ipacman

This side comment related to opensbi in https://github.com/ultraembedded/opensbi vs riscv32-unkown-elf-gcc generated from https://github.com/ultraembedded/riscv32_linux_from_scratch. The 'latest generated' riscv32-unkown-elf-gcc (v10.1.0) does not successfully compile/link the opensbi in https://github.com/ultraembedded/opensbi. Including a note here...

In my case, there is no buildroot directory since I cheated and used your DownloadedImage. Happy to $ make everything ..which I assume generates the tools and vmlinux.o file. But...

The default buildroot configs do not appear to select vi. The configs/buildroot_config points at busybox-minimal.config. Wondering what the 'DownloadedImage' used for busybox config? There are several busybox config files in...

Ok, in order to restore vi into the built image, I changed line 498 of configs/buildroot_config from: BR2_PACKAGE_BUSYBOX_CONFIG="package/busybox/busybox-minimal.config" to BR2_PACKAGE_BUSYBOX_CONFIG="busybox_config" Then did a "make clean" inside buildroot (and removed the...

I verified that vi initializes without a filename with -H option. That means it loads ok and thinking something with the filename parameter. So, did a quick look in buildroot/output/busybox-1.35.0/editors/vi.c...

I've located the location of the trap within the kernel function "strncpy_from_user" with the following call stack: do_se_sys_openat() do_sys_open() do_sys_openat2() getname() getname_flags() strncpy_from_user(): 000f4e4c : f4e4c: ff010113 addi sp,sp,-16 f4e50:...

Added some traceback code to mini-rv32 and traced back from the fault into userspace. The fault is triggered starting inside busybox vi.c file_insert() function at the call to fopen: fd...