Problems building/simulating risc-v linux using freedom-u-sdk

[David H. Lynch Jr.]

I have pulled the current git repository for the freedom-u-sdk

Straight from the repository I can build and run a risc-v 64 bit linux.
using either make sim or make qemu

But I need to build a risc-v 32 bit linux.

with several changes noted below I 
can built "make sim" but the spike execution just hangs - there is no
output.

make qemu terminates with lots of link errors in stress.


While I can eventually work this out - the freedom-u-sdk is fairly
opaque to me.

I would appreciate any clues - even merely suggestions as to the most
likely place to look for problems.


I have had to change 64 bits to 32 bits in about half a dozen places to
get all the way through "make sim"


diff --git a/Makefile b/Makefile
index 7f528cb..a87301a 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 RISCV ?= $(CURDIR)/toolchain
 PATH := $(RISCV)/bin:$(PATH)
-ISA ?= rv64imafdc
-ABI ?= lp64d
+ISA ?= rv32imafdc
+ABI ?= ilp32d
 
 srcdir := $(dir $(realpath $(lastword $(MAKEFILE_LIST))))
 srcdir := $(srcdir:/=)
@@ -45,11 +45,11 @@ spike := $(spike_wrkdir)/prefix/bin/spike
 
 qemu_srcdir := $(srcdir)/riscv-qemu
 qemu_wrkdir := $(wrkdir)/riscv-qemu
-qemu := $(qemu_wrkdir)/prefix/bin/qemu-system-riscv64
+qemu := $(qemu_wrkdir)/prefix/bin/qemu-system-riscv32
 
 rootfs := $(wrkdir)/rootfs.bin
 
-target := riscv64-unknown-linux-gnu
+target := riscv32-unknown-linux-gnu
 
 .PHONY: all
 all: $(hex)
@@ -181,7 +181,7 @@ $(qemu): $(qemu_srcdir)
  mkdir -p $(dir $@)
  cd $(qemu_wrkdir) && $</configure \
  --prefix=$(dir $(abspath $(dir $@))) \
- --target-list=riscv64-softmmu
+ --target-list=riscv32-softmmu
  $(MAKE) -C $(qemu_wrkdir)
  $(MAKE) -C $(qemu_wrkdir) install
  touch -c $@
diff --git a/conf/buildroot_initramfs_config
b/conf/buildroot_initramfs_config
index ab434d3..ad6cca4 100644
--- a/conf/buildroot_initramfs_config
+++ b/conf/buildroot_initramfs_config
@@ -1,4 +1,4 @@
-BR2_riscv64=y
+BR2_riscv64=n
 BR2_TOOLCHAIN_EXTERNAL=y
 BR2_TOOLCHAIN_EXTERNAL_PATH="$(RISCV)"
 BR2_TOOLCHAIN_EXTERNAL_CUSTOM_PREFIX="$(ARCH)-unknown-linux-gnu"
diff --git a/conf/buildroot_rootfs_config
b/conf/buildroot_rootfs_config
index c0ba5a7..0a5c6a3 100644
--- a/conf/buildroot_rootfs_config
+++ b/conf/buildroot_rootfs_config
@@ -1,4 +1,4 @@
-BR2_riscv64=y
+BR2_riscv64=n
 BR2_TOOLCHAIN_EXTERNAL=y
 BR2_TOOLCHAIN_EXTERNAL_PATH="$(RISCV)"
 BR2_TOOLCHAIN_EXTERNAL_CUSTOM_PREFIX="$(ARCH)-unknown-linux-gnu"
diff --git a/conf/linux_defconfig b/conf/linux_defconfig
index 7e703d5..bbbc025 100644
--- a/conf/linux_defconfig
+++ b/conf/linux_defconfig
@@ -4,7 +4,7 @@ CONFIG_HZ_100=y
 CONFIG_PCI=y
 CONFIG_PCI_DEBUG=y
 CONFIG_PCIE_XILINX=y
-CONFIG_CROSS_COMPILE="riscv64-unknown-linux-gnu-"
+CONFIG_CROSS_COMPILE="riscv32-unknown-linux-gnu-"
 CONFIG_DEFAULT_HOSTNAME="ucbvax"
 # CONFIG_CROSS_MEMORY_ATTACH is not set
 CONFIG_NAMESPACES=y
diff --git a/conf/linux_framebuffer_smp b/conf/linux_framebuffer_smp
index 4d87fb2..c1345da 100644
--- a/conf/linux_framebuffer_smp
+++ b/conf/linux_framebuffer_smp
@@ -1,7 +1,7 @@
 CONFIG_SMP=y
 # CONFIG_COMPACTION is not set
 CONFIG_HZ_100=y
-CONFIG_CROSS_COMPILE="riscv64-unknown-linux-gnu-"
+CONFIG_CROSS_COMPILE="riscv32-unknown-linux-gnu-"
 CONFIG_DEFAULT_HOSTNAME="ucbvax"
 # CONFIG_CROSS_MEMORY_ATTACH is not set
 CONFIG_NAMESPACES=y
diff --git a/riscv-gnu-toolchain b/riscv-gnu-toolchain
--- a/riscv-gnu-toolchain
+++ b/riscv-gnu-toolchain
@@ -1 +1 @@
-Subproject commit b4dae89f85bf882852c6186b1284df11065bfcd9
+Subproject commit b4dae89f85bf882852c6186b1284df11065bfcd9-dirty

[Jim Wilson]

On Wed, Feb 7, 2018 at 12:01 PM, David H. Lynch Jr. <dhly...@gmail.com> wrote:
> Straight from the repository I can build and run a risc-v 64 bit linux.
> using either make sim or make qemu
>
> But I need to build a risc-v 32 bit linux.

We only support 64-bit linux at present.

The 32-bit linux binutils/gcc/glibc support should be good. The
32-bit qemu user support should be good. We test this regularly using
the binutils and gcc testsuites. I know that there is a problem with
stack unwinding through an exception frame, but that is probably an
issue of the 32-bit qemu user support not tracking all of the ucontext
changes that have been made over the last few months. I don't think
that this would affect booting the kernel. The 32-bit glibc support
has not been upstreamed yet, but that is mostly because we didn't have
enough time to validate both the 64-bit and 32-bit support in time for
the glibc-2.27 release, so we could only upstream the 64-bit support.
The plan is to add the 32-bit support before the next glibc release.
This is unlikely to require much in the way of changes, this is mostly
spending time running tests to validate it.

I don't know if anyone has tested the 32-bit kernel support, or the
32-bit qemu system support.

Jim

[David H. Lynch Jr.]

Thank you.

I understand that 32bit support is not current or a priority for
others.

But it is critical for me. That means I am available to work towards
getting it running. 
You have given me some clues.

I do not care what risc-v simulator I use - atleast for now.
I have tried both spike and qemu.

I only care about the minimum necescary to start a risc-v linux kernel.
I do not (at this time) need a rootfs - I beleive that means I do not
need buildroot or glibc - except that the current freedom-u-sdk is
setup to create those.

Assuming that I am going to put some effort into getting 32 bits
working, and assuming my priority is just getting a riscv 32bit linuc
kernel to start booting.

Can I get some direction regarding where to direct my efforts ?

Do I look at spike or qemu ? as an example.








On Wed, 2018-02-07 at 12:38 -0800, Jim Wilson wrote:
> On Wed, Feb 7, 2018 at 12:01 PM, David H. Lynch Jr. <dhlynch2@gmail.c

[Jim Wilson]

On Wed, Feb 7, 2018 at 12:57 PM, David H. Lynch Jr. <dhly...@gmail.com> wrote:
> Can I get some direction regarding where to direct my efforts ?
> Do I look at spike or qemu ? as an example.

I'm not a kernel guy, so I can't give much help in that direction.

The serious work is happening with qemu. I think people only look at
spike because it is the reference implementation, and hence sometimes
useful for answering questions about how something is supposed to
work. Spike has no device support, so if you want to be able to talk
to anything after booting the kernel, you need qemu.

Jim