On Sat, 8 May 2021 at 09:16, Khem Raj <raj.k...@gmail.com> wrote:
> On Sat, May 8, 2021 at 1:30 AM Alejandro Hernandez Samaniego
> <alejan...@enedino.org> wrote:
> >
> > Add support for MACHINE=qemuriscv64.
> >
> > $ runqemu nographic
> >
> > BIOS:
> [tmp/deploy/images/qemuriscv64/baremetal-helloworld-image-qemuriscv64.elf]
> > MACHINE: [qemuriscv64]
> >
> > runqemu - INFO - Running
> tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/qemu-system-riscv64
> >
> > Hello OpenEmbedded on RISC-V 64!
> >
> > Signed-off-by: Alejandro Enedino Hernandez Samaniego <
> alejan...@enedino.org>
> > ---
> > .../baremetal-examples/baremetal-helloworld_git.bb | 12 ++++++++++--
> > 1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta-skeleton/recipes-baremetal/baremetal-examples/
> baremetal-helloworld_git.bb
> b/meta-skeleton/recipes-baremetal/baremetal-examples/
> baremetal-helloworld_git.bb
> > index ee945c1ff0..3b7b8193a7 100644
> > --- a/meta-skeleton/recipes-baremetal/baremetal-examples/
> baremetal-helloworld_git.bb
> > +++ b/meta-skeleton/recipes-baremetal/baremetal-examples/
> baremetal-helloworld_git.bb
> > @@ -4,7 +4,7 @@ DESCRIPTION = "These are introductory examples to
> showcase the use of QEMU to ru
> > LICENSE = "MIT"
> > LIC_FILES_CHKSUM = "file://LICENSE;md5=39346640a23c701e4f459e05f56f4449"
> >
> > -SRCREV = "99f4fa4a3b266b42b52af302610b0f4f429ba5e3"
> > +SRCREV = "0bf9ea216e6f76be50726a3a74e527b7bbb0ad93"
> > PV = "0.1+git${SRCPV}"
> >
> > SRC_URI = "git://
> github.com/aehs29/baremetal-helloqemu.git;protocol=https;branch=master"
> > @@ -28,12 +28,13 @@ inherit baremetal-image
> > # machine that QEMU uses on OE, e.g. -machine virt -cpu cortex-a57
> > # but the examples can also be run on other architectures/machines
> > # such as vexpress-a15 by overriding the setting on the machine.conf
> > -COMPATIBLE_MACHINE = "qemuarmv5|qemuarm|qemuarm64"
> > +COMPATIBLE_MACHINE = "qemuarmv5|qemuarm|qemuarm64|qemuriscv64"
> >
> > BAREMETAL_QEMUARCH ?= ""
> > BAREMETAL_QEMUARCH_qemuarmv5 = "versatile"
> > BAREMETAL_QEMUARCH_qemuarm = "arm"
> > BAREMETAL_QEMUARCH_qemuarm64 = "aarch64"
> > +BAREMETAL_QEMUARCH_qemuriscv64 = "riscv64"
> >
> > EXTRA_OEMAKE_append = " QEMUARCH=${BAREMETAL_QEMUARCH} V=1"
> >
> > @@ -49,3 +50,10 @@ FILES_${PN} += " \
> > ${base_libdir}/firmware/${BAREMETAL_BINNAME}.bin \
> > ${base_libdir}/firmware/${BAREMETAL_BINNAME}.elf \
> > "
> > +
> > +# RISC-V tunes set the BIOS, redefine since runqemu jumps there
> > +QB_DEFAULT_BIOS_qemuriscv64 = "${IMAGE_LINK_NAME}.elf"
> > +
> > +# Use the medium-any code model for the RISC-V 64 bit implementation,
> > +# since medlow can only access addresses below 0x80000000
> > +CFLAGS_append_qemuriscv64 = " -mcmodel=medany"
>
> I would have thought medlow would be appropriate for baremetal apps.
> Since this is a sample app
> we should try to use good defaults as it will serve as template.
> having no access below 0x80000000
> should not be such a hard limitation or is it so ?
>
Hey Khem,
I'd usually agree on using defaults but it seems that it might be, for
Riscv64 the RAM address
starts at 0x80000000 [1], which is what we're setting the _start global
symbol to, as far as I
understand using medany switches the usage of lui for auipc instructions
making data accesses
pc-relative, making it possible to load pointers above 0x800000000 where
the RAM is.
The medany code model seems to be widely used: Riscv-probe [2],
libgloss-htif [3], and
riscv64-in-qemu [4], Zephyr had some problems with their SDK and enforced
it as well for
CONFIG_64 [5], and the RISC-V Large Code Model Software Workaround from
SiFive states
the following [6]:
In Summary:
-mcmodel=medlow — Used for 32-bit architectures, this code model
requires that the program
and its statically defined symbols must lie between the absolute
addresses -2 GiB and +2 GiB,
which covers the full 32-bit address range. Code is generally linked
around address 0x00000000,
and instruction pairs lui and ld are used to generate addresses for
global symbols.
-mcmodel=medany — Used for 64-bit architectures, this code model also
generates a 32-bit signed
offset to refer to global symbols. Linked code can reside at any
address, and instruction pairs auipc
and ld are used to generate global symbol addresses in a +/- 2GiB
window from the code area.
There's currently an open issue on riscv-gcc to change the default code
model to medany for 64 bit targets [7].
My idea was to keep medlow for RISCV32 and use medany for RISCV64, but I'm
open to suggestions on
addressing the _start symbol for the RAM address while avoiding relocation
issues:
hello_baremetal_riscv64.c:(.text+0xe): relocation truncated to fit:
R_RISCV_HI20
[1] QEMU:
https://github.com/qemu/qemu/blob/d90f154867ec0ec22fd719164b88716e8fd48672/hw/riscv/virt.c#L60
[2]
https://github.com/michaeljclark/riscv-probe/blob/891ac1df30c3cc7f49c0ac175ecb6d390ec5db34/Makefile#L5
[3]
https://github.com/ucb-bar/libgloss-htif/blob/290b605e4a7340b584602eda183edab07f4bad45/util/htif.specs#L11
[4]
https://github.com/rtfb/riscv64-in-qemu/blob/93f7dbf85a5a45a492f324a7ccc3d29d96e8f238/Makefile#L92
[5]
https://github.com/zephyrproject-rtos/zephyr/blob/0c4e9d29bbc1b142ca738f86facb6e88218b629d/cmake/compiler/gcc/target_riscv.cmake#L10
[6]
https://sifive.cdn.prismic.io/sifive%2F15d1d90e-f60e-42a2-b6bf-c805c6c73b0d_riscv-large-code-model-workaround.pdf
[7] https://github.com/riscv/riscv-gcc/issues/164
Alejandro
> > --
> > 2.25.1
> >
> >
> >
> >
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151483):
https://lists.openembedded.org/g/openembedded-core/message/151483
Mute This Topic: https://lists.openembedded.org/mt/82674159/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
