Date: Mon, 23 Dec 2019 02:14:02 +0100 From: =?utf-8?Q?Klaus_K=C3=BCchemann?= <maciphone2@googlemail.com> To: Mark Millard <marklmi@yahoo.com>, 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: <8BA15674-DDF6-4BA2-847D-211ABDFEE94D@googlemail.com> In-Reply-To: <6DAB33B7-0627-40AA-81DB-9853EAB7FB6D@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> <6DAB33B7-0627-40AA-81DB-9853EAB7FB6D@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I=E2=80=99m using a =E2=80=99special=E2=80=99 2019.10 u-boot - version =
,developed by a BSD-colleague,
where the dtb-clock-settings were backported to 2019.10 u-boot for =
Rock64.
Before using that special version I=E2=80=99ve booted FreeBSD on the =
Rock64 by
typing 'boot disk0s2:/boot/kernel/kernel=E2=80=98 at the prompt with a =
standard linux-uboot-version=20
by Ayufan .
> Am 23.12.2019 um 01:24 schrieb Mark Millard via freebsd-arm =
<freebsd-arm@freebsd.org>:
>=20
> [The start_init: message was a dumb thing to use as a
> reference point.]
>=20
> On 2019-Dec-22, at 15:06, Mark Millard <marklmi at yahoo.com> wrote:
>=20
>> [It has taken explicitly controlling the DTB used and
>> use of "boot -v" together to be able to boot to
>> completion . . .]
>>=20
>> On 2019-Dec-22, at 12:47, Mark Millard <marklmi at yahoo.com> wrote:
>>=20
>>> 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.)
>> . . .
>>=20
>> The following forced the desired .dtb to be used:
>>=20
>> # 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"
>> . . .
>>=20
>> 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.
>>=20
>> 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:
>>=20
>> Warning: no time-of-day clock registered, system time will not be set =
accurately
>> start_init: trying /sbin/init
>=20
> This was a dumb choice of reference point:
>=20
> while ((path =3D strsep(&tmp_init_path, ":")) !=3D NULL) {
> if (bootverbose)
> printf("start_init: trying %s\n", path);
>=20
> The message only shows up for bootverbose in the first place.
>=20
>> So far, no hang-up has shown part of the "start_init"
>> message line.
>=20
> Again, a dumb reference point to have used.
>=20
> A normal boot shows:
>=20
> . . .
> Root mount waiting for: CAM
> Warning: no time-of-day clock registered, system time will not be set =
accurately
> Setting hostuuid: . . .
> Setting hostid: . . .
> Starting file system checks:
> . . .
>=20
> So the real range for failure is between:
>=20
> Warning: no time-of-day clock registered, system time will not be set =
accurately
> Setting hostuuid: . . .
>=20
>=20
>> 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.
>>=20
>> (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.)
>>=20
>=20
> So far, trying a debug kernel is like trying "boot -v": the
> problem has not occurred (and there are no interesting
> messages).
>=20
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
>=20
> _______________________________________________
> freebsd-arm@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8BA15674-DDF6-4BA2-847D-211ABDFEE94D>