Re: [PATCH] arm: mach-snapdragon: pinctrl: Place pin_name in .data section

[Jorge Ramirez-Ortiz, Gmail]

On 06/07/21, Ramon Fried wrote:
> On Mon, Jul 5, 2021 at 3:19 PM Stephan Gerhold  wrote:
> >
> > According to arch/arm/lib/crt0_64.S, the BSS section is "UNAVAILABLE"
> > and uninitialized before relocation. Also, it overlaps with the
> > appended DTB before relocation, so writing data into a variable
> > in the BSS section might corrupt the appended DTB.
> >
> > Unfortunately, pinctrl-apq8016.c and pinctrl-apq8096.c do place the
> > "pin_name" variable in the BSS section (since it's uninitialized).
> > It's also used before relocation, when setting up the pinctrl for
> > the serial driver.
> >
> > On DB410c this causes "GPIO_5" to be written into some part of an
> > appended DTB, e.g.:
> >
> > 80111820: edfe0dd0 9f10 3800 c00e...8
> > 80111830: 2800 1100 1000 ...(
> > 80111840: 4f495047 8800355f  GPIO_5..
> > 80111850:   0100 
> > 80111860: 0300 0400  0200
> > 80111870: 0300 0400 0f00 0200
> > 80111880: 0300 2d00 1b00 6c617551...-Qual
> > 80111890: 6d6d6f63 63655420 6c6f6e68 6569676fcomm Technologie
> >
> > Depending on the part of the DTB that is corrupted this might not
> > cause any problems, but it can also result in strange reboots
> > without any serial output.
> >
> > Fortunately, in practice this does not cause issues on DB410c yet
> > because board_fdt_blob_setup() in dragonboard410c.c currently
> > overrides the appended DTB with the one passed by the previous
> > bootloader (LK) (which does not get corrupted).
> >
> > DB820c does not have board_fdt_blob_setup() so I would expect it to
> > be affected by this problem. Perhaps everyone was just fortunate to
> > not compile an U-Boot configuration where the pin_name corrupts an
> > important part of the DTB.

I'll try to confirm during the week.

After Ramon's pinctrl changes db820c did indeed break - was able to
test a few months back- but we didnt have a board to test back then
(and nobody complained)

will come back to you on this but from what you are saying, this is
probably the fix we needed for db820c


> >
> > Make sure "pin_name" is explicitly placed in the .data section
> > instead of .bss to fix this.
> >
> > Cc: Ramon Fried 
> > Signed-off-by: Stephan Gerhold 
> > ---
> >
> >  arch/arm/mach-snapdragon/pinctrl-apq8016.c | 3 +--
> >  arch/arm/mach-snapdragon/pinctrl-apq8096.c | 2 +-
> >  2 files changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/mach-snapdragon/pinctrl-apq8016.c 
> > b/arch/arm/mach-snapdragon/pinctrl-apq8016.c
> > index 1042b564c3..70c0be0bca 100644
> > --- a/arch/arm/mach-snapdragon/pinctrl-apq8016.c
> > +++ b/arch/arm/mach-snapdragon/pinctrl-apq8016.c
> > @@ -10,7 +10,7 @@
> >  #include 
> >
> >  #define MAX_PIN_NAME_LEN 32
> > -static char pin_name[MAX_PIN_NAME_LEN];
> > +static char pin_name[MAX_PIN_NAME_LEN] __section(".data");
> >  static const char * const msm_pinctrl_pins[] = {
> > "SDC1_CLK",
> > "SDC1_CMD",
> > @@ -59,4 +59,3 @@ struct msm_pinctrl_data apq8016_data = {
> > .get_function_mux = apq8016_get_function_mux,
> > .get_pin_name = apq8016_get_pin_name,
> >  };
> > -
> > diff --git a/arch/arm/mach-snapdragon/pinctrl-apq8096.c 
> > b/arch/arm/mach-snapdragon/pinctrl-apq8096.c
> > index 20a71c319b..45462f01c2 100644
> > --- a/arch/arm/mach-snapdragon/pinctrl-apq8096.c
> > +++ b/arch/arm/mach-snapdragon/pinctrl-apq8096.c
> > @@ -10,7 +10,7 @@
> >  #include 
> >
> >  #define MAX_PIN_NAME_LEN 32
> > -static char pin_name[MAX_PIN_NAME_LEN];
> > +static char pin_name[MAX_PIN_NAME_LEN] __section(".data");
> >  static const char * const msm_pinctrl_pins[] = {
> > "SDC1_CLK",
> > "SDC1_CMD",
> > --
> > 2.32.0
> >
> Reviewed-by: Ramon Fried 

Re: [PATCH] arm: mach-snapdragon: pinctrl: Place pin_name in .data section

[Jorge Ramirez-Ortiz, Gmail]

On 15/07/21, Jorge Ramirez-Ortiz, Gmail wrote:
> On 06/07/21, Ramon Fried wrote:
> > On Mon, Jul 5, 2021 at 3:19 PM Stephan Gerhold  wrote:
> > >
> > > According to arch/arm/lib/crt0_64.S, the BSS section is "UNAVAILABLE"
> > > and uninitialized before relocation. Also, it overlaps with the
> > > appended DTB before relocation, so writing data into a variable
> > > in the BSS section might corrupt the appended DTB.
> > >
> > > Unfortunately, pinctrl-apq8016.c and pinctrl-apq8096.c do place the
> > > "pin_name" variable in the BSS section (since it's uninitialized).
> > > It's also used before relocation, when setting up the pinctrl for
> > > the serial driver.
> > >
> > > On DB410c this causes "GPIO_5" to be written into some part of an
> > > appended DTB, e.g.:
> > >
> > > 80111820: edfe0dd0 9f10 3800 c00e...8
> > > 80111830: 2800 1100 1000 ...(
> > > 80111840: 4f495047 8800355f  GPIO_5..
> > > 80111850:   0100 
> > > 80111860: 0300 0400  0200
> > > 80111870: 0300 0400 0f00 0200
> > > 80111880: 0300 2d00 1b00 6c617551...-Qual
> > > 80111890: 6d6d6f63 63655420 6c6f6e68 6569676fcomm Technologie
> > >
> > > Depending on the part of the DTB that is corrupted this might not
> > > cause any problems, but it can also result in strange reboots
> > > without any serial output.
> > >
> > > Fortunately, in practice this does not cause issues on DB410c yet
> > > because board_fdt_blob_setup() in dragonboard410c.c currently
> > > overrides the appended DTB with the one passed by the previous
> > > bootloader (LK) (which does not get corrupted).
> > >
> > > DB820c does not have board_fdt_blob_setup() so I would expect it to
> > > be affected by this problem. Perhaps everyone was just fortunate to
> > > not compile an U-Boot configuration where the pin_name corrupts an
> > > important part of the DTB.
> 
> I'll try to confirm during the week.
> 
> After Ramon's pinctrl changes db820c did indeed break - was able to
> test a few months back- but we didnt have a board to test back then
> (and nobody complained)
> 
> will come back to you on this but from what you are saying, this is
> probably the fix we needed for db820c


yep, all good. just tested it. thanks for the fix!


U-Boot 2021.07-00467-gc11f5abce8 (Jul 15 2021 - 09:20:22 +0200) 
   
Qualcomm-DragonBoard 820C   
   

   
DRAM:  3 GiB
   
PSCI:  v1.0 
   
MMC:   sdhci@74a4900: 0 
   
Loading Environment from EXT4... MMC: no card present   
   
In:serial@75b   
   
Out:   serial@75b   
   
Err:   serial@75b   
   
Net:   Net Initialization Skipped   
   
No ethernet found.  
   
Hit any key to stop autoboot:  0
   
MMC: no card present
   
dragonboard820c =>
dragonboard820c => bdinfo
boot_params = 0x
DRAM bank   = 0x
-> start= 0x8000
-> size = 0x6000
DRAM bank   = 0x0001
-> start= 0x0001
-> size = 0x5ea4
flashstart  = 0x
flashsize   = 0x
flashoffset = 0x
baudrate= 115200 bps
relocaddr   = 0x00013ff7
reloc off   = 0xbfef
Build   = 64-bit
current eth = unknown
ethaddr = (not set)
IP addr = 
fdt_blob= 0x00013f7673c0
new_fdt = 0x00013f7673c0
fdt_size= 0x0a20
lmb_dump_all:
 memory.cnt  = 0x2
 memory[0]  [0x8000-0xdfff], 0x6000 bytes flags: 0
 memory[1]  [0x1-0x15ea4fffe], 0x5ea4 bytes flags: 0
 reserved.cnt  = 0x1
 reserved[0][0x8630-0x864f], 0x0020 bytes flags: 4
arch_number = 0x
TLB addr= 0x00013fff
irq_sp  = 0x00013f7673b0
sp start= 0x00013f7673b0
Early malloc usage: 5d8 / 2000


> 
> 
> > >
> > > 

Re: [PATCH 1/5] efi_loader: increase eventlog buffer size

[Masahisa Kojima]

On Thu, 15 Jul 2021 at 15:46, Ilias Apalodimas
 wrote:
>
>
> On Thu, Jul 15, 2021 at 02:09:57PM +0900, Masahisa Kojima wrote:
> > Hi Simon, Ilias,
> >
> > On Wed, 14 Jul 2021 at 23:50, Simon Glass  wrote:
> > >
> > > Hi Masahisa,
> > >
> > > On Mon, 12 Jul 2021 at 02:40, Masahisa Kojima
> > >  wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Sun, 11 Jul 2021 at 09:01, Simon Glass  wrote:
> > > > >
> > > > > Hi Masahisa,
> > > > >
> > > > > On Wed, 7 Jul 2021 at 20:21, Masahisa Kojima 
> > > > >  wrote:
> > > > > >
> > > > > > On Wed, 7 Jul 2021 at 22:47, Heinrich Schuchardt 
> > > > > >  wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 7/7/21 3:36 PM, Masahisa Kojima wrote:
> > > > > > > > This is a preperation to add eventlog support
> > > > > > > > described in TCG PC Client PFP spec.
> > > > > > > >
> > > > > > > > Signed-off-by: Masahisa Kojima 
> > > > > > > > ---
> > > > > > > >   lib/efi_loader/Kconfig | 2 +-
> > > > > > > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > > > > > > > index b2ab48a048..a87bf3cc98 100644
> > > > > > > > --- a/lib/efi_loader/Kconfig
> > > > > > > > +++ b/lib/efi_loader/Kconfig
> > > > > > > > @@ -327,7 +327,7 @@ config EFI_TCG2_PROTOCOL
> > > > > > > >   config EFI_TCG2_PROTOCOL_EVENTLOG_SIZE
> > > > > > > >   int "EFI_TCG2_PROTOCOL EventLog size"
> > > > > > > >   depends on EFI_TCG2_PROTOCOL
> > > > > > > > - default 4096
> > > > > > > > + default 16384
> > > > > > >
> > > > > > > I found this text in EDK II:
> > > > > > >
> > > > > > > Minimum length(in bytes) of the system preboot TCG event log 
> > > > > > > area(LAML)
> > > > > > > ---
> > > > > > >
> > > > > > > For PC Client Implementation spec up to and including 1.2 the 
> > > > > > > minimum
> > > > > > > log size is 64KB. (SecurityPkg/SecurityPkg.dec)
> > > > > >
> > > > > > Thank you for your feedback.
> > > > > > I have not checked this.
> > > > > > TCG spec also says "The Log Area Minimum Length for the TCG event 
> > > > > > log
> > > > > > MUST be at least 64KB." in ACPI chapter.
> > > > > > I will update to set 64KB as default.
> > > > > >
> > > > >
> > > > > Is this the same as the BLOBLISTT_TPM2_TCG_LOG thing? If so, can we
> > > > > put this in the bloblist? We want to avoid adding code in EFI which is
> > > > > in U-Boot.
> > > >
> > > > I think bloblist is used for data passing from SPL/TPL to u-boot.
> > >
> > > It can also be used to place things in memory that end up accessed by
> > > Linux, e.g. ACPI tables. So I think it fits.
> >
> > I understand bloblist can be used for eventlog, I will check further.
> >
> > >
> > > > Is your comment saying that the eventlog generated
> > > > in u-boot(done in efi_tcg2.c with this patch series) should be appended
> > > > into the buffer pointed by BLOBLISTT_TPM2_TCG_LOG blob?
> > >
> > > I suppose so, but this logic should be implemented in the TPM layer I
> > > think, not just in EFI. Otherwise we end up with another parallel
> > > implementation.
> >
> > Current u-boot/lib/efi_loader/efi_tcg2.c includes the code
> > not directly related to EFI.
> > I would like to suggest to divide u-boot/lib/efi_loader/efi_tcg2.c
> > into two files.
> >
> >  1)  u-boot/lib/efi_loader/efi_tcg2.c
> >   This file implements the EFI interfaces required in TCG EFI Protocol
> > Specification(https://trustedcomputinggroup.org/resource/tcg-efi-protocol-specification/).
> >
>
> The only problem I see with the way the efi tcg2 eventlog is currently
> created, is that it's all done during the efi init.  Ideally this should
> happen earlier, especially if SPL or TF-A create their own eventlog.
>
> The status with TF-A atm is that it only creates an eventlog which then
> copies to secure and non-secure memory, but it doesnt extend the PCRs.
> We should pick that eventlog from u-boot (or better op-tee), extend the
> PCRs based on the information of the log and then use it as our basis and
> start appending events there.
>
> >  2) u-boot/lib/tcg2.c(new file)
> >  This file implements the functionality required in TCG PC Client
> > Platform Firmware Profile
> > Specification(https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification/).
> >  This file contains the common functions to extend eventlog and PCRs, etc.
>
> Splitting up the pc client spec bits is probably a good idea.
> What do you have in mind? Moving tcg2_pcr_extend() and
> tcg2_agile_log_append() as well, or just the pc client related wrappers?

Sorry but I was confused.
I checked spec again, there are many duplication in TCG EFI Protocol spec
and TCG PC Client PFP spec.
For example,  tdTCG_EfiSpecIdEvent structure is defined in both spec.
On second thought, it is difficult to split the pc client spec into new file,
so I would like to withdraw my suggestion earlier.

Thanks,
Masahis

RE: [EXT] Re: Problem on imx: add rom api support on imx8mn

[Ye Li]

Hi Michael,

> -Original Message-
> From: Michael Nazzareno Trimarchi 
> Sent: Thursday, July 15, 2021 2:52 PM
> To: Peng Fan (OSS) 
> Cc: Peng Fan ; U-Boot-Denx ;
> Stefano Babic ; Ye Li ; Fabio Estevam
> ; Jagan Teki 
> Subject: [EXT] Re: Problem on imx: add rom api support on imx8mn
> 
> Caution: EXT Email
> 
> Hi
> 
> On Thu, Jul 15, 2021 at 8:47 AM Peng Fan (OSS) 
> wrote:
> >
> >
> >
> > On 2021/7/8 17:15, Michael Nazzareno Trimarchi wrote:
> > > Hi Peng
> > >
> > > On Thu, Jul 8, 2021 at 9:12 AM Peng Fan (OSS) 
> wrote:
> > >>
> > >> On 2021/7/4 1:24, Michael Nazzareno Trimarchi wrote:
> > >>> Hi all
> > >>>
> > >>> I have some problems that I have understood and fixed but I can
> > >>> not explain. Right now I have on imx8mn that can boot from boot0
> > >>> or boot1 partition after remove a condition in the
> > >>> is_boot_from_stream_device
> > >>>
> > >>> This is a boot from mmcblk0boot0 with some debug
> > >>>
> > >>> U-Boot SPL 2020.04-5.4.70-2.3.2+gf3bcbdfc62 (Jul 03 2021 -
> > >>> 17:00:27 +) power_bd71837_init
> > >>> DDRINFO: start DRAM init
> > >>> DDRINFO: DRAM rate 1600MTS
> > >>> DDRINFO:ddrphy calibration done
> > >>> DDRINFO: ddrmix config done
> > >>> Normal Boot
> > >>> Trying to boot from BOOTROM
> > >>> ROM API interface 2 from boot 131073
> > >>>
> > >>> Interface is 2 MMC and boot is 131073 and according to this
> > >>>
> > >>> static int is_boot_from_stream_device(u32 boot)
> > >>> +{
> > >>> +   u32 interface;
> > >>> +
> > >>> +   interface = boot >> 16;
> > >>> +   if (interface >= BT_DEV_TYPE_USB)
> > >>> +   return 1;
> > >>> +
> > >>> +   if (interface == BT_DEV_TYPE_MMC && (boot & 1))
> > >>> +   return 1;
> > >>> +
> > >>> +   return 0;
> > >>> +}
> > >>>
> > >>> means a stream interface but it does not boot.
> > >>>
> > >>> Boot from boot1 give 131072 that is boot1 this let device boot
> > >>> because
> > >>
> > >> Who gives 131073? Boot from boot1, you mean emmc boot partition0?
> > >>
> > >>> is_boot_from_stream_device is 0 and romapi use
> > >>> spl_romapi_load_image_seekable
> > >>>
> > >>> Remove boot & 1 condition let me boot from mmcblk0boot0 and
> > >>> mmcblk0boot1 without any problem
> > >>
> > >> Have you enabled emmc fastboot in fuse?
> > >>
> > >> boot & 1 is checking emmc fastboot. emmc fastboot mode is actually
> > >> stream device. If fastboot mode enabled, you need burn your
> > >> flash.bin into offset 0. Not 32KB offset.
> > >
> > > The offset is correct and the spl is starting on boot0 but then it
> > > should load the rest from
> > > boot0 block and not from usb. And why in case of boot1 the 1 is not
> > > present. I flash both on offset 0. Anyway I sent a patch
> >
> > I suspect you have eMMC fastboot enabled for boot0, but not for boot1.
> 
> I think that was fuse this way
> 
> # Alternative Boot ("Fast boot")
> # =>[BT_FUSE_SEL | eMMC boot | USDHC1 EMMC]
> FB: ucmd fuse prog -y 1 3 0x10002A00
> # =>[Fast boot | 8-bit DDR | MMC High speed | 1.8V | eMMC reset enable]
> FB: ucmd fuse prog -y 2 1 0x00E7
> # =>[Fast Boot Ack enable]
> FB: ucmd fuse prog -y 2 2 0x0001
> # boot_bus_width: 2 (8-bit), reset_boot_bus_width: 0, boot_mode: 2 (use dual
> data rate (DDR))
> FB: ucmd mmc bootbus 0 2 0 2
> # boot_ack: 1, boot_partition: 1 (Boot partition 1), 7 (User area),
> partition_access: No access to boot partition (default)
> FB: ucmd mmc partconf 0 1 1 0
> 
> How is it supposed to work in this case?
> 

Above settings use the boot0 for fastboot. When you switch to boot1 for 
fastboot, did you change the 
partconf setting to "mmc partconf 0 1 2 0"?

If the ROM boots from emmc fastboot, it will set the bit0 to 1 to indicate the 
fastboot. Since at this time, ROM
does not leave fastboot (just stop the clock), we should continue the stream 
mode read in SPL for FIT image load. 
So below checking is correct.  If you continue the stream mode read, what is 
the failure do you meet?
The codes will read max 640KB data from ROM to search to FIT header. Can it get 
the header or not?

if (interface == BT_DEV_TYPE_MMC && (boot & 1))
return 1;

Best regards,
Ye Li

> Michael
> 
> 
> 
> >
> > Regards,
> > Peng.
> >
> > >
> > > Michael
> > >
> > >>
> > >> Regards,
> > >> Peng.
> > >>
> > >>>
> > >>> mmc partconf 0
> > >>> EXT_CSD[179], PARTITION_CONFIG:
> > >>> BOOT_ACK: 0x0
> > >>> BOOT_PARTITION_ENABLE: 0x1
> > >>> PARTITION_ACCESS: 0x0
> > >>>
> > >>> and the board was fused already.
> > >>>
> > >>> Any idea why?
> > >>>
> > >>> Michael
> > >>>
> > >
> > >
> > >
> 
> 
> 
> --
> Michael Nazzareno Trimarchi
> Co-Founder & Chief Executive Officer
> M. +39 347 913 2170
> mich...@amarulasolutions.com
> __
> 
> Amarula Solutions BV
> Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172
> i...@amarulasolutions.com
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ama
> rulasolutions.com%2F&data=04%7C01%7Cye.li%40nxp.com%7

Re: [RFC 1/7] ARM: mvebu: a38x: Correct mismatched bound warnings

[Stefan Roese]

Hi Pali,
Hi Kosta,

On 14.07.21 22:52, Pali Rohár wrote:

On Monday 03 May 2021 16:48:53 Tom Rini wrote:

With gcc-11 we see:
drivers/ddr/marvell/a38x/ddr3_debug.c:672:47: error: argument 2 of type 
'u32[5]' {aka 'unsigned int[5]'} with mismatched bound 
[-Werror=array-parameter=]
   672 | int ddr3_tip_read_adll_value(u32 dev_num, u32 
pup_values[MAX_INTERFACE_NUM * MAX_BUS_NUM],
   |   
^~~
In file included from drivers/ddr/marvell/a38x/ddr3_training_ip_engine.h:10,
  from drivers/ddr/marvell/a38x/ddr3_init.h:17,
  from drivers/ddr/marvell/a38x/ddr3_debug.c:6:
drivers/ddr/marvell/a38x/ddr3_training_ip_flow.h:116:47: note: previously 
declared as 'u32[]' {aka 'unsigned int[]'}

And similar warnings.  Correct these by updating the prototype.  Remove
the prototype for ddr3_tip_read_pup_value as it is unused.

Signed-off-by: Tom Rini 
---
  drivers/ddr/marvell/a38x/ddr3_training_ip_flow.h | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/ddr/marvell/a38x/ddr3_training_ip_flow.h 
b/drivers/ddr/marvell/a38x/ddr3_training_ip_flow.h
index ab152cb455e9..55832a55405b 100644
--- a/drivers/ddr/marvell/a38x/ddr3_training_ip_flow.h
+++ b/drivers/ddr/marvell/a38x/ddr3_training_ip_flow.h
@@ -8,6 +8,7 @@
  
  #include "ddr3_training_ip.h"

  #include "ddr3_training_ip_db.h"
+#include "mv_ddr_plat.h"
  
  #define KILLER_PATTERN_LENGTH		32

  #define EXT_ACCESS_BURST_LENGTH   8
@@ -112,9 +113,12 @@ int ddr3_tip_configure_odpg(u32 dev_num, enum 
hws_access_type access_type,
  int ddr3_tip_write_mrs_cmd(u32 dev_num, u32 *cs_mask_arr, enum mr_number 
mr_num, u32 data, u32 mask);
  int ddr3_tip_write_cs_result(u32 dev_num, u32 offset);
  int ddr3_tip_reset_fifo_ptr(u32 dev_num);
-int ddr3_tip_read_pup_value(u32 dev_num, u32 pup_values[], int reg_addr, u32 
mask);
-int ddr3_tip_read_adll_value(u32 dev_num, u32 pup_values[], u32 reg_addr, u32 
mask);
-int ddr3_tip_write_adll_value(u32 dev_num, u32 pup_values[], u32 reg_addr);
+int ddr3_tip_read_adll_value(u32 dev_num,
+u32 pup_values[MAX_INTERFACE_NUM * MAX_BUS_NUM],
+u32 reg_addr, u32 mask);
+int ddr3_tip_write_adll_value(u32 dev_num,
+ u32 pup_values[MAX_INTERFACE_NUM * MAX_BUS_NUM],
+ u32 reg_addr);
  int ddr3_tip_tune_training_params(u32 dev_num, struct tune_train_params 
*params);
  
  #endif /* _DDR3_TRAINING_IP_FLOW_H_ */


CC Stefan, Marek, Konstantin

Could you please send this patch to upstream?
https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell

Any change done in drivers/ddr/marvell/a38x cause issue in
future code synchronization with upstream repository.


Sure. It absolutely makes sense to try to keep these repo's at least
a bit in sync.

Kosta, could you please apply this patch to your "mv-ddr-marvell"
repo as well?

Thanks,
Stefan

Re: [PATCH 1/3] arm: mvebu: Espressobin: Fix setting $fdtfile env

[Stefan Roese]

On 14.07.21 16:37, Pali Rohár wrote:

Ensure that 'env default -a' always set correct value to $fdtfile, even
when custom user variable is already stored in non-volatile env storage
(means that env_get("fdtfile") call returns non-NULL value).

As default value is now correctly set like if specified at compile time in
CONFIG_EXTRA_ENV_SETTINGS, there is no need to set $fdtfile explicitly via
env_set("fdtfile", ...) call.

So remove wrong skip based on env_get("fdtfile") and then also unneeded
env_set("fdtfile", ...) call.

Fixes: c4df0f6f315c ("arm: mvebu: Espressobin: Set default value for $fdtfile env 
variable")
Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  board/Marvell/mvebu_armada-37xx/board.c | 7 ---
  1 file changed, 7 deletions(-)

diff --git a/board/Marvell/mvebu_armada-37xx/board.c 
b/board/Marvell/mvebu_armada-37xx/board.c
index 6a0e2fc3cd8f..53408d37af9b 100644
--- a/board/Marvell/mvebu_armada-37xx/board.c
+++ b/board/Marvell/mvebu_armada-37xx/board.c
@@ -133,9 +133,6 @@ int board_late_init(void)
device_unbind(dev);
}
  
-	if (env_get("fdtfile"))

-   return 0;
-
/* Ensure that 'env default -a' set correct value to $fdtfile */
if (ddr4 && emmc)
strcpy(ptr, 
"fdtfile=marvell/armada-3720-espressobin-v7-emmc.dtb");
@@ -146,10 +143,6 @@ int board_late_init(void)
else
strcpy(ptr, "fdtfile=marvell/armada-3720-espressobin.dtb");
  
-	/* If $fdtfile was not set explicitly by user then set default value */

-   if (!env_get("fdtfile"))
-   env_set("fdtfile", ptr + sizeof("fdtfile="));
-
return 0;
  }
  #endif




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH 2/3] arm: mvebu: Espressobin: Use function mmc_get_op_cond() for detecting eMMC

[Stefan Roese]

On 14.07.21 16:37, Pali Rohár wrote:

Use function mmc_get_op_cond() instead of mmc_init() for detecting presence
of eMMC. Documentation for this function says that it could be used to
detect the presence of SD/eMMC when no card detect logic is available.

This function is also used by mx6cuboxi board for detecting presence of eMMC.

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  board/Marvell/mvebu_armada-37xx/board.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/Marvell/mvebu_armada-37xx/board.c 
b/board/Marvell/mvebu_armada-37xx/board.c
index 53408d37af9b..6086996b8062 100644
--- a/board/Marvell/mvebu_armada-37xx/board.c
+++ b/board/Marvell/mvebu_armada-37xx/board.c
@@ -124,7 +124,7 @@ int board_late_init(void)
  
  	/* eMMC is mmc dev num 1 */

mmc_dev = find_mmc_device(1);
-   emmc = (mmc_dev && mmc_init(mmc_dev) == 0);
+   emmc = (mmc_dev && mmc_get_op_cond(mmc_dev) == 0);
  
  	/* if eMMC is not present then remove it from DM */

if (!emmc && mmc_dev) {




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH 3/3] mmc: mmc_get_op_cond: Allow quiet detection of eMMC

[Stefan Roese]

On 14.07.21 16:37, Pali Rohár wrote:

Add a new 'quiet' argument to mmc_get_op_cond() function which avoids
printing error message when SD/eMMC card is not detected.

Espressobin and mx6cuboxi boards use this function for detecting presence
of eMMC and therefore it is expected and normal that eMMC does not have to
be connected. So error message "Card did not respond to voltage select!"
should be skipped in this case as it is not an error.

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  board/Marvell/mvebu_armada-37xx/board.c | 2 +-
  board/solidrun/mx6cuboxi/mx6cuboxi.c| 2 +-
  drivers/mmc/mmc.c   | 7 ---
  include/mmc.h   | 3 ++-
  4 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/board/Marvell/mvebu_armada-37xx/board.c 
b/board/Marvell/mvebu_armada-37xx/board.c
index 6086996b8062..fdc873b1952f 100644
--- a/board/Marvell/mvebu_armada-37xx/board.c
+++ b/board/Marvell/mvebu_armada-37xx/board.c
@@ -124,7 +124,7 @@ int board_late_init(void)
  
  	/* eMMC is mmc dev num 1 */

mmc_dev = find_mmc_device(1);
-   emmc = (mmc_dev && mmc_get_op_cond(mmc_dev) == 0);
+   emmc = (mmc_dev && mmc_get_op_cond(mmc_dev, true) == 0);
  
  	/* if eMMC is not present then remove it from DM */

if (!emmc && mmc_dev) {
diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c 
b/board/solidrun/mx6cuboxi/mx6cuboxi.c
index 3eadc38f6fd4..6207bf8253ab 100644
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
@@ -374,7 +374,7 @@ static bool has_emmc(void)
mmc = find_mmc_device(2);
if (!mmc)
return 0;
-   return (mmc_get_op_cond(mmc) < 0) ? 0 : 1;
+   return (mmc_get_op_cond(mmc, true) < 0) ? 0 : 1;
  }
  
  int checkboard(void)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 1e83007286b2..8078a89f18cb 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -2766,7 +2766,7 @@ static int mmc_power_cycle(struct mmc *mmc)
return mmc_power_on(mmc);
  }
  
-int mmc_get_op_cond(struct mmc *mmc)

+int mmc_get_op_cond(struct mmc *mmc, bool quiet)
  {
bool uhs_en = supports_uhs(mmc->cfg->host_caps);
int err;
@@ -2842,7 +2842,8 @@ retry:
  
  		if (err) {

  #if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
-   pr_err("Card did not respond to voltage select! : 
%d\n", err);
+   if (!quiet)
+   pr_err("Card did not respond to voltage select! : 
%d\n", err);
  #endif
return -EOPNOTSUPP;
}
@@ -2882,7 +2883,7 @@ int mmc_start_init(struct mmc *mmc)
return -ENOMEDIUM;
}
  
-	err = mmc_get_op_cond(mmc);

+   err = mmc_get_op_cond(mmc, false);
  
  	if (!err)

mmc->init_in_progress = 1;
diff --git a/include/mmc.h b/include/mmc.h
index 6f943e78b740..0bf19de20e52 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -900,9 +900,10 @@ int mmc_set_bkops_enable(struct mmc *mmc);
   * the presence of SD/eMMC when no card detect logic is available.
   *
   * @param mmc Pointer to a MMC device struct
+ * @param quietBe quiet, do not print error messages when card is not 
detected.
   * @return 0 on success, <0 on error.
   */
-int mmc_get_op_cond(struct mmc *mmc);
+int mmc_get_op_cond(struct mmc *mmc, bool quiet);
  
  /**

   * Start device initialization and return immediately; it does not block on




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH v3 3/4] NSA310S : Use Ethernet PHY name from device tree

[Stefan Roese]

Hi Tony,

On 15.07.21 03:11, Tony Dinh wrote:

Hi Stefan,

I will need to resend this patch (V3 3/4).


Ok. Please add the patch version and history back into the patches
next time again.

Thanks,
Stefan


Thanks,
Tony

On Wed, Jul 7, 2021 at 2:07 AM Tony Dinh > wrote:


In DM Ethernet, the old "egiga0" name is no longer valid, so replace it
with Ethernet PHY name from device tree. Also, Ethernet PHY address
is available so read it from device tree.

Signed-off-by: Tony Dinh mailto:mibo...@gmail.com>>
---

Changes in v3:
- Get eth0 PHY address from device tree

Changes in v2:
- Correct copyright

  board/zyxel/nsa310s/nsa310s.c | 47 +--
  1 file changed, 39 insertions(+), 8 deletions(-)

diff --git a/board/zyxel/nsa310s/nsa310s.c
b/board/zyxel/nsa310s/nsa310s.c
index cd4a7723b1..b71de4e11f 100644
--- a/board/zyxel/nsa310s/nsa310s.c
+++ b/board/zyxel/nsa310s/nsa310s.c
@@ -1,8 +1,7 @@
  // SPDX-License-Identifier: GPL-2.0+
  /*
- * Copyright (C) 2015
- * Gerald Kerma mailto:drea...@doukki.net>>
- * Tony Dinh mailto:mibo...@gmail.com>>
+ * Copyright (C) 2015, 2021 Tony Dinh mailto:mibo...@gmail.com>>
+ * Copyright (C) 2015 Gerald Kerma mailto:drea...@doukki.net>>
   */

  #include 
@@ -81,21 +80,51 @@ int board_init(void)
         return 0;
  }

+static int fdt_get_phy_addr(const char *path)
+{
+       const void *fdt = gd->fdt_blob;
+       const u32 *reg;
+       const u32 *val;
+       int node, phandle, addr;
+
+       /* Find the node by its full path */
+       node = fdt_path_offset(fdt, path);
+       if (node >= 0) {
+               /* Look up phy-handle */
+               val = fdt_getprop(fdt, node, "phy-handle", NULL);
+               if (val) {
+                       phandle = fdt32_to_cpu(*val);
+                       if (!phandle)
+                               return -1;
+                       /* Follow it to its node */
+                       node = fdt_node_offset_by_phandle(fdt, phandle);
+                       if (node) {
+                               /* Look up reg */
+                               reg = fdt_getprop(fdt, node, "reg",
NULL);
+                               if (reg) {
+                                       addr = fdt32_to_cpu(*reg);
+                                       return addr;
+                               }
+                       }
+               }
+       }
+       return -1;
+}
+
  #ifdef CONFIG_RESET_PHY_R
  void reset_phy(void)
  {
         u16 reg;
         u16 phyaddr;
-       char *name = "egiga0";
+       char *name = "ethernet-controller@72000";
+       char *eth0_path =
"/ocp@f100/ethernet-controller@72000/ethernet0-port@0";

         if (miiphy_set_current_dev(name))
                 return;

-       /* read PHY dev address */
-       if (miiphy_read(name, 0xee, 0xee, (u16 *) &phyaddr)) {
-               printf("could not read PHY dev address\n");
+       phyaddr = fdt_get_phy_addr(eth0_path);
+       if (phyaddr < 0)
                 return;
-       }

         /* set RGMII delay */
         miiphy_write(name, phyaddr, MV88E1318_PGADR_REG,
MV88E1318_MAC_CTRL_PG);
@@ -131,5 +160,7 @@ void reset_phy(void)
         /* downshift */
         miiphy_write(name, phyaddr, 0x10, 0x3860);
         miiphy_write(name, phyaddr, 0x0, 0x9140);
+
+       printf("MV88E1318 PHY initialized on %s\n", name);
  }
  #endif /* CONFIG_RESET_PHY_R */
-- 
2.20.1





Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH v3 3/4] NSA310S : Use Ethernet PHY name from device tree

[Stefan Roese]

On 15.07.21 10:05, Stefan Roese wrote:

Hi Tony,

On 15.07.21 03:11, Tony Dinh wrote:

Hi Stefan,

I will need to resend this patch (V3 3/4).


Ok. Please add the patch version and history back into the patches
next time again.


Also, when re-sending please include the already collected tags into
the patches (Reviewed-by, Acked-by etc), if the patch has not changed
too much.

Thanks,
Stefan


Thanks,
Stefan


Thanks,
Tony

On Wed, Jul 7, 2021 at 2:07 AM Tony Dinh > wrote:


    In DM Ethernet, the old "egiga0" name is no longer valid, so 
replace it

    with Ethernet PHY name from device tree. Also, Ethernet PHY address
    is available so read it from device tree.

    Signed-off-by: Tony Dinh >

    ---

    Changes in v3:
    - Get eth0 PHY address from device tree

    Changes in v2:
    - Correct copyright

  board/zyxel/nsa310s/nsa310s.c | 47 
+--

  1 file changed, 39 insertions(+), 8 deletions(-)

    diff --git a/board/zyxel/nsa310s/nsa310s.c
    b/board/zyxel/nsa310s/nsa310s.c
    index cd4a7723b1..b71de4e11f 100644
    --- a/board/zyxel/nsa310s/nsa310s.c
    +++ b/board/zyxel/nsa310s/nsa310s.c
    @@ -1,8 +1,7 @@
  // SPDX-License-Identifier: GPL-2.0+
  /*
    - * Copyright (C) 2015
    - * Gerald Kerma mailto:drea...@doukki.net>>
    - * Tony Dinh mailto:mibo...@gmail.com>>
    + * Copyright (C) 2015, 2021 Tony Dinh mailto:mibo...@gmail.com>>
    + * Copyright (C) 2015 Gerald Kerma mailto:drea...@doukki.net>>
   */

  #include 
    @@ -81,21 +80,51 @@ int board_init(void)
         return 0;
  }

    +static int fdt_get_phy_addr(const char *path)
    +{
    +       const void *fdt = gd->fdt_blob;
    +       const u32 *reg;
    +       const u32 *val;
    +       int node, phandle, addr;
    +
    +       /* Find the node by its full path */
    +       node = fdt_path_offset(fdt, path);
    +       if (node >= 0) {
    +               /* Look up phy-handle */
    +               val = fdt_getprop(fdt, node, "phy-handle", NULL);
    +               if (val) {
    +                       phandle = fdt32_to_cpu(*val);
    +                       if (!phandle)
    +                               return -1;
    +                       /* Follow it to its node */
    +                       node = fdt_node_offset_by_phandle(fdt, 
phandle);

    +                       if (node) {
    +                               /* Look up reg */
    +                               reg = fdt_getprop(fdt, node, "reg",
    NULL);
    +                               if (reg) {
    +                                       addr = fdt32_to_cpu(*reg);
    +                                       return addr;
    +                               }
    +                       }
    +               }
    +       }
    +       return -1;
    +}
    +
  #ifdef CONFIG_RESET_PHY_R
  void reset_phy(void)
  {
         u16 reg;
         u16 phyaddr;
    -       char *name = "egiga0";
    +       char *name = "ethernet-controller@72000";
    +       char *eth0_path =
    "/ocp@f100/ethernet-controller@72000/ethernet0-port@0";

         if (miiphy_set_current_dev(name))
                 return;

    -       /* read PHY dev address */
    -       if (miiphy_read(name, 0xee, 0xee, (u16 *) &phyaddr)) {
    -               printf("could not read PHY dev address\n");
    +       phyaddr = fdt_get_phy_addr(eth0_path);
    +       if (phyaddr < 0)
                 return;
    -       }

         /* set RGMII delay */
         miiphy_write(name, phyaddr, MV88E1318_PGADR_REG,
    MV88E1318_MAC_CTRL_PG);
    @@ -131,5 +160,7 @@ void reset_phy(void)
         /* downshift */
         miiphy_write(name, phyaddr, 0x10, 0x3860);
         miiphy_write(name, phyaddr, 0x0, 0x9140);
    +
    +       printf("MV88E1318 PHY initialized on %s\n", name);
  }
  #endif /* CONFIG_RESET_PHY_R */
    --     2.20.1




Viele Grüße,
Stefan




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH V2 00/46] imx: add i.MX8ULP support

[Stefano Babic]

Hi Peng,

On 15.07.21 05:29, Peng Fan (OSS) wrote:

All,

If no objection to this patchset, I'll send a PR to Stefano's repo
in Friday this week. We will come out more update in rc[x]



No need - I am already on the way to merge them. TODO for next weekend.

I plan to merge this big chunk, too, before sending my PR to Tom, and 
also integrating some other patches that required just some refinements.


Regards,
Stefano


Thanks,
Peng.
On 2021/6/29 10:31, Peng Fan (OSS) wrote:

From: Peng Fan 

V2:
  Rebased and test on new revision silicon with upower included.

The i.MX 8ULP crossover applications processor family brings
ultra-low power processing and advanced integrated security with
EdgeLockTM secure enclave to the intelligent edge.

It includes an uPower core for handling power related functions.

This patchset is to add initial support for i.MX8ULP, with
core soc functions, clock, dtsi, and evk board.

Breno Lima (2):
   mx7ulp: Update unlock and refresh sequences in sWDOG driver
   mx7ulp: wdog: Wait for WDOG unlock and reconfiguration to complete

Peng Fan (24):
   arm: imx: add i.MX8ULP basic Kconfig option
   arm: imx: add i.MX8ULP cpu type and helper
   arm: imx: sys_proto: move boot mode define to common header
   arm: imx8ulp: support print cpu info
   imx: imx8ulp: add get reset cause
   arm: imx: basic i.MX8ULP support
   arm: imx: parse-container: guard included header files
   arm: imx: move container Kconfig under mach-imx
   net: fec_mxc: support i.MX8ULP
   driver: serial: fsl_lpuart: support i.MX8ULP
   arm: imx8ulp: add clock support
   drivers: mmc: fsl_esdhc_imx: support i.MX8ULP
   arm: imx8ulp: disable wdog3
   arm: imx8ulp: add rdc support
   arm: imx8ulp: add trdc release request
   arm: imx8ulp: release trdc and assign lpav from RTD to APD
   imx8ulp: unify rdc functions
   arm: imx8ulp: add dummy imx_get_mac_from_fuse
   arm: imx8ulp: add iomuxc support
   imx8ulp: soc: correct reset cause
   imx8ulp: move struct mu_type to common header
   imx8ulp: add upower api support
   arm: dts: add i.MX8ULP dtsi
   arm: imx: add i.MX8ULP EVK support

Ye Li (20):
   arm: imx8: Move container parser and image to mach-imx common folder
   arm: imx8: Move container image header file to mach-imx
   arm: imx8ulp: add container support
   driver: misc: Add MU and S400 API to communicate with Sentinel
   pinctrl: Add pinctrl driver for imx8ulp
   arm: imx8ulp: soc: Change to use CMC1 to get bootcfg
   arm: imx8ulp: Enable full L2 cache in SPL
   arm: imx8ulp: Update the reset vector in u-boot
   drivers: misc: s400_api: Update S400_SUCCESS_IND to 0xd6
   drivers: misc: imx8ulp: Add S400 API for image authentication
   drivers: misc: imx8ulp: Update S400 API for release RDC
   drivers: misc: s400_api: Update API for fuse read and write
   arm: imx8ulp: release and configure XRDC at early phase
   arm: imx8ulp: Probe the S400 MU device in arch init
   arm: iMX8ULP: Add boot device relevant functions
   arm: imx8ulp: Allocate DCNANO and MIPI_DSI to AD domain
   driver: misc: imx8ulp: Add fuse driver for imx8ulp
   imx8ulp: Use DGO_GP5 to get boot config
   imx8ulp: Add workaround for eMMC boot
   ddr: Add DDR driver for iMX8ULP

  arch/arm/Kconfig  |   10 +
  arch/arm/Makefile |    4 +-
  arch/arm/dts/Makefile |    3 +
  arch/arm/dts/imx8ulp-evk-u-boot.dtsi  |   40 +
  arch/arm/dts/imx8ulp-evk.dts  |  223 
  arch/arm/dts/imx8ulp-pinfunc.h    |  978 ++
  arch/arm/dts/imx8ulp.dtsi |  728 +++
  arch/arm/include/asm/arch-imx/cpu.h   |    4 +
  arch/arm/include/asm/arch-imx8ulp/cgc.h   |  130 ++
  arch/arm/include/asm/arch-imx8ulp/clock.h |   41 +
  arch/arm/include/asm/arch-imx8ulp/ddr.h   |   38 +
  arch/arm/include/asm/arch-imx8ulp/gpio.h  |   20 +
  arch/arm/include/asm/arch-imx8ulp/imx-regs.h  |  162 +++
  .../include/asm/arch-imx8ulp/imx8ulp-pins.h   |   60 +
  arch/arm/include/asm/arch-imx8ulp/iomux.h |   82 ++
  arch/arm/include/asm/arch-imx8ulp/mu_hal.h    |   12 +
  arch/arm/include/asm/arch-imx8ulp/pcc.h   |  139 ++
  arch/arm/include/asm/arch-imx8ulp/rdc.h   |   27 +
  arch/arm/include/asm/arch-imx8ulp/s400_api.h  |   41 +
  arch/arm/include/asm/arch-imx8ulp/sys_proto.h |   19 +
  arch/arm/include/asm/arch-imx8ulp/upower.h    |   15 +
  arch/arm/include/asm/arch-mx7ulp/sys_proto.h  |    9 -
  arch/arm/include/asm/global_data.h    |    5 +
  .../asm/{arch-imx8 => mach-imx}/image.h   |    2 +
  arch/arm/include/asm/mach-imx/sys_proto.h |   13 +-
  arch/arm/mach-imx/Kconfig |   15 +-
  arch/arm/mach-imx/Makefile    |    5 +
  arch/arm/mach-imx/cmd_dek.c   |    2 +-
  .../{imx8/image.c => image-container.c}   |   51 +-
  arch/arm/mach-imx/imx8/Kconfig    |   13 -
  arch/arm/mach-imx/imx8/Makefile   |    3 -

Re: [PATCH u-boot-mvebu 1/2] arm: mvebu: turris_omnia: force 40 MHz speed on SPI NOR

[Stefan Roese]

On 09.07.21 16:56, Marek Behún wrote:

Commit e2e95e5e2542 ("spi: Update speed/mode on change") changed the
boot time on Turris Omnia from ~2.3s to over 8s, due to SPL loading main
U-Boot from SPI NOR at 1 MHz instead of 40 MHz.

This is because the SPL code passes the CONFIG_SF_DEFAULT_SPEED option
to spi_flash_probe(), and with the above commit spi_flash_probe() starts
prefering this parameter instead of the one specified in device-tree.

The proper solution here would probably be to fix the SF subsystem to
prefer the frequency specified in the device-tree, if it is present, but
I am not sure what else will be affected on other boards with such a
change. So until then we need a more simple fix.

Since the CONFIG_SF_DEFAULT_SPEED option is used by the code, put the
correct value there for Turris Omnia. Also put the correct value to
CONFIG_SF_DEFAULT_MODE and use 40 MHz when reading environment.

Signed-off-by: Marek Behún 
Cc: Stefan Roese 
Cc: Tom Rini 
Cc: Marek Vasut 
Cc: Jagan Teki 
Cc: Patrick Delaunay 
Cc: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  configs/turris_omnia_defconfig | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig
index 57ab384f63..ec2294699f 100644
--- a/configs/turris_omnia_defconfig
+++ b/configs/turris_omnia_defconfig
@@ -56,7 +56,7 @@ CONFIG_CMD_FS_UUID=y
  # CONFIG_SPL_PARTITION_UUIDS is not set
  CONFIG_ENV_OVERWRITE=y
  CONFIG_USE_ENV_SPI_MAX_HZ=y
-CONFIG_ENV_SPI_MAX_HZ=5000
+CONFIG_ENV_SPI_MAX_HZ=4000
  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
  CONFIG_SPL_OF_TRANSLATE=y
  CONFIG_AHCI_PCI=y
@@ -67,6 +67,8 @@ CONFIG_MMC_SDHCI=y
  CONFIG_MMC_SDHCI_MV=y
  CONFIG_SPI_FLASH_MACRONIX=y
  CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SF_DEFAULT_MODE=0x0
+CONFIG_SF_DEFAULT_SPEED=4000
  CONFIG_PHY_MARVELL=y
  CONFIG_PHY_GIGE=y
  CONFIG_MVNETA=y




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH u-boot-mvebu 2/2] arm: mvebu: turris_{omnia,mox}: enable MTD command

