Welcome! Log In Create A New Profile

Advanced

Pogoplug Pink fails in Validating Existing Uboot

Posted by bodhi 
Pogoplug Pink fails in Validating Existing Uboot
September 01, 2011 07:35PM
Guys,

I'm installing Debian on a new Pogoplug Pink (it's an E02 version). I've opened the box to double check, making sure that it's actually an E02 (no SATA). I got the often reported error "Unknown uBoot detected on mtd0" when Jeff's script is validating the UBoot version and detected an unknown UBoot. Any idea how to proceed? perhaps I got a bad block on mtd0? It''s a brand new Popgoplug ordered recently when it was on sale for $33 from Adorama.

Appreciate any guidance :-) Here is the info.

-bash-3.2# uname -a
Linux Pogoplug 2.6.22.18 #44 Mon Aug 10 12:57:36 PDT 2009 armv5tejl unknown

-bash-3.2# wget -P /tmp http://jeff.doozan.com/debian/uboot/install_uboot_mtd0.sh
Connecting to jeff.doozan.com (69.163.187.226:80)
install_uboot_mtd0.s 100% |*************************************************************| 17281  --:--:-- ETA
-bash-3.2# chmod +x /tmp/install_uboot_mtd0.sh
-bash-3.2# /tmp/install_uboot_mtd0.sh --noprompt
# checking for /usr/sbin/nandwrite...

# Installing /usr/sbin/nandwrite...
Connecting to jeff.doozan.com (69.163.187.226:80)
nandwrite.md5        100% |*************************************************************|    44  --:--:-- ETA
Connecting to jeff.doozan.com (69.163.187.226:80)
nandwrite            100% |*************************************************************| 11500  --:--:-- ETA
# Successfully installed /usr/sbin/nandwrite.
# checking for /usr/sbin/nanddump...

# Installing /usr/sbin/nanddump...
Connecting to jeff.doozan.com (69.163.187.226:80)
nanddump.md5         100% |*************************************************************|    43  --:--:-- ETA
Connecting to jeff.doozan.com (69.163.187.226:80)
nanddump             100% |*************************************************************| 21286  --:--:-- ETA
# Successfully installed /usr/sbin/nanddump.
# checking for /usr/sbin/flash_erase...

# Installing /usr/sbin/flash_erase...
Connecting to jeff.doozan.com (69.163.187.226:80)
flash_erase.md5      100% |*************************************************************|    46  --:--:-- ETA
Connecting to jeff.doozan.com (69.163.187.226:80)
flash_erase          100% |*************************************************************| 12819  --:--:-- ETA
# Successfully installed /usr/sbin/flash_erase.
# checking for /usr/sbin/fw_printenv...

# Installing /usr/sbin/fw_printenv...
Connecting to jeff.doozan.com (69.163.187.226:80)
fw_printenv.md5      100% |*************************************************************|    46  --:--:-- ETA
Connecting to jeff.doozan.com (69.163.187.226:80)
fw_printenv          100% |*************************************************************|   652k 00:00:00 ETA
# Successfully installed /usr/sbin/fw_printenv.
# checking for /etc/fw_env.config...

# Installing /etc/fw_env.config...
Connecting to jeff.doozan.com (69.163.187.226:80)
fw_env.config.md5    100% |*************************************************************|    48  --:--:-- ETA
Connecting to jeff.doozan.com (69.163.187.226:80)
fw_env.config        100% |*************************************************************|   329  --:--:-- ETA
# Successfully installed /etc/fw_env.config.

# Validating existing uBoot...
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00080000...
Connecting to jeff.doozan.com (69.163.187.226:80)
valid-uboot.md5      100% |*************************************************************|   756  --:--:-- ETA
## Unknown uBoot detected on mtd0: 150f323cc589d1535d6e06c2038d0aa7
##
## The installer could not detect the version of your current uBoot
## This may happen if you have installed a different uBoot on
## /dev/mtd0 or if you have bad blocks on /dev/mtd0
##
## If you have bad blocks on mtd0, you should not try to install uBoot.
##
## If you have installed a diffirent uBoot on mtd0, and understand the
## risks, you can re-run the installer with the --no-uboot-check parameter
##
## Installation cancelled.



Edited 1 time(s). Last edit at 09/01/2011 10:31PM by bodhi.
Re: Pogoplug Pink fails in Validating Existing Uboot
September 01, 2011 10:30PM
I've rebooted back into Pogoplug and ran dmesg. Is it the classic problem with bad block on mtd0 ? what can I do to proceed?
Thanks

