QEMU build too big

[peterfeifanchen]

It seems the rootfs is too small for the data I want to test with inside of the QEMU build. Is there a way to give the rootfs more space? I am guessing there is a parameter I need to change...that controls the max size of the QEMU 32-bit build for the rootfs?

The error I get is (which disappears and start working again once I remove couple of 10MB files from the rootfs build):

qemu-system-arm: Could not load ROM image

[jbech-linaro]

What limit have you hit? I.e., how big root fs are you generating? From what I understand there no upper limit for the initramfs than the memory (RAM) itself. For QEMU we set this to 1057 (wonder why we have that strange number?), see here. You could try increase that.

[peterfeifanchen]

I tried 2048 and it still gave me the same error. I don't get anything else other than that error which occurs at the last step of the build when it is launching qemu.

If by size of rootfs you mean the size of filesystem.cpio.gz (95MB), rootfs-vexpress.cpio (15MB) or bios.bin (105MB). Once I remove 38MB of text files that I was loading in there, it starts working again. The limit seem to be 64MB somewhere.

[igoropaniuk]

Hi @peterfeifanchen,

You face this issue because of restrictions of max vexpress flash size. In QEMU it's defined as 64 mbytes (see qemu/hw/arm/vexpress.c:46) #define VEXPRESS_FLASH_SIZE (64 * 1024 * 1024)

So, when loading bios.bin in vexpress.c:581:

 ...
   image_size = load_image_targphys(fn, map[VE_NORFLASH0],
                                         VEXPRESS_FLASH_SIZE);
   g_free(fn);
   if (image_size < 0) {
       error_report("Could not load ROM image '%s'", bios_name);
       exit(1);
   }
...

there is a size check in load_image_targphys:

int load_image_targphys_as(const char *filename,
                           hwaddr addr, uint64_t max_sz, AddressSpace *as)
{
    int size;
    size = get_image_size(filename);
    if (size > max_sz) {
        return -1;
    }
    if (size > 0) {
        rom_add_file_fixed_as(filename, addr, -1, as);
    }
    return size;
}

[igoropaniuk]

As possible solution you can try to add additional storage(sd/mmc, where you can create some parititon and mount it somewhere within root dir) o vm, by passing additioanl params to qemu-system-arm, something like that:

-drive if=none,id=sd1,file=etc.img,format=raw
-device sd-card,drive=sd1,bus=sd-bus

I'm not sure if it will work, but at least it's worth to try

[jenswi-linaro]

Another option is to use a shared directory from the host with something like this: additional params to QEMU: -fsdev local,id=fsdev0,path=path_to_shared_dir,security_model=none -device virtio-9p-device,fsdev=fsdev0,mount_tag=shared Once Linux has booted in QEMU mount the directory with: mount -t 9p -o trans=virtio,version=9p2000.L shared /mnt

[igoropaniuk]

I was a bit wrong, my previous explanation was actual only for ARM Versatile Express emulation, but in our QEMU op-tee config ARM mach-virt emulation is used by default. Loading fails in load_image_mr:169:

if (size > memory_region_size(mr)) {;
        return -1;
    }

because of maximum size(64MB) of memory region, where this bios is going to be stored.

For cortext-a15 in memmap table 128 MB is dedicated for flash:

/* Addresses and sizes of our components.
 * 0..128MB is space for a flash device so we can run bootrom code such as UEFI.
...
static const MemMapEntry a15memmap[] = {
    /* Space up to 0x8000000 is reserved for a boot ROM */
    [VIRT_FLASH] =              {          0, 0x08000000 },
    ...

And in this VIRT_FLASH space two flash devices are created: first - normal, second - secured flash. see code

static void create_flash(const VirtBoardInfo *vbi,
                         MemoryRegion *sysmem,
                         MemoryRegion *secure_sysmem)
{
    /* Create two flash devices to fill the VIRT_FLASH space in the memmap.
     * Any file passed via -bios goes in the first of these.
     * sysmem is the system memory space. secure_sysmem is the secure view
     * of the system, and the first flash device should be made visible only
     * there. The second flash device is visible to both secure and nonsecure.
     * If sysmem == secure_sysmem this means there is no separate Secure
     * address space and both flash devices are generally visible.
     */
    hwaddr flashsize = vbi->memmap[VIRT_FLASH].size / 2;
    hwaddr flashbase = vbi->memmap[VIRT_FLASH].base;
    char *nodename;

    create_one_flash("virt.flash0", flashbase, flashsize,
                     bios_name, secure_sysmem);
    create_one_flash("virt.flash1", flashbase + flashsize, flashsize,
                     NULL, sysmem);

So that's why we have only 64mb :)

[igoropaniuk]

Hi @peterfeifanchen, Now you can mount host folders inside QEMU VM with this patch, so you can easily avoid "overloading" of CPIO archive with additional huge files you need. Hope it helps!

[ghost]

We're closing this issue since the question has been answered. If you however feel that you have additional questions or still thinks this is an issue, please feel free to re-open the issue again.