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
ploks, Don't power down or reboot. Here is how I recovered from this situation with restamp's help a while back: http://forum.doozan.com/read.php?3,5728,5748#msg-5748by bodhi - uBoot
Is there any of these i.MX6 boards that also has a PCIe slot?by bodhi - Allwinner A10
zampara, I think it's best that this question to be answered by WarheadSse! or you can ask at Arch forum: http://archlinuxarm.org/forum/viewforum.php?f=29 Worse case, you can boot from SATA and bypass NAND altogether. - bodhiby bodhi - uBoot
restamp, The fw_setenv machid dd6 statement is to correct an oversight in the current uBoot (Davy confirmed this). On Pogoplug E02, setting arcNumber to 3542 alone does not make uBoot pass along the archNumber to the kernel. So the work around is to also set machid explicitly using fw_setenv. archNumber 3542 only works if you have a kernel with the Pogoplug E02 patch. If you have a vanillaby bodhi - uBoot