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