Hi Tim, Marek,
On 20.05.22 00:24, Tim Harvey wrote:
On Sun, Apr 24, 2022 at 2:41 PM Marek Vasut wrote:
Add PCA9450 regulator driver. This is complementary driver for the BUCKn
and LDOn regulators provided by the PCA9450 PMIC driver. Currently the
driver permits reading the settngs and configu
Hi Patrick
One typo and one remark below
On 5/6/22 16:06, Patrick Delaunay wrote:
> Add stm32mp15x prefix to all STM32MP15x board specific function,
> this patch is a preliminary step for STM32MP13x support.
>
> This patch also add the RCC probe to avoid circular access with
s/add/adds
> usbph
HI Patrick
On 5/6/22 16:06, Patrick Delaunay wrote:
> Add support for new compatible "st,stm32mp13-ddr" to manage the
> DDR sub system (Controller and PHY) in STM32MP13x SOC:
> - only one AXI port
> - support of 16 port output (MEMC_DRAM_DATA_WIDTH = 2)
>
> The STM32MP15x SOC have 2 AXI ports and
On Fri, May 20, 2022 at 10:59 AM Rover Mo wrote:
>
> arch/*/lib/bootm.c is for the boot Linux commands, not just for
> bootm command.
>
> This commit makes CONFIG_BOOTM_LINUX selected by the boot Linux
> commands and arch/*/lib/bootm.c will be built if enabled
> CONFIG_BOOTM_LINUX.
NAK.
bootm is
Hi Patrick
On 5/6/22 16:06, Patrick Delaunay wrote:
> Although not recommended, the reset property could be made optional.
> This way the driver will probe even if no reset property is provided
> in an sdmmc node in DT. This reset is already optional in Linux.
>
> Signed-off-by: Yann Gautier
> S
HI Patrick
On 5/6/22 16:06, Patrick Delaunay wrote:
> Compile the device tree of STM32MP13x boards and add the needed
> U-Boot add-on.
>
> Signed-off-by: Patrick Delaunay
> ---
>
> arch/arm/dts/Makefile | 3 +
> arch/arm/dts/stm32mp13-u-boot.dtsi | 91 ++
Hi Patrick
On 5/6/22 16:06, Patrick Delaunay wrote:
> Add a initial config for STM32M13x SOC family, using the stm32mp135f-dk
> device tree.
>
> Signed-off-by: Patrick Delaunay
> ---
>
> board/st/stm32mp1/MAINTAINERS | 1 +
> configs/stm32mp13_defconfig | 54
On 5/20/22 09:00, Stefano Babic wrote:
Hi Tim, Marek,
Hi,
It's defined differently in include/power/bd71837.h (where it should
also likely be changed to something that doesn't collide)
$ git grep DVS_BUCK_RUN_MASK include/
include/power/bd71837.h:#define DVS_BUCK_RUN_MASK 0x3f
i
Hi,
On 5/17/22 14:39, Patrick DELAUNAY wrote:
Hi,
On 5/11/22 23:09, Marek Vasut wrote:
The Avenger96 board comes in multiple regulator configurations.
- rev.100 or rev.200 have Buck3 preconfigured to 3V3 operation on
boot and contains extra Enpirion EP53A8LQI DCDC converter which
sup
Hi,
On 5/17/22 10:23, Patrick DELAUNAY wrote:
Hi Patrice,
On 5/12/22 09:17, Patrice Chotard wrote:
Currently, SR_TCF flag is checked in case there is data, this criteria
is not correct.
SR_TCF flags is set when programmed number of bytes have been
transferred
to the memory device ("bytes" c
Hi PAtrick
typos below
On 5/6/22 16:06, Patrick Delaunay wrote:
> Add in U-Boot documentation the quick instruction for
s/for/to
> setup the STMicroelectronics STM32MP13x boards.
>
> Signed-off-by: Patrick Delaunay
> ---
>
> doc/board/st/stm32mp1.rst | 181 ++
Hi,
On 5/17/22 10:24, Patrick DELAUNAY wrote:
Hi Patrice
On 5/12/22 09:17, Patrice Chotard wrote:
Waiting for SR_BUSY bit when receiving a new command is not needed.
SR_BUSY bit is already managed in the previous command treatment.
Signed-off-by: Patrice Chotard
---
drivers/spi/stm32_qsp
another typo found below
On 5/20/22 08:49, Patrice CHOTARD wrote:
> Hi Patrick
>
> 2 minor typo below
>
> Thanks
> Patrice
>
> On 5/6/22 16:06, Patrick Delaunay wrote:
>> Introduce the code in mach-stm32mp and the configuration file
>> stm32mp13_defconfig for the new STM32MP family.
>>
>> Signe
Hi Tom,
Please pull the STM32 related fixes for u-boot/master, v2022.07:
u-boot-stm32-20220520
- spi: fix busy bit check in stm32_qspi driver
- stm32mp15: configure Buck3 voltage per PMIC NVM on Avenger96 board
CI status:
https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/12043
On 20.05.22 09:19, Marek Vasut wrote:
On 5/20/22 09:00, Stefano Babic wrote:
Hi Tim, Marek,
Hi,
It's defined differently in include/power/bd71837.h (where it should
also likely be changed to something that doesn't collide)
$ git grep DVS_BUCK_RUN_MASK include/
include/power/bd71837.h:#def
Hi Marek,
On 24.04.22 23:44, Marek Vasut wrote:
Introduce helper macro UART_BASE_ADDR(n), which returns Nth UART base
address. Convert all board configurations to this new macro. This is the
first step toward switching CONFIG_MXC_UART_BASE to Kconfig. This is a
clean up, no functional change.
T
On 5/20/22 09:24, Patrice CHOTARD wrote:
[...]
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause */
+/*
+ * Copyright (C) 2022, STMicroelectronics - All Rights Reserved
+ *
+ * Configuration settings for the STMicroelectonics STM32MP15x boards
s/STMicroelectonics/
On 5/20/22 09:30, Stefano Babic wrote:
Hi Marek,
On 24.04.22 23:44, Marek Vasut wrote:
Introduce helper macro UART_BASE_ADDR(n), which returns Nth UART base
address. Convert all board configurations to this new macro. This is the
first step toward switching CONFIG_MXC_UART_BASE to Kconfig. This
On 20.05.22 09:45, Marek Vasut wrote:
On 5/20/22 09:30, Stefano Babic wrote:
Hi Marek,
On 24.04.22 23:44, Marek Vasut wrote:
Introduce helper macro UART_BASE_ADDR(n), which returns Nth UART base
address. Convert all board configurations to this new macro. This is the
first step toward switchin
On Friday 20 May 2022 07:05:50 Stefan Roese wrote:
> On 19.05.22 11:11, Pali Rohár wrote:
> > It does not matter what is DT node name of atsha device. So find it via
> > atsha driver and not by DT node name.
> >
> > Signed-off-by: Pali Rohár
>
> Just curious: What exactly does this patch fix? Is
On 20.05.22 10:11, Stefano Babic wrote:
On 20.05.22 09:45, Marek Vasut wrote:
On 5/20/22 09:30, Stefano Babic wrote:
Hi Marek,
On 24.04.22 23:44, Marek Vasut wrote:
Introduce helper macro UART_BASE_ADDR(n), which returns Nth UART base
address. Convert all board configurations to this new macr
On Mon, May 16, 2022 at 12:50:34PM -0300, Fabio Estevam wrote:
> Hi Marcel,
>
> On 16/05/2022 12:41, Marcel Ziswiler wrote:
>
> > Talking about uuu, has anybody managed to get that going on the i.MX
> > 8M Mini yet? Regular USB device/host
> > functionality works great but last I tried gadget fun
This patch series adds support for the DHCOM DRC02 and DH picoITX
baseboards by DH electronics.
The two boards can be equipped with different SoMs. The STM32MP15xx based
versions are already mainlined. This patch adds support for the iMX6QDL
based variants.
Changes in v2:
- Rewrite board_fit_co
In the DH electronics iMX6 board file fix the outdated eeprom path by
using a DT label instead.
The label has been newly created for all iMX6QDL DHCOM boards.
Reviewed-by: Marek Vasut
Signed-off-by: Philip Oberfichtner
---
Changes in v2:
- Reviewed-by Marek
arch/arm/dts/imx6qdl-dhcom-u-boot
Migrate DH DRC02 device trees from Linux commit 42226c989789
(tag v5.18-rc7). No changes have been made, the DTs are exact copies.
Furthermore add the DTB to dh_imx6_defconfig.
Reviewed-by: Marek Vasut
Signed-off-by: Philip Oberfichtner
---
(no changes since v1)
arch/arm/dts/Makefile
Migrate DH picoITX device trees from Linux commit 42226c989789
(tag v5.18-rc7). No changes have been made, the DTs are exact copies.
Furthermore add the DTB to dh_imx6_defconfig.
Reviewed-by: Marek Vasut
Signed-off-by: Philip Oberfichtner
---
(no changes since v1)
arch/arm/dts/Makefile
Firstly the FEC can now use the regulator reg_eth_vio from
imx6qdl-dhcom-som.dtsi instead of defining its own.
Secondly the &fec node is moved to the more generic SoM device tree
file, because it can be used by multiple boards.
Reviewed-by: Marek Vasut
Signed-off-by: Philip Oberfichtner
---
C
Use phy address from device tree instead of CONFIG_FEC_MXC_PHYADDR from
board header. This is required, because the DH picoITX and DRC02 boards
require different settings than PDK2. The corresponding 'phy-handle'
device tree properties are already there.
I tested this change on picoITX and DRC02,
Add a u-boot dtsi for configuring the FEC node of the DH DRC02.
Reviewed-by: Marek Vasut
Signed-off-by: Philip Oberfichtner
---
Changes in v2:
- Reviewed-by Marek
arch/arm/dts/imx6s-dhcom-drc02-u-boot.dtsi | 10 ++
1 file changed, 10 insertions(+)
create mode 100644 arch/arm/dts/imx
Add a u-boot dtsi for configuring the FEC node of the DH picoITX.
Reviewed-by: Marek Vasut
Signed-off-by: Philip Oberfichtner
---
Changes in v2:
- Reviewed-by Marek
arch/arm/dts/imx6dl-dhcom-picoitx-u-boot.dtsi | 10 ++
1 file changed, 10 insertions(+)
create mode 100644 arch/arm/dt
Before this commit device tree selection could rely solely on
differentiating the iMX6 processor variant Q and DL. After adding two new
carrier boards, the DRC02 and the picoITX, the interchangeability of SoMs
makes this approach infeasible.
It is now required to specify the carrier board (dhcom-d
At 2022-05-20 14:34:18, "Heinrich Schuchardt" wrote:
>Am 20. Mai 2022 04:58:46 MESZ schrieb Rover Mo :
>
>Having EFI_SECURE_BOOT=y is not enough to use secure boot. You must also
>supply variables PK, KEK, db, dbx.
>
>Furthermore you would have to disable a whole lot more commands to secure the
Hi Marek,
don't you mind if I apply to my u-booz-imx this (that really belongs to
your competence area) ?
It fixes warnings for the librem5, and it is a pity if I cannot merge it.
Best regards,
Stefano
On 24.04.22 16:08, Angus Ainslie wrote:
Suppress warnings when building the SPL without U
On 5/20/22 11:08, Stefano Babic wrote:
Hi Marek,
don't you mind if I apply to my u-booz-imx this (that really belongs to
your competence area) ?
It fixes warnings for the librem5, and it is a pity if I cannot merge it.
Just pick it via imx, that's fine, I don't expect conflict.
Reviewed-by
Update the uDPU DTS to the version that is pending upstream [1][2][3][4].
[1]
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20220516124828.45144-4-robert.ma...@sartura.hr/
[2]
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20220516124828.45144-5-robert.ma...@sartura.hr
I am currently maintaing the Methode uDPU and eDPU boards so add myself
as the maintainer for them.
Signed-off-by: Robert Marko
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 56be0bfad0..3d72b0c11f 100644
--- a/MAINTAINERS
+++ b/MAINTA
Methode eDPU is an Armada 3720 power board based on the Methode uDPU.
They feature the same CPU, RAM, and storage as well as the form factor.
However, eDPU only has one SFP slot plus a copper G.hn port which does not
work under U-boot.
In order to reduce duplication, split the uDPU DTS into a co
On Mon, May 16, 2022 at 10:54 AM Stefan Roese wrote:
>
> On 16.05.22 10:52, Robert Marko wrote:
> > On Mon, May 16, 2022 at 8:40 AM Stefan Roese wrote:
> >>
> >> On 06.05.22 20:01, Robert Marko wrote:
> >>> Methode eDPU is an Armada 3720 power board based on the Methode uDPU.
> >>>
> >>> They fea
On 5/20/22 10:46, Philip Oberfichtner wrote:
Before this commit device tree selection could rely solely on
differentiating the iMX6 processor variant Q and DL. After adding two new
carrier boards, the DRC02 and the picoITX, the interchangeability of SoMs
makes this approach infeasible.
It is now
rootwait=1 is not a valid kernel boot parameters. According
to the documenation is only rootwait
rootwait[KNL] Wait (indefinitely) for root device to show up.
Useful for devices that are detected asynchronously
(e.g. USB and MMC devices).
On Friday 20 May 2022 12:54:23 Robert Marko wrote:
> Methode eDPU is an Armada 3720 power board based on the Methode uDPU.
>
> They feature the same CPU, RAM, and storage as well as the form factor.
>
> However, eDPU only has one SFP slot plus a copper G.hn port which does not
> work under U-boot
On Fri, May 20, 2022 at 1:01 PM Pali Rohár wrote:
>
> On Friday 20 May 2022 12:54:23 Robert Marko wrote:
> > Methode eDPU is an Armada 3720 power board based on the Methode uDPU.
> >
> > They feature the same CPU, RAM, and storage as well as the form factor.
> >
> > However, eDPU only has one SFP
Update the uDPU DTS to the version that is pending upstream [1][2][3][4].
[1]
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20220516124828.45144-4-robert.ma...@sartura.hr/
[2]
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20220516124828.45144-5-robert.ma...@sartura.hr
I am currently maintaing the Methode uDPU and eDPU boards so add myself
as the maintainer for them.
Signed-off-by: Robert Marko
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 56be0bfad0..3d72b0c11f 100644
--- a/MAINTAINERS
+++ b/MAINTA
Methode eDPU is an Armada 3720 power board based on the Methode uDPU.
They feature the same CPU, RAM, and storage as well as the form factor.
However, eDPU only has one SFP slot plus a copper G.hn port which does not
work under U-boot.
In order to reduce duplication, split the uDPU DTS into a co
On Fri, May 20, 2022 at 01:00:13PM +0200, Michael Trimarchi wrote:
> rootwait=1 is not a valid kernel boot parameters. According
> to the documenation is only rootwait
>
> rootwait [KNL] Wait (indefinitely) for root device to show up.
> Useful for devices that are dete
On 20.05.22 13:12, Robert Marko wrote:
I am currently maintaing the Methode uDPU and eDPU boards so add myself
as the maintainer for them.
Signed-off-by: Robert Marko
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 56be0bfad0..3d72b
The bi_enetaddr field in struct bd_info is write-only; nothing ever
reads back the value.
Moreover, the value we write is more or less random, and certainly not
something one can rely on: If the board has a writable environment and
the mac address has been stored there, we fetch that value. But if
On Fri, May 20, 2022 at 1:17 PM Stefan Roese wrote:
>
> On 20.05.22 13:12, Robert Marko wrote:
> > I am currently maintaing the Methode uDPU and eDPU boards so add myself
> > as the maintainer for them.
> >
> > Signed-off-by: Robert Marko
> > ---
> > MAINTAINERS | 8
> > 1 file change
On 20.05.22 13:26, Robert Marko wrote:
On Fri, May 20, 2022 at 1:17 PM Stefan Roese wrote:
On 20.05.22 13:12, Robert Marko wrote:
I am currently maintaing the Methode uDPU and eDPU boards so add myself
as the maintainer for them.
Signed-off-by: Robert Marko
---
MAINTAINERS | 8
Hi Philip,
On 20/05/2022 05:46, Philip Oberfichtner wrote:
This patch series adds support for the DHCOM DRC02 and DH picoITX
baseboards by DH electronics.
The two boards can be equipped with different SoMs. The STM32MP15xx
based
versions are already mainlined. This patch adds support for the
Update the uDPU DTS to the version that is pending upstream [1][2][3][4].
[1]
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20220516124828.45144-4-robert.ma...@sartura.hr/
[2]
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20220516124828.45144-5-robert.ma...@sartura.hr
Methode eDPU is an Armada 3720 power board based on the Methode uDPU.
They feature the same CPU, RAM, and storage as well as the form factor.
However, eDPU only has one SFP slot plus a copper G.hn port which does not
work under U-boot.
In order to reduce duplication, split the uDPU DTS into a co
I am currently maintaing the Methode uDPU and eDPU boards so add myself
as the maintainer for them.
Remove the old entry from board/Marvell/mvebu_armada-37xx/MAINTAINERS.
Signed-off-by: Robert Marko
---
Changes in v5:
* Remove entry from the board/Marvell/mvebu_armada-37xx/MAINTAINERS
---
MAINT
From: Nikita Shubin
Restore global pointer before board_init_f_init_reserve call,
as "a0" can be set in harts_early_init call and we end up with
invalid global pointer.
Signed-off-by: Nikita Shubin
---
arch/riscv/cpu/start.S | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/riscv/cpu/st
On 20.05.22 12:21, Marek Vasut wrote:
On 5/20/22 11:08, Stefano Babic wrote:
Hi Marek,
don't you mind if I apply to my u-booz-imx this (that really belongs
to your competence area) ?
It fixes warnings for the librem5, and it is a pity if I cannot merge it.
Just pick it via imx, that's fine
On 2022-05-20 05:31, Stefano Babic wrote:
On 20.05.22 12:21, Marek Vasut wrote:
On 5/20/22 11:08, Stefano Babic wrote:
Hi Marek,
don't you mind if I apply to my u-booz-imx this (that really belongs
to your competence area) ?
It fixes warnings for the librem5, and it is a pity if I cannot me
From: Peng Fan
Use BINMAN instead of imx specific packing method.
Signed-off-by: Peng Fan
---
arch/arm/mach-imx/imx8m/Kconfig | 1 +
arch/arm/mach-imx/imx8m/imximage-8mm-lpddr4.cfg | 10 +-
configs/imx8mm-icore-mx8mm-ctouch2_defconfig| 2 +-
configs/imx8mm-icore-m
From: Peng Fan
set the symbol as weak not work if LTO is enabled. Since u_boot_any is
only used on X86 for now, so guard it with X86, otherwise build break
if we use BINMAN_SYMBOLS on i.MX.
Tested-by: Tim Harvey #imx8m[m,n,p]-venice
Signed-off-by: Peng Fan
---
common/spl/spl.c | 8 ++-
From: Peng Fan
In arch/arm/lib/sections.c there is below code:
char __image_copy_start[0] __section(".__image_copy_start");
But actually 'objdump -t spl/u-boot-spl' not able to find out
symbol '__image_copy_start' for binman update image-pos/size.
So update link file
Tested-by: Tim Harvey #imx
From: Peng Fan
In arch/arm/dts/imx8mp-u-boot.dtsi, there are blob-ext@1, blob-ext@2 and
etc which is for packing ddr phy firmware. However we could not declare
symbol name such as 'binman_sym_declare(ulong, blob_ext@1, image_pos)',
because '@' is not allowed, so we choose to declare the symbol
'b
From: Peng Fan
V4:
Fix three boards build failure
V3:
Add R-b/T-b
Fix build warning
V2:
resolve some CI failure
include patch 7
binman symbol is a good feature, but only used on X86 for now. This patchset
is to use it for i.MX8M platform.
The current imx8m ddr phy firmware consumes lots
From: Peng Fan
By reading binman symbols, we no need hard coded IMEM_LEN/DMEM_LEN after
we update the binman dtsi to drop 0x8000/0x4000 length for the firmware.
And that could save binary size for many KBs.
Tested-by: Tim Harvey #imx8m[m,n,p]-venice
Signed-off-by: Peng Fan
---
drivers/ddr/im
From: Peng Fan
We are migrating to use BINMAN SYMBOLS, the current name is not
a valid binman type, so update to use blob-ext@[1,2,3,4].
Tested-by: Tim Harvey #imx8m[m,n,p]-venice
Signed-off-by: Peng Fan
---
arch/arm/dts/imx8mm-u-boot.dtsi | 8
arch/arm/dts/imx8mn-b
From: Peng Fan
After we switch to use BINMAN_SYMBOLS, there is no need to pad
the file size to 0x8000 and 0x4000. After we use BINMAN_SYMBOLS,
the u-boot-spl-ddr.bin shrink about 36KB with i.MX8MP-EVK.
Tested-by: Tim Harvey #imx8m[m,n,p]-venice
Signed-off-by: Peng Fan
---
arch/arm/dts/imx8mm-
From: Peng Fan
There is case that CONFIG_BINMAN is defined, but
CONFIG_SPL_BINMAN_SYMBOLS is not defined. In that case, there will be
build failure. So use CONFIG_SPL_BINMAN_SYMBOLS to guard the macros, and
define CONFIG_SPL_BINMAN_SYMBOLS in binman syms test.
Tested-by: Tim Harvey #imx8m[m,n,p
> Introduce helper macro UART_BASE_ADDR(n), which returns Nth UART base
> address. Convert all board configurations to this new macro. This is the
> first step toward switching CONFIG_MXC_UART_BASE to Kconfig. This is a
> clean up, no functional change.
> The new macro contains compile-time test to
> The MaxLinear GPY111 PHY is being used on some boards due to part
> availability. Add support for this PHY which requires a longer reset
> post-delay and RGMII delay configuration.
> Signed-off-by: Tim Harvey
Applied to u-boot-imx, master, thanks !
Best regards,
Stefano Babic
--
=
> From: Peng Fan
> Mark pinctrl_wdog as u-boot,dm-spl to clean up board code,
> The set_wdog_reset() function is not necessary as this is handled by
> the imx_watchdog.c driver due to the 'fsl,ext-reset-output' property
> being set.
> Signed-off-by: Peng Fan
Applied to u-boot-imx, master, thanks
> The Bosch ACC (Air Center Control) Board is based on the i.MX6D.
> The device tree is copied from Linux, see [1]. The only difference
> compared to the Linux DT is the removal of usbphynop properties. They are
> defined in the Linux version of imx6qdl.dtsi, but not in the u-boot
> version.
> [1]
> From: Fabio Estevam
> There is no reason for disabling I-cache and D-cache
> in SPL.
>
> Remove the unneeded CONFIG_SPL_SYS_ICACHE_OFF and
> CONFIG_SPL_SYS_DCACHE_OFF options.
> Signed-off-by: Fabio Estevam
Applied to u-boot-imx, master, thanks !
Best regards,
Stefano Babic
--
=
> Use phy address from device tree instead of CONFIG_FEC_MXC_PHYADDR from
> board header. This is required, because the DH picoITX and DRC02 boards
> require different settings than PDK2. The corresponding 'phy-handle'
> device tree properties are already there.
> I tested this change on picoITX an
> From: Peng Fan
> Mark pinctrl_wdog as u-boot,dm-spl to clean up board code,
> The set_wdog_reset() function is not necessary as this is handled by
> the imx_watchdog.c driver due to the 'fsl,ext-reset-output' property
> being set.
> Signed-off-by: Peng Fan
Applied to u-boot-imx, master, thanks
> Add a u-boot dtsi for configuring the FEC node of the DH picoITX.
> Reviewed-by: Marek Vasut
> Signed-off-by: Philip Oberfichtner
Applied to u-boot-imx, master, thanks !
Best regards,
Stefano Babic
--
=
DENX Software Enginee
> implement get f/w version api.
> print ele f/w version in spl.
> Signed-off-by: Gaurav Jain
> Reviewed-by: Peng Fan
> Reviewed-by: Pankaj Gupta
Applied to u-boot-imx, master, thanks !
Best regards,
Stefano Babic
--
=
DENX S
> From: Peng Fan
> pinctrl_wdog already marked u-boot,dm-spl, so clean up board code.
> The set_wdog_reset() function is not necessary as this is handled by
> the imx_watchdog.c driver due to the 'fsl,ext-reset-output' property
> being set.
> Signed-off-by: Peng Fan
Applied to u-boot-imx, master,
> I was trying to employ lpddr4_mr_read() to something similar to what
> the imx8mm-cl-iot-gate board is doing for auto-detecting the RAM
> type. However, the version in drivers/ddr/imx/imx8m/ddrphy_utils.c
> differs from the private one used by that board in how it extracts the
> byte value, and I
> From: Fabio Estevam
> Add USB Mass Storage support, which is a convenient way to flash
> the eMMC card, for example.
> Signed-off-by: Fabio Estevam
Applied to u-boot-imx, master, thanks !
Best regards,
Stefano Babic
--
=
DEN
> In the DH electronics iMX6 board file fix the outdated eeprom path by
> using a DT label instead.
> The label has been newly created for all iMX6QDL DHCOM boards.
> Reviewed-by: Marek Vasut
> Signed-off-by: Philip Oberfichtner
Applied to u-boot-imx, master, thanks !
Best regards,
Stefano Babic
> From: Peng Fan
> Marked related nodes as u-boot,dm-spl for serial driver model
> Enable CONFIG_DM_SERIAL
> Signed-off-by: Peng Fan
> Reviewed-by: Fabio Estevam
Applied to u-boot-imx, master, thanks !
Best regards,
Stefano Babic
--
> commit 61cf22505339 ("board: gateworks: gw_ventana: use comomn GSC driver")
> moved to the common GSC driver and moved remaining board-specific
> functions to eeprom.c. The functions in gsc.c are no longer used and it
> was removed from the Makefile but the file itself was not removed.
> Remove i
> From: Fabio Estevam
> The "mmc dev ${mmcdev}" command is done twice.
> Remove one ocurrence to avoid the duplication.
> Signed-off-by: Fabio Estevam
Applied to u-boot-imx, master, thanks !
Best regards,
Stefano Babic
--
=
DE
> Introduce helper macro UART_BASE_ADDR(n), which returns Nth UART base
> address. Convert all board configurations to this new macro. This is the
> first step toward switching CONFIG_MXC_UART_BASE to Kconfig. This is a
> clean up, no functional change.
> The new macro contains compile-time test to
> The I2C2 has SMBus device SMSC USB2514Bi connected to it, the device is
> capable of up to 100 kHz operation. Reduce the bus frequency to 100 kHz
> to guarantee this I2C device can work correctly.
> Signed-off-by: Marek Vasut
> Cc: Fabio Estevam
> Cc: Peng Fan
> Cc: Stefano Babic
Applied to u
> From: Peng Fan
> pinctrl_wdog already marked u-boot,dm-spl, so clean up board code.
> The set_wdog_reset() function is not necessary as this is handled by
> the imx_watchdog.c driver due to the 'fsl,ext-reset-output' property
> being set.
> Signed-off-by: Peng Fan
> Tested-by: Ariel D'Alessandr
> The IMX8MP SoC FEC needs to have the FEC_QUIRK_ENET_MAC defined.
> Fixes: commit 2395625209cc ("board: gateworks: venice: add
> imx8mp-venice-gw740x support")
> Signed-off-by: Tim Harvey
Applied to u-boot-imx, master, thanks !
Best regards,
Stefano Babic
--
==
> From: Peng Fan
> Enable CONFIG_SPL_DM_SERIAL. uart and its pinmux was already
> marked with u-boot,dm-spl.
> Move preloader_console_init after spl_early_init to make sure driver
> model work.
> Signed-off-by: Peng Fan
> Reviewed-by: Fabio Estevam
Applied to u-boot-imx, master, thanks !
Best r
> From: Peng Fan
> To i.MX8, M core stack is pre-coded in source code, so need to get it
> before kicking M core. The stack pointer is stored in the first word of
> the first PT_LOAD section __isr_vector. So use a num to index the
> section loading.
> Signed-off-by: Peng Fan
Applied to u-boot-imx
> Add a u-boot dtsi for configuring the FEC node of the DH DRC02.
> Reviewed-by: Marek Vasut
> Signed-off-by: Philip Oberfichtner
Applied to u-boot-imx, master, thanks !
Best regards,
Stefano Babic
--
=
DENX Software Engineeri
> From: Peng Fan
> With rpoc_att, bootaux able to kick elf file for M core
> Signed-off-by: Peng Fan
Applied to u-boot-imx, master, thanks !
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, Managing Direct
> The uart2 and its pinmux are already marked with u-boot,dm-spl but we
> need to move the call to preloader_console_init() after spl_early_init()
> to avoid a board hang as dm can't be used until after spl_early_init()
> due to the uart driver not enabling the uart clock.
> Remove the manual confi
> From: Marcel Ziswiler
> Move the preloader_console_init() call after spl_early_init() to avoid
> board hang in SPL.
> While at it remove explicit in-code console/debug UART pinmuxing (uart1
> and its pinmuxing are already marked as u-boot,dm-spl via device tree).
> Fixes: 4551e1898769 ("configs:
> From: Peng Fan
> Mark pinctrl_wdog as u-boot,dm-spl to clean up board code,
> The set_wdog_reset() function is not necessary as this is handled by
> the imx_watchdog.c driver due to the 'fsl,ext-reset-output' property
> being set.
> Signed-off-by: Peng Fan
Applied to u-boot-imx, master, thanks
> The badblock should be skipped properly in reading and writing.
> Fix the logic. The bcb struct is written, skipping the bad block,
> so we need to read using the same logic. This was tested create
> bad block in the area and then flash it and read it back.
> Acked-by: Han Xu
> Tested-By: Tim Ha
> Introduce helper macro UART_BASE_ADDR(n), which returns Nth UART base
> address. Convert all board configurations to this new macro. This is the
> first step toward switching CONFIG_MXC_UART_BASE to Kconfig. This is a
> clean up, no functional change.
> The new macro contains compile-time test to
> From: Fabio Estevam
> The "mmc dev ${mmcdev}" command is done twice.
> Remove one ocurrence to avoid the duplication.
> Signed-off-by: Fabio Estevam
Applied to u-boot-imx, master, thanks !
Best regards,
Stefano Babic
--
=
DE
> From: Peng Fan
> Enable CONFIG_DM_SERIAL. uart2 and its pinmux was already
> marked with u-boot,dm-spl.
> Signed-off-by: Peng Fan
> Reviewed-by: Fabio Estevam
Applied to u-boot-imx, master, thanks !
Best regards,
Stefano Babic
--
=
> Move the hook after nand_scan_tail is called. The hook must be replaced
> to the mxs specific one but those must to be assignment later in the
> probe function.
> With this fix markbad is working again. Before this change:
> nand markbad 0xDEC00
> NXS NAND: Writing OOB isn't supported
> NXS NAND:
> From: Peng Fan
> Enable CONFIG_DM_SERIAL. uart2 and its pinmux was already
> marked with u-boot,dm-spl.
> Signed-off-by: Peng Fan
> Reviewed-by: Fabio Estevam
Applied to u-boot-imx, master, thanks !
Best regards,
Stefano Babic
--
=
> From: Peng Fan
> pinctrl_wdog already marked u-boot,dm-spl, so clean up board code.
> The set_wdog_reset() function is not necessary as this is handled by
> the imx_watchdog.c driver due to the 'fsl,ext-reset-output' property
> being set.
> Signed-off-by: Peng Fan
Applied to u-boot-imx, master,
1 - 100 of 173 matches
Mail list logo
