OpenEmbedded Invitation

[mickeyl]

Hi guys,

this is Michael 'Mickey' Lauer, OpenEmbedded/Opie/OpenZaurus Core Developer. I've been following your progress concerning the GPL kernel sources for the pxa-based motorola phones with excitement. I want to invite you to join our team and add the necessary machine configurations and .bb files to build Motorola Handy Images / Packages.

For getting started, head over to the openembedded.org site and read GettingStarted as well as my presentation I gave at this years FOSDEM (http://vanille.de/tools/FOSDEM2005.pdf). Since many of us believe in Linux on phones, we would be glad to have you as a part of our team.

If you have specific questions, drop us a mail to oe@handhelds.org, or just head over to #oe on irc.freenode.net. I'll try to get hold of an A780 asap.

Sincere regards,

Michael 'Mickey' Lauer

[pascal]

thank you very much

but it looks like we have to grab boot loader sources too, before we can flash new image,

but my feeling is very good, things are getting really hot

[rpconnect]

yes, thank you!!!

I have been experimenting w/ OE for about a week; I am trying to build an ipaq image w/ 2.4.20 kernel and see how much of the qt/opie/gpe/x11 stull will run. I keep running into stupid problems here and there, and it seems to take forever, but the overall layout and organization of the OE build process is very encouraging.

Eventually we should be able to create the proper meta files to use the e680 linux kernel source from sourceforge (thanks again pascal) then build rootfs images w/ all kinds of options

[cyph]

I've been trying to get OE to compile apps for the phone. But I've not even been able to get the basic toolchain up correctly Compiled binaries use FPA instead of the VFP the phone's libs are using. I guess I might have to resort to using leprechaun's cross-compiler instead, but of course that would not be elegant in the whole OE scheme of things. Anyone got this working?

[rpconnect]

@cyph
i had the same problem and tried for a while to change the bitbake files to force an "e680-build" to use the cross-compiler from leprechaun's chain, but then you came out with your nice opie package and I stopped there. I was able to hack a build for the xqt app. i used bitbake to fetch, patch, and configure the package, then modified the compile proceedure to rebuild everything w/ the soft-float compiler; i think a similar proceedure could be done for other packages but i haven't had time to play around any more.

[cyph]

I'm using a line like :

ASSUME_PROVIDED = "virtual/${TARGET_PREFIX}gcc virtual/libc"

and setting the PATH to leprechaun's arm-linux- compilers right now. Will visit this soon again. But I guess just as well, don't change what's not broken

[rpconnect]

hmm, i'd be interested to find out more about what you tried (when you have time of course). I remember leprechaun expressing an interest in OE development to build a GPE package.

although it may take some effort to get a stable OE-style build environment working, i think in the long run it will be worth it. there are so many cool apps that OE can offer.

[cyph]

It will be nice to have OE build the toolchain, but leprechaun's crosstool works for now. I tried to use several gcc versions, and at the same time match the glibc on the phone (2.3.2) but the compile failed at certain points. If the compile succeeds, I end up with a binary using FPA instead of VFP, which is not binary compatible with the phone's libraries. It seems like most of the ARM systems out there are using FPA.

Don't ask me what have I tried, because I don't take note of failures I know.. I'm kinda lazy.

OE is so complex, and good documentation is not readily available. I usually end up with viewing 10 files in 10 different windows trying to trace how a package is compiled. Gives me a headache I'll go for a smoke But someday, I'll figure this whole thing out.....

[leprechaun]

Is FPA really a problem then? I mean if we build the whole system from scratch, there shouldn't be any lib problems..

The boot loader sources would be really nice to get though.
An open source phone, what a dream!

[cyph]

As of now though, realistically, I think we have to live with EZX. It, and a few closed source drivers are required for the operation of this phone. Otherwise we just end up with a very expensive PDA....

Closed source drivers which we can never replace:
MMC/SD (I guess they need to keep the SD protocol secret)
GSM
GPRS
TrueFFS DiskOnChip
MIDI Device

IMHO, bootloader sources are much less valuable than any of the above. Part of ezx sdk were leaked once, so we can just all sit back and pray for more miracles...

We can set up a sub-environment (maybe even a chroot) where we control all libraries ourselves, but I would really like to use the phone libraries as much as possible. Not too wise to have 2 of glibc/stdlibc/etc. in a device already low on memory.