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
@sym0, > registered as rtc0 > [ 92.625677][ T176] rtc-ds1307 0-0072: hctosys: > unable to read the hardware clock > [ 92.633382][ T176] i2c i2c-0: new_device: > Instantiated device ds1307 at 0x72 OK that's good to know. Now try: Boot with serial console connected. Interrupt count down and set the date date # or help date date <current time>by bodhi - Debian
What's the content of: cat /sys/firmware/devicetree/base/ocp@f1000000/i2c@11000/rtc@64/compatible cat /sys/firmware/devicetree/base/ocp@f1000000/i2c@11000/rtc@64/nameby bodhi - Debian
The kernel does not have driver for IDT 1337G chip (quite common for older chips that nobody has tried to mainline). Hopefully we can use the Dallas/Maxim ds1307 driver, which was known to work for some other chips other than Dallas/Maxim's. Attached is the updated dtb/dts.by bodhi - Debian
Koinin, > However, as expected, if the system fails to > boot (e.g. issues in initramfs or mounting root), > I do not get any kernel logs via netconsole — > since the module hasn’t been loaded yet. > I want to receive early kernel logs over > netconsole — as early as possible — ideally > starting right after U-Boot, even before the > rootfs is mounted.by bodhi - Debian
> I think that first we need to try to understand > the mechanism of interaction with RTC on 3.2.40. It is well defined in the modern kernel, we just need to do the right thing in the DTS. Since this box uses the external RTC we need to disable the internal RTC in the SoC.. Attached is the updated dtb/dts.by bodhi - Debian
sym0, Perhaps you should install and run my kernel linux-6.14.6-kirkwood-tld-1. See if there is any difference.by bodhi - Debian
> On 6.14.8 it doesn't find the I2C adapter... > > I also tried to compile kernel 3.2.40 with the > "modular" driver mv64xxx_i2c (it does not load > automatically). Don't need to do that. The kernel should already have i2c. We just need to enable it. > The boot log had typical errors, but RTC worked > fine (I checked it via /usr/sbin/rtc). Soby bodhi - Debian
> Now that I see > root=LABEL=rootfs works > reliably, I’ll stick with it. Cool!by bodhi - Debian
Koinin, > I'm using a GoFlex Home with U-Boot 2017.07 > installed following your instructions, and I've > successfully booted into Debian from a USB drive. Cool! > Other times the USB becomes > /dev/sdb1 → boot fails > because the kernel can't find the rootfs > > I have already tried using > UUID in > bootargs, but it did not >by bodhi - Debian
bodhi Wrote: ------------------------------------------------------- > This is suspect, might be wrong. > > > mww 0xD0010418 0x003E07CF ;# NAND Read Parameters > REgister > mww 0xD001041C 0x000F0F0F ;# NAND Write Parameters > Register > mww 0xD0010470 0x01C7D943 ;# NAND Flash Control > Register > I've verified they are correct.by bodhi - uBoot
This is suspect, might be wrong. mww 0xD0010418 0x003E07CF ;# NAND Read Parameters REgister mww 0xD001041C 0x000F0F0F ;# NAND Write Parameters Register mww 0xD0010470 0x01C7D943 ;# NAND Flash Control Registerby bodhi - uBoot
Some thoughts. The fan might be on the i2c (if not an GPIO fan), as well as the RTC chip. I don't think the IDT 1337G driver is supported in the kernel. It is on i2c bus.by bodhi - Debian
Quote> I found out that the board uses IDT 1337G (photo). > However, in the iomem output for 6.14.8 I do not > see any mentions of rtc-mv and mv64xxx_i2c > (perhaps they are called differently?). Interesting. Let me take a look at the DTS (please do the same). The RTC must be specified in the i2c node in the DTS. Yes, we are missing this RTC.by bodhi - Debian