Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 2 Feb 2020 05:32:46 +0100
From:      =?utf-8?Q?Klaus_K=C3=BCchemann?= <maciphone2@googlemail.com>
To:        Mark Millard <marklmi@yahoo.com>, freebsd-arm@freebsd.org
Subject:   Re: head -r357356: fails to boot RPi4 but boots Rock64 (same media, moved between machines); -r356426 booted both
Message-ID:  <E74D74DA-5436-4B3A-9075-3897357963C7@googlemail.com>
In-Reply-To: <78694513-66DE-4616-91C0-896D99C97B33@yahoo.com>
References:  <63205335-8E8A-4CCB-BC80-E4EC767FBC09.ref@yahoo.com> <63205335-8E8A-4CCB-BC80-E4EC767FBC09@yahoo.com> <e083e017-af5a-e219-3a3c-bc82b16c6027@fgznet.ch> <62250B30-E1F6-470D-BB84-F9565D063A06@yahoo.com> <78694513-66DE-4616-91C0-896D99C97B33@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help


> Am 02.02.2020 um 05:28 schrieb Mark Millard <marklmi@yahoo.com>:
>=20
> [head -r357392 made no difference in the failure sequence
> for booting the RPi4B.]
>=20
> On 2020-Feb-1, at 16:11, Mark Millard <marklmi at yahoo.com =
<http://yahoo.com/>>; wrote:
>=20
>=20
>=20
>> On 2020-Feb-1, at 14:25, Andreas Tobler <andreast-list at fgznet.ch> =
wrote:
>>=20
>>> On 01.02.20 12:58, Mark Millard via freebsd-arm wrote:
>>>> I had a working head -r356426 based microSD card that booted
>>>> both the Rock64 and the RPi4.
>>>> I upgraded it to be based on head -r357356 .
>>>> Now the RPi4B hangs up during boot and does not start its APs.
>>>> But the Rock64 boots fine via the same media.
>>>> Diffing RPi4B console logs for -r356426 vs. -r357356 shows
>>>> -r357356 shw the following as the only types of
>>>> textual differences:
>>>> psci0: PSCI version number mismatched with DT
>>>> device_attach: psci0 attach returned 6
>>>> psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
>>>> psci0: PSCI version number mismatched with DT
>>>> device_attach: psci0 attach returned 6
>>>> psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
>>>> psci0: PSCI version number mismatched with DT
>>>> device_attach: psci0 attach returned 6
>>>> psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
>>>> psci0: PSCI version number mismatched with DT
>>>> device_attach: psci0 attach returned 6
>>>> psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
>>>> psci0: PSCI version number mismatched with DT
>>>> device_attach: psci0 attach returned 6
>>>> psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
>>>> psci0: PSCI version number mismatched with DT
>>>> device_attach: psci0 attach returned 6
>>>> psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
>>>> psci0: PSCI version number mismatched with DT
>>>> device_attach: psci0 attach returned 6
>>>> psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
>>>> psci0: PSCI version number mismatched with DT
>>>> (More blocks of 3 such lines at a time happen later as well.)
>>>=20
>>> I see the same on a rpi3b+. Try r356775, r356776 is the breaking =
commit for me.
>=20
> I still get the above sort of thing from -r357392
> (non-debug kernel, as I usually run).
>=20
> I also still get "APs not started" and the like.
>=20
> The fix seems to have made no difference for this issue.
> If -r356775 really works, then there is more to the
> -r356776 story.
>=20
>> Looks like head -r357392 is an intended fix
>> to head -r356776 :
>>=20
>> Author: jeff
>> Date: Sat Feb  1 23:46:30 2020
>> New Revision: 357392
>> URL:=20
>> https://svnweb.freebsd.org/changeset/base/357392
>>=20
>>=20
>> Log:
>> Fix a bug in r356776 where the page allocator was not properly =
restored to
>> the percpu page allocator after it had been temporarily overridden by
>> startup_alloc.
>>=20
>> Reported by:	pho, bdragon
>>=20
>> Modified:
>> head/sys/vm/uma_core.c
>>=20
>> Modified: head/sys/vm/uma_core.c
>> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
>> --- head/sys/vm/uma_core.c	Sat Feb  1 23:16:30 2020	=
(r357391)
>> +++ head/sys/vm/uma_core.c	Sat Feb  1 23:46:30 2020	=
(r357392)
>> @@ -2101,7 +2101,9 @@ zone_kva_available(uma_zone_t zone, void =
*unused)
>> 	if ((zone->uz_flags & UMA_ZFLAG_CACHE) !=3D 0)
>> 		return;
>> 	KEG_GET(zone, keg);
>> -	if (keg->uk_allocf =3D=3D startup_alloc)
>> +	if (keg->uk_flags & UMA_ZONE_PCPU)
>> +		keg->uk_allocf =3D pcpu_page_alloc;
>> +	else if (keg->uk_allocf =3D=3D startup_alloc)
>> 		keg->uk_allocf =3D page_alloc;
>> }
>>=20
>>=20
>> I'll probably try it later today sometime.
>>=20
>=20
> I tried -r357392 for the RPi4B boot issue, but it
> was not a solution.
>=20
> The fix may well be a solution to some other
> issue(s).
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com <http://yahoo.com/>;
> ( dsl-only.net <http://dsl-only.net/>; went
> away in early 2018-Mar)

That was my guess because there=E2=80=99s nothing directly related to =
mmc issue in the code =E2=80=A6 ,
Thanks for reporting !

Regards

Klaus=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E74D74DA-5436-4B3A-9075-3897357963C7>