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.

DSC_0453

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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s