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

Re: Help supporting Debian on a Kurobox [SOLVED]

Expand Messages
  • Rogério Brito
    Hi, Guennadi. ... No problems. I m also not able to keep up with my mails. :-) And, BTW, I ve been getting more successful regarding the Kurobox. ... Just for
    Message 1 of 14 , Sep 10, 2008
    • 0 Attachment
      Hi, Guennadi.

      On 07/09/2008, at 16:35, Guennadi Liakhovetski wrote:
      > and sorry for the delay.

      No problems. I'm also not able to keep up with my mails. :-) And,
      BTW, I've been getting more successful regarding the Kurobox.

      > On Mon, 1 Sep 2008, Rogério Brito wrote:
      >> I wrote this
      >> http://buffalo.nas-central.org/forums/viewtopic.php?p=86166#p86166
      >> which
      >> gives a precompiled uBoot and a precompiled firmimg.bin with kernel
      >> 2.4.33.3.
      >>
      >> Can you answer some of the questions that I raise there? For
      >> instance, I'm
      >> not sure if the referenced uBoot is able to boot recent 2.6
      >> kernels and I'm
      >> also not sure if I need the new 2.4.33 firmimg.bin flashed in
      >> conjunction.

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

      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?).

      I can share the precompiled uboot kernel (as a Debian package) that
      I'm using with the Kurobox. For the purposes of this, I have used my
      own homebrew cross-toolchain (from x86-64 to powerpc). It has worked
      very well for me for compiling the kernels for my weaker powerpc boxes.

      >> If you have binaries already compiled that would allow me to boot
      >> a 2.6
      >> kernel (or if other members of one of these lists have them), I
      >> would be
      >> grateful.
      >
      > 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.

      > I am not sure whether it (version 1.2.0-r2, no idea what "-r2"
      > means) can
      > handle the Flat Device Tree. This version does already support FDT,
      > but I

      Do you mean the dtb files? Yes, it does.

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

      I think that I will also try to flash that initrd with a newer
      kernel, but this can wait until I get more information. It's been a
      quite good learning exercise to get all these things together.

      > 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?

      > Otherwise I will be
      > glad to provide you with any information I have, just ask on
      > mailing lists
      > as you have done until now. I don't follow forums, so, don't expect
      > me to
      > answer there.

      Neither I like to use forums. I prefer the facilities of using
      mailing lists (procmail is my friend here).

      > As for your target to support PPC LS / Kurobox systems in stock
      > Debian, I
      > think, the best way to do this would be:
      >
      > 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.

      > 2. build and test a current kernel and fdt - you should not need any
      > development for this, everything is already in the mainline kernel;

      Done and working fine. And I even reported a bug to linuxppc-dev, but
      it was an already known issue. :-)

      > * These two steps should let you run a current Debian distribution
      > on your
      > machine - note, you don't necessarily need any AVR daemon, already
      > at this
      > point you should have a fully functional Debian system.

      Yes, that's were I am.

      > 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 also found some bugs on the code (see my package of it at
      <http://mentors.debian.net/debian/pool/main/a/avr-evtd/>, in
      particular, my patch).

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

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


      Regards, Rogério Brito.

      --
      Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
      http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
      Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
    • Guennadi Liakhovetski
      Hi ... Good work! ... 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
      Message 2 of 14 , Sep 10, 2008
      • 0 Attachment
        Hi

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

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

        Thanks
        Guennadi
        ---
        Guennadi Liakhovetski, Ph.D.
        Freelance Open-Source Software Developer
      Your message has been successfully submitted and would be delivered to recipients shortly.