-bash-3.2# dmesg
[    0.000000] Linux version 2.6.22.18 (bdietrich@brad-ux) (gcc version 4.2.1) #                                                                                                 44 Mon Aug 10 12:57:36 PDT 2009
[    0.000000] CPU: ARM926EJ-S [56251311] revision 1 (ARMv5TE), cr=00053177
[    0.000000] Machine: Feroceon-KW
[    0.000000] Using UBoot passing parameters structure
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] On node 0 totalpages: 65536
[    0.000000]   DMA zone: 512 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 65024 pages, LIFO batch:15
[    0.000000]   Normal zone: 0 pages used for memmap
[    0.000000] CPU0: D VIVT write-back cache
[    0.000000] CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 s                                                                                                 ets
[    0.000000] CPU0: D cache: 16384 bytes, associativity 4, 32 byte lines, 128 s                                                                                                 ets
[    0.000000] Built 1 zonelists.  Total pages: 65024
[    0.000000] Kernel command line: console=ttyS0,115200 root=/dev/mtdblock2 ro
[    0.000000] PID hash table entries: 1024 (order: 10, 4096 bytes)
[    0.000000] Console: colour dummy device 80x30
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.010000] Memory: 256MB 0MB 0MB 0MB = 256MB total
[    0.010000] Memory: 255872KB available (3592K code, 252K data, 120K init)
[    0.010000] Calibrating delay loop... 1192.75 BogoMIPS (lpj=5963776)
[    0.250000] Mount-cache hash table entries: 512
[    0.250000] CPU: Testing write buffer coherency: ok
[    0.250000] NET: Registered protocol family 16
[    0.250000]
[    0.250000] CPU Interface
[    0.250000] -------------
[    0.250000] SDRAM_CS0 ....base 00000000, size 256MB
[    0.250000] SDRAM_CS1 ....disable
[    0.250000] SDRAM_CS2 ....disable
[    0.250000] SDRAM_CS3 ....disable
[    0.250000] PEX0_MEM ....base e8000000, size 128MB
[    0.250000] PEX0_IO ....base f2000000, size   1MB
[    0.250000] INTER_REGS ....base f1000000, size   1MB
[    0.250000] NFLASH_CS ....base fa000000, size   2MB
[    0.250000] SPI_CS ....base f4000000, size  16MB
[    0.250000] BOOT_ROM_CS ....no such
[    0.250000] DEV_BOOTCS ....no such
[    0.250000] CRYPT_ENG ....base f0000000, size   2MB
[    0.250000]
[    0.250000]   Marvell Development Board (LSP Version KW_LSP_4.2.7_patch21)--                                                                                                  SHEEVA PLUG  Soc: 88F6281 A0 LE
[    0.250000]
[    0.250000]  Detected Tclk 200000000 and SysClk 400000000
[    0.250000] MV Buttons Device Load
[    0.250000] Marvell USB EHCI Host controller #0: c0650600
[    0.750000] PEX0 interface detected no Link.
[    0.750000] PCI: bus0: Fast back to back transfers enabled
[    0.750000] SCSI subsystem initialized
[    0.750000] usbcore: registered new interface driver usbfs
[    0.750000] usbcore: registered new interface driver hub
[    0.750000] usbcore: registered new device driver usb
[    0.750000] NET: Registered protocol family 2
[    0.760000] Time: kw_clocksource clocksource has been installed.
[    0.850000] IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.850000] TCP established hash table entries: 8192 (order: 4, 65536 bytes)
[    0.850000] TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
[    0.850000] TCP: Hash tables configured (established 8192 bind 8192)
[    0.850000] TCP reno registered
[    0.880000] RTC has been updated!!!
[    0.880000] RTC registered
[    0.880000] Use the XOR engines (acceleration) for enhancing the following fu                                                                                                 nctions:
[    0.880000]   o RAID 5 Xor calculation
[    0.880000]   o kernel memcpy
[    0.880000]   o kenrel memzero
[    0.880000] Number of XOR engines to use: 4
[    0.880000] cesadev_init(c00116b4)
[    0.880000] mvCesaInit: sessions=640, queue=64, pSram=f0000000
[    0.880000] MV Buttons Driver Load
[    0.880000] squashfs: version 3.3 (2007/10/31) Phillip Lougher
[    0.880000] squashfs: LZMA suppport for slax.org by jro
[    0.880000] JFFS2 version 2.2. (NAND) é 2001-2006 Red Hat, Inc.
[    0.880000] io scheduler noop registered
[    0.880000] io scheduler anticipatory registered (default)
[    0.900000] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing                                                                                                  disabled
[    0.900000] serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
[    0.910000] serial8250.0: ttyS1 at MMIO 0xf1012100 (irq = 34) is a 16550A
[    0.920000] RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 bloc                                                                                                 ksize
[    0.930000] Loading Marvell Ethernet Driver:
[    0.940000]   o Cached descriptors in DRAM
[    0.940000]   o DRAM SW cache-coherency
[    0.940000]   o Single RX Queue support - ETH_DEF_RXQ=0
[    0.950000]   o Single TX Queue support - ETH_DEF_TXQ=0
[    0.950000]   o TCP segmentation offload enabled
[    0.960000]   o Receive checksum offload enabled
[    0.960000]   o Transmit checksum offload enabled
[    0.970000]   o Network Fast Processing (Routing) supported
[    0.970000]   o Driver ERROR statistics enabled
[    0.980000]   o Driver INFO statistics enabled
[    0.980000]   o Proc tool API enabled
[    0.990000]   o Rx descripors: q0=128
[    0.990000]   o Tx descripors: q0=532
[    0.990000]   o Loading network interface(s):
[    1.000000]     o eth0, ifindex = 1, GbE port = 0
[    1.010000]     o eth1, ifindex = 2, GbE port = 1
[    1.010000]
[    1.010000] mvFpRuleDb (cf8c2000): 2048 entries, 8192 bytes
[    1.020000] Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI
[    1.030000] Copyright (c) 1999-2006 Intel Corporation.
[    1.030000] e100: Intel(R) PRO/100 Network Driver, 3.5.17-k4-NAPI
[    1.040000] e100: Copyright(c) 1999-2006 Intel Corporation
[    1.040000]
[    1.040000] Warning Sata is Powered Off
[    1.050000] NFTL driver: nftlcore.c $Revision: 1.98 $, nftlmount.c $Revision:                                                                                                  1.41 $
[    1.060000] NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 1                                                                                                 28MiB 3,3V 8-bit)
[    1.070000] Scanning device for bad blocks
[    1.070000] Bad eraseblock 3 at 0x00060000
[    1.080000] Bad eraseblock 154 at 0x01340000
[    1.090000] Bad eraseblock 205 at 0x019a0000
[    1.100000] Bad eraseblock 279 at 0x022e0000
[    1.100000] Bad eraseblock 312 at 0x02700000
[    1.110000] Bad eraseblock 484 at 0x03c80000
[    1.130000] Bad eraseblock 634 at 0x04f40000
[    1.140000] Bad eraseblock 911 at 0x071e0000
[    1.150000] Bad eraseblock 952 at 0x07700000
[    1.160000] Bad eraseblock 990 at 0x07bc0000
[    1.160000] Bad eraseblock 994 at 0x07c40000
[    1.160000] Bad eraseblock 995 at 0x07c60000
[    1.170000] Using static partition definition
[    1.170000] Creating 4 MTD partitions on "nand_mtd":
[    1.180000] 0x00000000-0x00100000 : "u-boot"
[    1.180000] 0x00100000-0x00500000 : "uImage"
[    1.190000] 0x00500000-0x02500000 : "root"
[    1.190000] 0x02500000-0x08000000 : "data"
[    1.200000] ehci_marvell ehci_marvell.70059: Marvell Orion EHCI
[    1.200000] ehci_marvell ehci_marvell.70059: new USB bus registered, assigned                                                                                                  bus number 1
[    1.240000] ehci_marvell ehci_marvell.70059: irq 19, io base 0xf1050100
[    1.260000] ehci_marvell ehci_marvell.70059: USB 2.0 started, EHCI 1.00, driv                                                                                                 er 10 Dec 2004
[    1.260000] usb usb1: configuration #1 chosen from 1 choice
[    1.270000] hub 1-0:1.0: USB hub found
[    1.270000] hub 1-0:1.0: 1 port detected
[    1.390000] ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Dr                                                                                                 iver
[    1.390000] USB Universal Host Controller Interface driver v3.0
[    1.670000] usb 1-1: new high speed USB device using ehci_marvell and address                                                                                                  2
[    1.820000] usb 1-1: configuration #1 chosen from 1 choice
[    1.820000] hub 1-1:1.0: USB hub found
[    1.830000] hub 1-1:1.0: 4 ports detected
[    1.940000] usbcore: registered new interface driver usblp
[    1.940000] drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
[    1.950000] Initializing USB Mass Storage driver...
[    1.950000] usbcore: registered new interface driver usb-storage
[    1.960000] USB Mass Storage support registered.
[    1.970000] mice: PS/2 mouse device common for all mice
[    1.970000] i2c /dev entries driver
[    1.970000] Linux telephony interface: v1.00
[    1.980000] md: linear personality registered for level -1
[    1.980000] md: raid0 personality registered for level 0
[    1.990000] md: raid1 personality registered for level 1
[    2.160000] raid6: int32x1     97 MB/s
[    2.330000] raid6: int32x2    114 MB/s
[    2.500000] raid6: int32x4    122 MB/s
[    2.670000] raid6: int32x8    110 MB/s
[    2.670000] raid6: using algorithm int32x4 (122 MB/s)
[    2.670000] md: raid6 personality registered for level 6
[    2.680000] md: raid5 personality registered for level 5
[    2.680000] md: raid4 personality registered for level 4
[    2.690000] raid5: measuring checksumming speed
[    2.740000]    arm4regs  :  1084.000 MB/sec
[    2.790000]    8regs     :   754.800 MB/sec
[    2.840000]    32regs    :   899.600 MB/sec
[    2.840000] raid5: using function: arm4regs (1084.000 MB/sec)
[    2.850000] device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-d                                                                                                 evel@redhat.com
[    2.850000] dm_crypt using the OCF package.
[    2.860000] sdhci: Secure Digital Host Controller Interface driver
[    2.860000] sdhci: Copyright(c) Pierre Ossman
[    2.870000] usbcore: registered new interface driver usbhid
[    2.870000] drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
[    2.880000] TCP cubic registered
[    2.880000] NET: Registered protocol family 1
[    2.890000] NET: Registered protocol family 17
[    2.890000] md: Autodetecting RAID arrays.
[    2.900000] md: autorun ...
[    2.900000] md: ... autorun DONE.
[    6.120000] Empty flash at 0x009ac208 ends at 0x009ac800
[    6.580000] VFS: Mounted root (jffs2 filesystem) readonly.
[    6.580000] Freeing init memory: 120K
[    8.710000] eth0: link down
[    8.710000] eth0: started
[   11.730000] eth0: link up, full duplex, speed 1 Gbps
-bash-3.2#
Re: Pogoplug Pink fails in Validating Existing Uboot
September 01, 2011 10:54PM
@restamp,

