Ariane Cache

[jctullos]

Hello,

I saw on the website cache isn't implemented yet for Ariane. Is that still the case? Is there any branches that I could test out that uses cache?

Thank you!

[paulmnt]

Thank you for your interest @jctullos. A preliminary interface of Ariane to the ESP cache hierarchy is available on the branch dev-ariane-smp.

This branch is still not stable, but it supports already Linux booting with one Ariane core and the cache hierarchy present. In addition, all accelerators coherence models (non-coherent DMA, LLC-coherent DMA, coherent DMA and fully-coherent mode) are working properly.

In order to enable multi-core, however, we must first change the Ariane L1 and bus interfaces to enable L1 cache invalidation. Once this edit is complete and merged to the upstream repository in Ariane, we will be able to merge the feature in ESP as well.

[jctullos]

@paulmnt Oh that's perfect, thank you for the response! For my research, I only need 1 core instantiated. I will check out the branch and see how it does!

One last question, does ESP incorporate the Ariane changes to add PMP from around 14 July?

[paulmnt]

Not yet, but I plan to bump Ariane before changing its code. You may try upgrading it right away, if you need that specific commit:

cd esp/third-party/ariane
git checkout master
git pull
git submodule update --recursive

After you pull, most likely you will have to apply minor patches to the following files:

• esp/utils/ariane_verilog.txt is the list of RTL files to compile inside the Ariane repository.
• esp/rtl/src/ariane/ariane/ariane_wrap.sv is the SystemVerilog wrapper for Ariane, based on the code from Ariane's repo in esp/third-party/ariane/fpga/src/ariane_xilinx.sv
• esp/socs/common/ariane_soc_pkg.sv is the SystemVerilog package that defines a few constants for the interface of Ariane.

[jctullos]

Thank you for the information. I was able to build and boot on the VCU118 before doing an Ariane bump. But Linux had some problems. It gets through the bootup until mounting a files system and I get this error:

It happens each time I try to boot. I'm assuming it's having trouble with the initramfs. Have you seen this before?

[davide-giri]

Hi,

It seems you don't have the full file system, that happens when you don't run the utils/scripts/build_riscv_toolchain.sh script in your ESP clone. To know if this is the problem, after compiling Linux with make linux, check the content of the sysroot folder in your VCU118 design folder.

If you run ls in the sysroot folder you should get this:

applications  bin  dev  etc  init  lib  lib64  linuxrc  media  mnt  opt  proc  root  run  sbin  sys  tmp  usr  var

Instead, if you didn't run the script correctly you will get this:

etc  usr

The instructions for running the script are here: https://www.esp.cs.columbia.edu/docs/setup/setup-guide/#software-toolchain.

[jctullos]

Thanks @davide-giri ! I was in the process of running the riscv scripts as you posted that. I already had the tools built for another build, but figured there's added things that ESP includes.

After deleting the sysroot folder and running make-linux again, all the folders show up now. Once it loads, I'll let you know if it works!

[jctullos]

It worked! Was able to reach login. Thank you both!

[davide-giri]

Perfect!

If you have already installed the toolchain once on a machine, you just have to repeat the third step of the utils/scripts/build_riscv_toolchain.sh for each new ESP clone, you can skip the first two. Specifically this is the step you need to execute:

*** Populating root file system w/ buildroot ... ***

[jctullos]

Am I able to change the ram size easily? The build only has 500mb, but the vcu118 has extra I'd like to use.

[paulmnt]

The current setup builds with 1GB of addressable DRAM, of which 512MB are cached in Ariane's L1 and used by the OS (`0x80000000 - 0xA0000000). The remaining 512MB are cached by the ESP L2 and LLC, but not Ariane's L1 and are used for devices (e.g. Ethernet) and accelerators (0xA0000000 - 0xC0000000).

You may easily expand the OS memory up to almost 2GB (0x80000000 - 0xF8000000). Going beyond that requires a bit of work to expand the address width for some of the interconnect adapters and proxy components. This is already in our TODO list.

For the time being, if 2GB can do, edit these lines

DRAMLength       => X"0000_0000_7800_0000",
DRAMCachedLength => X"0000_0000_7800_0000")

This setup will not leave any area for the ESP allocator, so ESP accelerators will not work correctly, not even in fully-coherent mode, because Ariane is still missing the invalidate interface for the L1. If you wish to preserve some area for accelerators, reduce the DRAMCachedLength.

Note that after changing these parameters, you need to update the device tree ariane.dts, and, if using accelerators, the init script that loads ESP drivers in Linux sysroot/etc/init.d/S64esp. Both files are generated, but I would change them manually until you have a stable version. Then you may edit the generator utils/socmap/socmap_gen.py.

Optionally, you can update the size of the available DRAM for the bootloader as well.

[jctullos]

Thank you Paul for the detailed instructions.

So I'm assuming that when Linux boots, and shows the various allocations for accelerators, it's only listing them.

They're not activated correct? The cache I'm good with, but I don't want accelerators like the fft and adder turned on for benchmarks.

[paulmnt]

We've added an lsmod in the init script just to show the drivers that have been loaded. However, since you don't have accelerators in the system instance, no device is registered and drivers won't affect your experiments.

If you don't want those to be loaded at all, you can remove sysroot/etc/init.d/S64esp and sysroot/etc/init.d/S65drivers from sysroot in your design folder. Just recompile Linux and at the next boot accelerators' drivers won't be loaded.

[jctullos]

Ah thank you!

And sorry for so many questions! I didn't see any documentation for changing the CPU frequency. If I change the freq in top.vhd to 100MHz instead of 78, are there any additional changes I would make that would affect either the UART or Ethernet clocks?

I synthesized the build and at first glance, everything was generated correctly. No issues with timing on the design. I'm remaking Linux right now to test it.

[paulmnt]

We are happy to answer questions, no worries!

We have set frequencies on all boards to make sure that most designs will meet timing, regardless of the number of accelerator tiles that you add and considering the performance achievable by the third-party IPs (such as Ariane). Please note that Ariane will not close faster than 78MHz on VCU118 very easily. I believe that 100 MHz with the default ESP configuration (1 CPU tile + 1 memory tile + I/O tile) should work, although you may notice small setup violations. Typically, the critical paths are inside the FPU.

Having said that, changing the CPU_FREQ constant in top.vhd will not actually change the frequency of the synthesized design, but it will change the values of the scaler computed for Ethernet and UART, so they will not work correctly.

If you want to change the frequency of the design, then you must also edit the constraint files. For VCU118, for example, all constraints and pin allocations are stored in the folder constraints/xilinx-vcu118-xcvu9p. The file you need to change is mig.tcl:

set_property -dict [list \
                        CONFIG.C0_CLOCK_BOARD_INTERFACE {default_250mhz_clk1} \
                        CONFIG.C0.DDR4_TimePeriod {1600} \
                        CONFIG.C0.DDR4_InputClockPeriod {4000} \
                        CONFIG.C0.DDR4_CLKOUT0_DIVIDE {8} \
                        CONFIG.C0.DDR4_MemoryPart {MT40A256M16GE-083E} \
                        CONFIG.C0.DDR4_DataWidth {64} \
                        CONFIG.C0.DDR4_DataMask {DM_NO_DBI} \
                        CONFIG.C0.DDR4_Ordering {Strict} \
                        CONFIG.C0.DDR4_CasLatency {9} \
                        CONFIG.C0.DDR4_CasWriteLatency {9} \
                        CONFIG.C0.DDR4_Mem_Add_Map {BANK_ROW_COLUMN} \
                        CONFIG.ADDN_UI_CLKOUT1_FREQ_HZ {78} \ # EDIT THIS LINE to change Ariane's clock
                        CONFIG.C0.BANK_GROUP_WIDTH {1}\
                       ] [get_ips mig]

After applying this change, make sure to run make vivado-distclean before repeating synthesis, or the memory interface generator will not pick the update.

[jctullos]

That's great! I'll try it out later.

FYI, bumping the Ariane submodule so that I can include PMP works! The files you mentioned earlier were exactly the ones needing to be patched. Nothing needed to be changed in ariane_soc_pkg.sv file.

[paulmnt]

Great and thank you for letting me know!

[Kendidi]

@jctullos

Hi, did you went through the whole process, from building bootroom, bbl to vmlinux? Is it possible to just build the bbl and vmlinux and use Ariane bit file from CVA6? Thanks.

[jctullos]

Hey Kendidi,

I used the whole process. You can build bbl and Linux without generating the entire bitstream. But it has configurations and patches specific to ESP, so it probably wouldn't work on other builds.

[Kendidi]

Hi Jctullos,

I see. I do not have the Xilinx license to build bitfiles. Would be nice if they have pre-built bit files for Ariane on Xilinx VCU128.

[davide-giri]

Hi @Kendidi,

I have uploaded on the ESP website the pre-built files for the Xilinx VCU128 board for an SoC with 1 Ariane core. You can find it here https://www.esp.cs.columbia.edu/prebuilt/singlecore/ with the name ESP_singlecore_ariane_nocaches_vcu128_20200925_GitRev278f1a2.tar.gz.

The guide on how to design and use a single core ESP SoC is here: https://www.esp.cs.columbia.edu/docs/singlecore/singlecore-guide. At the bottom, the guide includes the instructions on how to use the prebuilt material.

Please, let us know if you have any further question. Thank you!

[paulmnt]

Hi, did you went through the whole process, from building bootroom, bbl to vmlinux?

Is it possible to just build the bbl and vmlinux and use Ariane bit file from CVA6?

Yes, the generated bbl file can be used for Ariane's SD card boot. The patches in Linux and BBL are simply adding support for peripherals from GRLIB, which we use in ESP. Other than that, both Linux and BBL are not modified. Please note that ESP drivers are not necessary with the CVA6 design, so you can remove their init scripts from the sysroot/etc/init.d to avoid error messages after boot completes. The scripts are S64 and S65. After removing them, you just need to recompile with 'make linux'.

[Kendidi]

Thank you @davide-giri !! I will check it out. Appreciate it.

Hi @paulmnt, the Xilinx VCU128 board I have has no SD card slot. It has jTAG support though. Can I use OpenOCD & GDB to load the bbl (with vmlinux embedded) to certain memory address and run instead?

[paulmnt]

Hi @Kendidi

When I mentioned the SD card, I was referring to the FPGA bit built with the CVA6 repo. Their default flow to run on FPGA relies on SD card and, for that flow, you may use the bbl image built within ESP, instead of the image built with Ariane SDK.

Instead, if you use the ESP prebuilt image that @davide-giri created, you only need to connect the VCU128 to the same local Ethernet network of your computer and use the included runme.sh script.

We are not relying on GDB to load programs. Instead, ESP has an Ethernet link based on the GRLIB EDCL IP, which allows for faster boot. The ESP guide to configure the debug link describes a couple of options to get the connection with the FPGA working.

I recommend using a router, if available, but the direct link does work as well. If you use a router, your computer can connect to it via Wi-Fi, while the FPGA must use a cable.

The prebuilt image for VCU128 is configured as follows:

  # Assume local network DHCP IPs are of the type 192.168.1.x and 192.168.1.12 is available
  ESPLINK_IP  : 192.168.1.12
  ESPLINK_PORT  :  46392

Whether you're using a router or a direct link with your computer NIC, it is possible to configure DHCP such that 192.168.1.12 is a valid IP.

When you run the runme.sh script in the prebuilt folder two things will happen: 1) Vivado will try to program the VCU128 FPGA assuming the JTAG port is connected to your machine (localhost, port 3121). 2) the esplink application will load the bootloader on a BRAM and the Linux image on the VCU128 DDR memory. Then esplink sends a reset to the Ariane processor to boot the system. The application can only work if your computer and the FPGA are connected to the same Ethernet subnetwork and 192.168.1.12 is a valid address on such network.

Please let us know if you have troubles booting the system. Thank you!

[Kendidi]

Thank you @paulmnt for the detailed information. I will try it out.

[Kendidi]

@jctullos

I am curious which FPGA board have you been using?

[jctullos]

I've been using the VCU118. But having some trouble with Linux again.

It's hanging now between BBL and Linux. I was having the same proble with the openpiton build. I wonder if it's because of PMP, there might be an issue with it.

[davide-giri]

Just a clarification, the pre-built material for the single-core SoC tutorial does not contain the runme.sh script. The instructions on how to use the pre-built material are at the end of the tutorial.

[Kendidi]

Ooh, I see. Thank you @davide-giri !!

[Kendidi]

From documentation:

top.bit: FPGA bitstream. Place this file in socs//vivado/esp-.runs/impl_1/.

I do not have "vivado/..." folder in "~/esp/socs/xilinx-vcu128-xcvu37p/" on my setup.

