Re: [PULL 14/14] hw/arm/aspeed: Add Fuji machine type

[Peter Maydell]

On Tue, 14 Sept 2021 at 13:14, Joel Stanley <joel@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