Am Thu, 6 Mar 2014 22:12:58 -0000 hat "John Willis" John.Willis@Distant-earth.com geschrieben:
Hi,
As mentioned, I'd like to use Debian (testing), as it has pretty good package management and is well-known. If someone prefers a different one, let me know :)
To be honest I have Yocto/OpenEmbedded going as well but I can see the sense in sticking with Debian IF we can minimise the trade offs.
Well, Yocto / OpenEmbedded still seems to miss tons of packages that a normal OS has (LibreOffice, etc.), so Debian would be better.
I'd like to stick to standard Debian as much as possible, so we've got as little work as possible as well.
It's not a small job regardless of how we cut it. We need to get an OS tuned for the hardware regardless.
True, but we can try to keep that as little as possible. I see no reason, for example, to recompile most programs available on Debian.
We'd need to take care of the base system. Most of the driver stuff probably happens in the kernel, most of the rest could mostly be standard Debian stuff without any patches (hopefully).
Right now we're running the rootfs of the GTA04 and I switch to debian unstable repos and installed all kinds of programs with it - without any issues. They work fine.
Standard Debian is compiled without NEON optimization though, so I guess we should at least recompile most of the base packages we need.
It is not just NEON that is lacking but that can sorted with some work once we have something setup to build the packages.
It's mostly build parameters we need to change, I guess?
As recompiling needs some CPU power, I was thinking of renting another small server which will only be used as build server for the OS.
Remember that Debian is an 'on device' OS, Angstrom and the likes got picked for the OpenPandora due to the ease (relative term) of cross compiling.
Okay. So it would make sense setting up a complete ARM QEMU rootfs on the server?
I tried to find ARM Root Servers you can rent, but I haven't found one yet.
Things have changed a lot in this area but we are still really going to want to be using a Qemu setup tweaked for the OMAP or an actual device :o to do most of the builds if we want to optimise beyond the generic. I have started to play with this already, based on what I played with when I got involved with the Raspian Debian port (a downstream rebuild but the same principle).
Okay... are there many OMAP-specific things when recompiling? I know there are some parameters you set in your compiler, but most of them are generic ARM stuff (like NEON). Is the OMAP special here?
Our build server should...
[wall of text removed]
All very sane and the more we can automate from this stage the better things will be.
The hardest step will probably to get this all working. Once it works, I don't think much should break there. Debian provides its own sources (unlike Angstrom, which links to non-existant sourcecodes after a while...)
DJWillis, do you think you can find some time to set this up?
I want to, I have started with the ARM emu build setup on my rigs and that has been churning packages for a while for testing (based on the OpenPandora setup). I have the usual work commitments so I'll have to see how this is going to work out.
Okay. Let me know if I should rent a root server so you can set it up directly there.
And let me know what speed / memory / etc. we need :)
If we do this all out in the open (or at least as open as we can be) then it is easy for them to see where things are and pitch in. I can't see it being a bad place to be but custom Debian is a new approach. Most of what we have learnt from the OpenPandora OS crapshoot is relevant and we know that frankly if we don't make it almost self-maintaining from the start it will rot and no amount of wishful thinking will fix it without hard labour.
Yep, exactly!
Even if it's more complex setting up such a system in the beginning - it certainly is worth it in the end!