[PATCH v2 2/2] board: sifive: unmatched: rearrange load addresses

Heinrich Schuchardt heinrich.schuchardt at canonical.com
Tue Nov 9 16:46:00 CET 2021


On 11/9/21 16:43, Tom Rini wrote:
> On Tue, Nov 09, 2021 at 03:46:01PM +0100, Heinrich Schuchardt wrote:
> 
>> * Put the small files below $kernel_addr_r to not limit the kernel size.
>> * ramdisk_addr_r should be the highest of all loading addresses to
>>    avoid limiting the size of the initial RAM disk.
>>
>> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt at canonical.com>
>> ---
>> v2:
>> 	new patch
>> ---
>>   include/configs/sifive-unmatched.h | 15 ++++++++-------
>>   1 file changed, 8 insertions(+), 7 deletions(-)
>>
>> diff --git a/include/configs/sifive-unmatched.h b/include/configs/sifive-unmatched.h
>> index 69a4eb2f2a..7a6f4acf4d 100644
>> --- a/include/configs/sifive-unmatched.h
>> +++ b/include/configs/sifive-unmatched.h
>> @@ -61,13 +61,14 @@
>>   #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" \
>> -	"pxefile_addr_r=0x88200000\0" \
>> -	"ramdisk_addr_r=0x88300000\0" \
>> -	"kernel_comp_addr_r=0x90000000\0" \
>> -	"kernel_comp_size=0x4000000\0" \
>> +	"fdt_addr_r=0x84000000\0" \
>> +	"scriptaddr=0x84100000\0" \
>> +	"pxefile_addr_r=0x84200000\0" \
>> +	"kernel_addr_r=0x85000000\0" \
>> +	"loadaddr=0x85000000\0" \
>> +	"kernel_comp_addr_r=0x8b000000\0" \
>> +	"kernel_comp_size=0x05000000\0" \
>> +	"ramdisk_addr_r=0x90000000\0" \
>>   	"type_guid_gpt_loader1=" TYPE_GUID_LOADER1 "\0" \
>>   	"type_guid_gpt_loader2=" TYPE_GUID_LOADER2 "\0" \
>>   	"type_guid_gpt_system=" TYPE_GUID_SYSTEM "\0" \
> 
> NAK.  Now that riscv finally has arch_lmb support, we need to stop
> disabling relocation of the device tree.  We should also stop disabling
> relocation of the initrd, and instead (a) do like you're doing and set
> sane default locations and then (b) set bootm_low/bootm_size such that
> we won't possibly be moving things outside of the acceptable to the
> kernel range for everything.
> 

Why should we relocate initrd or ftd?
This never should have been enabled on RISC-V.

Best regards

Heinrich


More information about the U-Boot mailing list