[U-Boot-Users] Re: FT u-boot shim

[U-Boot-Users] Re: FT u-boot shim

[Kumar Gala]

On Apr 26, 2006, at 2:19 PM, Wolfgang Denk wrote:

> In message <A8793E99-83C1-4FD9-8735- 
> D2E8F98B3003 at kernel.crashing.org> you wrote:
>>
>> I think thats part of the idea with arch/powerpc defining a standard
>> mechanism for how a boot loader should pass information to the kernel
>> (via a flat device tree).
>
> Yet another standard.
>
>> How would you propose that we handle booting arch/powerpc kernels
>> from u-boot going forward? (for new board ports and existing board
>> ports).
>
> Ideally, I'd like to see a common kernel  interface  for  all  archi-
> tectures,  PowerPC  and ARM and MIPS and ... But last time I dared to
> suggest this I've been told what a nincompoop I am.
>
> I will accept what is decided by the P.T.B., but  I  request  not  to
> break backwards compatibility with existing systems.

I've been thinking about the various issues related to booting an  
arch/powerpc kernel via u-boot.   I was hoping to get some ideas/ 
comments on what people thought about the various issues/questions  
related to producing a system that can boot an arch/powerpc kernel  
for an embedded system.  I'm using u-boot as the boot loader since  
its a popular choice (I imagine the issues are similar for others):

[NOTE: dts, flat dev tree, etc are used interchangeably]

1. boot with an "old" u-boot (via bd_t):
* Have a boot wrapper that takes bd_t and dts and merges them @ runtime
* Boot wrapper has to be custom based on bd_t definition for the system
* dts owned by kernel??

2. boot with a "new" u-boot (has a .dts in it):
* capable of booting arch/powerpc kernel directly w/o modification
* in a production system don't want to update u-boot
* dts owned by u-boot??

Some questions/issues:
* ownership of .dts is problematic.  I hate having a file duplicated  
by both u-boot and kernel.  However it also seems bad to make the  
build of either depend on the user grabbing a dts from some third  
party.  Ideas?  A concrete example would be the MPC8349 ADS/SYS/MDS  
port.  Boards ship with an "old" u-boot, thus we need a kernel  
wrapper with .dts.  However, newer u-boot's can (hopefully will) have  
a dts in them

* updating of dts:  In case 1, this is trivial since its part of the  
kernel blob.  Case 2. is more difficult.  What do people think of  
treating the dts like the environment.  You have a version compiled  
in, but can alternately have a blob in another location that will be  
used if exists.  This would allow one to update the dts portion w/o  
effecting the actual boot loader.

* one solution to the copies of .dts is that we make the wrapper  
portion of the kernel the owner of the official latest and  
greatest .dts.  Every so often a maintainer can sync their .dts with  
u-boot to keep them relatively in sync.  However, the main mechanism  
would be to load the latest .dts blob into the secondary location.   
We can provide scripts/tools to do this via u-boot and linux.

comments, other issues people have thought of?

- kumar

[U-Boot-Users] Re: FT u-boot shim

[Wolfgang Denk]

In message <6E3621C5-A379-4ABC-99C0-9A02B48D525D@kernel.crashing.org>
Kumar Gala wrote:
> 
> 1. boot with an "old" u-boot (via bd_t):
> * Have a boot wrapper that takes bd_t and dts and merges them @ runtime
> * Boot wrapper has to be custom based on bd_t definition for the system
> * dts owned by kernel??

Since we cannot go back in time and fix the "old" U-Boot  this  seems
to be the only option.

> 2. boot with a "new" u-boot (has a .dts in it):
> * capable of booting arch/powerpc kernel directly w/o modification

OK.

> * in a production system don't want to update u-boot

Let's say we have to support such situations, too.

> * dts owned by u-boot??

I'm not sure about this. I tend to believe the  dts  belongs  to  the
kernel.

> Some questions/issues:
> * ownership of .dts is problematic.  I hate having a file duplicated  
> by both u-boot and kernel.  However it also seems bad to make the  
> build of either depend on the user grabbing a dts from some third  
> party.  Ideas?  A concrete example would be the MPC8349 ADS/SYS/MDS  
> port.  Boards ship with an "old" u-boot, thus we need a kernel  
> wrapper with .dts.  However, newer u-boot's can (hopefully will) have  
> a dts in them

Can we provide the dts as a separate blob that gets  built  with  the
kernel image? From U-Boot's point of view, this could be a multi-file
image  which  combines  the  dts and the kernel into a single file so
that users don't have to care much about this.

> * updating of dts:  In case 1, this is trivial since its part of the  
> kernel blob.  Case 2. is more difficult.  What do people think of  
> treating the dts like the environment.  You have a version compiled  

I don't like this idea.

> in, but can alternately have a blob in another location that will be  
> used if exists.  This would allow one to update the dts portion w/o  
> effecting the actual boot loader.

If we consider this, then we might as well combine the dts  with  the
kernel  image.  Alternatively,  the dts might be stored in a separate
location in memory. It would be easy to extend the "bootm" command to
take an additional argument (dts address).

> * one solution to the copies of .dts is that we make the wrapper  
> portion of the kernel the owner of the official latest and  
> greatest .dts.  Every so often a maintainer can sync their .dts with  
> u-boot to keep them relatively in sync.  However, the main mechanism  
> would be to load the latest .dts blob into the secondary location.   

