BayPanard, Attached is the new PCIe bug work around/debug build. Please try again the same test. uboot.2024.10-tld-1.ds112.bodhi.250619.tar md5: a2b07d5f4b0d58210b822e24574468a3 sha256: 66e05c7edf4b310e61c8844edb1cb36eb2f4fabe0f6c485cfba398542fc116e1 This tarball includes 5 files. uboot.2024.10-tld-1.ds112.kwb uboot.2024.10-tld-1.ds112.environment.img uboot.2024.10-tld-1.ds112.by bodhi - Debian
BayPanard, Damn, fix one bug and another one shows up :) Thanks for testing!by bodhi - Debian
BayPanard, Attached is the new PCIe bug fix and debug build. Please try again the same test. I have high hope for this build. uboot.2024.10-tld-1.ds112.bodhi.250617.tar md5: 9c3bbbba90519277bf50abbc80372d6f sha256: d51aabe2620b36cb80590d61c1cb1b2084b6ea19cae6ee6fe621fe9eef88eb1b This tarball includes 5 files. uboot.2024.10-tld-1.ds112.kwb uboot.2024.10-tld-1.ds112.environment.imby bodhi - Debian
BayPanard, Thanks! very informative. It fails right away. And looks like we need a work around for this u-boot bug. I will upload another version.by bodhi - Debian
Up in the Wiki. Thanks! QuoteHome Automation & Tools X10 CALDav Calendar Server using Radicale Pogoplug Network Stack with PiHole: pics, and description Pi-hole on Pogoplug Mobile Pi-hole on Pogoplug Pro V3 (OXNAS) Pi-hole 5.0 ad-blocker on Seagate Dockstar Pi-hole 6.x ad-blocker on Seagate Dockstar/Debian 12.xby bodhi - Debian
BayPanard, Attached is the new PCIe debug build. uboot.2024.10-tld-1.ds112.bodhi.250616.tar md5: ccc884672cafb769f42bed15b75fd605 sha256: 36a67888b352a9a3f4d608d27457c24c4f9046bbc22ab04b81188b5485fb211c This tarball includes 5 files. uboot.2024.10-tld-1.ds112.kwb uboot.2024.10-tld-1.ds112.environment.img uboot.2024.10-tld-1.ds112.environment uboot.2024.10-tld-1.ds112.boot.cmdby bodhi - Debian
BayPanard, > uboot.2024.10-tld-1.ds112.kwb: Invalid image. Let me take a look. May be a bad build.by bodhi - Debian
rayknight Wrote: ------------------------------------------------------- > shermbug Wrote: > ------------------------------------------------------- > > If/when I come across some additional Pogo v4 / > > Mobile hardware, I will :-). > > If you're located in the US I can send you via US > Mail a > Smartenit > Harmony P2 which is essentially a relabby bodhi - uBoot
shermbug, > On the plus side, this has been a really good > learning experience to get JTAG up and running on > the Pi and generally having the ability to use > that interface to talk to a device. This may serve > me well in the future, and I also can advise users > about this forum if they run into similar issues > with uboot and the like. > Indeed. Next tby bodhi - uBoot
> But the serial console remains quiet. I think the serial port was fried (damaged) and u-boot could not start because of that.by bodhi - uBoot
If it were in u-boot command prompt, we would run go. Not sure what resume does here. go 0x800200by bodhi - uBoot
> load_image uboot.kwb 524288 bytes written at address 0x00000000 downloaded 524288 bytes in 56.624947s (9.042 KiB/s) > verify_image uboot.kwb verified 524288 bytes in 2.988857s (171.303 KiB/s) > > resume 0x800200 That's fishy. The load address should be 0x800000. resume 0x800200 meaning jump to 0x800200 and execute (where u-boot image was loaded with offset 0x200by bodhi - uBoot
In running from RAM test, did you run pogo_load_uboot right after pogo_init? do you have a log of this attempt? > Could we have an incorrect register setting that > is preventing the serial line from operating as > expected? That's not likely. The BootROM configured the serial port when the box is powered up (that's why we don't do anything regby bodhi - uBoot
Hi Rob, Welcome back! > I'll run it for a few days to make sure it all > works ok, and then write a follow-up post with > full instructions. That would be great!by bodhi - Debian
> Please correct me if I'm wrong here... I assume > that I just need to run > > pogo_load_uboot > > > and then it should start executing and will have > activity serial UART/console, right? Yes. > Keep in mind > also that I don't have the uboot environment in > NAND anymore as I'm pretty sure I had wiped that > at some point (tryby bodhi - uBoot
> At this point, I'm wondering if it's dead hardware > -- presumably something actually wrong with the > NAND. Could be. You could try to load the u-boot image to memory and execute it (instead of flashing). If it runs, it'll be easier to see if NAND flash is really bad.by bodhi - uBoot
Wiki thread QuoteMemory & Swap Settings Tuning for low RAM boxes - System and HDD performance. Also read several posts after for setups for logging to RAM. Try 65536 and increase the number gradually until 131072, it will make big difference. vm.min_free_kbytes = 65536 But this number must be tuned to a specific box with the amount of available RAM in mind.by bodhi - Debian
Jan, > Hi, was this ever resolved? > I tried rtcwake myself before on NSA325v2 with > 6.14.6-kirkwood-tld-1 before finding this thread > but without luck. Same write errors and system > cannot hibernate nor suspend as the ethernet seems > to refuse to suspend. I've not tried to resolve this, other than looking in the code to verify that the capability is still thby bodhi - Debian
Also see davidalfa working thread.. David wrote a really good thread about Dockstar mods and JTAG https://forum.doozan.com/read.php?2,127079,127629#msg-127629by bodhi - uBoot
How about. Instead of nand write 0 uboot.kwb 0 oob_softecc_kw Do nand write 0 uboot.kwb 0 We don't really care to write oob or ecc. The u-boot image has no oob or ecc info on it. It does not seem relevant to the time out, but try it anyway.by bodhi - uBoot
shermbug, > This is what the E02 file contains (3 lines all > labeled as "Dunit Control High Register"): > [code[ > mww 0xD0001424 0x0000F17F ;# Dunit Control High > Register > mww 0xD0001428 0x00085520 ;# Dunit Control High > Register > mww 0xD000147c 0x00008552 ;# Dunit Control High > Register > [/code[ These last 2 comments in Pogo E02by bodhi - uBoot
> For the section below, there is only one register > in the file that describes the v04 hardware. Do > the other two registers (0xD0001428 and > 0xD000147c) remain as they were? > > mww 0xffd01424 0x0000F07F ;# Updated (DDR DDR > Controller Control High) Dunit Control High > Register > # mww 0xD0001428 0x00085520 ;# Dunit Control High > Register > #by bodhi - uBoot
> I could not agree more! It is ludicrous that I am > spending this much energy on an old and largely > obsolete device. Especially because I got the unit > for free from someone at work who was > decluttering. You are the first person who attempt to JTAG the Pogo V4, afaik. > > After I bricked it, I was willing to spend a very > small amount of money (<&lby bodhi - uBoot
shermbug Wrote: > That said, there are a few values that don't seem > to map easily (or my low level hardware knowledge > is rusty): > > For the section below, there is only one register > in the file that describes the v04 hardware. Do > the other two registers (0xD0001428 and > 0xD000147c) remain as they were? > > mww 0xffd01424 0x0000F07F ;#by bodhi - uBoot
Hi shermbug, > I'm working on the assumption that the registers > in the file that @bodhi provided are really deltas > from the e02 device. With that in mind, there were > a lot of registers that I didn't update and a few > that I commented out because they seemed redundant > or inconsistent. I also added a few. All of these > should be apparent in the fiby bodhi - uBoot
BayPanard, This one is harder than I thought! please try again the same test. Attached is the new PCIe debug build. uboot.2024.10-tld-1.ds112.bodhi.250609.tar md5: ede6abcf4a3ab0e4e30da4858a3ebfdd sha256: af328c55f651f028ce421714e00636936a15074b8d4e4d9b3c5842ec88949ebc This tarball includes 5 files. uboot.2024.10-tld-1.ds112.kwb uboot.2024.10-tld-1.ds112.environment.img ubooby bodhi - Debian
BayPanard, Thanks! I can see the bug clearly now, will think about how to fix it.by bodhi - Debian
Attached is the updated DTB/DTS. Added uart1 node in the DTS.by bodhi - Debian
sym0, > > This activated ttyS1 port should be in the DTS, > > not DTSI, though. Because it might not be > > applicable to other WD NAS with Kirkwood Socs. > > If you help me to form dts\dtsi correctly, I will > check them in work. OK. > As far as I understand, debugging via strace, > rtc is actually a "shell" for some up_send_ctl >by bodhi - Debian
> It didn't help, but in the end I managed to get > the RTC working :) Nice work! > First, I managed to understand how RTC\FAN\LCD are > controlled in the stock firmware. This is done > using utilities: > > xmldb > up_read_daemon > up_send_daemon > up_send_ctl That's a work around. Great that it works, but not a real solution. But similarby bodhi - Debian