All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Malek <dan@embeddededge.com>
To: Jon Loeliger <jdl@freescale.com>
Cc: Jakob Viketoft <jakob.viketoft@bitsim.se>,
	Linux PPC Embedded list <linuxppc-embedded@ozlabs.org>
Subject: Re: OF flat device tree for ppc32...
Date: Thu, 19 May 2005 14:04:05 -0400	[thread overview]
Message-ID: <bf240432651c66377c282f68d3ffaae8@embeddededge.com> (raw)
In-Reply-To: <1116517058.24754.10.camel@gleep>


On May 19, 2005, at 11:37 AM, Jon Loeliger wrote:

> So, there were two positive comments that I received
> as feedback on my initial suggestion, and no negative
> comments.  (Minor patch deltas not withstanding.)

I have the same negative comments as Wolfgang.
This boot rom to kernel interface is continually discussed,
has been for years, and it just gets a little tiring :-)

The main reason for the original work done to create
the "boot wrapper" functions was to accommodate as
many boot roms as possible, distilled into a minimal
amount of common information.

We still have people (more and more, actually) that want
to run Linux and associated applications in minimal
flash and ram space.  Solutions that require more and
more code get to the point where they simply don't
fit into these systems.

There are also many embedded systems that don't
run something like U-Boot, and even if they did they
are not likely to perform field upgrades just to use
something that adds no value to their product.  We
must be able to accommodate these systems, as
the existing code does today.

Real embedded devices have minimalist requirements.
Minimal flash, minimal ram, minimal boot up time.  Even
today, Linux is too big and too slow for many of these
devices, making other alternatives more attractive.  If
we want to continue with success in this embedded
space, we have to address minimal requirement and
stop changing things to make them look like workstations.
We get spoiled by the few evaluation or demo boards we
see, because they are likely on the resource rich side.
Fine for development, but not something that will
see production.

We have embedded design wins today because of
the code we had years ago.  I'm afraid if we continue
with the code bloat and the performance challenges
we see with 2.6, we are going to lose many of the
new embedded products in the future.

If you consider yourself to be an embedded engineer,
you have to place "minimal resource use" at the top
of your list.  They have to boot and be useful "instantly."

Thanks.


	-- Dan

  reply	other threads:[~2005-05-19 18:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-19  6:41 OF flat device tree for ppc32 Jakob Viketoft
2005-05-19 15:37 ` Jon Loeliger
2005-05-19 18:04   ` Dan Malek [this message]
2005-05-20 16:40 ` Jon Loeliger
2005-05-26 23:08   ` Kumar Gala
2005-05-27 19:14     ` bd_t Cleaning: Interface Part Jon Loeliger
2005-05-30 10:13       ` Clemens Koller
2005-05-31 14:59         ` Jon Loeliger
2005-06-04 18:13       ` Sylvain Munaut
2005-05-27 19:16     ` bd_t Cleaning: Board Changes Jon Loeliger
2005-06-01 18:10       ` Mark A. Greer
2005-06-01 18:52         ` Kumar Gala
2005-08-29 23:46         ` Mark A. Greer
2005-05-27 19:18     ` bd_t Cleaning: Driver Bits Jon Loeliger
2005-05-27 19:20     ` bd_t Cleaning: System Parts Jon Loeliger

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=bf240432651c66377c282f68d3ffaae8@embeddededge.com \
    --to=dan@embeddededge.com \
    --cc=jakob.viketoft@bitsim.se \
    --cc=jdl@freescale.com \
    --cc=linuxppc-embedded@ozlabs.org \
    /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.