Hey PacoLM,
You're too kind, I don't deserve any credit. (Big sigh of relief over here, too.)
Okay, so it looks like that original script, with the "nandwrite" managed to trash your kernel. I still don't know what happened to the U-Boot variables, but we got bootloader, so that makes things much easier.
We have not see the output of the script, but it seems as if it went to completion. In that mode, the last thing the script does is "try" to reflash the kernel. . . So, that means the modules for the new kernel were
probably installed into your /lib directory.
I agree, the best bet seems to follow part of the instructions at
http://www.plugcomputer.org/plugwiki/index.php/Reflashing_images_on_the_GuruPlug , but I would suggest only one part at at time.
1. I would first only "
Burn the Kernel image" and then try to reboot the system.
(If you can't bring up a TFTP server, the same thing can be done from USB or SD Card.)
1.a. If the boot fails because of the file system, then follow the step "
Burn the Rootfs image"
1.b. If the boot fails because of the kernel, then maybe the U-Boot must be updated (
http://www.plugcomputer.org/index.php/us/resources/downloads?func=select&id=15 )
Once the factory kernel is booting again, then we can reconsider options for a kernel upgrade.
--------
There is something in your U-Boot variables and also on that page
http://www.plugcomputer.org/plugwiki/index.php/Reflashing_images_on_the_GuruPlug that is a curiosity. It is this line:
x_bootcmd_kernel=nand read.e 0x6400000 0x100000 0x400000
This line seems to tell U-Boot to load the kernel from Flash into RAM address 0x6400000. That is 100 MB from the base of the RAM.
This looks like someone used 0x6400000 as a location for a
tftpboot command, and then mistakenly copied it into x_bootcmd_kernel and x_bootcmd.
The first few lines U-Boot prints after a reboot should say something about addresses 0x800000 - 0x0 being saved for U-Boot. This means that the first 8 MB of memory is reserved for the bootloader, and nothing should be loaded into any address lower than 0x800000. So, normally, the kernel is loaded into the next available address, 0x800000.
At least one person with a Guruplug is loading the kernel into this address:
http://plugcomputer.org/plugforum/index.php?topic=1722.msg11467#msg11467 .
It is theoretically possible that the memory manager can handle empty RAM both below and above the kernel. But, it would not be surprising if that 92 MB between the boot loader and the kernel was unavailable.
When you get into your system again, shortly after the boot, why don't you try the command
free from the root login.
If the system memory seems unexpectedly low, it should be easy to fix and just as easy to back out if needed.
(If you change the one 0x6400000, then the second one must also be changed.)
