[PATCH v6 0/5] of-platdata: Avoid building libfdt

[PATCH v6 0/5] of-platdata: Avoid building libfdt

[Simon Glass]

The original patch of this series was sent in September 2019 but
unfortunately caused build problems on some boards, since they don't
comply with the of-platdata rules.

With of-platdata, the idea is to compile the device tree into C structures
to save space and avoid needing to use libfdt. But some boards use
of-platdata while also using libfdt in a few areas, thus defeating the
purpose of of-platdata.

This series includes the original two patches

   http://patchwork.ozlabs.org/patch/1167420/
   http://patchwork.ozlabs.org/patch/1167367/

as well as a few other patches to fix the build errors. Overall this
reduces code size and provides better error messages when unavailable
functions are used.

Board maintainers should still take a look at the result, adjusting the
of-platdata support as needed.

Note: This series was resent a year ago but not applied. Since then, some
boards have ended up using drivers in SPL which require OF_CONTROL, but
SPL_OF_CONTROL is not enabled. So now we have two problems. This series
fixes that one also.

The problems will keep getting worse if people are not aware that
something is wrong. Therefore I think this patch series should be applied
ASAP.

Changes in v6:
- Add new patch for atheros
- Add new patch for SPI flash
- Rebase to master

Changes in v5:
- Drop rockchip patches as those boards have been fixed

Changes in v4:
- Add new patch for rockchip build errors
- Add new patch for omap MMC build errors
- Add new patch for rockchip chromebook build errors
- Pull out patches into a new series
- Add new patches to handle build failures

Changes in v3:
- Fix eth_dev_get_mac_address() call dev_read...() only when available

Simon Glass (5):
  omap: mmc: Avoid using libfdt with of-platdata
  net: atheros: Add a check for OF_CONTROL
  spi: Add checks for OF_CONTROL
  spl: Allow SPL/TPL to use of-platdata without libfdt
  dm: core: Don't include ofnode functions with of-platdata

 drivers/core/Makefile     |  4 +++-
 drivers/mmc/davinci_mmc.c |  6 ++++++
 drivers/net/phy/atheros.c | 11 +++++++++++
 drivers/spi/spi-uclass.c  | 16 +++++++++++++---
 lib/Kconfig               |  4 ++--
 5 files changed, 35 insertions(+), 6 deletions(-)

-- 
2.32.0.432.gabb21c7263-goog

[PATCH v6 1/5] omap: mmc: Avoid using libfdt with of-platdata

[Simon Glass]

At present this driver is enabled in SPL on omapl138_lcdk, which uses
of-platdata. The driver needs to be ported to use of-platdata properly.
For now, avoid a build error by returning an error.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

(no changes since v1)

 drivers/mmc/davinci_mmc.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/mmc/davinci_mmc.c b/drivers/mmc/davinci_mmc.c
index 05ca3612809..7016649524f 100644
--- a/drivers/mmc/davinci_mmc.c
+++ b/drivers/mmc/davinci_mmc.c
@@ -506,6 +506,12 @@ static int davinci_mmc_of_to_plat(struct udevice *dev)
 	struct davinci_mmc_plat *plat = dev_get_plat(dev);
 	struct mmc_config *cfg = &plat->cfg;
 
+	/* FIXME: Cannot read from device tree with of-platdata */
+	if (CONFIG_IS_ENABLED(OF_PLATDATA)) {
+		printf("Please fix this driver to use of-platdata");
+		return -ENOSYS;
+	}
+
 	plat->reg_base = (struct davinci_mmc_regs *)dev_read_addr(dev);
 	cfg->f_min = 200000;
 	cfg->f_max = 25000000;
-- 
2.32.0.432.gabb21c7263-goog

[PATCH v6 2/5] net: atheros: Add a check for OF_CONTROL

[Simon Glass]

This phy cannot be used when OF_CONTROL is not enabled. A few boards
expect it to build, though, so add a runtime check for this case.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

Changes in v6:
- Add new patch for atheros

 drivers/net/phy/atheros.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/net/phy/atheros.c b/drivers/net/phy/atheros.c
