[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [microblaze-uclinux] Rethinking MicroBlaze commandline precedence
> >>>>> 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
> >>>>> 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
> > DTS and then iteratively compile the kernel? Are all of these
> > points/fallback priorities necessary? Personally, it seems like I
> > one 'compiled-in' source, and then the option to override at boot
> > 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?
> >>>> I understand that you are trying to pass to kernel for example
> > 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,
> > do
> >>> u-boot and PPC simpleBoot add the capability to tweak at boot
> >>> 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
> > the capability to edit the cmdline on the terminal before boot.
> > the question of 'does someone have a bootloader' is moot... they can
> > always fall back on that one. This would also make microblaze arch
> > in the spirit of EPapr, which exactly tries to standardize all of
> > mechanisms.
> NO. I understand that you like PowerPC and in many cases is PowerPC
> example but create next simple bootloader just for changing command
> For final products is definitely useless. For developing we recommend
you to use
> IIRC on ppc you have to wait some sec to continue - this extend
> I believe that we want to fast boot as is possible.
I'm not suggesting that this is what should always be done. Generally
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.
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.
> 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
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
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/