[PATCH v5 00/20] Introduce the lwIP network stack

Jerome Forissier jerome.forissier at linaro.org
Thu Aug 1 17:15:34 CEST 2024



On 8/1/24 16:43, Tom Rini wrote:
> On Thu, Aug 01, 2024 at 04:40:03PM +0200, Jerome Forissier wrote:
>>
>>
>> On 7/26/24 00:34, Tom Rini wrote:
>>> On Thu, Jul 25, 2024 at 11:22:20AM -0600, Tom Rini wrote:
>>>> On Thu, Jul 25, 2024 at 02:57:21PM +0200, Jerome Forissier wrote:
>>>>
>>>>> This is a rework of a patch series by Maxim Uvarov: "net/lwip: add lwip
>>>>> library for the network stack" [1]. The goal is to introduce the lwIP TCP/IP
>>>>> stack [2] [3] as an alternative to the current implementation in net/,
>>>>> selectable with Kconfig, and ultimately keep only lwIP if possible. Some
>>>>> reasons for doing so are:
>>>>> - Make the support of HTTPS in the wget command easier. Javier T. and
>>>>> Raymond M. (CC'd) have some additional lwIP and Mbed TLS patches to do
>>>>> so. With that it becomes possible to fetch and launch a distro installer
>>>>> such as Debian etc. using a secure, authenticated connection directly
>>>>> from the U-Boot shell. Several use cases:
>>>>>   * Authentication: prevent MITM attack (third party replacing the
>>>>> binary with a different one)
>>>>>   * Confidentiality: prevent third parties from grabbing a copy of the
>>>>> image as it is being downloaded
>>>>>   * Allow connection to servers that do not support plain HTTP anymore
>>>>> (this is becoming more and more common on the Internet these days)
>>>>> - Possibly benefit from additional features implemented in lwIP
>>>>> - Less code to maintain in U-Boot
>>>>>
>>>>> Prior to applying this series, the lwIP stack needs to be added as a
>>>>> Git subtree with the following command:
>>>>>
>>>>>  $  git subtree add --squash --prefix lib/lwip/lwip https://git.savannah.gnu.org/git/lwip.git STABLE-2_2_0_RELEASE
>>>>
>>>> This is better than v4, and on the hardware platforms I could build and
>>>> boot on (which was most of mine except the am62x_beagleplay), the tests
>>>> ran and completed, including the tftp+boot a Linux kernel.
>>>>
>>>> The bad news is CI blows up, a lot:
>>>> https://source.denx.de/u-boot/u-boot/-/pipelines/21764
>>>> And:
>>>> https://dev.azure.com/u-boot/a1096300-2999-4ec4-a21a-4c22075e3771/_apis/build/builds/9014/logs/106
>>>> which is another Kconfig dependency problem. I don't _think_ I
>>>> introduced that, but since this wasn't against top of tree, I had to
>>>> apply the cmd/Kconfig patch manually.
>>>>
>>>> I have my world build running still and may have more comments based on
>>>> that.
>>>
>>> First, with NET_LWIP being default rather than NET, there's a lot of
>>> other Kconfig dependency issues. Unfortunately I don't see an easy tool
>>> for making sure this is all clean aside from a shell loop like:
>>> for C in `(cd configs;ls)`;do make -s $C;done
>>
>> I have run this loop successfully with the upcoming v6 version. Some
>> configs do print some warnings but there is no error.
> 
> Those warnings are the problem, I wasn't clear, sorry. If I could make
> it error, I would since then CI would catch it.

v6 won't add any warning besides the ones in the new
qemu_arm64_lwip_defconfig file that you said were OK:

$ git co origin/next
$ for C in `(cd configs;ls)`;do echo $C...; make -s $C || break;done 2>&1 | tee configs_next.log
$ git checkout to-upstream/v6-wip
$ for C in `(cd configs;ls)`;do echo $C...; make -s $C || break;done 2>&1 | tee configs.log
$ diff -u configs_next.log configs.log
--- configs_next.log    2024-08-01 17:10:50.903533652 +0200
+++ configs.log 2024-08-01 17:03:55.497799493 +0200
@@ -2016,6 +2016,11 @@
 q8_a33_tablet_800x480_defconfig...
 qcom_defconfig...
 qemu_arm64_defconfig...
+qemu_arm64_lwip_defconfig...
+generated_defconfig:71:warning: override: reassigning to symbol ARM
+generated_defconfig:71:warning: override: ARM changes choice state
+generated_defconfig:72:warning: override: reassigning to symbol ARCH_QEMU
+generated_defconfig:72:warning: override: ARCH_QEMU changes choice state
 qemu_arm_defconfig...
 qemu-ppce500_defconfig...
 qemu-riscv32_defconfig...

Thanks,
-- 
Jerome


More information about the U-Boot mailing list