usual user
-
Posts
481 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by usual user
-
-
2 hours ago, laibsch said:
Awesome! Please do elaborate.
Since the RK3399 U-Boot can use an HDMI display and a USB keyboard, I would simply configure a jumpstart option in the boot flow that mounts a different root filesystem. When booting, you just have to select this option.
If interacting with the firmware console is too complicated, the recovery system can be placed on a removable storage device. In this way, in case of need, only the rescue media needs to be connected and the system restarted; no firmware console access is required.
A completely firmware-controlled fallback mechanism is also possible, but it requires further special configuration of the firmware.2 hours ago, laibsch said:What is the cargo cult practiced here at Armbian?
Read this thread to understand what I mean by my statement.
-
Everything you wish for here is achievable with pure U-Boot technology. A long time ago, I tried to practice how to realize this here in the forum, but my lesson from it was:
You can't teach old dogs new tricks, and Armbian users want to celebrate their cargo cult and hope that it will magically fulfill their wishes.
-
1 hour ago, grixm said:
I don't think there is any storage device on the rock s0 other than the emmc that I can boot from.
If I have not researched incorrectly, the Rock Pi S0 has microSD, USB, and Ethernet to access external storage, but you have not provided any information about which options are available in your specific case.
-
On 8/27/2025 at 8:00 PM, grixm said:
need to flash a new image to the emmc.
On 8/27/2025 at 8:00 PM, grixm said:Is there a way to trigger rebooting into maskrom from software instead of pushing the button?
To replace an image on the eMMC, the MASKROM mode is not necessary. It is only required when the firmware is so damaged that it no longer works, but the signature is still intact and the MASKROM code still executes it.
To replace an image, it is sufficient to boot from a rootfs that is not on the eMMC and replace it from there.
And the good thing about it is that no device-specific hacks are necessary, just a properly configured bootflow. Furthermore, it is also self-contained, as no external devices with special software or other dependencies are necessary. It can also be automated in such a way that it runs unattended and the user only has to start the process initially. -
35 minutes ago, adron said:
my GC02M2 camera is a RAW sensor ➝ needs RK3566 ISP driver for usable output.
Then you know which part you can contribute to mainline support, otherwise you have to use the manufacturer's BSP, because that's what you paid for.
-
-
9 hours ago, H_Berger said:
i wonna boot from the emmc, so i have bought an little emmc module
IMHO this is a waste of money. In a device with NVME support, the advantages of an NVME SSD far outweigh those of an eMMC. The proprietary module interface also makes it difficult to use in other devices. And as a boot device for the firmware, it also offers no significant advantages over a microSD card.
In any case, I would prefer a microSD card as a boot device, simply because of the easier handling when, for example, experimenting with the firmware. Only when everything works perfectly can one think about using an eMMC, but only if it is already permanently built into the device and the microSD card slot is to be kept free for other tasks.9 hours ago, H_Berger said:so there should no hassle with the MASK-ROM, right ?
Only as long as there is no valid firmware signature in the SPI flash. Otherwise, firmware components will be loaded from there, and they may be able to load subsequent components (U-Boot) from other devices, but compatibility must be ensured.
To avoid this, one must clean the SPI flash or store their own firmware in the SPI flash.
However, since there is no way to fully test one's own firmware for functionality in advance, one may find oneself in a situation that requires a MASK-ROM recovery procedure.9 hours ago, H_Berger said:just trying to build mainline u-boot ragarding this: ttps://uthings.uniud.it/building-mainline-u-boot-and-linux-kernel-for-orange-pi-boards
I prefer to trust the official documentation.
-
Maybe my firmware build can replace Petitboot?
-
11 hours ago, H_Berger said:
with "firmware" you mean the "uboot - loader" mainly right ?
Exactly
11 hours ago, H_Berger said:I think this uboot version is lacking at least on nvme support, right ?
Since I don't know the build, I can't make any concrete statements about it.
11 hours ago, H_Berger said:Usually my plan was not to boot from nvme
It is also not possible under any circumstances, as the access procedures are far too complex to be meaningfully encoded in the MASK-ROM. As firmware devices, only SPI flash, MMC (eMMC, SD card), and USB with a proprietary protocol are available.
11 hours ago, H_Berger said:I have red somewhere that the actual released git branch of uboot has support for the orange pi 5 plus
so building a uboot from git would help here ?This is correct. I just quickly built this version out of curiosity. I was just about to provide the binary artifacts when I quickly took a look at the schematic of your device.
If I am not misinterpreting the schematic, your device only allows the fixed SPI-MMC-USB sequence and the forced immediate proprietary USB device. This means that you cannot execute the firmware completely from the microSD card, for example, if there is still a valid firmware signature in a device (SPI, eMMC) that is higher up in the priority list.
It is therefore essential that you are familiar with the USB recovery procedure (MASK-ROM-MODE), in case something goes wrong during the firmware experiments with the higher prioritized devices (SPI, eMMC). -
3 hours ago, H_Berger said:
what didd I miss ?
You are running with a broken firmware:
3 hours ago, H_Berger said:## Checking fdt 0x00354c30 ... sha256(e3b0c44298...) + OK fdt_record_loadable: FDT_ERR_BADMAGIC
3 hours ago, H_Berger said:No valid device tree binary found
Your version is also quite outdated:
3 hours ago, H_Berger said:U-Boot SPL 2017.09
A current firmware log looks like this:
SpoilerDDR ff1a08bde6 typ 25/03/13-15:39:39,fwver: v1.19 ch0 ttot6 ch1 ttot6 ch2 ttot6 ch3 ttot6 ch0 ttot7 LPDDR5, 2400MHz channel[0] BW=16 Col=10 Bk=16 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB ch1 ttot7 channel[1] BW=16 Col=10 Bk=16 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB ch2 ttot7 channel[2] BW=16 Col=10 Bk=16 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB ch3 ttot7 channel[3] BW=16 Col=10 Bk=16 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB Manufacturer ID:0x1 DQS rds:h1,h2,. CH0 RX Vref:29.3%, TX Vref:22.0%,21.0% DQ rds:h2 l0 h5 h2 h3 h2 h2 h5 ., h1 h1 h3 h5 h2 h1 h4 h2 DQS rds:h1,l0,. CH1 RX Vref:28.9%, TX Vref:22.0%,22.0% DQ rds:h3 h2 l1 h3 h4 l0 h3 h1 ., h3 l0 h5 h1 h1 l0 h1 l0 DQS rds:l0,l0,. CH2 RX Vref:28.5%, TX Vref:22.0%,22.0% DQ rds:h1 h1 h1 h4 l0 h1 h2 h1 ., h7 h5 h2 h1 h3 h1 l0 l0 DQS rds:l0,h1,. CH3 RX Vref:29.3%, TX Vref:22.0%,21.0% DQ rds:h6 h4 h2 h6 h2 h2 h3 h1 ., h5 h6 h4 h1 h7 h5 h2 h2 stride=0x2, ddr_config=0x6 hash ch_mask0-1 0x20 0x40, bank_mask0-3 0x0 0x2400 0x44800 0x89000, rank_mask0 0x2000 change to F1: 534MHz ch0 ttot6 ch1 ttot6 ch2 ttot6 ch3 ttot6 change to F2: 1320MHz ch0 ttot8 ch1 ttot8 ch2 ttot8 ch3 ttot8 change to F3: 1968MHz ch0 ttot6 ch1 ttot6 ch2 ttot6 ch3 ttot6 change to F0: 2400MHz ch0 ttot7 ch1 ttot7 ch2 ttot7 ch3 ttot7 out U-Boot SPL 2025.07 (Jul 11 2025 - 00:00:00 +0000) Trying to boot from MMC2 ## Checking hash(es) for config config-1 ... OK ## Checking hash(es) for Image atf-1 ... sha256+ OK ## Checking hash(es) for Image u-boot ... sha256+ OK ## Checking hash(es) for Image fdt-1 ... sha256+ OK ## Checking hash(es) for Image atf-2 ... sha256+ OK ## Checking hash(es) for Image atf-3 ... sha256+ OK NOTICE: BL31: v2.13.0(release): NOTICE: BL31: Built : 00:00:00, May 22 2025 U-Boot 2025.07 (Jul 11 2025 - 00:00:00 +0000) Model: Hardkernel ODROID-M2 SoC: RK3588S2 DRAM: 16 GiB PMIC: RK806 (on=0x80, off=0x08) Core: 382 devices, 35 uclasses, devicetree: separate MMC: mmc@fe2c0000: 1, mmc@fe2e0000: 0 Loading Environment from nowhere... OK In: serial@feb50000 Out: serial@feb50000 Err: serial@feb50000 Model: Hardkernel ODROID-M2 SoC: RK3588S2 Net: eth0: ethernet@fe1c0000 starting USB... USB EHCI 1.00 USB OHCI 1.0 USB EHCI 1.00 USB OHCI 1.0 Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 Bus usb@fc800000: 1 USB Device(s) found Bus usb@fc840000: 1 USB Device(s) found Bus usb@fc880000: 5 USB Device(s) found Bus usb@fc8c0000: 1 USB Device(s) found Bus usb@fcd00000: 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Cannot persist EFI variables without system partition *** U-Boot Boot Menu *** Press UP/DOWN to move, ENTER to select, ESC to quit Standard Boot NVME USB Mass Storage eMMC USB Mass Storage microSD USB Mass Storage Power Off mmc 1 mmc 0 nvme 0 Exit Hit any key to stop autoboot: 2 1 0 Scanning for bootflows in all bootdevs Seq Method State Uclass Part Name Filename --- ----------- ------ -------- ---- ------------------------ ---------------- Scanning global bootmeth 'efi_mgr': 0 efi_mgr ready (none) 0 <NULL> ** Booting bootflow '<NULL>' with efi_mgr Loading Boot0000 'mmc 1' failed Loading Boot0001 'mmc 0' failed Loading Boot0002 'nvme 0' failed EFI boot manager: Cannot load any image Boot failed (err=-14) Scanning bootdev 'mmc@fe2c0000.bootdev': 1 extlinux ready mmc 1 mmc@fe2c0000.bootdev.part /extlinux/extlinux.conf ** Booting bootflow 'mmc@fe2c0000.bootdev.part_1' with extlinux Jumpstart Boot Options 1: ODROID-M1/M2 default 2: ODROID-M1/M2 previous kernel 3: ODROID-M1/M2 verbose 4: Odroid-N2/N2+ default 5: Odroid-N2/N2+ previous kernel Enter choice: 1: ODROID-M1/M2 default Retrieving file: /usr/lib/modules/linux/vmlinuz append: loglevel=7 root=PARTUUID=75235836-01 consolee=ttyS02,1500000 console=tty0 rootwait rootfstype=ext4 Retrieving file: /usr/lib/modules/linux/dtb/rockchip/rk3588s-odroid-m2.dtb Uncompressing Kernel Image to 0 ## Flattened Device Tree blob at 12000000 Booting using the fdt blob at 0x12000000 Working FDT set to 12000000 Loading Device Tree to 00000000ece60000, end 00000000ece779b7 ... OK Working FDT set to ece60000 Starting kernel ...
-
4 hours ago, robertoj said:
[vd] Codec list:
[vd] libdav1d (av1) - dav1d AV1 decoder by VideoLAN
[vd] libaom-av1 (av1) - libaom AV1
[vd] av1 - Alliance for Open Media AV1
[vd] av1_cuvid (av1) - Nvidia CUVID AV1 decoder
[vd] Opening decoder libdav1d
[vd] No hardware decoding available for this codec.Just out of curiosity, you are trying to play content that is encoded in AV1.
Are you sure that your device is equipped with an AV1 decoder IP and that the kernel has the appropriate driver?
-
FWIW
rkvdec will be out of staging in 6.17Be prepared to forward-port existing out-of-tree patches.
cedrus has not seen much movement since a long time
It can therefore be assumed that all necessary out-of-tree modifications from the past must be applied even with the latest kernel version.
Since no mainline developments have taken place, no forward porting should be necessary. -
7 hours ago, ceri said:
What does the shutdown process to that could fix this?
It leaves the device with an intact file system.
The corrupted file system structure has likely been restored by rolling back the journal during the automatic file system check of the unmounted file system at system startup. But the data loss is permanent.
There is a reason why UPS systems exist. -
50 minutes ago, rosenrot00 said:
Thank you that worked.
I don't know your plans for how things are supposed to proceed. But if you plan to continue using my firmware build, I would suggest transferring it to the SPI flash, provided you are not wanted to use any other firmware in there.
- This relieves you from having to pay attention to restoring my firmware build when changing an image.
- You have two firmware versions available to you, between which you can switch with the SPI-MMC boot switch.
- Even without the eMMC module, you can boot an OS from another connected storage device.
- The U-Boot console is also available with an HDMI monitor and a USB keyboard and can be used for analysis in the event of startup problems. Of course, it is also used to select various boot options if autoboot is interrupted. -
21 minutes ago, rosenrot00 said:
Where would I have to place it?
Use:
dd bs=512 seek=1 conv=notrunc,fsync if=odroid-n2/u-boot-meson.bin of=/dev/${entire-device-to-be-used}as outlined in the referenced post to replace the existing firmware on the eMMC.
Firmare is residing outside of partition layout structures so you can only write it by absolute access.
-
26 minutes ago, rosenrot00 said:
Isn’t uboot coming with the armbian image on the emmc?
Certainly, but I don't know if anyone has taken the effort to integrate a current version so far.
27 minutes ago, rosenrot00 said:Could you tell me where I find the most recent uboot?
The mainline U-Boot project always provides the source codes for the latest versions.
You can build it by yourself with the Armbian build framework, or use my build for a quick test. -
6 hours ago, rosenrot00 said:
Would be nice to understand why it doesn't boot.
The log is telling that the firmware can't operate the eMMC:
6 hours ago, rosenrot00 said:Device 0: unknown device Card did not respond to voltage select! : -110
Furthermore, the alternatively attempted BOOTP and PXE boot are also unsuccessful because it seems that a server is found, but the necessary bootflow is not configured correctly.
As you are running a quite dated U-Boot, maybe using a cureent release has better support for the eMMC. -
On 5/24/2025 at 5:03 AM, TinaB said:
I try to get my NanoPC-T4 a second life.
My NanoPC-T4 is still alive:
Spoiler
For a quick test, I used my NVME with my latest OS, which usually powers a different SBC:
Spoiler
Please do not let it bother you that the NanoPC-T4 uses an outdated kernel to run the OS. This is due to my negligence in building the current kernel without the necessary hacks needed for proper HDMI functionality. Some of the hacks have now been proper implemented in mainline, while others are still in flight. Until this process is completed, I have decided out of laziness to temporarily use an outdated kernel, as I do not miss any functionalities that a current kernel could provide me.
On 5/24/2025 at 5:03 AM, TinaB said:the green blinking light indicates me, that he found no bootable device.
My status LED is not blinking at boot at all. To debug boot problems, blinking LEDs are the worst possible option. Only proper console logs are of value. During OS runtime, it is configured as an HDD LED to indicate access to the microSD, as this is important information for when it is safe to remove it.
On 5/24/2025 at 5:03 AM, TinaB said:The final solution should be that has the bootloader on the eMMC while the rest of the os should be on the SSD
I am still running my firmware from the microSD, again out of laziness to copy it to the eMMC. But any of nessesary support for the NanoPC-T4 is availabe and maybe some boring day or some spezial demand let me revisit to configure it properly. Until then, the bitrottining configuration is sufficient to serve more or less as an always-on terminal server for several USB serial adapters, which provide me with console access to my other SBCs if necessary.
-
8 hours ago, antatarmbian said:
But still I cannot boot the system after removing the sd-card.
EXIT to the U-Boot console and report the output of the following command:
bootflow scan -l nvme8 hours ago, antatarmbian said:I then did armbian-install -> nvme01 Install UEFI system
I don't know what the armbian-install does, but does it make a difference if you dd the same unmodified image to the NVME as you do to the microSD?
-
-
On 1/23/2025 at 8:09 PM, usual user said:
I'm currently at 6.13-rc1 and will stay there at least for another two weeks.
Ok, moved on to 6.14-rc1.
No regressions were observed, only current fixes were applied, and new features were enabled.
It may take some time for some of the fixes to trickle into new stable releases, but the new features are never officially backported.Moved on to 6.15-rc1 (boot-analyze-odroid-m1.pdf).
No regressions were observed, only current fixes were applied, and new features were enabled.
-
Ok, judging by your information, the regression takes place during the transition from U-Boot 2024.04 to 2024.07.
Since mainline U-Boot works perfect for me up to until 2025.01, it must be because of how it's built or what additional patches are applied.
Since it cannot be ruled out that it is due to a incompatible bootflow, it may be interesting to try it with my build.
If this also fails, it is possible to get more information from the HDMI output, even if access to the serial console is not available.
For the test it is perfectly sufficient to start the firmware from a prepared microSD card via RCY button.
The existing setup can stay completely unchanged. -
For me USB works as expected:
Spoiler/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 480M /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 001: Dev 002, If 0, Class=Mass Storage, Driver=uas, 5000M /: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 480M /: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 001: Dev 002, If 0, Class=Mass Storage, Driver=uas, 5000M /: Bus 005.Port 001: Dev 001, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 001: Dev 002, If 0, Class=Mass Storage, Driver=usb-storage, 480M /: Bus 006.Port 001: Dev 001, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 007.Port 001: Dev 001, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 002: Dev 003, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 002: Dev 003, If 1, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 002: Dev 003, If 2, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 003: Dev 004, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M |__ Port 004: Dev 005, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M /: Bus 008.Port 001: Dev 001, Class=root_hub, Driver=ohci-platform/1p, 12MI don't have any usbstoragequirks in place because my storage devices have controllers with properly working UAS support.
I'm currently at 6.13-rc1 and will stay there at least for another two weeks. -
2 hours ago, eselarm said:
SBC/embedded Linux does not have GRUB bootmanager by default, otherwise that would be the way to select older kernel.
But I'm grateful that it also works for me with pure U-boot:
SpoilerU-Boot SPL 2025.01 (Jan 16 2025 - 00:00:00 +0000) Trying to boot from SPI ## Checking hash(es) for config config-1 ... OK ## Checking hash(es) for Image atf-1 ... sha256+ OK ## Checking hash(es) for Image u-boot ... sha256+ OK ## Checking hash(es) for Image fdt-1 ... sha256+ OK ## Checking hash(es) for Image atf-2 ... sha256+ OK NOTICE: BL31: v2.12.0(release): NOTICE: BL31: Built : 00:00:00, Nov 27 2024 NOTICE: BL31: Rockchip release version: v1.0 U-Boot 2025.01 (Jan 16 2025 - 00:00:00 +0000) Model: Hardkernel ODROID-M1 SoC: RK3568B2 DRAM: 8 GiB (effective 7.7 GiB) PMIC: RK809 (on=0x80, off=0x08) Core: 324 devices, 37 uclasses, devicetree: separate MMC: mmc@fe2b0000: 1, mmc@fe310000: 0 Loading Environment from nowhere... OK In: serial,usbkbd Out: serial,vidconsole Err: serial,vidconsole Model: Hardkernel ODROID-M1 SoC: RK3568B2 Net: eth0: ethernet@fe2a0000 starting USB... Bus usb@fd000000: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 Bus usb@fd800000: USB EHCI 1.00 Bus usb@fd840000: USB OHCI 1.0 Bus usb@fd880000: USB EHCI 1.00 Bus usb@fd8c0000: USB OHCI 1.0 scanning bus usb@fd000000 for devices... 1 USB Device(s) found scanning bus usb@fd800000 for devices... 2 USB Device(s) found scanning bus usb@fd840000 for devices... 1 USB Device(s) found scanning bus usb@fd880000 for devices... 5 USB Device(s) found scanning bus usb@fd8c0000 for devices... 1 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found scanning bus for devices... SATA link 0 timeout. AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp fbss pio slum part ccc apst Card did not respond to voltage select! : -110 Card did not respond to voltage select! : -110 Cannot persist EFI variables without system partition *** U-Boot Boot Menu *** Press UP/DOWN to move, ENTER to select, ESC to quit Standard Boot NVME USB Mass Storage SCSI USB Mass Storage eMMC USB Mass Storage microSD USB Mass Storage Power Off usb 0 mmc 1 nvme 0 Exit Hit any key to stop autoboot: 2 Hit any key to stop autoboot: 1 Scanning for bootflows in all bootdevs Seq Method State Uclass Part Name Filename --- ----------- ------ -------- ---- ------------------------ ---------------- Scanning global bootmeth 'efi_mgr': 0 efi_mgr ready (none) 0 <NULL> ** Booting bootflow '<NULL>' with efi_mgr Loading Boot0000 'usb 0' failed Loading Boot0001 'mmc 1' failed Loading Boot0002 'nvme 0' failed EFI boot manager: Cannot load any image Boot failed (err=-14) Scanning bootdev 'mmc@fe2b0000.bootdev': 1 extlinux ready mmc 1 mmc@fe2b0000.bootdev.part /extlinux/extlinux.conf ** Booting bootflow 'mmc@fe2b0000.bootdev.part_1' with extlinux Boot Options 1: ODROID-M1 40000015-01 2: ODROID-M1 50000006-01 3: NanoPC-T4 40000015-01 4: NanoPC-T4 40000015-01 verbose 5: NanoPC-T4 40000015-01 previous 6: Odroid-N2+ 40000015-01 7: Odroid-N2+ 40000015-01 verbose 8: Odroid-N2+ 40000015-01 previous 9: Odroid-N2+ SPI NOR 40000015-01 10: ODROID-M1 40000015-01 verbose 11: ODROID-M1 40000015-01 previous 12: ODROID-M1 40000015-01 previous verbose Enter choice: 1: ODROID-M1 40000015-01 Retrieving file: /usr/lib/modules/linux/vmlinuz append: loglevel=4 root=PARTUUID=40000015-01 coherent_pool=2M console=ttyS02,1500000 console=tty0 rootwait Retrieving file: /usr/lib/modules/linux/dtb/rockchip/rk3568-odroid-m1.dtb Uncompressing Kernel Image to 0 ## Flattened Device Tree blob at 12000000 Booting using the fdt blob at 0x12000000 Working FDT set to 12000000 Loading Device Tree to 00000000eae82000, end 00000000eae94200 ... OK Working FDT set to eae82000 Starting kernel ...
Separate boot partition and different root partitions → simple man’s A+B update possible?
in Beginners
Posted
Oh, sorry, I didn't notice the non-existent 6 and read it as Helios64.
Of course, my description of the boot method is not limited to Rockchip devices; it works on all for which a mainline U-Boot is available. I have used it on iMX6, LX2160A and S922X devices, but my remaining devices are all based on Rockchip.
The solutions are too varied to present a turnkey solution here. However, I am sure that only a corresponding configuration for implementation is required to achieve the desired behavior, but for that, the U-Boot documentation must be consulted to decide which solution should be chosen.