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

Tom Rini trini at konsulko.com
Mon Jul 26 16:43:37 CEST 2021


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 at 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210726/c501f0cd/attachment.sig>


More information about the U-Boot mailing list