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
marklmi at yahoo.com
Sun Oct 4 08:42:05 UTC 2020
On 2020-Oct-3, at 20:15, Mark Millard <marklmi at yahoo.com> wrote:
> On 2020-Oct-3, at 16:10, Mark Millard <marklmi at yahoo.com> wrote:
>
>> On 2020-Oct-3, at 15:20, Mark Millard <marklmi at yahoo.com> wrote:
>>
>>> Another FreeBSD vs. ubuntu context difference, this time in the
>>> fdt print / output . . .
>>>
>>> The ubuntu u-boot has (fdt print / output):
>>>
>>> memreserve = <0x3b400000 0x04c00000>;
>>> . . . (Note: 0x3b400000+0x04c00000 == 0x40000000) . . .
>>>
>>> #address-cells = <0x00000002>;
>>> #size-cells = <0x00000001>;
>>> . . .
>>> axi {
>>> vc_mem {
>>> reg = <0x3ec00000 0x40000000 0xc0000000>;
>>> };
>>> Note: "vc_mem is solely used as a mechanism for passing a couple
>>> of parameters through from the firmware to vcdbg"
>>> End note
>>> };
>>>
>>> . . . ( boot args has: vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 ) . . .
>>>
>>> reserved-memory {
>>> #address-cells = <0x00000002>;
>>> #size-cells = <0x00000001>;
>>> ranges;
>>> phandle = <0x0000003d>;
>>> linux,cma {
>>> compatible = "shared-dma-pool";
>>> size = <0x04000000>;
>>> reusable;
>>> linux,cma-default;
>>> alloc-ranges = <0x00000000 0x00000000 0x30000000>;
>>> phandle = <0x0000003e>;
>>> };
>>> };
>>> . . . (I split the reg into lines below) . . .
>>> memory at 0 {
>>> device_type = "memory";
>>> reg = <0x00000000 0x00000000 0x3b400000
>>> 0x00000000 0x40000000 0xbc000000
>>> 0x00000001 0x00000000 0x80000000
>>> 0x00000001 0x80000000 0x80000000>;
>>> };
>>> . . . (Note: 0x40000000+0xbc000000 == 0xFC000000) . . .
>>>
>>> (I've ignored gpiomem above and below.)
>>>
>>> It appears to be that the memreserve may be important
>>> to have. The above may also suggest that FreeBSD's:
>>>
>>> #define DMA_HIGH_LIMIT 0x3c000000
>>>
>>> may be a little too large (< or <= 0x3b400000 ?).
>>>
>>> FreeBSD u-boot reports just:
>>>
>>> /memreserve/ 0x0 0x1000;
>>> . . .
>>> memory at 0 {
>>>
>>> device_type = "memory";
>>> reg = <0x0 0x0 0x0>;
>>> };
>>>
>>> And so does not indicate anything special for either of
>>> (showing begin/end points):
>>>
>>> 0x3b400000..0x3FFFFFFF (in use by the vc?)
>>> 0xFC000000..0xFFFFFFFF (I/O peripheral area and such?)
>>>
>>> The context is an 8 GiByte RPi4 in both examples. Various
>>> details would vary on 1 GiByte and 2 GiByte RPi4Bs and
>>> some in memory at 0 on the 4 GiBYTe RPi4B.
>>
>> Turns out that rpi_DATA_2711_1p0.pdf 's "Figure 1. BCM2711
>> Address Maps" shows this "SDRAM (for the VC)" area in the
>> two 35-bit Address Maps, showing 0x0_4000_0000 as the
>> next address after the area in both diagrams --and notes
>> for area for each diagram:
>>
>> QUOTE
>> Size of VC SDRAM
>> determined by
>> config.txt
>> END QUOTE
>>
>> But ubuntu uses includes and such so overall there
>> are the following .txt files ( cmdline.txt being for
>> a different purpose ):
>>
>> # ls -ld /boot/firmware/*.txt
>> -rwxr-xr-x 1 root root 141 Jul 31 16:48 /boot/firmware/cmdline.txt
>> -rwxr-xr-x 1 root root 1117 Jul 31 16:48 /boot/firmware/config.txt
>> -rwxr-xr-x 1 root root 327 Jul 31 16:48 /boot/firmware/syscfg.txt
>> -rwxr-xr-x 1 root root 251 Sep 26 22:14 /boot/firmware/usercfg.txt
>>
>> config.txt includes syscfg.txt and usercfg.txt .
>>
>> config.txt uses the [pi4], [pi2], [pi3], and [all] section
>> notation as well.
>>
>> Looks like one of u-boot's jobs is to figure out the figures
>> that go in (base then size):
>>
>> memreserve = <0x???????? 0x????????>;
>>
>> (such that the total is 0x40000000 for the RPi4B) in order
>> to protect the VC SDRAM area.
>>
>>
>> The diagrams also indicate that 0xFC000000..0xFFFFFFFF is
>> for when "low Perioheral" mode is in use, listing ("up
>> to H" not including H):
>>
>> ARM Local peripherals from 0x0_FF80_0000 up to 0x1_0000_0000
>> and:
>> Main peripherals from 0x0_FC00_0000 up to 0x0_FF80_0000
>>
>> Otherwise they are listed at:
>>
>> ARM Local peripherals from 0x4_C000_0000 up to 0x5_0000_0000
>> and:
>> Main peripherals from 0x4_7C00_0000 up to 0x4_8000_0000
>>
>> I gather the ubuntu "fdt print /" result implies that ubuntu
>> is using "Low Peripheral" mode (or at least allowing for it).
>>
>> There are some other "Reserved" areas and the special areas
>> that are "two L2 cache aliases (one allocating, one
>> non-allocating) which cache (only) the first 1GB of SDRAM".
>> if these are all counted then 0x4_0000_0000 up to
>> 0x6_0000_0000 is all some form of special-use area in
>> both diagrams and 0x6_0000_0000 through 0x7_FFFF_FFFF is the
>> PCIe area in both diagams.
>
>
> Looks like in ubuntu land the following from the dtb/fdt
> work together(?) to cover avoiding memory that is
> inappropriate for use for low-RAM DMA activity:
>
> U-Boot> fdt print /
> / {
> memreserve = <0x3b400000 0x04c00000>;
> . . . (Note: 0x3b400000+0x04c00000 == 0x40000000) . . .
> reserved-memory {
> #address-cells = <0x00000002>;
> #size-cells = <0x00000001>;
> ranges;
> phandle = <0x0000003d>;
> linux,cma {
> compatible = "shared-dma-pool";
> size = <0x04000000>;
> reusable;
> linux,cma-default;
> alloc-ranges = <0x00000000 0x00000000 0x30000000>;
> phandle = <0x0000003e>;
> };
> };
> . . .
>
> where:
>
> alloc-ranges = <0x00000000 0x00000000 0x30000000> indicates a low
> memory range to use for "shared-dma-pool" DMA activity.
>
> memreserve = <0x3b400000 0x04c00000> indicates the actual
> area in use for gnu_mem=/gnu_mem_1024= material and so indicates
> an area that must be avoided. It appears that this adjusts based
> on what config.txt has for (either of) gnu_mem=/gnu_mem_1024= .
>
> It appears that the alloc-ranges=... above allows for the maximum
> recommended gpu_mem/gnu_mem_1024 figure for the RPi4B and so,
> if that limit is honored, avoids overlapping the memreserve. This
> may suggest that your code should change to:
>
> #define DMA_HIGH_LIMIT 0x30000000
>
>
> XHCI and the type-DMA4 engine use need to explicitly avoid the
> memreserve area. The old normal/LITE DMA could be redirected to
> use a different 1 GiByte range (shifted above the memreserve
> when there is enough RAM to do so).
>
>
> The more modern dtb/fdt's that I use in some contexts have the
> reserved-memory linux,cma alloc-ranges. (I'm not claiming such
> information is translated to uefi/ACPI.) But the old dtb/fdt's
> used with FreeBSD u-boot do not indicate those alloc-ranges.
>
> The u-boot for FreeBSD that I'm using (from ports) does not
> generate the memreserve material so neither the old or new
> fdt's end up with such material.
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
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
0x3e513000 - 0x3ebebfff, 6 MB ( 1753 pages) NoAlloc
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)
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
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.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
More information about the freebsd-arm
mailing list