GithubHelp home page GithubHelp logo

cnlohr / mini-rv32ima Goto Github PK

View Code? Open in Web Editor NEW
1.4K 30.0 107.0 301 KB

A tiny C header-only risc-v emulator.

License: MIT License

Makefile 8.74% C 88.52% JavaScript 0.14% Assembly 1.68% PowerShell 0.92%

mini-rv32ima's Introduction

riscv_emufun (mini-rv32ima)

Click below for the YouTube video introducing this project:

Writing a Really Tiny RISC-V Emulator But Will It Run Doom?

What

mini-rv32ima is a single-file-header, mini-rv32ima.h, in the STB Style library that:

  • Implements a RISC-V rv32ima/Zifencei†+Zicsr (and partial su), with CLINT and MMIO.
  • Is about 400 lines of actual code.
  • Has no dependencies, not even libc.
  • Is easily extensible. So you can easily add CSRs, instructions, MMIO, etc!
  • Is pretty performant. (~450 coremark on my laptop, about 1/2 the speed of QEMU)
  • Is human-readable and in basic C code.
  • Is "incomplete" in that it didn't implement the tons of the spec that Linux doesn't (and you shouldn't) use.
  • Is trivially embeddable in applications.

It has a demo wrapper that:

  • Implements a CLI, SYSCON, UART, DTB and Kernel image loading.
  • And it only around 250 lines of code, itself.
  • Compiles down to a ~18kB executable and only relies on libc.

†: Zifence+RV32A are stubbed. So, tweaks will need to be made if you want to emulate a multiprocessor system with this emulator.

Just see the mini-rv32ima folder.

It's "fully functional" now in that I can run Linux, apps, etc. Compile flat binaries and drop them in an image.

Why

I'm working on a really really simple C Risc-V emulator. So simple it doesn't even have an MMU (Memory Management Unit). I have a few goals, they include:

  • Furthering RV32-NOMMU work to improve Linux support for RV32-NOMMU. (Imagine if we could run Linux on the $1 ESP32-C3)
  • Learning more about RV32 and writing emulators.
  • Being further inspired by @pimaker's amazing work on Running Linux in a Pixel Shader and having the sneaking suspicion performance could be even better!
  • Hoping to port it to some weird places.
  • Understand the most simplistic system you can run Linux on and trying to push that boundary.
  • Continue to include my education of people about assembly language.

How

Windows instructions (Just playing with the image)

WSL (For full toolchain and image build:

  • You will need to remove all spaces from your path i.e. export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/Windows/system32:/snap/bin and continue the instructions. P.S. What in the world was Windows thinking, putting a space between "Program" and "Files"??!?

Linux instructions (both):

  • Clone this repo.
  • Install git build-essential and/or whatever other requirements are in place for buildroot.
  • make testdlimage
  • It automatically downloads the image (~1MB) and runs the emulator.
  • Should be up and running in about 2.5s depending on internet speed.

You can do in-depth work on Linux by:

  • make everything

If you want to play with the bare metal system, see below, or if you have the toolchain installed, just:

  • make testbare

If you just want to play emdoom, and use the prebuilt image:

  • On Windows, run windows\winrundoom.ps1
  • On Linux, cd mini-rv32ima, and type make testdoom

Questions?

  • Why not rv64?
    • Because then I can't run it as easily in a pixel shader if I ever hope to.
  • Can I add an MMU?
    • Yes. It actually probably wouldn't be too difficult.
  • Should I add an MMU?
    • No. It is important to further support for nommu systems to empower minimal Risc-V designs!

Everything else: Contact us on my Discord: https://discord.com/invite/CCeyWyZ

Hopeful goals?

  • Further drive down needed features to run Linux.
    • Remove need for RV32A extension on systems with only one CPU.
    • Support for relocatable ELF executables.
    • Add support for an unreal UART. One that's much simpler than the current 8250 driver.
  • Maybe run this in a pixelshader too!
  • Get opensbi working with this.
  • Be able to "embed" rv32 emulators in random projects.
  • Can I use early console to be a full system console?
  • Can I increase the maximum contiguous memory allocatable?

Special Thanks

More details

If you want to build the kernel yourself:

  • make everything
  • About 20 minutes. (Or 4+ hours if you're on Windows Subsytem for Linux 2)
  • And you should be dropped into a Linux busybox shell with some little tools that were compiled here.

Emdoom notes

  • Emdoom building is in the experiments/emdoom folder
  • You MUST build your kernel with MAX_ORDER set to >12 in buildroot/output/build/linux-5.19/include/linux/mmzone.h if you are building your own image.
  • You CAN use the pre-existing image that is described above.
  • On Windows, it will be very slow. Not sure why.

If you want to use bare metal to build your binaries so you don't need buildroot, you can use the rv64 gcc in 32-bit mode built into Ubuntu 20.04 and up.

sudo apt-get install gcc-multilib gcc-riscv64-unknown-elf make

Links

Attic

General notes:

(These things don't currently work)

Building Tests

(This does not work, now)

cd riscv-tests
export CROSS_COMPILE=riscv64-linux-gnu-
export PLATFORM_RISCV_XLEN=32
CC=riscv64-linux-gnu-gcc ./configure
make XLEN=32 RISCV_PREFIX=riscv64-unknown-elf- RISCV_GCC_OPTS="-g -O1 -march=rv32imaf -mabi=ilp32f -I/usr/include"

Building OpenSBI

(This does not currently work!)

cd opensbi
export CROSS_COMPILE=riscv64-unknown-elf-
export PLATFORM_RISCV_XLEN=32
make

Extra links

Using custom build

Where yminpatch is the patch from the mailing list.

rm -rf buildroot
git clone git://git.buildroot.net/buildroot
cd buildroot
git am < ../yminpatch.txt
make qemu_riscv32_nommu_virt_defconfig
make
# Or use our configs.

Note: For emdoom you will need to modify include/linux/mmzone.h and change MAX_ORDER to 13.

Buildroot Notes

Add this: https://github.com/cnlohr/buildroot/pull/1/commits/bc890f74354e7e2f2b1cf7715f6ef334ff6ed1b2

Use this: https://github.com/cnlohr/buildroot/commit/e97714621bfae535d947817e98956b112eb80a75

mini-rv32ima's People

Contributors

alexshpilkin avatar cnlohr avatar gagachang avatar jbylicki avatar jcodefox avatar lofcz avatar raspiduino avatar ronanj avatar rysteq avatar sellicott avatar splinedrive avatar thornley-david avatar tvlad1234 avatar xvuko avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

mini-rv32ima's Issues

Virtual Graphical interface

I would like to tell you that there is an old project in the Linux universe called Xvfb (https://en.wikipedia.org/wiki/Xvfb) that would be very interesting to implement in your emulator. Although I am not such an expert programmer (I have experience mostly with MSP430 MCUs in C), perhaps I could collaborate with your help... Although I found its graphic emulation with ASCII characters excellent and I loved it! (we are very nerds... :) )

Use as an embedded application loader

Have you played with the flipper zero? They have a runtime application system where they load an ELF file which has the 'kernel API' represented using jump relocations. They copy it into memory, perform the relocations, and jump to it.

I was wondering if you had thoughts around:

  1. Using mini-rv32ima as a bytecode interpreter, for instance on an esp32; and
  2. Loading the rv32 code from an ELF file and doing the relocations or whatever (or maybe we could do the same with CSRs and skip ELF loading entirely?)

My personal interest is that the stable Rust compiler can compile to risc-v, and I could make a runtime for my esp32's in C but then put the main logic in Rust code (which compiles to risc-v for interpretation). Having an indirection between firmware and main code would also help with pushing updates, writing tests, and propagating updates over a mesh network (or maybe I'm just too excited about ESP-NOW)

Yeah, thoughts?

Doom build fails since 32-bit libraries not installed (I think?)

Hey! Nice project!

I've gotten everything to work except for the Doom experiment.

Running make in the experiments/emdoom folder results in the following output:
$ make CC=../../../../buildroot/output/host/usr/bin/riscv32-buildroot-linux-uclibc-gcc CFLAGS="-mabi=ilp32 -fPIE -pie -flto" CFLAGS_FINAL="-mabi=ilp32 -flto -fPIE -pie -static -march=rv32ima -O4 -s -g -DNORMALUNIX -DLINUX -DMAXPLAYERS=1 -DDISABLE_NETWORK -static-libgcc -DSET_MEMORY_DEBUG=0 -DRANGECHECK -fdata-sections -ffunction-sections" LDFLAGS='-Wl,-elf2flt="-r -s 36000" -static -Wl,-Map=../../output.map -Wl,--gc-sections -flto' LIBS="" CS="../../video_console.c ../../extra_assembly.S" make -C embeddeddoom/src make[1]: Entering directory '/home/christoffer/mini-rv32ima/experiments/emdoom/embeddeddoom/src' gcc -m32 -DNORMALUNIX -DLINUX -L/usr/X11R6/lib -o support/shrinkwad support/shrinkwad.c -lXext -lX11 -lnsl -lm -lpthread /usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libXext.so when searching for -lXext /usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libXext.a when searching for -lXext /usr/bin/ld: cannot find -lXext: No such file or directory /usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libXext.so when searching for -lXext /usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libX11.so when searching for -lX11 /usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libX11.a when searching for -lX11 /usr/bin/ld: cannot find -lX11: No such file or directory /usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libX11.so when searching for -lX11 /usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libnsl.so when searching for -lnsl /usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libnsl.a when searching for -lnsl /usr/bin/ld: cannot find -lnsl: No such file or directory /usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libnsl.so when searching for -lnsl collect2: error: ld returned 1 exit status
I think it's because I don't have the 32-bit versions of the necessary libraries installed but I am stuck trying to install them. Running latest Ubuntu.

Human readable unit tests for rv64imafdc instructions

While developing my emulator (specifically implementing FD) i modified spike and dumped all register and csr reads/writes
Spend on it couple of days.
Maybe here it would be useful for someone.

File is gz compressed text file.
Each line is json object.

Fields:

type - single_instruction always
extension - rv ext
instruction - assemby mnemonic
text_encoding - disassembly
binary_encoding - actual bytes of instruction
initials - initial state of emulator
    - type
       - xreg_value
          - index - integer register id 
          - value
       - pc_value
          - value
asserts - conditions that checked after instruction executed

testcases.jsonlines.gz

out of ram for doom?

I tried to run the doom thing as the video looked like fun. but no matter what it always crashes saying its out of ram.. even allocating 2GB didnt help

./mini-rv32ima -f ../buildroot/output/images/Image -m 0x80000000

`Jan 1 00:00:01 login[28]: root login on 'console'
~ # ./emdoom [ 3.336385] ------------[ cut here ]------------
[ 3.336508] WARNING: CPU: 0 PID: 29 at mm/page_alloc.c:5406 0x80076c24
[ 3.336638] CPU: 0 PID: 29 Comm: emdoom Not tainted 5.19.0 #6
[ 3.336750] Hardware name: (efault) (DT)
[ 3.336858] epc : 0x80076c24
[ 3.336942] ra : 0x80076bf8
[ 3.337010] epc : 80076c24 ra : 80076bf8 sp : 806a7cc0
[ 3.337117] gp : 80923cd0 tp : 805a7000 t0 : 806a7ce8
[ 3.337219] t1 : fffff000 t2 : 00000037 s0 : 806a7d50
[ 3.337313] s1 : 00000cc0 a0 : 806a7cd0 a1 : 00000000
[ 3.337399] a2 : 00000000 a3 : 806a7ce8 a4 : 00000001
[ 3.337492] a5 : 8091f321 a6 : 806a7e00 a7 : 806a7e04
[ 3.337599] s2 : 0000000b s3 : 805a67d0 s4 : 00000000
[ 3.337687] s5 : 0000064b s6 : 00000000 s7 : 00000002
[ 3.337796] s8 : 0064b000 s9 : 00000003 s10: 00000001
[ 3.337902] s11: 806a2008 t3 : 00000004 t4 : 00000003
[ 3.338008] t5 : 00000001 t6 : 00000800
[ 3.338079] status: 00001880 badaddr: 80076c24 cause: 00000003
[ 3.338199] [<800776f0>] 0x800776f0
[ 3.338297] [<80077c48>] 0x80077c48
[ 3.338384] [<80072868>] 0x80072868
[ 3.338473] [<80069c84>] 0x80069c84
[ 3.338564] [<80069d0c>] 0x80069d0c
[ 3.338647] [<800c0898>] 0x800c0898
[ 3.338743] [<80085538>] 0x80085538
[ 3.338838] [<80085a30>] 0x80085a30
[ 3.338931] [<80086788>] 0x80086788
[ 3.339035] [<80002048>] 0x80002048
[ 3.339125] ---[ end trace 0000000000000000 ]---
[ 3.339218] nommu: Allocation of length 6598656 from process 29 (emdoom) failed
[ 3.339362] active_anon:0 inactive_anon:0 isolated_anon:0
[ 3.339362] active_file:0 inactive_file:0 isolated_file:0
[ 3.339362] unevictable:1980 dirty:0 writeback:0
[ 3.339362] slab_reclaimable:0 slab_unreclaimable:172
[ 3.339362] mapped:0 shmem:0 pagetables:0 bounce:0
[ 3.339362] kernel_misc_reclaimable:0
[ 3.339362] free:516712 free_pcp:0 free_cma:0
[ 3.339852] Node 0 active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:7920kB isolated(anon):0kB isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB writeback_tmp:0kB kernel_stack:128kB pagetables:0kB all_unreclaimable? no
[ 3.340191] Normal free:2066848kB boost:0kB min:5752kB low:7820kB high:9888kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:7920kB writepending:0kB present:2097148kB managed:2076976kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
[ 3.340580] lowmem_reserve[]: 0 0
[ 3.340705] Normal: 44kB (M) 28kB (M) 416kB (UM) 632kB (U) 864kB (UM) 7128kB (UM) 9256kB (UM) 7512kB (UM) 11024kB (U) 32048kB (M) 501*4096kB (M) = 2066848kB
[ 3.341335] 1981 total pagecache pages
[ 3.341426] binfmt_flat: Unable to allocate RAM for process text/data, errno -12

Segmentation fault`

thanks

Bare-metal libc

I am trying to make a bare-metal hello world program with uclibc, but I am not sure how to do it. Can I please get some suggestions?

inittab for buildroot

TODO: Make it so the scripts build out to replace getty in the inittab.

console::respawn:/bin/login -f root

How do we add this to the build system?

U-BOOT

Hello,
How to compile U-BOOT for this?
I'm trying to run this on an ESP-32 and it needs uboot.

Kernel panics on emulator compiled for ARM (trying to run linux on the Raspberry Pi Pico)

I am currently trying to use this emulator core to run Linux on the Raspberry Pi Pico. I have managed to solve the lack of RAM by storing memory contents on an SD card and using about 128K of internal SRAM as cache. It is quite slow, but seems to be working, it takes the emulator 30 seconds to get to the point where the kernel panics. I am using the provided precompiled Buildroot images. It always panics in the same spot, with the exact trace. I don't have any experience working with RISC-V so far, so I don't know where to start troubleshooting. This is what the kernel panic shows:
image

vi with no filename faults with access fault

After
$ make testdlimage
I login to Linux (amazing!) and then attempt to run vi:
~ # vi
11.662352] Oops - load access fault [#1]
[ 11.662595] CPU: 0 PID: 29 Comm: vi Not tainted 5.18.0 #7
[ 11.662919] Hardware name: riscv-minimal-nommu,qemu (DT)
[ 11.663180] epc : 0x800d9088
[ 11.663341] ra : 0x80081f20
[ 11.663496] epc : 800d9088 ra : 80081f20 sp : 807a1e90
[ 11.663860] gp : 802cf420 tp : 807aa000 t0 : 807a1dfc
[ 11.664181] t1 : 809af010 t2 : 80998c24 s0 : 807a1ea0
[ 11.664505] s1 : 809af000 a0 : 00000ff0 a1 : 00000000
[ 11.664808] a2 : 00000ff0 a3 : 00000000 a4 : 00000122
[ 11.665091] a5 : 00000ff0 a6 : 00000ff0 a7 : 00000000
[ 11.665374] s2 : 00000000 s3 : 807a1f38 s4 : 00000000
[ 11.665656] s5 : 00000000 s6 : 802d0000 s7 : 00001000
[ 11.665939] s8 : 00000000 s9 : 809aee78 s10: 0000000e
[ 11.666284] s11: 00000000 t3 : fefefeff t4 : 80808080
[ 11.666588] t5 : 00000800 t6 : 00000025
[ 11.666825] status: 00001880 badaddr: 00000001 cause: 00000005
[ 11.667207] ---[ end trace 0000000000000000 ]---
Segmentation fault
~ #
This does not happen if a filename is specified, e.g.

vi x.x

Atomic instruction emulation

From riscv privileged spec:

3.1.8 Machine Trap Delegation Registers (medeleg and mideleg)

By default, all traps at any privilege level are handled in machine mode, though a machine-mode
handler can redirect traps back to the appropriate level with the MRET instruction (Section 3.3.2).

Generally, linux runs in supervisor mode, and can't guarantee that machine mode interrupt doesn't happens in the middle of emulating atomic instruction

Proper implentation of atomic instructions would look something like this.

  1. Emulator encounters unknown instruction and emit Illegal instruction trap
  2. sbi implementation parses instruction and does emulation
   bool saved_mie = get_mie_from_mstatus();
   set_mie_in_mstatus(0);

   // atomic instruction emulation

   set_mie_in_mstatus(saved_mie);

Or you can embed same code directly into linux for better perf if:

  • linux runs in machine mode
  • system has one hart (core)

Customizing allowed instruction set?

Hello!

I am looking into this project in the context of making an arguably somewhat esoteric "fantasy console" that tries as hard as possible to be a realistic PSX-style game console and would run on an emulated RISC-V core w/ memory mapped peripherals, etc, and wanted to avoid having to write the core emulator myself.

Ideally, I would like to opt for a very minimal rv32em instruction set, which is what I have built my GCC toolchain to target. Of course a full rv32ima core would run such instructions just fine, but I'd like to restrict the allowed registers & instruction set for added challenge. Is there a good way for me to accomplish this, should I just fork and trim out what I don't need, etc.?

"make testdlimage" => "./mini-rv32ima -f DownloadedImage" ... hangs (tested on 3 different platforms).

Yesterday, on my laptop, everything went well

But today, on 3 other different platforms (Ubuntu, Ubuntu, WSL), fresh git clone, fresh make, it hangs on ./mini-rv32ima -f DownloadedImage

Pressing CTRL-C gives a register overview?

sander@brixit:~/git/mini-rv32ima$ make testdlimage
make -C mini-rv32ima testdlimage
make[1]: Entering directory '/home/sander/git/mini-rv32ima/mini-rv32ima'
echo "#include <stdio.h>" > bintoh.c
echo "int main(int argc,char ** argv) {if(argc==1) return -1; int c, p=0; printf( \"static const unsigned char %s[] = {\", argv[1] ); while( ( c = getchar() ) != EOF ) printf( \"0x%02x,%c\", c, (((p++)&15)==15)?10:' '); printf( \"};\" ); return 0; }" >> bintoh.c
gcc bintoh.c -o bintoh
./bintoh default64mbdtb < sixtyfourmb.dtb > default64mbdtc.h
# WARNING: sixtyfourmb.dtb MUST hvave at least 16 bytes of buffer room AND be 16-byte aligned.
#  dtc -I dts -O dtb -o sixtyfourmb.dtb sixtyfourmb.dts -S 1536
# for debug
gcc -o mini-rv32ima mini-rv32ima.c -g -O2 -Wall
gcc -o mini-rv32ima.tiny mini-rv32ima.c -Os -ffunction-sections -fdata-sections -Wl,--gc-sections -fwhole-program -s
wget https://github.com/cnlohr/mini-rv32ima-images/raw/master/images/linux-6.1.14-rv32nommu-cnl-1.zip -O linux-6.1.14-rv32nommu-cnl-1.zip
--2023-04-13 17:50:35--  https://github.com/cnlohr/mini-rv32ima-images/raw/master/images/linux-6.1.14-rv32nommu-cnl-1.zip
Resolving github.com (github.com)... 140.82.121.4
Connecting to github.com (github.com)|140.82.121.4|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://raw.githubusercontent.com/cnlohr/mini-rv32ima-images/master/images/linux-6.1.14-rv32nommu-cnl-1.zip [following]
--2023-04-13 17:50:35--  https://raw.githubusercontent.com/cnlohr/mini-rv32ima-images/master/images/linux-6.1.14-rv32nommu-cnl-1.zip
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.199.109.133, 185.199.110.133, 185.199.111.133, ...
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.199.109.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1507463 (1,4M) [application/zip]
Saving to: ‘linux-6.1.14-rv32nommu-cnl-1.zip’

linux-6.1.14-rv32nommu-cnl-1.zip                100%[====================================================================================================>]   1,44M  --.-KB/s    in 0,03s

2023-04-13 17:50:35 (47,2 MB/s) - ‘linux-6.1.14-rv32nommu-cnl-1.zip’ saved [1507463/1507463]

unzip linux-6.1.14-rv32nommu-cnl-1.zip
Archive:  linux-6.1.14-rv32nommu-cnl-1.zip
  inflating: Image
mv Image DownloadedImage
./mini-rv32ima -f DownloadedImage

... hang. So CTRL-C:

PC: 80001cbc [0x34021273] Z:00000000 ra:80001e4c sp:802e31d0 gp:80351078 tp:8030f340 t0:00001fff t1:802e31d0 t2:802e3210 s0:802e32f0 s1:00001800 a0:802e3260 a1:00000001 a2:802e32d8 a3:80351000 a4:00000080 a5:803510e4 a6:00000000 a7:8034c89e s2:800076f0 s3:800076f0 s4:00000002 s5:8030f340 s6:00000008 s7:802f6fe5 s8:802f5758 s9:00000007 s10:00000019 s11:00000000 t3:00000000 t4:8035c096 t5:8035c06c t6:802f577c
make: *** [Makefile:24: testdlimage] Interrupt

sander@brixit:~/git/mini-rv32ima$

"make everything" fails with 'elf2flt: ERROR: text=0x72698 overlaps data=0x698a0'

../../buildroot/output/host/bin/riscv32-buildroot-linux-uclibc-gcc duktape-2.7.0/src-noline/duktape.c duktape-2.7.0/examples/cmdline/duk_cmdline.c duktape-2.7.0/extras/console/duk_console.c -Wall -O2 -Iduktape-2.7.0/src-noline -DDUK_CMDLINE_CONSOLE_SUPPORT -Iduktape-2.7.0/extras/console -Wl,-elf2flt="-r -s 196608" -o duktapetest
~/mini-rv32ima/buildroot/output/host/riscv32-buildroot-linux-uclibc/bin/elf2flt: ERROR: text=0x72698 overlaps data=0x698a0 ?
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:21: duktapetest] Error 1
make[1]: Leaving directory '~/mini-rv32ima/packages/duktapetest'
make: *** [Makefile:16: everything] Error 2

Please express true isa as RV32IMAZicsr_Zifencei

This is RV32IMAZicsr_Zifencei.
you should also note that the atomics are non-atomic operations and are used for bit manipulation.

Base Integer Instruction Set, 32-bit | 40
Standard Extension for Integer Multiplication and Division | 8
Standard Extension for Atomic Instructions | 11
Control and Status Register (CSR) | 6
Instruction-Fetch Fence | 1

totaling in 66 instructions

Can't compile the baremetal example

Hi. Nice work there, by the way...
But I can't compile the baremetal test. I'm using the buildroot toolchain. Maybe I should use another one ?
I get this:
make testbare make -C baremetal make[1]: Entering directory '/opt/sandbox/mini-rv32ima/baremetal' ../buildroot/output/host/bin/riscv32-buildroot-linux-uclibc-gcc -o baremetal.elf baremetal.c baremetal.S -fno-stack-protector -static-libgcc -fdata-sections -ffunction-sections -g -Os -march=rv32ima -mabi=ilp32 -static -T flatfile.lds -nostdlib -Wl,--gc-sections baremetal.c: Assembler messages: baremetal.c:16: Error: unrecognized opcode csrrw x0,0x138,s1'
baremetal.c:16: Error: unrecognized opcode csrrw x0,0x138,a5' baremetal.c:16: Error: unrecognized opcode csrrw x0,0x138,a5'
baremetal.c:21: Error: unrecognized opcode csrrw x0,0x137,a5' baremetal.c:16: Error: unrecognized opcode csrrw x0,0x138,a5'
baremetal.c:16: Error: unrecognized opcode csrrw x0,0x138,s1' baremetal.c:31: Error: unrecognized opcode csrr a1,0xC00'
baremetal.c:31: Error: unrecognized opcode csrr a5,0xC00' baremetal.c:16: Error: unrecognized opcode csrrw x0,0x138,a4'
baremetal.c:26: Error: unrecognized opcode csrrw x0,0x136,a5' baremetal.c:16: Error: unrecognized opcode csrrw x0,0x138,a5'
baremetal.c:16: Error: unrecognized opcode csrrw x0,0x138,s0' baremetal.S: Assembler messages: baremetal.S:28: Error: unrecognized opcode csrw 0x138,t0'
Makefile:16: recipe for target 'baremetal.elf' failed
make[1]: *** [baremetal.elf] Error 1
make[1]: Leaving directory '/opt/sandbox/mini-rv32ima/baremetal'
Makefile:25: recipe for target 'testbare' failed
make: *** [testbare] Error 2`

Can it run OpenSBI?

Hi!

I have a pre-compiled risc-v opensbi image with the following:
image

So what file am i supposed to execute with the emulator? I tried fw_jump.bin but it didn't work.

Possible to get a full debian running on this?

Heyas!

Would it be possible to get a full apt based distro running on this, e.g. https://github.com/yuzibo/riscv32/wiki ? Is using flat binaries instead of elf a requirement due to the lack of mmu? Does this mean no dynamic linking? If so this sounds hard...

Background:
My goal is a bit of a funny one:

I want to find / build a hardware emulator that can run a full modern linux distro (in text mode only), with the requirements that a) the emulator source code (not binary) is really small, b) that the emulator source code is in as small as possible subset of whatever programming language it is built in as possible and c) the rootfs and kernel can be appended to the emulator source as a b64 encoded string constant c)

The goal is for this subset programming language to be small enough to teach only by example (no explanations / comments, only code, input plus output, to someone who does not know anything about the language, or even english). That is, someone who reads this arcive should be able to see these examples and the emulator code with the kernel/rootfs in it, figure out how to run it with no help, and get a running full current day linux system.

Would your project be a good starting point? I've also been looking at https://github.com/sysprog21/semu but that is a considerably larger codebase.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.