Loading ...
Sorry, an error occurred while loading the content.

Re: [nslu2-linux] Re: [nslu2-developers] leds driver

Expand Messages
  • Rod Whitby
    ... I ll add my ideas. We have quite a few led states available for the ready/status led, so we should come up with a comprehensive scheme for using it.
    Message 1 of 12 , Oct 1, 2005
    • 0 Attachment
      On 10/1/05, John Bowler <jbowler@...> wrote:
      > Here's my own base requirements:

      I'll add my ideas. We have quite a few led states available for the
      ready/status led, so we should come up with a comprehensive scheme for
      using it. Where colours are separated with a slash ("/") in the text
      below, it means to flash alternating the colour sequence specified
      (i.e. "Red/Green/Off" means red, then green, then off, then repeat).

      Let's start with the ones we cant' change:

      1/ Off - Power is off (led behind power button is also off), or kernel
      has crashed in the led off state while flashing something (led behind
      power button is still on).

      2/ Amber - We are in Redboot and the system is starting up (but the
      kernel hasn't started yet). We can't change this one - it's
      hard-coded in the bootloader.

      3/ Red/Green - We are in Redboot upgrade mode. We can't change this
      one - it's hard-coded in the bootloader.

      Now lets set some other principles:

      4/ Green - Should indicate that we are in normal user mode and all
      services are up.

      5/ Green/Off - Should be used to indicate CPU status so that you can
      visually distinguish an idle system,from a lightly-loaded system from
      a heavily-loaded system.

      6/ Green/Amber - System is shutting down

      Now let's look at what's left:

      7/ Red
      8/ Red/Amber
      9/ Red/Off
      10/ Amber/Off

      These should be used to indicate successful progression from kernel
      booting to normal user mode, such that the following failure points
      can be identified by the user:

      a) Kernel failed to run init
      - Propose Red/Off
      b) Init failed to pivot to the alternate rootfs
      - Propose Red/Amber
      c) Startup scripts failed to reach completion
      - Propose Amber/Off
      d) Kernel panic
      - Propose Red

      This choice of colour sequences takes into account John's requirements
      for flashing during boot and unambiguous state changes and a
      deterministically different finish state.

      So the kernel would set the leds to Red/Off, then change to Red/Amber
      at the start of /linuxrc, then change to Amber/Off after the rootfs
      has pivoted and the init scripts have started, then change to Green
      (and pass over control to the CPU state driver) in S99finish. A
      kernel panic would change to Red, and the shutdown process would
      change to Green/Amber.

      If the 10 states listed above are not enough to identify all useful
      states, or if we wanted to provide the user with additional state
      choices, then we can also use the next 10 three colour sequences:

      11/ Red/Amber/Green
      12/ Red/Green/Amber
      13/ Red/Amber/Off
      14/ Red/Off/Amber
      15/ Red/Green/Off
      16/ Red/Off/Green
      17/ Amber/Green/Off
      18/ Amber/Off/Green
      19/ Green/Amber/Off
      20/ Green/Off/Amber

      This could be extended indefinitely, even to the point of being able
      to spell out morse code in tri-colour.

      All of these states could be encoded by strings using the characters
      "O"ff, "R"ed, "G"reen, "A"mber, such as:

      "ROROROOAAOAAOAAOOGOGOGOOO"

      The kernel driver could cycle through the sequence at a fixed rate
      until the sequence was changed, or the scheme could be extended with
      numbers inserted in the stream to add durations.

      As far as the other leds go, I would like to see a claim/release
      mechanism on the disk activity leds, so that those of use who only
      need one disk activity led, and want to use the other led for
      something else (e.g. mail waiting) can do so.

      -- Rod
    • Adrian Day
      ... 2nd ed. I have little need of anything other than what s currently provided - disk leds flashing on access would be an added bonus. Would prefer the option
      Message 2 of 12 , Oct 2, 2005
      • 0 Attachment
        On 10/1/05, Rod Whitby <list.nslu2-linux@...> wrote:

        > As far as the other leds go, I would like to see a claim/release
        > mechanism on the disk activity leds, so that those of use who only
        > need one disk activity led, and want to use the other led for
        > something else (e.g. mail waiting) can do so.

        2nd'ed.

        I have little need of anything other than what's currently provided -
        disk leds flashing on access would be an added bonus. Would prefer the
        option to keep disk 1 and disk 2 status seperate.

        --
        AJ
      Your message has been successfully submitted and would be delivered to recipients shortly.