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)

-

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
-

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
-

On Thu, 25 Oct 2007 14:43:36 +0100
It was in the inital report, at
-

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
-

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
-

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:

-