Hi, with a lot of help from bodhi I managed to get my own debian onto my Synologx DS214 NAS. For those of you who want to repoduce this I created a small summary below. Note that I assume here that you know your way around linux. This is not intended to be a full beginners guide. === State === Currently the following periphery is working and tested on my NAS: - two SATA ports - front anby lonestar - Debian
Hi bodhi, I changed the message title. I will create an installation guide somewhen in next few days. regards, Martinby lonestar - Debian
Hi bodhi, I checked the led bahvior: For debian: - hdd leds are yellow on u-boot (regardless of whether a disk is in there) - hdd leds turn off when kernel starts to load and never turn on again - status led remain off all the time For stock: - hdd leds are yellow on u-boot (regardless of whether a disk is in there) - hdd leds turn off when kernel starts - hdd leds are still off whenby lonestar - Debian
Hi bodhi, front usb works using the first patch. (I tested with my self-built kernel and initrd which is actually just your kernel config + enabling the bcache driver) Cheers, Martinby lonestar - Debian
Ah I missed the question in the last post :) The front usb is the usb2 port. This doesn't work in linux The back usbs are usb3 (connected to the pcie controller). These work. Thanks, Martinby lonestar - Debian
Hi bodhi, I have for now recompiled the stock u-boot to change the default boot command to boot from the front usb (the only one that works on stock). So I have a working NAS where I can do some experiments. For me the hardware support is sufficient for now. Regarding your list: - RTC works - LEDs do not show up in /sys/class/led (not needed for me at the moment) - hw monitoring: I didnby lonestar - Debian
Hi bodhi, very good news and I want to apologize for the additional work that I caused. Both SATA work when using stock u-boot with your kernel and the new device tree. Replug is a little strange as the device nodes in /dev don't get reliably updated, but replugging is not a requirement for me at least. I tried to read and write from a file from one of the disks and it worked fine.by lonestar - Debian
Hi bodhi, I did some experiments today and I am now able to compile and boot stock u-boot. This means we can add traces wherever we like :) As a first test I enabled the tracing in mvLog.h and partially enabled the REG_DEBUG tracing. REG_DEBUG can't be fully enabled as u-boot won't boot any more afterwards. A comment mentions this only work with Lauterbach and I guess it is caby lonestar - Debian
Hi bodhi, i did the tests again with the original 6.0.7 kernel. Behavior is the same as previously in post from "December 04, 2022 01:06PM" Attached the two logs. I used only one disk in either SATA 1 or SATA2. thanks, Martinby lonestar - Debian
Hi bodhi, ok I will do the tests with the original kernel. Might take a few days as I will be rather busy this week. thanks, Martinby lonestar - Debian
Hi bodhi, my box supports hotplug of sata devices. I tested with the 7200 drive: In SATA1: - drive starts without spinning - ide reset in u-boot does not spin up - in linux drive spins up but is not detected - after unplugging, waiting, plugging the drive does not spin In SATA2: - drive starts without spinning - ide reset in u-boot spins up drive - in linux the drive is not detecby lonestar - Debian
Hi bodhi, sorry, I apparently misunderstood you at that time. I redid the last tests: First of all: when using stock u-boot with self-built kernel+initrd ethernet WORKS!!! With your latest patch, which added the regulators both drives are spinning (I did a ide reset in u-boot and at that time the SATA2 drive started) Unfortunately there are still no disks detected in debian. Thinkingby lonestar - Debian
Hi bodhi, I have so far failed to boot debian from stock u-boot. Will have to try more tomorrow. In stock u-boot: Press Ctrl+C to abort autoboot in 3 second Marvell>> md.l f1018000 8 f1018000: 00000000 00000000 00000000 00000000 ................ f1018010: 11110000 00004000 00000000 00000000 .....@.......... Marvell>> md.l f1018100 1 f1018100: 00000000 .... Marvby lonestar - Debian
Hi bodhi, a maybe important difference is that the disk that does not spin up at all in the self-built u-boot is a 7200 rpm disk. The other one is a 5400 rpm disk. I tested with stock u-boot: ide reset found the 7200 disk in sata 2. but not the 5400 drive in sata 1. Then I exchanged the two disks: it found the 5400 disk in sata 2 but not the 7200 in sata 1. This was reproducible.by lonestar - Debian
Hi bodhi, a very morising idea, yet no improvement so far. see attached dmesg.txt. Added a dump of sys/class/regulators, to confirm that the setting arrived at the kernel. Test was done with - 2 disks (see dmesg), - one disk that failed to spin up on any of the two sata ports alone in both of the ports. results: exactly the same behavior as before. thanks, Martinby lonestar - Debian
Hi bodhi, they are both 3.5" HDDs regards, Martinby lonestar - Debian
Hi bodhi, I did some further tests now with two different disks: Disk1: - spins up on sata 1 when link down is shown, but link never goes up - spins up on sata 2 before u-boot loads and never stops Disk2: - doesn't spin up on any of the two sata ports. Note that both disks work in stock image. This looks to me that this is not just a device tree issue, but maybe some timeoutby lonestar - Debian
Hi bodhi, SATA 1 regulator works correctly. For SATA 2 even when all are configured the disk does not spin up (previously I only tested with one disk). I will have to do further tests, but it likely won't happen before the weekend. thanks, Martinby lonestar - Debian
the corresponding output from stock: lonestar@ds214:/$ cat /proc/interrupts CPU0 CPU1 5: 4666 4188 axp_irq axp_local_clockevent 8: 26 0 axp_irq mv_eth 31: 92 0 axp_irq mv64xxx_i2c 41: 1188 0 axp_irq serial 42: 1 0 axp_irq serial 45: 0 0 axp_iby lonestar - Debian
i did a cat /proc/interrupts as suggested by a friend: root@debian:~# cat /proc/interrupts CPU0 CPU1 24: 5120 10230 MPIC 5 Level armada_370_xp_per_cpu_tick 25: 0 0 MPIC 3 Level arm-pmu 33: 2 0 MPIC 51 Level f1060900.xor 34: 2 0 MPIC 94 Level f10f0900.by lonestar - Debian
Hi bodhi, Interesting fact: the drive is correctly powered up after ata2 link down message. This is the same behavior as on stock image. So at least this part seems to be ok. Unplugging network during dhcp request leads to the following messages: Quote Listening on LPF/eth0/00:50:43:02:02:00 Sending on LPF/eth0/00:50:43:02:02:00 Sending on Socket/fallback DHCPDISCOVER on eth0 to 255by lonestar - Debian
I think we are on the right track with the sata controller: stock firmware: Quote [ 150.114185] sata_mv sata_mv.0: version 1.28 [ 150.114250] sata_mv sata_mv.0: cannot get clkdev [ 150.118980] sata_mv sata_mv.0: slots 32 ports 2 [ 150.124957] scsi0 : sata_mv [ 150.128240] scsi1 : sata_mv [ 150.131399] ata1: SATA max UDMA/133 irq 55 [ 150.135512] ata2: SATA max UDMA/133 irq 55 [by lonestar - Debian
Hi bodhi, doesn't work yet: on u-boot sata init blocks forever. On linux the following lines are in the dmesg output: Quote [ 3.286187][ T1] scsi host0: sata_mv [ 3.291223][ T1] scsi host1: sata_mv [ 3.295841][ T1] ata1: SATA max UDMA/133 irq 37 [ 3.300665][ T1] ata2: SATA max UDMA/133 irq 37 [ 3.636269][ T674] ata1: SATA link down (SStatus 0 SControby lonestar - Debian
Hi bodhi, I am currently looking at the GPL source code of synology which seems to be the correct one: https://master.dl.sourceforge.net/project/dsgpl/Synology%20NAS%20GPL%20Source/24922branch/armadaxp-source/u-boot-armada-2011.12.txz?viasf=1 While I am a software developer myself, my knowledge of u-boot is very limited. An interesting detail, that I have found so far: In file mvBoardEnvby lonestar - Debian
I did some further tests regarding the sata drives: the device tree specifies that pcie@1,0 is the usb controller. I think this is wrong, at least for the ds214: - when I remove the pcie@1,0 definition usb stops working. - when only pcie@1,0 is present usb works. I guess this means that the definitions in armada-xp-mv78230.dtsi might also not be sufficient? thanks, Martinby lonestar - Debian
Hi bodhi, unfortunately this doesn't work yet: Quote U-Boot 2023.01-rc1 (Nov 20 2022 - 09:26:19 +0000) SoC: MV78230-B0 at 1066 MHz DRAM: 512 MiB (533 MHz, 32-bit, ECC not enabled) Core: 23 devices, 17 uclasses, devicetree: separate Loading Environment from SPIFlash... SF: Detected n25q064 with page size 256 Bytes, erase size 4 KiB, total 8 MiB OK In: serial@12000 Out: sby lonestar - Debian
stock firmware insists on egiga0. egiga1 will be automatically switched back. see below. Quote Press Ctrl+C to abort autoboot in 3 second Marvell>> setenv ipaddr 192.168.1.190 Marvell>> setenv ethact egiga0 Marvell>> ping 192.168.1.1 Using egiga0 device host 192.168.1.1 is alive ---- rebooted here ------ Press Ctrl+C to abort autoboot in 3 second Marvell>> pby lonestar - Debian
the sata problem might be related to the disabled stuff here: root@debian:~# lspci -v 00:01.0 PCI bridge: Marvell Technology Group Ltd. MV78230 ARM SoC (rev 02) (prog-if 00 ) Device tree node: /sys/firmware/devicetree/base/soc/pcie@82000000/pcie@1,0 Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O bby lonestar - Debian
ethernet@70000 { status = "okay"; pinctrl-0 = <&ge0_gmii_pins>; pinctrl-names = "default"; phy = <&phy1>; phy-mode = "gmii"; }; leads to a change: packet notby lonestar - Debian
This thread was originally about getting the ds214 to work, so the first few messages just show this progress. Later in the thread you will find a short guide on setting ds214 with debian up: https://forum.doozan.com/read.php?2,133377,133858#msg-133858 ---------------------------------------------------------------------- Hi all, I am currently playing around a bit with my Synology DSby lonestar - Debian