spiderdijon, I did some digging and reading, and I don't think I can do any thing more regarding the 1st PCIe SATA controller. This driver is way too complicated, and I'm not familiar with PCI. I think we can call it a success in bringing up this box (with the PCI caveat). And we should write an installation post for RN2120, woud you like to do that? In this thread, I wrote indiviby bodhi - Debian
Random MAC issue mentioned in the release thread QuoteUpdated 16 Dec 2023: Rootfs Debian-6.6.2-mvebu-tld-1-rootfs-bodhi.tar.bz2 has been uploaded. Basic Debian bookworm armhf rootfs for most MVEBU Armada NAS: .... Note 6. Persistent MAC address (Optional): To enable the network dynamic IP to stay consistent after each reboot, and also for faster boot. In this rootfs, a scripby bodhi - Debian
ahuovinen, > U-Boot 2024.04-rc4 (Mar 13 2024 - 15:56:28 +0200) > NS v2 You should have flashed a known working u-boot first: the stock u-boot.by bodhi - uBoot
SuperPoney, > Continuing my setup, I was able to bring network. > For an unknown reason in my box the network card > under "initramfs-6.6.2-mvebu-tld-1" (Debain 12) is > named "end1" and not "end0" : That was because your u-boot envs set it up to use egiga1. Net: , egiga1 Power On! FDT loaded successfully Hit any key to stop autoboot:by bodhi - Debian
> I didn't post anything regarding the mvneta > problem earlier as I thought this was somehow only > affecting my installation :) Ah, OK :) If the next stable kernel 6.8.x does not pick this up, I will.by bodhi - Debian
Quotebodhi Of course there is also a chance that the envs location was moved by the modified u-boot. Quotea location is different for the envs.. that you mentioned was all empty. its much before. It can also be that the modified u-boot doesn't store the envs on flash at all. They instead specified them internally in the code. Use hexedit to load the mtd0 dump and search for "stby bodhi - Debian
> do i need a reboot between the editing and > fw_printenv? No need to. Check dmesg dmesg | grep -i2 spi [ 7.139740] spi-nor spi0.0: mx25l4005a (512 Kbytes) [ 7.145448] 1 cmdlinepart partitions found on MTD device spi0.0 [ 7.152119] Creating 1 MTD partitions on "spi0.0": [ 7.157662] 0x000000000000-0x000000080000 : "uboot" Check mtd cat /by bodhi - Debian
After dumping u-boot as described above, use hexedit to find the localtion in the image file mtd0.ns2, see if it is really 0x70000.by bodhi - Debian
> root@debian:/home/warri# cat /etc/fw_env.config > # MTD device name Device offset Env. size > Flash sector size Number of sectors > #/dev/mtd0 0xc0000 0x20000 0x20000 > /dev/mtd0 0x70000 0x1000 0x1000 I missed one zero, 6KB = 0x10000 cat /etc/fw_env.config /dev/mtd0 0x70000 0x10000 0x1000 But this u-boot seems to use only 4K envs Environmentby bodhi - Debian
After you see mtd0 detected and listed in Linux. Modify /etc/fw_env.config # MTD device name Device offset Env. size Flash sector size Number of sectors /dev/mtd0 0x70000 0x1000 0x1000 And then list the envs fw_printenvby bodhi - Debian
> Darn, maybe i have to desolder the flash chips to > program them ;) might be easier with a jtag. There > might be a way to do this with arduino > or raspberry pi IIRC . though dont have a pi and > all my arduinos are 5v 16mhz. No need to do that drastic step yet. The next step is to get the mtds definition correct and so Linux can see the MTD partitions (u-boot and envby bodhi - Debian
> If i compile mainline u-boot for networkspace 2, > how to test if it works without serial or > flashing? I don't think there is any other way to test. The only remaining way to test without flashing is to chain load u-boot image from u-boot prompt. However, the mainline u-boot has a very different architecture from the old stock u-boot. So chainload will not work in that dby bodhi - Debian
> Yes, was just experimenting. Too bad i cannot set > bootargs as i would like to in environment > variables because they are hard coded on the > u-boot differently. You already did set bootargs correctly. That's why you can boot and the kernel can mount the root device using the partition label. warri@debian:~$ cat /proc/cmdline console=ttyS0,115200 root=LABEL=rootfs rby bodhi - Debian
Root device root=/dev/sda1 should be used temporarily way to test boot. Use root=LABEL=rootfs so that it will boot successfully when you boot with multiple drives (SATA, USB,....) attached to the box (only one partition among them should be a rootfs)by bodhi - Debian
ahuovinen, > Yes but if you look my printenv output: > > rootfs=/dev/sdb7 . > > have to type > > setenv rootfs <enter> > > to remove it. after that booting from usb works. Ah I see. Cool! > really have to get u-boot flashed to standard > version so i can install > Linux of hdd. You can flash it in netconsole or in Debian too.by bodhi - Debian
Hi jaykumar, > @bodhi, can you please add this patch the kernel > releases > > https://lore.kernel.org/netdev/ZU9OEwz7GoHbBE1m@lore-desk/T/ > > I was troubleshooting constant kernel stack trace > and found this patch fixed the issue for me. Sure it was accepted in the kernel so I will pick it up. But can you point me to the post here where you have this mvneta pby bodhi - Debian
spiderdijon , I'm reading and thinking about this problem. Will let you know.by bodhi - Debian
> > warri@debian:~$ cat /proc/cmdline > console=ttyS0,115200 root=LABEL=rootfs > rootdelay=10 earlyprintk=serial > > Yes. That's why it works.by bodhi - Debian
Quoterootfs=/dev/sdb7 setting that to nothing it then works. Check your bootargs in Debian cat /proc/cmdline ====== OK so it does look like the problem is with serial console. Just in case, at netconsole prompt, see if serial and net console are listed: coninfoby bodhi - Debian
> Tried also with other serial cable, pl2303hxa > based chip and the output is garbage again. > The serial output was set to net console https://forum.doozan.com/read.php?2,137024,137082#msg-137082 But I don't know this u-boot so I cannot be sure why it was not set to serial at the begining. Normally, u-boot sets stdin/stdout/stderr to serial initially, and then when itby bodhi - Debian
spiderdijon, > The auto booting debian from USB works well which > is great, Cool! > but the sata controller issue persists. > The unit only has 4 drive bays. It also has two > e-sata ports on the rear which connect directly to > the SoC (not via PCI-E). Yes, together that's 6 slots. 4 by PCIe. > However as you say to dts/dtb looks fine and I > caby bodhi - Debian
tillewolle, > https://wiki.debian.org/InstallingDebianOn/Synology > problem is: The tutorials are written for Marvell > Armada 385 CPUs. My RS814+ uses an Intel Atom > D2700. > Correct, that tutorial can not be used for this RS814+. We don't have tutorial for Intel boxes. There is one working thread that might be of interest to you: https://forum.doozan.com/reaby bodhi - Debian
> got it working. the problem was that current u > boot had rootfs in envs. so setenv rootfs blanks > it and now it boots from stick. That meant the rootfs label was not stored correctly. Now if you force reset it e2label /dev/sdb1 rootfs And put the root=LABEL=rootfs back in the bootags, it will be mounted correctly.by bodhi - Debian
Looks like this u-boot actually causes a real problem with serial console input/output, and would stop a modern kernel from booting. stderr=serial stdin=nc stdout=nc Since you cannot run kwboot, I think there is some small risk in a solution that I have in mind. If it were a pure stock u-boot, then there is no risk.by bodhi - Debian
QuoteI have quickly googled the r8168 linux drivers, and see that there were some posts regarding if r8168 is fine with the r8169 drivers, and the results were mixed. Is this really an "unlucky" chip, with bad drivers/support? It seems so! the Linux driver works fine. But there is something missing in u-boot (could also be I'm missing some thing).by bodhi - Debian
SuperPoney, > I've trying to boot from stock to > Debian-6.6.2-mvebu-tld-1-rootfs-bodhi.tar.bz2. > Here are the steps I've made : > > mkfs -t ext3 -L rootfs /dev/sda > mount /dev/sda1 /media/eric/sda > cd /media/eric/sda/ > tar -xjf > /home/eric/Desktop/Debian-6.6.2-mvebu-tld-1-rootfs-bodhi.tar.bz2 > cd /media/eric/sda/boot > cp -a uImage uby bodhi - Debian
Also there is something in the envs that's worth trying a test for serial console. I will be back and post that tetst.by bodhi - Debian
ff00003c: 00000000 00000000 00000000 00000000 ................ So it is inconclusive. Hopefully kwboot will work when your serial console works. QuoteSo i can get to u boot through netconsole using fvdw-sl console.. not through serial which shows lots of non ascii characters... Yes. And the envs looks OK for the new set of setenvs to boot Debian. So the problem must be with the rootfs cby bodhi - Debian
Since this box is very old, check the bootROM version at u-boot console md ff00003c If it is older than 1.21, kwboot won't work.by bodhi - Debian
> so no difference. still loads of unreadable > stuff.. the differnce is that when that fvdw > firmware boots it shows up the boot messages May be that u-boot messed up the normal serial console. But not likely, can you interrupt serial console when it boots? If yes, ver help printenv > when i try to boot from the stick.. nothing.. See what I asked above. > meby bodhi - Debian