[Stefan Roese]

On 09.07.21 16:56, Marek Behún wrote:

Now that the MTD subsystem properly supports OF partitions of a SPI NOR,
we can enable the MTD command and start using it instead of the
deprecated sf command.

Signed-off-by: Marek Behún 
Cc: Stefan Roese 
Cc: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  configs/turris_mox_defconfig   | 3 +++
  configs/turris_omnia_defconfig | 4 
  2 files changed, 7 insertions(+)

diff --git a/configs/turris_mox_defconfig b/configs/turris_mox_defconfig
index 2c6f4938db..34127dc3e6 100644
--- a/configs/turris_mox_defconfig
+++ b/configs/turris_mox_defconfig
@@ -31,6 +31,7 @@ CONFIG_CMD_CLK=y
  CONFIG_CMD_GPIO=y
  CONFIG_CMD_I2C=y
  CONFIG_CMD_MMC=y
+CONFIG_CMD_MTD=y
  CONFIG_CMD_PCI=y
  CONFIG_CMD_SPI=y
  CONFIG_CMD_USB=y
@@ -60,12 +61,14 @@ CONFIG_MMC_SDHCI=y
  CONFIG_MMC_SDHCI_SDMA=y
  CONFIG_MMC_SDHCI_XENON=y
  CONFIG_MTD=y
+CONFIG_DM_MTD=y
  CONFIG_SF_DEFAULT_MODE=0
  CONFIG_SF_DEFAULT_SPEED=2000
  CONFIG_SPI_FLASH_MACRONIX=y
  CONFIG_SPI_FLASH_SPANSION=y
  CONFIG_SPI_FLASH_STMICRO=y
  CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_SPI_FLASH_MTD=y
  CONFIG_PHY_MARVELL=y
  CONFIG_PHY_GIGE=y
  CONFIG_MVNETA=y
diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig
index ec2294699f..f860cf5e7d 100644
--- a/configs/turris_omnia_defconfig
+++ b/configs/turris_omnia_defconfig
@@ -41,6 +41,7 @@ CONFIG_CMD_LZMADEC=y
  CONFIG_CMD_GPIO=y
  CONFIG_CMD_I2C=y
  CONFIG_CMD_MMC=y
+CONFIG_CMD_MTD=y
  CONFIG_CMD_PCI=y
  CONFIG_CMD_SATA=y
  CONFIG_CMD_SPI=y
@@ -65,8 +66,11 @@ CONFIG_AHCI_MVEBU=y
  CONFIG_DM_PCA953X=y
  CONFIG_MMC_SDHCI=y
  CONFIG_MMC_SDHCI_MV=y
+CONFIG_MTD=y
+CONFIG_DM_MTD=y
  CONFIG_SPI_FLASH_MACRONIX=y
  CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_MTD=y
  CONFIG_SF_DEFAULT_MODE=0x0
  CONFIG_SF_DEFAULT_SPEED=4000
  CONFIG_PHY_MARVELL=y




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH v2 3/6] efi_loader: add boot variable measurement

[Masahisa Kojima]

On Thu, 15 Jul 2021 at 15:59, Heinrich Schuchardt  wrote:
>
>
>
> On 7/14/21 3:00 PM, Masahisa Kojima wrote:
> > TCG PC Client PFP spec requires to measure "Boot"
> > and "BootOrder" variables, EV_SEPARATOR event prior
> > to the Ready to Boot invocation.
> > Since u-boot does not implement Ready to Boot event,
> > these measurements are performed when efi_start_image() is called.
> >
> > TCG spec also requires to measure "Calling EFI Application from
> > Boot Option" for each boot attempt, and "Returning from EFI
> > Application from Boot Option" if a boot device returns control
> > back to the Boot Manager.
> >
> > Signed-off-by: Masahisa Kojima 
> > ---
> >
> > Changes in v2:
> > - use efi_create_indexed_name() for "Boot" variable
> >
> >   include/efi_loader.h  |   4 ++
> >   include/tpm-v2.h  |  18 -
> >   lib/efi_loader/efi_boottime.c |  20 ++
> >   lib/efi_loader/efi_tcg2.c | 121 ++
> >   4 files changed, 162 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index b81180cfda..703b675950 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -407,6 +407,10 @@ efi_status_t efi_run_image(void *source_buffer, 
> > efi_uintn_t source_size);
> >   efi_status_t efi_init_variables(void);
> >   /* Notify ExitBootServices() is called */
> >   void efi_variables_boot_exit_notify(void);
> > +/* Measure efi application invocation */
> > +efi_status_t EFIAPI efi_tcg2_measure_efi_app_invocation(void);
> > +/* Measure efi application exit */
> > +efi_status_t EFIAPI efi_tcg2_measure_efi_app_exit(void);
> >   /* Called by bootefi to initialize root node */
> >   efi_status_t efi_root_node_register(void);
> >   /* Called by bootefi to initialize runtime */
> > diff --git a/include/tpm-v2.h b/include/tpm-v2.h
> > index 247b386967..325c73006e 100644
> > --- a/include/tpm-v2.h
> > +++ b/include/tpm-v2.h
> > @@ -73,7 +73,7 @@ struct udevice;
> >   /*
> >* event types, cf.
> >* "TCG PC Client Platform Firmware Profile Specification", Family "2.0"
> > - * rev 1.04, June 3, 2019
> > + * Level 00 Version 1.05 Revision 23, May 7, 2021
> >*/
> >   #define EV_EFI_EVENT_BASE   ((u32)0x8000)
> >   #define EV_EFI_VARIABLE_DRIVER_CONFIG   ((u32)0x8001)
> > @@ -85,8 +85,24 @@ struct udevice;
> >   #define EV_EFI_ACTION   ((u32)0x8007)
> >   #define EV_EFI_PLATFORM_FIRMWARE_BLOB   ((u32)0x8008)
> >   #define EV_EFI_HANDOFF_TABLES   ((u32)0x8009)
> > +#define EV_EFI_PLATFORM_FIRMWARE_BLOB2   ((u32)0x800A)
> > +#define EV_EFI_HANDOFF_TABLES2   ((u32)0x800B)
> > +#define EV_EFI_VARIABLE_BOOT2((u32)0x800C)
> >   #define EV_EFI_HCRTM_EVENT  ((u32)0x8010)
> >   #define EV_EFI_VARIABLE_AUTHORITY   ((u32)0x80E0)
> > +#define EV_EFI_SPDM_FIRMWARE_BLOB((u32)0x80E1)
> > +#define EV_EFI_SPDM_FIRMWARE_CONFIG  ((u32)0x80E2)
> > +
> > +#define EFI_CALLING_EFI_APPLICATION \
> > + "Calling EFI Application from Boot Option"
> > +#define EFI_RETURNING_FROM_EFI_APPLICATION  \
> > + "Returning from EFI Application from Boot Option"
> > +#define EFI_EXIT_BOOT_SERVICES_INVOCATION   \
> > + "Exit Boot Services Invocation"
> > +#define EFI_EXIT_BOOT_SERVICES_FAILED   \
> > + "Exit Boot Services Returned with Failure"
> > +#define EFI_EXIT_BOOT_SERVICES_SUCCEEDED\
> > + "Exit Boot Services Returned with Success"
> >
> >   /* TPMS_TAGGED_PROPERTY Structure */
> >   struct tpms_tagged_property {
> > diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> > index f6d5ba05e3..2914800c56 100644
> > --- a/lib/efi_loader/efi_boottime.c
> > +++ b/lib/efi_loader/efi_boottime.c
> > @@ -2993,6 +2993,16 @@ efi_status_t EFIAPI efi_start_image(efi_handle_t 
> > image_handle,
> >   image_obj->exit_status = &exit_status;
> >   image_obj->exit_jmp = &exit_jmp;
> >
> > + if (IS_ENABLED(CONFIG_EFI_TCG2_PROTOCOL)) {
> > + if (image_obj->image_type == IMAGE_SUBSYSTEM_EFI_APPLICATION) 
> > {
> > + ret = efi_tcg2_measure_efi_app_invocation();
> > + if (ret != EFI_SUCCESS) {
> > + EFI_PRINT("tcg2 measurement fails(0x%lx)\n",
> > +   ret);
>
> This will only show when enabling debug messages.
> Should this be log_warning()?
>
> > + }
> > + }
> > + }
> > +
> >   /* call the image! */
> >   if (setjmp(&exit_jmp)) {
> >   /*
> > @@ -3251,6 +3261,16 @@ static efi_status_t EFIAPI efi_exit(efi_handle_t 
> > image_handle,
> >   exit_status != EFI_SUCCESS)
> >   efi_delete_image(image_obj, loaded_image_protocol);
> >
> > + if (IS_ENABLED(CONFIG_EFI_T

Re: [PATCH v3 07/10] watchdog: wdt-uclass.c: handle all DM watchdogs in watchdog_reset()

[Stefan Roese]

Hi Rasmus,

On 05.07.21 17:30, Simon Glass wrote:

Hi Rasmus,

On Fri, 2 Jul 2021 at 06:45, Rasmus Villemoes
 wrote:


A board can have and make use of more than one watchdog device, say
one built into the SOC and an external gpio-petted one. Having
wdt-uclass only handle the first is both a little arbitrary and
unexpected.

So change initr_watchdog() so we visit (probe) all DM watchdog
devices. This essentially boils down to making the init_watchdog_dev
function into a .post_probe method.

Similarly let watchdog_reset() loop over the whole uclass - each
having their own ratelimiting metadata, and a separate "is this device
running" flag.

This gets rid of the watchdog_dev member of struct global_data.  We
do, however, still need the GD_FLG_WDT_READY set in
initr_watchdog(). This is because watchdog_reset() can get called
before DM is ready, and I don't think we can call uclass_get() that
early.

The current code just returns 0 if "getting" the first device fails -
that can of course happen because there are no devices, but it could
also happen if its ->probe call failed. In keeping with that, continue
with the handling of the remaining devices even if one fails to
probe. This is also why we cannot use uclass_probe_all().

If desired, it's possible to later add a per-device "u-boot,autostart"
boolean property, so that one can do CONFIG_WATCHDOG_AUTOSTART
per-device.

Reviewed-by: Stefan Roese 
Signed-off-by: Rasmus Villemoes 
---
  drivers/watchdog/wdt-uclass.c | 96 ++-
  include/asm-generic/global_data.h |  6 --
  2 files changed, 56 insertions(+), 46 deletions(-)



Please see my belated reply on the previous version of this patch.


Rasmus, do you plan to send an updated patchset version, addressing
Simons's comments?

Thanks,
Stefan

Re: [EXT] Re: Problem on imx: add rom api support on imx8mn

[Michael Nazzareno Trimarchi]

Hi

On Thu, Jul 15, 2021 at 9:56 AM Ye Li  wrote:
>
> Hi Michael,
>
> > -Original Message-
> > From: Michael Nazzareno Trimarchi 
> > Sent: Thursday, July 15, 2021 2:52 PM
> > To: Peng Fan (OSS) 
> > Cc: Peng Fan ; U-Boot-Denx ;
> > Stefano Babic ; Ye Li ; Fabio Estevam
> > ; Jagan Teki 
> > Subject: [EXT] Re: Problem on imx: add rom api support on imx8mn
> >
> > Caution: EXT Email
> >
> > Hi
> >
> > On Thu, Jul 15, 2021 at 8:47 AM Peng Fan (OSS) 
> > wrote:
> > >
> > >
> > >
> > > On 2021/7/8 17:15, Michael Nazzareno Trimarchi wrote:
> > > > Hi Peng
> > > >
> > > > On Thu, Jul 8, 2021 at 9:12 AM Peng Fan (OSS) 
> > wrote:
> > > >>
> > > >> On 2021/7/4 1:24, Michael Nazzareno Trimarchi wrote:
> > > >>> Hi all
> > > >>>
> > > >>> I have some problems that I have understood and fixed but I can
> > > >>> not explain. Right now I have on imx8mn that can boot from boot0
> > > >>> or boot1 partition after remove a condition in the
> > > >>> is_boot_from_stream_device
> > > >>>
> > > >>> This is a boot from mmcblk0boot0 with some debug
> > > >>>
> > > >>> U-Boot SPL 2020.04-5.4.70-2.3.2+gf3bcbdfc62 (Jul 03 2021 -
> > > >>> 17:00:27 +) power_bd71837_init
> > > >>> DDRINFO: start DRAM init
> > > >>> DDRINFO: DRAM rate 1600MTS
> > > >>> DDRINFO:ddrphy calibration done
> > > >>> DDRINFO: ddrmix config done
> > > >>> Normal Boot
> > > >>> Trying to boot from BOOTROM
> > > >>> ROM API interface 2 from boot 131073
> > > >>>
> > > >>> Interface is 2 MMC and boot is 131073 and according to this
> > > >>>
> > > >>> static int is_boot_from_stream_device(u32 boot)
> > > >>> +{
> > > >>> +   u32 interface;
> > > >>> +
> > > >>> +   interface = boot >> 16;
> > > >>> +   if (interface >= BT_DEV_TYPE_USB)
> > > >>> +   return 1;
> > > >>> +
> > > >>> +   if (interface == BT_DEV_TYPE_MMC && (boot & 1))
> > > >>> +   return 1;
> > > >>> +
> > > >>> +   return 0;
> > > >>> +}
> > > >>>
> > > >>> means a stream interface but it does not boot.
> > > >>>
> > > >>> Boot from boot1 give 131072 that is boot1 this let device boot
> > > >>> because
> > > >>
> > > >> Who gives 131073? Boot from boot1, you mean emmc boot partition0?
> > > >>
> > > >>> is_boot_from_stream_device is 0 and romapi use
> > > >>> spl_romapi_load_image_seekable
> > > >>>
> > > >>> Remove boot & 1 condition let me boot from mmcblk0boot0 and
> > > >>> mmcblk0boot1 without any problem
> > > >>
> > > >> Have you enabled emmc fastboot in fuse?
> > > >>
> > > >> boot & 1 is checking emmc fastboot. emmc fastboot mode is actually
> > > >> stream device. If fastboot mode enabled, you need burn your
> > > >> flash.bin into offset 0. Not 32KB offset.
> > > >
> > > > The offset is correct and the spl is starting on boot0 but then it
> > > > should load the rest from
> > > > boot0 block and not from usb. And why in case of boot1 the 1 is not
> > > > present. I flash both on offset 0. Anyway I sent a patch
> > >
> > > I suspect you have eMMC fastboot enabled for boot0, but not for boot1.
> >
> > I think that was fuse this way
> >
> > # Alternative Boot ("Fast boot")
> > # =>[BT_FUSE_SEL | eMMC boot | USDHC1 EMMC]
> > FB: ucmd fuse prog -y 1 3 0x10002A00
> > # =>[Fast boot | 8-bit DDR | MMC High speed | 1.8V | eMMC reset enable]
> > FB: ucmd fuse prog -y 2 1 0x00E7
> > # =>[Fast Boot Ack enable]
> > FB: ucmd fuse prog -y 2 2 0x0001
> > # boot_bus_width: 2 (8-bit), reset_boot_bus_width: 0, boot_mode: 2 (use dual
> > data rate (DDR))
> > FB: ucmd mmc bootbus 0 2 0 2
> > # boot_ack: 1, boot_partition: 1 (Boot partition 1), 7 (User area),
> > partition_access: No access to boot partition (default)
> > FB: ucmd mmc partconf 0 1 1 0
> >
> > How is it supposed to work in this case?
> >
>
> Above settings use the boot0 for fastboot. When you switch to boot1 for 
> fastboot, did you change the
> partconf setting to "mmc partconf 0 1 2 0"?

I don't need to use fastboot. I mean the idea is if I boot from block0
I want to continue there. BOOTROM
fill the mode but then it should be able to not fail. Am I right?

>
> If the ROM boots from emmc fastboot, it will set the bit0 to 1 to indicate 
> the fastboot. Since at this time, ROM
> does not leave fastboot (just stop the clock), we should continue the stream 
> mode read in SPL for FIT image load.
> So below checking is correct.  If you continue the stream mode read, what is 
> the failure do you meet?
> The codes will read max 640KB data from ROM to search to FIT header. Can it 
> get the header or not?
>

It does not find the header, in this case and it's not  problem of
size of 640Kb (I have extend it). My impression
is that is loading from mmcblk0 and not boot partition

Michael

> if (interface == BT_DEV_TYPE_MMC && (boot & 1))
> return 1;
>
> Best regards,
> Ye Li
>
> > Michael
> >
> >
> >
> > >
> > > Regards,
> > > Peng.
> > >
> > > >
> > > > Michael
> > > >
> > > >>
> > > >> Regards,
> > > >> Peng.
> > > >>
> > > >>>
> > > >>> mmc partconf 0
> > > >

Re: [PATCH 3/3] mmc: mmc_get_op_cond: Allow quiet detection of eMMC

[Stefan Roese]

(added Jaehoon as MMC co-maintainer)

On 15.07.21 10:03, Stefan Roese wrote:

On 14.07.21 16:37, Pali Rohár wrote:

Add a new 'quiet' argument to mmc_get_op_cond() function which avoids
printing error message when SD/eMMC card is not detected.

Espressobin and mx6cuboxi boards use this function for detecting presence
of eMMC and therefore it is expected and normal that eMMC does not 
have to

be connected. So error message "Card did not respond to voltage select!"
should be skipped in this case as it is not an error.

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 


Peng, Jaehoon are you okay with this patch? If yes, is it okay that
I will pull it via the marvell tree?

Thanks,
Stefan


Thanks,
Stefan


---
  board/Marvell/mvebu_armada-37xx/board.c | 2 +-
  board/solidrun/mx6cuboxi/mx6cuboxi.c    | 2 +-
  drivers/mmc/mmc.c   | 7 ---
  include/mmc.h   | 3 ++-
  4 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/board/Marvell/mvebu_armada-37xx/board.c 
b/board/Marvell/mvebu_armada-37xx/board.c

index 6086996b8062..fdc873b1952f 100644
--- a/board/Marvell/mvebu_armada-37xx/board.c
+++ b/board/Marvell/mvebu_armada-37xx/board.c
@@ -124,7 +124,7 @@ int board_late_init(void)
  /* eMMC is mmc dev num 1 */
  mmc_dev = find_mmc_device(1);
-    emmc = (mmc_dev && mmc_get_op_cond(mmc_dev) == 0);
+    emmc = (mmc_dev && mmc_get_op_cond(mmc_dev, true) == 0);
  /* if eMMC is not present then remove it from DM */
  if (!emmc && mmc_dev) {
diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c 
b/board/solidrun/mx6cuboxi/mx6cuboxi.c

index 3eadc38f6fd4..6207bf8253ab 100644
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
@@ -374,7 +374,7 @@ static bool has_emmc(void)
  mmc = find_mmc_device(2);
  if (!mmc)
  return 0;
-    return (mmc_get_op_cond(mmc) < 0) ? 0 : 1;
+    return (mmc_get_op_cond(mmc, true) < 0) ? 0 : 1;
  }
  int checkboard(void)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 1e83007286b2..8078a89f18cb 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -2766,7 +2766,7 @@ static int mmc_power_cycle(struct mmc *mmc)
  return mmc_power_on(mmc);
  }
-int mmc_get_op_cond(struct mmc *mmc)
+int mmc_get_op_cond(struct mmc *mmc, bool quiet)
  {
  bool uhs_en = supports_uhs(mmc->cfg->host_caps);
  int err;
@@ -2842,7 +2842,8 @@ retry:
  if (err) {
  #if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
-    pr_err("Card did not respond to voltage select! : %d\n", 
err);

+    if (!quiet)
+    pr_err("Card did not respond to voltage select! : 
%d\n", err);

  #endif
  return -EOPNOTSUPP;
  }
@@ -2882,7 +2883,7 @@ int mmc_start_init(struct mmc *mmc)
  return -ENOMEDIUM;
  }
-    err = mmc_get_op_cond(mmc);
+    err = mmc_get_op_cond(mmc, false);
  if (!err)
  mmc->init_in_progress = 1;
diff --git a/include/mmc.h b/include/mmc.h
index 6f943e78b740..0bf19de20e52 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -900,9 +900,10 @@ int mmc_set_bkops_enable(struct mmc *mmc);
   * the presence of SD/eMMC when no card detect logic is available.
   *
   * @param mmc    Pointer to a MMC device struct
+ * @param quiet    Be quiet, do not print error messages when card is 
not detected.

   * @return 0 on success, <0 on error.
   */
-int mmc_get_op_cond(struct mmc *mmc);
+int mmc_get_op_cond(struct mmc *mmc, bool quiet);
  /**
   * Start device initialization and return immediately; it does not 
block on





Viele Grüße,
Stefan




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH 17/27] ppc: Remove T1023RBD boards and T1024RDB_SECURE_BOOT

[gianluca]

Hello list!
I know this mail will be OT, but I am worried about what will happen to 
a new project using the PowerPC T2080,e6500 64-bit PPC on this web site:


https://www.powerpc-notebook.org

I suspect the same architecture will be move outside the official Linux 
release when the same device-model will not match the kernel. And this 
will be a pity for all people who are believe on architectures and the 
power of opensource other than x86 and arm processors.


So, this project will be a no-go or dead project before it will be launched.

Are my worries overkill?

I hope so.

 On 7/8/21 4:52 AM, Tom Rini wrote:

On Fri, May 14, 2021 at 09:34:22PM -0400, Tom Rini wrote:


These boards have not been converted to CONFIG_DM_PCI by the deadline
and is also missing conversion to CONFIG_DM.  Remove them.  As this is
the only ARCH_T1023 platform left, remove that support as well.

Cc: Priyanka Jain 
Signed-off-by: Tom Rini 


Applied to u-boot/master, thanks!




--
Eurek s.r.l.  |
Electronic Engineering| http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy  | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377  | Fax:   +39-(0)542-609212

Re: [PATCH u-boot-mvebu 01/31] tools: kwbimage: Fix compilation without CONFIG_SYS_U_BOOT_OFFS

[Stefan Roese]

On 08.07.21 19:30, Marek Behún wrote:

From: Pali Rohár 

The CONFIG_SYS_U_BOOT_OFFS option may be defined as empty string.
In this case it causes compilation error:

 tools/kwbimage.c: In function ‘image_headersz_v1’:
 tools/kwbimage.c:1002:39: error: expected expression before ‘)’ token
   if (headersz > CONFIG_SYS_U_BOOT_OFFS) {
^
 tools/kwbimage.c:1006:41: error: expected expression before ‘)’ token
 (int)headersz, CONFIG_SYS_U_BOOT_OFFS);
  ^
 tools/kwbimage.c:1011:35: error: expected expression before ‘;’ token
   headersz = CONFIG_SYS_U_BOOT_OFFS;
^
 make[1]: *** [scripts/Makefile.host:112: tools/kwbimage.o] Error 1
 make: *** [Makefile:1822: tools] Error 2

Check whether the value of CONFIG_SYS_U_BOOT_OFFS is really set.

Signed-off-by: Pali Rohár 
Reviewed-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  tools/Makefile | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/Makefile b/tools/Makefile
index d020c55d66..fadf3135d6 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -155,7 +155,7 @@ ifdef CONFIG_FIT_CIPHER
  HOST_EXTRACFLAGS  += -DCONFIG_FIT_CIPHER
  endif
  
-ifdef CONFIG_SYS_U_BOOT_OFFS

+ifneq ($(CONFIG_SYS_U_BOOT_OFFS),)
  HOSTCFLAGS_kwbimage.o += -DCONFIG_SYS_U_BOOT_OFFS=$(CONFIG_SYS_U_BOOT_OFFS)
  endif
  




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH u-boot-mvebu 02/31] tools: kwbimage: Simplify aligning and calculating checksum

[Stefan Roese]

On 08.07.21 19:30, Marek Behún wrote:

From: Pali Rohár 

The return value of kwbimage_generate() is used for aligning the data
part of kwbimage. Use it for calculating proper 4 byte alignment as is
required by BootROM and also use it for allocating additional 4 bytes
for the 32-bit data checksum.

This simplifies the alignment code to be only at one place (in function
kwbimage_generate) and also simplifies setting checksum as it can be
directly updated in memory.

Signed-off-by: Pali Rohár 
Reviewed-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  tools/kwbimage.c | 36 +++-
  1 file changed, 15 insertions(+), 21 deletions(-)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 02fd0c949f..c775abf0e3 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -891,7 +891,7 @@ static void *image_create_v0(size_t *imagesz, struct 
image_tool_params *params,
  
  	/* Fill in the main header */

main_hdr->blocksize =
-   cpu_to_le32(payloadsz + sizeof(uint32_t) - headersz);
+   cpu_to_le32(payloadsz - headersz);
main_hdr->srcaddr   = cpu_to_le32(headersz);
main_hdr->ext   = has_ext;
main_hdr->destaddr  = cpu_to_le32(params->addr);
@@ -1249,7 +1249,7 @@ static void *image_create_v1(size_t *imagesz, struct 
image_tool_params *params,
  
  	/* Fill the main header */

main_hdr->blocksize=
-   cpu_to_le32(payloadsz - headersz + sizeof(uint32_t));
+   cpu_to_le32(payloadsz - headersz);
main_hdr->headersz_lsb = cpu_to_le16(headersz & 0x);
main_hdr->headersz_msb = (headersz & 0x) >> 16;
main_hdr->destaddr = cpu_to_le32(params->addr)
@@ -1519,7 +1519,6 @@ static void kwbimage_set_header(void *ptr, struct stat 
*sbuf, int ifd,
size_t headersz = 0;
uint32_t checksum;
int ret;
-   int size;
  
  	fcfg = fopen(params->imagename, "r");

if (!fcfg) {
@@ -1547,9 +1546,6 @@ static void kwbimage_set_header(void *ptr, struct stat 
*sbuf, int ifd,
exit(EXIT_FAILURE);
}
  
-	/* The MVEBU BootROM does not allow non word aligned payloads */

-   sbuf->st_size = ALIGN(sbuf->st_size, 4);
-
version = image_get_version();
switch (version) {
/*
@@ -1580,16 +1576,10 @@ static void kwbimage_set_header(void *ptr, struct stat 
*sbuf, int ifd,
free(image_cfg);
  
  	/* Build and add image checksum header */

-   checksum =
-   cpu_to_le32(image_checksum32((uint32_t *)ptr, sbuf->st_size));
-   size = write(ifd, &checksum, sizeof(uint32_t));
-   if (size != sizeof(uint32_t)) {
-   fprintf(stderr, "Error:%s - Checksum write %d bytes %s\n",
-   params->cmdname, size, params->imagefile);
-   exit(EXIT_FAILURE);
-   }
-
-   sbuf->st_size += sizeof(uint32_t);
+   checksum = cpu_to_le32(image_checksum32((uint8_t *)ptr + headersz,
+   sbuf->st_size - headersz - sizeof(uint32_t)));
+   memcpy((uint8_t *)ptr + sbuf->st_size - sizeof(uint32_t), &checksum,
+   sizeof(uint32_t));
  
  	/* Finally copy the header into the image area */

memcpy(ptr, image, headersz);
@@ -1650,6 +1640,7 @@ static int kwbimage_generate(struct image_tool_params 
*params,
 struct image_type_params *tparams)
  {
FILE *fcfg;
+   struct stat s;
int alloc_len;
int version;
void *hdr;
@@ -1662,6 +1653,12 @@ static int kwbimage_generate(struct image_tool_params 
*params,
exit(EXIT_FAILURE);
}
  
+	if (stat(params->datafile, &s)) {

+   fprintf(stderr, "Could not stat data file %s: %s\n",
+   params->datafile, strerror(errno));
+   exit(EXIT_FAILURE);
+   }
+
image_cfg = malloc(IMAGE_CFG_ELEMENT_MAX *
   sizeof(struct image_cfg_element));
if (!image_cfg) {
@@ -1719,12 +1716,9 @@ static int kwbimage_generate(struct image_tool_params 
*params,
/*
 * The resulting image needs to be 4-byte aligned. At least
 * the Marvell hdrparser tool complains if its unaligned.
-* By returning 1 here in this function, called via
-* tparams->vrec_header() in mkimage.c, mkimage will
-* automatically pad the the resulting image to a 4-byte
-* size if necessary.
+* After the image data is stored 4-byte checksum.
 */
-   return 1;
+   return 4 + (4 - s.st_size % 4) % 4;
  }
  
  /*





Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH u-boot-mvebu 03/31] tools: kwbimage: Align SPI and NAND images to 256 bytes

[Stefan Roese]

On 08.07.21 19:30, Marek Behún wrote:

From: Pali Rohár 

Writing into SPI NOR and NAND memory can be done only in 256 bytes long
blocks. Align final image size so that when it is burned into SPI NOR or
NAND memory via U-Boot's commands (sf or mtd), we can use the $filesize
variable directly as the length argument.

Signed-off-by: Pali Rohár 
Reviewed-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  tools/kwbimage.c | 19 ++-
  1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index c775abf0e3..f40ba0994d 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1510,6 +1510,17 @@ static int image_get_version(void)
return e->version;
  }
  
+static int image_get_bootfrom(void)

+{
+   struct image_cfg_element *e;
+
+   e = image_find_option(IMAGE_CFG_BOOT_FROM);
+   if (!e)
+   return -1;
+
+   return e->bootfrom;
+}
+
  static void kwbimage_set_header(void *ptr, struct stat *sbuf, int ifd,
struct image_tool_params *params)
  {
@@ -1642,6 +1653,7 @@ static int kwbimage_generate(struct image_tool_params 
*params,
FILE *fcfg;
struct stat s;
int alloc_len;
+   int bootfrom;
int version;
void *hdr;
int ret;
@@ -1678,6 +1690,7 @@ static int kwbimage_generate(struct image_tool_params 
*params,
exit(EXIT_FAILURE);
}
  
+	bootfrom = image_get_bootfrom();

version = image_get_version();
switch (version) {
/*
@@ -1717,8 +1730,12 @@ static int kwbimage_generate(struct image_tool_params 
*params,
 * The resulting image needs to be 4-byte aligned. At least
 * the Marvell hdrparser tool complains if its unaligned.
 * After the image data is stored 4-byte checksum.
+* Final SPI and NAND images must be aligned to 256 bytes.
 */
-   return 4 + (4 - s.st_size % 4) % 4;
+   if (bootfrom == IBR_HDR_SPI_ID || bootfrom == IBR_HDR_NAND_ID)
+   return 4 + (256 - (alloc_len + s.st_size + 4) % 256) % 256;
+   else
+   return 4 + (4 - s.st_size % 4) % 4;
  }
  
  /*





Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH u-boot-mvebu 04/31] tools: kwbimage: Add constant for SDIO bootfrom

[Stefan Roese]

On 08.07.21 19:30, Marek Behún wrote:

Add constant for SDIO value of the bootfrom header field.

Signed-off-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  tools/kwbimage.h | 1 +
  1 file changed, 1 insertion(+)

diff --git a/tools/kwbimage.h b/tools/kwbimage.h
index 0b6d05bef1..9856b44536 100644
--- a/tools/kwbimage.h
+++ b/tools/kwbimage.h
@@ -27,6 +27,7 @@
  #define IBR_HDR_SATA_ID   0x78
  #define IBR_HDR_PEX_ID0x9C
  #define IBR_HDR_UART_ID   0x69
+#define IBR_HDR_SDIO_ID0xAE
  #define IBR_DEF_ATTRIB0x00
  
  /* Structure of the main header, version 0 (Kirkwood, Dove) */





Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH u-boot-mvebu 05/31] tools: kwbimage: Fix generation of SATA, SDIO and PCIe images

[Stefan Roese]

On 08.07.21 19:30, Marek Behún wrote:

From: Pali Rohár 

SATA and SDIO images must be aligned to sector size (which in most cases
is 512 bytes) and Source Address in main header is stored in number of
sectors from the beginning of the drive. SATA image must be stored at
sector 1 and SDIO image at sector 0. Source Address for PCIe image is
not used and must be set to 0x.

Signed-off-by: Pali Rohár 
Reviewed-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  tools/kwbimage.c | 22 ++
  1 file changed, 22 insertions(+)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index f40ba0994d..44bf5ee026 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1281,6 +1281,26 @@ static void *image_create_v1(size_t *imagesz, struct 
image_tool_params *params,
main_hdr->destaddr = cpu_to_le32(params->addr);
}
  
+	/*

+* For SATA srcaddr is specified in number of sectors starting from
+* sector 0. The main header is stored at sector number 1.
+* This expects the sector size to be 512 bytes.
+*/
+   if (main_hdr->blockid == IBR_HDR_SATA_ID)
+   main_hdr->srcaddr = cpu_to_le32((headersz + 511) / 512 + 1);
+
+   /*
+* For SDIO srcaddr is specified in number of sectors starting from
+* sector 0. The main header is stored at sector number 0.
+* This expects sector size to be 512 bytes.
+*/
+   if (main_hdr->blockid == IBR_HDR_SDIO_ID)
+   main_hdr->srcaddr = cpu_to_le32((headersz + 511) / 512);
+
+   /* For PCIe srcaddr is not used and must be set to 0x. */
+   if (main_hdr->blockid == IBR_HDR_PEX_ID)
+   main_hdr->srcaddr = cpu_to_le32(0x);
+
  #if defined(CONFIG_KWB_SECURE)
if (image_get_csk_index() >= 0) {
/*
@@ -1734,6 +1754,8 @@ static int kwbimage_generate(struct image_tool_params 
*params,
 */
if (bootfrom == IBR_HDR_SPI_ID || bootfrom == IBR_HDR_NAND_ID)
return 4 + (256 - (alloc_len + s.st_size + 4) % 256) % 256;
+   else if (bootfrom == IBR_HDR_SDIO_ID || bootfrom == IBR_HDR_PEX_ID)
+   return 4 + (512 - (alloc_len + s.st_size + 4) % 512) % 512;
else
return 4 + (4 - s.st_size % 4) % 4;
  }




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH u-boot-mvebu 06/31] tools: kwbimage: Don't crash when binary file name does not contain '/'

[Stefan Roese]

On 08.07.21 19:30, Marek Behún wrote:

From: Pali Rohár 

In the case when the file name is specified relative to the current
working directory, it does not contain '/' character and strrchr()
returns NULL.

The following strcmp() function then crashes on NULL pointer
dereference.

Signed-off-by: Pali Rohár 
Reviewed-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  tools/kwbimage.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 44bf5ee026..c08fb678d4 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1277,7 +1277,7 @@ static void *image_create_v1(size_t *imagesz, struct 
image_tool_params *params,
if (e) {
char *s = strrchr(e->binary.file, '/');
  
-		if (strcmp(s, "/binary.0") == 0)

+   if (s && strcmp(s, "/binary.0") == 0)
main_hdr->destaddr = cpu_to_le32(params->addr);
}
  




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH u-boot-mvebu 07/31] tools: kwbimage: Fix check for v0 extended header checksum

[Stefan Roese]

On 08.07.21 19:30, Marek Behún wrote:

From: Pali Rohár 

Extended header checksum for v0 image is present only in the case when
extended header is present. Skip checksum validation if extended header
is not present.

Signed-off-by: Pali Rohár 
Reviewed-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  tools/kwbimage.c | 18 +++---
  1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index c08fb678d4..5192edb330 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1653,15 +1653,19 @@ static int kwbimage_verify_header(unsigned char *ptr, 
int image_size,
  
  	/* Only version 0 extended header has checksum */

if (image_version((void *)ptr) == 0) {
-   struct ext_hdr_v0 *ext_hdr;
+   struct main_hdr_v0 *mhdr = (struct main_hdr_v0 *)ptr;
  
-		ext_hdr = (struct ext_hdr_v0 *)

+   if (mhdr->ext & 0x1) {
+   struct ext_hdr_v0 *ext_hdr;
+
+   ext_hdr = (struct ext_hdr_v0 *)
(ptr + sizeof(struct main_hdr_v0));
-   checksum = image_checksum8(ext_hdr,
-  sizeof(struct ext_hdr_v0)
-  - sizeof(uint8_t));
-   if (checksum != ext_hdr->checksum)
-   return -FDT_ERR_BADSTRUCTURE;
+   checksum = image_checksum8(ext_hdr,
+  sizeof(struct ext_hdr_v0)
+  - sizeof(uint8_t));
+   if (checksum != ext_hdr->checksum)
+   return -FDT_ERR_BADSTRUCTURE;
+   }
}
  
  	return 0;





Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH u-boot-mvebu 08/31] tools: kwbimage: Validate extended headers of v1 images

[Stefan Roese]

On 08.07.21 19:30, Marek Behún wrote:

From: Pali Rohár 

Add basic checks for extended headers of v1 images.

Signed-off-by: Pali Rohár 
Reviewed-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  tools/kwbimage.c | 28 
  1 file changed, 28 insertions(+)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 5192edb330..5f7cb8376a 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1668,6 +1668,34 @@ static int kwbimage_verify_header(unsigned char *ptr, 
int image_size,
}
}
  
+	if (image_version((void *)ptr) == 1) {

+   struct main_hdr_v1 *mhdr = (struct main_hdr_v1 *)ptr;
+
+   if (mhdr->ext & 0x1) {
+   uint32_t ohdr_size;
+   struct opt_hdr_v1 *ohdr = (struct opt_hdr_v1 *)
+ (ptr + sizeof(*mhdr));
+
+   while (1) {
+   if ((uint8_t *)ohdr + sizeof(*ohdr) >
+   (uint8_t *)mhdr + header_size)
+   return -FDT_ERR_BADSTRUCTURE;
+
+   ohdr_size = (ohdr->headersz_msb << 16) |
+   le16_to_cpu(ohdr->headersz_lsb);
+
+   if ((uint8_t *)ohdr + 4 + ohdr_size + 4 >
+   (uint8_t *)mhdr + header_size)
+   return -FDT_ERR_BADSTRUCTURE;
+
+   if (!(*((uint8_t *)ohdr + 4 + ohdr_size) & 0x1))
+   break;
+   ohdr = (struct opt_hdr_v1 *)((uint8_t *)ohdr +
+4 + ohdr_size + 4);
+   }
+   }
+   }
+
return 0;
  }
  




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH u-boot-mvebu 09/31] tools: kwbimage: Validate data checksum of v1 images

[Stefan Roese]

On 08.07.21 19:30, Marek Behún wrote:

From: Pali Rohár 

The data part of v1 images contains 32-bit checksum after the data.
Validate whether this checksum is correct.

Signed-off-by: Pali Rohár 
Reviewed-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  tools/kwbimage.c | 46 ++
  1 file changed, 46 insertions(+)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 5f7cb8376a..de6eb3f075 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1670,6 +1670,9 @@ static int kwbimage_verify_header(unsigned char *ptr, int 
image_size,
  
  	if (image_version((void *)ptr) == 1) {

struct main_hdr_v1 *mhdr = (struct main_hdr_v1 *)ptr;
+   unsigned char *endptr = ptr + sizeof(*mhdr);
+   uint32_t offset;
+   uint32_t size;
  
  		if (mhdr->ext & 0x1) {

uint32_t ohdr_size;
@@ -1693,7 +1696,50 @@ static int kwbimage_verify_header(unsigned char *ptr, 
int image_size,
ohdr = (struct opt_hdr_v1 *)((uint8_t *)ohdr +
 4 + ohdr_size + 4);
}
+
+   endptr = ((uint8_t *)ohdr + 4 + ohdr_size + 4);
+   }
+
+   offset = le32_to_cpu(mhdr->srcaddr);
+
+   /*
+* For SATA srcaddr is specified in number of sectors.
+* The main header is must be stored at sector number 1.
+* This expects that sector size is 512 bytes and recalculates
+* data offset to bytes relative to the main header.
+*/
+   if (mhdr->blockid == IBR_HDR_SATA_ID) {
+   if (offset < 1)
+   return -FDT_ERR_BADSTRUCTURE;
+   offset -= 1;
+   offset *= 512;
}
+
+   /*
+* For SDIO srcaddr is specified in number of sectors.
+* This expects that sector size is 512 bytes and recalculates
+* data offset to bytes.
+*/
+   if (mhdr->blockid == IBR_HDR_SDIO_ID)
+   offset *= 512;
+
+   /*
+* For PCIe srcaddr is always set to 0x.
+* This expects that data starts after all headers.
+*/
+   if (mhdr->blockid == IBR_HDR_PEX_ID && offset == 0x)
+   offset = endptr - ptr;
+
+   if (offset > image_size || offset % 4 != 0)
+   return -FDT_ERR_BADSTRUCTURE;
+
+   size = le32_to_cpu(mhdr->blocksize);
+   if (offset + size > image_size || size % 4 != 0)
+   return -FDT_ERR_BADSTRUCTURE;
+
+   if (image_checksum32(ptr + offset, size - 4) !=
+   *(uint32_t *)(ptr + offset + size - 4))
+   return -FDT_ERR_BADSTRUCTURE;
}
  
  	return 0;





Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH u-boot-mvebu 10/31] tools: kwbimage: Print size of binary header in kwbimage_print_header()

[Stefan Roese]

On 08.07.21 19:30, Marek Behún wrote:

From: Pali Rohár 

The binary header in kwbimage contains executable SPL code.

Print information about this binary header and not only information
about it's data part.

Signed-off-by: Pali Rohár 
Reviewed-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  tools/kwbimage.c | 24 
  1 file changed, 24 insertions(+)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index de6eb3f075..d8a14cb093 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1625,6 +1625,30 @@ static void kwbimage_print_header(const void *ptr)
printf("Image Type:   MVEBU Boot from %s Image\n",
   image_boot_mode_name(mhdr->blockid));
printf("Image version:%d\n", image_version((void *)ptr));
+   if (image_version((void *)ptr) == 1) {
+   struct main_hdr_v1 *mhdr = (struct main_hdr_v1 *)ptr;
+
+   if (mhdr->ext & 0x1) {
+   struct opt_hdr_v1 *ohdr = (struct opt_hdr_v1 *)
+ ((uint8_t *)ptr +
+  sizeof(*mhdr));
+
+   while (1) {
+   uint32_t ohdr_size;
+
+   ohdr_size = (ohdr->headersz_msb << 16) |
+   ohdr->headersz_lsb;
+   if (ohdr->headertype == OPT_HDR_V1_BINARY_TYPE) 
{
+   printf("BIN Hdr Size: ");
+   genimg_print_size(ohdr_size);
+   }
+   if (!(*((uint8_t *)ohdr + 4 + ohdr_size) & 0x1))
+   break;
+   ohdr = (struct opt_hdr_v1 *)((uint8_t *)ohdr +
+4 + ohdr_size + 4);
+   }
+   }
+   }
printf("Data Size:");
genimg_print_size(mhdr->blocksize - sizeof(uint32_t));
printf("Load Address: %08x\n", mhdr->destaddr);




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH u-boot-mvebu 11/31] tools: kwboot: Fix wrong parameter passed to read()

[Stefan Roese]

On 08.07.21 19:30, Marek Behún wrote:

From: Pali Rohár 

The 'buf' is a pointer and '_buf' is the array itself.
Therefore we should pass sizeof(_buf) instead of sizeof(buf) to read().

Signed-off-by: Pali Rohár 
Reviewed-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  tools/kwboot.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index 4be094c9c8..2edeb5a371 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -471,7 +471,7 @@ kwboot_term_pipe(int in, int out, char *quit, int *s)
ssize_t nin, nout;
char _buf[128], *buf = _buf;
  
-	nin = read(in, buf, sizeof(buf));

+   nin = read(in, buf, sizeof(_buf));
if (nin <= 0)
return -1;
  




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH u-boot-mvebu 12/31] tools: kwboot: Fix restoring terminal

[Stefan Roese]

On 08.07.21 19:30, Marek Behún wrote:

From: Pali Rohár 

Call tcsetattr() only if the file descriptor is valid. It may be
invalidated by previous lines (if it is not a tty descriptor).

Signed-off-by: Pali Rohár 
Reviewed-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  tools/kwboot.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index 2edeb5a371..7e8bf21d37 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -564,7 +564,8 @@ kwboot_terminal(int tty)
}
} while (quit[s] != 0);
  
-	tcsetattr(in, TCSANOW, &otio);

+   if (in >= 0)
+   tcsetattr(in, TCSANOW, &otio);
  out:
return rc;
  }




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH u-boot-mvebu 13/31] tools: kwboot: Print trailing newline after terminal is terminated

[Stefan Roese]

On 08.07.21 19:30, Marek Behún wrote:

From: Pali Rohár 

Print trailing newline as the last printed byte can be something
different.

Signed-off-by: Pali Rohár 
Reviewed-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  tools/kwboot.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index 7e8bf21d37..6e66ad4ecf 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -566,6 +566,7 @@ kwboot_terminal(int tty)
  
  	if (in >= 0)

tcsetattr(in, TCSANOW, &otio);
+   printf("\n");
  out:
return rc;
  }




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH u-boot-mvebu 14/31] tools: kwboot: Cosmetic fix - add missing curly brackets

[Stefan Roese]

On 08.07.21 19:30, Marek Behún wrote:

From: Pali Rohár 

Add missing curly brackets for this else statement.

Signed-off-by: Pali Rohár 
Reviewed-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  tools/kwboot.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index 6e66ad4ecf..e4d4267e47 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -485,13 +485,14 @@ kwboot_term_pipe(int in, int out, char *quit, int *s)
return 0;
buf++;
nin--;
-   } else
+   } else {
while (*s > 0) {
nout = write(out, quit, *s);
if (nout <= 0)
return -1;
(*s) -= nout;
}
+   }
}
}
  




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH u-boot-mvebu 15/31] tools: kwboot: Check for v1 header size

[Stefan Roese]

On 08.07.21 19:30, Marek Behún wrote:

From: Pali Rohár 

Too small invalid headers may cause kwboot to crash.
Check for header size of v1 images.

Signed-off-by: Pali Rohár 
Reviewed-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  tools/kwboot.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index e4d4267e47..7f3489c55c 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -651,6 +651,11 @@ kwboot_img_patch_hdr(void *img, size_t size)
else
hdrsz = KWBHEADER_V1_SIZE(hdr);
  
+	if (size < hdrsz) {

+   errno = EINVAL;
+   goto out;
+   }
+
csum = kwboot_img_csum8(hdr, hdrsz) - hdr->checksum;
if (csum != hdr->checksum) {
errno = EINVAL;




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH 3/3] mmc: mmc_get_op_cond: Allow quiet detection of eMMC

[Jaehoon Chung]

Hi Stefan,

On 7/15/21 5:20 PM, Stefan Roese wrote:
> (added Jaehoon as MMC co-maintainer)
> 
> On 15.07.21 10:03, Stefan Roese wrote:
>> On 14.07.21 16:37, Pali Rohár wrote:
>>> Add a new 'quiet' argument to mmc_get_op_cond() function which avoids
>>> printing error message when SD/eMMC card is not detected.
>>>
>>> Espressobin and mx6cuboxi boards use this function for detecting presence
>>> of eMMC and therefore it is expected and normal that eMMC does not have to
>>> be connected. So error message "Card did not respond to voltage select!"
>>> should be skipped in this case as it is not an error.
>>>
>>> Signed-off-by: Pali Rohár 
>>
>> Reviewed-by: Stefan Roese 
> 
> Peng, Jaehoon are you okay with this patch? If yes, is it okay that
> I will pull it via the marvell tree?

I don't have any objection.

Acked-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> 
> Thanks,
> Stefan
> 
>> Thanks,
>> Stefan
>>
>>> ---
>>>   board/Marvell/mvebu_armada-37xx/board.c | 2 +-
>>>   board/solidrun/mx6cuboxi/mx6cuboxi.c    | 2 +-
>>>   drivers/mmc/mmc.c   | 7 ---
>>>   include/mmc.h   | 3 ++-
>>>   4 files changed, 8 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/board/Marvell/mvebu_armada-37xx/board.c 
>>> b/board/Marvell/mvebu_armada-37xx/board.c
>>> index 6086996b8062..fdc873b1952f 100644
>>> --- a/board/Marvell/mvebu_armada-37xx/board.c
>>> +++ b/board/Marvell/mvebu_armada-37xx/board.c
>>> @@ -124,7 +124,7 @@ int board_late_init(void)
>>>   /* eMMC is mmc dev num 1 */
>>>   mmc_dev = find_mmc_device(1);
>>> -    emmc = (mmc_dev && mmc_get_op_cond(mmc_dev) == 0);
>>> +    emmc = (mmc_dev && mmc_get_op_cond(mmc_dev, true) == 0);
>>>   /* if eMMC is not present then remove it from DM */
>>>   if (!emmc && mmc_dev) {
>>> diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c 
>>> b/board/solidrun/mx6cuboxi/mx6cuboxi.c
>>> index 3eadc38f6fd4..6207bf8253ab 100644
>>> --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
>>> +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
>>> @@ -374,7 +374,7 @@ static bool has_emmc(void)
>>>   mmc = find_mmc_device(2);
>>>   if (!mmc)
>>>   return 0;
>>> -    return (mmc_get_op_cond(mmc) < 0) ? 0 : 1;
>>> +    return (mmc_get_op_cond(mmc, true) < 0) ? 0 : 1;
>>>   }
>>>   int checkboard(void)
>>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
>>> index 1e83007286b2..8078a89f18cb 100644
>>> --- a/drivers/mmc/mmc.c
>>> +++ b/drivers/mmc/mmc.c
>>> @@ -2766,7 +2766,7 @@ static int mmc_power_cycle(struct mmc *mmc)
>>>   return mmc_power_on(mmc);
>>>   }
>>> -int mmc_get_op_cond(struct mmc *mmc)
>>> +int mmc_get_op_cond(struct mmc *mmc, bool quiet)
>>>   {
>>>   bool uhs_en = supports_uhs(mmc->cfg->host_caps);
>>>   int err;
>>> @@ -2842,7 +2842,8 @@ retry:
>>>   if (err) {
>>>   #if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
>>> -    pr_err("Card did not respond to voltage select! : %d\n", err);
>>> +    if (!quiet)
>>> +    pr_err("Card did not respond to voltage select! : %d\n", 
>>> err);
>>>   #endif
>>>   return -EOPNOTSUPP;
>>>   }
>>> @@ -2882,7 +2883,7 @@ int mmc_start_init(struct mmc *mmc)
>>>   return -ENOMEDIUM;
>>>   }
>>> -    err = mmc_get_op_cond(mmc);
>>> +    err = mmc_get_op_cond(mmc, false);
>>>   if (!err)
>>>   mmc->init_in_progress = 1;
>>> diff --git a/include/mmc.h b/include/mmc.h
>>> index 6f943e78b740..0bf19de20e52 100644
>>> --- a/include/mmc.h
>>> +++ b/include/mmc.h
>>> @@ -900,9 +900,10 @@ int mmc_set_bkops_enable(struct mmc *mmc);
>>>    * the presence of SD/eMMC when no card detect logic is available.
>>>    *
>>>    * @param mmc    Pointer to a MMC device struct
>>> + * @param quiet    Be quiet, do not print error messages when card is not 
>>> detected.
>>>    * @return 0 on success, <0 on error.
>>>    */
>>> -int mmc_get_op_cond(struct mmc *mmc);
>>> +int mmc_get_op_cond(struct mmc *mmc, bool quiet);
>>>   /**
>>>    * Start device initialization and return immediately; it does not block 
>>> on
>>>
>>
>>
>> Viele Grüße,
>> Stefan
>>
> 
> 
> Viele Grüße,
> Stefan
> 

Re: [PATCH u-boot-mvebu 16/31] tools: kwbimage: Cosmetic fix - remove redundant space character

[Stefan Roese]

On 08.07.21 19:30, Marek Behún wrote:

Remove this space, since the constants are indented by tabs.

Signed-off-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  tools/kwbimage.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/kwbimage.h b/tools/kwbimage.h
index 9856b44536..cab3d95d13 100644
--- a/tools/kwbimage.h
+++ b/tools/kwbimage.h
@@ -28,7 +28,7 @@
  #define IBR_HDR_PEX_ID0x9C
  #define IBR_HDR_UART_ID   0x69
  #define IBR_HDR_SDIO_ID   0xAE
-#define IBR_DEF_ATTRIB 0x00
+#define IBR_DEF_ATTRIB 0x00
  
  /* Structure of the main header, version 0 (Kirkwood, Dove) */

  struct main_hdr_v0 {




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH u-boot-mvebu 17/31] tools: kwbimage: Use -a parameter (load address) for v1 images

[Stefan Roese]

On 08.07.21 19:30, Marek Behún wrote:

From: Pali Rohár 

The data part of v1 kwbimage currently contains U-Boot binary prepended
by 64 bytes long Legacy U-Boot image header. This means that the load
address is currently substracted by 64 bytes to ensure that U-Boot's
entry point is at specified execution address.

As mkimage has already separate arguments for load (-a) and execution
(-e) address, there is no need to derive fixed load address from
execution address.

Therefore remove this load address hack from the kwbimage tool and
support generating v1 kwbimage with arbitrary addresses for load and
execution.

Finally, calculate correct load address by caller for mkimage tool in
Makefile. File u-boot-spl.kwb is always a v1 kwbimage and it is the only
v1 kwbimage which U-Boot's build system generates.

Remove also useless overwriting of destaddr for /binary.0 to the value
which is already set on previous lines.

Signed-off-by: Pali Rohár 
Reviewed-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  Makefile |  2 +-
  tools/kwbimage.c | 10 +-
  2 files changed, 2 insertions(+), 10 deletions(-)

diff --git a/Makefile b/Makefile
index 0d3192ceba..85bd8fc12d 100644
--- a/Makefile
+++ b/Makefile
@@ -1398,7 +1398,7 @@ MKIMAGEFLAGS_u-boot.kwb = -n $(KWD_CONFIG_FILE) \
-T kwbimage -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_TEXT_BASE)
  
  MKIMAGEFLAGS_u-boot-spl.kwb = -n $(KWD_CONFIG_FILE) \

-   -T kwbimage -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_TEXT_BASE) \
+   -T kwbimage -a $(shell printf "0x%x" $$(($(CONFIG_SYS_TEXT_BASE)-64))) 
-e $(CONFIG_SYS_TEXT_BASE) \
$(if $(KEYDIR),-k $(KEYDIR))
  
  MKIMAGEFLAGS_u-boot.pbl = -n $(srctree)/$(CONFIG_SYS_FSL_PBL_RCW:"%"=%) \

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index d8a14cb093..acd57267f4 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1252,8 +1252,7 @@ static void *image_create_v1(size_t *imagesz, struct 
image_tool_params *params,
cpu_to_le32(payloadsz - headersz);
main_hdr->headersz_lsb = cpu_to_le16(headersz & 0x);
main_hdr->headersz_msb = (headersz & 0x) >> 16;
-   main_hdr->destaddr = cpu_to_le32(params->addr)
-- sizeof(image_header_t);
+   main_hdr->destaddr = cpu_to_le32(params->addr);
main_hdr->execaddr = cpu_to_le32(params->ep);
main_hdr->srcaddr  = cpu_to_le32(headersz);
main_hdr->ext  = hasext;
@@ -1273,13 +1272,6 @@ static void *image_create_v1(size_t *imagesz, struct 
image_tool_params *params,
e = image_find_option(IMAGE_CFG_DEBUG);
if (e)
main_hdr->flags = e->debug ? 0x1 : 0;
-   e = image_find_option(IMAGE_CFG_BINARY);
-   if (e) {
-   char *s = strrchr(e->binary.file, '/');
-
-   if (s && strcmp(s, "/binary.0") == 0)
-   main_hdr->destaddr = cpu_to_le32(params->addr);
-   }
  
  	/*

 * For SATA srcaddr is specified in number of sectors starting from




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH u-boot-mvebu 18/31] arm: mvebu: Fix return_to_bootrom()

[Stefan Roese]

On 08.07.21 19:30, Marek Behún wrote:

From: Pali Rohár 

Register r0 should be set to return value 0x0 - NO_ERR.

Set r0 with return value after all registers are restored from the
stack, so that the return value is always correct.

Signed-off-by: Pali Rohár 
Fixes: 944c7a317675 ("arm: mvebu: Add option to use UART xmodem protocol via 
kwboot")
Reviewed-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  arch/arm/mach-mvebu/lowlevel_spl.S | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-mvebu/lowlevel_spl.S 
b/arch/arm/mach-mvebu/lowlevel_spl.S
index 8718d7a43e..dde77b7652 100644
--- a/arch/arm/mach-mvebu/lowlevel_spl.S
+++ b/arch/arm/mach-mvebu/lowlevel_spl.S
@@ -13,8 +13,9 @@ ENDPROC(save_boot_params)
  ENTRY(return_to_bootrom)
ldr r12, =CONFIG_SPL_BOOTROM_SAVE
ldr sp, [r12]
+   ldmfd   sp!, {r0 - r12, lr} /* @ restore registers from stack */
mov r0, #0x0/* @ return value: 0x0 NO_ERR */
-   ldmfd   sp!, {r0 - r12, pc} /* @ restore regs and return */
+   bx  lr  /* @ return to bootrom */
  ENDPROC(return_to_bootrom)
  
  /*





Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH u-boot-mvebu 19/31] arm: mvebu: Mark return_to_bootrom() as a noreturn function

[Stefan Roese]

On 08.07.21 19:30, Marek Behún wrote:

From: Pali Rohár 

This function does not return, so add the appropriate compiler flag.

Signed-off-by: Pali Rohár 
Reviewed-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  arch/arm/mach-mvebu/include/mach/cpu.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h 
b/arch/arm/mach-mvebu/include/mach/cpu.h
index 52473ade7a..79858858c2 100644
--- a/arch/arm/mach-mvebu/include/mach/cpu.h
+++ b/arch/arm/mach-mvebu/include/mach/cpu.h
@@ -142,7 +142,7 @@ int mvebu_mbus_probe(struct mbus_win windows[], int count);
  int mvebu_soc_family(void);
  u32 mvebu_get_nand_clock(void);
  
-void return_to_bootrom(void);

+void __noreturn return_to_bootrom(void);
  
  #ifndef CONFIG_DM_MMC

  int mv_sdh_init(unsigned long regbase, u32 max_clk, u32 min_clk, u32 quirks);




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH u-boot-mvebu 20/31] arm: mvebu: Implement return_to_bootrom() via U-Boot's SPL framework

[Stefan Roese]

On 08.07.21 19:30, Marek Behún wrote:

From: Pali Rohár 

U-Boot's SPL framework already has an API for loading U-Boot via
BootROM.

Implement the function board_return_to_bootrom() for mvebu SPL code.

Signed-off-by: Pali Rohár 
Reviewed-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  arch/arm/mach-mvebu/Kconfig |  4 
  arch/arm/mach-mvebu/spl.c   | 12 
  2 files changed, 16 insertions(+)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index cda65f7478..2133d9a172 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -257,6 +257,7 @@ config MVEBU_SPL_BOOT_DEVICE_SPI
select SPL_SPI_FLASH_SUPPORT
select SPL_SPI_LOAD
select SPL_SPI_SUPPORT
+   select SPL_BOOTROM_SUPPORT
  
  config MVEBU_SPL_BOOT_DEVICE_MMC

bool "SDIO/MMC card"
@@ -267,14 +268,17 @@ config MVEBU_SPL_BOOT_DEVICE_MMC
select SPL_GPIO_SUPPORT
select SPL_LIBDISK_SUPPORT
select SPL_MMC_SUPPORT
+   select SPL_BOOTROM_SUPPORT
  
  config MVEBU_SPL_BOOT_DEVICE_SATA

bool "SATA"
select SPL_SATA_SUPPORT
select SPL_LIBDISK_SUPPORT
+   select SPL_BOOTROM_SUPPORT
  
  config MVEBU_SPL_BOOT_DEVICE_UART

bool "UART"
+   select SPL_BOOTROM_SUPPORT
  
  endchoice
  
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c

index 16ebb7a59e..836eb18889 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -79,6 +79,18 @@ u32 spl_boot_device(void)
return get_boot_device();
  }
  
+int board_return_to_bootrom(struct spl_image_info *spl_image,

+   struct spl_boot_device *bootdev)
+{
+   u32 *regs = *(u32 **)CONFIG_SPL_BOOTROM_SAVE;
+
+   printf("Returning to BootROM (return address 0x%08x)...\n", regs[13]);
+   return_to_bootrom();
+
+   /* NOTREACHED - return_to_bootrom() does not return */
+   hang();
+}
+
  void board_init_f(ulong dummy)
  {
int ret;




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH u-boot-mvebu 21/31] arm: mvebu: Use U-Boot's SPL BootROM framework for booting from NAND/UART

[Stefan Roese]

On 08.07.21 19:30, Marek Behún wrote:

From: Pali Rohár 

Current code uses hack in board_init_f() which calls return_to_bootrom()
to skip U-Boot SPL code and return back to BootROM to load U-Boot via
UART or from NAND.

This change migrates that hack from the board_init_f() function and
changes it to return BOOT_DEVICE_BOOTROM instead of returning to BootROM
directly, so that U-Boot's SPL framework is used for returning to
BootROM.

Signed-off-by: Pali Rohár 
Reviewed-by: Marek Behún 
---
  arch/arm/mach-mvebu/spl.c | 48 ---
  1 file changed, 25 insertions(+), 23 deletions(-)

diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 836eb18889..3551c9de42 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -76,7 +76,31 @@ static u32 get_boot_device(void)
  
  u32 spl_boot_device(void)

  {
-   return get_boot_device();
+   u32 boot_device = get_boot_device();
+
+   /*
+* Return to the BootROM to continue the Marvell xmodem
+* UART boot protocol. As initiated by the kwboot tool.
+*
+* This can only be done by the BootROM and not by the
+* U-Boot SPL infrastructure, since the beginning of the
+* image is already read and interpreted by the BootROM.
+* SPL has no chance to receive this information. So we
+* need to return to the BootROM to enable this xmodem
+* UART download.


The comment needs some updates as the SPL infrastructure is now used.
Could you please update it accordingly in v2?

Other than this:

Reviewed-by: Stefan Roese 

Thanks,
Stefan



+*
+* If booting from NAND lets let the BootROM load the
+* rest of the bootloader.
+*/
+   switch (boot_device) {
+   case BOOT_DEVICE_UART:
+#if defined(CONFIG_ARMADA_38X)
+   case BOOT_DEVICE_NAND:
+#endif
+   return BOOT_DEVICE_BOOTROM;
+   default:
+   return boot_device;
+   }
  }
  
  int board_return_to_bootrom(struct spl_image_info *spl_image,

@@ -147,26 +171,4 @@ void board_init_f(ulong dummy)
  
  	/* Update read timing control for PCIe */

mv_rtc_config();
-
-   /*
-* Return to the BootROM to continue the Marvell xmodem
-* UART boot protocol. As initiated by the kwboot tool.
-*
-* This can only be done by the BootROM and not by the
-* U-Boot SPL infrastructure, since the beginning of the
-* image is already read and interpreted by the BootROM.
-* SPL has no chance to receive this information. So we
-* need to return to the BootROM to enable this xmodem
-* UART download.
-*
-* If booting from NAND lets let the BootROM load the
-* rest of the bootloader.
-*/
-   switch (get_boot_device()) {
-   case BOOT_DEVICE_UART:
-#if defined(CONFIG_ARMADA_38X)
-   case BOOT_DEVICE_NAND:
-#endif
-   return_to_bootrom();
-   }
  }




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH] riscv: booti: do not force relocation if force_reloc is not set

[Leo Liang]

On Tue, Apr 06, 2021 at 10:50:16AM +0300, Vitaly Wool wrote:
> If force_reloc flag is not set and booti is called for an address
> ouside RAM (i. e. QSPI NOR flash), we should honor that and not try
> to force relocation in a bogus fashion.
> 
> Signed-off-by: Vitaly Wool 
> ---
>  arch/riscv/lib/image.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)

Reviewed-by: Leo Yu-Chi Liang 

[PATCH 0/2] arm: allwinner: r40: add devicetree for Forlinx FETA40i-C & OKA40i-C

[Ivan Uvarov]

This patchset adds a devicetree for the Forlinx FETA40i-C SoM and OKA40i-C
carrier board/devboard, mirroring changes merged into Linux 5.14-rc1.

Signed-off-by: Ivan Uvarov 

Ivan Uvarov (2):
  arm: allwinner: r40: add pinmux settings for MMC3 and UARTs 2,4,5&7
  arm: allwinner: r40: add devicetree for Forlinx FETA40i-C & OKA40i-C

 arch/arm/dts/Makefile   |   3 +-
 arch/arm/dts/sun8i-r40-feta40i.dtsi | 106 +++
 arch/arm/dts/sun8i-r40-oka40i-c.dts | 203 
 arch/arm/dts/sun8i-r40.dtsi |  43 ++
 configs/OKA40i_defconfig|  35 +
 5 files changed, 389 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/sun8i-r40-feta40i.dtsi
 create mode 100644 arch/arm/dts/sun8i-r40-oka40i-c.dts
 create mode 100644 configs/OKA40i_defconfig

-- 
2.32.0

u-boot@lists.denx.de

[Ivan Uvarov]

The Forlinx OKA40i-C devboard makes use of UARTs 0,2,3,4,5 and 7 of the R40
SoC, of which UART 0 is connected to an RS232 converter, UART 5 routed to
an RS485 converter, and the rest broken out directly via labeled headers.
The board also contains a micro-SD slot connected to SDC3.

This patch adds settings to R40's pinmux node for those UARTs that were not
already mapped, which would allow us to make use of all available UARTs and
the micro-SD slot on this board in a further patch.

The patch also adds the /omit-if-no-ref/ keyword to the existing nodes for
UART0 and UART3 for consistency.

Signed-off-by: Ivan Uvarov 

 1 file changed, 43 insertions(+)

diff --git a/arch/arm/dts/sun8i-r40.dtsi b/arch/arm/dts/sun8i-r40.dtsi
index d5ad3b9efd..51031a0e59 100644
--- a/arch/arm/dts/sun8i-r40.dtsi
+++ b/arch/arm/dts/sun8i-r40.dtsi
@@ -357,6 +357,8 @@
clock-names = "ahb", "mmc";
resets = <&ccu RST_BUS_MMC3>;
reset-names = "ahb";
+   pinctrl-0 = <&mmc3_pins>;
+   pinctrl-names = "default";
interrupts = ;
status = "disabled";
#address-cells = <1>;
@@ -601,6 +603,14 @@
bias-pull-up;
};
 
+   mmc3_pins: mmc3-pins {
+   pins = "PI4", "PI5", "PI6",
+  "PI7", "PI8", "PI9";
+   function = "mmc3";
+   drive-strength = <30>;
+   bias-pull-up;
+   };
+
/omit-if-no-ref/
spi0_pc_pins: spi0-pc-pins {
pins = "PC0", "PC1", "PC2";
@@ -631,20 +641,53 @@
function = "spi1";
};
 
+   /omit-if-no-ref/
uart0_pb_pins: uart0-pb-pins {
pins = "PB22", "PB23";
function = "uart0";
};
 
+   /omit-if-no-ref/
+   uart2_pi_pins: uart2-pi-pins {
+   pins = "PI18", "PI19";
+   function = "uart2";
+   };
+
+   /omit-if-no-ref/
+   uart2_rts_cts_pi_pins: uart2-rts-cts-pi-pins{
+   pins = "PI16", "PI17";
+   function = "uart2";
+   };
+
+   /omit-if-no-ref/
uart3_pg_pins: uart3-pg-pins {
pins = "PG6", "PG7";
function = "uart3";
};
 
+   /omit-if-no-ref/
uart3_rts_cts_pg_pins: uart3-rts-cts-pg-pins {
pins = "PG8", "PG9";
function = "uart3";
};
+
+   /omit-if-no-ref/
+   uart4_pg_pins: uart4-pg-pins {
+   pins = "PG10", "PG11";
+   function = "uart4";
+   };
+
+   /omit-if-no-ref/
+   uart5_ph_pins: uart5-ph-pins {
+   pins = "PH6", "PH7";
+   function = "uart5";
+   };
+
+   /omit-if-no-ref/
+   uart7_pi_pins: uart7-pi-pins {
+   pins = "PI20", "PI21";
+   function = "uart7";
+   };
};
 
wdt: watchdog@1c20c90 {
-- 
2.32.0

[PATCH 2/2] arm: allwinner: r40: add devicetree for Forlinx FETA40i-C & OKA40i-C

[Ivan Uvarov]

The FETA40i-C is a SoM by Forlinx based on the Allwinner R40/A40i.

SoM specifications:

- SoC: R40 or A40i
- PMIC: AXP221S
- RAM: 1GiB/2GiB DDR3 (dual-rank)
- eMMC: 8GB,
- Mates with carrier board via four 80-pin connectors (AXK6F80337YG).

OKA40i-C is a carrier board by the same manufacturer for this SoM,
whose main purpose is as a development board with a wide variety of
peripherals:

- Power: DC5V barrel or USB OTG or 4.2V Lipo battery
- Video out: HDMI, TV out, LVDS
- WiFi+Bluetooth: RL-UM02WBS-8723BU-V1.2 (802.11 b/g/n, BT V2.1/3.0/4.0)
- Ethernet: 10/100Mbps
- Storage: µSD, fullsize SD, eMMC (on SoM), SATA
- USB: 3 x USB2.0 Host (2 via hub, 1 native), 1 x USB2.0 OTG (micro-B)
- UART: RS232, RS485, 4 3.3v uarts (of which 2 have RTS/CTS)
- Other I/O: SPI x2, TWI, SDIO header, GPIO header, JTAG header
- Mini PCIe slot with sim holder for WLAN modem
- Smart card holder
- RTC (RX8010SJ)
- Two user LEDs
- Three user buttons (via KeyADC).

This patch adds a devicetree for the aforementioned SoM and devboard.
In order to reflect the modularity of this devboard and simplify adding
support for future hardware based on the same SoM, the devicetree is split:
Everything pertaining to the SoM itself is described in a separate .dtsi
file, which is included by the devboard's .dts.

Signed-off-by: Ivan Uvarov 

 4 files changed, 346 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9fb38682e6..a6e6fd99c8 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -611,7 +611,8 @@ dtb-$(CONFIG_MACH_SUN8I_H3) += \
sun8i-h3-rervision-dvk.dtb
 dtb-$(CONFIG_MACH_SUN8I_R40) += \
sun8i-r40-bananapi-m2-ultra.dtb \
-   sun8i-v40-bananapi-m2-berry.dtb
+   sun8i-v40-bananapi-m2-berry.dtb \
+   sun8i-r40-oka40i-c.dtb
 dtb-$(CONFIG_MACH_SUN8I_V3S) += \
sun8i-s3-pinecube.dtb \
sun8i-v3s-licheepi-zero.dtb
diff --git a/arch/arm/dts/sun8i-r40-feta40i.dtsi 
b/arch/arm/dts/sun8i-r40-feta40i.dtsi
new file mode 100644
index 00..265e0fa57a
--- /dev/null
+++ b/arch/arm/dts/sun8i-r40-feta40i.dtsi
@@ -0,0 +1,106 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+// Copyright (C) 2021 Ivan Uvarov 
+// Based on the sun8i-r40-bananapi-m2-ultra.dts, which is:
+//  Copyright (C) 2017 Chen-Yu Tsai 
+//  Copyright (C) 2017 Icenowy Zheng 
+
+#include "sun8i-r40.dtsi"
+
+&i2c0 {
+   status = "okay";
+
+   axp22x: pmic@34 {
+   compatible = "x-powers,axp221";
+   reg = <0x34>;
+   interrupt-parent = <&nmi_intc>;
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   };
+};
+
+#include "axp22x.dtsi"
+
+&mmc2 {
+   vmmc-supply = <®_dcdc1>;
+   vqmmc-supply = <®_aldo2>;
+   bus-width = <8>;
+   non-removable;
+   status = "okay";
+};
+
+&pio {
+   pinctrl-names = "default";
+   pinctrl-0 = <&clk_out_a_pin>;
+   vcc-pa-supply = <®_dcdc1>;
+   vcc-pc-supply = <®_aldo2>;
+   vcc-pd-supply = <®_dcdc1>;
+   vcc-pf-supply = <®_dldo4>;
+   vcc-pg-supply = <®_dldo1>;
+};
+
+®_aldo2 {
+   regulator-always-on;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-name = "vcc-pa";
+};
+
+®_aldo3 {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "avcc";
+};
+
+®_dcdc1 {
+   regulator-always-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-3v3";
+};
+
+®_dcdc2 {
+   regulator-always-on;
+   regulator-min-microvolt = <110>;
+   regulator-max-microvolt = <110>;
+   regulator-name = "vdd-cpu";
+};
+
+®_dcdc3 {
+   regulator-always-on;
+   regulator-min-microvolt = <110>;
+   regulator-max-microvolt = <110>;
+   regulator-name = "vdd-sys";
+};
+
+®_dcdc5 {
+   regulator-always-on;
+   regulator-min-microvolt = <150>;
+   regulator-max-microvolt = <150>;
+   regulator-name = "vcc-dram";
+};
+
+®_dldo1 {
+   regulator-always-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-wifi-io";
+};
+
+®_dldo4 {
+   regulator-always-on;
+   regulator-min-microvolt = <250>;
+   regulator-max-microvolt = <250>;
+   regulator-name = "vdd2v5-sata";
+};
+
+®_eldo2 {
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   regulator-name = "vdd1v2-sata";
+};
+
+®_eldo3 {
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   regulator-name = "vcc-pe";
+};
diff --git a/arch/arm/dts/sun8i-r40-oka40i-c.dts 
b/arch/arm/dts/sun8i-r40-oka40i-c.dts
new file mode 100644
index 00..0bd1336206
--- /dev/null
+++ b/arch/arm/dts/sun8i-r40-oka40i-c.dts
@@ -0,0 +1,203 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+// C

Re: [PATCH v2 2/2] arm: imx8m: add support for Advantech RSB-3720

[Peng Fan (OSS)]

Hi Paul,

On 2021/7/15 8:50, Ying-Chun Liu wrote:

From: "Ying-Chun Liu (PaulLiu)" 

Add initial support for Advantech RSB-3720 board.
The initial support includes:
  - MMC
  - eMMC
  - I2C
  - FEC
  - Serial console

Signed-off-by: Darren Huang 
Signed-off-by: Kevin12.Chen 
Signed-off-by: Phill.Liu 
Signed-off-by: Tim Liang 
Signed-off-by: wei.zeng 
Signed-off-by: Ying-Chun Liu (PaulLiu) 
Cc: uboot-imx 
---
  arch/arm/dts/Makefile |3 +
  arch/arm/mach-imx/imx8m/Kconfig   |   15 +
  board/freescale/imx8mp_rsb3720a1/Kconfig  |   14 +
  board/freescale/imx8mp_rsb3720a1/MAINTAINERS  |7 +
  board/freescale/imx8mp_rsb3720a1/Makefile |   24 +
  .../imx8mp_rsb3720a1/imx8mp_rsb3720a1.c   |  391 
  .../imx8mp_rsb3720a1/imximage-8mp-lpddr4.cfg  |   11 +
  .../lpddr4_timing_rsb3720a1_4G.c  | 1848 
  .../lpddr4_timing_rsb3720a1_6G.c  | 1875 +
  board/freescale/imx8mp_rsb3720a1/spl.c|  270 +++
  configs/imx8mp_rsb3720a1_4G_defconfig |  158 ++
  configs/imx8mp_rsb3720a1_6G_defconfig |  159 ++
  include/configs/imx8mp_rsb3720.h  |  273 +++
  13 files changed, 5048 insertions(+)
  create mode 100644 board/freescale/imx8mp_rsb3720a1/Kconfig
  create mode 100644 board/freescale/imx8mp_rsb3720a1/MAINTAINERS
  create mode 100644 board/freescale/imx8mp_rsb3720a1/Makefile
  create mode 100644 board/freescale/imx8mp_rsb3720a1/imx8mp_rsb3720a1.c
  create mode 100644 board/freescale/imx8mp_rsb3720a1/imximage-8mp-lpddr4.cfg
  create mode 100644 
board/freescale/imx8mp_rsb3720a1/lpddr4_timing_rsb3720a1_4G.c
  create mode 100644 
board/freescale/imx8mp_rsb3720a1/lpddr4_timing_rsb3720a1_6G.c
  create mode 100644 board/freescale/imx8mp_rsb3720a1/spl.c
  create mode 100644 configs/imx8mp_rsb3720a1_4G_defconfig
  create mode 100644 configs/imx8mp_rsb3720a1_6G_defconfig
  create mode 100644 include/configs/imx8mp_rsb3720.h


freescale/nxp is not the vendor is the board I think.
But if you prefer to leave it here, it should be ok.



diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 708ce2d094..ba458f3909 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1118,6 +1118,9 @@ dtb-$(CONFIG_TARGET_DURIAN) += phytium-durian.dtb
  dtb-$(CONFIG_TARGET_PRESIDIO_ASIC) += ca-presidio-engboard.dtb
  
  dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE) += imx8mm-cl-iot-gate.dtb

+ifneq 
($(CONFIG_TARGET_IMX8MP_RSB3720A1_4G)$(CONFIG_TARGET_IMX8MP_RSB3720A1_6G),)
+dtb-y += imx8mp-rsb3720-a1.dtb
+endif
  
  dtb-$(CONFIG_TARGET_EA_LPC3250DEVKITV2) += lpc3250-ea3250.dtb
  
diff --git a/arch/arm/mach-imx/imx8m/Kconfig b/arch/arm/mach-imx/imx8m/Kconfig

index 0669363c0f..042efb1695 100644
--- a/arch/arm/mach-imx/imx8m/Kconfig
+++ b/arch/arm/mach-imx/imx8m/Kconfig
@@ -137,6 +137,20 @@ config TARGET_IMX8MM_CL_IOT_GATE
select IMX8MM
select SUPPORT_SPL
select IMX8M_LPDDR4
+
+config TARGET_IMX8MP_RSB3720A1_4G
+   bool "Support i.MX8MP RSB3720A1 4G"
+   select BINMAN
+   select IMX8MP
+   select SUPPORT_SPL
+   select IMX8M_LPDDR4
+
+config TARGET_IMX8MP_RSB3720A1_6G
+   bool "Support i.MX8MP RSB3720A1 6G"
+   select BINMAN
+   select IMX8MP
+   select SUPPORT_SPL
+   select IMX8M_LPDDR4
  endchoice
  
  source "board/beacon/imx8mm/Kconfig"

@@ -147,6 +161,7 @@ source "board/freescale/imx8mq_evk/Kconfig"
  source "board/freescale/imx8mm_evk/Kconfig"
  source "board/freescale/imx8mn_evk/Kconfig"
  source "board/freescale/imx8mp_evk/Kconfig"
+source "board/freescale/imx8mp_rsb3720a1/Kconfig"
  source "board/gateworks/venice/Kconfig"
  source "board/google/imx8mq_phanbell/Kconfig"
  source "board/phytec/phycore_imx8mm/Kconfig"
diff --git a/board/freescale/imx8mp_rsb3720a1/Kconfig 
b/board/freescale/imx8mp_rsb3720a1/Kconfig
new file mode 100644
index 00..62c391ccca
--- /dev/null
+++ b/board/freescale/imx8mp_rsb3720a1/Kconfig
@@ -0,0 +1,14 @@
+if TARGET_IMX8MP_RSB3720A1_4G || TARGET_IMX8MP_RSB3720A1_6G
+
+config SYS_BOARD
+   default "imx8mp_rsb3720a1"
+
+config SYS_VENDOR
+   default "freescale"
+
+config SYS_CONFIG_NAME
+   default "imx8mp_rsb3720"
+
+source "board/freescale/common/Kconfig"
+
+endif
diff --git a/board/freescale/imx8mp_rsb3720a1/MAINTAINERS 
b/board/freescale/imx8mp_rsb3720a1/MAINTAINERS
new file mode 100644
index 00..e806b770a5
--- /dev/null
+++ b/board/freescale/imx8mp_rsb3720a1/MAINTAINERS
@@ -0,0 +1,7 @@
+i.MX8MP RSB3720 BOARD
+M: Ying-Chun Liu (PaulLiu) 
+S: Maintained
+F: board/freescale/imx8mp_rsb3720a1/
+F: include/configs/imx8mp_rsb3720a1.h
+F: configs/imx8mp_rsb3720a1_4G_defconfig
+F: configs/imx8mp_rsb3720a1_6G_defconfig
diff --git a/board/freescale/imx8mp_rsb3720a1/Makefile 
b/board/freescale/imx8mp_rsb3720a1/Makefile
new file mode 100644
index 00..ae5b8b83eb
--- /dev/null
+++ b/board/freescale/imx8mp_rsb3720a1/Makefile
@@ -0,0 +1,24 @@
+#
+# Copyr

Re: [PATCH 1/3] arm: mvebu: Espressobin: Fix setting $fdtfile env

[Stefan Roese]

On 14.07.21 16:37, Pali Rohár wrote:

Ensure that 'env default -a' always set correct value to $fdtfile, even
when custom user variable is already stored in non-volatile env storage
(means that env_get("fdtfile") call returns non-NULL value).

As default value is now correctly set like if specified at compile time in
CONFIG_EXTRA_ENV_SETTINGS, there is no need to set $fdtfile explicitly via
env_set("fdtfile", ...) call.

So remove wrong skip based on env_get("fdtfile") and then also unneeded
env_set("fdtfile", ...) call.

Fixes: c4df0f6f315c ("arm: mvebu: Espressobin: Set default value for $fdtfile env 
variable")
Signed-off-by: Pali Rohár 


All patches:

Applied to u-boot-marvell/master

Thanks,
Stefan


---
  board/Marvell/mvebu_armada-37xx/board.c | 7 ---
  1 file changed, 7 deletions(-)

diff --git a/board/Marvell/mvebu_armada-37xx/board.c 
b/board/Marvell/mvebu_armada-37xx/board.c
index 6a0e2fc3cd8f..53408d37af9b 100644
--- a/board/Marvell/mvebu_armada-37xx/board.c
+++ b/board/Marvell/mvebu_armada-37xx/board.c
@@ -133,9 +133,6 @@ int board_late_init(void)
device_unbind(dev);
}
  
-	if (env_get("fdtfile"))

-   return 0;
-
/* Ensure that 'env default -a' set correct value to $fdtfile */
if (ddr4 && emmc)
strcpy(ptr, 
"fdtfile=marvell/armada-3720-espressobin-v7-emmc.dtb");
@@ -146,10 +143,6 @@ int board_late_init(void)
else
strcpy(ptr, "fdtfile=marvell/armada-3720-espressobin.dtb");
  
-	/* If $fdtfile was not set explicitly by user then set default value */

-   if (!env_get("fdtfile"))
-   env_set("fdtfile", ptr + sizeof("fdtfile="));
-
return 0;
  }
  #endif




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH u-boot-mvebu 1/2] arm: mvebu: turris_omnia: force 40 MHz speed on SPI NOR

[Stefan Roese]

On 09.07.21 16:56, Marek Behún wrote:

Commit e2e95e5e2542 ("spi: Update speed/mode on change") changed the
boot time on Turris Omnia from ~2.3s to over 8s, due to SPL loading main
U-Boot from SPI NOR at 1 MHz instead of 40 MHz.

This is because the SPL code passes the CONFIG_SF_DEFAULT_SPEED option
to spi_flash_probe(), and with the above commit spi_flash_probe() starts
prefering this parameter instead of the one specified in device-tree.

The proper solution here would probably be to fix the SF subsystem to
prefer the frequency specified in the device-tree, if it is present, but
I am not sure what else will be affected on other boards with such a
change. So until then we need a more simple fix.

Since the CONFIG_SF_DEFAULT_SPEED option is used by the code, put the
correct value there for Turris Omnia. Also put the correct value to
CONFIG_SF_DEFAULT_MODE and use 40 MHz when reading environment.

Signed-off-by: Marek Behún 
Cc: Stefan Roese 
Cc: Tom Rini 
Cc: Marek Vasut 
Cc: Jagan Teki 
Cc: Patrick Delaunay 
Cc: Pali Rohár 


All patches:

Applied to u-boot-marvell/master

Thanks,
Stefan


---
  configs/turris_omnia_defconfig | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig
index 57ab384f63..ec2294699f 100644
--- a/configs/turris_omnia_defconfig
+++ b/configs/turris_omnia_defconfig
@@ -56,7 +56,7 @@ CONFIG_CMD_FS_UUID=y
  # CONFIG_SPL_PARTITION_UUIDS is not set
  CONFIG_ENV_OVERWRITE=y
  CONFIG_USE_ENV_SPI_MAX_HZ=y
-CONFIG_ENV_SPI_MAX_HZ=5000
+CONFIG_ENV_SPI_MAX_HZ=4000
  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
  CONFIG_SPL_OF_TRANSLATE=y
  CONFIG_AHCI_PCI=y
@@ -67,6 +67,8 @@ CONFIG_MMC_SDHCI=y
  CONFIG_MMC_SDHCI_MV=y
  CONFIG_SPI_FLASH_MACRONIX=y
  CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SF_DEFAULT_MODE=0x0
+CONFIG_SF_DEFAULT_SPEED=4000
  CONFIG_PHY_MARVELL=y
  CONFIG_PHY_GIGE=y
  CONFIG_MVNETA=y




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: [PATCH 1/3] arm: a37xx: pci: Extend validation for PCIe resources and oubound windows

[Stefan Roese]

On 08.07.21 20:18, Pali Rohár wrote:

Remapped address of PCIe outbound window may have set only bits from the
mask. Add additional check that remapped address which is calculated from
PCIe bus address specified in DTS file is valid.

Remove also useless clearing of low 16 bits in win_mask. As win_size is
power of two and is at least 0x1 it means that it always has zero low
16 bits.

Signed-off-by: Pali Rohár 


All patches:

Applied to u-boot-marvell/master

Thanks,
Stefan


---
  drivers/pci/pci-aardvark.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/pci-aardvark.c b/drivers/pci/pci-aardvark.c
