Upgrade older PogoPlug Mobile flash to newer?

Hi,

I've come a long way to making NetBSD easy to install on PogoPlugs thanks to a lot of help from bodhi. My HOW-TO can be found here:

Install NetBSD on a PogoPlug

One of the things I've noticed is that there are at least two versions of uboot which come with PogoPlug Mobiles. One allows for conditionals (if, then, fi) and can be selectively booted into GNU/Linux depending on whether another machine is on the network at a specific address, but the older version does not have conditionals and reports this:

Hit any key to stop autoboot:  0 
Unknown command 'if' - try 'help'
Unknown command 'then' - try 'help'
This command can be used only if enaMonExt is set!

A version which works is:

U-Boot 1.1.4 (Oct  1 2011 - 12:21:35) Cloud Engines 1.1.2 (3.4.27)

A version which doesn't have conditionals is:

U-Boot 1.1.4 (Jul 16 2009 - 21:02:16) Cloud Engines (3.4.16)

Could someone tell me the simplest way to make a backup copy of the newer flash and write it to the flash of an older Mobile, either in GNU/Linux or via u-boot using tftp?

johnklos,

Use nanddump and nandwrite in Linux. Simplest. Remember to make sure the nandwrite uses the correct option that nanddump used regarding OOB. Also make sure to look at the usage for nanddump and nadwrite in your installation.

example: nanddump to /tmp/usb/

/tmp # ./nanddump -nf usb/mtd0 /dev/mtd0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00200000…

/tmp # ./nanddump -nf usb/mtd1 /dev/mtd1
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00300000...

/tmp # ./nanddump -nf usb/mtd2 /dev/mtd2
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00300000...
/tmp # ./nanddump -nf usb/mtd3 /dev/mtd3
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00800000...

/tmp # ./nanddump -nf usb/mtd4 /dev/mtd4
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x07000000...

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 03/21/2014 05:41PM by bodhi.

Nice How-To, I always wanted to try NetBSD, but never succeeded. Last try (only booting kernel without rootfs, built it using SHEEVAPLUG config) however resulted in serial console garbage, regardless of my baud rate. I'll definitely try your kernel :-)
EDIT: works fine. Maybe my build failed because it's based on 6.1.3 instead of -CURRENT? Or does something in your config significantly differ from SHEEVAPLUG (although it's based on it)?



Edited 2 time(s). Last edit at 03/21/2014 06:24PM by ebbes.

Ah. Thank you! I've just used flash contents from the newer (3.4.27) PogoPlug Mobile onto two older ones (3.4.16). Neither of them could boot into GNU/Linux, so I did it from u-boot. I noticed that if I erased and flashed each section in turn, there were read issues, so I erased the whole 128 megs at once, then flashed each section, like so:

setenv ipaddr 10.12.26.88
setenv serverip 10.12.26.55

tftp 0x800000 mtd0_r
nand erase 0x0 0x8000000
nand write.e 0x800000 0x0 0x200000
tftp 0x800000 mtd1_r
nand write.e 0x800000 0x200000 0x300000
tftp 0x800000 mtd2_r
nand write.e 0x800000 0x500000 0x300000
tftp 0x800000 mtd3_r
nand write.e 0x800000 0x800000 0x800000
tftp 0x800000 mtd4_r
nand write.e 0x800000 0x1000000 0x7000000

I did the tftp before the erase in case networking wasn't working, of course. I dumped them from within GNU/Linux without the OOB data onto a USB stick (for mtd0 through mtd4):

./nanddump -nf /tmp/.cemnt/mnt_sdb1/mtd0_r /dev/mtd0

The only thing that stands out is that I have no idea where the environment variables get stored. Do they get stored in OOB sectors in the flash? I noticed that they got set to some factory default or something like that and I had to reset several in order to boot as I prefer:

setenv init_mmc 'mw f1010004 11113311; mw f1010008 551111'
setenv boot_bsd 'run init_mmc; nand read.e 0x800000 0x800000 0x500000; bootm 0x800000'
setenv bootcmd 'if ping 192.168.58.254; then run boot_nand; fi; run boot_bsd'
setenv ipaddr 192.168.58.233
setenv serverip 192.168.58.188
saveenv

ebbes: Thank you. I'd love to hear any feedback you have. The serial port issue, by the way, was one of the first things I ran across when I first tried NetBSD, too, but the fix is in the tree, so you can build a kernel from -current and it shouldn't give any problems.



Edited 1 time(s). Last edit at 03/21/2014 09:06PM by johnklos.

johnklos,

