On Fri, Aug 09, 2024 at 03:19:02PM +0200, Jerome Forissier wrote: > > > On 8/8/24 19:24, Tom Rini wrote: > > On Thu, Aug 08, 2024 at 06:41:02PM +0200, Jerome Forissier wrote: > >> > >> > >> On 8/7/24 22:44, Tom Rini wrote: > >>> On Wed, Aug 07, 2024 at 07:11:44PM +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 > >>> > >>> For v9, I think it would be good to do a CI run with NET_LWIP default > >>> and seeing what fails from that too. There's a few problems still > >>> leading to a lot of failures, in that case. Thanks. > >> > >> I pushed my branch to GitHub [1] and there's a failure in the > >> tools_only_macOS job [2]. Any idea what is going on? I tried twice and > >> it failed twice :-/ > >> Om my Linux machine, "make tools-only_config tools-only" works > >> fine. > >> > >> [1] https://github.com/u-boot/u-boot/pull/635 > >> [2] > >> https://dev.azure.com/u-boot/u-boot/_build/results?buildId=9105&view=results > > > > Alright so from [2] going to the job and then downloading the raw log (it's > > huge, firefox gets mad for me), scrolling down until it's not the git clone > > we > > see: > > 2024-08-08T14:36:30.0865130Z HOSTCC scripts/basic/fixdep > > 2024-08-08T14:36:30.8641660Z HOSTCC scripts/kconfig/conf.o > > 2024-08-08T14:36:30.9645180Z LEX scripts/kconfig/zconf.lex.c > > 2024-08-08T14:36:31.0545650Z YACC scripts/kconfig/zconf.tab.c > > 2024-08-08T14:36:33.2374910Z HOSTCC scripts/kconfig/zconf.tab.o > > 2024-08-08T14:36:34.9997050Z HOSTLD scripts/kconfig/conf > > 2024-08-08T14:36:36.5552790Z generated_defconfig:7:warning: unexpected > > data: # CONFIG_SANDBOX_ > > SDL is not set > > 2024-08-08T14:36:36.5666380Z generated_defconfig:12:warning: unexpected > > data: # CONFIG_BOOTSTD > > _FULL is not set > > 2024-08-08T14:36:36.5724560Z generated_defconfig:13:warning: unexpected > > data: # CONFIG_BOOTMET > > H_CROS is not set > > 2024-08-08T14:36:36.5742720Z generated_defconfig:14:warning: unexpected > > data: # CONFIG_BOOTMET > > H_VBE is not set > > 2024-08-08T14:36:36.5752700Z generated_defconfig:17:warning: unexpected > > data: # CONFIG_CMD_BOO > > TD is not set > > 2024-08-08T14:36:36.5772400Z generated_defconfig:18:warning: unexpected > > data: # CONFIG_CMD_BOO > > TM is not set > > 2024-08-08T14:36:36.5788060Z generated_defconfig:19:warning: unexpected > > data: # CONFIG_CMD_BOO > > TI is not set > > 2024-08-08T14:36:36.5792360Z generated_defconfig:20:warning: unexpected > > data: # CONFIG_CMD_ELF > > is not set > > 2024-08-08T14:36:36.5828400Z generated_defconfig:21:warning: unexpected > > data: # CONFIG_CMD_EXTENSION is not set > > 2024-08-08T14:36:36.5840470Z generated_defconfig:22:warning: unexpected > > data: # CONFIG_CMD_DAT > > E is not set > > 2024-08-08T14:36:36.5938540Z generated_defconfig:26:warning: unexpected > > data: # CONFIG_ACPIGEN > > is not set > > 2024-08-08T14:36:36.5974000Z generated_defconfig:35:warning: unexpected > > data: # CONFIG_VIRTIO_MMIO is not set > > 2024-08-08T14:36:36.5985430Z generated_defconfig:36:warning: unexpected > > data: # CONFIG_VIRTIO_PCI is not set > > 2024-08-08T14:36:36.6045140Z generated_defconfig:37:warning: unexpected > > data: # CONFIG_VIRTIO_SANDBOX is not set > > 2024-08-08T14:36:36.6053060Z generated_defconfig:38:warning: unexpected > > data: # CONFIG_GENERATE_ACPI_TABLE is not set > > 2024-08-08T14:36:36.6068760Z generated_defconfig:39:warning: unexpected > > data: # CONFIG_EFI_LOADER is not set > > 2024-08-08T14:36:36.6088140Z # > > 2024-08-08T14:36:36.6121560Z # configuration written to .config > > 2024-08-08T14:36:36.6130190Z # > > 2024-08-08T14:36:42.5830900Z scripts/kconfig/conf --syncconfig Kconfig > > 2024-08-08T14:36:43.9105630Z .config:284:warning: symbol value '' invalid > > for AVB_BUF_ADDR > > 2024-08-08T14:36:43.9121120Z .config:285:warning: symbol value '' invalid > > for AVB_BUF_SIZE > > 2024-08-08T14:36:43.9142940Z * > > 2024-08-08T14:36:43.9172380Z * Restart config... > > 2024-08-08T14:36:43.9257450Z * > > 2024-08-08T14:36:43.9288610Z * > > 2024-08-08T14:36:43.9332910Z * Security support > > 2024-08-08T14:36:43.9366750Z * > > 2024-08-08T14:36:43.9399770Z Build Android Verified Boot operations > > (AVB_VERIFY) [Y/n/?] y > > 2024-08-08T15:35:07.9280210Z ##[error]The Operation will be canceled. The > > next steps may not contain expected logs. > > > > And indeed, most of that is "normal" if we look at a current build for > > tools-only on macOS. We're being hit by the fact that the host CC isn't > > gcc and is llvm and https://github.com/llvm/llvm-project/issues/78778 > > applies, I believe. Now how do we work around this? Hum... > > That's an "interesting" bug... > > > If you go an change "# CONFIG_FOO is not set" to CONFIG_FOO=n in > > configs/tools-only_defconfig, I assume your build moves on? > > Yep, it does.
OK, good. > > This is > > valid syntax and fixing a more generic issue we have on macOS today. > > I am adding a new patch to v9: "configs: use syntax CONFIG_FOO=n in > tools-only_defconfig". It means one extra step when syncing the > defconfigs though... It is just a simple sed command but perhaps you > have a better idea? This should be fine, there's already a number of configs I have to un-sync when I do a re-sync. > Thanks again for testing and for your help, You're welcome. Tom
signature.asc
Description: PGP signature
