optimal hardware design for an ARM9 based single board computer to work with existing linux drivers

optimal hardware design for an ARM9 based single board computer to work with existing linux drivers

[Stefan Schoenleitner]

Hi,

for my project I would like to design an ARM9 based single board computer (SBC)
using the cirrus logic EP9302 CPU:

http://www.cirrus.com/en/pubs/proDatasheet/EP9302_PP3.pdf
http://www.cirrus.com/en/pubs/manual/EP93xx_Users_Guide_UM1.pdf


My goal is to use existing linux drivers together with attached peripheral
hardware without having to patch the driver code.
For this reason I'm looking for the best way to hook up peripheral hardware to
the CPU so that the linux kernel can handle it.


Among other features the CPU has a SPI bus and a total of 27 GPIO pins.
Using bit-banging on some of the available GPIO pins the CPU can also do I2C
communication.
(AFAIK bit-banging I2C on GPIO pins is already suppored by the linux kernel.)

Peripheral hardware (e.g. some linux-supported bluetooth chipset) can be hooked
up to the CPU in the following ways:

	1) directly connect it to the CPU's GPIO pins
	2) connect it to the CPU's GPIO pins in a multiplexed way using a bus
	   switch
	3) hook it up to some existing serial bus (SPI or I2C)
	4) hook it up to some existing _external_ serial bus (USB, UART)
	5) connect it to GPIO pins of a linux-supported GPIO expander that can
	   be accessed over I2C


Now I would like to review the mentioned approaches:


1) directly connect it to the CPU's GPIO pins:

The CPU has 18 standard GPIO pins (usable for I/O) and 19 enhanched GPIO pins
which also have interrupt support.
Obviously, I do not wan't to use all of the available GPIO pins for peripheral
hardware.
Also, if we consider chipset configuration pins, the number of available CPU
GPIO pins would not suffice.
For this reason, IMHO a direct connection of peripheral hardware to the CPU's
GPIO pins is not a reasonable design decision.


2) connect it to the CPU's GPIO pins in a multiplexed way using a bus switch

This approach is similar to 1) except for the difference that the CPUs GPIO pins
are multiplexed using a bus switch.
Thus different peripheral chipsets could be accessed in the following way:

	1. address the according bus switch so that the CPU's required GPIO are
	   routed through to the chip we want to talk to
	2. communicate with the chip

Again to save GPIO pins, the various bus switches could be addressed over a
serial bus like I2C.
While this communication is certainly suitable for high-speed devices, it also
has the drawback that the CPU's GPIO lines need to be routed all over the PCB
(printed circuit board) to the different bus switches and from there to the
chips we want to talk to.
Since I plan to use low-speed devices only, I do not want to make the hardware
design too complex.
For this reason I'd rather not take this design decision.


3) hook it up to some existing serial bus (SPI or I2C)

If the peripheral hardware chipset has support for serial communication, this
would be the easiest way to go.
Since there's already linux support for SPI as well as for I2C I would like to
use this way of talking to low-speed hardware whenever possible.


4) hook it up to some existing _external_ serial bus (USB, UART)

The single board computer should have external connections to the "outside world".
One serial port should be used as serial console while the other one will be
used for something else.
The USB connectors should be usable to connect arbitrary devices which are
supported by the linux kernel (e.g. external harddisk, webcam, whatever ...).
Also, usually peripheral hardware chips do not support USB.
For this reason this approach will not be taken for peripheral hardware access.


5) connect it to GPIO pins of a linux-supported GPIO expander that can be
accessed over I2C

