LiteX is a Migen/MiSoC based Core/SoC builder that provides the infrastructure to easily create Cores/SoCs (with or without CPU).

Related tags

Miscellaneous litex
Overview

                          Copyright 2012-2020 / Enjoy-Digital

License

Welcome to LiteX!

LiteX is a Migen/MiSoC based Core/SoC builder that provides the infrastructure to easily create Cores/SoCs (with or without CPU). The common components of a SoC are provided directly: Buses and Streams (Wishbone, AXI, Avalon-ST), Interconnect, Common cores (RAM, ROM, Timer, UART, etc...), CPU wrappers/integration, etc... and SoC creation capabilities can be greatly extended with the ecosystem of LiteX cores (DRAM, PCIe, Ethernet, SATA, etc...) that can be integrated/simulated/build easily with LiteX. It also provides build backends for open-source and vendors toolchains.

Think of Migen as a toolbox to create FPGA designs in Python and LiteX as a SoC builder to create/develop/debug FPGA SoCs in Python.

Want to get started and/or looking for documentation? Make sure to visit the Wiki!

A question or want to get in touch? Our IRC channel is #litex at freenode.net

Typical LiteX design flow:

                                      +---------------+
                                      |FPGA toolchains|
                                      +----^-----+----+
                                           |     |
                                        +--+-----v--+
                       +-------+        |           |
                       | Migen +-------->           |
                       +-------+        |           |        Your design
                                        |   LiteX   +---> ready to be used!
                                        |           |
              +----------------------+  |           |
              |LiteX Cores Ecosystem +-->           |
              +----------------------+  +-^-------^-+
               (Eth, SATA, DRAM, USB,     |       |
                PCIe, Video, etc...)      +       +
                                         board   target
                                         file    file

LiteX already supports various softcores CPUs: VexRiscv, Rocket, LM32, Mor1kx, PicoRV32, BlackParrot and is compatible with the LiteX's Cores Ecosystem:

Name Build Status Description
LiteX-Boards Boards support
LiteDRAM DRAM
LiteEth Ethernet
LitePCIe PCIe
LiteSATA SATA
LiteSDCard SD card
LiteICLink Inter-Chip communication
LiteJESD204B JESD204B
LiteVideo VGA, DVI, HDMI
LiteScope Logic analyzer

By combining LiteX with the ecosystem of cores, creating complex SoCs becomes easier than with traditional tools while providing better portability and flexibility. Here are some projects created recently with the tools:

A Multi-core Linux Capable SoC based on VexRiscv-SMP CPU, LiteDRAM, LiteSATA and integrated with LiteX: For more info, have a look at Linux-on-LiteX-Vexriscv project and try running Linux on your FPGA board!

A custom PCIe SDI Capture/Playback board built around LitePCIe and integrated with LiteX, allowing full control of the SDI flow and very low latency. To discover more products/projects built with LiteX, visit the projects page on the Wiki.

Papers, Presentations, Tutorials, Links

FPGA lessons/tutorials:

Migen tutorial:

OSDA 2019 paper/slides:

Linux on LiteX-Vexriscv:

RISC-V Getting Started Guide:

LiteX vs. Vivado First Impressions:

35C3 - Snakes and Rabbits - How CCC shaped an open hardware success:

Tim has to many projects - LatchUp Edition: https://www.youtube.com/watch?v=v7WrTmexod0

Sub-packages

litex.gen Provides specific or experimental modules to generate HDL that are not integrated in Migen.

litex.build: Provides tools to build FPGA bitstreams (interface to vendor toolchains) and to simulate HDL code or full SoCs.

litex.soc: Provides definitions/modules to build cores (bus, bank, flow), cores and tools to build a SoC from such cores.

Quick start guide

  1. Install Python 3.6+ and FPGA vendor's development tools and/or Verilator.
  2. Install Migen/LiteX and the LiteX's cores:
$ wget https://raw.githubusercontent.com/enjoy-digital/litex/master/litex_setup.py
$ chmod +x litex_setup.py
$ ./litex_setup.py init install --user (--user to install to user directory)

Later, if you need to update all repositories:

$ ./litex_setup.py update

Note: On MacOS, make sure you have HomeBrew installed. Then do, brew install wget.

Note: On Windows, it's possible you'll have to set SHELL environment variable to SHELL=cmd.exe.

  1. Install a RISC-V toolchain (Only if you want to test/create a SoC with a CPU):
$ ./litex_setup.py gcc
  1. Build the target of your board...:

Go to litex-boards/litex_boards/targets and execute the target you want to build.

  1. ... and/or install Verilator and test LiteX directly on your computer without any FPGA board:

On Linux (Ubuntu):

$ sudo apt install libevent-dev libjson-c-dev verilator
$ lxsim --cpu-type=vexriscv

On MacOS:

$ brew install json-c verilator libevent
$ brew cask install tuntap
$ lxsim --cpu-type=vexriscv
  1. Run a terminal program on the board's serial port at 115200 8-N-1.

You should get the BIOS prompt like the one below.

Community

LiteX has been initially developed by EnjoyDigital to create custom SoCs/Systems for our clients (and we are still using it for that purpose :)); but over the years a friendly community has grown around LiteX and the ecosystem of cores. Feedbacks and contributions have already greatly improved the project, EnjoyDigital still leads the development but it is now a community project and collaborative projects created around/with LiteX can be found at https://github.com/litex-hub.

Contact

E-mail: [email protected]

