[gentoo-embedded] Help wanted

[gentoo-embedded] Help wanted

[Jakub Ladman]

Hi anybody, who could help me.
I realy need a terminal for a serial ports with hardware handshaking.
I know minicom only for this purposes, but i am not able to build it for sh4 
cpu.

Do you know anything, what can help me?
Do you have minicom binary built for sh4 ang uclibc library?
Do you have any other terminal application.

I am like handless without it.

Thank you

Jakub Ladman
-- 
gentoo-embedded@gentoo.org mailing list

Re: [gentoo-embedded] list of devices / boards, subprojects for each?

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 915 bytes --]

On Friday 21 July 2006 17:03, Christopher Friedt wrote:
> Is there a published list of boards and their status for embedded gentoo?

we dont support boards at the moment, just architectures

getting a bsp up and running is left as an exercise for the end user ;)

> Would anyone be interested in polishing up a gentoo embedded port onto
> that platform with me?

WRT54G ?  that's mipsel right ?  we've got mipsel/uclibc and mipsel/glibc 
running ...

> Has anyone published a list of minimum or suggested specs for devices in
> terms of ram / flash ?

again, see previous comment ...

as you can see, Gentoo/embedded is at the 'for developers' stage ... it could 
use a lot of work before being ready 'for users' and doing mini bsp releases 
for like the nslu2/wrt54g/what-have-you ... if you really feel like getting 
down and dirty, this is an area that is wide open at the moment ;)
-mike

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-embedded] Help wanted

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 263 bytes --]

On Thursday 20 July 2006 12:06, Jakub Ladman wrote:
> I realy need a terminal for a serial ports with hardware handshaking.
> I know minicom only for this purposes, but i am not able to build it for
> sh4 cpu.

minicom cross builds for sh4 just fine for me
-mike

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-embedded] Help wanted

[Jakub Ladman]

Dne pátek 21 červenec 2006 07:42 Mike Frysinger napsal(a):
> On Thursday 20 July 2006 12:06, Jakub Ladman wrote:
> > I realy need a terminal for a serial ports with hardware handshaking.
> > I know minicom only for this purposes, but i am not able to build it for
> > sh4 cpu.
>
> minicom cross builds for sh4 just fine for me
> -mike

Tell me how to do it, please.

Jakub Ladman

-- 
gentoo-embedded@gentoo.org mailing list

Re: [gentoo-embedded] Help wanted

[Jakub Ladman]

[-- Attachment #1: Type: text/plain, Size: 1453 bytes --]

I am trying to buil minicom manually:

trotl minicom-2.1 # export CC="sh4-pc-linux-uclibc-gcc"
trotl minicom-2.1 # export ARCH=sh4
trotl minicom-2.1 # export CFLAGS="-Os -pipe -fPIC"
trotl minicom-2.1 # export LD="sh4-pc-linux-uclibc-ld"
trotl minicom-2.1 # export CXXFLAGS="${CFLAGS}"
trotl minicom-2.1 # export LDFLAGS="-L/var/sh4prj/lib -L/var/sh4prj/usr/lib"
trotl minicom-2.1 # export CBUILD=i686-pc-linux-gnu
trotl minicom-2.1 # export CHOST=sh4-pc-linux-uclibc
trotl minicom-2.1 # export CTARGET=sh4-pc-linux-uclibc
trotl minicom-2.1 # export CXX=sh4-pc-linux-uclibc-g++
trotl minicom-2.1 # ./configure --prefix=/var/sh4prj/usr/local --build=i686-pc-linux-gnu --host=sh4
trotl minicom-2.1 # make
trotl minicom-2.1 # make install

It completes without any errors, but:

trotl ladmanj # file /var/sh4prj/usr/local/bin/minicom
/var/sh4prj/usr/local/bin/minicom: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
trotl ladmanj #  

I am little bit agonized of it.

Jakub Ladman

Dne pátek 21 ?ervenec 2006 07:42 Mike Frysinger napsal(a):
> On Thursday 20 July 2006 12:06, Jakub Ladman wrote:
> > I realy need a terminal for a serial ports with hardware handshaking.
> > I know minicom only for this purposes, but i am not able to build it for
> > sh4 cpu.
>
> minicom cross builds for sh4 just fine for me
> -mike

[-- Attachment #2: Type: text/html, Size: 1899 bytes --]

Re: [gentoo-embedded] Help wanted

[Jakub Ladman]

It was bloody stupid mistake, i have make clean forgotten between incorrect 
and correct ./configure
Now the executable is built fine.
But a little problem remains with --prefix=...
A sh4 system root disk is nfs mounted my PC subdirectory /var/sh4prj
If i run ./configure with --prefix=/var/sh4prj/usr/local 
a binary searches config and other files at non-existent /var/sh4prj/usr/local 
directory.
Do you know, how to fix it? 
How to install into /var/sh4prj/usr/local, but set up-ed to /usr/local

Thank you
Jakub Ladman
Dne pátek 21 červenec 2006 11:27 Jakub Ladman napsal(a):
> I am trying to buil minicom manually:
>
> trotl minicom-2.1 # export CC="sh4-pc-linux-uclibc-gcc"
> trotl minicom-2.1 # export ARCH=sh4
> trotl minicom-2.1 # export CFLAGS="-Os -pipe -fPIC"
> trotl minicom-2.1 # export LD="sh4-pc-linux-uclibc-ld"
> trotl minicom-2.1 # export CXXFLAGS="${CFLAGS}"
> trotl minicom-2.1 # export LDFLAGS="-L/var/sh4prj/lib
> -L/var/sh4prj/usr/lib" trotl minicom-2.1 # export CBUILD=i686-pc-linux-gnu
> trotl minicom-2.1 # export CHOST=sh4-pc-linux-uclibc
> trotl minicom-2.1 # export CTARGET=sh4-pc-linux-uclibc
> trotl minicom-2.1 # export CXX=sh4-pc-linux-uclibc-g++
> trotl minicom-2.1 # ./configure --prefix=/var/sh4prj/usr/local
> --build=i686-pc-linux-gnu --host=sh4 trotl minicom-2.1 # make
> trotl minicom-2.1 # make install
>
> It completes without any errors, but:
>
> trotl ladmanj # file /var/sh4prj/usr/local/bin/minicom
> /var/sh4prj/usr/local/bin/minicom: ELF 32-bit LSB executable, Intel 80386,
> version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared
> libs), for GNU/Linux 2.6.9, not stripped trotl ladmanj #
>
> I am little bit agonized of it.
>
> Jakub Ladman
>
> Dne pátek 21 ?ervenec 2006 07:42 Mike Frysinger napsal(a):
> > On Thursday 20 July 2006 12:06, Jakub Ladman wrote:
> > > I realy need a terminal for a serial ports with hardware handshaking.
> > > I know minicom only for this purposes, but i am not able to build it
> > > for sh4 cpu.
> >
> > minicom cross builds for sh4 just fine for me
> > -mike

-- 
gentoo-embedded@gentoo.org mailing list

Re: [gentoo-embedded] Help wanted

[Anish Patel]

Jakub Ladman wrote:
> I am trying to buil minicom manually:
> 
> trotl minicom-2.1 # export CC="sh4-pc-linux-uclibc-gcc"
> trotl minicom-2.1 # export ARCH=sh4
> trotl minicom-2.1 # export CFLAGS="-Os -pipe -fPIC"
> trotl minicom-2.1 # export LD="sh4-pc-linux-uclibc-ld"
> trotl minicom-2.1 # export CXXFLAGS="${CFLAGS}"
> trotl minicom-2.1 # export LDFLAGS="-L/var/sh4prj/lib -L/var/sh4prj/usr/lib"
> trotl minicom-2.1 # export CBUILD=i686-pc-linux-gnu
> trotl minicom-2.1 # export CHOST=sh4-pc-linux-uclibc
> trotl minicom-2.1 # export CTARGET=sh4-pc-linux-uclibc
> trotl minicom-2.1 # export CXX=sh4-pc-linux-uclibc-g++
> trotl minicom-2.1 # ./configure --prefix=/var/sh4prj/usr/local --build=i686-pc-linux-gnu --host=sh4
> trotl minicom-2.1 # make
> trotl minicom-2.1 # make install
> 
> It completes without any errors, but:
> 
> trotl ladmanj # file /var/sh4prj/usr/local/bin/minicom
> /var/sh4prj/usr/local/bin/minicom: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
> trotl ladmanj #  
> 
> I am little bit agonized of it.
> 
> Jakub Ladman
> 
> Dne pátek 21 ?ervenec 2006 07:42 Mike Frysinger napsal(a):
>> On Thursday 20 July 2006 12:06, Jakub Ladman wrote:
>>> I realy need a terminal for a serial ports with hardware handshaking.
>>> I know minicom only for this purposes, but i am not able to build it for
>>> sh4 cpu.
>> minicom cross builds for sh4 just fine for me
>> -mike
> 
try using ./configure --target=sh4 and also put those CHOST and what 
nots with against the make, CC=$TARGET make, or edit the makefile to use 
your stuff.


-- 
gentoo-embedded@gentoo.org mailing list

Re: [gentoo-embedded] Help wanted

[Jakub Ladman]

Thanks to everyone.
My minicom is working now properly.
Jakub Ladman

Dne pátek 21 červenec 2006 15:04 Anish Patel napsal(a):
> Jakub Ladman wrote:
> > I am trying to buil minicom manually:
> >
> > trotl minicom-2.1 # export CC="sh4-pc-linux-uclibc-gcc"
> > trotl minicom-2.1 # export ARCH=sh4
> > trotl minicom-2.1 # export CFLAGS="-Os -pipe -fPIC"
> > trotl minicom-2.1 # export LD="sh4-pc-linux-uclibc-ld"
> > trotl minicom-2.1 # export CXXFLAGS="${CFLAGS}"
> > trotl minicom-2.1 # export LDFLAGS="-L/var/sh4prj/lib
> > -L/var/sh4prj/usr/lib" trotl minicom-2.1 # export
> > CBUILD=i686-pc-linux-gnu
> > trotl minicom-2.1 # export CHOST=sh4-pc-linux-uclibc
> > trotl minicom-2.1 # export CTARGET=sh4-pc-linux-uclibc
> > trotl minicom-2.1 # export CXX=sh4-pc-linux-uclibc-g++
> > trotl minicom-2.1 # ./configure --prefix=/var/sh4prj/usr/local
> > --build=i686-pc-linux-gnu --host=sh4 trotl minicom-2.1 # make
> > trotl minicom-2.1 # make install
> >
> > It completes without any errors, but:
> >
> > trotl ladmanj # file /var/sh4prj/usr/local/bin/minicom
> > /var/sh4prj/usr/local/bin/minicom: ELF 32-bit LSB executable, Intel
> > 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses
> > shared libs), for GNU/Linux 2.6.9, not stripped trotl ladmanj #
> >
> > I am little bit agonized of it.
> >
> > Jakub Ladman
> >
> > Dne pátek 21 ?ervenec 2006 07:42 Mike Frysinger napsal(a):
> >> On Thursday 20 July 2006 12:06, Jakub Ladman wrote:
> >>> I realy need a terminal for a serial ports with hardware handshaking.
> >>> I know minicom only for this purposes, but i am not able to build it
> >>> for sh4 cpu.
> >>
> >> minicom cross builds for sh4 just fine for me
> >> -mike
>
> try using ./configure --target=sh4 and also put those CHOST and what
> nots with against the make, CC=$TARGET make, or edit the makefile to use
> your stuff.

