Rethinking MicroBlaze commandline precedence

Rethinking MicroBlaze commandline precedence

[John Williams]

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?

John
-- 
John Williams, PhD, B.Eng, B.IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663

Re: [microblaze-uclinux] Rethinking MicroBlaze commandline precedence

[Michal Simek]

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

Re: [microblaze-uclinux] Rethinking MicroBlaze commandline precedence

[John Williams]

Hi Michal,

On Mon, Aug 10, 2009 at 5:29 PM, Michal Simek<michal.simek@petalogix.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).
>>
>> 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?

> 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! :)

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

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

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.

Cheers,

John
-- 
John Williams, PhD, B.Eng, B.IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663

Re: [microblaze-uclinux] Rethinking MicroBlaze commandline precedence

[Michal Simek]

Hi John,

John Williams wrote:
> Hi Michal,
> 
> On Mon, Aug 10, 2009 at 5:29 PM, Michal Simek<michal.simek@petalogix.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).
>>>
>>> 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.

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

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

RE: [microblaze-uclinux] Rethinking MicroBlaze commandline precedence

[Stephen Neuendorffer]

> -----Original Message-----
> From: owner-microblaze-uclinux@lists.itee.uq.edu.au
[mailto:owner-microblaze-
> uclinux@lists.itee.uq.edu.au] On Behalf Of Michal Simek
> Sent: Monday, August 10, 2009 2:26 AM
> To: microblaze-uclinux@itee.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@petalogix.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@itee.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.

Re: [microblaze-uclinux] Rethinking MicroBlaze commandline precedence

[Michal Simek]

Stephen Neuendorffer wrote:
> 
>> -----Original Message-----
>> From: owner-microblaze-uclinux@lists.itee.uq.edu.au
> [mailto:owner-microblaze-
>> uclinux@lists.itee.uq.edu.au] On Behalf Of Michal Simek
>> Sent: Monday, August 10, 2009 2:26 AM
>> To: microblaze-uclinux@itee.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@petalogix.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?

>From my point of view that CONFIG_CMDLINE_FORCE make perfectly sense to be sure
that no one else change my command line.

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

I didn't mean that device tree misses functions. I just say that is more complicated
to do that scheme which John described - nothing more nothing less.

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

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.

Do you have any link to that standard?

Michal


> 
>>> 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@itee.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.
> 
> 
> 
> ___________________________
> microblaze-uclinux mailing list
> microblaze-uclinux@itee.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

RE: [microblaze-uclinux] Rethinking MicroBlaze commandline precedence

[Stephen Neuendorffer]

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

Re: [microblaze-uclinux] Rethinking MicroBlaze commandline precedence

[Michal Simek]

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@itee.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