Date: Sun, 22 Dec 2019 12:47:03 -0800 From: Mark Millard <marklmi@yahoo.com> To: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Attempt to update Rock64 to head -r355976 failed to boot afterwards, anyone have a recent FreeBSD booting a Rock64? Message-ID: <FF778D08-0C49-4181-98B8-371003663F22@yahoo.com> In-Reply-To: <3C550401-A5BF-441E-81E6-29D5D917302B@yahoo.com> References: <78081E30-3758-46F3-A228-02B29CDAA6A6.ref@yahoo.com> <78081E30-3758-46F3-A228-02B29CDAA6A6@yahoo.com> <20191222113844.9385de125afd10e86358bc98@bidouilliste.com> <3C550401-A5BF-441E-81E6-29D5D917302B@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >=20 >> On Sun, 22 Dec 2019 00:22:16 -0800 >> Mark Millard via freebsd-arm <freebsd-arm@freebsd.org> wrote: >>=20 >>> [OverDrive 1000 and MACCHIATObin Doubleshot updates went fine. >>> The code has Peter Jeremy's rk_tsadc.c patch.] >>>=20 >>>=20 >>> The console shows for boot -v . . . >>>=20 >>>=20 >>> Loading kernel... >>> /boot/kernel/kernel text=3D0x98af14 data=3D0x18e618 = data=3D0x0+0x6fc8e8 syms=3D[0x8+0x142020+0x8+0x12d3fd] >>> Loading configured modules... >>> /boot/kernel/umodem.ko text=3D0x2120 text=3D0x13e0 data=3D0x6e8+0x10 = syms=3D[0x8+0xf60+0x8+0xb7f] >>> /boot/kernel/ucom.ko text=3D0x217f text=3D0x3340 data=3D0x880+0x858 = syms=3D[0x8+0x1170+0x8+0xb0d] >>> /boot/entropy size=3D0x1000 >>>=20 >>> Hit [Enter] to boot immediately, or any other key for command = prompt. >>> Booting [/boot/kernel/kernel] in 8 seconds...=20 >>>=20 >>> Type '?' for a list of commands, 'help' for more detailed help. >>> OK boot -v >>> Using DTB provided by EFI at 0x80f3000. >>> ---<<BOOT>>--- >>> . . . >>=20 >>=20 >> 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=20 >> SHA256 (/boot/dtb/rockchip/rk3328-rock64.dtb) =3D = 50a180fed37f1d5dbfda60a6c55261c7b87b5b2bc97e428042481c94877da317 >=20 > Thanks. >=20 > # sha256 /mnt/boot/dtb/rockchip/rk3328-rock64.dtb > SHA256 (/mnt/boot/dtb/rockchip/rk3328-rock64.dtb) =3D = 50a180fed37f1d5dbfda60a6c55261c7b87b5b2bc97e428042481c94877da317 >=20 > Looks like a match to me. So I need to look elsewhere than > the contents of that file . . . >=20 > 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? >=20 > 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.) >=20 > 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...=20 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=3D0xc2c5 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)dxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxd= xdxdxdxdxdxdxdxdxdxdxdx elr: ffff000000472ba0 spsr: 0 far: 10 esr: 96000006 dxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdx elr: = ffff000000472ab8 = dxdxdxdxdxdxdxdxdxdxdxdxdxdxddxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxd= xdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxdxd= xdxdxdxdxdxdxdxdxdxdxdxdxdxdxdx elr: ffff000000472ab8 spsr: 20000145 far: 67bebaa0ffff0000 esr: 96000044 timeout stopping cpus =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FF778D08-0C49-4181-98B8-371003663F22>