I have pretty much give up on the Pogo---although I still have one in operation as a media server, and 3 still new in boxes. I was never able to repair my flash with JTAG & openocd, so I discarded that one. A Raspberry Pi only costs $20 and it has much more capability than the Pogo. Only thing the Pogo is better at is the USB ports. I did manage to upgrade the U-boot code so it wouldby rayvt - uBoot
The power supply is good, I metered it and also swapped with a good Pogoplug. I think this board just suddenly went bad. Odd coincidence, though. I flashed a new u-boot build that I am working on---and it never came back. Wierd that this board died dead at the exact same time I flashed a new uboot. It's dead, though...even JTAG doesn't work on it, but does work on another Pogoplug.by rayvt - uBoot
See this: https://forum.doozan.com/read.php?3,93799by rayvt - uBoot
GUID Partition Table Header signature is wrong: 0x0 != 0x5452415020494645 When you boot up a Pogoplug which has a USB disk attached that is larger than 2TB you get these error messages: GPT: first_usable_lba incorrect: 22 > 0 part_print_efi: *** ERROR: Invalid GPT *** GUID Partition Table Header signature is wrong: 0x0 != 0x5452415020494645 part_print_efi: *** ERROR: Invalid Backup GPTby rayvt - uBoot
Well, I'm going crazy here. After trying (and failing) to write a good uboot into NAND, I switched the JTAG cable over to another Pogoplue E02 that works. I wanted to find a procedure which would load a Linux system so I could try to use nandwrite to flash the uboot. First step was to use JTAG to load a uboot and execute it. As I mentioned earlier, the current uboot (uboot.2017.07-tld-by rayvt - uBoot
I exactly followed the instructions in the first post. softlinked: uboot.kwb -> uboot.2017.07-tld-1.pogo_e02.mtd0.kwb I switched the JTAG & serial over to another pogoplug E02 that is good. Didn't try flashing, because I'm scared to corrupt this one. So I tried downloading the uboot.kwb and running it, according to the proc pogo_load_uboot in /usr/share/openocd/scripts/by rayvt - uBoot
I cannot get my Pogoplug E02 to reflash the u-Boot binary, or to load u-Boot into RAM and execute it. I am running openocd on a Raspberry PI 3B. This is openocd v 0.10. Can anybody figure what is wrong? I have a feeling that some part opf the setup is not right, because I cannot even load uboot and execute it. Trying to reflash Quoteraspberrypi>openocd -f pogo.cfg Open On-Chip Debuggeby rayvt - uBoot
The download link is bad. Is there a good link?by rayvt - Rescue System
QuoteBut to have the most flexible implementation, the max spin time should be adjustable by user. Linux have quirks table, but u-boot does not. Therefore I'll merge your patch, but keeping the code about factoring usb_ready_retry env into the max spin time. In a multi-drive configuration, this env will be useful. Sounds good. Yeah, the quirks thing...Linux has a lot of flexibility becaby rayvt - uBoot
QuoteFor boxes that boot with a HDD or MMC rootfs, we don't care much about the spin up time of the USB drive. Actually we want to ignore the failure rather quickly. That's the maximum time we will allow the drive to keep saying "Not Ready". As soon as the drive says "Ready" we are good to go. If the drive doesn't respond at all, we don't retry, we failby rayvt - uBoot
> For USB HDDs such as WD brand, 10 seconds might not be enough to spin up. Could be. It was enough for the one WD drive I had. I thought that Linux's 100 seconds might be excessive -- BWDIK? It would be hard to argue that uboot shouldn't also do 100 seconds. It's not like we'd be waiting 100 seconds for a bad or missing drive -- the drive is responding. So changeby rayvt - uBoot
Re: my April 27 post " - This problem is very common. .. Did you try a different flash drive? " Yes, I know. ;-( I tried every USB drive I have, which is a lot. Plus, googling the error message gets a potload of hits, all people complaining about the problem. I found the problem in UBOOT and fixed it. See the thread: http://forum.doozan.com/read.php?3,35295 " EHCI tby rayvt - uBoot
Analysis of the U-Boot bug. And the fix. There were two problems that caused this bug, which is what made it so difficult to reproduce and fix. The first problem laid a land-mine for the next I/O operation -- the innocent bystander -- to step on and blow up (timed out). Most USB disks worked okay. The disks that had trouble generally worked okay on the 2012-era versions of U-boot, bby rayvt - uBoot
For those who are curious about the error message: EHCI timed out on TD - token=0x80008d88 and EHCI timed out on TD - token=0x8d88 TD stands for "Queue Element Transfer Descriptor (qTD)", which is a micro-code instruction for the EHCI USB chip. A TD controls the I/O transfer of up to 20480 bytes of data. One I/O operation consists of one or more TDs. (Ref: Enhanced Host Conby rayvt - uBoot
Many people have run into the problem on a Pogoplug with a USB disk that refuses to boot. If you can see the U-Boot console, either with a serial cable or netconsole, the error message is "EHCI timed out on TD - token=0x{something}" repeated over and over again. A related problem is a drive which randomly fails to be detected by uboot, but without any error message. Frustratingly, oby rayvt - uBoot
The drive enumeration had me tearing my hair out when I upgraded from Jeff's davygravy-2012-02-20.kwb uboot to Bodhi's 2016.05 uboot. (Google search brings up Jeff's instruction page, and the script there says the davygravy is "current". I guess Jeff & Davy have abandoned it, but it sure would be nice if somebody could update that page and the supplied scripts toby rayvt - uBoot
I was updating all my pogoplugs to the latest U-boot and ran into a USB disk problem. I have one drive that this uboot will just not work with, it throws timeout errors (see below). Google shows that a lot of people have this same problem, but nobody seems to have a solution yet. All of the other dozen drives I have work fine. This is the boot drive, but that doesn't matter -- it getsby rayvt - uBoot
I've been fighting with doing cross-compile on my Debain desktop system this all day. Everything goes ok -- and it's a lot faster than building the kernel on the pogoplug -- but it just won't boot. I discovered that mkinitramfs pulls binaries and libraries from the *host* system, even though it (correctly) pulls modules from the cross-compiled target. Beats me how anybody is aby rayvt - Debian