[U-Boot] [ANNOUNCEMENT] Expect ML downtime at 2019-12-03 11:00 CET

[Claudius Heine]

Hi everyone,

because we are moving the mailing list to a different server, we have to
take it down for hopefully only a few minutes.

The DNS entries need to be updated, so it might take a while until those
will stabilize.

Thanks and have a nice day!
Claudius



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

Re: [U-Boot] [PATCH 1/1] efi_loader: pass address to efi_install_fdt()

[Heinrich Schuchardt]

On 12/3/19 7:37 AM, Alexander Graf wrote:


On 03.12.19 08:27, Heinrich Schuchardt wrote:

As part of moving the parsing of command line arguments to do_bootefi()
call efi_install_fdt() with the address of the device tree instead of a
string.

Signed-off-by: Heinrich Schuchardt 
---
  cmd/bootefi.c | 30 --
  1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index f613cce7e2..3cf190889e 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -196,40 +196,37 @@ static void *get_config_table(const efi_guid_t
*guid)
  #endif /* !CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE) */

  /**
- * efi_install_fdt() - install fdt passed by a command argument
+ * efi_install_fdt() - install device tree
   *
- * If fdt_opt is available, the device tree located at that memory
address will
+ * If fdt_addr is available, the device tree located at that memory
address will
   * will be installed as configuration table, otherwise the device
tree located
   * at the address indicated by environment variable fdtcontroladdr
will be used.
   *
- * On architectures (x86) using ACPI tables device trees shall not be
installed
- * as configuration table.
+ * On architectures using ACPI tables device trees shall not be
installed as
+ * configuration table.
   *
- * @fdt_opt:    pointer to argument
+ * @fdt_addr:    address of device tree
   * Return:    status code
   */
-static efi_status_t efi_install_fdt(const char *fdt_opt)
+static efi_status_t efi_install_fdt(uintptr_t fdt_addr)
  {
  /*
   * The EBBR spec requires that we have either an FDT or an ACPI
table
   * but not both.
   */
  #if CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE)
-    if (fdt_opt) {
+    if (fdt_addr) {



Why check for fdt_addr != 0 here? Since you do the parsing outside of
this function now, just make 0 a valid pointer and check for the
validity outside of this function.


fdt_addr == 0 signals that U-Boot's internal device tree shall be used
for the UEFI sub-system.

Your suggested change would drop the capability to use the internal
device tree. Why would you want to do so?

---

The context is Christian's patch set

Add support for booting EFI FIT images
https://lists.denx.de/pipermail/u-boot/2019-November/391516.html

In his patch

https://lists.denx.de/pipermail/u-boot/2019-November/391518.html
bootm: Add a bootm command for type IH_OS_EFI

he converts addresses to strings and calls do_bootefi() which converts
these strings back to addresses. I would prefer to pass addresses directly.

Best regards

Heinrich





  printf("ERROR: can't have ACPI table and device tree.\n");
  return EFI_LOAD_ERROR;
  }
  #else
-    unsigned long fdt_addr;
  void *fdt;
  bootm_headers_t img = { 0 };
  efi_status_t ret;

-    if (fdt_opt) {
-    fdt_addr = simple_strtoul(fdt_opt, NULL, 16);
-    if (!fdt_addr)
-    return EFI_INVALID_PARAMETER;
-    } else {
+    if (!fdt_addr) {
+    const char* fdt_opt;
+
  /* Look for device tree that is already installed */
  if (get_config_table(_guid_fdt))
  return EFI_SUCCESS;
@@ -556,6 +553,7 @@ static int do_efi_selftest(void)
  static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
  {
  efi_status_t ret;
+    uintptr_t fdt_addr;

  if (argc < 2)
  return CMD_RET_USAGE;
@@ -568,7 +566,11 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag,
int argc, char * const argv[])
  return CMD_RET_FAILURE;
  }

-    ret = efi_install_fdt(argc > 2 ? argv[2] : NULL);
+    if (argc > 2)
+    fdt_addr = simple_strtoul(argv[2], NULL, 16);
+    else
+    fdt_addr = 0UL;
+    ret = efi_install_fdt(fdt_addr);



So here:


if (fdt_addr)
     efi_install_fdt(fdt_addr);

And then you can remove all of the conditional code (and indentation) in
efi_install_fdt() above.


Alex





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

Re: [U-Boot] [PATCH 1/1] efi_loader: pass address to efi_install_fdt()

[Alexander Graf]

On 03.12.19 08:27, Heinrich Schuchardt wrote:

As part of moving the parsing of command line arguments to do_bootefi()
call efi_install_fdt() with the address of the device tree instead of a
string.

Signed-off-by: Heinrich Schuchardt 
---
  cmd/bootefi.c | 30 --
  1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index f613cce7e2..3cf190889e 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -196,40 +196,37 @@ static void *get_config_table(const efi_guid_t *guid)
  #endif /* !CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE) */

  /**
- * efi_install_fdt() - install fdt passed by a command argument
+ * efi_install_fdt() - install device tree
   *
- * If fdt_opt is available, the device tree located at that memory address will
+ * If fdt_addr is available, the device tree located at that memory address 
will
   * will be installed as configuration table, otherwise the device tree located
   * at the address indicated by environment variable fdtcontroladdr will be 
used.
   *
- * On architectures (x86) using ACPI tables device trees shall not be installed
- * as configuration table.
+ * On architectures using ACPI tables device trees shall not be installed as
+ * configuration table.
   *
- * @fdt_opt:   pointer to argument
+ * @fdt_addr:  address of device tree
   * Return:status code
   */
-static efi_status_t efi_install_fdt(const char *fdt_opt)
+static efi_status_t efi_install_fdt(uintptr_t fdt_addr)
  {
/*
 * The EBBR spec requires that we have either an FDT or an ACPI table
 * but not both.
 */
  #if CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE)
-   if (fdt_opt) {
+   if (fdt_addr) {



Why check for fdt_addr != 0 here? Since you do the parsing outside of 
this function now, just make 0 a valid pointer and check for the 
validity outside of this function.




printf("ERROR: can't have ACPI table and device tree.\n");
return EFI_LOAD_ERROR;
}
  #else
-   unsigned long fdt_addr;
void *fdt;
bootm_headers_t img = { 0 };
efi_status_t ret;

-   if (fdt_opt) {
-   fdt_addr = simple_strtoul(fdt_opt, NULL, 16);
-   if (!fdt_addr)
-   return EFI_INVALID_PARAMETER;
-   } else {
+   if (!fdt_addr) {
+   const char* fdt_opt;
+
/* Look for device tree that is already installed */
if (get_config_table(_guid_fdt))
return EFI_SUCCESS;
@@ -556,6 +553,7 @@ static int do_efi_selftest(void)
  static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
argv[])
  {
efi_status_t ret;
+   uintptr_t fdt_addr;

if (argc < 2)
return CMD_RET_USAGE;
@@ -568,7 +566,11 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int 
argc, char * const argv[])
return CMD_RET_FAILURE;
}

-   ret = efi_install_fdt(argc > 2 ? argv[2] : NULL);
+   if (argc > 2)
+   fdt_addr = simple_strtoul(argv[2], NULL, 16);
+   else
+   fdt_addr = 0UL;
+   ret = efi_install_fdt(fdt_addr);



So here:


if (fdt_addr)
    efi_install_fdt(fdt_addr);

And then you can remove all of the conditional code (and indentation) in 
efi_install_fdt() above.



Alex


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

Re: [U-Boot] [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem framework

[Kuldeep Singh]

Hi Frieder,

> -Original Message-
> From: Schrempf Frieder 
> Sent: Monday, December 2, 2019 5:35 PM
> To: Kuldeep Singh ; u-boot@lists.denx.de
> Cc: Priyanka Jain ; ja...@amarulasolutions.com;
> s...@denx.de; Ashish Kumar 
> Subject: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem
> framework
> 
> Caution: EXT Email
> 
> + Ashish
> 
> Hi Kuldeep,
> 
> On 29.11.19 06:54, Kuldeep Singh wrote:
> > This entire patch series migrate freescale qspi driver to spi-mem framework.
> 
> First, thanks for working on this. I have this on my list for quite a long 
> time, but
> struggled to find enough time to actually get it done.
> 
> >
> > Patch 1 removes the old fsl qspi driver
> 
> You shouldn't remove the old driver before the new one is in place, as this
> breaks the build in between the two patches.

I first merged the patch1 and patch2 and found that the diff output was very 
much less readable.
That's why I split them into 2 patches so as to make new driver changes legible.
Please let me know how shall I proceed. Shall I merge the two patches?

> 
> >
> > Patch 2 adds new qspi driver incorporating spi-mem framework which is
> > ported version of linux qspi driver. Initial port was done by Frieder.
> > Now, no more direct access to spi-nor memory is possible. Few changes
> > were introduced to prevent uboot crash such as to add complete flash
> > size to SFA1AD, SFA2AD, SFB1AD, SFB2AD based on chip select number
> > instead of 1k. Immediate effect was observed on pfe while using 1k
> > size as it access spi-nor memory directly. Using complete flash size 
> > resolves
> the crash but data read will not be valid.
> 
> Can you provide more information about the problem/crash you experience
> and the platform you are working on?

I observed crash on LS1012. Also, any access to flash direct memory above 1k 
will crash without this change.
By adding this, crash will be resolved but data is invalid as mentioned in 
patch-set.
 
> Are you referring to the same issue as Ashish in this discussion here [1]?

Yes, I had a discussion with him.
 
> There are two reasons why I'd like to avoid using the whole memory mapped
> area for AHB access.
> First, I'd like to keep the U-Boot driver as close as possible to the Linux 
> driver.
> Second, the intention of the spi-mem layer is to abstract the flash layer and
> therefore this driver should work independently of flash type or size. 

Boot from QSPI-NAND will still not be possible. Code in bootROM is only to 
access QSPI-NOR.

>With your version this wouldn't be the case if you connect a flash that is 
>bigger than the
> memory map for example.

I agree such use case can be valid for Linux but in case of Uboot, I believe 
access to flash size greater than 256M will not be required.
If in case there is a requirement, there is another region in CCSR space to map 
flash memories up to 4G.
Random crashes can be avoided by adding these changes. Please let us know your 
views as well.

Thanks
Kuldeep

> Thanks,
> Frieder
> 
> [1]:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.denx
> .de%2Fpipermail%2Fu-boot%2F2019-
> October%2F387788.htmldata=02%7C01%7Ckuldeep.singh%40nxp.com%
> 7C5f25f29d1a2d4971c62a08d7771feb4c%7C686ea1d3bc2b4c6fa92cd99c5c30
> 1635%7C0%7C0%7C637108851370551242sdata=OKjdpsL4BbALL3TIGh7
> EuJaVV0xC5%2FH8%2BIXoTnIowGQ%3Dreserved=0
> 
> >
> > Patch 3 removes unused config options.
> >
> > Patch 4 moves FSL_QSPI config to defconfigs instead of defining in header
> files.
> > SPI_FLASH_SPANSION is enabled while disabling SPI_FLASH_BAR.
> >
> > Patch 5 removes unused num-cs property for imx platforms
> >
> > Patch 6 enables SPI_FLASH_SPANSION for ls1012 boards. SPI_FLASH_BAR is
> > no longer required and can be removed.
> >
> > Patch 7 move SPI_FLASH_SPANSION to defconfigs instead of header files.
> > While enabling SPI_FLASH_SPANSION config, also disable SPI_FLASH_BAR at
> the same time.
> >
> > Patch 8 updates the device-tree properties treewide for layerscape
> > boards by aligning it with linux device-tree properties.
> >
> > Frieder Schrempf (1):
> >imx: imx6sx: Remove unused 'num-cs' property
> >
> > Kuldeep Singh (7):
> >spi: Remove old freescale qspi driver
> >spi: Transform the FSL QuadSPI driver to use the SPI MEM API
> >treewide: Remove unused FSL QSPI config options
> >configs: ls1043a: Move CONFIG_FSL_QSPI to defconfig
> >configs: ls1012a: Enable SPI_FLASH_SPANSION in defconfig
> >configs: ls1046a: Move SPI_FLASH_SPANSION to defconfig
> >treewide: Update fsl qspi node dt properties as per spi-mem driver
> >
> >   arch/arm/dts/fsl-ls1012a-frdm.dtsi|5 +-
> >   arch/arm/dts/fsl-ls1012a-qds.dtsi |5 +-
> >   arch/arm/dts/fsl-ls1012a-rdb.dtsi |5 +-
> >   arch/arm/dts/fsl-ls1012a.dtsi |4 +-
> >   arch/arm/dts/fsl-ls1043a-qds.dtsi |5 +-
> >   arch/arm/dts/fsl-ls1043a.dtsi |6 +-
> > 

[U-Boot] [PATCH 1/1] efi_loader: pass address to efi_install_fdt()

[Heinrich Schuchardt]

As part of moving the parsing of command line arguments to do_bootefi()
call efi_install_fdt() with the address of the device tree instead of a
string.

Signed-off-by: Heinrich Schuchardt 
---
 cmd/bootefi.c | 30 --
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index f613cce7e2..3cf190889e 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -196,40 +196,37 @@ static void *get_config_table(const efi_guid_t *guid)
 #endif /* !CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE) */

 /**
- * efi_install_fdt() - install fdt passed by a command argument
+ * efi_install_fdt() - install device tree
  *
- * If fdt_opt is available, the device tree located at that memory address will
+ * If fdt_addr is available, the device tree located at that memory address 
will
  * will be installed as configuration table, otherwise the device tree located
  * at the address indicated by environment variable fdtcontroladdr will be 
used.
  *
- * On architectures (x86) using ACPI tables device trees shall not be installed
- * as configuration table.
+ * On architectures using ACPI tables device trees shall not be installed as
+ * configuration table.
  *
- * @fdt_opt:   pointer to argument
+ * @fdt_addr:  address of device tree
  * Return: status code
  */
-static efi_status_t efi_install_fdt(const char *fdt_opt)
+static efi_status_t efi_install_fdt(uintptr_t fdt_addr)
 {
/*
 * The EBBR spec requires that we have either an FDT or an ACPI table
 * but not both.
 */
 #if CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE)
-   if (fdt_opt) {
+   if (fdt_addr) {
printf("ERROR: can't have ACPI table and device tree.\n");
return EFI_LOAD_ERROR;
}
 #else
-   unsigned long fdt_addr;
void *fdt;
bootm_headers_t img = { 0 };
efi_status_t ret;

-   if (fdt_opt) {
-   fdt_addr = simple_strtoul(fdt_opt, NULL, 16);
-   if (!fdt_addr)
-   return EFI_INVALID_PARAMETER;
-   } else {
+   if (!fdt_addr) {
+   const char* fdt_opt;
+
/* Look for device tree that is already installed */
if (get_config_table(_guid_fdt))
return EFI_SUCCESS;
@@ -556,6 +553,7 @@ static int do_efi_selftest(void)
 static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
argv[])
 {
efi_status_t ret;
+   uintptr_t fdt_addr;

if (argc < 2)
return CMD_RET_USAGE;
@@ -568,7 +566,11 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int 
argc, char * const argv[])
return CMD_RET_FAILURE;
}

-   ret = efi_install_fdt(argc > 2 ? argv[2] : NULL);
+   if (argc > 2)
+   fdt_addr = simple_strtoul(argv[2], NULL, 16);
+   else
+   fdt_addr = 0UL;
+   ret = efi_install_fdt(fdt_addr);
if (ret == EFI_INVALID_PARAMETER)
return CMD_RET_USAGE;
else if (ret != EFI_SUCCESS)
--
2.24.0

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

Re: [U-Boot] pull request u-boot-fsl-qoriq

[Priyanka Jain]

>-Original Message-
>From: Tom Rini 
>Sent: Tuesday, December 3, 2019 8:40 AM
>To: Priyanka Jain 
>Cc: U-Boot Mailing List 
>Subject: Re: pull request u-boot-fsl-qoriq
>
>On Mon, Dec 02, 2019 at 06:24:17AM +, Priyanka Jain wrote:
>
>> Dear Tom,
>>
>>
>>
>> Please find my pull-request for u-boot-fsl-qoriq/master
>>
>> https://travis-ci.org/p-priyanka-jain/u-boot/builds/618451045
>>
>>
>>
>> Summary
>>
>> fsl-qoriq : Minor bug fixes and updates on lx2160a, ls1028a, ls1012a,
>> ls1043aqds platforms
>>
>>
>>
>> priyankajain
>>
>>
>>
>
>Aside, I think something is messing with your pull request emails sometimes,
>there's loads of extra whitespace here.
>
Thanks, I will take care next time
>Applied to u-boot/master, thanks!
>
>--
>Tom
Priyanka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] arm: dts: Add mac node for rk3308 at dtsi level

[David Wu]

Hi Kever,

在 2019/11/27 下午2:23, Kever Yang 写道:

David,


On 2019/11/26 上午9:39, David Wu wrote:

The rk3308 only support RMII mode, and if it is output clock
mode, better to use ref_clk pin with drive strength 12ma.

Signed-off-by: David Wu 


Did you send this to kernel list at the same time?


I will send it later.




Thanks,

- Kever


---
  arch/arm/dts/rk3308.dtsi | 22 ++
  1 file changed, 22 insertions(+)

diff --git a/arch/arm/dts/rk3308.dtsi b/arch/arm/dts/rk3308.dtsi
index 0eeec165d4..a5c0b72ae0 100644
--- a/arch/arm/dts/rk3308.dtsi
+++ b/arch/arm/dts/rk3308.dtsi
@@ -627,6 +627,28 @@
  status = "disabled";
  };
+    mac: ethernet@ff4e {
+    compatible = "rockchip,rk3308-mac";
+    reg = <0x0 0xff4e 0x0 0x1>;
+    rockchip,grf = <>;
+    interrupts = ;
+    interrupt-names = "macirq";
+    clocks = < SCLK_MAC>, < SCLK_MAC_RX_TX>,
+ < SCLK_MAC_RX_TX>, < SCLK_MAC_REF>,
+ < SCLK_MAC>, < ACLK_MAC>,
+ < PCLK_MAC>, < SCLK_MAC_RMII>;
+    clock-names = "stmmaceth", "mac_clk_rx",
+  "mac_clk_tx", "clk_mac_ref",
+  "clk_mac_refout", "aclk_mac",
+  "pclk_mac", "clk_mac_speed";
+    phy-mode = "rmii";
+    pinctrl-names = "default";
+    pinctrl-0 = <_pins _refclk_12ma>;
+    resets = < SRST_MAC_A>;
+    reset-names = "stmmaceth";
+    status = "disabled";
+    };
+
  cru: clock-controller@ff50 {
  compatible = "rockchip,rk3308-cru";
  reg = <0x0 0xff50 0x0 0x1000>;








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

[U-Boot] [ANN] U-Boot v2020.01-rc4 released

[Tom Rini]

Hey all,

It's release day and here is v2020.01-rc4.  Yes, I'm still working on
fixing all of the issues that pop up as I get the MTD clean-up series
ready to go.  In fact, what I need to do at this point is grab the
handful of size reduction patches that this has shown are worthwhile,
then I can do the MTD series.  Then we're down to just fixing up
misconversions where things got turned off.

Once again, for a changelog, 
git log --merges v2020.01-rc3..v2020.01-rc4
and as always, I ask for more details in the PRs people send me so I can
put them in the merge commit.

I'm planning on doing -rc5 on December 23rd with the release scheduled
on January 6th.  Thanks all!

-- 
Tom


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 v4 00/42] common: Further reduce common.h

[Tom Rini]

On Thu, Nov 14, 2019 at 12:57:08PM -0700, Simon Glass wrote:

> This series drops the size of common.h down further, by moving things out
> into existing and new header files.
> 
> It is now down to about 200 lines.
> 
> Changes in v4:
> - Rename cpu_legacy.h to cpu_func.h
> - Use cpu_func.h instead of cpu_legacy.h
> - Use irq_func.h instead of irq_legacy.h
> 
> Changes in v3:
> - Add init.h header
> - Add new patch to inline pxa_wait_ticks()
> - Drop include in pxa2xx.c since this is for pxa_wait_ticks()
> - Put copyright info into vsprintf.c
> - Rename eeprom_legacy.h to eeprom.h since this may not be legacy code
> - Rename irq_legacy to irq_func to avoid the 'legacy' label
> - Update comment to wait_ticks() to indicate it is an internal function
> - Update commit message
> - Update the commit message
> 
> Changes in v2:
> - Move trap_init() into init.h instead; update commit message
> 
> Simon Glass (42):
>   common: Move older CPU functions to their own header
>   Drop CONFIG_SHOW_ACTIVITY
>   common: Drop global inclusion of status_led.h
>   status_led: Tidy up the code style
>   common: Move random-number functions into their own header
>   common: Drop linux/crc8.h
>   crc: Fix code style with crc functions
>   crc32: Use the crc.h header for crc functions
>   spl: bootcount: Move code out of header file
>   common: Move bootcount functions to their header file
>   common: Move sorting functions to their own header file
>   Move strtomhz() to vsprintf.h
>   common: Move env_get_ip() to net.h
>   serial: usb: Correct the usbtty_...() prototypes
>   common: Move serial_printf() to the serial header
>   common: Move serial functions out of common.h
>   common: Add a new lz4.h header file
>   common: Move some time functions out of common.h
>   common: Move wait_ticks functions out of common.h
>   arm: pxa: Drop pxa_wait_ticks()
>   common: Move timer_get_us() function out of common.h
>   common: Move get_ticks() function out of common.h
>   common: Move mii_init() function out of common.h
>   common: Move some CPU functions out of common.h
>   common: Drop cpu_init()
>   common: Move checkcpu() out of common.h
>   common: Move some SMP functions out of common.h
>   arm: powerpc: Tidy up code style for cache functions
>   common: Move some cache and MMU functions out of common.h
>   common: Drop checkicache() and checkdcache()
>   common: Move ARM cache operations out of common.h
>   arm: powerpc: Tidy up code style for interrupt functions
>   common: Move interrupt functions into a new header
>   common: Move enable/disable_interrupts out of common.h
>   common: Move command functions out of common.h
>   common: Drop board_show_dram()
>   common: Move board_get_usable_ram_top() out of common.h
>   common: Move some board functions out of common.h
>   common: Move pci_init_board() out of common.h
>   common: Move trap_init() out of common.h
>   common: Drop get_endaddr()
>   common: Move old EEPROM functions into a new header
> 
>  README|   2 +-
>  api/api.c |   1 +
>  arch/arc/lib/bootm.c  |   1 +
>  arch/arc/lib/cache.c  |   1 +
>  arch/arc/lib/cpu.c|   1 +
>  arch/arc/lib/interrupts.c |   1 +
>  arch/arm/cpu/arm11/cpu.c  |   4 +-
>  arch/arm/cpu/arm920t/cpu.c|   4 +-
>  arch/arm/cpu/arm920t/ep93xx/timer.c   |   1 +
>  arch/arm/cpu/arm920t/imx/timer.c  |   1 +
>  arch/arm/cpu/arm926ejs/armada100/cpu.c|   1 +
>  arch/arm/cpu/arm926ejs/armada100/timer.c  |   1 +
>  arch/arm/cpu/arm926ejs/cache.c|   1 +
>  arch/arm/cpu/arm926ejs/cpu.c  |   4 +-
>  arch/arm/cpu/arm926ejs/lpc32xx/cpu.c  |   1 +
>  arch/arm/cpu/arm926ejs/lpc32xx/timer.c|   1 +
>  arch/arm/cpu/arm926ejs/mx25/generic.c |   1 +
>  arch/arm/cpu/arm926ejs/mx27/generic.c |   1 +
>  arch/arm/cpu/arm926ejs/mx27/timer.c   |   1 +
>  arch/arm/cpu/arm926ejs/mxs/spl_boot.c |   1 +
>  arch/arm/cpu/arm926ejs/mxs/timer.c|   1 +
>  arch/arm/cpu/arm926ejs/spear/spr_misc.c   |   1 +
>  arch/arm/cpu/arm926ejs/spear/timer.c  |   1 +
>  arch/arm/cpu/arm946es/cpu.c   |   4 +-
>  arch/arm/cpu/armv7/arch_timer.c   |   1 +
>  arch/arm/cpu/armv7/cache_v7.c |   1 +
>  arch/arm/cpu/armv7/cpu.c  |   2 +
>  arch/arm/cpu/armv7/exception_level.c  |   1 +
>  .../cpu/armv7/iproc-common/hwinit-common.c|   1 +
>  arch/arm/cpu/armv7/iproc-common/timer.c   |   1 +
>  .../arm/cpu/armv7/kona-common/hwinit-common.c |   1 +
>  arch/arm/cpu/armv7/ls102xa/cpu.c  |   2 +
>  arch/arm/cpu/armv7/ls102xa/ls102xa_psci.c |   1 +
>  arch/arm/cpu/armv7/ls102xa/timer.c|   1 +
>  arch/arm/cpu/armv7/mpu_v7r.c  |   1 +
>  

Re: [U-Boot] pull request u-boot-fsl-qoriq

[Tom Rini]

On Mon, Dec 02, 2019 at 06:24:17AM +, Priyanka Jain wrote:

> Dear Tom,
> 
> 
> 
> Please find my pull-request for u-boot-fsl-qoriq/master
> 
> https://travis-ci.org/p-priyanka-jain/u-boot/builds/618451045
> 
> 
> 
> Summary
> 
> fsl-qoriq : Minor bug fixes and updates on lx2160a, ls1028a, ls1012a, 
> ls1043aqds platforms
> 
> 
> 
> priyankajain
> 
> 
> 

Aside, I think something is messing with your pull request emails
sometimes, there's loads of extra whitespace here.

Applied to u-boot/master, thanks!

-- 
Tom


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] warp7: Fix U-Boot corruption after saving the environment

[Tom Rini]

On Tue, Dec 03, 2019 at 12:04:46AM -0300, Fabio Estevam wrote:

> U-Boot binary has grown in such a way that it goes beyond the reserved
> area for the environment variables.
> 
> Running "saveenv" followed by a "reset" causes U-Boot to hang because
> of this overlap.
> 
> Fix this problem by selecting CONFIG_SYS_THUMB_BUILD=y, which
> generates a smaller u-boot-dtb.imx binary.
> 
> Also, in order to prevent this same problem in the future, use
> CONFIG_BOARD_SIZE_LIMIT, which will detect the overlap in build-time.
> 
> CONFIG_BOARD_SIZE_LIMIT does not accept math expressions, so declare
> CONFIG_ENV_OFFSET with its direct value instead.
> 
> Signed-off-by: Fabio Estevam 

Thanks for the rework.  Can you please look at what other i.MX boards
are likely fine, or perhaps more clearly if any i.MX5/6 SoCs do have
thumb2 related errata that might make it a bad idea to use thumb by
default ?

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PULL] u-boot-mips

[Tom Rini]

On Sat, Nov 30, 2019 at 11:01:15PM +0100, Daniel Schwierzeck wrote:

> Hi Tom,
> 
> please pull the removal of the MIPS Micronas VCT boards for 2020.01.
> 
> Gitlab: https://gitlab.denx.de/u-boot/custodians/u-boot-mips/pipelines/1454
> Travis CI: https://travis-ci.org/danielschwierzeck/u-boot/builds/618647984
> 
> 
> The following changes since commit 4b19b89ca4a866b7baa642533e6dbd67cd832d27:
> 
>   Merge tag 'rpi-next-2020.01' of https://github.com/mbgg/u-boot (2019-11-25 
> 12:56:27 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-mips.git master
> 
> for you to fetch changes up to 2a250ae9b6f1437f13dba272b690b24341b8e1d7:
> 
>   MIPS: remove Micronas VCT boards (2019-11-29 16:18:35 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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 v2] warp7: Fix U-Boot corruption after saving the environment

[Fabio Estevam]

On Mon, Dec 2, 2019 at 9:59 PM Tom Rini  wrote:

> Is there a reason we can't use CONFIG_SYS_THUMB_BUILD on these
> platforms?  It's not default y as I seem to recall some thumb problems
> with very early ARMv7 cores, but it should almost certainly be set here
> (and a large number of other i.MX platforms).  I'd much rather see that
> than moving the environment offset.  Thanks!

Just sent v3 with CONFIG_SYS_THUMB_BUILD=y.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3] warp7: Fix U-Boot corruption after saving the environment

[Fabio Estevam]

U-Boot binary has grown in such a way that it goes beyond the reserved
area for the environment variables.

Running "saveenv" followed by a "reset" causes U-Boot to hang because
of this overlap.

Fix this problem by selecting CONFIG_SYS_THUMB_BUILD=y, which
generates a smaller u-boot-dtb.imx binary.

Also, in order to prevent this same problem in the future, use
CONFIG_BOARD_SIZE_LIMIT, which will detect the overlap in build-time.

CONFIG_BOARD_SIZE_LIMIT does not accept math expressions, so declare
CONFIG_ENV_OFFSET with its direct value instead.

Signed-off-by: Fabio Estevam 
---
Changes since v2:
- Select CONFIG_SYS_THUMB_BUILD=y (Tom)

 configs/warp7_defconfig |  1 +
 include/configs/warp7.h | 13 +
 2 files changed, 14 insertions(+)

diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index 72cdb684a7..781cbe12d7 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -1,4 +1,5 @@
 CONFIG_ARM=y
+CONFIG_SYS_THUMB_BUILD=y
 CONFIG_ARCH_MX7=y
 CONFIG_SYS_TEXT_BASE=0x8780
 CONFIG_TARGET_WARP7=y
diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index 9a82581c5f..af278c617e 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -125,6 +125,19 @@
 #define CONFIG_SYS_INIT_SP_ADDR \
(CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET)
 
+/*
+ * Environment starts at CONFIG_ENV_OFFSET = 0x8 = 512k
+ *
+ * Detect overlap between U-Boot image and environment area in build-time
+ *
+ * CONFIG_BOARD_SIZE_LIMIT = CONFIG_ENV_OFFSET - u-boot.imx offset
+ * CONFIG_BOARD_SIZE_LIMIT = 512k - 1k = 511k = 523264
+ *
+ * Currently CONFIG_BOARD_SIZE_LIMIT does not handle expressions, so
+ * write the direct value here
+ */
+#define CONFIG_BOARD_SIZE_LIMIT523264
+
 /* I2C configs */
 #define CONFIG_SYS_I2C_MXC
 #define CONFIG_SYS_I2C_SPEED   10
-- 
2.17.1

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

Re: [U-Boot] [PATCH] ARM: DRA7: Fixup DSP OPP_HIGH clock rate on DRA76P/DRA77P SoCs

[Lokesh Vutla]

On 03/12/19 4:04 AM, Suman Anna wrote:
> The commit 1b42ab3eda8a ("ARM: DRA7: Fixup DSPEVE, IVA and GPU clock
> frequencies based on OPP") added the core logic to update the kernel
> device-tree blob to adjust the DSP, IVA and GPU DPLL clocks based on
> a one-time OPP choice selected in U-Boot for most of the DRA7xx/AM57xx
> family of SoCs.
> 
> The DSPs on DRA76xP/DRA77xP SoCs (DRA76x ACD package SoCs) though
> provide a higher performance and can run at a higher clock frequency
> of 850 MHz at OPP_HIGH instead of 750 MHz. Fix up the logic to use the
> correct clock rates on these SoCs. Note that this higher clock rate is
> not applicable to other Jacinto 6 Plus SoCs (DRA75xP/DRA74xP SoCs or
> AM574x SoCs) that follow the ABZ package.
> 
> Signed-off-by: Suman Anna 

Reviewed-by: Lokesh Vutla 

Thanks and regards,
Lokesh

> ---
>  arch/arm/mach-omap2/omap5/fdt.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/omap5/fdt.c b/arch/arm/mach-omap2/omap5/fdt.c
> index 8dee555c10c6..5ba8806dd744 100644
> --- a/arch/arm/mach-omap2/omap5/fdt.c
> +++ b/arch/arm/mach-omap2/omap5/fdt.c
> @@ -180,6 +180,14 @@ u32 dra7_opp_dsp_clk_rates[NUM_OPPS][OPP_DSP_CLK_NUM] = {
>   {75000, 75000, 5}, /* OPP_HIGH */
>  };
>  
> +/* DSP clock rates on DRA76x ACD-package based SoCs */
> +u32 dra76_opp_dsp_clk_rates[NUM_OPPS][OPP_DSP_CLK_NUM] = {
> + {}, /* OPP_LOW */
> + {6, 6, 4}, /* OPP_NOM */
> + {7, 7, 46667}, /* OPP_OD */
> + {85000, 85000, 56667}, /* OPP_HIGH */
> +};
> +
>  /* IVA voltage domain */
>  u32 dra7_opp_iva_clk_rates[NUM_OPPS][OPP_IVA_CLK_NUM] = {
>   {}, /* OPP_LOW */
> @@ -257,6 +265,10 @@ static void ft_opp_clock_fixups(void *fdt, bd_t *bd)
>   /* fixup DSP clocks */
>   clk_names = dra7_opp_dsp_clk_names;
>   clk_rates = dra7_opp_dsp_clk_rates[get_voltrail_opp(VOLT_EVE)];
> + /* adjust for higher OPP_HIGH clock rate on DRA76xP/DRA77xP SoCs */
> + if (is_dra76x_acd())
> + clk_rates = dra76_opp_dsp_clk_rates[get_voltrail_opp(VOLT_EVE)];
> +
>   ret = ft_fixup_clocks(fdt, clk_names, clk_rates, OPP_DSP_CLK_NUM);
>   if (ret) {
>   printf("ft_fixup_clocks failed for DSP voltage domain: %s\n",
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [EXT] Re: [PATCHv2 1/2] PCI: layerscape: Add Support for ls2088 PCIe EP mode

[Xiaowei Bao]

Hi Ramon,

Do you have any comments about this? Thanks a lot.

Best regards
Xiaowei

From: Xiaowei Bao
Sent: 2019年11月26日 10:52
To: Ramon Fried 
Cc: Bin Meng ; Simon Glass ; M.h. Lian 
; Z.q. Hou ; Mingkai Hu 
; Hongbo Wang ; York Sun 
; u-boot@lists.denx.de
Subject: RE: [EXT] Re: [U-Boot] [PATCHv2 1/2] PCI: layerscape: Add Support for 
ls2088 PCIe EP mode

H Ramon,

Thanks for your comments.
If we reimplement the PCIe EP driver base on PCIe UCLASS, we must test it in 
u-boot, but I have no idea how to test the actual device, do I need to 
implement our own test case, how to verify the cadence-ep actual device?

Best regards
Xiaowei


From: Ramon Fried mailto:ramon.fr...@gmail.com>>
Sent: 2019年11月25日 20:15
To: Xiaowei Bao mailto:xiaowei@nxp.com>>
Cc: Bin Meng mailto:bmeng...@gmail.com>>; Simon Glass 
mailto:s...@chromium.org>>; M.h. Lian 
mailto:minghuan.l...@nxp.com>>; Z.q. Hou 
mailto:zhiqiang@nxp.com>>; Mingkai Hu 
mailto:mingkai...@nxp.com>>; Hongbo Wang 
mailto:hongbo.w...@nxp.com>>; York Sun 
mailto:york@nxp.com>>; 
u-boot@lists.denx.de
Subject: Re: [EXT] Re: [U-Boot] [PATCHv2 1/2] PCI: layerscape: Add Support for 
ls2088 PCIe EP mode



Hi Ramon,

I need your help on this, could you help explain how to start the PCIe EP test 
in
u-boot? Thanks a lot.
Hi, you just need to run the test suite and it will test the PCIe EP sandbox 
class automatically.
See test/README
Why do you care about the EP testing, it's testing the PCIe UCLASS 
implementation.
To test your implementation you need to test on actual device.
Thanks,
Ramon.

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

Re: [U-Boot] [PATCH v4 1/2] disk: update to use SPL_PARTITIONS for SPL

[Kever Yang]

Hi Tom,

On 2019/12/3 上午7:02, Tom Rini wrote:

This and 2/2 need to be checked (possibly again) for unexpected size
growth.
This patches should only affect those boards with SPL_LIBDISK_SUPPORT 
enabled,
If this MACRO is enabled, the board wants to use partition, and all the 
related source code are needed,

there should be no difference for this kind of boards.
If the size is overflow with this patch, that means the board does not 
have a complete partition driver
support,  eg. none of partition like SPL_EFI_PARTITION is selected, we 
should remove

SPL_LIBDISK_SUPPORT for this kind of boards.


How can I check boards has size overflow? these two patch can pass the 
travis test.


Thanks,
- Kever


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

Re: [U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Ang, Chee Hong]

> Am 02.12.2019 um 17:10 schrieb Ang, Chee Hong:
> >> On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong
> >> 
> >> wrote:
> >>>
>  On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong
>  
>  wrote:
> >
> >> On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong
> >> 
> >> wrote:
> >>>
>  On Mon, Dec 2, 2019 at 11:25 AM 
> >> wrote:
> >
> > From: "Ang, Chee Hong" 
> >
> > New U-boot flow with ARM Trusted Firmware (ATF) support:
> > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux
> > (EL1)
> 
>  Adding support for ATF means that using U-Boot on Stratix10 and
>  Agilex without ATF keeps working, right?
> >>> ATF is needed in order for Stratix10 and Agilex's U-Boot to work.
> >>
> >> Is there a technical requirement for that?
> > Yes. We are using ATF to provide PSCI services such as system
> > reset (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in Linux) and
> > other secure services such as mailbox communications with Secure
> > Device Manager and accessing the System Manager registers which
> > are
> >> secure.
> > Without PSCI services, we are able to boot until U-Boot proper only.
> > Currently, our U-Boot in mainline doesn't boot to Linux due to
> > these missing
>  PSCI services.
> > Another reason is we have another boot flow which is using ATF + UEFI.
> > So now we are re-using the PSCI services from ATF so that now
> > U-Boot and UEFI share the same ATF-BL31 image so that we don't
> > have to
>  reimplement another sets of PSCI services for U-Boot again.
> > This will greatly reduce our engineering efforts.
> 
>  Hmm, thanks for the explanation.
> 
>  I don't really think I can review this, given the lack of knowledge
>  about that PSCI stuff.
> >>> I believe you can review it.
> >>> Have you briefly gone through the patches ? It has nothing to do
> >>> with the PSCI
> >> stuff.
> >>> It just call the invoke_smc() function to call the ATF's PSCI
> >>> functions. Those PSCI functions in ATF will do the rest.
> >>
> >> No, not yet. But see below.
> >>
> 
>  I must say it seems strange to me that U-Boot would have to rely on
>  ATF
> >> though.
>  How do other platforms implement this? Shouldn't PSCI be generic or
>  is it really platform specific? If it's generic, isn't that a
>  dupliation of code if you implement e.g. a reset driver for
>  Stratix10 but call
> >> into PSCI?
> >>> It's not strange at all.  A lot of U-Boot users already using this
> >>> boot flow (ATF +
> >> U-Boot).
> >>
> >> Just because other boards do this doesn't mean it's not strange.
> >> Wasn't there some kind of discussion around that PSCI stuff to make it
> available from U-Boot?
> >> What's wrong with that way?
> > Our downstream U-Boot branch is already implemented the PSCI stuffs in U-
> Boot.
> > I tried to upstream my PSCI code:
> > https://lists.denx.de/pipermail/u-boot/2019-May/368822.html
> >
> > Marek pointed me to this thread:
> > https://www.mail-archive.com/u-boot@lists.denx.de/msg319458.html
> >
> > He had a point. He suggested maybe we can implement the PSCI stuffs in
> > SPL/TPL. I took a look at the U-Boot code and found out ATF is already well
> supported. Why don't we just use the PSCI code from ATF rather than re-
> implementing the PSCI code again in SPL/TPL.
> > It will save our effort to maintain two PSCI code in U-Boot and ATF while we
> already have the ATF PSCI implementation to support UEFI.
> 
> It seems to me we do have working code in U-Boot, what's missing is "only" to
> turn it ino PSCI?
Existing PSCI framework in U-Boot provide a way for us to turn the code into a 
PSCI handler
by just adding a '__secure' keyword before the function name. See:
https://gitlab.denx.de/u-boot/u-boot/blob/master/arch/arm/mach-socfpga/mailbox_s10.c

Below is one of the functions that has 2 versions. One 'live' in a normal code 
section and another
one will be relocated to "__secure" section (for PSCI). You can see that 2 same 
functions
are duplicated for normal code section and PSCI section.

int mbox_send_cmd(u8 id, u32 cmd, u8 is_indirect, u32 len, u32 *arg,
  u8 urgent, u32 *resp_buf_len, u32 *resp_buf)
{
return mbox_send_cmd_common(id, cmd, is_indirect, len, arg, urgent,
   resp_buf_len, resp_buf);
}

int __secure mbox_send_cmd_psci(u8 id, u32 cmd, u8 is_indirect, u32 len,
u32 *arg, u8 urgent, u32 *resp_buf_len,
u32 *resp_buf)
{
return mbox_send_cmd_common(id, cmd, is_indirect, len, arg, urgent,
   resp_buf_len, resp_buf);
}

Those functions that are needed by PSCI runtime need to be duplicated for 
"__secure" section.
U-Boot Proper will copy and relocate the PSCI code in "__secure" section to a 
location before booting
Linux whereby they can be 

Re: [U-Boot] [PATCH v2] warp7: Fix U-Boot corruption after saving the environment

[Tom Rini]

On Mon, Dec 02, 2019 at 08:40:28PM -0300, Fabio Estevam wrote:

> U-Boot binary has grown in such a way that it goes beyond the reserved
> area for the environment variables.
> 
> Running "saveenv" followed by a "reset" causes U-Boot to hang because
> of this overlap.
> 
> Fix this problem by increasing the CONFIG_ENV_OFFSET size.
> 
> Also, in order to prevent this same problem in the future, use
> CONFIG_BOARD_SIZE_LIMIT, which will detect the overlap in build-time.
> 
> CONFIG_BOARD_SIZE_LIMIT does not accept math expressions, so declare
> CONFIG_ENV_OFFSET with its direct value instead.
> 
> Signed-off-by: Fabio Estevam 
> Acked-by: Pierre-Jean Texier 
> Tested-by: Pierre-Jean Texier 
> Acked-by: Joris Offouga 
> Tested-by: Joris Offouga 
> ---
> Changes since v1:
> - Rebased against master as CONFIG_ENV_OFFSET has moved to Kconfig
> 
>  configs/warp7_defconfig |  2 +-
>  include/configs/warp7.h | 13 +
>  2 files changed, 14 insertions(+), 1 deletion(-)

Is there a reason we can't use CONFIG_SYS_THUMB_BUILD on these
platforms?  It's not default y as I seem to recall some thumb problems
with very early ARMv7 cores, but it should almost certainly be set here
(and a large number of other i.MX platforms).  I'd much rather see that
than moving the environment offset.  Thanks!

-- 
Tom


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

[U-Boot] [PATCH v2] warp7: Fix U-Boot corruption after saving the environment

[Fabio Estevam]

U-Boot binary has grown in such a way that it goes beyond the reserved
area for the environment variables.

Running "saveenv" followed by a "reset" causes U-Boot to hang because
of this overlap.

Fix this problem by increasing the CONFIG_ENV_OFFSET size.

Also, in order to prevent this same problem in the future, use
CONFIG_BOARD_SIZE_LIMIT, which will detect the overlap in build-time.

CONFIG_BOARD_SIZE_LIMIT does not accept math expressions, so declare
CONFIG_ENV_OFFSET with its direct value instead.

Signed-off-by: Fabio Estevam 
Acked-by: Pierre-Jean Texier 
Tested-by: Pierre-Jean Texier 
Acked-by: Joris Offouga 
Tested-by: Joris Offouga 
---
Changes since v1:
- Rebased against master as CONFIG_ENV_OFFSET has moved to Kconfig

 configs/warp7_defconfig |  2 +-
 include/configs/warp7.h | 13 +
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index 72cdb684a7..04a639da6d 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -3,7 +3,7 @@ CONFIG_ARCH_MX7=y
 CONFIG_SYS_TEXT_BASE=0x8780
 CONFIG_TARGET_WARP7=y
 CONFIG_ENV_SIZE=0x2000
-CONFIG_ENV_OFFSET=0x8
+CONFIG_ENV_OFFSET=0xC
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_ARMV7_BOOT_SEC_DEFAULT=y
 # CONFIG_ARMV7_VIRT is not set
diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index 9a82581c5f..4b55376f7a 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -125,6 +125,19 @@
 #define CONFIG_SYS_INIT_SP_ADDR \
(CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET)
 
+/*
+ * Environment starts at CONFIG_ENV_OFFSET= 0xC = 768k = 768*1024 = 786432
+ *
+ * Detect overlap between U-Boot image and environment area in build-time
+ *
+ * CONFIG_BOARD_SIZE_LIMIT = CONFIG_ENV_OFFSET - u-boot.imx offset
+ * CONFIG_BOARD_SIZE_LIMIT = 768k - 1k = 767k = 785408
+ *
+ * Currently CONFIG_BOARD_SIZE_LIMIT does not handle expressions, so
+ * write the direct value here
+ */
+#define CONFIG_BOARD_SIZE_LIMIT785408
+
 /* I2C configs */
 #define CONFIG_SYS_I2C_MXC
 #define CONFIG_SYS_I2C_SPEED   10
-- 
2.17.1

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

[U-Boot] [PATCH] configs: sama5d27_som1_ek: Add default config to read ENV from QSPI

[Swapna.Gurumani]

From: Swapna Gurumani 

In the initial SPI flash setup, the default bus mode being used was 3,
which is incorrect, causing a CRC error when the ENV was being read from
QSPI. Setting the default bus mode to 0 which is the correct mode.

Signed-off-by: Swapna Gurumani 
---
 configs/sama5d27_som1_ek_qspiflash_defconfig | 8 
 1 file changed, 8 insertions(+)

diff --git a/configs/sama5d27_som1_ek_qspiflash_defconfig 
b/configs/sama5d27_som1_ek_qspiflash_defconfig
index 128b6645f6..2b11ec5974 100644
--- a/configs/sama5d27_som1_ek_qspiflash_defconfig
+++ b/configs/sama5d27_som1_ek_qspiflash_defconfig
@@ -45,6 +45,14 @@ CONFIG_SPL_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="at91-sama5d27_som1_ek"
 CONFIG_OF_SPL_REMOVE_PROPS="interrupts interrupt-parent dmas dma-names"
 CONFIG_ENV_IS_IN_SPI_FLASH=y
+CONFIG_USE_ENV_SPI_BUS=y
+CONFIG_ENV_SPI_BUS=0
+CONFIG_USE_ENV_SPI_CS=y
+CONFIG_ENV_SPI_CS=0
+CONFIG_USE_ENV_SPI_MAX_HZ=y
+CONFIG_ENV_SPI_MAX_HZ=5000
+CONFIG_USE_ENV_SPI_MODE=y
+CONFIG_ENV_SPI_MODE=0x0
 CONFIG_DM=y
 CONFIG_SPL_DM=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
-- 
2.17.1

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

Re: [U-Boot] [RESEND PATCH v2] dm: serial: Handle "stdout-path" with ":options" correctly

[Simon Glass]

On Sun, 1 Dec 2019 at 19:45, Simon Glass  wrote:
>
> HI BIn,
>
> On Sun, 1 Dec 2019 at 18:47, Bin Meng  wrote:
> >
> > Hi Simon,
> >
> > On Mon, Nov 25, 2019 at 9:52 PM Bin Meng  wrote:
> > >
> > > With commit f0921f5098d8 ("fdt: Sync up to the latest libfdt"),
> > > SiFive Unleashed board does not boot any more. This was due to
> > > the U-Boot local changes commit 77d7fff8cec2 ("fdt: Fix handling
> > > of paths with options in them") to libfdt/fdt_ro.c was dropped
> > > during the libfdt upgrade.
> > >
> > > From the history [1] it was mentioned that the U-Boot changes
> > > commit 77d7fff8cec2 ("fdt: Fix handling of paths with options in
> > > them") was rejected by libfdt upstream, hence we need find another
> > > way to fix the things.
> > >
> > > This commit uses another method, by updating serial_check_stdout()
> > > directly to handle the situation of "stdout-path" with ":options".
> > > A simpler way is to change the logic in fdtdec_get_chosen_node()
> > > to do similar thing, but I feel that not every property in chosen
> > > node may have the option in them, hence it would make more sense
> > > to do the special handling in serial_check_stdout() directly.
> > >
> > > [1]: http://patchwork.ozlabs.org/patch/462756/
> > >
> > > Signed-off-by: Bin Meng 
> > > Reviewed-by: Simon Glass 
> > >
> > > ---
> > >
> > > Changes in v2:
> > > - initialize node with -1 at the beginning of serial_check_stdout()
> > >   for better readability
> > >
> > >  drivers/serial/serial-uclass.c | 36 +++-
> > >  1 file changed, 19 insertions(+), 17 deletions(-)
> > >
> >
> > Could you pull this for v2020.01 as it is a critical fix to make
> > SiFive FU540 board boot again?
>
> Yes will do. I see Tom has assigned it to me.

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] tools/imximage: fix reported DCD information for MX7ULP

[Jorge Ramirez-Ortiz, LDTS]

On 28/11/19 11:33:21, Jorge Ramirez-Ortiz wrote:
> On the MX7ULP, OCRAM for DCD is at 0x2f01

any comments?

do notice that this is not trivial debug information: this is required
for security puposes so images can then be signed and booted via
SDP. Dumping the wrong information here is important stuff.


> 
> Signed-off-by: Jorge Ramirez-Ortiz 
> ---
>  tools/imximage.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/tools/imximage.c b/tools/imximage.c
> index d7c0b6e883..762a06d468 100644
> --- a/tools/imximage.c
> +++ b/tools/imximage.c
> @@ -11,6 +11,7 @@
>  #include "imagetool.h"
>  #include 
>  #include "imximage.h"
> +#include 
>  
>  #define UNDEFINED 0x
>  
> @@ -524,8 +525,13 @@ static void print_hdr_v2(struct imx_header *imx_hdr)
>   printf("HAB Blocks:   0x%08x 0x%08x 0x%08x\n",
>  (uint32_t)fhdr_v2->self, 0,
>  (uint32_t)(fhdr_v2->csf - fhdr_v2->self));
> +#ifndef CONFIG_MX7ULP
>   printf("DCD Blocks:   0x0091 0x%08x 0x%08x\n",
>  offs, be16_to_cpu(dcdlen));
> +#else
> + printf("DCD Blocks:   0x2f01 0x%08x 0x%08x\n",
> +offs, be16_to_cpu(dcdlen));
> +#endif
>   }
>   } else {
>   imx_header_v2_t *next_hdr_v2;
> -- 
> 2.17.1
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] flashing and testing u-boot on chromebook_bob

[Sahaj Sarup]

Hi Simon,

Been a couple of weeks. I have obtained a SuzyQable and its working
well with bob. I can see RxTx from Cr50, AP and EC. On mainline linux
from ArchLinuxArm I can see earlyprintk as well. However I am still
stuck on the u-boot end.

Just to make sure I didn't miss anything, I'm laying down all the
steps that I followed to have u-boot chainloaded from depthcharge on
bob.

1. Build U-boot
- Build bl31 as in README.rockchip. export bl31.elf as BL31 env
- change CONFIG_SYS_TEXT_BASE to 0x2100
- 0x2000 From
https://chromium.googlesource.com/chromiumos/platform/depthcharge/+/refs/heads/master/board/bob/defconfig#11
- 0x100 padding for fit image.
- make chromebook_bob_defconfig
- make

2. Create Fit Image (some hints taken from
https://wiki.debian.org/InstallingDebianOn/Asus/C101PA)
- Using the following .its
```
/dts-v1/;

/ {
description = "U-Boot + FDT  THIS PADDING IS NEEDED SO THE
IMAGE STARTS AT THE RIGHT OFFSET";
#address-cells = <1>;

images {

kernel@1 {
description = "kernel";
data = /incbin/("../../u-boot.bin");
type = "kernel_noload";
os = "linux";
arch = "arm64";
compression = "none";
load = <0>;
entry = <0>;
};
fdt@1 {
description = "rk3399-gru-bob.dtb";
data = /incbin/("../../arch/arm/dts/rk3399-gru-bob.dtb");
type = "flat_dt";
arch = "arm64";
compression = "none";
hash@1 {
algo = "sha1";
};
};

};
configurations {
default = "conf@1";
conf@1 {
kernel = "kernel@1";
fdt = "fdt@1";
};

};

};
```

- mkimage -D "-I dts -O dtb -p 2048" -f
doc/chromium/chromebook_bob.its ./u-boot-chromium.fit

- Made sure that the offset is 0x100

```
[sahaj@fedora-work u-boot]$ hexdump u-boot.bin | head
000 000a 1400 201f d503 0100 2000  

[sahaj@fedora-work u-boot]$ hexdump u-boot-chromium.fit | head -20

0e0  0300  0700   656b 6e72
0f0 6c65   0300 0b00 842c  1b00
100 000a 1400 201f d503 0100 2000  
110 33f8 000a   33f8 000a  
120 0a18 000c   003c 1400 76a0 1000
130 4241 d538 303f f100 00a0 5400 203f f100
[sahaj@fedora-work u-boot]$
```

- Created bootloader offset: dd if=/dev/zero of=bootloader.bin bs=512 count=1

- Build image: vbutil_kernel --pack u-boot.kpart --version 1 --vmlinuz
u-boot-chromium.fit --arch aarch64 --keyblock
doc/chromium/devkeys/kernel.keyblock --signprivate
doc/chromium/devkeys/kernel_data_key.vbprivk --config dummy.txt
--bootloader bootloader.bin


3. Flash and boot:

- SDCard kernel part: cgpt add -i 1 -t kernel -b 8192 -s 65536 -l
Kernel -S 1 -T 5 -P 10 /dev/sda
- sudo dd if=u-boot.kpart of=/dev/sdd1
- On the dev mode screen select ctrl+u
- ttyUSB1 (AP COnsole) remains blank
- power led is solid
- keep power button pressed for 10 sec for poweroff



On Fri, 22 Nov 2019 at 03:53, Simon Glass  wrote:
>
> +U-Boot Mailing List
> Please do copy the mailing list on each message.
>
> On Wed, 20 Nov 2019 at 17:16, Sahaj Sarup  wrote:
> >
> >
> >
> > On Tue, Nov 19, 2019, 06:51 Simon Glass  wrote:
> >>
> >> Hi Sahaj,
> >>
> >> On Mon, 18 Nov 2019 at 00:09, Sahaj Sarup  wrote:
> >> >
> >> > see in-line...
> >> >
> >> > On Mon, 18 Nov 2019 at 11:16, Simon Glass  wrote:
> >> > >
> >> > > Hi Sahaj,
> >> > >
> >> > > On Sun, 17 Nov 2019 at 21:33, Sahaj Sarup  wrote:
> >> > > >
> >> > > > Hi All,
> >> > > >
> >> > > > I was wondering if you could answer a few questions regarding u-boot
> >> > > > on Asus CP101 gru/bob ?
> >> > > >
> >> > > > - To test the u-boot image following README.chromium-chainload,
> >> > > > should I expect output on the display or do I need
> >> > > > CDD/SuzyQable Cable for serial?
> >> > >
> >> > > The display should work OK. I don't think that device supports CCD.
> >> >
> >> > Well since the display is blank and the uboot.bin and uboot.fit have
> >> > a correct 0x100 offset, I'll need to wait for my CCD cable to arrive.
> >> > Bob in fact supports ccd:
> >> > https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices
> >> > Although, i am confused as well since edp is supported, at least in
> >> > the dts files.
> >>
> >> Then I suspect it is broken.
> >
> >
> > Not broken, doesn't exist. The Edp driver is only for rk3288. I'm guessing 
> > they use the same ip, but soc specific stuff needs to be added for 3399.
> >
> > I was taking a look at rockchip's u-boot fork, looks like they are using 
> > drm for display now.
>
> OK I see,
>
> Regards,
> Simon



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

Re: [U-Boot] [PATCH v5 006/101] net: Move the checksum functions to lib/

[Joseph Hershberger]

> -Original Message-
> From: Simon Glass 
> Sent: Sunday, November 24, 2019 10:09 PM
> To: U-Boot Mailing List 
> Cc: Bin Meng ; Simon Glass ;
> Joseph Hershberger 
> Subject: [EXTERNAL] [PATCH v5 006/101] net: Move the checksum functions
> to lib/
> 
> These functions are used by code outside the network support, so move
> them to lib/ to be more accessible.
> 
> Without this, the functions are only accessible if CONFIG_NET is defined.
> Many boards do not enable that option but still want to do checksums in this
> format.
> 
> Fix up a few code-style nits while we are here.
> 
> Signed-off-by: Simon Glass 

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

Re: [U-Boot] [PATCH v4 1/2] disk: update to use SPL_PARTITIONS for SPL

[Tom Rini]

On Thu, Nov 28, 2019 at 11:06:41AM +0800, Kever Yang wrote:
> Hi Tom, Simon
>   ping...
>   Is it OK to merge this patch?
> 
> Thanks
> - Kever
> 
> Kever Yang  于2019年8月15日周四 下午4:32写道：
> 
> > The SPL disk driver can not depends on SPL_FRAMEWORK & PARTITIONS, which
> > will enable the disk driver when we actually not need it. Use a separate
> > Kconfig to control the partition driver in SPL and fix the issue caused by:
> > Fixes: 91ff686562 ("blk: Rework guard around part_init call")
> >
> > Signed-off-by: Kever Yang 
> > Reviewed-by: Simon Glass 
> > ---
> >
> > Changes in v4:
> > - format the commit message to ~75 columns.
> >
> > Changes in v3:
> > - update code in blk-uclass.c
> >
> > Changes in v2:
> > - add this patch
> >
> >  common/spl/Kconfig |  2 +-
> >  disk/Kconfig   | 20 
> >  disk/Makefile  |  2 +-
> >  drivers/block/blk-uclass.c |  2 +-
> >  scripts/Makefile.spl   |  2 +-
> >  5 files changed, 16 insertions(+), 12 deletions(-)
> >
> > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > index 5978fb2934..094680e54d 100644
> > --- a/common/spl/Kconfig
> > +++ b/common/spl/Kconfig
> > @@ -544,7 +544,7 @@ config SPL_LIBCOMMON_SUPPORT
> >
> >  config SPL_LIBDISK_SUPPORT
> > bool "Support disk partitions"
> > -   select PARTITIONS
> > +   select SPL_PARTITIONS
> > help
> >   Enable support for disk partitions within SPL. 'Disk' is
> > something
> >   of a misnomer as it includes non-spinning media such as flash (as
> > diff --git a/disk/Kconfig b/disk/Kconfig
> > index 28fb81c2ee..43e76cb49d 100644
> > --- a/disk/Kconfig
> > +++ b/disk/Kconfig
> > @@ -4,9 +4,7 @@ menu "Partition Types"
> >  config PARTITIONS
> > bool "Enable Partition Labels (disklabels) support"
> > default y
> > -   select SPL_SPRINTF if SPL
> > select TPL_SPRINTF if TPL
> > -   select SPL_STRTO if SPL
> > select TPL_STRTO if TPL
> > help
> >   Partition Labels (disklabels) Supported:
> > @@ -23,6 +21,12 @@ config PARTITIONS
> >   you must configure support for at least one non-MTD partition
> > type
> >   as well.
> >
> > +config SPL_PARTITIONS
> > +   select SPL_SPRINTF
> > +   select SPL_STRTO
> > +   bool "Enable Partition Labels (disklabels) support for SPL"
> > +   depends on SPL
> > +
> >  config MAC_PARTITION
> > bool "Enable Apple's MacOS partition table"
> > depends on PARTITIONS
> > @@ -32,7 +36,7 @@ config MAC_PARTITION
> >
> >  config SPL_MAC_PARTITION
> > bool "Enable Apple's MacOS partition table for SPL"
> > -   depends on SPL && PARTITIONS
> > +   depends on SPL_PARTITIONS
> > default y if MAC_PARTITION
> >
> >  config DOS_PARTITION
> > @@ -45,7 +49,7 @@ config DOS_PARTITION
> >
> >  config SPL_DOS_PARTITION
> > bool "Enable MS Dos partition table for SPL"
> > -   depends on SPL && PARTITIONS
> > +   depends on SPL_PARTITIONS
> > default y if DOS_PARTITION
> >
> >  config ISO_PARTITION
> > @@ -56,7 +60,7 @@ config ISO_PARTITION
> >
> >  config SPL_ISO_PARTITION
> > bool "Enable ISO partition table for SPL"
> > -   depends on SPL && PARTITIONS
> > +   depends on SPL_PARTITIONS
> >
> >  config AMIGA_PARTITION
> > bool "Enable AMIGA partition table"
> > @@ -67,7 +71,7 @@ config AMIGA_PARTITION
> >
> >  config SPL_AMIGA_PARTITION
> > bool "Enable AMIGA partition table for SPL"
> > -   depends on SPL && PARTITIONS
> > +   depends on SPL_PARTITIONS
> > default y if AMIGA_PARTITION
> >
> >  config EFI_PARTITION
> > @@ -111,7 +115,7 @@ config EFI_PARTITION_ENTRIES_OFF
> >
> >  config SPL_EFI_PARTITION
> > bool "Enable EFI GPT partition table for SPL"
> > -   depends on  SPL && PARTITIONS
> > +   depends on  SPL_PARTITIONS
> > default y if EFI_PARTITION
> >
> >  config PARTITION_UUIDS
> > @@ -125,7 +129,7 @@ config PARTITION_UUIDS
> >
> >  config SPL_PARTITION_UUIDS
> > bool "Enable support of UUID for partition in SPL"
> > -   depends on SPL && PARTITIONS
> > +   depends on SPL_PARTITIONS
> > default y if SPL_EFI_PARTITION
> >
> >  config PARTITION_TYPE_GUID
> > diff --git a/disk/Makefile b/disk/Makefile
> > index ccd0335959..92fcc2b4ac 100644
> > --- a/disk/Makefile
> > +++ b/disk/Makefile
> > @@ -5,7 +5,7 @@
> >
> >  #ccflags-y += -DET_DEBUG -DDEBUG
> >
> > -obj-$(CONFIG_PARTITIONS)   += part.o
> > +obj-$(CONFIG_$(SPL_)PARTITIONS)  += part.o
> >  obj-$(CONFIG_$(SPL_)MAC_PARTITION)   += part_mac.o
> >  obj-$(CONFIG_$(SPL_)DOS_PARTITION)   += part_dos.o
> >  obj-$(CONFIG_$(SPL_)ISO_PARTITION)   += part_iso.o
> > diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
> > index c23b6682a6..425ec3259f 100644
> > --- a/drivers/block/blk-uclass.c
> > +++ b/drivers/block/blk-uclass.c
> > @@ -649,7 +649,7 @@ int blk_unbind_all(int if_type)
> >
> >  static int 

[U-Boot] [PATCH] ARM: DRA7: Fixup DSP OPP_HIGH clock rate on DRA76P/DRA77P SoCs

[Suman Anna]

The commit 1b42ab3eda8a ("ARM: DRA7: Fixup DSPEVE, IVA and GPU clock
frequencies based on OPP") added the core logic to update the kernel
device-tree blob to adjust the DSP, IVA and GPU DPLL clocks based on
a one-time OPP choice selected in U-Boot for most of the DRA7xx/AM57xx
family of SoCs.

The DSPs on DRA76xP/DRA77xP SoCs (DRA76x ACD package SoCs) though
provide a higher performance and can run at a higher clock frequency
of 850 MHz at OPP_HIGH instead of 750 MHz. Fix up the logic to use the
correct clock rates on these SoCs. Note that this higher clock rate is
not applicable to other Jacinto 6 Plus SoCs (DRA75xP/DRA74xP SoCs or
AM574x SoCs) that follow the ABZ package.

Signed-off-by: Suman Anna 
---
 arch/arm/mach-omap2/omap5/fdt.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/mach-omap2/omap5/fdt.c b/arch/arm/mach-omap2/omap5/fdt.c
index 8dee555c10c6..5ba8806dd744 100644
--- a/arch/arm/mach-omap2/omap5/fdt.c
+++ b/arch/arm/mach-omap2/omap5/fdt.c
@@ -180,6 +180,14 @@ u32 dra7_opp_dsp_clk_rates[NUM_OPPS][OPP_DSP_CLK_NUM] = {
{75000, 75000, 5}, /* OPP_HIGH */
 };
 
+/* DSP clock rates on DRA76x ACD-package based SoCs */
+u32 dra76_opp_dsp_clk_rates[NUM_OPPS][OPP_DSP_CLK_NUM] = {
+   {}, /* OPP_LOW */
+   {6, 6, 4}, /* OPP_NOM */
+   {7, 7, 46667}, /* OPP_OD */
+   {85000, 85000, 56667}, /* OPP_HIGH */
+};
+
 /* IVA voltage domain */
 u32 dra7_opp_iva_clk_rates[NUM_OPPS][OPP_IVA_CLK_NUM] = {
{}, /* OPP_LOW */
@@ -257,6 +265,10 @@ static void ft_opp_clock_fixups(void *fdt, bd_t *bd)
/* fixup DSP clocks */
clk_names = dra7_opp_dsp_clk_names;
clk_rates = dra7_opp_dsp_clk_rates[get_voltrail_opp(VOLT_EVE)];
+   /* adjust for higher OPP_HIGH clock rate on DRA76xP/DRA77xP SoCs */
+   if (is_dra76x_acd())
+   clk_rates = dra76_opp_dsp_clk_rates[get_voltrail_opp(VOLT_EVE)];
+
ret = ft_fixup_clocks(fdt, clk_names, clk_rates, OPP_DSP_CLK_NUM);
if (ret) {
printf("ft_fixup_clocks failed for DSP voltage domain: %s\n",
-- 
2.23.0

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

Re: [U-Boot] [PATCH] spi: cadence_qspi_apb: fix QSPI write issues

[Simon Goldschmidt]

Am 22.11.2019 um 03:03 schrieb Tan, Ley Foon:




-Original Message-
From: Ooi, Joyce 
Sent: Thursday, November 21, 2019 10:42 PM
To: Jagan Teki 
Cc: Tan, Ley Foon ; Ang, Chee Hong
; Ooi, Joyce ; u-
b...@lists.denx.de
Subject: [PATCH] spi: cadence_qspi_apb: fix QSPI write issues

From: Chee Hong Ang 

QSPI driver perform chip select on every flash read/write access. The driver
need to disable/enable the QSPI controller while performing chip select. This
may cause some data lost especially the QSPI controller is configured to run
at slower speed as it may take longer time to access the flash device.
This patch prevent the driver from disable/enable the QSPI controller too
soon and inadvertently halting any ongoing flash read/write access by
ensuring the QSPI controller is always in idle mode after each read/write
access.

Signed-off-by: Chee Hong Ang 
Signed-off-by: Ooi, Joyce 


Reviewed-by: Ley Foon Tan 


Reviewed-by: Simon Goldschmidt 




---
  drivers/spi/cadence_qspi_apb.c | 9 +
  1 file changed, 9 insertions(+)

diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index 55a7501..ab14a5f 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -676,6 +676,10 @@ int
cadence_qspi_apb_indirect_read_execute(struct cadence_spi_platdata *plat,
writel(CQSPI_REG_INDIRECTRD_DONE,
   plat->regbase + CQSPI_REG_INDIRECTRD);

+   /* Wait til QSPI is idle */
+   if (!cadence_qspi_wait_idle(plat->regbase))
+   return -EIO;
+
return 0;

  failrd:
@@ -782,6 +786,11 @@ int
cadence_qspi_apb_indirect_write_execute(struct cadence_spi_platdata
*plat,
   plat->regbase + CQSPI_REG_INDIRECTWR);
if (bounce_buf)
free(bounce_buf);
+
+   /* Wait til QSPI is idle */
+   if (!cadence_qspi_wait_idle(plat->regbase))
+   return -EIO;
+
return 0;

  failwr:
--
1.9.1


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



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

Re: [U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Simon Goldschmidt]

Am 02.12.2019 um 17:10 schrieb Ang, Chee Hong:

On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong 
wrote:



On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong

wrote:



On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong

wrote:



On Mon, Dec 2, 2019 at 11:25 AM 

wrote:


From: "Ang, Chee Hong" 

New U-boot flow with ARM Trusted Firmware (ATF) support:
SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) ->
Linux
(EL1)


Adding support for ATF means that using U-Boot on Stratix10
and Agilex without ATF keeps working, right?

ATF is needed in order for Stratix10 and Agilex's U-Boot to work.


Is there a technical requirement for that?

Yes. We are using ATF to provide PSCI services such as system
reset (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in Linux) and
other secure services such as mailbox communications with Secure
Device Manager and accessing the System Manager registers which are

secure.

Without PSCI services, we are able to boot until U-Boot proper only.
Currently, our U-Boot in mainline doesn't boot to Linux due to
these missing

PSCI services.

Another reason is we have another boot flow which is using ATF + UEFI.
So now we are re-using the PSCI services from ATF so that now
U-Boot and UEFI share the same ATF-BL31 image so that we don't
have to

reimplement another sets of PSCI services for U-Boot again.

This will greatly reduce our engineering efforts.


Hmm, thanks for the explanation.

I don't really think I can review this, given the lack of knowledge
about that PSCI stuff.

I believe you can review it.
Have you briefly gone through the patches ? It has nothing to do with the PSCI

stuff.

It just call the invoke_smc() function to call the ATF's PSCI
functions. Those PSCI functions in ATF will do the rest.


No, not yet. But see below.



I must say it seems strange to me that U-Boot would have to rely on ATF

though.

How do other platforms implement this? Shouldn't PSCI be generic or
is it really platform specific? If it's generic, isn't that a
dupliation of code if you implement e.g. a reset driver for Stratix10 but call

into PSCI?

It's not strange at all.  A lot of U-Boot users already using this boot flow 
(ATF +

U-Boot).

Just because other boards do this doesn't mean it's not strange. Wasn't there
some kind of discussion around that PSCI stuff to make it available from U-Boot?
What's wrong with that way?

Our downstream U-Boot branch is already implemented the PSCI stuffs in U-Boot.
I tried to upstream my PSCI code:
https://lists.denx.de/pipermail/u-boot/2019-May/368822.html

Marek pointed me to this thread:
https://www.mail-archive.com/u-boot@lists.denx.de/msg319458.html

He had a point. He suggested maybe we can implement the PSCI stuffs in SPL/TPL. 
I took a look at the U-Boot code and found out
ATF is already well supported. Why don't we just use the PSCI code from ATF 
rather than re-implementing the PSCI code again in SPL/TPL.
It will save our effort to maintain two PSCI code in U-Boot and ATF while we 
already have the ATF PSCI implementation to support UEFI.


It seems to me we do have working code in U-Boot, what's missing is 
"only" to turn it ino PSCI?


And given U-Boot aims to support UEFI (kind of?), I'd rather argue: why 
do you need ATF at all?


Indeed, having the same code in both seems like double effort for 
maintenance.




In my opinion, you're reducing functionality in U-Boot by making ATF a
requirement.

And by saying "I can't review this", I mean this looks like a questionable way 
to
me and I'm not the one to say if a U-Boot board should go this way or not.

I understand. Btw, who should I include to review this ?



Yes. PSCI is a generic software interface which encapsulate the platform

specific code.

Let me give you a good example in one of your sysreset driver you have

implemented for S10.


#include 
#include 
#include 
-#include 

  static int socfpga_sysreset_request(struct udevice *dev,
 enum sysreset_t type)  {
  -  puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
  -  mbox_reset_cold();
  +  psci_system_reset();


And coming back on this, the sysreset driver won't work in SPL any more, 
right?




So this is not an socfgpa_s10 specific driver any more, right?


 return -EINPROGRESS;
  }

Above is the changes in one of my patchsets, the sysreset driver for
S10 used to call mbox_reset_cold() to send mailbox message to Secure
Device Manager
(SDM) to trigger COLD reset.
Calling 'mbox_reset_cold()' means you are calling platform specific
code in the sysreset driver to perform COLD reset. What if method to trigger

COLD reset is changed in new platform ?

We have to change the sysreset driver code to support another new platform.
If this function call is replaced with "psci_system_reset()", we don't
have to change the code at all because all the platform specific code
for COLD reset is now reside in ATF because this function just invoke
the PSCI function provided by ATF. You just have to replace the 

Re: [U-Boot] [RESEND PATCH] net: tftp: Fix tftp store address check in store_block()

[Joe Hershberger]

Hi Bin,

On Sun, Dec 1, 2019 at 7:46 PM Bin Meng  wrote:
>
> Hi Joe,
>
> On Wed, Nov 20, 2019 at 5:54 AM Joe Hershberger  
> wrote:
> >
> > On Sat, Nov 16, 2019 at 12:20 AM Bin Meng  wrote:
> > >
> > > During testing of qemu-riscv32 with a 2GiB memory configuration,
> > > tftp always fails with a error message:
> > >
> > >   Load address: 0x8400
> > >   Loading: #
> > >   TFTP error: trying to overwrite reserved memory...
> > >
> > > It turns out the result of 'tftp_load_addr + tftp_load_size' just
> > > overflows (0x1) and the test logic in store_block() fails.
> > > Fix this by adjusting the end address to ULONG_MAX when overflow
> > > is detected.
> > >
> > > Fixes: a156c47e39ad ("tftp: prevent overwriting reserved memory")
> > > Signed-off-by: Bin Meng 
> >
> > Odd corner case, but sure...
> >
> > Acked-by: Joe Hershberger 
>
> Could you pull this for v2020.01? thanks!

Yep, working on it!

I'm currently looking for the patches that are causing sizes to expand
beyond linking on a few targets.

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

Re: [U-Boot] [PATCH v2] spl: Allow cache drivers to be used in SPL

[Simon Goldschmidt]

Am 02.12.2019 um 17:01 schrieb Tom Rini:

On Fri, Nov 29, 2019 at 09:59:26AM +0800, Ley Foon Tan wrote:


Add an option for building cache drivers in SPL.

Signed-off-by: Ley Foon Tan 



Reviewed-by: Tom Rini 



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

Re: [U-Boot] [PATCH v4 2/2] cmd: Add dtimg command

[Sam Protsenko]

Hi Eugeniu,

On Thu, Nov 14, 2019 at 12:58 AM Eugeniu Rosca  wrote:
>
> Hi Roman,
> (CC-ing Igor for Android topics)
>
> On Wed, Nov 13, 2019 at 12:19:59PM +0200, Roman Stratiienko wrote:
> > On Tue, Nov 12, 2019 at 8:18 PM Eugeniu Rosca  wrote:
> > >
> > > Hello Sam,
> > >
> > > On Thu, Aug 16, 2018 at 11:34:13PM +0300, Sam Protsenko wrote:
> > > > dtimg command allows user to work with Android DTB/DTBO image format.
> > > > Such as, getting the address of desired DTB/DTBO file, printing the dump
> > > > of the image in U-Boot shell, etc.
>
> [..]
>
> > > Since you are the author and the main stakeholder of "dtimg", could you
> > > kindly feedback the command usage you envision for getting the start and
> > > size of dtb/dtbo blob given a certain "id" and "rev" fields used by
> > > mkdtboimg.py [1] and visible in the output of U-Boot's "dtimg dump" [2]?
> > >
> > > One option would be to extend the existing "dtimg {start|size}" to
> > > accept an argument like "id:" and "rev:".
> > >
> > > Another possibility is to create brand new dtimg sub-command.
> > > What would be your preference? TIA.
> > >
> > > [1] 
> > > https://android.googlesource.com/platform/system/libufdt/+/master/utils/src/mkdtboimg.py
> > > [2] https://gitlab.denx.de/u-boot/u-boot/commit/e63bf1b13b3a7a
> >
> > Let me add some background information to clarify why new command was 
> > suggested.
> > We came up with this during brainstorming on what is the best way to
> > implement lookup fdt by id and rev fields.
> >
> > First suggestion was to implement separate lookup command, e.g.:
> >
> > --> dtimg lookup id: 
> >
> > Second one was to integrate it into existing start/size command to
> > make command look more natural:
> >
> > --> dtimg start|size  [|id:] 
> >
> > Then after some time I suggested to combine 'start/size' subcommands
> > into single 'range' subcommand:
> >
> > --> dtimg range  id: [rev:] [ 
> > []]
> > --> dtimg range  index: [ []]
> >
> > Benefits of such combining:
> > - Reduce chance of human mistake in between of this commands (for
> > example different values for start and size).
> > - Increase readability and slightly reduce parsing time.
> >
> > Downsides:
> > This solution is a little revolutionary since it requires to start
> > long-term deprecation process of start/size subcommands.
>
> So, what you are proposing is to migrate away from the "start" and
> "size" sub-commands in the long run. While I understand the good
> intentions, let me share my opinion what this means for platform
> maintainers like us.
>
> As a platform maintainer, it is not uncommon to encounter a scenario
> like below:
>  - platform X reached "feature freeze" one year ago with U-Boot v2018.11
>  - platform Y reaches "feature freeze" soon with U-Boot v2020.01
>
> If "dtimg" is used in both platforms and the command usage is not
> backward compatible, this generates all kind of overhead like the need
> to maintain two different versions of boot scripts (in case you keep
> track of them externally as text files, which is what we do).
>
> This is hugely simplified involving one single command. Imagine
> several U-Boot commands fundamentally changing their usage pattern
> over time. Things would become pretty messy.
>
> >
> > So the main question to the community is next:
> > Are we ready to make long term deprecation in the name of benefits
> > mentioned above?
>
> I hope more people will feedback on that, but in my opinion, we have to
> honor the existing "dtimg" usage as a blueprint and carefully add
> backward-compatible changes to it. This roughly translates to, IMHO:
>  - in case of adding a brand new sub-command, it must not overlap in
>its function with any of pre-existing sub-commands
>  - in case of enriching/extending a pre-existing sub-command, it only
>sounds appropriate to me adding one or more _optional_ arguments to
>maintain backward compatibility
>

We should never change any commands (user interface), unless they are
deprecated / completely broken / etc. So although it might be seen as
more logical to modify existing 'dtimg' commands, we shouldn't do that
if it's breaking existing user interfaces. It's similar to golden
kernel rule ("we don't break user space"). Hence new sub-commands
(probably) should be added. Sorry, I didn't have much time to read the
whole discussion yet. But please stick to next two rules:

   1. Don't break existing interface; change it only in
backward-compatible manner
   2. Don't introduce non-standard extensions or non-standard
usage/namings to 'dtimg'. If you add some functionality, it must be
present in official Android DTBO format documentation, and we should
stick to namings suggested there.

Not asking that as 'dtimg' original author (it doesn't matter much),
but I think it's just a common sense in projects as big as U-Boot or
Linux kernel. And you correctly pointed out all possible implications,
so I have nothing to add on that matter.

I'm gonna review the whole discussion and 

Re: [U-Boot] [PATCH v2 3/8] cmd: bootimg: Add bootimg command

[Sam Protsenko]

Hi Eugeniu,

On Wed, Nov 27, 2019 at 9:17 PM Eugeniu Rosca  wrote:
>
> Hi Sam,
>
> On Wed, Oct 23, 2019 at 05:34:22PM +0300, Sam Protsenko wrote:
> > +static int do_bootimg_get_dtb_file(cmd_tbl_t *cmdtp, int flag, int argc,
> > +char * const argv[])
> > +{
> > + char *endp;
> > + char buf[65];
> > + u32 index;
> > + ulong addr;
> > + u32 size;
> > +
> > + if (argc < 3 || argc > 4)
> > + return CMD_RET_USAGE;
> > +
> > + index = simple_strtoul(argv[1], , 0);
> > + if (*endp != '\0') {
> > + printf("Error: Wrong index\n");
> > + return CMD_RET_FAILURE;
> > + }
> > +
> > + if (!android_image_get_dtb_by_index(bootimg_addr(), index, ,
> > + ))
>
> As discussed in https://patchwork.ozlabs.org/patch/958594/#2302310, we
> try to enhance the "dtimg" U-Boot command to be able to identify DT
> blobs by "id" or "rev" [*] field value.
>
> It's quite challenging in this context to avoid conflicting with your
> recently proposed "bootimg" command, since the latter makes use of the
> android_image_get_dtb_by_index API, which is subject of modification
> and/or renaming.
>
> I am willing to cooperate to entirely avoid or reconcile the conflict
> in the best possible way, but for that I need your feedback.
>

I'd like this patch series to be applied ASAP (probably before DTBO
patches you mention are merged). It's been too long as it is. Once
merged and we are unblocked w.r.t. Android boot stuff, we can then
look into DTBO changes you mention, and if any C API are changed, we
can change those usage overall the U-Boot tree. Hope you agree. I will
help you guys to figure out all DTBO related changes further, but
please let's get this patch series over with...

Thanks!

> [*] https://source.android.google.cn/devices/architecture/dto/partitions
>
> --
> Best Regards,
> Eugeniu
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 2/2] ARM: dts: imx6ull-colibri: pre-reloc for uart pinmux modes

[Stefano Babic]

Hi Igor,

On 03/11/19 17:21, Igor Opaniuk wrote:
> Hi Stefano,
> 
> On Wed, Oct 16, 2019 at 12:39 PM Igor Opaniuk  wrote:
>>
>> From: Igor Opaniuk 
>>
>> Add u-boot,dm-pre-reloc properties for uart pinmux configuration
>> nodes, which enables UART as early as possible (before relocation).
>>
>> Without this we miss almost the half of output (U-boot version,
>> CPU defails, Reset cause, DRAM details etc.).
>>
>> Fixes: cd69e8ef9b ("colibri-imx6ull: migrate pinctrl and regulators to 
>> dtb/dm")
>> Reviewed-by: Oleksandr Suvorov 
>> Reviewed-by: Fabio Estevam 
>> Signed-off-by: Igor Opaniuk 
>> ---
>>
>>  arch/arm/dts/imx6ull-colibri-u-boot.dtsi | 8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/arm/dts/imx6ull-colibri-u-boot.dtsi 
>> b/arch/arm/dts/imx6ull-colibri-u-boot.dtsi
>> index e81ac8cb27..531cdcc4da 100644
>> --- a/arch/arm/dts/imx6ull-colibri-u-boot.dtsi
>> +++ b/arch/arm/dts/imx6ull-colibri-u-boot.dtsi
>> @@ -2,3 +2,11 @@
>>  /*
>>   * Copyright 2019 Toradex AG
>>   */
>> +
>> +_uart1 {
>> +   u-boot,dm-pre-reloc;
>> +};
>> +
>> +_uart1_ctrl1 {
>> +   u-boot,dm-pre-reloc;
>> +};
>> --
>> 2.17.1
>>
> 
> Could you please also apply this patchset?
> 

This patchset is in "Changes requested" in patchwork. I tried to pick
them up and patches need a rebase on current master. Can you rebase them
and repost ? Thanks !

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

Re: [U-Boot] [NXP-IMX] please pull imx-master-11-21

[Fabio Estevam]

Hi Stefano,

On Mon, Dec 2, 2019 at 2:40 PM Stefano Babic  wrote:

> I am fine, thanks.

Excellent!

Please ping me when all my i.MX7ULP patches have been applied to your
tree and then I will submit an updated version of the i.MX7ULP
Embedded Artists board patch.

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

Re: [U-Boot] [NXP-IMX] please pull imx-master-11-21

[Stefano Babic]

On 02/12/19 18:28, Fabio Estevam wrote:
> Hi Stefano,
> 
> On Mon, Dec 2, 2019 at 2:04 PM Stefano Babic  wrote:
> 
>> About mx7ulp (and warp7,
>>
>> Tom has merged this one:
>>
>> commit a09fea1d28fe3c69a64bee092f5a764274d26ca2
>> Author: Tom Rini 
>> Date:   Mon Nov 18 20:02:10 2019 -0500
>>
>> env: Finish migration of common ENV options
>>
>> This drop CONFIG_ENV_SIZE from boards' header. If I merge your PR and
>> the fix for warp7, I will reintroduce the CONFIG_ENV_*Ü, and it is like
>> to do against Tom's patch. I think you should rework them to avoid the
>> reintroduction in the header file.
> 
> Could you please apply all the i.MX7ULP except the one that introduce
> the i.MX7ULP Embedded Artists COM board?
> 
> I can rework this last patch to not have CONFIG_ENV_SIZE in the header file.
> 
> Please let me know if you are OK with this.

I am fine, thanks.

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

Re: [U-Boot] [PATCH v2 7/8] env: ti: boot: Boot Android with dynamic partitions

[Sam Protsenko]

Hi Tom,

On Sun, Nov 3, 2019 at 4:35 PM Tom Rini  wrote:
>
> On Wed, Oct 23, 2019 at 05:34:26PM +0300, Sam Protsenko wrote:
>
> > Changes:
> >   - use boot.img instead of boot_fit.img
> >   - use .dtb from boot.img v2
> >   - implement recovery boot
> >   - always boot ramdisk from boot.img, we can't mount system as root
> > now, as system is a logical partition inside of super partition
> >   - don't add "skip_initramfs" to cmdline anymore
> >   - to boot into recovery, use boot image from recovery partition
> >   - prepare partition table:
> > - A/B scheme
> > - use 'super' partition instead of 'system' and 'vendor'
> > - add dtbo partitions
> > - introduce metadata partition
> >
> > Not implemented: reading and applying dtbo files from dtbo partition.
> >
> > Signed-off-by: Sam Protsenko 
>
> This breaks at least "dra7xx_evm" building:
>arm:  +   dra7xx_evm
> +(dra7xx_evm) In file included from include/configs/ti_omap5_common.h:57:0,
> +(dra7xx_evm)  from include/configs/dra7xx_evm.h:62,
> +(dra7xx_evm)  from include/config.h:5,
> +(dra7xx_evm)  from include/common.h:23,
> +(dra7xx_evm)  from env/common.c:10:
> +(dra7xx_evm) include/environment/ti/boot.h:104:3: error: expected '}' before 
> 'AB_SELECT_SLOT'
> +(dra7xx_evm)AB_SELECT_SLOT \
> +(dra7xx_evm)^
> +(dra7xx_evm) include/configs/ti_omap5_common.h:65:2: note: in expansion of 
> macro 'DEFAULT_COMMON_BOOT_TI_ARGS'
> +(dra7xx_evm)   DEFAULT_COMMON_BOOT_TI_ARGS \
> +(dra7xx_evm)   ^~~
> +(dra7xx_evm) include/env_default.h:111:2: note: in expansion of macro 
> 'CONFIG_EXTRA_ENV_SETTINGS'
> +(dra7xx_evm)   CONFIG_EXTRA_ENV_SETTINGS
> +(dra7xx_evm)   ^
> +(dra7xx_evm) make[2]: *** [env/common.o] Error 1
> +(dra7xx_evm) make[1]: *** [env] Error 2
> +(dra7xx_evm) make[1]: *** wait: No child processes.  Stop.
> +(dra7xx_evm) make: *** [sub-make] Error 2
>

Thanks, will be fixed in new version. I should run buildman more often :)

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

Re: [U-Boot] [NXP-IMX] please pull imx-master-11-21

[Fabio Estevam]

Hi Stefano,

On Mon, Dec 2, 2019 at 2:04 PM Stefano Babic  wrote:

> About mx7ulp (and warp7,
>
> Tom has merged this one:
>
> commit a09fea1d28fe3c69a64bee092f5a764274d26ca2
> Author: Tom Rini 
> Date:   Mon Nov 18 20:02:10 2019 -0500
>
> env: Finish migration of common ENV options
>
> This drop CONFIG_ENV_SIZE from boards' header. If I merge your PR and
> the fix for warp7, I will reintroduce the CONFIG_ENV_*Ü, and it is like
> to do against Tom's patch. I think you should rework them to avoid the
> reintroduction in the header file.

Could you please apply all the i.MX7ULP except the one that introduce
the i.MX7ULP Embedded Artists COM board?

I can rework this last patch to not have CONFIG_ENV_SIZE in the header file.

Please let me know if you are OK with this.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/8] image: android: Add functions for handling dtb field

[Sam Protsenko]

Hi Eugeniu,

On Tue, Oct 29, 2019 at 3:49 AM Eugeniu Rosca  wrote:
>
> Hi Sam,
>
> On Wed, Oct 23, 2019 at 05:34:20PM +0300, Sam Protsenko wrote:
> > Android Boot Image v2 adds "DTB" payload (and corresponding field in the
> > image header). Provide functions for its handling:
>
> I believe this totally new degree of freedom brought by "Android Boot
> Image v2" might unintentionally make some users more unhappy [0], since
> it enables yet another way of passing a DTB to the Android kernel.
>
> It looks to me that there are at least three valid design choices for
> DTB storage/passing which platform maintainers have to consider:
>  A. Android Image second area [1-2]
>  B. Dedicated DTB/DTBO partitions on a block device
>  C. DTB area in Android Image v2
>
> While there are some major disadvantages for [A][1-2], [B] and [C] look
> more or less equivalent and will most likely only differ in the tooling
> used to generate and extract the useful/relevant artifacts.
>
> Not to mention that hybrids [B+C] are also possible.
> Which solution should we pick as a long-term one?
>

My opinion is next: we should provide means (commands) to achieve any
of [A,B,C] options. Then user (I mean, U-Boot developer who implements
boot for each particular board) should decide which approach to use.
Also [D] FIT image can be used instead of Android Boot Image. But we
should remember that Google requires *mandatory* for all *new* devices
(starting with Android 10) to stick with [C] approach only. Option [B]
might be harder to handle from AVB verification point of view. Btw,
when we come to "boot_android" command, I think we'll need to
implement only officially recommended boot method. Maybe provide a
param to choose whether to do Android-9 or Android-10 boot scheme.

Anyway, the short answer is: we should provide a bunch of isolated
commands to allow the user to implement any boot method.

Also, this particular patch doesn't change boot behavior (it only adds
functions to handle dtb field), so it should be backward-compatible.

> [0] https://en.wikipedia.org/wiki/The_Paradox_of_Choice
> [1] 104816142f9c6a ("parse the second area of android image")
> [2] 6a7b406aa8b981 ("fdt: support booting with dtb in Android image")
>
> [..]
>
> >  common/Makefile|   2 +-
> >  common/image-android.c | 215 +
> >  include/image.h|   5 +
> >  3 files changed, 221 insertions(+), 1 deletion(-)
> >
> > diff --git a/common/Makefile b/common/Makefile
> > index 302d8beaf3..7e5f5058b3 100644
> > --- a/common/Makefile
> > +++ b/common/Makefile
> > @@ -108,7 +108,7 @@ endif
> >
> >  obj-y += image.o
> >  obj-$(CONFIG_ANDROID_AB) += android_ab.o
> > -obj-$(CONFIG_ANDROID_BOOT_IMAGE) += image-android.o
> > +obj-$(CONFIG_ANDROID_BOOT_IMAGE) += image-android.o image-android-dt.o
>
> I expect that in a not so distant future, Android users who care
> about performance aspects of their system (e.g. in automotive sector,
> where boot time is paramount to achieve ~2s to Rear View Camera) will
> attempt optimizing U-Boot by compiling out features they don't need.
>
> With this background:
>  - Would it make sense to allow users to selectively enable and disable
>support for A/B-capable and non-A/B devices? My guess is that it
>is currently not an important development/review criteria, since
>particularly image-android-dt.c implements functions, some of which
>are A/B-specific, some non-A/B-specific (e.g. android_image_get_dtbo)
>and some are common.
>  - I would try to avoid wiring the same compilation unit to Kbuild
>(e.g. image-android-dt.o) via multiple Kconfig symbols
>(CONFIG_ANDROID_BOOT_IMAGE and CONFIG_CMD_DTIMG) since this makes
>the relationship between the CONFIG symbols unclear. As a user, I
>would like to see a simple mapping between compiled objects and
>Kconfig symbols, eventually reflecting a hierarchy/dependency:
>
>config ANDROID_BOOT_IMAGE
>   select ANDROID_BOOT_IMAGE_DT
>
>config DTIMG
>   select ANDROID_BOOT_IMAGE_DT
>

I thought about that 4 months ago when implementing this patch, even
experimented with that. But decided to just add image-android-dt.o in
Makefile instead, don't remember for what reason exactly. Frankly,
don't really want to go there again and spend too much time (at least
not in the context of this patch series).

So here is what I suggest: can we approach this one-step-at-a-time?
This patch-set is a major step as it is, and it takes a lot of time to
get it merged. What you suggest makes sense but might have some
implications (even architectural) when trying to implement that. Can
we do that in another series?

> [..]
>
> > diff --git a/common/image-android.c b/common/image-android.c
> > index 3564a64221..5e721a27a7 100644
> > --- a/common/image-android.c
> > +++ b/common/image-android.c
> > @@ -6,10 +6,12 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > 

Re: [U-Boot] [NXP-IMX] please pull imx-master-11-21

[Stefano Babic]

On 22/11/19 07:42, Peng Fan wrote:
> Hi Stefano,
> 
> Please pull imx-master-11-21, based on imx/master.
> CI: https://travis-ci.org/MrVan/u-boot/builds/614830163
> 
> 
> i.mx6qp noc settings
> i.mx7ulp update and artists com board support
> 
> 
> Thanks,
> Peng.
> 

About mx7ulp (and warp7,

Tom has merged this one:

commit a09fea1d28fe3c69a64bee092f5a764274d26ca2
Author: Tom Rini 
Date:   Mon Nov 18 20:02:10 2019 -0500

env: Finish migration of common ENV options

This drop CONFIG_ENV_SIZE from boards' header. If I merge your PR and
the fix for warp7, I will reintroduce the CONFIG_ENV_*Ü, and it is like
to do against Tom's patch. I think you should rework them to avoid the
reintroduction in the header file.

I will just pick up myself i.mx6qp patch.

Regards,
Stefano

> The following changes since commit bdcf3a88cc582ce8bb9ea024fa917d9a52e05479:
> 
>   imx: imx8mm-evk: enable ethernet (2019-11-05 10:27:18 +0100)
> 
> are available in the Git repository at:
> 
>   https://github.com/MrVan/u-boot.git imx-master-11-21
> 
> for you to fetch changes up to 153d06d07d6827460e62045bd51083e64a727648:
> 
>   mx6cuboxi: Add Baruch as maintainer (2019-11-21 09:50:23 +0800)
> 
> 
> Fabio Estevam (8):
>   mx6: Allow configuring the NoC registers on i.MX6QP
>   mx7ulp: Print the LDO mode status
>   mx7ulp: Introduce the CONFIG_LDO_ENABLED_MODE option
>   mx7ulp: Remove the _RUN notation from the PMC1 LDOVL definitions
>   mx7ulp: scg: Remove unnused scg_a7_apll_init()
>   mx7ulp: Sync the device tree related files
>   mx7ulp: Add support for Embedded Artists COM board
>   mx6cuboxi: Add Baruch as maintainer
> 
>  arch/arm/dts/Makefile  |3 +-
>  arch/arm/dts/imx7ulp-com.dts   |   90 +++
>  arch/arm/dts/imx7ulp-evk.dts   |  157 +---
>  arch/arm/dts/imx7ulp-pinfunc.h | 1748 
> ++--
>  arch/arm/dts/imx7ulp.dtsi  |   28 ++-
>  arch/arm/include/asm/arch-mx7ulp/scg.h |1 -
>  arch/arm/mach-imx/mx6/soc.c|   35 +++
>  arch/arm/mach-imx/mx7ulp/Kconfig   |   11 +
>  arch/arm/mach-imx/mx7ulp/scg.c |   61 -
>  arch/arm/mach-imx/mx7ulp/soc.c |   78 ++
>  board/ea/mx7ulp_com/Kconfig|   12 +
>  board/ea/mx7ulp_com/MAINTAINERS|6 +
>  board/ea/mx7ulp_com/Makefile   |6 +
>  board/ea/mx7ulp_com/imximage.cfg   |  128 ++
>  board/ea/mx7ulp_com/mx7ulp_com.c   |   48 
>  board/solidrun/mx6cuboxi/MAINTAINERS   |1 +
>  configs/mx7ulp_com_defconfig   |   59 +
>  include/configs/mx7ulp_com.h   |  107 +
>  18 files changed, 1552 insertions(+), 1027 deletions(-)
>  create mode 100644 arch/arm/dts/imx7ulp-com.dts
>  create mode 100644 board/ea/mx7ulp_com/Kconfig
>  create mode 100644 board/ea/mx7ulp_com/MAINTAINERS
>  create mode 100644 board/ea/mx7ulp_com/Makefile
>  create mode 100644 board/ea/mx7ulp_com/imximage.cfg
>  create mode 100644 board/ea/mx7ulp_com/mx7ulp_com.c
>  create mode 100644 configs/mx7ulp_com_defconfig
>  create mode 100644 include/configs/mx7ulp_com.h
> 


-- 
=
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

[U-Boot] [PATCH] cmd: cp: add missing map_sysmem

[Philippe Reynes]

The command cp fails on sandbox because the address is used
directly. To fix this issue, we call the function map_sysmem
to translate the address.

Signed-off-by: Philippe Reynes 
---
 cmd/mem.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/cmd/mem.c b/cmd/mem.c
index c6b8038..1757c84 100644
--- a/cmd/mem.c
+++ b/cmd/mem.c
@@ -303,6 +303,7 @@ static int do_mem_cmp(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
 static int do_mem_cp(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
ulong   addr, dest, count;
+   void*src, *dst;
int size;
 
if (argc != 4)
@@ -326,25 +327,34 @@ static int do_mem_cp(cmd_tbl_t *cmdtp, int flag, int 
argc, char * const argv[])
return 1;
}
 
+   src = map_sysmem(addr, count * size);
+   dst = map_sysmem(dest, count * size);
+
 #ifdef CONFIG_MTD_NOR_FLASH
/* check if we are copying to Flash */
-   if (addr2info(dest) != NULL) {
+   if (addr2info((ulong)dst)) {
int rc;
 
puts ("Copy to Flash... ");
 
-   rc = flash_write ((char *)addr, dest, count*size);
+   rc = flash_write((char *)src, (ulong)dst, count * size);
if (rc != 0) {
flash_perror (rc);
+   unmap_sysmem(src);
+   unmap_sysmem(dst);
return (1);
}
puts ("done\n");
+   unmap_sysmem(src);
+   unmap_sysmem(dst);
return 0;
}
 #endif
 
-   memcpy((void *)dest, (void *)addr, count * size);
+   memcpy(dst, src, count * size);
 
+   unmap_sysmem(src);
+   unmap_sysmem(dst);
return 0;
 }
 
-- 
2.7.4

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

Re: [U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Ang, Chee Hong]

> On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong 
> wrote:
> >
> > > On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong
> > > 
> > > wrote:
> > > >
> > > > > On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong
> > > > > 
> > > > > wrote:
> > > > > >
> > > > > > > On Mon, Dec 2, 2019 at 11:25 AM 
> wrote:
> > > > > > > >
> > > > > > > > From: "Ang, Chee Hong" 
> > > > > > > >
> > > > > > > > New U-boot flow with ARM Trusted Firmware (ATF) support:
> > > > > > > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) ->
> > > > > > > > Linux
> > > > > > > > (EL1)
> > > > > > >
> > > > > > > Adding support for ATF means that using U-Boot on Stratix10
> > > > > > > and Agilex without ATF keeps working, right?
> > > > > > ATF is needed in order for Stratix10 and Agilex's U-Boot to work.
> > > > >
> > > > > Is there a technical requirement for that?
> > > > Yes. We are using ATF to provide PSCI services such as system
> > > > reset (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in Linux) and
> > > > other secure services such as mailbox communications with Secure
> > > > Device Manager and accessing the System Manager registers which are
> secure.
> > > > Without PSCI services, we are able to boot until U-Boot proper only.
> > > > Currently, our U-Boot in mainline doesn't boot to Linux due to
> > > > these missing
> > > PSCI services.
> > > > Another reason is we have another boot flow which is using ATF + UEFI.
> > > > So now we are re-using the PSCI services from ATF so that now
> > > > U-Boot and UEFI share the same ATF-BL31 image so that we don't
> > > > have to
> > > reimplement another sets of PSCI services for U-Boot again.
> > > > This will greatly reduce our engineering efforts.
> > >
> > > Hmm, thanks for the explanation.
> > >
> > > I don't really think I can review this, given the lack of knowledge
> > > about that PSCI stuff.
> > I believe you can review it.
> > Have you briefly gone through the patches ? It has nothing to do with the 
> > PSCI
> stuff.
> > It just call the invoke_smc() function to call the ATF's PSCI
> > functions. Those PSCI functions in ATF will do the rest.
> 
> No, not yet. But see below.
> 
> > >
> > > I must say it seems strange to me that U-Boot would have to rely on ATF
> though.
> > > How do other platforms implement this? Shouldn't PSCI be generic or
> > > is it really platform specific? If it's generic, isn't that a
> > > dupliation of code if you implement e.g. a reset driver for Stratix10 but 
> > > call
> into PSCI?
> > It's not strange at all.  A lot of U-Boot users already using this boot 
> > flow (ATF +
> U-Boot).
> 
> Just because other boards do this doesn't mean it's not strange. Wasn't there
> some kind of discussion around that PSCI stuff to make it available from 
> U-Boot?
> What's wrong with that way?
Our downstream U-Boot branch is already implemented the PSCI stuffs in U-Boot.
I tried to upstream my PSCI code:
https://lists.denx.de/pipermail/u-boot/2019-May/368822.html

Marek pointed me to this thread:
https://www.mail-archive.com/u-boot@lists.denx.de/msg319458.html

He had a point. He suggested maybe we can implement the PSCI stuffs in SPL/TPL. 
I took a look at the U-Boot code and found out
ATF is already well supported. Why don't we just use the PSCI code from ATF 
rather than re-implementing the PSCI code again in SPL/TPL.
It will save our effort to maintain two PSCI code in U-Boot and ATF while we 
already have the ATF PSCI implementation to support UEFI.
> 
> In my opinion, you're reducing functionality in U-Boot by making ATF a
> requirement.
> 
> And by saying "I can't review this", I mean this looks like a questionable 
> way to
> me and I'm not the one to say if a U-Boot board should go this way or not.
I understand. Btw, who should I include to review this ?
> 
> > Yes. PSCI is a generic software interface which encapsulate the platform
> specific code.
> > Let me give you a good example in one of your sysreset driver you have
> implemented for S10.
> >
> > #include 
> > #include 
> > #include 
> > -#include 
> >
> >  static int socfpga_sysreset_request(struct udevice *dev,
> > enum sysreset_t type)  {
> >  -  puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
> >  -  mbox_reset_cold();
> >  +  psci_system_reset();
> 
> So this is not an socfgpa_s10 specific driver any more, right?
> 
> > return -EINPROGRESS;
> >  }
> >
> > Above is the changes in one of my patchsets, the sysreset driver for
> > S10 used to call mbox_reset_cold() to send mailbox message to Secure
> > Device Manager
> > (SDM) to trigger COLD reset.
> > Calling 'mbox_reset_cold()' means you are calling platform specific
> > code in the sysreset driver to perform COLD reset. What if method to trigger
> COLD reset is changed in new platform ?
> > We have to change the sysreset driver code to support another new platform.
> > If this function call is replaced with "psci_system_reset()", we don't
> > have to change the code at all because all the 

Re: [U-Boot] One u-boot.bin for Raspberry PI 3 and 4 - possible?

[Matthias Brugger]

Hi Geoff,

On 03/10/2019 03:44, Geoff Williams wrote:
>> And with a U-Boot based on f5c626c64874d6e1482edf4a76aa22e5e54be63d without 
>> my
>> patches you see correct behavior?
> 
> The screen turning off issue was caused by a deployment script copying the 
> wrong
> u-boot binary to the SD card! The patch does not introduce a regression on 
> RPI 3
> (tested before/after patch).
> 
> Once I switched over to the the real u-boot image the grub graphical font 
> didn't
> load (irrespective of patch) I was able to fix this by changing the
> rpi_3_defconfig:
> 
> -CONFIG_OF_EMBED=y
> -CONFIG_DEFAULT_DEVICE_TREE="bcm2837-rpi-3-b"
> +CONFIG_OF_BOARD=y
> 
> I suspect my issues are to do with DTBs and that all these problems will go 
> away
> once a single defconfig is available. The screen turning off issue I have no
> idea about but its from a much older version of u-boot and probably relates to
> something in the image I built.
> 

In U-Boot master you should find now a rpi_arm64_defconfig which should boot on
both RPi3 and RPi4.

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

Re: [U-Boot] [PATCH] test.py: Make search for autoconf.mk more permission

[Stephen Warren]

On 12/1/19 7:34 PM, Simon Glass wrote:

Buildman doesn't store this file in the same directory as a normal build.
Update the conftest code to handle both cases.


Shouldn't we just fix buildman so that it puts the files in the standard 
locations? That way, we don't have to separately update every tool that 
might want to find/interpret this file or archive the build results, but 
instead just update one tool (buildman).

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

Re: [U-Boot] [PATCH v2] spl: Allow cache drivers to be used in SPL

[Tom Rini]

On Fri, Nov 29, 2019 at 09:59:26AM +0800, Ley Foon Tan wrote:

> Add an option for building cache drivers in SPL.
> 
> Signed-off-by: Ley Foon Tan 
> 

Reviewed-by: Tom Rini 

-- 
Tom


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

[U-Boot] [PATCHv2] blk: Make use of CONFIG_HAVE_BLOCK_DEVICE more

[Tom Rini]

When we do not have CONFIG_BLK (or SPL/TPL) enabled there are very few
cases where we need the blk_legacy code linked in. To catch these, build
when we have CONFIG_HAVE_BLOCK_DEVICE set.  In addition, we only need
cmd/blk_common.o to be linked in when we have CONFIG_HAVE_BLOCK_DEVICE
set, so make use of that directly.

Signed-off-by: Tom Rini 
---
Changes in v2:
- Reword commit message and make blk_legacy.o also use
  CONFIG_HAVE_BLOCK_DEVICE rather than CONFIG_PARTITIONS as it is more
  direct.
---
 cmd/Makefile   | 2 +-
 cmd/blk_common.c   | 2 --
 drivers/block/Makefile | 2 +-
 3 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/cmd/Makefile b/cmd/Makefile
index 2d723ea0f07d..f823d16755e6 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -15,7 +15,7 @@ obj-$(CONFIG_CMD_AES) += aes.o
 obj-$(CONFIG_CMD_AB_SELECT) += ab_select.o
 obj-$(CONFIG_CMD_ADC) += adc.o
 obj-$(CONFIG_CMD_ARMFLASH) += armflash.o
-obj-y += blk_common.o
+obj-$(CONFIG_HAVE_BLOCK_DEVICE) += blk_common.o
 obj-$(CONFIG_CMD_SOURCE) += source.o
 obj-$(CONFIG_CMD_BCB) += bcb.o
 obj-$(CONFIG_CMD_BDI) += bdinfo.o
diff --git a/cmd/blk_common.c b/cmd/blk_common.c
index cee25a0d4100..c5514cf8f8e8 100644
--- a/cmd/blk_common.c
+++ b/cmd/blk_common.c
@@ -11,7 +11,6 @@
 #include 
 #include 
 
-#ifdef CONFIG_HAVE_BLOCK_DEVICE
 int blk_common_cmd(int argc, char * const argv[], enum if_type if_type,
   int *cur_devnump)
 {
@@ -96,4 +95,3 @@ int blk_common_cmd(int argc, char * const argv[], enum 
if_type if_type,
}
}
 }
-#endif
diff --git a/drivers/block/Makefile b/drivers/block/Makefile
index 3feb0aa997df..94ab5c6f906e 100644
--- a/drivers/block/Makefile
+++ b/drivers/block/Makefile
@@ -6,7 +6,7 @@
 obj-$(CONFIG_$(SPL_)BLK) += blk-uclass.o
 
 ifndef CONFIG_$(SPL_)BLK
-obj-y += blk_legacy.o
+obj-$(CONFIG_HAVE_BLOCK_DEVICE) += blk_legacy.o
 endif
 
 ifndef CONFIG_SPL_BUILD
-- 
2.17.1

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

Re: [U-Boot] [PATCH] arm: dts: bcm283x: Allow UARTs to work before relocation

[Tom Rini]

On Sun, Dec 01, 2019 at 07:33:56PM -0700, Simon Glass wrote:

> At present the pinctrl nodes are not enabled in pre-relocation U-Boot so
> the UARTs do not correctly select the pinconfig to enable the UART pins.
> Fix this so that the U-Boot banner is printed.
> 
> Signed-off-by: Simon Glass 
> Fixes: 9821636b64 (bcm2835_pinctrl: Probe pre-reloc)
> ---
> 
>  arch/arm/dts/bcm283x-u-boot.dtsi | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/dts/bcm283x-u-boot.dtsi 
> b/arch/arm/dts/bcm283x-u-boot.dtsi
> index 36548dad62..68d03627f4 100644
> --- a/arch/arm/dts/bcm283x-u-boot.dtsi
> +++ b/arch/arm/dts/bcm283x-u-boot.dtsi
> @@ -19,3 +19,11 @@
>   {
>   u-boot,dm-pre-reloc;
>  };
> +
> +_gpio14 {
> + u-boot,dm-pre-reloc;
> +};
> +
> +_gpio14 {
> + u-boot,dm-pre-reloc;
> +};

I think this is superseded by the RPi PR that I had been testing and
just now pushed.  Can you confirm that master is fine on your Pis as
well?  I gather you hit this failure doing pytest on the board, which is
also how I found it.  Thanks!

-- 
Tom


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 v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Simon Goldschmidt]

On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong  wrote:
>
> > On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong 
> > wrote:
> > >
> > > > On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong
> > > > 
> > > > wrote:
> > > > >
> > > > > > On Mon, Dec 2, 2019 at 11:25 AM  wrote:
> > > > > > >
> > > > > > > From: "Ang, Chee Hong" 
> > > > > > >
> > > > > > > New U-boot flow with ARM Trusted Firmware (ATF) support:
> > > > > > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux
> > > > > > > (EL1)
> > > > > >
> > > > > > Adding support for ATF means that using U-Boot on Stratix10 and
> > > > > > Agilex without ATF keeps working, right?
> > > > > ATF is needed in order for Stratix10 and Agilex's U-Boot to work.
> > > >
> > > > Is there a technical requirement for that?
> > > Yes. We are using ATF to provide PSCI services such as system reset
> > > (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in Linux) and other secure
> > > services such as mailbox communications with Secure Device Manager and
> > > accessing the System Manager registers which are secure.
> > > Without PSCI services, we are able to boot until U-Boot proper only.
> > > Currently, our U-Boot in mainline doesn't boot to Linux due to these 
> > > missing
> > PSCI services.
> > > Another reason is we have another boot flow which is using ATF + UEFI.
> > > So now we are re-using the PSCI services from ATF so that now U-Boot
> > > and UEFI share the same ATF-BL31 image so that we don't have to
> > reimplement another sets of PSCI services for U-Boot again.
> > > This will greatly reduce our engineering efforts.
> >
> > Hmm, thanks for the explanation.
> >
> > I don't really think I can review this, given the lack of knowledge about 
> > that PSCI
> > stuff.
> I believe you can review it.
> Have you briefly gone through the patches ? It has nothing to do with the 
> PSCI stuff.
> It just call the invoke_smc() function to call the ATF's PSCI functions. 
> Those PSCI
> functions in ATF will do the rest.

No, not yet. But see below.

> >
> > I must say it seems strange to me that U-Boot would have to rely on ATF 
> > though.
> > How do other platforms implement this? Shouldn't PSCI be generic or is it 
> > really
> > platform specific? If it's generic, isn't that a dupliation of code if you 
> > implement
> > e.g. a reset driver for Stratix10 but call into PSCI?
> It's not strange at all.  A lot of U-Boot users already using this boot flow 
> (ATF + U-Boot).

Just because other boards do this doesn't mean it's not strange. Wasn't there
some kind of discussion around that PSCI stuff to make it available from U-Boot?
What's wrong with that way?

In my opinion, you're reducing functionality in U-Boot by making ATF a
requirement.

And by saying "I can't review this", I mean this looks like a
questionable way to me
and I'm not the one to say if a U-Boot board should go this way or not.

> Yes. PSCI is a generic software interface which encapsulate the platform 
> specific code.
> Let me give you a good example in one of your sysreset driver you have 
> implemented for S10.
>
> #include 
> #include 
> #include 
> -#include 
>
>  static int socfpga_sysreset_request(struct udevice *dev,
> enum sysreset_t type)
>  {
>  -  puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
>  -  mbox_reset_cold();
>  +  psci_system_reset();

So this is not an socfgpa_s10 specific driver any more, right?

> return -EINPROGRESS;
>  }
>
> Above is the changes in one of my patchsets, the sysreset driver for S10
> used to call mbox_reset_cold() to send mailbox message to Secure Device 
> Manager
> (SDM) to trigger COLD reset.
> Calling 'mbox_reset_cold()' means you are calling platform specific code in
> the sysreset driver to perform COLD reset. What if method to trigger COLD 
> reset is changed in new platform ?
> We have to change the sysreset driver code to support another new platform.
> If this function call is replaced with "psci_system_reset()", we don't have 
> to change the code
> at all because all the platform specific code for COLD reset is now reside in 
> ATF because this function
> just invoke the PSCI function provided by ATF. You just have to replace the 
> ATF binary with the new
> implementation for the new platform. We can re-use this sysreset driver for
> any platform that support ATF. In fact, it makes our U-Boot driver code more 
> 'generic' because PSCI
> interface stay the same. BTW, Linux also call PSCI functions to perform COLD 
> reset. By using ATF,
> U-Boot and Linux share the same COLD reset service provided by ATF. It 
> actually reduce
> code duplication.

What I meant was code duplication inside the U-Boot tree (having one
driver for each
arch but in effect all those drivers will call into the same psci function).

What you're doing is to move this code from U-Boot open U-Boot sources
to possibly
closed source ATF sources. But we've already had that discussion, I think...

Regards,
Simon

>
> I think 

Re: [U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Ang, Chee Hong]

> On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong 
> wrote:
> >
> > > On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong
> > > 
> > > wrote:
> > > >
> > > > > On Mon, Dec 2, 2019 at 11:25 AM  wrote:
> > > > > >
> > > > > > From: "Ang, Chee Hong" 
> > > > > >
> > > > > > New U-boot flow with ARM Trusted Firmware (ATF) support:
> > > > > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux
> > > > > > (EL1)
> > > > >
> > > > > Adding support for ATF means that using U-Boot on Stratix10 and
> > > > > Agilex without ATF keeps working, right?
> > > > ATF is needed in order for Stratix10 and Agilex's U-Boot to work.
> > >
> > > Is there a technical requirement for that?
> > Yes. We are using ATF to provide PSCI services such as system reset
> > (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in Linux) and other secure
> > services such as mailbox communications with Secure Device Manager and
> > accessing the System Manager registers which are secure.
> > Without PSCI services, we are able to boot until U-Boot proper only.
> > Currently, our U-Boot in mainline doesn't boot to Linux due to these missing
> PSCI services.
> > Another reason is we have another boot flow which is using ATF + UEFI.
> > So now we are re-using the PSCI services from ATF so that now U-Boot
> > and UEFI share the same ATF-BL31 image so that we don't have to
> reimplement another sets of PSCI services for U-Boot again.
> > This will greatly reduce our engineering efforts.
> 
> Hmm, thanks for the explanation.
> 
> I don't really think I can review this, given the lack of knowledge about 
> that PSCI
> stuff.
I believe you can review it.
Have you briefly gone through the patches ? It has nothing to do with the PSCI 
stuff.
It just call the invoke_smc() function to call the ATF's PSCI functions. Those 
PSCI 
functions in ATF will do the rest.
> 
> I must say it seems strange to me that U-Boot would have to rely on ATF 
> though.
> How do other platforms implement this? Shouldn't PSCI be generic or is it 
> really
> platform specific? If it's generic, isn't that a dupliation of code if you 
> implement
> e.g. a reset driver for Stratix10 but call into PSCI?
It's not strange at all.  A lot of U-Boot users already using this boot flow 
(ATF + U-Boot).
Yes. PSCI is a generic software interface which encapsulate the platform 
specific code.
Let me give you a good example in one of your sysreset driver you have 
implemented for S10.

#include 
#include 
#include 
-#include 
 
 static int socfpga_sysreset_request(struct udevice *dev,
enum sysreset_t type)
 {
 -  puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
 -  mbox_reset_cold();
 +  psci_system_reset();
return -EINPROGRESS;
 }
 
Above is the changes in one of my patchsets, the sysreset driver for S10
used to call mbox_reset_cold() to send mailbox message to Secure Device Manager
(SDM) to trigger COLD reset.
Calling 'mbox_reset_cold()' means you are calling platform specific code in
the sysreset driver to perform COLD reset. What if method to trigger COLD reset 
is changed in new platform ?
We have to change the sysreset driver code to support another new platform.
If this function call is replaced with "psci_system_reset()", we don't have to 
change the code
at all because all the platform specific code for COLD reset is now reside in 
ATF because this function
just invoke the PSCI function provided by ATF. You just have to replace the ATF 
binary with the new
implementation for the new platform. We can re-use this sysreset driver for
any platform that support ATF. In fact, it makes our U-Boot driver code more 
'generic' because PSCI
interface stay the same. BTW, Linux also call PSCI functions to perform COLD 
reset. By using ATF,
U-Boot and Linux share the same COLD reset service provided by ATF. It actually 
reduce
code duplication.

I think you are aware of we are working to move the mailbox driver code away 
from arch to drivers.
You will see that a lot of those mailbox functions will be removed from the 
mailbox driver.
One of them is 'mbox_reset_cold()' which you called in sysreset driver for S10.

> Regards,
> Simon
> 
> > >
> > > Regard,
> > > Simon
> > >
> > > > > >
> > > > > > SPL loads the u-boot.itb which consist of:
> > > > > > 1) u-boot-nodtb.bin (U-Boot Proper image)
> > > > > > 2) u-boot.dtb (U-Boot Proper DTB)
> > > > > > 3) bl31.bin (ATF-BL31 image)
> > > > > >
> > > > > > Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex)
> > > > > >
> > > > > > Now, U-Boot Proper is running in non-secure mode (EL2), it
> > > > > > invokes SMC/PSCI calls provided by ATF to perform COLD reset,
> > > > > > System Manager register accesses and mailbox communications
> > > > > > with Secure Device Manager (SDM).
> > > > > >
> > > > > > Steps to build the U-Boot with ATF support:
> > > > > > 1) Build U-Boot
> > > > > > 2) Build ATF BL31
> > > > > > 3) Copy ATF BL31 binary image into U-Boot's root folder
> > > > > > 4) "make 

Re: [U-Boot] [PULL] u-boot-socfpga/master

[Tom Rini]

On Thu, Nov 28, 2019 at 11:17:58AM +0100, Marek Vasut wrote:

> The following changes since commit 9a0cbae22a613dfd55e15565785749b74c19fdf0:
> 
>   Merge tag 'u-boot-rockchip-20191124' of
> https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip (2019-11-23
> 20:50:11 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-socfpga.git master
> 
> for you to fetch changes up to a1a9843a29672be49a5bbb3a07fea8dbc88369ba:
> 
>   ARM: socfpga: Unreset NAND in SPL on Gen5 (2019-11-25 13:12:56 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PULL] u-boot-usb/master

[Tom Rini]

On Thu, Nov 28, 2019 at 11:17:36AM +0100, Marek Vasut wrote:

> The following changes since commit 9a0cbae22a613dfd55e15565785749b74c19fdf0:
> 
>   Merge tag 'u-boot-rockchip-20191124' of
> https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip (2019-11-23
> 20:50:11 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-usb.git master
> 
> for you to fetch changes up to dbcbdad92caf4b42a6279da6e65180532bc45620:
> 
>   sandbox: enable USB_KEYBOARD_FN_KEYS (2019-11-25 13:28:53 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] Please pull mmc-11-27-2019

[Tom Rini]

On Thu, Nov 28, 2019 at 01:20:07AM +, Peng Fan wrote:

> Hi Tom,
> 
> Please pull mmc-11-27-2019
> CI: https://travis-ci.org/MrVan/u-boot/builds/617615361
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] pull request u-boot-mpc85xx

[Tom Rini]

On Tue, Nov 26, 2019 at 04:49:39AM +, Priyanka Jain wrote:

> Dear Tom,
> 
> Please find my pull-request for u-boot-mpc85xx/master
> https://travis-ci.org/p-priyanka-jain/u-boot/builds/616526169
> 
> Summary
> powerpc: Fix DM_MMC related build warnings by adding
> eSDHC device module support for T4240RDB, T2080RDB, T1042D4RDB,
> T1024RDB, P5040DS, P4080DS, P3041DS, P2041RDB, P2020RDB,
> P1020RDB platforms
> 
> priyankajain

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PULL] Pull request: u-boot-stm32 u-boot-stm32-20191126

[Tom Rini]

On Wed, Nov 27, 2019 at 01:42:24PM +, Patrick DELAUNAY wrote:

> Hi Tom
> 
> Please pull the STM32 related patches for u-boot-stm32-20191126
> 
> With the following changes:
> - Solve warning for stih410-b2260
> - Device tree alignment on v5.4-rc4 for all stm32 boards
> - Correct the eMMC pin configuration on stm32mp157c-ev1
> - Add DFU and SPI-NAND support for stm32mp1 board
> 
> Travis CI status:
>  https://travis-ci.org/patrickdelaunay/u-boot/builds/617166580
> 
> Thanks,
> Patrick
> 
> The following changes since commit 4b19b89ca4a866b7baa642533e6dbd67cd832d27:
> 
>   Merge tag 'rpi-next-2020.01' of https://github.com/mbgg/u-boot (2019-11-25 
> 12:56:27 -0500)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git 
> tags/u-boot-stm32-20191126
> 
> for you to fetch changes up to b4fee1610864036c8363e552f8547e99b1100f0b:
> 
>   stm32mp1: add support for virtual partition read (2019-11-26 10:14:35 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

[U-Boot] [PATCH] iminfo: add missing map_sysmem

[Philippe Reynes]

The command iminfo fails on sandbox because the address
is used directly. To fix this issue, we call the function
map_sysmem to translate the address.

Signed-off-by: Philippe Reynes 
---
 cmd/bootm.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/cmd/bootm.c b/cmd/bootm.c
index 8279f2b..62ee7c4 100644
--- a/cmd/bootm.c
+++ b/cmd/bootm.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -244,7 +245,7 @@ static int do_iminfo(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
 
 static int image_info(ulong addr)
 {
-   void *hdr = (void *)addr;
+   void *hdr = (void *)map_sysmem(addr, 0);
 
printf("\n## Checking Image at %08lx ...\n", addr);
 
@@ -254,11 +255,13 @@ static int image_info(ulong addr)
puts("   Legacy image found\n");
if (!image_check_magic(hdr)) {
puts("   Bad Magic Number\n");
+   unmap_sysmem(hdr);
return 1;
}
 
if (!image_check_hcrc(hdr)) {
puts("   Bad Header Checksum\n");
+   unmap_sysmem(hdr);
return 1;
}
 
@@ -267,15 +270,18 @@ static int image_info(ulong addr)
puts("   Verifying Checksum ... ");
if (!image_check_dcrc(hdr)) {
puts("   Bad Data CRC\n");
+   unmap_sysmem(hdr);
return 1;
}
puts("OK\n");
+   unmap_sysmem(hdr);
return 0;
 #endif
 #if defined(CONFIG_ANDROID_BOOT_IMAGE)
case IMAGE_FORMAT_ANDROID:
puts("   Android image found\n");
android_print_contents(hdr);
+   unmap_sysmem(hdr);
return 0;
 #endif
 #if defined(CONFIG_FIT)
@@ -284,6 +290,7 @@ static int image_info(ulong addr)
 
if (!fit_check_format(hdr)) {
puts("Bad FIT image format!\n");
+   unmap_sysmem(hdr);
return 1;
}
 
@@ -291,9 +298,11 @@ static int image_info(ulong addr)
 
if (!fit_all_image_verify(hdr)) {
puts("Bad hash in FIT image!\n");
+   unmap_sysmem(hdr);
return 1;
}
 
+   unmap_sysmem(hdr);
return 0;
 #endif
default:
@@ -301,6 +310,7 @@ static int image_info(ulong addr)
break;
}
 
+   unmap_sysmem(hdr);
return 1;
 }
 
-- 
2.7.4

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

Re: [U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Simon Goldschmidt]

On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong  wrote:
>
> > On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong 
> > wrote:
> > >
> > > > On Mon, Dec 2, 2019 at 11:25 AM  wrote:
> > > > >
> > > > > From: "Ang, Chee Hong" 
> > > > >
> > > > > New U-boot flow with ARM Trusted Firmware (ATF) support:
> > > > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux (EL1)
> > > >
> > > > Adding support for ATF means that using U-Boot on Stratix10 and
> > > > Agilex without ATF keeps working, right?
> > > ATF is needed in order for Stratix10 and Agilex's U-Boot to work.
> >
> > Is there a technical requirement for that?
> Yes. We are using ATF to provide PSCI services such as system reset (COLD 
> reset),
> CPU_ON/CPU_OFF (CPU hotplug in Linux) and other secure services such as 
> mailbox
> communications with Secure Device Manager and accessing the System Manager 
> registers
> which are secure.
> Without PSCI services, we are able to boot until U-Boot proper only. 
> Currently, our U-Boot in
> mainline doesn't boot to Linux due to these missing PSCI services.
> Another reason is we have another boot flow which is using ATF + UEFI. So now 
> we are
> re-using the PSCI services from ATF so that now U-Boot and UEFI share the 
> same ATF-BL31
> image so that we don't have to reimplement another sets of PSCI services for 
> U-Boot again.
> This will greatly reduce our engineering efforts.

Hmm, thanks for the explanation.

I don't really think I can review this, given the lack of knowledge about that
PSCI stuff.

I must say it seems strange to me that U-Boot would have to rely on ATF though.
How do other platforms implement this? Shouldn't PSCI be generic or is it
really platform specific? If it's generic, isn't that a dupliation of code if
you implement e.g. a reset driver for Stratix10 but call into PSCI?

Regards,
Simon

> >
> > Regard,
> > Simon
> >
> > > > >
> > > > > SPL loads the u-boot.itb which consist of:
> > > > > 1) u-boot-nodtb.bin (U-Boot Proper image)
> > > > > 2) u-boot.dtb (U-Boot Proper DTB)
> > > > > 3) bl31.bin (ATF-BL31 image)
> > > > >
> > > > > Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex)
> > > > >
> > > > > Now, U-Boot Proper is running in non-secure mode (EL2), it invokes
> > > > > SMC/PSCI calls provided by ATF to perform COLD reset, System
> > > > > Manager register accesses and mailbox communications with Secure
> > > > > Device Manager (SDM).
> > > > >
> > > > > Steps to build the U-Boot with ATF support:
> > > > > 1) Build U-Boot
> > > > > 2) Build ATF BL31
> > > > > 3) Copy ATF BL31 binary image into U-Boot's root folder
> > > > > 4) "make u-boot.itb" to generate u-boot.itb
> > > > >
> > > > > These patchsets have dependency on:
> > > > > [U-Boot,v8,00/19] Add Intel Agilex SoC support:
> > > > > https://patchwork.ozlabs.org/cover/1201373/
> > > > >
> > > > > Chee Hong Ang (19):
> > > > >   arm: socfpga: add fit source file for pack itb with ATF
> > > > >   arm: socfpga: Add function for checking description from FIT image
> > > > >   arm: socfpga: Load FIT image with ATF support
> > > > >   arm: socfpga: Override 'lowlevel_init' to support ATF
> > > > >   configs: socfpga: Enable FIT image loading with ATF support
> > > > >   arm: socfpga: Disable "spin-table" method for booting Linux
> > > > >   arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits)
> > > > >   arm: socfpga: Define SMC function identifiers for PSCI SiP services
> > > > >   arm: socfpga: Add secure register access helper functions for SoC
> > > > > 64bits
> > > > >   arm: socfpga: Secure register access for clock manager (SoC 64bits)
> > > > >   arm: socfpga: Secure register access in PHY mode setup
> > > > >   arm: socfpga: Secure register access for reading PLL frequency
> > > > >   mmc: dwmmc: socfpga: Secure register access in MMC driver
> > > > >   net: designware: socfpga: Secure register access in MAC driver
> > > > >   arm: socfpga: Secure register access in Reset Manager driver
> > > > >   arm: socfpga: stratix10: Initialize timer in SPL
> > > > >   arm: socfpga: stratix10: Refactor FPGA reconfig driver to support 
> > > > > ATF
> > > > >   arm: socfpga: Bridge reset now invokes SMC calls to query FPGA 
> > > > > config
> > > > > status
> > > > >   sysreset: socfpga: Invoke PSCI call for COLD reset
> > > > >
> > > > > Dalon Westergreen (1):
> > > > >   configs: stratix10: Remove CONFIG_OF_EMBED
> > > >
> > > > This one is included in another series already:
> > > > https://patchwork.ozlabs.org/user/todo/uboot/?series=132976
> > > >
> > > > Does this mean that one will be abandonen?
> > > > So the combined hex output part of that series is not required any more?
> > > >
> > > > Regards,
> > > > Simon
> > > >
> > > > >
> > > > >  arch/arm/mach-socfpga/Kconfig  |   2 -
> > > > >  arch/arm/mach-socfpga/Makefile |   4 +
> > > > >  arch/arm/mach-socfpga/board.c  |  10 +
> > > > >  

