Date: Mon, 23 Dec 2019 15:38:16 +0100 From: Emmanuel Vadot <manu@bidouilliste.com> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-arm <freebsd-arm@freebsd.org>, Peter Jeremy <peter@rulingia.com> Subject: Re: Attempt to update Rock64 to head -r355976 failed to boot afterwards, anyone have a recent FreeBSD booting a Rock64? Message-ID: <20191223153816.4e532acede0605a0c868a8e4@bidouilliste.com> In-Reply-To: <0AADC2F5-9867-40E7-B4C0-139CA16A3974@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> <0AADC2F5-9867-40E7-B4C0-139CA16A3974@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 22 Dec 2019 15:06:08 -0800 Mark Millard <marklmi@yahoo.com> wrote: > [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@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" > . . . 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. > 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. I don't have access to my boards right now but I'm pretty sure that booting without verbose worked for me recently. > (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) -- Emmanuel Vadot <manu@bidouilliste.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20191223153816.4e532acede0605a0c868a8e4>