Re: RPI4 install trip report

[adr <adr%sdf.org@localhost>]

Oh men, you are really confused.

Let's start with this. The rpi4 has now a firmware in an eprom
chip. I recommend to update this with the
debian-with-little-patches-packages they call the "raspberry pi
os". This firmware lets you change the boot order, install an os
from network etc.  Let's call this the "rpi's firmware". This
firmware let you boot an os directly, without the mini os u-boot.
Netbsd does that configuring the config.txt and cmdline.txt. The
os uses then dtbs to know where and what is in the board (like with
u-boot).

Dtbs are hell, but better than the chaos before them. Now some
people thought: let's use the popular uefi standard that is replacing
bios in the pc world. That's the edk2 project. That's not in the
netbsd image.  You have to build (or download builds ready for use)
them and put them in the dos partition. The files replace the
config.txt among others so the raspbery pi4 will load the blob.

https://github.com/tianocore/edk2

Raspberry builds:
https://github.com/pftf/RPi4

This software (we'll call it the "uefi firmware") is just like the
uefi interface your pc runs, in fact, maybe is edk2, look at the
platforms it supports.

https://github.com/tianocore/edk2-platforms/tree/master/Platform

So now the boot process is the same as with another uefi platform.

> While netbsd-9 is technically in scope, my view is that (for evbarm)
> netbsd-8 is now irrevelant, and netbsd-10 is the standard approach,
> especially for RPI4.

I always have used uefi with rpi4, since it is supported.

> clearly map to "a file with this name in this image".  On the RPI4 I
> just installed with netbsd-10 RC3, I see:
>
>  # ls -l /boot/EFI/BOOT/bootaa64.efi
>  -r-xr-xr-x  1 root  wheel  196056 Jan 18 23:49 /boot/EFI/BOOT/bootaa64.efi

Thas a boot loader that the "uefi firmware" will load, because it is
in a default location. Look at boot(8) in a x86|x86-64 machine.
It's called UEFI bootstrap. A man page for aarch64 platforms should
be written.

> > Yes, it uses the framebuffer that is going to be presented to
> > netbsd.
>
> OK, but as I have posted, I see nothing on my HDMI monitor.

That could be one of the reasons rpi4 without uefi is not supported
right now. I'll let some developer of the arm port respond to that.

> yes, but that's broken :-) On my PC Engines apu2 with coreboot, it's all
> changeable on the serial port.

There is network boot support in the options of the uefi firmware,
I don't know if there is now serial access support, I'll check when
I've some time.

> But there is "raspberrypi-userland-20170109nb3".

That's for arm32. It has nothing to do with the boot process. It
has some code for use with the old models' gpu, the openmax interface,
etc. It never worked fine for me.

You are really confused man!

> > >    . Are there really no tools to set these from NetBSD?
> >
> > Are there tools to modify the bios settings in netbsd?
>
> Lack of them is a bug.  I don't 100% expect PC bugs in arm land.  So a
> useful answer would answer the question, not ask another question that
> isn't actually logically related.

You can not change the settings of the machine firmware within the
os. Those settings change the computer the system "sees". That's
a barrier that gives you stability. I thought that was clear in
the answer "answering" the question.

> > The limit was added to the firmware to make operating systems that
> > don't deal with a bug in the hardware (dma access, iirc), work ok.
> > You are not booting from uefi, so you don't see that limit (netbsd
> > knows how to deal with that).
>
> I'm not so sure at this point.

Be sure, you are not using uefi.

> Booting arm64.img, things seem to work, except HDMI.  I can "scan list"
> on the wifi, and the ethernet and usd card work fine.  I have not really
> dug into more hw.

Again, let's hear from the devs working in the port, I'm curious.

I hope this helps.

adr.