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

6533Re: Help supporting Debian on a Kurobox [SOLVED]

Expand Messages
  • Guennadi Liakhovetski
    Sep 10, 2008
    • 0 Attachment

      On Wed, 10 Sep 2008, Rogério Brito wrote:

      > Just for further reference for the mailing lists, I own a standard Kurobox and
      > I'm able to use my own compiled 2.6.27-rc5 kernel on the Kurobox (which
      > guarantees me that I'm not going to get bitten by a glibc requirement on the
      > kernel version being too high). At least not now. :-)
      > I'm now using software which is completely free on my system (and this can
      > also be added to the Debian Wiki as a sucessful report of a current
      > installation that went well, even if I have not followed the use of d-i, which
      > does not exist at the moment).

      Good work!

      > This also serves as a report that the vanilla kernel is able to work well with
      > the standard Kurobox (I seem to recall that you stated only that it was tested
      > with a Kurobox HG, right?).

      No, not quite. It has also been tested by someonr from the LS-community on
      a HD system, but that was a few kernel releases back. Good to know it
      still works:-)

      > > I looked through the thread in the forum. I didn't quite understand, in
      > > one your post you write: "I have some problems with the precompiled uboot
      > > image that I am using" - does this mean that you have flashed the
      > > precompiled u-boot?
      > Yes, it does. Now, when I have some time, I will try to compile a newer uboot
      > and flash it.

      Wow, brave man... But see below.

      > > do not know how this specific binary was compiled. If you have already
      > > flashed it, just do "help bootm" in u-boot prompt. If it only describes
      > > two parameters - kernel and initrd - bad luck. If it describes three
      > > parameters - you are set up to boot a modern kernel.
      > Interestingly enough, I can't get the uboot netconsole, even though I *can*
      > boot into EM-mode for rescuing my box (but I guess that now that I'm with a
      > working kernel, I will rarely need to use such EM-mode tools).

      Your U-Boot probably uses some network addresses incompatible with your
      setup. Try to connect it to your PC directly with a crossover cable, or
      over a hub (not switch) and try to sniff the trafic, then you'll get
      IP-addresses it uses.

      > > Unfortunately, I don't think I am going to be very helpful to you.
      > > Firstly, I have no access to HD systems to test stuff, that's why the
      > > current U-Boot does not support them.
      > Are you upstream for uboot? Upstram for any project involved?

      Sorry, do not understand. What do you mean "_I_ am upstream?" I am
      developing as well for U-Boot as for the kernel, also for other platforms,
      and my patches do get "upstream" from time to time, yes. Yoou can just do
      "git log" and then search for any name you like:-)

      > > 1. get the current u-boot version ported to your hardware and merged into
      > > U-Boot mainline;
      > I guess that it already is, but I will check if the current uboot that I'm
      > using is patched or not.

      No, it is not. I did include rudimentary support for HD into the U-Boot
      patch that went upstream, but it is currently broken. Someone with Jtag
      and suitable developer skills has to fix it. The binary you've got is
      produced from patched sources, and that patch has no chance to get
      upstream in that form.

      > > 3. (optional) think about a user-space daemon to handle the AVR chip.
      > > Don't just get avr_evtd because you know it and it seems to work, think
      > > about what functionality you really need from such a daemon and how one
      > > best should implement it.
      > I seem to understand that you don't like the implementation of avr_evtd,
      > right?

      Well, I am not specifically emotional about it:-) I just preferred another

      > > I know I am subjective, but I think, my two
      > > sample programmes I've sent you go in the right direction.
      > Yes, they are small and to the point. I think that I may use them (and even
      > package them, if I happen to use them). I would only hope for them to be
      > slightly better documented.

      As I said, they are just "examples." In particular, you should not neet
      the ipowerd power daemon, I hope, one can find and use a standard GNU /
      Debian application that can be configured to do the same - control system
      power states depending on keyboard events. This part should be platform
      independent. Whereas buttond is actually the system-dependent part. It
      performs communication with the AVR controller, installed only on a couple
      of Buffalo systems and using their proprietory protocol.

      > > Instead, integrate with existing software,
      > > just interface the AVR with standard packages. For example, when the
      > > reboot button has been pressed, do not spawn a reboot process directly,
      > > instead, just provide a "reboot button pressed" event to the system and
      > > let the user configure a desired action using standard mechanisms.
      > Yes, using that way, things could be integrated with udev, I think (sorry if
      > I'm way off here).

      No, you are not. I am using udev to launch both thoes daemons (I think). I
      can look up my udev rules for you if you want. And it's the ipowerd that
      should be replaced with a more generic standard tool, I hope.

      Would also be nice to teach buttond more operations, like controlling the
      watchdog, LEDs, the fan, the eth PHY, etc. - if anyone wants those.

      Guennadi Liakhovetski, Ph.D.
      Freelance Open-Source Software Developer
    • Show all 14 messages in this topic