-- 
gentoo-embedded@gentoo.org mailing list

Re: [gentoo-embedded] list of devices / boards, subprojects for each?

[wireless]

Mike Frysinger wrote:
> On Friday 21 July 2006 17:03, Christopher Friedt wrote:
>>Is there a published list of boards and their status for embedded gentoo?

> we dont support boards at the moment, just architectures
> getting a bsp up and running is left as an exercise for the end user ;)

>>Would anyone be interested in polishing up a gentoo embedded port onto
>>that platform with me?

> WRT54G ?  that's mipsel right ?  we've got mipsel/uclibc and mipsel/glibc 
> running ...

>>Has anyone published a list of minimum or suggested specs for devices in
>>terms of ram / flash ?

> again, see previous comment ...

> as you can see, Gentoo/embedded is at the 'for developers' stage ... it could 
> use a lot of work before being ready 'for users' and doing mini bsp releases 
> for like the nslu2/wrt54g/what-have-you ... if you really feel like getting 
> down and dirty, this is an area that is wide open at the moment ;)
> -mike


Well, I agree, all of this is a good idea and 'wide open'. I'm in
the process of customizing a firewall, with several DMZs to put
up embedded systems for outside developers to access and control
various mechanical and imaging systems.

I have an old TS-5500, based on AMD 133 MHz 586 PCMCIA, which
is available. Besides using an x86 for a baseline, as an intro
SBC to embedded gentoo, would ease the transition from
workstation/server gentoo to embedded gentoo. After folks get use
to embedded gentoo on an x86 platform, then they can diverge into
a second embedded platform (arm, mips, sh, blackfin, ppc).....
Softening the upward migration path to so that other can
migrate to embedded gentoo contributors is a good idea.

I'd be receptive to purchasing/hosting several systems in this
(embedded)DMZ for folks to play with, especially if there is a
'turnkey' packaging where all I have to do is re-flash a SD/CF
card, modify configs and boot up the system, in the event
something goes wrong.

 There would also have to be an ACL (Access Control List) such
that I could regulate who gets access to these boards.
I could use some suggestions on iptables rules for this
(embedded) DMZ. I have spoken to several folks in the past that
have tried this, and maintaining security is always a challenge.
So a limited ACL in the beginning until the security mechanisms
mature, is a prudent step.


thoughts?

James
-- 
gentoo-embedded@gentoo.org mailing list

[gentoo-embedded] list of devices / boards, subprojects for each?

[Christopher Friedt]

Hello everyone,

Is there a published list of boards and their status for embedded gentoo?

Also, is there a sort of standard platform which is being used by most 
of you that is pretty cheaply available to all ? If not, i would suggest 
the linksys WRT54G or WRT54GL series of routers. They go for quite a 
cheap rate these days.

Would anyone be interested in polishing up a gentoo embedded port onto 
that platform with me?

My main platform aside from the router (which is more of a hobby) is the 
TS-7260 from www.embeddedarm.com . That one uses a debian-based linux, 
but I would much rather use a gentoo-based linux.

Has anyone published a list of minimum or suggested specs for devices in 
terms of ram / flash ?


~/Chris
-- 
gentoo-embedded@gentoo.org mailing list

Re: [gentoo-embedded] list of devices / boards, subprojects for each?

[Harald Schioeberg]

> 
>  There would also have to be an ACL (Access Control List) such
> that I could regulate who gets access to these boards.
> I could use some suggestions on iptables rules for this
> (embedded) DMZ. I have spoken to several folks in the past that
> have tried this, and maintaining security is always a challenge.
> So a limited ACL in the beginning until the security mechanisms
> mature, is a prudent step.

Hi,

here comes my experience with a similar configuration (not developers 
but students with root-privileges, even worse :))

