Message-ID: <1d3f23370908100156q46b9869av5ecdcc8879617be9@mail.gmail.com>
Date:	Mon, 10 Aug 2009 18:56:06 +1000
From:	John Williams <john.williams@...alogix.com>
To:	microblaze-uclinux@...e.uq.edu.au
Cc:	John Linn <John.Linn@...inx.com>,
	David DeBonis <david.debonis@...inx.com>,
	Linux Kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [microblaze-uclinux] Rethinking MicroBlaze commandline precedence

Hi Michal,

On Mon, Aug 10, 2009 at 5:29 PM, Michal Simek<michal.simek@...alogix.com> wrote:

> John Williams wrote:

>> Currently, MicroBlaze commandline handling in order of lowest to
>> highest priority, looks like this:
>>
>> 1. pointer in r5 from bootloader
>> 2. CONFIG_CMDLINE=...
>> 3. "chosen" section in DTS/DT
>> 4. CONFIG_CMDLINE=... && CONFIG_CMDLINE_FORCE
>>
>> I'm wondering if a cmdline in r5 should override the DTS.  My thinking
>> is based on two observations:
>>
>> (a) not everyone will use a bootloader like u-boot that can manipulate
>> DTBs easily before kernel boot
>> (b) a custom cmdline string in r5 allows the latest possible binding
>> (runtime), where as the DTB is typically created at compile time.
>>
>> So, how about this order instead:
>>
>> 1. CONFIG_CMDLINE=...
>> 2. "chosen" section in DTS/DT
>> 3. pointer in r5 from bootloader
>> 4. CONFIG_CMDLINE=... and CONFIG_CMDLINE_FORCE
>>
>> Then, apart from CMDLINE_FORCE, the precedence goes from earliest
>> binding (kernel build) to latest (runtime via bootloader/r5).
>>
>> Thoughts?
>
> I see there one big problem which can easily arise. Kernel expect that r5 points to
> NULL string and DTS/DTB and CMDLINE will contain correct string. Kernel just copy it and use
> it. There will be undefined behavior for more cases than for current handling. It will be
> less error prune.

This expectation currently exists anyway,  giving precendence to DTS
cmdline is only less error-prone on the assumption that it's more
common.

What about a move to an ARM-style ATAGs arrangement, where r5 points
not to an ASCIIZ string but instead to some sort of loosely structured
object, with tag codes to signify the commandline etc.

That way, we can error check r5 - if it doesn't have the right tags
then we don't use the (probably bogus) cmdline string?

> Ad observation a)
>
> My expectation is that users will use s.....I.... format (I don't like that name - What about
> renaming it?) with dtb - they setup commandline at once and they don't change it.


Ah what's wrong with simpleImage?  It's simple to boot, and make-fu
makes it simple to build! :)

> Ad observation b) - for final product they will use only one command line. For testing you can setup
> kernel to use only r5.

How?  Do we add CONFIG_CMDLINE_IGNORE_DTB?

Or just remove the commandline section from DTS "chosen" part?

> I understand that you are trying to pass to kernel for example MTD map which could be possible but
> IMHO better to do this in script which one with sed erase/comment/setup command line in DTS before
> compilation.

It's still a very early binding, and I think there are plenty of
reasons to want to override it at boot time.  If there weren't, why do
u-boot and PPC simpleBoot add the capability to tweak at boot time,
the cmdline passed via the DTB?

Setting MAC addresses for example - you don't want to compile a new
DTS for every board you ship, just to provide unique values. You just
want to be able to tweak the cmdline in the config flash or whatever.

Cheers,

John
-- 
John Williams, PhD, B.Eng, B.IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists