Hi Trond, The correct addresses to dump SAR. On Mirabox Marvell>> md.l 0xd0018230 1 d0018230: 0012b397 .... Marvell>> md.l 0xd0018234 1 d0018234: 00000000 .... At 0xd0018230, Bit 20 == 1 indicates 200Mhz.by bodhi - Debian
Hi Trond, Thanks for the test! Unfortunately, I forgot to add the register base to the SAR offset :)) So I need to come back with a correct address. It should be either 0xd0000000 or 0xf1000000. In this old u-boot I think it is 0xd0000000. BTW, bit 20 is the TCLK indicator.by bodhi - Debian
bodhi Wrote: > > Currently, I cannot manage the leds event in > the > > dts/dtb file correctly listed in the > > /sys/class/leds folder. > > Boot back to sysvinit and check the > /sys/class/leds again to see if they are > populated. Nevermind. I've found that the current kernel 6.9.6 does not have the LED control for this box. While other Kirwooby bodhi - Debian
mdg69, > I was not albe to connect serial console to run > the test you asked. That will make it harder for me to help. > This version allow to manual control the fan but > it seems to me the kernel miss the coretemp module > to check the cpu temp. I would like to create a > script that control the fan rpm in conjunction > with the cpu and HDD temp (drivetemp mby bodhi - Debian
mdg69, > I am triyng to get control of the leds on a lacie > 2big NAS with no luck. > My /sys/class/leds folder is always empty. > Any suggestion? That's because you are using the GF Home DTB. The LED definitions are different. > > Do you know if the Kernel has gpio-leds support or > there is a specific module to be loaded with > modprobe? > Thby bodhi - Debian
> After following your instructions, I was able to > make U-Boot load `uImage` and `uInitrd` from the > HDD, on the `/dev/sda1/` partition formatted in > ext3 (ext4 doesn't work). > > But I remembered the reason for not being able to > use HDDs larger than 2TB: they are in 'GPT' and > not 'MBR'... > > Thus, U-Boot does not read disby bodhi - Debian
> Yes, I am seeing the whole bootlog on a simple > connection without using kwboot. At least that's a > step in the right direction. > > > As for kwboot, the behavior is like the u-boot > > image was not a good one. Perhaps you should go > > ahead and boot into Debian, and then dump stock > > mtd0, and use it for kwboot. > > I'll seeby bodhi - Debian
dhargens, > xmodem: Connection timed out > > > You'll note that at the end the connection dropped > for some reason - which also won't work. I tried > both kwboots (rc3 & static) and neither worked for > me. I think that's normal. The connection timeout indicates that kwboot is still trying to handshake. If you run picocom/minicom then youby bodhi - Debian
Anderson, > Marvell>> scsi reset > > > > Reset SCSI > > AHCI init for unit0 > > Tarby bodhi - Debian
I forget if this box u-boot can see the HDDs. With at least one HDD in the slots. Power up, interrupt u-boot countdown and, help scsi resetby bodhi - Debian
Hi all, Please cold start (after shutdown for about 30 minutes) your RN102 or RN104. Interrupt u-boot at count down and dump SAR register md.l 0x18230 1 md.l 0x18234 1by bodhi - Debian
Thanks Trond!by bodhi - Debian
dhargens, > RJ-45 Console port. Here's the pins I'm using: > 3 - TXD > 4+5 - GND > 6 - RXD It looks right to me. > [*] I'm using minicom for my serial connection > program, set at 115200 8N1 Also OK. > [*] I've swapped Rx & Tx - one way it's silent, > the other way it's gibberish. > With this wiring setup I applyby bodhi - Debian
dhargens, This box uses RJ45 connector. It's a standdard Cisco one. See previous post. https://forum.doozan.com/read.php?2,134340,134421#msg-134421by bodhi - Debian
> I changed sda1 to sdb1, because rootfs usb is > sdb1 That's expected. The rootfs USB drive could be assigned any driver letter, depending on how many SATA drives and USB drives are attched. To make it resilient, the bootargs should be: setenv set_bootargs_debian 'setenv bootargs console=ttyS0,115200 root=LABEL=rootfs $(mtdparts) earlyprintk=serial init=/bin/system'by bodhi - Debian
Anderson, Power up, interrupt u-boot at count down and, setenv usbActive 0 setenv set_bootargs_debian 'setenv bootargs console=ttyS0,115200 root=/dev/sda1 $(mtdparts) earlyprintk=serial init=/bin/systemd' setenv bootcmd 'run set_bootargs_debian; run boot_debian_usb1; run boot_debian_usb2; run boot_debian_usb3; run boot_debian_usb4; reset' And then bootby bodhi - Debian
Anderson, > Now, I want to move the uImage and uInitrd to the > NAND. OK. > I successfully transferred the uImage, which is > 5MB, to the flash. > However, the uInitrd doesn't fit in the standard > partition because it's also 5MB and the file > doesn't fit (I tried to reduce it with this > tutorial > (https://forum.doozan.com/read.php?2,13by bodhi - Debian
Hi Ray, Did you find u-boot source any where in the website https://kb.netgear.com/2649/NETGEAR-Open-Source-Code-for-Programmers-GPL?by bodhi - Debian
anderson, > its possible resize MTD to fit > linux-6.4.11-mvebu-tld-1-bodhi com uInitrd with > 13mb? You did not post the entire boot log. So are you able to boot to USB rootfs or SATA rootfs with the current envs? Now it seems you want to put the kernel uImage and uInitrd on NAND mtd? The short answer is yes, given you can already boot the kernel from USB drive, it is possby bodhi - Debian
Hi Ray, > The earliest source code download for the > RN102/RN104/2120 6.2.5 seems to be based on > buildroot 2014.08 and uses a recipe for building > u-boot using a tar file for U-Boot-2014.07. The > latest source code 6.10.9 (6.10.10 link actually > downloads 6.10.9) uses buildroot 2015.11 and a > recipe for building u-boot using a tar file for > U-Boot-2015.1by bodhi - Debian
> > These parameters all seem to be uninitialized, > so > > probably they are ignored. Still, should I try > to > > set them? > > No, we should not. Because we don't know this > u-boot, and a messed up SAR register could be a > lot worse than wiping out u-boot on flash (the > system could be stuck on some limbo state). Note that the SAR regby bodhi - Debian
Hi Trond, > These parameters all seem to be uninitialized, so > probably they are ignored. Still, should I try to > set them? No, we should not. Because we don't know this u-boot, and a messed up SAR register could be a lot worse than wiping out u-boot on flash (the system could be stuck on some limbo state).by bodhi - Debian
Hi Trond, > > My hunch right now is that the Core Clock for the > RN102/104 was set to the wrong value in u-boot. The core clock (TCLK) for Armada 370 can be run at either 166 Mhz or 200 Mhz. I'm wondering if the clock tick is really run at 200 Mhz as printed out during the RN102 booting. The correct way to get the TCLK is to read it from the SAR register. And the modern Lby bodhi - Debian
Thanks Trond! But too bad, it did not have info we are looking for.by bodhi - Debian
Hi all, Could you reboot your RN102/104 with serial console. Interrupt the count down, and help If there is a command such as SAR, or SatR, or simlilar, execute it. See if it print out any info. Basically, this Sample at Reset register stores the board settings that have been set by the manufacturer. It could contain the boot device selection, CPU frequency, clock rate, ... among otherby bodhi - Debian
Hi Trond, My hunch right now is that the Core Clock for the RN102/104 was set to the wrong value in u-boot.by bodhi - Debian
Hi Trond, > The observed lagging is 31 times larger than the > difference in reported frequency, so there must be > more to it than just the clock frequency. Agree. The frequency difference is possibly just an artifact of hardware difference. Wish we have GPL source for the RN102 u-boot so we can see what it does during boot.by bodhi - Debian
And, another interesting observation. > Strangely, RN102 reports the wrong wrap time after > only 1 us. The full log is attached. Schedule clock disabled all interrupts before it calculates that wrap sched_clock_register(u64 (*read)(void), int bits, unsigned long rate) { u64 res, wrap, new_mask, new_epoch, cyc, ns; u32 new_mult, new_shift; unsigned long r, flags; char rby bodhi - Debian
Hi Trond, I've added this new debug info. The clocksource frequency is showing the difference clearly Yours and Jungle's dmesg [ 0.007897] clocksource: armada_370_xp_clocksource: scale: 1 ns, freq: 18,749,237 My Mirabox dmesg [ 0.008608] clocksource: armada_370_xp_clocksource: scale: 1 ns, freq: 18,699,646by bodhi - Debian
ahlaklisuvari, Could you get some information for this box. Power up, interrupt serial console countdown, and bdinfo md.l f1018000 8 md.l f1018100 1 md.l f1018140 1 help printenv and then boot boot Let it boot all the way to the Debian login prompt. And post the entire serial console log here (from the u-boot banner until the login prompt).by bodhi - uBoot