[U-Boot-Users] builtin OF tree dtb gone

[U-Boot-Users] builtin OF tree dtb gone

[Joakim Tjernlund]

While trying out the latest u-boot from my board I noticed that
support for using a prebuilt OF tree compiled int u-boot is gone.
The oftree_dtb symbol is gone and I can't find a replacement.

Why was it removed and is there a replacement?

If there isn't a replacement I request that
one is added.

 Jocke

[U-Boot-Users] builtin OF tree dtb gone

[Grant Likely]

On 12/16/06, Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> While trying out the latest u-boot from my board I noticed that
> support for using a prebuilt OF tree compiled int u-boot is gone.
> The oftree_dtb symbol is gone and I can't find a replacement.
>
> Why was it removed and is there a replacement?
>
> If there isn't a replacement I request that
> one is added.

It's been replaced with support in the bootm command for passing the .dtb

New boot sequence:
1) load kernel into memory (or flash)
2) load initrd into memory (optional)
3) load .dtb into memory (optional)
4) bootm <kenreladdr> [initrdaddr] [dtbaddr]

If a dtbaddr is provided; then the dtb is passed to the kernel.  If it
is not; then old style booting is used instead.
If you don't have an initrd, but do have a .dtb; pass '-' as the initrdarrd.

ie:

tftp 200000 uImage
tftp 400000 lite5200.dtb
bootm 200000 - 400000

Cheers,
g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] builtin OF tree dtb gone

[Joakim Tjernlund]

 

> -----Original Message-----
> From: glikely at gmail.com [mailto:glikely at gmail.com] On Behalf 
> Of Grant Likely
> Sent: den 16 december 2006 16:46
> To: Joakim Tjernlund
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] builtin OF tree dtb gone
> 
> On 12/16/06, Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> > While trying out the latest u-boot from my board I noticed that
> > support for using a prebuilt OF tree compiled int u-boot is gone.
> > The oftree_dtb symbol is gone and I can't find a replacement.
> >
> > Why was it removed and is there a replacement?
> >
> > If there isn't a replacement I request that
> > one is added.
> 
> It's been replaced with support in the bootm command for 
> passing the .dtb
> 
> New boot sequence:
> 1) load kernel into memory (or flash)
> 2) load initrd into memory (optional)
> 3) load .dtb into memory (optional)
> 4) bootm <kenreladdr> [initrdaddr] [dtbaddr]
> 

hmm, been trying to pass my dtb from within u-boot(0xffc9d90) and it does not
boot. Do I really need to make the of tree avalilable in lower RAM?

[U-Boot-Users] builtin OF tree dtb gone

[Jerry Van Baren]

Joakim Tjernlund wrote:
> While trying out the latest u-boot from my board I noticed that
> support for using a prebuilt OF tree compiled int u-boot is gone.
> The oftree_dtb symbol is gone and I can't find a replacement.
> 
> Why was it removed and is there a replacement?
> 
> If there isn't a replacement I request that
> one is added.
> 
>  Jocke

I'm not the authority on this, but I believe the intent is that you 
compile the blob outside of u-boot and then you can load it into RAM via 
tftp or burn it into flash if you want it permanently on the board. 
Other than having to download and burn two things (u-boot and the dtb 
blob) rather than one, having it burn into flash separately is no 
different from compiling it into the u-boot image and is aesthetically 
much cleaner and more flexible.

The New Improved[tm] bootm command takes address of the OF blob as the 
third parameter (help bootm).

IIRC, Wolfgang was not wild about building the blob into u-boot, it 
really isn't a u-boot "thing."

I am looking into/working on a flattened device tree command that would 
allow you to manipulate a OF blob in flash or RAM like the current env 
variables.  I have a dream of integrating it with the env storage, but 
all this takes time.  (I volunteer for too much - my ego writes checks 
that my brain cannot cash. ;-)

Best regards,
gvb

[U-Boot-Users] builtin OF tree dtb gone

[Joakim Tjernlund]

> -----Original Message-----
> From: Jerry Van Baren [mailto:gerald.vanbaren at comcast.net] 
> Sent: den 16 december 2006 17:08
> To: Joakim Tjernlund
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] builtin OF tree dtb gone
> 
> Joakim Tjernlund wrote:
> > While trying out the latest u-boot from my board I noticed that
> > support for using a prebuilt OF tree compiled int u-boot is gone.
> > The oftree_dtb symbol is gone and I can't find a replacement.
> > 
> > Why was it removed and is there a replacement?
> > 
> > If there isn't a replacement I request that
> > one is added.
> > 
> >  Jocke
> 
> I'm not the authority on this, but I believe the intent is that you 
> compile the blob outside of u-boot and then you can load it 
> into RAM via 
> tftp or burn it into flash if you want it permanently on the board. 
> Other than having to download and burn two things (u-boot and the dtb 
> blob) rather than one, having it burn into flash separately is no 
> different from compiling it into the u-boot image and is 
> aesthetically 
> much cleaner and more flexible.

"Other than having to download and burn two things" is a rather big
deal to me. First it adds extra work actually get two images into the board.
Secondly, now you have to reserve a DTB flash partion so you have
somewhere to store it and that is a waste of space.
Then you have to add even more args to the boot command to tell uboot where
to find it.

To me this new OF seems like a nice feature for developing new
stuff, but once you are done and ready to ship it only complicates
things for boards that don't need this new flexibility.

 Jocke

[U-Boot-Users] builtin OF tree dtb gone

[Pantelis Antoniou]

On 16 ??? 2006, at 11:32 ??, Joakim Tjernlund wrote:

>> -----Original Message-----
>> From: Jerry Van Baren [mailto:gerald.vanbaren at comcast.net]
>> Sent: den 16 december 2006 17:08
>> To: Joakim Tjernlund
>> Cc: u-boot-users at lists.sourceforge.net
>> Subject: Re: [U-Boot-Users] builtin OF tree dtb gone
>>
>> Joakim Tjernlund wrote:
>>> While trying out the latest u-boot from my board I noticed that
>>> support for using a prebuilt OF tree compiled int u-boot is gone.
>>> The oftree_dtb symbol is gone and I can't find a replacement.
>>>
>>> Why was it removed and is there a replacement?
>>>
>>> If there isn't a replacement I request that
>>> one is added.
>>>
>>>  Jocke
>>
>> I'm not the authority on this, but I believe the intent is that you
>> compile the blob outside of u-boot and then you can load it
>> into RAM via
>> tftp or burn it into flash if you want it permanently on the board.
>> Other than having to download and burn two things (u-boot and the dtb
>> blob) rather than one, having it burn into flash separately is no
>> different from compiling it into the u-boot image and is
>> aesthetically
>> much cleaner and more flexible.
>
> "Other than having to download and burn two things" is a rather big
> deal to me. First it adds extra work actually get two images into  
> the board.
> Secondly, now you have to reserve a DTB flash partion so you have
> somewhere to store it and that is a waste of space.
> Then you have to add even more args to the boot command to tell  
> uboot where
> to find it.
>
> To me this new OF seems like a nice feature for developing new
> stuff, but once you are done and ready to ship it only complicates
> things for boards that don't need this new flexibility.
>
>  Jocke
>

I agree.

As the guy that did the original implementation, my intent was to  
keep the
DTB along with u-boot.

I don't know where you get the idea that it's more "flexible" or  
"cleaner" to
have it on a different partition. That blob will never change after  
the board
is debugged, so you've only introduced an extra complicated step to  
boot a kernel.

When I have enough free time (yeah right) I'll work on getting even  
the u-boot
getting it's parameters from the blob - moving stuff away from the  
config.h file
if possible.

Regards

Pantelis


>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] builtin OF tree dtb gone

[Dan Malek]

On Dec 16, 2006, at 12:18 PM, Pantelis Antoniou wrote:

> As the guy that did the original implementation, my intent was to   
> keep theDTB along with u-boot.
> I don't know where you get the idea that it's more "flexible" or   
> "cleaner" tohave it on a different partition.

The problem is the dtb is still, and probably always
be changing.  My concern is even if you put the dtb
into u-boot, the next version of kernel will probably
not boot properly because the information needed
will be different.  So, to boot new kernels you need
to then update u-boot, which is something no one
is going to risk in a product.

All of these ideas are great when you are sitting
in a lab with an evaluation board, you can update
u-boot at will, or constantly change other items
in the flash.  In a real product, no one is going to
risk a software update that could turn millions of
working systems into doorstops.  Field upgrades
of existing Linux systems are already quite complicated,
and the last thing we need are even more variables
to cause problems or to track for recovery procedures.

These changes that add size and maintenance
complexity to Linux aren't popular for embedded
products.  People are starting to look again at
other, even proprietary solutions, due to overall
cost and lifetime product risk.   If we keep this up,
we are going to have the best over-engineered
and unused software around.

Thanks.

	-- Dan

[U-Boot-Users] builtin OF tree dtb gone

[Joakim Tjernlund]

> 
> On Dec 16, 2006, at 12:18 PM, Pantelis Antoniou wrote:
> 
> > As the guy that did the original implementation, my intent was to   
> > keep theDTB along with u-boot.
> > I don't know where you get the idea that it's more "flexible" or   
> > "cleaner" tohave it on a different partition.
> 
> The problem is the dtb is still, and probably always
> be changing.  My concern is even if you put the dtb
> into u-boot, the next version of kernel will probably
> not boot properly because the information needed
> will be different.  So, to boot new kernels you need
> to then update u-boot, which is something no one
> is going to risk in a product.

We do update u-boot in field, no mishaps yet since 2001.
Probably due to a very controlled update procedure.

> 
> All of these ideas are great when you are sitting
> in a lab with an evaluation board, you can update
> u-boot at will, or constantly change other items
> in the flash.  In a real product, no one is going to
> risk a software update that could turn millions of
> working systems into doorstops.  Field upgrades
> of existing Linux systems are already quite complicated,
> and the last thing we need are even more variables
> to cause problems or to track for recovery procedures.
> 
> These changes that add size and maintenance
> complexity to Linux aren't popular for embedded
> products.  People are starting to look again at
> other, even proprietary solutions, due to overall
> cost and lifetime product risk.   If we keep this up,
> we are going to have the best over-engineered
> and unused software around.

I don't get you point w.r.t subject at hand, do you or don't you
support a OF tree compiled into u-boot?

 Jocke

[U-Boot-Users] builtin OF tree dtb gone

[Dan Malek]

On Dec 16, 2006, at 2:39 PM, Joakim Tjernlund wrote:

> We do update u-boot in field, no mishaps yet since 2001.
> Probably due to a very controlled update procedure.

You should be playing the lottery, then :-)
How do you control a power failure (even done
by the user) between erasing and updating
the flash, as one example of bad things that
can happen during this process?

> I don't get you point w.r.t subject at hand, do you or don't you
> support a OF tree compiled into u-boot?

I don't like the OF for embedded products at all,
but there is no stopping that train.  Done properly,
it should be as Pantelis said.... once as part of
the u-boot board port.  Of course, when we started
discussing this and provided the first implementation,
its purpose was to pass some environment information
already part of u-boot in a more general way to the
kernel.  It has since turned into a completely
different monster.


	-- Dan

[U-Boot-Users] builtin OF tree dtb gone

[Wolfgang Denk]

In message <005b01c7212f$bebff860$1e67a8c0@Jocke> you wrote:
>
> "Other than having to download and burn two things" is a rather big
> deal to me. First it adds extra work actually get two images into the board.

A multi-file image is supposed to work, too. I never tested this,
though.

> Secondly, now you have to reserve a DTB flash partion so you have
> somewhere to store it and that is a waste of space.
> Then you have to add even more args to the boot command to tell uboot where
> to find it.

All this can be dealt with by using a multi-file image.

> To me this new OF seems like a nice feature for developing new
> stuff, but once you are done and ready to ship it only complicates
> things for boards that don't need this new flexibility.

I disagree here.

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
If some day we are defeated, well, war has  its  fortunes,  good  and
bad.
	-- Commander Kor, "Errand of Mercy", stardate 3201.7

[U-Boot-Users] builtin OF tree dtb gone

[Joakim Tjernlund]

> -----Original Message-----
> From: u-boot-users-bounces at lists.sourceforge.net 
> [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf 
> Of Wolfgang Denk
> Sent: den 16 december 2006 20:04
> To: Joakim Tjernlund
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] builtin OF tree dtb gone
> 
> In message <005b01c7212f$bebff860$1e67a8c0@Jocke> you wrote:
> >
> > "Other than having to download and burn two things" is a rather big
> > deal to me. First it adds extra work actually get two 
> images into the board.
> 
> A multi-file image is supposed to work, too. I never tested this,
> though.

Don't like this idea, its not a runtime/kernel load feature, IMHO.
What devices that is supported should be provided by firmware.

> 
> > Secondly, now you have to reserve a DTB flash partion so you have
> > somewhere to store it and that is a waste of space.
> > Then you have to add even more args to the boot command to 
> tell uboot where
> > to find it.
> 
> All this can be dealt with by using a multi-file image.

Can you add/modify OF items in a multi-file image?

> 
> > To me this new OF seems like a nice feature for developing new
> > stuff, but once you are done and ready to ship it only complicates
> > things for boards that don't need this new flexibility.
> 
> I disagree here.

Clearly, but you don't say why. You are saying that a multi-file image
might work but that won't work in a system where you need different OF trees.
I am supposed to supply X multi-file images, one for each board where only the
DTB differ?

   Regards 
             Jocke
> 
> Best regards,
> 
> Wolfgang Denk
> 

[U-Boot-Users] builtin OF tree dtb gone

[Wolfgang Denk]

In message <007701c7214c$a1c6f430$1e67a8c0@Jocke> you wrote:
>
> Don't like this idea, its not a runtime/kernel load feature, IMHO.
> What devices that is supported should be provided by firmware.

Then store the DTB in flash, probably as part of  your  production  /
update mechanism. Nobody prevents you from doing this.

> > I disagree here.
> 
> Clearly, but you don't say why. You are saying that a multi-file image
> might work but that won't work in a system where you need different OF trees.

Of course not.

> I am supposed to supply X multi-file images, one for each board where only the
> DTB differ?

No.

For a complete system you need U-Boot  plus  DTB  plus  Linux  kernel
[plus  root file system ...]. You may find, that for different boards
any of these components may be different or the same,  so  no  matter
which  you  bundle  together it will work fine in some setups, and be
unconvenient in others. The best flexibility is when  all  three  are
separate,  so  that's  the  default option we provide. If you want to
combine U-Boot plus DTB, fine, you define your [flash] memory map. If
you want to combine Linux and DTB, ok, use a multifile 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
Never worry about theory as long as  the  machinery  does  what  it's
supposed to do.                                      - R. A. Heinlein

[U-Boot-Users] builtin OF tree dtb gone

[Joakim Tjernlund]

> -----Original Message-----
> From: wd at denx.de [mailto:wd at denx.de] 
> Sent: den 17 december 2006 01:38
> To: Joakim Tjernlund
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] builtin OF tree dtb gone 
> 
> In message <007701c7214c$a1c6f430$1e67a8c0@Jocke> you wrote:
> >
> > Don't like this idea, its not a runtime/kernel load feature, IMHO.
> > What devices that is supported should be provided by firmware.
> 
> Then store the DTB in flash, probably as part of  your  production  /
> update mechanism. Nobody prevents you from doing this.

Well, newer versions of U-boot prevents me from embedding the OF tree
inside the u-boot image.

> 
> > > I disagree here.
> > 
> > Clearly, but you don't say why. You are saying that a 
> multi-file image
> > might work but that won't work in a system where you need 
> different OF trees.
> 
> Of course not.
> 
> > I am supposed to supply X multi-file images, one for each 
> board where only the
> > DTB differ?
> 
> No.
> 
> For a complete system you need U-Boot  plus  DTB  plus  Linux  kernel
> [plus  root file system ...]. You may find, that for different boards
> any of these components may be different or the same,  so  no  matter
> which  you  bundle  together it will work fine in some setups, and be
> unconvenient in others. The best flexibility is when  all  three  are
> separate,  so  that's  the  default option we provide. If you want to
> combine U-Boot plus DTB, fine, you define your [flash] memory map. If
> you want to combine Linux and DTB, ok, use a multifile image.

"in some setups", that's the point. Our setup works fine with
an embedded OF tree in u-boot. If I am to adapt to this new
method of supplying the OF tree, not only will I have to repartion
the flash to fit the tree in there, I also need to make sure
that some 15-20 people learns this new concept for no real gain.

It is nothing wrong with having the ability provide a OF tree
at boot time, but forcing everyone to do so is. The
most flexible way is to have both.

 Regards 
          Jocke
> 
> 
> Best regards,
> 
> Wolfgang Denk
> 

[U-Boot-Users] builtin OF tree dtb gone

[Grant Likely]

On 12/17/06, Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
>
> "in some setups", that's the point. Our setup works fine with
> an embedded OF tree in u-boot. If I am to adapt to this new
> method of supplying the OF tree, not only will I have to repartion
> the flash to fit the tree in there, I also need to make sure
> that some 15-20 people learns this new concept for no real gain.
>
> It is nothing wrong with having the ability provide a OF tree
> at boot time, but forcing everyone to do so is. The
> most flexible way is to have both.

This shouldn't be too big a deal.  Add the code back for linking the
.dtb into the image.  Look in common/boot.c and add a check for if the
third bootm parameter is '-'.  If it is, then use the builtin section
for the .dtb address.  Then you can either use the builtin version, or
pass a new one.  We're not talking a lot of code here.

Alternately; your u-boot image does not totally fill the sectors you
have allocated for it.  Since your plan is to update u-boot and the
.dtb at the same time; modify your u-boot build procedure (I think by
using objcopy) to link your .dtb to a known address within the unused
part of the u-boot sectors (so that u-boot+dtb are in a single file)
and make sure the update procedure also changes the default bootm
command to include the known dtb address.

There are lots of options here; and the default code in u-boot is not
forcing you to do it in a particular way.

g.


-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] builtin OF tree dtb gone

[Joakim Tjernlund]

> -----Original Message-----
> From: glikely at gmail.com [mailto:glikely at gmail.com] On Behalf 
> Of Grant Likely
> Sent: den 17 december 2006 16:11
> To: Joakim Tjernlund
> Cc: wd at denx.de; u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] builtin OF tree dtb gone
> 
> On 12/17/06, Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> >
> > "in some setups", that's the point. Our setup works fine with
> > an embedded OF tree in u-boot. If I am to adapt to this new
> > method of supplying the OF tree, not only will I have to repartion
> > the flash to fit the tree in there, I also need to make sure
> > that some 15-20 people learns this new concept for no real gain.
> >
> > It is nothing wrong with having the ability provide a OF tree
> > at boot time, but forcing everyone to do so is. The
> > most flexible way is to have both.
> 
> This shouldn't be too big a deal.  Add the code back for linking the
> .dtb into the image.  Look in common/boot.c and add a check for if the
> third bootm parameter is '-'.  If it is, then use the builtin section
> for the .dtb address.  Then you can either use the builtin version, or
> pass a new one.  We're not talking a lot of code here.

I am looking at this now. I have a DTB linked into uboot at address
0xffc9d90(near end of my 256MB RAM when u-boot has relocated itself).
Passing this address to bootm $loadaddr - 0xffc9d90 makes the
kernel SEGV because the kernel can't access data that high up in RAM
early in the boot process.
Seems to that the u-boot should copy the DTB to an address that 
the kernel can access before passing control the kernel. How
else is one supposed to have a DTB in flash that is even higher up
in the address space?

Maybe I have misunderstood something, but I can't se what presently.

> 
> Alternately; your u-boot image does not totally fill the sectors you
> have allocated for it.  Since your plan is to update u-boot and the
> .dtb at the same time; modify your u-boot build procedure (I think by
> using objcopy) to link your .dtb to a known address within the unused
> part of the u-boot sectors (so that u-boot+dtb are in a single file)
> and make sure the update procedure also changes the default bootm
> command to include the known dtb address.

This option does not really suit me, but thanks for the suggestion.

 Jocke

[U-Boot-Users] builtin OF tree dtb gone

[Joakim Tjernlund]

> -----Original Message-----
> From: u-boot-users-bounces at lists.sourceforge.net 
> [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf 
> Of Joakim Tjernlund
> Sent: den 17 december 2006 16:40
> To: 'Grant Likely'
> Cc: u-boot-users at lists.sourceforge.net; wd at denx.de
> Subject: Re: [U-Boot-Users] builtin OF tree dtb gone
> 
> > -----Original Message-----
> > From: glikely at gmail.com [mailto:glikely at gmail.com] On Behalf 
> > Of Grant Likely
> > Sent: den 17 december 2006 16:11
> > To: Joakim Tjernlund
> > Cc: wd at denx.de; u-boot-users at lists.sourceforge.net
> > Subject: Re: [U-Boot-Users] builtin OF tree dtb gone
> > 
> > On 12/17/06, Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> > >
> > > "in some setups", that's the point. Our setup works fine with
> > > an embedded OF tree in u-boot. If I am to adapt to this new
> > > method of supplying the OF tree, not only will I have to repartion
> > > the flash to fit the tree in there, I also need to make sure
> > > that some 15-20 people learns this new concept for no real gain.
> > >
> > > It is nothing wrong with having the ability provide a OF tree
> > > at boot time, but forcing everyone to do so is. The
> > > most flexible way is to have both.
> > 
> > This shouldn't be too big a deal.  Add the code back for linking the
> > .dtb into the image.  Look in common/boot.c and add a check 
> for if the
> > third bootm parameter is '-'.  If it is, then use the 
> builtin section
> > for the .dtb address.  Then you can either use the builtin 
> version, or
> > pass a new one.  We're not talking a lot of code here.
> 
> I am looking at this now. I have a DTB linked into uboot at address
> 0xffc9d90(near end of my 256MB RAM when u-boot has relocated itself).
> Passing this address to bootm $loadaddr - 0xffc9d90 makes the
> kernel SEGV because the kernel can't access data that high up in RAM
> early in the boot process.
> Seems to that the u-boot should copy the DTB to an address that 
> the kernel can access before passing control the kernel. How
> else is one supposed to have a DTB in flash that is even higher up
> in the address space?
> 
> Maybe I have misunderstood something, but I can't se what presently.

Ahh, found it. It is the addr2info check that relocates the OF tree.
addr2info checks if an address is in flash, if so it will relocate it
to lower RAM. But since I got my OF tree in high RAM that won't
happen.
The same would happen if one loaded a OF tree via tftp and placed
it high up in RAM.
I think that the addr2info check should be replaced with something
else that will move the tree to a low enough address if needed.

What would be a good test?

A simple way to support an embedded tree would be:
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 7aae8a6..7b2d221 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -531,8 +531,12 @@ do_bootm_linux (cmd_tbl_t *cmdtp, int fl
        image_header_t *hdr = &header;
 #ifdef CONFIG_OF_FLAT_TREE
        char    *of_flat_tree = NULL;
+#ifdef CFG_EMBEDDED_FLAT_TREE
+       ulong   of_data = (ulong)oftree_dtb;
+#else
        ulong   of_data = 0;
 #endif
+#endif

 Jocke

[U-Boot-Users] builtin OF tree dtb gone

[Wolfgang Denk]

In message <009301c721f5$69b25ef0$1e67a8c0@Jocke> you wrote:
>
> Ahh, found it. It is the addr2info check that relocates the OF tree.
> addr2info checks if an address is in flash, if so it will relocate it
> to lower RAM. But since I got my OF tree in high RAM that won't
> happen.
> The same would happen if one loaded a OF tree via tftp and placed
> it high up in RAM.
> I think that the addr2info check should be replaced with something
> else that will move the tree to a low enough address if needed.
> 
> What would be a good test?

Probably the "initrd_high" code should be generalized here.

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 came home the other night and tried to open the door  with  my  car
keys...and  the  building started up. So I took it out for a drive. A
cop pulled me over for speeding. He asked me where I  live...  "Right
here".                                                - Steven Wright

[U-Boot-Users] builtin OF tree dtb gone

[Joakim Tjernlund]

On Sun, 2006-12-17 at 18:13 +0100, Wolfgang Denk wrote:
> In message <009301c721f5$69b25ef0$1e67a8c0@Jocke> you wrote:
> >
> > Ahh, found it. It is the addr2info check that relocates the OF tree.
> > addr2info checks if an address is in flash, if so it will relocate it
> > to lower RAM. But since I got my OF tree in high RAM that won't
> > happen.
> > The same would happen if one loaded a OF tree via tftp and placed
> > it high up in RAM.
> > I think that the addr2info check should be replaced with something
> > else that will move the tree to a low enough address if needed.
> > 
> > What would be a good test?
> 
> Probably the "initrd_high" code should be generalized here.
> 
> Best regards,
> 
> Wolfgang Denk
> 
Wolfgang,
how about this patch:

Make it possible to use a OF tree embedded in u-boot.
Also make sure OF tree is below 8MB.

Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>

diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 7aae8a6..78f8d15 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -531,8 +531,12 @@ do_bootm_linux (cmd_tbl_t *cmdtp, int fl
 	image_header_t *hdr = &header;
 #ifdef CONFIG_OF_FLAT_TREE
 	char	*of_flat_tree = NULL;
+#ifdef CFG_EMBEDDED_FLAT_TREE
+	ulong	of_data = (ulong)oftree_dtb;
+#else
 	ulong	of_data = 0;
 #endif
+#endif
 
 	if ((s = getenv ("initrd_high")) != NULL) {
 		/* a value of "no" or a similar string will act like 0,
@@ -745,10 +749,8 @@ do_bootm_linux (cmd_tbl_t *cmdtp, int fl
 		hdr = (image_header_t *)of_flat_tree;
 
 		if  (*(ulong *)of_flat_tree == OF_DT_HEADER) {
-#ifndef CFG_NO_FLASH
-			if (addr2info((ulong)of_flat_tree) != NULL)
+		   if (of_flat_tree >= (char *) (8*1024*1024))
 				of_data = (ulong)of_flat_tree;
-#endif
 		} else if (ntohl(hdr->ih_magic) == IH_MAGIC) {
 			printf("## Flat Device Tree Image at %08lX\n", hdr);
 			print_image_hdr(hdr);
diff --git a/common/ft_build.c b/common/ft_build.c

[U-Boot-Users] builtin OF tree dtb gone

[Wolfgang Denk]

Dear Joakim,

in message <1166378632.30422.98.camel@gentoo-jocke.transmode.se> you wrote:
>
> how about this patch:

Sorry, but there are two things I don't like:

> Make it possible to use a OF tree embedded in u-boot.
> Also make sure OF tree is below 8MB.
> 
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> 
> diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
> index 7aae8a6..78f8d15 100644
> --- a/common/cmd_bootm.c
> +++ b/common/cmd_bootm.c
> @@ -531,8 +531,12 @@ do_bootm_linux (cmd_tbl_t *cmdtp, int fl
>  	image_header_t *hdr = &header;
>  #ifdef CONFIG_OF_FLAT_TREE
>  	char	*of_flat_tree = NULL;
> +#ifdef CFG_EMBEDDED_FLAT_TREE

I don't want to have another #ifdef here. It should be possible to do
this (for example in the linker script) without this.

> -#ifndef CFG_NO_FLASH
> -			if (addr2info((ulong)of_flat_tree) != NULL)
> +		   if (of_flat_tree >= (char *) (8*1024*1024))

And  I  definitely  reject  such  hard-wired  and  uncommented  magic
constants which are wrong on most of the systems.

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
In general, they do what you want, unless you want consistency.
                                    - Larry Wall in the perl man page

[U-Boot-Users] builtin OF tree dtb gone

[Joakim Tjernlund]

On Mon, 2006-12-18 at 00:56 +0100, Wolfgang Denk wrote:
> Dear Joakim,
> 
> in message <1166378632.30422.98.camel@gentoo-jocke.transmode.se> you wrote:
> >
> > how about this patch:
> 
> Sorry, but there are two things I don't like:
> 
> > Make it possible to use a OF tree embedded in u-boot.
> > Also make sure OF tree is below 8MB.
> > 
> > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > 
> > diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
> > index 7aae8a6..78f8d15 100644
> > --- a/common/cmd_bootm.c
> > +++ b/common/cmd_bootm.c
> > @@ -531,8 +531,12 @@ do_bootm_linux (cmd_tbl_t *cmdtp, int fl
> >  	image_header_t *hdr = &header;
> >  #ifdef CONFIG_OF_FLAT_TREE
> >  	char	*of_flat_tree = NULL;
> > +#ifdef CFG_EMBEDDED_FLAT_TREE
> 
> I don't want to have another #ifdef here. It should be possible to do
> this (for example in the linker script) without this.

Can't figure out how some linker magic would solve this. Somehow
this function needs a handle to where a default tree is stored.
Moved around the code a bit, hope you like this better.

> 
> > -#ifndef CFG_NO_FLASH
> > -			if (addr2info((ulong)of_flat_tree) != NULL)
> > +		   if (of_flat_tree >= (char *) (8*1024*1024))
> 
> And  I  definitely  reject  such  hard-wired  and  uncommented  magic
> constants which are wrong on most of the systems.

Right, redid this part. If you don't like this either, we can skip
this part for now.

  Regards
          Jocke

diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 7aae8a6..b3654ee 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -510,6 +510,23 @@ fixup_silent_linux ()
 #endif /* CONFIG_SILENT_CONSOLE */
 
 #ifdef CONFIG_PPC
+
+/* Define oftree_dtb to point to you own built in
+ * OF tree if you need one.
+ */
+#ifndef oftree_dtb
+ #define oftree_dtb 0
+#endif
+/* Early in the linux boot process most ppc systems
+ * can only access the first few MB of RAM. If the
+ * OF tree is located higher up in memory than
+ * LINUX_INITIAL_MEMORY, it will be copied to a
+ * lower address where the kernel can access it.
+ */
+#ifndef LINUX_INITIAL_MEMORY
+ #define LINUX_INITIAL_MEMORY (8*1024*1024) /* 8MB */
+#endif
+
 static void  __attribute__((noinline))
 do_bootm_linux (cmd_tbl_t *cmdtp, int flag,
 		int	argc, char *argv[],
@@ -531,7 +548,7 @@ do_bootm_linux (cmd_tbl_t *cmdtp, int fl
 	image_header_t *hdr = &header;
 #ifdef CONFIG_OF_FLAT_TREE
 	char	*of_flat_tree = NULL;
-	ulong	of_data = 0;
+	ulong	of_data = (ulong)oftree_dtb;
 #endif
 
 	if ((s = getenv ("initrd_high")) != NULL) {
@@ -745,10 +762,8 @@ do_bootm_linux (cmd_tbl_t *cmdtp, int fl
 		hdr = (image_header_t *)of_flat_tree;
 
 		if  (*(ulong *)of_flat_tree == OF_DT_HEADER) {
-#ifndef CFG_NO_FLASH
-			if (addr2info((ulong)of_flat_tree) != NULL)
+			if (of_flat_tree >= (char *) LINUX_INITIAL_MEMORY)
 				of_data = (ulong)of_flat_tree;
-#endif
 		} else if (ntohl(hdr->ih_magic) == IH_MAGIC) {
 			printf("## Flat Device Tree Image at %08lX\n", hdr);
 			print_image_hdr(hdr);
diff --git a/common/ft_build.c b/common/ft_build.c

[U-Boot-Users] builtin OF tree dtb gone

[Joakim Tjernlund]

Ping.

Didn't you like this either or no time to look at it?

 Jocke

> -----Original Message-----
> From: u-boot-users-bounces at lists.sourceforge.net 
> [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf 
> Of Joakim Tjernlund
> Sent: den 18 december 2006 15:39
> To: Wolfgang Denk
> Cc: 'Grant Likely'; u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] builtin OF tree dtb gone
> 
> On Mon, 2006-12-18 at 00:56 +0100, Wolfgang Denk wrote:
> > Dear Joakim,
> > 
> > in message 
> <1166378632.30422.98.camel@gentoo-jocke.transmode.se> you wrote:
> > >
> > > how about this patch:
> > 
> > Sorry, but there are two things I don't like:
> > 
> > > Make it possible to use a OF tree embedded in u-boot.
> > > Also make sure OF tree is below 8MB.
> > > 
> > > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > > 
> > > diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
> > > index 7aae8a6..78f8d15 100644
> > > --- a/common/cmd_bootm.c
> > > +++ b/common/cmd_bootm.c
> > > @@ -531,8 +531,12 @@ do_bootm_linux (cmd_tbl_t *cmdtp, int fl
> > >  	image_header_t *hdr = &header;
> > >  #ifdef CONFIG_OF_FLAT_TREE
> > >  	char	*of_flat_tree = NULL;
> > > +#ifdef CFG_EMBEDDED_FLAT_TREE
> > 
> > I don't want to have another #ifdef here. It should be 
> possible to do
> > this (for example in the linker script) without this.
> 
> Can't figure out how some linker magic would solve this. Somehow
> this function needs a handle to where a default tree is stored.
> Moved around the code a bit, hope you like this better.
> 
> > 
> > > -#ifndef CFG_NO_FLASH
> > > -			if (addr2info((ulong)of_flat_tree) != NULL)
> > > +		   if (of_flat_tree >= (char *) (8*1024*1024))
> > 
> > And  I  definitely  reject  such  hard-wired  and  
> uncommented  magic
> > constants which are wrong on most of the systems.
> 
> Right, redid this part. If you don't like this either, we can skip
> this part for now.
> 
>   Regards
>           Jocke
> 
> diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
> index 7aae8a6..b3654ee 100644
> --- a/common/cmd_bootm.c
> +++ b/common/cmd_bootm.c
> @@ -510,6 +510,23 @@ fixup_silent_linux ()
>  #endif /* CONFIG_SILENT_CONSOLE */
>  
>  #ifdef CONFIG_PPC
> +
> +/* Define oftree_dtb to point to you own built in
> + * OF tree if you need one.
> + */
> +#ifndef oftree_dtb
> + #define oftree_dtb 0
> +#endif
> +/* Early in the linux boot process most ppc systems
> + * can only access the first few MB of RAM. If the
> + * OF tree is located higher up in memory than
> + * LINUX_INITIAL_MEMORY, it will be copied to a
> + * lower address where the kernel can access it.
> + */
> +#ifndef LINUX_INITIAL_MEMORY
> + #define LINUX_INITIAL_MEMORY (8*1024*1024) /* 8MB */
> +#endif
> +
>  static void  __attribute__((noinline))
>  do_bootm_linux (cmd_tbl_t *cmdtp, int flag,
>  		int	argc, char *argv[],
> @@ -531,7 +548,7 @@ do_bootm_linux (cmd_tbl_t *cmdtp, int fl
>  	image_header_t *hdr = &header;
>  #ifdef CONFIG_OF_FLAT_TREE
>  	char	*of_flat_tree = NULL;
> -	ulong	of_data = 0;
> +	ulong	of_data = (ulong)oftree_dtb;
>  #endif
>  
>  	if ((s = getenv ("initrd_high")) != NULL) {
> @@ -745,10 +762,8 @@ do_bootm_linux (cmd_tbl_t *cmdtp, int fl
>  		hdr = (image_header_t *)of_flat_tree;
>  
>  		if  (*(ulong *)of_flat_tree == OF_DT_HEADER) {
> -#ifndef CFG_NO_FLASH
> -			if (addr2info((ulong)of_flat_tree) != NULL)
> +			if (of_flat_tree >= (char *) 
> LINUX_INITIAL_MEMORY)
>  				of_data = (ulong)of_flat_tree;
> -#endif
>  		} else if (ntohl(hdr->ih_magic) == IH_MAGIC) {
>  			printf("## Flat Device Tree Image at 
> %08lX\n", hdr);
>  			print_image_hdr(hdr);

[U-Boot-Users] builtin OF tree dtb gone

[Pantelis Antoniou]

On 17 ??? 2006, at 10:40 ??, Joakim Tjernlund wrote:

>> -----Original Message-----
>> From: glikely at gmail.com [mailto:glikely at gmail.com] On Behalf
>> Of Grant Likely
>> Sent: den 17 december 2006 16:11
>> To: Joakim Tjernlund
>> Cc: wd at denx.de; u-boot-users at lists.sourceforge.net
>> Subject: Re: [U-Boot-Users] builtin OF tree dtb gone
>>
>> On 12/17/06, Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
>>>
>>> "in some setups", that's the point. Our setup works fine with
>>> an embedded OF tree in u-boot. If I am to adapt to this new
>>> method of supplying the OF tree, not only will I have to repartion
>>> the flash to fit the tree in there, I also need to make sure
>>> that some 15-20 people learns this new concept for no real gain.
>>>
>>> It is nothing wrong with having the ability provide a OF tree
>>> at boot time, but forcing everyone to do so is. The
>>> most flexible way is to have both.
>>
>> This shouldn't be too big a deal.  Add the code back for linking the
>> .dtb into the image.  Look in common/boot.c and add a check for if  
>> the
>> third bootm parameter is '-'.  If it is, then use the builtin section
>> for the .dtb address.  Then you can either use the builtin  
>> version, or
>> pass a new one.  We're not talking a lot of code here.
>
> I am looking at this now. I have a DTB linked into uboot at address
> 0xffc9d90(near end of my 256MB RAM when u-boot has relocated itself).
> Passing this address to bootm $loadaddr - 0xffc9d90 makes the
> kernel SEGV because the kernel can't access data that high up in RAM
> early in the boot process.
> Seems to that the u-boot should copy the DTB to an address that
> the kernel can access before passing control the kernel. How
> else is one supposed to have a DTB in flash that is even higher up
> in the address space?
>
> Maybe I have misunderstood something, but I can't se what presently.
>

Yes, the DTB must be placed low-enough in the boot memory to be  
accessed.
I'm pretty sure that the original implementation I did made this work.
In fact I'm surprised that the flash pointing thingy even works for  
anyone.

Most of powerpc kernels need the initial OF tree to be under the 8MB.

The only way to guarantee that is to copy the OF tree to the stack
of the kernel we are about to boot.

I really don't understand the point of this discussion...
Let's see if I got this right.

OF's initial implementation worked well enough for it's users (Jocke  
& others).

There was a change to the OF implementation that makes those users  
unhappy.

There is no real technical reason to not accommodate those users.

I feel Jocke's complaints are reasonable. There should be a way to keep
him happy, since the old stuff used to work just fine; in fact I'd argue
it worked better.

That's my opinion anyway.

Regards

Pantelis

>>
>> Alternately; your u-boot image does not totally fill the sectors you
>> have allocated for it.  Since your plan is to update u-boot and the
>> .dtb at the same time; modify your u-boot build procedure (I think by
>> using objcopy) to link your .dtb to a known address within the unused
>> part of the u-boot sectors (so that u-boot+dtb are in a single file)
>> and make sure the update procedure also changes the default bootm
>> command to include the known dtb address.
>
> This option does not really suit me, but thanks for the suggestion.
>
>  Jocke
>
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] builtin OF tree dtb gone

[Timur Tabi]

Pantelis Antoniou wrote:
> On 17 ??? 2006, at 10:40 ??, Joakim Tjernlund wrote:
> 
>>> -----Original Message-----
>>> From: glikely at gmail.com [mailto:glikely at gmail.com] On Behalf
>>> Of Grant Likely
>>> Sent: den 17 december 2006 16:11
>>> To: Joakim Tjernlund
>>> Cc: wd at denx.de; u-boot-users at lists.sourceforge.net
>>> Subject: Re: [U-Boot-Users] builtin OF tree dtb gone
>>>
>>> On 12/17/06, Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
>>>> "in some setups", that's the point. Our setup works fine with
>>>> an embedded OF tree in u-boot. If I am to adapt to this new
>>>> method of supplying the OF tree, not only will I have to repartion
>>>> the flash to fit the tree in there, I also need to make sure
>>>> that some 15-20 people learns this new concept for no real gain.
>>>>
>>>> It is nothing wrong with having the ability provide a OF tree
>>>> at boot time, but forcing everyone to do so is. The
>>>> most flexible way is to have both.
>>> This shouldn't be too big a deal.  Add the code back for linking the
>>> .dtb into the image.  Look in common/boot.c and add a check for if  
>>> the
>>> third bootm parameter is '-'.  If it is, then use the builtin section
>>> for the .dtb address.  Then you can either use the builtin  
>>> version, or
>>> pass a new one.  We're not talking a lot of code here.
>> I am looking at this now. I have a DTB linked into uboot at address
>> 0xffc9d90(near end of my 256MB RAM when u-boot has relocated itself).
>> Passing this address to bootm $loadaddr - 0xffc9d90 makes the
>> kernel SEGV because the kernel can't access data that high up in RAM
>> early in the boot process.
>> Seems to that the u-boot should copy the DTB to an address that
>> the kernel can access before passing control the kernel. How
>> else is one supposed to have a DTB in flash that is even higher up
>> in the address space?
>>
>> Maybe I have misunderstood something, but I can't se what presently.
>>
> 
> Yes, the DTB must be placed low-enough in the boot memory to be  
> accessed.
> I'm pretty sure that the original implementation I did made this work.
> In fact I'm surprised that the flash pointing thingy even works for  
> anyone.
> 
> Most of powerpc kernels need the initial OF tree to be under the 8MB.

Really?  The current code puts the OF tree right before the initrd, which is 
located at the top of RAM:

    Booting using flat device tree at 0xfe250000
    Loading Ramdisk to 0fda2000, end 0ff752ef ... OK
    Loading Device Tree to 0fd9e000, end 0fd9f48a ...

Address 0fd9e000 is passed to the kernel.

Now granted, I have another bug where function ft_setup() doesn't work at all, 
but I don't think that's related.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] builtin OF tree dtb gone

[Wolfgang Denk]

In message <45B52696.4070105@freescale.com> you wrote:
>
> Really?  The current code puts the OF tree right before the initrd, which is 
> located at the top of RAM:

Only if you allow it...

If this doesn't fit for some reason or another, please feel free to
change the behaviour. See the README about "initrd_high".

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
What is wanted is not the will to believe,  but the will to find out,
which is the exact opposite.
		        -- Bertrand Russell, "Skeptical Essays", 1928

[U-Boot-Users] builtin OF tree dtb gone

[Wolfgang Denk]

In message <008901c721e6$ece8c160$1e67a8c0@Jocke> you wrote:
> > 
> > Then store the DTB in flash, probably as part of  your  production  /
> > update mechanism. Nobody prevents you from doing this.
> 
> Well, newer versions of U-boot prevents me from embedding the OF tree
> inside the u-boot image.

I wrote "in flash" - this does not mean that it has  to  be  embedded
within  the  U-Boot  image.  It  can  be simply attached to it's end,
probably with some padding to allow for sector alignment.

> "in some setups", that's the point. Our setup works fine with
> an embedded OF tree in u-boot. If I am to adapt to this new
> method of supplying the OF tree, not only will I have to repartion
> the flash to fit the tree in there, I also need to make sure

It should make very little difference (probably not  visible  to  the
rest  of the system), if the tree is embedded within the U-Boot image
or attached to it's end (or if it's preceeding the image).

> that some 15-20 people learns this new concept for no real gain.

You complain abouyt a problem where there is none.

> It is nothing wrong with having the ability provide a OF tree
> at boot time, but forcing everyone to do so is. The
> most flexible way is to have both.

You are not forced into anything here.

If you like, you can  still  use  your  own  boared-specific  lkinker
script  and  "embed"  he tree to any location in your image; you just
have to find a good way to remember the start address. Actually  that
should  not  be  too  difficult,  either.  It  should be prossible to
automatically set an environment variable to the right address.

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
Everyting looks interesting until you do it. Then you find it's  just
another job.                     - Terry Pratchett, _Moving Pictures_