I found some of your posts about how you dealt with this problem at
http://forum.doozan.com/read.php?3,2417,2417#msg-2417

It seems the problem is exactly as yours before. Could you advise: should I rerun the installer using the prameter --no-uboot-check ?

Below are the outputs of various commands that I've tried to verify if this is the same problem in your post.

Thanks in advance!

-bash-3.2# cd /proc
-bash-3.2# cat version
Linux version 2.6.22.18 (bdietrich@brad-ux) (gcc version 4.2.1) #44 Mon Aug 10 1                   2:57:36 PDT 2009
-bash-3.2# cat mtd
dev:    size   erasesize  name
mtd0: 00100000 00020000 "u-boot"
mtd1: 00400000 00020000 "uImage"
mtd2: 02000000 00020000 "root"
mtd3: 05b00000 00020000 "data"
-bash-3.2# cat partitions
major minor  #blocks  name

  31     0       1024 mtdblock0
  31     1       4096 mtdblock1
  31     2      32768 mtdblock2
  31     3      93184 mtdblock3
-bash-3.2# /usr/sbin/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
-bash-3.2#
Re: Pogoplug Pink fails in Validating Existing Uboot
September 02, 2011 02:41AM
Hi bodhi. It's late, and I don't have a lot of time to spend online tonight. (It's 3 AM here.)

On my "bad" Dockstar, the problem turned out to be an incorrectly flashed original uBoot. Jeff's installer does a hash of the existing uBoot and if one bit is different, it produces an entirely different hash sum. That was the case here. Jeff had me send him a copy of my uBoot partition, as extracted from my Dockstar, and sure enough, there was one bit different from the norm. It must have been in a noncritical part of the program, because the uBoot worked correctly. A latent bad segment on the NAND? Just a poor job of flashing at the factory? Who knows, but with that information I decided to go ahead and force Jeff's uBoot to install, and it worked for me. The new uBoot reads back entirely correctly.

On your system, it looks to me as if you have a bad block in your NAND in the area where the uBoot resides. (The uBoot partition is allocated the first 8 blocks of NAND and the bad block is erase block 3 at 0x60000). I'm not sure how to proceed in such a situation. Ideally, I think the way it is supposed to work is that if a bad block is encountered, it is skipped and the uBoot code continues at the next erase block boundary. But, I am not certain of this. In any event, it boils down to how much faith you have in the uBoot installer to install the new uBoot correctly upon encountering a bad erase block.

You can try the override and force in the new uBoot. If you do this, please let us know the outcome. Unfortunately, it appears the uBoot code takes up the first 4 erase blocks, so the last block of the uBoot code will fall on the bad block and will have to be relocated. There is room to do this -- I don't think blocks 4-5 are used. (Block 6, at 0xc0000, is used to store the environment, and I'm not sure about block 7.) But, I'm not that sure of how the uBoot itself is loaded and invoked. Another alternative would be to relocate the new uBoot to an area of NAND not being used and chain boot from the original uBoot into the new one and then into the appropriate OS.

Hopefully, someone else will jump in with a definitive answer and maybe we can both learn something. Does anyone else have any suggestions? Bodhi, good luck with it!



Edited 2 time(s). Last edit at 09/02/2011 02:53AM by restamp.
Re: Pogoplug Pink fails in Validating Existing Uboot
September 02, 2011 03:16PM
Thanks, restamp! It's good advises. Hopefully, others will chime in with more.

Suppose if I go ahead and force the override with the new UBoot, and then find out that the box is bricked. Can I recover in that case? or will it be bricked for good? Will the Nokia CA42 cable let me go back in and restore the Pogoplug FW?
Re: Pogoplug Pink fails in Validating Existing Uboot
September 02, 2011 05:01PM
If the uBoot winds up becoming corrupted during the install and you then reboot out of the running OS, I think your Pogoplug is toast. The only way to recover from that would be to open it up, connect a JTAG board, and reprogram it that way. (FWIW, I understand the JTAG unit for the Guruplug will work for this.) OTOH, I suspect your Pogoplug is not very useful to you in its current state, so it's probably worth taking the risk and trying something. If you opt for the chain-boot solution, then, yes, I think the CA42 would probably allow you to recover from an error, although I have not played at all with the original uBoot, so I cannot state that definitively.

If you do decide to just blast the new uBoot into your Pogoplug, after running the script but before rebooting I would at least try to verify that the 5th block (erase block 4) contains the last part of the uBoot code, which would normally be written to the 4th block (your bad erase block 3). I'm told that the nandwrite program should do this automatically upon encountering a bad block, but I have no direct experience with it. I would therefore carefully read back each block manually and verify that each was as I thought they should be before rebooting the Pogoplug. If any are not, then I would explicitly separate the uboot image into 131072 byte chunks and invoke nandwrite so as to make sure each block is correctly populated.

One more thing: Don't be surprised if, even if the nandwrite does exactly what it is supposed to do, that the installer still complains. You may have to manually verify that the NAND was correctly written after the fact.

Unfortunately, it's bad luck that you got a unit with a bad erase block in the first 8 blocks of the NAND. However, you could help others with similar Pogoplugs by reporting (1) whether the forced install script and nandwrite really do the right things upon encountering the bad block, (2) if not, what you had to do to make sure the new uBoot was actually written correctly to the NAND, and finally (3) if what we think will work -- i.e., just skipping the bad blocks and writing the code into the succeeding good blocks -- really works.

Good luck, and keep us informed.
Re: Pogoplug Pink fails in Validating Existing Uboot
September 02, 2011 11:11PM
Thanks restamp! I will proceed with the override and report back. I'll keep my fingers crossed :-)
Re: Pogoplug Pink fails in Validating Existing Uboot
September 04, 2011 04:28PM
restamp,

Looks like I was not successful in the attempt to do a force uboot installation. I'm getting closer to brick my pink pogoplug :-) I'm leaving box on for rescue if needed. The results so far:

The force install was not successful:
/tmp/install_uboot_mtd0.sh --noprompt --no-uboot-check parameter

-bash-3.2# wget -P /tmp http://jeff.doozan.com/debian/uboot/install_uboot_mtd0.sh
Connecting to jeff.doozan.com (69.163.187.226:80)
install_uboot_mtd0.s 100% |**************************************************| 17281  --:--:-- ETA
-bash-3.2# cd /tmp
-bash-3.2# chmod +x /tmp/install_uboot_mtd0.sh
-bash-3.2# /tmp/install_uboot_mtd0.sh --noprompt
# checking for /usr/sbin/nandwrite...
# checking for /usr/sbin/nanddump...
# checking for /usr/sbin/flash_erase...
# checking for /usr/sbin/fw_printenv...
# checking for /etc/fw_env.config...

# Validating existing uBoot...
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00080000...
Connecting to jeff.doozan.com (69.163.187.226:80)
valid-uboot.md5      100% |**************************************************|   756  --:--:-- ETA
## Unknown uBoot detected on mtd0: 150f323cc589d1535d6e06c2038d0aa7
##
## The installer could not detect the version of your current uBoot
## This may happen if you have installed a different uBoot on
## /dev/mtd0 or if you have bad blocks on /dev/mtd0
##
## If you have bad blocks on mtd0, you should not try to install uBoot.
##
## If you have installed a diffirent uBoot on mtd0, and understand the
## risks, you can re-run the installer with the --no-uboot-check parameter
##
## Installation cancelled.
-bash-3.2# /tmp/install_uboot_mtd0.sh --noprompt --no-uboot-check parameter
# checking for /usr/sbin/nandwrite...
# checking for /usr/sbin/nanddump...
# checking for /usr/sbin/flash_erase...
# checking for /usr/sbin/fw_printenv...
# checking for /etc/fw_env.config...

# Validating existing uBoot...
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00080000...
Connecting to jeff.doozan.com (69.163.187.226:80)
valid-uboot.md5      100% |**************************************************|   756  --:--:-- ETA
## Unknown uBoot detected on mtd0: 150f323cc589d1535d6e06c2038d0aa7
##
## --no-uboot-check flag detected, continuing installation

############################################
Your device could not be auto-detected.

You must be using a device listed below to run this installer.

What device are you using? Type the number of your device and press ENTER.
1 - Seagate Dockstar
2 - Seagate GoFlex Net
3 - Pogoplug v1
4 - Pogoplug v2 - Pink
5 - Other
4
Selected Pogoplug v2 - Pink
killall: hbwd: no process killed



DISABLE POGOPLUG SERVICES

The pogoplug service includes an auto-update feature which could
be used to cripple or disable your device.  It is recommended
that you disable this service.

NOTE: The pogoplug service is proprietary software
created by Cloud Engines.  It is not available for use
in other distributions and will not be available in
your new linux installation even if you choose not to disable it.

Would you like to disable the pogoplug services? [Y/n] Y
Applying fixes to the pogoplug environment...
Disabling the pogoplug service...
Done fixing pogoplug environment.

# checking for /uboot-original-mtd0.kwb...

# Installing /uboot-original-mtd0.kwb...
Connecting to jeff.doozan.com (69.163.187.226:80)
uboot-original-mtd0. 100% |**************************************************|    67  --:--:-- ETA
Connecting to jeff.doozan.com (69.163.187.226:80)
uboot-original-mtd0. 100% |**************************************************|   512k 00:00:00 ETA
# Successfully installed /uboot-original-mtd0.kwb.
# checking for /usr/sbin/blparam...

# Installing /usr/sbin/blparam...
Connecting to jeff.doozan.com (69.163.187.226:80)
blparam.md5          100% |**************************************************|    42  --:--:-- ETA
Connecting to jeff.doozan.com (69.163.187.226:80)
blparam              100% |**************************************************| 14168  --:--:-- ETA
# Successfully installed /usr/sbin/blparam.

# Installing uBoot
## Installing pinkpogo jeff-2010-10-23
Connecting to jeff.doozan.com (69.163.187.226:80)
uboot.mtd0.kwb.md5   100% |**************************************************|    74  --:--:-- ETA
Connecting to jeff.doozan.com (69.163.187.226:80)
uboot.mtd0.kwb       100% |**************************************************|   512k 00:00:00 ETA
Erase Total 4 Units
Performing Flash Erase of length 131072 at offset 0x60000
MTD Erase failure: Input/output error
Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
Writing data to block 2 at offset 0x40000
Writing data to block 3 at offset 0x60000
Bad block at 60000, 1 block(s) from 60000 will be skipped
Writing data to block 4 at offset 0x80000
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00080000...
## Verifying new uBoot...
Connecting to jeff.doozan.com (69.163.187.226:80)
uboot.mtd0.kwb.md5   100% |**************************************************|    74  --:--:-- ETA
##
##
## VERIFICATION FAILED!
##
## uBoot was not properly installed to mtd0.
##
##
## YOUR DEVICE MAY BE IN AN UNUSABLE STATE.
## DO NOT REBOOT OR POWER OFF YOUR DEVICE
##
##
## Make a backup of /tmp/uboot-mtd0-dump someplace safe and
## then re-run this installer.

OK! after this point, I proceeded to save the /tmp/uboot-mtd0-dump to /usr/local/ to make sure it's safe there. And then tried to erase 5 blocks, and do a nandwrite hopping it will skip the bad block and write to block 5.

-bash-3.2# /usr/sbin/flash_erase /dev/mtd0 0 5
Erase Total 5 Units
Performing Flash Erase of length 131072 at offset 0x60000
MTD Erase failure: Input/output error

-bash-3.2# /usr/sbin/nandwrite /dev/mtd0 uboot.mtd0.kwb
Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
Writing data to block 2 at offset 0x40000
Writing data to block 3 at offset 0x60000
Bad block at 60000, 1 block(s) from 60000 will be skipped
Writing data to block 4 at offset 0x80000

At this point my question is: how do I do a nanddump to get enough data to verify that uBoot was written the way we hope it would? i.e. compare the mtd0 md5 with Jeff's uboot.mtd0.kwb.md5 (listing below)

-bash-3.2# ls -l
-rwxr-xr-x    1 root     root        17281 Jan  1 00:10 install_uboot_mtd0.sh
-rwxr-xr-x    1 root     root        17281 Jan  1 00:40 install_uboot_mtd0.sh.save
-rw-r--r--    1 root     root       524288 Jan  1 00:38 mtd0.uboot
-rw-r--r--    1 root     root           23 Jan  1 00:00 resolv.conf
-rw-r--r--    1 root     root       524288 Jan  1 00:38 uboot-mtd0-dump
-rw-r--r--    1 root     root       524288 Jan  1 00:38 uboot.mtd0.kwb
-rw-r--r--    1 root     root           74 Jan  1 00:38 uboot.mtd0.kwb.md5
drwxr-xr-x    2 root     root           40 Jan  1 00:00 var

Really appreciate any help to proceed further at this point :-)
bodhi
Re: Pogoplug Pink fails in Validating Existing Uboot
September 04, 2011 08:56PM
Actually, this looks promising, bodhi. It appears that the nandwrite caught the bad block and correctly shifted the last block of data to the next good block.

Look, I'm no expert, but here's what I'd do:

First, and foremost, I don't think the new uBoot environment was ever written to the NAND. (Jeff's script bails out without doing that after it thought the uBoot was not correctly written.) Search through his install script and find the part where the environment is written and extract and execute that to put a sane environment on the NAND. It should include the command to erase one block of the NAND from location 0xc0000 followed by a nandwrite of the environment file. You may have to tweak some of the environment afterwards -- things like the MAC address, the ARC number, etc.

Another thing you may well want to do, if you don't have a hardware console connection, is to install the uBoot env changes to utilize the net console.

Second, you need to verify that the uBoot itself really is correct on the NAND. To do this, you'll need to selectively dump the NAND using the nanddump command. You might try:
nanddump -bnof /tmp/uBoot.dump -l 0x80000 /dev/mtd0
If that doesn't work, try:
nanddump -nof /tmp/uBoot1.dump -l 0x60000 /dev/mtd0
nanddump -nof /dev/uBoot2.dump -l 0x20000 -s 0x80000 /dev/mtd0
and then see if the concatenation of these files is equivalent to the original uBoot file.

Once you are convinced that the uBoot is successfully written to blocks 1-3 and 5 (with bad block 4 in the middle), and that the environment is correctly written, you really can't do much else other than cross your fingers and reboot. Either it will work, or it won't, but at some point you'll have to take that plunge.

Good luck, and if you have any questions, I'll try to answer them. But, at least put the uBoot environment on the NAND so there is at least a chance if your Pogoplug reboots that it will work.
Re: Pogoplug Pink fails in Validating Existing Uboot
September 05, 2011 02:46AM
Thanks restamp! I'll keep you posted.
- bodhi
Re: Pogoplug Pink fails in Validating Existing Uboot
September 06, 2011 02:13AM
@restamp,

I have a chance to continue on with my pink Pogo today! Here is what I've done so far, and some questions arised, hope you can shed light to these :-)

The following log shows these steps: Download the uboot.environment. Setup netconsole to get ready. And then flash uboot.environment. Do a fw_printenv to list all env variables.


#download uboot environment

Pogoplug:/tmp$ wget -O /tmp/uboot.environment http://jeff.doozan.com/debian/uboot/files/environment/uboot.environment
Connecting to jeff.doozan.com (69.163.187.226:80)
uboot.environment    100% |*******************************|   128k --:--:-- ETA

Pogoplug:/tmp$ ls -l uboot.environment
-rw-r--r--    1 root     root       131072 Jan  1 11:52 uboot.environment

# Setup netconsole 

Pogoplug:/tmp$ /usr/sbin/fw_setenv serverip 192.168.0.200
Pogoplug:/tmp$/usr/sbin/fw_setenv ipaddr 192.168.0.15
Pogoplug:/tmp$/usr/sbin/fw_setenv serverip 192.168.0.200
Pogoplug:/tmp$/usr/sbin/fw_setenv start_netconsole 'setenv ncip $serverip; setenv bootdelay 10; setenv stdin nc; setenv stdout nc; setenv stderr nc; version;'
Pogoplug:/tmp$/usr/sbin/fw_setenv preboot 'run if_netconsole start_netconsole'

Pogoplug:/tmp$ /usr/sbin/fw_printenv
bootcmd=bootp; setenv bootargs root=/dev/nfs nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
bootdelay=5
baudrate=115200
ipaddr=192.168.0.15
serverip=192.168.0.200
start_netconsole=setenv ncip $serverip; setenv bootdelay 10; setenv stdin nc; setenv stdout nc; setenv stderr nc; version;
preboot=run if_netconsole start_netconsole

# flash the uboot environment

Pogoplug:/tmp$ /usr/sbin/flash_erase /dev/mtd0 0xc0000 1
Erase Total 1 Units
Performing Flash Erase of length 131072 at offset 0xc0000 done
Pogoplug:/tmp$ /usr/sbin/nandwrite  -s 786432 /dev/mtd0 /tmp/uboot.environment
Writing data to block 6 at offset 0xc0000

Pogoplug:/tmp$ /usr/sbin/fw_printenv

ethact=egiga0
bootdelay=3
baudrate=115200
arcNumber=2097
mainlineLinux=yes
console=ttyS0,115200
led_init=green blinking
led_exit=green off
led_error=orange blinking
mtdparts=mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)
mtdids=nand0=orion_nand
partition=nand0,2
stdin=serial
stdout=serial
stderr=serial
rescue_installed=0
rescue_set_bootargs=setenv bootargs console=$console ubi.mtd=2 root=ubi0:rootfs ro rootfstype=ubifs $mtdparts $rescue_custom_params
rescue_bootcmd=if test $rescue_installed -eq 1; then run rescue_set_bootargs; nand read.e 0x800000 0x100000 0x400000; bootm 0x800000; else run pogo_bootcmd; fi
pogo_bootcmd=if fsload uboot-original-mtd0.kwb; then go 0x800200; fi
force_rescue=0
force_rescue_bootcmd=if test $force_rescue -eq 1 || ext2load usb 0:1 0x1700000 /rescueme 1 || fatload usb 0:1 0x1700000 /rescueme.txt 1; then run rescue_bootcmd; fi
ubifs_mtd=3
ubifs_set_bootargs=setenv bootargs console=$console ubi.mtd=$ubifs_mtd root=ubi0:rootfs rootfstype=ubifs $mtdparts $ubifs_custom_params
ubifs_bootcmd=run ubifs_set_bootargs; if ubi part data && ubifsmount rootfs && ubifsload 0x800000 /boot/uImage && ubifsload 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000; fi
usb_scan=usb_scan_done=0;for scan in $usb_scan_list; do run usb_scan_$scan; if test $usb_scan_done -eq 0 && ext2load usb $usb 0x800000 /boot/uImage 1; then usb_scan_done=1; echo "Found bootable drive on usb $usb"; setenv usb_device $usb; setenv usb_root /dev/$dev; fi; done
usb_scan_list=1 2 3 4
usb_scan_1=usb=0:1 dev=sda1
usb_scan_2=usb=1:1 dev=sdb1
usb_scan_3=usb=2:1 dev=sdc1
usb_scan_4=usb=3:1 dev=sdd1
usb_init=run usb_scan
usb_device=0:1
usb_root=/dev/sda1
usb_rootfstype=ext2
usb_rootdelay=10
usb_set_bootargs=setenv bootargs console=$console root=$usb_root rootdelay=$usb_rootdelay rootfstype=$usb_rootfstype $mtdparts $usb_custom_params
usb_bootcmd=run usb_init; run usb_set_bootargs; run usb_boot
usb_boot=mw 0x800000 0 1; ext2load usb $usb_device 0x800000 /boot/uImage; if ext2load usb $usb_device 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000; else bootm 0x800000; fi
bootcmd=usb start; run force_rescue_bootcmd; run ubifs_bootcmd; run usb_bootcmd; usb stop; run rescue_bootcmd; run pogo_bootcmd; reset

The questions are:
- arc number is set here as 2097. Should I set it to the Dockstar arc number 2998? I thought 2998 is the correct number, but want to confirm it.
- I did not see the mac address in the fw_printenv output. Should that be a concern?

I already got 2 nc sessions running on my Windows PC, one for view mode and one for update mode, using instruction from Jeff's post:
nc -l -u -p 6666
nc -u 192.168.0.15 6666

Appreciate it if you could take a look at these Uboot envs above to see if anything is not what we expect to!

-bodhi



Edited 1 time(s). Last edit at 09/06/2011 02:15AM by bodhi.
Re: Pogoplug Pink fails in Validating Existing Uboot
September 06, 2011 04:52AM
... Continuing the post above with the verification of uBoot file!

It does seem that the uBoot was successfully written to blocks 1-3 and 5.

Pogoplug:/tmp$ /usr/sbin/nanddump -nof /tmp/uBoot1.dump -l 0x60000 /dev/mtd0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00060000...

Pogoplug:/tmp$ /usr/sbin/nanddump -nof /tmp/uBoot2.dump -l 0x20000 -s 0x80000 /dev/mtd0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00080000 and ending at 0x000a0000...

Pogoplug:/tmp$ cat uBoot1.dump uBoot2.dump > uBoot.dump

Pogoplug:/tmp$ ls -l uBoot*.dump
-rw-r--r--    1 root     root       524288 Jan  2 13:31 uBoot.dump
-rw-r--r--    1 root     root       393216 Jan  2 13:23 uBoot1.dump
-rw-r--r--    1 root     root       131072 Jan  2 13:28 uBoot2.dump

Pogoplug:/tmp$ ls -l uboot.mtd0.kwb
-rw-r--r--    1 root     root       524288 Jan  1 00:38 uboot.mtd0.kwb

Pogoplug:/tmp$ diff -s uboot.mtd0.kwb uBoot.dump
Files uboot.mtd0.kwb and uBoot.dump are identical

Re: Pogoplug Pink fails in Validating Existing Uboot
September 06, 2011 05:48AM
@bodhi

*After* writing the uboot environment to nand, you need to set ethaddr, arcNumber, and then the netconsole stuff. Your netconsole config doesn't exist because you did it before writing the environment. And it won;t work without ethaddr.
Re: Pogoplug Pink fails in Validating Existing Uboot
September 06, 2011 02:07PM
kraqh3d Wrote:
-------------------------------------------------------
> @bodhi
>
> *After* writing the uboot environment to nand, you
> need to set ethaddr, arcNumber, and then the
> netconsole stuff. Your netconsole config doesn't
> exist because you did it before writing the
> environment. And it won;t work without ethaddr.

kraqh3d,

Thanks for the tips! I thought it was missing something, too, and it was pretty late here so did not ask. Will setup the netconsole and envs again and hope for the best :-)

bodhi
Re: Pogoplug Pink fails in Validating Existing Uboot
September 06, 2011 02:19PM
Bodhi, kraqh3d is correct about setting the ethaddr to the correct MAC address. Here is the diff of my Pogoplug's environment and the one you posted:
4a4
> arcNumber=2097
40,46d39
< ethaddr=00:25:31:00:AB:CD
< arcNumber=2097
< serverip=192.168.2.1
< ipaddr=192.168.2.2
< if_netconsole=ping $serverip
< start_netconsole=setenv ncip $serverip; setenv bootdelay 10; setenv stdin nc; setenv stdout nc; setenv stderr nc; version;
< preboot=run if_netconsole start_netconsole
The ethaddr needs to be added. A viable arcNumber is already in your environment. The rest sets up the net console: 192.168.2.1 is the address of the box running the 'nc's, and 192.168.2.2 is the address the uBoot claims on the Pogoplug.

It looks good to me. Now, the only question is whether the uBoot will correctly skip the bad block while loading itself into memory. Good luck. Hope it works. (But, don't forget to set ethaddr first -- that would be showstopper!)
Re: Pogoplug Pink fails in Validating Existing Uboot
September 06, 2011 03:20PM
restamp, thanks for verifying the settings! I will try this tonight and report back.
Re: Pogoplug Pink fails in Validating Existing Uboot
September 06, 2011 08:17PM
Great news :-)

It works as we hoped and expected. I modified the uBoot envs, setup netconsole on the Pogoplug Pink, started netconsoles from my Windows laptop, and then put in the Debian USB stick (backup image for the Dockstar), and rebooted.

Also note that previously, I've missed one of the netconsole setenv statements. Caught that thanks to restamp diff listing above!
Pogoplug:~$ /usr/sbin/fw_setenv if_netconsole 'ping $serverip'

Works perfectly as a clone of my Dockstar!

Many thanks to restamp for the instruction, also thanks kraqh3d for reviewing the uBoot envs. So now we know for sure uBoot correctly skips the bad block :-)

I've included the boot sequence below for future references.

Thanks again guys!
bodhi

C:\Archive\Netcat for Windows\netcat for Windows - nc111nt>nc -l -u -p 6666

U-Boot 2010.09 (Oct 23 2010 - 11:51:16)
Marvell-PinkPogo by Jeff Doozan
Hit any key to stop autoboot:  0
(Re)start USB...
USB:   Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 3 USB Device(s) found
       scanning bus for storage devices... 1 Storage Device(s) found
Loading file "/rescueme" from usb device 0:1 (usbda1)
** File not found /rescueme
reading /rescueme.txt

** Unable to read "/rescueme.txt" from usb 0:1 **
Creating 1 MTD partitions on "nand0":
0x000002500000-0x000008000000 : "mtd=3"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    129024 bytes
UBI: smallest flash I/O unit:    2048
UBI: sub-page size:              512
UBI: VID header offset:          512 (aligned 512)
UBI: data offset:                2048
UBI: attached mtd1 to ubi0
UBI: MTD device name:            "mtd=3"
UBI: MTD device size:            91 MiB
UBI: number of good PEBs:        720
UBI: number of bad PEBs:         8
UBI: max. allowed volumes:       128
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     0
UBI: available PEBs:             709
UBI: total number of reserved PEBs: 11
UBI: number of PEBs reserved for bad PEB handling: 7
UBI: max/mean erase counter: 1/1
UBIFS error (pid 0): ubifs_get_sb: cannot open "ubi:rootfs", error -19
Error reading superblock on volume 'ubi:rootfs'!
Loading file "/boot/uImage" from usb device 0:1 (usbda1)
1 bytes read
Found bootable drive on usb 0:1
Loading file "/boot/uImage" from usb device 0:1 (usbda1)
1431936 bytes read
Loading file "/boot/uInitrd" from usb device 0:1 (usbda1)
4888086 bytes read
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   Debian kernel 2.6.32-5-kirkwood
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1431872 Bytes = 1.4 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 01100000 ...
   Image Name:   Debian ramdisk 2.6.32-5-kirkwood
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    4888022 Bytes = 4.7 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...



Edited 1 time(s). Last edit at 09/06/2011 08:29PM by bodhi.
Re: Pogoplug Pink fails in Validating Existing Uboot
September 06, 2011 08:46PM
Great news indeed!

Thanks for being the guinea pig in this experiment, bodhi, but hey, being a successful guinea pig ain't all that bad, is it!

Hope you get many years of use out of your Pogoplug.
Re: Pogoplug Pink fails in Validating Existing Uboot
September 06, 2011 09:42PM
restamp Wrote:
-------------------------------------------------------
> Great news indeed!
>
> Thanks for being the guinea pig in this
> experiment, bodhi, but hey, being a successful
> guinea pig ain't all that bad, is it!
>
> Hope you get many years of use out of your
> Pogoplug.

restamp, not bad at all being a successful guinea pig, indeed! with your help and kraqh3d's, it's certainly a high percentage bet. I'll volunteer to be one again any time :-) Speaking of volunteering while we're on a winning streak (1 for 1)!, I also bought a Pogoplug Pro on sale a few months ago. Perhaps that could be the next guinea pig for Debian? WarheadsSE and oddballhero said it could be done, but I don't know enough about how to do that, whether it's an easy or hard job.

Also, I've just cold booted the pink Pogoplug a few times to be sure (I'm using a Sandisk Cruiser stick). It booted into Debian every time. The only minor thing that's not quite right yet is the LED (I'm still using Dockstar settings so when the pink Pogo is halted, the LED is not turned off, but when I cold boot, it turned on OK when it's fully operational).

Thanks
Re: Pogoplug Pink fails in Validating Existing Uboot
September 07, 2011 09:01AM
Great news!
Re: Pogoplug Pink fails in Validating Existing Uboot
September 07, 2011 04:21PM
bodhi Wrote:
-------------------------------------------------------
> restamp Wrote:
> restamp, not bad at all being a successful guinea
> pig, indeed! with your help and kraqh3d's, it's
> certainly a high percentage bet. I'll volunteer to
> be one again any time :-) Speaking of volunteering
> while we're on a winning streak (1 for 1)!, I also
> bought a Pogoplug Pro on sale a few months ago.
> Perhaps that could be the next guinea pig for
> Debian? WarheadsSE and oddballhero said it could
> be done, but I don't know enough about how to do
> that, whether it's an easy or hard job.
>


Bodhi,
Here is a link to how somebody loaded Fedora onto the Pro and Debian could probably be done the same way http://lists.fedoraproject.org/pipermail/arm/2011-July/001622.html . Just make sure that you have a CA-42 cable and make a backup of mtd1 and have 2 usb flash drives (one for ArchLinuxARM and one a copy of your Debian). The installation that WarheadsSE setup for ArchLinuxARM does not touch the uboot so it's not as radical as installing Jeff's uboot. So two ways to do this.

First way is like the link above which installs ArchLinuxARM and then you substitute the Debian usb flash drive (after copying the contents of /lib/modules/2.6.31.6_SMP_820/ and /usr/local/ from the ArchLinuxARM usb flash drive to the Debian usb flash drive) in place of the ArchLinuxARM usb flash drive. Make sure to save the ArchLinuxARM usb flash drive in case the process did not work. At the very least it allows you to go back to the original system (the ArchLinuxARM forum has instructions on restoring to the previous system: update - here is a link to the script - http://archlinuxarm.org/os/oxnas/oxnas-revert.sh ) or you can use ArchLinuxARM which is a good system on it's own. On the Fedora link above, also, see the caveats about network access and the gmac module.

Second way is to use the kernel that is already on the Pro and copy the contents of /lib/modules from NAND to your Debian Flash drive and use blparam to modify bootargs so that root points to sda1, rootfstype is either ext2 or ext3 depending on what your Debian Flash drive is formatted as, and mac_adr is your mac address. With this method, definitely have a CA-42 cable and backup of mtd1 as mentioned before.

In both cases, monitor the sizes of the log files in /var/log and monitor disk space with "df" to make sure you do not run out of space if the log files gets too large if there is a problem with udev or anything else. Just like ArchLinuxARM or the above Fedora installation, you are stuck with the 2.6.31 kernel until somebody decides to copy the modifications to a newer kernel like Callum Lerwick did. This is not worth my time since the PLX Oxnas chip is pretty much a closed proprietary system (I tried getting documentation from PLX Technology but was refused) and I have my PLX Oxnas systems doing what I want (I only have two). With the new Pogoplug Mobile coming out, I don't know if CloudEngines will still be using the same chip. Back to the Debian installation, it would probably help to do a "depmod -a" after booting into the Debian flash just to make sure all the modules register in either situation.

As with my other posts, try this at your own risk, as-is, no warranties and if you do not feel comfortable with this, don't do it.
Congratulations on modifying your E02 uboot.


Addendum:
Looks like other people have gotten Debian on Oxnas to work:
http://www.pogoplugged.com/forum/thread/21813/Can-someone-share-original-rcS-for-pogoplug-Pro/#20565
http://archlinuxarm.org/forum/viewtopic.php?f=29&t=1730&start=10#p10374



Edited 3 time(s). Last edit at 11/13/2011 08:01PM by oddballhero.
Re: Pogoplug Pink fails in Validating Existing Uboot
September 07, 2011 05:25PM
oddballhero,

Thanks for the well written instructions! without reading the completed description in that link, I'm leaning toward the first approach. It sounds like a pretty safe approach, since the fallback is using ArchLinuxARM, or going back to the original system to try again another day :-) I would be happy using ArchLinuxARM with a strong support community for it already.

-bodhi
Re: Pogoplug Pink fails in Validating Existing Uboot
November 18, 2011 07:03PM
@major,

If you're still around this forum, could you post the details of your Debian installation back here, as you mentioned in this thread ?
http://archlinuxarm.org/forum/viewtopic.php?f=29&t=1730&start=10#p10374

Thanks,
-bodhi
Author:

Your Email:


Subject:


Spam prevention:
Please, enter the code that you see below in the input field. This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right. If you enter the wrong code, a new image is created and you get another chance to enter it right.
Message: