CeeGO Posted June 4, 2022 Share Posted June 4, 2022 I've tried the latest CLI and GUI images. I tried different microSD cards but the result is the same. Both images get to Booting using the fdt blob and never progress. Is there anything I can try to get this working? 0 Quote Link to comment Share on other sites More sharing options...
AxelFoley Posted June 20, 2022 Share Posted June 20, 2022 No you are not the only person. The Image is screwed and wont boot when flashed to eMMC. It boots from SD. I'm looking into the problem now. 0 Quote Link to comment Share on other sites More sharing options...
AxelFoley Posted June 20, 2022 Share Posted June 20, 2022 Happens on both the CLI and GUI Desktop Images tried flashing in Rufus and Etcher It simply dose not work on eMMC .... so I don't know how this could get released without the basics being checked. I'm not going to buy SD Cards for my 20 node clusters ! 0 Quote Link to comment Share on other sites More sharing options...
AxelFoley Posted June 20, 2022 Share Posted June 20, 2022 https://wiki.pine64.org/wiki/ROCKPro64_Software_Release "If you are booting from a Micro SD card, then both Linux kernel versions will work. If you are trying to boot from an eMMC module then the 4.4.y will work, but the newer 5.10.y will not." Doh ! So you will need to flash to 4.4.y or boot from SD Card if you want Armbian 0 Quote Link to comment Share on other sites More sharing options...
schwar3kat Posted June 21, 2022 Share Posted June 21, 2022 22 hours ago, AxelFoley said: Doh ! So you will need to flash to 4.4.y or boot from SD Card if you want Armbian Hi Axel, I don't own one, and I don't have a board that uses eMMC, so I'm neither familiar with it nor can I can't test, but Googling the issue, Rockpro64 seems well known for a eMMC bug with random cards that report command queue (CMDQ) support but don't work correctly when CMDQ is enabled and if you searched these forums, you possibly came across this. https://forum.armbian.com/topic/19917-rockpro64-emmc-armbian-2108-kernel-51060-buster/ The post indicates that it only affects some boards, so it's likely a hardware tolerance issue that is triggered by something in the newer kernels. According to some Googled solutions it apparently requires a Kernel boot argument work around to get such cards to work with Kernels > 5. Kernel boot arguments can be added into the Armbian boot armbianEnv.txt file. It's certainly worth a try. You can try this: Add a line into into /boot/armbianEnv.txt extraargs="mmc_cmdqueue=off" Let us know if it works 0 Quote Link to comment Share on other sites More sharing options...
AxelFoley Posted June 21, 2022 Share Posted June 21, 2022 Tried setting extraargs="mmc_cmdqueue=off" Still same error. When I googled around a bit, one suggestion was that it was caused by the 1st n byte's of the eMMC chip getting nulled out deleting the normal boot partition location and that the solution was to move the boot sector to a new address range outside that first n bytes... but I'm no boot expert ... I'll do some digging; 0 Quote Link to comment Share on other sites More sharing options...
Igor Posted June 21, 2022 Share Posted June 21, 2022 Build image from sources. It has different boot loader. 0 Quote Link to comment Share on other sites More sharing options...
AxelFoley Posted June 22, 2022 Share Posted June 22, 2022 Well after a bit of tracing the serial output of the boot load process and looking at a working ayufan image against a Armbian Image (5 kernel) it looks like they have a different way of implementing U-Boot for the RockPro64 RK3399. Note my test boards come with PCIe NVMe Drives and the board provides 128Mb SPI boot Flash and 64GbE eMMC Storage from which I am trying to boot the kernel. Not booting eMMC: Armbian TPL -> SPL-> U-Boot -> Kernel Booting eMMC: Ayufan SPL -> U-Boot -> kernel >> What I notice is that Ayufan image has a serial boot output prefixed by what looks like a LDDR Memory test/probe. The boot sequence should be consistent at first then deviate, not deviate right from the start ! RTFM Here https://wiki.pine64.org/wiki/RK3399_boot_sequence "It employs 5 strategies, in order, to load a bootloader from off-chip: loading from NOR flash on SPI1 loading from NAND flash on SPI1 loading from eMMC loading from SD on the SDMMC controller bringing up the OTG0 USB controller in device mode and accepting control transfers to load programs Loading a bootloader from storage is done in 4 steps: Probing the boot device Finding the ID block Loading the first stage of the bootloader to main SRAM and running it (if the first stage returned to BROM) Loading the second stage to low DRAM and running it" >> I have a suspicion that Ayufan's images have loaded a U-Boot Boot loader into SPI Flash and, perhaps that may be the issue as to why his images work but others do not. His kernel may be located at address below in eMMC but other boot images are not. "Booting using the fdt blob at 0x1f00000" I'll see if I can wipe the SPI Flash and see if Armbian starts to boot. FailedBoot.log SuccessfulBootlog.log 0 Quote Link to comment Share on other sites More sharing options...
AxelFoley Posted June 22, 2022 Share Posted June 22, 2022 Nah I think the above hypothesis is wrong, in some respects. My (poor) understanding of the boot process is; 1). First/Primary Boot Stage loader is BROM in the SOC's Chip initiated to enable enough HW to find the main boot loader (e.g. U-boot's SPL Secondary Boot Loader which is loaded on SPIFlash/eMMC/SDMMC Card), 2). The U-Boots SPL then initiates more HW (such as DDR Memory) to enable the full U-Boot to be loaded into larger memory space. >> I suspect that this is a legacy constraint ... legacy systems had limited memory so any boot loader needs to fit into those smaller memory environments for backwards compatibility. >> however if it can probe and detect more memory (NAND,NOR Flash Chips, eMMC, SDMMC & DDR Memory). This is Where the TPL Comes in 3). Tertiary Program Loader (to look for larger memory HW in which the SPI can load a bigger version of U-Boot out side of legacy constrained HW). >> So I think that both eMMC's U-Boot SPL Part of the boot image is being initialised on the eMMC (nee MMC lines in the serial output as eMMC is treated as SDMMC). It immediately loads the TPL to initialise the DDR memory and this explains why you see the TPL before the SPL in the output. The reason why the working Auyfan's has more verbose DDR output is because he is using a debug version of U-Boot; Auyfan working u-boot ( v1.3(debug):370ab80) SPL finds kernel image on eMMC Found /boot/extlinux/extlinux.conf ...Retrieving file: /boot/vmlinuz-4.4.190-1233-rockchip-ayufan-gd3f1be0ed310 Armbian non working u-boot v1.3(release):845ee93 SPL finds kernel image on eMMC Found U-Boot script /boot/boot.scr so TPL hands back to SPL again after initialising the DDR Memory so SPL can load the big U-Boot image into DDR Memory .... but this is where I think the problem is .... Both images seem to try to load a Ram Disk to load the kernel into Aufan; ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Ramdisk to f5902000, end f5f00ca8 ... OK Loading Device Tree to 00000000f58e7000, end 00000000f5901810 ... OK Armbian; Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 09000000 Moving Image from 0x2080000 to 0x2200000, end=3f90000 ## Loading init Ramdisk from Legacy Image at 06000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 14238821 Bytes = 13.6 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 So I need to look at what this "rockchip-fixup.scr" is actually doing that Auyan's image is not. because it looks to me like the Armbian image is failing to load the kernel into DDR memory. Now this may be down to this line in the Armbian Boot process; Device 0: unknown device Card did not respond to voltage select! : -110 switch to partitions #0, OK >> I wonder if its the NVMe storage that's confusing the Armbian image boot process and preventing it from loading the kernel into DDR. Time for bed but tomorrow I'll disconnect the PCIe NVMe device and see if Armbian boots ! 0 Quote Link to comment Share on other sites More sharing options...
AxelFoley Posted June 22, 2022 Share Posted June 22, 2022 Update: well its was not the NVMe drive or the USB Peripherals. I disconnected them both and the Armbian image still refuses to boot the kernel There is still and unknown device Device 0: unknown device Card did not respond to voltage select! : -110 switch to partitions #0, OK and the image still fails to boot Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 09000000 Moving Image from 0x2080000 to 0x2200000, end=3f90000 ## Loading init Ramdisk from Legacy Image at 06000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 14238821 Bytes = 13.6 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 0 Quote Link to comment Share on other sites More sharing options...
schwar3kat Posted June 23, 2022 Share Posted June 23, 2022 Have you tried the new images 23-Jun? There is a description of the boot processes on the pine site https://wiki.pine64.org/wiki/RK3399_boot_sequence I noted this statement: "The BROM does not support using the standard option for eMMC boot partitions" I also note that rockchip64 has 128Mb SPI boot Flash. So perhaps it is possible to place your bootloader in spi, and the rest in eMMC 0 Quote Link to comment Share on other sites More sharing options...
Igor Posted June 24, 2022 Share Posted June 24, 2022 On 6/22/2022 at 9:55 PM, AxelFoley said: RTFM Here https://wiki.pine64.org/wiki/RK3399_boot_sequence Worth comparing if not already: https://github.com/armbian/build/blob/master/config/sources/families/include/rockchip64_common.inc 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.