[PATCH v2 1/2] board: sifive: unmatched: use zero copy for initrd

[Heinrich Schuchardt]

On 11/9/21 17:07, Tom Rini wrote:
> On Tue, Nov 09, 2021 at 04:50:27PM +0100, Heinrich Schuchardt wrote:
>> On 11/9/21 16:46, Tom Rini wrote:
>>> On Tue, Nov 09, 2021 at 03:46:00PM +0100, Heinrich Schuchardt wrote:
>>>
>>>> Booting Ubuntu Impish showed the following output:
>>>>
>>>>       relocaddr   = 0x00000000fff60000
>>>>
>>>>       Loading Ramdisk to fa118000, end fffff19d ...
>>>>
>>>> The initrd is overwriting the U-Boot binary. Booting fails.
>>>>
>>>> There is no need to copy the initrd from $ramdisk_addr_r.
>>>> Set init_high = ~0UL to use zero copy. Do the same for the device tree.
>>>>
>>>> Same for the devicetree.
>>>>
>>>> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt at canonical.com>
>>>> ---
>>>> v2:
>>>> 	Don't copy fdt either.
>>>> ---
>>>>    include/configs/sifive-unmatched.h | 2 ++
>>>>    1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/include/configs/sifive-unmatched.h b/include/configs/sifive-unmatched.h
>>>> index f68d7d7676..69a4eb2f2a 100644
>>>> --- a/include/configs/sifive-unmatched.h
>>>> +++ b/include/configs/sifive-unmatched.h
>>>> @@ -59,6 +59,8 @@
>>>>    	"name=system,size=-,bootable,type=${type_guid_gpt_system};"
>>>>    #define CONFIG_EXTRA_ENV_SETTINGS \
>>>> +	"fdt_high=0xffffffffffffffff\0" \
>>>> +	"initrd_high=0xffffffffffffffff\0" \
>>>>    	"kernel_addr_r=0x84000000\0" \
>>>>    	"fdt_addr_r=0x88000000\0" \
>>>>    	"scriptaddr=0x88100000\0" \
>>>
>>> I know I'm doing this out of order, but I'm going to repeat myself here
>>> too.  You cannot disable device tree relocation.  I cannot count the
>>> number of hours that have been wasted because of this mis-feature due to
>>> misalignment of the device tree or overwriting of the device tree and
>>> then U-Boot not fixing it because it was told not to, and then people
>>> and projects wasting countless hours over it.  It's why checkpatch.pl
>>> throws out an ERROR on this now.  I didn't yell even more loudly
>>> previously at riscv because as it was missing the arch_lmb portion to
>>> avoid overwriting U-Boot at run-time, it still was a problem.  But
>>> that's been fixed.  So, no.  NAK.
>>
>> Why should the devicetree relocated?
>> This should never have been enabled on RISC-V.
> 
> To repeat myself, because RISC-V has been broken until very recently and
> lacked the parts of lmb to avoid overwriting U-Boot while running, is
> why any platforms have been allowed in with fdt/initrd_high set to
> disable relocation.  As that problem has now been fixed, fdt relocation
> must be re-enabled on the currently wrong platforms, and will not be
> allowed on new platforms.
> 
> There are specific deployment cases where the developer can choose to
> disable relocation because they know that there will never be a way for
> things to be done in an overlapping manner because the system is locked
> down.  That is very rarely the case for mainline and absolutely not the
> case for a general purpose board like the unmatched.
> 

__lmb_alloc_base() seems not be integrated with the UEFI sub-system. So 
UEFI might hand out memory marked as reserved in the LMB sub-system.

I guess this is still a topic to be addressed.

Best regards

Heinrich