Why not load it separately or as part of the Linux kernel image?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
No user-servicable parts inside. Refer to qualified service personnel.

[U-Boot-Users] Re: FT u-boot shim

[Kumar Gala]

> Let's say we have to support such situations, too.
>
>> * dts owned by u-boot??
>
> I'm not sure about this. I tend to believe the  dts  belongs  to  the
> kernel.
>
>> Some questions/issues:
>> * ownership of .dts is problematic.  I hate having a file duplicated
>> by both u-boot and kernel.  However it also seems bad to make the
>> build of either depend on the user grabbing a dts from some third
>> party.  Ideas?  A concrete example would be the MPC8349 ADS/SYS/MDS
>> port.  Boards ship with an "old" u-boot, thus we need a kernel
>> wrapper with .dts.  However, newer u-boot's can (hopefully will) have
>> a dts in them
>
> Can we provide the dts as a separate blob that gets  built  with  the
> kernel image? From U-Boot's point of view, this could be a multi-file
> image  which  combines  the  dts and the kernel into a single file so
> that users don't have to care much about this.

The problem is that there are somethings that u-boot knows that needs  
to go into the blob (memory size, boot args, initrd info,  
frequencies, etc.)

>> * updating of dts:  In case 1, this is trivial since its part of the
>> kernel blob.  Case 2. is more difficult.  What do people think of
>> treating the dts like the environment.  You have a version compiled
>
> I don't like this idea.
>
>> in, but can alternately have a blob in another location that will be
>> used if exists.  This would allow one to update the dts portion w/o
>> effecting the actual boot loader.
>
> If we consider this, then we might as well combine the dts  with  the
> kernel  image.  Alternatively,  the dts might be stored in a separate
> location in memory. It would be easy to extend the "bootm" command to
> take an additional argument (dts address).

How would we distinguish the bootm command that takes a blob versus  
the ones we have today?

>> * one solution to the copies of .dts is that we make the wrapper
>> portion of the kernel the owner of the official latest and
>> greatest .dts.  Every so often a maintainer can sync their .dts with
>> u-boot to keep them relatively in sync.  However, the main mechanism
>> would be to load the latest .dts blob into the secondary location.
>
> Why not load it separately or as part of the Linux kernel image?

As stated before, the main issue is doing some runtime fix ups to the  
blob before its handed to the kernel.

The following pieces of info are setup at runtime that are board  
specific:

linux,stdout_path
cpus/<foo>/clock-frequency
cpus/<foo>/timebase-frequency
cpus/<foo>/bus-frequency
<soc>/pci/bus-range
<soc>/bus-frequency
<soc>/serial/clock-frequecny
<soc>/ethernet/address

We could hand bootm a memory location with a blob and do the fix ups  
at runtime, we would still have some coupling between the blob and u- 
boot build.  At least the blob wouldn't be built into u-boot.

- kumar

[U-Boot-Users] RE: FT u-boot shim

[Rune Torgersen]

Would it be possible to have the kernel smart enough that if it gets
passed a bd_t pointer, it updates the dts before booting fully. 
Newer u-boot versions that support dts then would pass a NULL bd_t
pointer to a kernel that supports dts. Kernel would then not update the
dts, but use the one it gets handed.

bootm should be able to see if the kernel has an attached dts, update it
with runtime parameters, and hand it off to the kernel. If it is an old
kernel, hand it the bd_t pointer.

[U-Boot-Users] Re: FT u-boot shim

[Jerry Van Baren]

Kumar Gala wrote:
>> Let's say we have to support such situations, too.
>>
>>> * dts owned by u-boot??
>> I'm not sure about this. I tend to believe the  dts  belongs  to  the
>> kernel.
>>
>>> Some questions/issues:
>>> * ownership of .dts is problematic.  I hate having a file duplicated
>>> by both u-boot and kernel.  However it also seems bad to make the
>>> build of either depend on the user grabbing a dts from some third
>>> party.  Ideas?  A concrete example would be the MPC8349 ADS/SYS/MDS
>>> port.  Boards ship with an "old" u-boot, thus we need a kernel
>>> wrapper with .dts.  However, newer u-boot's can (hopefully will) have
>>> a dts in them
>> Can we provide the dts as a separate blob that gets  built  with  the
>> kernel image? From U-Boot's point of view, this could be a multi-file
>> image  which  combines  the  dts and the kernel into a single file so
>> that users don't have to care much about this.
> 
> The problem is that there are somethings that u-boot knows that needs  
> to go into the blob (memory size, boot args, initrd info,  
> frequencies, etc.)

[snip]

> - kumar

A thought that keeps recurring (but I've suppressed because I don't have 
time to play...) is that it would be Really Cool[tm] to store the u-boot 
env variables in a flat tree and then pass the env/tree to linux.  It 
also sounds like a major change & disruption to u-boot :-(.  I haven't 
looked at what it would do to code size either.

U-boot could then be a better OpenBoot than OpenBoot ;-)

gvb

[U-Boot-Users] Re: FT u-boot shim

[Kumar Gala]

On Apr 27, 2006, at 2:30 PM, Rune Torgersen wrote:

> Would it be possible to have the kernel smart enough that if it gets
> passed a bd_t pointer, it updates the dts before booting fully.
> Newer u-boot versions that support dts then would pass a NULL bd_t
> pointer to a kernel that supports dts. Kernel would then not update  
> the
> dts, but use the one it gets handed.

What you are describing is the boot shim method.

U-boot is already capable of effectively doing this.  You can set a u- 
boot environment variable to make bootm do different things if you  
have flat device tree support built into u-boot.

> bootm should be able to see if the kernel has an attached dts,  
> update it
> with runtime parameters, and hand it off to the kernel. If it is an  
> old
> kernel, hand it the bd_t pointer.

We can do this w/o too much modification to what is happening in u- 
boot today.  I'd probably like to keep the ability to build a dev  
tree into the u-boot binary, but make the preferred means to pass a  
blob into the bootm command.

- kumar

[U-Boot-Users] Re: FT u-boot shim

[Wolfgang Denk]

In message <D358E665-60E4-48C0-82FD-7A1C16DAF00C@kernel.crashing.org> you wrote:
>
> The problem is that there are somethings that u-boot knows that needs  
> to go into the blob (memory size, boot args, initrd info,  
> frequencies, etc.)

Yes. Can we append auch variable data to the fixed part of the dts?

> How would we distinguish the bootm command that takes a blob versus  
> the ones we have today?

Arg count. For example:

OLD:	bootm <kernel_addr>
   or	bootm <kernel_addr> <ramdisk_addr>

NEW:	bootm <kernel_addr> - <dts_addr>
   or	bootm <kernel_addr> <ramdisk_addr> <dts_addr>

> As stated before, the main issue is doing some runtime fix ups to the  
> blob before its handed to the kernel.

Let's do exactly this: runtime fix ups.

> We could hand bootm a memory location with a blob and do the fix ups  
> at runtime, we would still have some coupling between the blob and u- 
> boot build.  At least the blob wouldn't be built into u-boot.

OK.



Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is necessary to have purpose.
	-- Alice #1, "I, Mudd", stardate 4513.3

[U-Boot-Users] Re: FT u-boot shim

[Kumar Gala]

[snip]

> A thought that keeps recurring (but I've suppressed because I don't  
> have time to play...) is that it would be Really Cool[tm] to store  
> the u-boot env variables in a flat tree and then pass the env/tree  
> to linux.  It also sounds like a major change & disruption to u- 
> boot :-(.  I haven't looked at what it would do to code size either.

I believe this is already supported in u-boot as a config option.   
You can also pass the bd_t to the kernel via the flat dev tree if you  
want.

- kumar

[U-Boot-Users] Re: FT u-boot shim

[Wolfgang Denk]

In message <44511C88.1010107@smiths-aerospace.com> you wrote:
> 
> A thought that keeps recurring (but I've suppressed because I don't have 
> time to play...) is that it would be Really Cool[tm] to store the u-boot 
> env variables in a flat tree and then pass the env/tree to linux.  It 

If somebody wants to read the environment variables, you  don't  need
to create a flat tree from it.

Also, it doesn't solve the original problem as most of  the  informa-
tion  you  need to pass is NOT part of the environment (and shall not
become such a part).


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I thought my people would grow tired of killing. But you were  right,
they  see it is easier than trading. And it has its pleasures. I feel
it myself. Like the hunt, but with richer rewards.
	-- Apella, "A Private Little War", stardate 4211.8

[U-Boot-Users] Re: FT u-boot shim

[Wolfgang Denk]

In message <2CD98C5D-E51C-49CA-9BDC-6FE4C1B67854@kernel.crashing.org> you wrote:
> 
> We can do this w/o too much modification to what is happening in u- 
> boot today.  I'd probably like to keep the ability to build a dev  
> tree into the u-boot binary, but make the preferred means to pass a  

I don't like this, as it's a very Linux-centric view, but  U-Boot  is
supposed to be OS unaware and independent.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Q: Why do PCs have a reset button on the front?
A: Because they are expected to run Microsoft operating systems.

[U-Boot-Users] Re: FT u-boot shim

[Kumar Gala]

On Apr 27, 2006, at 2:40 PM, Wolfgang Denk wrote:

> In message  
> <D358E665-60E4-48C0-82FD-7A1C16DAF00C@kernel.crashing.org> you wrote:
>>
>> The problem is that there are somethings that u-boot knows that needs
>> to go into the blob (memory size, boot args, initrd info,
>> frequencies, etc.)
>
> Yes. Can we append auch variable data to the fixed part of the dts?

appending is not really how it works, but the runtime fixup is doable.

>> How would we distinguish the bootm command that takes a blob versus
>> the ones we have today?
>
> Arg count. For example:
>
> OLD:	bootm <kernel_addr>
>    or	bootm <kernel_addr> <ramdisk_addr>
>
> NEW:	bootm <kernel_addr> - <dts_addr>
>    or	bootm <kernel_addr> <ramdisk_addr> <dts_addr>
>
>> As stated before, the main issue is doing some runtime fix ups to the
>> blob before its handed to the kernel.
>
> Let's do exactly this: runtime fix ups.
>
>> We could hand bootm a memory location with a blob and do the fix ups
>> at runtime, we would still have some coupling between the blob and u-
>> boot build.  At least the blob wouldn't be built into u-boot.
>
> OK.

Let me play with this some now that I've got some direction.

- kumar

[U-Boot-Users] Re: FT u-boot shim

[Kumar Gala]

On Apr 27, 2006, at 2:45 PM, Wolfgang Denk wrote:

> In message <2CD98C5D- 
> E51C-49CA-9BDC-6FE4C1B67854 at kernel.crashing.org> you wrote:
>>
>> We can do this w/o too much modification to what is happening in u-
>> boot today.  I'd probably like to keep the ability to build a dev
>> tree into the u-boot binary, but make the preferred means to pass a
>
> I don't like this, as it's a very Linux-centric view, but  U-Boot  is
> supposed to be OS unaware and independent.

Hmm, I guess.  There really isn't anything about the device tree that  
is Linux specific.  Other OSes could choice to use it.  But lets  
argue about that one once I've got the mechanism in which we pass the  
blob in via the bootm command.

The only difference I see would be that the address of the blob would  
be implicit if the blob was built into u-boot.  We would still use a  
passed in blob via the bootm command if given.

- kumar

[U-Boot-Users] Re: FT u-boot shim

[Kumar Gala]

>> How would we distinguish the bootm command that takes a blob versus
>> the ones we have today?
>
> Arg count. For example:
>
> OLD:	bootm <kernel_addr>
>    or	bootm <kernel_addr> <ramdisk_addr>
>
> NEW:	bootm <kernel_addr> - <dts_addr>
>    or	bootm <kernel_addr> <ramdisk_addr> <dts_addr>

do you mean a literal '-' char for the no ramdisk, but dts case?

- kumar

[U-Boot-Users] Re: FT u-boot shim

[Jerry Van Baren]

Wolfgang Denk wrote:
> In message <44511C88.1010107@smiths-aerospace.com> you wrote:
>> A thought that keeps recurring (but I've suppressed because I don't have 
>> time to play...) is that it would be Really Cool[tm] to store the u-boot 
>> env variables in a flat tree and then pass the env/tree to linux.  It 
> 
> If somebody wants to read the environment variables, you  don't  need
> to create a flat tree from it.

Understood.  That is why it is Really Cool[tm] rather than Really 
Useful[tm] ;-)

> Also, it doesn't solve the original problem as most of  the  informa-
> tion  you  need to pass is NOT part of the environment (and shall not
> become such a part).
> 
> Best regards,
> Wolfgang Denk

I agree and disagree with the parenthetical part of your statement. 
Agree because it _wouldn't_ be a part of u-boot (technically it would be 
if someone put it in their default env for their specific board, but why 
would denx.de care?).

Disagree because, while u-boot needs/uses some env variables, 
engineers/companies/end users are free to add variables and, I dare say, 
most do.  If a given board needs to pass certain non u-boot parameters 
to linux, it would simply add that to its env (which already happens).

I'm not sure you (Wolfgang and Kumar) are following my thought fully (or 
my ignorance is showing to everybody but me).  The thought is to change 
the native format of the u-boot environment storage from the 
key-string/value-string pairs to the flat tree (OpenFirmware) format 
which still supports the same key-string/value-string capability (but 
can do more than that).

The advantage, as I see it, is that it would be unifying and thus easier 
to maintain the common variables (call it the GRand Unifying Flat Tree 
(GRAFT) ;-).  One language (flat tree), no shims, equivalent key/value 
utility (but a different underlying storage format), no visible 
difference for the users (but potentially an upgrade challenge for 
existing boards and env variables).

The disadvantage is that it would be disruptive to u-boot and may cause 
some bloating and discomfort.

gvb
(the naive)

P.S. For the non-USA readers: "may cause some bloating and discomfort" 
is a standard disclaimer on medicines advertised on TV over here.

[U-Boot-Users] Re: FT u-boot shim

[Pantelis Antoniou]

On Thursday 27 April 2006 23:40, Jerry Van Baren wrote:
> Wolfgang Denk wrote:
> > In message <44511C88.1010107@smiths-aerospace.com> you wrote:
> >> A thought that keeps recurring (but I've suppressed because I don't have 
> >> time to play...) is that it would be Really Cool[tm] to store the u-boot 
> >> env variables in a flat tree and then pass the env/tree to linux.  It 
> > 
> > If somebody wants to read the environment variables, you  don't  need
> > to create a flat tree from it.
> 
> Understood.  That is why it is Really Cool[tm] rather than Really 
> Useful[tm] ;-)
> 
> > Also, it doesn't solve the original problem as most of  the  informa-
> > tion  you  need to pass is NOT part of the environment (and shall not
> > become such a part).
> > 
> > Best regards,
> > Wolfgang Denk
> 
> I agree and disagree with the parenthetical part of your statement. 
> Agree because it _wouldn't_ be a part of u-boot (technically it would be 
> if someone put it in their default env for their specific board, but why 
> would denx.de care?).
> 
> Disagree because, while u-boot needs/uses some env variables, 
> engineers/companies/end users are free to add variables and, I dare say, 
> most do.  If a given board needs to pass certain non u-boot parameters 
> to linux, it would simply add that to its env (which already happens).
> 
> I'm not sure you (Wolfgang and Kumar) are following my thought fully (or 
> my ignorance is showing to everybody but me).  The thought is to change 
> the native format of the u-boot environment storage from the 
> key-string/value-string pairs to the flat tree (OpenFirmware) format 
> which still supports the same key-string/value-string capability (but 
> can do more than that).
> 
> The advantage, as I see it, is that it would be unifying and thus easier 
> to maintain the common variables (call it the GRand Unifying Flat Tree 
> (GRAFT) ;-).  One language (flat tree), no shims, equivalent key/value 
> utility (but a different underlying storage format), no visible 
> difference for the users (but potentially an upgrade challenge for 
> existing boards and env variables).
> 
> The disadvantage is that it would be disruptive to u-boot and may cause 
> some bloating and discomfort.
> 
> gvb
> (the naive)
> 
> P.S. For the non-USA readers: "may cause some bloating and discomfort" 
> is a standard disclaimer on medicines advertised on TV over here.
> 

Since I'm the guy responsible let me weigh in a bit.

For starters, yes it's possible to pass the whole env using the FT tree.
Use CONFIG_OF_HAS_UBOOT_ENV to pass the u-boot env to the FT tree.

As for the rest of the cat-fight, I'm afraid I don't have the energy
to jump in at the moment.

Perhaps tomorrow :)

Regards

Pantelis

> 
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 

[U-Boot-Users] Re: FT u-boot shim

[Wolfgang Denk]

In message <9F5CC364-8FC8-48BA-8D12-E524815B6537@kernel.crashing.org> you wrote:
> 
> Hmm, I guess.  There really isn't anything about the device tree that  
> is Linux specific.  Other OSes could choice to use it.  But lets  

I guess there are VxWorks BSP's for most of the boards we are talking
about, right? Do  they  use  the  device  tree?  I  would  be  *very*
surprised.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Microsoft Multimedia:
You have nice graphics, sound and animations when the system crashes.

[U-Boot-Users] Re: FT u-boot shim

[Wolfgang Denk]

In message <7BC50BA2-D657-4907-94AA-DB5926F22504@kernel.crashing.org> you wrote:
>
> > NEW:	bootm <kernel_addr> - <dts_addr>
> >    or	bootm <kernel_addr> <ramdisk_addr> <dts_addr>
> 
> do you mean a literal '-' char for the no ramdisk, but dts case?

Yes. We could write "bootm <kernel_addr> NULL <dts_addr>"  or  "bootm
<kernel_addr> none <dts_addr>" or anythingl ike that as well, but I'm
a lazy typist :-)

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"...this does not mean that some of us should not want, in  a  rather
dispassionate sort of way, to put a bullet through csh's head."
                   - Larry Wall in <1992Aug6.221512.5963@netlabs.com>

[U-Boot-Users] Re: FT u-boot shim

[Wolfgang Denk]

[Removed the linuxppc-dev address; this is off topic there.]

In message <44512C25.2080105@smiths-aerospace.com> you wrote:
>
> Disagree because, while u-boot needs/uses some env variables, 
> engineers/companies/end users are free to add variables and, I dare say, 
> most do.  If a given board needs to pass certain non u-boot parameters 
> to linux, it would simply add that to its env (which already happens).

Yes, of course. But we  are  talking  about  parameters  like  memory
sizes,  bank  start  addresses, clock frequencies and that stuff. You
don't want to have this in your environment.  At  least  not  in  the
environment we have today.

Of course we can discuss a  more  structured  approach  with  certain
"system" variables, which are not stored in flash, but autogenerated,
etc. But this is a different story.

> I'm not sure you (Wolfgang and Kumar) are following my thought fully (or 
> my ignorance is showing to everybody but me).  The thought is to change 
> the native format of the u-boot environment storage from the 
> key-string/value-string pairs to the flat tree (OpenFirmware) format 
> which still supports the same key-string/value-string capability (but 
> can do more than that).

I see three serious problems with such an approach:

* memory footprint (both code and data size)
* boot time
* backward compatibility

For example, there are systems in the field which use a 1 kB or 2  kB
EEPROM  on  a slow I2C bus to store the environment (and a 128 kB ROM
for the U-Boot  code).  The  current  format  works  well  with  such
systems. How much of this is left if you switch to OFT format?

> The advantage, as I see it, is that it would be unifying and thus easier 
> to maintain the common variables (call it the GRand Unifying Flat Tree 
> (GRAFT) ;-).  One language (flat tree), no shims, equivalent key/value 

I guess you cannot convince me before you can show that Linux on  ARM
and MIPS (or at least *one* of these) will accept this, too.

> The disadvantage is that it would be disruptive to u-boot and may cause 
> some bloating and discomfort.

Grrrlp.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Lots of folks confuse bad management with destiny.   -- Frank Hubbard

[U-Boot-Users] Re: FT u-boot shim

[Tolunay Orkun]

Wolfgang Denk wrote:
> In message <D358E665-60E4-48C0-82FD-7A1C16DAF00C@kernel.crashing.org> you wrote:
>> The problem is that there are somethings that u-boot knows that needs  
>> to go into the blob (memory size, boot args, initrd info,  
>> frequencies, etc.)
> 
> Yes. Can we append auch variable data to the fixed part of the dts?
> 
>> How would we distinguish the bootm command that takes a blob versus  
>> the ones we have today?
> 
> Arg count. For example:
> 
> OLD:	bootm <kernel_addr>
>    or	bootm <kernel_addr> <ramdisk_addr>
> 
> NEW:	bootm <kernel_addr> - <dts_addr>
>    or	bootm <kernel_addr> <ramdisk_addr> <dts_addr>


How would you like to handle the case when dts is packed into 
multi-image file? Is bootm going to assume that the 3rd Image is dts?

Since dts is tightly coupled to kernel I would prefer something like:

bootm <kernel_addr>[:<dts_addr>] <ramdisk_addr>

Best regards,
Tolunay

[U-Boot-Users] Re: FT u-boot shim

[Wolfgang Denk]

[linuxppc-dev removed, this is off topic there.]

In message <44513DC1.8040608@orkun.us> you wrote:
>
> How would you like to handle the case when dts is packed into 
> multi-image file? Is bootm going to assume that the 3rd Image is dts?

With Ramdisk: kernel is 1st, ramdisk is 2nd, and dts is an optional
	3rd file.
Without ramdisk: kernel is 1st, and dts is an optional 2nd file.

The image type will be used to find out what is what.

> Since dts is tightly coupled to kernel I would prefer something like:
> 
> bootm <kernel_addr>[:<dts_addr>] <ramdisk_addr>

That would be an option, too, but I think my proposal  is  easier  to
remember, especially when thinking of the multi-file image case.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Hi there! This is just a note from me, to you, to tell you, the  per-
son  reading this note, that I can't think up any more famous quotes,
jokes, nor bizarre stories, so you may as well go home.

[U-Boot-Users] Re: FT u-boot shim

[Pantelis Antoniou]

On Friday 28 April 2006 01:12, Wolfgang Denk wrote:
> [linuxppc-dev removed, this is off topic there.]
> 
> In message <44513DC1.8040608@orkun.us> you wrote:
> >
> > How would you like to handle the case when dts is packed into 
> > multi-image file? Is bootm going to assume that the 3rd Image is dts?
> 
> With Ramdisk: kernel is 1st, ramdisk is 2nd, and dts is an optional
> 	3rd file.
> Without ramdisk: kernel is 1st, and dts is an optional 2nd file.
> 
> The image type will be used to find out what is what.
> 
> > Since dts is tightly coupled to kernel I would prefer something like:
> > 
> > bootm <kernel_addr>[:<dts_addr>] <ramdisk_addr>
> 
> That would be an option, too, but I think my proposal  is  easier  to
> remember, especially when thinking of the multi-file image case.
> 

It won't work.

The blob must contain the ethernet mac addresses for example...

> 
> Best regards,
> 
> Wolfgang Denk
> 

Regards

Pantelis

[U-Boot-Users] Re: FT u-boot shim

[Wolfgang Denk]

In message <200604280128.28841.pantelis@embeddedalley.com> you wrote:
>
> > > bootm <kernel_addr>[:<dts_addr>] <ramdisk_addr>
> > That would be an option, too, but I think my proposal  is  easier  to
> > remember, especially when thinking of the multi-file image case.
> 
> It won't work.
> 
> The blob must contain the ethernet mac addresses for example...

Ummm... I'm not sure what you are referring to.

The current topic of the discussion  (which  format  to  use  for  an
extended   "bootm"   command)  has  obviously  no  relation  to  your
statement.

And that the static blob that comes with the  kernel  image  must  be
"fixed  up"  (which  means that board specific parameters like memory
size, clock frequencies and MAC addresses must be  added/inserted/ap-
pended/whatever) has been discussed before.

So what exactly do you mean?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Virtue is a relative term.
	-- Spock, "Friday's Child", stardate 3499.1

[U-Boot-Users] Re: FT u-boot shim

[Pantelis Antoniou]

On Friday 28 April 2006 01:55, Wolfgang Denk wrote:
> In message <200604280128.28841.pantelis@embeddedalley.com> you wrote:
> >
> > > > bootm <kernel_addr>[:<dts_addr>] <ramdisk_addr>
> > > That would be an option, too, but I think my proposal  is  easier  to
> > > remember, especially when thinking of the multi-file image case.
> > 
> > It won't work.
> > 
> > The blob must contain the ethernet mac addresses for example...
> 
> Ummm... I'm not sure what you are referring to.
> 
> The current topic of the discussion  (which  format  to  use  for  an
> extended   "bootm"   command)  has  obviously  no  relation  to  your
> statement.
> 
> And that the static blob that comes with the  kernel  image  must  be
> "fixed  up"  (which  means that board specific parameters like memory
> size, clock frequencies and MAC addresses must be  added/inserted/ap-
> pended/whatever) has been discussed before.
> 
> So what exactly do you mean?
> 

You're going to carry around all the FT node building code & then patch an
external binary blob? Or are you going to poke at hardcoded positions in 
the blob?

And that with an extra binary blob that you have to carry around, at yet
another danger of screwing up. How many posts in the list we're going to
get from users that are trying to boot with a blob for their eval board,
or worse "something they found in the internet"?

