fdt addr should copy fdt out of flash
Jerry, I don't know which email address of yours to use, so I'm sending this to all of them, because I frequently don't get replies to my emails to you.
I noticed in the code for 'fdt addr' that you don't mempcy the fdt into RAM if the address is in flash. This means that commands like 'fdt set' won't work. In these cases, I think the 'fdt addr' should automatically copy the fdt into RAM.
I believe that the original code did this already, so the current behavior is technically a regression.
Signature · 2 lines
Timur Tabi Linux Kernel Developer @ Freescale
Quoted 3 lines · Timur Tabi
Jerry, I don't know which email address of yours to use, so I'm sending this to all of them, because I frequently don't get replies to my emails to you.
Hi Timur,
They all work. Don't take it personally, my wife claims I ignore her too. ;-) Seriously, I don't intentionally ignore you, it seems like a spam filter is hitting one of us.
The email addresses correspond to my day job, my night job, and I subscribed to the u-boot list at home via gmail to control my email clutter (I'm also subscribed to the u-boot list at my day job because I'm an email junkie).
Quoted 7 lines
I noticed in the code for 'fdt addr' that you don't mempcy the fdt into RAM if the address is in flash. This means that commands like 'fdt set' won't work. In these cases, I think the 'fdt addr' should automatically copy the fdt into RAM.
I believe that the original code did this already, so the current behavior is technically a regression.
"fdt addr" is to tell fdt where the blob is in memory. If you want to move it from flash to RAM, you need to use "fdt move".
The "bootm" code (should) still copy from flash to RAM if necessary, because I adapted the existing code. I have not built any multi-images and flashed them so that code is untested. I sent a query for RTFM pointers on building multi-images but nobody responded and I have not had time to follow up on that yet.
Best regards,
gvb
Quoted 4 lines · Jerry Van Baren
The email addresses correspond to my day job, my night job, and I subscribed to the u-boot list at home via gmail to control my email clutter (I'm also subscribed to the u-boot list at my day job because I'm an email junkie).
So if I had to email you out-of-the blue about an FDT issue, which one should I use?
Quoted 2 lines
"fdt addr" is to tell fdt where the blob is in memory. If you want to move it from flash to RAM, you need to use "fdt move".
fdt move requires me to know how big the FDT is. Is there any way you can have it figure out for me?
Quoted 2 lines
The "bootm" code (should) still copy from flash to RAM if necessary, because I adapted the existing code.
Ah yes, you're right.
Signature · 2 lines
Timur Tabi Linux Kernel Developer @ Freescale
Quoted 9 lines · Timur Tabi
Quoted 4 lines · Jerry Van Baren
The email addresses correspond to my day job, my night job, and I subscribed to the u-boot list at home via gmail to control my email clutter (I'm also subscribed to the u-boot list at my day job because I'm an email junkie).
So if I had to email you out-of-the blue about an FDT issue, which one should I use?
Well, it is hard to say... if you want the fastest response during the day (Eastern TZ), the smiths-aerospace.com address will be the one, but it will probably change sometime fairly soon...
<http://www.defenseindustrydaily.com/2007/01/ge-buys-smiths-aerospace-for-48b/index.php>
(the deal is scheduled to close May 4).
The gvb.uboot at gmail is how I'm subscribed as at home, and that is where I work on u-boot, but the response time will be less consistent.
Quoted 5 lines
Quoted 2 lines
"fdt addr" is to tell fdt where the blob is in memory. If you want to move it from flash to RAM, you need to use "fdt move".
fdt move requires me to know how big the FDT is. Is there any way you can have it figure out for me?
Yup, I'll add that as a desired enhancement. The size should be optional like it is with "fdt addr".
<http://www.denx.de/wiki/view/UBoot/UBootFdtInfo#ToDo>
Done (adding it to the ToDo list, that is).
Quoted 4 lines
Quoted 2 lines
The "bootm" code (should) still copy from flash to RAM if necessary, because I adapted the existing code.
Ah yes, you're right.
Quoted 2 lines · Jerry Van Baren
<http://www.denx.de/wiki/view/UBoot/UBootFdtInfo#ToDo>
Done (adding it to the ToDo list, that is).
Thanks. I have another suggestion.
For the 'fdt addr', I'd like to be able to say "fdt addr X +Y", where "Y" is the number of additional bytes I want.
Signature · 2 lines
Timur Tabi Linux Kernel Developer @ Freescale
Quoted 9 lines · Timur Tabi
Quoted 2 lines · Jerry Van Baren
<http://www.denx.de/wiki/view/UBoot/UBootFdtInfo#ToDo>
Done (adding it to the ToDo list, that is).Thanks. I have another suggestion.
For the 'fdt addr', I'd like to be able to say "fdt addr X +Y", where "Y" is the number of additional bytes I want.
Yes, that is a good idea. I'll add it to the list.
gvb
Quoted 6 lines · In message <[email protected]> you wrote:
The "bootm" code (should) still copy from flash to RAM if necessary, because I adapted the existing code. I have not built any multi-images and flashed them so that code is untested. I sent a query for RTFM pointers on building multi-images but nobody responded and I have not had time to follow up on that yet.
Imagine that in the long run the current dumb multi-file image format will be replaced by a new, more flexible one, where images can have types and other properties. Also imagine that libfdt code might be used to read such properties...
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de The game of life is a game of boomerangs. Our thoughts, deeds and words return to us sooner or later with astounding accuracy.
Quoted 7 lines · Wolfgang Denk
Quoted 5 lines · In message <[email protected]> you wrote:
The "bootm" code (should) still copy from flash to RAM if necessary, because I adapted the existing code. I have not built any multi-images and flashed them so that code is untested. I sent a query for RTFM pointers on building multi-images but nobody responded and I have not had time to follow up on that yet.
Quoted 7 lines
Imagine that in the long run the current dumb multi-file image format will be replaced by a new, more flexible one, where images can have types and other properties. Also imagine that libfdt code might be used to read such properties...
Best regards,
Wolfgang Denk
Imagine me dragging my feet until the problem becomes SEP. :-)
<http://en.wikipedia.org/wiki/Somebody_Else%27s_Problem_field>
gvb