[PATCH 1/1] sandbox: fix sandbox_hub_submit_control_msg()
Avoid incorrect fall through:
A USB_RT_HUB request should not be treated as USB_RT_PORT.
Simplify the coding:
Avoid duplicate debug() statements.
This fixes all -Wimplicit-fallthrough warnings.
Signed-off-by: Heinrich Schuchardt
---
drivers/usb/emul/sandbox_hub.c | 30 +-
1 file changed, 9 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/emul/sandbox_hub.c b/drivers/usb/emul/sandbox_hub.c
index 041ec3772a..084cc16cc6 100644
--- a/drivers/usb/emul/sandbox_hub.c
+++ b/drivers/usb/emul/sandbox_hub.c
@@ -220,13 +220,9 @@ static int sandbox_hub_submit_control_msg(struct udevice
*bus,
udev->status = 0;
udev->act_len = sizeof(*hubsts);
return 0;
+ }
}
- default:
- debug("%s: rx ctl requesttype=%x, request=%x\n",
- __func__, setup->requesttype,
- setup->request);
- break;
- }
+ break;
case USB_RT_PORT | USB_DIR_IN:
switch (setup->request) {
case USB_REQ_GET_STATUS: {
@@ -239,13 +235,12 @@ static int sandbox_hub_submit_control_msg(struct udevice
*bus,
udev->status = 0;
udev->act_len = sizeof(*portsts);
return 0;
+ }
}
- }
- default:
- debug("%s: rx ctl requesttype=%x, request=%x\n",
- __func__, setup->requesttype, setup->request);
break;
}
+ debug("%s: rx ctl requesttype=%x, request=%x\n",
+ __func__, setup->requesttype, setup->request);
} else if (pipe == usb_sndctrlpipe(udev, 0)) {
switch (setup->requesttype) {
case USB_RT_PORT:
@@ -263,7 +258,7 @@ static int sandbox_hub_submit_control_msg(struct udevice
*bus,
debug(" ** Invalid feature\n");
}
return ret;
- }
+ }
case USB_REQ_CLEAR_FEATURE: {
int port;
@@ -279,18 +274,11 @@ static int sandbox_hub_submit_control_msg(struct udevice
*bus,
}
udev->status = 0;
return 0;
+ }
}
- default:
- debug("%s: tx ctl requesttype=%x, request=%x\n",
- __func__, setup->requesttype,
- setup->request);
- break;
- }
- default:
- debug("%s: tx ctl requesttype=%x, request=%x\n",
- __func__, setup->requesttype, setup->request);
- break;
}
+ debug("%s: tx ctl requesttype=%x, request=%x\n",
+ __func__, setup->requesttype, setup->request);
}
debug("pipe=%lx\n", pipe);
--
2.39.2
Re: [RFC PATCH v7 15/23] cli: add hush 2021 as parser for run_command*()
Hi Francis, On Fri, 31 Mar 2023 at 08:49, Francis Laniel wrote: > > Enables using, in code, hush 2021 as parser for run_command function family. > It also enables the command run to be used by CLI user of hush 2021. > > Signed-off-by: Francis Laniel > --- > common/cli.c | 63 -- > common/cli_hush_upstream.c | 2 +- > 2 files changed, 48 insertions(+), 17 deletions(-) > Reviewed-by: Simon Glass
Re: [RFC PATCH v7 12/23] cli: Enables using hush 2021 parser as command line parser
On Fri, 31 Mar 2023 at 08:49, Francis Laniel wrote: > > If one defines HUSH_2021_PARSER, it is then possible to use 2021 parser with: > => parser get > old > => parser set 2021 > 2021> parser get > 2021 > > Signed-off-by: Francis Laniel > --- > cmd/parser.c | 7 - > common/cli.c | 38 +++ > common/cli_hush_2021.c| 3 ++ > common/cli_hush_upstream.c| 46 +--- > include/asm-generic/global_data.h | 4 +++ > include/cli_hush.h| 51 +-- > 6 files changed, 135 insertions(+), 14 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH 4/8] tools: prelink-riscv: Unmap the ELF image when done
On Fri, 31 Mar 2023 at 01:37, Bin Meng wrote: > > The codes forget to call munmap() to unmap the ELF image that was > mapped by previous mmap(). > > Signed-off-by: Bin Meng > --- > > tools/prelink-riscv.c | 2 ++ > 1 file changed, 2 insertions(+) Reviewed-by: Simon Glass
Re: WIP: Signing TI x509 certificates using binman
Hi Neha, On Sat, 1 Apr 2023 at 00:14, Neha Malcom Francis wrote: > > Hi Simon > > On 31/03/23 02:01, Simon Glass wrote: > > Hi Neha, > > > > On Fri, 24 Mar 2023 at 22:28, Neha Malcom Francis wrote: > >> > >> Hi Simon, > >> > >> Before I roll out the entire series that works for packaging K3 > >> bootloader images, wanted to get some reviews and comments regarding the > >> implementation of the signing etype [1] . I believe I've taken into > >> consideration what we've discussed earlier [2]. > >> > >> Let me know your thoughts. The tree is also WIP, and was mainly designed > >> for testing the signing etype on two of the devices. I will add the > >> remaining and refine the series based on the next comments. > > > > Yes this looks reasonable to me. For the openssl method, can you > > create a new 'real' method and put the cert stuff in there instead of > > using a 'custom' one? It seems to have a lot in common with what is > > there. We should really have an internal cert-generator method in that > > class, with other functions in that class doing appropriate things. I > > am looking for code reuse here, as well as clear indication of what > > the cert is for or does. > > So you're suggesting to include the config creation within the openssl > btool, am I right? For example methods to generate a config, add section > to a config, add extension to a section of a config... etc? I can take a > look at implementing this if this is what you have suggested. I am more thinking that your use case could be a new method in that file, with arguments that suit your case, but with common code to create a cert of the correct type. That means pulling out the existing cert creation into a new (internal) function in that btool that does both types of cert. For the CN args I think a dict would be suitable to pass in the settings. I'm trying to avoid people passing in a cert every time, since that is going to create a lot of code duplication and it will be hard to take advantage of common algos. > > If most of the cert is the same, you could > > pass a dict for the CN stuff, perhaps? > > > > What is the taml for? It is hard to tell, from the example provided. > Did you mean YAML? If so in the patch I linked, I don't think I had a > example for that. Could you point out what exactly you're asking about? Well I am wondering why it is in the code...is there a yaml file that you need to ingest and process? What is it for? ...actually I see the yaml files in your tree mentioned below. Does this come out of some other tool? > > > > > Do you have a .dts which shows the full image for a board? I think the > > cert stuff looks right, but it's a bit hard to tell. > > Yes, in the same github link I have the whole tree [3] that contains > DTBs for couple of the devices [4] and [5], please have a look and let > me know (I might force push a few changes in the next couple of days, so > better to look from the tree) OK I see. Yes it looks pretty good to me. > > > > > When sending the patches please do do follow the function-commenting > > style and make sure that it is clear what each arg means. E.g. I saw a > > hash integer which I assume is used to pass 256 or 384 or 512 for sha > > hashing. It should indicate the possible values / meaning in the arg. > > In fact, in that case, it might be better to pass a string like > > 'sha256'. > > Yes, you're right. Will address that when sending the patch series > completely. OK > > > > > Anyway, apart from my questions it seems good. > > > > Regards, > > Simon > > > >> > >> [1] > >> https://github.com/nehamalcom/u-boot/commit/ea7413ed5864340bd6f01e704e8bdcc073a7896b#diff-efb03d61a324724c4f86bf42b45c4e4e614cab18e1b3184f63721d62280a11b5 > >> > >> [2] > >> https://patchwork.ozlabs.org/project/uboot/patch/20230224120340.587786-1-n-fran...@ti.com/ > >> > >> -- > >> Thanking You > >> Neha Malcom Francis > > [3] https://github.com/nehamalcom/u-boot/commits/ti-secure-functionality > [4] > https://github.com/nehamalcom/u-boot/commit/dda1f9caf436df59c576466f35262df90aa1c0af > Regards, Simon
Re: [PATCH 29/33] doc: boards: amlogic: update documentation for WeTek Core2
Hi Christian, On Tue, 21 Mar 2023 at 18:11, Christian Hewitt wrote: > > > > On 20 Mar 2023, at 10:40 pm, Simon Glass wrote: > > > > Hi Christian, > > > > On Tue, 21 Mar 2023 at 06:05, Christian Hewitt > > wrote: > >> > >> Improve documentation. > >> > >> Signed-off-by: Christian Hewitt > >> --- > >> doc/board/amlogic/wetek-core2.rst | 83 +-- > >> 1 file changed, 47 insertions(+), 36 deletions(-) > > > > This should really move to binman. Would you like to take a look? > > > > I sent a patch for this a while ago but it needs something to review > > and try out. > > > > https://patchwork.ozlabs.org/project/uboot/patch/20220110031413.1970836-39-...@chromium.org/ > > > > I am happy to do more on it as needed. > > Hello Simon, > > For now this is just a cleanup but longer-term (won’t be quick) I can > take a look. Do you have that series rebased against current and in a > repo somewhere for easier cherry-picking? > OK I sent a v2 patch. Regards, Simon
Re: [RFC PATCH v7 11/23] cmd: Add new parser command
Hi Francis, On Fri, 31 Mar 2023 at 08:49, Francis Laniel wrote: > > This command can be used to print the current parser with 'parser print'. > It can also be used to set the current parser with 'parser set'. > For the moment, only one value is valid for set: old. > > Signed-off-by: Francis Laniel > --- > cmd/Makefile | 2 + > cmd/parser.c | 120 +++ > common/cli.c | 3 +- > 3 files changed, 124 insertions(+), 1 deletion(-) > create mode 100644 cmd/parser.c > Reviewed-by: Simon Glass But I wonder whether 'cli' might be a better name for this command? We use cli everywhere else. Also can you add doc/usage for this? Regards, Simon
Re: [RFC PATCH v7 21/23] test: hush: Fix loop tests for hush 2021
On Fri, 31 Mar 2023 at 08:50, Francis Laniel wrote: > > Modifies return code got from while loop as hush 2021 always returns 0 from > while loop. > > Signed-off-by: Francis Laniel > --- > test/hush/loop.c | 34 ++ > 1 file changed, 30 insertions(+), 4 deletions(-) > Reviewed-by: Simon Glass
Re: [RFC PATCH v7 17/23] test: hush: Fix variable expansion tests for hush 2021
On Fri, 31 Mar 2023 at 08:50, Francis Laniel wrote: > > Modifies the expected result for hush 2021. > Indeed, there were bugs in actual U-Boot hush which were fixed in upstream > Busybox. > As hush 2021 is based on upstream Busybox, these bugs no longer exist. > > Signed-off-by: Francis Laniel > --- > test/hush/dollar.c | 79 -- > 1 file changed, 69 insertions(+), 10 deletions(-) Reviewed-by: Simon Glass
Re: [RFC PATCH v7 16/23] test: hush: Fix instructions list tests for hush 2021
On Fri, 31 Mar 2023 at 08:49, Francis Laniel wrote: > > Modifies the expected result for hush 2021. > Indeed, there were bugs in actual U-Boot hush which were fixed in upstream > Busybox. > As hush 2021 is based on upstream Busybox, these bugs no longer exist. > > Signed-off-by: Francis Laniel > --- > test/hush/list.c | 69 +--- > 1 file changed, 65 insertions(+), 4 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH 1/3] net: support being a TCP server to unblock TCP fastboot
On Wed, 29 Mar 2023 at 09:31, Dmitrii Merkurev wrote: > > Make following changes to unblock TCP fastboot support: > > 1. Implement being a TCP server support > 2. Introduce dedicated TCP traffic handler (get rid of UDP signature) > 3. Ensure seq_num and ack_num are respected in net_send_tcp_packet > function (make sure existing wget_cmd code is reflected with the fix) > > Signed-off-by: Dmitrii Merkurev > Cc: Ying-Chun Liu (PaulLiu) > Cc: Simon Glass > Сс: Joe Hershberger > Сс: Ramon Fried > --- > > include/net/tcp.h | 16 +-- > net/tcp.c | 115 +++--- > net/wget.c| 43 - > 3 files changed, 90 insertions(+), 84 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH 2/6] virtio: pci: Tear down VQs in virtio_pci_reset()
On Thu, 30 Mar 2023 at 03:26, Ying-Chun Liu (PaulLiu) wrote: > > From: Will Deacon > > The pages backing the virtqueues for virtio PCI devices are not freed > on reset, despite the virtqueue structure being freed as part of the > driver '->priv_auto' destruction at ->remove() time. > > Call virtio_pci_del_vqs() from virtio_pci_reset() to free the virtqueue > pages before freeing the virtqueue structure itself. > > Signed-off-by: Will Deacon > [ Paul: pick from the Android tree. Rebase to the upstream ] > Signed-off-by: Ying-Chun Liu (PaulLiu) > Cc: Bin Meng > Link: > https://android.googlesource.com/platform/external/u-boot/+/5ed54ccd83cbffd0d8719ce650604b4e44b5b0d8 > --- > drivers/virtio/virtio_pci_modern.c | 38 +++--- > 1 file changed, 19 insertions(+), 19 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH v4] test_vboot.py: include test of fdt_add_pubkey tool
On Mon, 20 Mar 2023 at 13:28, Ivan Mikhaylov wrote: > > From: Roman Kopytin > > Add test_fdt_add_pubkey test which provides simple functionality test > which contains such steps: > create DTB and FIT files > add keys with fdt_add_pubkey to DTB > sign FIT image > check with fit_check_sign that keys properly added to DTB file > > Signed-off-by: Roman Kopytin > Signed-off-by: Ivan Mikhaylov > Cc: Rasmus Villemoes > --- > test/py/tests/test_vboot.py | 200 ++-- > 1 file changed, 166 insertions(+), 34 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH 3/3] net: share fastboot boot handle logic between transports
On Wed, 29 Mar 2023 at 09:31, Dmitrii Merkurev wrote: > > Introduce reboot, boot and continue commands support to > TCP fastboot by moving existing UDP logic into the common module. > > Cc: Ying-Chun Liu (PaulLiu) > Cc: Simon Glass > Сс: Joe Hershberger > Сс: Ramon Fried > Signed-off-by: Dmitrii Merkurev > --- > > drivers/fastboot/fb_common.c | 32 > include/fastboot.h | 9 + > net/fastboot_tcp.c | 5 - > net/fastboot_udp.c | 29 + > 4 files changed, 46 insertions(+), 29 deletions(-) Reviewed-by: Simon Glass
Re: [RFC PATCH v7 09/23] cli: Add menu for hush parser
On Fri, 31 Mar 2023 at 08:48, Francis Laniel wrote: > > For the moment, the menu contains only entry: HUSH_OLD_PARSER which is the > default. It seems to contain both with this patch? > The goal is to prepare the field to add a new hush parser which guarantees > actual behavior is still correct. > > Signed-off-by: Francis Laniel > --- > cmd/Kconfig | 21 + > common/Makefile | 3 ++- > 2 files changed, 23 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass
Re: [PATCH 5/6] virtio: Allocate bounce buffers for devices with VIRTIO_F_IOMMU_PLATFORM
On Thu, 30 Mar 2023 at 03:27, Ying-Chun Liu (PaulLiu) wrote: > > From: Will Deacon > > In preparation for bouncing virtio data for devices advertising the > VIRTIO_F_IOMMU_PLATFORM feature, allocate an array of bounce buffer > structures in the vring, one per descriptor. > > Signed-off-by: Will Deacon > [ Paul: pick from the Android tree. Rebase to the upstream ] > Signed-off-by: Ying-Chun Liu (PaulLiu) > Cc: Bin Meng > Link: > https://android.googlesource.com/platform/external/u-boot/+/3e052749e7c50c4c1a6014e645ae3b9be3710c07 > --- > drivers/virtio/virtio_ring.c | 25 - > include/virtio_ring.h| 5 - > 2 files changed, 24 insertions(+), 6 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH v3 8/9] rockchip: Move to standard boot
Hi Jonas, On Mon, 20 Mar 2023 at 20:54, Jonas Karlman wrote: > > Hi Simon, > On 2023-03-20 06:48, Simon Glass wrote: > > Drop the distro-boot scripts and use standard boot instead. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v3: > > - Update rk3588 boards too > > > > Changes in v2: > > - Add new patch to move rockchip to standard boot > > > > arch/arm/Kconfig | 1 - > > include/configs/px30_common.h | 4 +-- > > include/configs/rk3036_common.h | 5 +-- > > include/configs/rk3066_common.h | 5 +-- > > include/configs/rk3128_common.h | 4 +-- > > include/configs/rk3188_common.h | 5 +-- > > include/configs/rk322x_common.h | 5 +-- > > include/configs/rk3288_common.h | 5 +-- > > include/configs/rk3308_common.h | 4 +-- > > include/configs/rk3328_common.h | 4 +-- > > include/configs/rk3368_common.h | 5 +-- > > include/configs/rk3399_common.h | 2 +- > > include/configs/rk3568_common.h | 4 +-- > > include/configs/rk3588_common.h | 4 +-- > > include/configs/rockchip-common.h | 58 --- > > include/configs/rv1108_common.h | 3 +- > > 16 files changed, 14 insertions(+), 104 deletions(-) > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > index e324387ad057..5fe21413d6bc 100644 > > --- a/arch/arm/Kconfig > > +++ b/arch/arm/Kconfig > > @@ -1956,7 +1956,6 @@ config ARCH_ROCKCHIP > > imply ADC > > imply CMD_DM > > imply DEBUG_UART_BOARD_INIT > > - imply DISTRO_DEFAULTS if !ROCKCHIP_RK3399 > > imply FAT_WRITE > > imply SARADC_ROCKCHIP > > imply SPL_SYSRESET > > diff --git a/include/configs/px30_common.h b/include/configs/px30_common.h > > index c0896e5f6281..a4c8bfebdf84 100644 > > --- a/include/configs/px30_common.h > > +++ b/include/configs/px30_common.h > > @@ -25,12 +25,10 @@ > > "kernel_addr_c=0x03e8\0" \ > > "ramdisk_addr_r=0x0a20\0" > > > > -#include > > #define CFG_EXTRA_ENV_SETTINGS \ > > ENV_MEM_LAYOUT_SETTINGS \ > > "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \ > > "partitions=" PARTS_DEFAULT \ > > - ROCKCHIP_DEVICE_SETTINGS \ > > - BOOTENV > > + ROCKCHIP_DEVICE_SETTINGS > > Should BOOTENV not be replaced with: > > "boot_targets=" BOOT_TARGETS "\0" > > as was done in the initial rk3399 conversion? > > Above applies to similar changes in this patch. > > Patch nr 7 has not hit the list yet, will runtime test on the SoCs I > have access to once I have the complete series. Thanks, yes I fixed that and sent a new series. But it needs another spin as I misunderstood something. Regards, Simon
Re: [PATCH 6/6] virtio: Use bounce buffers when VIRTIO_F_IOMMU_PLATFORM is set
On Thu, 30 Mar 2023 at 03:27, Ying-Chun Liu (PaulLiu) wrote: > > From: Will Deacon > > Devices advertising the VIRTIO_F_IOMMU_PLATFORM feature require > platform-specific handling to configure their DMA transactions. > > When handling virtio descriptors for such a device, use bounce > buffers to ensure that the underlying buffers are always aligned > to and padded to PAGE_SIZE in preparation for platform specific > handling at page granularity. > > Signed-off-by: Will Deacon > [ Paul: pick from the Android tree. Rebase to the upstream ] > Signed-off-by: Ying-Chun Liu (PaulLiu) > Cc: Bin Meng > Link: > https://android.googlesource.com/platform/external/u-boot/+/1eff171e613ee67dca71dbe97be7282e2db17011 > --- > drivers/virtio/virtio_ring.c | 48 +++- > 1 file changed, 47 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass
Re: [PATCH 2/3] net: add fastboot TCP support
Hi Dmitrii,
On Wed, 29 Mar 2023 at 09:31, Dmitrii Merkurev wrote:
>
> Known limitations are
> 1. fastboot reboot doesn't work (answering OK but not rebooting)
> 2. flashing isn't supported (TCP transport only limitation)
>
> The command syntax is
> fastboot tcp
>
> Signed-off-by: Dmitrii Merkurev
> Cc: Ying-Chun Liu (PaulLiu)
> Cc: Simon Glass
> Сс: Joe Hershberger
> Сс: Ramon Fried
> ---
>
> MAINTAINERS| 6 +-
> cmd/fastboot.c | 25 +++-
> drivers/fastboot/Kconfig | 7 +
> drivers/fastboot/fb_common.c | 1 -
> include/net.h | 3 +-
> include/net/fastboot_tcp.h | 14 ++
> include/net/{fastboot.h => fastboot_udp.h} | 2 +-
> net/Makefile | 3 +-
> net/fastboot_tcp.c | 143 +
> net/{fastboot.c => fastboot_udp.c} | 4 +-
> net/net.c | 17 ++-
> 11 files changed, 210 insertions(+), 15 deletions(-)
> create mode 100644 include/net/fastboot_tcp.h
> rename include/net/{fastboot.h => fastboot_udp.h} (91%)
> create mode 100644 net/fastboot_tcp.c
> rename net/{fastboot.c => fastboot_udp.c} (99%)
Reviewed-by: Simon Glass
nits and a question below
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 91d40ea4b6..501d1147d9 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -978,10 +978,12 @@ F:cmd/fastboot.c
> F: doc/android/fastboot*.rst
> F: include/fastboot.h
> F: include/fastboot-internal.h
> -F: include/net/fastboot.h
> +F: include/net/fastboot_tcp.h
> +F: include/net/fastboot_udp.h
> F: drivers/fastboot/
> F: drivers/usb/gadget/f_fastboot.c
> -F: net/fastboot.c
> +F: net/fastboot_tcp.c
> +F: net/fastboot_udp.c
> F: test/dm/fastboot.c
>
> FPGA
> diff --git a/cmd/fastboot.c b/cmd/fastboot.c
> index 97dc02ce74..3d5ff951eb 100644
> --- a/cmd/fastboot.c
> +++ b/cmd/fastboot.c
> @@ -26,7 +26,7 @@ static int do_fastboot_udp(int argc, char *const argv[],
> return CMD_RET_FAILURE;
> }
>
> - err = net_loop(FASTBOOT);
> + err = net_loop(FASTBOOT_UDP);
>
> if (err < 0) {
> printf("fastboot udp error: %d\n", err);
> @@ -36,6 +36,26 @@ static int do_fastboot_udp(int argc, char *const argv[],
> return CMD_RET_SUCCESS;
> }
>
> +static int do_fastboot_tcp(int argc, char *const argv[],
> + uintptr_t buf_addr, size_t buf_size)
> +{
> + int err;
> +
> + if (!IS_ENABLED(CONFIG_TCP_FUNCTION_FASTBOOT)) {
> + pr_err("Fastboot TCP not enabled\n");
> + return CMD_RET_FAILURE;
> + }
> +
> + err = net_loop(FASTBOOT_TCP);
> +
> + if (err < 0) {
> + printf("fastboot tcp error: %d\n", err);
> + return CMD_RET_FAILURE;
> + }
> +
> + return CMD_RET_SUCCESS;
> +}
> +
> static int do_fastboot_usb(int argc, char *const argv[],
>uintptr_t buf_addr, size_t buf_size)
> {
> @@ -141,7 +161,8 @@ NXTARG:
>
> if (!strcmp(argv[1], "udp"))
> return do_fastboot_udp(argc, argv, buf_addr, buf_size);
> -
> + if (!strcmp(argv[1], "tcp"))
> + return do_fastboot_tcp(argc, argv, buf_addr, buf_size);
> if (!strcmp(argv[1], "usb")) {
> argv++;
> argc--;
> diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig
> index eefa34779c..c07df8369e 100644
> --- a/drivers/fastboot/Kconfig
> +++ b/drivers/fastboot/Kconfig
> @@ -28,6 +28,13 @@ config UDP_FUNCTION_FASTBOOT_PORT
> help
> The fastboot protocol requires a UDP port number.
>
> +config TCP_FUNCTION_FASTBOOT
> + depends on NET
> + select FASTBOOT
> + bool "Enable fastboot protocol over TCP"
> + help
> + This enables the fastboot protocol over TCP.
Please can you add some more help, like a link to the protocol and
what it is used for?
> +
> if FASTBOOT
>
> config FASTBOOT_BUF_ADDR
> diff --git a/drivers/fastboot/fb_common.c b/drivers/fastboot/fb_common.c
> index 57b6182c46..dde3cda78f 100644
> --- a/drivers/fastboot/fb_common.c
> +++ b/drivers/fastboot/fb_common.c
> @@ -15,7 +15,6 @@
> #include
> #include
> #include
> -#include
>
> /**
> * fastboot_buf_addr - base address of the fastboot download buffer
> diff --git a/include/net.h b/include/net.h
> index 399af5e064..63daab3731 100644
> --- a/include/net.h
> +++ b/include/net.h
> @@ -505,7 +505,8 @@ extern int net_restart_wrap; /* Tried all
> network devices */
>
> enum proto_t {
> BOOTP, RARP, ARP, TFTPGET, DHCP, PING, PING6, DNS, NFS, CDP, NETCONS,
> - SNTP, TFTPSRV, TFTPPUT, LINKLOCAL, FASTBOOT, WOL, UDP, NCSI, WGET
> + SNTP, TFTPSRV, TFTPPUT, LINKLOCAL, FASTBOOT_UDP, FASTBOOT_TCP, WOL,
> + UDP, NCSI, WGET
> };
Re: [RFC PATCH v7 10/23] global_data.h: add GD_FLG_HUSH_OLD_PARSER flag
On Fri, 31 Mar 2023 at 08:49, Francis Laniel wrote: > > This flag is used to indicate we are using the hush parser. > > Signed-off-by: Francis Laniel > --- > common/cli.c | 2 ++ > include/asm-generic/global_data.h | 4 > 2 files changed, 6 insertions(+) Reviewed-by: Simon Glass
Re: [RFC PATCH v7 04/23] test: hush: Test hush variable expansion
Hi Francis,
On Fri, 31 Mar 2023 at 08:48, Francis Laniel
wrote:
>
> Verifies shell variables are replaced by their values.
>
> Signed-off-by: Francis Laniel
> ---
> test/hush/Makefile | 1 +
> test/hush/dollar.c | 167 +++
> test/py/tests/test_ut.py | 8 +-
> 3 files changed, 175 insertions(+), 1 deletion(-)
> create mode 100644 test/hush/dollar.c
>
Reviewed-by: Simon Glass
nit below
> diff --git a/test/hush/Makefile b/test/hush/Makefile
> index a3c9ae5106..feb4f71956 100644
> --- a/test/hush/Makefile
> +++ b/test/hush/Makefile
> @@ -5,3 +5,4 @@
>
> obj-y += cmd_ut_hush.o
> obj-y += if.o
> +obj-y += dollar.o
> diff --git a/test/hush/dollar.c b/test/hush/dollar.c
> new file mode 100644
> index 00..27feda2970
> --- /dev/null
> +++ b/test/hush/dollar.c
> @@ -0,0 +1,167 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * (C) Copyright 2021
> + * Francis Laniel, Amarula Solutions, francis.lan...@amarulasolutions.com
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static int hush_test_simple_dollar(struct unit_test_state *uts)
> +{
> + console_record_reset_enable();
> + ut_assertok(run_command("echo $dollar_foo", 0));
> + ut_assert_nextline("%s", "");
ut_assert_nextline_empty();
> + ut_assert_console_end();
> +
> + ut_assertok(run_command("echo ${dollar_foo}", 0));
> + ut_assert_nextline("%s", "");
> + ut_assert_console_end();
> +
[..]
Regards,
Simon
Re: Newer U-Boot version throwing "Bootstage space exhasuted" with FIT image
Hi, On Sat, 1 Apr 2023 at 02:57, wrote: > > Hi, > > I changed from v2020.10 to v2022.10 and suddenly I get a bunch of "Bootstage > space exhasuted" messages during bootm. > > reloc pc : [] is memcpy() > > It evens triggers a reset. Older version works just fine: > > Sign value: unavailable > Timestamp:unavailable >Verifying Hash Integrity ... sha256+ OK > Bootstage space exhasuted > Bootstage space exhasuted > Bootstage space exhasuted > Bootstage space exhasuted >Loading fdt from 0xc272de94 to 0xc400 > Bootstage space exhasuted >Booting using the fdt blob at 0xc400 >Loading Kernel Image >kernel loaded at 0xc0008000, end = 0xc0735c80 > Bootstage space exhasuted > Bootstage space exhasuted >Loading Ramdisk to cfd23000, end c105 ... OK >Loading Device Tree to cfd1, end cfd22375 ... OK > Bootstage space exhasuted > Bootstage space exhasuted > > Starting kernel ... > > data abort > pc : [] lr : [<>] > reloc pc : []lr : [] > sp : fbf2786c ip : fp : 0001 > r10: c2d8 r9 : fbf37eb0 r8 : > r7 : r6 : r5 : e28ff010 r4 : > r3 : r2 : 0a10 r1 : fdfabb14 r0 : 2ffc0020 > Flags: nzCv IRQs off FIQs off Mode SVC_32 (T) > Code: f891 f03c f891 f05c (f891) f07c > Resetting CPU ... > > resetting ... Do you know which board it is? It would help to produce a full console trace. Regards, Simon
Re: [PATCH 4/6] virtio: Add helper functions to attach/detach vring descriptors
On Thu, 30 Mar 2023 at 03:26, Ying-Chun Liu (PaulLiu) wrote: > > From: Will Deacon > > Move the attach and detach logic for manipulating vring descriptors > out into their own functions so that we can later extend these to > bounce the data for devices with VIRTIO_F_IOMMU_PLATFORM set. > > Signed-off-by: Will Deacon > [ Paul: pick from the Android tree. Rebase to the upstream ] > Signed-off-by: Ying-Chun Liu (PaulLiu) > Cc: Bin Meng > Link: > https://android.googlesource.com/platform/external/u-boot/+/f73258a4bfe968c5f935db45f2ec5cc0104ee796 > --- > drivers/virtio/virtio_ring.c | 6 ++ > 1 file changed, 6 insertions(+) > Reviewed-by: Simon Glass
Re: [PATCH 1/6] virtio: Expose VIRTIO_F_IOMMU_PLATFORM in device features
On Thu, 30 Mar 2023 at 03:25, Ying-Chun Liu (PaulLiu) wrote: > > From: Will Deacon > > If we detect the VIRTIO_F_IOMMU_PLATFORM transport feature for a device, > then expose it in the device features. > > Signed-off-by: Will Deacon > [ Paul: pick from the Android tree. Rebase to the upstream ] > Signed-off-by: Ying-Chun Liu (PaulLiu) > Cc: Bin Meng > Link: > https://android.googlesource.com/platform/external/u-boot/+/9693bd26bfcfe77d6a1295a561420e08c5daf019 > --- > drivers/virtio/virtio-uclass.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Simon Glass
Re: [PATCH 3/6] virtio: Allocate virtqueue in page-size units
On Thu, 30 Mar 2023 at 03:26, Ying-Chun Liu (PaulLiu) wrote: > > From: Will Deacon > > In preparation for explicit bouncing of virtqueue pages for devices > advertising the VIRTIO_F_IOMMU_PLATFORM feature, introduce a couple > of wrappers around virtqueue allocation and freeing operations, > ensuring that buffers are handled in terms of page-size units. > > Signed-off-by: Will Deacon > [ Paul: pick from the Android tree. Rebase to the upstream ] > Signed-off-by: Ying-Chun Liu (PaulLiu) > Cc: Bin Meng > Link: > https://android.googlesource.com/platform/external/u-boot/+/b4bb5227d4cf4fdfcd8b4e1ff2692d3a54d1482a > --- > drivers/virtio/virtio_ring.c | 24 > include/virtio_ring.h| 16 +--- > 2 files changed, 29 insertions(+), 11 deletions(-) > Reviewed-by: Simon Glass
Re: [v4 0/7] Fix Rockchip RK3399 bootstd migration
Hi Peter, On Fri, 31 Mar 2023 at 21:40, Peter Robinson wrote: > > Hi Simon, > > > > > > > > I took a look at Simon's v3 series to fix the rk3399 bootstd > > > > > > > migration, > > > > > > > and it changed too much for everything else. I took about half of > > > > > > > that > > > > > > > series and then reworked a few things. Now only rk3399 platforms > > > > > > > change > > > > > > > at all and aside from bootcmd changes, the only thing is they now > > > > > > > disable true/test/sysboot/showvar/false/exit commands as those > > > > > > > were > > > > > > > being pulled in from distro and now we don't set that flag. I > > > > > > > think the > > > > > > > way I changed how we enable BOOTSTD_DEFAULTS should make it > > > > > > > easier to > > > > > > > perform more SoC migrations. > > > > > > > > > > > > Thanks for digging into this. I haven't seen any comments on the rpi > > > > > > conversion, so perhaps people could test that? > > > > > > > > > > I was planning on looking at that once 2023.04 was out but TBH I have > > > > > wasted so much time over the last few cycles dealing with regressions > > > > > through a bunch of these series that I now have so little time for > > > > > enhancements I now shy away. I know a lot of these series should > > > > > improve things in the future but they don't feel like when there's > > > > > unnecessary changes for things that are clearly untested. > > > > > > > > I too am unhappy with how some of these have gone. The _intent_ here is > > > > that getting the current "boot generic distro" framework is complex / > > > > error prone, and we can do better. Unfortunately the first set of > > > > platforms to switch to this are Rockchip and I think there was overlap > > > > there with platforms that got broken at the end of the v2023.01 cycle to > > > > fix other platforms, and then those sets of platforms flipped early in > > > > v2023.04 and took until -rc2? to get resolved. Which was less than > > > > ideal. > > > > > > > > > There's also a lot of change for changes sake, for example the > > > > > rockchips ATF binaries needed is called bl31.elf by the default output > > > > > of the ATF build process, for others it's bl31.bin, binman for what > > > > > ever reason has changed that to be atf-bl31, now I have to change the > > > > > entire build process to be able to work out what is what on a board by > > > > > board basis to be able to set the required variable to be able to > > > > > specify the ATF where previously it "just worked (tm)". I suppose > > > > > there is some perceived goal and improvement here but with both my > > > > > "U-Boot device maintainer" and "distro maintainer" hats on, both of > > > > > which I do in my own spare time, I currently fail to see it and I end > > > > > up. > > > > > > > > I wish I knew where to talk to with ATF / TF-A to get some agreed upon > > > > naming scheme going as one of the things that is very frustrating is > > > > getting the names and combinations of everything else that's required > > > > Just Right for every chip. And feedback that things aren't working is > > > > appreciated, since we do need to make things easier. > > > > > > In all of the various make_fit_atf.py the various vendors specified > > > them, this is the case for the rockchip one [1]. This is the case for > > > the Allwinner boards [2] but the rockchip ports have missed this so it > > > also should be fixed for GA. > > Can you do a patch to fix this regression please and then specify the > correct pieces in the binman section then? Yes I think this should be fixed. We don't have any Rockchip maintainers / contributors on this thread. Would you like to start a new one, or add them to this thread? > > > > A side point is that binman should not be storing firmware build > > > specifics in the device tree which is a means of describing the > > > hardware, This really needs to be fixed as it really isn't the right > > > place for that sort of things. I suspect a file in arch/arm/mach- > > > is likely a better location, or if it's board specific in the board/ > > > sub directory. > > > > Sorry, I don't agree with that at all. We store configuration > > information in devicetree in firmware as this seems to be best format > > for it, particularly with the growing number of firmware components > > that need to share this information at runtime. The layout of firmware > > is an important part of the system. We are still figuring out the > > flows though. Also I have not attempted to upstream the binman > > binding. I am very open to ideas on how best to do that. > > Rob what's your thoughts on the binman firmware build pieces being in > device tree and the process on upstreaming the bindings? It might be easier for Rob to comment on an actual proposal, which I have not done. It is on my radar though. Regards, Simon > > Regards, > Peter > > > > [1] > > > https://source.denx.de/u-boot/u-boot/-/blob/v2023.01/arch/arm/mach-rockchip/make_fit_a
Re: [PATCH v5 8/8] bootstd: Enable BOOTSTD_DEFAULTS by default
Hi Tom, On Sat, 1 Apr 2023 at 07:00, Tom Rini wrote: > > On Fri, Mar 31, 2023 at 10:26:01AM +1300, Simon Glass wrote: > > > This is needed to enable the boot command used to start standard boot. > > Enable it by default. This brings in quite a few features, mostly in > > common with DISTRO_DEFAULTS > > > > Exclude boards which have what looks like a custom boot command: > > > >git grep CONFIG_BOOTCOM configs/* |grep -v distro_bootcmd | > >sed -n 's/configs\/\(.*\)_defconfig.*/\1/p' > > > > Disable this option for boards which don't have enough space. > > > > Disable CONFIG_ENV_VARS_UBOOT_CONFIG for some Xilinx boards which have > > a very small environment. Disable BOOTSTD_DEFAULTS for smartweb since > > it is too close to its limit. > > > > Signed-off-by: Simon Glass > > I wasn't clear, sorry. What I want to see first is a standalone patch > that disables BOOTSTD on platforms that have their own custom bootcmd, > that is not just a more complex wrapper around distro_bootcmd (those > platforms will require more work to convert, but won't be impacted by > BOOTSTD_DEFAULTS being default). It needs to be on its own so it can be > reviewed. Thanks. Oh OK, I was wondering how it could be standard if it was just disabling BOOTSTD_DEFAULTS... I will give it a crack. I wonder if this is the same set which doesn't enable DISTRO_DEFAULTS? Regards, Simon
Re: [PATCH 18/38] efi: Show all known UUIDs with CONFIG_CMD_EFIDEBUG
Hi Heinrich,
On Fri, 31 Mar 2023 at 19:46, Heinrich Schuchardt wrote:
>
>
>
> Am 31. März 2023 03:16:06 MESZ schrieb Simon Glass :
> >Hi Heinrich,
> >
> >On Fri, 31 Mar 2023 at 13:27, Heinrich Schuchardt wrote:
> >>
> >>
> >>
> >> Am 31. März 2023 01:48:57 MESZ schrieb Simon Glass :
> >> >Hi Heinrich,
> >> >
> >> >On Fri, 31 Mar 2023 at 11:38, Heinrich Schuchardt
> >> >wrote:
> >> >>
> >> >>
> >> >>
> >> >> Am 30. März 2023 23:32:07 MESZ schrieb Simon Glass :
> >> >> >The CMD_EFIDEBUG option enables debugging so it is reasonable to assume
> >> >> >that all effects should be made to decode the dreaded UUIDs favoured by
> >> >> >UEFI.
> >> >> >
> >> >> >Update the table to show them all when CONFIG_CMD_EFIDEBUG is enabled.
> >> >> >
> >> >> >Signed-off-by: Simon Glass
> >> >> >---
> >> >> >
> >> >> > lib/uuid.c | 2 +-
> >> >> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >> >> >
> >> >> >diff --git a/lib/uuid.c b/lib/uuid.c
> >> >> >index 96e1af3c8b00..ab30fbf9152f 100644
> >> >> >--- a/lib/uuid.c
> >> >> >+++ b/lib/uuid.c
> >> >> >@@ -255,7 +255,7 @@ static const struct {
> >> >> > EFI_CERT_TYPE_PKCS7_GUID,
> >> >> > },
> >> >> > #endif
> >> >> >-#ifdef CONFIG_EFI
> >> >> >+#if defined(CONFIG_CMD_EFIDEBUG) || defined(CONFIG_EFI)
> >> >> > { "EFI_LZMA_COMPRESSED", EFI_LZMA_COMPRESSED },
> >> >> > { "EFI_DXE_SERVICES", EFI_DXE_SERVICES },
> >> >> > { "EFI_HOB_LIST", EFI_HOB_LIST },
> >> >>
> >> >> None of these are used when not building the EFI app.
> >> >
> >> >So you think we should disable them? As I said above, enabling
> >> >debugging seems like a good reason to allow decoding of all of them.
> >> >
> >> >Regards,
> >> >SImon
> >>
> >> U-Boot, Shim, GRUB will not use any of these. The EFI app sees them if
> >> shared by the preceding UEFI firmware.
> >>
> >> There are zillions other GUIDs that a vendor UEFI might use. But why
> >> should we care?
> >>
> >> I would rather drop these strings from the code base.
> >
> >I would far rather drop the UUIDs from the code base. Is that
> >possible? We should use a simple numeric tag, like 0, 1, 2, 3, 4 with
> >an associated descriptive string. Even using a 16-byte string would be
> >better than a UUID.
> >
> >While we have to put up with UUIDs, we need a way to make them
> >intelligible for us poor sods who need to decode boot-time traces[1]
> >and the like.
>
> The EFI spec uses GUIDs and these are strings you will find with Google.
> Natural numbers that have bo significance won't serve anybody. GUIDs not used
> inside U-Boot we should not care to translate as there are too many.
I think it is an interesting idea though, to have an internal register
of these things with an enum. Then U-Boot can just use that everywhere
and it is clear what it is, at least within the U-Boot code base.
Things that are not understood don't matter anyway, since we don't
have code for them.
Anyway, back to the original topic, as you can see from the trace
below, it is far too tedious for a human to decode the UUIDs. That is
what the computer is for.
But if this patch has no value, because the UUIDs I mention are never
shown, we can drop it.
Regards,
Simon
>
> >
> >Regards,
> >Simon
> >
> >[1]
> >EFI: Exit: efi_open_protocol: 0
> >EFI: Entry efi_open_protocol(7ed33da0,
> >5b1b31a1-9562-11d2-8e3f-00a0c969723b, 7ecf4978,
> >7ed33da0, 000
> >0, 0x2)
> >EFI: Exit: efi_open_protocol: 0
> >EFI: Entry efi_open_protocol(7ed238b0,
> >09576e91-6d3f-11d2-8e39-00a0c969723b, 7ecf4978,
> >7ed33da0, 000
> >0, 0x2)
> >EFI: Exit: efi_open_protocol: 0
> >EFI: Entry efi_locate_handle_ext(2,
> >a19832b9-ac25-11d3-9a2d-0090273fc14d, ,
> >7ecf4948, 7d6f3ba0)
> >EFI: Exit: efi_locate_handle_ext: 0
> >EFI: Entry efi_open_protocol(7ed25040,
> >09576e91-6d3f-11d2-8e39-00a0c969723b, 7ecf4978,
> >7ed33da0, 000
> >0, 0x2)
> >EFI: Exit: efi_open_protocol: 0
> >EFI: Entry efi_open_protocol(7ed25040,
> >a19832b9-ac25-11d3-9a2d-0090273fc14d, 7ecf4978,
> >7ed33da0, 000
> >0, 0x2)
> >EFI: Exit: efi_open_protocol: 0
> >EFI: Entry efi_open_protocol(7ed33da0,
> >5b1b31a1-9562-11d2-8e3f-00a0c969723b, 7ecf49b8, 0
> >0007ed33da0, , 0x2)
> >EFI: Exit: efi_open_protocol: 0
> >EFI: Entry efi_open_protocol(7ed238b0,
> >09576e91-6d3f-11d2-8e39-00a0c969723b, 7ecf4958,
> >7ed33da0, 000
> >0, 0x2)
> >EFI: Exit: efi_open_protocol: 0
> >EFI: Entry efi_locate_protocol(96751a3d-72f4-41a6-a794-ed5d0e67ae6b,
> >, 7ecf4668)
> >EFI: Exit: efi_locate_protocol: 14
> >EFI: Entry efi_locate_handle_ext(2,
> >f541796d-a62e-4954-a775-9584f61b9cdd, ,
> >7ecf4638, 7d40be00)
> >EFI: Exit: efi_locate_handle_ext: 14
> >
Re: [PATCH v5 3/8] bootstd: Support booting EFI where multiple options exist
Hi Tom, On Sat, 1 Apr 2023 at 07:02, Tom Rini wrote: > > On Fri, Mar 31, 2023 at 10:25:56AM +1300, Simon Glass wrote: > > > The current EFI implementation has a strange quirk where it watches > > loaded files and uses the last-loaded file to determine the device that > > is being booted from. > > > > This is confusing with bootstd, where multiple options may exist. Even > > loading a device tree will cause it to go wrong. There is no API for > > passing this information, since the only entry into booting an EFI image > > is the 'bootefi' command. > > > > To work around this, call efi_set_bootdev() for EFI images, if possible, > > just before booting. > > > > Signed-off-by: Simon Glass > > Shouldn't this all be a simple wrapper around the EFI Standard > BootDeviceOrder or whatever that's called? I think you are referring to boot manager, which isn't used here. This is replicating the existing distroboot functionality in standard boot. I've been trying to tease out the rules around finding the image and the devicetree files, and this is what I've got it. Regards, Simon
Re: RISC-V FIT image type
Hi Bin, On Fri, 31 Mar 2023 at 19:22, Bin Meng wrote: > > On Fri, Mar 31, 2023 at 5:36 AM Simon Glass wrote: > > > > Hi, > > > > I notice that in image.h we have IH_ARCH_RISCV but no mention of > > IH_ARCH_RISCV64. Should we not have two separate image types, as we do > > with ARM and x86? Otherwise, how would a loader know the word size of > > the target machine? > > I think that's because in RISC-V it is always the same bit-width > U-Boot to load the same bit-width kernel. There is no support of > 32-bit U-Boot to load 64-bit kernel and vice versa. Yes, understood, but in this case we can't be sure that it is possible load a FIT, e.g. if someone makes a mistake. Would it be OK to create a new "riscv64" type? This has come up in the universal payload discussions. Regards, Simon
[PATCH v2 0/1] meson: Demonstration of using binman to produce the image
The Odroid-C2 is quite a complicated image with many steps. It is an ideal example for how Binman can be used. Add a binman description and update the instructions accordingly. Changes in v2: - Rebase to -next Simon Glass (1): RFC: Move Odroid-C2 to use binman to produce the image arch/arm/dts/meson-sm1-odroid-c4-u-boot.dtsi | 107 arch/arm/mach-meson/Kconfig | 1 + doc/board/amlogic/odroid-c4.rst | 127 +-- tools/binman/etype/aml_encrypt.py| 124 ++ tools/binman/ftest.py| 3 + tools/binman/missing-blob-help | 6 + tools/binman/test/213_aml_encrypt.dts| 38 ++ tools/binman/test/214_list_no_dtb.dts| 23 8 files changed, 337 insertions(+), 92 deletions(-) create mode 100644 tools/binman/etype/aml_encrypt.py create mode 100644 tools/binman/test/213_aml_encrypt.dts create mode 100644 tools/binman/test/214_list_no_dtb.dts -- 2.40.0.348.gf938b09366-goog
Re: [PATCH] common: cli_hush: Restore clear local variable support
Hi Stefan,
On Sat, 1 Apr 2023 at 03:43, Stefan Herbrechtsmeier
wrote:
>
> From: Stefan Herbrechtsmeier
>
> The u-boot hush shell doesn’t support the unset command to clear a
> variable and therefore an empty value ("c=") should be a valid value
> for the set_local_var function to clear the variable. This partial
> reverts commit aa722529635c ("common: cli_hush: avoid dead code") and
> only checks for a `=` in the string. Additionally explicit call the
> unset_local_var function to remove the variable if the value is empty.
>
> Signed-off-by: Stefan Herbrechtsmeier
>
> ---
>
> common/cli_hush.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/common/cli_hush.c b/common/cli_hush.c
> index 1ad7a509df..c3f7dd12a0 100644
> --- a/common/cli_hush.c
> +++ b/common/cli_hush.c
> @@ -2171,12 +2171,18 @@ int set_local_var(const char *s, int flg_export)
> * NAME=VALUE format. So the first order of business is to
> * split 's' on the '=' into 'name' and 'value' */
> value = strchr(name, '=');
> - if (value == NULL || *(value + 1) == 0) {
> + if (value == NULL) {
if (!value)
> free(name);
> return -1;
> }
> *value++ = 0;
>
> + if (*value == 0) {
if (!*value)
> + unset_local_var(name);
> + free(name);
> + return 0;
> + }
> +
> for(cur = top_vars; cur; cur = cur->next) {
> if(strcmp(cur->name, name)==0)
> break;
> --
> 2.30.2
I think this should have a test, e.g. in
test/py/tests/test_hush_if_test.py or perhaps a C test?
Regards,
Simon
[PATCH 1/1] sandbox: fix fall through in sandbox_flash_bulk()
Handling of SANDBOX_FLASH_EP_OUT should never fall through to
SANDBOX_FLASH_EP_IN.
This addresses a warning shown when compiling with
-Wimplicit-fallthrough.
Signed-off-by: Heinrich Schuchardt
---
drivers/usb/emul/sandbox_flash.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/emul/sandbox_flash.c b/drivers/usb/emul/sandbox_flash.c
index 01ccc4bc17..7c5c1ab3de 100644
--- a/drivers/usb/emul/sandbox_flash.c
+++ b/drivers/usb/emul/sandbox_flash.c
@@ -266,6 +266,7 @@ static int sandbox_flash_bulk(struct udevice *dev, struct
usb_device *udev,
default:
break;
}
+ break;
case SANDBOX_FLASH_EP_IN:
switch (info->phase) {
case SCSIPH_DATA:
--
2.39.2
[PATCH 1/1] lib: missing fallthrough comment in vsnprintf_internal()
When a case statement intentionally falls through we should add a comment. Cf. -Wimplicit-fallthrough Signed-off-by: Heinrich Schuchardt --- lib/vsprintf.c | 4 1 file changed, 4 insertions(+) diff --git a/lib/vsprintf.c b/lib/vsprintf.c index 2d13e68b57..8af6310651 100644 --- a/lib/vsprintf.c +++ b/lib/vsprintf.c @@ -674,6 +674,7 @@ repeat: case 'x': flags |= SMALL; + /* fallthrough */ case 'X': base = 16; break; @@ -681,8 +682,10 @@ repeat: case 'd': if (fmt[1] == 'E') flags |= ERRSTR; + /* fallthrough */ case 'i': flags |= SIGN; + /* fallthrough */ case 'u': break; -- 2.39.2
[PATCH 1/1] tools: avoid implicit fallthrough in fdt_add_pubkey
When building with -Wimplicit-fallthrough we get a warning
tools/fdt_add_pubkey.c:52:25: warning:
this statement may fall through [-Wimplicit-fallthrough=]
52 | print_help();
|
Explicitly declare which functions don't return.
Fixes: 30238e99619c ("tools: add fdt_add_pubkey")
Signed-off-by: Heinrich Schuchardt
---
tools/fdt_add_pubkey.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/fdt_add_pubkey.c b/tools/fdt_add_pubkey.c
index 999f5a7e83..aa1c3d5b52 100644
--- a/tools/fdt_add_pubkey.c
+++ b/tools/fdt_add_pubkey.c
@@ -10,7 +10,7 @@ static const char *keyname = "key"; /* -n */
static const char *require_keys; /* -r */
static const char *keydest; /* argv[n] */
-static void print_usage(const char *msg)
+static void __attribute__((__noreturn__)) print_usage(const char *msg)
{
fprintf(stderr, "Error: %s\n", msg);
fprintf(stderr, "Usage: %s [-a ] [-k ] [-n ] [-r
]"
@@ -19,7 +19,7 @@ static void print_usage(const char *msg)
exit(EXIT_FAILURE);
}
-static void print_help(void)
+static void __attribute__((__noreturn__)) print_help(void)
{
fprintf(stderr, "Options:\n"
"\t-aCryptographic algorithm. Optional parameter,
default value: sha1,rsa2048\n"
--
2.39.2
Re: [PATCH v2] sysreset: gpio: fix gpio_reboot_request return value
It should return -EINPROGRESS if successful otherwise sysreset-uclass will continue to the next sysreset device. Signed-off-by: Jonathan Liu Reviewed-by: Simon Glass --- drivers/sysreset/sysreset_gpio.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) Applied to u-boot-dm, thanks!
Re: [PATCH] buildman: Correct overwriting of settings file
The toolchain test causes the settings file to be overwritten, which is annoying for local development. Fix it by passing None as the filename. Signed-off-by: Simon Glass --- tools/buildman/toolchain.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Applied to u-boot-dm, thanks!
[PATCH 1/1] efi_loader: remove duplicate assignment
Assigning the value of a variable to itself should be avoided.
Addresses-Coverity-ID: 451089 ("Evaluation order violation")
Fixes: 180b7118bed8 ("efi_loader: fix device-path for USB devices")
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_device_path.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index b6dd575b13..39e301450c 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -749,7 +749,7 @@ __maybe_unused static void *dp_fill(void *buf, struct
udevice *dev)
#endif
#if defined(CONFIG_USB)
case UCLASS_MASS_STORAGE: {
- struct blk_desc *desc = desc = dev_get_uclass_plat(dev);
+ struct blk_desc *desc = dev_get_uclass_plat(dev);
struct efi_device_path_controller *dp =
dp_fill(buf, dev->parent);
--
2.39.2
Re: [RFC PATCH v7 23/23] DO NOT MERGE: only to make CI happy
Hi Francis,
On Thu, Mar 30, 2023 at 3:14 PM Francis Laniel
wrote:
>
> Hi.
>
> Le jeudi 30 mars 2023, 21:17:33 WEST Tony Dinh a écrit :
> > Hi Francis,
> >
> > On Thu, Mar 30, 2023 at 12:50 PM Francis Laniel
> >
> > wrote:
> > > This commit set CONFIG_HUSH_PARSER_2021 as the default to trigger the CI
> > > with this parser.
> > >
> > > Nonetheless, the keymile (i.e. VENDOR_KM) board family is not compatible
> > > with new 2021 hush parser.
> > > Indeed, This boards used set_local_var() to store some variables as local
> > > shell. They then used get_local_var() to retrieve the variables values.
> > > Sadly, this two functions do not exist with CONFIG_HUSH_PARSER_2021.
> > > A patch was proposed to use environment variables rather than local
> > > variables but it does not tackle the problem, so complementary work is
> > > needed to make this boards use CONFIG_HUSH_PARSER_2021 [1].
> > >
> > > We also remove a #undef of CONFIG_FEATURE_SH_STANDALONE as it does not
> > > exist in U-Boot and causes troubles in the CI.
> > >
> > > We also set CONFIG_LTO for kirkwoord sheevaplug and phytec bk4r1,
> > > otherwise it hits its board size limit.
> > > By enabling this option, we also had to add assembly for
> > > __gnu_thumb1_case_si. It was taken from upstream gcc and adapted as width
> > > suffix was removed for the add [2].
> >
> > Thanks for adding __gnu_thumb1_case_si ! It will help not just the
> > Sheevaplug board, but also a few other boards too. I'll give this a
> > try.
>
> You are welcome!
> I nonetheless cannot ensure the modifications I brought to the code are
> correct
> as I do not have the board to test them.
> So, if you can test it on a board it will be really welcomed and in case you
> find any problem I will add your suggested changes to the commit!
I applied the arch/arm/lib/lib1funcs.S patch, built, and ran the
u-boot-2023.04-rc5 for Pogo V4 board (Kirkwood 6192 SoC). Everything
is working fine. Thanks!
Is it possible for you to send in this patch for lib1funcs.S
separately? Given this RFC patch series probably will take a while to
get merged. In the meantime, it would be great to have this earlier so
we all can start building LTO+Thumb enabled u-boots with gcc 12.x. I
can do more testing with other boards that have CONFIG_HAS_THUMB2 and
CONFIG_SPL_SYS_THUMB_BUILD. Please let me know if I can help with that
individual patch.
Ref [1] https://lists.denx.de/pipermail/u-boot/2022-November/500460.html
Ref [2] https://lists.denx.de/pipermail/u-boot/2022-November/500463.html
Tested-by: Tony Dinh
All the best,
Tony
>
> >
> > All the best,
> > Tony
> >
> > > Signed-off-by: Francis Laniel
> > > [1] https://marc.info/?l=u-boot&m=165541917618725&w=2
> > > [2]
> > > https://github.com/gcc-mirror/gcc/blob/4f181f9c7ee3efc509d185fdfda33be901
> > > 8f1611/libgcc/config/arm/lib1funcs.S#L2156 ---
> > >
> > > arch/arm/lib/lib1funcs.S | 17 +
> > > cmd/Kconfig | 3 ++-
> > > common/cli_hush_upstream.c | 1 -
> > > configs/bk4r1_defconfig | 1 +
> > > configs/sheevaplug_defconfig | 1 +
> > > 5 files changed, 21 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/arm/lib/lib1funcs.S b/arch/arm/lib/lib1funcs.S
> > > index de15d09e36..a1f44d9454 100644
> > > --- a/arch/arm/lib/lib1funcs.S
> > > +++ b/arch/arm/lib/lib1funcs.S
> > > @@ -419,4 +419,21 @@ ENTRY(__gnu_thumb1_case_uhi)
> > >
> > > ret lr
> > >
> > > ENDPROC(__gnu_thumb1_case_uhi)
> > > .popsection
> > >
> > > +
> > > +/* Taken and adapted from:
> > > https://github.com/gcc-mirror/gcc/blob/4f181f9c7ee3efc509d185fdfda33be901
> > > 8f1611/libgcc/config/arm/lib1funcs.S#L2156 */ +.pushsection
> > > .text.__gnu_thumb1_case_si, "ax"
> > > +ENTRY(__gnu_thumb1_case_si)
> > > + push{r0, r1}
> > > + mov r1, lr
> > > + addsr1, r1, #2 /* Align to word. */
> > > + lsrsr1, r1, #2
> > > + lslsr0, r0, #2
> > > + lslsr1, r1, #2
> > > + ldr r0, [r1, r0]
> > > + addsr0, r0, r1
> > > + mov lr, r0
> > > + pop {r0, r1}
> > > + mov pc, lr /* We know we were called from thumb code.
> > > */ +ENDPROC(__gnu_thumb1_case_si)
> > > +.popsection
> > >
> > > #endif
> > >
> > > diff --git a/cmd/Kconfig b/cmd/Kconfig
> > > index 1b9d04680d..d4809fcfa4 100644
> > > --- a/cmd/Kconfig
> > > +++ b/cmd/Kconfig
> > > @@ -28,7 +28,7 @@ menu "Hush flavor to use"
> > >
> > > config HUSH_OLD_PARSER
> > >
> > > bool "Use hush old parser"
> > >
> > > - default y
> > > + default y if VENDOR_KM
> > >
> > > help
> > >
> > > This option enables the old flavor of hush based on hush
> > > Busybox from
> > > 2005.
> > >
> > > @@ -37,6 +37,7 @@ menu "Hush flavor to use"
> > >
> > > config HUSH_2021_PARSER
> > >
> > > bool "Use hush 2021 parser"
> > >
> > > +
Re: Pull request: please pull u-boot-imx/next
On Fri, Mar 31, 2023 at 10:40:34AM +0200, Stefano Babic wrote: > Hi Tom, > > this is a big bunch for /next. > > For current release, I have still a couple of fixes that I am picking up. > > The following changes since commit 654483d251275d61eb5f93c18e320ad7d6bfcc5d: > > Merge tag 'u-boot-at91-2023.07-a' of > https://source.denx.de/u-boot/custodians/u-boot-at91 into next (2023-03-28 > 11:21:29 -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git > tags/u-boot-imx-next-20230331 > > for you to fetch changes up to f216580b642c7244aeb3619aeceecb331e025ad3: > > clk: imx8mp: add pwm clocks support (2023-03-30 13:53:55 +0200) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] doc: ti: Add switch setting for boot modes on AM62 SK
On Fri, Mar 31, 2023 at 03:36:15PM -0500, Judith Mendez wrote: > List some common boot modes and their corresponding switch > settings for AM62 SK. > > Signed-off-by: Judith Mendez Thanks for reworking. Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
[PATCH] doc: ti: Add switch setting for boot modes on AM62 SK
List some common boot modes and their corresponding switch settings for AM62 SK. Signed-off-by: Judith Mendez --- Changes from v1: Change table format from ascii-art to list-table doc/board/ti/am62x_sk.rst | 36 1 file changed, 36 insertions(+) diff --git a/doc/board/ti/am62x_sk.rst b/doc/board/ti/am62x_sk.rst index b1b7d99befb..3d85400b1a1 100644 --- a/doc/board/ti/am62x_sk.rst +++ b/doc/board/ti/am62x_sk.rst @@ -229,3 +229,39 @@ Image formats: | | SPL DTB 1...N | | | +---+ | +---+ + +Switch Setting for Boot Mode + + +Boot Mode pins provide means to select the boot mode and options before the +device is powered up. After every POR, they are the main source to populate +the Boot Parameter Tables. + +The following table shows some common boot modes used on AM62 platform. More +details can be found in the Technical Reference Manual: +https://www.ti.com/lit/pdf/spruiv7 under the `Boot Mode Pins` section. + +.. list-table:: Boot Modes + :widths: 32 32 32 + :header-rows: 1 + + * - Switch Label + - SW2: 12345678 + - SW3: 12345678 + * - SD + - 0100 + - 1110 + * - OSPI + - + - 11001110 + * - EMMC + - + - 11010010 + * - UART + - + - 11011100 + * - USB DFU + - + - 11001010 + +For SW2 and SW1, the switch state in the "ON" position = 1. -- 2.17.1
Re: [PATCH] include: configs: Change dtb names in fitImage to match oe-core
On Fri, Mar 31, 2023 at 01:52:44PM -0500, Andrew Davis wrote:
> On 3/31/23 1:36 PM, Tom Rini wrote:
> > On Fri, Mar 31, 2023 at 01:23:23PM -0500, Andrew Davis wrote:
> > > On 3/31/23 1:11 PM, Tom Rini wrote:
> > > > On Fri, Mar 31, 2023 at 12:19:14PM -0500, Andrew Davis wrote:
> > > > > On 3/31/23 12:04 PM, Nishanth Menon wrote:
> > > > > > On 16:06-20230330, Ryan Eatmon wrote:
> > > > > > > The oe-core class for assembling the fitImage includes the vendor
> > > > > > > sub-directory (with the / changed to _) in the config sections of
> > > > > > > the fitImage. Our env var settings for chosing which section to
> > > > > > > boot from needs to be updated to agree with the fitImage.
> > > > > > >
> > > > > > > Signed-off-by: Ryan Eatmon
> > > > > > > ---
> > > > > > > include/configs/am64x_evm.h | 4 ++--
> > > > > > > include/configs/am65x_evm.h | 2 +-
> > > > > > > include/configs/j721e_evm.h | 6 +++---
> > > > > > > include/configs/j721s2_evm.h | 6 +++---
> > > > > > > 4 files changed, 9 insertions(+), 9 deletions(-)
> > > > > > >
> > > > > > > diff --git a/include/configs/am64x_evm.h
> > > > > > > b/include/configs/am64x_evm.h
> > > > > > > index 26a7f2521e..456a44730c 100644
> > > > > > > --- a/include/configs/am64x_evm.h
> > > > > > > +++ b/include/configs/am64x_evm.h
> > > > > > > @@ -26,9 +26,9 @@
> > > > > > > #define EXTRA_ENV_AM642_BOARD_SETTINGS
> > > > > > > \
> > > > > > > "findfdt="
> > > > > > > \
> > > > > > > "if test $board_name = am64x_gpevm; then " \
> > > > > > > - "setenv fdtfile k3-am642-evm.dtb; fi; " \
> > > > > > > + "setenv fdtfile ti_k3-am642-evm.dtb; fi; " \
> > > > > > > "if test $board_name = am64x_skevm; then " \
> > > > > > > - "setenv fdtfile k3-am642-sk.dtb; fi;" \
> > > > > > > + "setenv fdtfile ti_k3-am642-sk.dtb; fi;" \
> > > > > >
> > > > > >
> > > > > > Kernel.org builds k3-am642-sk.dtb
> > > > > >
> > > > >
> > > > > Nope, kernel.org build ti/k3-am642-sk.dtb
> > > > >
> > > > > > Why would we want to go and fix it with non-standard?
> > > > > >
> > > > >
> > > > > The dtbs need to have their dir prefixed or there could be collisions
> > > >
> > > > The key here is we're talking about what's used in FIT images, and not
> > > > just loaded directly. All of the cases where fdtfile is used on arm64
> > > > platforms in tree today use "/" because it's loading a literal. In this
> > > > case, why again is OE mangling the name, and what are we using it for
> > > > again here? In other words, why can't it be treated as "/" to match the
> > > > load a file case? And if it _must_ be mangled, must we still use fdtfile
> > > > and not something else?
> > > >
> > >
> > > So to match other plats, we should:
> > >
> > > setenv fdtfile ti/k3-am642-sk.dtb
> > >
> > > That way loading works in the non-FIT case (and we just need to stop
> > > moving
> > > all the DTBs out of the ti/ to the root dir (which is probably broken on
> > > our
> > > part anyway..))
> >
> > Yes, this sounds right for the non-FIT case to match other platforms /
> > etc.
> >
> > > Then when we use "fdtfile" in the FIT case, we just mangle ("/"->"_") it
> > > at that point only before use. That work for everyone?
> >
> > Well, what _is_ the FIT case and how does it go exactly? I still want to
> > know why we're mangling things and come up with something that'll work
> > for when someone says "I've got an imx8mm and I'm using a FIT image from
> > OE and this doesn't work!".
> >
>
> So what happens is when OE is packaging a dtb file into the FIT image
> it names the node based on the dtb filename. Node names can't have
> / so it is turned into _ [0]. We select our FIT config using the
> "fdtfile" env var so we don't duplicate the above board_name to fdt
> logic. Result is fdtfile needs mangled when used to select a config
> node from OE made FIT image.
OK, so the next step would be to use setexpr + regex to mangle fdtfile
to get the node name to use, so you don't have to duplicate the logic.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] include: configs: Change dtb names in fitImage to match oe-core
On 3/31/23 1:36 PM, Tom Rini wrote:
On Fri, Mar 31, 2023 at 01:23:23PM -0500, Andrew Davis wrote:
On 3/31/23 1:11 PM, Tom Rini wrote:
On Fri, Mar 31, 2023 at 12:19:14PM -0500, Andrew Davis wrote:
On 3/31/23 12:04 PM, Nishanth Menon wrote:
On 16:06-20230330, Ryan Eatmon wrote:
The oe-core class for assembling the fitImage includes the vendor
sub-directory (with the / changed to _) in the config sections of
the fitImage. Our env var settings for chosing which section to
boot from needs to be updated to agree with the fitImage.
Signed-off-by: Ryan Eatmon
---
include/configs/am64x_evm.h | 4 ++--
include/configs/am65x_evm.h | 2 +-
include/configs/j721e_evm.h | 6 +++---
include/configs/j721s2_evm.h | 6 +++---
4 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/configs/am64x_evm.h b/include/configs/am64x_evm.h
index 26a7f2521e..456a44730c 100644
--- a/include/configs/am64x_evm.h
+++ b/include/configs/am64x_evm.h
@@ -26,9 +26,9 @@
#define EXTRA_ENV_AM642_BOARD_SETTINGS
\
"findfdt="\
"if test $board_name = am64x_gpevm; then " \
- "setenv fdtfile k3-am642-evm.dtb; fi; " \
+ "setenv fdtfile ti_k3-am642-evm.dtb; fi; " \
"if test $board_name = am64x_skevm; then " \
- "setenv fdtfile k3-am642-sk.dtb; fi;" \
+ "setenv fdtfile ti_k3-am642-sk.dtb; fi;" \
Kernel.org builds k3-am642-sk.dtb
Nope, kernel.org build ti/k3-am642-sk.dtb
Why would we want to go and fix it with non-standard?
The dtbs need to have their dir prefixed or there could be collisions
The key here is we're talking about what's used in FIT images, and not
just loaded directly. All of the cases where fdtfile is used on arm64
platforms in tree today use "/" because it's loading a literal. In this
case, why again is OE mangling the name, and what are we using it for
again here? In other words, why can't it be treated as "/" to match the
load a file case? And if it _must_ be mangled, must we still use fdtfile
and not something else?
So to match other plats, we should:
setenv fdtfile ti/k3-am642-sk.dtb
That way loading works in the non-FIT case (and we just need to stop moving
all the DTBs out of the ti/ to the root dir (which is probably broken on our
part anyway..))
Yes, this sounds right for the non-FIT case to match other platforms /
etc.
Then when we use "fdtfile" in the FIT case, we just mangle ("/"->"_") it
at that point only before use. That work for everyone?
Well, what _is_ the FIT case and how does it go exactly? I still want to
know why we're mangling things and come up with something that'll work
for when someone says "I've got an imx8mm and I'm using a FIT image from
OE and this doesn't work!".
So what happens is when OE is packaging a dtb file into the FIT image
it names the node based on the dtb filename. Node names can't have
/ so it is turned into _ [0]. We select our FIT config using the
"fdtfile" env var so we don't duplicate the above board_name to fdt
logic. Result is fdtfile needs mangled when used to select a config
node from OE made FIT image.
Andrew
[0]
https://git.openembedded.org/openembedded-core/tree/meta/classes-recipe/kernel-fitimage.bbclass#n425
Re: [PATCH] include: configs: Change dtb names in fitImage to match oe-core
On Fri, Mar 31, 2023 at 01:23:23PM -0500, Andrew Davis wrote:
> On 3/31/23 1:11 PM, Tom Rini wrote:
> > On Fri, Mar 31, 2023 at 12:19:14PM -0500, Andrew Davis wrote:
> > > On 3/31/23 12:04 PM, Nishanth Menon wrote:
> > > > On 16:06-20230330, Ryan Eatmon wrote:
> > > > > The oe-core class for assembling the fitImage includes the vendor
> > > > > sub-directory (with the / changed to _) in the config sections of
> > > > > the fitImage. Our env var settings for chosing which section to
> > > > > boot from needs to be updated to agree with the fitImage.
> > > > >
> > > > > Signed-off-by: Ryan Eatmon
> > > > > ---
> > > > >include/configs/am64x_evm.h | 4 ++--
> > > > >include/configs/am65x_evm.h | 2 +-
> > > > >include/configs/j721e_evm.h | 6 +++---
> > > > >include/configs/j721s2_evm.h | 6 +++---
> > > > >4 files changed, 9 insertions(+), 9 deletions(-)
> > > > >
> > > > > diff --git a/include/configs/am64x_evm.h b/include/configs/am64x_evm.h
> > > > > index 26a7f2521e..456a44730c 100644
> > > > > --- a/include/configs/am64x_evm.h
> > > > > +++ b/include/configs/am64x_evm.h
> > > > > @@ -26,9 +26,9 @@
> > > > >#define EXTRA_ENV_AM642_BOARD_SETTINGS
> > > > > \
> > > > > "findfdt="
> > > > > \
> > > > > "if test $board_name = am64x_gpevm; then " \
> > > > > - "setenv fdtfile k3-am642-evm.dtb; fi; " \
> > > > > + "setenv fdtfile ti_k3-am642-evm.dtb; fi; " \
> > > > > "if test $board_name = am64x_skevm; then " \
> > > > > - "setenv fdtfile k3-am642-sk.dtb; fi;" \
> > > > > + "setenv fdtfile ti_k3-am642-sk.dtb; fi;" \
> > > >
> > > >
> > > > Kernel.org builds k3-am642-sk.dtb
> > > >
> > >
> > > Nope, kernel.org build ti/k3-am642-sk.dtb
> > >
> > > > Why would we want to go and fix it with non-standard?
> > > >
> > >
> > > The dtbs need to have their dir prefixed or there could be collisions
> >
> > The key here is we're talking about what's used in FIT images, and not
> > just loaded directly. All of the cases where fdtfile is used on arm64
> > platforms in tree today use "/" because it's loading a literal. In this
> > case, why again is OE mangling the name, and what are we using it for
> > again here? In other words, why can't it be treated as "/" to match the
> > load a file case? And if it _must_ be mangled, must we still use fdtfile
> > and not something else?
> >
>
> So to match other plats, we should:
>
> setenv fdtfile ti/k3-am642-sk.dtb
>
> That way loading works in the non-FIT case (and we just need to stop moving
> all the DTBs out of the ti/ to the root dir (which is probably broken on our
> part anyway..))
Yes, this sounds right for the non-FIT case to match other platforms /
etc.
> Then when we use "fdtfile" in the FIT case, we just mangle ("/"->"_") it
> at that point only before use. That work for everyone?
Well, what _is_ the FIT case and how does it go exactly? I still want to
know why we're mangling things and come up with something that'll work
for when someone says "I've got an imx8mm and I'm using a FIT image from
OE and this doesn't work!".
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] include: configs: Change dtb names in fitImage to match oe-core
On 3/31/23 1:11 PM, Tom Rini wrote:
On Fri, Mar 31, 2023 at 12:19:14PM -0500, Andrew Davis wrote:
On 3/31/23 12:04 PM, Nishanth Menon wrote:
On 16:06-20230330, Ryan Eatmon wrote:
The oe-core class for assembling the fitImage includes the vendor
sub-directory (with the / changed to _) in the config sections of
the fitImage. Our env var settings for chosing which section to
boot from needs to be updated to agree with the fitImage.
Signed-off-by: Ryan Eatmon
---
include/configs/am64x_evm.h | 4 ++--
include/configs/am65x_evm.h | 2 +-
include/configs/j721e_evm.h | 6 +++---
include/configs/j721s2_evm.h | 6 +++---
4 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/configs/am64x_evm.h b/include/configs/am64x_evm.h
index 26a7f2521e..456a44730c 100644
--- a/include/configs/am64x_evm.h
+++ b/include/configs/am64x_evm.h
@@ -26,9 +26,9 @@
#define EXTRA_ENV_AM642_BOARD_SETTINGS
\
"findfdt="\
"if test $board_name = am64x_gpevm; then " \
- "setenv fdtfile k3-am642-evm.dtb; fi; " \
+ "setenv fdtfile ti_k3-am642-evm.dtb; fi; " \
"if test $board_name = am64x_skevm; then " \
- "setenv fdtfile k3-am642-sk.dtb; fi;" \
+ "setenv fdtfile ti_k3-am642-sk.dtb; fi;" \
Kernel.org builds k3-am642-sk.dtb
Nope, kernel.org build ti/k3-am642-sk.dtb
Why would we want to go and fix it with non-standard?
The dtbs need to have their dir prefixed or there could be collisions
The key here is we're talking about what's used in FIT images, and not
just loaded directly. All of the cases where fdtfile is used on arm64
platforms in tree today use "/" because it's loading a literal. In this
case, why again is OE mangling the name, and what are we using it for
again here? In other words, why can't it be treated as "/" to match the
load a file case? And if it _must_ be mangled, must we still use fdtfile
and not something else?
So to match other plats, we should:
setenv fdtfile ti/k3-am642-sk.dtb
That way loading works in the non-FIT case (and we just need to stop moving
all the DTBs out of the ti/ to the root dir (which is probably broken on our
part anyway..))
Then when we use "fdtfile" in the FIT case, we just mangle ("/"->"_") it
at that point only before use. That work for everyone?
Andrew
Re: [PATCH] include: configs: Change dtb names in fitImage to match oe-core
On Fri, Mar 31, 2023 at 12:19:14PM -0500, Andrew Davis wrote: > On 3/31/23 12:04 PM, Nishanth Menon wrote: > > On 16:06-20230330, Ryan Eatmon wrote: > > > The oe-core class for assembling the fitImage includes the vendor > > > sub-directory (with the / changed to _) in the config sections of > > > the fitImage. Our env var settings for chosing which section to > > > boot from needs to be updated to agree with the fitImage. > > > > > > Signed-off-by: Ryan Eatmon > > > --- > > > include/configs/am64x_evm.h | 4 ++-- > > > include/configs/am65x_evm.h | 2 +- > > > include/configs/j721e_evm.h | 6 +++--- > > > include/configs/j721s2_evm.h | 6 +++--- > > > 4 files changed, 9 insertions(+), 9 deletions(-) > > > > > > diff --git a/include/configs/am64x_evm.h b/include/configs/am64x_evm.h > > > index 26a7f2521e..456a44730c 100644 > > > --- a/include/configs/am64x_evm.h > > > +++ b/include/configs/am64x_evm.h > > > @@ -26,9 +26,9 @@ > > > #define EXTRA_ENV_AM642_BOARD_SETTINGS > > > \ > > > "findfdt=" > > > \ > > > "if test $board_name = am64x_gpevm; then " \ > > > - "setenv fdtfile k3-am642-evm.dtb; fi; " \ > > > + "setenv fdtfile ti_k3-am642-evm.dtb; fi; " \ > > > "if test $board_name = am64x_skevm; then " \ > > > - "setenv fdtfile k3-am642-sk.dtb; fi;" \ > > > + "setenv fdtfile ti_k3-am642-sk.dtb; fi;" \ > > > > > > Kernel.org builds k3-am642-sk.dtb > > > > Nope, kernel.org build ti/k3-am642-sk.dtb > > > Why would we want to go and fix it with non-standard? > > > > The dtbs need to have their dir prefixed or there could be collisions The key here is we're talking about what's used in FIT images, and not just loaded directly. All of the cases where fdtfile is used on arm64 platforms in tree today use "/" because it's loading a literal. In this case, why again is OE mangling the name, and what are we using it for again here? In other words, why can't it be treated as "/" to match the load a file case? And if it _must_ be mangled, must we still use fdtfile and not something else? -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 3/8] bootstd: Support booting EFI where multiple options exist
On Fri, Mar 31, 2023 at 10:25:56AM +1300, Simon Glass wrote: > The current EFI implementation has a strange quirk where it watches > loaded files and uses the last-loaded file to determine the device that > is being booted from. > > This is confusing with bootstd, where multiple options may exist. Even > loading a device tree will cause it to go wrong. There is no API for > passing this information, since the only entry into booting an EFI image > is the 'bootefi' command. > > To work around this, call efi_set_bootdev() for EFI images, if possible, > just before booting. > > Signed-off-by: Simon Glass Shouldn't this all be a simple wrapper around the EFI Standard BootDeviceOrder or whatever that's called? -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 8/8] bootstd: Enable BOOTSTD_DEFAULTS by default
On Fri, Mar 31, 2023 at 10:26:01AM +1300, Simon Glass wrote: > This is needed to enable the boot command used to start standard boot. > Enable it by default. This brings in quite a few features, mostly in > common with DISTRO_DEFAULTS > > Exclude boards which have what looks like a custom boot command: > >git grep CONFIG_BOOTCOM configs/* |grep -v distro_bootcmd | >sed -n 's/configs\/\(.*\)_defconfig.*/\1/p' > > Disable this option for boards which don't have enough space. > > Disable CONFIG_ENV_VARS_UBOOT_CONFIG for some Xilinx boards which have > a very small environment. Disable BOOTSTD_DEFAULTS for smartweb since > it is too close to its limit. > > Signed-off-by: Simon Glass I wasn't clear, sorry. What I want to see first is a standalone patch that disables BOOTSTD on platforms that have their own custom bootcmd, that is not just a more complex wrapper around distro_bootcmd (those platforms will require more work to convert, but won't be impacted by BOOTSTD_DEFAULTS being default). It needs to be on its own so it can be reviewed. Thanks. -- Tom signature.asc Description: PGP signature
Re: [v4 0/7] Fix Rockchip RK3399 bootstd migration
On Fri, Mar 31, 2023 at 09:39:53AM +0100, Peter Robinson wrote: > Hi Simon, > > > > > > > > I took a look at Simon's v3 series to fix the rk3399 bootstd > > > > > > > migration, > > > > > > > and it changed too much for everything else. I took about half of > > > > > > > that > > > > > > > series and then reworked a few things. Now only rk3399 platforms > > > > > > > change > > > > > > > at all and aside from bootcmd changes, the only thing is they now > > > > > > > disable true/test/sysboot/showvar/false/exit commands as those > > > > > > > were > > > > > > > being pulled in from distro and now we don't set that flag. I > > > > > > > think the > > > > > > > way I changed how we enable BOOTSTD_DEFAULTS should make it > > > > > > > easier to > > > > > > > perform more SoC migrations. > > > > > > > > > > > > Thanks for digging into this. I haven't seen any comments on the rpi > > > > > > conversion, so perhaps people could test that? > > > > > > > > > > I was planning on looking at that once 2023.04 was out but TBH I have > > > > > wasted so much time over the last few cycles dealing with regressions > > > > > through a bunch of these series that I now have so little time for > > > > > enhancements I now shy away. I know a lot of these series should > > > > > improve things in the future but they don't feel like when there's > > > > > unnecessary changes for things that are clearly untested. > > > > > > > > I too am unhappy with how some of these have gone. The _intent_ here is > > > > that getting the current "boot generic distro" framework is complex / > > > > error prone, and we can do better. Unfortunately the first set of > > > > platforms to switch to this are Rockchip and I think there was overlap > > > > there with platforms that got broken at the end of the v2023.01 cycle to > > > > fix other platforms, and then those sets of platforms flipped early in > > > > v2023.04 and took until -rc2? to get resolved. Which was less than > > > > ideal. > > > > > > > > > There's also a lot of change for changes sake, for example the > > > > > rockchips ATF binaries needed is called bl31.elf by the default output > > > > > of the ATF build process, for others it's bl31.bin, binman for what > > > > > ever reason has changed that to be atf-bl31, now I have to change the > > > > > entire build process to be able to work out what is what on a board by > > > > > board basis to be able to set the required variable to be able to > > > > > specify the ATF where previously it "just worked (tm)". I suppose > > > > > there is some perceived goal and improvement here but with both my > > > > > "U-Boot device maintainer" and "distro maintainer" hats on, both of > > > > > which I do in my own spare time, I currently fail to see it and I end > > > > > up. > > > > > > > > I wish I knew where to talk to with ATF / TF-A to get some agreed upon > > > > naming scheme going as one of the things that is very frustrating is > > > > getting the names and combinations of everything else that's required > > > > Just Right for every chip. And feedback that things aren't working is > > > > appreciated, since we do need to make things easier. > > > > > > In all of the various make_fit_atf.py the various vendors specified > > > them, this is the case for the rockchip one [1]. This is the case for > > > the Allwinner boards [2] but the rockchip ports have missed this so it > > > also should be fixed for GA. > > Can you do a patch to fix this regression please and then specify the > correct pieces in the binman section then? > > > > A side point is that binman should not be storing firmware build > > > specifics in the device tree which is a means of describing the > > > hardware, This really needs to be fixed as it really isn't the right > > > place for that sort of things. I suspect a file in arch/arm/mach- > > > is likely a better location, or if it's board specific in the board/ > > > sub directory. > > > > Sorry, I don't agree with that at all. We store configuration > > information in devicetree in firmware as this seems to be best format > > for it, particularly with the growing number of firmware components > > that need to share this information at runtime. The layout of firmware > > is an important part of the system. We are still figuring out the > > flows though. Also I have not attempted to upstream the binman > > binding. I am very open to ideas on how best to do that. > > Rob what's your thoughts on the binman firmware build pieces being in > device tree and the process on upstreaming the bindings? One question I have is, with your distribution person hat on, what do you think the right answer here is? It's not that U-Boot requires TF-A (and also other blobs depending on SoC) but rather that modern ARM SoCs are like x86-64 SoCs have been for ages and require multiple parts to get assembled "just so", to result in something that initializes enough of the system to get to loading something that can load the OS, and
Re: [PATCH] include: configs: Change dtb names in fitImage to match oe-core
On 3/31/23 12:04 PM, Nishanth Menon wrote:
On 16:06-20230330, Ryan Eatmon wrote:
The oe-core class for assembling the fitImage includes the vendor
sub-directory (with the / changed to _) in the config sections of
the fitImage. Our env var settings for chosing which section to
boot from needs to be updated to agree with the fitImage.
Signed-off-by: Ryan Eatmon
---
include/configs/am64x_evm.h | 4 ++--
include/configs/am65x_evm.h | 2 +-
include/configs/j721e_evm.h | 6 +++---
include/configs/j721s2_evm.h | 6 +++---
4 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/configs/am64x_evm.h b/include/configs/am64x_evm.h
index 26a7f2521e..456a44730c 100644
--- a/include/configs/am64x_evm.h
+++ b/include/configs/am64x_evm.h
@@ -26,9 +26,9 @@
#define EXTRA_ENV_AM642_BOARD_SETTINGS
\
"findfdt="\
"if test $board_name = am64x_gpevm; then " \
- "setenv fdtfile k3-am642-evm.dtb; fi; " \
+ "setenv fdtfile ti_k3-am642-evm.dtb; fi; " \
"if test $board_name = am64x_skevm; then " \
- "setenv fdtfile k3-am642-sk.dtb; fi;" \
+ "setenv fdtfile ti_k3-am642-sk.dtb; fi;" \
Kernel.org builds k3-am642-sk.dtb
Nope, kernel.org build ti/k3-am642-sk.dtb
Why would we want to go and fix it with non-standard?
The dtbs need to have their dir prefixed or there could be collisions
Andrew
"if test $fdtfile = undefined; then " \
"echo WARNING: Could not determine device tree to use; fi;
\0" \
"name_kern=Image\0" \
diff --git a/include/configs/am65x_evm.h b/include/configs/am65x_evm.h
index 33dd6cfdfa..60a7eb1453 100644
--- a/include/configs/am65x_evm.h
+++ b/include/configs/am65x_evm.h
@@ -24,7 +24,7 @@
/* U-Boot general configuration */
#define EXTRA_ENV_AM65X_BOARD_SETTINGS
\
"findfdt="\
- "setenv name_fdt k3-am654-base-board.dtb;"\
+ "setenv name_fdt ti_k3-am654-base-board.dtb;" \
"setenv fdtfile ${name_fdt}\0"\
"name_kern=Image\0" \
"console=ttyS2,115200n8\0"\
diff --git a/include/configs/j721e_evm.h b/include/configs/j721e_evm.h
index 48b1cea6e3..eac5cd5b76 100644
--- a/include/configs/j721e_evm.h
+++ b/include/configs/j721e_evm.h
@@ -34,11 +34,11 @@
#define EXTRA_ENV_J721E_BOARD_SETTINGS
\
"default_device_tree=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
"findfdt="\
- "setenv name_fdt ${default_device_tree};" \
+ "setenv name_fdt ti_${default_device_tree};" \
"if test $board_name = j721e; then " \
- "setenv name_fdt k3-j721e-common-proc-board.dtb; fi;" \
+ "setenv name_fdt ti_k3-j721e-common-proc-board.dtb;
fi;" \
"if test $board_name = j721e-eaik || test $board_name = j721e-sk;
then " \
- "setenv name_fdt k3-j721e-sk.dtb; fi;"\
+ "setenv name_fdt ti_k3-j721e-sk.dtb; fi;" \
"setenv fdtfile ${name_fdt}\0"\
"name_kern=Image\0" \
"console=ttyS2,115200n8\0"\
diff --git a/include/configs/j721s2_evm.h b/include/configs/j721s2_evm.h
index bfada9eebc..b30a4a8da4 100644
--- a/include/configs/j721s2_evm.h
+++ b/include/configs/j721s2_evm.h
@@ -31,11 +31,11 @@
#define EXTRA_ENV_J721S2_BOARD_SETTINGS
\
"default_device_tree=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
"findfdt="\
- "setenv name_fdt ${default_device_tree};" \
+ "setenv name_fdt ti_${default_device_tree};" \
"if test $board_name = j721s2; then " \
- "setenv name_fdt k3-j721s2-common-proc-board.dtb; fi;" \
+ "setenv name_fdt ti_k3-j721s2-common-proc-board.dtb;
fi;" \
"if test $board_name = am68-sk; then "\
- "setenv name_fdt k3-am68-sk-base-board.dtb; fi;"\
+ "setenv name_fdt ti_k3-am68-sk-base-board.dtb; fi;"\
"setenv fdtfile ${name_fdt}\0"\
"name_kern=Image\0" \
"console=ttyS2,
Re: [PATCH] include: configs: Change dtb names in fitImage to match oe-core
On 16:06-20230330, Ryan Eatmon wrote:
> The oe-core class for assembling the fitImage includes the vendor
> sub-directory (with the / changed to _) in the config sections of
> the fitImage. Our env var settings for chosing which section to
> boot from needs to be updated to agree with the fitImage.
>
> Signed-off-by: Ryan Eatmon
> ---
> include/configs/am64x_evm.h | 4 ++--
> include/configs/am65x_evm.h | 2 +-
> include/configs/j721e_evm.h | 6 +++---
> include/configs/j721s2_evm.h | 6 +++---
> 4 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/include/configs/am64x_evm.h b/include/configs/am64x_evm.h
> index 26a7f2521e..456a44730c 100644
> --- a/include/configs/am64x_evm.h
> +++ b/include/configs/am64x_evm.h
> @@ -26,9 +26,9 @@
> #define EXTRA_ENV_AM642_BOARD_SETTINGS
> \
> "findfdt=" \
> "if test $board_name = am64x_gpevm; then " \
> - "setenv fdtfile k3-am642-evm.dtb; fi; " \
> + "setenv fdtfile ti_k3-am642-evm.dtb; fi; " \
> "if test $board_name = am64x_skevm; then " \
> - "setenv fdtfile k3-am642-sk.dtb; fi;" \
> + "setenv fdtfile ti_k3-am642-sk.dtb; fi;" \
Kernel.org builds k3-am642-sk.dtb
Why would we want to go and fix it with non-standard?
> "if test $fdtfile = undefined; then " \
> "echo WARNING: Could not determine device tree to use;
> fi; \0" \
> "name_kern=Image\0" \
> diff --git a/include/configs/am65x_evm.h b/include/configs/am65x_evm.h
> index 33dd6cfdfa..60a7eb1453 100644
> --- a/include/configs/am65x_evm.h
> +++ b/include/configs/am65x_evm.h
> @@ -24,7 +24,7 @@
> /* U-Boot general configuration */
> #define EXTRA_ENV_AM65X_BOARD_SETTINGS
> \
> "findfdt=" \
> - "setenv name_fdt k3-am654-base-board.dtb;" \
> + "setenv name_fdt ti_k3-am654-base-board.dtb;" \
> "setenv fdtfile ${name_fdt}\0" \
> "name_kern=Image\0" \
> "console=ttyS2,115200n8\0" \
> diff --git a/include/configs/j721e_evm.h b/include/configs/j721e_evm.h
> index 48b1cea6e3..eac5cd5b76 100644
> --- a/include/configs/j721e_evm.h
> +++ b/include/configs/j721e_evm.h
> @@ -34,11 +34,11 @@
> #define EXTRA_ENV_J721E_BOARD_SETTINGS
> \
> "default_device_tree=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
> "findfdt=" \
> - "setenv name_fdt ${default_device_tree};" \
> + "setenv name_fdt ti_${default_device_tree};"\
> "if test $board_name = j721e; then "\
> - "setenv name_fdt k3-j721e-common-proc-board.dtb; fi;" \
> + "setenv name_fdt ti_k3-j721e-common-proc-board.dtb;
> fi;" \
> "if test $board_name = j721e-eaik || test $board_name =
> j721e-sk; then "\
> - "setenv name_fdt k3-j721e-sk.dtb; fi;" \
> + "setenv name_fdt ti_k3-j721e-sk.dtb; fi;" \
> "setenv fdtfile ${name_fdt}\0" \
> "name_kern=Image\0" \
> "console=ttyS2,115200n8\0" \
> diff --git a/include/configs/j721s2_evm.h b/include/configs/j721s2_evm.h
> index bfada9eebc..b30a4a8da4 100644
> --- a/include/configs/j721s2_evm.h
> +++ b/include/configs/j721s2_evm.h
> @@ -31,11 +31,11 @@
> #define EXTRA_ENV_J721S2_BOARD_SETTINGS
> \
> "default_device_tree=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
> "findfdt=" \
> - "setenv name_fdt ${default_device_tree};" \
> + "setenv name_fdt ti_${default_device_tree};"\
> "if test $board_name = j721s2; then " \
> - "setenv name_fdt k3-j721s2-common-proc-board.dtb; fi;" \
> + "setenv name_fdt ti_k3-j721s2-common-proc-board.dtb;
> fi;" \
> "if test $board_name = am68-sk; then " \
> - "setenv name_fdt k3-am68-sk-base-board.dtb; fi;"\
> + "setenv name_fdt ti_k3-am68-sk-base-board.dtb; fi;"\
> "setenv fdtfile ${name_fdt}\0" \
> "name_kern=Image\0" \
> "console=ttyS2,115200n8\0" \
> --
> 2.17.1
>
--
Regar
Re: Please pull u-boot-dm
On Fri, Mar 31, 2023 at 10:29:39AM +1300, Simon Glass wrote: > Hi Tom, > > https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/15825 > > > The following changes since commit 565681e596381b5b6db59cf06931e698f2d829e5: > > imx6sx-udoo-neo-basic: Introduce the u-boot.dtsi (2023-03-28 10:58:16 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-dm.git tags/dm-pull-31mar23 > > for you to fetch changes up to a47164dfc1ef899ef9ddc6d8f2a17f0e9e90ef34: > > sysreset: gpio: fix gpio_reboot_request return value (2023-03-31 > 08:32:52 +1300) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH] Revert "spi: zynq_qspi: Use dummy buswidth in dummy byte calculation"
From: Stefan Herbrechtsmeier
This reverts commit e09784728689de7949d4cdd559a9590e0bfcc702. The
commit wrongly divides the dummy bytes by dummy bus width to calculate
the dummy bytes. The framework already converts the dummy cycles to the
number of bytes and the controller use the SPI flash command to
determine the dummy cycles via the address width.
Signed-off-by: Stefan Herbrechtsmeier
---
drivers/spi/zynq_qspi.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/zynq_qspi.c b/drivers/spi/zynq_qspi.c
index 00e3ffcd1d..d1d4048966 100644
--- a/drivers/spi/zynq_qspi.c
+++ b/drivers/spi/zynq_qspi.c
@@ -676,7 +676,6 @@ static int zynq_qspi_exec_op(struct spi_slave *slave,
const struct spi_mem_op *op)
{
int op_len, pos = 0, ret, i;
- u32 dummy_bytes = 0;
unsigned int flag = 0;
const u8 *tx_buf = NULL;
u8 *rx_buf = NULL;
@@ -689,11 +688,6 @@ static int zynq_qspi_exec_op(struct spi_slave *slave,
}
op_len = op->cmd.nbytes + op->addr.nbytes + op->dummy.nbytes;
- if (op->dummy.nbytes) {
- op_len = op->cmd.nbytes + op->addr.nbytes +
-op->dummy.nbytes / op->dummy.buswidth;
- dummy_bytes = op->dummy.nbytes / op->dummy.buswidth;
- }
u8 op_buf[op_len];
@@ -707,8 +701,8 @@ static int zynq_qspi_exec_op(struct spi_slave *slave,
pos += op->addr.nbytes;
}
- if (dummy_bytes)
- memset(op_buf + pos, 0xff, dummy_bytes);
+ if (op->dummy.nbytes)
+ memset(op_buf + pos, 0xff, op->dummy.nbytes);
/* 1st transfer: opcode + address + dummy cycles */
/* Make sure to set END bit if no tx or rx data messages follow */
--
2.30.2
Kommanditgesellschaft - Sitz: Detmold - Amtsgericht Lemgo HRA 2790 -
Komplementärin: Weidmüller Interface Führungsgesellschaft mbH -
Sitz: Detmold - Amtsgericht Lemgo HRB 3924;
Geschäftsführer: Dr. Timo Berger, Volker Bibelhausen, Dr. Sebastian Durst,
André Sombecki;
USt-ID-Nr. DE124599660
[PATCH] common: cli_hush: Restore clear local variable support
From: Stefan Herbrechtsmeier
The u-boot hush shell doesn’t support the unset command to clear a
variable and therefore an empty value ("c=") should be a valid value
for the set_local_var function to clear the variable. This partial
reverts commit aa722529635c ("common: cli_hush: avoid dead code") and
only checks for a `=` in the string. Additionally explicit call the
unset_local_var function to remove the variable if the value is empty.
Signed-off-by: Stefan Herbrechtsmeier
---
common/cli_hush.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/common/cli_hush.c b/common/cli_hush.c
index 1ad7a509df..c3f7dd12a0 100644
--- a/common/cli_hush.c
+++ b/common/cli_hush.c
@@ -2171,12 +2171,18 @@ int set_local_var(const char *s, int flg_export)
* NAME=VALUE format. So the first order of business is to
* split 's' on the '=' into 'name' and 'value' */
value = strchr(name, '=');
- if (value == NULL || *(value + 1) == 0) {
+ if (value == NULL) {
free(name);
return -1;
}
*value++ = 0;
+ if (*value == 0) {
+ unset_local_var(name);
+ free(name);
+ return 0;
+ }
+
for(cur = top_vars; cur; cur = cur->next) {
if(strcmp(cur->name, name)==0)
break;
--
2.30.2
Kommanditgesellschaft - Sitz: Detmold - Amtsgericht Lemgo HRA 2790 -
Komplementärin: Weidmüller Interface Führungsgesellschaft mbH -
Sitz: Detmold - Amtsgericht Lemgo HRB 3924;
Geschäftsführer: Dr. Timo Berger, Volker Bibelhausen, Dr. Sebastian Durst,
André Sombecki;
USt-ID-Nr. DE124599660
[PATCH v3] imx: imx8mm: Add suppoer for Mettler-Toledo snowflake board.
From: Manuel Traut
The board is similar to "Kontron SL i.MX8M Mini" SoM. There are two variants.
Snowflake_v2 has an external SDCard Interface. LEIG is the same, but without
display and without external SDCard Interface. Both variants support
only 1GiB of main memory.
[ bigeasy: porting and a bit of cleanup ]
Signed-off-by: Manuel Traut
Signed-off-by: Sebastian Andrzej Siewior
---
v2…v3:
Addressing Frieder's comments:
- Add "kontron,imx8mm-sl" to the compatible string.
- Remove pca9450 node and pinctrl_i2c1. The included
imx8mm-kontron-sl.dtsi already provides this.
- Merge the overwritten values in dram_timing.ddrc_cfg/fsp_msg directly
into lpddr4_timing.c.
- Simplify the init in spl_dram_init() and panic() if the init failed.
- Replace a reference to SMARC with the current product name of the
SoM.
v1…v2:
- Clarify details about the board and whether or not there is an
external SD-card interface.
arch/arm/dts/Makefile |1 +
.../dts/imx8mm-mt-snowflake-v2-u-boot.dtsi| 116 ++
arch/arm/dts/imx8mm-mt-snowflake-v2.dts | 76 +
arch/arm/mach-imx/imx8m/Kconfig |8 +
board/mt/snowflake_v2/Kconfig | 18 +
board/mt/snowflake_v2/MAINTAINERS |7 +
board/mt/snowflake_v2/Makefile|9 +
board/mt/snowflake_v2/imximage.cfg|8 +
board/mt/snowflake_v2/lpddr4_timing.c | 1844 +
board/mt/snowflake_v2/snowflake_v2.c | 32 +
board/mt/snowflake_v2/snowflake_v2.env| 33 +
board/mt/snowflake_v2/spl.c | 147 ++
configs/snowflake_v2_emmcboot_defconfig | 134 ++
include/configs/snowflake_v2.h| 55 +
14 files changed, 2488 insertions(+)
create mode 100644 arch/arm/dts/imx8mm-mt-snowflake-v2-u-boot.dtsi
create mode 100644 arch/arm/dts/imx8mm-mt-snowflake-v2.dts
create mode 100644 board/mt/snowflake_v2/Kconfig
create mode 100644 board/mt/snowflake_v2/MAINTAINERS
create mode 100644 board/mt/snowflake_v2/Makefile
create mode 100644 board/mt/snowflake_v2/imximage.cfg
create mode 100644 board/mt/snowflake_v2/lpddr4_timing.c
create mode 100644 board/mt/snowflake_v2/snowflake_v2.c
create mode 100644 board/mt/snowflake_v2/snowflake_v2.env
create mode 100644 board/mt/snowflake_v2/spl.c
create mode 100644 configs/snowflake_v2_emmcboot_defconfig
create mode 100644 include/configs/snowflake_v2.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 7a577deb5023d..ba0786064847e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -964,6 +964,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mm-icore-mx8mm-edimm2.2.dtb \
imx8mm-kontron-bl.dtb \
imx8mm-kontron-bl-osm-s.dtb \
+ imx8mm-mt-snowflake-v2.dtb \
imx8mm-mx8menlo.dtb \
imx8mm-phg.dtb \
imx8mm-venice.dtb \
diff --git a/arch/arm/dts/imx8mm-mt-snowflake-v2-u-boot.dtsi
b/arch/arm/dts/imx8mm-mt-snowflake-v2-u-boot.dtsi
new file mode 100644
index 0..d6476db292b79
--- /dev/null
+++ b/arch/arm/dts/imx8mm-mt-snowflake-v2-u-boot.dtsi
@@ -0,0 +1,116 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Mettler Toledo GmbH
+ */
+
+/ {
+
+ aliases {
+ usbgadget0 = &usbg1;
+ };
+
+ usbg1: usbg1 {
+ u-boot,dm-spl;
+ compatible = "fsl,imx27-usb-gadget";
+ dr_mode = "peripheral";
+ chipidea,usb = <&usbotg1>;
+ status = "okay";
+ };
+
+ firmware {
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ };
+ };
+};
+
+&i2c1 {
+ status = "okay";
+ u-boot,dm-spl;
+ u-boot,dm-pre-reloc;
+};
+
+&i2c2 {
+ status = "okay";
+ u-boot,dm-spl;
+ u-boot,dm-pre-reloc;
+};
+
+&pinctrl_ecspi1 {
+ u-boot,dm-spl;
+};
+
+&pinctrl_i2c1 {
+ u-boot,dm-spl;
+};
+
+&pinctrl_pmic {
+ u-boot,dm-spl;
+};
+
+&pinctrl_uart3 {
+ u-boot,dm-spl;
+ u-boot,dm-pre-reloc;
+};
+
+&pinctrl_usdhc1 {
+ u-boot,dm-spl;
+};
+
+&pinctrl_usdhc1_100mhz {
+ u-boot,dm-spl;
+};
+
+&pinctrl_usdhc1_200mhz {
+ u-boot,dm-spl;
+};
+
+&pca9450 {
+ u-boot,dm-spl;
+};
+
+&{/soc@0/bus@3080/i2c@30a2/pmic@25/regulators} {
+ u-boot,dm-spl;
+};
+
+&ecspi1 {
+ u-boot,dm-spl;
+};
+
+&gpio1 {
+ u-boot,dm-spl;
+};
+
+&gpio2 {
+ u-boot,dm-spl;
+};
+
+&gpio3 {
+ u-boot,dm-spl;
+};
+
+&gpio4 {
+ u-boot,dm-spl;
+};
+
+&gpio5 {
+ u-boot,dm-spl;
+};
+
+&uart3 {
+ u-boot,dm-spl;
+ u-boot,dm-pre-reloc;
+};
+
+&usdhc1 {
+ u-boot,dm-spl;
+};
+
+&wdog1 {
+ u-boot,dm-spl;
+};
+
+&pinctrl_wdog {
+ u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/imx8mm-mt-snowflake-v2.dts
b/arch/arm/dts/imx8mm-mt-snowflake-v2.dts
new file mode 100644
index 0..f56997543e6d9
--- /dev/null
Re: [PATCH v2 1/1] input: button_kbd: make driver complementary to gpio buttons
On Mon, Mar 20, 2023 at 09:06:30PM +0200, Svyatoslav Ryhel wrote: > Remove need of dts binding for button keyboard since it reuses > gpio-keys binding. Select gpio-keys driver if button keyboard > is selected since button keyboard can not operate on its own. > > Tested-by: Svyatoslav Ryhel # HTC One X T30 > Signed-off-by: Svyatoslav Ryhel > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 1/1] cmd: ums: abort mounting by pressing any key
On Mon, Mar 20, 2023 at 09:01:43PM +0200, Svyatoslav Ryhel wrote: > This patch introduses config which allows interrupt run of usb > mass storage with any key. This is especially useful on devices > with limited input capabilities like tablets and smatphones which > have only gpio keys in direct access. > > Signed-off-by: Svyatoslav Ryhel > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] disk: Use a helper function to reduce duplication
On Mon, Mar 20, 2023 at 08:29:57AM +1300, Simon Glass wrote: > Reduce the duplicated code slightly by using a helper function to handle > the common code. > > This reduces the code size very slightly. > > Signed-off-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] lib: Fix SYS_TIMER_COUNTS_DOWN description in Kconfig
On Sun, Mar 19, 2023 at 04:13:02AM +0100, Marek Vasut wrote: > The SYS_TIMER_COUNTS_DOWN description contains a typo, > s@rathe@&r@ , fix it. > > Signed-off-by: Marek Vasut Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] gpio: allow passing NULL to gpio_request_by_line_name() to search all gpio controllers
On Fri, Mar 17, 2023 at 09:12:22PM +0100, Rasmus Villemoes wrote: > The API is more convenient to use if one doesn't have to know upfront > which gpio controller has a line with the name one is searching for, > and arrange to look that device up somehow. Or implement this loop > oneself. > > Signed-off-by: Rasmus Villemoes > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] image: Fix potentially uninitialized data variable
On Mon, Feb 27, 2023 at 08:56:31PM +0100, Marek Vasut wrote: > In case fitImage support is disabled, and image_locate_script() is > passed a fitImage, then the 'data' variable is used uninitialized. > Drop into the default: branch of the switch-case statement and do > not return the uninitialized data, and do not modify the return > pointer either, just print an error message. > > Reported by clang build: > " > $ make HOSTCC=clang CC=clang KCFLAGS=-Werror sandbox64_defconfig && make > HOSTCC=clang CC=clang KCFLAGS=-Werror > ... > boot/image-board.c:1006:7: error: variable 'data' is used uninitialized > whenever switch case is taken [-Werror,-Wsometimes-uninitialized] > case IMAGE_FORMAT_LEGACY: > ^~~ > include/image.h:608:29: note: expanded from macro 'IMAGE_FORMAT_LEGACY' > ^~~~ > boot/image-board.c:1128:19: note: uninitialized use occurs here > *datap = (char *)data; > ^~~~ > boot/image-board.c:1001:11: note: initialize the variable 'data' to silence > this warning > u32 *data; > ^ > = NULL > " > > Signed-off-by: Marek Vasut > Reviewed-by: Tom Rini > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 3/3] test: Add test for new command pci_mps
On Fri, Mar 10, 2023 at 11:07:15AM -0800, stcar...@linux.microsoft.com wrote: > From: Stephen Carlson > > Adds a test for the new pci_mps command to ensure that it can set the > Maximum Payload Size (MPS) of all devices to 256 bytes in the sandbox > environment. Enables the pci_mps command in the sandbox environment so > that this test can be run. > > Signed-off-by: Stephen Carlson Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 2/3] drivers: pci: sandbox: Add stub sandbox PCI MPS support
On Fri, Mar 10, 2023 at 11:07:14AM -0800, stcar...@linux.microsoft.com wrote: > From: Stephen Carlson > > Reports the sandbox swapcase PCI Express device to support a 256 byte > Maximum Payload Size for MPS tuning tests. > > Signed-off-by: Stephen Carlson > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/3] cmd: pci: Add command to set MPS of all PCIe devices
On Fri, Mar 10, 2023 at 11:07:13AM -0800, stcar...@linux.microsoft.com wrote: > From: Stephen Carlson > > Enable tuning of the PCI Express MPS (Maximum Payload Size) of > each device. The Maximum Read Request Size is not altered. > > The SAFE method uses the largest MPS value supported by all devices in the > system for each device. This method is the same algorithm as used by Linux > pci=pcie_bus_safe. > > The PEER2PEER method sets all devices to the minimal (128 byte) MPS, which > allows hot plug of devices later that might only support the minimum size, > and ensures compatibility of DMA between two devices on the bus. > > Signed-off-by: Stephen Carlson Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] sysinfo: gpio: fix loop over DT "revisions" array
On Fri, Mar 10, 2023 at 11:58:03AM +0100, Rasmus Villemoes wrote: > There can certainly be a lot more elements in the "revisions" (and > "names") arrays than there are gpios used to form the trinary number > we're searching for; we simply don't know the array size up-front. > > Nor do we need to, because the loop body already knows to recognize > -EOVERFLOW as "not that many elements present" (and we have a test > that specifically ensures that dev_read_u32_index() returns exactly > that). So just drop the i < priv->gpio_num condition. > > While in here, fix the weird placement of the default: keyword. > > Signed-off-by: Rasmus Villemoes > Reviewed-by: Simon Glass > Reviewed-by: Sean Anderson Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] nvedit: simplify do_env_indirect()
On Mon, Mar 06, 2023 at 02:27:21PM +0100, Rasmus Villemoes wrote: > Instead of calling env_get(from) up to three times, just do it once, > computing the value we will put into 'to' and error out if that is > NULL (i.e. no 'from' variable and no default provided). > > No functional change. > > Signed-off-by: Rasmus Villemoes > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] test: fs: Check fat short file name
On Wed, Mar 22, 2023 at 09:46:02AM +0100, Stefan Herbrechtsmeier wrote: > From: Stefan Herbrechtsmeier > > Ensure that a freshly written fat file with a lower case filename which > fits into the upper case 8.3 short filename is not mangeled with a tilde > and number. > > Signed-off-by: Stefan Herbrechtsmeier Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 4/4] test: exit: fix run_commandf() warnings
On Mon, Mar 20, 2023 at 11:23:14AM +0300, Evgeny Bachinin wrote: > Fix warnings after adding printf-like attribute format for > run_commandf(): > warning: too many arguments for format [-Wformat-extra-args] > > Signed-off-by: Evgeny Bachinin > Reviewed-by: Simon Glass > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 3/4] test: fdt: fix run_commandf() warnings
On Mon, Mar 20, 2023 at 11:23:13AM +0300, Evgeny Bachinin wrote:
> Fix warnings both for 32bit and 64bit architecture after adding
> printf-like attribute format for run_commandf():
> warning: format ‘%x’ expects argument of type ‘unsigned int’, but
> argument 2 has type ‘ulong {aka long unsigned int}’ [-Wformat=]
> ret = run_commandf("fdt addr -c %08x", addr);
> ^
> Signed-off-by: Evgeny Bachinin
> Cc: Marek Vasut
> Reviewed-by: Simon Glass
Applied to u-boot/next, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 1/1] api: move API related config options into submenu
On Fri, Mar 03, 2023 at 11:31:22PM +0100, Heinrich Schuchardt wrote: > Kconfig settings that are related to the API for standalone applications > should be in the API sub-menu and not on the top level. > > CONFIG_STANDALONE_LOAD_ADDR is only relevant if standalone example > applications are built. > > Signed-off-by: Heinrich Schuchardt Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] Kconfig: Sort the BUILD_TARGET list
On Tue, Feb 28, 2023 at 07:22:21AM +0100, Marek Vasut wrote: > Sort the defaults list in BUILD_TARGET Kconfig option. No functional change. > > Signed-off-by: Marek Vasut > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] powerpc/mpc85xx: disable legacy format booting
On Thu, Feb 23, 2023 at 07:03:47AM +0100, Heiko Schocher wrote: > disable CONFIG_LEGACY_IMAGE_FORMAT so prevent of booting > not signed fitimages. > > Signed-off-by: Heiko Schocher Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] fs: ext4: fix files seen as symlink during deletion
On Fri, Mar 17, 2023 at 01:15:12PM +0100, Corentin GUILLEVIC wrote: > The deletion process handles special case for symlinks whose target are > small enough that it fits in struct ext2_inode.b.symlink. So no block had > been allocated. But the check of file type wrongly considered regular > files as symlink. So, no block was freed. So, the EXT4 partition could be > corrupted because of no free block available. > > Signed-off-by: Corentin GUILLEVIC Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 2/4] unit-test: cover run_commandf() by test-cases
On Mon, Mar 20, 2023 at 11:23:12AM +0300, Evgeny Bachinin wrote:
> As run_commandf() is variadic version of run_command() and just a wrapper,
> hence apply similar run_command's test-cases.
>
> Let's avoid warning about empty string passing:
> warning: zero-length gnu_printf format string [-Wformat-zero-length]
>assert(run_commandf("") == 0);
>
> Signed-off-by: Evgeny Bachinin
> Reviewed-by: Simon Glass
Applied to u-boot/next, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] fs: fat: do not mangle short filenames
On Fri, Mar 17, 2023 at 01:04:13PM +0100, Stefan Herbrechtsmeier wrote: > From: Stefan Herbrechtsmeier > > Do not mangle lower or mixed case filenames which fit into the upper > case 8.3 short filename. This ensures FAT standard compatible short > filenames (SFN) to support systems without long filename (LFN) support > like boot roms (ex. SFN BOOT.BIN instead of BOOT~1.BIN for LFN > boot.bin). > > Signed-off-by: Stefan Herbrechtsmeier Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/4] cli: run_commandf(): small fixups
On Mon, Mar 20, 2023 at 11:23:11AM +0300, Evgeny Bachinin wrote: > * vsnprintf() can truncate cmd, hence it makes no sense to launch such > command (it's broken). Moreover, it's better to signalize to the caller > about such case (for facilitating debugging or bug hunting). > > * Fix kernel-doc warnings: > include/command.h:264: info: Scanning doc for run_commandf > include/command.h:268: warning: contents before sections > include/command.h:271: warning: No description found for return value > of 'run_commandf' > > * Add printf-like format attribute to validate at compile-time the format > string against parameters's type. > > * Fix compilation error in case of -Wall, -Werror, -Wextra: > error: variable ‘i’ set but not used [-Werror=unused-but-set-variable] > > * Drop extra ret variable. > > Signed-off-by: Evgeny Bachinin > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 2/2] drivers: rtc: add max313xx series rtc driver
On Mon, Mar 20, 2023 at 10:23:44AM +1300, Chris Packham wrote: > Adding support for Analog Devices MAX313XX series RTCs. > > This is ported from the Linux driver and adapted for use in u-boot. > Notable differences are > - handling of tm_year and tm_mon differ > - clock source support is omitted > - hwmon support for the MAX31328 and MAX31343 is omitted > - rtc_ops->reset is added > > Signed-off-by: Chris Packham > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/2] include: kernel.h: port find_closest() from Linux
On Mon, Mar 20, 2023 at 10:23:43AM +1300, Chris Packham wrote: > The find_closest() macro can be used to find an element in a sorted > array that is closest to an input value. Bring in this macro from > Linux v6.3-rc1-2-g8ca09d5fa354. > > Signed-off-by: Chris Packham > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] rtc: m41t62: implements read8/write8 operations
On Fri, Mar 17, 2023 at 03:22:41PM +0100, thomas.per...@bootlin.com wrote: > From: Thomas Perrot > > These operations are required by dm_rtc_read and > dm_bootcount_get helpers. > > Signed-off-by: Thomas Perrot > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] imx: imx8mm: Add suppoer for Mettler-Toledo snowflake board.
On 2023-03-16 11:33:47 [+0100], Frieder Schrempf wrote:
> > diff --git a/arch/arm/dts/imx8mm-mt-snowflake-v2.dts
> > b/arch/arm/dts/imx8mm-mt-snowflake-v2.dts
> > new file mode 100644
> > index 0..49761b22afcf0
> > --- /dev/null
> > +++ b/arch/arm/dts/imx8mm-mt-snowflake-v2.dts
> > @@ -0,0 +1,186 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2020 Mettler Toledo GmbH
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "imx8mm-kontron-sl.dtsi"
> > +#include "imx8mm-u-boot.dtsi"
> > +
> > +/ {
> > + model = "Mettler Toledo i.MX8MM Snowflake V2";
> > + compatible = "mt,imx8mm-snowflake-v2", "fsl,imx8mm";
>
> I think the compatible would normally include the SoM:
>
> compatible = "mt,imx8mm-snowflake-v2", "kontron,imx8mm-sl", "fsl,imx8mm";
This might work. Let me add it.
…
> > +
> > +&i2c1 {
> > + clock-frequency = <40>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_i2c1>;
> > + status = "okay";
> > +
> > + pca9450: pmic@25 {
…
> > +};
>
> The included SoM DTSI already contains the PMIC node. You can remove
> that here. Or if you need to do adjustments for the board level you
> should only overwrite what is needed instead of duplicating everything.
They appear to identical except for the regulator-name but this does not
matter. Dropping that then.
…
> > + pinctrl_i2c1: i2c1grp {
> > + fsl,pins = <
> > + MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL
> > 0x41c3
> > + MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA
> > 0x41c3
> > + >;
> > + };
>
> Same here, this node is already available from the SoM DTSI.
gone.
…
> > diff --git a/board/mt/snowflake_v2/spl.c b/board/mt/snowflake_v2/spl.c
> > new file mode 100644
> > index 0..3e27256914b32
> > --- /dev/null
> > +++ b/board/mt/snowflake_v2/spl.c
…
> > + dram_timing.fsp_msg[0].fsp_cfg[9].val = 0x110;
> > + dram_timing.fsp_msg[0].fsp_cfg[21].val = 0x1;
> > + dram_timing.fsp_msg[1].fsp_cfg[10].val = 0x110;
> > + dram_timing.fsp_msg[1].fsp_cfg[22].val = 0x1;
> > + dram_timing.fsp_msg[2].fsp_cfg[10].val = 0x110;
> > + dram_timing.fsp_msg[2].fsp_cfg[22].val = 0x1;
> > + dram_timing.fsp_msg[3].fsp_cfg[10].val = 0x110;
> > + dram_timing.fsp_msg[3].fsp_cfg[22].val = 0x1;
>
> As you only support the 1GB DDR on this board, you could integrate these
> values directly in the tables in lpddr4_timing.c and remove them here.
I'm not sure how much of the header file is auto-generated including
these bits here.
Let me merge this now and worry later.
> > +
> > + if (!ddr_init(&dram_timing) && check_ram_available(SZ_1G)) {
> > + size = 1;
> > + puts("1GB DDR RAM\n");
> > + } else {
> > + puts("Init DDR RAM failed\n");
> > + size = 1;
> > + }
> > +
> > + writel(size, M4_BOOTROM_BASE_ADDR);
>
> You could also simplify this and improve the error handling for your case:
>
> if (ddr_init(&dram_timing) || !check_ram_available(SZ_1G)) {
> puts("Init DDR RAM failed\n");
> halt();
> }
>
> puts("1GB DDR RAM\n");
> writel(1, M4_BOOTROM_BASE_ADDR);
Why not. There is not "halt()" in tree so I'm going to substite that
block with panic().
…
> > diff --git a/include/configs/snowflake_v2.h b/include/configs/snowflake_v2.h
> > new file mode 100644
> > index 0..f038dc9e6d7d8
> > --- /dev/null
> > +++ b/include/configs/snowflake_v2.h
> > @@ -0,0 +1,54 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * Copyright (C) 2019 Kontron Electronics GmbH
> > + * Copyright (C) 2020 Mettler Toledo GmbH
> > + *
> > + * Configuration settings for the MT Snowflake v2 Terminal, based on
> > Kontron N8000 i.MX8MM SMARC module.
>
> It's not a SMARC module. And nowadays the proper product name is
> "Kontron SL i.MX8M Mini".
okay.
That should have been all of your comments.
Sebastian
Newer U-Boot version throwing "Bootstage space exhasuted" with FIT image
Hi, I changed from v2020.10 to v2022.10 and suddenly I get a bunch of "Bootstage space exhasuted" messages during bootm. reloc pc : [] is memcpy() It evens triggers a reset. Older version works just fine: Sign value: unavailable Timestamp:unavailable Verifying Hash Integrity ... sha256+ OK Bootstage space exhasuted Bootstage space exhasuted Bootstage space exhasuted Bootstage space exhasuted Loading fdt from 0xc272de94 to 0xc400 Bootstage space exhasuted Booting using the fdt blob at 0xc400 Loading Kernel Image kernel loaded at 0xc0008000, end = 0xc0735c80 Bootstage space exhasuted Bootstage space exhasuted Loading Ramdisk to cfd23000, end c105 ... OK Loading Device Tree to cfd1, end cfd22375 ... OK Bootstage space exhasuted Bootstage space exhasuted Starting kernel ... data abort pc : [] lr : [<>] reloc pc : []lr : [] sp : fbf2786c ip : fp : 0001 r10: c2d8 r9 : fbf37eb0 r8 : r7 : r6 : r5 : e28ff010 r4 : r3 : r2 : 0a10 r1 : fdfabb14 r0 : 2ffc0020 Flags: nzCv IRQs off FIQs off Mode SVC_32 (T) Code: f891 f03c f891 f05c (f891) f07c Resetting CPU ... resetting ...
Re: [PATCH v3 1/3] starfive: pci: Add StarFive JH7110 pcie driver
On Friday 31 March 2023 18:35:00 Minda Chen wrote: > On 2023/3/30 1:27, Pali Rohár wrote: > > Hello! > > > > On Wednesday 29 March 2023 18:01:41 Minda Chen wrote: > >> + /* PCIe PCI Standard Configuration Identification Settings. */ > >> + value = (PCI_CLASS_BRIDGE_PCI_NORMAL << IDS_CLASS_CODE_SHIFT) | > >> IDS_REVISION_ID; > >> + writel(value, priv->reg_base + PCIE_PCI_IDS); > > > > This looks like configuration of the PCI_CLASS_REVISION read-only > > register. Is there any reason why you are removing the original > > "revision" information by hardcoded IDS_REVISION_ID constant? > > > This register is not read-only register, consist resion ID and class code. > Bit [39:32]: Revision ID > Bit [63:40]: Class code I mean that this "priv->reg_base + PCIE_PCI_IDS" read-write register configures what is visible when reading read-only standard PCI register PCI_CLASS_REVISION. PCIe Root Port is by definition of PCI-to-PCI Bridge class and therefore reading from PCI_CLASS_REVISION must return PCI_CLASS_BRIDGE_PCI_* value. This is required by PCIe spec. With above driver init code it looks like that your PCIe controller does not set correct value into PCI_CLASS_REVISION register after power-on and manually setting correct value via "priv->reg_base + PCIE_PCI_IDS" is a workaround. Hopefully it is a more clear what I mean in my previous email. Also mvebu controller has this issue and has similar workaround in pci_mvebu.c driver. > And the register reset value is zero, Our PCIe version is 2.0. So set value 2. > Maybe I will add comment to this. Well, Revision ID (low 8 bits of PCI_CLASS_REVISION) is the extension to the vendor / device id register. It is not version of PCIe standard. I would expect that this Vendor ID, Device ID and Revision ID values are not being changed by the driver as they identify PCI and PCIe devices.
Re: [PATCH 3/5] arm: dts: add DMA and CPSW nodes for uboot
Hi Bryan,
On 28/03/23 12:10 am, Bryan Brattlof wrote:
> Update the uboot dtsi to enable DMA and CPSW at the uboot level
>
> Signed-off-by: Bryan Brattlof
> ---
> arch/arm/dts/k3-am62a7-r5-sk.dts | 8
> arch/arm/dts/k3-am62a7-sk-u-boot.dtsi | 26 +-
> 2 files changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/dts/k3-am62a7-r5-sk.dts
> b/arch/arm/dts/k3-am62a7-r5-sk.dts
> index 58b7c8ad050fd..ea2e202237556 100644
> --- a/arch/arm/dts/k3-am62a7-r5-sk.dts
> +++ b/arch/arm/dts/k3-am62a7-r5-sk.dts
> @@ -141,3 +141,11 @@
> status = "okay";
> u-boot,dm-spl;
> };
> +
> +&main_pktdma {
> + ti,sci = <&dm_tifs>;
> +};
> +
> +&main_bcdma {
> + ti,sci = <&dm_tifs>;
> +};
> diff --git a/arch/arm/dts/k3-am62a7-sk-u-boot.dtsi
> b/arch/arm/dts/k3-am62a7-sk-u-boot.dtsi
> index 7fc749ed70976..07ade7120cfe5 100644
> --- a/arch/arm/dts/k3-am62a7-sk-u-boot.dtsi
> +++ b/arch/arm/dts/k3-am62a7-sk-u-boot.dtsi
> @@ -15,7 +15,7 @@
> };
> };
>
> -&cbass_main{
> +&cbass_main {
> u-boot,dm-spl;
>
> timer1: timer@240 {
> @@ -138,3 +138,27 @@
> &vdd_mmc1 {
> u-boot,dm-spl;
> };
> +
> +&main_bcdma {
> + u-boot,dm-spl;
> +};
"u-boot,dm-spl" is now "bootph-pre-ram". The changes are present in -next.
For the existing DT source files, these have already been taken care of [0]
So please base on -next. Otherwise the series LGTM
[0] https://lore.kernel.org/all/20230213155641.1208774-4-...@chromium.org/
> +
> +&main_pktdma {
> + u-boot,dm-spl;
> +};
> +
> +&cpsw3g {
> + reg = <0x00 0x0800 0x00 0x20>,
> + <0x00 0x43000200 0x00 0x8>;
> + reg-names = "cpsw_nuss", "mac_efuse";
> + /delete-property/ ranges;
> + pinctrl-0 = <&main_mdio1_pins_default
> + &main_rgmii1_pins_default>;
> + u-boot,dm-spl;
> +
> + cpsw-phy-sel@04044 {
> + compatible = "ti,am64-phy-gmii-sel";
> + reg = <0x00 0x00104044 0x00 0x8>;
> + u-boot,dm-spl;
> + };
> +};
--
Regards,
Ravi
[PATCH] watchdog: arm_smc_wdt: add watchdog support
Implement a ARM SMCCC based driver that allow to use
a secure watchdog on the platform.
Signed-off-by: Lionel Debieve
---
drivers/watchdog/Kconfig | 8 +++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/arm_smc_wdt.c | 116 +
3 files changed, 125 insertions(+)
create mode 100644 drivers/watchdog/arm_smc_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index b5ac8f7f50d..3a0341f609d 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -352,6 +352,14 @@ config WDT_TANGIER
Intel Tangier SoC. If you're using a board with Intel Tangier
SoC, say Y here.
+config WDT_ARM_SMC
+ bool "ARM SMC watchdog timer support"
+ depends on WDT && ARM_SMCCC
+ imply WATCHDOG
+ help
+ Select this to enable Arm SMC watchdog timer. This watchdog will
manage
+ a watchdog based on ARM SMCCC communication.
+
config SPL_WDT
bool "Enable driver model for watchdog timer drivers in SPL"
depends on SPL_DM
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 446d961d7d2..a4633c0d2fa 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_$(SPL_TPL_)WDT) += wdt-uclass.o
obj-$(CONFIG_WDT_SANDBOX) += sandbox_wdt.o
obj-$(CONFIG_WDT_ALARM_SANDBOX) += sandbox_alarm-wdt.o
obj-$(CONFIG_WDT_APPLE) += apple_wdt.o
+obj-$(CONFIG_WDT_ARM_SMC) += arm_smc_wdt.o
obj-$(CONFIG_WDT_ARMADA_37XX) += armada-37xx-wdt.o
obj-$(CONFIG_WDT_ASPEED) += ast_wdt.o
obj-$(CONFIG_WDT_AST2600) += ast2600_wdt.o
diff --git a/drivers/watchdog/arm_smc_wdt.c b/drivers/watchdog/arm_smc_wdt.c
new file mode 100644
index 000..e2e3c455082
--- /dev/null
+++ b/drivers/watchdog/arm_smc_wdt.c
@@ -0,0 +1,116 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * ARM Secure Monitor Call watchdog driver
+ * Copyright (C) 2022, STMicroelectronics - All Rights Reserved
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "arm_smc_wdt"
+#define DRV_VERSION"1.0"
+
+#define WDT_TIMEOUT_SECS(TIMEOUT) ((TIMEOUT) / 1000)
+
+enum smcwd_call {
+ SMCWD_INIT = 0,
+ SMCWD_SET_TIMEOUT = 1,
+ SMCWD_ENABLE= 2,
+ SMCWD_PET = 3,
+ SMCWD_GET_TIMELEFT = 4,
+};
+
+struct smcwd_priv_data {
+ u32 smc_id;
+ unsigned int min_timeout;
+ unsigned int max_timeout;
+};
+
+static int smcwd_call(struct udevice *dev, enum smcwd_call call,
+ unsigned long arg, struct arm_smccc_res *res)
+{
+ struct arm_smccc_res local_res;
+ struct smcwd_priv_data *priv = dev_get_priv(dev);
+
+ if (!res)
+ res = &local_res;
+
+ arm_smccc_smc(priv->smc_id, call, arg, 0, 0, 0, 0, 0, res);
+
+ if (res->a0 == PSCI_RET_NOT_SUPPORTED)
+ return -ENODEV;
+ if (res->a0 == PSCI_RET_INVALID_PARAMS)
+ return -EINVAL;
+ if (res->a0 != PSCI_RET_SUCCESS)
+ return -EIO;
+
+ return 0;
+}
+
+static int smcwd_reset(struct udevice *dev)
+{
+ return smcwd_call(dev, SMCWD_PET, 0, NULL);
+}
+
+static int smcwd_stop(struct udevice *dev)
+{
+ return smcwd_call(dev, SMCWD_ENABLE, 0, NULL);
+}
+
+static int smcwd_start(struct udevice *dev, u64 timeout_ms, ulong flags)
+{
+ int err;
+ u64 timeout_sec = WDT_TIMEOUT_SECS(timeout_ms);
+ struct smcwd_priv_data *priv = dev_get_priv(dev);
+
+ if (timeout_sec < priv->min_timeout || timeout_sec > priv->max_timeout)
+ return -EINVAL;
+
+ err = smcwd_call(dev, SMCWD_SET_TIMEOUT, timeout_sec, NULL);
+ if (err)
+ return err;
+
+ return smcwd_call(dev, SMCWD_ENABLE, 1, NULL);
+}
+
+static int smcwd_probe(struct udevice *dev)
+{
+ int err;
+ struct arm_smccc_res res;
+ struct smcwd_priv_data *priv = dev_get_priv(dev);
+
+ priv->smc_id = dev_read_u32_default(dev, "arm,smc-id", 0x82003D06);
+
+ err = smcwd_call(dev, SMCWD_INIT, 0, &res);
+ if (err < 0)
+ return err;
+
+ priv->min_timeout = res.a1;
+ priv->max_timeout = res.a2;
+
+ return 0;
+}
+
+static const struct wdt_ops smcwd_ops = {
+ .start = smcwd_start,
+ .stop = smcwd_stop,
+ .reset = smcwd_reset,
+};
+
+static const struct udevice_id smcwd_dt_ids[] = {
+ { .compatible = "arm,smc-wdt" },
+ {}
+};
+
+U_BOOT_DRIVER(wdt_sandbox) = {
+ .name = "smcwd",
+ .id = UCLASS_WDT,
+ .of_match = smcwd_dt_ids,
+ .priv_auto = sizeof(struct smcwd_priv_data),
+ .probe = smcwd_probe,
+ .ops = &smcwd_ops,
+};
--
2.25.1
[PATCH] Modify the print log when adma is not supported
---
drivers/mmc/sdhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index c6b250b9a1..4e57e12732 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -882,7 +882,7 @@ int sdhci_setup_cfg(struct mmc_config *cfg, struct
sdhci_host *host,
#endif
#if CONFIG_IS_ENABLED(MMC_SDHCI_ADMA)
if (!(caps & SDHCI_CAN_DO_ADMA2)) {
- printf("%s: Your controller doesn't support SDMA!!\n",
+ printf("%s: Your controller doesn't support ADMA!!\n",
__func__);
return -EINVAL;
}
--
2.25.1
Re: WIP: Signing TI x509 certificates using binman
Hi Simon On 31/03/23 02:01, Simon Glass wrote: Hi Neha, On Fri, 24 Mar 2023 at 22:28, Neha Malcom Francis wrote: Hi Simon, Before I roll out the entire series that works for packaging K3 bootloader images, wanted to get some reviews and comments regarding the implementation of the signing etype [1] . I believe I've taken into consideration what we've discussed earlier [2]. Let me know your thoughts. The tree is also WIP, and was mainly designed for testing the signing etype on two of the devices. I will add the remaining and refine the series based on the next comments. Yes this looks reasonable to me. For the openssl method, can you create a new 'real' method and put the cert stuff in there instead of using a 'custom' one? It seems to have a lot in common with what is there. We should really have an internal cert-generator method in that class, with other functions in that class doing appropriate things. I am looking for code reuse here, as well as clear indication of what the cert is for or does. So you're suggesting to include the config creation within the openssl btool, am I right? For example methods to generate a config, add section to a config, add extension to a section of a config... etc? I can take a look at implementing this if this is what you have suggested. If most of the cert is the same, you could pass a dict for the CN stuff, perhaps? What is the taml for? It is hard to tell, from the example provided. Did you mean YAML? If so in the patch I linked, I don't think I had a example for that. Could you point out what exactly you're asking about? Do you have a .dts which shows the full image for a board? I think the cert stuff looks right, but it's a bit hard to tell. Yes, in the same github link I have the whole tree [3] that contains DTBs for couple of the devices [4] and [5], please have a look and let me know (I might force push a few changes in the next couple of days, so better to look from the tree) When sending the patches please do do follow the function-commenting style and make sure that it is clear what each arg means. E.g. I saw a hash integer which I assume is used to pass 256 or 384 or 512 for sha hashing. It should indicate the possible values / meaning in the arg. In fact, in that case, it might be better to pass a string like 'sha256'. Yes, you're right. Will address that when sending the patch series completely. Anyway, apart from my questions it seems good. Regards, Simon [1] https://github.com/nehamalcom/u-boot/commit/ea7413ed5864340bd6f01e704e8bdcc073a7896b#diff-efb03d61a324724c4f86bf42b45c4e4e614cab18e1b3184f63721d62280a11b5 [2] https://patchwork.ozlabs.org/project/uboot/patch/20230224120340.587786-1-n-fran...@ti.com/ -- Thanking You Neha Malcom Francis [3] https://github.com/nehamalcom/u-boot/commits/ti-secure-functionality [4] https://github.com/nehamalcom/u-boot/commit/dda1f9caf436df59c576466f35262df90aa1c0af -- Thanking You Neha Malcom Francis
Re: [PATCH v3 1/3] starfive: pci: Add StarFive JH7110 pcie driver
On 2023/3/30 1:27, Pali Rohár wrote:
> Hello!
>
> On Wednesday 29 March 2023 18:01:41 Minda Chen wrote:
>> From: Mason Huo
>>
>> Add pcie driver for StarFive JH7110, the driver depends on
>> starfive gpio, pinctrl, clk and reset driver to do init.
>>
>> Several devices are tested:
>> a) M.2 NVMe SSD
>> b) Realtek 8169 Ethernet adapter.
>>
>> Signed-off-by: Mason Huo
>> Signed-off-by: Minda Chen
>> ---
>> drivers/pci/Kconfig| 11 +
>> drivers/pci/Makefile | 1 +
>> drivers/pci/pcie_starfive_jh7110.c | 463 +
>> 3 files changed, 475 insertions(+)
>> create mode 100644 drivers/pci/pcie_starfive_jh7110.c
>>
>> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
>> index ef328d2652..e7b0ff5bc3 100644
>> --- a/drivers/pci/Kconfig
>> +++ b/drivers/pci/Kconfig
>> @@ -374,4 +374,15 @@ config PCIE_UNIPHIER
>>Say Y here if you want to enable PCIe controller support on
>>UniPhier SoCs.
>>
>> +config PCIE_STARFIVE_JH7110
>> +bool "Enable Starfive JH7110 PCIe driver"
>> +depends on STARFIVE_JH7110
>> +depends on PINCTRL_STARFIVE_JH7110
>> +depends on CLK_JH7110
>> +depends on RESET_JH7110
>
> There is no direct hard dependency on on these 4 symbols (or at least I
> do not see any in include header files). So to allow compile time
> checks, change it to just soft dependency by switching from "depends" to
> "imply" keyword.
>
ok， I will change this.
>> +default y
>> +help
>> + Say Y here if you want to enable PCIe controller support on
>> + StarFive JH7110 SoC.
>> +
>> endif
> ...
>> diff --git a/drivers/pci/pcie_starfive_jh7110.c
>> b/drivers/pci/pcie_starfive_jh7110.c
>> new file mode 100644
>> index 00..1005ed9919
>> --- /dev/null
>> +++ b/drivers/pci/pcie_starfive_jh7110.c
> ...
>> +static int starfive_pcie_off_conf(pci_dev_t bdf, uint offset)
>> +{
>> +unsigned int bus = PCI_BUS(bdf);
>> +unsigned int dev = PCI_DEV(bdf);
>> +unsigned int func = PCI_FUNC(bdf);
>> +
>> +return PCIE_ECAM_OFFSET(bus, dev, func, offset);
>
> This function is used just on one place, it is pretty straightforward
> and nothing starfive_pcie-specific. Just directly inline it into
> starfive_pcie_conf_address() function?
>
> int where = PCIE_ECAM_OFFSET(PCI_BUS(bdf), PCI_DEV(bdf), PCI_FUNC(bdf),
> offset);
>
ok, thanks
>> +}
>> +
>> +static int starfive_pcie_addr_valid(pci_dev_t bdf, int first_busno)
>> +{
>> +/*
>> + * Single device limitation.
>> + * For JH7110 SoC limitation, one bus can only connnect one device.
>> + * And PCIe controller contain HW issue that non-root host bridge
>> + * bus emumerate duplicate devices.
>> + * Only can access device 0 in Bus 1 host bridge.
>> + */
>> +if ((PCI_BUS(bdf) != first_busno) && (PCI_DEV(bdf) > 0))
>> +return 0;
>
> In v2 discussion you wrote that the issue with duplicate devices is on
> the bus 1, which is secondary bus - the bus behind the root port.
>
> So check against root port bus (first_busno) is not correct, you need to
> check it against bus behind the root port (secondary bus).
>
> Current check completely filters all devices with numbers higher than 0
> behind the secondary bus, which completely breaks support for PCIe
> switches. Moreover behind PCIe switch can be anything with more
> complicated topology.
>
> That secondary bus number is dynamically allocated / assigned by U-Boot
> core code, so you need to check PCI_SECONDARY_BUS register of the root
> port.
>
> In pci_mvebu.c is this value cached in "->sec_busno" member. You can
> reuse this pattern.
>
> You probably want this kind of check:
>
> if (PCI_BUS(bdf) == priv->sec_busno && PCI_DEV(bdf) > 0)
> return false;
> else
> return true;
>
OK, thanks， I will record secondary busno according PCI_SECONDARY_BUS register
> Also comment "non-root host bridge bus" is strange. Bus of the host
> bridge is always the root one. You probably want to write the bus
> immediately behind the root bus / host bridge OR the secondary bus of
> the host bridge.
>
ok
>> +return 1;
>> +}
>> +
>> +static int starfive_pcie_conf_address(const struct udevice *udev, pci_dev_t
>> bdf,
>> + uint offset, void **paddr)
>> +{
>> +struct starfive_pcie *priv = dev_get_priv(udev);
>> +int where = starfive_pcie_off_conf(bdf, offset);
>> +
>> +if (!starfive_pcie_addr_valid(bdf, priv->first_busno))
>> +return -EINVAL;
>
> Maybe better error code is -ENODEV? As technically access request is
> valid but there is no device on it.
>
ok
>> +
>> +*paddr = (void *)(priv->cfg_base + where);
>> +return 0;
>> +}
>> +
> ...
>> +static int starfive_pcie_init_port(struct udevice *dev)
>> +{
>> +int ret, i;
>> +unsigned int value;
>> +struct starfive_pcie *priv = dev_get_priv(dev);
>> +
>> +ret = clk_enable_bulk(&priv->clks);
>> +if (ret) {
>> +dev_err
Re: [PATCH 33/38] fs: fat: Support reading from a larger block size
On 3/31/23 00:55, Heinrich Schuchardt wrote:
Am 30. März 2023 23:32:22 MESZ schrieb Simon Glass :
At present it is not possible to read from some CDROM drives since the
FAT sector size does not match the media's block size. Add a conversion
option for this, so that reading is possible.
This does increase SPL size for read-only FAT support by 25 bytes but
all but 6 are covered by the previous patch. We could reduce the
overhead of this feature to 0 bytes by making the code uglier (using
a static variable).
512 and 2048 are not the only physical sector sizes. Some hard drives use 4096.
To complete the logic you have first to take into account the size of a
FAT sector (BPB_BytsPerSec) defined in the FAT boot sector which can
take values 512, 1024, 2048, or 4096.
Cf. https://academy.cba.mit.edu/classes/networking_communications/SD/FAT.pdf
Best regards
Heinrich
This change deserves a test case.
Best regards
Heinrich
Signed-off-by: Simon Glass
---
fs/fat/Kconfig | 13 ++
fs/fat/fat.c | 107 -
fs/fat/fat_write.c | 8 ++--
3 files changed, 114 insertions(+), 14 deletions(-)
diff --git a/fs/fat/Kconfig b/fs/fat/Kconfig
index 9bb11eac9f7a..b0aa888c6cc4 100644
--- a/fs/fat/Kconfig
+++ b/fs/fat/Kconfig
@@ -22,3 +22,16 @@ config FS_FAT_MAX_CLUSTSIZE
is the smallest amount of disk space that can be used to hold a
file. Unless you have an extremely tight memory memory constraints,
leave the default.
+
+config FAT_BLK_XLATE
+ bool "Enable FAT filesystem on a device with a larger block size"
+ depends on FS_FAT
+ help
+ This provides a simple translation mechanism for reading FAT
+ filesystems which don't use the same sector size as the underlying
+ media. For example, the FAT filesystem may use 512 bytes but the
+ media uses 2048, e.g. on a CDROM drive.
+
+ This only supports the case where the FAT filesystem's sector size is
+ smaller than the media's block size. It does not support creating or
+ writing files.
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index f0df7988e172..02c6d55a99b3 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -43,13 +43,93 @@ static struct disk_partition cur_part_info;
#define DOS_FS_TYPE_OFFSET 0x36
#define DOS_FS32_TYPE_OFFSET0x52
-static int disk_read(__u32 block, __u32 nr_blocks, void *buf)
+/**
+ * disk_read_conv() - Read blocks and break them into smaller ones
+ *
+ * This is used when the FAT filesystem is hosted on a block device with a
+ * block size greated than 512 bytes, e.g. the 2048 bytes of a CDROM drive. It
+ * reads the blocks into a buffer and pulls out what is requested by the
calling
+ * function.
+ *
+ * It uses an internal 2KB buffer on the stack.
+ *
+ * @mydata: Filesystem information
+ * @block: Block number to read, in terms of mydata->sect_size
+ * @nr_blocks: Number of blocks to read, in terms of mydata->sect_size
+ * @buf: Buffer for data
+ */
+static int disk_read_conv(fsdata *mydata, __u32 block, __u32 nr_blocks,
+ void *buf)
+{
+ uint factor, whole, remain, upto;
+ ulong base, index;
+ uint to_copy;
+ u8 tbuf[2048];
+ int ret;
+
+ log_debug("mydata %x, cur_dev %lx, block %x, nr_block %x\n",
+ mydata->sect_size, cur_dev->blksz, block, nr_blocks);
+ if (mydata->sect_size > cur_dev->blksz ||
+ cur_dev->blksz > sizeof(tbuf)) {
+ log_err("Block size %lx not supported\n", cur_dev->blksz);
+ return -EIO;
+ }
+ factor = cur_dev->blksz / mydata->sect_size;
+
+ /* get the first partial block */
+ base = cur_part_info.start + block / factor;
+ index = block % factor;
+ log_debug("cur_part_info.start %llx, block %x, base %lx, index %lx\n",
+ (unsigned long long)cur_part_info.start, block, base, index);
+ ret = blk_dread(cur_dev, base, 1, tbuf);
+ if (ret != 1)
+ return -EIO;
+
+ to_copy = min((ulong)nr_blocks, factor - index);
+ log_debug("to_copy %x\n", to_copy);
+ memcpy(buf, tbuf + index * mydata->sect_size,
+ to_copy * mydata->sect_size);
+ upto = to_copy;
+
+ /* load any whole blocks */
+ remain = nr_blocks - upto;
+ whole = remain / factor;
+ log_debug("factor %x, whole %x, remain %x\n", factor, whole, remain);
+ if (whole) {
+ ret = blk_dread(cur_dev, base + 1, whole,
+ buf + upto * mydata->sect_size);
+ if (ret != whole)
+ return -EIO;
+ upto += whole * factor;
+ remain = nr_blocks - upto;
+ }
+
+ /* load any blocks at the end */
+ log_debug("end: remain %x\n", remain);
+ if (remain) {
+ ret = blk_dread(cur_dev, base + 1 + whole, 1, tbuf);
+ if (ret != 1)
+
Re: [PATCH 32/38] fs: fat: Shrink the size of a few strings
On 3/31/23 09:33, Ilias Apalodimas wrote:
On Fri, 31 Mar 2023 at 09:51, Heinrich Schuchardt wrote:
Am 31. März 2023 03:16:13 MESZ schrieb Simon Glass :
Hi Heinrich,
On Fri, 31 Mar 2023 at 13:05, Heinrich Schuchardt wrote:
Am 31. März 2023 01:49:35 MESZ schrieb Simon Glass :
Hi Heinrich,
On Fri, 31 Mar 2023 at 11:48, Heinrich Schuchardt wrote:
Am 30. März 2023 23:32:21 MESZ schrieb Simon Glass :
To save a few bytes, replace Error with ** and try to use the same string
for multiple messages where possible.
Signed-off-by: Simon Glass
---
fs/fat/fat.c | 12 ++--
fs/fat/fat_write.c | 14 --
2 files changed, 10 insertions(+), 16 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 2da93dae3cf3..f0df7988e172 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -97,8 +97,8 @@ int fat_register_device(struct blk_desc *dev_desc, int
part_no)
/* Read the partition table, if present */
if (part_get_info(dev_desc, part_no, &info)) {
if (part_no != 0) {
- printf("** Partition %d not valid on device %d **\n",
- part_no, dev_desc->devnum);
+ printf("** Partition %d invalid on device %d **\n",
+ part_no, dev_desc->devnum);
return -1;
}
@@ -168,7 +168,7 @@ static __u32 get_fatent(fsdata *mydata, __u32 entry)
__u32 ret = 0x00;
if (CHECK_CLUST(entry, mydata->fatsize)) {
- printf("Error: Invalid FAT entry: 0x%08x\n", entry);
+ printf("** Invalid FAT entry: %#08x\n", entry);
The ** is superfluous. The text makes it clear that an error occured
So should I drop the other ** strings in these files too? Please take
a look and see what you think.
I suggest to avoid prefixes like 'Error:' and '**' in all our code if the
message text already indicates an error.
That makes sense to me. It is sometimes hard to know whether something
indicates an error, though. If you look through fat.c you'll see what
I mean.
Users might prefer log_err writing messages in red on the console.
FWIW I agree with Heinrich here. We got 'Error: X' sprinkled
around from older code, but it makes sense to convert them to log_err
where possible
We should move all error output to log_err() and then can later add
decoration (color or prefix) in log_err().
Best regards
Heinrich
Regards
/Ilias
Regards,
Simon
Re: [PATCH 14/38] qfw: Show the file address if available
> Date: Fri, 31 Mar 2023 00:31:17 +0200
> From: Heinrich Schuchardt
>
> Am 30. März 2023 23:32:03 MESZ schrieb Simon Glass :
> >Some files have an associated address. Show this with the 'qfw list'
> >command so that it is possible to dump the data.
> >
> >Signed-off-by: Simon Glass
> >---
> >
> > cmd/qfw.c | 2 +-
> > doc/usage/cmd/qfw.rst | 28
> > 2 files changed, 17 insertions(+), 13 deletions(-)
> >
> >diff --git a/cmd/qfw.c b/cmd/qfw.c
> >index ae3c6a7a84e9..d6ecfa60d5a7 100644
> >--- a/cmd/qfw.c
> >+++ b/cmd/qfw.c
> >@@ -26,7 +26,7 @@ static int qemu_fwcfg_cmd_list_firmware(void)
> > for (file = qfw_file_iter_init(qfw_dev, &iter);
> > !qfw_file_iter_end(&iter);
> > file = qfw_file_iter_next(&iter)) {
> >-printf("%-56s\n", file->cfg.name);
> >+printf("%08lx %-56s\n", file->addr, file->cfg.name);
>
> Are the tables always in the lower 4GiB on all architectures
> (riscv64, arm64, x86)?
Some arm64 doesn't even have memory in the lower 4GiB of memory. Not
sure if qemu emulates such hardware though.
> > }
> >
> > return 0;
> >diff --git a/doc/usage/cmd/qfw.rst b/doc/usage/cmd/qfw.rst
> >index cc0e27c27790..76d74278a213 100644
> >--- a/doc/usage/cmd/qfw.rst
> >+++ b/doc/usage/cmd/qfw.rst
> >@@ -11,6 +11,7 @@ Synopsis
> > qfw list
> > qfw cpus
> > qfw load [kernel_addr [initrd_addr]]
> >+qfw list
> >
> > Description
> > ---
> >@@ -41,18 +42,21 @@ QEMU firmware files are listed via the *qfw list*
> >command:
> > ::
> >
> > => qfw list
> >-etc/boot-fail-wait
> >-etc/smbios/smbios-tables
> >-etc/smbios/smbios-anchor
> >-etc/e820
> >-genroms/kvmvapic.bin
> >-genroms/linuxboot.bin
> >-etc/system-states
> >-etc/acpi/tables
> >-etc/table-loader
> >-etc/tpm/log
> >-etc/acpi/rsdp
> >-bootorder
> >+ bios-geometry
> >+ bootorder
> >+000f0060 etc/acpi/rsdp
> >+bed14040 etc/acpi/tables
> >+ etc/boot-fail-wait
> >+ etc/e820
> >+ etc/smbios/smbios-anchor
> >+ etc/smbios/smbios-tables
> >+ etc/system-states
> >+ etc/table-loader
> >+ etc/tpm/log
> >+ genroms/kvmvapic.bin
> >+
> >+Where an address is shown, it indicates where the data is available for
> >+inspection, e.g. using the :doc:`md`.
> >
> > The available CPUs can be shown via the *qfw cpus* command:
> >
>
[PATCH v3 3/3] configs: rockchip: rock5b-rk3588: enable USB and regulators
Enable USB command, USB drivers, PHY and regulators, for USB host operations. Signed-off-by: Eugen Hristev --- configs/rock5b-rk3588_defconfig | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/configs/rock5b-rk3588_defconfig b/configs/rock5b-rk3588_defconfig index f3026c7ea166..c4b3bd65147f 100644 --- a/configs/rock5b-rk3588_defconfig +++ b/configs/rock5b-rk3588_defconfig @@ -41,12 +41,13 @@ CONFIG_SPL_STACK_R=y CONFIG_SPL_ATF=y CONFIG_CMD_GPT=y CONFIG_CMD_MMC=y +CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set +CONFIG_CMD_REGULATOR=y # CONFIG_SPL_DOS_PARTITION is not set CONFIG_SPL_OF_CONTROL=y CONFIG_OF_LIVE=y CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" -CONFIG_NET_RANDOM_ETHADDR=y CONFIG_SPL_REGMAP=y CONFIG_SPL_SYSCON=y CONFIG_SPL_CLK=y @@ -61,7 +62,9 @@ CONFIG_MMC_SDHCI_SDMA=y CONFIG_MMC_SDHCI_ROCKCHIP=y CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y +CONFIG_PHY_ROCKCHIP_INNO_USB2=y CONFIG_REGULATOR_PWM=y +CONFIG_DM_REGULATOR_FIXED=y CONFIG_PWM_ROCKCHIP=y CONFIG_SPL_RAM=y CONFIG_BAUDRATE=150 @@ -69,4 +72,17 @@ CONFIG_DEBUG_UART_SHIFT=2 CONFIG_DEBUG_UART_ANNOUNCE=y CONFIG_SYSRESET=y # CONFIG_BINMAN_FDT is not set +CONFIG_USB=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_EHCI_GENERIC=y +CONFIG_USB_OHCI_HCD=y +CONFIG_USB_OHCI_GENERIC=y +CONFIG_USB_HOST_ETHER=y +CONFIG_USB_ETHER_ASIX=y +CONFIG_USB_ETHER_ASIX88179=y +CONFIG_USB_ETHER_LAN75XX=y +CONFIG_USB_ETHER_LAN78XX=y +CONFIG_USB_ETHER_MCS7830=y +CONFIG_USB_ETHER_RTL8152=y +CONFIG_USB_ETHER_SMSC95XX=y CONFIG_ERRNO_STR=y -- 2.34.1
[PATCH v3 2/3] phy: rockchip-inno-usb2: add initial support for rk3588 PHY
Add initial support for the rk3588 PHY variant.
The driver now looks for phy-supply and enables/disables the vbus
accordingly.
The lookup for the host-port reg inside the struct now does a do {} while()
instead of a while() {} in order to allow a first check for reg == 0.
Co-developed-by: Frank Wang
Signed-off-by: Frank Wang
Signed-off-by: Eugen Hristev
Tested-by: Vasily Khoruzhick # rk3568-based board
Tested-by: Xavier Drudis Ferran # rk3399 rock pi 4B+
---
Changes in v3:
- add handling of -EBUSY and -EALREADY for regulator return
Changes in v2:
- add handling of -EACCES
drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 109 +-
1 file changed, 104 insertions(+), 5 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
index 55e1dbcfef7e..75c50670524e 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -61,6 +62,7 @@ struct rockchip_usb2phy_cfg {
struct rockchip_usb2phy {
void *reg_base;
struct clk phyclk;
+ struct udevice *vbus_supply[USB2PHY_NUM_PORTS];
const struct rockchip_usb2phy_cfg *phy_cfg;
};
@@ -86,11 +88,34 @@ struct rockchip_usb2phy_port_cfg *us2phy_get_port(struct
phy *phy)
return &phy_cfg->port_cfgs[phy->id];
}
+static struct udevice *rockchip_usb2phy_check_vbus(struct phy *phy)
+{
+ struct udevice *parent = phy->dev->parent;
+ struct rockchip_usb2phy *priv = dev_get_priv(parent);
+ struct udevice *vbus = NULL;
+
+ if (phy->id == USB2PHY_PORT_HOST)
+ vbus = priv->vbus_supply[USB2PHY_PORT_HOST];
+
+ return vbus;
+}
+
static int rockchip_usb2phy_power_on(struct phy *phy)
{
struct udevice *parent = dev_get_parent(phy->dev);
struct rockchip_usb2phy *priv = dev_get_priv(parent);
const struct rockchip_usb2phy_port_cfg *port_cfg = us2phy_get_port(phy);
+ struct udevice *vbus = NULL;
+ int ret;
+
+ vbus = rockchip_usb2phy_check_vbus(phy);
+ if (vbus) {
+ ret = regulator_set_enable(vbus, true);
+ if (ret && ret != -EALREADY) {
+ dev_err(phy->dev, "vbus enable failed: %d\n", ret);
+ return ret;
+ }
+ }
property_enable(priv->reg_base, &port_cfg->phy_sus, false);
@@ -105,6 +130,17 @@ static int rockchip_usb2phy_power_off(struct phy *phy)
struct udevice *parent = dev_get_parent(phy->dev);
struct rockchip_usb2phy *priv = dev_get_priv(parent);
const struct rockchip_usb2phy_port_cfg *port_cfg = us2phy_get_port(phy);
+ struct udevice *vbus = NULL;
+ int ret;
+
+ vbus = rockchip_usb2phy_check_vbus(phy);
+ if (vbus) {
+ ret = regulator_set_enable(vbus, false);
+ if (ret && ret != -EACCES && ret != -EBUSY) {
+ dev_info(phy->dev, "vbus disable failed: %d\n", ret);
+ return ret;
+ }
+ }
property_enable(priv->reg_base, &port_cfg->phy_sus, true);
@@ -149,13 +185,20 @@ static int rockchip_usb2phy_of_xlate(struct phy *phy,
struct ofnode_phandle_args *args)
{
const char *name = phy->dev->name;
+ struct udevice *parent = phy->dev->parent;
+ struct rockchip_usb2phy *priv = dev_get_priv(parent);
- if (!strcasecmp(name, "host-port"))
+ if (!strcasecmp(name, "host-port")) {
phy->id = USB2PHY_PORT_HOST;
- else if (!strcasecmp(name, "otg-port"))
+ device_get_supply_regulator(phy->dev, "phy-supply",
+
&priv->vbus_supply[USB2PHY_PORT_HOST]);
+ } else if (!strcasecmp(name, "otg-port")) {
phy->id = USB2PHY_PORT_OTG;
- else
+ device_get_supply_regulator(phy->dev, "phy-supply",
+
&priv->vbus_supply[USB2PHY_PORT_OTG]);
+ } else {
dev_err(phy->dev, "improper %s device\n", name);
+ }
return 0;
}
@@ -201,14 +244,14 @@ static int rockchip_usb2phy_probe(struct udevice *dev)
/* find out a proper config which can be matched with dt. */
index = 0;
- while (phy_cfgs[index].reg) {
+ do {
if (phy_cfgs[index].reg == reg) {
priv->phy_cfg = &phy_cfgs[index];
break;
}
++index;
- }
+ } while (phy_cfgs[index].reg);
if (!priv->phy_cfg) {
dev_err(dev, "failed find proper phy-cfg\n");
@@ -348,6 +391,58 @@ static const struct rockchip_usb2phy_cfg rk3568_phy_cfgs[]
= {
{ /* sentinel */ }
};
+static const struct rockchip_usb2phy_cfg rk3588_phy_cfgs[] = {
+ {
+
[PATCH v3 1/3] ARM: dts: rockchip: rk3588-rock-5b-u-boot: add USB 2.0 host
Add USB 2.0 host nodes and PHYs.
Co-developed-by: William Wu
Signed-off-by: William Wu
Signed-off-by: Eugen Hristev
---
Changes in v2,v3:
- none
arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 169
1 file changed, 169 insertions(+)
diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
index 2386edf90deb..e1d240baf35d 100644
--- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
@@ -4,6 +4,9 @@
*/
#include "rk3588-u-boot.dtsi"
+#include
+#include
+#include
/ {
aliases {
@@ -13,6 +16,105 @@
chosen {
u-boot,spl-boot-order = &sdmmc;
};
+
+ vcc5v0_host: vcc5v0-host-regulator {
+ u-boot,dm-pre-reloc;
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_host";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ enable-active-high;
+ gpio = <&gpio4 RK_PB0 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc5v0_host_en>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ usb_host0_ehci: usb@fc80 {
+ compatible = "generic-ehci";
+ reg = <0x0 0xfc80 0x0 0x4>;
+ interrupts = ;
+ clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST_ARB0>;
+ clock-names = "usbhost", "arbiter";
+ power-domains = <&power RK3588_PD_USB>;
+ status = "disabled";
+ };
+
+ usb_host0_ohci: usb@fc84 {
+ compatible = "generic-ohci";
+ reg = <0x0 0xfc84 0x0 0x4>;
+ interrupts = ;
+ clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST_ARB0>;
+ clock-names = "usbhost", "arbiter";
+ power-domains = <&power RK3588_PD_USB>;
+ status = "disabled";
+ };
+
+ usb_host1_ehci: usb@fc88 {
+ compatible = "generic-ehci";
+ reg = <0x0 0xfc88 0x0 0x4>;
+ interrupts = ;
+ clocks = <&cru HCLK_HOST1>, <&cru HCLK_HOST_ARB1>;
+ clock-names = "usbhost", "arbiter";
+ power-domains = <&power RK3588_PD_USB>;
+ status = "disabled";
+ };
+
+ usb_host1_ohci: usb@fc8c {
+ compatible = "generic-ohci";
+ reg = <0x0 0xfc8c 0x0 0x4>;
+ interrupts = ;
+ clocks = <&cru HCLK_HOST1>, <&cru HCLK_HOST_ARB1>;
+ clock-names = "usbhost", "arbiter";
+ power-domains = <&power RK3588_PD_USB>;
+ status = "disabled";
+ };
+
+ usb2phy2_grf: syscon@fd5d8000 {
+ compatible = "rockchip,rk3588-usb2phy-grf", "syscon",
+"simple-mfd";
+ reg = <0x0 0xfd5d8000 0x0 0x4000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ u2phy2: usb2-phy@8000 {
+ compatible = "rockchip,rk3588-usb2phy";
+ reg = <0x8000 0x10>;
+ interrupts = ;
+ clocks = <&cru CLK_USB2PHY_HDPTXRXPHY_REF>;
+ clock-names = "phyclk";
+ #clock-cells = <0>;
+ status = "disabled";
+
+ u2phy2_host: host-port {
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+ };
+ };
+
+ usb2phy3_grf: syscon@fd5dc000 {
+ compatible = "rockchip,rk3588-usb2phy-grf", "syscon",
+"simple-mfd";
+ reg = <0x0 0xfd5dc000 0x0 0x4000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ u2phy3: usb2-phy@c000 {
+ compatible = "rockchip,rk3588-usb2phy";
+ reg = <0xc000 0x10>;
+ interrupts = ;
+ clocks = <&cru CLK_USB2PHY_HDPTXRXPHY_REF>;
+ clock-names = "phyclk";
+ #clock-cells = <0>;
+ status = "disabled";
+
+ u2phy3_host: host-port {
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+ };
+ };
};
&sdmmc {
@@ -20,3 +122,70 @@
u-boot,dm-spl;
status = "okay";
};
+
+&pinctrl {
+ usb {
+ vcc5v0_host_en: vcc5v0-host-en {
+ rockchip,pins = <4 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&usb_host0_ehci {
+ companion = <&usb_host0_ohci>;
+ phys = <&u2phy2_host>;
+ phy-names = "usb2-phy";
+ status = "okay";
+};
+
+&usb_hos
[PATCH v4 2/2] regulator: rename dev_pdata to plat
Simplify the subsystem by renaming `dev_pdata` to just `plat`.
No functional change, just trivial renaming.
Suggested-by: Simon Glass
Signed-off-by: Eugen Hristev
Reviewed-by: Simon Glass
---
Changes in v3,v4:
- none
Changes in v2:
- this is a new patch
drivers/power/regulator/fan53555.c | 10 ++--
drivers/power/regulator/fixed.c| 16 +++
drivers/power/regulator/gpio-regulator.c | 46 +--
drivers/power/regulator/regulator_common.c | 53 +++---
drivers/power/regulator/regulator_common.h | 8 ++--
5 files changed, 66 insertions(+), 67 deletions(-)
diff --git a/drivers/power/regulator/fan53555.c
b/drivers/power/regulator/fan53555.c
index 5681206bbafe..815f96beef61 100644
--- a/drivers/power/regulator/fan53555.c
+++ b/drivers/power/regulator/fan53555.c
@@ -101,7 +101,7 @@ struct fan53555_priv {
static int fan53555_regulator_of_to_plat(struct udevice *dev)
{
- struct fan53555_plat *dev_pdata = dev_get_plat(dev);
+ struct fan53555_plat *plat = dev_get_plat(dev);
struct dm_regulator_uclass_plat *uc_pdata =
dev_get_uclass_plat(dev);
u32 sleep_vsel;
@@ -118,12 +118,12 @@ static int fan53555_regulator_of_to_plat(struct udevice
*dev)
*/
switch (sleep_vsel) {
case FAN53555_VSEL0:
- dev_pdata->sleep_reg = FAN53555_VSEL0;
- dev_pdata->vol_reg = FAN53555_VSEL1;
+ plat->sleep_reg = FAN53555_VSEL0;
+ plat->vol_reg = FAN53555_VSEL1;
break;
case FAN53555_VSEL1:
- dev_pdata->sleep_reg = FAN53555_VSEL1;
- dev_pdata->vol_reg = FAN53555_VSEL0;
+ plat->sleep_reg = FAN53555_VSEL1;
+ plat->vol_reg = FAN53555_VSEL0;
break;
default:
pr_err("%s: invalid vsel id %d\n", dev->name, sleep_vsel);
diff --git a/drivers/power/regulator/fixed.c b/drivers/power/regulator/fixed.c
index 90004d1601a9..ad3b4b98d667 100644
--- a/drivers/power/regulator/fixed.c
+++ b/drivers/power/regulator/fixed.c
@@ -24,16 +24,16 @@ struct fixed_clock_regulator_plat {
static int fixed_regulator_of_to_plat(struct udevice *dev)
{
struct dm_regulator_uclass_plat *uc_pdata;
- struct regulator_common_plat *dev_pdata;
+ struct regulator_common_plat *plat;
- dev_pdata = dev_get_plat(dev);
+ plat = dev_get_plat(dev);
uc_pdata = dev_get_uclass_plat(dev);
if (!uc_pdata)
return -ENXIO;
uc_pdata->type = REGULATOR_TYPE_FIXED;
- return regulator_common_of_to_plat(dev, dev_pdata, "gpio");
+ return regulator_common_of_to_plat(dev, plat, "gpio");
}
static int fixed_regulator_get_value(struct udevice *dev)
@@ -88,7 +88,7 @@ static int fixed_clock_regulator_get_enable(struct udevice
*dev)
static int fixed_clock_regulator_set_enable(struct udevice *dev, bool enable)
{
struct fixed_clock_regulator_plat *priv = dev_get_priv(dev);
- struct regulator_common_plat *dev_pdata = dev_get_plat(dev);
+ struct regulator_common_plat *plat = dev_get_plat(dev);
int ret = 0;
if (enable) {
@@ -101,11 +101,11 @@ static int fixed_clock_regulator_set_enable(struct
udevice *dev, bool enable)
if (ret)
return ret;
- if (enable && dev_pdata->startup_delay_us)
- udelay(dev_pdata->startup_delay_us);
+ if (enable && plat->startup_delay_us)
+ udelay(plat->startup_delay_us);
- if (!enable && dev_pdata->off_on_delay_us)
- udelay(dev_pdata->off_on_delay_us);
+ if (!enable && plat->off_on_delay_us)
+ udelay(plat->off_on_delay_us);
return ret;
}
diff --git a/drivers/power/regulator/gpio-regulator.c
b/drivers/power/regulator/gpio-regulator.c
index 9c0a68aa5af4..ded7be059bb0 100644
--- a/drivers/power/regulator/gpio-regulator.c
+++ b/drivers/power/regulator/gpio-regulator.c
@@ -27,12 +27,12 @@ struct gpio_regulator_plat {
static int gpio_regulator_of_to_plat(struct udevice *dev)
{
struct dm_regulator_uclass_plat *uc_pdata;
- struct gpio_regulator_plat *dev_pdata;
+ struct gpio_regulator_plat *plat;
struct gpio_desc *gpio;
int ret, count, i, j;
u32 states_array[GPIO_REGULATOR_MAX_STATES * 2];
- dev_pdata = dev_get_plat(dev);
+ plat = dev_get_plat(dev);
uc_pdata = dev_get_uclass_plat(dev);
if (!uc_pdata)
return -ENXIO;
@@ -47,7 +47,7 @@ static int gpio_regulator_of_to_plat(struct udevice *dev)
* per gpio-regulator. As of now no instance with multiple
* gpios is presnt
*/
- gpio = &dev_pdata->gpio;
+ gpio = &plat->gpio;
ret = gpio_request_by_name(dev, "gpios", 0, gpio, GPIOD_IS_OUT);
if (ret)
debug("regulator gpio - not found! Error: %d", ret);
@@ -68,21 +68,21 @@ static int gpio_regulator_of_to
[PATCH v4 1/2] regulator: implement basic reference counter
Some devices share a regulator supply, when the first one will request
regulator disable, the second device will have it's supply cut off before
graciously shutting down. Hence there will be timeouts and other failed
operations.
Implement a reference counter mechanism similar with what is done in
Linux, to keep track of enable and disable requests, and only disable the
regulator when the last of the consumers has requested shutdown.
Signed-off-by: Eugen Hristev
Reviewed-by: Simon Glass
---
Changes in v4:
- add documentation for error codes
Changes in v3:
- add error return codes
Changes in v2:
- add info in header regarding the function
drivers/power/regulator/regulator_common.c | 22 ++
drivers/power/regulator/regulator_common.h | 21 +
2 files changed, 43 insertions(+)
diff --git a/drivers/power/regulator/regulator_common.c
b/drivers/power/regulator/regulator_common.c
index 93d8196b381e..484a4fc31ef7 100644
--- a/drivers/power/regulator/regulator_common.c
+++ b/drivers/power/regulator/regulator_common.c
@@ -73,6 +73,23 @@ int regulator_common_set_enable(const struct udevice *dev,
return 0;
}
+ /* If previously enabled, increase count */
+ if (enable && dev_pdata->enable_count > 0) {
+ dev_pdata->enable_count++;
+ return -EALREADY;
+ }
+
+ if (!enable) {
+ if (dev_pdata->enable_count > 1) {
+ /* If enabled multiple times, decrease count */
+ dev_pdata->enable_count--;
+ return -EBUSY;
+ } else if (!dev_pdata->enable_count) {
+ /* If already disabled, do nothing */
+ return -EALREADY;
+ }
+ }
+
ret = dm_gpio_set_value(&dev_pdata->gpio, enable);
if (ret) {
pr_err("Can't set regulator : %s gpio to: %d\n", dev->name,
@@ -87,5 +104,10 @@ int regulator_common_set_enable(const struct udevice *dev,
if (!enable && dev_pdata->off_on_delay_us)
udelay(dev_pdata->off_on_delay_us);
+ if (enable)
+ dev_pdata->enable_count++;
+ else
+ dev_pdata->enable_count--;
+
return 0;
}
diff --git a/drivers/power/regulator/regulator_common.h
b/drivers/power/regulator/regulator_common.h
index c10492f01675..0faab447d099 100644
--- a/drivers/power/regulator/regulator_common.h
+++ b/drivers/power/regulator/regulator_common.h
@@ -13,6 +13,7 @@ struct regulator_common_plat {
struct gpio_desc gpio; /* GPIO for regulator enable control */
unsigned int startup_delay_us;
unsigned int off_on_delay_us;
+ unsigned int enable_count;
};
int regulator_common_of_to_plat(struct udevice *dev,
@@ -20,6 +21,26 @@ int regulator_common_of_to_plat(struct udevice *dev,
char *enable_gpio_name);
int regulator_common_get_enable(const struct udevice *dev,
struct regulator_common_plat *dev_pdata);
+/*
+ * Enable or Disable a regulator
+ *
+ * This is a reentrant function and subsequent calls that enable will
+ * increase an internal counter, and disable calls will decrease the counter.
+ * The actual resource will be enabled when the counter gets to 1 coming from
0,
+ * and disabled when it reaches 0 coming from 1.
+ *
+ * @dev: regulator device
+ * @dev_pdata: Platform data
+ * @enable: bool indicating whether to enable or disable the regulator
+ * @return:
+ * 0 on Success
+ * -EBUSY if the regulator cannot be disabled because it's requested by
+ *another device
+ * -EALREADY if the regulator has already been enabled or has already been
+ *disabled
+ * -EACCES if there is no possibility to enable/disable the regulator
+ * -ve on different error situation
+ */
int regulator_common_set_enable(const struct udevice *dev,
struct regulator_common_plat *dev_pdata, bool enable);
--
2.34.1
[PATCH 3/3] configs: Create minimal vexpress_fvp_defconfig
From: Peter Hoyes The vexpress64 board family now relies on OF_CONTROL and OF_HAS_PRIOR_STAGE, so platform-specific configuration requirements are minimal. The vexpress_aemv8a_semi_defconfig file defines many flags that are not needed for a minimal boot, such as flash memory configuration. Therefore create vexpress_fvp_defconfig which contains the minimum configuration required to boot on an Arm v8a FVP. Signed-off-by: Peter Hoyes --- configs/vexpress_fvp_defconfig | 5 + 1 file changed, 5 insertions(+) create mode 100644 configs/vexpress_fvp_defconfig diff --git a/configs/vexpress_fvp_defconfig b/configs/vexpress_fvp_defconfig new file mode 100644 index 00..7362c1fc35 --- /dev/null +++ b/configs/vexpress_fvp_defconfig @@ -0,0 +1,5 @@ +CONFIG_ARM=y +CONFIG_ARCH_VEXPRESS64=y +CONFIG_DEFAULT_DEVICE_TREE="arm_fvp" +CONFIG_IDENT_STRING=" arm_fvp" +# CONFIG_DISPLAY_CPUINFO is not set -- 2.34.1
[PATCH 2/3] vexpress64: Enable VIRTIO_MMIO and RTC_PL031 in the base model
From: Peter Hoyes The Arm EBBR (Embedded Base Boot Requirements) require that the time and basic networking EFI interfaces are available and working, so long as the hardware has an RTC and network interface. Arm FVPs typically have a memory-mapped PL031 RTC and a VIRTIO_NET device defined in the device tree, so "imply" these in the Kconfig for the FVP base model to simplify creating EBBR-compliant firmware. Signed-off-by: Peter Hoyes --- board/armltd/vexpress64/Kconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/board/armltd/vexpress64/Kconfig b/board/armltd/vexpress64/Kconfig index bd15cbeb7e..cf998096e4 100644 --- a/board/armltd/vexpress64/Kconfig +++ b/board/armltd/vexpress64/Kconfig @@ -12,8 +12,13 @@ config SYS_CONFIG_NAME config VEXPRESS64_BASE_MODEL bool select SEMIHOSTING + imply VIRTIO_MMIO select VIRTIO_BLK if VIRTIO_MMIO select VIRTIO_NET if VIRTIO_MMIO + select DM_ETH if VIRTIO_NET + imply RTC_PL031 + select DM_RTC if RTC_PL031 + imply EFI_SET_TIME if DM_RTC select LINUX_KERNEL_IMAGE_HEADER select POSITION_INDEPENDENT -- 2.34.1
[PATCH 1/3] vexpress64: Use OF_HAS_PRIOR_STAGE for BASE_FVP variant
From: Peter Hoyes BASE_FVP now typically uses a devicetree provided by a prior boot stage (typically Arm TF-A), so imply this option by default when TARGET_VEXPRESS64_BASE_FVP is selected. OF_HAS_PRIOR_STAGE selects OF_BOARD so this change is minor, but aligns TARGET_VEXPRESS64_BASE_FVP with TARGET_VEXPRESS64_BASER_FVP. Signed-off-by: Peter Hoyes --- board/armltd/vexpress64/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/armltd/vexpress64/Kconfig b/board/armltd/vexpress64/Kconfig index 5616e223a9..bd15cbeb7e 100644 --- a/board/armltd/vexpress64/Kconfig +++ b/board/armltd/vexpress64/Kconfig @@ -23,7 +23,7 @@ choice config TARGET_VEXPRESS64_BASE_FVP bool "Support Versatile Express ARMv8a FVP BASE model" select VEXPRESS64_BASE_MODEL - select OF_BOARD + imply OF_HAS_PRIOR_STAGE config TARGET_VEXPRESS64_BASER_FVP bool "Support Versatile Express ARMv8r64 FVP BASE model" -- 2.34.1
[RESEND PATCH v2] configs: imx8mn_bsh_smm_s2: remove console from bootargs
> The Linux kernel device tree already specifies the device to be used for
> boot console output with a stdout-path property under /chosen.
> Commit 36b661dc919da ("Merge branch 'next'") re-added the console
> setting that commit bede82f750752 ("configs: imx8mn_bsh_smm_s2: remove
> console from bootargs") had previously removed.
> Fixes: 36b661dc919da ("Merge branch 'next'")
> Signed-off-by: Dario Binacchi
> Reviewed-by: Fabio Estevam
Applied to u-boot-imx, master, thanks !
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH,Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
