summaryrefslogtreecommitdiff
path: root/board/emulation/qemu-riscv/qemu-riscv.c
AgeCommit message (Collapse)Author
2019-12-02common: Move some board functions out of common.hSimon Glass
A number of board function belong in init.h with the others. Move them. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2019-08-26riscv: qemu: add SPL configurationLukas Auer
Add two new configurations (qemu-riscv{32,64}_spl_defconfig) with SPL enabled for RISC-V QEMU. QEMU does not require SPL to run U-Boot. The configurations are meant to help the development of SPL on RISC-V. The configurations enable RAM as the only SPL boot device. Images must be loaded at address 0x80200000. In the default boot flow, U-Boot SPL starts in machine mode, loads the OpenSBI FW_DYNAMIC firmware and U-Boot proper from the supplied FIT image, and starts OpenSBI. U-Boot proper is then started in supervisor mode by OpenSBI. Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Anup Patel <anup.patel@wdc.com>
2019-08-11env: Move env_set_hex() to env.hSimon Glass
Move env_set_hex() over to the new header file along with env_set_addr() which uses it. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2018-11-26riscv: qemu: clear kernel-start/-end in device tree as workaround for BBLLukas Auer
QEMU specifies the location of Linux (supplied with the -kernel argument) in the device tree using the riscv,kernel-start and riscv,kernel-end properties. We currently rely on the SBI implementation of BBL to run Linux and therefore embed Linux as payload in BBL. This causes an issue, because BBL detects the kernel properties in the device tree and ignores the Linux payload as a result. Work around this issue by clearing the kernel properties in the device tree before booting Linux. Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2018-11-26riscv: qemu: detect and boot the kernel passed by QEMULukas Auer
QEMU embeds the location of the kernel image in the device tree. Store this address in the environment as variable kernel_start. It is used in the board-local distro boot command QEMU to boot the kernel with the U-Boot device tree. The QEMU boot command is added as the first boot target device. Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Alexander Graf <agraf@suse.de>
2018-11-26riscv: qemu: use device tree passed by prior boot stageLukas Auer
QEMU provides a device tree, which is passed to U-Boot using register a1. We are now able to directly select the device tree with the configuration CONFIG_OF_PRIOR_STAGE. Replace the hard-coded address in qemu-riscv with it. Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Rick Chen <rick@andestech.com>
2018-11-14riscv: qemu: Enumerate virtio bus during early bootBin Meng
Currently devices on the virtio bus is not automatically enumerated, which means peripherals on the virtio bus are not discovered by their drivers. This uses board_init() to do the virtio enumeration. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-10-03riscv: Add QEMU virt board supportBin Meng
This adds QEMU RISC-V 'virt' board target support, with the hope of helping people easily test U-Boot on RISC-V. The QEMU virt machine models a generic RISC-V virtual machine with support for the VirtIO standard networking and block storage devices. It has CLINT, PLIC, 16550A UART devices in addition to VirtIO and it also uses device-tree to pass configuration information to guest software. It implements RISC-V privileged architecture spec v1.10. Both 32-bit and 64-bit builds are supported. Support is pretty much preliminary, only booting to U-Boot shell with the UART driver on a single core. Booting Linux is not supported yet. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>