aprayoga
-
Posts
138 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by aprayoga
-
-
-
Hi everyone, thank you for all of your support.
I'll be still around but not in full time as before.
I saw Helios64 has several issues in this new release. I will start looking into it.
-
Hi all, you could download the SATA firmware update at https://cdn-kobol-io.s3-ap-southeast-1.amazonaws.com/Helios64/SATA_FW/Helios64_SATA_FW_update_00021_200624.img.xz
Instruction:
1. Download the sd card image
2. Flash the image into a microSD card
3. Insert microSD card into Helios64 and power on. Helios64 should automatically boot from microSD. If Helios64 still boot from eMMC, disable the eMMC
4. Wait for a while, the system will do a reboot and then power off if firmware flashing succeed.
If failed, both System Status and System Fault LEDs will blink
5. Remove the microSD card and boot Helios64 normally. See if there is any improvement.
Our officially supported stock firmware can be downloaded from https://cdn-kobol-io.s3-ap-southeast-1.amazonaws.com/Helios64/SATA_FW/Helios64_SATA_FW_factory_00020_190702.img.xz. If there is no improvement on newer firmware, please revert back to this stock firmware.
SHA256SUM:
e5dfbe84f4709a3e2138ffb620f0ee62ecbcc79a8f83692c1c1d7a4361f0d30f *Helios64_SATA_FW_factory_00020_190702.img.xz 0d78fec569dd699fd667acf59ba7b07c420a2865e1bcb8b85b26b61d404998c5 *Helios64_SATA_FW_update_00021_200624.img.xz
-
It could be caused by power supply failure. Could you check the following thread ?
-
## Executing script at 09000000 Bad Linux ARM64 Image magic!
@scottf007, it could be filesystem corruption or something wrong during update and kernel symlink was not updated to correct file. If you have access to Linux PC, you can use recovery button to enter UMS mode and do fsck or fixed the symlink.
@wurmfood, it is not a problem. Rockchip loader expect the storage to be partitioned and formatted in certain way but it also can load using raw offset. Armbian does not use GPT, so the loader will print such errors.
-
On 4/10/2021 at 1:44 PM, clostro said:
However, I don't see where this script checks to see if mains power is active. What I see is a script that will continually shutdown the device if the battery voltage is low even when the mains returns. Is that function provided by the service timer, as in the timer stops when there is mains?
@SIGSEGV @clostro the service is triggered by udev rules.
@wurmfood, I didn't realize the timer fill the the log every 20s. Initial idea was one time timer, poweroff after 10m of power loss event. Then it was improved to add polling of the battery level and poweroff when threshold reached. Your script look good, we are considering to adapt it to official release. Thank you
-
-
bus-width 4 because of microsd card, not eMMC.
As we already put warning note on our wiki, it is not supported out of box, because it could break the system. There are several cards that are not compatible and show error during the test. When those card used as boot drive (for the test, Helios4 boot from USB drive), it won't boot.
Too risky to be included out of box.
IMO, the card and the host controller should try to use lower/normal speed if higher one failed. but we don't see such case during our test.
-
@jbergler could you modify /boot/armbianEnv.txt and add/modify following lines:
verbosity=7 console=serial extraargs=earlyprintk ignore_loglevel
It should make the serial console more verbose and output the systemd services to serial.
Could you also post a step by step to set up and reproduce the crash?
maybe also the detail of ZFS pool and HDD model and size.
-
-
@crosser please modify /boot/armbianEnv.txt and add/modify following lines:
verbosity=7 console=serial extraargs=earlyprintk ignore_loglevel
It should make the serial console more verbose.
mortomanos is referring to Armbian Device Tree Overlays
-
The bootloader (u-boot) is configured to try loading OS from SD card first, then if it failed, it will try internal eMMC.
5 hours ago, oneo said:If I do futz with jumpers I'll still be able to mount and write to the eMMC correct?
You need to remove the jumper just before Linux initialized, otherwise the eMMC would not be detected. More info on our wiki.
-
-
-
@qrthi it seems something wrong during writing to eMMC.
Your log show these lines
Wrong image format for "source" command SCRIPT FAILED: continuing...
How did you write the image? We recommend to use Etcher because it has write verification.
7 hours ago, qrthi said:I'm really dreading the idea that I have to take apart the chassis and jump the board so that I can boot from the sd card. I don't understand why the sd card wouldn't be before the emmc in Helios64's boot order.
The boot mode jumper only needed if for some reason the bootloader corrupted and to fix it you need to completely bypass the boot device.
If the bootloader (u-boot) just fine, it will load Armbian from the sdcard first.
QuoteHit any key to stop autoboot: 0
Card did not respond to voltage select!
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scrThe "Card did not respond to voltage select" is because you removed the sdcard.
If you put Armbian sdcard, the lines would be
Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 3185 bytes read in 6 ms (517.6 KiB/s) ## Executing script at 00500000 Boot script loaded from mmc 1
My suggestion,
1. Download latest Armbian image.
2. Since you already have u-boot on your eMMC, no need to download and write the helios64_sdcard_u-boot-only.img.xz into sdcard.
3. Power on and enter UMS recovery mode
4. Write the image using Etcher. No need to extract the image. Etcher can handle it just fine.
5. Reboot Helios64.
-
On 2/12/2021 at 7:33 PM, bunducafe said:
Also in the boot settings I only have two points left I can chose.
What do you mean?
Have you managed to get serial console working?
12 hours ago, bunducafe said:Bottom line: Is there a way to easily delete the emmc partition and tell the helios64 to boot from SD card immediately?
Have you checked our wiki?
-
@apocrypha, theoretically Helios4 could support USB gadget since the SoC support USB OTG at one of the USB controller, i forgot which one, upper or lower.
Unfortunately, Helios4 does not have circuitry to support this operation. Both of the USB is USB Host only.
If you're referring to the micro usb port, it is not part of the USB controller of the armada 388. it using external USB to Serial converter IC
-
-
On 2/10/2021 at 4:34 PM, Gareth Halfacree said:
The UUID itself is a universally unique identifier - that's what UUID means, after all. There are a wide range of scenarios where public knowledge of the UUID could be a problem, all absolutely vanishingly unlikely - think things like "state-level actors falsifying evidence about what data they found on a system and using their knowledge of the drive's UUID as 'proof' that the evidence was legitimately collected instead of just made up from whole cloth."
Given it takes a whopping four seconds to elide the UUID, and absence of the UUID has zero impact on diagnosing the problem, why wouldn't I keep it private?
Back on topic: I still haven't rebooted since the update. Would I be safe to do so, or shall I keep on truckin' until we're closer to figuring out the root cause of the issue?
Did you see any error during upgrade? If there is no error, then it should be safe to reboot.
On 2/11/2021 at 3:29 AM, slymanjojo said:Curious; What would be the suggested method to move my rootfs back to my SATA drive without reformatting
(currently ext4)?? basically go back to my initial config with boot on eMMC and rootfs on SATA.
Thanks in advance.
There is no automated method that i'm aware of.
You could modify the rootdev=UUID= to point to UUID of the SATA partition.
Modify /etc/fstab on the SATA drive, find line with /media/mmcboot , change the existing UUID to UUID of the eMMC
On 2/13/2021 at 3:43 AM, edraket said:Also having the same issue.
Is there a way to discover the UUID of the rootdev without the system being able to boot?
Running from SD card.
sudo blkid
use the value of UUID not PARTUUID
-
@Mydogboris the system could be encounter kernel crash.
Have you tried to limit the cpu speed and governor?
Change CPU governor to Performance, and optionally reduce the CPU speed to keep the system run cool.
armbian-config > System > CPU
Minimum CPU speed = 1200000
Maximum CPU speed = 1200000
CPU governor = performance
-
CURRENT branch (Linux Kernel 5.10) Feature Support Status Remarks Shutdown OK Reboot OK Suspend to RAM Not Supported USB host controller refuses to enter suspend mode 2.5G Ethernet
(2.5G speed)OK TX offload disabled by default, can be enabled for better performance
2.5G Ethernet
(1G speed)Performance issue Requires hardware fix.
Main Power/UPS status OK Status can be read from sysfs
Battery Charging OK Status can be read from sysfs UPS configuration
OK Auto shutdown after 10 min of power loss. USB Type C - Host OK use dwc3-0-host overlay. Enable P13 jumper to be able to use USB 2.0 device. USB Type C - Gadget OK use overlay to enable USB device mode. refer to this link USB Type C - DisplayPort OK eMMC Boot OK SPI Boot Not Supported Recovery Button OK To use maskrom, jumper P13 must be enabled. USB LED Not Supported usbport led trigger does not support activity and only works with USB 2.0 device LAN LED Supported default to eth0 activity Wake On LAN Not Supported Suspend still have issue Armbian 21.02
Note:
- UPS action will be changed into based on battery voltage threshold rather than countdown timer. (PR 2259)
- To change LAN LED network device, change eth0 on /etc/systemd/system/helios64-heartbeat-led.service at line 9 into eth1
-
@edwinistrator we did recommend the Debian maintainer to try the following tweak at that time,
QuoteHi Uwe,
Can you try to add the following in /etc/sysfs.conf
devices/system/cpu/cpufreq/policy0/scaling_min_freq = 1416000
devices/system/cpu/cpufreq/policy4/scaling_min_freq = 1800000
devices/system/cpu/cpufreq/policy0/scaling_max_freq = 1416000
devices/system/cpu/cpufreq/policy4/scaling_max_freq = 1800000Then reboot your system.
and according to Uwe, it does improve the stability.
On 2/6/2021 at 5:17 AM, edwinistrator said:I'm not sure whether the current Armbian kernel also does this
currently we still use the lower freq but we are considering to also disable those lower freq and maybe also disable DVFS (just use one fixed clock speed), since we received many instability reported and some has good outcome when cpu clock limited to 1200 MHz.
-
On 2/4/2021 at 10:26 PM, Lore said:
Here is a pastebin of me just pressing the reset button. Full unedited output.
It booted normally but I did notice that there was a FSCK that happened.
yes, it is expected since pressing the reset button will force the system reset and skip graceful shutdown procedure, which one of the step flaggging the filesystem as clean. therefore next boot will read the filesystem dirty and do fsck to checck if there is any corruption.
On 2/5/2021 at 9:00 PM, Lore said:So, it rebooted itself. Here is the reboot output.
[79083.780521] Unable to handle kernel paging request at virtual address 7bff0000f77baf8c [79083.781213] Mem abort info: [79083.781458] ESR = 0x96000004 [79083.781727] EC = 0x25: DABT (current EL), IL = 32 bits [79083.782189] SET = 0, FnV = 0 [79083.782457] EA = 0, S1PTW = 0 [79083.782733] Data abort info: [79083.782985] ISV = 0, ISS = 0x00000004 [79083.783319] CM = 0, WnR = 0 [79083.783580] [7bff0000f77baf8c] address between user and kernel address ranges [79083.784202] Internal error: Oops: 96000004 [#1] PREEMPT SMP [79083.784688] Modules linked in: softdog governor_performance rfkill quota_v2 quota_tree r8152 snd_soc_hdmi_codec hantro_vpu(C) zstd rockchip_rga rockchip_vdec(C) v4l2_h264 videobuf2_dma_contig leds_pwm videobuf2_vmalloc v4l2_mem2mem gpio_charger videobuf2_dma_sg panfrost snd_soc_rockchip_i2s pwm_fan rockchipdrm videobuf2_memops videobuf2_v4l2 snd_soc_core fusb302 gpu_sched tcpm dw_mipi_dsi snd_pcm_dmaengine typec videobuf2_common snd_pcm dw_hdmi analogix_dp drm_kms_helper snd_timer cec snd sg videodev rc_core soundcore mc drm drm_panel_orientation_quirks gpio_beeper cpufreq_dt zram nfsd auth_rpcgss nfs_acl lockd grace sunrpc ledtrig_netdev lm75 ip_tables x_tables autofs4 raid10 raid1 raid0 multipath linear raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx realtek md_mod dwmac_rk stmmac_platform stmmac mdio_xpcs adc_keys [79083.791149] CPU: 5 PID: 0 Comm: swapper/5 Tainted: G C 5.9.14-rockchip64 #20.11.4 [79083.791913] Hardware name: Helios64 (DT) [79083.792257] pstate: 80000085 (Nzcv daIf -PAN -UAO BTYPE=--) [79083.792753] pc : tick_sched_handle.isra.19+0xc/0x58 [79083.793179] lr : tick_sched_timer+0x58/0xb0 [79083.793543] sp : ffff800011b03e00 [79083.793833] x29: ffff800011b03e00 x28: 000047ed20604465 [79083.794298] x27: ffff0000f77baa40 x26: 0000000000000002 [79083.794761] x25: 0000000000000080 x24: ffff80001150f018 [79083.795225] x23: ffff80001183a1c8 x22: ffff800010147f20 [79083.795688] x21: ffff800011bcbdf0 x20: 000047ed206048f4 [79083.796151] x19: 7bff0000f77baf40 x18: 0000000000000000 [79083.796615] x17: 0000000000000000 x16: 0000000000000000 [79083.797078] x15: 0000000000000000 x14: 0000000000000000 [79083.797541] x13: 000000000000018c x12: 0000000000000000 [79083.798004] x11: 0000000000000040 x10: ffff80001185ea30 [79083.798468] x9 : ffff80001185ea28 x8 : ffff0000f6800270 [79083.798931] x7 : 0000000000000000 x6 : 000001ba05a22d6f [79083.799395] x5 : 00ffffffffffffff x4 : ffff8000e62a3000 [79083.799858] x3 : ffff80001183a000 x2 : 0000000000000004 [79083.800321] x1 : ffff800011bcbef8 x0 : 7bff0000f77baf40 [79083.800785] Call trace: [79083.801002] tick_sched_handle.isra.19+0xc/0x58 [79083.801399] tick_sched_timer+0x58/0xb0 [79083.801737] __hrtimer_run_queues+0x104/0x3b0 [79083.802118] hrtimer_interrupt+0xf4/0x250 [79083.802471] arch_timer_handler_phys+0x30/0x40 [79083.802861] handle_percpu_devid_irq+0xa0/0x2b8 [79083.803257] generic_handle_irq+0x30/0x48 [79083.803609] __handle_domain_irq+0x94/0x108 [79083.803977] gic_handle_irq+0xc8/0x170 [79083.804307] el1_irq+0xb8/0x180 [79083.804582] arch_cpu_idle+0x14/0x20 [79083.804897] do_idle+0x1fc/0x270 [79083.805181] cpu_startup_entry+0x24/0x60 [79083.805525] secondary_start_kernel+0x16c/0x180 [79083.805923] Code: d503201f d503233f a9bf7bfd 910003fd (39413002) [79083.806461] ---[ end trace 9432c2eec90ab0ec ]--- [79083.806864] Kernel panic - not syncing: Fatal exception in interrupt [79083.807419] SMP: stopping secondary CPUs [79083.807766] Kernel Offset: disabled [79083.808071] CPU features: 0x0240022,2000200c [79083.808444] Memory Limit: none [79083.808719] Rebooting in 90 seconds..Have you tried to limit the cpu speed and governor?
Change CPU governor to Performance, and optionally reduce the CPU speed to keep the system run cool.
armbian-config > System > CPU
Minimum CPU speed = 1200000
Maximum CPU speed = 1200000
CPU governor = performance
-
1 hour ago, lalaw said:
Do you have any idea why the gadget would present as such a small capacity?
i have no idea why. Initially i thought you were exporting just the partition but your next reply show you exported the whole array.
Any error or warning on Mac side?
20 minutes ago, lalaw said:sudo modprobe g_mass_storage file=/dev/sdf1 iManufacturer="Kobol Innovations" iProduct="Helios64" iSerialNumber="1234567890"
don't export just the partition (sdf1) but the whole disk (sdf). It does not have partition table.
eMMC errors after 5.10.60 update
in Rockchip
Posted
@mrjpaxton Yes, it is a known issue. Try the following workaround on the other thread