This is IMHO a very promising approach which also has been taken in various
other (linux-compatible) designs I found on the internet
(e.g. the "DaVinci prototyping board",
http://www.linuxdevices.com/news/NS2209350555.html).

The idea is to connect a GPIO expander to the CPU's I2C bus which provides a
number (i.e. 8, 16, ..) of freely usable GPIO pins.
These GPIO pins are then connected to the peripheral hardware.
The linux kernel already has support for various GPIO expanders like the PCA9539
(16 port) or the PCF8574 (8 port) chips.
As far as I read in the kernel documentation, the drivers transparently map
those GPIO pins to the GPIO interface of the linux kernel.
Thus, from a device driver perspective, it makes no difference whether a device
is connected to the CPU's "real" GPIO pins or to a GPIO expander chip which can
be accessed over thr I2C bus.

Another advantage is the simple circuit design: Instead of having to route a
complete parallel bus over the PCB, only the serial I2C bus has to be routed
from the CPU to the port expander.
From the port expander a rather short bus then goes to the low-speed chip we
want to talk to.

In my oppinion, from a hardware as well as from a software perspective, this is
the right way to go.





As we saw, from a software perspective, it doesn't seem to make a big difference
whether peripheral hardware is directly hooked up to the CPU's GPIO pins or
it is hooked up to GPIO expanders.


* However, if we look at existing device drivers, will it be possible to use
them with this setup without modification ?

* How will the kernel find devices attached to GPIO pins ?
(There's no way to scan the bus since the kernel doesn't know what and where
devices are attached to the GPIO pins, right ?)

* What would be the best way to attach peripheral hardware from a linux-kernel
perspective ?

* Can you suggest any embedded hardware design documentation that considers
linux compatibility ?


sincerly,
stefan

Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers

[Robert Schwebel]

On Sat, Jul 05, 2008 at 11:03:11AM +0200, Stefan Schoenleitner wrote:
> for my project I would like to design an ARM9 based single board
> computer (SBC) using the cirrus logic EP9302 CPU:

As far as I know, Cirrus has discontinued the EP93 processors. I
wouldn't base a new design on it any more.

rsc
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers

[Stefan Schoenleitner]

Robert Schwebel wrote:
> As far as I know, Cirrus has discontinued the EP93 processors. I
> wouldn't base a new design on it any more.
> 
> rsc

Where did you get your information from ?
As far as I know cirrus discontinued direct software support for the ARM line in
favour of third party software.
(It seems that they even had their own linux distribution which is now
discontinued.)

The chips are still produced and even new product lines seem to be released.

To quote one of the cirrus guys:
----------------------------------------------------------------------------------------
"It is not being discontinued. We just will not be supporting the OS's like
Wince and Linux anymore. The linux part is supported mostly by this forum and
OE, and the cirrus-linux mailing list.

We will not be moving the kernel port forward from the Cirrus side, however,
Lennert has a kernel port in the mainstream. someone could take up our patch and
add the final set of periferals.

So yes, you can still buy EP93XX and EP73XX chips. Dont worry, they aint going
anywhere anytime soon."
----------------------------------------------------------------------------------------
[http://arm.cirrus.com/forum/viewtopic.php?t=3442]


Currently I bought a EP9302 evaluation board from olimex
(http://www.olimex.com/dev/cs-e930x.html).

Since I havn't started designing the prototype yet, moving to another CPU won't
be much of a problem.

stefan

Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers

[Robert Schwebel]

On Sat, Jul 05, 2008 at 01:05:33PM +0200, Stefan Schoenleitner wrote:
> Where did you get your information from ?

Thought I had read something like that, but if they say so ...

> To quote one of the cirrus guys:
> ----------------------------------------------------------------------------------------
> "It is not being discontinued. We just will not be supporting the OS's
> like Wince and Linux anymore. The linux part is supported mostly by
> this forum and OE, and the cirrus-linux mailing list.

Has it been different in the past? Last time we had an EP93 project (has
been some time ago), the support for Maverick Crunch was horrible and
cirrus' effort to support Linux mainline was almost 0.

If you want to have something which has good community support, check
what the mainline Linux kernel supports and base your stuff on that.

rsc
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers

[Stefan Schoenleitner]

Robert Schwebel wrote:
> Has it been different in the past? Last time we had an EP93 project (has
> been some time ago), the support for Maverick Crunch was horrible and
> cirrus' effort to support Linux mainline was almost 0.
> 
> If you want to have something which has good community support, check
> what the mainline Linux kernel supports and base your stuff on that.
> 
> rsc


Sounds good to me.
I could still do some peripheral device driver development for the stuff I want
to attach on the EP3902 board I already bought and do some testing as well.
Can you suggest some specific CPU ?

Of course features like LAN, USB and such are nice to have, but they are not
required for my design.
Goals should rather be that the CPU is cheap, easy to get and one should be able
to solder it by hand (e.g. SMD paste and hot-air flow soldering).
For this reason BGA packages are not possible.


Anyway, back to my original question ?
What is the best way to attach peripheral hardware so that existing drivers in
the linux-kernel can be used without having to do a lot of patching ?
It would be great if one could just use I2C expanders to interface low-speed
devices and the device drivers will just work once they know where to find the
hardware.

One of the chips I want to talk to is a voice codec with
data-rates < 15kbytes/sec.

Due to the low data-rate this should work with I2C port expanders.
The other possibility would be to use a multiplexed parallel bus using bus-switches.

How would you hook up such hardware to the CPU ?
What can you suggest ?

Is there something like good documentation on how to attach hardware to an
embedded CPU so that the linux-kernel will work just fine with it ?

stefan

Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers

[Stefan Schoenleitner]

Robert Schwebel wrote:
> 
> If you want to have something which has good community support, check
> what the mainline Linux kernel supports and base your stuff on that.


What do you think of this board ?
http://www.olimex.com/dev/sam9-L9260.html

The CPU seems to have good linux support.

Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers

[Michelle Konzack]

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

Hallo Stefan,

Ich habe ein ähnliches project / I have a similar project.

Am 2008-07-05 11:03:11, schrieb Stefan Schoenleitner:
> Hi,
> 
> for my project I would like to design an ARM9 based single board computer (SBC)
> using the cirrus logic EP9302 CPU:
> 
> http://www.cirrus.com/en/pubs/proDatasheet/EP9302_PP3.pdf
> http://www.cirrus.com/en/pubs/manual/EP93xx_Users_Guide_UM1.pdf

Simpy forget it...  discontinued.
Cirrus does not recommend it for new designs.
Maybe you schould go with a Freescale.  (Me too)

> For this reason I'm looking for the best way to hook up peripheral hardware to
> the CPU so that the linux kernel can handle it.

Hehe me too

> Among other features the CPU has a SPI bus and a total of 27 GPIO pins.
> Using bit-banging on some of the available GPIO pins the CPU can also do I2C
> communication.
> (AFAIK bit-banging I2C on GPIO pins is already suppored by the linux kernel.)

I have tested bit-banging on a LH7A411 bit it eat up  CPU  time  as  the
hell.  I have attached an I²C-Master which do the stuff...  3.48€  and
the problem is history...

> 	1) directly connect it to the CPU's GPIO pins

This would be the fastestes method.

> 	2) connect it to the CPU's GPIO pins in a multiplexed way using a bus
> 	   switch
> 	3) hook it up to some existing serial bus (SPI or I2C)