IMHO all this talk about having shims is bunk. It is trivial for the running
kernel to detect that a valid BLOB was passed by the bootloader. It can then
proceed with using a preset compiled in tree for use with non OF firmware.

But the bootloader should pass & generate the tree, if the board maintainer
is willing to pay the cost. 

> Best regards,
> 
> Wolfgang Denk
> 

Regards

Pantelis

[U-Boot-Users] Re: FT u-boot shim

[Wolfgang Denk]

In message <200604281034.26439.pantelis@embeddedalley.com> you wrote:
>
> You're going to carry around all the FT node building code & then patch an
> external binary blob? Or are you going to poke at hardcoded positions in 
> the blob?

I think that binary patching of pre-defined addresses is a bad  thing
to do, as it would soon cause more trouble and incompatibilities than
we have right now. So the only remaining option is ...

> And that with an extra binary blob that you have to carry around, at yet
> another danger of screwing up. How many posts in the list we're going to
> get from users that are trying to boot with a blob for their eval board,
> or worse "something they found in the internet"?

How many messages do we get today from user who misconfigured their system?

If the kernel make rules create a single file  (a  multi-file  imagew
with  the  kernel and the dts) then I don;t see much changes from the
user's point of view.

> IMHO all this talk about having shims is bunk. It is trivial for the running
> kernel to detect that a valid BLOB was passed by the bootloader. It can then
> proceed with using a preset compiled in tree for use with non OF firmware.

So you vote for keeping duplicated versions of the dts both in U-Boot
and in Linux?

> But the bootloader should pass & generate the tree, if the board maintainer
> is willing to pay the cost. 

And what is your suggestion if he is not willing to do that?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
My play was a complete success.  The audience was a failure.

[U-Boot-Users] Re: FT u-boot shim

[Pantelis Antoniou]

On Friday 28 April 2006 10:43, Wolfgang Denk wrote:
> In message <200604281034.26439.pantelis@embeddedalley.com> you wrote:
> >
> > You're going to carry around all the FT node building code & then patch an
> > external binary blob? Or are you going to poke at hardcoded positions in 
> > the blob?
> 
> I think that binary patching of pre-defined addresses is a bad  thing
> to do, as it would soon cause more trouble and incompatibilities than
> we have right now. So the only remaining option is ...
> 
> > And that with an extra binary blob that you have to carry around, at yet
> > another danger of screwing up. How many posts in the list we're going to
> > get from users that are trying to boot with a blob for their eval board,
> > or worse "something they found in the internet"?
> 
> How many messages do we get today from user who misconfigured their system?
> 

Too many. If there's a way to screw up, users will tend to find it.
It's better to not have *any* way to screw up.

> If the kernel make rules create a single file  (a  multi-file  imagew
> with  the  kernel and the dts) then I don;t see much changes from the
> user's point of view.
> 
> > IMHO all this talk about having shims is bunk. It is trivial for the running
> > kernel to detect that a valid BLOB was passed by the bootloader. It can then
> > proceed with using a preset compiled in tree for use with non OF firmware.
> 
> So you vote for keeping duplicated versions of the dts both in U-Boot
> and in Linux?
> 

I vote for having it in u-boot only. The linux blob will be present only
for kernels with a requirement to boot on non-OF firmware.

> > But the bootloader should pass & generate the tree, if the board maintainer
> > is willing to pay the cost. 
> 
> And what is your suggestion if he is not willing to do that?
> 

Pay the cost in linux kernel size, for the Linux included blob size.
Or use an earlier version of the kernel, with all that this entails.

> Best regards,
> 
> Wolfgang Denk
> 

Regards

Pantelis

[U-Boot-Users] Re: FT u-boot shim

[???]

shameless question:
What are "FT" && "blob" ?
Are they big things? In other word, are they "MUST Understand"?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20060428/3f1229f8/attachment.htm 

[U-Boot-Users] Re: FT u-boot shim

[Wolfgang Denk]

In message <200604281103.32689.pantelis@embeddedalley.com> you wrote:
>
> It's better to not have *any* way to screw up.

