Lede on Pogoplug Pro, Bad Magic Number

Hi all,

I'm trying to install Lede on the flash of a Pogoplug Pro (not sure if it's a V3 or not). I'm able to reach uboot via serial and transfer files into memory using tftpboot. I want to see if I can boot a kernel before committing it to flash. If I load lede-17.01.4-oxnas-pogoplug-v3-uImage into memory, I get:

CE>> bootm
## Booting image at 60500000 ...
Bad Magic Number

The same happens if I load lede-17.01.4-oxnas-pogoplug-v3-u-boot-initramfs.bin. (The *uImage and *u-boot-initramfs.bin files look like the best ones to try from the oxnas section of the Lede site.)

What does this mean?

If I load an image from another device, I get

## Checking Image at 60500000 ...
   Image Name:   Linux-2.6.35.14-00330-g86c6392
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1447568 Bytes =  1.4 MB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK

which means uBoot is recognizing it. Running mkimage -l locally shows that the Lede images I want to load are FITs, while the ones recognized by uBoot aren't.

Most of the instructions I've seen refer to booting Debian or Arch from a flash drive. Is there any way to get it to load Lede directly from flash? Do I need a new uBoot? The version is: U-Boot 1.1.2 (Jul 29 2010 - 19:36:07).

If I enter printenv, I get:

bootcmd=run boot_nand
bootdelay=2
baudrate=115200
autoload=n
bootfile="uImage"
kernflmode=s
load_nand=nboot 60500000 0 200000
load_nand2=nboot 60500000 0 800000
boot=bootm 60500000
boot_nand=run load_nand boot || run load_nand2 boot
ceboardver=PPRO1
stdin=serial
stdout=serial
stderr=serial
bootargs=root=ubi0:rootfs ubi.mtd=2,512 rootfstype=ubifs console=ttyS0,115200 elevator=cfq mac_adr=0x00,0x30,0xe0,0x00,0x00,0x01 mem=128M poweroutage=yes
filesize=1a7578
fileaddr=60008000
netmask=255.255.0.0
ipaddr=192.168.33.195
serverip=192.168.33.2

Am I missing something? Is there a standard way of loading firmware onto this device?

Any help or suggestions would be much appreciated; I've been stuck on this for a while now.

Check out at doozan forums, there is a lot of info about pogoplug, I have a Pogoplug Mobile, it is similar to the Series 4, but yours is different.
Here are my notes about the PogoPlug Mobile if you want to check it out just in case for reference: https://gist.github.com/braian87b/2f7e711ebdd48e7a7d37f286e5245b0d (based on: http://blog.qnology.com/2015/02/openwrt-on-pogoplug-mobile.html )
I think that these are the instructions for OpenWrt on your device, may be for Lede it will be similar: http://blog.qnology.com/2015/04/openwrt-on-pogoplug-v3oxnas-proclassic.html

