Message-ID: <20090810164242.05DE8CC8055@mail83-dub.bigfish.com>
Date:	Mon, 10 Aug 2009 09:42:20 -0700
From:	Stephen Neuendorffer <stephen.neuendorffer@...inx.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



> -----Original Message-----
> From: owner-microblaze-uclinux@...ts.itee.uq.edu.au
[mailto:owner-microblaze-
> uclinux@...ts.itee.uq.edu.au] On Behalf Of Michal Simek
> Sent: Monday, August 10, 2009 2:26 AM
> To: microblaze-uclinux@...e.uq.edu.au
> Cc: John Linn; David DeBonis; Linux Kernel list
> Subject: Re: [microblaze-uclinux] Rethinking MicroBlaze commandline
precedence
> 
> Hi John,
> 
> John Williams wrote:
> > 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).

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?

> >>> 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?
> 
> Not sure if is help - but seems to me more complicated than we need.

I would strongly discourage this, if only because the device tree also
fulfills those requirements.

> >> 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?
> 
> yes.
> 
> >
> >> 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.

> > 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.
> 
> 
> Cheers,
> Michal
> 
> >
> > Cheers,
> >
> > John
> 
> --
> 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
> 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/
> 


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.


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