From: Michal Simek <michal.simek@petalogix.com>
To: microblaze-uclinux@itee.uq.edu.au
Cc: John Linn <John.Linn@xilinx.com>,
David DeBonis <david.debonis@xilinx.com>,
Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [microblaze-uclinux] Rethinking MicroBlaze commandline precedence
Date: Mon, 10 Aug 2009 09:29:06 +0200 [thread overview]
Message-ID: <4A7FCC42.40809@petalogix.com> (raw)
In-Reply-To: <1d3f23370908092328l6e980f3ft2d5a8f8f37c26fcf@mail.gmail.com>
Hi John,
John Williams wrote:
> Hi,
>
> 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).
>
> 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.
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.
Ad observation b) - for final product they will use only one command line. For testing you can setup
kernel to use only r5.
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.
Regards,
Michal
>
> 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
next prev parent reply other threads:[~2009-08-10 7:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-10 6:28 Rethinking MicroBlaze commandline precedence John Williams
2009-08-10 7:29 ` Michal Simek [this message]
2009-08-10 8:56 ` [microblaze-uclinux] " John Williams
2009-08-10 9:25 ` Michal Simek
2009-08-10 16:42 ` Stephen Neuendorffer
2009-08-11 7:06 ` Michal Simek
2009-08-11 16:18 ` Stephen Neuendorffer
2009-08-11 16:59 ` Michal Simek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A7FCC42.40809@petalogix.com \
--to=michal.simek@petalogix.com \
--cc=John.Linn@xilinx.com \
--cc=david.debonis@xilinx.com \
--cc=linux-kernel@vger.kernel.org \
--cc=microblaze-uclinux@itee.uq.edu.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox