GTI Mirabox, Netgear RN102/RN104, Netgear RN2120 Installation & Kernel Upgrade (Linux-6.7.5)

iperf only

[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 54852
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  1.10 GBytes   941 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 54854
[  4]  0.0-10.0 sec  1.04 GBytes   896 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 54856
[  4]  0.0-10.0 sec  1.06 GBytes   909 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 54858
[  4]  0.0-10.0 sec  1.02 GBytes   877 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 54860
[  4]  0.0-10.0 sec  1.03 GBytes   888 Mbits/sec

Linux Mirabox 5.9.3-mvebu-370xp-tld-3
--------------------------------------------------------------------------------------------------
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 35082
[  4]  0.0-10.0 sec   717 MBytes   601 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 35084
[  4]  0.0-10.0 sec   734 MBytes   614 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 35086
[  4]  0.0-10.0 sec   728 MBytes   610 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 35088
[  4]  0.0-10.0 sec   721 MBytes   604 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 35090
[  4]  0.0-10.0 sec   725 MBytes   608 Mbits/sec

Linux Mirabox 5.9.3-mvebu-370xp-tld-4
--------------------------------------------------------------------------------------------------

Linux Mirabox 5.9.3-mvebu-370xp-tld-3 is still the best

Thanks David!

Looks like that IO coherency patch does not work (by itself).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

So apparently, either

- The target has enough juice (the M300 is 2Ghz, 2GB RAM), this kernel has no problem maxing out the network speed.

- Something in the network configuration with the Mirabox that causes the slow down if it is the recipient.


root@Mirabox:~# uname -a

Linux Mirabox 5.9.3-mvebu-370xp-tld-3 #3.0 PREEMPT Sun Nov 29 14:33:38 PST 2020 armv7l GNU/Linux

root@Mirabox:~# dmesg | grep flow

[  188.423040] mvneta d0070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off

root@M300:~# uname -a

Linux M300 5.9.12-kirkwood-tld-1 #1.0 PREEMPT Sat Dec 5 14:05:39 PST 2020 armv5tel GNU/Linux

root@M300:~# dmesg | grep flow

[   34.171088] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled

root@Mirabox:~# iperf -n4000M -i 3 -c 192.168.0.232
------------------------------------------------------------
Client connecting to 192.168.0.232, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.252 port 53616 connected with 192.168.0.232 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 3.0 sec   337 MBytes   942 Mbits/sec
[  3]  3.0- 6.0 sec   338 MBytes   944 Mbits/sec
[  3]  6.0- 9.0 sec   337 MBytes   941 Mbits/sec
[  3]  9.0-12.0 sec   336 MBytes   940 Mbits/sec
[  3] 12.0-15.0 sec   338 MBytes   945 Mbits/sec
[  3] 15.0-18.0 sec   337 MBytes   942 Mbits/sec
[  3] 18.0-21.0 sec   336 MBytes   941 Mbits/sec
[  3] 21.0-24.0 sec   336 MBytes   940 Mbits/sec
[  3] 24.0-27.0 sec   337 MBytes   941 Mbits/sec
[  3] 27.0-30.0 sec   337 MBytes   943 Mbits/sec
[  3] 30.0-33.0 sec   336 MBytes   939 Mbits/sec
[  3]  0.0-35.6 sec  3.91 GBytes   942 Mbits/sec

root@M300:~# iperf -n4000M -i 3 -c 192.168.0.252
------------------------------------------------------------
Client connecting to 192.168.0.252, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.232 port 58530 connected with 192.168.0.252 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 3.0 sec   231 MBytes   646 Mbits/sec
[  3]  3.0- 6.0 sec   229 MBytes   641 Mbits/sec
[  3]  6.0- 9.0 sec   231 MBytes   645 Mbits/sec
[  3]  9.0-12.0 sec   230 MBytes   643 Mbits/sec
[  3] 12.0-15.0 sec   230 MBytes   643 Mbits/sec
[  3] 15.0-18.0 sec   229 MBytes   641 Mbits/sec
[  3] 18.0-21.0 sec   231 MBytes   645 Mbits/sec
[  3] 21.0-24.0 sec   230 MBytes   643 Mbits/sec
[  3] 24.0-27.0 sec   230 MBytes   642 Mbits/sec
[  3]  0.0-29.1 sec  2.18 GBytes   643 Mbits/sec

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

David,

If you could, test the Mirabox with the M300 (see new Kirkwood kernel: https://forum.doozan.com/read.php?2,12096,112319#msg-112319).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

M300 has better performance with the new kernel. Better than Mirabox.

root@OptiPlex790:~# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size:  128 KByte (default)
------------------------------------------------------------
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 50150
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  1002 MBytes   840 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 50152
[  4]  0.0-10.0 sec  1.05 GBytes   902 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 50154
[  4]  0.0-10.0 sec  1.05 GBytes   900 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 50156
[  4]  0.0-10.0 sec  1.04 GBytes   892 Mbits/sec

Linux Mirabox 5.9.3-mvebu-370xp-tld-3

--------------------------------------------------------------------------------------------------

[  4] local 192.168.7.28 port 5001 connected with 192.168.7.109 port 40602
[  4]  0.0-10.0 sec   980 MBytes   821 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.109 port 40604
[  4]  0.0-10.0 sec   980 MBytes   822 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.109 port 40606
[  4]  0.0-10.0 sec   984 MBytes   824 Mbits/sec

Linux m301 5.2.9-kirkwood-tld-2 #1 PREEMPT Wed Aug 28 03:55:21 PDT 2019 armv5tel GNU/Linux

--------------------------------------------------------------------------------------------------

[  4] local 192.168.7.28 port 5001 connected with 192.168.7.109 port 48438
[  4]  0.0-10.0 sec  1.10 GBytes   940 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.109 port 48440
[  4]  0.0-10.0 sec  1.10 GBytes   940 Mbits/sec
[  4] local 192.168.7.28 port 5001 connected with 192.168.7.109 port 48442
[  4]  0.0-10.0 sec  1.10 GBytes   940 Mbits/sec

Linux m301 5.9.12-kirkwood-tld-1 #1.0 PREEMPT Sat Dec 5 14:05:39 PST 2020 armv5tel GNU/Linux


--------------------------------------------------------------------------------------------------

940Mbit/sec is about the maximum I can get from any machine on this spot to my i3 server (192.168.7.28).

Cool!

That's what I am seeing above:

https://forum.doozan.com/read.php?2,92514,112279#msg-112279

Mirabox to M300 : ~940 Mbs

And with the new Kirkwood kernel 5.9.12-kirkwood-tld-1, most of the boxes ( that I have tested so far: Pogo E02, GH Home, GF Net) will be able to achieve the ~940 Mbs.

======

The configuration I am using for the test:

Mirabox -- DLink DAP-1522 Wireless bridge -- M300

This bridge has 4 Gbit ports. Based on the iperf tests number, it does not have flow control enabled in itself (which is usually an unknown variable unless you run OpenWrt or other open source switch/router).

======

The Armada 370 SoC has some HW disadvantage comparing to the Armada 38x or XP. So I'm not sure if we could get it to perform as well if it is the receiver of network traffics.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 12/10/2020 05:28AM by bodhi.

Hi bodhi again,
Could we get 5.10.7 kernel if possible?If it will not increase network problem please don't bother.
Regards.

whitepawn,

> Could we get 5.10.7 kernel if possible?If it will
> not increase network problem please don't bother.

Sure I will build that in the next few days (I meant to but was a little bit busy)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Kernel linux-5.10.7-mvebu-370xp-tld-1 package has been uploaded. Please see 1st for download link.

NOTE: this is the special kernel version for GTI Mirabox and Netgear RN102 boxes only.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 01/30/2021 09:24PM by bodhi.

Hi Bodhi,

After a long pause, I powered up my Netgear RN-102 NAS again today and upgraded the kernel to version 5.10.7 dated 30 Jan 2021. No issues.

For the bulk of MVEBU boxes, your current version is 5.18.6. Do you intend to keep Mirabox and RN-102 current in the future?

The stable Debian version is now bullseye rather than buster. Is it safe to follow the standard Debian release upgrade procedure or should I start over from the your latest MVEBU root file system?

Regards,
Trond Melen

Hi Trond,

> For the bulk of MVEBU boxes, your current version
> is 5.18.6. Do you intend to keep Mirabox and
> RN-102 current in the future?

Yes, I will. I just forgot about it because nobody mentioned this.

> The stable Debian version is now bullseye rather
> than buster. Is it safe to follow the standard
> Debian
> release upgrade procedure or should I start
> over from the your latest MVEBU root file system?

Sure, upgrade is OK from buster to bullseye. The only gotcha is that Debian security site changed. Here is my MVEBU boxes apt sources

# cat /etc/apt/sources.list

deb http://ftp.us.debian.org/debian bullseye main contrib non-free
deb-src http://ftp.us.debian.org/debian bullseye main contrib non-free

deb https://security.debian.org/debian-security bullseye-security main contrib non-free

deb  http://http.debian.net/debian bullseye-updates main contrib non-free
deb-src http://http.debian.net/debian bullseye-updates main contrib non-free

And please remember to backup rootfs. It's a massive change.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Kernel linux-5.19.2-mvebu-370xp-tld-1 package has been uploaded. Please see 1st post for download link.

NOTE: this is the special kernel version for GTI Mirabox and Netgear RN102 boxes only

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@bodhi
Long time no see, how are you?
Nice to see some upgrade. I am using my RN120 as daily driver with your older kernel and openmediavault. Does this new kernel includes better network performance?

@tme
Did you made any iperf tests?

whitepawn,

I did not run any network performance test for this new kernel.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi bodhi,

> Kernel linux-5.19.2-mvebu-370xp-tld-1 package has been uploaded. Please see 1st post for download link.

The file 'Linux-5.8.5-mvebu-370xp-tld-1-bodhi.tar.bz2' (see under Updated 06 Sept 2020) required for first install has been deleted from Dropbox. How do I proceed without it (i.e. without running dpkg)?

Regards,
Trond Melen

Hi Trond,

Sorry, looks like I've removed it by mistake while pugrging old files on my Dropbox.

Please try using linux-5.19.2-mvebu-370xp-tld-1-bodhi.tar.bz2 (replace 5.8.5 with 5.19.2 in the instruction). It should work the same way.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi bodhi,

Following you advice, I successfully did a first install of Debian using 'linux-5.19.2-mvebu-370xp-tld-1-bodhi.tar.bz2'. The log is attached for reference.

U-boot detects some bad blocks, but they don't seem to interfere with the boot. Should I do something about it?

NAND:  (ID 0xf1ad)      128 MiB
MMC:   MRVL_MMC: 0
Bad block table found at page 65472, version 0x01
Bad block table found at page 65408, version 0x01
nand_read_bbt: Bad block at 0x000000f20000
nand_read_bbt: Bad block at 0x000002da0000

Regards,
Trond Melen

Hi Trond,

> Following you advice, I successfully did a first
> install of Debian using
> 'linux-5.19.2-mvebu-370xp-tld-1-bodhi.tar.bz2'.
> The log is attached for reference.

Thanks! I'll update the instruction to reflect that.


> Bad block table found at page 65472, version 0x01
> Bad block table found at page 65408, version 0x01
> nand_read_bbt: Bad block at 0x000000f20000
> nand_read_bbt: Bad block at 0x000002da0000

These bad blocks are far from the u-boot location, so it is OK. We're not using stock FW or the flash for anything other than booting.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi bodhi,

I have sucessfully booted the RN-102 from an SSD connected to the eSATA port on the back of the box. The advantages compared to booting from a USB stick or an SSD connected to the USB 2.0 port at the front panel are:

• faster booting and higher performance, espesially when swapping memory blocks to disk
• the front door may be opened while the box is running to mount or hot swap raid disks in the 2 bays
• the USB port at the front panel may be used for a USB-to-ethernet dongle (or something else)
• the box looks better with a clean front

The eSATA port does not provide 5V power, so a cable that splits the SSDs SATA connector into an eSATA connector and a USB connector for power (see attached picture) is needed. 12V is not neccessary for an SSD.

While the RN-102 was still booted from an SSD conneted to the USB port at the front, I did (as 'root'):

fw_setenv bootcmd 'ide reset; run SATA_bootcmd; reset'
fw_setenv load_uimage 'ext2load ide 0:1 0x2000000 /boot/uImage'
fw_setenv load_uinitrd 'ext2load ide 0:1 0x3000000 /boot/uInitrd'
fw_setenv SATA_bootcmd 'run SATA_set_bootargs; run SATA_boot'
fw_setenv SATA_boot 'run load_uimage; if run load_uinitrd; then bootm 0x2000000 0x3000000; else bootm 0x2000000; fi'
fw_setenv SATA_set_bootargs 'setenv bootargs console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $mtdparts earlyprintk=serial'
fw_printenv

and verified the output (attached for reference). Shut down and the box, disconnected the power, attached the same SSD to the eSATA port on the back and powered up.

The time it takes U-Boot to load 'uImage' and 'uInitrd' is down from 50 s to 5 s when booting the RN-102 from the eSATA port. Not bad.

Thank you very much for keeping this forum alive, updated and interesting!

Regards,
Trond Melen

Hi Trond,

Excellently done!

Thanks for the write up. I'll add eSATA booting to the installation post.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I've added Section C (eSATA booting) to the RN102 installation instruction.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi bodhi,

I have successfully booted Linux kernel 5.19.2 and your Debian bullseye root file system from an SSD connected to the USB2 connector at the front of my Netgear ReadyNAS RN-104. Booting from the same SSD connected to the rear eSata connector, however, fails 19 seconds into the boot when the kernel should check and mount the root file system. The full serial console session is attached.

Booting the RN-104 over eSata from an SSD made for the RN-102 (also kernel 5.19.2) succeeds up to the console login prompt, so I suspect the issue is with the dts-file. The dts-file for RN-102 has been updated as posted here, so maybe the same update for RN-104 is all that is missing?

Regards,
Trond Melen

Hi Trond,

You're right! the RN104 DTS is missing that eSATA node.

Here is the new DTB, please try.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi bodhi,

Success. Thanks! Maybe these updated dts-files should be pushed upstream?

I believe the RN-104 activity LED is directly controlled by the SATA controller. It is steady on when there is no disk activity in the compartment bays, blinking when there is disk activity, and off when there are no disks present. The LED is fairly dim compared to the RN-102. The power and backup LEDs, both inside push bottoms, work as expected.

My additions to your /etc/rc.local file for the RN-102 and RN-104 are:

# ReadyNAS RN-102?
if [ -d /sys/class/leds/rn102:blue:pwr ]; then

	# Switch the Power LED on, but off again if the Activity LED is on (one power indicator is enough)
	echo default-on > /sys/class/leds/rn102:blue:pwr/trigger
	if grep scsi0 /proc/scsi/scsi > /dev/null; then
		echo none > /sys/class/leds/rn102:blue:pwr/trigger
	fi
	if grep scsi1 /proc/scsi/scsi > /dev/null; then
		echo none > /sys/class/leds/rn102:blue:pwr/trigger
	fi

	# Switch the backup LED off
	echo none > /sys/class/leds/rn102:blue:backup/trigger
fi

# ReadyNAS RN-104?
if [ -d /sys/class/leds/rn104:blue:pwr ]; then

	# Switch the Power LED on
	echo default-on > /sys/class/leds/rn104:blue:pwr/trigger

	# Let the backup LED show disk activity on rootfs
	echo disk-activity > /sys/class/leds/rn104:blue:backup/trigger

	# The disk LEDs are supposed to be controled by correponding switches
	echo default-on > /sys/class/leds/rn104:blue:sata1/trigger
	echo default-on > /sys/class/leds/rn104:blue:sata2/trigger
	echo default-on > /sys/class/leds/rn104:blue:sata3/trigger
	echo default-on > /sys/class/leds/rn104:blue:sata4/trigger
fi

U-boot writes "NETGEAR Storage Welcome" on the built-in 2 by 16 character front display when it starts, and "Booting.." before booting Linux, which sticks since Linux makes no effort to change it. This has no apparent effect:

echo Hello world > /dev/char/2:16

In the dts-file, the display is referred to as 'auxdisplay'. Du you have any suggestions on how to write to the display from a shell?

Regards,
Trond Melen



Edited 3 time(s). Last edit at 12/30/2022 08:19AM by tme.

Hi Trond,

> Success. Thanks! Maybe these updated dts-files
> should be pushed upstream?

Not sure if I will have time to do that, atm. I will eventually.

> # Let the backup LED show disk activity on
> rootfs
> echo disk-activity >
> /sys/class/leds/rn104:blue:backup/trigger

What you saw here, disk-activity is the mainline kernel default trigger for all HDDs. In this custom kernel (linux-6.0.7-mvebu-xxx-tld-x), I wrote a patch that added controls for individual HDD LEDs. The trigger are ide-disk1 and ide-disk2. The hardware usually provides the GPIO for each LED, but mainline kernel don't deal with that type of granularity.

This is a Thecus N2350 example,

echo ide-disk1  > /sys/class/leds/n2350:white:sata1/trigger
echo ide-disk2  > /sys/class/leds/n2350:white:sata2/trigger

The LED behavior is a bit different. It will turn off when the HDD is idle, and flash when there is disk activity. I could have added more logic to turn on the HDD LED as a present indicator, but it would get a bit hairy without changing the default state of the blinking LED. I might take a look for this improvement in the future.

Quote

U-boot writes "NETGEAR Storage Welcome" on the built-in 2 by 16 character front display when it starts, and "Booting.." before booting Linux, which sticks since Linux makes no effort to change it. This has no apparent effect:
echo Hello world > /dev/char/2:16
In the dts-file, the display is referred to as 'auxdisplay'. Du you have any suggestions on how to write to the display from a shell?

Perhaps check this sticky thread in the Display sub-forum:

https://forum.doozan.com/read.php?9,10026

superelchi has not been around for a while, but I think you might be able to send PM. For anything small LCD display related, superelchi is the resident expert.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 12/30/2022 03:54PM by bodhi.

Hi bodhi,

When the triggers are set to 'ide-disk1' and 'ide-disk2', LED1 and LED2 are both constantly off when copying a disk in the first compartment to another disk in the second compartment using 'rsync':

tme@rn104:~$ lsblk | grep -v ^loop
NAME      MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda         8:0    1 931.5G  0 disk 
`-sda1      8:1    1 931.5G  0 part /home/rdiff-backup/backup
sdb         8:16   1 931.5G  0 disk 
`-sdb1      8:17   1 931.5G  0 part /home/rdiff-backup/rsync
sdc         8:32   0 111.8G  0 disk 
`-sdc1      8:33   0    64G  0 part /
mtdblock0  31:0    0   1.5M  0 disk 
mtdblock1  31:1    0   128K  0 disk 
mtdblock2  31:2    0     6M  0 disk 
mtdblock3  31:3    0     4M  0 disk 
mtdblock4  31:4    0   116M  0 disk 

tme@rn104:~$ cat /sys/class/leds/rn104:blue:sata1/trigger
none usb-gadget usb-host rc-feedback kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock usbport timer oneshot disk-activity disk-read disk-write [ide-disk1] ide-disk2 mtd nand-disk heartbeat gpio default-on flash torch panic d0072004.mdio-mii:00:link d0072004.mdio-mii:00:1Gbps d0072004.mdio-mii:00:100Mbps d0072004.mdio-mii:00:10Mbps

tme@rn104:~$ cat /sys/class/leds/rn104:blue:sata2/trigger
none usb-gadget usb-host rc-feedback kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock usbport timer oneshot disk-activity disk-read disk-write ide-disk1 [ide-disk2] mtd nand-disk heartbeat gpio default-on flash torch panic d0072004.mdio-mii:00:link d0072004.mdio-mii:00:1Gbps d0072004.mdio-mii:00:100Mbps d0072004.mdio-mii:00:10Mbps

Do you want me to test further?

Regards,
Trond Meen



Edited 1 time(s). Last edit at 01/09/2023 11:54AM by tme.

Hi Trond,

echo default-on > /sys/class/leds/rn104:blue:sata1/trigger
echo none > /sys/class/leds/rn104:blue:sata1/trigger
echo default-on > /sys/class/leds/rn104:blue:sata1/trigger
echo none > /sys/class/leds/rn104:blue:sata1/trigger

And do the same for sata2.

Did the LED turn on/off when set you trigger as above?

I double checked the DTS patches, and turn out that I set the ide-disk1/2 default trigger for RN102, but not RN104.

For the RN102, you don't need to do anything for SATA 1/2 LED. It should blink correctly. Did it?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi bodhi,

Yes, on the RN104, 'default-on' and 'none' work as expected for sata1, sata2, sata3 and sata4. 'ide-disk1' and 'ide-disk2' behaves the same as 'none', i.e. they fail. I believe it's the same for RN102, but I need to check.

Regards,
Trond Melen

Hi bodhi,

I believe it's the same for RN102, but I need to check.

I checked. Contrary to what I believed, 'ide-disk1' and 'ide-disk2' work perfectly on the RN102. Sorry for my confusion!

-Trond

Hi bodhi,

'rayknight' here suggests to add 2 modifications to the configuration to support the 16 by 2 character LCD display on the RN104. I'm eager to test if you provide a kernel update for the Armada 370.

Regards,
Trond Melen