head -r357356: fails to boot RPi4 but boots Rock64 (same media, moved between machines); -r356426 booted both

[Mark Millard]

On 2020-Feb-1, at 20:32, Klaus Küchemann <maciphone2 at googlemail.com> wrote:



>> Am 02.02.2020 um 05:28 schrieb Mark Millard <marklmi at yahoo.com>:
>> 
>> [head -r357392 made no difference in the failure sequence
>> for booting the RPi4B.]
>> 
>> On 2020-Feb-1, at 16:11, Mark Millard <marklmi at yahoo.com> wrote:
>> 
>> 
>> 
>>> On 2020-Feb-1, at 14:25, Andreas Tobler <andreast-list at fgznet.ch> wrote:
>>> 
>>>> 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.)
>>>> 
>>>> I see the same on a rpi3b+. Try r356775, r356776 is the breaking commit for me.
>> 
>> I still get the above sort of thing from -r357392
>> (non-debug kernel, as I usually run).
>> 
>> I also still get "APs not started" and the like.
>> 
>> The fix seems to have made no difference for this issue.
>> If -r356775 really works, then there is more to the
>> -r356776 story.
>> 
>>> Looks like head -r357392 is an intended fix
>>> to head -r356776 :
>>> 
>>> Author: jeff
>>> Date: Sat Feb  1 23:46:30 2020
>>> New Revision: 357392
>>> URL: 
>>> https://svnweb.freebsd.org/changeset/base/357392
>>> 
>>> 
>>> 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.
>>> 
>>> Reported by:	pho, bdragon
>>> 
>>> Modified:
>>> head/sys/vm/uma_core.c
>>> 
>>> Modified: head/sys/vm/uma_core.c
>>> ==============================================================================
>>> --- 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) != 0)
>>> 		return;
>>> 	KEG_GET(zone, keg);
>>> -	if (keg->uk_allocf == startup_alloc)
>>> +	if (keg->uk_flags & UMA_ZONE_PCPU)
>>> +		keg->uk_allocf = pcpu_page_alloc;
>>> +	else if (keg->uk_allocf == startup_alloc)
>>> 		keg->uk_allocf = page_alloc;
>>> }
>>> 
>>> 
>>> I'll probably try it later today sometime.
>>> 
>> 
>> I tried -r357392 for the RPi4B boot issue, but it
>> was not a solution.
>> 
>> The fix may well be a solution to some other
>> issue(s).
>> 
>> ===
>> Mark Millard
>> marklmi at yahoo.com
>> ( dsl-only.net went
>> away in early 2018-Mar)
> 
> That was my guess because there’s nothing directly related to mmc issue in the code … ,
> Thanks for reporting !
> 

I keep saying that the "APs not started" issue
(for example) is likely not an mmc issue at all.

I got no noticeable behavior change in any
direction.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)