search

litex-hub / linux-on-litex-vexriscv

Linux on LiteX-VexRiscv
BSD 2-Clause "Simplified" License
572 stars 174 forks source link

Attempted to run pre-built images without veriscv sim, application hangs on liftoff #336

Closed OrkunAliOzkan closed 1 year ago

OrkunAliOzkan commented 1 year ago

Hello! I attempted to boot the prebuilt images without using the in-built simulator through using the following commands:

1.

litex_sim --with-ethernet --with-sdram --cpu-type vexriscv --no-compile-gateware --threads 8

2. Load images (Linux+openSBI) into repository

3.

litex_sim --with-ethernet --with-sdram --cpu-type vexriscv --sdram-init boot.json --threads 8

However I find that the application hangs on liftoff and I do not understand why.

Dolu1990 commented 1 year ago

Hi ^^ Shouldn't it be --cpu-type vexriscv_smp ?

OrkunAliOzkan commented 1 year ago

Hia! Wow, such a speedy response!

Sadly replacing the cpu type to vexriscv_smp does not resolve the issue, and I am not sure why. It remains hanging on liftoff.

My litex_sim file is stock, and I notice my ROM usage statistic while building is at least 20% lower than what sim.py displays (19% from the commands above compared to 37% from sim.py).

Edit Adding --rom-init to opensbi.bin causes program to fail at stage before displaying litex sim logo

OrkunAliOzkan commented 1 year ago

Hi! All I was missing was adding --cpu-version linux! I will keep you updated on whether it boots into busy-box!

Now for context, I am doing this because I am trying to build the equivalent Linux environment on a rocket cored SoC, and have been not getting much progress and I do not know why. Out of curiosity, would you mind please providing documentation here on how to create the dependencies for vexriscv which are provided in the Linux+OpenSBI zip file in https://github.com/litex-hub/linux-on-litex-vexriscv/issues/164? I have documented my process for building all dependencies needed to boot Linux on a rocket cored SoC in the following issues tab: https://github.com/enjoy-digital/litex/issues/1672, however I have been unsure if I have made a mistake or not.

Absolutely any help would be very much so appreciated!

Edit Program has been locked on [0.665970] io scheduler kyber registered

Dolu1990 commented 1 year ago

Hi,

I think most is here : https://github.com/litex-hub/linux-on-litex-vexriscv#-generating-the-linux-binaries-optional

Program has been locked on [0.665970] io scheduler kyber registered

What is your full consol logs ? In simulation, think can take ages, especialy as it "decompress" the cpio file

nothing after liftoff

Generaly, it could be because opensbi has a missconfigured UART address, or something in that kind. (as that can vary between SoC)

OrkunAliOzkan commented 1 year ago

1. Full console log down bellow:

[jtagremote] loaded (0x55755b9f8ef0)
[spdeeprom] loaded (addr = 0x0)
[serial2console] loaded (0x55755b9f8ef0)
[clocker] loaded
[ethernet] loaded (0x55755b9f8ef0)
[gmii_ethernet] loaded (0x55755b9f8ef0)
[serial2tcp] loaded (0x55755b9f8ef0)
[xgmii_ethernet] loaded (0x55755b9f8ef0)
[clocker] sys_clk: freq_hz=1000000, phase_deg=0

        __   _ __      _  __
       / /  (_) /____ | |/_/
      / /__/ / __/ -_)>  <
     /____/_/\__/\__/_/|_|
   Build your hardware, easily!

 (c) Copyright 2012-2023 Enjoy-Digital
 (c) Copyright 2007-2015 M-Labs

 BIOS built on Apr 25 2023 13:30:42
 BIOS CRC passed (5785a591)

 LiteX git sha1: 0c326f0e

--=============== SoC ==================--
CPU:        VexRiscv SMP-LINUX @ 1MHz
BUS:        WISHBONE 32-bit @ 4GiB
CSR:        32-bit data
ROM:        128.0KiB
SRAM:       8.0KiB
L2:     8.0KiB
SDRAM:      64.0MiB 32-bit @ 1MT/s (CL-2 CWL-2)
MAIN-RAM:   64.0MiB

--========== Initialization ============--
Initializing SDRAM @0x40000000...
Switching SDRAM to software control.
Switching SDRAM to hardware control.

--============== Boot ==================--
Booting from serial...
Press Q or ESC to abort boot completely.
sL5DdSMmkekro
Timeout
Executing booted program at 0x40f00000

--============= Liftoff! ===============--

OpenSBI v0.8-1-gecf7701
   ____                    _____ ____ _____
  / __ \                  / ____|  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |____) | |_) || |_
  \____/| .__/ \___|_| |_|_____/|____/_____|
        | |
        |_|

Platform Name       : LiteX / VexRiscv-SMP
Platform Features   : timer,mfdeleg
Platform HART Count : 8
Boot HART ID        : 0
Boot HART ISA       : rv32imas
BOOT HART Features  : time
BOOT HART PMP Count : 0
Firmware Base       : 0x40f00000
Firmware Size       : 124 KB
Runtime SBI Version : 0.2

MIDELEG : 0x00000222
MEDELEG : 0x0000b101
[    0.000000] Linux version 5.14.0 (florent@panda) (riscv32-buildroot-linux-gnu-gcc.br_real (Buildroot 2021.08-381-g279167ee8d) 10.3.0, GNU ld (GNU Binutils) 2.36.1) #1 SMP Tue Sep 21 12:57:31 CEST 2021
[    0.000000] earlycon: liteuart0 at I/O port 0x0 (options '')
[    0.000000] Malformed early option 'console'
[    0.000000] earlycon: liteuart0 at MMIO 0xf0001000 (options '')
[    0.000000] printk: bootconsole [liteuart0] enabled
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x0000000040000000-0x0000000043ffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000040000000-0x0000000043ffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x0000000043ffffff]
[    0.000000] SBI specification v0.2 detected
[    0.000000] SBI implementation ID=0x1 Version=0x8
[    0.000000] SBI TIME extension detected
[    0.000000] SBI IPI extension detected
[    0.000000] SBI RFENCE extension detected
[    0.000000] SBI v0.2 HSM extension detected
[    0.000000] riscv: ISA extensions aim
[    0.000000] riscv: ELF capabilities aim
[    0.000000] percpu: Embedded 8 pages/cpu s11340 r0 d21428 u32768
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 16256
[    0.000000] Kernel command line: console=liteuart earlycon=liteuart,0xf0001000 rootwait root=/dev/ram0
[    0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes, linear)
[    0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes, linear)
[    0.000000] Sorting __ex_table...
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] Memory: 48644K/65536K available (5685K kernel code, 572K rwdata, 883K rodata, 209K init, 221K bss, 16892K 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 restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
[    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[    0.000000] riscv-intc: 32 local interrupts mapped
[    0.000000] plic: interrupt-controller@f0c00000: mapped 32 interrupts with 1 handlers for 2 contexts.
[    0.000000] random: get_random_bytes called from start_kernel+0x4ac/0x63c with crng_init=0
[    0.000000] riscv_timer_init_dt: Registering clocksource cpuid [0] hartid [0]
[    0.000000] clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x171024e7e0, max_idle_ns: 440795205315 ns
[    0.000017] sched_clock: 64 bits at 100MHz, resolution 10ns, wraps every 4398046511100ns
[    0.002164] Console: colour dummy device 80x25
[    0.003097] Calibrating delay loop (skipped), value calculated using timer frequency.. 200.00 BogoMIPS (lpj=400000)
[    0.004634] pid_max: default: 32768 minimum: 301
[    0.008055] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.009092] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.029602] ASID allocator using 9 bits (512 entries)
[    0.032202] rcu: Hierarchical SRCU implementation.
[    0.037673] smp: Bringing up secondary CPUs ...
[    0.038235] smp: Brought up 1 node, 1 CPU
[    0.043649] devtmpfs: initialized
[    0.067172] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.068496] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.076186] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[    0.219383] pps_core: LinuxPPS API ver. 1 registered
[    0.219919] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.221340] PTP clock support registered
[    0.224504] FPGA manager framework
[    0.237894] clocksource: Switched to clocksource riscv_clocksource
[    0.388340] NET: Registered PF_INET protocol family
[    0.390469] IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear)
[    0.398017] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes, linear)
[    0.399338] TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.400567] TCP bind hash table entries: 1024 (order: 1, 8192 bytes, linear)
[    0.401778] TCP: Hash tables configured (established 1024 bind 1024)
[    0.403210] UDP hash table entries: 256 (order: 1, 8192 bytes, linear)
[    0.404303] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes, linear)
[    0.422140] Unpacking initramfs...
[    0.457955] workingset: timestamp_bits=30 max_order=14 bucket_order=0
[    0.665114] io scheduler mq-deadline registered
[    0.665970] io scheduler kyber registered

2.

Generaly, it could be because opensbi has a missconfigured UART address, or something in that kind. (as that can vary between SoC)

How do I even go about solving that problem? Is that an issue regarding the CSR file?

Dolu1990 commented 1 year ago

I think the hang is normal, it will jsut take ages to unpack the initramfs :)

Is that an issue regarding the CSR file?

Yes You have to check where is the uart on the simulated SoC, and then, recompile opensbi with that address in i think, i'm not exactly sure.

OrkunAliOzkan commented 1 year ago

I think the hang is normal, it will jsut take ages to unpack the initramfs :)

You were right it does just take hours xD

You have to check where is the uart on the simulated SoC, and then, recompile opensbi with that address in i think, i'm not exactly sure.

I'm passing in the device tree into the buildscript so surely it would know what the correct uart address is, would you please elaborate? How can I determine what the correct uart address is for the sim?

OrkunAliOzkan commented 1 year ago

Hi, I realised that my method of generating the device tree was incorrect and that in fact for the sim use the simulators csr generation functionality (duh!)

Dolu1990 commented 1 year ago

For opensbi, for instance here is some hardcoded addresses : https://github.com/litex-hub/opensbi/blob/a9ce3ada56574fcdb5befae0395f2f3d33134f81/platform/litex/vexriscv/litex.c#L29