[oe] [RFC] handhelds-pxa-2.6 -> linux-handhelds-2.6

[Paul Sokolovsky]

Hello Erik,

Friday, October 13, 2006, 8:34:54 PM, you wrote:

> On Fri, Oct 13, 2006 at 07:51:07PM +0300, Paul Sokolovsky wrote:
>> 2. "pxa" there is misleading, as 2.6 tree supports different
>> architectures. Handhelds.org tree as of now supports PXA, SA, and S3
>> (Samsung) devices. To the various degrees, but that's improving.

> Technically, the pxa is not misleading per se. That recipe only builds a
> kernel for pxa devices.

  Well that's why I brought this to discussion. By "only builds" do
you mean the current state of affairs or some inherent constraint on
that recipe?

  If first, then true, we have only PXA in "production" (so to say)
level in HH.org CVS. But other archs do catch up. For example, rx3000
(S3) already has support for SD, i.e. pretty suitable to host a Linux
install ;-).

  If you mean the latter, then I don't see anything PXA-specific in
recipe itself. It will build with whatever defconfig is called by
MACHINE. Architecture-dependent gcc options are set outside (e.g.
tune-xscale.conf), and IIRC, there's actually possible to use specific
GCC version to build a kernel if it goes up to that. So, what other
arch dependencies I'm missing?



  The related question is however EABI support on pre-armv5 arhcs.
Koen, can you (possibly, once again ;-) ) elaborate, what we have
here. I hope noone (maybe, except ARM Inc.) talks about no EABI
support on armv4 machines? Maybe it won't be that thumb instruction
(let there be more memory in each of us), maybe there indeed be armv4
and armv5 specific binaries (with armv4 working around that
isntruction), but we will have Angstrom and other coolness on
all machines, right?

> But since we are not really targeting one kernel
> for several handhelds, I don't see a problem with what you propose.

  Yes, I checked this with OE maintainers and as I heard this was
discussed on OEDEM: it's ok to have separate MACHINE (and thus,
kernel) for each device which deserves that (i.e. not just marketing
renaming of another model). However, it's desirable to get rid of
machine dependency for all other packages where it reasonably can be
done (runtime checks and configuration is ok means for that, if
it doesn't lead to gross code size/quality issues and noticable
performance loss; hopefully, we have few cases of that being otherwise
in 10-20 machine-dependent packages we have now).

> E




-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com