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 |