Linux Kernel 5.3.5 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 07: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 07: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 06: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 05: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 06:59PM by bodhi.

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

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

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

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

This thread is temporarily closed until the next release.

Please create a new thread for installation problem.

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

I believe there is a bug in 4.12.4 kernel.

I installed omv on wd cloud mirror gen2, it seems everything works fine but when I copy big size file from nas to pc.

nas loose connection on samba/ftp.

I found similar case below

https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=171122&sid=6503947620282ef0f210efb3a28ad75b&start=25

https://forum.openmediavault.org/index.php/Thread/12245-OMV-Machine-hangs-randomly-on-large-file-transfers-to-OMV/?pageNo=1

I updated with 4.20.6 kernel and copy 40Gb over samba, works fine.

mcmg2,

Thanks for reporting this. The next rootfs will be buster and kernel 5.2.5+ so will fix this issue.

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

Kernel linux-5.2.9-mvebu-tld-1 package has been uploaded. There are important updates in this release.

Note: please beware that the boot envs need to be changed in this kernel version (to boot with uImage). Please see the kernel release notes.

Please see 1st post for download link.

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



Edited 1 time(s). Last edit at 08/27/2019 10:53PM by bodhi.

Hi Bodhi,

i try to generate a BootFS with your 5.2.9 kernel. (I had no problems up to and including version 5.1.7)

I have a Zyxel NAS 326 and create my own Debian RootFS and boot with a uImage.
But with kernel 5.2.9 a can't create a uInitrd.

I use this commands in a chroot qemu enviorment:

varK="5.2.9-mvebu-tld-1"
varV="1.0"

dpkg -i "/boot/linux-image-${varK}_${varV}_armhf.deb"
update-initramfs -k ${varK} -c

cp -a "/boot/vmlinuz-${varK}" "/boot/vmlinuz.tmp"
cat "/boot/armada-380-zyxel-nas326.dtb" >> "/boot/vmlinuz.tmp"

mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-${varK} -d "/boot/vmlinuz.tmp" "/boot/uImage"
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-${varK} -d "/boot/initrd.img-${varK}" "/boot/uInitrd"

rm -f "/boot/vmlinuz.tmp"

The output of the second mkimage-command is:

/usr/bin/mkimage: Write error on /boot/uInitrd: Success

Normally the output of the mkimage command look like this:

Image Name:   Linux-5.1.7-mvebu-tld-1
Created:      Mon Sep  9 10:04:54 2019
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    4680892 Bytes = 4571.18 KiB = 4.46 MiB
Load Address: 00008000
Entry Point:  00008000

Image Name:   initramfs-5.1.7-mvebu-tld-1
Created:      Mon Sep  9 10:04:56 2019
Image Type:   ARM Linux RAMDisk Image (gzip compressed)
Data Size:    9828544 Bytes = 9598.19 KiB = 9.37 MiB
Load Address: 00000000
Entry Point:  00000000

EDIT:
Everything is fine, I found my mistake.
My image-file which i used for mount /boot was too small.



Edited 1 time(s). Last edit at 09/09/2019 09:50AM by Kirsch.

Basic buster rootfs Debian-5.2.9-mvebu-tld-1-rootfs-bodhi.tar.bz2 has been uploaded. Please 1st for download link.

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

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

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