index 96aa039bdc26..77ce9d0c8d87 100644
--- a/drivers/pci/pci-aardvark.c
+++ b/drivers/pci/pci-aardvark.c
@@ -609,21 +609,22 @@ static void pcie_advk_set_ob_region(struct pcie_advk 
*pcie, int *wins,
 * match with given mask.
 * So every PCIe window size must be a power of two and every start
 * address must be aligned to window size. Minimal size is 64 KiB
-* because lower 16 bits of mask must be zero.
+* because lower 16 bits of mask must be zero. Remapped address
+* may have set only bits from the mask.
 */
while (*wins < OB_WIN_COUNT && size > 0) {
/* Calculate the largest aligned window size */
win_size = (1ULL << (fls64(size) - 1)) |
   (phys_start ? (1ULL << __ffs64(phys_start)) : 0);
win_size = 1ULL << __ffs64(win_size);
-   if (win_size < 0x1)
+   win_mask = ~(win_size - 1);
+   if (win_size < 0x1 || (bus_start & ~win_mask))
break;
  
  		dev_dbg(pcie->dev,

"Configuring PCIe window %d: [0x%llx-0x%llx] as 0x%x\n",
*wins, (u64)phys_start, (u64)phys_start + win_size,
actions);
-   win_mask = ~(win_size - 1) & ~0x;
pcie_advk_set_ob_win(pcie, *wins, phys_start, bus_start,
 win_mask, actions);
  




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Please pull u-boot-marvell/master

[Stefan Roese]

Hi Tom,

please pull the next batch of Marvell MVEBU related patches. Here the
summary log:


- Turris_omnia/mox: SPI NOR and MTD related changes / fixes (Marek)
- a37xx: pci: Misc fixes / optimizations (Pali)
- Espressobin: Fix setting $fdtfile env & changes in MMC detection
  (Pali)
- MMC: mmc_get_op_cond: Allow quiet detection of eMMC (Pali)


Here the Azure build, without any issues:

https://dev.azure.com/sr0718/u-boot/_build/results?buildId=98&view=results

Thanks,
Stefan


The following changes since commit c11f5abce84f630c92304683d5bde3204c5612c4:

  Merge branch '2021-07-14-build-and-host-updates' (2021-07-14 20:10:34 
-0400)


are available in the Git repository at:

  g...@source.denx.de:u-boot/custodians/u-boot-marvell.git

for you to fetch changes up to a4c577f981569bf34e997cd85618f922409d6b2f:

  mmc: mmc_get_op_cond: Allow quiet detection of eMMC (2021-07-15 
10:53:11 +0200)



Marek Behún (3):
  arm: mvebu: turris_omnia: force 40 MHz speed on SPI NOR
  arm: mvebu: turris_{omnia, mox}: enable MTD command
  arm: mvebu: armada-3720: remove unused config option

Pali Rohár (6):
  arm: a37xx: pci: Extend validation for PCIe resources and oubound 
windows
  arm: a37xx: pci: Optimize a3700_fdt_fix_pcie_regions() when fixup 
offset is zero

  arm: a37xx: pci: Fix typo in comment
  arm: mvebu: Espressobin: Fix setting $fdtfile env
  arm: mvebu: Espressobin: Use function mmc_get_op_cond() for 
detecting eMMC

  mmc: mmc_get_op_cond: Allow quiet detection of eMMC

 arch/arm/mach-mvebu/armada3700/cpu.c| 4 
 board/Marvell/mvebu_armada-37xx/board.c | 9 +
 board/solidrun/mx6cuboxi/mx6cuboxi.c| 2 +-
 configs/mvebu_db-88f3720_defconfig  | 1 -
 configs/mvebu_espressobin-88f3720_defconfig | 1 -
 configs/turris_mox_defconfig| 4 +++-
 configs/turris_omnia_defconfig  | 8 +++-
 configs/uDPU_defconfig  | 1 -
 drivers/mmc/mmc.c   | 7 ---
 drivers/pci/pci-aardvark.c  | 9 +
 drivers/serial/Kconfig  | 1 +
 include/mmc.h   | 3 ++-
 12 files changed, 28 insertions(+), 22 deletions(-)

[PATCH v2] drivers: watchdog: wdt-uclass: Use IS_ENABLED for WATCHDOG_AUTOSTART

[Teresa Remmet]

There is no separate SPL/TPL config for WATCHDOG_AUTOSTART.
So use IS_ENABLED instead of CONFIG_IS_ENABLED to make watchdog
working in SPL again.

Fixes: 830d29ac3721 ("watchdog: Allow to use CONFIG_WDT without starting 
watchdog")
Signed-off-by: Teresa Remmet 
Reviewed-by: Stefan Roese 
---
Changes in v2:
- Added Fixes tag
- Added Reviewed-by

 drivers/watchdog/wdt-uclass.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c
index a0c2429e5a43..17334dbda6c9 100644
--- a/drivers/watchdog/wdt-uclass.c
+++ b/drivers/watchdog/wdt-uclass.c
@@ -53,7 +53,7 @@ int initr_watchdog(void)
4 * reset_period) / 4;
}
 
-   if (!CONFIG_IS_ENABLED(WATCHDOG_AUTOSTART)) {
+   if (!IS_ENABLED(CONFIG_WATCHDOG_AUTOSTART)) {
printf("WDT:   Not starting\n");
return 0;
}
-- 
2.25.1

Re: [PATCH v3 03/16] x86: Allow coreboot serial driver to guess the UART

[Bin Meng]

Hi Simon,

On Mon, Jun 28, 2021 at 7:51 AM Simon Glass  wrote:
>
> At present this driver relies on coreboot to provide information about
> the console UART. However if coreboot is not compiled with the UART
> enabled, the information is left out. This configuration is quite
> common, e.g. with shipping x86-based Chrome OS Chromebooks.
>
> Add a way to determine the UART settings in this case, using a
> hard-coded list of PCI IDs.
>
> Signed-off-by: Simon Glass 
> ---
>
> (no changes since v1)
>
>  drivers/serial/serial_coreboot.c | 68 
>  include/pci_ids.h|  1 +
>  2 files changed, 61 insertions(+), 8 deletions(-)
>

Based on discussion of the last version, this patch should be dropped.
I will see if I can drop it when applying.

Regards,
Bin

Re: [PATCH v3 00/16] misc: Some more misc patches

[Bin Meng]

Hi Simon,

On Wed, Jul 14, 2021 at 11:47 PM Simon Glass  wrote:
>
> Hi Bin,
>
> On Sun, 27 Jun 2021 at 17:51, Simon Glass  wrote:
> >
> > Various issues were discovered in getting Chromium OS verified boot
> > running on top of coreboot, booting into U-Boot.
> >
> > Improvements include:
> > - enable serial console if even coreboot doesn't
> > - enable cache always
> > - show the BIOS date since Chromium OS's coreboot doesn't have a version
> > - update docs
> > - allow SPI driver to work without a PCH
> > - fix mtrr command when multi-processing (CONFIG_MP) is disabled
> > - add documentation about the memory map
> >
> > Changes in v3:
> > - Fix comment to menion u-boot,dm-tpl
> > - Fix 'u-boot,dm-pre-tpl' (it should be u-boot,dm-tpl)
> >
> > Changes in v2:
> > - Add a comment about the cases
> > - Reorder declaration and use bios_date for the variable name
> > - Add missing newline in the error path
> > - Use (ret) instead of (ret != 0) to fit with U-Boot style
> > - Convert table to reST format
> > - Add 'cros' tag since this not a generic x86 change
> > - Drop unnecessary patch 'Enable the cbsysinfo command'
> >
> > Simon Glass (16):
> >   pci: Use const for pci_find_device_id() etc.
> >   x86: pci: Allow binding of some devices before relocation
> >   x86: Allow coreboot serial driver to guess the UART
> >   spi: ich: Don't require the PCH
> >   tpm: cr50: Drop unnecessary coral headers
> >   x86: Don't set up MTRRs if previously done
> >   x86: Update the MP constants to avoid conflicts
> >   x86: Do cache set-up by default when booting from coreboot
> >   x86: coreboot: Show the BIOS date
> >   x86: coral: Allow booting from coreboot
> >   x86: Add function comments to cb_sysinfo.h
> >   x86: coreboot: Use vendor in the Kconfig
> >   x86: coreboot: Document the memory map
> >   x86: cros: Check ROM exists before building vboot
> >   dtoc: Check that a parent is not missing
> >   doc: Update documentation for cros-2021.04 release
> >
> >  arch/x86/cpu/coreboot/Kconfig|  2 +-
> >  arch/x86/cpu/i386/cpu.c  |  2 +-
> >  arch/x86/dts/chromebook_coral.dts|  2 +-
> >  arch/x86/dts/chromebook_samus.dts|  2 +-
> >  arch/x86/include/asm/cb_sysinfo.h| 16 ++
> >  arch/x86/include/asm/mp.h| 12 +++--
> >  arch/x86/lib/init_helpers.c  | 18 +--
> >  board/coreboot/coreboot/Kconfig  | 12 +++--
> >  board/coreboot/coreboot/coreboot.c   |  3 ++
> >  board/google/chromebook_coral/coral.c| 28 ++
> >  doc/board/coreboot/coreboot.rst  | 21 
> >  doc/chromium/run_vboot.rst   | 15 +++---
> >  doc/device-tree-bindings/pci/x86-pci.txt |  7 ++-
> >  drivers/pci/pci-uclass.c | 39 --
> >  drivers/serial/serial_coreboot.c | 68 +---
> >  drivers/spi/ich.c|  4 +-
> >  drivers/tpm/cr50_i2c.c   |  2 -
> >  include/dt-bindings/pci/pci.h| 12 +
> >  include/pci.h|  5 +-
> >  include/pci_ids.h|  1 +
> >  tools/dtoc/dtb_platdata.py   |  9 
> >  tools/dtoc/test/dtoc_test_noparent.dts   | 32 +++
> >  tools/dtoc/test_dtoc.py  | 10 
> >  23 files changed, 278 insertions(+), 44 deletions(-)
> >  create mode 100644 include/dt-bindings/pci/pci.h
> >  create mode 100644 tools/dtoc/test/dtoc_test_noparent.dts
> >
> > --
> > 2.32.0.93.g670b81a890-goog
> >
>
> Do you have any update on this series, please?
>

Sorry, I just applied this series.

There are many commits that have a blank line between your SoB tag and
the RB tag which I believe is caused by the patman patchwork
functionality.

I have manually removed the blank lines when applying. Would you
please fix the patman?

Regards,
Bin

Re: [PATCH v2 0/5] arm: dts: Add PMIC node for J7200

[Lokesh Vutla]

On Wed, 23 Jun 2021 16:14:49 -0500, Gowtham Tammana wrote:
> The J7200 EVM has PMIC LP876441 for supporting CPU AVS. This patchset
> adds dt nodes, compatible string, and configs to enable the
> corresponding driver.
> 
> v2:
>  - rebased the changes are reordered patches 3/4
> 
> [...]
 
Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, 
thanks!
[1/5] power: pmic: tps65941: Add compatible for LP876441
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/d4a344c393
[2/5] arm/dts: k3-j7200-r5-common: Add pmic lp876441 node
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/cbd49ed9d6
[3/5] arm/dts: k3-j7200-r5-common: Add VTM node
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/993fa93f2d
[4/5] arm/dts: k3-j7200-r5-common: Hook buck1_reg to vtm supply
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/9925c76752
[5/5] configs: j7200_evm_r5_defconfig: Enable AVS, PMIC and dependent configs
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/672758829a
 
--
Thanks and Regards,
Lokesh

Re: [PATCH v3 0/5] Add PMIC node for J7200

[Lokesh Vutla]

On Wed, 14 Jul 2021 15:52:55 -0500, Gowtham Tammana wrote:
> The J7200 EVM has PMIC LP876441 for supporting CPU AVS. This patchset
> adds dt nodes, compatible string, and configs to enable the
> corresponding driver.
> 
> v3:
>  - rebased to resolve minor conflicts against master
> 
> [...]
 
Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, 
thanks!
[1/5] power: pmic: tps65941: Add compatible for LP876441
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/d4a344c393
[2/5] arm/dts: k3-j7200-r5-common: Add pmic lp876441 node
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/cbd49ed9d6
[3/5] arm/dts: k3-j7200-r5-common: Add VTM node
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/993fa93f2d
[4/5] arm/dts: k3-j7200-r5-common: Hook buck1_reg to vtm supply
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/9925c76752
[5/5] configs: j7200_evm_r5_defconfig: Enable AVS, PMIC and dependent configs
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/672758829a
 
--
Thanks and Regards,
Lokesh

Re: [PATCH 1/2] Nokia RX-51: Add support for booting kernel in zImage format

[Lokesh Vutla]

On Fri, 18 Jun 2021 15:27:03 +0200, Pali Rohár wrote:
> Enable U-Boot bootz command and update env scripts to try loading also
> zImage file and to try booting via bootz command.
> 
> Update also lowlevel_init.S code for checking validity of zImage magic to
> correctly relocate kernel in zImage format.
> 
> This change allows U-Boot to directly boot Linux kernel without need for
> converting kernel image into U-Boot uImage format.
 
Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, 
thanks!
[1/2] Nokia RX-51: Add support for booting kernel in zImage format
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/77122d6fad
[2/2] Nokia RX-51: Load bootmenu also from uSD card
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/da523d3250
 
--
Thanks and Regards,
Lokesh

Re: [PATCH] Nokia RX-51: Add check for /lib/ld-linux.so.2 in test script

[Lokesh Vutla]

On Fri, 18 Jun 2021 15:31:08 +0200, Pali Rohár wrote:
> Unfortunately for testing is required qflasher which works only in 32-bit
> x86 mode. Apparently 64-bit x86 Azure CI has no problems as it has
> preinstalled 32-bit libraries and can execute also 32-bit x86 executables.
> 
> This change just show human readable output why nokia_rx51_test.sh test
> script fails.
 
Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, 
thanks!
[1/1] Nokia RX-51: Add check for /lib/ld-linux.so.2 in test script
  https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/f3ff72f9ff
 
--
Thanks and Regards,
Lokesh

Re: [PATCH] x86: Ensure the e820 map is installed in all cases

[Bin Meng]

On Sun, Jul 11, 2021 at 11:15 AM Simon Glass  wrote:
>
> This is a revert of a recent logic change in setup_zimage(). We do
> actually need to install this information always. Change it to install
> from the Coreboot tables if available, else the normal source.
>
> Fixes: e7bae8283fe ("x86: Allow installing an e820 when booting from 
> coreboot")
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/lib/zimage.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>

Reviewed-by: Bin Meng 

Re: [PATCH] x86: Ensure the e820 map is installed in all cases

[Bin Meng]

On Thu, Jul 15, 2021 at 7:54 PM Bin Meng  wrote:
>
> On Sun, Jul 11, 2021 at 11:15 AM Simon Glass  wrote:
> >
> > This is a revert of a recent logic change in setup_zimage(). We do
> > actually need to install this information always. Change it to install
> > from the Coreboot tables if available, else the normal source.
> >
> > Fixes: e7bae8283fe ("x86: Allow installing an e820 when booting from 
> > coreboot")
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  arch/x86/lib/zimage.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!

Re: [PATCH 1/5] efi_loader: increase eventlog buffer size

[Simon Glass]

Hi Ilias,

On Thu, 15 Jul 2021 at 00:20, Ilias Apalodimas
 wrote:
>
> On Wed, Jul 14, 2021 at 08:52:07AM -0600, Simon Glass wrote:
> > Hi Ilias,
> >
> > On Mon, 12 Jul 2021 at 03:28, Ilias Apalodimas
> >  wrote:
> > >
> > > On Mon, 12 Jul 2021 at 11:40, Masahisa Kojima
> > >  wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Sun, 11 Jul 2021 at 09:01, Simon Glass  wrote:
> > > > >
> > > > > Hi Masahisa,
> > > > >
> > > > > On Wed, 7 Jul 2021 at 20:21, Masahisa Kojima 
> > > > >  wrote:
> > > > > >
> > > > > > On Wed, 7 Jul 2021 at 22:47, Heinrich Schuchardt 
> > > > > >  wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 7/7/21 3:36 PM, Masahisa Kojima wrote:
> > > > > > > > This is a preperation to add eventlog support
> > > > > > > > described in TCG PC Client PFP spec.
> > > > > > > >
> > > > > > > > Signed-off-by: Masahisa Kojima 
> > > > > > > > ---
> > > > > > > >   lib/efi_loader/Kconfig | 2 +-
> > > > > > > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > > > > > > > index b2ab48a048..a87bf3cc98 100644
> > > > > > > > --- a/lib/efi_loader/Kconfig
> > > > > > > > +++ b/lib/efi_loader/Kconfig
> > > > > > > > @@ -327,7 +327,7 @@ config EFI_TCG2_PROTOCOL
> > > > > > > >   config EFI_TCG2_PROTOCOL_EVENTLOG_SIZE
> > > > > > > >   int "EFI_TCG2_PROTOCOL EventLog size"
> > > > > > > >   depends on EFI_TCG2_PROTOCOL
> > > > > > > > - default 4096
> > > > > > > > + default 16384
> > > > > > >
> > > > > > > I found this text in EDK II:
> > > > > > >
> > > > > > > Minimum length(in bytes) of the system preboot TCG event log 
> > > > > > > area(LAML)
> > > > > > > ---
> > > > > > >
> > > > > > > For PC Client Implementation spec up to and including 1.2 the 
> > > > > > > minimum
> > > > > > > log size is 64KB. (SecurityPkg/SecurityPkg.dec)
> > > > > >
> > > > > > Thank you for your feedback.
> > > > > > I have not checked this.
> > > > > > TCG spec also says "The Log Area Minimum Length for the TCG event 
> > > > > > log
> > > > > > MUST be at least 64KB." in ACPI chapter.
> > > > > > I will update to set 64KB as default.
> > > > > >
> > > > >
> > > > > Is this the same as the BLOBLISTT_TPM2_TCG_LOG thing? If so, can we
> > > > > put this in the bloblist? We want to avoid adding code in EFI which is
> > > > > in U-Boot.
> > > >
> > > > I think bloblist is used for data passing from SPL/TPL to u-boot.
> > > > Is your comment saying that the eventlog generated
> > > > in u-boot(done in efi_tcg2.c with this patch series) should be appended
> > > > into the buffer pointed by BLOBLISTT_TPM2_TCG_LOG blob?
> > > >
> > >
> > > Even in that case the eventlog can't be appended.  The TCG eventlog
> > > hould be copied into EFI memory, since the kernel expects to find it
> > > there.
> >
> > Typically bloblist is relocated by U-Boot. There are lots of tables
> > that must be passed to linux, including ACPI and SMBIOS. With bloblist
> > they can all be in one place.
>
>
> The eventlog must be allocated in EFI memory though.

There is really only one memory in U-Boot. I feel that all stuff that
EFI passes on to linux should be in a single bloblist.

>
> >
> > > What we could do is copy the contents of that buffer to the eventlog.
> > > Depending on what that buffer already has (e.g the starting header of
> > > the eventlog), we might need to strip it from the efi_tcg.c code.
> >
> > I'm not really sure, but the eventlog is not just EFI thing, right?
> > The code should be generic.
>
> It's purely an EFI construct.  Specifically the entire spec, and even the  log
> format for the eventlog are described in
> https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf

For some reason I have seen this in ACPI, or something similar.
Perhaps I was getting confused.

We need to find ways to implement EFI things with generic code. I'm
not 100% sure about this particular thing, but since we already create
something similar with ACPI I think we should at least look at doing
it in one place.

Regards,
Simon

RE: [EXT] Re: [RFC 1/7] ARM: mvebu: a38x: Correct mismatched bound warnings

[Kostya Porotchkin]

Hi Pali and Stefan,

> -Original Message-
> From: Stefan Roese 
> Sent: Thursday, July 15, 2021 11:00
> To: Pali Rohár ; Tom Rini 
> Cc: u-boot@lists.denx.de; Marek Behún ; Kostya
> Porotchkin 
> Subject: [EXT] Re: [RFC 1/7] ARM: mvebu: a38x: Correct mismatched bound
> warnings
> 
> External Email
> 
> --
> Hi Pali,
> Hi Kosta,
> 
> On 14.07.21 22:52, Pali Rohár wrote:
> > On Monday 03 May 2021 16:48:53 Tom Rini wrote:
> >> With gcc-11 we see:
> >> drivers/ddr/marvell/a38x/ddr3_debug.c:672:47: error: argument 2 of type
> 'u32[5]' {aka 'unsigned int[5]'} with mismatched bound [-Werror=array-
> parameter=]
> >>672 | int ddr3_tip_read_adll_value(u32 dev_num, u32
> pup_values[MAX_INTERFACE_NUM * MAX_BUS_NUM],
> >>|
> ^~~
> >> In file included from
> drivers/ddr/marvell/a38x/ddr3_training_ip_engine.h:10,
> >>   from drivers/ddr/marvell/a38x/ddr3_init.h:17,
> >>   from drivers/ddr/marvell/a38x/ddr3_debug.c:6:
> >> drivers/ddr/marvell/a38x/ddr3_training_ip_flow.h:116:47: note:
> >> previously declared as 'u32[]' {aka 'unsigned int[]'}
> >>
> >> And similar warnings.  Correct these by updating the prototype.
> >> Remove the prototype for ddr3_tip_read_pup_value as it is unused.
> >>
> >> Signed-off-by: Tom Rini 
> >> ---
> >>   drivers/ddr/marvell/a38x/ddr3_training_ip_flow.h | 10 +++---
> >>   1 file changed, 7 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/ddr/marvell/a38x/ddr3_training_ip_flow.h
> >> b/drivers/ddr/marvell/a38x/ddr3_training_ip_flow.h
> >> index ab152cb455e9..55832a55405b 100644
> >> --- a/drivers/ddr/marvell/a38x/ddr3_training_ip_flow.h
> >> +++ b/drivers/ddr/marvell/a38x/ddr3_training_ip_flow.h
> >> @@ -8,6 +8,7 @@
> >>
> >>   #include "ddr3_training_ip.h"
> >>   #include "ddr3_training_ip_db.h"
> >> +#include "mv_ddr_plat.h"
> >>
> >>   #define KILLER_PATTERN_LENGTH32
> >>   #define EXT_ACCESS_BURST_LENGTH  8
> >> @@ -112,9 +113,12 @@ int ddr3_tip_configure_odpg(u32 dev_num, enum
> hws_access_type access_type,
> >>   int ddr3_tip_write_mrs_cmd(u32 dev_num, u32 *cs_mask_arr, enum
> mr_number mr_num, u32 data, u32 mask);
> >>   int ddr3_tip_write_cs_result(u32 dev_num, u32 offset);
> >>   int ddr3_tip_reset_fifo_ptr(u32 dev_num); -int
> >> ddr3_tip_read_pup_value(u32 dev_num, u32 pup_values[], int reg_addr,
> >> u32 mask); -int ddr3_tip_read_adll_value(u32 dev_num, u32
> >> pup_values[], u32 reg_addr, u32 mask); -int
> >> ddr3_tip_write_adll_value(u32 dev_num, u32 pup_values[], u32
> >> reg_addr);
> >> +int ddr3_tip_read_adll_value(u32 dev_num,
> >> +   u32 pup_values[MAX_INTERFACE_NUM *
> MAX_BUS_NUM],
> >> +   u32 reg_addr, u32 mask);
> >> +int ddr3_tip_write_adll_value(u32 dev_num,
> >> +u32 pup_values[MAX_INTERFACE_NUM *
> MAX_BUS_NUM],
> >> +u32 reg_addr);
> >>   int ddr3_tip_tune_training_params(u32 dev_num, struct
> >> tune_train_params *params);
> >>
> >>   #endif /* _DDR3_TRAINING_IP_FLOW_H_ */
> >
> > CC Stefan, Marek, Konstantin
> >
> > Could you please send this patch to upstream?
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Marvel
> > lEmbeddedProcessors_mv-2Dddr-
> 2Dmarvell&d=DwIDaQ&c=nKjWec2b6R0mOyPaz7xt
> > fQ&r=-
> N9sN4p5NSr0JGQoQ_2UCOgAqajG99W1EbSOww0WU8o&m=uCuiUzuJ-
> xKl2xMLf1k
> > 3uSHRcVkxkdrRn7NXczjBNrk&s=IXYIGGlj-Y6Z9-VWGf8iWAiGQAbAYt-
> 3zROqOhn32Sk
> > &e=
> >
> > Any change done in drivers/ddr/marvell/a38x cause issue in future code
> > synchronization with upstream repository.
> 
> Sure. It absolutely makes sense to try to keep these repo's at least a bit in
> sync.
> 
> Kosta, could you please apply this patch to your "mv-ddr-marvell"
> repo as well?
[KP] I am porting this to our development stream and once merged, will issue a 
patch to Github.

Regards
Kosta
> 
> Thanks,
> Stefan

Re: [PATCH 0/5] stm32mp1: handle TF-A boot with FIP

[Patrick DELAUNAY]

Hi Simon

On 7/11/21 2:01 AM, Simon Glass wrote:

Hi Patrick,

On Thu, 8 Jul 2021 at 03:17, Patrick Delaunay
 wrote:


In next TF-A version the stm32mp1 platform will support the Firmware
Image Package (FIP) [1], a container filled with:
- the U-Boot binary = u-boot-nodtb.bin
- the U-Boot device tree = u-boot.dtb
- the Secure OS (OP-TEE) or the secure monitor (SP_MIN)

That sounds like a job for FIT?



Yes it is the same purpose but at TF-A BL2 level, so before U-Boot 
execution.



In the STM32MP boot chain with TF-A, we have:

1/ Rom code load TF-A BL2 in embedded RAM

  => it running in secure world, initializing the DDR

2/ TF-A BL2 load the next SW component from FIP containers in DDR

    a) secure world, OP-TEE for example, including key infrastructure.

    b) normal world = OS loader : U-Boot + device tree


But SPL is not used


TF-A BL2 can be see as SPL a remplacant and

a FIP loaded by TF-A BL2 is equivalent to FIT loaded by SPL,

it the container supported by trusted firmware


But even in this use case FIT can be use to load kernel by U-Boot...


It was a long debate on the preferred first stage bootloader

for STMicroelectronics ARMv7 platform, between TF-A BL2 and SPL .


Today the preferred solution is TF-A BL2 with FIP, for secure boot

support and long term integration with  OP-TEE, even is we lost

the falcon mode.




Regards,
Simon



Regards

Patrick

Please pull u-boot-x86

[Bin Meng]

Hi Tom,

This PR includes the following changes for v2021.10:

- x86: various improvements made in getting Chromium OS verified boot
  running on top of coreboot, booting into U-Boot.

Azure results: PASS
https://dev.azure.com/bmeng/GitHub/_build/results?buildId=383&view=results

The following changes since commit c11f5abce84f630c92304683d5bde3204c5612c4:

  Merge branch '2021-07-14-build-and-host-updates' (2021-07-14 20:10:34 -0400)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-x86

for you to fetch changes up to 2f91fc40039d2ef6f433d5c56c4f4701975f510f:

  x86: Ensure the e820 map is installed in all cases (2021-07-15 19:56:16 +0800)


Simon Glass (16):
  pci: Use const for pci_find_device_id() etc.
  x86: pci: Allow binding of some devices before relocation
  spi: ich: Don't require the PCH
  tpm: cr50: Drop unnecessary coral headers
  x86: Don't set up MTRRs if previously done
  x86: Update the MP constants to avoid conflicts
  x86: Do cache set-up by default when booting from coreboot
  x86: coreboot: Show the BIOS date
  x86: coral: Allow booting from coreboot
  x86: Add function comments to cb_sysinfo.h
  x86: coreboot: Use vendor in the Kconfig
  x86: coreboot: Document the memory map
  x86: cros: Check ROM exists before building vboot
  dtoc: Check that a parent is not missing
  doc: Update documentation for cros-2021.04 release
  x86: Ensure the e820 map is installed in all cases

 arch/x86/cpu/coreboot/Kconfig|  2 +-
 arch/x86/cpu/i386/cpu.c  |  2 +-
 arch/x86/dts/chromebook_coral.dts|  2 +-
 arch/x86/dts/chromebook_samus.dts|  2 +-
 arch/x86/include/asm/cb_sysinfo.h| 16 
 arch/x86/include/asm/mp.h| 12 
 arch/x86/lib/init_helpers.c  | 18 ++
 arch/x86/lib/zimage.c|  8 
 board/coreboot/coreboot/Kconfig  | 12 
 board/coreboot/coreboot/coreboot.c   |  3 +++
 board/google/chromebook_coral/coral.c| 28 
 doc/board/coreboot/coreboot.rst  | 21 +
 doc/chromium/run_vboot.rst   | 15 +++
 doc/device-tree-bindings/pci/x86-pci.txt |  7 ++-
 drivers/pci/pci-uclass.c | 39
+++
 drivers/spi/ich.c|  4 ++--
 drivers/tpm/cr50_i2c.c   |  2 --
 include/dt-bindings/pci/pci.h| 12 
 include/pci.h|  5 ++---
 tools/dtoc/dtb_platdata.py   |  9 +
 tools/dtoc/test/dtoc_test_noparent.dts   | 32 
 tools/dtoc/test_dtoc.py  | 10 ++
 22 files changed, 221 insertions(+), 40 deletions(-)
 create mode 100644 include/dt-bindings/pci/pci.h
 create mode 100644 tools/dtoc/test/dtoc_test_noparent.dts

Regards,
Bin

Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

[François Ozog]

On Sat, 10 Jul 2021 at 01:07, Julius Werner  wrote:

> > - "bloblist" is a general term for concept of linked list and it's not
> exactly U-boot implementation. The proposed solution will cause some degree
> of changes in all the participating projects. For backward compatibility
> issue, we have already though about it and proposed to have build configs
> which will be enabled by platform integrators.
>
> Okay, let's gather the requirements and then decide how the existing
> system needs to be expanded to meet them. Please keep me in the loop
> on those discussions.
>
> > > U-Boot has an established mechanism which is used in particular on all
> chrome
> > > books in both x86 and Arm environments.  I have the impression that
> > > U-Boot is the typical BL33 so I would import the mechanism into TFA,
> > > not the other way round.
>
> There has been no Chromebook (x86 or Arm) shipping with U-Boot since
> 2013 (before TF-A existed). In fact, Chromebooks are all running
> coreboot today and using the bl_aux_params mechanism (it's 3 SoC
> vendors, more than 3 SoCs, but the parameter code is shared at the
> vendor level), and one of my concerns here is trying to limit
> disruption to those existing setups. I don't have enough data to say
> what the "typical" boot flow among all TF-A devices in existence is,
> but at least for the millions of Chromebooks out there it is coreboot
> + TF-A, not U-Boot.
>
My bad! I candidly inferred from Chromebook reference in U-Boot and Simon's
VBE proposal that U-Boot was used.


-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.o...@linaro.org | Skype: ffozog

Re: [PATCH 1/5] efi_loader: increase eventlog buffer size

[Heinrich Schuchardt]

On 7/15/21 2:57 PM, Simon Glass wrote:

Hi Ilias,

On Thu, 15 Jul 2021 at 00:20, Ilias Apalodimas
 wrote:


On Wed, Jul 14, 2021 at 08:52:07AM -0600, Simon Glass wrote:

Hi Ilias,

On Mon, 12 Jul 2021 at 03:28, Ilias Apalodimas
 wrote:


On Mon, 12 Jul 2021 at 11:40, Masahisa Kojima
 wrote:


Hi Simon,

On Sun, 11 Jul 2021 at 09:01, Simon Glass  wrote:


Hi Masahisa,

On Wed, 7 Jul 2021 at 20:21, Masahisa Kojima  wrote:


On Wed, 7 Jul 2021 at 22:47, Heinrich Schuchardt  wrote:




On 7/7/21 3:36 PM, Masahisa Kojima wrote:

This is a preperation to add eventlog support
described in TCG PC Client PFP spec.

Signed-off-by: Masahisa Kojima 
---
   lib/efi_loader/Kconfig | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index b2ab48a048..a87bf3cc98 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -327,7 +327,7 @@ config EFI_TCG2_PROTOCOL
   config EFI_TCG2_PROTOCOL_EVENTLOG_SIZE
   int "EFI_TCG2_PROTOCOL EventLog size"
   depends on EFI_TCG2_PROTOCOL
- default 4096
+ default 16384


I found this text in EDK II:

Minimum length(in bytes) of the system preboot TCG event log area(LAML)
---

For PC Client Implementation spec up to and including 1.2 the minimum
log size is 64KB. (SecurityPkg/SecurityPkg.dec)


Thank you for your feedback.
I have not checked this.
TCG spec also says "The Log Area Minimum Length for the TCG event log
MUST be at least 64KB." in ACPI chapter.
I will update to set 64KB as default.



Is this the same as the BLOBLISTT_TPM2_TCG_LOG thing? If so, can we
put this in the bloblist? We want to avoid adding code in EFI which is
in U-Boot.


I think bloblist is used for data passing from SPL/TPL to u-boot.
Is your comment saying that the eventlog generated
in u-boot(done in efi_tcg2.c with this patch series) should be appended
into the buffer pointed by BLOBLISTT_TPM2_TCG_LOG blob?



Even in that case the eventlog can't be appended.  The TCG eventlog
hould be copied into EFI memory, since the kernel expects to find it
there.


Typically bloblist is relocated by U-Boot. There are lots of tables
that must be passed to linux, including ACPI and SMBIOS. With bloblist
they can all be in one place.



The eventlog must be allocated in EFI memory though.


There is really only one memory in U-Boot. I feel that all stuff that
EFI passes on to linux should be in a single bloblist.


We have should follow existing standards and not invent our own. LInux
is not the only OS booted via U-Boot.

Best regards

Heinrich








What we could do is copy the contents of that buffer to the eventlog.
Depending on what that buffer already has (e.g the starting header of
the eventlog), we might need to strip it from the efi_tcg.c code.


I'm not really sure, but the eventlog is not just EFI thing, right?
The code should be generic.


It's purely an EFI construct.  Specifically the entire spec, and even the  log
format for the eventlog are described in
https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf


For some reason I have seen this in ACPI, or something similar.
Perhaps I was getting confused.

We need to find ways to implement EFI things with generic code. I'm
not 100% sure about this particular thing, but since we already create
something similar with ACPI I think we should at least look at doing
it in one place.

Regards,
Simon

Re: [PATCH] Disable timer check in file loading

[Heinrich Schuchardt]

On 7/8/21 10:22 AM, Michael Chang wrote:

The u-boot efi console service registers a timer to poll the keyboard
input in every 50ns. In the efi block io service, this timer is


The event is triggered every 5000 ns not 50 ns. See
lib/efi_loader/efi_console.c:1309. The SetTimer() parameter is in
multiples of 100 ns. UEFI spec 2.9 has this sentence:
"TimerRelative: The event is to be signaled in TriggerTime 100ns units."


evaluated on each block read, and since the timer interval is much less
than the time needed to reading out a block (32kB) from the disk, the
keyboard polling is therefore in the wake of each block read.

Unfortunately USB keyboard spends too much time in polling. In my test
usb_kbd_poll_for_event costs 40ms in usb_kbd_testc() to test if a


I can't imagine that Linux is that slow. Why is U-Boot so slow? Please,
try to fix that code.


character is in the queue. In combination with the number of blocks to
be read from the disk, the extra amound of time delayed could be around
30 seconds to load linux and initrd.

For that matters, the timer check is disabled in file loading to speed
it up. The consequence would be losing the keystroke during the time
file is loading, but that is acceptable IMHO.


Disabling would mean that programs like iPXE cannot react to keyboard
input to interrupt a file transfer.

Best regards

Heinrich



Downstream bug reference:
https://bugzilla.suse.com/show_bug.cgi?id=1171222

Signed-off-by: Michael Chang 
---
  lib/efi_loader/efi_disk.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index 307d5d759b..d090110b06 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -15,6 +15,7 @@
  #include 
  #include 
  #include 
+#include 

  struct efi_system_partition efi_system_partition;

@@ -103,8 +104,7 @@ static efi_status_t efi_disk_rw_blocks(struct efi_block_io 
*this,
else
n = blk_dwrite(desc, lba, blocks, buffer);

-   /* We don't do interrupts, so check for timers cooperatively */
-   efi_timer_check();
+   WATCHDOG_RESET();

EFI_PRINT("n=%lx blocks=%x\n", n, blocks);

Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

[Simon Glass]

Hi François,

On Thu, 15 Jul 2021 at 08:25, François Ozog 
wrote:

>
>
> On Sat, 10 Jul 2021 at 01:07, Julius Werner  wrote:
>
>> > - "bloblist" is a general term for concept of linked list and it's not
>> exactly U-boot implementation. The proposed solution will cause some degree
>> of changes in all the participating projects. For backward compatibility
>> issue, we have already though about it and proposed to have build configs
>> which will be enabled by platform integrators.
>>
>> Okay, let's gather the requirements and then decide how the existing
>> system needs to be expanded to meet them. Please keep me in the loop
>> on those discussions.
>>
>> > > U-Boot has an established mechanism which is used in particular on
>> all chrome
>> > > books in both x86 and Arm environments.  I have the impression that
>> > > U-Boot is the typical BL33 so I would import the mechanism into TFA,
>> > > not the other way round.
>>
>> There has been no Chromebook (x86 or Arm) shipping with U-Boot since
>> 2013 (before TF-A existed). In fact, Chromebooks are all running
>> coreboot today and using the bl_aux_params mechanism (it's 3 SoC
>> vendors, more than 3 SoCs, but the parameter code is shared at the
>> vendor level), and one of my concerns here is trying to limit
>> disruption to those existing setups. I don't have enough data to say
>> what the "typical" boot flow among all TF-A devices in existence is,
>> but at least for the millions of Chromebooks out there it is coreboot
>> + TF-A, not U-Boot.
>>
> My bad! I candidly inferred from Chromebook reference in U-Boot and
> Simon's VBE proposal that U-Boot was used.
>

This is a bit off-topic, but it is somewhat in the reverse. U-Boot's
verified boot (2014 I think) uses the crypto from Chromium OS (which I
think came from Android at some point). VBE is an attempt to provide a
standard boot flow for U-Boot devices and is again heavily influenced by
Chromium OS. U-Boot does ship on most Chromebooks (oddly enough, not the
ARM ones!) but just as an alternate bootloader and is not used in the
verified-boot flow. I won't get into the details of how the Chroimum OS
replacement came about, as that is way off topic!

To me, bl_aux_params is a pretty limited. I am looking here:
https://github.com/ARM-software/arm-trusted-firmware/blob/master/include/export/lib/bl_aux_params/bl_aux_params_exp.h

Is that the right place?

There is not a huge amount of code in TF-A that uses it (mediatek and
rockchip?) so I don't see a problem with updating it, given the benefits of
interoperability.

In fact, having taken a bit of a look, my view is that U-Boot's bloblist is
a much better starting point for this effort:

- fuller implementation with more features
- has comments / more documentation
- easily supports everything in one block instead of a linked list (easier
to allocate)
- avoids 64-bit tags/size which seem quite unnecessary
- has unit tests

plus some minor points I won't mention. So I think it is worth the pain to
switch TF-A over.

Perhaps we can gather the requirements that are needed for this? So far I
am aware of:

- devicetree bob tag
- vendor-private tag area
- ability to link to another bloblist (do we really need this?)

Regards,
Simon

Re: [PATCH 0/5] stm32mp1: handle TF-A boot with FIP

[Simon Glass]

Hi Patrick,

On Thu, 15 Jul 2021 at 07:50, Patrick DELAUNAY
 wrote:
>
> Hi Simon
>
> On 7/11/21 2:01 AM, Simon Glass wrote:
> > Hi Patrick,
> >
> > On Thu, 8 Jul 2021 at 03:17, Patrick Delaunay
> >  wrote:
> >>
> >> In next TF-A version the stm32mp1 platform will support the Firmware
> >> Image Package (FIP) [1], a container filled with:
> >> - the U-Boot binary = u-boot-nodtb.bin
> >> - the U-Boot device tree = u-boot.dtb
> >> - the Secure OS (OP-TEE) or the secure monitor (SP_MIN)
> > That sounds like a job for FIT?
>
>
> Yes it is the same purpose but at TF-A BL2 level, so before U-Boot
> execution.
>
>
> In the STM32MP boot chain with TF-A, we have:
>
> 1/ Rom code load TF-A BL2 in embedded RAM
>
>=> it running in secure world, initializing the DDR
>
> 2/ TF-A BL2 load the next SW component from FIP containers in DDR
>
>  a) secure world, OP-TEE for example, including key infrastructure.
>
>  b) normal world = OS loader : U-Boot + device tree
>
>
> But SPL is not used
>
>
> TF-A BL2 can be see as SPL a remplacant and
>
> a FIP loaded by TF-A BL2 is equivalent to FIT loaded by SPL,
>
> it the container supported by trusted firmware
>
>
> But even in this use case FIT can be use to load kernel by U-Boot...
>
>
> It was a long debate on the preferred first stage bootloader
>
> for STMicroelectronics ARMv7 platform, between TF-A BL2 and SPL .
>
>
> Today the preferred solution is TF-A BL2 with FIP, for secure boot
>
> support and long term integration with  OP-TEE, even is we lost
>
> the falcon mode.

OK, thanks for the info...

Regards,
Simon

Re: [PATCH v3 03/16] x86: Allow coreboot serial driver to guess the UART

[Simon Glass]

Hi Bin,

On Thu, 15 Jul 2021 at 05:44, Bin Meng  wrote:
>
> Hi Simon,
>
> On Mon, Jun 28, 2021 at 7:51 AM Simon Glass  wrote:
> >
> > At present this driver relies on coreboot to provide information about
> > the console UART. However if coreboot is not compiled with the UART
> > enabled, the information is left out. This configuration is quite
> > common, e.g. with shipping x86-based Chrome OS Chromebooks.
> >
> > Add a way to determine the UART settings in this case, using a
> > hard-coded list of PCI IDs.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > (no changes since v1)
> >
> >  drivers/serial/serial_coreboot.c | 68 
> >  include/pci_ids.h|  1 +
> >  2 files changed, 61 insertions(+), 8 deletions(-)
> >
>
> Based on discussion of the last version, this patch should be dropped.
> I will see if I can drop it when applying.

OK thanks, I'll see what other ideas I can come up with.

Regards,
Simon

Re: [PATCH 1/5] efi_loader: increase eventlog buffer size

[Simon Glass]

Hi Heinrich,

On Thu, 15 Jul 2021 at 08:38, Heinrich Schuchardt  wrote:
>
> On 7/15/21 2:57 PM, Simon Glass wrote:
> > Hi Ilias,
> >
> > On Thu, 15 Jul 2021 at 00:20, Ilias Apalodimas
> >  wrote:
> >>
> >> On Wed, Jul 14, 2021 at 08:52:07AM -0600, Simon Glass wrote:
> >>> Hi Ilias,
> >>>
> >>> On Mon, 12 Jul 2021 at 03:28, Ilias Apalodimas
> >>>  wrote:
> 
>  On Mon, 12 Jul 2021 at 11:40, Masahisa Kojima
>   wrote:
> >
> > Hi Simon,
> >
> > On Sun, 11 Jul 2021 at 09:01, Simon Glass  wrote:
> >>
> >> Hi Masahisa,
> >>
> >> On Wed, 7 Jul 2021 at 20:21, Masahisa Kojima 
> >>  wrote:
> >>>
> >>> On Wed, 7 Jul 2021 at 22:47, Heinrich Schuchardt  
> >>> wrote:
> 
> 
> 
>  On 7/7/21 3:36 PM, Masahisa Kojima wrote:
> > This is a preperation to add eventlog support
> > described in TCG PC Client PFP spec.
> >
> > Signed-off-by: Masahisa Kojima 
> > ---
> >lib/efi_loader/Kconfig | 2 +-
> >1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index b2ab48a048..a87bf3cc98 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -327,7 +327,7 @@ config EFI_TCG2_PROTOCOL
> >config EFI_TCG2_PROTOCOL_EVENTLOG_SIZE
> >int "EFI_TCG2_PROTOCOL EventLog size"
> >depends on EFI_TCG2_PROTOCOL
> > - default 4096
> > + default 16384
> 
>  I found this text in EDK II:
> 
>  Minimum length(in bytes) of the system preboot TCG event log 
>  area(LAML)
>  ---
> 
>  For PC Client Implementation spec up to and including 1.2 the minimum
>  log size is 64KB. (SecurityPkg/SecurityPkg.dec)
> >>>
> >>> Thank you for your feedback.
> >>> I have not checked this.
> >>> TCG spec also says "The Log Area Minimum Length for the TCG event log
> >>> MUST be at least 64KB." in ACPI chapter.
> >>> I will update to set 64KB as default.
> >>>
> >>
> >> Is this the same as the BLOBLISTT_TPM2_TCG_LOG thing? If so, can we
> >> put this in the bloblist? We want to avoid adding code in EFI which is
> >> in U-Boot.
> >
> > I think bloblist is used for data passing from SPL/TPL to u-boot.
> > Is your comment saying that the eventlog generated
> > in u-boot(done in efi_tcg2.c with this patch series) should be appended
> > into the buffer pointed by BLOBLISTT_TPM2_TCG_LOG blob?
> >
> 
>  Even in that case the eventlog can't be appended.  The TCG eventlog
>  hould be copied into EFI memory, since the kernel expects to find it
>  there.
> >>>
> >>> Typically bloblist is relocated by U-Boot. There are lots of tables
> >>> that must be passed to linux, including ACPI and SMBIOS. With bloblist
> >>> they can all be in one place.
> >>
> >>
> >> The eventlog must be allocated in EFI memory though.
> >
> > There is really only one memory in U-Boot. I feel that all stuff that
> > EFI passes on to linux should be in a single bloblist.
>
> We have should follow existing standards and not invent our own. LInux
> is not the only OS booted via U-Boot.

Perhaps we can talk about it in the next call. My point is not about
avoiding standards!

What I am saying is that if we put things in a bloblist, and make that
available to Linux (or other OS) via EFI, things should work, but
non-EFI people are happy too. See the ACPI stuff for example - we put
all of those bits in a bloblist, which is really just a contiguous
area of memory. It is more convenient for U-Boot than allocating
memory willy nilly. Plus the 'bloblist' command lets you see what is
there.

Anyway I really don't understand all of this well enough to say what
we should do. I am just passing on hints. There is way too much
'separate' EFI code in U-Boot at present and we need to work to reduce
that and hopefully not add more.

[..]

Regards,
Simon

[PATCH v2 0/5] stm32mp1: handle TF-A boot with FIP

[Patrick Delaunay]

In next TF-A version the stm32mp1 platform will support the Firmware
Image Package (FIP) [1], a container filled with:
- the U-Boot binary = u-boot-nodtb.bin
- the U-Boot device tree = u-boot.dtb
- the Secure OS (OP-TEE) or the secure monitor (SP_MIN)

Upstream is in progress on TF-A side ([3] but reviews don't yet start).

Each part of the FIP is loaded by TF-A BL2 and U-Boot
is executed with its device tree address as parameter (nt_fw_dtb = r2
introduced by commit 4ac345220afa ("board: stm32mp1: use FDT address
provided by TF-A at boot time")

This FIP container simplifies the OP-TEE management (same number of partition
with or without OP-TEE, OP-TEE dynamically updates the U-Boot device tree
to add the required OP-TEE nodes) and allow support of generic TF-A
features as PKI [2].

This serie allows to generate U-Boot configured for the TF-A BL2 image
types:
- STM32IMAGE: stm32mp15_trusted_defconfig (current behavior)
- FIP: stm32mp15_defconfig (NEW)

The FIP will be the STMicroelectronics recommended image type for
STM32MP15x and the STM32IMAGE support should be marked deprecated in a
future TF-A release.

To prepare this migration, the serie move all the specific code or
device tree nodes for TF-A load of STM32IMAGE under compilation
flag CONFIG_STM32MP15x_STM32IMAGE.

This V2 serie of [4] is rebased on top for u-boot-stm32/master.

[1] 4.11. Firmware Image Package (FIP)
fiphttps://trustedfirmware-a.readthedocs.io/en/latest/design/firmware-design.html
stm32mp1: handle TF-A boot with FIP
[2] Authentication Framework & Chain of Trust
https://trustedfirmware-a.readthedocs.io/en/latest/design/auth-framework.html

[3] TF-A Serie proposal : FIP and FCONF for STM32MP1
https://github.com/Yann-lms/arm-trusted-firmware/commits/fip_fconf

[4] stm32mp1: handle TF-A boot with FIP
http://patchwork.ozlabs.org/project/uboot/list/?series=252477&state=*


Changes in v2:
- synchronize defconfig with latest change
- fix one typo: s/ enought / enough

Patrick Delaunay (5):
  arm: stm32mp: add config for STM32IMAGE support
  arm: stm32mp: handle the OP-TEE nodes in DT with FIP support
  arm: stm32mp: add defconfig for trusted boot with FIP
  doc: st: stm32mp1: Add FIP support for trusted boot
  stm32mp1: stm32prog: remove stm32prog_get_tee_partitions with FIP

 arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi  |   9 +-
 arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi  |   9 +-
 arch/arm/mach-stm32mp/Kconfig |   7 +
 .../cmd_stm32prog/cmd_stm32prog.c |   2 +
 .../mach-stm32mp/cmd_stm32prog/stm32prog.c|   4 +
 .../mach-stm32mp/cmd_stm32prog/stm32prog.h|   2 +
 arch/arm/mach-stm32mp/config.mk   |   2 +-
 arch/arm/mach-stm32mp/fdt.c   |  11 +-
 .../arm/mach-stm32mp/include/mach/stm32prog.h |   2 +
 board/st/common/Kconfig   |  21 ++-
 board/st/common/stm32mp_mtdparts.c|  31 +++-
 board/st/stm32mp1/MAINTAINERS |   1 +
 board/st/stm32mp1/stm32mp1.c  |  10 +-
 configs/stm32mp15_defconfig   | 158 +
 configs/stm32mp15_trusted_defconfig   |   1 +
 doc/board/st/stm32mp1.rst | 166 ++
 16 files changed, 346 insertions(+), 90 deletions(-)
 create mode 100644 configs/stm32mp15_defconfig

-- 
2.25.1

[PATCH v2 2/5] arm: stm32mp: handle the OP-TEE nodes in DT with FIP support

[Patrick Delaunay]

With FIP support in TF-A (when CONFIG_STM32MP15x_STM32IMAGE
is not activated), the DT nodes needed by OP-TEE are added by OP-TEE
firmware in U-Boot device tree, present in FIP.

These nodes are only required in trusted boot, when TF-A load the file
u-boot.stm32, including the U-Boot device tree with STM32IMAGE header,
in this case OP-TEE can't update the U-Boot device tree.

Moreover in trusted boot mode with FIP, as the OP-TEE nodes are present
in U-Boot device tree only when needed the function
stm32_fdt_disable_optee can be removed.

Signed-off-by: Patrick Delaunay 
Reviewed-by: Patrice Chotard 
---

(no changes since v1)

 arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi |  3 +++
 arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi |  3 +++
 arch/arm/mach-stm32mp/fdt.c  | 11 ++-
 3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi 
b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
index 6c62322f1c..36d166a0e1 100644
--- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
@@ -21,6 +21,8 @@
st,stm32prog-gpios = <&gpioa 14 GPIO_ACTIVE_LOW>;
};
 
+#ifdef CONFIG_STM32MP15x_STM32IMAGE
+   /* only needed for boot with TF-A, witout FIP support */
firmware {
optee {
compatible = "linaro,optee-tz";
@@ -37,6 +39,7 @@
u-boot,dm-spl;
};
};
+#endif
 
led {
red {
diff --git a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi 
b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
index 46a43371bd..e5a1cb7084 100644
--- a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
@@ -20,6 +20,8 @@
st,stm32prog-gpios = <&gpioa 14 GPIO_ACTIVE_LOW>;
};
 
+#ifdef CONFIG_STM32MP15x_STM32IMAGE
+   /* only needed for boot with TF-A, witout FIP support */
firmware {
optee {
compatible = "linaro,optee-tz";
@@ -33,6 +35,7 @@
no-map;
};
};
+#endif
 
led {
red {
diff --git a/arch/arm/mach-stm32mp/fdt.c b/arch/arm/mach-stm32mp/fdt.c
index ce2fe0206f..a19e954cf7 100644
--- a/arch/arm/mach-stm32mp/fdt.c
+++ b/arch/arm/mach-stm32mp/fdt.c
@@ -332,7 +332,16 @@ int ft_system_setup(void *blob, struct bd_info *bd)
   "st,package", pkg, false);
}
 
-   if (!CONFIG_IS_ENABLED(OPTEE) ||
+   /*
+* TEMP: remove OP-TEE nodes in kernel device tree
+*   copied from U-Boot device tree by optee_copy_fdt_nodes
+*   when OP-TEE is not detected (probe failed)
+* these OP-TEE nodes are present in -u-boot.dtsi
+* under CONFIG_STM32MP15x_STM32IMAGE only for compatibility
+* when FIP is not used by TF-A
+*/
+   if (CONFIG_IS_ENABLED(STM32MP15x_STM32IMAGE) &&
+   CONFIG_IS_ENABLED(OPTEE) &&
!tee_find_device(NULL, NULL, NULL, NULL))
stm32_fdt_disable_optee(blob);
 
-- 
2.25.1

[PATCH v2 1/5] arm: stm32mp: add config for STM32IMAGE support

[Patrick Delaunay]

By default for trusted boot with TF-A, U-Boot (u-boot-nodtb)
is located in FIP container with its device tree and with
the secure monitor (provided by TF-A or OP-TEE).
The FIP file is loaded by TF-A BL2 and each components is
extracted at the final location.

This patch add CONFIG_STM32MP15x_STM32IMAGE to request the
STM32 image generation for SOC STM32MP15x
when FIP container is not used (u-boot.stm32 is loaded by TF-A
as done previously to keep the backward compatibility).

Signed-off-by: Patrick Delaunay 
Reviewed-by: Patrice Chotard 
---

(no changes since v1)

 arch/arm/mach-stm32mp/Kconfig   |  7 +++
 arch/arm/mach-stm32mp/config.mk |  2 +-
 board/st/stm32mp1/stm32mp1.c| 10 +++---
 configs/stm32mp15_trusted_defconfig |  1 +
 4 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
index 0e59931679..b9e623bc3c 100644
--- a/arch/arm/mach-stm32mp/Kconfig
+++ b/arch/arm/mach-stm32mp/Kconfig
@@ -56,6 +56,13 @@ config STM32MP15x
dual core A7 for STM32MP157/3, monocore for STM32MP151
target all the STMicroelectronics board with SOC STM32MP1 family
 
+config STM32MP15x_STM32IMAGE
+   bool "Support STM32 image for generated U-Boot image"
+   depends on STM32MP15x && TFABOOT
+   help
+   Support of STM32 image generation for SOC STM32MP15x
+   for TF-A boot when FIP container is not used
+
 choice
prompt "STM32MP15x board select"
optional
diff --git a/arch/arm/mach-stm32mp/config.mk b/arch/arm/mach-stm32mp/config.mk
index c30bf482f7..f7f5b77c41 100644
--- a/arch/arm/mach-stm32mp/config.mk
+++ b/arch/arm/mach-stm32mp/config.mk
@@ -4,7 +4,7 @@
 #
 
 ifndef CONFIG_SPL
-INPUTS-y += u-boot.stm32
+INPUTS-$(CONFIG_STM32MP15x_STM32IMAGE) += u-boot.stm32
 else
 ifdef CONFIG_SPL_BUILD
 INPUTS-y += u-boot-spl.stm32
diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 2faf5c81b4..70bd4d1ed5 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -105,10 +105,14 @@ int checkboard(void)
const char *fdt_compat;
int fdt_compat_len;
 
-   if (IS_ENABLED(CONFIG_TFABOOT))
-   mode = "trusted";
-   else
+   if (IS_ENABLED(CONFIG_TFABOOT)) {
+   if (IS_ENABLED(CONFIG_STM32MP15x_STM32IMAGE))
+   mode = "trusted - stm32image";
+   else
+   mode = "trusted";
+   } else {
mode = "basic";
+   }
 
fdt_compat = fdt_getprop(gd->fdt_blob, 0, "compatible",
 &fdt_compat_len);
diff --git a/configs/stm32mp15_trusted_defconfig 
b/configs/stm32mp15_trusted_defconfig
index a58ea91d3e..6a8ccb1f3d 100644
--- a/configs/stm32mp15_trusted_defconfig
+++ b/configs/stm32mp15_trusted_defconfig
@@ -7,6 +7,7 @@ CONFIG_SYS_MEMTEST_END=0xc400
 CONFIG_ENV_OFFSET=0x28
 CONFIG_ENV_SECT_SIZE=0x4
 CONFIG_DEFAULT_DEVICE_TREE="stm32mp157c-ev1"
+CONFIG_STM32MP15x_STM32IMAGE=y
 CONFIG_TARGET_ST_STM32MP15x=y
 CONFIG_CMD_STM32KEY=y
 CONFIG_CMD_STM32PROG=y
-- 
2.25.1

[PATCH v2 5/5] stm32mp1: stm32prog: remove stm32prog_get_tee_partitions with FIP

[Patrick Delaunay]

The MTD tee partitions used to save the OP-TEE binary are needed when
TF-A doesn't use the FIP container to load binaries.

This patch puts under CONFIG_STM32MP15x_STM32IMAGE flag the associated
code in U-Boot binary and prepare the code cleanup when
CONFIG_STM32MP15x_STM32IMAGE support will be removed after TF-A migration
to FIP support.

Signed-off-by: Patrick Delaunay 
Reviewed-by: Patrice Chotard 
---

(no changes since v1)

 arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c | 2 ++
 arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c | 4 
 arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h | 2 ++
 arch/arm/mach-stm32mp/include/mach/stm32prog.h  | 2 ++
 4 files changed, 10 insertions(+)

diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c 
b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
index 064f51b2c7..1bccad4e6d 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
@@ -185,6 +185,7 @@ U_BOOT_CMD(stm32prog, 5, 0, do_stm32prog,
   "   = size of flashlayout (optional for image with STM32 
header)\n"
 );
 
+#ifdef CONFIG_STM32MP15x_STM32IMAGE
 bool stm32prog_get_tee_partitions(void)
 {
if (stm32prog_data)
@@ -192,6 +193,7 @@ bool stm32prog_get_tee_partitions(void)
 
return false;
 }
+#endif
 
 bool stm32prog_get_fsbl_nor(void)
 {
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c 
b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
index 96ebc6d978..0971ee79af 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
@@ -824,7 +824,9 @@ static int treat_partition_list(struct stm32prog_data *data)
INIT_LIST_HEAD(&data->dev[j].part_list);
}
 
+#ifdef CONFIG_STM32MP15x_STM32IMAGE
data->tee_detected = false;
+#endif
data->fsbl_nor_detected = false;
for (i = 0; i < data->part_nb; i++) {
part = &data->part_array[i];
@@ -878,10 +880,12 @@ static int treat_partition_list(struct stm32prog_data 
*data)
/* fallthrough */
case STM32PROG_NAND:
case STM32PROG_SPI_NAND:
+#ifdef CONFIG_STM32MP15x_STM32IMAGE
if (!data->tee_detected &&
!strncmp(part->name, "tee", 3))
data->tee_detected = true;
break;
+#endif
default:
break;
}
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h 
b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
index 9d58cf0e2d..240c5c44bc 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
@@ -122,7 +122,9 @@ struct stm32prog_data {
struct stm32prog_dev_t  dev[STM32PROG_MAX_DEV]; /* array of device */
int part_nb;/* nb of partition */
struct stm32prog_part_t *part_array;/* array of partition */
+#ifdef CONFIG_STM32MP15x_STM32IMAGE
booltee_detected;
+#endif
boolfsbl_nor_detected;
 
/* command internal information */
diff --git a/arch/arm/mach-stm32mp/include/mach/stm32prog.h 
b/arch/arm/mach-stm32mp/include/mach/stm32prog.h
index c080b9cc42..99be4e1d65 100644
--- a/arch/arm/mach-stm32mp/include/mach/stm32prog.h
+++ b/arch/arm/mach-stm32mp/include/mach/stm32prog.h
@@ -11,6 +11,8 @@ int stm32prog_read_medium_virt(struct dfu_entity *dfu, u64 
offset,
   void *buf, long *len);
 int stm32prog_get_medium_size_virt(struct dfu_entity *dfu, u64 *size);
 
+#ifdef CONFIG_STM32MP15x_STM32IMAGE
 bool stm32prog_get_tee_partitions(void);
+#endif
 
 bool stm32prog_get_fsbl_nor(void);
-- 
2.25.1

[PATCH v2 4/5] doc: st: stm32mp1: Add FIP support for trusted boot

[Patrick Delaunay]

TF-A for STM32MP15 now supports the FIP: it is a packaging format which
includes the secure monitor, u-boot-nodtb.bin and u-boot.dtb

This FIP file is loaded by FSBL = TF-A BL2.

This patch updates the board documentation to use this FIP file and no
more u-boot.stm32 (with STM32 image header) which is no more generated.

Signed-off-by: Patrick Delaunay 
Reviewed-by: Patrice Chotard 
---

Changes in v2:
- fix one typo: s/ enought / enough

 doc/board/st/stm32mp1.rst | 166 ++
 1 file changed, 97 insertions(+), 69 deletions(-)

diff --git a/doc/board/st/stm32mp1.rst b/doc/board/st/stm32mp1.rst
index f0c2b09b98..7440753788 100644
--- a/doc/board/st/stm32mp1.rst
+++ b/doc/board/st/stm32mp1.rst
@@ -60,7 +60,7 @@ Currently the following boards are supported:
 Boot Sequences
 --
 
-3 boot configurations are supported with:
+2 boot configurations are supported with:
 
 +--++-+--+
 | **ROM**  | **FSBL**   | **SSBL**| **OS**   |
@@ -70,10 +70,12 @@ Boot Sequences
 |  | embedded RAM   | DDR|
 +--++-+--+
 
-The **Trusted** boot chain
-``
+The **Trusted** boot chain with TF-A
+`
 
-defconfig_file : stm32mp15_trusted_defconfig
+defconfig_file :
+   + **stm32mp15_defconfig** (for TF-A with FIP support)
+   + **stm32mp15_trusted_defconfig** (for TF-A without FIP support)
 
 +-+-++---+
 |  ROM code   | FSBL| SSBL   | OS|
@@ -83,19 +85,16 @@ defconfig_file : stm32mp15_trusted_defconfig
 | TrustZone   |secure monitor|
 +-+-++---+
 
-TF-A performs a full initialization of Secure peripherals and installs a
-secure monitor, BL32:
+TF-A (BL2) initialize the DDR and loads the next stage binaries from a FIP 
file:
+   + BL32: a secure monitor BL32 = SPMin provided by TF-A or OP-TEE : performs 
a full initialization of Secure peripherals and provides service to normal world
+   + BL33: a non-trusted firmware = U-Boot, running in normal world and uses 
the secure monitor to access to secure resources.
+   + HW_CONFIG: The hardware configuration file = the U-Boot device tree
 
-  * SPMin provided by TF-A or
-  * OP-TEE from specific partitions (teeh, teed, teex).
+The **Basic** boot chain with SPL
+`
 
-U-Boot is running in normal world and uses the secure monitor to access
-to secure resources.
-
-The **Basic** boot chain
-
-
-defconfig_file : stm32mp15_basic_defconfig
+defconfig_file :
+   + **stm32mp15_basic_defconfig**
 
 +-+++---+
 |  ROM code   | FSBL   | SSBL   | OS|
@@ -163,12 +162,13 @@ Build Procedure
 
for example: use one output directory for each configuration::
 
+   # export KBUILD_OUTPUT=stm32mp15
# export KBUILD_OUTPUT=stm32mp15_trusted
# export KBUILD_OUTPUT=stm32mp15_basic
 
you can build outside of code directory::
 
-   # export KBUILD_OUTPUT=../build/stm32mp15_trusted
+   # export KBUILD_OUTPUT=../build/stm32mp15
 
 4. Configure U-Boot::
 
@@ -176,7 +176,7 @@ Build Procedure
 
with :
 
-   - For **trusted** boot mode : **stm32mp15_trusted_defconfig**
+   - For **trusted** boot mode : **stm32mp15_defconfig** or 
stm32mp15_trusted_defconfig
- For basic boot mode: stm32mp15_basic_defconfig
 
 5. Configure the device-tree and build the U-Boot image::
@@ -185,13 +185,13 @@ Build Procedure
 
Examples:
 
-  a) trusted boot on ev1::
+  a) trusted boot with FIP on ev1::
 
- # export KBUILD_OUTPUT=stm32mp15_trusted
- # make stm32mp15_trusted_defconfig
+ # export KBUILD_OUTPUT=stm32mp15
+ # make stm32mp15_defconfig
  # make DEVICE_TREE=stm32mp157c-ev1 all
 
-  b) trusted with OP-TEE boot on dk2::
+  b) trusted boot without FIP on dk2::
 
   # export KBUILD_OUTPUT=stm32mp15_trusted
   # make stm32mp15_trusted_defconfig
@@ -223,16 +223,32 @@ Build Procedure
 
 6. Output files
 
-   BootRom and TF-A expect binaries with STM32 image header
-   SPL expects file with U-Boot uImage header
+   The ROM code expects FSBL binaries with STM32 image header.
+   TF-A expects:
+   -   a FIP binary, including the OS monitor (SPmin or OP-TEE) and the U-Boot
+   binary + device tree
+   -  binaries with STM32 image header: U-Boot and OP-TEE
+   SPL expects file with U-Boot uImage header.
 
So in the output directory (selected by KBUILD_OUTPUT),
you can found the needed files:
 
   - For **Trusted** boot (with or without OP-TEE)
 
- - FSBL = **tf-a.stm32** (provided by TF-A compilation)
- - SSBL = **u-boot.stm32**
+ - with FIP:
+- FSBL = **tf-a

[PATCH v2 3/5] arm: stm32mp: add defconfig for trusted boot with FIP

[Patrick Delaunay]

Add TF-A FIP support for trusted boot on STM32MP15x,
when STM32MP15x_STM32IMAGE is not activated.

With FIP support the SSBL partition is named "fip" and its size is 4MB,
so the ENV partition name in device tree  (for SD card or eMMC)
or offset in defconfig (CONFIG_ENV_OFFSET / CONFIG_ENV_OFFSET_REDUND)
need to be modified.

With FIP the TEE MTD partitions are removed because the OP-TEE binray are
included in the FIP containers.

Signed-off-by: Patrick Delaunay 
Reviewed-by: Patrice Chotard 
---

Changes in v2:
- synchronize defconfig with latest change

 arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi |   6 +-
 arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi |   6 +-
 board/st/common/Kconfig  |  21 ++-
 board/st/common/stm32mp_mtdparts.c   |  31 +++--
 board/st/stm32mp1/MAINTAINERS|   1 +
 configs/stm32mp15_defconfig  | 158 +++
 6 files changed, 207 insertions(+), 16 deletions(-)
 create mode 100644 configs/stm32mp15_defconfig

diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi 
b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
index 36d166a0e1..f554d9359b 100644
--- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
@@ -15,13 +15,17 @@
config {
u-boot,boot-led = "heartbeat";
u-boot,error-led = "error";
-   u-boot,mmc-env-partition = "ssbl";
+   u-boot,mmc-env-partition = "fip";
st,adc_usb_pd = <&adc1 18>, <&adc1 19>;
st,fastboot-gpios = <&gpioa 13 GPIO_ACTIVE_LOW>;
st,stm32prog-gpios = <&gpioa 14 GPIO_ACTIVE_LOW>;
};
 
 #ifdef CONFIG_STM32MP15x_STM32IMAGE
+   config {
+   u-boot,mmc-env-partition = "ssbl";
+   };
+
/* only needed for boot with TF-A, witout FIP support */
firmware {
optee {
diff --git a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi 
b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
index e5a1cb7084..69eb285bf7 100644
--- a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
@@ -15,12 +15,16 @@
config {
u-boot,boot-led = "heartbeat";
u-boot,error-led = "error";
-   u-boot,mmc-env-partition = "ssbl";
+   u-boot,mmc-env-partition = "fip";
st,fastboot-gpios = <&gpioa 13 GPIO_ACTIVE_LOW>;
st,stm32prog-gpios = <&gpioa 14 GPIO_ACTIVE_LOW>;
};
 
 #ifdef CONFIG_STM32MP15x_STM32IMAGE
+   config {
+   u-boot,mmc-env-partition = "ssbl";
+   };
+
/* only needed for boot with TF-A, witout FIP support */
firmware {
optee {
diff --git a/board/st/common/Kconfig b/board/st/common/Kconfig
index ddcf33a122..2f57118bb2 100644
--- a/board/st/common/Kconfig
+++ b/board/st/common/Kconfig
@@ -8,18 +8,22 @@ config CMD_STBOARD
 
 config MTDPARTS_NAND0_BOOT
string "mtd boot partitions for nand0"
-   default "2m(fsbl),2m(ssbl1),2m(ssbl2)"
+   default "2m(fsbl),2m(ssbl1),2m(ssbl2)" if STM32MP15x_STM32IMAGE || \
+ !TFABOOT
+   default "2m(fsbl),4m(fip1),4m(fip2)"
depends on SYS_MTDPARTS_RUNTIME && ARCH_STM32MP
help
  This define the partitions of nand0 used to build mtparts dynamically
  for boot from nand0.
  Each partition need to be aligned with the device erase block size,
  512KB is the max size for the NAND supported by stm32mp1 platform.
+ The fsbl partition support multiple copy of the same binary, one by
+ erase block.
 
 config MTDPARTS_NAND0_TEE
string "mtd tee partitions for nand0"
default "512k(teeh),512k(teed),512k(teex)"
-   depends on SYS_MTDPARTS_RUNTIME && ARCH_STM32MP
+   depends on SYS_MTDPARTS_RUNTIME && ARCH_STM32MP && STM32MP15x_STM32IMAGE
help
  This define the tee partitions added in mtparts dynamically
  when tee is supported with boot from nand0.
@@ -28,7 +32,9 @@ config MTDPARTS_NAND0_TEE
 
 config MTDPARTS_NOR0_BOOT
string "mtd boot partitions for nor0"
-   default "256k(fsbl1),256k(fsbl2),2m(ssbl),512k(u-boot-env)"
+   default "256k(fsbl1),256k(fsbl2),2m(ssbl),512k(u-boot-env)" if 
STM32MP15x_STM32IMAGE || \
+  !TFABOOT
+   default "256k(fsbl1),256k(fsbl2),4m(fip),512k(u-boot-env)"
depends on SYS_MTDPARTS_RUNTIME && ARCH_STM32MP
help
  This define the partitions of nand0 used to build mtparts dynamically
@@ -40,24 +46,27 @@ config MTDPARTS_NOR0_BOOT
 config MTDPARTS_NOR0_TEE
string "mtd tee partitions for nor0"
default "256k(teeh),512k(teed),256k(teex)"
-   depends on SYS_MTDPARTS_RUNTIME && ARCH_STM32MP
+   depends on SYS_MTDPARTS_RUNTIME && ARCH_STM32MP && STM32MP15x_STM32IMAGE
help
  This define the tee partitions added in mtparts d

Re: [PATCH 1/5] efi_loader: increase eventlog buffer size

[Heinrich Schuchardt]

On 15.07.21 17:18, Simon Glass wrote:

Hi Heinrich,

On Thu, 15 Jul 2021 at 08:38, Heinrich Schuchardt  wrote:


On 7/15/21 2:57 PM, Simon Glass wrote:

Hi Ilias,

On Thu, 15 Jul 2021 at 00:20, Ilias Apalodimas
 wrote:


On Wed, Jul 14, 2021 at 08:52:07AM -0600, Simon Glass wrote:

Hi Ilias,

On Mon, 12 Jul 2021 at 03:28, Ilias Apalodimas
 wrote:


On Mon, 12 Jul 2021 at 11:40, Masahisa Kojima
 wrote:


Hi Simon,

On Sun, 11 Jul 2021 at 09:01, Simon Glass  wrote:


Hi Masahisa,

On Wed, 7 Jul 2021 at 20:21, Masahisa Kojima  wrote:


On Wed, 7 Jul 2021 at 22:47, Heinrich Schuchardt  wrote:




On 7/7/21 3:36 PM, Masahisa Kojima wrote:

This is a preperation to add eventlog support
described in TCG PC Client PFP spec.

Signed-off-by: Masahisa Kojima 
---
lib/efi_loader/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index b2ab48a048..a87bf3cc98 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -327,7 +327,7 @@ config EFI_TCG2_PROTOCOL
config EFI_TCG2_PROTOCOL_EVENTLOG_SIZE
int "EFI_TCG2_PROTOCOL EventLog size"
depends on EFI_TCG2_PROTOCOL
- default 4096
+ default 16384


I found this text in EDK II:

Minimum length(in bytes) of the system preboot TCG event log area(LAML)
---

For PC Client Implementation spec up to and including 1.2 the minimum
log size is 64KB. (SecurityPkg/SecurityPkg.dec)


Thank you for your feedback.
I have not checked this.
TCG spec also says "The Log Area Minimum Length for the TCG event log
MUST be at least 64KB." in ACPI chapter.
I will update to set 64KB as default.



Is this the same as the BLOBLISTT_TPM2_TCG_LOG thing? If so, can we
put this in the bloblist? We want to avoid adding code in EFI which is
in U-Boot.


I think bloblist is used for data passing from SPL/TPL to u-boot.
Is your comment saying that the eventlog generated
in u-boot(done in efi_tcg2.c with this patch series) should be appended
into the buffer pointed by BLOBLISTT_TPM2_TCG_LOG blob?



Even in that case the eventlog can't be appended.  The TCG eventlog
hould be copied into EFI memory, since the kernel expects to find it
there.


Typically bloblist is relocated by U-Boot. There are lots of tables
that must be passed to linux, including ACPI and SMBIOS. With bloblist
they can all be in one place.



The eventlog must be allocated in EFI memory though.


There is really only one memory in U-Boot. I feel that all stuff that
EFI passes on to linux should be in a single bloblist.


We have should follow existing standards and not invent our own. LInux
is not the only OS booted via U-Boot.


Perhaps we can talk about it in the next call. My point is not about
avoiding standards!

What I am saying is that if we put things in a bloblist, and make that
available to Linux (or other OS) via EFI, things should work, but


Which operating would be aware of your bloblist? Windows, BSD, Haiku?

We want U-Boot to be interchangable with other UEFI firmware like EDK
II. This will only work if we program against the same specs and don't
invent new interfaces.

Best regards

Heinrich


non-EFI people are happy too. See the ACPI stuff for example - we put
all of those bits in a bloblist, which is really just a contiguous
area of memory. It is more convenient for U-Boot than allocating
memory willy nilly. Plus the 'bloblist' command lets you see what is
there.

Anyway I really don't understand all of this well enough to say what
we should do. I am just passing on hints. There is way too much
'separate' EFI code in U-Boot at present and we need to work to reduce
that and hopefully not add more.

[..]

Regards,
Simon

[PATCHv2 1/2] i2c: add dm_i2c_reg_clrset

[Sebastian Reichel]

Add function to apply a bitmask to an i2c register, so
that specific bits can be cleared and/or set.

Suggested-by: Simon Glass 
Signed-off-by: Sebastian Reichel 
---
 drivers/i2c/i2c-uclass.c | 15 +++
 include/i2c.h| 14 ++
 test/dm/i2c.c| 29 +
 3 files changed, 58 insertions(+)

diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
index be56785217c3..8adcdaf86411 100644
--- a/drivers/i2c/i2c-uclass.c
+++ b/drivers/i2c/i2c-uclass.c
@@ -245,6 +245,21 @@ int dm_i2c_reg_write(struct udevice *dev, uint offset, 
uint value)
return dm_i2c_write(dev, offset, &val, 1);
 }
 
+int dm_i2c_reg_clrset(struct udevice *dev, uint offset, u32 clr, u32 set)
+{
+   uint8_t val;
+   int ret;
+
+   ret = dm_i2c_read(dev, offset, &val, 1);
+   if (ret < 0)
+   return ret;
+
+   val &= ~clr;
+   val |= set;
+
+   return dm_i2c_write(dev, offset, &val, 1);
+}
+
 /**
  * i2c_probe_chip() - probe for a chip on a bus
  *
diff --git a/include/i2c.h b/include/i2c.h
index c0fe94c1f333..4faa15ae 100644
--- a/include/i2c.h
+++ b/include/i2c.h
@@ -242,6 +242,20 @@ int dm_i2c_reg_read(struct udevice *dev, uint offset);
  */
 int dm_i2c_reg_write(struct udevice *dev, uint offset, unsigned int val);
 
+/**
+ * dm_i2c_reg_clrset() - Apply bitmask to an I2C register
+ *
+ * Read value, apply bitmask and write modified value back to the
+ * given address in an I2C chip
+ *
+ * @dev:   Device to use for transfer
+ * @offset:Address for the R/W operation
+ * @clr:   Bitmask of bits that should be cleared
+ * @set:   Bitmask of bits that should be set
+ * @return 0 on success, -ve on error
+ */
+int dm_i2c_reg_clrset(struct udevice *dev, uint offset, u32 clr, u32 set);
+
 /**
  * dm_i2c_xfer() - Transfer messages over I2C
  *
diff --git a/test/dm/i2c.c b/test/dm/i2c.c
index d74f5f9fbc7c..74b209719560 100644
--- a/test/dm/i2c.c
+++ b/test/dm/i2c.c
@@ -304,3 +304,32 @@ static int dm_test_i2c_addr_offset(struct unit_test_state 
*uts)
 }
 
 DM_TEST(dm_test_i2c_addr_offset, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
+
+static int dm_test_i2c_reg_clrset(struct unit_test_state *uts)
+{
+   struct udevice *eeprom;
+   struct udevice *dev;
+   u8 buf[5];
+
+   ut_assertok(i2c_get_chip_for_busnum(busnum, chip, 1, &dev));
+
+   /* Do a transfer so we can find the emulator */
+   ut_assertok(dm_i2c_read(dev, 0, buf, 5));
+   ut_assertok(uclass_first_device(UCLASS_I2C_EMUL, &eeprom));
+
+   /* Dummy data for the test */
+   ut_assertok(dm_i2c_write(dev, 0, "\xff\x00\xff\x00\x10", 5));
+
+   /* Do some clrset tests */
+   ut_assertok(dm_i2c_reg_clrset(dev, 0, 0xff, 0x10));
+   ut_assertok(dm_i2c_reg_clrset(dev, 1, 0x00, 0x11));
+   ut_assertok(dm_i2c_reg_clrset(dev, 2, 0xed, 0x00));
+   ut_assertok(dm_i2c_reg_clrset(dev, 3, 0xff, 0x13));
+   ut_assertok(dm_i2c_reg_clrset(dev, 4, 0x00, 0x14));
+
+   ut_assertok(dm_i2c_read(dev, 0, buf, 5));
+   ut_asserteq_mem("\x10\x11\x12\x13\x14", buf, sizeof(buf));
+
+   return 0;
+}
+DM_TEST(dm_test_i2c_reg_clrset, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
-- 
2.30.2

[PATCHv2 2/2] gpio: mcp230xx: Introduce new driver

[Sebastian Reichel]

Introduce driver for I2C based MCP230xx GPIO chips, which are
quite common and already well supported by the Linux kernel.

Reviewed-by: Simon Glass 
Signed-off-by: Sebastian Reichel 
---
 drivers/gpio/Kconfig |  10 ++
 drivers/gpio/Makefile|   1 +
 drivers/gpio/mcp230xx_gpio.c | 235 +++
 3 files changed, 246 insertions(+)
 create mode 100644 drivers/gpio/mcp230xx_gpio.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index de4dc51d4b48..f93e736639bb 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -179,6 +179,16 @@ config LPC32XX_GPIO
help
  Support for the LPC32XX GPIO driver.
 
+config MCP230XX_GPIO
+   bool "MCP230XX GPIO driver"
+   depends on DM
+   help
+ Support for Microchip's MCP230XX I2C connected GPIO devices.
+ The following chips are supported:
+  - MCP23008
+  - MCP23017
+  - MCP23018
+
 config MSCC_SGPIO
bool "Microsemi Serial GPIO driver"
depends on DM_GPIO && SOC_VCOREIII
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 8541ba0b0aec..00ffcc753534 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_KIRKWOOD_GPIO)   += kw_gpio.o
 obj-$(CONFIG_KONA_GPIO)+= kona_gpio.o
 obj-$(CONFIG_MARVELL_GPIO) += mvgpio.o
 obj-$(CONFIG_MARVELL_MFP)  += mvmfp.o
+obj-$(CONFIG_MCP230XX_GPIO)+= mcp230xx_gpio.o
 obj-$(CONFIG_MXC_GPIO) += mxc_gpio.o
 obj-$(CONFIG_MXS_GPIO) += mxs_gpio.o
 obj-$(CONFIG_PCA953X)  += pca953x.o
diff --git a/drivers/gpio/mcp230xx_gpio.c b/drivers/gpio/mcp230xx_gpio.c
new file mode 100644
index ..9f02fd42b35f
--- /dev/null
+++ b/drivers/gpio/mcp230xx_gpio.c
@@ -0,0 +1,235 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2021, Collabora Ltd.
+ * Copyright (C) 2021, General Electric Company
+ * Author(s): Sebastian Reichel 
+ */
+
+#define LOG_CATEGORY UCLASS_GPIO
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+enum mcp230xx_type {
+   UNKNOWN = 0,
+   MCP23008,
+   MCP23017,
+   MCP23018,
+};
+
+#define MCP230XX_IODIR 0x00
+#define MCP230XX_GPPU 0x06
+#define MCP230XX_GPIO 0x09
+#define MCP230XX_OLAT 0x0a
+
+#define BANKSIZE 8
+
+static int mcp230xx_read(struct udevice *dev, uint reg, uint offset)
+{
+   struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+   int bank = offset / BANKSIZE;
+   int mask = 1 << (offset % BANKSIZE);
+   int shift = (uc_priv->gpio_count / BANKSIZE) - 1;
+   int ret;
+
+   ret = dm_i2c_reg_read(dev, (reg << shift) | bank);
+   if (ret < 0)
+   return ret;
+
+   return !!(ret & mask);
+}
+
+static int mcp230xx_write(struct udevice *dev, uint reg, uint offset, bool val)
+{
+   struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+   int bank = offset / BANKSIZE;
+   int mask = 1 << (offset % BANKSIZE);
+   int shift = (uc_priv->gpio_count / BANKSIZE) - 1;
+
+   return dm_i2c_reg_clrset(dev, (reg << shift) | bank, mask, val ? mask : 
0);
+}
+
+static int mcp230xx_get_value(struct udevice *dev, uint offset)
+{
+   int ret;
+
+   ret = mcp230xx_read(dev, MCP230XX_GPIO, offset);
+   if (ret < 0) {
+   dev_err(dev, "%s error: %d\n", __func__, ret);
+   return ret;
+   }
+
+   return ret;
+}
+
+static int mcp230xx_set_value(struct udevice *dev, uint offset, int val)
+{
+   int ret;
+
+   ret = mcp230xx_write(dev, MCP230XX_GPIO, offset, val);
+   if (ret < 0) {
+   dev_err(dev, "%s error: %d\n", __func__, ret);
+   return ret;
+   }
+
+   return ret;
+}
+
+static int mcp230xx_get_flags(struct udevice *dev, unsigned int offset,
+ ulong *flags)
+{
+   int direction, pullup;
+
+   pullup = mcp230xx_read(dev, MCP230XX_GPPU, offset);
+   if (pullup < 0) {
+   dev_err(dev, "%s error: %d\n", __func__, pullup);
+   return pullup;
+   }
+
+   direction = mcp230xx_read(dev, MCP230XX_IODIR, offset);
+   if (direction < 0) {
+   dev_err(dev, "%s error: %d\n", __func__, direction);
+   return direction;
+   }
+
+   *flags = direction ? GPIOD_IS_IN : GPIOD_IS_OUT;
+
+   if (pullup)
+   *flags |= GPIOD_PULL_UP;
+
+   return 0;
+}
+
+static int mcp230xx_set_flags(struct udevice *dev, uint offset, ulong flags)
+{
+   bool input = !(flags & (GPIOD_IS_OUT | GPIOD_IS_OUT_ACTIVE));
+   bool pullup = flags & GPIOD_PULL_UP;
+   ulong supported_mask;
+   int ret;
+
+   /* Note: active-low is ignored (handled by core) */
+   supported_mask = GPIOD_ACTIVE_LOW | GPIOD_MASK_DIR | GPIOD_PULL_UP;
+   if (flags & ~supported_mask) {
+   dev_err(dev, "%s unsupported flag(s): %lx\n", __func__, flags);
+   return -EINVAL;
+   }
+
+   ret

[PATCHv2 0/2] Introduce mcp230xx support

[Sebastian Reichel]

Hi,

Add driver for mcp230xx devices, which are quite common.

Changes since PATCHv1:
 * add new patch adding dm_i2c_reg_clrset() as suggested
   by Simon Glass
 * Use | instead of + to build device register
   (resulting number is the same)
 * Properly handle GPIOD_IS_OUT_ACTIVE flag
 * Use bool for local variables in mcp230xx_set_flags()
 * Add Reviewed-by from Simon Glass

-- Sebastian

Sebastian Reichel (2):
  i2c: add dm_i2c_reg_clrset
  gpio: mcp230xx: Introduce new driver

 drivers/gpio/Kconfig |  10 ++
 drivers/gpio/Makefile|   1 +
 drivers/gpio/mcp230xx_gpio.c | 235 +++
 drivers/i2c/i2c-uclass.c |  15 +++
 include/i2c.h|  14 +++
 test/dm/i2c.c|  29 +
 6 files changed, 304 insertions(+)
 create mode 100644 drivers/gpio/mcp230xx_gpio.c

-- 
2.30.2

Re: [PATCH 1/5] efi_loader: increase eventlog buffer size

[Simon Glass]

Hi Heinrich,

On Thu, 15 Jul 2021 at 09:35, Heinrich Schuchardt  wrote:
>
>
>
> On 15.07.21 17:18, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Thu, 15 Jul 2021 at 08:38, Heinrich Schuchardt  
> > wrote:
> >>
> >> On 7/15/21 2:57 PM, Simon Glass wrote:
> >>> Hi Ilias,
> >>>
> >>> On Thu, 15 Jul 2021 at 00:20, Ilias Apalodimas
> >>>  wrote:
> 
>  On Wed, Jul 14, 2021 at 08:52:07AM -0600, Simon Glass wrote:
> > Hi Ilias,
> >
> > On Mon, 12 Jul 2021 at 03:28, Ilias Apalodimas
> >  wrote:
> >>
> >> On Mon, 12 Jul 2021 at 11:40, Masahisa Kojima
> >>  wrote:
> >>>
> >>> Hi Simon,
> >>>
> >>> On Sun, 11 Jul 2021 at 09:01, Simon Glass  wrote:
> 
>  Hi Masahisa,
> 
>  On Wed, 7 Jul 2021 at 20:21, Masahisa Kojima 
>   wrote:
> >
> > On Wed, 7 Jul 2021 at 22:47, Heinrich Schuchardt 
> >  wrote:
> >>
> >>
> >>
> >> On 7/7/21 3:36 PM, Masahisa Kojima wrote:
> >>> This is a preperation to add eventlog support
> >>> described in TCG PC Client PFP spec.
> >>>
> >>> Signed-off-by: Masahisa Kojima 
> >>> ---
> >>> lib/efi_loader/Kconfig | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> >>> index b2ab48a048..a87bf3cc98 100644
> >>> --- a/lib/efi_loader/Kconfig
> >>> +++ b/lib/efi_loader/Kconfig
> >>> @@ -327,7 +327,7 @@ config EFI_TCG2_PROTOCOL
> >>> config EFI_TCG2_PROTOCOL_EVENTLOG_SIZE
> >>> int "EFI_TCG2_PROTOCOL EventLog size"
> >>> depends on EFI_TCG2_PROTOCOL
> >>> - default 4096
> >>> + default 16384
> >>
> >> I found this text in EDK II:
> >>
> >> Minimum length(in bytes) of the system preboot TCG event log 
> >> area(LAML)
> >> ---
> >>
> >> For PC Client Implementation spec up to and including 1.2 the 
> >> minimum
> >> log size is 64KB. (SecurityPkg/SecurityPkg.dec)
> >
> > Thank you for your feedback.
> > I have not checked this.
> > TCG spec also says "The Log Area Minimum Length for the TCG event 
> > log
> > MUST be at least 64KB." in ACPI chapter.
> > I will update to set 64KB as default.
> >
> 
>  Is this the same as the BLOBLISTT_TPM2_TCG_LOG thing? If so, can we
>  put this in the bloblist? We want to avoid adding code in EFI which 
>  is
>  in U-Boot.
> >>>
> >>> I think bloblist is used for data passing from SPL/TPL to u-boot.
> >>> Is your comment saying that the eventlog generated
> >>> in u-boot(done in efi_tcg2.c with this patch series) should be 
> >>> appended
> >>> into the buffer pointed by BLOBLISTT_TPM2_TCG_LOG blob?
> >>>
> >>
> >> Even in that case the eventlog can't be appended.  The TCG eventlog
> >> hould be copied into EFI memory, since the kernel expects to find it
> >> there.
> >
> > Typically bloblist is relocated by U-Boot. There are lots of tables
> > that must be passed to linux, including ACPI and SMBIOS. With bloblist
> > they can all be in one place.
> 
> 
>  The eventlog must be allocated in EFI memory though.
> >>>
> >>> There is really only one memory in U-Boot. I feel that all stuff that
> >>> EFI passes on to linux should be in a single bloblist.
> >>
> >> We have should follow existing standards and not invent our own. LInux
> >> is not the only OS booted via U-Boot.
> >
> > Perhaps we can talk about it in the next call. My point is not about
> > avoiding standards!
> >
> > What I am saying is that if we put things in a bloblist, and make that
> > available to Linux (or other OS) via EFI, things should work, but
>
> Which operating would be aware of your bloblist? Windows, BSD, Haiku?

None, it is not necessary. The bloblist is a U-Boot construct, a
container for blobs. We can pass a pointer to the blob through the EFI
tables, as we do with ACPI.

>
> We want U-Boot to be interchangable with other UEFI firmware like EDK
> II. This will only work if we program against the same specs and don't
> invent new interfaces.

This is not a new interface. Let's chat about it in a contributor call.

Regards,
Simon

>
> Best regards
>
> Heinrich
>
> > non-EFI people are happy too. See the ACPI stuff for example - we put
> > all of those bits in a bloblist, which is really just a contiguous
> > area of memory. It is more convenient for U-Boot than allocating
> > memory willy nilly. Plus the 'bloblist' command lets you see what is
> > there.
> >
> > Anyway I really don't understand all of this well enough to say what
> > we should do. I am just passing on hints. 

Re: [PATCH v3 2/5] arm/dts: k3-j7200-r5-common: Add pmic lp876441 node

[Grygorii Strashko]

On 14/07/2021 23:52, Gowtham Tammana wrote:

Add pmic lp876411 node needed for CPU AVS support.

Signed-off-by: Gowtham Tammana 
---
  .../arm/dts/k3-j7200-r5-common-proc-board.dts | 26 +++
  1 file changed, 26 insertions(+)

diff --git a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts 
b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
index 8dc1809979..6ef92145ef 100644
--- a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
+++ b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
@@ -239,6 +239,32 @@
ti,driver-strength-ohm = <50>;
  };
  
+&wkup_i2c0 {

+   u-boot,dm-spl;
+   lp876441: lp876441@4c {
+   compatible = "ti,lp876441";
+   reg = <0x4c>;
+   u-boot,dm-spl;
+   pinctrl-names = "default";
+   pinctrl-0 = <&wkup_i2c0_pins_default>;
+   clock-frequency = <40>;


pls, send follow up fix to place pimux and freq props correctly in i2c node


+
+   regulators: regulators {
+   u-boot,dm-spl;
+   buck1_reg: buck1 {
+   /*VDD_CPU_AVS_REG*/
+   regulator-name = "buck1";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <125>;
+   regulator-always-on;
+   regulator-boot-on;
+   u-boot,dm-spl;
+   };
+   };
+   };
+
+};
+
  &main_i2c0 {
pinctrl-names = "default";
pinctrl-0 = <&main_i2c0_pins_default>;



--
Best regards,
grygorii

[PATCH 1/3] efi_capsule: Move signature from DTB to .rodata

[Ilias Apalodimas]

The capsule signature is now part of our DTB.  This is problematic when a
user is allowed to change/fixup that DTB from U-Boots command line since he
can overwrite the signature as well.
So Instead of adding the key on the DTB, embed it in the u-boot binary it
self as part of it's .rodata.  This assumes that the U-Boot binary we load
is authenticated by a previous boot stage loader.

Signed-off-by: Ilias Apalodimas 
---
 board/emulation/common/Makefile   |  1 -
 board/emulation/common/qemu_capsule.c | 43 ---
 include/asm-generic/sections.h|  2 ++
 lib/efi_loader/Kconfig|  6 
 lib/efi_loader/Makefile   |  8 +
 lib/efi_loader/efi_capsule.c  | 18 +--
 lib/efi_loader/efi_capsule_key.S  |  8 +
 7 files changed, 39 insertions(+), 47 deletions(-)
 delete mode 100644 board/emulation/common/qemu_capsule.c
 create mode 100644 lib/efi_loader/efi_capsule_key.S

diff --git a/board/emulation/common/Makefile b/board/emulation/common/Makefile
index 7ed447a69dce..c5b452e7e341 100644
--- a/board/emulation/common/Makefile
+++ b/board/emulation/common/Makefile
@@ -2,4 +2,3 @@
 
 obj-$(CONFIG_SYS_MTDPARTS_RUNTIME) += qemu_mtdparts.o
 obj-$(CONFIG_SET_DFU_ALT_INFO) += qemu_dfu.o
-obj-$(CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT) += qemu_capsule.o
diff --git a/board/emulation/common/qemu_capsule.c 
b/board/emulation/common/qemu_capsule.c
deleted file mode 100644
index 6b8a87022a4c..
--- a/board/emulation/common/qemu_capsule.c
+++ /dev/null
@@ -1,43 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (c) 2020 Linaro Limited
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-DECLARE_GLOBAL_DATA_PTR;
-
-int efi_get_public_key_data(void **pkey, efi_uintn_t *pkey_len)
-{
-   const void *fdt_blob = gd->fdt_blob;
-   const void *blob;
-   const char *cnode_name = "capsule-key";
-   const char *snode_name = "signature";
-   int sig_node;
-   int len;
-
-   sig_node = fdt_subnode_offset(fdt_blob, 0, snode_name);
-   if (sig_node < 0) {
-   EFI_PRINT("Unable to get signature node offset\n");
-   return -FDT_ERR_NOTFOUND;
-   }
-
-   blob = fdt_getprop(fdt_blob, sig_node, cnode_name, &len);
-
-   if (!blob || len < 0) {
-   EFI_PRINT("Unable to get capsule-key value\n");
-   *pkey = NULL;
-   *pkey_len = 0;
-   return -FDT_ERR_NOTFOUND;
-   }
-
-   *pkey = (void *)blob;
-   *pkey_len = len;
-
-   return 0;
-}
diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
index 267f1db73f23..ec992b0c2e3f 100644
--- a/include/asm-generic/sections.h
+++ b/include/asm-generic/sections.h
@@ -27,6 +27,8 @@ extern char __efi_helloworld_begin[];
 extern char __efi_helloworld_end[];
 extern char __efi_var_file_begin[];
 extern char __efi_var_file_end[];
+extern char __efi_capsule_sig_begin[];
+extern char __efi_capsule_sig_end[];
 
 /* Private data used by of-platdata devices/uclasses */
 extern char __priv_data_start[], __priv_data_end[];
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 156b39152112..42f1292fa04b 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -213,6 +213,12 @@ config EFI_CAPSULE_AUTHENTICATE
  Select this option if you want to enable capsule
  authentication
 
+config EFI_CAPSULE_KEY_PATH
+   string "Path to .esl file for capsule authentication"
+   depends on EFI_CAPSULE_AUTHENTICATE
+   help
+ Provide the .esl file used for capsule authentication
+
 config EFI_DEVICE_PATH_TO_TEXT
bool "Device path to text protocol"
default y
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index fd344cea29b0..9b369430e258 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -20,11 +20,19 @@ always += helloworld.efi
 targets += helloworld.o
 endif
 
+ifeq ($(CONFIG_EFI_CAPSULE_AUTHENTICATE),y)
+EFI_CAPSULE_KEY_PATH := $(subst $\",,$(CONFIG_EFI_CAPSULE_KEY_PATH))
+ifeq ("$(wildcard $(EFI_CAPSULE_KEY_PATH))","")
+$(error .esl cerificate not found. Configure your CONFIG_EFI_CAPSULE_KEY_PATH)
+endif
+endif
+
 obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
 obj-$(CONFIG_CMD_BOOTEFI_BOOTMGR) += efi_bootmgr.o
 obj-y += efi_boottime.o
 obj-y += efi_helper.o
 obj-$(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) += efi_capsule.o
+obj-$(CONFIG_EFI_CAPSULE_AUTHENTICATE) += efi_capsule_key.o
 obj-$(CONFIG_EFI_CAPSULE_FIRMWARE) += efi_firmware.o
 obj-y += efi_console.o
 obj-y += efi_device_path.o
diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
index b878e71438b8..50e93cad4ee5 100644
--- a/lib/efi_loader/efi_capsule.c
+++ b/lib/efi_loader/efi_capsule.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -222,12 +223,23 @@ skip:
 const efi_guid_t efi_guid_capsule_root_cert_guid =
EFI_FIRMWARE_MANAGEME

[PATCH 2/3] mkeficapsule: Remove dtb related options

[Ilias Apalodimas]

commit 322c813f4bec ("mkeficapsule: Add support for embedding public key in a 
dtb")
added a bunch of options enabling the addition of the capsule public key
in a dtb.  Since now we embeded the key in U-Boot's .rodata we don't this
this functionality anymore

Signed-off-by: Ilias Apalodimas 
---
 tools/mkeficapsule.c | 226 ++-
 1 file changed, 7 insertions(+), 219 deletions(-)

diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
index de0a62898886..214dc38e46e3 100644
--- a/tools/mkeficapsule.c
+++ b/tools/mkeficapsule.c
@@ -4,14 +4,12 @@
  * Author: AKASHI Takahiro
  */
 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -29,9 +27,6 @@ typedef __s32 s32;
 
 #define aligned_u64 __aligned_u64
 
-#define SIGNATURE_NODENAME "signature"
-#define OVERLAY_NODENAME   "__overlay__"
-
 #ifndef __packed
 #define __packed __attribute__((packed))
 #endif
@@ -52,9 +47,6 @@ static struct option options[] = {
{"raw", required_argument, NULL, 'r'},
{"index", required_argument, NULL, 'i'},
{"instance", required_argument, NULL, 'I'},
-   {"dtb", required_argument, NULL, 'D'},
-   {"public key", required_argument, NULL, 'K'},
-   {"overlay", no_argument, NULL, 'O'},
{"help", no_argument, NULL, 'h'},
{NULL, 0, NULL, 0},
 };
@@ -68,187 +60,10 @@ static void print_usage(void)
   "\t-r, --rawnew raw image file\n"
   "\t-i, --index  update image index\n"
   "\t-I, --instanceupdate hardware instance\n"
-  "\t-K, --public-key  public key esl file\n"
-  "\t-D, --dtb dtb file\n"
-  "\t-O, --overlay   the dtb file is an overlay\n"
   "\t-h, --help  print a help message\n",
   tool_name);
 }
 
-static int fdt_add_pub_key_data(void *sptr, void *dptr, size_t key_size,
-   bool overlay)
-{
-   int parent;
-   int ov_node;
-   int frag_node;
-   int ret = 0;
-
-   if (overlay) {
-   /*
-* The signature would be stored in the
-* first fragment node of the overlay
-*/
-   frag_node = fdt_first_subnode(dptr, 0);
-   if (frag_node == -FDT_ERR_NOTFOUND) {
-   fprintf(stderr,
-   "Couldn't find the fragment node: %s\n",
-   fdt_strerror(frag_node));
-   goto done;
-   }
-
-   ov_node = fdt_subnode_offset(dptr, frag_node, OVERLAY_NODENAME);
-   if (ov_node == -FDT_ERR_NOTFOUND) {
-   fprintf(stderr,
-   "Couldn't find the __overlay__ node: %s\n",
-   fdt_strerror(ov_node));
-   goto done;
-   }
-   } else {
-   ov_node = 0;
-   }
-
-   parent = fdt_subnode_offset(dptr, ov_node, SIGNATURE_NODENAME);
-   if (parent == -FDT_ERR_NOTFOUND) {
-   parent = fdt_add_subnode(dptr, ov_node, SIGNATURE_NODENAME);
-   if (parent < 0) {
-   ret = parent;
-   if (ret != -FDT_ERR_NOSPACE) {
-   fprintf(stderr,
-   "Couldn't create signature node: %s\n",
-   fdt_strerror(parent));
-   }
-   }
-   }
-   if (ret)
-   goto done;
-
-   /* Write the key to the FDT node */
-   ret = fdt_setprop(dptr, parent, "capsule-key",
- sptr, key_size);
-
-done:
-   if (ret)
-   ret = ret == -FDT_ERR_NOSPACE ? -ENOSPC : -EIO;
-
-   return ret;
-}
-
-static int add_public_key(const char *pkey_file, const char *dtb_file,
- bool overlay)
-{
-   int ret;
-   int srcfd = -1;
-   int destfd = -1;
-   void *sptr = NULL;
-   void *dptr = NULL;
-   off_t src_size;
-   struct stat pub_key;
-   struct stat dtb;
-
-   /* Find out the size of the public key */
-   srcfd = open(pkey_file, O_RDONLY);
-   if (srcfd == -1) {
-   fprintf(stderr, "%s: Can't open %s: %s\n",
-   __func__, pkey_file, strerror(errno));
-   ret = -1;
-   goto err;
-   }
-
-   ret = fstat(srcfd, &pub_key);
-   if (ret == -1) {
-   fprintf(stderr, "%s: Can't stat %s: %s\n",
-   __func__, pkey_file, strerror(errno));
-   ret = -1;
-   goto err;
-   }
-
-   src_size = pub_key.st_size;
-
-   /* mmap the public key esl file */
-   sptr = mmap(0, src_size, PROT_READ, MAP_SHARED, srcfd, 0);
-   if (sptr == MAP_FAILED) {
-   fpr

[PATCH 3/3] doc: Update CapsuleUpdate READMEs

[Ilias Apalodimas]

Since we removed embeddingg the capsule key into a .dtb and fixed
authenticated capsule updates for all boards, move the relevant
documentation in the efi file and update it accordingly

Signed-off-by: Ilias Apalodimas 
---
 doc/board/emulation/qemu_capsule_update.rst | 203 
 doc/develop/uefi/uefi.rst   | 125 
 2 files changed, 125 insertions(+), 203 deletions(-)
 delete mode 100644 doc/board/emulation/qemu_capsule_update.rst

diff --git a/doc/board/emulation/qemu_capsule_update.rst 
b/doc/board/emulation/qemu_capsule_update.rst
deleted file mode 100644
index 0a2286d039d9..
--- a/doc/board/emulation/qemu_capsule_update.rst
+++ /dev/null
@@ -1,203 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0+
-.. Copyright (C) 2020, Linaro Limited
-
-Enabling UEFI Capsule Update feature
-
-
-Support has been added for the UEFI capsule update feature which
-enables updating the U-Boot image using the UEFI firmware management
-protocol (fmp). The capsules are not passed to the firmware through
-the UpdateCapsule runtime service. Instead, capsule-on-disk
-functionality is used for fetching the capsule from the EFI System
-Partition (ESP) by placing the capsule file under the
-\EFI\UpdateCapsule directory.
-
-Currently, support has been added on the QEMU ARM64 virt platform for
-updating the U-Boot binary as a raw image when the platform is booted
-in non-secure mode, i.e. with CONFIG_TFABOOT disabled. For this
-configuration, the QEMU platform needs to be booted with
-'secure=off'. The U-Boot binary placed on the first bank of the NOR
-flash at offset 0x0. The U-Boot environment is placed on the second
-NOR flash bank at offset 0x400.
-
-The capsule update feature is enabled with the following configuration
-settings::
-
-CONFIG_MTD=y
-CONFIG_FLASH_CFI_MTD=y
-CONFIG_CMD_MTDPARTS=y
-CONFIG_CMD_DFU=y
-CONFIG_DFU_MTD=y
-CONFIG_PCI_INIT_R=y
-CONFIG_EFI_CAPSULE_ON_DISK=y
-CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT=y
-CONFIG_EFI_CAPSULE_FIRMWARE=y
-CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
-CONFIG_EFI_CAPSULE_FMP_HEADER=y
-
-In addition, the following config needs to be disabled(QEMU ARM specific)::
-
-CONFIG_TFABOOT
-
-The capsule file can be generated by using the tools/mkeficapsule::
-
-$ mkeficapsule --raw  --index 1 
-
-As per the UEFI specification, the capsule file needs to be placed on
-the EFI System Partition, under the \EFI\UpdateCapsule directory. The
-EFI System Partition can be a virtio-blk-device.
-
-Before initiating the firmware update, the efi variables BootNext,
-Boot and OsIndications need to be set. The Boot variable needs
-to be pointing to the EFI System Partition which contains the capsule
-file. The BootNext, Boot and OsIndications variables can be set
-using the following commands::
-
-=> efidebug boot add -b 0 Boot virtio 0:1 
-=> efidebug boot next 0
-=> setenv -e -nv -bs -rt -v OsIndications =0x04
-=> saveenv
-
-Finally, the capsule update can be initiated with the following
-command::
-
-=> efidebug capsule disk-update
-
-The updated U-Boot image will be booted on subsequent boot.
-
-Enabling Capsule Authentication
-^^^
-
-The UEFI specification defines a way of authenticating the capsule to
-be updated by verifying the capsule signature. The capsule signature
-is computed and prepended to the capsule payload at the time of
-capsule generation. This signature is then verified by using the
-public key stored as part of the X509 certificate. This certificate is
-in the form of an efi signature list (esl) file, which is embedded as
-part of the platform's device tree blob using the mkeficapsule
-utility.
-
-On the QEMU virt platforms, the device-tree is generated on the fly
-based on the devices configured. This device tree is then passed on to
-the various software components booting on the platform, including
-U-Boot. Therefore, on the QEMU virt platform, the signatute is
-embedded on an overlay. This overlay is then applied at runtime to the
-base platform device-tree. Steps needed for embedding the esl file in
-the overlay are highlighted below.
-
-The capsule authentication feature can be enabled through the
-following config, in addition to the configs listed above for capsule
-update::
-
-CONFIG_EFI_CAPSULE_AUTHENTICATE=y
-
-The public and private keys used for the signing process are generated
-and used by the steps highlighted below::
-
-1. Install utility commands on your host
-   * OPENSSL
-   * efitools
-
-2. Create signing keys and certificate files on your host
-
-$ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=CRT/ \
--keyout CRT.key -out CRT.crt -nodes -days 365
-$ cert-to-efi-sig-list CRT.crt CRT.esl
-
-$ openssl x509 -in CRT.crt -out CRT.cer -outform DER
-$ openssl x509 -inform DER -in CRT.cer -outform PEM -out CRT.pub

Re: [Uboot-stm32] [PATCH v2 2/5] arm: stm32mp: handle the OP-TEE nodes in DT with FIP support

[Ahmad Fatoum]

Hello Patrick,

On 15.07.21 17:22, Patrick Delaunay wrote:
> With FIP support in TF-A (when CONFIG_STM32MP15x_STM32IMAGE
> is not activated), the DT nodes needed by OP-TEE are added by OP-TEE
> firmware in U-Boot device tree, present in FIP.

What about the SCMI nodes. Who will fix up those?

> These nodes are only required in trusted boot, when TF-A load the file
> u-boot.stm32, including the U-Boot device tree with STM32IMAGE header,
> in this case OP-TEE can't update the U-Boot device tree.

[snip]

Cheers,
Ahmad


-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[PATCH u-boot-mvebu 1/2] ARM: dts: armada-385-turris-omnia: add `u-boot-env` NOR partition

[Marek Behún]

Specify a separate partition `u-boot-env` for U-Boot's env settings for
the Turris Omnia board.

Do this only in U-Boot's specific DTS. We do not want to do this in
Linux' official DTS, because Omnia's stock U-Boot stores env at a
different address, and there are still boards with stock U-Boot.

In a subsequent patch will add board code that fixes Linux's DTB before
booting Linux.

Signed-off-by: Marek Behún 
---
 arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi 
b/arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi
index af0655daaa..3ff76c9462 100644
--- a/arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi
+++ b/arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi
@@ -43,6 +43,17 @@
 
spi-nor@0 {
u-boot,dm-pre-reloc;
+
+   partitions {
+   partition@0 {
+   reg = <0x0 CONFIG_ENV_OFFSET>;
+   };
+
+   partition@f {
+   reg = ;
+   label = "u-boot-env";
+   };
+   };
};
 };
 
-- 
2.31.1

[PATCH u-boot-mvebu 2/2] arm: mvebu: turris_omnia: fixup MTD partitions in Linux' DTB

[Marek Behún]

Fixup SPI NOR partition nodes in Linux' device tree prior booting Linux.

Linux' devicetree does not contain "u-boot-env" partition and we do not
want to add it there because the address is different between stock
U-Boot and current upstream U-Boot.

Instead we add code that recreates partition nodes from scratch
according to how U-Boot sees them (which is defined in U-Boot's device
tree).

Signed-off-by: Marek Behún 
---
Hi Stefan,

the code of the fixup_mtd_partitions() function I am adding with this
patch is generic enough to be potentially used on other boards (for
example EspressoBIN's board code does something similar, so it could use
this function).

Indeed I want to generalize it, since there are multiple boards fixing
partition nodes in DTS prior booting Linux and there is already code for
this in common/fdt_support.c. The problem is that that code does not work
with DM_MTD, but rather with the obsolete MTDPARTS and several boards use
it. I want to convert those boards into using this new API, but this will
take some time and should be done via u-boot-spi tree.

So please for now merge this code via the mvebu tree. In the meantime
till this is merged into Tom's tree I shall be working on converting
those other boards that use fdt_fixup_mtdparts() to use device tree for
defining MTD partitions so that we can remove fdt_fixup_mtdparts(), move
this new code into common/fdt_support.c and covert those boards to use
this new code.
---
 board/CZ.NIC/turris_omnia/turris_omnia.c | 90 
 configs/turris_omnia_defconfig   |  1 +
 2 files changed, 91 insertions(+)

diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c 
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index 8b2f94f959..a7e5f56eed 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -31,6 +32,8 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#define OMNIA_SPI_NOR_PATH "/soc/spi@10600/spi-nor@0"
+
 #define OMNIA_I2C_BUS_NAME "i2c@11000->i2cmux@70->i2c@0"
 
 #define OMNIA_I2C_MCU_CHIP_ADDR0x2a
@@ -557,3 +560,90 @@ out:
return 0;
 }
 
+#if defined(CONFIG_OF_BOARD_SETUP)
+/*
+ * I plan to generalize this function and move it to common/fdt_support.c.
+ * This will require some more work on multiple boards, though, so for now 
leave
+ * it here.
+ */
+static bool fixup_mtd_partitions(void *blob, int offset, struct mtd_info *mtd)
+{
+   struct mtd_info *slave;
+   int parts;
+
+   parts = fdt_subnode_offset(blob, offset, "partitions");
+   if (parts < 0)
+   return false;
+
+   if (fdt_del_node(blob, parts) < 0)
+   return false;
+
+   parts = fdt_add_subnode(blob, offset, "partitions");
+   if (parts < 0)
+   return false;
+
+   if (fdt_setprop_u32(blob, parts, "#address-cells", 1) < 0)
+   return false;
+
+   if (fdt_setprop_u32(blob, parts, "#size-cells", 1) < 0)
+   return false;
+
+   if (fdt_setprop_string(blob, parts, "compatible",
+  "fixed-partitions") < 0)
+   return false;
+
+   mtd_probe_devices();
+
+   list_for_each_entry(slave, &mtd->partitions, node) {
+   char name[32];
+   int part;
+
+   snprintf(name, sizeof(name), "partition@%llx", slave->offset);
+   part = fdt_add_subnode(blob, parts, name);
+   if (part < 0)
+   return false;
+
+   if (fdt_setprop_u32(blob, part, "reg", slave->offset) < 0)
+   return false;
+
+   if (fdt_appendprop_u32(blob, part, "reg", slave->size) < 0)
+   return false;
+
+   if (fdt_setprop_string(blob, part, "label", slave->name) < 0)
+   return false;
+
+   if (!(slave->flags & MTD_WRITEABLE))
+   if (fdt_setprop_empty(blob, part, "read-only") < 0)
+   return false;
+
+   if (slave->flags & MTD_POWERUP_LOCK)
+   if (fdt_setprop_empty(blob, part, "lock") < 0)
+   return false;
+   }
+
+   return true;
+}
+
+int ft_board_setup(void *blob, struct bd_info *bd)
+{
+   struct mtd_info *mtd;
+   int node;
+
+   mtd = get_mtd_device_nm(OMNIA_SPI_NOR_PATH);
+   if (IS_ERR_OR_NULL(mtd))
+   goto fail;
+
+   node = fdt_path_offset(blob, OMNIA_SPI_NOR_PATH);
+   if (node < 0)
+   goto fail;
+
+   if (!fixup_mtd_partitions(blob, node, mtd))
+   goto fail;
+
+   return 0;
+
+fail:
+   printf("Failed fixing SPI NOR partitions!\n");
+   return 0;
+}
+#endif
diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig
index f860cf5e7d..5f7b1a67a2 100644
--- a/configs/turris_omnia_defconfi

Re: [PATCH 4/9] sandbox: tpm: Correct handling of get-capability

[Ilias Apalodimas]

Hi Simon, 

On Mon, Jul 05, 2021 at 09:48:44AM -0600, Simon Glass wrote:
> This function current handles the kernel case incorrectly. Fix it, and
> use the shorter TPM_HDR_LEN while we are here.
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  drivers/tpm/tpm_tis_sandbox.c | 14 --
>  1 file changed, 4 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/tpm/tpm_tis_sandbox.c b/drivers/tpm/tpm_tis_sandbox.c
> index 85b22afa4d9..efbeb00ab63 100644
> --- a/drivers/tpm/tpm_tis_sandbox.c
> +++ b/drivers/tpm/tpm_tis_sandbox.c
> @@ -140,16 +140,13 @@ static int sandbox_tpm_xfer(struct udevice *dev, const 
> uint8_t *sendbuf,
>   printf("Get flags index %#02x\n", index);
>   *recv_len = 22;
>   memset(recvbuf, '\0', *recv_len);
> - data = recvbuf + TPM_RESPONSE_HEADER_LENGTH +
> - sizeof(uint32_t);
> + data = recvbuf + TPM_HDR_LEN + sizeof(uint32_t);
>   switch (index) {
>   case FIRMWARE_NV_INDEX:
>   break;
>   case KERNEL_NV_INDEX:
>   handle_cap_flag_space(&data, index);
> - *recv_len = data - recvbuf -
> - TPM_RESPONSE_HEADER_LENGTH -
> - sizeof(uint32_t);
> + *recv_len = data - recvbuf;

This is the only actual fix right?
TPM_RESPONSE_HEADER_LENGTH and TPM_HDR_LEN are both defined to 10?
Is it worth updating the commit message with exactly the problem that was
fixed?

>   break;
>   case TPM_CAP_FLAG_PERMANENT: {
>   struct tpm_permanent_flags *pflags;
> @@ -166,15 +163,12 @@ static int sandbox_tpm_xfer(struct udevice *dev, const 
> uint8_t *sendbuf,
>   printf("   ** Unknown flags index %x\n", index);
>   return -ENOSYS;
>   }
> - put_unaligned_be32(*recv_len,
> -recvbuf +
> -TPM_RESPONSE_HEADER_LENGTH);
> + put_unaligned_be32(*recv_len, recvbuf + TPM_HDR_LEN);
>   break;
>   case TPM_CAP_NV_INDEX:
>   index = get_unaligned_be32(sendbuf + 18);
>   printf("Get cap nv index %#02x\n", index);
> - put_unaligned_be32(22, recvbuf +
> -TPM_RESPONSE_HEADER_LENGTH);
> + put_unaligned_be32(22, recvbuf + TPM_HDR_LEN);
>   break;
>   default:
>   printf("   ** Unknown 0x65 command type %#02x\n",
> -- 
> 2.32.0.93.g670b81a890-goog
> 

Re: [PATCH 5/9] sandbox: tpm: Finish comments for struct sandbox_tpm2

[Ilias Apalodimas]

On Mon, Jul 05, 2021 at 09:48:45AM -0600, Simon Glass wrote:
> Tidy up the missing comments for this struct.
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  drivers/tpm/tpm2_tis_sandbox.c | 20 
>  1 file changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/tpm/tpm2_tis_sandbox.c b/drivers/tpm/tpm2_tis_sandbox.c
> index 24c804a5645..5e0bd304699 100644
> --- a/drivers/tpm/tpm2_tis_sandbox.c
> +++ b/drivers/tpm/tpm2_tis_sandbox.c
> @@ -45,19 +45,31 @@ static const u8 sandbox_extended_once_pcr[] = {
>   0xea, 0x98, 0x31, 0xa9, 0x27, 0x59, 0xfb, 0x4b,
>  };
>  
> +/*
> + * Information about our TPM emulation. This is preserved in the sandbox
> + * state file if enabled.
> + *
> + * @init_done: true if open() has been called
> + * @startup_done: true if TPM2_CC_STARTUP has been processed
> + * @tests_done: true if TPM2_CC_SELF_TEST has be processed
> + * @pw: TPM password per hierarchy
> + * @pw_sz: Size of each password in bytes
> + * @properties: TPM properties
> + * @pcr: TPM Platform Configuration Registers. Each of these holds a hash and
> + *   can be 'extended' a number of times, meaning another hash is added into
> + *   its value (initial value all zeroes)
> + * @pcr_extensions: Number of times each PCR has been extended (starts at 0)
> + * @nvdata: non-volatile data, used to store important things for the 
> platform
> + */
>  struct sandbox_tpm2 {
>   /* TPM internal states */
>   bool init_done;
>   bool startup_done;
>   bool tests_done;
> - /* TPM password per hierarchy */
>   char pw[TPM2_HIERARCHY_NB][TPM2_DIGEST_LEN + 1];
>   int pw_sz[TPM2_HIERARCHY_NB];
> - /* TPM properties */
>   u32 properties[TPM2_PROPERTY_NB];
> - /* TPM PCRs */
>   u8 pcr[SANDBOX_TPM_PCR_NB][TPM2_DIGEST_LEN];
> - /* TPM PCR extensions */
>   u32 pcr_extensions[SANDBOX_TPM_PCR_NB];
>  };
>  
> -- 
> 2.32.0.93.g670b81a890-goog
> 

Acked-by: Ilias Apalodimas 

Re: [PATCHv2 1/2] i2c: add dm_i2c_reg_clrset

[Simon Glass]

On Thu, 15 Jul 2021 at 09:40, Sebastian Reichel
 wrote:
>
> Add function to apply a bitmask to an i2c register, so
> that specific bits can be cleared and/or set.
>
> Suggested-by: Simon Glass 
> Signed-off-by: Sebastian Reichel 
> ---
>  drivers/i2c/i2c-uclass.c | 15 +++
>  include/i2c.h| 14 ++
>  test/dm/i2c.c| 29 +
>  3 files changed, 58 insertions(+)

Reviewed-by: Simon Glass 

Re: [PATCHv2 2/2] gpio: mcp230xx: Introduce new driver

[Simon Glass]

Hi Sebastian,

On Thu, 15 Jul 2021 at 09:40, Sebastian Reichel
 wrote:
>
> Introduce driver for I2C based MCP230xx GPIO chips, which are
> quite common and already well supported by the Linux kernel.
>
> Reviewed-by: Simon Glass 
> Signed-off-by: Sebastian Reichel 
> ---
>  drivers/gpio/Kconfig |  10 ++
>  drivers/gpio/Makefile|   1 +
>  drivers/gpio/mcp230xx_gpio.c | 235 +++
>  3 files changed, 246 insertions(+)
>  create mode 100644 drivers/gpio/mcp230xx_gpio.c

Reviewed-by: Simon Glass 

BTW I see there is no change log on this patch. Patman will do this
for you automatically.


- Simon

u-boot and mtdparts

[Marek Behún]

Hello Tom and others,

many boards still use the obsolete mtdparts command.
What is the plan with this command? Do we still want to support it?

Recently as discovered by Masami, my patch
  mtd: spi-nor: allow  registering multiple MTDs when DM is enabled
caused that mtds may have different name than that defined in
CONFIG_MTDPARTS_DEFAULT.
Masami fixed his board by putting the partition definitions into
devicetree, but there are still many boards that may be broken.

The easy fix here is to make mtd_device_matches_name() in
drivers/mtd/mtdcore.c to support the old names. Most of them are in
format "type.id", for example "nor.1", "nand.1", but some are different.

The problem is that I do not know how exactly to match these names with
the devices. Does the number represent the bus, or chip select or
something else?

There are also multiple parsers of the mtdparts string (at least two,
one in cmd/mtdparts.c and the other in drivers/mtd/mtd_uboot.c).

IMO the proper solution would be to get rid of the mtdparts entirely,
move it to devicetree, and add code that generates the mtdparts string
for Linux' command line from devicetree.

What do you think?

Marek

[PATCH] CI: Update to LLVM-12

[Tom Rini]

The current stable release of LLVM is 12, update to that.  While at it,
fix that we had not correctly upgraded to LLVM 11 previously.

Signed-off-by: Tom Rini 
---
 .azure-pipelines.yml| 4 ++--
 .gitlab-ci.yml  | 4 ++--
 tools/docker/Dockerfile | 6 +++---
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index e3a994e0c441..2449817af59c 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -2,7 +2,7 @@ variables:
   windows_vm: vs2017-win2016
   ubuntu_vm: ubuntu-18.04
   macos_vm: macOS-10.15
-  ci_runner_image: trini/u-boot-gitlab-ci-runner:focal-20210609-06Jul2021
+  ci_runner_image: trini/u-boot-gitlab-ci-runner:focal-20210713-15Jul2021
   # Add '-u 0' options for Azure pipelines, otherwise we get "permission
   # denied" error when it tries to "useradd -m -u 1001 vsts_azpcontainer",
   # since our $(ci_runner_image) user is not root.
@@ -183,7 +183,7 @@ jobs:
   TEST_PY_BD: "sandbox"
 sandbox_clang:
   TEST_PY_BD: "sandbox"
-  OVERRIDE: "-O clang-10"
+  OVERRIDE: "-O clang-12"
 sandbox_spl:
   TEST_PY_BD: "sandbox_spl"
   TEST_PY_TEST_SPEC: "test_ofplatdata or test_handoff or test_spl"
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 86026a15f9da..40722d887b8b 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -2,7 +2,7 @@
 
 # Grab our configured image.  The source for this is found at:
 # https://source.denx.de/u-boot/gitlab-ci-runner
-image: trini/u-boot-gitlab-ci-runner:focal-20210609-06Jul2021
+image: trini/u-boot-gitlab-ci-runner:focal-20210713-15Jul2021
 
 # We run some tests in different order, to catch some failures quicker.
 stages:
@@ -178,7 +178,7 @@ sandbox test.py:
 sandbox with clang test.py:
   variables:
 TEST_PY_BD: "sandbox"
-OVERRIDE: "-O clang-10"
+OVERRIDE: "-O clang-12"
   <<: *buildman_and_testpy_dfn
 
 sandbox_spl test.py:
diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile
index ced4457ab20d..f4ad2213c74b 100644
--- a/tools/docker/Dockerfile
+++ b/tools/docker/Dockerfile
@@ -2,7 +2,7 @@
 # This Dockerfile is used to build an image containing basic stuff to be used
 # to build U-Boot and run our test suites.
 
-FROM ubuntu:focal-20210609
+FROM ubuntu:focal-20210713
 MAINTAINER Tom Rini 
 LABEL Description=" This image is for building U-Boot inside a container"
 
@@ -12,7 +12,7 @@ ENV DEBIAN_FRONTEND=noninteractive
 # Add LLVM repository
 RUN apt-get update && apt-get install -y gnupg2 wget xz-utils && rm -rf 
/var/lib/apt/lists/*
 RUN wget -O - https://apt.llvm.org/llvm-snapshot.gpg.key | apt-key add -
-RUN echo deb http://apt.llvm.org/focal/ llvm-toolchain-focal-11 main | tee 
/etc/apt/sources.list.d/llvm.list
+RUN echo deb http://apt.llvm.org/focal/ llvm-toolchain-focal-12 main | tee 
/etc/apt/sources.list.d/llvm.list
 
 # Manually install the kernel.org "Crosstool" based toolchains for gcc-11.1.0
 RUN wget -O - 
https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/11.1.0/x86_64-gcc-11.1.0-nolibc-aarch64-linux.tar.xz
 | tar -C /opt -xJ
@@ -39,7 +39,7 @@ RUN apt-get update && apt-get install -y \
binutils-dev \
bison \
build-essential \
-   clang-10 \
+   clang-12 \
coreutils \
cpio \
cppcheck \
-- 
2.17.1

Re: u-boot and mtdparts

[Simon Glass]

Hi Marek,

On Thu, 15 Jul 2021 at 12:13, Marek Behún  wrote:
>
> Hello Tom and others,
>
> many boards still use the obsolete mtdparts command.
> What is the plan with this command? Do we still want to support it?
>
> Recently as discovered by Masami, my patch
>   mtd: spi-nor: allow  registering multiple MTDs when DM is enabled
> caused that mtds may have different name than that defined in
> CONFIG_MTDPARTS_DEFAULT.
> Masami fixed his board by putting the partition definitions into
> devicetree, but there are still many boards that may be broken.
>
> The easy fix here is to make mtd_device_matches_name() in
> drivers/mtd/mtdcore.c to support the old names. Most of them are in
> format "type.id", for example "nor.1", "nand.1", but some are different.
>
> The problem is that I do not know how exactly to match these names with
> the devices. Does the number represent the bus, or chip select or
> something else?
>
> There are also multiple parsers of the mtdparts string (at least two,
> one in cmd/mtdparts.c and the other in drivers/mtd/mtd_uboot.c).
>
> IMO the proper solution would be to get rid of the mtdparts entirely,
> move it to devicetree, and add code that generates the mtdparts string
> for Linux' command line from devicetree.
>
> What do you think?

SGTM. Let's add some tests too.

Regards,
Simon

Re: [PATCH v4 1/5] spl: mmc: Support OP-TEE payloads in Falcon mode

[Patrick DELAUNAY]

Hi,

On 5/31/21 7:43 PM, Alexandru Gagniuc wrote:

In general, Falcon mode means we're booting a linux kernel directly.
With FIT images, however, an OP-TEE secure kernel can be booted before
linux. Thus, if the next stage is an IH_OS_TEE, this isn't necessarily
a problem.

Of course, a general solution would involve mmc_load_image_raw_os()
only loading the binary, and leaving the decision of suitability to
someone else. However, a rework of the boot flow is beyond the scope
of this patch. Accept IH_OS_TEE as a valid OS value.

Signed-off-by: Alexandru Gagniuc 
Reviewed-by: Tom Rini 
Reviewed-by: Patrick Delaunay 
---
  common/spl/spl_mmc.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index add2785b4e3..bab558d055f 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -230,8 +230,10 @@ static int mmc_load_image_raw_os(struct spl_image_info 
*spl_image,
if (ret)
return ret;
  
-	if (spl_image->os != IH_OS_LINUX) {

-   puts("Expected Linux image is not found. Trying to start 
U-boot\n");
+   if (spl_image->os != IH_OS_LINUX && spl_image->os != IH_OS_TEE) {
+   puts("Expected OS image is not found. Instead found ");
+   puts(genimg_get_os_name(spl_image->os));
+   puts(". Trying to start U-boot\n");
return -ENOENT;
}
  



When I merge this patch on master branch, I get the error:

arm:  +   imx6dl_mamoj
+= WARNING ==
+This board does not use CONFIG_DM_USB (Driver Model
+for  USB). Please update the board to use
+CONFIG_DM_USB before the v2019.07 release. Failure to
+update by the deadline may result in board removal.
+See doc/driver-model/migration.rst for more info.
+
+spl/u-boot-spl.bin exceeds file size limit:
+  limit:  0xefa0 bytes
+  actual: 0xf41d bytes
+  excess: 0x47d bytes
+make[1]: *** [Makefile:1997: spl/u-boot-spl.bin] Error 1
+make[1]: *** Deleting file 'spl/u-boot-spl.bin'
+make: *** [Makefile:177: sub-make] Error 2


The overhead:

$> tools/buildman/buildman -b TEST -c 2 imx6dl_mamoj

$> tools/buildman/buildman -b TEST -c 2 imx6dl_mamoj -seS

Summary of 2 commits for 1 boards (1 thread, 12 jobs per thread)

01: Merge branch '2021-07-14-build-and-host-updates'
   arm:  w+   imx6dl_mamoj
+= WARNING ==
+This board does not use CONFIG_DM_USB (Driver Model
+for  USB). Please update the board to use
+CONFIG_DM_USB before the v2019.07 release. Failure to
+update by the deadline may result in board removal.
+See doc/driver-model/migration.rst for more info.
+
02: spl: mmc: Support OP-TEE payloads in Falcon mode
   arm:  +   imx6dl_mamoj
+spl/u-boot-spl.bin exceeds file size limit:
+  limit:  0xefa0 bytes
+  actual: 0xf41d bytes
+  excess: 0x47d bytes
+make[1]: *** [Makefile:1997: spl/u-boot-spl.bin] Error 1
+make[1]: *** Deleting file 'spl/u-boot-spl.bin'
+make: *** [Makefile:177: sub-make] Error 2
   arm: (for 1/1 boards) spl/u-boot-spl:all +2242.0 
spl/u-boot-spl:rodata +2162.0 spl/u-boot-spl:text +80.0



With details :

diff 
01_gc11f5abce8_Merge-branch-\'2021-0/imx6dl_mamoj/spl-u-boot-spl.sizes 
02_g0620649bfa_spl--mmc--Support-OP/imx6dl_mamoj/spl-u-boot-spl.sizes

157a158,159
> 0012 T get_table_entry
> 0012 T get_table_entry_name
171a174
> 0014 T genimg_get_os_name
531a535
> 00a8 r uimage_os
563d566
< 0134 T spl_mmc_load
566a570
> 014c T spl_mmc_load


This issue need to be solved before I accept and merge the serie.


See also ./common/spl/spl_fit.c:514:

     This saves some
     * space by omitting the large table of OS types.
     */


But I think again about the title of this patch :

- spl: mmc: Support OP-TEE payloads in Falcon mode


If I unterstood after the serie the sequence for MMC is:

 ROM code => SPL => TEE (as raw OS) => U-Boot


but it is not really the Falcon mode and
OP-TEE + falcon mode is not really supported...


And the patch title is disturbing.


For me the correct sequence is in Falcon mode is :

    ROM code => SPL => TEE (secure world) => kernel (normal world)


With the TEE and the kernel loaded by the SPL..


and without falcon mode :

(A)    ROM code => SPL => TEE (secure world) => U-Boot

or

(B)    ROM code => SPL (TZ) => U-Boot (TZ) execute bootm => TEE (secure 
world) => kernel



what it your expected sequence in spl_load_simple_fit in this serie / in 
your defconfig ?


Today with the normal world address can be:

1/ = spl_image->entry_point (bootm_os.c in U-Boot proprer)

2/ = CONFIG_SYS_TEXT_BASE (hardcoded for SPL in spl_optee.S)


for 2/ When U-Boot is not used after SPL =  in falcon mode,

the LR register shoud be set to kernel entry point.

Patrick

Re: Please pull u-boot-marvell/master

[Tom Rini]

On Thu, Jul 15, 2021 at 12:36:58PM +0200, Stefan Roese wrote:

> Hi Tom,
> 
> please pull the next batch of Marvell MVEBU related patches. Here the
> summary log:
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: Please pull u-boot-x86

[Tom Rini]

On Thu, Jul 15, 2021 at 09:54:08PM +0800, Bin Meng wrote:

> Hi Tom,
> 
> This PR includes the following changes for v2021.10:
> 
> - x86: various improvements made in getting Chromium OS verified boot
>   running on top of coreboot, booting into U-Boot.
> 
> Azure results: PASS
> https://dev.azure.com/bmeng/GitHub/_build/results?buildId=383&view=results
> 
> The following changes since commit c11f5abce84f630c92304683d5bde3204c5612c4:
> 
>   Merge branch '2021-07-14-build-and-host-updates' (2021-07-14 20:10:34 -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-x86
> 
> for you to fetch changes up to 2f91fc40039d2ef6f433d5c56c4f4701975f510f:
> 
>   x86: Ensure the e820 map is installed in all cases (2021-07-15 19:56:16 
> +0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

[PATCH v2 0/6] Convert MIPS Malta boards to PCI DM

[Daniel Schwierzeck]

This series converts the PCI host controller drivers used by MIPS
Malta and the board-specific PCI setup code to PCI driver model.
Because the AMD PCNET driver is already converted to ETH driver
model, simply enable CONFIG_DM_ETH as well.

A patch in PCI uclass core is currently required for MIPS wanting
to use PCI DM (except Octeon MIPS64) due to CONFIG_SYS_SDRAM_BASE
being used as a virtual address on all MIPS boards.

The series for now is only tested with Qemu and the GT64120 PCI
controller. The Malta Qemu tests are already covered by U-Boot CI
Support for the MSC01 controller is prepared. The used PCI controller
depends on the plugged core card (Qemu emulates the CoreLV card with
GT64120).

Dynamic selection of the according PCI DT nodes via CONFIG_OF_BOARD_FIXUP
is prepared but not yet enabled. This requires fixing of the call order of
fix_fdt() in board_init_f, otherwise the passed-in rw_fdt_blob pointer
will point to a read-only NOR flash address. I'll send a separate
RFC patch for this.

I'll send a cleanup series for removing non-DM code after the merge
windows has closed and the PCI DM conversion deadline has been
enforced.

Changes in v2:
- add empty line before return statements
- add empty line before return statements
- use dm_pci_clrset_config32() where possible

Daniel Schwierzeck (6):
  dm: pci: add option to map virtual system memory base address
  pci: gt64120: convert to driver model
  pci: msc01: convert to driver model
  MIPS: malta: add DT bindings for PCI host controller
  MIPS: malta: add support for PCI driver model
  MIPS: malta: enable PCI driver model

 arch/mips/Kconfig   |  4 ++
 arch/mips/dts/mti,malta.dts | 28 +
 board/imgtec/malta/malta.c  | 80 -
 drivers/pci/Kconfig | 13 ++
 drivers/pci/pci-uclass.c|  9 +++--
 drivers/pci/pci_gt64120.c   | 74 +-
 drivers/pci/pci_msc01.c | 72 -
 7 files changed, 274 insertions(+), 6 deletions(-)

-- 
2.32.0

[PATCH v2 1/6] dm: pci: add option to map virtual system memory base address

[Daniel Schwierzeck]

On MIPS the DRAM start address respectively CONFIG_SYS_SDRAM_BASE
is still used as a virtual, CPU-mapped address instead of being used
as physical address. Converting all MIPS boards and generic MIPS code
to fix that is not trivial. Due to the approaching deadline for
PCI DM conversion, this workaround is required for MIPS boards with
PCI support until the CONFIG_SYS_SDRAM_BASE issue could be solved.

Add a compile-time option to let the PCI uclass core optionally map
the DRAM address to a physical address when adding the PCI region
of type PCI_REGION_SYS_MEMORY.

Signed-off-by: Daniel Schwierzeck 

Reviewed-by: Stefan Roese 
---

(no changes since v1)

 drivers/pci/Kconfig  | 13 +
 drivers/pci/pci-uclass.c |  9 ++---
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 517cf956ea..c49cb6eac9 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -54,6 +54,19 @@ config PCI_REGION_MULTI_ENTRY
  region type. This helps to add support for SoC's like OcteonTX/TX2
  where every peripheral is on the PCI bus.
 
+config PCI_MAP_SYSTEM_MEMORY
+   bool "Map local system memory from a virtual base address"
+   depends on PCI || DM_PCI
+   depends on MIPS
+   default n
+   help
+ Say Y if base address of system memory is being used as a virtual 
address
+ instead of a physical address (e.g. on MIPS). The PCI core will then 
remap
+ the virtual memory base address to a physical address when adding the 
PCI
+ region of type PCI_REGION_SYS_MEMORY.
+ This should only be required on MIPS where CONFIG_SYS_SDRAM_BASE is 
still
+ being used as virtual address.
+
 config PCI_SRIOV
bool "Enable Single Root I/O Virtualization support for PCI"
depends on PCI || DM_PCI
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index cb9aa81835..110a12b94b 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -1003,10 +1003,13 @@ static void decode_regions(struct pci_controller *hose, 
ofnode parent_node,
 
for (i = 0; i < CONFIG_NR_DRAM_BANKS; ++i) {
if (bd->bi_dram[i].size) {
+   phys_addr_t start = bd->bi_dram[i].start;
+
+   if (IS_ENABLED(CONFIG_PCI_MAP_SYSTEM_MEMORY))
+   start = virt_to_phys((void 
*)(uintptr_t)bd->bi_dram[i].start);
+
pci_set_region(hose->regions + hose->region_count++,
-  bd->bi_dram[i].start,
-  bd->bi_dram[i].start,
-  bd->bi_dram[i].size,
+  start, start, bd->bi_dram[i].size,
   PCI_REGION_MEM | PCI_REGION_SYS_MEMORY);
}
}
-- 
2.32.0

[PATCH v2 2/6] pci: gt64120: convert to driver model

[Daniel Schwierzeck]

This driver is currently only used on MIPS Malta boards.

Signed-off-by: Daniel Schwierzeck 

Reviewed-by: Simon Glass 

---

Changes in v2:
- add empty line before return statements

 drivers/pci/pci_gt64120.c | 74 ++-
 1 file changed, 73 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/pci_gt64120.c b/drivers/pci/pci_gt64120.c
index 80f11fedd1..e57fedf036 100644
--- a/drivers/pci/pci_gt64120.c
+++ b/drivers/pci/pci_gt64120.c
@@ -8,7 +8,7 @@
  *Maciej W. Rozycki 
  */
 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -114,6 +114,7 @@ static int gt_config_access(struct gt64120_pci_controller 
*gt,
return 0;
 }
 
+#if !IS_ENABLED(CONFIG_DM_PCI)
 static int gt_read_config_dword(struct pci_controller *hose, pci_dev_t dev,
int where, u32 *value)
 {
@@ -175,3 +176,74 @@ void gt64120_pci_init(void *regs, unsigned long sys_bus, 
unsigned long sys_phys,
pci_register_hose(hose);
hose->last_busno = pci_hose_scan(hose);
 }
+#else
+static int gt64120_pci_read_config(const struct udevice *dev, pci_dev_t bdf,
+  uint where, ulong *val,
+  enum pci_size_t size)
+{
+   struct gt64120_pci_controller *gt = dev_get_priv(dev);
+   u32 data = 0;
+
+   if (gt_config_access(gt, PCI_ACCESS_READ, bdf, where, &data)) {
+   *val = pci_get_ff(size);
+   return 0;
+   }
+
+   *val = pci_conv_32_to_size(data, where, size);
+
+   return 0;
+}
+
+static int gt64120_pci_write_config(struct udevice *dev, pci_dev_t bdf,
+   uint where, ulong val,
+   enum pci_size_t size)
+{
+   struct gt64120_pci_controller *gt = dev_get_priv(dev);
+   u32 data = 0;
+
+   if (size == PCI_SIZE_32) {
+   data = val;
+   } else {
+   u32 old;
+
+   if (gt_config_access(gt, PCI_ACCESS_READ, bdf, where, &old))
+   return 0;
+
+   data = pci_conv_size_to_32(old, val, where, size);
+   }
+
+   gt_config_access(gt, PCI_ACCESS_WRITE, bdf, where, &data);
+
+   return 0;
+}
+
+static int gt64120_pci_probe(struct udevice *dev)
+{
+   struct gt64120_pci_controller *gt = dev_get_priv(dev);
+
+   gt->regs = dev_remap_addr(dev);
+   if (!gt->regs)
+   return -EINVAL;
+
+   return 0;
+}
+
+static const struct dm_pci_ops gt64120_pci_ops = {
+   .read_config= gt64120_pci_read_config,
+   .write_config   = gt64120_pci_write_config,
+};
+
+static const struct udevice_id gt64120_pci_ids[] = {
+   { .compatible = "marvell,pci-gt64120" },
+   { }
+};
+
+U_BOOT_DRIVER(gt64120_pci) = {
+   .name   = "gt64120_pci",
+   .id = UCLASS_PCI,
+   .of_match   = gt64120_pci_ids,
+   .ops= >64120_pci_ops,
+   .probe  = gt64120_pci_probe,
+   .priv_auto  = sizeof(struct gt64120_pci_controller),
+};
+#endif
-- 
2.32.0