Netbsd on rock64 with no SPI

hea

Hi! I've been trying to get Netbsd to boot on this card. It's the latest version of the card where the SPI chip has been removed. I have tried every way I can think of, both bootable image spesific for this board and generic arm64 with u-boot from pkgin. The HW is ok. I can boot other os images. Anyone got this running with NetBSD?

kc9udx

Please confirm my presumption that you are trying to boot from a micro-SD card, that you have no eMMC installed, and that nothing is plugged in to the USB ports.

If all that is true, it really should boot from the image from armbsd.org assuming the image is burned correctly and the card works.

I have had endless troubles getting these things to boot the first time. But after that they keep working. Mind you I don't have that exact model to say for sure it works.

I just wasted literally the whole day yesterday getting a RockPro64 to work, despite that I've done it before.

hea

I download the NetBSD-10-aarch64--rock64.img.gz from armbsd.org, check shasum, gunzip,
then : dd if=NetBSD-10-aarch64--rock64.img of=/dev/rsd0 bs=1m conv=sync
I do "sync " again to be sure. Then I insert sdcard into the rock64 board with only network an hdmi attached. Power on... and ...nothing happens. Red lcd, white lcd and green lcd static on. Absolutly no activity.

My only guess is that the images on armbsd.org are made for the previous versions of this board and that the now missing spi causes the boot process to hang.

rvp

hea I download the NetBSD-10-aarch64--rock64.img.gz from armbsd.org, check shasum, gunzip,
then : dd if=NetBSD-10-aarch64--rock64.img of=/dev/rsd0 bs=1m conv=sync

Have you tried the official instructions for Rockchip here?

That says that you also need to write the board-specific u-boot image, rksd_loader.img starting at an offset of 32KB from the start of the SD-card (this is to skip the GPT sitting there).

Note that the instructions show the device to be written as rld0d, but, this (d--whole disk) device is only correct on amd64 architectures. If you're writing on NetBSD aarch64, then the whole-disk device is rld0c. Or, just use rld0-- that usually is the same as the whole-disk device, whether c or d

kc9udx

I don't know that any of them do anything with SPI ROM. Hopefully they don't. I did read something somewhere mentioning installboot messing with SPI ROM but that shouldn't even be an issue on a static image.

You could try flashing a different U-Boot to the card with that image.

hea

Thanks for the suggestions!
Think I've tried every possible combination.

I dont believe the image neccessarily tries to mess with the spi but maybe it checks whether the spi contains a u-boot and hang when spi is not found... Just a guess.

Anyway would be interesting to see if anyone actually booted this image on this specific board without the spi. I have only seen this working on the old version yet.

kc9udx

hea it must be failing before U-Boot displays anything; else you should get a U-Boot display. U-Boot does try to read its env from SPI ROM. But it starts printing messages before that. And it continues booting if it doesn't find anything that it put there.

Do you have an eMMC module? If so, perhaps you could boot Linux and flash the NetBSD image to that and see what happens. If that still doesn't work, you might be able to install U-Boot to it and then partition and format for, and install NetBSD.

~~Also, I wonder if the Pinebook (not Pro) or Pinephone images would work on that board.~~ Sorry, don't know what I was thinking. Those will certainly not work. However, the RockPro64 and Pinebook Pro ones might possibly work.

It's too bad I didn't know about this all a couple weeks ago. I just bought another RockPro64, and I would've bought a Rock64 just to try it.

hea

Thank you for the suggestions! Yes I have emmc module and I will try to install from linux first :-)

kc9udx

hea another thought: if you ever used Linux with the eMMC, you would have to disable the eMMC to boot NetBSD from the micro-SD card. Arch variants at the least, will install a U-Boot that doesn't display anything and refuses to boot NetBSD from micro-SD card.

The most frustrating thing about these boards is that they always try to boot to the eMMC first. So if there's a bad image there (or one hostile to NetBSD!) you cannot boot from any other source.

hea

I ended up installing armbian to emmc and installed from that to the sdcard. Then I removed emmc and tried to boot from sd, with negative result.

I also found some information here: https://github.com/u-boot/u-boot/blob/master/doc/README.rockchip

" Booting from an SD card on Pine64 Rock64 (RK3328)

=================================================

For Rock64 rk3328 board the following three parts are required:
TPL, SPL, and the u-boot image tree blob.

Write TPL/SPL image at 64 sector

=> sudo dd if=idbloader.img of=/dev/mmcblk0 seek=64
Write u-boot image tree blob at 16384 sector

