Re: [U-Boot] [PATCH v3 2/5] spi: add spi-mem driver for MediaTek MT7629 SoC

[Vignesh Raghavendra]

On 12/06/19 9:26 PM, Jagan Teki wrote:
> + Vignesh
> 
> On Tue, May 14, 2019 at 7:11 AM Weijie Gao  wrote:
>>
>> This patch adds spi-mem driver for MediaTek MT7629 SoC to access SPI-NOR
>> and SPI-NAND flashes.
>>
>> Cc: Jagan Teki 
>> Signed-off-by: Weijie Gao 
>> ---
>> Changes since v1: rename mtk_spimem to spi_snfi_spi. change pinctrl name.
>> Changes since v2: remove udevice in mtk_snfi_priv.
>> ---
>>  drivers/spi/Kconfig|   9 ++
>>  drivers/spi/Makefile   |   1 +
>>  drivers/spi/mtk_snfi_spi.c | 321 +
>>  3 files changed, 331 insertions(+)
>>  create mode 100644 drivers/spi/mtk_snfi_spi.c
>>
>> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
>> index 4f0f5d99953..8b6e0fb2d99 100644
>> --- a/drivers/spi/Kconfig
>> +++ b/drivers/spi/Kconfig
>> @@ -139,6 +139,15 @@ config MT7621_SPI
>>   the SPI NOR flash on platforms embedding this Ralink / MediaTek
>>   SPI core, like MT7621/7628/7688.
>>
>> +config MTK_SNFI_SPI
>> +   bool "Mediatek SPI memory controller driver"
>> +   depends on SPI_MEM
>> +   help
>> + Enable the Mediatek SPI memory controller driver. This driver is
>> + originally based on the MediaTek SNFI IP core. It can only be
>> + used to access SPI memory devices like SPI-NOR or SPI-NAND on
>> + platforms embedding this IP core, like MT7622/M7629.
>> +
>>  config MVEBU_A3700_SPI
>> bool "Marvell Armada 3700 SPI driver"
>> select CLK_ARMADA_3720
>> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
>> index f1e3becd2b7..5c639634777 100644
>> --- a/drivers/spi/Makefile
>> +++ b/drivers/spi/Makefile
>> @@ -36,6 +36,7 @@ obj-$(CONFIG_LPC32XX_SSP) += lpc32xx_ssp.o
>>  obj-$(CONFIG_MESON_SPIFC) += meson_spifc.o
>>  obj-$(CONFIG_MPC8XX_SPI) += mpc8xx_spi.o
>>  obj-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
>> +obj-$(CONFIG_MTK_SNFI_SPI) += mtk_snfi_spi.o
>>  obj-$(CONFIG_MT7621_SPI) += mt7621_spi.o
>>  obj-$(CONFIG_MSCC_BB_SPI) += mscc_bb_spi.o
>>  obj-$(CONFIG_MVEBU_A3700_SPI) += mvebu_a3700_spi.o
>> diff --git a/drivers/spi/mtk_snfi_spi.c b/drivers/spi/mtk_snfi_spi.c
>> new file mode 100644
>> index 000..0adc734a5c1
>> --- /dev/null
>> +++ b/drivers/spi/mtk_snfi_spi.c
>> @@ -0,0 +1,321 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Copyright (C) 2019 MediaTek Inc. All Rights Reserved.
>> + *
>> + * Author: Weijie Gao 
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define SNFI_MAC_CTL   0x500
>> +#define MAC_XIO_SELBIT(4)
>> +#define SF_MAC_EN  BIT(3)
>> +#define SF_TRIGBIT(2)
>> +#define WIP_READY  BIT(1)
>> +#define WIPBIT(0)
>> +
>> +#define SNFI_MAC_OUTL  0x504
>> +#define SNFI_MAC_INL   0x508
>> +
>> +#define SNFI_MISC_CTL  0x538
>> +#define SW_RST BIT(28)
>> +#define FIFO_RD_LTC_SHIFT  25
>> +#define FIFO_RD_LTCGENMASK(26, 25)
>> +#define LATCH_LAT_SHIFT8
>> +#define LATCH_LAT  GENMASK(9, 8)
>> +#define CS_DESELECT_CYC_SHIFT  0
>> +#define CS_DESELECT_CYCGENMASK(4, 0)
>> +
>> +#define SNF_STA_CTL1   0x550
>> +#define SPI_STATE  GENMASK(3, 0)
>> +
>> +#define SNFI_GPRAM_OFFSET  0x800
>> +#define SNFI_GPRAM_SIZE0x80
>> +
>> +#define SNFI_POLL_INTERVAL 50
>> +#define SNFI_RST_POLL_INTERVAL 100
>> +
>> +struct mtk_snfi_priv {
>> +   void __iomem *base;
>> +
>> +   struct clk nfi_clk;
>> +   struct clk pad_clk;
>> +};
>> +
>> +static int mtk_snfi_adjust_op_size(struct spi_slave *slave,
>> +  struct spi_mem_op *op)
>> +{
>> +   u32 nbytes;
>> +
>> +   /*
>> +* When there is input data, it will be appended after the output
>> +* data in the GPRAM. So the total size of either pure output data
>> +* or the output+input data must not exceed the GPRAM size.
>> +*/
>> +
>> +   nbytes = sizeof(op->cmd.opcode) + op->addr.nbytes +
>> +   op->dummy.nbytes;
>> +
>> +   if (nbytes + op->data.nbytes <= SNFI_GPRAM_SIZE)
>> +   return 0;
>> +
>> +   if (nbytes >= SNFI_GPRAM_SIZE)
>> +   return -ENOTSUPP;
>> +
>> +   op->data.nbytes = SNFI_GPRAM_SIZE - nbytes;
>> +
>> +   return 0;
>> +}
>> +
>> +static bool mtk_snfi_supports_op(struct spi_slave *slave,
>> +const struct spi_mem_op *op)
>> +{
>> +   if (op->cmd.buswidth > 1 || op->addr.buswidth > 1 ||
>> +   op->dummy.buswidth > 1 || op->data.buswidth > 1)
>> +   return false;
>> +

Re: [U-Boot] [PATCH] mx6sxsabresd: imximage.cfg: Handle the CONFIG_SECURE_BOOT case

[Fabio Estevam]

On Thu, Jun 13, 2019 at 6:10 PM Breno Matheus Lima  wrote:
>
> Secure boot is not enabled in mx6sxsabresd imximage.cfg, add support
> for it.
>
> Signed-off-by: Breno Lima 

Reviewed-by: Fabio Estevam 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] mx6sxsabresd: imximage.cfg: Handle the CONFIG_SECURE_BOOT case

[Peng Fan]

> Subject: [PATCH] mx6sxsabresd: imximage.cfg: Handle the
> CONFIG_SECURE_BOOT case
> 
> Secure boot is not enabled in mx6sxsabresd imximage.cfg, add support for it.
> 
> Signed-off-by: Breno Lima 
> ---
>  board/freescale/mx6sxsabresd/imximage.cfg | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/board/freescale/mx6sxsabresd/imximage.cfg
> b/board/freescale/mx6sxsabresd/imximage.cfg
> index 3e94f6ab66..0354bb36e2 100644
> --- a/board/freescale/mx6sxsabresd/imximage.cfg
> +++ b/board/freescale/mx6sxsabresd/imximage.cfg
> @@ -17,6 +17,13 @@ IMAGE_VERSION 2
> 
>  BOOT_FROMsd
> 
> +/*
> + * Secure boot support
> + */
> +#ifdef CONFIG_SECURE_BOOT
> +CSF CONFIG_CSF_SIZE
> +#endif
> +
>  /*
>   * Device Configuration Data (DCD)

Reviewed-by: Peng Fan 

>   *
> --
> 2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] ARM: bcm2835: (Raspberry Pi) Fix issue on SD Host driver, where wait_transfer_complete was not waiting long enough

[Raul Benet]

Function bcm_2835_wait_transfer_complete() on driver/mmc/bcm2835_sdhost.c
(used on Raspberry Pi platform), was not waiting long enough for
transfer to complete.
The previous code was claiming to wait for ~1 seconds, but my measurements
on a RPi 3B+ indicated a maximum wait of 12 ms. Measured using
get_tiimer() function.
Some, but not all, of the cards we use, sometimes required wait times
of ~56 ms to perform
the command 'saveenv' on an EXT4 partition. (the exact operation being a CMD25
write of the superblock of EXT4).

Re-implemented the loop exit condition to use get_timer() which allows
to specify
the wait time in more reliable manner. Set the maximum wait time to
the originally
intended 1 second.

Signed-off by: Raul Benet 

---
 drivers/mmc/bcm2835_sdhost.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/bcm2835_sdhost.c b/drivers/mmc/bcm2835_sdhost.c
index 1ce019a..96e06b8 100644
--- a/drivers/mmc/bcm2835_sdhost.c
+++ b/drivers/mmc/bcm2835_sdhost.c
@@ -234,7 +234,7 @@ static void bcm2835_reset_internal(struct
bcm2835_host *host)

 static int bcm2835_wait_transfer_complete(struct bcm2835_host *host)
 {
- int timediff = 0;
+ulong tstart_ms = get_timer(0);

  while (1) {
  u32 edm, fsm;
@@ -254,11 +254,12 @@ static int bcm2835_wait_transfer_complete(struct
bcm2835_host *host)
  break;
  }

- /* Error out after 10 register reads (~1s) */
- if (timediff++ == 10) {
+ /* Error out after ~1s */
+ulong tlapse_ms = get_timer(tstart_ms);
+ if ( tlapse_ms > 1000 /* ms */ ) {
  dev_err(host->dev,
- "wait_transfer_complete - still waiting after %d retries\n",
- timediff);
+ "wait_transfer_complete - still waiting after %lu ms\n",
+ tlapse_ms);
  bcm2835_dumpregs(host);
  return -ETIMEDOUT;
  }
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] rtl8169: use dm_pci_map_bar

[Patrick Wildt]

On Thu, Jun 13, 2019 at 06:43:25PM +0200, Thierry Reding wrote:
> On Thu, Jun 13, 2019 at 03:16:10PM +0800, Bin Meng wrote:
> > Hi Stefan,
> > 
> > On Thu, Jun 13, 2019 at 1:40 PM Stefan Roese  wrote:
> > >
> > > Added Bin, Joe and Thierry to Cc
> > >
> > > On 11.06.19 13:15, Patrick Wildt wrote:
> > > > Hi,
> > > >
> > > > I have an rtl8169 on a macchiatobin and that card has a 64-bit
> > > > memory address.  The current code only reads a single word, which
> > > > means it can only support a 32-bit address.  By using dm_pci_map_bar
> > > > we don't need to manually parse the register, we can just have it do
> > > > its job.
> > > >
> > > > I'm not sure though if this works for all devices since the previous
> > > > version had an explicit check for the device.
> > > >
> > > > Patrick
> > > >
> > > > Signed-off-by: Patrick Wildt 
> > > >
> > > > diff --git a/drivers/net/rtl8169.c b/drivers/net/rtl8169.c
> > > > index 521e5909a2..f1d2ade253 100644
> > > > --- a/drivers/net/rtl8169.c
> > > > +++ b/drivers/net/rtl8169.c
> > > > @@ -1182,22 +1182,11 @@ static int rtl8169_eth_probe(struct udevice 
> > > > *dev)
> > > >   struct pci_child_platdata *pplat = dev_get_parent_platdata(dev);
> > > >   struct rtl8169_private *priv = dev_get_priv(dev);
> > > >   struct eth_pdata *plat = dev_get_platdata(dev);
> > > > - u32 iobase;
> > > > - int region;
> > > >   int ret;
> > > >
> > > > - debug("rtl8169: REALTEK RTL8169 @0x%x\n", iobase);
> > > > - switch (pplat->device) {
> > > > - case 0x8168:
> > > > - region = 2;
> > > > - break;
> > > > - default:
> > > > - region = 1;
> > > > - break;
> > > > - }
> > > > - dm_pci_read_config32(dev, PCI_BASE_ADDRESS_0 + region * 4, 
> > > > );
> > > > - iobase &= ~0xf;
> > > > - priv->iobase = (int)dm_pci_mem_to_phys(dev, iobase);
> > > > + priv->iobase = dm_pci_map_bar(dev, PCI_BASE_ADDRESS_2,
> > > > +   PCI_REGION_MEM);
> > > > + printf("rtl8169: REALTEK RTL8169 @0x%x\n", priv->iobase);
> > > >
> > > >   ret = rtl_init(priv->iobase, dev->name, plat->enetaddr);
> > > >   if (ret < 0) {
> > >
> > > Bin, Joe, Thierry,
> > >
> > > do you have any comments on this patch? Moving unconditionally to one
> > > BAR instead of BAR1/2 depending on the chip version seems a bit
> > > "brave".
> > 
> > Agreed that blinding setting one BAR for the iobase is not a good idea.
> 
> Agreed. I don't know whether it's actually required to differentiate
> based on version, but I suppose the code is like that for a reason, so
> better keep that.
> 
> Also, looking at dm_pci_map_bar() it doesn't look like that does
> anything different than the existing code. It merely reads a single
> 32-bit register, so it doesn't properly deal with 64-bit BARs either.
> 
> I suppose that could be fixed in dm_pci_map_bar(), and then the fix
> would automatically propagate to all users of that, which is good. But I
> don't think it currently works correctly.
> 
> Thierry

Oh, I'm very sorry to have wasted your time.  Yes, I agree, the
differentiation must come back.

To be honest it was about half a year ago, so I think I forgot the
actual issue.  Maybe dm_pci_mem_to_phys() returned 0 for whatever
reason, but I don't remember.  The address is 32-bit, 0xf600,
so it definitely wasn't the 64-bit think I rambled about.  Sorry.

I will try to find out what was wrong and report back.

By the way, the debug() line in the current code prints iobase which at
that time isn't even initialized.

Patrick
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] mx6sxsabresd: imximage.cfg: Handle the CONFIG_SECURE_BOOT case

[Breno Matheus Lima]

Secure boot is not enabled in mx6sxsabresd imximage.cfg, add support
for it.

Signed-off-by: Breno Lima 
---
 board/freescale/mx6sxsabresd/imximage.cfg | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/board/freescale/mx6sxsabresd/imximage.cfg 
b/board/freescale/mx6sxsabresd/imximage.cfg
index 3e94f6ab66..0354bb36e2 100644
--- a/board/freescale/mx6sxsabresd/imximage.cfg
+++ b/board/freescale/mx6sxsabresd/imximage.cfg
@@ -17,6 +17,13 @@ IMAGE_VERSION 2
 
 BOOT_FROM  sd
 
