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

Klaus Küchemann maciphone2 at googlemail.com
Sun Feb 2 04:32:50 UTC 2020



> 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 <http://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 <http://yahoo.com/>
> ( dsl-only.net <http://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 !

Regards

Klaus


More information about the freebsd-arm mailing list