Hi, Mike:

I had been making my own set of gcc cross-compilers to cross-build
my ttylinux distribution, but I've switched to using crosstool-ng.

Maybe ttylinux can help you in some way, maybe with some
modifications; it is fairly easy to hack(I say that but I made it).
ttylinux is basically a cross-built kernel and busybox; it boots to
RAM Disk and has an install script that transfers the whole system
to a flash drive.
http://ttylinux.net/

Look me up. I work in the same building you do.


On 05/13/14 14:39, Mike Bushroe 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