[U-Boot-Users] fdt addr should copy fdt out of flash

[U-Boot-Users] fdt addr should copy fdt out of flash

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

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.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] fdt addr should copy fdt out of flash

[Jerry Van Baren]

Timur Tabi wrote:
> 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).

> 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

[U-Boot-Users] fdt addr should copy fdt out of flash

[Timur Tabi]

Jerry Van Baren wrote:

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

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

> The "bootm" code (should) still copy from flash to RAM if necessary, 
> because I adapted the existing code. 

Ah yes, you're right.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] fdt addr should copy fdt out of flash

[Jerry Van Baren]

Timur Tabi wrote:
> Jerry Van Baren wrote:
> 
>> 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.

CC:ing the list will generally be the fastest and most reliable.

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

>> The "bootm" code (should) still copy from flash to RAM if necessary, 
>> because I adapted the existing code. 
> 
> Ah yes, you're right.

[U-Boot-Users] fdt addr should copy fdt out of flash

[Timur Tabi]

Jerry Van Baren wrote:

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

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] fdt addr should copy fdt out of flash

[Wolfgang Denk]

In message <462E5992.3000405@smiths-aerospace.com> 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

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

[U-Boot-Users] fdt addr should copy fdt out of flash

[Jerry Van Baren]

Timur Tabi wrote:
> Jerry Van Baren wrote:
> 
>> <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

[U-Boot-Users] fdt addr should copy fdt out of flash

[Jerry Van Baren]

Wolfgang Denk wrote:
> In message <462E5992.3000405@smiths-aerospace.com> 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

Imagine me dragging my feet until the problem becomes SEP. :-)
<http://en.wikipedia.org/wiki/Somebody_Else%27s_Problem_field>

gvb