-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 23.02.2011 23:02, schrieb John Willis:
Firmware Image:
(...)
Sounds like a good plan to me. Providing some means of testing (and asking people to use them) based on sd cards without the people killing their NAND, since the (earlier) .next images are likely to be problematic.
Kernel:
(...)
I don't know the exact status of the kernel with patches and such. But might it maybe even be a good idea to directly aim for .38? It is supposed to be out rather soonish, which is likely "significantly before .next is ready". IIRC linux-omap is regulary synced in the git, not sure if it can directly be dropped in or not.
Toolchain:
Continue to develop the toolchain scripts based on the work I started with meta-toolchain in OE and try and fix as may host system packaging issues as we can without resorting to hacks or just copy/pasting in files. There is some stuff from Poky/Yocto we may wish to pull in for this but I think it will come into our tree via OpenEmbedded soon enough anyway.
We may also want to tweak things so the root path for the chain can be a little more configurable, I consider that one a low priority nice to have.
The toolchain should also be the same set of binaries used to build the image, if the image is GCC 4.5 SVN blah the toolchain is GCC 4.5 SVN blah etc. etc. - OE makes that pretty easy.
We should also aim to have a toolchain and SDK ready to go with the new firmware (or say release + 2 weeks?). Normal x86 and x64 Linux builds should be fine; we can offer unofficial toolchains for other architectures if there is demand.
Yes, having a "real" official toolchain sounds like a good plan to me. Personally I don't care too much what it is based upon, as long as it is easily usable and works nicely. Makes sense to have it based upon the OE stuff, especially if it is easily possible to gather the required packages there.
How does this toolchain (in general) cope with upgrades? Is it, once the feeds are setup correctly so that they point to openpandora.org, possible to just use opkg to get the relevant updates?
Codec pack: - -------------------------- Another thing that should be considered for the next firmware series is how to act in regards to the codec pack with mplayer and such. JDGBOLT is currently working on "panplayer" which should offer some good generic support for a lot of stuff. The question together with this are: 1) Does it make sense to offer a codec pack once a decent "complete bundle" for the mplayer is available? 2) If that is the case, are there easier ways than manually gathering a list of packages and "brute force" installing them using opkg? Is there someone available with the knowledge and time to do this?
Backwards compatibility: - -------------------------- The new angstrom version will change several libs that are often linked against. The most prominent examples are probably libjpeg.so.6 (will be libjpeg.so.8 after the upgrade) and boost (they got the version number in the mainly used name, too). The question now is: Do we accept it that a major update of the OS potentially breaks many existing PNDs? Should we advise the developers to package the libs linked against in the PND, just using them as backup (aka appending the lib/ folder in the LD_PRELOAD var)? Or would it make sense to create a package ourselves with the most common "old libs" while having the symlinks point to the latest ones. This step would increase the size of the firmware and I don't know by how much (and for which libs this would really make sense, the major examples with compatibility probs that come to my mind are boost and libjpeg).
Cheers, Nils Kneuper aka Ivanovic