Hi Tom, On Tue, 8 Mar 2022 at 20:10, Simon Glass <s...@chromium.org> wrote: > > Hi Tom, > > On Tue, 8 Mar 2022 at 20:00, Tom Rini <tr...@konsulko.com> wrote: > > > > On Tue, Mar 08, 2022 at 07:32:59PM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Tue, 8 Mar 2022 at 17:13, Tom Rini <tr...@konsulko.com> wrote: > > > > > > > > On Tue, Mar 08, 2022 at 02:20:15PM -0700, Simon Glass wrote: > > > > > Hi Soeren, > > > > > > > > > > On Tue, 8 Mar 2022 at 12:15, Soeren Moch <sm...@web.de> wrote: > > > > > > > > > > > > > > > > > > > > > > > > On 08.03.22 17:56, Simon Glass wrote: > > > > > > > Hi, > > > > > > > > > > > > > > On Tue, 8 Mar 2022 at 09:49, Heinrich Schuchardt > > > > > > > <xypron.g...@gmx.de> wrote: > > > > > > >> > > > > > > >> On 3/8/22 12:36, AKASHI Takahiro wrote: > > > > > > >>> With this patch set[1] applied, UEFI subsystem maintains a list > > > > > > >>> of its > > > > > > >>> disk objects dynamically at runtime based on block device's > > > > > > >>> probing. > > > > > > >>> (See "issues" below.) > > > > > > >>> > > > > > > >>> [1]https://github.com/t-akashi/u-boot/tree/efi/dm_disk > > > > > > >> > > > > > > >> This series together with Simon's series breaks multiple boards > > > > > > >> due to > > > > > > >> size constraints: > > > > > > >> > > > > > > >> https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/11197 > > > > > > >> > > > > > > >> Please, investigate how to work around this issue. > > > > > > > > > > > > > > tbs2910 - perhaps we should just drop this board? It doesn't use > > > > > > > DM_SERIAL and still uses OF_EMBED > > > > > > > > > > > > Are we again at the same point? You are breaking working boards with > > > > > > (for these boards) useless additions, and all you come up with is > > > > > > "remove this board". Of course without adding the board maintainer. > > > > > > > > > > I'm just expressing reasonable frustration that this board uses > > > > > OF_EMBED and does not use DM_SERIAL, after all of this time. Why > > > > > should the rest of the U-Boot developers care more about this board > > > > > than the maintainer? > > > > > > > > Please keep in mind Simon that we've had zero releases with the > > > > DM_SERIAL migration warning being posted, v2022.04 will be the first > > > > one. > > > > > > Yes, understood :-) For OF_EMBED though...? > > > > No deadline and 50 boards. > > Er, there has been a build message about that since the beginning, so > people ignored it. Do we really need to make the build fail for these > sorts of things? Perhaps so, but it is a sad situation. > > > > > > It was actually quite hard to add a migration message until we added > > > the CONFIG_SERIAL base thing and that was a pain to do. > > > > > > For those of us who take on larger refactors etc., we end up spending > > > a lot of our time on these few platforms. I'm not picking on tbs2910in > > > in particular. > > > > Well, the flip side of the problem here is that there's a number of > > platforms with real constraints to them and it keeps being "can we drop > > this yet?" without CC'ing the board maintainer on the series that once > > again pushes a given platform to the limit. I would expect no size > > growth to tbs2910 for the topic of this series since it disables > > EFI_LOADER entirely, so why is it a problem? > > The partition changes are going to add some size anyway, I expect. I > have not actually analysed it though. Perhaps we can just disable a > filesystem?
One more thing, if we get around to supporting file access through a device that is also going to add some size, although perhaps not a huge amount. Regards, SImon > Simon
