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

Re: [LinkStation_General] Re: Help supporting Debian on a Kurobox

Expand Messages
  • Rogério Brito
    Hi, Guennadi. ... No problems. I think that I can deal with it once that I can get a recent kernel to boot. ... Well, as long as it depends on interest, I
    Message 1 of 14 , Sep 1, 2008
    • 0 Attachment
      Hi, Guennadi.

      On Aug 29 2008, Guennadi Liakhovetski wrote:
      > On Thu, 28 Aug 2008, Rogério Brito wrote:
      >
      > > And do you know the status of the dtc thing? Does it still need to be
      > > done?
      >
      > Yes, sure. You could try to use a wrapper and link the device tree with
      > the kernel, but this is currently not supported on LS / Kuro and I don't
      > know how difficult it is to configure this.

      No problems. I think that I can deal with it once that I can get a recent
      kernel to boot.

      > > What I find surprising is that all this knowledge is not included in
      > > the distributions, but scattered on some pages and to get a proper
      > > recent system with all security updates one has to have a quite good
      > > mental compilation of the state of the things.
      >
      > The lack of interest and man-power?

      Well, as long as it depends on interest, I would be willing to contribute
      whatever I make.

      > > Another was the need to use extra init scripts to send strings like
      > > EEEE to /dev/ttyS1 to get shutdown to work properly (at least with the
      > > version of the kernel that I still have here, which is the stock
      > > 2.4.17).
      >
      > As you probably know by now, the daemons are not really _necessary_ with
      > recent kernels - the watchdog is switched off automatically by the
      > kernel.

      Now, I didn't know this. I even packaged avr_evtd and plan on getting it
      into the distribution, as it would matter for the people doing work on
      embedded platforms (and for projects like emdebian).

      > > The dtc thing was also news to me, even though I had used Linux on
      > > PowerPC for some time now.
      >
      > First it is relatively new - since about two years, I think. Secondly,
      > you only need it on (ppc) systems, that don't have OF. Your Macs do have
      > OF, and the device tree is actually a replacement of the OF on Macs and
      > other machines.

      Thanks. I didn't know the purpose of that information contained in a
      compiled file that should be put on the side of the kernel.

      > > I would like to change the state of things, to have them packaged in
      > > systematic ways so that users (and that includes me) can only install
      > > some packages and forget about the differences between a Kurobox
      > > standard and a plain NewWorld Macintosh or a common x86 machine. That's
      > > my purpose and I would appreciate any help that I can get, since I know
      > > very little about this machine.
      >
      > Well, if you have time, sure, would be nice. But just think how many
      > people will benefit from your work? Those ppc-based machines are not
      > produced any more. There are some others, I think, based on the same
      > CPU...

      Well, the userland is simply the same as the other powerpc binaries and, as
      such, I would use it for development (that's the purpose of Charles Plessy
      having sent me the Kuro Box). And it would also be a learning experience
      and, perhaps, this learning experience could be materialized in support for
      another sub-architecture of powerpc.

      Now, I would like to ask your help here. As you mentioned to me on an
      earlier post, I went to some forums and wikis and consulted their
      documentation, but I am still unsure of many things and I would appreciate
      your help here, since you seem to be knowledgeable about these boxes.

      I have, right now, a pure etch distribution (which I installed after some
      painful hours without sleep) and I am using the stock firmware with the
      2.4.17_kuro-box kernel and loading a self-compiled (patched) 2.6.15 kernel
      with the loader.o trick (not uloader.o).

      I really want to get rid of these tricks and I have a "normal" system,
      with the recent kernels that I'm used to work with and to test the
      distribution on the Kuro-Box.

      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.

      I just wish to get precompiled binaries first and then seeing how they are
      done to incorporate whatever is needed for Debian (or, as a last resort, to
      keep a private, unofficial repository of packages ready for users who want
      to be completely Free, with a Free operating system).

      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.


      Thanks for your help, 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 Rogério, and sorry for the delay. ... I looked through the thread in the forum. I didn t quite understand, in one your post you write: I have some
      Message 2 of 14 , Sep 7, 2008
      • 0 Attachment
        Hi Rogério,

        and sorry for the delay.

        On Mon, 1 Sep 2008, Rogério Brito wrote:

        > > > I would like to change the state of things, to have them packaged in
        > > > systematic ways so that users (and that includes me) can only install
        > > > some packages and forget about the differences between a Kurobox
        > > > standard and a plain NewWorld Macintosh or a common x86 machine. That's
        > > > my purpose and I would appreciate any help that I can get, since I know
        > > > very little about this machine.
        > >
        > > Well, if you have time, sure, would be nice. But just think how many
        > > people will benefit from your work? Those ppc-based machines are not
        > > produced any more. There are some others, I think, based on the same
        > > CPU...
        >
        > Well, the userland is simply the same as the other powerpc binaries and, as
        > such, I would use it for development (that's the purpose of Charles Plessy
        > having sent me the Kuro Box). And it would also be a learning experience
        > and, perhaps, this learning experience could be materialized in support for
        > another sub-architecture of powerpc.
        >
        > Now, I would like to ask your help here. As you mentioned to me on an
        > earlier post, I went to some forums and wikis and consulted their
        > documentation, but I am still unsure of many things and I would appreciate
        > your help here, since you seem to be knowledgeable about these boxes.
        >
        > I have, right now, a pure etch distribution (which I installed after some
        > painful hours without sleep) and I am using the stock firmware with the
        > 2.4.17_kuro-box kernel and loading a self-compiled (patched) 2.6.15 kernel
        > with the loader.o trick (not uloader.o).
        >
        > I really want to get rid of these tricks and I have a "normal" system,
        > with the recent kernels that I'm used to work with and to test the
        > distribution on the Kuro-Box.
        >
        > 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.
        >
        > I just wish to get precompiled binaries first and then seeing how they are
        > done to incorporate whatever is needed for Debian (or, as a last resort, to
        > keep a private, unofficial repository of packages ready for users who want
        > to be completely Free, with a Free operating system).
        >
        > 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?

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

        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. Secondly, I don't have much free
        time ATM, so, even email replies might be delayed. 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.

        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;

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

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

        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 know I am subjective, but I think, my two
        sample programmes I've sent you go in the right direction. Do not install
        any custom init-scripts and do not try to programme yet another boot /
        reboot / shutdown subsystem. 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.

        Thanks
        Guennadi
        ---
        Guennadi Liakhovetski, Ph.D.
        Freelance Open-Source Software Developer
      • 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 3 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 4 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.