I have Vivado installed a while back at "~/xilinx/Xilinx_Vivado_Lab_Lin_2019.2_1106_2127". I believe I can manually use Vidao to load top.bit to VCU128. Is this version OK?

When you run the runme.sh script in the prebuilt folder two things will happen:

I found one copy of runme.sh: "~/esp/third-party/accelerators/dma64/NV_NVDLA/test/runme.sh". Is this the one I should use?

[Kendidi]

After I run "make linux" at "/esp/socs/xilinx-vcu128-xcvu37p/", I see there is a bbl built in "/esp/socs/xilinx-vcu128-xcvu37p/pk-build/". I wonder does it contain everything needed to boot Linux including the Kernel and the root filesystem? If yes, then in theory, if bbl is copied to address 0x80000000, can it be executed from there and boot to Linux?

[davide-giri]

You should create the folder socs/<fpga-board>/vivado/esp-<fpga-board>.runs/impl_1/. That's where the top.bit bitstream would be if you were running Vivado instead of using the prebuilt bitstream.

Yes, you can load the bitstream manually, but it's probably faster if you use the instructions in the "FPGA programming" section of the guide to do it from the command line.

As I was saying above, there is not runme.sh script in this case, you don't need to use one. That's something we provide only for the tutorials with accelerators, not for the single-core SoC.

If you use the pre-built material you don't need to run make linux. In any case, the files to be copied on the FPGA are linux.bin and prom.bin and that is done automatically by make fpga-run-linux as per the instructions in the "Testing on FPGA" section of the guide.

[Kendidi]

@davide-giri

OK. Got it. Thank you!

Out of curiosity, does bbl built in "/esp/socs/xilinx-vcu128-xcvu37p/pk-build/" contain everything needed to boot Linux including the Kernel and the root filesystem? Thanks.

[jctullos]

@davide-giri

FYI, I have output from Linux again with PMP on Ariane. I had Master pulled yesterday and I believe there are some issues still. I went to commit: 3663eeb, which is right before the configurable XLEN commit.

For Linux, here are the configs and cmdline I had to add:

CONFIG_HVC_DRIVER=y CONFIG_SERIAL_EARLYCON_RISCV_SBI=y CONFIG_CMDLINE="earlyprintk console=hvc earlycon=sbi"

[paulmnt]

@davide-giri

OK. Got it. Thank you!

Out of curiosity, does bbl built in "/esp/socs/xilinx-vcu128-xcvu37p/pk-build/" contain everything needed to boot Linux including the Kernel and the root filesystem? Thanks.

Yes, everything is packaged there. Then from bbl we make an object copy into plain binary: Linux.bin, which is the file we transfer via Ethernet to memory.

[paulmnt]

@davide-giri

FYI, I have output from Linux again with PMP on Ariane. I had Master pulled yesterday and I believe there are some issues still. I went to commit: 3663eeb, which is right before the configurable XLEN commit.

For Linux, here are the configs and cmdline I had to add:

CONFIG_HVC_DRIVER=y

CONFIG_SERIAL_EARLYCON_RISCV_SBI=y

CONFIG_CMDLINE="earlyprintk console=hvc earlycon=sbi"

Thank you for sharing this information. We will investigate and try to understand if some of the recent changes are causing a bug that is exposed when updating Ariane.

[jctullos]

I'm also stuck again at the end of Linux boot. I reach to here:

I've updated the sysroot with the script and recompiled, but just can't seem to get anywhere on this.

So at least some progress. On another Linux build, I was able to get it to:

But stuck again.

[jctullos]

So going back to the ESP build, with PMP, it looks like there's some issue with RCU preempt and/or the PLIC driver (possibly due to using PMP and Supervisor mode). I finally found out why it was hanging at key_dns_resolver. This was the stacktrace after removing PLIC driver/DTS entry:

So once it reaches Run /init as init process, it hangs. I've found that if I start pressing buttons, it causes a buffer overflow and shows the panic. This makes sense, because the uart uses the interrupts for the uart. Still not sure why it isn't going to the buildroot/busybox init.

[paulmnt]

Hi @jctullos

Let me address your latest message first: the RCU stall is a known issue, which occurs every now and then at the end of Linux boot. We have not yet figured whether there is something in the boot loader code, or if this is a consequence of distributing interrupts with a slightly larger delay. That is inevitable when replacing the bus with a network-on-chip. In any case, the RCU stall only occurs occasionally, so if you see this error message every time you boot, then something else is broken.

The other two screenshots you posted, where boot is stuck, instead, do not occur for us at the head of master and not even at the head of dev-ariane-smp with caches enabled. I can try building a bitstream with Ariane at 3663eeb. In general, there might be buffer overflow issues and deadlock problems if you grow too much your sysroot: https://patchwork.kernel.org/patch/10802431/. The solution to this is to replace bbl with OpenSBI as boot loader. We plan to do this as well and as a reminder that this is urgent, I just opened this issue #64 .

I will let you know once I have the bitstream ready.

[jctullos]

Hey @paulmnt

So for the boot stuck, it's due to enabling PMP on the ariane core. It doesn't happen for the normal ESP build. It's when I bump Ariane to master to enable PMP. I believe there is a permissions issue with PMP, when Linux reaches the end of boot to execute the init script/initramfs, it can't execute it. I've tried it with a very minimal sysroot that I've used on 2 other processors for successful PMP/Linux builds, and it's failing at the same area.

Some additional info: I found online that a debug tip for Init was to build a simple HelloWorld executable, and have that called from the Init script. Using it, it still didn't execute the HelloWorld file.

Unfortunately, I can't move to OpenSBI, I'm evaluating Keystone (a security monitor) and it uses the BBL.

[paulmnt]

@jctullos I was able to reproduce the same kernel panic after bumping Ariane.

I am going to try on a stable branch, without caches and see if Linux boots that way. If your guess about permission is correct, then it will probably not boot anyway.

There are a few things to try:

• Upgrading bbl. PMP is using new CSRs and I guess that the boot loader should be aware of them.
• Upgrading Linux. Similarly, some arch/riscv routines may require knowing about PMP
• Propagate more information from AXI PROT/CACHE/ATOP fields? If PMP is causing a permission exception, then we may need to propagate additional information from the AXI transactions into the memory hierarchy the first time a particular address is accessed. Then, use that information when the same address is accessed a second time.

Upgrading bbl and Linux could be annoying, but fairly easy. Modifying the entire memory hierarchy requires a bit more work, but it could lead to very interesting research on security.

[jctullos]

Hm.. Glad you were able to reproduce the issue. I'll be interested if you succeed or not without caches.

I'm currently upgraded Linux to a 5.5 to see if there are bugs ironed out. I've already tried 5.3 with the minimal filesystem that always works on 2 other processors with PMP. So I don't have a lot of confidence in bumping it, but it's an easy check. For BBL, I've used both ESP and the other one that comes with the 5.3 Linux for the security monitor. The security monitor/5.3 build should work with the PMP on Ariane. I've looked at the CSR file and there's no differences between the registers. But I didn't look at it extremely close and would be worth going over again.

Thanks again for all your help.

Edit: I can verify that bumping Linux to 5.5 doesn't fix it. Still hangs at Run /init.

[paulmnt]

I'm happy to see that upgrading Linux though isn't causing major troubles.

Edit: caches are not the issue: I get the same kernel panic on master when Ariane has PMP enabled.

When you mention 2 other processors, do you mean 2 other SoCs with Ariane + PMP, or systems that do not integrate Ariane? I just wanted to know if we should look for this bug at the interface between ESP and Ariane, or if it is internal to Ariane itself.

[jctullos]

I'm not sure if it's internal to Ariane itself or to ESP. For the 2 other SoCs, I meant completely different RISCV processors that use PMP.

I had tried getting the OpenPiton build working on the VCU118, but couldn't get even their base VCU118 working (without PMP). So it's hard to tell if this is an ESP issue or Ariane.

One thing I will try out later today, I have a VC707 FPGA, I might try to build from the Ariane github and see if it boots with PMP.

[paulmnt]

One thing I will try out later today, I have a VC707 FPGA, I might try to build from the Ariane github and see if it boots with PMP.

I think this is the best thing to do first: if the SoC provided with Ariane shows the same issue, then it's probably internal to Ariane. If not, we can start looking into the AXI interface and see if we need to add information or fix a bug to support PMP.

Edit: In case the build from Ariane's repo does work, a test using the BBL image from ESP might be helpful to understand: some configuration on our end for Linux could be the problem as well.

[Kendidi]

@paulmnt

Yes, everything is packaged there. Then from bbl we make an object copy into plain binary: Linux.bin, which is the file we transfer via Ethernet to memory.

Got it. Thank you very much for your confirmation!

[paulmnt]

One thing I will try out later today, I have a VC707 FPGA, I might try to build from the Ariane github and see if it boots with PMP.

If you have the VC707, as long as you build small ESP instances, that's a great target to use for ESP as well, because synthesis time is significantly shorter than VCU118, but the clock period won't get past 62 MHz with Ariane and we set the default to 50 MHz.

[Kendidi]

@paulmnt and @davide-giri

I have copied the pre-built files to the appropriate (I think) locations:

/home/aie/esp/socs/xilinx-vcu128-xcvu37p/vivado/esp-xilinx-vcu128-xcvu37p.runs/impl_1/top.bit
/home/aie/esp/socs/xilinx-vcu128-xcvu37p/linux.bin

Environment variable set:

XILINX_VIVADO=/home/aie/xilinx/tools/Xilinx/Vivado_Lab/2019.2/

I connected Xilinx VCU128 FPGA and my system (192.168.1.1) to the same router.

Then I tried to FPGA test but got the following failure message.

kendidi@Machine:~/esp/socs/xilinx-vcu128-xcvu37p$ make fpga-run-linux
    CC esplink
    INFO generating programming script for xcvu37p
    /bin/sh: 4: vivado: not found
    INFO Waiting for DDR calibration...
    BUILD ariane.dtb
    CC startup.o
    CC uart.o
    CC main.o
    CC prom.exe
    OBJCP prom.srec
    CC systest.exe
    OBJCP ram.srec
    OBJCP prom.bin
    OBJCP systest.bin
ESPLink address 192.168.1.12:46392

Am I missing any steps? What "vivado" is it looking for? Please advise. Many thanks in advance!

[davide-giri]

@Kendidi you should copy all 4 prebuilt files, especially prom.bin because it's needed for booting Linux. You may want to make distclean and then copy the 4 files over again.

In the How to: setup guide you can see how to add Vivado to the environment. I'm pasting here the relevant part:

# Xilinx: Vivado, Vivado HLS
  # e.g. <vivado_path> = /opt/xilinx/Vivado/2018.2
  export XILINXD_LICENSE_FILE=<xilinx_license_path>
  export VIVADO=<vivado_path>
  source $VIVADO/settings64.sh

You may not need to export the license file in this case, but you definitely need the source step.

[Kendidi]

@davide-giri

Thanks for the info!

I ran "make distclean", copied the 4 pre-built files, set environment variables so follows, setup network and tried to run test with FPGA again.

export XILINXD_LICENSE_FILE=/home/aie/xilinx/Xilinx.lic
export VIVADO=/home/aie/xilinx/tools/Xilinx/Vivado_Lab/2019.2/
source $VIVADO/settings64.sh

It went further but still has issues.

aie@Machine:~/esp/20200923/esp/socs/xilinx-vcu128-xcvu37p$ make fpga-run-linux
    CP .esp_config
    CP .grlib_config
    CC tkparse.o
    CC tkcond.o
    CC tkgen.o
    LINK tkparse
    BUILD main.tk
    BUILD lconfig.tk
    CHMOD lconfig.tk
    DIFF checking .grlib_config...
    INFO Using default configuration file for GRLIB
    RUN grlib_config.vhd
    INFO Creating grlib_config.vhd
    INFO grlib_config.vhd written
    DIFF checking .esp_config...
    INFO Using default configuration file for ESP

Generating ESP configuration...
Created global constants definition into 'esp_global.vhd'
Created configuration into 'socmap.vhd'
Created ESPLink header into 'socmap.h'
Created device-tree into 'ariane.dts'
Created RTL caches configuration into 'cache_cfg.svh'
Created kernel module load script into 'S64esp'
Created configuration into 'power.h'
Created configuration into 'mmi64_regs.h'
    CC esplink
    INFO generating programming script for xcvu37p
/bin/sh: 4: vivado: not found
    INFO Waiting for DDR calibration...
    BUILD ariane.dtb
    CC startup.o
    CC uart.o
    CC main.o
    CC prom.exe
    OBJCP prom.srec
    CC systest.exe
    OBJCP ram.srec
    OBJCP prom.bin
    OBJCP systest.bin
ESPLink address 192.168.1.12:46392
sendto(): Network is unreachable
/home/aie/esp/20200923/esp/utils/Makefile:1705: recipe for target 'fpga-run-linux' failed
make: *** [fpga-run-linux] Error 1