Bluetooth over I2C? - Good luck.

> 	4) hook it up to some existing _external_ serial bus (USB, UART)

I am using for some devices the USB port on the CPU and  connected  a  7
port USB2.0 hub to it...  Not the best solution, but it works perfectly.

and of course, the the whole USB-Tree is  Linux-Supported.  No  need  to
reinvent the weel

> 4) hook it up to some existing _external_ serial bus (USB, UART)
> 
> The single board computer should have external connections to the "outside world".
> One serial port should be used as serial console while the other one will be
> used for something else.
> The USB connectors should be usable to connect arbitrary devices which are
> supported by the linux kernel (e.g. external harddisk, webcam, whatever ...).
> Also, usually peripheral hardware chips do not support USB.
> For this reason this approach will not be taken for peripheral hardware access.

How many USB Hosts does the Chip has exactly?

Maybe you could do the same as me with a 7-port USB 2.0 hub.

One of my Meto-Stations need MANY USB-Ports so I have connected a 4-port
hub to the LH7A411 and on the 4 ports of the 4-port hub again 4 USB Hubs
with 7 ports...

Now my Meto-Station has 28 USB ports availlable, supporting (in theorie)
version 2.0...  I have not found a solution less expensive as this one.

Now I can connect ANY hardware, like Bluetooth, WiFi, IR or what else to
it

