All the parts arrived by last Tuesday and I was able to boot the board using the validation images. I explored the u-boot environment and dug around the root file system to see what the BeagleBoard folks had put together. I booted the board using the serial console and connected the S-Video port to a TV. With the validation kernel [1] and root file system running I enabled the S-Video port an tried mplayer [2] with the provided sample AVI file. The video was in black and white and looked pretty bad. A little digging makes me think that the video resolution is in PAL, not ntsc [3]. I tried changing this using some tips I found online (including some info from the dss [4] documentation in the kernel docs) but never was able to change the settings in a way that looked correct. So more investigation on how to get S-Video output is required.
After experimenting with the validation builds I tossed my sgx [5] kernel and root filesystem [6] (but not my u-boot image) on the SD card. This exposed a number of issues that will need more work.
- The root file system image is a monolithic gzipped ext2 image that is over 96MB. It makes no sense to dump this into LPDDR memory in one lump. What I need is to create two partitions on the SD card, one for the boot images an one for the run time root file system image uncompressed. This will help speed the boot process [7] by having a smaller initrd [8] to copy into memory by the bootloader [9].
- The boot images will provide an initrd [10] that will pivot [11] to the uncompressed image. This requires two buildroot [12] targets – one for the initrd and one for the run time file system.
- The initrd should not be embedded in the kernel. That should help speed the boot by having a smaller kernel to copy into memory. But it is unclear, given the small size of the initrd and what it has to do, whether having it as a separate image on the SD card will actually create a faster boot.
- If the initrd does get embedded in the kernel it has to be created before the kernel is built.
- The run time system will require mounting /tmp (and/or /var/log and maybe some others) to a ram disk to avoid excessive writes to the flash [13] card.
- bui [14] (beaglebox [15] UI) will probably want to cache configuration changes and write them only when changing run levels or when some predefined range is exceeded.
- u-boot environment variables will be different for BeagleBox than for the validation images. That means we need to edit include/configs/omap3_beagle.h in the u-boot source and update [16] CONFIG_EXTRA_ENV_SETTINGS. The kernel bootargs is one thing that will probably change. It's unclear what else will need to change. More research in this area needs to be done. The settings for the video output will need to change from “dvi [17]” to “tv” to get S-Video output.
- The S-Video issue needs to be investigated to see what configuration is required to get decent video output.
I made some notes at the bottom of the Research [18] page related to this stuff. I still need to migrate these into the issue tracker [19].
Update: 2010-10-18
The issue tracker has been updated. I've also done an analysis of the arago [20] rootfs and found a suitable template (from Arago) for handling the writable ram disk files/directories. It also appears that the validation images use an initrd but do not pivot [21] away from it. This means that, if we use the current boot process from the validation images (re: how x-loader gets us started), the initrd image for BeagleBox will replace the ramdisk [22] image from the validation images and it will do little more than just pivot to the uncompressed run time file system on the SD card, which in turn will use it's init scripts to create the ram disks and symlinks to prevent writes to flash (re: the SD card) until absolutely necessary.