Thoughts on current OE gta01/gta02 integration, kernel, uboot
laforge at openmoko.org
Thu Oct 4 10:39:22 CEST 2007
On Wed, Oct 03, 2007 at 10:49:02PM +0100, Graeme Gregory wrote:
>> 1) the yaffs2 support is not working since there's a missing parameter
>> to the mkyaffs2image in bitbake.conf. I'm not yet sure which one is
>> the right one for us, will submit a patch later on.
> Im having trouble buidling mkyaffs2image at all at moment.
>> 2) the multi-mach support semems to work fine in general, however:
>> It would be great if Graeme or somebody else with bitbake+OE background
>> could look into resolving those issues.
> Pretty much all this problems are because mickey has made the choice
> to make gta01 and gta02 seperate machines within OE. This can be
> fixed, but Id like to talk to mickey at OEDEM before undoing his work.
This is something I failed to understand, too. I don't really see much
of a reason. 99% of the software is identical, and I'd much rather have
the software detect the differences at runtime.
There are a few differences in configuration files, though (inittab,
alsa state files, ...) an I guess that was the main reason for
But then, my knowledge about OE is much more limited.
Looking at it as an 'exercise', I think it's great, though. We will
have more devices next year, and they will - to a varying degree - show
different levels of similarity to GTA01 and GTA02.
In any case, I think we need something like a "neo1973" class of
devices, which encompasses (at least) GTA01, GTA02 and most likely GTA03
in the future. They are all Samsung s3c based, will likely share one
> gtk+ is gta01/2 specific as it has openmoko only patches applied.
yes and no. It is openmoko specific, I'd say. We will most definitely have
more devices that share the same UI and thus the same patches. So it
should be either openmoko-distribution specific, or specific to the
"neo1973" device class. I don't know how to implement such a device
class notion (with _neo1973.ipk packages) in OE, though.
>> 3) svn revisions for kernel + u-boot are frozen right now. I don't say
>> thre is no reason to do so, but I would want to know why those
>> specific revisions have been selected, and what particular
>> regressions are worked around by using old versions.
> Kernel is the latest svn according to my svn info on openmoko repo. u-boot
> I havent checked yet.
Ah yes, I just verified that, sorry. So the idea is to manually test and then
bump the revision after new commits go in?
- Harald Welte <laforge at openmoko.org> http://openmoko.org/
Software for the world's first truly open Free Software mobile phone
More information about the distro-devel