Re: Anyone with experience in Cross-Compiling, especially t…

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