[U-Boot-Users] builtin OF tree dtb gone
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
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.
-----Original Message----- From: glikely@gmail.com [mailto:glikely@gmail.com] On Behalf Of Grant Likely Sent: den 16 december 2006 16:46 To: Joakim Tjernlund Cc: u-boot-users@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:
- load kernel into memory (or flash)
- load initrd into memory (optional)
- load .dtb into memory (optional)
- 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?
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
-----Original Message----- From: Jerry Van Baren [mailto:gerald.vanbaren@comcast.net] Sent: den 16 december 2006 17:08 To: Joakim Tjernlund Cc: u-boot-users@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
On 16 Δεκ 2006, at 11:32 ΠΜ, Joakim Tjernlund wrote:
-----Original Message----- From: Jerry Van Baren [mailto:gerald.vanbaren@comcast.net] Sent: den 16 december 2006 17:08 To: Joakim Tjernlund Cc: u-boot-users@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
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
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
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
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
-----Original Message----- From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users-bounces@lists.sourceforge.net] On Behalf Of Wolfgang Denk Sent: den 16 december 2006 20:04 To: Joakim Tjernlund Cc: u-boot-users@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
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
-----Original Message----- From: wd@denx.de [mailto:wd@denx.de] Sent: den 17 december 2006 01:38 To: Joakim Tjernlund Cc: u-boot-users@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
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.
-----Original Message----- From: glikely@gmail.com [mailto:glikely@gmail.com] On Behalf Of Grant Likely Sent: den 17 december 2006 16:11 To: Joakim Tjernlund Cc: wd@denx.de; u-boot-users@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
-----Original Message----- From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users-bounces@lists.sourceforge.net] On Behalf Of Joakim Tjernlund Sent: den 17 december 2006 16:40 To: 'Grant Likely' Cc: u-boot-users@lists.sourceforge.net; wd@denx.de Subject: Re: [U-Boot-Users] builtin OF tree dtb gone
-----Original Message----- From: glikely@gmail.com [mailto:glikely@gmail.com] On Behalf Of Grant Likely Sent: den 17 december 2006 16:11 To: Joakim Tjernlund Cc: wd@denx.de; u-boot-users@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
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
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
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
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
Ping.
Didn't you like this either or no time to look at it?
Jocke
-----Original Message----- From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users-bounces@lists.sourceforge.net] On Behalf Of Joakim Tjernlund Sent: den 18 december 2006 15:39 To: Wolfgang Denk Cc: 'Grant Likely'; u-boot-users@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);
On 17 Δεκ 2006, at 10:40 ΠΜ, Joakim Tjernlund wrote:
-----Original Message----- From: glikely@gmail.com [mailto:glikely@gmail.com] On Behalf Of Grant Likely Sent: den 17 december 2006 16:11 To: Joakim Tjernlund Cc: wd@denx.de; u-boot-users@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Pantelis Antoniou wrote:
On 17 Δεκ 2006, at 10:40 ΠΜ, Joakim Tjernlund wrote:
-----Original Message----- From: glikely@gmail.com [mailto:glikely@gmail.com] On Behalf Of Grant Likely Sent: den 17 december 2006 16:11 To: Joakim Tjernlund Cc: wd@denx.de; u-boot-users@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.
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
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
participants (7)
-
Dan Malek -
Grant Likely -
Jerry Van Baren -
Joakim Tjernlund -
Pantelis Antoniou -
Timur Tabi -
Wolfgang Denk