+/*
+ * Secure boot support
+ */
+#ifdef CONFIG_SECURE_BOOT
+CSF CONFIG_CSF_SIZE
+#endif
+
 /*
  * Device Configuration Data (DCD)
  *
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: provide default SPL_SIZE_LIMIT for gen5

[Marek Vasut]

On 6/13/19 11:00 PM, Simon Goldschmidt wrote:
> 
> 
> Marek Vasut mailto:ma...@denx.de>> schrieb am Do., 13.
> Juni 2019, 22:56:
> 
> On 6/13/19 10:55 PM, Simon Goldschmidt wrote:
> >
> >
> > Marek Vasut mailto:ma...@denx.de>
> >> schrieb am Do., 13.
> > Juni 2019, 22:40:
> >
> >     On 6/13/19 10:26 PM, Simon Goldschmidt wrote:
> >     >
> >     >
> >     > On 13.06.19 22:14, Marek Vasut wrote:
> >     >> On 6/13/19 9:50 PM, Simon Goldschmidt wrote:
> >     >>> This provides an SPL_SIZE_LIMIT that makes the build check
> that
> >     the SPL
> >     >>> binary loaded from flash fits into the SRAM (64 KiB) and
> leaves
> >     enough
> >     >>> room for global data, heap  and stack (512 bytes assumed stack
> >     usage).
> >     >>>
> >     >>> Signed-off-by: Simon Goldschmidt
> >      
> >      >>
> >     >>> ---
> >     >>>
> >     >>>   arch/arm/mach-socfpga/Kconfig | 8 
> >     >>>   1 file changed, 8 insertions(+)
> >     >>>
> >     >>> diff --git a/arch/arm/mach-socfpga/Kconfig
> >     >>> b/arch/arm/mach-socfpga/Kconfig
> >     >>> index 48f02f08d4..1d914648e3 100644
> >     >>> --- a/arch/arm/mach-socfpga/Kconfig
> >     >>> +++ b/arch/arm/mach-socfpga/Kconfig
> >     >>> @@ -3,6 +3,12 @@ if ARCH_SOCFPGA
> >     >>>   config NR_DRAM_BANKS
> >     >>>   default 1
> >     >>>   +config SPL_SIZE_LIMIT
> >     >>> +    default 65536 if TARGET_SOCFPGA_GEN5
> >     >>> +
> >     >>> +config SPL_SIZE_LIMIT_PROVIDE_STACK
> >     >>> +    default 0x200 if TARGET_SOCFPGA_GEN5
> >     >>> +
> >     >>>   config SPL_STACK_R_ADDR
> >     >>>   default 0x0080 if TARGET_SOCFPGA_GEN5
> >     >>>   @@ -49,6 +55,8 @@ config TARGET_SOCFPGA_GEN5
> >     >>>   bool
> >     >>>   select SPL_ALTERA_SDRAM
> >     >>>   imply FPGA_SOCFPGA
> >     >>> +    imply SPL_SIZE_LIMIT_SUBTRACT_GD
> >     >>> +    imply SPL_SIZE_LIMIT_SUBTRACT_MALLOC
> >     >>>   imply SPL_STACK_R
> >     >>>   imply SPL_SYS_MALLOC_SIMPLE
> >     >>>   imply USE_TINY_PRINTF
> >     >>>
> >     >> 512 bytes for stack looks like it's too little. I think the SPL
> >     started
> >     >> misbehaving when it overgrew 50 kiB, no ?
> >     >
> >     > To 1: Well, I tested the stack usage once, booting from
> eMMC, and was
> >     > somewhere below that range. But yes, it's a problem for the
> >     future: once
> >     > we get a more stack-consuming function, we might be lost.
> Which size
> >     > would you suggest?
> >
> >     Hmmm, now that I think about it, the stack gets relocated to
> DRAM quite
> >     early too, right ? So maybe we really don't need that much
> space for
> >     stack.
> >
> >
> > Exactly. The only stack-consuming things before relocation are dts
> > parsing and maybe the ddr driver. I implemented a stack usage check by
> > filling the memory with 0xaa and checking it afterwards and if I
> > remember correctly it resulted in about 400 bytes. It's even more or
> > less independent of the boot type since the ski/mmc drivers are probed
> > only after DDR is up. Same goes for file systems.
> >
> > Nevertheless, stack usage can increase in the future. That's why
> I'm not
> > too happy about this constant. Otoh, DM_CLK makes me need every
> byte and
> > right now I don't see how I can enable secure boot (fit signature
> check)
> > due to this size limit...
> 
> Maybe before we add more bloat, we should consider how to trim the bloat
> down first ?
> 
> 
> One of the reasons why I haven't sent the clk driver patches yet.
> 
> Anyway, I'll be off for at least a week now, I just wanted to get this
> one in before the release.

So is 0x200 bytes for stack before SPL relocs the stack enough ?

> I hope I'll be working on SPL size after that... 64 KiB not being enough
> is just ridicculous...

Agreed

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: provide default SPL_SIZE_LIMIT for gen5

[Simon Goldschmidt]

Marek Vasut  schrieb am Do., 13. Juni 2019, 22:56:

> On 6/13/19 10:55 PM, Simon Goldschmidt wrote:
> >
> >
> > Marek Vasut mailto:ma...@denx.de>> schrieb am Do., 13.
> > Juni 2019, 22:40:
> >
> > On 6/13/19 10:26 PM, Simon Goldschmidt wrote:
> > >
> > >
> > > On 13.06.19 22:14, Marek Vasut wrote:
> > >> On 6/13/19 9:50 PM, Simon Goldschmidt wrote:
> > >>> This provides an SPL_SIZE_LIMIT that makes the build check that
> > the SPL
> > >>> binary loaded from flash fits into the SRAM (64 KiB) and leaves
> > enough
> > >>> room for global data, heap  and stack (512 bytes assumed stack
> > usage).
> > >>>
> > >>> Signed-off-by: Simon Goldschmidt
> >  > >
> > >>> ---
> > >>>
> > >>>   arch/arm/mach-socfpga/Kconfig | 8 
> > >>>   1 file changed, 8 insertions(+)
> > >>>
> > >>> diff --git a/arch/arm/mach-socfpga/Kconfig
> > >>> b/arch/arm/mach-socfpga/Kconfig
> > >>> index 48f02f08d4..1d914648e3 100644
> > >>> --- a/arch/arm/mach-socfpga/Kconfig
> > >>> +++ b/arch/arm/mach-socfpga/Kconfig
> > >>> @@ -3,6 +3,12 @@ if ARCH_SOCFPGA
> > >>>   config NR_DRAM_BANKS
> > >>>   default 1
> > >>>   +config SPL_SIZE_LIMIT
> > >>> +default 65536 if TARGET_SOCFPGA_GEN5
> > >>> +
> > >>> +config SPL_SIZE_LIMIT_PROVIDE_STACK
> > >>> +default 0x200 if TARGET_SOCFPGA_GEN5
> > >>> +
> > >>>   config SPL_STACK_R_ADDR
> > >>>   default 0x0080 if TARGET_SOCFPGA_GEN5
> > >>>   @@ -49,6 +55,8 @@ config TARGET_SOCFPGA_GEN5
> > >>>   bool
> > >>>   select SPL_ALTERA_SDRAM
> > >>>   imply FPGA_SOCFPGA
> > >>> +imply SPL_SIZE_LIMIT_SUBTRACT_GD
> > >>> +imply SPL_SIZE_LIMIT_SUBTRACT_MALLOC
> > >>>   imply SPL_STACK_R
> > >>>   imply SPL_SYS_MALLOC_SIMPLE
> > >>>   imply USE_TINY_PRINTF
> > >>>
> > >> 512 bytes for stack looks like it's too little. I think the SPL
> > started
> > >> misbehaving when it overgrew 50 kiB, no ?
> > >
> > > To 1: Well, I tested the stack usage once, booting from eMMC, and
> was
> > > somewhere below that range. But yes, it's a problem for the
> > future: once
> > > we get a more stack-consuming function, we might be lost. Which
> size
> > > would you suggest?
> >
> > Hmmm, now that I think about it, the stack gets relocated to DRAM
> quite
> > early too, right ? So maybe we really don't need that much space for
> > stack.
> >
> >
> > Exactly. The only stack-consuming things before relocation are dts
> > parsing and maybe the ddr driver. I implemented a stack usage check by
> > filling the memory with 0xaa and checking it afterwards and if I
> > remember correctly it resulted in about 400 bytes. It's even more or
> > less independent of the boot type since the ski/mmc drivers are probed
> > only after DDR is up. Same goes for file systems.
> >
> > Nevertheless, stack usage can increase in the future. That's why I'm not
> > too happy about this constant. Otoh, DM_CLK makes me need every byte and
> > right now I don't see how I can enable secure boot (fit signature check)
> > due to this size limit...
>
> Maybe before we add more bloat, we should consider how to trim the bloat
> down first ?
>

One of the reasons why I haven't sent the clk driver patches yet.

Anyway, I'll be off for at least a week now, I just wanted to get this one
in before the release.

I hope I'll be working on SPL size after that... 64 KiB not being enough is
just ridicculous...

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: provide default SPL_SIZE_LIMIT for gen5

[Marek Vasut]

On 6/13/19 10:55 PM, Simon Goldschmidt wrote:
> 
> 
> Marek Vasut mailto:ma...@denx.de>> schrieb am Do., 13.
> Juni 2019, 22:40:
> 
> On 6/13/19 10:26 PM, Simon Goldschmidt wrote:
> >
> >
> > On 13.06.19 22:14, Marek Vasut wrote:
> >> On 6/13/19 9:50 PM, Simon Goldschmidt wrote:
> >>> This provides an SPL_SIZE_LIMIT that makes the build check that
> the SPL
> >>> binary loaded from flash fits into the SRAM (64 KiB) and leaves
> enough
> >>> room for global data, heap  and stack (512 bytes assumed stack
> usage).
> >>>
> >>> Signed-off-by: Simon Goldschmidt
>  >
> >>> ---
> >>>
> >>>   arch/arm/mach-socfpga/Kconfig | 8 
> >>>   1 file changed, 8 insertions(+)
> >>>
> >>> diff --git a/arch/arm/mach-socfpga/Kconfig
> >>> b/arch/arm/mach-socfpga/Kconfig
> >>> index 48f02f08d4..1d914648e3 100644
> >>> --- a/arch/arm/mach-socfpga/Kconfig
> >>> +++ b/arch/arm/mach-socfpga/Kconfig
> >>> @@ -3,6 +3,12 @@ if ARCH_SOCFPGA
> >>>   config NR_DRAM_BANKS
> >>>   default 1
> >>>   +config SPL_SIZE_LIMIT
> >>> +    default 65536 if TARGET_SOCFPGA_GEN5
> >>> +
> >>> +config SPL_SIZE_LIMIT_PROVIDE_STACK
> >>> +    default 0x200 if TARGET_SOCFPGA_GEN5
> >>> +
> >>>   config SPL_STACK_R_ADDR
> >>>   default 0x0080 if TARGET_SOCFPGA_GEN5
> >>>   @@ -49,6 +55,8 @@ config TARGET_SOCFPGA_GEN5
> >>>   bool
> >>>   select SPL_ALTERA_SDRAM
> >>>   imply FPGA_SOCFPGA
> >>> +    imply SPL_SIZE_LIMIT_SUBTRACT_GD
> >>> +    imply SPL_SIZE_LIMIT_SUBTRACT_MALLOC
> >>>   imply SPL_STACK_R
> >>>   imply SPL_SYS_MALLOC_SIMPLE
> >>>   imply USE_TINY_PRINTF
> >>>
> >> 512 bytes for stack looks like it's too little. I think the SPL
> started
> >> misbehaving when it overgrew 50 kiB, no ?
> >
> > To 1: Well, I tested the stack usage once, booting from eMMC, and was
> > somewhere below that range. But yes, it's a problem for the
> future: once
> > we get a more stack-consuming function, we might be lost. Which size
> > would you suggest?
> 
> Hmmm, now that I think about it, the stack gets relocated to DRAM quite
> early too, right ? So maybe we really don't need that much space for
> stack.
> 
> 
> Exactly. The only stack-consuming things before relocation are dts
> parsing and maybe the ddr driver. I implemented a stack usage check by
> filling the memory with 0xaa and checking it afterwards and if I
> remember correctly it resulted in about 400 bytes. It's even more or
> less independent of the boot type since the ski/mmc drivers are probed
> only after DDR is up. Same goes for file systems.
> 
> Nevertheless, stack usage can increase in the future. That's why I'm not
> too happy about this constant. Otoh, DM_CLK makes me need every byte and
> right now I don't see how I can enable secure boot (fit signature check)
> due to this size limit...

Maybe before we add more bloat, we should consider how to trim the bloat
down first ?

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: provide default SPL_SIZE_LIMIT for gen5

[Simon Goldschmidt]

Marek Vasut  schrieb am Do., 13. Juni 2019, 22:40:

> On 6/13/19 10:26 PM, Simon Goldschmidt wrote:
> >
> >
> > On 13.06.19 22:14, Marek Vasut wrote:
> >> On 6/13/19 9:50 PM, Simon Goldschmidt wrote:
> >>> This provides an SPL_SIZE_LIMIT that makes the build check that the SPL
> >>> binary loaded from flash fits into the SRAM (64 KiB) and leaves enough
> >>> room for global data, heap  and stack (512 bytes assumed stack usage).
> >>>
> >>> Signed-off-by: Simon Goldschmidt 
> >>> ---
> >>>
> >>>   arch/arm/mach-socfpga/Kconfig | 8 
> >>>   1 file changed, 8 insertions(+)
> >>>
> >>> diff --git a/arch/arm/mach-socfpga/Kconfig
> >>> b/arch/arm/mach-socfpga/Kconfig
> >>> index 48f02f08d4..1d914648e3 100644
> >>> --- a/arch/arm/mach-socfpga/Kconfig
> >>> +++ b/arch/arm/mach-socfpga/Kconfig
> >>> @@ -3,6 +3,12 @@ if ARCH_SOCFPGA
> >>>   config NR_DRAM_BANKS
> >>>   default 1
> >>>   +config SPL_SIZE_LIMIT
> >>> +default 65536 if TARGET_SOCFPGA_GEN5
> >>> +
> >>> +config SPL_SIZE_LIMIT_PROVIDE_STACK
> >>> +default 0x200 if TARGET_SOCFPGA_GEN5
> >>> +
> >>>   config SPL_STACK_R_ADDR
> >>>   default 0x0080 if TARGET_SOCFPGA_GEN5
> >>>   @@ -49,6 +55,8 @@ config TARGET_SOCFPGA_GEN5
> >>>   bool
> >>>   select SPL_ALTERA_SDRAM
> >>>   imply FPGA_SOCFPGA
> >>> +imply SPL_SIZE_LIMIT_SUBTRACT_GD
> >>> +imply SPL_SIZE_LIMIT_SUBTRACT_MALLOC
> >>>   imply SPL_STACK_R
> >>>   imply SPL_SYS_MALLOC_SIMPLE
> >>>   imply USE_TINY_PRINTF
> >>>
> >> 512 bytes for stack looks like it's too little. I think the SPL started
> >> misbehaving when it overgrew 50 kiB, no ?
> >
> > To 1: Well, I tested the stack usage once, booting from eMMC, and was
> > somewhere below that range. But yes, it's a problem for the future: once
> > we get a more stack-consuming function, we might be lost. Which size
> > would you suggest?
>
> Hmmm, now that I think about it, the stack gets relocated to DRAM quite
> early too, right ? So maybe we really don't need that much space for stack.
>

Exactly. The only stack-consuming things before relocation are dts parsing
and maybe the ddr driver. I implemented a stack usage check by filling the
memory with 0xaa and checking it afterwards and if I remember correctly it
resulted in about 400 bytes. It's even more or less independent of the boot
type since the ski/mmc drivers are probed only after DDR is up. Same goes
for file systems.

Nevertheless, stack usage can increase in the future. That's why I'm not
too happy about this constant. Otoh, DM_CLK makes me need every byte and
right now I don't see how I can enable secure boot (fit signature check)
due to this size limit...

Regards,
Simon


> > To 2: No. The documentation says 60 KiB would be the limit (upper 4 KiB
> > reserved for BootRom usage while loading SPL). I'm running SPL with the
> > DM_CLK driver (still under development) with a binary (code + dtb) of
> > about 58 KiB and it runs fine. Heap size before relocation increases to
> > around 4KiB though, so that ensures the 60 KiB limit isn't breached.
>
> OK, thanks for checking.
>
> --
> Best regards,
> Marek Vasut
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: provide default SPL_SIZE_LIMIT for gen5

[Marek Vasut]

On 6/13/19 10:26 PM, Simon Goldschmidt wrote:
> 
> 
> On 13.06.19 22:14, Marek Vasut wrote:
>> On 6/13/19 9:50 PM, Simon Goldschmidt wrote:
>>> This provides an SPL_SIZE_LIMIT that makes the build check that the SPL
>>> binary loaded from flash fits into the SRAM (64 KiB) and leaves enough
>>> room for global data, heap  and stack (512 bytes assumed stack usage).
>>>
>>> Signed-off-by: Simon Goldschmidt 
>>> ---
>>>
>>>   arch/arm/mach-socfpga/Kconfig | 8 
>>>   1 file changed, 8 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-socfpga/Kconfig
>>> b/arch/arm/mach-socfpga/Kconfig
>>> index 48f02f08d4..1d914648e3 100644
>>> --- a/arch/arm/mach-socfpga/Kconfig
>>> +++ b/arch/arm/mach-socfpga/Kconfig
>>> @@ -3,6 +3,12 @@ if ARCH_SOCFPGA
>>>   config NR_DRAM_BANKS
>>>   default 1
>>>   +config SPL_SIZE_LIMIT
>>> +    default 65536 if TARGET_SOCFPGA_GEN5
>>> +
>>> +config SPL_SIZE_LIMIT_PROVIDE_STACK
>>> +    default 0x200 if TARGET_SOCFPGA_GEN5
>>> +
>>>   config SPL_STACK_R_ADDR
>>>   default 0x0080 if TARGET_SOCFPGA_GEN5
>>>   @@ -49,6 +55,8 @@ config TARGET_SOCFPGA_GEN5
>>>   bool
>>>   select SPL_ALTERA_SDRAM
>>>   imply FPGA_SOCFPGA
>>> +    imply SPL_SIZE_LIMIT_SUBTRACT_GD
>>> +    imply SPL_SIZE_LIMIT_SUBTRACT_MALLOC
>>>   imply SPL_STACK_R
>>>   imply SPL_SYS_MALLOC_SIMPLE
>>>   imply USE_TINY_PRINTF
>>>
>> 512 bytes for stack looks like it's too little. I think the SPL started
>> misbehaving when it overgrew 50 kiB, no ?
> 
> To 1: Well, I tested the stack usage once, booting from eMMC, and was
> somewhere below that range. But yes, it's a problem for the future: once
> we get a more stack-consuming function, we might be lost. Which size
> would you suggest?

Hmmm, now that I think about it, the stack gets relocated to DRAM quite
early too, right ? So maybe we really don't need that much space for stack.

> To 2: No. The documentation says 60 KiB would be the limit (upper 4 KiB
> reserved for BootRom usage while loading SPL). I'm running SPL with the
> DM_CLK driver (still under development) with a binary (code + dtb) of
> about 58 KiB and it runs fine. Heap size before relocation increases to
> around 4KiB though, so that ensures the 60 KiB limit isn't breached.

OK, thanks for checking.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: provide default SPL_SIZE_LIMIT for gen5

[Simon Goldschmidt]

On 13.06.19 22:14, Marek Vasut wrote:

On 6/13/19 9:50 PM, Simon Goldschmidt wrote:

This provides an SPL_SIZE_LIMIT that makes the build check that the SPL
binary loaded from flash fits into the SRAM (64 KiB) and leaves enough
room for global data, heap  and stack (512 bytes assumed stack usage).

Signed-off-by: Simon Goldschmidt 
---

  arch/arm/mach-socfpga/Kconfig | 8 
  1 file changed, 8 insertions(+)

diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index 48f02f08d4..1d914648e3 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -3,6 +3,12 @@ if ARCH_SOCFPGA
  config NR_DRAM_BANKS
default 1
  
+config SPL_SIZE_LIMIT

+   default 65536 if TARGET_SOCFPGA_GEN5
+
+config SPL_SIZE_LIMIT_PROVIDE_STACK
+   default 0x200 if TARGET_SOCFPGA_GEN5
+
  config SPL_STACK_R_ADDR
default 0x0080 if TARGET_SOCFPGA_GEN5
  
@@ -49,6 +55,8 @@ config TARGET_SOCFPGA_GEN5

bool
select SPL_ALTERA_SDRAM
imply FPGA_SOCFPGA
+   imply SPL_SIZE_LIMIT_SUBTRACT_GD
+   imply SPL_SIZE_LIMIT_SUBTRACT_MALLOC
imply SPL_STACK_R
imply SPL_SYS_MALLOC_SIMPLE
imply USE_TINY_PRINTF


512 bytes for stack looks like it's too little. I think the SPL started
misbehaving when it overgrew 50 kiB, no ?


To 1: Well, I tested the stack usage once, booting from eMMC, and was 
somewhere below that range. But yes, it's a problem for the future: once 
we get a more stack-consuming function, we might be lost. Which size 
would you suggest?


To 2: No. The documentation says 60 KiB would be the limit (upper 4 KiB 
reserved for BootRom usage while loading SPL). I'm running SPL with the 
DM_CLK driver (still under development) with a binary (code + dtb) of 
about 58 KiB and it runs fine. Heap size before relocation increases to 
around 4KiB though, so that ensures the 60 KiB limit isn't breached.


Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: provide default SPL_SIZE_LIMIT for gen5

[Marek Vasut]

On 6/13/19 9:50 PM, Simon Goldschmidt wrote:
> This provides an SPL_SIZE_LIMIT that makes the build check that the SPL
> binary loaded from flash fits into the SRAM (64 KiB) and leaves enough
> room for global data, heap  and stack (512 bytes assumed stack usage).
> 
> Signed-off-by: Simon Goldschmidt 
> ---
> 
>  arch/arm/mach-socfpga/Kconfig | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
> index 48f02f08d4..1d914648e3 100644
> --- a/arch/arm/mach-socfpga/Kconfig
> +++ b/arch/arm/mach-socfpga/Kconfig
> @@ -3,6 +3,12 @@ if ARCH_SOCFPGA
>  config NR_DRAM_BANKS
>   default 1
>  
> +config SPL_SIZE_LIMIT
> + default 65536 if TARGET_SOCFPGA_GEN5
> +
> +config SPL_SIZE_LIMIT_PROVIDE_STACK
> + default 0x200 if TARGET_SOCFPGA_GEN5
> +
>  config SPL_STACK_R_ADDR
>   default 0x0080 if TARGET_SOCFPGA_GEN5
>  
> @@ -49,6 +55,8 @@ config TARGET_SOCFPGA_GEN5
>   bool
>   select SPL_ALTERA_SDRAM
>   imply FPGA_SOCFPGA
> + imply SPL_SIZE_LIMIT_SUBTRACT_GD
> + imply SPL_SIZE_LIMIT_SUBTRACT_MALLOC
>   imply SPL_STACK_R
>   imply SPL_SYS_MALLOC_SIMPLE
>   imply USE_TINY_PRINTF
> 
512 bytes for stack looks like it's too little. I think the SPL started
misbehaving when it overgrew 50 kiB, no ?

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] arm: socfpga: provide default SPL_SIZE_LIMIT for gen5

[Simon Goldschmidt]

This provides an SPL_SIZE_LIMIT that makes the build check that the SPL
binary loaded from flash fits into the SRAM (64 KiB) and leaves enough
room for global data, heap  and stack (512 bytes assumed stack usage).

Signed-off-by: Simon Goldschmidt 
---

 arch/arm/mach-socfpga/Kconfig | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index 48f02f08d4..1d914648e3 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -3,6 +3,12 @@ if ARCH_SOCFPGA
 config NR_DRAM_BANKS
default 1
 
+config SPL_SIZE_LIMIT
+   default 65536 if TARGET_SOCFPGA_GEN5
+
+config SPL_SIZE_LIMIT_PROVIDE_STACK
+   default 0x200 if TARGET_SOCFPGA_GEN5
+
 config SPL_STACK_R_ADDR
default 0x0080 if TARGET_SOCFPGA_GEN5
 
@@ -49,6 +55,8 @@ config TARGET_SOCFPGA_GEN5
bool
select SPL_ALTERA_SDRAM
imply FPGA_SOCFPGA
+   imply SPL_SIZE_LIMIT_SUBTRACT_GD
+   imply SPL_SIZE_LIMIT_SUBTRACT_MALLOC
imply SPL_STACK_R
imply SPL_SYS_MALLOC_SIMPLE
imply USE_TINY_PRINTF
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/3] fastboot: Check if partition really exist in getvar_has_slot()

[Sam Protsenko]

Lukasz, Eugeniu,

Just sent v3 where build is fixed. Please review and merge, if applicable.

Thanks!

On Thu, Jun 13, 2019 at 3:01 PM Lukasz Majewski  wrote:
>
> On Thu, 13 Jun 2019 07:47:19 +0200
> Lukasz Majewski  wrote:
>
> > Hi Sam,
> >
> > > Hi Tom,
> > >
> > > We have broken fastboot right now... Can we please apply this
> > > series, so that it appears in v2019.07?
> >
> > I'm running Travis-CI on this series, and send PR to Marek when it
> > finish.
>
> Unfortunately, there are several build breaks:
> https://travis-ci.org/lmajewski/u-boot-dfu/jobs/545073270
>
> Please fix them before sending v3.
>
> Thanks in advance,
>
> >
> > Thanks for fixing fastboot.
> >
> > >
> > > Thanks!
> > >
> > > On Thu, Jun 13, 2019 at 12:14 AM Sam Protsenko
> > >  wrote:
> > > >
> > > > From: Igor Opaniuk 
> > > >
> > > > Currently getvar_has_slot() invocation for "boot" and "system"
> > > > partitions always returns affirmative response regardless the fact
> > > > of existence of these partitions, which leads to impossibility to
> > > > flash them on old non-A/B AOSP setups, where _a/_b suffixes aren't
> > > > used:
> > > >
> > > > $ fastboot flash boot boot.img
> > > > Sending 'boot__a' (11301 KB)OKAY [  0.451s]
> > > > Writing 'boot__a'   FAILED (remote: 'cannot find
> > > > partition') fastboot: error: Command failed
> > > >
> > > > Although partition layout is:
> > > > -> part list mmc 0
> > > > Partition Map for MMC device 0  --   Partition Type: EFI
> > > >
> > > > PartStart LBA   End LBA Name
> > > > Attributes
> > > > Type GUID
> > > > Partition GUID
> > > >   1 0x0800  0x000107ff  "boot"
> > > > attrs:  0x
> > > > type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
> > > > guid:   ea2e2470-db4a-d646-b828-10167f736d63
> > > >   2 0x00010800  0x000127ff  "environment"
> > > > attrs:  0x
> > > > type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
> > > > guid:   10a819d2-6004-3d48-bd87-114e2a796db9
> > > >   3 0x00012800  0x0001a7ff  "recovery"
> > > > attrs:  0x
> > > > type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
> > > > guid:   9ea116e4-8a34-0c48-8cf5-2fe9480f56cd
> > > >   4 0x0001a800  0x0031a7ff  "system"
> > > > attrs:  0x
> > > > ..
> > > >
> > > > This patch adds checks of existence for requested partitions
> > > > on eMMC/NAND.
> > > >
> > > > Signed-off-by: Igor Opaniuk 
> > > > Signed-off-by: Sam Protsenko 
> > > > ---
> > > >  drivers/fastboot/fb_getvar.c | 26 ++
> > > >  1 file changed, 22 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/fastboot/fb_getvar.c
> > > > b/drivers/fastboot/fb_getvar.c index b23880089e..563bda0088 100644
> > > > --- a/drivers/fastboot/fb_getvar.c
> > > > +++ b/drivers/fastboot/fb_getvar.c
> > > > @@ -179,11 +179,29 @@ static void getvar_slot_suffixes(char
> > > > *var_parameter, char *response)
> > > >
> > > >  static void getvar_has_slot(char *part_name, char *response)
> > > >  {
> > > > -   if (part_name && (!strcmp(part_name, "boot") ||
> > > > - !strcmp(part_name, "system")))
> > > > +   char part_name_wslot[PART_NAME_LEN];
> > > > +   size_t len;
> > > > +   int r;
> > > > +
> > > > +   if (!part_name)
> > > > +   goto no;
> > > > +
> > > > +   /* Append "_a" prefix to part_name */
> > > > +   len = strlcpy(part_name_wslot, part_name, PART_NAME_LEN -
> > > > 3);
> > > > +   if (len > PART_NAME_LEN - 3) {
> > > > +   fastboot_fail("too long partition name",
> > > > response);
> > > > +   return;
> > > > +   }
> > > > +   strcat(part_name_wslot, "_a");
> > > > +
> > > > +   /* Check if this partition exists */
> > > > +   r = getvar_get_part_info(part_name_wslot, response, NULL);
> > > > +   if (r >= 0) {
> > > > fastboot_okay("yes", response);
> > > > -   else
> > > > -   fastboot_okay("no", response);
> > > > +   return;
> > > > +   }
> > > > +no:
> > > > +   fastboot_okay("no", response);
> > > >  }
> > > >
> > > >  #if CONFIG_IS_ENABLED(FASTBOOT_FLASH_MMC)
> > > > --
> > > > 2.20.1
> > > >
> > > ___
> > > U-Boot mailing list
> > > U-Boot@lists.denx.de
> > > https://lists.denx.de/listinfo/u-boot
> >
> >
> >
> >
> > Best regards,
> >
> > Lukasz Majewski
> >
> > --
> >
> > DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> > Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> > lu...@denx.de
>
>
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, 

[U-Boot] [PATCH v3 3/3] fastboot: Check if partition really exist in getvar_has_slot()

[Sam Protsenko]

From: Igor Opaniuk 

Currently getvar_has_slot() invocation for "boot" and "system"
partitions always returns affirmative response regardless the fact of
existence of these partitions, which leads to impossibility to flash them
on old non-A/B AOSP setups, where _a/_b suffixes aren't used:

$ fastboot flash boot boot.img
Sending 'boot__a' (11301 KB)OKAY [  0.451s]
Writing 'boot__a'   FAILED (remote: 'cannot find partition')
fastboot: error: Command failed

Although partition layout is:
-> part list mmc 0
Partition Map for MMC device 0  --   Partition Type: EFI

PartStart LBA   End LBA Name
Attributes
Type GUID
Partition GUID
  1 0x0800  0x000107ff  "boot"
attrs:  0x
type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
guid:   ea2e2470-db4a-d646-b828-10167f736d63
  2 0x00010800  0x000127ff  "environment"
attrs:  0x
type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
guid:   10a819d2-6004-3d48-bd87-114e2a796db9
  3 0x00012800  0x0001a7ff  "recovery"
attrs:  0x
type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
guid:   9ea116e4-8a34-0c48-8cf5-2fe9480f56cd
  4 0x0001a800  0x0031a7ff  "system"
attrs:  0x
..

This patch adds checks of existence for requested partitions
on eMMC/NAND.

Fixes: f73a7df984a9 ("net: fastboot: Merge AOSP UDP fastboot")
Signed-off-by: Igor Opaniuk 
Signed-off-by: Sam Protsenko 
---
Changes in v3:
  - fix build on platforms where CONFIG_FASTBOOT is enabled but
CONFIG_FASTBOOT_FLASH is not
  - fix "no" response logic: "no" should be only reported when partition
exists, but not slotted
Changes in v2:
  - extract common code into getvar_get_part_info() (done in previous
patch)
  - use more secure strlcpy()

 drivers/fastboot/fb_getvar.c | 39 +++-
 1 file changed, 34 insertions(+), 5 deletions(-)

diff --git a/drivers/fastboot/fb_getvar.c b/drivers/fastboot/fb_getvar.c
index 4aa2f88ece..584c7f0263 100644
--- a/drivers/fastboot/fb_getvar.c
+++ b/drivers/fastboot/fb_getvar.c
@@ -20,7 +20,9 @@ static void getvar_product(char *var_parameter, char 
*response);
 static void getvar_platform(char *var_parameter, char *response);
 static void getvar_current_slot(char *var_parameter, char *response);
 static void getvar_slot_suffixes(char *var_parameter, char *response);
+#if CONFIG_IS_ENABLED(FASTBOOT_FLASH)
 static void getvar_has_slot(char *var_parameter, char *response);
+#endif
 #if CONFIG_IS_ENABLED(FASTBOOT_FLASH_MMC)
 static void getvar_partition_type(char *part_name, char *response);
 #endif
@@ -65,9 +67,11 @@ static const struct {
}, {
.variable = "slot-suffixes",
.dispatch = getvar_slot_suffixes
+#if CONFIG_IS_ENABLED(FASTBOOT_FLASH)
}, {
.variable = "has-slot",
.dispatch = getvar_has_slot
+#endif
 #if CONFIG_IS_ENABLED(FASTBOOT_FLASH_MMC)
}, {
.variable = "partition-type",
@@ -183,14 +187,39 @@ static void getvar_slot_suffixes(char *var_parameter, 
char *response)
fastboot_okay("_a,_b", response);
 }
 
+#if CONFIG_IS_ENABLED(FASTBOOT_FLASH)
 static void getvar_has_slot(char *part_name, char *response)
 {
-   if (part_name && (!strcmp(part_name, "boot") ||
- !strcmp(part_name, "system")))
-   fastboot_okay("yes", response);
-   else
-   fastboot_okay("no", response);
+   char part_name_wslot[PART_NAME_LEN];
+   size_t len;
+   int r;
+
+   if (!part_name || part_name[0] == '\0')
+   goto fail;
+
+   /* part_name_wslot = part_name + "_a" */
+   len = strlcpy(part_name_wslot, part_name, PART_NAME_LEN - 3);
+   if (len > PART_NAME_LEN - 3)
+   goto fail;
+   strcat(part_name_wslot, "_a");
+
+   r = getvar_get_part_info(part_name_wslot, response, NULL);
+   if (r >= 0) {
+   fastboot_okay("yes", response); /* part exists and slotted */
+   return;
+   }
+
+   r = getvar_get_part_info(part_name, response, NULL);
+   if (r >= 0)
+   fastboot_okay("no", response); /* part exists but not slotted */
+
+   /* At this point response is filled with okay or fail string */
+   return;
+
+fail:
+   fastboot_fail("invalid partition name", response);
 }
+#endif
 
 #if CONFIG_IS_ENABLED(FASTBOOT_FLASH_MMC)
 static void getvar_partition_type(char *part_name, char *response)
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 2/3] fastboot: getvar: Refactor fastboot_*_get_part_info() usage

[Sam Protsenko]

Extract fastboot_*_get_part_info() usage for MMC and NAND into
getvar_get_part_info() function, as it will be needed further in other
functions. This way we can avoid code duplication and mess with
preprocessor directives across all points of usage.

Signed-off-by: Sam Protsenko 
Reviewed-by: Lukasz Majewski 
Reviewed-by: Igor Opaniuk 
---
Changes in v3:
  - improve comments
  - fill response with fail string for unknown storage types
Changes in v2:
  - add this patch to series

 drivers/fastboot/fb_getvar.c | 58 ++--
 1 file changed, 42 insertions(+), 16 deletions(-)

diff --git a/drivers/fastboot/fb_getvar.c b/drivers/fastboot/fb_getvar.c
index 4268628f5e..4aa2f88ece 100644
--- a/drivers/fastboot/fb_getvar.c
+++ b/drivers/fastboot/fb_getvar.c
@@ -81,6 +81,47 @@ static const struct {
}
 };
 
+#if CONFIG_IS_ENABLED(FASTBOOT_FLASH)
+/**
+ * Get partition number and size for any storage type.
+ *
+ * Can be used to check if partition with specified name exists.
+ *
+ * If error occurs, this function guarantees to fill @p response with fail
+ * string. @p response can be rewritten in caller, if needed.
+ *
+ * @param[in] part_name Info for which partition name to look for
+ * @param[in,out] response Pointer to fastboot response buffer
+ * @param[out] size If not NULL, will contain partition size (in blocks)
+ * @return Partition number or negative value on error
+ */
+static int getvar_get_part_info(const char *part_name, char *response,
+   size_t *size)
+{
+   int r;
+# if CONFIG_IS_ENABLED(FASTBOOT_FLASH_MMC)
+   struct blk_desc *dev_desc;
+   disk_partition_t part_info;
+
+   r = fastboot_mmc_get_part_info(part_name, _desc, _info,
+  response);
+   if (r >= 0 && size)
+   *size = part_info.size;
+# elif CONFIG_IS_ENABLED(FASTBOOT_FLASH_NAND)
+   struct part_info *part_info;
+
+   r = fastboot_nand_get_part_info(part_name, _info, response);
+   if (r >= 0 && size)
+   *size = part_info->size;
+# else
+   fastboot_fail("this storage is not supported in bootloader", response);
+   r = -ENODEV;
+# endif
+
+   return r;
+}
+#endif
+
 static void getvar_version(char *var_parameter, char *response)
 {
fastboot_okay(FASTBOOT_VERSION, response);
@@ -176,22 +217,7 @@ static void getvar_partition_size(char *part_name, char 
*response)
int r;
size_t size;
 
-#if CONFIG_IS_ENABLED(FASTBOOT_FLASH_MMC)
-   struct blk_desc *dev_desc;
-   disk_partition_t part_info;
-
-   r = fastboot_mmc_get_part_info(part_name, _desc, _info,
-  response);
-   if (r >= 0)
-   size = part_info.size;
-#endif
-#if CONFIG_IS_ENABLED(FASTBOOT_FLASH_NAND)
-   struct part_info *part_info;
-
-   r = fastboot_nand_get_part_info(part_name, _info, response);
-   if (r >= 0)
-   size = part_info->size;
-#endif
+   r = getvar_get_part_info(part_name, response, );
if (r >= 0)
fastboot_response("OKAY", response, "0x%016zx", size);
 }
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 1/3] fastboot: Use const qualifier for char *part_name

[Sam Protsenko]

In fastboot_*_get_part_info() functions we can use stronger typing by
expecting const strings.

Signed-off-by: Sam Protsenko 
Reviewed-by: Lukasz Majewski 
Reviewed-by: Igor Opaniuk 
---
Changes in v3: none
Changes in v2: add this patch to series

 drivers/fastboot/fb_mmc.c  | 3 ++-
 drivers/fastboot/fb_nand.c | 4 ++--
 include/fb_mmc.h   | 3 ++-
 include/fb_nand.h  | 4 ++--
 4 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/fastboot/fb_mmc.c b/drivers/fastboot/fb_mmc.c
index 90ca81da9b..0a335db3a6 100644
--- a/drivers/fastboot/fb_mmc.c
+++ b/drivers/fastboot/fb_mmc.c
@@ -298,7 +298,8 @@ static int fb_mmc_update_zimage(struct blk_desc *dev_desc,
  * @part_info: Pointer to returned disk_partition_t
  * @response: Pointer to fastboot response buffer
  */
-int fastboot_mmc_get_part_info(char *part_name, struct blk_desc **dev_desc,
+int fastboot_mmc_get_part_info(const char *part_name,
+  struct blk_desc **dev_desc,
   disk_partition_t *part_info, char *response)
 {
int r;
diff --git a/drivers/fastboot/fb_nand.c b/drivers/fastboot/fb_nand.c
index 526bc12307..6756ea769f 100644
--- a/drivers/fastboot/fb_nand.c
+++ b/drivers/fastboot/fb_nand.c
@@ -152,8 +152,8 @@ static lbaint_t fb_nand_sparse_reserve(struct 
sparse_storage *info,
  * @part_info: Pointer to returned part_info pointer
  * @response: Pointer to fastboot response buffer
  */
-int fastboot_nand_get_part_info(char *part_name, struct part_info **part_info,
-   char *response)
+int fastboot_nand_get_part_info(const char *part_name,
+   struct part_info **part_info, char *response)
 {
struct mtd_info *mtd = NULL;
 
diff --git a/include/fb_mmc.h b/include/fb_mmc.h
index fd5db9eac8..95db001bee 100644
--- a/include/fb_mmc.h
+++ b/include/fb_mmc.h
@@ -14,7 +14,8 @@
  * @part_info: Pointer to returned disk_partition_t
  * @response: Pointer to fastboot response buffer
  */
-int fastboot_mmc_get_part_info(char *part_name, struct blk_desc **dev_desc,
+int fastboot_mmc_get_part_info(const char *part_name,
+  struct blk_desc **dev_desc,
   disk_partition_t *part_info, char *response);
 
 /**
diff --git a/include/fb_nand.h b/include/fb_nand.h
index 08ab0e28a6..6d7999f262 100644
--- a/include/fb_nand.h
+++ b/include/fb_nand.h
@@ -16,8 +16,8 @@
  * @part_info: Pointer to returned part_info pointer
  * @response: Pointer to fastboot response buffer
  */
-int fastboot_nand_get_part_info(char *part_name, struct part_info **part_info,
-   char *response);
+int fastboot_nand_get_part_info(const char *part_name,
+   struct part_info **part_info, char *response);
 
 /**
  * fastboot_nand_flash_write() - Write image to NAND for fastboot
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 0/3] fastboot: Fix getvar "has-slot" and cleanup

[Sam Protsenko]

This patch series fixes "has-slot" fastboot variable and provides
associated refactoring, so that related code is not cluttered.

Changes in v3:
  - fix build on platforms where CONFIG_FASTBOOT defined but
CONFIG_FASTBOOT_FLASH is not defined
  - rework logic for "has-slot" variable (handle "no" case properly)

Igor Opaniuk (1):
  fastboot: Check if partition really exist in getvar_has_slot()

Sam Protsenko (2):
  fastboot: Use const qualifier for char *part_name
  fastboot: getvar: Refactor fastboot_*_get_part_info() usage

 drivers/fastboot/fb_getvar.c | 97 
 drivers/fastboot/fb_mmc.c|  3 +-
 drivers/fastboot/fb_nand.c   |  4 +-
 include/fb_mmc.h |  3 +-
 include/fb_nand.h|  4 +-
 5 files changed, 84 insertions(+), 27 deletions(-)

-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] fastboot: Fix slot names reported by getvar

[Eugeniu Rosca]

Hi Sam,

Thanks for the detailed answer. Some comments below.

On Thu, Jun 13, 2019 at 04:59:40PM +0300, Sam Protsenko wrote:
> Hi Eugeniu,
> 
> On Thu, Jun 13, 2019 at 12:31 PM Eugeniu Rosca  wrote:
> >
> > Hi Sam,
> >
> > On Thu, Jun 13, 2019 at 12:49:45AM +0300, Sam Protsenko wrote:
> > > In commit [1] fastboot tool was changed w.r.t. new A/B specification [2],
> > > and now we should report slot names in "a" format instead of "_a".
> > > Latter is now considered legacy and we shouldn't rely on that anymore.
> >
> > This looks like a change which advantages the users who are always on
> > the tip/HEAD of all relevant components (fastboot and U-Boot), but that
> > rarely happens in the industry. Suppliers and hardening vendors often
> > deliver obsoleted versions because they can't keep up with upstream
> > development. Can you please document the behavior of 'fastboot flash'
> > (and anything else relying on
> > 'fastboot getvar (current-slot|slot-suffixes) in below scenarios:
> >
> > A. fastboot >= [1] && U-Boot + this patch
> > B. fastboot >= [1] && U-Boot - this patch
> > C. fastboot <  [1] && U-Boot + this patch
> > D. fastboot <  [1] && U-Boot - this patch
> >
> > Would it be possible to keep U-Boot backward-compatible, such that
> > regardless of the scenario enumerated above, 'fastboot flash' will
> > always succeed?
> >
> 
> I'm afraid in this particular case we weren't given any choice, and we
> won't be able to provide backward-compatibility for older Android
> releases. After this commit:
> 
> [3] 
> https://android.googlesource.com/platform/system/core/+/42b18a518bac85c3eea14206f6cbafbd1e98a31f

Thumbs up for pointing out this specific commit.

> 
> they dropped support for "_a" format completely (in fastboot tool). So:
>   * if user runs new fastboot tool ( >= [3]), then the only way to
> make "fastboot flash" work is to return slot in "a" format from
> bootloader
>   * if user runs old fastboot tool (< [1]), then the only way to make
> "fastboot flash" work is to return slot in "_a" format from bootloader

This interface change seems to carry no semantic value, so it's
unfortunate to see such kind of non-backward-compatible update
contributed by the maintainers of the user-space tool.

> Good news is that user can basically downgrade or upgrade fastboot
> tool, to be in sync with U-Boot version in use. Bad news, we need to
> decide which Android version to break in U-Boot/master.
> 
> I suggest we track AOSP/master in U-Boot/master. Please let me know if
> you agree, or maybe there is some better way I'm missing.

I can't come up with a better proposal.

Reflecting on fastboot in general, I think there are many more
questions which lack a straightforward answer:
 - How accurately the fastboot protocol [4] reflects the AOSP
   user-space implementation (and viceversa)?
 - Some basic git grepping reveals that the fastboot protocol [4]
   was once upgraded from v0.3 to v0.4, but that's pretty much it. It
   definitely doesn't cover the evolution of fastboot usage/parameters.
   For example, none of the AB/slot-related parameters (e.g.
   "slot-suffixes", "current-slot") has ever been documented in [4].
 - Since the protocol and the actual development are out of sync,
   staying aligned to AOSP means asserting about the fastboot
   interface updates by reviewing the AOSP patches (which is time
   consuming and cannot be easily automated).
 - OTOH, it is also not clear to which degree U-Boot/master is aligned
   to AOSP/master even after integrating this patch. As example,
   commit [3] mentioned by you dropped the support for 'slot-suffixes'
   altogether while the option is still being processed in U-Boot.

In a nutshell, I think we have no other choice but to apply this fix
(still not clear if w/ or w/o keeping the support for "slot-suffixes").
I think it's also a must to warn the users that this patch
assumes/depends on AOSP fastboot version/commit [3] or higher.

> > > [1] 
> > > https://android.googlesource.com/platform/system/core/+/8091947847d5e5130b09d2ac0a4bdc900f3b77c5
> > > [2] https://source.android.com/devices/tech/ota/ab/ab_implement#partitions

[4] 
https://android.googlesource.com/platform/system/core/+/master/fastboot/README.md

-- 
Best Regards,
Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/1] efi_loader: GetTime() must return EFI_UNSUPPORTED

[Heinrich Schuchardt]

If the GetTime() runtime service is not supported, EFI_UNSUPPORTED has to
be returned.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_runtime.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 9ede42a728..bf730d0ff6 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -366,8 +366,7 @@ efi_status_t __weak __efi_runtime EFIAPI efi_get_time(
struct efi_time *time,
struct efi_time_cap *capabilities)
 {
-   /* Nothing we can do */
-   return EFI_DEVICE_ERROR;
+   return EFI_UNSUPPORTED;
 }

 /**
--
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 1/1] efi: add RuntimeServicesSupported variable

[Heinrich Schuchardt]

From: AKASHI Takahiro 

This variable is defined in UEFI specification 2.8, section 8.1.
Its value should be updated whenever we add any usable runtime services
function.

Currently we only support SetVirtualAddress() for all systems and
ResetSystem() for some.

Signed-off-by: AKASHI Takahiro 
Reviewed-by: Heinrich Schuchardt 
---
v2
Currently we only support SetVirtualAddress() for all systems and
ResetSystem() for some.
---
 include/efi_api.h| 15 +++
 include/efi_loader.h |  3 +++
 lib/efi_loader/efi_runtime.c | 24 
 lib/efi_loader/efi_setup.c   |  5 +
 4 files changed, 47 insertions(+)

diff --git a/include/efi_api.h b/include/efi_api.h
index 65584dd2d8..d7d95edd4d 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -213,6 +213,21 @@ struct efi_capsule_header {
u32 capsule_image_size;
 };

+#define EFI_RT_SUPPORTED_GET_TIME  0x0001
+#define EFI_RT_SUPPORTED_SET_TIME  0x0002
+#define EFI_RT_SUPPORTED_GET_WAKEUP_TIME   0x0004
+#define EFI_RT_SUPPORTED_SET_WAKEUP_TIME   0x0008
+#define EFI_RT_SUPPORTED_GET_VARIABLE  0x0010
+#define EFI_RT_SUPPORTED_GET_NEXT_VARIABLE_NAME0x0020
+#define EFI_RT_SUPPORTED_SET_VARIABLE  0x0040
+#define EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP   0x0080
+#define EFI_RT_SUPPORTED_CONVERT_POINTER   0x0100
+#define EFI_RT_SUPPORTED_GET_NEXT_HIGH_MONOTONIC_COUNT 0x0200
+#define EFI_RT_SUPPORTED_RESET_SYSTEM  0x0400
+#define EFI_RT_SUPPORTED_UPDATE_CAPSULE0x0800
+#define EFI_RT_SUPPORTED_QUERY_CAPSULE_CAPABILITIES0x1000
+#define EFI_RT_SUPPORTED_QUERY_VARIABLE_INFO   0x2000
+
 struct efi_runtime_services {
struct efi_table_hdr hdr;
efi_status_t (EFIAPI *get_time)(struct efi_time *time,
diff --git a/include/efi_loader.h b/include/efi_loader.h
index f0e1313f93..b07155cecb 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -573,6 +573,9 @@ static inline int guidcmp(const efi_guid_t *g1, const 
efi_guid_t *g2)
 #define __efi_runtime_data __attribute__ ((section (".data.efi_runtime")))
 #define __efi_runtime __attribute__ ((section (".text.efi_runtime")))

+/* Indicate supported runtime services */
+efi_status_t efi_init_runtime_supported(void);
+
 /* Update CRC32 in table header */
 void __efi_runtime efi_update_table_header_crc32(struct efi_table_hdr *table);

diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 432551d0c8..6621b9eeae 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -89,6 +89,30 @@ struct elf_rela {
  * handle a good number of runtime callbacks
  */

+efi_status_t efi_init_runtime_supported(void)
+{
+   u16 efi_runtime_services_supported;
+
+   /*
+* This value must be synced with efi_runtime_detach_list
+* as well as efi_runtime_services.
+*/
+#if CONFIG_IS_ENABLED(CONFIG_ARCH_BCM283X) || \
+CONFIG_IS_ENABLED(CONFIG_FSL_LAYERSCAPE) || \
+CONFIG_IS_ENABLED(CONFIG_SYSRESET_X86) || \
+CONFIG_IS_ENABLED(CONFIG_PSCI_RESET)
+   efi_runtime_services_supported = EFI_RT_SUPPORTED_RESET_SYSTEM;
+#endif
+   efi_runtime_services_supported |=
+   EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP;
+   return EFI_CALL(efi_set_variable(L"RuntimeServicesSupported",
+_global_variable_guid,
+EFI_VARIABLE_BOOTSERVICE_ACCESS |
+EFI_VARIABLE_RUNTIME_ACCESS,
+sizeof(efi_runtime_services_supported),
+_runtime_services_supported));
+}
+
 /**
  * efi_update_table_header_crc32() - Update crc32 in table header
  *
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index 8691d686d2..bfb57836fa 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -117,6 +117,11 @@ efi_status_t efi_init_obj_list(void)
if (ret != EFI_SUCCESS)
goto out;

+   /* Indicate supported runtime services */
+   ret = efi_init_runtime_supported();
+   if (ret != EFI_SUCCESS)
+   goto out;
+
/* Initialize system table */
ret = efi_initialize_system_table();
if (ret != EFI_SUCCESS)
--
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] rtl8169: use dm_pci_map_bar

[Thierry Reding]

On Thu, Jun 13, 2019 at 03:16:10PM +0800, Bin Meng wrote:
> Hi Stefan,
> 
> On Thu, Jun 13, 2019 at 1:40 PM Stefan Roese  wrote:
> >
> > Added Bin, Joe and Thierry to Cc
> >
> > On 11.06.19 13:15, Patrick Wildt wrote:
> > > Hi,
> > >
> > > I have an rtl8169 on a macchiatobin and that card has a 64-bit
> > > memory address.  The current code only reads a single word, which
> > > means it can only support a 32-bit address.  By using dm_pci_map_bar
> > > we don't need to manually parse the register, we can just have it do
> > > its job.
> > >
> > > I'm not sure though if this works for all devices since the previous
> > > version had an explicit check for the device.
> > >
> > > Patrick
> > >
> > > Signed-off-by: Patrick Wildt 
> > >
> > > diff --git a/drivers/net/rtl8169.c b/drivers/net/rtl8169.c
> > > index 521e5909a2..f1d2ade253 100644
> > > --- a/drivers/net/rtl8169.c
> > > +++ b/drivers/net/rtl8169.c
> > > @@ -1182,22 +1182,11 @@ static int rtl8169_eth_probe(struct udevice *dev)
> > >   struct pci_child_platdata *pplat = dev_get_parent_platdata(dev);
> > >   struct rtl8169_private *priv = dev_get_priv(dev);
> > >   struct eth_pdata *plat = dev_get_platdata(dev);
> > > - u32 iobase;
> > > - int region;
> > >   int ret;
> > >
> > > - debug("rtl8169: REALTEK RTL8169 @0x%x\n", iobase);
> > > - switch (pplat->device) {
> > > - case 0x8168:
> > > - region = 2;
> > > - break;
> > > - default:
> > > - region = 1;
> > > - break;
> > > - }
> > > - dm_pci_read_config32(dev, PCI_BASE_ADDRESS_0 + region * 4, );
> > > - iobase &= ~0xf;
> > > - priv->iobase = (int)dm_pci_mem_to_phys(dev, iobase);
> > > + priv->iobase = dm_pci_map_bar(dev, PCI_BASE_ADDRESS_2,
> > > +   PCI_REGION_MEM);
> > > + printf("rtl8169: REALTEK RTL8169 @0x%x\n", priv->iobase);
> > >
> > >   ret = rtl_init(priv->iobase, dev->name, plat->enetaddr);
> > >   if (ret < 0) {
> >
> > Bin, Joe, Thierry,
> >
> > do you have any comments on this patch? Moving unconditionally to one
> > BAR instead of BAR1/2 depending on the chip version seems a bit
> > "brave".
> 
> Agreed that blinding setting one BAR for the iobase is not a good idea.

Agreed. I don't know whether it's actually required to differentiate
based on version, but I suppose the code is like that for a reason, so
better keep that.

Also, looking at dm_pci_map_bar() it doesn't look like that does
anything different than the existing code. It merely reads a single
32-bit register, so it doesn't properly deal with 64-bit BARs either.

I suppose that could be fixed in dm_pci_map_bar(), and then the fix
would automatically propagate to all users of that, which is good. But I
don't think it currently works correctly.

Thierry


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/3] fdt: Allow indicating a node is for U-Boot proper only

[Simon Glass]

Hi Patrick,

On Thu, 13 Jun 2019 at 09:12, Patrick DELAUNAY  wrote:
>
> Hi Simon,
>
> >
> > Hi,
> >
> > I create this serie with:
> >
> > 1/ documentation update for previous patch
> >[U-Boot,v2] dm: remove pre reloc properties in SPL and TPL device tree
> >http://patchwork.ozlabs.org/patch/1081155/
> >
> >PS: Code is already merged in commit commit c7a88dae997f ("dm: remove
> >pre reloc properties in SPL and TPL device tree")
> >but not the documentation.
> >
> > 2/ missing part for v1 serie (patch 1/2)
> >http://patchwork.ozlabs.org/project/uboot/list/?series=89846
> >=> http://patchwork.ozlabs.org/patch/1035797
> >
> > 3/ new tests for pre-reloc propertie in SPL as suggested by Simon
> >(http://patchwork.ozlabs.org/patch/1081155/#2156621)
> >
> > Regards
> > Patrick
> >
> >
> > Changes in v3:
> > - simplify test after Simon remarks by using fdtgrep on spl dtb
> > - rebase on u-boot-dm/sandbox-working
> >
> > Changes in v2:
> > - rebase on master
> >
> > Patrick Delaunay (3):
> >   test: check u-boot properties in SPL device tree
> >   fdt: Allow indicating a node is for U-Boot proper only
> >   dm: doc: add documentation for pre-reloc properties in SPL and TPL
> >
> >  arch/sandbox/dts/sandbox.dtsi| 18 ++
> >  doc/README.SPL   | 16 
> >  doc/README.TPL   |  4 
> >  doc/driver-model/README.txt  |  4 
> >  drivers/core/util.c  |  2 ++
> >  drivers/video/video-uclass.c |  4 +++-
> >  include/dm/ofnode.h  |  6 --
> >  include/dm/util.h|  6 --
> >  test/py/tests/test_ofplatdata.py | 28 
> >  9 files changed, 83 insertions(+), 5 deletions(-)
> >
> > --
> > 2.7.4
>
> Gentle reminder
>
> targeted for v2019.07 or for next release v2019.10 ?
>
> Not blocking for my board (as display is not yet supported).

I'm planning to pull this in for the next release, and expect to have
more time in a week.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] armv8: fix typo in LINUX_KERNEL_IMAGE_HEADER check

[Stephen Warren]

On 6/13/19 6:46 AM, Mian Yousaf Kaukab wrote:

Fixes: 8163faf952 ARMv8: add optional Linux kernel image header


I thought that I'd fixed this long ago, but perhaps I only did that for 
out internal branch and forgot to send the patch upstream. Anyway,


Reviewed-by: Stephen Warren 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/3] fdt: Allow indicating a node is for U-Boot proper only

[Patrick DELAUNAY]

Hi Simon,

> 
> Hi,
> 
> I create this serie with:
> 
> 1/ documentation update for previous patch
>[U-Boot,v2] dm: remove pre reloc properties in SPL and TPL device tree
>http://patchwork.ozlabs.org/patch/1081155/
> 
>PS: Code is already merged in commit commit c7a88dae997f ("dm: remove
>pre reloc properties in SPL and TPL device tree")
>but not the documentation.
> 
> 2/ missing part for v1 serie (patch 1/2)
>http://patchwork.ozlabs.org/project/uboot/list/?series=89846
>=> http://patchwork.ozlabs.org/patch/1035797
> 
> 3/ new tests for pre-reloc propertie in SPL as suggested by Simon
>(http://patchwork.ozlabs.org/patch/1081155/#2156621)
> 
> Regards
> Patrick
> 
> 
> Changes in v3:
> - simplify test after Simon remarks by using fdtgrep on spl dtb
> - rebase on u-boot-dm/sandbox-working
> 
> Changes in v2:
> - rebase on master
> 
> Patrick Delaunay (3):
>   test: check u-boot properties in SPL device tree
>   fdt: Allow indicating a node is for U-Boot proper only
>   dm: doc: add documentation for pre-reloc properties in SPL and TPL
> 
>  arch/sandbox/dts/sandbox.dtsi| 18 ++
>  doc/README.SPL   | 16 
>  doc/README.TPL   |  4 
>  doc/driver-model/README.txt  |  4 
>  drivers/core/util.c  |  2 ++
>  drivers/video/video-uclass.c |  4 +++-
>  include/dm/ofnode.h  |  6 --
>  include/dm/util.h|  6 --
>  test/py/tests/test_ofplatdata.py | 28 
>  9 files changed, 83 insertions(+), 5 deletions(-)
> 
> --
> 2.7.4

Gentle reminder

targeted for v2019.07 or for next release v2019.10 ?

Not blocking for my board (as display is not yet supported).

Patrick
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] fastboot: Fix slot names reported by getvar

[Sam Protsenko]

Hi Eugeniu,

On Thu, Jun 13, 2019 at 12:31 PM Eugeniu Rosca  wrote:
>
> Hi Sam,
>
> On Thu, Jun 13, 2019 at 12:49:45AM +0300, Sam Protsenko wrote:
> > In commit [1] fastboot tool was changed w.r.t. new A/B specification [2],
> > and now we should report slot names in "a" format instead of "_a".
> > Latter is now considered legacy and we shouldn't rely on that anymore.
>
> This looks like a change which advantages the users who are always on
> the tip/HEAD of all relevant components (fastboot and U-Boot), but that
> rarely happens in the industry. Suppliers and hardening vendors often
> deliver obsoleted versions because they can't keep up with upstream
> development. Can you please document the behavior of 'fastboot flash'
> (and anything else relying on
> 'fastboot getvar (current-slot|slot-suffixes) in below scenarios:
>
> A. fastboot >= [1] && U-Boot + this patch
> B. fastboot >= [1] && U-Boot - this patch
> C. fastboot <  [1] && U-Boot + this patch
> D. fastboot <  [1] && U-Boot - this patch
>
> Would it be possible to keep U-Boot backward-compatible, such that
> regardless of the scenario enumerated above, 'fastboot flash' will
> always succeed?
>

I'm afraid in this particular case we weren't given any choice, and we
won't be able to provide backward-compatibility for older Android
releases. After this commit:

[3] 
https://android.googlesource.com/platform/system/core/+/42b18a518bac85c3eea14206f6cbafbd1e98a31f

they dropped support for "_a" format completely (in fastboot tool). So:
  * if user runs new fastboot tool ( >= [3]), then the only way to
make "fastboot flash" work is to return slot in "a" format from
bootloader
  * if user runs old fastboot tool (< [1]), then the only way to make
"fastboot flash" work is to return slot in "_a" format from bootloader

Good news is that user can basically downgrade or upgrade fastboot
tool, to be in sync with U-Boot version in use. Bad news, we need to
decide which Android version to break in U-Boot/master.

I suggest we track AOSP/master in U-Boot/master. Please let me know if
you agree, or maybe there is some better way I'm missing.

Thanks!

> > [1] 
> > https://android.googlesource.com/platform/system/core/+/8091947847d5e5130b09d2ac0a4bdc900f3b77c5
> > [2] https://source.android.com/devices/tech/ota/ab/ab_implement#partitions
>
> --
> Best Regards,
> Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/5] sunxi: env: Load environment from boot media

[Maxime Ripard]

On Tue, Jun 11, 2019 at 04:34:25PM +0100, Andre Przywara wrote:
> On Tue, 11 Jun 2019 16:53:58 +0200
> Maxime Ripard  wrote:
> > On Tue, Jun 11, 2019 at 10:28:19AM -0400, Tom Rini wrote:
> > > On Tue, Jun 11, 2019 at 11:37:28AM +0200, Maxime Ripard wrote:
> > > > On Mon, Jun 10, 2019 at 10:11:39AM +0100, Andre Przywara wrote:
> > > > > On Mon, 10 Jun 2019 10:30:37 +0200
> > > > > Maxime Ripard  wrote:
> > > > >
> > > > > Hi Maxime,
> > > > >
> > > > > thanks for having a look!
> > > > >
> > > > > > On Sat, Jun 08, 2019 at 02:26:53AM +0100, Andre Przywara wrote:
> > > > > > > At the moment we need to configure the place where U-Boot tries 
> > > > > > > to load
> > > > > > > its environment from at compile time. This is not only 
> > > > > > > inflexible, but
> > > > > > > also unnecessary, as we have easy access to the boot source.
> > > > > > >
> > > > > > > This series prepares U-Boot on Allwinner boards to load the 
> > > > > > > environment
> > > > > > > from the same media where the SPL and U-Boot proper were loaded 
> > > > > > > from.
> > > > > > > This allows to keep one firmware binary, and copy it to an SD 
> > > > > > > card,
> > > > > > > eMMC or even SPI flash, without needing to configure it 
> > > > > > > differently.
> > > > > >
> > > > > > This does change a couple of things though. The environment used to 
> > > > > > be
> > > > > > loaded always from the same source, no matter the boot device. This
> > > > > > means that if you would set an SD card, you would get the 
> > > > > > environment
> > > > > > from the eMMC. Same thing for FEL. This is no longer the case.
> > > > > >
> > > > > > I don't know whether it's a good or a bad thing, but it should be
> > > > > > mentionned.
> > > > >
> > > > > This is true, I failed to mention that.
> > > > >
> > > > > To start a discussion on this:
> > > > > I consider the current (fixed location) behaviour somewhat surprising 
> > > > > and
> > > > > limiting, and couldn't find a real use case where this would be 
> > > > > required.
> > > > > Happy to hear of one!
> > > > > Instead I thought about those cases:
> > > > > - There is some botched U-Boot plus environment on the eMMC. You want 
> > > > > to
> > > > > boot from SD card to have a clean start, possibly to fix it. But it 
> > > > > will
> > > > > load the possibly outdated, broken or even unrelated environment from 
> > > > > eMMC.
> > > >
> > > > This one might be a feature though. Being able to restore / fix an
> > > > environment in the eMMC running from an SD card has save me a couple
> > > > of times. Or booting from the SD card because the U-Boot on the eMMC
> > > > is broken, while the environment is working.
> > > >
> > > > > - You want to boot from SD card without touching the eMMC at all. 
> > > > > Saving
> > > > > the environment will spoil that.
> > > >
> > > > But it goes against that one, which might be more important / sensible.
> > > >
> > > > > - You want to have one image for all possible boot media.
> > > >
> > > > That won't happen, only because NAND is a thing.
>
> Looks like there are exactly 2 out of 146 Allwinner boards with mainline
> (_defconfig) NAND support out there, and fortunately I haven't seen NAND
> flash on modern (sunxi) boards in a while.

That's a rather big underestimation though. Most of the boards before
the H3 era have a NAND. UBI cannot deal with the NAND chips technology
yet, but they do have a NAND chip that should be supported in the
future.

> And if I see this correctly, there is neither eMMC nor SD card on the
> C.H.I.P. devices?

Yes.

> So their defconfig will also "boot on all possible boot media".

But not the Olinuxinos, Cubieboard, pcduino's, etc. Basically all the
A10/A13/A20/A33 boards have a NAND chip, and most of them will also
have an SD card slot.

> What I was aiming at with "have one image for all possible boot media" is
> to not throw away what works already: the _defconfig build for most (all?)
> boards works naturally on eMMC and SD card, also on SPI flash, for the SPL
> and for U-Boot proper. It's just the environment that requires fixing.
> Which is what this series is about.

It works because the support is not complete at this point, so it's
pretty fragile to market it as such.

> > > Some of this is perhaps an argument for adding a sub-command to specify
> > > where the environment is to be read from.  Heuristics are still only a
> > > best guess and won't get it right every time.
>
> Yeah, I was wondering about this as well. Maxime's case of: "I want to
> save the environment to this device" seems like a valid use case.
>
> Wouldn't a parameter to "saveenv" solve this rather elegantly? Happy to
> look into a patch for this.

Yeah, passing the argument is pretty elegant.

> > I was mostly talking about the distribution of the image itself. While
> > eMMC, SD and SPI flash can be made to take the same image, NAND will
> > require a particular ECC and randomizer setup that requires that it's
> > bundled separately.
>
> 

[U-Boot] [PATCH v2 4/4] armv8: dts: ls1028ardb: Add slave nodes under the i2c0 controller

[Chuanhua Han]

This patch adds some slave nodes to support the i2c dm on the device
side under the i2c0 controller.

Signed-off-by: Chuanhua Han 
---
depends on: 
- https://patchwork.ozlabs.org/project/uboot/list/?series=113364
- https://patchwork.ozlabs.org/project/uboot/list/?series=110856
- https://patchwork.ozlabs.org/project/uboot/list/?series=109677

Changes in v2: 
- Delete unnecessary aliases about i2c.

 arch/arm/dts/fsl-ls1028a-rdb.dts | 67 
 1 file changed, 67 insertions(+)

diff --git a/arch/arm/dts/fsl-ls1028a-rdb.dts b/arch/arm/dts/fsl-ls1028a-rdb.dts
index 932cfa2275..ec24373d29 100644
--- a/arch/arm/dts/fsl-ls1028a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1028a-rdb.dts
@@ -13,6 +13,20 @@
 / {
model = "NXP Layerscape 1028a RDB Board";
compatible = "fsl,ls1028a-rdb", "fsl,ls1028a";
+
+   sys_mclk: clock-mclk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2500>;
+   };
+
+   reg_1p8v: regulator-1p8v {
+   compatible = "regulator-fixed";
+   regulator-name = "1P8V";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   };
 };
 
  {
@@ -37,6 +51,59 @@
 
  {
status = "okay";
+   u-boot,dm-pre-reloc;
+
+i2c-mux@77 {
+
+   compatible = "nxp,pca9547";
+   reg = <0x77>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   i2c@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x1>;
+
+   codec: sgtl5000@a {
+   #sound-dai-cells = <0>;
+   compatible = "fsl,sgtl5000";
+   reg = <0xa>;
+   VDDA-supply = <_1p8v>;
+   VDDIO-supply = <_1p8v>;
+   clocks = <_mclk>;
+   sclk-strength = <3>;
+   };
+   };
+
+   i2c@2 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x02>;
+
+   ina220@40 {
+   compatible = "ti,ina220";
+   reg = <0x40>;
+   shunt-resistor = <500>;
+   };
+   };
+
+   i2c@3 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x3>;
+
+   sa56004@4c {
+   compatible = "nxp,sa56004";
+   reg = <0x4c>;
+   };
+
+   rtc@51 {
+   compatible = "pcf2127-rtc";
+   reg = <0x51>;
+   };
+   };
+   };
 };
 
  {
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 3/4] configs: ls1028a: enable DM support for pcf2127 rtc

[Chuanhua Han]

Enable related configs to support pcf2127 rtc DM feature for
ls1028ardb board.

Signed-off-by: Chuanhua Han 
---
depends on: 
- https://patchwork.ozlabs.org/project/uboot/list/?series=113364
- https://patchwork.ozlabs.org/project/uboot/list/?series=110856
- https://patchwork.ozlabs.org/project/uboot/list/?series=109677

Changes in v2: 
-  Enable secure boot defconfig to support pcf2127 rtc DM
feature for ls1028ardb board.

 configs/ls1028ardb_tfa_SECURE_BOOT_defconfig | 9 -
 configs/ls1028ardb_tfa_defconfig | 9 -
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig 
b/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig
index 3432f90087..c101a33a4b 100644
--- a/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig
+++ b/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig
@@ -1,5 +1,6 @@
 CONFIG_ARM=y
 CONFIG_TARGET_LS1028ARDB=y
+CONFIG_SYS_MALLOC_F_LEN=0x6000
 CONFIG_SECURE_BOOT=y
 CONFIG_SYS_FSL_SDHC_CLK_DIV=1
 CONFIG_TFABOOT=y
@@ -8,7 +9,6 @@ CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT=y
 CONFIG_SEC_FIRMWARE_ARMV8_PSCI=y
 CONFIG_AHCI=y
 CONFIG_DISTRO_DEFAULTS=y
-# CONFIG_SYS_MALLOC_F is not set
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
@@ -60,3 +60,10 @@ CONFIG_WDT=y
 CONFIG_WDT_SP805=y
 CONFIG_RSA=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_DM_I2C=y
+CONFIG_DM_RTC=y
+CONFIG_DM_GPIO=y
+CONFIG_CMD_DATE=y
+CONFIG_RTC_PCF2127=y
+CONFIG_I2C_MUX=y
+CONFIG_I2C_MUX_PCA954x=y
diff --git a/configs/ls1028ardb_tfa_defconfig b/configs/ls1028ardb_tfa_defconfig
index a8e4ddb7a8..440104cb18 100644
--- a/configs/ls1028ardb_tfa_defconfig
+++ b/configs/ls1028ardb_tfa_defconfig
@@ -1,5 +1,6 @@
 CONFIG_ARM=y
 CONFIG_TARGET_LS1028ARDB=y
+CONFIG_SYS_MALLOC_F_LEN=0x6000
 CONFIG_SYS_FSL_SDHC_CLK_DIV=1
 CONFIG_TFABOOT=y
 CONFIG_NR_DRAM_BANKS=2
@@ -7,7 +8,6 @@ CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT=y
 CONFIG_SEC_FIRMWARE_ARMV8_PSCI=y
 CONFIG_AHCI=y
 CONFIG_DISTRO_DEFAULTS=y
-# CONFIG_SYS_MALLOC_F is not set
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
@@ -62,3 +62,10 @@ CONFIG_USB_XHCI_DWC3=y
 CONFIG_WDT=y
 CONFIG_WDT_SP805=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_DM_I2C=y
+CONFIG_DM_RTC=y
+CONFIG_DM_GPIO=y
+CONFIG_CMD_DATE=y
+CONFIG_RTC_PCF2127=y
+CONFIG_I2C_MUX=y
+CONFIG_I2C_MUX_PCA954x=y
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 2/4] gpio: do not include on ARCH_LS1028A

[Chuanhua Han]

As no gpio.h is defined for this architecture, to avoid
compilation failure, do not include  for
arch ls1028a.

Signed-off-by: Chuanhua Han 
---
depends on: 
- https://patchwork.ozlabs.org/project/uboot/list/?series=113364
- https://patchwork.ozlabs.org/project/uboot/list/?series=110856
- https://patchwork.ozlabs.org/project/uboot/list/?series=109677

Changes in v2: 
- No change.

 arch/arm/include/asm/gpio.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h
index f78b976e10..b5adf5c816 100644
--- a/arch/arm/include/asm/gpio.h
+++ b/arch/arm/include/asm/gpio.h
@@ -1,7 +1,7 @@
 #if !defined(CONFIG_ARCH_UNIPHIER) && !defined(CONFIG_ARCH_STI) && \
!defined(CONFIG_ARCH_K3) && !defined(CONFIG_ARCH_BCM6858) && \
!defined(CONFIG_ARCH_BCM63158) && !defined(CONFIG_ARCH_ROCKCHIP) && \
-   !defined(CONFIG_ARCH_LX2160A)
+   !defined(CONFIG_ARCH_LX2160A) && !defined(CONFIG_ARCH_LS1028A)
 #include 
 #endif
 #include 
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 1/4] armv8: ls1028a: The ls1028a platform supports the I2C driver model.

[Chuanhua Han]

DM_I2C_COMPAT is a compatibility layer that allows using the non-DM
I2C API when DM_I2C is used.When DM_I2C_COMPAT is not enabled for
compilation, a compilation error will be generated. This patch
solves the problem that the i2c-related api of the ls1028a platform
does not support dm.

Signed-off-by: Chuanhua Han 
---
depends on: 
- https://patchwork.ozlabs.org/project/uboot/list/?series=113364
- https://patchwork.ozlabs.org/project/uboot/list/?series=110856
- https://patchwork.ozlabs.org/project/uboot/list/?series=109677

Changes in v2:
- No change.

 arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 8 
 board/freescale/ls1028a/ls1028a.c | 8 
 include/configs/ls1028a_common.h  | 3 ---
 include/configs/ls1028ardb.h  | 1 -
 4 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index f3eaab960b..ee2b3f4a5d 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -40,14 +40,6 @@ config ARCH_LS1028A
select ARCH_EARLY_INIT_R
select BOARD_EARLY_INIT_F
select SYS_I2C_MXC
-   select SYS_I2C_MXC_I2C1
-   select SYS_I2C_MXC_I2C2
-   select SYS_I2C_MXC_I2C3
-   select SYS_I2C_MXC_I2C4
-   select SYS_I2C_MXC_I2C5
-   select SYS_I2C_MXC_I2C6
-   select SYS_I2C_MXC_I2C7
-   select SYS_I2C_MXC_I2C8
select SYS_FSL_ERRATUM_A009007
select SYS_FSL_ERRATUM_A008514 if !TFABOOT
select SYS_FSL_ERRATUM_A009663 if !TFABOOT
diff --git a/board/freescale/ls1028a/ls1028a.c 
b/board/freescale/ls1028a/ls1028a.c
index e5de4eb70c..49a9292c31 100644
--- a/board/freescale/ls1028a/ls1028a.c
+++ b/board/freescale/ls1028a/ls1028a.c
@@ -73,7 +73,15 @@ int board_init(void)
 #if defined(CONFIG_TARGET_LS1028ARDB)
u8 val = I2C_MUX_CH_DEFAULT;
 
+#ifndef CONFIG_DM_I2C
i2c_write(I2C_MUX_PCA_ADDR_PRI, 0x0b, 1, , 1);
+#else
+   struct udevice *dev;
+
+   if (!i2c_get_chip_for_busnum(0, I2C_MUX_PCA_ADDR_PRI, 1, ))
+   dm_i2c_write(dev, 0x0b, , 1);
+#endif
+
 #endif
return 0;
 }
