On 12/22/09 23:28, Somebody in the thread at some point said:
Hi -
Fedora provides a whole solution there, with the restriction it's
designed for native build, not cross.
That's probably also a matter of taste. I still find it a feature to be
The two ways have different advantages and disadvantages. Cross gives
you speed of rebuild, but 99% of packages on an ARM11+ type system you
actually have no interest in rebuilding since you just use the stock
versions. Cross can be extremely painful with projects that are not set
up for it, eg, perl. Native build gives you compatibility of build with
the whole package universe. The slow build action doesn't hurt so much
because -->
able to cross compile the systems - we can still recompile whole systems
consistently in just a few (ten) minutes, i.e. in order to change a
central switch (like softfloat vs. hardfloat, use another toolchain
etc). Out of interest, how long does it take to recompile Fedora on for
example MX31?
I don't know or care when I get the binary packages from a repo where
they're already built. The whole point of a distro solution is someone
did all the work for you. You're only thinking about mass rebuild
yourself because it's the buildroot mindset, that whole task disappears
with a distro basis.
Packages only help any QA effort. You don't have to release every
package build to your stable repo, a staged development / testing /
stable repo scheme is simple.
For let's say a telematics box it's almost impossible to test packet
combinations. All you can do is decide for "update application" and
"update platform". If you got your software updates via SMS, it
shouldn't go wrong because of an untested packet combination :-)
You missed my point I think. You can emulate "issue 6 monthly rootfs
tarball updates" by just updating the stable package repo at long
intervals with well-tested packagesets. At the same time you can offer
other repos with newer features earlier, get changed packages tested
easier, confirm patchlevel on test systems, etc.
Right. Fedora is different though, there are no cross-built packages
(although they do provide cross compilers, I use them for kernel and
Qi builds) and if storage is sufficient, there's no need to strip
anything out. Just nobble init.
Hmm, I'm still not convinced. But as I don't have any data, I'll keep
quiet :-)
You can get data easily enough, use the Fedora tarball and run with
init=/bin/bash as a starting point. Then write a script that does the
minimal jobs like bringup lo, remount rw, config ethernet and service
sshd start and time that as init.
The point is you're definitively bypassing the *whole* of Fedora bringup
that way while still getting the advantages of the Fedora rootfs basis
and most of sysv service management.
I think a central question is if you want to optimize things like
* early boot splash
* footprint
Early boot splash is a kernel matter, it has facilities for it already.
For footprint, you can't play this game if you don't have say 200MB
spare as already told it's the cost of entry.
But if you can play the distro game (combined with leaving the
bootloader alone to only boot Linux) the software engineering and
maintainence load for a really capable rootfs dwindles to about the same
level of job as maintaining a Linux server box, and quality goes up.
Well for my uses of it I have been able to specify that we should have
versioning GPIOs on the boards. It's a good idea anyway.
Hardware description is still one of the unsolved problems out there. It
...
need the schematics in machine readable form... When oftree comes into
the ARM world, we need a maximum-style bootloader which can provide
oftrees.
I take your point but actually there's no reason the *bootloader* needs
that when the bootloader is focussed solely on booting Linux. *Linux*
might want an equipment list from the board, but then typically you
would build all the drivers and they can simply probe and fail if its
not there on the board.
It's nothing to do with mainline, just intra-company communication and
management failure.
My experience is that mainline exposure of that perverted bit-twiddling
code and ideas helps finding sane solutions, because someone will
allways ask the right questions :-)
I'm not sure I managed to give the flavour of a bunch of hardware guys
half a world away rotating in and out on Military service. Even patches
internally aren't happening, Mainline isn't an answer.
Unfortunately, often people want to boot as fast as possible, which
requires optimization in that area as well. We recently had a board
which refused to boot without the PMIC having switched on some
voltages which are default-off.
If your device is able to run from USB power, there's the issue that
you are limited to 100mA before enumeration takes place. So without a
USB stack, you have to trade speed for power anyway.
My argument is that there are all these different requirements out
there: your use cases, mine, others. What we want to do with barebox is
Sure, Qi targets ARM9+ with steppingstone. If you have something else
you will have to use something else or port it.
If it's not understood what the advantages are of Qi's strict rejection
of its list of evil things, then they will likely go with U-Boot I guess
since it has the mindshare.
bus driver back into the bootloader. But actually, normal customers
don't care about 200ms on boot either way. They can get the thing to
market quicker and so cheaper and more reliably without that stuff in
the bootloader.
That's a matter of the definition of "normal customers" :-)
What I mean by it is for geeks like us, it's interesting to see how fast
it will go. The actual customer cannot tell 200ms by eye he will accept
it if it's not passing his threshold of being "too slow". But he will
like getting it shipping earlier because the bootloader is almost
invisible in dev effort and in management of production.
distributions, where people can just 'apt-get install kde'. All our
recent experiments seem to suggest that mainstream distros are not able
to do what we need today, but times may change.
Well it sounds like you didn't try Fedora which should be high on the
list. But if "what you need" doesn't match I guess you won't have a
good time there no matter how great it is.
However, I found the discussion pretty interesting! Thanks a lot, it
gave me some interesting insights.
You're welcome, we even mentioned Qi occasionally :-)
-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