a stepping-stone host with ssh-logins for outside devs. this is the only 
system, that accepts connections from outside, the firewall blocks any 
attempt to connect to any embedded system directly. we even have our 
devices in a network with private ip-addresses, with no routing at all 
to or from the internet, the steppingstone has 2 nics, one with a public 
IP for ssh-login, and one with the private ip. it does NOT do any 
routing or NAT. the private IP-config will probably not work for you, 
because:

the dev systems probably need outgoing http/ftp/rsync if not more. block 
smtp at all costs. if you need mail for debugging the embedded systems, 
configure your stepping-stone so that it accepts mails for your 
dns-zone, and delivers it locally, but do not forward any mail from the 
dev-dmz. if you only want to support one system (say gentoo) you might 
get along with a local gentoo-mirror, but development is really 
cumbersome if people don't have http/ftp access do download some patches 
or whatever. people will start to build ssh-portforwards if you are too 
restrictive and that kills any firewall.

you need ip-switchable powersupply for all dev-systems, these things 
will crash and the users need a way to reboot them remotly.
(afair ~300 Euro per 8 devices)
see that you get some with snmp support, then you can write a small tool 
that checks against the acl before it reboots the device.

you need a serial connection to each dev-system. we use terminal-servers 
  for that purpose. make sure you can break a serial login, users will 
forget to log out and block the serial port forever. again, see for snmp 
support for that purpose.
(terminal-servers are really expensive, about 150 Euro per port, but you 
can use a pc with lots of ports, and use a serial-to-network daemon)

if multiple devs should be able to share a device, you need some kind of 
a reservation system. We started with a wiki, where everyone entered the 
devices that he wants to book in a table. that worked amazingly well. 
now we have switched to a sql-db, with allows us to restrict the logins 
on the devices to that devices, that the user has actually reserved. the 
most important thing is that never 2 independant users access the device 
at the same time if they want to do things like system configuration 
things...

we provide our users with a tftp-server, that has a writeable directory 
for each stepping-stone-user. it is planned to allow the users to 
specify a config-snippet for the dhcpd (again, only for such system that 
the user has reserved in the db), when this is done there will be 
everything a user needs to boot any arbitary system on the device (if 
the device is netboot-enabled)

hope that gives you some ideas,
	harald
-- 
gentoo-embedded@gentoo.org mailing list

Re: [gentoo-embedded] list of devices / boards, subprojects for each?

[wireless]

Harald Schioeberg wrote:
> 
>>
>>  There would also have to be an ACL (Access Control List) such
>> that I could regulate who gets access to these boards.
>> I could use some suggestions on iptables rules for this
>> (embedded) DMZ. I have spoken to several folks in the past that
>> have tried this, and maintaining security is always a challenge.
>> So a limited ACL in the beginning until the security mechanisms
>> mature, is a prudent step.
> 
> 
> Hi,
> 
> here comes my experience with a similar configuration (not developers
> but students with root-privileges, even worse :))
> 
> a stepping-stone host with ssh-logins for outside devs. this is the only
> system, that accepts connections from outside, the firewall blocks any
> attempt to connect to any embedded system directly. we even have our
> devices in a network with private ip-addresses, with no routing at all
> to or from the internet, the steppingstone has 2 nics, one with a public
> IP for ssh-login, and one with the private ip. it does NOT do any
> routing or NAT. the private IP-config will probably not work for you,
> because:
> 
> the dev systems probably need outgoing http/ftp/rsync if not more. block
> smtp at all costs. if you need mail for debugging the embedded systems,
> configure your stepping-stone so that it accepts mails for your
> dns-zone, and delivers it locally, but do not forward any mail from the
> dev-dmz. if you only want to support one system (say gentoo) you might
> get along with a local gentoo-mirror, but development is really
> cumbersome if people don't have http/ftp access do download some patches
> or whatever. people will start to build ssh-portforwards if you are too
> restrictive and that kills any firewall.
> 
> you need ip-switchable powersupply for all dev-systems, these things
> will crash and the users need a way to reboot them remotly.
> (afair ~300 Euro per 8 devices)
> see that you get some with snmp support, then you can write a small tool
> that checks against the acl before it reboots the device.
> 
> you need a serial connection to each dev-system. we use terminal-servers
>  for that purpose. make sure you can break a serial login, users will
> forget to log out and block the serial port forever. again, see for snmp
> support for that purpose.
> (terminal-servers are really expensive, about 150 Euro per port, but you
> can use a pc with lots of ports, and use a serial-to-network daemon)
> 
> if multiple devs should be able to share a device, you need some kind of
> a reservation system. We started with a wiki, where everyone entered the
> devices that he wants to book in a table. that worked amazingly well.
> now we have switched to a sql-db, with allows us to restrict the logins
> on the devices to that devices, that the user has actually reserved. the
> most important thing is that never 2 independant users access the device
> at the same time if they want to do things like system configuration
> things...
> 
> we provide our users with a tftp-server, that has a writeable directory
> for each stepping-stone-user. it is planned to allow the users to
> specify a config-snippet for the dhcpd (again, only for such system that
> the user has reserved in the db), when this is done there will be
> everything a user needs to boot any arbitary system on the device (if
> the device is netboot-enabled)
> 
> hope that gives you some ideas,
>     harald

Hello Harald,

