Re: [Qemu-devel] [PATCH v3] Support u-boot noload images for arm as used by, NetBSD/evbarm GENERIC kernel.

[Nick Hudson <nicholas.a.hudson@gmail.com>]

On 03/01/2019 17:27, Peter Maydell wrote:
> On Thu, 3 Jan 2019 at 16:50, Nick Hudson <nicholas.a.hudson@gmail.com> wrote:
>> On 03/01/2019 16:20, Peter Maydell wrote:
>>> On Tue, 11 Dec 2018 at 12:27, Nick Hudson <nicholas.a.hudson@gmail.com> wrote:
>>>> --- a/hw/arm/boot.c
>>>> +++ b/hw/arm/boot.c
>>>> @@ -30,8 +30,9 @@
>>>>      * Documentation/arm/Booting and Documentation/arm64/booting.txt
>>>>      * They have different preferred image load offsets from system RAM base.
>>>>      */
>>>> -#define KERNEL_ARGS_ADDR 0x100
>>>> -#define KERNEL_LOAD_ADDR 0x00010000
>>>> +#define KERNEL_ARGS_ADDR   0x100
>>>> +#define KERNEL_NOLOAD_ADDR 0x00000000
>>>
>>> If I'm reading the code right, this requests that noload images
>>> are loaded at offset zero into RAM, yes ?
>>
>> Not quite.
>>
>> They're loaded as if the full noload image (including uboot header)
>> was loaded at offset zero, but as load_uboot_image doesn't load the
>> header then the image body (minus the header) is loaded at offset
>> zero + the size of the u-boot header, i.e. 0x40.
>>
>>> That's not a great
>>> choice, because we put our little mini bootloader at offset 0,
>>> and so the two will clash.
>>
>> Fortuntately, the bootloader fits in the space that the uboot header would
>> have occupied.
>>
>> My commit message has
>>
>> "The bootloader fits in the space that the uboot header would have occupied."
>>
>> to try and described this. I could add more of a description if required?
> 
> Ah, I missed that. This seems very fragile to me -- 0x40
> is only 64 bytes, which is 16 instructions. Currently
> our boot loader code is less than that, but only by four
> insns or so, so it's very plausible that some future
> enhancement to the loader code would take it over the 0x40
> boundary, at which point handling of noload images will
> silently fail. At a minimum we should have an assertion
> that we stay below 0x40; but I'm not keen on restricting
> ourselves to 16-instruction bootloaders.

I can add an assertion.

Kernels often like to be 2MiB aligned to allow for more simple
translation tables. This and the fact that  the bootloader hasn't 
changed in 3 years I'd like to kick this can down the road.

> 
> Will a noload image ever in practice also be a Linux kernel
> (ie hdr->ih_os == IH_OS_LINUX) ?

NetBSD/FreeBSD/OpenBSD (ab)use IH_OS_LINUX.  They and Linux

> If not, then we don't lose
> anything by not allowing those to be loaded. (And if anybody
> does in future complain that their image doesn't work, we
> could make it supported by allowing the mini-bootloader to
> be placed elsewhere in RAM.)



> 
> thanks
> -- PMM
> 

thanks,
Nick