Re: [U-Boot] [PATCH v4 2/2] cmd: Add dtimg command

[Eugeniu Rosca]

Dear Igor and Sam,
Cc: Tom, Simon

On Mon, Nov 18, 2019 at 10:27:32PM +0100, Eugeniu Rosca wrote:
> Hello Igor, hello Sam,
> 
> We still have high hopes getting your response to
> https://patchwork.ozlabs.org/patch/958594/#2302310
> 
> If not given, we will proceed with implementing the proposal from
> https://patchwork.ozlabs.org/patch/958594/#2303657

As the ones responsible for Android-specific patches, would you kindly
review the functionality submitted to
https://patchwork.ozlabs.org/cover/1202575/ ?

In case you are not available in the next weeks, I hope Tom and Simon
will suggest a way to go forward with the new patches?

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

Re: [U-Boot] [PATCH v5 101/101] x86: Add chromebook_coral

[Bin Meng]

Hi Simon,

On Mon, Nov 25, 2019 at 12:12 PM Simon Glass  wrote:
>
> Add support for coral which is a range of Apollo Lake-based Chromebook
> released in 2017. This also includes reef released in 2016, since it is
> based on the same SoC.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v5:
> - Add gpio-controller to GPIO nodes
> - Comment out GPIOs in the fsp_s node since we don't use them yet
> - Correct CPU ACPI IDs
> - Use a define for ACPI base address
>
> Changes in v4:
> - Add u-boot,skip-auto-config-until-reloc property to PCI
> - Drop duplicate commit 'Create a new sandbox_pci_read_bar() function'
> - New GPIO driver binding
> - Set up LPC pads early
> - Switch over to use pinctrl for pad init/config
> - Update documentation with more detailed memory map
> - Use hyphen for device-tree properties
> - apollolake -> Apollo Lake
>
> Changes in v3:
> - Ad FSP-S support
> - Add CONFIG_TPL_X86_ASSUME_CPUID to reduce code size
> - Add Chrome OS EC support
> - Add a proper SPI node and make the SPI flash node a child
> - Add bootstage support
> - Add more documentation
> - Add spi alias in device tree
> - Disable the bootcommand since it does nothing useful on coral
> - Don't enable SPI flash in TPL by default
> - Drop CONFIG_SPL_NET_SUPPORT
> - Drop patch '86: timer: Reduce timer code size in TPL on Intel CPUs'
> - Drop patch 'dm: core: Don't include ofnode functions with of-platdata'
> - Drop patch 'spi: sandbox: Add a test driver for sandbox SPI flash'
> - Drop patch 'spl: Allow SPL/TPL to use of-platdata without libfdt'
> - Drop patch 'x86: apollolake: Add definitions for the Intel Fast SPI 
> interface'
> - Drop patch 'x86: timer: Set up the timer in timer_early_get_count()'
> - Enable video and USB3
> - Reduce amount of early-pad data in TPL
> - Tidy up the pad settings in the device tree
> - Use a zero-based tsc timer
>
> Changes in v2: None
>
>  arch/x86/dts/Makefile |   1 +
>  arch/x86/dts/chromebook_coral.dts | 831 ++
>  board/google/Kconfig  |  15 +
>  board/google/chromebook_coral/Kconfig |  43 ++
>  board/google/chromebook_coral/MAINTAINERS |   6 +
>  board/google/chromebook_coral/Makefile|   5 +
>  board/google/chromebook_coral/coral.c |  18 +
>  configs/chromebook_coral_defconfig| 102 +++
>  doc/board/google/chromebook_coral.rst | 241 +++
>  include/configs/chromebook_coral.h|  32 +
>  10 files changed, 1294 insertions(+)
>  create mode 100644 arch/x86/dts/chromebook_coral.dts
>  create mode 100644 board/google/chromebook_coral/Kconfig
>  create mode 100644 board/google/chromebook_coral/MAINTAINERS
>  create mode 100644 board/google/chromebook_coral/Makefile
>  create mode 100644 board/google/chromebook_coral/coral.c
>  create mode 100644 configs/chromebook_coral_defconfig
>  create mode 100644 doc/board/google/chromebook_coral.rst
>  create mode 100644 include/configs/chromebook_coral.h
>
> diff --git a/arch/x86/dts/Makefile b/arch/x86/dts/Makefile
> index d4bdf62be6..be209aaaf8 100644
> --- a/arch/x86/dts/Makefile
> +++ b/arch/x86/dts/Makefile
> @@ -2,6 +2,7 @@
>
>  dtb-y += bayleybay.dtb \
> cherryhill.dtb \
> +   chromebook_coral.dtb \
> chromebook_link.dtb \
> chromebox_panther.dtb \
> chromebook_samus.dtb \
> diff --git a/arch/x86/dts/chromebook_coral.dts 
> b/arch/x86/dts/chromebook_coral.dts
> new file mode 100644
> index 00..583d5eb8bc
> --- /dev/null
> +++ b/arch/x86/dts/chromebook_coral.dts
> @@ -0,0 +1,831 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/dts-v1/;
> +
> +#include 
> +
> +/include/ "skeleton.dtsi"
> +/include/ "keyboard.dtsi"
> +/include/ "reset.dtsi"
> +/include/ "rtc.dtsi"
> +/include/ "tsc_timer.dtsi"
> +
> +#ifdef CONFIG_CHROMEOS
> +#include "chromeos-x86.dtsi"
> +#include "flashmap-x86-ro.dtsi"
> +#include "flashmap-16mb-rw.dtsi"
> +#endif
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/ {
> +   model = "Google Coral";
> +   compatible = "google,coral", "intel,apollolake";
> +
> +   aliases {
> +   cros-ec0 = _ec;
> +   fsp = _s;
> +   spi0 = 
> +   };
> +
> +   config {
> +  silent_console = <0>;
> +   };
> +
> +   chosen {
> +   stdout-path = 
> +   };
> +
> +   cpus {
> +   u-boot,dm-pre-reloc;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   cpu@0 {
> +   u-boot,dm-pre-reloc;
> +   device_type = "cpu";
> +   compatible = "intel,apl-cpu";
> +   reg = <0>;
> +   intel,apic-id = <0>;
> +   };
> +
> +   cpu@1 {
> +   device_type = "cpu";
> +   compatible = "intel,apl-cpu";
> +   reg = <1>;
> +   intel,apic-id = <2>;
> + 

Re: [U-Boot] [PATCH v5 100/101] x86: apl: Add FSP support

[Bin Meng]

Hi Simon,

On Mon, Nov 25, 2019 at 12:12 PM Simon Glass  wrote:
>
> The memory and silicon init parts of the FSP need support code to work.
> Add this for Apollo Lake.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v5:
> - Allocate the FSP-S data instead of using the stack
> - Rename APOLLOLAKE_USB2_PORT_MAX
>
> Changes in v4:
> - Adjust the comment for struct dw_i2c_speed_config
> - Rename arch_fsp_s_preinit() to arch_fsps_preinit()
> - Switch over to use pinctrl for pad init/config
> - Tidy up mixed case in FSP code
> - apollolake -> Apollo Lake
>
> Changes in v3:
> - Add bootstage timing for reading vbt
> - Add fspm_done() hook to handle FSP-S wierdness (it breaks SPI flash)
> - Don't allow BOOT_FROM_FAST_SPI_FLASH with FSP-S
> - Set boot_loader_tolum_size to 0
> - Use the IRQ uclass instead of ITSS
>
> Changes in v2: None
>
>  arch/x86/cpu/apollolake/Makefile |   6 +
>  arch/x86/cpu/apollolake/fsp_m.c  | 210 ++
>  arch/x86/cpu/apollolake/fsp_s.c  | 667 +++
>  3 files changed, 883 insertions(+)
>  create mode 100644 arch/x86/cpu/apollolake/fsp_m.c
>  create mode 100644 arch/x86/cpu/apollolake/fsp_s.c
>
> diff --git a/arch/x86/cpu/apollolake/Makefile 
> b/arch/x86/cpu/apollolake/Makefile
> index dc6df15dab..1760df54d8 100644
> --- a/arch/x86/cpu/apollolake/Makefile
> +++ b/arch/x86/cpu/apollolake/Makefile
> @@ -10,6 +10,12 @@ obj-y += cpu_common.o
>  ifndef CONFIG_TPL_BUILD
>  obj-y += cpu.o
>  obj-y += punit.o
> +ifdef CONFIG_SPL_BUILD
> +obj-y += fsp_m.o
> +endif
> +endif
> +ifndef CONFIG_SPL_BUILD
> +obj-y += fsp_s.o
>  endif
>
>  obj-y += hostbridge.o
> diff --git a/arch/x86/cpu/apollolake/fsp_m.c b/arch/x86/cpu/apollolake/fsp_m.c
> new file mode 100644
> index 00..39cda7c49b
> --- /dev/null
> +++ b/arch/x86/cpu/apollolake/fsp_m.c
> @@ -0,0 +1,210 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2019 Google LLC
> + * Written by Simon Glass 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * ODT settings:
> + * If ODT PIN to LP4 DRAM is pulled HIGH for ODT_A and HIGH for ODT_B,
> + * choose ODT_A_B_HIGH_HIGH. If ODT PIN to LP4 DRAM is pulled HIGH for ODT_A
> + * and LOW for ODT_B, choose ODT_A_B_HIGH_LOW.
> + *
> + * Note that the enum values correspond to the interpreted UPD fields
> + * within Ch[3:0]_OdtConfig parameters.
> + */
> +enum {
> +   ODT_A_B_HIGH_LOW= 0 << 1,
> +   ODT_A_B_HIGH_HIGH   = 1 << 1,
> +   N_WR_24 = 1 << 5,
> +};
> +
> +/*
> + * LPDDR4 helper routines for configuring the memory UPD for LPDDR4 
> operation.
> + * There are four physical LPDDR4 channels, each 32-bits wide. There are two
> + * logical channels using two physical channels together to form a 64-bit
> + * interface to memory for each logical channel.
> + */
> +
> +enum {
> +   LP4_PHYS_CH0A,
> +   LP4_PHYS_CH0B,
> +   LP4_PHYS_CH1A,
> +   LP4_PHYS_CH1B,
> +
> +   LP4_NUM_PHYS_CHANNELS,
> +};
> +
> +/*
> + * The DQs within a physical channel can be bit-swizzled within each byte.
> + * Within a channel the bytes can be swapped, but the DQs need to be routed
> + * with the corresponding DQS (strobe).
> + */
> +enum {
> +   LP4_DQS0,
> +   LP4_DQS1,
> +   LP4_DQS2,
> +   LP4_DQS3,
> +
> +   LP4_NUM_BYTE_LANES,
> +   DQ_BITS_PER_DQS = 8,
> +};
> +
> +/* Provide bit swizzling per DQS and byte swapping within a channel */
> +struct lpddr4_chan_swizzle_cfg {
> +   u8 dqs[LP4_NUM_BYTE_LANES][DQ_BITS_PER_DQS];
> +};
> +
> +struct lpddr4_swizzle_cfg {
> +   struct lpddr4_chan_swizzle_cfg phys[LP4_NUM_PHYS_CHANNELS];
> +};
> +
> +static void setup_sdram(struct fsp_m_config *cfg,
> +   const struct lpddr4_swizzle_cfg *swizzle_cfg)
> +{
> +   const struct lpddr4_chan_swizzle_cfg *sch;
> +   /* Number of bytes to copy per DQS */
> +   const size_t sz = DQ_BITS_PER_DQS;
> +   int chan;
> +
> +   cfg->memory_down = 1;
> +   cfg->scrambler_support = 1;
> +   cfg->channel_hash_mask = 0x36;
> +   cfg->slice_hash_mask = 9;
> +   cfg->interleaved_mode = 2;
> +   cfg->channels_slices_enable = 0;
> +   cfg->min_ref_rate2x_enable = 0;
> +   cfg->dual_rank_support_enable = 1;
> +
> +   /* LPDDR4 is memory down so no SPD addresses */
> +   cfg->dimm0_spd_address = 0;
> +   cfg->dimm1_spd_address = 0;
> +
> +   for (chan = 0; chan < 4; chan++) {
> +   struct fsp_ram_channel *ch = >chan[chan];
> +
> +   ch->rank_enable = 1;
> +   ch->device_width = 1;
> +   ch->dram_density = 2;
> +   ch->option = 3;
> +   ch->odt_config = ODT_A_B_HIGH_HIGH;
> +   }
> +
> +   /*
> +* CH0_DQB byte lanes in the bit swizzle configuration field are
> +* not 1:1. The mapping within the swizzling field is:
> +*   indices [0:7]   - byte lane 1 (DQS1) 

Re: [U-Boot] Load Debian/Fedora via EFI

[Michal Simek]

On 29. 11. 19 19:23, Heinrich Schuchardt wrote:
> On 11/29/19 11:16 AM, Michal Simek wrote:
>> Hi,
>>
>> I tried to boot latest debian and fedora rootfs via distro boot and
>> getting errors.
>> I have tried to run just one command and it is failing.
>>
>> ZynqMP> bootefi bootmgr ${fdtcontroladdr}
>> BootOrder not defined
>> EFI boot manager: Cannot load any image
>>
>> How to define BootOrder?
>>
>> Thanks,
>> Michal
> 
> # Booting via boot manager
> 
> U-Boot currently has no runtime support for variables. But Linaro is
> working on it. So update-grub cannot set the variables for you.

Who from Linaro is working on it? Akashi?

> 
> You can use the efidebug command to prepare for booting via the boot
> manager:
> 
> => efidebug boot add 0001 Debian mmc 0:1 \
>    efi/debian/grubarm.efi console=${console}
> 
> There seems to be a bug with communication lines in U-Boot. So you
> actually have to put this into a single line.
> 
> => efidebug boot order 0001
> 
> Use saveenv if you want to save the settings.
> 
> If you do not want to use the internal device tree load the proper
> device tree, e.g.
> 
> => load mmc 0:2 $fdt_addr_r dtb
> 
> Now you are ready to boot via the boot manager:
> 
> => bootefi bootmgr $fdt_addr_r
> 
> # Booting via distro defaults
> 
> DISTRO_DEFAULTS tries to load the devicetree from ${fdtfile} and the
> UEFI binary from efi/boot/bootaa64.efi on ARM64. See
> ./include/config_distro_bootcmd.h.
> 
> OpenBSD and FreeBSD follow the distro boot convention, Debian GRUB does
> not.

Fedora is the same case.
I got it working based on your guidance but would be IMHO better to
extend distroboot to cover one of the major distribution even through
workaround till variable support is done.

> 
> # Booting via boot script.
> 
> On Debian I use package flash-kernel to keep /boot/dtb in sync with the
> kernel and have a u-boot.scr.uimg script with something like the
> following lines:
> 
> setenv bootargs console=${console}
> load mmc 2:1 ${kernel_addr_r} EFI/debian/grubarm.efi
> load mmc 2:2 ${fdt_addr_r} dtb
> bootefi ${kernel_addr_r} ${fdt_addr_r}


flash-kernel is interesting. It generates u-boot script but if extX
partition has no bootable flag u-boot distroboot ignores it completely.
What's your default partition setup?

> 
> Alternatively you could use package flash-kernel and implement the
> /etc/flash-kernel/preboot.d/
> hook to start GRUB, cf.
> /etc/flash-kernel/bootscript/bootscr.uboot-generic
> 
> I currently have no Fedora system in use.
> 

you can take a look.
https://alt.fedoraproject.org/alt/

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

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

Re: [U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Ang, Chee Hong]

> > On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong
> > 
> > wrote:
> > >
> > > > On Mon, Dec 2, 2019 at 11:25 AM  wrote:
> > > > >
> > > > > From: "Ang, Chee Hong" 
> > > > >
> > > > > New U-boot flow with ARM Trusted Firmware (ATF) support:
> > > > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux
> > > > > (EL1)
> > > >
> > > > Adding support for ATF means that using U-Boot on Stratix10 and
> > > > Agilex without ATF keeps working, right?
> > > ATF is needed in order for Stratix10 and Agilex's U-Boot to work.
> >
> > Is there a technical requirement for that?
> Yes. We are using ATF to provide PSCI services such as system reset (COLD 
> reset),
> CPU_ON/CPU_OFF (CPU hotplug in Linux) and other secure services such as
> mailbox communications with Secure Device Manager and accessing the System
> Manager registers which are secure.
> Without PSCI services, we are able to boot until U-Boot proper only. 
> Currently,
> our U-Boot in mainline doesn't boot to Linux due to these missing PSCI 
> services.
> Another reason is we have another boot flow which is using ATF + UEFI. So now
> we are re-using the PSCI services from ATF so that now U-Boot and UEFI share
> the same ATF-BL31 image so that we don't have to reimplement another sets of
> PSCI services for U-Boot again.
> This will greatly reduce our engineering efforts.
> >
> > Regard,
> > Simon
> >
> > > > >
> > > > > SPL loads the u-boot.itb which consist of:
> > > > > 1) u-boot-nodtb.bin (U-Boot Proper image)
> > > > > 2) u-boot.dtb (U-Boot Proper DTB)
> > > > > 3) bl31.bin (ATF-BL31 image)
> > > > >
> > > > > Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex)
> > > > >
> > > > > Now, U-Boot Proper is running in non-secure mode (EL2), it
> > > > > invokes SMC/PSCI calls provided by ATF to perform COLD reset,
> > > > > System Manager register accesses and mailbox communications with
> > > > > Secure Device Manager (SDM).
> > > > >
> > > > > Steps to build the U-Boot with ATF support:
> > > > > 1) Build U-Boot
> > > > > 2) Build ATF BL31
> > > > > 3) Copy ATF BL31 binary image into U-Boot's root folder
> > > > > 4) "make u-boot.itb" to generate u-boot.itb
> > > > >
> > > > > These patchsets have dependency on:
> > > > > [U-Boot,v8,00/19] Add Intel Agilex SoC support:
> > > > > https://patchwork.ozlabs.org/cover/1201373/
> > > > >
> > > > > Chee Hong Ang (19):
> > > > >   arm: socfpga: add fit source file for pack itb with ATF
> > > > >   arm: socfpga: Add function for checking description from FIT image
> > > > >   arm: socfpga: Load FIT image with ATF support
> > > > >   arm: socfpga: Override 'lowlevel_init' to support ATF
> > > > >   configs: socfpga: Enable FIT image loading with ATF support
> > > > >   arm: socfpga: Disable "spin-table" method for booting Linux
> > > > >   arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits)
> > > > >   arm: socfpga: Define SMC function identifiers for PSCI SiP services
> > > > >   arm: socfpga: Add secure register access helper functions for SoC
> > > > > 64bits
> > > > >   arm: socfpga: Secure register access for clock manager (SoC 64bits)
> > > > >   arm: socfpga: Secure register access in PHY mode setup
> > > > >   arm: socfpga: Secure register access for reading PLL frequency
> > > > >   mmc: dwmmc: socfpga: Secure register access in MMC driver
> > > > >   net: designware: socfpga: Secure register access in MAC driver
> > > > >   arm: socfpga: Secure register access in Reset Manager driver
> > > > >   arm: socfpga: stratix10: Initialize timer in SPL
> > > > >   arm: socfpga: stratix10: Refactor FPGA reconfig driver to support 
> > > > > ATF
> > > > >   arm: socfpga: Bridge reset now invokes SMC calls to query FPGA 
> > > > > config
> > > > > status
> > > > >   sysreset: socfpga: Invoke PSCI call for COLD reset
> > > > >
> > > > > Dalon Westergreen (1):
> > > > >   configs: stratix10: Remove CONFIG_OF_EMBED
> > > >
> > > > This one is included in another series already:
> > > > https://patchwork.ozlabs.org/user/todo/uboot/?series=132976
> > > >
> > > > Does this mean that one will be abandonen?
> > > > So the combined hex output part of that series is not required any more?
Sorry, I missed this part.
Thanks for reminding the patches from Dalon.
These patchsets needed Dalon's previous patches to work. Especially the patch 
to remove
"CONFIG_OF_EMBED" from the defconfig file. I didn't know whether these patches 
will get
accepted to mainline or not. If you are basically OK with those patches from 
Dalon. I will remove
Dalon's patch from my patchsets when submitting the next patchsets.
> > > >
> > > > Regards,
> > > > Simon
> > > >
> > > > >
> > > > >  arch/arm/mach-socfpga/Kconfig  |   2 -
> > > > >  arch/arm/mach-socfpga/Makefile |   4 +
> > > > >  arch/arm/mach-socfpga/board.c  |  10 +
> > > > >  arch/arm/mach-socfpga/clock_manager_agilex.c   |   5 +-
> > > > >  arch/arm/mach-socfpga/clock_manager_s10.c 

Re: [U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Ang, Chee Hong]

> On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong 
> wrote:
> >
> > > On Mon, Dec 2, 2019 at 11:25 AM  wrote:
> > > >
> > > > From: "Ang, Chee Hong" 
> > > >
> > > > New U-boot flow with ARM Trusted Firmware (ATF) support:
> > > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux (EL1)
> > >
> > > Adding support for ATF means that using U-Boot on Stratix10 and
> > > Agilex without ATF keeps working, right?
> > ATF is needed in order for Stratix10 and Agilex's U-Boot to work.
> 
> Is there a technical requirement for that?
Yes. We are using ATF to provide PSCI services such as system reset (COLD 
reset),
CPU_ON/CPU_OFF (CPU hotplug in Linux) and other secure services such as mailbox
communications with Secure Device Manager and accessing the System Manager 
registers
which are secure.
Without PSCI services, we are able to boot until U-Boot proper only. Currently, 
our U-Boot in
mainline doesn't boot to Linux due to these missing PSCI services.
Another reason is we have another boot flow which is using ATF + UEFI. So now 
we are
re-using the PSCI services from ATF so that now U-Boot and UEFI share the same 
ATF-BL31
image so that we don't have to reimplement another sets of PSCI services for 
U-Boot again.
This will greatly reduce our engineering efforts.
> 
> Regard,
> Simon
> 
> > > >
> > > > SPL loads the u-boot.itb which consist of:
> > > > 1) u-boot-nodtb.bin (U-Boot Proper image)
> > > > 2) u-boot.dtb (U-Boot Proper DTB)
> > > > 3) bl31.bin (ATF-BL31 image)
> > > >
> > > > Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex)
> > > >
> > > > Now, U-Boot Proper is running in non-secure mode (EL2), it invokes
> > > > SMC/PSCI calls provided by ATF to perform COLD reset, System
> > > > Manager register accesses and mailbox communications with Secure
> > > > Device Manager (SDM).
> > > >
> > > > Steps to build the U-Boot with ATF support:
> > > > 1) Build U-Boot
> > > > 2) Build ATF BL31
> > > > 3) Copy ATF BL31 binary image into U-Boot's root folder
> > > > 4) "make u-boot.itb" to generate u-boot.itb
> > > >
> > > > These patchsets have dependency on:
> > > > [U-Boot,v8,00/19] Add Intel Agilex SoC support:
> > > > https://patchwork.ozlabs.org/cover/1201373/
> > > >
> > > > Chee Hong Ang (19):
> > > >   arm: socfpga: add fit source file for pack itb with ATF
> > > >   arm: socfpga: Add function for checking description from FIT image
> > > >   arm: socfpga: Load FIT image with ATF support
> > > >   arm: socfpga: Override 'lowlevel_init' to support ATF
> > > >   configs: socfpga: Enable FIT image loading with ATF support
> > > >   arm: socfpga: Disable "spin-table" method for booting Linux
> > > >   arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits)
> > > >   arm: socfpga: Define SMC function identifiers for PSCI SiP services
> > > >   arm: socfpga: Add secure register access helper functions for SoC
> > > > 64bits
> > > >   arm: socfpga: Secure register access for clock manager (SoC 64bits)
> > > >   arm: socfpga: Secure register access in PHY mode setup
> > > >   arm: socfpga: Secure register access for reading PLL frequency
> > > >   mmc: dwmmc: socfpga: Secure register access in MMC driver
> > > >   net: designware: socfpga: Secure register access in MAC driver
> > > >   arm: socfpga: Secure register access in Reset Manager driver
> > > >   arm: socfpga: stratix10: Initialize timer in SPL
> > > >   arm: socfpga: stratix10: Refactor FPGA reconfig driver to support ATF
> > > >   arm: socfpga: Bridge reset now invokes SMC calls to query FPGA config
> > > > status
> > > >   sysreset: socfpga: Invoke PSCI call for COLD reset
> > > >
> > > > Dalon Westergreen (1):
> > > >   configs: stratix10: Remove CONFIG_OF_EMBED
> > >
> > > This one is included in another series already:
> > > https://patchwork.ozlabs.org/user/todo/uboot/?series=132976
> > >
> > > Does this mean that one will be abandonen?
> > > So the combined hex output part of that series is not required any more?
> > >
> > > Regards,
> > > Simon
> > >
> > > >
> > > >  arch/arm/mach-socfpga/Kconfig  |   2 -
> > > >  arch/arm/mach-socfpga/Makefile |   4 +
> > > >  arch/arm/mach-socfpga/board.c  |  10 +
> > > >  arch/arm/mach-socfpga/clock_manager_agilex.c   |   5 +-
> > > >  arch/arm/mach-socfpga/clock_manager_s10.c  |   5 +-
> > > >  arch/arm/mach-socfpga/include/mach/misc.h  |   3 +
> > > >  .../mach-socfpga/include/mach/secure_reg_helper.h  |  20 ++
> > > >  arch/arm/mach-socfpga/lowlevel_init.S  |  48 +++
> > > >  arch/arm/mach-socfpga/misc_s10.c   |  47 ++-
> > > >  arch/arm/mach-socfpga/reset_manager_s10.c  |  31 +-
> > > >  arch/arm/mach-socfpga/secure_reg_helper.c  |  67 
> > > >  arch/arm/mach-socfpga/timer_s10.c  |   3 +-
> > > >  arch/arm/mach-socfpga/wrap_pll_config_s10.c|   9 +-
> > > >  board/altera/soc64/its/fit_spl_atf.its |  51 +++
> > > 

Re: [U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Simon Goldschmidt]

On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong  wrote:
>
> > On Mon, Dec 2, 2019 at 11:25 AM  wrote:
> > >
> > > From: "Ang, Chee Hong" 
> > >
> > > New U-boot flow with ARM Trusted Firmware (ATF) support:
> > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux (EL1)
> >
> > Adding support for ATF means that using U-Boot on Stratix10 and Agilex 
> > without
> > ATF keeps working, right?
> ATF is needed in order for Stratix10 and Agilex's U-Boot to work.

Is there a technical requirement for that?

Regard,
Simon

> > >
> > > SPL loads the u-boot.itb which consist of:
> > > 1) u-boot-nodtb.bin (U-Boot Proper image)
> > > 2) u-boot.dtb (U-Boot Proper DTB)
> > > 3) bl31.bin (ATF-BL31 image)
> > >
> > > Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex)
> > >
> > > Now, U-Boot Proper is running in non-secure mode (EL2), it invokes
> > > SMC/PSCI calls provided by ATF to perform COLD reset, System Manager
> > > register accesses and mailbox communications with Secure Device
> > > Manager (SDM).
> > >
> > > Steps to build the U-Boot with ATF support:
> > > 1) Build U-Boot
> > > 2) Build ATF BL31
> > > 3) Copy ATF BL31 binary image into U-Boot's root folder
> > > 4) "make u-boot.itb" to generate u-boot.itb
> > >
> > > These patchsets have dependency on:
> > > [U-Boot,v8,00/19] Add Intel Agilex SoC support:
> > > https://patchwork.ozlabs.org/cover/1201373/
> > >
> > > Chee Hong Ang (19):
> > >   arm: socfpga: add fit source file for pack itb with ATF
> > >   arm: socfpga: Add function for checking description from FIT image
> > >   arm: socfpga: Load FIT image with ATF support
> > >   arm: socfpga: Override 'lowlevel_init' to support ATF
> > >   configs: socfpga: Enable FIT image loading with ATF support
> > >   arm: socfpga: Disable "spin-table" method for booting Linux
> > >   arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits)
> > >   arm: socfpga: Define SMC function identifiers for PSCI SiP services
> > >   arm: socfpga: Add secure register access helper functions for SoC
> > > 64bits
> > >   arm: socfpga: Secure register access for clock manager (SoC 64bits)
> > >   arm: socfpga: Secure register access in PHY mode setup
> > >   arm: socfpga: Secure register access for reading PLL frequency
> > >   mmc: dwmmc: socfpga: Secure register access in MMC driver
> > >   net: designware: socfpga: Secure register access in MAC driver
> > >   arm: socfpga: Secure register access in Reset Manager driver
> > >   arm: socfpga: stratix10: Initialize timer in SPL
> > >   arm: socfpga: stratix10: Refactor FPGA reconfig driver to support ATF
> > >   arm: socfpga: Bridge reset now invokes SMC calls to query FPGA config
> > > status
> > >   sysreset: socfpga: Invoke PSCI call for COLD reset
> > >
> > > Dalon Westergreen (1):
> > >   configs: stratix10: Remove CONFIG_OF_EMBED
> >
> > This one is included in another series already:
> > https://patchwork.ozlabs.org/user/todo/uboot/?series=132976
> >
> > Does this mean that one will be abandonen?
> > So the combined hex output part of that series is not required any more?
> >
> > Regards,
> > Simon
> >
> > >
> > >  arch/arm/mach-socfpga/Kconfig  |   2 -
> > >  arch/arm/mach-socfpga/Makefile |   4 +
> > >  arch/arm/mach-socfpga/board.c  |  10 +
> > >  arch/arm/mach-socfpga/clock_manager_agilex.c   |   5 +-
> > >  arch/arm/mach-socfpga/clock_manager_s10.c  |   5 +-
> > >  arch/arm/mach-socfpga/include/mach/misc.h  |   3 +
> > >  .../mach-socfpga/include/mach/secure_reg_helper.h  |  20 ++
> > >  arch/arm/mach-socfpga/lowlevel_init.S  |  48 +++
> > >  arch/arm/mach-socfpga/misc_s10.c   |  47 ++-
> > >  arch/arm/mach-socfpga/reset_manager_s10.c  |  31 +-
> > >  arch/arm/mach-socfpga/secure_reg_helper.c  |  67 
> > >  arch/arm/mach-socfpga/timer_s10.c  |   3 +-
> > >  arch/arm/mach-socfpga/wrap_pll_config_s10.c|   9 +-
> > >  board/altera/soc64/its/fit_spl_atf.its |  51 +++
> > >  configs/socfpga_agilex_defconfig   |   8 +-
> > >  configs/socfpga_stratix10_defconfig|   9 +-
> > >  drivers/fpga/stratix10.c   | 261 --
> > >  drivers/mmc/socfpga_dw_mmc.c   |   7 +-
> > >  drivers/net/dwmac_socfpga.c|   5 +-
> > >  drivers/sysreset/sysreset_socfpga_s10.c|   4 +-
> > >  include/configs/socfpga_soc64_common.h |   2 +-
> > >  include/linux/intel-smc.h  | 374 
> > > +
> > >  22 files changed, 732 insertions(+), 243 deletions(-)  create mode
> > > 100644 arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
> > >  create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S
> > >  create mode 100644 arch/arm/mach-socfpga/secure_reg_helper.c
> > >  create mode 100644 board/altera/soc64/its/fit_spl_atf.its
> > >  create 

Re: [U-Boot] [PATCH] tools/imximage: fix reported DCD information for MX7ULP

[Fabio Estevam]

Hi Jorge,

Adding Breno.

On Thu, Nov 28, 2019 at 7:33 AM Jorge Ramirez-Ortiz  wrote:
>
> On the MX7ULP, OCRAM for DCD is at 0x2f01
>
> Signed-off-by: Jorge Ramirez-Ortiz 
> ---
>  tools/imximage.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/tools/imximage.c b/tools/imximage.c
> index d7c0b6e883..762a06d468 100644
> --- a/tools/imximage.c
> +++ b/tools/imximage.c
> @@ -11,6 +11,7 @@
>  #include "imagetool.h"
>  #include 
>  #include "imximage.h"
> +#include 
>
>  #define UNDEFINED 0x
>
> @@ -524,8 +525,13 @@ static void print_hdr_v2(struct imx_header *imx_hdr)
> printf("HAB Blocks:   0x%08x 0x%08x 0x%08x\n",
>(uint32_t)fhdr_v2->self, 0,
>(uint32_t)(fhdr_v2->csf - fhdr_v2->self));
> +#ifndef CONFIG_MX7ULP
> printf("DCD Blocks:   0x0091 0x%08x 0x%08x\n",
>offs, be16_to_cpu(dcdlen));
> +#else
> +   printf("DCD Blocks:   0x2f01 0x%08x 0x%08x\n",
> +  offs, be16_to_cpu(dcdlen));
> +#endif

Can we make the DCD OCRAM a variable passed via Kconfig and selected
by SoC type?

This way we don't need to keep changing this for future SoCs.

What do you think?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Ang, Chee Hong]

> On Mon, Dec 2, 2019 at 11:25 AM  wrote:
> >
> > From: "Ang, Chee Hong" 
> >
> > New U-boot flow with ARM Trusted Firmware (ATF) support:
> > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux (EL1)
> 
> Adding support for ATF means that using U-Boot on Stratix10 and Agilex without
> ATF keeps working, right?
ATF is needed in order for Stratix10 and Agilex's U-Boot to work.
> >
> > SPL loads the u-boot.itb which consist of:
> > 1) u-boot-nodtb.bin (U-Boot Proper image)
> > 2) u-boot.dtb (U-Boot Proper DTB)
> > 3) bl31.bin (ATF-BL31 image)
> >
> > Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex)
> >
> > Now, U-Boot Proper is running in non-secure mode (EL2), it invokes
> > SMC/PSCI calls provided by ATF to perform COLD reset, System Manager
> > register accesses and mailbox communications with Secure Device
> > Manager (SDM).
> >
> > Steps to build the U-Boot with ATF support:
> > 1) Build U-Boot
> > 2) Build ATF BL31
> > 3) Copy ATF BL31 binary image into U-Boot's root folder
> > 4) "make u-boot.itb" to generate u-boot.itb
> >
> > These patchsets have dependency on:
> > [U-Boot,v8,00/19] Add Intel Agilex SoC support:
> > https://patchwork.ozlabs.org/cover/1201373/
> >
> > Chee Hong Ang (19):
> >   arm: socfpga: add fit source file for pack itb with ATF
> >   arm: socfpga: Add function for checking description from FIT image
> >   arm: socfpga: Load FIT image with ATF support
> >   arm: socfpga: Override 'lowlevel_init' to support ATF
> >   configs: socfpga: Enable FIT image loading with ATF support
> >   arm: socfpga: Disable "spin-table" method for booting Linux
> >   arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits)
> >   arm: socfpga: Define SMC function identifiers for PSCI SiP services
> >   arm: socfpga: Add secure register access helper functions for SoC
> > 64bits
> >   arm: socfpga: Secure register access for clock manager (SoC 64bits)
> >   arm: socfpga: Secure register access in PHY mode setup
> >   arm: socfpga: Secure register access for reading PLL frequency
> >   mmc: dwmmc: socfpga: Secure register access in MMC driver
> >   net: designware: socfpga: Secure register access in MAC driver
> >   arm: socfpga: Secure register access in Reset Manager driver
> >   arm: socfpga: stratix10: Initialize timer in SPL
> >   arm: socfpga: stratix10: Refactor FPGA reconfig driver to support ATF
> >   arm: socfpga: Bridge reset now invokes SMC calls to query FPGA config
> > status
> >   sysreset: socfpga: Invoke PSCI call for COLD reset
> >
> > Dalon Westergreen (1):
> >   configs: stratix10: Remove CONFIG_OF_EMBED
> 
> This one is included in another series already:
> https://patchwork.ozlabs.org/user/todo/uboot/?series=132976
> 
> Does this mean that one will be abandonen?
> So the combined hex output part of that series is not required any more?
> 
> Regards,
> Simon
> 
> >
> >  arch/arm/mach-socfpga/Kconfig  |   2 -
> >  arch/arm/mach-socfpga/Makefile |   4 +
> >  arch/arm/mach-socfpga/board.c  |  10 +
> >  arch/arm/mach-socfpga/clock_manager_agilex.c   |   5 +-
> >  arch/arm/mach-socfpga/clock_manager_s10.c  |   5 +-
> >  arch/arm/mach-socfpga/include/mach/misc.h  |   3 +
> >  .../mach-socfpga/include/mach/secure_reg_helper.h  |  20 ++
> >  arch/arm/mach-socfpga/lowlevel_init.S  |  48 +++
> >  arch/arm/mach-socfpga/misc_s10.c   |  47 ++-
> >  arch/arm/mach-socfpga/reset_manager_s10.c  |  31 +-
> >  arch/arm/mach-socfpga/secure_reg_helper.c  |  67 
> >  arch/arm/mach-socfpga/timer_s10.c  |   3 +-
> >  arch/arm/mach-socfpga/wrap_pll_config_s10.c|   9 +-
> >  board/altera/soc64/its/fit_spl_atf.its |  51 +++
> >  configs/socfpga_agilex_defconfig   |   8 +-
> >  configs/socfpga_stratix10_defconfig|   9 +-
> >  drivers/fpga/stratix10.c   | 261 --
> >  drivers/mmc/socfpga_dw_mmc.c   |   7 +-
> >  drivers/net/dwmac_socfpga.c|   5 +-
> >  drivers/sysreset/sysreset_socfpga_s10.c|   4 +-
> >  include/configs/socfpga_soc64_common.h |   2 +-
> >  include/linux/intel-smc.h  | 374 
> > +
> >  22 files changed, 732 insertions(+), 243 deletions(-)  create mode
> > 100644 arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
> >  create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S
> >  create mode 100644 arch/arm/mach-socfpga/secure_reg_helper.c
> >  create mode 100644 board/altera/soc64/its/fit_spl_atf.its
> >  create mode 100644 include/linux/intel-smc.h
> >
> > --
> > 2.7.4
> >
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Simon Goldschmidt]

On Mon, Dec 2, 2019 at 11:25 AM  wrote:
>
> From: "Ang, Chee Hong" 
>
> New U-boot flow with ARM Trusted Firmware (ATF) support:
> SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux (EL1)

Adding support for ATF means that using U-Boot on Stratix10 and Agilex without
ATF keeps working, right?

>
> SPL loads the u-boot.itb which consist of:
> 1) u-boot-nodtb.bin (U-Boot Proper image)
> 2) u-boot.dtb (U-Boot Proper DTB)
> 3) bl31.bin (ATF-BL31 image)
>
> Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex)
>
> Now, U-Boot Proper is running in non-secure mode (EL2), it invokes
> SMC/PSCI calls provided by ATF to perform COLD reset, System Manager
> register accesses and mailbox communications with Secure Device Manager
> (SDM).
>
> Steps to build the U-Boot with ATF support:
> 1) Build U-Boot
> 2) Build ATF BL31
> 3) Copy ATF BL31 binary image into U-Boot's root folder
> 4) "make u-boot.itb" to generate u-boot.itb
>
> These patchsets have dependency on:
> [U-Boot,v8,00/19] Add Intel Agilex SoC support:
> https://patchwork.ozlabs.org/cover/1201373/
>
> Chee Hong Ang (19):
>   arm: socfpga: add fit source file for pack itb with ATF
>   arm: socfpga: Add function for checking description from FIT image
>   arm: socfpga: Load FIT image with ATF support
>   arm: socfpga: Override 'lowlevel_init' to support ATF
>   configs: socfpga: Enable FIT image loading with ATF support
>   arm: socfpga: Disable "spin-table" method for booting Linux
>   arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits)
>   arm: socfpga: Define SMC function identifiers for PSCI SiP services
>   arm: socfpga: Add secure register access helper functions for SoC
> 64bits
>   arm: socfpga: Secure register access for clock manager (SoC 64bits)
>   arm: socfpga: Secure register access in PHY mode setup
>   arm: socfpga: Secure register access for reading PLL frequency
>   mmc: dwmmc: socfpga: Secure register access in MMC driver
>   net: designware: socfpga: Secure register access in MAC driver
>   arm: socfpga: Secure register access in Reset Manager driver
>   arm: socfpga: stratix10: Initialize timer in SPL
>   arm: socfpga: stratix10: Refactor FPGA reconfig driver to support ATF
>   arm: socfpga: Bridge reset now invokes SMC calls to query FPGA config
> status
>   sysreset: socfpga: Invoke PSCI call for COLD reset
>
> Dalon Westergreen (1):
>   configs: stratix10: Remove CONFIG_OF_EMBED

This one is included in another series already:
https://patchwork.ozlabs.org/user/todo/uboot/?series=132976

Does this mean that one will be abandonen?
So the combined hex output part of that series is not required any more?

Regards,
Simon

>
>  arch/arm/mach-socfpga/Kconfig  |   2 -
>  arch/arm/mach-socfpga/Makefile |   4 +
>  arch/arm/mach-socfpga/board.c  |  10 +
>  arch/arm/mach-socfpga/clock_manager_agilex.c   |   5 +-
>  arch/arm/mach-socfpga/clock_manager_s10.c  |   5 +-
>  arch/arm/mach-socfpga/include/mach/misc.h  |   3 +
>  .../mach-socfpga/include/mach/secure_reg_helper.h  |  20 ++
>  arch/arm/mach-socfpga/lowlevel_init.S  |  48 +++
>  arch/arm/mach-socfpga/misc_s10.c   |  47 ++-
>  arch/arm/mach-socfpga/reset_manager_s10.c  |  31 +-
>  arch/arm/mach-socfpga/secure_reg_helper.c  |  67 
>  arch/arm/mach-socfpga/timer_s10.c  |   3 +-
>  arch/arm/mach-socfpga/wrap_pll_config_s10.c|   9 +-
>  board/altera/soc64/its/fit_spl_atf.its |  51 +++
>  configs/socfpga_agilex_defconfig   |   8 +-
>  configs/socfpga_stratix10_defconfig|   9 +-
>  drivers/fpga/stratix10.c   | 261 --
>  drivers/mmc/socfpga_dw_mmc.c   |   7 +-
>  drivers/net/dwmac_socfpga.c|   5 +-
>  drivers/sysreset/sysreset_socfpga_s10.c|   4 +-
>  include/configs/socfpga_soc64_common.h |   2 +-
>  include/linux/intel-smc.h  | 374 
> +
>  22 files changed, 732 insertions(+), 243 deletions(-)
>  create mode 100644 arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
>  create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S
>  create mode 100644 arch/arm/mach-socfpga/secure_reg_helper.c
>  create mode 100644 board/altera/soc64/its/fit_spl_atf.its
>  create mode 100644 include/linux/intel-smc.h
>
> --
> 2.7.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/6] net: introduce DSA class for Ethernet switches

[Alexandru Marginean]

On 12/1/2019 5:17 AM, Florian Fainelli wrote:



On 11/30/2019 6:21 PM, Alexandru Marginean wrote:

Hi Joe,

On 11/30/2019 1:56 AM, Joe Hershberger wrote:

Hi Alex,

On Mon, Nov 25, 2019 at 9:54 AM Alex Marginean
 wrote:


DSA stands for Distributed Switch Architecture and it covers switches
that
are connected to the CPU through an Ethernet link and generally use
frame
tags to pass information about the source/destination ports to/from CPU.
Front panel ports are presented as regular ethernet devices in U-Boot
and
they are expected to support the typical networking commands.
DSA switches may be cascaded, DSA class code does not currently support
this.


Is it expected to eventually retrofit the other switch drivers that we
have in U-Boot to use this?


For now I would like to at least make sure that the uclass code allows
that to happen.  Longer term yes, it would be nice to get existing
drivers converted.  This is applicable to switches that rely on a master
Eth device for I/O.  The list should include switches that use DSA in
kernel, of course:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/dsa


Some of these are under PHYs in U-Boot right now (like b53, mv88exxx),
hooked up to the master Eth.  This works, but comes with limitations,
like this in b53 driver:
  * The configuration determines which PHY ports to activate using the
  * CONFIG_B53_PHY_PORTS bitmask. Set bit N will active port N and so on.
Having these drivers converted should come with some benefits:
- their DT nodes would be in sync with the kernel DSA bindings,
- users would have some run-time control over the switch ports used for
I/O,
- driving PHYs of front panel ports comes more naturally with these
ports being registered as eth devices.

There are other switches which don't fall under DSA, those that present
some sort of direct I/O interface to the CPU and don't rely on a master
Eth device.  These switched may not follow DSA bindings, since they are
not technically DSA.  For them we could either have a more generic Eth
switch class or just let the drivers register the switch device or the
ports on the switch as Eth devices.


The Device Tree binding for DSA is actually fairly generic within the
'ports' container node, if you omit the ethernet phandle, this still
allows you to describe a multi-port Ethernet switch with the data path
being contained solely within the switch node and not spread across a
DSA master and a discrete switch. At least, this could be a starting point.



It is, I don't disagree with that.  My argument is DSA-like binding 
isn't enforced in kernel tree for non-DSA switches (is it?) and allowing 
U-Boot to use existing kernel DTs for non-DSA switches is a good thing.


Binding aside I still think DSA should be a class of its own in U-Boot. 
There are differences in the API between DSA ports and Eth devices and 
DSA uclass has the code dealing with master Eth, which is useless for 
non-DSA.  I think this way the code and the interface to the drivers is 
simpler and more clear.


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

Re: [U-Boot] [PATCH 0/8] Transition of fsl qspi driver to spi-mem framework

[Schrempf Frieder]

+ Ashish

Hi Kuldeep,

On 29.11.19 06:54, Kuldeep Singh wrote:
> This entire patch series migrate freescale qspi driver to spi-mem framework.

First, thanks for working on this. I have this on my list for quite a 
long time, but struggled to find enough time to actually get it done.

> 
> Patch 1 removes the old fsl qspi driver

You shouldn't remove the old driver before the new one is in place, as 
this breaks the build in between the two patches.

> 
> Patch 2 adds new qspi driver incorporating spi-mem framework which is ported
> version of linux qspi driver. Initial port was done by Frieder. Now, no more
> direct access to spi-nor memory is possible. Few changes were introduced to
> prevent uboot crash such as to add complete flash size to SFA1AD, SFA2AD,
> SFB1AD, SFB2AD based on chip select number instead of 1k. Immediate effect was
> observed on pfe while using 1k size as it access spi-nor memory directly. 
> Using
> complete flash size resolves the crash but data read will not be valid.

Can you provide more information about the problem/crash you experience 
and the platform you are working on?

Are you referring to the same issue as Ashish in this discussion here [1]?

There are two reasons why I'd like to avoid using the whole memory 
mapped area for AHB access.
First, I'd like to keep the U-Boot driver as close as possible to the 
Linux driver.
Second, the intention of the spi-mem layer is to abstract the flash 
layer and therefore this driver should work independently of flash type 
or size. With your version this wouldn't be the case if you connect a 
flash that is bigger than the memory map for example.

Thanks,
Frieder

[1]: https://lists.denx.de/pipermail/u-boot/2019-October/387788.html

> 
> Patch 3 removes unused config options.
> 
> Patch 4 moves FSL_QSPI config to defconfigs instead of defining in header 
> files.
> SPI_FLASH_SPANSION is enabled while disabling SPI_FLASH_BAR.
> 
> Patch 5 removes unused num-cs property for imx platforms
> 
> Patch 6 enables SPI_FLASH_SPANSION for ls1012 boards. SPI_FLASH_BAR is no 
> longer
> required and can be removed.
> 
> Patch 7 move SPI_FLASH_SPANSION to defconfigs instead of header files. While
> enabling SPI_FLASH_SPANSION config, also disable SPI_FLASH_BAR at the same 
> time.
> 
> Patch 8 updates the device-tree properties treewide for layerscape boards by
> aligning it with linux device-tree properties.
> 
> Frieder Schrempf (1):
>imx: imx6sx: Remove unused 'num-cs' property
> 
> Kuldeep Singh (7):
>spi: Remove old freescale qspi driver
>spi: Transform the FSL QuadSPI driver to use the SPI MEM API
>treewide: Remove unused FSL QSPI config options
>configs: ls1043a: Move CONFIG_FSL_QSPI to defconfig
>configs: ls1012a: Enable SPI_FLASH_SPANSION in defconfig
>configs: ls1046a: Move SPI_FLASH_SPANSION to defconfig
>treewide: Update fsl qspi node dt properties as per spi-mem driver
> 
>   arch/arm/dts/fsl-ls1012a-frdm.dtsi|5 +-
>   arch/arm/dts/fsl-ls1012a-qds.dtsi |5 +-
>   arch/arm/dts/fsl-ls1012a-rdb.dtsi |5 +-
>   arch/arm/dts/fsl-ls1012a.dtsi |4 +-
>   arch/arm/dts/fsl-ls1043a-qds.dtsi |5 +-
>   arch/arm/dts/fsl-ls1043a.dtsi |6 +-
>   arch/arm/dts/fsl-ls1046a-frwy.dts |5 +-
>   arch/arm/dts/fsl-ls1046a-qds.dtsi |5 +-
>   arch/arm/dts/fsl-ls1046a-rdb.dts  |5 +-
>   arch/arm/dts/fsl-ls1046a.dtsi |4 +-
>   arch/arm/dts/fsl-ls1088a-qds.dts  |5 +-
>   arch/arm/dts/fsl-ls1088a-rdb.dts  |5 +-
>   arch/arm/dts/fsl-ls1088a.dtsi |2 +-
>   arch/arm/dts/fsl-ls2080a-qds.dts  |5 +-
>   arch/arm/dts/fsl-ls2080a.dtsi |4 +-
>   arch/arm/dts/fsl-ls2088a-rdb-qspi.dts |5 +-
>   arch/arm/dts/imx6sx-sabreauto-u-boot.dtsi |2 -
>   arch/arm/dts/imx6sx-sdb-u-boot.dtsi   |2 -
>   arch/arm/dts/ls1021a-twr.dtsi |5 +-
>   arch/arm/dts/ls1021a.dtsi |6 +-
>   .../include/asm/arch-fsl-layerscape/config.h  |1 -
>   arch/arm/include/asm/arch-ls102xa/config.h|1 -
>   configs/ls1012aqds_qspi_defconfig |2 +-
>   configs/ls1012aqds_tfa_defconfig  |2 +-
>   configs/ls1012ardb_qspi_SECURE_BOOT_defconfig |2 +-
>   configs/ls1012ardb_qspi_defconfig |2 +-
>   configs/ls1012ardb_tfa_defconfig  |2 +-
>   configs/ls1043aqds_qspi_defconfig |2 +-
>   configs/ls1043aqds_sdcard_qspi_defconfig  |2 +-
>   configs/ls1043aqds_tfa_SECURE_BOOT_defconfig  |2 +
>   configs/ls1043aqds_tfa_defconfig  |2 +-
>   configs/ls1046aqds_qspi_defconfig |2 +-
>   configs/ls1046aqds_sdcard_qspi_defconfig  |2 +-
>   configs/ls1046aqds_tfa_SECURE_BOOT_defconfig  |1 +
>   configs/ls1046aqds_tfa_defconfig  

Re: [U-Boot] [PATCH 0/4] omapl138_lcdk: fix MMC boot

[Adam Ford]

On Mon, Dec 2, 2019 at 3:32 AM Bartosz Golaszewski  wrote:
>
> czw., 14 lis 2019 o 16:10 Bartosz Golaszewski  napisał(a):
> >
> > From: Bartosz Golaszewski 
> >
> > Booting from MMC on omapl138-lcdk is currently broken after we enabled
> > driver-model in SPL. While I know what's wrong - the bind() callback not
> > being called - I can't for the life of me figure out how to fix it.
> >
> > I'm still working on proper changes, but for now, I'd like to propose
> > this series which fixes MMC boot with a workaround in which we call
> > mmc_boot() manually from probe.
> >
> > First two patches drop some legacy code that's no longer needed. The
> > third patch adds a U_BOOT_DEVICE() for mmc as we don't yet have full
> > DT support (also in-progress). The last patch adds the workaround to
> > the davinci mmc driver.
> >
> > This series depends on Adam Ford's patch increasing the pre-reloc
> > malloc pool.
> >
> > [1] https://patchwork.ozlabs.org/patch/1192574/
> >
> > Bartosz Golaszewski (4):
> >   mmc: davinci: drop support for ti,dm6441-mmc
> >   mmc: davinci: drop struct davinci_mmc_plat
> >   board: omapl138_lcdk: add the mmc device to SPL
> >   mmc: davinci: fix mmc boot in SPL
> >
> >  arch/arm/mach-davinci/Kconfig |  1 +
> >  .../mach-davinci/include/mach/sdmmc_defs.h|  6 --
> >  board/davinci/da8xxevm/omapl138_lcdk.c| 10 ++-
> >  drivers/mmc/davinci_mmc.c | 73 +++
> >  4 files changed, 36 insertions(+), 54 deletions(-)
> >
> > --
> > 2.23.0
> >
>
> Gentle ping.

I wonder if having a 'fixes:' tag would help move things along.

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

Re: [U-Boot] [PATCH v2 0/6] J721e: Add networking support

[Grygorii Strashko]

On 02/12/2019 10:59, Vignesh Raghavendra wrote:

This patch enables networking support for TI's J721e SoC.
Patch 1 adds a new interface to DMA uclass to get channel specific
private/configuration data. Patch 2 to 4 use this interface to pass data
from J721e's UDMA driver to CPSW ethernet driver. Last two patches add
DMA and CPSW DT nodes and configs.

Depends on [1] for ethernet to work

[1] http://patchwork.ozlabs.org/project/uboot/list/?series=145954

v2:
Address comments from Grygorii.
Collect Acks


Few minor comments.

Reviewed-by: Grygorii Strashko 



Vignesh Raghavendra (6):
   dma: Introduce dma_get_cfg() interface
   dma: ti: k3-udma: Implement dma_get_cfg() interface
   net: ti: am65-cpsw-nuss: Rework RX flow ID handling
   net: ti: am65-cpsw-nuss: Add new compatible for J721e
   arm: dts: k3-j721e-common-proc-board: Add DMA and CPSW related DT
 nodes
   configs: j721e_evm_a72_defconfig: Enable DMA and Ethernet

  .../k3-j721e-common-proc-board-u-boot.dtsi| 239 ++
  configs/j721e_evm_a72_defconfig   |   8 +
  drivers/dma/dma-uclass.c  |  12 +
  drivers/dma/ti/k3-udma.c  |  30 ++-
  drivers/net/ti/am65-cpsw-nuss.c   |  14 +-
  include/dma-uclass.h  |  11 +
  include/dma.h |  11 +
  include/linux/soc/ti/ti-udma.h|  19 ++
  8 files changed, 334 insertions(+), 10 deletions(-)



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

Re: [U-Boot] [PATCH v2 5/6] arm: dts: k3-j721e-common-proc-board: Add DMA and CPSW related DT nodes

[Grygorii Strashko]

On 02/12/2019 10:59, Vignesh Raghavendra wrote:

Add DT nodes related to DMA and CPSW to -u-boot.dtsi to get networking
up on J721e EVM.

Signed-off-by: Vignesh Raghavendra 
Acked-by: Joe Hershberger 
---
  .../k3-j721e-common-proc-board-u-boot.dtsi| 239 ++
  1 file changed, 239 insertions(+)

diff --git a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi 
b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
index 541da22c4889..f3857b9100bb 100644
--- a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
@@ -3,11 +3,18 @@
   * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
   */
  
+#include 

+#include 
+
  / {
chosen {
stdout-path = "serial2:115200n8";
tick-timer = 
};
+
+   aliases {
+   ethernet0 = _port1;
+   };
  };
  
  _main{

@@ -24,6 +31,184 @@
clock-frequency = <2500>;
u-boot,dm-spl;
};
+


[...]


+_mdio {
+   phy0: ethernet-phy@0 {
+   reg = <0>;
+   /* TODO: phy reset: 
TCA9555RTWR(i2c:0x21)[p04].GPIO_MCU_RGMII_RSTN */


Could you drop this TODO pls?


+   ti,rx-internal-delay = ;
+   ti,fifo-depth = ;
+   };
+};
+
+_port1 {
+   phy-mode = "rgmii-rxid";
+   phy-handle = <>;
+};
+
+_cpsw {
+   reg = <0x0 0x4600 0x0 0x20>,
+ <0x0 0x40f00200 0x0 0x2>;
+   reg-names = "cpsw_nuss", "mac_efuse";
+
+   cpsw-phy-sel@40f04040 {
+   compatible = "ti,am654-cpsw-phy-sel";
+   reg= <0x0 0x40f04040 0x0 0x4>;
+   reg-names = "gmii-sel";
+   };
+};



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

Re: [U-Boot] [PATCH v2 3/6] net: ti: am65-cpsw-nuss: Rework RX flow ID handling

[Grygorii Strashko]

On 02/12/2019 10:59, Vignesh Raghavendra wrote:

Get flow ID information for RX DMA channel using dma_get_cfg() interface
instead of reading from DT. This is required in order to avoid DT update
whenever there is change in the range of flow ID allocated to the host.

Signed-off-by: Vignesh Raghavendra 
Acked-by: Joe Hershberger 
---
  drivers/net/ti/am65-cpsw-nuss.c | 13 -
  1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index 06b06639506a..2e14f4be862f 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -99,7 +99,6 @@ struct am65_cpsw_common {
  
  	u32			port_num;

struct am65_cpsw_port   ports[AM65_CPSW_CPSWNU_MAX_PORTS];
-   u32 rflow_id_base;
  
  	struct mii_dev		*bus;

u32 bus_freq;
@@ -276,6 +275,7 @@ static int am65_cpsw_start(struct udevice *dev)
struct am65_cpsw_common *common = priv->cpsw_common;
struct am65_cpsw_port *port = >ports[priv->port_id];
struct am65_cpsw_port *port0 = >ports[0];
+   struct ti_udma_drv_chan_cfg_data *dma_rx_cfg_data;
int ret, i;
  
  	ret = power_domain_on(>pwrdmn);

@@ -341,7 +341,8 @@ static int am65_cpsw_start(struct udevice *dev)
writel(PKTSIZE_ALIGN, port0->port_base + AM65_CPSW_PN_RX_MAXLEN_REG);
  
  	/* set base flow_id */

-   writel(common->rflow_id_base,
+   dma_get_cfg(>dma_rx, 0, (void **)_rx_cfg_data);
+   writel(dma_rx_cfg_data->flow_id_base,
   port0->port_base + AM65_CPSW_P0_FLOW_ID_REG);


Could you add dbg print here, hence you've dropped it below, pls?

  
  	/* Reset and enable the ALE */

@@ -669,11 +670,6 @@ static int am65_cpsw_probe_cpsw(struct udevice *dev)
AM65_CPSW_CPSW_NU_ALE_BASE;
cpsw_common->mdio_base = cpsw_common->ss_base + AM65_CPSW_MDIO_BASE;
  
-	cpsw_common->rflow_id_base = 0;

-   cpsw_common->rflow_id_base =
-   dev_read_u32_default(dev, "ti,rx-flow-id-base",
-cpsw_common->rflow_id_base);
-
ports_np = dev_read_subnode(dev, "ports");
if (!ofnode_valid(ports_np)) {
ret = -ENOENT;
@@ -761,12 +757,11 @@ static int am65_cpsw_probe_cpsw(struct udevice *dev)
if (ret)
goto out;
  
-	dev_info(dev, "K3 CPSW: nuss_ver: 0x%08X cpsw_ver: 0x%08X ale_ver: 0x%08X Ports:%u rflow_id_base:%u mdio_freq:%u\n",

+   dev_info(dev, "K3 CPSW: nuss_ver: 0x%08X cpsw_ver: 0x%08X ale_ver: 0x%08X 
Ports:%u mdio_freq:%u\n",
 readl(cpsw_common->ss_base),
 readl(cpsw_common->cpsw_base),
 readl(cpsw_common->ale_base),
 cpsw_common->port_num,
-cpsw_common->rflow_id_base,
 cpsw_common->bus_freq);
  
  out:




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

Re: [U-Boot] [PATCH] net: eth-uclass: ignore unavailable devices

[Alexandru Marginean]

On 12/1/2019 5:43 PM, Michael Walle wrote:

Am 2019-12-01 01:55, schrieb Alexandru Marginean:

Hi Michael,

On 10/22/2019 1:03 AM, Michael Walle wrote:

device_probe() may fail in which case the seq_id will be -1. Don't
display these devices during startup. While this is only a cosmetic
change, the return value of eth_initialize() will also change to the
actual number of available devices. The return value is only used in
spl_net to decide whether there are any devices to boot from. So
returning only available devices is also more correct in that case.

Signed-off-by: Michael Walle 
---
  net/eth-uclass.c | 17 +++--
  1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/net/eth-uclass.c b/net/eth-uclass.c
index 3bd98b01ad..acd59216e3 100644
--- a/net/eth-uclass.c
+++ b/net/eth-uclass.c
@@ -420,20 +420,25 @@ int eth_initialize(void)
    bootstage_mark(BOOTSTAGE_ID_NET_ETH_INIT);
  do {
-    if (num_devices)
-    printf(", ");
+    if (dev->seq != -1) {
+    if (num_devices)
+    printf(", ");
  -    printf("eth%d: %s", dev->seq, dev->name);
+    printf("eth%d: %s", dev->seq, dev->name);
  -    if (ethprime && dev == prime_dev)
-    printf(" [PRIME]");
+    if (ethprime && dev == prime_dev)
+    printf(" [PRIME]");
+    }
    eth_write_hwaddr(dev);
  +    if (dev->seq != -1)
+    num_devices++;
  uclass_next_device_check();
-    num_devices++;
  } while (dev);
  +    if (!num_devices)
+    printf("No ethernet found.\n");
  putc('\n');
  }



What would you say about something like this instead?  It's a bit more
compact and should be functionally equivalent:


sure, but I've noticed that this is only part of the fix (or isn't even
necessary). At least, it doesn't work if the first device is unavailable,
because eth_get_dev() will then fail. You should be able to reproduce
the issue if you disable the first enetc of the LS1028A. Then network
should only work if ethact is set.

I've traced that back to the pci enumeration which doesn't respect the
'status = "disabled"' property. But instead someone added that check to
the enetc driver, but that doesn't really work, because the device is
already included in the uclass list. See separate patch, I'll send in a
minute.

-michael


For disabled nodes the pci_find_and_bind_driver patch is sufficient.
We should probably deal with drivers failing to probe for other reasons 
too, there could be other legitimate reasons for that to happen.


how about the eth_initialize patch plus:

--- a/net/eth-uclass.c
+++ b/net/eth-uclass.c
@@ -69,8 +69,8 @@ struct udevice *eth_get_dev(void)

uc_priv = eth_get_uclass_priv();
if (!uc_priv->current)
-   eth_errno = uclass_first_device(UCLASS_ETH,
-   _priv->current);
+   uclass_get_device_by_seq(UCLASS_ETH, 0, _priv->current);
+
return uc_priv->current;
 }

Since seq == -1 on devices that fail to probe this code will ignore them.

Or add uclass helpers that only deal with devices that probe 
successfully: uclass_get_first_device_active, 
uclass_get_next_device_active and uclass_foreach_dev_active.


Alex





 net/eth-uclass.c | 54 ++--
 1 file changed, 25 insertions(+), 29 deletions(-)

diff --git a/net/eth-uclass.c b/net/eth-uclass.c
index 1bc8947749..4d4eaeb371 100644
--- a/net/eth-uclass.c
+++ b/net/eth-uclass.c
@@ -390,10 +390,16 @@ int eth_rx(void)

 int eth_initialize(void)
 {
+    struct udevice *dev, *prime_dev = NULL;
+    char *ethprime = env_get("ethprime");
 int num_devices = 0;
-    struct udevice *dev;
+    struct uclass *uc;

 eth_common_init();
+    eth_set_dev(NULL);
+
+    if (ethprime)
+    prime_dev = eth_get_dev_by_name(ethprime);

 /*
  * Devices need to write the hwaddr even if not started so that 
Linux

@@ -401,40 +407,30 @@ int eth_initialize(void)
  * This is accomplished by attempting to probe each device and 
calling

  * their write_hwaddr() operation.
  */
-    uclass_first_device_check(UCLASS_ETH, );
-    if (!dev) {
-    printf("No ethernet found.\n");
-    bootstage_error(BOOTSTAGE_ID_NET_ETH_START);
-    } else {
-    char *ethprime = env_get("ethprime");
-    struct udevice *prime_dev = NULL;
+    uclass_get(UCLASS_ETH, );
+    uclass_foreach_dev(dev, uc) {
+    if (device_probe(dev))
+    continue;
+
+    eth_write_hwaddr(dev);
+
+    if (num_devices)
+    printf(", ");
+    printf("eth%d: %s", dev->seq, dev->name);

-    if (ethprime)
-    prime_dev = eth_get_dev_by_name(ethprime);
-    if (prime_dev) {
+    if (dev == prime_dev) {
 eth_set_dev(prime_dev);
 eth_current_changed();
-    } else {
- 

Re: [U-Boot] [PATCH RESEND v2 00/10] dma: ti: k3-udma: Add support for J721e

[Grygorii Strashko]

On 02/12/2019 10:54, Vignesh Raghavendra wrote:

This series adds DMA support for J721e using exist K3 UDMA driver.

One main change is thati, on J721e, DMA resources such as DMA channels are
shared between different entities running on different cores of the SoC.
Therefore, U-Boot running on A72 core should request range of resources
allocated to it from centralized resource management core (DMSC) and use
only the allocated resource.

First two patches adds support for dynamically querying and using
allocated resources. Remaining patches fix issues when using UDMA driver
on a 32 bit core like R5. Last patch adds a new compatible for J721e

Vignesh Raghavendra (10):
   lib: Import few bitmap functions from Linux
   dma: ti: k3-udma: Query DMA channels allocated from Resource Manager
   soc: ti: k3-navss-ringacc: Flush/invalidate caches on ring push/pop
   soc: ti: k3-navss-ringacc: Get SYSFW reference from DT phandle
   dma: ti: k3-udma: Remove coherency check for cache ops
   dma: ti: k3-udma: Fix debug prints during enabling MEM_TO_DEV
 transfers
   dma: ti: k3-udma: Switch to exposed ring mode
   dma: ti: k3-udma: Fix ring push operation for 32 bit cores
   dma: ti: k3-udma: Fix build warnings when building for 32 bit
 platforms
   dma: ti: k3-udma: Add new compatible to J721e

  drivers/dma/ti/k3-udma-hwdef.h|  19 ++
  drivers/dma/ti/k3-udma.c  | 346 --
  drivers/soc/ti/k3-navss-ringacc.c |  13 +-
  include/linux/bitmap.h| 133 
  include/linux/bitops.h|  12 ++
  5 files changed, 403 insertions(+), 120 deletions(-)



minor comment to patch 2.
Otherwise:
Reviewed-by: Grygorii Strashko 

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

Re: [U-Boot] [PATCH RESEND v2 02/10] dma: ti: k3-udma: Query DMA channels allocated from Resource Manager

[Grygorii Strashko]

On 02/12/2019 10:54, Vignesh Raghavendra wrote:

On K3 SoCs, DMA channels are shared across multiple entities, therefore
U-Boot DMA driver needs to query resource range from centralised
resource management controller i.e SystemFirmware and use DMA channels
allocated for A72 host. Add support for the same.

Signed-off-by: Vignesh Raghavendra 
---
v2:
Address comments on v1 from Grygorii
Squash patch 5 (of v1) into this patch

  drivers/dma/ti/k3-udma-hwdef.h |  19 +++
  drivers/dma/ti/k3-udma.c   | 274 +++--
  2 files changed, 214 insertions(+), 79 deletions(-)

diff --git a/drivers/dma/ti/k3-udma-hwdef.h b/drivers/dma/ti/k3-udma-hwdef.h
index c88399a815ea..228a44cb73cf 100644
--- a/drivers/dma/ti/k3-udma-hwdef.h
+++ b/drivers/dma/ti/k3-udma-hwdef.h
@@ -181,4 +181,23 @@
  #define PDMA_STATIC_TR_Z(x)   \
(((x) << PDMA_STATIC_TR_Z_SHIFT) & PDMA_STATIC_TR_Z_MASK)
  
+enum udma_rm_range {

+   RM_RANGE_TCHAN = 0,
+   RM_RANGE_RCHAN,
+   RM_RANGE_RFLOW,
+   RM_RANGE_LAST,
+};
+
+struct udma_tisci_rm {
+   const struct ti_sci_handle *tisci;
+   const struct ti_sci_rm_udmap_ops *tisci_udmap_ops;
+   u32  tisci_dev_id;
+
+   /* tisci information for PSI-L thread pairing/unpairing */
+   const struct ti_sci_rm_psil_ops *tisci_psil_ops;
+   u32  tisci_navss_dev_id;
+
+   struct ti_sci_resource *rm_ranges[RM_RANGE_LAST];
+};


I'd move it in k3-udma.c


+
  #endif /* K3_NAVSS_UDMA_HWDEF_H_ */
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index a5fc7809bc41..2f82ab0955a4 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -11,12 +11,14 @@
  #include 


[...]

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

[U-Boot] [PATCH v4 6/6] config: enable DFU over USB on Raspberry Pi4 boards

[Marek Szyprowski]

Enable support for DFU over USB. This requires to enable USB gadget,
DWC2 UDC OTG driver and DFU command. DFU entities are defined for the
following firmware objects: u-boot.bin, uboot.env, config.txt, and
zImage/Image.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Lukasz Majewski 
---
 configs/rpi_4_32b_defconfig | 11 +++
 configs/rpi_4_defconfig | 11 +++
 include/configs/rpi.h   | 20 
 3 files changed, 42 insertions(+)

diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig
index 7ff390cd24..9d0515029c 100644
--- a/configs/rpi_4_32b_defconfig
+++ b/configs/rpi_4_32b_defconfig
@@ -12,6 +12,7 @@ CONFIG_MISC_INIT_R=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SYS_PROMPT="U-Boot> "
+CONFIG_CMD_DFU=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_MMC=y
@@ -21,6 +22,7 @@ CONFIG_ENV_FAT_INTERFACE="mmc"
 CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
+CONFIG_DFU_MMC=y
 CONFIG_DM_KEYBOARD=y
 CONFIG_DM_MMC=y
 CONFIG_MMC_SDHCI=y
@@ -28,6 +30,15 @@ CONFIG_MMC_SDHCI_BCM2835=y
 CONFIG_PINCTRL=y
 # CONFIG_PINCTRL_GENERIC is not set
 # CONFIG_REQUIRE_SERIAL_CONSOLE is not set
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_DM_USB_GADGET=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_MANUFACTURER="FSL"
+CONFIG_USB_GADGET_VENDOR_NUM=0x0525
+CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
+CONFIG_USB_GADGET_DWC2_OTG=y
+CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_DM_VIDEO=y
 CONFIG_SYS_WHITE_ON_BLACK=y
 CONFIG_CONSOLE_SCROLL_LINES=10
diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig
index c5089eb9c8..3d660d182a 100644
--- a/configs/rpi_4_defconfig
+++ b/configs/rpi_4_defconfig
@@ -12,6 +12,7 @@ CONFIG_MISC_INIT_R=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SYS_PROMPT="U-Boot> "
+CONFIG_CMD_DFU=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_MMC=y
@@ -21,6 +22,7 @@ CONFIG_ENV_FAT_INTERFACE="mmc"
 CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
+CONFIG_DFU_MMC=y
 CONFIG_DM_KEYBOARD=y
 CONFIG_DM_MMC=y
 CONFIG_MMC_SDHCI=y
@@ -28,6 +30,15 @@ CONFIG_MMC_SDHCI_BCM2835=y
 CONFIG_PINCTRL=y
 # CONFIG_PINCTRL_GENERIC is not set
 # CONFIG_REQUIRE_SERIAL_CONSOLE is not set
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_DM_USB_GADGET=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_MANUFACTURER="FSL"
+CONFIG_USB_GADGET_VENDOR_NUM=0x0525
+CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
+CONFIG_USB_GADGET_DWC2_OTG=y
+CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_DM_VIDEO=y
 CONFIG_SYS_WHITE_ON_BLACK=y
 CONFIG_CONSOLE_SCROLL_LINES=10
diff --git a/include/configs/rpi.h b/include/configs/rpi.h
index 83e258a6b9..b53a4b65d0 100644
--- a/include/configs/rpi.h
+++ b/include/configs/rpi.h
@@ -74,6 +74,25 @@
 #define CONFIG_TFTP_TSIZE
 #endif
 
+/* DFU over USB/UDC */
+#ifdef CONFIG_CMD_DFU
+#define CONFIG_SYS_DFU_DATA_BUF_SIZE   SZ_1M
+#define CONFIG_SYS_DFU_MAX_FILE_SIZE   SZ_2M
+
+#ifdef CONFIG_ARM64
+#define KERNEL_FILENAME"Image"
+#else
+#define KERNEL_FILENAME"zImage"
+#endif
+
+#define ENV_DFU_SETTINGS \
+   "dfu_alt_info=u-boot.bin fat 0 1;uboot.env fat 0 1;" \
+ "config.txt fat 0 1;" \
+ KERNEL_FILENAME " fat 0 1\0"
+#else
+#define ENV_DFU_SETTINGS ""
+#endif
+
 /* Console configuration */
 #define CONFIG_SYS_CBSIZE  1024
 
@@ -188,6 +207,7 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
"dhcpuboot=usb start; dhcp u-boot.uimg; bootm\0" \
ENV_DEVICE_SETTINGS \
+   ENV_DFU_SETTINGS \
ENV_MEM_LAYOUT_SETTINGS \
BOOTENV
 
-- 
2.17.1

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

[U-Boot] [PATCH v4 3/6] dfu: mmc: rearrange the code

[Marek Szyprowski]

Rename functions for bufferred file io operations to make them easier to
understand. Also add missing file offset argument to them (currently
unused). All this is a preparation to remove predefined file size limit
(CONFIG_SYS_DFU_MAX_FILE_SIZE) for DFU read/write operations.

Signed-off-by: Marek Szyprowski 
Acked-by: Lukasz Majewski 
---
 drivers/dfu/dfu_mmc.c | 61 ---
 1 file changed, 34 insertions(+), 27 deletions(-)

diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index 5b551f6ae1..e52c02be10 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -91,22 +91,8 @@ static int mmc_block_op(enum dfu_op op, struct dfu_entity 
*dfu,
return 0;
 }
 
-static int mmc_file_buffer(struct dfu_entity *dfu, void *buf, long *len)
-{
-   if (dfu_file_buf_len + *len > CONFIG_SYS_DFU_MAX_FILE_SIZE) {
-   dfu_file_buf_len = 0;
-   return -EINVAL;
-   }
-
-   /* Add to the current buffer. */
-   memcpy(dfu_file_buf + dfu_file_buf_len, buf, *len);
-   dfu_file_buf_len += *len;
-
-   return 0;
-}
-
 static int mmc_file_op(enum dfu_op op, struct dfu_entity *dfu,
-   void *buf, u64 *len)
+   u64 offset, void *buf, u64 *len)
 {
char dev_part_str[8];
int ret;
@@ -137,7 +123,7 @@ static int mmc_file_op(enum dfu_op op, struct dfu_entity 
*dfu,
 
switch (op) {
case DFU_OP_READ:
-   ret = fs_read(dfu->name, (size_t)buf, 0, 0, );
+   ret = fs_read(dfu->name, (size_t)buf, offset, 0, );
if (ret) {
puts("dfu: fs_read error!\n");
return ret;
@@ -145,7 +131,7 @@ static int mmc_file_op(enum dfu_op op, struct dfu_entity 
*dfu,
*len = size;
break;
case DFU_OP_WRITE:
-   ret = fs_write(dfu->name, (size_t)buf, 0, *len, );
+   ret = fs_write(dfu->name, (size_t)buf, offset, *len, );
if (ret) {
puts("dfu: fs_write error!\n");
return ret;
@@ -166,6 +152,30 @@ static int mmc_file_op(enum dfu_op op, struct dfu_entity 
*dfu,
return ret;
 }
 
+static int mmc_file_buf_write(struct dfu_entity *dfu, u64 offset, void *buf, 
long *len)
+{
+   if (dfu_file_buf_len + *len > CONFIG_SYS_DFU_MAX_FILE_SIZE) {
+   dfu_file_buf_len = 0;
+   return -EINVAL;
+   }
+
+   /* Add to the current buffer. */
+   memcpy(dfu_file_buf + dfu_file_buf_len, buf, *len);
+   dfu_file_buf_len += *len;
+
+   return 0;
+}
+
+static int mmc_file_buf_write_finish(struct dfu_entity *dfu)
+{
+   int ret = mmc_file_op(DFU_OP_WRITE, dfu, 0, dfu_file_buf,
+   _file_buf_len);
+
+   /* Now that we're done */
+   dfu_file_buf_len = 0;
+   return ret;
+}
+
 int dfu_write_medium_mmc(struct dfu_entity *dfu,
u64 offset, void *buf, long *len)
 {
@@ -177,7 +187,7 @@ int dfu_write_medium_mmc(struct dfu_entity *dfu,
break;
case DFU_FS_FAT:
case DFU_FS_EXT4:
-   ret = mmc_file_buffer(dfu, buf, len);
+   ret = mmc_file_buf_write(dfu, offset, buf, len);
break;
default:
printf("%s: Layout (%s) not (yet) supported!\n", __func__,
@@ -193,11 +203,7 @@ int dfu_flush_medium_mmc(struct dfu_entity *dfu)
 
if (dfu->layout != DFU_RAW_ADDR) {
/* Do stuff here. */
-   ret = mmc_file_op(DFU_OP_WRITE, dfu, dfu_file_buf,
-   _file_buf_len);
-
-   /* Now that we're done */
-   dfu_file_buf_len = 0;
+   ret = mmc_file_buf_write_finish(dfu);
}
 
return ret;
@@ -214,7 +220,7 @@ int dfu_get_medium_size_mmc(struct dfu_entity *dfu, u64 
*size)
case DFU_FS_FAT:
case DFU_FS_EXT4:
dfu_file_buf_filled = -1;
-   ret = mmc_file_op(DFU_OP_SIZE, dfu, NULL, size);
+   ret = mmc_file_op(DFU_OP_SIZE, dfu, 0, NULL, size);
if (ret < 0)
return ret;
if (*size > CONFIG_SYS_DFU_MAX_FILE_SIZE)
@@ -227,14 +233,15 @@ int dfu_get_medium_size_mmc(struct dfu_entity *dfu, u64 
*size)
}
 }
 
-static int mmc_file_unbuffer(struct dfu_entity *dfu, u64 offset, void *buf,
+
+static int mmc_file_buf_read(struct dfu_entity *dfu, u64 offset, void *buf,
 long *len)
 {
int ret;
u64 file_len;
 
if (dfu_file_buf_filled == -1) {
-   ret = mmc_file_op(DFU_OP_READ, dfu, dfu_file_buf, _len);
+   ret = mmc_file_op(DFU_OP_READ, dfu, 0, dfu_file_buf, _len);
if (ret < 0)
return ret;
dfu_file_buf_filled = file_len;
@@ -259,7 +266,7 @@ int dfu_read_medium_mmc(struct dfu_entity *dfu, u64 offset, 
void *buf,
  

[U-Boot] [PATCH v4 1/6] fat: write: fix broken write to fragmented files

[Marek Szyprowski]

The code for handing file overwrite incorrectly assumed that the file on
disk is always contiguous. This resulted in corrupting disk structure
every time when write to existing fragmented file happened. Fix this
by adding proper check for cluster discontinuity and adjust chunk size
on each partial write.

Signed-off-by: Marek Szyprowski 
---

This patch partially fixes the issue revealed by the following test
script:

--->8-fat_test1.sh---
#!/bin/bash
make sandbox_defconfig
make
dd if=/dev/zero of=/tmp/10M.img bs=1024 count=10k
mkfs.vfat -v /tmp/10M.img
cat >/tmp/cmds /tmp/model/file0003.raw
yes ABC | head -c 4096 >/tmp/model/file0005.raw
yes DEF | head -c 16384 >/tmp/model/file0007.raw
mcopy -n -i /tmp/10M.img ::file0001.raw /tmp/result
mcopy -n -i /tmp/10M.img ::file0003.raw /tmp/result
mcopy -n -i /tmp/10M.img ::file0005.raw /tmp/result
mcopy -n -i /tmp/10M.img ::file0007.raw /tmp/result
hd /tmp/10M.img
if diff -urq /tmp/model /tmp/result
then
echo Test okay
else
echo Test fail
fi
--->8---

Overwritting a discontiguous test file (file0007.raw) no longer causes
corruption to file0003.raw, which's data lies between the chunks of the
test file. The amount of data written to disk is still incorrect, what
causes damage to the file (file0005.raw), which's data lies next to the
test file. This will be fixed by the next patch.

Feel free to prepare a proper sandbox/py_test based tests based on the
provided test scripts.
---
 fs/fat/fat_write.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index 729cf39630..f946030f7d 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -794,6 +794,8 @@ set_contents(fsdata *mydata, dir_entry *dentptr, loff_t 
pos, __u8 *buffer,
 
newclust = get_fatent(mydata, endclust);
 
+   if (newclust != endclust + 1)
+   break;
if (IS_LAST_CLUST(newclust, mydata->fatsize))
break;
if (CHECK_CLUST(newclust, mydata->fatsize)) {
@@ -824,8 +826,6 @@ set_contents(fsdata *mydata, dir_entry *dentptr, loff_t 
pos, __u8 *buffer,
if (filesize <= cur_pos)
break;
 
-   /* CHECK: newclust = get_fatent(mydata, endclust); */
-
if (IS_LAST_CLUST(newclust, mydata->fatsize))
/* no more clusters */
break;
-- 
2.17.1

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

[U-Boot] [PATCH v4 4/6] dfu: mmc: remove file size limit for io operations

[Marek Szyprowski]

Add support for operations on files larger than
CONFIG_SYS_DFU_MAX_FILE_SIZE. The buffered io mechanism is still used for
aggregating io requests, so for files up to CONFIG_SYS_DFU_MAX_FILE_SIZE
nothing is changed and they will be handled in a single filesystem call.

Signed-off-by: Marek Szyprowski 
Acked-by: Lukasz Majewski 
---
 drivers/dfu/dfu_mmc.c | 46 ---
 1 file changed, 30 insertions(+), 16 deletions(-)

diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index e52c02be10..0d495a785b 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -17,7 +17,7 @@
 
 static unsigned char *dfu_file_buf;
 static u64 dfu_file_buf_len;
-static long dfu_file_buf_filled;
+static u64 dfu_file_buf_offset;
 
 static int mmc_block_op(enum dfu_op op, struct dfu_entity *dfu,
u64 offset, void *buf, long *len)
@@ -123,7 +123,7 @@ static int mmc_file_op(enum dfu_op op, struct dfu_entity 
*dfu,
 
switch (op) {
case DFU_OP_READ:
-   ret = fs_read(dfu->name, (size_t)buf, offset, 0, );
+   ret = fs_read(dfu->name, (size_t)buf, offset, *len, );
if (ret) {
puts("dfu: fs_read error!\n");
return ret;
@@ -154,25 +154,38 @@ static int mmc_file_op(enum dfu_op op, struct dfu_entity 
*dfu,
 
 static int mmc_file_buf_write(struct dfu_entity *dfu, u64 offset, void *buf, 
long *len)
 {
-   if (dfu_file_buf_len + *len > CONFIG_SYS_DFU_MAX_FILE_SIZE) {
+   int ret = 0;
+
+   if (offset == 0) {
dfu_file_buf_len = 0;
-   return -EINVAL;
+   dfu_file_buf_offset = 0;
}
 
/* Add to the current buffer. */
+   if (dfu_file_buf_len + *len > CONFIG_SYS_DFU_MAX_FILE_SIZE)
+   *len = CONFIG_SYS_DFU_MAX_FILE_SIZE - dfu_file_buf_len;
memcpy(dfu_file_buf + dfu_file_buf_len, buf, *len);
dfu_file_buf_len += *len;
 
-   return 0;
+   if (dfu_file_buf_len == CONFIG_SYS_DFU_MAX_FILE_SIZE) {
+   ret = mmc_file_op(DFU_OP_WRITE, dfu, dfu_file_buf_offset,
+ dfu_file_buf, _file_buf_len);
+   dfu_file_buf_offset += dfu_file_buf_len;
+   dfu_file_buf_len = 0;
+   }
+
+   return ret;
 }
 
 static int mmc_file_buf_write_finish(struct dfu_entity *dfu)
 {
-   int ret = mmc_file_op(DFU_OP_WRITE, dfu, 0, dfu_file_buf,
-   _file_buf_len);
+   int ret = mmc_file_op(DFU_OP_WRITE, dfu, dfu_file_buf_offset,
+   dfu_file_buf, _file_buf_len);
 
/* Now that we're done */
dfu_file_buf_len = 0;
+   dfu_file_buf_offset = 0;
+
return ret;
 }
 
@@ -219,12 +232,9 @@ int dfu_get_medium_size_mmc(struct dfu_entity *dfu, u64 
*size)
return 0;
case DFU_FS_FAT:
case DFU_FS_EXT4:
-   dfu_file_buf_filled = -1;
ret = mmc_file_op(DFU_OP_SIZE, dfu, 0, NULL, size);
if (ret < 0)
return ret;
-   if (*size > CONFIG_SYS_DFU_MAX_FILE_SIZE)
-   return -1;
return 0;
default:
printf("%s: Layout (%s) not (yet) supported!\n", __func__,
@@ -238,19 +248,23 @@ static int mmc_file_buf_read(struct dfu_entity *dfu, u64 
offset, void *buf,
 long *len)
 {
int ret;
-   u64 file_len;
 
-   if (dfu_file_buf_filled == -1) {
-   ret = mmc_file_op(DFU_OP_READ, dfu, 0, dfu_file_buf, _len);
+   if (offset == 0 || offset >= dfu_file_buf_offset + dfu_file_buf_len ||
+   offset + *len < dfu_file_buf_offset) {
+   u64 file_len = CONFIG_SYS_DFU_MAX_FILE_SIZE;
+
+   ret = mmc_file_op(DFU_OP_READ, dfu, offset, dfu_file_buf,
+ _len);
if (ret < 0)
return ret;
-   dfu_file_buf_filled = file_len;
+   dfu_file_buf_len = file_len;
+   dfu_file_buf_offset = offset;
}
-   if (offset + *len > dfu_file_buf_filled)
+   if (offset + *len > dfu_file_buf_offset + dfu_file_buf_len)
return -EINVAL;
 
/* Add to the current buffer. */
-   memcpy(buf, dfu_file_buf + offset, *len);
+   memcpy(buf, dfu_file_buf + offset - dfu_file_buf_offset, *len);
 
return 0;
 }
-- 
2.17.1

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

[U-Boot] [PATCH v4 5/6] usb: dwc2_udc_otg: add bcm2835 SoC (Raspberry Pi4) support

[Marek Szyprowski]

Broadcom 2835 SoC requires special conversion of physical memory addresses
for DMA purpose, so add needed wrappers to dwc2_udc_otg driver. Also extend
the list of compatible devices with 'brcm,bcm2835-usb' entry. This allows
to use USB gadget drivers (i.e. DFU) on Raspberry Pi4 boards.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Lukasz Majewski 
---
 drivers/usb/gadget/dwc2_udc_otg.c  |  2 ++
 drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 12 ++--
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/gadget/dwc2_udc_otg.c 
b/drivers/usb/gadget/dwc2_udc_otg.c
index 35f4147840..49f342eb21 100644
--- a/drivers/usb/gadget/dwc2_udc_otg.c
+++ b/drivers/usb/gadget/dwc2_udc_otg.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -1213,6 +1214,7 @@ static int dwc2_udc_otg_remove(struct udevice *dev)
 
 static const struct udevice_id dwc2_udc_otg_ids[] = {
{ .compatible = "snps,dwc2" },
+   { .compatible = "brcm,bcm2835-usb" },
{ .compatible = "st,stm32mp1-hsotg",
  .data = (ulong)dwc2_set_stm32mp1_hsotg_params },
{},
diff --git a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c 
b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
index 7eb632d3b1..5e695b4ff2 100644
--- a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
+++ b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c
@@ -28,7 +28,7 @@ static inline void dwc2_udc_ep0_zlp(struct dwc2_udc *dev)
 {
u32 ep_ctrl;
 
-   writel(usb_ctrl_dma_addr, >in_endp[EP0_CON].diepdma);
+   writel(phys_to_bus((unsigned long)usb_ctrl_dma_addr), 
>in_endp[EP0_CON].diepdma);
writel(DIEPT_SIZ_PKT_CNT(1), >in_endp[EP0_CON].dieptsiz);
 
ep_ctrl = readl(>in_endp[EP0_CON].diepctl);
@@ -49,7 +49,7 @@ static void dwc2_udc_pre_setup(void)
 
writel(DOEPT_SIZ_PKT_CNT(1) | sizeof(struct usb_ctrlrequest),
   >out_endp[EP0_CON].doeptsiz);
-   writel(usb_ctrl_dma_addr, >out_endp[EP0_CON].doepdma);
+   writel(phys_to_bus((unsigned long)usb_ctrl_dma_addr), 
>out_endp[EP0_CON].doepdma);
 
ep_ctrl = readl(>out_endp[EP0_CON].doepctl);
writel(ep_ctrl|DEPCTL_EPENA, >out_endp[EP0_CON].doepctl);
@@ -75,7 +75,7 @@ static inline void dwc2_ep0_complete_out(void)
 
writel(DOEPT_SIZ_PKT_CNT(1) | sizeof(struct usb_ctrlrequest),
   >out_endp[EP0_CON].doeptsiz);
-   writel(usb_ctrl_dma_addr, >out_endp[EP0_CON].doepdma);
+   writel(phys_to_bus((unsigned long)usb_ctrl_dma_addr), 
>out_endp[EP0_CON].doepdma);
 
ep_ctrl = readl(>out_endp[EP0_CON].doepctl);
writel(ep_ctrl|DEPCTL_EPENA|DEPCTL_CNAK,
@@ -113,7 +113,7 @@ static int setdma_rx(struct dwc2_ep *ep, struct 
dwc2_request *req)
(unsigned long) ep->dma_buf +
ROUND(ep->len, CONFIG_SYS_CACHELINE_SIZE));
 
-   writel((unsigned long) ep->dma_buf, >out_endp[ep_num].doepdma);
+   writel(phys_to_bus((unsigned long)ep->dma_buf), 
>out_endp[ep_num].doepdma);
writel(DOEPT_SIZ_PKT_CNT(pktcnt) | DOEPT_SIZ_XFER_SIZE(length),
   >out_endp[ep_num].doeptsiz);
writel(DEPCTL_EPENA|DEPCTL_CNAK|ctrl, >out_endp[ep_num].doepctl);
@@ -161,7 +161,7 @@ static int setdma_tx(struct dwc2_ep *ep, struct 
dwc2_request *req)
while (readl(>grstctl) & TX_FIFO_FLUSH)
;
 
-   writel((unsigned long) ep->dma_buf, >in_endp[ep_num].diepdma);
+   writel(phys_to_bus((unsigned long)ep->dma_buf), 
>in_endp[ep_num].diepdma);
writel(DIEPT_SIZ_PKT_CNT(pktcnt) | DIEPT_SIZ_XFER_SIZE(length),
   >in_endp[ep_num].dieptsiz);
 
@@ -921,7 +921,7 @@ static int dwc2_udc_get_status(struct dwc2_udc *dev,
   (unsigned long) usb_ctrl +
   ROUND(sizeof(g_status), CONFIG_SYS_CACHELINE_SIZE));
 
-   writel(usb_ctrl_dma_addr, >in_endp[EP0_CON].diepdma);
+   writel(phys_to_bus(usb_ctrl_dma_addr), >in_endp[EP0_CON].diepdma);
writel(DIEPT_SIZ_PKT_CNT(1) | DIEPT_SIZ_XFER_SIZE(2),
   >in_endp[EP0_CON].dieptsiz);
 
-- 
2.17.1

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

[U-Boot] [PATCH v4 0/6] Raspberry Pi4: add support for DFU over USB

[Marek Szyprowski]

Hi All!

This patchset enables support for DFU over USB protocol on Raspberry Pi4
board. The board has DWC2 UDC controller connected to the USB-C power
connector. Enabling DFU on it, make the u-boot development much more
convenient, as one no longer needs to swap SD-card between RPi4 board and
host machine to update the u-boot binary.

Patches are based on current 'master' u-boot branch. They were tested on
the 2019-07-10-raspbian-buster-lite.img sd-card image with the following
lines added to config.txt:
dtoverlay=dwc2,dr_mode=peripheral
dtparam=i2c_arm=on
dtparam=spi=on
enable_uart=1
uart_2ndstage=1
kernel=u-boot.bin

To enable DFU, one has to enter follwing command:
# dfu 0 mmc 0

During the development of this feature I've encountered a serious bugs
in FAT write code. Over-writing discontiguous files always caused serious
filesystem corruption. This was especially anoying, because the system
environment is kept on FAT volume in uboot.env file, so 'saveenv'
basically corrupted the boot partiting on the second call. Another bunch
of the issues in the FAT write code has been revealed while removing
predefined file size limit in DFU MMC code and then running sandbox
tests.

I hope that my fixes for FAT code will be helpful for non-RPi users too.

Best regards
Marek Szyprowski
Samsung R Institute Poland


Changelog:

v4:
- rechecked the FAT related fixes, it turned out that much simpler patch
  fixes both issues discovered while working on DFU support; added simple
  sandbox based tests reveleaing the issue and showing correctness
  of the fix
- rebased patches onto current u-boot's master branch: 4b19b89ca4a8
  ("Merge tag 'rpi-next-2020.01' of https://github.com/mbgg/u-boot;)

v3: https://patchwork.ozlabs.org/cover/1200793/
- fixed one more FAT issue revealed by sandbox tests

v3: (patch 6/6 posted separately): https://patchwork.ozlabs.org/patch/1195645/
- fixed non-RPi4 builds (missing #else ENV_DFU_SETTINGS def)
- removed config.txt entity (not needed in uboot-based boot)
- switched arm64 kernel filename to 'Image'

v2: https://patchwork.ozlabs.org/cover/1166589/
- added changes to rpi_4_defconfig too (arm64 version)
- extended DFU entity list by confix.txt, cmdline.txt and Image.gz
- fixed missing '\0' at the end of dfu_alt_info env
- added reviewed-by tags
- added patches for DFU MMC to remove file size limit
- added patch for fat write to fix issues on non-zero file offset
  (revealed by previous patch)

v1: https://patchwork.ozlabs.org/cover/1162770/
- initial version


Patch summary:

Marek Szyprowski (6):
  fat: write: fix broken write to fragmented files
  fat: write: adjust data written in each partial write
  dfu: mmc: rearrange the code
  dfu: mmc: remove file size limit for io operations
  usb: dwc2_udc_otg: add bcm2835 SoC (Raspberry Pi4) support
  config: enable DFU over USB on Raspberry Pi4 boards

 configs/rpi_4_32b_defconfig| 11 +++
 configs/rpi_4_defconfig| 11 +++
 drivers/dfu/dfu_mmc.c  | 93 +-
 drivers/usb/gadget/dwc2_udc_otg.c  |  2 +
 drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 12 +--
 fs/fat/fat_write.c |  8 +-
 include/configs/rpi.h  | 20 +
 7 files changed, 112 insertions(+), 45 deletions(-)

-- 
2.17.1

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

[U-Boot] [PATCH v4 2/6] fat: write: adjust data written in each partial write

[Marek Szyprowski]

The code for handing file overwrite incorrectly calculated the amount of
data to write when writing to the last non-cluster aligned chunk. Fix
this by ensuring that no more data than the 'filesize' is written to disk.
While touching min()-based calculations, change it to type-safe min_t()
function.

Signed-off-by: Marek Szyprowski 
---

This patch finally fixes the issue revealed by the test script from the
previous patch. The correctness of the change has been also verified by
the following additional test scripts:

--->8-fat_test2.sh---
#!/bin/bash
make sandbox_defconfig
make
dd if=/dev/zero of=/tmp/10M.img bs=1024 count=10k
mkfs.vfat -v /tmp/10M.img
cat >/tmp/cmds /tmp/model/file0003.raw
yes ABC | head -c 4096 >/tmp/model/file0005.raw
yes DEF | head -c 7936 >/tmp/model/file0007.raw
mcopy -n -i /tmp/10M.img ::file0001.raw /tmp/result
mcopy -n -i /tmp/10M.img ::file0003.raw /tmp/result
mcopy -n -i /tmp/10M.img ::file0005.raw /tmp/result
mcopy -n -i /tmp/10M.img ::file0007.raw /tmp/result
hd /tmp/10M.img
if diff -urq /tmp/model /tmp/result
then
echo Test okay
else
echo Test fail
fi
--->8-fat_test3.sh---
#!/bin/bash
make sandbox_defconfig
make
dd if=/dev/zero of=/tmp/10M.img bs=1024 count=10k
mkfs.vfat -v /tmp/10M.img
cat >/tmp/cmds /tmp/model/file0003.raw
yes ABC | head -c 4096 >/tmp/model/file0005.raw
yes DEF | head -c 8448 >/tmp/model/file0007.raw
mcopy -n -i /tmp/10M.img ::file0001.raw /tmp/result
mcopy -n -i /tmp/10M.img ::file0003.raw /tmp/result
mcopy -n -i /tmp/10M.img ::file0005.raw /tmp/result
mcopy -n -i /tmp/10M.img ::file0007.raw /tmp/result
hd /tmp/10M.img
if diff -urq /tmp/model /tmp/result
then
echo Test okay
else
echo Test fail
fi
--->8-fat_test4.sh---
#!/bin/bash
make sandbox_defconfig
make
dd if=/dev/zero of=/tmp/10M.img bs=1024 count=10k
mkfs.vfat -v /tmp/10M.img
cat >/tmp/cmds /tmp/model/file0003.raw
yes ABC | head -c 4096 >/tmp/model/file0005.raw
yes DEF | head -c 2304 >/tmp/model/file0007.raw
yes GHI | head -c 2304 >>/tmp/model/file0007.raw
yes DEF | head -c 2304 >>/tmp/model/file0007.raw
yes GHI | head -c 2304 >>/tmp/model/file0007.raw
mcopy -n -i /tmp/10M.img ::file0001.raw /tmp/result
mcopy -n -i /tmp/10M.img ::file0003.raw /tmp/result
mcopy -n -i /tmp/10M.img ::file0005.raw /tmp/result
mcopy -n -i /tmp/10M.img ::file0007.raw /tmp/result
hd /tmp/10M.img
if diff -urq /tmp/model /tmp/result
then
echo Test okay
else
echo Test fail
fi
--->8---
Feel free to prepare a proper sandbox/py_test based tests based on
the provided test scripts.
---
 fs/fat/fat_write.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index f946030f7d..8e4a235d7c 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -813,7 +813,9 @@ set_contents(fsdata *mydata, dir_entry *dentptr, loff_t 
pos, __u8 *buffer,
offset = 0;
else
offset = pos - cur_pos;
-   wsize = min(cur_pos + actsize, filesize) - pos;
+   wsize = min_t(unsigned long long, actsize, filesize - cur_pos);
+   wsize -= offset;
+
if (get_set_cluster(mydata, curclust, offset,
buffer, wsize, )) {
printf("Error get-and-setting cluster\n");
-- 
2.17.1

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

[U-Boot] [PATCH] configs: ls1028aqds: enable mdio muxing by default

[Alex Marginean]

LS1028A QDS boards have a MDIO MUX and they require the driver for it for
PHYs to work.

Signed-off-by: Alex Marginean 
---
 configs/ls1028aqds_tfa_SECURE_BOOT_defconfig | 2 ++
 configs/ls1028aqds_tfa_defconfig | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig 
b/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig
index 65e467817e..b5dceb4471 100644
--- a/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig
+++ b/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig
@@ -50,9 +50,11 @@ CONFIG_PHY_ATHEROS=y
 CONFIG_PHY_VITESSE=y
 CONFIG_DM_ETH=y
 CONFIG_DM_MDIO=y
+CONFIG_DM_MDIO_MUX=y
 CONFIG_DM_DSA=y
 CONFIG_E1000=y
 CONFIG_MSCC_FELIX_SWITCH=y
+CONFIG_MDIO_MUX_I2CREG=y
 CONFIG_PCI=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
diff --git a/configs/ls1028aqds_tfa_defconfig b/configs/ls1028aqds_tfa_defconfig
index 40d259d907..e75d140e94 100644
--- a/configs/ls1028aqds_tfa_defconfig
+++ b/configs/ls1028aqds_tfa_defconfig
@@ -56,9 +56,11 @@ CONFIG_PHY_ATHEROS=y
 CONFIG_PHY_VITESSE=y
 CONFIG_DM_ETH=y
 CONFIG_DM_MDIO=y
+CONFIG_DM_MDIO_MUX=y
 CONFIG_DM_DSA=y
 CONFIG_E1000=y
 CONFIG_MSCC_FELIX_SWITCH=y
+CONFIG_MDIO_MUX_I2CREG=y
 CONFIG_PCI=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
-- 
2.17.1

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

Re: [U-Boot] [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem framework

[Kuldeep Singh]

+ Ye li

Hi Stefan,

> -Original Message-
> From: Stefan Roese 
> Sent: Monday, December 2, 2019 3:38 PM
> To: Kuldeep Singh ; u-boot@lists.denx.de
> Cc: Priyanka Jain ; ja...@amarulasolutions.com;
> frieder.schre...@kontron.de
> Subject: [EXT] Re: [PATCH 0/8] Transition of fsl qspi driver to spi-mem
> framework
> 
> Caution: EXT Email
> 
> Hi Kuldeep,
> 
> On 29.11.19 06:54, Kuldeep Singh wrote:
> > This entire patch series migrate freescale qspi driver to spi-mem
> framework.
> >
> > Patch 1 removes the old fsl qspi driver
> >
> > Patch 2 adds new qspi driver incorporating spi-mem framework which is
> > ported version of linux qspi driver. Initial port was done by Frieder.
> > Now, no more direct access to spi-nor memory is possible. Few changes
> > were introduced to prevent uboot crash such as to add complete flash
> > size to SFA1AD, SFA2AD, SFB1AD, SFB2AD based on chip select number
> > instead of 1k. Immediate effect was observed on pfe while using 1k
> > size as it access spi-nor memory directly. Using complete flash size
> resolves the crash but data read will not be valid.
> >
> > Patch 3 removes unused config options.
> >
> > Patch 4 moves FSL_QSPI config to defconfigs instead of defining in header
> files.
> > SPI_FLASH_SPANSION is enabled while disabling SPI_FLASH_BAR.
> >
> > Patch 5 removes unused num-cs property for imx platforms
> >
> > Patch 6 enables SPI_FLASH_SPANSION for ls1012 boards. SPI_FLASH_BAR
> is
> > no longer required and can be removed.
> >
> > Patch 7 move SPI_FLASH_SPANSION to defconfigs instead of header files.
> > While enabling SPI_FLASH_SPANSION config, also disable SPI_FLASH_BAR
> at the same time.
> >
> > Patch 8 updates the device-tree properties treewide for layerscape
> > boards by aligning it with linux device-tree properties.
> 
> Many thanks for working on this. I've tested this patchset on a new i-
> MX6ULL/ULZ based board and noticed, that I still need to add this kind of
> patch to make it work on my platform:
> 
>  drivers/spi/fsl_qspi.c 
>  index
> 788fa0416f..0946f9d6d5 100644 @@ -44,6 +44,9 @@
> DECLARE_GLOBAL_DATA_PTR;
>   #define QUADSPI_IPCR  0x08
>   #define QUADSPI_IPCR_SEQID(x) ((x) << 24)
> 
> +#define QUADSPI_FLSHCR 0x0c
> +#define QUADSPI_FLSHCR_TDH(x)  ((x) << 16)
> +
>   #define QUADSPI_BUF3CR0x1c
>   #define QUADSPI_BUF3CR_ALLMST_MASKBIT(31)
>   #define QUADSPI_BUF3CR_ADATSZ(x)  ((x) << 8)
> @@ -666,6 +669,16 @@ static int fsl_qspi_default_setup(struct fsl_qspi *q)
> QUADSPI_BUF3CR_ADATSZ(q->devtype_data->ahb_buf_size / 8),
> base + QUADSPI_BUF3CR);
> 
> +   /*
> +* Clear THD bits to configure SDR mode instead of DDR mode. This
> +* might be necessary, as the BootROM in some versions and on some
> +* SoCs sets these bits to 0x1 for DDR mode. But this driver needs
> +* it set to SDR mode instead.
> +*/
> +   reg = qspi_readl(q, base + QUADSPI_FLSHCR);
> +   reg &= ~QUADSPI_FLSHCR_TDH(0x3);
> +   qspi_writel(q, reg, base + QUADSPI_FLSHCR);
> 
> This was suggested by Frieder and is also integrated in the Linux QSPI driver:
> 
> Commit ID f6910679e17a ("spi: spi-fsl-qspi: Clear TDH bits in FLSHCR
> register")
> 
> What is the status of SDR vs DDR mode in this driver? Is this driver version
> supposed to handle DDR mode correctly? If not, could you please integrate
> this patch (or Frieder's Linux patch) into your patchset so that the driver 
> also
> works on i.MX6ULL/ULZ ?

I will port Frieder's patch for i.mx from Linux to Uboot.
Meanwhile, I am waiting for comments on other patches so that I'll incorporate 
all changes in next version.

@Ye li
Please see attached email for reference.
Does Frieder's patch(f6910679e17a) resolves the fix proposed by you.
Also, can you please help in testing other i.mx platforms after including the 
change.

Thanks
Kuldeep

> 
> Thanks,
> Stefan
> 
> > Frieder Schrempf (1):
> >imx: imx6sx: Remove unused 'num-cs' property
> >
> > Kuldeep Singh (7):
> >spi: Remove old freescale qspi driver
> >spi: Transform the FSL QuadSPI driver to use the SPI MEM API
> >treewide: Remove unused FSL QSPI config options
> >configs: ls1043a: Move CONFIG_FSL_QSPI to defconfig
> >configs: ls1012a: Enable SPI_FLASH_SPANSION in defconfig
> >configs: ls1046a: Move SPI_FLASH_SPANSION to defconfig
> >treewide: Update fsl qspi node dt properties as per spi-mem driver
> >
> >   arch/arm/dts/fsl-ls1012a-frdm.dtsi|5 +-
> >   arch/arm/dts/fsl-ls1012a-qds.dtsi |5 +-
> >   arch/arm/dts/fsl-ls1012a-rdb.dtsi |5 +-
> >   arch/arm/dts/fsl-ls1012a.dtsi |4 +-
> >   arch/arm/dts/fsl-ls1043a-qds.dtsi |5 +-
> >   arch/arm/dts/fsl-ls1043a.dtsi |6 +-
> >   arch/arm/dts/fsl-ls1046a-frwy.dts  

[U-Boot] [PATCH v1 06/20] configs: socfpga: Enable FIT image loading with ATF support

[chee . hong . ang]

From: Chee Hong Ang 

SPL now loads ATF (BL31), U-Boot proper and DTB from FIT
image. The new boot flow with ATF support is as follow:

SPL -> ATF (BL31) -> U-Boot proper -> OS (Linux)

Signed-off-by: Chee Hong Ang 
---
 configs/socfpga_agilex_defconfig| 8 +++-
 configs/socfpga_stratix10_defconfig | 8 +++-
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/configs/socfpga_agilex_defconfig b/configs/socfpga_agilex_defconfig
index cdb9396..48c1bd6 100644
--- a/configs/socfpga_agilex_defconfig
+++ b/configs/socfpga_agilex_defconfig
@@ -1,6 +1,6 @@
 CONFIG_ARM=y
 CONFIG_ARCH_SOCFPGA=y
-CONFIG_SYS_TEXT_BASE=0x1000
+CONFIG_SYS_TEXT_BASE=0x20
 CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_ENV_SIZE=0x1000
 CONFIG_ENV_OFFSET=0x200
@@ -9,10 +9,16 @@ CONFIG_TARGET_SOCFPGA_AGILEX_SOCDK=y
 CONFIG_IDENT_STRING="socfpga_agilex"
 CONFIG_SPL_FS_FAT=y
 CONFIG_SPL_TEXT_BASE=0xFFE0
+CONFIG_FIT=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_SOURCE="board/altera/soc64/its/fit_spl_atf.its"
 CONFIG_BOOTDELAY=5
+CONFIG_SPL_LEGACY_IMAGE_SUPPORT=y
 CONFIG_SPL_CACHE=y
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_SYS_SPI_U_BOOT_OFFS=0x3c0
+CONFIG_SPL_ATF=y
+CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="SOCFPGA_AGILEX # "
 CONFIG_CMD_MEMTEST=y
diff --git a/configs/socfpga_stratix10_defconfig 
b/configs/socfpga_stratix10_defconfig
index 903d17b..c3d6e68 100644
--- a/configs/socfpga_stratix10_defconfig
+++ b/configs/socfpga_stratix10_defconfig
@@ -1,6 +1,6 @@
 CONFIG_ARM=y
 CONFIG_ARCH_SOCFPGA=y
-CONFIG_SYS_TEXT_BASE=0x1000
+CONFIG_SYS_TEXT_BASE=0x20
 CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_ENV_SIZE=0x1000
 CONFIG_ENV_OFFSET=0x200
@@ -9,9 +9,15 @@ CONFIG_TARGET_SOCFPGA_STRATIX10_SOCDK=y
 CONFIG_IDENT_STRING="socfpga_stratix10"
 CONFIG_SPL_FS_FAT=y
 CONFIG_SPL_TEXT_BASE=0xFFE0
+CONFIG_FIT=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_SOURCE="board/altera/soc64/its/fit_spl_atf.its"
 CONFIG_BOOTDELAY=5
+CONFIG_SPL_LEGACY_IMAGE_SUPPORT=y
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_SYS_SPI_U_BOOT_OFFS=0x3C0
+CONFIG_SPL_ATF=y
+CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="SOCFPGA_STRATIX10 # "
 CONFIG_CMD_MEMTEST=y
-- 
2.7.4

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

[U-Boot] [PATCH v1 08/20] arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits)

[chee . hong . ang]

From: Chee Hong Ang 

Allow U-Boot proper running in non-secure mode (EL2) to invoke
SMC call to ATF's PSCI runtime services such as System Manager's
registers access, 2nd phase bitstream FPGA reconfiguration,
Remote System Update (RSU) and etc.

Signed-off-by: Chee Hong Ang 
---
 arch/arm/mach-socfpga/include/mach/misc.h |  3 +++
 arch/arm/mach-socfpga/misc_s10.c  | 26 ++
 2 files changed, 29 insertions(+)

diff --git a/arch/arm/mach-socfpga/include/mach/misc.h 
b/arch/arm/mach-socfpga/include/mach/misc.h
index f6de1cc..b939250 100644
--- a/arch/arm/mach-socfpga/include/mach/misc.h
+++ b/arch/arm/mach-socfpga/include/mach/misc.h
@@ -43,4 +43,7 @@ void do_bridge_reset(int enable, unsigned int mask);
 void socfpga_pl310_clear(void);
 void socfpga_get_managers_addr(void);
 
+#ifdef CONFIG_ARM_SMCCC
+int invoke_smc(u32 func_id, u64 *args, int arg_len, u64 *ret_arg, int ret_len);
+#endif
 #endif /* _SOCFPGA_MISC_H_ */
diff --git a/arch/arm/mach-socfpga/misc_s10.c b/arch/arm/mach-socfpga/misc_s10.c
index a3f5b43..2d63175 100644
--- a/arch/arm/mach-socfpga/misc_s10.c
+++ b/arch/arm/mach-socfpga/misc_s10.c
@@ -164,3 +164,29 @@ void do_bridge_reset(int enable, unsigned int mask)
 
socfpga_bridges_reset(enable);
 }
+
+#ifdef CONFIG_ARM_SMCCC
+int invoke_smc(u32 func_id, u64 *args, int arg_len, u64 *ret_arg, int ret_len)
+{
+   int i;
+   struct pt_regs regs;
+
+   memset(, 0, sizeof(regs));
+
+   regs.regs[0] = func_id;
+
+   if (args) {
+   for (i = 0; i < arg_len; i++)
+   regs.regs[i + 1] = args[i];
+   }
+
+   smc_call();
+
+   if (ret_arg) {
+   for (i = 0; i < ret_len; i++)
+   ret_arg[i] = regs.regs[i + 1];
+   }
+
+   return regs.regs[0];
+}
+#endif
-- 
2.7.4

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

[U-Boot] [PATCH v1 20/20] sysreset: socfpga: Invoke PSCI call for COLD reset

[chee . hong . ang]

From: Chee Hong Ang 

Instead of sending mailbox command to trigger COLD reset, sysreset driver
now call "SYSTEM_RESET" PSCI runtime service provided by ATF to trigger
COLD reset.

Signed-off-by: Chee Hong Ang 
---
 drivers/sysreset/sysreset_socfpga_s10.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/sysreset/sysreset_socfpga_s10.c 
b/drivers/sysreset/sysreset_socfpga_s10.c
index 9837aad..96cf61e 100644
--- a/drivers/sysreset/sysreset_socfpga_s10.c
+++ b/drivers/sysreset/sysreset_socfpga_s10.c
@@ -8,13 +8,11 @@
 #include 
 #include 
 #include 
-#include 
 
 static int socfpga_sysreset_request(struct udevice *dev,
enum sysreset_t type)
 {
-   puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
-   mbox_reset_cold();
+   psci_system_reset();
return -EINPROGRESS;
 }
 
-- 
2.7.4

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

[U-Boot] [PATCH v1 19/20] arm: socfpga: Bridge reset now invokes SMC calls to query FPGA config status

[chee . hong . ang]

From: Chee Hong Ang 

Since SSBL is now running in non-secure mode (EL2), do_bridge_reset()
no longer send mailbox commands to SDM directly to query the status
of the FPGA configuration. Now, it invokes SMC service calls to ATF
(running at EL3) to perform the query.

Signed-off-by: Chee Hong Ang 
---
 arch/arm/mach-socfpga/misc_s10.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-socfpga/misc_s10.c b/arch/arm/mach-socfpga/misc_s10.c
index 894753e..2bef4ec 100644
--- a/arch/arm/mach-socfpga/misc_s10.c
+++ b/arch/arm/mach-socfpga/misc_s10.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -154,10 +155,17 @@ void do_bridge_reset(int enable, unsigned int mask)
 {
/* Check FPGA status before bridge enable */
if (enable) {
-   int ret = mbox_get_fpga_config_status(MBOX_RECONFIG_STATUS);
+   u64 arg = 1;
 
-   if (ret && ret != MBOX_CFGSTAT_STATE_CONFIG)
-   ret = mbox_get_fpga_config_status(MBOX_CONFIG_STATUS);
+   /* Send MBOX_RECONFIG_STATUS to SDM */
+   int ret = invoke_smc(INTEL_SIP_SMC_FPGA_CONFIG_ISDONE, NULL, 0,
+NULL, 0);
+
+   if (ret && ret != INTEL_SIP_SMC_FPGA_CONFIG_STATUS_BUSY) {
+   /* Send MBOX_CONFIG_STATUS to SDM */
+   ret = invoke_smc(INTEL_SIP_SMC_FPGA_CONFIG_ISDONE,
+, 1, NULL, 0);
+   }
 
if (ret)
return;
-- 
2.7.4

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

[U-Boot] [PATCH v1 14/20] mmc: dwmmc: socfpga: Secure register access in MMC driver

[chee . hong . ang]

From: Chee Hong Ang 

Allow MMC driver to access System Manager's SDMMC control
register in non-secure mode (EL2).

Signed-off-by: Chee Hong Ang 
---
 drivers/mmc/socfpga_dw_mmc.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/socfpga_dw_mmc.c b/drivers/mmc/socfpga_dw_mmc.c
index 568a3e7..b856a0b 100644
--- a/drivers/mmc/socfpga_dw_mmc.c
+++ b/drivers/mmc/socfpga_dw_mmc.c
@@ -5,6 +5,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -56,10 +57,12 @@ static void socfpga_dwmci_clksel(struct dwmci_host *host)
 
debug("%s: drvsel %d smplsel %d\n", __func__,
  priv->drvsel, priv->smplsel);
-   writel(sdmmc_mask, socfpga_get_sysmgr_addr() + SYSMGR_SDMMC);
+   socfpga_secure_reg_write32(sdmmc_mask, socfpga_get_sysmgr_addr() +
+  SYSMGR_SDMMC);
 
debug("%s: SYSMGR_SDMMCGRP_CTRL_REG = 0x%x\n", __func__,
-   readl(socfpga_get_sysmgr_addr() + SYSMGR_SDMMC));
+ socfpga_secure_reg_read32(socfpga_get_sysmgr_addr() +
+ SYSMGR_SDMMC));
 
/* Enable SDMMC clock */
setbits_le32(socfpga_get_clkmgr_addr() + CLKMGR_PERPLL_EN,
-- 
2.7.4

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

[U-Boot] [PATCH v1 10/20] arm: socfpga: Add secure register access helper functions for SoC 64bits

[chee . hong . ang]

From: Chee Hong Ang 

These secure register access functions allow U-Boot proper running
at EL2 (non-secure) to access System Manager's secure registers
by calling the ATF's PSCI runtime services (EL3/secure). If these
helper functions are called from secure mode (EL3), the helper
function will direct access the secure registers without calling
the ATF's PSCI runtime services.

Signed-off-by: Chee Hong Ang 
---
 arch/arm/mach-socfpga/Makefile |  2 +
 .../mach-socfpga/include/mach/secure_reg_helper.h  | 20 +++
 arch/arm/mach-socfpga/secure_reg_helper.c  | 67 ++
 3 files changed, 89 insertions(+)
 create mode 100644 arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
 create mode 100644 arch/arm/mach-socfpga/secure_reg_helper.c

diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index 3310e92..4b46b65 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -34,6 +34,7 @@ obj-y += mailbox_s10.o
 obj-y  += misc_s10.o
 obj-y  += mmu-arm64_s10.o
 obj-y  += reset_manager_s10.o
+obj-y  += secure_reg_helper.o
 obj-y  += system_manager_s10.o
 obj-y  += timer_s10.o
 obj-y  += wrap_pinmux_config_s10.o
@@ -47,6 +48,7 @@ obj-y += mailbox_s10.o
 obj-y  += misc_s10.o
 obj-y  += mmu-arm64_s10.o
 obj-y  += reset_manager_s10.o
+obj-y  += secure_reg_helper.o
 obj-y  += system_manager_s10.o
 obj-y  += timer_s10.o
 obj-y  += wrap_pinmux_config_s10.o
diff --git a/arch/arm/mach-socfpga/include/mach/secure_reg_helper.h 
b/arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
new file mode 100644
index 000..0dc6534
--- /dev/null
+++ b/arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright (C) 2019 Intel Corporation 
+ *
+ */
+
+#ifndef_SECURE_REG_HELPER_H_
+#define_SECURE_REG_HELPER_H_
+
+#ifdef CONFIG_ARM_SMCCC
+u32 socfpga_secure_reg_read32(phys_addr_t reg_addr);
+void socfpga_secure_reg_write32(u32 val, phys_addr_t reg_addr);
+void socfpga_secure_reg_update32(phys_addr_t reg_addr, u32 mask, u32 val);
+#else
+#define socfpga_secure_reg_read32  readl
+#define socfpga_secure_reg_write32 writel
+#define socfpga_secure_reg_update32clrsetbits_le32
+#endif
+
+#endif /* _SECURE_REG_HELPER_H_ */
diff --git a/arch/arm/mach-socfpga/secure_reg_helper.c 
b/arch/arm/mach-socfpga/secure_reg_helper.c
new file mode 100644
index 000..2968fab
--- /dev/null
+++ b/arch/arm/mach-socfpga/secure_reg_helper.c
@@ -0,0 +1,67 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Intel Corporation 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+u32 socfpga_secure_reg_read32(phys_addr_t reg_addr)
+{
+   int ret;
+   u64 ret_arg;
+   u64 args[1];
+
+   if (current_el() == 3)
+   return readl(reg_addr);
+
+   args[0] = (u64)reg_addr;
+   ret = invoke_smc(INTEL_SIP_SMC_REG_READ, args, 1, _arg, 1);
+   if (ret) {
+   /* SMC call return error */
+   hang();
+   }
+
+   return ret_arg;
+}
+
+void socfpga_secure_reg_write32(u32 val, phys_addr_t reg_addr)
+{
+   int ret;
+   u64 args[2];
+
+   if (current_el() == 3) {
+   writel(val, (u32 *)reg_addr);
+   } else {
+   args[0] = (u64)reg_addr;
+   args[1] = val;
+   ret = invoke_smc(INTEL_SIP_SMC_REG_WRITE, args, 2, NULL, 0);
+   if (ret) {
+   /* SMC call return error */
+   hang();
+   }
+   }
+}
+
+void socfpga_secure_reg_update32(phys_addr_t reg_addr, u32 mask, u32 val)
+{
+   int ret;
+   u64 args[3];
+
+   if (current_el() == 3) {
+   clrsetbits_le32(reg_addr, mask, val);
+   } else {
+   args[0] = (u64)reg_addr;
+   args[1] = mask;
+   args[2] = val;
+   ret = invoke_smc(INTEL_SIP_SMC_REG_UPDATE, args, 3, NULL, 0);
+   if (ret) {
+   /* SMC call return error */
+   hang();
+   }
+   }
+}
-- 
2.7.4

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

[U-Boot] [PATCH v1 12/20] arm: socfpga: Secure register access in PHY mode setup

[chee . hong . ang]

From: Chee Hong Ang 

Allow access to System Manager's EMAC control register from
non-secure mode during PHY mode setup.

Signed-off-by: Chee Hong Ang 
---
 arch/arm/mach-socfpga/misc_s10.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-socfpga/misc_s10.c b/arch/arm/mach-socfpga/misc_s10.c
index 2d63175..894753e 100644
--- a/arch/arm/mach-socfpga/misc_s10.c
+++ b/arch/arm/mach-socfpga/misc_s10.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -65,9 +66,9 @@ static u32 socfpga_phymode_setup(u32 gmac_index, const char 
*phymode)
else
return -EINVAL;
 
-   clrsetbits_le32(socfpga_get_sysmgr_addr() + SYSMGR_SOC64_EMAC0 +
-   gmac_index,
-   SYSMGR_EMACGRP_CTRL_PHYSEL_MASK, modereg);
+   socfpga_secure_reg_update32(socfpga_get_sysmgr_addr() +
+   SYSMGR_SOC64_EMAC0 + gmac_index,
+   SYSMGR_EMACGRP_CTRL_PHYSEL_MASK, modereg);
 
return 0;
 }
-- 
2.7.4

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

[U-Boot] [PATCH v1 13/20] arm: socfpga: Secure register access for reading PLL frequency

[chee . hong . ang]

From: Chee Hong Ang 

Allow reading external oscillator and FPGA clock's frequency from
System Manager's Boot Scratch Register 1 and Boot Scratch Register 2
in non-secure mode (EL2) on SoC 64bits platform.

Signed-off-by: Chee Hong Ang 
---
 arch/arm/mach-socfpga/wrap_pll_config_s10.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-socfpga/wrap_pll_config_s10.c 
b/arch/arm/mach-socfpga/wrap_pll_config_s10.c
index 3da8579..7bd92d0 100644
--- a/arch/arm/mach-socfpga/wrap_pll_config_s10.c
+++ b/arch/arm/mach-socfpga/wrap_pll_config_s10.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 const struct cm_config * const cm_get_default_config(void)
 {
@@ -39,8 +40,8 @@ const unsigned int cm_get_osc_clk_hz(void)
writel(clock,
   socfpga_get_sysmgr_addr() + SYSMGR_SOC64_BOOT_SCRATCH_COLD1);
 #endif
-   return readl(socfpga_get_sysmgr_addr() +
-SYSMGR_SOC64_BOOT_SCRATCH_COLD1);
+   return socfpga_secure_reg_read32(socfpga_get_sysmgr_addr() +
+SYSMGR_SOC64_BOOT_SCRATCH_COLD1);
 }
 
 const unsigned int cm_get_intosc_clk_hz(void)
@@ -56,6 +57,6 @@ const unsigned int cm_get_fpga_clk_hz(void)
writel(clock,
   socfpga_get_sysmgr_addr() + SYSMGR_SOC64_BOOT_SCRATCH_COLD2);
 #endif
-   return readl(socfpga_get_sysmgr_addr() +
-SYSMGR_SOC64_BOOT_SCRATCH_COLD2);
+   return socfpga_secure_reg_read32(socfpga_get_sysmgr_addr() +
+SYSMGR_SOC64_BOOT_SCRATCH_COLD2);
 }
-- 
2.7.4

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

[U-Boot] [PATCH v1 15/20] net: designware: socfpga: Secure register access in MAC driver

[chee . hong . ang]

From: Chee Hong Ang 

Allow MAC driver to access System Manager's EMAC control
registers in non-secure mode.

Signed-off-by: Chee Hong Ang 
---
 drivers/net/dwmac_socfpga.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/dwmac_socfpga.c b/drivers/net/dwmac_socfpga.c
index b7bf5db..ae747ca 100644
--- a/drivers/net/dwmac_socfpga.c
+++ b/drivers/net/dwmac_socfpga.c
@@ -16,6 +16,7 @@
 #include "designware.h"
 
 #include 
+#include 
 
 struct dwmac_socfpga_platdata {
struct dw_eth_pdata dw_eth_pdata;
@@ -96,8 +97,8 @@ static int dwmac_socfpga_probe(struct udevice *dev)
reset_assert_bulk(_bulk);
 
modemask = SYSMGR_EMACGRP_CTRL_PHYSEL_MASK << pdata->reg_shift;
-   clrsetbits_le32(pdata->phy_intf, modemask,
-   modereg << pdata->reg_shift);
+   socfpga_secure_reg_update32((phys_addr_t)pdata->phy_intf, modemask,
+   modereg << pdata->reg_shift);
 
reset_release_bulk(_bulk);
 
-- 
2.7.4

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

[U-Boot] [PATCH v1 07/20] arm: socfpga: Disable "spin-table" method for booting Linux

[chee . hong . ang]

From: Chee Hong Ang 

Standard PSCI function "CPU_ON" provided by ATF is now used
by Linux kernel to bring up the secondary CPUs to enable
SMP booting in Linux on SoC 64bits platform.

Signed-off-by: Chee Hong Ang 
---
 arch/arm/mach-socfpga/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index 969698c..6549033 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -33,7 +33,6 @@ config TARGET_SOCFPGA_AGILEX
bool
select ARMV8_MULTIENTRY
select ARMV8_SET_SMPEN
-   select ARMV8_SPIN_TABLE
select CLK
select NCORE_CACHE
select SPL_CLK if SPL
@@ -77,7 +76,6 @@ config TARGET_SOCFPGA_STRATIX10
bool
select ARMV8_MULTIENTRY
select ARMV8_SET_SMPEN
-   select ARMV8_SPIN_TABLE
select FPGA_STRATIX10
 
 choice
-- 
2.7.4

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

[U-Boot] [PATCH v1 18/20] arm: socfpga: stratix10: Refactor FPGA reconfig driver to support ATF

[chee . hong . ang]

From: Chee Hong Ang 

Refactor the FPGA recpnfiguration driver to call the ATF's PSCI
runtime services as it no longer handles the Secure Device Manager
(SDM) mailbox communication and FPGA reconfiguration logic.

Signed-off-by: Chee Hong Ang 
---
 drivers/fpga/stratix10.c | 261 +++
 1 file changed, 59 insertions(+), 202 deletions(-)

diff --git a/drivers/fpga/stratix10.c b/drivers/fpga/stratix10.c
index d8e3250..44a427d 100644
--- a/drivers/fpga/stratix10.c
+++ b/drivers/fpga/stratix10.c
@@ -2,92 +2,16 @@
 /*
  * Copyright (C) 2018 Intel Corporation 
  */
-
 #include 
 #include 
-#include 
+#include 
+#include 
+
+#define BITSTREAM_CHUNK_SIZE   0x0
 
 #define RECONFIG_STATUS_POLL_RESP_TIMEOUT_MS   6
 #define RECONFIG_STATUS_INTERVAL_DELAY_US  100
-
-static const struct mbox_cfgstat_state {
-   int err_no;
-   const char  *error_name;
-} mbox_cfgstat_state[] = {
-   {MBOX_CFGSTAT_STATE_IDLE, "FPGA in idle mode."},
-   {MBOX_CFGSTAT_STATE_CONFIG, "FPGA in config mode."},
-   {MBOX_CFGSTAT_STATE_FAILACK, "Acknowledgment failed!"},
-   {MBOX_CFGSTAT_STATE_ERROR_INVALID, "Invalid bitstream!"},
-   {MBOX_CFGSTAT_STATE_ERROR_CORRUPT, "Corrupted bitstream!"},
-   {MBOX_CFGSTAT_STATE_ERROR_AUTH, "Authentication failed!"},
-   {MBOX_CFGSTAT_STATE_ERROR_CORE_IO, "I/O error!"},
-   {MBOX_CFGSTAT_STATE_ERROR_HARDWARE, "Hardware error!"},
-   {MBOX_CFGSTAT_STATE_ERROR_FAKE, "Fake error!"},
-   {MBOX_CFGSTAT_STATE_ERROR_BOOT_INFO, "Error in boot info!"},
-   {MBOX_CFGSTAT_STATE_ERROR_QSPI_ERROR, "Error in QSPI!"},
-   {MBOX_RESP_ERROR, "Mailbox general error!"},
-   {-ETIMEDOUT, "I/O timeout error"},
-   {-1, "Unknown error!"}
-};
-
-#define MBOX_CFGSTAT_MAX ARRAY_SIZE(mbox_cfgstat_state)
-
-static const char *mbox_cfgstat_to_str(int err)
-{
-   int i;
-
-   for (i = 0; i < MBOX_CFGSTAT_MAX - 1; i++) {
-   if (mbox_cfgstat_state[i].err_no == err)
-   return mbox_cfgstat_state[i].error_name;
-   }
-
-   return mbox_cfgstat_state[MBOX_CFGSTAT_MAX - 1].error_name;
-}
-
-/*
- * Add the ongoing transaction's command ID into pending list and return
- * the command ID for next transfer.
- */
-static u8 add_transfer(u32 *xfer_pending_list, size_t list_size, u8 id)
-{
-   int i;
-
-   for (i = 0; i < list_size; i++) {
-   if (xfer_pending_list[i])
-   continue;
-   xfer_pending_list[i] = id;
-   debug("ID(%d) added to transaction pending list\n", id);
-   /*
-* Increment command ID for next transaction.
-* Valid command ID (4 bits) is from 1 to 15.
-*/
-   id = (id % 15) + 1;
-   break;
-   }
-
-   return id;
-}
-
-/*
- * Check whether response ID match the command ID in the transfer
- * pending list. If a match is found in the transfer pending list,
- * it clears the transfer pending list and return the matched
- * command ID.
- */
-static int get_and_clr_transfer(u32 *xfer_pending_list, size_t list_size,
-   u8 id)
-{
-   int i;
-
-   for (i = 0; i < list_size; i++) {
-   if (id != xfer_pending_list[i])
-   continue;
-   xfer_pending_list[i] = 0;
-   return id;
-   }
-
-   return 0;
-}
+#define RECONFIG_STATUS_POLL_RETRY_MAX 100
 
 /*
  * Polling the FPGA configuration status.
@@ -99,11 +23,13 @@ static int reconfig_status_polling_resp(void)
unsigned long start = get_timer(0);
 
while (1) {
-   ret = mbox_get_fpga_config_status(MBOX_RECONFIG_STATUS);
+   ret = invoke_smc(INTEL_SIP_SMC_FPGA_CONFIG_ISDONE, NULL, 0,
+NULL, 0);
+
if (!ret)
return 0;   /* configuration success */
 
-   if (ret != MBOX_CFGSTAT_STATE_CONFIG)
+   if (ret != INTEL_SIP_SMC_FPGA_CONFIG_STATUS_BUSY)
return ret;
 
if (get_timer(start) > RECONFIG_STATUS_POLL_RESP_TIMEOUT_MS)
@@ -116,125 +42,59 @@ static int reconfig_status_polling_resp(void)
return -ETIMEDOUT;
 }
 
-static u32 get_resp_hdr(u32 *r_index, u32 *w_index, u32 *resp_count,
-   u32 *resp_buf, u32 buf_size, u32 client_id)
-{
-   u32 buf[MBOX_RESP_BUFFER_SIZE];
-   u32 mbox_hdr;
-   u32 resp_len;
-   u32 hdr_len;
-   u32 i;
-
-   if (*resp_count < buf_size) {
-   u32 rcv_len_max = buf_size - *resp_count;
-
-   if (rcv_len_max > MBOX_RESP_BUFFER_SIZE)
-   rcv_len_max = MBOX_RESP_BUFFER_SIZE;
-   resp_len = mbox_rcv_resp(buf, rcv_len_max);
-
-   for (i = 0; i < resp_len; i++) {
-  

[U-Boot] [PATCH v1 09/20] arm: socfpga: Define SMC function identifiers for PSCI SiP services

[chee . hong . ang]

From: Chee Hong Ang 

This header file defines the Secure Monitor Call (SMC) message
protocol for ATF (BL31) PSCI runtime services. It includes all
the PSCI SiP function identifiers for the secure runtime services
provided by ATF. The secure runtime services include System Manager's
registers access, 2nd phase bitstream FPGA reconfiguration, Remote
System Update (RSU) and etc.

Signed-off-by: Chee Hong Ang 
---
 include/linux/intel-smc.h | 374 ++
 1 file changed, 374 insertions(+)
 create mode 100644 include/linux/intel-smc.h

diff --git a/include/linux/intel-smc.h b/include/linux/intel-smc.h
new file mode 100644
index 000..27710ac
--- /dev/null
+++ b/include/linux/intel-smc.h
@@ -0,0 +1,374 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2017-2018, Intel Corporation
+ */
+
+#ifndef __INTEL_SMC_H
+#define __INTEL_SMC_H
+
+#include 
+#include 
+
+/*
+ * This file defines the Secure Monitor Call (SMC) message protocol used for
+ * service layer driver in normal world (EL1) to communicate with secure
+ * monitor software in Secure Monitor Exception Level 3 (EL3).
+ *
+ * This file is shared with secure firmware (FW) which is out of kernel tree.
+ *
+ * An ARM SMC instruction takes a function identifier and up to 6 64-bit
+ * register values as arguments, and can return up to 4 64-bit register
+ * value. The operation of the secure monitor is determined by the parameter
+ * values passed in through registers.
+
+ * EL1 and EL3 communicates pointer as physical address rather than the
+ * virtual address.
+ */
+
+/*
+ * Functions specified by ARM SMC Calling convention:
+ *
+ * FAST call executes atomic operations, returns when the requested operation
+ * has completed.
+ * STD call starts a operation which can be preempted by a non-secure
+ * interrupt. The call can return before the requested operation has
+ * completed.
+ *
+ * a0..a7 is used as register names in the descriptions below, on arm32
+ * that translates to r0..r7 and on arm64 to w0..w7.
+ */
+
+#define INTEL_SIP_SMC_STD_CALL_VAL(func_num) \
+   ARM_SMCCC_CALL_VAL(ARM_SMCCC_STD_CALL, ARM_SMCCC_SMC_64, \
+   ARM_SMCCC_OWNER_SIP, (func_num))
+
+#define INTEL_SIP_SMC_FAST_CALL_VAL(func_num) \
+   ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_64, \
+   ARM_SMCCC_OWNER_SIP, (func_num))
+
+/*
+ * Return values in INTEL_SIP_SMC_* call
+ *
+ * INTEL_SIP_SMC_RETURN_UNKNOWN_FUNCTION:
+ * Secure monitor software doesn't recognize the request.
+ *
+ * INTEL_SIP_SMC_STATUS_OK:
+ * FPGA configuration completed successfully,
+ * In case of FPGA configuration write operation, it means secure monitor
+ * software can accept the next chunk of FPGA configuration data.
+ *
+ * INTEL_SIP_SMC_FPGA_CONFIG_STATUS_BUSY:
+ * In case of FPGA configuration write operation, it means secure monitor
+ * software is still processing previous data & can't accept the next chunk
+ * of data. Service driver needs to issue
+ * INTEL_SIP_SMC_FPGA_CONFIG_COMPLETED_WRITE call to query the
+ * completed block(s).
+ *
+ * INTEL_SIP_SMC_FPGA_CONFIG_STATUS_ERROR:
+ * There is error during the FPGA configuration process.
+ *
+ * INTEL_SIP_SMC_REG_ERROR:
+ * There is error during a read or write operation of the protected
+ * registers.
+ */
+#define INTEL_SIP_SMC_RETURN_UNKNOWN_FUNCTION  0x
+#define INTEL_SIP_SMC_STATUS_OK0x0
+#define INTEL_SIP_SMC_FPGA_CONFIG_STATUS_BUSY  0x1
+#define INTEL_SIP_SMC_FPGA_CONFIG_STATUS_REJECTED   0x2
+#define INTEL_SIP_SMC_FPGA_CONFIG_STATUS_ERROR 0x4
+#define INTEL_SIP_SMC_REG_ERROR0x5
+#define INTEL_SIP_SMC_RSU_ERROR0x7
+
+/*
+ * Request INTEL_SIP_SMC_FPGA_CONFIG_START
+ *
+ * Sync call used by service driver at EL1 to request the FPGA in EL3 to
+ * be prepare to receive a new configuration.
+ *
+ * Call register usage:
+ * a0: INTEL_SIP_SMC_FPGA_CONFIG_START.
+ * a1: flag for full or partial configuration
+ *0 full reconfiguration.
+ *1 partial reconfiguration.
+ * a2-7: not used.
+ *
+ * Return status:
+ * a0: INTEL_SIP_SMC_STATUS_OK, or INTEL_SIP_SMC_FPGA_CONFIG_STATUS_ERROR.
+ * a1-3: not used.
+ */
+#define INTEL_SIP_SMC_FUNCID_FPGA_CONFIG_START 1
+#define INTEL_SIP_SMC_FPGA_CONFIG_START \
+   INTEL_SIP_SMC_FAST_CALL_VAL(INTEL_SIP_SMC_FUNCID_FPGA_CONFIG_START)
+
+/*
+ * Request INTEL_SIP_SMC_FPGA_CONFIG_WRITE
+ *
+ * Async call used by service driver at EL1 to provide FPGA configuration data
+ * to secure world.
+ *
+ * Call register usage:
+ * a0: INTEL_SIP_SMC_FPGA_CONFIG_WRITE.
+ * a1: 64bit physical address of the configuration data memory block
+ * a2: Size of configuration data block.
+ * a3-7: not used.
+ *
+ * Return status:
+ * a0: INTEL_SIP_SMC_STATUS_OK, INTEL_SIP_SMC_FPGA_CONFIG_STATUS_BUSY or
+ * INTEL_SIP_SMC_FPGA_CONFIG_STATUS_ERROR.
+ * a1: 64bit physical address of 1st completed memory block if any 

[U-Boot] [PATCH v1 17/20] arm: socfpga: stratix10: Initialize timer in SPL

[chee . hong . ang]

From: Chee Hong Ang 

Initialize timer in SPL running in secure mode (EL3)
and skip timer initialization in U-Boot proper running in
non-secure mode (EL2).

Signed-off-by: Chee Hong Ang 
---
 arch/arm/mach-socfpga/timer_s10.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-socfpga/timer_s10.c 
b/arch/arm/mach-socfpga/timer_s10.c
index 5723789..0fa56c3 100644
--- a/arch/arm/mach-socfpga/timer_s10.c
+++ b/arch/arm/mach-socfpga/timer_s10.c
@@ -13,6 +13,7 @@
  */
 int timer_init(void)
 {
+#ifdef CONFIG_SPL_BUILD
int enable = 0x3;   /* timer enable + output signal masked */
int loadval = ~0;
 
@@ -21,6 +22,6 @@ int timer_init(void)
/* enable processor pysical counter */
asm volatile("msr cntp_ctl_el0, %0" : : "r" (enable));
asm volatile("msr cntp_tval_el0, %0" : : "r" (loadval));
-
+#endif
return 0;
 }
-- 
2.7.4

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

[U-Boot] [PATCH v1 16/20] arm: socfpga: Secure register access in Reset Manager driver

[chee . hong . ang]

From: Chee Hong Ang 

Allow socfpga_bridges_reset() function in Reset Manager driver to
access System Manager's register in non-secure mode (EL2).

Signed-off-by: Chee Hong Ang 
---
 arch/arm/mach-socfpga/reset_manager_s10.c | 31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-socfpga/reset_manager_s10.c 
b/arch/arm/mach-socfpga/reset_manager_s10.c
index c743077..d03f121 100644
--- a/arch/arm/mach-socfpga/reset_manager_s10.c
+++ b/arch/arm/mach-socfpga/reset_manager_s10.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -56,34 +57,37 @@ void socfpga_bridges_reset(int enable)
 {
if (enable) {
/* clear idle request to all bridges */
-   setbits_le32(socfpga_get_sysmgr_addr() +
-SYSMGR_SOC64_NOC_IDLEREQ_CLR, ~0);
+   socfpga_secure_reg_update32(socfpga_get_sysmgr_addr() +
+   SYSMGR_SOC64_NOC_IDLEREQ_CLR,
+   ~0, ~0);
 
/* Release all bridges from reset state */
clrbits_le32(socfpga_get_rstmgr_addr() + RSTMGR_SOC64_BRGMODRST,
 ~0);
 
/* Poll until all idleack to 0 */
-   while (readl(socfpga_get_sysmgr_addr() +
-SYSMGR_SOC64_NOC_IDLEACK))
+   while (socfpga_secure_reg_read32(socfpga_get_sysmgr_addr() +
+SYSMGR_SOC64_NOC_IDLEACK))
;
} else {
/* set idle request to all bridges */
-   writel(~0,
-  socfpga_get_sysmgr_addr() +
-  SYSMGR_SOC64_NOC_IDLEREQ_SET);
+   socfpga_secure_reg_write32(~0, socfpga_get_sysmgr_addr() +
+  SYSMGR_SOC64_NOC_IDLEREQ_SET);
 
/* Enable the NOC timeout */
-   writel(1, socfpga_get_sysmgr_addr() + SYSMGR_SOC64_NOC_TIMEOUT);
+   socfpga_secure_reg_write32(1, socfpga_get_sysmgr_addr() +
+  SYSMGR_SOC64_NOC_TIMEOUT);
 
/* Poll until all idleack to 1 */
-   while ((readl(socfpga_get_sysmgr_addr() + 
SYSMGR_SOC64_NOC_IDLEACK) ^
-   (SYSMGR_NOC_H2F_MSK | SYSMGR_NOC_LWH2F_MSK)))
+   while ((socfpga_secure_reg_read32(socfpga_get_sysmgr_addr() +
+  SYSMGR_SOC64_NOC_IDLEACK) ^ (SYSMGR_NOC_H2F_MSK |
+  SYSMGR_NOC_LWH2F_MSK)))
;
 
/* Poll until all idlestatus to 1 */
-   while ((readl(socfpga_get_sysmgr_addr() + 
SYSMGR_SOC64_NOC_IDLESTATUS) ^
-   (SYSMGR_NOC_H2F_MSK | SYSMGR_NOC_LWH2F_MSK)))
+   while ((socfpga_secure_reg_read32(socfpga_get_sysmgr_addr() +
+  SYSMGR_SOC64_NOC_IDLESTATUS) ^ (SYSMGR_NOC_H2F_MSK |
+  SYSMGR_NOC_LWH2F_MSK)))
;
 
/* Reset all bridges (except NOR DDR scheduler & F2S) */
@@ -92,7 +96,8 @@ void socfpga_bridges_reset(int enable)
   RSTMGR_BRGMODRST_FPGA2SOC_MASK));
 
/* Disable NOC timeout */
-   writel(0, socfpga_get_sysmgr_addr() + SYSMGR_SOC64_NOC_TIMEOUT);
+   socfpga_secure_reg_write32(0, socfpga_get_sysmgr_addr() +
+  SYSMGR_SOC64_NOC_TIMEOUT);
}
 }
 
-- 
2.7.4

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

[U-Boot] [PATCH v1 02/20] arm: socfpga: add fit source file for pack itb with ATF

[chee . hong . ang]

From: Chee Hong Ang 

Generate a FIT image for Intel SOCFPGA(64bits) which
include U-boot proper, ATF and DTB for U-boot proper.

Signed-off-by: Chee Hong Ang 
---
 board/altera/soc64/its/fit_spl_atf.its | 51 ++
 1 file changed, 51 insertions(+)
 create mode 100644 board/altera/soc64/its/fit_spl_atf.its

diff --git a/board/altera/soc64/its/fit_spl_atf.its 
b/board/altera/soc64/its/fit_spl_atf.its
new file mode 100644
index 000..bbc6a86
--- /dev/null
+++ b/board/altera/soc64/its/fit_spl_atf.its
@@ -0,0 +1,51 @@
+/*
+ * Copyright (C) 2019 Intel Corporation. All rights reserved
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+/dts-v1/;
+
+/ {
+   description = "FIT image with U-Boot proper, ATF bl31, DTB";
+   #address-cells = <1>;
+
+   images {
+   uboot {
+   description = "U-Boot (64-bit)";
+   data = /incbin/("../../../../u-boot-nodtb.bin");
+   type = "standalone";
+   os = "U-Boot";
+   arch = "arm64";
+   compression = "none";
+   load = <0x0020>;
+   };
+   atf {
+   description = "ARM Trusted Firmware";
+   data = /incbin/("../../../../bl31.bin");
+   type = "firmware";
+   os = "arm-trusted-firmware";
+   arch = "arm64";
+   compression = "none";
+   load = <0x1000>;
+   entry = <0x1000>;
+   };
+
+   fdt {
+   description = "Stratix 10 flat device-tree";
+   data = /incbin/("../../../../u-boot.dtb");
+   type = "flat_dt";
+   compression = "none";
+   };
+   };
+
+   configurations {
+   default = "conf";
+   conf {
+   description = "Intel Stratix 10";
+   firmware = "atf";
+   loadables = "uboot";
+   fdt = "fdt";
+   };
+   };
+};
-- 
2.7.4

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

[U-Boot] [PATCH v1 03/20] arm: socfpga: Add function for checking description from FIT image

[chee . hong . ang]

From: Chee Hong Ang 

Add board_fit_config_name_match() for matching board name with
device tree files in FIT image. This will ensure correct DTB
file is loaded for different board type. Currently, we are not
supporting multiple device tree files in FIT image therefore this
function basically do nothing for now.

Signed-off-by: Chee Hong Ang 
---
 arch/arm/mach-socfpga/board.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/mach-socfpga/board.c b/arch/arm/mach-socfpga/board.c
index 7c8c05c..1830e2c 100644
--- a/arch/arm/mach-socfpga/board.c
+++ b/arch/arm/mach-socfpga/board.c
@@ -86,3 +86,13 @@ int g_dnl_board_usb_cable_connected(void)
return 1;
 }
 #endif
+
+#ifdef CONFIG_SPL_BUILD
+int board_fit_config_name_match(const char *name)
+{
+   /* Just empty function now - can't decide what to choose */
+   debug("%s: %s\n", __func__, name);
+
+   return 0;
+}
+#endif
-- 
2.7.4

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