Hi Tom, Takahiro,
On Wed, 9 Mar 2022 at 08:33, Simon Glass sjg@chromium.org wrote:
Hi Tom,
On Wed, 9 Mar 2022 at 07:25, Tom Rini trini@konsulko.com wrote:
On Tue, Mar 08, 2022 at 08:10:38PM -0700, Simon Glass wrote:
Hi Tom,
On Tue, 8 Mar 2022 at 20:00, Tom Rini trini@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 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.
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.
Yes, in hind-sight, "don't do that" wasn't the right path. It would be a good idea to start a different thread and see what / how the platforms can be migrated away.
I think there is a use case for it now - e.g. booting Apple M1 which uses a separate bootloader. IMO a .img or .fit file would be better in some cases but people seem to be allergic to implementing U-Boot things in their code bases. We have the same requirement for the EFI app since UEFI does not implement the U-Boot .img file.
So if we are going to support this, perhaps we should create a new option for it. But honestly I am just too weary to consider yet another migration. We need to finish some, e.g. Kconfig.
Back to the original topic, I found that some partition code is present in SPL and cannot be dropped. This is a long-standing thing but matters a little more now that there is a driver and blk_post_probe() contains some code.
This series is foundational in two ways:
- adding driver model support for partitions - starting the clean-up of the EFI code to better use drive rmodel
Heinrich, can we please hold off on any new EFI changes in -next until we can get this series landed? Any conflicts will set us back again.
I will see if I can send a little series to clean that up and to reduce the board sizes for the non-SPL problems. With that, perhaps we can apply both series within a few days?
[..]
Regards, Simon