=> sudo dd if=u-boot.itb of=/dev/mmcblk0 seek=16384"

which I have tried both in combination wit rock64-image and generic arm image.
Needless to say, neither worked...

kc9udx

Have you tried the RockPro64 image? I suspect it should work. I'm not sure what would be different between the two. At least, we know that one works on the RockPro64. They both use the GENERIC64 kernel as far as I know. And the boot requirements should be the same.

Also, I don't mean to insult your intelligence but make sure mmcblk0 is the right device. I know I've gotten that wrong before. mmcblk0 and mmcblk1 don't always point to the same device.

hea

I did try the RockPro64 image at one point. And regarding the device I can confirm that I always do a dmesg when in doubt to see which is which. emmc is 64G and the sd is always 32G or less. But I appreciate you reminding me :-) And again, Armbian booted with no issues.

kc9udx

When Armbian boots, do you get U-Boot diagnostic messages before Armbian?

If so, try installed NetBSD on that card without modifying the bootloader and U-Boot portion. In the early days of support for these devices, I had to do that. There was some change that needed to be made, I'll have to see if I can recall what it was. Back then, I didn't even have a U-Boot that displayed anything. In that case, I needed a serial console to see what was happening.

hea

I really want to try that, but here my lack of knowledge gets in the way. I believe that dd will erase all existing content on a sd-card when used without options. The "seek" option can prevent that and add something to the card without erasing the content before the specified seek length. Is that correct? And if that is the case, how would i know the seek length in a given case? I did actually read "man dd" but I lack some basic knowledge here. I guess i should find/guess the size of the existing u-boot on the card and give a seek length greater than that value assuming that the u-boot is located at the beginning?

I must admit I find the u-boot topic a bit confusing. Does e.g. NetBSD use the same u-boot as a given linux-distro?

kc9udx

hea

Does e.g. NetBSD use the same u-boot as a given linux-distro?

No. The NetBSD U-Boot comes from pkgsrc, which is Das U-Boot from DENX. Any Linux distru would be getting U-Boot from the same place. But everyone who builds it can build it differently. Now, you could build the pkgsrc version from within Linux and end up with the same thing NetBSD uses.

They can be used interchangeably. Except that there's something about some of them which exclude NetBSD, or rather, they want to only boot Linux, and then only some Linux distrus, I guess.

kc9udx

Yes, seek skips the given number of blocks. The default block size is 512; so seek=2 will skip 1kb. bs determines the block size. seek=2 bs=4096 will skip 8kb.

The way to determine where to seek to is by looking at the partition data. disklabel is how I would do it in NetBSD; fdisk is how I think it's done in Linux.

The alternative world be to copy the beginning part (up to the end of U-Boot) from the booting Linux card to the NetBSD imaged card.

I don't know without investigating (which I cannot do for a few days) what the NetBSD U-Boot actually is. But I do know that some U-Boots shipped with Linux will boot NetBSD. The ones I know that won't are arch Linux based. (Manjaru especially). But as long as you get diagnostic messages from U-Boot, you'll be able to tell what's happening.

hea

Thanks for this! I will experiment a bit and see what I can get from it.

kc9udx

It occurs to me that since the pkgsrc instructions for u-boot-rock64 are to flash just U-Boot to an empty SD card, I wonder if the idbloader is missing from the NetBSD image. If so, you would just need to copy that from a working bootable Linux card. But I'm not sure about that.

hea

Thanks, that clarifies things a bit but not enough for me to get this running I'm afraid :-)
I will try some more of your suggestions and see but my expectations are not high.

hea

Yes, that was my next step after failing with the bootable image. I have tried the rld0d and rld0 unsure of which was the right one. Thank you for this clarification!

If I interpret the instructions right the rksd_loader is going to the sd-card and the arm64.img (which I assume to be the generic, tried both) goes to the emmc in this case. Is this correct or could both be written to the same device? And if the latter is the case: woudn't the rksd_loader overwrite parts of the arm64.img?

rvp

hea Is this correct or could both be written to the same device?

Both have to be written to the same device, the SD card.

hea And if the latter is the case: woudn't the rksd_loader overwrite parts of the arm64.img?

It won't because you're using seek=64 and the rksd_loader.img is only about 1MB. After writing both to an SD card, it will have this structure:

Range	Type
0 - 32 KB	GPT
32 KB - 1 MB	u-boot image (~1 MB)
1 MB - 16 MB	unused
16 MB - 96 MB	NetBSD EFI ESP partition (~80 MB)
96 MB - end	NetBSD FFS partition (after auto-resizing--1st boot)