Netbsd on rock64 with no SPI

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.

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.

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. 🙂

hea

Well this goes a bit over my head but if I understand it right the CONFIG_DM_RESET will do something with the display settings while in u-boot and maybe fix this issue? Sorry for not catching up on this right away but I'm really on deep water here.

And yes the images for the Pinebook pro has always worked without any problems so I expected to just boot the rock64 in the same way and don't look back :-)

Btw sorry but i cannot get anything from that link...

kc9udx

hea I think it's my fault. I must have fat fingered termbin. This should get you a uuencoded gzipped tar file:
Here

hea

There is a steep learning curve here. I will see if I can get this working :-) Thanks a lot!

kc9udx

rvp well, it depends when it was added and when the production U-Boot was generated. But it does look to me like it's been there a while 🙁

hea please do let me know if you are able to extract and use that U-Boot

hea

Struggling again. Trying to mount the image to get access to the creds.txt file... want to at least access the card via ssh before trying any further:

# vndconfig vnd0 ./NetBSD-10-aarch64--rock64.img
# vndconfig -l /dev/vnd0*
vnd0: / (/dev/dk0) inode 1547380

looks like it should?

# mount /dev/vnd0a /mnt/image
mount: no match for vnd0a: No such process

Tried some variations of this but new obstacles round every corner :-(

kc9udx

~~hea shouldn't you be trying to mount /dev/dk0 or possibly /dev/dk0e rather than /dev/vnd0a?~~. I'm prolly wrong, I have no idea.

hea that sounds like I ran into a file size limit. But I'm pretty sure I checked for that. I'll have to see later when I get a chance. Possibly I'll send the file separately.

rvp

hea Trying to mount the image to get access to the creds.txt file...

$ sudo vndconfig vnd0 NetBSD-10-aarch64-rock64.img 
$ sysctl hw.disknames
hw.disknames = ld0 dk0 dk1 dk2 dk3 dk4 dk5 dk6 dk7 dk8 dk9 dk10 dk11 dk12 dk13 vnd0 dk14 dk15
$ dmesg | tail
[    11.255713] bridge0: link state UP (was UNKNOWN)
[    18.505716] wsdisplay0: screen 1 added (default, vt100 emulation)
[    18.505716] wsdisplay0: screen 2 added (default, vt100 emulation)
[    18.505716] wsdisplay0: screen 3 added (default, vt100 emulation)
[    18.515708] wsdisplay0: screen 4 added (default, vt100 emulation)
[    27.085703] cpu 0: ucode 0x96->0xc6
[    27.095702] cpu 1: ucode 0x96->0xc6
[   599.575220] vnd0: GPT GUID: f637cbc1-13d7-4931-8a86-c877d279823b
[   599.575220] dk14 at vnd0: "EFI", 163840 blocks at 32768, type: msdos
[   599.585224] dk15 at vnd0: "netbsd-root", 2899968 blocks at 196608, type: ffs
$ sudo mount /dev/dk14 /mnt
$ ls -l /mnt
total 23155
drwxr-xr-x  1 root  wheel      1024 Apr  1 01:31 EFI/
-rwxr-xr-x  1 root  wheel      1594 Apr  1 01:31 LICENCE.broadcom
-rwxr-xr-x  1 root  wheel     52476 Apr  1 01:31 bootcode.bin
-rwxr-xr-x  1 root  wheel        33 Apr  1 01:31 cmdline.txt
-rwxr-xr-x  1 root  wheel       155 Apr  1 01:31 config.txt
drwxr-xr-x  1 root  wheel      1024 Apr  1 01:31 dtb/
-rwxr-xr-x  1 root  wheel      7269 Apr  1 01:31 fixup.dat
-rwxr-xr-x  1 root  wheel      5412 Apr  1 01:31 fixup4.dat
-rwxr-xr-x  1 root  wheel      3180 Apr  1 01:31 fixup4cd.dat
-rwxr-xr-x  1 root  wheel      3180 Apr  1 01:31 fixup_cd.dat
-rwxr-xr-x  1 root  wheel  16775144 Apr  1 01:31 netbsd.img
-rwxr-xr-x  1 root  wheel   2979264 Apr  1 01:31 start.elf
-rwxr-xr-x  1 root  wheel   2254944 Apr  1 01:31 start4.elf
-rwxr-xr-x  1 root  wheel    808060 Apr  1 01:31 start4cd.elf
-rwxr-xr-x  1 root  wheel    808060 Apr  1 01:31 start_cd.elf
$ sudo umount /mnt
$ sudo vndconfig -u vnd0

You should also be able to mount the wedges on the SD card directly with their device names.

hea

@kc9udx : I get this when renaming file to u-boot-2022.01.tar.gz and trying to tar xvf

x rock64/ x rock64/idbloader.img x rock64/installboot.plist
x rock64/rksd_loader.img: Truncated tar archive detected while reading data: Unknown error: -1

kc9udx

hea
rksd_loader.img
rkspi_loader.img
u-boot.itb

« Previous Page Next Page »