[Sending this to psas-all as a status update.]

After I stopped working on the flight computer on Wednesday
(2008-01-09), I did some research and I discovered the primary issues
which previously prevented the flight computer from booting Linux 2.6.
I worked on the flight computer for a few hours on Sunday
(2007-01-16), and managed to achieve some good results.  The flight
computer can now:

* Boot Linux 2.6.
* Use an initramfs as its root filesystem.
* Use a busybox initramfs I created, and provide a shell on a serial
* Boot all of the above out of 5MB of the 32MB onboard flash (not the
  Compact Flash), with nothing attached other than power and serial
* Access the onboard flash partitions via the MTD driver.
* Access USB devices from Linux.
* Access the Compact Flash card from Linux.

Short version of the process (mostly of interest to the software and
avionics teams):

* Newer 2.6 kernels on embedded systems like our TQM5200 (with STK5200
  carrier board in this case) require a "flattened device tree" (fdt),
  AKA "device tree blob" (dtb), compiled from the device tree source
  (dts) in the Denx kernel source.  `apt-get install
  device-tree-compiler` for the compiler.  Then, build `tqm5200.dtb`
  from `tqm5200.dts`, with the command `dtc
  ./arch/powerpc/boot/dts/tqm5200.dts -R 4 -S 0x3000 -O dtb -o
  /tmp/tqm5200.dtb`.  `-R 4` reserves 4 slots for additional maps; an
  initramfs needs one, and the u-boot documentation I found recommends
  reserving 4.  `-S 0x3000` reserves some extra space for u-boot to
  extend the map at boot time.

* Booting kernels with an fdt requires a newer u-boot.  Build and
  install u-boot from the u-boot Git repository; commit
  6d714f82fb4b8bb7e267e9c71b8009bc670bfe88 worked for me.  `make
  CROSS_COMPILE=powerpc-linux-gnu- TQM5200_config`, then `make`.
  Install mkimage (found in `tools/mkimage`) on the `$PATH`, to build
  kernel and initramfs images later.

* Flash the new `u-boot.bin` to the board using the existing copy of
  u-boot.  I used the `tftp` command to transfer `u-boot.bin` from my
  tftp server to the flight computer's memory, then flashed it to the
  firmware partition in the flash address space.  (The existing u-boot
  included an `update` command to automate flashing the new u-boot.bin
  from a given address, so I just used `run update`, but flashing
  manually would involve the `unprotect`, `erase`, `cp.b`, and
  `protect` commands.)  The new u-boot worked on the first try,
  fortunate since I would not get a second without a working JTAG or a
  wait for shipping.

* Build a 2.6 kernel from the DENX `linux-2.6-denx` tree, using `make
  CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc tqm5200_defconfig`
  then `make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc uImage`.
  This used `mkimage`, and created `arch/powerpc/boot/uImage`.

* With the new u-boot, tftp the kernel and dtb to the flight
  computer's memory (I suggest using the `${kernel_addr_r}` and
  `${fdt_addr_r}` variables for the addresses.)  Then boot with `bootm
  ${kernel_addr_r} - ${fdt_addr_r}`.  This should boot the 2.6 kernel
  and get as far as failing to mount a root filesystem.

* You can at this point test booting with a root filesystem from
  compact flash or NFS, if you want.

* TFTP the kernel and dtb again, and flash them to the appropriate
  partitions in the onboard flash, designated by the `${kernel_addr}`
  and `${fdt_addr}` variables.  u-boot does not protect these
  partitions, so you just need to use "erase" and "cp.b".  Reboot, and
  try bootm again with the addresses from flash; this should again
  boot as far as trying to find a root filesystem.

* Grab a copy of the latest busybox release.  Build it with `make
  CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc defconfig`, then
  optionally configure differently with `make
  CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc menuconfig` (or an
  alternative config target if you prefer), then build with `make
  CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc`.  Run `make
  CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc install` to install
  busybox and its symlinks to _install in the busybox source

* Make a directory for building the initramfs.  `cp -a
  /path/to/busybox/_install/* initramfs/`.  Make a dev directory in
  `initramfs/`, and create device files for at least `null`,
  `console`, and `ttyPSC0`.  In the initramfs directory, run `find . |
  cpio -o -H newc | gzip > ../initramfs_data.cpio.gz`.  Now, turn that
  into a u-boot image with `mkimage -A ppc -T ramdisk -C gzip -n
  'Busybox initramfs' -d ../initramfs_data.cpio.gz ../uRamdisk`.

* In u-boot, tftp `uRamdisk` to the flight computer's memory.  `setenv
  bootargs rdinit=/bin/sh`, and booth with `bootm ${kernel_addr}
  address_of_uRamdisk ${fdt_addr}`.  This should bring up the busybox

* Create `/etc/inittab` in the initramfs directory, with the single
  line `ttyPSC0::askfirst:/bin/sh`.  Re-create the initramfs and the
  `uRamdisk`.  tftp `uRamdisk` to the flight computer's memory,
  `setenv bootargs rdinit=/sbin/init`, and boot with `bootm` again.
  The flight computer should boot to busybox init, which starts a
  shell when you press enter.

* Finally, in u-boot, tftp the uRamdisk again and flash it to the
  appropriate partition in the onboard flash.  Test booting this with
  `bootm`.  Create a new boot macro with `setenv flash_initramfs
  "setenv bootargs rdinit=/sbin/init ; bootm ${kernel_addr}
  ${ramdisk_addr} ${fdt_addr}"` and set the flight computer to boot
  this by default with `setenv bootcmd "run flash_initramfs"`.

* The flight computer will now boot unattended into the Linux 2.6
  kernel and busybox init, and interact over the serial console on

This documentation will go up on the wiki shortly.  Since we have
version control for the wiki, any objections to simply removing
obsolete documentation, such as the notes on the PP01 (MENMON) flight
computer, or purchasing info for the 586-based flight computer?

- Josh Triplett

psas-all mailing list

This list's membership is automatically generated from the memberships of the 
psas-airframe, psas-avionics, psas-general, psas-payload, psas-propulsion, and 
psas-software mail lists. Visit http://lists.psas.pdx.edu to individually 
subscribe/unsubscribe yourself from these lists.

Reply via email to