Linux boot hangs in litex_sim.

[domninvv]

Hello! I'm trying to reproduce Linux boot using litex_sim, but seems like boot process hangs at the certain point: [ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000 [ 0.000000] Linux version 4.15.0-00049-g0893cdb507ad (martin@martin-ThinkPad-T14-Gen-1) (gcc version 7.2.0 (GCC)) #1 SMP Tue Jul 27 02:49:52 CEST 2021 [ 0.000000] bootconsole [early0] enabled [ 0.000000] Initial ramdisk at: 0x (ptrval) (5214208 bytes) [ 0.000000] Zone ranges: [ 0.000000] DMA32 [mem 0x0000000080200000-0x0000000083ffffff] [ 0.000000] Normal [mem 0x0000000084000000-0x0000083fffffffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000080200000-0x0000000083ffffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x0000000083ffffff] [ 0.000000] Cannot allocate SWIOTLB buffer [ 0.000000] elf_hwcap is 0x1129 [ 0.000000] percpu: Embedded 14 pages/cpu @ (ptrval) s28632 r0 d28712 u57344 [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 15655 [ 0.000000] Kernel command line: [ 0.000000] Dentry cache hash table entries: 8192 (order: 4, 65536 bytes) [ 0.000000] Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] Sorting __ex_table... [ 0.000000] Memory: 50976K/63488K available (4310K kernel code, 219K rwdata, 841K rodata, 5287K init, 780K bss, 12512K reserved, 0K cma-reserved) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU event tracing is enabled. [ 0.000000] RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1. [ 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] riscv,cpu_intc,0: 64 local interrupts mapped [ 0.000000] clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x1d854df40, max_idle_ns: 28210892935680 ns [ 0.007128] sched_clock: 64 bits at 125kHz, resolution 8000ns, wraps every 17592186044000ns [ 0.130504] console [hvc0] enabled [ 0.130504] console [hvc0] enabled [ 0.183352] bootconsole [early0] disabled [ 0.183352] bootconsole [early0] disabled [ 0.292048] Calibrating delay loop (skipped), value calculated using timer frequency.. 0.25 BogoMIPS (lpj=1250) [ 0.373240] pid_max: default: 32768 minimum: 301 [ 0.820656] Mount-cache hash table entries: 512 (order: 0, 4096 bytes) [ 0.909464] Mountpoint-cache hash table entries: 512 (order: 0, 4096 bytes) [ 5.959248] Hierarchical SRCU implementation. [ 8.297072] smp: Bringing up secondary CPUs ... [ 8.363144] smp: Brought up 1 node, 1 CPU [ 10.613224] devtmpfs: initialized [ 14.547200] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns [ 14.671200] futex hash table entries: 256 (order: 2, 16384 bytes) [ 16.885384] random: get_random_u32 called from bucket_table_alloc+0x134/0x3c0 with crng_init=0 [ 17.704808] NET: Registered protocol family 16 [ 40.927928] vgaarb: loaded [ 42.148584] SCSI subsystem initialized [ 44.191576] usbcore: registered new interface driver usbfs [ 44.436904] usbcore: registered new interface driver hub [ 44.709496] usbcore: registered new device driver usb [ 45.195544] pps_core: LinuxPPS API ver. 1 registered [ 45.251392] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> [ 45.395344] PTP clock support registered The output then freezes and nothing happens for days. Am I doing something wrong?

[troibe]

Hi @domninvv, How long did you actually wait? Linux is a super complex thing to execute on a simulated CPU. On my fairly new Ryzen system with 32GB of RAM I usually let the simulation run over night.

[domninvv]

Hi @domninvv, How long did you actually wait? Linux is a super complex thing to execute on a simulated CPU. On my fairly new Ryzen system with 32GB of RAM I usually let the simulation run over night.

At least for 3 days on AMD Epyc 7352 and no single line after "[ 45.395344] PTP clock support registered" is printed.

[troibe]

Ok perfect! At that point it should definitely have made some progress. Let me see if I can reproduce it and get back to you.

[domninvv]

I'm tying to reproduce all the steps in README.md, and I must notice that "ram_boot_offset = 0x40000000 # FIXME " is not valid for the litex_sim.py which is cloned from the master branch - there is no such line in this file at all, though it exists in original litex_sim.py in litex repo master branch.

[troibe]

I was able to reproduce the issue. Unfortunately I don't have the time currently to investigate which version of Litex broke the setup. As of now please use the version fixed in this repo if possible. I'll look into the more recent versions in the future.