qemu complier flags changed, #include <> needs to be ""

[CarlFK]

I don't know what repo this code comes from, but here is the change:

(LX P=arty C=or1k) juser@cnt6:~/litex-buildenv/third_party/litex$ git diff
diff --git a/litex/soc/integration/cpu_interface.py b/litex/soc/integration/cpu_interface.py
index bc934cf3..dfea77e3 100644
--- a/litex/soc/integration/cpu_interface.py
+++ b/litex/soc/integration/cpu_interface.py
@@ -136,7 +136,7 @@ def _get_rw_functions_c(reg_name, reg_base, nwords, busword, read_only, with_acc
 def get_csr_header(regions, constants, with_access_functions=True, with_shadow_base=True, shadow_base=0x80000000):
     r = "#ifndef __GENERATED_CSR_H\n#define __GENERATED_CSR_H\n"
     if with_access_functions:
-        r += "#include <hw/common.h>\n"
+        r += '#include "hw/common.h"\n'
     for name, origin, busword, obj in regions:
         if not with_shadow_base:
             origin &= (~shadow_base)

[mithro]

We can't really change this here as it'll break other firmware...

[mithro]

I think we need to change the ./scripts/build-qemu.sh script to add an extra include path to CFLAGS?

[CarlFK]

that sounds promising. I was thinking copy the file to a dir qemu is expecting it but build flags sounds way better.

…

On Wed, Sep 5, 2018 at 6:28 PM Tim Ansell ***@***.***> wrote: I think we need to change the ./scripts/build-qemu.sh script to add an extra include path to CFLAGS? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#49 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABauY1uJYdDrmeHIZOrfH9AJiIdrSOeks5uYF40gaJpZM4Wb2VS> .

-- Carl K

[mithro]

Look forward to the pull request!

[stffrdhrn]

For short term this sounds fine.

I think in the long run when upstreaming the qemu patches we need to provide some defaults in qemu for generated/csr.h and generated/mem.h. Then, when building in latex environment, we can inject CFLAGS to override the qemu provided csr.h / mem.h files.

[ewenmcneill]

@stffrdhrn @mithro FWIW, I've been thinking that we probably need to do the same thing (with the same files) in the MicroPython port (ports/fupy) as well, so possibly we want to agree on a standard default layout for holding a cached version of generated files. I'm assuming they're at least board specific, and maybe soft CPU/variant specific as well?

In which case possibly we want a target/$(BOARDNAME)/generated directory for each board to hold generated defaults, plus a way of injecting an -I in "development mode" before that include directory is reached for the case of building in the litex-buildenv environment where the most recently generated ones for the desired target can be used. Plus maybe a default for the BOARDNAME for building in just the qemu tree (or perhaps a "make BOARDNAME" type set of options that sets BOARDNAME appropriately for those includes, and does a recursive make).

If y'all come up with something clean/flexible to do that for qemu I'm happy to replicate it in our MicroPython port as well (inside ports/fupy).

Ewen

[stffrdhrn]

@ewenmcneill one thought I have is for qemu to support device tree. This will allow the memory locations and device layout to be determined at boot/runtime instead of compiled into the binary. There is some discussion on this here: https://elinux.org/CELF_Project_Proposal/Add_Device_Tree_emulation_support_to_QEMU. This is now fully supported in qemu with the qemu_fdt_* apis, see examples in hw/microblaze/boot.c (microblaze_load_dtb())? Do you think MicroPython would want/use something like that?

Also, I remember @mithro mentioning that he was updating litex to generate devicetrees for the linux kernel during litex build. I am not sure how far that has gotten.

CELF Project Proposal/Add Device Tree emulation support to QEMU - eLinux.org

[stffrdhrn]

@ewenmcneill oh... it looks like its already being discussed here: https://github.com/timvideos/litex-buildenv/wiki/DeviceTree

If we agree I will go about converting the litex hardware in qemu to device tree.

GitHub

timvideos/litex-buildenv

An environment for building LiteX based FPGA designs. Makes it easy to get everything you need! - timvideos/litex-buildenv

[mithro]

There is code here -> https://github.com/mithro/litex-devicetree

I thought upstream QEMu rejected the idea of using DeviceTree for configuration?

GitHub

mithro/litex-devicetree

Tool for generating Linux compatible DeviceTree from a LiteX csr.csv definition. - mithro/litex-devicetree

[ewenmcneill]

@stffrdhrn If upstream Qemu will agree to DeviceTree for configuration (at least for this particular varient -- litex) then I think that's probably the ideal medium term goal. We talked about it (at PyConAU 2018) with the upstream MicroPython developers and there was some interest in using DeviceTree for the ports/fupy (litex) port of MicroPython too.

Given what @mithro says, it'd probably make sense to confirm that upstream Qemu will accept DeviceTree (or definitely includes it already) -- that discussion you linked to seemed somewhat inconclusive whether it'd be accepted. If they will I'm happy to encourage our MicroPython port in that direction too (and it might well go that way even if Qemu doesn't).

Ewen

[stffrdhrn]

@ewenmcneill , @mithro I have been asking about device tree in #qemu but it seems no one is online yet. But I was looking and thinking. It seems that the qemu support for device tree is mostly around reading device tree which is to be passed to the kernel. Qemu can inject / override things to pass on to the kernel. That would work fine for the kernel, but it doesn't work for software that doesn't understand device tree.

Maybe the idea is to add device tree support to the litex bios / micropython. Then make sure a valid device tree is sent through via qemu.

[ewenmcneill]

@stffrdhrn Yes, @mithro had already suggested MicroPython parse DeviceTree to find things (rather than the current method which is basically "compiling in" things learnt by essentially #include <generated/csr.h> -- the reason why I commented on this ticket. There seems to be general agreement that's a good direction for MicroPython to explore, but no one has implemented code so I don't think "runtime DeviceTree" is happening in MIcroPython soon...

It would also help if the litex BIOS also could parse DeviceTree at least to find the things it needs to initialise. But I'm aware (from IRC) the litex BIOS currently doesn't fit in the space available (32kB) on some platform/CPU combinations, so there's not much room for more things in there right now, which might delay "runtime DeviceTree" for the litex BIOS. (MicroPython is also fairly space constrained in general, but I think less so on code that is ROMable -- ie, doesn't have to fit in RAM -- as the litex platforms treat MicroPython as a post-BIOS application, which potentially gets the rest of the flash space).

For the qemu case, I think we still need some short term solution, that allows building the emulated devices at a "known" location. It might make sense to pass that "known location" in via DeviceTree (and perhaps extract it out at build time) as an intermediate step? With the medium term goal perhaps being just that qemu puts things where it likes, and then provides information on where they are via DeviceTree parsed at run time.

I'm thinking this "compile time" DeviceTree might also be the intermediate step for MicroPython, to at least stop copying around generated/... header files on every build.

Does that make sense?

Ewen

[ray-bot]

Hey, Your issue has been resolved 🎉, Thanks!

[mithro]

@CarlFK Can you confirm this is fixed now?

[ray-bot]

Hey, Your issue has been resolved 🎉, Thanks!