RPi3 not using SMP?

[Mark Millard]

On 2020-Feb-8, at 14:28, Mark Millard <marklmi at yahoo.com> wrote:


> . . .

History omitted. Here I target what u-boot fdt print
reports for the 4 GiByte RPi4B vs. what FreeBSD
reports.

I had u-boot print the fdt and found:

U-Boot> fdt addr 0x7ef2000 
U-Boot> fdt print /       
/ {
        memreserve = <0x3b400000 0x04c00000>;
. . .
        framebuffer at 3e513000 {
                format = "a8r8g8b8";
                stride = <0x00001c80>;
                height = <0x000003d8>;
                width = <0x00000720>;
                reg = <0x00000000 0x3e513000 0x006d8c00>;
                compatible = "simple-framebuffer";
                status = "okay";
        };
. . .
        psci {
                compatible = "arm,psci-0.2";
                method = "smc";
        };
. . .
        axi {
                vc_mem {
                        reg = <0x3ec00000 0x40000000 0xc0000000>;
                };
        };
. . .
        memory at 0 {
                device_type = "memory";
                reg = <0x00000000 0x00000000 0x3b400000 0x00000000 0x40000000 0xbc000000>;
        };
. . .
};
U-Boot> 

(I may have missed interesting RAM region items. The material
is not familiar.)

boot -v showed (including here I get the fdt addr from):

OK boot -v
Using DTB provided by EFI at 0x7ef2000.
. . .
                   Type     Physical      Virtual   #Pages Attr
               Reserved 000000000000            0 00000001 WB 
     ConventionalMemory 000000001000         1000 00007ef1 WB 
       BootServicesData 000007ef2000      7ef2000 0000001c WB 
     ConventionalMemory 000007f0e000      7f0e000 00029f93 WB 
       BootServicesData 000031ea1000     31ea1000 00000001 WB 
             LoaderData 000031ea2000     31ea2000 00008001 WB 
             LoaderCode 000039ea3000     39ea3000 000000a6 WB 
               Reserved 000039f49000     39f49000 00000007 WB 
       BootServicesData 000039f50000     39f50000 00000001 WB 
               Reserved 000039f51000     39f51000 00000002 WB 
    RuntimeServicesData 000039f53000     39f53000 00000001 WB RUNTIME
               Reserved 000039f54000     39f54000 00000001 WB 
       BootServicesData 000039f55000     39f55000 00000002 WB 
    RuntimeServicesData 000039f57000     39f57000 00000001 WB RUNTIME
             LoaderData 000039f58000     39f58000 00001408 WB 
    RuntimeServicesCode 00003b360000     3b360000 00000010 WB RUNTIME
             LoaderData 00003b370000     3b370000 00000090 WB 
       BootServicesData 000040000000     40000000 000bc000 WB 
         MemoryMappedIO 0000fe100000     fe100000 00000001 RUNTIME
Physical memory chunk(s):
  0x00001000 - 0x39f48fff,   927 MB ( 237384 pages)
  0x39f50000 - 0x39f50fff,     0 MB (      1 pages)
  0x39f53000 - 0x39f53fff,     0 MB (      1 pages)
  0x39f55000 - 0x3b35ffff,    20 MB (   5131 pages)
  0x3b370000 - 0x3b3fffff,     0 MB (    144 pages)
  0x40000000 - 0xfbffffff,  3008 MB ( 770048 pages)
Excluded memory regions:
  0x00000000 - 0x00000fff,     0 MB (      1 pages) NoAlloc 
  0x32000000 - 0x33773fff,    23 MB (   6004 pages) NoAlloc 
  0x39f49000 - 0x39f4ffff,     0 MB (      7 pages) NoAlloc 
  0x39f51000 - 0x39f54fff,     0 MB (      4 pages) NoAlloc 
  0x39f57000 - 0x39f57fff,     0 MB (      1 pages) NoAlloc 
  0x3b360000 - 0x3b36ffff,     0 MB (     16 pages) NoAlloc 
  0x3e513000 - 0x3ebebfff,     6 MB (   1753 pages) NoAlloc 
  0xfe100000 - 0xfe100fff,     0 MB (      1 pages) NoAlloc



If I gather right, memreserve = <0x3b400000 0x04c00000> should
reserve 0x3b400000 - 0x3FFFFFFF . To me, that makes the
1753 pages line for the Excluded list seem odd:

 (0x3b400000 - 0x3FFFFFFF)
  0x3e513000 - 0x3ebebfff,     6 MB (   1753 pages) NoAlloc

Although, the Physical memory chunk(s) list does omit
the whole range 0x3b400000 - 0x3FFFFFFF. So may be the
exclusion region is a no-op of some kind?

Hmm. Looks like the exclusion contains the framebuffer:

        framebuffer at 3e513000 {
                format = "a8r8g8b8";
                stride = <0x00001c80>;
                height = <0x000003d8>;
                width = <0x00000720>;
                reg = <0x00000000 0x3e513000 0x006d8c00>;
                compatible = "simple-framebuffer";
                status = "okay";
        };

That looks like it spans: 0x3e513000 - 0x3EBEBBFF. So
0x3e513000 - 0x3ebebfff goes to the end of the last
page. The framebuffer just happens to already be inside
reserved region (by design, I expect).

(I added the frame buffer earlier in this note.)


I'm less sure of interpreting axi's vc_mem and memory at 0
so I just show them for reference.


There may be more things that I should extract from the
print and include. I'll keep the print around for a
while for such in case someone asks.



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