Re: [gentoo-embedded] is Gentoo ARM really defunct?

[Kumba]

Akos Maroy wrote:

> we already have portage working, with an old snapshot of the portage
> tree (arm keywords still included). see
> http://gentooforzaurus.opensistemas.com/
>
> the idea at the moment is to mount gentoo-related files through nfs, as
> it is quite large, and does not fit on most memory cards for the Zaurus.
>

I don't doubt this.  The smallest drive I managed to kludge gentoo on 
was 1GB, and that required NFS mounting, and waiting about 5 days for 
gcc to build over nfs (was a sparcstation 20).


> by this you mean we shouldn't bother trying to create stage1?

Stage1's need a seed stage, essentially a stage2 at minimum.  I had to 
use a live gentoo filesystem on my Cobalt RaQ2 to kickstart stage 
building for the systems (they're mips little endian, at the time, only 
big endian was supported).  Once you can achieve a stage2, then you can 
work on both stage3 and stage1.  I basically tar'ed up my existing 
stage2 on the cobalt at the time (installed over top a debian 
installation), and used that as a seed stage for stage1 with catalyst 
(was a ~100MB+ seed stage vs. ~40MB for stage2's), built a stage1 off 
that, and then repeated twice more just to make sure I had a pure stage 
with no debian in it  (Took a week).


> a lame question here: naturally there would be more poeple working on
> this, thus this separate portage tree has to be accessed / written by
> several people. how would we achieve this? put it in a CVS somewhere,
> and use cvs commit / update? or somehow utilize emerge sync?

For this project, and since you already have people working on it, I'd 
recommend CVS, or some kind of source code control system.  It'll make 
things easier.


> I see, catalyst is the name of the game here :)

Catalyst is the key for easier gentoo stage building.  I always 
considered the old 'stager' utility nothing more than a glorified bash 
script, but catalyst is a real tool, and is rather effective at what it 
does.


> when we get there, we'll have to have special precautions for embedded
> systems. for example for the Zaurus, you have to flash the new operating
> system in, including the kernel and the base filesystem, via a manual
> procedure.
>
> but hey, it's still some way when we have to address this issue :)

It's never an easy trip, porting to a new arch is typically only done by 
one person, then others get interested.  tuxus started the mips port 
that way, tgall_foo is working on ppc64, GMSoft more or less ran the 
hppa port all by himself for a time before some other people got hppa 
boxes, iggy is working on an s390 port (unsure how many people are using 
it), and the original arm port was started by zwelch by himself (he was 
the one who forked Gentoo into Zynot btw).  So in reality, if you've 
already got a small team together, you're better off from the start than 
some of the other ports.

These precautions you speak of will need to be documented too.  One of 
the people working on the Zaurus stuff may want to maintain a 
guidexml-based installation guide.  Should arm get re-incorporated into 
gentoo sometime down the road, this will be a required piece, especially 
to get it integrated into the Gentoo Handbook.


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond

--
gentoo-embedded@g.o mailing list