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

[Cédric Le Goater]

On 9/14/21 17:22, Richard Henderson wrote:
> On 9/14/21 5:26 AM, Peter Maydell wrote:
> > (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)
>
> Recalling that the win64 abi model is p64, i.e. 'long' is still 32-bit while 
> pointers are 64-bit, how close do we think we are to this being fixed already?

I removed the check from softmmu/vl.c and "all" tests on gitlab ran
fine. But, there is still a problem indeed. When running the Fuji
machine with a flash device to boot from  :

    $ gdb --args qemu-system-arm -M fuji-bmc -drive 
file=./flash-fuji,format=raw,if=mtd
    Thread 1 "qemu-system-arm" received signal SIGTRAP, Trace/breakpoint trap.
    _g_log_abort (breakpoint=1) at ../../../glib/gmessages.c:554
    554 ../../../glib/gmessages.c: No such file or directory.
    (gdb) bt
    #0  _g_log_abort (breakpoint=1) at ../../../glib/gmessages.c:554
    #1  0xb7ae351d in g_logv
        (log_domain=0xb7b2d00e "GLib", log_level=G_LOG_LEVEL_ERROR, format=0xb7b36730 "%s: 
failed to allocate %u bytes", args=0xbfffed8c "\260f\263\267") at 
../../../glib/gmessages.c:1373
    #2  0xb7ae36b9 in g_log (log_domain=0xb7b2d00e "GLib", log_level=G_LOG_LEVEL_ERROR, 
format=0xb7b36730 "%s: failed to allocate %u bytes")
        at ../../../glib/gmessages.c:1415
    #3  0xb7ae1e6a in g_malloc0 (n_bytes=134217728) at ../../../glib/gmem.c:137
    #4  0x006af2b7 in rom_add_blob
        (name=0xd65c67 "aspeed.boot_rom", blob=0xa3fa010, len=134217728, 
max_len=134217728, addr=0, fw_file_name=0x0, fw_callback=0x0, callback_opaque=0x0, 
as=0x0, read_only=true) at ../hw/core/loader.c:1068
    #5  0x0084b714 in write_boot_rom (addr=0, errp=<optimized out>, 
rom_size=134217728, dinfo=0x1766570) at ../hw/arm/aspeed.c:267
    #6  aspeed_machine_init (machine=0xb67c3010) at ../hw/arm/aspeed.c:397
    #7  0x0060e6d9 in machine_run_board_init (machine=<optimized out>) at 
../hw/core/machine.c:1276
    #8  0x0099be9b in qemu_init_board () at ../softmmu/vl.c:2618
    ...

The last allocation of the machine (which is the boot ramblock) fails.

However, when using the 'execute-in-place' option of the Aspeed machine
which fetches directly instructions to execute from the flash MMIO region,
the machine boots correctly. No extra allocation for the ramblock.

> > 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.
>
> I'm not opposed to deprecating 32-bit hosts...  ;-)

Until then, I am willing to make the following compromise for the fuji  :

    mc->default_ram_size = (HOST_LONG_BITS == 32 ? 1 : 2) * GiB;

Thanks,


C.