[PATCH v2 01/39] RFC: efi: Drop code that doesn't work with driver model

Tom Rini trini at konsulko.com
Fri Oct 14 17:34:44 CEST 2022


On Fri, Oct 14, 2022 at 05:27:39PM +0200, Jan Kiszka wrote:
> On 14.10.22 17:20, Tom Rini wrote:
> > On Fri, Oct 14, 2022 at 05:10:55PM +0200, Heinrich Schuchardt wrote:
> >> On 10/14/22 13:51, Jan Kiszka wrote:
> >>> On 21.10.21 01:34, Heinrich Schuchardt wrote:
> >>>> On 9/25/21 2:30 AM, Simon Glass wrote:
> >>>>> This code should never have been added as it builds a new feature on top
> >>>>> of legacy code. This has already been improved with the dependency on
> >>>>> BLK.
> >>>>>
> >>>>> Add a dependency on DM_ETH also, to avoid needing to deal with this old
> >>>>> code.
> >>>>>
> >>>>> Boards which want EFI_LOADER should migrate to driver model first.
> >>>>>
> >>>>> Note this patch is included to resolve the following build error:
> >>>>>
> >>>>> lib/efi_loader/efi_runtime.c:680:16: error: ‘CONFIG_SYS_TEXT_BASE’
> >>>>>      undeclared (first use in this function); did you mean
> >>>>>      ‘CONFIG_SYS_SRAM_BASE’?
> >>>>>     680 |   ulong base = CONFIG_SYS_TEXT_BASE;
> >>>>>         |                ^~~~~~~~~~~~~~~~~~~~
> >>>>>         |                CONFIG_SYS_SRAM_BASE
> >>>>>
> >>>>> Signed-off-by: Simon Glass <sjg at chromium.org>
> >>>>
> >>>> Reviewed-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
> >>>>
> >>>
> >>> How to deal with boards that need CONFIG_NET but do not actually
> >>> implement any driver (yet)? This now broke UEFI for the IOT2050 which
> >>> needs NET for network-related device tree setup (see also [1]) and
> >>> enforces a local hack for us.
> >>
> >> UEFI will not provide network without a DM driver.
> >> The migration period ended 2020.07.
> >>
> >> make iot2050_defconfig set EFI_LOADER=y.
> >> What does not work in UEFI?
> >>
> >> Are you missing a way to call eth_get_dev() to trigger aforementioned
> >> devicetree setup?
> >>
> >> Adding 'net list' to CONFIG_PREBOOT might do the trick.
> > 
> > I think, and this is why I suggested NETDEVICES, the issue is that there
> > is no network driver in U-Boot, but we need to have networking support
> > enabled in general, in order to perform device tree fixups for Linux
> > where there is the network driver.
> > 
> 
> Exactly.
> 
> Unfortunately, NETDEVICES does not do the trick because it selects
> DM_ETH anyway, thus you don't detect legacy network drivers this way.

Right, but does your platform enable NETDEVICES? It sounds like it
shouldn't be since you don't have devices in U-Boot? Or something else?

-- 
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/20221014/dee95181/attachment.sig>


More information about the U-Boot mailing list