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

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

Expand Messages
  • Guennadi Liakhovetski
    ...a couple more things that probably won t be so easy to find: yes, you certainly want to work with lenny / sid, which needs a recent kernel, so, you want the
    Message 1 of 14 , Aug 27, 2008
    • 0 Attachment
      ...a couple more things that probably won't be so easy to find:

      yes, you certainly want to work with lenny / sid, which needs a recent
      kernel, so, you want the newest, and that one needs a recent u-boot
      (unless you want to mess up with a wrapper - which is not yet supported
      for LS / Kuro, as far as I know, and I don't know how difficult it would
      be to get it working). Kurobox-HD is not working in the mainline U-Boot,
      so, you need the patched version. Installing a new U-Boot is risky, so,
      you want Jtag... You might be able to find pre-built u-boot binaries, and
      if you select the correct one and don't make any mistakes during the
      installation, it will work. However, it still quite easy to make a mistake
      there and they are usually fatal (i.e., require Jtag).

      Regards
      Guennadi
      ---
      Guennadi Liakhovetski, Ph.D.
      Freelance Open-Source Software Developer
    • Rogério Brito
      ... Do you mean kernels 2.6.25+? At www.genbako.com, I saw a patch to kernel 2.6.25, but I don t know what support the newer mainline kernels have. ... I do
      Message 2 of 14 , Aug 27, 2008
      • 0 Attachment
        On Aug 27 2008, Guennadi Liakhovetski wrote:
        > On Wed, 27 Aug 2008, Rogério Brito wrote:
        > > Which kernel are you using? I see that your programs use 2.6
        > > interfaces, if I'm not mistaken. BTW, has anybody tried to send those
        > > patches available at www.genbako.com upstream? I think that the people
        > > at ozlabs would include that support (whishful thinking here).
        >
        > PPC Linkstation / Kurobox platforms are supported by the current
        > mainstream kernel and (partially) U-Boot.

        Do you mean kernels 2.6.25+? At www.genbako.com, I saw a patch to kernel
        2.6.25, but I don't know what support the newer mainline kernels have.

        > Please, search the wiki / Forums for installation instructions.

        I do have spent some time (and even mirrored everything that I could)
        reading about the various solutions, but they mostly seem to be "partition
        the HD in Emergency Mode with mfdisk, mount the HD at /mnt, unpack this
        prebuilt tarball and this will boot with a module loader.o, with which you
        can load a newer kernel".

        This seems to me that the function of loader.o would be like a kexec.

        > Looks like you have spent _very_ little time there if you still haven't
        > found out what kerel versions run on these platforms.

        Maybe I just didn't know what to look for. Please, don't have a negative
        view of my efforts. I'm just trying to learn (and my self-esteem seems to
        be very low).

        Regarding your other e-mail and the JTAG interface, from what I understand
        (the pictures that I saw in the wiki @...-central.org---it is there
        that I read about "Kuro Project Debian" and "Kuro Project Sylver"), I would
        have to solder the cable of the interface and I'm afraid of doing something
        wrong (especially finding such a cable here in Brazil).

        I already did something more recent than what is described on
        <http://buffalo.nas-central.org/index.php/Debian_install>, which seems to
        be a plain woody install (I took the basedebs.tar from woody, unpacked,
        updated to sarge, and then updated to etch).

        The other image, Sylver's, seem to have a kernel that is made for the Kuro
        HG, not the plain Kuro, like the one that I have. :-(

        Also, the link
        <http://sylver78.free.fr/kernel-2.6.20.2_kurobox_universal-20070313_testing.tar.gz> seems to be broken, which is, according to the changelogs on
        <http://buffalo.nas-central.org/index.php/Debian_sylver>, is the only
        kernel image with support for the tulip driver. :-(

        As you can see, I have not read that little as it may seem.


        Thanks for your help so far, 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, you didn t cc this rreply to me, so, I only saw it now. ... I mean vanilla sources from kernel.org. Your model should be supported by it directly without
        Message 3 of 14 , Aug 28, 2008
        • 0 Attachment
          Hi,

          you didn't cc this rreply to me, so, I only saw it now.

          On Wed, 27 Aug 2008, Rogério Brito wrote:

          > On Aug 27 2008, Guennadi Liakhovetski wrote:
          > > On Wed, 27 Aug 2008, Rogério Brito wrote:
          > > > Which kernel are you using? I see that your programs use 2.6
          > > > interfaces, if I'm not mistaken. BTW, has anybody tried to send those
          > > > patches available at www.genbako.com upstream? I think that the people
          > > > at ozlabs would include that support (whishful thinking here).
          > >
          > > PPC Linkstation / Kurobox platforms are supported by the current
          > > mainstream kernel and (partially) U-Boot.
          >
          > Do you mean kernels 2.6.25+? At www.genbako.com, I saw a patch to kernel
          > 2.6.25, but I don't know what support the newer mainline kernels have.

          I mean vanilla sources from kernel.org. Your model should be supported by
          it directly without any further patches. However, I cannot verify, since I
          don't have this hardware.

          > > Please, search the wiki / Forums for installation instructions.
          >
          > I do have spent some time (and even mirrored everything that I could)
          > reading about the various solutions, but they mostly seem to be "partition
          > the HD in Emergency Mode with mfdisk, mount the HD at /mnt, unpack this
          > prebuilt tarball and this will boot with a module loader.o, with which you
          > can load a newer kernel".
          >
          > This seems to me that the function of loader.o would be like a kexec.

          Yes, that would be a possibility for you - use that uloader.o or whatever
          it is called to load a new u-boot, then use it to start a recent kernel,
          which would allow you to use a recent distribution:-)

          > > Looks like you have spent _very_ little time there if you still haven't
          > > found out what kerel versions run on these platforms.
          >
          > Maybe I just didn't know what to look for. Please, don't have a negative
          > view of my efforts. I'm just trying to learn (and my self-esteem seems to
          > be very low).

          I just tried to prevent you from wasting your time on hopelessly old
          software.

          Otherwise, I am afraid, I cannot help you with specific instructions which
          would suit you best. Try to search for uloader.o suitable for your system
          (no, not loader.o - you want to load a new u-boot version, not the
          kernel), and try to start from there.

          Thanks
          Guennadi

          > Regarding your other e-mail and the JTAG interface, from what I understand
          > (the pictures that I saw in the wiki @...-central.org---it is there
          > that I read about "Kuro Project Debian" and "Kuro Project Sylver"), I would
          > have to solder the cable of the interface and I'm afraid of doing something
          > wrong (especially finding such a cable here in Brazil).
          >
          > I already did something more recent than what is described on
          > <http://buffalo.nas-central.org/index.php/Debian_install>, which seems to
          > be a plain woody install (I took the basedebs.tar from woody, unpacked,
          > updated to sarge, and then updated to etch).
          >
          > The other image, Sylver's, seem to have a kernel that is made for the Kuro
          > HG, not the plain Kuro, like the one that I have. :-(
          >
          > Also, the link
          > <http://sylver78.free.fr/kernel-2.6.20.2_kurobox_universal-20070313_testing.tar.gz> seems to be broken, which is, according to the changelogs on
          > <http://buffalo.nas-central.org/index.php/Debian_sylver>, is the only
          > kernel image with support for the tulip driver. :-(
          >
          > As you can see, I have not read that little as it may seem.
          >
          >
          > Thanks for your help so far, 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
          >
          > ------------------------------------
          >
          > Yahoo! Groups Links
          >
          >
          >

          ---
          Guennadi Liakhovetski, Ph.D.
          Freelance Open-Source Software Developer
        • Rogério Brito
          Hi, Guennadi. Thanks for your helpful answers. I m adding back the debian-powerpc and debian-embedded lists to the CC so that more people can benefit from your
          Message 4 of 14 , Aug 28, 2008
          • 0 Attachment
            Hi, Guennadi.

            Thanks for your helpful answers. I'm adding back the debian-powerpc
            and debian-embedded lists to the CC so that more people can benefit
            from your knowledge.

            On 28/08/2008, at 17:31, Guennadi Liakhovetski wrote:
            > you didn't cc this rreply to me, so, I only saw it now.

            Sorry. My mutt followed the Reply-To when I pressed "group reply". :-(

            > On Wed, 27 Aug 2008, Rogério Brito wrote:
            >
            >> On Aug 27 2008, Guennadi Liakhovetski wrote:
            >>> PPC Linkstation / Kurobox platforms are supported by the current
            >>> mainstream kernel and (partially) U-Boot.
            >>
            >> Do you mean kernels 2.6.25+? At www.genbako.com, I saw a patch to
            >> kernel
            >> 2.6.25, but I don't know what support the newer mainline kernels
            >> have.
            >
            > I mean vanilla sources from kernel.org.

            That's excellent, as that is what I would use anyway, without knowing
            it further.

            > Your model should be supported by it directly without any further
            > patches. However, I cannot verify, since I don't have this hardware.

            And do you know the status of the dtc thing? Does it still need to be
            done?

            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.

            For instance, it one thing that was new to me was the necessity of
            having a daemon like avr_evtd (or the programs you sent me attached
            before).

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

            The dtc thing was also news to me, even though I had used Linux on
            PowerPC for some time now.

            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.

            >>> Please, search the wiki / Forums for installation instructions.
            >>
            >> I do have spent some time (and even mirrored everything that I could)
            >> reading about the various solutions, but they mostly seem to be
            >> "partition
            >> the HD in Emergency Mode with mfdisk, mount the HD at /mnt, unpack
            >> this
            >> prebuilt tarball and this will boot with a module loader.o, with
            >> which you
            >> can load a newer kernel".
            >>
            >> This seems to me that the function of loader.o would be like a kexec.
            >
            > Yes, that would be a possibility for you - use that uloader.o or
            > whatever
            > it is called to load a new u-boot, then use it to start a recent
            > kernel,
            > which would allow you to use a recent distribution:-)

            I would like to take some conservative steps before proceeding with
            further, more risky ways. That's what my (limited) mathematical
            background tells me. :-)

            >>> Looks like you have spent _very_ little time there if you still
            >>> haven't
            >>> found out what kerel versions run on these platforms.
            >>
            >> Maybe I just didn't know what to look for. Please, don't have a
            >> negative
            >> view of my efforts. I'm just trying to learn (and my self-esteem
            >> seems to
            >> be very low).
            >
            > I just tried to prevent you from wasting your time on hopelessly old
            > software.

            Thanks for your concern. It is much appreciated. Indeed, I saw that
            much of the information seems to be dated by now (e.g., some of the
            posts on the wiki are dated back to 2006 or earlier and much has
            changed since then).

            > Otherwise, I am afraid, I cannot help you with specific
            > instructions which
            > would suit you best. Try to search for uloader.o suitable for your
            > system
            > (no, not loader.o - you want to load a new u-boot version, not the
            > kernel), and try to start from there.

            Thanks. Didn't know that and what I read led me to think that
            loader.o would be the tool to use to load a newer kernel.


            Thanks again, Rogério Brito.

            P.S.: I'm leaving the part below as a reference to Debian lists of
            what I did to get things working up to my current state.

            >
            >> Regarding your other e-mail and the JTAG interface, from what I
            >> understand
            >> (the pictures that I saw in the wiki @...-central.org---it
            >> is there
            >> that I read about "Kuro Project Debian" and "Kuro Project
            >> Sylver"), I would
            >> have to solder the cable of the interface and I'm afraid of doing
            >> something
            >> wrong (especially finding such a cable here in Brazil).
            >>
            >> I already did something more recent than what is described on
            >> <http://buffalo.nas-central.org/index.php/Debian_install>, which
            >> seems to
            >> be a plain woody install (I took the basedebs.tar from woody,
            >> unpacked,
            >> updated to sarge, and then updated to etch).
            >>
            >> The other image, Sylver's, seem to have a kernel that is made for
            >> the Kuro
            >> HG, not the plain Kuro, like the one that I have. :-(
            >>
            >> Also, the link
            >> <http://sylver78.free.fr/
            >> kernel-2.6.20.2_kurobox_universal-20070313_testing.tar.gz> seems
            >> to be broken, which is, according to the changelogs on
            >> <http://buffalo.nas-central.org/index.php/Debian_sylver>, is the only
            >> kernel image with support for the tulip driver. :-(
            >>
            >> As you can see, I have not read that little as it may seem.
            >>
            >>
            >> Thanks for your help so far, 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
            >>
            >> ------------------------------------
            >>
            >> Yahoo! Groups Links
            >>
            >>
            >>
            >
            > ---
            > Guennadi Liakhovetski, Ph.D.
            > Freelance Open-Source Software Developer

            --
            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
            ... 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
            Message 5 of 14 , Aug 29, 2008
            • 0 Attachment
              On Thu, 28 Aug 2008, Rogério Brito wrote:

              > > Your model should be supported by it directly without any further patches.
              > > However, I cannot verify, since I don't have this hardware.
              >
              > 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.

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

              > For instance, it one thing that was new to me was the necessity of having a
              > daemon like avr_evtd (or the programs you sent me attached before).

              This is platform-specific.

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

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

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

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