Netbsd on rock64 with no SPI

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

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.

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.

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

hea

Lo and behold! I have now logged into this computer for the first time via ssh. I manged to copy a creds.txt file to the msdos partition. Being spoon fed for almost a week I'd better make it work...
Thanks for all your help! This is really unknown territory for me and the information one can find often demands some extra knowledge that I don't possess, so this has been lots of learning and very enjoyable:-) I think I need a break before trying the modified u-boot. ssh access is at the moment sufficient on this computer but I will try to see if I can get the display working...

kc9udx

hea if you haven't already, make sure to download those files from termbin; before they expire and get deleted. They only have time-to-live of one week.

hea

kc9udx Are the files compressed?

hea

Thanks! I downloaded straight away. Not ready to try it yet. The network behaves weird on the rock64. Need to be connected directly to router. Do not accept switch connection. So amongst other things I'm trying to sort out that.

« Previous Page