aprayoga
-
Posts
138 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Community Map
Posts posted by aprayoga
-
-
I could not reproduce your setup.
First I tried with fresh Armbian 20.08.8 then transfer to eMMC using nand-sata-install.System can boot if sd card inserted.
I clean up the eMMC. then run next test.
I tried boot from fresh Armbian 20.08.4 then transfer to eMMC using nand-sata-install.
System can boot if sd card inserted.Then boot from fresh Armbian 20.08.8 without cleaning the eMMC, then transfer to eMMC using nand-sata-install.
System can boot if sd card inserted.
Initially I though maybe previous u-boot on eMMC looking for old device tree name therefore your system failed to boot. But it does not seem the case.
4 hours ago, TDCroPower said:Is it possible to do something with the file /boot/armbianEnv.txt and changing the variable "rootdev"?
Because in the /boot/boot.scr the default value for "rootdev" -> "/dev/mmcblk0p1" is used and this is the partition of the microSD.You could try to set "rootdev=/dev/mmcblk1p1" in /boot/armbianEnv.txt as a workaround.
But keep in mind that all of the actual boot files are still on sdcard and not accessible under /boot/
-
3 hours ago, antsu said:
This one works "even less" (if that makes sense) since it's missing this patch and fails at an earlier stage in the compilation process. (With the patch applied it fails at the same point I mentioned in my previous post).
Unrelated, but I should also note that today, after configuring my Helios64 with the legacy Armbian image and letting it run for a few hours with a moderate load, it crashed again with a kernel panic. Unfortunately I wasn't able to capture the panic messages as I had iftop open on the serial console at the time and it all mixed together beautifully.
So with Armbian 20.08.8 LEGACY, the system still crashed? Let us know if you managed to get the log and a way to reproduce the crash.
3 hours ago, TDCroPower said:Did the team change anything about the boot variant with the 20.08.8?
With the previous version I was able to boot from the eMMC with a detour and now I can't boot anymore, although the image was transferred via nand-sata-install!There is a change to rename device tree to follow mainline device tree naming.
from /boot/rockchip/rk3399-helios64.dtb to /boot/rockchip/rk3399-kobol-helios64.dtb
Did you use fresh image of 20.08.8 then transfer to eMMC via nand-sata-install?
-
To summarize current status
Feature Support Status Feature Legacy Remarks Current Remarks Shutdown Issue Failed to shutdown PMIC and trigger crash, HDD already parked OK Reboot Issue Similar like shutdown but Watchdog trigger the reboot so it appear successful OK Suspend to RAM Not Supported Yet Failed to resume operation after wake up Not Supported Yet USB host controller refuse to enter suspend mode 2.5G Ethernet OK Performance Issue Slightly improved with tx offload disabled Main Power/UPS Status OK Status can be read from sysfs OK Status can be read from sysfs Battery Charging Status Not Supported OK Charging and Full charge can be read from sysfs UPS configuration Not Supported Yet Need user-space tool to monitor power status and trigger shutdown Not Supported Yet Need user-space tool to monitor power status and trigger shutdown USB Type C - Host OK Not Supported Yet There are some issue with fusb302 driver and USB Host Controller driver USB Type C - Gadget OK Not Supported Yet There are some issue with fusb302 driver and USB Controller driver USB Type C - DisplayPort OK Not Supported Yet There are some issue with fusb302 driver and DisplayPort alternate driver eMMC Install Not Supported Yet The bootloader unable to load rootfs from eMMC Not Supported Yet The bootloader unable to load rootfs from eMMC SPI Boot Not Supported Yet Not Supported Yet Recovery key Not Supported Yet System can enter maskrom mode but need special OS image and rkdevelop Not Supported Yet System can enter maskrom mode but need special OS image and rkdevelop We are still working on eMMC issue.
-
Helios64 also encounter some random crash, yesterday we tried to redefine opp just 408 MHz and 1.4/1.8 GHz and we don't see any random crash anymore.
It seems similar DVFS problem as discussed in this thread. Then our customer point us to odroid n1 issue at
https://forum.odroid.com/viewtopic.php?t=30303
Maybe you can give it a try on Nano Pi M4v2.
We are still testing on Helios64 (with value 40000), so far with reboot and power cycle does not trigger any kernel crash.
-
@FredK and @bigbrovar, thanks for the info.
on Friday, i did some initial investigation and as you said upper USB port seems only work at 2.0 (high-speed USB device) not 3.0.[ 42.581478] usb 4-1: new high-speed USB device number 2 using xhci-hcd [ 42.747232] usb 4-1: New USB device found, idVendor=0480, idProduct=0820, bcdDevice= 3.15 [ 42.755452] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 42.762635] usb 4-1: Product: External USB 3.0 [ 42.767095] usb 4-1: Manufacturer: TOSHIBA [ 42.771225] usb 4-1: SerialNumber: XXXXXXXXXXX6F [ 42.777009] usb-storage 4-1:1.0: USB Mass Storage device detected [ 42.785088] scsi host4: usb-storage 4-1:1.0 [ 42.839846] usbcore: registered new interface driver uas [ 49.139357] scsi 4:0:0:0: Direct-Access TOSHIBA External USB 3.0 5438 PQ: 0 ANSI: 6 [ 49.149674] sd 4:0:0:0: Attached scsi generic sg2 type 0 [ 49.161946] sd 4:0:0:0: [sdc] Very big device. Trying to use READ CAPACITY(16). [ 49.171592] sd 4:0:0:0: [sdc] 7814037164 512-byte logical blocks: (4.00 TB/3.64 TiB) [ 49.179392] sd 4:0:0:0: [sdc] 4096-byte physical blocks [ 49.187768] sd 4:0:0:0: [sdc] Write Protect is off [ 49.195302] sd 4:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 49.334260] sdc: sdc1 sdc2 [ 49.339876] sd 4:0:0:0: [sdc] Attached SCSI disk
this morning i tried, and it works as 3.0 (SuperSpeed Gen 1 USB device)
[ 90.585477] usb 4-1: new high-speed USB device number 2 using xhci-hcd [ 91.477501] usb 5-1: new SuperSpeed Gen 1 USB device number 2 using xhci-hcd [ 91.503435] usb 5-1: New USB device found, idVendor=0480, idProduct=0820, bcdDevice= 3.15 [ 91.511642] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 91.518807] usb 5-1: Product: External USB 3.0 [ 91.523274] usb 5-1: Manufacturer: TOSHIBA [ 91.527390] usb 5-1: SerialNumber: XXXXXXXXXXX6F [ 91.534376] usb-storage 5-1:1.0: USB Mass Storage device detected [ 91.540743] scsi host4: usb-storage 5-1:1.0 [ 91.583403] usbcore: registered new interface driver uas [ 97.211091] scsi 4:0:0:0: Direct-Access TOSHIBA External USB 3.0 5438 PQ: 0 ANSI: 6 [ 97.221100] sd 4:0:0:0: Attached scsi generic sg2 type 0 [ 97.229812] sd 4:0:0:0: [sdc] Very big device. Trying to use READ CAPACITY(16). [ 97.238524] sd 4:0:0:0: [sdc] 7814037164 512-byte logical blocks: (4.00 TB/3.64 TiB) [ 97.246315] sd 4:0:0:0: [sdc] 4096-byte physical blocks [ 97.253361] sd 4:0:0:0: [sdc] Write Protect is off [ 97.258537] sd 4:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 97.394956] sdc: sdc1 sdc2 [ 97.402343] sd 4:0:0:0: [sdc] Attached SCSI disk
we will need to investigate further
-
On 6/5/2020 at 3:52 PM, Vin said:
Another very vital point is software support, for what i can tell the RK3399 doesnt seem to run all too stable on other devices so far?
as mentioned by @Werner, RK3399 runs best on the legacy, 4.4 kernel. Mainline, (LK 5.4), for example, still have some issue on DP over TypeC.
We ran some burn-in test (stress-ng for cpu, parallel fio on all sata port, all usb port, emmc and microsd) under LK 4.4. we didn't encounter stability issue in 24 hours.
Similar like Helios4, Helios64 will have legacy and current support.
On 3/12/2020 at 12:29 AM, Userlab said:Hi @aprayoga
you are right but maybe i can with https://www.delock.com/produkte/1089_M-2/65921/merkmale.html
i have tried similar riser from Amazon, as you can see on following pictures, the riser is too long
and M.2 modem is too wide
-
2 minutes ago, Tido said:
Could you name the two families? And maybe say one or two words about your expectation about each. So, people know where you come from and what you are looking for.
the families are
- rk3399
only rockpro64 and rock pi 4 under this family
- rockchip64
the rest of rk3399 boards.
Helios64 can boot with both family with the correct device tree (different dts for rk3399 and rockchip64).
looking at this PR https://github.com/armbian/build/pull/1934 it seems the direction is to merge rk3399 to rockchip64 (implied by renaming the the patch folder from rk3399 into rockchip64 instead of the other way a round).
-
Hi all,
currently i'm working on upcoming Helios64 board. For RK3399 board there are 2 families, what are the differences between them?
I've been following discussion on github and this forum for few months but still unsure which family i should use.
-
7 hours ago, FrancisTheodoreCatte said:
After upgrading to the 4.19.104-mvebu kernel I also started experiencing the same complete cpu lockups, but here's the kicker: the lockups are continuing, even after downgrading to kernel 4.14.171-mvebu.
Easy way for me to trigger it is by running echo check > /sys/block/md0/md/sync_action
I managed to catch the CPU stall via the serial console:
https://pastebin.com/C8yCQMAnHere's the output from armbianmonitor -u:
edit:
same lockup still happens when running an md data-check even after downgrading further, to 4.14.153-mvebu.
Thanks for providing the crash log.
Last weekend i ran some test with following image
- Buster NEXT upgraded to buster CURRENT
- fresh Buster CURRENT
and load the system with
stress-ng -c 2 -P 70
It supposed to make the system busy and run with full speed (1.6 GHz). i ran it for about 20 hours each test but i did not encounter any issue.
Looking on your log, it seems marvell_xor that trigger the crash. I will try your suggestion to trigger the crash -
-
On 2/12/2020 at 4:27 AM, shaddow501 said:
Second issue:
When "make scripts" and make modules_prepare instead of link to the 5.4.18-sunxi64 it creates a link for modules in 5.4.18 which makes the modules useless, since it doesnt go to the correct /lib/modules library.
instead that the modules will be installed in lib/modules/5.4.18-sunxi64, it install it in /lib/modules/5.4.18.
The way to fix it is to modify the Makefile and add the -sunxi64.
VERSION = 5
PATCHLEVEL = 4
SUBLEVEL = 18
EXTRAVERSION = -sunxi64
NAME = Kleptomaniac OctopusI don't think you need to modify the Makefile, you can set LOCALVERSION environment variable before compiling.
You could try something like this when you invoke the makeLOCALVERSION=-sunxi64 make modules
Here is how Armbian compile the kernel:
https://github.com/armbian/build/blob/master/lib/compilation.sh#L367-L371 -
On 1/13/2020 at 5:35 AM, Carlo said:
Hi,
I have a problem with ch341 USB serial adapter, I tried to search on forum and on internet without luck.
I'm runnig a Linux helios4 4.19.84-mvebu #19.11.3 on an helios4 board, off course.
When I connect a CH341 device, like NodeMCU, serial adapter or an Arduino Mega Pro Mini, etc, for the first time or I boot the system with the device connected, it is enumerated correctly and I have it listed on dmesg and I give a /dev/ttyUSBx, but if I disconnect and reconnect it, the system, sometimes at the first time, sometimes after few times, give me these errors and didn't detects the usb adapter until the next boot.
What's wrong ? What can I do, other usb device, link stick, works fine.
Sotty for my english, I hope that my message is comprensible.
Bye, Carlo
[dom gen 12 23:28:15 2020] usb 2-1: new full-speed USB device number 7 using xhci-hcd [dom gen 12 23:28:15 2020] usb 2-1: New USB device found, idVendor=1a86, idProduct=5523, bcdDevice= 3.04 [dom gen 12 23:28:15 2020] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [dom gen 12 23:28:15 2020] ch341 2-1:1.0: ch341-uart converter detected [dom gen 12 23:28:15 2020] usb 2-1: ch341-uart converter now attached to ttyUSB0 [dom gen 12 23:28:26 2020] usb 2-1: USB disconnect, device number 7 [dom gen 12 23:28:26 2020] usb 2-1: ch341_read_int_callback - usb_submit_urb failed: -19 [dom gen 12 23:28:31 2020] xhci-hcd f10f0000.usb3: xHCI host not responding to stop endpoint command. [dom gen 12 23:28:31 2020] xhci-hcd f10f0000.usb3: xHCI host controller not responding, assume dead [dom gen 12 23:28:31 2020] xhci-hcd f10f0000.usb3: HC died; cleaning up [dom gen 12 23:28:31 2020] usb 2-1: failed to send control message: -19 [dom gen 12 23:28:31 2020] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0 [dom gen 12 23:28:31 2020] ch341 2-1:1.0: device disconnected
A few months ago I enabled some USB-Serial converter driver on the kernel and test it. I used an USB hub then hotplug several USB-Serial (PL2303, FT232, FT2232, CH340G, CH341A, CP2101, CP2102), all detected correctly.
According to your log, it seems something wrong with the USB Host controller driver, could you try with other USB device? maybe USB Flash drive -
5 hours ago, Mangix said:
My kernel right now is 4.19.63-mvebu. Is this the latest version? It doesn't sound like it is.
Between middle-to end of November 2019, Armbian change the version and branch naming.
Version from something like 5.91 become something like 19.11.x, if i'm not mistaken Year.Month, like Ubuntu versioning.
Then the branch name,
- DEFAULT become LEGACY
- NEXT become CURRENT
To upgrade to new version, use armbian-config.
sudo apt-get update sudo apt-get -y upgrade sudo armbian-config
Select System > Other, to switch to other kernel
Confirm the action
And after some process, you will be presented by list of kernels
Select linux-image-current-mvebu. The system will install the new kernel and automatically reboot.
Confirm the kernel installed correctly and Armbian changed to new branch CURRENT by executing,
uname -a grep "BRANCH" /etc/armbian-release
-
13 hours ago, sirleon said:
@aprayoga Thank you very much! It is working now after I followed your advice in combination with these instructions from David
to solve this Error:
Good to hear you got it working. I tried the instructions first on my system and did not encounter such error. Could you share your u-boot version?
On 12/29/2019 at 7:57 AM, Koen said:I'm trying to start afresh on the latest buster image, but failing miserably.
1. Armbian-config setting Locale not working and subsequently giving perl errors. (Fixed by manually editing /etc/default/locale)
2. Arbmian-config setting Keyboard not doing anything. (Fixed by manually edditing /etc/default/keyboard)3. Arbmian-config accessing "system - CPU" crashes armbian-config.
cat: /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies: File or folder doesn't exist cat: /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors: File or folder doesn't exist
4. Can't do anything iptables, not even -L to see existing rules, let alone actually configuring anything.
iptables v1.8.2 (nf_tables): CHAIN_ADD failed (No such file or directory): chain INPUT
Haven't been able to get around the last one. Tried removing and reinstalling the iptables package, but same result.
I test on fresh Armbian_19.11.3_Helios4_buster_current_4.19.84.img
1. I don't encounter such error when accessing the system from Windows using PuTTY or thru serial console
UPDATE: i tried to SSH from my Ubuntu machine (got id_ID locale), indeed there are perl warning regarding locale but armbian-config is still usable to generate the locale, no need to manually edit file. After the locale generated by armbian-config, no more perl locale warning.
2. Confirmed3. Confirmed.
cat: /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies: No such file or directory cat: /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors: No such file or directory /usr/lib/armbian-config/jobs.sh: line 1075: Error: Expected at least 5 tokens for --menu, have 4. Use --help to list options. / 1000: syntax error in expression (error token is ": Expected at least 5 tokens for --menu, have 4. Use --help to list options. / 1000")
The path is not exist, even though the driver is compiled. I will need to investigate further.
---
I also tried using fresh Armbian 5.91 then upgraded to Armbian 19.11.3, but strangely i don't see the System - CPU menu.
4. As mentioned on @sirleon link, apparently Buster make use nftables by default and on our kernel is not enabled. You could try to switch to iptables-legacy version.
CONFIG_NF_TABLES=m CONFIG_NF_TABLES_SET=m # CONFIG_NF_TABLES_INET is not set # CONFIG_NF_TABLES_NETDEV is not set # CONFIG_NF_TABLES_IPV4 is not set # CONFIG_NF_TABLES_ARP is not set # CONFIG_NF_TABLES_IPV6 is not set # CONFIG_NF_TABLES_BRIDGE is not set
meanwhile, i will try to enable those modules and test.
@Igor, could you take a look whether armbian-config issues also occur on other board?
-
On 12/23/2019 at 12:20 AM, sirleon said:
I tried to move the complete system from the SD-card to an SSD, so i followed the tutorial as described here.
I'm not sure how to do the following steps:
I can't move the target SATA-device because spi_workaround is enabled.
What can I do to get rid of the SD-card and booting from SPI / SATA-device?
Should I move the /boot partition from the SD-card to sdb1? Is it necessary to modify /etc/fstab ?
(I alread tried moving the rootFS with sata-nand-install while spi_workaround is disabled. The system was booting and mounted from sdb1, but I can't get it to boot without the SD-card)
Hi @sirleon, the tutorial is intended for moving the rootfs to USB thumb drive and due to spi_workaround it does not work with SATA seamlessly but you almost there..
I suggest to move the rootfs to drive that connected to SATA0 (most likely /dev/sda), because there is known issue that u-boot failed to recognized SATA device other than on SATA0.
To boot from SATA you need to:
1. Move the rootfs with sata-nand-install while spi_workaround is disabled, and reboot.
The system will boot from SD card.2. Unmount /boot and copy over boot files from /media/mmcboot/boot to /boot
umount /boot cp -rf /media/mmcboot/boot/* /boot/
3. Edit /etc/fstab and remove/comment 2 lines that have mount point to /media/mmcboot and /boot.
4. Reboot the system and cancel u-boot auto boot.
5. Run following commands on u-boot prompt to add sata boot and reboot
setenv boot_targets "usb0 scsi0 mmc0 pxe dhcp" setenv bootcmd_scsi0 'devnum=0; run scsi_boot' saveenv
You could reorder the boot order on boot_targets variable. On above command, it would tried to boot from USB and if failed try SATA/SCSI and so on.
-
On 8/15/2019 at 9:48 AM, jimbolaya said:
I just received and set up my Helios4. I set it up with Buster and it seems to be working OK.
One thing that seems to be missing is the ch341 usb serial driver. I have this attached to an old APC UPS that has a serial port and a USB serial cable that uses the HL-340 serial chip.
I was unable to find the driver in /lib/modules. Will I need to compile the driver myself or am I missing a package?
If it wasn't included intentionally, is there a technical reason not to include the driver for this kernel?
@jimbolaya, I know it's quite late, ch341 driver would be included on next release. Refer to commit 14a0a54.
On 10/7/2019 at 6:00 PM, smith69085 said:Hello, I've been using the Helios4 for some time now and its working great. The only thing I'm missing is a soft shut down button, opposed to using ssh.
I'm pretty new to this and struggling to find info on a solution. CAn anyone point me in the right direction for a shutdown button connected through the gpio pins?
@smith69085, we have updated the wiki page how to use the GPIO for button. You can take a look on
https://wiki.kobol.io/gpio/#use-gpio-with-device-tree-overlay
But currently the base dtb (armada-388-helios4.dtb) on Armbian 5.91 is still not compiled with overlay support. You can download the attached dtb, rename and replace the dtb on your system.
lk4.14_armada-388-helios4.dtb is for Armbian Default (Stretch, Linux Kernel 4.14)
sudo cp lk4.14_armada-388-helios4.dtb /boot/dtb/armada-388-helios4.dtb
lk4.19_armada-388-helios4.dtb is for Armbian Next (Buster, Linux Kernel 4.19)
sudo cp lk4.19_armada-388-helios4.dtb /boot/dtb/armada-388-helios4.dtb
-
@Mangix have you check the wiki, https://wiki.kobol.io/cesa/ ? There are plenty of informations over there, for example the benchmark result and what kind of cipher can be hardware accelerated.
-
On 9/6/2019 at 5:55 PM, Fefo said:
Hi,
Yes - System activity led is blinking
Yes - power indicator led is also on
System is not possible to reach either by console or network
STEP-1
I have tried starting system without mentioned disk on SATA port 4 and then is OK (access possible).
STEP-2
I changed SATA cable for port4 and reconnecting disk - system becomes unnaccessible again.
STEP-3
I have tried starting system without disk on SATA port 3 and then is OK (access possible).
STEP-4
I tried and changed SATA cable for port 3 and reconnecting disk - system becomes unnaccessible again.
My result:
If Disks on SATA3 and SATA4 are both connected - system doesnt start.
Last operation (before malfunction) was creating mirror (inside OpenMediaVault) between this two disks (both 1TB - on SATA 3 and SATA4 ports )
Is it a SW bug of some sort?
Info: At this point data loss is not a problem - I have this for testing purposes for now.
Regards
I still confused with your configuration, you said you setup sdb & sdc as mirror but from the armbian log on first post, it's RAID level 5 with member sdb, sdc, &sdd
Quote[ 2.858020] async_tx: api initialized (async)
[ 2.864901] md/raid:md0: not clean -- starting background reconstruction
[ 2.864938] md/raid:md0: device sdb operational as raid disk 0
[ 2.864941] md/raid:md0: device sdc operational as raid disk 1
[ 2.864943] md/raid:md0: device sdd operational as raid disk 2
[ 2.866085] md/raid:md0: raid level 5 active with 3 out of 3 devices, algorithm 2
[ 2.916888] md0: detected capacity change from 0 to 2000140894208
[ 3.685359] random: crng init done
Please run the following commands to make boot process more verbose
sudo sed -i 's/verbosity=1/verbosity=7/g' /boot/armbianEnv.txt echo "extraargs=no_console_suspend ignore_loglevel" | sudo tee -a /boot/armbianEnv.txt sudo sed -i 's/exit 0/dmesg -n 8\nexit 0/g' /etc/rc.local sudo reboot
and please capture serial console from very beginning of u-boot.
Oh, with the configuration that has problem.
-
1 hour ago, prok said:
Hello, I'm going through the setup tutorial, but I'm unable to connect to the Helios4 via serial port. I'm running PuTTY on Windows, and installed the FTDI driver (via setup executable) from the page linked in the installation guide. When I attempt to connect, nothing happens. The device shows under Device Manager using the COM3 port. I tried setting the speed to 115200 for the COM3 port via Windows settings, but that didn't make a difference. Is there something I'm missing?
Hi,
Just wanted to make sure, do you see something like in screenshot below?
-
5 hours ago, alchemist said:
Hi,
An other question : I would like to run the latest vanilla kernel (5.2.*). Is there a patch for the dual fan ? The patch provided in the pwm section seems for kernel 4.x and is is rejected.
Thanks!
Kind regards,
Xavier Miller.
Hi,
We haven't started to work on 5.2 but maybe you can try the patch by Gontran Baerts for ArchLinux
-
18 hours ago, alchemist said:
Hi,
I am trying to compile and run U-BOOT on SATA1 but I don't succeed. What I can do is boot from flash memory using the armbian binary provided on the armbian sd card.
And I cannot find the SATA installation documentation on the wiki, except the picture with the DIP switches (I used this from Solidrun, : dd if=u-boot-spl-sata.kwb of=/dev/sdX bs=512 seek=1 conv=sync, not working).
And I cannot get a self-compiled working U-BOOT binary with helios4_defconfig
So my questions is what options do I need to activate to have a self-compiled U-BOOT binary that can boot on SATA ? Is the dd command from Solidrun OK for the sata option ?
(For now, I will boot from flash memory, running Gentoo Linux and concentrate later on U-Boot... I want to understand and master that part too)
Kind regards,
Xavier Miller
Hi,
currently booting directly to SATA1 is not supported. It was supported using Marvell U-boot 2013.01.
If your intention is to boot without SD Card, you can boot from SPI NOR flash. The U-Boot on SPI NOR flash then would search boot.scr on following order
- USB
- SATA1
- SD Card
-
1 hour ago, jimbolaya said:
I just received and set up my Helios4. I set it up with Buster and it seems to be working OK.
One thing that seems to be missing is the ch341 usb serial driver. I have this attached to an old APC UPS that has a serial port and a USB serial cable that uses the HL-340 serial chip.
I was unable to find the driver in /lib/modules. Will I need to compile the driver myself or am I missing a package?
If it wasn't included intentionally, is there a technical reason not to include the driver for this kernel?
Hi,
you're right, the driver is not included, you'd need to compile the driver by yourself if you need ASAP.I don't see any technical reason not to include the driver. After i test, I will enable it on Armbian kernel
-
@MarcC it is possible to write U-Boot directly to SATA disk but currently no U-Boot image for SATA available. and AFAIK, the procedure a bit different but more similar like PC. Write U-Boot SPL to disk boot sector then put u-boot.bin into FAT formatted 1st partition.
We are still experimenting with this, can not say when it would be ready.
-
27 minutes ago, MarcC said:
Hi @gprovost,
Reading the wiki while waiting for the Batch3 , I was wondering if it would be possible to boot directly to a sata disk...
SPI-NOR Flash wiki page only mentions booting to a microSD card or USB drives. Would something like the following work ?
ext4load sata 0:1
Or does the concurrent access issue between SPI NOR Flash and SATA drives currently prevents this ? Thanks.
Yes, you can boot from SATA disk but currently limited only from SATA1 port.
Take a look on following log:
U-Boot SPL 2018.11-00008-g8f200a3d28 (Jul 03 2019 - 08:01:15 +0800) High speed PHY - Version: 2.0 Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type | -------------------------------- | 0 | 6 | SATA0 | | 1 | 5 | USB3 HOST0 | | 2 | 6 | SATA1 | | 3 | 6 | SATA3 | | 4 | 6 | SATA2 | | 5 | 5 | USB3 HOST1 | -------------------------------- High speed PHY - Ended Successfully mv_ddr: mv_ddr-armada-17.10.4 DDR3 Training Sequence - Switching XBAR Window to FastPath Window DDR Training Sequence - Start scrubbing DDR3 Training Sequence - End scrubbing mv_ddr: completed successfully Trying to boot from SPI U-Boot 2018.11-00008-g8f200a3d28 (Jul 03 2019 - 08:01:15 +0800) SoC: MV88F6828-A0 at 1600 MHz DRAM: 2 GiB (800 MHz, 32-bit, ECC enabled) MMC: mv_sdh: 0 Loading Environment from SPI Flash... SF: Detected w25q32bv with page size 256 Bytes, erase size 4 KiB, total 4 MiB OK Model: Helios4 Board: Helios4 SCSI: MVEBU SATA INIT Target spinup took 0 ms. Target spinup took 0 ms. AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq led only pmp fbss pio slum part sxs Net: Warning: ethernet@70000 (eth1) using random MAC address - ee:e0:5b:09:22:72 eth1: ethernet@70000 Hit any key to stop autoboot: 0 starting USB... USB0: MVEBU XHCI INIT controller @ 0xf10f4000 Register 2000120 NbrPorts 2 Starting the controller USB XHCI 1.00 USB1: MVEBU XHCI INIT controller @ 0xf10fc000 Register 2000120 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 1 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Device 0: device type unknown ... is now current device scanning bus for devices... Device 0: (0:0) Vendor: ATA Prod.: TOSHIBA MK5065GS Rev: GJ00 Type: Hard Disk Capacity: 476940.0 MB = 465.7 GB (976773168 x 512) Device 0: (0:1) Vendor: ATA Prod.: TOSHIBA MK5065GS Rev: GJ00 Type: Hard Disk Capacity: 476940.0 MB = 465.7 GB (976773168 x 512) Device 0: (1:0) Vendor: ATA Prod.: STEC MACH8 SSD Rev: 1031 Type: Hard Disk Capacity: 57241.8 MB = 55.9 GB (117231408 x 512) Device 0: (1:1) Vendor: ATA Prod.: STEC MACH8 SSD Rev: 1031 Type: Hard Disk Capacity: 57241.8 MB = 55.9 GB (117231408 x 512) Found 4 device(s). Device 0: (0:0) Vendor: ATA Prod.: TOSHIBA MK5065GS Rev: GJ00 Type: Hard Disk Capacity: 476940.0 MB = 465.7 GB (976773168 x 512) ... is now current device Scanning scsi 0:1... Found U-Boot script /boot/boot.scr 2948 bytes read in 88 ms (32.2 KiB/s) ## Executing script at 03000000 Boot script loaded from scsi 199 bytes read in 54 ms (2.9 KiB/s) 18933 bytes read in 167 ms (110.4 KiB/s) 5408781 bytes read in 223 ms (23.1 MiB/s) 5590368 bytes read in 218 ms (24.5 MiB/s) ## Loading init Ramdisk from Legacy Image at 02880000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 5408717 Bytes = 5.2 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 02040000 Booting using the fdt blob at 0x2040000 Loading Ramdisk to 0fad7000, end 0ffff7cd ... OK reserving fdt memory region: addr=2040000 size=6a000 Loading Device Tree to 0fa6a000, end 0fad6fff ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel.
Helios4 boot from SPI with rootfs located on scsi 0:1
To access the SATA disk, you have to use scsi command instead of sata command
Helios64 Support
in Rockchip
Posted
@TDCroPower
The eMMC boot fixed on this PR . The wiki instruction more on new install using new u-boot that able to emulate eMMC as USB Mass Storage.
You should wait new Armbian update