This is a pretty good one I use: http://www.ebay.com/itm/USB-2-0-to-TTL-UART-6PIN-Module-Serial-Converter-CP2102-STC-PRGMR-Free-cable-/170895253016?pt=LH_DefaultDomain_0&hash=item27ca269e18by bodhi - uBoot
Easiest to use Davy's rootfs: http://forum.doozan.com/read.php?2,8722,11448#msg-11448by bodhi - Debian
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 theby bodhi - uBoot
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 filby bodhi - uBoot
Daveee, You can use Davy's NSA320 rootfs here : http://forum.doozan.com/read.php?2,7806. It boots just about any Kirkwwod boxes, including the GF Net.by bodhi - Debian
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 :)by bodhi - uBoot
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 uBootby bodhi - uBoot
Cassie Wrote: ------------------------------------------------------- > bodhi Wrote: > -------------------------------------------------- > ----- > > Your GF Home does have pins out, right? > Yes, it looks like this: > > http://img641.imageshack.us/img641/3348/seagategof > lexhomebasein.jpg > > thanx The wire testing hooks should work fine.by bodhi - Off-Topic
Your GF Home does have pins out, right?by bodhi - Off-Topic
I could not tell why either! did not see any error other than the mounting of sda1 failed at one point (however it seems to mount OK later). It is a little bit hard to read the log from a serial console. You could try to boot with Davy's rootfs: http://forum.doozan.com/read.php?2,7806by bodhi - Debian
Cassie, I use electrical wire testing hooks such as these: http://www.ebay.com/itm/Electrical-Wire-Testing-Hooks-20-Pack-GE-/281061090797?pt=LH_DefaultDomain_0&hash=item41708be5edby bodhi - Off-Topic
Here you go. JTAG for the Dockstar, but it should be similar to Pogo E02: http://archlinuxarm.org/forum/viewtopic.php?f=18&t=195&start=120#p4403by bodhi - uBoot
Ah! thanks for the confirmation Dhead. I saw the same behavior. MMC init does not work the first time it's called, so your work around is a nice way to get it running.by bodhi - uBoot
Since your uBoot env for rootfs type is Ext2, it should boot Ext3 without problem (but the reverse is not true). Looks like the SD card was not found by uBoot, perhaps you need to repartition, reformat and put a new roofts on it. The USB drive seems to work, but I think the Arch kernel did not complete booting, so you never got to the point where dhcp is requesting ip from the router. I would doby bodhi - uBoot
dhead, Looks great! you're still running davy's uBoot. Once you've flashed this uBoot version, the Arch revert won't work. It only works with Arch installation of uBoot. Also briefly scanning your envs, it looks fine.by bodhi - uBoot
solidplanet Wrote: ------------------------------------------------------- > usb_scan_list=1 2 3 4 Since you want to scan 8 USB devices, this list should be 1 to 8. > serverip=192.168.0.120 > ipaddr=192.168.0.211 > if_netconsole=ping $serverip > start_netconsole=setenv ncip $serverip; setenv > bootdelay 10; setenv stdin nc; setenv stdout nc; > setenv stderr nc;by bodhi - uBoot
dhead, I installed uboot-env and tried to figure out what happened. It seems that anything after flashing the uboot.environment didn't stick, So my next step was just to continue from "Adjust MTD parts". Arch Linux uBoot is a different version, so at this point, you can't use uboot-env tools, you would need to use blparam to change uBoot envs. The good sign is LEDby bodhi - uBoot
Your uBoot envs look good, and you booted back to Pogo linux. So you can just rerun the Squeeze installation from scratch. The installer will detect new uBoot and skip that part. Also, remmeber to keep the entire log of the installation.by bodhi - Debian
Pls post your output of /usr/sbin/fw_printenvby bodhi - Debian
solidplanet, If you don't have serial console to the Iconnect, I'd recommend that you set up netconsole first before changing uBoot envs. Because you could get locked out of the box with uBoot envs problem, and will have to resort to serial console. See this thread for instruction: http://forum.doozan.com/read.php?3,14by bodhi - uBoot
ploks, Looks great :) I see that you're running your own preempt rt build? it should work without problem, too (PM if you'd like to exchange info). Since you have netconsole now, as long as you don't change uBoot image/envs, you can always recover from any rootfs problem. - bodhiby bodhi - uBoot
Congratulation! if you have rebooted by mistake after step 5, and then saw the prompt Pogoplug:/tmp$ then your uBoot has been installed correctly and working. Without a USB rootfs, it would boot back into Pogo OS, and that's how the prompt looks like. I assumed you printed the envs as posted above after you've rebooted? > 1. To set ethadd is My pogoplug Mac address. istby bodhi - uBoot
The 2nd block of code is the full listing of uBoot envs on one of my plugs. The 1st block of code is the list of the relevant uBoot envs in reversed order of variable assigments (backward from the bootcmd). It would be obvious what need to be changed when we substitue the value of each variable. The crucial point here is the execution order ensures that the content of the variable usb_rootby bodhi - uBoot
The rootfs label approach is described here: http://forum.doozan.com/read.php?3,8044,8152#msg-8152 Basically, rootfs label environment variable will tell uBoot to find the USB drive with that label and use that for booting. So does not matter how many drives are connected to the box, it will use the correct drive for rootfs, as long as it's the only drive with that specific label.by bodhi - uBoot
TJ Wrote: ------------------------------------------------------- > I note > that Arch uses a different approach of insisting > that the mac address be in a file: > /usr/local/mac_addr > It's only true for the Pogoplug Pro (OXNAS)! For the other models, Arch Linux ARM does not need /usr/local/mac_addr.by bodhi - Debian
ploks, Looks really good! Step 2 is exactly what we hope to see. 2 more things to check before reboot: - Is ethaddr the Pogoplug's MAC address? this is important Pogoplug:/tmp$ /usr/sbin/fw_setenv ethaddr=00:25:31:02:D6:74 - Please post the output of /usr/sbin/fw_printenv If the output of fw_printenv looks sane, then you shoud use an existing roofts (e.g. davy's NSA320by bodhi - uBoot
Did you try flash_erase and nandwrite again before nanddump?by bodhi - uBoot
daveeeee, The saved image and what in NAND differs because looks like you've dumped it starting at block 0, which is your bad block. Try: nanddump -bnof /tmp/uBoot.dump -l 0x80000 -s 0x20000 /dev/mtd0 Do the diff again afterward, if the saved image uboot.mtd0.kwb is identical with uBoot.dump then you can flash the uBoot env.by bodhi - uBoot
Step 6 is not necessary. It actually reversed the works you've done in step 1 to 5 (uBoot was installed manually in step 1). So retry step 1 to 5. Also, your step 2 does not look right. Look again at the referenced thread above to see how the 2 chunks of uBoot image were dumped, and later concatenated, and compared with the saved uBoot image. This is to make sure the uBoot image in NANDby bodhi - uBoot
cheeto4493 Wrote: ------------------------------------------------------- > Had a perfectly good working system. > I shutdown put the FlashDrive in my win7 machine > and ran WinImage to make a backup of the drive. > Put it back in, and now it won't boot. > Light comes up orange as normal, but doesn't > connect to network. > Will boot without the flash driveby bodhi - Debian