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

[Wolfgang Grandegger]

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

Yes, a cut & paste error, sorry.

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

Here is the revised list:

                 from FLASH   from Memory
   Non-cached:    11116 us       6226 us
   Cached    :     2800 us       1703 us (2096 us)

The number in brackets is _with_ memcpy. The FDT should normally be 
access from memory, I fully agree.

Wolfgang.