> 5) connect it to GPIO pins of a linux-supported GPIO expander that can be
> accessed over I2C
> 
> This is IMHO a very promising approach which also has been taken in various
> other (linux-compatible) designs I found on the internet
> (e.g. the "DaVinci prototyping board",
> http://www.linuxdevices.com/news/NS2209350555.html).
> 
> The idea is to connect a GPIO expander to the CPU's I2C bus which provides a
> number (i.e. 8, 16, ..) of freely usable GPIO pins.

I have gotten some differenttypes from Philips/NXP, but currently I have
not found support in the Kernel except one (since 6 weeks?).

AFAIK there are some peoples working on it.

> These GPIO pins are then connected to the peripheral hardware.
> The linux kernel already has support for various GPIO expanders like the PCA9539
> (16 port) or the PCF8574 (8 port) chips.

This is the one I am currently using...  and it works very nice.

> As far as I read in the kernel documentation, the drivers transparently map
> those GPIO pins to the GPIO interface of the linux kernel.
> Thus, from a device driver perspective, it makes no difference whether a device
> is connected to the CPU's "real" GPIO pins or to a GPIO expander chip which can
> be accessed over thr I2C bus.

Right.

> Another advantage is the simple circuit design: Instead of having to route a
> complete parallel bus over the PCB, only the serial I2C bus has to be routed
> from the CPU to the port expander.

Be careful with the speed of the I²C bus.  If you use bit-banging,  you
can run into trouble.  bit-banging is realy only for very-cheep hardware
where you not realy care about timings...

> As we saw, from a software perspective, it doesn't seem to make a big difference
> whether peripheral hardware is directly hooked up to the CPU's GPIO pins or
> it is hooked up to GPIO expanders.

This is a good question.  Since I am beginning to go into this  business
(studied electronic for more then 13 years and was working  only  french
@army and have no experience in it)  your  questions  fit  100%  my  own
questions

> * However, if we look at existing device drivers, will it be possible to use
> them with this setup without modification ?
> 
> * How will the kernel find devices attached to GPIO pins ?
> (There's no way to scan the bus since the kernel doesn't know what and where
> devices are attached to the GPIO pins, right ?)

This is what I am asking me too...
I have tried to read the Kernel-Sources but...  HELL!!!

I am not a Kernel-Geek!

> * What would be the best way to attach peripheral hardware from a linux-kernel
> perspective ?

USB  ;-)

> * Can you suggest any embedded hardware design documentation that considers
> linux compatibility ?

Thanks, Greetings and nice Day/Evening
    Michelle Konzack
    Systemadministrator
    24V Electronic Engineer
    Tamay Dogan Network
    Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack   Apt. 917                  ICQ #328449886
+49/177/9351947    50, rue de Soultz         MSN LinuxMichi
+33/6/61925193     67100 Strasbourg/France   IRC #Debian (irc.icq.com)

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

Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers

[Michelle Konzack]

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

