Gentoo Archives: gentoo-embedded

From: wireless <wireless@×××××××××××.com>
To: gentoo-embedded@l.g.o, dave.adams@×××××××××.com, beth@××××××.net
Cc: bdale@××.com, overholt@××××××.com
Subject: Re: [gentoo-embedded] list of devices / boards, subprojects for each?
Date: Fri, 28 Jul 2006 17:32:14
Message-Id: 44CA4E4B.8050102@tampabay.rr.com
In Reply to: Re: [gentoo-embedded] list of devices / boards, subprojects for each? by Christopher Friedt
1 Christopher Friedt wrote:
2 > Hello Harald, Mike et al,
3
4 Hello David, Bdale, Andrew et. al.,
5
6
7 Well sorry for the delay, I just got back from the Freescale
8 (PPC , i.MX, Coldfire) conference in Orlando. WHAT A BLAST,
9 Embedded Linux everywhere, Lots of folks that love all aspects of
10 Linux, fantastic food, a wonderful presentation by Neil
11 Armstrong and a private concert for 2000 linux enthusiast at the
12 Hard Rock Cafe (food and drinks) while watching '3 Doors Down'.
13 You'll have excuse my exuberance, but, it was one ass_kicking
14 time! I felt like a teenager again.....
15
16 If anyone questions the vitality of the PPC or any other
17 FreeScale processor lines, they should attend the FTF next year:
18 http://www.freescale.com/webapp/sps/site/homepage.jsp?nodeId=0525779036
19
20 Genesi won an award with embedded gentoo and a 7.1 surround
21 system implementation, at last year's show:
22
23 http://www.genesippc.com/press.php?date=20050624
24
25 > I'm hearing excellent ideas here. My first conception was to just have
26 > individuals responsible for their various boards with collaboration on a
27 > common platform, but to have a terminal server for other gentoo-embedded
28 > developers is also a fantastic idea. This would facilitate svn firmware
29 > images / filesystems, etc.
30
31 Sounds good. Some of my interest are a bit more aggressive: Real
32 time(SCADA) controls of actual hardware combined with streaming
33 video, Some 8/16 bit processors running state-machines with
34 minimalistic tcp/ip stacks, testing custom(fast)
35 bootloaders...... for sure embedded (gentoo) would be at the core
36 of our site, but augmented with other aspects of traditional
37 embedded systems development. Building a bridge to all of those
38 legacy embedded developers is as important as getting the
39 tech-kids of tomorrow hooked on embedded gentoo, methinks.
40
41
42 > The reason I believe that gentoo would be a great choice for embedded
43 > linux is purely for 2 reasons:
44
45 > 1) portage - an incredibly versatile solution to package management
46 > 2) a highly 'emergant' user / developer / bugfix base
47
48 > Obviously the developers in gentoo-embedded would prefer to have portage
49 > as the primary (only) package management system for gentoo-embedded -
50 > that only makes logical sense.
51
52 There are too many virtues of embedded gentoo to list at this
53 time. Suffice it to say that anyone technical who spends a little
54 time with gentoo, quickly develops their list of favorite features.
55
56
57 > However, there is also an important underlying issue here - whether the
58 > embedded device is Gentoo-based, Debian-based, or RedHat-based, there is
59 > still a need for a standardized embedded device architecture both in
60 > software and hardware.
61
62 I like the standardized approach. It would be nice to have a
63 security mechanism in place for various sites to host embedded
64 gentoo systems and use somewhat similar security approaches to
65 'ease the effort/pain' of keeping these embedded development
66 sites functional, yet secure. If we do not keep these development
67 sites secure, we are going to spend a lot of time on the phone
68 explaining what's going on to our bandwidth suppliers.......
69
70 Vapier (Mike) has an excellent site, that only needs some
71 modifications to begin using as a template. My thoughts are (4)
72 NICS: INTERNET, LAN, DMZ, DMZ-EMBEDDED with the forth being for
73 the collection of (embedded) targets and the terminal server. If
74 it's cookie-cutter, then lots of folks could be encouraged to
75 quickly to set up a few boards on the net. This in turn would
76 encourage lots of local groups to become a visible presence for
77 the communities in which they live (reducing latencies etc etc).
78
79 http://www.gentoo.org/doc/en/home-router-howto.xml
80
81 The use of raw iptables/netfilter scriptable commands on a
82 firewall that allows a site to put embedded development
83 systems up on the net, will also serve as an excellent teaching
84 platform to secure the myriad of embedded gentoo devices that
85 will appear in the near future. Many embedded products that now
86 have an ethernet interface, lack robust security.
87
88 > Some related notes from my most recent Linux World Expo visit in Toronto:
89
90 > I have spoken to Bdale Garbee, CT Open Source & Linux for HP on a
91 > similar topic. I asked him if HP would be interested in supporting a
92 > sort of 'summer of embedded code' for embedded Linux. He mentioned that
93 > he and HP would be interested in 'facilitating' more research into
94 > embedded standards, both hardware and software, since HP uses Linux
95 > exclusively for most of their products that have a processor network
96 > device built into them (aside from the iPaq ... sigh).
97
98 The approach I have suggested would greatly facilitate a proposed
99 'summer of embedded code' and align mentors at the various host
100 sites with those aspiring embedded gentoo minds......
101
102 As mike indicated board level support is still lacking from
103 embedded-gentoo. However, it would be possible, in time for some
104 of the online embedded gentoo development sites to support board
105 level packages as a starting point for board level support.
106 Certainly, we would be willing to consult with FreeScale and
107 select a few boards to package up with embedded gentoo. Any
108 specific requests from the gentoo-embedded community for BSP
109 using embedded gentoo? Freescale promote the usage of an open
110 source tool for setting up new embedded targets, call 'ltib'.
111
112 http://www.bitshrine.org/
113 http://savannah.nongnu.org/projects/ltib/
114
115
116 The only downfall I see is that it does not (yet) support ebuilds
117 directly......only rpms.
118
119 Freescale has gone full-tilt into supporting and encouraging the
120 use of embedded linux. It is their design reference platform of
121 choice. Embedded gentoo was only mentioned on a few slides, but,
122 I'm quite certain embedded gentoo will impress the folks at
123 Freescale. We're already deep into planing a presentation for the
124 FTF in Orlando next summer. I would be quite surprised if
125 FreeScale does not get fully behind these ideas.
126
127
128 > Another business card that I acquired was from Andrew Overholt at
129 > RedHat. He has helped out considerably with the CDT / Eclipse project.
130 > If anyone here has used Eclipse, I'm sure you would agree that it
131 > provides an excellent and freely available platform for code as well as
132 > management. My opinion is that the management side of something on this
133 > scale is almost as important as the code itself, and if that platform
134 > can be standardized for embedded developers the world would literally be
135 > our oyster.
136
137 > These two potentials could not only improve the state of embedded
138 > development but also prove reasonably profitable for all parties
139 > involved, including Gentoo, RedHat, and HP, besides all of the
140 > subsidiary companies who may be employing the technology.
141 >
142 > I've CC'd Bdale and Andrew on this. Responses and comments are very
143 > welcome.
144 >
145 >
146 > Cheers,
147 >
148 > ~/Chris
149 >
150
151 I've cc'd David Adams of Freescale, and Elizabeth (president of
152 Buffer Inc) as Buffer is a Design Alliance Partner with Freescale.
153
154
155 sincerely,
156 James && Elizabeth Horton.
157 (aka wireless@×××××××××××.com)
158
159
160 > wireless wrote:
161 >> Harald Schioeberg wrote:
162 >>>> There would also have to be an ACL (Access Control List) such
163 >>>> that I could regulate who gets access to these boards.
164 >>>> I could use some suggestions on iptables rules for this
165 >>>> (embedded) DMZ. I have spoken to several folks in the past that
166 >>>> have tried this, and maintaining security is always a challenge.
167 >>>> So a limited ACL in the beginning until the security mechanisms
168 >>>> mature, is a prudent step.
169 >>>
170 >>> Hi,
171 >>>
172 >>> here comes my experience with a similar configuration (not developers
173 >>> but students with root-privileges, even worse :))
174 >>>
175 >>> a stepping-stone host with ssh-logins for outside devs. this is the only
176 >>> system, that accepts connections from outside, the firewall blocks any
177 >>> attempt to connect to any embedded system directly. we even have our
178 >>> devices in a network with private ip-addresses, with no routing at all
179 >>> to or from the internet, the steppingstone has 2 nics, one with a public
180 >>> IP for ssh-login, and one with the private ip. it does NOT do any
181 >>> routing or NAT. the private IP-config will probably not work for you,
182 >>> because:
183 >>>
184 >>> the dev systems probably need outgoing http/ftp/rsync if not more. block
185 >>> smtp at all costs. if you need mail for debugging the embedded systems,
186 >>> configure your stepping-stone so that it accepts mails for your
187 >>> dns-zone, and delivers it locally, but do not forward any mail from the
188 >>> dev-dmz. if you only want to support one system (say gentoo) you might
189 >>> get along with a local gentoo-mirror, but development is really
190 >>> cumbersome if people don't have http/ftp access do download some patches
191 >>> or whatever. people will start to build ssh-portforwards if you are too
192 >>> restrictive and that kills any firewall.
193 >>>
194 >>> you need ip-switchable powersupply for all dev-systems, these things
195 >>> will crash and the users need a way to reboot them remotly.
196 >>> (afair ~300 Euro per 8 devices)
197 >>> see that you get some with snmp support, then you can write a small tool
198 >>> that checks against the acl before it reboots the device.
199 >>>
200 >>> you need a serial connection to each dev-system. we use terminal-servers
201 >>> for that purpose. make sure you can break a serial login, users will
202 >>> forget to log out and block the serial port forever. again, see for snmp
203 >>> support for that purpose.
204 >>> (terminal-servers are really expensive, about 150 Euro per port, but you
205 >>> can use a pc with lots of ports, and use a serial-to-network daemon)
206 >>>
207 >>> if multiple devs should be able to share a device, you need some kind of
208 >>> a reservation system. We started with a wiki, where everyone entered the
209 >>> devices that he wants to book in a table. that worked amazingly well.
210 >>> now we have switched to a sql-db, with allows us to restrict the logins
211 >>> on the devices to that devices, that the user has actually reserved. the
212 >>> most important thing is that never 2 independant users access the device
213 >>> at the same time if they want to do things like system configuration
214 >>> things...
215 >>>
216 >>> we provide our users with a tftp-server, that has a writeable directory
217 >>> for each stepping-stone-user. it is planned to allow the users to
218 >>> specify a config-snippet for the dhcpd (again, only for such system that
219 >>> the user has reserved in the db), when this is done there will be
220 >>> everything a user needs to boot any arbitary system on the device (if
221 >>> the device is netboot-enabled)
222 >>>
223 >>> hope that gives you some ideas,
224 >>> harald
225 >>
226 >> Hello Harald,
227 >>
228 >> This is a wonderful architecture, although I suspect it will take
229 >> me some time to get things together. I should like to start off
230 >> with a custom firewall.
231 >>
232 >> Currently we only have a single static IP, so I'll have to stick
233 >> to the four nic (2 DMZs) for now until we add some more
234 >> static/routable IPs. Give me a little time to get
235 >> organized.
236 >>
237 >> sincerely,
238 >>
239 >> James
240 >>
241 >
242 > Mike Frysinger wrote:
243 >> > On Friday 21 July 2006 17:03, Christopher Friedt wrote:
244 >>> >>Is there a published list of boards and their status for embedded
245 > gentoo?
246 >
247 >> > we dont support boards at the moment, just architectures
248 >> > getting a bsp up and running is left as an exercise for the end
249 > user ;)
250 >
251 >>> >>Would anyone be interested in polishing up a gentoo embedded port onto
252 >>> >>that platform with me?
253 >
254 >> > WRT54G ? that's mipsel right ? we've got mipsel/uclibc and
255 > mipsel/glibc
256 >> > running ...
257 >
258 >>> >>Has anyone published a list of minimum or suggested specs for
259 > devices in
260 >>> >>terms of ram / flash ?
261 >
262 >> > again, see previous comment ...
263 >
264 >> > as you can see, Gentoo/embedded is at the 'for developers' stage ...
265 > it could
266 >> > use a lot of work before being ready 'for users' and doing mini bsp
267 > releases
268 >> > for like the nslu2/wrt54g/what-have-you ... if you really feel like
269 > getting
270 >> > down and dirty, this is an area that is wide open at the moment ;)
271 >> > -mike
272 >
273 >
274 > Well, I agree, all of this is a good idea and 'wide open'. I'm in
275 > the process of customizing a firewall, with several DMZs to put
276 > up embedded systems for outside developers to access and control
277 > various mechanical and imaging systems.
278 >
279 > I have an old TS-5500, based on AMD 133 MHz 586 PCMCIA, which
280 > is available. Besides using an x86 for a baseline, as an intro
281 > SBC to embedded gentoo, would ease the transition from
282 > workstation/server gentoo to embedded gentoo. After folks get use
283 > to embedded gentoo on an x86 platform, then they can diverge into
284 > a second embedded platform (arm, mips, sh, blackfin, ppc).....
285 > Softening the upward migration path to so that other can
286 > migrate to embedded gentoo contributors is a good idea.
287 >
288 > I'd be receptive to purchasing/hosting several systems in this
289 > (embedded)DMZ for folks to play with, especially if there is a
290 > 'turnkey' packaging where all I have to do is re-flash a SD/CF
291 > card, modify configs and boot up the system, in the event
292 > something goes wrong.
293 >
294 > There would also have to be an ACL (Access Control List) such
295 > that I could regulate who gets access to these boards.
296 > I could use some suggestions on iptables rules for this
297 > (embedded) DMZ. I have spoken to several folks in the past that
298 > have tried this, and maintaining security is always a challenge.
299 > So a limited ACL in the beginning until the security mechanisms
300 > mature, is a prudent step.
301 >
302 >
303 > thoughts?
304 >
305 > James
306 >
307 >
308
309 --
310 gentoo-embedded@g.o mailing list