2019-06-25 01:11:49 +03:00
|
|
|
/*
|
|
|
|
* QEMU RISC-V Boot Helper
|
|
|
|
*
|
|
|
|
* Copyright (c) 2017 SiFive, Inc.
|
|
|
|
* Copyright (c) 2019 Alistair Francis <alistair.francis@wdc.com>
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify it
|
|
|
|
* under the terms and conditions of the GNU General Public License,
|
|
|
|
* version 2 or later, as published by the Free Software Foundation.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope it will be useful, but WITHOUT
|
|
|
|
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
|
|
|
|
* more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License along with
|
|
|
|
* this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "qemu/osdep.h"
|
2020-10-28 14:36:57 +03:00
|
|
|
#include "qemu/datadir.h"
|
2019-06-25 01:11:49 +03:00
|
|
|
#include "qemu/units.h"
|
|
|
|
#include "qemu/error-report.h"
|
|
|
|
#include "exec/cpu-defs.h"
|
2019-08-12 08:23:52 +03:00
|
|
|
#include "hw/boards.h"
|
2019-06-25 01:11:49 +03:00
|
|
|
#include "hw/loader.h"
|
|
|
|
#include "hw/riscv/boot.h"
|
2020-07-01 21:39:48 +03:00
|
|
|
#include "hw/riscv/boot_opensbi.h"
|
2019-06-25 01:11:49 +03:00
|
|
|
#include "elf.h"
|
2020-07-01 21:39:46 +03:00
|
|
|
#include "sysemu/device_tree.h"
|
2019-07-22 23:20:40 +03:00
|
|
|
#include "sysemu/qtest.h"
|
2022-01-12 11:13:22 +03:00
|
|
|
#include "sysemu/kvm.h"
|
2022-10-25 03:43:21 +03:00
|
|
|
#include "sysemu/reset.h"
|
2019-06-25 01:11:49 +03:00
|
|
|
|
2020-07-01 21:39:46 +03:00
|
|
|
#include <libfdt.h>
|
|
|
|
|
2021-01-16 02:00:27 +03:00
|
|
|
bool riscv_is_32bit(RISCVHartArrayState *harts)
|
2020-10-14 03:17:30 +03:00
|
|
|
{
|
2024-02-03 13:11:09 +03:00
|
|
|
RISCVCPUClass *mcc = RISCV_CPU_GET_CLASS(&harts->harts[0]);
|
|
|
|
return mcc->misa_mxl_max == MXL_RV32;
|
2020-10-14 03:17:30 +03:00
|
|
|
}
|
|
|
|
|
2021-10-22 09:01:30 +03:00
|
|
|
/*
|
|
|
|
* Return the per-socket PLIC hart topology configuration string
|
|
|
|
* (caller must free with g_free())
|
|
|
|
*/
|
|
|
|
char *riscv_plic_hart_config_string(int hart_count)
|
|
|
|
{
|
|
|
|
g_autofree const char **vals = g_new(const char *, hart_count + 1);
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < hart_count; i++) {
|
|
|
|
CPUState *cs = qemu_get_cpu(i);
|
|
|
|
CPURISCVState *env = &RISCV_CPU(cs)->env;
|
|
|
|
|
2022-01-12 11:13:22 +03:00
|
|
|
if (kvm_enabled()) {
|
|
|
|
vals[i] = "S";
|
|
|
|
} else if (riscv_has_ext(env, RVS)) {
|
2021-10-22 09:01:30 +03:00
|
|
|
vals[i] = "MS";
|
|
|
|
} else {
|
|
|
|
vals[i] = "M";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
vals[i] = NULL;
|
|
|
|
|
|
|
|
/* g_strjoinv() obliges us to cast away const here */
|
|
|
|
return g_strjoinv(",", (char **)vals);
|
|
|
|
}
|
|
|
|
|
2021-01-16 02:00:27 +03:00
|
|
|
target_ulong riscv_calc_kernel_start_addr(RISCVHartArrayState *harts,
|
2020-10-14 03:17:33 +03:00
|
|
|
target_ulong firmware_end_addr) {
|
2020-12-16 21:23:08 +03:00
|
|
|
if (riscv_is_32bit(harts)) {
|
2020-10-14 03:17:33 +03:00
|
|
|
return QEMU_ALIGN_UP(firmware_end_addr, 4 * MiB);
|
|
|
|
} else {
|
|
|
|
return QEMU_ALIGN_UP(firmware_end_addr, 2 * MiB);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-12-29 12:18:26 +03:00
|
|
|
const char *riscv_default_firmware_name(RISCVHartArrayState *harts)
|
|
|
|
{
|
|
|
|
if (riscv_is_32bit(harts)) {
|
|
|
|
return RISCV32_BIOS_BIN;
|
|
|
|
}
|
|
|
|
|
|
|
|
return RISCV64_BIOS_BIN;
|
|
|
|
}
|
|
|
|
|
2022-12-29 12:18:27 +03:00
|
|
|
static char *riscv_find_bios(const char *bios_filename)
|
2022-12-29 12:18:25 +03:00
|
|
|
{
|
|
|
|
char *filename;
|
|
|
|
|
2022-12-29 12:18:27 +03:00
|
|
|
filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_filename);
|
2022-12-29 12:18:25 +03:00
|
|
|
if (filename == NULL) {
|
|
|
|
if (!qtest_enabled()) {
|
|
|
|
/*
|
|
|
|
* We only ship OpenSBI binary bios images in the QEMU source.
|
|
|
|
* For machines that use images other than the default bios,
|
|
|
|
* running QEMU test will complain hence let's suppress the error
|
|
|
|
* report for QEMU testing.
|
|
|
|
*/
|
2022-12-29 12:18:27 +03:00
|
|
|
error_report("Unable to find the RISC-V BIOS \"%s\"",
|
|
|
|
bios_filename);
|
2022-12-29 12:18:25 +03:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return filename;
|
|
|
|
}
|
|
|
|
|
2022-12-29 12:18:27 +03:00
|
|
|
char *riscv_find_firmware(const char *firmware_filename,
|
|
|
|
const char *default_machine_firmware)
|
2019-07-16 21:47:25 +03:00
|
|
|
{
|
2022-12-29 12:18:27 +03:00
|
|
|
char *filename = NULL;
|
2019-07-16 21:47:25 +03:00
|
|
|
|
2022-12-29 12:18:27 +03:00
|
|
|
if ((!firmware_filename) || (!strcmp(firmware_filename, "default"))) {
|
2019-07-16 21:47:25 +03:00
|
|
|
/*
|
2020-05-01 15:19:05 +03:00
|
|
|
* The user didn't specify -bios, or has specified "-bios default".
|
|
|
|
* That means we are going to load the OpenSBI binary included in
|
|
|
|
* the QEMU source.
|
2019-07-16 21:47:25 +03:00
|
|
|
*/
|
2022-12-29 12:18:27 +03:00
|
|
|
filename = riscv_find_bios(default_machine_firmware);
|
|
|
|
} else if (strcmp(firmware_filename, "none")) {
|
|
|
|
filename = riscv_find_bios(firmware_filename);
|
2019-07-16 21:47:25 +03:00
|
|
|
}
|
|
|
|
|
2022-12-29 12:18:27 +03:00
|
|
|
return filename;
|
|
|
|
}
|
|
|
|
|
|
|
|
target_ulong riscv_find_and_load_firmware(MachineState *machine,
|
|
|
|
const char *default_machine_firmware,
|
2024-08-17 03:25:02 +03:00
|
|
|
hwaddr *firmware_load_addr,
|
2022-12-29 12:18:27 +03:00
|
|
|
symbol_fn_t sym_cb)
|
|
|
|
{
|
|
|
|
char *firmware_filename;
|
2024-08-17 03:25:02 +03:00
|
|
|
target_ulong firmware_end_addr = *firmware_load_addr;
|
2022-12-29 12:18:27 +03:00
|
|
|
|
|
|
|
firmware_filename = riscv_find_firmware(machine->firmware,
|
|
|
|
default_machine_firmware);
|
|
|
|
|
2019-10-03 19:59:29 +03:00
|
|
|
if (firmware_filename) {
|
2019-07-16 21:47:25 +03:00
|
|
|
/* If not "none" load the firmware */
|
2020-10-14 03:17:28 +03:00
|
|
|
firmware_end_addr = riscv_load_firmware(firmware_filename,
|
|
|
|
firmware_load_addr, sym_cb);
|
2019-07-16 21:47:25 +03:00
|
|
|
g_free(firmware_filename);
|
|
|
|
}
|
2020-10-14 03:17:28 +03:00
|
|
|
|
|
|
|
return firmware_end_addr;
|
2019-07-16 21:47:25 +03:00
|
|
|
}
|
|
|
|
|
2019-06-25 01:11:52 +03:00
|
|
|
target_ulong riscv_load_firmware(const char *firmware_filename,
|
2024-08-17 03:25:02 +03:00
|
|
|
hwaddr *firmware_load_addr,
|
2020-04-27 11:06:42 +03:00
|
|
|
symbol_fn_t sym_cb)
|
2019-06-25 01:11:52 +03:00
|
|
|
{
|
2021-11-11 17:11:40 +03:00
|
|
|
uint64_t firmware_entry, firmware_end;
|
|
|
|
ssize_t firmware_size;
|
2019-06-25 01:11:52 +03:00
|
|
|
|
2023-01-02 14:52:34 +03:00
|
|
|
g_assert(firmware_filename != NULL);
|
|
|
|
|
2020-04-27 11:06:42 +03:00
|
|
|
if (load_elf_ram_sym(firmware_filename, NULL, NULL, NULL,
|
2020-10-14 03:17:28 +03:00
|
|
|
&firmware_entry, NULL, &firmware_end, NULL,
|
2020-04-27 11:06:42 +03:00
|
|
|
0, EM_RISCV, 1, 0, NULL, true, sym_cb) > 0) {
|
2024-08-17 03:25:02 +03:00
|
|
|
*firmware_load_addr = firmware_entry;
|
2020-10-14 03:17:28 +03:00
|
|
|
return firmware_end;
|
2019-06-25 01:11:52 +03:00
|
|
|
}
|
|
|
|
|
2020-10-14 03:17:28 +03:00
|
|
|
firmware_size = load_image_targphys_as(firmware_filename,
|
2024-08-17 03:25:02 +03:00
|
|
|
*firmware_load_addr,
|
2020-10-28 13:16:22 +03:00
|
|
|
current_machine->ram_size, NULL);
|
2020-10-14 03:17:28 +03:00
|
|
|
|
|
|
|
if (firmware_size > 0) {
|
2024-08-17 03:25:02 +03:00
|
|
|
return *firmware_load_addr + firmware_size;
|
2019-06-25 01:11:52 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
error_report("could not load firmware '%s'", firmware_filename);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
2023-02-06 17:00:22 +03:00
|
|
|
static void riscv_load_initrd(MachineState *machine, uint64_t kernel_entry)
|
|
|
|
{
|
|
|
|
const char *filename = machine->initrd_filename;
|
|
|
|
uint64_t mem_size = machine->ram_size;
|
|
|
|
void *fdt = machine->fdt;
|
|
|
|
hwaddr start, end;
|
|
|
|
ssize_t size;
|
|
|
|
|
|
|
|
g_assert(filename != NULL);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We want to put the initrd far enough into RAM that when the
|
|
|
|
* kernel is uncompressed it will not clobber the initrd. However
|
|
|
|
* on boards without much RAM we must ensure that we still leave
|
|
|
|
* enough room for a decent sized initrd, and on boards with large
|
2024-02-06 18:40:42 +03:00
|
|
|
* amounts of RAM, we put the initrd at 512MB to allow large kernels
|
|
|
|
* to boot.
|
|
|
|
* So for boards with less than 1GB of RAM we put the initrd
|
|
|
|
* halfway into RAM, and for boards with 1GB of RAM or more we put
|
|
|
|
* the initrd at 512MB.
|
2023-02-06 17:00:22 +03:00
|
|
|
*/
|
2024-02-06 18:40:42 +03:00
|
|
|
start = kernel_entry + MIN(mem_size / 2, 512 * MiB);
|
2023-02-06 17:00:22 +03:00
|
|
|
|
|
|
|
size = load_ramdisk(filename, start, mem_size - start);
|
|
|
|
if (size == -1) {
|
|
|
|
size = load_image_targphys(filename, start, mem_size - start);
|
|
|
|
if (size == -1) {
|
|
|
|
error_report("could not load ramdisk '%s'", filename);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Some RISC-V machines (e.g. opentitan) don't have a fdt. */
|
|
|
|
if (fdt) {
|
|
|
|
end = start + size;
|
2024-04-01 10:51:22 +03:00
|
|
|
qemu_fdt_setprop_u64(fdt, "/chosen", "linux,initrd-start", start);
|
|
|
|
qemu_fdt_setprop_u64(fdt, "/chosen", "linux,initrd-end", end);
|
2023-02-06 17:00:22 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-01-02 14:52:39 +03:00
|
|
|
target_ulong riscv_load_kernel(MachineState *machine,
|
2023-02-06 17:00:20 +03:00
|
|
|
RISCVHartArrayState *harts,
|
2020-10-14 03:17:33 +03:00
|
|
|
target_ulong kernel_start_addr,
|
2023-02-06 17:00:21 +03:00
|
|
|
bool load_initrd,
|
2020-10-14 03:17:33 +03:00
|
|
|
symbol_fn_t sym_cb)
|
2019-06-25 01:11:49 +03:00
|
|
|
{
|
2023-01-02 14:52:39 +03:00
|
|
|
const char *kernel_filename = machine->kernel_filename;
|
hw/riscv: Use load address rather than entry point for fw_dynamic next_addr
The original BBL boot method had the kernel embedded as an opaque blob
that was blindly jumped to, which OpenSBI implemented as fw_payload.
OpenSBI then implemented fw_jump, which allows the payload to be loaded
elsewhere, but still blindly jumps to a fixed address at which the
kernel is to be loaded. Finally, OpenSBI introduced fw_dynamic, which
allows the previous stage to inform it where to jump to, rather than
having to blindly guess like fw_jump, or embed the payload as part of
the build like fw_payload. When used with an opaque binary (i.e. the
output of objcopy -O binary), it matches the behaviour of the previous
methods. However, when used with an ELF, QEMU currently passes on the
ELF's entry point address, which causes a discrepancy compared with all
the other boot methods if that entry point is not the first instruction
in the binary.
This difference specific to fw_dynamic with an ELF is not apparent when
booting Linux, since its entry point is the first instruction in the
binary. However, FreeBSD has a separate ELF entry point, following the
calling convention used by its bootloader, that differs from the first
instruction in the binary, used for the legacy SBI entry point, and so
the specific combination of QEMU's default fw_dynamic firmware with
booting FreeBSD as an ELF rather than a raw binary does not work.
Thus, align the behaviour when loading an ELF with the behaviour when
loading a raw binary; namely, use the base address of the loaded kernel
in place of the entry point.
The uImage code is left as-is in using the U-Boot header's entry point,
since the calling convention for that entry point is the same as the SBI
one and it mirrors what U-Boot will do.
Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20211214032456.70203-1-jrtc27@jrtc27.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-12-14 06:24:56 +03:00
|
|
|
uint64_t kernel_load_base, kernel_entry;
|
2023-02-06 17:00:21 +03:00
|
|
|
void *fdt = machine->fdt;
|
2019-06-25 01:11:49 +03:00
|
|
|
|
2023-01-02 14:52:34 +03:00
|
|
|
g_assert(kernel_filename != NULL);
|
|
|
|
|
hw/riscv: Use load address rather than entry point for fw_dynamic next_addr
The original BBL boot method had the kernel embedded as an opaque blob
that was blindly jumped to, which OpenSBI implemented as fw_payload.
OpenSBI then implemented fw_jump, which allows the payload to be loaded
elsewhere, but still blindly jumps to a fixed address at which the
kernel is to be loaded. Finally, OpenSBI introduced fw_dynamic, which
allows the previous stage to inform it where to jump to, rather than
having to blindly guess like fw_jump, or embed the payload as part of
the build like fw_payload. When used with an opaque binary (i.e. the
output of objcopy -O binary), it matches the behaviour of the previous
methods. However, when used with an ELF, QEMU currently passes on the
ELF's entry point address, which causes a discrepancy compared with all
the other boot methods if that entry point is not the first instruction
in the binary.
This difference specific to fw_dynamic with an ELF is not apparent when
booting Linux, since its entry point is the first instruction in the
binary. However, FreeBSD has a separate ELF entry point, following the
calling convention used by its bootloader, that differs from the first
instruction in the binary, used for the legacy SBI entry point, and so
the specific combination of QEMU's default fw_dynamic firmware with
booting FreeBSD as an ELF rather than a raw binary does not work.
Thus, align the behaviour when loading an ELF with the behaviour when
loading a raw binary; namely, use the base address of the loaded kernel
in place of the entry point.
The uImage code is left as-is in using the U-Boot header's entry point,
since the calling convention for that entry point is the same as the SBI
one and it mirrors what U-Boot will do.
Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20211214032456.70203-1-jrtc27@jrtc27.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-12-14 06:24:56 +03:00
|
|
|
/*
|
|
|
|
* NB: Use low address not ELF entry point to ensure that the fw_dynamic
|
|
|
|
* behaviour when loading an ELF matches the fw_payload, fw_jump and BBL
|
|
|
|
* behaviour, as well as fw_dynamic with a raw binary, all of which jump to
|
|
|
|
* the (expected) load address load address. This allows kernels to have
|
|
|
|
* separate SBI and ELF entry points (used by FreeBSD, for example).
|
|
|
|
*/
|
2019-11-19 09:21:09 +03:00
|
|
|
if (load_elf_ram_sym(kernel_filename, NULL, NULL, NULL,
|
hw/riscv: Use load address rather than entry point for fw_dynamic next_addr
The original BBL boot method had the kernel embedded as an opaque blob
that was blindly jumped to, which OpenSBI implemented as fw_payload.
OpenSBI then implemented fw_jump, which allows the payload to be loaded
elsewhere, but still blindly jumps to a fixed address at which the
kernel is to be loaded. Finally, OpenSBI introduced fw_dynamic, which
allows the previous stage to inform it where to jump to, rather than
having to blindly guess like fw_jump, or embed the payload as part of
the build like fw_payload. When used with an opaque binary (i.e. the
output of objcopy -O binary), it matches the behaviour of the previous
methods. However, when used with an ELF, QEMU currently passes on the
ELF's entry point address, which causes a discrepancy compared with all
the other boot methods if that entry point is not the first instruction
in the binary.
This difference specific to fw_dynamic with an ELF is not apparent when
booting Linux, since its entry point is the first instruction in the
binary. However, FreeBSD has a separate ELF entry point, following the
calling convention used by its bootloader, that differs from the first
instruction in the binary, used for the legacy SBI entry point, and so
the specific combination of QEMU's default fw_dynamic firmware with
booting FreeBSD as an ELF rather than a raw binary does not work.
Thus, align the behaviour when loading an ELF with the behaviour when
loading a raw binary; namely, use the base address of the loaded kernel
in place of the entry point.
The uImage code is left as-is in using the U-Boot header's entry point,
since the calling convention for that entry point is the same as the SBI
one and it mirrors what U-Boot will do.
Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20211214032456.70203-1-jrtc27@jrtc27.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-12-14 06:24:56 +03:00
|
|
|
NULL, &kernel_load_base, NULL, NULL, 0,
|
2019-11-19 09:21:09 +03:00
|
|
|
EM_RISCV, 1, 0, NULL, true, sym_cb) > 0) {
|
2023-02-06 17:00:20 +03:00
|
|
|
kernel_entry = kernel_load_base;
|
|
|
|
goto out;
|
2019-06-25 01:11:49 +03:00
|
|
|
}
|
|
|
|
|
2019-06-25 01:11:54 +03:00
|
|
|
if (load_uimage_as(kernel_filename, &kernel_entry, NULL, NULL,
|
|
|
|
NULL, NULL, NULL) > 0) {
|
2023-02-06 17:00:20 +03:00
|
|
|
goto out;
|
2019-06-25 01:11:54 +03:00
|
|
|
}
|
|
|
|
|
2020-10-14 03:17:33 +03:00
|
|
|
if (load_image_targphys_as(kernel_filename, kernel_start_addr,
|
2020-10-28 13:16:22 +03:00
|
|
|
current_machine->ram_size, NULL) > 0) {
|
2023-02-06 17:00:20 +03:00
|
|
|
kernel_entry = kernel_start_addr;
|
|
|
|
goto out;
|
2019-06-25 01:11:54 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
error_report("could not load kernel '%s'", kernel_filename);
|
|
|
|
exit(1);
|
2023-02-06 17:00:20 +03:00
|
|
|
|
|
|
|
out:
|
|
|
|
/*
|
|
|
|
* For 32 bit CPUs 'kernel_entry' can be sign-extended by
|
|
|
|
* load_elf_ram_sym().
|
|
|
|
*/
|
|
|
|
if (riscv_is_32bit(harts)) {
|
|
|
|
kernel_entry = extract64(kernel_entry, 0, 32);
|
|
|
|
}
|
|
|
|
|
2023-02-06 17:00:21 +03:00
|
|
|
if (load_initrd && machine->initrd_filename) {
|
|
|
|
riscv_load_initrd(machine, kernel_entry);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (fdt && machine->kernel_cmdline && *machine->kernel_cmdline) {
|
|
|
|
qemu_fdt_setprop_string(fdt, "/chosen", "bootargs",
|
|
|
|
machine->kernel_cmdline);
|
|
|
|
}
|
|
|
|
|
2023-02-06 17:00:20 +03:00
|
|
|
return kernel_entry;
|
2019-06-25 01:11:49 +03:00
|
|
|
}
|
|
|
|
|
2023-02-01 20:12:11 +03:00
|
|
|
/*
|
hw/riscv: change riscv_compute_fdt_addr() semantics
As it is now, riscv_compute_fdt_addr() is receiving a dram_base, a
mem_size (which is defaulted to MachineState::ram_size in all boards)
and the FDT pointer. And it makes a very important assumption: the DRAM
interval dram_base + mem_size is contiguous. This is indeed the case for
most boards that use a FDT.
The Icicle Kit board works with 2 distinct RAM banks that are separated
by a gap. We have a lower bank with 1GiB size, a gap follows, then at
64GiB the high memory starts. MachineClass::default_ram_size for this
board is set to 1.5Gb, and machine_init() is enforcing it as minimal RAM
size, meaning that there we'll always have at least 512 MiB in the Hi
RAM area.
Using riscv_compute_fdt_addr() in this board is weird because not only
the board has sparse RAM, and it's calling it using the base address of
the Lo RAM area, but it's also using a mem_size that we have guarantees
that it will go up to the Hi RAM. All the function assumptions doesn't
work for this board.
In fact, what makes the function works at all in this case is a
coincidence. Commit 1a475d39ef54 introduced a 3GB boundary for the FDT,
down from 4Gb, that is enforced if dram_base is lower than 3072 MiB. For
the Icicle Kit board, memmap[MICROCHIP_PFSOC_DRAM_LO].base is 0x80000000
(2 Gb) and it has a 1Gb size, so it will fall in the conditions to put
the FDT under a 3Gb address, which happens to be exactly at the end of
DRAM_LO. If the base address of the Lo area started later than 3Gb this
function would be unusable by the board. Changing any assumptions inside
riscv_compute_fdt_addr() can also break it by accident as well.
Let's change riscv_compute_fdt_addr() semantics to be appropriate to the
Icicle Kit board and for future boards that might have sparse RAM
topologies to worry about:
- relieve the condition that the dram_base + mem_size area is contiguous,
since this is already not the case today;
- receive an extra 'dram_size' size attribute that refers to a contiguous
RAM block that the board wants the FDT to reside on.
Together with 'mem_size' and 'fdt', which are now now being consumed by a
MachineState pointer, we're able to make clear assumptions based on the
DRAM block and total mem_size available to ensure that the FDT will be put
in a valid RAM address.
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20230201171212.1219375-4-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-02-01 20:12:12 +03:00
|
|
|
* This function makes an assumption that the DRAM interval
|
|
|
|
* 'dram_base' + 'dram_size' is contiguous.
|
2023-02-01 20:12:11 +03:00
|
|
|
*
|
hw/riscv: change riscv_compute_fdt_addr() semantics
As it is now, riscv_compute_fdt_addr() is receiving a dram_base, a
mem_size (which is defaulted to MachineState::ram_size in all boards)
and the FDT pointer. And it makes a very important assumption: the DRAM
interval dram_base + mem_size is contiguous. This is indeed the case for
most boards that use a FDT.
The Icicle Kit board works with 2 distinct RAM banks that are separated
by a gap. We have a lower bank with 1GiB size, a gap follows, then at
64GiB the high memory starts. MachineClass::default_ram_size for this
board is set to 1.5Gb, and machine_init() is enforcing it as minimal RAM
size, meaning that there we'll always have at least 512 MiB in the Hi
RAM area.
Using riscv_compute_fdt_addr() in this board is weird because not only
the board has sparse RAM, and it's calling it using the base address of
the Lo RAM area, but it's also using a mem_size that we have guarantees
that it will go up to the Hi RAM. All the function assumptions doesn't
work for this board.
In fact, what makes the function works at all in this case is a
coincidence. Commit 1a475d39ef54 introduced a 3GB boundary for the FDT,
down from 4Gb, that is enforced if dram_base is lower than 3072 MiB. For
the Icicle Kit board, memmap[MICROCHIP_PFSOC_DRAM_LO].base is 0x80000000
(2 Gb) and it has a 1Gb size, so it will fall in the conditions to put
the FDT under a 3Gb address, which happens to be exactly at the end of
DRAM_LO. If the base address of the Lo area started later than 3Gb this
function would be unusable by the board. Changing any assumptions inside
riscv_compute_fdt_addr() can also break it by accident as well.
Let's change riscv_compute_fdt_addr() semantics to be appropriate to the
Icicle Kit board and for future boards that might have sparse RAM
topologies to worry about:
- relieve the condition that the dram_base + mem_size area is contiguous,
since this is already not the case today;
- receive an extra 'dram_size' size attribute that refers to a contiguous
RAM block that the board wants the FDT to reside on.
Together with 'mem_size' and 'fdt', which are now now being consumed by a
MachineState pointer, we're able to make clear assumptions based on the
DRAM block and total mem_size available to ensure that the FDT will be put
in a valid RAM address.
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20230201171212.1219375-4-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-02-01 20:12:12 +03:00
|
|
|
* Considering that 'dram_end' is the lowest value between
|
|
|
|
* the end of the DRAM block and MachineState->ram_size, the
|
|
|
|
* FDT location will vary according to 'dram_base':
|
|
|
|
*
|
|
|
|
* - if 'dram_base' is less that 3072 MiB, the FDT will be
|
|
|
|
* put at the lowest value between 3072 MiB and 'dram_end';
|
|
|
|
*
|
|
|
|
* - if 'dram_base' is higher than 3072 MiB, the FDT will be
|
|
|
|
* put at 'dram_end'.
|
2023-02-01 20:12:11 +03:00
|
|
|
*
|
|
|
|
* The FDT is fdt_packed() during the calculation.
|
|
|
|
*/
|
hw/riscv: change riscv_compute_fdt_addr() semantics
As it is now, riscv_compute_fdt_addr() is receiving a dram_base, a
mem_size (which is defaulted to MachineState::ram_size in all boards)
and the FDT pointer. And it makes a very important assumption: the DRAM
interval dram_base + mem_size is contiguous. This is indeed the case for
most boards that use a FDT.
The Icicle Kit board works with 2 distinct RAM banks that are separated
by a gap. We have a lower bank with 1GiB size, a gap follows, then at
64GiB the high memory starts. MachineClass::default_ram_size for this
board is set to 1.5Gb, and machine_init() is enforcing it as minimal RAM
size, meaning that there we'll always have at least 512 MiB in the Hi
RAM area.
Using riscv_compute_fdt_addr() in this board is weird because not only
the board has sparse RAM, and it's calling it using the base address of
the Lo RAM area, but it's also using a mem_size that we have guarantees
that it will go up to the Hi RAM. All the function assumptions doesn't
work for this board.
In fact, what makes the function works at all in this case is a
coincidence. Commit 1a475d39ef54 introduced a 3GB boundary for the FDT,
down from 4Gb, that is enforced if dram_base is lower than 3072 MiB. For
the Icicle Kit board, memmap[MICROCHIP_PFSOC_DRAM_LO].base is 0x80000000
(2 Gb) and it has a 1Gb size, so it will fall in the conditions to put
the FDT under a 3Gb address, which happens to be exactly at the end of
DRAM_LO. If the base address of the Lo area started later than 3Gb this
function would be unusable by the board. Changing any assumptions inside
riscv_compute_fdt_addr() can also break it by accident as well.
Let's change riscv_compute_fdt_addr() semantics to be appropriate to the
Icicle Kit board and for future boards that might have sparse RAM
topologies to worry about:
- relieve the condition that the dram_base + mem_size area is contiguous,
since this is already not the case today;
- receive an extra 'dram_size' size attribute that refers to a contiguous
RAM block that the board wants the FDT to reside on.
Together with 'mem_size' and 'fdt', which are now now being consumed by a
MachineState pointer, we're able to make clear assumptions based on the
DRAM block and total mem_size available to ensure that the FDT will be put
in a valid RAM address.
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20230201171212.1219375-4-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-02-01 20:12:12 +03:00
|
|
|
uint64_t riscv_compute_fdt_addr(hwaddr dram_base, hwaddr dram_size,
|
|
|
|
MachineState *ms)
|
2020-07-01 21:39:47 +03:00
|
|
|
{
|
hw/riscv: change riscv_compute_fdt_addr() semantics
As it is now, riscv_compute_fdt_addr() is receiving a dram_base, a
mem_size (which is defaulted to MachineState::ram_size in all boards)
and the FDT pointer. And it makes a very important assumption: the DRAM
interval dram_base + mem_size is contiguous. This is indeed the case for
most boards that use a FDT.
The Icicle Kit board works with 2 distinct RAM banks that are separated
by a gap. We have a lower bank with 1GiB size, a gap follows, then at
64GiB the high memory starts. MachineClass::default_ram_size for this
board is set to 1.5Gb, and machine_init() is enforcing it as minimal RAM
size, meaning that there we'll always have at least 512 MiB in the Hi
RAM area.
Using riscv_compute_fdt_addr() in this board is weird because not only
the board has sparse RAM, and it's calling it using the base address of
the Lo RAM area, but it's also using a mem_size that we have guarantees
that it will go up to the Hi RAM. All the function assumptions doesn't
work for this board.
In fact, what makes the function works at all in this case is a
coincidence. Commit 1a475d39ef54 introduced a 3GB boundary for the FDT,
down from 4Gb, that is enforced if dram_base is lower than 3072 MiB. For
the Icicle Kit board, memmap[MICROCHIP_PFSOC_DRAM_LO].base is 0x80000000
(2 Gb) and it has a 1Gb size, so it will fall in the conditions to put
the FDT under a 3Gb address, which happens to be exactly at the end of
DRAM_LO. If the base address of the Lo area started later than 3Gb this
function would be unusable by the board. Changing any assumptions inside
riscv_compute_fdt_addr() can also break it by accident as well.
Let's change riscv_compute_fdt_addr() semantics to be appropriate to the
Icicle Kit board and for future boards that might have sparse RAM
topologies to worry about:
- relieve the condition that the dram_base + mem_size area is contiguous,
since this is already not the case today;
- receive an extra 'dram_size' size attribute that refers to a contiguous
RAM block that the board wants the FDT to reside on.
Together with 'mem_size' and 'fdt', which are now now being consumed by a
MachineState pointer, we're able to make clear assumptions based on the
DRAM block and total mem_size available to ensure that the FDT will be put
in a valid RAM address.
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20230201171212.1219375-4-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-02-01 20:12:12 +03:00
|
|
|
int ret = fdt_pack(ms->fdt);
|
|
|
|
hwaddr dram_end, temp;
|
2023-02-01 20:12:10 +03:00
|
|
|
int fdtsize;
|
2020-07-01 21:39:47 +03:00
|
|
|
|
2023-02-01 20:12:10 +03:00
|
|
|
/* Should only fail if we've built a corrupted tree */
|
|
|
|
g_assert(ret == 0);
|
|
|
|
|
hw/riscv: change riscv_compute_fdt_addr() semantics
As it is now, riscv_compute_fdt_addr() is receiving a dram_base, a
mem_size (which is defaulted to MachineState::ram_size in all boards)
and the FDT pointer. And it makes a very important assumption: the DRAM
interval dram_base + mem_size is contiguous. This is indeed the case for
most boards that use a FDT.
The Icicle Kit board works with 2 distinct RAM banks that are separated
by a gap. We have a lower bank with 1GiB size, a gap follows, then at
64GiB the high memory starts. MachineClass::default_ram_size for this
board is set to 1.5Gb, and machine_init() is enforcing it as minimal RAM
size, meaning that there we'll always have at least 512 MiB in the Hi
RAM area.
Using riscv_compute_fdt_addr() in this board is weird because not only
the board has sparse RAM, and it's calling it using the base address of
the Lo RAM area, but it's also using a mem_size that we have guarantees
that it will go up to the Hi RAM. All the function assumptions doesn't
work for this board.
In fact, what makes the function works at all in this case is a
coincidence. Commit 1a475d39ef54 introduced a 3GB boundary for the FDT,
down from 4Gb, that is enforced if dram_base is lower than 3072 MiB. For
the Icicle Kit board, memmap[MICROCHIP_PFSOC_DRAM_LO].base is 0x80000000
(2 Gb) and it has a 1Gb size, so it will fall in the conditions to put
the FDT under a 3Gb address, which happens to be exactly at the end of
DRAM_LO. If the base address of the Lo area started later than 3Gb this
function would be unusable by the board. Changing any assumptions inside
riscv_compute_fdt_addr() can also break it by accident as well.
Let's change riscv_compute_fdt_addr() semantics to be appropriate to the
Icicle Kit board and for future boards that might have sparse RAM
topologies to worry about:
- relieve the condition that the dram_base + mem_size area is contiguous,
since this is already not the case today;
- receive an extra 'dram_size' size attribute that refers to a contiguous
RAM block that the board wants the FDT to reside on.
Together with 'mem_size' and 'fdt', which are now now being consumed by a
MachineState pointer, we're able to make clear assumptions based on the
DRAM block and total mem_size available to ensure that the FDT will be put
in a valid RAM address.
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20230201171212.1219375-4-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-02-01 20:12:12 +03:00
|
|
|
fdtsize = fdt_totalsize(ms->fdt);
|
2020-07-01 21:39:47 +03:00
|
|
|
if (fdtsize <= 0) {
|
|
|
|
error_report("invalid device-tree");
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
hw/riscv: change riscv_compute_fdt_addr() semantics
As it is now, riscv_compute_fdt_addr() is receiving a dram_base, a
mem_size (which is defaulted to MachineState::ram_size in all boards)
and the FDT pointer. And it makes a very important assumption: the DRAM
interval dram_base + mem_size is contiguous. This is indeed the case for
most boards that use a FDT.
The Icicle Kit board works with 2 distinct RAM banks that are separated
by a gap. We have a lower bank with 1GiB size, a gap follows, then at
64GiB the high memory starts. MachineClass::default_ram_size for this
board is set to 1.5Gb, and machine_init() is enforcing it as minimal RAM
size, meaning that there we'll always have at least 512 MiB in the Hi
RAM area.
Using riscv_compute_fdt_addr() in this board is weird because not only
the board has sparse RAM, and it's calling it using the base address of
the Lo RAM area, but it's also using a mem_size that we have guarantees
that it will go up to the Hi RAM. All the function assumptions doesn't
work for this board.
In fact, what makes the function works at all in this case is a
coincidence. Commit 1a475d39ef54 introduced a 3GB boundary for the FDT,
down from 4Gb, that is enforced if dram_base is lower than 3072 MiB. For
the Icicle Kit board, memmap[MICROCHIP_PFSOC_DRAM_LO].base is 0x80000000
(2 Gb) and it has a 1Gb size, so it will fall in the conditions to put
the FDT under a 3Gb address, which happens to be exactly at the end of
DRAM_LO. If the base address of the Lo area started later than 3Gb this
function would be unusable by the board. Changing any assumptions inside
riscv_compute_fdt_addr() can also break it by accident as well.
Let's change riscv_compute_fdt_addr() semantics to be appropriate to the
Icicle Kit board and for future boards that might have sparse RAM
topologies to worry about:
- relieve the condition that the dram_base + mem_size area is contiguous,
since this is already not the case today;
- receive an extra 'dram_size' size attribute that refers to a contiguous
RAM block that the board wants the FDT to reside on.
Together with 'mem_size' and 'fdt', which are now now being consumed by a
MachineState pointer, we're able to make clear assumptions based on the
DRAM block and total mem_size available to ensure that the FDT will be put
in a valid RAM address.
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20230201171212.1219375-4-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-02-01 20:12:12 +03:00
|
|
|
/*
|
|
|
|
* A dram_size == 0, usually from a MemMapEntry[].size element,
|
|
|
|
* means that the DRAM block goes all the way to ms->ram_size.
|
|
|
|
*/
|
|
|
|
dram_end = dram_base;
|
|
|
|
dram_end += dram_size ? MIN(ms->ram_size, dram_size) : ms->ram_size;
|
|
|
|
|
2020-07-01 21:39:47 +03:00
|
|
|
/*
|
|
|
|
* We should put fdt as far as possible to avoid kernel/initrd overwriting
|
|
|
|
* its content. But it should be addressable by 32 bit system as well.
|
2022-06-08 09:20:15 +03:00
|
|
|
* Thus, put it at an 2MB aligned address that less than fdt size from the
|
2021-01-07 12:11:27 +03:00
|
|
|
* end of dram or 3GB whichever is lesser.
|
2020-07-01 21:39:47 +03:00
|
|
|
*/
|
2022-04-19 14:59:45 +03:00
|
|
|
temp = (dram_base < 3072 * MiB) ? MIN(dram_end, 3072 * MiB) : dram_end;
|
2023-02-01 20:12:11 +03:00
|
|
|
|
|
|
|
return QEMU_ALIGN_DOWN(temp - fdtsize, 2 * MiB);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 'fdt_addr' is received as hwaddr because boards might put
|
|
|
|
* the FDT beyond 32-bit addressing boundary.
|
|
|
|
*/
|
|
|
|
void riscv_load_fdt(hwaddr fdt_addr, void *fdt)
|
|
|
|
{
|
|
|
|
uint32_t fdtsize = fdt_totalsize(fdt);
|
2020-07-01 21:39:47 +03:00
|
|
|
|
|
|
|
/* copy in the device tree */
|
|
|
|
qemu_fdt_dumpdtb(fdt, fdtsize);
|
|
|
|
|
|
|
|
rom_add_blob_fixed_as("fdt", fdt, fdtsize, fdt_addr,
|
|
|
|
&address_space_memory);
|
2022-10-25 03:43:21 +03:00
|
|
|
qemu_register_reset_nosnapshotload(qemu_fdt_randomize_seeds,
|
|
|
|
rom_ptr_for_as(&address_space_memory, fdt_addr, fdtsize));
|
2020-07-01 21:39:47 +03:00
|
|
|
}
|
|
|
|
|
2024-09-19 08:50:41 +03:00
|
|
|
void riscv_rom_copy_firmware_info(MachineState *machine,
|
|
|
|
RISCVHartArrayState *harts,
|
|
|
|
hwaddr rom_base, hwaddr rom_size,
|
|
|
|
uint32_t reset_vec_size,
|
2020-12-16 21:22:37 +03:00
|
|
|
uint64_t kernel_entry)
|
2020-07-01 21:39:48 +03:00
|
|
|
{
|
2024-09-19 08:50:41 +03:00
|
|
|
struct fw_dynamic_info32 dinfo32;
|
2020-07-01 21:39:48 +03:00
|
|
|
struct fw_dynamic_info dinfo;
|
|
|
|
size_t dinfo_len;
|
|
|
|
|
2024-09-19 08:50:41 +03:00
|
|
|
if (riscv_is_32bit(harts)) {
|
|
|
|
dinfo32.magic = cpu_to_le32(FW_DYNAMIC_INFO_MAGIC_VALUE);
|
|
|
|
dinfo32.version = cpu_to_le32(FW_DYNAMIC_INFO_VERSION);
|
|
|
|
dinfo32.next_mode = cpu_to_le32(FW_DYNAMIC_INFO_NEXT_MODE_S);
|
|
|
|
dinfo32.next_addr = cpu_to_le32(kernel_entry);
|
|
|
|
dinfo32.options = 0;
|
|
|
|
dinfo32.boot_hart = 0;
|
|
|
|
dinfo_len = sizeof(dinfo32);
|
2020-12-16 21:22:37 +03:00
|
|
|
} else {
|
|
|
|
dinfo.magic = cpu_to_le64(FW_DYNAMIC_INFO_MAGIC_VALUE);
|
|
|
|
dinfo.version = cpu_to_le64(FW_DYNAMIC_INFO_VERSION);
|
|
|
|
dinfo.next_mode = cpu_to_le64(FW_DYNAMIC_INFO_NEXT_MODE_S);
|
|
|
|
dinfo.next_addr = cpu_to_le64(kernel_entry);
|
2024-09-19 08:50:41 +03:00
|
|
|
dinfo.options = 0;
|
|
|
|
dinfo.boot_hart = 0;
|
|
|
|
dinfo_len = sizeof(dinfo);
|
2020-12-16 21:22:37 +03:00
|
|
|
}
|
2020-07-01 21:39:48 +03:00
|
|
|
|
|
|
|
/**
|
|
|
|
* copy the dynamic firmware info. This information is specific to
|
|
|
|
* OpenSBI but doesn't break any other firmware as long as they don't
|
|
|
|
* expect any certain value in "a2" register.
|
|
|
|
*/
|
|
|
|
if (dinfo_len > (rom_size - reset_vec_size)) {
|
|
|
|
error_report("not enough space to store dynamic firmware info");
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
2024-09-19 08:50:41 +03:00
|
|
|
rom_add_blob_fixed_as("mrom.finfo",
|
|
|
|
riscv_is_32bit(harts) ?
|
|
|
|
(void *)&dinfo32 : (void *)&dinfo,
|
|
|
|
dinfo_len,
|
2020-07-01 21:39:48 +03:00
|
|
|
rom_base + reset_vec_size,
|
|
|
|
&address_space_memory);
|
|
|
|
}
|
|
|
|
|
2021-01-16 02:00:27 +03:00
|
|
|
void riscv_setup_rom_reset_vec(MachineState *machine, RISCVHartArrayState *harts,
|
2020-12-16 21:23:08 +03:00
|
|
|
hwaddr start_addr,
|
2020-12-16 21:22:37 +03:00
|
|
|
hwaddr rom_base, hwaddr rom_size,
|
|
|
|
uint64_t kernel_entry,
|
2022-07-28 21:19:26 +03:00
|
|
|
uint64_t fdt_load_addr)
|
2020-07-01 21:39:46 +03:00
|
|
|
{
|
|
|
|
int i;
|
2020-07-01 21:39:49 +03:00
|
|
|
uint32_t start_addr_hi32 = 0x00000000;
|
2022-04-19 14:59:45 +03:00
|
|
|
uint32_t fdt_load_addr_hi32 = 0x00000000;
|
2020-07-01 21:39:46 +03:00
|
|
|
|
2020-12-16 21:23:08 +03:00
|
|
|
if (!riscv_is_32bit(harts)) {
|
2020-12-16 21:22:37 +03:00
|
|
|
start_addr_hi32 = start_addr >> 32;
|
2022-04-19 14:59:45 +03:00
|
|
|
fdt_load_addr_hi32 = fdt_load_addr >> 32;
|
2020-12-16 21:22:37 +03:00
|
|
|
}
|
2020-07-01 21:39:46 +03:00
|
|
|
/* reset vector */
|
2020-07-01 21:39:47 +03:00
|
|
|
uint32_t reset_vec[10] = {
|
2020-07-01 21:39:48 +03:00
|
|
|
0x00000297, /* 1: auipc t0, %pcrel_hi(fw_dyn) */
|
|
|
|
0x02828613, /* addi a2, t0, %pcrel_lo(1b) */
|
2020-07-01 21:39:46 +03:00
|
|
|
0xf1402573, /* csrr a0, mhartid */
|
2020-12-16 21:22:37 +03:00
|
|
|
0,
|
|
|
|
0,
|
2020-07-01 21:39:46 +03:00
|
|
|
0x00028067, /* jr t0 */
|
|
|
|
start_addr, /* start: .dword */
|
2020-07-01 21:39:49 +03:00
|
|
|
start_addr_hi32,
|
2020-07-01 21:39:47 +03:00
|
|
|
fdt_load_addr, /* fdt_laddr: .dword */
|
2022-04-19 14:59:45 +03:00
|
|
|
fdt_load_addr_hi32,
|
2020-07-01 21:39:48 +03:00
|
|
|
/* fw_dyn: */
|
2020-07-01 21:39:46 +03:00
|
|
|
};
|
2020-12-16 21:23:08 +03:00
|
|
|
if (riscv_is_32bit(harts)) {
|
2020-12-16 21:22:37 +03:00
|
|
|
reset_vec[3] = 0x0202a583; /* lw a1, 32(t0) */
|
|
|
|
reset_vec[4] = 0x0182a283; /* lw t0, 24(t0) */
|
|
|
|
} else {
|
|
|
|
reset_vec[3] = 0x0202b583; /* ld a1, 32(t0) */
|
|
|
|
reset_vec[4] = 0x0182b283; /* ld t0, 24(t0) */
|
|
|
|
}
|
2020-07-01 21:39:46 +03:00
|
|
|
|
2023-10-12 19:46:02 +03:00
|
|
|
if (!harts->harts[0].cfg.ext_zicsr) {
|
2023-01-23 06:57:54 +03:00
|
|
|
/*
|
|
|
|
* The Zicsr extension has been disabled, so let's ensure we don't
|
|
|
|
* run the CSR instruction. Let's fill the address with a non
|
|
|
|
* compressed nop.
|
|
|
|
*/
|
|
|
|
reset_vec[2] = 0x00000013; /* addi x0, x0, 0 */
|
|
|
|
}
|
|
|
|
|
2020-07-01 21:39:46 +03:00
|
|
|
/* copy in the reset vector in little_endian byte order */
|
2020-07-01 21:39:47 +03:00
|
|
|
for (i = 0; i < ARRAY_SIZE(reset_vec); i++) {
|
2020-07-01 21:39:46 +03:00
|
|
|
reset_vec[i] = cpu_to_le32(reset_vec[i]);
|
|
|
|
}
|
|
|
|
rom_add_blob_fixed_as("mrom.reset", reset_vec, sizeof(reset_vec),
|
|
|
|
rom_base, &address_space_memory);
|
2024-09-19 08:50:41 +03:00
|
|
|
riscv_rom_copy_firmware_info(machine, harts,
|
|
|
|
rom_base, rom_size,
|
|
|
|
sizeof(reset_vec),
|
2020-07-01 21:39:48 +03:00
|
|
|
kernel_entry);
|
2020-07-01 21:39:46 +03:00
|
|
|
}
|
2022-01-12 11:13:22 +03:00
|
|
|
|
|
|
|
void riscv_setup_direct_kernel(hwaddr kernel_addr, hwaddr fdt_addr)
|
|
|
|
{
|
|
|
|
CPUState *cs;
|
|
|
|
|
|
|
|
for (cs = first_cpu; cs; cs = CPU_NEXT(cs)) {
|
|
|
|
RISCVCPU *riscv_cpu = RISCV_CPU(cs);
|
|
|
|
riscv_cpu->env.kernel_addr = kernel_addr;
|
|
|
|
riscv_cpu->env.fdt_addr = fdt_addr;
|
|
|
|
}
|
|
|
|
}
|
2022-10-04 12:23:51 +03:00
|
|
|
|
|
|
|
void riscv_setup_firmware_boot(MachineState *machine)
|
|
|
|
{
|
|
|
|
if (machine->kernel_filename) {
|
|
|
|
FWCfgState *fw_cfg;
|
|
|
|
fw_cfg = fw_cfg_find();
|
|
|
|
|
|
|
|
assert(fw_cfg);
|
|
|
|
/*
|
|
|
|
* Expose the kernel, the command line, and the initrd in fw_cfg.
|
|
|
|
* We don't process them here at all, it's all left to the
|
|
|
|
* firmware.
|
|
|
|
*/
|
|
|
|
load_image_to_fw_cfg(fw_cfg,
|
|
|
|
FW_CFG_KERNEL_SIZE, FW_CFG_KERNEL_DATA,
|
|
|
|
machine->kernel_filename,
|
|
|
|
true);
|
|
|
|
load_image_to_fw_cfg(fw_cfg,
|
|
|
|
FW_CFG_INITRD_SIZE, FW_CFG_INITRD_DATA,
|
|
|
|
machine->initrd_filename, false);
|
|
|
|
|
|
|
|
if (machine->kernel_cmdline) {
|
|
|
|
fw_cfg_add_i32(fw_cfg, FW_CFG_CMDLINE_SIZE,
|
|
|
|
strlen(machine->kernel_cmdline) + 1);
|
|
|
|
fw_cfg_add_string(fw_cfg, FW_CFG_CMDLINE_DATA,
|
|
|
|
machine->kernel_cmdline);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|