[PATCH] Remove loglevel from default kernel boot arguments to let kernel using it's default configuration.

Yorick Moko yorickmoko at gmail.com
Wed Jun 10 18:43:37 CEST 2009


I can confirm this (bootin shr-unstable from SD)

root at om-gta02 /proc $ cat /proc/cmdline
loglevel=4 console=tty0 console=ttySAC2,115200 init=/sbin/init ro
mtdparts=physmap-flash:-(nor);neo1973-nand:0x00040000(qi),0x00040000(depr-ub-env),0x00800000(kernel),0x000a0000(depr),0x00040000(identity-ext2),0x0f6a0000(rootfs)
 g_ether.dev_addr=00:1F:11:01:08:10
g_ether.host_addr=00:1F:11:01:08:11  root=/dev/mmcblk0p1 rootdelay=1
loglevel=1 quiet splash

it doesn't seem to make sense passing loglevel twice


as a result, my splash screen is disturbed by a blinking cursor

On Wed, Jun 10, 2009 at 6:36 PM, Sebastian
Krzyszkowiak<seba.dos1 at gmail.com> wrote:
> I'm just repeating, what mwester said to me on IRC. He said, that
> repeating loglevel=? in kernel command line twice is wrong, so it
> could be even issue with SD cards. Well, patch is very quick, so don't
> be sorry :) I just want to make loglevel=0 (or 1? which is the lowest
> value?) be really quiet, cause on SHR there are some kernel messages
> and they bork splash screen, and mwester said that repeating loglevel
> could be wrong.
>
> On 6/10/09, Nelson Castillo <arhuaco at freaks-unidos.net> wrote:
>> On Wed, Jun 10, 2009 at 1:17 PM, Sebastian
>> Krzyszkowiak<seba.dos1 at gmail.com> wrote:
>>> Shouldn't then kernel have lower default loglevel? loglevel=7 could be
>>> still turned on by long POWER press. Now even kernel can't decide,
>>> what loglevel  to use, when booting from NAND...
>>
>> We inherit this value from upstream Sebastian. It would be a little
>> cryptic to have a different OM default value IMHO.
>> I read a thread on LKML where people thought that this was better as a
>> kernel option.
>>
>> If you wanted to change this value at the moment you would have to
>> recompile Qi...
>>
>> From what I have read recently Qi philosophy (mid/long term) values SD
>> card over NAND thus this is not really an issue.
>>
>> I'm sorry about the patch :-/
>>
>
>



More information about the openmoko-kernel mailing list