Indeed. I wonder why there are so many :-(

> > So you vote for keeping duplicated versions of the dts both in U-Boot
> > and in Linux?
> 
> I vote for having it in u-boot only. The linux blob will be present only
> for kernels with a requirement to boot on non-OF firmware.

This will be some boards. SO we would have some boards where the  dts
is  in U-Boot, and some others were it is in the Linux kernel? And if
you want to use a board with different boot loaders, then...

...then we have a mess.

> Pay the cost in linux kernel size, for the Linux included blob size.

Agreed.

> Or use an earlier version of the kernel, with all that this entails.

I think cutting off support for recent kernel versions is  the  worst
thing we could do.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Quote from a recent meeting:   "We are going to continue having these
meetings everyday until I find out why no work is getting done."

[U-Boot-Users] Re: FT u-boot shim

[Tolunay Orkun]

Wolfgang Denk wrote:
>>> So you vote for keeping duplicated versions of the dts both in U-Boot
>>> and in Linux?
>>>       
>> I vote for having it in u-boot only. The linux blob will be present only
>> for kernels with a requirement to boot on non-OF firmware.
>>     
>
> This will be some boards. SO we would have some boards where the  dts
> is  in U-Boot, and some others were it is in the Linux kernel? And if
> you want to use a board with different boot loaders, then...
>
> ...then we have a mess.
>
>   

Why can't we have dts compiled into 'vmlinux' perhaps marked as __init 
(or something like it). If kernel is going to patch it anyway, why do we 
pass a static file from u-boot?

I guess OF based system can omit compiling the dts into 'vmlinux' or if 
bootlooder passes a tree compiled in dts would be ignored/freed if present.

Best regards,
Tolunay

[U-Boot-Users] Re: FT u-boot shim

[Rune Torgersen]

> -----Original Message-----
> From: Tolunay Orkun
> Why can't we have dts compiled into 'vmlinux' perhaps marked 
> as __init 
> (or something like it). If kernel is going to patch it 
> anyway, why do we 
> pass a static file from u-boot?
> 

Have it in there with space reserved for the variables bootm need to
fill in. 
That way bootm only needs to look in the dts, find the variables it
needs to update, and patch them.

[U-Boot-Users] Re: FT u-boot shim - using ramdisk?

[Roger Larsson]

On fredag 28 april 2006 00.12, Wolfgang Denk wrote:
> [linuxppc-dev removed, this is off topic there.]
>
> In message <44513DC1.8040608@orkun.us> you wrote:
> > How would you like to handle the case when dts is packed into
> > multi-image file? Is bootm going to assume that the 3rd Image is dts?
>
> With Ramdisk: kernel is 1st, ramdisk is 2nd, and dts is an optional
> 	3rd file.
> Without ramdisk: kernel is 1st, and dts is an optional 2nd file.
>
> The image type will be used to find out what is what.
>
> > Since dts is tightly coupled to kernel I would prefer something like:
> >
> > bootm <kernel_addr>[:<dts_addr>] <ramdisk_addr>
>
> That would be an option, too, but I think my proposal  is  easier  to
> remember, especially when thinking of the multi-file image case.

Hmm... ramdisk_addr (initrd)
Isn't the dts supposed to have some file structure?

Suppose we do not have a ramdisk then we could create a ramdisk
containing dts information.

If we have a ramdisk couldn't it be patched to contain dts information?

I know to little about this ramdisk will it be discarded to early?
Does it have to contain something U-Boot can not provide if used?

/RogerL

[U-Boot-Users] Re: FT u-boot shim

[Wolfgang Denk]

In message <DCEAAC0833DD314AB0B58112AD99B93B859679@ismail.innsys.innovsys.com> you wrote:
>
> Have it in there with space reserved for the variables bootm need to
> fill in. 
> That way bootm only needs to look in the dts, find the variables it
> needs to update, and patch them.

Note that some of these variables might be pretty dynamic,  like  the
number of ethernet interfaces / MAC addresses etc.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Though a program be but three lines long,
someday it will have to be maintained."
- The Tao of Programming

[U-Boot-Users] Re: FT u-boot shim - using ramdisk?

[Kumar Gala]

[snip]

> Hmm... ramdisk_addr (initrd)
> Isn't the dts supposed to have some file structure?
>
> Suppose we do not have a ramdisk then we could create a ramdisk
> containing dts information.
>
> If we have a ramdisk couldn't it be patched to contain dts  
> information?
>
> I know to little about this ramdisk will it be discarded to early?
> Does it have to contain something U-Boot can not provide if used?

This will not work.  The "dts" has to get patched up before being  
handed to the kernel.  It contains information like memory size, boot  
args, initrd locations (if you have a ramdisk), etc.

Building it into the kernel or a ramdisk doesn't work.  The fix ups  
need to occur before the kernel gets ahold of it.  So you either do  
it as a boot wrapper around the kernel which translates the bd_t, and  
other args into the dts or u-boot does it as part of the bootm command.

- kumar

[U-Boot-Users] Re: FT u-boot shim - using ramdisk?

[Wolfgang Denk]

In message <200604281836.06731.roger.larsson@norran.net> you wrote:
>
> Suppose we do not have a ramdisk then we could create a ramdisk
> containing dts information.
> 
> If we have a ramdisk couldn't it be patched to contain dts information?

"could", maybe. But this  would  break  compatibility  with  existing
systems. And I don't see any advantages of such an approach.

> I know to little about this ramdisk will it be discarded to early?

No. It may stay and serve as root file system as long as  the  system
is running (= forever).

> Does it have to contain something U-Boot can not provide if used?

Can't parse this. When the ramdisk is used  (by  the  Linux  kernel),
there is no trace of U-Boot left.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Oh dear, I think you'll find reality's on the blink again."
- Marvin The Paranoid Android

[U-Boot-Users] Re: FT u-boot shim

[Pantelis Antoniou]

On Friday 28 April 2006 22:28, Wolfgang Denk wrote:
> In message <DCEAAC0833DD314AB0B58112AD99B93B859679@ismail.innsys.innovsys.com> you wrote:
> >
> > Have it in there with space reserved for the variables bootm need to
> > fill in. 
> > That way bootm only needs to look in the dts, find the variables it
> > needs to update, and patch them.
> 
> Note that some of these variables might be pretty dynamic,  like  the
> number of ethernet interfaces / MAC addresses etc.
> 

And some of them might even be strings... Even worse...

> Best regards,
> 
> Wolfgang Denk
> 

Regards

Pantelis