diff --git a/include/configs/ls1028a_common.h b/include/configs/ls1028a_common.h
index d3d787f14d..0fa5095fc8 100644
--- a/include/configs/ls1028a_common.h
+++ b/include/configs/ls1028a_common.h
@@ -41,9 +41,6 @@
 /* Size of malloc() pool */
 #define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + 2048 * 1024)
 
-/* I2C */
-#define CONFIG_SYS_I2C
-
 /* Serial Port */
 #define CONFIG_CONS_INDEX   1
 #define CONFIG_SYS_NS16550_SERIAL
diff --git a/include/configs/ls1028ardb.h b/include/configs/ls1028ardb.h
index 10791be824..b77c36d279 100644
--- a/include/configs/ls1028ardb.h
+++ b/include/configs/ls1028ardb.h
@@ -22,7 +22,6 @@
 #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE
 
 #define CONFIG_QIXIS_I2C_ACCESS
-#define CONFIG_SYS_I2C_EARLY_INIT
 
 /*
  * QIXIS Definitions
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] armv8: fix typo in LINUX_KERNEL_IMAGE_HEADER check

[Mian Yousaf Kaukab]

Fixes: 8163faf952 ARMv8: add optional Linux kernel image header

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm/cpu/armv8/start.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
index fe52166e28..99d126660d 100644
--- a/arch/arm/cpu/armv8/start.S
+++ b/arch/arm/cpu/armv8/start.S
@@ -18,7 +18,7 @@
 
 .globl _start
 _start:
-#if defined(LINUX_KERNEL_IMAGE_HEADER)
+#if defined(CONFIG_LINUX_KERNEL_IMAGE_HEADER)
 #include 
 #elif defined(CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK)
 /*
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] imx6: [PATCH] Add support for new board "eval1a"

[claudio]

This patch adds support for the latest evalboard Eval 1A from databyte


Signed-off-by: Claudio Hediger 
Cc: Stefano Babic 
---
From ecfc11f5507e2a1db2c8981b193017e1fd74f7eb Mon Sep 17 00:00:00 2001
From: Claudio Hediger 
Date: Sun, 9 Jun 2019 15:56:29 +0200
Subject: [PATCH 1/3] Added new file. Not finished yet. Commit before eclipse

---
 arch/arm/dts/eval1a.dts   | 204 +
 arch/arm/mach-imx/mx6/Kconfig |   6 +
 board/databyte.ch/eval1a/Kconfig  |  12 ++
 board/databyte.ch/eval1a/MAINTAINERS  |   7 +
 board/databyte.ch/eval1a/Makefile |   4 +
 board/databyte.ch/eval1a/eval1a.c | 211 ++
 board/databyte.ch/eval1a/imximage.cfg | 133 
 board/databyte.ch/eval1a/plugin.S | 173 +
 configs/eval1a_defconfig  |  36 +
 include/configs/eval1a.h  |  54 +++
 10 files changed, 840 insertions(+)
 create mode 100644 arch/arm/dts/eval1a.dts
 create mode 100644 board/databyte.ch/eval1a/Kconfig
 create mode 100644 board/databyte.ch/eval1a/MAINTAINERS
 create mode 100644 board/databyte.ch/eval1a/Makefile
 create mode 100644 board/databyte.ch/eval1a/eval1a.c
 create mode 100644 board/databyte.ch/eval1a/imximage.cfg
 create mode 100644 board/databyte.ch/eval1a/plugin.S
 create mode 100644 configs/eval1a_defconfig
 create mode 100644 include/configs/eval1a.h

diff --git a/arch/arm/dts/eval1a.dts b/arch/arm/dts/eval1a.dts
new file mode 100644
index 00..1869abab6a
--- /dev/null
+++ b/arch/arm/dts/eval1a.dts
@@ -0,0 +1,204 @@
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+
+#include "imx6ull.dtsi"
+
+/ {
+   model = "Databyte imx6 Evalboard 1A";
+   compatible = "dtb,eval1a", "fsl,imx6ull";
+
+   chosen {
+   stdout-path = 
+   };
+
+   memory {
+   reg = <0x8000 0x2000>;
+   };
+
+   regulators {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg_can_3v3: regulator@0 {
+   compatible = "regulator-fixed";
+   reg = <0>;
+   regulator-name = "can-3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpios = <_spi 3 GPIO_ACTIVE_LOW>;
+   };
+
+   reg_sd1_vmmc: regulator@1 {
+   compatible = "regulator-fixed";
+   regulator-name = "VSD_3V3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = < 9 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   };
+
+};
+
+ {
+   arm-supply = <_arm>;
+   soc-supply = <_soc>;
+   /*dc-supply = <_gpio_dvfs>;*/
+};
+
+ {
+   assigned-clocks = < IMX6UL_CLK_PLL4_AUDIO_DIV>;
+   assigned-clock-rates = <786432000>;
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_enet1>;
+   phy-mode = "rmii";
+   phy-handle = <>;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_enet2>;
+   phy-mode = "rmii";
+   phy-handle = <>;
+   status = "okay";
+
+   mdio {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ethphy0: ethernet-phy@2 {
+   compatible = "micrel,ksz8081";
+   reg = <2>;
+   };
+
+   ethphy1: ethernet-phy@1 {
+   compatible = "micrel,ksz8081";
+   reg = <1>;
+   };
+   };
+};
+
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_hog_1>;
+   eval1a {
+
+   pinctrl_enet1: enet1grp {
+   fsl,pins = <
+   MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN
0x1b0b0
+   MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER
0x1b0b0
+   MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00
0x1b0b0
+   MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01
0x1b0b0
+   MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN
0x1b0b0
+   MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00
0x1b0b0
+   MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01
0x1b0b0
+   MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1
0x4001b031
+   >;
+   };
+
+   pinctrl_enet2: enet2grp {
+   fsl,pins = <
+   MX6UL_PAD_GPIO1_IO07__ENET2_MDC
0x1b0b0
+

Re: [U-Boot] [PATCH v2 3/3] fastboot: Check if partition really exist in getvar_has_slot()

[Lukasz Majewski]

On Thu, 13 Jun 2019 07:47:19 +0200
Lukasz Majewski  wrote:

> Hi Sam,
> 
> > Hi Tom,
> > 
> > We have broken fastboot right now... Can we please apply this
> > series, so that it appears in v2019.07?  
> 
> I'm running Travis-CI on this series, and send PR to Marek when it
> finish.

Unfortunately, there are several build breaks:
https://travis-ci.org/lmajewski/u-boot-dfu/jobs/545073270

Please fix them before sending v3.

Thanks in advance,

> 
> Thanks for fixing fastboot.
> 
> > 
> > Thanks!
> > 
> > On Thu, Jun 13, 2019 at 12:14 AM Sam Protsenko
> >  wrote:  
> > >
> > > From: Igor Opaniuk 
> > >
> > > Currently getvar_has_slot() invocation for "boot" and "system"
> > > partitions always returns affirmative response regardless the fact
> > > of existence of these partitions, which leads to impossibility to
> > > flash them on old non-A/B AOSP setups, where _a/_b suffixes aren't
> > > used:
> > >
> > > $ fastboot flash boot boot.img
> > > Sending 'boot__a' (11301 KB)OKAY [  0.451s]
> > > Writing 'boot__a'   FAILED (remote: 'cannot find
> > > partition') fastboot: error: Command failed
> > >
> > > Although partition layout is:
> > > -> part list mmc 0
> > > Partition Map for MMC device 0  --   Partition Type: EFI
> > >
> > > PartStart LBA   End LBA Name
> > > Attributes
> > > Type GUID
> > > Partition GUID
> > >   1 0x0800  0x000107ff  "boot"
> > > attrs:  0x
> > > type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
> > > guid:   ea2e2470-db4a-d646-b828-10167f736d63
> > >   2 0x00010800  0x000127ff  "environment"
> > > attrs:  0x
> > > type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
> > > guid:   10a819d2-6004-3d48-bd87-114e2a796db9
> > >   3 0x00012800  0x0001a7ff  "recovery"
> > > attrs:  0x
> > > type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
> > > guid:   9ea116e4-8a34-0c48-8cf5-2fe9480f56cd
> > >   4 0x0001a800  0x0031a7ff  "system"
> > > attrs:  0x
> > > ..
> > >
> > > This patch adds checks of existence for requested partitions
> > > on eMMC/NAND.
> > >
> > > Signed-off-by: Igor Opaniuk 
> > > Signed-off-by: Sam Protsenko 
> > > ---
> > >  drivers/fastboot/fb_getvar.c | 26 ++
> > >  1 file changed, 22 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/fastboot/fb_getvar.c
> > > b/drivers/fastboot/fb_getvar.c index b23880089e..563bda0088 100644
> > > --- a/drivers/fastboot/fb_getvar.c
> > > +++ b/drivers/fastboot/fb_getvar.c
> > > @@ -179,11 +179,29 @@ static void getvar_slot_suffixes(char
> > > *var_parameter, char *response)
> > >
> > >  static void getvar_has_slot(char *part_name, char *response)
> > >  {
> > > -   if (part_name && (!strcmp(part_name, "boot") ||
> > > - !strcmp(part_name, "system")))
> > > +   char part_name_wslot[PART_NAME_LEN];
> > > +   size_t len;
> > > +   int r;
> > > +
> > > +   if (!part_name)
> > > +   goto no;
> > > +
> > > +   /* Append "_a" prefix to part_name */
> > > +   len = strlcpy(part_name_wslot, part_name, PART_NAME_LEN -
> > > 3);
> > > +   if (len > PART_NAME_LEN - 3) {
> > > +   fastboot_fail("too long partition name",
> > > response);
> > > +   return;
> > > +   }
> > > +   strcat(part_name_wslot, "_a");
> > > +
> > > +   /* Check if this partition exists */
> > > +   r = getvar_get_part_info(part_name_wslot, response, NULL);
> > > +   if (r >= 0) {
> > > fastboot_okay("yes", response);
> > > -   else
> > > -   fastboot_okay("no", response);
> > > +   return;
> > > +   }
> > > +no:
> > > +   fastboot_okay("no", response);
> > >  }
> > >
> > >  #if CONFIG_IS_ENABLED(FASTBOOT_FLASH_MMC)
> > > --
> > > 2.20.1
> > >
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot  
> 
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> lu...@denx.de




Best regards,

Lukasz Majewski

--

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


pgpZI5ufAjjPY.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: dts: Stratix10: Enable i2c

[Marek Vasut]

On 6/13/19 10:17 AM, Ley Foon Tan wrote:
> Enable i2c1 in Stratix 10 devkit.
> 
> SOCFPGA_STRATIX10 # i2c bus
> Bus 0:  i2c@ffc02900
> SOCFPGA_STRATIX10 # i2c dev 0
> Setting bus to 0
> SOCFPGA_STRATIX10 # i2c probe
> Valid chip addresses: 14 4C 51 68 74
> 
> Signed-off-by: Ley Foon Tan 
> ---
>  arch/arm/dts/socfpga_stratix10_socdk.dts | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/dts/socfpga_stratix10_socdk.dts 
> b/arch/arm/dts/socfpga_stratix10_socdk.dts
> index 2745050810..c5409df026 100755
> --- a/arch/arm/dts/socfpga_stratix10_socdk.dts
> +++ b/arch/arm/dts/socfpga_stratix10_socdk.dts
> @@ -9,6 +9,7 @@
>   model = "SoCFPGA Stratix 10 SoCDK";
>  
>   aliases {
> + i2c0 = 
>   serial0 = 
>   };
>  
> @@ -77,6 +78,10 @@
>   };
>  };
>  
> + {
> + status = "okay";
> +};
> +
>   {
>   status = "okay";
>   cap-sd-highspeed;
> 
Applied, thanks.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] watchdog: tangier: Convert to use WDT class

[Stefan Roese]

On 13.06.19 13:10, Andy Shevchenko wrote:

On Thu, Jun 13, 2019 at 06:51:34AM +0200, Stefan Roese wrote:

On 12.06.19 19:28, Andy Shevchenko wrote:



   #define WDT_DEFAULT_TIMEOUT  90


Nitpicking: If you by any chance need to re-send this patch again,
please remove WDT_DEFAULT_TIMEOUT completely from this file.


This is left in order to have some traces of what firmware default is in use.
I can convert this into comment.


Sure. You also could remove it and use this original default
value either via Kconfig (CONFIG_WATCHDOG_TIMEOUT_MSECS) or via
DT ("timeout-sec" property). All is fine with me.

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC] fastboot: flashing to emmc hw boot (0, 1) partitions

[Sam Protsenko]

Hi Igor,

Although we are thinking to use QSPI for boot speedup, it still would
be nice to see flashing to boot0 implemented. Technically, I don't see
much difficulties here, as we already can do this from U-Boot shell,
like this:

=> mmc dev 0 1
=> fatload mmc 1 ${loadaddr} tiboot3.bin
=> mmc write ${loadaddr} 0x0 0x400

Of course, boot procedure should be probably changed too, as ROM-code
must be given the access to boot0 partition:

=> mmc partconf 0 1 1 1
=> mmc bootbus 0 1 0 0

Anyway, that's not so difficult to add to "fastboot flash" U-Boot
implementation. The only thing I'm worrying about is how to
differentiate between User Data Area and Boot Area partitions in
fastboot tool. Because when we do:

$ fastboot flash boot0 some.img

we might as well mean that boot0 is UDA partition name. So we have two
options here:
  1. In U-Boot: recognize "boot0" name as a special case and flash
into boot0 area instead of trying to flash into UDA area
  2. In fastboot tool: provide some new option so that user can
specify which area to use (boot area or UDA)

As I see it, once we decide on the course of action (#1 or #2), RFC
patch with initial implementation should be sent, so that we have more
specifics to talk about.

Thanks!

On Wed, Jun 12, 2019 at 4:23 PM Igor Opaniuk  wrote:
>
> Hi,
>
> Currently a lot of boards started (AFAIK: Colibri/Apalis
> iMX6/iMX7/iMX8QXP; TI AM56XX [1] etc.) using hardware boot0/1
> partitions for storing U-boot blob (which obviously speeds up the
> booting process).
>
> Taking into account that current implementation of fastboot driver
> does support only flashing images to "software" partitions in the user
> data area, does it make sense to add also the same support for
> boot0/boot1?
>
> It will definitely simplify and unify the way of firmware flashing, as
> currently people are playing around with `mmc partinfo`/`mmc write`
> and flashing stuff manually instead of using fastboot (where it's
> enabled).
>
> My suggestion is to introduce custom handling for `boot0` and `boot1`
> in the same manner as done for `zimage` [2] [3] for re-packing Android
> boot image with the new zImage. Example of flashing:
>
> -> fastboot flash boot0 u-boot.img
>
> Question: are there any objections (why it should not be
> done)/limitations I'm not aware of?
>
> Thanks for your suggestions.
>
> [1] 
> http://git.ti.com/cgit/cgit.cgi/ti-u-boot/ti-u-boot.git/tree/board/ti/am65x/README?h=ti-u-boot-2018.01
> [2] 
> http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/fastboot/fb_mmc.c;h=90ca81da9b5f338f09a27873fb142d142a07933e;hb=HEAD#l389
> [3] 
> http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/fastboot/fb_mmc.c;h=90ca81da9b5f338f09a27873fb142d142a07933e;hb=HEAD#l188
>
> --
> Best regards - Freundliche Grüsse - Meilleures salutations
>
> Igor Opaniuk
>
> mailto: igor.opan...@gmail.com
> skype: igor.opanyuk
> +380 (93) 836 40 67
> http://ua.linkedin.com/in/iopaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Call For Participation - OSFC 3rd to 6th September 2019

[Philipp Deppenwiese]

Do you have something crazy going on and want to present it to the
community?

Submit your talk for the Open Source Firmware conference 2019 in silicon
valley until June 30, 2019.
Speakers get complimentary admission to the conference.
We also have scholarship funds to help you attend the conference.

We will have three tracks:
1) Open Source Firmware Main Track
2) Security Track
3) Baseboard Management Controllers (BMC) Track
as well as lightning talks during the hackathon

So just go ahead and participate on the OSFC 19: https://osfc.io/speakers
See you in California in September."


Cheers,

Zaolin

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/3] fastboot: Check if partition really exist in getvar_has_slot()

[Eugeniu Rosca]

Hi Sam, hi Igor,

On Thu, Jun 13, 2019 at 12:14:11AM +0300, Sam Protsenko wrote:
> From: Igor Opaniuk 
> 
> Currently getvar_has_slot() invocation for "boot" and "system"
> partitions always returns affirmative response regardless the fact of
> existence of these partitions, which leads to impossibility to flash them
> on old non-A/B AOSP setups, where _a/_b suffixes aren't used:
> 
> $ fastboot flash boot boot.img
> Sending 'boot__a' (11301 KB)OKAY [  0.451s]
> Writing 'boot__a'   FAILED (remote: 'cannot find partition')
> fastboot: error: Command failed
> 
> Although partition layout is:
> -> part list mmc 0
> Partition Map for MMC device 0  --   Partition Type: EFI
> 
> Part  Start LBA   End LBA Name
>   Attributes
>   Type GUID
>   Partition GUID
>   1   0x0800  0x000107ff  "boot"
>   attrs:  0x
>   type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
>   guid:   ea2e2470-db4a-d646-b828-10167f736d63
>   2   0x00010800  0x000127ff  "environment"
>   attrs:  0x
>   type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
>   guid:   10a819d2-6004-3d48-bd87-114e2a796db9
>   3   0x00012800  0x0001a7ff  "recovery"
>   attrs:  0x
>   type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
>   guid:   9ea116e4-8a34-0c48-8cf5-2fe9480f56cd
>   4   0x0001a800  0x0031a7ff  "system"
>   attrs:  0x
> ..
> 
> This patch adds checks of existence for requested partitions
> on eMMC/NAND.
> 
> Signed-off-by: Igor Opaniuk 
> Signed-off-by: Sam Protsenko 
> ---
>  drivers/fastboot/fb_getvar.c | 26 ++
>  1 file changed, 22 insertions(+), 4 deletions(-)

With the https://patchwork.ozlabs.org/cover/1114844/
("[U-Boot,v2,0/3] fastboot: Fix getvar "has-slot" and cleanup")
series applied on top of v2019.07-rc4-136-gc2ea87883ef3, I get
below build failure on sandbox:

drivers/fastboot/fb_getvar.c: In function ‘getvar_has_slot’:
drivers/fastboot/fb_getvar.c:198:6: warning: implicit declaration of function 
‘getvar_get_part_info’; did you mean ‘getvar_serialno’? 
[-Wimplicit-function-declaration]
  r = getvar_get_part_info(part_name_wslot, response, NULL);
  ^~~~
  getvar_serialno
[..]
  LD  u-boot
drivers/built-in.o: In function `getvar_has_slot':
/home/erosca/R/u-boot-master/drivers/fastboot/fb_getvar.c:198: undefined 
reference to `getvar_get_part_info'
collect2: error: ld returned 1 exit status
Makefile:1570: recipe for target 'u-boot' failed
make[1]: *** [u-boot] Error 1
Makefile:498: recipe for target '__build_one_by_one' failed
make: *** [__build_one_by_one] Error 2

-- 
Best Regards,
Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] watchdog: tangier: Convert to use WDT class

[Andy Shevchenko]

On Thu, Jun 13, 2019 at 06:51:34AM +0200, Stefan Roese wrote:
> On 12.06.19 19:28, Andy Shevchenko wrote:

> >   #define WDT_DEFAULT_TIMEOUT   90
> 
> Nitpicking: If you by any chance need to re-send this patch again,
> please remove WDT_DEFAULT_TIMEOUT completely from this file.

This is left in order to have some traces of what firmware default is in use.
I can convert this into comment.

> Reviewed-by: Stefan Roese 

Thanks!

-- 
With Best Regards,
Andy Shevchenko


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Default environment file

[Stefano Babic]

Hi Vladimir,

On 12/06/19 23:33, Vladimir Oltean wrote:
> On Wed, 12 Jun 2019 at 19:30, Stefano Babic  wrote:
>>
>> Hi Tom,
>>
>> Hi everybody,
>>
>> On 12/06/19 16:16, Tom Rini wrote:
>>> On Wed, Jun 12, 2019 at 10:43:26AM +0200, Stefano Babic wrote:
 Hi Pascal,

 On 12/06/19 10:20, Linder Pascal wrote:
> Hi everyone,
>
>
> I am currently moving the configurations of the KM boards from header 
> files to Kconfig. But for the customly defined environment variables I 
> did not found a decent solution until I have come across the default 
> environment file, which seems very interesting to me.
>
>
> To this day, nevertheless, it appears that noone made use of the 
> CONFIG_USE_DEFAULT_ENV_FILE configuration defined in env/Kconfig. Does 
> anyone still have an example for this kind of environment definition or 
> knows how to create it?
>
>
> In my opinion, this could be highly relevant for the transition away from 
> the header files in include/configs.
>

 Fully agree. Rather, I do not think there is a relevant example. But the
 environment is something like data and should not be part of the header
 file as it is for histoical reason. I added some times ago a way to
 extract the environment from the header and make the transition easy
 (see make u-boot-initial-env). And if the environment is split from the
 header as CONFIG_USE_DEFAULT_ENV_FILE allows, it is also easier to set
 an own environment via OE BSP layer without pushing for each small
 change to U-Boot. Not only, environments often conflict, and what is
 good for a project becomes evil for another one.
>>>
>>> With the high-level goal of being able to eliminate the include/configs
>>> file, we need to figure out a better solution to dealing with the
>>> default environment.
>>
>> Right.
>>
>>> Shuffling things into include/environment/ has
>>> been the first step I've tried but I'm absolutely not tied down to this
>>> and if people are motivated to push in a new solution to this overall
>>> problem I'm happy to see it happen.  This sounds like a good overall
>>> idea.
>>
>> The default / initial environment is more a configuration data for the
>> bootloader as part of it. Linking it to the rest of code was done at the
>> beginning of U-Boot and it was never changed for historical reasons, but
>> the environment is just configuration data.  Theoretically, we could
>> have the same environment for multiple boards and we could use the same
>> files.
>>
>> IMHO it should be more a job for binman as for the linker to put
>> environment and u-boot code together. My first idea could be to drop it
>> from code and appending it to the binary, letting the code (SPL /
>> u-boot) know where the initial environment is found.
>> CONFIG_USE_DEFAULT_ENV_FILE could be used to set which file should be
>> taken by binman - the result is still a single file that can be signed
>> in case of secure boot.
>>
>> Best regards,
>> Stefano
>>
>> --
>> =
>> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
>> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
>> =
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> https://lists.denx.de/listinfo/u-boot
> 
> Hi guys,
> 
> Chiming in to the discussion as well, as I was looking to submit a new
> board port of U-boot with the distro boot feature, and I was amazed by
> the stupendous amount of code duplication in these include/configs/*.h
> files.
> Separating the default env from the main bootloader executable image
> doesn't look to me like the main problem here - 

It is part of the problem - the environment is really data for the
bootloader, and it is mixed with code. It make sense to have one
bootloader and exchange just the data, as usually for each program.

IMHO it is also quite nasty that this initial environment is set with an
array of strings, and the board maintainer should be careful adding the
'\0' to each command. How many times led this to errors due to
mishandling of the stings ?

And U-Boot does not use this internally - "env import" parses an ASCII
file from the memory.

> but rather how to
> re-use common portions of environments in a way that scales for
> hundreds of boards, and at the same time allow for customization?

Yes, and not only. This is maybe ok for board vendors, but think about
to the very common use case where a board is used for many projects.
Each project often needs its own environment for many reason. It should
be easy to exchange the environment without pushing it to u-boot, but
just use the bootloader as "code" and add the own "data".

Reusing can be reached if 

Re: [U-Boot] [PATCH v1] watchdog: move WATCHDOG_TIMEOUT_MSECS to Kconfig

[Martyn Welch]

On Wed, 2019-06-12 at 10:22 +0200, Heiko Schocher wrote:
> move WATCHDOG_TIMEOUT_MSECS to Kconfig and fix
> all board defconfigs.
> 
> Signed-off-by: Heiko Schocher 
> ---
> 
> Patchseries build fine on travis see:
> https://travis-ci.org/hsdenx/u-boot-test/builds/544546490
> 
> Based on mainline commit:
> 68b90e57bc: "configs: tinker-rk3288 disable CONFIG_SPL_I2C_SUPPORT"
> 
> and wdt imx patches from Marek:
> http://patchwork.ozlabs.org/patch/1112591/
> http://patchwork.ozlabs.org/patch/1112592/
> 
>  arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2 | 1 -
>  configs/dh_imx6_defconfig  | 1 +
>  configs/display5_defconfig | 1 +
>  configs/display5_factory_defconfig | 1 +
>  configs/ge_bx50v3_defconfig| 1 +
>  configs/kp_imx6q_tpc_defconfig | 1 +
>  configs/m53menlo_defconfig | 1 +
>  configs/mx53ppd_defconfig  | 1 +
>  configs/tqma6s_wru4_mmc_defconfig  | 1 +
>  configs/warp_defconfig | 1 +
>  drivers/watchdog/Kconfig   | 9 +
>  include/configs/MPC8349ITX.h   | 6 --
>  include/configs/MPC837XERDB.h  | 5 -
>  include/configs/dh_imx6.h  | 1 -
>  include/configs/display5.h | 1 -
>  include/configs/ge_bx50v3.h| 2 --
>  include/configs/kp_imx6q_tpc.h | 1 -
>  include/configs/m53menlo.h | 1 -
>  include/configs/mx53ppd.h  | 2 --
>  include/configs/socfpga_common.h   | 1 -
>  include/configs/socfpga_stratix10_socdk.h  | 1 -
>  include/configs/tqma6_wru4.h   | 1 -
>  include/configs/warp.h | 1 -
>  include/wdt.h  | 3 ---
>  scripts/config_whitelist.txt   | 1 -
>  25 files changed, 18 insertions(+), 28 deletions(-)
> 

Acked-by: Martyn Welch 

> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2
> b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2
> index 9583bf743e..d7f7b9f111 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2
> @@ -16,6 +16,5 @@ You can enable it by setting CONFIG_IMX_WATCHDOG.
>  Use following config to set watchdog timeout, if this config is not
> defined,
>  the default timeout value is 128s which is the maximum. Set 10
> seconds for
>  example:
> -#define CONFIG_WATCHDOG_TIMEOUT_MSECS 1
>  Set CONFIG_WATCHDOG_RESET_DISABLE to disable reset watchdog, so that
> the
>  watchdog will not be fed in u-boot.
> diff --git a/configs/dh_imx6_defconfig b/configs/dh_imx6_defconfig
> index d9ec5c7c5e..c3ef829553 100644
> --- a/configs/dh_imx6_defconfig
> +++ b/configs/dh_imx6_defconfig
> @@ -62,5 +62,6 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0525
>  CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
>  CONFIG_CI_UDC=y
>  CONFIG_USB_GADGET_DOWNLOAD=y
> +CONFIG_WATCHDOG_TIMEOUT_MSECS=6
>  CONFIG_IMX_WATCHDOG=y
>  CONFIG_OF_LIBFDT=y
> diff --git a/configs/display5_defconfig b/configs/display5_defconfig
> index 3b793f4500..1c52441802 100644
> --- a/configs/display5_defconfig
> +++ b/configs/display5_defconfig
> @@ -79,4 +79,5 @@ CONFIG_MII=y
>  CONFIG_MXC_UART=y
>  CONFIG_SPI=y
>  CONFIG_MXC_SPI=y
> +CONFIG_WATCHDOG_TIMEOUT_MSECS=15000
>  CONFIG_IMX_WATCHDOG=y
> diff --git a/configs/display5_factory_defconfig
> b/configs/display5_factory_defconfig
> index 0d9eed3a3e..1df7461a21 100644
> --- a/configs/display5_factory_defconfig
> +++ b/configs/display5_factory_defconfig
> @@ -86,5 +86,6 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x1b67
>  CONFIG_USB_GADGET_PRODUCT_NUM=0x4000
>  CONFIG_CI_UDC=y
>  CONFIG_USB_GADGET_DOWNLOAD=y
> +CONFIG_WATCHDOG_TIMEOUT_MSECS=15000
>  CONFIG_IMX_WATCHDOG=y
>  CONFIG_OF_LIBFDT=y
> diff --git a/configs/ge_bx50v3_defconfig
> b/configs/ge_bx50v3_defconfig
> index 8be881b939..cc056dc681 100644
> --- a/configs/ge_bx50v3_defconfig
> +++ b/configs/ge_bx50v3_defconfig
> @@ -60,5 +60,6 @@ CONFIG_DM_SPI=y
>  CONFIG_MXC_SPI=y
>  CONFIG_DM_VIDEO=y
>  CONFIG_VIDEO_IPUV3=y
> +CONFIG_WATCHDOG_TIMEOUT_MSECS=6000
>  CONFIG_IMX_WATCHDOG=y
>  # CONFIG_EFI_LOADER is not set
> diff --git a/configs/kp_imx6q_tpc_defconfig
> b/configs/kp_imx6q_tpc_defconfig
> index 0ca83cbfea..7e9d2fc747 100644
> --- a/configs/kp_imx6q_tpc_defconfig
> +++ b/configs/kp_imx6q_tpc_defconfig
> @@ -40,5 +40,6 @@ CONFIG_FEC_MXC=y
>  CONFIG_MII=y
>  CONFIG_IMX_THERMAL=y
>  CONFIG_USB=y
> +CONFIG_WATCHDOG_TIMEOUT_MSECS=6
>  CONFIG_IMX_WATCHDOG=y
>  CONFIG_OF_LIBFDT=y
> diff --git a/configs/m53menlo_defconfig b/configs/m53menlo_defconfig
> index 0e5fa01fde..6be311bf35 100644
> --- a/configs/m53menlo_defconfig
> +++ b/configs/m53menlo_defconfig
> @@ -69,6 +69,7 @@ CONFIG_USB_ETHER_SMSC95XX=y
>  CONFIG_VIDEO_IPUV3=y
> 

Re: [U-Boot] sf probe failed on Intel DNV-NS platform

[杜睿哲_Pegatron]

Hi Bin,

I have just tried 'make coreboot_defconfig' and I can boot into U-Boot from 
Coreboot now. But "sf probe" still failed with same error:
--
=> sf probe
Invalid bus 0 (err=-19)
Failed to initialize SPI flash at 0:0 (error -19)
--
I saw there was uclass 72,73,74 for spi by "dm uclass" command but I cannot see 
any spi information from "dm tree". Do you have any idea about this?

Thanks.
-Hilbert
This e-mail and its attachment may contain information that is confidential or 
privileged, and are solely for the use of the individual to whom this e-mail is 
addressed. If you are not the intended recipient or have received it 
accidentally, please immediately notify the sender by reply e-mail and destroy 
all copies of this email and its attachment. Please be advised that any 
unauthorized use, disclosure, distribution or copying of this email or its 
attachment is strictly prohibited.
本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: dts: Stratix10: Enable i2c

[Simon Goldschmidt]

On Thu, Jun 13, 2019 at 10:17 AM Ley Foon Tan  wrote:
>
> Enable i2c1 in Stratix 10 devkit.
>
> SOCFPGA_STRATIX10 # i2c bus
> Bus 0:  i2c@ffc02900
> SOCFPGA_STRATIX10 # i2c dev 0
> Setting bus to 0
> SOCFPGA_STRATIX10 # i2c probe
> Valid chip addresses: 14 4C 51 68 74
>
> Signed-off-by: Ley Foon Tan 

Reviewed-by: Simon Goldschmidt 

> ---
>  arch/arm/dts/socfpga_stratix10_socdk.dts | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/dts/socfpga_stratix10_socdk.dts 
> b/arch/arm/dts/socfpga_stratix10_socdk.dts
> index 2745050810..c5409df026 100755
> --- a/arch/arm/dts/socfpga_stratix10_socdk.dts
> +++ b/arch/arm/dts/socfpga_stratix10_socdk.dts
> @@ -9,6 +9,7 @@
> model = "SoCFPGA Stratix 10 SoCDK";
>
> aliases {
> +   i2c0 = 
> serial0 = 
> };
>
> @@ -77,6 +78,10 @@
> };
>  };
>
> + {
> +   status = "okay";
> +};
> +
>   {
> status = "okay";
> cap-sd-highspeed;
> --
> 2.19.0
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] fastboot: Fix slot names reported by getvar

[Eugeniu Rosca]

Hi Sam,

On Thu, Jun 13, 2019 at 12:49:45AM +0300, Sam Protsenko wrote:
> In commit [1] fastboot tool was changed w.r.t. new A/B specification [2],
> and now we should report slot names in "a" format instead of "_a".
> Latter is now considered legacy and we shouldn't rely on that anymore.

This looks like a change which advantages the users who are always on
the tip/HEAD of all relevant components (fastboot and U-Boot), but that
rarely happens in the industry. Suppliers and hardening vendors often
deliver obsoleted versions because they can't keep up with upstream
development. Can you please document the behavior of 'fastboot flash'
(and anything else relying on
'fastboot getvar (current-slot|slot-suffixes) in below scenarios:

A. fastboot >= [1] && U-Boot + this patch
B. fastboot >= [1] && U-Boot - this patch
C. fastboot <  [1] && U-Boot + this patch
D. fastboot <  [1] && U-Boot - this patch

Would it be possible to keep U-Boot backward-compatible, such that
regardless of the scenario enumerated above, 'fastboot flash' will
always succeed?

> [1] 
> https://android.googlesource.com/platform/system/core/+/8091947847d5e5130b09d2ac0a4bdc900f3b77c5
> [2] https://source.android.com/devices/tech/ota/ab/ab_implement#partitions

-- 
Best Regards,
Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC 2/6] efi: add RuntimeServicesSupported variable

[Heinrich Schuchardt]

On 6/13/19 11:17 AM, Heinrich Schuchardt wrote:
>
>
> On 6/13/19 9:06 AM, AKASHI Takahiro wrote:
>> On Thu, Jun 13, 2019 at 07:56:19AM +0200, Heinrich Schuchardt wrote:
>>>
>>>
>>> On 6/5/19 6:21 AM, AKASHI Takahiro wrote:
 This variable is defined in UEFI specification 2.8, section 8.1.
 Its value should be updated whenever we add any usable runtime services
 function.
>>>
>>> It is also required by the EBBR specification.
>>>

 Signed-off-by: AKASHI Takahiro 
 ---
  include/efi_api.h| 15 +++
  include/efi_loader.h |  3 +++
  lib/efi_loader/efi_runtime.c | 28 
  lib/efi_loader/efi_setup.c   |  5 +
  4 files changed, 51 insertions(+)

 diff --git a/include/efi_api.h b/include/efi_api.h
 index 65584dd2d82a..d7d95edd4dfc 100644
 --- a/include/efi_api.h
 +++ b/include/efi_api.h
 @@ -213,6 +213,21 @@ struct efi_capsule_header {
u32 capsule_image_size;
  };

 +#define EFI_RT_SUPPORTED_GET_TIME 0x0001
 +#define EFI_RT_SUPPORTED_SET_TIME 0x0002
 +#define EFI_RT_SUPPORTED_GET_WAKEUP_TIME  0x0004
 +#define EFI_RT_SUPPORTED_SET_WAKEUP_TIME  0x0008
 +#define EFI_RT_SUPPORTED_GET_VARIABLE 0x0010
 +#define EFI_RT_SUPPORTED_GET_NEXT_VARIABLE_NAME   0x0020
 +#define EFI_RT_SUPPORTED_SET_VARIABLE 0x0040
 +#define EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP  0x0080
 +#define EFI_RT_SUPPORTED_CONVERT_POINTER  0x0100
 +#define EFI_RT_SUPPORTED_GET_NEXT_HIGH_MONOTONIC_COUNT0x0200
 +#define EFI_RT_SUPPORTED_RESET_SYSTEM 0x0400
 +#define EFI_RT_SUPPORTED_UPDATE_CAPSULE   0x0800
 +#define EFI_RT_SUPPORTED_QUERY_CAPSULE_CAPABILITIES   0x1000
 +#define EFI_RT_SUPPORTED_QUERY_VARIABLE_INFO  0x2000
 +
  struct efi_runtime_services {
struct efi_table_hdr hdr;
efi_status_t (EFIAPI *get_time)(struct efi_time *time,
 diff --git a/include/efi_loader.h b/include/efi_loader.h
 index 23ce73226762..7bd8002e303e 100644
 --- a/include/efi_loader.h
 +++ b/include/efi_loader.h
 @@ -573,6 +573,9 @@ static inline int guidcmp(const efi_guid_t *g1, const 
 efi_guid_t *g2)
  #define __efi_runtime_data __attribute__ ((section (".data.efi_runtime")))
  #define __efi_runtime __attribute__ ((section (".text.efi_runtime")))

 +/* Indicate supported runtime services */
 +efi_status_t efi_init_runtime_supported(void);
 +
  /* Update CRC32 in table header */
  void __efi_runtime efi_update_table_header_crc32(struct efi_table_hdr 
 *table);

 diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
 index 60442cb21d37..cf202bb9ec07 100644
 --- a/lib/efi_loader/efi_runtime.c
 +++ b/lib/efi_loader/efi_runtime.c
 @@ -89,6 +89,34 @@ struct elf_rela {
   * handle a good number of runtime callbacks
   */

 +efi_status_t efi_init_runtime_supported(void)
 +{
 +  u16 efi_runtime_services_supported;
 +
 +  /*
 +   * This value must be synced with efi_runtime_detach_list
 +   * as well as efi_runtime_services.
 +   */
 +  efi_runtime_services_supported = EFI_RT_SUPPORTED_RESET_SYSTEM;
>>>
>>> This support is system dependent, e.g. on RK3288 systems it does not exist.
>>
>> efi_reset_system() is defined as a weak function and so
>> there is no easy way to determine whether this API is supported or not.
>>
 +#ifdef CONFIG_EFI_GET_TIME
 +  efi_runtime_services_supported |= EFI_RT_SUPPORTED_GET_TIME;
>>>
>>> We do not support this at runtime.
>>
>> Okay, I will drop it.
>>
 +#endif
 +#ifdef CONFIG_EFI_SET_TIME
 +  efi_runtime_services_supported |= EFI_RT_SUPPORTED_SET_TIME;
>>>
>>> We do not support this at runtime.
>>
>> ditto
>>
 +#endif
 +#ifdef CONFIG_EFI_RUNTIME_SET_VIRTUAL_ADDRESS_MAP
 +  efi_runtime_services_supported |=
 +  EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP;
>>>
>>> Our support is incomplete as we have not implemented ConvertPointer().
>>
>> Incomplete?
>> My patch#3 adds ConvertPointer().
>
> That is a later patch. So I did not consider it for this patch.
> Furthermore the implementation of ConvertPointer depends on
> CONFIG_EFI_RUNTIME_CONVERT_POINTER.

EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP and
EFI_RT_SUPPORTED_CONVERT_POINTER are separate values.

You are right in switching EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP on here.

Best regards

Heinrich

>>
>> -Takahiro Akashi
>>
>>> For unsupported services we will have to change the return value to
>>> EFI_UNSUPPORTED. But that will be a separate patch.
>>>
>>> Best regards
>>>
>>> Heinrich
>>>
 +#endif
 +
 +  return EFI_CALL(efi_set_variable(L"RuntimeServicesSupported",
 +   

Re: [U-Boot] [PATCH 1/1] fastboot: check if partition really exist in getvar_has_slot()

[Igor Opaniuk]

On Wed, Jun 12, 2019 at 12:54 PM Igor Opaniuk  wrote:
>
> From: Igor Opaniuk 
>
> Currently getvar_has_slot() invocation for "boot" and "system"
> partitions always returns affirmative response regardless the fact of
> existence of these partitions, which leads to impossibility to flash them
> on old non-A/B AOSP setups, where _a/_b suffixes aren't used:
>
> $ fastboot flash boot boot.img
> Sending 'boot__a' (11301 KB)OKAY [  0.451s]
> Writing 'boot__a'   FAILED (remote: 'cannot find partition')
> fastboot: error: Command failed
>
> Although partition layout is:
> -> part list mmc 0
> Partition Map for MMC device 0  --   Partition Type: EFI
>
> PartStart LBA   End LBA Name
> Attributes
> Type GUID
> Partition GUID
>   1 0x0800  0x000107ff  "boot"
> attrs:  0x
> type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
> guid:   ea2e2470-db4a-d646-b828-10167f736d63
>   2 0x00010800  0x000127ff  "environment"
> attrs:  0x
> type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
> guid:   10a819d2-6004-3d48-bd87-114e2a796db9
>   3 0x00012800  0x0001a7ff  "recovery"
> attrs:  0x
> type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
> guid:   9ea116e4-8a34-0c48-8cf5-2fe9480f56cd
>   4 0x0001a800  0x0031a7ff  "system"
> attrs:  0x
> ..
>
> This patch adds checks of existence for requested partitions
> on eMMC/NAND.
>
> Signed-off-by: Igor Opaniuk 
> ---
>  drivers/fastboot/fb_getvar.c | 37 
>  1 file changed, 33 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/fastboot/fb_getvar.c b/drivers/fastboot/fb_getvar.c
> index 4268628f5e..51e3f13060 100644
> --- a/drivers/fastboot/fb_getvar.c
> +++ b/drivers/fastboot/fb_getvar.c
> @@ -144,11 +144,40 @@ static void getvar_slot_suffixes(char *var_parameter, 
> char *response)
>
>  static void getvar_has_slot(char *part_name, char *response)
>  {
> -   if (part_name && (!strcmp(part_name, "boot") ||
> - !strcmp(part_name, "system")))
> -   fastboot_okay("yes", response);
> -   else
> +   char part_name_wslot[PART_NAME_LEN];
> +   int r;
> +
> +   if (!part_name) {
> fastboot_okay("no", response);
> +   return;
> +   }
> +
> +   /* Concatenate _a prefix and check if this partition exist */
> +   part_name_wslot[0] = '\0';
> +   strcat(part_name_wslot, part_name);
> +   strcat(part_name_wslot, "_a");
> +
> +#if CONFIG_IS_ENABLED(FASTBOOT_FLASH_MMC)
> +   struct blk_desc *dev_desc;
> +   disk_partition_t part_info;
> +
> +   r = fastboot_mmc_get_part_info(part_name_wslot, _desc, _info,
> +  response);
> +   if (r >= 0) {
> +   fastboot_okay("yes", response);
> +   return;
> +   }
> +#endif
> +#if CONFIG_IS_ENABLED(FASTBOOT_FLASH_NAND)
> +   struct part_info *part_info;
> +
> +   r = fastboot_nand_get_part_info(part_name_wslot, _info, 
> response);
> +   if (r >= 0) {
> +   fastboot_okay("yes", response);
> +   return;
> +   }
> +#endif
> +   fastboot_okay("no", response);
>  }
>
>  #if CONFIG_IS_ENABLED(FASTBOOT_FLASH_MMC)
> --
> 2.17.1
>

FYI: v2 patch was included in "Fix getvar "has-slot" and cleanup" [1]
patch-series and re-sent by Sam Protsenko .

[1] https://patchwork.ozlabs.org/cover/1114844/

-- 
Best regards - Freundliche Grüsse - Meilleures salutations

Igor Opaniuk

mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC 2/6] efi: add RuntimeServicesSupported variable

[Heinrich Schuchardt]

On 6/13/19 9:06 AM, AKASHI Takahiro wrote:
> On Thu, Jun 13, 2019 at 07:56:19AM +0200, Heinrich Schuchardt wrote:
>>
>>
>> On 6/5/19 6:21 AM, AKASHI Takahiro wrote:
>>> This variable is defined in UEFI specification 2.8, section 8.1.
>>> Its value should be updated whenever we add any usable runtime services
>>> function.
>>
>> It is also required by the EBBR specification.
>>
>>>
>>> Signed-off-by: AKASHI Takahiro 
>>> ---
>>>  include/efi_api.h| 15 +++
>>>  include/efi_loader.h |  3 +++
>>>  lib/efi_loader/efi_runtime.c | 28 
>>>  lib/efi_loader/efi_setup.c   |  5 +
>>>  4 files changed, 51 insertions(+)
>>>
>>> diff --git a/include/efi_api.h b/include/efi_api.h
>>> index 65584dd2d82a..d7d95edd4dfc 100644
>>> --- a/include/efi_api.h
>>> +++ b/include/efi_api.h
>>> @@ -213,6 +213,21 @@ struct efi_capsule_header {
>>> u32 capsule_image_size;
>>>  };
>>>
>>> +#define EFI_RT_SUPPORTED_GET_TIME  0x0001
>>> +#define EFI_RT_SUPPORTED_SET_TIME  0x0002
>>> +#define EFI_RT_SUPPORTED_GET_WAKEUP_TIME   0x0004
>>> +#define EFI_RT_SUPPORTED_SET_WAKEUP_TIME   0x0008
>>> +#define EFI_RT_SUPPORTED_GET_VARIABLE  0x0010
>>> +#define EFI_RT_SUPPORTED_GET_NEXT_VARIABLE_NAME0x0020
>>> +#define EFI_RT_SUPPORTED_SET_VARIABLE  0x0040
>>> +#define EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP   0x0080
>>> +#define EFI_RT_SUPPORTED_CONVERT_POINTER   0x0100
>>> +#define EFI_RT_SUPPORTED_GET_NEXT_HIGH_MONOTONIC_COUNT 0x0200
>>> +#define EFI_RT_SUPPORTED_RESET_SYSTEM  0x0400
>>> +#define EFI_RT_SUPPORTED_UPDATE_CAPSULE0x0800
>>> +#define EFI_RT_SUPPORTED_QUERY_CAPSULE_CAPABILITIES0x1000
>>> +#define EFI_RT_SUPPORTED_QUERY_VARIABLE_INFO   0x2000
>>> +
>>>  struct efi_runtime_services {
>>> struct efi_table_hdr hdr;
>>> efi_status_t (EFIAPI *get_time)(struct efi_time *time,
>>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>>> index 23ce73226762..7bd8002e303e 100644
>>> --- a/include/efi_loader.h
>>> +++ b/include/efi_loader.h
>>> @@ -573,6 +573,9 @@ static inline int guidcmp(const efi_guid_t *g1, const 
>>> efi_guid_t *g2)
>>>  #define __efi_runtime_data __attribute__ ((section (".data.efi_runtime")))
>>>  #define __efi_runtime __attribute__ ((section (".text.efi_runtime")))
>>>
>>> +/* Indicate supported runtime services */
>>> +efi_status_t efi_init_runtime_supported(void);
>>> +
>>>  /* Update CRC32 in table header */
>>>  void __efi_runtime efi_update_table_header_crc32(struct efi_table_hdr 
>>> *table);
>>>
>>> diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
>>> index 60442cb21d37..cf202bb9ec07 100644
>>> --- a/lib/efi_loader/efi_runtime.c
>>> +++ b/lib/efi_loader/efi_runtime.c
>>> @@ -89,6 +89,34 @@ struct elf_rela {
>>>   * handle a good number of runtime callbacks
>>>   */
>>>
>>> +efi_status_t efi_init_runtime_supported(void)
>>> +{
>>> +   u16 efi_runtime_services_supported;
>>> +
>>> +   /*
>>> +* This value must be synced with efi_runtime_detach_list
>>> +* as well as efi_runtime_services.
>>> +*/
>>> +   efi_runtime_services_supported = EFI_RT_SUPPORTED_RESET_SYSTEM;
>>
>> This support is system dependent, e.g. on RK3288 systems it does not exist.
>
> efi_reset_system() is defined as a weak function and so
> there is no easy way to determine whether this API is supported or not.
>
>>> +#ifdef CONFIG_EFI_GET_TIME
>>> +   efi_runtime_services_supported |= EFI_RT_SUPPORTED_GET_TIME;
>>
>> We do not support this at runtime.
>
> Okay, I will drop it.
>
>>> +#endif
>>> +#ifdef CONFIG_EFI_SET_TIME
>>> +   efi_runtime_services_supported |= EFI_RT_SUPPORTED_SET_TIME;
>>
>> We do not support this at runtime.
>
> ditto
>
>>> +#endif
>>> +#ifdef CONFIG_EFI_RUNTIME_SET_VIRTUAL_ADDRESS_MAP
>>> +   efi_runtime_services_supported |=
>>> +   EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP;
>>
>> Our support is incomplete as we have not implemented ConvertPointer().
>
> Incomplete?
> My patch#3 adds ConvertPointer().

That is a later patch. So I did not consider it for this patch.
Furthermore the implementation of ConvertPointer depends on
CONFIG_EFI_RUNTIME_CONVERT_POINTER.

Best regards

Heinrich

>
> -Takahiro Akashi
>
>> For unsupported services we will have to change the return value to
>> EFI_UNSUPPORTED. But that will be a separate patch.
>>
>> Best regards
>>
>> Heinrich
>>
>>> +#endif
>>> +
>>> +   return EFI_CALL(efi_set_variable(L"RuntimeServicesSupported",
>>> +_global_variable_guid,
>>> +EFI_VARIABLE_BOOTSERVICE_ACCESS |
>>> +EFI_VARIABLE_RUNTIME_ACCESS,
>>> +sizeof(efi_runtime_services_supported),
>>> +_runtime_services_supported));
>>> +}
>>> 

Re: [U-Boot] mvebu: reserve SRAM memory on Marvell Armada 3700/7K/8K

[Heinrich Schuchardt]

On 6/13/19 10:23 AM, Mark Kettenis wrote:
>> From: Heinrich Schuchardt 
>> Date: Thu, 13 Jun 2019 08:09:17 +0200
>>
>> On 6/13/19 7:48 AM, Stefan Roese wrote:
>>> Added Heinrich to Cc (and use Alex's new address)
>>>
>>> On 11.06.19 13:00, Patrick Wildt wrote:
 The ARM-TF and the optional OP-TEE use the memory region 0x400
 to 0x540 and should be reserved in the memory map, otherwise the
 OS might wrongly assume that it can use that memory area for itself.
 This has also been done in EDK2 [0].

 [0]
 https://github.com/tianocore/edk2-platforms/commit/bf1c4a2cf8024669d1748e78c7e417433f85707e


 Signed-off-by: Patrick Wildt 

 diff --git a/arch/arm/mach-mvebu/arm64-common.c
 b/arch/arm/mach-mvebu/arm64-common.c
 index aaf7b7c447..7572aad8c9 100644
 --- a/arch/arm/mach-mvebu/arm64-common.c
 +++ b/arch/arm/mach-mvebu/arm64-common.c
 @@ -14,6 +14,7 @@
   #include 
   #include 
   #include 
 +#include 
     DECLARE_GLOBAL_DATA_PTR;
   @@ -142,5 +143,11 @@ int arch_early_init_r(void)
   pci_init();
   #endif
   +#ifdef CONFIG_EFI_LOADER
 +    /* Reserve trusted SRAM section */
 +    efi_add_memory_map(0x0400, 0x0140 >> EFI_PAGE_SHIFT,
 +   EFI_RESERVED_MEMORY_TYPE, false);
 +#endif
>>
>> We already have a reservation via the device tree for a part of this
>> area [0x400-0x420[ in U-Boot and Linux:
>>
>> cf63dad014bae080445bccbf9cecbe05f2cbed45
>> arm64: dts: marvell: armada-ap806: reserve PSCI area
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.2-rc4=132ac39cffbcfed80ada38ef0fc6d34d95da7be6
>>
>> As the concerned boards can be booted not only via bootefi but also via
>> booti I suggest to update the device trees in Linux and U-Boot.
>
> But surely the EFI memory map should be correct and not include these
> reserved regions as "free".  Otherwise EFI boot services might hand
> out memory that will crash the system when accessed once we've
> switched out of EL3.  And I don't think the current code adjusts the
> EFI memory based on reservations in the device tree does it?
>

Function efi_carve_out_dt_rsv() in cmd/bootefi.c takes care of adding
reserved regions to the memory map.

Typically U-Boot is running at EL2. Should this not be the case the
bootefi command does the switch.

Best regards

Heinrich
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 1/2] regulator: bd71837: copy the bd71837 pmic

[Vaittinen, Matti]

Hello Jaehoon and Stefano,

On Wed, 2019-06-12 at 12:58 +0200, Stefano Babic wrote:
> Hi Maitti,
> 
> On 12/06/19 12:24, Vaittinen, Matti wrote:
> > Hello Stefano,
> > 
> > On Mon, 2019-06-10 at 11:40 +0200, sba...@denx.de wrote:
> > > > https://source.codeaurora.org/external/imx/uboot-imx
> > > > cherry picked, styled and merged commits:
> > > > - MLK-18387 pmic: Add pmic driver for BD71837: e9a3bec2e95a
> > > > - MLK-18590 pmic: bd71837: Change to use new fdt API:
> > > > acdc5c297a96
> > > > Signed-off-by: Ye Li 
> > > > Signed-off-by: Matti Vaittinen <
> > > > matti.vaitti...@fi.rohmeurope.com>
> > > > Reviewed-by: Simon Glass 
> > > 
> > > Applied to u-boot-imx, master, thanks !
> > 
> > Thanks for merging the patch :]
> > Do you think the 2/2 could also be taken in?
> > 
> 
> The thing is that I did not know why patches were assigned to me. 1/2
> was just defines and I decided to merge it instead of postpone it.
> 2/2
> is the driver, and should flow into power tree (maintainer is
> Jaehoon),
> even if this is thought for i.MX8. It is enough to me to get an ACK
> by
> Jaehoon to merge into u-boot-imx, if Jaehonn agrees.

Allright. The BD71837 and BD71847 are indeed intended to be used for
powering the i.MX8. I don't expect them to be used too much for other
SoCs - so that might be the reason the patches were assignrd to you in
first place. I know few people who are using the BD71837 and would be
happy seeing the driver in u-Boot ;) So Jaehoon, how do you see this?
Is the driver Ok to go in Stefano's tree? Should I take some action
like resending the 2/2?

Best Regards
Matti Vaittinen

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] mvebu: reserve SRAM memory on Marvell Armada 3700/7K/8K

[Mark Kettenis]

> From: Heinrich Schuchardt 
> Date: Thu, 13 Jun 2019 08:09:17 +0200
> 
> On 6/13/19 7:48 AM, Stefan Roese wrote:
> > Added Heinrich to Cc (and use Alex's new address)
> >
> > On 11.06.19 13:00, Patrick Wildt wrote:
> >> The ARM-TF and the optional OP-TEE use the memory region 0x400
> >> to 0x540 and should be reserved in the memory map, otherwise the
> >> OS might wrongly assume that it can use that memory area for itself.
> >> This has also been done in EDK2 [0].
> >>
> >> [0]
> >> https://github.com/tianocore/edk2-platforms/commit/bf1c4a2cf8024669d1748e78c7e417433f85707e
> >>
> >>
> >> Signed-off-by: Patrick Wildt 
> >>
> >> diff --git a/arch/arm/mach-mvebu/arm64-common.c
> >> b/arch/arm/mach-mvebu/arm64-common.c
> >> index aaf7b7c447..7572aad8c9 100644
> >> --- a/arch/arm/mach-mvebu/arm64-common.c
> >> +++ b/arch/arm/mach-mvebu/arm64-common.c
> >> @@ -14,6 +14,7 @@
> >>   #include 
> >>   #include 
> >>   #include 
> >> +#include 
> >>     DECLARE_GLOBAL_DATA_PTR;
> >>   @@ -142,5 +143,11 @@ int arch_early_init_r(void)
> >>   pci_init();
> >>   #endif
> >>   +#ifdef CONFIG_EFI_LOADER
> >> +    /* Reserve trusted SRAM section */
> >> +    efi_add_memory_map(0x0400, 0x0140 >> EFI_PAGE_SHIFT,
> >> +   EFI_RESERVED_MEMORY_TYPE, false);
> >> +#endif
> 
> We already have a reservation via the device tree for a part of this
> area [0x400-0x420[ in U-Boot and Linux:
> 
> cf63dad014bae080445bccbf9cecbe05f2cbed45
> arm64: dts: marvell: armada-ap806: reserve PSCI area
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.2-rc4=132ac39cffbcfed80ada38ef0fc6d34d95da7be6
> 
> As the concerned boards can be booted not only via bootefi but also via
> booti I suggest to update the device trees in Linux and U-Boot.

But surely the EFI memory map should be correct and not include these
reserved regions as "free".  Otherwise EFI boot services might hand
out memory that will crash the system when accessed once we've
switched out of EL3.  And I don't think the current code adjusts the
EFI memory based on reservations in the device tree does it?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] arm: dts: Stratix10: Enable i2c

[Ley Foon Tan]

Enable i2c1 in Stratix 10 devkit.

SOCFPGA_STRATIX10 # i2c bus
Bus 0:  i2c@ffc02900
SOCFPGA_STRATIX10 # i2c dev 0
Setting bus to 0
SOCFPGA_STRATIX10 # i2c probe
Valid chip addresses: 14 4C 51 68 74

Signed-off-by: Ley Foon Tan 
---
 arch/arm/dts/socfpga_stratix10_socdk.dts | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/dts/socfpga_stratix10_socdk.dts 
b/arch/arm/dts/socfpga_stratix10_socdk.dts
index 2745050810..c5409df026 100755
--- a/arch/arm/dts/socfpga_stratix10_socdk.dts
+++ b/arch/arm/dts/socfpga_stratix10_socdk.dts
@@ -9,6 +9,7 @@
model = "SoCFPGA Stratix 10 SoCDK";
 
aliases {
+   i2c0 = 
serial0 = 
};
 
@@ -77,6 +78,10 @@
};
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
cap-sd-highspeed;
-- 
2.19.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/3] fastboot: Use const qualifier for char *part_name

[Igor Opaniuk]

On Thu, Jun 13, 2019 at 12:14 AM Sam Protsenko
 wrote:
>
> In fastboot_*_get_part_info() functions we can use stronger typing by
> expecting const strings.
>
> Signed-off-by: Sam Protsenko 
> ---
>  drivers/fastboot/fb_mmc.c  | 3 ++-
>  drivers/fastboot/fb_nand.c | 4 ++--
>  include/fb_mmc.h   | 3 ++-
>  include/fb_nand.h  | 4 ++--
>  4 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/fastboot/fb_mmc.c b/drivers/fastboot/fb_mmc.c
> index 90ca81da9b..0a335db3a6 100644
> --- a/drivers/fastboot/fb_mmc.c
> +++ b/drivers/fastboot/fb_mmc.c
> @@ -298,7 +298,8 @@ static int fb_mmc_update_zimage(struct blk_desc *dev_desc,
>   * @part_info: Pointer to returned disk_partition_t
>   * @response: Pointer to fastboot response buffer
>   */
> -int fastboot_mmc_get_part_info(char *part_name, struct blk_desc **dev_desc,
> +int fastboot_mmc_get_part_info(const char *part_name,
> +  struct blk_desc **dev_desc,
>disk_partition_t *part_info, char *response)
>  {
> int r;
> diff --git a/drivers/fastboot/fb_nand.c b/drivers/fastboot/fb_nand.c
> index 526bc12307..6756ea769f 100644
> --- a/drivers/fastboot/fb_nand.c
> +++ b/drivers/fastboot/fb_nand.c
> @@ -152,8 +152,8 @@ static lbaint_t fb_nand_sparse_reserve(struct 
> sparse_storage *info,
>   * @part_info: Pointer to returned part_info pointer
>   * @response: Pointer to fastboot response buffer
>   */
> -int fastboot_nand_get_part_info(char *part_name, struct part_info 
> **part_info,
> -   char *response)
> +int fastboot_nand_get_part_info(const char *part_name,
> +   struct part_info **part_info, char *response)
>  {
> struct mtd_info *mtd = NULL;
>
> diff --git a/include/fb_mmc.h b/include/fb_mmc.h
> index fd5db9eac8..95db001bee 100644
> --- a/include/fb_mmc.h
> +++ b/include/fb_mmc.h
> @@ -14,7 +14,8 @@
>   * @part_info: Pointer to returned disk_partition_t
>   * @response: Pointer to fastboot response buffer
>   */
> -int fastboot_mmc_get_part_info(char *part_name, struct blk_desc **dev_desc,
> +int fastboot_mmc_get_part_info(const char *part_name,
> +  struct blk_desc **dev_desc,
>disk_partition_t *part_info, char *response);
>
>  /**
> diff --git a/include/fb_nand.h b/include/fb_nand.h
> index 08ab0e28a6..6d7999f262 100644
> --- a/include/fb_nand.h
> +++ b/include/fb_nand.h
> @@ -16,8 +16,8 @@
>   * @part_info: Pointer to returned part_info pointer
>   * @response: Pointer to fastboot response buffer
>   */
> -int fastboot_nand_get_part_info(char *part_name, struct part_info 
> **part_info,
> -   char *response);
> +int fastboot_nand_get_part_info(const char *part_name,
> +   struct part_info **part_info, char *response);
>
>  /**
>   * fastboot_nand_flash_write() - Write image to NAND for fastboot
> --
> 2.20.1
>

Reviewed-by: Igor Opaniuk 

-- 
Best regards - Freundliche Grüsse - Meilleures salutations

Igor Opaniuk

mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/3] fastboot: getvar: Refactor fastboot_*_get_part_info() usage

[Igor Opaniuk]

Hi Sam,

On Thu, Jun 13, 2019 at 12:14 AM Sam Protsenko
 wrote:
>
> Extract fastboot_*_get_part_info() usage for MMC and NAND into
> getvar_get_part_info() function, as it will be needed further in other
> functions. This way we can avoid code duplication and mess with
> preprocessor directives across all points of usage.
>
> Signed-off-by: Sam Protsenko 
> ---
>  drivers/fastboot/fb_getvar.c | 52 +---
>  1 file changed, 36 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/fastboot/fb_getvar.c b/drivers/fastboot/fb_getvar.c
> index 4268628f5e..b23880089e 100644
> --- a/drivers/fastboot/fb_getvar.c
> +++ b/drivers/fastboot/fb_getvar.c
> @@ -81,6 +81,41 @@ static const struct {
> }
>  };
>
> +#if CONFIG_IS_ENABLED(FASTBOOT_FLASH)
> +/**
> + * Universal function to get partition number and size.
> + *
> + * @param[in] part_name Info for which partition name to look for
> + * @param[in,out] response Pointer to fastboot response buffer
> + * @param[out] size If not NULL, will contain partition size (in blocks)
> + * @return Partition number or negative value on error
> + */
> +static int getvar_get_part_info(const char *part_name, char *response,
> +   size_t *size)
> +{
> +   int r;
> +# if CONFIG_IS_ENABLED(FASTBOOT_FLASH_MMC)
> +   struct blk_desc *dev_desc;
> +   disk_partition_t part_info;
> +
> +   r = fastboot_mmc_get_part_info(part_name, _desc, _info,
> +  response);
> +   if (r >= 0 && size)
> +   *size = part_info.size;
> +# elif CONFIG_IS_ENABLED(FASTBOOT_FLASH_NAND)
> +   struct part_info *part_info;
> +
> +   r = fastboot_nand_get_part_info(part_name, _info, response);
> +   if (r >= 0 && size)
> +   *size = part_info->size;
> +# else
> +   r = -ENODEV;
> +# endif
> +
> +   return r;
> +}
> +#endif
> +
>  static void getvar_version(char *var_parameter, char *response)
>  {
> fastboot_okay(FASTBOOT_VERSION, response);
> @@ -176,22 +211,7 @@ static void getvar_partition_size(char *part_name, char 
> *response)
> int r;
> size_t size;
>
> -#if CONFIG_IS_ENABLED(FASTBOOT_FLASH_MMC)
> -   struct blk_desc *dev_desc;
> -   disk_partition_t part_info;
> -
> -   r = fastboot_mmc_get_part_info(part_name, _desc, _info,
> -  response);
> -   if (r >= 0)
> -   size = part_info.size;
> -#endif
> -#if CONFIG_IS_ENABLED(FASTBOOT_FLASH_NAND)
> -   struct part_info *part_info;
> -
> -   r = fastboot_nand_get_part_info(part_name, _info, response);
> -   if (r >= 0)
> -   size = part_info->size;
> -#endif
> +   r = getvar_get_part_info(part_name, response, );
> if (r >= 0)
> fastboot_response("OKAY", response, "0x%016zx", size);
>  }
> --
> 2.20.1
>

Reviewed-by: Igor Opaniuk 

-- 
Best regards - Freundliche Grüsse - Meilleures salutations

Igor Opaniuk

mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 2/2] armv8: fsl-layerscape: Increase mmc read size for secure-boot headers

[Udit Agarwal]

Maximum size of secure boot header to be read from
MMC is 12KB which spans across 0x20 blocks.

Hence increase the mmc read size for secure boot
headers from MMC to 0x20 blocks.

Signed-off-by: Udit Agarwal 
---
Changes in V2:
Modifications in the subject line and commit
message.

 include/configs/ls1088ardb.h | 18 +-
 include/configs/ls2080ardb.h |  8 
 include/configs/lx2160a_common.h |  8 
 3 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/include/configs/ls1088ardb.h b/include/configs/ls1088ardb.h
index 322adb530a..7500c3d3c6 100644
--- a/include/configs/ls1088ardb.h
+++ b/include/configs/ls1088ardb.h
@@ -320,8 +320,8 @@
"mmcinfo;mmc read 0x8000 0x5000 0x800;" \
"mmc read 0x8010 0x7000 0x800;" \
"env exists secureboot && " \
-   "mmc read 0x8070 0x3800 0x10 && "   \
-   "mmc read 0x8074 0x3A00 0x10 && "   \
+   "mmc read 0x8070 0x3800 0x20 && "   \
+   "mmc read 0x8074 0x3A00 0x20 && "   \
"esbc_validate 0x8070 && "  \
"esbc_validate 0x8074 ;"\
"fsl_mc start mc 0x8000 0x8010\0"
@@ -342,8 +342,8 @@
"mcinitcmd=mmcinfo;mmc read 0x8000 0x5000 0x800;"   \
"mmc read 0x8010 0x7000 0x800;" \
"env exists secureboot && " \
-   "mmc read 0x8070 0x3800 0x10 && "   \
-   "mmc read 0x8074 0x3A00 0x10 && "   \
+   "mmc read 0x8070 0x3800 0x20 && "   \
+   "mmc read 0x8074 0x3A00 0x20 && "   \
"esbc_validate 0x8070 && "  \
"esbc_validate 0x8074 ;"\
"fsl_mc start mc 0x8000 0x8010\0"   \
@@ -377,7 +377,7 @@
"load_addr=0xa000\0"\
"kernel_size=0x280\0"   \
"kernel_size_sd=0x14000\0"  \
-   "kernelhdr_size_sd=0x10\0"  \
+   "kernelhdr_size_sd=0x20\0"  \
QSPI_MC_INIT_CMD\
"mcmemsize=0x7000\0"\
BOOTENV \
@@ -446,7 +446,7 @@
"load_addr=0xa000\0"\
"kernel_size=0x280\0"   \
"kernel_size_sd=0x14000\0"  \
-   "kernelhdr_size_sd=0x10\0"  \
+   "kernelhdr_size_sd=0x20\0"  \
MC_INIT_CMD \
BOOTENV \
"boot_scripts=ls1088ardb_boot.scr\0"\
@@ -493,7 +493,7 @@
 #undef CONFIG_BOOTCOMMAND
 #ifdef CONFIG_TFABOOT
 #define QSPI_NOR_BOOTCOMMAND   \
-   "sf read 0x80001000 0xd0 0x10;" \
+   "sf read 0x80001000 0xd0 0x10;" \
"env exists mcinitcmd && env exists secureboot "\
" && sf read 0x8078 0x78 0x10 " \
"&& esbc_validate 0x8078;env exists mcinitcmd " \
@@ -504,7 +504,7 @@
"env exists mcinitcmd && mmcinfo; " \
"mmc read 0x80001000 0x6800 0x800; "\
"env exists mcinitcmd && env exists secureboot "\
-   " && mmc read 0x8078 0x3C00 0x10 "  \
+   " && mmc read 0x8078 0x3C00 0x20 "  \
"&& esbc_validate 0x8078;env exists mcinitcmd " \
"&& fsl_mc lazyapply dpl 0x80001000;"   \
"run distro_bootcmd;run sd_bootcmd;"\
@@ -527,7 +527,7 @@
"env exists mcinitcmd && mmcinfo; " \
"mmc read 0x80001000 0x6800 0x800; "\
"env exists mcinitcmd && env exists secureboot "\
-   " && mmc read 0x8078 0x3C00 0x10 "  \
+   " && mmc read 0x8078 0x3C00 0x20 "  \
"&& esbc_validate 0x8078;env exists mcinitcmd " \
"&& fsl_mc lazyapply dpl 0x80001000;"   \
"run distro_bootcmd;run sd_bootcmd;"\
diff --git a/include/configs/ls2080ardb.h b/include/configs/ls2080ardb.h
index 2e8a8bbdb7..cb80f12c32 100644
--- a/include/configs/ls2080ardb.h
+++ b/include/configs/ls2080ardb.h
@@ -345,8 +345,8 @@ unsigned long get_board_sys_clk(void);
"mmcinfo;mmc read 0x8000 0x5000 0x800;" \
"mmc read 0x8010 0x7000 0x800;" \
"env exists secureboot && " \
-   "mmc read 0x8070 0x3800 0x10 && "   \
-   "mmc read 0x8074 0x3A00 0x10 && "   \
+   "mmc read 0x8070 0x3800 0x20 && "   \
+   "mmc read 0x8074 0x3A00 0x20 && "   \
"esbc_validate 0x8070 && "  

[U-Boot] [PATCH v2 1/2] configs: fsl-layerscape: secure_boot: Enable setexpr command.

[Udit Agarwal]

setexpr command is used while running secure boot (chain of trust with
confidentiality) feature.

So, Enable CONFIG_CMD_SETEXPR to enable setexpr command.

Signed-off-by: Udit Agarwal 
---
Changes in V2:
Corrects commit message.

 configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig | 1 +
 configs/ls1012aqds_tfa_SECURE_BOOT_defconfig  | 2 +-
 configs/ls1012ardb_tfa_SECURE_BOOT_defconfig  | 2 +-
 configs/ls1028aqds_tfa_SECURE_BOOT_defconfig  | 1 +
 configs/ls1028ardb_tfa_SECURE_BOOT_defconfig  | 1 +
 configs/ls1043aqds_tfa_SECURE_BOOT_defconfig  | 1 +
 configs/ls1043ardb_tfa_SECURE_BOOT_defconfig  | 1 +
 configs/ls1046afrwy_tfa_SECURE_BOOT_defconfig | 1 +
 configs/ls1046aqds_tfa_SECURE_BOOT_defconfig  | 1 +
 configs/ls1046ardb_tfa_SECURE_BOOT_defconfig  | 1 +
 configs/ls1088ardb_tfa_SECURE_BOOT_defconfig  | 2 +-
 configs/ls2088ardb_tfa_SECURE_BOOT_defconfig  | 2 +-
 configs/lx2160aqds_tfa_SECURE_BOOT_defconfig  | 1 +
 configs/lx2160ardb_tfa_SECURE_BOOT_defconfig  | 1 +
 14 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig 
b/configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig
index 02f5dedfa2..bf68873466 100644
--- a/configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig
+++ b/configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig
@@ -50,4 +50,5 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_RSA=y
+CONFIG_CMD_SETEXPR=y
 CONFIG_RSA_SOFTWARE_EXP=y
diff --git a/configs/ls1012aqds_tfa_SECURE_BOOT_defconfig 
b/configs/ls1012aqds_tfa_SECURE_BOOT_defconfig
index 9a6139e58c..80fb0c473c 100644
--- a/configs/ls1012aqds_tfa_SECURE_BOOT_defconfig
+++ b/configs/ls1012aqds_tfa_SECURE_BOOT_defconfig
@@ -30,7 +30,7 @@ CONFIG_CMD_SF=y
 CONFIG_CMD_SPI=y
 CONFIG_DEFAULT_SPI_BUS=1
 CONFIG_CMD_USB=y
-# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_SETEXPR=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_DATE=y
 CONFIG_OF_CONTROL=y
diff --git a/configs/ls1012ardb_tfa_SECURE_BOOT_defconfig 
b/configs/ls1012ardb_tfa_SECURE_BOOT_defconfig
index 5e524e74c1..f8b7585802 100644
--- a/configs/ls1012ardb_tfa_SECURE_BOOT_defconfig
+++ b/configs/ls1012ardb_tfa_SECURE_BOOT_defconfig
@@ -27,7 +27,7 @@ CONFIG_CMD_MMC=y
 CONFIG_CMD_PCI=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_USB=y
-# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_SETEXPR=y
 CONFIG_CMD_CACHE=y
 CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1012a-rdb"
diff --git a/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig 
b/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig
index 7cd2f59d7b..b1d2c6bb3e 100644
--- a/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig
+++ b/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig
@@ -59,4 +59,5 @@ CONFIG_USB_XHCI_DWC3=y
 CONFIG_WDT=y
 CONFIG_WDT_SP805=y
 CONFIG_RSA=y
+CONFIG_CMD_SETEXPR=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig 
b/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig
index 3432f90087..3cd6cb56bf 100644
--- a/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig
+++ b/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig
@@ -59,4 +59,5 @@ CONFIG_USB_XHCI_DWC3=y
 CONFIG_WDT=y
 CONFIG_WDT_SP805=y
 CONFIG_RSA=y
+CONFIG_CMD_SETEXPR=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/ls1043aqds_tfa_SECURE_BOOT_defconfig 
b/configs/ls1043aqds_tfa_SECURE_BOOT_defconfig
index 8964042fcc..919d8b0e0f 100644
--- a/configs/ls1043aqds_tfa_SECURE_BOOT_defconfig
+++ b/configs/ls1043aqds_tfa_SECURE_BOOT_defconfig
@@ -58,4 +58,5 @@ CONFIG_USB_XHCI_DWC3=y
 CONFIG_RSA=y
 CONFIG_SPL_RSA=y
 CONFIG_RSA_SOFTWARE_EXP=y
+CONFIG_CMD_SETEXPR=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/ls1043ardb_tfa_SECURE_BOOT_defconfig 
b/configs/ls1043ardb_tfa_SECURE_BOOT_defconfig
index a481cb104d..637febf9a5 100644
--- a/configs/ls1043ardb_tfa_SECURE_BOOT_defconfig
+++ b/configs/ls1043ardb_tfa_SECURE_BOOT_defconfig
@@ -52,3 +52,4 @@ CONFIG_RSA=y
 CONFIG_SPL_RSA=y
 CONFIG_RSA_SOFTWARE_EXP=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_CMD_SETEXPR=y
diff --git a/configs/ls1046afrwy_tfa_SECURE_BOOT_defconfig 
b/configs/ls1046afrwy_tfa_SECURE_BOOT_defconfig
index e5522d8629..116c9a26c7 100644
--- a/configs/ls1046afrwy_tfa_SECURE_BOOT_defconfig
+++ b/configs/ls1046afrwy_tfa_SECURE_BOOT_defconfig
@@ -53,3 +53,4 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_RSA=y
+CONFIG_CMD_SETEXPR=y
diff --git a/configs/ls1046aqds_tfa_SECURE_BOOT_defconfig 
b/configs/ls1046aqds_tfa_SECURE_BOOT_defconfig
index 715d07934c..69e39e7207 100644
--- a/configs/ls1046aqds_tfa_SECURE_BOOT_defconfig
+++ b/configs/ls1046aqds_tfa_SECURE_BOOT_defconfig
@@ -59,3 +59,4 @@ CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_RSA=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_CMD_SETEXPR=y
diff --git a/configs/ls1046ardb_tfa_SECURE_BOOT_defconfig 
b/configs/ls1046ardb_tfa_SECURE_BOOT_defconfig
index 3244d5659a..8cd246a63e 100644
--- a/configs/ls1046ardb_tfa_SECURE_BOOT_defconfig
+++ b/configs/ls1046ardb_tfa_SECURE_BOOT_defconfig
@@ -52,3 +52,4 @@ CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_RSA=y
 

Re: [U-Boot] [PATCH v5 1/2] arm: i.MX: Add CMD_NANDBCB Kconfig entry

[Shyam Saini]

> >
> > Add Kconfig entry for CMD_NANDBCB, and default y on i.MX6
> > platform with NAND_MXS defined.
> >
> > Reviewed-by: Stefano Babic 
> > Signed-off-by: Jagan Teki 
> > Signed-off-by: Shyam Saini 
> > ---
> > Hi,
> >
> > This patch series is based on feedback gathered from this [1] discussion
> > and [2] patch submitted by Stefan.
> >
> > [1] https://patchwork.ozlabs.org/patch/870467/
> > [2] https://patchwork.ozlabs.org/patch/897222/
> >
> > Changes for v5:
> > - New patch
> > Changes for v4:
> > - No change
> > Changes for v3:
> > - Fixed Typo 'seprate'
> > Changes for v2:
> > - New patch
> >  arch/arm/mach-imx/Kconfig | 11 +++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> > index ec09ef240f..5dd286f9a7 100644
> > --- a/arch/arm/mach-imx/Kconfig
> > +++ b/arch/arm/mach-imx/Kconfig
> > @@ -71,6 +71,17 @@ config CMD_HDMIDETECT
> >   This enables the 'hdmidet' command which detects if an HDMI 
> > monitor
> >   is connected.
> >
> > +config CMD_NANDBCB
> > +   bool "i.MX6 NAND Boot Control Block(BCB) command"
> > +   depends on NAND && CMD_MTDPARTS
> > +   default y if ARCH_MX6 && NAND_MXS
> > +   help
> > + Unlike normal 'nand write/erase' commands, this command update
> > + Boot Control Block(BCB) for i.MX6 platform NAND IP's.
> > +
> > + This is similar to kobs-ng, which is used in Linux as separate
> > + rootfs package.
> > +
>
> This patch structuring is not in proper order.
>
> 01: Add support for nandbcb (would have all required code, kconfig,
> makefile changes)
> 02: Enable it on board config.
> 03: Readme, about the steps.

okay, will fix this in next version.

Thanks!!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] rtl8169: use dm_pci_map_bar

[Bin Meng]

Hi Stefan,

On Thu, Jun 13, 2019 at 1:40 PM Stefan Roese  wrote:
>
> Added Bin, Joe and Thierry to Cc
>
> On 11.06.19 13:15, Patrick Wildt wrote:
> > Hi,
> >
> > I have an rtl8169 on a macchiatobin and that card has a 64-bit
> > memory address.  The current code only reads a single word, which
> > means it can only support a 32-bit address.  By using dm_pci_map_bar
> > we don't need to manually parse the register, we can just have it do
> > its job.
> >
> > I'm not sure though if this works for all devices since the previous
> > version had an explicit check for the device.
> >
> > Patrick
> >
> > Signed-off-by: Patrick Wildt 
> >
> > diff --git a/drivers/net/rtl8169.c b/drivers/net/rtl8169.c
> > index 521e5909a2..f1d2ade253 100644
> > --- a/drivers/net/rtl8169.c
> > +++ b/drivers/net/rtl8169.c
> > @@ -1182,22 +1182,11 @@ static int rtl8169_eth_probe(struct udevice *dev)
> >   struct pci_child_platdata *pplat = dev_get_parent_platdata(dev);
> >   struct rtl8169_private *priv = dev_get_priv(dev);
> >   struct eth_pdata *plat = dev_get_platdata(dev);
> > - u32 iobase;
> > - int region;
> >   int ret;
> >
> > - debug("rtl8169: REALTEK RTL8169 @0x%x\n", iobase);
> > - switch (pplat->device) {
> > - case 0x8168:
> > - region = 2;
> > - break;
> > - default:
> > - region = 1;
> > - break;
> > - }
> > - dm_pci_read_config32(dev, PCI_BASE_ADDRESS_0 + region * 4, );
> > - iobase &= ~0xf;
> > - priv->iobase = (int)dm_pci_mem_to_phys(dev, iobase);
> > + priv->iobase = dm_pci_map_bar(dev, PCI_BASE_ADDRESS_2,
> > +   PCI_REGION_MEM);
> > + printf("rtl8169: REALTEK RTL8169 @0x%x\n", priv->iobase);
> >
> >   ret = rtl_init(priv->iobase, dev->name, plat->enetaddr);
> >   if (ret < 0) {
>
> Bin, Joe, Thierry,
>
> do you have any comments on this patch? Moving unconditionally to one
> BAR instead of BAR1/2 depending on the chip version seems a bit
> "brave".

Agreed that blinding setting one BAR for the iobase is not a good idea.

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] pico-imx7d: Enable DM_USB

[Jun Nie]

Joris Offouga  于2019年6月11日周二 下午8:09写道：
>
> This patch enable usb support with device-tree
>
> Signed-off-by: Joris Offouga 
> ---
>  arch/arm/dts/imx7d-pico.dtsi |  2 ++
>  board/technexion/pico-imx7d/pico-imx7d.c | 13 -
>  configs/pico-hobbit-imx7d_defconfig  |  1 +
>  configs/pico-imx7d_bl33_defconfig|  1 +
>  configs/pico-imx7d_defconfig |  1 +
>  configs/pico-pi-imx7d_defconfig  |  1 +
>  6 files changed, 6 insertions(+), 13 deletions(-)
>

Reviewed-by: Jun Nie 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC 2/6] efi: add RuntimeServicesSupported variable

[AKASHI Takahiro]

On Thu, Jun 13, 2019 at 07:56:19AM +0200, Heinrich Schuchardt wrote:
> 
> 
> On 6/5/19 6:21 AM, AKASHI Takahiro wrote:
> > This variable is defined in UEFI specification 2.8, section 8.1.
> > Its value should be updated whenever we add any usable runtime services
> > function.
> 
> It is also required by the EBBR specification.
> 
> >
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  include/efi_api.h| 15 +++
> >  include/efi_loader.h |  3 +++
> >  lib/efi_loader/efi_runtime.c | 28 
> >  lib/efi_loader/efi_setup.c   |  5 +
> >  4 files changed, 51 insertions(+)
> >
> > diff --git a/include/efi_api.h b/include/efi_api.h
> > index 65584dd2d82a..d7d95edd4dfc 100644
> > --- a/include/efi_api.h
> > +++ b/include/efi_api.h
> > @@ -213,6 +213,21 @@ struct efi_capsule_header {
> > u32 capsule_image_size;
> >  };
> >
> > +#define EFI_RT_SUPPORTED_GET_TIME  0x0001
> > +#define EFI_RT_SUPPORTED_SET_TIME  0x0002
> > +#define EFI_RT_SUPPORTED_GET_WAKEUP_TIME   0x0004
> > +#define EFI_RT_SUPPORTED_SET_WAKEUP_TIME   0x0008
> > +#define EFI_RT_SUPPORTED_GET_VARIABLE  0x0010
> > +#define EFI_RT_SUPPORTED_GET_NEXT_VARIABLE_NAME0x0020
> > +#define EFI_RT_SUPPORTED_SET_VARIABLE  0x0040
> > +#define EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP   0x0080
> > +#define EFI_RT_SUPPORTED_CONVERT_POINTER   0x0100
> > +#define EFI_RT_SUPPORTED_GET_NEXT_HIGH_MONOTONIC_COUNT 0x0200
> > +#define EFI_RT_SUPPORTED_RESET_SYSTEM  0x0400
> > +#define EFI_RT_SUPPORTED_UPDATE_CAPSULE0x0800
> > +#define EFI_RT_SUPPORTED_QUERY_CAPSULE_CAPABILITIES0x1000
> > +#define EFI_RT_SUPPORTED_QUERY_VARIABLE_INFO   0x2000
> > +
> >  struct efi_runtime_services {
> > struct efi_table_hdr hdr;
> > efi_status_t (EFIAPI *get_time)(struct efi_time *time,
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index 23ce73226762..7bd8002e303e 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -573,6 +573,9 @@ static inline int guidcmp(const efi_guid_t *g1, const 
> > efi_guid_t *g2)
> >  #define __efi_runtime_data __attribute__ ((section (".data.efi_runtime")))
> >  #define __efi_runtime __attribute__ ((section (".text.efi_runtime")))
> >
> > +/* Indicate supported runtime services */
> > +efi_status_t efi_init_runtime_supported(void);
> > +
> >  /* Update CRC32 in table header */
> >  void __efi_runtime efi_update_table_header_crc32(struct efi_table_hdr 
> > *table);
> >
> > diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
> > index 60442cb21d37..cf202bb9ec07 100644
> > --- a/lib/efi_loader/efi_runtime.c
> > +++ b/lib/efi_loader/efi_runtime.c
> > @@ -89,6 +89,34 @@ struct elf_rela {
> >   * handle a good number of runtime callbacks
> >   */
> >
> > +efi_status_t efi_init_runtime_supported(void)
> > +{
> > +   u16 efi_runtime_services_supported;
> > +
> > +   /*
> > +* This value must be synced with efi_runtime_detach_list
> > +* as well as efi_runtime_services.
> > +*/
> > +   efi_runtime_services_supported = EFI_RT_SUPPORTED_RESET_SYSTEM;
> 
> This support is system dependent, e.g. on RK3288 systems it does not exist.

efi_reset_system() is defined as a weak function and so
there is no easy way to determine whether this API is supported or not.

> > +#ifdef CONFIG_EFI_GET_TIME
> > +   efi_runtime_services_supported |= EFI_RT_SUPPORTED_GET_TIME;
> 
> We do not support this at runtime.

Okay, I will drop it.

> > +#endif
> > +#ifdef CONFIG_EFI_SET_TIME
> > +   efi_runtime_services_supported |= EFI_RT_SUPPORTED_SET_TIME;
> 
> We do not support this at runtime.

ditto

> > +#endif
> > +#ifdef CONFIG_EFI_RUNTIME_SET_VIRTUAL_ADDRESS_MAP
> > +   efi_runtime_services_supported |=
> > +   EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP;
> 
> Our support is incomplete as we have not implemented ConvertPointer().

Incomplete?
My patch#3 adds ConvertPointer().

-Takahiro Akashi

> For unsupported services we will have to change the return value to
> EFI_UNSUPPORTED. But that will be a separate patch.
> 
> Best regards
> 
> Heinrich
> 
> > +#endif
> > +
> > +   return EFI_CALL(efi_set_variable(L"RuntimeServicesSupported",
> > +_global_variable_guid,
> > +EFI_VARIABLE_BOOTSERVICE_ACCESS |
> > +EFI_VARIABLE_RUNTIME_ACCESS,
> > +sizeof(efi_runtime_services_supported),
> > +_runtime_services_supported));
> > +}
> > +
> >  /**
> >   * efi_update_table_header_crc32() - Update crc32 in table header
> >   *
> > diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
> > index 45d6aca051f3..75fa344060d5 100644
> > --- a/lib/efi_loader/efi_setup.c
> > +++ 

Re: [U-Boot] [PATCH v3 0/6] rockchip: rk3399: Make u-boot.itb as BUILD_TARGET

[Jagan Teki]

Hi Kever,

On Wed, May 8, 2019 at 12:23 AM Jagan Teki  wrote:
>
> RK3399 TPL changes are merged recently which I was thinking
> of waiting for next MW. so this series skip binman changes
> from previous version[1] and have only BUILD_TARGET changes.
>
> BINMAN changes would need another rework, where we need to consider
> the TPL image as well and that would send separately.
>
> CHanges for v3:
> - skip binman changes
> - rebase on u-boot-rockchip/master
>
> [1] https://patchwork.ozlabs.org/cover/1092198/
>
> Jagan Teki (6):
>   Makefile: clean image.map
>   Makefile: clean bl31_*.bin
>   travis.yml: Add pyelftools install entry
>   rockchip: rk3399: Get bl31.elf via BL31
>   board: puma: Get bl31.bin via BL31 and rk3399m0.bin via PMUM0
>   Kconfig: Add u-boot.itb BUILD_TARGET for Rockchip

I think you hold for this with puma changes? any further comments
please let me know.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] km/spi: port SPI flash of KM Kirkwood boards to driver model

[Stefan Roese]

On 04.06.19 14:23, pascal.lin...@edu.hefr.ch wrote:

From: Pascal Linder 

The required configurations were activated in the default configuration
files of the board series and the SPI interface setting is added to
the common device tree file.

Some adaptions were necessary in the driver (kirkwood_spi.c) in order to
support the driver model on the shared SPI bus. Weak functions were added
to the claim and release operation (release was not yet implemented) and
can be overwritten in the board specific file. For KM boards these
functionality is needed to change the MPP configuration when claiming
or releasing the bus as the pins are shared between the NAND and SPI NOR
device.

Finally, the deprecated code in the driver could be deleted as only KM
boards were overwriting these weak functions. Every occurrence of the
now unused preprocessor definition CONFIG_SYS_KW_SPI_MPP and its
associated defines were removed as well.

Signed-off-by: Pascal Linder 
Signed-off-by: Holger Brunck 
---
  arch/arm/dts/kirkwood-km_kirkwood.dts | 22 +
  arch/arm/include/asm/arch-mvebu/spi.h | 11 -
  board/keymile/km_arm/km_arm.c | 23 -
  configs/km_kirkwood_128m16_defconfig  |  4 ++
  configs/km_kirkwood_defconfig |  4 ++
  configs/km_kirkwood_pci_defconfig |  4 ++
  configs/kmcoge5un_defconfig   |  4 ++
  configs/kmnusa_defconfig  |  4 ++
  configs/kmsugp1_defconfig |  4 ++
  configs/kmsuv31_defconfig |  4 ++
  configs/mgcoge3un_defconfig   |  4 ++
  configs/portl2_defconfig  |  7 ++-
  drivers/spi/kirkwood_spi.c| 71 ++-
  include/configs/km/km_arm.h   |  2 -
  scripts/config_whitelist.txt  |  1 -
  15 files changed, 97 insertions(+), 72 deletions(-)


It would be better (easier to review) to split this patch into multiple
separate patches. Perhaps something like this (just a rough idea):

patch 1/5: Add board specific MPP handling to kirkwood-spi (DM version)
patch 2/5: Add SPI nodes and properties to Keymile DT files
patch 3/5: Enable DM_SPI in defconfigs
patch 4/5: Add board specific DM SPI MPP stuff to Keymile boards
patch 5/5: Remove now unused MPP stuff (non-DM driver and header)

Please find some further comments below.



diff --git a/arch/arm/dts/kirkwood-km_kirkwood.dts 
b/arch/arm/dts/kirkwood-km_kirkwood.dts
index f035eff1c11..b2c0209f5db 100644
--- a/arch/arm/dts/kirkwood-km_kirkwood.dts
+++ b/arch/arm/dts/kirkwood-km_kirkwood.dts
@@ -13,6 +13,10 @@
device_type = "memory";
reg = <0x 0x0800>;
};
+
+   aliases {
+   spi0 = 
+   };
  };
  
   {

@@ -29,3 +33,21 @@
phy-handle = <>;
};
  };
+
+ {
+   status = "okay";
+
+   flash@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "st,m25p80", "jedec,spi-nor", "spi-flash";
+   reg = <0>;
+   spi-max-frequency = <3300>;
+   mode = <3>;
+
+   partition@uboot {
+   reg = <0x00 0x0c>;
+   label = "uboot";
+   };
+   };
+};
diff --git a/arch/arm/include/asm/arch-mvebu/spi.h 
b/arch/arm/include/asm/arch-mvebu/spi.h
index d6f6d1ac574..58b6c32c4d8 100644
--- a/arch/arm/include/asm/arch-mvebu/spi.h
+++ b/arch/arm/include/asm/arch-mvebu/spi.h
@@ -23,17 +23,6 @@ struct kwspi_registers {
u32 dw_cfg; /* 0x10620 - Direct Write Configuration */
  };
  
-/* They are used to define CONFIG_SYS_KW_SPI_MPP

- * each of the below #defines selects which mpp is
- * configured for each SPI signal in spi_claim_bus
- * bit 0: selects pin for MOSI (MPP1 if 0, MPP6 if 1)
- * bit 1: selects pin for SCK (MPP2 if 0, MPP10 if 1)
- * bit 2: selects pin for MISO (MPP3 if 0, MPP11 if 1)
- */
-#define MOSI_MPP6  (1 << 0)
-#define SCK_MPP10  (1 << 1)
-#define MISO_MPP11 (1 << 2)
-
  /* Control Register */
  #define KWSPI_CSN_ACT (1 << 0) /* Activates serial memory interface */
  #define KWSPI_SMEMRDY (1 << 1) /* SerMem Data xfer ready */
diff --git a/board/keymile/km_arm/km_arm.c b/board/keymile/km_arm/km_arm.c
index ea03be9eb37..3db80615ef6 100644
--- a/board/keymile/km_arm/km_arm.c
+++ b/board/keymile/km_arm/km_arm.c
@@ -310,16 +310,35 @@ int board_late_init(void)
return 0;
  }
  
-int board_spi_claim_bus(struct spi_slave *slave)

+static const u32 spi_mpp_config[] = {
+   MPP1_SPI_MOSI,
+   MPP2_SPI_SCK,
+   MPP3_SPI_MISO,
+   0
+};
+
+static u32 spi_mpp_backup[4];
+
+int mvebu_board_spi_claim_bus(struct udevice *dev)
  {
+   spi_mpp_backup[3] = 0;
+
+   /* set new spi mpp config and save current one */
+   kirkwood_mpp_conf(spi_mpp_config, spi_mpp_backup);
+
kw_gpio_set_value(KM_FLASH_GPIO_PIN, 0);
  
  	return 0;

  }
  
-void board_spi_release_bus(struct spi_slave *slave)

+int 

Re: [U-Boot] [PATCH 00/92] ram: rk3399: Add LPDDR4 support

[Jagan Teki]

On Thu, Jun 13, 2019 at 7:21 AM Kever Yang  wrote:
>
> Hi Jagan,
>
>
> On 06/11/2019 11:03 PM, Jagan Teki wrote:
>
> Note: Puma rk3399 has SPL size overflow, better to enable TPL
> for this board.
>
> We need to keep Puma on a SPL-only configuration for the time being.
> Please make sure that the LPDDR4 code is an optional feature that does not
> increase the DRAM-driver size for boards that don’t need/want it.
>
> We have few boards do have TPL-runnable, would be any technical issue
> to switch puma to TPL? because we have lpddr4 code part of existing
> driver itself and it require extra ifdef to consider which indeed look
> awful from code point-of-view.
>
> Dose the driver size increase too much for Puma because of the lpddr4
> init logic or because of the two extra timing data? The two timing data
> are pretty big, maybe we do not need them if the board is not lpddr4?

Yes, along with the code that support set rate for lpddr4. Still
thinking how we can manage to mark the lpddr4 changes independent,
marking ifdef in all the code look awful. let me know if you have any
inputs?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 00/92] ram: rk3399: Add LPDDR4 support

[Jagan Teki]

On Thu, Jun 13, 2019 at 7:14 AM Kever Yang  wrote:
>
> Hi Jagan,
>
> Very grateful for you to send this patch set for LPDDR4 support.
>
> But, 92 patches, a little bit too much for merge them one by one,
>
> is it possible for U-Boot to merge this from somewhere after we review
>
> all these patches?

Applying entire series still not working for me via pwclient or
git-pw, but I usually create a bundle and apply them in single instant
like as below

₹ git config pw.server https://patchwork.ozlabs.org/
₹ git config pw.project uboot
₹ git config pw.username
₹ git config pw.password
₹ git-pw bundle list
₹ git-pw bundle apply 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] board: atmel: fix pda variable not being reset

[Eugen.Hristev]

From: Eugen Hristev 

In case someone detects a PDA and u-boot sets the 'pda' variable,
and the user does a saveenv, the pda is set in env, and if the
screen is removed, u-boot will still have in the env the 'pda'
variable, even if no screen is attached.
In order to fix this, we have to reset the 'pda' variable,
such that it's not just set if the screen is detected, but also unset
if no screen is detected.

Signed-off-by: Eugen Hristev 
---
 board/atmel/common/board.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/board/atmel/common/board.c b/board/atmel/common/board.c
index fc300a4..20c3b8c 100644
--- a/board/atmel/common/board.c
+++ b/board/atmel/common/board.c
@@ -29,7 +29,7 @@ void at91_pda_detect(void)
 
ret = w1_get_bus(AT91_PDA_EEPROM_DEFAULT_BUS, );
if (ret)
-   return;
+   goto pda_detect_err;
 
for (device_find_first_child(bus, );
 dev;
@@ -41,7 +41,7 @@ void at91_pda_detect(void)
ret = w1_eeprom_read_buf(dev, AT91_PDA_EEPROM_ID_OFFSET,
 (u8 *)buf, 
AT91_PDA_EEPROM_ID_LENGTH);
if (ret)
-   return;
+   goto pda_detect_err;
break;
}
}
@@ -61,6 +61,8 @@ void at91_pda_detect(void)
printf("PDA TM5000 detected\n");
break;
}
+
+pda_detect_err:
env_set("pda", (const char *)buf);
 }
 #else
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v5 1/2] arm: i.MX: Add CMD_NANDBCB Kconfig entry

[Jagan Teki]

On Wed, Jun 12, 2019 at 2:02 PM Shyam Saini
 wrote:
>
> Add Kconfig entry for CMD_NANDBCB, and default y on i.MX6
> platform with NAND_MXS defined.
>
> Reviewed-by: Stefano Babic 
> Signed-off-by: Jagan Teki 
> Signed-off-by: Shyam Saini 
> ---
> Hi,
>
> This patch series is based on feedback gathered from this [1] discussion
> and [2] patch submitted by Stefan.
>
> [1] https://patchwork.ozlabs.org/patch/870467/
> [2] https://patchwork.ozlabs.org/patch/897222/
>
> Changes for v5:
> - New patch
> Changes for v4:
> - No change
> Changes for v3:
> - Fixed Typo 'seprate'
> Changes for v2:
> - New patch
>  arch/arm/mach-imx/Kconfig | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index ec09ef240f..5dd286f9a7 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -71,6 +71,17 @@ config CMD_HDMIDETECT
>   This enables the 'hdmidet' command which detects if an HDMI monitor
>   is connected.
>
> +config CMD_NANDBCB
> +   bool "i.MX6 NAND Boot Control Block(BCB) command"
> +   depends on NAND && CMD_MTDPARTS
> +   default y if ARCH_MX6 && NAND_MXS
> +   help
> + Unlike normal 'nand write/erase' commands, this command update
> + Boot Control Block(BCB) for i.MX6 platform NAND IP's.
> +
> + This is similar to kobs-ng, which is used in Linux as separate
> + rootfs package.
> +

This patch structuring is not in proper order.

01: Add support for nandbcb (would have all required code, kconfig,
makefile changes)
02: Enable it on board config.
03: Readme, about the steps.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] mvebu: reserve SRAM memory on Marvell Armada 3700/7K/8K

[Heinrich Schuchardt]

On 6/13/19 7:48 AM, Stefan Roese wrote:
> Added Heinrich to Cc (and use Alex's new address)
>
> On 11.06.19 13:00, Patrick Wildt wrote:
>> The ARM-TF and the optional OP-TEE use the memory region 0x400
>> to 0x540 and should be reserved in the memory map, otherwise the
>> OS might wrongly assume that it can use that memory area for itself.
>> This has also been done in EDK2 [0].
>>
>> [0]
>> https://github.com/tianocore/edk2-platforms/commit/bf1c4a2cf8024669d1748e78c7e417433f85707e
>>
>>
>> Signed-off-by: Patrick Wildt 
>>
>> diff --git a/arch/arm/mach-mvebu/arm64-common.c
>> b/arch/arm/mach-mvebu/arm64-common.c
>> index aaf7b7c447..7572aad8c9 100644
>> --- a/arch/arm/mach-mvebu/arm64-common.c
>> +++ b/arch/arm/mach-mvebu/arm64-common.c
>> @@ -14,6 +14,7 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>     DECLARE_GLOBAL_DATA_PTR;
>>   @@ -142,5 +143,11 @@ int arch_early_init_r(void)
>>   pci_init();
>>   #endif
>>   +#ifdef CONFIG_EFI_LOADER
>> +    /* Reserve trusted SRAM section */
>> +    efi_add_memory_map(0x0400, 0x0140 >> EFI_PAGE_SHIFT,
>> +   EFI_RESERVED_MEMORY_TYPE, false);
>> +#endif

We already have a reservation via the device tree for a part of this
area [0x400-0x420[ in U-Boot and Linux:

cf63dad014bae080445bccbf9cecbe05f2cbed45
arm64: dts: marvell: armada-ap806: reserve PSCI area

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.2-rc4=132ac39cffbcfed80ada38ef0fc6d34d95da7be6

As the concerned boards can be booted not only via bootefi but also via
booti I suggest to update the device trees in Linux and U-Boot.

Best regards

Heinrich

>> +
>>   return 0;
>>   }
>>
>
> I would like to see some comments from the U-Boot "EFI guys", if
> this is the correct approach. I remember some discussions about
> using "reserved-memory" in the DT for this but I might be wrong
> here.
>
> Any comments?
>
> Thanks,
> Stefan
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC 2/6] efi: add RuntimeServicesSupported variable

[Heinrich Schuchardt]

On 6/5/19 6:21 AM, AKASHI Takahiro wrote:
> This variable is defined in UEFI specification 2.8, section 8.1.
> Its value should be updated whenever we add any usable runtime services
> function.

It is also required by the EBBR specification.

>
> Signed-off-by: AKASHI Takahiro 
> ---
>  include/efi_api.h| 15 +++
>  include/efi_loader.h |  3 +++
>  lib/efi_loader/efi_runtime.c | 28 
>  lib/efi_loader/efi_setup.c   |  5 +
>  4 files changed, 51 insertions(+)
>
> diff --git a/include/efi_api.h b/include/efi_api.h
> index 65584dd2d82a..d7d95edd4dfc 100644
> --- a/include/efi_api.h
> +++ b/include/efi_api.h
> @@ -213,6 +213,21 @@ struct efi_capsule_header {
>   u32 capsule_image_size;
>  };
>
> +#define EFI_RT_SUPPORTED_GET_TIME0x0001
> +#define EFI_RT_SUPPORTED_SET_TIME0x0002
> +#define EFI_RT_SUPPORTED_GET_WAKEUP_TIME 0x0004
> +#define EFI_RT_SUPPORTED_SET_WAKEUP_TIME 0x0008
> +#define EFI_RT_SUPPORTED_GET_VARIABLE0x0010
> +#define EFI_RT_SUPPORTED_GET_NEXT_VARIABLE_NAME  0x0020
> +#define EFI_RT_SUPPORTED_SET_VARIABLE0x0040
> +#define EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP 0x0080
> +#define EFI_RT_SUPPORTED_CONVERT_POINTER 0x0100
> +#define EFI_RT_SUPPORTED_GET_NEXT_HIGH_MONOTONIC_COUNT   0x0200
> +#define EFI_RT_SUPPORTED_RESET_SYSTEM0x0400
> +#define EFI_RT_SUPPORTED_UPDATE_CAPSULE  0x0800
> +#define EFI_RT_SUPPORTED_QUERY_CAPSULE_CAPABILITIES  0x1000
> +#define EFI_RT_SUPPORTED_QUERY_VARIABLE_INFO 0x2000
> +
>  struct efi_runtime_services {
>   struct efi_table_hdr hdr;
>   efi_status_t (EFIAPI *get_time)(struct efi_time *time,
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 23ce73226762..7bd8002e303e 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -573,6 +573,9 @@ static inline int guidcmp(const efi_guid_t *g1, const 
> efi_guid_t *g2)
>  #define __efi_runtime_data __attribute__ ((section (".data.efi_runtime")))
>  #define __efi_runtime __attribute__ ((section (".text.efi_runtime")))
>
> +/* Indicate supported runtime services */
> +efi_status_t efi_init_runtime_supported(void);
> +
>  /* Update CRC32 in table header */
>  void __efi_runtime efi_update_table_header_crc32(struct efi_table_hdr 
> *table);
>
> diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
> index 60442cb21d37..cf202bb9ec07 100644
> --- a/lib/efi_loader/efi_runtime.c
> +++ b/lib/efi_loader/efi_runtime.c
> @@ -89,6 +89,34 @@ struct elf_rela {
>   * handle a good number of runtime callbacks
>   */
>
> +efi_status_t efi_init_runtime_supported(void)
> +{
> + u16 efi_runtime_services_supported;
> +
> + /*
> +  * This value must be synced with efi_runtime_detach_list
> +  * as well as efi_runtime_services.
> +  */
> + efi_runtime_services_supported = EFI_RT_SUPPORTED_RESET_SYSTEM;

This support is system dependent, e.g. on RK3288 systems it does not exist.

> +#ifdef CONFIG_EFI_GET_TIME
> + efi_runtime_services_supported |= EFI_RT_SUPPORTED_GET_TIME;

We do not support this at runtime.

> +#endif
> +#ifdef CONFIG_EFI_SET_TIME
> + efi_runtime_services_supported |= EFI_RT_SUPPORTED_SET_TIME;

We do not support this at runtime.

> +#endif
> +#ifdef CONFIG_EFI_RUNTIME_SET_VIRTUAL_ADDRESS_MAP
> + efi_runtime_services_supported |=
> + EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP;

Our support is incomplete as we have not implemented ConvertPointer().

For unsupported services we will have to change the return value to
EFI_UNSUPPORTED. But that will be a separate patch.

Best regards

Heinrich

> +#endif
> +
> + return EFI_CALL(efi_set_variable(L"RuntimeServicesSupported",
> +  _global_variable_guid,
> +  EFI_VARIABLE_BOOTSERVICE_ACCESS |
> +  EFI_VARIABLE_RUNTIME_ACCESS,
> +  sizeof(efi_runtime_services_supported),
> +  _runtime_services_supported));
> +}
> +
>  /**
>   * efi_update_table_header_crc32() - Update crc32 in table header
>   *
> diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
> index 45d6aca051f3..75fa344060d5 100644
> --- a/lib/efi_loader/efi_setup.c
> +++ b/lib/efi_loader/efi_setup.c
> @@ -123,6 +123,11 @@ efi_status_t efi_init_obj_list(void)
>   if (ret != EFI_SUCCESS)
>   goto out;
>
> + /* Indicate supported runtime services */
> + ret = efi_init_runtime_supported();
> + if (ret != EFI_SUCCESS)
> + goto out;
> +
>   /* Initialize system table */
>   ret = efi_initialize_system_table();
>   if (ret != EFI_SUCCESS)
>
___
U-Boot mailing list