[U-Boot-Users] LIBFDT: first version of fdt_find_compatible_node

[Jerry Van Baren]

Wolfgang Grandegger wrote:
> Hi Jerry,
> 
>  >Wolfgang Grandegger wrote:
>>> Jerry Van Baren wrote:
> [snip]
>>> Yes, blob parsing will be done from the start of the blob until an 
>>> answer is found every time a question is asked of it.  Not a paradigm 
>>> of efficiency. :-/
>>>
>>> WRT the cached version, I have doubts about how much time it will 
>>> save since I expect the "find compatible" will only be used during 
>>> initialization.  Is it worth optimizing?  Really slow memory - yes. 
>>> Fast memory - I doubt it.
>>> a) I don't picture blobs being stored in really slow memory (no i2c 
>>> memories).
>>> b) If the memory really is slow, it seems like it would be as good or 
>>> better to copy the blob to RAM and use it out of RAM (but there may 
>>> be chicken & egg problems with that - I don't know how deeply you are 
>>> looking to embed this).
>>>
>>> I don't know what board/processor/memory you are ultimately targeting 
>>> with this, so my criticisms may not be valid.  I know denx.de 
>>> support(s|ed) some very slow to boot boards that lots of tricks were 
>>> done WRT optimization of env variables because they were stored in 
>>> i2c memory.
>>
>> I'm doing that for a MPC823 at 50 MHz, a very low-end system, and 
>> almost to slow for 2.6. I will do some real measurements when time 
>> permits to get a better feeling.
> 
> Here are the results of some quick measurements on my MPC855 at 80/40 
> MHz with the attached code example and my DTS test file:
> 
>               from FLASH   from Memory
> Non-cached:    11116 us       1703 us
> Cached    :     2800 us       6226 us
> 
> Well, I think we can drop the cached version even if its 4 times faster, 
> as it make life more difficult, especially in case the FDT gets updated.
> 
> Wolfgang.

Risk & reward.  The reward is pretty substantial if you read directly 
from slow flash, but iffy for faster RAM.

In the "from Memory" column, do you have the numbers switched?  The 
non-cached is shown as being 4x faster than the cached.

To be a fair comparison, the "from Memory" column also needs the time it 
would take to copy the blob from flash to RAM added, yes?  That penalty 
can be bypassed by loading the blob directly into RAM via tftp or the 
copy to RAM time may already be part of the boot process, but it should 
be identified.

gvb