From: Jerry Van Baren <gvb.uboot@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] LIBFDT: first version of fdt_find_compatible_node
Date: Thu, 26 Apr 2007 06:45:58 -0400 [thread overview]
Message-ID: <463082E6.9060002@gmail.com> (raw)
In-Reply-To: <46307410.2000202@grandegger.com>
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
next prev parent reply other threads:[~2007-04-26 10:45 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
2007-04-26 10:45 ` Jerry Van Baren [this message]
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=463082E6.9060002@gmail.com \
--to=gvb.uboot@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox