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

18634Re: [nslu2-linux] flashing apex from redboot

Expand Messages
  • Rob Lockhart
    May 1, 2007
    • 0 Attachment
      On 4/29/2007 7:16 AM EST, Phil Endecott wrote:
      > Rob wrote:
      >> Those wiki instructions (Debian/CompileApex) are very dated
      >> indeed - referring to a very old version of Apex.
      > They're about 6 months old. I promise you there is a lot of much older
      > and more out of date stuff on the nslu2 Wiki!
      > As far as I can see nothing much has changed i.e. all of the commands
      > are still correct (apart from the version number in wget of course).
      > If you disagree please let me know and/or fix the page.

      Yes I agree. It wasn't a "slam" on you guys by any means... it was more
      an appeal for those of us that can't recompile LE/BE/etc. with our eyes
      closed (like me), that sometimes we need explicit instructions, until we
      get comfortable enough in doing it. It seems that the "make menuconfig"
      options I see are different than the options given in the Wiki. It
      shows me such things as "Enable Experimental Features", "CPU
      endian-ness", "IXP42X Implementations (Linksys NSLU2)". I didn't see
      any such options as:
      . change CROSS_COMPILE to arm-linux-gnu- (looks like it is missing a
      . change default kernel command line as required (example would be
      helpful here)

      I could always try every option, build hundreds of APEX versions, and
      then reboot until I'm blue in the face until I realize what does or
      doesn't work. I guess I'm a little spoiled by the official linux
      (x86-based) in that when you build a kernel, most everything works and
      what isn't working is fairly well-documented in the "make menuconfig"
      help function on every item. But in the case of Apex for ARM, lots of
      this is unknown to newbies like me. :-) I really do appreciate your
      help as well as Gordon and others in demystifying this (and helping of
      course to update the Wiki).

      >> Since the
      >> makefile specifies whether Apex is LE or BE, I am not even sure if the
      >> endianness swapping (per the wiki) is even necessary anymore.
      > Can you elaborate on that a bit? Which makefile? Do you mean in the configuration?
      > Remember that APEX is still being loaded by the big-endian Redboot. I
      > think this is why we need to byte-swap it. But the endianness of the
      > NSLU2 boot process and the content of its flash is just a bit to
      > tortured for me to understand properly.

      I think Rod hit the nail on the head when he said the master Makefile
      (in another email in this thread). That is what I had downloaded in
      ~slug/kernel directory. I am not sure if that makefile somehow
      overwrote the makefile in the extracted ~slug/kernel/apex-1.4.18
      directory but with "make menuconfig", some of the assumptions and/or
      work-arounds might not even be necessary anymore. Specifically, you can
      compile Apex for LE or BE. I think I compiled it for LE, unless I'm

      >> Furthermore, there are a bunch of new stuff in the menuconfig (i.e.,
      >> ping, DHCP, TFTP, enable IXP4xx ethernet, FAT/EXT2/JFFS filesystem,
      >> etc.). Not sure if all of this works (since IXP4xx ethernet depends on
      >> microcode) so I'm not sure if Apex has network support yet.
      > It won't even compile if you enable the DHCP or BOOTP options. I have
      > not yet discovered whether any other networking stuff works. I suspect
      > not. Anyone wanting to "net boot" i.e. to load the kernel by TFTP
      > would be best advise to use a full version of Redboot. However, APEX
      > does work for a flash-resident kernel and NFS root filesystem (I have
      > done this).
      Thanks - saves me the effort of trying it! It would be nice, but for
      now using the ENV options are certainly sufficient. Main thing is
      getting it to a point when we can do everything RedBoot can do, so then
      we can gracefully think of RedBoot workarounds as "those things we had
      to do in the past."

    • Show all 16 messages in this topic