NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Links to instructions for installing TrueNAS with front panel display capability on some ReadyNAS
For those looking to install an alternate OS on their RN42x, 52x, or 62x unit, here is a link to some very good instructions on installing TrueNAS Scale: https://www.reddit.com/r/truenas/comments/1ozklya/truenas_installation_on_readynas_426_a_stepbystep/
Though it's included in that post, here is the link to a project that makes the front display useful in TrueNAS Scale: https://github.com/riplatt/truenas-rn426-panel
Given it requires no special Kernel and TrueNAS Scale is Debian based, I suspect that the display project can be used as the basis for doing the same under other Linux OS's (at least Debian-based ones).
I take no credit other than finding this and have not done the install myself, so cannot help you if you need it. Personally, I'm looking at OMV.
22 Replies
Thanks for sharing.
I took a quick look - the instructions give the RAM requirement as 16 GB.
RN52x NAS come with 4 GB ECC ram, the RN62x come with 8 GB ECC - so you definitely should upgrade the RAM before conversion. If you want to run apps, you probably should upgrade to 32 GB.
Before anyone gets deep on this, I’m fairly sure that approach to driving the front panel won’t work on a Pro6, only those newer models with navigation buttons.
id love to be proved wrong however!
Oh, and fan control is another thing to think about before jumping right in on your main NAS.
Yes, the display part works only on native OS6 units. The huge amount of RAM required is one reason I think OMV is better suited to most ReadyNAS and the only choice for some. But I posted this for those who think otherwise. Netgear uses lmsensors for fan control, and it should work fine in other Linux variations.
Yes exactly. I’ve got fan control all configured but people need to know it’s a pretty involved and manual process. It’s not an out of the box or add an app experience.
I saw this the other day, and wanted to try it on my RN428 running TrueNAS 25.10.5.
I do have a couple of questions on the install:
git clone https://github.com/riplatt/truenas-rn426-panel.git
cd truenas-rn426-panel
I have a RN428, and from what I've read, it has the same motherboard (and I think the same display). I don't need to change any parameters, correct?
sudo ./install.sh /mnt/<your-pool>/rn426-panel
Which is preferable, the boot pool, or the storage pool? I'm thinking the boot pool, but I wanted to make sure. Also, do you think this will persist across OS updates?The 428 does have the same hardware as a 426, just two more SATA slots, so I'm sure it will work on one. As for your other questions, the person who wrote the code isn't a member of this forum. You can try him over at GitHub or Reddit. Or members of the TrueNAS community may be able to help you on the issues of which pool to use and persistence across any updates.
Thanks! I did drop the same question on the Git page for
truenas-rn426-panel a couple of days ago, but I have not heard back yet. I'm sure he's just busy, and I'm impatient... :D
I'll have to try him on reddit. I never logged into there before
I'm the author of the panel driver. Sandshark, thanks for posting about it in the first place, and sorry it's taken me a while to turn up. I'm on the forum now, so I'm glad to answer things here as well as on GitHub.
Laserbait, I replied to your GitHub issue on the 26th, sorry for the wait. The short version:
The storage pool is the one you want, not the boot pool. A TrueNAS update creates a new boot environment, so anything sitting in the boot pool can get lost, and the installer wants a path under /mnt anyway.
It does survive updates. The files live on the pool, which an update doesn't touch, and the installer registers a POSTINIT script in the TrueNAS config DB, which an update keeps.
Sandshark is right about the 428. The config struct I pulled this out of is named "rn426_8" in the stock kernel, so NETGEAR treated the two models as one board. If you ever have the front bezel off, I'd love a photo of the small board's silkscreen. Mine reads "RN526&RN626X Front Board V20".
On fan control, there's a writeup and a script in the repo now, docs/fan-control.md and tools/it87-fancontrol.sh, so it needn't all be done by hand. portalman, if you've got yours working already I'd be interested in how you went about it. I've only the one machine to go on.
On other models, I agree the RN426 code won't port as it stands, though not quite for the reason you'd expect. The RN426 turns out to be the awkward one. Its panel GPIOs hang off the Denverton SoC through a driver NETGEAR wrote themselves, which never made it to mainline, and that's why my code pokes SoC registers directly.
Every other config I can find in that kernel uses gpio_ich instead. That's ordinary mainline Linux, still in the kernel today. So the other models are probably easier than mine, not harder. I've put the pin maps I extracted in docs/porting.md.
There's a quick test that would tell us whether that holds, if anyone fancies it. Any non-RN426 unit will do. OS6 is too old for gpiodetect, so it needs a live USB, and GRML works fine:
sudo modprobe lpc_ich gpio-ich
gpiodetect
If a chip labelled gpio_ich turns up, it's worth me writing the code. If nothing does, we've found that out in two minutes instead of after I've written a driver blind. No rush, and a negative result is just as useful. I've only got the one RN426, so I can't run it myself.
Riplatt, thank you for joining the discussion here. The ReadyNAS hardware is still extremely capable, but now shackled to an outdated OS. Your help to others in updating to a more modern OS is very much appreciated. My forte is mostly the hardware, not the software. I've learned a lot about Linux in order to get the most use from my ReadyNAS, but I'm no expert by any standard.
I'm going to pull a couple other more likely candidates from storage and see what I get. The 516, 526/8, and 626/8 are the best other candidates to run TrueNAS. Most of the rest can't have RAM expanded enough, so are a better candidate for OMV (see OMV-on-Pro/Ultra-series----a-project). The x1x series are a generation earlier than the x2x series but still OS6 native units. The 526/8 and 626/8 are of the same generation as the 426/8 but with higher end processors (Pentium D1508 for the 52x and Xenon D-1521 for the 62x).
Hi, thanks for your work here. My main workhorses are RN516 (with upgraded RAM/CPU), but many of my testbeds are old legacy Pro6 (upgraded RAM/CPU) with OS6. So I've always been looking for a new OS solution that works with both Pro6 and RN516.
I've never found a front panel driver solution for the Pro6 outside of the Netgear flavour of the OS. I've spent time looking at source etc, and have not got anywhere in replicating a working solution. If the solution for the 516 and newer units works on those, great. Shame there's nothing I know of for the Pro6.
My work on fan control has been to install sensors, sensors-detect, fancontrol and pwmconfig. Detecting the sensors is easy enough, as is testing what's connected to what with pwmconfig - which finally gives you a base fancontrol profile that you can use and tweak. The issue I've found is that the hardware devices/device locations dont always persist between reboots, so what was hmon3/pwm1 can be hmon1/pwm1 on another boot. Annoying.
I've tested nearly every NAS type distro going, and mostly got them working on Pro6/RN516, with some compromises, but I've never found something which felt right, and complete. Booting from USB on an ongoing basis is poor, as is dedicating one or more drives to a boot pool. As is heath-robinson fancontrol for devices that 'move'.
I guess I've never got to the stage with an alternative OS where the compromises were 'better' overall than just sweating the ReadyNAS firmware as is. If the NAS is 'offline' and not internet connected/presenting open ports, and just sitting serving files, it's probably OK for a while yet.
Having said that, I'm very aware that there's plenty of life left in the hardware - and at some point we will simply have no sensible choice but to retire the Readynas OS6 software.
I continue to watch this thread with interest! And I shall be reviewing the testing! If there's a step by step guide, I'd be happy to test things on a Pro6 (even without the display support).
Thanks both.
portalman: the hwmon renumbering is fixable. Don't reference the hwmon numbers at all, look the device up by name. The number changes between boots but the name doesn't:
find_hwmon() {
for h in /sys/class/hwmon/hwmon*; do
[ -r "$h/name" ] || continue
[ "$(cat "$h/name")" = "$1" ] && echo "$h"
done
}
IT="$(find_hwmon it8622 | head -n1)"
Then write to "$IT/pwm2" instead of a fixed path. Worth retrying for a minute at boot too, since the module can register late. That's what tools/it87-fancontrol.sh in the repo does.
No argument on the rest. An offline box that just serves files can stay on OS6. And I've got nothing for the Pro6, I don't even know if its panel is the same design. If you want to find out, tools/rn-probe.sh is read-only and would tell me what's in there (read the safety note at the top first). A negative result still helps.
Sandshark: can you confirm those CPUs for the 526/8 and 626/8, the Pentium D1508 and Xeon D-1521? If that's right, my README is wrong.
I've been claiming the driver covers the RN526 and RN626X because they share the front board with my 426. That holds for the buttons, which really are on the front board. It doesn't hold for the LCD. The LCD never goes through the front board at all, my code drives its pins on the CPU itself, at addresses hard-coded for the Atom C3538 in the 426. On a different CPU those addresses point at nothing and the display just sits on "Booting...", which is what the RN524X owner reported in June.
I only have the 426 so I can't test this myself. I opened an issue rather than quietly editing the README: https://github.com/riplatt/truenas-rn426-panel/issues/4
If you get a 526 or 626 out of storage, rn-probe.sh output settles it. The CPU model line alone is enough. Run that before the gpio_ich test from my last post, if you only run one thing.
Initial probes for a Pro6 and an RN516 uploaded as issues to repo. Will attempt another less troublesome pro6 when I can, along with live-boot probes.
GRML probes for pro6 and rn516 added.
Was unable to complete modprobe and gpiodetect steps due to unavailability of one of the modules. Had to run 25.12 I get it to boot. 2026 image appears not to support legacy bios boot. 25.12 does not appear to include both modules. Was able to install gpiodetect but obviously pointless without modules.
Will loop back on another pro6 chassis with a less troublesome display.
My main unit is a 628X and my backup unit is a 528X, so no need to get them out of storage. AFAIK, the CPU is the only difference in the units' hardware. Here are the results running rn-probe from OS6. To run under GRML, I'll have to wait for a convenient time. Note the CPU info I gave before is accurate. Since the 528X is only my backup, I can more easily run GRML on it, but it's currently in the middle of a scrub.
------------------------------------------------------------
rn-probe.sh report -- paste this whole thing into your GitHub issue
Generated on: RN528A
------------------------------------------------------------
=== 1. Identity ===
dmidecode system-product-name: # SMBIOS implementations newer than version 2.8 are not
# fully supported by this version of dmidecode.
ReadyNAS 528X
dmidecode system-version: # SMBIOS implementations newer than version 2.8 are not
# fully supported by this version of dmidecode.
11/24/2016 ReadyNAS 528X V2.4
dmidecode baseboard-product-name: # SMBIOS implementations newer than version 2.8 are not
# fully supported by this version of dmidecode.
ReadyNAS 528X
product_name: ReadyNAS 528X
product_version: 11/24/2016 ReadyNAS 528X V2.4
board_name: ReadyNAS 528X
bios_version: RN528v24
bios_date: 11/24/2016
=== 2. CPU (most important field -- this driver's GPIO addresses are Intel Denverton/Atom C3000 specific) ===
Model name: Intel(R) Pentium(R) CPU D1508 @ 2.20GHz
=== 3. Kernel ===
Linux RN528A 4.4.218.x86_64.1 #1 SMP Tue Oct 11 22:26:01 UTC 2022 x86_64 GNU/Linux
=== 4. i2c ===
-- loaded i2c modules --
(none matched 'i2c')
-- i2c-dev adapters --
i2c-0: SMBus I801 adapter at f000 <-- likely the i801 (RN426's MSP430 + RTC bus)
(NOTE: bus numbering is NOT stable across reboots -- identify by name, not number.)
-- i2cdetect (ONE read-byte pass per adapter; 0x1c = expected MSP430 on RN426 family, 0x44 = RTC) --
i2cdetect: not installed (part of i2c-tools) -- skipping i2c bus scan
=== 5. hwmon (fan control side) ===
/sys/class/hwmon/hwmon0: coretemp
temp1_input: 49000
temp2_input: 49000
temp3_input: 49000
/sys/class/hwmon/hwmon1: it8732
fan1_input: 2170
fan2_input: 2163
pwm1: 138
pwm1_auto_channels_temp: 1
pwm1_auto_point1_temp: 127000
pwm1_auto_point1_temp_hyst: 127000
pwm1_auto_point2_temp: 127000
pwm1_auto_point3_temp: 127000
pwm1_auto_slope: 3
pwm1_auto_start: 138
pwm1_enable: 3
pwm1_freq: 31250
pwm2: 138
pwm2_auto_channels_temp: 1
pwm2_auto_point1_temp: 127000
pwm2_auto_point1_temp_hyst: 127000
pwm2_auto_point2_temp: 127000
pwm2_auto_point3_temp: 127000
pwm2_auto_slope: 3
pwm2_auto_start: 138
pwm2_enable: 3
pwm2_freq: 31250
pwm3: 128
pwm3_auto_channels_temp: 1
pwm3_auto_point1_temp: 127000
pwm3_auto_point1_temp_hyst: 127000
pwm3_auto_point2_temp: 127000
pwm3_auto_point3_temp: 127000
pwm3_auto_slope: 0
pwm3_auto_start: 128
pwm3_enable: 0
pwm3_freq: 31250
pwm4: 128
pwm4_auto_channels_temp: 8
pwm4_auto_point1_temp: 127000
pwm4_auto_point1_temp_hyst: 127000
pwm4_auto_point2_temp: 127000
pwm4_auto_point3_temp: 127000
pwm4_auto_slope: 127
pwm4_enable: 3
pwm4_freq: 31250
temp1_input: 48000
temp2_input: 40000
temp3_input: 44000
=== 6. PCI (SMBus / LPC / ISA bridge; 00:1f.1 = P2SB the LCD driver needs to unhide) ===
00:1f.0 ISA bridge [0601]: Intel Corporation C224 Series Chipset Family Server Standard SKU LPC Controller [8086:8c54] (rev 05)
00:1f.3 SMBus [0c05]: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller [8086:8c22] (rev 05)
00:1f.1 (P2SB): not found at that address on this board
=== 7. GPIO (read-only) ===
-- loaded GPIO modules --
(nothing matched 'gpio' or 'lpc_ich')
-- gpiochips via /sys/bus/gpio (the one that works on current kernels) --
/sys/bus/gpio/devices not present
-- gpiodetect (libgpiod) --
gpiodetect: not installed (Debian package 'gpiod').
ReadyNAS OS6 is Jessie-based and too old for it. If that's what you're
running, boot a live USB instead -- GRML works fine -- and run this
script from there.
-- legacy /sys/class/gpio (deprecated, and empty on current kernels) --
gpiochip372: gpio_ich
gpiochip448: gpio_it87
entry: export
entry: gpiochip372
entry: gpiochip448
entry: unexport
*** NO GPIO CONTROLLER IS BOUND RIGHT NOW. ***
This is NOT a negative result. The gpio-ich driver does not load by
itself, so an empty list here tells us nothing either way.
To get the answer that actually matters, run these two commands by
hand and paste the output into your issue:
sudo modprobe lpc_ich gpio-ich
gpiodetect
A chip labelled gpio_ich means this driver should port to your model
without any of the register poking the RN426 needs.
This script will not run that modprobe for you. It is strictly
read-only by design -- see the safety note at the top of the file.
If modprobe fails, check the dmesg lines below for
"gpio_ich: ACPI BAR is busy". That one is usually fixed by booting
with acpi_enforce_resources=lax on the kernel command line.
-- dmesg lines mentioning gpio / lpc / p2sb (needs root on most systems) --
[ 1.051900] gpio_it87: Found Chip IT8732 rev 2. 64 GPIO lines starting at 0a10h
[ 1.085169] gpio_ich: GPIO from 372 to 447 on gpio_ich
[ 1.085177] lpc_ich: Resource conflict(s) found affecting gpio_ich
[ 4.862945] __button_init: button 'reset' gpio_it87:23n (IRQ)
[ 4.863071] __button_init: button 'front-board' gpio_ich:2 (IRQ)
[ 4.863077] i2cfb_init: initializing I2C FB buttons gpio_ich:2 (IRQ)
=== 8. Front panel state ===
(This script cannot see the LCD. Please look at the unit right now and
note in your GitHub issue which of these it's showing:)
- stuck on "Booting..."
- blank / backlight off
- showing real info (hostname, pool, etc. -- i.e. already working)
- something else (describe it)
------------------------------------------------------------
ALSO PLEASE INCLUDE in your GitHub issue (this script cannot determine these):
1. Your exact ReadyNAS model number (e.g. RN424, RN524X, RN214, ...).
2. A PHOTO of the front board's silkscreen -- the small printed marking
that identifies the board revision (e.g. this project's board reads
"RN526&RN626X Front Board V20"). It's on the small board behind the
front bezel, connected to the mainboard by a ribbon cable.
3. What the front-panel LCD is currently displaying (see section 8 above).
4. If section 7 said NO GPIO CONTROLLER IS BOUND, the output of:
sudo modprobe lpc_ich gpio-ich && gpiodetect
This script will not load that module itself. Whether a chip
labelled gpio_ich appears is the single most useful thing you can
tell us, and a negative answer is just as useful as a positive one.
------------------------------------------------------------
------------------------------------------------------------
rn-probe.sh report -- paste this whole thing into your GitHub issue
Generated on: RN628A
------------------------------------------------------------
=== 1. Identity ===
dmidecode system-product-name: # SMBIOS implementations newer than version 2.8 are not
# fully supported by this version of dmidecode.
ReadyNAS 628X
dmidecode system-version: # SMBIOS implementations newer than version 2.8 are not
# fully supported by this version of dmidecode.
01/25/2017 ReadyNAS 528X V3.0
dmidecode baseboard-product-name: # SMBIOS implementations newer than version 2.8 are not
# fully supported by this version of dmidecode.
ReadyNAS 628X
product_name: ReadyNAS 628X
product_version: 01/25/2017 ReadyNAS 528X V3.0
board_name: ReadyNAS 628X
bios_version: RN528v30
bios_date: 01/25/2017
=== 2. CPU (most important field -- this driver's GPIO addresses are Intel Denverton/Atom C3000 specific) ===
Model name: Intel(R) Xeon(R) CPU D-1521 @ 2.40GHz
=== 3. Kernel ===
Linux RN628A 4.4.218.x86_64.1 #1 SMP Tue Oct 11 22:26:01 UTC 2022 x86_64 GNU/Linux
=== 4. i2c ===
-- loaded i2c modules --
(none matched 'i2c')
-- i2c-dev adapters --
i2c-0: SMBus I801 adapter at f000 <-- likely the i801 (RN426's MSP430 + RTC bus)
(NOTE: bus numbering is NOT stable across reboots -- identify by name, not number.)
-- i2cdetect (ONE read-byte pass per adapter; 0x1c = expected MSP430 on RN426 family, 0x44 = RTC) --
i2cdetect: not installed (part of i2c-tools) -- skipping i2c bus scan
=== 5. hwmon (fan control side) ===
/sys/class/hwmon/hwmon0: coretemp
temp1_input: 45000
temp2_input: 45000
temp3_input: 44000
temp4_input: 45000
temp5_input: 44000
/sys/class/hwmon/hwmon1: it8732
fan1_input: 1781
fan2_input: 1771
pwm1: 113
pwm1_auto_channels_temp: 1
pwm1_auto_point1_temp: 127000
pwm1_auto_point1_temp_hyst: 127000
pwm1_auto_point2_temp: 127000
pwm1_auto_point3_temp: 127000
pwm1_auto_slope: 3
pwm1_auto_start: 113
pwm1_enable: 3
pwm1_freq: 31250
pwm2: 113
pwm2_auto_channels_temp: 1
pwm2_auto_point1_temp: 127000
pwm2_auto_point1_temp_hyst: 127000
pwm2_auto_point2_temp: 127000
pwm2_auto_point3_temp: 127000
pwm2_auto_slope: 3
pwm2_auto_start: 113
pwm2_enable: 3
pwm2_freq: 31250
pwm3: 128
pwm3_auto_channels_temp: 1
pwm3_auto_point1_temp: 127000
pwm3_auto_point1_temp_hyst: 127000
pwm3_auto_point2_temp: 127000
pwm3_auto_point3_temp: 127000
pwm3_auto_slope: 0
pwm3_auto_start: 128
pwm3_enable: 0
pwm3_freq: 31250
pwm4: 128
pwm4_auto_channels_temp: 8
pwm4_auto_point1_temp: 127000
pwm4_auto_point1_temp_hyst: 127000
pwm4_auto_point2_temp: 127000
pwm4_auto_point3_temp: 127000
pwm4_auto_slope: 127
pwm4_enable: 3
pwm4_freq: 31250
temp1_input: 45000
temp2_input: 42000
temp3_input: 44000
=== 6. PCI (SMBus / LPC / ISA bridge; 00:1f.1 = P2SB the LCD driver needs to unhide) ===
00:1f.0 ISA bridge [0601]: Intel Corporation C224 Series Chipset Family Server Standard SKU LPC Controller [8086:8c54] (rev 05)
00:1f.3 SMBus [0c05]: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller [8086:8c22] (rev 05)
00:1f.1 (P2SB): not found at that address on this board
=== 7. GPIO (read-only) ===
-- loaded GPIO modules --
(nothing matched 'gpio' or 'lpc_ich')
-- gpiochips via /sys/bus/gpio (the one that works on current kernels) --
/sys/bus/gpio/devices not present
-- gpiodetect (libgpiod) --
gpiodetect: not installed (Debian package 'gpiod').
ReadyNAS OS6 is Jessie-based and too old for it. If that's what you're
running, boot a live USB instead -- GRML works fine -- and run this
script from there.
-- legacy /sys/class/gpio (deprecated, and empty on current kernels) --
gpiochip372: gpio_ich
gpiochip448: gpio_it87
entry: export
entry: gpiochip372
entry: gpiochip448
entry: unexport
*** NO GPIO CONTROLLER IS BOUND RIGHT NOW. ***
This is NOT a negative result. The gpio-ich driver does not load by
itself, so an empty list here tells us nothing either way.
To get the answer that actually matters, run these two commands by
hand and paste the output into your issue:
sudo modprobe lpc_ich gpio-ich
gpiodetect
A chip labelled gpio_ich means this driver should port to your model
without any of the register poking the RN426 needs.
This script will not run that modprobe for you. It is strictly
read-only by design -- see the safety note at the top of the file.
If modprobe fails, check the dmesg lines below for
"gpio_ich: ACPI BAR is busy". That one is usually fixed by booting
with acpi_enforce_resources=lax on the kernel command line.
-- dmesg lines mentioning gpio / lpc / p2sb (needs root on most systems) --
[ 0.977445] gpio_it87: Found Chip IT8732 rev 2. 64 GPIO lines starting at 0a10h
[ 1.006123] gpio_ich: GPIO from 372 to 447 on gpio_ich
[ 1.006130] lpc_ich: Resource conflict(s) found affecting gpio_ich
[ 4.823400] __button_init: button 'reset' gpio_it87:23n (IRQ)
[ 4.823523] __button_init: button 'front-board' gpio_ich:2 (IRQ)
[ 4.823529] i2cfb_init: initializing I2C FB buttons gpio_ich:2 (IRQ)
=== 8. Front panel state ===
(This script cannot see the LCD. Please look at the unit right now and
note in your GitHub issue which of these it's showing:)
- stuck on "Booting..."
- blank / backlight off
- showing real info (hostname, pool, etc. -- i.e. already working)
- something else (describe it)
------------------------------------------------------------
ALSO PLEASE INCLUDE in your GitHub issue (this script cannot determine these):
1. Your exact ReadyNAS model number (e.g. RN424, RN524X, RN214, ...).
2. A PHOTO of the front board's silkscreen -- the small printed marking
that identifies the board revision (e.g. this project's board reads
"RN526&RN626X Front Board V20"). It's on the small board behind the
front bezel, connected to the mainboard by a ribbon cable.
3. What the front-panel LCD is currently displaying (see section 8 above).
4. If section 7 said NO GPIO CONTROLLER IS BOUND, the output of:
sudo modprobe lpc_ich gpio-ich && gpiodetect
This script will not load that module itself. Whether a chip
labelled gpio_ich appears is the single most useful thing you can
tell us, and a negative answer is just as useful as a positive one.
------------------------------------------------------------
Thanks for sharing this. The front panel support is a nice touch, especially for older ReadyNAS hardware where the display often becomes useless after switching the OS. I’m also curious how well the same approach works on other Debian-based systems like OMV. Could be a useful project for anyone trying to get more life out of these older units.
Quick update, and thanks to you both. That was fast work.
Sandshark, your 528X/628X probes settled it. Pentium D1508 and Xeon D-1521 confirmed, C224 chipset, none of the hardware my LCD code talks to. So my README was wrong and I've now fixed it: the driver is for the RN426/428 only. The good news in your output is the dmesg lines showing the stock kernel drives the front panel through gpio_ich, with the button interrupt on gpio_ich line 2. That's the map I need for a proper 52x/62x port.
portalman, your GRML probes explained themselves once I checked: Debian stopped building the gpio-ich module entirely, in both current releases. Your modprobe didn't fail because of anything on your end, the module doesn't exist. TrueNAS and OMV use Debian kernels, so the same applies there.
That kills my "load the module and use libgpiod" plan, but there's a cleaner route anyway: the ICH GPIO block sits on plain I/O ports, so a driver can talk to it directly through /dev/port with no kernel module at all. That's how my RN426 code already works, and it would run the same on OS6, GRML, TrueNAS or OMV. That's the direction I'll take for the 52x/62x port, and possibly the 516 after that.
No need to run anything else for now. When I have code worth testing I'll say so here.
Thanks for the links Sandshark, I didn't know about either of those.
portalman, the second one covers your Pro6. The Pro6 LCD isn't GPIO at all, it's a serial device on /dev/ttyS1 with a simple text protocol, and berouques' scripts already drive it under Debian and OMV. Worth a try on one of your test mules.
The fmor kernel module covers the Ultra 4 (LCD, LEDs and buttons) and has a fork for the RN314. I'll link all of these from my porting docs so people with those models find the right project. Mine stays focused on the 52x/62x route from my last post.
I believe the one for the Ultra4 is also appropriate to the Ultra6, and may be for the Pro6, too. I really haven't looked at them very deeply, as I'm not there yet with OMV.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