This is a wonderful architecture, although I suspect it will take
me some time to get things together.  I should like to start off
with a custom  firewall.

Currently we only have a single static IP, so I'll have to stick
to the four nic (2 DMZs) for now until we add some more
static/routable IPs.  Give me a little time to get
organized.

sincerely,

James

-- 
gentoo-embedded@gentoo.org mailing list

Re: [gentoo-embedded] list of devices / boards, subprojects for each?

[Christopher Friedt]

Hello Harald, Mike et al,

I'm hearing excellent ideas here. My first conception was to just have 
individuals responsible for their various boards with collaboration on a 
common platform, but to have a terminal server for other gentoo-embedded 
developers is also a fantastic idea. This would facilitate svn firmware 
images / filesystems, etc.

The reason I believe that gentoo would be a great choice for embedded 
linux is purely for 2 reasons:

1) portage - an incredibly versatile solution to package management
2) a highly 'emergant' user / developer / bugfix base

Obviously the developers in gentoo-embedded would prefer to have portage 
as the primary (only) package management system for gentoo-embedded - 
that only makes logical sense.

However, there is also an important underlying issue here - whether the 
embedded device is Gentoo-based, Debian-based, or RedHat-based, there is 
still a need for a standardized embedded device architecture both in 
software and hardware.

Some related notes from my most recent Linux World Expo visit in Toronto:

I have spoken to Bdale Garbee, CT Open Source & Linux for HP on a 
similar topic. I asked him if HP would be interested in supporting a 
sort of 'summer of embedded code' for embedded Linux. He mentioned that 
he and HP would be interested in 'facilitating' more research into 
embedded standards, both hardware and software, since HP uses Linux 
exclusively for most of their products that have a processor network 
device built into them (aside from the iPaq ... sigh).

Another business card that I acquired was from Andrew Overholt at 
RedHat. He has helped out considerably with the CDT / Eclipse project. 
If anyone here has used Eclipse, I'm sure you would agree that it 
provides an excellent and freely available platform for code as well as 
  management. My opinion is that the management side of something on 
this scale is almost as important as the code itself, and if that 
platform can be standardized for embedded developers the world would 
literally be our oyster.

These two potentials could not only improve the state of embedded 
development but also prove reasonably profitable for all parties 
involved, including Gentoo, RedHat, and HP, besides all of the 
subsidiary companies who may be employing the technology.

I've CC'd Bdale and Andrew on this. Responses and comments are very welcome.


Cheers,

~/Chris




wireless wrote:
 > Harald Schioeberg wrote:
 >>>  There would also have to be an ACL (Access Control List) such
 >>> that I could regulate who gets access to these boards.
 >>> I could use some suggestions on iptables rules for this
 >>> (embedded) DMZ. I have spoken to several folks in the past that
 >>> have tried this, and maintaining security is always a challenge.
 >>> So a limited ACL in the beginning until the security mechanisms
 >>> mature, is a prudent step.
 >>
 >> Hi,
 >>
 >> here comes my experience with a similar configuration (not developers
 >> but students with root-privileges, even worse :))
 >>
 >> a stepping-stone host with ssh-logins for outside devs. this is the only
 >> system, that accepts connections from outside, the firewall blocks any
 >> attempt to connect to any embedded system directly. we even have our
 >> devices in a network with private ip-addresses, with no routing at all
 >> to or from the internet, the steppingstone has 2 nics, one with a public
 >> IP for ssh-login, and one with the private ip. it does NOT do any
 >> routing or NAT. the private IP-config will probably not work for you,
 >> because:
 >>
 >> the dev systems probably need outgoing http/ftp/rsync if not more. block
 >> smtp at all costs. if you need mail for debugging the embedded systems,
 >> configure your stepping-stone so that it accepts mails for your
 >> dns-zone, and delivers it locally, but do not forward any mail from the
 >> dev-dmz. if you only want to support one system (say gentoo) you might
 >> get along with a local gentoo-mirror, but development is really
 >> cumbersome if people don't have http/ftp access do download some patches
 >> or whatever. people will start to build ssh-portforwards if you are too
 >> restrictive and that kills any firewall.
 >>
 >> you need ip-switchable powersupply for all dev-systems, these things
 >> will crash and the users need a way to reboot them remotly.
 >> (afair ~300 Euro per 8 devices)
 >> see that you get some with snmp support, then you can write a small tool
 >> that checks against the acl before it reboots the device.
 >>
 >> you need a serial connection to each dev-system. we use terminal-servers
 >>  for that purpose. make sure you can break a serial login, users will
 >> forget to log out and block the serial port forever. again, see for snmp
 >> support for that purpose.
 >> (terminal-servers are really expensive, about 150 Euro per port, but you
 >> can use a pc with lots of ports, and use a serial-to-network daemon)
 >>
 >> if multiple devs should be able to share a device, you need some kind of
 >> a reservation system. We started with a wiki, where everyone entered the
 >> devices that he wants to book in a table. that worked amazingly well.
 >> now we have switched to a sql-db, with allows us to restrict the logins
 >> on the devices to that devices, that the user has actually reserved. the
 >> most important thing is that never 2 independant users access the device
 >> at the same time if they want to do things like system configuration
 >> things...
 >>
 >> we provide our users with a tftp-server, that has a writeable directory
 >> for each stepping-stone-user. it is planned to allow the users to
 >> specify a config-snippet for the dhcpd (again, only for such system that
 >> the user has reserved in the db), when this is done there will be
 >> everything a user needs to boot any arbitary system on the device (if
 >> the device is netboot-enabled)
 >>
 >> hope that gives you some ideas,
 >>     harald
 >
 > Hello Harald,
 >
 > This is a wonderful architecture, although I suspect it will take
 > me some time to get things together.  I should like to start off
 > with a custom  firewall.
 >
 > Currently we only have a single static IP, so I'll have to stick
 > to the four nic (2 DMZs) for now until we add some more
 > static/routable IPs.  Give me a little time to get
 > organized.
 >
 > sincerely,
 >
 > James
 >

