On 4/2/25 14:52, Peter Maydell wrote:
On Tue, 4 Feb 2025 at 13:40, Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
On 4/2/25 12:13, Peter Maydell wrote:
On Tue, 4 Feb 2025 at 09:57, Daniel P. Berrangé <berrange@redhat.com> 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.