From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Grandegger Date: Thu, 26 Apr 2007 13:12:32 +0200 Subject: [U-Boot-Users] LIBFDT: first version of fdt_find_compatible_node In-Reply-To: <463082E6.9060002@gmail.com> References: <462F1831.7070902@grandegger.com> <462F6FDC.8020804@smiths-aerospace.com> <462FADF0.9020008@grandegger.com> <462FC2BE.9070309@smiths-aerospace.com> <46305734.70909@grandegger.com> <46307410.2000202@grandegger.com> <463082E6.9060002@gmail.com> Message-ID: <46308920.9020902@grandegger.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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.