Comments
  • RFC: Split LiteX CPU cores into their own Python modules

    RFC: Split LiteX CPU cores into their own Python modules

    With the increasing number of CPU cores supported by LiteX, cloning the LiteX repository means cloning a large number of submodules which can get very big.

    I think we should convert each of the supported LiteX CPUs into their own Python packages.

    litex/soc/cores/cpu becomes a "namespace module" which other Python packages can provide modules under. See https://packaging.python.org/guides/packaging-namespace-packages/

    The CPUs can be split into;

    • [ ] litex-cpu-lm32
    • [ ] litex-cpu-mor1k
    • [ ] litex-cpu-vexriscv
    • [ ] litex-cpu-blackparrot
    • [ ] litex-cpu-microwatt
    • [ ] litex-cpu-chiselwatt
    • [ ] litex-cpu-rocket
    • [ ] litex-cpu-picorv32
    • [ ] litex-cpu-minerva

    This allows projects which are only using a single CPU like VexRISCV to only pay the cost of that CPU.

    The setup process then becomes;

    git clone git+ssh://github.com/enjoy-digital/litex.git
    (cd litex; python setup.py install)
    git clone git+ssh://github.com/enjoy-digital/litex-cpu-vexriscv.git
    (cd litex-cpu-vexriscv; python setup.py install)
    

    People can also submodule the repository in using the normal method of;

    git submodule add third_party/litex git+ssh://github.com/enjoy-digital/litex.git
    (cd third_party/litex; python setup.py -e install)
    git submodule add third_party/litex-cpu-vexriscv git+ssh://github.com/enjoy-digital/litex-cpu-vexriscv.git
    (cd third_party/litex-cpu-vexriscv; python setup.py -e install)
    

    Or specify a Python requirements file using;

    -e https://github.com/enjoy-digital/litex.git#egg=litex
    -e https://github.com/enjoy-digital/litex-cpu-vexriscv.git#egg=litex-cpu-vexriscv
    

    We can easily set up Travis CI so that any push to the LiteX repository causes each of the CPU packages to be tested in combination with the based LiteX.

    As VexRISCV is currently the most popular CPU to use with LiteX, we could also make VexRISCV the "default" CPU that is included with LiteX by default and just move the other CPU cores into their own modules. I personally don't think we should preference VexRISCV like that, but it could be a possible compromise?

    Thoughts?

    enhancement question 
    opened by mithro 51
  • integration/soc Add accessible_region to add_memory_buses

    integration/soc Add accessible_region to add_memory_buses

    Commit Message: Enables CPUs to know which memory addresses are accessible via the connected memory_bus.

    Explanation: Current situation around the NaxRiscv:

    • litex_sim --cpu-type naxriscv working
    • litex_sim --cpu-type naxriscv --integrated-main-ram-size 8192 Hangs, litex does not connect anything to the CPU's memory_bus, but NaxRiscv uses the memory_bus for every main_ram request.
    • Any litex_sim --cpu-type naxriscv --with-sdram --sdram-module=MT41K128M16 --sdram-data-width=16 but with other main_ram origins would also not work because the ioRange of naxriscv is hardcoded.

    Idea of this PR: Configure the nax IORange with the help of SoCRegion data.

    The following NaxRiscv pythondata changes are necessary for testing: config/gen.scala:14 replace ioRange with:

    def ioRange (address : UInt) : Bool = {
      if(args.contains("mem-region-origin"))
        !SizeMapping(BigInt(args("mem-region-origin").toString), BigInt(args("mem-region-length").toString)).hit(address)
      else 
        True
    }
    

    @enjoy-digital How do you think about this PR?

    Additional notes:

    • Unfortunately, I was not able to write the Scala code in a cleaner way.
    • This PR only changes the ioRange, the FetchRange setting could be improved later as well.
    opened by cklarhorst 48
  • LiteX 2020 roadmap and new LiteX SoC class

    LiteX 2020 roadmap and new LiteX SoC class

    LiteX has evolved a lot and the current SoCCore, SoCSDRAM inheritated from MiSoC have evolved quite a bit in the last years and could be greatly improved now that we have a better idea of the SoCs we want to be able build with LiteX and the features we want to support.

    A new refreshed LiteXSoC class could be created and could be flexible enough to: In the short term:

    • [ ] allow SoCCore/SoCSDRAM/SoCZynq to inherit from it for retro-compatibility with existing designs.
    • [x] support different types of main SoC bus (Wishbone, AXI, etc...) with different data-widths.
    • [x] support automatic bridging between bus types and data-width adaptation when adding a bus Master or Slave to the main bus (ex: AXI 64-bit to Wishbone 32-bit, Wishbone 32-bit to AXI 32-bit, etc...)
    • [x] support AXI-Lite ROM/SRAM/Interconnect when main bus is AXI (requires adding AXI-Lite ROM, SRAM, Interconnect components to LiteX).
    • [x] support mixed dynamic/static CSRs regions allocation (some CSR regions could be user-defined or reserved by the CPU (and then static), the others could dynamically allocated).
    • [x] support AXI-Lite to CSRs direct bridging when the main bus is AXI. (we are currently doing AXI->Wishbone->CSR which is not efficient).
    • [ ] support mixed dynamic/static CSRs allocation within a CSR region. (It's currently difficult to use static CSRs regions since CSRs can move within a module when a new CSR is added).
    • [x] support mixed dynamic/static IRQs numbering (some IRQs could be user-defined or reserved by the CPU (and then static), the others could dynamically allocated).
    • [x] support mixed dynamic/static Memory regions allocation (some Memory regions could be user-defined or reserved by the CPU (and then static), the others could dynamically allocated).
    • [x] support properties on Memory regions: IO/Cached/Linker, allow the CPU (or main Master of the bus) to define the IO/Cached regions and checks regions properties when adding a new peripheral to the memory map.
    • [ ] ease multiple instances of a similar component (SDRAM, Ethernet, etc...): It's already possible, but requires workarounds.
    • [x] ease instance of standard SoC components/cores: we currently have redundancies in the targets when adding an Ethernet, SDRAM core and as prototyped in Linux-on-LiteX-Vexriscv (https://github.com/litex-hub/linux-on-litex-vexriscv/blob/master/soc_linux.py) we could probably have add_ethernet, add_sdram, ... methods to easily add standard components. With only a few parameters, the method would be able to find the right core/primitive/implementation to use and then simplify integration and reduce redundancy.
    • [ ] improve the .csv/.json exports of the SoC informations to allow external tools to easily reuse this.

    In the long term:

    • [x] add logging of all the steps of the SoC elaboration to ease SoC creation/debug. (ex: information on the CPU (type, data width, parameters), main bus (type, data width), about all the automatic operations happening during the SoC creation (bridge additions, data-width adaptation, automatic allocation of CSR regions/IRQ/Memory regions, PLL parameters computations, etc... so that the user can be aware of this more easily: looking at the generated csr.h/soc.v or just receive an error message is often to limited to really understand what is going on).
    • [ ] add AMP/SMP support for multi-CPU.
    • [ ] add multi-SoC support with NoC interconnection between SoCs.
    • etc...

    Also, even if using Migen vs nMigen is not really limiting LiteX for now, we should see if it's possible to switch easily between Migen and nMigen compat mode to generate the verilog (would allow testing progressively nMigen while still allowing Migen use) and then see if it's interesting to start creating new cores in nMigen or/and adapt existing ones.

    I'll start prototyping this in the next weeks/months and that would be great to discuss or/and have feedback/ideas from the main contributors/users: @mithro, @xobs, @gsomlo, @mateusz-holenko, @jersey99, @bunnie, @gregdavill or anyone having ideas on the direction LiteX should take.

    Edit: Feedbacks/Suggestions:

    @xobs:

    • [ ] Using CSRs as a bus by themselves. We had some people wanting to put a 6502 on Fomu, and being able to use CSRs natively would be a neat trick.
    • [x] BIOS on SPI. Currently this is very clunky, as litex appears to be designed around the assumption that instruction 0 must be in a ROM somewhere in a region called "rom", and must have a program called "bios.elf". This is the case for most large FPGAs, but for smaller ICE40 boards being able to boot directly from XIP SPI would be nice.
    • [ ] Documented Caching. There appears to be a cache that we're seeing on Betrusted (L2 cache?) that we're not seeing on Fomu. As such, accesses are bursty on Betrusted but super slow on Fomu. It'd be nice to know how that's done, and how to enable it on Fomu.
    • [ ] Nicer IP Library. I'm still not sure how to handle this one. Over time, we've been building up a library of IP modules that tend to live in various repositories. These are self-contained files, usually Modules, such as a random number generator, touchpad, or RGB LED.

    @daveshah1:

    • [x] it would definitely be good to have the litedram/eth init code in the same repo as the cores by putting them all in one repo or making the BIOS more modular.
    • [x] Apropos external CSR bus, it would be nice to support systems where the main processor is actually a hard core (Zynq etc) and LiteX just provides peripherals.
    enhancement 
    opened by enjoy-digital 44
  • Porting LiteX to the Crosslink-NX eval board

    Porting LiteX to the Crosslink-NX eval board

    I've just started working on getting LiteX working on the Crosslink-NX evaluation board, basically copying the Versa ECP5 target, stripping out the Trellis stuff, adapting it for Radiant, and working on some of the device specific details that need to be figured out (like the PLL block configuration). Figured I'd start a thread here on it in case anyone else has played with this, or has some pointers on the process.

    new-feature 
    opened by davidcorrigan714 40
  • Litex BIOS SD Card Booting via SPI (bitbanging)

    Litex BIOS SD Card Booting via SPI (bitbanging)

    I've generated code, shown to work on a de10nano with a MiSTer SDRAM board that will load EMULATOR.BIN, IMAGE, ROOTFS~1.CPI and RV32.DTB from a SD Card connected to GPIO pins in SPI mode.

    Demonstration below:

    `--============= Console ================-- litex> gpiospisdboot SD Card via SPI Initialising Reading MBR Partition Information: Active=0x00, Type=0x06, LBAStart=0x00000800

    Read FAT16 Boot Sector Jump Code: 0xeb 0x3c 0x90 OEM Code: [mkfs.fat] Sector Size: 512 Sectors Per Cluster: 128 Reserved Sectors: 128 Number of Fats: 2 Root Dir Entries: 2048 Total Sectors Short: 0 Media Descriptor: 0xf8 Fat Size Sectors: 128 Sectors Per Track: 32 Number of Heads: 64 Hidden Sectors: 2048 Total Sectors Long: 4194304 Drive Number: 0x80 Current Head: 0x01 Boot Signature: 0x29 Volume ID: 0xebdc1fad Volume Label: [RISCV ] Volume Label: [FAT16 ] Boot Sector Signature: 0xaa55

    sdCardFatTable = 0xc7ff0000 Reading Fat16 Table (128 Sectors Long)

    sdCardFat16RootDir = 0xc7fe0000 Reading Root Directory (128 Sectors Long)

    Root Directory File 0 [RISCV . ] @ Cluster 0 for 0 bytes File 2 [EMULATOR.BIN] @ Cluster 3 for 9600 bytes File 4 [IMAGE . ] @ Cluster 4 for 4545524 bytes File 6 [ROOTFS~1.CPI] @ Cluster 74 for 8029184 bytes File 8 [RV32 .DTB] @ Cluster 197 for 1837 bytes

    Reading File [IMAGE.] into 0xc0000000 : File starts at Cluster 4 length 4545524 Clusters: 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73

    Reading File [ROOTFS~1.CPI] into 0xc0800000 : File starts at Cluster 74 length 8029184 Clusters: 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196

    Reading File [RV32.DTB] into 0xc1000000 : File starts at Cluster 197 length 1837 Clusters: 197

    Reading File [EMULATOR.BIN] into 0x20000000 : File starts at Cluster 3 length 9600 Clusters: 3

    Executing booted program at 0x20000000

    --============= Liftoff! ===============-- VexRiscv Machine Mode software built Jan 10 2020 11:39:55 --========== Booting Linux =============--`

    Code is available at https://github.com/rob-ng15/litex-mister

    enhancement 
    opened by rob-ng15 39
  • FemtoRV: Finish integration.

    FemtoRV: Finish integration.

    The upstream versions does not compile correctly with Verilator with ADDR_WIDTH set to 32. So the following patched version is currently used: femtorv32_quark.v.txt.

    enhancement 
    opened by enjoy-digital 38
  • issues with the picolibc switch?:  Use this issue to share issues/get information/help

    issues with the picolibc switch?: Use this issue to share issues/get information/help

    My CI just broke on the latest litex, and there's a new note that this library seems to be required:

    Traceback (most recent call last):
      File "/home/bunnie/code/betrusted-soc/betrusted_soc.py", line 1974, in <module>
        ret = main()
      File "/home/bunnie/code/betrusted-soc/betrusted_soc.py", line 1901, in main
        vns = builder.build(run=False)
      File "/home/bunnie/code/betrusted-soc/deps/litex/litex/soc/integration/builder.py", line 276, in build
        new_variables_contents = self._get_variables_contents()
      File "/home/bunnie/code/betrusted-soc/deps/litex/litex/soc/integration/builder.py", line 143, in _get_variables_contents
        picolibc_directory = get_data_mod("software", "picolibc").data_location
      File "/home/bunnie/code/betrusted-soc/deps/litex/litex/__init__.py", line 14, in get_data_mod
        raise ImportError("""\
    ImportError: pythondata-software-picolibc module not installed! Unable to use picolibc software.
    No module named 'pythondata_software_picolibc'
    
    You can install this by running;
     pip install git+https://github.com/litex-hub/pythondata-software-picolibc.git
    

    However, at least in my view of litex-hub, I don't see a pythondata-software-picolibc:

    image

    (In the image above, I'm only finding software-compiler-rt in litex-hub, and that is the only search result)

    I have a feeling I'm missing something really obvious -- could someone please give me a clue on where to find this new dependency?

    bug? 
    opened by bunnie 36
  • Converting LiteX to use Python modules.

    Converting LiteX to use Python modules.

    This is the start of converting LiteX to use the litex-data-XXX python modules.

    It hasn't been tested and probably doesn't work yet, but wanted you to see the direction it is going.

    opened by mithro 34
  • CSR accessor performance / feature / build Regressions

    CSR accessor performance / feature / build Regressions

    Due to a recent change, the CSR accessor methods have undergone a large performance regression. Additionally, the Etherbone library is now incompatible.

    Performance Regression

    Previously, CSRs were defined similarly to:

    static inline void csr_writel(uint32_t value, uint32_t addr)
    {
    	*((volatile uint32_t *)addr) = value;
    }
    

    This allowed the compiler to inline writes very easily. For example, in Fomu we have the following function:

    static void spi_single_tx(uint8_t out) {
    	int bit;
    
    	for (bit = 7; bit >= 0; bit--) {
    		if (out & (1 << bit)) {
    			lxspi_bitbang_write((0 << PIN_CLK) | (1 << PIN_MOSI));
    			lxspi_bitbang_write((1 << PIN_CLK) | (1 << PIN_MOSI));
    			lxspi_bitbang_write((0 << PIN_CLK) | (1 << PIN_MOSI));
    		} else {
    			lxspi_bitbang_write((0 << PIN_CLK) | (0 << PIN_MOSI));
    			lxspi_bitbang_write((1 << PIN_CLK) | (0 << PIN_MOSI));
    			lxspi_bitbang_write((0 << PIN_CLK) | (0 << PIN_MOSI));
    		}
    	}
    }
    

    This would get compiled down to the following function:

    (gdb) disassemble spi_single_tx
    Dump of assembler code for function spi_single_tx:
       0x0000014c <+0>:     li      a4,7
       0x00000150 <+4>:     lui     a5,0xe0008
       0x00000154 <+8>:     li      a6,2
       0x00000158 <+12>:    li      a2,1
       0x0000015c <+16>:    li      a7,3
       0x00000160 <+20>:    li      a1,-1
       0x00000164 <+24>:    sra     a3,a0,a4
       0x00000168 <+28>:    andi    a3,a3,1
       0x0000016c <+32>:    beqz    a3,0x188 <spi_single_tx+60>
       0x00000170 <+36>:    sw      a2,-2048(a5) # 0xe0007800
       0x00000174 <+40>:    sw      a7,-2048(a5)
       0x00000178 <+44>:    sw      a2,-2048(a5)
       0x0000017c <+48>:    addi    a4,a4,-1
       0x00000180 <+52>:    bne     a4,a1,0x164 <spi_single_tx+24>
       0x00000184 <+56>:    ret
       0x00000188 <+60>:    sw      zero,-2048(a5)
       0x0000018c <+64>:    sw      a6,-2048(a5)
       0x00000190 <+68>:    sw      zero,-2048(a5)
       0x00000194 <+72>:    j       0x17c <spi_single_tx+48>
    End of assembler dump.
    (gdb)
    

    With the most recent changes to the CSR accessors, this is now expanded to:

    (gdb) disassemble spi_single_tx
    Dump of assembler code for function spi_single_tx:
       0x000001dc <+0>:     addi    sp,sp,-16
       0x000001e0 <+4>:     sw      s0,8(sp)
       0x000001e4 <+8>:     sw      s1,4(sp)
       0x000001e8 <+12>:    sw      s2,0(sp)
       0x000001ec <+16>:    sw      ra,12(sp)
       0x000001f0 <+20>:    mv      s2,a0
       0x000001f4 <+24>:    li      s0,7
       0x000001f8 <+28>:    li      s1,-1
       0x000001fc <+32>:    sra     a5,s2,s0
       0x00000200 <+36>:    andi    a5,a5,1
       0x00000204 <+40>:    beqz    a5,0x240 <spi_single_tx+100>
       0x00000208 <+44>:    li      a0,1
       0x0000020c <+48>:    jal     ra,0x1c8 <lxspi_bitbang_write>
       0x00000210 <+52>:    li      a0,3
       0x00000214 <+56>:    jal     ra,0x1c8 <lxspi_bitbang_write>
       0x00000218 <+60>:    li      a0,1
       0x0000021c <+64>:    addi    s0,s0,-1
       0x00000220 <+68>:    jal     ra,0x1c8 <lxspi_bitbang_write>
       0x00000224 <+72>:    bne     s0,s1,0x1fc <spi_single_tx+32>
       0x00000228 <+76>:    lw      ra,12(sp)
       0x0000022c <+80>:    lw      s0,8(sp)
       0x00000230 <+84>:    lw      s1,4(sp)
       0x00000234 <+88>:    lw      s2,0(sp)
       0x00000238 <+92>:    addi    sp,sp,16
       0x0000023c <+96>:    ret
       0x00000240 <+100>:   li      a0,0
       0x00000244 <+104>:   jal     ra,0x1c8 <lxspi_bitbang_write>
       0x00000248 <+108>:   li      a0,2
       0x0000024c <+112>:   jal     ra,0x1c8 <lxspi_bitbang_write>
       0x00000250 <+116>:   li      a0,0
       0x00000254 <+120>:   j       0x21c <spi_single_tx+64>
    End of assembler dump.
    (gdb) disassemble lxspi_bitbang_write
    Dump of assembler code for function lxspi_bitbang_write:
       0x000001c8 <+0>:     mv      a1,a0
       0x000001cc <+4>:     lui     a0,0xe0008
       0x000001d0 <+8>:     li      a2,0
       0x000001d4 <+12>:    addi    a0,a0,-2048 # 0xe0007800
       0x000001d8 <+16>:    j       0x20 <_csr_wr>
    End of assembler dump.
    (gdb) disassemble _csr_wr
    Dump of assembler code for function _csr_wr:
       0x00000020 <+0>:     sw      a1,0(a0)
       0x00000024 <+4>:     ret
    End of assembler dump.
    (gdb)
    

    Each single-instruction store is turned into two function calls and a load, which increases the instruction count 9x (ignoring penalties for jumps and returns).

    Feature regression

    It can be extremely useful to use libeb-c with the wishbone bridge in order to prototype and debug code on a local machine before porting it to an embedded softcore. Previously, the functions csr_(read|write)[bwl]() were conditionally defined if CSR_ACCESSORS_DEFINED was not defined. This allowed for C code to be compiled both for the device itself, as well as on a host system connected to a wishbone bridge simply by defining the macro CSR_ACCESSORS_DEFINED and providing replacement functions.

    With the most recent patch, this can no longer be done. Instead it inserts an unconditional call to _csr_(rd|wr) which does direct array indexing.

    Build regression

    The new function appears to require a new symbol when compiling with 8-bit CSRs:

    d:/software/fomu-toolchain-windows-v1.5.3/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/bin/ld.exe: C:\Users\smcro\AppData\Local\Temp\ccK4Ba47.ltrans0.ltrans.o: in function `.L0 ':
    D:\Code\Fomu\foboot\hw\build\software\bios/../../../../sw/include/hw/common.h:78: undefined reference to `__lshrdi3'
    collect2.exe: error: ld returned 1 exit status
    

    This appears to be due to the use of 64-bit parameters on a 32-bit system. Changing the argument to a 32-bit parameter (i.e. static inline void _csr_wr(unsigned long *a, uint32_t v, int csr_bytes)) fixes this build issue, but it's not clear why this needs to be a 64-bit value.

    enhancement question 
    opened by xobs 30
  • Create a custom some with 2 cores and a custom communication

    Create a custom some with 2 cores and a custom communication

    Hello everyone,

    I am interested in creating a SoC with 2 cores and a custom communication between them (UART or something else). But reading the BaseSoC implementation, I see no trick that I could do. I thought about creating a SoC module with 2 cores submodules. Can someone help me, every idea is welcome. The idea I have in mind is like in the image attached. Thank you.

    Jo Distributed-Memory-Architecture

    question ideas 
    opened by jwfaye 27
  • Software only compiles on Windows when V=1

    Software only compiles on Windows when V=1

    Something changed, and now

    smcro@CUBOID   yosys-bld  D:\Code\HaD\valentytest   master ≢                                                                                                                                                                                 [09:36]
    ❯ make -C D:\Code\HaD\valentytest\build2\software\libcompiler_rt -f D:\Code\HaD\valentytest\deps\litex\litex\soc\software\libcompiler_rt\Makefile
    make: Entering directory 'D:/Code/HaD/valentytest/build2/software/libcompiler_rt'
     CC       umodsi3.o
    riscv64-unknown-elf-gcc.exe: error: D:CodeHaDvalentytestdepslitexlitexsoc/software/compiler_rt/lib/builtins/umodsi3.c: No such file or directory
    riscv64-unknown-elf-gcc.exe: fatal error: no input files
    compilation terminated.
    make: *** [D:\Code\HaD\valentytest\deps\litex\litex\soc\software\libcompiler_rt\Makefile:27: umodsi3.o] Error 1
    make: Leaving directory 'D:/Code/HaD/valentytest/build2/software/libcompiler_rt'
    smcro@CUBOID   yosys-bld  D:\Code\HaD\valentytest   master ≢                                                                                                                                                                                 [09:36]
    ❯ make -C D:\Code\HaD\valentytest\build2\software\libcompiler_rt -f D:\Code\HaD\valentytest\deps\litex\litex\soc\software\libcompiler_rt\Makefile V=1
    make: Entering directory 'D:/Code/HaD/valentytest/build2/software/libcompiler_rt'
    riscv64-unknown-elf-gcc -std=gnu99 -c -MD -MP -Os -march=rv32ima    -mabi=ilp32 -D__vexriscv__ -g3 -fomit-frame-pointer -Wall -fno-builtin -nostdinc -ID:\\Code\\HaD\\valentytest\\deps\\litex\\litex\\soc/software/include/base -ID:\\Code\\HaD\\valentytest\\deps\\litex\\litex\\soc/software/include -ID:\\Code\\HaD\\valentytest\\deps\\litex\\litex\\soc/common -ID:\\Code\\HaD\\valentytest\\build2\\software\\include -fexceptions -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -D_YUGA_LITTLE_ENDIAN=1 -D_YUGA_BIG_ENDIAN=0 -Wno-missing-prototypes  D:\\Code\\HaD\\valentytest\\deps\\litex\\litex\\soc/software/compiler_rt/lib/builtins/umodsi3.c -o umodsi3.o
    riscv64-unknown-elf-gcc -std=gnu99 -c -MD -MP -Os -march=rv32ima    -mabi=ilp32 -D__vexriscv__ -g3 -fomit-frame-pointer -Wall -fno-builtin -nostdinc -ID:\\Code\\HaD\\valentytest\\deps\\litex\\litex\\soc/software/include/base -ID:\\Code\\HaD\\valentytest\\deps\\litex\\litex\\soc/software/include -ID:\\Code\\HaD\\valentytest\\deps\\litex\\litex\\soc/common -ID:\\Code\\HaD\\valentytest\\build2\\software\\include -fexceptions -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -D_YUGA_LITTLE_ENDIAN=1 -D_YUGA_BIG_ENDIAN=0 -Wno-missing-prototypes  D:\\Code\\HaD\\valentytest\\deps\\litex\\litex\\soc/software/compiler_rt/lib/builtins/udivsi3.c -o udivsi3.o
    

    I'm unsure of what changed, or why it's not working. The && appears to be causing the problem now.

    My current workaround is to hardcode V=1 in common.mk.

    Edited: Corrected how I'm hardcoding verbose mode.

    question 
    opened by xobs 27
  • liblitedram: SPD read improvements

    liblitedram: SPD read improvements

    • add generic sdram_read_spd function, that automatically changes SPD pages
    • make sdram_spd command read entire SPD
    • print memory sizes using print_size function, which selects appropriate unit (B/KiB/MiB/GiB)
    • make printed SDRAM size match, actually supported memory size by litedram. Read module size from the SPD and multiply it by the number of modules defined by litedram.
    • do not choose between printing either main RAM size or SDRAM size, as they might differ. Rather print both if available

    This PR requires changes in litedram from PR https://github.com/enjoy-digital/litedram/pull/320:

    • definition of SDRAM_PHY_SUPPORTED_MEMORY as a fallback when SPD is not available
    • definition of SDRAM_PHY_[DDR3|DDR4|...] to select appropriate code paths when reading and parsing the SPD
    opened by michalsieron 0
  • DMA Axi connection is not working

    DMA Axi connection is not working

    Hi, I believe that you have not updated the axis connection of DMA and it is not working. When I try to connect it to the axis it gives me an error like this.

      File "litex_sim.py", line 1259, in <module>
        main()
      File "litex_sim.py", line 1219, in main
        soc = SimSoC(
      File "litex_sim.py", line 248, in __init__
        self.submodules.mm2s = mm2s = LiteDRAMDMAReader(axi_port_mm2s,fifo_buffered=True,with_csr=True)
      File "/home/mohammad/Desktop/fpga_dnn/litex/litedram/litedram/frontend/dma.py", line 107, in __init__
        rdata.connect(fifo.sink, omit={"id", "resp"}),
      File "/home/mohammad/Desktop/fpga_dnn/litex/migen/migen/genlib/record.py", line 165, in connect
        r += self_e.connect(getattr(slave, field), keep=keep, omit=omit)
      File "/home/mohammad/Desktop/fpga_dnn/litex/migen/migen/genlib/record.py", line 158, in connect
        r += [getattr(slave, field).eq(self_e) for slave in slaves]
      File "/home/mohammad/Desktop/fpga_dnn/litex/migen/migen/genlib/record.py", line 158, in <listcomp>
        r += [getattr(slave, field).eq(self_e) for slave in slaves]
    AttributeError: 'Record' object has no attribute 'dest'
    

    Then, I changed "dma.py" line 107 to rdata.connect(fifo.sink, omit={"id","resp","dest","user"}). it is working now, but it gives me a wrong answer so I believe there is more to it than adding,"dest","user". When I looked at the waveforms it was giving me all zeros not sure where the problem is. Here is my code:

    user_port_mm2s = self.sdram.crossbar.get_port(data_width=sdram_data_width)
    axi_port_mm2s  = LiteDRAMAXIPort(
        data_width    = user_port_mm2s.data_width,
        address_width = user_port_mm2s.address_width + log2_int(user_port_mm2s.data_width//8),
        id_width      = 1)
    axi2native_mm2s = LiteDRAMAXI2Native(
        port  = user_port_mm2s,
        axi  = axi_port_mm2s,
        # with_read_modify_write = port.get("ecc", False)
    )
    self.submodules += axi2native_mm2s 
    self.submodules.mm2s = mm2s = LiteDRAMDMAReader(axi_port_mm2s,with_csr=True)
    self.add_csr("mm2s")
    

    it also works correctly when I make a native connection like this: self.submodules.mm2s = mm2s = LiteDRAMDMAReader(user_port_mm2s,with_csr=True)

    opened by mohammadshahidzade 0
  • vexriscv_smp sim-build fails

    vexriscv_smp sim-build fails

    Hi, thanks for this great project!

    I've updated my litex-setup and wanted to get started with a vexriscv-smp configuration - but litex-sim fails:

    $ litex_sim --cpu-type vexriscv_smp
    [...]
    verilator -Wno-fatal -O3 --cc /opt/work/src/orangeCart/supporting-tools/litex/pythondata-cpu-vexriscv-smp/pythondata_cpu_vexriscv_smp/verilog/Ram_1w_1rs_Generic.v --cc /opt/work/src/orangeCart/supporting-tools/litex/pythondata-cpu-vexriscv-smp/pythondata_cpu_vexriscv_smp/verilog/VexRiscvLitexSmpCluster_Cc1_Iw32Is4096Iy1_Dw32Ds4096Dy1_ITs4DTs4_Ood_Wm.v --cc /opt/work/src/orangeCart/supporting-tools/litex/build/sim/gateware/sim.v  --top-module sim --exe \
    	-DPRINTF_COND=0 \
    	sim_init.cpp /opt/work/src/orangeCart/supporting-tools/litex/litex/litex/build/sim/core/veril.cpp libdylib.o modules.o pads.o parse.o sim.o \
    	--top-module sim \
    	 \
    	-CFLAGS "-ggdb -Wall -O3   -I/opt/work/src/orangeCart/supporting-tools/litex/litex/litex/build/sim/core" \
    	-LDFLAGS "-lpthread -Wl,--no-as-needed -ljson-c -lz -lm -lstdc++ -Wl,--no-as-needed -ldl -levent" \
    	--trace \
    	 \
    	 \
    	--unroll-count 256 \
    	--output-split 5000 \
    	--output-split-cfuncs 500 \
    	--output-split-ctrace 500 \
    	 \
    	-Wno-BLKANDNBLK \
    	-Wno-WIDTH \
    	-Wno-COMBDLY \
    	-Wno-CASEINCOMPLETE \
    	--relative-includes
    %Error-TIMESCALEMOD: /opt/work/src/orangeCart/supporting-tools/litex/pythondata-cpu-vexriscv-smp/pythondata_cpu_vexriscv_smp/verilog/Ram_1w_1rs_Generic.v:2:8: Timescale missing on this module as other modules have it (IEEE 1800-2017 3.14.2.2)
                         /opt/work/src/orangeCart/supporting-tools/litex/pythondata-cpu-vexriscv-smp/pythondata_cpu_vexriscv_smp/verilog/VexRiscvLitexSmpCluster_Cc1_Iw32Is4096Iy1_Dw32Ds4096Dy1_ITs4DTs4_Ood_Wm.v:6:8: ... Location of module with timescale
        6 | module VexRiscvLitexSmpCluster_Cc1_Iw32Is4096Iy1_Dw32Ds4096Dy1_ITs4DTs4_Ood_Wm (
          |        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    %Error: Exiting due to 1 error(s)
            ... See the manual and https://verilator.org for more assistance.
    make: *** [/opt/work/src/orangeCart/supporting-tools/litex/litex/litex/build/sim/core/Makefile:44: sim] Error 1
    make: Leaving directory '/opt/work/src/orangeCart/supporting-tools/litex/build/sim/gateware'
    

    I found some thread about TIMESCALEMOD, but trying to add -Wno-TIMESCALEMOD resulted in different errors:

    %Error: /opt/work/src/orangeCart/supporting-tools/litex/pythondata-cpu-vexriscv-smp/pythondata_cpu_vexriscv_smp/verilog/VexRiscvLitexSmpCluster_Cc1_Iw32Is4096Iy1_Dw32Ds4096Dy1_ITs4DTs4_Ood_Wm.v:14242:17: Unsupported or unknown PLI call: '$urandom'
    14242 |     buffers_0 = $urandom;
          |                 ^~~~~~~~
    %Error: /opt/work/src/orangeCart/supporting-tools/litex/pythondata-cpu-vexriscv-smp/pythondata_cpu_vexriscv_smp/verilog/VexRiscvLitexSmpCluster_Cc1_Iw32Is4096Iy1_Dw32Ds4096Dy1_ITs4DTs4_Ood_Wm.v:14243:17: Unsupported or unknown PLI call: '$urandom'
    14243 |     buffers_1 = $urandom;
          |                 ^~~~~~~~
    %Error: /opt/work/src/orangeCart/supporting-tools/litex/pythondata-cpu-vexriscv-smp/pythondata_cpu_vexriscv_smp/verilog/VexRiscvLitexSmpCluster_Cc1_Iw32Is4096Iy1_Dw32Ds4096Dy1_ITs4DTs4_Ood_Wm.v:14191:24: Unsupported or unknown PLI call: '$urandom'
    14191 |     inputArea_target = $urandom;
          |                        ^~~~~~~~
    %Error: /opt/work/src/orangeCart/supporting-tools/litex/pythondata-cpu-vexriscv-smp/pythondata_cpu_vexriscv_smp/verilog/VexRiscvLitexSmpCluster_Cc1_Iw32Is4096Iy1_Dw32Ds4096Dy1_ITs4DTs4_Ood_Wm.v:14192:22: Unsupported or unknown PLI call: '$urandom'
    14192 |     outputArea_hit = $urandom;
          |                      ^~~~~~~~
    %Error: Exiting due to 4 error(s)
    

    My setup builds and boots into the console fine with litex_sim --cpu-type vexriscv.

    Any hints? pottendo

    opened by pottendo 2
  • Add support for Novastar cards

    Add support for Novastar cards

    brand: Novastar MRV416 FPGA: SL3-22E-6B324C (unknown family. possibly vendor Intilligence Silicon) Memory: ESMT M14D5121632A Eth PHY: PF025 Additional MCU: Artery technology AT32F421G8U7 ARM Cortex-M4 based Flash: Fudan micro FM25W32 16 HUB75 ports

    new-feature 
    opened by romanetz 1
  • Cannot start Litex_term on/dev/ttyLXU0 (PCIe) when running Linux on Acorn

    Cannot start Litex_term on/dev/ttyLXU0 (PCIe) when running Linux on Acorn

    Hi, I have been stuck on this issue for days where I built the linux for acorn board but cannot connect to bios or upload linux image via litex_term. More specifically my host computer would just lock up/freeze when I try to use litex_term on the virtual UART port created by litex_pcie driver. The driver loaded fine, and litexpcie_util can correctly see FPGA info and do DMA test. I didn't observer any major error when building the bitstream. Sorry I am failing to provide more specific info on where the issue is, because I just straight up don't know. It could be FPGA side or PCIe driver side or litex_term, but there is no error message showed when lock up happens, and it happens every single time. I attached syslog when lockup happens below, hope that will help, since that's all I got.

    Board:Acorn_CLE215 Project:linux-on-litex-vexriscv Build command used: ./make.py --board=acorn_pcie --build --flash System lock up when executing: litex_term /dev/ttyLXU0 or litex_term --image wheremyimageis /dev/ttyLXU0 Host operating system ubuntu 22.04 (also tried on different computer with ubuntu 18.04 same result) Host computer: Intel NUC PCIe Connection: Thunderbolt3 (also tried directly attach to motherboard with same result)

    syslog when computer crashed:

    Jan  3 02:18:50 patrickchen-NUC10i7FNH rtkit-daemon[934]: Supervising 7 threads of 4 processes of 1 users.
    Jan  3 02:19:50 patrickchen-NUC10i7FNH rtkit-daemon[934]: message repeated 3 times: [ Supervising 7 threads of 4 processes of 1 users.]
    Jan  3 02:20:10 patrickchen-NUC10i7FNH kernel: [ 2011.842655] litepcie: loading out-of-tree module taints kernel.
    Jan  3 02:20:10 patrickchen-NUC10i7FNH kernel: [ 2011.842687] litepcie: module verification failed: signature and/or required key missing - tainting kernel
    Jan  3 02:20:10 patrickchen-NUC10i7FNH kernel: [ 2011.843039] litepcie 0000:06:00.0: [Probing device]
    Jan  3 02:20:10 patrickchen-NUC10i7FNH kernel: [ 2011.843054] litepcie 0000:06:00.0: enabling device (0000 -> 0002)
    Jan  3 02:20:10 patrickchen-NUC10i7FNH kernel: [ 2011.863504] litepcie 0000:06:00.0: Version 
    Jan  3 02:20:10 patrickchen-NUC10i7FNH kernel: [ 2011.863583] litepcie 0000:06:00.0: 1 MSI IRQs allocated.
    Jan  3 02:20:10 patrickchen-NUC10i7FNH kernel: [ 2011.863595] litepcie 0000:06:00.0: Creating /dev/litepcie0
    Jan  3 02:20:10 patrickchen-NUC10i7FNH kernel: [ 2011.866648] liteuart.1: ttyLXU0 at MMIO 0x0 (irq = 0, base_baud = 0) is a liteuart
    Jan  3 02:20:28 patrickchen-NUC10i7FNH gnome-shell[1697]: libinput error: event10 - MX Keys Keyboard: client bug: event processing lagging behind by 29ms, your system is too slow
    Jan  3 02:20:46 patrickchen-NUC10i7FNH nautilus[4678]: Called "net usershare info" but it failed: Failed to execute child process “net” (No such file or directory)
    Jan  3 02:20:52 patrickchen-NUC10i7FNH rtkit-daemon[934]: Supervising 7 threads of 4 processes of 1 users.
    Jan  3 02:20:52 patrickchen-NUC10i7FNH rtkit-daemon[934]: Supervising 7 threads of 4 processes of 1 users.
    Jan  3 02:21:32 patrickchen-NUC10i7FNH gnome-shell[1697]: Window manager warning: last_user_time (2093887) is greater than comparison timestamp (2092697).  This most likely represents a buggy client sending inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW.  Trying to work around...
    Jan  3 02:21:32 patrickchen-NUC10i7FNH gnome-shell[1697]: Window manager warning: W20 appears to be one of the offending windows with a timestamp of 2093887.  Working around...
    Jan  3 02:21:35 patrickchen-NUC10i7FNH gnome-shell[1697]: Window manager warning: last_user_time (2094449) is greater than comparison timestamp (2094179).  This most likely represents a buggy client sending inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW.  Trying to work around...
    Jan  3 02:21:35 patrickchen-NUC10i7FNH gnome-shell[1697]: Window manager warning: W20 appears to be one of the offending windows with a timestamp of 2094449.  Working around...
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237551] watchdog: BUG: soft lockup - CPU#10 stuck for 26s! [swapper/10:0]
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237557] Modules linked in: liteuart(OE) litepcie(OE) ftdi_sio pcspkr ch341 usbserial rfcomm joydev input_leds hid_generic uhid hid cmac algif_hash algif_skcipher af_alg snd_hda_codec_hdmi snd_sof_pci_intel_cnl snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation soundwire_cadence snd_sof_intel_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof snd_soc_hdac_hda snd_hda_ext_core snd_ctl_led snd_soc_acpi_intel_match snd_hda_codec_realtek snd_soc_acpi soundwire_bus snd_hda_codec_generic bnep ledtrig_audio snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine intel_rapl_msr intel_rapl_common snd_hda_intel x86_pkg_temp_thermal snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec intel_powerclamp snd_hda_core snd_hwdep coretemp snd_pcm kvm_intel snd_seq_midi binfmt_misc iwlmvm snd_seq_midi_event kvm tps6598x i915 mei_hdcp typec mac80211 snd_rawmidi crct10dif_pclmul ghash_clmulni_intel libarc4 btusb ttm btrtl snd_seq btbcm aesni_intel drm_kms_helper nls_iso8859_1 crypto_simd btintel
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237592]  cryptd snd_seq_device cec iwlwifi bluetooth snd_timer rc_core rapl i2c_algo_bit fb_sys_fops intel_cstate intel_wmi_thunderbolt wmi_bmof snd ecdh_generic syscopyarea cfg80211 ee1004 ecc soundcore sysfillrect sysimgblt mei_me intel_pch_thermal mei serial_multi_instantiate mac_hid acpi_tad acpi_pad sch_fq_codel msr parport_pc ppdev lp drm parport ramoops pstore_blk reed_solomon pstore_zone efi_pstore ip_tables x_tables autofs4 sdhci_pci cqhci nvme i2c_i801 crc32_pclmul e1000e thunderbolt sdhci nvme_core i2c_smbus intel_lpss_pci xhci_pci ahci intel_lpss libahci idma64 xhci_pci_renesas wmi video pinctrl_cannonlake
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237620] CPU: 10 PID: 0 Comm: swapper/10 Tainted: G           OE     5.15.0-56-generic #62-Ubuntu
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237622] Hardware name: Intel(R) Client Systems NUC10i7FNH/NUC10i7FNB, BIOS FNCML357.0055.2021.1202.1748 12/02/2021
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237623] RIP: 0010:liteuart_timer+0x8d/0x100 [liteuart]
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237628] Code: ff 00 00 00 00 45 31 c0 44 89 e9 31 d2 be 01 00 00 00 4c 89 ff e8 c3 08 b0 c5 49 8b bc 24 f0 fe ff ff e8 36 46 ae c5 41 8b 06 <84> c0 74 9d 41 8b 84 24 40 ff ff ff 83 f8 06 7f 40 b8 01 00 00 00
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237629] RSP: 0018:ffffb65ac037ce80 EFLAGS: 00000202
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237631] RAX: 0000000000000000 RBX: ffffb65ac3d06820 RCX: ffff8bc41cfe3a10
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237632] RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffff8bc400051000
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237633] RBP: ffffb65ac037cea8 R08: 0000000000000001 R09: ffffffff886898d8
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237633] R10: 0000000000000003 R11: 000000000000000a R12: ffff8bc417318200
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237634] R13: 0000000000000000 R14: ffffb65ac3d06828 R15: ffff8bc417318028
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237635] FS:  0000000000000000(0000) GS:ffff8bc7b0e80000(0000) knlGS:0000000000000000
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237636] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237637] CR2: 00007f5eb5c06658 CR3: 0000000268e10003 CR4: 00000000003706e0
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237638] Call Trace:
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237639]  <IRQ>
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237641]  ? liteuart_startup+0x70/0x70 [liteuart]
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237643]  call_timer_fn+0x29/0x120
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237646]  __run_timers.part.0+0x1e3/0x270
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237648]  ? ktime_get+0x43/0xc0
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237650]  ? lapic_next_deadline+0x2c/0x40
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237652]  ? clockevents_program_event+0xaa/0x130
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237655]  run_timer_softirq+0x2a/0x60
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237656]  __do_softirq+0xd6/0x2e7
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237659]  irq_exit_rcu+0x94/0xc0
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237662]  sysvec_apic_timer_interrupt+0x80/0x90
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237664]  </IRQ>
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237665]  <TASK>
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237665]  asm_sysvec_apic_timer_interrupt+0x1b/0x20
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237666] RIP: 0010:cpuidle_enter_state+0xd9/0x620
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237670] Code: 3d 44 d8 d9 78 e8 d7 c2 68 ff 49 89 c7 0f 1f 44 00 00 31 ff e8 18 d0 68 ff 80 7d d0 00 0f 85 61 01 00 00 fb 66 0f 1f 44 00 00 <45> 85 f6 0f 88 6d 01 00 00 4d 63 ee 49 83 fd 09 0f 87 e7 03 00 00
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237671] RSP: 0018:ffffb65ac0163e28 EFLAGS: 00000246
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237672] RAX: ffff8bc7b0eb0b80 RBX: ffffd65abfc80f00 RCX: 0000000000000000
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237672] RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000000
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237673] RBP: ffffb65ac0163e78 R08: 000001e3185d0ca6 R09: 00000000002f5530
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237674] R10: 0000000000000004 R11: 071c71c71c71c71c R12: ffffffff888d40e0
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237675] R13: 0000000000000002 R14: 0000000000000002 R15: 000001e3185d0ca6
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237677]  ? cpuidle_enter_state+0xc8/0x620
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237679]  cpuidle_enter+0x2e/0x50
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237681]  cpuidle_idle_call+0x142/0x1e0
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237683]  do_idle+0x83/0xf0
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237684]  cpu_startup_entry+0x20/0x30
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237685]  start_secondary+0x12a/0x180
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237687]  secondary_startup_64_no_verify+0xc2/0xcb
    Jan  3 02:21:38 patrickchen-NUC10i7FNH kernel: [ 2100.237689]  </TASK>
    Jan  3 02:21:52 patrickchen-NUC10i7FNH rtkit-daemon[934]: Supervising 7 threads of 4 processes of 1 users.
    Jan  3 02:21:52 patrickchen-NUC10i7FNH rtkit-daemon[934]: Supervising 7 threads of 4 processes of 1 users.
    Jan  3 02:21:56 patrickchen-NUC10i7FNH gnome-shell[1697]: Window manager warning: Ping serial 2118249 was reused for window W9, previous use was for window W0.
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237242] watchdog: BUG: soft lockup - CPU#10 stuck for 53s! [swapper/10:0]
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237247] Modules linked in: liteuart(OE) litepcie(OE) ftdi_sio pcspkr ch341 usbserial rfcomm joydev input_leds hid_generic uhid hid cmac algif_hash algif_skcipher af_alg snd_hda_codec_hdmi snd_sof_pci_intel_cnl snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation soundwire_cadence snd_sof_intel_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof snd_soc_hdac_hda snd_hda_ext_core snd_ctl_led snd_soc_acpi_intel_match snd_hda_codec_realtek snd_soc_acpi soundwire_bus snd_hda_codec_generic bnep ledtrig_audio snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine intel_rapl_msr intel_rapl_common snd_hda_intel x86_pkg_temp_thermal snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec intel_powerclamp snd_hda_core snd_hwdep coretemp snd_pcm kvm_intel snd_seq_midi binfmt_misc iwlmvm snd_seq_midi_event kvm tps6598x i915 mei_hdcp typec mac80211 snd_rawmidi crct10dif_pclmul ghash_clmulni_intel libarc4 btusb ttm btrtl snd_seq btbcm aesni_intel drm_kms_helper nls_iso8859_1 crypto_simd btintel
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237320]  cryptd snd_seq_device cec iwlwifi bluetooth snd_timer rc_core rapl i2c_algo_bit fb_sys_fops intel_cstate intel_wmi_thunderbolt wmi_bmof snd ecdh_generic syscopyarea cfg80211 ee1004 ecc soundcore sysfillrect sysimgblt mei_me intel_pch_thermal mei serial_multi_instantiate mac_hid acpi_tad acpi_pad sch_fq_codel msr parport_pc ppdev lp drm parport ramoops pstore_blk reed_solomon pstore_zone efi_pstore ip_tables x_tables autofs4 sdhci_pci cqhci nvme i2c_i801 crc32_pclmul e1000e thunderbolt sdhci nvme_core i2c_smbus intel_lpss_pci xhci_pci ahci intel_lpss libahci idma64 xhci_pci_renesas wmi video pinctrl_cannonlake
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237347] CPU: 10 PID: 0 Comm: swapper/10 Tainted: G           OEL    5.15.0-56-generic #62-Ubuntu
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237366] Hardware name: Intel(R) Client Systems NUC10i7FNH/NUC10i7FNB, BIOS FNCML357.0055.2021.1202.1748 12/02/2021
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237367] RIP: 0010:liteuart_timer+0x8d/0x100 [liteuart]
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237371] Code: ff 00 00 00 00 45 31 c0 44 89 e9 31 d2 be 01 00 00 00 4c 89 ff e8 c3 08 b0 c5 49 8b bc 24 f0 fe ff ff e8 36 46 ae c5 41 8b 06 <84> c0 74 9d 41 8b 84 24 40 ff ff ff 83 f8 06 7f 40 b8 01 00 00 00
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237372] RSP: 0018:ffffb65ac037ce80 EFLAGS: 00000202
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237373] RAX: 0000000000000000 RBX: ffffb65ac3d06820 RCX: 0000000000030b80
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237374] RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffff8bc400051000
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237375] RBP: ffffb65ac037cea8 R08: 0000000000000001 R09: 0000000000000008
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237376] R10: 0000000000000002 R11: 000000000000000a R12: ffff8bc417318200
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237376] R13: 0000000000000000 R14: ffffb65ac3d06828 R15: ffff8bc417318028
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237377] FS:  0000000000000000(0000) GS:ffff8bc7b0e80000(0000) knlGS:0000000000000000
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237378] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237379] CR2: 00007f5eb5c06658 CR3: 0000000268e10003 CR4: 00000000003706e0
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237380] Call Trace:
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237381]  <IRQ>
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237382]  ? liteuart_startup+0x70/0x70 [liteuart]
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237384]  call_timer_fn+0x29/0x120
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237387]  __run_timers.part.0+0x1e3/0x270
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237388]  ? ktime_get+0x43/0xc0
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237390]  ? lapic_next_deadline+0x2c/0x40
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237392]  ? clockevents_program_event+0xaa/0x130
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237394]  run_timer_softirq+0x2a/0x60
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237395]  __do_softirq+0xd6/0x2e7
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237397]  irq_exit_rcu+0x94/0xc0
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237400]  sysvec_apic_timer_interrupt+0x80/0x90
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237402]  </IRQ>
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237402]  <TASK>
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237403]  asm_sysvec_apic_timer_interrupt+0x1b/0x20
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237404] RIP: 0010:cpuidle_enter_state+0xd9/0x620
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237407] Code: 3d 44 d8 d9 78 e8 d7 c2 68 ff 49 89 c7 0f 1f 44 00 00 31 ff e8 18 d0 68 ff 80 7d d0 00 0f 85 61 01 00 00 fb 66 0f 1f 44 00 00 <45> 85 f6 0f 88 6d 01 00 00 4d 63 ee 49 83 fd 09 0f 87 e7 03 00 00
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237407] RSP: 0018:ffffb65ac0163e28 EFLAGS: 00000246
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237408] RAX: ffff8bc7b0eb0b80 RBX: ffffd65abfc80f00 RCX: 0000000000000000
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237409] RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000000
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237410] RBP: ffffb65ac0163e78 R08: 000001e3185d0ca6 R09: 00000000002f5530
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237410] R10: 0000000000000004 R11: 071c71c71c71c71c R12: ffffffff888d40e0
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237411] R13: 0000000000000002 R14: 0000000000000002 R15: 000001e3185d0ca6
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237413]  ? cpuidle_enter_state+0xc8/0x620
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237414]  cpuidle_enter+0x2e/0x50
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237416]  cpuidle_idle_call+0x142/0x1e0
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237417]  do_idle+0x83/0xf0
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237419]  cpu_startup_entry+0x20/0x30
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237420]  start_secondary+0x12a/0x180
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237421]  secondary_startup_64_no_verify+0xc2/0xcb
    Jan  3 02:22:06 patrickchen-NUC10i7FNH kernel: [ 2128.237423]  </TASK>
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877170] rcu: INFO: rcu_sched self-detected stall on CPU
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877174] rcu: 	10-....: (1 GPs behind) idle=2ff/1/0x4000000000000004 softirq=65947/65952 fqs=7037 
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877176] 	(t=15000 jiffies g=142785 q=9974)
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877178] NMI backtrace for cpu 10
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877179] CPU: 10 PID: 0 Comm: swapper/10 Tainted: G           OEL    5.15.0-56-generic #62-Ubuntu
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877181] Hardware name: Intel(R) Client Systems NUC10i7FNH/NUC10i7FNB, BIOS FNCML357.0055.2021.1202.1748 12/02/2021
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877181] Call Trace:
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877210]  <IRQ>
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877212]  show_stack+0x52/0x5c
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877215]  dump_stack_lvl+0x4a/0x63
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877219]  dump_stack+0x10/0x16
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877221]  nmi_cpu_backtrace.cold+0x4d/0x93
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877223]  ? lapic_can_unplug_cpu+0x90/0x90
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877226]  nmi_trigger_cpumask_backtrace+0xec/0x100
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877229]  arch_trigger_cpumask_backtrace+0x19/0x20
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877231]  trigger_single_cpu_backtrace+0x44/0x4f
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877234]  rcu_dump_cpu_stacks+0x102/0x149
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877235]  print_cpu_stall.cold+0x2f/0xe2
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877237]  ? timekeeping_update+0xf7/0x150
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877240]  check_cpu_stall+0x109/0x270
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877242]  rcu_sched_clock_irq+0x9a/0x250
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877261]  update_process_times+0x94/0xd0
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877262]  ? tick_nohz_handler+0xb0/0xb0
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877264]  tick_sched_handle+0x29/0x70
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877265]  ? tick_nohz_handler+0xb0/0xb0
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877266]  tick_sched_timer+0x8c/0xc0
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877267]  __hrtimer_run_queues+0x106/0x210
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877268]  hrtimer_interrupt+0x101/0x220
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877287]  __sysvec_apic_timer_interrupt+0x5e/0xe0
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877288]  sysvec_apic_timer_interrupt+0x3e/0x90
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877290]  asm_sysvec_apic_timer_interrupt+0x1b/0x20
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877292] RIP: 0010:liteuart_timer+0x8d/0x100 [liteuart]
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877296] Code: ff 00 00 00 00 45 31 c0 44 89 e9 31 d2 be 01 00 00 00 4c 89 ff e8 c3 08 b0 c5 49 8b bc 24 f0 fe ff ff e8 36 46 ae c5 41 8b 06 <84> c0 74 9d 41 8b 84 24 40 ff ff ff 83 f8 06 7f 40 b8 01 00 00 00
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877297] RSP: 0018:ffffb65ac037ce80 EFLAGS: 00000202
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877298] RAX: 0000000000000000 RBX: ffffb65ac3d06820 RCX: 0000000000030b80
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877299] RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffff8bc400051000
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877300] RBP: ffffb65ac037cea8 R08: 0000000000000001 R09: 0000000000000008
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877301] R10: 0000000000000006 R11: 000000000000000a R12: ffff8bc417318200
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877301] R13: 0000000000000000 R14: ffffb65ac3d06828 R15: ffff8bc417318028
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877303]  ? liteuart_startup+0x70/0x70 [liteuart]
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877304]  call_timer_fn+0x29/0x120
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877305]  __run_timers.part.0+0x1e3/0x270
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877306]  ? ktime_get+0x43/0xc0
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877308]  ? lapic_next_deadline+0x2c/0x40
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877309]  ? clockevents_program_event+0xaa/0x130
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877311]  run_timer_softirq+0x2a/0x60
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877312]  __do_softirq+0xd6/0x2e7
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877314]  irq_exit_rcu+0x94/0xc0
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877316]  sysvec_apic_timer_interrupt+0x80/0x90
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877318]  </IRQ>
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877318]  <TASK>
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877319]  asm_sysvec_apic_timer_interrupt+0x1b/0x20
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877320] RIP: 0010:cpuidle_enter_state+0xd9/0x620
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877322] Code: 3d 44 d8 d9 78 e8 d7 c2 68 ff 49 89 c7 0f 1f 44 00 00 31 ff e8 18 d0 68 ff 80 7d d0 00 0f 85 61 01 00 00 fb 66 0f 1f 44 00 00 <45> 85 f6 0f 88 6d 01 00 00 4d 63 ee 49 83 fd 09 0f 87 e7 03 00 00
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877323] RSP: 0018:ffffb65ac0163e28 EFLAGS: 00000246
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877324] RAX: ffff8bc7b0eb0b80 RBX: ffffd65abfc80f00 RCX: 0000000000000000
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877325] RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000000
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877325] RBP: ffffb65ac0163e78 R08: 000001e3185d0ca6 R09: 00000000002f5530
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877326] R10: 0000000000000004 R11: 071c71c71c71c71c R12: ffffffff888d40e0
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877327] R13: 0000000000000002 R14: 0000000000000002 R15: 000001e3185d0ca6
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877328]  ? cpuidle_enter_state+0xc8/0x620
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877329]  cpuidle_enter+0x2e/0x50
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877331]  cpuidle_idle_call+0x142/0x1e0
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877332]  do_idle+0x83/0xf0
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877334]  cpu_startup_entry+0x20/0x30
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877335]  start_secondary+0x12a/0x180
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877336]  secondary_startup_64_no_verify+0xc2/0xcb
    Jan  3 02:22:13 patrickchen-NUC10i7FNH kernel: [ 2134.877338]  </TASK>
    
    

    Thank you!

    question bug? 
    opened by PatrickChenHZ 2
Owner
null
BSD-licensed Yamaha FM sound cores (OPM, OPN, OPL, and others)

ymfm ymfm is a collection of BSD-licensed Yamaha FM sound cores (OPM, OPN, OPL, and others), written by Aaron Giles Supported environments This code s

Aaron Giles 163 Dec 31, 2022
This repo contains source code of our paper presented in IROS2021 "Single-Shot is Enough: Panoramic Infrastructure Based Calibration of Multiple Cameras and 3D LiDARs"

Single-Shot is Enough: Panoramic Infrastructure Based Calibration of Multiple Cameras and 3D LiDARs Updates [2021/09/01] first commit, source code of

Alibaba 83 Dec 19, 2022
A collection of command line tools for ARM devices with Allwinner SoCs.

sunxi-tools Copyright (C) 2012 Alejandro Mery [email protected] For a full list of contributors, see this link or use the command git shortlog -se --no-m

Free/Open Source Software for Allwinner SoCs (A10/A13/A10s/A20/A31/...) 467 Jan 2, 2023
A simple library that helps Android developers to execute JavaScript code from Android native side easily without using Webview.

AndroidJSModule A simple library that helps Android developers to execute JavaScript code from Android native side easily without using Webview. Insta

Hung Nguyen 5 May 24, 2022
DICOM images and volumes viewer with advanced processing infrastructure (WPF, ITK, VTK)

DicomViewer DICOM images and volumes viewer with advanced processing infrastructure Stack: WPF (C#) ITK (C++) VTK (C++) Structure: DicomViewer - WPF a

Paweł Piorun 1 Sep 8, 2022
Hierarchical Engine for Large-scale Infrastructure Co-Simulation (HELICS)

A multi-language, cross-platform library that enables different simulators to easily exchange data and stay synchronized in time. Scalable from two si

GMLC-TDC 83 Dec 23, 2022
64-bit LKM Rootkit builder based on yaml prescription

1337kit - LKM Rootkit Builder About project 1337kit is 64-bit LKM Rootkit builder based on yaml prescription Fully tested on: Linux 5.11.0-34-generic

Lukas Balazik 18 Dec 28, 2022
Arduino core for GD32 devices, community developed, based on original GigaDevice's core

GD32 Arduino Core (New) This is a Arduino core is based off of the original GigaDevice core that was provided by the company in early June 2021 (see h

null 46 Dec 24, 2022
Advanced discord token grabber builder with GUI

Token-Grabber-Builder Advanced discord token grabber builder with GUI Screenshot Features Hidden console High execution speed Grab discord tokens Stea

RadonCoding 2 Dec 2, 2021
Buffer reader/builder for C

ubuf ubuf is a simple interface for reading/writing binary data. It handles automatically expanding the buffer and byte order for you, but that's abou

adrian 2 Jan 10, 2022
Tiny FEL tools for allwinner SOC, support RISC-V D1 chip

XFEL Tiny FEL tools for allwinner SOC, support RISC-V D1 chip. How to build The xfel tools depends on the libusb-1.0 library, you need to install libu

xboot.org 132 Dec 30, 2022
Port of MIT's xv6 OS to the Nezha RISC-V board with Allwinner D1 SoC

xv6 is a re-implementation of Dennis Ritchie's and Ken Thompson's Unix Version 6 (v6). xv6 loosely follows the structure and style of v6, but is impl

Michael Engel 62 Dec 12, 2022
Porting RT-Thread for Gowin GW1NSR-4C Soc GCC version

Porting RT-Thread for Gowin GW1NSR-4C Soc GCC version Hello everyone, this project based on RT-THREAD NANO 3.1.5 and GOWIN GW1NSR-4C Soc chip. The com

Ray 3 Apr 23, 2022
Kernel with ARM/KVM for SM-A600G (Samsung Galaxy A6) with Exynos7870 SoC

Kernel source for SM-A600G (Samsung Galaxy A6 with exynos7870) with KVM support. Warning: Super long text ahead, be careful not to mess up your brain

@raspiduino 6 Sep 20, 2022
Risc-V RV32IMAFC + 80s ERA SoC (bitmap + GPU, sprites, tilemaps)

A simple (no interrupts or exceptions/traps), Risc-V RV32IMAFC CPU, with a pseudo SMT (dual thread) capability. The display is similar to the 8-bit era machines, along with audio, SDCARD read support, UART and PS/2 keyboard input.

Rob S 17 Jun 3, 2022
This repository is meant to host the core files needed to create a Beacon Object File for use with Cobalt Strike

BOF Template This repository is meant to host the core files needed to create a Beacon Object File for use with Cobalt Strike. A Beacon Object File (B

Cobalt Strike 42 Nov 9, 2022
Create a calculator of any kind in any language, create a pr.

calculators Create a calculator of any kind in any language, create a pr. Create a calculator of any type using the programming language of your choic

Akshay Gautam 2 Oct 21, 2022
Pty for Flutter. Provides the ability to create processes with pseudo terminal file descriptors.

flutter_pty This is an experimental package to explore the possibilities of using native code to implement PTY instead of pure FFI and blocking isolat

null 7 Nov 24, 2022
Easily hook WIN32 x64 functions

About Library for easy hooking of arbitrary functions in WIN32 x64 executables. Only requires target function address. Disassembles the function prolo

tcpie 17 Jun 12, 2022