From: Andy Green <andy@warmcat.com>
To: Robert Schwebel <r.schwebel@pengutronix.de>
Cc: Wolfgang Denk <wd@denx.de>,
celinux-dev@tree.celinuxforum.org,
linux-embedded@vger.kernel.org
Subject: Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
Date: Wed, 23 Dec 2009 09:29:22 +0000 [thread overview]
Message-ID: <4B31E2F2.4010206@warmcat.com> (raw)
In-Reply-To: <20091223085607.GE22533@pengutronix.de>
On 12/23/09 08:56, Somebody in the thread at some point said:
Hi -
>> yourself because it's the buildroot mindset, that whole task
>> disappears with a distro basis.
>
> If you don't step into for example toolchain problems or other crazy
> things...
Again this is buildroot thinking. The distro provides both the native
and cross toolchains for you. You're going to want to use the same
distro as you normally use on your box so the cross toolchain installs
as a package there.
If all that's left is the risk of "crazy things" happening well that's a
risk whatever you do or even if you do nothing :-)
> The oftree is currently provided by the bootloader, and much of what it
> contains is unprobable peripherals, i.e. the IP cores in the SoC cpus.
> For example for i.MX (which we happen to maintain in the mainline),
> there is a strong aim for having one kernel that runs on as many devices
> as possible. If you want to do this and if you can't probe significant
> parts of the hardware, you need an instance outside of the kernel who
> tells you what's actually there.
The only thing I know of that matches "outside the kernel" requirement
is the machine ID that's passed in on ATAG. I agree it's generally good
to have a single build that's multipurpose.
On iMX you have to go read IIM to get device info but actually that's
not hard. But that device ID will itself alone tell you the on-SoC
peripherals since there's an ID per die; it makes no difference if this
expanded SoC oftree data itself lives in the kernel then. The non-SoC
stuff can just be probed.
> We have customers who care about "splash in 0.5 s" vs. "shell runs after
> 3 s, then qt starts". People may be used to that kind of noticable boot
That's fine, they can pay for the extra time to market and work done on
the crap in their bootloader :-) Many customers don't care if it acts
in line with their general expectation and was delivered faster and
cheaper than they expected.
> Do you remember the times when we had analog TV? We could zap through 5
But your CRT took a while to warm up / "boot" as well...
-Andy
next prev parent reply other threads:[~2009-12-23 9:29 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-17 8:31 CELF Project Proposal- Refactoring Qi, lightweight bootloader Matt Hsu
2009-12-17 9:21 ` Andy Green
2009-12-21 19:30 ` [Celinux-dev] " Wolfgang Denk
2009-12-21 19:32 ` Mike Frysinger
2009-12-21 20:17 ` Andy Green
2009-12-21 21:38 ` Wolfgang Denk
2009-12-21 22:38 ` Andy Green
2009-12-21 23:17 ` Wookey
2009-12-21 23:19 ` Robert Schwebel
2009-12-22 8:22 ` Andy Green
2009-12-22 11:12 ` Robert Schwebel
2009-12-22 22:23 ` Andy Green
2009-12-22 23:28 ` Robert Schwebel
2009-12-23 8:38 ` Andy Green
2009-12-23 8:56 ` Robert Schwebel
2009-12-23 9:29 ` Andy Green [this message]
2009-12-23 9:43 ` Robert Schwebel
2009-12-27 7:27 ` Rob Landley
2009-12-27 10:09 ` Andy Green
2009-12-28 0:21 ` Rob Landley
2009-12-28 11:33 ` Andy Green
2009-12-27 7:17 ` Rob Landley
2009-12-27 9:54 ` Andy Green
2009-12-27 23:15 ` Rob Landley
2009-12-28 10:27 ` Andy Green
2009-12-28 19:57 ` Peter Korsgaard
2009-12-28 20:20 ` Andy Green
2009-12-29 4:25 ` Rob Landley
2009-12-29 11:11 ` Andy Green
2009-12-17 23:13 ` Tim Bird
2009-12-21 2:45 ` [Celinux-dev] " Rob Landley
2009-12-21 5:51 ` Matt Hsu
2009-12-21 8:00 ` Rob Landley
2009-12-21 9:54 ` Andy Green
2009-12-21 20:49 ` Wookey
2009-12-23 2:28 ` Jamie Lokier
2009-12-23 8:48 ` Andy Green
2009-12-29 13:13 ` Jamie Lokier
2009-12-29 13:36 ` Andy Green
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=4B31E2F2.4010206@warmcat.com \
--to=andy@warmcat.com \
--cc=celinux-dev@tree.celinuxforum.org \
--cc=linux-embedded@vger.kernel.org \
--cc=r.schwebel@pengutronix.de \
--cc=wd@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;
as well as URLs for NNTP newsgroup(s).