Re: [Bugme-new] [Bug 9217] New: CONFIG_CMDLINE doesn't pass to kernel

Re: [Bugme-new] [Bug 9217] New: CONFIG_CMDLINE doesn't pass to kernel

[Andrew Morton]

On Wed, 24 Oct 2007 05:32:14 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=9217
> 
>            Summary: CONFIG_CMDLINE doesn't pass to kernel
>            Product: Other
>            Version: 2.5
>      KernelVersion: 2.6.23
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: high
>           Priority: P1
>          Component: Other
>         AssignedTo: other_other@kernel-bugs.osdl.org
>         ReportedBy: svs1957@gmail.com
> 
> 
> Most recent kernel where this bug did not occur:2.6.24-rc1
> Distribution: Debian Armel (arm with EABI)
> Hardware Environment: Sharp Zaurus 750 (ARM pxa255)
> Software Environment: Debian
> Problem Description:
> I try to upgrade kernel from 2.6.22.9 to 2.6.23.
> 2.6.22.9 works correct. Kernel 2.6.23 doesn't use  CONFIG_CMDLINE and doesn't
> pass bootparams:
> CONFIG_CMDLINE="console=ttyS0,115200n8 console=tty1 noinitrd
> root=/dev/mmcblk0p1 rootfstype=ext3 rw rootdelay=5"
> But kernel still try to mount /dev/mtdblock2 using jffs2.
> Steps to reproduce:
> Compile kernel with CONFIG_CMDLINE and try to boot.
> 
> 

Something broke CONFIG_CMDLINE of ARM (at least) between 2.6.22 and 2.6.23.

I don't know whether it was an ARM patch one of those kernel-wide changes. 
We have futzed with the command-line parsing a bit recently, but the 2.6.23
changelog doesn't suggest anything obvious.

Re: [Bugme-new] [Bug 9217] New: CONFIG_CMDLINE doesn't pass to kernel

[Bill Gatliff]

Andrew Morton wrote:
> Something broke CONFIG_CMDLINE of ARM (at least) between 2.6.22 and 2.6.23.
>
> I don't know whether it was an ARM patch one of those kernel-wide changes. 
> We have futzed with the command-line parsing a bit recently, but the 2.6.23
> changelog doesn't suggest anything obvious.
>   

What does the affected system's bootloader pass in r2?  If it's nonzero, 
ARM's 2.6.23 may interpret it as being an ATAGS pointer.  And when that 
happens, the system prefers the ATAGS over CONFIG_CMDLINE.

There's sanity checking in __vet_atags, but maybe it isn't enough.  
Other than that, I can't see anything yet.


b.g.

-- 
Bill Gatliff
bgat@billgatliff.com

Re: [Bugme-new] [Bug 9217] New: CONFIG_CMDLINE doesn't pass to kernel

[mwester]

> On Wed, 24 Oct 2007 05:32:14 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote:
> 
> > http://bugzilla.kernel.org/show_bug.cgi?id=9217
> > 
> >            Summary: CONFIG_CMDLINE doesn't pass to kernel
> >            Product: Other
> >            Version: 2.5
> >      KernelVersion: 2.6.23
> >           Platform: All
> >         OS/Version: Linux
> >               Tree: Mainline
> >             Status: NEW
> >           Severity: high
> >           Priority: P1
> >          Component: Other
> >         AssignedTo: other_other@kernel-bugs.osdl.org
> >         ReportedBy: svs1957@gmail.com
> > 
> > 
> > Most recent kernel where this bug did not occur:2.6.24-rc1
> > Distribution: Debian Armel (arm with EABI)
> > Hardware Environment: Sharp Zaurus 750 (ARM pxa255)
> > Software Environment: Debian
> > Problem Description:
> > I try to upgrade kernel from 2.6.22.9 to 2.6.23.
> > 2.6.22.9 works correct. Kernel 2.6.23 doesn't use  CONFIG_CMDLINE and doesn't
> > pass bootparams:
> > CONFIG_CMDLINE="console=ttyS0,115200n8 console=tty1 noinitrd
> > root=/dev/mmcblk0p1 rootfstype=ext3 rw rootdelay=5"
> > But kernel still try to mount /dev/mtdblock2 using jffs2.
> > Steps to reproduce:
> > Compile kernel with CONFIG_CMDLINE and try to boot.
> > 
> > 
> 
> Something broke CONFIG_CMDLINE of ARM (at least) between 2.6.22 and 2.6.23.
> 
> I don't know whether it was an ARM patch one of those kernel-wide changes. 
> We have futzed with the command-line parsing a bit recently, but the 2.6.23
> changelog doesn't suggest anything obvious.

I think the zaurus kernel deliberately ignored the bootparams passed in by the device's bootloader.  The 2.6.23 kernel now honors the r2 setting from the bootloader, which is most likely pointing to those ATAGs that were being ignored earlier.

I suppose you can hack up the logic in setup.c where the ATAGs are parsed, but it seems to me that it would be better to work out some logic, perhaps in the fixup section for that machine, to do whatever is necessary to override or otherwise get along with the bootloader.

Mike (mwester)

Re: [Bugme-new] [Bug 9217] New: CONFIG_CMDLINE doesn't pass to kernel

[Lennert Buytenhek]

On Wed, Oct 24, 2007 at 10:35:33PM -0500, Bill Gatliff wrote:

> >Something broke CONFIG_CMDLINE of ARM (at least) between 2.6.22 and 2.6.23.
> >
> >I don't know whether it was an ARM patch one of those kernel-wide changes. 
> >We have futzed with the command-line parsing a bit recently, but the 2.6.23
> >changelog doesn't suggest anything obvious.
> 
> What does the affected system's bootloader pass in r2?  If it's nonzero, 
> ARM's 2.6.23 may interpret it as being an ATAGS pointer.  And when that 
> happens, the system prefers the ATAGS over CONFIG_CMDLINE.
> 
> There's sanity checking in __vet_atags, but maybe it isn't enough.  
> Other than that, I can't see anything yet.

