I’ve just received the USB/RS-232 adapter (which is based around the FTDI FT232BM chipset, and supported under Linux without any additional work), and connected it to the board’s UART1/2 port and my laptop using the null modem cable supplied with the board.
For the curious,
[ 177.992226] usb 2-2: new full speed USB device using ohci_hcd and address 3
[ 1090.655407] usb 2-2: USB disconnect, address 3
[ 1160.036191] usb 2-2: new full speed USB device using ohci_hcd and address 4
[ 1160.656891] usbcore: registered new interface driver usbserial
[ 1160.656938] USB Serial support registered for generic
[ 1160.659703] usbcore: registered new interface driver usbserial_generic
[ 1160.659709] usbserial: USB Serial Driver core
[ 1160.676061] USB Serial support registered for FTDI USB Serial Device
[ 1160.677502] ftdi_sio 2-2:1.0: FTDI USB Serial Device converter detected
[ 1160.677628] usb 2-2: Detected FT232BM
[ 1160.677632] usb 2-2: Number of endpoints 2
[ 1160.677635] usb 2-2: Endpoint 1 MaxPacketSize 64
[ 1160.677639] usb 2-2: Endpoint 2 MaxPacketSize 64
[ 1160.677642] usb 2-2: Setting MaxPacketSize 64
[ 1160.694632] usb 2-2: FTDI USB Serial Device converter now attached to ttyUSB0
[ 1160.696459] usbcore: registered new interface driver ftdi_sio
[ 1160.696466] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver
sudo lsusb -v reports:
Bus 002 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0403 Future Technology Devices International, Ltd idProduct 0x6001 FT232 USB-Serial (UART) IC bcdDevice 4.00 iManufacturer 1 FTDI iProduct 2 USB-to-Serial iSerial 3 FTE2QSKA bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 44mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 2 USB-to-Serial Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x0000 (Bus Powered)
We can confirm that everything works by running
cat /dev/ttyUSB0 from a BASH session, and powering on the board:
tyson@UmBongo:~$ cat /dev/ttyUSB0 Texas Instruments X-Loader 1.47 (Jan 14 2011 - 15:43:28) Starting X-loader on MMC Reading boot sector 212836 Bytes Read from MMC Starting OS Bootloader from MMC... Starting OS Bootloader... U-Boot 2010.06 (Jan 14 2011 - 15:43:45) OMAP3430/3530-GP ES3.1, CPU-OPP2 L3-165MHz OMAP3 EVM board + LPDDR/NAND I2C: ready DRAM: 128 MiB NAND: 256 MiB *** Warning - bad CRC or NAND, using default environment In: serial Out: serial Err: serial Read back SMSC id 0xffff0000 Die ID #2f7c000400000000040365fa1801900d Net: smc911x-0 Hit any key to stop autoboot: 0 mmc1 is available reading boot.scr 421 bytes read Running bootscript from mmc ... ## Executing script at 82000000 reading uImage ** Unable to read "uImage" from mmc 0:1 ** ***** RootFS: /dev/mmcblk0p2 ***** Wrong Image Format for bootm command ERROR: can't get kernel image! OMAP3_EVM #
Obviously, since I renamed the
uImage file on my Android SD card from earlier (to
kuImage), the board fails to successfully boot Linux.
After downloading and installing CuteCom (a Qt-based serial console utility), and configuring it to communicate with the board at 115200 baud, using 8 data bits, and without parity or software/hardware handshaking, the
help command command can be issued to the board’s bootloader – which results in:
OMAP3_EVM # help ? - alias for 'help' base - print or set address offset bdinfo - print Board Info structure boot - boot default, i.e., run 'bootcmd' bootd - boot default, i.e., run 'bootcmd' bootm - boot application image from memory bootp - boot image via network using BOOTP/TFTP protocol cmp - memory compare coninfo - print console devices and information cp - memory copy crc32 - checksum calculation dhcp - boot image via network using DHCP/TFTP protocol echo - echo args to console editenv - edit environment variable exit - exit script ext2load- load binary file from a Ext2 filesystem ext2ls - list files in a directory (default /) false - do nothing, unsuccessfully fastboot- fastboot- use USB Fastboot protocol fatinfo - print information about filesystem fatload - load binary file from a dos filesystem fatls - list files in a directory (default /) fsinfo - print information about filesystems fsload - load binary file from a filesystem image go - start application at address 'addr' help - print command description/usage i2c - I2C sub-system imxtract- extract a part of a multi-image itest - return true/false on integer compare loadb - load binary file over serial line (kermit mode) loads - load S-Record file over serial line loady - load binary file over serial line (ymodem mode) loop - infinite loop on address range ls - list files in a directory (default /) md - memory display mm - memory modify (auto-incrementing address) mmc - MMC sub-system mtest - simple RAM read/write test mw - memory write (fill) nand - NAND sub-system nandecc - switch OMAP3 NAND ECC calculation algorithm nboot - boot from NAND device nfs - boot image via network using NFS protocol nm - memory modify (constant address) ping - send ICMP ECHO_REQUEST to network host printenv- print environment variables rarpboot- boot image via network using RARP/TFTP protocol reset - Perform RESET of the CPU run - run commands in an environment variable saveenv - save environment variables to persistent storage setenv - set environment variables showvar - print local hushshell variables sleep - delay execution for some time source - run script from memory test - minimal test like /bin/sh tftpboot- boot image via network using TFTP protocol true - do nothing, successfully version - print monitor version OMAP3_EVM #
At this stage, it’s necessary to remove the SD card from the board, and attempt to copy a Symbian ROM image to it.
Unfortunately, after installing Android, it’s also necessary to resize the ~70MB primary partition in order to make it fit. The quickest way to do so would probably be to use GParted and a USB card reader, if you’re using Linux under a virtual machine (as opposed to rebooting into a Wubi installation, in order to use my laptop’s internal reader, which I was initially tempted to do).
An SD card prepared using the the tool from the aforementioned archive contains an x86 partition table, and 3 partitions (a 70.57MiB FAT32 boot partition, a 941.31MiB Ext3 root partition, and an 870.71MiB FAT32 data partition).
Since it is possible to reconstitute these partitions using that tool, and since they’re unnecessary for the Symbian Platform, we can remove the root and data partitions, and then resize the boot partition to be 512.97MiB in order to store the Symbian ROM with some allowances for future growth.
If that process fails with “
GNU Parted cannot resize this partition to this size. We're working on it!“, then:
- Mount the boot partition (usually
- Copy all of its contents to a convenient location
- Unmount the partition
- Remove the partition using GParted
- Create a new 512.97MiB FAT32 partition with 0MiB free space preceding it
- Mount the newly created boot partition
- Copy the “
MLO” and “
u-boot.bin” files from earlier to said partition
- Unmount the partition – if you’re using a VM, and want to copy the ROM using the host OS, instead of the guest OS
Now, we can attempt to copy “
beagle.rom.img” from the “
ROM Images” directory to the root of the boot partition as “
uImage“, unmount the partition, and then insert the card back into the board.
Unfortunately, at this stage, although several LEDs on the board illuminate, I can’t see any output from it on the serial console – which leads me to suspect that the bootloader and firmware on the card isn’t being loaded. Testing using the Windows CE card lends credence to that thought.
Attempting to copy the
x-load.bin.ift file from
/OMAP35X/Boot_Images to the root of the boot partition also yields the same result.
After quickly making some raw sector dumps of both SD cards, I suspect that the structure of the x86 MBR/partition table, and the location of the boot partition is a factor in the ability to boot the board.
file reports the following, for the Windows CE card:
dump: x86 boot sector, code offset 0x0, OEM-ID "MSDOS5.0", sectors/cluster 64, root entries 512, Media descriptor 0xf8, sectors/FAT 236, heads 64, hidden sectors 135, sectors 3858489 (volumes > 32 MB) , serial number 0x61636637, unlabeled, FAT (16 bit)
For the modified Android card, this is reported, instead:
dump2: x86 boot sector; partition 1: ID=0xb, starthead 32, startsector 2048, 1048576 sectors, code offset 0xb8
With that in mind, since I’ve got a complete raw backup of the Windows card that I can restore later; I’ll remove the
NK.BIN files, and copy over the Android boot files (modulo the Linux kernel binary), plus a Symbian ROM image.
Lo and behold, we now have X-Loader and U-Boot, which attempt to boot our “Linux” kernel into 0×82000000, but seem to get stuck afterwards.
After getting this far, I’ll probably take a break, and see if manual intervention at the bootloader prompt gets us any further, later.