On Tue, 14 Sept 2021 at 13:14, Joel Stanley <j...@jms.id.au> wrote:
> The upstream device tree uses 2G:
>
> https://elixir.bootlin.com/linux/v5.15-rc1/source/arch/arm/boot/dts/ast2600-facebook-netbmc-common.dtsi#L20
>
> It's unfortunate we limit the defaults given very few (no one?) is
> using this model on a machine that is 32 bit.
This runs into a set of desires which are all reasonable
but unfortunately sometimes in conflict:
(1) boards should behave the same on all hosts (whether those
hosts are 64 bit or 32 bit)
(2) RAM blocks should have a length that fits inside a
signed 32-bit type on 32-bit hosts (at least I assume this
is where the 2047MB limit is coming from; in theory this ought
to be improveable but auditing the code for mishandling of
RAMblock sizes to ensure we weren't accidentally stuffing
their size into a signed 'long' somewhere would be kind
of painful)
(3) default behaviour of a board should match the real
hardware
(4) every board should start cleanly with no non-default
arguments, so we can have a machine-model agnostic test
of "does every machine we support at least init cleanly"
So far when we have run into this problem with other machine
types, the one that we have ended up discarding is (3).
There's a good argument to be made that what we should deal
with is (2) -- this probably involves making ram_addr_t
be 64-bits always, rather than "64 bits unless we're on
a 32-bit host and Xen is not compiled in", and a certain
amount of testing or audit that we don't have any places
where we stuff ram sizes into 'long' variables. But it's a lot
more work than compromising on (3) :-)
Even if we did fix (2) we'd need to compromise on (3)
sometimes still -- if a board has 4GB of RAM that's
not going to fit in 32 bits regardless. But we would be
able to let boards with 2GB have 2GB.
thanks
-- PMM
