Re: Pull request: u-boot-sunxi/master fix for v2022.04
On Sat, Mar 26, 2022 at 01:13:22AM +, Andre Przywara wrote: > Hi Tom, > > please pull the master branch from u-boot-sunxi, containing two regression > fixes for 2022.04, related to Allwinner networking: Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 2/2] bootcount: Add pmic pfuze100 bootcount driver
On Fri, Mar 18, 2022 at 12:04:38PM +0100, Philip Oberfichtner wrote: > Use the MEMA - MEMD registers on the PFUZE100 as bootcount > registers. > > Based on work from Heiko Schocher . > Signed-off-by: Philip Oberfichtner Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/2] power: pfuze100: Add MEMx register definitions
On Fri, Mar 18, 2022 at 12:04:37PM +0100, Philip Oberfichtner wrote: > Add missing MEMA - MEMD register definitions for PFUZE100. > > Based on work from Heiko Schocher . > Signed-off-by: Philip Oberfichtner Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/5] disk: Add an option for partitions in SPL
On Fri, Mar 11, 2022 at 12:10:01PM -0700, Simon Glass wrote: > In some cases we do not want to enable partition support in SPL. Add an > option to allow this. > > Signed-off-by: Simon Glass With a slight tweak (as disk/disk-uclass.c isn't in yet), applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/3] ARM: dts: ast2600: Add PWM to device tree
On Tue, Mar 08, 2022 at 11:04:07AM +0800, Billy Tsai wrote: > Add the PWM node and enable it for AST2600 EVB > > Signed-off-by: Billy Tsai > Reviewed-by: Simon Glass > Reviewed-by: Chia-Wei Wang Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/3] pinctrl: Add the pinctrl setting for PWM.
On Tue, Mar 08, 2022 at 11:04:06AM +0800, Billy Tsai wrote: > This patchs add the signal description array for PWM pinctrl settings. > > Signed-off-by: Billy Tsai > Reviewed-by: Simon Glass > Reviewed-by: Chia-Wei Wang Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/3] pwm: Add Aspeed ast2600 PWM support
On Tue, Mar 08, 2022 at 11:04:05AM +0800, Billy Tsai wrote: > This patch add the support of PWM controller which can be found at aspeed > ast2600 soc. The pwm supoorts up to 16 channels and it's part function > of multi-function device "pwm-tach controller". > > Signed-off-by: Billy Tsai > Reviewed-by: Simon Glass > Reviewed-by: Chia-Wei Wang Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] cmd: test: pinmux: Do not check all empty spaces
On Mon, Mar 07, 2022 at 04:48:17PM +0100, Michal Simek wrote: > There is really no value to check empty spaces. That's why use > ut_assert_nextlinen() instead of ut_assert_nextline(). > This change ensures that PINMUX_SIZE can be increased without changing > tests. > > Signed-off-by: Michal Simek > Reviewed-by: Patrice Chotard Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/2] Add option to use -Og
On Tue, Feb 22, 2022 at 12:19:25PM -0500, Sean Anderson wrote: > This adds support for using -Og when building U-Boot. According to the > gcc man page: > > > -Og should be the optimization level of choice for the standard > > edit-compile-debug cycle, offering a reasonable level of optimization > > while maintaining fast compilation and a good debugging experience. > > This optimization level is roughly -O1 minus a few additional > optimizations. It provides a noticably better debugging experience, with > many fewer variables . > > Signed-off-by: Sean Anderson > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] Split CONFIG_CC_OPTIMIZE_FOR_SIZE into two configs
On Tue, Feb 22, 2022 at 12:19:24PM -0500, Sean Anderson wrote: > This adds a separate CONFIG_CC_OPTIMIZE_FOR_SPEED option in a choice, > in preparation for adding another optimization option. Also convert SH's > makefile to use this new option. > > Signed-off-by: Sean Anderson > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm: kirkwood: Add nas440 board, Marvell 88SE6121 AHCI
Hi Hajo,
General comments:
- You're missing a file in this patch set: arch/arm/mach-kirkwood/Kconfig.
- There are numerous style problems. You should run
scripts/checkpatch.pl on each file to cleanup. Also look into using
patman to create patches, and possibly sending patches too. It takes a
bit of getting used to, but patman is very useful. Especially sending
patch series and revisions.
- Please use the canonical form for nas440_defconfig.
make nas440_deconfig
make savedefconfig
mv defconfig configs/nas440_defconfig
- This is a board that is not yet supported in mainline Linux (i.e.
there is no legacy dependency). Thus, we don't want to use ATAGS.
Remove:
> > > +CONFIG_SUPPORT_PASSING_ATAGS=y
> > > +CONFIG_CMDLINE_TAG=y
> > > +CONFIG_INITRD_TAG=y
- This patch will need a revision after Tom's patch is merged to master. See:
https://lists.denx.de/pipermail/u-boot/2022-March/478823.html
Thanks,
Tony
On Thu, Mar 24, 2022 at 3:04 PM Tony Dinh wrote:
>
> Hi Hajo,
>
> I've added Stefan.
>
> When you send patches for Kirkwood or other Marvell boards, please
> also send it directly to Stefan (Stefan is the maintainer of Marvell
> u-boots).
>
> Tony
>
> On Thu, Mar 24, 2022 at 3:11 AM Pali Rohár wrote:
> >
> > Hello!
> >
> > On Thursday 24 March 2022 10:55:38 Hajo Noerenberg wrote:
> > > This adds support for the Seagate Blackarmor NAS440 (4-bay Kirkwood NAS
> > > box).
> > >
> > > Does it make sense to include support for a 10+ year old device?
> >
> > If these old devices are still in use and you would like to maintain
> > this support then I think that there is no issue with it.
> >
> > > If yes, I would be willing to discuss and finalize this patch. If no, it
> > > will be archived here for the public, which is fine with me.
> > >
> > > For the NAS440 is the something special that hard disk drives 1 and 2 are
> > > connected to a 88SE6121 SATA-II controller, which is connected via PCIe.
> > > Hard disk drives 3 and 4 are directly connected to the 88F6281 SoC.
> > >
> > > - Add NAS440 dtb and associated files/configs
> > > * Includes support for HD44780 front LCD
> > > * Includes support for device LEDs (via 74AHC164 shift register)
> > > - Add Marvell 88SE6121 AHCI support. Thanks to Pali Rohár for recently
> > > adding the necessary Kirkwood PCIe driver. It works :)
> >
> > Perfect!
> >
> > > - Tested with my NAS440 hardware: ETH/USB/SATA/AHCI-SCSI/GPIO/LCD/LEDs ok
> > >
> > > As far as I can see this fully implements the support for this board
> > > within U-Boot. With the Linux kernel however there are problems, the
> > > kernel AHCI driver fails with "failed to IDENTIFY" messages for the
> > > 88SE6121 drive ports, which I could not solve yet despite comparison with
> > > the GPL sources from Seagate.
> > >
> > > Note: I am collecting various information and patches for the family of
> > > Blackarmor NAS boards at https://github.com/hn/seagate-blackarmor-nas
> > >
> > > Hajo
> > >
> > >
> > > ---
> > > arch/arm/dts/kirkwood-blackarmor-nas440.dts | 166 +
> > > board/Seagate/nas440/Kconfig| 12 +
> > > board/Seagate/nas440/MAINTAINERS| 7 +
> > > board/Seagate/nas440/Makefile | 7 +
> > > board/Seagate/nas440/kwbimage.cfg | 156
> > > board/Seagate/nas440/nas440.c | 378
> > > configs/nas440_defconfig| 89 +
> > > drivers/ata/ahci-pci.c | 1 +
> > > include/configs/nas440.h| 50 +++
> > > 9 files changed, 866 insertions(+)
> > > create mode 100644 arch/arm/dts/kirkwood-blackarmor-nas440.dts
> > > create mode 100644 board/Seagate/nas440/Kconfig
> > > create mode 100644 board/Seagate/nas440/MAINTAINERS
> > > create mode 100644 board/Seagate/nas440/Makefile
> > > create mode 100644 board/Seagate/nas440/kwbimage.cfg
> > > create mode 100644 board/Seagate/nas440/nas440.c
> > > create mode 100644 configs/nas440_defconfig
> > > create mode 100644 include/configs/nas440.h
> > >
> > > diff --git a/arch/arm/dts/kirkwood-blackarmor-nas440.dts
> > > b/arch/arm/dts/kirkwood-blackarmor-nas440.dts
> > > new file mode 100644
> > > index 00..60e3fe6f0d
> > > --- /dev/null
> > > +++ b/arch/arm/dts/kirkwood-blackarmor-nas440.dts
> > > @@ -0,0 +1,166 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * Device Tree file for Seagate Blackarmor NAS440
> > > + *
> > > + * Copyright (C) 2021 Hajo Noerenberg
> > > + * Copyright (C) 2015 Andreas Fischer
> > > + * Copyright (C) 2014 Evgeni Dobrev
> > > + */
> > > +
> > > +/dts-v1/;
> > > +
> > > +#include
> > > +#include
> > > +#include "kirkwood.dtsi"
> > > +#include "kirkwood-6281.dtsi"
> > > +
> > > +/ {
> > > + model = "Seagate Blackarmor NAS440";
> > > + compatible = "seagate,blackarmor-nas440","marvell,kirkwood-88f6281",
> > > + "marvell,kirkwood";
> > > +
> > > + memory { /* 256 MB */
> > > + device_type =
Pull request: u-boot-sunxi/master fix for v2022.04
Hi Tom, please pull the master branch from u-boot-sunxi, containing two regression fixes for 2022.04, related to Allwinner networking: - - Fix A20 GBit Ethernet operation - Update board .dts files to provide correct RGMII PHY mode - Tested on BananaPi M1, Pine64 LTS, and Pine H64. Thanks, Andre === The following changes since commit cbc05bba8cb7da62eae65f41e1b0ddbcadc06bba: doc: update doc/sphinx/requirements.txt (2022-03-25 08:59:49 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master for you to fetch changes up to 85da5587629b12220c2f19ac0780ca8f4c482f16: sunxi: dts: Update RGMII phy-mode properties (2022-03-26 00:16:44 +) Andre Przywara (2): sunxi: Fix old GMAC pinmux setup sunxi: dts: Update RGMII phy-mode properties arch/arm/dts/sun50i-a64-sopine-baseboard.dts | 2 +- arch/arm/dts/sun50i-h5-nanopi-neo2.dts| 2 +- arch/arm/dts/sun50i-h5-orangepi-zero-plus.dts | 2 +- arch/arm/dts/sun6i-a31-hummingbird.dts| 2 +- arch/arm/dts/sun7i-a20-bananapi-m1-plus.dts | 2 +- arch/arm/dts/sun7i-a20-bananapi.dts | 2 +- arch/arm/dts/sun7i-a20-bananapro.dts | 2 +- arch/arm/dts/sun7i-a20-cubietruck.dts | 2 +- arch/arm/dts/sun7i-a20-olinuxino-lime2.dts| 2 +- arch/arm/dts/sun7i-a20-pcduino3-nano.dts | 2 +- arch/arm/dts/sun8i-a83t-bananapi-m3.dts | 2 +- arch/arm/dts/sun8i-a83t-cubietruck-plus.dts | 2 +- arch/arm/dts/sun8i-h3-orangepi-plus.dts | 2 +- arch/arm/dts/sunxi-bananapi-m2-plus.dtsi | 2 +- arch/arm/mach-sunxi/board.c | 1 - board/sunxi/board.c | 3 +++ 16 files changed, 17 insertions(+), 15 deletions(-)
Re: [PATCH] pci: Add defines for normal and subtractive PCI bridges
On Fri, Feb 18, 2022 at 01:18:40PM +0100, Pali Rohár wrote: > Add following two new PCI class codes defines into pci_ids.h include file: > > PCI_CLASS_BRIDGE_PCI_NORMAL > PCI_CLASS_BRIDGE_PCI_SUBTRACTIVE > > And use these defines in all U-Boot code for describing PCI class codes for > normal and subtractive PCI bridges. > > Signed-off-by: Pali Rohár > Reviewed-by: Stefan Roese Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/2] pci: Remove duplicate PCI_CLASS_CODE_* and PCI_CLASS_SUB_CODE_* macros
On Fri, Feb 18, 2022 at 01:16:19PM +0100, Pali Rohár wrote: > Macros PCI_CLASS_CODE_* and PCI_CLASS_SUB_CODE_* are unused and are > duplication of PCI_CLASS_* macros defined in pci_ids.h header file. > So remove them. > > Signed-off-by: Pali Rohár > Reviewed-by: Stefan Roese Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] sandbox: video: Replace PCI_CLASS_* macros by one from pci_ids.h
On Fri, Feb 18, 2022 at 01:16:18PM +0100, Pali Rohár wrote: > Replace old macros PCI_CLASS_CODE_COMM and PCI_CLASS_SUB_CODE_COMM_SERIAL > by new macros defined in pci_ids.h. Old macros would be deleted in followup > commit. > > Signed-off-by: Pali Rohár > Reviewed-by: Stefan Roese Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v7 14/16] test: py: vboot: add test for global image signature
On Fri, Mar 25, 2022 at 11:54:18PM +0100, Philippe REYNES wrote: > Hi Tom, > > > Le 25/03/2022 à 18:11, Tom Rini a écrit : > > On Mon, Mar 14, 2022 at 03:57:43PM +0100, Philippe Reynes wrote: > > > > > Adds test units for the pre-load header signature. > > > > > > Signed-off-by: Philippe Reynes > > > --- > > > test/py/tests/test_vboot.py | 145 -- > > > test/py/tests/vboot/sandbox-binman-pss.dts| 25 +++ > > > test/py/tests/vboot/sandbox-binman.dts| 24 +++ > > > .../tests/vboot/sandbox-u-boot-global-pss.dts | 28 > > > test/py/tests/vboot/sandbox-u-boot-global.dts | 27 > > > test/py/tests/vboot/simple-images.its | 36 + > > > 6 files changed, 269 insertions(+), 16 deletions(-) > > > create mode 100644 test/py/tests/vboot/sandbox-binman-pss.dts > > > create mode 100644 test/py/tests/vboot/sandbox-binman.dts > > > create mode 100644 test/py/tests/vboot/sandbox-u-boot-global-pss.dts > > > create mode 100644 test/py/tests/vboot/sandbox-u-boot-global.dts > > > create mode 100644 test/py/tests/vboot/simple-images.its > > This leads to CI failures such as: > > https://source.denx.de/u-boot/u-boot/-/jobs/412046 > > and I guess maybe we need something new in test/py/requirements.txt > > maybe? > > I think that this issue should be fixed with this patch : > > https://patchwork.ozlabs.org/project/uboot/patch/20220127140314.10264-2-philippe.rey...@softathome.com/ OK, but that's a rather specific hard-coded path to add, and won't work in my setup for example since I use mktemp to make the base dir for all my tests. -- Tom signature.asc Description: PGP signature
Re: [PATCH v7 14/16] test: py: vboot: add test for global image signature
Hi Tom, Le 25/03/2022 à 18:11, Tom Rini a écrit : On Mon, Mar 14, 2022 at 03:57:43PM +0100, Philippe Reynes wrote: Adds test units for the pre-load header signature. Signed-off-by: Philippe Reynes --- test/py/tests/test_vboot.py | 145 -- test/py/tests/vboot/sandbox-binman-pss.dts| 25 +++ test/py/tests/vboot/sandbox-binman.dts| 24 +++ .../tests/vboot/sandbox-u-boot-global-pss.dts | 28 test/py/tests/vboot/sandbox-u-boot-global.dts | 27 test/py/tests/vboot/simple-images.its | 36 + 6 files changed, 269 insertions(+), 16 deletions(-) create mode 100644 test/py/tests/vboot/sandbox-binman-pss.dts create mode 100644 test/py/tests/vboot/sandbox-binman.dts create mode 100644 test/py/tests/vboot/sandbox-u-boot-global-pss.dts create mode 100644 test/py/tests/vboot/sandbox-u-boot-global.dts create mode 100644 test/py/tests/vboot/simple-images.its This leads to CI failures such as: https://source.denx.de/u-boot/u-boot/-/jobs/412046 and I guess maybe we need something new in test/py/requirements.txt maybe? I think that this issue should be fixed with this patch : https://patchwork.ozlabs.org/project/uboot/patch/20220127140314.10264-2-philippe.rey...@softathome.com/ The rest of the series seems fine, btw. great, thanks a lot Regards, Philippe
Re: [PATCH 1/2] net: dsa: fix phydev->speed being uninitialized for the CPU port fixed PHY
On Fri, Mar 25, 2022 at 11:07 AM Vladimir Oltean
wrote:
>
> Hi Tim,
>
> On Fri, Mar 25, 2022 at 09:53:20AM -0700, Tim Harvey wrote:
> > Vladimir,
> >
> > I came across this while looking for the best place to configure cpu
> > port interface mode (ie rgmii id) for the mv88e61xx dsa driver I'm
> > working on. Note that this patch causes port_probe to be called on the
> > cpu port 'before' the master device has been probed. I'm not sure if
> > this is intended or not?
> >
> > In my case I was looking to configure the cpu port interface mode when
> > the port was probed but I can't do that because it happens before the
> > switch is probed because of some things that need to happen there.
> > Best Regards,
> >
> > Tim
>
> You're past the DM_MDIO probing issues now? Glad to hear that.
> Probing the DSA CPU port before the master wasn't necessarily the
> intention, but then again, I'm not sure that there's a strict ordering
> guarantee between the two that needs to be satisfied?
>
> What do you need exactly? We could probably always reverse the
> device_probe(master) call with the probing of the CPU port if the
> ordering turns out to be a real problem. I can regression-test the
> change on my boards, but I'd like to understand the need you have, maybe
> even document it so that future changes are aware of it.
Yes, I've got the mdio probing working now. The mv88e61xx driver
supports several chips that have different register offsets that need
to be known before indirect read/write and port read/write can be
used. That detection happens early on so I have it in the dsa_probe. I
would prefer to configure the cpu port interface mode (mac mode, link
speed/duplex etc) once instead of doing it every time the cpu port
gets enabled so I want to put that in the dsa_probe but at that time I
don't have the phy_device to determine interface mode (I suppose I
could get it from dt?). I noticed dsa_class calls ops->port_probe for
the cpu port early so that seemed like a great place to do all that,
but then I found my switch dsa_probe hadn't been called yet so I
haven't identified the switch and set the register offsets yet.
I have worked around the fact that the port_probe is called for the
cpu port before the switch is probed I just wasn't sure if something
in this patch should be changed in case others fall into this trap in
the future. dsa_port_probe probes the master before calling
ops->port_probe with the comment 'We depend on the master device for
proper operation' so I just figured the same should be done for the
pre_probe.
I hope to send a series in the next few days but I do have a few items
I still need to fix:
1. my board currently uses the mv88e61xx_hw_reset weak override to
configure LEDs, GPIO's using direct register writes as I need one of
the GPIO's to be configured as a 125MHz RGMII_RCLK and configure MAC
interface mode(rgmii delays). I've moved the mac interface config into
the driver based on the dt props (phy-mode and fixed-link subnode) but
am still not sure how to go about dealing with the 'very custom' LED
and GPIO config without the hassle of defining new dt bindings. I was
hoping to use board_phy_config() but when that is called for the
switch the phy_id is a generic PHY_FIXED_ID and when called for the
ports the phydev->bus uses indirect register writes which can't be
used to configure the gpios.
2. While my switch mdio bus is probing now as well as my fec_dm_mdio
bus I'm not clear how to properly get the struct mii_dev * associated
with the fec_dm_mdio from the dsa switch. Currently I'm using
miiphy_get_dev_by_name("mdio") which is horrible. How do I get the
mii_bus or even the udevice of an dm_mdio bus associated with a dm_eth
device?
Best Regards,
Tim
Re: [1/3] pinctrl: mediatek: rewrite mtk_pinconf_set and related functions
On Thu, Mar 10, 2022 at 12:31:43PM +0800, Sam Shih wrote: > There are many pins in a SoCs, and different pin may belong > to different "io_type", For example: some pins of MT7622 belongs > to "io_type A", the other belongs to "io_type B", and pinctrl "V0" > means handle pinconf via "io_type A" or "io_type B", so SoCs that > contain "io_type A" and "io_type B" pins, use "V0" in pinctrl driver. > > This patch separates the implementation of register operations > (e.g: "bias-pull-up/down", "driving" and "input-enable") into > different functions, and lets the original V0/V1 > ops to call the new functions. > > Signed-off-by: Sam Shih This series breaks mt7623a_unielec_u7623_02 and other mediatek platforms, please retest and resubmit, thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH] ARM: imx: Decode ECSPI env location from i.MX8M ROMAPI tables
Hi Marek, On 25/03/2022 14:59, Marek Vasut wrote: Decode ECSPI boot device in env_get_location() from i.MX8M ROMAPI tables. This is necessary to correctly identify env is in SPI NOR when the system boots from SPI NOR attached to ECSPI. Signed-off-by: Marek Vasut Cc: Fabio Estevam Cc: Peng Fan Cc: Stefano Babic Reviewed-by: Fabio Estevam
Re: [PATCH v4 9/9] configs: imx8mm_evk: add pwm backlight support
Hi Tommaso, On Fri, Mar 25, 2022 at 9:04 AM Tommaso Merciai wrote: > > Enable support for backlight/pwm-imx driver > > Signed-off-by: Tommaso Merciai > --- > configs/imx8mm_evk_defconfig | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/configs/imx8mm_evk_defconfig b/configs/imx8mm_evk_defconfig > index 01395fc7eb..cfba6cc673 100644 > --- a/configs/imx8mm_evk_defconfig > +++ b/configs/imx8mm_evk_defconfig > @@ -84,3 +84,8 @@ CONFIG_SYSRESET_PSCI=y > CONFIG_SYSRESET_WATCHDOG=y > CONFIG_DM_THERMAL=y > CONFIG_IMX_WATCHDOG=y > +CONFIG_DM_VIDEO=y There is no video driver for imx8mm yet, so you could drop this one, right?
Re: [PATCH 1/2] net: dsa: fix phydev->speed being uninitialized for the CPU port fixed PHY
Hi Tim, On Fri, Mar 25, 2022 at 09:53:20AM -0700, Tim Harvey wrote: > Vladimir, > > I came across this while looking for the best place to configure cpu > port interface mode (ie rgmii id) for the mv88e61xx dsa driver I'm > working on. Note that this patch causes port_probe to be called on the > cpu port 'before' the master device has been probed. I'm not sure if > this is intended or not? > > In my case I was looking to configure the cpu port interface mode when > the port was probed but I can't do that because it happens before the > switch is probed because of some things that need to happen there. > Best Regards, > > Tim You're past the DM_MDIO probing issues now? Glad to hear that. Probing the DSA CPU port before the master wasn't necessarily the intention, but then again, I'm not sure that there's a strict ordering guarantee between the two that needs to be satisfied? What do you need exactly? We could probably always reverse the device_probe(master) call with the probing of the CPU port if the ordering turns out to be a real problem. I can regression-test the change on my boards, but I'd like to understand the need you have, maybe even document it so that future changes are aware of it.
[PATCH] ARM: imx: Decode ECSPI env location from i.MX8M ROMAPI tables
Decode ECSPI boot device in env_get_location() from i.MX8M ROMAPI tables.
This is necessary to correctly identify env is in SPI NOR when the system
boots from SPI NOR attached to ECSPI.
Signed-off-by: Marek Vasut
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Stefano Babic
---
arch/arm/include/asm/mach-imx/sys_proto.h | 1 +
arch/arm/mach-imx/imx8m/soc.c | 4
2 files changed, 5 insertions(+)
diff --git a/arch/arm/include/asm/mach-imx/sys_proto.h
b/arch/arm/include/asm/mach-imx/sys_proto.h
index 0c0c7814fb2..309f8d17959 100644
--- a/arch/arm/include/asm/mach-imx/sys_proto.h
+++ b/arch/arm/include/asm/mach-imx/sys_proto.h
@@ -159,6 +159,7 @@ enum boot_dev_type_e {
BT_DEV_TYPE_MMC = 2,
BT_DEV_TYPE_NAND = 3,
BT_DEV_TYPE_FLEXSPINOR = 4,
+ BT_DEV_TYPE_SPI_NOR = 6,
BT_DEV_TYPE_USB = 0xE,
BT_DEV_TYPE_MEM_DEV = 0xF,
diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index 1a5a391443d..ccbbe545810 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -597,6 +597,9 @@ enum boot_device get_boot_device(void)
case BT_DEV_TYPE_FLEXSPINOR:
boot_dev = QSPI_BOOT;
break;
+ case BT_DEV_TYPE_SPI_NOR:
+ boot_dev = SPI_NOR_BOOT;
+ break;
case BT_DEV_TYPE_USB:
boot_dev = USB_BOOT;
break;
@@ -1335,6 +1338,7 @@ enum env_location env_get_location(enum env_operation op,
int prio)
switch (dev) {
case QSPI_BOOT:
+ case SPI_NOR_BOOT:
if (IS_ENABLED(CONFIG_ENV_IS_IN_SPI_FLASH))
return ENVL_SPI_FLASH;
return ENVL_NOWHERE;
--
2.35.1
Re: [PATCH v7 14/16] test: py: vboot: add test for global image signature
On Mon, Mar 14, 2022 at 03:57:43PM +0100, Philippe Reynes wrote: > Adds test units for the pre-load header signature. > > Signed-off-by: Philippe Reynes > --- > test/py/tests/test_vboot.py | 145 -- > test/py/tests/vboot/sandbox-binman-pss.dts| 25 +++ > test/py/tests/vboot/sandbox-binman.dts| 24 +++ > .../tests/vboot/sandbox-u-boot-global-pss.dts | 28 > test/py/tests/vboot/sandbox-u-boot-global.dts | 27 > test/py/tests/vboot/simple-images.its | 36 + > 6 files changed, 269 insertions(+), 16 deletions(-) > create mode 100644 test/py/tests/vboot/sandbox-binman-pss.dts > create mode 100644 test/py/tests/vboot/sandbox-binman.dts > create mode 100644 test/py/tests/vboot/sandbox-u-boot-global-pss.dts > create mode 100644 test/py/tests/vboot/sandbox-u-boot-global.dts > create mode 100644 test/py/tests/vboot/simple-images.its This leads to CI failures such as: https://source.denx.de/u-boot/u-boot/-/jobs/412046 and I guess maybe we need something new in test/py/requirements.txt maybe? The rest of the series seems fine, btw. -- Tom signature.asc Description: PGP signature
[PATCH] rockchip: clk: add clocks to px30_clk_enable
From: Chris Morgan
Add the HCLK_OTG, HCLK_SFC, and SCLK_SFC clocks to px30_clk_enable.
Without this change U-Boot reports an error of "Enable
clock-controller@ff2b failed" on boot when using the SFC or USB in
U-Boot.
Signed-off-by: Chris Morgan
---
drivers/clk/rockchip/clk_px30.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/clk/rockchip/clk_px30.c b/drivers/clk/rockchip/clk_px30.c
index ea874e3f4b..5d467447a1 100644
--- a/drivers/clk/rockchip/clk_px30.c
+++ b/drivers/clk/rockchip/clk_px30.c
@@ -1403,10 +1403,13 @@ static int px30_clk_enable(struct clk *clk)
{
switch (clk->id) {
case HCLK_HOST:
+ case HCLK_OTG:
+ case HCLK_SFC:
case SCLK_GMAC:
case SCLK_GMAC_RX_TX:
case SCLK_MAC_REF:
case SCLK_MAC_REFOUT:
+ case SCLK_SFC:
case ACLK_GMAC:
case PCLK_GMAC:
case SCLK_GMAC_RMII:
--
2.25.1
[PATCH] doc: man-page for the wdt command
Describe the wdt command. Signed-off-by: Heinrich Schuchardt --- doc/usage/index.rst | 1 + doc/usage/wdt.rst | 77 + 2 files changed, 78 insertions(+) create mode 100644 doc/usage/wdt.rst diff --git a/doc/usage/index.rst b/doc/usage/index.rst index 0aacf531b2..630a6cb28a 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -52,3 +52,4 @@ Shell commands size true ums + wdt diff --git a/doc/usage/wdt.rst b/doc/usage/wdt.rst new file mode 100644 index 00..8d80433c1f --- /dev/null +++ b/doc/usage/wdt.rst @@ -0,0 +1,77 @@ +.. SPDX-License-Identifier: GPL-2.0+: + +wdt command + + +Synopsis + + +:: + +wdt list +wdt dev [] +wdt start [flags] +wdt stop +wdt reset +wdt expirer [flags] + +Description +--- + +The wdt command is used to control watchdog timers. + +The 'wdt list' command shows a list of all watchdog devices. + +The 'wdt dev' command called without argument shows the current watchdog device. +The current device is set when passing the name of the device as argument. + +The 'wdt start' command starts the current watchdog timer. + +The 'wdt stop' command stops the current watchdog timer. + +The 'wdt reset' command resets the current watchdog timer without stopping it. + +The 'wdt expire' command let's the current watchdog timer expire immediately. +This will lead to a reset. + +name +name of the watchdog device + +timeout_ms +timeout interval in milliseconds + +flags +unsigned long value passed to the driver. The usage is driver specific. +The value is ignored by most drivers. + +Example +--- + +:: + +=> wdt dev +No watchdog timer device set! +=> wdt list +watchdog@1c20ca0 (sunxi_wdt) +=> wdt dev watchdog@1c20ca0 +=> wdt dev +dev: watchdog@1c20ca0 +=> wdt start 3000 +=> wdt reset +=> wdt stop +=> wdt expire + +U-Boot SPL 2022.04-rc3 (Mar 25 2022 - 13:48:33 +) + + In the example above '(sunxi_wdt)' refers to the driver for the watchdog + device. + +Configuration +- + +The command is only available if CONFIG_CMD_WDT=y. + +Return value + + +The return value $? is 0 if the command succeeds, 1 upon failure. -- 2.34.1
Re: [PATCH 1/2] net: dsa: fix phydev->speed being uninitialized for the CPU port fixed PHY
On Sat, Dec 4, 2021 at 3:01 PM Vladimir Oltean wrote:
>
> If the DSA API is going to allow drivers to do things such as:
>
> - phy_config in dsa_ops :: port_probe
> - phy_startup in dsa_ops :: port_enable
>
> then it would actually be good if the ->port_probe() method would
> actually be called in all cases before the ->port_enable() is.
>
> Currently this is true for user ports, but not true for the CPU port,
> because the CPU port does not have a udevice registered for it (this is
> all part of DSA's design). So the current issue is that after
> phy_startup has finished for the CPU port, its phydev->speed is an
> uninitialized value, because phy_config() was never called for the
> priv->cpu_port_fixed_phy, and it is precisely phy_config() who copies
> the speed into the phydev in the case of the fixed PHY driver.
>
> So we need to simulate a probing event for the CPU port by manually
> calling the driver's ->port_probe() method for the CPU port.
>
> Fixes: 8a2982574854 ("net: dsa: introduce a .port_probe() method in struct
> dsa_ops")
> Signed-off-by: Vladimir Oltean
> ---
> net/dsa-uclass.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c
> index 606b1539a776..9ff55a02fb23 100644
> --- a/net/dsa-uclass.c
> +++ b/net/dsa-uclass.c
> @@ -466,6 +466,8 @@ static int dsa_pre_probe(struct udevice *dev)
> {
> struct dsa_pdata *pdata = dev_get_uclass_plat(dev);
> struct dsa_priv *priv = dev_get_uclass_priv(dev);
> + struct dsa_ops *ops = dsa_get_ops(dev);
> + int err;
>
> priv->num_ports = pdata->num_ports;
> priv->cpu_port = pdata->cpu_port;
> @@ -477,6 +479,15 @@ static int dsa_pre_probe(struct udevice *dev)
>
> uclass_find_device_by_ofnode(UCLASS_ETH, pdata->master_node,
> >master_dev);
> +
> + /* Simulate a probing event for the CPU port */
> + if (ops->port_probe) {
> + err = ops->port_probe(dev, priv->cpu_port,
> + priv->cpu_port_fixed_phy);
> + if (err)
> + return err;
> + }
> +
> return 0;
> }
>
> --
> 2.25.1
>
Vladimir,
I came across this while looking for the best place to configure cpu
port interface mode (ie rgmii id) for the mv88e61xx dsa driver I'm
working on. Note that this patch causes port_probe to be called on the
cpu port 'before' the master device has been probed. I'm not sure if
this is intended or not?
In my case I was looking to configure the cpu port interface mode when
the port was probed but I can't do that because it happens before the
switch is probed because of some things that need to happen there.
Best Regards,
Tim
[PATCH] spi: rockchip_sfc: Add missing include for dm/device_compat.h
From: Chris Morgan Add missing include for dm/device_compat.h. Without this include the SFC driver fails to compile because dev_err and dev_dbg are not defined. Signed-off-by: Chris Morgan --- drivers/spi/rockchip_sfc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/spi/rockchip_sfc.c b/drivers/spi/rockchip_sfc.c index e098ac..851a648298 100644 --- a/drivers/spi/rockchip_sfc.c +++ b/drivers/spi/rockchip_sfc.c @@ -12,6 +12,7 @@ #include #include #include +#include #include #include #include -- 2.25.1
Re: [PATCH v3 2/3] efi_loader: initrddump: drain input before prompt
On Tue, 22 Mar 2022 at 22:58, Heinrich Schuchardt
wrote:
>
> Up to now the initrddump.efi application has drained the input after
> showing the prompt. This works for humans but leads to problems when
> automating testing. If the input is drained, this should be done before
> showing the prompt.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> v3:
> new patch
> ---
> lib/efi_loader/initrddump.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/lib/efi_loader/initrddump.c b/lib/efi_loader/initrddump.c
> index 25dbd635e5..4dd40eb0d3 100644
> --- a/lib/efi_loader/initrddump.c
> +++ b/lib/efi_loader/initrddump.c
> @@ -120,6 +120,14 @@ static void printx(u64 val, u32 prec)
> print(buf);
> }
>
> +/**
> + * efi_drain_input() - drain console input
> + */
> +static void efi_drain_input(void)
> +{
> + cin->reset(cin, true);
> +}
> +
> /**
> * efi_input_yn() - get answer to yes/no question
> *
> @@ -137,8 +145,6 @@ static efi_status_t efi_input_yn(void)
> efi_uintn_t index;
> efi_status_t ret;
>
> - /* Drain the console input */
> - ret = cin->reset(cin, true);
> for (;;) {
> ret = bs->wait_for_event(1, >wait_for_key, );
> if (ret != EFI_SUCCESS)
> @@ -179,8 +185,6 @@ static efi_status_t efi_input(u16 *buffer, efi_uintn_t
> buffer_size)
> u16 outbuf[2] = u" ";
> efi_status_t ret;
>
> - /* Drain the console input */
> - ret = cin->reset(cin, true);
> *buffer = 0;
> for (;;) {
> ret = bs->wait_for_event(1, >wait_for_key, );
> @@ -393,6 +397,7 @@ static efi_status_t do_save(u16 *filename)
> ret = root->open(root, , filename, EFI_FILE_MODE_READ, 0);
> if (ret == EFI_SUCCESS) {
> file->close(file);
> + efi_drain_input();
> print(u"Overwrite existing file (y/n)? ");
> ret = efi_input_yn();
> print(u"\r\n");
> @@ -486,6 +491,7 @@ efi_status_t EFIAPI efi_main(efi_handle_t image_handle,
> u16 *pos;
> efi_uintn_t ret;
>
> + efi_drain_input();
> print(u"=> ");
> ret = efi_input(command, sizeof(command));
> if (ret == EFI_ABORTED)
> --
> 2.34.1
>
Acked-by: Ilias Apalodimas
Re: [PATCH v3 1/3] efi_loader: nocolor command line attr for initrddump.efi
Hi Heinrich,
On Tue, 22 Mar 2022 at 22:58, Heinrich Schuchardt
wrote:
>
> initrddump.efi uses colored output and clear the screen. This is not
> helpful for integration into Python tests. Allow specifying 'nocolor' in
> the load option data to suppress color output and clearing the screen.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> v3:
> new patch
> ---
> lib/efi_loader/initrddump.c | 77 -
> 1 file changed, 68 insertions(+), 9 deletions(-)
>
> diff --git a/lib/efi_loader/initrddump.c b/lib/efi_loader/initrddump.c
> index 7de43bcfff..25dbd635e5 100644
> --- a/lib/efi_loader/initrddump.c
> +++ b/lib/efi_loader/initrddump.c
> @@ -4,6 +4,9 @@
> *
> * initrddump.efi saves the initial RAM disk provided via the
> * EFI_LOAD_FILE2_PROTOCOL.
> + *
> + * Specifying 'nocolor' as load option data suppresses colored output and
> + * clearing of the screen.
> */
>
> #include
> @@ -25,6 +28,7 @@ static const efi_guid_t guid_simple_file_system_protocol =
> EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID;
> static const efi_guid_t load_file2_guid = EFI_LOAD_FILE2_PROTOCOL_GUID;
> static efi_handle_t handle;
> +static bool nocolor;
>
> /*
> * Device path defined by Linux to identify the handle providing the
> @@ -46,6 +50,17 @@ static const struct efi_initrd_dp initrd_dp = {
> }
> };
>
> +/**
> + * color() - set foreground color
> + *
> + * @color: foreground color
> + */
> +static void color(u8 color)
> +{
> + if (!nocolor)
> + cout->set_attribute(cout, color | EFI_BACKGROUND_BLACK);
> +}
> +
> /**
> * print() - print string
> *
> @@ -56,6 +71,17 @@ static void print(u16 *string)
> cout->output_string(cout, string);
> }
>
> +/**
> + * cls() - clear screen
> + */
> +static void cls(void)
> +{
> + if (nocolor)
> + print(u"\r\n");
> + else
> + cout->clear_screen(cout);
> +}
> +
> /**
> * error() - print error string
> *
> @@ -63,9 +89,9 @@ static void print(u16 *string)
> */
> static void error(u16 *string)
> {
> - cout->set_attribute(cout, EFI_LIGHTRED | EFI_BACKGROUND_BLACK);
> + color(EFI_LIGHTRED);
> print(string);
> - cout->set_attribute(cout, EFI_LIGHTBLUE | EFI_BACKGROUND_BLACK);
> + color(EFI_LIGHTBLUE);
> }
>
> /*
> @@ -215,10 +241,13 @@ static u16 *skip_whitespace(u16 *pos)
> *
> * @string:string to search for keyword
> * @keyword: keyword to be searched
> - * Return: true fi @string starts with the keyword
> + * Return: true if @string starts with the keyword
> */
> static bool starts_with(u16 *string, u16 *keyword)
> {
> + if (!string || !keyword)
> + return false;
> +
> for (; *keyword; ++string, ++keyword) {
> if (*string != *keyword)
> return false;
> @@ -400,6 +429,30 @@ out:
> return ret;
> }
>
> +/**
> + * get_load_options() - get load options
> + *
> + * Return: load options or NULL
> + */
> +u16 *get_load_options(void)
> +{
> + efi_status_t ret;
> + struct efi_loaded_image *loaded_image;
> +
> + ret = bs->open_protocol(handle, _image_guid,
> + (void **)_image, NULL, NULL,
> + EFI_OPEN_PROTOCOL_GET_PROTOCOL);
> + if (ret != EFI_SUCCESS) {
> + error(u"Loaded image protocol not found\r\n");
> + return NULL;
> + }
> +
> + if (!loaded_image->load_options_size || !loaded_image->load_options)
> + return NULL;
> +
> + return loaded_image->load_options;
> +}
> +
> /**
> * efi_main() - entry point of the EFI application.
> *
> @@ -410,18 +463,23 @@ out:
> efi_status_t EFIAPI efi_main(efi_handle_t image_handle,
> struct efi_system_table *systab)
> {
> + u16 *load_options;
> +
> handle = image_handle;
> systable = systab;
> cerr = systable->std_err;
> cout = systable->con_out;
> cin = systable->con_in;
> bs = systable->boottime;
> + load_options = get_load_options();
Don't we need to check for NULL here?
>
> - cout->set_attribute(cout, EFI_LIGHTBLUE | EFI_BACKGROUND_BLACK);
> - cout->clear_screen(cout);
> - cout->set_attribute(cout, EFI_WHITE | EFI_BACKGROUND_BLACK);
> + if (starts_with(load_options, u"nocolor"))
> + nocolor = true;
> +
> + color(EFI_WHITE);
> + cls();
> print(u"INITRD Dump\r\n===\r\n\r\n");
> - cout->set_attribute(cout, EFI_LIGHTBLUE | EFI_BACKGROUND_BLACK);
> + color(EFI_LIGHTBLUE);
>
> for (;;) {
> u16 command[BUFFER_SIZE];
> @@ -443,7 +501,8 @@ efi_status_t EFIAPI efi_main(efi_handle_t image_handle,
> do_help();
> }
>
> - cout->set_attribute(cout, EFI_LIGHTGRAY | EFI_BACKGROUND_BLACK);
> -
Re: [RFC PATCH 6/6] mkeficapsule: Remove raw and FIT GUID types
Hi,
On Thu, 24 Mar 2022 at 17:34, Sughosh Ganu wrote:
>
> On Thu, 24 Mar 2022 at 20:40, Michal Simek wrote:
> >
> >
> >
> > On 3/24/22 15:51, Sughosh Ganu wrote:
> > > On Thu, 24 Mar 2022 at 19:55, Michal Simek
> > > wrote:
> > >>
> > >>
> > >>
> > >> On 3/24/22 13:39, Sughosh Ganu wrote:
> > >>> While building a capsule, the GUID value of that specific image is to
> > >>> be passed through the --guid command option to the mkeficapsule
> > >>> tool. This renders the EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID and
> > >>> EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID values superfluous. Remove the
> > >>> --raw and --fit command line options as well.
> > >>>
> > >>> Signed-off-by: Sughosh Ganu
> > >>> ---
> > >>>tools/eficapsule.h | 8
> > >>>tools/mkeficapsule.c | 26 +-
> > >>>2 files changed, 1 insertion(+), 33 deletions(-)
> > >>>
> > >>> diff --git a/tools/eficapsule.h b/tools/eficapsule.h
> > >>> index 69c9c58c2f..d63b831443 100644
> > >>> --- a/tools/eficapsule.h
> > >>> +++ b/tools/eficapsule.h
> > >>> @@ -37,14 +37,6 @@ typedef struct {
> > >>>EFI_GUID(0x6dcbd5ed, 0xe82d, 0x4c44, 0xbd, 0xa1, \
> > >>> 0x71, 0x94, 0x19, 0x9a, 0xd9, 0x2a)
> > >>>
> > >>> -#define EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID \
> > >>> - EFI_GUID(0xae13ff2d, 0x9ad4, 0x4e25, 0x9a, 0xc8, \
> > >>> - 0x6d, 0x80, 0xb3, 0xb2, 0x21, 0x47)
> > >>> -
> > >>> -#define EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID \
> > >>> - EFI_GUID(0xe2bb9c06, 0x70e9, 0x4b14, 0x97, 0xa3, \
> > >>> - 0x5a, 0x79, 0x13, 0x17, 0x6e, 0x3f)
> > >>> -
> > >>>#define EFI_CERT_TYPE_PKCS7_GUID \
> > >>>EFI_GUID(0x4aafd29d, 0x68df, 0x49ee, 0x8a, 0xa9, \
> > >>> 0x34, 0x7d, 0x37, 0x56, 0x65, 0xa7)
> > >>> diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
> > >>> index c118335b93..5f74d23b9e 100644
> > >>> --- a/tools/mkeficapsule.c
> > >>> +++ b/tools/mkeficapsule.c
> > >>> @@ -27,17 +27,11 @@
> > >>>static const char *tool_name = "mkeficapsule";
> > >>>
> > >>>efi_guid_t efi_guid_fm_capsule =
> > >>> EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID;
> > >>> -efi_guid_t efi_guid_image_type_uboot_fit =
> > >>> - EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID;
> > >>> -efi_guid_t efi_guid_image_type_uboot_raw =
> > >>> - EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID;
> > >>>efi_guid_t efi_guid_cert_type_pkcs7 = EFI_CERT_TYPE_PKCS7_GUID;
> > >>>
> > >>> -static const char *opts_short = "frg:i:I:v:p:c:m:dh";
> > >>> +static const char *opts_short = "g:i:I:v:p:c:m:dh";
> > >>>
> > >>>static struct option options[] = {
> > >>> - {"fit", no_argument, NULL, 'f'},
> > >>> - {"raw", no_argument, NULL, 'r'},
> > >>>{"guid", required_argument, NULL, 'g'},
> > >>>{"index", required_argument, NULL, 'i'},
> > >>>{"instance", required_argument, NULL, 'I'},
> > >>> @@ -54,8 +48,6 @@ static void print_usage(void)
> > >>>fprintf(stderr, "Usage: %s [options] > >>> file>\n"
> > >>>"Options:\n"
> > >>>
> > >>> - "\t-f, --fit FIT image type\n"
> > >>> - "\t-r, --raw raw image type\n"
> > >>>"\t-g, --guid guid for image blob
> > >>> type\n"
> > >>>"\t-i, --index update image index\n"
> > >>>"\t-I, --instanceupdate hardware
> > >>> instance\n"
> > >>> @@ -606,22 +598,6 @@ int main(int argc, char **argv)
> > >>>break;
> > >>>
> > >>>switch (c) {
> > >>> - case 'f':
> > >>> - if (guid) {
> > >>> - fprintf(stderr,
> > >>> - "Image type already specified\n");
> > >>> - exit(EXIT_FAILURE);
> > >>> - }
> > >>> - guid = _guid_image_type_uboot_fit;
> > >>> - break;
> > >>> - case 'r':
> > >>> - if (guid) {
> > >>> - fprintf(stderr,
> > >>> - "Image type already specified\n");
> > >>> - exit(EXIT_FAILURE);
> > >>> - }
> > >>> - guid = _guid_image_type_uboot_raw;
> > >>> - break;
> > >>>case 'g':
> > >>>if (guid) {
> > >>>fprintf(stderr,
> > >>
> > >> Can you please find a way how to export guid based on what you build?
> > >> I think the best would be when capsules are enable to generated them
> > >> directly as
> > >> the part of build process with proper guids.
> > >
> > > I don't know how that can be done in a generic way. A platform might
> > > have more than one updatable image. So for doing what you are
> > > suggesting, we will need to a) pass the board for which the capsule is
> > >
Re: [PATCH v4 00/33] Initial implementation of standard boot
On Fri, Mar 25, 2022 at 03:36:24PM +0100, Michael Nazzareno Trimarchi wrote: > Hi Tom > > > On Wed, Mar 23, 2022 at 9:07 PM Tom Rini wrote: > > > > On Wed, Mar 23, 2022 at 08:57:36PM +0100, Michael Nazzareno Trimarchi wrote: > > > Hi Tom > > > > > > On Wed, Mar 23, 2022 at 8:30 PM Tom Rini wrote: > > > > > > > > On Wed, Mar 23, 2022 at 08:21:22PM +0100, Michael Nazzareno Trimarchi > > > > wrote: > > > > > Hi Tom > > > > > > > > > > On Wed, Mar 23, 2022 at 7:46 PM Simon Glass wrote: > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > On Wed, 23 Mar 2022 at 08:05, Tom Rini wrote: > > > > > > > > > > > > > > On Sun, Mar 06, 2022 at 05:49:43AM -0700, Simon Glass wrote: > > > > > > > > > > > > > > > > The bootflow feature provide a built-in way for U-Boot to > > > > > > > > automatically > > > > > > > > boot an Operating System without custom scripting and other > > > > > > > > customisation. > > > > > > > > This is called 'standard boot' since it provides a standard way > > > > > > > > for > > > > > > > > U-Boot to boot a distro, without scripting. > > > > > > > > > > > > > > > > It introduces the following concepts: > > > > > > > > > > > > > > > >- bootdev - a device which can hold a distro > > > > > > > >- bootmeth - a method to scan a bootdev to find bootflows > > > > > > > > (owned by > > > > > > > > U-Boot) > > > > > > > >- bootflow - a description of how to boot (owned by the > > > > > > > > distro) > > > > > > > > > > > > > > > > This series provides an implementation of these, enabled to > > > > > > > > scan for > > > > > > > > bootflows from MMC, USB and Ethernet. It supports the existing > > > > > > > > distro > > > > > > > > boot as well as the EFI loader flow (bootefi/bootmgr). It works > > > > > > > > similiarly to the existing script-based approach, but is native > > > > > > > > to > > > > > > > > U-Boot. > > > > > > > > > > > > > > > > With this we can boot on a Raspberry Pi 3 with just one command: > > > > > > > > > > > > > > > >bootflow scan -lb > > > > > > > > > > > > > > > > which means to scan, listing (-l) each bootflow and trying to > > > > > > > > boot each > > > > > > > > one (-b). The final patch shows this. > > > > > > > > > > > > > > > > With a standard way to identify boot devices, booting become > > > > > > > > easier. It > > > > > > > > also should be possible to support U-Boot scripts, for backwards > > > > > > > > compatibility only. > > > > > > > > > > > > > > > > This series relies on the PXE clean-up series, posted here: > > > > > > > > > > > > > > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/list/?series=267078 > > > > > > > > > > > > > > > > For documentation, see the 'doc' patch. > > > > > > > > > > > > > > > > For version 2, a new naming scheme is used as above: > > > > > > > > > > > > > > > >- bootdev is used instead of bootdevice, because 'device' is > > > > > > > > overused, > > > > > > > >is everywhere in U-Boot, can be confused with udevice > > > > > > > >- bootmeth - because 'method' is too vanilla, appears 1300 > > > > > > > > times in > > > > > > > >U-Boot > > > > > > > > > > > > > > > > Also in version 2, drivers are introduced for the boot methods, > > > > > > > > to make > > > > > > > > it more extensible. Booting a custom OS is simply a matter of > > > > > > > > creating a > > > > > > > > bootmeth for it and implementing the read_file() and boot() > > > > > > > > methods. > > > > > > > > > > > > > > > > Version 4 makes some minor improvements and leaves out the RFC > > > > > > > > patch for > > > > > > > > rpi conversion, in the hope of getting the base support applied > > > > > > > > sooner > > > > > > > > rather than later. > > > > > > > > > > > > > > > > The design is described in these two documents: > > > > > > > > > > > > > > > > https://drive.google.com/file/d/1ggW0KJpUOR__vBkj3l61L2dav4ZkNC12/view?usp=sharing > > > > > > > > > > > > > > > > https://drive.google.com/file/d/1kTrflO9vvGlKp-ZH_jlgb9TY3WYG6FF9/view?usp=sharing > > > > > > > > > > > > > > I keep putting off commenting more here, but, I still feel this > > > > > > > is the > > > > > > > wrong direction. What problems do we have today with distro boot? > > > > > > > Well, we haven't figured out how to move configuring it out of > > > > > > > the board > > > > > > > config.h file. But that's just one of a half dozen or so > > > > > > > examples of > > > > > > > how we haven't figured out a good solution to configuring the > > > > > > > default > > > > > > > environment. And only some of those other examples are boot > > > > > > > related > > > > > > > (the NXP chain of trust booting stuff is another boot example, > > > > > > > ETHPRIME, > > > > > > > HOSTNAME, etc, are non-boot examples). > > > > > > > > > > > > > > We also aren't improving testing of "can we boot" here, because > > > > > > > what > > > > > > > THAT needs is setting up LAVA and booting some installers on some > >
Re: [PATCH v4 00/33] Initial implementation of standard boot
Hi Tom On Wed, Mar 23, 2022 at 9:07 PM Tom Rini wrote: > > On Wed, Mar 23, 2022 at 08:57:36PM +0100, Michael Nazzareno Trimarchi wrote: > > Hi Tom > > > > On Wed, Mar 23, 2022 at 8:30 PM Tom Rini wrote: > > > > > > On Wed, Mar 23, 2022 at 08:21:22PM +0100, Michael Nazzareno Trimarchi > > > wrote: > > > > Hi Tom > > > > > > > > On Wed, Mar 23, 2022 at 7:46 PM Simon Glass wrote: > > > > > > > > > > Hi Tom, > > > > > > > > > > On Wed, 23 Mar 2022 at 08:05, Tom Rini wrote: > > > > > > > > > > > > On Sun, Mar 06, 2022 at 05:49:43AM -0700, Simon Glass wrote: > > > > > > > > > > > > > > The bootflow feature provide a built-in way for U-Boot to > > > > > > > automatically > > > > > > > boot an Operating System without custom scripting and other > > > > > > > customisation. > > > > > > > This is called 'standard boot' since it provides a standard way > > > > > > > for > > > > > > > U-Boot to boot a distro, without scripting. > > > > > > > > > > > > > > It introduces the following concepts: > > > > > > > > > > > > > >- bootdev - a device which can hold a distro > > > > > > >- bootmeth - a method to scan a bootdev to find bootflows > > > > > > > (owned by > > > > > > > U-Boot) > > > > > > >- bootflow - a description of how to boot (owned by the distro) > > > > > > > > > > > > > > This series provides an implementation of these, enabled to scan > > > > > > > for > > > > > > > bootflows from MMC, USB and Ethernet. It supports the existing > > > > > > > distro > > > > > > > boot as well as the EFI loader flow (bootefi/bootmgr). It works > > > > > > > similiarly to the existing script-based approach, but is native to > > > > > > > U-Boot. > > > > > > > > > > > > > > With this we can boot on a Raspberry Pi 3 with just one command: > > > > > > > > > > > > > >bootflow scan -lb > > > > > > > > > > > > > > which means to scan, listing (-l) each bootflow and trying to > > > > > > > boot each > > > > > > > one (-b). The final patch shows this. > > > > > > > > > > > > > > With a standard way to identify boot devices, booting become > > > > > > > easier. It > > > > > > > also should be possible to support U-Boot scripts, for backwards > > > > > > > compatibility only. > > > > > > > > > > > > > > This series relies on the PXE clean-up series, posted here: > > > > > > > > > > > > > >https://patchwork.ozlabs.org/project/uboot/list/?series=267078 > > > > > > > > > > > > > > For documentation, see the 'doc' patch. > > > > > > > > > > > > > > For version 2, a new naming scheme is used as above: > > > > > > > > > > > > > >- bootdev is used instead of bootdevice, because 'device' is > > > > > > > overused, > > > > > > >is everywhere in U-Boot, can be confused with udevice > > > > > > >- bootmeth - because 'method' is too vanilla, appears 1300 > > > > > > > times in > > > > > > >U-Boot > > > > > > > > > > > > > > Also in version 2, drivers are introduced for the boot methods, > > > > > > > to make > > > > > > > it more extensible. Booting a custom OS is simply a matter of > > > > > > > creating a > > > > > > > bootmeth for it and implementing the read_file() and boot() > > > > > > > methods. > > > > > > > > > > > > > > Version 4 makes some minor improvements and leaves out the RFC > > > > > > > patch for > > > > > > > rpi conversion, in the hope of getting the base support applied > > > > > > > sooner > > > > > > > rather than later. > > > > > > > > > > > > > > The design is described in these two documents: > > > > > > > > > > > > > > https://drive.google.com/file/d/1ggW0KJpUOR__vBkj3l61L2dav4ZkNC12/view?usp=sharing > > > > > > > > > > > > > > https://drive.google.com/file/d/1kTrflO9vvGlKp-ZH_jlgb9TY3WYG6FF9/view?usp=sharing > > > > > > > > > > > > I keep putting off commenting more here, but, I still feel this is > > > > > > the > > > > > > wrong direction. What problems do we have today with distro boot? > > > > > > Well, we haven't figured out how to move configuring it out of the > > > > > > board > > > > > > config.h file. But that's just one of a half dozen or so examples > > > > > > of > > > > > > how we haven't figured out a good solution to configuring the > > > > > > default > > > > > > environment. And only some of those other examples are boot related > > > > > > (the NXP chain of trust booting stuff is another boot example, > > > > > > ETHPRIME, > > > > > > HOSTNAME, etc, are non-boot examples). > > > > > > > > > > > > We also aren't improving testing of "can we boot" here, because what > > > > > > THAT needs is setting up LAVA and booting some installers on some > > > > > > hardware (and some QEMU). That's testing that Linux boot works. > > > > > > Today > > > > > > we have tests for hush parsing, and if distro boot makes use of > > > > > > something we don't have a test for, we need a test for it. This > > > > > > adds > > > > > > tests for itself, which is good. > > > > > > > > > > > > And I still don't see an example of where
Re: [RFC PATCH 5/6] FMP: Remove GUIDs for FIT and raw images
On Thu, 24 Mar 2022 at 14:39, Sughosh Ganu wrote:
>
> The capsule update code has been modified for getting the image GUID
> values from the platform code. With this, each image now has a unique
> GUID value. With this change, there is no longer a need for defining
> GUIDs for FIT and raw images. Remove these GUID values.
>
> Signed-off-by: Sughosh Ganu
> ---
> include/efi_api.h | 8
> lib/efi_loader/efi_firmware.c | 4
> 2 files changed, 12 deletions(-)
>
> diff --git a/include/efi_api.h b/include/efi_api.h
> index 982c200172..c7f7873b5d 100644
> --- a/include/efi_api.h
> +++ b/include/efi_api.h
> @@ -1967,14 +1967,6 @@ struct efi_signature_list {
> EFI_GUID(0x86c77a67, 0x0b97, 0x4633, 0xa1, 0x87, \
> 0x49, 0x10, 0x4d, 0x06, 0x85, 0xc7)
>
> -#define EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID \
> - EFI_GUID(0xae13ff2d, 0x9ad4, 0x4e25, 0x9a, 0xc8, \
> -0x6d, 0x80, 0xb3, 0xb2, 0x21, 0x47)
> -
> -#define EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID \
> - EFI_GUID(0xe2bb9c06, 0x70e9, 0x4b14, 0x97, 0xa3, \
> -0x5a, 0x79, 0x13, 0x17, 0x6e, 0x3f)
> -
> #define IMAGE_ATTRIBUTE_IMAGE_UPDATABLE0x0001
> #define IMAGE_ATTRIBUTE_RESET_REQUIRED 0x0002
> #define IMAGE_ATTRIBUTE_AUTHENTICATION_REQUIRED0x0004
> diff --git a/lib/efi_loader/efi_firmware.c b/lib/efi_loader/efi_firmware.c
> index 13cb492092..9fbedaf023 100644
> --- a/lib/efi_loader/efi_firmware.c
> +++ b/lib/efi_loader/efi_firmware.c
> @@ -185,8 +185,6 @@ static efi_status_t efi_fill_image_desc_array(
> * - versioning of firmware image
> * - package information
> */
> -const efi_guid_t efi_firmware_image_type_uboot_fit =
> - EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID;
>
> /**
> * efi_firmware_fit_get_image_info - return information about the current
> @@ -293,8 +291,6 @@ const struct efi_firmware_management_protocol efi_fmp_fit
> = {
> * This FIRMWARE_MANAGEMENT_PROTOCOL driver provides a firmware update
> * method with raw data.
> */
> -const efi_guid_t efi_firmware_image_type_uboot_raw =
> - EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID;
>
> /**
> * efi_firmware_raw_get_image_info - return information about the current
> --
> 2.25.1
>
Reviewed-by: Ilias Apalodimas
Re: [PATCH 15/15] Convert CONFIG_BACKSIDE_L2_CACHE to Kconfig
On Fri, Mar 18, 2022 at 08:38:32AM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_BACKSIDE_L2_CACHE > > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 14/15] vinco: Remove CONFIG_ATMEL_SPI0
On Fri, Mar 18, 2022 at 08:38:31AM -0400, Tom Rini wrote: > This is not referenced anywhere, remove. > > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 13/15] lcd: Remove LCD_TEST_PATTERN code
On Fri, Mar 18, 2022 at 08:38:30AM -0400, Tom Rini wrote: > This is a legacy driver and the value is set in board config headers > without a CONFIG prefix. Remove the code. > > Cc: Anatolij Gustschin > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 12/15] Convert CONFIG_LCD_INFO et al to Kconfig
On Fri, Mar 18, 2022 at 08:38:29AM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_LCD_INFO >CONFIG_LCD_LOGO >CONFIG_LCD_INFO_BELOW_LOGO >CONFIG_LCD_IN_PSRAM > > Cc: Anatolij Gustschin > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 11/15] Convert CONFIG_ATMEL_LCD et al to Kconfig
On Fri, Mar 18, 2022 at 08:38:28AM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_ATMEL_LCD >CONFIG_ATMEL_LCD_BGR555 >CONFIG_ATMEL_LCD_RGB565 >CONFIG_GURNARD_SPLASH > > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 10/15] Convert CONFIG_MII_INIT to Kconfig
On Fri, Mar 18, 2022 at 08:38:27AM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_MII_INIT > > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 09/15] Convert CONFIG_PHY_RESET_DELAY to Kconfig
On Fri, Mar 18, 2022 at 08:38:26AM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_PHY_RESET_DELAY > > Cc: Ramon Fried > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 08/15] Convert CONFIG_SYS_RX_ETH_BUFFER to Kconfig
On Fri, Mar 18, 2022 at 08:38:25AM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_SYS_RX_ETH_BUFFER > > Cc: Ramon Fried > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 07/15] Convert CONFIG_LPC32XX_ETH to Kconfig
On Fri, Mar 18, 2022 at 08:38:24AM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_LPC32XX_ETH > > Cc: Ramon Fried > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 06/15] Convert CONFIG_TFTP_PORT to Kconfig
On Fri, Mar 18, 2022 at 08:38:23AM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_TFTP_PORT > > Cc: Ramon Fried > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 05/15] Convert CONFIG_RMII to Kconfig
On Fri, Mar 18, 2022 at 08:38:22AM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_RMII > > Cc: Ramon Fried > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 04/15] Convert CONFIG_SYS_FAULT_ECHO_LINK_DOWN to Kconfig
On Fri, Mar 18, 2022 at 08:38:21AM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_SYS_FAULT_ECHO_LINK_DOWN > > Cc: Ramon Fried > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 03/15] Convert CONFIG_RESET_PHY_R to Kconfig
On Fri, Mar 18, 2022 at 08:38:20AM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_RESET_PHY_R > > Cc: Ramon Fried > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 02/15] Convert CONFIG_AT91_WANTS_COMMON_PHY to Kconfig
On Fri, Mar 18, 2022 at 08:38:19AM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_AT91_WANTS_COMMON_PHY > > Cc: Eugen Hristev > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 01/15] Convert CONFIG_AT91_LED to Kconfig
On Fri, Mar 18, 2022 at 08:38:18AM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_AT91_LED > > Cc: Eugen Hristev > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: ubifs: fix journal replay wrt. xattr nodes
On Fri, Mar 11, 2022 at 12:21:01PM +, Ville Baillie wrote: > Hi all > > Has there been any thought about bringing this fix into the u-boot ubifs > layer? > > https://github.com/torvalds/linux/commit/1cb51a15b576ee325d527726afff40947218fd5e > > > This fixes something that can break boot if you rely on UBIFS to load your > kernel images. If someone would port and post it, it would come in, yes. -- Tom signature.asc Description: PGP signature
Re: [PATCH] CI: Pin pylint version to 2.12.2
On Fri, Mar 25, 2022 at 08:28:20AM -0400, Tom Rini wrote: > For consistency in runs, we need to always use the same pylint version. > Pin to 2.12.2 as this is what we have been using so far. > > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
[PATCH v4] mtd: gpmi: fix the bch setting backward compatible issue
Previous u-boot code changed the default bch setting behavior and caused
backward compatible issue. This fix choose the legacy bch geometry back
again as the default option. If the minimum ecc strength that NAND chips
required need to be chosen, it can be enabled by either adding DT flag
"fsl,use-minimum-ecc" or CONFIG_NAND_MXS_USE_MINIMUM_ECC in configs. The
unused flag "fsl,legacy-bch-geometry" get removed.
Fixes: 51cdf83eea (mtd: gpmi: provide the option to use legacy bch geometry)
Fixes: 616f03daba (mtd: gpmi: change the BCH layout setting for large oob NAND)
Tested-by: Tim Harvey
Tested-by: Sean Nyekjaer
Signed-off-by: Han Xu
---
Changes in v2:
- change the commit log about backward compatible issue is in u-boot
- removed the unused flag
- add fixes and test tag
Changes in v3:
- fix the fixes syntax
- fix the change log syntax
- add more test tag
Changes in v4:
- change the fix tag to single line
---
drivers/mtd/nand/raw/mxs_nand.c| 71 ++
drivers/mtd/nand/raw/mxs_nand_dt.c | 2 -
include/mxs_nand.h | 2 -
3 files changed, 62 insertions(+), 13 deletions(-)
diff --git a/drivers/mtd/nand/raw/mxs_nand.c b/drivers/mtd/nand/raw/mxs_nand.c
index 748056a43e..ee5d7fde9c 100644
--- a/drivers/mtd/nand/raw/mxs_nand.c
+++ b/drivers/mtd/nand/raw/mxs_nand.c
@@ -195,6 +195,7 @@ static inline int mxs_nand_legacy_calc_ecc_layout(struct
bch_geometry *geo,
struct nand_chip *chip = mtd_to_nand(mtd);
struct mxs_nand_info *nand_info = nand_get_controller_data(chip);
unsigned int block_mark_bit_offset;
+ int corr, ds_corr;
/* The default for the length of Galois Field. */
geo->gf_len = 13;
@@ -225,6 +226,17 @@ static inline int mxs_nand_legacy_calc_ecc_layout(struct
bch_geometry *geo,
geo->ecc_strength = min(round_down(geo->ecc_strength, 2),
nand_info->max_ecc_strength_supported);
+ /* check ecc strength, same as nand_ecc_is_strong_enough() did*/
+ if (chip->ecc_step_ds) {
+ corr = mtd->writesize * geo->ecc_strength /
+ geo->ecc_chunkn_size;
+ ds_corr = mtd->writesize * chip->ecc_strength_ds /
+ chip->ecc_step_ds;
+ if (corr < ds_corr ||
+ geo->ecc_strength < chip->ecc_strength_ds)
+ return -EINVAL;
+ }
+
block_mark_bit_offset = mtd->writesize * 8 -
(geo->ecc_strength * geo->gf_len * (geo->ecc_chunk_count - 1)
+ MXS_NAND_METADATA_SIZE * 8);
@@ -,6 +1123,7 @@ static int mxs_nand_set_geometry(struct mtd_info *mtd,
struct bch_geometry *geo)
struct nand_chip *chip = mtd_to_nand(mtd);
struct nand_chip *nand = mtd_to_nand(mtd);
struct mxs_nand_info *nand_info = nand_get_controller_data(nand);
+ int err;
if (chip->ecc_strength_ds > nand_info->max_ecc_strength_supported) {
printf("unsupported NAND chip, minimum ecc required %d\n"
@@ -1118,19 +1131,57 @@ static int mxs_nand_set_geometry(struct mtd_info *mtd,
struct bch_geometry *geo)
return -EINVAL;
}
- if ((!(chip->ecc_strength_ds > 0 && chip->ecc_step_ds > 0) &&
-mtd->oobsize < 1024) || nand_info->legacy_bch_geometry) {
- dev_warn(mtd->dev, "use legacy bch geometry\n");
- return mxs_nand_legacy_calc_ecc_layout(geo, mtd);
+ /* use the legacy bch setting by default */
+ if ((!nand_info->use_minimum_ecc && mtd->oobsize < 1024) ||
+ !(chip->ecc_strength_ds > 0 && chip->ecc_step_ds > 0)) {
+ dev_dbg(mtd->dev, "use legacy bch geometry\n");
+ err = mxs_nand_legacy_calc_ecc_layout(geo, mtd);
+ if (!err)
+ return 0;
}
- if (mtd->oobsize > 1024 || chip->ecc_step_ds < mtd->oobsize)
- return mxs_nand_calc_ecc_for_large_oob(geo, mtd);
+ /* for large oob nand */
+ if (mtd->oobsize > 1024) {
+ dev_dbg(mtd->dev, "use large oob bch geometry\n");
+ err = mxs_nand_calc_ecc_for_large_oob(geo, mtd);
+ if (!err)
+ return 0;
+ }
- return mxs_nand_calc_ecc_layout_by_info(geo, mtd,
- chip->ecc_strength_ds, chip->ecc_step_ds);
+ /* otherwise use the minimum ecc nand chips required */
+ dev_dbg(mtd->dev, "use minimum ecc bch geometry\n");
+ err = mxs_nand_calc_ecc_layout_by_info(geo, mtd, chip->ecc_strength_ds,
+ chip->ecc_step_ds);
- return 0;
+ if (err)
+ dev_err(mtd->dev, "none of the bch geometry setting works\n");
+
+ return err;
+}
+
+void mxs_nand_dump_geo(struct mtd_info *mtd)
+{
+ struct nand_chip *nand = mtd_to_nand(mtd);
+ struct mxs_nand_info *nand_info =
Re: [PATCH 1/1] doc: update doc/sphinx/requirements.txt
On Fri, Mar 25, 2022 at 01:40:54PM +0100, Heinrich Schuchardt wrote: > Pin all dependencies as reported by 'pip freeze'. > > Signed-off-by: Heinrich Schuchardt Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH 1/1] doc: update doc/sphinx/requirements.txt
Pin all dependencies as reported by 'pip freeze'. Signed-off-by: Heinrich Schuchardt --- doc/sphinx/requirements.txt | 25 +++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/doc/sphinx/requirements.txt b/doc/sphinx/requirements.txt index 44c187880d..5baec4d93e 100644 --- a/doc/sphinx/requirements.txt +++ b/doc/sphinx/requirements.txt @@ -1,4 +1,25 @@ +alabaster==0.7.12 +Babel==2.9.1 +certifi==2021.10.8 +charset-normalizer==2.0.12 docutils==0.16 -sphinx==3.4.3 -sphinx_rtd_theme==1.0.0 +idna==3.3 +imagesize==1.3.0 +Jinja2==3.0.3 +MarkupSafe==2.1.1 +packaging==21.3 +Pygments==2.11.2 +pyparsing==3.0.7 +pytz==2022.1 +requests==2.27.1 six==1.16.0 +snowballstemmer==2.2.0 +Sphinx==3.4.3 +sphinx-rtd-theme==1.0.0 +sphinxcontrib-applehelp==1.0.2 +sphinxcontrib-devhelp==1.0.2 +sphinxcontrib-htmlhelp==2.0.0 +sphinxcontrib-jsmath==1.0.1 +sphinxcontrib-qthelp==1.0.3 +sphinxcontrib-serializinghtml==1.1.5 +urllib3==1.26.9 -- 2.34.1
[PATCH] CI: Pin pylint version to 2.12.2
For consistency in runs, we need to always use the same pylint version.
Pin to 2.12.2 as this is what we have been using so far.
Signed-off-by: Tom Rini
---
.azure-pipelines.yml | 2 +-
.gitlab-ci.yml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index 0f1a1bd86326..cd5461d7 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -214,7 +214,7 @@ stages:
cd ${WORK_DIR}
export USER=azure
pip install -r test/py/requirements.txt
- pip install asteval pylint pyopenssl
+ pip install asteval pylint==2.12.2 pyopenssl
export PATH=${PATH}:~/.local/bin
echo "[MASTER]" >> .pylintrc
echo "load-plugins=pylint.extensions.docparams" >> .pylintrc
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 388e666ec9e3..7df7e939f542 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -220,7 +220,7 @@ Run pylint:
stage: testsuites
script:
- pip install -r test/py/requirements.txt
-- pip install asteval pylint pyopenssl
+- pip install asteval pylint==2.12.2 pyopenssl
- export PATH=${PATH}:~/.local/bin
- echo "[MASTER]" >> .pylintrc
- echo "load-plugins=pylint.extensions.docparams" >> .pylintrc
--
2.25.1
[PATCH] mmc: zynq_sdhci: Fix SDx_BASECLK configuration
From: Ashok Reddy Soma
The DLL mode supported SD reference clocks are 50 MHz, 100 MHz and
200 MHz. When user select SD frequency as 200MHz in the design, the
actual frequency is going to come around ~187MHz (<= 200MHz considering
the parent clock and divisor selection). We need to set SDx_BASECLK as
200 in this case, setting 187 will result in tuning failures in mmc.
Set SDx_BASECLK to exact value of 200, 100 or 50 based on the frequency
range.
Signed-off-by: Ashok Reddy Soma
Signed-off-by: Michal Simek
---
drivers/mmc/zynq_sdhci.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
index d96f5d543f54..a59d96c6bdad 100644
--- a/drivers/mmc/zynq_sdhci.c
+++ b/drivers/mmc/zynq_sdhci.c
@@ -765,6 +765,15 @@ static int sdhci_zynqmp_set_dynamic_config(struct
arasan_sdhci_priv *priv,
mhz = DIV64_U64_ROUND_UP(clock, 100);
+ if (mhz > 100 && mhz <= 200)
+ mhz = 200;
+ else if (mhz > 50 && mhz <= 100)
+ mhz = 100;
+ else if (mhz > 25 && mhz <= 50)
+ mhz = 50;
+ else
+ mhz = 25;
+
ret = zynqmp_pm_set_sd_config(node_id, SD_CONFIG_BASECLK, mhz);
if (ret) {
dev_err(dev, "SD_CONFIG_BASECLK failed\n");
--
2.35.1
[PATCH v4 8/9] arm: dts: imx8mm_evk: add pwm1/backlight support
Add pwm1/backlight support nodes for imx8mm_evk board
Signed-off-by: Tommaso Merciai
---
arch/arm/dts/imx8mm-evk.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/dts/imx8mm-evk.dtsi b/arch/arm/dts/imx8mm-evk.dtsi
index 60179e006d..e7a2bd8a64 100644
--- a/arch/arm/dts/imx8mm-evk.dtsi
+++ b/arch/arm/dts/imx8mm-evk.dtsi
@@ -41,6 +41,15 @@
enable-active-high;
};
+ backlight: backlight {
+ status = "disabled";
+ compatible = "pwm-backlight";
+ pwms = < 0 500>;
+ brightness-levels = <0 255>;
+ num-interpolated-steps = <255>;
+ default-brightness-level = <250>;
+ };
+
ir-receiver {
compatible = "gpio-ir-receiver";
gpios = < 13 GPIO_ACTIVE_LOW>;
@@ -350,6 +359,12 @@
status = "okay";
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_backlight>;
+ status = "disabled";
+};
+
{
pinctrl_fec1: fec1grp {
fsl,pins = <
@@ -491,4 +506,10 @@
MX8MM_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B0x166
>;
};
+
+ pinctrl_backlight: backlightgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_GPIO1_IO01_PWM1_OUT0x06
+ >;
+ };
};
--
2.25.1
[PATCH v4 9/9] configs: imx8mm_evk: add pwm backlight support
Enable support for backlight/pwm-imx driver Signed-off-by: Tommaso Merciai --- configs/imx8mm_evk_defconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/configs/imx8mm_evk_defconfig b/configs/imx8mm_evk_defconfig index 01395fc7eb..cfba6cc673 100644 --- a/configs/imx8mm_evk_defconfig +++ b/configs/imx8mm_evk_defconfig @@ -84,3 +84,8 @@ CONFIG_SYSRESET_PSCI=y CONFIG_SYSRESET_WATCHDOG=y CONFIG_DM_THERMAL=y CONFIG_IMX_WATCHDOG=y +CONFIG_DM_VIDEO=y +CONFIG_BACKLIGHT=y +CONFIG_BACKLIGHT_PWM=y +CONFIG_DM_PWM=y +CONFIG_PWM_IMX=y \ No newline at end of file -- 2.25.1
[PATCH v4 7/9] driver: pwm: pwm-imx: separe dm from non dm implementation
Separe dm implementation from non dm implementation of pwm-imx
driver using CONFIG_DM_PWM
Signed-off-by: Tommaso Merciai
---
drivers/pwm/pwm-imx.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
index 1d656e726f..9b8a8c189d 100644
--- a/drivers/pwm/pwm-imx.c
+++ b/drivers/pwm/pwm-imx.c
@@ -13,17 +13,6 @@
#include
#include
#include
-
-int pwm_init(int pwm_id, int div, int invert)
-{
- struct pwm_regs *pwm = (struct pwm_regs *)pwm_id_to_reg(pwm_id);
-
- if (!pwm)
- return -1;
-
- writel(0, >ir);
- return 0;
-}
#include
int pwm_config_internal(struct pwm_regs *pwm, unsigned long period_cycles,
@@ -44,6 +33,7 @@ int pwm_config_internal(struct pwm_regs *pwm, unsigned long
period_cycles,
return 0;
}
+#ifndef CONFIG_DM_PWM
/* pwm_id from 0..7 */
struct pwm_regs *pwm_id_to_reg(int pwm_id)
{
@@ -110,6 +100,17 @@ int pwm_imx_get_parms(int period_ns, int duty_ns, unsigned
long *period_c,
return 0;
}
+int pwm_init(int pwm_id, int div, int invert)
+{
+ struct pwm_regs *pwm = (struct pwm_regs *)pwm_id_to_reg(pwm_id);
+
+ if (!pwm)
+ return -1;
+
+ writel(0, >ir);
+ return 0;
+}
+
int pwm_config(int pwm_id, int duty_ns, int period_ns)
{
struct pwm_regs *pwm = (struct pwm_regs *)pwm_id_to_reg(pwm_id);
@@ -145,7 +146,7 @@ void pwm_disable(int pwm_id)
clrbits_le32(>cr, PWMCR_EN);
}
-#if defined(CONFIG_DM_PWM)
+#else
struct imx_pwm_priv {
struct pwm_regs *regs;
bool invert;
--
2.25.1
[PATCH v4 5/9] driver: pwm: pwm-imx: get and enable per/ipg clock using dm
Get and enable ipg/per pwms clocks using dm api into imx_pwm_of_to_plat
and imx_pwm_probe driver function
Signed-off-by: Tommaso Merciai
---
Changes since v4:
- Fix ipg/per clk declaration
- Fix clk_get_by_name call
- Fix clk_enable call
drivers/pwm/pwm-imx.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
index 67dad21295..74b0817a05 100644
--- a/drivers/pwm/pwm-imx.c
+++ b/drivers/pwm/pwm-imx.c
@@ -24,6 +24,7 @@ int pwm_init(int pwm_id, int div, int invert)
writel(0, >ir);
return 0;
}
+#include
int pwm_config_internal(struct pwm_regs *pwm, unsigned long period_cycles,
unsigned long duty_cycles, unsigned long prescale)
@@ -148,6 +149,8 @@ void pwm_disable(int pwm_id)
struct imx_pwm_priv {
struct pwm_regs *regs;
bool invert;
+ struct clk per_clk;
+ struct clk ipg_clk;
};
static int imx_pwm_set_invert(struct udevice *dev, uint channel,
@@ -193,15 +196,43 @@ static int imx_pwm_set_enable(struct udevice *dev, uint
channel, bool enable)
static int imx_pwm_of_to_plat(struct udevice *dev)
{
+ int ret;
struct imx_pwm_priv *priv = dev_get_priv(dev);
priv->regs = dev_read_addr_ptr(dev);
+ ret = clk_get_by_name(dev, "per", >per_clk);
+ if (ret) {
+ printf("Failed to get per_clk\n");
+ return ret;
+ }
+
+ ret = clk_get_by_name(dev, "ipg", >ipg_clk);
+ if (ret) {
+ printf("Failed to get ipg_clk\n");
+ return ret;
+ }
+
return 0;
}
static int imx_pwm_probe(struct udevice *dev)
{
+ int ret;
+ struct imx_pwm_priv *priv = dev_get_priv(dev);
+
+ ret = clk_enable(>per_clk);
+ if (ret) {
+ printf("Failed to enable per_clk\n");
+ return ret;
+ }
+
+ ret = clk_enable(>ipg_clk);
+ if (ret) {
+ printf("Failed to enable ipg_clk\n");
+ return ret;
+ }
+
return 0;
}
--
2.25.1
[PATCH v4 4/9] drivers: pwm: pwm-imx: move pwm-imx-util into pwm-imx
Move pwm_imx_get_parms, pwm_id_to_reg functions into pwm-imx.c
and drop off pwm-imx-util.c
Signed-off-by: Tommaso Merciai
---
drivers/pwm/Makefile | 2 +-
drivers/pwm/pwm-imx-util.c | 80 --
drivers/pwm/pwm-imx-util.h | 15 ---
drivers/pwm/pwm-imx.c | 67 ++-
4 files changed, 67 insertions(+), 97 deletions(-)
delete mode 100644 drivers/pwm/pwm-imx-util.c
delete mode 100644 drivers/pwm/pwm-imx-util.h
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 55f2bc081d..5d696ec49c 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -13,7 +13,7 @@ obj-$(CONFIG_DM_PWM) += pwm-uclass.o
obj-$(CONFIG_PWM_AT91) += pwm-at91.o
obj-$(CONFIG_PWM_CROS_EC) += cros_ec_pwm.o
obj-$(CONFIG_PWM_EXYNOS) += exynos_pwm.o
-obj-$(CONFIG_PWM_IMX) += pwm-imx.o pwm-imx-util.o
+obj-$(CONFIG_PWM_IMX) += pwm-imx.o
obj-$(CONFIG_PWM_MESON)+= pwm-meson.o
obj-$(CONFIG_PWM_MTK) += pwm-mtk.o
obj-$(CONFIG_PWM_ROCKCHIP) += rk_pwm.o
diff --git a/drivers/pwm/pwm-imx-util.c b/drivers/pwm/pwm-imx-util.c
deleted file mode 100644
index 823a9d2d6b..00
--- a/drivers/pwm/pwm-imx-util.c
+++ /dev/null
@@ -1,80 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * (C) Copyright 2014
- * Heiko Schocher, DENX Software Engineering, h...@denx.de.
- *
- * Basic support for the pwm module on imx6.
- *
- * Based on linux:drivers/pwm/pwm-imx.c
- * from
- * Sascha Hauer
- */
-
-#include
-#include
-#include
-
-/* pwm_id from 0..7 */
-struct pwm_regs *pwm_id_to_reg(int pwm_id)
-{
- switch (pwm_id) {
- case 0:
- return (struct pwm_regs *)PWM1_BASE_ADDR;
- case 1:
- return (struct pwm_regs *)PWM2_BASE_ADDR;
-#ifdef CONFIG_MX6
- case 2:
- return (struct pwm_regs *)PWM3_BASE_ADDR;
- case 3:
- return (struct pwm_regs *)PWM4_BASE_ADDR;
-#endif
-#ifdef CONFIG_MX6SX
- case 4:
- return (struct pwm_regs *)PWM5_BASE_ADDR;
- case 5:
- return (struct pwm_regs *)PWM6_BASE_ADDR;
- case 6:
- return (struct pwm_regs *)PWM7_BASE_ADDR;
- case 7:
- return (struct pwm_regs *)PWM8_BASE_ADDR;
-#endif
- default:
- printf("unknown pwm_id: %d\n", pwm_id);
- break;
- }
- return NULL;
-}
-
-int pwm_imx_get_parms(int period_ns, int duty_ns, unsigned long *period_c,
- unsigned long *duty_c, unsigned long *prescale)
-{
- unsigned long long c;
-
- /*
-* we have not yet a clock framework for imx6, so add the clock
-* value here as a define. Replace it when we have the clock
-* framework.
-*/
- c = CONFIG_IMX6_PWM_PER_CLK;
- c = c * period_ns;
- do_div(c, 10);
- *period_c = c;
-
- *prescale = *period_c / 0x1 + 1;
-
- *period_c /= *prescale;
- c = *period_c * (unsigned long long)duty_ns;
- do_div(c, period_ns);
- *duty_c = c;
-
- /*
-* according to imx pwm RM, the real period value should be
-* PERIOD value in PWMPR plus 2.
-*/
- if (*period_c > 2)
- *period_c -= 2;
- else
- *period_c = 0;
-
- return 0;
-}
diff --git a/drivers/pwm/pwm-imx-util.h b/drivers/pwm/pwm-imx-util.h
deleted file mode 100644
index 82c61d774d..00
--- a/drivers/pwm/pwm-imx-util.h
+++ /dev/null
@@ -1,15 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * (C) Copyright 2014
- * Heiko Schocher, DENX Software Engineering, h...@denx.de.
- *
- * Basic support for the pwm module on imx6.
- */
-
-#ifndef _pwm_imx_util_h_
-#define _pwm_imx_util_h_
-
-struct pwm_regs *pwm_id_to_reg(int pwm_id);
-int pwm_imx_get_parms(int period_ns, int duty_ns, unsigned long *period_c,
- unsigned long *duty_c, unsigned long *prescale);
-#endif
diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
index 2008c1520e..67dad21295 100644
--- a/drivers/pwm/pwm-imx.c
+++ b/drivers/pwm/pwm-imx.c
@@ -13,7 +13,6 @@
#include
#include
#include
-#include "pwm-imx-util.h"
int pwm_init(int pwm_id, int div, int invert)
{
@@ -44,6 +43,72 @@ int pwm_config_internal(struct pwm_regs *pwm, unsigned long
period_cycles,
return 0;
}
+/* pwm_id from 0..7 */
+struct pwm_regs *pwm_id_to_reg(int pwm_id)
+{
+
+ switch (pwm_id) {
+ case 0:
+ return (struct pwm_regs *)PWM1_BASE_ADDR;
+ case 1:
+ return (struct pwm_regs *)PWM2_BASE_ADDR;
+#ifdef CONFIG_MX6
+ case 2:
+ return (struct pwm_regs *)PWM3_BASE_ADDR;
+ case 3:
+ return (struct pwm_regs *)PWM4_BASE_ADDR;
+#endif
+#ifdef CONFIG_MX6SX
+ case 4:
+ return (struct pwm_regs *)PWM5_BASE_ADDR;
+ case 5:
+ return (struct pwm_regs *)PWM6_BASE_ADDR;
+
[PATCH v4 6/9] driver: pwm: pwm-imx: introduce pwm_dm_imx_get_parms
Introduce pwm_dm_imx_get_parms, dm version of pwm_imx_get_parms.
This function get clock rate using clk dm api
Signed-off-by: Tommaso Merciai
---
Changes since v4:
- Fix clk_get_rate call
drivers/pwm/pwm-imx.c | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
index 74b0817a05..1d656e726f 100644
--- a/drivers/pwm/pwm-imx.c
+++ b/drivers/pwm/pwm-imx.c
@@ -153,6 +153,36 @@ struct imx_pwm_priv {
struct clk ipg_clk;
};
+int pwm_dm_imx_get_parms(struct imx_pwm_priv *priv, int period_ns,
+ int duty_ns, unsigned long *period_c, unsigned long
*duty_c,
+ unsigned long *prescale)
+{
+ unsigned long long c;
+
+ c = clk_get_rate(>per_clk);
+ c = c * period_ns;
+ do_div(c, 10);
+ *period_c = c;
+
+ *prescale = *period_c / 0x1 + 1;
+
+ *period_c /= *prescale;
+ c = *period_c * (unsigned long long)duty_ns;
+ do_div(c, period_ns);
+ *duty_c = c;
+
+ /*
+* according to imx pwm RM, the real period value should be
+* PERIOD value in PWMPR plus 2.
+*/
+ if (*period_c > 2)
+ *period_c -= 2;
+ else
+ *period_c = 0;
+
+ return 0;
+}
+
static int imx_pwm_set_invert(struct udevice *dev, uint channel,
bool polarity)
{
@@ -173,7 +203,7 @@ static int imx_pwm_set_config(struct udevice *dev, uint
channel,
debug("%s: Config '%s' channel: %d\n", __func__, dev->name, channel);
- pwm_imx_get_parms(period_ns, duty_ns, _cycles, _cycles,
+ pwm_dm_imx_get_parms(priv, period_ns, duty_ns, _cycles,
_cycles,
);
return pwm_config_internal(regs, period_cycles, duty_cycles, prescale);
--
2.25.1
[PATCH v4 3/9] clk: imx8mm: add pwm clocks support
Add clocks support for the PWM controllers. This is ported from
Linux v5.17-rc8.
Signed-off-by: Tommaso Merciai
---
drivers/clk/imx/clk-imx8mm.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index 3aa8c641f9..964a778934 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -116,6 +116,18 @@ static const char *imx8mm_i2c3_sels[] = {"clock-osc-24m",
"sys_pll1_160m", "sys_
static const char *imx8mm_i2c4_sels[] = {"clock-osc-24m", "sys_pll1_160m",
"sys_pll2_50m", "sys_pll3_out", "audio_pll1_out",
"video_pll1_out", "audio_pll2_out",
"sys_pll1_133m", };
+static const char *imx8mm_pwm1_sels[] = {"clock-osc-24m", "sys_pll2_100m",
"sys_pll1_160m", "sys_pll1_40m",
+"sys_pll3_out", "clk_ext1",
"sys_pll1_80m", "video_pll1_out", };
+
+static const char *imx8mm_pwm2_sels[] = {"clock-osc-24m", "sys_pll2_100m",
"sys_pll1_160m", "sys_pll1_40m",
+"sys_pll3_out", "clk_ext1",
"sys_pll1_80m", "video_pll1_out", };
+
+static const char *imx8mm_pwm3_sels[] = {"clock-osc-24m", "sys_pll2_100m",
"sys_pll1_160m", "sys_pll1_40m",
+"sys_pll3_out", "clk_ext2",
"sys_pll1_80m", "video_pll1_out", };
+
+static const char *imx8mm_pwm4_sels[] = {"clock-osc-24m", "sys_pll2_100m",
"sys_pll1_160m", "sys_pll1_40m",
+"sys_pll3_out", "clk_ext2",
"sys_pll1_80m", "video_pll1_out", };
+
static const char *imx8mm_wdog_sels[] = {"clock-osc-24m", "sys_pll1_133m",
"sys_pll1_160m", "vpu_pll_out",
"sys_pll2_125m", "sys_pll3_out",
"sys_pll1_80m", "sys_pll2_166m", };
@@ -391,6 +403,14 @@ static int imx8mm_clk_probe(struct udevice *dev)
imx8m_clk_composite("i2c3", imx8mm_i2c3_sels, base + 0xae00));
clk_dm(IMX8MM_CLK_I2C4,
imx8m_clk_composite("i2c4", imx8mm_i2c4_sels, base + 0xae80));
+ clk_dm(IMX8MM_CLK_PWM1,
+ imx8m_clk_composite("pwm1", imx8mm_pwm1_sels, base + 0xb380));
+ clk_dm(IMX8MM_CLK_PWM2,
+ imx8m_clk_composite("pwm2", imx8mm_pwm2_sels, base + 0xb400));
+ clk_dm(IMX8MM_CLK_PWM3,
+ imx8m_clk_composite("pwm3", imx8mm_pwm3_sels, base + 0xb480));
+ clk_dm(IMX8MM_CLK_PWM4,
+ imx8m_clk_composite("pwm4", imx8mm_pwm4_sels, base + 0xb500));
clk_dm(IMX8MM_CLK_WDOG,
imx8m_clk_composite("wdog", imx8mm_wdog_sels, base + 0xb900));
clk_dm(IMX8MM_CLK_USDHC3,
@@ -425,6 +445,14 @@ static int imx8mm_clk_probe(struct udevice *dev)
imx_clk_gate4("i2c4_root_clk", "i2c4", base + 0x41a0, 0));
clk_dm(IMX8MM_CLK_OCOTP_ROOT,
imx_clk_gate4("ocotp_root_clk", "ipg_root", base + 0x4220, 0));
+ clk_dm(IMX8MM_CLK_PWM1_ROOT,
+ imx_clk_gate4("pwm1_root_clk", "pwm1", base + 0x4280, 0));
+ clk_dm(IMX8MM_CLK_PWM2_ROOT,
+ imx_clk_gate4("pwm2_root_clk", "pwm2", base + 0x4290, 0));
+ clk_dm(IMX8MM_CLK_PWM3_ROOT,
+ imx_clk_gate4("pwm3_root_clk", "pwm3", base + 0x42a0, 0));
+ clk_dm(IMX8MM_CLK_PWM4_ROOT,
+ imx_clk_gate4("pwm4_root_clk", "pwm4", base + 0x42b0, 0));
clk_dm(IMX8MM_CLK_USDHC1_ROOT,
imx_clk_gate4("usdhc1_root_clk", "usdhc1", base + 0x4510, 0));
clk_dm(IMX8MM_CLK_USDHC2_ROOT,
--
2.25.1
[PATCH v4 2/9] arch: mach-imx: imx8m: add pwm_regs struct in imx-regs
Add pwm_regs struct for i.MX8MM SOC
Signed-off-by: Tommaso Merciai
---
arch/arm/include/asm/arch-imx8m/imx-regs.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/include/asm/arch-imx8m/imx-regs.h
b/arch/arm/include/asm/arch-imx8m/imx-regs.h
index 57a95de1b8..f31f54ad0c 100644
--- a/arch/arm/include/asm/arch-imx8m/imx-regs.h
+++ b/arch/arm/include/asm/arch-imx8m/imx-regs.h
@@ -359,6 +359,15 @@ struct src {
#define PWMCR_CLKSRC_IPG (1 << 16)
#define PWMCR_EN (1 << 0)
+struct pwm_regs {
+ u32 cr;
+ u32 sr;
+ u32 ir;
+ u32 sar;
+ u32 pr;
+ u32 cnr;
+};
+
#define WDOG_WDT_MASK BIT(3)
#define WDOG_WDZST_MASKBIT(0)
struct wdog_regs {
--
2.25.1
[PATCH v4 1/9] arch: mach-imx: imx8m: add pwm ctrl registers fields defines
Add pwm control registers fields defines into imx-regs.h:
- prescaler
- dozeen
- waiten
- dbgen
- clksrc_ipg_high
- clksrc_ipg, en field
References:
- iMX8MMRM.pdf p 3884
Signed-off-by: Tommaso Merciai
---
arch/arm/include/asm/arch-imx8m/imx-regs.h | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/include/asm/arch-imx8m/imx-regs.h
b/arch/arm/include/asm/arch-imx8m/imx-regs.h
index 11389a0f4d..57a95de1b8 100644
--- a/arch/arm/include/asm/arch-imx8m/imx-regs.h
+++ b/arch/arm/include/asm/arch-imx8m/imx-regs.h
@@ -351,6 +351,14 @@ struct src {
u32 ddr2_rcr;
};
+#define PWMCR_PRESCALER(x) (((x - 1) & 0xFFF) << 4)
+#define PWMCR_DOZEEN (1 << 24)
+#define PWMCR_WAITEN (1 << 23)
+#define PWMCR_DBGEN(1 << 22)
+#define PWMCR_CLKSRC_IPG_HIGH (2 << 16)
+#define PWMCR_CLKSRC_IPG (1 << 16)
+#define PWMCR_EN (1 << 0)
+
#define WDOG_WDT_MASK BIT(3)
#define WDOG_WDZST_MASKBIT(0)
struct wdog_regs {
--
2.25.1
[PATCH v4 0/9] imx8mm: add pwm-imx backlight support
Hi, This series add support for pwm/backlight on i.MX8MM evk, separe also CONFIG_DM_PWM pwm-imx implementation from non dm implementation moving pwm-imx-util into pwm-imx with driver refactoring. 1. add pwm ctrl registers fields for i.MX8MM SOC 2. add pwm_regs struct for i.MX8MM SOC 3. add pwm clocks support for i.MX8MM SOC 4. move pwm-imx-util into pwm-imx 5. get and enable per/ipg clock using dm 6. introduce pwm_dm_imx_get_parms 7. separe dm from non dm implementation into pwm-imx driver 8. add pwm1/backlight dts support for imx8mm_evk 9. add pwm backlight configs support for imx8mm_evk Tommaso Merciai (9): arch: mach-imx: imx8m: add pwm ctrl registers fields defines arch: mach-imx: imx8m: add pwm_regs struct in imx-regs clk: imx8mm: add pwm clocks support drivers: pwm: pwm-imx: move pwm-imx-util into pwm-imx driver: pwm: pwm-imx: get and enable per/ipg clock using dm driver: pwm: pwm-imx: introduce pwm_dm_imx_get_parms driver: pwm: pwm-imx: separe dm from non dm implementation arm: dts: imx8mm_evk: add pwm1/backlight support configs: imx8mm_evk: add pwm backlight support arch/arm/dts/imx8mm-evk.dtsi | 21 +++ arch/arm/include/asm/arch-imx8m/imx-regs.h | 17 +++ configs/imx8mm_evk_defconfig | 5 + drivers/clk/imx/clk-imx8mm.c | 28 drivers/pwm/Makefile | 2 +- drivers/pwm/pwm-imx-util.c | 80 --- drivers/pwm/pwm-imx-util.h | 15 -- drivers/pwm/pwm-imx.c | 155 +++-- 8 files changed, 213 insertions(+), 110 deletions(-) delete mode 100644 drivers/pwm/pwm-imx-util.c delete mode 100644 drivers/pwm/pwm-imx-util.h -- 2.25.1
[PATCH] serial: zynq: Change fifor behavior in debug mode
Serial IP has output buffer which status is indicated by two bits. If fifo
if empty or full. Default configuration is that chars are pushed to fifo
till it is full. Time to time it is visible that chars are scambled and
logs are not visible. Not sure what it is exactly happening but all the
time it helps to change driver behavior to write only one char at a time.
That's why enable this mode when debug uart is enabled not to see scrambled
chars in debug by default.
Signed-off-by: Michal Simek
---
drivers/serial/serial_zynq.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/serial/serial_zynq.c b/drivers/serial/serial_zynq.c
index fd999368ab70..6bb003dc1558 100644
--- a/drivers/serial/serial_zynq.c
+++ b/drivers/serial/serial_zynq.c
@@ -21,6 +21,7 @@
#define ZYNQ_UART_SR_TXACTIVE BIT(11) /* TX active */
#define ZYNQ_UART_SR_TXFULLBIT(4) /* TX FIFO full */
+#define ZYNQ_UART_SR_TXEMPTY BIT(3) /* TX FIFO empty */
#define ZYNQ_UART_SR_RXEMPTY BIT(1) /* RX FIFO empty */
#define ZYNQ_UART_CR_TX_EN BIT(4) /* TX enabled */
@@ -107,8 +108,13 @@ static void _uart_zynq_serial_init(struct uart_zynq *regs)
static int _uart_zynq_serial_putc(struct uart_zynq *regs, const char c)
{
- if (readl(>channel_sts) & ZYNQ_UART_SR_TXFULL)
- return -EAGAIN;
+ if (CONFIG_IS_ENABLED(DEBUG_UART_ZYNQ)) {
+ if (!(readl(>channel_sts) & ZYNQ_UART_SR_TXEMPTY))
+ return -EAGAIN;
+ } else {
+ if (readl(>channel_sts) & ZYNQ_UART_SR_TXFULL)
+ return -EAGAIN;
+ }
writel(c, >tx_rx_fifo);
--
2.35.1
Re: [RFC PATCH 0/6] efi: capsule: Image GUID usage cleanup
Sughosh, On Fri, Mar 25, 2022 at 03:14:20PM +0530, Sughosh Ganu wrote: > hi Takahiro, > > On Fri, 25 Mar 2022 at 10:23, AKASHI Takahiro > wrote: > > > > Sughosh, > > > > On Thu, Mar 24, 2022 at 06:08:55PM +0530, Sughosh Ganu wrote: > > > > > > This series is cleaning up the usage of the image GUIDs that are used > > > in capsule update and the EFI System Resource Table(ESRT). > > > > > > Currently, there are two instances of the Firmware Management > > > Protocol(FMP), one defined for updating the FIT images, and the other > > > for updating raw images. The FMP code defines two GUID values, one for > > > all FIT images, and one for raw images. Depending on the FMP instance > > > used on a platform, the platform needs to use the corresponding image > > > GUID value for all images on the platform, and also across platforms. > > > > > > A few issues are being fixed through the patch series. One, that an > > > image for a different platform can be flashed on another platform if > > > both the platforms are using the same FMP instance. So, for e.g. a > > > capsule generated for the Socionext DeveloperBox platform can be > > > flashed on the ZynqMP platform, since both the platforms use the > > > CONFIG_EFI_CAPSULE_FIRMWARE_RAW instance of the FMP. This can be > > > corrected if each firmware image that can be updated through the > > > capsule update mechanism has it's own unique image GUID. > > > > Ok although the specification doesn't explicitly require the uniqueness > > "across platforms". > > Yes, but unless we have a single image running on multiple platforms, > we do need different GUID values across platforms. > > > > > > The second issue that this patch series fixes is the value of FwClass > > > in the ESRT. With the current logic, all firmware image entries in the > > > ESRT display the same GUID value -- either the FIT GUID or the raw > > > GUID. This is not in compliance with the UEFI specification, as the > > > specification requires all entries to have unique GUID values. > > > > Well, this is *not* a problem of fit FMP driver, but a matter of how > > ESRT is populated. Table 23-16 "ESRT and FMP Fields" says, > > The ImageTypeId GUID from the Firmware > > Management Protocol instance for a device is > > used as the Firmware Class GUID in the ESRT. > > Where there are multiple identical devices in > > the system, system firmware must create a > > mapping to ensure that the ESRT FwClass > > GUIDs are unique and consistent. > > The second sentence suggests that UEFI implementation, i.e. > > efi_esrt_populate(), may and should allow some *mapping*. > > > > That said, I basically accept the requirement that you mention above. > > > > > The third issue being fixed is the population of the > > > EFI_FIRMWARE_IMAGE_DESCRIPTOR array. The current code uses the dfu > > > framework for populating the image descriptor array. However, there > > > might be other images that are not to be updated through the capsule > > > update mechanism also registered with the dfu framework. As a result > > > of this, the ESRT will show up entries of images that are not to be > > > targeted by the capsule update mechanism. > > > > > > These issues are being fixed by defining a structure, efi_fw_images. A > > > platform can then define image related information like the image GUID > > > and image name. Every platform that uses capsule update mechanism > > > needs to define fw_images array. This array will then be used to > > > populate the image descriptor array, and also in determining if a > > > particular capsule's payload can be used for updating an image on the > > > platform. > > > > When ESRT support patch was posted, I proposed that we should have > > a kind of configuration table that defines all the firmware on the system > > for ESRT, but this proposal was rejected. > > Your efi_fw_images[] looks quite similar as what I had in mind. > > Why not define efi_fw_images[] as ESRT itself. > > (Of course, some fields in an entry can still be populated through > > GetImageInfo API.) > > Currently, with this patch series, that is what is happening. The > efi_fw_images array gets read by the GetImageInfo function, and that > information gets used for populating the ESRT. Btw, I also want to > extend this structure as part of a separate task, where we have > information related to the dfu framework as part of the structure. > Then the capsule related dfu information can be populated from this > structure, instead of the dfu_alt_info env variable. This is what > Ilias has suggested. But I will take this up as a separate exercise. > > > > > > The first patch of this series adds the fw_images array in all > > > platforms which are using UEFI capsule updates > > > > > > The second patch of the series changes the logic for populating the > > > image descriptor array, using the information from the fw_images array > > > defined by the platform. > > > > So a FIT image can
Re: [PATCH 09/11] pci: Add function to validate PCI address range
On Fri, 25 Mar 2022 at 07:14, Bin Meng wrote: > > On Sun, Mar 20, 2022 at 7:42 PM Andrew Scull wrote: > > > > Add a function to convert a PCI address range to a physical address > > range. The address range is validated to ensure it is contained within > > one of the PCI address regions and that the whole range can be indexed > > from the resulting physical address. > > I am not sure if we need to provide such an API given there is already > dm_pci_bus_to_phys() and friends. Not sure we really need this new API > to add a check against the range. ... > If we really need this, I believe we can do some refactoring on the > existing _dm_pci_bus_to_phys() to provide the new capability you > wanted. A big reason is to check the range fits in the region, not just a single pointer. It looks like evolving the existing API might not be too tricky for that. The bit that really caused me trouble was that the PCI driver adds system memory as identity mapped regions. But that system memory hasn't been declared as part of the PCI bus so why is it being added? I want to remove that but don't know the background, or have the ability to test PCI will still work properly. We can't allow a virtio device to claim it has buffers in the middle of system memory and then have the driver blindly corrupt that region of memory, so there'll need to be a way to prevent that. > > + * @size: Size of the addressrange > > need a space before 'range' Ack. > Please add a test case in test/dm/pci.c to cover this new API. I was just learning about the sandbox testing, I'll take a look.
Re: [PATCH 06/11] virtio: pci: Read entire capability into memory
On Fri, Mar 25, 2022 at 5:18 PM Andrew Scull wrote: > > On Fri, 25 Mar 2022 at 07:51, Bin Meng wrote: > > > > On Fri, Mar 25, 2022 at 3:03 PM Andrew Scull wrote: > > > > > > On Fri, 25 Mar 2022 at 04:31, Bin Meng wrote: > > > > > > > > On Sun, Mar 20, 2022 at 7:42 PM Andrew Scull wrote: > > > > > > > > > > Read the virtio PCI capability out of the device configuration space > > > > > to > > > > > a struct rather than accessing fields directly from the configuration > > > > > space as they are needed. This both makes access to the fields easier > > > > > and avoids re-reading fields. > > > > > > > > > > Re-reading fields could result in time-of-check to time-of-use > > > > > problems, > > > > > should the value in the configuration space change. The range check of > > > > > the `bar` field and the later call to `dm_pci_read_bar32()` is an > > > > > example of where this could happen. > > > > > > > > I don't see the need to avoid the time-of-check to time-of-use > > > > problems, as it can only happen with the PCI configuration access > > > > capability, which U-Boot driver does not touch. > > > > > > > > Am I missing something? > > > > > > U-Boot doesn't touch the configuration space but the device could > > > have, whether that be accidently or maliciously. Linux has taken > > > similar precautions [1] to add more safety checks and I'll be looking > > > to do the same in other parts of the u-boot virtio drivers. > > > > > > [1] -- https://lwn.net/Articles/865216 > > > > > > > Got it. So basically the problem is that we don't trust the host that > > implements the virtio device :) > > > > I am curious that under such a guideline, probably lots of device > > drivers need to be enhanced to do the sanity check, no? > > Absolutely, they do! My focus is going to be primarily on the modern > PCI driver, vring and block driver. This will lay a foundation for the > others but they will also need to be checked over carefully before > being relied on. Do you know if the Linux kernel has a plan to apply such a guideline to some other drivers than virtio, like usb or nvme? There are devices that can do bad things too so we should not trust them? Regards, Bin
Re: data abort when run 'dhcp'
It's very strange. And I can't detect it's a bug of usb or dlmalloc. 1. Starting u-boot and dhcp via am335x's ethernet(cpsw driver), it's ok. 2. Starting u-boot and dhcp via am335x's usb net, data abort. 3. start fastboot, and CTRL C right now, dhcp via am335x's usb net, it's ok. 在 2022/3/24 17:33, qianfan 写道: 在 2022/3/23 18:12, Heinrich Schuchardt 写道: On 3/23/22 11:07, qianfan wrote: 在 2022/3/23 17:51, Heinrich Schuchardt 写道: On 3/23/22 10:13, qianfan wrote: 在 2022/3/23 16:02, qianfan 写道: 在 2022/3/23 15:45, qianfan 写道: 在 2022/3/23 10:28, qianfan 写道: Hi: I had a custom AM335X board connected my computer by usbnet. It always report data abort when 'dhcp': Next it the log: U-Boot 2022.01-rc1-00183-gfa5b4e2d19-dirty (Feb 25 2022 - 15:45:02 +0800) CPU : AM335X-GP rev 2.1 Model: WISDOM AM335X CCT DRAM: 512 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0 Loading Environment from NAND... *** Warning - bad CRC, using default environment Net: Could not get PHY for ethernet@4a10: addr 0 eth2: ethernet@4a10, eth3: usb_ether Hit any key to stop autoboot: 0 => setenv autoload no => dhcp using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in MAC de:ad:be:ef:00:01 HOST MAC de:ad:be:ef:00:00 RNDIS ready musb-hdrc: peripheral reset irq lost! high speed config #2: 2 mA, Ethernet Gadget, using RNDIS USB RNDIS network up! BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 DHCP client bound to address 192.168.200.4 (757 ms) data abort pc : [<9fe9b0a2>] lr : [<9febbc3f>] reloc pc : [<808130a2>] lr : [<80833c3f>] sp : 9de53410 ip : 9de53578 fp : 0001 r10: 9de5345c r9 : 9de67e80 r8 : 9febbae5 r7 : 9de72c30 r6 : 9feec710 r5 : 000d r4 : 0018 r3 : 3fdd8e04 r2 : 0002 r1 : 9feec728 r0 : 9feec700 Flags: Nzcv IRQs off FIQs on Mode SVC_32 (T) Code: f023 0303 60ca 4403 (6091) 685a Resetting CPU ... resetting ... It's there has any doc about how to debug data abort? Or is the bug is already fixed? Thanks This bug doesn't fixed on master code. I found v2021.01 is good and v2021.04-rc2 is bad. Also I had tested this on beaglebone black with am335x_evm_defconfig, has the simliar problem. find the first bug commit via 'git bisect': it told me that commit e97eb638de0dc8f6e989e20eaeb0342f103cb917 broke it. But it is very strange due to this commit doesn't touch any dhcp or network code. ➜ u-boot-main git:(e97eb638de) ✗ git bisect bug e97eb638de0dc8f6e989e20eaeb0342f103cb917 is the first bug commit commit e97eb638de0dc8f6e989e20eaeb0342f103cb917 Author: Heinrich Schuchardt Date: Wed Jan 20 22:21:53 2021 +0100 fs: fat: consistent error handling for flush_dir() Provide function description for flush_dir(). Move all error messages for flush_dir() from the callers to the function. Move mapping of errors to -EIO to the function. Always check return value of flush_dir() (Coverity CID 316362). In fat_unlink() return -EIO if flush_dirty_fat_buffer() fails. Signed-off-by: Heinrich Schuchardt :04 04 2281a449f2d134078d7faa1ee735a367b55aad7e 77d188b1c99181fd71f2167fdeee3434a09db209 M fs 184aa6504143b452132e28cd3ebecc7b941cdfa1 is the first commit before e97eb638de0dc8f6e989e20eaeb0342f103cb917: * e97eb638de0dc8f6e989e20eaeb0342f103cb917 fs: fat: consistent error handling for flush_dir() * 184aa6504143b452132e28cd3ebecc7b941cdfa1 Merge tag 'u-boot-rockchip-20210121' of https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip |\ | * 9ddc0787bd660214366e386ce689dd78299ac9d0 pci: Add Rockchip dwc based PCIe controller driver I checked 184aa6504143b452132e28cd3ebecc7b941cdfa1 can work fine. U-Boot 2021.01-00688-g184aa65041-dirty (Mar 23 2022 - 15:07:56 +0800) CPU : AM335X-GP rev 2.1 Model: TI AM335x BeagleBone Black DRAM: 512 MiB WDT: Started with servicing (60s timeout) NAND: 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Loading Environment from FAT... not set. Validating first E-fuse MAC Net: eth2: ethernet@4a10, eth3: usb_ether Hit any key to stop autoboot: 0 => dhcp ethernet@4a10 Waiting for PHY auto negotiation to complete. TIMEOUT ! using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in MAC de:ad:be:ef:00:01 HOST MAC de:ad:be:ef:00:00 RNDIS ready musb-hdrc: peripheral reset irq lost! high speed config #2: 2 mA, Ethernet Gadget, using RNDIS USB RNDIS network up! BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 DHCP client bound to address 192.168.200.157 (757 ms) Using usb_ether device TFTP from server 192.168.200.1; our IP address is 192.168.200.157 Filename 'u-boot.img'. Load address: 0x8200 Loading: # # # # 2.5 MiB/s done Bytes transferred = 1123888 (112630 hex) => "data abort" messages: data abort pc : [<9ff8196c>] lr : [<9ffa1cd7>]
Re: [RFC PATCH 1/6] capsule: Add Image GUIDs for platforms using capsule updates
hi Masami, On Fri, 25 Mar 2022 at 10:58, Masami Hiramatsu wrote: > > Hi Sughosh, > > OK I understand that if the platform uses the FIT capsule, the > fw_images[] must have 1 entry and it is completely non relationship > with dfu_alt_info... We may need a document for this case too. Actually, what you are stating above applies to both raw images as well as FIT images. I have added a paragraph in the capsule update related section in the uefi.rst. Can you check my patch 4 of this series. Thanks. -sughosh > > Thanks, > > 2022年3月25日(金) 10:09 Masami Hiramatsu : > > > > Hi Sughosh, > > > > 2022年3月24日(木) 23:40 Sughosh Ganu : > > > > > > hi Masami, > > > > > > On Thu, 24 Mar 2022 at 19:14, Masami Hiramatsu > > > wrote: > > > > > > > > Hi Sughosh, > > > > > > > > 2022年3月24日(木) 21:39 Sughosh Ganu : > > > > > > > > > > Currently, all platforms that enable capsule updates do so using > > > > > either EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID or > > > > > EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID. This is based on the Firmware > > > > > Management Protocol(FMP) instance used on the platform. However, this > > > > > means that all platforms that enable a particular FMP instance have > > > > > the same GUID value for all the updatable images, either the FIT image > > > > > GUID or the raw image GUID, and that an image for some platform can be > > > > > updated on any other platform which uses the same FMP instance. > > > > > Another > > > > > issue with this implementation is that the ESRT table shows the same > > > > > GUID value for all images on the platform and also across platforms, > > > > > which is not in compliance with the UEFI specification. > > > > > > > > > > Fix this by defining image GUID values and firmware names for > > > > > individual images per platform. The GetImageInfo FMP hook would then > > > > > populate these values in the image descriptor array. > > > > > > > > OK, so you have generated GUIDs for each "dfu_alt_info" entry on the > > > > platforms, correct? > > > > > > No, I have generated the fw_images array based on the information that > > > I found in the dfu_alt_info variable for the platform. But this is not > > > correlated to the dfu_alt_info variable. If you think that the array > > > should have more/different entries for your platform, please let me > > > know, and I will change it. > > > > At least for the DeveloperBox, it looks good to me. > > (Hopefully, if you comment the string formatted GUID in the code for > > mkeficapsule, that is perfect. :) ) > > > > > > I think you should explain that those GUIDs (fw_images[] entries) must > > > > be corresponding to the dfu_alt_info entries, in the same order. > > > > > > The dfu_alt_info can have more entries than the firmware images that > > > are updatable through capsule update. One example is the ST platforms > > > which have additional entries in the dfu_alt_info. The image > > > descriptor array should only contain entries of images which are > > > updatable through capsule update, since the same information is also > > > used for generating the ESRT. Which is why I have changed the logic to > > > populate the image descriptors through the fw_images array rather than > > > the dfu_alt_info. > > > > I meant, the order of the fw_images array needs to be same as > > dfu_alt_info entries and the firmware entries for dfu_alt_info must be > > the first, because finally we will use the index of the fw_images > > array, which matched to given image type GUID, for specifying > > dfu_alt_info entry. > > Or, without dfu_alt_info, your new fw_images can update the firmware? > > I would like to see such *relationship* at least in the patch > > description and the documentation. > > > > Thank you, > > > > > > > > > > -sughosh > > > > > > > Without that, it is hard to understand why the next patch ([2/6]) works > > > > :-) > > > > > > > > Thank you, > > > > > > > > > > > > > > Signed-off-by: Sughosh Ganu > > > > > --- > > > > > .../imx8mp_rsb3720a1/imx8mp_rsb3720a1.c | 19 +++ > > > > > .../imx8mm-cl-iot-gate/imx8mm-cl-iot-gate.c | 18 +++ > > > > > board/emulation/qemu-arm/qemu-arm.c | 20 > > > > > board/kontron/pitx_imx8m/pitx_imx8m.c | 15 +++- > > > > > board/kontron/sl-mx8mm/sl-mx8mm.c | 14 +++ > > > > > board/kontron/sl28/sl28.c | 14 +++ > > > > > board/sandbox/sandbox.c | 17 ++ > > > > > board/socionext/developerbox/developerbox.c | 23 > > > > > +++ > > > > > board/xilinx/common/board.h | 18 +++ > > > > > board/xilinx/zynq/board.c | 18 +++ > > > > > board/xilinx/zynqmp/zynqmp.c | 18 +++ > > > > > include/configs/imx8mm-cl-iot-gate.h | 10 > > > > > include/configs/imx8mp_rsb3720.h | 10 > > > > >
[PATCH] Fix URLs to old freescale git repos
Freescale git repos are now on source.codeaurora.org. Signed-off-by: Pali Rohár --- doc/README.mpc85xx-sd-spi-boot | 2 +- drivers/misc/mxc_ocotp.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/README.mpc85xx-sd-spi-boot b/doc/README.mpc85xx-sd-spi-boot index e3f580446a1c..329de4e6c4c1 100644 --- a/doc/README.mpc85xx-sd-spi-boot +++ b/doc/README.mpc85xx-sd-spi-boot @@ -14,7 +14,7 @@ Where to get boot_format: you can browse it online at: -http://git.freescale.com/git/cgit.cgi/ppc/sdk/boot-format.git/ +https://source.codeaurora.org/external/qoriq/qoriq-yocto-sdk/boot-format Building diff --git a/drivers/misc/mxc_ocotp.c b/drivers/misc/mxc_ocotp.c index b1893a5c7eba..8ee18f29d9be 100644 --- a/drivers/misc/mxc_ocotp.c +++ b/drivers/misc/mxc_ocotp.c @@ -6,7 +6,7 @@ * Based on Dirk Behme's * https://github.com/dirkbehme/u-boot-imx6/blob/28b17e9/drivers/misc/imx_otp.c, * which is based on Freescale's - * http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/tree/drivers/misc/imx_otp.c?h=imx_v2009.08_1.1.0=9aa74e6, + * https://source.codeaurora.org/external/imx/uboot-imx/tree/drivers/misc/imx_otp.c?id=9aa74e6, * which is: * Copyright (C) 2011 Freescale Semiconductor, Inc. */ -- 2.20.1
Re: [RFC PATCH 0/6] efi: capsule: Image GUID usage cleanup
hi Takahiro, On Fri, 25 Mar 2022 at 10:23, AKASHI Takahiro wrote: > > Sughosh, > > On Thu, Mar 24, 2022 at 06:08:55PM +0530, Sughosh Ganu wrote: > > > > This series is cleaning up the usage of the image GUIDs that are used > > in capsule update and the EFI System Resource Table(ESRT). > > > > Currently, there are two instances of the Firmware Management > > Protocol(FMP), one defined for updating the FIT images, and the other > > for updating raw images. The FMP code defines two GUID values, one for > > all FIT images, and one for raw images. Depending on the FMP instance > > used on a platform, the platform needs to use the corresponding image > > GUID value for all images on the platform, and also across platforms. > > > > A few issues are being fixed through the patch series. One, that an > > image for a different platform can be flashed on another platform if > > both the platforms are using the same FMP instance. So, for e.g. a > > capsule generated for the Socionext DeveloperBox platform can be > > flashed on the ZynqMP platform, since both the platforms use the > > CONFIG_EFI_CAPSULE_FIRMWARE_RAW instance of the FMP. This can be > > corrected if each firmware image that can be updated through the > > capsule update mechanism has it's own unique image GUID. > > Ok although the specification doesn't explicitly require the uniqueness > "across platforms". Yes, but unless we have a single image running on multiple platforms, we do need different GUID values across platforms. > > > The second issue that this patch series fixes is the value of FwClass > > in the ESRT. With the current logic, all firmware image entries in the > > ESRT display the same GUID value -- either the FIT GUID or the raw > > GUID. This is not in compliance with the UEFI specification, as the > > specification requires all entries to have unique GUID values. > > Well, this is *not* a problem of fit FMP driver, but a matter of how > ESRT is populated. Table 23-16 "ESRT and FMP Fields" says, > The ImageTypeId GUID from the Firmware > Management Protocol instance for a device is > used as the Firmware Class GUID in the ESRT. > Where there are multiple identical devices in > the system, system firmware must create a > mapping to ensure that the ESRT FwClass > GUIDs are unique and consistent. > The second sentence suggests that UEFI implementation, i.e. > efi_esrt_populate(), may and should allow some *mapping*. > > That said, I basically accept the requirement that you mention above. > > > The third issue being fixed is the population of the > > EFI_FIRMWARE_IMAGE_DESCRIPTOR array. The current code uses the dfu > > framework for populating the image descriptor array. However, there > > might be other images that are not to be updated through the capsule > > update mechanism also registered with the dfu framework. As a result > > of this, the ESRT will show up entries of images that are not to be > > targeted by the capsule update mechanism. > > > > These issues are being fixed by defining a structure, efi_fw_images. A > > platform can then define image related information like the image GUID > > and image name. Every platform that uses capsule update mechanism > > needs to define fw_images array. This array will then be used to > > populate the image descriptor array, and also in determining if a > > particular capsule's payload can be used for updating an image on the > > platform. > > When ESRT support patch was posted, I proposed that we should have > a kind of configuration table that defines all the firmware on the system > for ESRT, but this proposal was rejected. > Your efi_fw_images[] looks quite similar as what I had in mind. > Why not define efi_fw_images[] as ESRT itself. > (Of course, some fields in an entry can still be populated through > GetImageInfo API.) Currently, with this patch series, that is what is happening. The efi_fw_images array gets read by the GetImageInfo function, and that information gets used for populating the ESRT. Btw, I also want to extend this structure as part of a separate task, where we have information related to the dfu framework as part of the structure. Then the capsule related dfu information can be populated from this structure, instead of the dfu_alt_info env variable. This is what Ilias has suggested. But I will take this up as a separate exercise. > > > The first patch of this series adds the fw_images array in all > > platforms which are using UEFI capsule updates > > > > The second patch of the series changes the logic for populating the > > image descriptor array, using the information from the fw_images array > > defined by the platform. > > So a FIT image can still work as a single binary of firmware > under FIT FMP driver. Correct? Yes, this will still work. Only change is that every platform will have a separate image GUID for the FIT image. > > > The third patch of the series removes the test cases using the --raw >
Re: [PATCH 06/11] virtio: pci: Read entire capability into memory
On Fri, Mar 25, 2022 at 3:03 PM Andrew Scull wrote: > > On Fri, 25 Mar 2022 at 04:31, Bin Meng wrote: > > > > On Sun, Mar 20, 2022 at 7:42 PM Andrew Scull wrote: > > > > > > Read the virtio PCI capability out of the device configuration space to > > > a struct rather than accessing fields directly from the configuration > > > space as they are needed. This both makes access to the fields easier > > > and avoids re-reading fields. > > > > > > Re-reading fields could result in time-of-check to time-of-use problems, > > > should the value in the configuration space change. The range check of > > > the `bar` field and the later call to `dm_pci_read_bar32()` is an > > > example of where this could happen. > > > > I don't see the need to avoid the time-of-check to time-of-use > > problems, as it can only happen with the PCI configuration access > > capability, which U-Boot driver does not touch. > > > > Am I missing something? > > U-Boot doesn't touch the configuration space but the device could > have, whether that be accidently or maliciously. Linux has taken > similar precautions [1] to add more safety checks and I'll be looking > to do the same in other parts of the u-boot virtio drivers. > > [1] -- https://lwn.net/Articles/865216 > Got it. So basically the problem is that we don't trust the host that implements the virtio device :) I am curious that under such a guideline, probably lots of device drivers need to be enhanced to do the sanity check, no? Regards, Bin
Re: [PATCH 07/11] virtio: pci: Check virtio configs are mapped
On Fri, Mar 25, 2022 at 3:07 PM Andrew Scull wrote:
>
> On Fri, 25 Mar 2022 at 04:38, Bin Meng wrote:
> >
> > On Sun, Mar 20, 2022 at 7:42 PM Andrew Scull wrote:
> > >
> > > The calls to `virtio_pci_map_capability()` return NULL on error. If this
> > > happens, later accesses to the pointers would be unsafe. Avoid this by
> > > failing if the configs were not successfully mapped.
> > >
> > > Signed-off-by: Andrew Scull
> > > ---
> > > drivers/virtio/virtio_pci_modern.c | 25 -
> > > 1 file changed, 20 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/virtio/virtio_pci_modern.c
> > > b/drivers/virtio/virtio_pci_modern.c
> > > index 38a0da0a84..2f1a1cedbc 100644
> > > --- a/drivers/virtio/virtio_pci_modern.c
> > > +++ b/drivers/virtio/virtio_pci_modern.c
> > > @@ -534,7 +534,19 @@ static int virtio_pci_probe(struct udevice *udev)
> > > return -EINVAL;
> > > }
> > >
> > > + /* Map configuration structures */
> > > + priv->common = virtio_pci_map_capability(udev, _cap);
> > > + if (!priv->common) {
> >
> > This can't be NULL, as you did not pass a NULL capability pointer
> >
> > > + printf("(%s): could not map common config\n", udev->name);
> > > + return -EINVAL;
> > > + }
> > > +
> > > priv->notify_len = notify_cap.length;
> > > + priv->notify_base = virtio_pci_map_capability(udev, _cap);
> > > + if (!priv->notify_base) {
> > > + printf("(%s): could not map notify config\n", udev->name);
> > > + return -EINVAL;
> > > + }
> > >
> > > /*
> > > * Device capability is only mandatory for devices that have
> > > @@ -543,13 +555,16 @@ static int virtio_pci_probe(struct udevice *udev)
> > > device = virtio_pci_find_capability(udev,
> > > VIRTIO_PCI_CAP_DEVICE_CFG,
> > > sizeof(struct virtio_pci_cap),
> > > _cap);
> > > - if (device)
> > > + if (device) {
> > > priv->device_len = device_cap.length;
> > > + priv->device = virtio_pci_map_capability(udev,
> > > _cap);
> > > + if (!priv->device) {
> > > + printf("(%s): could not map device config\n",
> > > + udev->name);
> > > + return -EINVAL;
> > > + }
> > > + }
> > >
> > > - /* Map configuration structures */
> > > - priv->common = virtio_pci_map_capability(udev, _cap);
> > > - priv->notify_base = virtio_pci_map_capability(udev, _cap);
> > > - priv->device = virtio_pci_map_capability(udev, _cap);
> > > debug("(%p): common @ %p, notify base @ %p, device @ %p\n",
> > > udev, priv->common, priv->notify_base, priv->device);
> > >
> >
> > I don't think adding these checks is necessary.
>
> See later patches in the series that validate the address range is
> within the declared PCI ranges and not an arbitrary range chosen,
> accidently or maliciously, by the device. If those checks fail, the
> memory will not have been mapped and the probe should fail.
Yep, I see additional checks being added in patch 10, so the patch
order should be adjusted to let this patch come later.
Regards,
Bin
Re: [PATCH] arm64: zynqmp: enable the PMUFW watchdog
On 3/24/22 22:03, Jorge Ramirez-Ortiz, Foundries wrote:
On 24/03/22, Michal Simek wrote:
On 3/23/22 15:04, Jorge Ramirez-Ortiz wrote:
From 528b3117a36b7b4eea1839afbea7191d60638b0c Mon Sep 17 00:00:00 2001
From: Jorge Ramirez-Ortiz
Date: Wed, 23 Mar 2022 14:41:15 +0100
Subject: [PATCH] arm64: zynqmp: enable the PMUFW watchdog
If the PMUFW was built with support for the CSU watchdog we must let the
firmware know that it can be started.
We do this by faking the FSBL done state.
Reference code in PMUFW:
https://github.com/Xilinx/embeddedsw/blob/master/lib/sw_apps/zynqmp_pmufw/src/xpfw_mod_common.c#L36
It needs this fix on the PMUFW
https://github.com/Xilinx/embeddedsw/pull/190
/* FSBL might not be running anywhere - i.e: SPL boots PMUFW */
SPL doesn't boot PMUFW. It is the first firmware in BOOT.BIN which is loaded
by bootrom to PMU. It means comment is not correct.
FSBL or SPL just sending PMU configuration object to PMUFW.
yeah I guess it depends what you mean by boot - unless SPL configures it, it
wont really boot to a functional state.
but anyway ok, will change.
Signed-off-by: Jorge Ramirez-Ortiz
---
arch/arm/mach-zynqmp/include/mach/hardware.h | 5 -
board/xilinx/zynqmp/zynqmp.c | 4
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-zynqmp/include/mach/hardware.h
b/arch/arm/mach-zynqmp/include/mach/hardware.h
index a70d6d611b..24c3ef3d7d 100644
--- a/arch/arm/mach-zynqmp/include/mach/hardware.h
+++ b/arch/arm/mach-zynqmp/include/mach/hardware.h
@@ -174,8 +174,11 @@ struct csu_regs {
#define ZYNQMP_PMU_BASEADDR 0xFFD8
+#define FSBL_COMPLETION0x1
+
struct pmu_regs {
- u32 reserved[18];
+ u32 reserved[17];
+ u32 gen_storage5; /* 0x44 */
u32 gen_storage6; /* 0x48 */
};
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 70b3c81f12..c88c5fb8ea 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -419,6 +419,10 @@ int board_init(void)
zynqmp_pm_cfg_obj_size);
printf("Silicon version:\t%d\n", zynqmp_get_silicon_version());
+ /* fake FSBL completion to start the PMUFW watchdog when enabled */
+ writel(readl(_base->gen_storage5) | FSBL_COMPLETION,
+ _base->gen_storage5);
I look at the code in FSBL and it set it up XFsbl_HandoffExit which is at
the end of FSBL. It means this should be setup in SPL not in U-Boot proper.
not sure what you mean. This piece of code I am posting only executes in SPL,
doesn it?
ah. ok. Then fine.
M
Re: [PATCH 11/11] virtio: pci: Allow exclusion of legacy driver
On Sun, Mar 20, 2022 at 7:42 PM Andrew Scull wrote: > > Add a new config to control whether the driver for legacy virtio PCI > devices is included in the build. VIRTIO_PCI_LEGACY is included by > default when VIRTIO_PCI is selected, but it can also be indepedently typo: independently > toggled. > > Signed-off-by: Andrew Scull > --- > drivers/virtio/Kconfig | 9 + > drivers/virtio/Makefile | 3 ++- > 2 files changed, 11 insertions(+), 1 deletion(-) > Otherwise, Reviewed-by: Bin Meng
Re: [PATCH 10/11] virtio: pci: Check mapped range is in a PCI region
On Sun, Mar 20, 2022 at 7:42 PM Andrew Scull wrote:
>
> The virtio PCI capabilities describe a region of memory that should be
> mapped. Ensure those are valid PCI regions before accessing them.
>
> Signed-off-by: Andrew Scull
> ---
> drivers/virtio/virtio_pci_modern.c | 23 +++
> 1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/virtio/virtio_pci_modern.c
> b/drivers/virtio/virtio_pci_modern.c
> index 2f1a1cedbc..84750e2b27 100644
> --- a/drivers/virtio/virtio_pci_modern.c
> +++ b/drivers/virtio/virtio_pci_modern.c
> @@ -457,8 +457,9 @@ static int virtio_pci_find_capability(struct udevice
> *udev, u8 cfg_type,
> static void __iomem *virtio_pci_map_capability(struct udevice *udev,
>const struct virtio_pci_cap
> *cap)
> {
> - ulong base;
> - void __iomem *p;
> + unsigned long mask, flags;
> + phys_addr_t phys_addr;
> + u32 base;
>
> if (!cap)
> return NULL;
> @@ -470,9 +471,23 @@ static void __iomem *virtio_pci_map_capability(struct
> udevice *udev,
> * For simplicity, only read the BAR address as 32-bit.
> */
> base = dm_pci_read_bar32(udev, cap->bar);
> - p = (void __iomem *)base + cap->offset;
>
> - return p;
> + if (U32_MAX - base < cap->offset)
> + return NULL;
> + base += cap->offset;
> +
> + if (U32_MAX - base < cap->length)
> + return NULL;
> +
> + /* Find the corresponding memory region that isn't system memory. */
> + mask = PCI_REGION_TYPE | PCI_REGION_SYS_MEMORY;
> + flags = PCI_REGION_MEM;
> + phys_addr = dm_pci_bus_range_to_phys(dev_get_parent(udev), base,
> +cap->length, mask, flags);
> + if (!phys_addr)
> + return NULL;
> +
> + return (void __iomem *)map_physmem(phys_addr, cap->length,
> MAP_NOCACHE);
Could we use dm_pci_map_bar() instead?
I understand the way the current patch does is to add some sanity
checks against buggy virtio device implementations, but is it really
necessary, or can we move such check somewhere else, like in the
probe()?
> }
>
> static int virtio_pci_bind(struct udevice *udev)
> --
Regards,
Bin
Re: [PATCH 09/11] pci: Add function to validate PCI address range
On Sun, Mar 20, 2022 at 7:42 PM Andrew Scull wrote:
>
> Add a function to convert a PCI address range to a physical address
> range. The address range is validated to ensure it is contained within
> one of the PCI address regions and that the whole range can be indexed
> from the resulting physical address.
I am not sure if we need to provide such an API given there is already
dm_pci_bus_to_phys() and friends. Not sure we really need this new API
to add a check against the range.
>
> Signed-off-by: Andrew Scull
> ---
> drivers/pci/pci-uclass.c | 30 ++
> include/pci.h| 16
> 2 files changed, 46 insertions(+)
>
> diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
> index 54a05d7567..efab8916e2 100644
> --- a/drivers/pci/pci-uclass.c
> +++ b/drivers/pci/pci-uclass.c
> @@ -1452,6 +1452,36 @@ phys_addr_t dm_pci_bus_to_phys(struct udevice *dev,
> pci_addr_t bus_addr,
> return phys_addr;
> }
>
> +phys_addr_t dm_pci_bus_range_to_phys(struct udevice *dev, pci_addr_t
> bus_addr,
> +size_t size, unsigned long mask,
> +unsigned long flags)
> +{
> + struct udevice *ctlr = pci_get_controller(dev);
> + struct pci_controller *hose = dev_get_uclass_priv(ctlr);
> + struct pci_region *res;
> + size_t offset;
> + int i;
> +
> + for (i = 0; i < hose->region_count; i++) {
> + res = >regions[i];
> +
> + if ((res->flags & mask) != flags)
> + continue;
> +
> + if (bus_addr < res->bus_start)
> + continue;
> +
> + offset = bus_addr - res->bus_start;
> + if (offset >= res->size || size > res->size - offset)
> + continue;
> +
> + return res->phys_start + offset;
> + }
> +
> + puts("pci_bus_range_to_phys: invalid address range\n");
> + return 0;
> +}
If we really need this, I believe we can do some refactoring on the
existing _dm_pci_bus_to_phys() to provide the new capability you
wanted.
> +
> static int _dm_pci_phys_to_bus(struct udevice *dev, phys_addr_t phys_addr,
>unsigned long flags, unsigned long skip_mask,
>pci_addr_t *ba)
> diff --git a/include/pci.h b/include/pci.h
> index 673c95c6bb..15b3031c1f 100644
> --- a/include/pci.h
> +++ b/include/pci.h
> @@ -1446,6 +1446,22 @@ u32 dm_pci_read_bar32(const struct udevice *dev, int
> barnum);
> phys_addr_t dm_pci_bus_to_phys(struct udevice *dev, pci_addr_t addr,
>unsigned long flags);
>
> +/**
> + * dm_pci_bus_range_to_phys() - convert a PCI bus address range to a physical
> + * address.
> + *
> + * @dev: Device containing the PCI address
> + * @addr: PCI address to convert
> + * @size: Size of the addressrange
need a space before 'range'
> + * @mask: Mask of flags to match
> + * @flags: Flags for the region type (PCI_REGION_...)
> + * Return: physical address corresponding to that PCI bus address range or 0
> if
> + *the range could not be converted
> + */
> +phys_addr_t dm_pci_bus_range_to_phys(struct udevice *dev, pci_addr_t
> bus_addr,
> +size_t size, unsigned long mask,
> +unsigned long flags);
> +
> /**
> * dm_pci_phys_to_bus() - convert a physical address to a PCI bus address
> *
Please add a test case in test/dm/pci.c to cover this new API.
Regards,
Bin
Re: [PATCH 08/11] pci: Check region ranges are addressable
On Sun, Mar 20, 2022 at 7:42 PM Andrew Scull wrote: > > When parsing the `ranges` DT node, check that both extremes of the > regions are addressable without overflow. This assumption can then be > safely made when processing the regions. > > Signed-off-by: Andrew Scull > --- > drivers/pci/pci-uclass.c | 17 - > 1 file changed, 16 insertions(+), 1 deletion(-) > Reviewed-by: Bin Meng
Re: [PATCH v2 0/9] efi_loader: booting via short-form device-path
Heinrich, I made the same complaint several times in the past. If I made some comments on your patches, don't merge them until we have reached the agreement even you are the maintainer. It's not the way how the community development should work. This happened again with this patch series. -Takahiro Akashi On Sat, Mar 19, 2022 at 10:11:39AM +0100, Heinrich Schuchardt wrote: > The GUID of partitions is sufficient for identification and will stay > constant in the lifetime of a boot option. The preceding path of the > device-path may change due to changes in the enumeration of devices. > Therefore it is preferable to use the short-form of device-paths in load > options. > > > With this series booting via short-form device-paths is reenable. > The 'efidebug boot add' command is adjusted to create either short-form > or long-form device paths. > > The check for the EFI System Partition used for capsule updates is > corrected. > > A unit test for the boot manager is added. > > v2: > merge multiple patches to a series > fix ESP detection > > Heinrich Schuchardt (9): > efi_loader: export efi_dp_shorten() > efi_loader: fix efi_dp_find_obj() > efi_loader: efi_dp_find_obj() add protocol check > efi_loader: support booting via short-form device-path > efi_loader: use short-form DP for load options > efi_loader: export efi_system_partition_guid > efi_loader: remove efi_disk_is_system_part() > efi_loader: move dtbdump.c, initrddump.c to lib/efi_loader > test: test UEFI boot manager > > cmd/efidebug.c| 70 ++- > include/efi_loader.h | 12 +- > lib/efi_loader/Makefile | 12 + > lib/efi_loader/dtbdump.c | 539 ++ > lib/efi_loader/efi_boottime.c | 22 +- > lib/efi_loader/efi_capsule.c | 13 +- > lib/efi_loader/efi_device_path.c | 138 +++-- > lib/efi_loader/efi_disk.c | 31 +- > lib/efi_loader/initrddump.c | 449 +++ > lib/efi_selftest/Makefile | 12 - > lib/efi_selftest/dtbdump.c| 539 -- > lib/efi_selftest/initrddump.c | 449 --- > test/py/tests/test_efi_bootmgr/conftest.py| 42 ++ > .../test_efi_bootmgr/test_efi_bootmgr.py | 31 + > 14 files changed, 1232 insertions(+), 1127 deletions(-) > create mode 100644 lib/efi_loader/dtbdump.c > create mode 100644 lib/efi_loader/initrddump.c > delete mode 100644 lib/efi_selftest/dtbdump.c > delete mode 100644 lib/efi_selftest/initrddump.c > create mode 100644 test/py/tests/test_efi_bootmgr/conftest.py > create mode 100644 test/py/tests/test_efi_bootmgr/test_efi_bootmgr.py > > -- > 2.34.1 >
Re: [PATCH v4 00/11] enable menu-driven boot device selection
Hi Akashi-san,
On Fri, 25 Mar 2022 at 10:20, Takahiro Akashi
wrote:
>
> Kojima-san,
>
> On Thu, Mar 24, 2022 at 10:54:32PM +0900, Masahisa Kojima wrote:
> > This patch series adds the menu-driven boot device selection,
> > by extending the existing "bootmenu" to include UEFI and distro_boot
> > related entries, and supports menu-driven UEFI boot variable
> > maintenance.
> >
> > This patch series also includes the removable media support
> > that UEFI specification requires to support.
> >
> > The menu example is as follows.
>
> Good job done, Kojima-san. I like it.
> Before reviewing each commit, I would suggest a couple of
> improvements on the menu itself.
> They are more or less my opinion and other people may have
> their own preference, though.
Thank you for your comment and verifying the actual behavior.
>
> 1) Top menu (U-Boot Boot Menu)
> - In general, it's a bit difficult to understand from where
>each menu item comes and what it means.
>For instance,
> > UEFI BOOT : debian
>is a user-defined boot option, while
> > UEFI BOOT0002 : mmc0:1
>is an option for removable media. Correct?
Yes, and I agree that the current menu title is a bit difficult to understand,
especially for automatically listed removable media(e.g. mmc0:1).
>
> - I'd prefer to categorize items into sub-menus, particularly,
>UEFI items.
>
>bootmenu_...
>distro_boot ...
>UEFI Boot
>UEFI Boot Manager Maintenance
Yes, it is a good idea.
On the other hand, if user prefers simpler menu and only uses UEFI Boot
for example, bootmenu_xx and distro boot entries can be removed by
updating the U-Boot environment variable(remove bootmenu_xx
and boot_targets).
>
>and "UEFI Boot" sub-menu shows
> > UEFI BOOT : debian
> > UEFI BOOT0001 : ubuntu
>in an order of "BootOrder",
>
>and
> /* not selectable */
> > UEFI BOOT0002 : mmc0:1
> > UEFI BOOT0003 : mmc0:2
It is a little difficult.
UEFI BootOrder variable is also automatically updated by bootmenu
to include the removable media, so the entries that user defined
Boot and automatically added removable media are mixed in
BootOrder.
The UEFI Boot entry is displayed in the order of BootOrder.
>
> - For UEFI items, I want to do "e" (edit/modify) directly here
>to change the option.
It is the same as the Grub menu. I will consider it but let me set
as a low priority now.
>
> - When "U-Boot console" is selected, the prompt ("=>") is displayed
>like
>UEFI Boot Manager Maintenance
> U-Boot console=>
>It should be output at the beginning of the next line or
>the screen be cleaned up before showing the prompt.
Thank you. It should be fixed.
>
> - What not have "Quit" here?
OK, I will consider to add.
>
> 2) UEFI Boot Manager Maintenance
> - The title should be "UEFI Boot Manager Maintenance".
"UEFI Boot Manager Maintenance" is the same as the current one.
> - I want to have "Edit(Modify) Boot Option"
Yes, I agree.
> - "Add Boot Option"
>- The menu titles should be "Select a device" and "Select a file".
Current "Add Boot Option" will support the "Select a file" feature.
I think the user will normally use the boot option having FilePath.
>- Some devices are shown, some are not. Why?
> Do we have to run, say, "scsi rescan" beforehand?
Current bootmenu enumerates the all devices implementing
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.
If some devices are not shown, please run the discover command
like "scsi rescan" then re-enter the bootmenu with "bootmenu" command.
If the all devices listed by "efidebug dh" having
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL are not shown in bootmenu,
something wrong in my code.
>- How can we specify "removable media" without a file path?
This patch series only supports the auto enumeration.
I think the user will not manually add the "removable media".
>- At "file selection" menu, "Esc" should let us go back to
> the "device selection" menu rather than the top, "Add Boot Option".
Yes, I agree.
>- We should be able to specify initrd path, i.e. the second device path
> in a boot option.
>- We should be able to specify "optional data" in a boot option.
> - "Change Boot Order"
I consider supporting these two items.
>- I like a more intuitive operation here. Say,
> select an item with "Enter" and then use "Up" and "Down" to move it
> around.
Yes, I agree and try to improve.
> - Probably, it would be better to have the final confirmation, like
>"Do you want to save the change?"
Yes, same for "Delete Boot Option".
Thanks,
Masahisa Kojima
>
> Thanks,
> -Takahiro Akashi
>
> > *** U-Boot Boot Menu ***
> >
> > bootmenu_00 : Boot 1. kernel
> > bootmenu_01 : Boot 2. kernel
> > bootmenu_02 : Reset board
> > UEFI BOOT : debian
> > UEFI BOOT0001 : ubuntu
> > UEFI BOOT0002 : mmc0:1
> > UEFI BOOT0003 : mmc0:2
> > UEFI
