Pogoplug V4: Bad eraseblock 2 at 0x000000040000

Re: Pogoplug V4: Bad eraseblock 2 at 0x000000040000

rsantag — Wed, 04 Feb 2026 13:05:07 -0600

OK, thanks Bodhi.

Re: Pogoplug V4: Bad eraseblock 2 at 0x000000040000

bodhi — Wed, 04 Feb 2026 09:22:33 -0600

> Is there a way to change where uboot looks for
> environment from 0xc0000 to 0xe0000? If I could
> tweak that then I think I could get both preboot
> and OpenWRT working.

No, there is no way to change the envs address from the user interface. u-boot does have a redundant envs capability (fallback), but I did not configure it in the 2017.07 version.

> probably wouldn't
> help with being able to boot OpenWRT that is
> installed to Pogoplug's internal storage.

For now, you could boot OpenWrt with a uEnv.txt in USB, HDD, or SD card.

Re: Pogoplug V4: Bad eraseblock 2 at 0x000000040000

rsantag — Tue, 03 Feb 2026 14:04:26 -0600

Hmm, uEnv.txt didn't seem to work for preboot. Guessing by the time it's picking up uEnv.txt, it's already past the point of invoking any preboot routines? Likewise, probably wouldn't help with being able to boot OpenWRT that is installed to Pogoplug's internal storage.

Is there a way to change where uboot looks for environment from 0xc0000 to 0xe0000? If I could tweak that then I think I could get both preboot and OpenWRT working.

Re: Pogoplug V4: Bad eraseblock 2 at 0x000000040000

rsantag — Tue, 03 Feb 2026 13:05:08 -0600

bodhi Wrote:
>
> Did you try kwboot before flashing?
>

No, i was going to try flashing uboot regardless since it's not much good to me running the stock OS.

>
> On this box with bad block 6, you can still boot
> Debian rootfs on USB or HDD or SD with uEnv.txt
> capability.
>

Oh, cool - hadn't even thought to try booting Debian, but yeah, it came right up.

>
> Booting with uEnv.txt (to fix messed up U-Boot
> envs or corrupted NAND envs area)
> https://forum.doozan.com/read.php?3,116134,116139#msg-116139

I tried reflashing environment to block 6, and it did skip it and write it to block 7. Didn't know if it needed to be flash_erased beforehand, since only block 6 had been (attempted) to be erased, so did flash_erase on block 7 and then flashed environment to block 6/7 again

root@pihole:/tmp# flash_erase /dev/mtd0 0xc0000 1
flash_erase: Skipping bad block at 000c0000
Erasing 128 Kibyte @ c0000 -- 100 % complete
root@pihole:/tmp# nandwrite -s 786432 /dev/mtd0 uboot.2016.05-tld-1.environment.img
Writing data to block 6 at offset 0xc0000
Bad block at c0000, 1 block(s) will be skipped
Writing data to block 7 at offset 0xe0000
Written 62 blocks containing only 0xff bytes
Those block may be incorrectly treated as empty!
root@pihole:/tmp# flash_erase /dev/mtd0 0xe0000 1                               
Erasing 128 Kibyte @ e0000 -- 100 % complete
root@pihole:/tmp# nandwrite -s 786432 /dev/mtd0 uboot.2016.05-tld-1.environment.img
Writing data to block 6 at offset 0xc0000
Bad block at c0000, 1 block(s) will be skipped
Writing data to block 7 at offset 0xe0000
Written 62 blocks containing only 0xff bytes
Those block may be incorrectly treated as empty!

Then changed 0xc0000 in /etc/fw_env.config to 0xe0000, and now fw_printenv and fw_setenv work correctly under Debian. But guessing uboot doesn't look at block 7 if block 6 is bad, as it didn't pick up my preboot setting, so I guess a hollow victory...

But hadn't thought about using uEnv.txt to set those variables. I'll give that a try

Re: Pogoplug V4: Bad eraseblock 2 at 0x000000040000

bodhi — Mon, 02 Feb 2026 23:17:36 -0600

> Tried "kwboot -t -B 115200 /dev/ttyUSB0 -b
> uboot.2017.07-tld-1.pogo_v4.mtd0.kwb" a few times,
> starting kwboot before powering up pogoplug, and
> powering up pogoplug before kwboot, but nothing
> there either.

Did you try kwboot before flashing?

> I have one with bad block 6 that failed awhile back,
> but with different symptoms.
>
> uboot loads, but it can't readenv:
>
> U-Boot 2017.07-tld-1 (Sep 05 2017 - 00:34:01
> -0700)
> Pogoplug V4
> *** Warning - readenv() failed, using default
> environment

> I'm assuming this is because of the bad block
> right where ENV is supposed to be.

Yes.

> Is there a way to fix this, either while in uboot
> environment looks good while I'm in uboot

With 2017.07-tld-1, the internal envs are populated automatically when the envs are corrupted (or the envs block is bad).

