Welcome! Log In Create A New Profile

Advanced

uboot installs, but not environment. [Inactive]

Posted by chackoc 
uboot installs, but not environment. [Inactive]
February 05, 2013 06:22PM
I have a black E02. The install script appears to install uboot ok but fails when trying to install the environment.

...
If you agree, type 'ok' and press ENTER to continue: ok
# 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 (50.116.34.13:80)
valid-uboot.md5      100% |***************************************************************|  1133  --:--:-- ETA
## Valid uBoot detected: [pinkpogo davygravy-2012-02-20-current]
## The newest uBoot is already installed on mtd0.


You are already running the latest uBoot.
Your current uBoot environment should be reasonable.  However, if you're having
any probems booting, you can reset the environment variables to know good values.
Would you like to reset the uBoot environment? [N/y] y

# Installing uBoot environment
Connecting to download.doozan.com (50.116.34.13:80)
uboot.environment.md 100% |***************************************************************|    32  --:--:-- ETA
Erase Total 1 Units
Performing Flash Erase of length 131072 at offset 0xc0000
MTD Erase failure: Input/output error
Writing data to block 6 at offset 0xc0000
Bad block at c0000, 1 block(s) from c0000 will be skipped
Writing data to block 7 at offset 0xe0000

# Verifying uBoot environment
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x000c0000 and ending at 0x000e0000...
Connecting to download.doozan.com (50.116.34.13:80)
uboot.environment.md 100% |***************************************************************|    32  --:--:-- ETA
## VERIFICATION FAILED!
## uBoot environment was not properly written to mtd0.  Please re-run this installer.

From that output it almost looks like the installer may have succesfully id'ed the bad block and written the env to block 7 instead of 6. Is that correct?

It looks like the script does it's verification against the hardcoded block 6 so that might explain why the verification failed. I edited the script as follows to see if the env was succesfully written to block 7:

Pogoplug:/tmp$ !diff
diff install_uboot_mtd0.sh install_uboot_mtd0_mod.sh 
--- install_uboot_mtd0.sh	Sat Jan  1 00:01:45 2000
+++ install_uboot_mtd0_mod.sh	Sat Jan  1 00:56:45 2000
@@ -527,7 +527,7 @@
   echo "# Verifying uBoot environment"
 
   # Verify the uBoot environment
-  $NANDDUMP --noecc --omitoob -f "/tmp/uboot.environment" -s 0xc0000 -l 0x20000 /dev/mtd0
+  $NANDDUMP --noecc --omitoob -f "/tmp/uboot.environment" -s 0xe0000 -l 0x20000 /dev/mtd0
   wget -O "$UBOOT_ENV.md5" "$UBOOT_ENV_URL.md5"
   verify_md5 "/tmp/uboot.environment" "$UBOOT_ENV.md5"
   if [ "$?" -ne "0" ]; then
Pogoplug:/tmp$

But when I ran the modified script it still failed verification.

# Installing uBoot environment
Connecting to download.doozan.com (50.116.34.13:80)
uboot.environment.md 100% |***************************************************************|    32  --:--:-- ETA
Erase Total 1 Units
Performing Flash Erase of length 131072 at offset 0xc0000
MTD Erase failure: Input/output error
Writing data to block 6 at offset 0xc0000
Bad block at c0000, 1 block(s) from c0000 will be skipped
Writing data to block 7 at offset 0xe0000

# Verifying uBoot environment
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x000e0000 and ending at 0x00100000...
Connecting to download.doozan.com (50.116.34.13:80)
uboot.environment.md 100% |***************************************************************|    32  --:--:-- ETA
## VERIFICATION FAILED!
## uBoot environment was not properly written to mtd0.  Please re-run this installer.

In any case rebooting with a USB drive doesn't work. The LED just lights up orange and my routers device table never shows the rebooting box. I'm also unable to use fw_printenv. I get the following:

