Attempt to update Rock64 to head -r355976 failed to boot afterwards, anyone have a recent FreeBSD booting a Rock64?

[Mark Millard]

On 2019-Dec-23, at 08:29, Mark Millard <marklmi at yahoo.com> wrote:

> On 2019-Dec-23, at 06:38, Emmanuel Vadot <manu at bidouilliste.com> wrote:
> 
>> On Sun, 22 Dec 2019 15:06:08 -0800
>> Mark Millard <marklmi at yahoo.com> wrote:
>> 
>>> . . .
>>> 
>>> The following forced the desired .dtb to be used:
>>> 
>>> # more /boot/loader.conf 
>>> . . .
>>> rk3328_rock64_load="YES"
>>> rk3328_rock64_type="dtb"
>>> rk3328_rock64_name="/boot/dtb/rockchip/rk3328-rock64.dtb"
>>> . . .
>> 
>> You need to put the dtb in the ESP partition under /efi/dtb/rockchip
>> U-Boot dtb is sometimes different than the one we use for the kernel.
>> 
> 
> I'll experiment with such, likely later today, thanks.
> 
> . . .
> 

Thanks for the notes. The results were . . .

Putting the .dtb in the msdosfs file system as
dtb/rockchip/rk3328-rock64.dtb worked the same
as the loader.conf way for overall behavior,
but no _load/_type/_name in /boot/loader.conf
involved.

Still, I supposed that having u-boot use the same
DTB material that FreeBSD does might appropriate,
at least if the u-boot is of an appropriate vintage
relative to the kernel's DTB handling.

I'm not clear on if there is a solid reason to
prefer one way over the other. _load/_type/_name
use automatically references updated files from
the install operations, no extra copy operation
needed. (But how risky is such automatic updating
vs. not doing so?)

I still see that my non-debug kernel build fails
to complete a power-on boot for plain boot but
works for "boot -v". I've not thought of a good
way to gather information for the failure.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)