djurny
-
Posts
110 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by djurny
-
-
Hi all,
If anyone is interested, I have a Helios64 backup battery pack lying around that I did order back in the day, but never got around to installing/using it. (Have a separate UPS.) From my guess this thing is <6 years old, but again, never seen any charge or discharge.
PM me when interested.
Groetjes,
PS Available for pickup in the San Jose, Bay Area, CA (USA) or can send domestically thru USPS.
-
Hi,
If you are having trouble sourcing a proper serial dongle, you could also try to set (or cap) the serial console's baudrate yourself in armbianEnv.txt.
Use/replace the following:
console=comfort extraargs=console=ttyS2,115200 earlyprintk=ttyS2,115200This should prevent your bootscript from setting the kernel's serial baudrate to 1M5 and at least give you some kernel logging during booting. Not sure if the login prompt will follow the same baudrate, as `getty` (or one of it's variants) might use different default settings.
Groetjes,
-
Hi,
Not an expert here, but some educated guesses would be related to either timing, blocksizes towards the devices. Anything that might change or increase the amount of ATA commands towards the disks would be my bet to look at. You could experiment with enabling/disabling NCQ, reducing read-ahead, increasing chunksizes in case you use [software] RAID, increasing caching by tweaking vm options. Perhaps even the IO schedulers, there might have been some new IO schedulers introduced on the new kernel that show different behavior compared to the older kernel, etc.
Groetjes,
-
Hi,
If you want to know which kernel is used for your build, just run:
./compile.sh inventory-boardsThis will take some time.
Open the resulting .csv file, which will contain all combinations possible.
Groetjes,
-
Hi,
Did you also make sure that you copy any ata options from your old installation? e.g. For my own Helios64 I have had similar issues and those were resolved by limiting the SATA link speed to 3Gbps:
extraargs=libata.force=1:3.0G,2:3.0G,3:3.0G,4:3.0GThe internets say that those ATA errors are caused by the the disk not responding to a controller request in time. Mostly it is advised to replace the [S]ATA cables and to make sure contacts are clean and no crosstalk/EMI can occur. A reduction in the ATA link speed also helps, which in my case sure did.
Do keep in mind, that if you have regular spinning drives, the most throughput you will get out of your drives will be around 100~140 MB/s, which translates to roughly 1.5 Gb/s. So decreasing the linkspeed will not cause any slowdown, your drive's throughput will remain the performance bottleneck.
For my Helios64, I have had some issues with the left-most (or top) disk, as the connectors did not protrude well enough, or had a little too much flex which caused the left-most disk from sometimes not being detected at all. Reseating and pressing on the connector from the rear helped that issue.
As the internets mention these errors are the ATA driver complaining about not hearing from the drive(s) in time (or at all), you might want to experiment with a lower CPU frequency, or perhaps not using any of the dynamic freq scaling governors, but sticking to the powersave or performance one.
Groetjes,
-
Hi @zital debian,
Some things you could also try:
- Replace cables - again. I've had similar issues where the NIC of SBC would drop to 10Mbe half duplex, persistently after using different cables. In the end it was all the cables i had lying around that were not of good quality. Replaced the cat "5e" ones with cat 6 and the issues went away.
- Disable autoneg on your NIC or only advertise 1Gbe.
- Try a different switch port, switch or router.
- Check if you have some of those green options on your router/switch enabled, i think it's called EEE. I had some issues with and my Orangepi zero SBCs in combination with those bad cat "5e" ethernet cables.
Groetjes,
-
-
Hi @loeriver,
Check your serial console, as sending a serial <BRK> will trigger the Magic Sysrq sequence.
For example, using `tio` to connect to a serial console, I can invoke the Magic Sysrq help test with <ctrl>-t + B + <enter>.
Perhaps your serial port has it's RX line shorted to ground?
Groetjes,
-
Hi @Werner,
Not to pick nits, but 7 is the highest level (lowest priority) you can give a printk() statement. To make them appear however, the loglevel of the printk() needs to be smaller than the loglevel of the console, meaning the [console] loglevel needs to be 7+1:
loglevel= [KNL,EARLY] All Kernel Messages with a loglevel **smaller** than the console loglevel will be printed to the console. It can also be changed with klogd or other programs. The loglevels are defined as follows:Also, the following text also steers into the direction of using 8 instead of 7 to show all printk() messages:
To change the current console_loglevel simply write the desired level to ``/proc/sys/kernel/printk``. For example, to print all messages to the console:: # echo 8 > /proc/sys/kernel/printk(Taken from https://www.kernel.org/doc/Documentation/core-api/printk-basics.rst.)
Grt,
-
Hi @gyrex,
You might want to try without the fstab entry for your root filesystem:
UUID=024728b4-7d81-4433-8476-0f98407d1481 / ext4 defaults,noatime,commit=600,errors=remount-ro 0 1and add the following to your armbianEnv.txt.
extraargs=rwThe fstab entry for your rootfs is there to remount your rootfs with some options, it is not there to actuall mount it - that's already done by the rootdev/rootfstype in your kernel commandline.
or: change the last digit from 1 to 0 in the fstab entry for your rootfs to prohibit fsck during boot.
Hopefully that would allow the system to complete it's boot and make room for some live troubleshooting.
Thx,
Groetjes,
-
Hi @Carlos Hartmann,
Backups of anything are a good thing. So my advise would be to always keep the ISOs you downloaded somewhere 'safe'. Not that safe that you will forget where you stashed it of course (looking at you @djurny...).
Groetjes,
-
Hi @Vodalex,
Write down the MAC address of the interface you want to use to wake up the Helios4.
ip link showYou would need to put the Helios4 in suspend, by either:
sudo pm-suspendor:
echo 'suspend' | sudo tee /sys/power/stateTo wake it up, from another system, make sure that wakeonlan is installed. Then:
wakeonlan ${HARDWARE_ADDRESS}That should be it.
Groetjes,
-
Hi there,
I think what would be next is to try an older image to see if the serial console and hardware itself are still working.
If you're interested, I still have a version here locally: Armbian_20.08.10_Helios64_buster_current_5.8.14.img.xz.
Groetjes,
-
Hi there,
Some notes from my side, with the image we are now both trying out, I do have some issues every other boot. Seems that the kernel gets stuck at:
[ 19.941334] amba ff6d0000.dma-controller: deferred probe pending: (reason unknown) [ 19.942069] amba ff6e0000.dma-controller: deferred probe pending: (reason unknown) [ 19.942765] platform ff1d0000.spi: deferred probe pending: (reason unknown) [ 19.943404] platform ff1e0000.spi: deferred probe pending: (reason unknown) [ 19.944042] platform ff200000.spi: deferred probe pending: (reason unknown)No idea why. This seems to alternate every other boot, so after a reboot this appears to be tolerated, but the next reboot the kernel gets stuck again. And stuck in like magic sysrq stops working.
Make sure you have verbosity=8 in your armbianEnv.txt, to make sure some (read: more) output is generated on the console.
Groetjes,
-
Hi,
Just to baseline some stuff:
- The baudrate you use in screen, it's set to 1.500.000 ?
-
Did the serial cable work before? Or is this the first time you use a C-C cable?
I know too little about the differences of C-C vs A-C cables, but if this is the first time using the C-C cable, please try to use A-C with some Mac-to-A hub. I can only confirm an A-C cable works here. -
Are you sure that the connector of the C end at the Helios64 side is making proper contact?
In my (and other's case) the actual plug part did not fully pass through the case. I had to cut some of the plastic away of the C side to expose more of the actual connector. This way it fully entered the case and made better contact with the board. Not sure if I'm explaining this well or not, let me know if this is not clear. - Is there anything on your Mac side that is trying to automatically mount the card while you are writing the image?
-
Are you sure the entire image was written to the SDcard?
e.g. Did you use conv=fsync for dd ? Or a sync before removing the SDcard? (There is no umounting happening as the card could not be mounted you mentioned.) -
Did you try and sha256 sum the SDcard contents as well?
You should be able to do that (slowly) with
dd if=/dev/sdcard bs=1 count=$(stat -c '%s' Bookworm_current_minimal) | sha256sum
Make sure to remove the card first and reinsert it to avoid dd is reading cache.
Grt,
-
Hi,
Curious what the result is of "parted u s pr" on the unxz'd image?
As for the tools you mentioned, the basics like dd or even unxz'ing directly onto your device are a safe bet. I like to see what's going on and add sauce myself when needed.
In addition to that, can you share the sha256sum of the unxz'd image file? I'm getting:
djurny@ekspiees:~/Downloads$ sha256sum Bookworm_current_minimal 6a28d5e6af0eb3ab3f534a14f2f2092633397092e7032bf0f82621fea58194d7 Bookworm_current_minimalAlso, try to loop-mount the image file to check if the contents are readable:
First check the offset of the first partition in amount of sectors:
djurny@ekspiees:~/Downloads$ parted Bookworm_current_minimal u s pr WARNING: You are not superuser. Watch out for permissions. Model: (file) Disk /home/djurny/Downloads/Bookworm_current_minimal: 2646016s Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 32768s 2646015s 2613248s primary ext4Mount the image:
djurny@ekspiees:~/Downloads$ mkdir /tmp/image djurny@ekspiees:~/Downloads$ sudo mount -o loop,offset=$((512 * 32768)) Bookworm_current_minimal /tmp/image [sudo] password for djurny: 2444666666 djurny@ekspiees:~/Downloads$ ls -Failh /tmp/image/boot/ total 63M 32709 drwxr-xr-x 3 root root 4.0K Nov 24 2024 ./ 2 drwxr-xr-x 19 root root 4.0K Nov 24 2024 ../ 29474 -rw-r--r-- 1 root root 0 Nov 24 2024 .next 29472 lrwxrwxrwx 1 root root 33 Nov 24 2024 Image -> vmlinuz-6.6.62-current-rockchip64 29475 -rw-r--r-- 1 root root 4.9M Nov 17 2024 System.map-6.6.62-current-rockchip64 29476 -rw-r--r-- 1 1005 1005 130 Nov 24 2024 armbianEnv.txt 29477 -rw-r--r-- 1 root root 38K Nov 24 2024 boot.bmp 29478 -rw-r--r-- 1 1005 1005 3.8K Nov 24 2024 boot.cmd 29479 -rw-rw-r-- 1 root root 3.9K Nov 24 2024 boot.scr 29480 -rw-r--r-- 1 root root 243K Nov 17 2024 config-6.6.62-current-rockchip64 29473 lrwxrwxrwx 1 root root 29 Nov 24 2024 dtb -> dtb-6.6.62-current-rockchip64/ 32710 drwxr-xr-x 3 root root 4.0K Nov 24 2024 dtb-6.6.62-current-rockchip64/ 29669 -rw-r--r-- 1 root root 15M Nov 24 2024 initrd.img-6.6.62-current-rockchip64 29672 lrwxrwxrwx 1 root root 33 Nov 24 2024 uInitrd -> uInitrd-6.6.62-current-rockchip64 29671 -rw-r--r-- 1 root root 15M Nov 24 2024 uInitrd-6.6.62-current-rockchip64 29481 -rw-r--r-- 1 root root 29M Nov 17 2024 vmlinuz-6.6.62-current-rockchip64 djurny@ekspiees:~/Downloads$After dd'ing the image to an SDcard, I was able to boot my Helios64 successfully:
djurny@ekspiees:~/Downloads$ sudo dd if=Bookworm_current_minimal of=/dev/mmcblk0 conv=fsync status=progressSpoilerDDR Version 1.24 20191016 In soft reset SRX channel 0 CS = 0 MR0=0x18 MR4=0x2 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x18 MR4=0x2 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! change freq to 416MHz 0,1 Channel 0: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB Channel 1: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB 256B stride channel 0 CS = 0 MR0=0x18 MR4=0x2 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x18 MR4=0x2 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! channel 0, cs 0, advanced training done channel 1, cs 0, advanced training done change freq to 856MHz 1,0 ch 0 ddrconfig = 0x101, ddrsize = 0x40 ch 1 ddrconfig = 0x101, ddrsize = 0x40 pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD ddr_set_rate to 328MHZ ddr_set_rate to 666MHZ ddr_set_rate to 928MHZ channel 0, cs 0, advanced training done channel 1, cs 0, advanced training done ddr_set_rate to 416MHZ, ctl_index 0 ddr_set_rate to 856MHZ, ctl_index 1 support 416 856 328 666 928 MHz, current 856MHz OUT Boot1: 2019-03-14, version: 1.19 CPUId = 0x0 ChipType = 0x10, 323 SdmmcInit=2 0 BootCapSize=100000 UserCapSize=14910MB FwPartOffset=2000 , 100000 mmc0:cmd5,20 SdmmcInit=0 0 BootCapSize=0 UserCapSize=30528MB FwPartOffset=2000 , 0 StorageInit ok = 65838 SecureMode = 0 SecureInit read PBA: 0x4 SecureInit read PBA: 0x404 SecureInit read PBA: 0x804 SecureInit read PBA: 0xc04 SecureInit read PBA: 0x1004 SecureInit read PBA: 0x1404 SecureInit read PBA: 0x1804 SecureInit read PBA: 0x1c04 SecureInit ret = 0, SecureMode = 0 atags_set_bootdev: ret:(0) GPT 0x3380ec0 signature is wrong recovery gpt... GPT 0x3380ec0 signature is wrong recovery gpt fail! LoadTrust Addr:0x4000 No find bl30.bin No find bl32.bin Load uboot, ReadLba = 2000 Load OK, addr=0x200000, size=0xdcfd8 RunBL31 0x40000 NOTICE: BL31: v1.3(debug):42583b6 NOTICE: BL31: Built : 07:55:13, Oct 15 2019 NOTICE: BL31: Rockchip release version: v1.1 INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3 INFO: Using opteed sec cpu_context! INFO: boot cpu mask: 0 INFO: plat_rockchip_pmu_init(1190): pd status 3e INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK ERROR: Error initializing runtime service opteed_fast INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x200000 INFO: SPSR = 0x3c9 U-Boot 2020.07-armbian (Oct 13 2020 - 16:49:59 +0200) SoC: Rockchip rk3399 Reset cause: RST DRAM: 3.9 GiB PMIC: RK808 SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB MMC: mmc@fe320000: 1, sdhci@fe330000: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Model: Helios64 Revision: 1.2 - 4GB non ECC Net: eth0: ethernet@fe300000 scanning bus for devices... Hit any key to stop autoboot: 0 => run bootcmd switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 3906 bytes read in 7 ms (544.9 KiB/s) ## Executing script at 00500000 Boot script loaded from mmc 1:1 130 bytes read in 6 ms (20.5 KiB/s) 15073177 bytes read in 644 ms (22.3 MiB/s) 30097920 bytes read in 1281 ms (22.4 MiB/s) 88353 bytes read in 19 ms (4.4 MiB/s) 2825 bytes read in 15 ms (183.6 KiB/s) Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 09000000 Trying kaslrseed command... Info: Unknown command can be safely ignored since kaslrseed does not apply to all boards. Unknown command 'kaslrseed' - try 'help' ## Loading init Ramdisk from Legacy Image at 06000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 15073113 Bytes = 14.4 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Ramdisk to f5086000, end f5ee5f59 ... OK Loading Device Tree to 00000000f5008000, end 00000000f5085fff ... OK Starting kernel ... helios64 login: root (automatic login) Last login: Sun Jun 1 18:24:17 UTC 2025 on tty1 Waiting for system to finish booting ... /usr/lib/armbian/armbian-firstlogin: line 662: /sys/class/graphics/fb0/virtual_size: No such file or directory Welcome to Armbian! Documentation: https://docs.armbian.com | Community support: https://forum.armbian.com IP address: 192.168.2.36 Create root password:It all seems to work? So my guess is something is going wrong with either the image file you have downloaded or the writing to the SDcard...
Grt,
-
Hi there,
Some things you might want to check or confirm:
Quote- After flashing via `dd`, macOS warns “Cannot initialize disk” — I believe this is expected.
I would expect that your OS would detect a new disk with one partition called armbi_root. Are you confident that you have used the correct image?
If you are using wget to download an image from the main site's download area (https://www.armbian.com/helios64/) https://dl.armbian.com/helios64/Bookworm_current_minimal, do note that this will download Bookworm_current_minimal, which is actually an .xz image! You need to rename it to .xz and then unxz it to your SDcard. You cannot just dd that as that won't work.
djurny@ekspiees:~/Downloads$ wget https://dl.armbian.com/helios64/Bookworm_current_minimal --2025-06-01 08:12:51-- https://dl.armbian.com/helios64/Bookworm_current_minimal Resolving dl.armbian.com (dl.armbian.com)... 152.53.81.238 Connecting to dl.armbian.com (dl.armbian.com)|152.53.81.238|:443... connected. HTTP request sent, awaiting response... 302 Found Location: https://armbian.chi.auroradev.org/dl/helios64/archive/Armbian_24.11.1_Helios64_bookworm_current_6.6.62_minimal.img.xz [following] --2025-06-01 08:12:52-- https://armbian.chi.auroradev.org/dl/helios64/archive/Armbian_24.11.1_Helios64_bookworm_current_6.6.62_minimal.img.xz Resolving armbian.chi.auroradev.org (armbian.chi.auroradev.org)... 23.186.112.5, 2602:fc41::5 Connecting to armbian.chi.auroradev.org (armbian.chi.auroradev.org)|23.186.112.5|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 251530384 (240M) [application/x-xz] Saving to: 'Bookworm_current_minimal' Bookworm_current_minimal 100%[==========================================================================>] 239.88M 24.2MB/s in 10s 2025-06-01 08:13:02 (23.6 MB/s) - 'Bookworm_current_minimal' saved [251530384/251530384] djurny@ekspiees:~/Downloads$ ls -l Bookworm_current_minimal -rw-rw-r-- 1 djurny djurny 251530384 Nov 24 2024 Bookworm_current_minimal djurny@ekspiees:~/Downloads$ file Bookworm_current_minimal Bookworm_current_minimal: XZ compressed data, checksum CRC64 djurny@ekspiees:~/Downloads$Are you running any disks in your Helios64? When I was testing/playing around with my Helios64 and rebooting a lot, I decided to take out some disks to prevent them from being stopped/started all the time. This led to random stalls in the OS reaching console login. After reinserting all disks this went away.
Also, just to be clear where I'm coming from: I'm also still running Buster (5.9.13-rockchip64 #trunk.16) on my Helios64. Did not yet spend any time to go for Bookworm fully.
Groetjes,
-
-
Testing on Nanopi R2S revealed that U-Boot there does not have setexpr built-in. I expect it will be the same on the 'Rock64' board you have?
To make sure - as I do not have your hardware here - can you check if the following commands work on your U-Boot monitor commandline:
setenv b setenv c setenv a "a/b" setexpr b sub "a/" "" a echo ${b} setexpr c 1 + 1 echo ${c} fdtAlso, to give a workaround (hopefully), the output of the following on the U-Boot monitor commandline:
echo ${fdtfile} echo ${fdt_addr_r} echo ${kernel_addr_r} echo ${ramdisk_addr_r} verThx,
Groetjes,
-
Hi there,
Ok, after some walking back and forth, typos, reboots, rewriting entire images, multiple armbianEnv.txt files, looking into U-Boot sources, googling (of course) I managed to find some things and got U-Boot on my Helios64 to boot properly again.
In short, the aarch64 requirements to the linux kernel, the way U-Boot sometimes will move the loaded kernel image in memory might overwrite the starting point of the inital ramdisk. The load addresses for kernel and initial ramdisk are mostly hardcoded in U-Boot but can be overridden by armbianEnv.txt or the bootscript.
SpoilerNOTICE: BL31: v1.3(debug):42583b6 NOTICE: BL31: Built : 07:55:13, Oct 15 2019 NOTICE: BL31: Rockchip release version: v1.1 INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3 INFO: Using opteed sec cpu_context! INFO: boot cpu mask: 0 INFO: plat_rockchip_pmu_init(1190): pd status 3e INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK ERROR: Error initializing runtime service opteed_fast INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x200000 INFO: SPSR = 0x3c9 U-Boot 2020.07-armbian (Oct 13 2020 - 16:49:59 +0200) SoC: Rockchip rk3399 Reset cause: RST DRAM: 3.9 GiB PMIC: RK808 SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB MMC: mmc@fe320000: 1, sdhci@fe330000: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Model: Helios64 Revision: 1.2 - 4GB non ECC Net: eth0: ethernet@fe300000 scanning bus for devices... 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 13115 bytes read in 6 ms (2.1 MiB/s) ## Executing script at 00500000 Boot script loaded from mmc 1:1 636 bytes read in 5 ms (124 KiB/s) Imported environment (/boot/armbianEnv.txt) from mmc 1:1 to 0x9000000 Using version override -6.12.30-current-rockchip64 for image loading var_fdtfile=rk3399-kobol-helios64.dtb 90448 bytes read in 13 ms (6.6 MiB/s) Loaded DT (/boot/dtb-6.12.30-current-rockchip64/rockchip/rk3399-kobol-helios64.dtb) from mmc 1:1 to 0x01f00000 2825 bytes read in 9 ms (305.7 KiB/s) ## Executing script at 09000000 Sourced fixup script (/boot/dtb-6.12.30-current-rockchip64/rockchip/overlay/rockchip-fixup.scr) from mmc 1:1 to 0x9000000 38007296 bytes read in 1617 ms (22.4 MiB/s) Loaded kernel (/boot/Image-6.12.30-current-rockchip64) from mmc 1:1 to 2000000 Using kernel text_offset 0x0 bytes to calculate initial ramdisk load address Using kernel image_size 0x2520000 bytes to calculate initial ramdisk load address 17515242 bytes read in 747 ms (22.4 MiB/s) Loaded initial ramdisk (/boot/uInitrd-6.12.30-current-rockchip64) from mmc 1:1 to 4600000 Trying kaslrseed command... Info: Unknown command can be safely ignored since kaslrseed does not apply to all boards. Unknown command 'kaslrseed' - try 'help' Kernel commandline arguments: root=UUID=8ac95870-8815-4816-82da-6664b846fc34 rootfstype=f2fs rootwait splash=verbose console=ttyS2,1500000 console=tty1 consoleblank=0 loglevel=8 ubootpart=21825e31-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u,0x174c:0x1053:u rw net.ifnames=0 libata.force=1:3.0G,2:3.0G,3:3.0G,4:3.0G ipv6.disable=1 cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory ## Loading init Ramdisk from Legacy Image at 04600000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 17515178 Bytes = 16.7 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Ramdisk to f4e32000, end f5ee62aa ... OK Loading Device Tree to 00000000f4e18000, end 00000000f4e31fff ... OK Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]As Helios64 uses Rockchip rk3399 from the aarch64 family, the attached boot.scr might also work for you.
This bootscript will only work on aarch64 systems, as it assumes the kernel is uncompressed!
If you test this, make sure to make a backup of your existing boot.scr or read up on how to regenerate the boot.scr from your boot.cmd.
- Make sure you have serial console available
- Copy the attached bootscript to /boot
- Add verbosity=1 (if not already there) to your armbianEnv.txt
- Reboot
Would be great that if you test, to share the serial console output here to see it it also works for you.
I will also test and verify on one of my Nanopi R2Ss somewhere today or tomorrow.
Will put all the details into a pull request.
Groetjes,
Update: Removed boot.scr as testing on Nanopi R2S showed some misbehavior.
-
Hi there,
I'm seeing the same while trying to update some U-Boot bootscripts on my Helios64 (rockchip aarch64). Seems there needs to be more space between $kernel_load_addr_r and $ramdisk_addr_r. How much is a bit puzzling, as for other archs it's usually enough to count the kernel's image size (and some alignment).
If i come across something interesting, I will share here too.
Groetjes,
-
I also have some oom issues when doing an aptitude upgrade in my opizero w/256 MiB ram. Guess even more on a 128MiB board like yours.
Best to add a swap file to make sure upgrades go without issue.
Grt,
-
Little odd that it fails to load the fix up script there;
QuoteFailed to load '/boot/dtb/overlay/sun8i-v3s-fixup.scr'
In the old boot.cmd it checks if it can find the file and loads it if it can.
Can you share a serial console log of the 21.x release that did work? Incl aembianmonitor -u output?
Thx,
Grt,
-
Hi @Zaf9670,
Your situation actually helped find an OBOE in the U-Boot image overlap test, so thank you for that!
Can you try with an older image and share the U-Boot output? Also, can you add the following in your armbianEnv.txt:
verbosity=8 earlycon=on console=serialI've had better experience with setting console to serial only and earlycon might help the kernel spew out some things earlier on.
Groetjes,
kernel: ... sysrq: HELP messages in log
in Allwinner sunxi
Posted
Hi Loeriver,
Where is the other end of your USB serial dongle connected to? Can you check there if the dongle had disappeard from the USB bus and re-appeared around the same time?
In my "professional" life we have had workstations mysteriously reboot whenever we would power cycle the device hosting the USB to serial device.
Even though you say it's not related, if this is still mysterious, best to check under each stone...
Groetjes,