Mike Frysinger wrote:
 > > On Friday 21 July 2006 17:03, Christopher Friedt wrote:
 >> >>Is there a published list of boards and their status for embedded 
gentoo?

 > > we dont support boards at the moment, just architectures
 > > getting a bsp up and running is left as an exercise for the end 
user  ;)

 >> >>Would anyone be interested in polishing up a gentoo embedded port onto
 >> >>that platform with me?

 > > WRT54G ?  that's mipsel right ?  we've got mipsel/uclibc and 
mipsel/glibc
 > > running ...

 >> >>Has anyone published a list of minimum or suggested specs for 
devices in
 >> >>terms of ram / flash ?

 > > again, see previous comment ...

 > > as you can see, Gentoo/embedded is at the 'for developers' stage 
... it could
 > > use a lot of work before being ready 'for users' and doing mini bsp 
releases
 > > for like the nslu2/wrt54g/what-have-you ... if you really feel like 
getting
 > > down and dirty, this is an area that is wide open at the moment  ;)
 > > -mike


Well, I agree, all of this is a good idea and 'wide open'. I'm in
the process of customizing a firewall, with several DMZs to put
up embedded systems for outside developers to access and control
various mechanical and imaging systems.

I have an old TS-5500, based on AMD 133 MHz 586 PCMCIA, which
is available. Besides using an x86 for a baseline, as an intro
SBC to embedded gentoo, would ease the transition from
workstation/server gentoo to embedded gentoo. After folks get use
to embedded gentoo on an x86 platform, then they can diverge into
a second embedded platform (arm, mips, sh, blackfin, ppc).....
Softening the upward migration path to so that other can
migrate to embedded gentoo contributors is a good idea.

I'd be receptive to purchasing/hosting several systems in this
(embedded)DMZ for folks to play with, especially if there is a
'turnkey' packaging where all I have to do is re-flash a SD/CF
card, modify configs and boot up the system, in the event
something goes wrong.

  There would also have to be an ACL (Access Control List) such
that I could regulate who gets access to these boards.
I could use some suggestions on iptables rules for this
(embedded) DMZ. I have spoken to several folks in the past that
have tried this, and maintaining security is always a challenge.
So a limited ACL in the beginning until the security mechanisms
mature, is a prudent step.


thoughts?

James


-- 
gentoo-embedded@gentoo.org mailing list

Re: [gentoo-embedded] list of devices / boards, subprojects for each?

[wireless]

Christopher Friedt wrote:
> Hello Harald, Mike et al,

Hello David, Bdale, Andrew et. al.,


Well sorry for the delay, I just got back from the Freescale
(PPC , i.MX, Coldfire) conference in Orlando. WHAT A BLAST,
Embedded Linux everywhere, Lots of folks that love all aspects of
Linux, fantastic food, a wonderful presentation by  Neil
Armstrong and a private concert for 2000 linux enthusiast at the
Hard Rock Cafe (food and drinks) while watching '3 Doors Down'.
You'll have excuse my exuberance, but, it was one ass_kicking
time! I felt like a teenager again.....

If anyone questions the vitality of the PPC or any other
FreeScale processor lines, they should attend the FTF next year:
http://www.freescale.com/webapp/sps/site/homepage.jsp?nodeId=0525779036

Genesi won an award with embedded gentoo and a 7.1 surround
system implementation, at last year's show:

http://www.genesippc.com/press.php?date=20050624

> I'm hearing excellent ideas here. My first conception was to just have
> individuals responsible for their various boards with collaboration on a
> common platform, but to have a terminal server for other gentoo-embedded
> developers is also a fantastic idea. This would facilitate svn firmware
> images / filesystems, etc.

Sounds good. Some of my interest are a bit more aggressive: Real
time(SCADA) controls of actual hardware combined with streaming
video, Some 8/16  bit processors running state-machines with
minimalistic tcp/ip stacks, testing custom(fast)
bootloaders...... for sure embedded (gentoo) would be at the core
of our site, but augmented with other aspects of traditional
embedded systems development. Building a bridge to all of those
legacy embedded developers is as important as getting the
tech-kids of tomorrow hooked on embedded gentoo, methinks.


> The reason I believe that gentoo would be a great choice for embedded
> linux is purely for 2 reasons:

> 1) portage - an incredibly versatile solution to package management
> 2) a highly 'emergant' user / developer / bugfix base

> Obviously the developers in gentoo-embedded would prefer to have portage
> as the primary (only) package management system for gentoo-embedded -
> that only makes logical sense.

There are too many virtues of embedded gentoo to list at this
time. Suffice it to say that anyone technical who spends a little
time with gentoo, quickly develops their list of favorite features.


> However, there is also an important underlying issue here - whether the
> embedded device is Gentoo-based, Debian-based, or RedHat-based, there is
> still a need for a standardized embedded device architecture both in
> software and hardware.

I like the standardized approach. It would be nice to have a
security mechanism in place for various sites to host embedded
gentoo systems and use somewhat similar security approaches to
'ease the effort/pain' of keeping these embedded development
sites functional, yet secure. If we do not keep these development
sites secure, we are going to spend a lot of time on the phone
explaining what's going on to our bandwidth suppliers.......

Vapier (Mike) has an excellent site, that only needs some
modifications to begin using as a template. My thoughts are (4)
NICS: INTERNET, LAN, DMZ, DMZ-EMBEDDED with the forth being for
the  collection of (embedded) targets and the terminal server. If
it's cookie-cutter, then lots of folks could be encouraged to
quickly to set up a few boards on the net. This in turn would
encourage lots of local groups to become a visible presence for
the communities in which they live (reducing latencies etc etc).

http://www.gentoo.org/doc/en/home-router-howto.xml

The use of raw iptables/netfilter scriptable commands on a
firewall   that allows a site to  put embedded development
systems up on the net, will also serve as an excellent teaching
platform to secure the myriad of embedded gentoo devices that
will appear in the near future. Many embedded products that now
have an ethernet interface, lack robust security.

> Some related notes from my most recent Linux World Expo visit in Toronto:

> I have spoken to Bdale Garbee, CT Open Source & Linux for HP on a
> similar topic. I asked him if HP would be interested in supporting a
> sort of 'summer of embedded code' for embedded Linux. He mentioned that
> he and HP would be interested in 'facilitating' more research into
> embedded standards, both hardware and software, since HP uses Linux
> exclusively for most of their products that have a processor network
> device built into them (aside from the iPaq ... sigh).

The approach I have suggested would greatly facilitate a proposed
'summer of embedded code' and align mentors at the various host
sites with those aspiring embedded gentoo minds......

As mike indicated board level support is still lacking from
embedded-gentoo. However, it would be possible, in time for some
of the online embedded gentoo development sites to support board
level packages as a starting point for board level support.
Certainly, we would be willing to consult with FreeScale and
select a few boards to package up with embedded gentoo. Any
specific requests from the gentoo-embedded community for BSP
using embedded gentoo? Freescale promote the usage of an open
source tool for setting up new embedded targets, call 'ltib'.

http://www.bitshrine.org/
http://savannah.nongnu.org/projects/ltib/


The only downfall I see is that it does not (yet) support ebuilds
directly......only rpms.

Freescale has gone full-tilt into supporting and encouraging the
use of embedded linux. It is their design reference platform of
choice. Embedded gentoo was only mentioned on a few slides, but,
I'm quite certain embedded gentoo will impress the folks at
Freescale. We're already deep into planing a presentation for the
FTF in Orlando next summer. I would be quite surprised if
FreeScale does not get fully behind these ideas.


> Another business card that I acquired was from Andrew Overholt at
> RedHat. He has helped out considerably with the CDT / Eclipse project.
> If anyone here has used Eclipse, I'm sure you would agree that it
> provides an excellent and freely available platform for code as well as
>  management. My opinion is that the management side of something on this
> scale is almost as important as the code itself, and if that platform
> can be standardized for embedded developers the world would literally be
> our oyster.

> These two potentials could not only improve the state of embedded
> development but also prove reasonably profitable for all parties
> involved, including Gentoo, RedHat, and HP, besides all of the
> subsidiary companies who may be employing the technology.
> 
> I've CC'd Bdale and Andrew on this. Responses and comments are very
> welcome.
> 
> 
> Cheers,
> 
> ~/Chris
> 

I've cc'd David Adams  of Freescale, and Elizabeth (president of
Buffer Inc) as Buffer is a Design Alliance Partner with Freescale.


sincerely,
James && Elizabeth Horton.
(aka wireless@tampabay.rr.com)


