Bug 1913238
| Summary: | Failed to load '/dtb/rockchip/rk3399-pinebook-pro.dtb' ** Unrecognized filesystem type ** while booting aarch64 Workstation image on Pinebook Pro (RockChip RK3399) from SD card with internal eMMC disabled | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Dominik 'Rathann' Mierzejewski <dominik> | ||||||
| Component: | arm-image-installer | Assignee: | Peter Robinson <pbrobinson> | ||||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 34 | CC: | fmartine, mjg59, pbrobinson, pjones, pwhalen, wcohen | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | aarch64 | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2022-03-24 15:00:04 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 245418 | ||||||||
| Attachments: |
|
||||||||
|
Description
Dominik 'Rathann' Mierzejewski
2021-01-06 10:45:41 UTC
Looks similar to what is reported here: https://github.com/ayufan-rock64/linux-build/issues/222 . Created attachment 1745466 [details] u-boot log with eMMC disabled and binaries flashed to correct SD card offset I did some reading and it looks like this is due to too-old u-boot pre-installed on the eMMC. After disabling the eMMC it still didn't boot from the SD card until I put both idbloader.img and u-boot.itb from rawhide uboot-tools at the correct offset (https://wiki.pine64.org/wiki/RK3399_boot_sequence#General_maintenance ): 1. make backup of the contents of the first SD card partition (here: sdg1) 2. delete sdg1 in fdisk 3. create a new sdg1 partition at offset 18432 instead of 2048 sectors (and mark it bootable) 4. sudo mkfs.fat -n 607B-AB6B -v -h 2048 /dev/sdg1 5. copy the contents of original partition to sdg1 6. sudo dd if=idbloader.img conv=notrunc seek=64 of=/dev/sdg 7. sudo dd if=u-boot.itb conv=notrunc seek=16384 of=/dev/sdg I'm now able to boot to u-boot console. Even the display and keyboard seem to work. :) kernel is still not booting, though. New log attached. I guess I should reassign to arm-image installer since it produces an unbootable image. It's because the rockchip firmware is too large and writes through the partition table and the beginning of the VFAT partition, it's a known issue and should be solved one way or another for f34. It's not really a bug with arm-image-installer, but what ever. I was able to boot grub manually using: load mmc 1:2 0x01f00000 /dtb/rockchip/rk3399-pinebook-pro.dtb load mmc 1:1 0x02080000 /efi/fedora/grubaa64.efi bootefi 0x02080000 0x01f00000 ... which is what seems to be the default. I don't know why it's failing, but @pbrobinson said he's dealing with it, so hopefully he'll be able to fix it soon. Having said that, I removed "rhgb quiet" from grub command line, added console=ttyS2,1500000 and booted the kernel. It printed the following on both the LCD and the serial console: EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map... and then nothing. Sorry about the needinfo, my mistake. This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34. Is this bug still present? I'm able to boot successfully on two rk3399 devices. I believe we could just close it. This might be Pinebook Pro specific, but we can close this. If I understand correctly, the supported way of installing and booting Fedora is to flash u-boot to the SPI anyway. So I think this was basically the dd overwriting the early bits of the ESP partition. |