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

[Mark Millard]

[It has taken explicitly controlling the DTB used and
use of "boot -v" together to be able to boot to
completion . . .]

On 2019-Dec-22, at 12:47, Mark Millard <marklmi at yahoo.com> wrote:

> On 2019-Dec-22, at 11:16, Mark Millard <marklmi at yahoo.com> wrote:
> 
>> On 2019-Dec-22, at 02:38, Emmanuel Vadot <manu at bidouilliste.com> wrote:
>> 
>>> On Sun, 22 Dec 2019 00:22:16 -0800
>>> Mark Millard via freebsd-arm <freebsd-arm at freebsd.org> wrote:
>>> 
>>>> [OverDrive 1000 and MACCHIATObin Doubleshot updates went fine.
>>>> The code has Peter Jeremy's rk_tsadc.c patch.]
>>>> 
>>>> 
>>>> The console shows for boot -v . . .
>>>> 
>>>> 
>>>> Loading kernel...
>>>> /boot/kernel/kernel text=0x98af14 data=0x18e618 data=0x0+0x6fc8e8 syms=[0x8+0x142020+0x8+0x12d3fd]
>>>> Loading configured modules...
>>>> /boot/kernel/umodem.ko text=0x2120 text=0x13e0 data=0x6e8+0x10 syms=[0x8+0xf60+0x8+0xb7f]
>>>> /boot/kernel/ucom.ko text=0x217f text=0x3340 data=0x880+0x858 syms=[0x8+0x1170+0x8+0xb0d]
>>>> /boot/entropy size=0x1000
>>>> 
>>>> Hit [Enter] to boot immediately, or any other key for command prompt.
>>>> Booting [/boot/kernel/kernel] in 8 seconds... 
>>>> 
>>>> Type '?' for a list of commands, 'help' for more detailed help.
>>>> OK boot -v
>>>> Using DTB provided by EFI at 0x80f3000.
>>>> ---<<BOOT>>---
>>>> . . .
>>> 
>>> 
>>> I don't have the same clocks from the dtb, make sure that you are
>>> using the latest one.
>>> rk3328_cru0: <Rockchip RK3328 Clock and Reset Unit> mem 0xff440000-0xff440fff on ofwbus0
>>> . . .
>>> sha256 /boot/dtb/rockchip/rk3328-rock64.dtb 
>>> SHA256 (/boot/dtb/rockchip/rk3328-rock64.dtb) = 50a180fed37f1d5dbfda60a6c55261c7b87b5b2bc97e428042481c94877da317
>> 
>> Thanks.
>> 
>> # sha256 /mnt/boot/dtb/rockchip/rk3328-rock64.dtb
>> SHA256 (/mnt/boot/dtb/rockchip/rk3328-rock64.dtb) = 50a180fed37f1d5dbfda60a6c55261c7b87b5b2bc97e428042481c94877da317
>> 
>> Looks like a match to me. So I need to look elsewhere than
>> the contents of that file . . .
>> 
>> My getting: "Using DTB provided by EFI at 0x80f3000" suggests
>> that the file is not being used for some reason: Instead some
>> sort of nonFreeBSD/internal-to-something-else DTB seems to be
>> in use?
>> 
>> So my current guess is that I need to figure out how to control
>> which DTB source is used so that /boot/dtb/rockchip/rk3328-rock64.dtb
>> is used in my context. (Although I've no clue why I'd need a
>> different configuration for controlling such things now.)
>> 
>> Note: I tried putting back the prior EFI/BOOT/bootaa64.efi but
>> it made no difference to the failed-boot behavior.
> 
> Well, using load -t explicitly got farther:
> (So once I figure out an equivalent in /boot/loader.conf
> it should automatically get farther.)
. . .

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

Interestingly, so far, boot -v works for power up booting,
but default booting does not, even for when "boot" is
typed to the loader prompt.

The default usually just hangs instead of showing all
the information that I reported previously. The hangup
(possibly with some text) is just before the start_init
line in:

Warning: no time-of-day clock registered, system time will not be set accurately
start_init: trying /sbin/init

So far, no hang-up has shown part of the "start_init"
message line.

But I've not had troubles (so far) with "shutdown -r now"
reboots, defaults or otherwise: problems Just for going
from power-off to power-on and trying to boot.

(Someday, I also want to figure out how to set up the
Rock64 to get a stable DHCP binding: a fixed MAC
address, I guess.)

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