AndreaCipcino, Try this new version of the DTB. I've also attached the DTS here for reference. Copy the DTB to the rootfs /boot/dts/. And recreate the uImage with it. Reboot and please post the serial console or dmesg log.by bodhi - Debian
@AndreaCipcino & Mijzelf, > as I recall, rtc1is not present. Only rtc0 is > inside /sys/class/rtc. Yes, that's what I expected to see in dmesg, only rtc0. @Ray, Correct. ==== But dmesg output is needed for confirmation, as always.by bodhi - Debian
achlebek, Connect serial console. Power up, interrupt u-boot count down, and printenv boot And then post the entire serial console log here.by bodhi - Debian
A reminder so I don't forget when we get back to this topic. Looks like the DTS for this device needs some improvement regarding RTC. This box uses rs5c372a chip, which is already configured in the kernel. But we probably need to disable the standard Kirkwood rtc device, so it the rs5c372a device can be exposed properly. i2c@11000 { status = "okay"; rs5c372a: rsby bodhi - Debian
> Sorry, I forgot to respond that I got this working > and not by using kwboot. Cool! what's ever works.by bodhi - Debian
AndreaCipcino, Sure. I'll also take a look at this box RTC driver to see if somehting is missing.by bodhi - Debian
AndreaCipcino, > But as I have checked just now , it has not the > wakealarm file, and rtcwake says that rtc0 is not > enebled for wakeup events too. I don't recall you've posted the boot log. Please do that.by bodhi - Debian
AndreaCipcino, > Now for saving this configuration, it is better to > use saveenv or use fw_setenv ? Use saveenv in serial console. Currently, you cannot use fw_setenv yet. The mtdparts in bootargs and the /etc/fw_env.config must be correct so you can read/write u-boot envs in Debian.by bodhi - uBoot
Try fw_setenv curr_bootfrom 2 fw_setenv next_bootfrom 1 fw_setenv change_boot_part 1by bodhi - Debian
achlebek, It's much better if you connect a serial console and post the serial boot log so I can see what's wrong during u-boot booting. dmesg output is irrelevant at this this time. However, your current envs are curr_bootfrom=1 next_bootfrom=1 change_boot_part=0 And you cannot boot to Debian, so I'm guessing that the last stock kernel was booted from kernel 2. So doby bodhi - Debian
AndreaCipcino, > setenv mainlineLinux yes > USB starts no problem, but STOCK OS hangs up at > "booting the kernel" . > I have foun that the problem is the environment > variable "mainlineLinux yes" if I do not set this > variable then stock OS starts as normal. >Is this > variable necessary for USB rootfs booting and > operation ?by bodhi - uBoot
AndreaCipcino, My notes in the release. QuoteUpdated 01 Nov 2023: Basic Debian bookworm Kirkwood rootfs for most Kirwood plugs: - tarball size: 250MB - install size: 714MB - The init system used in this rootfs is sysvinit . To boot with systemd, see Notes below. - Installed packages: nano, avahi, ntp, busybox-syslogd (log to RAM), htop, isc-dhcp-client, dialog, bzip2, nfs servby bodhi - Debian
AndreaCipcino, > I have managed to run a rootfs of Debian 12 + OMV7 > on this old NAS. Everything works except hard disk > presence LEDs. Which kernel are you running on this ReadyNAS duo V2? If you are running my regularly released kernel here, then yes that's how it behaves. When you access the HDD, it will flash to show activities.by bodhi - Debian
Anderson, > I think it is really best to use rootfs on > the USB. That's what I said. The kernel is already installed in the USB rootfs. You would load the uImage and uInitrd from the rootfs /boot. And you would update it regularly when I release a new one. And you woud update to the latest Debian. So it is secured if you use it facing the internet. > On my 'EX2 Ultrby bodhi - Debian
Anderson, I've been running 4 NAS boxes with USB rootfs (Sandisk brand) for more than 10 years now. A couple years ago, I had to replace one of the internal HDDs, but the USB rootfs are still the same drives.by bodhi - Debian
Bob, > the Pogo 4 devices to Sandisk 32GB cards designed > for dashcams and surveillance cams. I am guessing > they have inbuilt sector write balancing and other > safeguards to prevent premature failure. I'd hope they have sophisticate write balancing. What you can also do is to over provision, i.e. leave about 2 to 4 GB unallocated. Those unallocated sectors will be uby bodhi - Debian
achlebek, Sorry, it has been many years since I see stock boot log, no idea what happended there.by bodhi - Debian
achlebek, > Thank you bodhi. > Is there an SSH way to blindly make it boot > kernel-2? Yes. But it is always riskier when you don't have serial console. Because you cannot see any problem booting up after you've made the change. Let see if your stock OS has these set up. SSH into stock OS and cat /etc/fw_env.config fw_printenv > I never tinkered with seby bodhi - Debian
achlebek, > Hi, there seem to be here some extremely > proficient users so let me ask a question before I > try to Debian my after-warranty Zyxel NAS326: Yes, do install Debian. Stock OS should be used only as a fallback/rescue system when you have problem and need to fix Debian rootfs. > > It reverts to defaults on every reboot/power. I > attach full dmesg but theby bodhi - Debian
Hi Trond, Thanks! so that theory about TCLK is proven not to be. BTW, I looked at the GPL code Quote[ 0.000000] Kernel command line: console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 mtdparts=pxa3xx_nand-0:0x180000@0(u-boot),0x20000@0x180000(u-boot-env),0x600000@0x200000(uImage),0x400000@0x800000(minirootfs),-(ubifs) earlyprintk=serial mtdparts=pxa3xx_nand-0:0x180000@0(u-boot),0x200by bodhi - Debian
Here is the test kernel linux-6.9.6-mvebu-370xp-tld-3.x. This kernel is the same as the released kernel linux-6.9.6-mvebu-370xp-tld-2, but with some more debug loggings during boot. Download at Dropbox linux-6.9.6-mvebu-370xp-tld-3.x-bodhi.tar.bz2 md5sum linux-6.9.6-mvebu-370xp-tld-3.x-bodhi.tar.bz2 d680f87fa4aab42522614fc5943b641e linux-6.9.6-mvebu-370xp-tld-3.x-bodhi.tar.bz2 sby bodhi - Debian
Hi Trond, > On RN102 (warm start): > > Marvell>> md.l 0xd0018230 1 > d0018230: 0012b395 .... > Marvell>> md.l 0xd0018234 1 > d0018234: 00000000 .... > > Ok. So we can see BIT 20 was set to 200 Mhz (001 2b395), same as the Mirabox. I will post a test kernel so we can see in Linux if the SAR register content is the same as in u-boot. The Miby bodhi - Debian
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