On Tue, Dec 17, 2024 at 01:17:42PM -0700, Simon Glass wrote: > Hi Tom, > > On Tue, 17 Dec 2024 at 12:57, Tom Rini <[email protected]> wrote: > > > > On Tue, Dec 17, 2024 at 12:46:17PM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Tue, 17 Dec 2024 at 07:25, Tom Rini <[email protected]> wrote: > > > > > > > > On Tue, Dec 17, 2024 at 08:00:56AM -0600, Simon Glass wrote: > > > > > > > > > While we do plan to switch to OF_SEPARATE now it is supported, it > > > > > seems > > > > > worth at least showing how OF_EMBED could be used instead, just for > > > > > the > > > > > record. > > > > > > > > > > So make the Makefile rule conditional on OF_SEPARATE and adjust fdtdec > > > > > to avoid a build error when OF_EMBED is used. > > > > > > > > > > Finally. the dtb symbol has a double underscore, so update it to > > > > > avoid a > > > > > build warning. > > > > > > > > > > With future patches, OF_EMBED will no-longer be used with the EFI app, > > > > > so it is expected that it will eventually stop working. > > > > > > > > > > Signed-off-by: Simon Glass <[email protected]> > > > > > Fixes: 2e7bf25f6bf ("Support separate DTB files with the UEFI app") > > > > > --- > > > > > > > > > > Makefile | 2 +- > > > > > include/asm-generic/sections.h | 2 +- > > > > > lib/fdtdec.c | 2 +- > > > > > 3 files changed, 3 insertions(+), 3 deletions(-) > > > > > > > > > > Applied to sjg/master, thanks! > > > > > > > > Since you've picked up several series that no one was objecting to and > > > > providing reasonable feedback on and applied them to your own tree, do > > > > you plan to squash/rebase them and repost so they can be applied to > > > > master / next at some point? > > > > > > The original EFI-app series actually had objections in toto. Did you > > > not see the comments from Heinrich? > > > > I assume you mean: > > https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/#3419029 > > which is a question. > > Apart from the general tone, it was mostly the cover letter.
Which is https://patchwork.ozlabs.org/project/uboot/cover/[email protected]/#3418939 and an open question to explain the use case more. > > > I've offered to send pull requests every now and then, to keep things > > > in sync, if that is your goal? But I don't believe I can do that for > > > particular patches/series. It is going to be hard enough for me to > > > just maintain my own tree, let along dealing with your/Linaro tree. > > > > I find you calling the mainline project tree "your/Linaro tree" > > offensive. And I'm again asking you to explain in public what you are > > doing exactly. > > I'm sorry you are offended. Please suggest a better name that I can > use. Honestly, from my point of view, it feels like a > Linaro-controlled tree. There's nothing particularly wrong with that, > but I would like the freedom to continue to innovate U-Boot, without > Linaro telling me what to do. Does that sound OK to you? It's mainline. The tree at https://source.denx.de/u-boot/u-boot is the mainline tree for the Das U-Boot project, and I am the maintainer of that tree and the nominal head of the U-Boot project. If you want to ignore the feedback you have been given by other people to do whatever you like, please don't call it U-Boot. It is not "Linaro" disagreeing with your ideas, it's a number of people. It's most frequently myself (neither I nor my company get any money from Linaro, nor Arm Ltd), Heinrich (employed at Canonical, like you) or Ilias (yes, Linaro). While I am open to, and am exploring how to formally change the project from the old fashioned "Benevolent Dictator For Life" model to something that reflects modern project management, Wolfgang passed the project hat down to me a long time ago. If you don't like my leadership, moving past the BDFL model and to something else will give you a chance to take the reigns, so to speak. -- Tom
signature.asc
Description: PGP signature
