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. Thank you very much for your reply and for the attachments. ... Just trying to run anything newer than what came with the Kurobox, since the
    Message 1 of 14 , Aug 27, 2008
    • 0 Attachment
      Hi, Guennadi.

      Thank you very much for your reply and for the attachments.

      On Aug 27 2008, Guennadi Liakhovetski wrote:
      > On Wed, 27 Aug 2008, Rogério Brito wrote:
      >
      > > Just for the information of others, I'm booting the 2.4.17 kernel that
      > > came with the Kurobox (that's untouched) and I'm using the userland of
      > > Debian stable (Debian etch).
      >
      > I am not sure what you are trying to do with this software.

      Just trying to run anything newer than what came with the Kurobox, since
      the software that ships with it is so ancient (it seems to be from the
      woody era or earlier even).

      > AFAIU Debian development scheme, etch is "dead" by now, i.e., there won't
      > be anything new included in it, which also would make no sense now, that
      > lenny is (hopefully) only monthes away.

      Yes, I know that. I run sid on my system, with a custom built kernel
      tracking the current -rc* from kernel.org. I use sid mostly for my 3
      packages in Debian already.

      The reason why I "stopped" with etch on the Kurobox is that I could not
      upgrade to anything newer, because the version of glibc shipped with
      testing/unstable needs NTPL, which is only supported by kernels >= 2.6.8.

      I was also worried about loosing commands like "write_ok", "mfdisk" and
      similars.

      > Also 2.4.17 is, well, useless for any open source development.

      Unfortunately, I still don't know how to upgrade the kernel of the Kurobox
      (despite the fact that I'm used to kernel upgrades on ia32, amd64, and both
      OldWorld and NewWorld PPCs). Actually, I have not yet understood the
      Kurobox flow of boot process.

      > > I already fixed the other project which with I'm involved and I can now
      > > spend some time with the Kurobox. One of the first things that I want
      > > to do is to package the avr_evtd daemon and include it in Debian
      > > proper. Is there any effort to do that already?
      >
      > I have not spent much time with avr_evtd, just be aware, that there are
      > several similar daemons for the handling of the AVR chip on linkstations /
      > kuroboxes.

      I didn't know that. The avr_evtd daemon would benefit from a facelift on
      its Makefile, its tarball and some of its code. I spent some time (just
      some hours) packaging it so that I could have one more package available
      from the distribution.

      I think that I would also need to have some init scripts shipped with the
      daemon, to issue the sequence of characters like EEEE to /dev/ttyS0.

      From what I saw, the device nodes /dev/fl*, /dev/AVR00 and the like are not
      strictly needed, are they?

      > Just for an example of what alternative approaches can be taken to handle
      > the chip I am attaching two simple programmes I am using on my kurobox-HG.

      Thanks for sharing them.

      > Their advantage is, that they are using standard input interfaces to
      > process buttons and support reboot, power off and suspend. Notice, that
      > suspend is (still) not supported by the mainline linkstatin kernel.

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


      Thanks, 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
      ... PPC Linkstation / Kurobox platforms are supported by the current mainstream kernel and (partially) U-Boot. Please, search the wiki / Forums for
      Message 2 of 14 , Aug 27, 2008
      • 0 Attachment
        On Wed, 27 Aug 2008, Rogério Brito wrote:

        > > Their advantage is, that they are using standard input interfaces to
        > > process buttons and support reboot, power off and suspend. Notice, that
        > > suspend is (still) not supported by the mainline linkstatin kernel.
        >
        > 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. Please, search the wiki / Forums
        for installation instructions. Looks like you have spent _very_ little
        time there if you still haven't found out what kerel versions run on these
        platforms.

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