Hack&Dev

If you follow Paul Sokolovsky's blog you'll know we've been developing some recipes for building initramfs images using OE. I won't repeat the details here, check Paul's blog for an overview but I will describe the loopback booting module (since he ... [More] hinted so politely). First, why would you want to boot off a loopback device? The most difficult thing for new users coming to Linux is probably installing it. You have to understand how to partition a disk and hope you don't accidentally wipe all your data in the first place. To make things quick for testing and easy for new users, over at Hack&Dev we usually release a boot pack which contains a kernel zImage, an initramfs and a root filesytem image. The user just unpacks all these files into the root directory of a memory card, installs Cocoboot and taps boot, no dangerous and confusing partitioning required. So after Paul showed me his nifty method for building an NFS booting initramfs I couldn't resist adding another recipe that you can use for loopback booting. We later went on to merge them into a nice modular system that you can plug in whatever boot methods you need. Okay, how to use it? First build an initramfs image with the initramfs-module-loop package installed. The easiest way to do this is just bitbake initramfs-image. Next pop the initramfs in the appropriate place for your bootloader (or compile it into the kernel) and add to the kernel command-line something like root=/dev/loop looproot=/dev/mmcblk0p1:rootfs.ext2 The initramfs will note the root option and start the loopboot module which will mount partition one of the MMC card (mmcblk0p1), then loopback mount the rootfs.ext2 and finally switch_root to it. The full syntax for the looproot option is looproot=[device:]file[:offset] device is the device file resides on, file is a filesystem image and offset is the offset into the image to mount from (see losetup(8) manpage, the -o option). In theory you should be able to include multiple looproot options and to allow recursive mounting (ie an image within an image), but this is untested. So to boot an image off the LifeDrive's data partition you might use something like: root=/dev/loop looproot=:/dev/hda:91814912 looproot=rootfs.ext2 Note I'm giving a block device as the file argument here. This is because Palm OS writes an invalid partition table (their partition start/end offset calculations are wrong) to the HDD so we have to use a loopback device to manually specify the offset into the disk. The second looproot option then will mount the filesystem image. [Less]

Been doing some playing with GPIOs Clearing outputs: 23 turns of backlight, LEDs and causes palmos to think battery is dead. 24 turns off LEDs and causes palmos to think battery is dead. 25 as well... 79 - backlight power 114 - disables usb USB detect is in ASIC: bit 3 of register 0x36. High when disconnected.

BT on: 08000044: 001f00fa001800bc BT off: 08000044: 001f00ff00180080 ^^ Writing the ff into 0x44 had no effect, but 0x80 into 0x48 killed the connection. :D bit 2: no effect bit 3: no effect bit 4: breaks connection ... [More] bit 5: breaks connection Bingo! I'd say 4 and 5 are BT power and reset (although which is which?). Overwriting 0x0 (RBR/THR) also kills the connection while powering down BTUART has no effect indicating it's definately connect to ASIC UART. [Less]

BT on: 08000044: 001f00fa001800bc BT off: 08000044: 001f00ff00180080 ^^ Writing the ff into 0x44 had no effect, but 0x80 into 0x48 killed the connection. :D bit 2: no effect bit 3: no effect bit 4: breaks connection ... [More] bit 5: breaks connection Bingo! I'd say 4 and 5 are BT power and reset (although which is which?). Overwriting 0x0 (RBR/THR) also kills the connection while powering down BTUART has no effect indicating it's definately connect to ASIC UART. [Less]

BT on: 08000044: 001f00fa001800bc BT off: 08000044: 001f00ff00180080 ^^ Writing the ff into 0x44 had no effect, but 0x80 into 0x48 killed the connection. :D bit 2: no effect bit 3: no effect bit 4: breaks connection ... [More] bit 5: breaks connection Bingo! I'd say 4 and 5 are BT power and reset (although which is which?). Overwriting 0x0 (RBR/THR) also kills the connection while powering down BTUART has no effect indicating it's definately connect to ASIC UART. [Less]

I've just had some success in bringing my poor LifeDrive back from the grave. While the HDD is still unusable due to a broken cable, I was able to get the Linux kernel to boot. I chopped the end off a Nokia DKU-5 data cable (USB -> TTL serial ... [More] converter) and soldered it to some test points corresponding to the serial port on the LD's mainboard. You might be able to make out the tiny red wires in bottom-left corner of the photo. (The yellow stuff is Blu Tack, preventing things from moving around). By holding down the hotsync button and resetting the device, minicom at 115200 baud and no flow control on my PC gets me to the "Sandal" recovery console: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Sandal =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > There are a couple of different commands you can use in the Sandal console but the important ones are "w" which reads and writes memory and "x" which executes code at the given address. I wrote a small script bin2sandal.py which converts a binary image into a series of Sandal commands enabling you to upload and execute a tiny bootloader I wrote in ARM assembly called quickload: $ ./bin2sandal.py -d quickload.bin > /dev/ttyUSB0 ... >w 0xa00000e8=0xe5950000 0xA00000E8 : 0xE5950000 >w 0xa00000ec=0xe1a0f00e 0xA00000EC : 0xE1A0F00E >x 0xa0000000 Executing at 0xA0000000 Q? The Q? prompt is quickload asking us to upload a kernel image. Well we'd better give it what it wants: $ ./ql.py < zImage > /dev/ttyUSB0 Q? ql.py: uploading image... G............................. A little while later: .............................D Uncompressing Linux.......................................... ........................... done, booting the kernel. Linux version 2.6.21-hnd2 (ato@shion) (gcc version 4.1.2) #38 Sat Jul 7 12:50:15 EST 2007 CPU: XScale-PXA270 [69054117] revision 7 (ARMv5TE), cr=0000397f Machine: Palm LifeDrive ... boot messages ... # echo "I'm alive!" I'm alive! # Unfortunately neither LCD nor MMC is working. I suspect this is because we normally rely on Palm OS to configure and power them up. I'll try overwriting the GPIO configuration with that from a working device later. The tools I used are in linux4palm/tools/serial-loader in Hack&Dev's SVN. Quickload should work on any PXA device, however you'll need to change the machine code that's passed to the kernel. [Less]

I've just had some success in bringing my poor LifeDrive back from the grave. While the HDD is still unusable due to a broken cable, I was able to get the Linux kernel to boot. I chopped the end off a Nokia DKU-5 data cable (USB -> TTL serial ... [More] converter) and soldered it to some test points corresponding to the serial port on the LD's mainboard. You might be able to make out the tiny red wires in bottom-left corner of the photo. (The yellow stuff is Blu Tack, preventing things from moving around). By holding down the hotsync button and resetting the device, minicom at 115200 baud and no flow control on my PC gets me to the "Sandal" recovery console: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Sandal =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > There are a couple of different commands you can use in the Sandal console but the important ones are "w" which reads and writes memory and "x" which executes code at the given address. I wrote a small script bin2sandal.py which converts a binary image into a series of Sandal commands enabling you to upload and execute a tiny bootloader I wrote in ARM assembly called quickload: $ ./bin2sandal.py -d quickload.bin > /dev/ttyUSB0 ... >w 0xa00000e8=0xe5950000 0xA00000E8 : 0xE5950000 >w 0xa00000ec=0xe1a0f00e 0xA00000EC : 0xE1A0F00E >x 0xa0000000 Executing at 0xA0000000 Q? The Q? prompt is quickload asking us to upload a kernel image. Well we'd better give it what it wants: $ ./ql.py < zImage > /dev/ttyUSB0 Q? ql.py: uploading image... G............................. A little while later: .............................D Uncompressing Linux.......................................... ........................... done, booting the kernel. Linux version 2.6.21-hnd2 (ato@shion) (gcc version 4.1.2) #38 Sat Jul 7 12:50:15 EST 2007 CPU: XScale-PXA270 [69054117] revision 7 (ARMv5TE), cr=0000397f Machine: Palm LifeDrive ... boot messages ... # echo "I'm alive!" I'm alive! # Unfortunately neither LCD nor MMC is working. I suspect this is because we normally rely on Palm OS to configure and power them up. I'll try overwriting the GPIO configuration with that from a working device later. The tools I used are in linux4palm/tools/serial-loader in Hack&Dev's SVN. Quickload should work on any PXA device, however you'll need to change the machine code that's passed to the kernel. [Less]

I've just had some success in bringing my poor LifeDrive back from the grave. While the HDD is still unusable due to a broken cable, I was able to get the Linux kernel to boot. I chopped the end off a Nokia DKU-5 data cable (USB -> TTL serial ... [More] converter) and soldered it to some test points corresponding to the serial port on the LD's mainboard. You might be able to make out the tiny red wires in bottom-left corner of the photo. (The yellow stuff is Blu Tack, preventing things from moving around). By holding down the hotsync button and resetting the device, minicom at 115200 baud and no flow control on my PC gets me to the "Sandal" recovery console: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Sandal =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > There are a couple of different commands you can use in the Sandal console but the important ones are "w" which reads and writes memory and "x" which executes code at the given address. I wrote a small script bin2sandal.py which converts a binary image into a series of Sandal commands enabling you to upload and execute a tiny bootloader I wrote in ARM assembly called quickload: $ ./bin2sandal.py -d quickload.bin > /dev/ttyUSB0 ... >w 0xa00000e8=0xe5950000 0xA00000E8 : 0xE5950000 >w 0xa00000ec=0xe1a0f00e 0xA00000EC : 0xE1A0F00E >x 0xa0000000 Executing at 0xA0000000 Q? The Q? prompt is quickload asking us to upload a kernel image. Well we'd better give it what it wants: $ ./ql.py < zImage > /dev/ttyUSB0 Q? ql.py: uploading image... G............................. A little while later: .............................D Uncompressing Linux.......................................... ........................... done, booting the kernel. Linux version 2.6.21-hnd2 (ato@shion) (gcc version 4.1.2) #38 Sat Jul 7 12:50:15 EST 2007 CPU: XScale-PXA270 [69054117] revision 7 (ARMv5TE), cr=0000397f Machine: Palm LifeDrive ... boot messages ... # echo "I'm alive!" I'm alive! # Unfortunately neither LCD nor MMC is working. I suspect this is because we normally rely on Palm OS to configure and power them up. I'll try overwriting the GPIO configuration with that from a working device later. The tools I used are in linux4palm/tools/serial-loader in Hack&Dev's SVN. Quickload should work on any PXA device, however you'll need to change the machine code that's passed to the kernel. [Less]

I've just had some success in bringing my poor LifeDrive back from the grave. While the HDD is still unusable due to a broken cable, I was able to get the Linux kernel to boot. I chopped the end off a Nokia DKU-5 data cable (USB -> TTL serial ... [More] converter) and soldered it to some test points corresponding to the serial port on the LD's mainboard. You might be able to make out the tiny red wires in bottom-left corner of the photo. (The yellow stuff is Blu Tack, preventing things from moving around). By holding down the hotsync button and resetting the device, minicom at 115200 baud and no flow control on my PC gets me to the "Sandal" recovery console: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Sandal =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > There are a couple of different commands you can use in the Sandal console but the important ones are "w" which reads and writes memory and "x" which executes code at the given address. I wrote a small script bin2sandal.py which converts a binary image into a series of Sandal commands enabling you to upload and execute a tiny bootloader I wrote in ARM assembly called quickload: $ ./bin2sandal.py -d quickload.bin > /dev/ttyUSB0 ... >w 0xa00000e8=0xe5950000 0xA00000E8 : 0xE5950000 >w 0xa00000ec=0xe1a0f00e 0xA00000EC : 0xE1A0F00E >x 0xa0000000 Executing at 0xA0000000 Q? The Q? prompt is quickload asking us to upload a kernel image. Well we'd better give it what it wants: $ ./ql.py < zImage > /dev/ttyUSB0 Q? ql.py: uploading image... G............................. A little while later: .............................D Uncompressing Linux.......................................... ........................... done, booting the kernel. Linux version 2.6.21-hnd2 (ato@shion) (gcc version 4.1.2) #38 Sat Jul 7 12:50:15 EST 2007 CPU: XScale-PXA270 [69054117] revision 7 (ARMv5TE), cr=0000397f Machine: Palm LifeDrive ... boot messages ... # echo "I'm alive!" I'm alive! # Unfortunately neither LCD nor MMC is working. I suspect this is because we normally rely on Palm OS to configure and power them up. I'll try overwriting the GPIO configuration with that from a working device later. The tools I used are in linux4palm/tools/serial-loader in Hack&Dev's SVN. Quickload should work on any PXA device, however you'll need to change the machine code that's passed to the kernel. [Less]

Anyone who's done some handheld hacking will know that testing on a physical device is usually a real pain. If the lack of decent input and tiny screen don't get to you then it's the tiring compile, copy-to-sd, put-sd-in-handheld, test, reboot ... [More] , put-sd-back-in-pc, fix-code cycle. Today I'm going to explain how you can boot an unmodified linux4palm kernel zImage and rootfs inside the emulator qemu. First though a big thanks to Andrzej "balrog-kun" Zaborowski who as part of his work for OpenedHand added support for XScale processors to qemu and helped Marek and I get the Hack&Dev kernel working properly within it. Installing qemu (with H&D patches)Windows It's your lucky day, we're making things easy. Grab these binaries and unzip them somewhere. Linux and others Today I committed the OpenMoko qemu tree with the palm machine support patches into H&D SVN. So the first step is to grab a copy of tree: svn co https://hackndev.svn.sourceforge.net/svnroot/hackndev/qemu/trunk qemu-hnd cd qemu-hnd Alternatively get the version I wrote this guide against from the SF release page. Next you'll need to make sure you have gcc 3.x installed (look for /usr/bin/gcc-3.*). Unfortunately qemu will not build with gcc 4. Gentoo users can grab 3.4.6 with: emerge -av =gcc-3.4.6-r2 Next we configure and make, choosing only to build the arm-softmmu target and using the 3.4.6 compiler: ./configure --disable-system --disable-user --target-list=arm-softmmu --cc=gcc-3.4.6 make -j3 Once the build is complete, you'll find a qemu-system-arm executable in arm-softmmu/. Booting qemu You can check which machines qemu supports using this command: ./arm-softmmu/qemu-system-arm -M ? As of this writing the partially supported palms are palmld, palmt650, palmt680, palmtc, palmz72 and palmtx. Grab and unpack a bootpack for your desired machine. I'm going to use Stepan's Fire and Water 0.0.3 palmld bootpack as an example. Now simply fire up qemu, telling it to use the kernel and rootfs from the bootpack. I'm omitting the initrd since the palmld bootpack expects to boot off the HDD but it's easier to boot it off the SD card in qemu. The psplash=false option is to disable the OE splash screen so that I can view the startup messages. ./arm-softmmu/qemu-system-arm -M palmld -kernel zImage \ -sd Angstrom-opie-image-palmld-0.0.3-alpha.rootfs.ext2 \ -append "root=/dev/mmcblk0 psplash=false" It may take a while to boot so be patient. Eventually you should see the OPIE touchscreen callibration screen: Since qemu doesn't currently support the palms' touchscreens press Ctrl+Alt+3 to get to the serial console. You can then login as root. Press Ctrl+Alt+1 if you want to get back to the graphical output. Edit: More screenshots [Less]