linux-kernel - RE: [microblaze-uclinux] Rethinking MicroBlaze commandline precedence

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090811161911.31858AF0053@mail161-va3.bigfish.com>
Date:	Tue, 11 Aug 2009 09:18:54 -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

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

> >>>> 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.
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
device tree.

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.


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