Re: rpi4 FreeBSD vs. ubuntu u-boot fdt print / memereserve difference (lack of reserve in FreeBSD context), 0x3b400000 vs. DMA_HIGH_LIMIT being 0x3c000000
Mark Millard via freebsd-arm <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.arm |
|---|---|
| Message-ID | <[email protected]> |
On 2020-Oct-4, at 01:41, Mark Millard <marklmi at yahoo.com> wrote:
>
> On 2020-Oct-3, at 20:15, Mark Millard <marklmi at yahoo.com> wrote:
>
>> . . .
>
> Looking at the FreeBSD boot-time memory map
> on the 8 GiByte RPi4B via a u-boot based boot
> shows that the address ranges
> 0x3b400000..0x3e512fff and
> 0x3ebec000..0x3fffffff are not referenced
> below (I inserted some notes):
>
> Type Physical Virtual #Pages Attr
> Reserved 000000000000 0 00000002 WB
> ConventionalMemory 000000002000 2000 00007eef WB
> ACPIReclaimMemory 000007ef1000 7ef1000 0000001e WB
> ConventionalMemory 000007f0f000 7f0f000 00029f71 WB
> BootServicesData 000031e80000 31e80000 00000001 WB
> LoaderData 000031e81000 31e81000 00008001 WB
> LoaderCode 000039e82000 39e82000 000000ad WB
> Reserved 000039f2f000 39f2f000 00000007 WB
> BootServicesData 000039f36000 39f36000 00000001 WB
> RuntimeServicesData 000039f37000 39f37000 00000001 WB RUNTIME
> BootServicesData 000039f38000 39f38000 00000002 WB
> Reserved 000039f3a000 39f3a000 00000001 WB
> BootServicesData 000039f3b000 39f3b000 00000002 WB
> RuntimeServicesData 000039f3d000 39f3d000 00000002 WB RUNTIME
> Reserved 000039f3f000 39f3f000 00000001 WB
> BootServicesData 000039f40000 39f40000 00000001 WB
> Reserved 000039f41000 39f41000 00000001 WB
> BootServicesData 000039f42000 39f42000 00000002 WB
> Reserved 000039f44000 39f44000 00000001 WB
> LoaderData 000039f45000 39f45000 0000140b WB
> RuntimeServicesCode 00003b350000 3b350000 00000010 WB RUNTIME
> LoaderData 00003b360000 3b360000 000000a0 WB
> NOTE: Here is where 0x3b400000..0x3e512fff is not mentioned at all (even later)
> NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all (even later)
> BootServicesData 000040000000 40000000 000bc000 WB
> MemoryMappedIO 0000fe100000 fe100000 00000001 RUNTIME
> BootServicesData 000100000000 100000000 00100000 WB
> Physical memory chunk(s):
> 0x00002000 - 0x07ef0fff, 126 MB ( 32495 pages)
> 0x07f0f000 - 0x39f2efff, 800 MB ( 204832 pages)
> 0x39f36000 - 0x39f39fff, 0 MB ( 4 pages)
> 0x39f3b000 - 0x39f3efff, 0 MB ( 4 pages)
> 0x39f40000 - 0x39f40fff, 0 MB ( 1 pages)
> 0x39f42000 - 0x39f43fff, 0 MB ( 2 pages)
> 0x39f45000 - 0x3b34ffff, 20 MB ( 5131 pages)
> 0x3b360000 - 0x3b3fffff, 0 MB ( 160 pages)
> NOTE: Here is where 0x3b400000..0x3e512fff is not mentioned at all (even later)
> NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all (even later)
> 0x40000000 - 0xfbffffff, 3008 MB ( 770048 pages)
> 0x100000000 - 0x1ffffffff, 4096 MB (1048576 pages)
> Excluded memory regions:
> 0x00000000 - 0x00001fff, 0 MB ( 2 pages) NoAlloc
> 0x07ef1000 - 0x07f0efff, 0 MB ( 30 pages) NoAlloc
> 0x32000000 - 0x33451fff, 20 MB ( 5202 pages) NoAlloc
> 0x39f2f000 - 0x39f35fff, 0 MB ( 7 pages) NoAlloc
> 0x39f37000 - 0x39f37fff, 0 MB ( 1 pages) NoAlloc
> 0x39f3a000 - 0x39f3afff, 0 MB ( 1 pages) NoAlloc
> 0x39f3d000 - 0x39f3ffff, 0 MB ( 3 pages) NoAlloc
> 0x39f41000 - 0x39f41fff, 0 MB ( 1 pages) NoAlloc
> 0x39f44000 - 0x39f44fff, 0 MB ( 1 pages) NoAlloc
> 0x3b350000 - 0x3b35ffff, 0 MB ( 16 pages) NoAlloc
> NOTE: Here is where 0x3b400000..0x3e512fff is not mentioned at all (even above)
> 0x3e513000 - 0x3ebebfff, 6 MB ( 1753 pages) NoAlloc
Looks like the above "NoAlloc" line is from:
/* Exclude the EFI framebuffer from our view of physical memory. */
efifb = (struct efi_fb *)preload_search_info(kmdp,
MODINFO_METADATA | MODINFOMD_EFI_FB);
if (efifb != NULL)
physmem_exclude_region(efifb->fb_addr, efifb->fb_size,
EXFLAG_NOALLOC);
However, for the RPi4B, it looks like the EFI FrameBuffer is in a
subrange of the more general "gpu_mem" area that can be sized by
doing gpu_mem= or gpu_mem_1024= via config.txt . The size varies
by changing the smaller memory address and runs to the end of the
1 GiByte area on RPi4B's.
At least this gives a reason for the one NoAlloc range that did
show up that is in the gpu_mem=/gpu_mem_1024= area (but without a
containing "Physical memory chunk").
In the end, I do not expect that this contributes to the issue
at hand: phys_avail and the like seem to omit the whole gpu_mem=
area and so it looks like the gpu_mem= memory is avoided for
allocation.
> NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all (even above)
> 0xfe100000 - 0xfe100fff, 0 MB ( 1 pages) NoAlloc
>
> Physical memory chunk(s):
> 0x00000000002000 - 0x00000007ef0fff, 133099520 bytes (32495 pages)
> 0x00000007f0f000 - 0x00000031ffffff, 705630208 bytes (172273 pages)
> 0x00000033452000 - 0x00000039f2efff, 112054272 bytes (27357 pages)
> 0x00000039f36000 - 0x00000039f36fff, 4096 bytes (1 pages)
> 0x00000039f38000 - 0x00000039f39fff, 8192 bytes (2 pages)
> 0x00000039f3b000 - 0x00000039f3cfff, 8192 bytes (2 pages)
> 0x00000039f40000 - 0x00000039f40fff, 4096 bytes (1 pages)
> 0x00000039f42000 - 0x00000039f43fff, 8192 bytes (2 pages)
> 0x00000039f45000 - 0x0000003b34ffff, 21016576 bytes (5131 pages)
> 0x0000003b360000 - 0x0000003b3fffff, 655360 bytes (160 pages)
> NOTE: Here is where 0x3b400000..0x3e512fff is not mentioned at all (even above)
> NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all (even above)
> 0x00000040000000 - 0x000000fbffffff, 3154116608 bytes (770048 pages)
> 0x00000100000000 - 0x000001f3840fff, 4085518336 bytes (997441 pages)
>
> So:
>
> #define DMA_HIGH_LIMIT 0x3c000000
>
> leads to the range for potential DMA use seeming to
> overlap 0x3b400000..0x3bffffff (which is not mentioned
> above).
>
> Should the missing ranges have a classification above?
> Is the lack of mention supposed to prevent the range
> of memory's use for DMA activity?
>
> I'll note that there are a bunch of explicitly "Excluded
> memory regions" that overlap with the range for potential
> DMA use as well.
>
> Note: Use of gpu_mem_1024=256 in config.txt instead
> produces (notes added again):
>
> Type Physical Virtual #Pages Attr
> Reserved 000000000000 0 00000002 WB
> ConventionalMemory 000000002000 2000 00007eef WB
> ACPIReclaimMemory 000007ef1000 7ef1000 0000001e WB
> ConventionalMemory 000007f0f000 7f0f000 0001eb71 WB
> BootServicesData 000026a80000 26a80000 00000001 WB
> LoaderData 000026a81000 26a81000 00008001 WB
> LoaderCode 00002ea82000 2ea82000 000000ad WB
> Reserved 00002eb2f000 2eb2f000 00000007 WB
> BootServicesData 00002eb36000 2eb36000 00000001 WB
> RuntimeServicesData 00002eb37000 2eb37000 00000001 WB RUNTIME
> BootServicesData 00002eb38000 2eb38000 00000002 WB
> Reserved 00002eb3a000 2eb3a000 00000001 WB
> BootServicesData 00002eb3b000 2eb3b000 00000002 WB
> RuntimeServicesData 00002eb3d000 2eb3d000 00000002 WB RUNTIME
> Reserved 00002eb3f000 2eb3f000 00000001 WB
> BootServicesData 00002eb40000 2eb40000 00000001 WB
> Reserved 00002eb41000 2eb41000 00000001 WB
> BootServicesData 00002eb42000 2eb42000 00000002 WB
> Reserved 00002eb44000 2eb44000 00000001 WB
> LoaderData 00002eb45000 2eb45000 0000140b WB
> RuntimeServicesCode 00002ff50000 2ff50000 00000010 WB RUNTIME
> LoaderData 00002ff60000 2ff60000 000000a0 WB
> NOTE: Here is where 0x30000000..0x3e512fff is not mentioned at all (even below)
> NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all (even below)
> BootServicesData 000040000000 40000000 000bc000 WB
> MemoryMappedIO 0000fe100000 fe100000 00000001 RUNTIME
> BootServicesData 000100000000 100000000 00100000 WB
> Physical memory chunk(s):
> 0x00002000 - 0x07ef0fff, 126 MB ( 32495 pages)
> 0x07f0f000 - 0x2eb2efff, 620 MB ( 158752 pages)
> 0x2eb36000 - 0x2eb39fff, 0 MB ( 4 pages)
> 0x2eb3b000 - 0x2eb3efff, 0 MB ( 4 pages)
> 0x2eb40000 - 0x2eb40fff, 0 MB ( 1 pages)
> 0x2eb42000 - 0x2eb43fff, 0 MB ( 2 pages)
> 0x2eb45000 - 0x2ff4ffff, 20 MB ( 5131 pages)
> 0x2ff60000 - 0x2fffffff, 0 MB ( 160 pages)
> NOTE: Here is where 0x30000000..0x3e512fff is not mentioned at all (even below)
> NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all (even below)
> 0x40000000 - 0xfbffffff, 3008 MB ( 770048 pages)
> 0x100000000 - 0x1ffffffff, 4096 MB (1048576 pages)
> Excluded memory regions:
> 0x00000000 - 0x00001fff, 0 MB ( 2 pages) NoAlloc
> 0x07ef1000 - 0x07f0efff, 0 MB ( 30 pages) NoAlloc
> 0x26c00000 - 0x28051fff, 20 MB ( 5202 pages) NoAlloc
> 0x2eb2f000 - 0x2eb35fff, 0 MB ( 7 pages) NoAlloc
> 0x2eb37000 - 0x2eb37fff, 0 MB ( 1 pages) NoAlloc
> 0x2eb3a000 - 0x2eb3afff, 0 MB ( 1 pages) NoAlloc
> 0x2eb3d000 - 0x2eb3ffff, 0 MB ( 3 pages) NoAlloc
> 0x2eb41000 - 0x2eb41fff, 0 MB ( 1 pages) NoAlloc
> 0x2eb44000 - 0x2eb44fff, 0 MB ( 1 pages) NoAlloc
> 0x2ff50000 - 0x2ff5ffff, 0 MB ( 16 pages) NoAlloc
(Line that was here moved down to track address-range ordering.)
> NOTE: Here is where 0x30000000..0x3e512fff is not mentioned at all (even above)
0x3e513000 - 0x3ebebfff, 6 MB ( 1753 pages) NoAlloc
(Again the EFI framebuffer.)
> NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all (even above)
> 0xfe100000 - 0xfe100fff, 0 MB ( 1 pages) NoAlloc
>
> Physical memory chunk(s):
> 0x00000000002000 - 0x00000007ef0fff, 133099520 bytes (32495 pages)
> 0x00000007f0f000 - 0x00000026bfffff, 516886528 bytes (126193 pages)
> 0x00000028052000 - 0x0000002eb2efff, 112054272 bytes (27357 pages)
> 0x0000002eb36000 - 0x0000002eb36fff, 4096 bytes (1 pages)
> 0x0000002eb38000 - 0x0000002eb39fff, 8192 bytes (2 pages)
> 0x0000002eb3b000 - 0x0000002eb3cfff, 8192 bytes (2 pages)
> 0x0000002eb40000 - 0x0000002eb40fff, 4096 bytes (1 pages)
> 0x0000002eb42000 - 0x0000002eb43fff, 8192 bytes (2 pages)
> 0x0000002eb45000 - 0x0000002ff4ffff, 21016576 bytes (5131 pages)
> 0x0000002ff60000 - 0x0000002fffffff, 655360 bytes (160 pages)
> NOTE: Here is where 0x30000000..0x3e512fff is not mentioned at all (even above)
> NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all (even above)
> 0x00000040000000 - 0x000000fbffffff, 3154116608 bytes (770048 pages)
> 0x00000100000000 - 0x000001f3cb5fff, 4090191872 bytes (998582 pages)
>
>
> (Note: gpu_mem_1024=16 leads to the rpi firmware
> messing up and being unable to read the microsd card
> for later rpi firmware files that it needs. It
> actually ended up doing a USB3 SSD based boot, in
> my context a uefi/ACPI boot.)
>
>
> gpu_mem_1024=32 produced (no notes this time):
>
> Type Physical Virtual #Pages Attr
> Reserved 000000000000 0 00000002 WB
> ConventionalMemory 000000002000 2000 00007eef WB
> ACPIReclaimMemory 000007ef1000 7ef1000 0000001e WB
> ConventionalMemory 000007f0f000 7f0f000 0002cb71 WB
> BootServicesData 000034a80000 34a80000 00000001 WB
> LoaderData 000034a81000 34a81000 00008001 WB
> LoaderCode 00003ca82000 3ca82000 000000ad WB
> Reserved 00003cb2f000 3cb2f000 00000007 WB
> BootServicesData 00003cb36000 3cb36000 00000001 WB
> RuntimeServicesData 00003cb37000 3cb37000 00000001 WB RUNTIME
> BootServicesData 00003cb38000 3cb38000 00000002 WB
> Reserved 00003cb3a000 3cb3a000 00000001 WB
> BootServicesData 00003cb3b000 3cb3b000 00000002 WB
> RuntimeServicesData 00003cb3d000 3cb3d000 00000002 WB RUNTIME
> Reserved 00003cb3f000 3cb3f000 00000001 WB
> BootServicesData 00003cb40000 3cb40000 00000001 WB
> Reserved 00003cb41000 3cb41000 00000001 WB
> BootServicesData 00003cb42000 3cb42000 00000002 WB
> Reserved 00003cb44000 3cb44000 00000001 WB
> LoaderData 00003cb45000 3cb45000 0000140b WB
> RuntimeServicesCode 00003df50000 3df50000 00000010 WB RUNTIME
> LoaderData 00003df60000 3df60000 000000a0 WB
> BootServicesData 000040000000 40000000 000bc000 WB
> MemoryMappedIO 0000fe100000 fe100000 00000001 RUNTIME
> BootServicesData 000100000000 100000000 00100000 WB
> Physical memory chunk(s):
> 0x00002000 - 0x07ef0fff, 126 MB ( 32495 pages)
> 0x07f0f000 - 0x3cb2efff, 844 MB ( 216096 pages)
> 0x3cb36000 - 0x3cb39fff, 0 MB ( 4 pages)
> 0x3cb3b000 - 0x3cb3efff, 0 MB ( 4 pages)
> 0x3cb40000 - 0x3cb40fff, 0 MB ( 1 pages)
> 0x3cb42000 - 0x3cb43fff, 0 MB ( 2 pages)
> 0x3cb45000 - 0x3df4ffff, 20 MB ( 5131 pages)
> 0x3df60000 - 0x3dffffff, 0 MB ( 160 pages)
> 0x40000000 - 0xfbffffff, 3008 MB ( 770048 pages)
> 0x100000000 - 0x1ffffffff, 4096 MB (1048576 pages)
> Excluded memory regions:
> 0x00000000 - 0x00001fff, 0 MB ( 2 pages) NoAlloc
> 0x07ef1000 - 0x07f0efff, 0 MB ( 30 pages) NoAlloc
> 0x34c00000 - 0x36051fff, 20 MB ( 5202 pages) NoAlloc
> 0x3cb2f000 - 0x3cb35fff, 0 MB ( 7 pages) NoAlloc
> 0x3cb37000 - 0x3cb37fff, 0 MB ( 1 pages) NoAlloc
> 0x3cb3a000 - 0x3cb3afff, 0 MB ( 1 pages) NoAlloc
> 0x3cb3d000 - 0x3cb3ffff, 0 MB ( 3 pages) NoAlloc
> 0x3cb41000 - 0x3cb41fff, 0 MB ( 1 pages) NoAlloc
> 0x3cb44000 - 0x3cb44fff, 0 MB ( 1 pages) NoAlloc
> 0x3df50000 - 0x3df5ffff, 0 MB ( 16 pages) NoAlloc
> 0x3e513000 - 0x3ebebfff, 6 MB ( 1753 pages) NoAlloc
(Above: again the EFI framebuffer inside the bigger
gpu_mem area.)
> 0xfe100000 - 0xfe100fff, 0 MB ( 1 pages) NoAlloc
>
> Physical memory chunk(s):
> 0x00000000002000 - 0x00000007ef0fff, 133099520 bytes (32495 pages)
> 0x00000007f0f000 - 0x00000034bfffff, 751767552 bytes (183537 pages)
> 0x00000036052000 - 0x0000003cb2efff, 112054272 bytes (27357 pages)
> 0x0000003cb36000 - 0x0000003cb36fff, 4096 bytes (1 pages)
> 0x0000003cb38000 - 0x0000003cb39fff, 8192 bytes (2 pages)
> 0x0000003cb3b000 - 0x0000003cb3cfff, 8192 bytes (2 pages)
> 0x0000003cb40000 - 0x0000003cb40fff, 4096 bytes (1 pages)
> 0x0000003cb42000 - 0x0000003cb43fff, 8192 bytes (2 pages)
> 0x0000003cb45000 - 0x0000003df4ffff, 21016576 bytes (5131 pages)
> 0x0000003df60000 - 0x0000003dffffff, 655360 bytes (160 pages)
> 0x00000040000000 - 0x000000fbffffff, 3154116608 bytes (770048 pages)
> 0x00000100000000 - 0x000001f372afff, 4084379648 bytes (997163 pages)
>
>
> I wonder if such could be contributing to why
> DMA_HIGH_LIMIT had to be set smaller than the
> 3 GiByte limit: to under a 1 GiByte limit.
It looks like my ACPI boots are getting the EFI framebuffer
being more like (default gpu_mem example, as I remember):
0x3e2fe000 - 0x3eae6fff, 7 MB ( 2025 pages) NoAlloc
again not having a containing "Physical memory chunk" (and,
again in the gpu_mem=/gpu_mem_1024= area).
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"