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

Heinrich Schuchardt heinrich.schuchardt at canonical.com
Tue Nov 9 16:50:27 CET 2021


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.

Best regards

Heinrich



More information about the U-Boot mailing list