[U-Boot] [PATCH] ti: am335x_evm: Enable CONFIG_SPL_OF_CONTROL

[Tom Rini]

On Tue, Mar 19, 2019 at 05:01:42PM +0530, Faiz Abbas wrote:
> Hi Tom,
> 
> On 19/03/19 4:49 PM, Tom Rini wrote:
> > Enable support for SPL_OF_CONTROL on this platform.  That means doing a
> > few things:
> > - Add u-boot,dm-pre-reloc to a number of nodes
> > - Drop static platdata in the board file.
> > - A lot of tweaks to the defconfig.  We remove some things such as
> >   SPL_USE_ARCH_MEMCPY/SET for space.  Increase our malloc len.
> > - Drop, for now at least, USB SPL support as it's causing a hang.
> > 
> > Cc: Faiz Abbas <faiz_abbas at ti.com>
> > Cc: Lokesh Vutla <lokeshvutla at ti.com>
> > Signed-off-by: Tom Rini <trini at konsulko.com>
> > ---
> >  arch/arm/dts/am335x-evm-u-boot.dtsi | 45 +++++++++++++++++++++++++++++++++++--
> >  board/ti/am335x/board.c             | 30 -------------------------
> >  configs/am335x_evm_defconfig        | 14 ++++++++----
> >  3 files changed, 53 insertions(+), 36 deletions(-)
> > 
> > diff --git a/arch/arm/dts/am335x-evm-u-boot.dtsi b/arch/arm/dts/am335x-evm-u-boot.dtsi
> > index b6b97ed16d91..16a9f855ad1f 100644
> > --- a/arch/arm/dts/am335x-evm-u-boot.dtsi
> > +++ b/arch/arm/dts/am335x-evm-u-boot.dtsi
> > @@ -3,11 +3,52 @@
> >   * Copyright (C) 2017 Texas Instruments Incorporated - http://www.ti.com/
> >   */
> >  
> > +#include "am33xx-u-boot.dtsi"
> >  
> > -&mmc3 {
> > -	status = "disabled";
> > +&l4_wkup {
> > +	u-boot,dm-pre-reloc;
> > +};
> > +
> > +&scm {
> > +	u-boot,dm-pre-reloc;
> > +};
> > +
> > +&am33xx_pinmux {
> > +	u-boot,dm-pre-reloc;
> > +};
> > +
> > +&uart0_pins {
> > +	u-boot,dm-pre-reloc;
> > +};
> > +
> > +&uart0 {
> > +	u-boot,dm-pre-reloc;
> > +};
> > +
> > +&gpio0 {
> > +	u-boot,dm-pre-reloc;
> > +};
> > +
> > +&i2c0 {
> > +	u-boot,dm-pre-reloc;
> > +};
> > +
> > +&i2c0_pins {
> > +	u-boot,dm-pre-reloc;
> >  };
> >  
> >  &usb0 {
> >  	dr_mode = "peripheral";
> >  };
> > +
> > +&mmc1 {
> > +	u-boot,dm-pre-reloc;
> > +};
> > +
> > +&mmc1_pins {
> > +	u-boot,dm-pre-reloc;
> > +};
> > +
> > +&mmc3 {
> > +	status = "disabled";
> > +};
> > diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
> > index d67f94ad47ba..bfad1a75a456 100644
> > --- a/board/ti/am335x/board.c
> > +++ b/board/ti/am335x/board.c
> > @@ -1054,33 +1054,3 @@ void board_fit_image_post_process(void **p_image, size_t *p_size)
> >  	secure_boot_verify_image(p_image, p_size);
> >  }
> >  #endif
> > -
> > -#if !CONFIG_IS_ENABLED(OF_CONTROL)
> > -static const struct omap_hsmmc_plat am335x_mmc0_platdata = {
> > -	.base_addr = (struct hsmmc *)OMAP_HSMMC1_BASE,
> > -	.cfg.host_caps = MMC_MODE_HS_52MHz | MMC_MODE_HS | MMC_MODE_4BIT,
> > -	.cfg.f_min = 400000,
> > -	.cfg.f_max = 52000000,
> > -	.cfg.voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195,
> > -	.cfg.b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT,
> > -};
> > -
> > -U_BOOT_DEVICE(am335x_mmc0) = {
> > -	.name = "omap_hsmmc",
> > -	.platdata = &am335x_mmc0_platdata,
> > -};
> > -
> > -static const struct omap_hsmmc_plat am335x_mmc1_platdata = {
> > -	.base_addr = (struct hsmmc *)OMAP_HSMMC2_BASE,
> > -	.cfg.host_caps = MMC_MODE_HS_52MHz | MMC_MODE_HS | MMC_MODE_8BIT,
> > -	.cfg.f_min = 400000,
> > -	.cfg.f_max = 52000000,
> > -	.cfg.voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195,
> > -	.cfg.b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT,
> > -};
> > -
> > -U_BOOT_DEVICE(am335x_mmc1) = {
> > -	.name = "omap_hsmmc",
> > -	.platdata = &am335x_mmc1_platdata,
> > -};
> > -#endif
> 
> We also need to look at arch/arm/mach-omap2/board.c. Bunch of GPIO and
> I2C platdata there.

Yes, but that's all also guarded under a check for SPL_OF_CONTROL being
enabled.  The above is the board-specific part and why I dropped it.

> In general, if we are not able to fit all bootmodes with SPL_OF_CONTROL
> enabled, should we remove it and add back platdata or do something else?

I'm not sure we can fit all the boot modes with platdata either, nor am
I convinced that's the best thing to do.  Checking the TRM again, you
can only have 4 choices at most in a single hardware config, and we
already don't support some options such as SPI with everything else.

But I'd like to start with seeing everything working with
SPL_OF_CONTROL, even if it's not all enabled in the same binary and then
we can see what options are available to us to fit the most into a
single binary.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190319/cdf20a94/attachment.sig>