Gentoo Archives: gentoo-dev

From: Nick Rout <nick@×××××××.nz>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Portage in Embedded Systems?
Date: Tue, 05 Oct 2004 23:22:12
Message-Id: 20041006121529.2B26.NICK@rout.co.nz
In Reply to: Re: [gentoo-dev] Portage in Embedded Systems? by Ned Ludd
1 On Tue, 05 Oct 2004 19:09:59 -0400
2 Ned Ludd <solar@g.o> wrote:
3
4 > On Mon, 2004-10-04 at 23:33, Chris White wrote:
5 > > All,
6 > >
7 > > Maybe I've just not seen this, but what sort of footprint does
8 > > portage leave on embedded systems with low cpu/ram?
9 >
10 > I think what your asking about here is what we are starting to coin as a
11 > gentoo-lite system. A lot of people are gaining an interest in this.
12 > Running gentoo with portage on crappy old hardware. Or they just want
13 > the performance boast and lower memory usage. For a system like this I'd
14 > think you would want atleast a P75 with atleast 32M of of ram.
15 > Portage is not so big. But python itself is a beast.
16 >
17 > In one experiment I've managed to get pythons runtime down to about 2
18 > Megs of HD space. And in another experiment with the portage tree itself
19 > I managed to get it down to 14 Megs with the use of squashfs and
20 > excluding a few things from the tree which I know are not needed to do
21 > emerge system. But a full portage-rsync tree compressed was about 17
22 > Megs
23 >
24 > Now if we are talking embedded systems in the way I like to think of
25 > them (ie firmware) then the min requirements are about 4M of Ram and 3M
26 > of flash space using a semi default setup, give or take depending on the
27 > device your building for.
28 >
29 > > I ask this mainly
30 > > because it's a Good Thing To Know (tm) considering the last LWE
31 > > conference was full of people asking about using Gentoo for embedded
32 > > devices.
33 > portage needs work and a fair bit of it.
34 > Other than myself and mike more people need to propose ideas to the
35 > portage team to make things more flexible.
36 >
37 > > Something like higher end Palms may be able to dish it out,
38 > > but what happens when you get to lower end palms or even cell phones?
39 >
40 > What about them?
41 > Most cell phones are ARM based.
42 > Mike Frysinger is currently working on generic uclibc arm little endian
43 > stages. When he has those complete (and most of the bugs worked out)
44 > I'll start on generic uclibc arm big endian stages. When I have those
45 > complete and I'm happy with it I'm going to ship the device off to OSU
46 > so we can continue to support the arch from a (le||be) perspective. The
47 > unit I will be developing with is a nslu2 that was a donation to the
48 > gentoo embedded project thanks to the guys over at the nslu2-linux
49 > project (http://www.nslu2-linux.org/) who had a fund raiser in order to
50 > get me one. They ended up getting 9x the amount in donations needed to
51 > send me a unit and were able to send them to a number of other embedded
52 > projects.
53
54 having taken delivery of a zaurus sl-5500 yeterday this took my eye:
55
56 http://www.opensistemas.com/Gentoo_for_Zaurus.715.0.html
57
58 From the screenshots and other stuff i read there they seems to be cross
59 compiling to binary packages on a x86, then installing on the zaurus,
60 with the possibilty of turning the .tbz2 into a zaurus style .ipk
61 package.
62
63 Presumably the portage tree is not needed on the zaurus, i am not sure
64 and also not game enough to flash mine yet :)
65
66 mind you a zaurus is probably more development oriented than the average
67 ARM based cellphone.
68
69
70 >
71 > Unfortunately there are a few drawbacks to our embedded support right
72 > now.
73 > 1) Lack of skilled (wo)manpower.
74 > 2) Lack of proper cross-toolchain handling by portage. So everything is
75 > considered native-* vs cross-* (this means you must use the same host
76 > arch as your target arch) or use a binfmt_elf kernel module to emulate
77 > your target arch.
78 > 3) package management for embedded devices. (no all devices are
79 > read-only)
80 > - ipkg format seems ideal here but I/we have not enough input from the
81 > community to tell what will be ideal in the long run.
82 >
83 > If anybody that has a decent level of cross compiling experience and
84 > thinks that they would be interested in gentoo supporting better cross-*
85 > support please contact me. (seriously motivated people only)
86 >
87 > >
88 > > Thanks ahead of time for any/all comments and hold on (*ChrisWhite
89 > > prepares fireproof suit)... and flames.
90 >
91 > hrmm flames.. none right now but as soon as I can think of something or
92 > get a blowtorch I'll be sure to direct it your way.
93 >
94 > --
95 > Ned Ludd <solar@g.o>
96 > Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer
97
98 --
99 Nick Rout <nick@×××××××.nz>
100
101
102 --
103 gentoo-dev@g.o mailing list