Report: FreeBSD on Rpi4 8 GB model

[Mark Millard]

On 2020-Jun-6, at 13:01, Robert Crowston via freebsd-arm <freebsd-arm at freebsd.org> wrote:

> To reinstate some additional confusion, I only changed the SPIN_PAGE variable to 2 (didn't touch NR_DRAM_BANKS) and I see all 8 GB (well, 7.84 GB) in htop.

sysutils/u-boot-rpi4 already has SPIN_PAGE set to 2. So you were likely
not using the same vintage of materials as sysutils/u-boot-rpi4
produces to compile. Your context may already have had NR_DRAM_BANKS
changed.

I expect Kyle was talking about changes to make to sysutils/u-boot-rpi4 .
For that context, apparently NR_DRAM_BANKS does need to be changed in
order for 8 GiByte to be found and used: sysutils/u-boot-rpi4 does not
start with the updated material (yet).

Such is my guess anyway, I do not have a test context.

> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Saturday, 6 June 2020 20:55, Kyle Evans <kevans at freebsd.org> wrote:
> 
>> On Sat, Jun 6, 2020 at 2:45 PM Robert Crowston crowston at protonmail.com wrote:
>> 
>>>> No, SPIN_PAGES=2 is fine
>>> 
>>> I confirm that CONFIG_RPI_EFI_NR_SPIN_PAGES 2 is sufficient.
>> 
>> Thanks for confirming. :-)
>> 
>>>> Even without this setting, it should still largely boot;
>>>> you'll just only have half the memory you wanted.
>>> 
>>> Without raising the spin pages limit, the kernel panics while trying to start the secondary CPUs. I don't have a working JTAG so I can't diagnose exactly why, but the spin table thing seemed like an obvious thing to check.
>> 
>> Sorry, that was specifically referring to raising CONFIG_NR_DRAM_BANKS
>> -- an unmodified sysutils/u-boot-rpi4 (which uses
>> CONFIG_RPI_EFI_NR_SPIN_PAGES=2) should boot with half the RAM
>> recognized, and bumping CONFIG_NR_DRAM_BANKS in our fragment should
>> correct that.
> 



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