Flashing kernel to nand on pogoplug pro

[bramm]

Hi,

I've been compiling and testing a few kernels for the pogoplug pro. (3.1.10+ from warheadse, with the oxnas-ehci.c from redsquare123 and the Iomega p89626 kernel 2.6.31.14). I'm trying to get an arduino nano to work with usb. I finally found a way to make it stable, but it needs to be unplugged/replugged before it can be used. otherwise I still keep oxnas-ehci errors (-32) from the device enumeration if it's not first replugged. Then it stays healthy after a reboot if the power is not unplugged and ftdi_sio can be loaded normally. Strange eh? But I can work with this, Though I wish I knew a bit more about USB to fix this.

However
I tested all these with tftp and so far everything looks fine.

I'm ready to flash a kernel to nand, but I'm a bit wary.

I've read the oxnas-install.sh en oxnas-revert.sh scripts.

I have a few questions though.
How large can the kernel be at max?

This is the uImage:

Image Name: Linux-3.1.10+
Created: Mon Dec 17 12:30:33 2012
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3272064 Bytes = 3195.38 kB = 3.12 MB
Load Address: 0x60008000
Entry Point: 0x60008000
Image arch/arm/boot/uImage is ready

(this one is not very modular and I'll change that probably)

But if I would like to flash this one, is that possible?

say I would do the following;

/usr/sbin/flash_erase /dev/mtd1 0x500000 17
/usr/sbin/nandwrite -p -s 0x500000 /dev/mtd1 /my/uImage

would that be safe?

I'm scared that I'll screw up u-boot and I don't want to go there. Is u-boot located on /dev/mtd0 or also on /dev/mtd1?

another question
after the oxnas.install.sh is finished, are there 4 kernels in nand? 2 new ones with usb rootfs support from Arch Linux Arm and the two original ones?

original at 0x200000
new at 0x500000
original at 0x800000
new at 0xB00000


Thx for your time,

Bram

[WarheadsSE]

Spot on. If you are worried about screwing up uboot, skip NAND and boot entirely from SATA.

[bramm]

I want to boot into the ubifs and the device will be using wifi.
By screwing up u-boot I meant the bootloader, bricking the device which I would like to avoid.

is this a correct assumption?
/dev/mtd0 = uboot
/dev/mtd1= kernel location
/dev/mtd2= root fs

so It's safe to write in /dev/mtd1?

Thx

[WarheadsSE]

Nope.

mtd0 = everything
mtd1 = stage1 + uboot + kernel
mtd2 = rootfs ubi image.

[ckiick]

Here's what the partitions are:

/dev/mtd0 - overlay partition of the WHOLE of nand. Size 128M.
/dev/mtd1 - boot partition, contains stage1 bootloader, uboot, boot environment and kernel images. size 14M.
/dev/mtd2 - rootfs partition. Contains the original cloudengines OS. Size 114M.

I have two suggestions about how to do this safely.

1) MAKE BACKUPS. Use the nanddump utility to back up everything in mtd1.
- to back up stage1 and uboot so that it can be restored later:
# nanddump -n -l 0x200000 -f mtd1-uboot.dump /dev/mtd1
- to back up the rest of nand, including all copies of uImage:
# nanddump -n -o -s 0x200000 -f mtd1-uImage.dump /dev/mtd1
- to back up all of mtd1 without the OOB data
# nanddump -n -o -f mtd1-full.dump /dev/mtd1
- to back up all of mtd1 with the OOB data
# nanddump -n -f mtd1-oob.dump /dev/mtd1
The OOB data is needed for uboot and the boot environment because they use ECC codes. Stage1 and the kernel
images do not use ECC. Weird, I know.
Then copy the backup files to multiple locations on multiple machines. Trust me, YOU WANT BACKUPS.

2) Write a script instead of typing in the commands by hand. One slip (like missing a '0') and you'll be reading up on
booting from SATA. So write a script, check it, double check it, test it, and then check it again.

The size limit on kernels is currently 3MB. That's because of the space available in NAND. If you wanted to wipe out one
or both of the original kernels, you could go well beyond that. But then the revert script wouldn't work, and you'd have to
restore the original kernel to nand using one of your backups if you wanted to go back. 3M should be plenty if you use some
kernel modules instead of making everything built-in. Go through your kernel config carefully and take out or modularize the things you don't need to boot the system.

The commands to write a kernel to nand are going to look like this:
/usr/sbin/flash_erase /dev/mtd1 0x500000 24
/usr/sbin/nandwrite -p -s 0x500000 /dev/mtd1 /my/uImage

DO NOT erase more than 24 blocks. Make triply sure that you get the location of 0x500000 correct.
DO NOT nandwrite a file larger than 3MiB. If you go over then one of the original kernels gets clobbered. Which isn't
a catastrophe, since it's the backup copy, but you never know.

Good luck,

[bramm]

thanks a lot for your detailed explanation, I will give it a try.