Re: [PATCH v2] net: tftp: Avoid sending extra ack on completion
On Wed, Feb 17, 2021 at 12:29 PM Oliver Graute wrote:
>
> On 03/02/21, Ramon Fried wrote:
> > in tftpboot, if ack was already sent previously for this
> > packet, don't send again.
> >
> > Fixes: cc6b87ecaa96 ("net: tftp: Add client support for RFC 7440")
> >
> > Reported-by: Suneel Garapati
> > Signed-off-by: Ramon Fried
>
> Tested-by: Oliver Graute
Tom, can you please merge this ?
This is an important bug fix that should be merged asap.
Thanks,
Ramon.
Re: [PATCH 1/2] scripts/check-config.sh: fix to be compatible with BSD sed
On Sat, 13 Feb 2021 at 03:06, Roger Pau Monne wrote: > > Fist use extended regexp in order to drop the '\' around the > parentheses which is not supported by BSD sed in regular mode. > > Secondly use [[:blank:]] instead of \s, as the later is a GNU > extension. > > No functional change intended. > > Signed-off-by: Roger Pau Monné > --- > Cc: Masahiro Yamada > Cc: Simon Glass > Cc: Michal Simek > Cc: Wolfgang Wallner > Cc: Jan Kiszka > --- > scripts/check-config.sh | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH v6 5/5] test: add a simple test for the adc-keys button driver
On Thu, 11 Feb 2021 at 01:48, Marek Szyprowski wrote: > > Add adc-keys device to the sandbox/test.dts and connect it to the channel > #3 of the sandbox_adc driver. The default values sampled by sandbox_adc > driver determines that button3 and button4 are released and button5 is > pressed. > > Signed-off-by: Marek Szyprowski > --- > arch/sandbox/dts/test.dts | 24 ++- > configs/sandbox_defconfig | 1 + > test/dm/button.c | 50 +-- > 3 files changed, 72 insertions(+), 3 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH v2 2/4] test: Allow simple glob pattern in the test name
On Thu, 11 Feb 2021 at 07:40, Andy Shevchenko wrote: > > When run `ut dm [test name]` allow to use simple pattern to run all tests > started with given prefix. For example, to run all ACPI test cases: > ut dm acpi* > > Signed-off-by: Andy Shevchenko > --- > v2: rebased against dm/test-working branch (Simon) Sadly that is deferred, but we can pick this patch up later. > test/test-main.c | 11 +-- > 1 file changed, 9 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH] test: cmd: setexpr: Fix a typo
On Wed, 17 Feb 2021 at 02:04, Bin Meng wrote: > > SETEXPR_TEST is for a new setexpr test, not mem. > > Signed-off-by: Bin Meng > --- > > test/cmd/setexpr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass Thanks...I have a local patch not yet sent.
Re: Chromium OS verified boot 2018 with U-Boot
Hi Heinrich, On Tue, 16 Feb 2021 at 10:52, Heinrich Schuchardt wrote: > > On 16.02.21 18:12, Simon Glass wrote: > > Hi, > > > > Just a note that the U-Boot / vboot integration has been updated with > > the 2018 version of vboot and it makes full use of driver model. > > > > If it available at [1] > > > > Documentation for running it on coral (2018 Intel Apollo Lake > > Chromebook) is available [2] as well as running it on sandbox [3]. > > > > The earlier release for 2015's samus (Chromebook Pixel 2) and 2012's > > link is still available at [4]. > > > > Regards, > > Simon > > > > [1] https://github.com/sjg20/u-boot/tree/cros-2021.01 > > [2] > > https://github.com/sjg20/u-boot/blob/cros-2021.01/cros/doc/cros_coral.rst > > [3] > > https://github.com/sjg20/u-boot/blob/cros-2021.01/cros/doc/cros_sandbox.rst > > [4] https://github.com/sjg20/u-boot/tree/cros-2019.01 > > Those *.rst should be in /doc/board/ ? Well not really since there is code in cros/ that is needed. > > It this something you are planning to merge into upstream U-Boot? Possibly but I need to chat with Tom about it. We did talk about having a u-boot-cros tree but I'm not quite ready yet. Regards, Simon
Re: [BUG] [BISECT] rockchip: roc-pc-rk3399: TPL misses dtb
Hi, On Mon, 15 Feb 2021 at 08:11, Tom Rini wrote: > > On Mon, Feb 15, 2021 at 03:05:20PM +0100, Markus Reichl wrote: > > > With recent U-Boot and roc-pc-mezzanine-rk3399_defconfig > > and booting from SPI flash I get: > > > > U-Boot TPL 2021.01-00884-g0a2aaab0b6 (Feb 15 2021 - 14:36:50) > > Missing DTB > > ### ERROR ### Please RESET the board ### > > > > Bisecting points to: > > > > commit 0a2aaab0b678fd1778ff2fc59d0770fc82995532 > > Author: Simon Glass > > Date: Wed Jan 13 20:29:49 2021 -0700 > > > > fdtdec: Use CONFIG_IS_ENABLED in board_fdt_blob_setup() > > This setting may be different in SPL and TPL. Update the code to check > > the correct setting. > > Signed-off-by: Simon Glass > > > > lib/fdtdec.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Reverting this commit fixes booting. > > Thanks for the report. I'm about to push a revert for this and I'll add > a Reported-by from you. I'm not sure what is going on here, but possibly we need to add TPL_SEPARATE_BSS to the board config.. Regards, Simon
Re: [PATCH] bootm: do not hang on failure
On Wed, 17 Feb 2021 at 04:56, Heinrich Schuchardt wrote: > > On ARMv8 systems > > load mmc 0:1 $loadaddr vmlinuz-5.10.0-3-arm64 > booti > > leads to a hanging system requiring to physically reset the system: > > FDT and ATAGS support not compiled in - hanging > ### ERROR ### Please RESET the board ### > > For systems where physical access is difficult hanging is a poor choice. > It is preferable to reset the system when U-Boot reaches a state that is > not recoverable. > > Signed-off-by: Heinrich Schuchardt > --- > arch/arm/lib/bootm.c | 7 ++- > 1 file changed, 2 insertions(+), 5 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH] patman: Use less for help file, if available
On Wed, 17 Feb 2021 at 03:41, Nicolas Boichat wrote: > > It's convenient to be able to scroll up in `patman -H`. > > Signed-off-by: Nicolas Boichat > --- > > tools/patman/main.py | 3 +++ > 1 file changed, 3 insertions(+) Reviewed-by: Simon Glass
Re: [PATCH] test: print_ut: Fix potential build error
kOn Wed, 17 Feb 2021 at 02:31, Bin Meng wrote: > > This files uses the macro U_BOOT_CMD which is defined in command.h, > but command.h is conditionally included. Fix it. > > Signed-off-by: Bin Meng > --- > > test/print_ut.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass
Re: [PATCH] fdt/sunxi: Remove OF_STDOUT_PATH
On Sun, 14 Feb 2021 at 05:35, Andre Przywara wrote: > > OF_STDOUT_PATH was meant to hold the devicetree path to the serial > console, to be put into the linux,stdout-path property of the chosen node. > > The only user of that was sunxi, and it was actually wrong for years > there: the paths hardcoded in sunxi_common.h were not matching the DTs, > evident by the leading 0's in nodenames, which have been removed years > ago. > > On top of that, "linux,stdout-path" is now deprecated for a while (Linux > commit 2a9d832cc9aae from November 2014), and also all modern DTs > (including those included in U-Boot) carry a "stdout-path" property > already. > > So remove the stanza from sunxi_common.h, and, since this was the last > user, also remove the associated bits from the rest of U-Boot. > > Signed-off-by: Andre Przywara > --- > README | 1 - > common/fdt_support.c | 9 + > include/configs/sunxi-common.h | 18 -- > scripts/config_whitelist.txt | 1 - > 4 files changed, 1 insertion(+), 28 deletions(-) > You should teach a class in how to write commit messages :-) Reviewed-by: Simon Glass
Re: [PATCH v2 4/4] test: Don't unmount not (yet) mounted system
Hi Andy, On Thu, 11 Feb 2021 at 07:40, Andy Shevchenko wrote: > > When test suite tries to create a file for a new filesystem test case and > fails, > the clean up of the exception tries to unmount the image, that has not yet > been > mounted. When it happens, the fuse_mounted global variable is set to False and > inconveniently the test case tries to use sudo, so without this change the > admin of the machine gets an (annoying) email: > > Subject: *** SECURITY information for example.com *** > > example.com : Feb 5 19:43:47 : ... COMMAND=/bin/umount > .../build-sandbox/persistent-data/mnt > > and second run of the test cases on uncleaned build folder will ask for sudo > which is not what expected. > > Besides that there is a double unmount calls during successfully run test > case. > > All of these due to over engineered Python try-except clause and people didn't > get it properly at all. The rule of thumb is that don't use more keywords than > try-except in the exception handling code. Nevertheless, here we adjust code > to be less intrusive to the initial logic behind that complex and unclear > constructions in the test case, although it adds a lot of lines of the code, > i.e. splits one exception handler to three, so on each step we know what > cleanup shall perform. > > Signed-off-by: Andy Shevchenko > --- > v2: new patch > test/py/tests/test_fs/conftest.py | 78 ++- > 1 file changed, 56 insertions(+), 22 deletions(-) > This looks OK to me, but there is a lot of duplication in the code, isn't there? Perhaps another forray? Regards, Simon
Re: [PATCH v6 2/5] button: add a simple Analog to Digital Converter device based button driver
On Thu, 11 Feb 2021 at 01:48, Marek Szyprowski wrote: > > Add a simple Analog to Digital Converter device based button driver. This > driver binds to the 'adc-keys' device tree node. > > Signed-off-by: Marek Szyprowski > --- > drivers/button/Kconfig | 8 ++ > drivers/button/Makefile | 1 + > drivers/button/button-adc.c | 146 > 3 files changed, 155 insertions(+) > create mode 100644 drivers/button/button-adc.c Reviewed-by: Simon Glass
Re: [PATCH v2 3/4] test: Use positive conditional in test_matches()
On Thu, 11 Feb 2021 at 07:40, Andy Shevchenko
wrote:
>
> It is easier to read the positive conditional.
>
> While at it, convert hard coded length of "_test_" to strlen("_test_")
> which will be converted to a constant bu optimizing compiler.
>
> Signed-off-by: Andy Shevchenko
> ---
> v2: new patch
> test/test-main.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
Reviewed-by: Simon Glass
Re: [PATCH v2 1/4] test: Include /sbin to the PATH when creating ext4 disk image
On Thu, 11 Feb 2021 at 07:40, Andy Shevchenko wrote: > > On some distributions the mkfs.ext4 is under /sbin and /sbin is not set > for mere users. Include /sbin to the PATH when creating ext4 disk image, > so that users won't get a scary traceback from Python. > > Cc: Patrick Delaunay > Signed-off-by: Andy Shevchenko > --- > v2: used '/sbin' as is (Simon) > test/py/tests/test_env.py | 2 ++ > 1 file changed, 2 insertions(+) Reviewed-by: Simon Glass
Re: [PATCH 02/25] arm: Remove mx23evk board
Hi Tom, On Tue, Feb 9, 2021 at 10:04 AM Tom Rini wrote: > > This board has not been converted to CONFIG_DM_MMC by the deadline of > v2019.04, which is almost two years ago. In addition there are other DM > migrations it is also missing. Remove it. I will convert this board to DM. Please don't remove it. Thanks
[PATCH 2/2] mx28evk: Convert to driver model
Make the conversion to driver model as it is mandatory.
Successfully tested booting Linux from the SD card.
Dropped support for networking and splash screen as these need
to be properly converted to DM and tested.
Signed-off-by: Fabio Estevam
---
I haven't had a chance to add DM_ETH and DM_VIDEO yet, but
these can be added later.
arch/arm/dts/Makefile | 1 +
arch/arm/dts/imx28-evk-u-boot.dtsi | 10
board/freescale/mx28evk/MAINTAINERS | 1 +
board/freescale/mx28evk/mx28evk.c | 77 -
configs/mx28evk_defconfig | 28 +--
include/configs/mx28evk.h | 7 ---
6 files changed, 26 insertions(+), 98 deletions(-)
create mode 100644 arch/arm/dts/imx28-evk-u-boot.dtsi
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 88f23e4ef41e..fefac899fb90 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -651,6 +651,7 @@ dtb-$(CONFIG_VF610) += vf500-colibri.dtb \
vf610-bk4r1.dtb
dtb-$(CONFIG_MX28) += \
+ imx28-evk.dtb \
imx28-xea.dtb
dtb-$(CONFIG_MX51) += \
diff --git a/arch/arm/dts/imx28-evk-u-boot.dtsi
b/arch/arm/dts/imx28-evk-u-boot.dtsi
new file mode 100644
index ..6adbae68d2f8
--- /dev/null
+++ b/arch/arm/dts/imx28-evk-u-boot.dtsi
@@ -0,0 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019
+ * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
+ *
+ * SPDX-License-Identifier: GPL-2.0+ or X11
+ */
+
+#include "imx28-u-boot.dtsi"
+
diff --git a/board/freescale/mx28evk/MAINTAINERS
b/board/freescale/mx28evk/MAINTAINERS
index a98a70558a72..b6974c954046 100644
--- a/board/freescale/mx28evk/MAINTAINERS
+++ b/board/freescale/mx28evk/MAINTAINERS
@@ -2,6 +2,7 @@ MX28EVK BOARD
M: Fabio Estevam
S: Maintained
F: board/freescale/mx28evk/
+F: arch/arm/dts/imx28-evk.dts
F: include/configs/mx28evk.h
F: configs/mx28evk_defconfig
F: configs/mx28evk_auart_console_defconfig
diff --git a/board/freescale/mx28evk/mx28evk.c
b/board/freescale/mx28evk/mx28evk.c
index a6b66d99ccb1..4fdd171a8a2f 100644
--- a/board/freescale/mx28evk/mx28evk.c
+++ b/board/freescale/mx28evk/mx28evk.c
@@ -71,80 +71,3 @@ int board_init(void)
return 0;
}
-
-#ifdef CONFIG_CMD_MMC
-static int mx28evk_mmc_wp(int id)
-{
- if (id != 0) {
- printf("MXS MMC: Invalid card selected (card id = %d)\n", id);
- return 1;
- }
-
- return gpio_get_value(MX28_PAD_SSP1_SCK__GPIO_2_12);
-}
-
-int board_mmc_init(struct bd_info *bis)
-{
- /* Configure WP as input */
- gpio_direction_input(MX28_PAD_SSP1_SCK__GPIO_2_12);
-
- /* Configure MMC0 Power Enable */
- gpio_direction_output(MX28_PAD_PWM3__GPIO_3_28, 0);
-
- return mxsmmc_initialize(bis, 0, mx28evk_mmc_wp, NULL);
-}
-#endif
-
-#ifdef CONFIG_CMD_NET
-
-int board_eth_init(struct bd_info *bis)
-{
- struct mxs_clkctrl_regs *clkctrl_regs =
- (struct mxs_clkctrl_regs *)MXS_CLKCTRL_BASE;
- struct eth_device *dev;
- int ret;
-
- ret = cpu_eth_init(bis);
- if (ret)
- return ret;
-
- /* MX28EVK uses ENET_CLK PAD to drive FEC clock */
- writel(CLKCTRL_ENET_TIME_SEL_RMII_CLK | CLKCTRL_ENET_CLK_OUT_EN,
- &clkctrl_regs->hw_clkctrl_enet);
-
- /* Power-on FECs */
- gpio_direction_output(MX28_PAD_SSP1_DATA3__GPIO_2_15, 0);
-
- /* Reset FEC PHYs */
- gpio_direction_output(MX28_PAD_ENET0_RX_CLK__GPIO_4_13, 0);
- udelay(200);
- gpio_set_value(MX28_PAD_ENET0_RX_CLK__GPIO_4_13, 1);
-
- ret = fecmxc_initialize_multi(bis, 0, 0, MXS_ENET0_BASE);
- if (ret) {
- puts("FEC MXS: Unable to init FEC0\n");
- return ret;
- }
-
- ret = fecmxc_initialize_multi(bis, 1, 3, MXS_ENET1_BASE);
- if (ret) {
- puts("FEC MXS: Unable to init FEC1\n");
- return ret;
- }
-
- dev = eth_get_dev_by_name("FEC0");
- if (!dev) {
- puts("FEC MXS: Unable to get FEC0 device entry\n");
- return -EINVAL;
- }
-
- dev = eth_get_dev_by_name("FEC1");
- if (!dev) {
- puts("FEC MXS: Unable to get FEC1 device entry\n");
- return -EINVAL;
- }
-
- return ret;
-}
-
-#endif
diff --git a/configs/mx28evk_defconfig b/configs/mx28evk_defconfig
index 4f0ed83bc1f0..bae603309dbe 100644
--- a/configs/mx28evk_defconfig
+++ b/configs/mx28evk_defconfig
@@ -7,27 +7,25 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y
CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x4000
CONFIG_ENV_OFFSET=0x4
+CONFIG_DM_GPIO=y
CONFIG_SPL_TEXT_BASE=0x1000
CONFIG_TARGET_MX28EVK=y
CONFIG_SPL_SERIAL_SUPPORT=y
CONFIG_SPL=y
+CONFIG_DEFAULT_DEVICE_TREE="imx28-evk"
CONFIG_FIT=y
-# CONFIG_CONSOLE_MUX is not set
CONFIG_SYS_CONSOLE_IS_IN_ENV=y
# CONFIG_DISPLAY_BOARDINFO is not set
CONFIG_ARCH_MISC_INIT=y
# CONFIG_SPL_FRAMEWORK is not set
CONF
[PATCH 1/2] imx28-evk: Import devicetree file from Linux
Import the imx28-evk devicetree files from Linux kernel
version 5.11-rc7.
This is in preparation for converting the mx28evk_defconfig
target to driver model.
Signed-off-by: Fabio Estevam
---
arch/arm/dts/imx28-evk.dts | 360 +
1 file changed, 360 insertions(+)
create mode 100644 arch/arm/dts/imx28-evk.dts
diff --git a/arch/arm/dts/imx28-evk.dts b/arch/arm/dts/imx28-evk.dts
new file mode 100644
index ..7e2b0f198dfa
--- /dev/null
+++ b/arch/arm/dts/imx28-evk.dts
@@ -0,0 +1,360 @@
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright 2012 Freescale Semiconductor, Inc.
+
+/dts-v1/;
+#include "imx28.dtsi"
+
+/ {
+ model = "Freescale i.MX28 Evaluation Kit";
+ compatible = "fsl,imx28-evk", "fsl,imx28";
+
+ memory@4000 {
+ device_type = "memory";
+ reg = <0x4000 0x0800>;
+ };
+
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+
+ reg_vddio_sd0: regulator-vddio-sd0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vddio-sd0";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&gpio3 28 0>;
+ };
+
+ reg_fec_3v3: regulator-fec-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "fec-3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&gpio2 15 0>;
+ };
+
+ reg_usb0_vbus: regulator-usb0-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb0_vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = <&gpio3 9 0>;
+ enable-active-high;
+ };
+
+ reg_usb1_vbus: regulator-usb1-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb1_vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = <&gpio3 8 0>;
+ enable-active-high;
+ };
+
+ reg_lcd_3v3: regulator-lcd-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "lcd-3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&gpio3 30 0>;
+ enable-active-high;
+ };
+
+ reg_can_3v3: regulator-can-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "can-3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&gpio2 13 0>;
+ enable-active-high;
+ };
+
+ reg_lcd_5v: regulator-lcd-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "lcd-5v";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+
+ panel {
+ compatible = "sii,43wvf1g";
+ backlight = <&backlight_display>;
+ dvdd-supply = <®_lcd_3v3>;
+ avdd-supply = <®_lcd_5v>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&display_out>;
+ };
+ };
+ };
+
+ apb@8000 {
+ apbh@8000 {
+ nand-controller@8000c000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpmi_pins_a &gpmi_status_cfg
+&gpmi_pins_evk>;
+ status = "okay";
+ };
+
+ ssp0: spi@8001 {
+ compatible = "fsl,imx28-mmc";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_8bit_pins_a
+ &mmc0_cd_cfg &mmc0_sck_cfg>;
+ bus-width = <8>;
+ wp-gpios = <&gpio2 12 0>;
+ vmmc-supply = <®_vddio_sd0>;
+ status = "okay";
+ };
+
+ ssp1: spi@80012000 {
+ compatible = "fsl,imx28-mmc";
+ bus-width = <8>;
+ wp-gpios = <&gpio0 28 0>;
+ };
+
+ ssp2: spi@80014000 {
+ #address-cells = <1>;
+
Re: [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"
Hi Tom, On Mon, Feb 15, 2021 at 4:30 AM Tom Rini wrote: > > On Sun, Feb 14, 2021 at 08:12:16PM +0100, Daniel Schwierzeck wrote: > > Am Sonntag, den 14.02.2021, 09:52 -0500 schrieb Tom Rini: > > > > ... > > > > > > > > > > > > > > > > > > > Tom, do you know the situation here? > > > > > > > > > > > > > > So, I made a lack of DM_PCI migration be fatal and got a > > > > > > > build done > > > > > > > here: > > > > > > > https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348 > > > > > > > > > > > > > > Of note, MIPS malta fails, so I had to drop that from pytest > > > > > > > to complete > > > > > > > the world build. There's then a handful of ARM boards, > > > > > > > another large > > > > > > > chunk of PowerPC, and then a few others such as r7780mp. SH > > > > > > > is the big > > > > > > > what to do here to me, other than PowerPC, as other than > > > > > > > r2dplus > > > > > > > everything is missing the main "convert to DM" migration > > > > > > > deadline as > > > > > > > well. > > > > > > > > > > > > What should we do for this patch? > > > > > > > > > > > > If the plan is to drop all boards that are not converted to DM > > > > > > PCI in > > > > > > 2021.04, I can drop this revert patch in v2. > > > > > > > > > > I've posted the patch to drop the SH boards. Daniel, what about > > > > > Malta? > > > > > > > > Malta should be fixed, since it's mips used in CI. > > > > > > There's also qemu_mips* in CI, so it depends on what Daniel thinks is > > > the right overall answer here. > > > > > > > Malta is the MIPS reference board physically as well as in Qemu. > > qemu_mips is actually deprecated and is going to be removed from Qemu > > sooner or later. That's why I added Malta to CI with the goal to remove > > qemu_mips. > > > > The problem with MIPS and DM_PCI is that there are some generic issues > > with memory mapping and CONFIG_SYS_SDRAM_BASE being used as virtual > > address. Actually I have a pending patch queue from Paul Burton for > > Malta for converting to DM_PCI, but that requires resolving the generic > > issues with some refactoring for all MIPS boards. It's still on my TODO > > list ;) > > > > Until I can spare enough time to resolve all issues, I could try to > > disable the PCI driver in Malta defconfig and mark the driver as broken > > in Kconfig. This way we can avoid removing the whole board. > > Thanks for explaining. Yes, lets go that route for now. To make this series not to depend on board removal series, I will drop this revert patch in v2, and fix the non-DM PCI driver of mpc85xx instead. Regards, Bin
Re: [PATCH v5 6/6] test/py: ecdsa: Add test for mkimage ECDSA signing
On Wed, Feb 17, 2021 at 06:02:34PM -0600, Alex G. wrote: > On 2/17/21 5:03 PM, Tom Rini wrote: > > On Thu, Jan 28, 2021 at 09:52:48AM -0600, Alexandru Gagniuc wrote: > > > > > Add a test to make sure that the ECDSA signatures generated by > > > mkimage can be verified successfully. pyCryptodomex was chosen as the > > > crypto library because it integrates much better with python code. > > > Using openssl would have been unnecessarily painful. > > > > > > Signed-off-by: Alexandru Gagniuc > > > Reviewed-by: Simon Glass > > > > So, to run this test I've done a "pip install -r > > test/py/requirements.txt" to make sure I have everything now needed > > installed. When I run this test (building in /tmp): > > +/tmp/.bm-work/sandbox/tools/mkimage -F /tmp/.bm-work/sandbox/test.fit > > -k/tmp/.bm-work/sandbox/ecdsa-test-key.pem > > Can not get key file '/tmp/.bm-work/sandbox/ecdsa-test-key.pem/dev.pem' > > Can not get key file '/tmp/.bm-work/sandbox/ecdsa-test-key.pem/dev.pem' > > Failed to sign 'signature' signature node in 'kernel' image node: -2 > > Failed to sign 'signature' signature node in 'fdt-1' image node: -2 > > FIT description: Chrome OS kernel image with one or more FDT blobs > > ... > > +fdtget -tbi /tmp/.bm-work/sandbox/test.fit /images/kernel/signature value > > Error at 'value': FDT_ERR_NOTFOUND > > > > Which I think means that since we have a key-name-hint of "dev" it's > > taking the -k argument as a keydir and that's where it goes wrong. > > Did this happen with this series alone? > I realize not that also applying "mkimage: Add a 'keyfile' argument for > image signing" would cause this. I shoudl have (but forgot to) update the > test in that series. I'll update the other series if you want to pull them > in together. No, this was with the other series applied as well. In the end, please make sure that yes, the tests all pass. If it's easier to combine both series, that's fine. Thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH V2] cmd: mmc: update the mmc command's usage about argument
On 12/16/20 7:24 AM, Jaehoon Chung wrote: > It's confusing whether arguments are optional or mandatory. > Update the command's usage to clarify how to use. > > Signed-off-by: Jaehoon Chung > Reviewed-by: Simon Glass Ping. Is there any progress about this patch? Best Regards, Jaehoon Chung > --- > Changed on V2 > - Update commit-msg > - Add Simon's Reviewed-by tag > --- > cmd/mmc.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/cmd/mmc.c b/cmd/mmc.c > index 1529a3e05ddd..cb6b59f36a43 100644 > --- a/cmd/mmc.c > +++ b/cmd/mmc.c > @@ -1017,13 +1017,13 @@ U_BOOT_CMD( > " Power cycling is required to initialize partitions after set to > complete.\n" > #endif > #ifdef CONFIG_SUPPORT_EMMC_BOOT > - "mmc bootbus dev boot_bus_width reset_boot_bus_width boot_mode\n" > + "mmc bootbus > \n" > " - Set the BOOT_BUS_WIDTH field of the specified device\n" > "mmc bootpart-resize \n" > " - Change sizes of boot and RPMB partitions of specified device\n" > - "mmc partconf dev [boot_ack boot_partition partition_access]\n" > + "mmc partconf [boot_ack boot_partition partition_access]\n" > " - Show or change the bits of the PARTITION_CONFIG field of the > specified device\n" > - "mmc rst-function dev value\n" > + "mmc rst-function \n" > " - Change the RST_n_FUNCTION field of the specified device\n" > " WARNING: This is a write-once field and 0 / 1 / 2 are the only > valid values.\n" > #endif >
Re: [PATCH] mmc: initialize an err variable
On 12/8/20 7:10 AM, Tom Rini wrote: > On Fri, Dec 04, 2020 at 06:36:00AM +0900, Jaehoon Chung wrote: > >> Initialize an err variable to 0. >> >> Signed-off-by: Jaehoon Chung > > Reported-by: Coverity (CID: 313548) > Reviewed-by: Tom Rini Ping. Is there any progress about this patch? Best Regards, Jaehoon Chung >
Re: [PATCH] common: splash_source: fix -Wint-to-pointer-cast warning
On 12/13/20 12:39 AM, Simon Glass wrote: > On Mon, 7 Dec 2020 at 01:18, Jaehoon Chung wrote: >> >> Fix -Wint-to-pointer-cast warning >> >> common/splash_source.c: In function 'splash_load_raw': >> common/splash_source.c:100:12: warning: cast to pointer from integer of >> different size [-Wint-to-pointer-cast] >> 100 | bmp_hdr = (struct bmp_header *)bmp_load_addr; >> |^ >> common/splash_source.c: In function 'splash_sf_read_raw': >> common/splash_source.c:39:47: warning: cast to pointer from integer of >> different size [-Wint-to-pointer-cast] >>39 | return spi_flash_read(sf, offset, read_size, (void *)bmp_load_addr); >> | ^ >> >> Signed-off-by: Jaehoon Chung >> --- >> common/splash_source.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> > > Reviewed-by: Simon Glass Ping. Is there any progress about this patch? Best Regards, Jaehoon Chung >
Re: Converting imx28-evk to DM
On Wed, Feb 17, 2021 at 9:00 PM Fabio Estevam wrote: > > Hi Lukasz, > > I am working on converting imx28-evk to DM. > > Things are working as expected and U-Boot is able to boot the Linux kernel. > > I am getting the following error though: > > U-Boot 2021.04-rc1-00219-g7fa88ac80054-dirty (Feb 17 2021 - 20:53:16 -0300) > > CPU: Freescale i.MX28 rev1.2 at 454 MHz > BOOT: SSP SD/MMC #0, 3V3 > DRAM: 128 MiB > NAND: 0 MiB > MMC: MXS MMC: 0, MXS MMC: 1 > Loading Environment from MMC... mxs_of_to_plat: 'gpio-ranges' not > defined - using default! Ah, just needed to include "imx28-u-boot.dtsi". I thought this was included automatically. Now the error is gone. Thanks
Re: [PATCH v5 6/6] test/py: ecdsa: Add test for mkimage ECDSA signing
On 2/17/21 5:03 PM, Tom Rini wrote: On Thu, Jan 28, 2021 at 09:52:48AM -0600, Alexandru Gagniuc wrote: Add a test to make sure that the ECDSA signatures generated by mkimage can be verified successfully. pyCryptodomex was chosen as the crypto library because it integrates much better with python code. Using openssl would have been unnecessarily painful. Signed-off-by: Alexandru Gagniuc Reviewed-by: Simon Glass So, to run this test I've done a "pip install -r test/py/requirements.txt" to make sure I have everything now needed installed. When I run this test (building in /tmp): +/tmp/.bm-work/sandbox/tools/mkimage -F /tmp/.bm-work/sandbox/test.fit -k/tmp/.bm-work/sandbox/ecdsa-test-key.pem Can not get key file '/tmp/.bm-work/sandbox/ecdsa-test-key.pem/dev.pem' Can not get key file '/tmp/.bm-work/sandbox/ecdsa-test-key.pem/dev.pem' Failed to sign 'signature' signature node in 'kernel' image node: -2 Failed to sign 'signature' signature node in 'fdt-1' image node: -2 FIT description: Chrome OS kernel image with one or more FDT blobs ... +fdtget -tbi /tmp/.bm-work/sandbox/test.fit /images/kernel/signature value Error at 'value': FDT_ERR_NOTFOUND Which I think means that since we have a key-name-hint of "dev" it's taking the -k argument as a keydir and that's where it goes wrong. Did this happen with this series alone? I realize not that also applying "mkimage: Add a 'keyfile' argument for image signing" would cause this. I shoudl have (but forgot to) update the test in that series. I'll update the other series if you want to pull them in together. Alex
Converting imx28-evk to DM
Hi Lukasz, I am working on converting imx28-evk to DM. Things are working as expected and U-Boot is able to boot the Linux kernel. I am getting the following error though: U-Boot 2021.04-rc1-00219-g7fa88ac80054-dirty (Feb 17 2021 - 20:53:16 -0300) CPU: Freescale i.MX28 rev1.2 at 454 MHz BOOT: SSP SD/MMC #0, 3V3 DRAM: 128 MiB NAND: 0 MiB MMC: MXS MMC: 0, MXS MMC: 1 Loading Environment from MMC... mxs_of_to_plat: 'gpio-ranges' not defined - using default! Would you have any suggestions for fixing this error? Do you see such a warning in the imx28_xea_defconfig target? Thanks, Fabio Estevam
Re: [PATCH v2] cmd: mmc: add mmc bootpart-check
Hi,
On 2/18/21 1:35 AM, grygorii tertychnyi wrote:
> This patch allows to check the current boot partition. It is useful
> when you use two different sets of (bootloader, kernel) images and
> want to boot the corresponding kernel image in boot script. E.g.:
>
> if mmc bootpart-check ${mmcdev} 1; then
> echo "booted from eMMC boot0 partition"
> ...load kernel image1
> elif mmc bootpart-check ${mmcdev} 2; then
> echo "booted from eMMC boot1 partition"
> ...load kernel image2
> fi
If mmc_bootpart-check is used, it's just for your
bootsripts.
Your patch is doing nothing...
U-boot> mmc bootpart-check 1 1
U-boot> mmc bootpart-check 1 2
U-boot> mmc bootpart-check 1 3
To use this command by other developer, it needs to be more useful than now.
So i think good that displayed the bootpart value in your patch.
Then it doesn't need to use "echo booted from.." in your bootscript.
e.g) if success..
U-boot> mmc bootpart-check 1 1
Boot partition 1 enabled for boot
if fail
U-boot> mmc bootpart-check 1 1
Boot partition 2 enabled for boot
Code can be the below..
switch (part_emmc) {
case 0x0:
printf("Device not boot enabled");
break;
case 0x1:
printf("Boot partition 1 ...);
break;
case 0x2:
...
default:
printf("BOOT_PARTITION_ENABLE is reserved\n");
}
Then other developer and you can get more information with this command.
Also when checking is failed, it can provide which bootpart is valid.
And this patch's commit-msg can be described more common, not only bootscript's
case.
how about this?
>
> Signed-off-by: Grygorii Tertychnyi
I think better that Signed-off-by and Author's email address maintains to same.
Author: grygorii tertychnyi
Date: Wed Feb 17 17:35:16 2021 +0100
cmd: mmc: add mmc bootpart-check
Best Regards,
Jaehoon Chung
> ---
> v2:
> - renamed the command, it is "bootpart-check" now
> - added <> to mandatory arguments help string
> - added more details to commit message
>
> cmd/mmc.c | 39 +++
> 1 file changed, 39 insertions(+)
>
> diff --git a/cmd/mmc.c b/cmd/mmc.c
> index 1529a3e05ddd..3332dee4b130 100644
> --- a/cmd/mmc.c
> +++ b/cmd/mmc.c
> @@ -771,6 +771,41 @@ static int do_mmc_boot_resize(struct cmd_tbl *cmdtp, int
> flag,
> return CMD_RET_SUCCESS;
> }
>
> +static int do_mmc_boot_check(struct cmd_tbl *cmdtp, int flag,
> + int argc, char *const argv[])
> +{
> + int dev;
> + struct mmc *mmc;
> + u8 part_args, part_emmc;
> +
> + if (argc != 3)
> + return CMD_RET_USAGE;
> +
> + dev = simple_strtoul(argv[1], NULL, 10);
> +
> + mmc = init_mmc_device(dev, false);
> + if (!mmc)
> + return CMD_RET_FAILURE;
> +
> + if (IS_SD(mmc)) {
> + printf("It is not an eMMC device\n");
> + return CMD_RET_FAILURE;
> + }
> +
> + if (mmc->part_config == MMCPART_NOAVAILABLE) {
> + printf("No part_config info for ver. 0x%x\n", mmc->version);
> + return CMD_RET_FAILURE;
> + }
> +
> + part_emmc = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
> + part_args = simple_strtoul(argv[2], NULL, 10);
> +
> + if (part_emmc == part_args)
> + return CMD_RET_SUCCESS;
> + else
> + return CMD_RET_FAILURE;
> +}
> +
> static int mmc_partconf_print(struct mmc *mmc)
> {
> u8 ack, access, part;
> @@ -952,6 +987,7 @@ static struct cmd_tbl cmd_mmc[] = {
> #endif
> #ifdef CONFIG_SUPPORT_EMMC_BOOT
> U_BOOT_CMD_MKENT(bootbus, 5, 0, do_mmc_bootbus, "", ""),
> + U_BOOT_CMD_MKENT(bootpart-check, 3, 0, do_mmc_boot_check, "", ""),
> U_BOOT_CMD_MKENT(bootpart-resize, 4, 0, do_mmc_boot_resize, "", ""),
> U_BOOT_CMD_MKENT(partconf, 5, 0, do_mmc_partconf, "", ""),
> U_BOOT_CMD_MKENT(rst-function, 3, 0, do_mmc_rst_func, "", ""),
> @@ -1019,6 +1055,9 @@ U_BOOT_CMD(
> #ifdef CONFIG_SUPPORT_EMMC_BOOT
> "mmc bootbus dev boot_bus_width reset_boot_bus_width boot_mode\n"
> " - Set the BOOT_BUS_WIDTH field of the specified device\n"
> + "mmc bootpart-check \n"
> + " - Return success if the given boot_partition value matches
> BOOT_PARTITION_ENABLE\n"
> + " bit field of the specified device\n"
> "mmc bootpart-resize \n"
> " - Change sizes of boot and RPMB partitions of specified device\n"
> "mmc partconf dev [boot_ack boot_partition partition_access]\n"
>
Re: [PATCH v5 6/6] test/py: ecdsa: Add test for mkimage ECDSA signing
On Thu, Jan 28, 2021 at 09:52:48AM -0600, Alexandru Gagniuc wrote: > Add a test to make sure that the ECDSA signatures generated by > mkimage can be verified successfully. pyCryptodomex was chosen as the > crypto library because it integrates much better with python code. > Using openssl would have been unnecessarily painful. > > Signed-off-by: Alexandru Gagniuc > Reviewed-by: Simon Glass So, to run this test I've done a "pip install -r test/py/requirements.txt" to make sure I have everything now needed installed. When I run this test (building in /tmp): +/tmp/.bm-work/sandbox/tools/mkimage -F /tmp/.bm-work/sandbox/test.fit -k/tmp/.bm-work/sandbox/ecdsa-test-key.pem Can not get key file '/tmp/.bm-work/sandbox/ecdsa-test-key.pem/dev.pem' Can not get key file '/tmp/.bm-work/sandbox/ecdsa-test-key.pem/dev.pem' Failed to sign 'signature' signature node in 'kernel' image node: -2 Failed to sign 'signature' signature node in 'fdt-1' image node: -2 FIT description: Chrome OS kernel image with one or more FDT blobs ... +fdtget -tbi /tmp/.bm-work/sandbox/test.fit /images/kernel/signature value Error at 'value': FDT_ERR_NOTFOUND Which I think means that since we have a key-name-hint of "dev" it's taking the -k argument as a keydir and that's where it goes wrong. -- Tom signature.asc Description: PGP signature
Re: About doc/usage directory
On 2/17/21 3:14 PM, Heinrich Schuchardt wrote: > Am 17. Februar 2021 07:06:02 MEZ schrieb Jaehoon Chung > : >> Hi all, >> >> I have a question about usage page. >> I have found files under doc/usage/. It's description how to use each >> command. >> But there is not mmc.rst and file relevant to power command.(regulator, >> pmic, etc) >> If someone didn't have any plan, I want to update file relevant to mmc >> and pmic command. >> >> Is there any rule to update it? My goal is to apply next release. > > Thank you for taking care of these man-pages. > > As it is documentation, reaching the next release should not pose a problem. > > I not aware of any current work. > > You could use load.rst as a template for structuring your pages. Thanks! I will do it. Best Regards, Jaehoon Chung > > Best regards > > Heinrich > > >> >> If someone are already doing this, let me know, plz. >> >> Best Regards, >> Jaehoon Chung > >
Re: [PATCH 16/25] arm: Remove gwventana boards
On Wed, Feb 17, 2021 at 10:26:20AM -0800, Tim Harvey wrote:
> On Wed, Feb 10, 2021 at 9:31 AM Tom Rini wrote:
> >
> > On Wed, Feb 10, 2021 at 09:29:44AM -0800, Tim Harvey wrote:
> > > On Tue, Feb 9, 2021 at 5:03 AM Tom Rini wrote:
> > > >
> > > > These boards have not been converted to CONFIG_DM_MMC by the deadline of
> > > > v2019.04, which is almost two years ago. In addition there are other DM
> > > > migrations it is also missing. Remove them.
> > > >
> > > > Cc: Tim Harvey
> > > > Signed-off-by: Tom Rini
> > > > ---
> > > > arch/arm/mach-imx/mx6/Kconfig |1 -
> > > > board/gateworks/gw_ventana/Kconfig | 28 -
> > > > board/gateworks/gw_ventana/MAINTAINERS |8 -
> > > > board/gateworks/gw_ventana/Makefile | 11 -
> > > > board/gateworks/gw_ventana/README | 320
> > > > board/gateworks/gw_ventana/common.c | 1760 ---
> > > > board/gateworks/gw_ventana/common.h | 99 --
> > > > board/gateworks/gw_ventana/eeprom.c | 266 ---
> > > > board/gateworks/gw_ventana/gsc.c| 283 ---
> > > > board/gateworks/gw_ventana/gsc.h| 71 -
> > > > board/gateworks/gw_ventana/gw_ventana.c | 1381 ---
> > > > board/gateworks/gw_ventana/gw_ventana_spl.c | 779
> > > > board/gateworks/gw_ventana/ventana_eeprom.h | 140 --
> > > > configs/gwventana_emmc_defconfig| 111 --
> > > > configs/gwventana_gw5904_defconfig | 115 --
> > > > configs/gwventana_nand_defconfig| 115 --
> > > > include/configs/gw_ventana.h| 298
> > > > 17 files changed, 5786 deletions(-)
> > > > delete mode 100644 board/gateworks/gw_ventana/Kconfig
> > > > delete mode 100644 board/gateworks/gw_ventana/MAINTAINERS
> > > > delete mode 100644 board/gateworks/gw_ventana/Makefile
> > > > delete mode 100644 board/gateworks/gw_ventana/README
> > > > delete mode 100644 board/gateworks/gw_ventana/common.c
> > > > delete mode 100644 board/gateworks/gw_ventana/common.h
> > > > delete mode 100644 board/gateworks/gw_ventana/eeprom.c
> > > > delete mode 100644 board/gateworks/gw_ventana/gsc.c
> > > > delete mode 100644 board/gateworks/gw_ventana/gsc.h
> > > > delete mode 100644 board/gateworks/gw_ventana/gw_ventana.c
> > > > delete mode 100644 board/gateworks/gw_ventana/gw_ventana_spl.c
> > > > delete mode 100644 board/gateworks/gw_ventana/ventana_eeprom.h
> > > > delete mode 100644 configs/gwventana_emmc_defconfig
> > > > delete mode 100644 configs/gwventana_gw5904_defconfig
> > > > delete mode 100644 configs/gwventana_nand_defconfig
> > > > delete mode 100644 include/configs/gw_ventana.h
> > > >
> > >
> > > Tom,
> > >
> > > I will submit a patchset to convert the gw_ventana IMX6 based boards
> > > to DM. I started this effort over a year ago and got stuck at some
> > > point but I think I know how to get through that now.
> > >
> > > I hope to be able to submit something by the end of next week.
> >
> > Thanks! Their conversion will help unblock a few of the older
> > migrations.
>
> Tom / Stefano,
>
> Looking at this again I realize where I got stuck previously trying to
> migrate the Gateworks Ventana support to driver-model.
Thanks for digging in and summarizing.
> 1. I need MULTI_DTB_FIT for raw NAND and the following issues are blocking me:
> a. spl_nand_fit_read() requires the reads to be page-aligned to the
> writesize of the NAND device. I have to work through trying to give
> the common nand spl code knowledge of the mtd device to get around
> this.
> b. spl_nand_fit_read() since 9f6a14c47ff9 ("spl: fit: nand: fix fit
> loading in case of bad blocks") which introduces bad block handling
> now requires a lot of static defines describing the NAND chip such as
> CONFIG_SYS_NAND_BLOCK_SIZE CONFIG_SYS_NAND_BAD_BLOCK_POS and a few
> more that I need to get from mtd as well as we support multiple flash
> devices that have different geometries. I can wrap that code around an
> 'ifdef CONFIG_SYS_NAND_BLOCK_SIZE' to opt out of that feature.
Which is all SPL related, right? It seems so, but to be clear...
> 2. I have a board with an MV88E61XX switch and
> drivers/net/phy/mv88e61xx.c and I don't see any driver-model support
> for eth switches connected to a phy. This blocks me from using DM_ETH.
> I have an unsubmitted patch queued up depending on my imx8mm-venice
> series that I think may provide a dm solution for network switches via
> DM_ETH_PHY.
> 3. I can't use driver model for SPL because of memory constraints: I
> need to read the board model from an I2C EEPROM in the SPL and then if
> I wanted to use SPL dm I would have to use dm_uninit() followed by
> dm_init_and_scan() which doesn't work because dm_uninit() does not
> free memory. It seems to me the DM_SPL code needs to implement memory
> free.
>
> The biggest hurdle I see is (3) above and as far as I can tell most if
> not all other IMX boards are not using driv
Re: [PATCH 16/25] arm: Remove gwventana boards
On Wed, Feb 10, 2021 at 9:31 AM Tom Rini wrote:
>
> On Wed, Feb 10, 2021 at 09:29:44AM -0800, Tim Harvey wrote:
> > On Tue, Feb 9, 2021 at 5:03 AM Tom Rini wrote:
> > >
> > > These boards have not been converted to CONFIG_DM_MMC by the deadline of
> > > v2019.04, which is almost two years ago. In addition there are other DM
> > > migrations it is also missing. Remove them.
> > >
> > > Cc: Tim Harvey
> > > Signed-off-by: Tom Rini
> > > ---
> > > arch/arm/mach-imx/mx6/Kconfig |1 -
> > > board/gateworks/gw_ventana/Kconfig | 28 -
> > > board/gateworks/gw_ventana/MAINTAINERS |8 -
> > > board/gateworks/gw_ventana/Makefile | 11 -
> > > board/gateworks/gw_ventana/README | 320
> > > board/gateworks/gw_ventana/common.c | 1760 ---
> > > board/gateworks/gw_ventana/common.h | 99 --
> > > board/gateworks/gw_ventana/eeprom.c | 266 ---
> > > board/gateworks/gw_ventana/gsc.c| 283 ---
> > > board/gateworks/gw_ventana/gsc.h| 71 -
> > > board/gateworks/gw_ventana/gw_ventana.c | 1381 ---
> > > board/gateworks/gw_ventana/gw_ventana_spl.c | 779
> > > board/gateworks/gw_ventana/ventana_eeprom.h | 140 --
> > > configs/gwventana_emmc_defconfig| 111 --
> > > configs/gwventana_gw5904_defconfig | 115 --
> > > configs/gwventana_nand_defconfig| 115 --
> > > include/configs/gw_ventana.h| 298
> > > 17 files changed, 5786 deletions(-)
> > > delete mode 100644 board/gateworks/gw_ventana/Kconfig
> > > delete mode 100644 board/gateworks/gw_ventana/MAINTAINERS
> > > delete mode 100644 board/gateworks/gw_ventana/Makefile
> > > delete mode 100644 board/gateworks/gw_ventana/README
> > > delete mode 100644 board/gateworks/gw_ventana/common.c
> > > delete mode 100644 board/gateworks/gw_ventana/common.h
> > > delete mode 100644 board/gateworks/gw_ventana/eeprom.c
> > > delete mode 100644 board/gateworks/gw_ventana/gsc.c
> > > delete mode 100644 board/gateworks/gw_ventana/gsc.h
> > > delete mode 100644 board/gateworks/gw_ventana/gw_ventana.c
> > > delete mode 100644 board/gateworks/gw_ventana/gw_ventana_spl.c
> > > delete mode 100644 board/gateworks/gw_ventana/ventana_eeprom.h
> > > delete mode 100644 configs/gwventana_emmc_defconfig
> > > delete mode 100644 configs/gwventana_gw5904_defconfig
> > > delete mode 100644 configs/gwventana_nand_defconfig
> > > delete mode 100644 include/configs/gw_ventana.h
> > >
> >
> > Tom,
> >
> > I will submit a patchset to convert the gw_ventana IMX6 based boards
> > to DM. I started this effort over a year ago and got stuck at some
> > point but I think I know how to get through that now.
> >
> > I hope to be able to submit something by the end of next week.
>
> Thanks! Their conversion will help unblock a few of the older
> migrations.
Tom / Stefano,
Looking at this again I realize where I got stuck previously trying to
migrate the Gateworks Ventana support to driver-model.
1. I need MULTI_DTB_FIT for raw NAND and the following issues are blocking me:
a. spl_nand_fit_read() requires the reads to be page-aligned to the
writesize of the NAND device. I have to work through trying to give
the common nand spl code knowledge of the mtd device to get around
this.
b. spl_nand_fit_read() since 9f6a14c47ff9 ("spl: fit: nand: fix fit
loading in case of bad blocks") which introduces bad block handling
now requires a lot of static defines describing the NAND chip such as
CONFIG_SYS_NAND_BLOCK_SIZE CONFIG_SYS_NAND_BAD_BLOCK_POS and a few
more that I need to get from mtd as well as we support multiple flash
devices that have different geometries. I can wrap that code around an
'ifdef CONFIG_SYS_NAND_BLOCK_SIZE' to opt out of that feature.
2. I have a board with an MV88E61XX switch and
drivers/net/phy/mv88e61xx.c and I don't see any driver-model support
for eth switches connected to a phy. This blocks me from using DM_ETH.
I have an unsubmitted patch queued up depending on my imx8mm-venice
series that I think may provide a dm solution for network switches via
DM_ETH_PHY.
3. I can't use driver model for SPL because of memory constraints: I
need to read the board model from an I2C EEPROM in the SPL and then if
I wanted to use SPL dm I would have to use dm_uninit() followed by
dm_init_and_scan() which doesn't work because dm_uninit() does not
free memory. It seems to me the DM_SPL code needs to implement memory
free.
The biggest hurdle I see is (3) above and as far as I can tell most if
not all other IMX boards are not using driver model for SPL. If this
is true, then there are a lot of boards out there that haven't been
able to fully swtich to driver model and are getting missed in the
checks because DM_USB, DM_MMC, DM_* are defined for U-boot proper.
That does not help remove legacy code from what I can tell.
What are your thoughts on the fact that many (majority?) bo
Re: [PATCH 5/8] image: Adjust the workings of fit_check_format()
On 17.02.2021 14.43, Tom Rini wrote: On Wed, Feb 17, 2021 at 02:30:56PM +0100, Jesper Schmitz Mouridsen wrote: Hi Can you avoid the use of ENODATA since it is not defined in FreeBSD's errno.h? I like that FreeBSD has EDOOFUS, but I don't see an obvious replacement for ENODATA, can you suggest something please? Thanks! Perhaps EBADMSG?
Re: [PATCH V2] nvme: Fix cache alignment
On 2/16/21 2:00 AM, Bin Meng wrote: Hi Marek, Hi, On Tue, Feb 16, 2021 at 3:16 AM Marek Vasut wrote: The various structures in the driver are already correctly padded and cache aligned in memory, however the cache operations are called on the structure sizes, which themselves might not be cache aligned. Add the necessary rounding to fix this, which permits the nvme to work on arm64. Signed-off-by: Marek Vasut Cc: Bin Meng --- V2: Fix typo in the bugfix description --- drivers/nvme/nvme.c | 50 + 1 file changed, 32 insertions(+), 18 deletions(-) Would you give a chance to test Andre's patch? http://patchwork.ozlabs.org/project/uboot/patch/20210208133154.12645-1-andre.przyw...@arm.com/ Cc some people who have looked at Andre's patch I'll let you decide which patch to pick, thanks.
RE: [PATCH] Tegra: remove e2220-1170 board
Peter Robinson wrote at Wednesday, February 17, 2021 10:07 AM: > It's an old bringup board with out upstream Linux or L4T support > > Signed-off-by: Peter Robinson > Cc: Stephen Warren > Cc: Tom Warren > --- > > The E2220-1170 was a Tegra210 bringup board and outside of source wide > or SoC wide changes it's no seen any additions since it landed over 5 > years ago, I doubt anyone outside nvidia actually has one and there's > no upstream Linux dtb for it and it appears the support in L4T has > been dropped as there's no config or dtb included in the R32.4.4 release. > > Tom or Stephen is there any need for it to hang around still? Acked-by: Stephen Warren I thought I'd sent this patch before, but maybe I'm thinking of an even older board (Whistler?) -- nvpublic
sunxi/pinephone suggestions and fixes
Hello.
Please consider the attached suggestions for the sunxi/pinephone
platform.
Among commits written for and by Mobian users, these ones may be of
interest for all pinephone owners.
Each header mentions the original motivation and author.
Thanks.
(Please CC me in follow-ups)
>From 170dde27a95b0cde433dfbe2e5996424c66e8320 Mon Sep 17 00:00:00 2001
From: Arnaud Ferraris
Date: Mon, 24 Feb 2020 11:37:42 +0100
Subject: [PATCH 2/4] pinephone_defconfig: reduce boot delay
On a cellular phone, the vast majority of users can be expected to
have no serial console connected and prefer a short boot.
---
configs/pinephone_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/pinephone_defconfig b/configs/pinephone_defconfig
index 9967cddab9..9b51a7a100 100644
--- a/configs/pinephone_defconfig
+++ b/configs/pinephone_defconfig
@@ -10,4 +10,5 @@
CONFIG_PINEPHONE_DT_SELECTION=y
CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pinephone-1.2"
# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_BOOTDELAY=0
CONFIG_OF_LIST="sun50i-a64-pinephone-1.1 sun50i-a64-pinephone-1.2"
--
2.20.1
>From 9cc9a9c0131057816d2f7e5a53efc05008d22d6d Mon Sep 17 00:00:00 2001
From: Marius Gripsgard
Date: Tue, 5 May 2020 16:51:13 +0200
Subject: [PATCH 20/20] Enable led on boot to notify user of boot status
---
arch/arm/mach-sunxi/Kconfig | 5 +
board/sunxi/board.c | 4 ++--
configs/pinephone_defconfig | 1 +
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 8421f3b685..2bfdf7738b 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -1,5 +1,10 @@
if ARCH_SUNXI
+config PINEPHONE_LEDS
+ bool "Notify boot status via LEDs on PinePhone"
+ ---help---
+ LED boot notification.
+
config SPL_LDSCRIPT
default "arch/arm/cpu/armv7/sunxi/u-boot-spl.lds" if !ARM64
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index abd7e390b2..a117b89ba2 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -637,6 +638,12 @@ void sunxi_board_init(void)
{
int power_failed = 0;
+#ifdef CONFIG_PINEPHONE_LEDS
+ /* PD18:G PD19:R PD20:B */
+ gpio_request(SUNXI_GPD(18), "led:green");
+ gpio_direction_output(SUNXI_GPD(18), 1);
+#endif
+
#ifdef CONFIG_SY8106A_POWER
power_failed = sy8106a_set_vout1(CONFIG_SY8106A_VOUT1_VOLT);
#endif
diff --git a/configs/pinephone_defconfig b/configs/pinephone_defconfig
index ff5da42ce0..9de6ab2316 100644
--- a/configs/pinephone_defconfig
+++ b/configs/pinephone_defconfig
@@ -1,6 +21,7 @@
CONFIG_ARM=y
CONFIG_ARCH_SUNXI=y
CONFIG_SPL=y
+CONFIG_PINEPHONE_LEDS=y
CONFIG_MACH_SUN50I=y
CONFIG_SUNXI_DRAM_LPDDR3_STOCK=y
CONFIG_DRAM_CLK=552
--
2.26.2
>From 26251b8792608080e2e8a551291e8a362cc31769 Mon Sep 17 00:00:00 2001
From: Icenowy Zheng
Date: Fri, 19 Jun 2020 20:16:57 +0800
Subject: [PATCH] sunxi: support asymmetric dual rank DRAM on A64/R40
Previously we have known that R40 has a configuration register for its
rank 1, which allows different configuration than rank 0. Reverse
engineering of newest libdram of A64 from Allwinner shows that A64 has
this register too. It's bit 0 (which enables dual rank in rank 0
configuration register) means a dedicated rank size setup is used for
rank 1.
Now, Pine64 scheduled to use a 3GiB LPDDR3 DRAM chip (which has 2GiB
rank 0 and 1GiB rank 1) on PinePhone, that makes asymmetric dual rank
DRAM support necessary.
Add this support. As we have gained knowledge of asymmetric dual rank,
we can now allow R40 dual rank memory setup to work too.
Signed-off-by: Icenowy Zheng
---
.../include/asm/arch-sunxi/dram_sunxi_dw.h| 11 +-
arch/arm/mach-sunxi/dram_sunxi_dw.c | 100 +-
2 files changed, 84 insertions(+), 27 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h b/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
index a5a7ebde44..e843c14202 100644
--- a/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
+++ b/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
@@ -215,12 +215,17 @@ struct sunxi_mctl_ctl_reg {
#define NR_OF_BYTE_LANES (32 / BITS_PER_BYTE)
/* The eight data lines (DQn) plus DM, DQS and DQSN */
#define LINES_PER_BYTE_LANE (BITS_PER_BYTE + 3)
-struct dram_para {
+
+struct rank_para {
u16 page_size;
- u8 bus_full_width;
- u8 dual_rank;
u8 row_bits;
u8 bank_bits;
+};
+
+struct dram_para {
+ u8 dual_rank;
+ u8 bus_full_width;
+ struct rank_para ranks[2];
const u8 dx_read_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE];
const u8 dx_write_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE];
const u8 ac_delays[31];
diff --git a/arch/arm/mach-sunxi/dram_sunxi_dw.c b/arch/arm/mach-sunxi/dram_sunxi_dw.c
index 85e7a1874e..b679f92e70 100644
--- a/arch/arm/mach-sunxi/dram_sunxi_dw.c
+++ b/arch/arm/mach-sunxi/dram_sunxi_dw.c
@@ -346,18 +346,24 @@ static void mctl_set_cr(uint16_t socid, struct dram_para *para)
#else
#error Unsupported DRAM type!
#endif
- (para->bank_bits == 3 ? MCTL_CR_EIGHT_BANKS :
Re: [PATCH 5/8] image: Adjust the workings of fit_check_format()
Hi
Can you avoid the use of ENODATA since it is not defined in FreeBSD's
errno.h?
Regards
Jesper Schmitz Mouridsen
On 16.02.2021 01.08, Simon Glass wrote:
At present this function does not accept a size for the FIT. This means
that it must be read from the FIT itself, introducing potential security
risk. Update the function to include a size parameter, which can be
invalid, in which case fit_check_format() calculates it.
For now no callers pass the size, but this can be updated later.
Also adjust the return value to an error code so that all the different
types of problems can be distinguished by the user.
Signed-off-by: Simon Glass
Reported-by: Bruce Monroe
Reported-by: Arie Haenel
Reported-by: Julien Lenoir
---
arch/arm/cpu/armv8/sec_firmware.c | 2 +-
cmd/bootefi.c | 2 +-
cmd/bootm.c| 6 ++--
cmd/disk.c | 2 +-
cmd/fpga.c | 2 +-
cmd/nand.c | 2 +-
cmd/source.c | 2 +-
cmd/ximg.c | 2 +-
common/image-fdt.c | 2 +-
common/image-fit.c | 46 +-
common/splash_source.c | 6 ++--
common/update.c| 4 +--
drivers/fpga/socfpga_arria10.c | 6 ++--
drivers/net/fsl-mc/mc.c| 2 +-
drivers/net/pfe_eth/pfe_firmware.c | 2 +-
include/image.h| 21 +-
tools/fit_common.c | 3 +-
tools/fit_image.c | 2 +-
tools/mkimage.h| 2 ++
19 files changed, 66 insertions(+), 50 deletions(-)
diff --git a/arch/arm/cpu/armv8/sec_firmware.c
b/arch/arm/cpu/armv8/sec_firmware.c
index c6c4fcc7e07..267894fbcb3 100644
--- a/arch/arm/cpu/armv8/sec_firmware.c
+++ b/arch/arm/cpu/armv8/sec_firmware.c
@@ -317,7 +317,7 @@ __weak bool sec_firmware_is_valid(const void
*sec_firmware_img)
return false;
}
- if (!fit_check_format(sec_firmware_img)) {
+ if (fit_check_format(sec_firmware_img, IMAGE_SIZE_INVAL)) {
printf("SEC Firmware: Bad firmware image (bad FIT header)\n");
return false;
}
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 1583a96be14..271b385edea 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -73,7 +73,7 @@ void efi_set_bootdev(const char *dev, const char *devnr,
const char *path,
/* Remember only PE-COFF and FIT images */
if (efi_check_pe(buffer, buffer_size, NULL) != EFI_SUCCESS) {
#ifdef CONFIG_FIT
- if (!fit_check_format(buffer))
+ if (fit_check_format(buffer, IMAGE_SIZE_INVAL))
return;
/*
* FIT images of type EFI_OS are started via command bootm.
diff --git a/cmd/bootm.c b/cmd/bootm.c
index 7732b97f635..81c6b939781 100644
--- a/cmd/bootm.c
+++ b/cmd/bootm.c
@@ -292,7 +292,7 @@ static int image_info(ulong addr)
case IMAGE_FORMAT_FIT:
puts(" FIT image found\n");
- if (!fit_check_format(hdr)) {
+ if (fit_check_format(hdr, IMAGE_SIZE_INVAL)) {
puts("Bad FIT image format!\n");
unmap_sysmem(hdr);
return 1;
@@ -369,7 +369,7 @@ static int do_imls_nor(void)
#endif
#if defined(CONFIG_FIT)
case IMAGE_FORMAT_FIT:
- if (!fit_check_format(hdr))
+ if (fit_check_format(hdr, IMAGE_SIZE_INVAL))
goto next_sector;
printf("FIT Image at %08lX:\n", (ulong)hdr);
@@ -449,7 +449,7 @@ static int nand_imls_fitimage(struct mtd_info *mtd, int
nand_dev, loff_t off,
return ret;
}
- if (!fit_check_format(imgdata)) {
+ if (fit_check_format(imgdata, IMAGE_SIZE_INVAL)) {
free(imgdata);
return 0;
}
diff --git a/cmd/disk.c b/cmd/disk.c
index 0bc3808dfe2..2726115e855 100644
--- a/cmd/disk.c
+++ b/cmd/disk.c
@@ -114,7 +114,7 @@ int common_diskboot(struct cmd_tbl *cmdtp, const char
*intf, int argc,
/* This cannot be done earlier,
* we need complete FIT image in RAM first */
if (genimg_get_format((void *) addr) == IMAGE_FORMAT_FIT) {
- if (!fit_check_format(fit_hdr)) {
+ if (fit_check_format(fit_hdr, IMAGE_SIZE_INVAL)) {
bootstage_error(BOOTSTAGE_ID_IDE_FIT_READ);
puts("** Bad FIT image format\n");
return 1;
diff --git a/cmd/fpga.c b/cmd/fpga.c
index 8ae1c936fbb..51410a8e424 100644
--- a/cmd/fpga.c
+++ b/cmd/fpga.c
@@ -330,7 +330,7 @@ static int do_fpga_loadmk(struct cmd_tbl *cmdtp, int flag,
int argc,
return CMD_RET_FAILURE;
}
- if (!fit_check_format(fit_hdr)) {
+ if (fit_check_format(
[PATCH] Tegra: remove e2220-1170 board
It's an old bringup board with out upstream Linux or L4T support
Signed-off-by: Peter Robinson
Cc: Stephen Warren
Cc: Tom Warren
---
The E2220-1170 was a Tegra210 bringup board and outside of source wide
or SoC wide changes it's no seen any additions since it landed over 5
years ago, I doubt anyone outside nvidia actually has one and there's
no upstream Linux dtb for it and it appears the support in L4T has
been dropped as there's no config or dtb included in the R32.4.4 release.
Tom or Stephen is there any need for it to hang around still?
arch/arm/dts/Makefile| 1 -
arch/arm/dts/tegra210-e2220-1170.dts | 63
arch/arm/mach-tegra/tegra210/Kconfig | 9
board/nvidia/e2220-1170/Kconfig | 12 --
board/nvidia/e2220-1170/MAINTAINERS | 6 ---
board/nvidia/e2220-1170/Makefile | 8
board/nvidia/e2220-1170/e2220-1170.c | 32 --
configs/e2220-1170_defconfig | 48 -
include/configs/e2220-1170.h | 28 -
9 files changed, 207 deletions(-)
delete mode 100644 arch/arm/dts/tegra210-e2220-1170.dts
delete mode 100644 board/nvidia/e2220-1170/Kconfig
delete mode 100644 board/nvidia/e2220-1170/MAINTAINERS
delete mode 100644 board/nvidia/e2220-1170/Makefile
delete mode 100644 board/nvidia/e2220-1170/e2220-1170.c
delete mode 100644 configs/e2220-1170_defconfig
delete mode 100644 include/configs/e2220-1170.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 33e483f4fb..1f678c4ed1 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -199,7 +199,6 @@ dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
tegra124-venice2.dtb \
tegra186-p2771--000.dtb \
tegra186-p2771--500.dtb \
- tegra210-e2220-1170.dtb \
tegra210-p2371-.dtb \
tegra210-p2371-2180.dtb \
tegra210-p2571.dtb \
diff --git a/arch/arm/dts/tegra210-e2220-1170.dts
b/arch/arm/dts/tegra210-e2220-1170.dts
deleted file mode 100644
index e6b06862d8..00
--- a/arch/arm/dts/tegra210-e2220-1170.dts
+++ /dev/null
@@ -1,63 +0,0 @@
-/dts-v1/;
-
-#include "tegra210.dtsi"
-
-/ {
- model = "NVIDIA E2220-1170";
- compatible = "nvidia,e2220-1170", "nvidia,tegra210";
-
- chosen {
- stdout-path = &uarta;
- };
-
- aliases {
- i2c0 = "/i2c@7000d000";
- mmc0 = "/sdhci@700b0600";
- mmc1 = "/sdhci@700b";
- usb0 = "/usb@7d00";
- };
-
- memory {
- reg = <0x0 0x8000 0x0 0xc000>;
- };
-
- sdhci@700b {
- status = "okay";
- cd-gpios = <&gpio TEGRA_GPIO(Z, 1) GPIO_ACTIVE_LOW>;
- power-gpios = <&gpio TEGRA_GPIO(Z, 4) GPIO_ACTIVE_HIGH>;
- bus-width = <4>;
- };
-
- sdhci@700b0600 {
- status = "okay";
- bus-width = <8>;
- non-removable;
- };
-
- i2c@7000d000 {
- status = "okay";
- clock-frequency = <40>;
- };
-
- usb@7d00 {
- status = "okay";
- dr_mode = "peripheral";
- };
-
- clocks {
- compatible = "simple-bus";
- #address-cells = <1>;
- #size-cells = <0>;
-
- clk32k_in: clock@0 {
- compatible = "fixed-clock";
- reg = <0>;
- #clock-cells = <0>;
- clock-frequency = <32768>;
- };
- };
-};
-
-&uarta {
- status = "okay";
-};
diff --git a/arch/arm/mach-tegra/tegra210/Kconfig
b/arch/arm/mach-tegra/tegra210/Kconfig
index 97ed8e05f4..17f18cbf30 100644
--- a/arch/arm/mach-tegra/tegra210/Kconfig
+++ b/arch/arm/mach-tegra/tegra210/Kconfig
@@ -3,14 +3,6 @@ if TEGRA210
choice
prompt "Tegra210 board select"
-config TARGET_E2220_1170
- bool "NVIDIA Tegra210 E2220-1170 board"
- select BOARD_LATE_INIT
- help
- E2220-1170 is a Tegra210 bringup board with onboard SoC, DRAM,
- eMMC, SD card slot, HDMI, USB micro-B port, and sockets for various
- expansion modules.
-
config TARGET_P2371_
bool "NVIDIA Tegra210 P2371- board"
select BOARD_LATE_INIT
@@ -46,7 +38,6 @@ endchoice
config SYS_SOC
default "tegra210"
-source "board/nvidia/e2220-1170/Kconfig"
source "board/nvidia/p2371-/Kconfig"
source "board/nvidia/p2371-2180/Kconfig"
source "board/nvidia/p2571/Kconfig"
diff --git a/board/nvidia/e2220-1170/Kconfig b/board/nvidia/e2220-1170/Kconfig
deleted file mode 100644
index 0a30f49362..00
--- a/board/nvidia/e2220-1170/Kconfig
+++ /dev/null
@@ -1,12 +0,0 @@
-if TARGET_E2220_1170
-
-config SYS_BOARD
- default "e2220-1170"
-
-config SYS_VENDOR
- default "nvidia"
-
-config SYS_CONFIG_NAME
- default "e2220-1170"
-
-endif
diff --git a/board/nvidia/e22
[PATCH 1/1] doc: booti man-page
Provide a man-page for the booti command. Signed-off-by: Heinrich Schuchardt --- doc/usage/booti.rst | 114 doc/usage/index.rst | 1 + 2 files changed, 115 insertions(+) create mode 100644 doc/usage/booti.rst diff --git a/doc/usage/booti.rst b/doc/usage/booti.rst new file mode 100644 index 00..d631fb571d --- /dev/null +++ b/doc/usage/booti.rst @@ -0,0 +1,114 @@ +.. SPDX-License-Identifier: GPL-2.0+: + +booti command += + +Synopsis + + +:: + +booti [ [[:]] []] + +Description +--- + +The booti command is used to boot a Linux kernel in flat or compressed +'Image' format. Which compressed formats are supported is configurable. + +addr +address of kernel image, defaults to CONFIG_SYS_LOAD_ADDR. + +initrd +address of the initial RAM disk. Use '-' to boot a kernel with a device +tree but without an initial RAM disk. + +size +size of the initial RAM disk. This parameter must be specified for raw +initial RAM disks. + +fdt +address of the device tree. + +To support compressed Image files the following environment variables must be +set: + +kernel_comp_addr_r +start of memory area used for decompression + +kernel_comp_size +size of the compressed file. The value has to be at least the size of +loaded image for decompression to succeed. For the booti command the +maximum decompressed size is 10 times this value. + +Example +--- + +This is the boot log of an Odroid C2 board: + +:: + +=> load mmc 0:1 $fdt_addr_r dtb-5.10.0-3-arm64 +27530 bytes read in 7 ms (3.7 MiB/s) +=> load mmc 0:1 $kernel_addr_r vmlinuz-5.10.0-3-arm64 +26990448 bytes read in 1175 ms (21.9 MiB/s) +=> load mmc 0:1 $ramdisk_addr_r initrd.img-5.10.0-3-arm64 +27421776 bytes read in 1209 ms (21.6 MiB/s) +=> booti $kernel_addr_r $ramdisk_addr_r:$filesize $fdt_addr_r +Moving Image from 0x808 to 0x820, end=9c6 +## Flattened Device Tree blob at 08008000 + Booting using the fdt blob at 0x8008000 + Loading Ramdisk to 7a52a000, end 7bf50c50 ... OK + Loading Device Tree to 7a52, end 7a529b89 ... OK + +Starting kernel ... + +The kernel can be compressed with gzip: + +.. code-block:: bash + +cd /boot +gzip -k vmlinuz-5.10.0-3-arm64 + +Here is the boot log for the compressed kernel: + +:: + +=> setenv kernel_comp_addr_r 0x5000 +=> setenv kernel_comp_size 0x0400 +=> load mmc 0:1 $fdt_addr_r dtb-5.10.0-3-arm64 +27530 bytes read in 6 ms (4.4 MiB/s) +=> load mmc 0:1 $kernel_addr_r vmlinuz-5.10.0-3-arm64.gz +9267730 bytes read in 402 ms (22 MiB/s) +=> load mmc 0:1 $ramdisk_addr_r initrd.img-5.10.0-3-arm64 +27421776 bytes read in 1181 ms (22.1 MiB/s) +=> booti $kernel_addr_r $ramdisk_addr_r:$filesize $fdt_addr_r + Uncompressing Kernel Image +Moving Image from 0x808 to 0x820, end=9c6 +## Flattened Device Tree blob at 08008000 + Booting using the fdt blob at 0x8008000 + Loading Ramdisk to 7a52a000, end 7bf50c50 ... OK + Loading Device Tree to 7a52, end 7a529b89 ... OK + +Starting kernel ... + +Configuration +- + +The booti command is only available if CONFIG_CMD_BOOTI=y. + +Which compression types are supported depends on: + +* CONFIG_BZIP2 +* CONFIG_GZIP +* CONFIG_LZ4 +* CONFIG_LZMA +* CONFIG_LZO +* CONFIG_ZSTD + +Return value + + +Normally this command does not return. If an error occurs, the return value $? +is set to 1 (false). If the operating system returns to U-Boot, the system is +reset. diff --git a/doc/usage/index.rst b/doc/usage/index.rst index 5754958d7e..7dca91309b 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -15,6 +15,7 @@ Shell commands base bootefi + booti bootmenu button conitrace -- 2.30.0
[PATCH v2] cmd: mmc: add mmc bootpart-check
This patch allows to check the current boot partition. It is useful
when you use two different sets of (bootloader, kernel) images and
want to boot the corresponding kernel image in boot script. E.g.:
if mmc bootpart-check ${mmcdev} 1; then
echo "booted from eMMC boot0 partition"
...load kernel image1
elif mmc bootpart-check ${mmcdev} 2; then
echo "booted from eMMC boot1 partition"
...load kernel image2
fi
Signed-off-by: Grygorii Tertychnyi
---
v2:
- renamed the command, it is "bootpart-check" now
- added <> to mandatory arguments help string
- added more details to commit message
cmd/mmc.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/cmd/mmc.c b/cmd/mmc.c
index 1529a3e05ddd..3332dee4b130 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -771,6 +771,41 @@ static int do_mmc_boot_resize(struct cmd_tbl *cmdtp, int
flag,
return CMD_RET_SUCCESS;
}
+static int do_mmc_boot_check(struct cmd_tbl *cmdtp, int flag,
+int argc, char *const argv[])
+{
+ int dev;
+ struct mmc *mmc;
+ u8 part_args, part_emmc;
+
+ if (argc != 3)
+ return CMD_RET_USAGE;
+
+ dev = simple_strtoul(argv[1], NULL, 10);
+
+ mmc = init_mmc_device(dev, false);
+ if (!mmc)
+ return CMD_RET_FAILURE;
+
+ if (IS_SD(mmc)) {
+ printf("It is not an eMMC device\n");
+ return CMD_RET_FAILURE;
+ }
+
+ if (mmc->part_config == MMCPART_NOAVAILABLE) {
+ printf("No part_config info for ver. 0x%x\n", mmc->version);
+ return CMD_RET_FAILURE;
+ }
+
+ part_emmc = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
+ part_args = simple_strtoul(argv[2], NULL, 10);
+
+ if (part_emmc == part_args)
+ return CMD_RET_SUCCESS;
+ else
+ return CMD_RET_FAILURE;
+}
+
static int mmc_partconf_print(struct mmc *mmc)
{
u8 ack, access, part;
@@ -952,6 +987,7 @@ static struct cmd_tbl cmd_mmc[] = {
#endif
#ifdef CONFIG_SUPPORT_EMMC_BOOT
U_BOOT_CMD_MKENT(bootbus, 5, 0, do_mmc_bootbus, "", ""),
+ U_BOOT_CMD_MKENT(bootpart-check, 3, 0, do_mmc_boot_check, "", ""),
U_BOOT_CMD_MKENT(bootpart-resize, 4, 0, do_mmc_boot_resize, "", ""),
U_BOOT_CMD_MKENT(partconf, 5, 0, do_mmc_partconf, "", ""),
U_BOOT_CMD_MKENT(rst-function, 3, 0, do_mmc_rst_func, "", ""),
@@ -1019,6 +1055,9 @@ U_BOOT_CMD(
#ifdef CONFIG_SUPPORT_EMMC_BOOT
"mmc bootbus dev boot_bus_width reset_boot_bus_width boot_mode\n"
" - Set the BOOT_BUS_WIDTH field of the specified device\n"
+ "mmc bootpart-check \n"
+ " - Return success if the given boot_partition value matches
BOOT_PARTITION_ENABLE\n"
+ " bit field of the specified device\n"
"mmc bootpart-resize \n"
" - Change sizes of boot and RPMB partitions of specified device\n"
"mmc partconf dev [boot_ack boot_partition partition_access]\n"
--
2.25.1
Re: [PATCH] cmd: mmc: add mmc partboot
On Tue, 16 Feb 2021 at 10:00 Jaehoon Chung wrote:
> On 2/16/21 5:18 PM, gr embeter wrote:
> > Hi Jaehoon,
> > thanks for your comments.
> >
> > On Tue, 16 Feb 2021 at 00:30 Jaehoon Chung
> wrote:
> >
> >> Hi Grygorii,
> >>
> >> On 2/15/21 10:04 PM, gr embeter wrote:
> >>> Hello Jaehoon,
> >>>
> >>> On Sun, 14 Feb 2021 at 23:08 Jaehoon Chung
> >> wrote:
> >>>
> Dear Grygorii,
>
> On 2/12/21 7:32 PM, grygorii tertychnyi wrote:
> > This patch allows to determine active boot partition in boot script:
> >
> > if mmc partboot ${mmcdev} 2; then
> > echo "booted from eMMC boot1 partition"
> > fi
>
> I don't know what purpose this patch has.
> >>>
> >>>
> >>> With an eMMC as a boot source I have two boot partitions, i.e. “boot1”
> >> and
> >>> “boot2”, with two different versions of U-Boot on each partition.
> >>>
> >>> I also have two different kernels located on eMMC “user” partition,
> let’s
> >>> say “image1” and “image2”.
> >>>
> >>> So, I want to boot “image1” kernel if it is U-boot from “boot1”
> partition
> >>> is booted now,
> >>> and to boot “image2” kernel if it is U-boot from “boot2” partition is
> >>> booted.
> >>>
> >>> It is easy to do it manually. I just added possibility to do it with
> >> U-boot
> >>> script now,
> >>> because “mmc partconf ...” does not let you check the current boot
> >>> partition with hush.
> >>>
> >>> Hope, I explained the purpose.
> >>
> >> I remembered. Because i feel to see similar patch to use bootpart.
> >> At that time, i also asked same question. Sorry for not remembered
> yours.
> >>
> >>
> >>
> https://protect2.fireeye.com/v1/url?k=dac52f49-855e1643-dac4a406-0cc47a31384a-4f6e07c1e040623a&q=1&e=3829977a-6bc3-49e3-868a-0dcba5fab9e4&u=https%3A%2F%2Fpatchwork.ozlabs.org%2Fproject%2Fuboot%2Fpatch%2F20201212074633.891704-1-grembeter%40outlook.com%2F
> >>
> >
> > Indeed. I should’ve mentioned this link. Sorry. I’ll extend commit
> message.
> >
> >
> >>>
> >>>
> >>>
>
> Best Regards,
> Jaehoon Chung
>
> >
> > Signed-off-by: Grygorii Tertychnyi <
> grygorii.tertych...@leica-geosystems.com>
> > ---
> > cmd/mmc.c | 39 +++
> > 1 file changed, 39 insertions(+)
> >
> > diff --git a/cmd/mmc.c b/cmd/mmc.c
> > index 1529a3e05ddd..010d6ab9aa19 100644
> > --- a/cmd/mmc.c
> > +++ b/cmd/mmc.c
> > @@ -771,6 +771,41 @@ static int do_mmc_boot_resize(struct cmd_tbl
> *cmdtp, int flag,
> > return CMD_RET_SUCCESS;
> > }
> >
> > +static int do_mmc_partboot(struct cmd_tbl *cmdtp, int flag,
> > +int argc, char *const argv[])
> > +{
> > + int dev;
> > + struct mmc *mmc;
> > + u8 part_args, part_emmc;
> > +
> > + if (argc != 3)
> > + return CMD_RET_USAGE;
> > +
> > + dev = simple_strtoul(argv[1], NULL, 10);
> > +
> > + mmc = init_mmc_device(dev, false);
> > + if (!mmc)
> > + return CMD_RET_FAILURE;
> > +
> > + if (IS_SD(mmc)) {
> > + puts("PARTITION_CONFIG only exists on eMMC\n");
> > + return CMD_RET_FAILURE;
> > + }
> > +
> > + if (mmc->part_config == MMCPART_NOAVAILABLE) {
> > + printf("No part_config info for ver. 0x%x\n",
> mmc->version);
> > + return CMD_RET_FAILURE;
> > + }
> > +
> > + part_emmc = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
> > + part_args = simple_strtoul(argv[2], NULL, 10);
> > +
> > + if (part_emmc == part_args)
> > + return CMD_RET_SUCCESS;
> > + else
> > + return CMD_RET_FAILURE;
> > +}
> > +
> > static int mmc_partconf_print(struct mmc *mmc)
> > {
> > u8 ack, access, part;
> > @@ -953,6 +988,7 @@ static struct cmd_tbl cmd_mmc[] = {
> > #ifdef CONFIG_SUPPORT_EMMC_BOOT
> > U_BOOT_CMD_MKENT(bootbus, 5, 0, do_mmc_bootbus, "", ""),
> > U_BOOT_CMD_MKENT(bootpart-resize, 4, 0, do_mmc_boot_resize, "",
> ""),
> > + U_BOOT_CMD_MKENT(partboot, 3, 0, do_mmc_partboot, "", ""),
> >>
> >> partboot can be confused. how about changing more clear name, like
> >> mmc_bootpart_check?
> >
> >
> > Agree. We have “bootpart-resize”, and “bootpart-check” looks very
> natural.
> >
> > I’ll prepare V2 for
> > mmc bootpart-check
> >
> >
> >>
> > U_BOOT_CMD_MKENT(partconf, 5, 0, do_mmc_partconf, "", ""),
> > U_BOOT_CMD_MKENT(rst-function, 3, 0, do_mmc_rst_func, "", ""),
> > #endif
> > @@ -1021,6 +1057,9 @@ U_BOOT_CMD(
> > " - Set the BOOT_BUS_WIDTH field of the specified device\n"
> > "mmc bootpart-resize MB>\n"
> > " - Change sizes of boot and RPMB partitions of specified
> >> device\n"
> > + "mmc partboot dev boot_partition\n"
> >>
> >> why it needs to pass "
[PATCH] mips: mtmips: Kconfig: select options used in SPL
debug_uart_init SPL_SERIAL_SUPPORT __udelaySPL_LIBGENERIC_SUPPORT putsSPL_LIBCOMMON_SUPPORT default_serial_console SPL_DM / SPL_DM_SERIAL after disable SPL, and re-enable SPL, options above and some more options will be un-set. then cause a compile error. add minmal options needed by compile. Signed-off-by: Du Huanpeng --- arch/mips/mach-mtmips/Kconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/mips/mach-mtmips/Kconfig b/arch/mips/mach-mtmips/Kconfig index 8756cadb..d6ae3a0 100644 --- a/arch/mips/mach-mtmips/Kconfig +++ b/arch/mips/mach-mtmips/Kconfig @@ -44,8 +44,12 @@ config SOC_MT7620 select PINCTRL_MT7620 select MT7620_SERIAL select MISC + select SPL_SERIAL_SUPPORT if SPL + select SPL_LIBGENERIC_SUPPORT if SPL + select SPL_LIBCOMMON_SUPPORT if SPL select SPL_SEPARATE_BSS if SPL select SPL_LOADER_SUPPORT if SPL + imply SPL_DM if SPL select SPL_OF_CONTROL if SPL_DM select SPL_OF_PLATDATA if SPL_DM select SPL_DM_SERIAL if SPL_DM -- 2.7.4
Re: [PATCH 5/8] image: Adjust the workings of fit_check_format()
On Wed, Feb 17, 2021 at 02:30:56PM +0100, Jesper Schmitz Mouridsen wrote: > Hi > > Can you avoid the use of ENODATA since it is not defined in FreeBSD's > > errno.h? I like that FreeBSD has EDOOFUS, but I don't see an obvious replacement for ENODATA, can you suggest something please? Thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] odroid-go2: remove setting SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
Hi Tom, Am Mittwoch, 17. Februar 2021, 03:21:25 CET schrieb Tom Rini: > On Wed, Feb 17, 2021 at 02:42:21AM +0100, Heiko Stuebner wrote: > > Hi Tom, > > > > Am Dienstag, 16. Februar 2021, 15:26:52 CET schrieb Tom Rini: > > > On Sat, Feb 13, 2021 at 11:45:50PM +0100, Heiko Stuebner wrote: > > > > Hi Roger, > > > > > > > > Am Samstag, 13. Februar 2021, 16:59:01 CET schrieb Roger Pau Monne: > > > > > From: Roger Pau Monné > > > > > > > > > > Using a non-default SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR setting makes the > > > > > resulting u-boot-rockchip.bin unbootable, as it gets stuck after SPL. > > > > > Removing the setting from the defconfig allows U-Boot to load > > > > > successfully. > > > > > > > > Hmm, I'd disagree slightly. > > > > > > > > In the rockchip-common.h the CONFIG_SPL_PAD_TO is defined as > > > > > > > > /* ((CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR - 64) * 512) */ > > > > #define CONFIG_SPL_PAD_TO 8355840 > > > > > > > > so it's a static value but based on the MMCSD_RAW_MODE... config option. > > > > > > > > So instead of mandating one specific MMCSD_RAW_MODE... value > > > > that CONFIG_SPL_PAD_TO should be defined based on the the > > > > actual config value of CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR > > > > and not some static number that then gets enforced for all boards. > > > > > > So, what does CONFIG_SPL_PAD_TO actually mean, in this case? And > > > SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR ? What I'm getting at is that we > > > generally have some required to be fixed (by the SoC/ROM/etc) locations > > > some parts of our SPL/TPL/U-Boot need to be at and then the rest of the > > > values are (supposed to be) well and carefully chosen offsets and not > > > changed around. So with the above comment in the code to explain where > > > 8355840 came from, it also shouldn't and nor should > > > CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR be changed without a compelling > > > reason. > > > > Normally Rockchip platforms have two loader binaries: > > > > - idbLoader.img (tpl + spl, or only spl), loving at offset 64 of a sd-card > > This is mandated by the bootrom > > - u-boot.itb (u-boot, atf, etc) living at SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR > > As SPL will load from the location specified in the config, this location > > can be set depending on emmc/sd-card/whatever needs. > > > > It looks like recently a new binary creating method was added that creates > > a u-boot-rockchip.bin combining these somewhat automatically: > > > > idbLoader.img > > + SPL_PAD_TO > > + u-boot.itb > > > > So that only that binary needs to be flashed to the boot medium > > instead of two. > > > > So the SPL_PAD_TO essentially would mandate one specific > > SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR for every board. > > > > > > For the odroid-go2 itself it doesn't really matter I guess, but there are > > other boards with different requirements, so mandating one specific place > > for the main uboot for all boards that will ever exist seems a bit counter- > > intuitive to me. > > I would say that yes, it's quite intentional that all boards for a given > SoC (or SoC family) would use the same value for > SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR and NOT leave it up to be per-board. > It should be a matter of kilobytes being potentially wasted which is > (often or most likely) worth sacrificing in the name of consistency and > ease of future use / development. In other cases this ends up being > something around "ROM will only load something of $X size, round that up > a little bit, place U-Boot there, as it's the next thing to load". Ok ... then I'guess I'll not stand in the way ;-) . Though we're in the megabyte range with CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR being 0x4000 * 512 . But I guess with current emmc sizes that might not matter too much. But should there be some sort of warning when the CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR doesn't match the expected value? Because for example rk3399-puma and rk3368-lion historical use that 0x200 instead of 0x4000 block offset and I think at least their default firmware also expects u-boot to not reach that far into the emmc. Heiko
[PATCH] patman: Use less for help file, if available
It's convenient to be able to scroll up in `patman -H`.
Signed-off-by: Nicolas Boichat
---
tools/patman/main.py | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/patman/main.py b/tools/patman/main.py
index c4e4d80d4250..5830c5a5e24f 100755
--- a/tools/patman/main.py
+++ b/tools/patman/main.py
@@ -9,6 +9,7 @@
from argparse import ArgumentParser
import os
import re
+import shutil
import sys
import traceback
import unittest
@@ -169,6 +170,8 @@ elif args.cmd == 'send':
elif args.full_help:
pager = os.getenv('PAGER')
+if not pager:
+pager = shutil.which('less')
if not pager:
pager = 'more'
fname = os.path.join(os.path.dirname(os.path.realpath(sys.argv[0])),
--
2.30.0.478.g8a0d178c01-goog
[PATCH 1/1] test: missing dependency for test/cmd/setexpr.c
test/cmd/setexpr.c cannot be linked with CONFIG_CMD_SETEXPR=n:
ld.bfd: test/built-in.o: in function `setexpr_test_sub':
test/cmd/setexpr.c:227: undefined reference to `setexpr_regex_sub'
ld.bfd: test/built-in.o: in function `setexpr_test_backref':
test/cmd/setexpr.c:267: undefined reference to `setexpr_regex_sub'
Signed-off-by: Heinrich Schuchardt
---
test/cmd/Makefile | 2 +-
test/cmd_ut.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/test/cmd/Makefile b/test/cmd/Makefile
index 5451e9ea90..c84df60395 100644
--- a/test/cmd/Makefile
+++ b/test/cmd/Makefile
@@ -8,4 +8,4 @@ endif
obj-y += mem.o
obj-$(CONFIG_CMD_MEM_SEARCH) += mem_search.o
obj-$(CONFIG_CMD_PWM) += pwm.o
-obj-y += setexpr.o
+obj-$(CONFIG_CMD_SETEXPR) += setexpr.o
diff --git a/test/cmd_ut.c b/test/cmd_ut.c
index 90674d5de5..8f3089890e 100644
--- a/test/cmd_ut.c
+++ b/test/cmd_ut.c
@@ -75,8 +75,10 @@ static struct cmd_tbl cmd_ut_sub[] = {
U_BOOT_CMD_MKENT(log, CONFIG_SYS_MAXARGS, 1, do_ut_log, "", ""),
#endif
U_BOOT_CMD_MKENT(mem, CONFIG_SYS_MAXARGS, 1, do_ut_mem, "", ""),
+#ifdef CONFIG_CMD_SETEXPR
U_BOOT_CMD_MKENT(setexpr, CONFIG_SYS_MAXARGS, 1, do_ut_setexpr, "",
""),
+#endif
#ifdef CONFIG_UT_TIME
U_BOOT_CMD_MKENT(time, CONFIG_SYS_MAXARGS, 1, do_ut_time, "", ""),
#endif
--
2.30.0
[PATCH] bootm: do not hang on failure
On ARMv8 systems
load mmc 0:1 $loadaddr vmlinuz-5.10.0-3-arm64
booti
leads to a hanging system requiring to physically reset the system:
FDT and ATAGS support not compiled in - hanging
### ERROR ### Please RESET the board ###
For systems where physical access is difficult hanging is a poor choice.
It is preferable to reset the system when U-Boot reaches a state that is
not recoverable.
Signed-off-by: Heinrich Schuchardt
---
arch/arm/lib/bootm.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 11af9e2fb9..f60ee3a7e6 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -16,7 +16,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -249,8 +248,7 @@ static void boot_prep_linux(bootm_headers_t *images)
#ifdef CONFIG_OF_LIBFDT
debug("using: FDT\n");
if (image_setup_linux(images)) {
- printf("FDT creation failed! hanging...");
- hang();
+ panic("FDT creation failed!");
}
#endif
} else if (BOOTM_ENABLE_TAGS) {
@@ -283,8 +281,7 @@ static void boot_prep_linux(bootm_headers_t *images)
setup_board_tags(¶ms);
setup_end_tag(gd->bd);
} else {
- printf("FDT and ATAGS support not compiled in - hanging\n");
- hang();
+ panic("FDT and ATAGS support not compiled in\n");
}
board_prep_linux(images);
--
2.30.0
[PATCH 1/1] lib: rsa: struct udevice build warning
Avoid build warnings observed with gcc 10.2
In file included from lib/rsa/rsa-keyprop.c:16:
include/u-boot/rsa-mod-exp.h:65:24: warning:
‘struct udevice’ declared inside parameter list will not be visible
outside of this definition or declaration
65 | int rsa_mod_exp(struct udevice *dev, const uint8_t *sig,
| uint32_t sig_len,
|^~~
include/u-boot/rsa-mod-exp.h:96:24: warning:
‘struct udevice’ declared inside parameter list will not be visible
outside of this definition or declaration
96 | int (*mod_exp)(struct udevice *dev, const uint8_t *sig,
|
by defining struct udevice.
Fixes: 401d1c4f5d2d ("common: Drop asm/global_data.h from common header")
Signed-off-by: Heinrich Schuchardt
---
include/u-boot/rsa-mod-exp.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/u-boot/rsa-mod-exp.h b/include/u-boot/rsa-mod-exp.h
index 7b7c2915a9..fc9557c781 100644
--- a/include/u-boot/rsa-mod-exp.h
+++ b/include/u-boot/rsa-mod-exp.h
@@ -9,6 +9,8 @@
#include
#include
+struct udevice;
+
/**
* struct key_prop - holder for a public key properties
*
--
2.30.0
Re: [PATCH v2] net: tftp: Avoid sending extra ack on completion
On 03/02/21, Ramon Fried wrote:
> in tftpboot, if ack was already sent previously for this
> packet, don't send again.
>
> Fixes: cc6b87ecaa96 ("net: tftp: Add client support for RFC 7440")
>
> Reported-by: Suneel Garapati
> Signed-off-by: Ramon Fried
Tested-by: Oliver Graute
Re: [PATCH] usb: gadget: dwc2_udc_otg: Fix dwc2_gadget_start()
On 2/17/21 9:57 AM, Patrice CHOTARD wrote: Hi Marek Hi, [...] @@ -319,12 +318,11 @@ static int dwc2_gadget_start(struct usb_gadget *g, struct dwc2_udc *dev = the_controller; debug_cond(DEBUG_SETUP != 0, "%s: %s\n", __func__, "no name"); if (!driver || - (driver->speed != USB_SPEED_FULL && - driver->speed != USB_SPEED_HIGH) || + driver->speed < USB_SPEED_FULL || The DWC2 can't operate in LS gadget mode , i.e. emulate some old keyboard ? Maybe what you want is driver->speed > USB_SPEED_HIGH instead ? The test is correct, in case driver->speed is lower than FS, we return -EINVAL. All others speed FS/HS/SS and higher are allowed. What's the problem with LS ? [...]
Re: [PATCH v5] net: tftp: Add client support for RFC 7440
On 17/02/21, Oliver Graute wrote: > On 18/07/20, Ramon Fried wrote: > > Add support for RFC 7440: "TFTP Windowsize Option". > > > > This optional feature allows the client and server > > to negotiate a window size of consecutive blocks to send as an > > alternative for replacing the single-block lockstep schema. > > > > windowsize can be defined statically during compilation by > > setting CONFIG_TFTP_WINDOWSIZE, or defined in runtime by > > setting an environment variable: "tftpwindowsize" > > If not defined, the windowsize is set to 1, meaning that it > > behaves as it was never defined. > > this commit breaks my TFTP Setup. I run into lot of timeouts and most of > the times I can't load the kernel or the dtb. > > Using ethernet@5b04 device > TFTP from server 192.168.100.99; our IP address is 192.168.100.96 > Filename 'Image'. > Load address: 0x8028 > Loading: #T T T T T T T > > On bisecting between 2020.07 and 2020.10 I stumbled across this commit. > reverting it fix the issue immediately. > > Some clue why the default windowsize set 1 breaks it for me? ok found the patch that fixed the issue myself https://lists.denx.de/pipermail/u-boot/2021-February/439845.html Best regards, Oliver
Re: [PATCH 07/16] arm: Remove ot1200 board
Hi Tom Am Mi., 10. Feb. 2021 um 03:43 Uhr schrieb Tom Rini : > > This board relies on using CONFIG_LIBATA but does not enable CONFIG_AHCI. The > deadline for this conversion was the v2019.07 release. In order to > convert to using the DWC SATA driver under DM further migrations are > required. > I will drive tomorrow to the office to get my hands on the device again. On Monday I will ack this patch or will post some patches to keep the board. -- greets -- Christian Gmeiner, MSc https://christian-gmeiner.info/privacypolicy
[PATCH] test: print_ut: Fix potential build error
This files uses the macro U_BOOT_CMD which is defined in command.h, but command.h is conditionally included. Fix it. Signed-off-by: Bin Meng --- test/print_ut.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/print_ut.c b/test/print_ut.c index a456a44..61ea432 100644 --- a/test/print_ut.c +++ b/test/print_ut.c @@ -6,8 +6,8 @@ #define DEBUG #include -#if CONFIG_IS_ENABLED(EFI_LOADER) && !defined(API_BUILD) #include +#if CONFIG_IS_ENABLED(EFI_LOADER) && !defined(API_BUILD) #include #endif #include -- 2.7.4
Re: [PATCH v5] net: tftp: Add client support for RFC 7440
On 18/07/20, Ramon Fried wrote: > Add support for RFC 7440: "TFTP Windowsize Option". > > This optional feature allows the client and server > to negotiate a window size of consecutive blocks to send as an > alternative for replacing the single-block lockstep schema. > > windowsize can be defined statically during compilation by > setting CONFIG_TFTP_WINDOWSIZE, or defined in runtime by > setting an environment variable: "tftpwindowsize" > If not defined, the windowsize is set to 1, meaning that it > behaves as it was never defined. this commit breaks my TFTP Setup. I run into lot of timeouts and most of the times I can't load the kernel or the dtb. Using ethernet@5b04 device TFTP from server 192.168.100.99; our IP address is 192.168.100.96 Filename 'Image'. Load address: 0x8028 Loading: #T T T T T T T On bisecting between 2020.07 and 2020.10 I stumbled across this commit. reverting it fix the issue immediately. Some clue why the default windowsize set 1 breaks it for me? Best regards, Oliver
[PATCH v2] usb: gadget: dwc2_udc_otg: Fix dwc2_gadget_start() and usb_gadget_register_driver()
Since commit 8745b9ebccae ("usb: gadget: add super speed support")
ums was no more functional on platform which use dwc2_udc_otg driver.
This was due to a too restrictive test which checked that the gadget
driver speed was either FS or HS.
So all gadget driver with max speed set to speed higher than
HS (SS in case of composite gadget driver in our case) are not
allowed, which is wrong.
Update the speed test in usb_gadget_register_driver() and in
dwc2_gadget_start() to allow all gadget driver speed equal or higher
than FS.
Tested on stm32mp157c-ev1 board.
Fixes: c791c8431c34 ("usb: dwc2: convert driver to DM_USB_GADGET")
Signed-off-by: Patrice Chotard
---
Changes in v2:
- update gadget driver speed test in usb_gadget_register_driver()
and in dwc2_gadget_start() instead of removing it completely.
drivers/usb/gadget/dwc2_udc_otg.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/dwc2_udc_otg.c
b/drivers/usb/gadget/dwc2_udc_otg.c
index ecac80fc11..2f31814442 100644
--- a/drivers/usb/gadget/dwc2_udc_otg.c
+++ b/drivers/usb/gadget/dwc2_udc_otg.c
@@ -248,9 +248,7 @@ int usb_gadget_register_driver(struct usb_gadget_driver
*driver)
debug_cond(DEBUG_SETUP != 0, "%s: %s\n", __func__, "no name");
- if (!driver
- || (driver->speed != USB_SPEED_FULL
- && driver->speed != USB_SPEED_HIGH)
+ if (!driver || driver->speed < USB_SPEED_FULL
|| !driver->bind || !driver->disconnect || !driver->setup)
return -EINVAL;
if (!dev)
@@ -320,9 +318,7 @@ static int dwc2_gadget_start(struct usb_gadget *g,
debug_cond(DEBUG_SETUP != 0, "%s: %s\n", __func__, "no name");
- if (!driver ||
- (driver->speed != USB_SPEED_FULL &&
-driver->speed != USB_SPEED_HIGH) ||
+ if (!driver || driver->speed < USB_SPEED_FULL ||
!driver->bind || !driver->disconnect || !driver->setup)
return -EINVAL;
--
2.17.1
[PATCH] test: cmd: setexpr: Fix a typo
SETEXPR_TEST is for a new setexpr test, not mem. Signed-off-by: Bin Meng --- test/cmd/setexpr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/cmd/setexpr.c b/test/cmd/setexpr.c index fd6d869..7067e1f 100644 --- a/test/cmd/setexpr.c +++ b/test/cmd/setexpr.c @@ -15,7 +15,7 @@ #define BUF_SIZE 0x100 -/* Declare a new mem test */ +/* Declare a new setexpr test */ #define SETEXPR_TEST(_name, _flags)UNIT_TEST(_name, _flags, setexpr_test) /* Test 'setexpr' command with simply setting integers */ -- 2.7.4
Re: [PATCH] usb: gadget: dwc2_udc_otg: Fix dwc2_gadget_start()
Hi Marek
On 2/16/21 10:15 PM, Marek Vasut wrote:
> On 2/16/21 6:32 PM, Patrice CHOTARD wrote:
>> Hi Marek
>
> Hi,
>
>> On 2/11/21 12:26 PM, Marek Vasut wrote:
>>> On 2/11/21 10:58 AM, Patrice CHOTARD wrote:
Hi Marek
On 2/10/21 3:26 PM, Marek Vasut wrote:
> On 2/10/21 3:17 PM, Patrice Chotard wrote:
>> Since commit 8745b9ebccae ("usb: gadget: add super speed support")
>> ums was no more functional on platform which use dwc2_udc_otg driver.
>>
>> Remove the speed test in dwc2_gadget_start() to fix it.
>> Tested on stm32mp157c-ev1 board.
>
> Isn't the speed check correct though ?
I am not sure this speed test is needed.
>
> What is really going on when this fails ?
Since 8745b9ebccae ("usb: gadget: add super speed support"),
driver->speed is now set to USB_SPEED_SUPER in
drivers/usb/gadget/composite.c
and this forbids dwc2_udc_otg.c to be registered.
>>>
>>> That sounds like a bug in the USB gadget/otg core , no ?
>>
>> After analysis, if i correctly understood, the speed test done in both
>> usb_gadget_register_driver()
>> and in dwc2_gadget_start() in dwc2_udc_otg.c is too restrictive and accepts
>> only gadget driver with
>> max speed equal to USB_SPEED_FULL or USB_SPEED_HIGH.
>
> That should be fine for the DWC2 IP, which is LS/FS/HS.
>
>> So all gadget driver with max speed set to higher speed than USB_SPEED_HIGH
>> (USB_SPEED_SUPER in case of
>> composite gadget driver) are not allowed, which is wrong.
>>
>> This test should check that the gadget driver max speed is higher or equal
>> to the min speed supported by
>> dwc2_udc_otg driver, ie USB_SPEED_FULL.
>>
>> So the test should be :
>>
>> @@ -247,12 +247,11 @@ int usb_gadget_register_driver(struct
>> usb_gadget_driver *driver)
>> unsigned long flags = 0;
>> debug_cond(DEBUG_SETUP != 0, "%s: %s\n", __func__, "no name");
>> if (!driver
>> - || (driver->speed != USB_SPEED_FULL
>> - && driver->speed != USB_SPEED_HIGH)
>> + || driver->speed < USB_SPEED_FULL
>> || !driver->bind || !driver->disconnect || !driver->setup)
>> return -EINVAL;
>> if (!dev)
>> return -ENODEV;
>> if (dev->driver)
>> @@ -319,12 +318,11 @@ static int dwc2_gadget_start(struct usb_gadget *g,
>> struct dwc2_udc *dev = the_controller;
>> debug_cond(DEBUG_SETUP != 0, "%s: %s\n", __func__, "no name");
>> if (!driver ||
>> - (driver->speed != USB_SPEED_FULL &&
>> - driver->speed != USB_SPEED_HIGH) ||
>> + driver->speed < USB_SPEED_FULL ||
>
> The DWC2 can't operate in LS gadget mode , i.e. emulate some old keyboard ?
> Maybe what you want is driver->speed > USB_SPEED_HIGH instead ?
The test is correct, in case driver->speed is lower than FS, we return -EINVAL.
All others speed FS/HS/SS and higher are allowed.
>
>> !driver->bind || !driver->disconnect || !driver->setup)
>> return -EINVAL;
>> if (!dev)
>>
>> I you are agree, i will send a v2 with this.
>
> Yes please. But you really want to get AB/RB from Lukasz, since he does the
> gadget stuff.
Ok, i will add Lukasz for the V2 review.
Thanks
Patrice
[PATCH] arm64: zynqmp: Rename zc1275/zcu1275 to be aligned with DT name
Folder names corresponds to DT name. These boards have been renamed from
zc1275 to zcu1275 by commit shown below and this should be the part of that
commit.
Fixes: 420d44678119 ("arm64: zynqmp: Rename zc1275 to zcu1275")
Signed-off-by: Michal Simek
---
board/xilinx/zynqmp/{zynqmp-zc1275-revA => zynqmp-zcu1275-revA} | 0
.../{zynqmp-zc1275-revB => zynqmp-zcu1275-revB}/psu_init_gpl.c| 0
2 files changed, 0 insertions(+), 0 deletions(-)
rename board/xilinx/zynqmp/{zynqmp-zc1275-revA => zynqmp-zcu1275-revA} (100%)
rename board/xilinx/zynqmp/{zynqmp-zc1275-revB =>
zynqmp-zcu1275-revB}/psu_init_gpl.c (100%)
diff --git a/board/xilinx/zynqmp/zynqmp-zc1275-revA
b/board/xilinx/zynqmp/zynqmp-zcu1275-revA
similarity index 100%
rename from board/xilinx/zynqmp/zynqmp-zc1275-revA
rename to board/xilinx/zynqmp/zynqmp-zcu1275-revA
diff --git a/board/xilinx/zynqmp/zynqmp-zc1275-revB/psu_init_gpl.c
b/board/xilinx/zynqmp/zynqmp-zcu1275-revB/psu_init_gpl.c
similarity index 100%
rename from board/xilinx/zynqmp/zynqmp-zc1275-revB/psu_init_gpl.c
rename to board/xilinx/zynqmp/zynqmp-zcu1275-revB/psu_init_gpl.c
--
2.30.0
