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

From: Jan Kiszka <jan.kiszka@siemens.com>
To: Tom Rini <trini@konsulko.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 17:35:43 +0200	[thread overview]
Message-ID: <93359f56-b4c8-586d-ea77-cff9808d2e4b@siemens.com> (raw)
In-Reply-To: <20221014153444.GU2020586@bill-the-cat>

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.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux