denni_isl

Hi folks, This is a bit strange. One core is constantly at 100% on a firefly-rk3399 board. It seems to be because of some emmc issues according to this output. journalctl -f This is htop

This did it! Did add - device_tree=/boot/dtb/rockchip/firefly-rk3399.dtb in armbianEnv.txt and start 20.02.7 kernel 5.4.28 from Mars 28 But it was not sufficient to bring up Armbian_20.08.1_Firefly-rk3399_focal_current_5.8.6.img ( do always clean the SD between the attempts with - dd if=/dev/zero of=/dev/sdc bs=4096 status=progress) This is a good reading about dtb and overlays - https://www.raspberrypi.org/documentation/configuration/device-tree.md

This image Armbian_20.02.7_Firefly-rk3399_bullseye_legacy_4.4.213 - legacy did work. Will try current next. And this is the messages from the serial output from ttyFIQ0 Current - Armbian_20.02.7_Firefly-rk3399_buster_current_5.4.28_desktop is not working, this is the output. Perhaps some issues with the dtb file with the current kernel as balbes150 did suggest.

This is the output And for comparison the image actually working - Armbian_19.11.7_Firefly-rk3399_bionic_legacy_4.4.208_desktop

balbes150, thank you for your effort. There is no more output from u-boot when using; setenv extraargs debug, setenv extraargs "debug ignore_loglevel" and setenv extraargs "debug initcall_debug"

How do i enable full log output mode?

Those partitions do always remain on the emmc; /dev/mmcblk1boot0 /dev/mmcblk1rpmb - (Replay Protected Memory Block) "information is always available to the authorized users" . This is probably they key of the vendors (manufacturers) ultimate power over the product. Some well-known use cases include software version authentication - This might be the case. "Secured: write protect can be enabled and disabled only for those who are authorized to use the RPMB." Boot partitions can be permanent, secured or power-on write protected.

Something similar to above commands might be the right way to bring it up coorectly. Might try something similar to those commands to try to get to the images on the sd card. How is it possible to obtain the correct addresses corresponding to those? setenv loadaddr "0x11000000" setenv dtb_loadaddr "0x1000000" setenv initrd_loadaddr "0x13000000" Got those messages from u-boot trying to boot Armbian_20.05.2_Firefly-rk3399_buster_current_5.4.43_desktop image, after - Starting kernel ..................

This is the boot messages from trying to boot Armbian_20.05.2_Firefly-rk3399_buster_current_5.4.43_desktop

There are always unallocated partitions left after emmc cleaning with blockthiscard /dev/mmcblk1rmp (unknown 4.2M)and /dev/mmcblkboot0 (read only 4.2M). It is like the vendor "firefly" is locking the hardware from the software (image) upgrade(?). and use ./upgrade_tool or rkdeveloptool to upload through usb otg - Btw. is there any way to open up the .img files from those partitions? Is the Vendor in control here? Did - dd if=/dev/zero of=/dev/mmcblk1 bs=4096 status=progress - the /dev/mmcblk1boot0 and /dev/mmcblk1rpmb are still there. - When booting from A

Yes, this is correct but it just recognizance the SD card as a medium not as a booting. If I update the SD card with v19.11.7 and and install it with armbian-config to emmc it will not boot again. If I install the v19.11.7 before doing apt update; apt upgrade update to the emmc and then it will bee a fully functional installation I do have a a SD image from 2017 that I can always boot up from though.

Did try this in u-boot and get error And this

This is a good summary of the most useful u-boot commands with some explanations https://docs.embeddedarm.com/U-boot_commands

Sorry, but I have limited experianse in using u-boot commands. What would be the correct way of starting the kernel with the correct dtb files from /dev/mmcblk1p1 in the /boot directory?

One point to notice. - Did the mistake of updating the installation card before the installation to emmc and that did not work. The upgrade should be done from emmc only.