On Sat, 2018-11-03 at 20:33 +0100, Alexander Graf wrote:
On 03.11.18 18:07, Auer, Lukas wrote:
On Tue, 2018-10-30 at 16:27 +0100, Alexander Graf wrote:
On 30.10.18 16:02, Auer, Lukas wrote:
On Tue, 2018-10-30 at 13:55 +0100, Lukas Auer wrote:
QEMU embeds the location of the kernel image in the device tree. Store this address in the environment as variable kernel_start and use it in CONFIG_BOOTCOMMAND to boot the kernel. Use the device tree passed by the prior boot stage to boot Linux.
Signed-off-by: Lukas Auer lukas.auer@aisec.fraunhofer.de
Changes in v2:
- Rebase onto u-boot-dm/next
- Boot Linux with the device tree provided by the prior boot
stage
board/emulation/qemu-riscv/Kconfig | 1 + board/emulation/qemu-riscv/qemu-riscv.c | 29 +++++++++++++++++++++++++ configs/qemu-riscv32_defconfig | 1 + configs/qemu-riscv64_defconfig | 1 + include/configs/qemu-riscv.h | 10 ++++++++- 5 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/board/emulation/qemu-riscv/Kconfig b/board/emulation/qemu-riscv/Kconfig index 37a80db6a9..be5839b7db 100644 --- a/board/emulation/qemu-riscv/Kconfig +++ b/board/emulation/qemu-riscv/Kconfig @@ -29,5 +29,6 @@ config BOARD_SPECIFIC_OPTIONS # dummy imply CMD_EXT2 imply CMD_EXT4 imply CMD_FAT
- imply BOARD_LATE_INIT
endif diff --git a/board/emulation/qemu-riscv/qemu-riscv.c b/board/emulation/qemu-riscv/qemu-riscv.c index 2ce093e19a..ee20983095 100644 --- a/board/emulation/qemu-riscv/qemu-riscv.c +++ b/board/emulation/qemu-riscv/qemu-riscv.c @@ -19,3 +19,32 @@ int board_init(void)
return 0; }
+int board_late_init(void) +{
- ulong kernel_start;
- ofnode chosen_node;
- int ret;
- chosen_node = ofnode_path("/chosen");
- if (!ofnode_valid(chosen_node)) {
printf("No chosen node found\n");return 0;- }
+#ifdef CONFIG_ARCH_RV64I
- ret = ofnode_read_u64(chosen_node, "riscv,kernel-
start",
(u64 *)&kernel_start);+#else
- ret = ofnode_read_u32(chosen_node, "riscv,kernel-
start",
(u32 *)&kernel_start);+#endif
- if (ret) {
printf("Can't find kernel start address indevice tree\n");
return 0;- }
- env_set_hex("kernel_start", kernel_start);
- return 0;
+} diff --git a/configs/qemu-riscv32_defconfig b/configs/qemu- riscv32_defconfig index b55644378a..13dd53a550 100644 --- a/configs/qemu-riscv32_defconfig +++ b/configs/qemu-riscv32_defconfig @@ -4,4 +4,5 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_FIT=y CONFIG_DISPLAY_CPUINFO=y CONFIG_DISPLAY_BOARDINFO=y +CONFIG_HUSH_PARSER=y CONFIG_OF_PRIOR_STAGE=y diff --git a/configs/qemu-riscv64_defconfig b/configs/qemu- riscv64_defconfig index a542ac4893..06eb3042fa 100644 --- a/configs/qemu-riscv64_defconfig +++ b/configs/qemu-riscv64_defconfig @@ -5,4 +5,5 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_FIT=y CONFIG_DISPLAY_CPUINFO=y CONFIG_DISPLAY_BOARDINFO=y +CONFIG_HUSH_PARSER=y CONFIG_OF_PRIOR_STAGE=y diff --git a/include/configs/qemu-riscv.h b/include/configs/qemu- riscv.h index ba6a18f2e6..7c88ba300a 100644 --- a/include/configs/qemu-riscv.h +++ b/include/configs/qemu-riscv.h @@ -21,7 +21,15 @@ #define CONFIG_ENV_SIZE SZ_4K
#define CONFIG_EXTRA_ENV_SETTINGS \
- "fdt_high=0xffffffffffffffff\0" \
- "fdt_high=0x82000000\0" \
- "bootm_size=0x10000000\0" \ "initrd_high=0xffffffffffffffff\0"
+#define CONFIG_BOOTCOMMAND \
- "if env exists kernel_start; then " \
"bootm ${kernel_start} - ${prior_stage_dtb};" \As Alexander Graf pointed out in reply to patch 24, we don't need the separate environment variable "prior_stage_dtb". I will replace it with "fdtcontroladdr" here and drop patch 24 in the next version.
Also, can you please enable distro boot? :)
Thanks,
Alex
I just had a closer look at distro boot and it's actually quite easy to use. I will update this patch to enable it and will add a bootcmd for virtio block devices (virtio support is currently in u-boot- dm/next).
I was looking into testing bootefi on U-Boot and tried to run the hello world and selftest EFI binaries, however I could not get them running. After starting them I immediately get a load access fault. The faulting instruction is at 0xfe77c1fa, which is strange since the binary is loaded to 0x80200000. Do you know what this could be caused by?
I'm not quite sure yet what goes wrong. I tested and verified the riscv uefi port on andes targets (where at least grub still works), but I can confirm that the same code just falls apart for me on the qemu target.
Any help to debug it down a bit further is much appreciated.
I started to narrow it down further. The hello EFI application faults at the very beginning of its efi_main. The first thing it does is to print "Hello World". For that, it needs the con_out protocol from the systable. This is where it goes wrong. con_out is listed to be at 0x17ffd8638, which is above the available system memory. Once it is accessed, the system throws the load access fault. So, I think something with the relocation of the systable entries does not work.
Thanks, Lukas
Also note that I completed the list of exception codes in this patch series. U-Boot master will not indicate this exception occurred.
Ah nice, that will definitely help to debug what's going wrong :).
Alex