index f922fecd6b5..cc772f3060f 100644
--- a/drivers/net/phy/atheros.c
+++ b/drivers/net/phy/atheros.c
@@ -7,6 +7,7 @@
  * Copyright (c) 2019 Michael Walle <michael@walle.cc>
  */
 #include <common.h>
+#include <log.h>
 #include <phy.h>
 #include <dm/device_compat.h>
 #include <linux/bitfield.h>
@@ -197,6 +198,16 @@ static int ar803x_of_init(struct phy_device *phydev)
 	u32 strength, freq, min_uV, max_uV;
 	int sel;
 
+	/*
+	 * This driver requires OF_CONTROL but this is included on some boards
+	 * that don't support it in SPL. Return an error so the board vendor
+	 * can resolve this.
+	 */
+	if (!CONFIG_IS_ENABLED(OF_CONTROL)) {
+		log_err("atheros driver requires OF_CONTROL enabled");
+		return -ENOSYS;
+	}
+
 	node = phy_get_ofnode(phydev);
 	if (!ofnode_valid(node))
 		return -EINVAL;
-- 
2.32.0.432.gabb21c7263-goog

[PATCH v6 3/5] spi: Add checks for OF_CONTROL

[Simon Glass]

This uclass requires OF_CONTROL to be enabled but some boards use it in
SPL without doing that. Add a warning so that the maintainer can fix it.

Expand the check in spi_post_probe() too.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

Changes in v6:
- Add new patch for SPI flash

 drivers/spi/spi-uclass.c | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
index d867b278064..2ae3e075993 100644
--- a/drivers/spi/spi-uclass.c
+++ b/drivers/spi/spi-uclass.c
@@ -176,11 +176,11 @@ static int spi_child_post_bind(struct udevice *dev)
 
 static int spi_post_probe(struct udevice *bus)
 {
-#if !CONFIG_IS_ENABLED(OF_PLATDATA)
 	struct dm_spi_bus *spi = dev_get_uclass_priv(bus);
 
-	spi->max_hz = dev_read_u32_default(bus, "spi-max-frequency", 0);
-#endif
+	if (CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA))
+		spi->max_hz = dev_read_u32_default(bus, "spi-max-frequency", 0);
+
 #if defined(CONFIG_NEEDS_MANUAL_RELOC)
 	struct dm_spi_ops *ops = spi_get_ops(bus);
 	static int reloc_done;
@@ -471,6 +471,16 @@ int spi_slave_of_to_plat(struct udevice *dev, struct dm_spi_slave_plat *plat)
 	int mode = 0;
 	int value;
 
+	/*
+	 * This uclass requires OF_CONTROL but this is included on some boards
+	 * that don't support it in SPL. Return an error so the board vendor
+	 * can resolve this.
+	 */
+	if (!CONFIG_IS_ENABLED(OF_CONTROL)) {
+		log_err("SPI flash requires OF_CONTROL enabled");
+		return -ENOSYS;
+	}
+
 	plat->cs = dev_read_u32_default(dev, "reg", -1);
 	plat->max_hz = dev_read_u32_default(dev, "spi-max-frequency",
 					    SPI_DEFAULT_SPEED_HZ);
-- 
2.32.0.432.gabb21c7263-goog

[PATCH v6 4/5] spl: Allow SPL/TPL to use of-platdata without libfdt

[Simon Glass]

At present libfdt is included in SPL/TPL if SPL/TPL_OF_CONTROL is enabled.
But if of-platdata is in use this is not required. Update the condition to
avoid building this extra code. This ensures that if a libfdt function is
used it will produce a link error rather than silently increasing the
build size.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

Changes in v6:
- Rebase to master

Changes in v5:
- Drop rockchip patches as those boards have been fixed

Changes in v4:
- Add new patch for rockchip build errors
- Add new patch for omap MMC build errors
- Add new patch for rockchip chromebook build errors
- Pull out patches into a new series
- Add new patches to handle build failures

 lib/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/Kconfig b/lib/Kconfig
index ad4d75e0a40..ef1235bf0c8 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -599,7 +599,7 @@ config OF_LIBFDT_OVERLAY
 
 config SPL_OF_LIBFDT
 	bool "Enable the FDT library for SPL"
-	default y if SPL_OF_CONTROL
+	default y if SPL_OF_CONTROL && !SPL_OF_PLATDATA
 	help
 	  This enables the FDT library (libfdt). It provides functions for
 	  accessing binary device tree images in memory, such as adding and
@@ -620,7 +620,7 @@ config SPL_OF_LIBFDT_ASSUME_MASK
 
 config TPL_OF_LIBFDT
 	bool "Enable the FDT library for TPL"
-	default y if TPL_OF_CONTROL
+	default y if TPL_OF_CONTROL && !TPL_OF_PLATDATA
 	help
 	  This enables the FDT library (libfdt). It provides functions for
 	  accessing binary device tree images in memory, such as adding and
-- 
2.32.0.432.gabb21c7263-goog

[PATCH v6 5/5] dm: core: Don't include ofnode functions with of-platdata

[Simon Glass]

These functions cannot work with of-platdata since libfdt is not
available. At present when dev_read_...() functions are used it produces
error messages about ofnode which is confusing.

Adjust the Makefile and header to produce an error message for the actual
dev_read...() function which is called. This makes it easier to see what
code needs to be converted for use with of-platdata.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

(no changes since v3)

Changes in v3:
- Fix eth_dev_get_mac_address() call dev_read...() only when available

 drivers/core/Makefile | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/core/Makefile b/drivers/core/Makefile
index 5edd4e41357..725e6e94cd2 100644
--- a/drivers/core/Makefile
+++ b/drivers/core/Makefile
@@ -15,6 +15,8 @@ obj-$(CONFIG_$(SPL_)OF_LIVE) += of_access.o of_addr.o
 ifndef CONFIG_DM_DEV_READ_INLINE
 obj-$(CONFIG_OF_CONTROL) += read.o
 endif
-obj-$(CONFIG_OF_CONTROL) += of_extra.o ofnode.o read_extra.o
+ifdef CONFIG_$(SPL_TPL_)OF_LIBFDT
+obj-$(CONFIG_$(SPL_TPL_)OF_CONTROL) += of_extra.o ofnode.o read_extra.o
+endif
 
 ccflags-$(CONFIG_DM_DEBUG) += -DDEBUG
-- 
2.32.0.432.gabb21c7263-goog

Re: [PATCH v6 0/5] of-platdata: Avoid building libfdt

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1599 bytes --]

On Sun, Jul 25, 2021 at 10:13:42AM -0600, Simon Glass wrote:

> The original patch of this series was sent in September 2019 but
> unfortunately caused build problems on some boards, since they don't
> comply with the of-platdata rules.
> 
> With of-platdata, the idea is to compile the device tree into C structures
> to save space and avoid needing to use libfdt. But some boards use
> of-platdata while also using libfdt in a few areas, thus defeating the
> purpose of of-platdata.
> 
> This series includes the original two patches
> 
>    http://patchwork.ozlabs.org/patch/1167420/
>    http://patchwork.ozlabs.org/patch/1167367/
> 
> as well as a few other patches to fix the build errors. Overall this
> reduces code size and provides better error messages when unavailable
> functions are used.
> 
> Board maintainers should still take a look at the result, adjusting the
> of-platdata support as needed.
> 
> Note: This series was resent a year ago but not applied. Since then, some
> boards have ended up using drivers in SPL which require OF_CONTROL, but
> SPL_OF_CONTROL is not enabled. So now we have two problems. This series
> fixes that one also.
> 
> The problems will keep getting worse if people are not aware that
> something is wrong. Therefore I think this patch series should be applied
> ASAP.

OK, so I took 5/6 and 6/6 and fired off a build.  The only fails-to-link
now are:
am335x_boneblack_vboot am335x_evm am335x_evm_spiboot

So are all of the other problems still present?  I'm going to look in to
the am335x failures.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH v6 0/5] of-platdata: Avoid building libfdt

[Simon Glass]

Hi Tom,

On Sun, 25 Jul 2021 at 14:32, Tom Rini <trini@konsulko.com> wrote:
>
> On Sun, Jul 25, 2021 at 10:13:42AM -0600, Simon Glass wrote:
>
> > The original patch of this series was sent in September 2019 but
> > unfortunately caused build problems on some boards, since they don't
> > comply with the of-platdata rules.
> >
> > With of-platdata, the idea is to compile the device tree into C structures
> > to save space and avoid needing to use libfdt. But some boards use
> > of-platdata while also using libfdt in a few areas, thus defeating the
> > purpose of of-platdata.
> >
> > This series includes the original two patches
> >
> >    http://patchwork.ozlabs.org/patch/1167420/
> >    http://patchwork.ozlabs.org/patch/1167367/
> >
> > as well as a few other patches to fix the build errors. Overall this
> > reduces code size and provides better error messages when unavailable
> > functions are used.
> >
> > Board maintainers should still take a look at the result, adjusting the
> > of-platdata support as needed.
> >
> > Note: This series was resent a year ago but not applied. Since then, some
> > boards have ended up using drivers in SPL which require OF_CONTROL, but
> > SPL_OF_CONTROL is not enabled. So now we have two problems. This series
> > fixes that one also.
> >
> > The problems will keep getting worse if people are not aware that
> > something is wrong. Therefore I think this patch series should be applied
> > ASAP.
>
> OK, so I took 5/6 and 6/6 and fired off a build.  The only fails-to-link
> now are:
> am335x_boneblack_vboot am335x_evm am335x_evm_spiboot
>
> So are all of the other problems still present?  I'm going to look in to
> the am335x failures.

I got a passing build here:

https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/8398

I am wondering if I did something wrong when sending?

Regards,
SImon

Re: [PATCH v6 0/5] of-platdata: Avoid building libfdt

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2165 bytes --]

On Sun, Jul 25, 2021 at 09:57:25PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Sun, 25 Jul 2021 at 14:32, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Sun, Jul 25, 2021 at 10:13:42AM -0600, Simon Glass wrote:
> >
> > > The original patch of this series was sent in September 2019 but
> > > unfortunately caused build problems on some boards, since they don't
> > > comply with the of-platdata rules.
> > >
> > > With of-platdata, the idea is to compile the device tree into C structures
> > > to save space and avoid needing to use libfdt. But some boards use
> > > of-platdata while also using libfdt in a few areas, thus defeating the
> > > purpose of of-platdata.
> > >
> > > This series includes the original two patches
> > >
> > >    http://patchwork.ozlabs.org/patch/1167420/
> > >    http://patchwork.ozlabs.org/patch/1167367/
> > >
> > > as well as a few other patches to fix the build errors. Overall this
> > > reduces code size and provides better error messages when unavailable
> > > functions are used.
> > >
> > > Board maintainers should still take a look at the result, adjusting the
> > > of-platdata support as needed.
> > >
> > > Note: This series was resent a year ago but not applied. Since then, some
> > > boards have ended up using drivers in SPL which require OF_CONTROL, but
> > > SPL_OF_CONTROL is not enabled. So now we have two problems. This series
> > > fixes that one also.
> > >
> > > The problems will keep getting worse if people are not aware that
> > > something is wrong. Therefore I think this patch series should be applied
> > > ASAP.
> >
> > OK, so I took 5/6 and 6/6 and fired off a build.  The only fails-to-link
> > now are:
> > am335x_boneblack_vboot am335x_evm am335x_evm_spiboot
> >
> > So are all of the other problems still present?  I'm going to look in to
> > the am335x failures.
> 
> I got a passing build here:
> 
> https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/8398
> 
> I am wondering if I did something wrong when sending?

I didn't include patches 1-4, in order to get build failures and see
what platforms need fixing.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH v6 0/5] of-platdata: Avoid building libfdt

[Simon Glass]

Hi Tom,

On Mon, 26 Jul 2021 at 06:09, Tom Rini <trini@konsulko.com> wrote:
>
> On Sun, Jul 25, 2021 at 09:57:25PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Sun, 25 Jul 2021 at 14:32, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Sun, Jul 25, 2021 at 10:13:42AM -0600, Simon Glass wrote:
> > >
> > > > The original patch of this series was sent in September 2019 but
> > > > unfortunately caused build problems on some boards, since they don't
> > > > comply with the of-platdata rules.
> > > >
> > > > With of-platdata, the idea is to compile the device tree into C structures
> > > > to save space and avoid needing to use libfdt. But some boards use
> > > > of-platdata while also using libfdt in a few areas, thus defeating the
> > > > purpose of of-platdata.
> > > >
> > > > This series includes the original two patches
> > > >
> > > >    http://patchwork.ozlabs.org/patch/1167420/
> > > >    http://patchwork.ozlabs.org/patch/1167367/
> > > >
> > > > as well as a few other patches to fix the build errors. Overall this
> > > > reduces code size and provides better error messages when unavailable
> > > > functions are used.
> > > >
> > > > Board maintainers should still take a look at the result, adjusting the
> > > > of-platdata support as needed.
> > > >
> > > > Note: This series was resent a year ago but not applied. Since then, some
> > > > boards have ended up using drivers in SPL which require OF_CONTROL, but
> > > > SPL_OF_CONTROL is not enabled. So now we have two problems. This series
> > > > fixes that one also.
> > > >
> > > > The problems will keep getting worse if people are not aware that
> > > > something is wrong. Therefore I think this patch series should be applied
> > > > ASAP.
> > >
> > > OK, so I took 5/6 and 6/6 and fired off a build.  The only fails-to-link
> > > now are:
> > > am335x_boneblack_vboot am335x_evm am335x_evm_spiboot
> > >
> > > So are all of the other problems still present?  I'm going to look in to
> > > the am335x failures.
> >
> > I got a passing build here:
> >
> > https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/8398
> >
> > I am wondering if I did something wrong when sending?
>
> I didn't include patches 1-4, in order to get build failures and see
> what platforms need fixing.

OK, I see. Yes I believe all the problems are still present. If you
like i can add the errors/warnings I saw here.

Regards,
SImon

Re: [PATCH v6 0/5] of-platdata: Avoid building libfdt

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2820 bytes --]

On Mon, Jul 26, 2021 at 07:45:27AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 26 Jul 2021 at 06:09, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Sun, Jul 25, 2021 at 09:57:25PM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Sun, 25 Jul 2021 at 14:32, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Sun, Jul 25, 2021 at 10:13:42AM -0600, Simon Glass wrote:
> > > >
> > > > > The original patch of this series was sent in September 2019 but
> > > > > unfortunately caused build problems on some boards, since they don't
> > > > > comply with the of-platdata rules.
> > > > >
> > > > > With of-platdata, the idea is to compile the device tree into C structures
> > > > > to save space and avoid needing to use libfdt. But some boards use
> > > > > of-platdata while also using libfdt in a few areas, thus defeating the
> > > > > purpose of of-platdata.
> > > > >
> > > > > This series includes the original two patches
> > > > >
> > > > >    http://patchwork.ozlabs.org/patch/1167420/
> > > > >    http://patchwork.ozlabs.org/patch/1167367/
> > > > >
> > > > > as well as a few other patches to fix the build errors. Overall this
> > > > > reduces code size and provides better error messages when unavailable
> > > > > functions are used.
> > > > >
> > > > > Board maintainers should still take a look at the result, adjusting the
> > > > > of-platdata support as needed.
> > > > >
> > > > > Note: This series was resent a year ago but not applied. Since then, some
> > > > > boards have ended up using drivers in SPL which require OF_CONTROL, but
> > > > > SPL_OF_CONTROL is not enabled. So now we have two problems. This series
> > > > > fixes that one also.
> > > > >
> > > > > The problems will keep getting worse if people are not aware that
> > > > > something is wrong. Therefore I think this patch series should be applied
> > > > > ASAP.
> > > >
> > > > OK, so I took 5/6 and 6/6 and fired off a build.  The only fails-to-link
> > > > now are:
> > > > am335x_boneblack_vboot am335x_evm am335x_evm_spiboot
> > > >
> > > > So are all of the other problems still present?  I'm going to look in to
> > > > the am335x failures.
> > >
> > > I got a passing build here:
> > >
> > > https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/8398
> > >
> > > I am wondering if I did something wrong when sending?
> >
> > I didn't include patches 1-4, in order to get build failures and see
> > what platforms need fixing.
> 
> OK, I see. Yes I believe all the problems are still present. If you
> like i can add the errors/warnings I saw here.

Please. https://source.denx.de/u-boot/u-boot/-/jobs/298139 are the only
errors I saw at build time when not using the patches to turn build time
in to run time problems.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH v6 2/5] net: atheros: Add a check for OF_CONTROL

[Ramon Fried]

On Sun, Jul 25, 2021 at 7:14 PM Simon Glass <sjg@chromium.org> wrote:
>
> This phy cannot be used when OF_CONTROL is not enabled. A few boards
> expect it to build, though, so add a runtime check for this case.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v6:
> - Add new patch for atheros
>
>  drivers/net/phy/atheros.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>
> diff --git a/drivers/net/phy/atheros.c b/drivers/net/phy/atheros.c
> index f922fecd6b5..cc772f3060f 100644
> --- a/drivers/net/phy/atheros.c
> +++ b/drivers/net/phy/atheros.c
> @@ -7,6 +7,7 @@
>   * Copyright (c) 2019 Michael Walle <michael@walle.cc>
>   */
>  #include <common.h>
> +#include <log.h>
>  #include <phy.h>
>  #include <dm/device_compat.h>
>  #include <linux/bitfield.h>
> @@ -197,6 +198,16 @@ static int ar803x_of_init(struct phy_device *phydev)
>         u32 strength, freq, min_uV, max_uV;
>         int sel;
>
> +       /*
> +        * This driver requires OF_CONTROL but this is included on some boards
> +        * that don't support it in SPL. Return an error so the board vendor
> +        * can resolve this.
> +        */
> +       if (!CONFIG_IS_ENABLED(OF_CONTROL)) {
> +               log_err("atheros driver requires OF_CONTROL enabled");
> +               return -ENOSYS;
> +       }
> +
>         node = phy_get_ofnode(phydev);
>         if (!ofnode_valid(node))
>                 return -EINVAL;
> --
> 2.32.0.432.gabb21c7263-goog
>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>

Re: [PATCH v6 0/5] of-platdata: Avoid building libfdt

[Simon Glass]

Hi Tom,

On Mon, 26 Jul 2021 at 08:43, Tom Rini <trini@konsulko.com> wrote:
>
> On Mon, Jul 26, 2021 at 07:45:27AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, 26 Jul 2021 at 06:09, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Sun, Jul 25, 2021 at 09:57:25PM -0600, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Sun, 25 Jul 2021 at 14:32, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Sun, Jul 25, 2021 at 10:13:42AM -0600, Simon Glass wrote:
> > > > >
> > > > > > The original patch of this series was sent in September 2019 but
> > > > > > unfortunately caused build problems on some boards, since they don't
> > > > > > comply with the of-platdata rules.
> > > > > >
> > > > > > With of-platdata, the idea is to compile the device tree into C structures
> > > > > > to save space and avoid needing to use libfdt. But some boards use
> > > > > > of-platdata while also using libfdt in a few areas, thus defeating the
> > > > > > purpose of of-platdata.
> > > > > >
> > > > > > This series includes the original two patches
> > > > > >
> > > > > >    http://patchwork.ozlabs.org/patch/1167420/
> > > > > >    http://patchwork.ozlabs.org/patch/1167367/
> > > > > >
> > > > > > as well as a few other patches to fix the build errors. Overall this
> > > > > > reduces code size and provides better error messages when unavailable
> > > > > > functions are used.
> > > > > >
> > > > > > Board maintainers should still take a look at the result, adjusting the
> > > > > > of-platdata support as needed.
> > > > > >
> > > > > > Note: This series was resent a year ago but not applied. Since then, some
> > > > > > boards have ended up using drivers in SPL which require OF_CONTROL, but
> > > > > > SPL_OF_CONTROL is not enabled. So now we have two problems. This series
> > > > > > fixes that one also.
> > > > > >
> > > > > > The problems will keep getting worse if people are not aware that
> > > > > > something is wrong. Therefore I think this patch series should be applied
> > > > > > ASAP.
> > > > >
> > > > > OK, so I took 5/6 and 6/6 and fired off a build.  The only fails-to-link
> > > > > now are:
> > > > > am335x_boneblack_vboot am335x_evm am335x_evm_spiboot
> > > > >
> > > > > So are all of the other problems still present?  I'm going to look in to
> > > > > the am335x failures.
> > > >
> > > > I got a passing build here:
> > > >
> > > > https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/8398
> > > >
> > > > I am wondering if I did something wrong when sending?
> > >
> > > I didn't include patches 1-4, in order to get build failures and see
> > > what platforms need fixing.
> >
> > OK, I see. Yes I believe all the problems are still present. If you
> > like i can add the errors/warnings I saw here.
>
> Please. https://source.denx.de/u-boot/u-boot/-/jobs/298139 are the only
> errors I saw at build time when not using the patches to turn build time
> in to run time problems.

