view · edit · print · history

Sluggo is the replacement for the RedBoot bootloader on the NSLU2. It is designed for developer-only use - it is not intended for mass distribution as part of a firmware image.

[Beewoolie] On the other hand, Apex[1] is designed to be part of mass distributions.

[tman] Sluggo isn't for mass distribution because of the chance that there will be an error when reflashing the bootloader and the user will end up with a dead NSLU2. It's not the RedBoot or added features aspect. Apex would have exactly the same issues and therefore also be developer-with-JTAG only

[Beewoolie] There are bound to be system features that will only be available with a new boot loader. I expect that we'll become comformtable enough with a complete flash image such that reflashing everything will be an acceptable option for users without JTAG. Users willing to do this must be adequately warned of the risk.

[Beewoolie] I've been thinking about ways to make the boot loader more flexible and useful. Imagine using the reset button, the power-on button and the LEDs as a UI. The user holds the reset button and powers the unit on. Immediately, the ready light begins flashing. The loader is in a wait state. Press the reset button and the disk LEDs cycle through four states. When the proper state is selected, the user presses the power-on button. If the user doesn't press reset or power-on for ten seconds, the unit will perform a normal boot. On successfully navigating the UI, the bootloader performs one of the special starup sequences:

  • Both LEDs off - normal boot
  • Disk 1 LED on - enable telnet server in boot loader
  • Disk 2 LED on - enable firmware upgrade mode
  • Both LEDs on - failsafe boot

There can certainly be more modes as we really have four LEDs. The problem is that it may be difficult for the user to identify the different modes if this UI is overly complex. Perhaps we should add voice prompts using the beeper. :-)

[tman] About your idea of holding buttons down. The Sercomm modified RedBoot does sort of implement this already. You can force it to enter upgrade mode by doing stuff with the reset button. It's not as flexible as your idea however since it really is just making it wait for you to upload a new flash image. Implement it as a command line arg to the kernel?

How about hold reset down whilst powering up to enter this special mode? Then pressing reset will advance the mode?

A slightly more practical idea to the voice prompts :) is just the plain old POST beeps you get on a PC or even morse code? Keep it fairly simple and it shouldn't be too annoying for the user to decipher.

[Beewoolie] Your idea of holding down reset while the unit powers up sounds, ahem, very familiar. How is it different from what I wrote? Is your concern that the reset button is difficult to press? Frankly, I'm not that concerned. This isn't going to be done often. It's only for junior G-men. And paperclips are still plentiful in the free-world.

I also believe that the beeper could reasonably support the UI. It would be really great if it weren't such a shrill tone. Experimentation is necessary.

[tman]The pressing the reset button part is the same as your idea. Not cycling through the modes is the difference. You switch to the next mode by pressing the reset button.

view · edit · print · history · Last edited by tman.
Based on work by beewoolie, tman, and Beewoolie.
Originally by tman.
Page last modified on April 14, 2005, at 03:26 PM