aprayoga
-
Posts
138 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by aprayoga
-
-
@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
-
18 hours ago, SR-G said:
+ what exactly are these values / are they related to the CPU speed and if yes, how are they different than what is applyed when modifying the CPU governance configuration through armbian-config ?
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.
SpoilerIf the other board follows Nano ITX form factor (size and screw hole location), you might be able to put it inside Helios64 enclosure.
But you will face some difficulties, for example
- find cable/wiring to power the SATA drives. No space to put PC power supply (whatever the form factor).
- the backplate, you would need to create your own backplate.
-
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.
Spoilermodified boot.cmd
# DO NOT EDIT THIS FILE # # Please edit /boot/armbianEnv.txt to set supported parameters # regulator dev vdd_log regulator value 930000 regulator dev vdd_center regulator value 950000 setenv load_addr "0x9000000" setenv overlay_error "false" # default values setenv rootdev "/dev/mmcblk0p1" setenv verbosity "1" setenv console "both" setenv bootlogo "false" setenv rootfstype "ext4" setenv docker_optimizations "on" setenv earlycon "off" echo "Boot script loaded from ${devtype} ${devnum}" if test -e ${devtype} ${devnum} ${prefix}armbianEnv.txt; then load ${devtype} ${devnum} ${load_addr} ${prefix}armbianEnv.txt env import -t ${load_addr} ${filesize} fi if test "${logo}" = "disabled"; then setenv logo "logo.nologo"; fi if test "${console}" = "display" || test "${console}" = "both"; then setenv consoleargs "console=tty1"; fi if test "${console}" = "serial" || test "${console}" = "both"; then setenv consoleargs "console=ttyS2,1500000 ${consoleargs}"; fi if test "${earlycon}" = "on"; then setenv consoleargs "earlycon ${consoleargs}"; fi if test "${bootlogo}" = "true"; then setenv consoleargs "bootsplash.bootfile=bootsplash.armbian ${consoleargs}"; fi # get PARTUUID of first partition on SD/eMMC the boot script was loaded from if test "${devtype}" = "mmc"; then part uuid mmc ${devnum}:1 partuuid; fi setenv bootargs "root=${rootdev} rootwait rootfstype=${rootfstype} ${consoleargs} consoleblank=0 loglevel=${verbosity} ubootpart=${partuuid} usb-storage.quirks=${usbstoragequirks} ${extraargs} ${extraboardargs}" if test "${docker_optimizations}" = "on"; then setenv bootargs "${bootargs} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1"; fi load ${devtype} ${devnum} ${ramdisk_addr_r} ${prefix}uInitrd load ${devtype} ${devnum} ${kernel_addr_r} ${prefix}Image load ${devtype} ${devnum} ${fdt_addr_r} ${prefix}dtb/${fdtfile} fdt addr ${fdt_addr_r} fdt resize 65536 for overlay_file in ${overlays}; do if load ${devtype} ${devnum} ${load_addr} ${prefix}dtb/rockchip/overlay/${overlay_prefix}-${overlay_file}.dtbo; then echo "Applying kernel provided DT overlay ${overlay_prefix}-${overlay_file}.dtbo" fdt apply ${load_addr} || setenv overlay_error "true" fi done for overlay_file in ${user_overlays}; do if load ${devtype} ${devnum} ${load_addr} ${prefix}overlay-user/${overlay_file}.dtbo; then echo "Applying user provided DT overlay ${overlay_file}.dtbo" fdt apply ${load_addr} || setenv overlay_error "true" fi done if test "${overlay_error}" = "true"; then echo "Error applying DT overlays, restoring original DT" load ${devtype} ${devnum} ${fdt_addr_r} ${prefix}dtb/${fdtfile} else if load ${devtype} ${devnum} ${load_addr} ${prefix}dtb/rockchip/overlay/${overlay_prefix}-fixup.scr; then echo "Applying kernel provided DT fixup script (${overlay_prefix}-fixup.scr)" source ${load_addr} fi if test -e ${devtype} ${devnum} ${prefix}fixup.scr; then load ${devtype} ${devnum} ${load_addr} ${prefix}fixup.scr echo "Applying user provided fixup script (fixup.scr)" source ${load_addr} fi fi booti ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r} # Recompile with: # mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scrYou could also use the attached 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.
Spoilermodified boot.cmd
# DO NOT EDIT THIS FILE # # Please edit /boot/armbianEnv.txt to set supported parameters # regulator dev vdd_log regulator value 930000 regulator dev vdd_center regulator value 950000 setenv load_addr "0x9000000" setenv overlay_error "false" # default values setenv rootdev "/dev/mmcblk0p1" setenv verbosity "1" setenv console "both" setenv bootlogo "false" setenv rootfstype "ext4" setenv docker_optimizations "on" setenv earlycon "off" echo "Boot script loaded from ${devtype} ${devnum}" if test -e ${devtype} ${devnum} ${prefix}armbianEnv.txt; then load ${devtype} ${devnum} ${load_addr} ${prefix}armbianEnv.txt env import -t ${load_addr} ${filesize} fi if test "${logo}" = "disabled"; then setenv logo "logo.nologo"; fi if test "${console}" = "display" || test "${console}" = "both"; then setenv consoleargs "console=tty1"; fi if test "${console}" = "serial" || test "${console}" = "both"; then setenv consoleargs "console=ttyS2,1500000 ${consoleargs}"; fi if test "${earlycon}" = "on"; then setenv consoleargs "earlycon ${consoleargs}"; fi if test "${bootlogo}" = "true"; then setenv consoleargs "bootsplash.bootfile=bootsplash.armbian ${consoleargs}"; fi # get PARTUUID of first partition on SD/eMMC the boot script was loaded from if test "${devtype}" = "mmc"; then part uuid mmc ${devnum}:1 partuuid; fi setenv bootargs "root=${rootdev} rootwait rootfstype=${rootfstype} ${consoleargs} consoleblank=0 loglevel=${verbosity} ubootpart=${partuuid} usb-storage.quirks=${usbstoragequirks} ${extraargs} ${extraboardargs}" if test "${docker_optimizations}" = "on"; then setenv bootargs "${bootargs} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1"; fi load ${devtype} ${devnum} ${ramdisk_addr_r} ${prefix}uInitrd load ${devtype} ${devnum} ${kernel_addr_r} ${prefix}Image load ${devtype} ${devnum} ${fdt_addr_r} ${prefix}dtb/${fdtfile} fdt addr ${fdt_addr_r} fdt resize 65536 for overlay_file in ${overlays}; do if load ${devtype} ${devnum} ${load_addr} ${prefix}dtb/rockchip/overlay/${overlay_prefix}-${overlay_file}.dtbo; then echo "Applying kernel provided DT overlay ${overlay_prefix}-${overlay_file}.dtbo" fdt apply ${load_addr} || setenv overlay_error "true" fi done for overlay_file in ${user_overlays}; do if load ${devtype} ${devnum} ${load_addr} ${prefix}overlay-user/${overlay_file}.dtbo; then echo "Applying user provided DT overlay ${overlay_file}.dtbo" fdt apply ${load_addr} || setenv overlay_error "true" fi done if test "${overlay_error}" = "true"; then echo "Error applying DT overlays, restoring original DT" load ${devtype} ${devnum} ${fdt_addr_r} ${prefix}dtb/${fdtfile} else if load ${devtype} ${devnum} ${load_addr} ${prefix}dtb/rockchip/overlay/${overlay_prefix}-fixup.scr; then echo "Applying kernel provided DT fixup script (${overlay_prefix}-fixup.scr)" source ${load_addr} fi if test -e ${devtype} ${devnum} ${prefix}fixup.scr; then load ${devtype} ${devnum} ${load_addr} ${prefix}fixup.scr echo "Applying user provided fixup script (fixup.scr)" source ${load_addr} fi fi booti ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r} # Recompile with: # mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scrYou could also use the attached boot.scr
-
@Mydogboris Does Red LED (System Error) on the front panel blinking?
-
-
-
@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.
-
On 1/8/2021 at 5:53 PM, tionebrr said:
Alright this I understand. Too bad for the 2.5G chips...
We still trying to get the proper firmware for the chip.
On 1/8/2021 at 5:53 PM, tionebrr said:he 1G Phy is reset before suspend, which pulls INTB low, which triggers the event, and the driver clears the interrupt before suspending? Is this possible guys?
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.
-
if you need to modify the bootloader, you can start from these lines
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
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.
-
On 1/9/2021 at 5:21 AM, lalaw said:
1. Any ETA on when DAS mode would be rolled into kernel 5.x?
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.
On 1/9/2021 at 5:21 AM, lalaw said:2. Any ideas on how I can get around the 1 post per day limitation?
I gave you a like, it should lift the limitation.
On 1/9/2021 at 5:21 AM, lalaw said:Some issues that I foresee:
1. Because the DAS mode is using the Mass Storage Gadget, it seems like my choices are to expose the entire disk/block device or to have a file that simulates the block devices. The problem with the file is that it would no longer appears as a filesystem in NAS mode, correct?
2. If my assumption in (1) is true, then I have to expose the entire disk. For the Mac to read the disk, I assume I need to use exFat or Fat32 (as ext4, ZFS, etc. support on Mac sound spotty for r/w)
3. exFat/Fat32 don't appear to be first class citizens in the world of OMV, but it sounds like I can cobble together support and mount those disks manually
4. Once sorted out, would it be possible to combine the Capture1 disk with other NAS-dedicated disks in a SnapRaid group for redundancy? And expose the Capture1 disk as a (r/o) share on the NAS?
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.
-
-
-
@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.
SpoilerSimplified schematic
D31 location
The interrupt pin connected to GPIO0_B0 on RK3399
-
-
@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.
-
-
-
@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
SpoilerDec 23 00:49:26 helios64 kernel: cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work [rockchipdrm]] Not connected. Disabling cdn Dec 23 00:49:26 helios64 kernel: cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work [rockchipdrm]] Not connected. Disabling cdn Dec 23 00:50:15 helios64 kernel: cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work [rockchipdrm]] Not connected. Disabling cdn Dec 23 00:50:15 helios64 kernel: cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work [rockchipdrm]] Connected, not enabled. Enabling cdn Dec 23 00:50:16 helios64 kernel: Console: switching to colour frame buffer device 240x67 Dec 23 00:50:16 helios64 kernel: rockchip-drm display-subsystem: [drm] fb0: rockchipdrmfb frame buffer device
and this is log from LK 4.4
SpoilerDec 23 01:05:57 helios64 kernel: fusb302 4-0022: CC connected in CC2 as DFP Dec 23 01:05:57 helios64 kernel: cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work] Not connected. Disabling cdn Dec 23 01:05:57 helios64 kernel: fusb302 4-0022: PD disabled Dec 23 01:05:57 helios64 kernel: xhci-hcd xhci-hcd.2.auto: xHCI Host Controller Dec 23 01:05:57 helios64 kernel: xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 2 Dec 23 01:05:57 helios64 kernel: xhci-hcd xhci-hcd.2.auto: hcc params 0x0220fe64 hci version 0x110 quirks 0x06030010 Dec 23 01:05:57 helios64 kernel: xhci-hcd xhci-hcd.2.auto: irq 223, io mem 0xfe800000 Dec 23 01:05:57 helios64 kernel: usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 Dec 23 01:05:57 helios64 kernel: usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 Dec 23 01:05:57 helios64 kernel: usb usb2: Product: xHCI Host Controller Dec 23 01:05:57 helios64 kernel: usb usb2: Manufacturer: Linux 4.4.213-rk3399 xhci-hcd Dec 23 01:05:57 helios64 kernel: usb usb2: SerialNumber: xhci-hcd.2.auto Dec 23 01:05:57 helios64 kernel: hub 2-0:1.0: USB hub found Dec 23 01:05:57 helios64 kernel: hub 2-0:1.0: 1 port detected Dec 23 01:05:57 helios64 kernel: xhci-hcd xhci-hcd.2.auto: xHCI Host Controller Dec 23 01:05:57 helios64 kernel: xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 6 Dec 23 01:05:57 helios64 kernel: usb usb6: We don't know the algorithms for LPM for this host, disabling LPM. Dec 23 01:05:57 helios64 kernel: usb usb6: New USB device found, idVendor=1d6b, idProduct=0003 Dec 23 01:05:57 helios64 kernel: usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1 Dec 23 01:05:57 helios64 kernel: usb usb6: Product: xHCI Host Controller Dec 23 01:05:57 helios64 kernel: usb usb6: Manufacturer: Linux 4.4.213-rk3399 xhci-hcd Dec 23 01:05:57 helios64 kernel: usb usb6: SerialNumber: xhci-hcd.2.auto Dec 23 01:05:57 helios64 kernel: hub 6-0:1.0: USB hub found Dec 23 01:05:57 helios64 kernel: hub 6-0:1.0: 1 port detected Dec 23 01:05:57 helios64 kernel: rockchip-dwc3 usb0: USB HOST connected Dec 23 01:05:59 helios64 systemd[1]: systemd-hostnamed.service: Succeeded. Dec 23 01:05:59 helios64 kernel: fusb302 4-0022: PD connected as DFP, supporting 5V Dec 23 01:05:59 helios64 kernel: fusb302 4-0022: DP config successful, pin_assignment 0x8 Dec 23 01:05:59 helios64 kernel: cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work] Not connected. Disabling cdn Dec 23 01:06:00 helios64 kernel: usb 6-1: new SuperSpeed USB device number 2 using xhci-hcd Dec 23 01:06:00 helios64 kernel: usb 6-1: New USB device found, idVendor=2109, idProduct=0817 Dec 23 01:06:00 helios64 kernel: usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Dec 23 01:06:00 helios64 kernel: usb 6-1: Product: USB3.0 Hub Dec 23 01:06:00 helios64 kernel: usb 6-1: Manufacturer: VIA Labs, Inc. Dec 23 01:06:00 helios64 kernel: hub 6-1:1.0: USB hub found Dec 23 01:06:00 helios64 kernel: hub 6-1:1.0: 4 ports detected Dec 23 01:06:00 helios64 kernel: fusb302 4-0022: attention, dp_status 9a Dec 23 01:06:00 helios64 kernel: cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work] Connected, not enabled. Enabling cdn Dec 23 01:06:00 helios64 kernel: rockchip-vop ff900000.vop: [drm:vop_crtc_enable] Update mode to 1024x768p75, type: 10
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.
USB-C DAS (Is it or is it NOT supported?)
in Rockchip
Posted
@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?