[PATCH] rockchip: jerry: Enable RESET driver
At present the display does not work since it needs the reset driver to
operate. Fix this by enabling it.
Signed-off-by: Simon Glass
Fixes: cd529f7ad62 ("rockchip: video: edp: Add missing reset support")
Fixes: 9749d2ea29e ("rockchip: video: vop: Add reset support")
---
configs/chromebook_jerry_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/chromebook_jerry_defconfig
b/configs/chromebook_jerry_defconfig
index 35d546e6315..a60468eafa5 100644
--- a/configs/chromebook_jerry_defconfig
+++ b/configs/chromebook_jerry_defconfig
@@ -95,6 +95,7 @@ CONFIG_REGULATOR_RK8XX=y
CONFIG_PWM_ROCKCHIP=y
CONFIG_RAM=y
CONFIG_SPL_RAM=y
+CONFIG_DM_RESET=y
CONFIG_DEBUG_UART_SHIFT=2
CONFIG_ROCKCHIP_SERIAL=y
CONFIG_SOUND=y
--
2.37.3.998.g577e59143f-goog
Re: [RFC PATCH] dm: fpga: Introduce new uclass
Hi Alexander,
On Mon, 26 Sept 2022 at 14:48, Alexander Dahl wrote:
>
> For future DM based FPGA drivers and for now to have a meaningful
> logging class for old FPGA drivers.
>
> Suggested-by: Michal Simek
> Suggested-by: Simon Glass
> Signed-off-by: Alexander Dahl
> ---
> arch/sandbox/dts/test.dts | 4
> drivers/fpga/Kconfig | 14 ++
> drivers/fpga/Makefile | 3 +++
> drivers/fpga/fpga-uclass.c | 11 +++
> drivers/fpga/sandbox.c | 11 +++
> include/dm/uclass-id.h | 1 +
> test/dm/Makefile | 1 +
> test/dm/fpga.c | 20
> 8 files changed, 65 insertions(+)
> create mode 100644 drivers/fpga/fpga-uclass.c
> create mode 100644 drivers/fpga/sandbox.c
> create mode 100644 test/dm/fpga.c
Reviewed-by: Simon Glass
nits below
>
> diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> index 2761588f0d..3b9cc8cd7c 100644
> --- a/arch/sandbox/dts/test.dts
> +++ b/arch/sandbox/dts/test.dts
> @@ -650,6 +650,10 @@
> };
> };
>
> + fpga {
> + compatible = "sandbox,fpga";
> + };
> +
> pinctrl-gpio {
> compatible = "sandbox,pinctrl-gpio";
>
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index e07a9cf80e..2ad1ff60b6 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -118,4 +118,18 @@ config SPL_FPGA_LOAD_SECURE
> Enables the fpga loads() functions that are used to load secure
> (authenticated or encrypted or both) bitstreams on to FPGA.
>
> +config DM_FPGA
> + bool "Enable Driver Model for FPGA drivers"
> + depends on DM
this is the default I think so you can drop this
> + select FPGA
Normally we would have 'depends on FPGA' here. With this you will just
need to enable DM_FPGA and will get FPGA automatically. If that is
what you want, that is fine.
> + help
> + Enable driver model for FPGA.
> + For now this is uclass only without a real driver using it.
What is an FPGA? What sort of features does the uclass support (none yet).
> +
> +config SANDBOX_FPGA
> + bool "Enable sandbox FPGA driver"
> + depends on SANDBOX && DM_FPGA
> + help
> + tbd
Add help here, explaining that for now it is only a driver with no
uclass methods.
> +
> endmenu
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index 83243fb107..610c168fc3 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -4,6 +4,9 @@
> # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
>
> obj-y += fpga.o
> +obj-$(CONFIG_DM_FPGA) += fpga-uclass.o
> +obj-$(CONFIG_SANDBOX_FPGA) += sandbox.o
> +
> obj-$(CONFIG_FPGA_SPARTAN2) += spartan2.o
> obj-$(CONFIG_FPGA_SPARTAN3) += spartan3.o
> obj-$(CONFIG_FPGA_VERSALPL) += versalpl.o
> diff --git a/drivers/fpga/fpga-uclass.c b/drivers/fpga/fpga-uclass.c
> new file mode 100644
> index 00..4278ec28e5
> --- /dev/null
> +++ b/drivers/fpga/fpga-uclass.c
> @@ -0,0 +1,11 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2022 Alexander Dahl
> + */
> +
> +#include
> +
> +UCLASS_DRIVER(fpga) = {
> + .name = "fpga",
> + .id = UCLASS_FPGA,
> +};
> diff --git a/drivers/fpga/sandbox.c b/drivers/fpga/sandbox.c
> new file mode 100644
> index 00..5687efccb1
> --- /dev/null
> +++ b/drivers/fpga/sandbox.c
> @@ -0,0 +1,11 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2022 Alexander Dahl
> + */
> +
> +#include
> +
> +U_BOOT_DRIVER(sandbox_fpga) = {
> + .name = "sandbox_fpga",
> + .id = UCLASS_FPGA,
> +};
> diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
> index a432e43871..c2b15881ba 100644
> --- a/include/dm/uclass-id.h
> +++ b/include/dm/uclass-id.h
> @@ -56,6 +56,7 @@ enum uclass_id {
> UCLASS_ETH, /* Ethernet device */
> UCLASS_ETH_PHY, /* Ethernet PHY device */
> UCLASS_FIRMWARE,/* Firmware */
> + UCLASS_FPGA,/* FPGA device */
> UCLASS_FUZZING_ENGINE, /* Fuzzing engine */
> UCLASS_FS_FIRMWARE_LOADER, /* Generic loader */
> UCLASS_GPIO,/* Bank of general-purpose I/O pins */
> diff --git a/test/dm/Makefile b/test/dm/Makefile
> index 7543df8823..666c85f10a 100644
> --- a/test/dm/Makefile
> +++ b/test/dm/Makefile
> @@ -47,6 +47,7 @@ ifneq ($(CONFIG_EFI_PARTITION),)
> obj-$(CONFIG_FASTBOOT_FLASH_MMC) += fastboot.o
> endif
> obj-$(CONFIG_FIRMWARE) += firmware.o
> +obj-$(CONFIG_DM_FPGA) += fpga.o
> obj-$(CONFIG_DM_HWSPINLOCK) += hwspinlock.o
> obj-$(CONFIG_DM_I2C) += i2c.o
> obj-$(CONFIG_SOUND) += i2s.o
> diff --git a/test/dm/fpga.c b/test/dm/fpga.c
> new file mode 100644
> index 00..8d29c8f159
> --- /dev/null
> +++ b/test/dm/fpga.c
> @@ -0,0 +1,20 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2022 Alexander Dahl
> + */
> +
> +#include
> +#include
Re: [PATCH 0/2] efi_loader: provide media ID
Hi, On Tue, 27 Sept 2022 at 00:53, Heinrich Schuchardt wrote: > > > > On 9/27/22 03:51, AKASHI Takahiro wrote: > > On Mon, Sep 26, 2022 at 08:06:52AM +0200, Heinrich Schuchardt wrote: > >> > >> > >> On 9/16/22 02:58, AKASHI Takahiro wrote: > >>> On Thu, Sep 15, 2022 at 10:02:40PM +0200, Heinrich Schuchardt wrote: > The medium a device like 'mmc 0' or 'usb 0' points to may change over > time. Hence device type and number are not sufficient to identify the > inserted medium. The same is true for the device path generated for > such a device. > >>> > >>> Well, it depends on how a device path is generated in U-Boot's UEFI > >>> implementation. I believe that a device path represents an "unique path" > >>> to a given device however this device is enumerated. > >>> In this sense, the current dp_fill()/efi_dp_from_part() is not a right > >>> implementation as it relies on device numbers. > >>> Furthermore, a generated device path here is different from one generated > >>> by EDK2 (even if both software are run on the same board). > >>> > >>> This is an issue that I used to tackle in > >>> https://lists.denx.de/pipermail/u-boot/2021-November/468216.html > >>> although I have since had no progress. > >>> > This is why the EFI_BLOCK_IO_PROTOCOL provides a field > MediaId. > > Whenever a removable medium is changed or a new block device with a > previously used device path is created we should provide a different > MediaID. > > This series adds a field media_id to the block device descriptor and > fills > it after probing. The value of the field is then copied to the > EFI_BLOCK_IO_PROTOCOL. > >>> > >>> I'm afraid that your patch doesn't always work as you expect. > >>> When "scsi rescan" or "usb stop; usb start", for instance, is invoked, > >>> all the existing devices and associated blk_desc structures are once freed > >>> and even if nothing is changed, i.e. a device is neither removed nor > >>> added, > >>> the exact same structures will be re-created. > >>> With your patch applied, however, a new (and different) "media_id" will be > >>> assigned to an existing device. UEFI User may be notified of "media > >>> change". > >>> (To be honest, this is quite unlikely because the current UEFI > >>> implementation > >>> doesn't use BLOCK_IO_PROTOCOL internally, say, for file system access.) > >> > >> This behavior matches what EDK II does if you remove a device and create a > >> new device. > > > > I don't think that EDK2 has "scsi rescan" or others, which users can invoke > > at any time. Moreover, I believe that EDK2 code (drivers) checks whether a > > device > > is really changed or not before updating a MediaId. > > > >> If a device is removed and recreated anything could have happened in > >> between > >> like complete repartitioning. We cannot assume that any cached state is > >> valid anymore even if GUIDs are the same. > > > > I'm not sure if you fully understand my point. > > My assumption is the case where a device is NOT removed around "scsi rescan" > > (or usb stop/start) and stays online. In this case, > > 1. access to, say, "scsi 0:1", via UEFI BLOCK_IO succeeds > > 2. "scsi rescan" > > 3. access to the same device, "scsi 0:1", via UEFI BLOCK_IO > > currently (3) succeeds, but with your patch, it may potentially fail because > > of media_id altered. > > > > I admit that it will not happen under the current UEFI implementation > > because > > non of UEFI applications will survive across command lines and none of > > information, > > including media_id or handle, can be carried over from (1) to (3). > > But unconditionally incrementing an internally-held media_id, as in your > > patch, > > is a wrong behavior. > > The patch issues a new media ID if a new device is probed which only > happens to have the same device number if another device of that number > was removed before. > > Commands like 'usb scan' don't necessarily issue the same numbers to the > same device as before the command if a new device has been attached in > the meanwhile. > > Assuming that a new device contains the same medium as an old one > because by chance it has the same device number is definitively unsafe. > > If a device is probed, we have to assume that it contains a new medium. Sorry if I repeat myself, but this sort of thing should be handled in the driver model code. Can we get some more progress on integrating the EFI layer better? Regards, Simon
Re: [PATCH] fdt_support: cosmetic: remove fdt_fixup_nor_flash_size prototype
On Tue, 27 Sept 2022 at 02:18, Patrick Delaunay
wrote:
>
> Remove prototype for the removed function fdt_fixup_nor_flash_size.
> This patch has no impact as the function is never used.
>
> Fixes: 98f705c9cefd ("powerpc: remove 4xx support")
> Signed-off-by: Patrick Delaunay
> ---
>
> include/fdt_support.h | 2 --
> 1 file changed, 2 deletions(-)
Reviewed-by: Simon Glass
Re: [PATCH v2 1/8] dm: fpga: Introduce new uclass
Hi Alex,
On Mon, 26 Sept 2022 at 00:14, Alexander Dahl wrote:
>
> Hello Simon,
>
> Am Sun, Sep 25, 2022 at 08:15:38AM -0600 schrieb Simon Glass:
> > Hi Michal,
> >
> > On Thu, 22 Sept 2022 at 05:45, Michal Simek wrote:
> > >
> > >
> > >
> > > On 9/22/22 13:35, Simon Glass wrote:
> > > > Hi,
> > > >
> > > > On Thu, 22 Sept 2022 at 12:27, Michal Simek
> > > > wrote:
> > > >>
> > > >>
> > > >>
> > > >> On 9/21/22 15:22, Alexander Dahl wrote:
> > > >>> For future DM based FPGA drivers and for now to have a meaningful
> > > >>> logging class for old FPGA drivers.
> > > >>>
> > > >>> Suggested-by: Michal Simek
> > > >>> Signed-off-by: Alexander Dahl
> > > >>> ---
> > > >>>include/dm/uclass-id.h | 1 +
> > > >>>1 file changed, 1 insertion(+)
> > > >>>
> > > >>> diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
> > > >>> index a432e43871..c2b15881ba 100644
> > > >>> --- a/include/dm/uclass-id.h
> > > >>> +++ b/include/dm/uclass-id.h
> > > >>> @@ -56,6 +56,7 @@ enum uclass_id {
> > > >>>UCLASS_ETH, /* Ethernet device */
> > > >>>UCLASS_ETH_PHY, /* Ethernet PHY device */
> > > >>>UCLASS_FIRMWARE,/* Firmware */
> > > >>> + UCLASS_FPGA,/* FPGA device */
> > > >>>UCLASS_FUZZING_ENGINE, /* Fuzzing engine */
> > > >>>UCLASS_FS_FIRMWARE_LOADER, /* Generic loader */
> > > >>>UCLASS_GPIO,/* Bank of general-purpose I/O pins */
> > > >>
> > > >> Simon: the whole series look good to me. I am happy to take it via my
> > > >> tree when
> > > >> you ACK it. Also no problem if you want to take it via your tree.
> > > >> Please let me know which way you want to go.
> > > >
> > > > This is a good step forward but needs a lot more work.
> > > >
> > > > Please add a uclass file for the FPGA - i.e.
> > > > drivers/fpga/fpga-uclass.c - see other such files for examples.
> > > >
> > > > The FPGA uclass should have methods that match the non-DM interface.
> > > > You will likely need a DM_FPGA config to allow enabling the uclass.
> > > >
> > > > Also this needs a simple sandbox driver/emulator pair, so that it can
> > > > be tested, with tests in test/dm/fpga.c that use the driver.
> > > >
> > > > Admittedly this should have been done ages ago. I vaguely remember
> > > > mentioning it at the time, but perhaps I missed it. In any case, all
> > > > uclasses must have an API, implementation and tests that run in CI
> > > > with sandbox. Testing is a vital part of U-Boot and lack of testing is
> > > > the main reason why we went back to the 3-month release cycle.
> > >
> > > It can be done in steps for sure. Issues which Alex is addressing are
> > > there for
> > > quite some time and I think we shouldn't gate them by adding requirement
> > > to
> > > create the whole fpga uclass. It can be done on the top of this series.
> > > We know that it has to happen but I wouldn't push Alex to do it as
> > > condition for
> > > applying this series.
> > > From my perspective if he has time to do, let's start with it. If not it
> > > can be
> > > done later.
> >
> > Well if this is a start, then let's make it a real start. At minimum:
> >
> > - add a uclass file with the uclass driver
> > - we can skip having any methods for now
> > - add a sandbox driver which does nothing
> > - add a test which probes the sandbox device
> >
> > That is about 50 lines of code and people can then add to it over time.
>
> FWIW, I already did that on the weekend, I just have to look over
> it again and maybe give it some polishing before sending. Draft ist
> here:
>
> https://github.com/LeSpocky/u-boot/commit/49efd2a2d0129b977d38340c8361f080043b
>
> > Without that, I'd rather not have the UCLASS_FPGA.
>
> That's okay I guess. Will just take me some time, it's not that easy
> if you have to learn about DM and UT first, and try it in the end of
> the day. ;-)
Yes, check the docs on testing.
What you have looks OK, just needs a uclass_first_device(UCLASS_FPGA,
..) in the test to make sure it can probe the device.
Regards,
Simon
Re: [PATCH 07/10] board_f/r: Allow selection of CONFIG_TIMER_EARLY w/o CONFIG_TIMER
Hi Stefan, On Mon, 26 Sept 2022 at 07:52, Stefan Roese wrote: > > Hi Simon, > > On 25.09.22 16:15, Simon Glass wrote: > > Hi Stefan, > > > > On Wed, 21 Sept 2022 at 08:06, Stefan Roese wrote: > >> > >> The early timer functions provided via CONFIG_TIMER_EARLY don't need > >> CONFIG_TIMER to be enabled, as they don't make use of the DM timer > >> and uclass interface. This patch now allow the selection of > >> CONFIG_TIMER_EARLY w/o CONFIG_TIMER, enabling this early timer > >> functionality also for non CONFIG_TIMER drivers. > >> > >> With this change it's necessary to guard the dm_timer_init() call > >> in initr_dm_devices() & initf_dm() additionally via CONFIG_TIMER. > >> > >> Signed-off-by: Stefan Roese > >> --- > >> common/board_f.c | 2 +- > >> common/board_r.c | 2 +- > >> drivers/timer/Kconfig | 1 - > >> 3 files changed, 2 insertions(+), 3 deletions(-) > > > > I don't like this as it complicates the logic and also seems to be > > adding a new feature to legacy code. > > > > Instead, let's enable the early timer only for driver model. > > Hmmm, not sure how this should work. Do you have this in mind (instead > of this patch)? > > diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig > index fd8745ffc2e0..30d6efe98f29 100644 > --- a/drivers/timer/Kconfig > +++ b/drivers/timer/Kconfig > @@ -39,7 +39,7 @@ config VPL_TIMER > > config TIMER_EARLY > bool "Allow timer to be used early in U-Boot" > - depends on TIMER > + depends on DM > # initr_bootstage() requires a timer and is called before > initr_dm() > # so only the early timer is available > default y if X86 && BOOTSTAGE > > This results in some compilation errors, like this: > > $ make stm32mp15_basic_defconfig > $ make -sj > /opt/kernel.org/gcc-11.1.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi-ld.bfd: > common/board_f.o: in function `initf_dm': > /home/stefan/git/u-boot/u-boot-marvell/common/board_f.c:791: undefined > reference to `dm_timer_init' > /opt/kernel.org/gcc-11.1.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi-ld.bfd: > common/board_r.o: in function `initr_dm_devices': > /home/stefan/git/u-boot/u-boot-marvell/common/board_r.c:258: undefined > reference to `dm_timer_init' > make: *** [Makefile:1790: u-boot] Error 1 > > I might be missing something. Or it's not that easy and we still need > my original implementation. Well, given that TIMER depends on DM, I don't think you need to change that. Also, TIMER_EARLY depends on TIMER (as it should), you should just be able to check for IS_ENABLED(CONFIG_TIMER) We can disable the early timer stuff for things that don't use CONFIG_TIMER Regards, Simon
Re: [PATCH 04/10] timer: cadence-ttc: Add timer_early functions
On Mon, 26 Sept 2022 at 08:11, Stefan Roese wrote:
>
> Hi Simon,
> Hi Michal,
>
> On 25.09.22 16:15, Simon Glass wrote:
> > Hi Stefan,
> >
> > On Wed, 21 Sept 2022 at 08:06, Stefan Roese wrote:
> >>
> >> Currently this timer driver provides timer_get_boot_us() to support the
> >> BOOTSTAGE functionality. This patch adds the timer_early functions so
> >> that the "normal" timer functions can be used, when CONFIG_TIMER_EARLY
> >> is enabled.
> >>
> >> timer_get_boot_us() will get removed in a follow-up patch, once the
> >> BOOTSTAGE interface is migrated to timer_get_us().
> >>
> >> Signed-off-by: Stefan Roese
> >> Cc: Michal Simek
> >> ---
> >> drivers/timer/cadence-ttc.c | 25 +
> >> 1 file changed, 25 insertions(+)
> >>
> >> diff --git a/drivers/timer/cadence-ttc.c b/drivers/timer/cadence-ttc.c
> >> index 2eff45060ad6..e26c7923a140 100644
> >> --- a/drivers/timer/cadence-ttc.c
> >> +++ b/drivers/timer/cadence-ttc.c
> >> @@ -58,6 +58,31 @@ ulong timer_get_boot_us(void)
> >> }
> >> #endif
> >>
> >> +unsigned long notrace timer_early_get_rate(void)
> >> +{
> >> + return 1;
> >> +}
> >> +
> >> +u64 notrace timer_early_get_count(void)
> >> +{
> >> + u64 ticks = 0;
> >> + u32 rate = 1;
> >> + u64 us;
> >> + int ret;
> >> +
> >> + ret = dm_timer_init();
> >
> > I don't think you can call this if you want to support bootstage,
> > since driver model may not be inited.
>
> Yes, thanks for noticing. Still, this code is copied from the original
> timer_get_boot_us() function in this driver. Which also has problems
> with early timer access AFAICT.
Yes, good point.
Reviewed-by: Simon Glass
>
> Michal, you are the author of the timer_get_boot_us() implementation
> in commit 56c0e646c4f6a ("timer: cadence: Implement timer_get_boot_us").
> How is this supposed to work in the early boot phase, before DM is
> initialized?
>
> Thanks,
> Stefan
>
> >> + if (!ret) {
> >> + /* The timer is available */
> >> + rate = timer_get_rate(gd->timer);
> >> + timer_get_count(gd->timer, );
> >> + } else {
> >> + return 0;
> >> + }
> >> +
> >> + us = (ticks * 1000) / rate;
> >> + return us;
> >> +}
> >> +
> >> static u64 cadence_ttc_get_count(struct udevice *dev)
> >> {
> >> struct cadence_ttc_priv *priv = dev_get_priv(dev);
> >> --
> >> 2.37.3
> >>
> >
> > REgards,
> > Simon
Regards,
Simon
[PATCH v5 15/15] dm: core: Do not stop uclass iteration on error
When probing a device fails NULL pointer is returned, and following
devices in uclass list cannot be iterated. Skip to next device on error
instead.
With that the only condition under which these simple iteration
functions return error is when the dm is not initialized at uclass_get
time. This is not all that interesting, change return type to void.
Fixes: 6494d708bf ("dm: Add base driver model support")
Signed-off-by: Michal Suchanek
---
v2: - Fix up tests
v3: - Fix up API doc
- Correctly forward error from uclass_get
- Do not return an error when last device fails to probe
- Drop redundant initialization
- Wrap at 80 columns
v4: - change return value to void
- further simplify iteration
---
drivers/core/uclass.c | 30 ++
include/dm/uclass.h | 13 ++---
test/dm/core.c| 10 --
test/dm/test-fdt.c| 27 ---
4 files changed, 48 insertions(+), 32 deletions(-)
diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
index b7d11bdd23..6dec6a3973 100644
--- a/drivers/core/uclass.c
+++ b/drivers/core/uclass.c
@@ -574,28 +574,34 @@ int uclass_get_device_by_phandle(enum uclass_id id,
struct udevice *parent,
}
#endif
-int uclass_first_device(enum uclass_id id, struct udevice **devp)
+/*
+ * Starting from the given device return first device in the uclass that
+ * probes successfully.
+ */
+static void _uclass_next_device(struct udevice *dev, struct udevice **devp)
+{
+ for (; dev; uclass_find_next_device()) {
+ if (!device_probe(dev))
+ break;
+ }
+ *devp = dev;
+}
+
+void uclass_first_device(enum uclass_id id, struct udevice **devp)
{
struct udevice *dev;
int ret;
- *devp = NULL;
ret = uclass_find_first_device(id, );
- if (!dev)
- return 0;
- return uclass_get_device_tail(dev, ret, devp);
+ _uclass_next_device(dev, devp);
}
-int uclass_next_device(struct udevice **devp)
+void uclass_next_device(struct udevice **devp)
{
struct udevice *dev = *devp;
- int ret;
- *devp = NULL;
- ret = uclass_find_next_device();
- if (!dev)
- return 0;
- return uclass_get_device_tail(dev, ret, devp);
+ uclass_find_next_device();
+ _uclass_next_device(dev, devp);
}
int uclass_first_device_err(enum uclass_id id, struct udevice **devp)
diff --git a/include/dm/uclass.h b/include/dm/uclass.h
index b1c016ef9f..ee15c92063 100644
--- a/include/dm/uclass.h
+++ b/include/dm/uclass.h
@@ -320,32 +320,31 @@ int uclass_get_device_by_driver(enum uclass_id id, const
struct driver *drv,
* uclass_first_device() - Get the first device in a uclass
*
* The device returned is probed if necessary, and ready for use
+ * Devices that fail to probe are skipped
*
* This function is useful to start iterating through a list of devices which
* are functioning correctly and can be probed.
*
* @id: Uclass ID to look up
* @devp: Returns pointer to the first device in that uclass if no error
- * occurred, or NULL if there is no first device, or an error occurred with
- * that device.
- * Return: 0 if OK (found or not found), other -ve on error
+ * occurred, or NULL if there is no usable device
*/
-int uclass_first_device(enum uclass_id id, struct udevice **devp);
+void uclass_first_device(enum uclass_id id, struct udevice **devp);
/**
* uclass_next_device() - Get the next device in a uclass
*
* The device returned is probed if necessary, and ready for use
+ * Devices that fail to probe are skipped
*
* This function is useful to iterate through a list of devices which
* are functioning correctly and can be probed.
*
* @devp: On entry, pointer to device to lookup. On exit, returns pointer
* to the next device in the uclass if no error occurred, or NULL if there is
- * no next device, or an error occurred with that next device.
- * Return: 0 if OK (found or not found), other -ve on error
+ * no next device
*/
-int uclass_next_device(struct udevice **devp);
+void uclass_next_device(struct udevice **devp);
/**
* uclass_first_device_err() - Get the first device in a uclass
diff --git a/test/dm/core.c b/test/dm/core.c
index 84eb76ed5f..7f3f8d183b 100644
--- a/test/dm/core.c
+++ b/test/dm/core.c
@@ -1078,11 +1078,10 @@ static int dm_test_uclass_devices_get(struct
unit_test_state *uts)
struct udevice *dev;
int ret;
- for (ret = uclass_first_device(UCLASS_TEST, );
+ for (ret = uclass_first_device_check(UCLASS_TEST, );
dev;
-ret = uclass_next_device()) {
+ret = uclass_next_device_check()) {
ut_assert(!ret);
- ut_assert(dev);
ut_assert(device_active(dev));
}
@@ -1112,11 +,10 @@ static int dm_test_uclass_devices_get_by_name(struct
unit_test_state *uts)
* this will fail on checking condition:
[PATCH v5 13/15] dm: core: Switch uclass_*_device_err to use uclass_*_device_check
The _err variant iterators use the simple iterators without suffix as
basis.
However, there is no user that uclass_next_device_err for iteration,
many users of uclass_first_device_err use it to get the first and
(assumed) only device of an uclass, and a couple that use
uclass_next_device_err to get the device following a known device in the
uclass list.
While there are some truly singleton device classes in which more than
one device cannot exist these are quite rare, and most classes can have
multiple devices even if it is not the case on the SoC's EVB.
In a later patch the simple iterators will be updated to not stop on
error and return next device instead. With this in many cases the code
that expects the first device or an error if it fails to probe may get
the next device instead. Use the _check iterators as the basis of _err
iterators to preserve the old behavior.
This is problematic for eth_get_dev: it relies on the broken behavior
that returns an error but not the device on which the error happened
which gives the caller no reasonable way to report or handle the error.
With this change the device is returned but eth_get_dev stores the
returned device pointer directly in a global state without checking the
return value. Unset the pointer again in the error case.
Do the same for sysinfo_get because it is not clear how exactly the
sysinfo is used by some callers, and fix up a call to pci_get_bus that
checks the returned device and not the return value.
Switch uclass_foreach_dev_probe to the simple iterator - it does not
use the returned value, and did not give out the failing devices
previously.
Note in documentation that a non-activated device can be returned on
error.
Signed-off-by: Michal Suchanek
---
v5: - udate documentation
- fix up a few more cases where device returned on error may cause
problem
---
drivers/core/uclass.c| 28 -
drivers/pci/pci-uclass.c | 7 +++
drivers/sysinfo/sysinfo-uclass.c | 10 -
include/dm/uclass.h | 36 ++--
net/eth-uclass.c | 2 ++
5 files changed, 48 insertions(+), 35 deletions(-)
diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
index a591e22403..b7d11bdd23 100644
--- a/drivers/core/uclass.c
+++ b/drivers/core/uclass.c
@@ -586,19 +586,6 @@ int uclass_first_device(enum uclass_id id, struct udevice
**devp)
return uclass_get_device_tail(dev, ret, devp);
}
-int uclass_first_device_err(enum uclass_id id, struct udevice **devp)
-{
- int ret;
-
- ret = uclass_first_device(id, devp);
- if (ret)
- return ret;
- else if (!*devp)
- return -ENODEV;
-
- return 0;
-}
-
int uclass_next_device(struct udevice **devp)
{
struct udevice *dev = *devp;
@@ -611,11 +598,24 @@ int uclass_next_device(struct udevice **devp)
return uclass_get_device_tail(dev, ret, devp);
}
+int uclass_first_device_err(enum uclass_id id, struct udevice **devp)
+{
+ int ret;
+
+ ret = uclass_first_device_check(id, devp);
+ if (ret)
+ return ret;
+ else if (!*devp)
+ return -ENODEV;
+
+ return 0;
+}
+
int uclass_next_device_err(struct udevice **devp)
{
int ret;
- ret = uclass_next_device(devp);
+ ret = uclass_next_device_check(devp);
if (ret)
return ret;
else if (!*devp)
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 00e3828d95..2aa1043604 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -1768,10 +1768,9 @@ int pci_sriov_init(struct udevice *pdev, int vf_en)
bdf = dm_pci_get_bdf(pdev);
- pci_get_bus(PCI_BUS(bdf), );
-
- if (!bus)
- return -ENODEV;
+ ret = pci_get_bus(PCI_BUS(bdf), );
+ if (ret)
+ return ret;
bdf += PCI_BDF(0, 0, vf_offset);
diff --git a/drivers/sysinfo/sysinfo-uclass.c b/drivers/sysinfo/sysinfo-uclass.c
index c5cc3cb959..10194d0e14 100644
--- a/drivers/sysinfo/sysinfo-uclass.c
+++ b/drivers/sysinfo/sysinfo-uclass.c
@@ -16,7 +16,15 @@ struct sysinfo_priv {
int sysinfo_get(struct udevice **devp)
{
- return uclass_first_device_err(UCLASS_SYSINFO, devp);
+ int ret = uclass_first_device_err(UCLASS_SYSINFO, devp);
+
+ /*
+* There is some very dodgy error handling in gazerbeam,
+* do not return a device on error.
+*/
+ if (ret)
+ *devp = NULL;
+ return ret;
}
int sysinfo_detect(struct udevice *dev)
diff --git a/include/dm/uclass.h b/include/dm/uclass.h
index f6c0110b06..b1c016ef9f 100644
--- a/include/dm/uclass.h
+++ b/include/dm/uclass.h
@@ -332,17 +332,6 @@ int uclass_get_device_by_driver(enum uclass_id id, const
struct driver *drv,
*/
int uclass_first_device(enum uclass_id id, struct udevice **devp);
-/**
- * uclass_first_device_err() - Get the first
[PATCH v5 08/15] w1: Fix bus counting in w1_get_bus
Use uclass_first_device_check/uclass_next_device_check to correctly
count buses that fail to probe.
Fixes: d3e19cf919 ("w1: Add 1-Wire uclass")
Signed-off-by: Michal Suchanek
---
drivers/w1/w1-uclass.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/w1/w1-uclass.c b/drivers/w1/w1-uclass.c
index 52b519c21d..de4f25bcf9 100644
--- a/drivers/w1/w1-uclass.c
+++ b/drivers/w1/w1-uclass.c
@@ -16,6 +16,7 @@
#include
#include
+#include
#include
#include
#include
@@ -182,24 +183,25 @@ static int w1_enumerate(struct udevice *bus)
int w1_get_bus(int busnum, struct udevice **busp)
{
int ret, i = 0;
-
struct udevice *dev;
- for (ret = uclass_first_device(UCLASS_W1, );
-dev && !ret;
-ret = uclass_next_device(), i++) {
+ for (ret = uclass_first_device_check(UCLASS_W1, );
+ dev;
+ ret = uclass_next_device_check(), i++) {
if (i == busnum) {
+ if (ret) {
+ debug("Cannot probe w1 bus %d: %d (%s)\n",
+ busnum, ret, errno_str(ret));
+ return ret;
+ }
*busp = dev;
return 0;
}
}
- if (!ret) {
- debug("Cannot find w1 bus %d\n", busnum);
- ret = -ENODEV;
- }
+ debug("Cannot find w1 bus %d\n", busnum);
- return ret;
+ return -ENODEV;
}
u8 w1_get_device_family(struct udevice *dev)
--
2.37.3
[PATCH v5 14/15] dm: treewide: Do not use the return value of simple uclass iterator
uclass_first_device/uclass_next_device return value will be removed,
don't use it.
With the current implementation bus is equivalent to !ret. It i
redundant to check both, ret check can be replaced with bus check, and
ret check inside the iteration is dead code.
Signed-off-by: Michal Suchanek
---
v5: - consolidate multiple similar patches
---
cmd/virtio.c | 9 +++--
drivers/dma/dma-uclass.c | 7 +++
drivers/gpio/gpio-uclass.c | 14 ++
drivers/w1/w1-uclass.c | 9 ++---
4 files changed, 14 insertions(+), 25 deletions(-)
diff --git a/cmd/virtio.c b/cmd/virtio.c
index ea3ed2e631..f7a2ef4313 100644
--- a/cmd/virtio.c
+++ b/cmd/virtio.c
@@ -23,18 +23,15 @@ static int do_virtio(struct cmd_tbl *cmdtp, int flag, int
argc,
* device_probe() for children (i.e. virtio devices)
*/
struct udevice *bus, *child;
- int ret;
- ret = uclass_first_device(UCLASS_VIRTIO, );
- if (ret)
+ uclass_first_device(UCLASS_VIRTIO, );
+ if (!bus)
return CMD_RET_FAILURE;
while (bus) {
device_foreach_child_probe(child, bus)
;
- ret = uclass_next_device();
- if (ret)
- break;
+ uclass_next_device();
}
return CMD_RET_SUCCESS;
diff --git a/drivers/dma/dma-uclass.c b/drivers/dma/dma-uclass.c
index 012609bb53..952cbc2170 100644
--- a/drivers/dma/dma-uclass.c
+++ b/drivers/dma/dma-uclass.c
@@ -209,10 +209,9 @@ int dma_get_cfg(struct dma *dma, u32 cfg_id, void
**cfg_data)
int dma_get_device(u32 transfer_type, struct udevice **devp)
{
struct udevice *dev;
- int ret;
- for (ret = uclass_first_device(UCLASS_DMA, ); dev && !ret;
-ret = uclass_next_device()) {
+ for (uclass_first_device(UCLASS_DMA, ); dev;
+uclass_next_device()) {
struct dma_dev_priv *uc_priv;
uc_priv = dev_get_uclass_priv(dev);
@@ -228,7 +227,7 @@ int dma_get_device(u32 transfer_type, struct udevice **devp)
*devp = dev;
- return ret;
+ return 0;
}
int dma_memcpy(void *dst, void *src, size_t len)
diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index 0ed32b7217..3a35f1e30a 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -59,11 +59,10 @@ static int gpio_to_device(unsigned int gpio, struct
gpio_desc *desc)
{
struct gpio_dev_priv *uc_priv;
struct udevice *dev;
- int ret;
- for (ret = uclass_first_device(UCLASS_GPIO, );
+ for (uclass_first_device(UCLASS_GPIO, );
dev;
-ret = uclass_next_device()) {
+uclass_next_device()) {
uc_priv = dev_get_uclass_priv(dev);
if (gpio >= uc_priv->gpio_base &&
gpio < uc_priv->gpio_base + uc_priv->gpio_count) {
@@ -73,7 +72,7 @@ static int gpio_to_device(unsigned int gpio, struct gpio_desc
*desc)
}
/* No such GPIO */
- return ret ? ret : -ENOENT;
+ return -ENOENT;
}
#if CONFIG_IS_ENABLED(DM_GPIO_LOOKUP_LABEL)
@@ -121,12 +120,11 @@ int dm_gpio_lookup_name(const char *name, struct
gpio_desc *desc)
struct udevice *dev;
ulong offset;
int numeric;
- int ret;
numeric = isdigit(*name) ? dectoul(name, NULL) : -1;
- for (ret = uclass_first_device(UCLASS_GPIO, );
+ for (uclass_first_device(UCLASS_GPIO, );
dev;
-ret = uclass_next_device()) {
+uclass_next_device()) {
int len;
uc_priv = dev_get_uclass_priv(dev);
@@ -154,7 +152,7 @@ int dm_gpio_lookup_name(const char *name, struct gpio_desc
*desc)
}
if (!dev)
- return ret ? ret : -EINVAL;
+ return -EINVAL;
gpio_desc_init(desc, dev, offset);
diff --git a/drivers/w1/w1-uclass.c b/drivers/w1/w1-uclass.c
index de4f25bcf9..a4247ecd62 100644
--- a/drivers/w1/w1-uclass.c
+++ b/drivers/w1/w1-uclass.c
@@ -36,15 +36,10 @@ int w1_bus_find_dev(const struct udevice *bus, u64 id,
struct udevice
{
struct udevice *dev;
u8 family = id & 0xff;
- int ret;
- for (ret = uclass_first_device(UCLASS_W1_EEPROM, );
- !ret && dev;
+ for (uclass_first_device(UCLASS_W1_EEPROM, );
+ dev;
uclass_next_device()) {
- if (ret || !dev) {
- debug("cannot find w1 eeprom dev\n");
- return -ENODEV;
- }
if (dev_get_driver_data(dev) == family) {
*devp = dev;
--
2.37.3
[PATCH v5 12/15] dm: blk: Do not use uclass_next_device_err
blk_first_device_err/blk_next_device_err uses
uclass_first_device_err/uclass_next_device_err for device iteration.
Although the function names superficially match the return value from
uclass_first_device_err/uclass_next_device_err is never used
meaningfully, and uclass_first_device/uclass_next_device works equally
well for this purpose.
In the following patch the semantic of
uclass_first_device_err/uclass_next_device_err will be changed to be
based on uclass_first_device_check/uclass_next_device_check breaking
this sole user that uses uclass_next_device_err for iteration.
Signed-off-by: Michal Suchanek
---
drivers/block/blk-uclass.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
index 21c5209bb6..676f2444bf 100644
--- a/drivers/block/blk-uclass.c
+++ b/drivers/block/blk-uclass.c
@@ -585,11 +585,9 @@ int blk_find_next(enum blk_flag_t flags, struct udevice
**devp)
int blk_first_device_err(enum blk_flag_t flags, struct udevice **devp)
{
- int ret;
-
- for (ret = uclass_first_device_err(UCLASS_BLK, devp);
-!ret;
-ret = uclass_next_device_err(devp)) {
+ for (uclass_first_device(UCLASS_BLK, devp);
+*devp;
+uclass_next_device(devp)) {
if (!blk_flags_check(*devp, flags))
return 0;
}
@@ -599,11 +597,9 @@ int blk_first_device_err(enum blk_flag_t flags, struct
udevice **devp)
int blk_next_device_err(enum blk_flag_t flags, struct udevice **devp)
{
- int ret;
-
- for (ret = uclass_next_device_err(devp);
-!ret;
-ret = uclass_next_device_err(devp)) {
+ for (uclass_next_device(devp);
+*devp;
+uclass_next_device(devp)) {
if (!blk_flags_check(*devp, flags))
return 0;
}
--
2.37.3
[PATCH v5 10/15] dm: treewide: Use uclass_first_device_err when accessing one device
There is a number of users that use uclass_first_device to access the
first and (assumed) only device in uclass.
Some check the return value of uclass_first_device and also that a
device was returned which is exactly what uclass_first_device_err does.
Some are not checking that a device was returned and can potentially
crash if no device exists in the uclass. Finally there is one that
returns NULL on error either way.
Convert all of these to use uclass_first_device_err instead, the return
value will be removed from uclass_first_device in a later patch.
Also print the symbolic error when the return value is printed.
Signed-off-by: Michal Suchanek
---
arch/arm/mach-omap2/am33xx/board.c| 4 ++--
arch/x86/cpu/broadwell/cpu.c | 4 +---
arch/x86/cpu/intel_common/cpu.c | 4 +---
arch/x86/lib/pinctrl_ich6.c | 4 +---
board/intel/cougarcanyon2/cougarcanyon2.c | 4 +---
drivers/mmc/omap_hsmmc.c | 2 +-
drivers/serial/serial-uclass.c| 2 +-
drivers/serial/serial_bcm283x_mu.c| 2 +-
drivers/serial/serial_bcm283x_pl011.c | 2 +-
drivers/sysreset/sysreset_ast.c | 2 +-
drivers/video/exynos/exynos_fb.c | 24 ++-
drivers/video/mali_dp.c | 2 +-
drivers/video/stm32/stm32_dsi.c | 6 --
drivers/video/tegra124/dp.c | 7 ---
lib/acpi/acpi_table.c | 2 +-
lib/efi_loader/efi_gop.c | 2 +-
net/eth-uclass.c | 4 ++--
test/boot/bootmeth.c | 2 +-
test/dm/acpi.c| 14 ++---
test/dm/devres.c | 4 ++--
test/dm/i2c.c | 8
test/dm/virtio_device.c | 8
test/dm/virtio_rng.c | 2 +-
test/fuzz/cmd_fuzz.c | 2 +-
test/fuzz/virtio.c| 2 +-
25 files changed, 55 insertions(+), 64 deletions(-)
diff --git a/arch/arm/mach-omap2/am33xx/board.c
b/arch/arm/mach-omap2/am33xx/board.c
index 7f1b84e466..f393ff9144 100644
--- a/arch/arm/mach-omap2/am33xx/board.c
+++ b/arch/arm/mach-omap2/am33xx/board.c
@@ -265,8 +265,8 @@ int arch_misc_init(void)
struct udevice *dev;
int ret;
- ret = uclass_first_device(UCLASS_MISC, );
- if (ret || !dev)
+ ret = uclass_first_device_err(UCLASS_MISC, );
+ if (ret)
return ret;
#if defined(CONFIG_DM_ETH) && defined(CONFIG_USB_ETHER)
diff --git a/arch/x86/cpu/broadwell/cpu.c b/arch/x86/cpu/broadwell/cpu.c
index 2adcf4b242..7877961451 100644
--- a/arch/x86/cpu/broadwell/cpu.c
+++ b/arch/x86/cpu/broadwell/cpu.c
@@ -31,11 +31,9 @@ static int broadwell_init_cpu(void *ctx, struct event *event)
int ret;
/* Start up the LPC so we have serial */
- ret = uclass_first_device(UCLASS_LPC, );
+ ret = uclass_first_device_err(UCLASS_LPC, );
if (ret)
return ret;
- if (!dev)
- return -ENODEV;
ret = cpu_set_flex_ratio_to_tdp_nominal();
if (ret)
return ret;
diff --git a/arch/x86/cpu/intel_common/cpu.c b/arch/x86/cpu/intel_common/cpu.c
index 96d05e2eb3..8f489e6c65 100644
--- a/arch/x86/cpu/intel_common/cpu.c
+++ b/arch/x86/cpu/intel_common/cpu.c
@@ -61,11 +61,9 @@ int cpu_common_init(void)
/* Early chipset init required before RAM init can work */
uclass_first_device(UCLASS_NORTHBRIDGE, );
- ret = uclass_first_device(UCLASS_LPC, );
+ ret = uclass_first_device_err(UCLASS_LPC, );
if (ret)
return ret;
- if (!lpc)
- return -ENODEV;
/* Cause the SATA device to do its early init */
uclass_first_device(UCLASS_AHCI, );
diff --git a/arch/x86/lib/pinctrl_ich6.c b/arch/x86/lib/pinctrl_ich6.c
index fd5e311b29..c93f245845 100644
--- a/arch/x86/lib/pinctrl_ich6.c
+++ b/arch/x86/lib/pinctrl_ich6.c
@@ -160,11 +160,9 @@ static int ich6_pinctrl_probe(struct udevice *dev)
u32 iobase = -1;
debug("%s: start\n", __func__);
- ret = uclass_first_device(UCLASS_PCH, );
+ ret = uclass_first_device_err(UCLASS_PCH, );
if (ret)
return ret;
- if (!pch)
- return -ENODEV;
/*
* Get the memory/io base address to configure every pins.
diff --git a/board/intel/cougarcanyon2/cougarcanyon2.c
b/board/intel/cougarcanyon2/cougarcanyon2.c
index ce11eae59d..7f61ef8b36 100644
--- a/board/intel/cougarcanyon2/cougarcanyon2.c
+++ b/board/intel/cougarcanyon2/cougarcanyon2.c
@@ -21,11 +21,9 @@ int board_early_init_f(void)
struct udevice *pch;
int ret;
- ret = uclass_first_device(UCLASS_PCH, );
+ ret = uclass_first_device_err(UCLASS_PCH, );
if (ret)
return ret;
- if (!pch)
- return -ENODEV;
/*
[PATCH v5 11/15] dm: treewide: Use uclass_next_device_err when accessing second device
There are a couple users of uclass_next_device return value that get the
first device by other means and use uclass_next_device assuming the
following device in the uclass is related to the first one.
Use uclass_next_device_err because the return value from
uclass_next_device will be removed in a later patch.
Signed-off-by: Michal Suchanek
---
arch/arm/mach-k3/j721s2_init.c | 2 +-
board/atmel/common/mac_eeprom.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-k3/j721s2_init.c b/arch/arm/mach-k3/j721s2_init.c
index 12da8136f9..dd0c7ba18f 100644
--- a/arch/arm/mach-k3/j721s2_init.c
+++ b/arch/arm/mach-k3/j721s2_init.c
@@ -164,7 +164,7 @@ void board_init_f(ulong dummy)
if (ret)
panic("DRAM 0 init failed: %d\n", ret);
- ret = uclass_next_device();
+ ret = uclass_next_device_err();
if (ret)
panic("DRAM 1 init failed: %d\n", ret);
}
diff --git a/board/atmel/common/mac_eeprom.c b/board/atmel/common/mac_eeprom.c
index a723ba723c..4606008c69 100644
--- a/board/atmel/common/mac_eeprom.c
+++ b/board/atmel/common/mac_eeprom.c
@@ -56,7 +56,7 @@ int at91_set_eth1addr(int offset)
return ret;
/* attempt to obtain a second eeprom device */
- ret = uclass_next_device();
+ ret = uclass_next_device_err();
if (ret)
return ret;
--
2.37.3
[PATCH v5 07/15] video: ipuv3: Fix error handling when getting the display
The code checks that uclass_first_device returned a device but the
returned value that is assigned is never used. Use
uclass_first_device_err instead, and move the error return outside of
the if block.
Fixes: f4ec1ae08e ("mxc_ipuv3_fb.c: call display_enable")
Signed-off-by: Michal Suchanek
---
drivers/video/imx/mxc_ipuv3_fb.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/video/imx/mxc_ipuv3_fb.c b/drivers/video/imx/mxc_ipuv3_fb.c
index 49bbeefdd8..8b01a1be11 100644
--- a/drivers/video/imx/mxc_ipuv3_fb.c
+++ b/drivers/video/imx/mxc_ipuv3_fb.c
@@ -609,12 +609,11 @@ static int ipuv3_video_probe(struct udevice *dev)
return ret;
#if defined(CONFIG_DISPLAY)
- ret = uclass_first_device(UCLASS_DISPLAY, _dev);
- if (disp_dev) {
+ ret = uclass_first_device_err(UCLASS_DISPLAY, _dev);
+ if (!ret)
ret = display_enable(disp_dev, 16, NULL);
- if (ret < 0)
- return ret;
- }
+ if (ret < 0)
+ return ret;
#endif
if (CONFIG_IS_ENABLED(PANEL)) {
struct udevice *panel_dev;
--
2.37.3
[PATCH v5 09/15] cmd: List all uclass devices regardless of probe error
There are a few commands that iterate uclass with
uclass_first_device/uclass_next_device or the _err variant.
Use the _check class iterator variant to get devices that fail to probe
as well, and print the status.
Signed-off-by: Michal Suchanek
---
cmd/adc.c | 22 ++
cmd/demo.c | 16 ++--
cmd/gpio.c | 15 +++
cmd/pmic.c | 15 ---
cmd/regulator.c | 13 +++--
5 files changed, 46 insertions(+), 35 deletions(-)
diff --git a/cmd/adc.c b/cmd/adc.c
index 1c5d3e10a3..7dcb44eb61 100644
--- a/cmd/adc.c
+++ b/cmd/adc.c
@@ -6,29 +6,27 @@
#include
#include
#include
+#include
#include
static int do_adc_list(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
struct udevice *dev;
- int ret;
+ int ret, err;
- ret = uclass_first_device_err(UCLASS_ADC, );
- if (ret) {
- printf("No available ADC device\n");
- return CMD_RET_FAILURE;
- }
+ ret = err = uclass_first_device_check(UCLASS_ADC, );
- do {
- printf("- %s\n", dev->name);
+ while (dev) {
+ printf("- %s status: %s\n", dev->name,
+ ret ? errno_str(ret) : "OK");
- ret = uclass_next_device();
+ ret = uclass_next_device_check();
if (ret)
- return CMD_RET_FAILURE;
- } while (dev);
+ err = ret;
+ }
- return CMD_RET_SUCCESS;
+ return err ? CMD_RET_FAILURE : CMD_RET_SUCCESS;
}
static int do_adc_info(struct cmd_tbl *cmdtp, int flag, int argc,
diff --git a/cmd/demo.c b/cmd/demo.c
index 571f562ec6..56551f269d 100644
--- a/cmd/demo.c
+++ b/cmd/demo.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
@@ -64,20 +65,23 @@ static int do_demo_light(struct cmd_tbl *cmdtp, int flag,
int argc,
int do_demo_list(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
{
struct udevice *dev;
- int i, ret;
+ int i, ret, err = 0;
puts("Demo uclass entries:\n");
- for (i = 0, ret = uclass_first_device(UCLASS_DEMO, );
+ for (i = 0, ret = uclass_first_device_check(UCLASS_DEMO, );
dev;
-ret = uclass_next_device()) {
- printf("entry %d - instance %08x, ops %08x, plat %08x\n",
+ret = uclass_next_device_check()) {
+ printf("entry %d - instance %08x, ops %08x, plat %08x, probe %i
(%s)\n",
i++, (uint)map_to_sysmem(dev),
(uint)map_to_sysmem(dev->driver->ops),
- (uint)map_to_sysmem(dev_get_plat(dev)));
+ (uint)map_to_sysmem(dev_get_plat(dev)),
+ ret, errno_str(ret));
+ if (ret)
+ err = ret;
}
- return cmd_process_error(cmdtp, ret);
+ return cmd_process_error(cmdtp, err);
}
static struct cmd_tbl demo_commands[] = {
diff --git a/cmd/gpio.c b/cmd/gpio.c
index 53e9ce666f..4bf410a9e7 100644
--- a/cmd/gpio.c
+++ b/cmd/gpio.c
@@ -77,17 +77,24 @@ static int do_gpio_status(bool all, const char *gpio_name)
struct udevice *dev;
int banklen;
int flags;
- int ret;
+ int ret, err = 0;
flags = 0;
if (gpio_name && !*gpio_name)
gpio_name = NULL;
- for (ret = uclass_first_device(UCLASS_GPIO, );
+ for (ret = uclass_first_device_check(UCLASS_GPIO, );
dev;
-ret = uclass_next_device()) {
+ret = uclass_next_device_check()) {
const char *bank_name;
int num_bits;
+ if (ret) {
+ printf("GPIO device %s probe error %i (%s)\n",
+ dev->name, ret, errno_str(ret));
+ err = ret;
+ continue;
+ }
+
flags |= FLAG_SHOW_BANK;
if (all)
flags |= FLAG_SHOW_ALL;
@@ -120,7 +127,7 @@ static int do_gpio_status(bool all, const char *gpio_name)
flags |= FLAG_SHOW_NEWLINE;
}
- return ret;
+ return err;
}
#endif
diff --git a/cmd/pmic.c b/cmd/pmic.c
index 0cb44d0740..d5624241e6 100644
--- a/cmd/pmic.c
+++ b/cmd/pmic.c
@@ -51,25 +51,26 @@ static int do_list(struct cmd_tbl *cmdtp, int flag, int
argc,
char *const argv[])
{
struct udevice *dev;
- int ret;
+ int ret, err = 0;
printf("| %-*.*s| %-*.*s| %s @ %s\n",
LIMIT_DEV, LIMIT_DEV, "Name",
LIMIT_PARENT, LIMIT_PARENT, "Parent name",
"Parent uclass", "seq");
- for (ret = uclass_first_device(UCLASS_PMIC, ); dev;
-ret = uclass_next_device()) {
+ for (ret = uclass_first_device_check(UCLASS_PMIC, ); dev;
+
[PATCH v5 05/15] usb: ether: Fix error handling in usb_ether_init
The code checks the return value from uclass_first_device as well as
that the device exists but it passes on the return value which may be
zero if there are no gadget devices. Just check that a device was
returned and return -ENODEV otherwise.
Also remove the dev variable which is not really used for anything.
Signed-off-by: Michal Suchanek
---
drivers/usb/gadget/ether.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index abb5332f13..ad394c80fc 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -2636,18 +2636,17 @@ static const struct eth_ops usb_eth_ops = {
int usb_ether_init(void)
{
- struct udevice *dev;
struct udevice *usb_dev;
int ret;
- ret = uclass_first_device(UCLASS_USB_GADGET_GENERIC, _dev);
- if (!usb_dev || ret) {
+ uclass_first_device(UCLASS_USB_GADGET_GENERIC, _dev);
+ if (!usb_dev) {
pr_err("No USB device found\n");
- return ret;
+ return -ENODEV;
}
- ret = device_bind_driver(usb_dev, "usb_ether", "usb_ether", );
- if (!dev || ret) {
+ ret = device_bind_driver(usb_dev, "usb_ether", "usb_ether", NULL);
+ if (ret) {
pr_err("usb - not able to bind usb_ether device\n");
return ret;
}
--
2.37.3
[PATCH v5 06/15] stdio: Fix class iteration in stdio_add_devices()
There is a complaint in the code that iterates keyboards that we don't
have the _check variant of class iterator but we in fact do, use it.
In the code that iterates video devices there is an attempt to print
errors but the simple iterator does not return a device when there is an
error. Use the _check variant of the iterator as well.
Also print the symbolic error.
Fixes: b206cd7372 ("dm: stdio: Plumb in the new keyboard uclass")
Fixes: e3b81c1c0d ("dm: stdio: video: Plumb the video uclass into stdio")
Signed-off-by: Michal Suchanek
---
common/stdio.c | 33 ++---
1 file changed, 14 insertions(+), 19 deletions(-)
diff --git a/common/stdio.c b/common/stdio.c
index 92161a0df8..17f0aef76d 100644
--- a/common/stdio.c
+++ b/common/stdio.c
@@ -306,7 +306,6 @@ int stdio_init_tables(void)
int stdio_add_devices(void)
{
struct udevice *dev;
- struct uclass *uc;
int ret;
if (IS_ENABLED(CONFIG_DM_KEYBOARD)) {
@@ -316,24 +315,18 @@ int stdio_add_devices(void)
* have a list of input devices to start up in the stdin
* environment variable. That work probably makes more sense
* when stdio itself is converted to driver model.
-*
-* TODO(s...@chromium.org): Convert changing
-* uclass_first_device() etc. to return the device even on
-* error. Then we could use that here.
*/
- ret = uclass_get(UCLASS_KEYBOARD, );
- if (ret)
- return ret;
/*
* Don't report errors to the caller - assume that they are
* non-fatal
*/
- uclass_foreach_dev(dev, uc) {
- ret = device_probe(dev);
+ for (ret = uclass_first_device_check(UCLASS_KEYBOARD, );
+ dev;
+ ret = uclass_next_device_check()) {
if (ret)
- printf("Failed to probe keyboard '%s'\n",
- dev->name);
+ printf("%s: Failed to probe keyboard '%s'
(ret=%d %s)\n",
+ __func__, dev->name, ret,
errno_str(ret));
}
}
#if CONFIG_IS_ENABLED(SYS_I2C_LEGACY)
@@ -353,13 +346,15 @@ int stdio_add_devices(void)
int ret;
if (!IS_ENABLED(CONFIG_SYS_CONSOLE_IS_IN_ENV)) {
- for (ret = uclass_first_device(UCLASS_VIDEO, );
-vdev;
-ret = uclass_next_device())
- ;
- if (ret)
- printf("%s: Video device failed (ret=%d)\n",
- __func__, ret);
+ for (ret = uclass_first_device_check(UCLASS_VIDEO,
+);
+ vdev;
+ ret = uclass_next_device_check()) {
+ if (ret)
+ printf("%s: Failed to probe video
device '%s' (ret=%d %s)\n",
+ __func__, dev->name,
+ ret, errno_str(ret));
+ }
}
if (IS_ENABLED(CONFIG_SPLASH_SCREEN) &&
IS_ENABLED(CONFIG_CMD_BMP))
--
2.37.3
[PATCH v5 04/15] bootstd: Fix listing boot devices
bootdev_list() uses uclass_*_device_err() to iterate devices.
However, the only value _err adds is returning an error when the device
pointer is null, and that's checked anyway.
Also there is some intent to report errors, and that's what
uclass_*_device_check() is for, use it.
Also print the symbolic error.
Signed-off-by: Michal Suchanek
---
boot/bootdev-uclass.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/boot/bootdev-uclass.c b/boot/bootdev-uclass.c
index 13ac69eb39..e7115c5750 100644
--- a/boot/bootdev-uclass.c
+++ b/boot/bootdev-uclass.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -195,16 +196,16 @@ void bootdev_list(bool probe)
printf("Seq Probed Status UclassName\n");
printf("--- -- -- --\n");
if (probe)
- ret = uclass_first_device_err(UCLASS_BOOTDEV, );
+ ret = uclass_first_device_check(UCLASS_BOOTDEV, );
else
ret = uclass_find_first_device(UCLASS_BOOTDEV, );
for (i = 0; dev; i++) {
printf("%3x [ %c ] %6s %-9.9s %s\n", dev_seq(dev),
device_active(dev) ? '+' : ' ',
- ret ? simple_itoa(ret) : "OK",
+ ret ? errno_str(ret) : "OK",
dev_get_uclass_name(dev_get_parent(dev)), dev->name);
if (probe)
- ret = uclass_next_device_err();
+ ret = uclass_next_device_check();
else
ret = uclass_find_next_device();
}
--
2.37.3
[PATCH v5 03/15] dm: pci: Fix device PCI iteration
When there is no PCI bus uclass_first_device will return no bus and no
error which will result in pci_find_first_device calling
skip_to_next_device with no bus, and the bus is only checked at the end
of the while cycle, not the beginning.
Also stop dealing with the return value of
uclass_first_device/uclass_next_device - once the iteration is fixed to
continue after an error there is nothing meaningful to get anymore.
Fixes: 76c3fbcd3d ("dm: pci: Add a way to iterate through all PCI devices")
Signed-off-by: Michal Suchanek
---
drivers/pci/pci-uclass.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 16a6a699f9..00e3828d95 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -1211,22 +1211,19 @@ static int pci_bridge_write_config(struct udevice *bus,
pci_dev_t bdf,
static int skip_to_next_device(struct udevice *bus, struct udevice **devp)
{
struct udevice *dev;
- int ret = 0;
/*
* Scan through all the PCI controllers. On x86 there will only be one
* but that is not necessarily true on other hardware.
*/
- do {
+ while (bus) {
device_find_first_child(bus, );
if (dev) {
*devp = dev;
return 0;
}
- ret = uclass_next_device();
- if (ret)
- return ret;
- } while (bus);
+ uclass_next_device();
+ }
return 0;
}
@@ -1235,7 +1232,6 @@ int pci_find_next_device(struct udevice **devp)
{
struct udevice *child = *devp;
struct udevice *bus = child->parent;
- int ret;
/* First try all the siblings */
*devp = NULL;
@@ -1248,9 +1244,7 @@ int pci_find_next_device(struct udevice **devp)
}
/* We ran out of siblings. Try the next bus */
- ret = uclass_next_device();
- if (ret)
- return ret;
+ uclass_next_device();
return bus ? skip_to_next_device(bus, devp) : 0;
}
@@ -1258,12 +1252,9 @@ int pci_find_next_device(struct udevice **devp)
int pci_find_first_device(struct udevice **devp)
{
struct udevice *bus;
- int ret;
*devp = NULL;
- ret = uclass_first_device(UCLASS_PCI, );
- if (ret)
- return ret;
+ uclass_first_device(UCLASS_PCI, );
return skip_to_next_device(bus, devp);
}
--
2.37.3
[PATCH v5 02/15] dm: treewide: Do not opencode uclass_probe_all()
We already have a function for probing all devices of a specific class,
use it.
Signed-off-by: Michal Suchanek
---
drivers/cpu/cpu-uclass.c | 20
drivers/virtio/virtio-uclass.c | 15 +--
test/dm/core.c | 17 +++--
test/test-main.c | 11 +--
4 files changed, 9 insertions(+), 54 deletions(-)
diff --git a/drivers/cpu/cpu-uclass.c b/drivers/cpu/cpu-uclass.c
index 71e5900d70..a754832526 100644
--- a/drivers/cpu/cpu-uclass.c
+++ b/drivers/cpu/cpu-uclass.c
@@ -20,25 +20,13 @@ DECLARE_GLOBAL_DATA_PTR;
int cpu_probe_all(void)
{
- struct udevice *cpu;
- int ret;
+ int ret = uclass_probe_all(UCLASS_CPU);
- ret = uclass_first_device(UCLASS_CPU, );
if (ret) {
- debug("%s: No CPU found (err = %d)\n", __func__, ret);
- return ret;
- }
-
- while (cpu) {
- ret = uclass_next_device();
- if (ret) {
- debug("%s: Error while probing CPU (err = %d)\n",
- __func__, ret);
- return ret;
- }
+ debug("%s: Error while probing CPUs (err = %d %s)\n",
+ __func__, ret, errno_str(ret));
}
-
- return 0;
+ return ret;
}
int cpu_is_current(struct udevice *cpu)
diff --git a/drivers/virtio/virtio-uclass.c b/drivers/virtio/virtio-uclass.c
index 9e2d0e06a1..da4f2f26a6 100644
--- a/drivers/virtio/virtio-uclass.c
+++ b/drivers/virtio/virtio-uclass.c
@@ -183,21 +183,8 @@ void virtio_driver_features_init(struct virtio_dev_priv
*priv,
int virtio_init(void)
{
- struct udevice *bus;
- int ret;
-
/* Enumerate all known virtio devices */
- ret = uclass_first_device(UCLASS_VIRTIO, );
- if (ret)
- return ret;
-
- while (bus) {
- ret = uclass_next_device();
- if (ret)
- break;
- }
-
- return ret;
+ return uclass_probe_all(UCLASS_VIRTIO);
}
static int virtio_uclass_pre_probe(struct udevice *udev)
diff --git a/test/dm/core.c b/test/dm/core.c
index fd4d756972..84eb76ed5f 100644
--- a/test/dm/core.c
+++ b/test/dm/core.c
@@ -512,23 +512,15 @@ static int dm_test_leak(struct unit_test_state *uts)
int i;
for (i = 0; i < 2; i++) {
- struct udevice *dev;
int ret;
- int id;
dm_leak_check_start(uts);
ut_assertok(dm_scan_plat(false));
ut_assertok(dm_scan_fdt(false));
- /* Scanning the uclass is enough to probe all the devices */
- for (id = UCLASS_ROOT; id < UCLASS_COUNT; id++) {
- for (ret = uclass_first_device(UCLASS_TEST, );
-dev;
-ret = uclass_next_device())
- ;
- ut_assertok(ret);
- }
+ ret = uclass_probe_all(UCLASS_TEST);
+ ut_assertok(ret);
ut_assertok(dm_leak_check_end(uts));
}
@@ -653,10 +645,7 @@ static int dm_test_children(struct unit_test_state *uts)
ut_asserteq(2 + NODE_COUNT, dm_testdrv_op_count[DM_TEST_OP_PROBE]);
/* Probe everything */
- for (ret = uclass_first_device(UCLASS_TEST, );
-dev;
-ret = uclass_next_device())
- ;
+ ret = uclass_probe_all(UCLASS_TEST);
ut_assertok(ret);
ut_asserteq(total, dm_testdrv_op_count[DM_TEST_OP_PROBE]);
diff --git a/test/test-main.c b/test/test-main.c
index 31837e57a8..be0bf9d52c 100644
--- a/test/test-main.c
+++ b/test/test-main.c
@@ -89,16 +89,7 @@ static int dm_test_post_run(struct unit_test_state *uts)
/* Ensure all the test devices are probed */
static int do_autoprobe(struct unit_test_state *uts)
{
- struct udevice *dev;
- int ret;
-
- /* Scanning the uclass is enough to probe all the devices */
- for (ret = uclass_first_device(UCLASS_TEST, );
-dev;
-ret = uclass_next_device())
- ;
-
- return ret;
+ return uclass_probe_all(UCLASS_TEST);
}
/*
--
2.37.3
[PATCH v5 01/15] dm: core: Fix uclass_probe_all to really probe all devices
uclass_probe_all uses uclass_first_device/uclass_next_device assigning
the return value.
The interface for getting meaningful error is
uclass_first_device_check/uclass_next_device_check, use it.
Also do not stop iteration when an error is encountered. Probing all
devices includes those that happen to be after a failing device in the
uclass order.
Fixes: a59153dfeb ("dm: core: add function uclass_probe_all() to probe all
devices")
Signed-off-by: Michal Suchanek
---
drivers/core/uclass.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
index 08d9ed82de..a591e22403 100644
--- a/drivers/core/uclass.c
+++ b/drivers/core/uclass.c
@@ -799,20 +799,18 @@ int uclass_pre_remove_device(struct udevice *dev)
int uclass_probe_all(enum uclass_id id)
{
struct udevice *dev;
- int ret;
+ int ret, err;
- ret = uclass_first_device(id, );
- if (ret || !dev)
- return ret;
+ err = uclass_first_device_check(id, );
/* Scanning uclass to probe all devices */
while (dev) {
- ret = uclass_next_device();
+ ret = uclass_next_device_check();
if (ret)
- return ret;
+ err = ret;
}
- return 0;
+ return err;
}
int uclass_id_count(enum uclass_id id)
--
2.37.3
[PATCH] dm: pci: Fix doc typo first -> next
pci_find_first_device description says it can be used for iteration with itself but it should really be with pci_find_next_device Signed-off-by: Michal Suchanek --- Resent separately include/pci.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/pci.h b/include/pci.h index d7ed35dd52..c55d6107a4 100644 --- a/include/pci.h +++ b/include/pci.h @@ -957,7 +957,7 @@ int pci_bus_find_devfn(const struct udevice *bus, pci_dev_t find_devfn, /** * pci_find_first_device() - return the first available PCI device * - * This function and pci_find_first_device() allow iteration through all + * This function and pci_find_next_device() allow iteration through all * available PCI devices on all buses. Assuming there are any, this will * return the first one. * -- 2.37.3
[PATCH] dm: core: Add note about device_probe idempotence
device_probe returns early when the device is already activated. Add a note to the documentation that it can be used on already activated devices. Signed-off-by: Michal Suchanek --- Resent separately include/dm/device-internal.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/dm/device-internal.h b/include/dm/device-internal.h index 94844d30d8..f31c470208 100644 --- a/include/dm/device-internal.h +++ b/include/dm/device-internal.h @@ -184,8 +184,8 @@ int device_of_to_plat(struct udevice *dev); /** * device_probe() - Probe a device, activating it * - * Activate a device so that it is ready for use. All its parents are probed - * first. + * Activate a device (if not yet activated) so that it is ready for use. + * All its parents are probed first. * * @dev: Pointer to device to probe * Return: 0 if OK, -ve on error -- 2.37.3
[PATCH] dm: core: Document return value of device bind functions
These functions use device_bind_with_driver_data internally, copy the return value description. Signed-off-by: Michal Suchanek --- Resent separately include/dm/lists.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/dm/lists.h b/include/dm/lists.h index fc3b4ae585..97236f8fa0 100644 --- a/include/dm/lists.h +++ b/include/dm/lists.h @@ -73,6 +73,7 @@ int lists_bind_fdt(struct udevice *parent, ofnode node, struct udevice **devp, * @drv_name: Name of driver to attach to this parent * @dev_name: Name of the new device thus created * @devp: If non-NULL, returns the newly bound device + * Return: 0 if OK, -ve on error */ int device_bind_driver(struct udevice *parent, const char *drv_name, const char *dev_name, struct udevice **devp); @@ -88,6 +89,7 @@ int device_bind_driver(struct udevice *parent, const char *drv_name, * @dev_name: Name of the new device thus created * @node: Device tree node * @devp: If non-NULL, returns the newly bound device + * Return: 0 if OK, -ve on error */ int device_bind_driver_to_node(struct udevice *parent, const char *drv_name, const char *dev_name, ofnode node, -- 2.37.3
[PATCH] dm: blk: Add probe in blk_first_device/blk_next_device
The description claims that the device is probed but it isn't.
Add the device_probe() call.
Also consolidate the iteration into one function.
Fixes: 8a5cbc065d ("dm: blk: Use uclass_find_first/next_device() in
blk_first/next_device()")
Signed-off-by: Michal Suchanek
---
Resent separately
drivers/block/blk-uclass.c | 46 ++
1 file changed, 22 insertions(+), 24 deletions(-)
diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
index 676f2444bf..35beedfdf7 100644
--- a/drivers/block/blk-uclass.c
+++ b/drivers/block/blk-uclass.c
@@ -361,45 +361,43 @@ int blk_dselect_hwpart(struct blk_desc *desc, int hwpart)
return blk_select_hwpart(desc->bdev, hwpart);
}
-int blk_first_device(int if_type, struct udevice **devp)
+static int _blk_next_device(int if_type, struct udevice **devp)
{
struct blk_desc *desc;
- int ret;
+ int ret = 0;
+
+ for (; *devp; uclass_find_next_device(devp)) {
+ desc = dev_get_uclass_plat(*devp);
+ if (desc->if_type == if_type) {
+ ret = device_probe(*devp);
+ if (!ret)
+ return 0;
+ }
+ }
- ret = uclass_find_first_device(UCLASS_BLK, devp);
if (ret)
return ret;
- if (!*devp)
- return -ENODEV;
- do {
- desc = dev_get_uclass_plat(*devp);
- if (desc->if_type == if_type)
- return 0;
- ret = uclass_find_next_device(devp);
- if (ret)
- return ret;
- } while (*devp);
return -ENODEV;
}
+int blk_first_device(int if_type, struct udevice **devp)
+{
+ uclass_find_first_device(UCLASS_BLK, devp);
+
+ return _blk_next_device(if_type, devp);
+}
+
int blk_next_device(struct udevice **devp)
{
struct blk_desc *desc;
- int ret, if_type;
+ int if_type;
desc = dev_get_uclass_plat(*devp);
if_type = desc->if_type;
- do {
- ret = uclass_find_next_device(devp);
- if (ret)
- return ret;
- if (!*devp)
- return -ENODEV;
- desc = dev_get_uclass_plat(*devp);
- if (desc->if_type == if_type)
- return 0;
- } while (1);
+ uclass_find_next_device(devp);
+
+ return _blk_next_device(if_type, devp);
}
int blk_find_device(int if_type, int devnum, struct udevice **devp)
--
2.37.3
Re: Please pull u-boot-watchdog/master
On Tue, Sep 27, 2022 at 02:48:09PM +0200, Stefan Roese wrote: > Hi Tom, > > please pull the following watchdog related last minute fixes: > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] Makefile: Disable PLATFORM_LIBGCC for LLVM toolchain
On Tue, Sep 27, 2022 at 12:41:15PM -0400, Tom Rini wrote: > On Tue, Sep 27, 2022 at 09:29:51AM -0700, Alistair Delva wrote: > > Hi Tom, > > > > On Tue, Sep 27, 2022 at 8:57 AM Tom Rini wrote: > > > > > > On Mon, Sep 26, 2022 at 08:47:47PM +, Alistair Delva wrote: > > > > > > > The LLVM toolchain does not have or need libgcc, so do not require > > > > it to exist on the library path. Even if "-print-libgcc-file-name" > > > > returned the empty string, -lgcc would be specified. > > > > > > > > This leaves CONFIG_USE_PRIVATE_LIBGCC alone because I did not have > > > > a target/toolchain combination available for testing. > > > > > > > > Signed-off-by: Alistair Delva > > > > Cc: Simon Glass > > > > Cc: Tom Rini > > > > Cc: Nick Desaulniers > > > > --- > > > > Makefile | 2 ++ > > > > 1 file changed, 2 insertions(+) > > > > > > > > diff --git a/Makefile b/Makefile > > > > index 8af67ebd63..af06b7aa19 100644 > > > > --- a/Makefile > > > > +++ b/Makefile > > > > @@ -874,8 +874,10 @@ u-boot-main := $(libs-y) > > > > ifeq ($(CONFIG_USE_PRIVATE_LIBGCC),y) > > > > PLATFORM_LIBGCC = arch/$(ARCH)/lib/lib.a > > > > else > > > > +ifneq ($(cc-name),clang) > > > > PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(c_flags) > > > > -print-libgcc-file-name`) -lgcc > > > > endif > > > > +endif > > > > PLATFORM_LIBS += $(PLATFORM_LIBGCC) > > > > > > > > ifdef CONFIG_CC_COVERAGE > > > > > > So this one isn't quite right, and will result in some platforms / > > > architectures just failing to build as the handful of functions we get > > > provided by CONFIG_USE_PRIVATE_LIBGCC end up being missing. > > > > > > It's also the case that this is a badly named option, and something we > > > really should figure out how to remove and then always provide the > > > required functions for. What configuration did you end up having this > > > problem on exactly? > > > > We have CI set up for qemu_arm64_defconfig, qemu-x86_64_defconfig, > > am57xx_evm_defconfig and rock-pi-4-rk3399_defconfig. I think all were > > affected, since they don't use CONFIG_USE_PRIVATE_LIBGCC, so they all > > hit this fallback. > > > > AFAIK, for a long time, Android used an LLVM toolchain built with some > > workarounds such as knowledge of a corresponding GCC-based toolchain, > > so -print-libgcc-file-name could provide a path to libgcc.a. However, > > our newer toolchains no longer do this and the symbols are either > > automatically provided or provided by compiler-rt. In U-Boot's case, I > > don't think our targets ever required libgcc but because the > > fall-through expands to "-L . -lgcc" when -print-libgcc-file-name > > returns the empty string, the link will fail because it will look for > > libgcc but not find it. > > OK, that sounds familiar now that you say it, and part of why rpi_arm64 > + LLVM isn't part of my local testing loop. I believe I had been > thinking the best path forward was to port ashldi3.S and friends from > arch/arm64 in the Linux kernel over, so that USE_PRIVATE_LIBGCC (which > is a bad name!) could also be select'd on CONFIG_ARM64. That would just > leave x86, which just needs a div64 implementation for 64bit? I'm not > entirely sure. > > All of that said, it might also be the case we don't need the fallback > to using libgcc at all, in most cases? If you're able to build and test > those platforms with it disabled, it might well be the case that we > just don't need the fallback anymore, and a world build with that just > removed would help figure out if that's true. OK, another new test build, a look at the kernel, and I see a better path forward than it used to be at least. It would be best to: - Port the kernel's current GENERIC_LIB_*DI3 functions - Rename USE_PRIVATE_LIBGCC in U-Boot / drop it, depending on the location (arch/arm/lib/Makefile should just include ashldi3.o and friends on !ARM64). - Port the kernel's arch/powerpc/boot/crtsavres.S for PowerPC which is fairly straight forward looking, even if you aren't a PowerPC person This would be the way forward to drop trying to use libgcc directly, I believe. -- Tom signature.asc Description: PGP signature
Re: [PATCH] tools: kwboot: Change KWBOOT_MSG_RSP_TIMEO_AXP to 10ms
On Friday 19 August 2022 10:20:46 Pali Rohár wrote:
> On Friday 19 August 2022 09:43:59 Stefan Roese wrote:
> > Testing on the theadorable Armada XP platform has shown, thaz using the
> > current value of 1000ms as response timeout does not result in reliable
> > booting via kwboot. Using 10ms seems to be much better. So let's change
> > this value to this 10ms instead.
> >
> > Signed-off-by: Stefan Roese
>
> Acked-by: Pali Rohár
Hello Stefan! You should update also documentation file doc/kwboot.1
because it mention "1000 ms" for Option \fB-a\fP.
> > ---
> > tools/kwboot.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tools/kwboot.c b/tools/kwboot.c
> > index 16bcd4d9a778..da4fe32da226 100644
> > --- a/tools/kwboot.c
> > +++ b/tools/kwboot.c
> > @@ -84,7 +84,7 @@ static unsigned char kwboot_msg_debug[] = {
> > #define KWBOOT_MSG_RSP_TIMEO 50 /* ms */
> >
> > /* Defines known to work on Armada XP */
> > -#define KWBOOT_MSG_RSP_TIMEO_AXP 1000 /* ms */
> > +#define KWBOOT_MSG_RSP_TIMEO_AXP 10 /* ms */
> >
> > /*
> > * Xmodem Transfers
> > --
> > 2.37.2
> >
Re: [PATCH] Makefile: Disable PLATFORM_LIBGCC for LLVM toolchain
On Tue, Sep 27, 2022 at 9:30 AM Alistair Delva wrote: > > Hi Tom, > > On Tue, Sep 27, 2022 at 8:57 AM Tom Rini wrote: > > > > On Mon, Sep 26, 2022 at 08:47:47PM +, Alistair Delva wrote: > > > > > The LLVM toolchain does not have or need libgcc, so do not require > > > it to exist on the library path. Even if "-print-libgcc-file-name" > > > returned the empty string, -lgcc would be specified. > > > > > > This leaves CONFIG_USE_PRIVATE_LIBGCC alone because I did not have > > > a target/toolchain combination available for testing. > > > > > > Signed-off-by: Alistair Delva > > > Cc: Simon Glass > > > Cc: Tom Rini > > > Cc: Nick Desaulniers > > > --- > > > Makefile | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/Makefile b/Makefile > > > index 8af67ebd63..af06b7aa19 100644 > > > --- a/Makefile > > > +++ b/Makefile > > > @@ -874,8 +874,10 @@ u-boot-main := $(libs-y) > > > ifeq ($(CONFIG_USE_PRIVATE_LIBGCC),y) > > > PLATFORM_LIBGCC = arch/$(ARCH)/lib/lib.a > > > else > > > +ifneq ($(cc-name),clang) > > > PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(c_flags) > > > -print-libgcc-file-name`) -lgcc > > > endif > > > +endif > > > PLATFORM_LIBS += $(PLATFORM_LIBGCC) > > > > > > ifdef CONFIG_CC_COVERAGE > > > > So this one isn't quite right, and will result in some platforms / > > architectures just failing to build as the handful of functions we get > > provided by CONFIG_USE_PRIVATE_LIBGCC end up being missing. So sounds like based on the configs we build for Android, we don't need the compiler runtime for ARCH=arm64 and ARCH=x86_64 (possibly ARCH=arm). LLVM's equivalent is called compiler-rt; `$ clang --rtlib=compiler-rt`, which might need to be passed explicitly depending on whether clang was configured at build time of clang itself to use libgcc or compiler-rt as the implicit default --rtlib. FWIW, the Linux kernel is a bit of a mess when it comes to compiler runtime. Some architecture ports require a compiler runtime, some provide their own impl, but only for some symbols which makes targeting them with any given compiler...interesting. If these flags are going to the compiler as the driver, I wonder if `--rtlib=libgcc` vs `--rtlib=none` might be more descriptive. > > > > It's also the case that this is a badly named option, and something we > > really should figure out how to remove and then always provide the > > required functions for. What configuration did you end up having this > > problem on exactly? > > We have CI set up for qemu_arm64_defconfig, qemu-x86_64_defconfig, > am57xx_evm_defconfig and rock-pi-4-rk3399_defconfig. I think all were > affected, since they don't use CONFIG_USE_PRIVATE_LIBGCC, so they all > hit this fallback. > > AFAIK, for a long time, Android used an LLVM toolchain built with some > workarounds such as knowledge of a corresponding GCC-based toolchain, > so -print-libgcc-file-name could provide a path to libgcc.a. However, > our newer toolchains no longer do this and the symbols are either > automatically provided or provided by compiler-rt. In U-Boot's case, I > don't think our targets ever required libgcc but because the > fall-through expands to "-L . -lgcc" when -print-libgcc-file-name > returns the empty string, the link will fail because it will look for > libgcc but not find it. > > Alistair. -- Thanks, ~Nick Desaulniers
Re: [PATCH v10 10/15] FWU: Add support for the FWU Multi Bank Update feature
On Tue, Sep 27, 2022 at 2:22 AM Sughosh Ganu wrote:
>
> On Mon, 26 Sept 2022 at 20:24, Jassi Brar wrote:
> >
> > On Mon, Sep 26, 2022 at 4:01 AM Sughosh Ganu
> > wrote:
> > > On Mon, 26 Sept 2022 at 08:25, Jassi Brar
> > > wrote:
> >
> > > > .
> > > > >
> > > > > +static __maybe_unused efi_status_t fwu_post_update_process(bool
> > > > > fw_accept_os)
> > > > > +{
> > > > > + int status;
> > > > > + u32 update_index;
> > > > > + efi_status_t ret;
> > > > > +
> > > > > + status = fwu_plat_get_update_index(_index);
> > > > > + if (status < 0) {
> > > > > + log_err("Failed to get the FWU update_index value\n");
> > > > > + return EFI_DEVICE_ERROR;
> > > > > + }
> > > > > +
> > > > > + /*
> > > > > +* All the capsules have been updated successfully,
> > > > > +* update the FWU metadata.
> > > > > +*/
> > > > > + log_debug("Update Complete. Now updating active_index to
> > > > > %u\n",
> > > > > + update_index);
> > > > > + status = fwu_update_active_index(update_index);
> > > > >
> > > > Do we want to check if all images in the bank are updated via capsules
> > > > before switching the bank?
> > >
> > > This function does get called only when the update status for every
> > > capsule is a success. Even if one of the capsules does not get
> > > updated, the active index will not get updated.
> > >
> > but we don't check if the capsule for each image in the bank is
> > provided for update.
>
> Yes, we have had this discussion earlier. Neither the FWU spec, nor
> the capsule update spec in UEFI puts that restriction that all images
> on the platform need to be updated. If a user wants to ensure such a
> behaviour, they may choose some kind of image packaging like FIP or
> FIT which would mean that all the images on the platform are being
> updated. But this is not something to be ensured by the FWU update
> code.
>
> >
> > > >
> > > > A developer will make sure all images are provided in one go, so that
> > > > the switch is successful.
> > > > But a malicious user may force some old vulnerable image back into use
> > > > by updating all but that image.
> > >
> > > That I believe is to be handled through a combination of implementing
> > > a rollback protection mechanism, along with capsule authentication.
> > > These are separate to the implementation of the multi bank updates
> > > that these patches are aiming for.
> > >
> > This sounds like : we don't worry about buffer-overflow
> > vulnerabilities because the system will be secured and hardened by
> > other mechanisms.
>
> Not sure how this is related. The aim of the FWU spec is for providing
> a means for a platform to maintain multiple partitions of images and
> to specify the metadata structure for the bookkeeping of the different
> partitions and images on those partitions. If we need a more secure
> and hardened system, we do have the Dependable Boot spec, which is
> talking precisely about these things. Those are indeed separate
> features or aspects from what the FWU spec is talking about. And this
> patchset is implementing the FWU spec.
>
I am out of ways to explain. Best of luck.
Re: [PATCH] Makefile: Disable PLATFORM_LIBGCC for LLVM toolchain
On Tue, Sep 27, 2022 at 09:29:51AM -0700, Alistair Delva wrote: > Hi Tom, > > On Tue, Sep 27, 2022 at 8:57 AM Tom Rini wrote: > > > > On Mon, Sep 26, 2022 at 08:47:47PM +, Alistair Delva wrote: > > > > > The LLVM toolchain does not have or need libgcc, so do not require > > > it to exist on the library path. Even if "-print-libgcc-file-name" > > > returned the empty string, -lgcc would be specified. > > > > > > This leaves CONFIG_USE_PRIVATE_LIBGCC alone because I did not have > > > a target/toolchain combination available for testing. > > > > > > Signed-off-by: Alistair Delva > > > Cc: Simon Glass > > > Cc: Tom Rini > > > Cc: Nick Desaulniers > > > --- > > > Makefile | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/Makefile b/Makefile > > > index 8af67ebd63..af06b7aa19 100644 > > > --- a/Makefile > > > +++ b/Makefile > > > @@ -874,8 +874,10 @@ u-boot-main := $(libs-y) > > > ifeq ($(CONFIG_USE_PRIVATE_LIBGCC),y) > > > PLATFORM_LIBGCC = arch/$(ARCH)/lib/lib.a > > > else > > > +ifneq ($(cc-name),clang) > > > PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(c_flags) > > > -print-libgcc-file-name`) -lgcc > > > endif > > > +endif > > > PLATFORM_LIBS += $(PLATFORM_LIBGCC) > > > > > > ifdef CONFIG_CC_COVERAGE > > > > So this one isn't quite right, and will result in some platforms / > > architectures just failing to build as the handful of functions we get > > provided by CONFIG_USE_PRIVATE_LIBGCC end up being missing. > > > > It's also the case that this is a badly named option, and something we > > really should figure out how to remove and then always provide the > > required functions for. What configuration did you end up having this > > problem on exactly? > > We have CI set up for qemu_arm64_defconfig, qemu-x86_64_defconfig, > am57xx_evm_defconfig and rock-pi-4-rk3399_defconfig. I think all were > affected, since they don't use CONFIG_USE_PRIVATE_LIBGCC, so they all > hit this fallback. > > AFAIK, for a long time, Android used an LLVM toolchain built with some > workarounds such as knowledge of a corresponding GCC-based toolchain, > so -print-libgcc-file-name could provide a path to libgcc.a. However, > our newer toolchains no longer do this and the symbols are either > automatically provided or provided by compiler-rt. In U-Boot's case, I > don't think our targets ever required libgcc but because the > fall-through expands to "-L . -lgcc" when -print-libgcc-file-name > returns the empty string, the link will fail because it will look for > libgcc but not find it. OK, that sounds familiar now that you say it, and part of why rpi_arm64 + LLVM isn't part of my local testing loop. I believe I had been thinking the best path forward was to port ashldi3.S and friends from arch/arm64 in the Linux kernel over, so that USE_PRIVATE_LIBGCC (which is a bad name!) could also be select'd on CONFIG_ARM64. That would just leave x86, which just needs a div64 implementation for 64bit? I'm not entirely sure. All of that said, it might also be the case we don't need the fallback to using libgcc at all, in most cases? If you're able to build and test those platforms with it disabled, it might well be the case that we just don't need the fallback anymore, and a world build with that just removed would help figure out if that's true. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] nitrogen6x: Remove extra quotes in fdtfile
On 9/27/2022 7:24 AM, Ariel D'Alessandro wrote:
> After commit 395110284b56 ("nitrogen6x: Populate FDTFILE at build-time
> for all platforms") iMX.6Q Sabrelite fails to boot due to a bad fdtfile
> string:
>
> Retrieving file: /dtbs/5.18.0-0.deb11.4-armmp/"imx6q-sabrelite".dtb
> ** File not found /dtbs/5.18.0-0.deb11.4-armmp/"imx6q-sabrelite".dtb **
>
> CONFIG_DEFAULT_DEVICE_TREE option is string typed, so __stringify() is
> adding extra quotes. Remove this.
>
> Signed-off-by: Ariel D'Alessandro
> Reviewed-by: Fabio Estevam
> ---
> include/configs/nitrogen6x.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
> index 2007b48868..26e6de2d2c 100644
> --- a/include/configs/nitrogen6x.h
> +++ b/include/configs/nitrogen6x.h
> @@ -76,7 +76,7 @@
> "fdt_high=0x\0" \
> "initrd_high=0x\0" \
> "fdt_addr_r=0x1800\0" \
> - "fdtfile=" __stringify(CONFIG_DEFAULT_DEVICE_TREE) ".dtb\0" \
> + "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
> "kernel_addr_r=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
> "pxefile_addr_r=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
> "scriptaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
Acked-by: Troy Kisky
Re: [PATCH] Makefile: Disable PLATFORM_LIBGCC for LLVM toolchain
Hi Tom, On Tue, Sep 27, 2022 at 8:57 AM Tom Rini wrote: > > On Mon, Sep 26, 2022 at 08:47:47PM +, Alistair Delva wrote: > > > The LLVM toolchain does not have or need libgcc, so do not require > > it to exist on the library path. Even if "-print-libgcc-file-name" > > returned the empty string, -lgcc would be specified. > > > > This leaves CONFIG_USE_PRIVATE_LIBGCC alone because I did not have > > a target/toolchain combination available for testing. > > > > Signed-off-by: Alistair Delva > > Cc: Simon Glass > > Cc: Tom Rini > > Cc: Nick Desaulniers > > --- > > Makefile | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/Makefile b/Makefile > > index 8af67ebd63..af06b7aa19 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -874,8 +874,10 @@ u-boot-main := $(libs-y) > > ifeq ($(CONFIG_USE_PRIVATE_LIBGCC),y) > > PLATFORM_LIBGCC = arch/$(ARCH)/lib/lib.a > > else > > +ifneq ($(cc-name),clang) > > PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(c_flags) > > -print-libgcc-file-name`) -lgcc > > endif > > +endif > > PLATFORM_LIBS += $(PLATFORM_LIBGCC) > > > > ifdef CONFIG_CC_COVERAGE > > So this one isn't quite right, and will result in some platforms / > architectures just failing to build as the handful of functions we get > provided by CONFIG_USE_PRIVATE_LIBGCC end up being missing. > > It's also the case that this is a badly named option, and something we > really should figure out how to remove and then always provide the > required functions for. What configuration did you end up having this > problem on exactly? We have CI set up for qemu_arm64_defconfig, qemu-x86_64_defconfig, am57xx_evm_defconfig and rock-pi-4-rk3399_defconfig. I think all were affected, since they don't use CONFIG_USE_PRIVATE_LIBGCC, so they all hit this fallback. AFAIK, for a long time, Android used an LLVM toolchain built with some workarounds such as knowledge of a corresponding GCC-based toolchain, so -print-libgcc-file-name could provide a path to libgcc.a. However, our newer toolchains no longer do this and the symbols are either automatically provided or provided by compiler-rt. In U-Boot's case, I don't think our targets ever required libgcc but because the fall-through expands to "-L . -lgcc" when -print-libgcc-file-name returns the empty string, the link will fail because it will look for libgcc but not find it. Alistair.
Re: [PATCH v10 02/15] FWU: Add FWU metadata structure and driver for accessing metadata
On Tue, Sep 27, 2022 at 2:14 AM Sughosh Ganu wrote:
>
> On Mon, 26 Sept 2022 at 20:12, Jassi Brar wrote:
> >
> > On Mon, Sep 26, 2022 at 5:00 AM Sughosh Ganu
> > wrote:
> > >
> > > On Mon, 26 Sept 2022 at 08:28, Jassi Brar
> > > wrote:
> > > >
> >
> > > >
> > > > .
> > > > > +/**
> > > > > + * fwu_revert_boot_index() - Revert the active index in the FWU
> > > > > metadata
> > > > > + *
> > > > > + * Revert the active_index value in the FWU metadata, by swapping
> > > > > the values
> > > > > + * of active_index and previous_active_index in both copies of the
> > > > > + * FWU metadata.
> > > > > + *
> > > > > + * Return: 0 if OK, -ve on error
> > > > > + *
> > > > > + */
> > > > > +int fwu_revert_boot_index(void)
> > > > > +{
> > > > > + int ret;
> > > > > + u32 cur_active_index;
> > > > > + struct udevice *dev;
> > > > > + struct fwu_mdata mdata = { 0 };
> > > > > +
> > > > > + ret = fwu_get_dev_mdata(, );
> > > > > + if (ret)
> > > > > + return ret;
> > > > > +
> > > > > + /*
> > > > > +* Swap the active index and previous_active_index fields
> > > > > +* in the FWU metadata
> > > > > +*/
> > > > > + cur_active_index = mdata.active_index;
> > > > > + mdata.active_index = mdata.previous_active_index;
> > > > > + mdata.previous_active_index = cur_active_index;
> > > > >
> > > > This may cause problems.
> > > > We are reverting because active_index does not work, and here we set
> > > > it to previous_active_index which is supposed to mean "last good
> > > > index".
> > > > Also this logic assumes a 2-banks setup, and is obviously incorrect
> > > > for >2 banks where the previous_active_index should point to
> > > > "boot_index minus 2" bank (but of course there is no guarantee that
> > > > that bank is preserved still).
> > > > So either previous_active_index be left changed OR we also copy the
> > > > previous bank to active bank before the swap.
> > >
> > > Sorry, but I don't understand the review comment here. Even in the
> > > case of num_banks > 2, this function is simply using the
> > > previous_active_index value. It does not care what the
> > > previous_active_index value is. If you remember, the setting of the
> > > update bank is really a platform
> > > function(fwu_plat_get_update_index()). A platform can set any bank
> > > number as the update bank. So we cannot tell what the value of the
> > > previous_active_index will be.
> > >
> > Do you remember you pick update_bank in a circular-buffer manner in
> > fwu_plat_get_update_index() ? But don't even bother the >2 banks.
> >
> > Consider the simple 2-banks platform
> > Initially:
> >active_index = 1
> >previous_active_index = 0
> >
> > After update and before reboot
> >active_index = 0 updated bank 0
> >previous_active_index = 1
> >
> > After reboot, for some reason update fails (reject bank0) and we call
> > fwu_revert_boot_index()
> >active_index = 1<<< good
> >previous_active_index = 0 points to unbootable bank
> >
> > Which may be seen as inconsistency if we assume previous_bank to
> > always contain a bootable set of images.
> > So we also need to copy bank1 into bank0 as part of the revert (at
> > least as a backup for reasons other than a/b update failure).
>
> If the platform owner wants to restore a particular bank with good
> images, the procedure to update that bank needs to be followed just
> like it was any other update.
>
The banks are under FWU and the platform has (should have) no control
over which bank the image goes in.
> If an updated bank fails the image
> acceptance test, the following boot would be from the
> previous_active_bank. In that case, the other bank needs to be updated
> by explicitly putting capsules in the ESP and initiating the update.
>
Which capsule - the one that just failed or the previous one (which
may not be available/provided)?
Doesn't simply copying over the bank make more sense?
>
> > > All that this function does is use the
> > > previous_active_index as the partition/bank to boot from in the
> > > subsequent boot cycle.
> > >
> > That is, you assume the previous_active_index bank contains working images.
>
> It is the responsibility of the platform owner to ensure that all
> partitions have valid images.
>
I differ. The platform should not be modifying banks and meta-data
beneath the fwu framework.
The specification says "A Client can only read from or write to images
in the update bank"
-j
Re: [PATCH] Makefile: Disable PLATFORM_LIBGCC for LLVM toolchain
On Mon, Sep 26, 2022 at 08:47:47PM +, Alistair Delva wrote: > The LLVM toolchain does not have or need libgcc, so do not require > it to exist on the library path. Even if "-print-libgcc-file-name" > returned the empty string, -lgcc would be specified. > > This leaves CONFIG_USE_PRIVATE_LIBGCC alone because I did not have > a target/toolchain combination available for testing. > > Signed-off-by: Alistair Delva > Cc: Simon Glass > Cc: Tom Rini > Cc: Nick Desaulniers > --- > Makefile | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Makefile b/Makefile > index 8af67ebd63..af06b7aa19 100644 > --- a/Makefile > +++ b/Makefile > @@ -874,8 +874,10 @@ u-boot-main := $(libs-y) > ifeq ($(CONFIG_USE_PRIVATE_LIBGCC),y) > PLATFORM_LIBGCC = arch/$(ARCH)/lib/lib.a > else > +ifneq ($(cc-name),clang) > PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(c_flags) > -print-libgcc-file-name`) -lgcc > endif > +endif > PLATFORM_LIBS += $(PLATFORM_LIBGCC) > > ifdef CONFIG_CC_COVERAGE So this one isn't quite right, and will result in some platforms / architectures just failing to build as the handful of functions we get provided by CONFIG_USE_PRIVATE_LIBGCC end up being missing. It's also the case that this is a badly named option, and something we really should figure out how to remove and then always provide the required functions for. What configuration did you end up having this problem on exactly? -- Tom signature.asc Description: PGP signature
[PATCH v2] apalis/colibri_imx6/-imx6ull/_imx7: update env memory layout
From: Marcel Ziswiler
Update the distro config env memory layout for the Apalis iMX6,
Colibri iMX6, Colibri iMX6ULL and Colibri iMX7:
- loadaddr=0x8420 (resp. 0x1420 on them i.MX 6) allows for 64MB
area for uncompressing (ie FIT images)
- fdt_addr_r = loadaddr + 64MB : allows for 64MB kernel
- scriptaddr = fdt_addr_r + 512KB : allows for 512KB fdt
- pxefile_addr_r = scriptaddr + 512KB : allows for 512KB script
- ramdisk_addr_r = pxefile_addr_r + 512KB : allows for 1MB extlinux.conf
Memory layout analogous to 64-bit one from commit fd5c7173ade4
("imx8m{m,n}_venice: update env memory layout") but left pxefile_addr_r
updated according to doc/develop/distro.rst.
This fixes a potential issue caused by the compressed kernel being
relocated on top of the ramdisk causing its corruption.
Signed-off-by: Marcel Ziswiler
---
Changes in v2:
- Changed i.MX 6 addressing back to starting from 0x1000 instead of
0x8000.
configs/apalis_imx6_defconfig | 1 +
configs/colibri-imx6ull-emmc_defconfig | 1 +
configs/colibri-imx6ull_defconfig | 1 +
configs/colibri_imx6_defconfig | 1 +
configs/colibri_imx7_defconfig | 1 +
configs/colibri_imx7_emmc_defconfig| 1 +
include/configs/apalis_imx6.h | 10 +-
include/configs/colibri-imx6ull.h | 10 +-
include/configs/colibri_imx6.h | 10 +-
include/configs/colibri_imx7.h | 10 +-
10 files changed, 26 insertions(+), 20 deletions(-)
diff --git a/configs/apalis_imx6_defconfig b/configs/apalis_imx6_defconfig
index 5960aef698f..2689e8d9846 100644
--- a/configs/apalis_imx6_defconfig
+++ b/configs/apalis_imx6_defconfig
@@ -22,6 +22,7 @@ CONFIG_SPL_MMC=y
CONFIG_SPL_SERIAL=y
CONFIG_SPL=y
CONFIG_CMD_HDMIDETECT=y
+CONFIG_SYS_LOAD_ADDR=0x1420
CONFIG_AHCI=y
CONFIG_SYS_MEMTEST_START=0x1000
CONFIG_SYS_MEMTEST_END=0x1001
diff --git a/configs/colibri-imx6ull-emmc_defconfig
b/configs/colibri-imx6ull-emmc_defconfig
index e6ed9b5fd0f..02b6be0a2b4 100644
--- a/configs/colibri-imx6ull-emmc_defconfig
+++ b/configs/colibri-imx6ull-emmc_defconfig
@@ -10,6 +10,7 @@ CONFIG_DM_GPIO=y
CONFIG_TARGET_COLIBRI_IMX6ULL_EMMC=y
CONFIG_DEFAULT_DEVICE_TREE="imx6ull-colibri-emmc-eval-v3"
CONFIG_SYS_PROMPT="Colibri iMX6ULL # "
+CONFIG_SYS_LOAD_ADDR=0x8420
CONFIG_SYS_MEMTEST_START=0x8000
CONFIG_SYS_MEMTEST_END=0x8800
CONFIG_DISTRO_DEFAULTS=y
diff --git a/configs/colibri-imx6ull_defconfig
b/configs/colibri-imx6ull_defconfig
index d65f2533ca2..cc0a3473941 100644
--- a/configs/colibri-imx6ull_defconfig
+++ b/configs/colibri-imx6ull_defconfig
@@ -11,6 +11,7 @@ CONFIG_DM_GPIO=y
CONFIG_TARGET_COLIBRI_IMX6ULL_NAND=y
CONFIG_DEFAULT_DEVICE_TREE="imx6ull-colibri-eval-v3"
CONFIG_SYS_PROMPT="Colibri iMX6ULL # "
+CONFIG_SYS_LOAD_ADDR=0x8420
CONFIG_SYS_MEMTEST_START=0x8000
CONFIG_SYS_MEMTEST_END=0x8800
CONFIG_DISTRO_DEFAULTS=y
diff --git a/configs/colibri_imx6_defconfig b/configs/colibri_imx6_defconfig
index 5cf398b09e2..135095b275d 100644
--- a/configs/colibri_imx6_defconfig
+++ b/configs/colibri_imx6_defconfig
@@ -22,6 +22,7 @@ CONFIG_SPL_MMC=y
CONFIG_SPL_SERIAL=y
CONFIG_SPL=y
CONFIG_CMD_HDMIDETECT=y
+CONFIG_SYS_LOAD_ADDR=0x1420
CONFIG_SYS_MEMTEST_START=0x1000
CONFIG_SYS_MEMTEST_END=0x1001
CONFIG_DISTRO_DEFAULTS=y
diff --git a/configs/colibri_imx7_defconfig b/configs/colibri_imx7_defconfig
index dfdb74f69b0..28872639b61 100644
--- a/configs/colibri_imx7_defconfig
+++ b/configs/colibri_imx7_defconfig
@@ -11,6 +11,7 @@ CONFIG_SYS_PROMPT="Colibri iMX7 # "
CONFIG_IMX_RDC=y
CONFIG_IMX_BOOTAUX=y
CONFIG_IMX_HAB=y
+CONFIG_SYS_LOAD_ADDR=0x8420
CONFIG_OF_BOARD_FIXUP=y
CONFIG_SYS_MEMTEST_START=0x8000
CONFIG_SYS_MEMTEST_END=0x8c00
diff --git a/configs/colibri_imx7_emmc_defconfig
b/configs/colibri_imx7_emmc_defconfig
index 033ce1747bf..c12717b4f25 100644
--- a/configs/colibri_imx7_emmc_defconfig
+++ b/configs/colibri_imx7_emmc_defconfig
@@ -12,6 +12,7 @@ CONFIG_ARMV7_BOOT_SEC_DEFAULT=y
CONFIG_IMX_RDC=y
CONFIG_IMX_BOOTAUX=y
CONFIG_IMX_HAB=y
+CONFIG_SYS_LOAD_ADDR=0x8420
CONFIG_SYS_MEMTEST_START=0x8000
CONFIG_SYS_MEMTEST_END=0x8c00
CONFIG_DISTRO_DEFAULTS=y
diff --git a/include/configs/apalis_imx6.h b/include/configs/apalis_imx6.h
index 4922b063309..8f338943475 100644
--- a/include/configs/apalis_imx6.h
+++ b/include/configs/apalis_imx6.h
@@ -70,11 +70,11 @@
#define MEM_LAYOUT_ENV_SETTINGS \
"bootm_size=0x2000\0" \
- "fdt_addr_r=0x1210\0" \
- "kernel_addr_r=0x1100\0" \
- "pxefile_addr_r=0x1710\0" \
- "ramdisk_addr_r=0x1220\0" \
- "scriptaddr=0x1700\0"
+ "fdt_addr_r=0x1820\0" \
+ "kernel_addr_r=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
+ "pxefile_addr_r=0x1830\0" \
+ "ramdisk_addr_r=0x1840\0" \
+ "scriptaddr=0x1828\0"
#define CONFIG_EXTRA_ENV_SETTINGS \
BOOTENV \
diff --git
Re: [PATCH] rockchip: rk3399: add ethaddr and serial# init, enable for R4S
Please disregard (duplicate patch) Following up with "[PATCH] rk3399: r4s: Derive local MAC address if EEPROM is missing". Cheers, Christian
Re: [PATCH] rockchip: rk3399: add ethaddr and serial# init, enable for R4S
> Following up with "[PATCH] rockchip: rk3399: add ethaddr and serial# init, > enable for R4S", which enables these settings in > configs/nanopi-r4s-rk3399_defconfig. > > This doesn't look any different from what you already sent. > > ChenYu Following up with "[PATCH] rk3399: r4s: Derive local MAC address if EEPROM is missing". Cheers, Christian
[PATCH] rk3399: r4s: Derive local MAC address if EEPROM is missing
Some RK3399 boards, such as newer revisions of NanoPi R4S, do not provide an EEPROM chip containing a globally unique MAC address. Currently, this means that a randomly generated temporary MAC address may be generated each time the device is rebooted, leading to ARP cache issues and other confusing bugs. Since RK3399 CPUs provide a built-in unique serial number, we can reliably derive a locally MAC address from it by reading the corresponding bits from the non-secure efuse block. Enable configuration options that allow deriving a local MAC address from the CPU serial number. --- configs/nanopi-r4s-rk3399_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/configs/nanopi-r4s-rk3399_defconfig b/configs/nanopi-r4s-rk3399_defconfig index 46ba07f4d5..aa89ac5854 100644 --- a/configs/nanopi-r4s-rk3399_defconfig +++ b/configs/nanopi-r4s-rk3399_defconfig @@ -63,3 +63,7 @@ CONFIG_VIDEO_ROCKCHIP=y CONFIG_DISPLAY_ROCKCHIP_HDMI=y CONFIG_SPL_TINY_MEMSET=y CONFIG_ERRNO_STR=y +CONFIG_MISC=y +CONFIG_MISC_INIT_R=y +CONFIG_ROCKCHIP_EFUSE=y +CONFIG_ROCKCHIP_OTP=y -- 2.36.2
[PATCH v2] nitrogen6x: Remove extra quotes in fdtfile
After commit 395110284b56 ("nitrogen6x: Populate FDTFILE at build-time
for all platforms") iMX.6Q Sabrelite fails to boot due to a bad fdtfile
string:
Retrieving file: /dtbs/5.18.0-0.deb11.4-armmp/"imx6q-sabrelite".dtb
** File not found /dtbs/5.18.0-0.deb11.4-armmp/"imx6q-sabrelite".dtb **
CONFIG_DEFAULT_DEVICE_TREE option is string typed, so __stringify() is
adding extra quotes. Remove this.
Signed-off-by: Ariel D'Alessandro
Reviewed-by: Fabio Estevam
---
include/configs/nitrogen6x.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index 2007b48868..26e6de2d2c 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -76,7 +76,7 @@
"fdt_high=0x\0" \
"initrd_high=0x\0" \
"fdt_addr_r=0x1800\0" \
- "fdtfile=" __stringify(CONFIG_DEFAULT_DEVICE_TREE) ".dtb\0" \
+ "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
"kernel_addr_r=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
"pxefile_addr_r=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
"scriptaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
--
2.37.2
Re: [PATCH] imx6: Remove extra quotes in fdtfile environment variable
Hi Fabio,
On 9/27/22 11:20, Fabio Estevam wrote:
> Hi Ariel,
>
> On Tue, Sep 27, 2022 at 11:14 AM Ariel D'Alessandro
> wrote:
>>
>> After commit 395110284b56 ("nitrogen6x: Populate FDTFILE at build-time
>> for all platforms") iMX.6Q Sabrelite fails to boot due to a bad fdtfile
>> string:
>>
>> Retrieving file: /dtbs/5.18.0-0.deb11.4-armmp/"imx6q-sabrelite".dtb
>> ** File not found /dtbs/5.18.0-0.deb11.4-armmp/"imx6q-sabrelite".dtb **
>>
>> CONFIG_DEFAULT_DEVICE_TREE option is string typed, so __stringify() is
>> adding extra quotes. Remove this.
>>
>> Signed-off-by: Ariel D'Alessandro
>
> Just a nit: in the Subject, it would be better to change it like this:
>
> nitrogen6x: Remove extra quotes in fdtfile
Makes sense. Will amend it right away.
>
> Reviewed-by: Fabio Estevam
>
> Stefano/Tom,
>
> This is 2022.10 material IMHO.
Thanks!
Re: [PATCH] imx6: Remove extra quotes in fdtfile environment variable
Hi Ariel,
On Tue, Sep 27, 2022 at 11:14 AM Ariel D'Alessandro
wrote:
>
> After commit 395110284b56 ("nitrogen6x: Populate FDTFILE at build-time
> for all platforms") iMX.6Q Sabrelite fails to boot due to a bad fdtfile
> string:
>
> Retrieving file: /dtbs/5.18.0-0.deb11.4-armmp/"imx6q-sabrelite".dtb
> ** File not found /dtbs/5.18.0-0.deb11.4-armmp/"imx6q-sabrelite".dtb **
>
> CONFIG_DEFAULT_DEVICE_TREE option is string typed, so __stringify() is
> adding extra quotes. Remove this.
>
> Signed-off-by: Ariel D'Alessandro
Just a nit: in the Subject, it would be better to change it like this:
nitrogen6x: Remove extra quotes in fdtfile
Reviewed-by: Fabio Estevam
Stefano/Tom,
This is 2022.10 material IMHO.
[PATCH] imx6: Remove extra quotes in fdtfile environment variable
After commit 395110284b56 ("nitrogen6x: Populate FDTFILE at build-time
for all platforms") iMX.6Q Sabrelite fails to boot due to a bad fdtfile
string:
Retrieving file: /dtbs/5.18.0-0.deb11.4-armmp/"imx6q-sabrelite".dtb
** File not found /dtbs/5.18.0-0.deb11.4-armmp/"imx6q-sabrelite".dtb **
CONFIG_DEFAULT_DEVICE_TREE option is string typed, so __stringify() is
adding extra quotes. Remove this.
Signed-off-by: Ariel D'Alessandro
---
include/configs/nitrogen6x.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index 2007b48868..26e6de2d2c 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -76,7 +76,7 @@
"fdt_high=0x\0" \
"initrd_high=0x\0" \
"fdt_addr_r=0x1800\0" \
- "fdtfile=" __stringify(CONFIG_DEFAULT_DEVICE_TREE) ".dtb\0" \
+ "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
"kernel_addr_r=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
"pxefile_addr_r=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
"scriptaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
--
2.37.2
Re: [PULL] Pull request for u-boot next / v2022.10 = u-boot-stm32-20220927
On Tue, Sep 27, 2022 at 02:00:14PM +0200, Patrice CHOTARD wrote: > Hi Tom, > > Please pull the STM32 related fixes for u-boot/next, v2022.10: > u-boot-stm32-20220927 > > CI status: > https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/13610 > > Thanks > Patrice > > The following changes since commit ebdd6afa543324648138f780a648b8fb65d488eb: > > Merge branch 'next' of > https://source.denx.de/u-boot/custodians/u-boot-marvell into next (2022-09-20 > 08:50:07 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-stm.git > tags/u-boot-stm32-20220927 > > for you to fetch changes up to 762d410e0db94c41b8d7f1ec85e47f7474655ad8: > > configs: increase SYS_MALLOC_F_LEN for STM32 MCU's board (2022-09-27 > 10:41:02 +0200) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 0/4] clk-imx8mm: Reduce SPL binary size
Hi Fabio On Tue, Sep 27, 2022 at 3:44 PM Fabio Estevam wrote: > > Hi Michael, > > On Tue, Sep 27, 2022 at 10:38 AM Michael Nazzareno Trimarchi > wrote: > > > When Dario wrote the Ti clock, he was using the dtsi. One idea can be > > understand if this approch > > cost less in term of space in the SPL > > Care to submit a patch series with your proposal? Our plan can be this one. We are soon sending some patches for imx Nand subsystems that introduce new clocks there. We use then this series to create a PoC where we move those clocks in dtsi format as in omap and then send it later Michael -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH 0/4] clk-imx8mm: Reduce SPL binary size
Hi Michael, On Tue, Sep 27, 2022 at 10:38 AM Michael Nazzareno Trimarchi wrote: > When Dario wrote the Ti clock, he was using the dtsi. One idea can be > understand if this approch > cost less in term of space in the SPL Care to submit a patch series with your proposal?
Re: [PATCH 0/4] clk-imx8mm: Reduce SPL binary size
Hi Fabio On Tue, Sep 27, 2022 at 2:29 PM Fabio Estevam wrote: > > Hi Michael, > > On 27/09/2022 09:24, Michael Nazzareno Trimarchi wrote: > > >> Fabio Estevam (4): > >> clk-imx8mm: Only build PWM clocks in non-SPL code > >> clk-imx8mm: Move CLK_ENET_AXI to the non-SPL section > > > > I'm not really convinced of those two. I mean with should maybe think > > about > > some different approach of clock framework to reduce the size > > What is your proposal then? When Dario wrote the Ti clock, he was using the dtsi. One idea can be understand if this approch cost less in term of space in the SPL Michael -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PULL] Pull request for u-boot next / v2022.10 = u-boot-stm32-20220927
Tom Sorry, this PR is not dedicated for v2022.10 as indicated in the subject but for v2023.01. Patrice On 9/27/22 14:00, Patrice CHOTARD wrote: > Hi Tom, > > Please pull the STM32 related fixes for u-boot/next, v2022.10: > u-boot-stm32-20220927 > > CI status: > https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/13610 > > Thanks > Patrice > > The following changes since commit ebdd6afa543324648138f780a648b8fb65d488eb: > > Merge branch 'next' of > https://source.denx.de/u-boot/custodians/u-boot-marvell into next (2022-09-20 > 08:50:07 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-stm.git > tags/u-boot-stm32-20220927 > > for you to fetch changes up to 762d410e0db94c41b8d7f1ec85e47f7474655ad8: > > configs: increase SYS_MALLOC_F_LEN for STM32 MCU's board (2022-09-27 > 10:41:02 +0200) > > > - Increase SYS_MALLOC_F_LEN for STM32 MCU's board > - SPL fixes for STM32F7 MCUs > - Device tree alignement with kernelv6.0-rc4 for MCU's board > - Device tree alignement with kernelv6.0-rc3 for MPU's board > - Update DDR node for STM32MP15 > - Cleanup config file for STM32MP1 > - Update for cmd_stm32key command > - Fix compatible string to add partitions for STM32MP1 > - Update for stm32programmer tool > > > Christophe Kerello (1): > board: st: stm32mp1: use of correct compatible string to add partitions > > Patrice Chotard (9): > ARM: dts: stm32: DT sync with kernel v6.0-rc4 for MCU's boards > configs: stm32f746-disco: Fix SPL boot > configs: stm32f769-disco: Fix SPL boot > configs: stm32746g-eval: Fix SPL boot > configs: stm32f746-disco: Fix CONFIG_SYS_SPL_ARGS_ADDR > configs: stm32746g-eval: Fix CONFIG_SYS_SPL_ARGS_ADDR > configs: stm32f769-disco: Fix internal flash size > configs: stm32f746-disco: Remove CONFIG_SYS_UBOOT_START flag > configs: increase SYS_MALLOC_F_LEN for STM32 MCU's board > > Patrick Delaunay (12): > stm32mp: stm32prog: support empty flashlayout > stm32mp: stm32prog: change default flashlayout location to > CONFIG_SYS_LOAD_ADDR > stm32mp: stm32prog: solve warning for 64bits compilation > stm32mp: stm32prog: correctly handle OTP when SMC is not supported > ARM: dts: stm32mp: alignment with v6.0-rc3 > stm32mp: stm32prog: improve the partitioning trace > arm: stm32mp: add defines for BSEC_LOCK status in stm32key command > arm: stm32mp: introduced read_close_status function in stm32key command > arm: stm32mp: support several key in command stm32key > arm: stm32mp: adapt the command stm32key for STM32MP13x > configs: stm32mp1: cleanup config file > ARM: dts: stm32mp15: update DDR node > > arch/arm/dts/stm32429i-eval-u-boot.dtsi| 2 +- > arch/arm/dts/stm32746g-eval.dts| 18 +++--- > arch/arm/dts/stm32f4-pinctrl.dtsi | 2 +- > arch/arm/dts/stm32f429-disco-u-boot.dtsi | 8 ++--- > arch/arm/dts/stm32f429-disco.dts | 20 --- > arch/arm/dts/stm32f429-pinctrl.dtsi| 94 > -- > arch/arm/dts/stm32f429.dtsi| 69 > +++-- > arch/arm/dts/stm32f469-disco-u-boot.dtsi | 7 ++-- > arch/arm/dts/stm32f469-disco.dts | 24 ++--- > arch/arm/dts/stm32f469-pinctrl.dtsi| 96 > +-- > arch/arm/dts/stm32f7-pinctrl.dtsi | 2 +- > arch/arm/dts/stm32f7-u-boot.dtsi | 2 +- > arch/arm/dts/stm32f746-disco.dts | 12 +++ > arch/arm/dts/stm32f746.dtsi| 67 > +++- > arch/arm/dts/stm32f769-disco.dts | 18 +++--- > arch/arm/dts/stm32h743.dtsi| 19 -- > arch/arm/dts/stm32h743i-disco.dts | 8 ++--- > arch/arm/dts/stm32h743i-eval.dts | 8 ++--- > arch/arm/dts/stm32h750i-art-pi.dts | 8 ++--- > arch/arm/dts/stm32mp13-u-boot.dtsi | 10 +++--- > arch/arm/dts/stm32mp131.dtsi | 28 +++ > arch/arm/dts/stm32mp135f-dk.dts| 4 +-- > arch/arm/dts/stm32mp15-ddr.dtsi| 16 + > a
Re: [PULL] u-boot-riscv/next
On Mon, Sep 26, 2022 at 07:39:22AM +, Leo Liang wrote: > Hi Tom, > > The following changes since commit 435596d57f8beedf36b5dc858fe7ba9d6c03334b: > > Merge tag 'u-boot-imx-20220922' of > https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2022-09-22 10:29:29 > -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-riscv.git next > > for you to fetch changes up to 3c1ec13317292933fd01d9c60aae3ff1d5bc171e: > > riscv: ae350: Disable AVAILABLE_HARTS (2022-09-26 14:29:44 +0800) > > CI result shows no issue: > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/13595 > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [GIT PULL] xilinx patches for v2023.01-rc1 (round 2)
On Mon, Sep 26, 2022 at 04:03:28PM +0200, Michal Simek wrote: > Hi Tom, > > please pull the following patches to your tree. It is the second round with > small updates but especially adding new Xilinx SOC. > CI loop doesn't show any issue. > > Thanks, > Michal > > > The following changes since commit ebdd6afa543324648138f780a648b8fb65d488eb: > > Merge branch 'next' of > https://source.denx.de/u-boot/custodians/u-boot-marvell into next > (2022-09-20 08:50:07 -0400) > > are available in the Git repository at: > > g...@source.denx.de:u-boot/custodians/u-boot-microblaze.git > tags/xilinx-for-v2023.01-rc1-v2 > > for you to fetch changes up to f2641f066b53a2bbb933bccffd696a875fd9adf5: > > arm64: versal-net: Add support for mini configuration (2022-09-26 14:23:30 > +0200) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Please pull u-boot-watchdog/master
Hi Tom, please pull the following watchdog related last minute fixes: - autoboot: make sure watchdog device(s) are handled with keyed autoboot (Rasmus) - gpio_wdt: use __udelay() to avoid recursion (Rasmus) - watchdog: max6370: use __udelay() to avoid recursion (Pali) Here the Azure build, without any issues: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=271=results Thanks, Stefan The following changes since commit f117c54cc83e3c519883edb5a48062644d38c443: Merge https://gitlab.denx.de/u-boot/custodians/u-boot-marvell (2022-09-26 08:30:17 -0400) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-watchdog.git for you to fetch changes up to c11cedc876631c1753427a68db4efaa00f700a79: autoboot: make sure watchdog device(s) are handled with keyed autoboot (2022-09-27 12:25:51 +0200) Pali Rohár (1): watchdog: max6370: use __udelay() to avoid recursion Rasmus Villemoes (2): watchdog: gpio_wdt: use __udelay() to avoid recursion autoboot: make sure watchdog device(s) are handled with keyed autoboot common/autoboot.c | 3 +++ drivers/watchdog/gpio_wdt.c| 2 +- drivers/watchdog/max6370_wdt.c | 2 +- 3 files changed, 5 insertions(+), 2 deletions(-)
Re: [PATCH 1/4] autoboot: make sure watchdog device(s) are handled with keyed autoboot
On 27.09.22 11:54, Rasmus Villemoes wrote: Currently, AUTOBOOT_KEYED and its variant AUTOBOOT_ENCRYPTION are broken when one has an external always-running watchdog device with a timeout shorter than the configured boot delay (in my case, I have a gpio-wdt one with a timeout of 1 second), because we fail to call WATCHDOG_RESET() in the loops where we wait for the bootdelay to elapse. This is done implicitly in the !AUTOBOOT_KEYED case, i.e. abortboot_single_key(), because that loop contains a udelay(1), and udelay() does a WATCHDOG_RESET(). To fix this, simply add similar udelay() calls in the other loops. Signed-off-by: Rasmus Villemoes Applied to u-boot-watchdog/master Thanks, Stefan --- common/autoboot.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/common/autoboot.c b/common/autoboot.c index 63f2587941..cdafe76309 100644 --- a/common/autoboot.c +++ b/common/autoboot.c @@ -115,6 +115,7 @@ static int passwd_abort_crypt(uint64_t etime) presskey_len++; } } + udelay(1); } while (never_timeout || get_ticks() <= etime); return abort; @@ -206,6 +207,7 @@ static int passwd_abort_sha256(uint64_t etime) if (slow_equals(sha, sha_env, SHA256_SUM_LEN)) abort = 1; } + udelay(1); } while (!abort && get_ticks() <= etime); free(presskey); @@ -293,6 +295,7 @@ static int passwd_abort_key(uint64_t etime) abort = 1; } } + udelay(1); } while (!abort && get_ticks() <= etime); return abort; Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH] watchdog: max6370: use __udelay() to avoid recursion
On 27.09.22 12:19, Pali Rohár wrote:
The udelay() function in lib/time.c contains a WATCHDOG_RESET()
call. So use __udelay() in max6370_wdt.c to prevent recursion.
Fixes: 0a095fc53b15 ("watchdog: Add MAX6370 watchdog timer driver")
Signed-off-by: Pali Rohár
Applied to u-boot-watchdog/master
Thanks,
Stefan
---
drivers/watchdog/max6370_wdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/max6370_wdt.c b/drivers/watchdog/max6370_wdt.c
index 556c6a4b6d6b..44872e23c586 100644
--- a/drivers/watchdog/max6370_wdt.c
+++ b/drivers/watchdog/max6370_wdt.c
@@ -73,7 +73,7 @@ static int max6370_wdt_reset(struct udevice *dev)
if (dm_gpio_is_valid(>gpio_wdi)) {
dm_gpio_set_value(>gpio_wdi, 1);
- udelay(1);
+ __udelay(1);
dm_gpio_set_value(>gpio_wdi, 0);
} else {
val = readb(wdt->reg);
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH] watchdog: gpio_wdt: use __udelay() to avoid recursion
On 27.09.22 09:45, Rasmus Villemoes wrote:
The udelay() function in lib/time.c contains a WATCHDOG_RESET()
call. The only reason this doesn't lead to a catastrophic infinite
recursion is due to the rate-limiting in wdt-uclass.c:
if (time_after_eq(now, priv->next_reset)) {
priv->next_reset = now + priv->reset_period;
wdt_reset(dev);
}
But this would fall apart if ->next_reset was updated after calling the
device's reset method.
This is needlessly fragile, and it's easy enough to avoid that
recursion in the first place by just using __udelay() directly.
Signed-off-by: Rasmus Villemoes
Applied to u-boot-watchdog/master
Thanks,
Stefan
---
drivers/watchdog/gpio_wdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/gpio_wdt.c b/drivers/watchdog/gpio_wdt.c
index fe06ec8cc9..2920c2c751 100644
--- a/drivers/watchdog/gpio_wdt.c
+++ b/drivers/watchdog/gpio_wdt.c
@@ -31,7 +31,7 @@ static int gpio_wdt_reset(struct udevice *dev)
case HW_ALGO_LEVEL:
/* Pulse */
dm_gpio_set_value(>gpio, 1);
- udelay(1);
+ __udelay(1);
dm_gpio_set_value(>gpio, 0);
break;
}
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH 0/4] clk-imx8mm: Reduce SPL binary size
Hi Michael, On 27/09/2022 09:24, Michael Nazzareno Trimarchi wrote: Fabio Estevam (4): clk-imx8mm: Only build PWM clocks in non-SPL code clk-imx8mm: Move CLK_ENET_AXI to the non-SPL section I'm not really convinced of those two. I mean with should maybe think about some different approach of clock framework to reduce the size What is your proposal then?
Re: [PATCH 0/4] clk-imx8mm: Reduce SPL binary size
Hi Fabio On Mon, Sep 26, 2022 at 6:40 PM Fabio Estevam wrote: > > Reduce the SPL binary size by building some clocks only for the > non-SPL case, such as Ethernet and PWM and by also building ECSPI > and QSPI when their respective drivers are enabled. > > On a imx8mm_evk_defconfig the following SPL binary reduction was > observed. > > Prior to this series: > > $ aarch64-linux-gnu-readelf -s spl/u-boot-spl | sort -nk 3 | grep > imx8mm_clk_probe >766: 007f34c8 4100 FUNCLOCAL DEFAULT1 imx8mm_clk_probe > > After this series: > > $ aarch64-linux-gnu-readelf -s spl/u-boot-spl | sort -nk 3 | grep > imx8mm_clk_probe >766: 007f34c8 3316 FUNCLOCAL DEFAULT1 imx8mm_clk_probe > > Total reduction: 4100 - 3316 = 784 bytes. > > Fabio Estevam (4): > clk-imx8mm: Only build PWM clocks in non-SPL code > clk-imx8mm: Move CLK_ENET_AXI to the non-SPL section I'm not really convinced of those two. I mean with should maybe think about some different approach of clock framework to reduce the size Michael > clk-imx8mm: Only build ecspi clocks when CONFIG_DM_SPI=y > clk-imx8mm: Only build QSPI clocks when CONFIG_NXP_FSPI=y > > drivers/clk/imx/clk-imx8mm.c | 86 > 1 file changed, 49 insertions(+), 37 deletions(-) > > -- > 2.25.1 > -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH] pico-imx7d: add baseboard SD card boot detect
On Sun, Aug 21, 2022 at 7:31 PM wrote: > > Migrate SD card boot detection from Technexion u-boot for pico-imx7d SoM. > > From ecd4f6ecbec290c63504f7ec3a9b478425235d14 Mon Sep 17 00:00:00 2001 > From: "Benjamin Szőke" > > Date: Sun, 21 Aug 2022 21:08:55 +0200 > Subject: [PATCH] pico-imx7d: add baseboard SD card boot detect > > Add SD card boot detection from Technexion u-boot for pico-imx7d SoM. Signed-off-by tag is missing. Also, this patch changes too many things in a single patch, which makes it hard to review it. Please rework it in a patch series, so that each patch changes a single logical topic.
Re: [PATCH v2] configs: imx8m: Enable CONFIG_ARMV8_CRYPTO support
Hi Loic, On Thu, Sep 22, 2022 at 6:19 AM Loic Poulain wrote: > > This enables armv8 crypto extension usage for SHA1/SHA256. > > Which speed up sha1/sha256 operations, about 10x faster with > a imx8mm evk for a 20MiB kernel hash verification (12ms vs 165ms). > > Signed-off-by: Loic Poulain Great improvement, thanks: Reviewed-by: Fabio Estevam
Re: [PATCH v1] gpio: adp5585: add gpio driver for ADP5585 I/O Expander Controller
Hi Alice, On Tue, Sep 6, 2022 at 6:37 AM Alice Guo (OSS) wrote: > > From: Alice Guo Please add a commit log. > Signed-off-by: Alice Guo > --- a/arch/arm/include/asm/arch-imx9/gpio.h > +++ b/arch/arm/include/asm/arch-imx9/gpio.h > @@ -6,6 +6,8 @@ > #ifndef __ASM_ARCH_IMX9_GPIO_H > #define __ASM_ARCH_IMX9_GPIO_H > > +#include This looks like an unrelated change. > +config ADP5585_GPIO > + bool "ADP5585 GPIO driver" > + depends on DM_GPIO && DM_I2C > + help > + Support ADP5585 GPIO expander on i.MX platform. Please remove "on i.MX platform" as the GPIO expander can be used on any platform.
Re: [PATCH v10 15/15] FWU: doc: Add documentation for the FWU feature
Hello Sughosh, Thanks for the documentation. See comments on few typos found (with help of my editor) and suggestions. Best regards, Etienne On Thu, 15 Sept 2022 at 10:16, Sughosh Ganu wrote: > > Add documentattion for the FWU Multi Bank Update feature. The document s/documentattion/documentation/ > describes the steps needed for setting up the platform for the > feature, as well as steps for enabling the feature on the platform. > > Signed-off-by: Sughosh Ganu > --- > Changes since V9: None > > doc/develop/uefi/fwu_updates.rst | 165 +++ > doc/develop/uefi/index.rst | 1 + > doc/develop/uefi/uefi.rst| 2 + > 3 files changed, 168 insertions(+) > create mode 100644 doc/develop/uefi/fwu_updates.rst > > diff --git a/doc/develop/uefi/fwu_updates.rst > b/doc/develop/uefi/fwu_updates.rst > new file mode 100644 > index 00..fad3fbb3a8 > --- /dev/null > +++ b/doc/develop/uefi/fwu_updates.rst > @@ -0,0 +1,165 @@ > +.. SPDX-License-Identifier: GPL-2.0+ > +.. Copyright (c) 2022 Linaro Limited > + > +FWU Multi Bank Updates in U-Boot > + > + > +The FWU Multi Bank Update feature implements the firmware update > +mechanism described in the PSA Firmware Update for A-profile Arm > +Architecture specification [1]. Certain aspects of the Dependable > +Boot specification [2] are also implemented. The feature provides a > +mechanism to have multiple banks of updatable firmware images and for > +updating the firmware images on the non-booted bank. On a successful > +update, the platform boots from the updated bank on subsequent > +boot. The UEFI capsule-on-disk update feature is used for performing > +the actual updates of the updatable firmware images. > + > +The bookkeeping of the updatable images is done through a structure > +called metadata. Currently, the FWU metadata supports identification > +of images based on image GUIDs stored on a GPT partitioned storage > +media. There are plans to extend the metadata structure for non GPT > +partitioned devices as well. > + > +Accessing the FWU metadata is done through generic API's which are > +defined in a driver which complies with the U-Boot's driver model. A > +new uclass UCLASS_FWU_MDATA has been added for accessing the FWU > +metadata. Individual drivers can be added based on the type of storage > +media, and it's partitioning method. Details of the storage device s/it's/its/ > +containing the FWU metadata partitions are specified through a U-Boot > +specific device tree property `fwu-mdata-store`. Please refer to > +U-Boot `doc `__ > +for the device tree bindings. > + > +Enabling the FWU Multi Bank Update feature > +-- > + > +The feature can be enabled by specifying the following configs:: > + > +CONFIG_EFI_CAPSULE_ON_DISK=y > +CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT=y > +CONFIG_EFI_CAPSULE_FIRMWARE=y CONFIG_EFI_CAPSULE_FIRMWARE is not needed. Selected by the above. > +CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y > + > +CONFIG_FWU_MULTI_BANK_UPDATE=y > +CONFIG_CMD_FWU_METADATA=y > +CONFIG_DM_FWU_MDATA=y Note also in efi_setup.c, CONFIG_FWU_MULTI_BANK_UPDATE enforces capsules are not checked at 1st EFI command. This means we need CONFIG_EFI_CAPSULE_ON_DISK_EARLY=y, if I'm right. > +CONFIG_FWU_MDATA_GPT_BLK=y > +CONFIG_FWU_NUM_BANKS= > +CONFIG_FWU_NUM_IMAGES_PER_BANK= > + > +in the .config file > + > +The first group of configuration settings enable the UEFI > +capsule-on-disk update functionality. The second group of configs > +enable the FWU Multi Bank Update functionality. Please refer to the > +section :ref:`uefi_capsule_update_ref` for more details on generation > +of the UEFI capsule. > + > +Setting up the device for GPT partitioned storage > +- > + > +Before enabling the functionality in U-Boot, a GPT partitioned storage > +device is required. Assuming a GPT partitioned storage device, the > +storage media needs to be partitioned with the correct number of > +partitions, given the number of banks and number of images per bank > +that the platform is going to support. Each updatable firmware image > +will be stored on an separate partition. In addition, the two copies s/an/a/ > +of the FWU metadata will be stored on two separate partitions. > + > +As an example, a platform supporting two banks with each bank > +containing three images would need to have 2 * 3 = 6 partitions plus > +the two metadata partitions, or 8 partitions. In addition the storage > +media can have additional partitions of non-updatable images, like the > +EFI System Partition(ESP), a partition for the root file system > +etc. An example list of images on the storage medium would be > + > +* FWU metadata 1 > +* U-Boot 1 > +* OP-TEE 1 > +* FWU metadata 2 > +* OP-TEE 2 > +* U-Boot 2 > +* ESP > +* rootfs > + > +When generating the partitions, a few aspects need to be taken care > +of.
[PULL] Pull request for u-boot next / v2022.10 = u-boot-stm32-20220927
Hi Tom, Please pull the STM32 related fixes for u-boot/next, v2022.10: u-boot-stm32-20220927 CI status: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/13610 Thanks Patrice The following changes since commit ebdd6afa543324648138f780a648b8fb65d488eb: Merge branch 'next' of https://source.denx.de/u-boot/custodians/u-boot-marvell into next (2022-09-20 08:50:07 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-stm.git tags/u-boot-stm32-20220927 for you to fetch changes up to 762d410e0db94c41b8d7f1ec85e47f7474655ad8: configs: increase SYS_MALLOC_F_LEN for STM32 MCU's board (2022-09-27 10:41:02 +0200) - Increase SYS_MALLOC_F_LEN for STM32 MCU's board - SPL fixes for STM32F7 MCUs - Device tree alignement with kernelv6.0-rc4 for MCU's board - Device tree alignement with kernelv6.0-rc3 for MPU's board - Update DDR node for STM32MP15 - Cleanup config file for STM32MP1 - Update for cmd_stm32key command - Fix compatible string to add partitions for STM32MP1 - Update for stm32programmer tool Christophe Kerello (1): board: st: stm32mp1: use of correct compatible string to add partitions Patrice Chotard (9): ARM: dts: stm32: DT sync with kernel v6.0-rc4 for MCU's boards configs: stm32f746-disco: Fix SPL boot configs: stm32f769-disco: Fix SPL boot configs: stm32746g-eval: Fix SPL boot configs: stm32f746-disco: Fix CONFIG_SYS_SPL_ARGS_ADDR configs: stm32746g-eval: Fix CONFIG_SYS_SPL_ARGS_ADDR configs: stm32f769-disco: Fix internal flash size configs: stm32f746-disco: Remove CONFIG_SYS_UBOOT_START flag configs: increase SYS_MALLOC_F_LEN for STM32 MCU's board Patrick Delaunay (12): stm32mp: stm32prog: support empty flashlayout stm32mp: stm32prog: change default flashlayout location to CONFIG_SYS_LOAD_ADDR stm32mp: stm32prog: solve warning for 64bits compilation stm32mp: stm32prog: correctly handle OTP when SMC is not supported ARM: dts: stm32mp: alignment with v6.0-rc3 stm32mp: stm32prog: improve the partitioning trace arm: stm32mp: add defines for BSEC_LOCK status in stm32key command arm: stm32mp: introduced read_close_status function in stm32key command arm: stm32mp: support several key in command stm32key arm: stm32mp: adapt the command stm32key for STM32MP13x configs: stm32mp1: cleanup config file ARM: dts: stm32mp15: update DDR node arch/arm/dts/stm32429i-eval-u-boot.dtsi| 2 +- arch/arm/dts/stm32746g-eval.dts| 18 +++--- arch/arm/dts/stm32f4-pinctrl.dtsi | 2 +- arch/arm/dts/stm32f429-disco-u-boot.dtsi | 8 ++--- arch/arm/dts/stm32f429-disco.dts | 20 --- arch/arm/dts/stm32f429-pinctrl.dtsi| 94 -- arch/arm/dts/stm32f429.dtsi| 69 +++-- arch/arm/dts/stm32f469-disco-u-boot.dtsi | 7 ++-- arch/arm/dts/stm32f469-disco.dts | 24 ++--- arch/arm/dts/stm32f469-pinctrl.dtsi| 96 +-- arch/arm/dts/stm32f7-pinctrl.dtsi | 2 +- arch/arm/dts/stm32f7-u-boot.dtsi | 2 +- arch/arm/dts/stm32f746-disco.dts | 12 +++ arch/arm/dts/stm32f746.dtsi| 67 +++- arch/arm/dts/stm32f769-disco.dts | 18 +++--- arch/arm/dts/stm32h743.dtsi| 19 -- arch/arm/dts/stm32h743i-disco.dts | 8 ++--- arch/arm/dts/stm32h743i-eval.dts | 8 ++--- arch/arm/dts/stm32h750i-art-pi.dts | 8 ++--- arch/arm/dts/stm32mp13-u-boot.dtsi | 10 +++--- arch/arm/dts/stm32mp131.dtsi | 28 +++ arch/arm/dts/stm32mp135f-dk.dts| 4 +-- arch/arm/dts/stm32mp15-ddr.dtsi| 16 + arch/arm/dts/stm32mp15-pinctrl.dtsi| 64 ++ arch/arm/dts/stm32mp15-u-boot.dtsi | 14 arch/arm/dts/stm32mp151.dtsi | 7 ++-- arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi | 1 - arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi | 1 - arch/arm/dts/stm32mp15xx-dkx.dtsi | 8 + arch/arm/include/asm/arch-stm32f7/stm32.h | 6 ++-- arch/arm/mach-stm32mp/cmd_stm32key.c | 331
Re: [PATCH v10 03/15] FWU: Add FWU metadata access driver for GPT partitioned block devices
Hey Etiennem
[...]
> > > > + uint *secondary_mpart)
> > > > +{
> > > > + int i, ret;
> > > > + u32 mdata_parts;
> > > > + efi_guid_t part_type_guid;
> > > > + struct disk_partition info;
> > > > + const efi_guid_t fwu_mdata_guid = FWU_MDATA_GUID;
> > > > +
> > > > + mdata_parts = 0;
> > > > + for (i = 1; i < MAX_SEARCH_PARTITIONS; i++) {
> > > > + if (part_get_info(desc, i, ))
> > > > + continue;
> > > > + uuid_str_to_bin(info.type_guid, part_type_guid.b,
> > > > + UUID_STR_FORMAT_GUID);
> > > > +
> > > > + if (!guidcmp(_mdata_guid, _type_guid)) {
> > > > + ++mdata_parts;
> > > > + if (!*primary_mpart)
> > > > + *primary_mpart = i;
> > > > + else
> > > > + *secondary_mpart = i;
> > > > + }
> > > > + }
> > > > +
> > > > + if (mdata_parts != 2) {
> > > > + log_debug("Expect two copies of the FWU metadata instead
> > > > of %d\n",
> > > > + mdata_parts);
> > > > + ret = -EINVAL;
> > > > + } else {
> > > > + ret = 0;
> > > > + }
> > >
> > > Can we change that a bit? There are are some assumptions in this code,
> > > e.g
> > > the user must pass the values zero'ed out. Can we instead get an array of
>
> I don't agree. If the function returns an error code, caller shall not
> use the output content.
> That is what callers of gpt_get_mdata_partitions() do in this patch,
> so returning -EINVAL if fine.
> (note that I don't mind this gets an array ref rather than 2 pointers).
Ah true. In any case I still think we should change to an array, imho it
would be much easier to read
>
> best regards,
> etienne
>
> > > 2 instead? In that case you don't care if any of the values are zero and
> > > you can just fill in the array. Something like:
> >
> > Okay, will make use of the array as you suggest.
> >
> > >
[...]
Regards
/Ilias
[PATCH] ARM: zynq: Define rtc alias on zc702/zc706
Define rtc alias on zc702/zc706 boards.
Signed-off-by: Michal Simek
---
arch/arm/dts/zynq-zc702.dts | 3 ++-
arch/arm/dts/zynq-zc706.dts | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/zynq-zc702.dts b/arch/arm/dts/zynq-zc702.dts
index 99ee87bb2453..f04129fd0429 100644
--- a/arch/arm/dts/zynq-zc702.dts
+++ b/arch/arm/dts/zynq-zc702.dts
@@ -18,6 +18,7 @@
mmc0 =
usb0 =
nvmem0 =
+ rtc0 =
};
memory@0 {
@@ -165,7 +166,7 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <4>;
- rtc@51 {
+ rtc: rtc@51 {
compatible = "nxp,pcf8563";
reg = <0x51>;
};
diff --git a/arch/arm/dts/zynq-zc706.dts b/arch/arm/dts/zynq-zc706.dts
index f0ad68d94f17..dd3ae83c82ed 100644
--- a/arch/arm/dts/zynq-zc706.dts
+++ b/arch/arm/dts/zynq-zc706.dts
@@ -17,6 +17,7 @@
spi0 =
mmc0 =
nvmem0 =
+ rtc0 =
};
memory@0 {
@@ -124,7 +125,7 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <4>;
- rtc@51 {
+ rtc: rtc@51 {
compatible = "nxp,pcf8563";
reg = <0x51>;
};
--
2.36.1
Re: [PATCH] configs: increase SYS_MALLOC_F_LEN for STM32 MCU's board
On 9/27/22 10:39, Patrick DELAUNAY wrote: > Hi, > > On 9/26/22 17:59, Patrice Chotard wrote: >> Some STM32 MCU's board need their SYS_MALLOC_F_LEN value enlarged >> to avoid the "alloc space exhausted" error message during their boot >> process. >> Use the default SYS_MALLOC_F_LEN value which is set to 0x2000 in >> Kconfig. >> >> Signed-off-by: Patrice Chotard >> --- >> >> configs/stm32746g-eval_defconfig | 1 - >> configs/stm32746g-eval_spl_defconfig | 1 - >> configs/stm32f429-discovery_defconfig | 1 - >> configs/stm32f429-evaluation_defconfig | 1 - >> configs/stm32f469-discovery_defconfig | 1 - >> configs/stm32f746-disco_defconfig | 1 - >> configs/stm32f746-disco_spl_defconfig | 1 - >> configs/stm32f769-disco_defconfig | 1 - >> configs/stm32f769-disco_spl_defconfig | 1 - >> configs/stm32h743-disco_defconfig | 1 - >> configs/stm32h743-eval_defconfig | 1 - >> configs/stm32h750-art-pi_defconfig | 1 - >> 12 files changed, 12 deletions(-) >> >> diff --git a/configs/stm32746g-eval_defconfig >> b/configs/stm32746g-eval_defconfig >> index 58232a7114..7200446d28 100644 >> --- a/configs/stm32746g-eval_defconfig >> +++ b/configs/stm32746g-eval_defconfig >> @@ -2,7 +2,6 @@ CONFIG_ARM=y >> CONFIG_ARCH_STM32=y >> CONFIG_SYS_TEXT_BASE=0x0800 >> CONFIG_SYS_MALLOC_LEN=0x10 >> -CONFIG_SYS_MALLOC_F_LEN=0xE00 >> CONFIG_NR_DRAM_BANKS=1 >> CONFIG_ENV_SIZE=0x2000 >> CONFIG_DEFAULT_DEVICE_TREE="stm32746g-eval" >> diff --git a/configs/stm32746g-eval_spl_defconfig >> b/configs/stm32746g-eval_spl_defconfig >> index 28f522b15e..ff42952a76 100644 >> --- a/configs/stm32746g-eval_spl_defconfig >> +++ b/configs/stm32746g-eval_spl_defconfig >> @@ -2,7 +2,6 @@ CONFIG_ARM=y >> CONFIG_ARCH_STM32=y >> CONFIG_SYS_TEXT_BASE=0x08009000 >> CONFIG_SYS_MALLOC_LEN=0x10 >> -CONFIG_SYS_MALLOC_F_LEN=0xE00 >> CONFIG_SPL_GPIO=y >> CONFIG_SPL_LIBCOMMON_SUPPORT=y >> CONFIG_SPL_LIBGENERIC_SUPPORT=y >> diff --git a/configs/stm32f429-discovery_defconfig >> b/configs/stm32f429-discovery_defconfig >> index e6e595d495..914ac14641 100644 >> --- a/configs/stm32f429-discovery_defconfig >> +++ b/configs/stm32f429-discovery_defconfig >> @@ -2,7 +2,6 @@ CONFIG_ARM=y >> CONFIG_ARCH_STM32=y >> CONFIG_SYS_TEXT_BASE=0x0800 >> CONFIG_SYS_MALLOC_LEN=0x020 >> -CONFIG_SYS_MALLOC_F_LEN=0xF00 >> CONFIG_NR_DRAM_BANKS=1 >> CONFIG_ENV_SIZE=0x2000 >> CONFIG_ENV_SECT_SIZE=0x2 >> diff --git a/configs/stm32f429-evaluation_defconfig >> b/configs/stm32f429-evaluation_defconfig >> index 073f27168a..af7a8bf076 100644 >> --- a/configs/stm32f429-evaluation_defconfig >> +++ b/configs/stm32f429-evaluation_defconfig >> @@ -2,7 +2,6 @@ CONFIG_ARM=y >> CONFIG_ARCH_STM32=y >> CONFIG_SYS_TEXT_BASE=0x0800 >> CONFIG_SYS_MALLOC_LEN=0x10 >> -CONFIG_SYS_MALLOC_F_LEN=0xF00 >> CONFIG_NR_DRAM_BANKS=1 >> CONFIG_ENV_SIZE=0x2000 >> CONFIG_DEFAULT_DEVICE_TREE="stm32429i-eval" >> diff --git a/configs/stm32f469-discovery_defconfig >> b/configs/stm32f469-discovery_defconfig >> index bd3693275e..90680fdb05 100644 >> --- a/configs/stm32f469-discovery_defconfig >> +++ b/configs/stm32f469-discovery_defconfig >> @@ -2,7 +2,6 @@ CONFIG_ARM=y >> CONFIG_ARCH_STM32=y >> CONFIG_SYS_TEXT_BASE=0x0800 >> CONFIG_SYS_MALLOC_LEN=0x10 >> -CONFIG_SYS_MALLOC_F_LEN=0xF00 >> CONFIG_NR_DRAM_BANKS=1 >> CONFIG_ENV_SIZE=0x2000 >> CONFIG_DEFAULT_DEVICE_TREE="stm32f469-disco" >> diff --git a/configs/stm32f746-disco_defconfig >> b/configs/stm32f746-disco_defconfig >> index ed537b0578..a8edf11b40 100644 >> --- a/configs/stm32f746-disco_defconfig >> +++ b/configs/stm32f746-disco_defconfig >> @@ -2,7 +2,6 @@ CONFIG_ARM=y >> CONFIG_ARCH_STM32=y >> CONFIG_SYS_TEXT_BASE=0x0800 >> CONFIG_SYS_MALLOC_LEN=0x10 >> -CONFIG_SYS_MALLOC_F_LEN=0xE00 >> CONFIG_NR_DRAM_BANKS=1 >> CONFIG_ENV_SIZE=0x2000 >> CONFIG_DEFAULT_DEVICE_TREE="stm32f746-disco" >> diff --git a/configs/stm32f746-disco_spl_defconfig >> b/configs/stm32f746-disco_spl_defconfig >> index d4a65bde24..0e358e86ff 100644 >> --- a/configs/stm32f746-disco_spl_defconfig >> +++ b/configs/stm32f746-disco_spl_defconfig >> @@ -2,7 +2,6 @@ CONFIG_ARM=y >> CONFIG_ARCH_STM32=y >> CONFIG_SYS_TEXT_BASE=0x08009000 >> CONFIG_SYS_MALLOC_LEN=0x10 >> -CONFIG_SYS_MALLOC_F_LEN=0xE00 >> CONFIG_SPL_GPIO=y >> CONFIG_SPL_LIBCOMMON_SUPPORT=y >> CONFIG_SPL_LIBGENERIC_SUPPORT=y >> diff --git a/configs/stm32f769-disco_defconfig >> b/configs/stm32f769-disco_defconfig >> index 5b5307ca1d..3e7b5bd06e 100644 >> --- a/configs/stm32f769-disco_defconfig >> +++ b/configs/stm32f769-disco_defconfig >> @@ -2,7 +2,6 @@ CONFIG_ARM=y >> CONFIG_ARCH_STM32=y >> CONFIG_SYS_TEXT_BASE=0x0800 >> CONFIG_SYS_MALLOC_LEN=0x10 >> -CONFIG_SYS_MALLOC_F_LEN=0xE00 >> CONFIG_NR_DRAM_BANKS=1 >> CONFIG_ENV_SIZE=0x2000 >> CONFIG_DEFAULT_DEVICE_TREE="stm32f769-disco" >> diff --git a/configs/stm32f769-disco_spl_defconfig >>
Re: [PATCH v10 07/15] FWU: STM32MP1: Add support to read boot index from backup register
On Thu, 15 Sept 2022 at 10:15, Sughosh Ganu wrote:
>
> The FWU Multi Bank Update feature allows the platform to boot the
> firmware images from one of the partitions(banks). The first stage
> bootloader(fsbl) passes the value of the boot index, i.e. the bank
> from which the firmware images were booted from to U-Boot. On the
> STM32MP157C-DK2 board, this value is passed through one of the SoC's
> backup register. Add a function to read the boot index value from the
> backup register.
>
> Signed-off-by: Sughosh Ganu
> Reviewed-by: Patrick Delaunay
> Acked-by: Ilias Apalodimas
> ---
> Changes since V9:
> * Change the fwu_plat_get_bootidx() function to take an uint * as the
> function parameter instead of the void * as suggested by Etienne.
>
> arch/arm/mach-stm32mp/include/mach/stm32.h | 5 +
> board/st/stm32mp1/stm32mp1.c | 23 ++
> include/fwu.h | 12 +++
> 3 files changed, 40 insertions(+)
>
> diff --git a/arch/arm/mach-stm32mp/include/mach/stm32.h
> b/arch/arm/mach-stm32mp/include/mach/stm32.h
> index c70375a723..c85ae6a34e 100644
> --- a/arch/arm/mach-stm32mp/include/mach/stm32.h
> +++ b/arch/arm/mach-stm32mp/include/mach/stm32.h
> @@ -112,11 +112,16 @@ enum boot_device {
> #ifdef CONFIG_STM32MP15x
> #define TAMP_BACKUP_MAGIC_NUMBER TAMP_BACKUP_REGISTER(4)
> #define TAMP_BACKUP_BRANCH_ADDRESS TAMP_BACKUP_REGISTER(5)
> +#define TAMP_FWU_BOOT_INFO_REG TAMP_BACKUP_REGISTER(10)
> #define TAMP_COPRO_RSC_TBL_ADDRESS TAMP_BACKUP_REGISTER(17)
> #define TAMP_COPRO_STATE TAMP_BACKUP_REGISTER(18)
> #define TAMP_BOOT_CONTEXT TAMP_BACKUP_REGISTER(20)
> #define TAMP_BOOTCOUNT TAMP_BACKUP_REGISTER(21)
>
> +#define TAMP_FWU_BOOT_IDX_MASK GENMASK(3, 0)
> +
> +#define TAMP_FWU_BOOT_IDX_OFFSET 0
> +
> #define TAMP_COPRO_STATE_OFF 0
> #define TAMP_COPRO_STATE_INIT 1
> #define TAMP_COPRO_STATE_CRUN 2
> diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
> index 6562bcf95b..54b9535405 100644
> --- a/board/st/stm32mp1/stm32mp1.c
> +++ b/board/st/stm32mp1/stm32mp1.c
> @@ -960,3 +960,26 @@ static void board_copro_image_process(ulong fw_image,
> size_t fw_size)
> }
>
> U_BOOT_FIT_LOADABLE_HANDLER(IH_TYPE_COPRO, board_copro_image_process);
> +
> +#if defined(CONFIG_FWU_MULTI_BANK_UPDATE)
> +
> +#include
> +
> +/**
> + * fwu_plat_get_bootidx() - Get the value of the boot index
> + * @boot_idx: Boot index value
> + *
> + * Get the value of the bank(partition) from which the platform
> + * has booted. This value is passed to U-Boot from the earlier
> + * stage bootloader which loads and boots all the relevant
> + * firmware images
> + *
> + */
> +void fwu_plat_get_bootidx(uint *boot_idx)
> +{
> + u32 *bootidx = boot_idx;
> +
> + *bootidx = (readl(TAMP_FWU_BOOT_INFO_REG) >>
> + TAMP_FWU_BOOT_IDX_OFFSET) & TAMP_FWU_BOOT_IDX_MASK;
> +}
I may be nitpicking but despite this is fine in this source file build
only for 32bit, I think the cast is not that clean.
Would prefer:
void fwu_plat_get_bootidx(uint *boot_idx)
{
*boot_idx = (readl(TAMP_FWU_BOOT_INFO_REG) >>
TAMP_FWU_BOOT_IDX_OFFSET) & TAMP_FWU_BOOT_IDX_MASK;
}
br,
etienne
> +#endif /* CONFIG_FWU_MULTI_BANK_UPDATE */
> diff --git a/include/fwu.h b/include/fwu.h
> index 3ff37c628b..484289ed4f 100644
> --- a/include/fwu.h
> +++ b/include/fwu.h
> @@ -244,4 +244,16 @@ int fwu_plat_get_alt_num(struct udevice *dev, efi_guid_t
> *image_guid,
> *
> */
> int fwu_plat_get_update_index(uint *update_idx);
> +
> +/**
> + * fwu_plat_get_bootidx() - Get the value of the boot index
> + * @boot_idx: Boot index value
> + *
> + * Get the value of the bank(partition) from which the platform
> + * has booted. This value is passed to U-Boot from the earlier
> + * stage bootloader which loads and boots all the relevant
> + * firmware images
> + *
> + */
> +void fwu_plat_get_bootidx(uint *boot_idx);
> #endif /* _FWU_H_ */
> --
> 2.34.1
>
Re: [PATCH v10 03/15] FWU: Add FWU metadata access driver for GPT partitioned block devices
Hello Sughosh and all,
On Mon, 26 Sept 2022 at 10:46, Sughosh Ganu wrote:
>
> hi Ilias,
>
> On Thu, 22 Sept 2022 at 14:16, Ilias Apalodimas
> wrote:
> >
> > Hi Sughosh
> >
> > On Thu, Sep 15, 2022 at 01:44:39PM +0530, Sughosh Ganu wrote:
> > > In the FWU Multi Bank Update feature, the information about the
> > > updatable images is stored as part of the metadata, on a separate
> > > partition. Add a driver for reading from and writing to the metadata
> > > when the updatable images and the metadata are stored on a block
> > > device which is formatted with GPT based partition scheme.
> > >
> > > Signed-off-by: Sughosh Ganu
> > > Reviewed-by: Patrick Delaunay
> > > Reviewed-by: Etienne Carriere
> > > ---
> > > Changes since V9:
> > > * s/formated/formatted in the commit message
> > > * Add a '\n' character in the log message
> > >
> > > drivers/fwu-mdata/Kconfig | 16 ++
> > > drivers/fwu-mdata/Makefile | 8 +
> > > drivers/fwu-mdata/gpt_blk.c | 378
> > > include/fwu.h | 4 +
> > > 4 files changed, 406 insertions(+)
> > > create mode 100644 drivers/fwu-mdata/Kconfig
> > > create mode 100644 drivers/fwu-mdata/Makefile
> > > create mode 100644 drivers/fwu-mdata/gpt_blk.c
> > >
> > > diff --git a/drivers/fwu-mdata/Kconfig b/drivers/fwu-mdata/Kconfig
> > > new file mode 100644
> > > index 00..7322da48b1
> > > --- /dev/null
> > > +++ b/drivers/fwu-mdata/Kconfig
> > > @@ -0,0 +1,16 @@
> > > +config FWU_MDATA
> > > + bool "Driver support for accessing FWU Metadata"
> > > + depends on DM
> > > + help
> > > + Enable support for accessing FWU Metadata partitions. The
> > > + FWU Metadata partitions reside on the same storage device
> > > + which contains the other FWU updatable firmware images.
> > > +
> > > +config FWU_MDATA_GPT_BLK
> > > + bool "FWU Metadata access for GPT partitioned Block devices"
> > > + select PARTITION_TYPE_GUID
> > > + select PARTITION_UUIDS
> > > + depends on DM && HAVE_BLOCK_DEVICE && EFI_PARTITION
> > > + help
> > > + Enable support for accessing FWU Metadata on GPT partitioned
> > > + block devices.
By the way, drop HAVE_BLOCK_DEVICE that is no more needed here.
See
https://source.denx.de/u-boot/u-boot/-/commit/7f8967c2b82f9917987b69fbf43f8f591f3a8516
> > > diff --git a/drivers/fwu-mdata/Makefile b/drivers/fwu-mdata/Makefile
> > > new file mode 100644
> > > index 00..3fee64c10c
> > > --- /dev/null
> > > +++ b/drivers/fwu-mdata/Makefile
> > > @@ -0,0 +1,8 @@
> > > +# SPDX-License-Identifier: GPL-2.0-or-later
> > > +#
> > > +# Copyright (c) 2022, Linaro Limited
> > > +#
> > > +
> > > +
> > > +obj-$(CONFIG_FWU_MDATA) += fwu-mdata-uclass.o
> > > +obj-$(CONFIG_FWU_MDATA_GPT_BLK) += gpt_blk.o
> > > diff --git a/drivers/fwu-mdata/gpt_blk.c b/drivers/fwu-mdata/gpt_blk.c
> > > new file mode 100644
> > > index 00..df115575e0
> > > --- /dev/null
> > > +++ b/drivers/fwu-mdata/gpt_blk.c
> > > @@ -0,0 +1,378 @@
> > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > +/*
> > > + * Copyright (c) 2022, Linaro Limited
> > > + */
> > > +
> > > +#define LOG_CATEGORY UCLASS_FWU_MDATA
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#define PRIMARY_PART BIT(0)
> > > +#define SECONDARY_PART BIT(1)
> > > +#define BOTH_PARTS (PRIMARY_PART | SECONDARY_PART)
> > > +
> > > +#define MDATA_READ BIT(0)
> > > +#define MDATA_WRITE BIT(1)
> > > +
> > > +static int gpt_get_mdata_partitions(struct blk_desc *desc,
> > > + uint *primary_mpart,
> > > + uint *secondary_mpart)
> > > +{
> > > + int i, ret;
> > > + u32 mdata_parts;
> > > + efi_guid_t part_type_guid;
> > > + struct disk_partition info;
> > > + const efi_guid_t fwu_mdata_guid = FWU_MDATA_GUID;
> > > +
> > > + mdata_parts = 0;
> > > + for (i = 1; i < MAX_SEARCH_PARTITIONS; i++) {
> > > + if (part_get_info(desc, i, ))
> > > + continue;
> > > + uuid_str_to_bin(info.type_guid, part_type_guid.b,
> > > + UUID_STR_FORMAT_GUID);
> > > +
> > > + if (!guidcmp(_mdata_guid, _type_guid)) {
> > > + ++mdata_parts;
> > > + if (!*primary_mpart)
> > > + *primary_mpart = i;
> > > + else
> > > + *secondary_mpart = i;
> > > + }
> > > + }
> > > +
> > > + if (mdata_parts != 2) {
> > > + log_debug("Expect two copies of the FWU metadata instead of
> > > %d\n",
> > > + mdata_parts);
> > > + ret = -EINVAL;
> > > + } else {
> > > +
Re: [PATCH] fs: btrfs: remove the usage of undeclared fs_mutex variable
> Which branch is the code based on?
>
I actually cloned it from u-boot github master.
https://github.com/u-boot/u-boot/blob/f117c54cc83e3c519883edb5a48062644d38c443/fs/btrfs/disk-io.c#L785
> I don't believe it's upstream, as such compiling error should be exposed
> very easily.
>
Actually, I was also surprised but the compiler did not give me any error
because the mutex definition was as follows:
#define mutex_init(...)
and the compiler did not generate any error because we don't do anything
the parameter.
>> ---
>> fs/btrfs/disk-io.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
>
> Furthermore at current upstream HEAD a1375562c0a8 ("Merge tag
> 'x86_urgent_for_v6.0-rc8' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip"), there is no
> btrfs_new_fs_info() function defined anyway.
>
Hmm, I sent these patches for u-boot. Maybe there is a misunderstanding
here? :)
> THanks,
> Qu
>
>> index 8043abc1bd..c80f8e8028 100644
>> --- a/fs/btrfs/disk-io.c
>> +++ b/fs/btrfs/disk-io.c
>> @@ -782,8 +782,6 @@ struct btrfs_fs_info *btrfs_new_fs_info(void)
>> fs_info->fs_root_tree = RB_ROOT;
>> cache_tree_init(_info->mapping_tree.cache_tree);
>> - mutex_init(_info->fs_mutex);
>> -
>> return fs_info;
>> free_all:
>> btrfs_free_fs_info(fs_info);
[PATCH] fs: btrfs: remove the usage of undeclared fs_mutex variable
This line probably got in by mistake as there is no fs_mutex member in the btrfs_fs_info struct. Signed-off-by: Pankaj Raghav --- fs/btrfs/disk-io.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index 8043abc1bd..c80f8e8028 100644 --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -782,8 +782,6 @@ struct btrfs_fs_info *btrfs_new_fs_info(void) fs_info->fs_root_tree = RB_ROOT; cache_tree_init(_info->mapping_tree.cache_tree); - mutex_init(_info->fs_mutex); - return fs_info; free_all: btrfs_free_fs_info(fs_info); -- 2.25.1
Re: [PATCH] usb: common: Detect USB storage media with "miscellaneous" USB devices
On 26. Sep 2022, at 01:45, Marek Vasut wrote: > > On 9/25/22 16:46, Christian Kohlschütter wrote: >> When detecting USB storage devices, we currently skip everything that is >> not marked as "undefined device class". >> Composite devices such as tinyusb's CDC+MSC identify as "miscellaneous" >> (class 0xEF). >> Introduce a new constant, USB_CLASS_MISC (0xEF), and allow the detection >> process to proceed for USB devices with this device class. > > What does Linux do with such a device , is there a specific quirk or does it > simply not check the bDeviceClass at all ? I didn't see any relevant checks in drivers/usb/storage, however changing the bDeviceClass from "MISC" (0xEF) to "UNSPECIFIED"/"PER_INTERFACE" (0x00) causes the device to be no longer detected by either Linux or macOS, but it would work with U-Boot (i.e., without the change). macOS' USB prober would report the USB device as "unconfigured". On Linux, using usbutils but not busybox, lsusb would actually hang. I think it's a good idea to keep the set of permitted device classes to a minimum (0x00 / 0xEF) and abort early in all other cases. This way, we can skip the more elaborate checks in usb_storage_probe for devices that are definitely not supported.
Re: [PATCH] rockchip: rk3399: add ethaddr and serial# init, enable for R4S
> On 26. Sep 2022, at 13:59, Chen-Yu Tsai wrote: > > On Mon, Sep 26, 2022 at 7:53 PM Christian Kohlschütter > wrote: >> >> Some RK3399 boards, such as newer revisions of NanoPi R4S, do not >> provide an EEPROM chip containing a globally unique MAC address. >> >> Currently, this means that a randomly generated temporary MAC address >> may be generated each time the device is rebooted, leading to ARP cache >> issues and other confusing bugs. >> >> Since RK3399 CPUs provide a built-in unique serial number, we can >> reliably derive a locally MAC address from it by reading the >> corresponding bits from the non-secure efuse block. >> >> Port from uboot-rockchip 0c294d0, fix compilation issues and adjust >> coding style. >> >> rockchip: board: puma_rk3399: derive ethaddr from cpuid >> rockchip: board: puma_rk3399: add support for serial# and cpuid# >> rockchip: efuse: add (misc) driver for RK3399 non-secure efuse block >> via efuses >> >> Signed-off-by: Christian Kohlschütter >> --- >> board/rockchip/evb_rk3399/evb-rk3399.c | 120 + >> configs/nanopi-r4s-rk3399_defconfig| 4 + >> drivers/misc/Makefile | 2 +- > > There's already code in arch/arm/mach-rockchip/misc.c that does pretty much > the same thing. > > IIRC all you need to do is enable MISC_INIT_R and ROCKCHIP_EFUSE > or ROCKCHIP_OTP. > > ChenYu Oh cool, thanks ChenYu! Is there a reason to not enable these options by default (at least for the R4S)? Following up with "[PATCH] rockchip: rk3399: add ethaddr and serial# init, enable for R4S", which enables these settings in configs/nanopi-r4s-rk3399_defconfig. Cheers, Christian
[PATCH] rockchip: rk3399: add ethaddr and serial# init, enable for R4S
Some RK3399 boards, such as newer revisions of NanoPi R4S, do not
provide an EEPROM chip containing a globally unique MAC address.
Currently, this means that a randomly generated temporary MAC address
may be generated each time the device is rebooted, leading to ARP cache
issues and other confusing bugs.
Since RK3399 CPUs provide a built-in unique serial number, we can
reliably derive a locally MAC address from it by reading the
corresponding bits from the non-secure efuse block.
Port from uboot-rockchip 0c294d0, fix compilation issues and adjust
coding style.
rockchip: board: puma_rk3399: derive ethaddr from cpuid
rockchip: board: puma_rk3399: add support for serial# and cpuid#
rockchip: efuse: add (misc) driver for RK3399 non-secure efuse block
via efuses
Signed-off-by: Christian Kohlschütter
---
board/rockchip/evb_rk3399/evb-rk3399.c | 120 +
configs/nanopi-r4s-rk3399_defconfig| 4 +
drivers/misc/Makefile | 2 +-
3 files changed, 125 insertions(+), 1 deletion(-)
diff --git a/board/rockchip/evb_rk3399/evb-rk3399.c
b/board/rockchip/evb_rk3399/evb-rk3399.c
index abb76585cf..ab8738ccf3 100644
--- a/board/rockchip/evb_rk3399/evb-rk3399.c
+++ b/board/rockchip/evb_rk3399/evb-rk3399.c
@@ -5,11 +5,20 @@
#include
#include
+#include
+#include
+#include
+#include
#include
#include
#include
+#include
+#include
#include
+#define RK3399_CPUID_OFF 0x7
+#define RK3399_CPUID_LEN 0x10
+
#ifndef CONFIG_SPL_BUILD
int board_early_init_f(void)
{
@@ -30,3 +39,114 @@ out:
return 0;
}
#endif
+static void setup_macaddr(void)
+{
+ if (!IS_ENABLED(CONFIG_CMD_NET))
+ return;
+
+ int ret;
+ const char *cpuid = env_get("cpuid#");
+ u8 hash[SHA256_SUM_LEN];
+ int size = sizeof(hash);
+ u8 mac_addr[6];
+
+ /* Only generate a MAC address if none is set in the environment */
+ if (env_get("ethaddr"))
+ return;
+
+ if (!cpuid) {
+ debug("%s: could not retrieve 'cpuid#'\n", __func__);
+ return;
+ }
+
+ ret = hash_block("sha256", (void *)cpuid, strlen(cpuid), hash, );
+ if (ret) {
+ debug("%s: failed to calculate SHA256\n", __func__);
+ return;
+ }
+
+ /* Copy 6 bytes of the hash to base the MAC address on */
+ memcpy(mac_addr, hash, 6);
+
+ /* Make this a valid MAC address and set it */
+ mac_addr[0] &= 0xfe; /* clear multicast bit */
+ mac_addr[0] |= 0x02; /* set local assignment bit (IEEE802) */
+ eth_env_set_enetaddr("ethaddr", mac_addr);
+}
+
+static void setup_serial(void)
+{
+ if (!IS_ENABLED(CONFIG_ROCKCHIP_EFUSE))
+ return;
+
+ struct udevice *dev;
+ int ret, i;
+ u8 cpuid[RK3399_CPUID_LEN];
+ u8 low[RK3399_CPUID_LEN / 2], high[RK3399_CPUID_LEN / 2];
+ char cpuid_str[RK3399_CPUID_LEN * 2 + 1];
+ u64 serialno;
+ char serialno_str[16];
+
+ /* retrieve the device */
+ ret = uclass_get_device_by_driver(UCLASS_MISC,
+ DM_DRIVER_GET(rockchip_efuse), );
+ if (ret) {
+ debug("%s: could not find efuse device\n", __func__);
+ return;
+ }
+
+ /* read the cpu_id range from the efuses */
+ ret = misc_read(dev, RK3399_CPUID_OFF, , sizeof(cpuid));
+ if (ret) {
+ debug("%s: reading cpuid from the efuses failed\n",
+ __func__);
+ return;
+ }
+
+ memset(cpuid_str, 0, sizeof(cpuid_str));
+ for (i = 0; i < 16; i++)
+ sprintf(_str[i * 2], "%02x", cpuid[i]);
+
+ debug("cpuid: %s\n", cpuid_str);
+
+ /*
+* Mix the cpuid bytes using the same rules as in
+* ${linux}/drivers/soc/rockchip/rockchip-cpuinfo.c
+*/
+ for (i = 0; i < 8; i++) {
+ low[i] = cpuid[1 + (i << 1)];
+ high[i] = cpuid[i << 1];
+ }
+
+ serialno = crc32_no_comp(0, low, 8);
+ serialno |= (u64)crc32_no_comp(serialno, high, 8) << 32;
+ snprintf(serialno_str, sizeof(serialno_str), "%llx", serialno);
+
+ env_set("cpuid#", cpuid_str);
+ env_set("serial#", serialno_str);
+}
+
+int misc_init_r(void)
+{
+ setup_serial();
+ setup_macaddr();
+
+ return 0;
+}
+
+void get_board_serial(struct tag_serialnr *serialnr)
+{
+ u64 serial = 0;
+
+ if (IS_ENABLED(CONFIG_SERIAL_TAG)) {
+ char *serial_string;
+
+ serial_string = env_get("serial#");
+
+ if (serial_string)
+ serial = simple_strtoull(serial_string, NULL, 16);
+ }
+
+ serialnr->high = (u32)(serial >> 32);
+ serialnr->low = (u32)(serial & 0x);
+}
diff --git a/configs/nanopi-r4s-rk3399_defconfig
b/configs/nanopi-r4s-rk3399_defconfig
index 46ba07f4d5..aa89ac5854 100644
---
Re: [PATCH v4 1/1] blk: Rename if_type to uclass_id
Use the word 'uclass' instead of 'if_type' to complete the conversion. Signed-off-by: Simon Glass --- Changes in v4: - Fix comments from Takahiro Akashi missed on the previous revision Changes in v3: - Drop previously applied patches - Rebase on -next after EFI changes Changes in v2: - Use conv_uclass_id() instead of the confusing uclass_id_to_uclass_id() board/st/common/stm32mp_dfu.c | 2 +- cmd/bcb.c | 4 +- cmd/blk_common.c | 18 ++--- cmd/lsblk.c | 2 +- cmd/mmc.c | 4 +- common/spl/spl_sata.c | 2 +- common/spl/spl_usb.c | 2 +- common/usb_storage.c | 6 +- disk/disk-uclass.c| 8 +- disk/part.c | 14 ++-- doc/usage/partitions.rst | 2 +- drivers/ata/sata.c| 2 +- drivers/block/blk-uclass.c| 145 +- drivers/block/blk_legacy.c| 58 +++--- drivers/block/ide.c | 8 +- drivers/block/sandbox.c | 8 +- drivers/mmc/mmc-uclass.c | 2 +- drivers/mmc/mmc_legacy.c | 8 +- drivers/net/fsl_enetc.c | 12 +-- drivers/net/fsl_enetc.h | 2 +- drivers/scsi/scsi.c | 6 +- drivers/virtio/virtio_blk.c | 2 +- drivers/xen/pvblock.c | 2 +- fs/fat/fat.c | 2 +- include/blk.h | 122 ++-- include/efi_loader.h | 4 +- lib/efi_loader/efi_disk.c | 12 +-- lib/efi_loader/efi_var_file.c | 4 +- 28 files changed, 231 insertions(+), 232 deletions(-) Applied to u-boot-dm, thanks!
[PATCH] board: altera: c5/a10/a5/stratix10: remove Chin Liang as maintainer
Chin Liang is no longer actively maintaining this project. Signed-off-by: Dinh Nguyen --- board/altera/arria10-socdk/MAINTAINERS | 1 - board/altera/arria5-socdk/MAINTAINERS| 1 - board/altera/cyclone5-socdk/MAINTAINERS | 1 - board/altera/stratix10-socdk/MAINTAINERS | 1 - 4 files changed, 4 deletions(-) diff --git a/board/altera/arria10-socdk/MAINTAINERS b/board/altera/arria10-socdk/MAINTAINERS index 5a76efb54b..e288584362 100644 --- a/board/altera/arria10-socdk/MAINTAINERS +++ b/board/altera/arria10-socdk/MAINTAINERS @@ -1,6 +1,5 @@ SOCFPGA BOARD M: Dinh Nguyen -M: Chin-Liang See S: Maintained F: board/altera/arria10-socdk/ F: include/configs/socfpga_arria10_socdk.h diff --git a/board/altera/arria5-socdk/MAINTAINERS b/board/altera/arria5-socdk/MAINTAINERS index 873ec2be2d..a6c5bc8024 100644 --- a/board/altera/arria5-socdk/MAINTAINERS +++ b/board/altera/arria5-socdk/MAINTAINERS @@ -1,6 +1,5 @@ SOCFPGA BOARD M: Dinh Nguyen -M: Chin-Liang See S: Maintained F: board/altera/arria5-socdk/ F: include/configs/socfpga_arria5_socdk.h diff --git a/board/altera/cyclone5-socdk/MAINTAINERS b/board/altera/cyclone5-socdk/MAINTAINERS index ecf1d04f76..6a8dfdd286 100644 --- a/board/altera/cyclone5-socdk/MAINTAINERS +++ b/board/altera/cyclone5-socdk/MAINTAINERS @@ -1,6 +1,5 @@ SOCFPGA BOARD M: Dinh Nguyen -M: Chin-Liang See S: Maintained F: board/altera/cyclone5-socdk/ F: include/configs/socfpga_cyclone5_socdk.h diff --git a/board/altera/stratix10-socdk/MAINTAINERS b/board/altera/stratix10-socdk/MAINTAINERS index 6efd0cfc05..0b475980dd 100644 --- a/board/altera/stratix10-socdk/MAINTAINERS +++ b/board/altera/stratix10-socdk/MAINTAINERS @@ -1,6 +1,5 @@ SOCFPGA BOARD M: Chin-Liang See -M: Dinh Nguyen S: Maintained F: board/altera/stratix10-socdk/ F: include/configs/socfpga_stratix10_socdk.h -- 2.25.1
Re: [PATCH] configs: socfpga: Add CONFIG_NET_RANDOM_ETHADDR=y to SOCFPGA defconfig
On 9/25/22 09:37, teik.heng.ch...@intel.com wrote: From: Tien Fong Chee Ethernet initialization is only work with properly set MAC addresses. Hence, this config is required to create the random MAC addresses for Ethernet initialization. Signed-off-by: Tien Fong Chee Signed-off-by: Teik Heng Chong --- configs/socfpga_arria10_defconfig | 1 + configs/socfpga_arria5_defconfig | 1 + configs/socfpga_cyclone5_defconfig | 1 + 3 files changed, 3 insertions(+) diff --git a/configs/socfpga_arria10_defconfig b/configs/socfpga_arria10_defconfig index 3eac3dfa5d..53c01ff659 100644 --- a/configs/socfpga_arria10_defconfig +++ b/configs/socfpga_arria10_defconfig @@ -60,6 +60,7 @@ CONFIG_PHY_MICREL=y CONFIG_PHY_MICREL_KSZ90X1=y CONFIG_ETH_DESIGNWARE=y CONFIG_MII=y +CONFIG_NET_RANDOM_ETHADDR=y CONFIG_SPI=y CONFIG_TIMER=y CONFIG_SPL_TIMER=y diff --git a/configs/socfpga_arria5_defconfig b/configs/socfpga_arria5_defconfig index dbadb3d49a..da25aa9154 100644 --- a/configs/socfpga_arria5_defconfig +++ b/configs/socfpga_arria5_defconfig @@ -63,6 +63,7 @@ CONFIG_PHY_MICREL=y CONFIG_PHY_MICREL_KSZ90X1=y CONFIG_ETH_DESIGNWARE=y CONFIG_MII=y +CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DM_RESET=y CONFIG_SPI=y CONFIG_CADENCE_QSPI=y diff --git a/configs/socfpga_cyclone5_defconfig b/configs/socfpga_cyclone5_defconfig index 4fd14d2e2c..508bfe31fc 100644 --- a/configs/socfpga_cyclone5_defconfig +++ b/configs/socfpga_cyclone5_defconfig @@ -64,6 +64,7 @@ CONFIG_PHY_MICREL=y CONFIG_PHY_MICREL_KSZ90X1=y CONFIG_ETH_DESIGNWARE=y CONFIG_MII=y +CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DM_RESET=y CONFIG_SPI=y CONFIG_CADENCE_QSPI=y Acked-by: Dinh Nguyen
[PATCH v3 3/3] net: emaclite: fix handling for IP packets with specific lengths
From: Samuel Obuch
The maximum length is capped similarly to the emaclite_send function.
Avoid integer underflow for values of ip->ip_len < 30, the minimum
length of an IP packet is 21 bytes.
Signed-off-by: Samuel Obuch
---
drivers/net/xilinx_emaclite.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
index a4851ad36f..16ba915fba 100644
--- a/drivers/net/xilinx_emaclite.c
+++ b/drivers/net/xilinx_emaclite.c
@@ -517,6 +517,8 @@ try_again:
length = ntohs(ip->ip_len);
length += ETHER_HDR_SIZE + ETH_FCS_LEN;
debug("IP Packet %x\n", length);
+ if (length > PKTSIZE)
+ length = PKTSIZE;
break;
default:
debug("Other Packet\n");
@@ -525,7 +527,7 @@ try_again:
}
/* Read the rest of the packet which is longer then first read */
- if (length != first_read)
+ if (length > first_read)
xemaclite_alignedread(addr + first_read,
etherrxbuff + first_read,
length - first_read);
--
2.31.1
[PATCH v3 1/3] net: emaclite: enable for more architectures
From: Samuel Obuch Function ioremap_nocache seems to be defined only for MIPS and Microblaze architectures. Therefore, the function call in the emaclite driver causes this driver to be unusable with other architectures, for example RISC-V. Use ioremap function instead of ioremap_nocache, and include linux/io.h instead of asm/io.h, so that ioremap function is automatically created, if not defined by the architecture. We can switch to the ioremap function, as Microblaze's ioremap_nocache is just empty and in MIPS implementations of ioremap_nocache and ioremap are the same. Signed-off-by: Samuel Obuch --- v3: Fix commit message, remove addtional asm/io.h include. v2: Use ioremap instead of ioremap_nocache, switch to linux/io.h. v1: Do not use ioremap_nocache for archs other than MIPS and Microblaze. drivers/net/xilinx_emaclite.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c index 6c9f1f7c27..29e8271c63 100644 --- a/drivers/net/xilinx_emaclite.c +++ b/drivers/net/xilinx_emaclite.c @@ -14,14 +14,13 @@ #include #include #include -#include #include #include #include #include #include +#include #include -#include #include DECLARE_GLOBAL_DATA_PTR; @@ -615,8 +614,8 @@ static int emaclite_of_to_plat(struct udevice *dev) int offset = 0; pdata->iobase = dev_read_addr(dev); - emaclite->regs = (struct emaclite_regs *)ioremap_nocache(pdata->iobase, -0x1); + emaclite->regs = (struct emaclite_regs *)ioremap(pdata->iobase, +0x1); emaclite->phyaddr = -1; -- 2.31.1
[PATCH v3 2/3] net: emaclite: fix xemaclite_alignedread/write functions
From: Samuel Obuch
Use __raw_read* and __raw_write* functions to ensure read/write
is passed to the memory-mapped regions, as non-volatile accesses
may get optimised out.
Signed-off-by: Samuel Obuch
---
drivers/net/xilinx_emaclite.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
index 29e8271c63..a4851ad36f 100644
--- a/drivers/net/xilinx_emaclite.c
+++ b/drivers/net/xilinx_emaclite.c
@@ -112,12 +112,12 @@ static void xemaclite_alignedread(u32 *srcptr, void
*destptr, u32 bytecount)
/* Word aligned buffer, no correction needed. */
to32ptr = (u32 *) destptr;
while (bytecount > 3) {
- *to32ptr++ = *from32ptr++;
+ *to32ptr++ = __raw_readl(from32ptr++);
bytecount -= 4;
}
to8ptr = (u8 *) to32ptr;
- alignbuffer = *from32ptr++;
+ alignbuffer = __raw_readl(from32ptr++);
from8ptr = (u8 *)
for (i = 0; i < bytecount; i++)
@@ -135,8 +135,7 @@ static void xemaclite_alignedwrite(void *srcptr, u32
*destptr, u32 bytecount)
from32ptr = (u32 *) srcptr;
while (bytecount > 3) {
-
- *to32ptr++ = *from32ptr++;
+ __raw_writel(*from32ptr++, to32ptr++);
bytecount -= 4;
}
@@ -147,7 +146,7 @@ static void xemaclite_alignedwrite(void *srcptr, u32
*destptr, u32 bytecount)
for (i = 0; i < bytecount; i++)
*to8ptr++ = *from8ptr++;
- *to32ptr++ = alignbuffer;
+ __raw_writel(alignbuffer, to32ptr++);
}
static int wait_for_bit(const char *func, u32 *reg, const u32 mask,
--
2.31.1
Re: [PATCH] fs: btrfs: remove the usage of undeclared fs_mutex variable
On 2022/9/27 18:49, Pankaj Raghav wrote:
Which branch is the code based on?
I actually cloned it from u-boot github master.
https://github.com/u-boot/u-boot/blob/f117c54cc83e3c519883edb5a48062644d38c443/fs/btrfs/disk-io.c#L785
I don't believe it's upstream, as such compiling error should be exposed
very easily.
Actually, I was also surprised but the compiler did not give me any error
because the mutex definition was as follows:
#define mutex_init(...)
and the compiler did not generate any error because we don't do anything
the parameter.
---
fs/btrfs/disk-io.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
Furthermore at current upstream HEAD a1375562c0a8 ("Merge tag
'x86_urgent_for_v6.0-rc8' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip"), there is no
btrfs_new_fs_info() function defined anyway.
Hmm, I sent these patches for u-boot. Maybe there is a misunderstanding
here? :)
Yeah, you're completely right, I thought it's for kernel by default...
Sorry for the confusion.
Qu
THanks,
Qu
index 8043abc1bd..c80f8e8028 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -782,8 +782,6 @@ struct btrfs_fs_info *btrfs_new_fs_info(void)
fs_info->fs_root_tree = RB_ROOT;
cache_tree_init(_info->mapping_tree.cache_tree);
- mutex_init(_info->fs_mutex);
-
return fs_info;
free_all:
btrfs_free_fs_info(fs_info);
Re: [PATCH] fs: btrfs: remove the usage of undeclared fs_mutex variable
On 2022/9/27 18:39, Qu Wenruo wrote:
On 2022/9/27 17:55, Pankaj Raghav wrote:
This line probably got in by mistake as there is no fs_mutex member in
the btrfs_fs_info struct.
Signed-off-by: Pankaj Raghav
Which branch is the code based on?
I don't believe it's upstream, as such compiling error should be exposed
very easily.
---
fs/btrfs/disk-io.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
Furthermore at current upstream HEAD a1375562c0a8 ("Merge tag
'x86_urgent_for_v6.0-rc8' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip"), there is no
btrfs_new_fs_info() function defined anyway.
My bad, I didn't notice it's for Uboot, not kernel.
In that case, you can safely remove it, but it won't cause compile error
since in , we define mutex_init() as noop, thus it
doesn't cause any compile error.
Anyway the patch itself looks good, I also checked if there is other
mutex related usage, and this is the only one.
Reviewed-by: Qu Wenruo
Thanks,
Qu
THanks,
Qu
index 8043abc1bd..c80f8e8028 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -782,8 +782,6 @@ struct btrfs_fs_info *btrfs_new_fs_info(void)
fs_info->fs_root_tree = RB_ROOT;
cache_tree_init(_info->mapping_tree.cache_tree);
- mutex_init(_info->fs_mutex);
-
return fs_info;
free_all:
btrfs_free_fs_info(fs_info);
Re: [PATCH] fs: btrfs: remove the usage of undeclared fs_mutex variable
On 2022/9/27 17:55, Pankaj Raghav wrote:
This line probably got in by mistake as there is no fs_mutex member in
the btrfs_fs_info struct.
Signed-off-by: Pankaj Raghav
Which branch is the code based on?
I don't believe it's upstream, as such compiling error should be exposed
very easily.
---
fs/btrfs/disk-io.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
Furthermore at current upstream HEAD a1375562c0a8 ("Merge tag
'x86_urgent_for_v6.0-rc8' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip"), there is no
btrfs_new_fs_info() function defined anyway.
THanks,
Qu
index 8043abc1bd..c80f8e8028 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -782,8 +782,6 @@ struct btrfs_fs_info *btrfs_new_fs_info(void)
fs_info->fs_root_tree = RB_ROOT;
cache_tree_init(_info->mapping_tree.cache_tree);
- mutex_init(_info->fs_mutex);
-
return fs_info;
free_all:
btrfs_free_fs_info(fs_info);
Re: [PATCH 1/4] autoboot: make sure watchdog device(s) are handled with keyed autoboot
On 27.09.22 11:54, Rasmus Villemoes wrote: Currently, AUTOBOOT_KEYED and its variant AUTOBOOT_ENCRYPTION are broken when one has an external always-running watchdog device with a timeout shorter than the configured boot delay (in my case, I have a gpio-wdt one with a timeout of 1 second), because we fail to call WATCHDOG_RESET() in the loops where we wait for the bootdelay to elapse. This is done implicitly in the !AUTOBOOT_KEYED case, i.e. abortboot_single_key(), because that loop contains a udelay(1), and udelay() does a WATCHDOG_RESET(). To fix this, simply add similar udelay() calls in the other loops. Signed-off-by: Rasmus Villemoes Reviewed-by: Stefan Roese Thanks, Stefan --- common/autoboot.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/common/autoboot.c b/common/autoboot.c index 63f2587941..cdafe76309 100644 --- a/common/autoboot.c +++ b/common/autoboot.c @@ -115,6 +115,7 @@ static int passwd_abort_crypt(uint64_t etime) presskey_len++; } } + udelay(1); } while (never_timeout || get_ticks() <= etime); return abort; @@ -206,6 +207,7 @@ static int passwd_abort_sha256(uint64_t etime) if (slow_equals(sha, sha_env, SHA256_SUM_LEN)) abort = 1; } + udelay(1); } while (!abort && get_ticks() <= etime); free(presskey); @@ -293,6 +295,7 @@ static int passwd_abort_key(uint64_t etime) abort = 1; } } + udelay(1); } while (!abort && get_ticks() <= etime); return abort; Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH] watchdog: max6370: use __udelay() to avoid recursion
On 27.09.22 12:19, Pali Rohár wrote:
The udelay() function in lib/time.c contains a WATCHDOG_RESET()
call. So use __udelay() in max6370_wdt.c to prevent recursion.
Fixes: 0a095fc53b15 ("watchdog: Add MAX6370 watchdog timer driver")
Signed-off-by: Pali Rohár
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
drivers/watchdog/max6370_wdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/max6370_wdt.c b/drivers/watchdog/max6370_wdt.c
index 556c6a4b6d6b..44872e23c586 100644
--- a/drivers/watchdog/max6370_wdt.c
+++ b/drivers/watchdog/max6370_wdt.c
@@ -73,7 +73,7 @@ static int max6370_wdt_reset(struct udevice *dev)
if (dm_gpio_is_valid(>gpio_wdi)) {
dm_gpio_set_value(>gpio_wdi, 1);
- udelay(1);
+ __udelay(1);
dm_gpio_set_value(>gpio_wdi, 0);
} else {
val = readb(wdt->reg);
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH] watchdog: gpio_wdt: use __udelay() to avoid recursion
On Tuesday 27 September 2022 10:00:00 Stefan Roese wrote: > The max6370_wdt.c driver has the same problem AFAICT. Pali, could you > please take a look a this? Done, here is patch: https://patchwork.ozlabs.org/project/uboot/patch/20220927101919.6999-1-p...@kernel.org/
[PATCH] watchdog: max6370: use __udelay() to avoid recursion
The udelay() function in lib/time.c contains a WATCHDOG_RESET()
call. So use __udelay() in max6370_wdt.c to prevent recursion.
Fixes: 0a095fc53b15 ("watchdog: Add MAX6370 watchdog timer driver")
Signed-off-by: Pali Rohár
---
drivers/watchdog/max6370_wdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/max6370_wdt.c b/drivers/watchdog/max6370_wdt.c
index 556c6a4b6d6b..44872e23c586 100644
--- a/drivers/watchdog/max6370_wdt.c
+++ b/drivers/watchdog/max6370_wdt.c
@@ -73,7 +73,7 @@ static int max6370_wdt_reset(struct udevice *dev)
if (dm_gpio_is_valid(>gpio_wdi)) {
dm_gpio_set_value(>gpio_wdi, 1);
- udelay(1);
+ __udelay(1);
dm_gpio_set_value(>gpio_wdi, 0);
} else {
val = readb(wdt->reg);
--
2.20.1
[PATCH 4/4] sandbox.dtsi: add a sandbox,alarm-wdt instance
In order to test that we properly handle watchdog(s) during the "wait
for the user to interrupt autoboot" phase, we need a watchdog device
to be watching us.
Signed-off-by: Rasmus Villemoes
---
arch/sandbox/dts/sandbox.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/sandbox/dts/sandbox.dtsi b/arch/sandbox/dts/sandbox.dtsi
index 56e6b38bfa..c3b09895ca 100644
--- a/arch/sandbox/dts/sandbox.dtsi
+++ b/arch/sandbox/dts/sandbox.dtsi
@@ -27,6 +27,12 @@
};
};
+ alarm_wdt: alarm-wdt {
+ compatible = "sandbox,alarm-wdt";
+ timeout-sec = <5>;
+ u-boot,autostart;
+ };
+
audio: audio-codec {
compatible = "sandbox,audio-codec";
#sound-dai-cells = <1>;
--
2.37.2
[PATCH 3/4] sandbox: add SIGALRM-based watchdog device
In order to test that U-Boot actually maintains the watchdog device(s)
during long-running busy-loops, such as those where we wait for the
user to stop autoboot, we need a watchdog device that actually does
something during those loops; we cannot test that behaviour via the DM
test framework.
So introduce a relatively simple watchdog device which is simply based
on calling the host OS' alarm() function; that has the nice property
that a new call to alarm() simply sets a new deadline, and alarm(0)
cancels any existing alarm. These properties are precisely what we
need to implement start/reset/stop. We install our own handler so that
we get a known message printed if and when the watchdog fires, and by
just invoking that handler directly, we get expire_now for free.
The actual calls to the various OS functions (alarm, signal, raise)
need to be done in os.c, and since the driver code cannot get access
to the values of SIGALRM or SIG_DFL (that would require including a
host header, and that's only os.c which can do that), we cannot simply
do trivial wrappers for signal() and raise(), but instead create
specialized functions just for use by this driver.
Apart from enabling this driver for sandbox{,64}_defconfig, also
enable the wdt command which was useful for hand-testing this new
driver (especially with running u-boot under strace).
Signed-off-by: Rasmus Villemoes
---
arch/sandbox/cpu/os.c| 17 ++
configs/sandbox64_defconfig | 2 +
configs/sandbox_defconfig| 2 +
drivers/watchdog/Kconfig | 8 +++
drivers/watchdog/Makefile| 1 +
drivers/watchdog/sandbox_alarm-wdt.c | 79
include/os.h | 17 ++
7 files changed, 126 insertions(+)
create mode 100644 drivers/watchdog/sandbox_alarm-wdt.c
diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index f937991139..4e8953b4d4 100644
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
@@ -130,6 +130,23 @@ void os_exit(int exit_code)
exit(exit_code);
}
+unsigned int os_alarm(unsigned int seconds)
+{
+ return alarm(seconds);
+}
+
+void os_set_alarm_handler(void (*handler)(int))
+{
+ if (!handler)
+ handler = SIG_DFL;
+ signal(SIGALRM, handler);
+}
+
+void os_raise_sigalrm(void)
+{
+ raise(SIGALRM);
+}
+
int os_write_file(const char *fname, const void *buf, int size)
{
int fd;
diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
index 290d1506c2..1870a46257 100644
--- a/configs/sandbox64_defconfig
+++ b/configs/sandbox64_defconfig
@@ -54,6 +54,7 @@ CONFIG_CMD_READ=y
CONFIG_CMD_REMOTEPROC=y
CONFIG_CMD_SPI=y
CONFIG_CMD_USB=y
+CONFIG_CMD_WDT=y
CONFIG_BOOTP_DNS2=y
CONFIG_CMD_TFTPPUT=y
CONFIG_CMD_TFTPSRV=y
@@ -234,6 +235,7 @@ CONFIG_SPLASH_SCREEN_ALIGN=y
CONFIG_WDT=y
CONFIG_WDT_GPIO=y
CONFIG_WDT_SANDBOX=y
+CONFIG_WDT_ALARM_SANDBOX=y
CONFIG_FS_CBFS=y
CONFIG_FS_CRAMFS=y
CONFIG_CMD_DHRYSTONE=y
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index ab5d3f19bf..f117616db8 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -78,6 +78,7 @@ CONFIG_CMD_READ=y
CONFIG_CMD_REMOTEPROC=y
CONFIG_CMD_SPI=y
CONFIG_CMD_USB=y
+CONFIG_CMD_WDT=y
CONFIG_CMD_AXI=y
CONFIG_CMD_SETEXPR_FMT=y
CONFIG_CMD_AB_SELECT=y
@@ -311,6 +312,7 @@ CONFIG_W1_EEPROM_SANDBOX=y
CONFIG_WDT=y
CONFIG_WDT_GPIO=y
CONFIG_WDT_SANDBOX=y
+CONFIG_WDT_ALARM_SANDBOX=y
CONFIG_FS_CBFS=y
CONFIG_FS_CRAMFS=y
CONFIG_ADDR_MAP=y
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 50e6a1efba..53ec2331a7 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -279,6 +279,14 @@ config WDT_SANDBOX
can be probed and supports all of the methods of WDT, but does not
really do anything.
+config WDT_ALARM_SANDBOX
+ bool "Enable SIGALRM-based Watchdog Timer support for Sandbox"
+ depends on SANDBOX && WDT
+ help
+ Enable support for a SIGALRM-based watchdog timer in Sandbox. This is
+ a watchdog device based on the host OS' alarm() function, which will
+ kill the sandbox with SIGALRM unless properly maintained.
+
config WDT_SBSA
bool "SBSA watchdog timer support"
depends on WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 0e2f582a5f..446d961d7d 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_DESIGNWARE_WATCHDOG) += designware_wdt.o
obj-$(CONFIG_ULP_WATCHDOG) += ulp_wdog.o
obj-$(CONFIG_$(SPL_TPL_)WDT) += wdt-uclass.o
obj-$(CONFIG_WDT_SANDBOX) += sandbox_wdt.o
+obj-$(CONFIG_WDT_ALARM_SANDBOX) += sandbox_alarm-wdt.o
obj-$(CONFIG_WDT_APPLE) += apple_wdt.o
obj-$(CONFIG_WDT_ARMADA_37XX) += armada-37xx-wdt.o
obj-$(CONFIG_WDT_ASPEED) += ast_wdt.o
diff --git a/drivers/watchdog/sandbox_alarm-wdt.c
b/drivers/watchdog/sandbox_alarm-wdt.c
new file mode 100644
index
[PATCH 2/4] watchdog: introduce a u-boot,autostart property
This is a companion to u-boot,noautostart. If one has a single
watchdog device that one does want to have auto-started, but several
others that one doesn't, the only way currently is to set the
CONFIG_WATCHDOG_AUTOSTART and then use the opt-out for the majority.
The main motivation for this is to add an autostarted watchdog device
to the sandbox (to test a fix) without having to set AUTOSTART in
sandbox_defconfig and add the noautostart property to the existing
devices. But it's also nice for symmetry, and the logic in
init_watchdog_dev() becomes simpler to read because we avoid all the
negations.
Signed-off-by: Rasmus Villemoes
---
doc/device-tree-bindings/watchdog/common.txt | 9 +
drivers/watchdog/wdt-uclass.c| 15 +--
2 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/doc/device-tree-bindings/watchdog/common.txt
b/doc/device-tree-bindings/watchdog/common.txt
index 9db6dd6146..d041fea234 100644
--- a/doc/device-tree-bindings/watchdog/common.txt
+++ b/doc/device-tree-bindings/watchdog/common.txt
@@ -6,7 +6,8 @@ Optional properties:
be used instead.
- hw_margin_ms : Period used to reset the watchdog in ms
If this period is not defined, the default value is 1000.
-- u-boot,noautostart : Specify that this watchdog should not autostart
- When the config option WATCHDOG_AUTOSTART is set, all
enabled
- watchdogs are started. This property allows specifying
that this
- watchdog should NOT be started.
+- u-boot,noautostart :
+- u-boot,autostart : These (mutually exclusive) boolean properties can be used
to control
+ whether the watchdog is automatically started when
probed. If neither
+ are present, the behaviour is determined by the config
option
+ WATCHDOG_AUTOSTART.
diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c
index dbf556467d..5b3ceaf641 100644
--- a/drivers/watchdog/wdt-uclass.c
+++ b/drivers/watchdog/wdt-uclass.c
@@ -36,8 +36,8 @@ struct wdt_priv {
ulong next_reset;
/* Whether watchdog_start() has been called on the device. */
bool running;
- /* No autostart */
- bool noautostart;
+ /* autostart */
+ bool autostart;
};
static void init_watchdog_dev(struct udevice *dev)
@@ -54,7 +54,7 @@ static void init_watchdog_dev(struct udevice *dev)
dev->name);
}
- if (!IS_ENABLED(CONFIG_WATCHDOG_AUTOSTART) || priv->noautostart) {
+ if (!priv->autostart) {
printf("WDT: Not starting %s\n", dev->name);
return;
}
@@ -258,19 +258,22 @@ static int wdt_pre_probe(struct udevice *dev)
* indicated by a hw_margin_ms property.
*/
ulong reset_period = 1000;
- bool noautostart = false;
+ bool autostart = IS_ENABLED(CONFIG_WATCHDOG_AUTOSTART);
struct wdt_priv *priv;
if (CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)) {
timeout = dev_read_u32_default(dev, "timeout-sec", timeout);
reset_period = dev_read_u32_default(dev, "hw_margin_ms",
4 * reset_period) / 4;
- noautostart = dev_read_bool(dev, "u-boot,noautostart");
+ if (dev_read_bool(dev, "u-boot,noautostart"))
+ autostart = false;
+ else if (dev_read_bool(dev, "u-boot,autostart"))
+ autostart = true;
}
priv = dev_get_uclass_priv(dev);
priv->timeout = timeout;
priv->reset_period = reset_period;
- priv->noautostart = noautostart;
+ priv->autostart = autostart;
/*
* Pretend this device was last reset "long" ago so the first
* watchdog_reset will actually call its ->reset method.
--
2.37.2
[PATCH 0/4] handle watchdogs during keyed autoboot
The fix and explanation is in the first patch, which I hope can make it into v2022.10, it should be rather uncontroversial. The second patch may make sense on its own, but is not at all urgent and can be considered a mere suggestion, but it was convenient for making the following two patches less intrusive. While I noticed this on my actual hardware, it's not too hard to verify the problem in sandbox, which is what patches 2-4 are for. More precisely, I've tested that with this series (and the stuff added by the first patch temporarily commented out), building sandbox64_defconfig modified by setting CONFIG_BOOTDELAY=15 and CONFIG_AUTOBOOT_KEYED=y, doing ./u-boot -D works as always (ordinary simple autoboot, getting a prompt after 15 seconds), while with ./u-boot -D --autoboot_keyed the sandbox gets killed as expected five seconds into the 15 second countdown. And with the first patch properly applied, this is fixed. I don't know if this is a good way to test this, or if having that SIGALRM based watchdog device running always in sandbox can cause problems for other uses of sandbox. I also won't have time in the near future for polishing or reworking the test, so consider it mostly POC. Regardless, as I wrote above, I do hope the fix itself (1/4) can be applied soonish. Rasmus Villemoes (4): autoboot: make sure watchdog device(s) are handled with keyed autoboot watchdog: introduce a u-boot,autostart property sandbox: add SIGALRM-based watchdog device sandbox.dtsi: add a sandbox,alarm-wdt instance arch/sandbox/cpu/os.c| 17 + arch/sandbox/dts/sandbox.dtsi| 6 ++ common/autoboot.c| 3 + configs/sandbox64_defconfig | 2 + configs/sandbox_defconfig| 2 + doc/device-tree-bindings/watchdog/common.txt | 9 ++- drivers/watchdog/Kconfig | 8 ++ drivers/watchdog/Makefile| 1 + drivers/watchdog/sandbox_alarm-wdt.c | 79 drivers/watchdog/wdt-uclass.c| 15 ++-- include/os.h | 17 + 11 files changed, 149 insertions(+), 10 deletions(-) create mode 100644 drivers/watchdog/sandbox_alarm-wdt.c -- 2.37.2
[PATCH 1/4] autoboot: make sure watchdog device(s) are handled with keyed autoboot
Currently, AUTOBOOT_KEYED and its variant AUTOBOOT_ENCRYPTION are broken when one has an external always-running watchdog device with a timeout shorter than the configured boot delay (in my case, I have a gpio-wdt one with a timeout of 1 second), because we fail to call WATCHDOG_RESET() in the loops where we wait for the bootdelay to elapse. This is done implicitly in the !AUTOBOOT_KEYED case, i.e. abortboot_single_key(), because that loop contains a udelay(1), and udelay() does a WATCHDOG_RESET(). To fix this, simply add similar udelay() calls in the other loops. Signed-off-by: Rasmus Villemoes --- common/autoboot.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/common/autoboot.c b/common/autoboot.c index 63f2587941..cdafe76309 100644 --- a/common/autoboot.c +++ b/common/autoboot.c @@ -115,6 +115,7 @@ static int passwd_abort_crypt(uint64_t etime) presskey_len++; } } + udelay(1); } while (never_timeout || get_ticks() <= etime); return abort; @@ -206,6 +207,7 @@ static int passwd_abort_sha256(uint64_t etime) if (slow_equals(sha, sha_env, SHA256_SUM_LEN)) abort = 1; } + udelay(1); } while (!abort && get_ticks() <= etime); free(presskey); @@ -293,6 +295,7 @@ static int passwd_abort_key(uint64_t etime) abort = 1; } } + udelay(1); } while (!abort && get_ticks() <= etime); return abort; -- 2.37.2
[PATCH] apalis/colibri_imx6/-imx6ull/_imx7: update env memory layout
From: Marcel Ziswiler
Update the distro config env memory layout for the Apalis iMX6,
Colibri iMX6, Colibri iMX6ULL and Colibri iMX7:
- loadaddr=0x8420 allows for 64MB area for uncompressing (ie FIT
images)
- fdt_addr_r = loadaddr + 64MB : allows for 64MB kernel
- scriptaddr = fdt_addr_r + 512KB : allows for 512KB fdt
- pxefile_addr_r = scriptaddr + 512KB : allows for 512KB script
- ramdisk_addr_r = pxefile_addr_r + 512KB : allows for 1MB extlinux.conf
Memory layout analogous to 64-bit one from commit fd5c7173ade4
("imx8m{m,n}_venice: update env memory layout") but left pxefile_addr_r
updated according to doc/develop/distro.rst.
This fixes a potential issue caused by the compressed kernel being
relocated on top of the ramdisk causing its corruption.
Signed-off-by: Marcel Ziswiler
eries-version: 1
---
configs/apalis_imx6_defconfig | 1 +
configs/colibri-imx6ull-emmc_defconfig | 1 +
configs/colibri-imx6ull_defconfig | 1 +
configs/colibri_imx6_defconfig | 1 +
configs/colibri_imx7_defconfig | 1 +
configs/colibri_imx7_emmc_defconfig| 1 +
include/configs/apalis_imx6.h | 10 +-
include/configs/colibri-imx6ull.h | 10 +-
include/configs/colibri_imx6.h | 10 +-
include/configs/colibri_imx7.h | 10 +-
10 files changed, 26 insertions(+), 20 deletions(-)
diff --git a/configs/apalis_imx6_defconfig b/configs/apalis_imx6_defconfig
index 5960aef698f..02a3e8337ca 100644
--- a/configs/apalis_imx6_defconfig
+++ b/configs/apalis_imx6_defconfig
@@ -22,6 +22,7 @@ CONFIG_SPL_MMC=y
CONFIG_SPL_SERIAL=y
CONFIG_SPL=y
CONFIG_CMD_HDMIDETECT=y
+CONFIG_SYS_LOAD_ADDR=0x8420
CONFIG_AHCI=y
CONFIG_SYS_MEMTEST_START=0x1000
CONFIG_SYS_MEMTEST_END=0x1001
diff --git a/configs/colibri-imx6ull-emmc_defconfig
b/configs/colibri-imx6ull-emmc_defconfig
index e6ed9b5fd0f..02b6be0a2b4 100644
--- a/configs/colibri-imx6ull-emmc_defconfig
+++ b/configs/colibri-imx6ull-emmc_defconfig
@@ -10,6 +10,7 @@ CONFIG_DM_GPIO=y
CONFIG_TARGET_COLIBRI_IMX6ULL_EMMC=y
CONFIG_DEFAULT_DEVICE_TREE="imx6ull-colibri-emmc-eval-v3"
CONFIG_SYS_PROMPT="Colibri iMX6ULL # "
+CONFIG_SYS_LOAD_ADDR=0x8420
CONFIG_SYS_MEMTEST_START=0x8000
CONFIG_SYS_MEMTEST_END=0x8800
CONFIG_DISTRO_DEFAULTS=y
diff --git a/configs/colibri-imx6ull_defconfig
b/configs/colibri-imx6ull_defconfig
index d65f2533ca2..cc0a3473941 100644
--- a/configs/colibri-imx6ull_defconfig
+++ b/configs/colibri-imx6ull_defconfig
@@ -11,6 +11,7 @@ CONFIG_DM_GPIO=y
CONFIG_TARGET_COLIBRI_IMX6ULL_NAND=y
CONFIG_DEFAULT_DEVICE_TREE="imx6ull-colibri-eval-v3"
CONFIG_SYS_PROMPT="Colibri iMX6ULL # "
+CONFIG_SYS_LOAD_ADDR=0x8420
CONFIG_SYS_MEMTEST_START=0x8000
CONFIG_SYS_MEMTEST_END=0x8800
CONFIG_DISTRO_DEFAULTS=y
diff --git a/configs/colibri_imx6_defconfig b/configs/colibri_imx6_defconfig
index 5cf398b09e2..ca3ec8b706d 100644
--- a/configs/colibri_imx6_defconfig
+++ b/configs/colibri_imx6_defconfig
@@ -22,6 +22,7 @@ CONFIG_SPL_MMC=y
CONFIG_SPL_SERIAL=y
CONFIG_SPL=y
CONFIG_CMD_HDMIDETECT=y
+CONFIG_SYS_LOAD_ADDR=0x8420
CONFIG_SYS_MEMTEST_START=0x1000
CONFIG_SYS_MEMTEST_END=0x1001
CONFIG_DISTRO_DEFAULTS=y
diff --git a/configs/colibri_imx7_defconfig b/configs/colibri_imx7_defconfig
index dfdb74f69b0..28872639b61 100644
--- a/configs/colibri_imx7_defconfig
+++ b/configs/colibri_imx7_defconfig
@@ -11,6 +11,7 @@ CONFIG_SYS_PROMPT="Colibri iMX7 # "
CONFIG_IMX_RDC=y
CONFIG_IMX_BOOTAUX=y
CONFIG_IMX_HAB=y
+CONFIG_SYS_LOAD_ADDR=0x8420
CONFIG_OF_BOARD_FIXUP=y
CONFIG_SYS_MEMTEST_START=0x8000
CONFIG_SYS_MEMTEST_END=0x8c00
diff --git a/configs/colibri_imx7_emmc_defconfig
b/configs/colibri_imx7_emmc_defconfig
index 033ce1747bf..c12717b4f25 100644
--- a/configs/colibri_imx7_emmc_defconfig
+++ b/configs/colibri_imx7_emmc_defconfig
@@ -12,6 +12,7 @@ CONFIG_ARMV7_BOOT_SEC_DEFAULT=y
CONFIG_IMX_RDC=y
CONFIG_IMX_BOOTAUX=y
CONFIG_IMX_HAB=y
+CONFIG_SYS_LOAD_ADDR=0x8420
CONFIG_SYS_MEMTEST_START=0x8000
CONFIG_SYS_MEMTEST_END=0x8c00
CONFIG_DISTRO_DEFAULTS=y
diff --git a/include/configs/apalis_imx6.h b/include/configs/apalis_imx6.h
index 4922b063309..51ef4e3663c 100644
--- a/include/configs/apalis_imx6.h
+++ b/include/configs/apalis_imx6.h
@@ -70,11 +70,11 @@
#define MEM_LAYOUT_ENV_SETTINGS \
"bootm_size=0x2000\0" \
- "fdt_addr_r=0x1210\0" \
- "kernel_addr_r=0x1100\0" \
- "pxefile_addr_r=0x1710\0" \
- "ramdisk_addr_r=0x1220\0" \
- "scriptaddr=0x1700\0"
+ "fdt_addr_r=0x8820\0" \
+ "kernel_addr_r=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
+ "pxefile_addr_r=0x8830\0" \
+ "ramdisk_addr_r=0x8840\0" \
+ "scriptaddr=0x8828\0"
#define CONFIG_EXTRA_ENV_SETTINGS \
BOOTENV \
diff --git a/include/configs/colibri-imx6ull.h
b/include/configs/colibri-imx6ull.h
index 04cde9530ad..79b1284cc7a 100644
---
[PATCH v1 1/2] arm: nuvoton: Add support for Nuvoton NPCM845 BMC
Add basic support for the Nuvoton NPCM845 EVB (Arbel).
Signed-off-by: Jim Liu
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/nuvoton-common-npcm8xx.dtsi | 170 ++
arch/arm/dts/nuvoton-npcm845-evb.dts | 30
arch/arm/dts/nuvoton-npcm845.dtsi | 77
arch/arm/dts/nuvoton-npcm8xx-u-boot.dtsi | 136 ++
arch/arm/include/asm/arch-npcm8xx/gcr.h | 140 +++
arch/arm/include/asm/arch-npcm8xx/rst.h | 26 +++
arch/arm/mach-npcm/Kconfig| 8 +
arch/arm/mach-npcm/Makefile | 1 +
arch/arm/mach-npcm/npcm8xx/Kconfig| 18 ++
arch/arm/mach-npcm/npcm8xx/Makefile | 1 +
arch/arm/mach-npcm/npcm8xx/cpu.c | 135 ++
arch/arm/mach-npcm/npcm8xx/reset.c| 37
board/nuvoton/arbel_evb/Kconfig | 18 ++
board/nuvoton/arbel_evb/MAINTAINERS | 7 +
board/nuvoton/arbel_evb/Makefile | 1 +
board/nuvoton/arbel_evb/arbel_evb.c | 29 +++
configs/arbel_evb_defconfig | 66 +++
include/configs/arbel.h | 35
.../dt-bindings/clock/nuvoton,npcm845-clk.h | 52 ++
.../dt-bindings/reset/nuvoton,npcm8xx-reset.h | 124 +
21 files changed, 1112 insertions(+)
create mode 100644 arch/arm/dts/nuvoton-common-npcm8xx.dtsi
create mode 100644 arch/arm/dts/nuvoton-npcm845-evb.dts
create mode 100644 arch/arm/dts/nuvoton-npcm845.dtsi
create mode 100644 arch/arm/dts/nuvoton-npcm8xx-u-boot.dtsi
create mode 100644 arch/arm/include/asm/arch-npcm8xx/gcr.h
create mode 100644 arch/arm/include/asm/arch-npcm8xx/rst.h
create mode 100644 arch/arm/mach-npcm/npcm8xx/Kconfig
create mode 100644 arch/arm/mach-npcm/npcm8xx/Makefile
create mode 100644 arch/arm/mach-npcm/npcm8xx/cpu.c
create mode 100644 arch/arm/mach-npcm/npcm8xx/reset.c
create mode 100644 board/nuvoton/arbel_evb/Kconfig
create mode 100644 board/nuvoton/arbel_evb/MAINTAINERS
create mode 100644 board/nuvoton/arbel_evb/Makefile
create mode 100644 board/nuvoton/arbel_evb/arbel_evb.c
create mode 100644 configs/arbel_evb_defconfig
create mode 100644 include/configs/arbel.h
create mode 100644 include/dt-bindings/clock/nuvoton,npcm845-clk.h
create mode 100644 include/dt-bindings/reset/nuvoton,npcm8xx-reset.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 965895bc2a..5c24d6354d 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1239,6 +1239,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt8518-ap1-emmc.dtb
dtb-$(CONFIG_ARCH_NPCM7xx) += nuvoton-npcm750-evb.dtb
+dtb-$(CONFIG_ARCH_NPCM8XX) += nuvoton-npcm845-evb.dtb
dtb-$(CONFIG_XEN) += xenguest-arm64.dtb
dtb-$(CONFIG_ARCH_OCTEONTX) += octeontx.dtb
diff --git a/arch/arm/dts/nuvoton-common-npcm8xx.dtsi
b/arch/arm/dts/nuvoton-common-npcm8xx.dtsi
new file mode 100644
index 00..aa7aac8c37
--- /dev/null
+++ b/arch/arm/dts/nuvoton-common-npcm8xx.dtsi
@@ -0,0 +1,170 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2021 Nuvoton Technology tomer.mai...@nuvoton.com
+
+#include
+#include
+#include
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <>;
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ compatible = "simple-bus";
+ interrupt-parent = <>;
+ ranges;
+
+ gcr: system-controller@f080 {
+ compatible = "nuvoton,npcm845-gcr", "syscon";
+ reg = <0x0 0xf080 0x0 0x1000>;
+ };
+
+ gic: interrupt-controller@dfff9000 {
+ compatible = "arm,gic-400";
+ reg = <0x0 0xdfff9000 0x0 0x1000>,
+ <0x0 0xdfffa000 0x0 0x2000>,
+ <0x0 0xdfffc000 0x0 0x2000>,
+ <0x0 0xdfffe000 0x0 0x2000>;
+ interrupts = ;
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ #address-cells = <0>;
+ ppi-partitions {
+ ppi_cluster0: interrupt-partition-0 {
+ affinity = < >;
+ };
+ };
+ };
+ };
+
+ ahb {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ compatible = "simple-bus";
+ interrupt-parent = <>;
+ ranges;
+
+ rstc: reset-controller@f0801000 {
+ compatible = "nuvoton,npcm845-reset";
+ reg = <0x0 0xf0801000 0x0 0x78>;
+ #reset-cells = <2>;
+ nuvoton,sysgcr = <>;
+ };
+
+ clk: clock-controller@f0801000 {
+
[PATCH v1 2/2] clk: nuvoton: Add support for NPCM845
Add clock controller driver for NPCM845
Signed-off-by: Jim Liu
---
drivers/clk/nuvoton/Makefile | 1 +
drivers/clk/nuvoton/clk_npcm8xx.c | 98 +++
2 files changed, 99 insertions(+)
create mode 100644 drivers/clk/nuvoton/clk_npcm8xx.c
diff --git a/drivers/clk/nuvoton/Makefile b/drivers/clk/nuvoton/Makefile
index c63d9c16f1..b55dc80de2 100644
--- a/drivers/clk/nuvoton/Makefile
+++ b/drivers/clk/nuvoton/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_ARCH_NPCM) += clk_npcm.o
obj-$(CONFIG_ARCH_NPCM7xx) += clk_npcm7xx.o
+obj-$(CONFIG_ARCH_NPCM8XX) += clk_npcm8xx.o
diff --git a/drivers/clk/nuvoton/clk_npcm8xx.c
b/drivers/clk/nuvoton/clk_npcm8xx.c
new file mode 100644
index 00..27e3cfcf55
--- /dev/null
+++ b/drivers/clk/nuvoton/clk_npcm8xx.c
@@ -0,0 +1,98 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2022 Nuvoton Technology Corp.
+ */
+
+#include
+#include
+#include "clk_npcm.h"
+
+/* Parent clock map */
+static const struct parent_data pll_parents[] = {
+ {NPCM8XX_CLK_PLL0, 0},
+ {NPCM8XX_CLK_PLL1, 1},
+ {NPCM8XX_CLK_REFCLK, 2},
+ {NPCM8XX_CLK_PLL2DIV2, 3}
+};
+
+static const struct parent_data cpuck_parents[] = {
+ {NPCM8XX_CLK_PLL0, 0},
+ {NPCM8XX_CLK_PLL1, 1},
+ {NPCM8XX_CLK_REFCLK, 2},
+ {NPCM8XX_CLK_PLL2, 7}
+};
+
+static const struct parent_data apb_parent[] = {{NPCM8XX_CLK_AHB, 0}};
+
+static struct npcm_clk_pll npcm8xx_clk_plls[] = {
+ {NPCM8XX_CLK_PLL0, NPCM8XX_CLK_REFCLK, PLLCON0, 0},
+ {NPCM8XX_CLK_PLL1, NPCM8XX_CLK_REFCLK, PLLCON1, 0},
+ {NPCM8XX_CLK_PLL2, NPCM8XX_CLK_REFCLK, PLLCON2, 0},
+ {NPCM8XX_CLK_PLL2DIV2, NPCM8XX_CLK_REFCLK, PLLCON2, POST_DIV2}
+};
+
+static struct npcm_clk_select npcm8xx_clk_selectors[] = {
+ {NPCM8XX_CLK_AHB, cpuck_parents, CLKSEL, NPCM8XX_CPUCKSEL, 4, 0},
+ {NPCM8XX_CLK_APB2, apb_parent, 0, 0, 1, FIXED_PARENT},
+ {NPCM8XX_CLK_APB5, apb_parent, 0, 0, 1, FIXED_PARENT},
+ {NPCM8XX_CLK_SPI0, apb_parent, 0, 0, 1, FIXED_PARENT},
+ {NPCM8XX_CLK_SPI1, apb_parent, 0, 0, 1, FIXED_PARENT},
+ {NPCM8XX_CLK_SPI3, apb_parent, 0, 0, 1, FIXED_PARENT},
+ {NPCM8XX_CLK_SPIX, apb_parent, 0, 0, 1, FIXED_PARENT},
+ {NPCM8XX_CLK_UART, pll_parents, CLKSEL, UARTCKSEL, 4, 0},
+ {NPCM8XX_CLK_UART2, pll_parents, CLKSEL, UARTCKSEL, 4, 0},
+ {NPCM8XX_CLK_SDHC, pll_parents, CLKSEL, SDCKSEL, 4, 0}
+};
+
+static struct npcm_clk_div npcm8xx_clk_dividers[] = {
+ {NPCM8XX_CLK_AHB, CLKDIV1, CLK4DIV, DIV_TYPE1 | PRE_DIV2},
+ {NPCM8XX_CLK_APB2, CLKDIV2, APB2CKDIV, DIV_TYPE2},
+ {NPCM8XX_CLK_APB5, CLKDIV2, APB5CKDIV, DIV_TYPE2},
+ {NPCM8XX_CLK_SPI0, CLKDIV3, SPI0CKDIV, DIV_TYPE1},
+ {NPCM8XX_CLK_SPI1, CLKDIV3, SPI1CKDIV, DIV_TYPE1},
+ {NPCM8XX_CLK_SPI3, CLKDIV1, SPI3CKDIV, DIV_TYPE1},
+ {NPCM8XX_CLK_SPIX, CLKDIV3, SPIXCKDIV, DIV_TYPE1},
+ {NPCM8XX_CLK_UART, CLKDIV1, UARTDIV1, DIV_TYPE1},
+ {NPCM8XX_CLK_UART2, CLKDIV3, UARTDIV2, DIV_TYPE1},
+ {NPCM8XX_CLK_SDHC, CLKDIV1, MMCCKDIV, DIV_TYPE1}
+};
+
+static struct npcm_clk_data npcm8xx_clk_data = {
+ .clk_plls = npcm8xx_clk_plls,
+ .num_plls = ARRAY_SIZE(npcm8xx_clk_plls),
+ .clk_selectors = npcm8xx_clk_selectors,
+ .num_selectors = ARRAY_SIZE(npcm8xx_clk_selectors),
+ .clk_dividers = npcm8xx_clk_dividers,
+ .num_dividers = ARRAY_SIZE(npcm8xx_clk_dividers),
+ .refclk_id = NPCM8XX_CLK_REFCLK,
+ .pll0_id = NPCM8XX_CLK_PLL0,
+};
+
+static int npcm8xx_clk_probe(struct udevice *dev)
+{
+ struct npcm_clk_priv *priv = dev_get_priv(dev);
+
+ priv->base = dev_read_addr_ptr(dev);
+ if (!priv->base)
+ return -EINVAL;
+
+ priv->clk_data = _clk_data;
+ priv->num_clks = NPCM8XX_NUM_CLOCKS;
+
+ return 0;
+}
+
+static const struct udevice_id npcm8xx_clk_ids[] = {
+ { .compatible = "nuvoton,npcm845-clk" },
+ { }
+};
+
+U_BOOT_DRIVER(clk_npcm) = {
+ .name = "clk_npcm",
+ .id = UCLASS_CLK,
+ .of_match = npcm8xx_clk_ids,
+ .ops= _clk_ops,
+ .priv_auto = sizeof(struct npcm_clk_priv),
+ .probe = npcm8xx_clk_probe,
+ .flags = DM_FLAG_PRE_RELOC,
+};
--
2.17.1
[PATCH v1 0/2] Add support for Nuvoton NPCM845 BMC
The Nuvoton Arbel NPCM8XX SoC is a fourth-generation BMC. The NPCM8XX computing subsystem comprises a quadcore ARM Cortex A35 ARM-V8 architecture. Some of the Arbel NPCM8XX peripherals are based on Poleg NPCM7XX. This patchset was tested on the Arbel NPCM8XX evaluation board. And DTS is base on linux upstream Jim Liu (2): arm: nuvoton: Add support for Nuvoton NPCM845 BMC clk: nuvoton: Add support for NPCM845 arch/arm/dts/Makefile | 1 + arch/arm/dts/nuvoton-common-npcm8xx.dtsi | 170 ++ arch/arm/dts/nuvoton-npcm845-evb.dts | 30 arch/arm/dts/nuvoton-npcm845.dtsi | 77 arch/arm/dts/nuvoton-npcm8xx-u-boot.dtsi | 136 ++ arch/arm/include/asm/arch-npcm8xx/gcr.h | 140 +++ arch/arm/include/asm/arch-npcm8xx/rst.h | 26 +++ arch/arm/mach-npcm/Kconfig| 8 + arch/arm/mach-npcm/Makefile | 1 + arch/arm/mach-npcm/npcm8xx/Kconfig| 18 ++ arch/arm/mach-npcm/npcm8xx/Makefile | 1 + arch/arm/mach-npcm/npcm8xx/cpu.c | 135 ++ arch/arm/mach-npcm/npcm8xx/reset.c| 37 board/nuvoton/arbel_evb/Kconfig | 18 ++ board/nuvoton/arbel_evb/MAINTAINERS | 7 + board/nuvoton/arbel_evb/Makefile | 1 + board/nuvoton/arbel_evb/arbel_evb.c | 29 +++ configs/arbel_evb_defconfig | 66 +++ drivers/clk/nuvoton/Makefile | 1 + drivers/clk/nuvoton/clk_npcm8xx.c | 98 ++ include/configs/arbel.h | 35 .../dt-bindings/clock/nuvoton,npcm845-clk.h | 52 ++ .../dt-bindings/reset/nuvoton,npcm8xx-reset.h | 124 + 23 files changed, 1211 insertions(+) create mode 100644 arch/arm/dts/nuvoton-common-npcm8xx.dtsi create mode 100644 arch/arm/dts/nuvoton-npcm845-evb.dts create mode 100644 arch/arm/dts/nuvoton-npcm845.dtsi create mode 100644 arch/arm/dts/nuvoton-npcm8xx-u-boot.dtsi create mode 100644 arch/arm/include/asm/arch-npcm8xx/gcr.h create mode 100644 arch/arm/include/asm/arch-npcm8xx/rst.h create mode 100644 arch/arm/mach-npcm/npcm8xx/Kconfig create mode 100644 arch/arm/mach-npcm/npcm8xx/Makefile create mode 100644 arch/arm/mach-npcm/npcm8xx/cpu.c create mode 100644 arch/arm/mach-npcm/npcm8xx/reset.c create mode 100644 board/nuvoton/arbel_evb/Kconfig create mode 100644 board/nuvoton/arbel_evb/MAINTAINERS create mode 100644 board/nuvoton/arbel_evb/Makefile create mode 100644 board/nuvoton/arbel_evb/arbel_evb.c create mode 100644 configs/arbel_evb_defconfig create mode 100644 drivers/clk/nuvoton/clk_npcm8xx.c create mode 100644 include/configs/arbel.h create mode 100644 include/dt-bindings/clock/nuvoton,npcm845-clk.h create mode 100644 include/dt-bindings/reset/nuvoton,npcm8xx-reset.h -- 2.17.1
Re: [PATCH] configs: increase SYS_MALLOC_F_LEN for STM32 MCU's board
Hi, On 9/26/22 17:59, Patrice Chotard wrote: Some STM32 MCU's board need their SYS_MALLOC_F_LEN value enlarged to avoid the "alloc space exhausted" error message during their boot process. Use the default SYS_MALLOC_F_LEN value which is set to 0x2000 in Kconfig. Signed-off-by: Patrice Chotard --- configs/stm32746g-eval_defconfig | 1 - configs/stm32746g-eval_spl_defconfig | 1 - configs/stm32f429-discovery_defconfig | 1 - configs/stm32f429-evaluation_defconfig | 1 - configs/stm32f469-discovery_defconfig | 1 - configs/stm32f746-disco_defconfig | 1 - configs/stm32f746-disco_spl_defconfig | 1 - configs/stm32f769-disco_defconfig | 1 - configs/stm32f769-disco_spl_defconfig | 1 - configs/stm32h743-disco_defconfig | 1 - configs/stm32h743-eval_defconfig | 1 - configs/stm32h750-art-pi_defconfig | 1 - 12 files changed, 12 deletions(-) diff --git a/configs/stm32746g-eval_defconfig b/configs/stm32746g-eval_defconfig index 58232a7114..7200446d28 100644 --- a/configs/stm32746g-eval_defconfig +++ b/configs/stm32746g-eval_defconfig @@ -2,7 +2,6 @@ CONFIG_ARM=y CONFIG_ARCH_STM32=y CONFIG_SYS_TEXT_BASE=0x0800 CONFIG_SYS_MALLOC_LEN=0x10 -CONFIG_SYS_MALLOC_F_LEN=0xE00 CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x2000 CONFIG_DEFAULT_DEVICE_TREE="stm32746g-eval" diff --git a/configs/stm32746g-eval_spl_defconfig b/configs/stm32746g-eval_spl_defconfig index 28f522b15e..ff42952a76 100644 --- a/configs/stm32746g-eval_spl_defconfig +++ b/configs/stm32746g-eval_spl_defconfig @@ -2,7 +2,6 @@ CONFIG_ARM=y CONFIG_ARCH_STM32=y CONFIG_SYS_TEXT_BASE=0x08009000 CONFIG_SYS_MALLOC_LEN=0x10 -CONFIG_SYS_MALLOC_F_LEN=0xE00 CONFIG_SPL_GPIO=y CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y diff --git a/configs/stm32f429-discovery_defconfig b/configs/stm32f429-discovery_defconfig index e6e595d495..914ac14641 100644 --- a/configs/stm32f429-discovery_defconfig +++ b/configs/stm32f429-discovery_defconfig @@ -2,7 +2,6 @@ CONFIG_ARM=y CONFIG_ARCH_STM32=y CONFIG_SYS_TEXT_BASE=0x0800 CONFIG_SYS_MALLOC_LEN=0x020 -CONFIG_SYS_MALLOC_F_LEN=0xF00 CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x2000 CONFIG_ENV_SECT_SIZE=0x2 diff --git a/configs/stm32f429-evaluation_defconfig b/configs/stm32f429-evaluation_defconfig index 073f27168a..af7a8bf076 100644 --- a/configs/stm32f429-evaluation_defconfig +++ b/configs/stm32f429-evaluation_defconfig @@ -2,7 +2,6 @@ CONFIG_ARM=y CONFIG_ARCH_STM32=y CONFIG_SYS_TEXT_BASE=0x0800 CONFIG_SYS_MALLOC_LEN=0x10 -CONFIG_SYS_MALLOC_F_LEN=0xF00 CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x2000 CONFIG_DEFAULT_DEVICE_TREE="stm32429i-eval" diff --git a/configs/stm32f469-discovery_defconfig b/configs/stm32f469-discovery_defconfig index bd3693275e..90680fdb05 100644 --- a/configs/stm32f469-discovery_defconfig +++ b/configs/stm32f469-discovery_defconfig @@ -2,7 +2,6 @@ CONFIG_ARM=y CONFIG_ARCH_STM32=y CONFIG_SYS_TEXT_BASE=0x0800 CONFIG_SYS_MALLOC_LEN=0x10 -CONFIG_SYS_MALLOC_F_LEN=0xF00 CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x2000 CONFIG_DEFAULT_DEVICE_TREE="stm32f469-disco" diff --git a/configs/stm32f746-disco_defconfig b/configs/stm32f746-disco_defconfig index ed537b0578..a8edf11b40 100644 --- a/configs/stm32f746-disco_defconfig +++ b/configs/stm32f746-disco_defconfig @@ -2,7 +2,6 @@ CONFIG_ARM=y CONFIG_ARCH_STM32=y CONFIG_SYS_TEXT_BASE=0x0800 CONFIG_SYS_MALLOC_LEN=0x10 -CONFIG_SYS_MALLOC_F_LEN=0xE00 CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x2000 CONFIG_DEFAULT_DEVICE_TREE="stm32f746-disco" diff --git a/configs/stm32f746-disco_spl_defconfig b/configs/stm32f746-disco_spl_defconfig index d4a65bde24..0e358e86ff 100644 --- a/configs/stm32f746-disco_spl_defconfig +++ b/configs/stm32f746-disco_spl_defconfig @@ -2,7 +2,6 @@ CONFIG_ARM=y CONFIG_ARCH_STM32=y CONFIG_SYS_TEXT_BASE=0x08009000 CONFIG_SYS_MALLOC_LEN=0x10 -CONFIG_SYS_MALLOC_F_LEN=0xE00 CONFIG_SPL_GPIO=y CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y diff --git a/configs/stm32f769-disco_defconfig b/configs/stm32f769-disco_defconfig index 5b5307ca1d..3e7b5bd06e 100644 --- a/configs/stm32f769-disco_defconfig +++ b/configs/stm32f769-disco_defconfig @@ -2,7 +2,6 @@ CONFIG_ARM=y CONFIG_ARCH_STM32=y CONFIG_SYS_TEXT_BASE=0x0800 CONFIG_SYS_MALLOC_LEN=0x10 -CONFIG_SYS_MALLOC_F_LEN=0xE00 CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x2000 CONFIG_DEFAULT_DEVICE_TREE="stm32f769-disco" diff --git a/configs/stm32f769-disco_spl_defconfig b/configs/stm32f769-disco_spl_defconfig index b5d54b48ec..f0a1b667b8 100644 --- a/configs/stm32f769-disco_spl_defconfig +++ b/configs/stm32f769-disco_spl_defconfig @@ -2,7 +2,6 @@ CONFIG_ARM=y CONFIG_ARCH_STM32=y CONFIG_SYS_TEXT_BASE=0x08009000 CONFIG_SYS_MALLOC_LEN=0x10 -CONFIG_SYS_MALLOC_F_LEN=0xE00 CONFIG_SPL_GPIO=y CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y diff --git
[PATCH] fdt_support: cosmetic: remove fdt_fixup_nor_flash_size prototype
Remove prototype for the removed function fdt_fixup_nor_flash_size.
This patch has no impact as the function is never used.
Fixes: 98f705c9cefd ("powerpc: remove 4xx support")
Signed-off-by: Patrick Delaunay
---
include/fdt_support.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/fdt_support.h b/include/fdt_support.h
index b8380716f39..5638bd4f165 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -243,8 +243,6 @@ int fdt_increase_size(void *fdt, int add_len);
int fdt_delete_disabled_nodes(void *blob);
-int fdt_fixup_nor_flash_size(void *blob);
-
struct node_info;
#if defined(CONFIG_FDT_FIXUP_PARTITIONS)
void fdt_fixup_mtdparts(void *fdt, const struct node_info *node_info,
--
2.25.1
Re: [PATCH] watchdog: gpio_wdt: use __udelay() to avoid recursion
Hi Rasmus,
(add Pali to Cc)
On 27.09.22 09:45, Rasmus Villemoes wrote:
The udelay() function in lib/time.c contains a WATCHDOG_RESET()
call. The only reason this doesn't lead to a catastrophic infinite
recursion is due to the rate-limiting in wdt-uclass.c:
if (time_after_eq(now, priv->next_reset)) {
priv->next_reset = now + priv->reset_period;
wdt_reset(dev);
}
But this would fall apart if ->next_reset was updated after calling the
device's reset method.
This is needlessly fragile, and it's easy enough to avoid that
recursion in the first place by just using __udelay() directly.
Signed-off-by: Rasmus Villemoes
---
drivers/watchdog/gpio_wdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/gpio_wdt.c b/drivers/watchdog/gpio_wdt.c
index fe06ec8cc9..2920c2c751 100644
--- a/drivers/watchdog/gpio_wdt.c
+++ b/drivers/watchdog/gpio_wdt.c
@@ -31,7 +31,7 @@ static int gpio_wdt_reset(struct udevice *dev)
case HW_ALGO_LEVEL:
/* Pulse */
dm_gpio_set_value(>gpio, 1);
- udelay(1);
+ __udelay(1);
dm_gpio_set_value(>gpio, 0);
break;
}
Yes, good catch:
Reviewed-by: Stefan Roese
The max6370_wdt.c driver has the same problem AFAICT. Pali, could you
please take a look a this?
Thanks,
Stefan
[PATCH] xilinx: zynq: Enable early eeprom decoding
Xilinx Zynq evaluation boards have factory program content in eeprom.
Enable reading and decoding eeprom content to get information about board
name, revision and especially getting ethernet mac address.
Signed-off-by: Michal Simek
---
board/xilinx/zynq/board.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c
index c96433be693b..17ee541bd840 100644
--- a/board/xilinx/zynq/board.c
+++ b/board/xilinx/zynq/board.c
@@ -37,6 +37,9 @@ int board_init(void)
if (IS_ENABLED(CONFIG_SPL_BUILD))
printf("Silicon version:\t%d\n", zynq_get_silicon_version());
+ if (CONFIG_IS_ENABLED(DM_I2C) && CONFIG_IS_ENABLED(I2C_EEPROM))
+ xilinx_read_eeprom();
+
return 0;
}
--
2.36.1
[PATCH] ARM: zynq: Point via nvmem0 alias to eeprom on zc702/zc706
EEPROM stores identification information about board like a board name,
revision, serial number and ethernet MAC address. U-Boot is capable to read
nvmemX aliases and read/display provided information when nvmem alias link
is described.
Signed-off-by: Michal Simek
---
arch/arm/dts/zynq-zc702.dts | 3 ++-
arch/arm/dts/zynq-zc706.dts | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/zynq-zc702.dts b/arch/arm/dts/zynq-zc702.dts
index 1bd4f8c9f661..99ee87bb2453 100644
--- a/arch/arm/dts/zynq-zc702.dts
+++ b/arch/arm/dts/zynq-zc702.dts
@@ -17,6 +17,7 @@
spi0 =
mmc0 =
usb0 =
+ nvmem0 =
};
memory@0 {
@@ -142,7 +143,7 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <2>;
- eeprom@54 {
+ eeprom: eeprom@54 {
compatible = "atmel,24c08";
reg = <0x54>;
};
diff --git a/arch/arm/dts/zynq-zc706.dts b/arch/arm/dts/zynq-zc706.dts
index cb919e40533e..f0ad68d94f17 100644
--- a/arch/arm/dts/zynq-zc706.dts
+++ b/arch/arm/dts/zynq-zc706.dts
@@ -16,6 +16,7 @@
serial0 =
spi0 =
mmc0 =
+ nvmem0 =
};
memory@0 {
@@ -101,7 +102,7 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <2>;
- eeprom@54 {
+ eeprom: eeprom@54 {
compatible = "atmel,24c08";
reg = <0x54>;
};
--
2.36.1
[PATCH] watchdog: gpio_wdt: use __udelay() to avoid recursion
The udelay() function in lib/time.c contains a WATCHDOG_RESET()
call. The only reason this doesn't lead to a catastrophic infinite
recursion is due to the rate-limiting in wdt-uclass.c:
if (time_after_eq(now, priv->next_reset)) {
priv->next_reset = now + priv->reset_period;
wdt_reset(dev);
}
But this would fall apart if ->next_reset was updated after calling the
device's reset method.
This is needlessly fragile, and it's easy enough to avoid that
recursion in the first place by just using __udelay() directly.
Signed-off-by: Rasmus Villemoes
---
drivers/watchdog/gpio_wdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/gpio_wdt.c b/drivers/watchdog/gpio_wdt.c
index fe06ec8cc9..2920c2c751 100644
--- a/drivers/watchdog/gpio_wdt.c
+++ b/drivers/watchdog/gpio_wdt.c
@@ -31,7 +31,7 @@ static int gpio_wdt_reset(struct udevice *dev)
case HW_ALGO_LEVEL:
/* Pulse */
dm_gpio_set_value(>gpio, 1);
- udelay(1);
+ __udelay(1);
dm_gpio_set_value(>gpio, 0);
break;
}
--
2.37.2
