Date: Sun, 9 Feb 2020 15:56:44 -0800 From: Mark Millard <marklmi@yahoo.com> To: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: RPi3 not using SMP? Message-ID: <19B0635A-6FD3-43BA-A3EE-60C168228109@yahoo.com> In-Reply-To: <E5DFA1BD-3BB4-4ED2-9E8C-E9CEA1CB0927@yahoo.com> References: <20200208011940.GA8570@www.zefox.net> <6B6CCB8F-B56A-4758-BEEC-6418718C95CB@yahoo.com> <9F1B762C-D1DA-40F6-A2D6-451B40A39E4A@yahoo.com> <CF5FC50C-FDE5-434C-BADC-2AE7D3348663@yahoo.com> <142E83E3-CD79-43B3-A86A-2AD45A778FB5@yahoo.com> <E5DFA1BD-3BB4-4ED2-9E8C-E9CEA1CB0927@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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=20
U-Boot> fdt print / =20
/ {
memreserve =3D <0x3b400000 0x04c00000>;
. . .
framebuffer@3e513000 {
format =3D "a8r8g8b8";
stride =3D <0x00001c80>;
height =3D <0x000003d8>;
width =3D <0x00000720>;
reg =3D <0x00000000 0x3e513000 0x006d8c00>;
compatible =3D "simple-framebuffer";
status =3D "okay";
};
. . .
psci {
compatible =3D "arm,psci-0.2";
method =3D "smc";
};
. . .
axi {
vc_mem {
reg =3D <0x3ec00000 0x40000000 0xc0000000>;
};
};
. . .
memory@0 {
device_type =3D "memory";
reg =3D <0x00000000 0x00000000 0x3b400000 0x00000000 =
0x40000000 0xbc000000>;
};
. . .
};
U-Boot>=20
(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=20
ConventionalMemory 000000001000 1000 00007ef1 WB=20
BootServicesData 000007ef2000 7ef2000 0000001c WB=20
ConventionalMemory 000007f0e000 7f0e000 00029f93 WB=20
BootServicesData 000031ea1000 31ea1000 00000001 WB=20
LoaderData 000031ea2000 31ea2000 00008001 WB=20
LoaderCode 000039ea3000 39ea3000 000000a6 WB=20
Reserved 000039f49000 39f49000 00000007 WB=20
BootServicesData 000039f50000 39f50000 00000001 WB=20
Reserved 000039f51000 39f51000 00000002 WB=20
RuntimeServicesData 000039f53000 39f53000 00000001 WB RUNTIME
Reserved 000039f54000 39f54000 00000001 WB=20
BootServicesData 000039f55000 39f55000 00000002 WB=20
RuntimeServicesData 000039f57000 39f57000 00000001 WB RUNTIME
LoaderData 000039f58000 39f58000 00001408 WB=20
RuntimeServicesCode 00003b360000 3b360000 00000010 WB RUNTIME
LoaderData 00003b370000 3b370000 00000090 WB=20
BootServicesData 000040000000 40000000 000bc000 WB=20
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=20
0x32000000 - 0x33773fff, 23 MB ( 6004 pages) NoAlloc=20
0x39f49000 - 0x39f4ffff, 0 MB ( 7 pages) NoAlloc=20
0x39f51000 - 0x39f54fff, 0 MB ( 4 pages) NoAlloc=20
0x39f57000 - 0x39f57fff, 0 MB ( 1 pages) NoAlloc=20
0x3b360000 - 0x3b36ffff, 0 MB ( 16 pages) NoAlloc=20
0x3e513000 - 0x3ebebfff, 6 MB ( 1753 pages) NoAlloc=20
0xfe100000 - 0xfe100fff, 0 MB ( 1 pages) NoAlloc
If I gather right, memreserve =3D <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@3e513000 {
format =3D "a8r8g8b8";
stride =3D <0x00001c80>;
height =3D <0x000003d8>;
width =3D <0x00000720>;
reg =3D <0x00000000 0x3e513000 0x006d8c00>;
compatible =3D "simple-framebuffer";
status =3D "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@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.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19B0635A-6FD3-43BA-A3EE-60C168228109>