Pogoplug:/tmp$ /usr/sbin/fw_printenv 
Too few good blocks within range
Pogoplug:/tmp$

Does anyone have any ideas on how to move forward? It seems like others who have had problems were able to skip a bad block and write the objects to the next blocks. Should I try doing that by manually having my modded script write to block 7 (which I assume is 0xe0000)? Perhaps the issue is that block 7 isn't erased before being written to?

For the record, the proposed changes to the script are shown below, but I'm pretty terrified that if I run this I'll brick the box since I don't really know anything about any of this hardware.

Pogoplug:/tmp$ !diff
diff install_uboot_mtd0.sh install_uboot_mtd0_mod.sh 
--- install_uboot_mtd0.sh	Sat Jan  1 00:01:45 2000
+++ install_uboot_mtd0_mod.sh	Sat Jan  1 01:11:18 2000
@@ -520,14 +520,14 @@
     echo "## Could not install uBoot environment, exiting"
     exit 1
   fi
-  $FLASH_ERASE /dev/mtd0 0xc0000 1
-  $NANDWRITE -s 786432 /dev/mtd0 "$UBOOT_ENV"
+  $FLASH_ERASE /dev/mtd0 0xe0000 1
+  $NANDWRITE -s 917504 /dev/mtd0 "$UBOOT_ENV"
 
   echo ""
   echo "# Verifying uBoot environment"
 
   # Verify the uBoot environment
-  $NANDDUMP --noecc --omitoob -f "/tmp/uboot.environment" -s 0xc0000 -l 0x20000 /dev/mtd0
+  $NANDDUMP --noecc --omitoob -f "/tmp/uboot.environment" -s 0xe0000 -l 0x20000 /dev/mtd0
   wget -O "$UBOOT_ENV.md5" "$UBOOT_ENV_URL.md5"
   verify_md5 "/tmp/uboot.environment" "$UBOOT_ENV.md5"
   if [ "$?" -ne "0" ]; then
Pogoplug:/tmp$

Also, in case it's not blindingly obvious, while I'm comfortable on the software side of linux, messing around with this sort of stuff is completely new to me.



Edited 2 time(s). Last edit at 02/25/2013 08:30PM by chackoc.
Re: uboot installs, but not environment. should my script mod work in theory?
February 05, 2013 09:01PM
chackoc,

It does look like it will work, in theory. All numbers seem right as I did a sanity check. Also I think this is important, mtd0 partition size is 1M. When you flash uBoot envs (which is 1 block) to the address 0xe0000, it will end at 0x00100000 (which is 1M). So it will fit.

If the installation script continues w/o problem, don't reboot yet. Do these:

1. Verify your uBoot envs were installed correctly with fw_printenv. You will need to change the file /etc/fw_env.config to use the new address 0xe0000. And run /usr/sbin/fw_printenv.

2 . If the envs were installed OK, and you can run fw_printenv, then set up netconsole right away. See this thread:
http://forum.doozan.com/read.php?3,14

In any case, that's my take, but pls proceed only if you're willing to connect a serial console to recover if any thing goes wrong :) You can use serial console to recover because you've installed uBoot successfully.

And post your uBoot envs here if you'd like, for confirmation before reboot.

Good luck!
Re: uboot installs, but not environment. should my script mod work in theory?
February 06, 2013 01:00AM
Thanks for the sanity check bodhi. I ran the modified script. It failed at first but then I cleared out the existing /tmp/uboot.environment file and it worked. (I guess wget was seeing the existing file and not redownloading a fresh copy?)

I also corrected /etc/fw_env.config (thanks for that, never would have found it without the mention).

Now when I rerun the modified install script everything looks to go smoothly:

...
# 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 (50.116.34.13:80)
valid-uboot.md5      100% |**************************************************************************|  1133  --:--:-- ETA
## Valid uBoot detected: [pinkpogo davygravy-2012-02-20-current]
## The newest uBoot is already installed on mtd0.


