Tag Archives: ARM

Raspberry Pi Power Architecture

Embarking on some work with the Raspberry Pi recently, I wanted to know what its power architecture looked like. The schematic diagrams are freely available but a quick web search didn’t reveal any higher-level design documents like this, so I drew my own and here it is.

I offer no guarantees of accuracy. Don’t blame me if you use this documentation and destroy your Raspberry Pi or anything else. This is not an official document. I hope it’s useful to someone.

The original version of this that I posted in April 2013 had a mistake in it, which Kai kindly pointed out. The version below has been corrected.

Raspberry Pi Power Architecture2

There’s a nice shiny pdf of it here: Raspberry Pi Power Architecture

Bubble Development Board – progress

Having now had the Bubble Development Boards for a few days, I’ve tested a few more features.

Both JTAG sockets (Xilinx 14-pin and ARM 20-pin) work with their respective dongles.

The Ethernet adapter, a Wiznet W5100, is showing signs of life. If I plug an Ethernet cable into it, the ‘link’, ‘full duplex’ and speed indicator LEDs come on. Frequently the ‘link’ LED blinks continuously along with the Rx LED. I don’t know why, though searching on the web indicates that the W5100 can be fussy about the choice of transformer it’s used with, and sometimes about what kind of hub it’s plugged into – apparenly the automatic MDI/MDI-X negotiation can get confused. The tests were done with a TP-Link TL-SF1005D switch and I haven’t tried any other. Sometimes, though, the link will settle down to a steady state, then I see the Tx and Rx LEDs doing sensible things.


The W5100 chip is wired to the Samosa bus with very simple address decoding so that it should appear every 4 bytes across the whole 256-byte Samosa address range. Manually poking and peeking its registers from the Bubble board’s boot loader gave sensible results, and I even managed to get it to try and send a packet, the Tx LED blinking reassuringly.

Recent Linux kernels have a driver for the W5100. I tried kernel version 3.7.1 which has already been patched for the Bubble board. The existing drivers expect the chip to be I/O or memory mapped, which is not the case on this board because it’s on the Samosa bus. The Samosa bus is accessed using its own function calls inside the kernel. I patched the driver, and had to undo one or two assumptions made in the code about memory access, and the results are promising: the chip is found correctly, interface eth0 appears, and it even sends packets from the DHCP client attempting to get itself an address. However, the first attempt to send a packet results in an error:

NETDEV WATCHDOG: eth0 (w5100): transmit queue 0 timed out

and a stack trace, though the kernel carries on running. It seems that the Ethernet chip’s interrupts are not making it into the kernel. This turns out to be due to the offending interrupt line not being connected to anything in the Bubble board’s CPLD, so I’ll have to fix that next. That needs the Xilinx programming dongle which I haven’t got with me at the moment.

Bubble Development Board – first prototypes received

A couple of days ago I received the first examples of the Bubble Development Board and started testing them.


Much to my joy, the board fits neatly into a low-cost plastic case from Farnell, part number 1526699. With front and rear panels suitably cut out, it should be well protected and easy to connect things to.


But does it work? Well, yes, largely. Here are the results so far.

  • Power: the LEDs (green for +5V input, orange for VDD_IO from the Bubble) come on and the Bubble board starts up reliably.
  • Reset button: does what it says on the tin.
  • Serial port: console works.
  • USB host: tested to work with a memory stick and a USB-to-Ethernet adapter.
  • USB slave: working. USB networking connection successfully established to a desktop PC as documented at http://www.balloonboard.org/balloonwiki/USBNetworking.
  • Audio: output works, straight into a pair of headphones, and quality seems good with no unpleasant background noises. Haven’t tried input yet.
  • HDMI: the Bubble board I was using was set up to drive an LCD panel, but by installing fbset and fiddling around with the settings (making them roughly 800×600, 60Hz) I managed to get a display on a monitor connected to the HDMI port. However, the image tends to disappear every few seconds and then come back again with some flickering, so something’s not quite right. I tried another monitor via an HDMI-DVI cable with the same result.
  • Micro SD socket: not working yet. The kernel reports an error during boot and /dev/mmc* devices don’t appear. I’ve noticed that other implementations of the SD card socket from Bubble have pullup resistors on all the data and clock lines which I neglected to put on this board. This might be an easy fix because the wiring looks right.
  • JTAG, Samosa, Raspberry Pi header, Ethernet: not tested yet.

Here’s another picture with the Bubble board turned over so you can see what’s on it.


How to Get a Real Serial Port – PCI Express under Linux


I do a lot of hardware and software development on things with embedded processors, ranging from little 8-bit Atmel chips to big 32-bit ARM-based things like the Balloon Board. Often the systems they’re built in to don’t have much of a display or keyboard, so getting information in and out of them for testing and debugging purposes is tricky. One thing that really helps is a good old-fashioned serial port. Pretty much every embedded processor has some kind of serial port on it, and they’re generally very easy to use from software so can be got working very early in the development process.

In order to make use of a serial port, you need another one to connect it to. This used to be easy: they used to be ubiquitous on desktop and laptop PCs. However, in the last 10 years they’ve gradually died out and been replaced by USB to serial adapters. Though such adapters are cheap and readily available, I’ve had loads of problems with them. Since they’re easily detached, they often seem to go missing, or get left in toolboxes and attached to projects. Some of the ones I’ve used also sometimes seem to get themselves in a mess and start turning my data into junk until they’re unplugged and reinserted. This is not helpful.


It can also be hard to predict how the serial port will be identified when it’s plugged in: under Windows, it gets a COM port number, but which number it gets depends on how many other such devices have ever been plugged into that machine and even into which USB socket, so setting debugging software up to find the one you want is impossible. Under Linux the same problem exists but with an extra feature: if you have a terminal program watching a serial port, then accidentally unplug it and plug it back in again, the program carries on as if nothing has happened but you don’t see any output . That’s because the operating system thinks that the old port is still in use even though it’s not there any more, and allocates a new, available number when it’s plugged back in, so /dev/ttyUSB0 magically becomes /dev/ttyUSB1. Even restarting your terminal program doesn’t work, because it’s still going to look at the old number. You can reconfigure the terminal program to look at the new one, but then you’ll find that if you shut everything down and restart it, the USB serial port will have moved back to /dev/ttyUSB0. The only way out is to stop the program, unplug the adapter again, plug it back in and restart the program. This is a serious pain.

I recently had the chance to do something about this problem in my own workshop. I was configuring a new Linux PC for the workbench, and discovered, to my great joy, a little-documented feature on the shiny new Gigabyte GA-Z77N-WIFI motherboard: a serial port! Tucked away on a little white connector, there it was, forgotten and unloved. All it needed was a cable to bring it to the outside world, and it worked. It turns up as COM1 under Windows and /dev/ttyS0 under Linux, and it’s always there, can’t be unplugged, and never changes its number. Wonderful.

If one serial port is good, more must be better. The motherboard has a PCI Express slot on it, intended for a turbo-nutter graphics card which this machine didn’t need. I found a PCI Express serial port card, similar to the PEX4S553 from Startech.com which looked like it would do the trick. Actually I had it lying around because I’d fitted it to a Mac Pro a couple of years ago, but it never worked properly in the Mac.


I put it in the machine and switched on. Would it work? Typing lspci revealed that it was there, and was working, so were the ports usable?

ls /dev/ttyS*
ttyS0    ttyS1    ttyS2    ttyS3

Not bad, but why only four? There’s the one on the motherboard, plus four on the card, so that should be five, right? Well, to cut a long story short, after a bit of web research, I found that the standard serial port driver in the Linux kernel only looks for four serial ports as standard, but responds to a kernel command line parameter to make it look for more (or indeed less). Experimentally rebooting and manually editing the kernel command line in grub to add


to the end of it worked! I had all five ports, and they all did what they should. To make the change permanent, I edited /etc/default/grub to add 8250.nr_uarts=5 to the end of the GRUB_CMDLINE_LINUX_DEFAULT parameter, and ran update-grub. Now all five ports turn up every time I switch the machine on, and I’m a happy developer. By the way, I’m running Debian Linux 6.0 (squeezy) with kernel version 3.2.something from backports, but the kernel version won’t make any difference – this stuff is all ancient history.

It remained only to tidy up the wiring. The ports on the Startech card appear on 10-pin headers. The wiring on these is simple: pin 1 on the header goes to pin 1 on the 9-pin D connector, pin 2 to pin 2, and so on. Pin 10 isn’t used. However, the way the pins are numbered differs between the headers and the D connectors: the headers are numbered on alternate sides, like a street, so one side is 1/3/5/7/9 and the other is 2/4/6/8/10. The D connectors are numbered 1-5 on the top row and 6-9 on the bottom row.

I had a load of serial port breakout cables in the bottom of my PC parts box, left over from the early 90s. I found that many of them were wired straight-through, like this:


which is wrong for the Startech card. I had to rewire them to look like this:
:DSC_0362[1] DSC_0361[1]

according to the correct pin numbering, and then they worked. The card fitted neatly in the back of the machine:

DSC_0366[1]and, as a finishing touch, I did a ‘case mod’ to mount two of the serial ports on the unused 3.5″ floppy drive blanking plate:

DSC_0365[1]Notice how they’re labelled, so I always know which is which! It’s a very practical arrangement for the workbench, having reliable serial ports always at hand. The other two are round the back, and will probably be used less frequently.

Bubble Development Board V1.0

I’ve just got V1.0 of a development board for the ‘Bubble’ embedded ARM module ready for manufacture, and will hopefully have prototypes soon.


It’s designed to make the Bubble board easy to work with, and brings out various useful connectors:

  • JTAG ports compatible with Xilinx (14-pin) and ARM (20-pin) dongle pinouts
  • Serial port for the console
  • USB host, for memory sticks, keyboards and whatever else
  • USB slave, for mass storage or USB networking
  • Micro SD card
  • HDMI for monitor connection
  • Ethernet
  • Stereo analogue audio in/out
  • Raspberry-Pi compatible expansion connector with I2C, SPI and GPIO

It’s all powered from a Micro USB connector which should take a standard mobile phone charger, and is designed to sit neatly in a low-cost plastic box for protection.

Everything except the Ethernet port is already supported by Linux on the Bubble board, though making the HDMI port work will involve some fiddling with the LCD output timings. The Ethernet port is based on the Wiznet W5100 chip, which is popular in the embedded community and is supported by recent Linux kernels.