riscv_soc_tb Simulaton

[Youssef-IA]

Hi, Thanks for your efforts.

I wanted to run a simulation as mentioned in http://sergeykhbr.github.io/riscv_vhdl/verification_page.html#sim_tb_link and unable to find the mentioned testbench file or a document that explains the expected behavior.

On the other hand, I tried to run through the following path iscv_vhdl/vhdl/rtl/prj/sim, after creating a questasim makefile the mimics the committed xilinx makefile. But, I do not understand what is the expected behavior while moving from a JTAG test to another, is that documented anywhere? Also I noticed that both Ethernet & UART enables are instantiated with 0, is that intended?

That's the waveform output

[sergeykhbr]

Hi, I didn't update documentation quite a long period of time. It contains a lot of obsolete information, sorry for that. Here're the list of possible simulation configurations:

1. ASIC unisim simulation (most generic and full simulation) using ncsim:

   cd riscv_vhdl\sv\prj\impl\asic_sim
   make build
   make gui

2. KC705 simulation (it requires library with the Secure IP components (SIP-components) to simulate DDR controller using ncsim. I think it is possible to simulate this FPGA project entirely in Vivado.

   cd riscv_vhdl\sv\prj\impl\kc705_sim
   make build
   make gui

3. Build KC705 bitstream file:

   cd riscv_vhdl\sv\prj\impl\kc705
   make

4. Simulate SystemC precise model:

   - Download and build systemc library
   - Specify env, variables SYSTEMC_LIB and SYSTEMC_SRC accordingly with the build folder
   - Use CMake for \riscv_vhdl\debugger\cmake to generate project (I am suing Visual Studio)
   - Build project and run configuration from cmake bin output directory:
       riscvdebugger.exe -c riscv_vhdl/debugger/targets/sysc_river_x1_gui.json

5. openocd + gdb could be used with the RTL simulation and SystemC to verify and debug simulation as a real hardware.

[Youssef-IA]

Hi again, Thanks for your response.

For asic_sim, I am unable to use ncsim currently, but Simulation started successfully using questasim showing the green terminal of the uart output .. but nothing is printed. Is there any configuration that needs to be added or maybe tool issue and I need to install ncsim?

If I want to try helloworld example, should I add the generated .hex file somewhere? I tried to load it into rtl/techmap/mem/rom_inferred_32.sv & rtl/techmap/mem/rom_inferred_2x32.sv modules but nothing happened.

If that is documented anywhere just please refer to it and i will check.

[sergeykhbr]

There's no need to change configuration or hex-files to run simulation. As an example I've just run clean repository _asicsim simulation with the following result:

Time diagram above shows the following signals:

• Boot ROM values to check that HEX-files were read successfully: -- asic_top_tb.tt.soc0.boot0.o.r_valid -- asic_top_tb.tt.soc0.boot0.o.r_data
• UART td with 115200: -- asic_top_tb.tt.soc0.uart1.o_td
• Core[0] executed instructions: -- asic_top_tb.tt.soc0.group0.xslotcpu[0].cpux.river0.proc0.exec0.o_valid -- asic_top_tb.tt.soc0.group0.xslotcpu[0].cpux.river0.proc0.exec0.o_pc[63:0]

You can use the same signals to check your simulation. UART VIP decodes the td signal and writes accumulated bytes into file uart_0.log (it should be created in your questasim project). Console just read and show content of this file.

[Youssef-IA]

Thanks for your help, It is highly appreciated. I started the simulation successfully, but it is not the same as yours. It stops at 414.8875 us and o_pc = 00...0100b8

I'll be debugging the issue, is there anything that you could provide to help? where to start from? Also I think that If I need to change the scenarios, I need to add the hex file to the boot ROM memory, right? (e.g.: hello_world.hex)

[sergeykhbr]

1. I see that CPU starts working as expected but failing on the first FPU instruction:

   100b8:  f2000053            fmv.d.x ft0,zero
   fmv.d.x f1, x0

   Did you change configuration parameter CFG_HW_FPU_ENABLE? It is enabled by default and I actually didn't try to disable it. Could you check that inside of execute module is properly instantiated module fpu0 (FpuTop)?

2. Hello world example is quite obsolete example and to run it properly it should be build with some startup file that initialize CPU registers and others peripheries. Example of such startup.S file you can find in the folder examples/common/system/startup.S. Basically, hello world requires some makefile and source code modifications to start it properly. To generate hex-files I use utility examples/elf2rawx. Take into account that the latest RTL simulation instantiates 2 ROM blocks and it requires 2 hex files with the suffixes _hi.hex and _lo.hex. Parameter CFG_BOOTROM_FILE specifies only one file but these suffixes will be added in the file "rom_inferred_2x32.sv".

Generate 1 hex- file:

elf2rawx example.elf -h -f 65536 -l 8 -o example.hex

Generate 2 hex- files:

elf2rawx example.elf -h -f 65536 -l 8 -o example_hi.hex -o example_lo.hex

[Youssef-IA]

Hi, Thanks a lot for the detailed reply, that's really appreciated.

I started debugging the fpu module as you mentioned, CFG_HW_FPU_ENABLE=1 & the module is properly instaniated. So I started checking the internal signals, FPU inputs mainly. I found that fpu0.i_en=1 just 1 clock cycle before the mentioned fpu instruction (100b8), then goes down. Also both of the inputs (fpu0.i_a & fpu0.i_b) are stuck to 0 jsut before that command (100b8). is that expected? and what is the previous command (100b4) stands for?

Is there a document or another program explaining what is expected from the simulation so that I can debug more?

[sergeykhbr]

Hi, let's start it working with Questa.

• If you compile _bootromtests example you will get listing file (bootrom_test.lst) with the disassembled code. I think it's better than documentation (see link below).

  # intialization when HW FPU enabled
  #ifdef FPU_ENABLED
  fssr    x0
  100b4:   00301073            fssr    zero
  fmv.d.x f0, x0
  100b8:   f2000053            fmv.d.x ft0,zero
  fmv.d.x f1, x0
  100bc:   f20000d3            fmv.d.x ft1,zero
  fmv.d.x f2, x0

• Instruction 100b4 is also FPU instruction or more precisely it is a privileged instruction to write into CSR (Control Status Register) which is available for the disabled and enabled FPU. Your simulation looks good for me at this point.

• I've prepared VCD file (o_river.vcd) generated by SystemC model that I use as a reference in a case of problems (as shown on picture above). It should help you to identify the difference with RTL. See the link https://github.com/sergeykhbr/riscv_vhdl/tree/tmpstorage/files

[Youssef-IA]

Hi , thanks a lot for your help The simulation now resumes bs it hangs like this, with no output in the UART, o_pc = 10e18 10e18: 0000100f fence.i

just to confirm, you are using examples/bootrom_tests/linuxbuild/bin/bootrom_tests.hex file, right?

[sergeykhbr]

Hi, could you simulate a bit longer? Fence.I is a quite time consuming operation. We have a bit different gcc version and as a result build files, but I suppose this Fence_I is from 'exception_handler_c' method and it means that something executed in a wrong way. Could you provide more info what happened before pc jumps into exception?

[Youssef-IA]

Hi, I simulated longer time (2ms) but the screenshot is just cropped, it later jumps to this command and keeps repeating 10e1c: 0001f7b7 lui a5,0x1f

The last commands before the exception are (in order before the exception) 19c98: fcf42823 sw a5,-48(s0) 11a34: fe010113 addi sp,sp,-32 11a38: 00813c23 sd s0,24(sp)
11a3c: 02010413 addi s0,sp,32 malloc_type pool = (malloc_type )ADDR_BUS0_XSLV_SRAM; 11a40: 080007b7 lui a5,0x8000 11a44: fef43423 sd a5,-24(s0) pnp_map pnp = (pnp_map )ADDR_BUS0_XSLV_PNP; 11a48: 100ff7b7 lui a5,0x100ff 11a4c: fef43023 sd a5,-32(s0) // 8-bytes alignment pool->allocated_sz = (sizeof(malloc_type) + 7) & ~0x7ull; 11a50: fe843783 ld a5,-24(s0) 11a54: 00001737 lui a4,0x1 11a58: 81870713 addi a4,a4,-2024 # 818 <_ftext-0xf7e8> 11a5c: 00e7b423 sd a4,8(a5)

_traptable: 10004: 7500006f j 10754

_trapentry: 10754: 340f1073 csrw mscratch,t5 10758: 34202f73 csrr t5,mcause 1075c: 100f5c63 bgez t5,10874 10874: 00123023 sd ra,0(tp) # 0 <_ftext-0x10000> ..... the above commands were repeated multiple times ....

_handleexception: ..... multiple commands from handle_exception function .....: 108e8: 0e323823 sd gp,240(tp) 108ec: 51c000ef jal ra,10e08

_void exception_handlerc() { 10e08: fe010113 addi sp,sp,-32 10e0c: 00113c23 sd ra,24(sp) 10e10: 00813823 sd s0,16(sp) 10e14: 02010413 addi s0,sp,32 10e18: 0000100f fence.i <<<<<< The hanging command

[sergeykhbr]

It looks like exception occurs on write access into the pnp module register. I suppose that pnp (or the whole apb-bridge "bus1") weren't properly instantiated and connected. It should be quite easy to track error on apb-bridge in/outs.

[Youssef-IA]

Thanks for you response. I will debug it.

I was checking the new commits and I found that you updated the helloworld example after our earlier conversation, so in asic_sim_pkg.sv, I changed: localparam CFG_BOOTROM_FILE_HEX = "../../../../examples/helloworld/makefiles/bin/helloworld";

And Ran the simulation again, It hangs at o_pc = 100c0, which is a very simple ori command

And the UART prints this unkown character

Do you have any idea what is the issue? Did I miss something while updating CFG_BOOTROM_FILE_HEX?

[sergeykhbr]

It looks like simulation reads xxxx from address 0x1b8c8 that stucks the simulator when it tries to OR the results. Or less probable, this address is not responding.

Main idea here is to initialize mtvec CSR register and enable vector mode (bit[1:0] = 0.1). I recommend to run bootrom_tests firsts successfully before changing any parameters.

[Youssef-IA]

Thanks a lot for your help, the design is running now. But I am not sure if it's running as expected, can you please provide the expected UART output ?

It's hanging at the following output for a while now:

DDR. . . . . . .PASS

Copy BBL . . . .mcause:0000000000000006,mepc:0000000000018290

it that expected?

[sergeykhbr]

Hi, happy to hear that. Here's one of the latest output (sd-card disconnected):

sdtype: unknown
HARTID . . . . .0
HARTS. . . . . .1
PLIC_IRQS  . . .73
HWID . . . . . .0x20220903
FWID . . . . . .0x20220116
PLIC . . . . . .PASS
MTIMER . . . . .PASS
SWIRQ. . . . . .PASS
L2.Coherence . .Disabled
PMP. . . . . . .PASS
MMU.MPRV . . . .PASS
HW_FPU . . . . .testing
Testing FADD
Testing FMUL
Testing DCVT_D_W
Testing DCVT_D_WU
Testing DCVT_W_D
Testing DCVT_WU_D
FPU errors . . .0
instr_load_err .PASS
rd_missaccess. .PASS
wr_missaccess. .PASS
stack_ovr. . . .PASS
stack_und. . . .PASS

# Plug'n'Play info:
# AXI4: slv0: Optimizing Technologies.    AXI Interconnect
#    0000000000000000...ffffffffffffffff, size = 0 bytes
# AXI4: mst1: Optimizing Technologies.    RISC-V River x4 Workgroup
# AXI4: slv2: Optimizing Technologies.    Boot ROM
#    0000000000010000...000000000001ffff, size = 64 KB
# AXI4: slv3: Optimizing Technologies.    Internal SRAM
#    0000000008000000...00000000081fffff, size = 2 MB
# AXI4: slv4: Optimizing Technologies.    Internal SRAM
#    0000000080000000...00000000bfffffff, size = 1024 MB
# AXI4: slv5: Optimizing Technologies.    DDR Controller
#    00000000100c0000...00000000100c0fff, size = 4 KB
# AXI4: slv6: Optimizing Technologies.    PRCI
#    0000000000000000...ffffffffffffffff, size = 0 bytes
# AXI4: slv7: Optimizing Technologies.    Generic GPIO
#    0000000010060000...0000000010060fff, size = 4 KB
# AXI4: slv8: Optimizing Technologies.    CLINT
#    0000000002000000...000000000200ffff, size = 64 KB
# AXI4: slv9: Optimizing Technologies.    PLIC
#    000000000c000000...000000000fffffff, size = 64 MB
# AXI4: slv10: Optimizing Technologies.    Plug'n'Play support
#    00000000100ff000...00000000100fffff, size = 4 KB
# AXI4: slv11: Optimizing Technologies.    AXI2APB Bridge
#    0000000010000000...00000000100fffff, size = 1 MB
# AXI4: slv12: Optimizing Technologies.    Workgroup DMI
#    000000001001e000...000000001001efff, size = 4 KB
# AXI4: slv13: Optimizing Technologies.    Generic UART
#    0000000010010000...0000000010010fff, size = 4 KB
# AXI4: slv14: Optimizing Technologies.    SPI Controller
#    0000000010050000...0000000010050fff, size = 4 KB
# AXI4: slv15: Optimizing Technologies.    Unknown
#    0000000800000000...0000000fffffffff, size = 0 bytes
DDR Init . .DONE
DDR[0] . . . . .0x1122334455667788 expected 0x1122334455667788ull
DDR[1] . . . . .0xffeeddccbbaa9988 expected 0xffeeddccbbaa9988ull
DDR[9MB] . . . .0xcafef00ddead0901 expected 0xcafef00ddead0901ull
DDR. . . . . . .PASS
Copy BBL . . . .mcause:0000000000000006,mepc:0000000000018290

• Hardware SD controller development is in progress so you should see this exception. When I've used software to generate SPI commands for SD-card there was a chance to get the following output (after DDR test):

DDR Init . .DONE
DDR[0] . . . . .0x1122334455667788 expected 0x1122334455667788ull
DDR[1] . . . . .0xffeeddccbbaa9988 expected 0xffeeddccbbaa9988ull
DDR[9MB] . . . .0xcafef00ddead0901 expected 0xcafef00ddead0901ull
DDR. . . . . . .PASS
DUM: ff ff ff ff ff ff ff ff ff ff 
CMD0: ff ff ff ff ff ff ff R1: 01
CMD8: ff ff ff ff ff ff ff R1: 01
CMD58: 00 00 00 00 ff ff ff R3: 01 00ff8000
CMD55: ff ff ff ff ff ff ff R1: 01
ACMD41: ff ff ff ff ff ff ff R1: 01
CMD55: ff ff ff ff ff ff ff R1: 01
ACMD41: ff ff ff ff ff ff ff R1: 01
CMD55: ff ff ff ff ff ff ff R1: 00
ACMD41: ff ff ff ff ff ff ff R1: 00
CMD58: ff ff ff ff ff ff ff R3: 00 c0ff8000 HCS=1
SPI.Init . . . .SDHC
Copy BBL . . . .10485760 B copied
bbl loader
              vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
                  vvvvvvvvvvvvvvvvvvvvvvvvvvvv
rrrrrrrrrrrrr       vvvvvvvvvvvvvvvvvvvvvvvvvv
rrrrrrrrrrrrrrrr      vvvvvvvvvvvvvvvvvvvvvvvv
rrrrrrrrrrrrrrrrrr    vvvvvvvvvvvvvvvvvvvvvvvv
rrrrrrrrrrrrrrrrrr    vvvvvvvvvvvvvvvvvvvvvvvv
rrrrrrrrrrrrrrrrrr    vvvvvvvvvvvvvvvvvvvvvvvv
rrrrrrrrrrrrrrrr      vvvvvvvvvvvvvvvvvvvvvv  
rrrrrrrrrrrrr       vvvvvvvvvvvvvvvvvvvvvv    
rr                vvvvvvvvvvvvvvvvvvvvvv      
rr            vvvvvvvvvvvvvvvvvvvvvvvv      rr
rrrr      vvvvvvvvvvvvvvvvvvvvvvvvvv      rrrr
rrrrrr      vvvvvvvvvvvvvvvvvvvvvv      rrrrrr
rrrrrrrr      vvvvvvvvvvvvvvvvvv      rrrrrrrr
rrrrrrrrrr      vvvvvvvvvvvvvv      rrrrrrrrrr
rrrrrrrrrrrr      vvvvvvvvvv      rrrrrrrrrrrr
rrrrrrrrrrrrrr      vvvvvv      rrrrrrrrrrrrrr
rrrrrrrrrrrrrrrr      vv      rrrrrrrrrrrrrrrr
rrrrrrrrrrrrrrrrrr          rrrrrrrrrrrrrrrrrr
rrrrrrrrrrrrrrrrrrrr      rrrrrrrrrrrrrrrrrrrr
rrrrrrrrrrrrrrrrrrrrrr  rrrrrrrrrrrrrrrrrrrrrr

       INSTRUCTION SETS WANT TO BE FREE
 {
  #address-cells = <0x00000002>;
  #size-cells = <0x00000002>;
  compatible = "riscv-virtio";
  model = "riscv-virtio,qemu";
  flash@20000000 {
    bank-width = <0x00000004>;
    reg = <0x00000000 0x20000000 0x00000000 0x02000000 0x00000000 0x22000000 0x00000000 0x02000000>;
    compatible = "cfi-flash";
  }
  chosen {
    bootargs = <0x6561726c 0x79707269 0x6e746b3d 0x6b656570 0x20727720 0x726f6f74 0x3d2f6465 0x762f7664>;
    stdout-path = <0x2f756172 0x74403130 0x30313030>;
  }
  uart@10010000 {
    interrupts = <0x0000000a>;
    interrupt-parent = <0x00000003>;
    clock-frequency = <0x00384000>;
    reg = <0x00000000 0x10010000 0x00000000 0x00000100>;
    compatible = "sifive,uart0";
  }
  test@100000 {
    reg = <0x00000000 0x00100000 0x00000000 0x00001000>;
    compatible = "sifive,test1", "sifive,test0";
  }
  virtio_mmio@10008000 {
    interrupts = <0x00000008>;
    interrupt-parent = <0x00000003>;
    reg = <0x00000000 0x10008000 0x00000000 0x00001000>;
    compatible = "virtio,mmio";
  }
  virtio_mmio@10007000 {
    interrupts = <0x00000007>;
    interrupt-parent = <0x00000003>;
    reg = <0x00000000 0x10007000 0x00000000 0x00001000>;
    compatible = "virtio,mmio";
  }
  virtio_mmio@10006000 {
    interrupts = <0x00000006>;
    interrupt-parent = <0x00000003>;
    reg = <0x00000000 0x10006000 0x00000000 0x00001000>;
    compatible = "virtio,mmio";
  }
  virtio_mmio@10005000 {
    interrupts = <0x00000005>;
    interrupt-parent = <0x00000003>;
    reg = <0x00000000 0x10005000 0x00000000 0x00001000>;
    compatible = "virtio,mmio";
  }
  virtio_mmio@10004000 {
    interrupts = <0x00000004>;
    interrupt-parent = <0x00000003>;
    reg = <0x00000000 0x10004000 0x00000000 0x00001000>;
    compatible = "virtio,mmio";
  }
  virtio_mmio@10003000 {
    interrupts = <0x00000003>;
    interrupt-parent = <0x00000003>;
    reg = <0x00000000 0x10003000 0x00000000 0x00001000>;
    compatible = "virtio,mmio";
  }
  virtio_mmio@10002000 {
    interrupts = <0x00000002>;
    interrupt-parent = <0x00000003>;
    reg = <0x00000000 0x10002000 0x00000000 0x00001000>;
    compatible = "virtio,mmio";
  }
  virtio_mmio@10001000 {
    interrupts = <0x00000001>;
    interrupt-parent = <0x00000003>;
    reg = <0x00000000 0x10001000 0x00000000 0x00001000>;
    compatible = "virtio,mmio";
  }
  cpus {
    #address-cells = <0x00000001>;
    #size-cells = <0x00000000>;
    timebase-frequency = <0x00989680>;
    cpu-map {
      cluster0 {
        core0 {
          cpu = <0x00000001>;
        }
      }
    }
    cpu@0 {
      phandle = <0x00000001>;
      device_type = "cpu";
      reg = <0x00000000>;
      status = "okay";
      compatible = "riscv";
      riscv,isa = "rv64imafdcsu";
      mmu-type = "riscv,sv48";
      interrupt-controller {
        #interrupt-cells = <0x00000001>;
        interrupt-controller;
        compatible = "riscv,cpu-intc";
        phandle = <0x00000002>;
      }
    }
  }
  memory@80000000 {
    device_type = "memory";
    reg = <0x00000000 0x80000000 0x00000000 0x20000000>;
  }
  soc {
    #address-cells = <0x00000002>;
    #size-cells = <0x00000002>;
    compatible = "simple-bus";
    ranges;
    pci@30000000 {
      interrupt-map-mask = <0x00001800 0x00000000 0x00000000 0x00000007>;
      interrupt-map = <0x00000000 0x00000000 0x00000000 0x00000001 0x00000003 0x00000020 0x00000000 0x00000000 0x00000000 0x00000002 0x00000003 0x00000021 0x00000000 0x00000000 0x00000000 0x00000003 0x00000003 0x00000022 0x00000000 0x00000000 0x00000000 0x00000004 0x00000003 0x00000023 0x00000800 0x00000000 0x00000000 0x00000001 0x00000003 0x00000021 0x00000800 0x00000000 0x00000000 0x00000002 0x00000003 0x00000022 0x00000800 0x00000000 0x00000000 0x00000003 0x00000003 0x00000023 0x00000800 0x00000000 0x00000000 0x00000004 0x00000003 0x00000020 0x00001000 0x00000000 0x00000000 0x00000001 0x00000003 0x00000022 0x00001000 0x00000000 0x00000000 0x00000002 0x00000003 0x00000023 0x00001000 0x00000000 0x00000000 0x00000003 0x00000003 0x00000020 0x00001000 0x00000000 0x00000000 0x00000004 0x00000003 0x00000021 0x00001800 0x00000000 0x00000000 0x00000001 0x00000003 0x00000023 0x00001800 0x00000000 0x00000000 0x00000002 0x00000003 0x00000020 0x00001800 0x00000000 0x00000000 0x00000003 0x00000003 0x00000021 0x00001800 0x00000000 0x00000000 0x00000004 0x00000003 0x00000022>;
      ranges = <0x01000000 0x00000000 0x00000000 0x00000000 0x03000000 0x00000000 0x00010000 0x02000000 0x00000000 0x40000000 0x00000000 0x40000000 0x00000000 0x40000000>;
      reg = <0x00000000 0x30000000 0x00000000 0x10000000>;
      dma-coherent;
      bus-range = <0x00000000 0x000000ff>;
      linux,pci-domain = <0x00000000>;
      device_type = "pci";
      compatible = "pci-host-ecam-generic";
      #size-cells = <0x00000002>;
      #interrupt-cells = <0x00000001>;
      #address-cells = <0x00000003>;
    }
    interrupt-controller@c000000 {
      phandle = <0x00000003>;
      riscv,ndev = <0x00000035>;
      reg = <0x00000000 0x0c000000 0x00000000 0x04000000>;
      interrupts-extended = <0x00000002 0xffffffff 0x00000002 0x00000009>;
      interrupt-controller;
      compatible = "riscv,plic0";
      #interrupt-cells = <0x00000001>;
      #address-cells = <0x00000000>;
    }
  }
}
[    0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
[    0.000000] No DTB passed to the kernel
[    0.000000] Linux version 5.0.0-rc1-56210-g0a657e0d72f0 (coder@coder-comp) (gcc version 11.1.0 (g5964b5cd727)) #11 SMP Mon Aug 22 11:09:54 MSK 2022
[    0.000000] Zone ranges:
[    0.000000]   DMA32    [mem 0x0000000080200000-0x000000009fffffff]
[    0.000000]   Normal   [mem 0x00000000a0000000-0x000009ffffffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000080200000-0x000000009fffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x000000009fffffff]
[    0.000000] software IO TLB: mapped [mem 0x9b8fc000-0x9f8fc000] (64MB)
[    0.000000] elf_hwcap is 0x112d
[    0.000000] percpu: Embedded 14 pages/cpu @(____ptrval____) s28568 r0 d28776 u57344
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 128775
[    0.000000] Kernel command line: earlyprintk=keep rw root=/dev/vda
[    0.000000] Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
[    0.000000] Sorting __ex_table...
[    0.000000] Memory: 442248K/522240K available (3962K kernel code, 248K rwdata, 887K rodata, 155K init, 789K bss, 79992K reserved, 0K cma-reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] rcu: Hierarchical RCU implementation.
[    0.000000] rcu:     RCU event tracing is enabled.
[    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
[    0.000000] NR_IRQS: 0, nr_irqs: 0, preallocated irqs: 0
[    0.000000] plic: mapped 53 interrupts to 1 (out of 2) handlers.
[    0.000000] clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x24e6a1710, max_idle_ns: 440795202120 ns
[    0.000653] sched_clock: 64 bits at 10MHz, resolution 100ns, wraps every 4398046511100ns
[    0.815190] printk: console [hvc0] enabled
[    0.834363] Calibrating delay loop (skipped), value calculated using timer frequency.. 20.00 BogoMIPS (lpj=100000)
[    0.878327] pid_max: default: 32768 minimum: 301
[    0.914269] Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)
[    0.939484] Mountpoint-cache hash table entries: 1024 (order: 1, 8192 bytes)
[    0.972428] Kernel panic - not syncing: Can't find rootfs type
[    0.994972] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.0.0-rc1-56210-g0a657e0d72f0 #11
[    1.029401] Call Trace:
[    1.040786] [<ffffffe000029012>] walk_stackframe+0x0/0xa6
[    1.064140] [<ffffffe00002930c>] show_stack+0x2a/0x34
[    1.086488] [<ffffffe0003ee358>] dump_stack+0x66/0x80
[    1.108435] [<ffffffe00002cc4e>] panic+0xdc/0x21a
[    1.128936] [<ffffffe000009f98>] mnt_init+0x11e/0x1a6
[    1.150950] [<ffffffe000009c80>] vfs_caches_init+0x64/0x74
[    1.174943] [<ffffffe000000980>] start_kernel+0x2b4/0x2e4
[    1.198504] [<ffffffe000000076>] clear_bss_done+0x3a/0x3c
[    1.222219] ---[ end Kernel panic - not syncing: Can't find rootfs type ]---

[Youssef-IA]

Got it, thanks a lot for your help!

Just one last question please, does any of the other tests provided in examples are fully developed yet? or just bootrom_tests & helloworld?

• "riscv_tests" & "dhrystone" are running but I can not figure what is the expected output?
• "boot" is showing spi.c compilation issue related to ADDR_BUS0_XSLV_QSPI2

[sergeykhbr]

I removed this QSPI controller because I hope to implement controller that can use SD-card in SD mode.

All examples were runnable some time ago but I broke it removing additional ROM block (fwimage) because of conceptual reason. Previous idea was to copy application (helloworld, riscv-tests, Drhystone or whatever) from this ROM into SRAM by bootloader and start execution from SRAM. Now it is impossible, SD-card or JTAG should be used for that.

I've committed update into boot example to skip coping procedure (ROM/SD->SRAM) so now there's possibility to initialize SRAM block and run application just after boot. It is valid for RTL simulation or FPGA to check examples but invalid for ASIC implementation.

SD-controller is the critical element right now to use system in a standard way without additional hacks and workarounds and store linux rootfs or user applications.

[Youssef-IA]

Thanks a lot for you help, great work! Looking forward for SD-controller implementation.