Andre, On 4/17/21 1:23 PM, Andre Przywara wrote: > On Sat, 17 Apr 2021 12:47:23 -0500 Samuel Holland <sam...@sholland.org> wrote: >> On 3/31/21 10:39 AM, Andre Przywara wrote: >>> On 20/02/2021 12:14, Nicolas Boulenguez wrote: >>> >>> Hi Arnaud, >>> >>>> From: Arnaud Ferraris <arnaud.ferra...@gmail.com> >>> >>> as mentioned before, this looks useful, so can you re-send this with a >>> commit message and your Signed-off-by:? >> >> It looks like you picked up this patch regardless? > > Yes, I asked him twice, without any reply. At the end I figured that > the danger of a copyright infringement is low given the nature of the > change, and I didn't feel this should block this useful feature. The > alternative would be to have sent it as a patch of mine, but I felt > that I should preserve his authorship, so took the patch anyway. > I got a reply from him on another patch, and it's not his first U-Boot > patch, so I think it's just an oversight (from the sender of the patch?) > > Chen-Yu asked about the feature lately, so if you think that approach > is dodgy, we can revert it and take another version of the patch.
Okay, I'll trust your judgement here. >>> Also I was wondering if you could increase the COMP_SIZE? The 64MB look >>> rather arbitrary and maybe unnecessarily limiting. I think we could go >>> up till 0xfa00000, but maybe should stop at 0xf800000, to leave some >>> space for further extensions? >> >> And you changed KERNEL_COMP_SIZE to 0xb000000. How does that work when >> U-Boot itself is at 0x4a000000 (KERNEL_COMP_ADDR_R + 0x6000000)? > > It's not anymore at this time, that's just the load address, and it > relocates itself to the end of DRAM very early. So basically the whole > memory except the very end is available. > > Btw, the reason we confine everything to below 0x50000000 is just that > we need to concatenate the base (0x4....) with that offset, and cannot > use arithmetic, because that doesn't work in the Makefiles. Ah, that makes sense. So we're assuming that U-Boot relocates itself above 0x50000000, and so nothing important remains inside the address range used by sunxi-common.h. Thanks for the explanation, Samuel > Cheers, > Andre > >>>> --- >>>> include/configs/sunxi-common.h | 15 +++++++++++++++ >>>> 1 file changed, 15 insertions(+) >>>> >>>> diff --git a/include/configs/sunxi-common.h >>>> b/include/configs/sunxi-common.h >>>> index 5b0bec0561..227284cd29 100644 >>>> --- a/include/configs/sunxi-common.h >>>> +++ b/include/configs/sunxi-common.h >>>> @@ -291,6 +291,8 @@ extern int soft_i2c_gpio_scl; >>>> */ >>>> #define BOOTM_SIZE __stringify(0xa000000) >>>> #define KERNEL_ADDR_R __stringify(SDRAM_OFFSET(0080000)) >>>> +#define KERNEL_COMP_ADDR_R __stringify(SDRAM_OFFSET(4000000)) >>>> +#define KERNEL_COMP_SIZE __stringify(0x4000000) >>>> #define FDT_ADDR_R __stringify(SDRAM_OFFSET(FA00000)) >>>> #define SCRIPT_ADDR_R __stringify(SDRAM_OFFSET(FC00000)) >>>> #define PXEFILE_ADDR_R __stringify(SDRAM_OFFSET(FD00000)) >>>> @@ -332,6 +334,18 @@ extern int soft_i2c_gpio_scl; >>>> "pxefile_addr_r=" PXEFILE_ADDR_R "\0" \ >>>> "ramdisk_addr_r=" RAMDISK_ADDR_R "\0" >>>> >>>> +#ifdef CONFIG_ARM64 >>>> + >>>> +#define MEM_LAYOUT_ENV_EXTRA_SETTINGS \ >>>> + "kernel_comp_addr_r=" KERNEL_COMP_ADDR_R "\0" \ >>>> + "kernel_comp_size=" KERNEL_COMP_SIZE "\0" >>>> + >>>> +#else >>>> + >>>> +#define MEM_LAYOUT_ENV_EXTRA_SETTINGS "" >> >> This can be defined to nothing. No empty string is needed. >> >>>> + >>>> +#endif >>>> + >>>> #define DFU_ALT_INFO_RAM \ >>>> "dfu_alt_info_ram=" \ >>>> "kernel ram " KERNEL_ADDR_R " 0x1000000;" \ >>>> @@ -487,6 +501,7 @@ extern int soft_i2c_gpio_scl; >>>> #define CONFIG_EXTRA_ENV_SETTINGS \ >>>> CONSOLE_ENV_SETTINGS \ >>>> MEM_LAYOUT_ENV_SETTINGS \ >>>> + MEM_LAYOUT_ENV_EXTRA_SETTINGS \ >>>> DFU_ALT_INFO_RAM \ >>>> "fdtfile=" FDTFILE "\0" \ >>>> "console=ttyS0,115200\0" \ >>>> >>> >> >