Ok, pardon my dumbness, but let me back up a bit.

First, lets look at the switch/router things:

(And I should first ask what flash controller is being used – does it automatically do ‘read scrub’ or other techniques to get around this whole issue? If so, you don’t need to do anything…)

Can you log in (as root, or become root) on the switches/routers?

If so, can you ‘see’ all the files you’d have to change?

If so, why not copy ‘in place’. That is, copy the whole thing (or parts of it) to a new directory, then rename everything to the new place.

So, for example, lets say you had /bin, /etc, and /var you wanted to do this to. /bin has 200M, /etc has 10M, and /var has 1G. Your flash has 2G free.

So, ‘mkdir /bin.new /etc.new /var.new ; cd /bin ; tar cf – . | ( cd /bin.new && tar xf - ) ;cd /etc; tar cf – . | (cd /etc.new && tar xf -) ; cd /var ; tar cf - . | (cd /var.new && tar xf -)’

That gets you 3 new dirs., /bin.new /etc.new and /var.new. Do your MD5 sums across the world and compare.

Now, rename everything: ‘mv /bin /bin.old ; /bin.old/mv /bin.new /bin ; mv /etc /etc.old ; mv /etc.new /etc ; mv /var /var.old ; mv /var.new /var’.

Ok, so now new is new and old is old. Delete old as you see fit, but probably after a reboot ;-)

Beware that when you move /bin suddenly you won’t have mv available any more, so you have to say /bin.old/mv to be able to use it.

No new kernel needed.

On the other hand, if you have no choice but to make a kernel, ‘everything you need’ should be there when you get the kernel source. Other than special hardware that requires special drivers, just ‘build it and they will come’. Or rather, build it and it will run. All the majic of linking and all that is taken care of for you. The only thing where absolute addresses is needed is (as far as I can remember right now) just hardware.

Good luck, Mr Phelps!

Rusty

From: plug-discuss-bounces@lists.phxlinux.org [mailto:plug-discuss-bounces@lists.phxlinux.org] On Behalf Of Mike Bushroe
Sent: Tuesday, May 13, 2014 2:39 PM
To: plug-discuss@lists.phxlinux.org
Subject: Anyone with experience in Cross-Compiling, especially to an embedded powerPC?

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