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

Re: Help supporting Debian on a Kurobox

Expand Messages
  • Rogério Brito
    Dear people, It seems that I ve made some progress. I m taking debian-devel out of the Cc ies. ... I m a bit reluctant to go to extremes right now with the
    Message 1 of 14 , Aug 23, 2008
    View Source
    • 0 Attachment
      Dear people,

      It seems that I've made some progress. I'm taking debian-devel out of
      the Cc'ies.

      On 22/08/2008, at 12:11, Rogério Brito wrote:

      > On Aug 22 2008, Sven Luther wrote:
      >> Ok. It is possible that you could attach a serial console, but this
      >> involves some soldering on the board. Search the web for
      >> instructions on
      >> how to do this.
      >
      > I don't even know if the kernel has serial support compiled in. I will
      > check this.

      I'm a bit reluctant to go to extremes right now with the JTAG
      interface and u-boot (BTW, thanks to everybody who has replied).

      I'm happy to report that after some hours chrooting the thing,
      configuring things etc, I'm able to use an etch userspace on this
      Kurobox, which is quite an improvement regarding the software it came
      with.

      I *do* plan on packaging the kernel/working on another flavor once
      that I'm comfortable with the userspace (I guess that I should do
      this in one week, since I have one project that needs to hurry with a
      release, due to some problems).

      For the people at the Linkstation General mailing list that may have
      not followed the threads, I intend to integrate support of the
      Kurobox (I have a plain one, not HG) on the main Debian release, so
      that specific releases wouldn't seem necessary. I hope that Sylver
      and others working on these distributions want to join forces with me
      to get a better Universal Operating System.

      I see that there's quite a bit of information regarding the Kurobox
      and other Linkstations at:
      http://buffalo.nas-central.org/ and its subpages.

      But I think that we can "materialize" the information like
      <http://buffalo.nas-central.org/index.php/Debian_avr_evtd>
      into proper Debian packages for the Kurobox. In fact, I'm packaging
      it at this moment and will send more questions to debian-mentors
      regarding some corner cases.

      To be more concrete, here is what I see as my plan of action:

      * substitute the non-free watchdog daemon with a Free, debianized
      version;
      * modify the reboot/shutdown scripts (needed to get the unit to
      shutdown/reboot);
      * recompile the kernel to have everything under control of dpkg (and
      also to enjoy a more recent userspace, as newer glibc's need NTPL);
      * get a systematic way of updating the firmware/kernel that boots on
      the box.

      > It's just a common ppc box, with some additional things to light up
      > the
      > leds in case of a full HD and in case of shutting down the system.
      > It seems
      > that using a custom kernel with uboot looses some functionality,
      > though.
      > :-(

      If I'm mistaken here, I would be glad to be corrected.

      >> 1) U-boot is able to boot a uimage.
      >
      > Right, but how does one generate this uImage? Will it be side-by-
      > side of a
      > normal kernel image?

      From what I could figure out so far, it would be generated by a
      "make uImage", instead of the usual "make bzImage" (it's been ages
      since I compiled things without generating a package with Debian's
      kernel-package).

      >> So, the first order of business is to get your kurobox modified so it
      >> has a serial console, and see if you can get the uboot prompt,
      >> once you
      >> have this, things become an order of magnitude easier.

      Do you mean here, by "a serial console", the JTAG interface? I may
      need to get a proper cable. :-/

      > The heartbeat daemon seems to be available, though. I hope that it
      > works. I'm willling to package it.

      I'm testing it right now and I plan on releasing a package of it as
      soon as I get it properly packaged.

      >> This needs a packaged version of mkimage for powerpc, and
      >> probably some modifications of mkvmlinuz (or the kernel package
      >> directly).
      >
      > Which utilities would generate an uImage?

      I guess that this step could be the last one.


      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
    • Rogério Brito
      Hi there. Here is a question for those involved in Debian packaging. First of all, let me state my intended purpose: I want to provide as much support in
      Message 2 of 14 , Aug 27, 2008
      View Source
      • 0 Attachment
        Hi there.

        Here is a question for those involved in Debian packaging.

        First of all, let me state my intended purpose: I want to provide as much
        support in Debian proper as is feasible for the Kurobox and Linkstation
        (since I have a plain Kurobox and I want to run programs from this century
        on it).

        On Aug 23 2008, Rogério Brito wrote:
        > I'm a bit reluctant to go to extremes right now with the JTAG
        > interface and u-boot (BTW, thanks to everybody who has replied).

        I may now consider using the JTAG interface if that's what's needed to
        flash the firmware. I'm still uncertain of what the flow of the boot
        process of the Kurobox is.

        > I'm happy to report that after some hours chrooting the thing,
        > configuring things etc, I'm able to use an etch userspace on this
        > Kurobox, which is quite an improvement regarding the software it came
        > with.

        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 *do* plan on packaging the kernel/working on another flavor once
        > that I'm comfortable with the userspace (I guess that I should do
        > this in one week, since I have one project that needs to hurry with a
        > release, due to some problems).

        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 want to have as many files under the control of the packaging system as
        possible, since I want the Kurobox to face the outside and running an
        Intrusion Detection System is easier if all files are under control of
        dpkg.

        > For the people at the Linkstation General mailing list that may have
        > not followed the threads, I intend to integrate support of the
        > Kurobox (I have a plain one, not HG) on the main Debian release, so
        > that specific releases wouldn't seem necessary.

        I just mentioned the plain Kurobox, but I'm willing to support the other
        variants too, with a good package.

        > I hope that Sylver and others working on these distributions want to join
        > forces with me to get a better Universal Operating System.

        Is Sylver subscribed to this list? I have not received any feedback from
        people from this list.

        > I see that there's quite a bit of information regarding the Kurobox
        > and other Linkstations at:
        > http://buffalo.nas-central.org/ and its subpages.
        >
        > But I think that we can "materialize" the information like
        > <http://buffalo.nas-central.org/index.php/Debian_avr_evtd>
        > into proper Debian packages for the Kurobox. In fact, I'm packaging
        > it at this moment and will send more questions to debian-mentors
        > regarding some corner cases.

        I'm already packaging the Debian avr_evtd, but it will be necessary to
        patch a lot of things and the contact e-mail to the author of the daemon
        (lb-source@...) doesn't seem to be working. I would like
        to integrate my changes upstream, so that every distribution benefits from
        it.

        > To be more concrete, here is what I see as my plan of action:
        >
        > * substitute the non-free watchdog daemon with a Free, debianized
        > version;

        This is already a work in progress. If anybody has this packaged, please
        let me know and I'll concentrate my efforts in other areas.

        > * modify the reboot/shutdown scripts (needed to get the unit to
        > shutdown/reboot);

        I'm not exactly sure if the shutdown scripts need to be modified once
        avr_evtd is properly installed.

        > * recompile the kernel to have everything under control of dpkg (and
        > also to enjoy a more recent userspace, as newer glibc's need NTPL);

        The kernel that I have in mind would support both the Kurobox and the
        Kurobox HG, among others, and I would like to push the patches found at
        genbako upstream to the main kernel.org, so that no patching will be
        necessary for future kernels.

        > * get a systematic way of updating the firmware/kernel that boots on
        > the box.

        This is a step that I would take to have debian-installer working
        out-of-the-box on the Kuroboxes, once I understand completely how this
        system boots (with all the pivoting root and such).

        I hope to hear from other people soon.


        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
        ... I am not sure what you are trying to do with this software. AFAIU Debian development scheme, etch is dead by now, i.e., there won t be anything new
        Message 3 of 14 , Aug 27, 2008
        View Source
        • 0 Attachment
          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. 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. Also 2.4.17 is, well, useless for any open
          source development.

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

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

          Thanks
          Guennadi
          ---
          Guennadi Liakhovetski, Ph.D.
          Freelance Open-Source Software Developer
        • 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 4 of 14 , Aug 27, 2008
          View Source
          • 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 5 of 14 , Aug 27, 2008
            View Source
            • 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 6 of 14 , Aug 27, 2008
              View Source
              • 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 7 of 14 , Aug 27, 2008
                View Source
                • 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 8 of 14 , Aug 28, 2008
                  View Source
                  • 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 9 of 14 , Aug 28, 2008
                    View Source
                    • 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 10 of 14 , Aug 29, 2008
                      View Source
                      • 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 11 of 14 , Sep 1, 2008
                        View Source
                        • 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 12 of 14 , Sep 7, 2008
                          View Source
                          • 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 13 of 14 , Sep 10, 2008
                            View Source
                            • 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 14 of 14 , Sep 10, 2008
                              View Source
                              • 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.