[U-Boot] [PATCH v2 28/29] riscv: qemu: detect and boot the kernel passed by QEMU

Sun Nov 4 21:19:52 UTC 2018

On 04.11.18 13:52, Auer, Lukas wrote:
> 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 at 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 in
>>>>>> device
>>>>>> 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 for digging it to that. Relocations for runtime code are broken
(efi_runtime_relocate()). The R_ABSOLUTE path doesn't properly handle
dynsyms.

Alex