[PATCH v6 0/5] of-platdata: Avoid building libfdt
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(-)
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;
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;
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
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);
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
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
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.
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
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.
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
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.
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
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.
participants (3)
-
Ramon Fried -
Simon Glass -
Tom Rini