Date: Sun, 22 Dec 2019 15:06:08 -0800 From: Mark Millard <marklmi@yahoo.com> To: Emmanuel Vadot <manu@bidouilliste.com>, 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: <0AADC2F5-9867-40E7-B4C0-139CA16A3974@yahoo.com> In-Reply-To: <FF778D08-0C49-4181-98B8-371003663F22@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> <FF778D08-0C49-4181-98B8-371003663F22@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[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: >=20 >> 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. >=20 > 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=20 . . . rk3328_rock64_load=3D"YES" rk3328_rock64_type=3D"dtb" rk3328_rock64_name=3D"/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.) =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?0AADC2F5-9867-40E7-B4C0-139CA16A3974>