rom: requested regions overlap error

[marcelobarrosalmeida]

Hello

I have tried to use the machine stm32-f103c8 without success. I am stucked in the following error:

$ <path_to>/qemu_stm32/arm-softmmu/qemu-system-arm -machine stm32-p103 \
-semihosting -monitor stdio  -kernel demo_vector.elf

(process:3764): GLib-WARNING **: 08:55:51.177: ../../../../glib/gmem.c:489: custom memory allocation vtable not supported
QEMU 2.1.3 monitor - type 'help' for more information
(qemu) VNC server running on `127.0.0.1:5900'
rom: requested regions overlap (rom phdr #2: demo_vector.elf. free=0x0000000008000304, addr=0x0000000008000280)
rom loading failed

I am using an standard linker file already used in non-simulated projects:

ENTRY(Reset_Handler)

/* Highest address of the user mode stack */
_estack = 0x20005000;    /* end of RAM */
/* Generate a link error if heap and stack don't fit into RAM */
_Min_Heap_Size = 0x200;      /* required amount of heap  */
_Min_Stack_Size = 0x400; /* required amount of stack */

/* Specify the memory areas */
MEMORY
{
  RAM   (xrw)  : ORIGIN = 0x20000000, LENGTH = 20K
  FLASH (rx)   : ORIGIN = 0x08000000, LENGTH = 64K
}
/* ... */

Looking in the file stm32_f103c8.c I saw that 132kb is used instead of 64kb and I tried to use a linker file with 132kb of flash as well but the error remains. Similar targets generates the same problem (stm32-maple, stm32-p103).

The startup.s file came from a real project as well (provided by ST) and I compiled qemu from sources ( 2.1.3), branch stm32 (https://github.com/beckus/qemu_stm32).

Could anyone point me some directions ?

Thanks in advance.

[marcelobarrosalmeida]

I found the demo repository (https://github.com/beckus/stm32_p103_demos) ... looking for differences...

[marcelobarrosalmeida]

The problem is related to the following part of the ST linker file:

  .data : 
  {
    . = ALIGN(4);
    _sdata = .;        /* create a global symbol at data start */
    *(.data)           /* .data sections */
    *(.data*)          /* .data* sections */

    . = ALIGN(4);
    _edata = .;        /* define a global symbol at data end */
  } >RAM AT> FLASH

Just replace it by the following snippet (as used in demo repo):

    .data : AT (_sidata) 
    {
        _sdata = .;
        *(.data)        /* Initialized data */
        _edata = .;
    } >RAM

I replaced my memory regions as well, using now:

MEMORY
{
  FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 128K
  RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 20K
}

[beckus]

Hello, Thank you for giving an update on the solution. Are you still having any issues?

[marcelobarrosalmeida]

No, Now I can compile and run. Thanks !

[bjfiedler]

Hi, I'm having the same problem if I try to use the same ELF for my real hardware and QEMU. Changing the location of the flash in the linkerscript allows me to use my image with QEMU but not with the real board anymore.

The issue with the overlapping segments error seems to be fixed upstream at f33e5e6299288c as mentioned in this ticket https://bugs.launchpad.net/qemu/+bug/1429841/.

This yields to the problem of a crashing QEMU in arm_cpu_reset() as the rom could not be found at address 0x0.

I think the cause of the problem is located in aliasing 0x0 to 0x8000000 if I understand the code comments correctly. At arm_reset_cpu() where the rom is searched for, this aliasing seems to be ignored.

In upstream QEMU this seems to be fixed using the values from the vector table https://github.com/qemu/qemu/blob/55afdac3b29e672aad51e953412364127e54268b/target/arm/cpu.c#L302

I was not able to merge this changes from upstream qemu into this repo but maybe this links are helpfull for someone who has deeper insights in the project.

I have attached two patches which allow to run elf files with the flash located at 0x08000000 but this are just dirty hotfixes for demonstration purpose.

I hope this might help. Thanks in advance. Björn

0001-hofix-for-elf-segments-with-zero-size-issuing-overla.txt 0002-fix-elf-with-flash-at-0x08000000-instead-0x0.txt

[mhomran]

The problem is a bug in QEMU. What happened is that there's an empty section which's called ".igot.plt" that has the load address of the upcoming section ".bss". That's okay and shouldn't introduce any errors. Solution: move this empty section to bss section in the linker script.

The new .bss section

/* Uninitialized data section into "RAM" Ram type memory */
  . = ALIGN(4);
  .bss :
  {
    /* This is used by the startup in order to initialize the .bss section */
    _sbss = .;         /* define a global symbol at bss start */
    __bss_start__ = _sbss;
    *(.igot.plt)       /* The added section */
    *(.bss)
    *(.bss*)
    *(COMMON)

    . = ALIGN(4);
    _ebss = .;         /* define a global symbol at bss end */
    __bss_end__ = _ebss;
  } >RAM