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 - [email protected]
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss
---------------------------------------------------
PLUG-discuss mailing list - [email protected]
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss
