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 <mbrug...@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 <mbrug...@suse.com> >>>>> Signed-off-by: Andrei Gherzan <and...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
