Re: [PATCH v3 7/8] board: ti: Pull redundant DDR functions to a common location and Fixup DDR size when ECC is enabled
Hi, Wadim,
Thanks for the review.
On 30/05/24 17:48, Wadim Egorov wrote:
Hi Santhosh,
thanks for this series!
Am 23.05.24 um 07:04 schrieb Santhosh Kumar K:
As there are few redundant functions in board/ti/*/evm.c files, pull
them to a common location of access to reuse and include the common file
to access the functions.
Call k3-ddrss driver through fixup_ddr_driver_for_ecc() to fixup the
device tree and resize the available amount of DDR, if ECC is enabled.
Otherwise, fixup the device tree using the regular
fdt_fixup_memory_banks().
Also call dram_init_banksize() after every call to
fixup_ddr_driver_for_ecc() is made so that gd->bd is populated
correctly.
Ensure that fixup_ddr_driver_for_ecc() is agnostic to the number of DDR
controllers present.
Signed-off-by: Santhosh Kumar K
Signed-off-by: Neha Malcom Francis
---
[...]
+++ b/board/ti/common/k3-ddr-init.c
@@ -0,0 +1,89 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023, Texas Instruments Incorporated -
https://www.ti.com/
+ */
+
+#include
+#include
+#include
+#include
+
+#include "k3-ddr-init.h"
+
+int dram_init(void)
+{
+ s32 ret;
+
+ ret = fdtdec_setup_mem_size_base_lowest();
+ if (ret)
+ printf("Error setting up mem size and base. %d\n", ret);
+
+ return ret;
+}
+
+int dram_init_banksize(void)
+{
+ s32 ret;
+
+ ret = fdtdec_setup_memory_banksize();
+ if (ret)
+ printf("Error setting up memory banksize. %d\n", ret);
+
+ return ret;
+}
I'm wondering if we can generalize more.
What do you say if we keep dram_init() & dram_init_banksize() in the
board code and move fixup_ddr_driver_for_ecc() & fixup_memory_node() to
mach-k3 and make them available for all K3 based boards?
It looks like I will reuse the code for our boards and I assume other
vendors too.
Regards,
Wadim
Yeah, makes sense, will work on it and post v4.
Regards,
Santhosh.
+
+#if defined(CONFIG_SPL_BUILD)
+
+void fixup_ddr_driver_for_ecc(struct spl_image_info *spl_image)
+{
+ struct udevice *dev;
+ int ret, ctr = 1;
+
+ dram_init_banksize();
+
+ ret = uclass_get_device(UCLASS_RAM, 0, );
+ if (ret)
+ panic("Cannnot get RAM device for ddr size fixup: %d\n", ret);
+
+ ret = k3_ddrss_ddr_fdt_fixup(dev, spl_image->fdt_addr, gd->bd);
+ if (ret)
+ printf("Error fixing up ddr node for ECC use! %d\n", ret);
+
+ dram_init_banksize();
+
+ ret = uclass_next_device_err();
+
+ while (!ret) {
+ ret = k3_ddrss_ddr_fdt_fixup(dev, spl_image->fdt_addr, gd->bd);
+ if (ret)
+ printf("Error fixing up ddr node %d for ECC use! %d\n",
ctr, ret);
+
+ dram_init_banksize();
+ ret = uclass_next_device_err();
+ ctr++;
+ }
+}
+
+void fixup_memory_node(struct spl_image_info *spl_image)
+{
+ u64 start[CONFIG_NR_DRAM_BANKS];
+ u64 size[CONFIG_NR_DRAM_BANKS];
+ int bank;
+ int ret;
+
+ dram_init();
+ dram_init_banksize();
+
+ for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) {
+ start[bank] = gd->bd->bi_dram[bank].start;
+ size[bank] = gd->bd->bi_dram[bank].size;
+ }
+
+ ret = fdt_fixup_memory_banks(spl_image->fdt_addr, start, size,
+ CONFIG_NR_DRAM_BANKS);
+
+ if (ret)
+ printf("Error fixing up memory node! %d\n", ret);
+}
+
+#endif
diff --git a/board/ti/common/k3-ddr-init.h
b/board/ti/common/k3-ddr-init.h
new file mode 100644
index ..9d1826815dfd
--- /dev/null
+++ b/board/ti/common/k3-ddr-init.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2023, Texas Instruments Incorporated -
https://www.ti.com/
+ */
+
+#ifndef __K3_DDR_INIT_H
+#define __K3_DDR_INIT_H
+
+int dram_init(void);
+int dram_init_banksize(void);
+
+void fixup_ddr_driver_for_ecc(struct spl_image_info *spl_image);
+void fixup_memory_node(struct spl_image_info *spl_image);
+
+#endif /* __K3_DDR_INIT_H */
diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c
index 539eaf47186a..e0cd8529bc2b 100644
--- a/board/ti/j721e/evm.c
+++ b/board/ti/j721e/evm.c
@@ -17,6 +17,7 @@
#include "../common/board_detect.h"
#include "../common/fdt_ops.h"
+#include "../common/k3-ddr-init.h"
#define board_is_j721e_som() (board_ti_k3_is("J721EX-PM1-SOM") || \
board_ti_k3_is("J721EX-PM2-SOM"))
@@ -37,17 +38,6 @@ int board_init(void)
return 0;
}
-int dram_init(void)
-{
-#ifdef CONFIG_PHYS_64BIT
- gd->ram_size = 0x1;
-#else
- gd->ram_size = 0x8000;
-#endif
-
- return 0;
-}
-
phys_addr_t board_get_usable_ram_top(phys_size_t total_size)
{
#ifdef CONFIG_PHYS_64BIT
@@ -59,23 +49,6 @@ phys_addr_t board_get_usable_ram_top(phys_size_t
total_size)
return gd->ram_top;
}
-int dram_init_banksize(void)
-{
- /* Bank 0 declares the memory available in the DDR low region */
- gd->bd->bi_dram[0].start = 0x8000;
- gd->bd->bi_dram[0].size = 0x8000;
- gd->ram_size = 0x8000;
-
-#ifdef CONFIG_PHYS_64BIT
- /*
Re: Possible license violation
On Thu, Jun 06, 2024 at 08:15:24PM -0400, pm88hpxmd...@disengage.co wrote: > > > > > I think this is huge misunderstanding.They just don’t want users > to brick devices:After agent reply, no > complaintshttps://forum.gl-inet.com/t/uboot-for-gl-mt3000-beryl-ax/41760/13Nice > company, sorry for fuss> HiI am copying this message to you and > GL team.Regarding license violation:U-boot’s license requires Gl.iNet to > provide the source-code for U-boot (including any modifications they made) to > anybody that asks for it. So…GL team refused to send source code nor .bin > file. I wanted to inspect it for possible backdoors but still they are > refusing.“ If you choose to provide source through a written offer, then > anybody who requests the source from you is entitled to receive it.If you > commercially distribute binaries not accompanied with source code, the GPL > says you must provide a written offer to distribute the source code later. > When users non-commercially redistribute the binaries they received from you, > they must pass along a copy of this written offer. This means that people who > did not get the binaries directly from you can still receive copies of the > source code, along with the written offer.The reason we require the offer to > be valid for any third party is so that people who receive the binaries > indirectly in that way can order the source code from > you.”https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.htmlhttps://github.com/u-boot/u-bootSo > I am sending this message to you to check this situation. They probably will > not send it to you.Also please use web mail (not business domain) as they can > sent it to you through it to hide the fact of licensing violation. For > example send request from Gmail. Please take measures. It is certainly very > disappointing to hear GL.iNET is not following the clear license terms of > software they are using. -- Tom Ah, yes, I see the sources are available at: https://github.com/gl-inet/uboot-for-qca95xx/tree/master/src -- Tom signature.asc Description: PGP signature
Re: Possible license violation
I think this is huge misunderstanding.They just don’t want users to brick devices:After agent reply, no complaintshttps://forum.gl-inet.com/t/uboot-for-gl-mt3000-beryl-ax/41760/13Nice company, sorry for fuss> HiI am copying this message to you and GL team.Regarding license violation:U-boot’s license requires Gl.iNet to provide the source-code for U-boot (including any modifications they made) to anybody that asks for it. So…GL team refused to send source code nor .bin file. I wanted to inspect it for possible backdoors but still they are refusing.“ If you choose to provide source through a written offer, then anybody who requests the source from you is entitled to receive it.If you commercially distribute binaries not accompanied with source code, the GPL says you must provide a written offer to distribute the source code later. When users non-commercially redistribute the binaries they received from you, they must pass along a copy of this written offer. This means that people who did not get the binaries directly from you can still receive copies of the source code, along with the written offer.The reason we require the offer to be valid for any third party is so that people who receive the binaries indirectly in that way can order the source code from you.”https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.htmlhttps://github.com/u-boot/u-bootSo I am sending this message to you to check this situation. They probably will not send it to you.Also please use web mail (not business domain) as they can sent it to you through it to hide the fact of licensing violation. For example send request from Gmail. Please take measures. It is certainly very disappointing to hear GL.iNET is not following the clear license terms of software they are using. -- Tom
Re: [GIT PULL] Please pull u-boot-dfu-20240606
On Thu, Jun 06, 2024 at 12:06:44PM +0200, Mattijs Korpershoek wrote: > Hi Tom, > > Please find some fixes for master: > > - dwc3 fix crash when ep0 stalls or gadget is stopped > - Kconfig build fix for DFU_SF (SPI flash DFU driver) > > The CI job is at > https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/20990 > > Thanks, > Mattijs > > The following changes since commit c0ea27bccfb7d2d37fd36806ac2a2f7389099420: > > Prepare v2024.07-rc4 (2024-06-03 18:34:59 -0600) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-dfu.git > tags/u-boot-dfu-20240606 > > for you to fetch changes up to 4339138a2086f8449b9356130cb6e97a81aa8679: > > dfu: add missing dependency for SPI flash DFU driver (2024-06-06 09:11:21 > +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: Pull request doc-2024-07-rc5
On Thu, Jun 06, 2024 at 09:42:07AM +0200, Heinrich Schuchardt wrote: > Dear Tom, > > The following changes since commit 4b992573b34b1586e323e27b177680a6efec1c76: > > Merge https://gitlab.denx.de/u-boot/custodians/u-boot-usb (2024-06-05 > 10:59:10 -0600) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-efi.git > tags/doc-2024-07-rc5 > > for you to fetch changes up to 0efc5a9f670144cad7f287711f25c69cba0fde39: > > doc: process.rst: Document device tree resync rules (2024-06-06 > 09:28:20 +0200) > > Gitlab CI showed no issues building the documentation: > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/20988 > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: Possible license violation
On Tue, Jun 04, 2024 at 06:47:18PM -0400, pm88hpxmd...@disengage.co wrote: > HiI am copying this message to you and GL team.Regarding license > violation:U-boot’s license requires Gl.iNet to provide the source-code for > U-boot (including any modifications they made) to anybody that asks for it. > So…GL team refused to send source code nor .bin file. I wanted to inspect it > for possible backdoors but still they are refusing.“ If you choose to provide > source through a written offer, then anybody who requests the source from you > is entitled to receive it.If you commercially distribute binaries not > accompanied with source code, the GPL says you must provide a written offer > to distribute the source code later. When users non-commercially redistribute > the binaries they received from you, they must pass along a copy of this > written offer. This means that people who did not get the binaries directly > from you can still receive copies of the source code, along with the written > offer.The reason we require the offer to be valid for any third party is so > that people who receive the binaries indirectly in that way can order the > source code from > you.”https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.htmlhttps://github.com/u-boot/u-bootSo > I am sending this message to you to check this situation. They probably will > not send it to you.Also please use web mail (not business domain) as they can > sent it to you through it to hide the fact of licensing violation. For > example send request from Gmail. Please take measures. It is certainly very disappointing to hear GL.iNET is not following the clear license terms of software they are using. -- Tom signature.asc Description: PGP signature
[PATCH] arm: mvebu: Enable bootstd and other modernization for Synology DS414 (Armada XP) board
- Switch to standard boot (in include/configs/ds414.h and
configs/ds414_defconfig)
- Implement board_late_init() to ensure successful enumeration
of USB3 devices
- Remove unnecessary misc_init_r(), since NET_RANDOM_ETHADDR is now
configured in
- Remove unnecessary checkboard()
- Updated IDENT_STRING to indicate this u-boot supports both Synology
DS414 and DS214+ boards
- Add SYS_THUMB_BUILD to reduce binary size
- Add NET_RANDOM_ETHADDR
- Add CONFIG_LBA48 and CONFIG_SYS_64BIT_LBA to support >2TB HDD/SDD
Signed-off-by: Tony Dinh
---
board/Synology/ds414/ds414.c | 15 +++
configs/ds414_defconfig | 20 ++
include/configs/ds414.h | 51 ++--
3 files changed, 42 insertions(+), 44 deletions(-)
diff --git a/board/Synology/ds414/ds414.c b/board/Synology/ds414/ds414.c
index abe6f9eb5e..f0b55fa095 100644
--- a/board/Synology/ds414/ds414.c
+++ b/board/Synology/ds414/ds414.c
@@ -181,18 +181,9 @@ int board_init(void)
return 0;
}
-int misc_init_r(void)
+int board_late_init(void)
{
- if (!env_get("ethaddr")) {
- puts("Incomplete environment, populating from SPI flash\n");
- do_syno_populate(0, NULL);
- }
- return 0;
-}
-
-int checkboard(void)
-{
- puts("Board: DS414\n");
-
+ /* Do late init to ensure successful enumeration of XHCI devices */
+ pci_init();
return 0;
}
diff --git a/configs/ds414_defconfig b/configs/ds414_defconfig
index ecf9501ba5..501ed51129 100644
--- a/configs/ds414_defconfig
+++ b/configs/ds414_defconfig
@@ -1,5 +1,6 @@
CONFIG_ARM=y
CONFIG_ARCH_CPU_INIT=y
+CONFIG_SYS_THUMB_BUILD=y
CONFIG_ARCH_MVEBU=y
CONFIG_SUPPORT_PASSING_ATAGS=y
CONFIG_CMDLINE_TAG=y
@@ -25,44 +26,40 @@ CONFIG_SPL_BSS_MAX_SIZE=0x4000
CONFIG_SPL=y
CONFIG_DEBUG_UART_BASE=0xf1012000
CONFIG_DEBUG_UART_CLOCK=25000
+CONFIG_IDENT_STRING="\nSynology DS214+/DS414 2/4-Bay Diskstation"
CONFIG_SYS_LOAD_ADDR=0x80
CONFIG_PCI=y
CONFIG_DEBUG_UART=y
+CONFIG_BOOTSTD_FULL=y
CONFIG_BOOTDELAY=3
CONFIG_USE_BOOTARGS=y
-CONFIG_BOOTARGS="console=ttyS0,115200 ip=off initrd=0x840,8M root=/dev/md0
rw syno_hw_version=DS414r1 ihd_num=4 netif_num=2 flash_size=8 SataLedSpecial=1
HddHotplug=1"
-CONFIG_USE_BOOTCOMMAND=y
-CONFIG_BOOTCOMMAND="sf probe; sf read ${loadaddr} 0xd 0x2d; sf read
${ramdisk_addr_r} 0x3a 0x43; bootm ${loadaddr} ${ramdisk_addr_r}"
# CONFIG_DISPLAY_BOARDINFO is not set
CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
+CONFIG_BOARD_LATE_INIT=y
CONFIG_SPL_MAX_SIZE=0x1bfd0
CONFIG_SPL_SYS_MALLOC_SIMPLE=y
# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
CONFIG_SPL_I2C=y
+CONFIG_SYS_PROMPT="DS414> "
CONFIG_SYS_MAXARGS=32
CONFIG_CMD_I2C=y
CONFIG_CMD_PCI=y
CONFIG_CMD_SPI=y
CONFIG_CMD_USB=y
-# CONFIG_CMD_SETEXPR is not set
-CONFIG_CMD_DHCP=y
CONFIG_CMD_TFTPPUT=y
-CONFIG_CMD_MII=y
-CONFIG_CMD_PING=y
CONFIG_CMD_TIME=y
-CONFIG_CMD_EXT2=y
-CONFIG_CMD_FAT=y
CONFIG_CMD_JFFS2=y
CONFIG_CMD_MTDPARTS=y
CONFIG_CMD_UBI=y
-CONFIG_ISO_PARTITION=y
CONFIG_ENV_OVERWRITE=y
CONFIG_ENV_SPI_MAX_HZ=5000
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_ARP_TIMEOUT=200
CONFIG_NET_RETRY_COUNT=50
+CONFIG_NET_RANDOM_ETHADDR=y
CONFIG_SPL_OF_TRANSLATE=y
+CONFIG_LBA48=y
+CONFIG_SYS_64BIT_LBA=y
CONFIG_DM_I2C=y
CONFIG_SYS_I2C_MVTWSI=y
# CONFIG_MMC is not set
@@ -83,4 +80,3 @@ CONFIG_USB_XHCI_HCD=y
# CONFIG_USB_XHCI_MVEBU is not set
CONFIG_USB_XHCI_PCI=y
CONFIG_USB_EHCI_HCD=y
-CONFIG_USB_STORAGE=y
diff --git a/include/configs/ds414.h b/include/configs/ds414.h
index 9446acba79..bbefe632e0 100644
--- a/include/configs/ds414.h
+++ b/include/configs/ds414.h
@@ -1,5 +1,6 @@
/* SPDX-License-Identifier: GPL-2.0+ */
/*
+ * Copyright (C) 2024 Tony Dinh
* Copyright (C) 2014 Stefan Roese
*/
@@ -16,14 +17,9 @@
* U-Boot into it.
*/
-/* I2C */
#define CFG_I2C_MVTWSI_BASE0 MVEBU_TWSI_BASE
-/*
- * mv-common.h should be defined after CMD configs since it used them
- * to enable certain macros
- */
-#include "mv-common.h"
+#define PHY_ANEG_TIMEOUT 16000 /* PHY needs a longer aneg time */
/*
* Memory layout while starting into the bin_hdr via the
@@ -38,23 +34,38 @@
* L2 cache thus cannot be used.
*/
-/* SPL */
-/* Defines for SPL */
+/* Keep device tree and initrd in lower memory so the kernel can access them */
+#define RELOCATION_LIMITS_ENV_SETTINGS \
+ "fdt_high=0x1000\0" \
+ "initrd_high=0x1000\0"
+
+/*
+ * mv-common.h should be defined after CMD configs since it used them
+ * to enable certain macros
+ */
+#include "mv-common.h"
+
+#ifndef CONFIG_SPL_BUILD
-/* Default Environment */
+#define KERNEL_ADDR_R __stringify(0x100)
+#define FDT_ADDR_R __stringify(0x200)
+#define RAMDISK_ADDR_R __stringify(0x220)
+#define SCRIPT_ADDR_R __stringify(0x180)
+#define PXEFILE_ADDR_R __stringify(0x190)
-#define CFG_EXTRA_ENV_SETTINGS \
- "initrd_high=0x\0"
Re: Needs a check in the device tree
hi Simon, yes, you are right, I forgot to call this checking function, thanks! Best regards Jianqiang Simon Glass 于2024年6月6日周四 17:04写道： > Hi Jianqiang, > > On Wed, 5 Jun 2024 at 07:40, jianqiang wang wrote: > > > > Dear Das U-Boot developers, > > > > I found that the u-boot device tree implementation lacks a check for the > > off_dt_struct field in the device tree. > > > > In file scripts\dtc\libfdt\libfdt_internal.h, fdt_offset_ptr_ returns the > > dt struct address. It calculates the address by adding the header > address, > > fdt offset, and a specified offset. However, the fdt offset is read from > > the device tree and lacks a proper check. The returned pointer can even > > point to any address, leading to arbitrary read or write. > > > > Could you please confirm it is a vulnerability? > > Doesn't fdt_check_header() help here? Where are you calling the code from? > > Regards, > Simon >
Re: Proposal: U-Boot memory management
hi Simon, On Wed, 29 May 2024 at 22:00, Simon Glass wrote: > > +Sughosh Ganu for reference > > > On Sun, 31 Dec 2023 at 09:16, Tom Rini wrote: > > > > On Sun, Dec 31, 2023 at 04:40:06PM +0100, Heinrich Schuchardt wrote: > > > > > > > > > Am 31. Dezember 2023 16:11:44 MEZ schrieb Tom Rini : > > > >On Sun, Dec 31, 2023 at 07:22:10AM -0700, Simon Glass wrote: > > > >> Hi Tom, > > > >> > > > >> On Sun, Dec 31, 2023 at 6:54 AM Tom Rini wrote: > > > >> > > > > >> > On Sun, Dec 31, 2023 at 05:48:23AM -0700, Simon Glass wrote: > > > >> > > Hi, > > > >> > > > > > >> > > On Fri, Dec 29, 2023 at 10:52 AM Tom Rini > > > >> > > wrote: > > > >> > > > > > > >> > > > On Fri, Dec 29, 2023 at 06:44:15PM +0100, Mark Kettenis wrote: > > > >> > > > > > Date: Fri, 29 Dec 2023 11:17:44 -0500 > > > >> > > > > > From: Tom Rini > > > >> > > > > > > > > >> > > > > > On Fri, Dec 29, 2023 at 05:05:17PM +0100, Heinrich > > > >> > > > > > Schuchardt wrote: > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > Am 29. Dezember 2023 16:43:07 MEZ schrieb Tom Rini > > > >> > > > > > > : > > > >> > > > > > > >On Fri, Dec 29, 2023 at 05:36:09AM +, Simon Glass > > > >> > > > > > > >wrote: > > > >> > > > > > > >> Hi, > > > >> > > > > > > >> > > > >> > > > > > > >> On Sat, Dec 16, 2023 at 6:01 PM Simon Glass > > > >> > > > > > > >> wrote: > > > >> > > > > > > >> > > > > >> > > > > > > >> > Hi, > > > >> > > > > > > >> > > > > >> > > > > > > >> > This records my thoughts after a discussion with > > > >> > > > > > > >> > Ilias & Heinrich re > > > >> > > > > > > >> > memory allocation in U-Boot. > > > >> > > > > > > >> > > > > >> > > > > > > >> > 1. malloc() > > > >> > > > > > > >> > > > > >> > > > > > > >> > malloc() is used for programmatic memory allocation. > > > >> > > > > > > >> > It allows memory > > > >> > > > > > > >> > to be freed. It is not designed for very large > > > >> > > > > > > >> > allocations (e.g. a > > > >> > > > > > > >> > 10MB kernel or 100MB ramdisk). > > > >> > > > > > > >> > > > > >> > > > > > > >> > 2. lmb > > > >> > > > > > > >> > > > > >> > > > > > > >> > lmb is used for large blocks of memory, such as those > > > >> > > > > > > >> > needed for a > > > >> > > > > > > >> > kernel or ramdisk. Allocation is only transitory, for > > > >> > > > > > > >> > the purposes of > > > >> > > > > > > >> > loading some images and booting. If the boot fails, > > > >> > > > > > > >> > then all lmb > > > >> > > > > > > >> > allocations go away. > > > >> > > > > > > >> > > > > >> > > > > > > >> > lmb is set up by getting all available memory and > > > >> > > > > > > >> > then removing what > > > >> > > > > > > >> > is used by U-Boot (code, data, malloc() space, etc.) > > > >> > > > > > > >> > > > > >> > > > > > > >> > lmb reservations have a few flags so that areas of > > > >> > > > > > > >> > memory can be > > > >> > > > > > > >> > provided with attributes > > > >> > > > > > > >> > > > > >> > > > > > > >> > There are some corner cases...e.g. loading a file > > > >> > > > > > > >> > does an lmb > > > >> > > > > > > >> > allocation but only for the purpose of avoiding a > > > >> > > > > > > >> > file being loaded > > > >> > > > > > > >> > over U-Boot code/data. The allocation is dropped > > > >> > > > > > > >> > immediately after the > > > >> > > > > > > >> > file is loaded. Within the bootm command, or when > > > >> > > > > > > >> > using standard boot, > > > >> > > > > > > >> > this would be fairly easy to solve. > > > >> > > > > > > >> > > > > >> > > > > > > >> > Linux has renamed lmb to memblock. We should consider > > > >> > > > > > > >> > doing the same. > > > >> > > > > > > >> > > > > >> > > > > > > >> > 3. EFI > > > >> > > > > > > >> > > > > >> > > > > > > >> > EFI has its own memory-allocation tables. > > > >> > > > > > > >> > > > > >> > > > > > > >> > Like lmb, EFI is able to deal with large allocations. > > > >> > > > > > > >> > But via a 'pool' > > > >> > > > > > > >> > function it can also do smaller allocations similar > > > >> > > > > > > >> > to malloc(), > > > >> > > > > > > >> > although each one uses at least 4KB at present. > > > >> > > > > > > >> > > > > >> > > > > > > >> > EFI allocations do not go away when a boot fails. > > > >> > > > > > > >> > > > > >> > > > > > > >> > With EFI it is possible to add allocations post > > > >> > > > > > > >> > facto, in which case > > > >> > > > > > > >> > they are added to the allocation table just as if the > > > >> > > > > > > >> > memory was > > > >> > > > > > > >> > allocated with EFI to begin with. > > > >> > > > > > > >> > > > > >> > > > > > > >> > The EFI allocations and the lmb allocations use the > > > >> > > > > > > >> > same memory, so in > > > >> > > > > > > >> > principle could conflict. > > > >> > > > > > > >> > > > > >> > > > > > > >> > EFI allocations are sometimes used to allocate > > > >> > > > > > > >> > internal U-Boot data as > > > >> > > > > > > >> > well, if needed by the EFI app. For example, while > > > >> > > >
Re: [PATCH 0/3] arm: dts: am625/am62a7: Switch over to OF_UPSTREAM
On June 5, 2024 thus sayeth Nishanth Menon: > Cleanup am625 on by switching over the last two platforms (SK and > beagleplay) over to OF_UPSTREAM, and while at it, switch over am62a7 > (last of the am62* family) over as well. > > This superscedes the previous version of beagleplay only patch[1] > > Test logs: https://gist.github.com/nmenon/ba310d3750a80789aca6a4fd90190135 > > Nishanth Menon (3): > arm: dts: am625_beagleplay: Switch to OF_UPSTREAM > arm: dts: am625_sk: Switch to OF_UPSTREAM > arm: dts: am62a7_sk: Switch to OF_UPSTREAM Looks great to me Reviewed-by: Bryan Brattlof ~Bryan
Re: [PATCH v3 05/12] net-lwip: add ping command
On Thu, 6 Jun 2024 at 20:02, Ilias Apalodimas
wrote:
>
> On Thu, 6 Jun 2024 at 19:53, Ilias Apalodimas
> wrote:
> >
> > [...]
> >
> > > +static int ping_raw_init(void *recv_arg)
> > > +{
> > > + ping_pcb = raw_new(IP_PROTO_ICMP);
> > > + if (!ping_pcb)
> > > + return -ENOMEM;
> > > +
> > > + raw_recv(ping_pcb, ping_recv, recv_arg);
> > > + raw_bind(ping_pcb, IP_ADDR_ANY);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static void ping_raw_stop(void)
> > > +{
> > > + if (ping_pcb != NULL) {
> >
> > nits, but we usually do if (!ping_pcb) for NULL pointers and variables
> > that have a value of 0.
> > Please change it in other files as well
> >
> >
> > > + raw_remove(ping_pcb);
> > > + ping_pcb = NULL;
> > > + }
> > > +}
> > > +
> > > +static void ping_prepare_echo(struct icmp_echo_hdr *iecho)
> > > +{
> > > + ICMPH_TYPE_SET(iecho, ICMP_ECHO);
> > > + ICMPH_CODE_SET(iecho, 0);
> > > + iecho->chksum = 0;
> > > + iecho->id = PING_ID;
> > > + iecho->seqno = lwip_htons(++ping_seq_num);
> > > +
> > > + iecho->chksum = inet_chksum(iecho, sizeof(*iecho));
> > > +}
> > > +
> > > +static void ping_send_icmp(struct raw_pcb *raw, const ip_addr_t *addr)
> > > +{
> > > + struct pbuf *p;
> > > + struct icmp_echo_hdr *iecho;
> > > + size_t ping_size = sizeof(struct icmp_echo_hdr);
> > > +
> > > + p = pbuf_alloc(PBUF_IP, (u16_t)ping_size, PBUF_RAM);
> > > + if (!p)
> > > + return;
> > > +
> > > + if ((p->len == p->tot_len) && (p->next == NULL)) {
> >
> > && !p->next
> >
> > > + iecho = (struct icmp_echo_hdr *)p->payload;
> > > + ping_prepare_echo(iecho);
> > > + raw_sendto(raw, p, addr);
> > > + }
> > > +
> > > + pbuf_free(p);
> > > +}
> > > +
> > > +static void ping_send(void *arg)
> > > +{
> > > + struct raw_pcb *pcb = (struct raw_pcb *)arg;
> > > +
> > > + ping_send_icmp(pcb, ping_target);
> > > + sys_timeout(PING_DELAY_MS, ping_send, ping_pcb);
> > > +}
> > > +
> > > +static int ping_loop(const ip_addr_t* addr)
> > > +{
> > > + bool alive;
> > > + ulong start;
> > > + int ret;
> > > +
> > > + printf("Using %s device\n", eth_get_name());
> > > +
> > > + ret = ping_raw_init();
> > > + if (ret < 0)
> > > + return ret;
> > > + ping_target = addr;
> > > + ping_seq_num = 0;
> > > +
> > > + start = get_timer(0);
> > > + ping_send(ping_pcb);
> > > +
> > > + do {
> > > + eth_rx();
> > > + if (alive)
> > > + break;
> > > + sys_check_timeouts();
> > > + if (ctrlc()) {
> > > + printf("\nAbort\n");
> > > + break;
> > > + }
> > > + } while (get_timer(start) < PING_TIMEOUT_MS);
> >
> > I am a bit confused about what happens here.
> > ping_send() will send the packet, but it will also schedule itself to
> > rerun after 1 ms and send another ping?
> >
> > > +
> > > + sys_untimeout(ping_send, ping_pcb);
> >
> > So we need the sys_untimeout() because we queued 2 pings? Because
> > sys_timeout() is supposed to be an one shot.
>
> Ah nvm, I misread that. We always reschedule ping_send_icmp(), that's
> why we have to delete it here
Ok so looking at it a bit more. Why do we have to schedule contunuous pings?
We just have to send one packet and wait for the response no?
Thanks
/Ilias
>
>
> >
> > Thanks
> > /Ilias
> > > + ping_raw_stop();
> > > + ping_target = NULL;
> > > +
> > > + if (alive) {
> > > + alive = false;
> > > + return 0;
> > > + }
> > > + printf("ping failed; host %s is not alive\n", ipaddr_ntoa(addr));
> > > + return -1;
> > > +}
> > > +
> > > +int do_ping(struct cmd_tbl *cmdtp, int flag, int argc, char *const
> > > argv[])
> > > +{
> > > + ip_addr_t addr;
> > > +
> > > + if (argc < 2)
> > > + return CMD_RET_USAGE;
> > > +
> > > + if (!ipaddr_aton(argv[1], ))
> > > + return CMD_RET_USAGE;
> > > +
> > > + if (ping_loop() < 0)
> > > + return CMD_RET_FAILURE;
> > > +
> > > + return CMD_RET_SUCCESS;
> > > +}
> > > --
> > > 2.40.1
> > >
Re: [PATCH v3 05/12] net-lwip: add ping command
On Thu, 6 Jun 2024 at 19:53, Ilias Apalodimas
wrote:
>
> [...]
>
> > +static int ping_raw_init(void *recv_arg)
> > +{
> > + ping_pcb = raw_new(IP_PROTO_ICMP);
> > + if (!ping_pcb)
> > + return -ENOMEM;
> > +
> > + raw_recv(ping_pcb, ping_recv, recv_arg);
> > + raw_bind(ping_pcb, IP_ADDR_ANY);
> > +
> > + return 0;
> > +}
> > +
> > +static void ping_raw_stop(void)
> > +{
> > + if (ping_pcb != NULL) {
>
> nits, but we usually do if (!ping_pcb) for NULL pointers and variables
> that have a value of 0.
> Please change it in other files as well
>
>
> > + raw_remove(ping_pcb);
> > + ping_pcb = NULL;
> > + }
> > +}
> > +
> > +static void ping_prepare_echo(struct icmp_echo_hdr *iecho)
> > +{
> > + ICMPH_TYPE_SET(iecho, ICMP_ECHO);
> > + ICMPH_CODE_SET(iecho, 0);
> > + iecho->chksum = 0;
> > + iecho->id = PING_ID;
> > + iecho->seqno = lwip_htons(++ping_seq_num);
> > +
> > + iecho->chksum = inet_chksum(iecho, sizeof(*iecho));
> > +}
> > +
> > +static void ping_send_icmp(struct raw_pcb *raw, const ip_addr_t *addr)
> > +{
> > + struct pbuf *p;
> > + struct icmp_echo_hdr *iecho;
> > + size_t ping_size = sizeof(struct icmp_echo_hdr);
> > +
> > + p = pbuf_alloc(PBUF_IP, (u16_t)ping_size, PBUF_RAM);
> > + if (!p)
> > + return;
> > +
> > + if ((p->len == p->tot_len) && (p->next == NULL)) {
>
> && !p->next
>
> > + iecho = (struct icmp_echo_hdr *)p->payload;
> > + ping_prepare_echo(iecho);
> > + raw_sendto(raw, p, addr);
> > + }
> > +
> > + pbuf_free(p);
> > +}
> > +
> > +static void ping_send(void *arg)
> > +{
> > + struct raw_pcb *pcb = (struct raw_pcb *)arg;
> > +
> > + ping_send_icmp(pcb, ping_target);
> > + sys_timeout(PING_DELAY_MS, ping_send, ping_pcb);
> > +}
> > +
> > +static int ping_loop(const ip_addr_t* addr)
> > +{
> > + bool alive;
> > + ulong start;
> > + int ret;
> > +
> > + printf("Using %s device\n", eth_get_name());
> > +
> > + ret = ping_raw_init();
> > + if (ret < 0)
> > + return ret;
> > + ping_target = addr;
> > + ping_seq_num = 0;
> > +
> > + start = get_timer(0);
> > + ping_send(ping_pcb);
> > +
> > + do {
> > + eth_rx();
> > + if (alive)
> > + break;
> > + sys_check_timeouts();
> > + if (ctrlc()) {
> > + printf("\nAbort\n");
> > + break;
> > + }
> > + } while (get_timer(start) < PING_TIMEOUT_MS);
>
> I am a bit confused about what happens here.
> ping_send() will send the packet, but it will also schedule itself to
> rerun after 1 ms and send another ping?
>
> > +
> > + sys_untimeout(ping_send, ping_pcb);
>
> So we need the sys_untimeout() because we queued 2 pings? Because
> sys_timeout() is supposed to be an one shot.
Ah nvm, I misread that. We always reschedule ping_send_icmp(), that's
why we have to delete it here
>
> Thanks
> /Ilias
> > + ping_raw_stop();
> > + ping_target = NULL;
> > +
> > + if (alive) {
> > + alive = false;
> > + return 0;
> > + }
> > + printf("ping failed; host %s is not alive\n", ipaddr_ntoa(addr));
> > + return -1;
> > +}
> > +
> > +int do_ping(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
> > +{
> > + ip_addr_t addr;
> > +
> > + if (argc < 2)
> > + return CMD_RET_USAGE;
> > +
> > + if (!ipaddr_aton(argv[1], ))
> > + return CMD_RET_USAGE;
> > +
> > + if (ping_loop() < 0)
> > + return CMD_RET_FAILURE;
> > +
> > + return CMD_RET_SUCCESS;
> > +}
> > --
> > 2.40.1
> >
Re: [PATCH v3 00/12] Introduce the lwIP network stack
On Thu, Jun 06, 2024 at 03:35:55PM +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. (CC'd) > has 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 Alright, on Pi 3, I think we have more "output changed, test fails" problems: == FAILURES === _ test_efi_fit_launch _ test/py/tests/test_efi_fit.py:452: in test_efi_fit_launch launch_efi(False, False) test/py/tests/test_efi_fit.py:394: in launch_efi net_set_up = net_dhcp() test/py/tests/test_efi_fit.py:178: in net_dhcp assert 'DHCP client bound to address ' in output E AssertionError: assert 'DHCP client bound to address ' in 'Waiting for Ethernet connection... done.\r\neth0: smsc95xx_eth b8:27:eb:fc:64:a6 active' Captured stdout call - U-Boot> usb start U-Boot> U-Boot> setenv autoload no U-Boot> U-Boot> dhcp Waiting for Ethernet connection... done. eth0: smsc95xx_eth b8:27:eb:fc:64:a6 active U-Boot> === short test summary info === I'm going to skip that set of tests and see how far we get but I suspect it'll keep failing on DHCP output being different. -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 05/12] net-lwip: add ping command
[...]
> +static int ping_raw_init(void *recv_arg)
> +{
> + ping_pcb = raw_new(IP_PROTO_ICMP);
> + if (!ping_pcb)
> + return -ENOMEM;
> +
> + raw_recv(ping_pcb, ping_recv, recv_arg);
> + raw_bind(ping_pcb, IP_ADDR_ANY);
> +
> + return 0;
> +}
> +
> +static void ping_raw_stop(void)
> +{
> + if (ping_pcb != NULL) {
nits, but we usually do if (!ping_pcb) for NULL pointers and variables
that have a value of 0.
Please change it in other files as well
> + raw_remove(ping_pcb);
> + ping_pcb = NULL;
> + }
> +}
> +
> +static void ping_prepare_echo(struct icmp_echo_hdr *iecho)
> +{
> + ICMPH_TYPE_SET(iecho, ICMP_ECHO);
> + ICMPH_CODE_SET(iecho, 0);
> + iecho->chksum = 0;
> + iecho->id = PING_ID;
> + iecho->seqno = lwip_htons(++ping_seq_num);
> +
> + iecho->chksum = inet_chksum(iecho, sizeof(*iecho));
> +}
> +
> +static void ping_send_icmp(struct raw_pcb *raw, const ip_addr_t *addr)
> +{
> + struct pbuf *p;
> + struct icmp_echo_hdr *iecho;
> + size_t ping_size = sizeof(struct icmp_echo_hdr);
> +
> + p = pbuf_alloc(PBUF_IP, (u16_t)ping_size, PBUF_RAM);
> + if (!p)
> + return;
> +
> + if ((p->len == p->tot_len) && (p->next == NULL)) {
&& !p->next
> + iecho = (struct icmp_echo_hdr *)p->payload;
> + ping_prepare_echo(iecho);
> + raw_sendto(raw, p, addr);
> + }
> +
> + pbuf_free(p);
> +}
> +
> +static void ping_send(void *arg)
> +{
> + struct raw_pcb *pcb = (struct raw_pcb *)arg;
> +
> + ping_send_icmp(pcb, ping_target);
> + sys_timeout(PING_DELAY_MS, ping_send, ping_pcb);
> +}
> +
> +static int ping_loop(const ip_addr_t* addr)
> +{
> + bool alive;
> + ulong start;
> + int ret;
> +
> + printf("Using %s device\n", eth_get_name());
> +
> + ret = ping_raw_init();
> + if (ret < 0)
> + return ret;
> + ping_target = addr;
> + ping_seq_num = 0;
> +
> + start = get_timer(0);
> + ping_send(ping_pcb);
> +
> + do {
> + eth_rx();
> + if (alive)
> + break;
> + sys_check_timeouts();
> + if (ctrlc()) {
> + printf("\nAbort\n");
> + break;
> + }
> + } while (get_timer(start) < PING_TIMEOUT_MS);
I am a bit confused about what happens here.
ping_send() will send the packet, but it will also schedule itself to
rerun after 1 ms and send another ping?
> +
> + sys_untimeout(ping_send, ping_pcb);
So we need the sys_untimeout() because we queued 2 pings? Because
sys_timeout() is supposed to be an one shot.
Thanks
/Ilias
> + ping_raw_stop();
> + ping_target = NULL;
> +
> + if (alive) {
> + alive = false;
> + return 0;
> + }
> + printf("ping failed; host %s is not alive\n", ipaddr_ntoa(addr));
> + return -1;
> +}
> +
> +int do_ping(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
> +{
> + ip_addr_t addr;
> +
> + if (argc < 2)
> + return CMD_RET_USAGE;
> +
> + if (!ipaddr_aton(argv[1], ))
> + return CMD_RET_USAGE;
> +
> + if (ping_loop() < 0)
> + return CMD_RET_FAILURE;
> +
> + return CMD_RET_SUCCESS;
> +}
> --
> 2.40.1
>
[PATCH] doc/sphinx, test/py: Update requests module to 2.32.2
The issue described in https://github.com/psf/requests/pull/6655 has been assigned as a security issue. While unlikely to be exploited in our usage, update to the current release to fix it. Furthermore, upstream has now moved on to v2.23.2 as the release to use which has all of the issues resolved. Reported-by: GitHub dependabot Signed-off-by: Tom Rini --- Changes in v2: - Switch from 2.23.0 to 2.23.2 to use most recent upstream. --- doc/sphinx/requirements.txt | 2 +- test/py/requirements.txt| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/sphinx/requirements.txt b/doc/sphinx/requirements.txt index 426f41e1a028..54eb70aa92c0 100644 --- a/doc/sphinx/requirements.txt +++ b/doc/sphinx/requirements.txt @@ -9,7 +9,7 @@ Jinja2==3.1.4 MarkupSafe==2.1.3 packaging==23.2 Pygments==2.17.2 -requests==2.31.0 +requests==2.32.2 six==1.16.0 snowballstemmer==2.2.0 Sphinx==7.2.6 diff --git a/test/py/requirements.txt b/test/py/requirements.txt index 0f67c3c61949..c1dd636931f7 100644 --- a/test/py/requirements.txt +++ b/test/py/requirements.txt @@ -20,7 +20,7 @@ pytest==6.2.5 pytest-xdist==2.5.0 python-mimeparse==1.6.0 python-subunit==1.3.0 -requests==2.31.0 +requests==2.32.2 setuptools==65.5.1 six==1.16.0 testtools==2.3.0 -- 2.34.1
[PATCH v3 03/12] net-lwip: add DHCP support and dhcp commmand
Add what it takes to enable NETDEVICES with NET_LWIP and enable DHCP as
well as the dhcp command.
- net-lwip/net-lwip.c is mostly empty for now. It will provide functions
similar to net/net.c except based on the lwIP stack
- include/net-lwip.h is a replacement for include/net.h which is unused
when NET_LWIP is enabled. Declarations from the latter will be
transferred to the former as needed when new network commands are ported
on top of lwIP.
- CMD_TFTPBOOT is selected by BOOTMETH_EFI due to this code having
an implicit dependency on do_tftpb().
Signed-off-by: Jerome Forissier
---
Makefile| 1 +
boot/Kconfig| 3 +-
cmd/Kconfig | 26 +
cmd/Makefile| 4 +
cmd/net-lwip.c | 13 +++
common/board_r.c| 4 +-
drivers/net/Kconfig | 2 +-
include/net-lwip.h | 85 +++
include/net.h | 2 +-
net-lwip/Makefile | 15 +++
net-lwip/dhcp.c | 105 +++
net-lwip/eth_internal.h | 35 +++
net-lwip/net-lwip.c | 224
net-lwip/tftp.c | 11 ++
14 files changed, 525 insertions(+), 5 deletions(-)
create mode 100644 cmd/net-lwip.c
create mode 100644 include/net-lwip.h
create mode 100644 net-lwip/Makefile
create mode 100644 net-lwip/dhcp.c
create mode 100644 net-lwip/eth_internal.h
create mode 100644 net-lwip/net-lwip.c
create mode 100644 net-lwip/tftp.c
diff --git a/Makefile b/Makefile
index ceb99a2698e..d3c9e6775dc 100644
--- a/Makefile
+++ b/Makefile
@@ -860,6 +860,7 @@ libs-y += env/
libs-y += lib/
libs-y += fs/
libs-$(CONFIG_NET) += net/
+libs-$(CONFIG_NET_LWIP) += net-lwip/
libs-y += disk/
libs-y += drivers/
libs-$(CONFIG_SYS_FSL_DDR) += drivers/ddr/fsl/
diff --git a/boot/Kconfig b/boot/Kconfig
index 6f3096c15a6..004e69dd92a 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -378,7 +378,7 @@ config BOOT_DEFAULTS_CMDS
select CMD_FAT
select CMD_FS_GENERIC
select CMD_PART if PARTITIONS
- select CMD_DHCP if CMD_NET
+ select CMD_DHCP if CMD_NET || CMD_NET_LWIP
select CMD_PING if CMD_NET
select CMD_PXE if CMD_NET
select CMD_BOOTI if ARM64
@@ -540,6 +540,7 @@ config BOOTMETH_EXTLINUX_PXE
config BOOTMETH_EFILOADER
bool "Bootdev support for EFI boot"
depends on EFI_BINARY_EXEC
+ select CMD_TFTPBOOT if CMD_NET_LWIP
default y
help
Enables support for EFI boot using bootdevs. This makes the
diff --git a/cmd/Kconfig b/cmd/Kconfig
index b026439c773..1bfa528e945 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -2084,6 +2084,32 @@ config CMD_WOL
endif
+if NET_LWIP
+
+menuconfig CMD_NET_LWIP
+ bool "Network commands (lwIP)"
+ default y
+
+if CMD_NET_LWIP
+
+config CMD_DHCP
+ bool "dhcp"
+ select PROT_DHCP_LWIP
+ help
+ Boot image via network using DHCP/TFTP protocol
+
+config CMD_TFTPBOOT
+ bool "tftp"
+ select PROT_UDP_LWIP
+ default n
+ help
+ tftpboot - load file via network using TFTP protocol
+ Currently a placeholder (not implemented)
+
+endif
+
+endif
+
menu "Misc commands"
config CMD_2048
diff --git a/cmd/Makefile b/cmd/Makefile
index 87133cc27a8..535b6838ca5 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -128,6 +128,10 @@ endif
obj-$(CONFIG_CMD_MUX) += mux.o
obj-$(CONFIG_CMD_NAND) += nand.o
obj-$(CONFIG_CMD_NET) += net.o
+obj-$(CONFIG_CMD_NET_LWIP) += net-lwip.o
+ifdef CONFIG_CMD_NET_LWIP
+CFLAGS_net-lwip.o := -I$(srctree)/lib/lwip/lwip/src/include
-I$(srctree)/lib/lwip/u-boot
+endif
obj-$(CONFIG_ENV_SUPPORT) += nvedit.o
obj-$(CONFIG_CMD_NVEDIT_EFI) += nvedit_efi.o
obj-$(CONFIG_CMD_ONENAND) += onenand.o
diff --git a/cmd/net-lwip.c b/cmd/net-lwip.c
new file mode 100644
index 000..966d7226eda
--- /dev/null
+++ b/cmd/net-lwip.c
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Copyright (C) 2024 Linaro Ltd. */
+
+#include
+#include
+
+#if defined(CONFIG_CMD_DHCP)
+U_BOOT_CMD(
+dhcp, 3, 1, do_dhcp,
+"boot image via network using DHCP/TFTP protocol",
+"[loadAddress] [[hostIPaddr:]bootfilename]"
+);
+#endif
diff --git a/common/board_r.c b/common/board_r.c
index da0b80f24ff..6548eb8fdd5 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -472,7 +472,7 @@ static int initr_status_led(void)
}
#endif
-#ifdef CONFIG_CMD_NET
+#if defined(CONFIG_CMD_NET) || defined(CONFIG_CMD_NET_LWIP)
static int initr_net(void)
{
puts("Net: ");
@@ -727,7 +727,7 @@ static init_fnc_t init_sequence_r[] = {
#ifdef CONFIG_PCI_ENDPOINT
pci_ep_init,
#endif
-#ifdef CONFIG_CMD_NET
+#if defined(CONFIG_CMD_NET) || defined(CONFIG_CMD_NET_LWIP)
INIT_FUNC_WATCHDOG_RESET
initr_net,
#endif
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index b2d7b499766..4ba09c9d6f8 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -96,7 +96,7 @@ config
[PATCH v3 01/12] net: introduce alternative implementation as net-lwip/
Prepare the introduction of the lwIP (lightweight IP) TCP/IP stack by adding a new net-lwip/ directory and the NET_LWIP symbol. Network support is either NO_NET, NET (legacy stack) or NET_LWIP. Subsequent commits will introduce the lwIP code, re-work the NETDEVICE integration and port some of the NET commands and features to lwIP. SPL_NET cannot be enabled when NET_LWIP=y. SPL_NET pulls some symbols that are part of NET (such as arp_init(), arp_timeout_check(), arp_receive(), net_arp_wait_packet_ip()). lwIP support in SPL may be added later. Similarly, DFU_TFTP is not compatible with NET_LWIP because it depends on net_loop(), tftp_timeout_ms, tftp_timeout_count_max. Let's add a dependency of DFU_OVER_TFTP on !NET_LWIP for now. Signed-off-by: Jerome Forissier --- Kconfig| 40 ++ Makefile | 2 +- common/Kconfig | 2 +- common/spl/Kconfig | 1 + drivers/dfu/Kconfig| 2 +- drivers/fastboot/Kconfig | 4 ++-- drivers/net/phy/Kconfig| 2 +- drivers/usb/gadget/Kconfig | 2 +- net-lwip/Kconfig | 37 +++ net/Kconfig| 14 - 10 files changed, 85 insertions(+), 21 deletions(-) create mode 100644 net-lwip/Kconfig diff --git a/Kconfig b/Kconfig index 82df59f176e..b7304bd37c5 100644 --- a/Kconfig +++ b/Kconfig @@ -745,7 +745,47 @@ source "dts/Kconfig" source "env/Kconfig" +choice + prompt "Networking stack" + default NET + +config NO_NET + bool "No networking support" + +config NET + bool "Legacy U-Boot networking stack" + imply NETDEVICES + +config NET_LWIP + bool "Use lwIP for networking stack" + imply NETDEVICES + help + Include networking support based on the lwIP (lightweight IP) + TCP/IP stack (https://nongnu.org/lwip). This is a replacement for + the default U-Boot network stack and applications located in net/ + and enabled via CONFIG_NET as well as other pieces of code that + depend on CONFIG_NET (such as cmd/net.c enabled via CONFIG_CMD_NET). + Therefore the two symbols CONFIG_NET and CONFIG_NET_LWIP are mutually + exclusive. + +endchoice + +if NET source "net/Kconfig" +endif + +if NET_LWIP +source "net-lwip/Kconfig" +endif + +config SYS_RX_ETH_BUFFER + int "Number of receive packet buffers" + default 4 + help + Defines the number of Ethernet receive buffers. On some Ethernet + controllers it is recommended to set this value to 8 or even higher, + since all buffers can be full shortly after enabling the interface on + high Ethernet traffic. source "drivers/Kconfig" diff --git a/Makefile b/Makefile index f8206b2e30a..ceb99a2698e 100644 --- a/Makefile +++ b/Makefile @@ -859,7 +859,7 @@ libs-$(CONFIG_OF_EMBED) += dts/ libs-y += env/ libs-y += lib/ libs-y += fs/ -libs-y += net/ +libs-$(CONFIG_NET) += net/ libs-y += disk/ libs-y += drivers/ libs-$(CONFIG_SYS_FSL_DDR) += drivers/ddr/fsl/ diff --git a/common/Kconfig b/common/Kconfig index 5e3070e9253..807b726384d 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -424,7 +424,7 @@ config LOGF_FUNC_PAD config LOG_SYSLOG bool "Log output to syslog server" - depends on NET + depends on NET || NET_LWIP help Enables a log driver which broadcasts log records via UDP port 514 to syslog servers. diff --git a/common/spl/Kconfig b/common/spl/Kconfig index 6405374bcc1..f67f0a859db 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -1055,6 +1055,7 @@ config SPL_DM_SPI_FLASH config SPL_NET bool "Support networking" + depends on !NET_LWIP help Enable support for network devices (such as Ethernet) in SPL. This permits SPL to load U-Boot over a network link rather than diff --git a/drivers/dfu/Kconfig b/drivers/dfu/Kconfig index 0360d9da142..c6bce82eb10 100644 --- a/drivers/dfu/Kconfig +++ b/drivers/dfu/Kconfig @@ -11,7 +11,7 @@ config DFU_OVER_USB config DFU_OVER_TFTP bool - depends on NET + depends on NET && !NET_LWIP if DFU config DFU_WRITE_ALT diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig index 70207573de2..05e988166fb 100644 --- a/drivers/fastboot/Kconfig +++ b/drivers/fastboot/Kconfig @@ -27,7 +27,7 @@ config USB_FUNCTION_FASTBOOT This enables the USB part of the fastboot gadget. config UDP_FUNCTION_FASTBOOT - depends on NET + depends on NET || NET_LWIP select FASTBOOT bool "Enable fastboot protocol over UDP" help @@ -41,7 +41,7 @@ config UDP_FUNCTION_FASTBOOT_PORT The fastboot protocol requires a UDP port number. config TCP_FUNCTION_FASTBOOT - depends on NET + depends on NET || NET_LWIP select FASTBOOT bool "Enable fastboot protocol over TCP" help diff --git
Re: [PATCH 0/7] misc: introduce STATUS LED activity function
Hi Christian, On 6/6/24 1:52 PM, Christian Marangi wrote: On Thu, Jun 06, 2024 at 12:55:37PM +0200, Quentin Schulz wrote: Hi Christian, On 6/6/24 11:52 AM, Christian Marangi wrote: On Thu, Jun 06, 2024 at 11:12:11AM +0200, Quentin Schulz wrote: Hi Christian, On 6/5/24 9:21 PM, Christian Marangi wrote: This series expand the STATUS LED framework with a new color and a big new feature. One thing that many device need is a way to communicate to the user that the device is actually doing something. This is especially useful for recovery steps where an user (for example) insert an USB drive, keep a button pressed and the device autorecover. There is currently no way to signal the user externally that the bootloader is processing/recoverying aside from setting a LED on. A solid LED on is not enough and won't actually signal any kind of progress. Solution is the good old blinking LED but uboot doesn't suggest (and support) interrupts and almost all the LED are usually GPIO LED that doesn't support HW blink. I haven't used it yet but we do have a cyclic framework now for things happening in the background. I think this is a good use-case for this framework? Something would set the blinking frequency (could be from CLI directly, or as part of board files, or architecture, etc...) and the LED would just blink then. This would allow to highlight stages in the boot process, though that is not like an activity LED so if you're stuck in a stage, you wouldn't know if something is still happening or if you're really stuck (e.g. no packet on TFTP or TFTP very slow). The benefit is that it would be way less intrusive than patching all commands that could make use of that LED. Right now, this only adds support to MTD, SPI and TFTP, but what about MMC, NVMe, USB, other net stuff (e.g. wget), etc... Can you hint me on where is this framework? Checking the tftp code i couldn't find extra call to it. Maybe it's attached to the schedule() function? https://docs.u-boot.org/en/latest/develop/cyclic.html Thanks looks very interesting and looks handy to make use of the watchdog for it. I will try now to rework the implementation for the sw blink to make use of cyclic thing. Also notice that it's really not a one setting since almost all device have GPIO LEDs and doesn't have a way to support HW Blink so the "activity" function needs to be called multiple time to increase the counter and toggle the LED. Cyclic callback would be called twice per expected blink period, where you would toggle the GPIO (essentially making it 50% duty cycle, but could be more fine-grained if you want a different duty cycle). Well status LED already have CONFIG_STATUS_LED_FREQ where you can set a value. I will just use this. This actually only appears in the rST doc, nothing actually makes use of this right now, so it's not something we **need** to use. What I meant is, if you only provide a frequency, a specific, hardcoded, pattern is expected. E.g. for 1KHz, you enable the LED for 0.5ms and disable it for 0.5ms (or 1ms and 1ms, depending on how you see LED_STATUS_FREQ working). Could be 0.2ms and 0.8ms but it would always be this. How do you differentiate between "something is happening on NAND" and "TFTP is being used" if you don't have the ability to change the duty cycle? Or are you expecting people to have multiple LED of different colors for that? Also this have the extra feature that you can check if something gets stuck in the process. The lifecycle is: - Turn on the ACTIVITY LED at the start of the thing - Blink once in a while (for very little task this might not happen) - Turn off the ACTIVITY LED at the end of the thing Soo if something goes wrong the LED would never turn OFF but would stay solid ON. Yes, that's something that wouldn't be covered by cyclic framework here. It all depends what you want to do, if it's an activity LED, then we need to hook ourselves deep into frameworks where stuff is actually happening. If it's just to specify which stage of the boot we reached, then cyclic would be good enough probably (register for stage 1, unregister stage1+register for stage2 for different frequency, etc...). The cyclic framework can reduce the implementation to just START and STOP. We would lose the ability to know if there is an actual progress or not tho... So maybe that is bad but honestly a TFTP transfer can be tracked by the other machine and MTD write/erase won't magically stop and get stalled... (and even with that they will timeout and the status LED stop will be called anyway) So a dumb blinking with the watchdog is O.K. This is really a simple thing to show that something is happening (use case of recovering the device without actually using serial) Then it's not so much an activity LED anymore, rather a "i'm still alive and doing X thing right now, but maybe I'm stuck who knows", e.g. a little bit like a glorified heartbeat (I'm not saying it's bad, it's just a
Re: [PATCH 0/7] misc: introduce STATUS LED activity function
On Thu, Jun 06, 2024 at 03:32:14PM +0200, Quentin Schulz wrote: > Hi Christian, > > On 6/6/24 1:52 PM, Christian Marangi wrote: > > On Thu, Jun 06, 2024 at 12:55:37PM +0200, Quentin Schulz wrote: > > > Hi Christian, > > > > > > On 6/6/24 11:52 AM, Christian Marangi wrote: > > > > On Thu, Jun 06, 2024 at 11:12:11AM +0200, Quentin Schulz wrote: > > > > > Hi Christian, > > > > > > > > > > On 6/5/24 9:21 PM, Christian Marangi wrote: > > > > > > This series expand the STATUS LED framework with a new color > > > > > > and a big new feature. One thing that many device need is a way > > > > > > to communicate to the user that the device is actually doing > > > > > > something. > > > > > > > > > > > > This is especially useful for recovery steps where an > > > > > > user (for example) insert an USB drive, keep a button pressed > > > > > > and the device autorecover. > > > > > > > > > > > > There is currently no way to signal the user externally that > > > > > > the bootloader is processing/recoverying aside from setting > > > > > > a LED on. > > > > > > > > > > > > A solid LED on is not enough and won't actually signal any > > > > > > kind of progress. > > > > > > Solution is the good old blinking LED but uboot doesn't > > > > > > suggest (and support) interrupts and almost all the LED > > > > > > are usually GPIO LED that doesn't support HW blink. > > > > > > > > > > > > > > > > I haven't used it yet but we do have a cyclic framework now for things > > > > > happening in the background. I think this is a good use-case for this > > > > > framework? Something would set the blinking frequency (could be from > > > > > CLI > > > > > directly, or as part of board files, or architecture, etc...) and the > > > > > LED > > > > > would just blink then. This would allow to highlight stages in the > > > > > boot > > > > > process, though that is not like an activity LED so if you're stuck > > > > > in a > > > > > stage, you wouldn't know if something is still happening or if you're > > > > > really > > > > > stuck (e.g. no packet on TFTP or TFTP very slow). The benefit is that > > > > > it > > > > > would be way less intrusive than patching all commands that could > > > > > make use > > > > > of that LED. Right now, this only adds support to MTD, SPI and TFTP, > > > > > but > > > > > what about MMC, NVMe, USB, other net stuff (e.g. wget), etc... > > > > > > > > > > > > > Can you hint me on where is this framework? Checking the tftp code i > > > > couldn't find extra call to it. Maybe it's attached to the schedule() > > > > function? > > > > > > > > > > https://docs.u-boot.org/en/latest/develop/cyclic.html > > > > > > > Thanks looks very interesting and looks handy to make use of the > > watchdog for it. I will try now to rework the implementation for the sw > > blink to make use of cyclic thing. > > > > > > Also notice that it's really not a one setting since almost all device > > > > have GPIO LEDs and doesn't have a way to support HW Blink so the > > > > "activity" function needs to be called multiple time to increase the > > > > counter and toggle the LED. > > > > > > > > > > Cyclic callback would be called twice per expected blink period, where you > > > would toggle the GPIO (essentially making it 50% duty cycle, but could be > > > more fine-grained if you want a different duty cycle). > > > > > > > Well status LED already have CONFIG_STATUS_LED_FREQ where you can set a > > value. I will just use this. > > > > This actually only appears in the rST doc, nothing actually makes use of > this right now, so it's not something we **need** to use. > > What I meant is, if you only provide a frequency, a specific, hardcoded, > pattern is expected. E.g. for 1KHz, you enable the LED for 0.5ms and disable > it for 0.5ms (or 1ms and 1ms, depending on how you see LED_STATUS_FREQ > working). Could be 0.2ms and 0.8ms but it would always be this. How do you > differentiate between "something is happening on NAND" and "TFTP is being > used" if you don't have the ability to change the duty cycle? Or are you > expecting people to have multiple LED of different colors for that? > I just sent v2 to account for the Cyclic thing. Honestly I wanted to keep the thing very simple with the config we already had. But yes it's pretty easy to add additional config to configure different blink times. > > > > Also this have the extra feature that you can check if something gets > > > > stuck in the process. The lifecycle is: > > > > - Turn on the ACTIVITY LED at the start of the thing > > > > - Blink once in a while (for very little task this might not happen) > > > > - Turn off the ACTIVITY LED at the end of the thing > > > > > > > > Soo if something goes wrong the LED would never turn OFF but would stay > > > > solid ON. > > > > > > > > > > Yes, that's something that wouldn't be covered by cyclic framework here. > > > It > > > all depends what you want to do, if it's an activity LED, then we need to > > > hook
[PATCH v2 8/8] doc: convert README.LED to .rst documentation
Convert README.LED to .rst documentation and include all the relevant documentation in the status_led.h. Signed-off-by: Christian Marangi --- doc/README.LED | 77 -- doc/api/index.rst | 1 + doc/api/status_led.rst | 35 +++ include/status_led.h | 224 - 4 files changed, 256 insertions(+), 81 deletions(-) delete mode 100644 doc/README.LED create mode 100644 doc/api/status_led.rst diff --git a/doc/README.LED b/doc/README.LED deleted file mode 100644 index c21c9d53ec3..000 --- a/doc/README.LED +++ /dev/null @@ -1,77 +0,0 @@ -Status LED - - -This README describes the status LED API. - -The API is defined by the include file include/status_led.h - -The first step is to enable CONFIG_LED_STATUS in menuconfig: -> Device Drivers > LED Support. - -If the LED support is only for specific board, enable -CONFIG_LED_STATUS_BOARD_SPECIFIC in the menuconfig. - -Status LEDS 0 to 5 are enabled by the following configurations at menuconfig: -CONFIG_STATUS_LED0, CONFIG_STATUS_LED1, ... CONFIG_STATUS_LED5 - -The following should be configured for each of the enabled LEDs: -CONFIG_STATUS_LED_BIT -CONFIG_STATUS_LED_STATE -CONFIG_STATUS_LED_FREQ -Where is an integer 1 through 5 (empty for 0). - -CONFIG_STATUS_LED_BIT is passed into the __led_* functions to identify which LED -is being acted on. As such, the value choose must be unique with with respect to -the other CONFIG_STATUS_LED_BIT's. Mapping the value to a physical LED is the -reponsiblity of the __led_* function. - -CONFIG_STATUS_LED_STATE is the initial state of the LED. It should be set to one -of these values: CONFIG_LED_STATUS_OFF or CONFIG_LED_STATUS_ON. - -CONFIG_STATUS_LED_FREQ determines the LED blink frequency. -Values range from 2 to 10. - -Some other LED macros -- - -CONFIG_STATUS_LED_BOOT is the LED to light when the board is booting. -This must be a valid LED number (0-5). - -CONFIG_STATUS_LED_RED is the red LED. It is used to signal errors. This must be -a valid LED number (0-5). Other similar color LED's macros are -CONFIG_STATUS_LED_GREEN, CONFIG_STATUS_LED_YELLOW and CONFIG_STATUS_LED_BLUE. - -General LED functions -- -The following functions should be defined: - -__led_init is called once to initialize the LED to CONFIG_STATUS_LED_STATE. -One time start up code should be placed here. - -__led_set is called to change the state of the LED. - -__led_toggle is called to toggle the current state of the LED. - -Colour LED - - -Colour LED's are at present only used by ARM. - -The functions names explain their purpose. - -coloured_LED_init -red_LED_on -red_LED_off -green_LED_on -green_LED_off -yellow_LED_on -yellow_LED_off -blue_LED_on -blue_LED_off - -These are weakly defined in arch/arm/lib/board.c to noops. Where applicable, define -these functions in the board specific source. - -TBD : Describe older board dependent macros similar to what is done for - -TBD : Describe general support via asm/status_led.h diff --git a/doc/api/index.rst b/doc/api/index.rst index 51b2013af36..d40e90801d1 100644 --- a/doc/api/index.rst +++ b/doc/api/index.rst @@ -22,6 +22,7 @@ U-Boot API documentation rng sandbox serial + status_led sysreset timer unicode diff --git a/doc/api/status_led.rst b/doc/api/status_led.rst new file mode 100644 index 000..44bbea47157 --- /dev/null +++ b/doc/api/status_led.rst @@ -0,0 +1,35 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Status LED +== + +.. kernel-doc:: include/status_led.h + :doc: Overview + +CONFIG_STATUS_LED Description +- + +.. kernel-doc:: include/status_led.h + :doc: CONFIG Description + +Special Status LED Configs +-- +.. kernel-doc:: include/status_led.h + :doc: LED Status Config + +Colour Status LED Configs +- +.. kernel-doc:: include/status_led.h + :doc: LED Colour Config + +Required API + + +.. kernel-doc:: include/status_led.h + :doc: Required API + +Status LED API +-- + +.. kernel-doc:: include/status_led.h + :internal: diff --git a/include/status_led.h b/include/status_led.h index 7de40551621..6893d1d68e0 100644 --- a/include/status_led.h +++ b/include/status_led.h @@ -4,18 +4,102 @@ * Wolfgang Denk, DENX Software Engineering, w...@denx.de. */ -/* - * The purpose of this code is to signal the operational status of a +/** + * DOC: Overview + * + * Status LED is a Low-Level way to handle LEDs to signal state of the + * bootloader, for example boot progress, file transfer fail, activity + * of some sort like tftp transfer, mtd write/erase. + * + * The original usage these API were to signal the operational status of a * target which usually boots over the network; while running in * PCBoot, a status LED is blinking. As soon as a valid BOOTP reply * message
[PATCH v2 7/8] ubi: implement support for LED status activity
Implement support for LED status activity. If the feature is enabled,
make the defined ACTIVITY LED to signal ubi write operation.
Signed-off-by: Christian Marangi
---
cmd/ubi.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/cmd/ubi.c b/cmd/ubi.c
index 0a6a80bdd10..37c16048b19 100644
--- a/cmd/ubi.c
+++ b/cmd/ubi.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -417,7 +418,19 @@ int ubi_volume_begin_write(char *volume, void *buf, size_t
size,
int ubi_volume_write(char *volume, void *buf, size_t size)
{
- return ubi_volume_begin_write(volume, buf, size, size);
+ int ret;
+
+#ifdef CONFIG_LED_STATUS_ACTIVITY_ENABLE
+ status_led_activity_start(CONFIG_LED_STATUS_ACTIVITY);
+#endif
+
+ ret = ubi_volume_begin_write(volume, buf, size, size);
+
+#ifdef CONFIG_LED_STATUS_ACTIVITY_ENABLE
+ status_led_activity_stop(CONFIG_LED_STATUS_ACTIVITY);
+#endif
+
+ return ret;
}
int ubi_volume_read(char *volume, char *buf, size_t size)
--
2.43.0
[PATCH v2 6/8] mtd: implement support for LED status activity
Implement support for LED status activity. If the feature is enabled,
make the defined ACTIVITY LED to signal mtd write or erase operations.
Signed-off-by: Christian Marangi
---
cmd/mtd.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/cmd/mtd.c b/cmd/mtd.c
index 9189f45cabd..a10805d05a5 100644
--- a/cmd/mtd.c
+++ b/cmd/mtd.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#if CONFIG_IS_ENABLED(CMD_MTD_OTP)
#include
#endif
@@ -559,6 +560,11 @@ static int do_mtd_io(struct cmd_tbl *cmdtp, int flag, int
argc,
while (mtd_block_isbad(mtd, off))
off += mtd->erasesize;
+#ifdef CONFIG_LED_STATUS_ACTIVITY_ENABLE
+ if (!read)
+ status_led_activity_start(CONFIG_LED_STATUS_ACTIVITY);
+#endif
+
/* Loop over the pages to do the actual read/write */
while (remaining) {
/* Skip the block if it is bad */
@@ -586,6 +592,11 @@ static int do_mtd_io(struct cmd_tbl *cmdtp, int flag, int
argc,
io_op.oobbuf += io_op.oobretlen;
}
+#ifdef CONFIG_LED_STATUS_ACTIVITY_ENABLE
+ if (!read)
+ status_led_activity_stop(CONFIG_LED_STATUS_ACTIVITY);
+#endif
+
if (!ret && dump)
mtd_dump_device_buf(mtd, start_off, buf, len, woob);
@@ -653,6 +664,10 @@ static int do_mtd_erase(struct cmd_tbl *cmdtp, int flag,
int argc,
erase_op.addr = off;
erase_op.len = mtd->erasesize;
+#ifdef CONFIG_LED_STATUS_ACTIVITY_ENABLE
+ status_led_activity_start(CONFIG_LED_STATUS_ACTIVITY);
+#endif
+
while (len) {
if (!scrub) {
ret = mtd_block_isbad(mtd, erase_op.addr);
@@ -681,6 +696,10 @@ static int do_mtd_erase(struct cmd_tbl *cmdtp, int flag,
int argc,
erase_op.addr += mtd->erasesize;
}
+#ifdef CONFIG_LED_STATUS_ACTIVITY_ENABLE
+ status_led_activity_stop(CONFIG_LED_STATUS_ACTIVITY);
+#endif
+
if (ret && ret != -EIO)
ret = CMD_RET_FAILURE;
else
--
2.43.0
[PATCH v2 5/8] tftp: implement support for LED status activity
Implement support for LED status activity. If the feature is enabled,
make the defined ACTIVITY LED to signal traffic.
Signed-off-by: Christian Marangi
---
net/tftp.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/net/tftp.c b/net/tftp.c
index 2e335413492..0515dc34d4b 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -19,6 +19,7 @@
#include
#include
#include "bootp.h"
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -193,6 +194,9 @@ static void new_transfer(void)
#ifdef CONFIG_CMD_TFTPPUT
tftp_put_final_block_sent = 0;
#endif
+#ifdef CONFIG_LED_STATUS_ACTIVITY_ENABLE
+ status_led_activity_start(CONFIG_LED_STATUS_ACTIVITY);
+#endif
}
#ifdef CONFIG_CMD_TFTPPUT
@@ -302,6 +306,9 @@ static void tftp_complete(void)
time_start * 1000, "/s");
}
puts("\ndone\n");
+#ifdef CONFIG_LED_STATUS_ACTIVITY_ENABLE
+ status_led_activity_stop(CONFIG_LED_STATUS_ACTIVITY);
+#endif
if (!tftp_put_active)
efi_set_bootdev("Net", "", tftp_filename,
map_sysmem(tftp_load_addr, 0),
--
2.43.0
[PATCH v2 4/8] led: status_led: add new activity LED config and functions
Add a new activity LED config and additional functions to implement a
simple software blink feature to signal activity of any kind.
Usual activity might be a file transfer with TFTP, a flash write...
User of this API will call status_led_activity_start/stop() on each
activity and LED will be toggled based on the defined FREQ config value.
With this enabled, cyclic API are also enabled as this makes use of
cyclic API to handle LED blink.
Signed-off-by: Christian Marangi
---
drivers/led/Kconfig | 16 +++
drivers/misc/status_led.c | 41 +++
include/status_led.h | 2 ++
3 files changed, 59 insertions(+)
diff --git a/drivers/led/Kconfig b/drivers/led/Kconfig
index 6c4f02d71f2..869ed78e87f 100644
--- a/drivers/led/Kconfig
+++ b/drivers/led/Kconfig
@@ -359,6 +359,22 @@ config LED_STATUS_BOOT
endif # LED_STATUS_BOOT_ENABLE
+config LED_STATUS_ACTIVITY_ENABLE
+ bool "Enable BOOT LED"
+ select CYCLIC
+ help
+ Enable to turn an LED on when the board is doing some
+ activity (flash write, file download).
+
+if LED_STATUS_ACTIVITY_ENABLE
+
+config LED_STATUS_ACTIVITY
+ int "LED to light when the board is doing some activity"
+ help
+ Valid enabled LED device number.
+
+endif # LED_STATUS_ACTIVITY_ENABLE
+
config LED_STATUS_RED_ENABLE
bool "Enable red LED"
help
diff --git a/drivers/misc/status_led.c b/drivers/misc/status_led.c
index 93bfb410662..5ee68c7c77d 100644
--- a/drivers/misc/status_led.c
+++ b/drivers/misc/status_led.c
@@ -5,6 +5,7 @@
*/
#include
+#include
#include
/*
@@ -23,6 +24,7 @@ typedef struct {
int state;
int period;
int cnt;
+ struct cyclic_info *cyclic;
} led_dev_t;
led_dev_t led_dev[] = {
@@ -140,3 +142,42 @@ void status_led_toggle(int led)
__led_toggle(ld->mask);
}
+
+static void status_led_activity_toggle(void *ctx)
+{
+ __led_toggle(*(led_id_t *)ctx);
+}
+
+void status_led_activity_start(int led)
+{
+ led_dev_t *ld;
+
+ ld = status_get_led_dev(led);
+ if (!ld)
+ return;
+
+ if (ld->cyclic) {
+ printf("Cyclic for activity status LED already registered. THIS
IS AN ERROR.\n");
+ cyclic_unregister(ld->cyclic);
+ }
+
+ status_led_set(led, CONFIG_LED_STATUS_BLINKING);
+
+ ld->cyclic = cyclic_register(status_led_activity_toggle,
+ld->period * 500, "activity", >mask);
+ if (!ld->cyclic)
+ printf("Registering of cyclic function for activity status LED
failed\n");
+}
+
+void status_led_activity_stop(int led)
+{
+ led_dev_t *ld;
+
+ ld = status_get_led_dev(led);
+ if (!ld)
+ return;
+
+ cyclic_unregister(ld->cyclic);
+ ld->cyclic = NULL
+ status_led_set(led, CONFIG_LED_STATUS_OFF);
+}
diff --git a/include/status_led.h b/include/status_led.h
index fe0c84fb4b4..7de40551621 100644
--- a/include/status_led.h
+++ b/include/status_led.h
@@ -39,6 +39,8 @@ void status_led_init(void);
void status_led_tick(unsigned long timestamp);
void status_led_set(int led, int state);
void status_led_toggle(int led);
+void status_led_activity_start(int led);
+void status_led_activity_stop(int led);
/* MVS v1 **/
#if (defined(CONFIG_MVS) && CONFIG_MVS < 2)
--
2.43.0
[PATCH v2 3/8] led: status_led: add function to toggle a status LED
Add function to toggle a status LED by using the status LED ID reference
configs.
Signed-off-by: Christian Marangi
---
drivers/misc/status_led.c | 28 +++-
include/status_led.h | 1 +
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/misc/status_led.c b/drivers/misc/status_led.c
index a6e9c03a02e..93bfb410662 100644
--- a/drivers/misc/status_led.c
+++ b/drivers/misc/status_led.c
@@ -103,17 +103,24 @@ void status_led_tick(ulong timestamp)
}
}
-void status_led_set(int led, int state)
+static led_dev_t *status_get_led_dev(int led)
{
- led_dev_t *ld;
-
if (led < 0 || led >= MAX_LED_DEV)
- return;
+ return NULL;
if (!status_led_init_done)
status_led_init();
- ld = _dev[led];
+ return _dev[led];
+}
+
+void status_led_set(int led, int state)
+{
+ led_dev_t *ld;
+
+ ld = status_get_led_dev(led);
+ if (!ld)
+ return;
ld->state = state;
if (state == CONFIG_LED_STATUS_BLINKING) {
@@ -122,3 +129,14 @@ void status_led_set(int led, int state)
}
__led_set (ld->mask, state);
}
+
+void status_led_toggle(int led)
+{
+ led_dev_t *ld;
+
+ ld = status_get_led_dev(led);
+ if (!ld)
+ return;
+
+ __led_toggle(ld->mask);
+}
diff --git a/include/status_led.h b/include/status_led.h
index 5ce4522b029..fe0c84fb4b4 100644
--- a/include/status_led.h
+++ b/include/status_led.h
@@ -38,6 +38,7 @@
void status_led_init(void);
void status_led_tick(unsigned long timestamp);
void status_led_set(int led, int state);
+void status_led_toggle(int led);
/* MVS v1 **/
#if (defined(CONFIG_MVS) && CONFIG_MVS < 2)
--
2.43.0
[PATCH v2 2/8] led: status_led: add support for white LED colour
Add support for white LED colour present on many devices.
Signed-off-by: Christian Marangi
---
cmd/legacy_led.c| 6 ++
common/board_f.c| 2 ++
drivers/led/Kconfig | 14 ++
drivers/misc/gpio_led.c | 12
include/status_led.h| 4
5 files changed, 38 insertions(+)
diff --git a/cmd/legacy_led.c b/cmd/legacy_led.c
index 5256255f052..40dbc05a651 100644
--- a/cmd/legacy_led.c
+++ b/cmd/legacy_led.c
@@ -57,6 +57,9 @@ static const led_tbl_t led_commands[] = {
#endif
#ifdef CONFIG_LED_STATUS_BLUE
{ "blue", CONFIG_LED_STATUS_BLUE, blue_led_off, blue_led_on, NULL },
+#endif
+#ifdef CONFIG_LED_STATUS_WHITE
+ { "white", CONFIG_LED_STATUS_WHITE, white_led_off, white_led_on, NULL },
#endif
{ NULL, 0, NULL, NULL, NULL }
};
@@ -180,6 +183,9 @@ U_BOOT_CMD(
#endif
#ifdef CONFIG_LED_STATUS_BLUE
"blue|"
+#endif
+#ifdef CONFIG_LED_STATUS_WHITE
+ "white|"
#endif
"all] [on|off|toggle|blink] [blink-freq in ms]",
"[led_name] [on|off|toggle|blink] sets or clears led(s)"
diff --git a/common/board_f.c b/common/board_f.c
index 039d6d712d0..54e2009339e 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -72,6 +72,8 @@ __weak void yellow_led_on(void) {}
__weak void yellow_led_off(void) {}
__weak void blue_led_on(void) {}
__weak void blue_led_off(void) {}
+__weak void white_led_on(void) {}
+__weak void white_led_off(void) {}
/*
* Why is gd allocated a register? Prior to reloc it might be better to
diff --git a/drivers/led/Kconfig b/drivers/led/Kconfig
index 9837960198d..6c4f02d71f2 100644
--- a/drivers/led/Kconfig
+++ b/drivers/led/Kconfig
@@ -415,6 +415,20 @@ config LED_STATUS_GREEN
endif # LED_STATUS_GREEN_ENABLE
+config LED_STATUS_WHITE_ENABLE
+ bool "Enable white LED"
+ help
+ Enable white status LED.
+
+if LED_STATUS_WHITE_ENABLE
+
+config LED_STATUS_WHITE
+ int "White LED identification"
+ help
+ Valid enabled LED device number (0-5).
+
+endif # LED_STATUS_WHITE_ENABLE
+
config LED_STATUS_CMD
bool "Enable status LED commands"
diff --git a/drivers/misc/gpio_led.c b/drivers/misc/gpio_led.c
index 0f3682e1465..de84c206b6b 100644
--- a/drivers/misc/gpio_led.c
+++ b/drivers/misc/gpio_led.c
@@ -112,3 +112,15 @@ void blue_led_off(void)
__led_set(GPIO_BIT(CONFIG_LED_STATUS_BLUE), CONFIG_LED_STATUS_OFF);
}
#endif
+
+#ifdef CONFIG_LED_STATUS_WHITE
+void white_led_on(void)
+{
+ __led_set(GPIO_BIT(CONFIG_LED_STATUS_WHITE), CONFIG_LED_STATUS_ON);
+}
+
+void white_led_off(void)
+{
+ __led_set(GPIO_BIT(CONFIG_LED_STATUS_WHITE), CONFIG_LED_STATUS_OFF);
+}
+#endif
diff --git a/include/status_led.h b/include/status_led.h
index 6707ab1d29d..5ce4522b029 100644
--- a/include/status_led.h
+++ b/include/status_led.h
@@ -87,6 +87,8 @@ void yellow_led_on(void);
void yellow_led_off(void);
void blue_led_on(void);
void blue_led_off(void);
+void white_led_on(void);
+void white_led_off(void);
#else
.extern LED_init
.extern red_led_on
@@ -97,6 +99,8 @@ void blue_led_off(void);
.extern green_led_off
.extern blue_led_on
.extern blue_led_off
+ .extern white_led_on
+ .extern white_led_off
#endif
#endif /* _STATUS_LED_H_ */
--
2.43.0
[PATCH v2 1/8] misc: gpio_led: fix broken coloured LED status functions
The GPIO LED driver is a backend to provide LED status functions via the
GPIO common functions.
The coloured LED functions are currently broken and deviates from what
is written in README.LED
Quoting the README.LED:
CONFIG_STATUS_LED_RED is the red LED. It is used to signal errors.
This must be a valid LED number (0-5). Other similar color LED's macros
are CONFIG_STATUS_LED_GREEN, CONFIG_STATUS_LED_YELLOW and
CONFIG_STATUS_LED_BLUE.
Hence the value of the config must refer to the ID.
Currently this is not the case and the driver expect the GPIO ID to be
put in these config. On top of this to actually have these functions, a
never define in Kconfig config must be declared to actually compile
them. (CONFIG_GPIO_LED_STUBS)
To fix this and the GPIO problem, introduce some define that reference
the LED_STATUS_BIT config to have the ID->BIT connection (as
described in Docs) and drop the never defined config.
The gpio_led already provide a wrapper to the functions and should not
be enabled if the board provide their custom function hence it's ok to
also provide the wrapper for the colour functions.
Signed-off-by: Christian Marangi
---
drivers/misc/gpio_led.c | 31 +++
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/misc/gpio_led.c b/drivers/misc/gpio_led.c
index 30679f80cf1..0f3682e1465 100644
--- a/drivers/misc/gpio_led.c
+++ b/drivers/misc/gpio_led.c
@@ -52,56 +52,63 @@ void __led_toggle(led_id_t mask)
gpio_set_value(mask, !gpio_get_value(mask));
}
-#ifdef CONFIG_GPIO_LED_STUBS
-
/* 'generic' override of colored LED stubs, to use GPIO functions instead */
+/* We support up to 6 LEDs, LED 0 STATUS BIT doesn't have the number suffix */
+#define GPIO_BIT0 CONFIG_LED_STATUS_BIT
+#define GPIO_BIT1 CONFIG_LED_STATUS_BIT1
+#define GPIO_BIT2 CONFIG_LED_STATUS_BIT2
+#define GPIO_BIT3 CONFIG_LED_STATUS_BIT3
+#define GPIO_BIT4 CONFIG_LED_STATUS_BIT4
+#define GPIO_BIT5 CONFIG_LED_STATUS_BIT5
+/* C preprocessor magic way to generate a GPIO_LED reference */
+#define GPIO_BIT(id) ___PASTE(GPIO_BIT, id)
+
#ifdef CONFIG_LED_STATUS_RED
+
void red_led_on(void)
{
- __led_set(CONFIG_LED_STATUS_RED, CONFIG_LED_STATUS_ON);
+ __led_set(GPIO_BIT(CONFIG_LED_STATUS_RED), CONFIG_LED_STATUS_ON);
}
void red_led_off(void)
{
- __led_set(CONFIG_LED_STATUS_RED, CONFIG_LED_STATUS_OFF);
+ __led_set(GPIO_BIT(CONFIG_LED_STATUS_RED), CONFIG_LED_STATUS_OFF);
}
#endif
#ifdef CONFIG_LED_STATUS_GREEN
void green_led_on(void)
{
- __led_set(CONFIG_LED_STATUS_GREEN, CONFIG_LED_STATUS_ON);
+ __led_set(GPIO_BIT(CONFIG_LED_STATUS_GREEN), CONFIG_LED_STATUS_ON);
}
void green_led_off(void)
{
- __led_set(CONFIG_LED_STATUS_GREEN, CONFIG_LED_STATUS_OFF);
+ __led_set(GPIO_BIT(CONFIG_LED_STATUS_GREEN), CONFIG_LED_STATUS_OFF);
}
#endif
#ifdef CONFIG_LED_STATUS_YELLOW
void yellow_led_on(void)
{
- __led_set(CONFIG_LED_STATUS_YELLOW, CONFIG_LED_STATUS_ON);
+ __led_set(GPIO_BIT(CONFIG_LED_STATUS_YELLOW), CONFIG_LED_STATUS_ON);
}
void yellow_led_off(void)
{
- __led_set(CONFIG_LED_STATUS_YELLOW, CONFIG_LED_STATUS_OFF);
+ __led_set(GPIO_BIT(CONFIG_LED_STATUS_YELLOW), CONFIG_LED_STATUS_OFF);
}
#endif
#ifdef CONFIG_LED_STATUS_BLUE
void blue_led_on(void)
{
- __led_set(CONFIG_LED_STATUS_BLUE, CONFIG_LED_STATUS_ON);
+ __led_set(GPIO_BIT(CONFIG_LED_STATUS_BLUE), CONFIG_LED_STATUS_ON);
}
void blue_led_off(void)
{
- __led_set(CONFIG_LED_STATUS_BLUE, CONFIG_LED_STATUS_OFF);
+ __led_set(GPIO_BIT(CONFIG_LED_STATUS_BLUE), CONFIG_LED_STATUS_OFF);
}
#endif
-
-#endif /* CONFIG_GPIO_LED_STUBS */
--
2.43.0
[PATCH v2 0/8] misc: introduce STATUS LED activity function
This series expand the STATUS LED framework with a new color and a big new feature. One thing that many device need is a way to communicate to the user that the device is actually doing something. This is especially useful for recovery steps where an user (for example) insert an USB drive, keep a button pressed and the device autorecover. There is currently no way to signal the user externally that the bootloader is processing/recoverying aside from setting a LED on. A solid LED on is not enough and won't actually signal any kind of progress. Solution is the good old blinking LED but uboot doesn't suggest (and support) interrupts and almost all the LED are usually GPIO LED that doesn't support HW blink. To fix this and handle the problem of device not supporting HW blink, expand the STATUS LED framework with new API. We introduce a new config LED_STATUS_ACTIVITY, that similar to the RED, GREEN and others, takes the LED ID set in the LED_STATUS config and is used as the global LED for activity operations. We add status_led_activity_start/stop() used to turn the activity LED on and register a cyclic to make it blink. LED will continue to blink until _stop() is called. Function that will start some kind of action will first call _start() and then at the end will call stop(). If (on the broken implementation) a _start() is called before calling a _stop(), the Cyclic is first unregister and is registered again. Support for this is initially added to the tftp, mtd and ubi command. This also contains a big fixup for the gpio_led driver that currently deviates from the Documentation and make the coloured status led feature unusable. Changes v2: - Add Documentation conversion - Rework to Cyclic and simplify implementation Christian Marangi (8): misc: gpio_led: fix broken coloured LED status functions led: status_led: add support for white LED colour led: status_led: add function to toggle a status LED led: status_led: add new activity LED config and functions tftp: implement support for LED status activity mtd: implement support for LED status activity ubi: implement support for LED status activity doc: convert README.LED to .rst documentation cmd/legacy_led.c | 6 + cmd/mtd.c | 19 cmd/ubi.c | 15 ++- common/board_f.c | 2 + doc/README.LED| 77 - doc/api/index.rst | 1 + doc/api/status_led.rst| 35 ++ drivers/led/Kconfig | 30 + drivers/misc/gpio_led.c | 41 +-- drivers/misc/status_led.c | 69 +++- include/status_led.h | 231 +- net/tftp.c| 7 ++ 12 files changed, 435 insertions(+), 98 deletions(-) delete mode 100644 doc/README.LED create mode 100644 doc/api/status_led.rst -- 2.43.0
[PATCH 6/6] powerpc: Add support for CZ.NIC Turris 1.x routers
From: Pali Rohár Add support for CZ.NIC Turris 1.x routers. CZ.NIC Turris 1.0 (RTRS01) and 1.1 (RTRS02) are open source routers, they have dual-core PowerPC Freescale P2020 CPU and are based on reference Freescale P2020RDB-PC-A board design. Hardware design is fully open source, all firmware and hardware design files are available at Turris project website: https://docs.turris.cz/hw/turris-1x/turris-1x/ https://project.turris.cz/en/hardware.html The P2020 BootROM can load U-Boot either from NOR flash or from SD card. We add the new defconfigs, turris_1x_nor_defconfig, which configures U-Boot for building the NOR image, and turris_1x_sdcard_defconfig, which configures U-Boot for building an image suitable for SD card. The defconfig for NOR image is stripped-down a - many config options enabled in SD defconfig are disabled for NOR defconfig. This is because U-Boot grew non-trivially in the last two years and it would not fit into the space allocated for U-Boot in the NOR memory. In the future we may try to use LTO to reduce the size of the code and enable more options. The design of CZ.NIC Turris 1.x routers is based on Freescale P2020RDB-PC-A board, so some code from boards/freescale/p1_p2_rdb_pc is used and linked into Turris 1.x board code. Turris 1.x code in this patch uses modern distroboot and can boot Linux kernel from various locations, including NAND, SD card, USB flash disks, NVMe disks or SATA disks (connected to extra SATA/SCSI PCIe controllers). Via distroboot is implemented also rescue NOR boot for factory recovery, triggered by reset button, like on other existing Turris routers. SD boot with RAM larger than 2GB will only allocate 2GB of RAM (We were not able to fix this yet) Signed-off-by: Pali Rohár [ Because various CONFIG_ macros were migrated to Kconfig since the last time this worked on upstream U-Boot (in 2022), a non-trivial rebasing was needed and some issues were solved. ] Signed-off-by: Marek Mojík --- arch/powerpc/cpu/mpc85xx/Kconfig| 7 + arch/powerpc/dts/Makefile | 1 + arch/powerpc/dts/turris1x-u-boot.dtsi | 17 + arch/powerpc/dts/turris1x.dts | 511 ++ board/CZ.NIC/turris_1x/Kconfig | 155 ++ board/CZ.NIC/turris_1x/MAINTAINERS | 13 + board/CZ.NIC/turris_1x/Makefile | 15 + board/CZ.NIC/turris_1x/ddr.c| 28 + board/CZ.NIC/turris_1x/law.c| 13 + board/CZ.NIC/turris_1x/tlb.c| 143 + board/CZ.NIC/turris_1x/turris_1x.c | 571 board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 9 +- boot/Kconfig| 2 +- configs/turris_1x_nor_defconfig | 87 +++ configs/turris_1x_sdcard_defconfig | 106 include/configs/turris_1x.h | 335 16 files changed, 2011 insertions(+), 2 deletions(-) create mode 100644 arch/powerpc/dts/turris1x-u-boot.dtsi create mode 100644 arch/powerpc/dts/turris1x.dts create mode 100644 board/CZ.NIC/turris_1x/Kconfig create mode 100644 board/CZ.NIC/turris_1x/MAINTAINERS create mode 100644 board/CZ.NIC/turris_1x/Makefile create mode 100644 board/CZ.NIC/turris_1x/ddr.c create mode 100644 board/CZ.NIC/turris_1x/law.c create mode 100644 board/CZ.NIC/turris_1x/tlb.c create mode 100644 board/CZ.NIC/turris_1x/turris_1x.c create mode 100644 configs/turris_1x_nor_defconfig create mode 100644 configs/turris_1x_sdcard_defconfig create mode 100644 include/configs/turris_1x.h diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig index e813bf094d..b441ba9840 100644 --- a/arch/powerpc/cpu/mpc85xx/Kconfig +++ b/arch/powerpc/cpu/mpc85xx/Kconfig @@ -173,6 +173,12 @@ config TARGET_P2020RDB imply CMD_SATA imply SATA_SIL +config TARGET_TURRIS_1X + bool "Support Turris 1.x" + select SUPPORT_SPL + select ARCH_P2020 + select SYS_L2_SIZE_512KB + config TARGET_P2041RDB bool "Support P2041RDB" select ARCH_P2041 @@ -1530,6 +1536,7 @@ config TPL_SYS_MPC85XX_NO_RESETVEC config FSL_VIA bool +source "board/CZ.NIC/turris_1x/Kconfig" source "board/emulation/qemu-ppce500/Kconfig" source "board/freescale/mpc8548cds/Kconfig" source "board/freescale/p1010rdb/Kconfig" diff --git a/arch/powerpc/dts/Makefile b/arch/powerpc/dts/Makefile index bb436f02bc..321c644804 100644 --- a/arch/powerpc/dts/Makefile +++ b/arch/powerpc/dts/Makefile @@ -26,6 +26,7 @@ dtb-$(CONFIG_TARGET_T2080QDS) += t2080qds.dtb dtb-$(CONFIG_TARGET_T2080RDB) += t2080rdb.dtb dtb-$(CONFIG_TARGET_T4240RDB) += t4240rdb.dtb dtb-$(CONFIG_TARGET_TUGE1) += kmtuge1.dtb +dtb-$(CONFIG_TARGET_TURRIS_1X) += turris1x.dtb dtb-$(CONFIG_TARGET_TUXX1) += kmtuxa1.dtb dtb-$(CONFIG_TARGET_MCR3000) += mcr3000.dtb dtb-$(CONFIG_TARGET_GAZERBEAM) += gazerbeam.dtb diff --git a/arch/powerpc/dts/turris1x-u-boot.dtsi b/arch/powerpc/dts/turris1x-u-boot.dtsi new
[PATCH 0/6] Add Turris 1.x board
Hello all, this is a continuation of previous work by Pali to add support for the Turris 1.x board. As the patches were based on u-boot v2022.04, a nontrivial rebasing was needed. Some notes: - Some options that are in SD defconfig are disabled in NOR defconfig because over the years u-boot grew and the old NOR defconfig will not fit into NOR memory. - SD boot with RAM larger than 2GB will only allocate 2GB of RAM (We were not able to fix this yet) Marek Mojík (2): powerpc: mpc85xx: use CONFIG_VAL() for SYS_MONITOR_BASE in start.s powerpc: use CONFIG_IS_ENABLED() when checking for DM_SERIAL in include/asm/config.h This contributor prefers not to receive mails (4): board_f: Add support for CONFIG_OF_BOARD_FIXUP for XIP images board: freescale: p1_p2_rdb_pc: Add weak function p1_p2_rdb_pc_fix_fdt_model() for fixing DT model string powerpc: mpc8xxx: Extend find_law() to find_law_by_addr_id() powerpc: Add support for CZ.NIC Turris 1.x routers arch/powerpc/cpu/mpc85xx/Kconfig| 7 + arch/powerpc/cpu/mpc85xx/start.S| 2 +- arch/powerpc/cpu/mpc8xxx/law.c | 5 +- arch/powerpc/dts/Makefile | 1 + arch/powerpc/dts/turris1x-u-boot.dtsi | 17 + arch/powerpc/dts/turris1x.dts | 511 ++ arch/powerpc/include/asm/config.h | 2 +- arch/powerpc/include/asm/fsl_law.h | 8 +- board/CZ.NIC/turris_1x/Kconfig | 155 ++ board/CZ.NIC/turris_1x/MAINTAINERS | 13 + board/CZ.NIC/turris_1x/Makefile | 15 + board/CZ.NIC/turris_1x/ddr.c| 28 + board/CZ.NIC/turris_1x/law.c| 13 + board/CZ.NIC/turris_1x/tlb.c| 143 + board/CZ.NIC/turris_1x/turris_1x.c | 571 board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 13 +- boot/Kconfig| 2 +- common/board_f.c| 8 +- configs/turris_1x_nor_defconfig | 87 +++ configs/turris_1x_sdcard_defconfig | 106 dts/Kconfig | 6 + include/configs/turris_1x.h | 335 22 files changed, 2041 insertions(+), 7 deletions(-) create mode 100644 arch/powerpc/dts/turris1x-u-boot.dtsi create mode 100644 arch/powerpc/dts/turris1x.dts create mode 100644 board/CZ.NIC/turris_1x/Kconfig create mode 100644 board/CZ.NIC/turris_1x/MAINTAINERS create mode 100644 board/CZ.NIC/turris_1x/Makefile create mode 100644 board/CZ.NIC/turris_1x/ddr.c create mode 100644 board/CZ.NIC/turris_1x/law.c create mode 100644 board/CZ.NIC/turris_1x/tlb.c create mode 100644 board/CZ.NIC/turris_1x/turris_1x.c create mode 100644 configs/turris_1x_nor_defconfig create mode 100644 configs/turris_1x_sdcard_defconfig create mode 100644 include/configs/turris_1x.h -- 2.45.1
[PATCH 5/6] powerpc: use CONFIG_IS_ENABLED() when checking for DM_SERIAL in include/asm/config.h
Use the CONFIG_IS_ENABLED() macro when checking for DM_SERIAL so that CFG_SYS_NS16550_CLK is not defined as get_serial_clock() in SPL if SPL does not have DM_SERIAL enabled. Signed-off-by: Marek Mojík --- arch/powerpc/include/asm/config.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/config.h b/arch/powerpc/include/asm/config.h index f0702cab14..f61f4e1ea6 100644 --- a/arch/powerpc/include/asm/config.h +++ b/arch/powerpc/include/asm/config.h @@ -39,7 +39,7 @@ /* The FMAN driver uses the PHYLIB infrastructure */ -#if defined(CONFIG_DM_SERIAL) && !defined(CONFIG_CLK_MPC83XX) +#if CONFIG_IS_ENABLED(DM_SERIAL) && !defined(CONFIG_CLK_MPC83XX) /* * TODO: Convert this to a clock driver exists that can give us the UART * clock here. -- 2.45.1
[PATCH 2/6] board: freescale: p1_p2_rdb_pc: Add weak function p1_p2_rdb_pc_fix_fdt_model() for fixing DT model string
From: Pali Rohár
This allows boards to fixup / overwrite DT model string when booting OS.
Signed-off-by: Pali Rohár
Signed-off-by: Marek Mojík
---
board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 4
1 file changed, 4 insertions(+)
diff --git a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
index 399ff72072..336d274cdb 100644
--- a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
+++ b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
@@ -364,6 +364,8 @@ int board_early_init_r(void)
return 0;
}
+__weak void p1_p2_rdb_pc_fix_fdt_model(void *blob) {}
+
#if defined(CONFIG_OF_BOARD_SETUP) || defined(CONFIG_OF_BOARD_FIXUP)
static void fix_max6370_watchdog(void *blob)
{
@@ -407,6 +409,7 @@ int ft_board_setup(void *blob, struct bd_info *bd)
sizeof("okay"), 0);
#endif
+ p1_p2_rdb_pc_fix_fdt_model(blob);
fix_max6370_watchdog(blob);
#if defined(CONFIG_HAS_FSL_DR_USB)
@@ -464,6 +467,7 @@ int ft_board_setup(void *blob, struct bd_info *bd)
#ifdef CONFIG_OF_BOARD_FIXUP
int board_fix_fdt(void *blob)
{
+ p1_p2_rdb_pc_fix_fdt_model(blob);
fix_max6370_watchdog(blob);
return 0;
}
--
2.45.1
[PATCH 1/6] board_f: Add support for CONFIG_OF_BOARD_FIXUP for XIP images
From: Pali Rohár
When U-Boot is running from flash memory (execute in place) then
gd->fdt_blob before relocation points to read-only flash memory.
So U-Boot calls board_fix_fdt() with read-only gd->fdt_blob pointer which
cause immediate CPU crash when callback is trying to modify gd->fdt_blob.
Fix this issue by introducing a new config option OF_INITIAL_DTB_READONLY
which moves fix_fdt callback after the reloc_fdt callback. This makes
CONFIG_OF_BOARD_FIXUP working also if U-Boot before relocation is not
running from read/write (S)RAM memory.
This is required for mpc85xx boards when booting from flash NOR.
Signed-off-by: Pali Rohár
Signed-off-by: Marek Mojík
---
common/board_f.c | 8 +++-
dts/Kconfig | 6 ++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/common/board_f.c b/common/board_f.c
index 212ffb3090..22c180b218 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -949,7 +949,7 @@ static const init_fnc_t init_sequence_f[] = {
* - board info struct
*/
setup_dest_addr,
-#ifdef CONFIG_OF_BOARD_FIXUP
+#if defined(CONFIG_OF_BOARD_FIXUP) && !defined(CONFIG_OF_INITIAL_DTB_READONLY)
fix_fdt,
#endif
#ifdef CFG_PRAM
@@ -965,6 +965,10 @@ static const init_fnc_t init_sequence_f[] = {
reserve_board,
reserve_global_data,
reserve_fdt,
+#if defined(CONFIG_OF_BOARD_FIXUP) && defined(CONFIG_OF_INITIAL_DTB_READONLY)
+ reloc_fdt,
+ fix_fdt,
+#endif
reserve_bootstage,
reserve_bloblist,
reserve_arch,
@@ -975,7 +979,9 @@ static const init_fnc_t init_sequence_f[] = {
setup_bdinfo,
display_new_sp,
INIT_FUNC_WATCHDOG_RESET
+#if !defined(CONFIG_OF_BOARD_FIXUP) || !defined(CONFIG_OF_INITIAL_DTB_READONLY)
reloc_fdt,
+#endif
reloc_bootstage,
reloc_bloblist,
setup_reloc,
diff --git a/dts/Kconfig b/dts/Kconfig
index 6883a000a0..569d4be338 100644
--- a/dts/Kconfig
+++ b/dts/Kconfig
@@ -145,6 +145,12 @@ config OF_EMBED
endchoice
+config OF_INITIAL_DTB_READONLY
+ bool "Initial DTB for DT control is read-only"
+ help
+ If initial DTB for DT control is read-only (e.g. points to
+ memory-mapped flash memory), then set this option.
+
config OF_BOARD
bool "Provided by the board (e.g a previous loader) at runtime"
default y if SANDBOX || OF_HAS_PRIOR_STAGE
--
2.45.1
[PATCH 4/6] powerpc: mpc85xx: use CONFIG_VAL() for SYS_MONITOR_BASE in start.s
Use CONFIG_VAL() for SYS_MONITOR_BASE in start.S so that correct value is used for SPL. Signed-off-by: Marek Mojík --- arch/powerpc/cpu/mpc85xx/start.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S index b737d5d12f..3e24a90233 100644 --- a/arch/powerpc/cpu/mpc85xx/start.S +++ b/arch/powerpc/cpu/mpc85xx/start.S @@ -116,7 +116,7 @@ bootsect: .long (CONFIG_FSL_PREPBL_ESDHC_BOOT_SECTOR_START + CONFIG_FSL_PREPBL_ESDHC_BOOT_SECTOR_DATA) * 512 .org 0x58 /* Target address in the system's local memory address space */ - .long CONFIG_SYS_MONITOR_BASE + .long CONFIG_VAL(SYS_MONITOR_BASE) .org 0x60 /* Execution starting address */ .long _start -- 2.45.1
[PATCH 3/6] powerpc: mpc8xxx: Extend find_law() to find_law_by_addr_id()
From: Pali Rohár
The find_law() function searches for LAW just by physical address. This
is unsuitable for cases with overlapping LAWs. Extend it to
find_law_by_addr_id(), which searches for LAW by physical address and
target id.
Add a static inline definition of the original find_law() into fsl_law.h
header.
Signed-off-by: Pali Rohár
Signed-off-by: Marek Mojík
---
arch/powerpc/cpu/mpc8xxx/law.c | 5 -
arch/powerpc/include/asm/fsl_law.h | 8 +++-
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/law.c b/arch/powerpc/cpu/mpc8xxx/law.c
index f16bc19966..f3a9749625 100644
--- a/arch/powerpc/cpu/mpc8xxx/law.c
+++ b/arch/powerpc/cpu/mpc8xxx/law.c
@@ -130,7 +130,7 @@ int set_last_law(phys_addr_t addr, enum law_size sz, enum
law_trgt_if id)
return idx;
}
-struct law_entry find_law(phys_addr_t addr)
+struct law_entry find_law_by_addr_id(phys_addr_t addr, enum law_trgt_if id)
{
struct law_entry entry;
int i;
@@ -146,6 +146,9 @@ struct law_entry find_law(phys_addr_t addr)
if (!get_law_entry(i, ))
continue;
+ if (id != -1 && id != entry.trgt_id)
+ continue;
+
upper = entry.addr + (2ull << entry.size);
if ((addr >= entry.addr) && (addr < upper)) {
entry.index = i;
diff --git a/arch/powerpc/include/asm/fsl_law.h
b/arch/powerpc/include/asm/fsl_law.h
index 9e2f2d5370..d1cd728397 100644
--- a/arch/powerpc/include/asm/fsl_law.h
+++ b/arch/powerpc/include/asm/fsl_law.h
@@ -130,7 +130,13 @@ extern void set_law(u8 idx, phys_addr_t addr, enum
law_size sz, enum law_trgt_if
extern int set_next_law(phys_addr_t addr, enum law_size sz, enum law_trgt_if
id);
extern int set_last_law(phys_addr_t addr, enum law_size sz, enum law_trgt_if
id);
extern int set_ddr_laws(u64 start, u64 sz, enum law_trgt_if id);
-extern struct law_entry find_law(phys_addr_t addr);
+extern struct law_entry find_law_by_addr_id(phys_addr_t addr, enum law_trgt_if
id);
+
+static inline struct law_entry find_law(phys_addr_t addr)
+{
+ return find_law_by_addr_id(addr, -1);
+}
+
extern void disable_law(u8 idx);
extern void init_laws(void);
extern void print_laws(void);
--
2.45.1
Re: [PATCH] board: rockchip: Add FriendlyElec NanoPi R6C
Hi Quentin,
thanks for your feedback!
Am 06.06.2024 um 16:53 schrieb Quentin Schulz:
Hi Sebastian,
On 6/5/24 5:36 PM, Sebastian Kropatsch wrote:
[You don't often get email from seb-...@mail.de. Learn why this is
important at https://aka.ms/LearnAboutSenderIdentification ]
The NanoPi R6C is a SBC by FriendlyElec based on the Rockchip RK3588s.
It comes with 4GB or 8GB of RAM, a microSD card slot, optional 32GB eMMC
storage, one M.2 M-Key connector, one RTL8211F 1GbE and one RTL8125
2.5GbE Ethernet port, one USB 2.0 Type-A and one USB 3.0 Type-A port, a
HDMI port, a 30-pin GPIO header as well as multiple buttons and LEDs.
Add initial support for this board using the upstream devicetree sources.
Tests in U-Boot proper:
- Booting from eMMC works
- 1GbE Ethernet works using the eth_eqos driver (tested by ping)
- 2.5GbE Ethernet works using the eth_rtl8169 driver (tested by ping),
but the status LEDs on this specific port currently aren't working
- NVMe SSD in M.2 socket does get recognized (tested with `nvme scan`
followed by `nvme details`)
Kernel commit:
d5f1d7437451 ("arm64: dts: rockchip: Add support for NanoPi R6C")
Signed-off-by: Sebastian Kropatsch
---
Hello!
The Ethernet status LEDs which sit directly on the 2.5GbE port using the
RTL8169 driver don't light up when connected and I couldn't figure out
why. The other port with a RTL8211F has no problems with the LEDs.
Have there been occurrences like this in combination with the RTL8125?
I'm trying to figure out if this is something that could be solved in
the devicetree or if this is a potential driver bug.
Secondly, the default active network device in U-Boot is the 1GbE one.
I believe it would make sense to make the 2.5GbE device the default
active one since this one is labeled "LAN", whereas the 1GbE is labeled
"WAN". However, since the 2.5GbE device is PCIe-based, it only shows up
in U-Boot proper after using the `pci enum` command (shows up as in gets
listed in `net list` and `dm tree`).
Do you have any tips on the preferred approach to handle this switch of
the default active net device? Is this even a sensible thing to include
in U-Boot in your opinion?
Thanks for your feedback!
Best regards,
Sebastian
---
arch/arm/dts/rk3588s-nanopi-r6c-u-boot.dtsi | 3 +
arch/arm/mach-rockchip/rk3588/Kconfig | 13 +++
board/friendlyelec/nanopi-r6c-rk3588s/Kconfig | 12 +++
.../nanopi-r6c-rk3588s/MAINTAINERS | 7 ++
configs/nanopi-r6c-rk3588s_defconfig | 83 +++
doc/board/rockchip/rockchip.rst | 1 +
include/configs/nanopi-r6c-rk3588s.h | 12 +++
7 files changed, 131 insertions(+)
create mode 100644 arch/arm/dts/rk3588s-nanopi-r6c-u-boot.dtsi
create mode 100644 board/friendlyelec/nanopi-r6c-rk3588s/Kconfig
create mode 100644 board/friendlyelec/nanopi-r6c-rk3588s/MAINTAINERS
create mode 100644 configs/nanopi-r6c-rk3588s_defconfig
create mode 100644 include/configs/nanopi-r6c-rk3588s.h
diff --git a/arch/arm/dts/rk3588s-nanopi-r6c-u-boot.dtsi
b/arch/arm/dts/rk3588s-nanopi-r6c-u-boot.dtsi
new file mode 100644
index 00..853ed58cfe
--- /dev/null
+++ b/arch/arm/dts/rk3588s-nanopi-r6c-u-boot.dtsi
@@ -0,0 +1,3 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk3588s-u-boot.dtsi"
diff --git a/arch/arm/mach-rockchip/rk3588/Kconfig
b/arch/arm/mach-rockchip/rk3588/Kconfig
index 820e979abb..0e232ddfb9 100644
--- a/arch/arm/mach-rockchip/rk3588/Kconfig
+++ b/arch/arm/mach-rockchip/rk3588/Kconfig
@@ -78,6 +78,18 @@ config TARGET_NANOPCT6_RK3588
Power: 5.5*2.1mm DC Jack, 12VDC input
Dimensions: 110x80x1.6mm (without case) / 86x114.5x30mm
(with case)
+config TARGET_NANOPI_R6C_RK3588
Please add the S at the end of the symbol.
u-boot-next currently has two other RK3588s boards, which are Rock5A
and Indiedroid Nova. Both do not have the S at the end of the symbol:
config TARGET_ROCK5A_RK3588
[...]
config TARGET_NOVA_RK3588
Which is why I haven't included the S. Should we update those as well?
I suppose in this case I should also update '/include/configs/nanopi-
r6c-rk3588s.h' which currently reads:
diff --git a/include/configs/nanopi-r6c-rk3588s.h
b/include/configs/nanopi-r6c-rk3588s.h
new file mode 100644
index 00..e05856f3ce
--- /dev/null
+++ b/include/configs/nanopi-r6c-rk3588s.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+
+#ifndef __NANOPI_R6C_RK3588_H
+#define __NANOPI_R6C_RK3588_H
+
+#define ROCKCHIP_DEVICE_SETTINGS \
+ "stdout=serial,vidconsole\0" \
+ "stderr=serial,vidconsole\0"
+
+#include
+
+#endif /* __NANOPI_R6C_RK3588_H */
(end '/include/configs/nanopi-r6c-rk3588s.h')
If this should not be updated to add an S, let me know. I'll send a v2
when I know :)
Otherwise looking good to me. I'm wondering if we shouldn't do something
for boards which do not need a -u-boot.dtsi. Here it's needed because
U-Boot would include
Re: [PATCH v3 06/12] net-lwip: add dns command
On 6/6/24 18:02, Ilias Apalodimas wrote:
> [...]
>
+
+ if (!ipaddr) {
+ printf("DNS: host not found\n");
+ host_ipaddr.addr = 0;
+ return;
+ }
+
+ if (var)
+ env_set(var, ipstr);
>>>
>>> Do we need this? Won't this set == ipaddr?
>>
>> No, the syntax of the dns command is: 'dns hostname [env_var]' so one can
>> pretty much give any variable name to receive the IP address.
>>
>>> If we do not need it repurpose the void *arg and get rid of the global
>>> 'done'
>>
>> I could probably use a struct to get rid of the globals. Let me see what I
>> can do.
>
> Yea just pass a struct with char* and a bool * and you should be fine
Done in v4.
Thanks,
--
Jerome
Re: [PATCH v3 06/12] net-lwip: add dns command
[...]
> >> +
> >> + if (!ipaddr) {
> >> + printf("DNS: host not found\n");
> >> + host_ipaddr.addr = 0;
> >> + return;
> >> + }
> >> +
> >> + if (var)
> >> + env_set(var, ipstr);
> >
> > Do we need this? Won't this set == ipaddr?
>
> No, the syntax of the dns command is: 'dns hostname [env_var]' so one can
> pretty much give any variable name to receive the IP address.
>
> > If we do not need it repurpose the void *arg and get rid of the global
> > 'done'
>
> I could probably use a struct to get rid of the globals. Let me see what I
> can do.
Yea just pass a struct with char* and a bool * and you should be fine
Thanks
/Ilias
>
> >> +
> >> + printf("%s\n", ipstr);
> >> +}
> >> +
> >> +int do_dns(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
> >> +{
> >> + bool has_server = false;
> >> + ip_addr_t ipaddr;
> >> + ip_addr_t ns;
> >> + char *nsenv;
> >> + char *name;
> >> + char *var;
> >> + int ret;
> >
> > [...]
> >
> > Thanks
> > /Ilias
Re: [PATCH v3 06/12] net-lwip: add dns command
On 6/6/24 17:46, Ilias Apalodimas wrote:
>> @@ -7,6 +7,7 @@ obj-$(CONFIG_$(SPL_)DM_ETH) += ../net/eth_common.o
>> obj-$(CONFIG_$(SPL_)DM_ETH) += ../net/eth-uclass.o
>> obj-$(CONFIG_$(SPL_)DM_ETH) += net-lwip.o
>> obj-$(CONFIG_CMD_DHCP) += dhcp.o
>> +obj-$(CONFIG_CMD_DNS) += dns.o
>> obj-$(CONFIG_CMD_PING) += ping.o
>> obj-$(CONFIG_CMD_TFTPBOOT) += tftp.o
>>
>> diff --git a/net-lwip/dns.c b/net-lwip/dns.c
>> new file mode 100644
>> index 000..24a5149343a
>> --- /dev/null
>> +++ b/net-lwip/dns.c
>> @@ -0,0 +1,107 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/* Copyright (C) 2024 Linaro Ltd. */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define DNS_RESEND_MS 1000
>> +#define DNS_TIMEOUT_MS 1
>> +
>> +static ulong start;
>> +static ip_addr_t host_ipaddr;
>> +static bool done;
>> +
>> +static void do_dns_tmr(void *arg)
>> +{
>> + dns_tmr();
>> +}
>> +
>> +static void dns_cb(const char *name, const ip_addr_t *ipaddr, void *arg)
>> +{
>> + const char *var = arg;
>> + char *ipstr = ip4addr_ntoa(ipaddr);
>> +
>> + done = true;
>> +
>> + if (!ipaddr) {
>> + printf("DNS: host not found\n");
>> + host_ipaddr.addr = 0;
>> + return;
>> + }
>> +
>> + if (var)
>> + env_set(var, ipstr);
>
> Do we need this? Won't this set == ipaddr?
No, the syntax of the dns command is: 'dns hostname [env_var]' so one can
pretty much give any variable name to receive the IP address.
> If we do not need it repurpose the void *arg and get rid of the global 'done'
I could probably use a struct to get rid of the globals. Let me see what I can
do.
>> +
>> + printf("%s\n", ipstr);
>> +}
>> +
>> +int do_dns(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
>> +{
>> + bool has_server = false;
>> + ip_addr_t ipaddr;
>> + ip_addr_t ns;
>> + char *nsenv;
>> + char *name;
>> + char *var;
>> + int ret;
>
> [...]
>
> Thanks
> /Ilias
Re: [PATCH v3 02/12] net-lwip: build lwIP
On Thu, 6 Jun 2024 at 16:36, Jerome Forissier
wrote:
>
> Build the lwIP library when NET_LWIP is enabled. The following files
> are adaptation layers written specially for U-Boot:
>
> lib/lwip/u-boot/arch/cc.h
> lib/lwip/u-boot/arch/sys_arch.h (empty)
> lib/lwip/u-boot/limits.h (empty)
> lib/lwip/u-boot/lwipopts.h
>
> They were initially contributed by Maxim in a previous RFC patch series.
>
> Signed-off-by: Jerome Forissier
> Co-developed-by: Maxim Uvarov
> Cc: Maxim Uvarov
> ---
> lib/Makefile| 2 +
> lib/lwip/Makefile | 57 +
> lib/lwip/u-boot/arch/cc.h | 43 +++
> lib/lwip/u-boot/arch/sys_arch.h | 0
> lib/lwip/u-boot/limits.h| 0
> lib/lwip/u-boot/lwipopts.h | 197
> 6 files changed, 299 insertions(+)
> create mode 100644 lib/lwip/Makefile
> create mode 100644 lib/lwip/u-boot/arch/cc.h
> create mode 100644 lib/lwip/u-boot/arch/sys_arch.h
> create mode 100644 lib/lwip/u-boot/limits.h
> create mode 100644 lib/lwip/u-boot/lwipopts.h
>
> diff --git a/lib/Makefile b/lib/Makefile
> index 2a76acf100d..c35786a0576 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -94,6 +94,8 @@ obj-$(CONFIG_LIBAVB) += libavb/
> obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += libfdt/
> obj-$(CONFIG_$(SPL_TPL_)OF_REAL) += fdtdec_common.o fdtdec.o
>
> +obj-$(CONFIG_NET_LWIP) += lwip/
> +
> ifdef CONFIG_SPL_BUILD
> obj-$(CONFIG_SPL_YMODEM_SUPPORT) += crc16-ccitt.o
> obj-$(CONFIG_$(SPL_TPL_)HASH) += crc16-ccitt.o
> diff --git a/lib/lwip/Makefile b/lib/lwip/Makefile
> new file mode 100644
> index 000..158e59b91fc
> --- /dev/null
> +++ b/lib/lwip/Makefile
> @@ -0,0 +1,57 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Copyright (C) 2024 Linaro Ltd.
> +
> +ccflags-y += -I$(srctree)/lib/lwip/lwip/src/include
> -I$(srctree)/lib/lwip/u-boot
> +
> +obj-y += \
> + lwip/src/api/api_lib.o \
> + lwip/src/api/api_msg.o \
> + lwip/src/api/err.o \
> + lwip/src/api/if_api.o \
> + lwip/src/api/netbuf.o \
> + lwip/src/api/netdb.o \
> + lwip/src/api/netifapi.o \
> + lwip/src/api/sockets.o \
> + lwip/src/api/tcpip.o \
> + lwip/src/apps/http/http_client.o \
> + lwip/src/apps/tftp/tftp.o \
> + lwip/src/core/altcp_alloc.o \
> + lwip/src/core/altcp.o \
> + lwip/src/core/altcp_tcp.o \
> + lwip/src/core/def.o \
> + lwip/src/core/dns.o \
> + lwip/src/core/inet_chksum.o \
> + lwip/src/core/init.o \
> + lwip/src/core/ip.o \
> + lwip/src/core/ipv4/acd.o \
> + lwip/src/core/ipv4/autoip.o \
> + lwip/src/core/ipv4/dhcp.o \
> + lwip/src/core/ipv4/etharp.o \
> + lwip/src/core/ipv4/icmp.o \
> + lwip/src/core/ipv4/igmp.o \
> + lwip/src/core/ipv4/ip4_addr.o \
> + lwip/src/core/ipv4/ip4.o \
> + lwip/src/core/ipv4/ip4_frag.o \
> + lwip/src/core/ipv6/dhcp6.o \
> + lwip/src/core/ipv6/ethip6.o \
> + lwip/src/core/ipv6/icmp6.o \
> + lwip/src/core/ipv6/inet6.o \
> + lwip/src/core/ipv6/ip6_addr.o \
> + lwip/src/core/ipv6/ip6.o \
> + lwip/src/core/ipv6/ip6_frag.o \
> + lwip/src/core/ipv6/mld6.o \
> + lwip/src/core/ipv6/nd6.o \
> + lwip/src/core/mem.o \
> + lwip/src/core/memp.o \
> + lwip/src/core/netif.o \
> + lwip/src/core/pbuf.o \
> + lwip/src/core/raw.o \
> + lwip/src/core/stats.o \
> + lwip/src/core/sys.o \
> + lwip/src/core/tcp.o \
> + lwip/src/core/tcp_in.o \
> + lwip/src/core/tcp_out.o \
> + lwip/src/core/timeouts.o \
> + lwip/src/core/udp.o \
> + lwip/src/netif/ethernet.o
> diff --git a/lib/lwip/u-boot/arch/cc.h b/lib/lwip/u-boot/arch/cc.h
> new file mode 100644
> index 000..31c036dc0c5
> --- /dev/null
> +++ b/lib/lwip/u-boot/arch/cc.h
> @@ -0,0 +1,43 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/* Copyright (C) 2023 Linaro Ltd. */
> +
> +#ifndef LWIP_ARCH_CC_H
> +#define LWIP_ARCH_CC_H
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#define LWIP_ERRNO_INCLUDE
> +
> +#define LWIP_ERRNO_STDINCLUDE 1
> +#define LWIP_NO_UNISTD_H 1
> +#define LWIP_TIMEVAL_PRIVATE 1
> +
> +#ifdef CONFIG_LIB_RAND
> +#define LWIP_RAND() ((u32_t)rand())
> +#endif
> +
> +/* different handling for unit test, normally not needed */
> +#ifdef LWIP_NOASSERT_ON_ERROR
> +#define LWIP_ERROR(message, expression, handler) do { if (!(expression)) { \
> + handler; }} while (0)
> +#endif
> +
> +#define LWIP_DONT_PROVIDE_BYTEORDER_FUNCTIONS
> +
> +#define LWIP_PLATFORM_ASSERT(x) do {printf("Assertion \"%s\" failed at line
> %d in %s\n", \
> + x, __LINE__, __FILE__); } while (0)
> +
> +#define atoi(str) (int)dectoul(str, NULL)
> +#define lwip_strnstr(a, b) strnstr(a, b)
> +
> +#define LWIP_ERR_T int
> +#define LWIP_CONST_CAST(target_type, val)
Re: [PATCH v3 06/12] net-lwip: add dns command
> @@ -7,6 +7,7 @@ obj-$(CONFIG_$(SPL_)DM_ETH) += ../net/eth_common.o
> obj-$(CONFIG_$(SPL_)DM_ETH) += ../net/eth-uclass.o
> obj-$(CONFIG_$(SPL_)DM_ETH) += net-lwip.o
> obj-$(CONFIG_CMD_DHCP) += dhcp.o
> +obj-$(CONFIG_CMD_DNS) += dns.o
> obj-$(CONFIG_CMD_PING) += ping.o
> obj-$(CONFIG_CMD_TFTPBOOT) += tftp.o
>
> diff --git a/net-lwip/dns.c b/net-lwip/dns.c
> new file mode 100644
> index 000..24a5149343a
> --- /dev/null
> +++ b/net-lwip/dns.c
> @@ -0,0 +1,107 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/* Copyright (C) 2024 Linaro Ltd. */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DNS_RESEND_MS 1000
> +#define DNS_TIMEOUT_MS 1
> +
> +static ulong start;
> +static ip_addr_t host_ipaddr;
> +static bool done;
> +
> +static void do_dns_tmr(void *arg)
> +{
> + dns_tmr();
> +}
> +
> +static void dns_cb(const char *name, const ip_addr_t *ipaddr, void *arg)
> +{
> + const char *var = arg;
> + char *ipstr = ip4addr_ntoa(ipaddr);
> +
> + done = true;
> +
> + if (!ipaddr) {
> + printf("DNS: host not found\n");
> + host_ipaddr.addr = 0;
> + return;
> + }
> +
> + if (var)
> + env_set(var, ipstr);
Do we need this? Won't this set == ipaddr?
If we do not need it repurpose the void *arg and get rid of the global 'done'
> +
> + printf("%s\n", ipstr);
> +}
> +
> +int do_dns(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
> +{
> + bool has_server = false;
> + ip_addr_t ipaddr;
> + ip_addr_t ns;
> + char *nsenv;
> + char *name;
> + char *var;
> + int ret;
[...]
Thanks
/Ilias
Re: [PATCH 9/9] Revert "arm: am335x: Enable SPL_OF_CONTROL on some configs"
On Thu, Jun 06, 2024 at 09:04:17AM -0600, Simon Glass wrote: > Hi Tom, > > On Wed, 5 Jun 2024 at 14:15, Tom Rini wrote: > > > > On Wed, Jun 05, 2024 at 02:08:54PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Wed, 5 Jun 2024 at 08:42, Tom Rini wrote: > > > > > > > > On Tue, Jun 04, 2024 at 09:25:21PM -0600, Simon Glass wrote: > > > > > > > > > This is a partial revert which makes boneblack_vboot boot again. > > > > > > > > > > This reverts commit f4b64e9736e73ceec14d51600bed9a8ac48f9fe8. > > > > > > > > > > Signed-off-by: Simon Glass > > > > > --- > > > > > > > > > > configs/am335x_boneblack_vboot_defconfig | 1 - > > > > > 1 file changed, 1 deletion(-) > > > > > > > > > > diff --git a/configs/am335x_boneblack_vboot_defconfig > > > > > b/configs/am335x_boneblack_vboot_defconfig > > > > > index d473a1a793b..3ec4abddd77 100644 > > > > > --- a/configs/am335x_boneblack_vboot_defconfig > > > > > +++ b/configs/am335x_boneblack_vboot_defconfig > > > > > @@ -40,7 +40,6 @@ CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2 > > > > > # CONFIG_CMD_SETEXPR is not set > > > > > CONFIG_BOOTP_DNS2=y > > > > > CONFIG_OF_CONTROL=y > > > > > -CONFIG_SPL_OF_CONTROL=y > > > > > CONFIG_ENV_OVERWRITE=y > > > > > CONFIG_ENV_IS_IN_MMC=y > > > > > CONFIG_SYS_REDUNDAND_ENVIRONMENT=y > > > > > > > > So, this change was a while ago. But I did it because some of the > > > > drivers, tho I forget which ones exactly, really were not functional > > > > without SPL_OF_CONTROL enabled. That said, does am335x_evm_defconfig > > > > work in your configuration? I think we have to keep am335x_evm_spiboot > > > > because it's so radically different from how the rest of the possible > > > > options boot, but I'm not sure we need a vboot defconfig? Or if we do, > > > > it should be updated to use the #include logic these days. > > > > > > I don't actually have an am335x_evm board, which is why I'm using bbb. > > > We only have the vboot version, since the non-vboot was removed a > > > while back. > > > > > > In any case, with this patch, bbb boots again. > > > > Yes, the am335x_evm build supports all of the TI (or associated, like > > beagleboard) platforms. Please give it a try. > > Yes, that works. So what should we do with the boneblack config? We > really should have something that boots. We should delete it and make sure the vboot docs are still up to date / correct. -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 07/12] net-lwip: add wget command
Hi Jerome,
Can we split this in 2 patches instead?
A preparatory one, with split the net-common etc and one that adds wget?
Thanks
/Ilias
On Thu, 6 Jun 2024 at 16:37, Jerome Forissier
wrote:
>
> Add support for the wget command with NET_LWIP.
>
> About the small change in cmd/efidebug.c: when the wget command based
> on the lwIP stack is used the wget command has a built-in URL
> validation function since it needs to parse it anyways (in parse_url()).
> Therefore wget_validate_uri() doesn't exist. So, guard the call in
> efidebug.c with CONFIG_CMD_WGET.
>
> Based on code initially developed by Maxim U.
>
> Signed-off-by: Jerome Forissier
> Co-developed-by: Maxim Uvarov
> Cc: Maxim Uvarov
> ---
> cmd/Kconfig| 7 ++
> cmd/Makefile | 5 +-
> cmd/efidebug.c | 8 +-
> cmd/net-common.c | 115 +
> cmd/net-lwip.c | 12 +++
> cmd/net.c | 115 -
> include/net-lwip.h | 51 +
> net-lwip/Makefile | 1 +
> net-lwip/wget.c| 180 +
> 9 files changed, 375 insertions(+), 119 deletions(-)
> create mode 100644 cmd/net-common.c
> create mode 100644 net-lwip/wget.c
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 6ef0b52cd34..d9a86540be6 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -2117,6 +2117,13 @@ config CMD_TFTPBOOT
> help
> tftpboot - load file via network using TFTP protocol
>
> +config CMD_WGET
> + bool "wget"
> + select PROT_TCP_LWIP
> + help
> + wget is a simple command to download kernel, or other files,
> + from a http server over TCP.
> +
> endif
>
> endif
> diff --git a/cmd/Makefile b/cmd/Makefile
> index 535b6838ca5..e90f2f68211 100644
> --- a/cmd/Makefile
> +++ b/cmd/Makefile
> @@ -129,8 +129,11 @@ obj-$(CONFIG_CMD_MUX) += mux.o
> obj-$(CONFIG_CMD_NAND) += nand.o
> obj-$(CONFIG_CMD_NET) += net.o
> obj-$(CONFIG_CMD_NET_LWIP) += net-lwip.o
> +obj-$(filter y,$(CONFIG_CMD_NET) $(CONFIG_CMD_NET_LWIP)) += net-common.o
> ifdef CONFIG_CMD_NET_LWIP
> -CFLAGS_net-lwip.o := -I$(srctree)/lib/lwip/lwip/src/include
> -I$(srctree)/lib/lwip/u-boot
> +lwip-includes := -I$(srctree)/lib/lwip/lwip/src/include
> -I$(srctree)/lib/lwip/u-boot
> +CFLAGS_net-lwip.o := $(lwip-includes)
> +CFLAGS_net-common.o := $(lwip-includes)
> endif
> obj-$(CONFIG_ENV_SUPPORT) += nvedit.o
> obj-$(CONFIG_CMD_NVEDIT_EFI) += nvedit_efi.o
> diff --git a/cmd/efidebug.c b/cmd/efidebug.c
> index c2c525f2351..d80e91ecadd 100644
> --- a/cmd/efidebug.c
> +++ b/cmd/efidebug.c
> @@ -741,9 +741,11 @@ static int efi_boot_add_uri(int argc, char *const
> argv[], u16 *var_name16,
> if (!label)
> return CMD_RET_FAILURE;
>
> - if (!wget_validate_uri(argv[3])) {
> - printf("ERROR: invalid URI\n");
> - return CMD_RET_FAILURE;
> + if (IS_ENABLED(CONFIG_CMD_WGET)) {
> + if (!wget_validate_uri(argv[3])) {
> + printf("ERROR: invalid URI\n");
> + return CMD_RET_FAILURE;
> + }
> }
>
> efi_create_indexed_name(var_name16, var_name16_size, "Boot", id);
> diff --git a/cmd/net-common.c b/cmd/net-common.c
> new file mode 100644
> index 000..f01d9e63998
> --- /dev/null
> +++ b/cmd/net-common.c
> @@ -0,0 +1,115 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2000
> + * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
> + */
> +
> +#include
> +#include
> +#include
> +#ifdef CONFIG_NET
> +#include
> +#elif defined CONFIG_NET_LWIP
> +#include
> +#else
> +#error Either NET or NET_LWIP must be enabled
> +#endif
> +#include
> +#include
> +
> +static int do_net_list(struct cmd_tbl *cmdtp, int flag, int argc, char
> *const argv[])
> +{
> + const struct udevice *current = eth_get_dev();
> + unsigned char env_enetaddr[ARP_HLEN];
> + const struct udevice *dev;
> + struct uclass *uc;
> +
> + uclass_id_foreach_dev(UCLASS_ETH, dev, uc) {
> + eth_env_get_enetaddr_by_index("eth", dev_seq(dev),
> env_enetaddr);
> + printf("eth%d : %s %pM %s\n", dev_seq(dev), dev->name,
> env_enetaddr,
> + current == dev ? "active" : "");
> + }
> + return CMD_RET_SUCCESS;
> +}
> +
> +static int do_net_stats(struct cmd_tbl *cmdtp, int flag, int argc, char
> *const argv[])
> +{
> + int nstats, err, i, off;
> + struct udevice *dev;
> + u64 *values;
> + u8 *strings;
> +
> + if (argc < 2)
> + return CMD_RET_USAGE;
> +
> + err = uclass_get_device_by_name(UCLASS_ETH, argv[1], );
> + if (err) {
> + printf("Could not find device %s\n", argv[1]);
> + return CMD_RET_FAILURE;
> + }
> +
> + if (!eth_get_ops(dev)->get_sset_count ||
> + !eth_get_ops(dev)->get_strings ||
> +
Re: [RFC PATCH] drivers: bootcount: Add support for FAT filesystem
Hi Vasileios, On 6/5/24 8:10 PM, Vasileios Amoiridis wrote: [You don't often get email from vassilisa...@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] From: Vasileios Amoiridis Add support to save boot count variable in a file in a FAT filesystem. Signed-off-by: Vasileios Amoiridis --- doc/README.bootcount | 12 drivers/bootcount/Kconfig | 49 +++ drivers/bootcount/Makefile| 2 +- drivers/bootcount/bootcount_ext.c | 18 4 files changed, 56 insertions(+), 25 deletions(-) diff --git a/doc/README.bootcount b/doc/README.bootcount index f6c5f82f98..cce66d4d70 100644 --- a/doc/README.bootcount +++ b/doc/README.bootcount @@ -23,15 +23,17 @@ It is the responsibility of some application code (typically a Linux application) to reset the variable "bootcount" to 0 when the system booted successfully, thus allowing for more boot cycles. -CONFIG_BOOTCOUNT_EXT +CONFIG_BOOTCOUNT_FS -This adds support for maintaining boot count in a file on an EXT filesystem. +This adds support for maintaining boot count in a file on a filesystem. +Supported filesystems are FAT and EXT. + The file to use is defined by: -CONFIG_SYS_BOOTCOUNT_EXT_INTERFACE -CONFIG_SYS_BOOTCOUNT_EXT_DEVPART -CONFIG_SYS_BOOTCOUNT_EXT_NAME +CONFIG_SYS_BOOTCOUNT_FS_INTERFACE +CONFIG_SYS_BOOTCOUNT_FS_DEVPART +CONFIG_SYS_BOOTCOUNT_FS_NAME The format of the file is: diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig index 3c56253b1e..a39a7556bb 100644 --- a/drivers/bootcount/Kconfig +++ b/drivers/bootcount/Kconfig @@ -25,10 +25,9 @@ config BOOTCOUNT_GENERIC Set to the address where the bootcount and bootcount magic will be stored. -config BOOTCOUNT_EXT - bool "Boot counter on EXT filesystem" - depends on FS_EXT4 - select EXT4_WRITE +config BOOTCOUNT_FS + bool "Boot counter on filesystem" + depends on FS_EXT4 || FS_FAT help Add support for maintaining boot count in a file on an EXT filesystem. @@ -177,6 +176,30 @@ config BOOTCOUNT_BOOTLIMIT counter being cleared. If set to 0, do not set a boot limit in the environment. +if BOOTCOUNT_FS +choice + prompt "Filesystem type" + default BOOTCOUNT_EXT + +config BOOTCOUNT_EXT + bool "Boot counter on EXT filesystem" + depends on FS_EXT4 + select EXT4_WRITE + help + Add support for maintaining boot count in a file on an EXT + filesystem. + +config BOOTCOUNT_FAT + bool "Boot counter on FAT filesystem" + depends on FS_FAT + select FAT_WRITE + help + Add support for maintaining boot count in a file on a FAT + filesystem. + +endchoice +endif + config SYS_BOOTCOUNT_SINGLEWORD bool "Use single word to pack boot count and magic value" depends on BOOTCOUNT_GENERIC @@ -184,26 +207,26 @@ config SYS_BOOTCOUNT_SINGLEWORD This option enables packing boot count magic value and boot count into single word (32 bits). -config SYS_BOOTCOUNT_EXT_INTERFACE +config SYS_BOOTCOUNT_FS_INTERFACE string "Interface on which to find boot counter EXT filesystem" default "mmc" - depends on BOOTCOUNT_EXT + depends on BOOTCOUNT_FS help Set the interface to use when locating the filesystem to use for the boot counter. -config SYS_BOOTCOUNT_EXT_DEVPART +config SYS_BOOTCOUNT_FS_DEVPART string "Partition of the boot counter EXT filesystem" default "0:1" - depends on BOOTCOUNT_EXT + depends on BOOTCOUNT_FS help Set the partition to use when locating the filesystem to use for the boot counter. -config SYS_BOOTCOUNT_EXT_NAME +config SYS_BOOTCOUNT_FS_NAME string "Path and filename of the EXT filesystem based boot counter" default "/boot/failures" - depends on BOOTCOUNT_EXT + depends on BOOTCOUNT_FS help Set the filename and path of the file used to store the boot counter. @@ -211,18 +234,18 @@ config SYS_BOOTCOUNT_ADDR hex "RAM address used for reading and writing the boot counter" default 0x44E3E000 if BOOTCOUNT_AM33XX || BOOTCOUNT_AM33XX_NVMEM default 0xE0115FF8 if ARCH_LS1043A || ARCH_LS1021A - depends on BOOTCOUNT_AM33XX || BOOTCOUNT_GENERIC || BOOTCOUNT_EXT || \ + depends on BOOTCOUNT_AM33XX || BOOTCOUNT_GENERIC || BOOTCOUNT_FS || \ BOOTCOUNT_AM33XX_NVMEM help Set the address used for reading and writing the boot counter. config SYS_BOOTCOUNT_MAGIC hex "Magic value for the boot counter" - default 0xB001C041 if BOOTCOUNT_GENERIC || BOOTCOUNT_EXT || \ + default 0xB001C041 if BOOTCOUNT_GENERIC || BOOTCOUNT_FS || \
Re: [PATCH 3/9] rockchip: veyron: Add logging for power init
Hi Simon,
On 6/6/24 5:04 PM, Simon Glass wrote:
HI Quentin,
On Wed, 5 Jun 2024 at 02:36, Quentin Schulz wrote:
Hi Simon,
On 6/5/24 5:25 AM, Simon Glass wrote:
Add better logging for power init so that CONFIG_LOG_ERROR_RETURN can
be enabled.
Signed-off-by: Simon Glass
---
board/google/veyron/veyron.c | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/board/google/veyron/veyron.c b/board/google/veyron/veyron.c
index 32dbcdc4d10..23fe8bf088c 100644
--- a/board/google/veyron/veyron.c
+++ b/board/google/veyron/veyron.c
@@ -29,44 +29,41 @@ static int veyron_init(void)
int ret;
ret = regulator_get_by_platname("vdd_arm", );
- if (ret) {
- debug("Cannot set regulator name\n");
- return ret;
- }
+ if (ret)
+ return log_msg_ret("vdd", ret);
Those log messages aren't for code in SPL as far as I could tell, is
there any reason to make them that small/cryptic?
Oh yes, it happens early in U-Boot proper before any messages which is
probably what confused me.
Re size, they just need to support searching the code base. Long
strings mean that many boards fail to boot / hit their limits when
CONFIG_LOG_ERROR_RETURN is enabled. So I try to keep them to 3
characters.
git grep vcc/vdd is going to return a lot of matches :)
This is for one board, so there isn't much reason to argue about this,
so fine :)
/* Slowly raise to max CPU voltage to prevent overshoot */
ret = regulator_set_value(dev, 120);
if (ret)
- return ret;
+ return log_msg_ret("s12", ret);
udelay(175); /* Must wait for voltage to stabilize, 2mV/us */
ret = regulator_set_value(dev, 140);
if (ret)
- return ret;
+ return log_msg_ret("s14", ret);
udelay(100); /* Must wait for voltage to stabilize, 2mV/us */
ret = rockchip_get_clk();
if (ret)
- return ret;
+ return log_msg_ret("clk", ret);
clk.id = PLL_APLL;
ret = clk_set_rate(, 18);
if (IS_ERR_VALUE(ret))
- return ret;
+ return log_msg_ret("s18", ret);
ret = regulator_get_by_platname("vcc33_sd", );
if (ret) {
debug("Cannot get regulator name\n");
- return ret;
+ if (ret)
+ return log_msg_ret("vcc", ret);
I think you can just merge the debug and log_msg_ret here?
They are actually different. The debug message is how I actually found
this problem.
I meant:
"""
if (ret) {
debug("Cannot get regulator name\n");
if (ret)
return log_msg_ret("vcc", ret);
}
"""
Nothing changes ret before the third line, so at the very least we could
have:
"""
if (ret) {
debug("Cannot get regulator name\n");
return log_msg_ret("vcc", ret);
}
"""
But i was also suggesting we merge this into:
"""
if (ret)
return log_msg_ret("Cannot get vcc regulator name", ret);
"""
But since you seem to want to keep only a few characters, then just
removing the debug entirely? Or what's the plan with it? (I see
log_msg_ret as a debug message, but I'm probably wrong here?).
Cheers,
Quentin
Re: Needs a check in the device tree
Hi Jianqiang, On Wed, 5 Jun 2024 at 07:40, jianqiang wang wrote: > > Dear Das U-Boot developers, > > I found that the u-boot device tree implementation lacks a check for the > off_dt_struct field in the device tree. > > In file scripts\dtc\libfdt\libfdt_internal.h, fdt_offset_ptr_ returns the > dt struct address. It calculates the address by adding the header address, > fdt offset, and a specified offset. However, the fdt offset is read from > the device tree and lacks a proper check. The returned pointer can even > point to any address, leading to arbitrary read or write. > > Could you please confirm it is a vulnerability? Doesn't fdt_check_header() help here? Where are you calling the code from? Regards, Simon
Re: [PATCH 3/9] rockchip: veyron: Add logging for power init
HI Quentin,
On Wed, 5 Jun 2024 at 02:36, Quentin Schulz wrote:
>
> Hi Simon,
>
> On 6/5/24 5:25 AM, Simon Glass wrote:
> > Add better logging for power init so that CONFIG_LOG_ERROR_RETURN can
> > be enabled.
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > board/google/veyron/veyron.c | 27 ---
> > 1 file changed, 12 insertions(+), 15 deletions(-)
> >
> > diff --git a/board/google/veyron/veyron.c b/board/google/veyron/veyron.c
> > index 32dbcdc4d10..23fe8bf088c 100644
> > --- a/board/google/veyron/veyron.c
> > +++ b/board/google/veyron/veyron.c
> > @@ -29,44 +29,41 @@ static int veyron_init(void)
> > int ret;
> >
> > ret = regulator_get_by_platname("vdd_arm", );
> > - if (ret) {
> > - debug("Cannot set regulator name\n");
> > - return ret;
> > - }
> > + if (ret)
> > + return log_msg_ret("vdd", ret);
> >
>
> Those log messages aren't for code in SPL as far as I could tell, is
> there any reason to make them that small/cryptic?
Oh yes, it happens early in U-Boot proper before any messages which is
probably what confused me.
Re size, they just need to support searching the code base. Long
strings mean that many boards fail to boot / hit their limits when
CONFIG_LOG_ERROR_RETURN is enabled. So I try to keep them to 3
characters.
>
> > /* Slowly raise to max CPU voltage to prevent overshoot */
> > ret = regulator_set_value(dev, 120);
> > if (ret)
> > - return ret;
> > + return log_msg_ret("s12", ret);
> > udelay(175); /* Must wait for voltage to stabilize, 2mV/us */
> > ret = regulator_set_value(dev, 140);
> > if (ret)
> > - return ret;
> > + return log_msg_ret("s14", ret);
> > udelay(100); /* Must wait for voltage to stabilize, 2mV/us */
> >
> > ret = rockchip_get_clk();
> > if (ret)
> > - return ret;
> > + return log_msg_ret("clk", ret);
> > clk.id = PLL_APLL;
> > ret = clk_set_rate(, 18);
> > if (IS_ERR_VALUE(ret))
> > - return ret;
> > + return log_msg_ret("s18", ret);
> >
> > ret = regulator_get_by_platname("vcc33_sd", );
> > if (ret) {
> > debug("Cannot get regulator name\n");
> > - return ret;
> > + if (ret)
> > + return log_msg_ret("vcc", ret);
>
> I think you can just merge the debug and log_msg_ret here?
They are actually different. The debug message is how I actually found
this problem.
>
> Otherwise looking good to me,
>
> Cheers,
> Quentin
Regards,
Simon
Re: [PATCH 9/9] Revert "arm: am335x: Enable SPL_OF_CONTROL on some configs"
Hi Tom, On Wed, 5 Jun 2024 at 14:15, Tom Rini wrote: > > On Wed, Jun 05, 2024 at 02:08:54PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Wed, 5 Jun 2024 at 08:42, Tom Rini wrote: > > > > > > On Tue, Jun 04, 2024 at 09:25:21PM -0600, Simon Glass wrote: > > > > > > > This is a partial revert which makes boneblack_vboot boot again. > > > > > > > > This reverts commit f4b64e9736e73ceec14d51600bed9a8ac48f9fe8. > > > > > > > > Signed-off-by: Simon Glass > > > > --- > > > > > > > > configs/am335x_boneblack_vboot_defconfig | 1 - > > > > 1 file changed, 1 deletion(-) > > > > > > > > diff --git a/configs/am335x_boneblack_vboot_defconfig > > > > b/configs/am335x_boneblack_vboot_defconfig > > > > index d473a1a793b..3ec4abddd77 100644 > > > > --- a/configs/am335x_boneblack_vboot_defconfig > > > > +++ b/configs/am335x_boneblack_vboot_defconfig > > > > @@ -40,7 +40,6 @@ CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2 > > > > # CONFIG_CMD_SETEXPR is not set > > > > CONFIG_BOOTP_DNS2=y > > > > CONFIG_OF_CONTROL=y > > > > -CONFIG_SPL_OF_CONTROL=y > > > > CONFIG_ENV_OVERWRITE=y > > > > CONFIG_ENV_IS_IN_MMC=y > > > > CONFIG_SYS_REDUNDAND_ENVIRONMENT=y > > > > > > So, this change was a while ago. But I did it because some of the > > > drivers, tho I forget which ones exactly, really were not functional > > > without SPL_OF_CONTROL enabled. That said, does am335x_evm_defconfig > > > work in your configuration? I think we have to keep am335x_evm_spiboot > > > because it's so radically different from how the rest of the possible > > > options boot, but I'm not sure we need a vboot defconfig? Or if we do, > > > it should be updated to use the #include logic these days. > > > > I don't actually have an am335x_evm board, which is why I'm using bbb. > > We only have the vboot version, since the non-vboot was removed a > > while back. > > > > In any case, with this patch, bbb boots again. > > Yes, the am335x_evm build supports all of the TI (or associated, like > beagleboard) platforms. Please give it a try. Yes, that works. So what should we do with the boneblack config? We really should have something that boots. Regards, Simon
Re: [PATCH 3/3] regulator: rk8xx: clarify operator precedence
On Wed, 5 Jun 2024 at 03:33, Quentin Schulz wrote: > > From: Quentin Schulz > > My linter complains that the order isn't clear enough so let's put > parentheses around the ternary condition to make it happy. > > Signed-off-by: Quentin Schulz > --- > drivers/power/regulator/rk8xx.c | 26 +- > 1 file changed, 13 insertions(+), 13 deletions(-) > Reviewed-by: Simon Glass Tested-by: Simon Glass # chromebook-bob
Re: [PATCH 2/3] regulator: rk8xx: pass pmic udevice instead of regulator to all internal functions
On Wed, 5 Jun 2024 at 03:33, Quentin Schulz wrote: > > From: Quentin Schulz > > For the sake of consistency, make all internal (starting with _) > functions expect a pmic udevice instead of a regulator udevice. > > Signed-off-by: Quentin Schulz > --- > drivers/power/regulator/rk8xx.c | 20 ++-- > 1 file changed, 10 insertions(+), 10 deletions(-) Reviewed-by: Simon Glass Tested-by: Simon Glass # chromebook-bob
Re: [PATCH 7/9] rockchip: bob: kevin: Disable dcache in SPL
Hi Jonas, On Wed, 5 Jun 2024 at 05:07, Jonas Karlman wrote: > > Hi Simon, > > On 2024-06-05 05:25, Simon Glass wrote: > > This causes a hang, so disable it. > > When I initially tested this on multiple boards there was some boards > that also hanged, that turned out to be an issue in one of the drivers. > > If I remember correctly such hang was related to a null pointer > dereference or unaligned access in one of the drivers. > > Could there be a similar underlying issue for these boards? Yes it could be. I will take a look. But given the release date I would like to get this patch in first. Regards, Simon
Re: [PATCH 1/3] regulator: rk8xx: fix incorrect device used for _ldo_[sg]et_suspend_value
On Wed, 5 Jun 2024 at 03:33, Quentin Schulz wrote:
>
> From: Quentin Schulz
>
> _ldo_get_suspend_value and _ldo_set_suspend_value get passed the parent
> of the regulator (so the pmic) as first argument, therefore this udevice
> should be used for pmic_* callbacks instead of using the parent of the
> pmic.
>
> To avoid further confusion, let's rename the argument to pmic instead of
> dev, highlighting which kind of device we expect as argument.
>
> Fixes: f047e4ab9762 ("regulator: rk8xx: add indirection level for some ldo
> callbacks")
> Reported-by: Simon Glass
> Signed-off-by: Quentin Schulz
> ---
> drivers/power/regulator/rk8xx.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
Reviewed-by: Simon Glass
Tested-by: Simon Glass # chromebook-bob
Re: [PATCH 0/2] Cleanup fit documentation
Hi Simon, On 6/5/24 5:52 PM, Simon Glass wrote: Hi Sam, On Tue, 4 Jun 2024 at 20:13, Simon Glass wrote: Hi Sam, On Tue, 4 Jun 2024 at 13:53, Sam Povilus wrote: Sam Povilus (2): doc: Remove extraneous curly braces doc: add clarity to what a "fpga" image is doc/usage/fit/source_file_format.rst | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) This is now at [1]. Could you please instead do a PR for that? I am not sure yet the best way to incorporate or link the FIT spec from the U-Boot documentation. I suppose we could employ a script to sync it? One can reference links from another Sphinx project thanks to intersphinx_mapping, c.f. https://git.yoctoproject.org/yocto-docs/tree/documentation/conf.py#n114 and https://git.yoctoproject.org/yocto-docs/tree/documentation/migration-guides/release-notes-5.0.rst#n196. It requires the objects.inv file to be available, which seems to be the case. Hope this helps, Cheers, Quentin
Re: [PATCH] board: rockchip: Add FriendlyElec NanoPi R6C
Hi Sebastian,
On 6/5/24 5:36 PM, Sebastian Kropatsch wrote:
[You don't often get email from seb-...@mail.de. Learn why this is important at
https://aka.ms/LearnAboutSenderIdentification ]
The NanoPi R6C is a SBC by FriendlyElec based on the Rockchip RK3588s.
It comes with 4GB or 8GB of RAM, a microSD card slot, optional 32GB eMMC
storage, one M.2 M-Key connector, one RTL8211F 1GbE and one RTL8125
2.5GbE Ethernet port, one USB 2.0 Type-A and one USB 3.0 Type-A port, a
HDMI port, a 30-pin GPIO header as well as multiple buttons and LEDs.
Add initial support for this board using the upstream devicetree sources.
Tests in U-Boot proper:
- Booting from eMMC works
- 1GbE Ethernet works using the eth_eqos driver (tested by ping)
- 2.5GbE Ethernet works using the eth_rtl8169 driver (tested by ping),
but the status LEDs on this specific port currently aren't working
- NVMe SSD in M.2 socket does get recognized (tested with `nvme scan`
followed by `nvme details`)
Kernel commit:
d5f1d7437451 ("arm64: dts: rockchip: Add support for NanoPi R6C")
Signed-off-by: Sebastian Kropatsch
---
Hello!
The Ethernet status LEDs which sit directly on the 2.5GbE port using the
RTL8169 driver don't light up when connected and I couldn't figure out
why. The other port with a RTL8211F has no problems with the LEDs.
Have there been occurrences like this in combination with the RTL8125?
I'm trying to figure out if this is something that could be solved in
the devicetree or if this is a potential driver bug.
Secondly, the default active network device in U-Boot is the 1GbE one.
I believe it would make sense to make the 2.5GbE device the default
active one since this one is labeled "LAN", whereas the 1GbE is labeled
"WAN". However, since the 2.5GbE device is PCIe-based, it only shows up
in U-Boot proper after using the `pci enum` command (shows up as in gets
listed in `net list` and `dm tree`).
Do you have any tips on the preferred approach to handle this switch of
the default active net device? Is this even a sensible thing to include
in U-Boot in your opinion?
Thanks for your feedback!
Best regards,
Sebastian
---
arch/arm/dts/rk3588s-nanopi-r6c-u-boot.dtsi | 3 +
arch/arm/mach-rockchip/rk3588/Kconfig | 13 +++
board/friendlyelec/nanopi-r6c-rk3588s/Kconfig | 12 +++
.../nanopi-r6c-rk3588s/MAINTAINERS| 7 ++
configs/nanopi-r6c-rk3588s_defconfig | 83 +++
doc/board/rockchip/rockchip.rst | 1 +
include/configs/nanopi-r6c-rk3588s.h | 12 +++
7 files changed, 131 insertions(+)
create mode 100644 arch/arm/dts/rk3588s-nanopi-r6c-u-boot.dtsi
create mode 100644 board/friendlyelec/nanopi-r6c-rk3588s/Kconfig
create mode 100644 board/friendlyelec/nanopi-r6c-rk3588s/MAINTAINERS
create mode 100644 configs/nanopi-r6c-rk3588s_defconfig
create mode 100644 include/configs/nanopi-r6c-rk3588s.h
diff --git a/arch/arm/dts/rk3588s-nanopi-r6c-u-boot.dtsi
b/arch/arm/dts/rk3588s-nanopi-r6c-u-boot.dtsi
new file mode 100644
index 00..853ed58cfe
--- /dev/null
+++ b/arch/arm/dts/rk3588s-nanopi-r6c-u-boot.dtsi
@@ -0,0 +1,3 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk3588s-u-boot.dtsi"
diff --git a/arch/arm/mach-rockchip/rk3588/Kconfig
b/arch/arm/mach-rockchip/rk3588/Kconfig
index 820e979abb..0e232ddfb9 100644
--- a/arch/arm/mach-rockchip/rk3588/Kconfig
+++ b/arch/arm/mach-rockchip/rk3588/Kconfig
@@ -78,6 +78,18 @@ config TARGET_NANOPCT6_RK3588
Power: 5.5*2.1mm DC Jack, 12VDC input
Dimensions: 110x80x1.6mm (without case) / 86x114.5x30mm (with case)
+config TARGET_NANOPI_R6C_RK3588
Please add the S at the end of the symbol.
Otherwise looking good to me. I'm wondering if we shouldn't do something
for boards which do not need a -u-boot.dtsi. Here it's needed because
U-Boot would include rk3588-u-boot.dtsi automatically (because of
CONFIG_SYS_SOC being rk3588) instead of rk3588s-u-boot.dtsi. Maybe it's
too much headache for the benefit :)
Cheers,
Quentin
Re: [PATCH v2 1/1] xilinx: zynqmp: Enable reset_cpu() in SPL
On 6/4/24 15:59, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
This commit enables SPL to reset the CPU via PMU-firmware. The usual
reset mechanism requires bl31 to be loaded which may not be the case in
SPL.
Signed-off-by: Lukas Funke
---
Changes in v2:
- Drop 2/2 since reworking ZYNQMP_FIRMWARE dependency is out-of-scope
board/xilinx/zynqmp/zynqmp.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index f370fb7347a..a129b1dbbbc 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include "../common/board.h"
#include "pm_cfg_obj.h"
@@ -285,6 +286,14 @@ int dram_init(void)
#if !CONFIG_IS_ENABLED(SYSRESET)
void reset_cpu(void)
{
+ if (!IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE)) {
+ log_warning("reset failed: ZYNQMP_FIRMWARE disabled");
+ return;
+ }
+
+ xilinx_pm_request(PM_RESET_ASSERT,
+ ZYNQMP_PM_RESET_START + ZYNQMP_RESET_SOFT,
Isn't it easier to use ZYNQMP_PM_RESET_SOFT directly?
Also you can remove that include above to dt binding.
The rest looks good. If you want to make nicer I would put there a comment that
in case of !CONFIG_ZYNQMP_FIRMWARE xilinx_pm_request is not present compiler
removes it because of return inside if. If defined in SPL case xilinx_pm_request
will send command over IPI.
Thanks,
Michal
Re: [PATCH] ARM: stm32: Ping IWDG on exit from PSCI suspend code
On 4/20/24 00:03, Marek Vasut wrote:
> Make sure the OS would not get any spurious IWDG pretimeout IRQ
> right after the system wakes up. This may happen in case the SoC
> got woken up by another source than the IWDG pretimeout and the
> pretimeout IRQ arrived immediately afterward, but too late to be
> handled by the suspend main loop. In case either of the IWDG is
> enabled, ping it first and then return to the OS.
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Igor Opaniuk
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: Simon Glass
> Cc: Tom Rini
> Cc: u-b...@dh-electronics.com
> Cc: uboot-st...@st-md-mailman.stormreply.com
> ---
> arch/arm/mach-stm32mp/stm32mp1/psci.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm/mach-stm32mp/stm32mp1/psci.c
> b/arch/arm/mach-stm32mp/stm32mp1/psci.c
> index 4f2379df45f..e99103910d9 100644
> --- a/arch/arm/mach-stm32mp/stm32mp1/psci.c
> +++ b/arch/arm/mach-stm32mp/stm32mp1/psci.c
> @@ -808,6 +808,27 @@ void __secure psci_system_suspend(u32 __always_unused
> function_id,
> writel(SYSCFG_CMPENR_MPUEN, STM32_SYSCFG_BASE + SYSCFG_CMPENSETR);
> clrbits_le32(STM32_SYSCFG_BASE + SYSCFG_CMPCR, SYSCFG_CMPCR_SW_CTRL);
>
> + /*
> + * Make sure the OS would not get any spurious IWDG pretimeout IRQ
> + * right after the system wakes up. This may happen in case the SoC
> + * got woken up by another source than the IWDG pretimeout and the
> + * pretimeout IRQ arrived immediately afterward, but too late to be
> + * handled by the main loop above. In case either of the IWDG is
> + * enabled, ping it first and then return to the OS.
> + */
> +
> + /* Ping IWDG1 and ACK pretimer IRQ */
> + if (gic_enabled[4] & BIT(22)) {
> + writel(IWDG_KR_RELOAD_KEY, STM32_IWDG1_BASE + IWDG_KR);
> + writel(IWDG_EWCR_EWIC, STM32_IWDG1_BASE + IWDG_EWCR);
> + }
> +
> + /* Ping IWDG2 and ACK pretimer IRQ */
> + if (gic_enabled[4] & BIT(23)) {
> + writel(IWDG_KR_RELOAD_KEY, STM32_IWDG2_BASE + IWDG_KR);
> + writel(IWDG_EWCR_EWIC, STM32_IWDG2_BASE + IWDG_EWCR);
> + }
> +
> /*
>* The system has resumed successfully. Rewrite LR register stored
>* on stack with 'ep' value, so that on return from this PSCI call,
Reviewed-by: Patrice Chotard
Thanks
Patrice
[PATCH] gpio: Add proper dependency on ZYNQMP_FIRMWARE
ZYNQMP_FIRMWARE can be disabled and driver depends on it that's why record this dependency via Kconfig. Signed-off-by: Michal Simek --- drivers/gpio/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index b050585389bb..93c5125fed9b 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -639,7 +639,7 @@ config NOMADIK_GPIO config ZYNQMP_GPIO_MODEPIN bool "ZynqMP gpio modepin" - depends on DM_GPIO + depends on DM_GPIO && ZYNQMP_FIRMWARE help This config enables the ZynqMP gpio modepin driver. ZynqMP modepin driver will set and get the status of PS_MODE pins. These modepins -- 2.40.1
Re: [PATCH 5/5] dts: stm32mp157c-odyssey: add phy-reset-gpios property to ethernet node
On 4/28/24 16:24, Heesub Shin wrote:
> In Odyssey board, we should reset the PHY chipset, toggling G0 pin.
>
> Signed-off-by: Heesub Shin
> ---
> arch/arm/dts/stm32mp157c-odyssey.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/dts/stm32mp157c-odyssey.dts
> b/arch/arm/dts/stm32mp157c-odyssey.dts
> index b6210cf8b2..4cc5e07683 100644
> --- a/arch/arm/dts/stm32mp157c-odyssey.dts
> +++ b/arch/arm/dts/stm32mp157c-odyssey.dts
> @@ -75,6 +75,7 @@
> phy-mode = "rgmii-id";
> max-speed = <1000>;
> phy-handle = <>;
> + phy-reset-gpios = < 0 GPIO_ACTIVE_LOW>;
> st,ext-phyclk;
>
> mdio0 {
Reviewed-by: Patrice Chotard
Thanks
Patrice
Re: [PATCH 4/5] net: dwc_eth_qos: add support for phy-reset-gpios property
On 4/28/24 16:24, Heesub Shin wrote:
> This commit adds support for a property 'phy-reset-gpios' to reset PHY
> chipset.
>
> Signed-off-by: Heesub Shin
> ---
> drivers/net/dwc_eth_qos_stm32.c | 23 ++-
> 1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/dwc_eth_qos_stm32.c b/drivers/net/dwc_eth_qos_stm32.c
> index fbc08bba1d..cffaa10b70 100644
> --- a/drivers/net/dwc_eth_qos_stm32.c
> +++ b/drivers/net/dwc_eth_qos_stm32.c
> @@ -266,6 +266,12 @@ static int eqos_probe_resources_stm32(struct udevice
> *dev)
> if (ret)
> dev_warn(dev, "No phy clock provided %d\n", ret);
>
> + /* Get reset gpio pin (optional) */
> + ret = gpio_request_by_name(dev, "phy-reset-gpios", 0,
> +>phy_reset_gpio, GPIOD_IS_OUT);
> + if (ret)
> + pr_warn("No phy reset gpio provided: %d\n", ret);
> +
> dev_dbg(dev, "%s: OK\n", __func__);
>
> return 0;
> @@ -277,6 +283,21 @@ err_probe:
> return ret;
> }
>
> +static int eqos_start_resets_stm32(struct udevice *dev)
> +{
> + struct eqos_priv *eqos = dev_get_priv(dev);
> +
> + debug("%s(dev=%p):\n", __func__, dev);
> +
> + if (dm_gpio_is_valid(>phy_reset_gpio)) {
> + dm_gpio_set_value(>phy_reset_gpio, 1);
> + udelay(2);
> + dm_gpio_set_value(>phy_reset_gpio, 0);
> + }
> +
> + return 0;
> +}
> +
> static int eqos_remove_resources_stm32(struct udevice *dev)
> {
> dev_dbg(dev, "%s:\n", __func__);
> @@ -292,7 +313,7 @@ static struct eqos_ops eqos_stm32_ops = {
> .eqos_probe_resources = eqos_probe_resources_stm32,
> .eqos_remove_resources = eqos_remove_resources_stm32,
> .eqos_stop_resets = eqos_null_ops,
> - .eqos_start_resets = eqos_null_ops,
> + .eqos_start_resets = eqos_start_resets_stm32,
> .eqos_stop_clks = eqos_stop_clks_stm32,
> .eqos_start_clks = eqos_start_clks_stm32,
> .eqos_calibrate_pads = eqos_null_ops,
Reviewed-by: Patrice Chotard
Thanks
Patrice
Re: [PATCH 3/5] dts: stm32mp157c-odyssey: fix incorrect PHY address
On 4/28/24 16:24, Heesub Shin wrote:
> In Odyssey board, KSZ9031 is at the PHY address 0x7, not 0x0. This
> commit fixes it.
>
> Signed-off-by: Heesub Shin
> ---
> arch/arm/dts/stm32mp157c-odyssey.dts | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/dts/stm32mp157c-odyssey.dts
> b/arch/arm/dts/stm32mp157c-odyssey.dts
> index 53ba018197..b6210cf8b2 100644
> --- a/arch/arm/dts/stm32mp157c-odyssey.dts
> +++ b/arch/arm/dts/stm32mp157c-odyssey.dts
> @@ -81,8 +81,8 @@
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "snps,dwmac-mdio";
> - phy0: ethernet-phy@0 {
> - reg = <0>;
> + phy0: ethernet-phy@7 {
> + reg = <7>;
> };
> };
> };
Reviewed-by: Patrice Chotard
Thanks
Patrice
Re: [PATCH 2/5] dts: stm32mp157c-odyssey: use internal clock for Tx
On 4/28/24 16:24, Heesub Shin wrote:
> In Odyssey board, we should use the internal clock from RCC as the
> transmit clock, instead of the external clock from ETH_CLK125 pad. This
> commit adds a property, st,eth-clk-sel, so that the ETH_CLK_SEL mux
> selects ETH_CLK.
>
> Signed-off-by: Heesub Shin
> ---
> arch/arm/dts/stm32mp157c-odyssey.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/dts/stm32mp157c-odyssey.dts
> b/arch/arm/dts/stm32mp157c-odyssey.dts
> index 17bcf56f74..53ba018197 100644
> --- a/arch/arm/dts/stm32mp157c-odyssey.dts
> +++ b/arch/arm/dts/stm32mp157c-odyssey.dts
> @@ -75,6 +75,7 @@
> phy-mode = "rgmii-id";
> max-speed = <1000>;
> phy-handle = <>;
> + st,ext-phyclk;
>
> mdio0 {
> #address-cells = <1>;
Reviewed-by: Patrice Chotard
Thanks
Patrice
Re: [PATCH 1/5] dts: stm32mp157c-odyssey: set PLL4_P to 125Mhz for ETH_CLK
On 4/28/24 16:24, Heesub Shin wrote:
> Odyssey board requires ETH_CLK of 125Mhz. This commit sets PLL4_P/Q/R to
> 125, 62.5 and 62.5Mhz in respectively.
>
> Signed-off-by: Heesub Shin
> ---
> arch/arm/dts/stm32mp157c-odyssey-som-u-boot.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/dts/stm32mp157c-odyssey-som-u-boot.dtsi
> b/arch/arm/dts/stm32mp157c-odyssey-som-u-boot.dtsi
> index b780dbd95e..d07fdcf4bc 100644
> --- a/arch/arm/dts/stm32mp157c-odyssey-som-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp157c-odyssey-som-u-boot.dtsi
> @@ -115,11 +115,11 @@
> bootph-all;
> };
>
> - /* VCO = 594.0 MHz => P = 99, Q = 74, R = 74 */
> + /* VCO = 750.0 MHz => P = 125, Q = 62.5, R = 62.5 */
> pll4: st,pll@3 {
> compatible = "st,stm32mp1-pll";
> reg = <3>;
> - cfg = < 3 98 5 7 7 PQR(1,1,1) >;
> + cfg = < 3 124 5 9 9 PQR(1,1,1) >;
> bootph-all;
> };
> };
Reviewed-by: Patrice Chotard
Thanks
Patrice
[PATCH] arm64: zynqmp: Align #address/size-cells with node
zynqmp-mini-nand wasn't aligned with dt binding that's why fix it.
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-mini-nand.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/zynqmp-mini-nand.dts
b/arch/arm/dts/zynqmp-mini-nand.dts
index 5889d436edb8..e08a7840d8e1 100644
--- a/arch/arm/dts/zynqmp-mini-nand.dts
+++ b/arch/arm/dts/zynqmp-mini-nand.dts
@@ -46,8 +46,8 @@
status = "okay";
reg = <0x0 0xff10 0x1000>;
clock-names = "clk_sys", "clk_flash";
- #address-cells = <2>;
- #size-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
arasan,has-mdma;
num-cs = <2>;
nand@0 {
--
2.40.1
Re: [PATCH v3 7/7] drivers: misc: Add driver to access ZynqMP efuses
On 6/4/24 16:27, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
Add driver to access ZynqMP efuses. This is a u-boot port of [1].
Note: Accessing eFuses requires eFuse access to be enabled in the
underlying PMU firmware.
[1]
https://lore.kernel.org/all/20240224114516.86365-8-srinivas.kandaga...@linaro.org/
Signed-off-by: Lukas Funke
---
Changes in v3:
- Align ZynqMP eFuse driver with Linux kernel
- Adapt versal, versal-net and zynqmp to use common chip-id function
- Enable CMD_FUSE and ZYNQMP_EFUSE for zynqmp_virt and zynqmp_kria defconfig
- Use 'dev_err' instead 'log_msg_ret' if possible
Changes in v2:
- Drop vendor specific fuse cmd, use existing fuse cmd
- Minor code refactoring (reverse x-mas tree)
drivers/misc/Kconfig| 8 +
drivers/misc/Makefile | 1 +
drivers/misc/zynqmp_efuse.c | 360
3 files changed, 369 insertions(+)
create mode 100644 drivers/misc/zynqmp_efuse.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 6009d55f400..c07f50c9a76 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -298,6 +298,14 @@ config FSL_SEC_MON
Security Monitor can be transitioned on any security failures,
like software violations or hardware security violations.
+config ZYNQMP_EFUSE
+ bool "Enable ZynqMP eFUSE Driver"
+ depends on ZYNQMP_FIRMWARE
+ help
+ Enable access to Zynq UltraScale (ZynqMP) eFUSEs thought PMU firmware
+ interface. ZnyqMP has 256 eFUSEs where some of them are security
related
+ and cannot be read back (i.e. AES key).
+
choice
prompt "Security monitor interaction endianess"
depends on FSL_SEC_MON
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index e53d52c47b3..68ba5648eab 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -92,3 +92,4 @@ obj-$(CONFIG_ESM_K3) += k3_esm.o
obj-$(CONFIG_ESM_PMIC) += esm_pmic.o
obj-$(CONFIG_SL28CPLD) += sl28cpld.o
obj-$(CONFIG_SPL_SOCFPGA_DT_REG) += socfpga_dtreg.o
+obj-$(CONFIG_ZYNQMP_EFUSE) += zynqmp_efuse.o
diff --git a/drivers/misc/zynqmp_efuse.c b/drivers/misc/zynqmp_efuse.c
new file mode 100644
index 000..d12de7494d2
--- /dev/null
+++ b/drivers/misc/zynqmp_efuse.c
@@ -0,0 +1,360 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2014 - 2015 Xilinx, Inc.
+ * Michal Simek
Not sure which version you used as source but please sync up with kernel version
you used. I expect there will be much newer dates because efuse were added
recently.
+ *
+ * (C) Copyright 2024 Weidmueller Interface GmbH
+ * Lukas Funke
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SILICON_REVISION_MASK 0xF
+#define P_USER_0_64_UPPER_MASK GENMASK(31, 16)
+#define P_USER_127_LOWER_4_BIT_MASK GENMASK(3, 0)
+#define WORD_INBYTES 4
+#define SOC_VER_SIZE 0x4
+#define EFUSE_MEMORY_SIZE 0x177
+#define UNUSED_SPACE 0x8
+#define ZYNQMP_NVMEM_SIZE (SOC_VER_SIZE + UNUSED_SPACE + \
+EFUSE_MEMORY_SIZE)
+#define SOC_VERSION_OFFSET 0x0
+#define EFUSE_START_OFFSET 0xC
+#define EFUSE_END_OFFSET 0xFC
+#define EFUSE_PUF_START_OFFSET 0x100
+#define EFUSE_PUF_MID_OFFSET 0x140
+#define EFUSE_PUF_END_OFFSET 0x17F
+#define EFUSE_NOT_ENABLED 29
+
+/*
+ * efuse access type
+ */
+enum efuse_access {
+ EFUSE_READ = 0,
+ EFUSE_WRITE
+};
+
+/**
+ * struct xilinx_efuse - the basic structure
+ * @src: address of the buffer to store the data to be write/read
+ * @size: read/write word count
+ * @offset:read/write offset
+ * @flag: 0 - represents efuse read and 1- represents efuse write
+ * @pufuserfuse:0 - represents non-puf efuses, offset is used for read/write
+ * 1 - represents puf user fuse row number.
+ *
+ * this structure stores all the required details to
+ * read/write efuse memory.
+ */
+struct xilinx_efuse {
+ u64 src;
+ u32 size;
+ u32 offset;
+ enum efuse_access flag;
+ u32 pufuserfuse;
+};
+
+/**
+ * struct efuse_map_entry - offset and length of zynqmp fuses
+ * @offset:offset of efuse to be read/write
+ * @length:length of efuse
+ */
+struct efuse_map_entry {
+ u32 offset;
+ u32 length;
+};
+
+struct efuse_map_entry zynqmp_efuse_table[] = {
+ {0x000, 0x04}, /* soc revision */
+ {0x00c, 0x0c}, /* SoC DNA */
+ {0x020, 0x04}, /* efuse-usr0 */
+ {0x024, 0x04}, /* efuse-usr1 */
+ {0x028, 0x04}, /* efuse-usr2 */
+ {0x02c, 0x04}, /* efuse-usr3 */
+ {0x030, 0x04}, /* efuse-usr4 */
+ {0x034, 0x04}, /* efuse-usr5 */
+ {0x038, 0x04}, /* efuse-usr6 */
+ {0x03c, 0x04}, /* efuse-usr7 */
+ {0x040, 0x04}, /* efuse-miscusr */
+ {0x050, 0x04}, /* efuse-chash */
+ {0x054, 0x04}, /* efuse-pufmisc */
+ {0x058, 0x04}, /* efuse-sec */
+ {0x05c,
Re: [PATCH v2 00/14] Introduce the lwIP network stack
On Thu, Jun 06, 2024 at 11:15:54AM +0200, Jerome Forissier wrote: > > > On 5/27/24 17:34, Tom Rini wrote: > > On Fri, May 24, 2024 at 06:19:54PM +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. (CC'd) > >> has 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. directly from the U-Boot shell. > >> - Possibly benefit from additional features implemented in lwIP > >> - Less code to maintain in U-Boot > >> > >> The first patch introduces a new Kconfig symbol: NET_LWIP, which selects > >> the lwIP implementation instead of the current one (NET). Contrary to the > >> approach chosen by Maxim in [1], NET_LWIP and NET cannot be enabled > >> simultaneously. The rationale is we want to start from a clean state and > >> not pull potentially duplicated functionality from both stacks. Note > >> however that a few files are still built in net/, they are the ones > >> related to ethernet device management and the ethernet bootflow. > >> > >> The second patch imports the lwIP code as a Git subtree under > >> lib/lwip/lwip. Some glue code is added under lib/lwip/u-boot. > > > > For next time, please just make it a pre-req to run the git subtree > > command (and note it in the cover letter). > > > > In more specific feedback, I tried this on a Pi 3, and: > > U-Boot> tftpboot 20 EFI/arm64/helloworld.efi > > TFTP from server 192.168.1.10; our IP address is 192.168.1.100 > > Filename 'EFI/arm64/helloworld.efi'. > > Load address: 0x20 > > Loading: > > > > FAILED test/py/tests/test_efi_loader.py::test_efi_helloworld_net - > > u_boot_spawn.Timeout > > > > So some amount of networking is working (that's a reasonable dhcp > > response it got), but tftp'ing a file fails. > > Thanks for testing! This fails because I changed the command output. The > legacy command prints "Bytes transferred =" while the newer one prints > "%lu bytes transferred" plus throughput information. I will use the older > message in v3 because several tests as well as documentation would need > updating. We'll do that later if desired. Thanks. And yeah, I would like to keep the output unchanged as much as is feasible, it's in many ways a form of ABI. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/2] ARM: dts: stm32: Add pinmux nodes for DH electronics STM32MP13xx DHCOR SoM and DHSBC board
On 4/28/24 00:20, Marek Vasut wrote:
> Add new pinmux nodes for DH electronics STM32MP13xx DHCOR SoM and DHSBC board.
> The following pinmux nodes are added:
> - ADC pins
> - ADC CC pins
> - ETH1 pins
> - ETH2 pins
> - I2C5 pins
> - MCAN1 pins
> - MCAN2 pins
> - PWM13 pins
> - PWM5 pins
> - QSPI pins
> - SAI1 pins
> - SDMMC2 D4..D7 pins
> - SPI2 pins
> - SPI3 pins
> - UART4 pins
> - UART7 pins
> - USART1 pins
> - USART2 pins
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: u-b...@dh-electronics.com
> Cc: uboot-st...@st-md-mailman.stormreply.com
> ---
> V2: Squash the pinmux patches into one megapatch
> ---
> arch/arm/dts/stm32mp13-pinctrl.dtsi | 483
> 1 file changed, 483 insertions(+)
>
> diff --git a/arch/arm/dts/stm32mp13-pinctrl.dtsi
> b/arch/arm/dts/stm32mp13-pinctrl.dtsi
> index 27e0c382678..c01d39f03ea 100644
> --- a/arch/arm/dts/stm32mp13-pinctrl.dtsi
> +++ b/arch/arm/dts/stm32mp13-pinctrl.dtsi
> @@ -6,6 +6,12 @@
> #include
>
> {
> + adc1_pins_a: adc1-pins-0 {
> + pins {
> + pinmux = ; /* ADC1 in12 */
> + };
> + };
> +
> adc1_usb_cc_pins_a: adc1-usb-cc-pins-0 {
> pins {
> pinmux = , /* ADC1 in6 */
> @@ -13,6 +19,104 @@
> };
> };
>
> + adc1_usb_cc_pins_b: adc1-usb-cc-pins-1 {
> + pins {
> + pinmux = , /* ADC1_INP2 */
> + ; /* ADC1_INP11
> */
> + };
> + };
> +
> + eth1_rgmii_pins_a: eth1-rgmii-0 {
> + pins1 {
> + pinmux = , /*
> ETH_RGMII_TXD0 */
> + , /*
> ETH_RGMII_TXD1 */
> + , /*
> ETH_RGMII_TXD2 */
> + , /*
> ETH_RGMII_TXD3 */
> + , /*
> ETH_RGMII_TX_CTL */
> + , /*
> ETH_RGMII_GTX_CLK */
> + , /* ETH_MDIO */
> + ; /* ETH_MDC */
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <2>;
> + };
> +
> + pins2 {
> + pinmux = , /*
> ETH_RGMII_RXD0 */
> + , /*
> ETH_RGMII_RXD1 */
> + , /*
> ETH_RGMII_RXD2 */
> + , /*
> ETH_RGMII_RXD3 */
> + , /*
> ETH_RGMII_RX_CTL */
> + ; /*
> ETH_RGMII_RX_CLK */
> + bias-disable;
> + };
> +
> + };
> +
> + eth1_rgmii_sleep_pins_a: eth1-rgmii-sleep-0 {
> + pins1 {
> + pinmux = , /*
> ETH_RGMII_TXD0 */
> + , /*
> ETH_RGMII_TXD1 */
> + , /*
> ETH_RGMII_TXD2 */
> + , /*
> ETH_RGMII_TXD3 */
> + , /*
> ETH_RGMII_TX_CTL */
> + , /*
> ETH_RGMII_GTX_CLK */
> + , /* ETH_MDIO */
> + , /* ETH_MDC */
> + , /*
> ETH_RGMII_RXD0 */
> + , /*
> ETH_RGMII_RXD1 */
> + , /*
> ETH_RGMII_RXD1 */
> + , /*
> ETH_RGMII_RXD1 */
> + , /*
> ETH_RGMII_RX_CTL */
> + ; /*
> ETH_RGMII_RX_CLK */
> + };
> + };
> +
> + eth2_rgmii_pins_a: eth2-rgmii-0 {
> + pins1 {
> + pinmux = , /*
> ETH_RGMII_TXD0 */
> + , /*
> ETH_RGMII_TXD1 */
> + , /*
> ETH_RGMII_TXD2 */
> + , /*
> ETH_RGMII_TXD3 */
> + , /*
> ETH_RGMII_TX_CTL */
> + , /*
> ETH_RGMII_GTX_CLK */
> + , /* ETH_MDIO */
> + ; /* ETH_MDC */
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <2>;
> + };
> +
> + pins2 {
> + pinmux = , /*
> ETH_RGMII_RXD0 */
> + , /*
> ETH_RGMII_RXD1 */
> + , /*
> ETH_RGMII_RXD2 */
> + , /*
> ETH_RGMII_RXD3 */
> + , /*
> ETH_RGMII_RX_CTL */
> + ; /*
> ETH_RGMII_RX_CLK */
> + bias-disable;
> + };
> + };
> +
> + eth2_rgmii_sleep_pins_a: eth2-rgmii-sleep-0 {
> + pins1 {
> + pinmux = , /*
> ETH_RGMII_TXD0 */
> + , /*
> ETH_RGMII_TXD1 */
> + , /*
> ETH_RGMII_TXD2 */
Re: [PATCH v5] cmd: move ELF load and boot to lib/elf.c
On Thu, Jun 06, 2024 at 09:02:43AM +0200, Heinrich Schuchardt wrote: > On 6/5/24 20:43, Maxim Moskalets wrote: > > From: Maxim Moskalets > > > > Loading and running the ELF image is the responsibility of the > > library and should not be associated with the command line interface. > > > > It is also required to run ELF images from FIT with the bootm command > > so as not to depend on the command line interface. > > > > Signed-off-by: Maxim Moskalets > > In future versions please, include a change log separated from the > commit message by ---, e.g. > > --- > v6: > foo changed to bar > v5: > xxx removed > --- > > Best regards > > Heinrich Do you have any other feedback, Heinrich? -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 5/7] soc: xilinx: zynqmp: Use zynqmp_pm_get_chipid() to get chip revision
On 6/4/24 16:27, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
Use common zynqmp_pm_get_chipid() function to get the chip revision
Signed-off-by: Lukas Funke
---
(no changes since v1)
drivers/soc/soc_xilinx_zynqmp.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/soc/soc_xilinx_zynqmp.c b/drivers/soc/soc_xilinx_zynqmp.c
index d8b4f172a39..8a65810b7d7 100644
--- a/drivers/soc/soc_xilinx_zynqmp.c
+++ b/drivers/soc/soc_xilinx_zynqmp.c
@@ -346,22 +346,21 @@ static const struct soc_ops soc_xilinx_zynqmp_ops = {
static int soc_xilinx_zynqmp_probe(struct udevice *dev)
{
struct soc_xilinx_zynqmp_priv *priv = dev_get_priv(dev);
- u32 ret_payload[PAYLOAD_ARG_CNT];
+ u32 idcode, version;
int ret;
priv->family = zynqmp_family;
- if (!IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE))
- ret = zynqmp_mmio_read(ZYNQMP_PS_VERSION, _payload[2]);
+ if (!CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE))
+ ret = zynqmp_mmio_read(ZYNQMP_PS_VERSION, );
else
- ret = xilinx_pm_request(PM_GET_CHIPID, 0, 0, 0, 0,
- ret_payload);
+ ret = zynqmp_pm_get_chipid(, );
if (ret < 0)
return ret;
- priv->revision = ret_payload[2] & ZYNQMP_PS_VER_MASK;
+ priv->revision = version & ZYNQMP_PS_VER_MASK;
- if (IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE)) {
+ if (CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)) {
/*
* Firmware returns:
* payload[0][31:0] = status of the operation
@@ -370,11 +369,9 @@ static int soc_xilinx_zynqmp_probe(struct udevice *dev)
* payload[2][28:20] = EXTENDED_IDCODE
* payload[2][29] = PL_INIT
*/
- u32 idcode = ret_payload[1];
- u32 idcode2 = ret_payload[2] >>
- ZYNQMP_CSU_VERSION_EMPTY_SHIFT;
- dev_dbg(dev, "IDCODE: 0x%0x, IDCODE2: 0x%0x\n", idcode,
- idcode2);
+ u32 idcode2 = version >> ZYNQMP_CSU_VERSION_EMPTY_SHIFT;
+
+ dev_dbg(dev, "IDCODE: 0x%0x, IDCODE2: 0x%0x\n", idcode,
idcode2);
ret = soc_xilinx_zynqmp_detect_machine(dev, idcode, idcode2);
if (ret)
Looks good.
Reviewed-by: Michal Simek
Thanks,
Michal
Re: [PATCH v3 4/7] soc: xilinx: versal-net: Use zynqmp_pm_get_chipid() to get chip revision
On 6/4/24 16:27, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
Use common zynqmp_pm_get_chipid() function to get the chip revision
Signed-off-by: Lukas Funke
---
(no changes since v1)
drivers/soc/soc_xilinx_versal_net.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/soc/soc_xilinx_versal_net.c
b/drivers/soc/soc_xilinx_versal_net.c
index 146d068bb4a..76467a3bbb5 100644
--- a/drivers/soc/soc_xilinx_versal_net.c
+++ b/drivers/soc/soc_xilinx_versal_net.c
@@ -47,23 +47,22 @@ static const struct soc_ops soc_xilinx_versal_net_ops = {
static int soc_xilinx_versal_net_probe(struct udevice *dev)
{
struct soc_xilinx_versal_net_priv *priv = dev_get_priv(dev);
- u32 ret_payload[PAYLOAD_ARG_CNT];
+ u32 idcode, version;
int ret;
priv->family = versal_family;
- if (IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE)) {
- ret = xilinx_pm_request(PM_GET_CHIPID, 0, 0, 0, 0,
- ret_payload);
+ if (CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)) {
+ ret = zynqmp_pm_get_chipid(, );
if (ret)
return ret;
} else {
- ret_payload[2] = readl(PMC_TAP_VERSION);
- if (!ret_payload[2])
+ version = readl(PMC_TAP_VERSION);
+ if (!version)
return -EINVAL;
}
- priv->revision = FIELD_GET(PS_VERSION_MASK, ret_payload[2]);
+ priv->revision = FIELD_GET(PS_VERSION_MASK, version);
return 0;
}
Reviewed-by: Michal Simek
Thanks,
Michal
Re: [PATCH v3 6/7] firmware: zynqmp: Add support to access efuses
On 6/4/24 16:27, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
Add functions to access efuses through PMU firmware
interface.
Signed-off-by: Lukas Funke
---
(no changes since v1)
drivers/firmware/firmware-zynqmp.c | 31 ++
include/zynqmp_firmware.h | 2 ++
2 files changed, 33 insertions(+)
diff --git a/drivers/firmware/firmware-zynqmp.c
b/drivers/firmware/firmware-zynqmp.c
index dfad798a2e7..8e9687693dd 100644
--- a/drivers/firmware/firmware-zynqmp.c
+++ b/drivers/firmware/firmware-zynqmp.c
@@ -211,6 +211,37 @@ int zynqmp_pm_feature(const u32 api_id)
return ret_payload[1] & FIRMWARE_VERSION_MASK;
}
+int zynqmp_pm_get_chipid(u32 *idcode, u32 *version)
+{
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+ int ret;
+
+ if (!idcode || !version)
+ return -EINVAL;
+
+ ret = xilinx_pm_request(PM_GET_CHIPID, 0, 0, 0, 0, ret_payload);
+ *idcode = ret_payload[1];
+ *version = ret_payload[2];
+
+ return ret;
+}
+
+int zynqmp_pm_efuse_access(const u64 address, u32 *out)
+{
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+ int ret;
+
+ if (!out)
+ return -EINVAL;
+
+ ret = xilinx_pm_request(PM_EFUSE_ACCESS, upper_32_bits(address),
+ lower_32_bits(address), 0, 0, ret_payload);
+
+ *out = ret_payload[1];
+
+ return ret;
+}
+
int zynqmp_pm_is_function_supported(const u32 api_id, const u32 id)
{
int ret;
diff --git a/include/zynqmp_firmware.h b/include/zynqmp_firmware.h
index 73198a6a6ea..7f18b4d59bf 100644
--- a/include/zynqmp_firmware.h
+++ b/include/zynqmp_firmware.h
@@ -453,6 +453,8 @@ int xilinx_pm_request(u32 api_id, u32 arg0, u32 arg1, u32
arg2,
int zynqmp_pm_set_sd_config(u32 node, enum pm_sd_config_type config, u32
value);
int zynqmp_pm_set_gem_config(u32 node, enum pm_gem_config_type config,
u32 value);
+int zynqmp_pm_get_chipid(u32 *idcode, u32 *version);
+int zynqmp_pm_efuse_access(const u64 address, u32 *out);
int zynqmp_pm_is_function_supported(const u32 api_id, const u32 id);
int zynqmp_mmio_read(const u32 address, u32 *value);
int zynqmp_mmio_write(const u32 address, const u32 mask, const u32 value);
Reviewed-by: Michal Simek
Thanks,
Michal
Re: [PATCH v3 3/7] soc: xilinx: versal: Use zynqmp_pm_get_chipid() to get chip revision
On 6/4/24 16:27, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
Use common zynqmp_pm_get_chipid() function to get the chip revision
Signed-off-by: Lukas Funke
---
(no changes since v1)
drivers/soc/soc_xilinx_versal.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/soc/soc_xilinx_versal.c b/drivers/soc/soc_xilinx_versal.c
index 3d8c25c19bb..3d949c4e612 100644
--- a/drivers/soc/soc_xilinx_versal.c
+++ b/drivers/soc/soc_xilinx_versal.c
@@ -45,23 +45,22 @@ static const struct soc_ops soc_xilinx_versal_ops = {
static int soc_xilinx_versal_probe(struct udevice *dev)
{
struct soc_xilinx_versal_priv *priv = dev_get_priv(dev);
- u32 ret_payload[PAYLOAD_ARG_CNT];
+ u32 idcode, version;
int ret;
priv->family = versal_family;
- if (IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE)) {
- ret = xilinx_pm_request(PM_GET_CHIPID, 0, 0, 0, 0,
- ret_payload);
+ if (CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)) {
+ ret = zynqmp_pm_get_chipid(, );
This function is defined in 6/7 that's why this will fail when it compiles which
end up in non bisectable tree.
if (ret)
return ret;
} else {
- ret_payload[2] = readl(VERSAL_PS_PMC_VERSION);
- if (!ret_payload[2])
+ version = readl(VERSAL_PS_PMC_VERSION);
+ if (!version)
return -EINVAL;
}
- priv->revision = ret_payload[2] >> VERSAL_PS_VER_SHIFT;
+ priv->revision = version >> VERSAL_PS_VER_SHIFT;
return 0;
}
But code is ok.
M
Re: [PATCH v3 2/7] configs: zynqmp_virt: Enable CMD_FUSE and ZYNQMP_EFUSE
On 6/4/24 16:27, lukas.funke-...@weidmueller.com wrote: From: Lukas Funke Enable CMD_FUSE and ZYNQMP_EFUSE in order to be able to write ZyqnMP eFuses from within the bootloader. Signed-off-by: Lukas Funke --- (no changes since v1) configs/xilinx_zynqmp_kria_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/xilinx_zynqmp_kria_defconfig b/configs/xilinx_zynqmp_kria_defconfig index ba42f0c7848..ac91dccbe64 100644 --- a/configs/xilinx_zynqmp_kria_defconfig +++ b/configs/xilinx_zynqmp_kria_defconfig @@ -65,6 +65,7 @@ CONFIG_CMD_DFU=y CONFIG_CMD_FPGA_LOADBP=y CONFIG_CMD_FPGA_LOADP=y CONFIG_CMD_FPGA_LOAD_SECURE=y +CONFIG_CMD_FUSE=y CONFIG_CMD_GPIO=y CONFIG_CMD_PWM=y CONFIG_CMD_GPT=y @@ -147,6 +148,7 @@ CONFIG_I2C_MUX_PCA954x=y CONFIG_LED=y CONFIG_LED_GPIO=y CONFIG_MISC=y +CONFIG_ZYNQMP_EFUSE=y CONFIG_I2C_EEPROM=y CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_MMC_IO_VOLTAGE=y Feel free to merge it with Kria. No need for two patches. M
Re: [PATCH v3 1/7] configs: zynqmp_kria: Enable CMD_FUSE and ZYNQMP_EFUSE
On 6/4/24 16:27, lukas.funke-...@weidmueller.com wrote: From: Lukas Funke Enable CMD_FUSE and ZYNQMP_EFUSE in order to be able to write ZyqnMP eFuses from within the bootloader for Kria SoM. Signed-off-by: Lukas Funke --- (no changes since v1) configs/xilinx_zynqmp_virt_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/xilinx_zynqmp_virt_defconfig b/configs/xilinx_zynqmp_virt_defconfig index ee87beb19c6..1edd4ac77b1 100644 --- a/configs/xilinx_zynqmp_virt_defconfig +++ b/configs/xilinx_zynqmp_virt_defconfig @@ -65,6 +65,7 @@ CONFIG_CMD_DFU=y CONFIG_CMD_FPGA_LOADBP=y CONFIG_CMD_FPGA_LOADP=y CONFIG_CMD_FPGA_LOAD_SECURE=y +CONFIG_CMD_FUSE=y CONFIG_CMD_GPIO=y CONFIG_CMD_PWM=y CONFIG_CMD_GPT=y @@ -147,6 +148,7 @@ CONFIG_I2C_MUX_PCA954x=y CONFIG_LED=y CONFIG_LED_GPIO=y CONFIG_MISC=y +CONFIG_ZYNQMP_EFUSE=y CONFIG_I2C_EEPROM=y CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_MMC_IO_VOLTAGE=y The patch itself is fine but it should be after symbol is defined. It means Kconfig change first and then enable it. M
[PATCH v3 12/12] CI: add qemu_arm64_lwip to the test matrix
Build and run qemu_arm64_lwip_defconfig in CI. This tests the lightweight
IP (lwIP) implementation of the dhcp, tftpboot and ping commands.
Signed-off-by: Jerome Forissier
---
.azure-pipelines.yml | 7 +++
1 file changed, 7 insertions(+)
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index 27f69583c65..4da1bb12fab 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -199,6 +199,10 @@ stages:
cd \${WORK_DIR}
git config --global --add safe.directory \${WORK_DIR}
git clone --depth=1 https://source.denx.de/u-boot/u-boot-test-hooks
/tmp/uboot-test-hooks
+ # qemu_arm64_lwip_defconfig is the same as qemu_arm64 but with
NET_LWIP enabled.
+ # The test config and the boardenv file from qemu_arm64 can be
re-used so create symlinks
+ ln -s conf.qemu_arm64_na
/tmp/uboot-test-hooks/bin/travis-ci/conf.qemu_arm64_lwip_na
+ ln -s u_boot_boardenv_qemu_arm64_na.py
/tmp/uboot-test-hooks/py/travis-ci/u_boot_boardenv_qemu_arm64_lwip_na.py
ln -s travis-ci /tmp/uboot-test-hooks/bin/\`hostname\`
ln -s travis-ci /tmp/uboot-test-hooks/py/\`hostname\`
grub-mkimage --prefix=\"\" -o ~/grub_x86.efi -O i386-efi normal echo
lsefimmap lsefi lsefisystab efinet tftp minicmd
@@ -371,6 +375,9 @@ stages:
qemu_arm64:
TEST_PY_BD: "qemu_arm64"
TEST_PY_TEST_SPEC: "not sleep"
+qemu_arm64_lwip:
+ TEST_PY_BD: "qemu_arm64_lwip"
+ TEST_PY_TEST_SPEC: "test_net_dhcp or test_net_ping or
test_net_tftpboot"
qemu_m68k:
TEST_PY_BD: "M5208EVBE"
TEST_PY_ID: "--id qemu"
--
2.40.1
[PATCH v3 11/12] MAINTAINERS: net-lwip: add myself as a maintainer
Add myself as a maintainer for the lwIP network stack integration code and network commands. The library code itself (i.e., most files under lib/lwip/ except README, Makefile and integration files in u-boot) is unmodified from upstream and therefore does not need a maintainer. Signed-off-by: Jerome Forissier Reviewed-by: Ilias Apalodimas --- MAINTAINERS | 11 +++ 1 file changed, 11 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index f8afd7d51e2..11105869304 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1310,6 +1310,17 @@ F: drivers/net/ F: include/net.h F: net/ +NETWORK (LWIP) +M: Jerome Forissier +S: Maintained +F: cmd/net-lwip.c +F: configs/qemu_arm64_lwip_defconfig +F: include/net-lwip.h +F: lib/lwip/Makefile +F: lib/lwip/README +F: lib/lwip/u-boot/ +F: net-lwip/ + NIOS M: Thomas Chou S: Maintained -- 2.40.1
[PATCH v3 10/12] configs: add qemu_arm64_lwip_defconfig
Add qemu_arm64_lwip_defconfig based on qemu_arm64_defconfig but with NET_LWIP instead of NET. Signed-off-by: Jerome Forissier --- configs/qemu_arm64_lwip_defconfig | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 configs/qemu_arm64_lwip_defconfig diff --git a/configs/qemu_arm64_lwip_defconfig b/configs/qemu_arm64_lwip_defconfig new file mode 100644 index 000..050c93ff97b --- /dev/null +++ b/configs/qemu_arm64_lwip_defconfig @@ -0,0 +1,3 @@ +#include +CONFIG_NET_LWIP=y +# CONFIG_DFU_TFTP is not set -- 2.40.1
[PATCH v3 09/12] cmd: bdinfo: enable -e when CONFIG_CMD_NET_LWIP=y
Support "bdinfo -e" when lwIP is selected.
Signed-off-by: Jerome Forissier
Reviewed-by: Ilias Apalodimas
Reviewed-by: Tom Rini
---
cmd/bdinfo.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c
index 79106caeec2..690fb894bf6 100644
--- a/cmd/bdinfo.c
+++ b/cmd/bdinfo.c
@@ -152,7 +152,7 @@ static int bdinfo_print_all(struct bd_info *bd)
bdinfo_print_num_l("relocaddr", gd->relocaddr);
bdinfo_print_num_l("reloc off", gd->reloc_off);
printf("%-12s= %u-bit\n", "Build", (uint)sizeof(void *) * 8);
- if (IS_ENABLED(CONFIG_CMD_NET))
+ if (IS_ENABLED(CONFIG_CMD_NET) || IS_ENABLED(CONFIG_CMD_NET_LWIP))
print_eth();
bdinfo_print_num_l("fdt_blob", (ulong)map_to_sysmem(gd->fdt_blob));
bdinfo_print_num_l("new_fdt", (ulong)map_to_sysmem(gd->new_fdt));
@@ -198,7 +198,8 @@ int do_bdinfo(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
case 'a':
return bdinfo_print_all(bd);
case 'e':
- if (!IS_ENABLED(CONFIG_CMD_NET))
+ if (!IS_ENABLED(CONFIG_CMD_NET) &&
+ !IS_ENABLED(CONFIG_CMD_NET_LWIP))
return CMD_RET_USAGE;
print_eth();
return CMD_RET_SUCCESS;
--
2.40.1
[PATCH v3 08/12] test: dm: dsa, eth: disable tests when CONFIG_NET_LWIP=y
Some sandbox tests make strong assumptions on how the network stack is
implemented. For example, the ping tests assume that ARP resolution
occurs upon sending out the ICMP packet. This is not always the case
with the lwIP stack which can cache ARP information.
Therefore, disable these tests when CONFIG_NET_LWIP is enabled.
Signed-off-by: Jerome Forissier
---
test/dm/dsa.c | 2 ++
test/dm/eth.c | 4
2 files changed, 6 insertions(+)
diff --git a/test/dm/dsa.c b/test/dm/dsa.c
index c857106eaf4..147e2a4afe2 100644
--- a/test/dm/dsa.c
+++ b/test/dm/dsa.c
@@ -59,6 +59,7 @@ static int dm_test_dsa_probe(struct unit_test_state *uts)
DM_TEST(dm_test_dsa_probe, UT_TESTF_SCAN_FDT);
+#if !defined(CONFIG_NET_LWIP)
/* This test sends ping requests with the local address through each DSA port
* via the sandbox DSA master Eth.
*/
@@ -80,3 +81,4 @@ static int dm_test_dsa(struct unit_test_state *uts)
}
DM_TEST(dm_test_dsa, UT_TESTF_SCAN_FDT);
+#endif /* !defined(CONFIG_NET_LWIP) */
diff --git a/test/dm/eth.c b/test/dm/eth.c
index bb3dcc6b954..cf97b1c1ab3 100644
--- a/test/dm/eth.c
+++ b/test/dm/eth.c
@@ -170,6 +170,7 @@ static int dm_test_ip6_make_lladdr(struct unit_test_state
*uts)
DM_TEST(dm_test_ip6_make_lladdr, UT_TESTF_SCAN_FDT);
#endif
+#if !defined(CONFIG_NET_LWIP)
static int dm_test_eth(struct unit_test_state *uts)
{
net_ping_ip = string_to_ip("1.1.2.2");
@@ -298,6 +299,7 @@ static int dm_test_eth_act(struct unit_test_state *uts)
return 0;
}
DM_TEST(dm_test_eth_act, UT_TESTF_SCAN_FDT);
+#endif /* !CONFIG_NET_LWIP */
/* Ensure that all addresses are loaded properly */
static int dm_test_ethaddr(struct unit_test_state *uts)
@@ -332,6 +334,7 @@ static int dm_test_ethaddr(struct unit_test_state *uts)
}
DM_TEST(dm_test_ethaddr, UT_TESTF_SCAN_FDT);
+#if !defined(CONFIG_NET_LWIP)
/* The asserts include a return on fail; cleanup in the caller */
static int _dm_test_eth_rotate1(struct unit_test_state *uts)
{
@@ -616,6 +619,7 @@ static int dm_test_eth_async_ping_reply(struct
unit_test_state *uts)
}
DM_TEST(dm_test_eth_async_ping_reply, UT_TESTF_SCAN_FDT);
+#endif /* !CONFIG_NET_LWIP */
#if IS_ENABLED(CONFIG_IPV6_ROUTER_DISCOVERY)
--
2.40.1
[PATCH v3 07/12] net-lwip: add wget command
Add support for the wget command with NET_LWIP.
About the small change in cmd/efidebug.c: when the wget command based
on the lwIP stack is used the wget command has a built-in URL
validation function since it needs to parse it anyways (in parse_url()).
Therefore wget_validate_uri() doesn't exist. So, guard the call in
efidebug.c with CONFIG_CMD_WGET.
Based on code initially developed by Maxim U.
Signed-off-by: Jerome Forissier
Co-developed-by: Maxim Uvarov
Cc: Maxim Uvarov
---
cmd/Kconfig| 7 ++
cmd/Makefile | 5 +-
cmd/efidebug.c | 8 +-
cmd/net-common.c | 115 +
cmd/net-lwip.c | 12 +++
cmd/net.c | 115 -
include/net-lwip.h | 51 +
net-lwip/Makefile | 1 +
net-lwip/wget.c| 180 +
9 files changed, 375 insertions(+), 119 deletions(-)
create mode 100644 cmd/net-common.c
create mode 100644 net-lwip/wget.c
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 6ef0b52cd34..d9a86540be6 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -2117,6 +2117,13 @@ config CMD_TFTPBOOT
help
tftpboot - load file via network using TFTP protocol
+config CMD_WGET
+ bool "wget"
+ select PROT_TCP_LWIP
+ help
+ wget is a simple command to download kernel, or other files,
+ from a http server over TCP.
+
endif
endif
diff --git a/cmd/Makefile b/cmd/Makefile
index 535b6838ca5..e90f2f68211 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -129,8 +129,11 @@ obj-$(CONFIG_CMD_MUX) += mux.o
obj-$(CONFIG_CMD_NAND) += nand.o
obj-$(CONFIG_CMD_NET) += net.o
obj-$(CONFIG_CMD_NET_LWIP) += net-lwip.o
+obj-$(filter y,$(CONFIG_CMD_NET) $(CONFIG_CMD_NET_LWIP)) += net-common.o
ifdef CONFIG_CMD_NET_LWIP
-CFLAGS_net-lwip.o := -I$(srctree)/lib/lwip/lwip/src/include
-I$(srctree)/lib/lwip/u-boot
+lwip-includes := -I$(srctree)/lib/lwip/lwip/src/include
-I$(srctree)/lib/lwip/u-boot
+CFLAGS_net-lwip.o := $(lwip-includes)
+CFLAGS_net-common.o := $(lwip-includes)
endif
obj-$(CONFIG_ENV_SUPPORT) += nvedit.o
obj-$(CONFIG_CMD_NVEDIT_EFI) += nvedit_efi.o
diff --git a/cmd/efidebug.c b/cmd/efidebug.c
index c2c525f2351..d80e91ecadd 100644
--- a/cmd/efidebug.c
+++ b/cmd/efidebug.c
@@ -741,9 +741,11 @@ static int efi_boot_add_uri(int argc, char *const argv[],
u16 *var_name16,
if (!label)
return CMD_RET_FAILURE;
- if (!wget_validate_uri(argv[3])) {
- printf("ERROR: invalid URI\n");
- return CMD_RET_FAILURE;
+ if (IS_ENABLED(CONFIG_CMD_WGET)) {
+ if (!wget_validate_uri(argv[3])) {
+ printf("ERROR: invalid URI\n");
+ return CMD_RET_FAILURE;
+ }
}
efi_create_indexed_name(var_name16, var_name16_size, "Boot", id);
diff --git a/cmd/net-common.c b/cmd/net-common.c
new file mode 100644
index 000..f01d9e63998
--- /dev/null
+++ b/cmd/net-common.c
@@ -0,0 +1,115 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2000
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ */
+
+#include
+#include
+#include
+#ifdef CONFIG_NET
+#include
+#elif defined CONFIG_NET_LWIP
+#include
+#else
+#error Either NET or NET_LWIP must be enabled
+#endif
+#include
+#include
+
+static int do_net_list(struct cmd_tbl *cmdtp, int flag, int argc, char *const
argv[])
+{
+ const struct udevice *current = eth_get_dev();
+ unsigned char env_enetaddr[ARP_HLEN];
+ const struct udevice *dev;
+ struct uclass *uc;
+
+ uclass_id_foreach_dev(UCLASS_ETH, dev, uc) {
+ eth_env_get_enetaddr_by_index("eth", dev_seq(dev),
env_enetaddr);
+ printf("eth%d : %s %pM %s\n", dev_seq(dev), dev->name,
env_enetaddr,
+ current == dev ? "active" : "");
+ }
+ return CMD_RET_SUCCESS;
+}
+
+static int do_net_stats(struct cmd_tbl *cmdtp, int flag, int argc, char *const
argv[])
+{
+ int nstats, err, i, off;
+ struct udevice *dev;
+ u64 *values;
+ u8 *strings;
+
+ if (argc < 2)
+ return CMD_RET_USAGE;
+
+ err = uclass_get_device_by_name(UCLASS_ETH, argv[1], );
+ if (err) {
+ printf("Could not find device %s\n", argv[1]);
+ return CMD_RET_FAILURE;
+ }
+
+ if (!eth_get_ops(dev)->get_sset_count ||
+ !eth_get_ops(dev)->get_strings ||
+ !eth_get_ops(dev)->get_stats) {
+ printf("Driver does not implement stats dump!\n");
+ return CMD_RET_FAILURE;
+ }
+
+ nstats = eth_get_ops(dev)->get_sset_count(dev);
+ strings = kcalloc(nstats, ETH_GSTRING_LEN, GFP_KERNEL);
+ if (!strings)
+ return CMD_RET_FAILURE;
+
+ values = kcalloc(nstats, sizeof(u64), GFP_KERNEL);
+ if (!values)
+ goto err_free_strings;
+
+ eth_get_ops(dev)->get_strings(dev,
[PATCH v3 06/12] net-lwip: add dns command
Add CMD_DNS when NET_LWIP is enabled to provide the dns command using
lwIP.
Signed-off-by: Jerome Forissier
---
cmd/Kconfig| 6 +++
cmd/net-lwip.c | 8
include/net-lwip.h | 1 +
net-lwip/Makefile | 1 +
net-lwip/dns.c | 107 +
5 files changed, 123 insertions(+)
create mode 100644 net-lwip/dns.c
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 07cfe824e3f..6ef0b52cd34 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -2098,6 +2098,12 @@ config CMD_DHCP
help
Boot image via network using DHCP/TFTP protocol
+config CMD_DNS
+ bool "dns"
+ select PROT_DNS_LWIP
+ help
+ Lookup the IP of a hostname
+
config CMD_PING
bool "ping"
select PROT_RAW_LWIP
diff --git a/cmd/net-lwip.c b/cmd/net-lwip.c
index 13856703fcf..3abafdf7969 100644
--- a/cmd/net-lwip.c
+++ b/cmd/net-lwip.c
@@ -27,3 +27,11 @@ U_BOOT_CMD(
"[loadAddress] [[hostIPaddr:]bootfilename]"
);
#endif
+
+#if defined(CONFIG_CMD_DNS)
+U_BOOT_CMD(
+ dns,3, 1, do_dns,
+ "lookup the IP of a hostname",
+ "hostname [envvar]"
+);
+#endif
diff --git a/include/net-lwip.h b/include/net-lwip.h
index 2abaaa3b4e3..0019d1524e5 100644
--- a/include/net-lwip.h
+++ b/include/net-lwip.h
@@ -82,6 +82,7 @@ int net_lwip_init(void);
struct netif *net_lwip_get_netif(void);
int do_dhcp(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
+int do_dns(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
int do_ping(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
int do_tftpb(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
diff --git a/net-lwip/Makefile b/net-lwip/Makefile
index e68d4e24197..aa247859483 100644
--- a/net-lwip/Makefile
+++ b/net-lwip/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_$(SPL_)DM_ETH) += ../net/eth_common.o
obj-$(CONFIG_$(SPL_)DM_ETH) += ../net/eth-uclass.o
obj-$(CONFIG_$(SPL_)DM_ETH) += net-lwip.o
obj-$(CONFIG_CMD_DHCP) += dhcp.o
+obj-$(CONFIG_CMD_DNS) += dns.o
obj-$(CONFIG_CMD_PING) += ping.o
obj-$(CONFIG_CMD_TFTPBOOT) += tftp.o
diff --git a/net-lwip/dns.c b/net-lwip/dns.c
new file mode 100644
index 000..24a5149343a
--- /dev/null
+++ b/net-lwip/dns.c
@@ -0,0 +1,107 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Copyright (C) 2024 Linaro Ltd. */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DNS_RESEND_MS 1000
+#define DNS_TIMEOUT_MS 1
+
+static ulong start;
+static ip_addr_t host_ipaddr;
+static bool done;
+
+static void do_dns_tmr(void *arg)
+{
+ dns_tmr();
+}
+
+static void dns_cb(const char *name, const ip_addr_t *ipaddr, void *arg)
+{
+ const char *var = arg;
+ char *ipstr = ip4addr_ntoa(ipaddr);
+
+ done = true;
+
+ if (!ipaddr) {
+ printf("DNS: host not found\n");
+ host_ipaddr.addr = 0;
+ return;
+ }
+
+ if (var)
+ env_set(var, ipstr);
+
+ printf("%s\n", ipstr);
+}
+
+int do_dns(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
+{
+ bool has_server = false;
+ ip_addr_t ipaddr;
+ ip_addr_t ns;
+ char *nsenv;
+ char *name;
+ char *var;
+ int ret;
+
+ if (argc == 1 || argc > 3)
+ return CMD_RET_USAGE;
+
+ if (argc >= 2)
+ name = argv[1];
+
+ if (argc == 3)
+ var = argv[2];
+
+ dns_init();
+
+ nsenv = env_get("dnsip");
+ if (nsenv && ipaddr_aton(nsenv, )) {
+ dns_setserver(0, );
+ has_server = true;
+ }
+
+ nsenv = env_get("dnsip2");
+ if (nsenv && ipaddr_aton(nsenv, )) {
+ dns_setserver(1, );
+ has_server = true;
+ }
+
+ if (!has_server) {
+ log_err("No valid name server (dnsip/dnsip2)\n");
+ return CMD_RET_FAILURE;
+ }
+
+ done = false;
+
+ ret = dns_gethostbyname(name, , dns_cb, var);
+
+ if (ret == ERR_OK) {
+ dns_cb(name, , var);
+ } else if (ret == ERR_INPROGRESS) {
+ start = get_timer(0);
+ sys_timeout(DNS_RESEND_MS, do_dns_tmr, NULL);
+ do {
+ eth_rx();
+ if (done)
+ break;
+ sys_check_timeouts();
+ if (ctrlc()) {
+ printf("\nAbort\n");
+ break;
+ }
+ } while (get_timer(start) < DNS_TIMEOUT_MS);
+ sys_untimeout(do_dns_tmr, NULL);
+ }
+
+ if (done && host_ipaddr.addr != 0)
+ return CMD_RET_SUCCESS;
+
+ return CMD_RET_FAILURE;
+}
+
--
2.40.1
[PATCH v3 05/12] net-lwip: add ping command
Add support for the the ping command with NET_LWIP. The implementation
is derived from lwIP's contrib/apps/ping/ping.c.
Signed-off-by: Jerome Forissier
---
boot/Kconfig | 2 +-
cmd/Kconfig| 6 ++
cmd/net-lwip.c | 8 +++
include/net-lwip.h | 3 +
net-lwip/Makefile | 1 +
net-lwip/ping.c| 163 +
6 files changed, 182 insertions(+), 1 deletion(-)
create mode 100644 net-lwip/ping.c
diff --git a/boot/Kconfig b/boot/Kconfig
index 004e69dd92a..983a284ec52 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -379,7 +379,7 @@ config BOOT_DEFAULTS_CMDS
select CMD_FS_GENERIC
select CMD_PART if PARTITIONS
select CMD_DHCP if CMD_NET || CMD_NET_LWIP
- select CMD_PING if CMD_NET
+ select CMD_PING if CMD_NET || CMD_NET_LWIP
select CMD_PXE if CMD_NET
select CMD_BOOTI if ARM64
select CMD_BOOTZ if ARM && !ARM64
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 94a8de266f6..07cfe824e3f 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -2098,6 +2098,12 @@ config CMD_DHCP
help
Boot image via network using DHCP/TFTP protocol
+config CMD_PING
+ bool "ping"
+ select PROT_RAW_LWIP
+ help
+ Send ICMP ECHO_REQUEST to network host
+
config CMD_TFTPBOOT
bool "tftp"
select PROT_UDP_LWIP
diff --git a/cmd/net-lwip.c b/cmd/net-lwip.c
index 490a2e4ac5c..13856703fcf 100644
--- a/cmd/net-lwip.c
+++ b/cmd/net-lwip.c
@@ -12,6 +12,14 @@ U_BOOT_CMD(
);
#endif
+#if defined(CONFIG_CMD_PING)
+U_BOOT_CMD(
+ ping, 2, 1, do_ping,
+ "send ICMP ECHO_REQUEST to network host",
+ "pingAddress"
+);
+#endif
+
#if defined(CONFIG_CMD_TFTPBOOT)
U_BOOT_CMD(
tftpboot, 3, 0, do_tftpb,
diff --git a/include/net-lwip.h b/include/net-lwip.h
index 2308703e46b..2abaaa3b4e3 100644
--- a/include/net-lwip.h
+++ b/include/net-lwip.h
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
@@ -50,6 +51,7 @@ int eth_env_get_enetaddr_by_index(const char *base_name, int
index,
int eth_init(void);/* Initialize the device */
int eth_send(void *packet, int length); /* Send a packet */
int eth_rx(void);
+const char *eth_get_name(void);
int eth_get_dev_index(void);
int eth_init_state_only(void); /* Set active state */
void eth_set_current(void);/* set nterface to ethcur var */
@@ -80,6 +82,7 @@ int net_lwip_init(void);
struct netif *net_lwip_get_netif(void);
int do_dhcp(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
+int do_ping(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
int do_tftpb(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
#endif /* __NET_LWIP_H__ */
diff --git a/net-lwip/Makefile b/net-lwip/Makefile
index a56c32bfa74..e68d4e24197 100644
--- a/net-lwip/Makefile
+++ b/net-lwip/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_$(SPL_)DM_ETH) += ../net/eth_common.o
obj-$(CONFIG_$(SPL_)DM_ETH) += ../net/eth-uclass.o
obj-$(CONFIG_$(SPL_)DM_ETH) += net-lwip.o
obj-$(CONFIG_CMD_DHCP) += dhcp.o
+obj-$(CONFIG_CMD_PING) += ping.o
obj-$(CONFIG_CMD_TFTPBOOT) += tftp.o
# Disable this warning as it is triggered by:
diff --git a/net-lwip/ping.c b/net-lwip/ping.c
new file mode 100644
index 000..51947d615ed
--- /dev/null
+++ b/net-lwip/ping.c
@@ -0,0 +1,163 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Copyright (C) 2024 Linaro Ltd. */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PING_DELAY_MS 1000
+#define PING_TIMEOUT_MS 1
+/* Ping identifier - must fit on a u16_t */
+#define PING_ID 0xAFAF
+
+static const ip_addr_t *ping_target;
+static struct raw_pcb *ping_pcb;
+static uint16_t ping_seq_num;
+
+static u8_t ping_recv(void *arg, struct raw_pcb *pcb, struct pbuf *p,
+ const ip_addr_t *addr)
+{
+ struct icmp_echo_hdr *iecho;
+ bool *alive = arg;
+
+ if (addr->addr != ping_target->addr)
+ return 0;
+
+ if ((p->tot_len >= (IP_HLEN + sizeof(struct icmp_echo_hdr))) &&
+ pbuf_remove_header(p, IP_HLEN) == 0) {
+ iecho = (struct icmp_echo_hdr *)p->payload;
+
+ if ((iecho->id == PING_ID) &&
+ (iecho->seqno == lwip_htons(ping_seq_num))) {
+ *alive = true;
+ printf("host %s is alive\n", ipaddr_ntoa(addr));
+ pbuf_free(p);
+ return 1; /* eat the packet */
+ }
+ /* not eaten, restore original packet */
+ pbuf_add_header(p, IP_HLEN);
+ }
+
+ return 0; /* don't eat the packet */
+}
+
+static int ping_raw_init(void *recv_arg)
+{
+ ping_pcb = raw_new(IP_PROTO_ICMP);
+ if (!ping_pcb)
+ return -ENOMEM;
+
+ raw_recv(ping_pcb, ping_recv, recv_arg);
+ raw_bind(ping_pcb,
[PATCH v3 04/12] net-lwip: add TFTP support and tftpboot command
Implement do_tftpb().
Signed-off-by: Jerome Forissier
---
cmd/Kconfig | 3 +-
cmd/net-lwip.c | 8 ++
net-lwip/dhcp.c | 11 ++-
net-lwip/tftp.c | 202 +++-
4 files changed, 219 insertions(+), 5 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 1bfa528e945..94a8de266f6 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -2101,10 +2101,9 @@ config CMD_DHCP
config CMD_TFTPBOOT
bool "tftp"
select PROT_UDP_LWIP
- default n
+ default y
help
tftpboot - load file via network using TFTP protocol
- Currently a placeholder (not implemented)
endif
diff --git a/cmd/net-lwip.c b/cmd/net-lwip.c
index 966d7226eda..490a2e4ac5c 100644
--- a/cmd/net-lwip.c
+++ b/cmd/net-lwip.c
@@ -11,3 +11,11 @@ U_BOOT_CMD(
"[loadAddress] [[hostIPaddr:]bootfilename]"
);
#endif
+
+#if defined(CONFIG_CMD_TFTPBOOT)
+U_BOOT_CMD(
+ tftpboot, 3, 0, do_tftpb,
+ "boot image via network using TFTP protocol\n",
+ "[loadAddress] [[hostIPaddr:]bootfilename]"
+);
+#endif
diff --git a/net-lwip/dhcp.c b/net-lwip/dhcp.c
index d1d35999b04..7bacc234f1e 100644
--- a/net-lwip/dhcp.c
+++ b/net-lwip/dhcp.c
@@ -94,11 +94,20 @@ int do_dhcp(struct cmd_tbl *cmdtp, int flag, int argc, char
*const argv[])
int dhcp_run(ulong addr, const char *fname, bool autoload)
{
char *dhcp_argv[] = {"dhcp", NULL, };
+#ifdef CONFIG_CMD_TFTPBOOT
+ char *tftp_argv[] = {"tftpboot", boot_file_name, NULL, };
+#endif
struct cmd_tbl cmdtp = {}; /* dummy */
if (autoload) {
- /* Will be supported when TFTP is added */
+#ifdef CONFIG_CMD_TFTPBOOT
+ /* Assume DHCP was already performed */
+ if (boot_file_name[0])
+ return do_tftpb(, 0, 2, tftp_argv);
+ return 0;
+#else
return -EOPNOTSUPP;
+#endif
}
return do_dhcp(, 0, 1, dhcp_argv);
diff --git a/net-lwip/tftp.c b/net-lwip/tftp.c
index 1fa246f55d9..02ee4aacca5 100644
--- a/net-lwip/tftp.c
+++ b/net-lwip/tftp.c
@@ -2,10 +2,208 @@
/* Copyright (C) 2024 Linaro Ltd. */
#include
+#include
+#include
+#include
+#include
+#include
#include
+#include
+
+static ulong daddr;
+static ulong size;
+static ulong prevsize;
+#define PROGRESS_PRINT_STEP_BYTES (100 * 1024)
+static ulong start_time;
+static enum done_state {
+ NOT_DONE = 0,
+ SUCCESS = 1,
+ FAILURE = 2
+} done;
+
+static void *tftp_open(const char *fname, const char *mode, u8_t is_write)
+{
+ return NULL;
+}
+
+static void tftp_close(void *handle)
+{
+ ulong elapsed;
+
+ if (done == FAILURE) {
+ /* Closing after an error */
+ return;
+ }
+
+ elapsed = get_timer(start_time);
+ done = SUCCESS;
+ printf("\nBytes transferred = %lu (%lx hex)\n", size, size);
+
+ if (env_set_hex("filesize", size)) {
+ log_err("filesize not updated\n");
+ return;
+ }
+}
+
+static int tftp_read(void *handle, void *buf, int bytes)
+{
+ return 0;
+}
+
+static int tftp_write(void *handle, struct pbuf *p)
+{
+ struct pbuf *q;
+
+ for (q = p; q != NULL; q = q->next) {
+ memcpy((void *)daddr, q->payload, q->len);
+ daddr += q->len;
+ size += q->len;
+ if (size - prevsize > PROGRESS_PRINT_STEP_BYTES) {
+ printf("#");
+ prevsize = size;
+ }
+ }
+
+ return 0;
+}
+
+static void tftp_error(void *handle, int err, const char *msg, int size)
+{
+ char message[100];
+
+ done = FAILURE;
+ memset(message, 0, sizeof(message));
+ memcpy(message, msg, LWIP_MIN(sizeof(message) - 1, (size_t)size));
+
+ log_info("\nTFTP error: %d (%s)\n", err, message);
+}
+
+static const struct tftp_context tftp_context = {
+ tftp_open,
+ tftp_close,
+ tftp_read,
+ tftp_write,
+ tftp_error
+};
+
+static int tftp_run(ulong addr, char *fname, ip_addr_t srvip)
+{
+ void *f = (void *)0x1; /* unused fake file handle*/
+ err_t err;
+
+ if (!fname || addr == 0)
+ return -1;
+
+ done = NOT_DONE;
+ size = 0;
+ prevsize = 0;
+ daddr = addr;
+
+ log_info("TFTP from server %s; our IP address is %s\n",
+ip4addr_ntoa(), env_get("ipaddr"));
+ log_info("Filename '%s'.\n", fname);
+ log_info("Load address: 0x%lx\n", daddr);
+ log_info("Loading: ");
+
+ err = tftp_init_client(_context);
+ if (!(err == ERR_OK || err == ERR_USE))
+ log_err("tftp_init_client err: %d\n", err);
+
+ start_time = get_timer(0);
+ err = tftp_get(f, , TFTP_PORT, fname, TFTP_MODE_OCTET);
+ /* might return different errors, like routing problems */
+ if (err != ERR_OK) {
+ log_err("tftp_get err=%d\n",
[PATCH v3 02/12] net-lwip: build lwIP
Build the lwIP library when NET_LWIP is enabled. The following files
are adaptation layers written specially for U-Boot:
lib/lwip/u-boot/arch/cc.h
lib/lwip/u-boot/arch/sys_arch.h (empty)
lib/lwip/u-boot/limits.h (empty)
lib/lwip/u-boot/lwipopts.h
They were initially contributed by Maxim in a previous RFC patch series.
Signed-off-by: Jerome Forissier
Co-developed-by: Maxim Uvarov
Cc: Maxim Uvarov
---
lib/Makefile| 2 +
lib/lwip/Makefile | 57 +
lib/lwip/u-boot/arch/cc.h | 43 +++
lib/lwip/u-boot/arch/sys_arch.h | 0
lib/lwip/u-boot/limits.h| 0
lib/lwip/u-boot/lwipopts.h | 197
6 files changed, 299 insertions(+)
create mode 100644 lib/lwip/Makefile
create mode 100644 lib/lwip/u-boot/arch/cc.h
create mode 100644 lib/lwip/u-boot/arch/sys_arch.h
create mode 100644 lib/lwip/u-boot/limits.h
create mode 100644 lib/lwip/u-boot/lwipopts.h
diff --git a/lib/Makefile b/lib/Makefile
index 2a76acf100d..c35786a0576 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -94,6 +94,8 @@ obj-$(CONFIG_LIBAVB) += libavb/
obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += libfdt/
obj-$(CONFIG_$(SPL_TPL_)OF_REAL) += fdtdec_common.o fdtdec.o
+obj-$(CONFIG_NET_LWIP) += lwip/
+
ifdef CONFIG_SPL_BUILD
obj-$(CONFIG_SPL_YMODEM_SUPPORT) += crc16-ccitt.o
obj-$(CONFIG_$(SPL_TPL_)HASH) += crc16-ccitt.o
diff --git a/lib/lwip/Makefile b/lib/lwip/Makefile
new file mode 100644
index 000..158e59b91fc
--- /dev/null
+++ b/lib/lwip/Makefile
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2024 Linaro Ltd.
+
+ccflags-y += -I$(srctree)/lib/lwip/lwip/src/include
-I$(srctree)/lib/lwip/u-boot
+
+obj-y += \
+ lwip/src/api/api_lib.o \
+ lwip/src/api/api_msg.o \
+ lwip/src/api/err.o \
+ lwip/src/api/if_api.o \
+ lwip/src/api/netbuf.o \
+ lwip/src/api/netdb.o \
+ lwip/src/api/netifapi.o \
+ lwip/src/api/sockets.o \
+ lwip/src/api/tcpip.o \
+ lwip/src/apps/http/http_client.o \
+ lwip/src/apps/tftp/tftp.o \
+ lwip/src/core/altcp_alloc.o \
+ lwip/src/core/altcp.o \
+ lwip/src/core/altcp_tcp.o \
+ lwip/src/core/def.o \
+ lwip/src/core/dns.o \
+ lwip/src/core/inet_chksum.o \
+ lwip/src/core/init.o \
+ lwip/src/core/ip.o \
+ lwip/src/core/ipv4/acd.o \
+ lwip/src/core/ipv4/autoip.o \
+ lwip/src/core/ipv4/dhcp.o \
+ lwip/src/core/ipv4/etharp.o \
+ lwip/src/core/ipv4/icmp.o \
+ lwip/src/core/ipv4/igmp.o \
+ lwip/src/core/ipv4/ip4_addr.o \
+ lwip/src/core/ipv4/ip4.o \
+ lwip/src/core/ipv4/ip4_frag.o \
+ lwip/src/core/ipv6/dhcp6.o \
+ lwip/src/core/ipv6/ethip6.o \
+ lwip/src/core/ipv6/icmp6.o \
+ lwip/src/core/ipv6/inet6.o \
+ lwip/src/core/ipv6/ip6_addr.o \
+ lwip/src/core/ipv6/ip6.o \
+ lwip/src/core/ipv6/ip6_frag.o \
+ lwip/src/core/ipv6/mld6.o \
+ lwip/src/core/ipv6/nd6.o \
+ lwip/src/core/mem.o \
+ lwip/src/core/memp.o \
+ lwip/src/core/netif.o \
+ lwip/src/core/pbuf.o \
+ lwip/src/core/raw.o \
+ lwip/src/core/stats.o \
+ lwip/src/core/sys.o \
+ lwip/src/core/tcp.o \
+ lwip/src/core/tcp_in.o \
+ lwip/src/core/tcp_out.o \
+ lwip/src/core/timeouts.o \
+ lwip/src/core/udp.o \
+ lwip/src/netif/ethernet.o
diff --git a/lib/lwip/u-boot/arch/cc.h b/lib/lwip/u-boot/arch/cc.h
new file mode 100644
index 000..31c036dc0c5
--- /dev/null
+++ b/lib/lwip/u-boot/arch/cc.h
@@ -0,0 +1,43 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (C) 2023 Linaro Ltd. */
+
+#ifndef LWIP_ARCH_CC_H
+#define LWIP_ARCH_CC_H
+
+#include
+#include
+#include
+#include
+
+#define LWIP_ERRNO_INCLUDE
+
+#define LWIP_ERRNO_STDINCLUDE 1
+#define LWIP_NO_UNISTD_H 1
+#define LWIP_TIMEVAL_PRIVATE 1
+
+#ifdef CONFIG_LIB_RAND
+#define LWIP_RAND() ((u32_t)rand())
+#endif
+
+/* different handling for unit test, normally not needed */
+#ifdef LWIP_NOASSERT_ON_ERROR
+#define LWIP_ERROR(message, expression, handler) do { if (!(expression)) { \
+ handler; }} while (0)
+#endif
+
+#define LWIP_DONT_PROVIDE_BYTEORDER_FUNCTIONS
+
+#define LWIP_PLATFORM_ASSERT(x) do {printf("Assertion \"%s\" failed at line %d
in %s\n", \
+ x, __LINE__, __FILE__); } while (0)
+
+#define atoi(str) (int)dectoul(str, NULL)
+#define lwip_strnstr(a, b) strnstr(a, b)
+
+#define LWIP_ERR_T int
+#define LWIP_CONST_CAST(target_type, val) ((target_type)((uintptr_t)val))
+
+#if defined(CONFIG_SYS_BIG_ENDIAN)
+#define BYTE_ORDER BIG_ENDIAN
+#endif
+
+#endif /* LWIP_ARCH_CC_H */
diff --git a/lib/lwip/u-boot/arch/sys_arch.h b/lib/lwip/u-boot/arch/sys_arch.h
new file mode 100644
index 000..e69de29bb2d
diff --git a/lib/lwip/u-boot/limits.h b/lib/lwip/u-boot/limits.h
new file mode 100644
index
[PATCH v3 00/12] Introduce the lwIP network stack
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. (CC'd) has 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 The first patch introduces a new Kconfig symbol: NET_LWIP, which selects the lwIP implementation instead of the current one (NET). Contrary to the approach chosen by Maxim in [1], NET_LWIP and NET cannot be enabled simultaneously. The rationale is we want to start from a clean state and not pull potentially duplicated functionality from both stacks. Note however that a few files are still built in net/, they are the ones related to ethernet device management and the ethernet bootflow. The second patch introduces the Makefile to build lwIP when NET_LWIP is enabled. The subsequent patches implement various network-oriented commands and features: dhcp, dns, ping, tftpboot, wget. NET_LWIP is not enabled by default because it lacks functionality compared to NET and many CI tests would fail to run or even build. Some tests (dm dsa/eth) are disabled when NET_LWIP is selected because they make strong assumptions on how the network stack is implemented and how the packet flow occurs. For example, an ARP exchange is expected when an ICMP packet goes out, but with lwIP no exchange will occur if the host IP is already in the the ARP cache. Due to the above and in order to provide some level of testing, a new QEMU configuration is introduced (qemu_arm64_lwip_defconfig) which is the same as qemu_arm64_lwip_defconfig but with NET_LWIP and CMD_*_LWIP enabled. Tests are added to test/py/tests/test_net.py for that configuration. Changes in v3: - Make NET_LWIP a Kconfig choice in patch "net: introduce alternative implementation as net-lwip/" (Tom R.) - Drop the patch introducing lwIP as a Git subtree and document the git command in the cover letter instead (Tom R.) - "net-lwip: add TFTP support and tftpboot command": use the same "Bytes transferred =" message as in the legacy implementation (Tom R., Maxim U.) - Drop "test/py: net: add _lwip variants of dhcp, ping and tftpboot tests" which is not needed anymore. - Add missing kfree() calls in cmd/net-common.c and fix the parsing of decimal address in net-lwip/wget.c (patch "net-lwip: add wget command") (Maxim U.) - "net-lwip: add ping command": drop the ICMP payload (Ilias A.). Set the sequence number to zero when entering ping_loop(). Changes in v2: ** Address comments from Ilias A. - "net-lwip: add wget command" Implement the wget_with_dns() function to do most of the wget work and call it from do_wget(). This allows to simplify patch "net-lwip: add support for EFI_HTTP_BOOT". - "net-lwip: import net command from cmd/net.c" Move a few functions from cmd/net.c to a new file cmd/net-common.c rather than duplicating then in cmd/net-lwip.c. - "net-lwip: add support for EFI_HTTP_BOOT" Since wget_with_dns() is now implemented in "net-lwip: add wget command", just enable the wget command when the lwIP stack is enabled and EFI_HTTP_BOOT is requested. ** Address comments from Tom R. - "net-lwip: add DHCP support and dhcp commmand", "net-lwip: add TFTP support and tftpboot command", "net-lwip: add ping command", "net-lwip: add dns command", "net-lwip: add wget command" Do not introduce new CMD_XXX_LWIP symbols and use existing CMD_XXX instead. - "configs: add qemu_arm64_lwip_defconfig" Use #include . - "net-lwip: import lwIP library under lib/lwip" Patch removed and replaced by the introduction of a Git subtree: "Squashed 'lib/lwip/lwip/' content from commit 0a0452b2c3". Note that I have not yet addressed your comments on "test: dm: dsa, eth: disable tests when CONFIG_NET_LWIP=y"). I need some more time for that and I think running CI on this v2 will help better understand what is needed for v3. ** Miscellaneous improvements - "net: introduce alternative implementation as net-lwip/": *
[PATCH] ARM: stm32: Fix livetree conversion on STM32MP15xx DHSOM
Unlike fdt_node_check_compatible() which returns 0 if node is compatible,
ofnode_device_is_compatible() return true which is non-zero if node is
compatible. The intention of the code is to exit from the function in
case the node is not compatible with "micrel,ks8851-mll". Add the missing
invert into the conditional to reinstate original behavior.
This exposes a follow up problem caused by conversion to DM based FMC2 EBI
driver, where the FMC2 EBI is not configured when accessed by this code.
Probe the KS8851 MAC, which also configures the FMC2 EBI as a dependency,
so that the KS8851 MAC CCR register can be accessed over the FMC2 EBI bus
and checked for EEPROM present bit.
Fixes: 5a605b7c8615 ("board: dhelectronics: stm32mp1: convert to livetree")
Signed-off-by: Marek Vasut
---
Cc: Patrice Chotard
Cc: Patrick Delaunay
Cc: Simon Glass
Cc: Tom Rini
Cc: u-b...@dh-electronics.com
Cc: u-boot@lists.denx.de
Cc: uboot-st...@st-md-mailman.stormreply.com
---
board/dhelectronics/dh_stm32mp1/board.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/board/dhelectronics/dh_stm32mp1/board.c
b/board/dhelectronics/dh_stm32mp1/board.c
index ebd45f9053f..4f4f537fee5 100644
--- a/board/dhelectronics/dh_stm32mp1/board.c
+++ b/board/dhelectronics/dh_stm32mp1/board.c
@@ -76,14 +76,25 @@
static bool dh_stm32_mac_is_in_ks8851(void)
{
- ofnode node;
+ struct udevice *udev;
u32 reg, cider, ccr;
+ char path[256];
+ ofnode node;
+ int ret;
node = ofnode_path("ethernet1");
if (!ofnode_valid(node))
return false;
- if (ofnode_device_is_compatible(node, "micrel,ks8851-mll"))
+ ret = ofnode_get_path(node, path, sizeof(path));
+ if (ret)
+ return false;
+
+ ret = uclass_get_device_by_of_path(UCLASS_ETH, path, );
+ if (ret)
+ return false;
+
+ if (!ofnode_device_is_compatible(node, "micrel,ks8851-mll"))
return false;
/*
--
2.43.0
[PATCH] ARM: dts: stm32: Auto-detect second MAC on STM32MP15xx DH electronics DHCOM
Test whether this system is compatible with STM32MP15xx DHCOM SoM,
if so, test whether R292 pull up is populated on pin PC3, which is
an indication that the second MAC chip, KS8851-16MLL, is populated.
Use this information to patch 'status' DT property into the second
ethernet MAC DT node and enable/disable the MAC on systems where
the chip is/isn't populated respectively.
Use spl_perform_fixups() to patch the U-Boot proper DT from SPL and
ft_board_setup() to patch Linux DT from U-Boot proper. This way both
software components are configured the same way.
Signed-off-by: Marek Vasut
---
Cc: Patrice Chotard
Cc: Patrick Delaunay
Cc: Simon Glass
Cc: Tom Rini
Cc: u-b...@dh-electronics.com
Cc: u-boot@lists.denx.de
Cc: uboot-st...@st-md-mailman.stormreply.com
---
arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 1 +
board/dhelectronics/dh_stm32mp1/board.c| 65 ++
2 files changed, 66 insertions(+)
diff --git a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
index 1b445619325..d7b78cdcfa9 100644
--- a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
@@ -26,6 +26,7 @@
u-boot,error-led = "error";
dh,som-coding-gpios = < 12 0>, < 13 0>, < 15
0>;
dh,ddr3-coding-gpios = < 6 0>, < 7 0>;
+ dh,mac-coding-gpios = < 3 0>;
};
};
diff --git a/board/dhelectronics/dh_stm32mp1/board.c
b/board/dhelectronics/dh_stm32mp1/board.c
index 20c9d70737e..ebd45f9053f 100644
--- a/board/dhelectronics/dh_stm32mp1/board.c
+++ b/board/dhelectronics/dh_stm32mp1/board.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -672,12 +673,69 @@ void board_quiesce_devices(void)
#endif
}
+static void dh_stm32_ks8851_fixup(void *blob)
+{
+ struct gpio_desc ks8851intrn;
+ bool compatible = false;
+ int ks8851intrn_value;
+ const char *prop;
+ ofnode node;
+ int idx = 0;
+ int offset;
+ int ret;
+
+ /* Do nothing if not STM32MP15xx DHCOM SoM */
+ while ((prop = fdt_stringlist_get(blob, 0, "compatible", idx++, NULL)))
{
+ if (!strstr(prop, "dhcom-som"))
+ continue;
+ compatible = true;
+ break;
+ }
+
+ if (!compatible)
+ return;
+
+ /*
+* Read state of INTRN pull up resistor, if this pull up is populated,
+* KS8851-16MLL is populated as well and should be enabled, otherwise
+* it should be disabled.
+*/
+ node = ofnode_path("/config");
+ if (!ofnode_valid(node))
+ return;
+
+ ret = gpio_request_by_name_nodev(node, "dh,mac-coding-gpios", 0,
+, GPIOD_IS_IN);
+ if (ret)
+ return;
+
+ ks8851intrn_value = dm_gpio_get_value();
+
+ dm_gpio_free(NULL, );
+
+ /* Set the 'status' property into KS8851-16MLL DT node. */
+ offset = fdt_path_offset(blob, "ethernet1");
+ ret = fdt_node_check_compatible(blob, offset, "micrel,ks8851-mll");
+ if (ret)/* Not compatible */
+ return;
+
+ /* Add a bit of extra space for new 'status' property */
+ ret = fdt_shrink_to_minimum(blob, 4096);
+ if (!ret)
+ return;
+
+ fdt_setprop_string(blob, offset, "status",
+ ks8851intrn_value ? "okay" : "disabled");
+}
+
#if defined(CONFIG_OF_BOARD_SETUP)
int ft_board_setup(void *blob, struct bd_info *bd)
{
const char *buck3path = "/soc/i2c@5c002000/stpmic@33/regulators/buck3";
int buck3off, ret, uv;
+ dh_stm32_ks8851_fixup(blob);
+
ret = board_get_regulator_buck3_nvm_uv_av96();
if (ret)/* Not Avenger96 board, do not patch Buck3 in DT. */
return 0;
@@ -698,6 +756,13 @@ int ft_board_setup(void *blob, struct bd_info *bd)
}
#endif
+#if defined(CONFIG_SPL_BUILD)
+void spl_perform_fixups(struct spl_image_info *spl_image)
+{
+ dh_stm32_ks8851_fixup(spl_image_fdt_addr(spl_image));
+}
+#endif
+
static void board_copro_image_process(ulong fw_image, size_t fw_size)
{
int ret, id = 0; /* Copro id fixed to 0 as only one coproc on mp1 */
--
2.43.0
Re: [PATCH v2 0/1] xilinx: Add option to load environment from outside of
On 6/3/24 18:47, Vasileios Amoiridis wrote: From: Vasileios Amoiridis Changes in v2: - Remove duplication of custom hardcoded env_locations[] code. - Add implementation with general arch_env_get_location(op, prio) v1: https://lore.kernel.org/u-boot/20240522174738.73522-1-vassilisa...@gmail.com/ Vasileios Amoiridis (1): xilinx: Add option to load environment from outside of boot media board/xilinx/versal-net/board.c | 47 ++-- board/xilinx/versal/board.c | 47 ++-- board/xilinx/zynq/board.c | 49 +++-- board/xilinx/zynqmp/zynqmp.c| 55 + 4 files changed, 101 insertions(+), 97 deletions(-) Applied. M
Re: [PATCH 0/7] misc: introduce STATUS LED activity function
On Thu, Jun 06, 2024 at 12:55:37PM +0200, Quentin Schulz wrote: > Hi Christian, > > On 6/6/24 11:52 AM, Christian Marangi wrote: > > On Thu, Jun 06, 2024 at 11:12:11AM +0200, Quentin Schulz wrote: > > > Hi Christian, > > > > > > On 6/5/24 9:21 PM, Christian Marangi wrote: > > > > This series expand the STATUS LED framework with a new color > > > > and a big new feature. One thing that many device need is a way > > > > to communicate to the user that the device is actually doing > > > > something. > > > > > > > > This is especially useful for recovery steps where an > > > > user (for example) insert an USB drive, keep a button pressed > > > > and the device autorecover. > > > > > > > > There is currently no way to signal the user externally that > > > > the bootloader is processing/recoverying aside from setting > > > > a LED on. > > > > > > > > A solid LED on is not enough and won't actually signal any > > > > kind of progress. > > > > Solution is the good old blinking LED but uboot doesn't > > > > suggest (and support) interrupts and almost all the LED > > > > are usually GPIO LED that doesn't support HW blink. > > > > > > > > > > I haven't used it yet but we do have a cyclic framework now for things > > > happening in the background. I think this is a good use-case for this > > > framework? Something would set the blinking frequency (could be from CLI > > > directly, or as part of board files, or architecture, etc...) and the LED > > > would just blink then. This would allow to highlight stages in the boot > > > process, though that is not like an activity LED so if you're stuck in a > > > stage, you wouldn't know if something is still happening or if you're > > > really > > > stuck (e.g. no packet on TFTP or TFTP very slow). The benefit is that it > > > would be way less intrusive than patching all commands that could make use > > > of that LED. Right now, this only adds support to MTD, SPI and TFTP, but > > > what about MMC, NVMe, USB, other net stuff (e.g. wget), etc... > > > > > > > Can you hint me on where is this framework? Checking the tftp code i > > couldn't find extra call to it. Maybe it's attached to the schedule() > > function? > > > > https://docs.u-boot.org/en/latest/develop/cyclic.html > Thanks looks very interesting and looks handy to make use of the watchdog for it. I will try now to rework the implementation for the sw blink to make use of cyclic thing. > > Also notice that it's really not a one setting since almost all device > > have GPIO LEDs and doesn't have a way to support HW Blink so the > > "activity" function needs to be called multiple time to increase the > > counter and toggle the LED. > > > > Cyclic callback would be called twice per expected blink period, where you > would toggle the GPIO (essentially making it 50% duty cycle, but could be > more fine-grained if you want a different duty cycle). > Well status LED already have CONFIG_STATUS_LED_FREQ where you can set a value. I will just use this. > > Also this have the extra feature that you can check if something gets > > stuck in the process. The lifecycle is: > > - Turn on the ACTIVITY LED at the start of the thing > > - Blink once in a while (for very little task this might not happen) > > - Turn off the ACTIVITY LED at the end of the thing > > > > Soo if something goes wrong the LED would never turn OFF but would stay > > solid ON. > > > > Yes, that's something that wouldn't be covered by cyclic framework here. It > all depends what you want to do, if it's an activity LED, then we need to > hook ourselves deep into frameworks where stuff is actually happening. If > it's just to specify which stage of the boot we reached, then cyclic would > be good enough probably (register for stage 1, unregister stage1+register > for stage2 for different frequency, etc...). > The cyclic framework can reduce the implementation to just START and STOP. We would lose the ability to know if there is an actual progress or not tho... So maybe that is bad but honestly a TFTP transfer can be tracked by the other machine and MTD write/erase won't magically stop and get stalled... (and even with that they will timeout and the status LED stop will be called anyway) So a dumb blinking with the watchdog is O.K. This is really a simple thing to show that something is happening (use case of recovering the device without actually using serial) > > More than happy to rework this to a less intrusive implementation. > > > > Maybe this can be generalized to some generic API like task_start(), > > task_processing() and task_end()? Might make more sense than having to > > add specific LED function to each function? > > > > This also likely would introduce a hit in performance if we need to toggle > the GPIO in the same thread that we do TFTP/storage medium reading/writing? > I assume we could still adapt cyclic to make it spawn a one time event > instead of looping (e.g. by unregistering itself at the end of its own >
Re: [PATCH 0/7] misc: introduce STATUS LED activity function
Hi Christian, On 6/6/24 11:52 AM, Christian Marangi wrote: On Thu, Jun 06, 2024 at 11:12:11AM +0200, Quentin Schulz wrote: Hi Christian, On 6/5/24 9:21 PM, Christian Marangi wrote: This series expand the STATUS LED framework with a new color and a big new feature. One thing that many device need is a way to communicate to the user that the device is actually doing something. This is especially useful for recovery steps where an user (for example) insert an USB drive, keep a button pressed and the device autorecover. There is currently no way to signal the user externally that the bootloader is processing/recoverying aside from setting a LED on. A solid LED on is not enough and won't actually signal any kind of progress. Solution is the good old blinking LED but uboot doesn't suggest (and support) interrupts and almost all the LED are usually GPIO LED that doesn't support HW blink. I haven't used it yet but we do have a cyclic framework now for things happening in the background. I think this is a good use-case for this framework? Something would set the blinking frequency (could be from CLI directly, or as part of board files, or architecture, etc...) and the LED would just blink then. This would allow to highlight stages in the boot process, though that is not like an activity LED so if you're stuck in a stage, you wouldn't know if something is still happening or if you're really stuck (e.g. no packet on TFTP or TFTP very slow). The benefit is that it would be way less intrusive than patching all commands that could make use of that LED. Right now, this only adds support to MTD, SPI and TFTP, but what about MMC, NVMe, USB, other net stuff (e.g. wget), etc... Can you hint me on where is this framework? Checking the tftp code i couldn't find extra call to it. Maybe it's attached to the schedule() function? https://docs.u-boot.org/en/latest/develop/cyclic.html Also notice that it's really not a one setting since almost all device have GPIO LEDs and doesn't have a way to support HW Blink so the "activity" function needs to be called multiple time to increase the counter and toggle the LED. Cyclic callback would be called twice per expected blink period, where you would toggle the GPIO (essentially making it 50% duty cycle, but could be more fine-grained if you want a different duty cycle). Also this have the extra feature that you can check if something gets stuck in the process. The lifecycle is: - Turn on the ACTIVITY LED at the start of the thing - Blink once in a while (for very little task this might not happen) - Turn off the ACTIVITY LED at the end of the thing Soo if something goes wrong the LED would never turn OFF but would stay solid ON. Yes, that's something that wouldn't be covered by cyclic framework here. It all depends what you want to do, if it's an activity LED, then we need to hook ourselves deep into frameworks where stuff is actually happening. If it's just to specify which stage of the boot we reached, then cyclic would be good enough probably (register for stage 1, unregister stage1+register for stage2 for different frequency, etc...). More than happy to rework this to a less intrusive implementation. Maybe this can be generalized to some generic API like task_start(), task_processing() and task_end()? Might make more sense than having to add specific LED function to each function? This also likely would introduce a hit in performance if we need to toggle the GPIO in the same thread that we do TFTP/storage medium reading/writing? I assume we could still adapt cyclic to make it spawn a one time event instead of looping (e.g. by unregistering itself at the end of its own callback?). (AFAIK linux kernel have something similar used for all the trace framework so having something in uboot to trace these kind of operation might be interesting) Indeed, that's what's being done with ledtrig_.* functions, they are however scheduled on a workqueue and called from the subsystem directly. I'm a bit confused also as to why we control the LED blinking from the cmd/ ? E.g. for cmd/mtd.c I would assume that the changes made to the mtd subsystem should be enough to handle those? Similarly, since UBI is for use over NAND/MTD, shouldn't that already be handled by the MTD subsystem, and if not, why not in the UBI subsystem instead of the CMD_UBI? One of the issues is that you may not necessarily go through the cmd/ to do stuff with storage medium or network (e.g. directly from board files). For the net protocols, why not hook this to the net_[sg]et_*_handler for example so it's protocol-agnostic? No clue how difficult this would be, or if you'd rather have something like per-protocol activity? Finally, maybe we also want to have a Kconfig symbol per "type" of activity to control what should be "monitored", and I would also suggest if we go this route to have a Kconfig symbol for the frequency per "type" of activity as well, so that
Re: [PATCH v2 08/14] net-lwip: add wget command
чт, 6 июн. 2024 г. в 12:56, Jerome Forissier :
>
>
>
> On 5/28/24 15:39, Maxim Uvarov wrote:
> > пт, 24 мая 2024 г. в 19:22, Jerome Forissier :
> >>
> >> Add support for the wget command with NET_LWIP.
> >>
> >> About the small change in cmd/efidebug.c: when the wget command based
> >> on the lwIP stack is used the wget command has a built-in URL
> >> validation function since it needs to parse it anyways (in parse_url()).
> >> Therefore wget_validate_uri() doesn't exist. So, guard the call in
> >> efidebug.c with CONFIG_CMD_WGET.
> >>
> >> Based on code initially developed by Maxim U.
> >>
> >> Signed-off-by: Jerome Forissier
> >> Co-developed-by: Maxim Uvarov
> >> Cc: Maxim Uvarov
> >> ---
> >> cmd/Kconfig| 7 ++
> >> cmd/Makefile | 5 +-
> >> cmd/efidebug.c | 8 +-
> >> cmd/net-common.c | 112
> >> cmd/net-lwip.c | 12 +++
> >> cmd/net.c | 115 -
> >> include/net-lwip.h | 51 +
> >> net-lwip/Makefile | 1 +
> >> net-lwip/wget.c| 180 +
> >> 9 files changed, 372 insertions(+), 119 deletions(-)
> >> create mode 100644 cmd/net-common.c
> >> create mode 100644 net-lwip/wget.c
> >>
> >> diff --git a/cmd/Kconfig b/cmd/Kconfig
> >> index 6ef0b52cd34..d9a86540be6 100644
> >> --- a/cmd/Kconfig
> >> +++ b/cmd/Kconfig
> >> @@ -2117,6 +2117,13 @@ config CMD_TFTPBOOT
> >> help
> >> tftpboot - load file via network using TFTP protocol
> >>
> >> +config CMD_WGET
> >> + bool "wget"
> >> + select PROT_TCP_LWIP
> >> + help
> >> + wget is a simple command to download kernel, or other files,
> >> + from a http server over TCP.
> >> +
> >> endif
> >>
> >> endif
> >> diff --git a/cmd/Makefile b/cmd/Makefile
> >> index 535b6838ca5..e90f2f68211 100644
> >> --- a/cmd/Makefile
> >> +++ b/cmd/Makefile
> >> @@ -129,8 +129,11 @@ obj-$(CONFIG_CMD_MUX) += mux.o
> >> obj-$(CONFIG_CMD_NAND) += nand.o
> >> obj-$(CONFIG_CMD_NET) += net.o
> >> obj-$(CONFIG_CMD_NET_LWIP) += net-lwip.o
> >> +obj-$(filter y,$(CONFIG_CMD_NET) $(CONFIG_CMD_NET_LWIP)) += net-common.o
> >> ifdef CONFIG_CMD_NET_LWIP
> >> -CFLAGS_net-lwip.o := -I$(srctree)/lib/lwip/lwip/src/include
> >> -I$(srctree)/lib/lwip/u-boot
> >> +lwip-includes := -I$(srctree)/lib/lwip/lwip/src/include
> >> -I$(srctree)/lib/lwip/u-boot
> >> +CFLAGS_net-lwip.o := $(lwip-includes)
> >> +CFLAGS_net-common.o := $(lwip-includes)
> >> endif
> >> obj-$(CONFIG_ENV_SUPPORT) += nvedit.o
> >> obj-$(CONFIG_CMD_NVEDIT_EFI) += nvedit_efi.o
> >> diff --git a/cmd/efidebug.c b/cmd/efidebug.c
> >> index c2c525f2351..d80e91ecadd 100644
> >> --- a/cmd/efidebug.c
> >> +++ b/cmd/efidebug.c
> >> @@ -741,9 +741,11 @@ static int efi_boot_add_uri(int argc, char *const
> >> argv[], u16 *var_name16,
> >> if (!label)
> >> return CMD_RET_FAILURE;
> >>
> >> - if (!wget_validate_uri(argv[3])) {
> >> - printf("ERROR: invalid URI\n");
> >> - return CMD_RET_FAILURE;
> >> + if (IS_ENABLED(CONFIG_CMD_WGET)) {
> >> + if (!wget_validate_uri(argv[3])) {
> >> + printf("ERROR: invalid URI\n");
> >> + return CMD_RET_FAILURE;
> >> + }
> >> }
> >>
> >> efi_create_indexed_name(var_name16, var_name16_size, "Boot", id);
> >> diff --git a/cmd/net-common.c b/cmd/net-common.c
> >> new file mode 100644
> >> index 000..b5dfd2c8866
> >> --- /dev/null
> >> +++ b/cmd/net-common.c
> >> @@ -0,0 +1,112 @@
> >> +// SPDX-License-Identifier: GPL-2.0+
> >> +/*
> >> + * (C) Copyright 2000
> >> + * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
> >> + */
> >> +
> >> +#include
> >> +#include
> >> +#include
> >> +#ifdef CONFIG_NET
> >> +#include
> >> +#elif defined CONFIG_NET_LWIP
> >> +#include
> >> +#else
> >> +#error Either NET or NET_LWIP must be enabled
> >> +#endif
> >> +#include
> >> +#include
> >> +
> >> +static int do_net_list(struct cmd_tbl *cmdtp, int flag, int argc, char
> >> *const argv[])
> >> +{
> >> + const struct udevice *current = eth_get_dev();
> >> + unsigned char env_enetaddr[ARP_HLEN];
> >> + const struct udevice *dev;
> >> + struct uclass *uc;
> >> +
> >> + uclass_id_foreach_dev(UCLASS_ETH, dev, uc) {
> >> + eth_env_get_enetaddr_by_index("eth", dev_seq(dev),
> >> env_enetaddr);
> >> + printf("eth%d : %s %pM %s\n", dev_seq(dev), dev->name,
> >> env_enetaddr,
> >> + current == dev ? "active" : "");
> >> + }
> >> + return CMD_RET_SUCCESS;
> >> +}
> >> +
> >> +static int do_net_stats(struct cmd_tbl *cmdtp, int flag, int argc, char
> >> *const argv[])
> >> +{
> >> + int nstats, err, i, off;
> >> + struct udevice *dev;
> >> + u64 *values;
> >> + u8 *strings;
> >> +
> >> + if (argc < 2)
> >> + return
Re: [PATCH 0/7] misc: introduce STATUS LED activity function
On Thu, Jun 06, 2024 at 11:12:11AM +0200, Quentin Schulz wrote: > Hi Christian, > > On 6/5/24 9:21 PM, Christian Marangi wrote: > > This series expand the STATUS LED framework with a new color > > and a big new feature. One thing that many device need is a way > > to communicate to the user that the device is actually doing > > something. > > > > This is especially useful for recovery steps where an > > user (for example) insert an USB drive, keep a button pressed > > and the device autorecover. > > > > There is currently no way to signal the user externally that > > the bootloader is processing/recoverying aside from setting > > a LED on. > > > > A solid LED on is not enough and won't actually signal any > > kind of progress. > > Solution is the good old blinking LED but uboot doesn't > > suggest (and support) interrupts and almost all the LED > > are usually GPIO LED that doesn't support HW blink. > > > > I haven't used it yet but we do have a cyclic framework now for things > happening in the background. I think this is a good use-case for this > framework? Something would set the blinking frequency (could be from CLI > directly, or as part of board files, or architecture, etc...) and the LED > would just blink then. This would allow to highlight stages in the boot > process, though that is not like an activity LED so if you're stuck in a > stage, you wouldn't know if something is still happening or if you're really > stuck (e.g. no packet on TFTP or TFTP very slow). The benefit is that it > would be way less intrusive than patching all commands that could make use > of that LED. Right now, this only adds support to MTD, SPI and TFTP, but > what about MMC, NVMe, USB, other net stuff (e.g. wget), etc... > Can you hint me on where is this framework? Checking the tftp code i couldn't find extra call to it. Maybe it's attached to the schedule() function? Also notice that it's really not a one setting since almost all device have GPIO LEDs and doesn't have a way to support HW Blink so the "activity" function needs to be called multiple time to increase the counter and toggle the LED. Also this have the extra feature that you can check if something gets stuck in the process. The lifecycle is: - Turn on the ACTIVITY LED at the start of the thing - Blink once in a while (for very little task this might not happen) - Turn off the ACTIVITY LED at the end of the thing Soo if something goes wrong the LED would never turn OFF but would stay solid ON. More than happy to rework this to a less intrusive implementation. Maybe this can be generalized to some generic API like task_start(), task_processing() and task_end()? Might make more sense than having to add specific LED function to each function? (AFAIK linux kernel have something similar used for all the trace framework so having something in uboot to trace these kind of operation might be interesting) -- Ansuel
Re: [PATCH 0/7] misc: introduce STATUS LED activity function
Hi Christian, On 6/5/24 9:21 PM, Christian Marangi wrote: This series expand the STATUS LED framework with a new color and a big new feature. One thing that many device need is a way to communicate to the user that the device is actually doing something. This is especially useful for recovery steps where an user (for example) insert an USB drive, keep a button pressed and the device autorecover. There is currently no way to signal the user externally that the bootloader is processing/recoverying aside from setting a LED on. A solid LED on is not enough and won't actually signal any kind of progress. Solution is the good old blinking LED but uboot doesn't suggest (and support) interrupts and almost all the LED are usually GPIO LED that doesn't support HW blink. I haven't used it yet but we do have a cyclic framework now for things happening in the background. I think this is a good use-case for this framework? Something would set the blinking frequency (could be from CLI directly, or as part of board files, or architecture, etc...) and the LED would just blink then. This would allow to highlight stages in the boot process, though that is not like an activity LED so if you're stuck in a stage, you wouldn't know if something is still happening or if you're really stuck (e.g. no packet on TFTP or TFTP very slow). The benefit is that it would be way less intrusive than patching all commands that could make use of that LED. Right now, this only adds support to MTD, SPI and TFTP, but what about MMC, NVMe, USB, other net stuff (e.g. wget), etc... Cheers, Quentin
Re: [PATCH 5/7] tftp: implement support for LED status activity
On Thu, Jun 06, 2024 at 09:22:05AM +0100, Peter Robinson wrote: > On Wed, 5 Jun 2024 at 20:51, Christian Marangi wrote: > > > > Implement support for LED status activity. If the feature is enabled, > > make the defined ACTIVITY LED to signal traffic. > > Would this not just duplicate the activity on the NIC LED? > Yes but most of the time Vendor doesn't ship NIC port with LED attached or even some PHY require additional setup to make the NIC LED blink on traffic. -- Ansuel
Re: [PATCH v2 07/14] net-lwip: add dns command
чт, 6 июн. 2024 г. в 09:29, Ilias Apalodimas :
>
> Hi Jerome,
>
> [...]
>
> > +
> > +static ulong start;
> > +static ip_addr_t host_ipaddr;
> > +static bool done;
> > +
> > +static void do_dns_tmr(void *arg)
> > +{
> > + dns_tmr();
> > +}
> > +
> > +static void dns_cb(const char *name, const ip_addr_t *ipaddr, void *arg)
> > +{
> > + char *var = (char *)arg;
>
> const char *
>
>
> > + char *ipstr = ip4addr_ntoa(ipaddr);
> > +
> > + done = true;
> > +
> > + if (!ipaddr) {
> > + printf("DNS: host not found\n");
> > + host_ipaddr.addr = 0;
> > + return;
> > + }
> > +
> > + if (var)
> > + env_set(var, ipstr);
> > +
> > + printf("%s\n", ipstr);
> > +}
> > +
> > +int do_dns(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
> > +{
> > + bool has_server = false;
> > + ip_addr_t ipaddr;
> > + ip_addr_t ns;
> > + char *nsenv;
> > + char *name;
> > + char *var;
> > + int ret;
> > +
> > + if (argc == 1 || argc > 3)
> > + return CMD_RET_USAGE;
> > +
> > + if (argc >= 2)
> > + name = argv[1];
> > +
> > + if (argc == 3)
> > + var = argv[2];
> > +
> > + dns_init();
> > +
> > + nsenv = env_get("dnsip");
> > + if (nsenv && ipaddr_aton(nsenv, )) {
> > + dns_setserver(0, );
> > + has_server = true;
> > + }
> > +
> > + nsenv = env_get("dnsip2");
> > + if (nsenv && ipaddr_aton(nsenv, )) {
> > + dns_setserver(1, );
> > + has_server = true;
> > + }
> > +
> > + if (!has_server) {
> > + log_err("No valid name server (dnsip/dnsip2)\n");
> > + return CMD_RET_FAILURE;
> > + }
> > +
> > + done = false;
> > +
> > + ret = dns_gethostbyname(name, , dns_cb, var);
> > +
> > + if (ret == ERR_OK) {
> > + dns_cb(name, , var);
> > + } else if (ret == ERR_INPROGRESS) {
> > + start = get_timer(0);
> > + sys_timeout(DNS_RESEND_MS, do_dns_tmr, NULL);
> > + do {
> > + eth_rx();
> > + if (done)
> > + break;
> > + sys_check_timeouts();
> > + if (ctrlc()) {
> > + printf("\nAbort\n");
> > + break;
> > + }
> > + } while (get_timer(start) < DNS_TIMEOUT_MS);
> > + sys_untimeout(do_dns_tmr, NULL);
> > + }
>
> Looking at the lwip code there are other ret values than just ERR_OK,
> ERR_INPROGRESS. Should we have an 'else' handling the rest?
>
+1
And check the return code of eth_rx(), that is int function
and current code for some reason skips this check.
BR,
Maxim.
> > +
> > + if (done && host_ipaddr.addr != 0)
> > + return CMD_RET_SUCCESS;
> > +
> > + return CMD_RET_FAILURE;
> > +}
> > +
> > --
> > 2.40.1
> >
>
> Thanks
> /Ilias
--
Best regards,
Maxim Uvarov
Re: [PATCH 5/7] tftp: implement support for LED status activity
On Wed, 5 Jun 2024 at 20:51, Christian Marangi wrote:
>
> Implement support for LED status activity. If the feature is enabled,
> make the defined ACTIVITY LED to signal traffic.
Would this not just duplicate the activity on the NIC LED?
> Signed-off-by: Christian Marangi
> ---
> net/tftp.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/net/tftp.c b/net/tftp.c
> index 2e335413492..07dea321bb4 100644
> --- a/net/tftp.c
> +++ b/net/tftp.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include "bootp.h"
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -193,6 +194,10 @@ static void new_transfer(void)
> #ifdef CONFIG_CMD_TFTPPUT
> tftp_put_final_block_sent = 0;
> #endif
> +#ifdef CONFIG_LED_STATUS_ACTIVITY_ENABLE
> + status_led_set(CONFIG_LED_STATUS_ACTIVITY,
> + CONFIG_LED_STATUS_BLINKING);
> +#endif
> }
>
> #ifdef CONFIG_CMD_TFTPPUT
> @@ -228,6 +233,10 @@ static void show_block_marker(void)
> {
> ulong pos;
>
> +#ifdef CONFIG_LED_STATUS_ACTIVITY_ENABLE
> + status_led_activity(CONFIG_LED_STATUS_ACTIVITY);
> +#endif
> +
> #ifdef CONFIG_TFTP_TSIZE
> if (tftp_tsize) {
> pos = tftp_cur_block * tftp_block_size +
> @@ -290,6 +299,9 @@ static void tftp_complete(void)
> /* Print hash marks for the last packet received */
> while (tftp_tsize && tftp_tsize_num_hash < 49) {
> putc('#');
> +#ifdef CONFIG_LED_STATUS_ACTIVITY_ENABLE
> + status_led_activity(CONFIG_LED_STATUS_ACTIVITY);
> +#endif
> tftp_tsize_num_hash++;
> }
> puts(" ");
> @@ -302,6 +314,10 @@ static void tftp_complete(void)
> time_start * 1000, "/s");
> }
> puts("\ndone\n");
> +#ifdef CONFIG_LED_STATUS_ACTIVITY_ENABLE
> + status_led_set(CONFIG_LED_STATUS_ACTIVITY,
> + CONFIG_LED_STATUS_OFF);
> +#endif
> if (!tftp_put_active)
> efi_set_bootdev("Net", "", tftp_filename,
> map_sysmem(tftp_load_addr, 0),
> --
> 2.43.0
>
[PATCH 5/6] bootstd: Add a bootmeth for Android
Android boot flow is a bit different than a regular Linux distro.
Android relies on multiple partitions in order to boot.
A typical boot flow would be:
1. Parse the Bootloader Control Block (BCB, misc partition)
2. If BCB requested bootonce-bootloader, start fastboot and wait.
3. If BCB requested recovery or normal android, run the following:
3.a. Get slot (A/B) from BCB
3.b. Run AVB (Android Verified Boot) on boot partitions
3.c. Load boot and vendor_boot partitions
3.d. Load device-tree, ramdisk and boot
The AOSP documentation has more details at [1], [2], [3]
This has been implemented via complex boot scripts such as [4].
However, these boot script are neither very maintainable nor generic.
Moreover, DISTRO_DEFAULTS is being deprecated [5].
Add a generic Android bootflow implementation for bootstd.
For this initial version, only boot image v4 is supported.
[1] https://source.android.com/docs/core/architecture/bootloader
[2] https://source.android.com/docs/core/architecture/partitions
[3] https://source.android.com/docs/core/architecture/partitions/generic-boot
[4]
https://source.denx.de/u-boot/u-boot/-/blob/master/include/configs/meson64_android.h
[5] https://lore.kernel.org/r/all/20230914165615.1058529-17-...@chromium.org/
Signed-off-by: Mattijs Korpershoek
---
MAINTAINERS | 7 +
boot/Kconfig| 14 ++
boot/Makefile | 2 +
boot/bootmeth_android.c | 522
boot/bootmeth_android.h | 27 +++
doc/develop/bootstd.rst | 6 +
6 files changed, 578 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 66783d636e3d..6d2b87720565 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -939,6 +939,13 @@ F: include/bootstd.h
F: net/eth_bootdevice.c
F: test/boot/
+BOOTMETH_ANDROID
+M: Mattijs Korpershoek
+S: Maintained
+T: git https://source.denx.de/u-boot/custodians/u-boot-dfu.git
+F: boot/bootmeth_android.c
+F: boot/bootmeth_android.h
+
BTRFS
M: Marek Behún
R: Qu Wenruo
diff --git a/boot/Kconfig b/boot/Kconfig
index 6f3096c15a6f..5fa6f3b8315d 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -494,6 +494,20 @@ config BOOTMETH_GLOBAL
EFI bootmgr, since they take full control over which bootdevs are
selected to boot.
+config BOOTMETH_ANDROID
+ bool "Bootdev support for Android"
+ depends on X86 || ARM || SANDBOX
+ select ANDROID_AB
+ select ANDROID_BOOT_IMAGE
+ select CMD_BCB
+ select PARTITION_TYPE_GUID
+ select PARTITION_UUIDS
+ help
+ Enables support for booting Android using bootdevs. Android requires
+ multiple partitions (misc, boot, vbmeta, ...) in storage for booting.
+
+ Note that only MMC bootdevs are supported at present.
+
config BOOTMETH_CROS
bool "Bootdev support for Chromium OS"
depends on X86 || ARM || SANDBOX
diff --git a/boot/Makefile b/boot/Makefile
index 84ccfeaecec4..75d1cd46fabf 100644
--- a/boot/Makefile
+++ b/boot/Makefile
@@ -66,3 +66,5 @@ obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_VBE_REQUEST) += vbe_request.o
obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_VBE_SIMPLE) += vbe_simple.o
obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_VBE_SIMPLE_FW) += vbe_simple_fw.o
obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_VBE_SIMPLE_OS) += vbe_simple_os.o
+
+obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_ANDROID) += bootmeth_android.o
diff --git a/boot/bootmeth_android.c b/boot/bootmeth_android.c
new file mode 100644
index ..26d548d2fd6e
--- /dev/null
+++ b/boot/bootmeth_android.c
@@ -0,0 +1,522 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Bootmethod for Android
+ *
+ * Copyright (C) 2024 BayLibre, SAS
+ * Written by Mattijs Korpershoek
+ */
+#define LOG_CATEGORY UCLASS_BOOTSTD
+
+#include
+#include
+#if CONFIG_IS_ENABLED(AVB_VERIFY)
+#include
+#endif
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "bootmeth_android.h"
+
+#define BCB_FIELD_COMMAND_SZ 32
+#define BCB_PART_NAME "misc"
+#define BOOT_PART_NAME "boot"
+#define VENDOR_BOOT_PART_NAME "vendor_boot"
+
+/**
+ * struct android_priv - Private data
+ *
+ * This is read from the disk and recorded for use when the full Android
+ * kernel must be loaded and booted
+ */
+struct android_priv {
+ int boot_mode;
+ char slot[2];
+ u32 header_version;
+};
+
+static int android_check(struct udevice *dev, struct bootflow_iter *iter)
+{
+ /* This only works on mmc devices */
+ if (bootflow_iter_check_mmc(iter))
+ return log_msg_ret("mmc", -ENOTSUPP);
+
+ /* This only works on whole devices, as multiple
+* partitions are needed to boot Android
+*/
+ if (iter->part != 0)
+ return log_msg_ret("mmc part", -ENOTSUPP);
+
+ return 0;
+}
+
+static int scan_boot_part(struct udevice *blk, struct android_priv *priv)
+{
+ struct blk_desc *desc = dev_get_uclass_plat(blk);
+ struct disk_partition
[PATCH 6/6] bootstd: Add test for bootmeth_android
Add a unit test for testing the Android bootmethod.
This requires another mmc image (mmc7) to contain the following partitions:
- misc: contains the Bootloader Control Block (BCB)
- boot_a: contains a fake generic kernel image
- vendor_boot_a: contains a fake vendor_boot image
Also add BOOTMETH_ANDROID as a dependency on sandbox so that we can test
this with:
$ ./test/py/test.py --bd sandbox --build -k test_ut # to build the mmc7.img
$ ./test/py/test.py --bd sandbox --build -k bootflow_android
Signed-off-by: Mattijs Korpershoek
---
arch/sandbox/dts/test.dts | 8 +
configs/sandbox_defconfig | 2 +-
test/boot/bootflow.c | 65 ++--
test/py/tests/test_ut.py | 76 +++
4 files changed, 147 insertions(+), 4 deletions(-)
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index a012f5c4c9ba..5fb5eac862ec 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -43,6 +43,7 @@
mmc4 = "/mmc4";
mmc5 = "/mmc5";
mmc6 = "/mmc6";
+ mmc7 = "/mmc7";
pci0 =
pci1 =
pci2 =
@@ -1129,6 +1130,13 @@
filename = "mmc6.img";
};
+ /* This is used for Android tests */
+ mmc7 {
+ status = "disabled";
+ compatible = "sandbox,mmc";
+ filename = "mmc7.img";
+ };
+
pch {
compatible = "sandbox,pch";
};
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 93b52f2de5cf..bc4398f101a7 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -15,6 +15,7 @@ CONFIG_FIT=y
CONFIG_FIT_RSASSA_PSS=y
CONFIG_FIT_CIPHER=y
CONFIG_FIT_VERBOSE=y
+CONFIG_BOOTMETH_ANDROID=y
CONFIG_LEGACY_IMAGE_FORMAT=y
CONFIG_MEASURED_BOOT=y
CONFIG_BOOTSTAGE=y
@@ -40,7 +41,6 @@ CONFIG_LOG_MAX_LEVEL=9
CONFIG_LOG_DEFAULT_LEVEL=6
CONFIG_DISPLAY_BOARDINFO_LATE=y
CONFIG_STACKPROTECTOR=y
-CONFIG_ANDROID_AB=y
CONFIG_CMD_CPU=y
CONFIG_CMD_LICENSE=y
CONFIG_CMD_SMBIOS=y
diff --git a/test/boot/bootflow.c b/test/boot/bootflow.c
index 4511cfa7f9bf..934c4dcbad2b 100644
--- a/test/boot/bootflow.c
+++ b/test/boot/bootflow.c
@@ -27,6 +27,7 @@
DECLARE_GLOBAL_DATA_PTR;
+extern U_BOOT_DRIVER(bootmeth_android);
extern U_BOOT_DRIVER(bootmeth_cros);
extern U_BOOT_DRIVER(bootmeth_2script);
@@ -518,12 +519,12 @@ BOOTSTD_TEST(bootflow_cmd_boot, UT_TESTF_DM |
UT_TESTF_SCAN_FDT);
* @uts: Unit test state
* @mmc_dev: MMC device to use, e.g. "mmc4". Note that this must remain valid
* in the caller until
- * @bind_cros: true to bind the ChromiumOS bootmeth
+ * @bind_cros: true to bind the ChromiumOS and Android bootmeths
* @old_orderp: Returns the original bootdev order, which must be restored
* Returns 0 on success, -ve on failure
*/
static int prep_mmc_bootdev(struct unit_test_state *uts, const char *mmc_dev,
- bool bind_cros, const char ***old_orderp)
+ bool bind_cros_android, const char ***old_orderp)
{
static const char *order[] = {"mmc2", "mmc1", NULL, NULL};
struct udevice *dev, *bootstd;
@@ -545,12 +546,19 @@ static int prep_mmc_bootdev(struct unit_test_state *uts,
const char *mmc_dev,
"bootmeth_script", 0, ofnode_null(), ));
/* Enable the cros bootmeth if needed */
- if (IS_ENABLED(CONFIG_BOOTMETH_CROS) && bind_cros) {
+ if (IS_ENABLED(CONFIG_BOOTMETH_CROS) && bind_cros_android) {
ut_assertok(uclass_first_device_err(UCLASS_BOOTSTD, ));
ut_assertok(device_bind(bootstd, DM_DRIVER_REF(bootmeth_cros),
"cros", 0, ofnode_null(), ));
}
+ /* Enable the android bootmeths if needed */
+ if (IS_ENABLED(CONFIG_BOOTMETH_ANDROID) && bind_cros_android) {
+ ut_assertok(uclass_first_device_err(UCLASS_BOOTSTD, ));
+ ut_assertok(device_bind(bootstd,
DM_DRIVER_REF(bootmeth_android),
+ "android", 0, ofnode_null(), ));
+ }
+
/* Change the order to include the device */
std = dev_get_priv(bootstd);
old_order = std->bootdev_order;
@@ -589,6 +597,37 @@ static int scan_mmc_bootdev(struct unit_test_state *uts,
const char *mmc_dev,
return 0;
}
+/**
+ * scan_mmc_android_bootdev() - Set up an mmc bootdev so we can access other
+ * distros. Android bootflow might print "ANDROID:*" while scanning
+ *
+ * @uts: Unit test state
+ * @mmc_dev: MMC device to use, e.g. "mmc4"
+ * Returns 0 on success, -ve on failure
+ */
+static int scan_mmc_android_bootdev(struct unit_test_state *uts, const char
*mmc_dev)
+{
+ struct bootstd_priv *std;
+ struct udevice *bootstd;
+ const char **old_order;
+
+ ut_assertok(prep_mmc_bootdev(uts, mmc_dev, true, _order));
+
+
[PATCH 4/6] android: boot: Add set_abootimg_addr() and set_avendor_bootimg_addr()
The only way to configure the load addresses for both bootimg and
vendor_bootimg is by using the "abootimg" command.
If we want to use the C API, there is no equivalent.
Add set_abootimg_addr() and set_avendor_bootimg_addr() so that we can
specify the load address from C.
This can be useful for implementing an Android bootmethod.
Signed-off-by: Mattijs Korpershoek
---
cmd/abootimg.c | 10 ++
include/image.h | 14 ++
2 files changed, 24 insertions(+)
diff --git a/cmd/abootimg.c b/cmd/abootimg.c
index 88c77d999290..33381e22dec2 100644
--- a/cmd/abootimg.c
+++ b/cmd/abootimg.c
@@ -21,11 +21,21 @@ ulong get_abootimg_addr(void)
return (_abootimg_addr == -1 ? image_load_addr : _abootimg_addr);
}
+void set_abootimg_addr(ulong addr)
+{
+ _abootimg_addr = addr;
+}
+
ulong get_avendor_bootimg_addr(void)
{
return _avendor_bootimg_addr;
}
+void set_avendor_bootimg_addr(ulong addr)
+{
+ _avendor_bootimg_addr = addr;
+}
+
static int abootimg_get_ver(int argc, char *const argv[])
{
const struct andr_boot_img_hdr_v0 *hdr;
diff --git a/include/image.h b/include/image.h
index 18e5ced5ab42..6deaf406605e 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1977,6 +1977,13 @@ u32 android_image_get_version(const void *hdr);
*/
ulong get_abootimg_addr(void);
+/**
+ * set_abootimg_addr() - Set Android boot image address
+ *
+ * Return: no returned results
+ */
+void set_abootimg_addr(ulong addr);
+
/**
* get_avendor_bootimg_addr() - Get Android vendor boot image address
*
@@ -1984,6 +1991,13 @@ ulong get_abootimg_addr(void);
*/
ulong get_avendor_bootimg_addr(void);
+/**
+ * set_abootimg_addr() - Set Android vendor boot image address
+ *
+ * Return: no returned results
+ */
+void set_avendor_bootimg_addr(ulong addr);
+
/**
* board_fit_config_name_match() - Check for a matching board name
*
--
2.45.0
[PATCH 3/6] bootstd: Add bootflow_iter_check_mmc() helper
Some bootflows might be able to only boot from MMC devices.
Add a helper function these bootflows can use.
Signed-off-by: Mattijs Korpershoek
---
boot/bootflow.c| 12
include/bootflow.h | 9 +
2 files changed, 21 insertions(+)
diff --git a/boot/bootflow.c b/boot/bootflow.c
index 9aa3179c3881..59d77d2385f4 100644
--- a/boot/bootflow.c
+++ b/boot/bootflow.c
@@ -575,6 +575,18 @@ int bootflow_iter_check_blk(const struct bootflow_iter
*iter)
return -ENOTSUPP;
}
+int bootflow_iter_check_mmc(const struct bootflow_iter *iter)
+{
+ const struct udevice *media = dev_get_parent(iter->dev);
+ enum uclass_id id = device_get_uclass_id(media);
+
+ log_debug("uclass %d: %s\n", id, uclass_get_name(id));
+ if (id == UCLASS_MMC)
+ return 0;
+
+ return -ENOTSUPP;
+}
+
int bootflow_iter_check_sf(const struct bootflow_iter *iter)
{
const struct udevice *media = dev_get_parent(iter->dev);
diff --git a/include/bootflow.h b/include/bootflow.h
index 080ee8501225..6058ddd89b16 100644
--- a/include/bootflow.h
+++ b/include/bootflow.h
@@ -407,6 +407,15 @@ void bootflow_remove(struct bootflow *bflow);
*/
int bootflow_iter_check_blk(const struct bootflow_iter *iter);
+/**
+ * bootflow_iter_check_mmc() - Check that a bootflow uses a MMC device
+ *
+ * This checks the bootdev in the bootflow to make sure it uses a mmc device
+ *
+ * Return: 0 if OK, -ENOTSUPP if some other device is used (e.g. ethernet)
+ */
+int bootflow_iter_check_mmc(const struct bootflow_iter *iter);
+
/**
* bootflow_iter_check_sf() - Check that a bootflow uses SPI FLASH
*
--
2.45.0
[PATCH 2/6] boot: android: Add image_android_get_version()
When reading a boot image header, we may need to retrieve the header
version.
Add a helper function for it.
Signed-off-by: Mattijs Korpershoek
---
boot/image-android.c | 7 ++-
include/image.h | 7 +++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/boot/image-android.c b/boot/image-android.c
index ddd8ffd5e540..4f8fb51585eb 100644
--- a/boot/image-android.c
+++ b/boot/image-android.c
@@ -185,7 +185,7 @@ bool android_image_get_data(const void *boot_hdr, const
void *vendor_boot_hdr,
return false;
}
- if (((struct andr_boot_img_hdr_v0 *)boot_hdr)->header_version > 2) {
+ if (android_image_get_version(boot_hdr) > 2) {
if (!vendor_boot_hdr) {
printf("For boot header v3+ vendor boot image has to be
provided\n");
return false;
@@ -203,6 +203,11 @@ bool android_image_get_data(const void *boot_hdr, const
void *vendor_boot_hdr,
return true;
}
+u32 android_image_get_version(const void *hdr)
+{
+ return ((struct andr_boot_img_hdr_v0 *)hdr)->header_version;
+}
+
static ulong android_image_get_kernel_addr(struct andr_image_data *img_data)
{
/*
diff --git a/include/image.h b/include/image.h
index acffd17e0dfd..18e5ced5ab42 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1963,6 +1963,13 @@ bool is_android_boot_image_header(const void *hdr);
*/
bool is_android_vendor_boot_image_header(const void *vendor_boot_img);
+/**
+ * android_image_get_version() - Retrieve the boot.img version
+ *
+ * Return: Android boot image header version.
+ */
+u32 android_image_get_version(const void *hdr);
+
/**
* get_abootimg_addr() - Get Android boot image address
*
--
2.45.0