> wireless wrote:
>> Harald Schioeberg wrote:
>>>>  There would also have to be an ACL (Access Control List) such
>>>> that I could regulate who gets access to these boards.
>>>> I could use some suggestions on iptables rules for this
>>>> (embedded) DMZ. I have spoken to several folks in the past that
>>>> have tried this, and maintaining security is always a challenge.
>>>> So a limited ACL in the beginning until the security mechanisms
>>>> mature, is a prudent step.
>>>
>>> Hi,
>>>
>>> here comes my experience with a similar configuration (not developers
>>> but students with root-privileges, even worse :))
>>>
>>> a stepping-stone host with ssh-logins for outside devs. this is the only
>>> system, that accepts connections from outside, the firewall blocks any
>>> attempt to connect to any embedded system directly. we even have our
>>> devices in a network with private ip-addresses, with no routing at all
>>> to or from the internet, the steppingstone has 2 nics, one with a public
>>> IP for ssh-login, and one with the private ip. it does NOT do any
>>> routing or NAT. the private IP-config will probably not work for you,
>>> because:
>>>
>>> the dev systems probably need outgoing http/ftp/rsync if not more. block
>>> smtp at all costs. if you need mail for debugging the embedded systems,
>>> configure your stepping-stone so that it accepts mails for your
>>> dns-zone, and delivers it locally, but do not forward any mail from the
>>> dev-dmz. if you only want to support one system (say gentoo) you might
>>> get along with a local gentoo-mirror, but development is really
>>> cumbersome if people don't have http/ftp access do download some patches
>>> or whatever. people will start to build ssh-portforwards if you are too
>>> restrictive and that kills any firewall.
>>>
>>> you need ip-switchable powersupply for all dev-systems, these things
>>> will crash and the users need a way to reboot them remotly.
>>> (afair ~300 Euro per 8 devices)
>>> see that you get some with snmp support, then you can write a small tool
>>> that checks against the acl before it reboots the device.
>>>
>>> you need a serial connection to each dev-system. we use terminal-servers
>>>  for that purpose. make sure you can break a serial login, users will
>>> forget to log out and block the serial port forever. again, see for snmp
>>> support for that purpose.
>>> (terminal-servers are really expensive, about 150 Euro per port, but you
>>> can use a pc with lots of ports, and use a serial-to-network daemon)
>>>
>>> if multiple devs should be able to share a device, you need some kind of
>>> a reservation system. We started with a wiki, where everyone entered the
>>> devices that he wants to book in a table. that worked amazingly well.
>>> now we have switched to a sql-db, with allows us to restrict the logins
>>> on the devices to that devices, that the user has actually reserved. the
>>> most important thing is that never 2 independant users access the device
>>> at the same time if they want to do things like system configuration
>>> things...
>>>
>>> we provide our users with a tftp-server, that has a writeable directory
>>> for each stepping-stone-user. it is planned to allow the users to
>>> specify a config-snippet for the dhcpd (again, only for such system that
>>> the user has reserved in the db), when this is done there will be
>>> everything a user needs to boot any arbitary system on the device (if
>>> the device is netboot-enabled)
>>>
>>> hope that gives you some ideas,
>>>     harald
>>
>> Hello Harald,
>>
>> This is a wonderful architecture, although I suspect it will take
>> me some time to get things together.  I should like to start off
>> with a custom  firewall.
>>
>> Currently we only have a single static IP, so I'll have to stick
>> to the four nic (2 DMZs) for now until we add some more
>> static/routable IPs.  Give me a little time to get
>> organized.
>>
>> sincerely,
>>
>> James
>>
> 
> Mike Frysinger wrote:
>> > On Friday 21 July 2006 17:03, Christopher Friedt wrote:
>>> >>Is there a published list of boards and their status for embedded
> gentoo?
> 
>> > we dont support boards at the moment, just architectures
>> > getting a bsp up and running is left as an exercise for the end
> user  ;)
> 
>>> >>Would anyone be interested in polishing up a gentoo embedded port onto
>>> >>that platform with me?
> 
>> > WRT54G ?  that's mipsel right ?  we've got mipsel/uclibc and
> mipsel/glibc
>> > running ...
> 
>>> >>Has anyone published a list of minimum or suggested specs for
> devices in
>>> >>terms of ram / flash ?
> 
>> > again, see previous comment ...
> 
>> > as you can see, Gentoo/embedded is at the 'for developers' stage ...
> it could
>> > use a lot of work before being ready 'for users' and doing mini bsp
> releases
>> > for like the nslu2/wrt54g/what-have-you ... if you really feel like
> getting
>> > down and dirty, this is an area that is wide open at the moment  ;)
>> > -mike
> 
> 
> Well, I agree, all of this is a good idea and 'wide open'. I'm in
> the process of customizing a firewall, with several DMZs to put
> up embedded systems for outside developers to access and control
> various mechanical and imaging systems.
> 
> I have an old TS-5500, based on AMD 133 MHz 586 PCMCIA, which
> is available. Besides using an x86 for a baseline, as an intro
> SBC to embedded gentoo, would ease the transition from
> workstation/server gentoo to embedded gentoo. After folks get use
> to embedded gentoo on an x86 platform, then they can diverge into
> a second embedded platform (arm, mips, sh, blackfin, ppc).....
> Softening the upward migration path to so that other can
> migrate to embedded gentoo contributors is a good idea.
> 
> I'd be receptive to purchasing/hosting several systems in this
> (embedded)DMZ for folks to play with, especially if there is a
> 'turnkey' packaging where all I have to do is re-flash a SD/CF
> card, modify configs and boot up the system, in the event
> something goes wrong.
> 
>  There would also have to be an ACL (Access Control List) such
> that I could regulate who gets access to these boards.
> I could use some suggestions on iptables rules for this
> (embedded) DMZ. I have spoken to several folks in the past that
> have tried this, and maintaining security is always a challenge.
> So a limited ACL in the beginning until the security mechanisms
> mature, is a prudent step.
> 
> 
> thoughts?
> 
> James
> 
> 

-- 
gentoo-embedded@gentoo.org mailing list