If this is the SHARP Shepherd (which seems to be the Zaurus SL-C750,
which looks like it's the one the submitter is using), it's not setting
boot_params at all:

	MACHINE_START(SHEPHERD, "SHARP Shepherd")
		.phys_io        = 0x40000000,
		.io_pg_offst    = (io_p2v(0x40000000) >> 18) & 0xfffc,
		.fixup          = fixup_corgi,
		.map_io         = pxa_map_io,
		.init_irq       = pxa25x_init_irq,
		.init_machine   = corgi_init,
		.timer          = &pxa_timer,
	MACHINE_END

Re: [Bugme-new] [Bug 9217] New: CONFIG_CMDLINE doesn't pass to kernel

[Richard Purdie]

On Thu, 2007-10-25 at 14:23 +0200, Lennert Buytenhek wrote:
> On Wed, Oct 24, 2007 at 10:35:33PM -0500, Bill Gatliff wrote:
> 
> > >Something broke CONFIG_CMDLINE of ARM (at least) between 2.6.22 and 2.6.23.
> > >
> > >I don't know whether it was an ARM patch one of those kernel-wide changes. 
> > >We have futzed with the command-line parsing a bit recently, but the 2.6.23
> > >changelog doesn't suggest anything obvious.
> > 
> > What does the affected system's bootloader pass in r2?  If it's nonzero, 
> > ARM's 2.6.23 may interpret it as being an ATAGS pointer.  And when that 
> > happens, the system prefers the ATAGS over CONFIG_CMDLINE.
> > 
> > There's sanity checking in __vet_atags, but maybe it isn't enough.  
> > Other than that, I can't see anything yet.
> 
> If this is the SHARP Shepherd (which seems to be the Zaurus SL-C750,
> which looks like it's the one the submitter is using), it's not setting
> boot_params at all:
> 
> 	MACHINE_START(SHEPHERD, "SHARP Shepherd")
> 		.phys_io        = 0x40000000,
> 		.io_pg_offst    = (io_p2v(0x40000000) >> 18) & 0xfffc,
> 		.fixup          = fixup_corgi,
> 		.map_io         = pxa_map_io,
> 		.init_irq       = pxa25x_init_irq,
> 		.init_machine   = corgi_init,
> 		.timer          = &pxa_timer,
> 	MACHINE_END

The Zaurus has an insane bootloader which doesn't pass any sane values,
it doesn't support the right (well, any) machine number and the
commandline it passes is unchangeable and bogus too. The approach has
always therefore been to pretend it doesn't exist and used a commandline
compiled into the kernel.

Could the original bug reporter please report what commandline the
kernel actually uses please? In theory it can only be either:

* the one being compiled in with CONFIG_CMDLINE
* the one hardcoded into the bootloader

but I'd be surprised it boots at all with the latter!

Cheers,

Richard

Re: [Bugme-new] [Bug 9217] New: CONFIG_CMDLINE doesn't pass to kernel

[Andrew Morton]

On Thu, 25 Oct 2007 14:43:36 +0100
Richard Purdie <rpurdie@rpsys.net> wrote:

> On Thu, 2007-10-25 at 14:23 +0200, Lennert Buytenhek wrote:
> > On Wed, Oct 24, 2007 at 10:35:33PM -0500, Bill Gatliff wrote:
> > 
> > > >Something broke CONFIG_CMDLINE of ARM (at least) between 2.6.22 and 2.6.23.
> > > >
> > > >I don't know whether it was an ARM patch one of those kernel-wide changes. 
> > > >We have futzed with the command-line parsing a bit recently, but the 2.6.23
> > > >changelog doesn't suggest anything obvious.
> > > 
> > > What does the affected system's bootloader pass in r2?  If it's nonzero, 
> > > ARM's 2.6.23 may interpret it as being an ATAGS pointer.  And when that 
> > > happens, the system prefers the ATAGS over CONFIG_CMDLINE.
> > > 
> > > There's sanity checking in __vet_atags, but maybe it isn't enough.  
> > > Other than that, I can't see anything yet.
> > 
> > If this is the SHARP Shepherd (which seems to be the Zaurus SL-C750,
> > which looks like it's the one the submitter is using), it's not setting
> > boot_params at all:
> > 
> > 	MACHINE_START(SHEPHERD, "SHARP Shepherd")
> > 		.phys_io        = 0x40000000,
> > 		.io_pg_offst    = (io_p2v(0x40000000) >> 18) & 0xfffc,
> > 		.fixup          = fixup_corgi,
> > 		.map_io         = pxa_map_io,
> > 		.init_irq       = pxa25x_init_irq,
> > 		.init_machine   = corgi_init,
> > 		.timer          = &pxa_timer,
> > 	MACHINE_END
> 
> The Zaurus has an insane bootloader which doesn't pass any sane values,
> it doesn't support the right (well, any) machine number and the
> commandline it passes is unchangeable and bogus too. The approach has
> always therefore been to pretend it doesn't exist and used a commandline
> compiled into the kernel.
> 
> Could the original bug reporter please report what commandline the
> kernel actually uses please? In theory it can only be either:
> 
> * the one being compiled in with CONFIG_CMDLINE
> * the one hardcoded into the bootloader
> 
> but I'd be surprised it boots at all with the latter!
> 

It was in the inital report, at
http://bugzilla.kernel.org/show_bug.cgi?id=9217 :


: I try to upgrade kernel from 2.6.22.9 to 2.6.23.
: 2.6.22.9 works correct. Kernel 2.6.23 doesn't use  CONFIG_CMDLINE and doesn't
: pass bootparams:
: CONFIG_CMDLINE="console=ttyS0,115200n8 console=tty1 noinitrd
: root=/dev/mmcblk0p1 rootfstype=ext3 rw rootdelay=5"
: But kernel still try to mount /dev/mtdblock2 using jffs2.
: Steps to reproduce:
: Compile kernel with CONFIG_CMDLINE and try to boot.

Re: [Bugme-new] [Bug 9217] New: CONFIG_CMDLINE doesn't pass to kernel

[Richard Purdie]

On Thu, 2007-10-25 at 13:02 -0700, Andrew Morton wrote:
> On Thu, 25 Oct 2007 14:43:36 +0100
> Richard Purdie <rpurdie@rpsys.net> wrote: 
> > Could the original bug reporter please report what commandline the
> > kernel actually uses please? In theory it can only be either:
> > 
> > * the one being compiled in with CONFIG_CMDLINE
> > * the one hardcoded into the bootloader
> > 
> > but I'd be surprised it boots at all with the latter!
> 
> It was in the inital report, at
> http://bugzilla.kernel.org/show_bug.cgi?id=9217 :

No it wasn't, I'd looked.

> : I try to upgrade kernel from 2.6.22.9 to 2.6.23.
> : 2.6.22.9 works correct. Kernel 2.6.23 doesn't use  CONFIG_CMDLINE and doesn't
> : pass bootparams:
> : CONFIG_CMDLINE="console=ttyS0,115200n8 console=tty1 noinitrd
> : root=/dev/mmcblk0p1 rootfstype=ext3 rw rootdelay=5"
> : But kernel still try to mount /dev/mtdblock2 using jffs2.
> : Steps to reproduce:
> : Compile kernel with CONFIG_CMDLINE and try to boot.

This is the commandline they wanted to use, not the one that was
actually used. The one that was used should appear on the console, on
the serial console if they have the lead or in dmesg when the device
boots. We know it probably contained root=/dev/mtdblock2 but thats it.

I'd like to confirm which commandline is appearing since if we know
which one it is we might stand a chance of knowing where it came from,
until then this is just a guessing game.

Cheers,

Richard

Re: [Bugme-new] [Bug 9217] New: CONFIG_CMDLINE doesn't pass to kernel

[Richard Purdie]

On Thu, 2007-10-25 at 22:54 +0100, Richard Purdie wrote:
> On Thu, 2007-10-25 at 13:02 -0700, Andrew Morton wrote:
> > It was in the inital report, at
> > http://bugzilla.kernel.org/show_bug.cgi?id=9217 :
>
> This is the commandline they wanted to use, not the one that was
> actually used. The one that was used should appear on the console, on
> the serial console if they have the lead or in dmesg when the device
> boots. We know it probably contained root=/dev/mtdblock2 but thats it.
> 
> I'd like to confirm which commandline is appearing since if we know
> which one it is we might stand a chance of knowing where it came from,
> until then this is just a guessing game.

There was a followup in the bugzilla:

> I use u-boot to boot kernel.
> When kernel >=2.6.23 boot it use u-boot default bootparam:
> console=ttyS0,115200 console=tty1 root=/dev/mtdblock2 rootfstype=jffs2
> Now I try to change it in u-boot source.
>
> kernel 2.6.22.9 change default u-boot boot params to what I set in
> CONFIG_CMDLINE But 2.6.23 and later doesn't

So its not the standard bootloader, its one which passes an ATAG
commandline and 2.6.23 onwards uses an ATAG commandline if present over
the compiled in commandline.

My opinion is that this is a feature. Recompile the bootloader without
the commandline if you want to use the one compiled into the kernel.

This is going to be useful in the future when booting Zaurus kernels
with kexec since it means we can customise the commandline through the
ATAGs.

Cheers,

Richard

Re: [Bugme-new] [Bug 9217] New: CONFIG_CMDLINE doesn't pass to kernel

[Russell King]

On Sun, Oct 28, 2007 at 10:46:47PM +0000, Richard Purdie wrote:
> On Thu, 2007-10-25 at 22:54 +0100, Richard Purdie wrote:
> > On Thu, 2007-10-25 at 13:02 -0700, Andrew Morton wrote:
> > > It was in the inital report, at
> > > http://bugzilla.kernel.org/show_bug.cgi?id=9217 :
> >
> > This is the commandline they wanted to use, not the one that was
> > actually used. The one that was used should appear on the console, on
> > the serial console if they have the lead or in dmesg when the device
> > boots. We know it probably contained root=/dev/mtdblock2 but thats it.
> > 
> > I'd like to confirm which commandline is appearing since if we know
> > which one it is we might stand a chance of knowing where it came from,
> > until then this is just a guessing game.
> 
> There was a followup in the bugzilla:
> 
> > I use u-boot to boot kernel.
> > When kernel >=2.6.23 boot it use u-boot default bootparam:
> > console=ttyS0,115200 console=tty1 root=/dev/mtdblock2 rootfstype=jffs2
> > Now I try to change it in u-boot source.
> >
> > kernel 2.6.22.9 change default u-boot boot params to what I set in
> > CONFIG_CMDLINE But 2.6.23 and later doesn't
> 
> So its not the standard bootloader, its one which passes an ATAG
> commandline and 2.6.23 onwards uses an ATAG commandline if present
> over the compiled in commandline.

That statement is misleading.  The kernel has _always_ used the command
line passed from the boot loader in preference to the built-in command
line.

The thing that's changed is that the kernel how honors the value passed
from the boot loader in R2 to find out where the ATAG list is - as
documented since 2002 that it will eventually do.  That's 5 years
of warning.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of: