kirkwood: add support for NETGEAR ReadyNAS Duo v2 #3371
Conversation
|
So, this can only be flashed with serial access? |
Yes, serial is required, but without disassembling the case. It's on rear panel. |
CHKDSK88
force-pushed
the
netgear-readynas-v2
branch
from
127b0bb
to
fd41846
Compare
|
This will need clarification as to exactly what Netgear ReadyNAS v2 this is for. There are multiple Netgear ReadyNAS v2 units two of which contain a Kirkwood SOC. The Netgear Model RND-4B marketing name Netgear ReadyNAS NV+ v2 is a 4-bay NAS, The Netgear Model RND-2B marketing name Netgear ReadyNAS Duo v2 is a 2-bay NAS. Based on your description and the name used in some of the patch files this should be Netgear ReadyNAS Duo v2 to avoid confusion. |
CHKDSK88
force-pushed
the
netgear-readynas-v2
branch
from
fd41846
to
1297fd7
Compare
CHKDSK88
changed the title
|
Thank You. I added "Duo" to device name. |
CHKDSK88
force-pushed
the
netgear-readynas-v2
branch
from
1297fd7
to
3486b02
Compare
|
Has this been tested on an actual device? I pulled the git repository branch for CHKDSK88:netgear-readynas-v2. Did a build resulting in: drwxr-xr-x 3 rayk rayk 4096 Sep 5 04:28 . And then followed the "Installation by USB + serial:" instructions with the following result:
|
|
Could You paste result of u-boot |
|
|
Did You have time for more tests? |
CHKDSK88
force-pushed
the
netgear-readynas-v2
branch
from
3486b02
to
ceee899
Compare
|
Binary images, if someone would like to test: |
|
You can add a Test By from me. Installed successfully. |
CHKDSK88
force-pushed
the
netgear-readynas-v2
branch
from
ceee899
to
ccdfea5
Compare
|
Done. Thank You. |
|
Are You plan to merge it? |
CHKDSK88
force-pushed
the
netgear-readynas-v2
branch
from
ccdfea5
to
4282a3d
Compare
|
@adschm Any chance this could be merged soon? I have another device (Netgear ReadyNAS NV+ V2) that would extend from the support for this device. |
CHKDSK88
force-pushed
the
netgear-readynas-v2
branch
from
4282a3d
to
2b2c4e2
Compare
|
Rebased to current master. @ynezz |
|
@aparcar maybe you can look at this too? |
| mkdir -p /var/lock | ||
| touch /var/lock/fw_printenv.lock | ||
| fw_setenv bootargs 'console=ttyS0,115200n8 earlyprintk' | ||
| fw_setenv bootcmd 'nand read.e 0x1200000 0x200000 0x600000;bootm 0x1200000' |
There was a problem hiding this comment.
Hmm... Can we run these commands at installation time and drop these lines here?
There was a problem hiding this comment.
Ok, I will try detect if sysupgrade is called from initramfs and run it only then. But I could test it after 2-3 months, because my device is away from me now.
There was a problem hiding this comment.
I must think about it in the next week.
There was a problem hiding this comment.
I'm not sure... But I thought we can just run those commands in U-Boot shell before the tftpboot, am I missing something?
There was a problem hiding this comment.
Or just check if they match already. Either would be fine by me.
There was a problem hiding this comment.
Alternatively, maybe at least the "bootargs" part could be added to device tree as "chosen" property in /aliaases in device tree?
Edit: I see that those arguments are in place already, so maybe bootargs could be dropped from U-boot environment, unless they need to be cleared?
There was a problem hiding this comment.
I prepared new version: envs are configured only during first installation via initramfs. If someone want override it, changes wouldn't be destroyed via regular sysupgrade.
target/linux/kirkwood/image/Makefile
Outdated
| DEVICE_DTS := kirkwood-netgear_readynas_duo_v2 | ||
| KERNEL_IN_UBI := | ||
| IMAGES := sysupgrade.bin | ||
| DEVICE_PACKAGES := kmod-ata-marvell-sata kmod-fs-ext4 kmod-gpio-button-hotplug \ |
There was a problem hiding this comment.
This line exceeds 80 characters...
| @@ -11,6 +11,10 @@ boot() { | |||
| path_to_hwmon='/sys/class/hwmon/hwmon0' | |||
| echo 2 > "$path_to_hwmon/pwm1_enable" # fan is on pwm1 | |||
| ;; | |||
| netgear,readynas-duo-v2) | |||
| path_to_hwmon='/sys/class/hwmon/hwmon0' | |||
| echo 1200 > "$path_to_hwmon/fan1_target" #set target rpm | |||
There was a problem hiding this comment.
(I cannot add a comment on a line that is not in the diff, so I'll write this here)
# configuring (lm85/lm63) onboard temp/fan controller to run the fan on its own
Maybe we can add "g762" to (lm85/lm63), or remove it entirely.
echo 1200 > "$path_to_hwmon/fan1_target" #set target rpm
And could you add a space after #?
|
Does |
Simple poweroff cause, that it can't be turned on from button and WOL won't work. It need to reset by plug off power supply.
Poweroff in stock firmware cause setting two bits (PHY register: Page 3 Reg 17 Bit 4 and RTC register: SL2(BIT5) of RS5C372a control 1 register (0xe0)) and reboot. If bootloader detect that state, it enable WOL and suspend device. Then it wait for WOL signal or button. If gpio-poweroff is used, power button causes state, when is impossible to turn it on, without plug off the power supply. |
|
So...you mean that the effect of simple poweroff and gpio-poweroff is totally same? Asking to be sure, what is the effect of gpio-poweroff pin (gpio30)? Does the stock FW also use it? |
Hi @CHKDSK88, your NAS is using a marvell PHY right?, then you may need the same poweroff-restart driver I made for the LinkStation LS421DE NAS (see 59c200c). It uses the INTn at the PHY to wake up the machine, restart or power off depending on its state. However, the PHY registers you point to don't make much sense to me. About the RTC, probably the register has to do with the wakealarm pin interrupt, hopefully it is already cleared if a wake alarm is scheduled or not. For testing the Linkstation poweroff-restart driver you need to add your board to the compatible list in the driver itself. Regards |
Another idea: maybe we can configure this pin from U-boot somehow? We have a "phyWrite" command available there. |
I'm on holiday till next Sunday, so I will look again after 16.08.21. Maybe this will work.
I found why author do it: I tried multiple possible solutions. I removed it during tests of workaround. But if we use my patch to poweroff driver, this entry is useless.
Did You try Debian? I wonder, if Openwrt's netifd isn't a problem. |
Acked, makes sense.
Not yet, but I wouldn't suspect netifd here. I'd be happy to run Debian on this box as well, but OpenWrt is my go-to embedded framework. |
|
In the meantime my poweroff patches were accepted: |
Congratulations! |
|
@CHKDSK88 I ran a bisect session on this patchset, and narrowed the problem down to this commit, actually in OpenWrt, not in kernel: 467cd37 (base-files: failsafe: Fix IP configuration) - How strange indeed it is.
And then reverting last commit on my local tree did indeed help! I guess I will rerun the bisect, but this time, include sysupgrade in the process - maybe this will pinpoint the problem more accurately. Now, the question remains, why does this commit affect the power-up sequence. OT: Nice thing is, that I haven't actually need to use my smart plug running https://github.com/arendst/Tasmota to perform power-cycles on the unit, but still it is a very useful tool in an embedded CI environment. |
|
I ran another bisect session, on full image including my patches, and using sysupgrade in the process. I am puzzled, because was running kernel 5.4 in my tests.
There is no need to include this in test images, as this variable is always set by image booted from TFTP, not the actual test image.
|
|
Guys, what's blocking this from getting merged? Did people involved lose interest? |
|
@skoczko We haven't figured out a way to consistently fix the power button issue mis-triggered by PHY configuration. |
|
Thats a pity. Any chances for 'unofficial' build (bins)? If the power button was the only issue - then resetting it from smart plug is not a problem, and the box looks perfect for simple openwrt nas... :) |
|
I agree that it's better than nothing - one could still use "poweroff" command. |
|
I will check it. But if it will not help, I will prepare final version without power button functionality. |
|
@Leo-PL |
|
@CHKDSK88, +1, makes total sense. Please ping me when you push update, I'll rebuild and retest. |
CHKDSK88
force-pushed
the
netgear-readynas-v2
branch
from
7e5f4fc
to
7112215
Compare
|
Reviewed-by: Lech Perczak lech.perczak@gmail.com I noticed, that the power button inactivates, when the link is finally up after setting up interfaces. Unit properly powers off after a "poweroff" command. I'll try to look into the PHY driver in near future. |
|
@Leo-PL |
|
Besides, do you have a datasheet for this PHY, by any chance? |
You can't find it in the internet. :/ |
| mkdir -p /var/lock | ||
| touch /var/lock/fw_printenv.lock | ||
| fw_setenv bootargs 'console=ttyS0,115200n8 earlyprintk' | ||
| fw_setenv bootcmd 'nand read.e 0x1200000 0x200000 0x600000;bootm 0x1200000' |
There was a problem hiding this comment.
It's still lingering in my mind. I think this can be done manually once during the installation. We should access u-boot shell for installation anyway, why should we split the procedure?
I mean, setenv bootcmd ... && saveenv could be inserted somewhere around bootm 0x1200000 in the commit message.
There was a problem hiding this comment.
And then we don't need platform_check_image() change anymore, right?
There was a problem hiding this comment.
I was too fast. Now should be ok.
This patch adds kernel module for Global Mixed-mode Technology Inc G762 and G763 fan speed PWM controller chips. Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
Linkstation poweroff driver was added to mvebu target, but is required for kirkwood target too. This commit make two changes: - move linkstation-poweroff support patch from mvebu to generic and replace upstream accepted version - backport small linkstation-poweroff fix from 5.12 Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
CHKDSK88
force-pushed
the
netgear-readynas-v2
branch
from
7112215
to
b5e4da0
Compare
NETGEAR ReadyNAS Duo v2 is a NAS based on Marvell kirkwood SoC.
Specification:
- Processor Marvell 88F6282 (1.6 GHz)
- 256MB RAM
- 128MB NAND
- 1x GBE LAN port (PHY: Marvell 88E1318)
- 1x USB 2.0
- 2x USB 3.0
- 2x SATA
- 3x button
- 5x leds
- serial on J5 connector accessible from rear panel
(115200 8N1) (VCC,TX,RX,GND) (3V3 LOGIC!)
Installation by USB + serial:
- Copy initramfs image to fat32 usb drive
- Connect pendrive to USB 2.0 front socket
- Connect serial console
- Stop booting in u-boot
- Do:
usb reset
setenv bootargs 'console=ttyS0,115200n8 earlyprintk'
setenv bootcmd 'nand read.e 0x1200000 0x200000 0x600000;bootm 0x1200000'
saveenv
fatload usb 0:1 0x1200000 openwrt-kirkwood-netgear_readynas-duo-v2-initramfs-uImage
bootm 0x1200000
- copy sysupgrade image via ssh.
- run sysupgrade
Installation by TFTP + serial:
- Setup TFTP server and copy initramfs image
- Connect serial console
- Stop booting in u-boot
- Do:
setenv bootargs 'console=ttyS0,115200n8 earlyprintk'
setenv bootcmd 'nand read.e 0x1200000 0x200000 0x600000;bootm 0x1200000'
saveenv
setenv serverip 192.168.1.1
setenv ipaddr 192.168.1.2
tftpboot 0x1200000 openwrt-kirkwood-netgear_readynas-duo-v2-initramfs-uImage
bootm 0x1200000
- copy sysupgrade image via ssh.
- run sysupgrade
Known issues:
- Power button and PHY INTn pin are connected to the same GPIO. It
causes that every network restart button is pressed in system.
As workaround, button is used as regular BTN_1.
For more info please look at file:
RND_5.3.13_WW.src/u-boot/board/mv_feroceon/mv_hal/usibootup/usibootup.c
from Netgear GPL sources.
Tested-by: Raylynn Knight <rayknight@me.com>
Tested-by: Lech Perczak <lech.perczak@gmail.com>
Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
CHKDSK88
force-pushed
the
netgear-readynas-v2
branch
from
b5e4da0
to
0a8e57c
Compare
|
Merged. Thanks! |
NETGEAR ReadyNAS Duo v2 is a NAS based on Marvell kirkwood SoC.
Specification:
(115200 8N1) (VCC,TX,RX,GND) (3V3 LOGIC!)
Installation by USB + serial:
usb reset
fatload usb 0:1 0x1200000 openwrt-kirkwood-netgear_readynas-duo-v2-initramfs-uImage
setenv bootargs 'console=ttyS0,115200n8 earlyprintk'
bootm 0x1200000
Installation by TFTP + serial:
setenv serverip 192.168.1.1
setenv ipaddr 192.168.1.2
setenv bootargs 'console=ttyS0,115200n8 earlyprintk'
tftpboot 0x1200000 openwrt-kirkwood-netgear_readynas-duo-v2-initramfs-uImage
bootm 0x1200000
Known issues:
causes that every network restart button is pressed in system.
As workaround, button is used as regular BTN_1.
For more info please look at file:
RND_5.3.13_WW.src/u-boot/board/mv_feroceon/mv_hal/usibootup/usibootup.c
from Netgear GPL sources.
Tested-by: Raylynn Knight rayknight@me.com
Tested-by: Lech Perczak lech.perczak@gmail.com
Signed-off-by: Pawel Dembicki paweldembicki@gmail.com