[changing CC to psas-avionics, which replaced psas-software since I sent
the original mail.]

On Tue, Oct 06, 2009 at 08:38:06PM -0700, Sarah A Sharp wrote:
> My perpetual goal for PSAS is to get a new (2.6.31) Linux kernel
> installed on it, with dave and kay's userspace code to talk to an
> lpcusb board through usbfs.  I continue to try to follow the
> directions you posted a year and a half ago, but I continue to get
> lost, so bare with me. :)

Every time I try to build a new kernel for the board I get lost and have
to muddle through as well; these processes just don't stay fixed over
time. :)

By the way, I looked at the current denx tree, and I'd guess that you
probably want to use the DENX-v2.6.31-stable branch.  It has some fixes
since the DENX-v2.6.31 tag.

> Can you please look over the following email and return it with
> unnecessary steps removed.  I think I remember that I don't need the
> flattened device tree, but I'm not sure.

You do need the fdt, actually.  It *might* not have changed since the
version the flight computer currently has, but it can't hurt to flash a
new one.

> In the meantime, I have completed the following steps on this page:
> http://psas.pdx.edu/FlightComputerAv2b/?updated
> 
> I'm attempting to build the denx tree, but this command
>   make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc tqm5200_defconfig
> gives this error:
>   Can't find default configuration "arch/powerpc/configs/tqm5200_defconfig"!

They moved it in April 2008.  You now want:

make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc 52xx/tqm5200_defconfig

I just tested that with current DENX-v2.6.31-stable
(c94e8c9e1834eed8e7bed0912e5d482073a3cd08), and it worked.

And, after doing that, you can:

make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc menuconfig

and use menuconfig to add anything else you need.

> On Wed, Jan 16, 2008 at 3:34 PM, Josh Triplett <j...@freedesktop.org> wrote:
[...]
> > 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.

You still need this step.  It looks like the fdt files *have* changed
several times, so I'd recommend compiling and flashing the one from the
kernel version you use.

> > * 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.

The version of u-boot currently on the flight computer should work now,
but I'd recommend leaving this information in the guide.  And in any
case, building and flashing a new u-boot can't *hurt*.

> > * 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`.

As stated above, substitute "52xx/tqm5200_defconfig" for
"tqm5200_defconfig" here.  Should otherwise work.

> > * 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.

Still applies.

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

Ditto.

> > * 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.

Note that you *cannot* tftp directly to the ${kernel_addr} and
${fdt_addr} locations in flash.  You need to tftp to the _r addresses
and then use erase and cp.b to flash those to the non-_r addresses.

> > * 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
> >  directory.

This should still work.

> > * 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`.

And, of course, you can add any other tools and libraries you want at
this point.

Also, to get sensible USB support, you'll need a lot more devices.  You
could try to put udev (and the necessary configuration) into the
initramfs.  Alternatively, you *might* have luck using the new
devtmpfs, as long as you can live with all devices only having
permissions for root.  (We may well not bother having any non-root users
on the flight computer, so this should work fine.)

> > * 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
> >  shell.

This still applies.

> > * 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.

Of course, you can use busybox's init to start anything else you like,
or you can use something else as /sbin/init.  Oh, and you might not
actually need to explicitly set rdinit=/sbin/init; the kernel should
default to that.

> > * 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"`.

This still applies.

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

Hopefully you can now get to this point with 2.6.31. :)

- Josh Triplett

_______________________________________________
psas-avionics mailing list
psas-avionics@lists.psas.pdx.edu
http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics

Reply via email to