Re: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board

g for the new version and > imx8mm_evk_rohm_defconfig for the old one. > > What do you think? Maybe a dynamic way to identify if BD71837 or PCA9450 (by probing i2c) would work better? Different configs would imply different builds and binaries, which is a problem when trying to support a single build for both the old EVK and EVKB (and the main difference is the PMIC, nothing really major). I also share Andrey's concerns, as we do have several EVKs in hands, and having one single build would facilitate quite a bit. Cheers, -- Ricardo Salveti de Araujo

Re: [PATCH v2 1/2] mmc: Check for device with a seq number equal to num before checking against index

tly again, but I just wanted to reply back here first before submitting as I'm surprised nobody reported this issue before. Can you verify on your target hardware if this is indeed working as intended? Thanks, -- Ricardo Salveti

[PATCH] xilinx: zynqmp: increase CONFIG_SYS_SPL_MALLOC_SIZE to 16MB

A/TF-A/OP-TEE/U-Boot proper), which can easily reach up to 10MB, so increase the default CONFIG_SYS_SPL_MALLOC_SIZE size to 16MB to cover more advanced scenarios. Signed-off-by: Ricardo Salveti --- include/configs/xilinx_zynqmp.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --g

Re: [PATCH v2 1/2] mmc: Check for device with a seq number equal to num before checking against index

Hi Aswath, Thanks for the quick response. On Wed, Jul 7, 2021 at 1:55 AM Aswath Govindraju wrote: > > Hi Ricardo, > > On 07/07/21 4:39 am, Ricardo Salveti wrote: > > Hi Aswath, > > > > On Thu, Mar 25, 2021 at 4:19 AM Aswath Govindraju > > wrote: > >&

Re: RPi3: serial console

files I noticed it works fine with the latest firmware when using an older bcm2710-rpi-3-b-plus.dtb (placed together with the firmware). If I use the latest bcm2710-rpi-3-b-plus.dtb from the 5.4 downstream kernel, it doesn't work (only tested on rpi3-b-plus). This is with CONFIG_OF_BOARD=y, if I use CONFIG_OF_EMBED instead it works just fine (which gives me the impression that u-boot might not be happy with the dtb generated by the firmware when enable_uart is not set). Cheers, -- Ricardo Salveti de Araujo

Re: [U-Boot] [PATCH 3/3] omap4: splitting padconfs into common, 4430 and 4460

Hi Aneesh, On Thu, Sep 22, 2011 at 3:42 AM, Aneesh V wrote: > Hi Ricardo, > > On Thursday 22 September 2011 01:47 AM, Ricardo Salveti de Araujo wrote: >> Not all padconfs are the same between 4430 and 4460, so instead of >> working around this with an if, we should hav

Re: [U-Boot] [PULL] Please pull u-boot-imx

e is still valid. Jon, did you have any issue when testing that patch set on SOMs without eMMC support? Cheers, -- Ricardo Salveti de Araujo ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PULL] Please pull u-boot-imx

Hi Baruch, On Wed, Nov 14, 2018 at 5:07 AM Baruch Siach wrote: > > Hi Ricardo, > > On Tue, Nov 13, 2018 at 11:42:44AM -0200, Ricardo Salveti wrote: > > On Thu, Sep 6, 2018 at 12:52 PM Fabio Estevam wrote: > > > On Thu, Sep 6, 2018 at 12:42 PM, Baruch Siach wrote: >

Re: [U-Boot] [PULL] Please pull u-boot-imx

Hi Baruch, On Sun, Nov 18, 2018 at 7:51 AM Baruch Siach wrote: > > Hi Peter, Ricardo, > > Peter Robinson writes: > > On Fri, Nov 16, 2018 at 1:06 AM Ricardo Salveti > > wrote: > >> On Wed, Nov 14, 2018 at 5:07 AM Baruch Siach wrote: > >> > On T

Re: [U-Boot] [PULL] Please pull u-boot-imx

Hi Baruch, On Sun, Nov 18, 2018 at 6:29 PM Baruch Siach wrote: > > Hi Ricardo, > > Ricardo Salveti writes: > > The line where it locks up waiting for the command to complete: > > http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/fsl_esdhc.c;h=3cdfa7f5a689789ea2f24da8

Re: [U-Boot] [PATCH v2] mmc: fsl_esdhc: Avoid infinite loop in esdhc_send_cmd_common()

ng infinite loop inside esdhc_send_cmd_common() > > while (!(esdhc_read32(®s->irqstat) & flags)) > ; > > Instead of looping forever, provide an exit path so that a timeout > error can be propagated in the case irqstat does not report > any interru

Re: [U-Boot] [PATCH v2] mmc: fsl_esdhc: Avoid infinite loop in esdhc_send_cmd_common()

On Mon, Nov 19, 2018 at 12:03 PM Ricardo Salveti wrote: > > Hi Fabio, > > On Mon, Nov 19, 2018 at 10:31 AM Fabio Estevam wrote: > > > > The following hang is observed on a Hummingboard 2 MicroSOM > > i2eX iMX6D - rev 1.3 with no eMMC populated on board: > >

Re: [U-Boot] [PATCH v2] mmc: fsl_esdhc: Avoid infinite loop in esdhc_send_cmd_common()

On Mon, Nov 19, 2018 at 12:42 PM Fabio Estevam wrote: > > Hi Ricardo, > > On Mon, Nov 19, 2018 at 12:25 PM Ricardo Salveti > wrote: > > > Looking a bit further, this ends up adding a significant boot delay > > because the mmc driver still tries to send another two

[U-Boot] [PATCH] dragonboard410c: prefer sdcard boot over emmc

Make the external devices the preferred ones when booting the system (usb is already the first option). This allows users to easily boot custom distributions without requiring them to reflash/customize u-boot. Cc: Mateusz Kulikowski Signed-off-by: Ricardo Salveti --- include/configs

[U-Boot] [PATCH] dragonboard410c: adding missing default addr for script and pxe boot

Cc: Mateusz Kulikowski Signed-off-by: Ricardo Salveti --- include/configs/dragonboard410c.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/dragonboard410c.h b/include/configs/dragonboard410c.h index 74a827d..1dbe219 100644 --- a/include/configs/dragonboard410c.h +++ b

Re: [U-Boot] [PATCH 1/3] spl: imx6: Let spl_boot_device return USDHC1 or USDHC2

all the other boards using MMC2 and doing only one single call will have the same problem. Not sure if there is an easy fix here, but converting everything to dynamic mmc initialization will required quite a bit of effort. Thanks, -- Ricardo Salveti de Araujo ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] spl: imx6: Let spl_boot_device return USDHC1 or USDHC2

On Thu, Aug 8, 2019 at 10:13 AM Adam Ford wrote: > On Wed, Aug 7, 2019 at 6:44 PM Ricardo Salveti wrote: > > Hi Adam, > > > > On Thu, May 23, 2019 at 4:11 PM Adam Ford wrote: > > > > > > Currently, when the spl_boot_device checks the boot device, it >

Re: [U-Boot] [PATCH v1] common: fix building image.c

erence to `fit_image_load' bootm.c:(.text+0x132): undefined reference to `image_decomp' collect2: error: ld returned 1 exit status scripts/Makefile.host:106: recipe for target 'tools/dumpimage' failed Guess it is better to isolate the other individual pieces instead. Cheers, -- Ricardo Salveti de Araujo ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] apalis_imx6: fix broken fsl_esdhc_imx conversion

Commit e37ac717d796 ("Convert to use fsl_esdhc_imx for i.MX platforms") converted FSL_ESDHC to FSL_ESDHC_IMX, but the config check for apalis_imx6 wasn't updated accordantly. Signed-off-by: Ricardo Salveti --- board/toradex/apalis_imx6/apalis_imx6.c | 4 ++-- 1 file changed, 2 i

[U-Boot] [PATCH] spl: imx: only use HAB if spl fit signature is not enabled

: Ricardo Salveti --- arch/arm/mach-imx/spl.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c index 1f230aca33..a98fab8f1c 100644 --- a/arch/arm/mach-imx/spl.c +++ b/arch/arm/mach-imx/spl.c @@ -261,6 +261,7 @@ __weak void __noreturn

[U-Boot] [PATCH] apalis_imx6: allocate specific region of memory to OP-TEE

OP-TEE uses the memory region defined by the maximum DRAM address minus CONFIG_OPTEE_TZDRAM_SIZE, so subtract CONFIG_OPTEE_TZDRAM_SIZE from the available DRAM size to avoid conflicts. Signed-off-by: Ricardo Salveti --- board/toradex/apalis_imx6/apalis_imx6.c | 5 + 1 file changed, 5

[U-Boot] [PATCH] imx: apalis_imx6: select MX6Q via Kconfig

Toradex Apalis iMX6 modules are available in the iMX6D and iMX6Q variants, which are quite similar and already managed via only one dtb in u-boot (imx6-apalis.dtb). Select MX6Q via Kconfig by default in order to automatically enable the HAS_CAAM and MX6_SMP features. Signed-off-by: Ricardo

[U-Boot] [PATCH] apalis_imx6: add board_fit_config_name_match to support FIT in SPL

Only one dtb is currently supported, so match with imx6-apalis. Signed-off-by: Ricardo Salveti --- board/toradex/apalis_imx6/apalis_imx6.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/board/toradex/apalis_imx6/apalis_imx6.c b/board/toradex/apalis_imx6/apalis_imx6.c index

Re: [U-Boot] [PATCH] apalis_imx6: fix broken fsl_esdhc_imx conversion

On Tue, Sep 3, 2019 at 9:58 AM Max Krummenacher < max.krummenac...@toradex.com> wrote: > On Mon, 2019-09-02 at 18:12 -0300, Ricardo Salveti wrote: > > Commit e37ac717d796 ("Convert to use fsl_esdhc_imx for i.MX platforms") > > converted FSL_ESDHC to FSL_ESDH

Re: [U-Boot] [PATCH] apalis_imx6: allocate specific region of memory to OP-TEE

CONFIG_OPTEE_TZDRAM_SIZE from the available DRAM size to avoid > > conflicts. > > > > Signed-off-by: Ricardo Salveti > > --- > > board/toradex/apalis_imx6/apalis_imx6.c | 5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/board/toradex/

Re: [U-Boot] [PATCH] apalis_imx6: allocate specific region of memory to OP-TEE

On Tue, Sep 3, 2019 at 11:34 AM Igor Opaniuk wrote: > Hi Ricardo, > > On Tue, Sep 3, 2019 at 4:53 PM Ricardo Salveti wrote: > > > > On Tue, Sep 3, 2019 at 12:09 AM Peng Fan wrote: > > > > > > > Subject: [PATCH] apalis_imx6: allocate sp

[U-Boot] [PATCH] colibri_imx6: fix broken fsl_esdhc_imx conversion

Commit e37ac71 converted FSL_ESDHC to FSL_ESDHC_IMX, but the config check for colibri_imx6 wasn't updated accordantly. Signed-off-by: Ricardo Salveti --- board/toradex/colibri_imx6/colibri_imx6.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/board/toradex/colibri

Re: [PATCH] rpi: always set fdt_addr with firmware-provided FDT address

e.g. config.txt > >> and > >> that will break booting the system. > >> > >> But from your response it seems thats not what you are experiencing. Or do > >> you > >> change the DTB loaded from FW in the U-Boot shell? > > > > > > Maybe I wasn't too clear in my explanation ;-) > > > > At every boot, u-boot executes set_fdt_addr() function. At the very first > > boot, > > if nobody has changed the default u-boot environment built in u-boot, > > adding a > > custom fdt_addr variable, this function saves the fdt_addr variable in > > Which function are we talking about? Adding a custom fdt_addr can be done via > the CLI or by adding that to the U-Boot sources (include/configs/rpi.h) but > not > through a 'function'. > > Do you mean that in some script you made saveenv is called? I used overlays in > RPi and never had that problem. > > Actually I'm a bit puzzled about the problem. Can you give me a step by step > reproducer, starting with which config I should use to compile U-Boot? Yes, this issue only happens if you save the environment at least once, as then on following boots it won't set the address based on what the firmware uses, but instead restore the value from the saved environment, which can be wrong. I noticed the same when moving one sdcard between boards, and I was only able to get it to boot correctly after removing the saved environment. Cheers, -- Ricardo Salveti

Re: [PATCH] rpi: always set fdt_addr with firmware-provided FDT address

On Thu, Sep 30, 2021 at 12:12 AM Matthias Brugger wrote: > On 29/09/2021 23:05, Ricardo Salveti wrote: > > On Wed, Sep 29, 2021 at 1:49 PM Matthias Brugger wrote: > >> On 29/09/2021 14:19, Mauro Salvini wrote: > >>> Hi Matthias, > >>> > >>>

[PATCH] ARM: imx8m: support env in fat and ext4

NOWHERE when no valid mode is found. Signed-off-by: Ricardo Salveti --- arch/arm/mach-imx/imx8m/soc.c | 35 +++ 1 file changed, 15 insertions(+), 20 deletions(-) diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c index f2ddc834d4b

Re: i.MX8MM-EVK Boot failure

ng default environment In:serial Out: serial Err: serial Net: Warning: ethernet@30be using MAC address from ROM eth0: ethernet@30be Hit any key to stop autoboot: 0 MMC Device 0 not found no mmc device at slot 0 MMC Device 0 not found no mmc device at slot 0 Will investigate more tomorrow, but reporting as you might know where the problem is. Thanks, -- Ricardo Salveti de Araujo

Re: i.MX8MM-EVK Boot failure

Hi Fabio, On Fri, Dec 13, 2019 at 6:44 AM Fabio Estevam wrote: > > Hi Ricardo, > > On Thu, Dec 12, 2019 at 6:20 PM Ricardo Salveti wrote: > > > Can you also confirm if mmc is working correctly on imx8mm evk? > > I don't have access to a imx8mm_evk at the moment,

Re: [PATCHv3] zynqmp: restore the jtag interface

restore_jtag(); #else if (CONFIG_IS_ENABLED(DM_I2C) && CONFIG_IS_ENABLED(I2C_EEPROM)) Do you want me to send a patch directly to you or do you prefer to squash the changes as it seems this wasn't asked to be merged upstream yet? Thanks, -- Ricardo Salveti

[PATCH] xilinx: zynqmp: fix ZYNQMP_RESTORE_JTAG check

Config check should be done without the SPL_ prefix. Signed-off-by: Ricardo Salveti --- board/xilinx/zynqmp/zynqmp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c index dfb5dab7afa..2b5239ccb47 100644 --- a/board

[PATCH] xilinx: common: change bootm_size to not go beyond ram_top

is available in env_get_bootm_size when bootm_size is not defined by the default environment. Signed-off-by: Ricardo Salveti --- board/xilinx/common/board.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c index 78a5d0efa86

Re: [PATCH] xilinx: common: change bootm_size to not go beyond ram_top

On Thu, Jan 20, 2022 at 4:33 AM Michal Simek wrote: > On 1/19/22 23:52, Ricardo Salveti wrote: > > The available ram can be limited by ram_top as that depends on the > > reserved memory nodes provided by the device-tree (via > > board_get_usable_ram_top), so make sure to

[PATCH v2] xilinx: common: change bootm_size to not go beyond ram_top

is available in env_get_bootm_size when bootm_size is not defined by the default environment. Signed-off-by: Ricardo Salveti --- Change in v2: - Declare bootm_size based on ram top and base board/xilinx/common/board.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board

Unable to select a different ENV location due env_get_location on zynqmp

k. Thanks, -- Ricardo Salveti

Re: Unable to select a different ENV location due env_get_location on zynqmp

wrote: > >>>> Hi, > >>>> > >>>> On 2/14/22 21:10, Ricardo Salveti wrote: > >>>>> Hi Michal, > >>>>> > >>>>> This is a bit similar to the issue raised on iMX8-based targets a few > >>>>

[U-Boot] [PATCH 0/3] omap4: changes for 4460 ES1.1

Changes to add proper support for 4460 ES1.1, including revision detection. Ricardo Salveti de Araujo (3): omap4: replacing OMAP4_CONTROL with OMAP4430_CONTROL omap4: adding revision detection for 4460 ES1.1 omap4: splitting padconfs into common, 4430 and 4460 arch/arm/cpu/armv7/omap4

[U-Boot] [PATCH 1/3] omap4: replacing OMAP4_CONTROL with OMAP4430_CONTROL

OMAP4460 has a different set of values for the ID code, so moving the old ones to be related just with 4430. Signed-off-by: Ricardo Salveti de Araujo 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/arm/cpu/armv7/omap4/board.c b/arch/arm/cpu/armv7/omap4/board.c index 309b244

[U-Boot] [PATCH 3/3] omap4: splitting padconfs into common, 4430 and 4460

Not all padconfs are the same between 4430 and 4460, so instead of working around this with an if, we should have an specific padconf structure for both chips (like handling the differences between the LEDs GPIOs and TPS). Signed-off-by: Ricardo Salveti de Araujo 4 files changed, 40 insertions

[U-Boot] [PATCH 2/3] omap4: adding revision detection for 4460 ES1.1

Signed-off-by: Ricardo Salveti de Araujo 2 files changed, 17 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/armv7/omap4/board.c b/arch/arm/cpu/armv7/omap4/board.c index 140562b..d9639ab 100644 --- a/arch/arm/cpu/armv7/omap4/board.c +++ b/arch/arm/cpu/armv7/omap4/board.c @@ -218,7