aboutsummaryrefslogtreecommitdiff
path: root/include/hw/riscv/sifive_u.h
AgeCommit message (Collapse)Author
2020-08-21hw/riscv: sifive_u: Add a dummy L2 cache controller deviceBin Meng
It is enough to simply map the SiFive FU540 L2 cache controller into the MMIO space using create_unimplemented_device(), with an FDT fragment generated, to make the latest upstream U-Boot happy. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1595227748-24720-1-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-06-19hw/riscv: sifive_u: Add a dummy DDR memory controller deviceBin Meng
It is enough to simply map the SiFive FU540 DDR memory controller into the MMIO space using create_unimplemented_device(), to make the upstream U-Boot v2020.07 DDR memory initialization codes happy. Note we do not generate device tree fragment for the DDR memory controller. Since the controller data in device tree consumes a very large space (see fu540-hifive-unleashed-a00-ddr.dtsi in the U-Boot source), and it is only needed by U-Boot SPL but not any operating system, we choose not to generate the fragment here. This also means when testing with U-Boot SPL, the device tree has to come from U-Boot SPL itself, but not the one generated by QEMU on the fly. The memory has to be set to 8GiB to match the real HiFive Unleashed board when invoking QEMU (-m 8G). With this commit, QEMU can boot U-Boot SPL built for SiFive FU540 all the way up to loading U-Boot proper from MMC: $ qemu-system-riscv64 -nographic -M sifive_u,msel=6 -m 8G -bios u-boot-spl.bin U-Boot SPL 2020.07-rc3-00208-g88bd5b1 (Jun 08 2020 - 20:16:10 +0800) Trying to boot from MMC1 Unhandled exception: Load access fault EPC: 0000000008009be6 TVAL: 0000000010050014 The above exception is expected because QSPI is unsupported yet. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1592268641-7478-6-git-send-email-bmeng.cn@gmail.com Message-Id: <1592268641-7478-6-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-06-19hw/riscv: sifive_u: Support different boot source per MSEL pin stateBin Meng
SiFive FU540 SoC supports booting from several sources, which are controlled using the Mode Select (MSEL[3:0]) pins on the chip. Typically, the boot process runs through several stages before it begins execution of user-provided programs. The SoC supports booting from memory-mapped QSPI flash, which is how start_in_flash property is used for at present. This matches MSEL = 1 configuration (QSPI0). Typical booting flows involve the Zeroth Stage Boot Loader (ZSBL). It's not necessary for QEMU to implement the full ZSBL ROM codes, because we know ZSBL downloads the next stage program into the L2 LIM at address 0x8000000 and executes from there. We can bypass the whole ZSBL execution and use "-bios" to load the next stage program directly if MSEL indicates a ZSBL booting flow. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1592268641-7478-4-git-send-email-bmeng.cn@gmail.com Message-Id: <1592268641-7478-4-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-06-19hw/riscv: sifive_u: Add a new property msel for MSEL pin stateBin Meng
On SiFive FU540 SoC, the value stored at physical address 0x1000 stores the MSEL pin state that is used to control the next boot location that ROM codes jump to. Add a new property msel to sifive_u machine for this. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1591625864-31494-12-git-send-email-bmeng.cn@gmail.com Message-Id: <1591625864-31494-12-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-06-19hw/riscv: sifive_u: Hook a GPIO controllerBin Meng
SiFive FU540 SoC integrates a GPIO controller with 16 GPIO lines. This hooks the exsiting SiFive GPIO model to the SoC, and adds its device tree data as well. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1591625864-31494-8-git-send-email-bmeng.cn@gmail.com Message-Id: <1591625864-31494-8-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-06-15riscv: Fix type of SiFive[EU]SocState, member parent_objMarkus Armbruster
Device "riscv.sifive.e.soc" is a direct subtype of TYPE_DEVICE, but its instance struct SiFiveESoCState's member @parent_obj is SysBusDevice instead of DeviceState. Correct that. Same for "riscv.sifive.u.soc"'s instance struct SiFiveUSoCState. Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Alistair Francis <Alistair.Francis@wdc.com> Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Cc: qemu-riscv@nongnu.org Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20200609122339.937862-21-armbru@redhat.com>
2020-04-29riscv/sifive_u: Add a serial property to the sifive_u machineBin Meng
At present the board serial number is hard-coded to 1, and passed to OTP model during initialization. Firmware (FSBL, U-Boot) uses the serial number to generate a unique MAC address for the on-chip ethernet controller. When multiple QEMU 'sifive_u' instances are created and connected to the same subnet, they all have the same MAC address hence it creates a unusable network. A new "serial" property is introduced to specify the board serial number. When not given, the default serial number 1 is used. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1573916930-19068-1-git-send-email-bmeng.cn@gmail.com> [ Changed by AF: - Use the SoC's serial property to pass the info to the SoC - Fixup commit title - Rebase on file restructuring ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-04-29riscv/sifive_u: Add a serial property to the sifive_u SoCAlistair Francis
At present the board serial number is hard-coded to 1, and passed to OTP model during initialization. Firmware (FSBL, U-Boot) uses the serial number to generate a unique MAC address for the on-chip ethernet controller. When multiple QEMU 'sifive_u' instances are created and connected to the same subnet, they all have the same MAC address hence it creates a unusable network. A new "serial" property is introduced to the sifive_u SoC to specify the board serial number. When not given, the default serial number 1 is used. Suggested-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-10-28riscv/sifive_u: Add the start-in-flash propertyAlistair Francis
Add a property that when set to true QEMU will jump from the ROM code to the start of flash memory instead of DRAM which is the default behaviour. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-10-28riscv/sifive_u: Manually define the machineAlistair Francis
Instead of using the DEFINE_MACHINE() macro to define the machine let's do it manually. This allows us to specify machine properties. This patch is no functional change. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-10-28riscv/sifive_u: Add QSPI memory regionAlistair Francis
The HiFive Unleashed uses is25wp256 SPI NOR flash. There is currently no model of this in QEMU, so to allow boot firmware developers to use QEMU to target the Unleashed let's add a chunk of memory to represent the QSPI0 memory mapped flash. This can be targeted using QEMU's -device loader command line option. In the future we can look at adding a model for the is25wp256 flash. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-10-28riscv/sifive_u: Add L2-LIM cache memoryAlistair Francis
On reset only a single L2 cache way is enabled, the others are exposed as memory that can be used by early boot firmware. This L2 region is generally disabled using the WayEnable register at a later stage in the boot process. To allow firmware to target QEMU and the HiFive Unleashed let's add the L2 LIM (LooselyIntegrated Memory). Ideally we would want to adjust the size of this chunk of memory as the L2 Cache Controller WayEnable register is incremented. Unfortunately I don't see a nice way to handle reducing or blocking out the L2 LIM while still allowing it be re returned to all enabled from a reset. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-10-28riscv: hw: Drop "clock-frequency" property of cpu nodesBin Meng
The "clock-frequency" property of cpu nodes isn't required. Drop it. This is to keep in sync with Linux kernel commit below: https://patchwork.kernel.org/patch/11133031/ Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-09-17riscv: sifive_u: Remove handcrafted clock nodes for UART and ethernetBin Meng
In the past we did not have a model for PRCI, hence two handcrafted clock nodes ("/soc/ethclk" and "/soc/uartclk") were created for the purpose of supplying hard-coded clock frequencies. But now since we have added the PRCI support in QEMU, we don't need them any more. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-09-17riscv: sifive_u: Fix broken GEM supportBin Meng
At present the GEM support in sifive_u machine is seriously broken. The GEM block register base was set to a weird number (0x100900FC), which for no way could work with the cadence_gem model in QEMU. Not like other GEM variants, the FU540-specific GEM has a management block to control 10/100/1000Mbps link speed changes, that is mapped to 0x100a0000. We can simply map it into MMIO space without special handling using create_unimplemented_device(). Update the GEM node compatible string to use the official name used by the upstream Linux kernel, and add the management block reg base & size to the <reg> property encoding. Tested with upstream U-Boot and Linux kernel MACB drivers. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-09-17riscv: sifive_u: Instantiate OTP memory with a serial numberBin Meng
This adds an OTP memory with a given serial number to the sifive_u machine. With such support, the upstream U-Boot for sifive_fu540 boots out of the box on the sifive_u machine. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-09-17riscv: sifive_u: Update UART base addresses and IRQsBin Meng
This updates the UART base address and IRQs to match the hardware. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Jonathan Behrens <fintelia@gmail.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Chih-Min Chao <chihmin.chao@sifive.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-09-17riscv: sifive_u: Add PRCI block to the SoCBin Meng
Add PRCI mmio base address and size mappings to sifive_u machine, and generate the corresponding device tree node. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-09-17riscv: sifive_u: Generate hfclk and rtcclk nodesBin Meng
To keep in sync with Linux kernel device tree, generate hfclk and rtcclk nodes in the device tree, to be referenced by PRCI node. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-09-17riscv: sifive_u: Update hart configuration to reflect the real FU540 SoCBin Meng
The FU540-C000 includes a 64-bit E51 RISC-V core and four 64-bit U54 RISC-V cores. Currently the sifive_u machine only populates 4 U54 cores. Update the max cpu number to 5 to reflect the real hardware, by creating 2 CPU clusters as containers for RISC-V hart arrays to populate heterogeneous harts. The cpu nodes in the generated DTS have been updated as well. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-09-17riscv: sifive_u: Set the minimum number of cpus to 2Bin Meng
It is not useful if we only have one management CPU. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> [Palmer: Set default CPUs to 2] Reviewed-by: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-09-17riscv: Add a sifive_cpu.h to include both E and U cpu type definesBin Meng
Group SiFive E and U cpu type defines into one header file. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-08-16include: Make headers more self-containedMarkus Armbruster
Back in 2016, we discussed[1] rules for headers, and these were generally liked: 1. Have a carefully curated header that's included everywhere first. We got that already thanks to Peter: osdep.h. 2. Headers should normally include everything they need beyond osdep.h. If exceptions are needed for some reason, they must be documented in the header. If all that's needed from a header is typedefs, put those into qemu/typedefs.h instead of including the header. 3. Cyclic inclusion is forbidden. This patch gets include/ closer to obeying 2. It's actually extracted from my "[RFC] Baby steps towards saner headers" series[2], which demonstrates a possible path towards checking 2 automatically. It passes the RFC test there. [1] Message-ID: <87h9g8j57d.fsf@blackfin.pond.sub.org> https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg03345.html [2] Message-Id: <20190711122827.18970-1-armbru@redhat.com> https://lists.nongnu.org/archive/html/qemu-devel/2019-07/msg02715.html Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20190812052359.30071-2-armbru@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-04-04riscv: plic: Fix incorrect irq calculationAlistair Francis
This patch fixes four different things, to maintain bisectability they have been merged into a single patch. The following fixes are below: sifive_plic: Fix incorrect irq calculation The irq is incorrectly calculated to be off by one. It has worked in the past as the priority_base offset has also been set incorrectly. We are about to fix the priority_base offset so first first the irq calculation. sifive_u: Fix PLIC priority base offset and numbering According to the FU540 manual the PLIC source priority address starts at an offset of 0x04 and not 0x00. The same manual also specifies that the PLIC only has 53 source priorities. Fix these two incorrect header files. We also need to over extend the plic_gpios[] array as the PLIC sources count from 1 and not 0. riscv: sifive_e: Fix PLIC priority base offset According to the FE31 manual the PLIC source priority address starts at an offset of 0x04 and not 0x00. riscv: virt: Fix PLIC priority base offset Update the virt offsets based on the newly updated SiFive U and SiFive E offsets. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2018-12-20sifive_u: Add clock DT node for GEM ethernetAnup Patel
The GEM ethernet on SiFive unleashed has fixed input clock of 125MHz as-per SiFive FU540 manual. This patch updates FDT generation for QEMU sifive_u machine to provide fixed-rate clock for GEM ethernet. Signed-off-by: Anup Patel <anup@brainfault.org> Signed-off-by: Anup Patel <anup.patel@wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2018-07-05hw/riscv/sifive_u: Connect the Cadence GEM Ethernet deviceAlistair Francis
Connect the Cadence GEM ethernet device. This also requires us to expose the plic interrupt lines. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Michael Clark <mjc@sifive.com>
2018-07-05hw/riscv/sifive_u: Create a SiFive U SoC objectAlistair Francis
Create a SiFive Unleashed U54 SoC and use that in the sifive_u machine. We leave the SoC, RAM, device tree and reset/fdt loading as part of the machine. All the other device creation has been moved to the SoC. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Michael Clark <mjc@sifive.com>
2018-05-06RISC-V: Remove unused class definitionsMichael Clark
Removes a whole lot of unnecessary boilerplate code. Machines don't need to be objects. The expansion of the SOC object model for the RISC-V machines will happen in the future as SiFive plans to add their FE310 and FU540 SOCs to QEMU. However, it seems that this present boilerplate is complete unnecessary. Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Signed-off-by: Michael Clark <mjc@sifive.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
2018-05-06RISC-V: Replace hardcoded constants with enum valuesMichael Clark
The RISC-V device-tree code has a number of hard-coded constants and this change moves them into header enums. Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Signed-off-by: Michael Clark <mjc@sifive.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
2018-03-07SiFive Freedom U Series RISC-V MachineMichael Clark
This provides a RISC-V Board compatible with the the SiFive Freedom U SDK. The following machine is implemented: - 'sifive_u'; CLINT, PLIC, UART, device-tree Acked-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Michael Clark <mjc@sifive.com>