Yes I see the same thing now.

I suspect I didn't have the latest master when I started and some
boards have been removed.

Do you want to just take the patches that make sense from this series?

Regards,
Simon

Re: [PATCH v6 0/5] of-platdata: Avoid building libfdt

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3571 bytes --]

On Sat, Jul 31, 2021 at 05:07:41PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 26 Jul 2021 at 08:43, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Mon, Jul 26, 2021 at 07:45:27AM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Mon, 26 Jul 2021 at 06:09, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Sun, Jul 25, 2021 at 09:57:25PM -0600, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Sun, 25 Jul 2021 at 14:32, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Sun, Jul 25, 2021 at 10:13:42AM -0600, Simon Glass wrote:
> > > > > >
> > > > > > > The original patch of this series was sent in September 2019 but
> > > > > > > unfortunately caused build problems on some boards, since they don't
> > > > > > > comply with the of-platdata rules.
> > > > > > >
> > > > > > > With of-platdata, the idea is to compile the device tree into C structures
> > > > > > > to save space and avoid needing to use libfdt. But some boards use
> > > > > > > of-platdata while also using libfdt in a few areas, thus defeating the
> > > > > > > purpose of of-platdata.
> > > > > > >
> > > > > > > This series includes the original two patches
> > > > > > >
> > > > > > >    http://patchwork.ozlabs.org/patch/1167420/
> > > > > > >    http://patchwork.ozlabs.org/patch/1167367/
> > > > > > >
> > > > > > > as well as a few other patches to fix the build errors. Overall this
> > > > > > > reduces code size and provides better error messages when unavailable
> > > > > > > functions are used.
> > > > > > >
> > > > > > > Board maintainers should still take a look at the result, adjusting the
> > > > > > > of-platdata support as needed.
> > > > > > >
> > > > > > > Note: This series was resent a year ago but not applied. Since then, some
> > > > > > > boards have ended up using drivers in SPL which require OF_CONTROL, but
> > > > > > > SPL_OF_CONTROL is not enabled. So now we have two problems. This series
> > > > > > > fixes that one also.
> > > > > > >
> > > > > > > The problems will keep getting worse if people are not aware that
> > > > > > > something is wrong. Therefore I think this patch series should be applied
> > > > > > > ASAP.
> > > > > >
> > > > > > OK, so I took 5/6 and 6/6 and fired off a build.  The only fails-to-link
> > > > > > now are:
> > > > > > am335x_boneblack_vboot am335x_evm am335x_evm_spiboot
> > > > > >
> > > > > > So are all of the other problems still present?  I'm going to look in to
> > > > > > the am335x failures.
> > > > >
> > > > > I got a passing build here:
> > > > >
> > > > > https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/8398
> > > > >
> > > > > I am wondering if I did something wrong when sending?
> > > >
> > > > I didn't include patches 1-4, in order to get build failures and see
> > > > what platforms need fixing.
> > >
> > > OK, I see. Yes I believe all the problems are still present. If you
> > > like i can add the errors/warnings I saw here.
> >
> > Please. https://source.denx.de/u-boot/u-boot/-/jobs/298139 are the only
> > errors I saw at build time when not using the patches to turn build time
> > in to run time problems.
> 
> Yes I see the same thing now.
> 
> I suspect I didn't have the latest master when I started and some
> boards have been removed.
> 
> Do you want to just take the patches that make sense from this series?

It gets back to figuring out something to do for am335x_evm.  I need to
post the fixes for the other two defconfigs as well.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]