Date: Tue, 8 Mar 2022 22:00:35 -0500 From: Tom Rini trini@konsulko.com
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 trini@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 smoch@web.de wrote:
On 08.03.22 17:56, Simon Glass wrote:
Hi,
On Tue, 8 Mar 2022 at 09:49, Heinrich Schuchardt xypron.glpk@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.
And neither should there be. OF_EMBED is the obvious choice when chainloading U-Boot from a proprietary initial loader that loads ELF binaries.