The original U-Boot store the envs at 0xA0000. Davygravy's built u-Boot stores it at 0xC0000 (the normal convention that Jeff has established). This is one of the good reasons why I defined them in the new U-Boot builds at 0xC0000. They can coexists and you can choose to boot different rootfs without having to worry about redefining them. And when you booted in to Debia/Arch, use blparam for the old envs (different checksum is calculated).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

johnklos Wrote:
-------------------------------------------------------
> ebbes: Thank you. I'd love to hear any feedback
> you have. The serial port issue, by the way, was
> one of the first things I ran across when I first
> tried NetBSD, too, but the fix is in the tree, so
> you can build a kernel from -current and it
> shouldn't give any problems.

Ahh, if I only knew that... Okay, so I'll need -current. And a rootfs, maybe I'll build one when I have some time.
By the way: what filesystems does NetBSD support as rootfs? ext2? I know that FreeBSD uses UFS or ZFS (okay, ZFS on kirkwood is no good idea, but NetBSD doesn't support it anyway afaik?), but UFS isn't the most Linux-friendly filesystem I know (and I have to somehow get the files onto it using a Linux machine).
And another question: Why do you suggest putting kernel in NAND? Wouldn't it be better to place it on rootfs partition (or - in case of filesystem not supported by U-Boot - on another ext2 partition) and have U-Boot load it from there? Or is this just common NetBSD practice?

Hi,

> By the way: what filesystems does NetBSD support
> as rootfs? ext2? I know that FreeBSD uses UFS or
> ZFS (okay, ZFS on kirkwood is no good idea, but
> NetBSD doesn't support it anyway afaik?), but UFS
> isn't the most Linux-friendly filesystem I know
> (and I have to somehow get the files onto it using
> a Linux machine).

ZFS is an option, but I haven't played with it. AFAIK there are kernel modules for amd64 and i386, but if they were written properly they should compile fine for ARM.

I haven't tried ext2fs as root, but it seems like it should be fine:
http://mail-index.netbsd.org/current-users/2012/06/28/msg020532.html

I may make some images available much like Jun Ebihara is doing for Raspberry Pis:
http://mail-index.netbsd.org/port-arm/2014/03/21/msg002300.html

> And another question: Why do you suggest putting
> kernel in NAND? Wouldn't it be better to place it
> on rootfs partition (or - in case of filesystem
> not supported by U-Boot - on another ext2
> partition) and have U-Boot load it from there? Or
> is this just common NetBSD practice?

The reason I put the kernel in NAND is because I had too many problems with alternate u-boots (probably my fault). I couldn't get them to reliably boot off of SD or USB, and most of the PogoPlugs don't support MMC or USB booting without modifying u-boot, so I tried this instead. I wanted to make it so that anyone can use PogoPlugs with NetBSD even if they're not the soldering type, and I wanted to keep GNU/Linux as an option so people can always flash updates.

Obviously if you have a serial console or have installed another u-boot, you can boot from wherever or tftp boot, but I like the way this works so far :)

Just FYI, I'll revisit my HOW-TO after we see where the "Kirkwood U-boot - Getting all supported Kirkwoods on-board" thread leads. If there's a simple, consistent way to install a single u-boot on any PogoPlug which would give us options to boot off of USB, MMC or SATA, I'd love that!

Johnklos,

If you can get ZFS to compile on these plugs. I'd like to know! I've tried it about a year ago, but it failed because ARM was not supported then.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

ZFS on a 128MB ram ARMv5 device is a bad choice. Just saying.

Yeah:) I am aware that it'd take at least 1GB to run ZFS. Just want to see if it can be compiled on ARMV5

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Can it be compiled? Yes. Do you want to do that? No.

WarheadsSE Wrote:
-------------------------------------------------------
> Can it be compiled? Yes. Do you want to do that?
> No.

Why? Is there any technical reason not to?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Because it _can_ be compiled on v5, there is no point in doing it since it can't even be used in such a device.

Well, you could use ZFS on Kirkwood devices if you disable some features. But without these features, ZFS would totally suck. So there's absolutely no point in using it.

I wouldn't agree at all that there's no point in compiling ZFS. First, it's good to exercise the codebase. Second, there are plenty of ARM devices available with 1 or 2 gigs of memory, and ARM devices are good candidates for moving servers to the storage as opposed to the other way around.

People say there's "absolutely no point" in keeping a modern operating system running on VAX hardware, but that's demonstrably not true.

johnklos,

> People say there's "absolutely no point" in keeping a modern operating system running on VAXhardware, but that's demonstrably not true.

Well said :)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)