view · edit · print · history

Here are some thoughts on a RedBoot replacement for OpenSlug.

One goal is to get the 2.6.x kernel specific changes pushed upstream to kernel.org. So in the words of dsaxena:

"Dec 14 20:57:56 <dsaxena> so someone can grab kernel.org, do a 'make nslu2_defconfig && make zImage' and have a bootable kernel :)"

Since Linksys/Sercomm reused the IXDP425 development board machine id number, we are in between a rock and a hard place. We shouldn't, nor would they be accepted, push NSLU2 changes upstream for the IXDP425 machine id. The RedBoot shipped with the NSLU2 passes that wrong machine id to the kernel, so the choice is:

  • Kludge the sources to use the wrong machine id (which is what Linksys/Sercomm did)
  • Use the proper machine id
  • Use a different bootloader, http://wiki.buici.com/bin/view/Main/ApexBootloader, and be flexible about which ID to pass to the kernel. It can be a runtime selectable option.

So from a maintenance point of view, pushing the NSLU2 kernel changes upstream and using the proper machine id makes a lot of sense. Once all the changes are incorporated upstream, it's a normal Linux kernel. However, changing the machine id requires a new RedBoot and that opens the door for RedBoot changes.

  • The Machine ID only deals with the MACHINE record. We can make changes to the kernel that are MACHINE agnostic, or at a minimum, support both the ixdp425 target and the newer nslu2 target.

RedBoot Change list

  1. Pass a better machine id to the Linux kernel (maybe even intelligently)
    1. (For OpenSlug) Change the machine id to match the NSLU2 machine id 597, iirc
    2. Possibly add support to check the for the eRcOmM trailer in flash and pass the IXDP425 (Linksys compatible machine id) allowing backward compatibility with Unslung and Linksys code. Or maybe look at the SysConf? area. SysConf? == old machine id, no SysConf? == OpenSlug and NSLU2 machine id. (This needs some feasibility research) This should be easy enough to do as long as we know the size of the firmware.
  2. Support both normal and FatSlug configurations (by feeling out memory)
    1. This can be tricky if you want to search the memory space defined by a second chip select line. Accessing a region of memory that has no devices may lock-up the machine. The best case would be if it generated a fault that we can trap.
  3. Add enhanced upgrade capability.
    1. Add support for RedBoot boot scripts and possibly partition table. This allows longer timeouts during the boot process and possibly changing the default IP address from for the upgrade to a user defined value. After flashing to the new RedBoot, user upgrades would be much easier and possible directly from RedBoot. Normally, the user would only be reflashing partitions other than the RedBoot partition.
    2. The upgrade sw will be enhanced to replace the full 8MB of flash.
  4. Add RedBoot support to the OpenEmbedded Repo if possible to allow the full 8MB image to be created including the RedBoot Portion

This winds up with an OpenSlug that has a recovery ability directly from RedBoot. Booting will be faster without switchbox, currently I can boot in 21 seconds with switchbox and without insmoding the drivers. The full 8MB upgrade capability could be used to replace the stock firmware or revert to it. FatSlugs? could be either OpenSlug or Unslung. Finally, down the road, the replacement mechanism for other bootloaders is in place for the brave souls.

[Beewoolie] I think that completely new boot code is going to be required to make these sorts of changes feasible. RedBoot is byzantine, probably because of the history it has had with being patched for vendors and the tie to eCos. As of version 1.2.11, APEX boots the SLUG standard firmware and provides access to all of the system devices. In addition, it supports Fat Slugs--slugs with more than 32MiB of memory. :-)

view · edit · print · history · Last edited by beewoolie.
Based on work by tman, beewoolie, ka6sox, and g2.
Originally by g2.
Page last modified on May 15, 2005, at 05:15 PM