You are already running the latest uBoot.
Your current uBoot environment should be reasonable.  However, if you're having
any probems booting, you can reset the environment variables to know good values.
Would you like to reset the uBoot environment? [N/y] y

# Installing uBoot environment
Connecting to download.doozan.com (50.116.34.13:80)
uboot.environment.md 100% |**************************************************************************|    32  --:--:-- ETA
Connecting to download.doozan.com (50.116.34.13:80)
uboot.environment    100% |**************************************************************************|   128k --:--:-- ETA
Erase Total 1 Units
Performing Flash Erase of length 131072 at offset 0xe0000 done
Writing data to block 7 at offset 0xe0000

# Verifying uBoot environment
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x000e0000 and ending at 0x00100000...
Connecting to download.doozan.com (50.116.34.13:80)
uboot.environment.md 100% |**************************************************************************|    32  --:--:-- ETA

# uBoot installation has completed successfully.

/usr/sbin/fw_printenv also looks to be working now. Shown below is the output including the variables I set in case I need to use netconsole.

Pogoplug:/tmp$ /usr/sbin/fw_printenv 
ethact=egiga0
bootdelay=3
baudrate=115200
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
arcNumber=2097
serverip=192.168.0.8
ipaddr=192.168.0.22
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
Pogoplug:/tmp$

I think I'm ready to reboot, and I'm hopeful everything is working ok now. That said it's late and I don't really want to deal with any further issues tonight so I'm going to leave the box up for now and try rebooting tomorrow. Thanks again for the help bodhi.
Re: uboot installs, but not environment. should my script mod work in theory?
February 06, 2013 11:40AM
chackoc,

Look like you've done all you can to set up uBoot envs. Now the question remained is whether uBoot will skip that bad block and read the envs in the next block. I don't really know. In my successful attempt to get uBoot to load its image around the bad block, it did. So I think you have a pretty good probability that this will work. Please let us know :)
Re: uboot installs, but not environment. should my script mod work in theory?
February 06, 2013 02:05PM
No luck on reboot. LED stayed orange and there was nothing on my nc. I did notice that a new device showed up on my router with a random mac address so it ended up getting an IP other than the one i set as ipaddr with fw_setenv. That probably had something to do with not seeing any netconsole output. That device wasn't pingable though so not much I can do to test it.

I'll play around with networking for now to see if I can get netconsole working. Hopefully that will show me why the USB isn't booting. Thankfully the plug seems to boot succesfully into the default OS when I remove the USB drive.
Re: uboot installs, but not environment. should my script mod work in theory?
February 06, 2013 02:26PM
chackoc,

Darn :) It's worth a try. Good to know that one way or the other. I think the reason it did not work is probably when uBoot try to load the envs from 0xc0000 it encountered the bad block so gave up, and uses the default envs. I hoped it would skip it, but apparently it did not. If I understand correctly, the location 0xc0000 and the size of envs were hardcoded in uBoot header file, so I guess we can't do much about it. Because of the envs failed to load, I don't think netconsole would work, either (we have to set it up in the envs, so it's a catch-22).

As long as it boots in to the default OS, you're OK. You could flash back the stock uBoot while in the default OS.

If you're determined to get it to boot Debian, I think serial console is the best bet. You will be able to interrupt uBoot and play with the envs to see if it is possible to boot USB. The Pogo E02 has a serial header built-in, so there is no soldering needed.
Re: uboot installs, but not environment. should my script mod work in theory?
February 06, 2013 03:25PM
When I SSH into the new box the envs look ok (i.e. fw_printenv works and shows the stuff I added in). Are you saying that it boots up with default envs and then somewhere later in the boot process it picks up the custom stuff? Or is fw_printenv showing some theoretical environment that doesn't actually correspond to the running environment?

I did notice that even when rebooting into the stock OS (i.e. with no USB attached) nc on my laptop is still blank, so that probably supports your read of the situation.

With the serial cable it sounds like I would have to manually intervene every time the box reboots. That wouldn't really be sustainable if that's the case. Although since it's meant to be an always on server maybe...

For now I think I'm going to try and learn more about uboot. If it's just an address in a header somewhere maybe I could find the source and recompile it.
Re: uboot installs, but not environment. should my script mod work in theory?
February 06, 2013 05:04PM
My guess is because uBoot can't read the envs when it encounter the bad block, it loaded a default setting (which is its standard behavior)... Assuming it did, it would use that default envs to boot the kernel but could not find the kernel, so it went back to stock kernel in NAND. Once you are in the default OS, the fw_printenv tool would then use the info in fw_env.config to manipulate the envs, which you have loaded to the address. Of course we can't tell for sure if this was the case without serial console.

One way to tell is to start pinging the address 192.168.0.22 before powering on the box. You would see a response if in fact the envs for netconsole somehow took effect. If you get no response then the behavior is consistent to the theory above.

I'm pretty sure you can boot USB while you're in serial console at uBoot prompt. The only thing remained is what to do so that you can reboot/cold start the box with USB. But it would be really nice if you can recompile uBoot and share your experience with us!
Re: uboot installs, but not environment. should my script mod work in theory?
February 06, 2013 06:01PM
That makes sense. The compile instructions here (http://projects.doozan.com/uboot/build_uboot.htm) seem pretty straightforward and the patch mentioned (http://projects.doozan.com/uboot/patches/mach-pinkpogo.patch) does indeed appear to hardcode 0xc0000 as the position of the env.

As long as those instructions aren't outdated recompiling with a modified patch seems plausible. Unfortunatley the codebase referenced by that page is 2010.09 which is pretty old. Not sure if there are newer patches somewhere that correspond to the current release of the pinkpogo image.

I was hoping to solve this without purchasing anything else but I'll need the cable to test the newly compiled image anyway, so I guess figuring out where to get that is the next step.
Re: uboot installs, but not environment. should my script mod work in theory?
February 06, 2013 06:19PM
Re: uboot installs, but not environment. should my script mod work in theory?
February 07, 2013 02:42PM
Looks like the cable will take a while to get here so I'm going to stick this project on the back burner for now. Thanks again for all the help bodhi.
Re: uboot installs, but not environment. should my script mod work in theory?
February 25, 2013 06:27PM
Just to close this off, I got the cable and had a look at the bootup. It turns out arch was actually booting ok despite the corrupt block 6. There was a problem with the networking service that was preventing networking from working. This, combined with the fact that the LED stayed orange, led me to erroneously believe that arch wasn't even booting.

I ended up fixing the networking issue with the following commands (though I don't really know what they do)
systemctl disable netcfg.service
systemctl enable dhcpcd@eth0.service
systemctl enable netcfg@wired-eth0.service

Now on reboots networking appears to work and I can SSH into the box. The only real issue left is that it has a new MAC address every reboot so my router gives it a new IP every time. I believe that's down to not being able to modify the env and I may just live with it since I can always check the router for the current IP.

The fact that the front LED stays orange is also annoying, but that's just cosmetic I suppose.

Now to familiarize myself with Arch (or explore sticking something apt-get based onto the USB stick)...
Re: uboot installs, but not environment. should my script mod work in theory?
February 25, 2013 07:58PM
Hey chackoc, congrat :) please edit your post to note that the procedure did work as intended, so will benefit others looking for solution.

As for your MAC address, you'll need to set the env for ethaddr. And for LED, look in /sys/class/leds to see the trigger for green, orange... LEDs
Re: uboot installs, but not environment. should my script mod work in theory?
February 25, 2013 08:28PM
I don't think anything I did actually worked. As far as I can tell my env is still unusable because Block 6 is corrupted and uboot falls back to defaults. That's why I can't address the MAC issue, set up netconsole, etc. I'm simply able to work around the issue now so I'll likely focus on that rather than finding a way to get access to a user-modifiable env. In any case I'll try and figure out how to flag the topic as no longer active.
Re: uboot installs, but not environment. should my script mod work in theory?
February 25, 2013 08:38PM
What you can do is trying the command setenv in serial console to set ethaddr . See if it does retain so you can boot into the kernel with the correct env. If it does I will find the env loading tool ( somebody has posted that here, but I could not remember where).
Re: uboot installs, but not environment. [Inactive]
March 03, 2013 09:03PM
I looked into this. Turns out the env value for ethaddr was already set but it still wasn't coming through to the Arch installation. I was still getting a random MAC (and thus IP from the router) every time.

I ended up addressing the problem by using a PRE_UP command with macchanger to manually set the ethernet address prior to bringing up the interface. Appears to be working and I now consistently get the same MAC and IP across reboots. As far as I'm concerned the box is now where it needs to be, although it was a bit of an adventure getting it there.

Thanks again for all the help bodhi. I'll leave the status of the thread as "Inactive" rather than "Solved" since I've given up trying to get a working, user-modifiable ENV for the case where a user is unlucky enough to get a box with a bad block 6.
hey guys, i have the exact same error.

# Verifying uBoot environment
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x000c0000 and ending at 0x000e0000...
Connecting to download.doozan.com (50.116.34.13:80)
uboot.environment.md 100% |*******************************|    32  --:--:-- ETA
## VERIFICATION FAILED!
## uBoot environment was not properly written to mtd0.  Please re-run this installer.

is there no fix or solution for it?
Re: uboot installs, but not environment. should my script mod work in theory?
June 06, 2013 11:12PM
I was able to "fix" it by getting a cable and using it to manually modify the Arch install.

If your uboot installed successfully, and the only issue is a bad block 6 preventing the env install, then I would imagine you'll be at the same position I was: Arch is loading successfully but since you weren't able to set the networking env variables the machine is loading the default env which is insufficient to get a network connection.

If that's where you are, the easiest solution is to get a cable and then use the console to fix up the networking.

The better, but more difficult, solution would be to compile a custom uboot that looks for the ENV variables in block 7 rather than 6. I wanted to go that route but I couldn't find the patches used in the published uboot images, and I didn't want to go through all the work of locating the appropriate patches myself.

I suppose you could also try spinning your own arch image with the changes I mentioned above. That's sort of a shot in the dark though. It would only work if your problem ends up being exactly like mine was and the only way to know would be to load up the modified image and see if stuff works. The cable is much better because you can actually work through any issues rather than just tossing a new Arch image at the machine and hoping it works.



Edited 1 time(s). Last edit at 06/06/2013 11:14PM by chackoc.
Re: uboot installs, but not environment. should my script mod work in theory?
June 07, 2013 03:33AM
nemmy Wrote:
-------------------------------------------------------
> hey guys, i have the exact same error.
>
>
> # Verifying uBoot environment
> Block size 131072, page size 2048, OOB size 64
> Dumping data starting at 0x000c0000 and ending at
> 0x000e0000...
> Connecting to download.doozan.com
> (50.116.34.13:80)
> uboot.environment.md 100%
> |*******************************|    32  --:--:--
> ETA
> ## VERIFICATION FAILED!
> ## uBoot environment was not properly written to
> mtd0.  Please re-run this installer.
>
>
> is there no fix or solution for it?

I don't see that it is the same problem as chackoc's. Do you have bad block? in Rescue system, look at dmesg to see if there were bad blocks reported.
!!!!!!  DANGER DANGER DANGER DANGER DANGER DANGER  !!!!!!

If you lose power to your device while running this script,
it could be left in an unusable state.

This script will replace the bootloader on /dev/mtd0.

This installer will only work on the following devices:
 Seagate Dockstar
 Seagate GoFlex Net
 Seagate GoFlex Home
 Pogoplug v1
 Pogoplug Pink (v2)
Do not run this installer on any other device.

By typing ok, you agree to assume all liabilities and risks
associated with running this installer.

If you agree, type 'ok' and press ENTER to continue: ok
# 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 (50.116.34.13:80)
valid-uboot.md5      100% |*******************************|  1133  --:--:-- ETA
## Valid uBoot detected: [pinkpogo davygravy-2012-02-20-current]
## The newest uBoot is already installed on mtd0.


You are already running the latest uBoot.
Your current uBoot environment should be reasonable.  However, if you're having
any probems booting, you can reset the environment variables to know good values.
Would you like to reset the uBoot environment? [N/y] y

# Installing uBoot environment
Connecting to download.doozan.com (50.116.34.13:80)
uboot.environment.md 100% |*******************************|    32  --:--:-- ETA
Connecting to download.doozan.com (50.116.34.13:80)
uboot.environment    100% |*******************************|   128k 00:00:00 ETA
Erase Total 1 Units
Performing Flash Erase of length 131072 at offset 0xc0000
MTD Erase failure: Input/output error
Writing data to block 6 at offset 0xc0000
Bad block at c0000, 1 block(s) from c0000 will be skipped
Writing data to block 7 at offset 0xe0000

# Verifying uBoot environment
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x000c0000 and ending at 0x000e0000...
Connecting to download.doozan.com (50.116.34.13:80)
uboot.environment.md 100% |*******************************|    32  --:--:-- ETA
## VERIFICATION FAILED!
## uBoot environment was not properly written to mtd0.  Please re-run this installer.

yea i have a bad block in 6 as well.
i thought this was going to be a fun and easy project but its turning out to be a not so fun google search project :( and i dont have a lot of experience with linux and a lot of the forums dont really make sense to me.

do you guys know of how i can re-enable my.pogoplug.com and restore back to the factory firmware on this now?
Re: uboot installs, but not environment. [Inactive]
June 07, 2013 09:11AM
The following thread suggests a method for reverting, but I've never done it and I have no idea if it works. Also there is some discussion about future firmware updates from pogo possibly bricking the device down the road.

http://archlinuxarm.org/forum/viewtopic.php?f=18&t=5388

So it does look possible but I would research the method a lot more before trying it.

Also if you want to get an arch box up it might be worth it to try again. My understanding is that the software can write the uboot around a bad block in the default uboot location, and the default install doesn't use blocks 5 or 7, so we literally have the one case (bad block 6) that the default install is incapable of working around. All that is to say that if you just get another box to try again it's unlikely you'll run into the same issue.
Re: uboot installs, but not environment. [Inactive]
June 07, 2013 01:05PM
@chackoc,

It is certainly feasible doing that. But the instruction in the link seems incomplete. Be careful, it might lock you out so do this only if you have serial console.

Other topic: re uBoot patch, the latest uBoot and a few versions before that has the Pogo E02 patch in mainline. So it could be modified to set the env address at a different location.

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



Edited 1 time(s). Last edit at 06/07/2013 01:10PM by bodhi.
Re: uboot installs, but not environment. [Inactive]
June 07, 2013 01:41PM
Can you elaborate on the "mainline" comment? Does that mean the necessary changes are already included in the default uboot sources (http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=summary)? So if I download the latest uboot (v2012.07) and compile it with an appropriate toolkit I should get the same behavior that I get from using the images installed by the generica E02 install script?

That's my baseline -- I know those generic images work on my E02. When I first looked at this I saw the header file that looks to define ENV as block 6, but I was worried that I was missing whatever other patches were used to create the E02 specific uboot images used by the scripts. If there aren't any special patches (or if all of the necessary patches are included in the v2012.07 release) then perhaps I'll revisit compiling a custom uboot at some point.
Re: uboot installs, but not environment. [Inactive]
June 07, 2013 03:35PM
Yes. Davy's Pogo E02 patch has been in mainline uBoot. I've compiled and flashed 2003.01 uBoot with Pogo E02 support already in mainline. And I also had to change the env address to 0xc0000 to be able to use current envs, as our standard location is at 0xc0000.
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: