My first experiences with Fedora on a BeagleBoard

Last week I spent some time making libvirt able to start emulated (through QEMU) ARM systems. Today I was looking into starting Fedora on a BeagleBoard. A colleague of mine loaned me the BeagleBoard, for me a nice opportunity to check out the current status of Fedora ARM. There is some documentation on the Fedora ARM Wiki pages. Unfortunately the available downloads do not include a kernel that runs on the BeagleBoard.

Compiling a kernel for the BeagleBoard

The Fedora ARM Project provides a repository for Fedora 12 that contains cross-compilers. This allows one to compile a kernel on x86_64, and saves the need for a ARM CPU. As the packages were created with/for Fedora 12, the tools are not up to date. The available GNU Compiler Collection has version 4.1.2. And unfortunately there seems to be a known issue with kernels newer than 2.4.34. Of course, you only look for this when you run into the error:
linux-2.6/arch/arm/include/asm/atomic.h:42: error: impossible constraint in 'asm'
make[1]: *** [kernel/sched.o] Error 1
make: *** [kernel] Error 2

Switching to linux-2.6.34 was likely the easiest way to workaround this issue. Note to self: look into the option of updating the cross compiler toolchain?

Booting the BeagleBoard

Equipment used:
  • USB-to-serial converter
  • null-modem cable
  • BeagleBoard serial port connector cable
  • USB-Mini plug
  • SD-card

In order to see what the BeagleBoard is doing, I used minicom over the USB-serial converter to receive the output from the serial console. After transferring the root-filesystem to the SD-card, it is possible to send a u-boot image to the BeagleBoard over the serial-connection. Inside u-boot the command loady starts a filetransfer over the ymodem protocol. minicom can send a file after pressing "CTRL+A s". And while doing so, abrt created this bug.

The procedure to boot Linux on Beagle Board is straight forwards and with some tuning the kernel can get started:
Texas Instruments X-Loader 1.4.2 (Feb 19 2009 - 12:01:24)
Reading boot sector
Error: reading boot sector
Loading u-boot.bin from nand

U-Boot 2009.01-dirty (Feb 19 2009 - 12:22:31)

I2C: ready
OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz
OMAP3 Beagle board + LPDDR/NAND
DRAM: 128 MB
NAND: 256 MiB
MUSB: using high speed
In: serial
Out: serial
Err: serial
Board revision Ax/Bx
Serial #3a5c00020000000004013ef109010017
OMAP3 # mmcinit
OMAP3 # fatload mmc 0:1 0x80000000 uimage-2.6.34_201102061623
OMAP3 # setenv bootargs console=ttyS2,115200n8 root=/dev/mmcblk0p2 rootwait nohz=off
OMAP3 # bootm 0x80000000
## Booting kernel from Legacy Image at 80000000 ...
Image Name: Linux-2.6.34beagleboard
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1678404 Bytes = 1.6 MB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Linux version 2.6.34beagleboard ([email protected]) (gcc version 4.1.2 20070925 (Red Hat 4.1.2-33.fa1)) #3 Sun Feb 6 16:18:40 GMT 2011
CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c53c7f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: OMAP3 Beagle Board

Some Issues

For some reason init seems to be of the opinion that booting is not successful and a reboot is needed. Adding the 'kernel parameter' --verbose that does not get handled by the kernel, but by init, the following messages were written:
Waiting for root device /dev/mmcblk0p2...
mmc0: new SD card at address 9ced
mmcblk0: mmc0:9ced SD02G 1.89 GiB
mmcblk0: p1 p2
kjournald starting. Commit interval 5 seconds
EXT3-fs (mmcblk0p2): using internal journal
EXT3-fs (mmcblk0p2): recovery complete
EXT3-fs (mmcblk0p2): mounted filesystem with writeback data mode
VFS: Mounted root (ext3 filesystem) on device 179:2.
Freeing init memory: 136K
init: Control request to emit fedora.serial-console-available event
init: Handling fedora.serial-console-available event
init: serial goal changed from stop to start
init: serial state changed from waiting to starting
init: Handling starting event
init: serial state changed from starting to pre-start
init: Active serial pre-start process (453)
init: Control request for status of rcS
init: Control request for status of rcS
init: Control request for status of rcS
init: Control request for status of rcS
init: Control request for status of rcS
init: Control request for status of rcS
init: Event queue paused
init: Control request for status of rcS
init: Control request for status of rcS
Restarting system.

Booting with init=/bin/dash seems to work and one can do some diagnosis. However when doing an exec init --verbose a reboot get initiated again :-/

Next Steps

Whenever I have another day for playing, I will look into the booting issue. Until than, I'm very grateful for any pointers!

From what I understand, the USB-port on the BeagleBoard can be configured to provide a networking-device. It would be very useful if the BeagleBord can communicate over a network-card called usb0. Everything indicates that this is possible, as a test-kernel I tried to start, resulted in these messages on my laptop:
usb 1-1: New USB device found, idVendor=0525, idProduct=a4a2
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1: Product: RNDIS/Ethernet Gadget
usb 1-1: Manufacturer: Linux 2.6.28-omap1 with musb_hdrc
cdc_ether 1-1:1.0: usb0: register 'cdc_ether' at usb-0000:00:1a.7-1, CDC Ethernet Device, 8a:18:75:d3:a6:10
usbcore: registered new interface driver cdc_ether
usbcore: registered new interface driver cdc_subset
usb0: no IPv6 routers present
usb 1-1: USB disconnect, address 43
cdc_ether 1-1:1.0: usb0: unregister 'cdc_ether' usb-0000:00:1a.7-1, CDC Ethernet Device
But of course, this test-kernel is affected by same reboot-problem.

And the Future?

It looks like there is quite something going on on the BeagleBoard. Futhermore there is the new DreamPlug (oder here)coming. Alternatively I might look into a Pandaboard. These are all nice and low-energy solutions for a little home server...
Share Comments
comments powered by Disqus