Mike,
It's been a long time since I had to build a cross compiler. What a bear
that task is! I fought and researched and learned a lot about it. Still
what ultimately helped me accomplish it was the work that was started by
Dan Kegel on a tool called crosstool.
http://kegel.com/crosstool/
That tool didn't have exactly the support for what I needed at the time but
I found it cleanly designed and easily updatable to accomplish what I was
targeting (Which was ppc from x86).
Building a toolchain takes many hours of compiling and lots of frustrations
when some error during the process... Im not sure if crosstool has been
updated in a long time but it might be worth looking at least as some
instructions in script form.
Good luck!
On Tue, May 13, 2014 at 2:39 PM, Mike Bushroe <
mbushroe@gmail.com> wrote:
> I am working on the switch/routers that form the backbone of the Space
> Station LAN (Joint Station LAN or JSL). The ppc processors that control the
> switching fabric, perform the routing functions, SNMP, and all other
> network functions are about 10 years old. Parts of the Flash have been
> updated frequently for Firmware Upgrades. But the OS files (Linux
> 2.4.22-1.3 "Red Haggis" Kernel) have never been refreshed and are at the
> end of the manufacture's data retention time. It looks like I may need to
> cross-compile a stripped down version of busybox, load it into the ramdisk,
> change root to the ramdisk, unmount then remount (?) the Flash drive to
> make sure no files are active, then run a script to go through every file
> in the system to copy it, md5sum old and new, if no errors delete the old
> and rename the new.
>
> From what I have read so far, this will require getting a copy of the
> kernel header files, which the vendor of the card is not currently willing
> to do. The next best would be to get the generic header files for this or a
> close release and use those. I am also confused about this process. The
> header files define the functions and variables, but not their address in
> memory. I am assuming that dynamic linking to the kernel function happens
> when the program starts, or are the function calls all sent to one address
> which then determines which call was requested and branches of to the
> correct code? Or is there another file(s) that contains the loader
> information on the kernel routines and I will need to find or decipher that
> too before a successful cross-compile can happen?
>
> Sorry to dump a tough one on the group when I have added little
> recently, but if I can get this going soon enough, it might actually get
> used on the flight hardware. Otherwise it will be deemed a 'science
> project' and cancelled in favor of just copying over the minimum number of
> system files to run the script and using that instead of a stripped busy
> box. On the other hand, if I can get this to work, I can also tweak the
> nandflash calls to attempt to recover bad blocks that are only bad because
> the data aged out. Currently, all the programs that work with nand flash
> don't allow any interaction with marked bad blocks. But if the blocks only
> failed because the data evaporated, a few write - erase cycles should
> freshen it back up to being fully functional and probably just as reliable
> as the blocks that hadn't aged out yet!
>
>
> Mike
> --
> "Creativity is intelligence having fun." — Albert Einstein
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss
(text/plain)