Linux Kernel 4.20.6 MVEBU package and Debian armhf rootfs

bodhi Wrote:
-------------------------------------------------------
> Kernel linux-4.18.5-mvebu-tld-1 package has been
> uploaded. Please see 1st post for download link.

Thanks, bodhi!
I did the update on my Thecus N2350 and it is working fine. MTDs are also ok - i used your provided command. The box has been running absolutely stable in the last months.
Cheers, Manuel

> Thanks, bodhi!
> I did the update on my Thecus N2350 and it is
> working fine. MTDs are also ok - i used your
> provided command. The box has been running
> absolutely stable in the last months.
> Cheers, Manuel

Cool! thanks for the report.

-bodhi
===========================
Forum Wiki
bodhi's corner

same with updated DTB (ex2100) and patches..
so linux-4.17.19 is the last "working" kernel for this box ..

pengu Wrote:
-------------------------------------------------------
> same with updated DTB (ex2100) and patches..
> so linux-4.17.19 is the last "working" kernel for
> this box ..

Thanks for reporting pengu.

-bodhi
===========================
Forum Wiki
bodhi's corner

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

-bodhi
===========================
Forum Wiki
bodhi's corner



Edited 1 time(s). Last edit at 02/08/2019 06:18PM by bodhi.

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

-bodhi
===========================
Forum Wiki
bodhi's corner



Edited 1 time(s). Last edit at 02/08/2019 06:19PM by bodhi.

Please see the installation instruction for Mirabox (Armada 370) in this working thread post:

https://forum.doozan.com/read.php?2,41809,80659#msg-80659

If you have the Mirabox, please test the installation instruction.

In the future, I hope to release the Mirabox as part of this kernel. Currently, we need to use a different kernel for this box, due to stock u-boot limitation.

Please post questions or your results in that working thread.

-bodhi
===========================
Forum Wiki
bodhi's corner



Edited 1 time(s). Last edit at 03/17/2019 05:03PM by bodhi.

hi bodhi,

I have a question regarding the installation instructions:
Section A (USB with serial console) calls for GPIO setup like this:

setenv usb_init 'mw.l f1018100 20420000; mw.l f1018140 003E8800; sleep 3; usb start'

Section B (USB without serial console) proposes:

setenv usb_init 'mw.l f1018100 20420000; mw.l f1018140 003E8800; sleep 3; usb start'

Section C (HDD without serial console) proposes:

fw_setenv sata_init 'mw.l f1018100 20420000; mw.l f1018140 003ca800; sleep 3; scsi init'

I looked up the meaning of the GPIO bits in the device tree (armada-380-zyxel-nas326.dts).

Both set GPIO0 the same: Bits 17 (unknown), 22(unknown), 29(pwr_en_sata1) are set.

They differ in how GPIO1 is set:
The USB instructions set:
Bits 11(pwr_en_usb2), 15(unknown), 17(reset button), 18(led:white:sata1), 19(unknown), 20(led:white:sys), 21(led:white:sata2)
The HDD instructions set:
Bits 11(pwr_en_usb2), 13(pwr_en_sata0), 15(unknown), 18(led:white:sata1), 19(unknown), 20(led:white:sys), 21(led:white:sata2)
So the USB instructions set bit 17(reset button), whereas the HDD instructions set bit 13(pwr_en_sata0).

Does this difference serve a purpose?
If possible, could you point out the purpose of the difference in setup and the functions of the unknown pins?

thanks,

kralan

Hi kralan,

The questions about which section of installation for which box?

I see, it's NAS326. It's been a while :) let me look at the DTS and refresh my memory.

-bodhi
===========================
Forum Wiki
bodhi's corner



Edited 3 time(s). Last edit at 04/13/2019 04:19PM by bodhi.

Hi kralan,

About NAS326 GPIOs.


First, what ever you see in the DTS is correct. As I recall, the definition for USB and SATA power were what I got from the u-boot GPL source.

Second, what we have in u-boot envs were just hacks that were proven to work by a few of us here, because those GPIO memory pokes enabled the USB and SATA power. Enough for booting with USB or SATA. Stock u-boot purposedly did not enable power to the drive, it just boot the kernel from NAND, and rely on the stock kernel booting process to enable the power to the drives (those memory pokes were hard coded in stock kernel).

So the DTS nodes definition in the regulators are to be trusted.

               usb2_power

                        gpio = <&gpio1 11 GPIO_ACTIVE_HIGH>;    =>  mpp43
                };

		reg_sata0: regulator@2 {

			gpio = <&gpio1 13 GPIO_ACTIVE_HIGH>;  ==> mpp45
		};

		reg_sata1: regulator@3 {

			gpio = <&gpio0 29 GPIO_ACTIVE_HIGH>;  ==> mpp 29
		};

And about the unknown pins, they were not defined in u-boot GPL source (or there is definition, but I never got around to try to add more pins), so I left them unknown in the DTS. Most likely they are really not used. But if you have this box, you could experiment with them to see if they serve any purpose! or you could try to examine the board visually to see where the pins are traced to, if at all.

-bodhi
===========================
Forum Wiki
bodhi's corner

For reference, here is the GPL source.

/*
 *  linux/drivers/gpio/gpio-ms/gpio_ms.h
 */

/** define gpio offset **/
#if 0
#define HDD1_DETECT_REG_OFFSET                  0
#define HDD2_DETECT_REG_OFFSET          1
#define HDD3_DETECT_REG_OFFSET          2
#define HDD4_DETECT_REG_OFFSET          3
#endif
#define POWER_BUTTON_REG_OFFSET                 46
#define RESET_BUTTON_REG_OFFSET                 49
#define COPY_BUTTON_REG_OFFSET                  39
#define HTP_GPIO_REG_OFFSET                             18
#define HDD1_CTRL_REG_OFFSET                    45
#define HDD2_CTRL_REG_OFFSET            29
//#define HDD3_CTRL_REG_OFFSET            10
//#define HDD4_CTRL_REG_OFFSET            11
#define PWREN_USB_REG_OFFSET            43
#define POWER_OFF_REG_OFFSET                    20
//#define MCU_WDT_REG_OFFSET                            39
#define HDD1_LED_WHITE_REG_OFFSET               50
#define HDD1_LED_RED_REG_OFFSET                 48
#define HDD2_LED_WHITE_REG_OFFSET               53
#define HDD2_LED_RED_REG_OFFSET                 54
//#define HDD3_LED_WHITE_REG_OFFSET             52
//#define HDD3_LED_RED_REG_OFFSET                       53
//#define HDD4_LED_WHITE_REG_OFFSET             54
//#define HDD4_LED_RED_REG_OFFSET                       55
#define SYS_LED_WHITE_REG_OFFSET                52
#define SYS_LED_RED_REG_OFFSET                  55
#define COPY_LED_WHITE_REG_OFFSET               26
#define COPY_LED_RED_REG_OFFSET                 37
#define USB_LED_WHITE_REG_OFFSET                21

-bodhi
===========================
Forum Wiki
bodhi's corner

Also, I might add this to help your understanding what's in the DTS.

The USB and HDD power regulator GPIOs were not defined in the MPP pins. Since they were activated by the kernel automatically, I did not see any value in adding definition for the pins. So they are just GPIOs that are used by the kernel.

-bodhi
===========================
Forum Wiki
bodhi's corner

bodhi,

thank you for your detailed explanation.
I probably won't trace the traces on the board, but I'll go and review the sources to gain more insight.

kralan

kralan,

> thank you for your detailed explanation.
> I probably won't trace the traces on the board,
> but I'll go and review the sources to gain more
> insight.
>

While you are at this GPL source code, perhaps you might come across some way to control the Ethernet port power during shutdown. The normal Debian init script are not doing enough somehow to keep the port alive in a low power state. The GPIO poweroff cut the power, and the ethernet port is also down completely at that time. That's why WOL never works on this box. I did not have time to investigate further.

IIRC, stock NAS326 FW implemeted a big hack for WOL (not a real WOL that is supported by the network chip). It is not acceptable to me to use that approach.

-bodhi
===========================
Forum Wiki
bodhi's corner



Edited 1 time(s). Last edit at 04/14/2019 05:59PM by bodhi.