From: Wolfgang Grandegger <wg@grandegger.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] LIBFDT: first version of fdt_find_compatible_node
Date: Thu, 26 Apr 2007 11:42:40 +0200 [thread overview]
Message-ID: <46307410.2000202@grandegger.com> (raw)
In-Reply-To: <46305734.70909@grandegger.com>
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fdt-find-compatible-nodes.c
Type: text/x-csrc
Size: 907 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070426/6a8c55ec/attachment.c
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lite5200.dts
Url: http://lists.denx.de/pipermail/u-boot/attachments/20070426/6a8c55ec/attachment.txt
next prev parent reply other threads:[~2007-04-26 9:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-25 8:58 [U-Boot-Users] LIBFDT: first version of fdt_find_compatible_node Wolfgang Grandegger
2007-04-25 15:12 ` Jerry Van Baren
2007-04-25 19:37 ` Wolfgang Grandegger
2007-04-25 21:06 ` Jerry Van Baren
2007-04-26 7:39 ` Wolfgang Grandegger
2007-04-26 9:42 ` Wolfgang Grandegger [this message]
2007-04-26 10:45 ` Jerry Van Baren
2007-04-26 11:12 ` Wolfgang Grandegger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46307410.2000202@grandegger.com \
--to=wg@grandegger.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.