RockPro64 with latest image fails to boot?

[Bjoern A. Zeeb]

On 1 Aug 2020, at 17:04, Søren Schmidt wrote:

> On 1 Aug 2020, at 18.57, Emmanuel Vadot <manu at bidouilliste.com> wrote:
>>
>>
>> Hi Søren,
>>
>> On Sat, 1 Aug 2020 10:23:56 +0200
>> Søren Schmidt <soren.schmidt at gmail.com 
>> <mailto:soren.schmidt at gmail.com>> wrote:
>>
>>> Hi
>>>
>>> Just tried the latest snapshot:
>>>
>>> FreeBSD-13.0-CURRENT-arm64-aarch64-ROCKPRO64-20200730-r363681.img
>>
>> Just took the same snapshot and did a 'env default -a' just in case 
>> in
>> u-boot and I'm able to boot correctly with or without an hdmi monitor
>> attached.
>
> Wierd, but it is reproducible every time unfortunatly, here a verbose 
> boot with HDMI monitor attached:
>
> OK boot -v
> Using DTB provided by EFI at 0x80ea000.
> EFI framebuffer information:
> addr, size     0xf6000000, 0x7e9000
> dimensions     1920 x 1080
> stride         1920
> masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
> ---<<BOOT>>---
> KDB: debugger backends: ddb
> KDB: current backend: ddb
>                    Type     Physical      Virtual   #Pages Attr
>      ConventionalMemory 000000200000       200000 00007eea WB
>       ACPIReclaimMemory 0000080ea000      80ea000 0000002c WB
>      ConventionalMemory 000008116000      8116000 000e0d46 WB
>        BootServicesData 0000e8e5c000     e8e5c000 00000001 WB
>              LoaderData 0000e8e5d000     e8e5d000 00008001 WB
>              LoaderCode 0000f0e5e000     f0e5e000 000000aa WB
>                Reserved 0000f0f08000     f0f08000 00000005 WB
>        BootServicesData 0000f0f0d000     f0f0d000 00000001 WB
>     RuntimeServicesData 0000f0f0e000     f0f0e000 00000001 WB RUNTIME
>        BootServicesData 0000f0f0f000     f0f0f000 00000002 WB
>                Reserved 0000f0f11000     f0f11000 00000001 WB
>        BootServicesData 0000f0f12000     f0f12000 00000002 WB
>     RuntimeServicesData 0000f0f14000     f0f14000 00000002 WB RUNTIME
>                Reserved 0000f0f16000     f0f16000 00000001 WB
>        BootServicesData 0000f0f17000     f0f17000 00000001 WB
>                Reserved 0000f0f18000     f0f18000 00000001 WB
>        BootServicesData 0000f0f19000     f0f19000 00000002 WB
>                Reserved 0000f0f1b000     f0f1b000 00000004 WB
>              LoaderData 0000f0f1f000     f0f1f000 00003011 WB
>     RuntimeServicesCode 0000f3f30000     f3f30000 00000010 WB RUNTIME
>              LoaderData 0000f3f40000     f3f40000 000040c0 WB
> Physical memory chunk(s):
>   0x00200000 - 0x080e9fff,   126 MB (  32490 pages)
>   0x08116000 - 0xf0f07fff,  3725 MB ( 953842 pages)
>   0xf0f0d000 - 0xf0f10fff,     0 MB (      4 pages)
>   0xf0f12000 - 0xf0f15fff,     0 MB (      4 pages)
>   0xf0f17000 - 0xf0f17fff,     0 MB (      1 pages)
>   0xf0f19000 - 0xf0f1afff,     0 MB (      2 pages)
>   0xf0f1f000 - 0xf3f2ffff,    48 MB (  12305 pages)
>   0xf3f40000 - 0xf7ffffff,    64 MB (  16576 pages)
> Excluded memory regions:
>   0x080ea000 - 0x08115fff,     0 MB (     44 pages) NoAlloc
>   0xe9000000 - 0xea354fff,    19 MB (   4949 pages) NoAlloc
>   0xf0f08000 - 0xf0f0cfff,     0 MB (      5 pages) NoAlloc
>   0xf0f0e000 - 0xf0f0efff,     0 MB (      1 pages) NoAlloc
>   0xf0f11000 - 0xf0f11fff,     0 MB (      1 pages) NoAlloc
>   0xf0f14000 - 0xf0f16fff,     0 MB (      3 pages) NoAlloc
>   0xf0f18000 - 0xf0f18fff,     0 MB (      1 pages) NoAlloc
>   0xf0f1b000 - 0xf0f1efff,     0 MB (      4 pages) NoAlloc
>   0xf3f30000 - 0xf3f3ffff,     0 MB (     16 pages) NoAlloc
>   0xf6000000 - 0xf67e8fff,     7 MB (   2025 pages) NoAlloc
> Found 6 CPUs in the device tree
> Copyright (c) 1992-2020 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 
> 1994
> 	The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 13.0-CURRENT #0 r363681: Thu Jul 30 10:18:20 UTC 2020
>     root at releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC 
> arm64


In case you would be willing to try building a kernel yourself, try 
something with a lot of non-essential modules (e.g. the allwinner 
modules) removed and see what happens (just trying to make the size of 
the kernel smaller).


/bz