[U-Boot] [PATCH v2 2/8] ARM: bcm283x: Add BCM283x_BASE define

[Matthias Brugger]

On 26/07/2019 14:43, Andrei Gherzan wrote:
> Hi,
> 
> On 26/07/2019 13.04, Alexander Graf wrote:
>>
>>
>> On 26.07.19 13:55, Matthias Brugger wrote:
>>>
>>>
>>> On 26/07/2019 13:16, Alexander Graf wrote:
>>>>
>>>>
>>>> On 24.07.19 16:39, Andrei Gherzan wrote:
>>>>> From: Matthias Brugger <mbrugger at suse.com>
>>>>>
>>>>> Devices of bcm283x have different base address, depending if they
>>>>> are on
>>>>> bcm2835 or bcm2836/7. Use BCM283x_BASE depending on the SoC you
>>>>> want to
>>>>> build and only add the offset in the header files.
>>>>>
>>>>> Signed-off-by: Matthias Brugger <mbrugger at suse.com>
>>>>> Signed-off-by: Andrei Gherzan <andrei at balena.io>
>>>>> ---
>>>>>    arch/arm/mach-bcm283x/Kconfig              | 5 +++++
>>>>>    arch/arm/mach-bcm283x/include/mach/mbox.h  | 6 +-----
>>>>>    arch/arm/mach-bcm283x/include/mach/sdhci.h | 6 +-----
>>>>>    arch/arm/mach-bcm283x/include/mach/timer.h | 6 +-----
>>>>>    arch/arm/mach-bcm283x/include/mach/wdog.h  | 6 +-----
>>>>>    5 files changed, 9 insertions(+), 20 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm/mach-bcm283x/Kconfig
>>>>> b/arch/arm/mach-bcm283x/Kconfig
>>>>> index 3eb5a9a897..8e69914a83 100644
>>>>> --- a/arch/arm/mach-bcm283x/Kconfig
>>>>> +++ b/arch/arm/mach-bcm283x/Kconfig
>>>>> @@ -141,4 +141,9 @@ config SYS_SOC
>>>>>    config SYS_CONFIG_NAME
>>>>>        default "rpi"
>>>>>    +config BCM283x_BASE
>>>>> +    hex
>>>>> +    default "0x20000000" if BCM2835
>>>>> +    default "0x3f000000" if BCM2836 || BCM2837
>>>>
>>>> How hard would it be to make the base a global variable instead and
>>>> just set it
>>>> early on board init based on the FDT or maybe even CPU core revision
>>>> registers?
>>>
>>> Might be possible. Candidates to implement this are
>>> board_early_init_f or
>>> misc_init_f, I think.
>>>
>>>>
>>>> That would allow us to support RPi3 & 4 with the same U-Boot binary.
>>>
>>> Good point :)
>>
>> Yeah, then you only need to do the memory map dynamically as well and
>> the rest should all be handled by DT :). Which again means you don't
>> need a new config target at all!
> I like that. It will bring a little confusion though when using a rpi3
> defconfig for rpi4. I guess we could just copy it.
> 

I have a working POC of this feature, but it needs more time. I propose to merge
RPi4 support now, so that it can get accepted for v2019.10. Afterwards we can
implement a unified u-boot binary for RPi[34] and maybe even RPi[12] in the future.

If nobody shouts I'll merge this series fixing the two comments I had.
Please let me know if you disagree.

Regards,
Matthias