summaryrefslogtreecommitdiff
path: root/include/configs/qemu-riscv.h
AgeCommit message (Collapse)Author
2019-06-05riscv: increase the environment size for the qemu-riscv platform to 128kBKarsten Merker
The existing default size of 4kB is too small as the default environment has already nearly that size and defining a single additional environment variable can exceed the available space. Signed-off-by: Karsten Merker <merker@debian.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-05-09riscv: qemu-riscv.h: define CONFIG_PREBOOT (enables extlinux)David Abdurachmanov
- Set fdt_addr variable, which is needed for extlinux to find FDT. Otherwise booting kernel using extlinux results in missing FDT. - Also run fdt addr with FDT address so that fdt commands would work out of the box in U-Boot prompt. This is successfully used by Fedora/RISCV with 5.1-rc3+ kernel using OpenSBI -> U-Boot (S-mode) [extlinux] -> Kernel setup. Signed-off-by: David Abdurachmanov <david.abdurachmanov@gmail.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-05-09riscv: set CONFIG_SYS_BOOTM_LEN to SZ_64MDavid Abdurachmanov
After updating Fedora/RISCV kernel to 5.1-rc3+ the size increased above the current threshold. Looking into HiKey, Dragonboards, etc. seems that SZ_64M is a popular option. This sucessfully boots Fedora/RISCV with 5.1-rc3+ kernel on QEMU 4.0 (master) with OpenSBI -> U-Boot (S-mode) [extlinux] -> Kernel setup. Signed-off-by: David Abdurachmanov <david.abdurachmanov@gmail.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-01-15riscv: qemu: define standalone load addressLukas Auer
We need to define the standalone load address to use standalone application on qemu-riscv. Define it and set it equal to CONFIG_SYS_LOAD_ADDR. To not overwrite it, change the assigned of CONFIG_STANDALONE_LOAD_ADDR in arch/riscv/config.mk to a conditional one. 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>
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: enable distro bootLukas Auer
Enable distro boot on the qemu-riscv32/64 boards. Supported boot target devices are VirtIO and DHCP. 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: support booting LinuxLukas Auer
Support booting Linux (as payload of BBL) from FIT images. For this, the default CONFIG_SYS_BOOTM_LEN is increased to 16 MB, and the environment variables fdt_high and initrd_high are set to mark the device tree and initrd as in-place. Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
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>