[zephyr] [Qemu simulation] Erro rom: requested regions overlap (rom phdr #0:

957 views
Skip to first unread message

Sathya Narayanan N

unread,
Sep 10, 2018, 6:09:39 AM9/10/18
to RISC-V SW Dev
Dear Experts,

I get the below error while trying to simulate zephyr os on my pc. 

What should I do to get it working ?


Error prints:

qemu-system-riscv32 --version
QEMU emulator version 2.12.92 (v3.0.0-rc2-43-g79fe4f4-dirty)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

~/zephyr/samples/hello_world/build$ /usr/local/bin/qemu-system-riscv32 -m 32 -nographic -machine sifive_e -pidfile qemu.pid -serial mon:stdio -kernel /home/risecreek/zephyr/samples/synchronization/build/zephyr/zephyr.elf
rom: requested regions overlap (rom phdr #0: /home/risecreek/zephyr/samples/synchronization/build/zephyr/zephyr.elf. free=0x0000000000001008, addr=0x0000000000001000)


Steps to reproduce the problem:

git clone https://github.com/zephyrproject-rtos/zephyr.git

unset GNUARMEMB_TOOLCHAIN_PATH
export ZEPHYR_BASE="~/zephyr"
export ZEPHYR_TOOLCHAIN_VARIANT=cross-compile
export CROSS_COMPILE="/home/risecreek/tools/riscv/bin/riscv32-unknown-elf-"

cd zephyr
source zephyr-env.sh
cd ./samples/synchronization

mkdir build && cd build

cmake -GNinja -DBOARD=qemu_riscv32 ..



--
 regards,
Sathya  

 

Michael Clark

unread,
Sep 10, 2018, 8:22:33 AM9/10/18
to Sathya Narayanan N, RISC-V SW Dev


On 10/09/2018, at 10:09 PM, Sathya Narayanan N <sath...@gmail.com> wrote:

Dear Experts,

I get the below error while trying to simulate zephyr os on my pc. 

What should I do to get it working ?

It appears that the zephyr ELF link address overlaps the QEMU ‘sifive_e’ machine’s internal ROM. See the sifive_e_memmap array here:


The riscv-qemu repo version may have stricter checking for ROM overlaps compared to QEMU 2.12 which may just overwrite the existing emulated Mask ROM with the ELF file. The riscv-qemu repo is based on QEMU 3.0.0-rc2 as we can see in your log. You likely need to modify the zephyr linker script start address to use the current official program entry point for the machine, which is 0x2040_0000, the same address as the HiFive1. This should make your binary compatible with real hardware (unless of course you are targeting the Mask ROM).

If you look at freedom-e-sdk you’ll find linker scripts that map to SiFive E Series hardware, in this case the ‘sifive_e’ machine is modelled on the HiFive1:


The other alternative is that we could patch QEMU to allow passing the ELF file using the -bios parameter, and have that replace the emulated Mask ROM. I can consider making a patch to riscv-qemu. We’ll have to consider the consequences as -bios is currently used on the ‘virt’ machine (in conjunction with -kernel), but it doesn’t overwrite the emulated Mask ROM. The small Mask ROM needs to be present on U series devices because it loads a pointer to the dynamically generated device-tree.

You could perhaps log an issue here if you are targeting Mask ROM:


Otherwise you just need to update the Zephyr linker script.

Error prints:

qemu-system-riscv32 --version
QEMU emulator version 2.12.92 (v3.0.0-rc2-43-g79fe4f4-dirty)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

~/zephyr/samples/hello_world/build$ /usr/local/bin/qemu-system-riscv32 -m 32 -nographic -machine sifive_e -pidfile qemu.pid -serial mon:stdio -kernel /home/risecreek/zephyr/samples/synchronization/build/zephyr/zephyr.elf
rom: requested regions overlap (rom phdr #0: /home/risecreek/zephyr/samples/synchronization/build/zephyr/zephyr.elf. free=0x0000000000001008, addr=0x0000000000001000)


Steps to reproduce the problem:

git clone https://github.com/zephyrproject-rtos/zephyr.git

unset GNUARMEMB_TOOLCHAIN_PATH
export ZEPHYR_BASE="~/zephyr"
export ZEPHYR_TOOLCHAIN_VARIANT=cross-compile
export CROSS_COMPILE="/home/risecreek/tools/riscv/bin/riscv32-unknown-elf-"

cd zephyr
source zephyr-env.sh
cd ./samples/synchronization

mkdir build && cd build

cmake -GNinja -DBOARD=qemu_riscv32 ..



--
 regards,
Sathya  

 

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAD0cppFXqaTD%2BRiYXW6Aa2bGzpea44px1a7EMJcE_UhP93MCJQ%40mail.gmail.com.

Jean-Paul Etienne

unread,
Sep 11, 2018, 10:36:46 AM9/11/18
to RISC-V SW Dev
Hi Sathya,
The qemu_riscv32 board in Zephyr bases itself on an old version of qemu for riscv (version 2.7.50), which is available in the zephyr toolchain.
Check link below.

The riscv qemu version (2.12.92) you are using comprises sifive machine models, which are incompatible with the qemu_riscv32 board that is currently defined in Zephyr.
However, If I'm not mistaken one of the sifive machine models in this version of qemu emulates the hifive1 board. (Michael Clark can confirm this)
In this case, compile zephyr for the hifive1 board instead and give it a try (using the correct machine model)

Regards,
Jean-Paul

Michael Clark

unread,
Sep 11, 2018, 5:01:00 PM9/11/18
to Jean-Paul Etienne, RISC-V SW Dev


On 12/09/2018, at 2:36 AM, Jean-Paul Etienne <fracta...@gmail.com> wrote:

Hi Sathya,
The qemu_riscv32 board in Zephyr bases itself on an old version of qemu for riscv (version 2.7.50), which is available in the zephyr toolchain.
Check link below.

The riscv qemu version (2.12.92) you are using comprises sifive machine models, which are incompatible with the qemu_riscv32 board that is currently defined in Zephyr.
However, If I'm not mistaken one of the sifive machine models in this version of qemu emulates the hifive1 board. (Michael Clark can confirm this)
In this case, compile zephyr for the hifive1 board instead and give it a try (using the correct machine model)

That was certainly correct for one branch of Zephyr. I was able to run the HiFive1 target in the SiFive E series target ‘sifive_e’. Unfortunately, this was a case where we deliberately broke backwards compatibility because the ‘sifive’ machine didn’t match any hardware or simulators. There might be updates since then. We used the HiFive1 linker script load address of 0x2040_0000. We have other problems than just loading the target binaries as we may also want the user to be able to specify their own Mask ROM. In QEMU we have -bios and -kernel arguments so we could potentially use -bios to load Mask ROM. It’s not ideal as there is also a flash protect area. QEMU has the ability to attach flash devices so we can grow the support while trying our best to maintain backwards compatibility.

Now one of the problems we have is emulation of different hardware with different address maps and interrupt routing configurations as there are many different possible core configurations with ROM, flash, scratchpad and DRAM, from SiFive’s core generator. It’s a problem shared between spike and QEMU so ideally we can address it in a uniform way. Both of the emulators currently generate device tree, so using device tree as an input configuration mode would be quite a big change to how they work. We would have to validate the device tree and refuse to run if it contained devices we couldn’t emulate (as passing these to the OS would cause crashes), so we can perform relatively accurate simulation, and the parameter bounds for devices are often originated inside the emulator based on its internal constraints.

We are having ongoing discussions about this “protocol” or “format” issue (as the technical problem is not that hard to solve). We need something that maps to QOM (QEMU Object Model) and we need to break the model used by many of the arm machines in QEMU which use static configuration based on SOC structs. Indeed, internally QEMU supports dynamic configuration. I think it should be relatively easy to solve if we get both spike and QEMU on the same page. The most important piece is the schema for the configuration model. We should choose a format that is easy to use, noting here that SiFive E Series (Freedom Everywhere) do not have device tree, and SiFive U Series (Freedom Unleashed) do. I note here that x86 in QEMU has quite flexible device configuration but using command line arguments is not that friendly so a config file would be nice. This is a discussion to have on qemu-devel when we have a concrete proposal.

I’d prefer a modern and simple format using JSON or YAML that is easy to edit. YAML would look quite nice and it supports comments. Antmicro’s renode emulator has a very nice format to describe dynamic virtual hardware configurations however I’m not sure if there is a spec and whether it is open or not. It would be nice to have a format that is trivial to generate in Python to test different hardware configurations. libfdt based solutions add complexity to scripts because the Python bindings require a native library, which just makes build and installation of tooling harder.

I have a really simple format in mind that leverages simple parsers that are widespread. We’ll be able to generate device-tree from it pretty easily... That’s another discussion though.

I’m raising this because the compatibility issues come down to describing the memory map for ROMs, Flash, Scratchpad and DRAM. Note we also need to generate linker scripts. These just need a simple memmap.json (from core generator). We could replace several hundred lines of code with a dozen or so as JSON is a first class format in Python that maps to dict, list, etc (sorry talking about other related problems).

Regards,
Michael

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

Sathya Narayanan N

unread,
Sep 12, 2018, 2:06:41 AM9/12/18
to michae...@mac.com, fracta...@gmail.com, RISC-V SW Dev
Thanks Jean and Michael !

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/88D349D5-06AB-41A0-AEF3-5556995FB7AD%40mac.com.


--
 regards,
Sathya  

 

Sathya Narayanan N

unread,
Sep 13, 2018, 3:48:53 AM9/13/18
to RISC-V SW Dev, michae...@mac.com, fracta...@gmail.com
Hi Michael,

Do you want me to try with the below linker script:



regards,
sathya
Regards,
Jean-Paul
~/zephyr/samples/hello_world/build$ /usr/local/bin/qemu-system-riscv32 -m 32 -nographic -machine sifive_e -pidfile qemu.pid -serial *mon:stdio -kernel /home/risecreek/zephyr/samples/synchronization/build/zephyr/zephyr.elf
rom: requested regions overlap (rom phdr #0: /home/risecreek/zephyr/samples/synchronization/build/zephyr/zephyr.elf. free=0x0000000000001008, addr=0x0000000000001000)


Steps to reproduce the problem:


unset GNUARMEMB_TOOLCHAIN_PATH
export ZEPHYR_BASE="~/zephyr"
export ZEPHYR_TOOLCHAIN_VARIANT=cross-compile
export CROSS_COMPILE="/home/risecreek/tools/riscv/bin/riscv32-unknown-elf-"

cd zephyr
source zephyr-env.sh
cd ./samples/synchronization

mkdir build && cd build

cmake -GNinja -DBOARD=qemu_riscv32 ..



--
 regards,
Sathya  

 

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.


--
 regards,
Sathya  

 

Michael Clark

unread,
Sep 13, 2018, 4:10:35 AM9/13/18
to Sathya Narayanan N, RISC-V SW Dev, fracta...@gmail.com


On 13/09/2018, at 7:48 PM, Sathya Narayanan N <sath...@gmail.com> wrote:

Hi Michael,

Do you want me to try with the below linker script:


I’m not quite sure what is going on but from the log message it seems that one the ELF files overlaps the ROM.

I have tested all of the QEMU machines in the riscv-qemu/riscv-all branch.

Could you do the following?

Note which repo and branch of Zephyr, and how to reproduce your build, including pointer to the commit id or branch. Also include the repo and branch details for the QEMU you built. This is if you want me to try to reproduce the problem on my side. Consider logging an issue in the riscv-qemu bug tracker on GitHub.

However I might be able to tell what is going on if you use readelf on your binary e.g.

riscv64-unknown-elf-readelf -a zephyr.elf

If we can’t see where the overlap is coming from then we’ll need the details on how to reproduce your setup. e.g. steps to reproduce your build, which SDK you downloaded and from where. I am not that familiar with Zephyr.

Thanks,
Michael

Jean-Paul Etienne

unread,
Sep 14, 2018, 7:15:04 PM9/14/18
to RISC-V SW Dev, michae...@mac.com, fracta...@gmail.com
Hi Sathya,
I've compiled zephyr for hifive1 board and tried it on the same riscv-qemu version as you  2.12.92 (v3.0.0-rc2-43-g79fe4f4-dirty) and it works.
cmake -GNinja -DBOARD=hifive1 ..

Give it a try

Regards,
Jean-Paul
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.


--
 regards,
Sathya  

 

Sathya Narayanan N

unread,
Sep 15, 2018, 2:21:53 AM9/15/18
to Jean-Paul Etienne, RISC-V SW Dev, michae...@mac.com
Hi Jean,

Thanks. I tried the SDK qemu, I was able to simulate riscv_qemu32. I tried hifive1 on riscv qemu. I was able to generate image for board. But I was not able to simulate. 

Can you please guide to the path of linker script ?
I want to load at a particular address like 20000. 
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.


--
 regards,
Sathya  

 

Reply all
Reply to author
Forward
0 new messages