"The Image must be placed text_offset bytes from a 2MB aligned base
address anywhere in usable system RAM and called there."

For the virt board, we write our startup bootloader at the very
bottom of RAM, so that bit can't be used for the image. To avoid
overlap in case the image requests to be loaded at an offset
smaller than our bootloader, we increment the load offset to the
next 2MB.

This fixes a boot failure for Xen AArch64.

Signed-off-by: Stewart Hildebrand <stewart.hildebrand@dornerworks.com>
---
Changes v1 -> v2:
- use KiB/MiB macros for readability (suggested by Philippe Mathieu-Daudé), hence the additional #include
- define an upper bound for the bootloader size since TEXT_OFFSET has to be page aligned anyway (suggested by Andre Przywara)
- add assert() in write_bootloader() to make sure we stay below the 4K max (suggested by Peter Maydell)
---
 hw/arm/boot.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/hw/arm/boot.c b/hw/arm/boot.c
index 20c71d7d96..a675a602bc 100644
--- a/hw/arm/boot.c
+++ b/hw/arm/boot.c
@@ -24,6 +24,7 @@
 #include "qemu/config-file.h"
 #include "qemu/option.h"
 #include "exec/address-spaces.h"
+#include "qemu/units.h"
 
 /* Kernel boot protocol is specified in the kernel docs
  * Documentation/arm/Booting and Documentation/arm64/booting.txt
@@ -36,6 +37,8 @@
 #define ARM64_TEXT_OFFSET_OFFSET    8
 #define ARM64_MAGIC_OFFSET          56
 
+#define BOOTLOADER_MAX_SIZE         (4 * KiB)
+
 AddressSpace *arm_boot_address_space(ARMCPU *cpu,
                                      const struct arm_boot_info *info)
 {
@@ -184,6 +187,8 @@ static void write_bootloader(const char *name, hwaddr addr,
         code[i] = tswap32(insn);
     }
 
+    assert((len * sizeof(uint32_t)) < BOOTLOADER_MAX_SIZE);
+
     rom_add_blob_fixed_as(name, code, len * sizeof(uint32_t), addr, as);
 
     g_free(code);
@@ -919,6 +924,16 @@ static uint64_t load_aarch64_image(const char *filename, hwaddr mem_base,
         memcpy(&hdrvals, buffer + ARM64_TEXT_OFFSET_OFFSET, sizeof(hdrvals));
         if (hdrvals[1] != 0) {
             kernel_load_offset = le64_to_cpu(hdrvals[0]);
+
+            /* For the virt board, we write our startup "bootloader" at the very
+             * bottom of RAM, so that bit can't be used for the image. To avoid
+             * overlap in case the image requests to be loaded at an offset
+             * smaller than our bootloader, we increment the load offset to the
+             * next 2MB.
+             */
+            if (kernel_load_offset < BOOTLOADER_MAX_SIZE) {
+                kernel_load_offset += 2 * MiB;
+            }
         }
     }
 
-- 
2.17.1

On Tue, 16 Oct 2018 15:06:29 +0000
Stewart Hildebrand <Stewart.Hildebrand@dornerworks.com> wrote:

Hi, 

> "The Image must be placed text_offset bytes from a 2MB aligned base
> address anywhere in usable system RAM and called there."
> 
> For the virt board, we write our startup bootloader at the very
> bottom of RAM, so that bit can't be used for the image. To avoid
> overlap in case the image requests to be loaded at an offset
> smaller than our bootloader, we increment the load offset to the
> next 2MB.
> 
> This fixes a boot failure for Xen AArch64.

Thanks for that, works for me.

> Signed-off-by: Stewart Hildebrand <stewart.hildebrand@dornerworks.com>

Tested-by: Andre Przywara <andre.przywara@arm.com>

Cheers,
Andre.

On 16 October 2018 at 16:06, Stewart Hildebrand
<Stewart.Hildebrand@dornerworks.com> wrote:
> "The Image must be placed text_offset bytes from a 2MB aligned base
> address anywhere in usable system RAM and called there."
>
> For the virt board, we write our startup bootloader at the very
> bottom of RAM, so that bit can't be used for the image. To avoid
> overlap in case the image requests to be loaded at an offset
> smaller than our bootloader, we increment the load offset to the
> next 2MB.
>
> This fixes a boot failure for Xen AArch64.
>
> Signed-off-by: Stewart Hildebrand <stewart.hildebrand@dornerworks.com>
> ---


Applied to target-arm.next, thanks. I rephrased the comment a bit,
since this isn't a virt-board specific issue.

-- PMM