On 4/2/25 14:52, Peter Maydell wrote:
On Tue, 4 Feb 2025 at 13:40, Philippe Mathieu-Daudé <philmd@xxxxxxxxxx> wrote:
On 4/2/25 12:13, Peter Maydell wrote:
On Tue, 4 Feb 2025 at 09:57, Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote:
IMHO we can have distinct machines for each model, but
*NOT* have further machines for each RAM size within a
model.
Yes, this was what I was intending to suggest. Apologies
if I was confusing with what I said the previous time round.
OK, let's see if we understand each other correctly as developer,
before explaining to users, taking the 4B model as example.
The 4B come in 4 physical variants, depending on the amount of
DRAM: 1G, 2G, 4G and 8G.
We can not allocate 2G on 32-bit hosts, so to have a reproducible
guest behavior on 32/64-bit hosts, it makes sense to takes the
model with 1G of DRAM as default for the 'raspi4b' machine.
At the moment we create the 1GB version on 32-bit hosts and
the 2GB version on 64-bit hosts. I dunno that that's ideal,
but I think it's probably best not to change that at this point.
Well this is annoying in my "unify qemu-system-{arm/aarch64}" effort,
but not a blocker.
If an user specify -m 2G ... 8G, we can adapt the 'board_rev'
register to expose the corresponding amount of ram. Now, how /
where to tell the users 1/ the default is 1G, and 2/ they can use
2/4/8G?
In the documentation: docs/system/arm/raspi.rst .
OK.
Back to this series, please tell me if patches 1-7 aren't useful or
if you prefer them in a separate series:
hw/arm/raspi: Access SoC parent object using BCM283X_BASE() macro
hw/arm/raspi: Merge model 4B with other models
hw/arm/raspi: Unify RASPI_MACHINE types
hw/arm/raspi: Pass board_rev as argument to raspi_base_machine_init()
hw/arm/raspi: Consider processor id in types[] array
hw/arm/raspi: Consider network interface for B models
hw/arm/raspi: Check ramsize is within chipset aperture
Thanks,
Phil.