That would be the first thing to check. Look at the sticker on the bottom and confirm which version you have. They usually carry an identifier like "B04" (that's the pink V3). AFAIR V3 and Pro don't differ that much, hardware-wise, but it would still be preferable to flash the correct one.

If you indeed have a PogoPlug V3 or Pro, and since you have a serial connection, the process is not very difficult.

The only complication is that the original uboot is quite limited. It can't boot OpenWrt/LEDE, and it can't flash anything.

The process is like this:

  1. Cancel booting in the original uboot
  2. Set the original uboot to boot to a second, better uboot (provided in the LEDE download directory). At this point, the better uboot is not on flash yet, but this preparation saves you from having to go back to the original uboot after you flash a better one in step 4.
  3. TFTP the better uboot into memory and boot into that better uboot, and immediately cancel its boot process
  4. Now that we are in a better uboot that is able to flash something, have it write itself to flash.
  5. TFTP an OpenWrt/LEDE image into memory and boot it
  6. From OpenWrt/LEDE, sysupgrade to OpenWrt/LEDE, this will write it to flash

The instructions how to do it are in the OpenWrt forum, and they do work. Just substitute the newer OpenWrt/LEDE files and filenames.

And yes, doing it like this first boots into the original uboot, then into the better uboot, and then into OpenWrt/LEDE. This only adds a few seconds to the boot process. You could directly replace the original uboot with the better one, but it's dangerous if something goes wrong. This way, youc an always fall back to the original uboot and try again.

Amazing, I didn't know that was possible.

I just realize that the process in the OpenWrt forum post is correct, but the annotations are not matching what is actually done. Maybe this step-by-step helps.

In the original uboot (after booting has just been canceled):

setenv ipaddr 192.168.1.1
setenv serverip 192.168.1.100

Sets up the device to be 192.168.1.1 and to receive from a TFTP server at 192.168.1.100.

tftp 64000000 openwrt-oxnas-ox820-u-boot.bin

Transfers the "better uboot" to memory at addess 0x64000000.

setenv boot_openwrt nand read 0x64000000 0x440000 0x90000 \; go 64000000
setenv bootcmd run boot_openwrt
saveenv

This gives the still original uboot a routine to read 0x90000 bytes from flash at 0x440000 into memory at 0x64000000, and then run the program at 0x64000000. Then it saves this routine to be run at boot. (The name "boot_openwrt" is actually a misnomer, since it doesn't boot OpenWrt yet, but a second uboot stage. But it doesn't matter that much.)

go 64000000

This starts whatever is at memory 0x64000000, this is the "better uboot" we just TFTPed there. The "better uboot" starts now and has to be canceled, too. Now in the second, "better uboot":

setenv ipaddr 192.168.1.1
setenv serverip 192.168.1.100

Again, set up TFTP parameters like before.

nand erase 0x440000 0x90000
nand write 64000000 0x440000 0x90000

This erases 0x90000 bytes at flash address 0x440000, and then writes whatever is at memory address 0x64000000 to address 0x440000 in flash. Which is the "better uboot" we are actualy currently running (remember we TFTPed it to 0x64000000 in the original uboot). Which means: Now the "better uboot" is written to flash and will be started by the routine we set up iin the original uboot.

The "better uboot" doesn't have to be set up. By default it tries to boot OpenWrt from flash. Now we just need to actually write an OpenWrt to flash. We do this by ...

tftpboot 0x62000000 pogoplug-v3-squashfs-ubinized.bin
bootm

... TFTPing OpenWrt to memory (at address 0x62000000) and running it. OpenWrt will start (you can actually watch it via serial). Then connect to OpenWrt as usual, SSH or http to 192.168.1.1 ... or simply use the serial connection that is still connected. Sysupgrade with the same OpenWrt image we are currently running. This will write OpenWrt to the correct address on flash.

After that, reboot (there is no point in configuring the OpenWrt we are currently running from memory.) And you're done, OpenWrt will start from flash.

(Note: You could do some things a bit different, issuing a few commands in a different order, or flash OpenWrt to flash from the "better" uboot itself, which is in fact what I did with my Pogoplugs. But this process works and is transparent enough.)

1 Like

Hey all,

Wow, thanks for getting back to me so fast.

braian87b, I feel like I've spent a lot of time skulking around the doozan forums, but unfortunately most of the information seems to be related to Marvell-Kirkwood-based PogoPlugs and getting Debian and Arch booting from USB sticks. Your gist seems to be for a PogoPlug that's been booted into Debian?

takimata, I followed your instructions with the following results.

In your first post you mentioned booting to a second, better uboot. The forum post mentions the file openwrt-oxnas-ox820-u-boot.bin, and on the Lede website in the oxnas section, this file can indeed be found under "Supplementary Files". I loaded it onto the Pogoplug via tftp, following the instructions in the forum, and I now reach the second uboot every time the PogoPlug boots up.

From there, if I try to load in the Lede initramfs:

OX820 # setenv ipaddr 192.168.1.1
OX820 # setenv 192.168.1.100
OX820 # tftpboot 0x62000000 lede-17.01.4-oxnas-pogoplug-v3-u-boot-initramfs.bin
Speed: 1000, full duplex
*** ERROR: `ethaddr' not set
Speed: 1000, full duplex

Which I think means it wasn't successful. A couple questions I have about this process:

  1. Where did this uBoot image that's in the "Supplementary Files" section come from? There's a "bootloader" section in the Lede menuconfig, but there's nothing to select. Did someone compile a uboot for this device separately?

  2. What's the difference between tftpboot and tftp? They seem to do the same thing, but tftp is used in the instructions for loading an image to the original bootloader, while tftpboot is used in the new bootloader.

  3. Why does bootm yield "Bad magic number", while "go 64000000" works? Does bootm expect a header while go starts running code directly from memory?

I'll post again regarding takimata's second post.

Checking the bottom of my PogoPlug, it says "Model: POGOPLUG PRO" and the color is black, so I'm thinking this is a Pro and not a V3.

With openwrt-oxnas-ox820-u-boot.bin, there's no need to interrupt. It will search for a kernel and fail to find one, leaving me in the bootloader. Following takimata's second set of instructions with *u-boot-initramfs.bin, the Pogoplug will now boot all the way to an OpenWRT shell prompt if I don't stop the second bootloader. I stopped it and entered

nand erase 0x440000 0x90000
nand write 64000000 0x440000 0x90000

Now, instead of booting all the way to an OpenWRT shell, it stops at the second bootloader; which makes sense. This bootloader appears similar to the one from "Supplementary files". I encountered the same problem with "ethaddr not set", which I remedied by setting an environment variable with the ethernet address from the first bootloader.

The following happens when I try to load *squashfs-ubinized.bin:

OX820 # tftpboot 0x62000000 lede-17.01.4-oxnas-pogoplug-pro-squashfs-ubinized.bin
Speed: 1000, full duplex
Using dwmac.40400000 device
TFTP from server 192.168.50.59; our IP address is 192.168.50.100
Filename 'lede-17.01.4-oxnas-pogoplug-pro-squashfs-ubinized.bin'.
Load address: 0x62000000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################
         5.5 MiB/s
done
Bytes transferred = 4063232 (3e0000 hex)
OX820 # bootm
Wrong Image Format for bootm command
ERROR: can't get kernel image!
OX820 # 

When I try changing the ip address in uboot, I get a slow procession of T's after "Loading" instead of the speedy #'s, so I left those variables in the uboot environment alone. Any idea what's going wrong here? I'm glad I can reach an OpenWRT shell through the initramfs image, but I'd like to finish the process.

I have not done this process in more than two years (once you successfully modify your device, subsequently you only need to sysupgrade). But I believe this is because the LEDE 17.01 image does not have initramfs.

Also, I never went the "boot OpenWrt from memory and sysupgrade" route, I wrote the image directly to flash from the second stage uboot. Unfortunately, I can't find my notes on how to do that anymore, and I don't have a device ready to reproduce it.

I would suggest to try to memory-boot this older OpenWrt 15.05 initramfs image. I believe it's not very important which OpenWrt you boot from memory, you can still sysupgrade to the latest LEDE.

I ended going back to the original boot loader, tftping the initramfs image into memory, booting into the shell, and then doing a sysupgrade from there. sysupgrade complained with Image metadata not found. when I ran it with pogoplug-pro-squashfs-sysupgrade.tar, but adding -F made it continue. From there I've been booting directly into LEDE.

I was actually able to boot pogoplug-pro-uImage from the second uboot, but I ended up in the root filesystem of the original pogoplug firmware.

I still have a number of questions about different aspects of this process, but maybe I should start a separate thread for them.

Thanks a lot for your help. I was thoroughly flummoxed for a while; even starting to look into compiling uboot.

To be perfectly honest, I don't quite get what you describe in your last reply, or whether your Pogoplug is now working with LEDE. I hope it is.

It might be good to go properly test and document this "uboot way" of installing OpenWrt, especially considering that current LEDE builds seem to not be able to memory-boot from uboot anymore. Yet another thing to go on my seemingly endless todo list, sigh.

It seems to be booting normally and I can log into it without the use of a serial cable. I can also reach the Luci page. Which parts are confusing? I took advantage of the fact that I was able to boot all the way into Lede using the in-memory initramfs image transferred over in the first uboot. From there, I used SCP to transfer a sysupgrade.tar image using the link-local IPv6 address.

I would be willing to test and document this "uboot way". I have another Pogoplug Pro I could try it on (though I replaced it's original bootloader in an earlier attempt to install LEDE; I can get only as far as the new uboot on that one).

Is there an agreed-upon way to go about properly testing and documenting? I could start by listing what I think were the relevant steps in this thread.

I guess the part where you write about "the root filesystem of the original pogoplug firmware" threw me off. I am happy you achieved your goal.

Not that I'm aware of. If it works for you, and its documentation can help others, Any written record, in any way, will be helpful and greatly appreciated. Especially since in this case, documentation is virtually nonexistant. And if I learn anything out of this conversation: It's better to write something down and not need it than the other way around.

I just wish I had documented flashing OpenWrt to the device from uboot. It's not horribly complicated, but I failed to properly write it down, even for myself. I have a PogoPlug that I'm not currently using*, already modified but still with the original uboot present, so I could reproduce and document the proper way. It's not particularly high on my todo list, but it's on there.

*) I actually did a long-term stability test on that PogoPlug, and then forgot about it. Its uptime is currently at 301 days. So, consider LEDE stable on that target. :wink:

Ah, that was before I did a sysupgrade. I was testing to see if I could get any of the images to boot from the second bootloader. The only one that would was *uImage. I'm assuming that was a kernel image, so it ended up loading the original Pogoplug root file system.

Below are what I believe to be the relevant steps for loading LEDE onto a Pogoplug Pro. I left out booting into the second uboot and then flashing it. I think sysupgrade flashes the second uboot as well as the kernel and rootfs. That should probably be confirmed.

  1. Acquire Pogoplug.
  2. Open the Pogoplug case and locate the serial port pins. This blog post shows where they are.
  3. Attach a USB-serial converter to the pins. Don't follow the instructions in the above post for constructing a connector between the 2mm pins in the Pogoplug and the 2.54mm pins of the USB-serial converter (unless you feel you must). Just search for "2.54mm to 2mm jumper" and order one.
  4. Boot the Pogoplug with the USB-serial converter attached. Watch the output from uboot. Halt it before it boots the OS.
  5. Connect the Pogoplug to a computer via ethernet and start a tftp server. Use printenv to find out what IP address the Pogoplug needs the tftpserver to be. The relevant variable is serverip. I've found it easier to change the IP address of the tftpserver than attempting to alter the serverip variable in uBoot.
  6. Create a uBoot environment variable "script" that loads the second bootloader from NAND into memory and boots it by entering:
    setenv boot_lede nand read 0x64000000 0x440000 0x90000 \; go 64000000
    0x64000000 is the location in memory to load the second uboot to, 0x440000 is its location in NAND, and 0x90000 is its size (the number of bytes to read from NAND).
    go 64000000 instructs the first bootloader to start running at address 0x64000000.
  7. Alter the bootcmd environment variable to invoke the above "script variable" on boot.
    setenv bootcmd run boot_lede
  8. Save the uboot environment.
    saveenv
  9. Load the initramfs image into memory over tftp.
    tftp 64000000 u-boot-initramfs.bin
  10. Boot into the initramfs.
    go 64000000
  11. Once booted into initramfs-LEDE, transfer squashfs-sysupgrade.tar to the Pogoplug.
  12. Run sysupgrade on the Pogoplug to write LEDE to flash.
    sysupgrade squashfs-sysupgrade.tar

The oxnas images for Lede seem to have a rather large (6) number of images for each target. I've written my conjectures about what each does. Let me know if I get any wrong?
u-boot-initramfs: Used for "live-booting" into a LEDE environment from uBoot. Includes the second-stage uboot, kernel, and a root filesystem.
uImage: The uboot-wrapped kernel. Can be booted from the second-stage uBoot using the bootm command. Included in the other images.
squashfs-ubinized.bin and ubifs-ubinized.bin: Images containing the kernel uImage, either a squashfs or ubifs root filesystem, and (possibly?) the second-stage bootloader. Using these, one can flash a device by halting at the second stage bootloader and using uboot to write to NAND directly.
squashfs-sysupgrade.tar and ubifs-sysupgrade.tar: Sysupgrade images. Can be used to flash the device using the method described above.
Choice of squashfs or ubifs: The squashfs images are used to create a device with a flash layout similar to the one described here. In this layout there are two filesystems: read-only squashfs, and (initially empty) read-write ubifs. The two are combined to form the root filesystem using overlayfs.
The ubifs images are used to create a single, read-write ubifs root filesystem.
Trade-offs: squashfs is smaller and potentially longer-lasting on a NAND device, as long as one doesn't plan on writing to it too often. ubifs allows one the option of making many small changes to the root filesystem directly at the cost of being a bit larger and potentially shorter-lasting on a NAND device.

1 Like

Yes, Upgrade Pogoplug Mobile (or Series 4) from OpenWrt to LEDE
Sorry, I did't see that you talked to me, you should add "@" previous the username in order to me receive the proper mention notification I think

if you follow the steps of qnology you first will have boot into debian on SD card. then using Debian you could configure pogo run OpenWrt from internal 128Mb flash, if you broke something on OpenWrt you could put again the Debian SD card again and reflash OpenWrt again, (I think that the uboot will try to boot from USB, then SD then internal Flash) ...
Worked perfectly on my pogoplug's mobile's, I did't try it to flash LEDE, but there is a PR on the new OpenWrt so the next release of OpenWrt (previously called LEDE) will have (again) Support for the PogoPlug Mobile/V4.

There is lack of proper instructions for people to follow, easily and securely, when we see a blog post from many months or even years and it uses really previous releases and even it have broken links (happen on qnology) or even many forum threads with a lot of chatting around with so many trial and error and go back and bouncing it is just too dificult to follow or even risky (There have been some bricks and I personally had that problem with old OpenWrt forum and Doozan Forums too on the past), I read hours even days, and finally just leave it there as is, and I have to read a lot of hours, several days too to install Debian on a Iomega Ez too. That is because when I managed to follow by myself I written that gist with steps and my notes about to help others to follow more easily (I did do for the PogoPlug Mobile/V4 and the Iomega Ez too.

I encourage others users that made success on these or other devices with newer firmware to write down their notes about too, in that way all of us will be benefited.