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

[Mark Millard]

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

. . .
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 load -t dtb /boot/dtb/rockchip/rk3328-rock64.dtb
/boot/dtb/rockchip/rk3328-rock64.dtb size=0xc2c5
OK boot
Using DTB from loaded file '/boot/dtb/rockchip/rk3328-rock64.dtb'.
---<<BOOT>>---
. . .
CPU  1: ARM Cortex-A53 r0p4 affinity:  1
CPU  2: ARM Cortex-A53 r0p4 affinity:  2
CPU  3: ARM Cortex-A53 r0p4 affinity:  3
Root mount waiting for: usbus0 usbus1 usbus2 CAM
uhub2: 1 port with 1 removable, self powered
uhub1: 1 port with 1 removable, self powered
uhub0: 1 port with 1 removable, self powered
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Warning: no time-of-day clock registered, system time will not be set accurately
Fatal data abort:
Fatal data abort:
  x0:                0
  x1:               30
  x2:                0
  x3:                1
   x1: ffff000067bea420
  x2:                c
  x3:                0
  x4:                3
  x5: ffff0000007637e0
  x6: ffff000000472014
  x7:              151
  x8: fffffd0000bd0510
  x9:            92ac8
 x10:              2db
 x11:                0
 x12:         96000006
 x13:            92ac7
 x14:               31
 x15: ffff000000890a2b
 x16:                1
 x17:                0
 x18: ffff000067bea320
 x19: fffffd0000bd0500
 x20: ffff000067bea420
 x21: fffffd000c51c560
 x22:               1b
 x23:               1b
 x24: fffffd0000aab880
 x25:               78
 x26: ffff0000417ebd1c
 x27: ffff0000417eb000
 x0:               2d
  x1:                0
  x2: ffff000067be9f08
  x3:                1
  x4:               78
  x5:               55
  x6: ffff000000472014
  x7:              151
  x8:                0
  x9:                1
 x10:           167bca
 x11:                f
 x12:           2e774a
 x13: ffff0000016fe000
oresight Trace Memory Controller (TMC)dxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdx elr: ffff000000472ba0
spsr:                0
 far:               10
 esr:         96000006
dxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdx elr: ffff000000472ab8
dxdxdxdxdxdxdxdxdxdxdxdxdxdxddxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdx elr: ffff000000472ab8
spsr:         20000145
 far: 67bebaa0ffff0000
 esr:         96000044
timeout stopping cpus


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