I think the bit file wasn't loaded therefore 192.168.1.12 cannot be reached.

[jctullos]

@paulmnt

Alright, so an update after building for the VC707:

I'm able to boot a working PMP build on it. So the issue might be in something with the VCU118 and ESP/Open Piton builds. I used the ariane SDK build (which also uses Linux 5.1). The Ariane commit I checked out for a working build that successfully uses initramfs: https://github.com/openhwgroup/cva6/commit/eef5ff6d3a8fe28213b283085740524b41b22002

When I took that same build, added the apbuart to riscv-pk (with no additional changes to their Linux/Buildroot/Busybox config), and boot it with the ESP VCU118, I reach the same area as previously. Stuck at Run /init as init process. So that tells me there's nothing wrong with your Linux/Buildroot/Busybox config, but it's hardware related with an ESP build.

The changes I did make to the Ariane SDK linux_defconfig are:

CONFIG_DEFAULT_HOSTNAME="ariane-fpga"

CONFIG_CROSS_MEMORY_ATTACH is not set

CONFIG_NAMESPACES=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="${BR_BINARIES_DIR}/rootfs.cpio" CONFIG_EMBEDDED=y CONFIG_SMP=y CONFIG_HZ_100=y CONFIG_CMDLINE="earlyprintk console=hvc earlycon=sbi" CONFIG_MODULES=y

CONFIG_BLK_DEV_BSG is not set

CONFIG_PARTITION_ADVANCED=y

CONFIG_COMPACTION is not set

CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_TLS=y CONFIG_INET=y CONFIG_IP_MULTICAST=y

CONFIG_WIRELESS is not set

CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_VIRTIO_BLK=y CONFIG_EEPROM_AT24=y CONFIG_NETDEVICES=y CONFIG_VXLAN=y

CONFIG_LOWRISC_DIGILENT_100MHZ=y

CONFIG_XILINX_EMACLITE=y

CONFIG_MDIO_BCM_UNIMAC=y

CONFIG_MDIO_BITBANG=y

CONFIG_MDIO_BUS_MUX_GPIO=y

CONFIG_MDIO_BUS_MUX_MMIOREG=y

CONFIG_MDIO_BUS_MUX_MULTIPLEXER=y

CONFIG_MDIO_GPIO=y

CONFIG_REALTEK_PHY=y

CONFIG_WLAN is not set

CONFIG_INPUT_KEYBOARD is not set

CONFIG_INPUT_MOUSE is not set

CONFIG_VT is not set

CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_OF_PLATFORM=y CONFIG_SERIAL_UARTLITE=y CONFIG_HVC_RISCV_SBI=y CONFIG_VIRTIO_CONSOLE=y

CONFIG_HW_RANDOM is not set

CONFIG_I2C=y CONFIG_I2C_OCORES=y

CONFIG_SPI=y

CONFIG_SPI_XILINX=y

CONFIG_GPIOLIB=y CONFIG_GPIO_SYSFS=y CONFIG_GPIO_XILINX=y CONFIG_POWER_RESET=y CONFIG_POWER_RESET_GPIO_RESTART=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_EHCI_HCD=y

CONFIG_MMC=y

CONFIG_MMC_SPI=y

CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y CONFIG_LEDS_PWM=y CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_HEARTBEAT=y CONFIG_LEDS_TRIGGER_PANIC=y CONFIG_VIRTIO_MMIO=y

CONFIG_IOMMU_SUPPORT is not set

CONFIG_PWM=y CONFIG_SIFIVE_PLIC=y CONFIG_EXT3_FS=y

CONFIG_PROC_PAGE_MONITOR is not set

CONFIG_TMPFS=y

CONFIG_MISC_FILESYSTEMS is not set

CONFIG_NFS_FS=y CONFIG_NFS_V4=y CONFIG_NFS_SWAP=y CONFIG_NFS_V4_1=y CONFIG_NFS_V4_2=y CONFIG_CRYPTO_ECHAINIV=y

CONFIG_CRYPTO_HW is not set

CONFIG_PRINTK_TIME=y CONFIG_STRIP_ASM_SYMS=y CONFIG_DEBUG_SECTION_MISMATCH=y CONFIG_STACKTRACE=y

So all I did was remove the ethernet items they have listed as it causes a stuck boot on the VC707.