Netbsd on rock64 with no SPI

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)

kc9udx

rvp thanks for making that table. That makes it clearer than trying to think of all the sizes with and without block sizes.

I sure wish the resize_ffs would only grow to 8Gb. I always end up changing it to do that anyway.

hea

# dd if=NetBSD-10-aarch64--generic.img of=/dev/rsd0d bs=1m conv=sync
# dd if=rksd_loader.img of=/dev/rsd0d seek=64 conv=sync

gives:

# fdisk sd0d

`fdisk: Cannot determine the number of heads
Disk: /dev/rsd0d
NetBSD disklabel disk geometry:
cylinders: 7647, heads: 64, sectors/track: 32 (2048 sectors/cylinder)
total sectors: 15661056, bytes/sector: 512

BIOS disk geometry:
cylinders: 974, heads: 255, sectors/track: 63 (16065 sectors/cylinder)
total sectors: 15661056

Partitions aligned to 2048 sector boundaries, offset 63

Partition table:
0: Primary DOS with 32 bit FAT - LBA (sysid 12)
start 32768, size 163840 (80 MB, Cyls 2/10/9-12/60/48), Active
1: <UNUSED>
2: <UNUSED>
3: GPT Protective MBR (sysid 238)
start 1, size 32767 (16 MB, Cyls 0/0/2-2/10/8)
PBR is not bootable: Bad magic number (0x0000)
First active partition: 0
Drive serial number: 0 (0x00000000) `

Tried with both generic and rock64 image.
Any suggestions to what goes wrong?

kc9udx

Do you get the U-Boot diagnostic output?

Do you get it with Linux?

If not, U-Boot is not running. It may be that the idbloader isn't working.

hea

i run the above commands using NetBSD amd64. Then i type fdisk sd0d to get the output as shown. If I insert this sd-card into the rock64 and try to boot. nothing happens. If I have the keyboard plugged in the leds flash after a while but nothing else seems to happen. From the output of fdisk it seems to me that I get a different result than the table @rvp posted.

Not sure what U-Boot diagnostic output means or how I get it. There is a file: idbloader.img in the /usr/pkg/share/u-boot/rock64 directory along with u-boot.itb and rkspi_loader.img but none of them are mentioned in any way elsewhere.

kc9udx

It looks like this:

https://www.youtube.com/shorts/jVab9bcjM_I

Do you see anything like that before Linux boots? The earlier versions of U-Boot that came with NetBSD images didn't output to the framebuffer. Some linuces' U-Boots don't output anything.

A serial console might give you error messages if U-Boot fails.

hea

When I boot Armbian I cannot see anything u-boot related. It goes straight to the typical systemd init it seems. Maybe serial console will be the next step here.

Btw this is output from disklabel when i write the rock63 bootable image to sd:

`6 partitions:

size offset fstype [fsize bsize cpg/sgs]

d: 15661056 0 unused 0 0 # (Cyl. 0 - 7646)
e: 163840 32768 MSDOS # (Cyl. 16 - 95)
f: 32767 1 unknown # (Cyl. 0*- 15)
disklabel: boot block size 0
disklabel: super block size 0`

Does this look right? Why no NetBSD partitions?

rvp

hea Does this look right? Why no NetBSD partitions?

gpt show sd0 should show you the NetBSD partition.

Both the fdisk and disklabel look odd, but, they're what I see, too, after writing the images to a USB flash drive (I have no ARM HW at all...):

Script started on Sat Apr  5 20:16:14 2025

$ sudo fdisk sd0
fdisk: Cannot determine the number of heads
Disk: /dev/rsd0
NetBSD disklabel disk geometry:
cylinders: 15208, heads: 16, sectors/track: 63 (1008 sectors/cylinder)
total sectors: 15330304, bytes/sector: 512

BIOS disk geometry:
cylinders: 954, heads: 255, sectors/track: 63 (16065 sectors/cylinder)
total sectors: 15330304

Partitions aligned to 2048 sector boundaries, offset 63

Partition table:
0: Primary DOS with 32 bit FAT - LBA (sysid 12)
    start 32768, size 163840 (80 MB, Cyls 2/10/9-12/60/48), Active
1: <UNUSED>
2: <UNUSED>
3: GPT Protective MBR (sysid 238)
    start 1, size 32767 (16 MB, Cyls 0/0/2-2/10/8)
        PBR is not bootable: Bad magic number (0x0000)
First active partition: 0
Drive serial number: 0 (0x00000000)

$ sudo gpt show sd0
     start      size  index  contents
         0         1         MBR
         1         1         Pri GPT header
         2         4         Pri GPT table
         6     32762         Unused
     32768    163840      1  GPT part - EFI System
    196608   2899968      2  GPT part - NetBSD FFSv1/FFSv2
   3096576      2043         Unused
   3098619         4         Sec GPT table
   3098623         1         Sec GPT header
   3098624  12231680         Unused

$ sudo disklabel sd0
# /dev/rsd0:
type: SCSI
disk: Cruzer Blade    
label: fictitious
flags: removable
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 16
sectors/cylinder: 1008
cylinders: 15208
total sectors: 15330304
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0		# microseconds
track-to-track seek: 0	# microseconds
drivedata: 0 

6 partitions:
#        size    offset     fstype [fsize bsize cpg/sgs]
 d:  15330304         0     unused      0     0        # (Cyl.      0 -  15208*)
 e:    163840     32768      MSDOS                     # (Cyl.     32*-    195*)
 f:     32767         1    unknown                     # (Cyl.      0*-     32*)
disklabel: boot block size 0
disklabel: super block size 0

$ ^D
exit

Script done on Sat Apr  5 20:17:11 2025

BTW, the disk image thus created (latest rock64 NetBSD-10.1_STABLE image + rock64 u-boot image inserted), boot fine in Qemu/aarch64 running on Ubuntu/amd64 24.04.2.

hea

rock64 - image ofcourse...

kc9udx

I don't know the answer but I can tell you it's normal. The NetBSD partition doesn't exist until after the first boot. There's some kind of trickery in the initial boot. At least, the other images I've gotten from armbsd.org all are like that.

It's fairly annoying especially for me; because I have to interrupt booting the first time to edit rc.conf to only resize the root partition to 6Gb. I can't do that before booting the image.

kc9udx

But that doesn't account for the idbloader for RockChip, of course. OP Rock64 is getting lost before NetBSD ever comes into play.

rvp

kc9udx But that doesn't account for the idbloader for RockChip, of course.

The rksd_loader.img file has both idbloader.img (offset 0), and u-boot.itb (offset 0x38000) inside it. I wonder if one has to "reset" the Rock64 somehow between OS changes?

Well, I'm out of ideas. If @kc9udx can't think of anything else, ask on port-arm

hea Is btw ssh default activated on these images?

Yes. Try typing this blind after the system has booted (assuming it's at the login prompt):

root                           # login as `root' (no password needed)
useradd -m rvp                 # create user `rvp'
passwd rvp                     # set password
<mypasswd>                     # password for `rvp'
<mypasswd>                     # confirm passwd
exit

Then, try ssh (root logins aren't allowed by default).

hea

I can confirm gpt show sd0d created an identical output here.

When I tried to boot the last time after using latest rock64 NetBSD-10.1_STABLE image + rock64 u-boot image inserted as above, I waited a bit longer and I noticed after a wile a second flash on the keyboard leds plus network-led activity. Like it rebooted. Maybe it actually boots but that both the keyboard and hdmi-output doesn't work? I first expected the leds on the rock64 to flash when booting, but i noticed that the recent Armbian gave no led activity so... Is btw ssh default activated on these images?

hea

Pulled the card out and her are gpt show sd0d before and after:

start size index contents 0 1 MBR 1 1 Pri GPT header 2 4 Pri GPT table 6 32762 Unused 32768 163840 1 GPT part - EFI System 196608 2899968 2 GPT part - NetBSD FFSv1/FFSv2 3096576 2043 Unused 3098619 4 Sec GPT table 3098623 1 Sec GPT header 3098624 27219968 Unused

start size index contents 0 1 MBR 1 1 Pri GPT header 2 4 Pri GPT table 6 32762 Unused 32768 163840 1 GPT part - EFI System 196608 30113792 2 GPT part - NetBSD FFSv1/FFSv2 30310400 8187 Unused 30318587 4 Sec GPT table 30318591 1 Sec GPT header

So it must have booted and resized and rebooted if i interpret this right.
There is an expression: "barking up the wrong tree".
This was unexpected to say the least. What now...

kc9udx

hea yes certainly everything but the display is working.

I guess something we've overlooked is, what kind of display are you using? A plug-in LCD on the board, the HDMI plug, or other (can't remember if you can do video over USB3 on this one)?

Also did you read the Pine64 wiki? There are instructions about non-working displays on the Rock64.

Also alsø on the RockPro64, with NetBSD, the 4k HDMI display doesn't work right. And the "text mode" at boot time uses that display mode. The rightmost ⅓ of the display is missing. I wonder if there is a similar or worse problem with the Rock64.

kc9udx

rvp

I wonder if one has to "reset" the Rock64 somehow between OS changes?

No; The only time that should be needed is if the system locks up. But even then a power cycle will suffice.

rvp

kc9udx I guess something we've overlooked is, what kind of display are you using?

Something in that...

@hea, can you try compiling the u-boot-rock64 package using these as a LOCALPATCH? The code for CONFIG_DM_RESET should already exist in u-boot-2022.01, I think.

Then embed the resulting new rksd_loader.img onto the SD card as usual.

hea

Thank you so much for your answers!
I can now confirm that
dd if=NetBSD-10-aarch64--rock64.img of=/dev/rsd0d bs=1m conv=sync
creates a bootable image which resizes the partitions and reboots (no need for flashing u-boot). And probably it did all the time. I stand corrected.

To my defence I tried two different monitors and I read the wiki regarding the monitor issue, so I just ruled this out early. But it seems like this is a problem afterall. In addition I had to reconnect the network directly into the router to make the rock64 visible on the network.

After all this I'm able to ping it, i seem to be able to blindly create a user end exit. Then ssh <ipaddress> -l <user> asks for password but do not accept the one I created. I will do some more tests.

rvp

hea Then ssh <ipaddress> -l <user> asks for password but do not accept the one I created.

David Gutteridge of TNF told me something I was not aware of at all:

Could one of you please mention creds_msdos(8) to them?
https://man.netbsd.org/creds_msdos.8

This is the way to get a non-root account set up automatically
for a headless install, which will then make that available to an
ssh session. Where it says "boot partition" that means of course
the first one that has the EFI content on it. Now, it only works
the very first time (when the automatic resizing happens). So they
have to:

Write the image using dd to the card again.

Add u-boot again the same way if necessary (depending on the
image they're working with).

Mount the card on the device doing the writing, and manually place
the text file with the login details on the first partition
at the point where other config files are found.

That should help you to ssh into the system.

kc9udx Fwiw, rock64-rk3328_defconfig already had CONFIG_DM_RESET in it.

Uh-oh! That doesn't bode well...

hea

I have now also booted the emmc the same way. Problem is that I doubt the keyboard works at all. The numlock/capslock leds do not respond. And if i after boot type root to login, and then type poweroff it does not turn off. I can still ping it. Only when i physically power off it goes offline.

I guess I will have to get a usb to serial console adapter to get any further.

kc9udx

Here is the U-Boot with the requested patches from @rvp Termbin. Fwiw, rock64-rk3328_defconfig already had CONFIG_DM_RESET in it.

Also, since you have NetBSD installed on the eMMC, you can boot Linux on an SD card, mount the eMMC, and modify the configuration in NetBSD to suit your needs.

On a side note, I don't mean to spam the thread but I thought you might find it amusing: I'm having the opposite problem. On my RockPro64, NetBSD has some display issues but 1920x1080 works well. Under dietpi, I either get "No signal" or just no X display when starting X. X (and a whole slew of graphical stuff) is running but it doesn't display anywhere. 🙂

« Previous Page Next Page »