#52 rock64 support
Closed: Fixed 2 years ago by pak0st. Opened 3 years ago by pak0st.

The rock64 is marked as supported board under "Other Devices:"

The script fails with:
Error: You must choose a supported board or none at all.

Missing rock64 file in board.d directory.


In #42 , it is mentioned that a different tool may be used for flashing Rockchip devices. Is this still the case?

Yes, working to update the docs and the plan is to have it write to the SPI flash so you can just use --target=none from arm-image-installer. The rockchips U-Boot splats itself over about the first 9Mb of the disk which causes issues with the partition table and the EFI partition.

Thank you for the reply, @pbrobinson ! Updating the docs would be awesome!

My knowledge is really limited in this area, is the generic aarch64 image targeting systems which can already handle EFI boot?

Taking a look at the other distributions, Debian and Manjaro are taking two different approaches - Debian concatenating two images (one with uboot and one with the actual distro image) and the latest Manjaro images and installer using boot partition targeted by the uboot. Could one of those approaches be used as a stop-gap solution until the SPI flash method is developed for Rockchip devices?

Thank you for the informative reply!

My knowledge is really limited in this area, is the generic aarch64 image targeting systems which can already handle EFI boot?

We only support booting with UEFI on aarch64 devices.

Taking a look at the other distributions, Debian and Manjaro are taking two different approaches - Debian concatenating two images (one with uboot and one with the actual distro image) and the latest Manjaro images and installer using boot partition targeted by the uboot. Could one of those approaches be used as a stop-gap solution until the SPI flash method is developed for Rockchip devices?

No, it would be an order of magnitude work to do that, we only support UEFI for a reason, it's a single install/boot path and hence less code. U-Boot is a firmware, it supports a UEFI implementation already.

Had success installing F32 with the arm-image-installer using
sudo arm-image-installer --addconsole --addkey ~/.ssh/id_rsa.pub --relabel --resizefs --image=/opt/downloads/Pine64/Fedora-Minimal-32-1.6.aarch64.raw.xz --media=/dev/sdb --target=rock64-rk3328

However, I had to rename or create the board file
/usr/share/arm-image-installer/boards.d/rock64-rk3328

# write uboot
echo "= Writing idbloader.img for $TARGET .... on media $MEDIA"
dd if=$PREFIX/usr/share/uboot/$TARGET/idbloader.img of=$MEDIA seek=64; sync; sleep 5
echo "= Writing u-boot FIT image for $TARGET .... on media $MEDIA"
dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA seek=16384; sync; sleep 5
# set console for Rockchips
SYSCON=ttyS2,1500000n8

@revoman , sounds good! Will try it this week when I have some spare time

related: http://opensource.rock-chips.com/wiki_Boot_option#Boot_from_SD.2FTF_Card,
i.e. the 16384 offset is what's recommend

dd if=idbloader.img of=sdb seek=64
dd if=u-boot.itb of=sdb seek=16384
dd if=boot.img of=sdb seek=32768
dd if=rootfs.img of=sdb seek=262144

Yes, working to update the docs and the plan is to have it write to the SPI flash so you can just use --target=none from arm-image-installer. The rockchips U-Boot splats itself over about the first 9Mb of the disk which causes issues with the partition table and the EFI partition.

@pbrobinson already did this: https://nullr0ute.com/2021/05/fedora-on-the-pinebook-pro/ so I think this issue can be closed now.

@pbrobinson already did this: https://nullr0ute.com/2021/05/fedora-on-the-pinebook-pro/ so I think this issue can be closed now.

Rock64 is a different device to Rockpro64, I need to look at the SPI support there in U-Boot. It's on my todo list still

Sorry for not replying to the issue earlier - didn't have spare sd card and forgot for awhile.

Downloaded the aarch64 image and used the same setup as @revoman - it worked as expected and Fedora is booting on the rock64.

It didn't like my monitor but serial confirms the behaviour:
https://pastebin.com/ztp95d3E

I believe this can be marked as closed.

Metadata Update from @pak0st:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

I know this is closed, just wanted to comment that I had to disable the panfrost driver to get video working. Can't remember the specifics now, but it's something to try if you're interested.

I know this is closed, just wanted to comment that I had to disable the panfrost driver to get video working. Can't remember the specifics now, but it's something to try if you're interested.

This is not a location to report kernel issues. It's about setting up the device to boot.

Login to comment on this ticket.

Metadata