[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [microblaze-uclinux] Rethinking MicroBlaze commandline precedence
John Williams wrote:
> Hi Michal,
> On Mon, Aug 10, 2009 at 5:29 PM, Michal Simek<michal.simek@xxxxxxxxxxxxx> 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).
>> 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
> 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?
Not sure if is help - but seems to me more complicated than we need.
>> 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! :)
It is more complicated than origin file. Your suggestion for simple build/boot is fine. :-)
>> 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
> 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?
I understand that make sense to change it - especially for development.
It should be possible to do it in u-boot. Not sure if is work to extend command line but maybe yes.
Worth to ask on u-boot mailing list.
> 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.
You should be able to change it in u-boot. The size of mac addr is the same. Shorten is possible too.
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663
microblaze-uclinux mailing list
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/