Message-ID: <4A81A37F.4030000@petalogix.com>
Date:	Tue, 11 Aug 2009 18:59:43 +0200
From:	Michal Simek <michal.simek@...alogix.com>
To:	microblaze-uclinux@...e.uq.edu.au
CC:	John Linn <linnj@...inx.com>, David DeBonis <ddeboni@...inx.com>,
	Linux Kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [microblaze-uclinux] Rethinking MicroBlaze commandline precedence



Stephen Neuendorffer wrote:
>>>>>>> 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).
>>> This makes reasonable sense to me, although I wonder if the order is
>>> correct?  For instance, in many cases a flow may be to fix the
> hardware
>>> DTS and then iteratively compile the kernel?  Are all of these
>>> points/fallback priorities necessary?  Personally, it seems like I
> want
>>> one 'compiled-in' source, and then the option to override at boot
> time.
>>> Could it be simplified by getting rid CONFIG_CMDLINE alltogether and
>>> just using the DTS, now that this we always have a device tree?
>> From my point of view that CONFIG_CMDLINE_FORCE make perfectly sense
> to be sure
>> that no one else change my command line.
> 
> If there weren't so many options, maybe there wouldn't be so many places
> to get it wrong?

We have 3 option how to pass command line to kernel. Via r5, from dts/dtb, in kernel yourself.
That's not too much options (+ one forcing) and all make sense to me. John is talking about option
to have r5 higher priority than dts/dtb which make sense for some cases but we can easily reach it
with change kernel options or deleting command line from DTS.

> 
>>>>>> 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?
>>>> 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.
>>> One way around this is to do what powerpc has: a simple bootloader
> with
>>> the capability to edit the cmdline on the terminal before boot.
> Then
>>> the question of 'does someone have a bootloader' is moot... they can
>>> always fall back on that one.  This would also make microblaze arch
> more
>>> in the spirit of EPapr, which exactly tries to standardize all of
> these
>>> mechanisms.
>> NO. I understand that you like PowerPC and in many cases is PowerPC
> good
>> example but create next simple bootloader just for changing command
> line.
>> For final products is definitely useless. For developing we recommend
> you to use
>> U-BOOT.
>> IIRC on ppc you have to wait some sec to continue - this extend
> booting time.
>> I believe that we want to fast boot as is possible.
> 
> I'm not suggesting that this is what should always be done.  Generally
> speaking,
> I prefer u-boot as well, however, if the problem is
> that a user may not have a bootloader, then it is a reasonable
> assumption you could make.

If user don't have bootloader, then can use two options which have - dts/dtb and kernel
and not care about passing command line via register. I am convinced that for developing
will have bootloader and for final product one stable command line. And in all cases
we have xmd script which can add prepare command line before run the kernel.


> IMO, microblaze tries to do alot of initialization in the kernel proper,
> which may or may
> not be a good idea.  PowerPC avoids some of these issues by simply
> assuming there is always
> *some* sort of bootloader.

I am not sure what you mean.

> 
>> Do you have any link to that standard?
> 
> I think it is publicly accessibly at power.org.  Generally the goal is
> to attempt to standardize on the mechanism of passing parameters like
> the command line to the kernel.  Nothing is explicitly disallowed, but
> the preferred way to pass information of any type is in a structured
> device tree.

We have three standard mechanisms for it. There is no mystery in it.

We can keep this "issue" open but currently I haven't seen a reason
why do any change. If you have any data that users have problem with current
handling, please send it to me and we can discuss about. I don't have any and none
reported any problem with it.

John mentioned case with different MAC for every board where MAC configuring make sense
but for find out that value you should use any advance booting mechanism which u-boot do it.

Michal


> 
> Steve
> 
> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
> 
> 
> 
> ___________________________
> microblaze-uclinux mailing list
> microblaze-uclinux@...e.uq.edu.au
> Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
> Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
> 
> 

-- 
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
--
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