> But not when I'm in Openwrt
>
> root@OpenWrt:/# fw_printenv
> Warning: Bad CRC, using default environment

OpenWrt does not have the correct definition for the envs.

====

On this box with bad block 6, you can still boot Debian rootfs on USB or HDD or SD with uEnv.txt capability.

See the Wiki thread:

Booting with uEnv.txt (to fix messed up U-Boot envs or corrupted NAND envs area)
https://forum.doozan.com/read.php?3,116134,116139#msg-116139

Re: Pogoplug V4: Bad eraseblock 2 at 0x000000040000

rsantag — Mon, 02 Feb 2026 15:17:57 -0600

Well, I got an I/O error on the "flash_erase /dev/mtd0 0 4", I'm assuming because of the bad block.
Ran "nandwrite /dev/mtd0 /tmp/uboot.2017.07-tld-1.pogo_v4.mtd0.kwb" and it did write, skipping over block 2, so writing to block 0-4.
Ran "nandwrite -s 786432 /dev/mtd0 /tmp/uboot.2016.05-tld-1.environment.img", which gave no errors.

But when I tried rebooting, got no light on front, nothing on the console (using "screen" with serial cable).
Tried "kwboot -t -B 115200 /dev/ttyUSB0 -b uboot.2017.07-tld-1.pogo_v4.mtd0.kwb" a few times, starting kwboot before powering up pogoplug, and powering up pogoplug before kwboot, but nothing there either.

Guessing no other options except JTAG at this point (which would be more trouble than it's worth - I have more Pogoplugs, so not a huge loss).

Haven't tried the one with bad block 3, although I have one with bad block 6 that failed awhile back, but with different symptoms.

uboot loads, but it can't readenv:

U-Boot 2017.07-tld-1 (Sep 05 2017 - 00:34:01 -0700)
Pogoplug V4

SoC:   Kirkwood 88F6192_A1
DRAM:  128 MiB
WARNING: Caches not enabled
NAND:  128 MiB
MMC:   MVEBU_MMC: 0
*** Warning - readenv() failed, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   egiga0
Hit any key to stop autoboot:  0

I'm assuming this is because of the bad block right where ENV is supposed to be.
Is there a way to fix this, either while in uboot or from OpenWRT, which I am able to tftpboot

Pogov4> setenv ipaddr 192.168.1.145
Pogov4> setenv serverip 192.168.1.162
Pogov4> tftpboot 0x800000 openwrt.img
Using egiga0 device
TFTP from server 192.168.1.162; our IP address is 192.168.1.145
Filename 'openwrt.img'.
Load address: 0x800000
Loading: #################################################################
         #################################################################
         #################################################################
         ###################################################
         3.6 MiB/s
done
Bytes transferred = 3608527 (370fcf hex)
Pogov4> bootm 0x800000

......boot messages ..

BusyBox v1.30.1 () built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 19.07.4, r11208-ce6496d796
 -----------------------------------------------------
=== WARNING! =====================================
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
--------------------------------------------------
root@OpenWrt:/#

environment looks good while I'm in uboot

Pogov4>
arcNumber=3960
baudrate=115200
bootcmd=run bootcmd_uenv; run scan_disk; run set_bootargs; run bootcmd_exec; reset
bootcmd_exec=run load_uimage; if run load_initrd; then if run load_dtb; then bootm $load_uimage_addr $load_initrd_addr $load_dtb_addr; else bootm $load_uimage_addr $load_initrd_addr; fi; else if run load_dtb; then bootm $load_uimage_addr - $load_dtb_addr; else bootm$load_uimage_addr; fi; fi
bootcmd_uenv=run uenv_load; if test $uenv_loaded -eq 1; then run uenv_import; fi
bootdelay=10
bootdev=usb
console=ttyS0,115200
device=0:1
devices=usb ide mmc
disks=0 1 2 3
dtb_file=/boot/dts/kirkwood-pogoplug_v4
ethact=egiga0
ethaddr=52:3b:20:9c:11:51
if_netconsole=ping $serverip
ipaddr=192.168.1.40
led_error=orange blinking
led_exit=green off
led_init=green blinking
load_dtb=echo loading DTB $dtb_file ...; load $bootdev $device $load_dtb_addr $dtb_file
load_dtb_addr=0x1c00000
load_initrd=echo loading uInitrd ...; load $bootdev $device $load_initrd_addr /boot/uInitrd
load_initrd_addr=0x1100000
load_uimage=echo loading uImage ...; load $bootdev $device $load_uimage_addr /boot/uImage
load_uimage_addr=0x800000
mainlineLinux=yes
mtdids=nand0=orion_nand
mtdparts=mtdparts=orion_nand:2M(u-boot),3M(uImage),3M(uImage2),8M(failsafe),112M(root)
partition=nand0,2
preboot_nc=run if_netconsole start_netconsole
scan_disk=echo running scan_disk ...; scan_done=0; setenv scan_usb "usb start";  setenv scan_ide "ide reset";  setenv scan_mmc "mmc rescan"; for dev in $devices; do if test $scan_done -eq 0; then echo Scan device $dev; run scan_$dev; for disknum in $disks; do if test $scan_done -eq 0; then echo device $dev $disknum:1; if load $dev $disknum:1 $load_uimage_addr /boot/uImage 1; then scan_done=1; echo Found bootable drive on $dev $disknum; setenv device $disknum:1; setenv bootdev $dev; fi; fi; done; fi; done
serverip=192.168.1.162
set_bootargs=setenv bootargs console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $mtdparts $custom_params
start_netconsole=setenv ncip $serverip; setenv bootdelay 10; setenv stdin nc; setenv stdout nc; setenv stderr nc; version;
stderr=serial
stdin=serial
stdout=serial
uenv_addr=0x810000
uenv_import=echo importing envs ...; env import -t $uenv_addr $filesize
uenv_init_devices=setenv init_usb "usb start";  setenv init_ide "ide reset";  setenv init_mmc "mmc rescan"; for devtype in $devices; do run init_$devtype; done;
uenv_load=run uenv_init_devices; setenv uenv_loaded 0; for devtype in $devices;  do for disknum in 0; do run uenv_read_disk; done; done;
uenv_read=echo loading envs from $devtype $disknum ...; if load $devtype $disknum:1 $uenv_addr /boot/uEnv.txt; then setenv uenv_loaded 1; fi
uenv_read_disk=if test $devtype -eq mmc; then if $devtype part; then run uenv_read;  fi; else if $devtype part $disknum; then run uenv_read; fi;  fi
usb_ready_retry=15

Environment size: 2906/131068 bytes

But not when I'm in Openwrt

root@OpenWrt:/# fw_printenv
Warning: Bad CRC, using default environment
bootcmd=bootp; setenv bootargs root=/dev/nfs nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
bootdelay=5
baudrate=115200
root@OpenWrt:/#

/proc/mtd looks like this:

root@OpenWrt:/# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 001c0000 00020000 "uboot"
mtd1: 00040000 00020000 "uboot_env"
mtd2: 07e00000 00020000 "ubi"
root@OpenWrt:/#

Guessing all this is related to the messed up ENV?

Re: Pogoplug V4: Bad eraseblock 2 at 0x000000040000

bodhi — Sun, 01 Feb 2026 23:08:08 -0600

rsantag,

The "work around" is not something that works in all scenarios. I wrote that to mean in each case, the bad blocks and their location must be considered before the flashing is attempted.

> I'm assuming I need
> to somehow configure it with the new locations for
> uboot and environment. Am I on the right track?

No need to reconfigure anything!

===

NAND block is 128K in size. My intention was to keep 2 blocks free after u-boot image and before envs image. This enables the bad-block work around.

This u-boot image is 512K, and the envs image is 128K. u-boot image location is at 0x0. The envs location is at 768k (0xC0000).

So in term of eraseblocks, u-boot image is at 1st block (block 0) and occupies 4 blocks (block 0 to block 3). The envs is at 6th block, and occupies 1 block.

========

For your situation: Pogoplug Mobile with a bad eraseblock 2.

Before flashing, you should run kwboot and confirm that it the Pogo V4 u-boot can be kwbbooted with the latest u-boot image (2017.07 or later). This allows a recovery path if something goes wrong in flashing.

You can go ahead and flash u-boot image. nandwrite will report an error at block 2 and that block will be skipped by nandwrite. So there will be a "hole" in the NAND blocks for u-boot image (which now occupies block 0-4). This fragment will be automatically taken care by the BootROM and u-boot will run OK.

Same for your second Pogo Mobile which has bad block 3.

The envs image can be flashed as normal.

Re: Pogoplug V4: Bad eraseblock 2 at 0x000000040000

rsantag — Sun, 01 Feb 2026 20:51:40 -0600

I see that my uboot image is 524,288 bytes - 4 blocks, and the environment image is 131,072 - 1 block. Is the work around to move them somewhere that avoids the bad blocks, i.e. on the pogoplug with a bad block 2, I would write environment at, say, block 1 - 131,072, and write uboot starting at block 3 - 393,216? If so, I'm assuming I need to somehow configure it with the new locations for uboot and environment. Am I on the right track?

Pogoplug V4: Bad eraseblock 2 at 0x000000040000

rsantag — Sun, 01 Feb 2026 13:02:36 -0600

I have a Pogoplug Mobile with a bad eraseblock 2, and another with a bad eraseblock 3. I was reading U-Boot: dmesg | grep -i 'bad' --> Bad eraseblock 72 at 0x000000900000 which says there is a work around to bad eraseblocks 0 thru 7. Can someone tell me what the workaround is?

Thanks!