February 2022 - U-Boot

Boot from specified partition (or FS) UUID without knowing Device ID
by Tom Hale 19 Feb '22

19 Feb '22

I want to have a fallback boot situation where boot is first tried from one partition, and then from another partition (on a different device) if the first partition isn't available (eg, if the first device fails). Can I boot from a specific FS UUID or a partition UUID without knowing a particular device ID? (I'm not sure if my devices will always be detected in a repeatable order). Can fatload be used with only a partition UUID? Or can I somehow get the dev number from the UUID? Thanks in advance, Tom

4 4

[PATCH 1/1] tools: mkefitools: remove duplicate test
by Heinrich Schuchardt 19 Feb '22

19 Feb '22

This resolves Coverity CID 348360. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- tools/mkeficapsule.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c index f7590e482f..c118335b93 100644 --- a/tools/mkeficapsule.c +++ b/tools/mkeficapsule.c @@ -210,8 +210,6 @@ static int create_auth_data(struct auth_context *ctx) cert.size = file_size; ret = read_bin_file(ctx->key_file, &key.data, &file_size); - if (ret < 0) - return -1; if (ret < 0) return -1; if (file_size > UINT_MAX) -- 2.34.1

2 1

[PATCH v5 00/16] image: add a stage pre-load
by Philippe Reynes 19 Feb '22

19 Feb '22

This serie adds a stage pre-load before launching an image. This stage is used to read a header before the image and this header contains the signature of the full image. So u-boot may check the full image before using any data of the image. The support of this header is added to binman, and a command verify checks the signature of a blob and set the u-boot env variable "loadaddr_verified" to the beginning of the "real" image. The support of this header is only added to binman, but it may also be added to mkimage. Changelog: v5: - replace config SANDBOX_BINMAN by an imply v4: - add a config SANDBOX_BIN - enhance help for asn1 and oid - change the format of the pre-load header - add the support of pre-load header in binman - add py test for pre-load header - add a command verify v3: - move image-pre-load.c to /boot - update mkimage to add public key in u-boot device tree - add script gen_pre_load_header.sh v2: - move the code to image-pre-load - add support of stage pre-load for spl - add support of stage pre-load on spl_ram Philippe Reynes (16): arch: Kconfig: imply BINMAN for SANDBOX lib: Kconfig: enhance help for ASN1 lib: Kconfig: enhance the help of OID_REGISTRY lib: allow to build asn1 decoder and oid registry in SPL lib: crypto: allow to build crypyo in SPL lib: rsa: allow rsa verify with pkey in SPL boot: image: add a stage pre-load cmd: bootm: add a stage pre-load common: spl: fit_ram: allow to use image pre load mkimage: add public key for image pre-load stage Makefile: provide sah-key to binman tools: binman: add support for pre-load header configs: sandbox_defconfig: enable stage pre-load in bootm test: py: vboot: add test for global image signature cmd: verify: initial import configs: sandbox_defconfig: enable config CMD_VERIFY Makefile | 1 + arch/Kconfig | 1 + arch/sandbox/dts/sandbox.dtsi | 3 + arch/sandbox/dts/test.dts | 3 + boot/Kconfig | 55 +++ boot/Makefile | 1 + boot/bootm.c | 33 ++ boot/image-pre-load.c | 408 ++++++++++++++++++ cmd/Kconfig | 17 + cmd/Makefile | 1 + cmd/bootm.c | 2 +- cmd/verify.c | 53 +++ common/spl/spl_ram.c | 21 +- configs/sandbox_defconfig | 4 + include/image.h | 30 ++ lib/Kconfig | 37 +- lib/Makefile | 10 +- lib/crypto/Kconfig | 29 ++ lib/crypto/Makefile | 19 +- lib/rsa/Kconfig | 19 + test/py/tests/test_fit.py | 3 + test/py/tests/test_vboot.py | 123 +++++- 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/sandbox-u-boot.dts | 3 + test/py/tests/vboot/simple-images.its | 36 ++ tools/binman/etype/pre_load.py | 156 +++++++ tools/fit_image.c | 3 + tools/image-host.c | 114 +++++ 31 files changed, 1262 insertions(+), 27 deletions(-) create mode 100644 boot/image-pre-load.c create mode 100644 cmd/verify.c 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 create mode 100644 tools/binman/etype/pre_load.py -- 2.17.1

2 23

Re: U-Boot Digest, Vol 165, Issue 29
by Walter Heck 19 Feb '22

19 Feb '22

Unsubscribe On Sun, Feb 13, 2022, 12:00 <u-boot-request(a)lists.denx.de> wrote: > Send U-Boot mailing list submissions to > u-boot(a)lists.denx.de > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.denx.de/listinfo/u-boot > or, via email, send a message with subject or body 'help' to > u-boot-request(a)lists.denx.de > > You can reach the person managing the list at > u-boot-owner(a)lists.denx.de > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of U-Boot digest..." > > > Today's Topics: > > 1. Re: [PATCH 2/2] net: phy: mv88e6352: Fix > miiphy_read/miiphy_write return value checks (Ramon Fried) > 2. [PATCH 1/2] arm: omap3: Cleanup sys_info to fit OMAP3 booting > with LTO (Adam Ford) > 3. [PATCH 2/2] arm: omap3: Make some memory functions static and > clean headers (Adam Ford) > 4. [PATCH] tools/zynqmp_pm_cfg_obj_convert.py: fix build with > Vivado 2021.x (Luca Ceresoli) > 5. [PATCH] usb: ehci-omap: Drop dead code (Adam Ford) > 6. Re: [ANN] U-Boot v2022.04-rc1 released (Andy Shevchenko) > 7. Re: [ANN] U-Boot v2022.04-rc1 released (Michal Simek) > 8. Re: [PATCH] image: Control FIT signature verification at > runtime (Alex G.) > 9. Re: Problem IMX8MN booting legacy kernel and mipi display > (Michael Nazzareno Trimarchi) > 10. [PATCH] tools: kwbimage: Fix dumping DATA registers for v0 > images (Pali Roh?r) > 11. [PATCH] tools: mkimage/dumpimage: Allow to use -l with -T > (Pali Roh?r) > 12. [PATCH 1/7] microblaze: exception: move privileged > instruction exception out of v5 ifdef (Ovidiu Panait) > 13. [PATCH 5/7] microblaze: exception: move unaligned access > printfs inside switch case (Ovidiu Panait) > 14. [PATCH 3/7] microblaze: exception: fix delay slot exception > handling (Ovidiu Panait) > 15. [PATCH 7/7] microblaze: exception: drop user exception > support (Ovidiu Panait) > 16. [PATCH 6/7] microblaze: exception: fix unaligned data access > register mask (Ovidiu Panait) > 17. [PATCH 2/7] microblaze: exception: migrate MICROBLAZE_V5 to > Kconfig (Ovidiu Panait) > 18. [PATCH 4/7] microblaze: exception: fix return address for > delay slot exceptions (Ovidiu Panait) > 19. Re: [PATCH v4 1/2] efi_loader: use > efi_update_capsule_firmware() for capsule on disk > (Heinrich Schuchardt) > 20. Re: [PATCH v4 2/2] efi_loader: Reset system after > CapsuleUpdate on disk (Heinrich Schuchardt) > 21. Re: [PATCH 3/3] efi_loader: add menu-driven UEFI Boot > Variable maintenance (Heinrich Schuchardt) > 22. Re: [PATCH 1/3] efi_loader: add menu-driven boot device > selection (Heinrich Schuchardt) > 23. Re: [PATCH 2/3] lib/charset: add u16_strcat() function > (Heinrich Schuchardt) > 24. Re: [PATCH v4 2/2] efi_loader: Reset system after > CapsuleUpdate on disk (Heinrich Schuchardt) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 12 Feb 2022 13:50:05 +0200 > From: Ramon Fried <rfried.dev(a)gmail.com> > To: Daniel Klauer <daniel.klauer(a)gin.de> > Cc: U-Boot Mailing List <u-boot(a)lists.denx.de> > Subject: Re: [PATCH 2/2] net: phy: mv88e6352: Fix > miiphy_read/miiphy_write return value checks > Message-ID: > < > CAGi-RU+mJcJ4aceUXQWUL-v80zwUdOaoZC--zeLL6C64SPcB9A(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On Wed, Feb 9, 2022 at 5:41 PM Daniel Klauer <daniel.klauer(a)gin.de> wrote: > > > > The miiphy_read/miiphy_write functions return 1 on error, not -errno. > Why don't you just fix the miiphy_read/miiphy_write functions ? > > > ------------------------------ > > Message: 2 > Date: Sat, 12 Feb 2022 06:12:40 -0600 > From: Adam Ford <aford173(a)gmail.com> > To: u-boot(a)lists.denx.de > Cc: trini(a)konsulko.com, aford(a)beaconembedded.com, Adam Ford > <aford173(a)gmail.com> > Subject: [PATCH 1/2] arm: omap3: Cleanup sys_info to fit OMAP3 booting > with LTO > Message-ID: <20220212121241.1655425-1-aford173(a)gmail.com> > > With LTO enabled, some functions appear to be optimized in a > way that causes hanging on some OMAP3 boards after some > unrelated patches were applied. The solution appears to make > several functions __used. There also appears be to be some > dead code, so remove it while cleaning this up. > > This has been tested on a general purpose OMAP3530, DM3730, > and AM3517. > > Signed-off-by: Adam Ford <aford173(a)gmail.com> > > diff --git a/arch/arm/include/asm/arch-omap3/sys_proto.h > b/arch/arm/include/asm/arch-omap3/sys_proto.h > index a6e9ff84aa..e7078a32db 100644 > --- a/arch/arm/include/asm/arch-omap3/sys_proto.h > +++ b/arch/arm/include/asm/arch-omap3/sys_proto.h > @@ -45,16 +45,12 @@ void gpmc_init(void); > void enable_gpmc_cs_config(const u32 *gpmc_config, const struct gpmc_cs > *cs, > u32 base, u32 size); > void set_gpmc_cs0(int flash_type); > - > void watchdog_init(void); > void set_muxconf_regs(void); > - > u32 get_cpu_family(void); > u32 get_cpu_rev(void); > -u32 get_sku_id(void); > u32 is_gpmc_muxed(void); > u32 get_gpmc0_type(void); > -u32 get_gpmc0_width(void); > u32 is_running_in_sdram(void); > u32 is_running_in_sram(void); > u32 is_running_in_flash(void); > diff --git a/arch/arm/mach-omap2/omap3/sys_info.c > b/arch/arm/mach-omap2/omap3/sys_info.c > index ac72633c20..5f535e2782 100644 > --- a/arch/arm/mach-omap2/omap3/sys_info.c > +++ b/arch/arm/mach-omap2/omap3/sys_info.c > @@ -55,7 +55,7 @@ void omap_die_id(unsigned int *die_id) > /****************************************** > * get_cpu_type(void) - extract cpu info > ******************************************/ > -u32 get_cpu_type(void) > +static u32 get_cpu_type(void) > { > return readl(&ctrl_base->ctrl_omap_stat); > } > @@ -64,7 +64,7 @@ u32 get_cpu_type(void) > * get_cpu_id(void) - extract cpu id > * returns 0 for ES1.0, cpuid otherwise > ******************************************/ > -u32 get_cpu_id(void) > +static u32 get_cpu_id(void) > { > struct ctrl_id *id_base; > u32 cpuid = 0; > @@ -89,7 +89,7 @@ u32 get_cpu_id(void) > /****************************************** > * get_cpu_family(void) - extract cpu info > ******************************************/ > -u32 get_cpu_family(void) > +__used u32 get_cpu_family(void) > { > u16 hawkeye; > u32 cpu_family; > @@ -119,7 +119,7 @@ u32 get_cpu_family(void) > /****************************************** > * get_cpu_rev(void) - extract version info > ******************************************/ > -u32 get_cpu_rev(void) > +__used u32 get_cpu_rev(void) > { > u32 cpuid = get_cpu_id(); > > @@ -132,41 +132,12 @@ u32 get_cpu_rev(void) > /***************************************************************** > * get_sku_id(void) - read sku_id to get info on max clock rate > *****************************************************************/ > -u32 get_sku_id(void) > +static u32 get_sku_id(void) > { > struct ctrl_id *id_base = (struct ctrl_id *)OMAP34XX_ID_L4_IO_BASE; > return readl(&id_base->sku_id) & SKUID_CLK_MASK; > } > > > -/*************************************************************************** > - * get_gpmc0_base() - Return current address hardware will be > - * fetching from. The below effectively gives what is correct, its a > bit > - * mis-leading compared to the TRM. For the most general case the mask > - * needs to be also taken into account this does work in practice. > - * - for u-boot we currently map: > - * -- 0 to nothing, > - * -- 4 to flash > - * -- 8 to enent > - * -- c to wifi > - > ****************************************************************************/ > -u32 get_gpmc0_base(void) > -{ > - u32 b; > - > - b = readl(&gpmc_cfg->cs[0].config7); > - b &= 0x1F; /* keep base [5:0] */ > - b = b << 24; /* ret 0x0b000000 */ > - return b; > -} > - > -/******************************************************************* > - * get_gpmc0_width() - See if bus is in x8 or x16 (mainly for nand) > - *******************************************************************/ > -u32 get_gpmc0_width(void) > -{ > - return WIDTH_16BIT; > -} > - > /************************************************************************* > * get_board_rev() - setup to pass kernel board revision information > * returns:(bit[0-3] sub version, higher bit[7-4] is higher version) > -- > 2.32.0 > > > > ------------------------------ > > Message: 3 > Date: Sat, 12 Feb 2022 06:12:41 -0600 > From: Adam Ford <aford173(a)gmail.com> > To: u-boot(a)lists.denx.de > Cc: trini(a)konsulko.com, aford(a)beaconembedded.com, Adam Ford > <aford173(a)gmail.com> > Subject: [PATCH 2/2] arm: omap3: Make some memory functions static and > clean headers > Message-ID: <20220212121241.1655425-2-aford173(a)gmail.com> > > There are a few memory functions for both the emif4 (AM3517) > and sdrc (OMAP35/DM37) code that can be defined as static, > because those functions are not used externally. Make them > static and clean up some of the corresponding headers. > > Signed-off-by: Adam Ford <aford173(a)gmail.com> > > diff --git a/arch/arm/include/asm/arch-omap3/mem.h > b/arch/arm/include/asm/arch-omap3/mem.h > index 7adc134a75..569779c55e 100644 > --- a/arch/arm/include/asm/arch-omap3/mem.h > +++ b/arch/arm/include/asm/arch-omap3/mem.h > @@ -480,7 +480,6 @@ void mem_init(void); > u32 is_mem_sdr(void); > u32 mem_ok(u32 cs); > > -u32 get_sdr_cs_size(u32); > u32 get_sdr_cs_offset(u32); > > #endif /* __ASSEMBLY__ */ > diff --git a/arch/arm/include/asm/arch-omap3/sys_proto.h > b/arch/arm/include/asm/arch-omap3/sys_proto.h > index e7078a32db..3e6335c5fa 100644 > --- a/arch/arm/include/asm/arch-omap3/sys_proto.h > +++ b/arch/arm/include/asm/arch-omap3/sys_proto.h > @@ -33,11 +33,8 @@ struct board_sdrc_timings { > void prcm_init(void); > void per_clocks_enable(void); > void ehci_clocks_enable(void); > - > void memif_init(void); > void sdrc_init(void); > -void do_sdrc_init(u32, u32); > - > void get_board_mem_timings(struct board_sdrc_timings *timings); > int identify_nand_chip(int *mfr, int *id); > void emif4_init(void); > @@ -60,12 +57,10 @@ void invalidate_dcache(u32); > u32 wait_on_value(u32, u32, void *, u32); > void cancel_out(u32 *num, u32 *den, u32 den_limit); > void sdelay(unsigned long); > -void make_cs1_contiguous(void); > int omap_nand_switch_ecc(uint32_t, uint32_t); > void power_init_r(void); > void do_omap3_emu_romcode_call(u32 service_id, u32 parameters); > void omap3_set_aux_cr_secure(u32 acr); > u32 warm_reset(void); > - > void save_omap_boot_params(void); > #endif > diff --git a/arch/arm/mach-omap2/omap3/emif4.c > b/arch/arm/mach-omap2/omap3/emif4.c > index df6e9ce1d6..d7d779819b 100644 > --- a/arch/arm/mach-omap2/omap3/emif4.c > +++ b/arch/arm/mach-omap2/omap3/emif4.c > @@ -35,7 +35,7 @@ u32 is_mem_sdr(void) > * get_sdr_cs_size - > * - Get size of chip select 0/1 > */ > -u32 get_sdr_cs_size(u32 cs) > +static u32 get_sdr_cs_size(u32 cs) > { > u32 size = 0; > > diff --git a/arch/arm/mach-omap2/omap3/sdrc.c > b/arch/arm/mach-omap2/omap3/sdrc.c > index 4d85b1dee9..07f534a60b 100644 > --- a/arch/arm/mach-omap2/omap3/sdrc.c > +++ b/arch/arm/mach-omap2/omap3/sdrc.c > @@ -44,13 +44,28 @@ u32 is_mem_sdr(void) > return 0; > } > > +/* > + * get_sdr_cs_size - > + * - Get size of chip select 0/1 > + */ > +static u32 get_sdr_cs_size(u32 cs) > +{ > + u32 size; > + > + /* get ram size field */ > + size = readl(&sdrc_base->cs[cs].mcfg) >> 8; > + size &= 0x3FF; /* remove unwanted bits */ > + size <<= 21; /* multiply by 2 MiB to find size in MB */ > + return size; > +} > + > /* > * make_cs1_contiguous - > * - When we have CS1 populated we want to have it mapped after cs0 to > allow > * command line mem=xyz use all memory with out discontinuous support > * compiled in. We could do it in the ATAG, but there really is two > banks... > */ > -void make_cs1_contiguous(void) > +static void make_cs1_contiguous(void) > { > u32 size, a_add_low, a_add_high; > > @@ -62,22 +77,6 @@ void make_cs1_contiguous(void) > > } > > - > -/* > - * get_sdr_cs_size - > - * - Get size of chip select 0/1 > - */ > -u32 get_sdr_cs_size(u32 cs) > -{ > - u32 size; > - > - /* get ram size field */ > - size = readl(&sdrc_base->cs[cs].mcfg) >> 8; > - size &= 0x3FF; /* remove unwanted bits */ > - size <<= 21; /* multiply by 2 MiB to find size in MB */ > - return size; > -} > - > /* > * get_sdr_cs_offset - > * - Get offset of cs from cs0 start > @@ -128,7 +127,7 @@ static void write_sdrc_timings(u32 cs, struct > sdrc_actim *sdrc_actim_base, > * true and a possible 2nd time depending on memory configuration from > * stack+global context. > */ > -void do_sdrc_init(u32 cs, u32 early) > +static void do_sdrc_init(u32 cs, u32 early) > { > struct sdrc_actim *sdrc_actim_base0, *sdrc_actim_base1; > struct board_sdrc_timings timings; > -- > 2.32.0 > > > > ------------------------------ > > Message: 4 > Date: Sat, 12 Feb 2022 13:51:21 +0100 > From: Luca Ceresoli <luca(a)lucaceresoli.net> > To: u-boot(a)lists.denx.de > Cc: Luca Ceresoli <luca(a)lucaceresoli.net>, Michal Simek > <michal.simek(a)xilinx.com>, Giulio Benetti > <giulio.benetti(a)benettiengineering.com>, Neal Frager > <nealf(a)xilinx.com> > Subject: [PATCH] tools/zynqmp_pm_cfg_obj_convert.py: fix build with > Vivado 2021.x > Message-ID: <20220212125121.3398547-1-luca(a)lucaceresoli.net> > > This tool fails with a pm_cfg_obj.c file generated by Vitis 2021.2. This is > because that version of Vitis added the PM_CONFIG_OBJECT_TYPE_BASE that was > not previously generated, thus the script does not implement it. > > Reported-by: Neal Frager <nealf(a)xilinx.com> > [report: > https://lists.buildroot.org/pipermail/buildroot/2022-February/636639.html] > Signed-off-by: Luca Ceresoli <luca(a)lucaceresoli.net> > --- > tools/zynqmp_pm_cfg_obj_convert.py | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/tools/zynqmp_pm_cfg_obj_convert.py > b/tools/zynqmp_pm_cfg_obj_convert.py > index 0a44710e1e14..239991a5263c 100755 > --- a/tools/zynqmp_pm_cfg_obj_convert.py > +++ b/tools/zynqmp_pm_cfg_obj_convert.py > @@ -244,6 +244,8 @@ pm_define = { > > 'SUSPEND_TIMEOUT' : 0xFFFFFFFF, > > + 'PM_CONFIG_OBJECT_TYPE_BASE' : 0x1, > + > 'PM_CONFIG_IPI_PSU_CORTEXA53_0_MASK' : 0x00000001, > 'PM_CONFIG_IPI_PSU_CORTEXR5_0_MASK' : 0x00000100, > 'PM_CONFIG_IPI_PSU_CORTEXR5_1_MASK' : 0x00000200, > -- > 2.25.1 > > > > ------------------------------ > > Message: 5 > Date: Sat, 12 Feb 2022 08:26:40 -0600 > From: Adam Ford <aford173(a)gmail.com> > To: u-boot(a)lists.denx.de > Cc: marex(a)denx.de, trini(a)konsulko.com, Adam Ford < > aford173(a)gmail.com> > Subject: [PATCH] usb: ehci-omap: Drop dead code > Message-ID: <20220212142640.1669851-1-aford173(a)gmail.com> > > omap_ehci_hcd_stop appears to be dead code, and omap_ehci_hcd_init > is only called by the probe function, so it can be static to that > function. Remove both from the header along with some additional > checking for DM_USB. > > Signed-off-by: Adam Ford <aford173(a)gmail.com> > > diff --git a/arch/arm/include/asm/ehci-omap.h > b/arch/arm/include/asm/ehci-omap.h > index f970bba937..2b51b5eb99 100644 > --- a/arch/arm/include/asm/ehci-omap.h > +++ b/arch/arm/include/asm/ehci-omap.h > @@ -123,17 +123,4 @@ struct omap_ehci { > u32 insreg08; /* 0xb0 */ > }; > > -#if !CONFIG_IS_ENABLED(DM_USB) || !CONFIG_IS_ENABLED(OF_CONTROL) > -/* > - * FIXME: forward declaration of this structs needed because omap got the > - * ehci implementation backwards. move out ehci_hcd_x from board files > - */ > -struct ehci_hccr; > -struct ehci_hcor; > - > -int omap_ehci_hcd_init(int index, struct omap_usbhs_board_data > *usbhs_pdata, > - struct ehci_hccr **hccr, struct ehci_hcor **hcor); > -int omap_ehci_hcd_stop(void); > -#endif > - > #endif /* _OMAP_COMMON_EHCI_H_ */ > diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c > index d5facf10e1..d34c0add4a 100644 > --- a/drivers/usb/host/ehci-omap.c > +++ b/drivers/usb/host/ehci-omap.c > @@ -163,27 +163,12 @@ static inline void omap_ehci_phy_reset(int on, int > delay) > #define omap_ehci_phy_reset(on, delay) do {} while (0) > #endif > > -/* Reset is needed otherwise the kernel-driver will throw an error. */ > -int omap_ehci_hcd_stop(void) > -{ > - debug("Resetting OMAP EHCI\n"); > - omap_ehci_phy_reset(1, 0); > - > - if (omap_uhh_reset() < 0) > - return -1; > - > - if (omap_ehci_tll_reset() < 0) > - return -1; > - > - return 0; > -} > - > /* > * Initialize the OMAP EHCI controller and PHY. > * Based on "drivers/usb/host/ehci-omap.c" from Linux 3.1 > * See there for additional Copyrights. > */ > -int omap_ehci_hcd_init(int index, struct omap_usbhs_board_data > *usbhs_pdata) > +static int omap_ehci_hcd_init(int index, struct omap_usbhs_board_data > *usbhs_pdata) > { > int ret; > unsigned int i, reg = 0, rev = 0; > -- > 2.32.0 > > > > ------------------------------ > > Message: 6 > Date: Sat, 12 Feb 2022 17:02:00 +0200 > From: Andy Shevchenko <andy.shevchenko(a)gmail.com> > To: Andy Shevchenko <andriy.shevchenko(a)intel.com> > Cc: Tom Rini <trini(a)konsulko.com>, Simon Glass <sjg(a)chromium.org>, Bin > Meng <bmeng.cn(a)gmail.com>, U-Boot Mailing List > <u-boot(a)lists.denx.de>, u-boot-custodians(a)lists.denx.de, > u-boot-board-maintainers(a)lists.denx.de > Subject: Re: [ANN] U-Boot v2022.04-rc1 released > Message-ID: > < > CAHp75VfgWnGTjOUsJ05DfMU0qFQtrwr9oBQCBC9TLi8h3LHN+g(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On Fri, Feb 11, 2022 at 9:15 PM Andy Shevchenko > <andy.shevchenko(a)gmail.com> wrote: > > On Fri, Feb 11, 2022 at 8:46 PM Andy Shevchenko > > <andy.shevchenko(a)gmail.com> wrote: > > > On Fri, Feb 11, 2022 at 8:31 PM Andy Shevchenko > > > <andriy.shevchenko(a)intel.com> wrote: > > > > On Mon, Jan 31, 2022 at 05:59:30PM -0500, Tom Rini wrote: > > ... > > > > git bisect bad 379d3c1fd6aa490b1ad5697525cfc89b615cf25a > > > # first bad commit: [379d3c1fd6aa490b1ad5697525cfc89b615cf25a] x86: > > > Move FACP table into separate functions > > > u-boot((379d3c1fd6aa...)|BISECTING)$ > > > > For the record, these two > > acpi: Move MCFG implementation to common lib > > arch: x86: lib: acpi_table: Fix MCFG entries > > > > do not help. > > > > > Irony is that I have reviewed it, but that time I was busy and > couldn't test. > > > > > > > Simon, can you prioritize setting up Edison to make it available for > tests? > > > > So, I'm open to testing any other suggestions. > > Meanwhile I will try to revert and if it works and no other solution > comes, I will send it out. > > -- > With Best Regards, > Andy Shevchenko > > > ------------------------------ > > Message: 7 > Date: Sat, 12 Feb 2022 17:58:29 +0100 > From: Michal Simek <monstr(a)monstr.eu> > To: Tom Rini <trini(a)konsulko.com>, u-boot(a)lists.denx.de, Simon Glass > <sjg(a)chromium.org> > Cc: u-boot-custodians(a)lists.denx.de, > u-boot-board-maintainers(a)lists.denx.de, Michal Simek > <michal.simek(a)xilinx.com> > Subject: Re: [ANN] U-Boot v2022.04-rc1 released > Message-ID: <b7383793-f671-0766-1309-14b75f031ac0(a)monstr.eu> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Hi, > > On 1/31/22 23:59, Tom Rini wrote: > > Hey all, > > > > It's release day and so here's v2022.04-rc1. While there's much in here > > that needed to come in, there's a few big things outstanding, including > > but not limited to i.MX and layerscape syncs and further sunxi changes. > > > > In terms of a changelog, > > git log --merges v2022.01..v2022.04-rc1 > > contains what I've pulled but as always, better PR messages and tags > > will provide better results here. > > > > So we're now looking at regular releases every other Monday, and with > > final release on April 4th, 2022. Thanks all! > > > > I also found that this patch break ZynqMP boards. I didn't have a time to > dig > into it more. Just did a bisect to find out what's going on. > 985503439762 ("fdt: Don't call board_fdt_blob_setup() without OF_BOARD") > > Thanks, > Michal > > -- > Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 > w: www.monstr.eu p: +42-0-721842854 > Maintainer of Linux kernel - Xilinx Microblaze > Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs > U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs > > > > ------------------------------ > > Message: 8 > Date: Sat, 12 Feb 2022 12:55:24 -0600 > From: "Alex G." <mr.nuke.me(a)gmail.com> > To: Andrew Jeffery <andrew(a)aj.id.au>, u-boot(a)lists.denx.de > Cc: sjg(a)chromium.org, chiawei_wang(a)aspeedtech.com, joel(a)jms.id.au, > openbmc(a)lists.ozlabs.org > Subject: Re: [PATCH] image: Control FIT signature verification at > runtime > Message-ID: <97430094-7d2a-432b-a121-96812fac87f9(a)gmail.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 1/30/22 21:41, Andrew Jeffery wrote: > > Some platform designs include support for disabling secure-boot via a > > jumper on the board. Sometimes this control can be separate from the > > mechanism enabling the root-of-trust for the platform. Add support for > > this latter scenario by allowing boards to implement > > board_fit_image_require_verfied(), which is then invoked in the usual > > FIT verification paths. > > > > Signed-off-by: Andrew Jeffery <andrew(a)aj.id.au> > > --- > > Hi, > > > > This patch is extracted from and motivated by a series adding run-time > > control of FIT signature verification to u-boot in OpenBMC: > > > > https://lore.kernel.org/openbmc/20220131012538.73021-1-andrew@aj.id.au/ > > > > Unfortunately the OpenBMC u-boot tree is quite a way behind on tracking > > upstream and contains a bunch of out-of-tree work as well. As such I'm > > looking to upstream the couple of changes that make sense against > > master. > > I don't understand the practical use of a mechanism to disable security > if secure boot was enabled in the first place. Sure it can be > technically done, but why is this not a bad idea? > > > Please take a look! > > > > Andrew > > > > boot/Kconfig | 8 ++++++++ > > boot/image-fit.c | 21 +++++++++++++++++---- > > include/image.h | 9 +++++++++ > > 3 files changed, 34 insertions(+), 4 deletions(-) > > > > diff --git a/boot/Kconfig b/boot/Kconfig > > index c8d5906cd304..ec413151fd5a 100644 > > --- a/boot/Kconfig > > +++ b/boot/Kconfig > > @@ -78,6 +78,14 @@ config FIT_SIGNATURE > > format support in this case, enable it using > > CONFIG_LEGACY_IMAGE_FORMAT. > > > > +if FIT_SIGNATURE > > +config FIT_RUNTIME_SIGNATURE > > + bool "Control verification of FIT uImages at runtime" > > + help > > + This option allows board support to disable verification of > > + signatures at runtime, for example through the state of a GPIO. > > The commit message does a much nicer job explaining this option, even > though it is this kconfig help text that almost all users will ever see. > > > +endif # FIT_SIGNATURE > > + > > config FIT_SIGNATURE_MAX_SIZE > > hex "Max size of signed FIT structures" > > depends on FIT_SIGNATURE > > diff --git a/boot/image-fit.c b/boot/image-fit.c > > index f01cafe4e277..919dbfa4ee1d 100644 > > --- a/boot/image-fit.c > > +++ b/boot/image-fit.c > > @@ -1308,6 +1308,14 @@ static int fit_image_check_hash(const void *fit, > int noffset, const void *data, > > return 0; > > } > > > > +#ifndef __weak > > +#define __weak > > +#endif > > What? > > > +__weak int board_fit_image_require_verified(void) > > +{ > > + return 1; > > +} > > + > > I caution against having any platform security related functionality as > a weak function. Did I get the right function, or something else with > the same name was compiled that returns 0 and silently disables security > in my platform? > > I think a weak function in this context is a source of confusion and > future bugs. You could instead require the symbol to be defined if and > only if the appropriate kconfig is selected. Symbol not defined -> > compiler error. Symbol defined twice -> compiler error. Solves the > issues in the preceding paragraph. > > [snip] > > > diff --git a/include/image.h b/include/image.h > > index 97e5f2eb24d6..98900c2e839b 100644 > > --- a/include/image.h > > +++ b/include/image.h > > @@ -1173,6 +1173,15 @@ int calculate_hash(const void *data, int > data_len, const char *algo, > > # define FIT_IMAGE_ENABLE_VERIFY CONFIG_IS_ENABLED(FIT_SIGNATURE) > > #endif > > > > +/* > > + * Further, allow run-time control of verification, e.g. via a jumper > > + */ > > +#if defined(CONFIG_FIT_RUNTIME_SIGNATURE) > > +# define fit_image_require_verified() > board_fit_image_require_verified() > > +#else > > +# define fit_image_require_verified() FIT_IMAGE_ENABLE_VERIFY > > +#endif > > + > > image.h is also used for host code. When only changing target code > behavior, there should be a very good reason to modify common code. I'm > not convinced that threshold has been met. > > My second concern here is subjective: I don't like functions defined as > macros, further depending on config selections. It makes many code > parsers and IDEs poop their pantaloons. It makes u-boot harder to work > with as a result. I suggest finding a way to turn this into a static > inline. > > Alex > > > ------------------------------ > > Message: 9 > Date: Sat, 12 Feb 2022 20:27:17 +0100 > From: Michael Nazzareno Trimarchi <michael(a)amarulasolutions.com> > To: Tim Harvey <tharvey(a)gateworks.com> > Cc: Adam Ford <aford173(a)gmail.com>, Fabio Estevam > <festevam(a)gmail.com>, dl-uboot-imx <uboot-imx(a)nxp.com>, > U-Boot-Denx > <u-boot(a)lists.denx.de>, Stefano Babic <sbabic(a)denx.de> > Subject: Re: Problem IMX8MN booting legacy kernel and mipi display > Message-ID: > <CAOf5uwkKG6mc0ek+H5vLn= > KwWU0gghgDYGjV0beMJ1+8dfL04Q(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hi Tim > > You are using the imx8mm. I have problems on imx8mn. It's like some > part is not implemented. Time to time power domain timeout if I > enabled > mipi pipeline > > Michael > > On Wed, Feb 2, 2022 at 4:54 PM Tim Harvey <tharvey(a)gateworks.com> wrote: > > > > On Wed, Feb 2, 2022 at 5:04 AM Michael Nazzareno Trimarchi > > <michael(a)amarulasolutions.com> wrote: > > > > > > Hi Adam > > > > > > On Wed, Feb 2, 2022 at 2:02 PM Adam Ford <aford173(a)gmail.com> wrote: > > > > > > > > On Wed, Feb 2, 2022 at 6:24 AM Michael Nazzareno Trimarchi > > > > <michael(a)amarulasolutions.com> wrote: > > > > > > > > > > Hi all > > > > > > > > > > I have now able to pack those combination and all of them look ok > > > > > > > > > > - mainline uboot > > > > > - optee 3.15.0 > > > > > - atf 2.5 > > > > > - mainline kernel > > > > > > > > > > - mainline uboot > > > > > - optee 3.15.0 > > > > > - imx-atf rel_imx_5.4.70_2.3.2 > > > > > - Linux rel_imx_5.4.70_2.3.2 > > > > > > > > > > I have a setup where I can test some peripherals. I can run an > optee > > > > > test on both combinations > > > > > The big issue I have it's the DSIM display it's not working and > > > > > crashes the kernel using the rel_imx_5.4.70_2.3.2 nxp version. The > > > > > mipi > > > > > randomly deadlock the booting. If I don't register the mipi part > it's > > > > > ok. Can someone have an idea? > > > > > > > > Are you using the Linux rel_imx_5.4.70_2.3.2 with imx-atf > rel_imx_5.4.70_2.3.2? > > > > > > > > The NXP kernel expects the NXP ATF code. The power-domain drivers in > > > > the NXP branch make secure calls to ATF which enable/disable the > > > > power-domains which control a bunch of peripherals like DSI, CSI, USB > > > > and GPU. If you're using the mainline ATF, I don't believe it > > > > contains the power-domain controllers, so when the Linux power-domain > > > > drivers make the secure calls, it's likely the power-domains won't > > > > change. > > > > > > - mainline uboot > > > - optee 3.15.0 > > > - imx-atf rel_imx_5.4.70_2.3.2 > > > - Linux rel_imx_5.4.70_2.3.2 > > > > > > I have tried even to not load optee in the image but still the same > > > > > > Michael > > > > > > > > adam > > > > > > > > > > All of them can be test using a buildroot setup > > > > > > > > > > Michael > > > > > > > Michael, > > > > I have not bothered with NXP's kernel, but I do have DSIM working on > > 5.15 with a set of patches here > > https://github.com/Gateworks/linux-venice if it is helpful. I've been > > using this with a mainline U-Boot, imx-atf lf_v2.4. > > > > Tim > > > > -- > Michael Nazzareno Trimarchi > Co-Founder & Chief Executive Officer > M. +39 347 913 2170 > michael(a)amarulasolutions.com > __________________________________ > > Amarula Solutions BV > Joop Geesinkweg 125, 1114 AB, Amsterdam, NL > T. +31 (0)85 111 9172 > info(a)amarulasolutions.com > www.amarulasolutions.com > > > ------------------------------ > > Message: 10 > Date: Sun, 13 Feb 2022 01:04:33 +0100 > From: Pali Roh?r <pali(a)kernel.org> > To: Stefan Roese <sr(a)denx.de> > Cc: Marek Beh?n <marek.behun(a)nic.cz>, Tony Dinh <mibodhi(a)gmail.com>, > u-boot(a)lists.denx.de > Subject: [PATCH] tools: kwbimage: Fix dumping DATA registers for v0 > images > Message-ID: <20220213000433.16131-1-pali(a)kernel.org> > Content-Type: text/plain; charset=UTF-8 > > End of DATA register section is indicated by zero value in both raddr and > rdata. > > So do not stop dumping registers with non-zero address and zero value. > And also print end of DATA registers section. > > Fixes: 1a8e6b63e24f ("tools: kwbimage: Dump kwbimage config file on '-p > -1' option") > Signed-off-by: Pali Roh?r <pali(a)kernel.org> > Reported-by: Tony Dinh <mibodhi(a)gmail.com> > Tested-by: Tony Dinh <mibodhi(a)gmail.com> > --- > tools/kwbimage.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/tools/kwbimage.c b/tools/kwbimage.c > index 9b63ce80ff4e..99d38cd1cfb2 100644 > --- a/tools/kwbimage.c > +++ b/tools/kwbimage.c > @@ -2226,11 +2226,13 @@ static int kwbimage_generate_config(void *ptr, > struct image_tool_params *params) > ehdr0 = (struct ext_hdr_v0 *)(mhdr0 + 1); > if (ehdr0->offset) { > for (regdata = (struct ext_hdr_v0_reg *)((uint8_t > *)ptr + ehdr0->offset); > - (uint8_t *)regdata < (uint8_t *)ptr + > header_size && regdata->raddr && > - regdata->rdata; > + (uint8_t *)regdata < (uint8_t *)ptr + > header_size && > + (regdata->raddr || regdata->rdata); > regdata++) > fprintf(f, "DATA 0x%08x 0x%08x\n", > le32_to_cpu(regdata->raddr), > le32_to_cpu(regdata->rdata)); > + if ((uint8_t *)regdata != (uint8_t *)ptr + > ehdr0->offset) > + fprintf(f, "DATA 0x0 0x0\n"); > } > } > > -- > 2.20.1 > > > > ------------------------------ > > Message: 11 > Date: Sun, 13 Feb 2022 01:09:46 +0100 > From: Pali Roh?r <pali(a)kernel.org> > To: Simon Glass <sjg(a)chromium.org>, Jan Kiszka > <jan.kiszka(a)siemens.com>, Heinrich Schuchardt <xypron.glpk(a)gmx.de> > Cc: u-boot(a)lists.denx.de > Subject: [PATCH] tools: mkimage/dumpimage: Allow to use -l with -T > Message-ID: <20220213000946.16236-1-pali(a)kernel.org> > Content-Type: text/plain; charset=UTF-8 > > Currently -l option for mkimage and dumpimage ignores option -T and always > tries to autodetect image type. > > With this change it is possible to tell mkimage and dumpimage to parse > image file as specific type (and not random autodetected type). This allows > to use mkimage -l or dumpimage -l as tool for validating image. > > params.type for -l option is now by default initialized to zero > (IH_TYPE_INVALID) instead of IH_TYPE_KERNEL. imagetool_get_type() for > IH_TYPE_INVALID returns NULL, which is assigned to tparams. mkimage and > dumpimage code is extended to handle tparams with NULL for -l option. And > imagetool_verify_print_header() is extended to do validation via tparams if > is not NULL. > > Signed-off-by: Pali Roh?r <pali(a)kernel.org> > --- > doc/mkimage.1 | 10 ++++++++-- > tools/dumpimage.c | 17 ++++++++--------- > tools/imagetool.c | 11 ++++++++++- > tools/imagetool.h | 22 ++++------------------ > tools/mkimage.c | 36 ++++++++++++++---------------------- > 5 files changed, 44 insertions(+), 52 deletions(-) > > diff --git a/doc/mkimage.1 b/doc/mkimage.1 > index fc84cca066b0..287006279f71 100644 > --- a/doc/mkimage.1 > +++ b/doc/mkimage.1 > @@ -1,10 +1,10 @@ > -.TH MKIMAGE 1 "2010-05-16" > +.TH MKIMAGE 1 "2022-02-07" > > .SH NAME > mkimage \- Generate image for U-Boot > .SH SYNOPSIS > .B mkimage > -.RB "\-l [" "uimage file name" "]" > +.RB [ \-T " \fItype\fP] " \-l " [\fIuimage file name\fP]" > > .B mkimage > .RB [\fIoptions\fP] " \-f [" "image tree source file" "]" " [" "uimage > file name" "]" > @@ -47,6 +47,12 @@ supports verified boot. > .BI "\-l [" "uimage file name" "]" > mkimage lists the information contained in the header of an existing > U-Boot image. > > +.TP > +.BI "\-T [" "image type" "]" > +Parse image file as type. > +Pass \-h as the image to see the list of supported image type. > +Without this option image type is autodetected. > + > .P > .B Create old legacy image: > > diff --git a/tools/dumpimage.c b/tools/dumpimage.c > index e5481435a764..4791dd0dfe18 100644 > --- a/tools/dumpimage.c > +++ b/tools/dumpimage.c > @@ -12,9 +12,7 @@ > static void usage(void); > > /* parameters initialized by core will be used by the image type code */ > -static struct image_tool_params params = { > - .type = IH_TYPE_KERNEL, > -}; > +static struct image_tool_params params; > > /* > * dumpimage_extract_subimage - > @@ -110,7 +108,7 @@ int main(int argc, char **argv) > } > } > > - if (argc < 2) > + if (argc < 2 || (params.iflag && params.lflag)) > usage(); > > if (optind >= argc) { > @@ -122,7 +120,7 @@ int main(int argc, char **argv) > > /* set tparams as per input type_id */ > tparams = imagetool_get_type(params.type); > - if (tparams == NULL) { > + if (!params.lflag && tparams == NULL) { > fprintf(stderr, "%s: unsupported type: %s\n", > params.cmdname, genimg_get_type_name(params.type)); > exit(EXIT_FAILURE); > @@ -132,7 +130,7 @@ int main(int argc, char **argv) > * check the passed arguments parameters meets the requirements > * as per image type to be generated/listed > */ > - if (tparams->check_params) { > + if (tparams && tparams->check_params) { > if (tparams->check_params(&params)) { > fprintf(stderr, "%s: Parameter check failed\n", > params.cmdname); > @@ -159,7 +157,7 @@ int main(int argc, char **argv) > exit(EXIT_FAILURE); > } > > - if ((uint32_t)sbuf.st_size < tparams->header_size) { > + if (tparams && (uint32_t)sbuf.st_size < tparams->header_size) { > fprintf(stderr, "%s: Bad size: \"%s\" is not valid > image\n", > params.cmdname, params.imagefile); > exit(EXIT_FAILURE); > @@ -203,8 +201,9 @@ int main(int argc, char **argv) > > static void usage(void) > { > - fprintf(stderr, "Usage: %s -l image\n" > - " -l ==> list image header information\n", > + fprintf(stderr, "Usage: %s [-T type] -l image\n" > + " -l ==> list image header information\n" > + " -T ==> parse image file as 'type'\n", > params.cmdname); > fprintf(stderr, > " %s [-T type] [-p position] [-o outfile] image\n" > diff --git a/tools/imagetool.c b/tools/imagetool.c > index ba1f64aa377a..5ad6d7413fec 100644 > --- a/tools/imagetool.c > +++ b/tools/imagetool.c > @@ -26,6 +26,12 @@ struct image_type_params *imagetool_get_type(int type) > return NULL; > } > > +static int imagetool_verify_print_header_by_type( > + void *ptr, > + struct stat *sbuf, > + struct image_type_params *tparams, > + struct image_tool_params *params); > + > int imagetool_verify_print_header( > void *ptr, > struct stat *sbuf, > @@ -39,6 +45,9 @@ int imagetool_verify_print_header( > struct image_type_params **start = __start_image_type; > struct image_type_params **end = __stop_image_type; > > + if (tparams) > + return imagetool_verify_print_header_by_type(ptr, sbuf, > tparams, params); > + > for (curr = start; curr != end; curr++) { > if ((*curr)->verify_header) { > retval = (*curr)->verify_header((unsigned char > *)ptr, > @@ -65,7 +74,7 @@ int imagetool_verify_print_header( > return retval; > } > > -int imagetool_verify_print_header_by_type( > +static int imagetool_verify_print_header_by_type( > void *ptr, > struct stat *sbuf, > struct image_type_params *tparams, > diff --git a/tools/imagetool.h b/tools/imagetool.h > index c3f80fc64e84..5169b0245dad 100644 > --- a/tools/imagetool.h > +++ b/tools/imagetool.h > @@ -178,33 +178,19 @@ struct image_type_params *imagetool_get_type(int > type); > /* > * imagetool_verify_print_header() - verifies the image header > * > - * Scan registered image types and verify the image_header for each > - * supported image type. If verification is successful, this prints > - * the respective header. > - * > - * Return: 0 on success, negative if input image format does not match > with > - * any of supported image types > - */ > -int imagetool_verify_print_header( > - void *ptr, > - struct stat *sbuf, > - struct image_type_params *tparams, > - struct image_tool_params *params); > - > -/* > - * imagetool_verify_print_header_by_type() - verifies the image header > - * > * Verify the image_header for the image type given by tparams. > + * If tparams is NULL then scan registered image types and verify the > + * image_header for each supported image type. > * If verification is successful, this prints the respective header. > * @ptr: pointer the the image header > * @sbuf: stat information about the file pointed to by ptr > - * @tparams: image type parameters > + * @tparams: image type parameters or NULL > * @params: mkimage parameters > * > * Return: 0 on success, negative if input image format does not match > with > * the given image type > */ > -int imagetool_verify_print_header_by_type( > +int imagetool_verify_print_header( > void *ptr, > struct stat *sbuf, > struct image_type_params *tparams, > diff --git a/tools/mkimage.c b/tools/mkimage.c > index f8a9899a51f6..d24b3bc002bf 100644 > --- a/tools/mkimage.c > +++ b/tools/mkimage.c > @@ -82,8 +82,9 @@ static int show_valid_options(enum ih_category category) > static void usage(const char *msg) > { > fprintf(stderr, "Error: %s\n", msg); > - fprintf(stderr, "Usage: %s -l image\n" > - " -l ==> list image header > information\n", > + fprintf(stderr, "Usage: %s [-T type] -l image\n" > + " -l ==> list image header information\n" > + " -T ==> parse image file as 'type'\n", > params.cmdname); > fprintf(stderr, > " %s [-x] -A arch -O os -T type -C comp -a addr -e > ep -n name -d data_file[:data_file...] image\n" > @@ -329,7 +330,7 @@ static void process_args(int argc, char **argv) > params.datafile = datafile; > else if (!params.datafile) > usage("Missing data file for auto-FIT (use -d)"); > - } else if (type != IH_TYPE_INVALID) { > + } else if (params.lflag || type != IH_TYPE_INVALID) { > if (type == IH_TYPE_SCRIPT && !params.datafile) > usage("Missing data file for script (use -d)"); > params.type = type; > @@ -396,7 +397,7 @@ int main(int argc, char **argv) > > /* set tparams as per input type_id */ > tparams = imagetool_get_type(params.type); > - if (tparams == NULL) { > + if (tparams == NULL && !params.lflag) { > fprintf (stderr, "%s: unsupported type %s\n", > params.cmdname, genimg_get_type_name(params.type)); > exit (EXIT_FAILURE); > @@ -406,14 +407,14 @@ int main(int argc, char **argv) > * check the passed arguments parameters meets the requirements > * as per image type to be generated/listed > */ > - if (tparams->check_params) > + if (tparams && tparams->check_params) > if (tparams->check_params (&params)) > usage("Bad parameters for image type"); > > if (!params.eflag) { > params.ep = params.addr; > /* If XIP, entry point must be after the U-Boot header */ > - if (params.xflag) > + if (params.xflag && tparams) > params.ep += tparams->header_size; > } > > @@ -474,7 +475,7 @@ int main(int argc, char **argv) > params.cmdname, params.imagefile); > exit (EXIT_FAILURE); > #endif > - } else if (sbuf.st_size < (off_t)tparams->header_size) { > + } else if (tparams && sbuf.st_size < > (off_t)tparams->header_size) { > fprintf (stderr, > "%s: Bad size: \"%s\" is not valid image: > size %llu < %u\n", > params.cmdname, params.imagefile, > @@ -493,21 +494,12 @@ int main(int argc, char **argv) > exit (EXIT_FAILURE); > } > > - if (params.fflag) { > - /* > - * Verifies the header format based on the > expected header for image > - * type in tparams > - */ > - retval = > imagetool_verify_print_header_by_type(ptr, &sbuf, > - tparams, &params); > - } else { > - /** > - * When listing the image, we are not given the > image type. Simply check all > - * image types to find one that matches our header > - */ > - retval = imagetool_verify_print_header(ptr, &sbuf, > - tparams, &params); > - } > + /* > + * Verifies the header format based on the expected header > for image > + * type in tparams. If tparams is NULL simply check all > image types > + * to find one that matches our header. > + */ > + retval = imagetool_verify_print_header(ptr, &sbuf, > tparams, &params); > > (void) munmap((void *)ptr, sbuf.st_size); > (void) close (ifd); > -- > 2.20.1 > > > > ------------------------------ > > Message: 12 > Date: Sun, 13 Feb 2022 10:09:19 +0200 > From: Ovidiu Panait <ovidiu.panait(a)windriver.com> > To: u-boot(a)lists.denx.de > Cc: Ovidiu Panait <ovidiu.panait(a)windriver.com>, Michal Simek > <monstr(a)monstr.eu> > Subject: [PATCH 1/7] microblaze: exception: move privileged > instruction exception out of v5 ifdef > Message-ID: <20220213080925.1548411-1-ovidiu.panait(a)windriver.com> > Content-Type: text/plain > > The privileged instruction exception seems to have been introduced in > microblaze v7.00 along with MMU support, so having it wrapped in > MICROBLAZE_v5 ifdefs seems incorrect. Move it out of the ifdef, since all > recent microblaze versions support it. > > Signed-off-by: Ovidiu Panait <ovidiu.panait(a)windriver.com> > --- > > arch/microblaze/cpu/exception.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/microblaze/cpu/exception.c > b/arch/microblaze/cpu/exception.c > index e9476abedb..f60f1fc693 100644 > --- a/arch/microblaze/cpu/exception.c > +++ b/arch/microblaze/cpu/exception.c > @@ -37,10 +37,10 @@ void _hw_exception_handler (void) > case 0x5: > puts("Divide by zero exception\n"); > break; > -#ifdef MICROBLAZE_V5 > case 0x7: > puts("Priviledged or stack protection violation > exception\n"); > break; > +#ifdef MICROBLAZE_V5 > case 0x1000: > puts("Exception in delay slot\n"); > break; > -- > 2.25.1 > > > > ------------------------------ > > Message: 13 > Date: Sun, 13 Feb 2022 10:09:23 +0200 > From: Ovidiu Panait <ovidiu.panait(a)windriver.com> > To: u-boot(a)lists.denx.de > Cc: Ovidiu Panait <ovidiu.panait(a)windriver.com>, Michal Simek > <monstr(a)monstr.eu> > Subject: [PATCH 5/7] microblaze: exception: move unaligned access > printfs inside switch case > Message-ID: <20220213080925.1548411-5-ovidiu.panait(a)windriver.com> > Content-Type: text/plain > > The unaligned access messages are only valid in the case of an unaligned > data access exception. Do not print them for other types of hw exceptions. > > Signed-off-by: Ovidiu Panait <ovidiu.panait(a)windriver.com> > --- > > arch/microblaze/cpu/exception.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/arch/microblaze/cpu/exception.c > b/arch/microblaze/cpu/exception.c > index f79e465e1f..d37f04364a 100644 > --- a/arch/microblaze/cpu/exception.c > +++ b/arch/microblaze/cpu/exception.c > @@ -35,6 +35,10 @@ void _hw_exception_handler (void) > switch (state & 0x1f) { /* mask on exception cause */ > case 0x1: > puts("Unaligned data access exception\n"); > + > + printf("Unaligned %sword access\n", ((state & 0x800) ? "" > : "half")); > + printf("Unaligned %s access\n", ((state & 0x400) ? "store" > : "load")); > + printf("Register R%x\n", (state & 0x3E) >> 5); > break; > case 0x2: > puts("Illegal op-code exception\n"); > @@ -57,9 +61,6 @@ void _hw_exception_handler (void) > } > > printf("Return address from exception 0x%x\n", address); > - printf("Unaligned %sword access\n", ((state & 0x800) ? "" : > "half")); > - printf("Unaligned %s access\n", ((state & 0x400) ? "store" : > "load")); > - printf("Register R%x\n", (state & 0x3E) >> 5); > hang(); > } > > -- > 2.25.1 > > > > ------------------------------ > > Message: 14 > Date: Sun, 13 Feb 2022 10:09:21 +0200 > From: Ovidiu Panait <ovidiu.panait(a)windriver.com> > To: u-boot(a)lists.denx.de > Cc: Ovidiu Panait <ovidiu.panait(a)windriver.com>, Michal Simek > <monstr(a)monstr.eu> > Subject: [PATCH 3/7] microblaze: exception: fix delay slot exception > handling > Message-ID: <20220213080925.1548411-3-ovidiu.panait(a)windriver.com> > Content-Type: text/plain > > The switch statement in _hw_exception_handler() only covers the > rightmost 5 bits that encode the exception cause: > switch (state & 0x1f) > { > ... > } > > For this reason, the "0x1000" case will never be reached, because the 13th > bit was zeroed out. To fix this, move delay slot exception handling before > the switch statement (delay slot (DS) bit in Exception Status Register is > independent of the exception cause (EC)). > > Signed-off-by: Ovidiu Panait <ovidiu.panait(a)windriver.com> > --- > > arch/microblaze/cpu/exception.c | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/arch/microblaze/cpu/exception.c > b/arch/microblaze/cpu/exception.c > index 5601dde5b4..64d5fe4a80 100644 > --- a/arch/microblaze/cpu/exception.c > +++ b/arch/microblaze/cpu/exception.c > @@ -21,6 +21,11 @@ void _hw_exception_handler (void) > printf("Hardware exception at 0x%x address\n", address); > R17(address); > printf("Return address from exception 0x%x\n", address); > + > + if (CONFIG_IS_ENABLED(XILINX_MICROBLAZE0_DELAY_SLOT_EXCEP) && > + (state & 0x1000)) > + puts("Exception in delay slot\n"); > + > switch (state & 0x1f) { /* mask on exception cause */ > case 0x1: > puts("Unaligned data access exception\n"); > @@ -40,11 +45,6 @@ void _hw_exception_handler (void) > case 0x7: > puts("Priviledged or stack protection violation > exception\n"); > break; > -#if CONFIG_IS_ENABLED(XILINX_MICROBLAZE0_DELAY_SLOT_EXCEP) > - case 0x1000: > - puts("Exception in delay slot\n"); > - break; > -#endif > default: > puts("Undefined cause\n"); > break; > -- > 2.25.1 > > > > ------------------------------ > > Message: 15 > Date: Sun, 13 Feb 2022 10:09:25 +0200 > From: Ovidiu Panait <ovidiu.panait(a)windriver.com> > To: u-boot(a)lists.denx.de > Cc: Ovidiu Panait <ovidiu.panait(a)windriver.com>, Michal Simek > <monstr(a)monstr.eu> > Subject: [PATCH 7/7] microblaze: exception: drop user exception > support > Message-ID: <20220213080925.1548411-7-ovidiu.panait(a)windriver.com> > Content-Type: text/plain > > A user exception is triggered by inserting a bralid/brki jump to > "C_BASE_VECTORS+0x8" in the software flow. Because u-boot microblaze code > does not deal with MMU-related features such as user-mode/privileged-mode > separation, there are no code sequences that call into the user exception > handler. > > It seems there is no real usecase for having user exception support in > u-boot, so drop the code that installs the nop handler. > > Signed-off-by: Ovidiu Panait <ovidiu.panait(a)windriver.com> > --- > > arch/microblaze/cpu/exception.c | 8 ----- > arch/microblaze/cpu/start.S | 40 ++----------------------- > board/xilinx/microblaze-generic/Kconfig | 9 ------ > 3 files changed, 3 insertions(+), 54 deletions(-) > > diff --git a/arch/microblaze/cpu/exception.c > b/arch/microblaze/cpu/exception.c > index d3640d3903..1f7c44d1f3 100644 > --- a/arch/microblaze/cpu/exception.c > +++ b/arch/microblaze/cpu/exception.c > @@ -63,11 +63,3 @@ void _hw_exception_handler (void) > printf("Return address from exception 0x%x\n", address); > hang(); > } > - > -#if CONFIG_IS_ENABLED(XILINX_MICROBLAZE0_USR_EXCEP) > -void _exception_handler (void) > -{ > - puts("User vector_exception\n"); > - hang(); > -} > -#endif > diff --git a/arch/microblaze/cpu/start.S b/arch/microblaze/cpu/start.S > index 645f7cb038..0ea0b78da9 100644 > --- a/arch/microblaze/cpu/start.S > +++ b/arch/microblaze/cpu/start.S > @@ -97,9 +97,9 @@ clear_bss: > * r5 - relocation offset (zero when setting up vectors before > * relocation, and gd->reloc_off when setting up vectors after > * relocation) > - * - the relocation offset is added to the _exception_handler, > - * _interrupt_handler and _hw_exception_handler symbols to reflect > the > - * post-relocation memory addresses > + * - the relocation offset is added to the _interrupt_handler and > + * _hw_exception_handler symbols to reflect the post-relocation > memory > + * addresses > * > * Reserve registers: > * r10: Stores little/big endian offset for vectors > @@ -149,40 +149,6 @@ __setup_exceptions: > rsubi r8, r10, 0x6 > sh r6, r4, r8 > > -#if CONFIG_IS_ENABLED(XILINX_MICROBLAZE0_USR_EXCEP) > - /* user_vector_exception */ > - swi r2, r4, 0x8 /* user vector exception - imm opcode */ > - swi r3, r4, 0xC /* user vector exception - brai opcode */ > - > - addik r6, r5, _exception_handler > - sw r6, r1, r0 > - /* > - * BIG ENDIAN memory map for user exception > - * 0x8: 0xB000XXXX > - * 0xC: 0xB808XXXX > - * > - * then it is necessary to count address for storing the most > significant > - * 16bits from _exception_handler address and copy it to > - * 0xa address. Big endian use offset in r10=0 that's why is it > just > - * 0xa address. The same is done for the least significant 16 bits > - * for 0xe address. > - * > - * LITTLE ENDIAN memory map for user exception > - * 0x8: 0xXXXX00B0 > - * 0xC: 0xXXXX08B8 > - * > - * Offset is for little endian setup to 0x2. rsubi instruction > decrease > - * address value to ensure that points to proper place which is > - * 0x8 for the most significant 16 bits and > - * 0xC for the least significant 16 bits > - */ > - lhu r7, r1, r10 > - rsubi r8, r10, 0xa > - sh r7, r4, r8 > - rsubi r8, r10, 0xe > - sh r6, r4, r8 > -#endif > - > /* interrupt_handler */ > swi r2, r4, 0x10 /* interrupt - imm opcode */ > swi r3, r4, 0x14 /* interrupt - brai opcode */ > diff --git a/board/xilinx/microblaze-generic/Kconfig > b/board/xilinx/microblaze-generic/Kconfig > index 117b476f3f..a0af2e9abd 100644 > --- a/board/xilinx/microblaze-generic/Kconfig > +++ b/board/xilinx/microblaze-generic/Kconfig > @@ -38,15 +38,6 @@ config XILINX_MICROBLAZE0_HW_VER > string "Core version number" > default "7.10.d" > > -config XILINX_MICROBLAZE0_USR_EXCEP > - bool "MicroBlaze user exception support" > - default y > - help > - Enable this option in order to install the user exception handler > - (_exception_handler routine from > arch/microblaze/cpu/exception.c) in > - the exception vector table. The user exception vector is located > at > - C_BASE_VECTORS + 0x8 address. > - > config XILINX_MICROBLAZE0_DELAY_SLOT_EXCEP > bool "MicroBlaze delay slot exception support" > default y > -- > 2.25.1 > > > > ------------------------------ > > Message: 16 > Date: Sun, 13 Feb 2022 10:09:24 +0200 > From: Ovidiu Panait <ovidiu.panait(a)windriver.com> > To: u-boot(a)lists.denx.de > Cc: Ovidiu Panait <ovidiu.panait(a)windriver.com>, Michal Simek > <monstr(a)monstr.eu> > Subject: [PATCH 6/7] microblaze: exception: fix unaligned data access > register mask > Message-ID: <20220213080925.1548411-6-ovidiu.panait(a)windriver.com> > Content-Type: text/plain > > The correct mask for getting the source/destination register from ESR in > the case of an unaligned access exception is 0x3E0. With this change, a > dummy unaligned store produces the expected info: > """ > >> swi r5, r0, 0x111 > > ... > Hardware exception at 0x111 address > Unaligned data access exception > Unaligned word access > Unaligned store access > Register R5 > Return address from exception 0x7f99dfc > ### ERROR ### Please RESET the board ### > """ > > Signed-off-by: Ovidiu Panait <ovidiu.panait(a)windriver.com> > --- > > arch/microblaze/cpu/exception.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/microblaze/cpu/exception.c > b/arch/microblaze/cpu/exception.c > index d37f04364a..d3640d3903 100644 > --- a/arch/microblaze/cpu/exception.c > +++ b/arch/microblaze/cpu/exception.c > @@ -38,7 +38,7 @@ void _hw_exception_handler (void) > > printf("Unaligned %sword access\n", ((state & 0x800) ? "" > : "half")); > printf("Unaligned %s access\n", ((state & 0x400) ? "store" > : "load")); > - printf("Register R%x\n", (state & 0x3E) >> 5); > + printf("Register R%x\n", (state & 0x3E0) >> 5); > break; > case 0x2: > puts("Illegal op-code exception\n"); > -- > 2.25.1 > > > > ------------------------------ > > Message: 17 > Date: Sun, 13 Feb 2022 10:09:20 +0200 > From: Ovidiu Panait <ovidiu.panait(a)windriver.com> > To: u-boot(a)lists.denx.de > Cc: Ovidiu Panait <ovidiu.panait(a)windriver.com>, Michal Simek > <monstr(a)monstr.eu> > Subject: [PATCH 2/7] microblaze: exception: migrate MICROBLAZE_V5 to > Kconfig > Message-ID: <20220213080925.1548411-2-ovidiu.panait(a)windriver.com> > Content-Type: text/plain > > Also, rename it to XILINX_MICROBLAZE0_DELAY_SLOT_EXCEP, since it only > covers delay slot exception support. > > Signed-off-by: Ovidiu Panait <ovidiu.panait(a)windriver.com> > --- > > arch/microblaze/cpu/exception.c | 2 +- > board/xilinx/microblaze-generic/Kconfig | 9 +++++++++ > include/configs/microblaze-generic.h | 3 --- > 3 files changed, 10 insertions(+), 4 deletions(-) > > diff --git a/arch/microblaze/cpu/exception.c > b/arch/microblaze/cpu/exception.c > index f60f1fc693..5601dde5b4 100644 > --- a/arch/microblaze/cpu/exception.c > +++ b/arch/microblaze/cpu/exception.c > @@ -40,7 +40,7 @@ void _hw_exception_handler (void) > case 0x7: > puts("Priviledged or stack protection violation > exception\n"); > break; > -#ifdef MICROBLAZE_V5 > +#if CONFIG_IS_ENABLED(XILINX_MICROBLAZE0_DELAY_SLOT_EXCEP) > case 0x1000: > puts("Exception in delay slot\n"); > break; > diff --git a/board/xilinx/microblaze-generic/Kconfig > b/board/xilinx/microblaze-generic/Kconfig > index e31257d335..117b476f3f 100644 > --- a/board/xilinx/microblaze-generic/Kconfig > +++ b/board/xilinx/microblaze-generic/Kconfig > @@ -47,6 +47,15 @@ config XILINX_MICROBLAZE0_USR_EXCEP > the exception vector table. The user exception vector is located > at > C_BASE_VECTORS + 0x8 address. > > +config XILINX_MICROBLAZE0_DELAY_SLOT_EXCEP > + bool "MicroBlaze delay slot exception support" > + default y > + help > + Enable this option if the MicroBlaze processor supports > exceptions > + caused by delay slot instructions (processor version >= v5.00). > When > + enabled, the hw exception handler will print a message indicating > + whether the exception was triggered by a delay slot instruction. > + > config XILINX_MICROBLAZE0_VECTOR_BASE_ADDR > hex "Location of MicroBlaze vectors" > default 0x0 > diff --git a/include/configs/microblaze-generic.h > b/include/configs/microblaze-generic.h > index ca749ed18a..fd5a9cf8b8 100644 > --- a/include/configs/microblaze-generic.h > +++ b/include/configs/microblaze-generic.h > @@ -11,9 +11,6 @@ > /* Microblaze is microblaze_0 */ > #define XILINX_FSL_NUMBER 3 > > -/* MicroBlaze CPU */ > -#define MICROBLAZE_V5 1 > - > #define CONFIG_SYS_BOOTM_LEN (64 * 1024 * 1024) > > /* uart */ > -- > 2.25.1 > > > > ------------------------------ > > Message: 18 > Date: Sun, 13 Feb 2022 10:09:22 +0200 > From: Ovidiu Panait <ovidiu.panait(a)windriver.com> > To: u-boot(a)lists.denx.de > Cc: Ovidiu Panait <ovidiu.panait(a)windriver.com>, Michal Simek > <monstr(a)monstr.eu> > Subject: [PATCH 4/7] microblaze: exception: fix return address for > delay slot exceptions > Message-ID: <20220213080925.1548411-4-ovidiu.panait(a)windriver.com> > Content-Type: text/plain > > According to the MicroBlaze reference manual (xilinx2021.2/ug984/page-37): > """ > If an exception is caused by an instruction in a delay slot (that is, > ESR[DS]=1), the exception handler should return execution to > the address stored in BTR instead of the normal exception return > address stored in R17. > """ > > Adjust the code to print the proper return address for delay slot > exceptions. > > Signed-off-by: Ovidiu Panait <ovidiu.panait(a)windriver.com> > --- > > arch/microblaze/cpu/exception.c | 12 ++++++++++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/arch/microblaze/cpu/exception.c > b/arch/microblaze/cpu/exception.c > index 64d5fe4a80..f79e465e1f 100644 > --- a/arch/microblaze/cpu/exception.c > +++ b/arch/microblaze/cpu/exception.c > @@ -20,11 +20,17 @@ void _hw_exception_handler (void) > MFS(state, resr); > printf("Hardware exception at 0x%x address\n", address); > R17(address); > - printf("Return address from exception 0x%x\n", address); > > if (CONFIG_IS_ENABLED(XILINX_MICROBLAZE0_DELAY_SLOT_EXCEP) && > - (state & 0x1000)) > + (state & 0x1000)) { > + /* > + * For exceptions in delay slots, the return address is > stored > + * in the Branch Target Register (BTR), rather than R17. > + */ > + MFS(address, rbtr); > + > puts("Exception in delay slot\n"); > + } > > switch (state & 0x1f) { /* mask on exception cause */ > case 0x1: > @@ -49,6 +55,8 @@ void _hw_exception_handler (void) > puts("Undefined cause\n"); > break; > } > + > + printf("Return address from exception 0x%x\n", address); > printf("Unaligned %sword access\n", ((state & 0x800) ? "" : > "half")); > printf("Unaligned %s access\n", ((state & 0x400) ? "store" : > "load")); > printf("Register R%x\n", (state & 0x3E) >> 5); > -- > 2.25.1 > > > > ------------------------------ > > Message: 19 > Date: Sun, 13 Feb 2022 09:58:10 +0100 > From: Heinrich Schuchardt <xypron.glpk(a)gmx.de> > To: Masami Hiramatsu <masami.hiramatsu(a)linaro.org>, > u-boot(a)lists.denx.de > Cc: Patrick Delaunay <patrick.delaunay(a)foss.st.com>, Patrice Chotard > <patrice.chotard(a)foss.st.com>, Alexander Graf <agraf(a)csgraf.de>, > AKASHI Takahiro <takahiro.akashi(a)linaro.org>, Simon Glass > <sjg(a)chromium.org>, Bin Meng <bmeng.cn(a)gmail.com>, Ilias > Apalodimas > <ilias.apalodimas(a)linaro.org>, Jose Marinho <jose.marinho(a)arm.com > >, > Grant Likely <grant.likely(a)arm.com>, Tom Rini <trini(a)konsulko.com > >, > Etienne Carriere <etienne.carriere(a)linaro.org>, Sughosh Ganu > <sughosh.ganu(a)linaro.org>, Paul Liu <paul.liu(a)linaro.org> > Subject: Re: [PATCH v4 1/2] efi_loader: use > efi_update_capsule_firmware() for capsule on disk > Message-ID: <cfd78afc-8b23-0dd7-98aa-4f9477a08c93(a)gmx.de> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 2/3/22 10:23, Masami Hiramatsu wrote: > > Since the efi_update_capsule() represents the UpdateCapsule() runtime > > service, it has to handle the capsule flags and update ESRT. However > > the capsule-on-disk doesn't need to care about such things. > > > > Thus, the capsule-on-disk should use the efi_capsule_update_firmware() > > directly instead of calling efi_update_capsule(). > > > > This means the roles of the efi_update_capsule() and capsule-on-disk > > are different. We have to keep the efi_update_capsule() for providing > > runtime service API at boot time. > > > > Suggested-by: AKASHI Takahiro <takahiro.akashi(a)linaro.org> > > Signed-off-by: Masami Hiramatsu <masami.hiramatsu(a)linaro.org> > > Reviewed-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> > > > ------------------------------ > > Message: 20 > Date: Sun, 13 Feb 2022 10:01:35 +0100 > From: Heinrich Schuchardt <xypron.glpk(a)gmx.de> > To: Masami Hiramatsu <masami.hiramatsu(a)linaro.org>, > u-boot(a)lists.denx.de > Cc: Patrick Delaunay <patrick.delaunay(a)foss.st.com>, Patrice Chotard > <patrice.chotard(a)foss.st.com>, Heinrich Schuchardt > <xypron.glpk(a)gmx.de>, Alexander Graf <agraf(a)csgraf.de>, AKASHI > Takahiro <takahiro.akashi(a)linaro.org>, Simon Glass < > sjg(a)chromium.org>, > Bin Meng <bmeng.cn(a)gmail.com>, Ilias Apalodimas > <ilias.apalodimas(a)linaro.org>, Jose Marinho <jose.marinho(a)arm.com > >, > Grant Likely <grant.likely(a)arm.com>, Tom Rini <trini(a)konsulko.com > >, > Etienne Carriere <etienne.carriere(a)linaro.org>, Sughosh Ganu > <sughosh.ganu(a)linaro.org>, Paul Liu <paul.liu(a)linaro.org> > Subject: Re: [PATCH v4 2/2] efi_loader: Reset system after > CapsuleUpdate on disk > Message-ID: <b69b5a40-14a2-6791-b63f-925b9b1645ff(a)gmx.de> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 2/3/22 10:23, Masami Hiramatsu wrote: > > Add a cold reset soon after processing capsule update on disk. > > This is required in UEFI specification 2.9 Section 8.5.5 > > "Delivery of Capsules via file on Mass Storage device" as; > > > > In all cases that a capsule is identified for processing the system > is > > restarted after capsule processing is completed. > > > > This also reports the result of each capsule update so that the user can > > notice that the capsule update has been succeeded or not from console > log. > > > > Signed-off-by: Masami Hiramatsu <masami.hiramatsu(a)linaro.org> > > Reviewed-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> > > > ------------------------------ > > Message: 21 > Date: Sun, 13 Feb 2022 10:58:17 +0100 > From: Heinrich Schuchardt <xypron.glpk(a)gmx.de> > To: Masahisa Kojima <masahisa.kojima(a)linaro.org> > Cc: Ilias Apalodimas <ilias.apalodimas(a)linaro.org>, Simon Glass > <sjg(a)chromium.org>, Takahiro Akashi <takahiro.akashi(a)linaro.org>, > Francois Ozog <francois.ozog(a)linaro.org>, Mark Kettenis > <mark.kettenis(a)xs4all.nl>, u-boot(a)lists.denx.de > Subject: Re: [PATCH 3/3] efi_loader: add menu-driven UEFI Boot > Variable maintenance > Message-ID: <9e88e71a-ea98-98ad-e0db-1686c2045d95(a)gmx.de> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 2/10/22 08:05, Masahisa Kojima wrote: > > This commit adds the menu-driven UEFI Boot Variable maintenance. > > User can add and delete the Boot#### variable, and update the > > BootOrder variable through menu operation. > > > > Signed-off-by: Masahisa Kojima <masahisa.kojima(a)linaro.org> > > --- > > lib/efi_loader/efi_bootmgr.c | 720 +++++++++++++++++++++++++++++++++++ > > 1 file changed, 720 insertions(+) > > > > diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c > > index 013d868f23..739140f742 100644 > > --- a/lib/efi_loader/efi_bootmgr.c > > +++ b/lib/efi_loader/efi_bootmgr.c > > @@ -32,6 +32,8 @@ static const struct efi_runtime_services *rs; > > Where is the Kconfig entry to disable this code? > > > */ > > > > #define EFI_BOOTMGR_MENU_ENTRY_NUM_MAX 1024 > > +#define EFI_BOOTMGR_FILE_PATH_MAX 512 > > +#define EFI_BOOTMGR_BOOT_NAME_MAX 64 > > > > typedef efi_status_t (*efi_bootmenu_entry_func)(void *data, bool > *exit); > > > > @@ -95,12 +97,49 @@ struct efi_bootmgr_boot_selection_data { > > > > static efi_status_t efi_bootmgr_process_boot_selected(void *data, bool > *exit); > > static efi_status_t efi_bootmgr_process_boot_selection(void *data, > bool *exit); > > +static efi_status_t efi_bootmgr_process_maintenance(void *data, bool > *exit); > > +static efi_status_t efi_bootmgr_process_add_boot_option(void *data, > bool *exit); > > +static efi_status_t efi_bootmgr_process_delete_boot_option(void *data, > bool *exit); > > +static efi_status_t efi_bootmgr_process_change_boot_order(void *data, > bool *exit); > > > > static struct efi_bootmgr_menu_item bootmgr_menu_items[] = { > > {u"Boot Manager", efi_bootmgr_process_boot_selection}, > > + {u"Boot Manager maintenance", efi_bootmgr_process_maintenance}, > > {u"Quit", NULL}, > > }; > > > > +static struct efi_bootmgr_menu_item maintenance_menu_items[] = { > > + {u"Add Boot Option", efi_bootmgr_process_add_boot_option}, > > + {u"Delete Boot Option", efi_bootmgr_process_delete_boot_option}, > > + {u"Change Boot Order", efi_bootmgr_process_change_boot_order}, > > + {u"Quit", NULL}, > > +}; > > + > > +struct efi_bootmgr_boot_option { > > + struct efi_simple_file_system_protocol *current_volume; > > + struct efi_device_path *dp_volume; > > + u16 *current_path; > > + u16 *boot_name; > > + bool file_selected; > > +}; > > + > > +static const struct efi_device_path END = { > > + .type = DEVICE_PATH_TYPE_END, > > + .sub_type = DEVICE_PATH_SUB_TYPE_END, > > + .length = sizeof(END), > > +}; > > + > > +struct efi_bootmgr_volume_entry_data { > > + struct efi_bootmgr_boot_option *bo; > > + struct efi_simple_file_system_protocol *v; > > + struct efi_device_path *dp; > > +}; > > + > > +struct efi_bootmgr_file_entry_data { > > + struct efi_bootmgr_boot_option *bo; > > + struct efi_file_info *f; > > +}; > > + > > static void efi_bootmgr_menu_print_entry(void *data) > > { > > struct efi_bootmgr_menu_entry *entry = data; > > @@ -558,6 +597,687 @@ static efi_status_t > efi_bootmgr_process_boot_selection(void *data, bool *exit) > > return ret; > > } > > > > +static efi_status_t efi_bootmgr_volume_selected(void *data, bool *exit) > > +{ > > + struct efi_bootmgr_volume_entry_data *info = data; > > + > > + *exit = true; > > + > > + if (info) { > > + info->bo->current_volume = info->v; > > + info->bo->dp_volume = info->dp; > > + } > > + > > + return EFI_SUCCESS; > > +} > > + > > +static efi_status_t efi_bootmgr_file_selected(void *data, bool *exit) > > +{ > > + struct efi_bootmgr_file_entry_data *info = data; > > + > > + *exit = true; > > + > > + if (!info) > > + return EFI_INVALID_PARAMETER; > > + > > + if (u16_strncmp(info->f->file_name, u".", 1) == 0 && > > + u16_strlen(info->f->file_name) == 1) { > > + /* stay current path */ > > + } else if (u16_strncmp(info->f->file_name, u"..", 2) == 0 && > > + u16_strlen(info->f->file_name) == 2) { > > + u32 i; > > + int len = u16_strlen(info->bo->current_path); > > + > > + for (i = len - 2; i > 0; i--) { > > + if (info->bo->current_path[i] == u'\\') > > + break; > > + } > > + > > + if (i == 0) > > + info->bo->current_path[0] = u'\0'; > > + else > > + info->bo->current_path[i + 1] = u'\0'; > > + } else { > > + size_t new_len; > > + > > + new_len = u16_strlen(info->bo->current_path) + > > + u16_strlen(info->f->file_name) + 1; > > + if (new_len >= EFI_BOOTMGR_FILE_PATH_MAX) { > > Why do we need such an arbitrary limitation? Please, allocate a buffer > of adequate size. > > > + /* TODO: show error notification to user */ > > + log_err("file path is too long\n"); > > + return EFI_INVALID_PARAMETER; > > + } > > + u16_strcat(info->bo->current_path, info->f->file_name); > > I would prefer to use a safe function here where the destination buffer > length is an argument. > > > > + if (info->f->attribute & EFI_FILE_DIRECTORY) { > > + if (new_len + 1 >= EFI_BOOTMGR_FILE_PATH_MAX) { > > Please, remove this duplicate test and fix the test above. > > > + log_err("file path is too long\n"); > > + return EFI_INVALID_PARAMETER; > > + } > > + u16_strcat(info->bo->current_path, u"\\"); > > + } else { > > + info->bo->file_selected = true; > > + } > > + } > > + return EFI_SUCCESS; > > +} > > + > > +static efi_status_t efi_bootmgr_select_volume(struct > efi_bootmgr_boot_option *bo) > > +{ > > + u16 *name; > > + u32 i; > > + efi_status_t ret; > > + efi_uintn_t count; > > + struct efi_device_path *device_path; > > + efi_handle_t *volume_handles = NULL; > > + struct efi_simple_file_system_protocol *v; > > + struct efi_device_path_to_text_protocol *text; > > + struct efi_bootmgr_menu_item *menu_item, *iter; > > + > > + ret = EFI_CALL(efi_locate_handle_buffer(BY_PROTOCOL, > &efi_system_partition_guid, > > We have too many EFI_CALLs. Factor out a function > efi_locate_handle_buffer_int() which you can call without EFI_CALL and > remove all of the existing EFI_CALLs. > > > + NULL, &count, > > + (efi_handle_t > **)&volume_handles)); > > + if (ret != EFI_SUCCESS) > > + return ret; > > What will you do if you get multiple results? > > > + > > + ret = > EFI_CALL(systab.boottime->locate_protocol(&efi_guid_device_path_to_text_protocol, > > + NULL, (void > **)&text)); > > This will give you a random instance of a device path and not the one > related to the ESP. You just called LocateHandleBuffer() for good > reason. Please, use efi_search_protocol(). > > > + if (ret != EFI_SUCCESS) > > + goto out1; > > + > > + menu_item = calloc(count + 1, sizeof(struct > efi_bootmgr_menu_item)); > > + if (!menu_item) { > > + ret = EFI_OUT_OF_RESOURCES; > > + goto out1; > > + } > > + > > + iter = menu_item; > > + for (i = 0; i < count; i++) { > > + struct efi_bootmgr_volume_entry_data *info; > > + > > + ret = > EFI_CALL(systab.boottime->open_protocol(volume_handles[i], > > + > &efi_simple_file_system_protocol_guid, > > + (void **)&v, efi_root, > NULL, > > + > EFI_OPEN_PROTOCOL_GET_PROTOCOL)); > > + if (ret != EFI_SUCCESS) > > + continue; > > + > > + ret = > EFI_CALL(systab.boottime->open_protocol(volume_handles[i], > > + &efi_guid_device_path, > > + (void **)&device_path, > efi_root, NULL, > > + > EFI_OPEN_PROTOCOL_GET_PROTOCOL)); > > + if (ret != EFI_SUCCESS) > > + continue; > > + > > + name = text->convert_device_path_to_text(device_path, > true, true); > > + if (!name) { > > + ret = EFI_OUT_OF_RESOURCES; > > + goto out2; > > + } > > + > > + info = calloc(1, sizeof(struct > efi_bootmgr_volume_entry_data)); > > + if (!info) { > > + ret = EFI_OUT_OF_RESOURCES; > > + goto out2; > > + } > > + > > + info->v = v; > > + info->dp = device_path; > > + info->bo = bo; > > + iter->title = name; > > + iter->func = efi_bootmgr_volume_selected; > > + iter->data = info; > > + iter++; > > + } > > + > > + iter->title = u"Quit"; > > + iter->func = NULL; > > + iter->data = NULL; > > + count += 1; > > + > > + ret = efi_bootmgr_process_common(menu_item, count, false); > > + > > +out2: > > + iter = menu_item; > > + for (i = 0; i < count - 1; i++) { > > + struct efi_bootmgr_volume_entry_data *p; > > + > > + p = (struct efi_bootmgr_volume_entry_data *)

2 1

[RFC PATCH v2 00/21] Modernize U-Boot shell
by Francis Laniel 18 Feb '22

18 Feb '22

Hi. First I hope you are fine and the same for your relatives. During 2021 summer, Sean Anderson wrote a contribution to add a new shell, based on LIL, to U-Boot [1][2]. While one of the goals of this contribution was to address the fact actual U-Boot shell, which is based on Busybox hush, is old there was a discussion about adding a new shell versus updating the actual one [3][4]. So, in this series, with Harald Seiler, we updated the actual U-Boot shell to reflect what is currently in Busybox source code. Basically, this contribution is about taking a snapshot of Busybox shell/hush.c file (as it exists in commit 37460f5da) and adapt it to suit U-Boot needs. This contribution was written to be as backward-compatible as possible to avoid breaking the existing. So, the 2021 hush flavor offers the same as the actual, that is to say: 1. Variable expansion. 2. Instruction lists (;, && and ||). 3. If, then and else. 4. Loops (for, while and until). No new features offered by Busybox hush were implemented (e.g. functions). In terms of testing, new unit tests were added to ut to ensure the new behavior is the same as the old one and it does not add regression. Nonetheless, if old behavior was buggy and fixed upstream, the fix is then added to U-Boot [5]. In sandbox, all of these tests pass smoothly: 2021> printenv board board=sandbox 2021> ut hush Running 20 hush tests ... Failures: 0 Thanks to the effort of Harald Seiler, I was successful booting a board: 2021> printenv board_rev board_rev=iMX8MP 2021> boot ... root@iMX8MPboard:~# fw_printenv board_rev board_rev=iMX8MP I marked this contribution as RFC to indeed collect your opinion. My goal is not to change suddenly actual shell to this one, we clearly need a transition period to think about it. I think it is better to see this contribution as a proof of concept which shows it is possible to update the actual shell. If you want to review it - your review will really be appreciated - here are some information regarding the commits: * commits marked as "test:" deal with unit tests. * commit "cli: Add Busybox upstream hush.c file." copies Busybox shell/hush.c into U-Boot tree, this explain why this commit contains around 12000 additions. * commit "cli: Port Busybox 2021 hush to U-Boot." modifies previously added file to permit us to use this as new shell. The really good idea of #include'ing Busybox code into a wrapper file to define some particular functions while minimizing modifications to upstream code comes from Harald Seiler. * Other commits focus on enabling features we need (e.g. if). Changes since v1: * Renamed cli_hush_2021_upstream.c to cli_hush_upstream.c. * Addressed reviews regarding variable expansion unit test. Francis Laniel (21): test: Add framework to test hush behavior test: hush: Test hush if/else test/py: hush_if_test: Remove the test file test: hush: Test hush variable expansion test: hush: Test hush commands list test: hush: Test hush loops. cli: Add Busybox upstream hush.c file cli: Port Busybox 2021 hush to U-Boot cli: Add choice for hush parser cli: Add HUSH_2021_PARSER to hush parser choice cli: Enables using hush 2021 parser as command line parser cli: hush_2021: Enable variables expansion for hush 2021 cli: hush_2021: Add functions to be called from run_command() cli: Modify run_command() to add hush 2021 as parser test: hush: Fix instructions list tests for hush 2021 test: hush: Fix variable expansion tests for hush 2021 cli: hush_2021: Enable using \< and \> as string compare operators cli: hush_2021: Enable if keyword test: hush: Fix if tests for hush 2021 cli: hush_2021: Enable loops test: hush: Fix loop tests for hush 2021 cmd/Kconfig | 22 + common/Makefile | 3 +- common/cli.c | 27 +- common/cli_hush_2021.c | 309 + common/cli_hush_upstream.c | 12791 +++++++++++++++++++++++++++ include/cli_hush.h | 8 + include/test/hush.h | 15 + include/test/suites.h | 1 + test/Makefile | 3 + test/cmd_ut.c | 6 + test/hush/Makefile | 10 + test/hush/cmd_ut_hush.c | 20 + test/hush/dollar.c | 226 + test/hush/if.c | 351 + test/hush/list.c | 127 + test/hush/loop.c | 84 + test/py/tests/test_hush_if_test.py | 184 - 17 files changed, 13999 insertions(+), 188 deletions(-) create mode 100644 common/cli_hush_2021.c create mode 100644 common/cli_hush_upstream.c create mode 100644 include/test/hush.h create mode 100644 test/hush/Makefile create mode 100644 test/hush/cmd_ut_hush.c create mode 100644 test/hush/dollar.c create mode 100644 test/hush/if.c create mode 100644 test/hush/list.c create mode 100644 test/hush/loop.c delete mode 100644 test/py/tests/test_hush_if_test.py Best regards and thank you in advance for your reviews. --- [1] https://lists.denx.de/pipermail/u-boot/2021-July/453347.html [2] https://runtimeterror.com/tech/lil/ [3] https://lists.denx.de/pipermail/u-boot/2021-July/453790.html [4] https://lists.denx.de/pipermail/u-boot/2021-July/453848.html [5] https://lists.denx.de/pipermail/u-boot/2021-August/458569.html -- 2.25.1

5 27

[PATCH] udoo_neo: Move to DM for REGUALTOR/PMIC/I2C drivers
by Peter Robinson 18 Feb '22

18 Feb '22

This moves over the PMIC power init to DM and the associated i2c and regulator bits. Signed-off-by: Peter Robinson <pbrobinson(a)gmail.com> --- board/udoo/neo/neo.c | 139 +++---------------------------------- configs/udoo_neo_defconfig | 10 +-- include/configs/udoo_neo.h | 5 -- 3 files changed, 15 insertions(+), 139 deletions(-) diff --git a/board/udoo/neo/neo.c b/board/udoo/neo/neo.c index 62f81fff68..d374b86b5d 100644 --- a/board/udoo/neo/neo.c +++ b/board/udoo/neo/neo.c @@ -51,11 +51,6 @@ enum { PAD_CTL_PUS_22K_UP | PAD_CTL_SPEED_LOW | \ PAD_CTL_DSE_80ohm | PAD_CTL_SRE_FAST | PAD_CTL_HYS) -#define I2C_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \ - PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \ - PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \ - PAD_CTL_ODE) - #define ENET_PAD_CTRL (PAD_CTL_PUS_100K_UP | PAD_CTL_PUE | \ PAD_CTL_SPEED_MED | \ PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST) @@ -81,135 +76,25 @@ int dram_init(void) return 0; } -#ifdef CONFIG_SYS_I2C_MXC -#define PC MUX_PAD_CTRL(I2C_PAD_CTRL) -/* I2C1 for PMIC */ -static struct i2c_pads_info i2c_pad_info1 = { - .scl = { - .i2c_mode = MX6_PAD_GPIO1_IO00__I2C1_SCL | PC, - .gpio_mode = MX6_PAD_GPIO1_IO00__GPIO1_IO_0 | PC, - .gp = IMX_GPIO_NR(1, 0), - }, - .sda = { - .i2c_mode = MX6_PAD_GPIO1_IO01__I2C1_SDA | PC, - .gpio_mode = MX6_PAD_GPIO1_IO01__GPIO1_IO_1 | PC, - .gp = IMX_GPIO_NR(1, 1), - }, -}; -#endif - -#if CONFIG_IS_ENABLED(POWER_LEGACY) int power_init_board(void) { - struct pmic *p; - int ret; - unsigned int reg, rev_id; - - ret = power_pfuze3000_init(PFUZE3000_I2C_BUS); - if (ret) - return ret; - - p = pmic_get("PFUZE3000"); - ret = pmic_probe(p); - if (ret) - return ret; + struct udevice *dev; + int ret, dev_id, rev_id; - pmic_reg_read(p, PFUZE3000_DEVICEID, &reg); - pmic_reg_read(p, PFUZE3000_REVID, &rev_id); - printf("PMIC: PFUZE3000 DEV_ID=0x%x REV_ID=0x%x\n", reg, rev_id); - - /* disable Low Power Mode during standby mode */ - pmic_reg_read(p, PFUZE3000_LDOGCTL, &reg); - reg |= 0x1; - ret = pmic_reg_write(p, PFUZE3000_LDOGCTL, reg); - if (ret) + ret = pmic_get("pfuze3000@8", &dev); + if (ret == -ENODEV) + return 0; + if (ret != 0) return ret; - ret = pmic_reg_write(p, PFUZE3000_SW1AMODE, 0xc); - if (ret) - return ret; + dev_id = pmic_reg_read(dev, PFUZE3000_DEVICEID); + rev_id = pmic_reg_read(dev, PFUZE3000_REVID); + printf("PMIC: PFUZE3000 DEV_ID=0x%x REV_ID=0x%x\n", dev_id, rev_id); - ret = pmic_reg_write(p, PFUZE3000_SW1BMODE, 0xc); - if (ret) - return ret; - - ret = pmic_reg_write(p, PFUZE3000_SW2MODE, 0xc); - if (ret) - return ret; - - ret = pmic_reg_write(p, PFUZE3000_SW3MODE, 0xc); - if (ret) - return ret; - - /* set SW1A standby voltage 0.975V */ - pmic_reg_read(p, PFUZE3000_SW1ASTBY, &reg); - reg &= ~0x3f; - reg |= PFUZE3000_SW1AB_SETP(9750); - ret = pmic_reg_write(p, PFUZE3000_SW1ASTBY, reg); - if (ret) - return ret; - - /* set SW1B standby voltage 0.975V */ - pmic_reg_read(p, PFUZE3000_SW1BSTBY, &reg); - reg &= ~0x3f; - reg |= PFUZE3000_SW1AB_SETP(9750); - ret = pmic_reg_write(p, PFUZE3000_SW1BSTBY, reg); - if (ret) - return ret; - - /* set SW1A/VDD_ARM_IN step ramp up time from 16us to 4us/25mV */ - pmic_reg_read(p, PFUZE3000_SW1ACONF, &reg); - reg &= ~0xc0; - reg |= 0x40; - ret = pmic_reg_write(p, PFUZE3000_SW1ACONF, reg); - if (ret) - return ret; - - /* set SW1B/VDD_SOC_IN step ramp up time from 16us to 4us/25mV */ - pmic_reg_read(p, PFUZE3000_SW1BCONF, &reg); - reg &= ~0xc0; - reg |= 0x40; - ret = pmic_reg_write(p, PFUZE3000_SW1BCONF, reg); - if (ret) - return ret; - - /* set VDD_ARM_IN to 1.350V */ - pmic_reg_read(p, PFUZE3000_SW1AVOLT, &reg); - reg &= ~0x3f; - reg |= PFUZE3000_SW1AB_SETP(13500); - ret = pmic_reg_write(p, PFUZE3000_SW1AVOLT, reg); - if (ret) - return ret; - - /* set VDD_SOC_IN to 1.350V */ - pmic_reg_read(p, PFUZE3000_SW1BVOLT, &reg); - reg &= ~0x3f; - reg |= PFUZE3000_SW1AB_SETP(13500); - ret = pmic_reg_write(p, PFUZE3000_SW1BVOLT, reg); - if (ret) - return ret; - - /* set DDR_1_5V to 1.350V */ - pmic_reg_read(p, PFUZE3000_SW3VOLT, &reg); - reg &= ~0x0f; - reg |= PFUZE3000_SW3_SETP(13500); - ret = pmic_reg_write(p, PFUZE3000_SW3VOLT, reg); - if (ret) - return ret; - - /* set VGEN2_1V5 to 1.5V */ - pmic_reg_read(p, PFUZE3000_VLDO2CTL, &reg); - reg &= ~0x0f; - reg |= PFUZE3000_VLDO_SETP(15000); - /* enable */ - reg |= 0x10; - ret = pmic_reg_write(p, PFUZE3000_VLDO2CTL, reg); - if (ret) - return ret; + pmic_clrsetbits(dev, PFUZE3000_LDOGCTL, 0, 1); return 0; } -#endif static iomux_v3_cfg_t const uart1_pads[] = { MX6_PAD_GPIO1_IO04__UART1_TX | MUX_PAD_CTRL(UART_PAD_CTRL), @@ -299,10 +184,6 @@ int board_init(void) gpio_request(IMX_GPIO_NR(4, 16), "ncp692"); gpio_direction_output(IMX_GPIO_NR(4, 16) , 1); -#ifdef CONFIG_SYS_I2C_MXC - setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, &i2c_pad_info1); -#endif - setup_fec(); return 0; diff --git a/configs/udoo_neo_defconfig b/configs/udoo_neo_defconfig index ca08de1bd4..9177bdba65 100644 --- a/configs/udoo_neo_defconfig +++ b/configs/udoo_neo_defconfig @@ -10,8 +10,9 @@ CONFIG_ENV_SIZE=0x2000 CONFIG_ENV_OFFSET=0x80000 CONFIG_MX6SX=y CONFIG_TARGET_UDOO_NEO=y -CONFIG_SYS_I2C_MXC_I2C1=y +CONFIG_DM_I2C=y CONFIG_DM_GPIO=y +CONFIG_DM_MMC=y CONFIG_DEFAULT_DEVICE_TREE="imx6sx-udoo-neo-basic" CONFIG_SPL_TEXT_BASE=0x00908000 CONFIG_SPL_MMC=y @@ -39,8 +40,6 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_SYS_MMC_ENV_DEV=1 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y CONFIG_BOUNCE_BUFFER=y -CONFIG_SYS_I2C_LEGACY=y -CONFIG_SPL_SYS_I2C_LEGACY=y CONFIG_SYS_I2C_MXC=y CONFIG_FSL_USDHC=y CONFIG_PHYLIB=y @@ -52,11 +51,12 @@ CONFIG_FEC_MXC=y CONFIG_MII=y CONFIG_PINCTRL=y CONFIG_PINCTRL_IMX6=y -CONFIG_POWER_LEGACY=y -CONFIG_POWER_I2C=y +CONFIG_DM_PMIC=y +CONFIG_DM_PMIC_PFUZE100=y CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_ANATOP=y CONFIG_DM_REGULATOR_FIXED=y +CONFIG_DM_REGULATOR_PFUZE100=y CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_STORAGE=y diff --git a/include/configs/udoo_neo.h b/include/configs/udoo_neo.h index 3a7cb050b1..ac13c3e57f 100644 --- a/include/configs/udoo_neo.h +++ b/include/configs/udoo_neo.h @@ -68,9 +68,4 @@ #define CONFIG_SYS_INIT_SP_ADDR \ (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET) -/* PMIC */ -#define CONFIG_POWER_PFUZE3000 -#define CONFIG_POWER_PFUZE3000_I2C_ADDR 0x08 -#define PFUZE3000_I2C_BUS 0 - #endif /* __CONFIG_H */ -- 2.33.1

3 2

[PATCH v4 0/2] Add MNT Reform 2 board support
by Patrick Wildt 18 Feb '22

18 Feb '22

The MNT Reform 2 is a modular DIY laptop. In its initial version it is based on the BoundaryDevices i.MX8MQ SoM. Some parts have been lifted from BoundaryDevices official U-Boot downstream project. This U-Boot patchset supports the serial console, the SD card and eMMC, Gigabit Ethernet and USB. Changes since v3: - Adjusted to Binman changes in main branch. - Cleaned up environment variables akin to i.MX8MM. - Added vendor-prefix to device tree filename. - Provided ramdisk_addr_r. Changes since v2: - Switched to Binman. Changes since v1: - Synced DTS with files in Linux git repo. - Added support for USB host ports. Patrick Wildt (2): arm: dts: imx8mq: add MNT Reform 2 board: mntre: imx8mq: Add MNT Reform 2 board support arch/arm/dts/Makefile | 1 + arch/arm/dts/imx8mq-mnt-reform2-u-boot.dtsi | 13 + arch/arm/dts/imx8mq-mnt-reform2.dts | 214 ++++ arch/arm/dts/imx8mq-nitrogen-som.dtsi | 275 +++++ arch/arm/mach-imx/imx8m/Kconfig | 7 + board/mntre/imx8mq_reform2/Kconfig | 15 + board/mntre/imx8mq_reform2/MAINTAINERS | 7 + board/mntre/imx8mq_reform2/Makefile | 12 + board/mntre/imx8mq_reform2/imx8mq_reform2.c | 213 ++++ board/mntre/imx8mq_reform2/lpddr4_timing.c | 1014 +++++++++++++++++ .../mntre/imx8mq_reform2/lpddr4_timing_ch2.h | 95 ++ board/mntre/imx8mq_reform2/spl.c | 260 +++++ configs/imx8mq_reform2_defconfig | 85 ++ include/configs/imx8mq_reform2.h | 108 ++ 14 files changed, 2319 insertions(+) create mode 100644 arch/arm/dts/imx8mq-mnt-reform2-u-boot.dtsi create mode 100644 arch/arm/dts/imx8mq-mnt-reform2.dts create mode 100644 arch/arm/dts/imx8mq-nitrogen-som.dtsi create mode 100644 board/mntre/imx8mq_reform2/Kconfig create mode 100644 board/mntre/imx8mq_reform2/MAINTAINERS create mode 100644 board/mntre/imx8mq_reform2/Makefile create mode 100644 board/mntre/imx8mq_reform2/imx8mq_reform2.c create mode 100644 board/mntre/imx8mq_reform2/lpddr4_timing.c create mode 100644 board/mntre/imx8mq_reform2/lpddr4_timing_ch2.h create mode 100644 board/mntre/imx8mq_reform2/spl.c create mode 100644 configs/imx8mq_reform2_defconfig create mode 100644 include/configs/imx8mq_reform2.h -- 2.34.1

4 9

[PATCH 1/1] doc: describe fatload command
by Heinrich Schuchardt 18 Feb '22

18 Feb '22

Man-page for fatload command. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- doc/usage/fatload.rst | 80 +++++++++++++++++++++++++++++++++++++++++++ doc/usage/index.rst | 1 + 2 files changed, 81 insertions(+) create mode 100644 doc/usage/fatload.rst diff --git a/doc/usage/fatload.rst b/doc/usage/fatload.rst new file mode 100644 index 0000000000..93acb27a53 --- /dev/null +++ b/doc/usage/fatload.rst @@ -0,0 +1,80 @@ +.. SPDX-License-Identifier: GPL-2.0+: + +fatload command +=============== + +Synopsis +-------- + +:: + + fatload <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]] + +Description +----------- + +The fatload command is used to read a file from a FAT filesystem into memory. +You can always use the :doc:`load command <load>` instead. + +The number of transferred bytes is saved in the environment variable filesize. +The load address is saved in the environment variable fileaddr. + +interface + interface for accessing the block device (mmc, sata, scsi, usb, ....) + +dev + device number + +part + partition number, defaults to 0 (whole device) + +addr + load address, defaults to environment variable loadaddr or if loadaddr is + not set to configuration variable CONFIG_SYS_LOAD_ADDR + +filename + path to file, defaults to environment variable bootfile + +bytes + maximum number of bytes to load + +pos + number of bytes to skip + +addr, bytes, pos are hexadecimal numbers. + +If either 'pos' or 'bytes' are not aligned according to the minimum alignment +requirement for DMA transfer (ARCH_DMA_MINALIGN) additional buffering will be +used, a misaligned buffer warning will be printed, and performance will suffer +for the load. + +Example +------- + +:: + + => fatload mmc 0:1 ${kernel_addr_r} snp.efi + 149280 bytes read in 11 ms (12.9 MiB/s) + => + => fatload mmc 0:1 ${kernel_addr_r} snp.efi 1000000 + 149280 bytes read in 9 ms (15.8 MiB/s) + => + => fatload mmc 0:1 ${kernel_addr_r} snp.efi 1000000 100 + 149024 bytes read in 10 ms (14.2 MiB/s) + => + => fatload mmc 0:1 ${kernel_addr_r} snp.efi 10 + 16 bytes read in 1 ms (15.6 KiB/s) + => + +Configuration +------------- + +The fatload command is only available if CONFIG_CMD_FAT=y. + +Return value +------------ + +The return value $? is set to 0 (true) if the file was successfully loaded +even if the number of bytes is less then the specified length. + +If an error occurs, the return value $? is set to 1 (false). diff --git a/doc/usage/index.rst b/doc/usage/index.rst index 964d761e13..0aacf531b2 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -34,6 +34,7 @@ Shell commands exit false fatinfo + fatload for load loady -- 2.34.1

1 0

Single-document documentation format
by Tom Hale 18 Feb '22

18 Feb '22

I'm having a lot of trouble finding the definition of certain commands, eg "fatload": https://www.denx.de/wiki/view/DULG/WebSearch?search=fatload&web=on&scope=te… Is there an updated single page that I can search if I can't work out how to make search work for me? -- Thanks, Tom Hale

3 2

Which board to select for "Rasbperry Pi 4B"
by Tom Hale 18 Feb '22

18 Feb '22

I'm guessing that many of U-boot's users are on Raspberry Pi boards? Which board should I select at the board select page: https://www.denx.de/wiki/DULG/BoardSelect -- Thanks! Tom Hale

3 2