aprayoga

@lalaw recovery mode use usb 2.0 signals while g_mass_storage use the USB 3.0 signals. Since you were able to test it under 4.4 and works at super-speed, your connection seems ok. how did you load the g_mass_storage kernel module? have you tried to unplug and re-plug the usb cable after loading the g_mass_storage module?

@Lore you could add fsck.repair=yes to extraargs line on /boot/armbianEnv.txt extraargs=earlyprintk ignore_loglevel fsck.repair=yes it will run fsck.ext4 -y /dev/mmcblk0p1 automatically. --- You have another issue (I'd say bigger issue), why you often got files system corruption. Does it always happen after a reboot? Could you monitor/log serial console during reboot ? maybe there are some processes that killed forcefully by systemd because missing the timeout to shutdown

It affect various subsystem. CPU governance work in higher level, algorithm, when to apply certain CPU speed from predefined table.

VDD_LOG powers internal logic circuitry such as SRAM, clock & reset Unit, PLL, internal MCU. VDD_CENTER powers mostly vpu, encoder/decoder but it also powers DDR controller. Recommended operating condition for those supply is 0.9V but we have found other RK3399 board, RockPro64, increase this to 0.95V to improve stability https://github.com/u-boot/u-boot/commit/f210cbc1f3d4f84baa595d83933369b4d6a529ea https://github.com/u-boot/u-boot/commit/5a6d960b222203e60ab57e19b3eb7b41c24b564b

@maknho did you mean the enclosure? In short, no. You can't use Helios64 enclosure with another board.

Hi @Seneca, @SR-G Could you add following lines to the beginning of /boot/boot.cmd regulator dev vdd_log regulator value 930000 regulator dev vdd_center regulator value 950000 run mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr and reboot. Verify whether it can improve stability. You could also use the attached boot.scr boot.scr

Hi @snakekick, @clostro, @silver0480, @ShadowDance could you add following lines to the beginning of /boot/boot.cmd regulator dev vdd_log regulator value 930000 regulator dev vdd_center regulator value 950000 run mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr and reboot. Verify whether it can improve stability. You could also use the attached boot.scr boot.scr

@Mydogboris Does Red LED (System Error) on the front panel blinking?

@Lore, do you have other Linux system ? please modify /boot/armbianEnv.txt on the micro SD card and add/modify following lines: verbosity=7 console=serial extraargs=earlyprintk ignore_loglevel It should make the serial console more verbose

@yay thank you for additional testing. We will take note at the MTU value.

@mortomanos Could you contact us to support@kobol.io and see how we can help you from there in case there is a need to return the board.

We still trying to get the proper firmware for the chip. It is possible but as i mentioned previously, the main problem is the system could not enter suspend, then next problem is no wol support in PHY driver and if i'm not mistaken, there is no support for interrupt mode in PHY driver.

@allen--smithee if you need to modify the bootloader, you can start from these lines https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-rockchip64-mainline/add-board-helios64.patch#L1671-L1687 You can add parameter checking there. Maybe check certain U-Boot environment variable, maybe check for certain file in the filesystem. You could also remove it completely and modify /boot/boot.scr instead, to enable/disable the HDD power. Another thing to explore, you could remove the afromentioned u-boot function and also remove the power rail nodes from linux device tree https://github.com/armbian/build/blob/master/patch/kernel/rockchip64-current/add-board-helios64.patch#L239-L259 and then when you need to enable it, just access the gpio from sysfs.

@silver0480 thank you for detailed test procedure.

We are working on this issue. The same Realtek driver working fine on an Ubuntu laptop (amd64), Helios4 (armhf), and Helios64 LK 4.4. We are looking into USB host controller driver, it seems there are some quirks not implemented on mainline kernel.

You can use DAS mode on Kernel 5.9 using device tree overlay It is not as seamless as in LK 4.4 where you can just change to cable to switch the usb role but it work. I gave you a like, it should lift the limitation. 1. correct 2. Yes, you'd need to use filesystem that can be recognized by both, Linux and Mac. With FAT32 there is maximum partition size and maximum file size (4GB) limitation. With exFAT, it might put some load to cpu during NAS because of FUSE but it might be change in future where in kernel module used instead of FUSE. 4. I don't have experience with SnapRaid. There is another method you can explore to use the DAS mode, expose the system as MTP device. It should not have issue with exclusive access to block device and the filesystem type.

@tikey Could you check whether LED8 is on or blinking?

@ebin-dev, unfortunately there is no progress.

@tionebrr yes, the firmware on 2.5G chip. The 1G PHY interrupt is open drain but default state after reset the pin is pulled low, i guess there is an interrupt event nack by phy driver. You could disconnect 1G PHY interrupt line by removing D31 but i don't think it would help since the 2.5G firmware does not use the pin. The interrupt pin connected to GPIO0_B0 on RK3399

@devman Could you measure the voltage at molex power connector?

@Renée if you compile the u-boot yourself you can get the binaries required. You can execute following command from u-boot source code tools/kwboot -b u-boot-spl.kwb -t -B 115200 /dev/ttyUSB2 adapt /dev/ttyUSB2 to the correct USB serial on your system. I also attached u-boot-spl.kwb and kwboot (compiled on Ubuntu 20.04 amd64) for your convenience

@retrack as mentioned by @gprovost, the main issue is suspend is not supported yet. then there is no wol support on realtek PHY driver (1G ethernet). on 2.5G ethernet, the firmware does not trigger interrupt pin. even if it does, it won't work due to the interrupt line pulled by 1G PHY. The interrupt line is shared between 1G and 2.5G ethernet. so it still need Realtek PHY changes. There is another way to use WoL on 2.5G, by using USB suspend mechanism / LPM. but unfortunately RK3399 does not support this.

@chango yes, it seems something wrong with the on-board eMMC. You shouldn't be able to move to eMMC if it wasn't detected. Could you attach serial console output since power on?

@succo what image/kernel did you use? on legacy it should work. I haven't tested much on mainline kernel.

@tekrantz, Did you need to shave the included USB-C serial console cable? if yes, you might also need to shave the cable on your dongle. OK, before doing that, maybe try without the backplate first. this is log form LK 5.9 and this is log from LK 4.4 Dongle in use: https://www.ugreen.com/products/5-in-1-usb-c-hub-with-4k-hdmi Note: I don't have recess issue on the USB-C port so I don't need to shave the USB C cable.