Am 2008-07-05 13:05:33, schrieb Stefan Schoenleitner:
> ----------------------------------------------------------------------------------------
> "It is not being discontinued. We just will not be supporting the OS's like
> Wince and Linux anymore. The linux part is supported mostly by this forum and
> OE, and the cirrus-linux mailing list.
> 
> We will not be moving the kernel port forward from the Cirrus side, however,
> Lennert has a kernel port in the mainstream. someone could take up our patch and
> add the final set of periferals.
> 
> So yes, you can still buy EP93XX and EP73XX chips. Dont worry, they aint going
> anywhere anytime soon."
> ----------------------------------------------------------------------------------------
> [http://arm.cirrus.com/forum/viewtopic.php?t=3442]

Das ist cool..  did'nt know since I have read other things.

Greetings
    Michelle Konzack
    Systemadministrator
    24V Electronic Engineer
    Tamay Dogan Network
    Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack   Apt. 917                  ICQ #328449886
+49/177/9351947    50, rue de Soultz         MSN LinuxMichi
+33/6/61925193     67100 Strasbourg/France   IRC #Debian (irc.icq.com)

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

Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers

[Michelle Konzack]

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

Hallo Stefan,

Am 2008-07-05 13:54:28, schrieb Stefan Schoenleitner:
> I could still do some peripheral device driver development for the stuff I want
> to attach on the EP3902 board I already bought and do some testing as well.
> Can you suggest some specific CPU ?
> 
> Of course features like LAN, USB and such are nice to have, but they are not
> required for my design.

Philips/NXP:  LH7A400/10/11

00 = I²C,...
10 = Ethetnet without CAN
11 = Ethernet, CAN, I²C,...

> Goals should rather be that the CPU is cheap, easy to get and one should be able
> to solder it by hand (e.g. SMD paste and hot-air flow soldering).
> For this reason BGA packages are not possible.

No InfraRed-Welding System available?

I have goten one from eBay AOYUE 710 which cost new 2000€, but on eBay
400€ + transport.

> Is there something like good documentation on how to attach hardware to an
> embedded CPU so that the linux-kernel will work just fine with it ?

Thanks, Greetings and nice Day/Evening
    Michelle Konzack
    Systemadministrator
    24V Electronic Engineer
    Tamay Dogan Network
    Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack   Apt. 917                  ICQ #328449886
+49/177/9351947    50, rue de Soultz         MSN LinuxMichi
+33/6/61925193     67100 Strasbourg/France   IRC #Debian (irc.icq.com)

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

Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers

[Andrés Calderón]

On Sat, Jul 5, 2008 at 4:03 AM, Stefan Schoenleitner
<dev.c0debabe@gmail.com> wrote:
> Hi,
>
> for my project I would like to design an ARM9 based single board computer (SBC)
> using the cirrus logic EP9302 CPU:
>

The AT91SAM9 family is a better choice[1], the ATMEL and community
support is great [2][3].
[1] http://www.atmel.com/dyn/products/devices.asp?family_id=605
[2] http://www.linux4sam.org
[3] http://maxim.org.za/at91_26.html

The AT91SAM9260  and the older AT91RM9200 is available in  TQFP208 package.
Both support SD Cards, Ethernet, USB, SPI,I2C, a lot of GPIOs... ADCs
only in the AT91SAM9260.

The at91 lacks of FPU, but the cirrus maverick crunch support is very poor.


> http://www.cirrus.com/en/pubs/proDatasheet/EP9302_PP3.pdf
> http://www.cirrus.com/en/pubs/manual/EP93xx_Users_Guide_UM1.pdf
>
>
> My goal is to use existing linux drivers together with attached peripheral
> hardware without having to patch the driver code.
> For this reason I'm looking for the best way to hook up peripheral hardware to
> the CPU so that the linux kernel can handle it.
>
>
> Among other features the CPU has a SPI bus and a total of 27 GPIO pins.
> Using bit-banging on some of the available GPIO pins the CPU can also do I2C
> communication.
> (AFAIK bit-banging I2C on GPIO pins is already suppored by the linux kernel.)
>
> Peripheral hardware (e.g. some linux-supported bluetooth chipset) can be hooked
> up to the CPU in the following ways:
>
>        1) directly connect it to the CPU's GPIO pins
>        2) connect it to the CPU's GPIO pins in a multiplexed way using a bus
>           switch
>        3) hook it up to some existing serial bus (SPI or I2C)
>        4) hook it up to some existing _external_ serial bus (USB, UART)
>        5) connect it to GPIO pins of a linux-supported GPIO expander that can
>           be accessed over I2C
>
>
> Now I would like to review the mentioned approaches:
>
>
> 1) directly connect it to the CPU's GPIO pins:
>
> The CPU has 18 standard GPIO pins (usable for I/O) and 19 enhanched GPIO pins
> which also have interrupt support.
> Obviously, I do not wan't to use all of the available GPIO pins for peripheral
> hardware.
> Also, if we consider chipset configuration pins, the number of available CPU
> GPIO pins would not suffice.
> For this reason, IMHO a direct connection of peripheral hardware to the CPU's
> GPIO pins is not a reasonable design decision.
>
>
> 2) connect it to the CPU's GPIO pins in a multiplexed way using a bus switch
>
> This approach is similar to 1) except for the difference that the CPUs GPIO pins
> are multiplexed using a bus switch.
> Thus different peripheral chipsets could be accessed in the following way:
>
>        1. address the according bus switch so that the CPU's required GPIO are
>           routed through to the chip we want to talk to
>        2. communicate with the chip
>
> Again to save GPIO pins, the various bus switches could be addressed over a
> serial bus like I2C.
> While this communication is certainly suitable for high-speed devices, it also
> has the drawback that the CPU's GPIO lines need to be routed all over the PCB
> (printed circuit board) to the different bus switches and from there to the
> chips we want to talk to.
> Since I plan to use low-speed devices only, I do not want to make the hardware
> design too complex.
> For this reason I'd rather not take this design decision.
>
>
> 3) hook it up to some existing serial bus (SPI or I2C)
>
> If the peripheral hardware chipset has support for serial communication, this
> would be the easiest way to go.
> Since there's already linux support for SPI as well as for I2C I would like to
> use this way of talking to low-speed hardware whenever possible.
>
>
> 4) hook it up to some existing _external_ serial bus (USB, UART)
>
> The single board computer should have external connections to the "outside world".
> One serial port should be used as serial console while the other one will be
> used for something else.
> The USB connectors should be usable to connect arbitrary devices which are
> supported by the linux kernel (e.g. external harddisk, webcam, whatever ...).
> Also, usually peripheral hardware chips do not support USB.
> For this reason this approach will not be taken for peripheral hardware access.
>
>
> 5) connect it to GPIO pins of a linux-supported GPIO expander that can be
> accessed over I2C
>
> This is IMHO a very promising approach which also has been taken in various
> other (linux-compatible) designs I found on the internet
> (e.g. the "DaVinci prototyping board",
> http://www.linuxdevices.com/news/NS2209350555.html).
>
> The idea is to connect a GPIO expander to the CPU's I2C bus which provides a
> number (i.e. 8, 16, ..) of freely usable GPIO pins.
> These GPIO pins are then connected to the peripheral hardware.
> The linux kernel already has support for various GPIO expanders like the PCA9539
> (16 port) or the PCF8574 (8 port) chips.
> As far as I read in the kernel documentation, the drivers transparently map
> those GPIO pins to the GPIO interface of the linux kernel.
> Thus, from a device driver perspective, it makes no difference whether a device
> is connected to the CPU's "real" GPIO pins or to a GPIO expander chip which can
> be accessed over thr I2C bus.
>
> Another advantage is the simple circuit design: Instead of having to route a
> complete parallel bus over the PCB, only the serial I2C bus has to be routed
> from the CPU to the port expander.
> >From the port expander a rather short bus then goes to the low-speed chip we
> want to talk to.
>
> In my oppinion, from a hardware as well as from a software perspective, this is
> the right way to go.
>
>
>
>
>
> As we saw, from a software perspective, it doesn't seem to make a big difference
> whether peripheral hardware is directly hooked up to the CPU's GPIO pins or
> it is hooked up to GPIO expanders.
>
>
> * However, if we look at existing device drivers, will it be possible to use
> them with this setup without modification ?
>
> * How will the kernel find devices attached to GPIO pins ?
> (There's no way to scan the bus since the kernel doesn't know what and where
> devices are attached to the GPIO pins, right ?)
>
> * What would be the best way to attach peripheral hardware from a linux-kernel
> perspective ?
>
> * Can you suggest any embedded hardware design documentation that considers
> linux compatibility ?
>
>
> sincerly,
> stefan
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
 Andrés Calderón
 Cel: +57 (300) 275 3666
 Email: andres.calderon@emqbit.com
 Web: www.emqbit.com

 "El hombre que produce mientras otros
 disponen de su producto, es un esclavo."
 -- Ayn Rand

Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers

[Jean-Christophe PLAGNIOL-VILLARD]

On 14:48 Sat 05 Jul     , Stefan Schoenleitner wrote:
> 
> 
> Robert Schwebel wrote:
> > 
> > If you want to have something which has good community support, check
> > what the mainline Linux kernel supports and base your stuff on that.
> 
> 
> What do you think of this board ?
> http://www.olimex.com/dev/sam9-L9260.html
If you are looking for a mainline Linux kernel and U-Boot, you could
take a look on the AT91SAM9260 or AT91SAM9263

Best Regards,
J.