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
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
