vexpress: Add support for the -bios flag to provide firmware

Right now to run firmware inside the QEMU VExpress model requires
padding out the firmware image to the size of the virtual flash and
passing it in via the -pflash argument. If the firmware image is passed
without padding, then QEMU will fail. Also, when passed as a -pflash
argument, QEMU treats the file as persistent storage and will modify the
file.

The -bios flag provides the semantics that we want for providing a
firmware image. This patch maps the contents of the -bios file into the
address space at the boot flash location.

Tested with the vexpress-a15 model and the Tianocore port.

Signed-off-by: Grant Likely <grant.likely@linaro.org>
Tested-by: Roy Franz <roy.franz@linaro.org>
Cc: Peter Maydell <peter.maydell@linaro.org>
---
 hw/arm/vexpress.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

On 28 March 2014 17:57, Grant Likely <grant.likely@linaro.org> wrote:
> Right now to run firmware inside the QEMU VExpress model requires
> padding out the firmware image to the size of the virtual flash and
> passing it in via the -pflash argument. If the firmware image is passed
> without padding, then QEMU will fail. Also, when passed as a -pflash
> argument, QEMU treats the file as persistent storage and will modify the
> file.
>
> The -bios flag provides the semantics that we want for providing a
> firmware image. This patch maps the contents of the -bios file into the
> address space at the boot flash location.
>
> Tested with the vexpress-a15 model and the Tianocore port.
>
> Signed-off-by: Grant Likely <grant.likely@linaro.org>
> Tested-by: Roy Franz <roy.franz@linaro.org>
> Cc: Peter Maydell <peter.maydell@linaro.org>
> ---
>  hw/arm/vexpress.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/hw/arm/vexpress.c b/hw/arm/vexpress.c
> index 67628af58840..80c549caa662 100644
> --- a/hw/arm/vexpress.c
> +++ b/hw/arm/vexpress.c
> @@ -28,6 +28,7 @@
>  #include "net/net.h"
>  #include "sysemu/sysemu.h"
>  #include "hw/boards.h"
> +#include "hw/loader.h"
>  #include "exec/address-spaces.h"
>  #include "sysemu/blockdev.h"
>  #include "hw/block/flash.h"
> @@ -528,6 +529,17 @@ static void vexpress_common_init(VEDBoardInfo *daughterboard,
>
>      daughterboard->init(daughterboard, args->ram_size, args->cpu_model, pic);
>
> +    /*
> +     * If a bios file was provided, attempt to map it into memory
> +     */
> +    if (bios_name) {
> +        const char *fn = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
> +        if (!fn || load_image_targphys(fn, map[VE_NORFLASH0], VEXPRESS_FLASH_SIZE) < 0) {
> +            error_report("Could not load rom image '%s'.\n", fn);
> +            exit(0);

 exit(1), surely?

> +        }
> +    }
> +
>      /* Motherboard peripherals: the wiring is the same but the
>       * addresses vary between the legacy and A-Series memory maps.
>       */
> --
> 1.8.3.2
>

Otherwise I think this is OK. We should probably add a flash
image to the virt board too at some point.

thanks
-- PMM

On 28 March 2014 17:57, Grant Likely <grant.likely@linaro.org> wrote:
> Right now to run firmware inside the QEMU VExpress model requires
> padding out the firmware image to the size of the virtual flash and
> passing it in via the -pflash argument. If the firmware image is passed
> without padding, then QEMU will fail.

Alex suggested on IRC that if your firmware build process
is producing incorrectly sized output binaries this is a
bug in your firmware's build process. I have some sympathy
with this line of argument -- why is Tianocore producing
undersized images?

thanks
-- PMM

On Tue, 15 Apr 2014 16:50:06 +0100, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 28 March 2014 17:57, Grant Likely <grant.likely@linaro.org> wrote:
> > Right now to run firmware inside the QEMU VExpress model requires
> > padding out the firmware image to the size of the virtual flash and
> > passing it in via the -pflash argument. If the firmware image is passed
> > without padding, then QEMU will fail.
> 
> Alex suggested on IRC that if your firmware build process
> is producing incorrectly sized output binaries this is a
> bug in your firmware's build process. I have some sympathy
> with this line of argument -- why is Tianocore producing
> undersized images?

It's not a flash image. It's a firmware executable binary. Padding it
out to the size of the flash precludes using the rest of the flash for
other data. Both U-Boot and UEFI build processes work this way, and have
done for a long time. I don't think it is unreasonable for QEMU to work
with files that are only the size of the executable.

g.

On Tue, 15 Apr 2014 16:46:50 +0100, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 28 March 2014 17:57, Grant Likely <grant.likely@linaro.org> wrote:
> > Right now to run firmware inside the QEMU VExpress model requires
> > padding out the firmware image to the size of the virtual flash and
> > passing it in via the -pflash argument. If the firmware image is passed
> > without padding, then QEMU will fail. Also, when passed as a -pflash
> > argument, QEMU treats the file as persistent storage and will modify the
> > file.
> >
> > The -bios flag provides the semantics that we want for providing a
> > firmware image. This patch maps the contents of the -bios file into the
> > address space at the boot flash location.
> >
> > Tested with the vexpress-a15 model and the Tianocore port.
> >
> > Signed-off-by: Grant Likely <grant.likely@linaro.org>
> > Tested-by: Roy Franz <roy.franz@linaro.org>
> > Cc: Peter Maydell <peter.maydell@linaro.org>
> > ---
> >  hw/arm/vexpress.c | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/hw/arm/vexpress.c b/hw/arm/vexpress.c
> > index 67628af58840..80c549caa662 100644
> > --- a/hw/arm/vexpress.c
> > +++ b/hw/arm/vexpress.c
> > @@ -28,6 +28,7 @@
> >  #include "net/net.h"
> >  #include "sysemu/sysemu.h"
> >  #include "hw/boards.h"
> > +#include "hw/loader.h"
> >  #include "exec/address-spaces.h"
> >  #include "sysemu/blockdev.h"
> >  #include "hw/block/flash.h"
> > @@ -528,6 +529,17 @@ static void vexpress_common_init(VEDBoardInfo *daughterboard,
> >
> >      daughterboard->init(daughterboard, args->ram_size, args->cpu_model, pic);
> >
> > +    /*
> > +     * If a bios file was provided, attempt to map it into memory
> > +     */
> > +    if (bios_name) {
> > +        const char *fn = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
> > +        if (!fn || load_image_targphys(fn, map[VE_NORFLASH0], VEXPRESS_FLASH_SIZE) < 0) {
> > +            error_report("Could not load rom image '%s'.\n", fn);
> > +            exit(0);
> 
>  exit(1), surely?

Yes, of course. I'll fix in the next version.

> 
> > +        }
> > +    }
> > +
> >      /* Motherboard peripherals: the wiring is the same but the
> >       * addresses vary between the legacy and A-Series memory maps.
> >       */
> > --
> > 1.8.3.2
> >
> 
> Otherwise I think this is OK. We should probably add a flash
> image to the virt board too at some point.

yes. There is some work being scoped out to make UEFI configure itself
from a FDT which would work well with the virt platform.

g.