U-Boot v2020.10: Environment Variables Missing in include/configs/mt7623.h

Hello Ryder/Weijie, I am using mainline u-boot v2020.10 for "Banana Pi R2" board. I am trying to use a boot script "boot.scr", there are few environment variables that are missing for e.g. if you take a look at boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr}

Re: [BUG] Hang shortly after loading FDT when booting on RK3399

On 11/19/20 12:45 AM, Jean Lucas wrote: On 11/17/20 1:28 PM, Jean Lucas wrote: On 11/17/20 9:42 AM, Alper Nebi Yasak wrote: On 17/11/2020 17:11, Peter Robinson wrote: On Tue, Nov 17, 2020 at 12:43 PM Alper Nebi Yasak wrote: On 17/11/2020 04:49, Jean Lucas wrote: Hello all, On Pine64

Re: [PATCH v3 5/7] riscv: dts: Add device tree for Microchip Icicle Kit

> On 17-Nov-2020, at 7:46 AM, Bin Meng wrote: > > On Tue, Nov 10, 2020 at 6:46 PM Padmarao Begari > wrote: >> >> Add device tree for Microchip PolarFire SoC Icicle Kit. >> >> Signed-off-by: Padmarao Begari >> Reviewed-by: Anup Patel >> --- >> arch/riscv/dts/Makefile

Re: [BUG] Hang shortly after loading FDT when booting on RK3399

On 11/17/20 1:28 PM, Jean Lucas wrote: On 11/17/20 9:42 AM, Alper Nebi Yasak wrote: On 17/11/2020 17:11, Peter Robinson wrote: On Tue, Nov 17, 2020 at 12:43 PM Alper Nebi Yasak wrote: On 17/11/2020 04:49, Jean Lucas wrote: Hello all, On Pine64 RockPro64 and Pinebook Pro (both RK3399),

Re: [PATCH v3 0/3] tools/sunxi: Use mkimage for SPL generation

On 11/18/20 11:32 AM, Andre Przywara wrote: > Andre Przywara (3): > sunxi: Factor out eGON BROM header description > tools: mkimage: Add Allwinner eGON support > sunxi: Use mkimage for SPL boot image generation > > arch/arm/include/asm/arch-sunxi/spl.h | 65 +--- > common/image.c

Re: [PATCH v3 2/3] tools: mkimage: Add Allwinner eGON support

On 11/18/20 11:32 AM, Andre Przywara wrote: > So far we used the separate mksunxiboot tool for generating a bootable > image for Allwinner SPLs, probably just for historical reasons. > > Use the mkimage framework to generate a so called eGON image the > Allwinner BROM expects. > The new image

Re: [PATCH v4 1/2] dm: core: add function uclass_probe_all() to probe all devices

On 11/17/20 10:00 AM, Vabhav Sharma wrote: > From: Vabhav Sharma > > Support a common method to probe all devices associated with uclass. > > This includes data structures and code for finding the first device and > looping for remaining devices associated with uclasses (groups of devices >

Re: [PATCH v4 2/2] drivers: serial: probe all uart devices

On 11/17/20 10:00 AM, Vabhav Sharma wrote: > From: Vabhav Sharma > > U-Boot DM model probe only single device at a time > which is enabled and configured using device tree > or platform data method. > > PL011 UART IP is SBSA compliant and firmware does the > serial port set-up, initialization

Re: [PATCH v8 00/18] efi_loader: add capsule update support

On Wed, Nov 18, 2020 at 09:49:22AM -0500, Tom Rini wrote: > On Wed, Nov 18, 2020 at 12:11:29PM +0900, AKASHI Takahiro wrote: > > On Tue, Nov 17, 2020 at 10:02:41PM -0500, Tom Rini wrote: > > > On Wed, Nov 18, 2020 at 09:26:38AM +0900, AKASHI Takahiro wrote: > > > > On Tue, Nov 17, 2020 at

[PATCH v2] common: update: fix an "unused" warning against update_flash()

Since update_flash() is used only in update_tftp(), it should be guarded with appropriate config options. After the commit 3149e524fc1e, common/update.c will be built under either CONFIG_UDATE_TFTP, CONFIG_DFU_TFTP or CONFIG_UPDATE_FIT. Since CONFIG_UPDATE_FIT, hence fit_update(), doesn't rely on

Re: Porting U-Boot to a QCA9531 board?

Hi Heinrich > On 18 Nov 2020, at 17:27, Heinrich Schuchardt > wrote: > > > The driver will not be compiled because your config does not select > CONFIG_AG7XXX. So clear when you point it out. I’ll modify this, and retest, thank you. > >> - With OpenWrt 18.06

Re: Porting U-Boot to a QCA9531 board?

Hi Heinrich > On 18 Nov 2020, at 17:27, Heinrich Schuchardt wrote: > > > The driver will not be compiled because your config does not select > CONFIG_AG7XXX. So clear when you point it out. I’ll modify this, and retest, thank you. > >> - With OpenWrt 18.06 (Kernel 4.4 - ar71xx mach target)

Re: [BUG] U-boot does not detect emmc card in odroid-c2 for newer U-boot as 2020.04

I only have the emmc  installed. U-Boot 2021.01-rc2-00047-g9324c9a823-dirty (Nov 18 2020 - 16:38:40 +0100) odroid-c2 Model: Hardkernel ODROID-C2 SoC:   Amlogic Meson GXBB (S905) Revision 1f:c (0:1) DRAM:  2 GiB MMC:   mmc@72000: 0, mmc@74000: 1 In:    serial Out:   serial Err:   serial Net:  

[PATCH v3 2/3] tools: mkimage: Add Allwinner eGON support

So far we used the separate mksunxiboot tool for generating a bootable image for Allwinner SPLs, probably just for historical reasons. Use the mkimage framework to generate a so called eGON image the Allwinner BROM expects. The new image type is called "sunxi_egon", to differentiate it from the

[PATCH v3 3/3] sunxi: Use mkimage for SPL boot image generation

Switch the SPL boot image generation from using mksunxiboot to the new sunxi_egon format of mkimage. Verified to create identical results for all 152 Allwinner boards. Signed-off-by: Andre Przywara Reviewed-by: Simon Glass Reviewed-by: Jagan Teki --- scripts/Makefile.spl | 8 1 file

[PATCH v3 1/3] sunxi: Factor out eGON BROM header description

To be able to easily share the Allwinner eGON BROM header structure between the tools and the SPL code, move the struct definition into a separate header file. Signed-off-by: Andre Przywara --- arch/arm/include/asm/arch-sunxi/spl.h | 65 + include/sunxi_image.h

[PATCH v3 0/3] tools/sunxi: Use mkimage for SPL generation

Hi, an update addressing Samuel's review comments and fixing the broken tools-only build. == So far creating a bootable SPL image for Allwinner based boards uses the mksunxiboot tool. Most other platforms seemed to have integrated this kind of functionality into the common

Re: Porting U-Boot to a QCA9531 board?

On 18.11.20 11:34, Wambui Karuga wrote: > Hi > > I'm trying to port the latest version of U-Boot (master branch) to a QCA9531 > board, based on the QCA ap147 reference design which itself is OS image > compatible with the ap143 target of mainline U-Boot. The board comes with the > closed-source

Re: [BUG] U-boot does not detect emmc card in odroid-c2 for newer U-boot as 2020.04

On 16.11.20 15:16, Otto Meier wrote: > I tried to build  an actual u-boot from git for my odroid-c2 board. > > It doesn't find the emmc card and therefore does not boot from it. > emmc is Ok and boots with u-boot 2020.04 fine. > > Newer u-boot then 2020.04 show these messages: > >

Re:[RESEND PATCH] fdt: Use phandle to distinguish DT nodes with same name

On 11/18/20 8:44 PM, Aswath Govindraju wrote: > Hi Simon, > > On 18/11/20 8:07 pm, Simon Glass wrote: >> Hi Aswath, >> >> On Mon, 16 Nov 2020 at 07:29, Aswath Govindraju wrote: >>> >>> While assigning the sequence number to subsystem instances by reading the >>> aliases property, only DT

[PATCH v2 9/9] board: sl28: add OP-TEE Trusted OS support (bl32)

Add support to load the OP-TEE Trusted OS by the SPL. Signed-off-by: Michael Walle --- .../dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi | 36 +++ board/kontron/sl28/Kconfig| 23 board/kontron/sl28/sl28.c | 7 3 files

[PATCH v2 8/9] board: sl28: add ATF support (bl31)

Add support to load the bl31 part of the ARM Trusted Firmware by the SPL. Signed-off-by: Michael Walle --- .../dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi | 41 +- board/kontron/sl28/Kconfig| 10 board/kontron/sl28/Makefile | 6 ++-

[PATCH v2 7/9] board: sl28: remove u-boot from loadable DT node

It is not needed. Remove it. Signed-off-by: Michael Walle --- arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi | 3 --- 1 file changed, 3 deletions(-) diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi index

[PATCH v2 2/9] spl: atf: move storage for bl31_params into function

There is no need to have the storage available globally. This is also a preparation for LOAD_IMAGE_V2 support. That will introduce a similar generator function which also has its own storage. Signed-off-by: Michael Walle Acked-by: Michal Simek --- common/spl/spl_atf.c | 5 ++--- 1 file

[PATCH v2 5/9] spl: atf: add support for LOAD_IMAGE_V2

Newer platforms use the LOAD_IMAGE_V2 parameter passing method. Add support for it. Signed-off-by: Michael Walle --- common/spl/Kconfig | 9 common/spl/spl_atf.c | 99 ++-- include/atf_common.h | 30 ++ include/spl.h| 35

[PATCH v2 0/9] spl: atf: add support for LOAD_IMAGE_V2

Newer TF-A versions provide a new image loading protocol. This is used on (newer?) NXP's SoCs. Normally, the bootflow is bl1 -> bl2 -> bl31 -> u-boot. With this series it is possible that U-Boot SPL loads the bl31 directly and thus replacing bl1 and bl2 from the TF-A. This was tested on the

[PATCH v2 6/9] armv8: layerscape: don't initialize GIC in SPL

The BL31 expects the GIC to be uninitialized. Thus, if we are loading the BL31 by the SPL we must not initialize it. If u-boot is loaded by the SPL directly, it will initialize the GIC again (in the same lowlevel_init()). This was tested on a custom board with SPL loading the BL31 and jumping to

[PATCH v2 4/9] spl: atf: remove helper structure from common header

bl2_to_bl31_params_mem is just an implementation detail of the SPL ATF support and is not needed anywhere else. Move it from the header to the actual module. Signed-off-by: Michael Walle Acked-by: Michal Simek --- common/spl/spl_atf.c | 11 +++ include/atf_common.h | 14 --

[PATCH v2 3/9] spl: atf: provide a bl2_plat_get_bl31_params_default()

Move the actual implementation of the bl2_plat_get_bl31_params() to its own function. The weak function will just call the default implementation. This has the advantage that board code can still call the original implementation if it just want to modify minor things. Signed-off-by: Michael Walle

[PATCH v2 1/9] treewide: use CONFIG_IS_ENABLED() for ARMV8_SEC_FIRMWARE_SUPPORT

There is SPL_ARMV8_SEC_FIRMWARE_SUPPORT and ARMV8_SEC_FIRMWARE_SUPPORT. Thus use CONFIG_IS_ENABLED() instead of the simple #ifdef. Signed-off-by: Michael Walle Acked-by: Michal Simek --- arch/arm/cpu/armv8/cpu-dt.c | 2 +- arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 8

Re: [PATCH] dfu: simplify the dependencies of DFU_TFTP

On 17.11.20 01:27, AKASHI Takahiro wrote: > Since CONFIG_UPDATE_COMMON always selects CONFIG_DFU_WRITE_ALT, we can > drop the latter from dependencies of CONFIG_DFU_TFTP. > > Fixes: 3149e524fc1e ("common: update: add a generic interface for FIT >image") > Signed-off-by: AKASHI Takahiro

Re: [PATCH] common: update: fix an "unused" warning against update_flash()

On 17.11.20 01:26, AKASHI Takahiro wrote: > Since update_flash() is used only in update_tftp(), it should be > guarded with appropriate config options. You are not adding an additional guard but relaxing guards. Your commit message does not capture this. Here is an example requiring your patch:

Re: [PATCH 7/8] board: sl28: add ATF support (bl31)

Am 2020-11-18 15:15, schrieb Michal Simek: On 18. 11. 20 15:10, Michael Walle wrote: Am 2020-11-18 15:06, schrieb Michal Simek: On 16. 11. 20 22:47, Michael Walle wrote: Add support to load the bl31 part of the ARM Trusted Firmware by the SPL. Signed-off-by: Michael Walle ---  

Re: [BUG] U-boot does not detect emmc card in odroid-c2 for newer U-boot as 2020.04

Hi, i have reverted the commit fe95905ffed57d617cad81a71ac419d53aaa1ebf and  set regulator-allways-on in meson-gxbb-odroidc2.dts. And i also applied "PATCH V2] mmc: display an error number to debug" from list and disabled CONFIG_MMC_DEBUG after that i got the following result: U-Boot

Re: [PATCH 3/3] riscv: Complete efi header for RV32/64

On 17.11.20 09:07, Leo Liang wrote: > Date: Mon, 16 Nov 2020 17:07:41 +0800 > From: Leo Yu-Chi Liang > Subject: [PATCH 3/3] riscv: Complete efi header for RV32/64 > > This patch depends on Atish's patch. >

Re: [EXTERNAL] Re: [RESEND PATCH] fdt: Use phandle to distinguish DT nodes with same name

Hi Simon, On 18/11/20 8:07 pm, Simon Glass wrote: > Hi Aswath, > > On Mon, 16 Nov 2020 at 07:29, Aswath Govindraju wrote: >> >> While assigning the sequence number to subsystem instances by reading the >> aliases property, only DT nodes names are compared and not the complete >> path. This

Re: [SPECIFICATION RFC] The firmware and bootloader log specification

On 14.11.20 00:52, Daniel Kiper wrote: > Hey, > > This is next attempt to create firmware and bootloader log specification. > Due to high interest among industry it is an extension to the initial > bootloader log only specification. It takes into the account most of the > comments which I got up

Re: [PATCH V3] dm: core: Add late driver remove option

On Wed, Nov 18, 2020 at 07:37:27AM -0700, Simon Glass wrote: > Hi Marek, > > On Sun, 15 Nov 2020 at 06:19, Marek Vasut wrote: > > > > On 11/9/20 1:21 AM, Simon Glass wrote: > > > Hi Marek, > > > > [...] > > > > >> diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c > > >> index

Re: [PATCH v8 00/18] efi_loader: add capsule update support

On Wed, Nov 18, 2020 at 12:11:29PM +0900, AKASHI Takahiro wrote: > On Tue, Nov 17, 2020 at 10:02:41PM -0500, Tom Rini wrote: > > On Wed, Nov 18, 2020 at 09:26:38AM +0900, AKASHI Takahiro wrote: > > > On Tue, Nov 17, 2020 at 06:59:52PM -0500, Tom Rini wrote: > > > > On Wed, Nov 18, 2020 at

Re: [RESEND PATCH] fdt: Use phandle to distinguish DT nodes with same name

Hi Aswath, On Mon, 16 Nov 2020 at 07:29, Aswath Govindraju wrote: > > While assigning the sequence number to subsystem instances by reading the > aliases property, only DT nodes names are compared and not the complete > path. This causes a problem when there are two DT nodes with same name but >

Re: [PATCH V3] dm: core: Add late driver remove option

Hi Marek, On Sun, 15 Nov 2020 at 06:19, Marek Vasut wrote: > > On 11/9/20 1:21 AM, Simon Glass wrote: > > Hi Marek, > > [...] > > >> diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c > >> index 1206e306db..f9091a3d41 100644 > >> --- a/arch/arm/lib/bootm.c > >> +++ b/arch/arm/lib/bootm.c >

Re: [PATCH 4/5] env: allow default environment to be amended from control dtb

Hi, On Tue, 17 Nov 2020 at 11:23, Tom Rini wrote: > > On Tue, Nov 17, 2020 at 12:31:07PM +0100, Wolfgang Denk wrote: > > Dear Simon, > > > > In message > > you > > wrote: > > > > > > > Apending data to it is not acceptable. If you need to append data, > > > > then only to the regular

Re: [PATCH 03/18] common: board_f: Move setup_machine code to setup_bdinfo

Hi Ovidiu, On Tue, 17 Nov 2020 at 01:00, Ovidiu Panait wrote: > > Hi Simon, > > On 14.11.2020 17:17, Simon Glass wrote: > > [Please note this e-mail is from an EXTERNAL e-mail address] > > > > Hi Ovidiu > > > > On Thu, 5 Nov 2020 at 03:10, Ovidiu Panait > > wrote: > >> setup_bdinfo is used to

Re: [PATCH] common/board_r: make sure to call initr_dm() before initr_trace()

Hi Pragnesh, On Mon, 16 Nov 2020 at 22:23, Pragnesh Patel wrote: > > Hi, > > >-Original Message- > >From: Simon Glass > >Sent: 17 November 2020 05:23 > >To: Pragnesh Patel > >Cc: Heinrich Schuchardt ; U-Boot Mailing List >b...@lists.denx.de> > >Subject: Re: [PATCH] common/board_r:

Re: [PATCH] dm: core: Fix incorrect flag check

On Sun, 15 Nov 2020 at 13:23, Marek Vasut wrote: > > The test should be checking whether $flags are non-zero and $drv_flags > contain specific flags, however these two sets of flags are separate, > and the two tests should be logically ANDed, not bitwise ANDed. > > Signed-off-by: Marek Vasut >

Re: [PATCH 5/8] spl: atf: add support for LOAD_IMAGE_V2

On 16. 11. 20 22:47, Michael Walle wrote: > Newer platforms use the LOAD_IMAGE_V2 parameter passing method. Add > support for it. > > Signed-off-by: Michael Walle > --- > common/spl/Kconfig | 9 > common/spl/spl_atf.c | 99 ++-- >

Re: [PATCH 4/8] spl: atf: remove helper structure from common header

On 16. 11. 20 22:47, Michael Walle wrote: > bl2_to_bl31_params_mem is just an implementation detail of the SPL ATF > support and is not needed anywhere else. Move it from the header to the > actual module. > > Signed-off-by: Michael Walle > --- > common/spl/spl_atf.c | 11 +++ >

Re: [PATCH 3/8] spl: atf: provide a bl2_plat_get_bl31_params_default()

On 18. 11. 20 15:23, Michal Simek wrote: > > > On 16. 11. 20 22:47, Michael Walle wrote: >> Move the actual implementation of the bl2_plat_get_bl31_params() to its >> own function. The weak function will just call the default >> implementation. This has the advantage that board code can still

Re: [PATCH 3/8] spl: atf: provide a bl2_plat_get_bl31_params_default()

On 16. 11. 20 22:47, Michael Walle wrote: > Move the actual implementation of the bl2_plat_get_bl31_params() to its > own function. The weak function will just call the default > implementation. This has the advantage that board code can still call > the original implementation if it just want

Re: [PATCH 1/8] treewide: use CONFIG_IS_ENABLED() for ARMV8_SEC_FIRMWARE_SUPPORT

On 16. 11. 20 22:47, Michael Walle wrote: > There is SPL_ARMV8_SEC_FIRMWARE_SUPPORT and ARMV8_SEC_FIRMWARE_SUPPORT. > Thus use CONFIG_IS_ENABLED() instead of the simple #ifdef. > > Signed-off-by: Michael Walle > --- > arch/arm/cpu/armv8/cpu-dt.c | 2 +- >

Re: [PATCH 7/8] board: sl28: add ATF support (bl31)

Am 2020-11-18 15:15, schrieb Michal Simek: On 18. 11. 20 15:10, Michael Walle wrote: Am 2020-11-18 15:06, schrieb Michal Simek: On 16. 11. 20 22:47, Michael Walle wrote: Add support to load the bl31 part of the ARM Trusted Firmware by the SPL. Signed-off-by: Michael Walle ---  

Re: [PATCH RFC 10/20] mmc/jz_mmc: Add a JZ4740 compatible string

Hi Lubomir, On Tue, 2020-11-17 at 22:00 +0100, Lubomir Rintel wrote: > The driver doesn't use the jz4780's extra DMA channels and handles jz4740 > just fine. > > Signed-off-by: Lubomir Rintel > --- > drivers/mmc/jz_mmc.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git

Re: [U-Boot] [PATCH v2 4/4] Correct return code from builtin_run_command_list()

Re: [U-Boot] [GIT PULL] fpga changes

Re: [U-Boot] [PATCH 0/2] kbuild - trivial fixes

dc276b0113694ecc62913311e2580857754aa890173dfaa9d95afad6396bb741 " , " environmentId

Re: [U-Boot] [PATCH v2 02/11] Do not apply: tools: add genkconfig

dc276b0113694ecc62913311e2580857754aa890173dfaa9d95afad6396bb741 " , " environmentId

Re: [BUG] U-boot does not detect emmc card in odroid-c2 for newer U-boot as 2020.04

Hi, it is not a new issue, since u-boot 2020.07 this issue exists. even by using the repo you mention the error exist. I allways use : make odroid-c2_defconfig with no other config option set to build u-boot. Best regards Otto Am 18.11.20 um 09:12 schrieb Alexander Dahl: Hei hei, FWIW

Porting U-Boot to a QCA9531 board?

Hi I'm trying to port the latest version of U-Boot (master branch) to a QCA9531 board, based on the QCA ap147 reference design which itself is OS image compatible with the ap143 target of mainline U-Boot. The board comes with the closed-source BREED bootloader from the manufacturer but it also

Re: [PATCH 7/8] board: sl28: add ATF support (bl31)

On 18. 11. 20 15:10, Michael Walle wrote: > Am 2020-11-18 15:06, schrieb Michal Simek: >> On 16. 11. 20 22:47, Michael Walle wrote: >>> Add support to load the bl31 part of the ARM Trusted Firmware by the >>> SPL. >>> >>> Signed-off-by: Michael Walle >>> --- >>>  

Re: [PATCH 7/8] board: sl28: add ATF support (bl31)

Am 2020-11-18 15:06, schrieb Michal Simek: On 16. 11. 20 22:47, Michael Walle wrote: Add support to load the bl31 part of the ARM Trusted Firmware by the SPL. Signed-off-by: Michael Walle --- .../dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi | 41 +- board/kontron/sl28/Kconfig

Re: [PATCH 2/8] spl: atf: move storage for bl31_params into function

On 16. 11. 20 22:47, Michael Walle wrote: > There is no need to have the storage available globally. This is also a > preparation for LOAD_IMAGE_V2 support. That will introduce a similar > generator function which also has its own storage. > > Signed-off-by: Michael Walle > --- >

Re: [PATCH 7/8] board: sl28: add ATF support (bl31)

On 16. 11. 20 22:47, Michael Walle wrote: > Add support to load the bl31 part of the ARM Trusted Firmware by the > SPL. > > Signed-off-by: Michael Walle > --- > .../dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi | 41 +- > board/kontron/sl28/Kconfig| 10 >

Re: [BUG] U-boot does not detect emmc card in odroid-c2 for newer U-boot as 2020.04

On 11/18/20 8:44 PM, Otto Meier wrote: > Hi, > > it is not a new issue, since u-boot 2020.07 this issue exists. > even by using the repo you mention the error exist. Yes, git repo doesn't matter. When i have checked, you are using almost latest u-boot. (commit 9324c9a823) If it's existed since

Re: [PATCH v3] sunxi: add PineCube board

On 18/11/2020 10:27, Icenowy Zheng wrote: > PineCube is an IP camera development kit released by Pine64. > > It comes with the following compoents: > > - A mainboard with Sochip S3 SoC, a 16MByte SPI Flash, AXP209 PMIC, > a power-only microUSB connector, a USB Type-A connector, a 10/100Mbps >

RE: [PATCH 4/8] M: dts: r8a77950-u-boot: Remove leading 0x from rpc node

Hi Marek, > -Original Message- > From: Lad Prabhakar > Sent: 18 November 2020 11:29 > To: Marek Vasut ; u-boot@lists.denx.de > Cc: Biju Das ; Prabhakar > ; Prabhakar Mahadev > Lad > Subject: [PATCH 4/8] M: dts: r8a77950-u-boot: Remove leading 0x from rpc node > I missed the typo in

[PATCH 8/8] ARM: dts: r7s72100-gr-peach-u-boot: Remove leading 0x from rpc node

Remove the leading "0x" from rpc node to fix the below dtc warning: Warning (simple_bus_reg): Node /soc/rpc@0xee20 simple-bus unit address format error, expected "ee20" Signed-off-by: Lad Prabhakar --- arch/arm/dts/r7s72100-gr-peach-u-boot.dts | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 7/8] ARM: dts: r8a77970-u-boot: Remove leading 0x from rpc node

Remove the leading "0x" from rpc node to fix the below dtc warning: Warning (simple_bus_reg): Node /soc/rpc@0xee20 simple-bus unit address format error, expected "ee20" Signed-off-by: Lad Prabhakar --- arch/arm/dts/r8a77970-u-boot.dtsi | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 6/8] ARM: dts: r8a77995-u-boot: Remove leading 0x from rpc node

Remove the leading "0x" from rpc node to fix the below dtc warning: Warning (simple_bus_reg): Node /soc/rpc@0xee20 simple-bus unit address format error, expected "ee20" Signed-off-by: Lad Prabhakar --- arch/arm/dts/r8a77995-u-boot.dtsi | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 5/8] ARM: dts: r8a77960-u-boot: Remove leading 0x from rpc node

Remove the leading "0x" from rpc node to fix the below dtc warning: Warning (simple_bus_reg): Node /soc/rpc@0xee20 simple-bus unit address format error, expected "ee20" Signed-off-by: Lad Prabhakar --- arch/arm/dts/r8a77960-u-boot.dtsi | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 4/8] M: dts: r8a77950-u-boot: Remove leading 0x from rpc node

Remove the leading "0x" from rpc node to fix the below dtc warning: Warning (simple_bus_reg): Node /soc/rpc@0xee20 simple-bus unit address format error, expected "ee20" Signed-off-by: Lad Prabhakar --- arch/arm/dts/r8a77950-u-boot.dtsi | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 3/8] ARM: dts: 8a77980-u-boot: Remove leading 0x from rpc node

Remove the leading "0x" from rpc node to fix the below dtc warning: Warning (simple_bus_reg): Node /soc/rpc@0xee20 simple-bus unit address format error, expected "ee20" Signed-off-by: Lad Prabhakar --- arch/arm/dts/r8a77980-u-boot.dtsi | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 2/8] ARM: dts: r8a77990-u-boot: Remove leading 0x from rpc node

Remove the leading "0x" from rpc node to fix the below dtc warning: Warning (simple_bus_reg): Node /soc/rpc@0xee20 simple-bus unit address format error, expected "ee20" Signed-off-by: Lad Prabhakar --- arch/arm/dts/r8a77990-u-boot.dtsi | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 1/8] ARM: dts: r8a77965-u-boot: Remove leading 0x from rpc node

Remove the leading "0x" from rpc node to fix the below dtc warning: Warning (simple_bus_reg): Node /soc/rpc@0xee20 simple-bus unit address format error, expected "ee20" Signed-off-by: Lad Prabhakar --- arch/arm/dts/r8a77965-u-boot.dtsi | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 0/8] Renesas drop leading 0x from rpc nodes

Hi All, This patch series drops leading 0x from rpc nodes. Cheers, Prabhakar Lad Prabhakar (8): ARM: dts: r8a77965-u-boot: Remove leading 0x from rpc node ARM: dts: r8a77990-u-boot: Remove leading 0x from rpc node ARM: dts: 8a77980-u-boot: Remove leading 0x from rpc node M: dts:

[PATCH v3] sunxi: add PineCube board

PineCube is an IP camera development kit released by Pine64. It comes with the following compoents: - A mainboard with Sochip S3 SoC, a 16MByte SPI Flash, AXP209 PMIC, a power-only microUSB connector, a USB Type-A connector, a 10/100Mbps Ethernet port and FPC connectors for camera and daughter

Re: [PATCH 20/26] arm: mach-k3: do board config for PM and RM only if supported

On 17/11/2020 11:22, Tero Kristo wrote: On 17/11/2020 08:14, Lokesh Vutla wrote: On 16/11/20 5:57 pm, Tero Kristo wrote: On 16/11/2020 06:23, Lokesh Vutla wrote: On 10/11/20 2:35 pm, Tero Kristo wrote: If the raw PM support is built in, we are operating in the split firmware approach

Re: [PATCH v2] sunxi: add PineCube board

On 18/11/2020 06:29, Icenowy Zheng wrote: > PineCube is an IP camera development kit released by Pine64. > > It comes with the following compoents: > > - A mainboard with Sochip S3 SoC, a 16MByte SPI Flash, AXP209 PMIC, > a power-only microUSB connector, a USB Type-A connector, a 10/100Mbps >

[PATCH] pinctrl: renesas: Add support for R8A774C0

Renesas RZ/G2E (a.k.a. r8a774c0) is pin compatible with R-Car E3 (a.k.a. r8a77990), however it doesn't have several automotive specific peripherals. This patch hooks R8A774C0 SoC with the pfc driver. Signed-off-by: Lad Prabhakar Reviewed-by: Biju Das --- arch/arm/mach-rmobile/Kconfig.64 | 1

Re: [BUG] U-boot does not detect emmc card in odroid-c2 for newer U-boot as 2020.04

Hei hei, FWIW see below, Am Dienstag, 17. November 2020, 20:08:21 CET schrieb Otto Meier: > Dear Jaehoon Chung, > > I cloned github.com/u-boot which i believe is the master repo. That seems to be an up to date mirror. However, according to [1] and [2] the real upstream repository is here: