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

From: Tom Rini <trini@konsulko.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>,
	Bin Meng <bmeng.cn@gmail.com>,
	Christian Melki <christian.melki@t2data.com>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	U-Boot Mailing List <u-boot@lists.denx.de>,
	Alexander Graf <agraf@csgraf.de>, Simon Glass <sjg@chromium.org>
Subject: Re: [PATCH v2 01/39] RFC: efi: Drop code that doesn't work with driver model
Date: Fri, 14 Oct 2022 11:38:42 -0400	[thread overview]
Message-ID: <20221014153842.GV2020586@bill-the-cat> (raw)
In-Reply-To: <93359f56-b4c8-586d-ea77-cff9808d2e4b@siemens.com>

[-- Attachment #1: Type: text/plain, Size: 2984 bytes --]

On Fri, Oct 14, 2022 at 05:35:43PM +0200, Jan Kiszka wrote:
> On 14.10.22 17:34, Tom Rini wrote:
> > 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@chromium.org>
> >>>>>>
> >>>>>> Reviewed-by: Heinrich Schuchardt <xypron.glpk@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?
> > 
> 
> NETDEVICES is off, obviously.

Right, so, this patch should make the EFI code test for NETDEVICES and
not NET, and then you wouldn't need to hack in something on your
platform I think.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]