optimal hardware design for an ARM9 based single board computer to work with existing linux drivers
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
Quoted 2 lines · Stefan Schoenleitner
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
Signature · 5 lines
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-9Quoted 4 lines · Robert Schwebel
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
Quoted 1 line · Stefan Schoenleitner
Where did you get your information from ?
Thought I had read something like that, but if they say so ...
Quoted 5 lines
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
Signature · 5 lines
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-9Quoted 8 lines · Robert Schwebel
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
Hallo Stefan,
Am 2008-07-05 13:54:28, schrieb Stefan Schoenleitner:
Quoted 6 lines
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,...
Quoted 3 lines
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.
Quoted 2 lines
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
Signature · 5 lines
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)
Quoted 3 lines · Robert Schwebel
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.
Quoted 10 lines · Stefan Schoenleitner
Quoted 3 lines · Robert Schwebel
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.
Am 2008-07-05 13:05:33, schrieb Stefan Schoenleitner:
Quoted 5 lines
----------------------------------------------------------------------------------------
"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.
Quoted 8 lines
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
Signature · 5 lines
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)
Hallo Stefan,
Ich habe ein ähnliches project / I have a similar project.
Am 2008-07-05 11:03:11, schrieb Stefan Schoenleitner:
Quoted 7 lines
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)
Quoted 2 lines
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
Quoted 4 lines
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...
Quoted 1 line
1) directly connect it to the CPU's GPIO pins
This would be the fastestes method.
Quoted 3 lines
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.
Quoted 1 line
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
Quoted 9 lines
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
Quoted 10 lines
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.
Quoted 3 lines
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.
Quoted 5 lines
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.
Quoted 3 lines
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...
Quoted 3 lines
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
Quoted 6 lines
* 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!
Quoted 2 lines
* What would be the best way to attach peripheral hardware from a linux-kernel perspective ?
USB ;-)
Quoted 2 lines
* 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
Signature · 5 lines
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)
Quoted 5 lines · Stefan Schoenleitner
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.
Quoted 141 lines
http://www.cirrus.com/en/pubs/proDatasheet/EP9302_PP3.pdf
http://www.cirrus.com/en/pubs/manual/EP93xx_Users_Guide_UM1.pdfMy 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 I2CNow 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 chipAgain 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.
Quoted 1 line
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 8 lines
Andrés Calderón Cel: +57 (300) 275 3666 Email: [email protected] Web: www.emqbit.com "El hombre que produce mientras otros disponen de su producto, es un esclavo." -- Ayn Rand