[U-Boot] [PATCH] soc: ti: k3-navss-ringacc: fix k3_nav_ringacc_ring_reset_dma

[Vignesh Raghavendra]

In case dma_ring_reset_quirk is not set the k3_ringacc_ring_reset_dma will
just exit without ring reset. Fix it, by adding ring reset call in case
dma_ring_reset_quirk is not.

Signed-off-by: Grygorii Strashko 
Signed-off-by: Vignesh Raghavendra 
---
 drivers/soc/ti/k3-navss-ringacc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/ti/k3-navss-ringacc.c 
b/drivers/soc/ti/k3-navss-ringacc.c
index fcb84f7aa49b..64ebc0ba0030 100644
--- a/drivers/soc/ti/k3-navss-ringacc.c
+++ b/drivers/soc/ti/k3-navss-ringacc.c
@@ -366,8 +366,10 @@ void k3_nav_ringacc_ring_reset_dma(struct k3_nav_ring 
*ring, u32 occ)
if (!ring || !(ring->flags & KNAV_RING_FLAG_BUSY))
return;
 
-   if (!ring->parent->dma_ring_reset_quirk)
+   if (!ring->parent->dma_ring_reset_quirk) {
+   k3_nav_ringacc_ring_reset(ring);
return;
+   }
 
if (!occ)
occ = ringacc_readl(>rt->occ);
-- 
2.23.0

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

Re: [U-Boot] [PATCH v1] pci: add DM based mpc85xx driver

[Heiko Schocher]

Hello Z.q. Hou,

Am 29.08.2019 um 10:11 schrieb Z.q. Hou:

Hi Heiko,


-Original Message-
From: Heiko Schocher 
Sent: 2019年7月16日 11:36
To: u-boot@lists.denx.de
Cc: Heiko Schocher ; Alexander Graf ;
Andrew F. Davis ; Xiaowei Bao ; Bin
Meng ; Eugen Hristev
; Heinrich Schuchardt
; Horatiu Vultur ;
Z.q. Hou ; Krzysztof Kozlowski ;
Liviu Dudau ; Marek Vasut
; Mario Six ; Michal Simek
; Neil Armstrong ;
Prabhakar Kushwaha ; Ryder Lee
; Simon Glass ; Stefan
Roese 
Subject: [PATCH v1] pci: add DM based mpc85xx driver

add DM based PCI Configuration space access support for MPC85xx PCI
Bridge


Seems you're converting the arch/powerpc/cpu/mpc85xx/pci.c to driver model,


Yes, should have added this to commit message .. fixed.


but not every mpc85xx platform uses this driver, platforms mpc8536, 8544,
8548 and 8568 use the drivers/pci/fsl_pci_init.c, please take them into account.


Oh, wasn;t aware of this! ... I have no idea why there are 2 drivers and
where are the differences between them, nor I can test all the other
plattforms, so this seems difficult to me.

Do you know, why there are 2 different drivers?

I made this new driver, because I work on DM support for the socrates
board, which is mpc8544 based ... !?

May I rename this driver from pci_mpc85xx.c to pci_mpc85xx_dm.c and it
can be a base for DM support and others, who can test their changes,
can add the other variants?


Note: The platforms using arch/powerpc/cpu/mpc85xx/pci.c set up PCI LAWs in
file arch/powerpc/cpu/mpc8xxx/law.c, while other platforms set up PCI LAWs in
PCI driver. So I think you can move the PCI LAWs set-up into this DM PCI driver
And remove the PCI entries from law.c.


Yes good idea, add this in v2 for this driver.


Signed-off-by: Heiko Schocher 

---
Travis build, see:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftravis
-ci.org%2Fhsdenx%2Fu-boot-test%2Fbuilds%2F558855544data=02%7
C01%7CZhiqiang.Hou%40nxp.com%7C231ac8975b2242ea5bfb08d7099eccc
8%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63698844995746
0734sdata=lQcXtvh5a0G9r%2BFlXnnGQ5VgDYvcR%2FEGWpShJ324su
U%3Dreserved=0

  MAINTAINERS   |   5 ++
  drivers/pci/Kconfig   |   7 ++
  drivers/pci/Makefile  |   1 +
  drivers/pci/pci_mpc85xx.c | 132
++
  4 files changed, 145 insertions(+)
  create mode 100644 drivers/pci/pci_mpc85xx.c

diff --git a/MAINTAINERS b/MAINTAINERS
index e91684191f..01faa67a6d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -639,6 +639,11 @@ S: Maintained
  F:drivers/pci_endpoint/
  F:  include/pci_ep.h

+PCI MPC85xx
+M: Heiko Schocher 
+S: Maintained
+F: drivers/pci/pci_mpc85xx.c
+
  POWER
  M:Jaehoon Chung 
  S:Maintained
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig index
3fe38f7315..88db0067b4 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -68,6 +68,13 @@ config PCIE_FSL
  PowerPC MPC85xx, MPC86xx, B series, P series and T series SoCs.
  This driver does not support SRIO_PCIE_BOOT feature.

+config PCI_MPC85XX
+   bool "MPC85XX PowerPC PCI support"
+   depends on DM_PCI
+   help
+ Say Y here if you want to enable PCI controller support on FSL
+ PowerPC MPC85xx SoC.
+
  config PCI_RCAR_GEN2
bool "Renesas RCar Gen2 PCIe driver"
depends on DM_PCI
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile index
b5ebd50c85..929f119fb3 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_PCIE_ECAM_GENERIC) +=
pcie_ecam_generic.o
  obj-$(CONFIG_FSL_PCI_INIT) += fsl_pci_init.o
  obj-$(CONFIG_PCI_INDIRECT_BRIDGE) += pci_indirect.o
  obj-$(CONFIG_PCI_GT64120) += pci_gt64120.o
+obj-$(CONFIG_PCI_MPC85XX) += pci_mpc85xx.o
  obj-$(CONFIG_PCI_MSC01) += pci_msc01.o
  obj-$(CONFIG_PCIE_IMX) += pcie_imx.o
  obj-$(CONFIG_FTPCI100) += pci_ftpci100.o diff --git
a/drivers/pci/pci_mpc85xx.c b/drivers/pci/pci_mpc85xx.c new file mode
100644 index 00..c0d35f7f2c
--- /dev/null
+++ b/drivers/pci/pci_mpc85xx.c
@@ -0,0 +1,132 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * (C) Copyright 2019
+ * Heiko Schocher, DENX Software Engineering, h...@denx.de.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+
+struct mpc85xx_pci_priv {
+   void __iomem*cfg_addr;
+   void __iomem*cfg_data;
+};
+
+static int mpc85xx_pci_dm_read_config(struct udevice *dev, pci_dev_t bdf,
+ uint offset, ulong *value,
+ enum pci_size_t size)
+{
+   struct mpc85xx_pci_priv *priv = dev_get_priv(dev);
+   u32 addr;
+
+   addr = bdf | (offset & 0xfc) | ((offset & 0xf00) << 16) | 0x8000;
+   out_be32(priv->cfg_addr, addr);
+   sync();
+   *value = pci_conv_32_to_size(in_le32(priv->cfg_data), offset, size);
+
+   return 0;
+}
+
+static int mpc85xx_pci_dm_write_config(struct udevice *dev, pci_dev_t
bdf,
+  uint 

Re: [U-Boot] Pull request for UEFI sub-system for v2019.10-rc4

[Tom Rini]

On Thu, Aug 29, 2019 at 08:14:11AM +0200, Heinrich Schuchardt wrote:

> The following changes since commit e4b8dd9b34021241cd05d5cc9d24b4ae34657830:
> 
>   Merge https://gitlab.denx.de/u-boot/custodians/u-boot-mpc85xx
> (2019-08-27 07:11:37 -0400)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git
> tags/efi-2019-10-rc4
> 
> for you to fetch changes up to 53c701720c3d5e5ae107454ea9b9f680bc399006:
> 
>   efi_selftest: use standalone UEFI program for exception (2019-08-29
> 05:54:26 +0200)
> 
> No errors were reported by Gitlab.
> 
> Primary key fingerprint:
> 6DC4 F9C7 1F29 A6FA 06B7  6D33 C481 DBBC 2C05 1AC4
> 

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/master

[Tom Rini]

On Thu, Aug 29, 2019 at 05:22:58AM +, Prabhakar Kushwaha wrote:

> Dear Tom,
> 
> Please find my pull request for u-boot-mpc85xx/master
> 
> Summary:
> Enable DM PCI for T2080RDB, T4240RDB, T1024RDB, T1042D4RDB, P1020RDB,
> P2020RDB, P2041RDB, P3041DS, P4080DS, and MPC8548CDS
> 
> Travis-CI:  https://travis-ci.org/prabhukush/u-boot/builds/577733313
> 
> --pk (prabhakar: prabhu_kush)
> 

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] Please pull u-boot-amlogic-20190828

[Tom Rini]

On Wed, Aug 28, 2019 at 03:20:00PM +0200, Neil Armstrong wrote:

> Hi Tom,
> 
> This PR simply adds a missing compatible enabling the G12B clock controller.
> 
> The CI jobs passed at 
> https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic/pipelines/568
> 
> Thanks,
> Neil
> 
> The following changes since commit e4b8dd9b34021241cd05d5cc9d24b4ae34657830:
> 
>   Merge https://gitlab.denx.de/u-boot/custodians/u-boot-mpc85xx (2019-08-27 
> 07:11:37 -0400)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic.git 
> tags/u-boot-amlogic-20190828
> 
> for you to fetch changes up to d0e8c4ad513c0df492cc90bdc59f272687e90b32:
> 
>   clk: meson-g12b: add compatible (2019-08-28 10:14:31 +0200)
> 

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 1/2] mmc: Fix timeout values passed to mmc_wait_dat0()

[Peng Fan]

> Subject: Re: [PATCH 1/2] mmc: Fix timeout values passed to mmc_wait_dat0()
> 
> Hi Peng,
> 
> On Tue, Aug 27, 2019 at 10:40 AM Peng Fan  wrote:
> >
> > > Subject: [PATCH 1/2] mmc: Fix timeout values passed to
> > > mmc_wait_dat0()
> > >
> > > mmc_wait_dat0() expects timeout argument to be in usec units. But
> > > some overlying functions operate on timeout in msec units. Convert
> > > timeout from msec to usec when passing it to mmc_wait_dat0().
> > >
> > > This fixes 'avb' commands on BeagleBoard X15, because next chain was
> > > failing:
> > >
> > > get_partition() -> mmc_switch_part() -> __mmc_switch() ->
> > > mmc_wait_dat0()
> > >
> > > when passing incorrect timeout from __mmc_switch() to
> mmc_wait_dat0().
> > >
> > > Fixes: bb98b8c5c06a ("mmc: During a switch, poll on dat0 if
> > > available and check the final status")
> > > Signed-off-by: Sam Protsenko 
> >
> > Applied to mmc/master.
> >
> 
> Thanks for taking care of this. Quick question: does it mean that this patch 
> will
> find its way to v2019.10? Because this patch is a bug fix to me (it actually 
> fixes
> AVB, which doesn't work at all right now).

Yes. It will land in 2019.10, I'll send pull request to Tom later.

Regards,
Peng.

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

Re: [U-Boot] [PATCH v2] imx: support i.MX8QM ROM 7720 a1 board

[Peng Fan]

> Subject: [PATCH v2] imx: support i.MX8QM ROM 7720 a1 board
> 
> Add i.MX8QM ROM 7720a1 board support
> 
> Boot log as below:
> U-Boot 2019.07-1-g6c912ea4d4 (Aug 28 2019 - 13:01:45 +0200)
> 
> CPU:   NXP i.MX8QM RevB A53 at 1200 MHz
> 
> Model: Advantech iMX8QM Qseven series
> Board: ROM-7720-A1 4GB
> Build: SCFW 65afe5f6
> Boot:  SD2
> DRAM:  3.9 GiB
> MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
> Loading Environment from MMC... OK
> In:serial@5a06
> Out:   serial@5a06
> Err:   serial@5a06
> Net:   eth0: ethernet@5b04Could not get PHY for FEC1: addr 1
> , eth-1: ethernet@5b05
> Hit any key to stop autoboot:  0
> 
> Signed-off-by: Oliver Graute 
> Cc: Stefano Babic 
> Cc: Fabio Estevam 
> Cc: Peng Fan 
> Cc: Simon Glass 
> Cc: Ye Li 
> Cc: uboot-imx 
> ---
> 
> These changes are based on this vendor tree:

Please use imx/master or upstream master branch for your development.

Regards,
Peng.

> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.
> com%2FADVANTECH-Corp%2Fuboot-imx6.gitdata=02%7C01%7Cpeng.f
> an%40nxp.com%7C005702a90967449b2a7808d72bb5dc4a%7C686ea1d3bc2
> b4c6fa92cd99c5c301635%7C0%7C0%7C637025932415631263sdata=I
> 9xkcdDOGgrHPZdbhSl6aLTcg%2FTKq7KnOrZALbTbXH0%3Dreserved=0
> 
> I adapted the files and compared them with code from similar imx8qm-mek
> board
> 
> Changes for v2:
>  - cleanup of u-boot environment
>  - set power mode SC_R_DC_0 for full boot of linux kernel
>  - enabled usdhc2
>  - enabled FEC defines
>  - updated README.md
>  - enabled readwrite for nfs rootfs
>  - removed include of environment header
> 
>  arch/arm/dts/Makefile |   1 +
>  arch/arm/dts/imx8qm-rom7720-a1.dts| 373
> ++
>  arch/arm/mach-imx/imx8/Kconfig|   7 +
>  arch/arm/mach-imx/mkimage_fit_atf.sh  |   3 +
>  board/freescale/imx8qm_rom7720_a1/Kconfig |  14 +
>  board/freescale/imx8qm_rom7720_a1/MAINTAINERS |   6 +
>  board/freescale/imx8qm_rom7720_a1/Makefile|  11 +
>  board/freescale/imx8qm_rom7720_a1/README  |  70 
>  .../imx8qm_rom7720_a1/imx8qm_rom7720_a1.c | 181 +
>  .../freescale/imx8qm_rom7720_a1/imximage.cfg  |  21 +
>  board/freescale/imx8qm_rom7720_a1/spl.c   | 228 +++
>  configs/imx8qm_rom7720_a1_4G_defconfig|  82 
>  include/configs/imx8qm_rom7720.h  | 189 +
>  13 files changed, 1186 insertions(+)
>  create mode 100644 arch/arm/dts/imx8qm-rom7720-a1.dts
>  create mode 100644 board/freescale/imx8qm_rom7720_a1/Kconfig
>  create mode 100644 board/freescale/imx8qm_rom7720_a1/MAINTAINERS
>  create mode 100644 board/freescale/imx8qm_rom7720_a1/Makefile
>  create mode 100644 board/freescale/imx8qm_rom7720_a1/README
>  create mode 100644
> board/freescale/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c
>  create mode 100644 board/freescale/imx8qm_rom7720_a1/imximage.cfg
>  create mode 100644 board/freescale/imx8qm_rom7720_a1/spl.c
>  create mode 100644 configs/imx8qm_rom7720_a1_4G_defconfig
>  create mode 100644 include/configs/imx8qm_rom7720.h
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
> 20dbc2ff84..54c1f40085 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -613,6 +613,7 @@ dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb
>  dtb-$(CONFIG_ARCH_IMX8) += \
>   fsl-imx8qm-apalis.dtb \
>   fsl-imx8qm-mek.dtb \
> + imx8qm-rom7720-a1.dtb \
>   fsl-imx8qxp-colibri.dtb \
>   fsl-imx8qxp-mek.dtb
> 
> diff --git a/arch/arm/dts/imx8qm-rom7720-a1.dts
> b/arch/arm/dts/imx8qm-rom7720-a1.dts
> new file mode 100644
> index 00..5f9ac955ed
> --- /dev/null
> +++ b/arch/arm/dts/imx8qm-rom7720-a1.dts
> @@ -0,0 +1,373 @@
> +// SPDX-License-Identifier:  GPL-2.0+
> +/*
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + * Copyright 2017 NXP
> + */
> +
> +/dts-v1/;
> +
> +/* First 128KB is for PSCI ATF. */
> +/memreserve/ 0x8000 0x0002;
> +
> +#include "fsl-imx8qm.dtsi"
> +
> +/ {
> + model = "Advantech iMX8QM Qseven series";
> + compatible = "fsl,imx8qm-mek", "fsl,imx8qm";
> +
> + chosen {
> + bootargs = "console=ttyLP0,115200
> earlycon=lpuart32,0x5a06,115200";
> + stdout-path = 
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <_gpio_leds>;
> + user {
> + label = "heartbeat";
> + gpios = < 15 0>;
> + default-state = "on";
> + linux,default-trigger = "heartbeat";
> + };
> + };
> +
> + regulators {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + reg_usb_otg1_vbus: regulator@0 {
> + compatible = "regulator-fixed";
> + reg = <0>;
> + regulator-name = "usb_otg1_vbus";
> +

Re: [U-Boot] [PATCH] mmc: dw_mmc: fix timeout calculate method

[Kever Yang]

Hi Alexey,


On 2019/8/29 下午5:21, Alexey Brodkin wrote:

Hi Kever,


-Original Message-
From: Kever Yang 
Sent: Thursday, August 29, 2019 10:17 AM
To: Peng Fan ; u-boot@lists.denx.de
Cc: tr...@konsulko.com; eugeniy.palt...@synopsys.com; Alexey Brodkin 
; Simon
Glass 
Subject: Re: [PATCH] mmc: dw_mmc: fix timeout calculate method

Add ARC maintainers.

Thanks for adding us in the loop.


On 2019/8/27 下午5:58, Peng Fan wrote:

Hi Kever,


-Original Message-
From: U-Boot  On Behalf Of Peng Fan
Sent: 2019年8月27日 15:40
To: Kever Yang ; u-boot@lists.denx.de
Cc: tr...@konsulko.com
Subject: Re: [U-Boot] [PATCH] mmc: dw_mmc: fix timeout calculate method


Subject: [PATCH] mmc: dw_mmc: fix timeout calculate method

There are two cases not been considered:
- use uint for timeout, it will overflow when size bigger than 512KB for
it *8*1000 at the beginning, but we may use size up to 32MB;
- The timeout is using clock speed for data rate, but the device may not
have such high speed, eg. clock is 52MHz while the device write speed

may

be less than 10MB/s.

Fix them in this patch, the max timeout is about 6500 when size is
32MB after fix.

Signed-off-by: Kever Yang 

This patch breaks build, I need drop it.
See build:
https://travis-ci.org/MrVan/u-boot/jobs/577210464

The error happens only in ARC architecture, and seems like the arc
compiler not support 64bit div?

It's not a compiler problem but a subtle issue with libgcc.
To be independent from toolchain type (and we have quite a few flavors like
little- and big-endian, ARCv1 or ARCv2 etc) decision was made to move
libgcc into U-Boot but given full libgcc is quite large only primitives required
by up-to-date U-Boot were copied from GCC to U-Boot.


Any idea on how to fix this?

Add missing primitives like __udivdi3() and their dependencies, see for example:
https://github.com/gcc-mirror/gcc/blob/master/libgcc/libgcc2.c#L1318.

And I'll happily do it myself but for some reason I cannot reproduce that 
problem locally.
I use the same pre-built arc-2018.09 toolchain:
>8---
# arc-linux-gcc -v
gcc version 8.2.1 20180814 (ARCv2 ISA Linux uClibc toolchain 2018.09)
>8---

And may successfully build U-Boot for HSDK from
https://github.com/MrVan/u-boot/commits/mmc-8-28-2019:
>8---
# git l
76c0bf2873 - (HEAD -> mrvan, github-mrvan/mmc-8-28-2019) ARM: dts: ast2500: Add SDHCI 
nodes (27 hours ago) 
07b000cd32 - configs: AST2500 EVB: Enable SD controller (27 hours ago) 
5f6a033f10 - mmc: Add Aspeed SD controller driver (27 hours ago) 
a6503eaa66 - clk: aspeed: Add support for SD clock (27 hours ago) 
c54e328452 - mmc: Rename timeout parameters for clarification (27 hours ago) 
be949bb19c - mmc: Fix timeout values passed to mmc_wait_dat0() (27 hours ago) 
49842f0edf - dm: mmc: remove unused U_BOOT_DRIVER(mmc) (27 hours ago) 
7b91b47f8f - Prepare v2019.10-rc3 (27 hours ago) 
>8---


I think this tree does not including this patch, Peng drop it because of 
this issue,

so you need to apply this patch in your branch to reproduce the problem.
I have send out V2 patch for this fix with only using 32bit variable 
instead of 64bit.


Thanks,
- Kever


That way:
>8---
./tools/buildman/buildman hsdk
boards.cfg is up to date. Nothing to do.
Building current source for 1 boards (1 thread, 48 jobs per thread)
arc:  w+   hsdk
 010 /1  hsdk
>8---

What do I do wrong?

-Alexey





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

Re: [U-Boot] [PATCH] Fix unreliable detection of DRAM size on Orange Pi 3

[André Przywara]

On 25/08/2019 15:41, Siarhei Siamashka wrote:
> On Sat, 24 Aug 2019 22:07:43 +0200
> Ondřej Jirman  wrote:

Hi,

>> Hi Jagan,
>>
>> can you please apply this patch to the sunxi tree, so that it
>> doesn't get lost.
>>
>> thank you,
>>  Ondrej
>>
>> On Mon, Jul 29, 2019 at 01:39:42AM +0200, megous hlavni wrote:
>>> From: Ondrej Jirman 
>>>
>>> Orange Pi 3 has 2 GiB of DRAM, that sometime get misdetected
>>> as 4 GiB, due to false negative result from mctl_mem_matches()
>>> when detecting number of column address bits. This leads to
>>> u-boot detecting more address bits than there are and the
>>> boot process hangs shortly after.
>>>
>>> In mctl_mem_matches() we need to wait for each write to finish,
>>> separately. Without this, the check is not reliable for some
>>> unknown reason, probably having to do with unpredictable memory
>>> access ordering.
>>>
>>> Patch was made with help from André Przywara, who noticed that
>>> my original idea about detection failing due to read-back from
>>> cache without involving DRAM was false, because data cache is
>>> still of at the time of the DRAM size autodetection.
>>>
>>> Signed-off-by: Ondrej Jirman 
>>> Cc: André Przywara 
>>> ---
>>>  arch/arm/mach-sunxi/dram_helpers.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm/mach-sunxi/dram_helpers.c 
>>> b/arch/arm/mach-sunxi/dram_helpers.c
>>> index 239ab421a8..6dba448638 100644
>>> --- a/arch/arm/mach-sunxi/dram_helpers.c
>>> +++ b/arch/arm/mach-sunxi/dram_helpers.c
>>> @@ -30,6 +30,7 @@ bool mctl_mem_matches(u32 offset)
>>>  {
>>> /* Try to write different values to RAM at two addresses */
>>> writel(0, CONFIG_SYS_SDRAM_BASE);
>>> +   dsb();
>>> writel(0xaa55aa55, (ulong)CONFIG_SYS_SDRAM_BASE + offset);
>>> dsb();
>>> /* Check if the same value is actually observed when reading back */
>>> -- 
> 
> Hi!
> 
> This looks like resurfacing of the old problem, which did not get a
> complete fix back in 2016:
>https://lists.denx.de/pipermail/u-boot/2016-April/251803.html
> 
> Now the main question is whether the DSB instruction's barrier
> magic is really required here or maybe it's just a timing issue.

I think both:
From the compiler's and the CPU's point of view these two stores look
independent: they don't have any data dependency and go to different
addresses. So both the compiler and the CPU are allowed to reorder these
stores. However, we are after some non-obvious aliasing effect, so in
fact there *is* a dependency between the two stores. So architecturally
this barrier is definitely required, to notify everyone about this
dependency (although I think a dmb(); might be sufficient here).

So for the sake of this patch, we should take it. It is needed and
apparently solves one issue, and I can't see any harm in it.

Regardless of this I was wondering if in this situation (single in-order
core running with MMU and caches off) this is the full story, as the CPU
does not have a good reason to reorder.

> Could you please experiment with this problem a little bit more?
> 
>  1. What if you just move this second DSB instruction after the
> second write and have two of them there? Does this also make
> the problem disappear?

I don't think two dsb()s next to each other will do anything useful. I
would think the second dsb() would just be ignored, as the order is
already preserved and all memory accesses have been completed:
"A DSB is a memory barrier that ensures that memory accesses that occur
before the DSB have completed before the completion of the DSB
instruction." (ARMv8 ARM, section B2.3.5: DSB)
I can't imagine this would introduce any kind of relevant delay, as a
DSB is just a barrier.

>  2. What if you just replace DSB with udelay(1) / udelay(10) /
> udelay(100)? Does this make the problem disappear?>
> 
> I suspect that we may be dealing with some sort of buffering in
> the DRAM controller itself

Indeed it seems perfectly possible that the DDR3 controller buffers and
potentially reorders those two writes.
The canonical solution would to force the write by telling the memory
controller directly, however this is probably not only controller
specific, but also undocumented.

I was wondering whether waiting for the next refresh would help (or for
the period of one refresh cycle), but I guess the DRAM controller could
buffer requests beyond that point.

> and the only reason why DSB helps is
> that it introduces some delay because it's a rather slow
> instruction.

How much delay a DSB instruction introduces, is dependent on many
things, but mostly on the number of outstanding memory requests and the
time it takes them to complete them. So I am not sure we can call it a
"slow instruction" per se.

So to summarise: I think Siarhei has a point in that this is actually
more of a timing issue, but the DSB in there is needed and we should
apply this patch:

Reviewed-by: Andre Przywara 

Cheers,
Andre.

___
U-Boot 

Re: [U-Boot] [PATCH 1/1] x86: efi_loader: Fix invalid address return from efi_alloc()

[Park, Aiden]

Hi Heinrich and Bin,

> -Original Message-
> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Wednesday, August 28, 2019 10:16 PM
> To: Bin Meng ; Park, Aiden 
> Cc: Simon Glass ; u-boot@lists.denx.de; Alexander Graf
> 
> Subject: Re: [PATCH 1/1] x86: efi_loader: Fix invalid address return from
> efi_alloc()
> 
> On 8/29/19 5:36 AM, Bin Meng wrote:
> > +Heinrich,
> >
> > On Wed, Aug 28, 2019 at 2:35 AM Park, Aiden  wrote:
> >>
> >> This issue can be seen on 32bit operation when one of E820_RAM type
> >> entries is greater than 4GB memory space.
> >>
> >> The efi_alloc() finds a free memory in the conventional memory which
> >> is greater than 4GB. But, it does type cast to 32bit address space
> >> and eventually returns invalid address.
> >>
> >> Signed-off-by: Aiden Park 
> >> ---
> >>   arch/x86/lib/e820.c | 22 +-
> >>   1 file changed, 21 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/x86/lib/e820.c b/arch/x86/lib/e820.c index
> >> d6ae2c4e9d..3e93931231 100644
> >> --- a/arch/x86/lib/e820.c
> >> +++ b/arch/x86/lib/e820.c
> >> @@ -41,11 +41,15 @@ void efi_add_known_memory(void)
> >>   {
> >>  struct e820_entry e820[E820MAX];
> >>  unsigned int i, num;
> >> -   u64 start, pages;
> >> +   u64 start, pages, ram_top;
> >>  int type;
> >>
> >>  num = install_e820_map(ARRAY_SIZE(e820), e820);
> >>
> >> +   ram_top = (u64)gd->ram_top & ~EFI_PAGE_MASK;
> >> +   if (!ram_top)
> >
> > So for the logic here to work, gd->ram_top is already zero in 32-bit,
> > right? I was wondering how U-Boot could boot on such target?
> 
> If in 32bit mode RAM addresses up to 2^32-1 are available, gd->ram_top is 0 
> due
> to overflow.
> 
> >
> >> +   ram_top = 0x1ULL;
> 
> In this special case we correct the value to 4GB.
> 
> >> +
> >>  for (i = 0; i < num; ++i) {
> >>  start = e820[i].addr;
> >>  pages = ALIGN(e820[i].size, EFI_PAGE_SIZE) >>
> >> EFI_PAGE_SHIFT; @@ -70,6 +74,22 @@ void efi_add_known_memory(void)
> >>  }
> >>
> >>  efi_add_memory_map(start, pages, type, false);
> >> +
> >> +   if (type == EFI_CONVENTIONAL_MEMORY) {
> >> +   u64 end = start + (pages << EFI_PAGE_SHIFT);
> >> +
> >> +   /* reserve the memory region greater than ram_top 
> >> */
> >> +   if (ram_top < start) {
> >> +   efi_add_memory_map(start, pages,
> >> +  EFI_BOOT_SERVICES_DATA,
> >> +  true);
> >
> > Heinrich, could you please review the changes here?
> 
> These lines are verbatim copies of what we have in 
> lib/efi_loader/efi_memory.c.
> Function wise this is ok.
> 
> But this creates code duplication. Most of what is in this loop and in the 
> loop in
> lib/efi_loader/efi_memory.c (starting at /* Remove partial pages */) could be
> put into a separate common function.
> 
> Aiden, do you want to give a try?
> 
I have a quick question here. Do we really need to override
efi_add_known_memory() in arch/x86/lib/e820.c?
I think the original weak function would be okay for x86 arch as well.

> Best regards
> 
> Heinrich
> 
> >
> >> +   } else if (start < ram_top && ram_top < end) {
> >> +   pages = (end - ram_top) >> EFI_PAGE_SHIFT;
> >> +   efi_add_memory_map(ram_top, pages,
> >> +  EFI_BOOT_SERVICES_DATA,
> >> +  true);
> >> +   }
> >> +   }
> >>  }
> >>   }
> >>   #endif /* CONFIG_IS_ENABLED(EFI_LOADER) */
> >> --
> >
> > Regards,
> > Bin
> >

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

Re: [U-Boot] [PATCH 1/4] x86: Drop weak version board_get_usable_ram_top()

[Park, Aiden]

> -Original Message-
> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Thursday, August 29, 2019 12:27 PM
> To: Bin Meng ; Simon Glass ; Park,
> Aiden ; U-Boot Mailing List 
> Subject: Re: [PATCH 1/4] x86: Drop weak version board_get_usable_ram_top()
> 
> On 8/29/19 11:53 AM, Bin Meng wrote:
> > Every x86 platform provides board_get_usable_ram_top(), hence there is
> > no need to provide a weak version board_get_usable_ram_top(), not to
> > mention there is another weak version board_get_usable_ram_top() in
> > common/board_f.c.
> >
> > Signed-off-by: Bin Meng 
> 
> Reviewed-by: Heinrich Schuchardt 
>

Reviewed-by: Aiden Park 
 
> > ---
> >
> >   arch/x86/lib/init_helpers.c | 6 --
> >   1 file changed, 6 deletions(-)
> >
> > diff --git a/arch/x86/lib/init_helpers.c b/arch/x86/lib/init_helpers.c
> > index 5e19f13..4774a9b 100644
> > --- a/arch/x86/lib/init_helpers.c
> > +++ b/arch/x86/lib/init_helpers.c
> > @@ -10,12 +10,6 @@
> >
> >   DECLARE_GLOBAL_DATA_PTR;
> >
> > -/* Get the top of usable RAM */
> > -__weak ulong board_get_usable_ram_top(ulong total_size) -{
> > -   return gd->ram_size;
> > -}
> > -
> >   int init_cache_f_r(void)
> >   {
> >   #if CONFIG_IS_ENABLED(X86_32BIT_INIT) && !defined(CONFIG_HAVE_FSP)
> > && \
> >

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

Re: [U-Boot] [PATCH] cmd: pxe: Use internal FDT if external one cannot be retrieved

[Stephen Warren]

On 8/29/19 5:20 AM, Anton Leontiev wrote:

2019-08-26 at 18:59, Stephen Warren :

On 8/23/19 8:40 AM, Anton Leontiev wrote:

From: Anton Leontiev 

Original commit c61d94d86035 ("pxe: implement fdtdir extlinux.conf tag")
states, that if FDT file cannot be retrieved then FDT packaged in
firmware should be used.


It's not meant to say that. I believe the part of the description you're
referring to is:

  if no FDT file was loaded, and $fdtaddr is set:
# This indicates an FDT packaged with firmware
use the FDT at $fdtaddr

That wasn't meant to say anything about "if there was an error loading
the FDT file", but rather is meant to mean "if no FDT file was loaded
because extlinux.conf contained no fdt or fdtdir statement". Nothing
there is intended to refer to errors loading a specified FDT file.

...

What specific problem are you trying to solve?


We have a GNU/Linux distribution that use FDTDIR in its extlinux.conf
to support several boards. But some boards have FDT embedded in U-Boot
and it is't present in FDTDIR. In such configuration U-Boot fails to
boot an entry, despite no exact FDT is specified in it. Distribution
itself is designed to work on any board.


I lookead at that referenced commit description in full and the code, 
and I believe what you want is for U-Boot to set fdt_addr to the 
location of the in-RAM DT, and leave fdt_addr_r unset. This will 
indicate to the pxe code that no FDT should be loaded when parsing 
extlinux.conf, but instead to use fdt_addr directly.


Does that work for you, or does it break some other script/use-case on 
this board?

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

Re: [U-Boot] [PATCH 1/4] x86: Drop weak version board_get_usable_ram_top()

[Heinrich Schuchardt]

On 8/29/19 11:53 AM, Bin Meng wrote:

Every x86 platform provides board_get_usable_ram_top(), hence there
is no need to provide a weak version board_get_usable_ram_top(), not
to mention there is another weak version board_get_usable_ram_top()
in common/board_f.c.

Signed-off-by: Bin Meng 


Reviewed-by: Heinrich Schuchardt 


---

  arch/x86/lib/init_helpers.c | 6 --
  1 file changed, 6 deletions(-)

diff --git a/arch/x86/lib/init_helpers.c b/arch/x86/lib/init_helpers.c
index 5e19f13..4774a9b 100644
--- a/arch/x86/lib/init_helpers.c
+++ b/arch/x86/lib/init_helpers.c
@@ -10,12 +10,6 @@

  DECLARE_GLOBAL_DATA_PTR;

-/* Get the top of usable RAM */
-__weak ulong board_get_usable_ram_top(ulong total_size)
-{
-   return gd->ram_size;
-}
-
  int init_cache_f_r(void)
  {
  #if CONFIG_IS_ENABLED(X86_32BIT_INIT) && !defined(CONFIG_HAVE_FSP) && \



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

Re: [U-Boot] [PATCH 1/2] mmc: Fix timeout values passed to mmc_wait_dat0()

[Sam Protsenko]

Hi Peng,

On Tue, Aug 27, 2019 at 10:40 AM Peng Fan  wrote:
>
> > Subject: [PATCH 1/2] mmc: Fix timeout values passed to mmc_wait_dat0()
> >
> > mmc_wait_dat0() expects timeout argument to be in usec units. But some
> > overlying functions operate on timeout in msec units. Convert timeout from
> > msec to usec when passing it to mmc_wait_dat0().
> >
> > This fixes 'avb' commands on BeagleBoard X15, because next chain was
> > failing:
> >
> > get_partition() -> mmc_switch_part() -> __mmc_switch() ->
> > mmc_wait_dat0()
> >
> > when passing incorrect timeout from __mmc_switch() to mmc_wait_dat0().
> >
> > Fixes: bb98b8c5c06a ("mmc: During a switch, poll on dat0 if available and
> > check the final status")
> > Signed-off-by: Sam Protsenko 
>
> Applied to mmc/master.
>

Thanks for taking care of this. Quick question: does it mean that this
patch will find its way to v2019.10? Because this patch is a bug fix
to me (it actually fixes AVB, which doesn't work at all right now).

Thanks!

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

Re: [U-Boot] USB port doesn't work on the Olimex A64 OLinuXino board

[Juan Francisco Cantero Hurtado]

On 28/8/19 1:25, Jagan Teki wrote:

On Wed, Aug 28, 2019 at 4:05 AM Juan Francisco Cantero Hurtado
 wrote:


Hi, I'm trying to build an u-boot image for the Olimex A64 board.
Everything builds fine (ATF and u-boot) but when I boot the board with
the image, the USB port doesn't receive power. I've an USB meter
connected and it never receives power. I've tried with HEAD, 2019.10-rc3
and 2019.07. Nothing works.


Is board not booting because of unpower or USB not receiving anything
in U-Boot proper? would be please elaborate and paste the log if any?


The problem is only with the USB port. I'm using an USB power meter to 
discard a problem in the communication with the USB devices. It has a 
LED which only requires GND and +5V to work. So, the firmware is not 
enabling the USB ports. U-boot boots fine but the USB doesn't even 
receive power.


Armbian is using 2018.05 and with their version of u-boot, the USB works 
fine. IIRC, a year ago I was using the same version of u-boot with 
OpenBSD and an USB HDD connected without problems.


Log of HEAD:

U-Boot SPL 2019.10-rc3-ge4b8dd9b (Aug 27 2019 - 23:50:49 +0200)

DRAM: 1024 MiB

Trying to boot from MMC1

NOTICE:  BL31: v2.1(release):44e8d5e

NOTICE:  BL31: Built : 23:43:55, Aug 27 2019

NOTICE:  BL31: Detected Allwinner A64/H64/R18 SoC (1689)

NOTICE:  BL31: Found U-Boot DTB at 0x408af58, model: Olimex A64-Olinuxino

NOTICE:  BL31: PMIC: Detected AXP803 on RSB.





U-Boot 2019.10-rc3-ge4b8dd9b (Aug 27 2019 - 23:50:49 +0200) Allwinner 
Technology




CPU:   Allwinner A64 (SUN50I)

Model: Olimex A64-Olinuxino

DRAM:  1 GiB

MMC:   mmc@1c0f000: 0, mmc@1c1: 1

Loading Environment from FAT... Card did not respond to voltage select!

In:serial

Out:   serial

Err:   serial

Net:   phy interface7

eth0: ethernet@1c3

starting USB...

Bus usb@1c1a000: USB EHCI 1.00

Bus usb@1c1a400: USB OHCI 1.0

Bus usb@1c1b000: USB EHCI 1.00

Bus usb@1c1b400: USB OHCI 1.0

scanning bus usb@1c1a000 for devices... 1 USB Device(s) found

scanning bus usb@1c1a400 for devices... 1 USB Device(s) found

scanning bus usb@1c1b000 for devices... 1 USB Device(s) found

scanning bus usb@1c1b400 for devices... 1 USB Device(s) found

   scanning usb for storage devices... 0 Storage Device(s) found

Hit any key to stop autoboot:  0
=> usb tree

USB device tree:

  1  Hub (480 Mb/s, 0mA)

 u-boot EHCI Host Controller



  1  Hub (12 Mb/s, 0mA)

  U-Boot Root Hub



  1  Hub (480 Mb/s, 0mA)

 u-boot EHCI Host Controller



  1  Hub (12 Mb/s, 0mA)

  U-Boot Root Hub



=>

Log of Armbian with this version of u-boot:

https://apt.armbian.com/pool/main/l/linux-u-boot-olinuxino-a64-next/

U-boot complains because there is not a partition on the SD card but the 
USB receives power.


U-Boot SPL 2018.05-armbian (Sep 19 2018 - 13:36:09 +0200)

DRAM: 1024 MiB

Trying to boot from MMC1

NOTICE:  BL3-1: Running on A64/H64 (1689) in SRAM A2 (@0x44000)

NOTICE:  Configuring SPC Controller

NOTICE:  BL3-1: v1.0(debug):c9f55c0

NOTICE:  BL3-1: Built : 13:36:02, Sep 19 2018

NOTICE:  DT: sun50i-a64-olinuxino

INFO:Configuring AXP PMIC

INFO:PMIC: DRAM voltage: 1.36V

INFO:PMIC: setup successful

NOTICE:  SCPI: dummy stub handler, implementation level: 00

INFO:BL3-1: Initializing runtime services

INFO:BL3-1: Preparing for EL3 exit to normal world

INFO:BL3-1: Next image address: 0x4a00, SPSR: 0x3c9





U-Boot 2018.05-armbian (Sep 19 2018 - 13:36:09 +0200) Allwinner Technology



CPU:   Allwinner A64 (SUN50I)

Model: Olimex A64-Olinuxino

DRAM:  1 GiB

MMC:   SUNXI SD/MMC: 0, SUNXI SD/MMC: 1

Loading Environment from EXT4...

** Unable to use mmc 0:auto for loading the env **

Failed (-5)

In:serial

Out:   serial

Err:   serial

Net:   No ethernet found.

** Unrecognized filesystem type **

** Unrecognized filesystem type **

starting USB...

No controllers found

Autoboot in 1 seconds, press  to stop

switch to partitions #0, OK

mmc0 is current device

** No partition table - mmc 0 **

switch to partitions #0, OK

mmc1(part 0) is current device

** No partition table - mmc 1 **
starting USB...

No controllers found

USB is stopped. Please issue 'usb start' first.

starting USB...

No controllers found

No ethernet found.

missing environment variable: pxeuuid

missing environment variable: bootfile

Retrieving file: pxelinux.cfg/

No ethernet found.

missing environment variable: bootfile

Retrieving file: pxelinux.cfg/000

No ethernet found.

missing environment variable: bootfile

Retrieving file: pxelinux.cfg/00

No ethernet found.

missing environment variable: bootfile

Retrieving file: pxelinux.cfg/0

No ethernet found.

missing environment variable: bootfile

Retrieving file: pxelinux.cfg/

No ethernet found.

missing environment variable: bootfile

Retrieving file: pxelinux.cfg/000

No ethernet found.

missing environment variable: bootfile

Retrieving file: pxelinux.cfg/00

No ethernet found.

missing 

[U-Boot] [PATCH] scrapyard: Delete this file and script

[Tom Rini]

The README.scrapyard file has been inconsistently updated.  While well
intentioned, bad data is worse than no data, and in this case a pointer
to use the history that git provides.  Remove the current content and
the script that would update it from time to time as well.

Signed-off-by: Tom Rini 
---
 doc/README.scrapyard  | 354 +-
 scripts/fill_scrapyard.py | 165 -
 2 files changed, 2 insertions(+), 517 deletions(-)
 delete mode 100755 scripts/fill_scrapyard.py

diff --git a/doc/README.scrapyard b/doc/README.scrapyard
index fc0873431aa4..7c239c1dadb8 100644
--- a/doc/README.scrapyard
+++ b/doc/README.scrapyard
@@ -4,355 +4,5 @@ negligence in combination with ordinary bitrot.  Sometimes 
this goes
 by unnoticed, but often build errors will result.  If nobody cares any
 more to resolve such problems, then the code is really dead and will
 be removed from the U-Boot source tree.  The remainders rest in peace
-in the imperishable depths of the git history.  This document tries to
-maintain a list of such former fellows, so archaeologists can check
-easily if there is something they might want to dig for...
-The list should be sorted in reverse chronological order.
-
-
-BoardArchCPUCommit  Removed Last known 
maintainer/contact
-=
-ocotea   powerpc ppc4xx 29155e732015-10-27  Stefan 
Roese 
-taishan  powerpc ppc4xx bb5553c62015-10-27  Stefan 
Roese 
-ebonypowerpc ppc4xx 9d9e2f5d2015-10-27  Stefan 
Roese 
-taihupowerpc ppc4xx 123b6cd72015-10-27  John Otken 

-lcd4_lwmon5  powerpc ppc4xx b6b5e3942015-10-02  Stefan 
Roese 
-da830evm arm arm926ejs  d7e8b2b92015-09-12  Nick 
Thompson 
-wireless_space   arm arm926ejs  b352182a2015-09-12  Albert 
ARIBAUD 
-stxgp3   powerpc mpc85xx2ec69b882015-09-02  Dan Malek 

-stxssa   powerpc mpc85xx2ec69b882015-09-02  Dan Malek 

-cmi_mpc5xx   powerpc mpc5xx 972f53202015-09-02
-zeus powerpc ppc4xx eb5d1dc72015-09-02  Stefan 
Roese 
-sbc405   powerpc ppc4xx 0e0305932015-09-02
-pcs440ep powerpc ppc4xx 242836a82015-09-02  Stefan 
Roese 
-p3p440   powerpc ppc4xx c6999e5f2015-09-02  Stefan 
Roese 
-csb272/csb472powerpc ppc4xx 54a3f2602015-09-02  Tolunay 
Orkun 
-alpr powerpc ppc4xx 0d2fc8112015-09-02  Stefan 
Roese 
-balloon3 arm pxa679d44562015-08-30  Marek 
Vasut 
-cpu9260_128M arm arm926ejs  af7f884b2015-08-30  Eric 
Benard 
-cpu9260  arm arm926ejs  af7f884b2015-08-30  Eric 
Benard 
-cpu9260_nand_128M armarm926ejs  af7f884b2015-08-30  Eric 
Benard 
-cpu9260_nand arm arm926ejs  af7f884b2015-08-30  Eric 
Benard 
-cpu9G20_128M arm arm926ejs  af7f884b2015-08-30  Eric 
Benard 
-cpu9G20  arm arm926ejs  af7f884b2015-08-30  Eric 
Benard 
-cpuat91  arm arm920taf7f884b2015-08-30  Eric 
Benard 
-cpuat91_ram  arm arm920taf7f884b2015-08-30  Eric 
Benard 
-davinci_dm355evm arm arm926ejs  6761946f2015-08-30
-davinci_dm355leopard arm arm926ejs  6761946f2015-08-30
-davinci_dm365evm arm arm926ejs  6761946f2015-08-30
-davinci_dm6467evm armarm926ejs  6761946f2015-08-30
-davinci_dm6467Tevm arm   arm926ejs  6761946f2015-08-30
-davinci_dvevmarm arm926ejs  6761946f2015-08-30
-davinci_schmoogie armarm926ejs  6761946f2015-08-30
-davinci_sffsdr   arm arm926ejs  6761946f2015-08-30
-davinci_sonata   arm arm926ejs  6761946f2015-08-30
-dig297   arm armv7  5ff33d042015-08-30  Luca 
Ceresoli 
-ea20 arm arm926ejs  6761946f2015-08-30
-eb_cpux9k2   arm arm920t5522f12b2015-08-30  Jens 
Scharsig 
-eb_cpux9k2_ram   arm arm920t5522f12b2015-08-30  Jens 
Scharsig 
-enbw_cmc arm arm926ejs  a6f7f7872015-08-30  Heiko 
Schocher 
-ima3-mx53arm armv7  3eb8f58d2015-08-30
-imx27litearm arm926ejs  bc0840bc2015-08-30  Wolfgang 
Denk 
-imx31_litekitarm arm113636d141782015-08-30
-jornada  arm sa1100 df0b116d2015-08-30  Kristoffer 
Ericson 
-lp8x4x   arm pxa9f840b8d2015-08-30  Sergey 
Yanovich 
-magnesiumarm arm926ejs  bc0840bc2015-08-30  

[U-Boot] [PATCH] genboardscfg.py: Convert to Python 3

[Tom Rini]

Convert this tool to requiring Python 3.  The bulk of this is done with
the 2to3 tool and finally we need to use the '//' operator to have our
division result return an int rather than a float.

Cc: Masahiro Yamada 
Signed-off-by: Tom Rini 
---
 tools/genboardscfg.py | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/tools/genboardscfg.py b/tools/genboardscfg.py
index e9bbd15e15a9..8db5483e29bd 100755
--- a/tools/genboardscfg.py
+++ b/tools/genboardscfg.py
@@ -1,4 +1,4 @@
-#!/usr/bin/env python2
+#!/usr/bin/env python3
 # SPDX-License-Identifier: GPL-2.0+
 #
 # Author: Masahiro Yamada 
@@ -168,7 +168,7 @@ class KconfigScanner:
 warnings = self._conf.load_config(self._tmpfile)
 if warnings:
 for warning in warnings:
-print '%s: %s' % (defconfig, warning)
+print('%s: %s' % (defconfig, warning))
 
 try_remove(self._tmpfile)
 self._tmpfile = None
@@ -177,7 +177,7 @@ class KconfigScanner:
 
 # Get the value of CONFIG_SYS_ARCH, CONFIG_SYS_CPU, ... etc.
 # Set '-' if the value is empty.
-for key, symbol in self._SYMBOL_TABLE.items():
+for key, symbol in list(self._SYMBOL_TABLE.items()):
 value = self._conf.get_symbol(symbol).get_value()
 if value:
 params[key] = value
@@ -242,8 +242,8 @@ def scan_defconfigs(jobs=1):
 processes = []
 queues = []
 for i in range(jobs):
-defconfigs = all_defconfigs[total_boards * i / jobs :
-total_boards * (i + 1) / jobs]
+defconfigs = all_defconfigs[total_boards * i // jobs :
+total_boards * (i + 1) // jobs]
 q = multiprocessing.Queue(maxsize=-1)
 p = multiprocessing.Process(target=scan_defconfigs_for_multiprocess,
 args=(q, defconfigs))
@@ -290,7 +290,7 @@ class MaintainersDatabase:
   'Active', 'Orphan' or '-'.
 """
 if not target in self.database:
-print >> sys.stderr, "WARNING: no status info for '%s'" % target
+print("WARNING: no status info for '%s'" % target, file=sys.stderr)
 return '-'
 
 tmp = self.database[target][0]
@@ -301,8 +301,8 @@ class MaintainersDatabase:
 elif tmp.startswith('Orphan'):
 return 'Orphan'
 else:
-print >> sys.stderr, ("WARNING: %s: unknown status for '%s'" %
-  (tmp, target))
+print(("WARNING: %s: unknown status for '%s'" %
+  (tmp, target)), file=sys.stderr)
 return '-'
 
 def get_maintainers(self, target):
@@ -313,7 +313,7 @@ class MaintainersDatabase:
   they are separated with colons.
 """
 if not target in self.database:
-print >> sys.stderr, "WARNING: no maintainers for '%s'" % target
+print("WARNING: no maintainers for '%s'" % target, file=sys.stderr)
 return ''
 
 return ':'.join(self.database[target][1])
@@ -418,7 +418,7 @@ def gen_boards_cfg(output, jobs=1, force=False):
 check_top_directory()
 
 if not force and output_is_new(output):
-print "%s is up to date. Nothing to do." % output
+print("%s is up to date. Nothing to do." % output)
 sys.exit(0)
 
 params_list = scan_defconfigs(jobs)
-- 
2.7.4

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

Re: [U-Boot] [PATCH v5 0/7] usb: Add cadence USB3 gadget/host/phy driver

[Vignesh Raghavendra]

Hi,

On 28/08/19 7:52 PM, Sherry Sun wrote:
> Hi Vignesh,
[...]
>> I see that Cadence USB driver for Linux kernel is still under development and
>> DT compatible binding is supposed to be "cdns,usb3" not "cdns,usb3-1.0.0".
>> See v11:
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
>> work.kernel.org%2Fpatch%2F4415%2Fdata=02%7C01%7Csherry.s
>> un%40nxp.com%7C97d431d6b569451ff8ac08d72bb5f883%7C686ea1d3bc2b
>> 4c6fa92cd99c5c301635%7C0%7C0%7C637025932942549390sdata=Jltlk
>> Te7SXTAQAKtF7HzOqY291upS67Eixeke9oXQ2w%3Dreserved=0
>> Deviating from kernel binding will break sync'ing of DTs b/w kernel and U-
>> Boot.
>>
> 
> Thanks for your reminder, I only noticed the DT compatible in v5 last time. 
> So I will change it to "cdns,usb3" in next version.
> 
>> Also, why not sync the latest host/gadget driver patches from kernel as is?
>> That should help in borrowing bug fixes/features whenever Cadence updates
>> kernel driver in future.
> 
> Since there are many differences between the cdns3 driver in uboot and 
> kernel, 
> such as in uboot, we didn't support host mode in cdns3 core.c, instead we add 
> an 
> xhci-imx8 driver as host driver. So the patches from kernel can't be applied  
> to this driver.
> 

I see that xhci-imx8.c is generic enough to be used with v11 upstream
cdns3/core.c and cdns3/host.c once IMX specific stuff is moved to top
level wrapper.

I see you use a separate compatible for host driver which does not match
with kernel (as there is no separate node for host vs device). Moreover
the dt bindings listed in patch 1/7 lists non core registers as part of
Cadence USB3 controller node.

Above issues make it impossible to sync Kernel DT nodes with U-Boot DT
nodes which is not acceptable for U-Boot. All non Cadence core registers
and configurations need to part of a separate wrapper driver that then
binds to  appropriate host/device Cadence USB3 controller node based on
dr_mode property. E.g: see who dwc3 is modeled [3]:
Also see cdns-ti.c in the TI U-Boot branch [1] [2])

If there are more customization required for host driver cdns3/host.c we
can provide vendor specific hooks/callbacks to be called from cdns3/host.c
Current series is not usable on TI platform with Cadence USB3 IP at
least in host mode and would need core host driver to be ported from kernel.

Keeping Linux kernel and U-Boot driver stack in sync has a big advantage
for you as well. It simplifies borrowing bug fixes and new features or
functions (especially in subsystems like USB where code is pretty large)

BTW, I have a tree with v10  of Cadence USB3 kernel driver ported to
U-Boot here[1]. It is based on 2019.01 U-Boot but should apply as is on
the latest tree as well. (Tree is still missing USB3 PHY support and
thus USB 3.0 support) and works on TI platform. I am waiting for
bindings to be frozen in Linux before posting to U-Boot list.

Hopefully we can find a way to collaborate!

[1] git://git.ti.com/~vigneshr/ti-u-boot/vigneshr-ti-u-boot.git
branch: dfu
[2]
http://git.ti.com/cgit/cgit.cgi/~vigneshr/ti-u-boot/vigneshr-ti-u-boot.git/tree/arch/arm/dts/k3-j721e-main.dtsi?h=dfu#n430
[3]
https://elixir.bootlin.com/u-boot/latest/source/drivers/usb/dwc3/dwc3-generic.c



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

Re: [U-Boot] [PATCH v4 1/1] board: arm: Add support for Broadcom BCM7445

[Bin Meng]

+Simon

On Thu, Aug 29, 2019 at 1:24 AM Thomas Fitzsimmons  wrote:
>
> Hi Bin,
>
> Bin Meng  writes:
>
> > Hi Thomas,
> >
> > On Wed, Aug 28, 2019 at 6:31 AM Thomas Fitzsimmons  
> > wrote:
> >>
> >> Hi Bin,
> >>
> >> Bin Meng  writes:
> >>
> >> > Hi Thomas,
> >> >
> >> > On Sat, Jun 9, 2018 at 6:06 AM Thomas Fitzsimmons  
> >> > wrote:
> >> >>
> >> >> Add support for loading U-Boot on the Broadcom 7445 SoC.  This port
> >> >> assumes Broadcom's BOLT bootloader is acting as the second stage
> >> >> bootloader, and U-Boot is acting as the third stage bootloader, loaded
> >> >> as an ELF program by BOLT.
> >> >>
> >> >> Signed-off-by: Thomas Fitzsimmons 
> >> >> Cc: Stefan Roese 
> >> >> Cc: Tom Rini 
> >> >> Cc: Florian Fainelli 
> >> >> ---
> >> >> Changes for v4:
> >> >>- Use high timer register for get_ticks
> >> >>- Move hard-coded register addresses from Kconfig to header
> >> >>- Document I-cache/D-cache expectation
> >> >>
> >> >>  MAINTAINERS |  10 +
> >> >>  arch/arm/Kconfig|  12 +
> >> >>  arch/arm/Makefile   |   1 +
> >> >>  arch/arm/mach-bcmstb/Kconfig|  36 ++
> >> >>  arch/arm/mach-bcmstb/Makefile   |   8 +
> >> >>  arch/arm/mach-bcmstb/include/mach/gpio.h|  11 +
> >> >>  arch/arm/mach-bcmstb/include/mach/hardware.h|  11 +
> >> >>  arch/arm/mach-bcmstb/include/mach/prior_stage.h |  30 ++
> >> >>  arch/arm/mach-bcmstb/include/mach/sdhci.h   |  15 +
> >> >>  arch/arm/mach-bcmstb/include/mach/timer.h   |  13 +
> >> >>  arch/arm/mach-bcmstb/lowlevel_init.S|  21 ++
> >> >>  board/broadcom/bcmstb/MAINTAINERS   |   7 +
> >> >>  board/broadcom/bcmstb/Makefile  |   8 +
> >> >>  board/broadcom/bcmstb/bcmstb.c  | 194 +++
> >> >>  configs/bcm7445_defconfig   |  27 ++
> >> >>  doc/README.bcm7xxx  | 150 
> >> >>  drivers/mmc/Kconfig |  11 +
> >> >>  drivers/mmc/Makefile|   1 +
> >> >>  drivers/mmc/bcmstb_sdhci.c  |  67 
> >> >>  drivers/spi/Kconfig |   7 +
> >> >>  drivers/spi/Makefile|   1 +
> >> >>  drivers/spi/bcmstb_spi.c| 439 
> >> >> 
> >> >>  drivers/spi/spi-uclass.c|   2 +-
> >> >>  dts/Kconfig |   7 +
> >> >>  include/configs/bcm7445.h   |  26 ++
> >> >>  include/configs/bcmstb.h| 183 ++
> >> >>  include/fdtdec.h|   4 +
> >> >>  lib/fdtdec.c|   4 +
> >> >>  28 files changed, 1305 insertions(+), 1 deletion(-)
> >> >>  create mode 100644 arch/arm/mach-bcmstb/Kconfig
> >> >>  create mode 100644 arch/arm/mach-bcmstb/Makefile
> >> >>  create mode 100644 arch/arm/mach-bcmstb/include/mach/gpio.h
> >> >>  create mode 100644 arch/arm/mach-bcmstb/include/mach/hardware.h
> >> >>  create mode 100644 arch/arm/mach-bcmstb/include/mach/prior_stage.h
> >> >>  create mode 100644 arch/arm/mach-bcmstb/include/mach/sdhci.h
> >> >>  create mode 100644 arch/arm/mach-bcmstb/include/mach/timer.h
> >> >>  create mode 100644 arch/arm/mach-bcmstb/lowlevel_init.S
> >> >>  create mode 100644 board/broadcom/bcmstb/MAINTAINERS
> >> >>  create mode 100644 board/broadcom/bcmstb/Makefile
> >> >>  create mode 100644 board/broadcom/bcmstb/bcmstb.c
> >> >>  create mode 100644 configs/bcm7445_defconfig
> >> >>  create mode 100644 doc/README.bcm7xxx
> >> >>  create mode 100644 drivers/mmc/bcmstb_sdhci.c
> >> >>  create mode 100644 drivers/spi/bcmstb_spi.c
> >> >>  create mode 100644 include/configs/bcm7445.h
> >> >>  create mode 100644 include/configs/bcmstb.h
> >> >>
> >> >
> >> > [snip]
> >> >
> >> >> diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
> >> >> index d2d091f..c517d06 100644
> >> >> --- a/drivers/spi/spi-uclass.c
> >> >> +++ b/drivers/spi/spi-uclass.c
> >> >> @@ -273,7 +273,7 @@ int spi_get_bus_and_cs(int busnum, int cs, int 
> >> >> speed, int mode,
> >> >> bool created = false;
> >> >> int ret;
> >> >>
> >> >> -#if CONFIG_IS_ENABLED(OF_PLATDATA)
> >> >> +#if CONFIG_IS_ENABLED(OF_PLATDATA) || CONFIG_IS_ENABLED(OF_PRIOR_STAGE)
> >> >
> >> > Could you please explain this change a little bit? Why should we call
> >> > uclass_first_device_err() for OF_PRIOR_STAGE?
> >> >
> >> >> ret = uclass_first_device_err(UCLASS_SPI, );
> >> >>  #else
> >> >> ret = uclass_get_device_by_seq(UCLASS_SPI, busnum, );
> >>
> >> On the BCM7445 eval board, the prior-stage-provided device tree does not
> >> have an alias for spi0, though it has aliases for other device types; I
> >> don't know why this is the case, but I don't have control over what the
> >> prior 

Re: [U-Boot] (no subject)

[Fabio Estevam]

Hi Thomas,

On Thu, Aug 29, 2019 at 12:12 PM Thomas Schaefer
 wrote:

> does this mean that these dts files are directly imported from linux tree 
> without
> modification?

Yes, this is our goal.

> I have cloned 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git . Is
> this the right repository to use for the patch?

Yes, you can generate your patch against this tree.

> I found you and Shawn Guo in the imx maintainers list (among others). Should 
> I send the
> patch directly to you, and also to linux-arm-ker...@lists.infradead.org list?

Please send it via git send-email to all i.MX kernel folks and the
linux-arm-kernel list.

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

Re: [U-Boot] (no subject)

[Thomas Schaefer]

Hi Fabio,

> Hi Thomas,
> 
> On Thu, Aug 29, 2019 at 10:40 AM Thomas Schaefer 
>  wrote:
> 
> >  arch/arm/dts/imx7d.dtsi | 2 +-
> >  arch/arm/dts/imx7s.dtsi | 4 ++--
> >  2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/dts/imx7d.dtsi b/arch/arm/dts/imx7d.dtsi index 
> > 30b058934b..2c33aa876f 100644
> > --- a/arch/arm/dts/imx7d.dtsi
> > +++ b/arch/arm/dts/imx7d.dtsi
> > @@ -101,7 +101,7 @@
> >   {
> > usbotg2: usb@30b2 {
> > compatible = "fsl,imx7d-usb", "fsl,imx27-usb";
> > -   reg = <0x30b2 0x200>;
> > +   reg = <0x30b2 0x1>;
> 
> Yes, I have just checked the reference manual and 0x1 size is correct.
> 
> Could you please send a patch to fix it in the kernel dts?
> 
> Then, after it gets fixed in the kernel we can simply import it to U-Boot.
> 
> Thanks

does this mean that these dts files are directly imported from linux tree 
without
modification?

I have cloned 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git . Is
this the right repository to use for the patch?

I found you and Shawn Guo in the imx maintainers list (among others). Should I 
send the
patch directly to you, and also to linux-arm-ker...@lists.infradead.org list?

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

[U-Boot] [PATCH v1] usb: Guarantee alignment of the string descriptor

[Andy Shevchenko]

GCC 9.x starts complaining about potential misalignment of the pointer to the
array (in this case alignment=2) in the packed (alignment=1) structures.

drivers/usb/gadget/composite.c:545:23: warning: taking address of packed member 
of ‘struct usb_string_descriptor’ may result in an unaligned pointer value 
[-Waddress-of-packed-member]
  545 |collect_langs(sp, s->wData);

drivers/usb/gadget/composite.c:550:24: warning: taking address of packed member 
of ‘struct usb_string_descriptor’ may result in an unaligned pointer value 
[-Waddress-of-packed-member]
  550 | collect_langs(sp, s->wData);

drivers/usb/gadget/composite.c:555:25: warning: taking address of packed member 
of ‘struct usb_string_descriptor’ may result in an unaligned pointer value 
[-Waddress-of-packed-member]
  555 |  collect_langs(sp, s->wData);

Define structure alignment to be 2 to guarantee alignment of its members.

Signed-off-by: Andy Shevchenko 
---
 include/linux/usb/ch9.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/usb/ch9.h b/include/linux/usb/ch9.h
index 264c9712a3..a9b3c2709a 100644
--- a/include/linux/usb/ch9.h
+++ b/include/linux/usb/ch9.h
@@ -336,7 +336,7 @@ struct usb_string_descriptor {
__u8  bDescriptorType;
 
__le16 wData[1];/* UTF-16LE encoded */
-} __attribute__ ((packed));
+} __attribute__ ((packed, aligned(2)));
 
 /* note that "string" zero is special, it holds language codes that
  * the device supports, not Unicode characters.
-- 
2.23.0.rc1

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

Re: [U-Boot] [PATCH v1 1/4] x86: acpi: Annotate struct acpi_table_header with __packed

[Andy Shevchenko]

On Thu, Aug 29, 2019 at 5:13 PM Bin Meng  wrote:
>
> Hi Andy,
>
> On Thu, Aug 29, 2019 at 10:04 PM Andy Shevchenko
>  wrote:
> >
> > GCC starts complaining about possible pointer misalignment of pointers to 
> > the
>
> Which GCC version?

gcc (Debian 9.2.1-4) 9.2.1 20190821
Copyright (C) 2019 Free Software Foundation, Inc.

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

Re: [U-Boot] [PATCH v1 1/4] x86: acpi: Annotate struct acpi_table_header with __packed

[Bin Meng]

Hi Andy,

On Thu, Aug 29, 2019 at 10:04 PM Andy Shevchenko
 wrote:
>
> GCC starts complaining about possible pointer misalignment of pointers to the

Which GCC version?

> unpacked (alignment=4) structures in the packed (alignment=1) ones:
>
>   CC  arch/x86/cpu/tangier/acpi.o
> arch/x86/cpu/tangier/acpi.c: In function ‘acpi_create_fadt’:
> arch/x86/cpu/tangier/acpi.c:22:37: warning: taking address of packed member 
> of ‘struct acpi_fadt’ may result in an unaligned pointer value 
> [-Waddress-of-packed-member]
>   22 |  struct acpi_table_header *header = &(fadt->header);
>
>   CC  arch/x86/lib/acpi_table.o
> arch/x86/lib/acpi_table.c: In function ‘acpi_create_spcr’:
> arch/x86/lib/acpi_table.c:366:37: warning: taking address of packed member of 
> ‘struct acpi_spcr’ may result in an unaligned pointer value 
> [-Waddress-of-packed-member]
>   366 |  struct acpi_table_header *header = &(spcr->header);
>
> Fix the potential issues by annotating embedded structures with __packed even
> though they are packed naturally.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/include/asm/acpi_table.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

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

[U-Boot] [PATCH 1/2] dm: spi: Return 0 if driver does not implement ops->cs_info

[Bin Meng]

If an SPI controller driver does not implement ops->cs_info, that
probably means any chip select number could be valid, hence let's
return 0 for spi_cs_info().

Signed-off-by: Bin Meng 
---

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

diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
index 88cb2a1..24de0b5 100644
--- a/drivers/spi/spi-uclass.c
+++ b/drivers/spi/spi-uclass.c
@@ -237,11 +237,10 @@ int spi_cs_info(struct udevice *bus, uint cs, struct 
spi_cs_info *info)
return ops->cs_info(bus, cs, info);
 
/*
-* We could assume there is at least one valid chip select, but best
-* to be sure and return an error in this case. The driver didn't
-* care enough to tell us.
+* We could assume there is at least one valid chip select.
+* The driver didn't care enough to tell us.
 */
-   return -ENODEV;
+   return 0;
 }
 
 int spi_find_bus_and_cs(int busnum, int cs, struct udevice **busp,
-- 
2.7.4

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

[U-Boot] [PATCH 2/2] dm: spi: Check cs number before accessing slaves

[Bin Meng]

In spi_get_bus_and_cs() only bus number is checked before accessing
slaves. We should check cs number as well.

Signed-off-by: Bin Meng 
---

 drivers/spi/spi-uclass.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
index 24de0b5..f633eb5 100644
--- a/drivers/spi/spi-uclass.c
+++ b/drivers/spi/spi-uclass.c
@@ -271,6 +271,7 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed, int 
mode,
 {
struct udevice *bus, *dev;
struct dm_spi_slave_platdata *plat;
+   struct spi_cs_info info;
bool created = false;
int ret;
 
@@ -283,6 +284,11 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed, int 
mode,
printf("Invalid bus %d (err=%d)\n", busnum, ret);
return ret;
}
+   ret = spi_cs_info(bus, cs, );
+   if (ret) {
+   printf("Invalid cs %d (err=%d)\n", cs, ret);
+   return ret;
+   }
ret = spi_find_chip_select(bus, cs, );
 
/*
-- 
2.7.4

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

[U-Boot] [PATCH v1 2/4] x86: tangier: Reserve PCI ECAM in motherboard resources

[Andy Shevchenko]

Per PCI firmware specification the ACPI has to reserve the memory
which is defined as PCI ECAM.

Fixes: 39665beed6f7 ("x86: tangier: Enable ACPI support for Intel Tangier")
Signed-off-by: Andy Shevchenko 
---
 arch/x86/cpu/tangier/acpi.c |  3 ++-
 .../include/asm/arch-tangier/acpi/platform.asl  |  1 +
 .../asm/arch-tangier/acpi/southcluster.asl  | 17 +
 arch/x86/include/asm/arch-tangier/iomap.h   | 10 ++
 4 files changed, 30 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/include/asm/arch-tangier/iomap.h

diff --git a/arch/x86/cpu/tangier/acpi.c b/arch/x86/cpu/tangier/acpi.c
index 61b2642aa9..362e133cf1 100644
--- a/arch/x86/cpu/tangier/acpi.c
+++ b/arch/x86/cpu/tangier/acpi.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 void acpi_create_fadt(struct acpi_fadt *fadt, struct acpi_facs *facs,
  void *dsdt)
@@ -63,7 +64,7 @@ u32 acpi_fill_mcfg(u32 current)
/* TODO: Derive parameters from SFI MCFG table */
current += acpi_create_mcfg_mmconfig
((struct acpi_mcfg_mmconfig *)current,
-   0x3f50, 0x0, 0x0, 0x0);
+   MCFG_BASE_ADDRESS, 0x0, 0x0, 0x0);
 
return current;
 }
diff --git a/arch/x86/include/asm/arch-tangier/acpi/platform.asl 
b/arch/x86/include/asm/arch-tangier/acpi/platform.asl
index a75b388c47..cf75ca7543 100644
--- a/arch/x86/include/asm/arch-tangier/acpi/platform.asl
+++ b/arch/x86/include/asm/arch-tangier/acpi/platform.asl
@@ -6,6 +6,7 @@
  */
 
 #include 
+#include 
 
 /*
  * The _PTS method (Prepare To Sleep) is called before the OS is
diff --git a/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl 
b/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
index 1b9d808b7b..f73a6b351c 100644
--- a/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
+++ b/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
@@ -66,6 +66,23 @@ Device (PCI0)
 Return (MCRS)
 }
 
+/* Device Resource Consumption */
+Device (PDRC)
+{
+Name (_HID, EISAID("PNP0C02"))
+Name (_UID, One)
+
+Name (PDRS, ResourceTemplate()
+{
+Memory32Fixed(ReadWrite, MCFG_BASE_ADDRESS, MCFG_BASE_SIZE)
+})
+
+Method (_CRS, 0, Serialized)
+{
+Return (PDRS)
+}
+}
+
 Method (_OSC, 4)
 {
 /* Check for proper GUID */
diff --git a/arch/x86/include/asm/arch-tangier/iomap.h 
b/arch/x86/include/asm/arch-tangier/iomap.h
new file mode 100644
index 00..b0fc03e015
--- /dev/null
+++ b/arch/x86/include/asm/arch-tangier/iomap.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/* Copyright (c) 2019 Intel Corporation */
+
+#ifndef _TANGIER_IOMAP_H
+#define _TANGIER_IOMAP_H
+
+#define MCFG_BASE_ADDRESS  0x3f50
+#define MCFG_BASE_SIZE 0x0010
+
+#endif /* _TANGIER_IOMAP_H */
-- 
2.23.0.rc1

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

[U-Boot] [PATCH v1 1/4] x86: acpi: Annotate struct acpi_table_header with __packed

[Andy Shevchenko]

GCC starts complaining about possible pointer misalignment of pointers to the
unpacked (alignment=4) structures in the packed (alignment=1) ones:

  CC  arch/x86/cpu/tangier/acpi.o
arch/x86/cpu/tangier/acpi.c: In function ‘acpi_create_fadt’:
arch/x86/cpu/tangier/acpi.c:22:37: warning: taking address of packed member of 
‘struct acpi_fadt’ may result in an unaligned pointer value 
[-Waddress-of-packed-member]
  22 |  struct acpi_table_header *header = &(fadt->header);

  CC  arch/x86/lib/acpi_table.o
arch/x86/lib/acpi_table.c: In function ‘acpi_create_spcr’:
arch/x86/lib/acpi_table.c:366:37: warning: taking address of packed member of 
‘struct acpi_spcr’ may result in an unaligned pointer value 
[-Waddress-of-packed-member]
  366 |  struct acpi_table_header *header = &(spcr->header);

Fix the potential issues by annotating embedded structures with __packed even
though they are packed naturally.

Signed-off-by: Andy Shevchenko 
---
 arch/x86/include/asm/acpi_table.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/acpi_table.h 
b/arch/x86/include/asm/acpi_table.h
index 02aea127c1..7588913f93 100644
--- a/arch/x86/include/asm/acpi_table.h
+++ b/arch/x86/include/asm/acpi_table.h
@@ -34,7 +34,7 @@ struct acpi_rsdp {
 };
 
 /* Generic ACPI header, provided by (almost) all tables */
-struct acpi_table_header {
+struct __packed acpi_table_header {
char signature[4];  /* ACPI signature (4 ASCII characters) */
u32 length; /* Table length in bytes (incl. header) */
u8 revision;/* Table version (not ACPI version!) */
-- 
2.23.0.rc1

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

[U-Boot] [PATCH v1 4/4] x86: tangier: Use spaces over TABs in ASL code

[Andy Shevchenko]

For sake of consistency use spaces over TABs in ASL code.

Signed-off-by: Andy Shevchenko 
---
 .../asm/arch-tangier/acpi/southcluster.asl| 26 +--
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl 
b/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
index f73a6b351c..c622783f44 100644
--- a/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
+++ b/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
@@ -382,19 +382,19 @@ Device (PCI0)
 Name (RBUF, ResourceTemplate()
 {
 /*
-* Shadow registers in SRAM for PMIC:
-*   SRAM   PMIC register
-*   
-*   0x00-  Unknown
-*   0x03   THRMIRQ (0x04)
-*   0x04   BCUIRQ (0x05)
-*   0x05   ADCIRQ (0x06)
-*   0x06   CHGRIRQ0 (0x07)
-*   0x07   CHGRIRQ1 (0x08)
-*   0x08-  Unknown
-*   0x0a   PBSTATUS (0x27)
-*   0x0b-  Unknown
-*/
+ * Shadow registers in SRAM for PMIC:
+ *   SRAMPMIC register
+ *   
+ *   0x00-Unknown
+ *   0x03THRMIRQ (0x04)
+ *   0x04BCUIRQ (0x05)
+ *   0x05ADCIRQ (0x06)
+ *   0x06CHGRIRQ0 (0x07)
+ *   0x07CHGRIRQ1 (0x08)
+ *   0x08-Unknown
+ *   0x0aPBSTATUS (0x27)
+ *   0x0b-Unknown
+ */
 Memory32Fixed(ReadWrite, 0xF610, 0x0010)
 Interrupt(ResourceConsumer, Level, ActiveHigh, Shared, ,, 
) { 30 }
 Interrupt(ResourceConsumer, Level, ActiveHigh, Shared, ,, 
) { 23 }
-- 
2.23.0.rc1

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

[U-Boot] [PATCH v1 3/4] x86: tangier: Fix off-by-one error when preparing CSRT

[Andy Shevchenko]

Intel iDMA 32-bit controller has 17 bits for the maximum block size value.
Due to nature of the binary number representation the maximum value is
2^17 - 1. The original code misses the latter part in equation.

Fixes: 5e99fde34a77 ("x86: tangier: Populate CSRT for shared DMA controller")
Signed-off-by: Andy Shevchenko 
---
 arch/x86/cpu/tangier/acpi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/cpu/tangier/acpi.c b/arch/x86/cpu/tangier/acpi.c
index 362e133cf1..8b128138b0 100644
--- a/arch/x86/cpu/tangier/acpi.c
+++ b/arch/x86/cpu/tangier/acpi.c
@@ -95,7 +95,7 @@ static u32 acpi_fill_csrt_dma(struct acpi_csrt_group *grp)
si->dma_address_width = 32;
si->base_request_line = 0;
si->num_handshake_signals = 16;
-   si->max_block_size = 0x2;
+   si->max_block_size = 0x1;
 
return grp->length;
 }
-- 
2.23.0.rc1

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

Re: [U-Boot] (no subject)

[Fabio Estevam]

Hi Thomas,

On Thu, Aug 29, 2019 at 10:40 AM Thomas Schaefer
 wrote:

>  arch/arm/dts/imx7d.dtsi | 2 +-
>  arch/arm/dts/imx7s.dtsi | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/dts/imx7d.dtsi b/arch/arm/dts/imx7d.dtsi
> index 30b058934b..2c33aa876f 100644
> --- a/arch/arm/dts/imx7d.dtsi
> +++ b/arch/arm/dts/imx7d.dtsi
> @@ -101,7 +101,7 @@
>   {
> usbotg2: usb@30b2 {
> compatible = "fsl,imx7d-usb", "fsl,imx27-usb";
> -   reg = <0x30b2 0x200>;
> +   reg = <0x30b2 0x1>;

Yes, I have just checked the reference manual and 0x1 size is correct.

Could you please send a patch to fix it in the kernel dts?

Then, after it gets fixed in the kernel we can simply import it to U-Boot.

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

[U-Boot] [PATCH v2 4/5] CVE-2019-14195: nfs: fix unbounded memcpy with unvalidated length at nfs_readlink_reply //RE: [PATCH 4/5] CVE-2019-14195: nfs: fix unbounded memcpy with unvalidated length at n

[liucheng (G)]

Changes in v2:
- Add reported-by tag for patch 4/5
--
CVE-2019-14195: nfs: fix unbounded memcpy with unvalidated length at 
nfs_readlink_reply

This patch adds a check to rpc_pkt.u.reply.data at nfs_readlink_reply.

Signed-off-by: Cheng Liu 
Reported-by: Fermín Serna 
---
 net/nfs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/nfs.c b/net/nfs.c
index 11941fa..915acd9 100644
--- a/net/nfs.c
+++ b/net/nfs.c
@@ -634,6 +634,9 @@ static int nfs_readlink_reply(uchar *pkt, unsigned len)
/* new path length */
rlen = ntohl(rpc_pkt.u.reply.data[1 + nfsv3_data_offset]);
 
+   if (((uchar *)&(rpc_pkt.u.reply.data[0]) - (uchar *)(_pkt) + rlen) 
> len)
+   return -NFS_RPC_DROP;
+
if (*((char *)&(rpc_pkt.u.reply.data[2 + nfsv3_data_offset])) != '/') {
int pathlen;
 
-- 
1.8.5.6

-Original Message-
From: liucheng (G) 
Sent: Wednesday, August 21, 2019 10:48 PM
To: u-boot@lists.denx.de
Cc: liucheng (G) 
Subject: [PATCH 4/5] CVE-2019-14195: nfs: fix unbounded memcpy with unvalidated 
length at nfs_readlink_reply

CVE-2019-14195: nfs: fix unbounded memcpy with unvalidated length at 
nfs_readlink_reply

This patch adds a check to rpc_pkt.u.reply.data at nfs_readlink_reply.

Signed-off-by: Cheng Liu 
---
 net/nfs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/nfs.c b/net/nfs.c
index 11941fa..915acd9 100644
--- a/net/nfs.c
+++ b/net/nfs.c
@@ -634,6 +634,9 @@ static int nfs_readlink_reply(uchar *pkt, unsigned len)
/* new path length */
rlen = ntohl(rpc_pkt.u.reply.data[1 + nfsv3_data_offset]);
 
+   if (((uchar *)&(rpc_pkt.u.reply.data[0]) - (uchar *)(_pkt) + rlen) 
> len)
+   return -NFS_RPC_DROP;
+
if (*((char *)&(rpc_pkt.u.reply.data[2 + nfsv3_data_offset])) != '/') {
int pathlen;
 
-- 
1.8.5.6

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

[U-Boot] [PATCH v2 3/5] CVE-2019-14194/CVE-2019-14198: nfs: fix unbounded memcpy with a failed length check at nfs_read_reply //RE: [PATCH 3/5] CVE-2019-14194/CVE-2019-14198: nfs: fix unbounded memcpy

[liucheng (G)]

Changes in v2:
- Add reported-by tag for patch 3/5
--
CVE-2019-14194/CVE-2019-14198: nfs: fix unbounded memcpy with a failed length 
check at nfs_read_reply

This patch adds a check to rpc_pkt.u.reply.data at nfs_read_reply.

Signed-off-by: Cheng Liu 
Reported-by: Fermín Serna 
---
 net/nfs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/nfs.c b/net/nfs.c
index b7cf3b3..11941fa 100644
--- a/net/nfs.c
+++ b/net/nfs.c
@@ -701,6 +701,9 @@ static int nfs_read_reply(uchar *pkt, unsigned len)
&(rpc_pkt.u.reply.data[4 + nfsv3_data_offset]);
}
 
+   if (((uchar *)&(rpc_pkt.u.reply.data[0]) - (uchar *)(_pkt) + rlen) 
> len)
+   return -;
+
if (store_block(data_ptr, nfs_offset, rlen))
return -;
 
-- 
1.8.5.6

-Original Message-
From: liucheng (G) 
Sent: Wednesday, August 21, 2019 10:48 PM
To: u-boot@lists.denx.de
Cc: liucheng (G) 
Subject: [PATCH 3/5] CVE-2019-14194/CVE-2019-14198: nfs: fix unbounded memcpy 
with a failed length check at nfs_read_reply

CVE-2019-14194/CVE-2019-14198: nfs: fix unbounded memcpy with a failed length 
check at nfs_read_reply

This patch adds a check to rpc_pkt.u.reply.data at nfs_read_reply.

Signed-off-by: Cheng Liu 
---
 net/nfs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/nfs.c b/net/nfs.c
index b7cf3b3..11941fa 100644
--- a/net/nfs.c
+++ b/net/nfs.c
@@ -701,6 +701,9 @@ static int nfs_read_reply(uchar *pkt, unsigned len)
&(rpc_pkt.u.reply.data[4 + nfsv3_data_offset]);
}
 
+   if (((uchar *)&(rpc_pkt.u.reply.data[0]) - (uchar *)(_pkt) + rlen) 
> len)
+   return -;
+
if (store_block(data_ptr, nfs_offset, rlen))
return -;
 
-- 
1.8.5.6

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

[U-Boot] [PATCH v2 5/5] CVE-2019-14196: nfs: fix unbounded memcpy with a failed length check at nfs_lookup_reply //RE: [PATCH 5/5] CVE-2019-14196: nfs: fix unbounded memcpy with a failed length check

[liucheng (G)]

Changes in v2:
- Add reported-by tag for patch 5/5
--
CVE-2019-14196: nfs: fix unbounded memcpy with a failed length check at 
nfs_lookup_reply

This patch adds a check to rpc_pkt.u.reply.data at nfs_lookup_reply.

Signed-off-by: Cheng Liu 
Reported-by: Fermín Serna 
---
 net/nfs.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/net/nfs.c b/net/nfs.c
index 915acd9..89952ae 100644
--- a/net/nfs.c
+++ b/net/nfs.c
@@ -566,11 +566,15 @@ static int nfs_lookup_reply(uchar *pkt, unsigned len)
}
 
if (supported_nfs_versions & NFSV2_FLAG) {
+   if (((uchar *)&(rpc_pkt.u.reply.data[0]) - (uchar *)(_pkt) 
+ NFS_FHSIZE) > len)
+   return -NFS_RPC_DROP;
memcpy(filefh, rpc_pkt.u.reply.data + 1, NFS_FHSIZE);
} else {  /* NFSV3_FLAG */
filefh3_length = ntohl(rpc_pkt.u.reply.data[1]);
if (filefh3_length > NFS3_FHSIZE)
filefh3_length  = NFS3_FHSIZE;
+   if (((uchar *)&(rpc_pkt.u.reply.data[0]) - (uchar *)(_pkt) 
+ filefh3_length) > len)
+   return -NFS_RPC_DROP;
memcpy(filefh, rpc_pkt.u.reply.data + 2, filefh3_length);
}
 
-- 
1.8.5.6

-Original Message-
From: liucheng (G) 
Sent: Wednesday, August 21, 2019 10:48 PM
To: u-boot@lists.denx.de
Cc: liucheng (G) 
Subject: [PATCH 5/5] CVE-2019-14196: nfs: fix unbounded memcpy with a failed 
length check at nfs_lookup_reply

CVE-2019-14196: nfs: fix unbounded memcpy with a failed length check at 
nfs_lookup_reply

This patch adds a check to rpc_pkt.u.reply.data at nfs_lookup_reply.

Signed-off-by: Cheng Liu 
---
 net/nfs.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/net/nfs.c b/net/nfs.c
index 915acd9..89952ae 100644
--- a/net/nfs.c
+++ b/net/nfs.c
@@ -566,11 +566,15 @@ static int nfs_lookup_reply(uchar *pkt, unsigned len)
}
 
if (supported_nfs_versions & NFSV2_FLAG) {
+   if (((uchar *)&(rpc_pkt.u.reply.data[0]) - (uchar *)(_pkt) 
+ NFS_FHSIZE) > len)
+   return -NFS_RPC_DROP;
memcpy(filefh, rpc_pkt.u.reply.data + 1, NFS_FHSIZE);
} else {  /* NFSV3_FLAG */
filefh3_length = ntohl(rpc_pkt.u.reply.data[1]);
if (filefh3_length > NFS3_FHSIZE)
filefh3_length  = NFS3_FHSIZE;
+   if (((uchar *)&(rpc_pkt.u.reply.data[0]) - (uchar *)(_pkt) 
+ filefh3_length) > len)
+   return -NFS_RPC_DROP;
memcpy(filefh, rpc_pkt.u.reply.data + 2, filefh3_length);
}
 
-- 
1.8.5.6

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

[U-Boot] [PATCH v2 2/5] CVE: nfs: fix stack-based buffer overflow in some nfs_handler reply helper functions //RE: [PATCH 2/5] CVE: nfs: fix stack-based buffer overflow in some nfs_handler reply helpe

[liucheng (G)]

Changes in v2:
- Add reported-by tag for patch 2/5
--
CVE: nfs: fix stack-based buffer overflow in some nfs_handler reply helper 
functions

This patch adds a check to nfs_handler to fix buffer overflow for 
CVE-2019-14197,
CVE-2019-14200, CVE-2019-14201, CVE-2019-14202, CVE-2019-14203 and 
CVE-2019-14204.

Signed-off-by: Cheng Liu 
Reported-by: Fermín Serna 
---
 net/nfs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/nfs.c b/net/nfs.c
index d6a7f8e..b7cf3b3 100644
--- a/net/nfs.c
+++ b/net/nfs.c
@@ -732,6 +732,9 @@ static void nfs_handler(uchar *pkt, unsigned dest, struct 
in_addr sip,
 
debug("%s\n", __func__);
 
+   if (len > sizeof(struct rpc_t))
+   return;
+
if (dest != nfs_our_port)
return;
 
-- 
1.8.5.6

-Original Message-
From: liucheng (G) 
Sent: Wednesday, August 21, 2019 10:48 PM
To: u-boot@lists.denx.de
Cc: liucheng (G) 
Subject: [PATCH 2/5] CVE: nfs: fix stack-based buffer overflow in some 
nfs_handler reply helper functions

CVE: nfs: fix stack-based buffer overflow in some nfs_handler reply helper 
functions

This patch adds a check to nfs_handler to fix buffer overflow for 
CVE-2019-14197,
CVE-2019-14200, CVE-2019-14201, CVE-2019-14202, CVE-2019-14203 and 
CVE-2019-14204.

Signed-off-by: Cheng Liu 
---
 net/nfs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/nfs.c b/net/nfs.c
index d6a7f8e..b7cf3b3 100644
--- a/net/nfs.c
+++ b/net/nfs.c
@@ -732,6 +732,9 @@ static void nfs_handler(uchar *pkt, unsigned dest, struct 
in_addr sip,
 
debug("%s\n", __func__);
 
+   if (len > sizeof(struct rpc_t))
+   return;
+
if (dest != nfs_our_port)
return;
 
-- 
1.8.5.6

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

[U-Boot] [PATCH v2 1/5] CVE: net: fix unbounded memcpy of UDP packet//RE: [PATCH 1/5] CVE: net: fix unbounded memcpy of UDP packet

[liucheng (G)]

Changes in v2:
- Add reviewed-by and reported-by tags for patch 1/5
--
CVE: net: fix unbounded memcpy of UDP packet

This patch adds a check to udp_len to fix unbounded memcpy for
CVE-2019-14192, CVE-2019-14193 and CVE-2019-14199.

Signed-off-by: Cheng Liu 
Reviewed-by: Simon Goldschmidt 
Reported-by: Fermín Serna 
---
 net/net.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/net.c b/net/net.c
index 40511db..68f9693 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1253,6 +1253,9 @@ void net_process_received_packet(uchar *in_packet, int 
len)
return;
}
 
+   if (ntohs(ip->udp_len) < UDP_HDR_SIZE || ntohs(ip->udp_len) > 
ntohs(ip->ip_len))
+   return;
+
debug_cond(DEBUG_DEV_PKT,
   "received UDP (to=%pI4, from=%pI4, len=%d)\n",
   _ip, _ip, len);
-- 
1.8.5.6

-Original Message-
From: Simon Goldschmidt [mailto:simon.k.r.goldschm...@gmail.com] 
Sent: Thursday, August 22, 2019 3:30 AM
To: liucheng (G) 
Cc: U-Boot Mailing List 
Subject: Re: [U-Boot] [PATCH 1/5] CVE: net: fix unbounded memcpy of UDP packet

On Wed, Aug 21, 2019 at 8:32 PM Cheng Liu  wrote:
>
> CVE: net: fix unbounded memcpy of UDP packet
>
> This patch adds a check to udp_len to fix unbounded memcpy for
> CVE-2019-14192, CVE-2019-14193 and CVE-2019-14199.
>
> Signed-off-by: Cheng Liu 

Reviewed-by: Simon Goldschmidt 

Although being annoyed by the lack of response from Fermin nearly a
month ago, would it make sense to add:

Reported-by: Fermín Serna 

Regards,
Simon

> ---
>  net/net.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/net/net.c b/net/net.c
> index 40511db..68f9693 100644
> --- a/net/net.c
> +++ b/net/net.c
> @@ -1253,6 +1253,9 @@ void net_process_received_packet(uchar *in_packet, int 
> len)
> return;
> }
>
> +   if (ntohs(ip->udp_len) < UDP_HDR_SIZE || ntohs(ip->udp_len) > 
> ntohs(ip->ip_len))
> +   return;
> +
> debug_cond(DEBUG_DEV_PKT,
>"received UDP (to=%pI4, from=%pI4, len=%d)\n",
>_ip, _ip, len);
> --
> 1.8.5.6
>
> ___
> 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

[U-Boot] (no subject)

[Thomas Schaefer]

Hi all,

I want to introduce a small patch that fixes v 2019.07 bootloader crash during
USB scan on our i.MX7 based custom board (see explanation in the patch comment).

Could you please review and add to next u-boot release?

Best regards,
Thomas


From 3a5dab56111d55fca0f5925bc852f663c71de6c8 Mon Sep 17 00:00:00 2001
From: Thomas Schaefer 
Date: Thu, 29 Aug 2019 11:36:53 +0200
Subject: [PATCH] dts: arm: fix USB controller 'size' parameter

With introduction of bind method in ehci-mx6 driver, usb device
sequence number is calculated using the base address and size
paramters of the reg property in the usbotg and usbh nodes.

Currently the size parameter is set to 0x200 in imx7s and imx7d
dtsi files, which is wrong for i.MX7 and results in board reset
in case that more than one USB interface is used. Setting reg
to the correct value of 0x1 will fix this issue.

Signed-off-by: Thomas Schaefer 
---
 arch/arm/dts/imx7d.dtsi | 2 +-
 arch/arm/dts/imx7s.dtsi | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/dts/imx7d.dtsi b/arch/arm/dts/imx7d.dtsi
index 30b058934b..2c33aa876f 100644
--- a/arch/arm/dts/imx7d.dtsi
+++ b/arch/arm/dts/imx7d.dtsi
@@ -101,7 +101,7 @@
  {
usbotg2: usb@30b2 {
compatible = "fsl,imx7d-usb", "fsl,imx27-usb";
-   reg = <0x30b2 0x200>;
+   reg = <0x30b2 0x1>;
interrupts = ;
clocks = < IMX7D_USB_CTRL_CLK>;
fsl,usbphy = <>;
diff --git a/arch/arm/dts/imx7s.dtsi b/arch/arm/dts/imx7s.dtsi
index 5067b9f7e7..8b9b4bbd8a 100644
--- a/arch/arm/dts/imx7s.dtsi
+++ b/arch/arm/dts/imx7s.dtsi
@@ -1003,7 +1003,7 @@
 
usbotg1: usb@30b1 {
compatible = "fsl,imx7d-usb", "fsl,imx27-usb";
-   reg = <0x30b1 0x200>;
+   reg = <0x30b1 0x1>;
interrupts = ;
clocks = < IMX7D_USB_CTRL_CLK>;
fsl,usbphy = <>;
@@ -1014,7 +1014,7 @@
 
usbh: usb@30b3 {
compatible = "fsl,imx7d-usb", "fsl,imx27-usb";
-   reg = <0x30b3 0x200>;
+   reg = <0x30b3 0x1>;
interrupts = ;
clocks = < IMX7D_USB_CTRL_CLK>;
fsl,usbphy = <>;
-- 
2.11.0

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

[U-Boot] [PATCH] arm: omap2: am43xx: Enable CONFIG_DM_USB

[sunil . m]

From: Suniel Mahesh 

Enable CONFIG_DM_USB to remove compile warning for
am43xx based targets:

= WARNING ==
This board does not use CONFIG_DM_USB. Please update
the board to use CONFIG_DM_USB before the v2019.07 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/MIGRATION.txt for more info.


Signed-off-by: Suniel Mahesh 
---
 configs/am43xx_evm_qspiboot_defconfig | 1 +
 configs/am43xx_evm_rtconly_defconfig  | 1 +
 configs/am43xx_hs_evm_defconfig   | 1 +
 3 files changed, 3 insertions(+)

diff --git a/configs/am43xx_evm_qspiboot_defconfig 
b/configs/am43xx_evm_qspiboot_defconfig
index 06268ba..b1bf670 100644
--- a/configs/am43xx_evm_qspiboot_defconfig
+++ b/configs/am43xx_evm_qspiboot_defconfig
@@ -50,6 +50,7 @@ CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
 CONFIG_TI_QSPI=y
 CONFIG_USB=y
+CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_DWC3=y
diff --git a/configs/am43xx_evm_rtconly_defconfig 
b/configs/am43xx_evm_rtconly_defconfig
index caf761b..3064f31 100644
--- a/configs/am43xx_evm_rtconly_defconfig
+++ b/configs/am43xx_evm_rtconly_defconfig
@@ -49,6 +49,7 @@ CONFIG_TI_QSPI=y
 CONFIG_TIMER=y
 CONFIG_OMAP_TIMER=y
 CONFIG_USB=y
+CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_DWC3=y
diff --git a/configs/am43xx_hs_evm_defconfig b/configs/am43xx_hs_evm_defconfig
index d634ab1..8be2102 100644
--- a/configs/am43xx_hs_evm_defconfig
+++ b/configs/am43xx_hs_evm_defconfig
@@ -59,6 +59,7 @@ CONFIG_TI_QSPI=y
 CONFIG_TIMER=y
 CONFIG_OMAP_TIMER=y
 CONFIG_USB=y
+CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_DWC3=y
-- 
2.7.4

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

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

[Marek Vasut]

The following changes since commit 8c56ea5c1e033f16993e5427300399ef848234bb:

  Merge branch 'u-boot-stm32_20190827' of
https://gitlab.denx.de/u-boot/custodians/u-boot-stm (2019-08-27 13:19:47
-0400)

are available in the Git repository at:

  git://git.denx.de/u-boot-usb.git master

for you to fetch changes up to fd0637b814cdbc8aa9060f313f6c8e71fb9c5d15:

  dwc2: use the nonblock argument in submit_int_msg (2019-08-29 14:07:26
+0200)


Michal Suchanek (5):
  usb_kdb: only process events successfully received
  usb: usb_submit_int_msg -> usb_int_msg
  usb: storage: submit_int_msg -> usb_int_msg
  usb: Add nonblock argument to submit_int_msg
  dwc2: use the nonblock argument in submit_int_msg

 common/usb.c   | 11 +++
 common/usb_kbd.c   | 11 +--
 common/usb_storage.c   |  4 ++--
 drivers/usb/emul/sandbox_keyb.c|  3 ++-
 drivers/usb/emul/usb-emul-uclass.c |  6 --
 drivers/usb/host/dwc2.c| 15 +--
 drivers/usb/host/ehci-hcd.c| 13 -
 drivers/usb/host/ohci-hcd.c|  4 ++--
 drivers/usb/host/r8a66597-hcd.c|  2 +-
 drivers/usb/host/sl811-hcd.c   |  2 +-
 drivers/usb/host/usb-sandbox.c |  5 +++--
 drivers/usb/host/usb-uclass.c  |  5 +++--
 drivers/usb/host/xhci.c| 13 -
 drivers/usb/musb-new/musb_uboot.c  | 12 +++-
 include/usb.h  | 11 ++-
 15 files changed, 68 insertions(+), 49 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PULL] u-boot-sh/master

[Marek Vasut]

The following changes since commit 1e60ccd94318fb86610e1e28512b2aaac5f4b069:

  Merge branch '2019-08-20-master-imports' (2019-08-20 21:40:12 -0400)

are available in the Git repository at:

  git://git.denx.de/u-boot-sh.git master

for you to fetch changes up to be1e9dc0800a9d44514a0c640ded0bd70400ddc6:

  ARM: renesas: Enable R8A66597 USB host on GR Peach (2019-08-22
18:23:37 +0200)


Marek Vasut (10):
  usb: r8a66597: Remove CONFIG_SUPERH_ON_CHIP_R8A66597
  usb: r8a66597: Make CONFIG_RZA_USB default
  usb: r8a66597: Replace IO accessors
  usb: r8a66597: Remove BE support
  usb: r8a66597: Replace R8A66597_BASE0
  usb: r8a66597: Convert to USB DM
  usb: r8a66597: Add Kconfig entry
  usb: r8a66597: Checkpatch cleanup
  usb: r8a66597: Add optional DM VBUS regulator support
  ARM: renesas: Enable R8A66597 USB host on GR Peach

 arch/arm/dts/r7s72100-gr-peach-u-boot.dts |  14 +
 configs/grpeach_defconfig |   9 +++-
 drivers/usb/host/Kconfig  |   9 
 drivers/usb/host/r8a66597-hcd.c   | 330
+--
 drivers/usb/host/r8a66597.h   | 535
++--
 5 files changed, 458 insertions(+), 439 deletions(-)

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

Re: [U-Boot] [PULL] u-boot-stm32 for v2019.10 (round 1)

[Tom Rini]

On Tue, Aug 27, 2019 at 03:37:33PM +, Patrice CHOTARD wrote:

> Hi Tom
> 
> 
> This pull request is mainly fixes and update related to STM32MP1 platforms
> 
> Travis CI status: https://travis-ci.org/pchotard/u-boot/builds/577259480
> 
> The following changes since commit d39221f33f0e78cc80d1304ab4ca4e4a3886fbff:
> 
>   Prepare v2019.10-rc3 (2019-08-26 20:16:42 -0400)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git 
> u-boot-stm32_20190827
> 
> for you to fetch changes up to 06d1dd2cdc3c69122e58b38fd11b2a4e524a37e2:
> 
>   stm32mp1: update README for remoteproc support (2019-08-27 11:19:23 +0200)
> 

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 08/25] dt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs

[Fabien DESSENNE]

Hi Lokes, Suman


On 28/08/2019 2:55 PM, Lokesh Vutla wrote:
> From: Suman Anna 
>
> The Texas Instruments K3 family of SoCs have one of more dual-core
> Arm Cortex R5F processor subsystems/clusters (R5FSS). Add the device
> tree bindings document for these R5F subsystem devices. These R5F
> processors do not have an MMU, and so require fixed memory carveout
> regions matching the firmware image addresses. The nodes require more
> than one memory region, with the first memory region used for DMA
> allocations at runtime. The remaining memory regions are reserved
> and are used for the loading and running of the R5F remote processors.
>
> The added example illustrates the DT nodes for the single R5FSS device
> present on K3 AM65x family of SoCs.
>
> Signed-off-by: Suman Anna 
> Signed-off-by: Lokesh Vutla 
> ---
>   .../remoteproc/ti,k3-r5f-rproc.txt| 164 ++
>   1 file changed, 164 insertions(+)
>   create mode 100644 doc/device-tree-bindings/remoteproc/ti,k3-r5f-rproc.txt
>
> diff --git a/doc/device-tree-bindings/remoteproc/ti,k3-r5f-rproc.txt 
> b/doc/device-tree-bindings/remoteproc/ti,k3-r5f-rproc.txt
> new file mode 100644
> index 00..c2fa6e8344
> --- /dev/null
> +++ b/doc/device-tree-bindings/remoteproc/ti,k3-r5f-rproc.txt
> @@ -0,0 +1,164 @@
> +TI K3 R5F processor subsystems
> +==
> +
> +The TI K3 family of SoCs usually have one or more dual-core Arm Cortex
> +R5F processor subsystems/clusters (R5FSS). The dual core cluster can be
> +used either in a LockStep mode providing safety/fault tolerance features
> +or in a Split mode providing two individual compute cores for doubling
> +the compute capacity. These are used together with other processors
> +present on the SoC to achieve various system level goals.
> +
> +R5F Sub-System Device Node:
> +===
> +Each Dual-Core R5F sub-system is represented as a single DTS node 
> representing
> +the cluster, with a pair of child DT nodes representing the individual R5F
> +cores. Each node has a number of required or optional properties that enable
> +the OS running on the host processor to perform the device management of the
> +remote processor and to communicate with the remote processor.
> +
> +Required properties:
> +
> +The following are the mandatory properties:
> +
> +- compatible:Should be one of the following,
> + "ti,am654-r5fss" for R5F clusters/subsystems on
> +K3 AM65x SoCs
> + "ti,j721e-r5fss" for R5F clusters/subsystems on
> +K3 J721E SoCs
> +- power-domains: Should contain a phandle to a PM domain provider node
> + and an args specifier containing the R5FSS device id
> + value. This property is as per the binding,
> + 
> Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
> +- #address-cells:Should be 1
> +- #size-cells:   Should be 1
> +- ranges:Standard ranges definition providing translations for
> + R5F TCM address spaces


Maybe dma-ranges is more appropriated here : you can find more details 
here: https://lkml.org/lkml/2019/4/3/1261

BR

Fabien


> +
> +Optional properties:
> +
> +- lockstep-mode: Configuration Mode for the Dual R5F cores within the R5F
> + cluster. Should be either a value of 1 (LockStep mode) 
> or
> + 0 (Split mode), default is LockStep mode if omitted.
> +
> +
> +R5F Processor Child Nodes:
> +==
> +The R5F Sub-System device node should define two R5F child nodes, each node
> +representing a TI instantiation of the Arm Cortex R5F core. There are some
> +specific integration differences for the IP like the usage of a Region 
> Address
> +Translator (RAT) for translating the larger SoC bus addresses into a 32-bit
> +address space for the processor.
> +
> +Required properties:
> +
> +The following are the mandatory properties:
> +
> +- compatible:Should be one of the following,
> + "ti,am654-r5f" for the R5F cores in K3 AM65x SoCs
> + "ti,j721e-r5f" for the R5F cores in K3 J721E SOCs
> +- reg:   Should contain an entry for each value in 
> 'reg-names'.
> + Each entry should have the memory region's start address
> + and the size of the region, the representation matching
> + the parent node's '#address-cells' and '#size-cells' 
> values.
> +- reg-names: Should contain strings with the following names, each
> + representing a specific internal memory region, and
> + should be defined in this order,
> +  "atcm", "btcm"
> +- ti,sci:

Re: [U-Boot] [PATCH] cmd: pxe: Use internal FDT if external one cannot be retrieved

[Anton Leontiev]

2019-08-26 at 18:59, Stephen Warren :
> On 8/23/19 8:40 AM, Anton Leontiev wrote:
> > From: Anton Leontiev 
> >
> > Original commit c61d94d86035 ("pxe: implement fdtdir extlinux.conf tag")
> > states, that if FDT file cannot be retrieved then FDT packaged in
> > firmware should be used.
>
> It's not meant to say that. I believe the part of the description you're
> referring to is:
>
>  if no FDT file was loaded, and $fdtaddr is set:
># This indicates an FDT packaged with firmware
>use the FDT at $fdtaddr
>
> That wasn't meant to say anything about "if there was an error loading
> the FDT file", but rather is meant to mean "if no FDT file was loaded
> because extlinux.conf contained no fdt or fdtdir statement". Nothing
> there is intended to refer to errors loading a specified FDT file.

Indeed, I read it strictly as "if no FDT file was loaded" regardless the reason.
Thank you for clarification.

> > If FDT file cannot be retrieved and it is specified explicitly using
> > FDT keyword then the label is skipped. If it cannot be found in
> > FDTDIR then internal FDT is tried first.
>
> This makes the fdt/fdtdir keywords work differently. I don't think we
> want that.

FDT will work as always. FDTDIR will be less strict. It doesn't
specify exact file to be loaded, that's why it should not fail if
there is no such file.

> What specific problem are you trying to solve?

We have a GNU/Linux distribution that use FDTDIR in its extlinux.conf
to support several boards. But some boards have FDT embedded in U-Boot
and it is't present in FDTDIR. In such configuration U-Boot fails to
boot an entry, despite no exact FDT is specified in it. Distribution
itself is designed to work on any board.

> And note that if we do change anything here, we should update the
> comment at around line 730, which describes the algorithm that's
> implemented.

Thank you, I'll update the comment.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC PATCH] patman: Use the Change-Id, version, and prefix in the Message-Id

[Johannes Berg]

Hi Doug,

Some comments on the actual mechanics here (vs. on the kernel list I
picked this up from).

It seems like perhaps you could increase the "count" variable. You got:

20190828132723.0.RFC.Ie6289f437ae533d7fcaddfcee9202f0e92c6b2b9@changeid

but usually patches are numbered starting from 1, not 0. Especially for
series, it might be easier to understand if that was the same here.

I'd probably also put it after the tag, so you'd have "RFC.1" instead of
"0.RFC", I'm saying it mostly because I originally thought you somehow
generated a timestamp with a decimal point :-)

Obviously none of that really matters, but it'd be easier to understand
(and if necessary reverse-engineer) IMHO.

johannes


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

Re: [U-Boot] [PATCH 03/25] remoteproc: elf_loader: Always check the validity of the image before loading

[Fabien DESSENNE]

Hi Lokesh


I would prefer you keep the rproc_elf32_sanity_check() API available 
(not static).

Some u-boot drivers (eg ti_power_proc.c) handle binary (raw) firmwares 
while some other handle ELF format ones.

We may think about drivers that can handle both formats. 
rproc_elf32_sanity_check() can then be used to check if the firmware 
shall be ELF-decoded or simply memcpy'ed.

Anyway I agree with your proposal to call rproc_elf32_sanity_check() 
from rproc_elf32_load_image()

BR


Fabien


On 28/08/2019 2:55 PM, Lokesh Vutla wrote:
> rproc_elf32_load_image() rely on user to send a valid address for elf loading.
> Instead do a sanity check on the address passed by user. This will help
> all rproc elf users to not call sanity_check explicitly before calling
> elf_loading.
>
> Now that rproc_elf32_sanity_check() is used only in rproc-elf-loader.c
> make it static.
>
> Signed-off-by: Lokesh Vutla 
> ---
>   drivers/remoteproc/rproc-elf-loader.c | 13 +
>   drivers/remoteproc/stm32_copro.c  |  9 +
>   include/remoteproc.h  | 20 
>   test/dm/remoteproc.c  |  7 ++-
>   4 files changed, 16 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/remoteproc/rproc-elf-loader.c 
> b/drivers/remoteproc/rproc-elf-loader.c
> index 7574ba3fb3..149aeafb85 100644
> --- a/drivers/remoteproc/rproc-elf-loader.c
> +++ b/drivers/remoteproc/rproc-elf-loader.c
> @@ -8,7 +8,7 @@
>   #include 
>   
>   /* Basic function to verify ELF32 image format */
> -int rproc_elf32_sanity_check(ulong addr, ulong size)
> +static int rproc_elf32_sanity_check(ulong addr, ulong size)
>   {
>   Elf32_Ehdr *ehdr;
>   char class;
> @@ -64,13 +64,18 @@ int rproc_elf32_sanity_check(ulong addr, ulong size)
>   return 0;
>   }
>   
> -/* A very simple elf loader, assumes the image is valid */
> -int rproc_elf32_load_image(struct udevice *dev, unsigned long addr)
> +int rproc_elf32_load_image(struct udevice *dev, unsigned long addr, ulong 
> size)
>   {
>   Elf32_Ehdr *ehdr; /* Elf header structure pointer */
>   Elf32_Phdr *phdr; /* Program header structure pointer */
>   const struct dm_rproc_ops *ops;
> - unsigned int i;
> + unsigned int i, ret;
> +
> + ret =  rproc_elf32_sanity_check(addr, size);
> + if (ret) {
> + dev_err(dev, "Invalid ELF32 Image %d\n", ret);
> + return ret;
> + }
>   
>   ehdr = (Elf32_Ehdr *)addr;
>   phdr = (Elf32_Phdr *)(addr + ehdr->e_phoff);
> diff --git a/drivers/remoteproc/stm32_copro.c 
> b/drivers/remoteproc/stm32_copro.c
> index ff82313bca..1760dc5aba 100644
> --- a/drivers/remoteproc/stm32_copro.c
> +++ b/drivers/remoteproc/stm32_copro.c
> @@ -149,14 +149,7 @@ static int stm32_copro_load(struct udevice *dev, ulong 
> addr, ulong size)
>   return ret;
>   }
>   
> - /* Support only ELF32 image */
> - ret = rproc_elf32_sanity_check(addr, size);
> - if (ret) {
> - dev_err(dev, "Invalid ELF32 image (%d)\n", ret);
> - return ret;
> - }
> -
> - return rproc_elf32_load_image(dev, addr);
> + return rproc_elf32_load_image(dev, addr, size);
>   }
>   
>   /**
> diff --git a/include/remoteproc.h b/include/remoteproc.h
> index 81f616a1f9..6657b39723 100644
> --- a/include/remoteproc.h
> +++ b/include/remoteproc.h
> @@ -202,25 +202,14 @@ int rproc_ping(int id);
>*/
>   int rproc_is_running(int id);
>   
> -/**
> - * rproc_elf32_sanity_check() - Verify if an image is a valid ELF32 one
> - *
> - * Check if a valid ELF32 image exists at the given memory location. Verify
> - * basic ELF32 format requirements like magic number and sections size.
> - *
> - * @addr:address of the image to verify
> - * @size:size of the image
> - * @return 0 if the image looks good, else appropriate error value.
> - */
> -int rproc_elf32_sanity_check(ulong addr, ulong size);
> -
>   /**
>* rproc_elf32_load_image() - load an ELF32 image
>* @dev:device loading the ELF32 image
>* @addr:   valid ELF32 image address
> + * @size:size of the image
>* @return 0 if the image is successfully loaded, else appropriate error 
> value.
>*/
> -int rproc_elf32_load_image(struct udevice *dev, unsigned long addr);
> +int rproc_elf32_load_image(struct udevice *dev, unsigned long addr, ulong 
> size);
>   #else
>   static inline int rproc_init(void) { return -ENOSYS; }
>   static inline int rproc_dev_init(int id) { return -ENOSYS; }
> @@ -231,10 +220,9 @@ static inline int rproc_stop(int id) { return -ENOSYS; }
>   static inline int rproc_reset(int id) { return -ENOSYS; }
>   static inline int rproc_ping(int id) { return -ENOSYS; }
>   static inline int rproc_is_running(int id) { return -ENOSYS; }
> -static inline int rproc_elf32_sanity_check(ulong addr,
> -ulong size) { return -ENOSYS; }
>   static inline int rproc_elf32_load_image(struct udevice *dev,
> -   

Re: [U-Boot] [PATCH 05/25] remoteproc: elf_loader: Introduce a common elf loader function

[Fabien DESSENNE]

Hi Lokesh,


Then a common rproc_elf_sanity_check() 32/64-bit common API would be 
great :)


BR

Fabien


On 28/08/2019 2:55 PM, Lokesh Vutla wrote:
> Introduce a common remoteproc elf loader function that automatically
> detects the 64 bit elf file or 32 bit elf file and loads the sections
> accordingly.
>
> Signed-off-by: Lokesh Vutla 
> ---
>   drivers/remoteproc/rproc-elf-loader.c | 15 +++
>   include/remoteproc.h  | 14 ++
>   2 files changed, 29 insertions(+)
>
> diff --git a/drivers/remoteproc/rproc-elf-loader.c 
> b/drivers/remoteproc/rproc-elf-loader.c
> index dff1873a51..276164bae7 100644
> --- a/drivers/remoteproc/rproc-elf-loader.c
> +++ b/drivers/remoteproc/rproc-elf-loader.c
> @@ -219,3 +219,18 @@ int rproc_elf64_load_image(struct udevice *dev, ulong 
> addr, ulong size)
>   
>   return ret;
>   }
> +
> +int rproc_elf_load_image(struct udevice *dev, ulong addr, ulong size)
> +{
> + Elf32_Ehdr *ehdr = (Elf32_Ehdr *)addr;
> +
> + if (!addr) {
> + dev_err(dev, "Invalid firmware address\n");
> + return -EFAULT;
> + }
> +
> + if (ehdr->e_ident[EI_CLASS] == ELFCLASS64)
> + return rproc_elf64_load_image(dev, addr, size);
> + else
> + return rproc_elf32_load_image(dev, addr, size);
> +}
> diff --git a/include/remoteproc.h b/include/remoteproc.h
> index f5d77c8c81..e0493aae2c 100644
> --- a/include/remoteproc.h
> +++ b/include/remoteproc.h
> @@ -219,6 +219,17 @@ int rproc_elf32_load_image(struct udevice *dev, unsigned 
> long addr, ulong size);
>* @return 0 if the image is successfully loaded, else appropriate error 
> value.
>*/
>   int rproc_elf64_load_image(struct udevice *dev, ulong addr, ulong size);
> +
> +/**
> + * rproc_elf_load_image() - load an ELF image
> + * @dev: device loading the ELF image
> + * @addr:valid ELF image address
> + * @size:size of the image
> + *
> + * Auto detects if the image is ELF32 or ELF64 image and load accordingly.
> + * @return 0 if the image is successfully loaded, else appropriate error 
> value.
> + */
> +int rproc_elf_load_image(struct udevice *dev, unsigned long addr, ulong 
> size);
>   #else
>   static inline int rproc_init(void) { return -ENOSYS; }
>   static inline int rproc_dev_init(int id) { return -ENOSYS; }
> @@ -235,6 +246,9 @@ static inline int rproc_elf32_load_image(struct udevice 
> *dev,
>   static inline int rproc_elf64_load_image(struct udevice *dev, ulong addr,
>ulong size)
>   { return -ENOSYS; }
> +static inline int rproc_elf_load_image(struct udevice *dev, ulong addr,
> +ulong size)
> +{ return -ENOSYS; }
>   #endif
>   
>   #endif  /* _RPROC_H_ */
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v5 6/7] phy: Add USB PHY driver for the cadence USB3

[Pawel Laszczak]

+ Rafal, Anil, Sanket, Jayshri, Rahul

>
>We are discussing if Cadence/TI/NXP could use the same USB PHY driver
>
>(drivers/phy/cadence/phy-cadence-sierra.c), I find I can't get
>
>Alan Douglas , would you please forward related
>
>people? The question is like below, thanks.
>
>
>
>Alan, we find the suggested value at this driver 
>(drivers/phy/cadence/phy-cadence-sierra.c)
>
>is so different with "USB 3.0 PHY User Guide for 28FDSOI" CH 3.1.1 Bring-up 
>Sequence.
>
>Does this driver support this 28nm PHY? If it supports, why the initialized 
>value is so different?
>
>The UG suggested value can be used at NXP platform.
>
>
>
>Peter
>
>
>
>> > >
>
>> > > This is indeed a different driver. IMO it would be better to keep
>
>> > > the driver closer to its linux version. The reason for that  is that
>
>> > > it is quite new and will be adapted when platforms starts supporting
>
>> > > it. If we start with something too far from the original, it will hard 
>> > > to update.
>
>> > > Already I see that the registers initialized are not all the same as
>
>> > > in the linux driver and not all the values are the same either, nor
>
>> > > are the register names
>
>> > >
>
>> > > TI's J7 platforms is using this PHY driver for USB3/PCIe support,
>
>> > > and the linux driver has already seen quite a few modifications to
>
>> > > get it to work
>
>> > (https://urldefense.proofpoint.com/v2/url?u=https-3A__eur01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-
>252Fgit.ti=DwIGaQ=aUq983L2pue2FqKFoP6PGHMJQyoJ7kl3s3GZ-_haXqY=e1OgxfvkL0qo9XO6fX1gscva-w03uSYC1nIyxl89-
>rI=Ip2RbyxoGLS3zuYNjazxkPFURIUZllrs6iSfUmllZGM=MG2JpCkGii7tKv3Sb4ekJ08smJd54TTIC6jmZpOdzY0=
> .
>
>> > > com%2Fti-linux-kernel%2Fti-linux-kernel%2Fblobs%2Fhistory%2Fti-linux
>
>> > > -
>
>> > > 4.19.y%2Fdrivers%2Fphy%2Fcadence%2Fphy-cadence-
>
>> > > sierra.cdata=02%7C01%7Csherry.sun%40nxp.com%7C84f9122d7eb64
>
>> > > 9820bae08d72b997681%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0
>
>> > > %7C637025810458595586sdata=6JpD7VcFudhzXSVP0WaGVEp7Fwrue
>
>> > > A%2B4V6eeOfif19w%3Dreserved=0)
>
>> > > Adding support for it on top of this current version will be rather 
>> > > difficult.
>
>> > >
>
>> >
>
>> > Thanks for your advice.
>
>> > Actually I am not familiar with this phy driver in linux, so also
>
>> > +peter, who worked on this USB driver under linux, maybe he can give some
>
>> suggestions.
>
>> >
>
>>
>
>> Add Alan from Cadence
>
>>
>
>> Alan, we find the suggested value at this driver 
>> (drivers/phy/cadence/phy-cadence-
>
>> sierra.c)
>
>> is so different with "USB 3.0 PHY User Guide for 28FDSOI" CH 3.1.1 Bring-up
>
>> Sequence.
>
>> Does this driver support this 28nm PHY? If it supports, why the initialized 
>> value is so
>
>> different?
>
>> The UG suggested value can be used at NXP platform.
>
>>
>
>> Peter

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

Re: [U-Boot] [PATCH 02/25] remoteproc: ops: Add elf section size as input parameter to device_to_virt api

[Fabien DESSENNE]

Hi Lokesh


On 28/08/2019 2:55 PM, Lokesh Vutla wrote:
> Introduce a new parameter size that accepts elf section size to remoteproc
> ops callback device_to_virt(). This can enforce more checks on the
> elf section that is being loaded.


It would be better to talk about "size" instead of "elf section size" 
since device_to_virt may deal with any memory region.


> Signed-off-by: Lokesh Vutla 
> ---
>   drivers/remoteproc/rproc-elf-loader.c | 3 ++-
>   drivers/remoteproc/sandbox_testproc.c | 4 +++-
>   drivers/remoteproc/stm32_copro.c  | 4 +++-
>   include/remoteproc.h  | 3 ++-
>   4 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/remoteproc/rproc-elf-loader.c 
> b/drivers/remoteproc/rproc-elf-loader.c
> index 67937a7595..7574ba3fb3 100644
> --- a/drivers/remoteproc/rproc-elf-loader.c
> +++ b/drivers/remoteproc/rproc-elf-loader.c
> @@ -86,7 +86,8 @@ int rproc_elf32_load_image(struct udevice *dev, unsigned 
> long addr)
>   continue;
>   
>   if (ops->device_to_virt)
> - dst = ops->device_to_virt(dev, (ulong)dst);
> + dst = ops->device_to_virt(dev, (ulong)dst,
> +   phdr->p_memsz);
>   
>   dev_dbg(dev, "Loading phdr %i to 0x%p (%i bytes)\n",
>   i, dst, phdr->p_filesz);
> diff --git a/drivers/remoteproc/sandbox_testproc.c 
> b/drivers/remoteproc/sandbox_testproc.c
> index 5f35119ab7..0a8f7871e1 100644
> --- a/drivers/remoteproc/sandbox_testproc.c
> +++ b/drivers/remoteproc/sandbox_testproc.c
> @@ -306,9 +306,11 @@ static int sandbox_testproc_ping(struct udevice *dev)
>* sandbox_testproc_device_to_virt() - Convert device address to virtual 
> address
>* @dev:device to operate upon
>* @da: device address
> + * @size:Size of the section


Size of the memory region @da is pointing to


>* @return converted virtual address
>*/
> -static void *sandbox_testproc_device_to_virt(struct udevice *dev, ulong da)
> +static void *sandbox_testproc_device_to_virt(struct udevice *dev, ulong da,
> +  ulong size)
>   {
>   u64 paddr;
>   
> diff --git a/drivers/remoteproc/stm32_copro.c 
> b/drivers/remoteproc/stm32_copro.c
> index de3b9729f3..ff82313bca 100644
> --- a/drivers/remoteproc/stm32_copro.c
> +++ b/drivers/remoteproc/stm32_copro.c
> @@ -107,9 +107,11 @@ static int stm32_copro_set_hold_boot(struct udevice 
> *dev, bool hold)
>* stm32_copro_device_to_virt() - Convert device address to virtual address
>* @dev:corresponding STM32 remote processor device
>* @da: device address
> + * @size:Size of the section
>* @return converted virtual address
>*/
> -static void *stm32_copro_device_to_virt(struct udevice *dev, ulong da)
> +static void *stm32_copro_device_to_virt(struct udevice *dev, ulong da,
> + ulong size)
>   {


I guess it would be better than this function also checks that the end 
address of the region is in the range of valid region

Something like:

end_addr = cpu_to_be32(da + size - 1)   + check success of 
dev_translate_dma_address(dev, _addr);


>   fdt32_t in_addr = cpu_to_be32(da);
>   u64 paddr;
> diff --git a/include/remoteproc.h b/include/remoteproc.h
> index 4987194905..81f616a1f9 100644
> --- a/include/remoteproc.h
> +++ b/include/remoteproc.h
> @@ -122,9 +122,10 @@ struct dm_rproc_ops {
>*
>* @dev:Remote proc device
>* @da: Device address
> +  * @size:   Size of the section


Size of the memory region @da is pointing to


>* @return virtual address.
>*/
> - void * (*device_to_virt)(struct udevice *dev, ulong da);
> + void * (*device_to_virt)(struct udevice *dev, ulong da, ulong size);
>   };
>   
>   /* Accessor */
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 04/25] remoteproc: elf-loader: Add 64 bit elf loading support

[Fabien DESSENNE]

Hi Lokesh



On 28/08/2019 2:55 PM, Lokesh Vutla wrote:
> The current rproc-elf-loader supports loading of only 32 bit elf files.
> Introduce support for loading of 64 bit elf files in rproc-elf-loader.
>
> Signed-off-by: Lokesh Vutla 
> ---
>   drivers/remoteproc/rproc-elf-loader.c | 109 ++
>   include/remoteproc.h  |  12 +++
>   2 files changed, 121 insertions(+)
>
> diff --git a/drivers/remoteproc/rproc-elf-loader.c 
> b/drivers/remoteproc/rproc-elf-loader.c
> index 149aeafb85..dff1873a51 100644
> --- a/drivers/remoteproc/rproc-elf-loader.c
> +++ b/drivers/remoteproc/rproc-elf-loader.c
> @@ -64,6 +64,61 @@ static int rproc_elf32_sanity_check(ulong addr, ulong size)
>   return 0;
>   }
>   
> +static int rproc_elf64_sanity_check(ulong addr, ulong size)


The same remark as for rproc_elf32_sanity_check() applies : not static

BR

Fabien


> +{
> + Elf64_Ehdr *ehdr = (Elf64_Ehdr *)addr;
> + char class;
> +
> + if (!addr) {
> + pr_debug("Invalid fw address?\n");
> + return -EFAULT;
> + }
> +
> + if (size < sizeof(Elf64_Ehdr)) {
> + pr_debug("Image is too small\n");
> + return -ENOSPC;
> + }
> +
> + class = ehdr->e_ident[EI_CLASS];
> +
> + if (!IS_ELF(*ehdr) || ehdr->e_type != ET_EXEC || class != ELFCLASS64) {
> + pr_debug("Not an executable ELF64 image\n");
> + return -EPROTONOSUPPORT;
> + }
> +
> + /* We assume the firmware has the same endianness as the host */
> +# ifdef __LITTLE_ENDIAN
> + if (ehdr->e_ident[EI_DATA] != ELFDATA2LSB) {
> +# else /* BIG ENDIAN */
> + if (ehdr->e_ident[EI_DATA] != ELFDATA2MSB) {
> +# endif
> + pr_debug("Unsupported firmware endianness\n");
> + return -EILSEQ;
> + }
> +
> + if (size < ehdr->e_shoff + sizeof(Elf64_Shdr)) {
> + pr_debug("Image is too small\n");
> + return -ENOSPC;
> + }
> +
> + if (memcmp(ehdr->e_ident, ELFMAG, SELFMAG)) {
> + pr_debug("Image is corrupted (bad magic)\n");
> + return -EBADF;
> + }
> +
> + if (ehdr->e_phnum == 0) {
> + pr_debug("No loadable segments\n");
> + return -ENOEXEC;
> + }
> +
> + if (ehdr->e_phoff > size) {
> + pr_debug("Firmware size is too small\n");
> + return -ENOSPC;
> + }
> +
> + return 0;
> +}
> +
>   int rproc_elf32_load_image(struct udevice *dev, unsigned long addr, ulong 
> size)
>   {
>   Elf32_Ehdr *ehdr; /* Elf header structure pointer */
> @@ -110,3 +165,57 @@ int rproc_elf32_load_image(struct udevice *dev, unsigned 
> long addr, ulong size)
>   
>   return 0;
>   }
> +
> +int rproc_elf64_load_image(struct udevice *dev, ulong addr, ulong size)
> +{
> + const struct dm_rproc_ops *ops = rproc_get_ops(dev);
> + u64 da, memsz, filesz, offset;
> + Elf64_Ehdr *ehdr;
> + Elf64_Phdr *phdr;
> + int i, ret = 0;
> + void *ptr;
> +
> + dev_dbg(dev, "%s: addr = 0x%lx size = 0x%lx\n", __func__, addr, size);
> +
> + if (rproc_elf64_sanity_check(addr, size))
> + return -EINVAL;
> +
> + ehdr = (Elf64_Ehdr *)addr;
> + phdr = (Elf64_Phdr *)(addr + (ulong)ehdr->e_phoff);
> +
> + /* go through the available ELF segments */
> + for (i = 0; i < ehdr->e_phnum; i++, phdr++) {
> + da = phdr->p_paddr;
> + memsz = phdr->p_memsz;
> + filesz = phdr->p_filesz;
> + offset = phdr->p_offset;
> +
> + if (phdr->p_type != PT_LOAD)
> + continue;
> +
> + dev_dbg(dev, "%s:phdr: type %d da 0x%llx memsz 0x%llx filesz 
> 0x%llx\n",
> + __func__, phdr->p_type, da, memsz, filesz);
> +
> + ptr = (void *)(uintptr_t)da;
> + if (ops->device_to_virt) {
> + ptr = ops->device_to_virt(dev, da, phdr->p_memsz);
> + if (!ptr) {
> + dev_err(dev, "bad da 0x%llx mem 0x%llx\n", da,
> + memsz);
> + ret = -EINVAL;
> + break;
> + }
> + }
> +
> + if (filesz)
> + memcpy(ptr, (void *)addr + offset, filesz);
> + if (filesz != memsz)
> + memset(ptr + filesz, 0x00, memsz - filesz);
> +
> + flush_cache(rounddown((ulong)ptr, ARCH_DMA_MINALIGN),
> + roundup((ulong)ptr + filesz, ARCH_DMA_MINALIGN) -
> + rounddown((ulong)ptr, ARCH_DMA_MINALIGN));
> + }
> +
> + return ret;
> +}
> diff --git a/include/remoteproc.h b/include/remoteproc.h
> index 6657b39723..f5d77c8c81 100644
> --- a/include/remoteproc.h
> +++ b/include/remoteproc.h
> @@ -210,6 +210,15 @@ int rproc_is_running(int id);
>* @return 0 if the image is successfully loaded, else appropriate error 
> 

Re: [U-Boot] [PATCH v5 6/7] phy: Add USB PHY driver for the cadence USB3

[Peter Chen]

  
> >
> > This is indeed a different driver. IMO it would be better to keep the
> > driver closer to its linux version. The reason for that  is that it is
> > quite new and will be adapted when platforms starts supporting it. If
> > we start with something too far from the original, it will hard to update.
> > Already I see that the registers initialized are not all the same as
> > in the linux driver and not all the values are the same either, nor
> > are the register names
> >
> > TI's J7 platforms is using this PHY driver for USB3/PCIe support, and
> > the linux driver has already seen quite a few modifications to get it
> > to work
> (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ti.
> > com%2Fti-linux-kernel%2Fti-linux-kernel%2Fblobs%2Fhistory%2Fti-linux-
> > 4.19.y%2Fdrivers%2Fphy%2Fcadence%2Fphy-cadence-
> > sierra.cdata=02%7C01%7Csherry.sun%40nxp.com%7C84f9122d7eb64
> > 9820bae08d72b997681%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0
> > %7C637025810458595586sdata=6JpD7VcFudhzXSVP0WaGVEp7Fwrue
> > A%2B4V6eeOfif19w%3Dreserved=0)
> > Adding support for it on top of this current version will be rather 
> > difficult.
> >
> 
> Thanks for your advice.
> Actually I am not familiar with this phy driver in linux, so also +peter, who 
> worked on
> this USB driver under linux, maybe he can give some suggestions.
> 

Add Alan from Cadence

Alan, we find the suggested value at this driver 
(drivers/phy/cadence/phy-cadence-sierra.c)
is so different with "USB 3.0 PHY User Guide for 28FDSOI" CH 3.1.1 Bring-up 
Sequence.
Does this driver support this 28nm PHY? If it supports, why the initialized 
value is so different?
The UG suggested value can be used at NXP platform.

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

Re: [U-Boot] [PATCH v5 6/7] phy: Add USB PHY driver for the cadence USB3

[Peter Chen]

Hi Pawel,

We are discussing if Cadence/TI/NXP could use the same USB PHY driver
(drivers/phy/cadence/phy-cadence-sierra.c), I find I can't get
Alan Douglas , would you please forward related
people? The question is like below, thanks.

Alan, we find the suggested value at this driver 
(drivers/phy/cadence/phy-cadence-sierra.c)
is so different with "USB 3.0 PHY User Guide for 28FDSOI" CH 3.1.1 Bring-up 
Sequence.
Does this driver support this 28nm PHY? If it supports, why the initialized 
value is so different?
The UG suggested value can be used at NXP platform.

Peter

> > >
> > > This is indeed a different driver. IMO it would be better to keep
> > > the driver closer to its linux version. The reason for that  is that
> > > it is quite new and will be adapted when platforms starts supporting
> > > it. If we start with something too far from the original, it will hard to 
> > > update.
> > > Already I see that the registers initialized are not all the same as
> > > in the linux driver and not all the values are the same either, nor
> > > are the register names
> > >
> > > TI's J7 platforms is using this PHY driver for USB3/PCIe support,
> > > and the linux driver has already seen quite a few modifications to
> > > get it to work
> > (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ti.
> > > com%2Fti-linux-kernel%2Fti-linux-kernel%2Fblobs%2Fhistory%2Fti-linux
> > > -
> > > 4.19.y%2Fdrivers%2Fphy%2Fcadence%2Fphy-cadence-
> > > sierra.cdata=02%7C01%7Csherry.sun%40nxp.com%7C84f9122d7eb64
> > > 9820bae08d72b997681%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0
> > > %7C637025810458595586sdata=6JpD7VcFudhzXSVP0WaGVEp7Fwrue
> > > A%2B4V6eeOfif19w%3Dreserved=0)
> > > Adding support for it on top of this current version will be rather 
> > > difficult.
> > >
> >
> > Thanks for your advice.
> > Actually I am not familiar with this phy driver in linux, so also
> > +peter, who worked on this USB driver under linux, maybe he can give some
> suggestions.
> >
> 
> Add Alan from Cadence
> 
> Alan, we find the suggested value at this driver 
> (drivers/phy/cadence/phy-cadence-
> sierra.c)
> is so different with "USB 3.0 PHY User Guide for 28FDSOI" CH 3.1.1 Bring-up
> Sequence.
> Does this driver support this 28nm PHY? If it supports, why the initialized 
> value is so
> different?
> The UG suggested value can be used at NXP platform.
> 
> Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/4] x86: qemu: Extract getting memory size to a separate routine

[Bin Meng]

This extracts getting memory size logic in dram_init() to a separate
routine qemu_get_low_memory_size(). No functional changes.

Signed-off-by: Bin Meng 
---

 arch/x86/cpu/qemu/dram.c  | 9 +++--
 arch/x86/include/asm/arch-qemu/qemu.h | 7 +++
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/x86/cpu/qemu/dram.c b/arch/x86/cpu/qemu/dram.c
index 736c4c3..c29b073 100644
--- a/arch/x86/cpu/qemu/dram.c
+++ b/arch/x86/cpu/qemu/dram.c
@@ -9,7 +9,7 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-int dram_init(void)
+u32 qemu_get_low_memory_size(void)
 {
u32 ram;
 
@@ -19,7 +19,12 @@ int dram_init(void)
ram |= ((u32)inb(CMOS_DATA_PORT)) << 6;
ram += 16 * 1024;
 
-   gd->ram_size = ram * 1024;
+   return ram * 1024;
+}
+
+int dram_init(void)
+{
+   gd->ram_size = qemu_get_low_memory_size();
post_code(POST_DRAM);
 
return 0;
diff --git a/arch/x86/include/asm/arch-qemu/qemu.h 
b/arch/x86/include/asm/arch-qemu/qemu.h
index 100eb8e..c98deb2 100644
--- a/arch/x86/include/asm/arch-qemu/qemu.h
+++ b/arch/x86/include/asm/arch-qemu/qemu.h
@@ -37,4 +37,11 @@
 #define PMREGMISC  0x80
 #define PMIOSE (1 << 0)
 
+/**
+ * qemu_get_low_memory_size() - Get low memory size
+ *
+ * @return:size of memory below 4GiB
+ */
+u32 qemu_get_low_memory_size(void);
+
 #endif /* _ARCH_QEMU_H_ */
-- 
2.7.4

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

[U-Boot] [PATCH 4/4] x86: qemu: Report high memory in the E820 table

[Bin Meng]

Now that we are able to get the size of high memory from QEMU,
report its memory range as usable ram.

Signed-off-by: Bin Meng 
---

 arch/x86/cpu/qemu/e820.c | 59 
 1 file changed, 40 insertions(+), 19 deletions(-)

diff --git a/arch/x86/cpu/qemu/e820.c b/arch/x86/cpu/qemu/e820.c
index e682486..a4136eb 100644
--- a/arch/x86/cpu/qemu/e820.c
+++ b/arch/x86/cpu/qemu/e820.c
@@ -1,46 +1,67 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
+ * QEMU x86 specific E820 table generation
+ *
  * (C) Copyright 2015 Miao Yan 
+ * (C) Copyright 2019 Bin Meng 
  */
 
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
 unsigned int install_e820_map(unsigned int max_entries,
  struct e820_entry *entries)
 {
-   entries[0].addr = 0;
-   entries[0].size = ISA_START_ADDRESS;
-   entries[0].type = E820_RAM;
+   u64 high_mem_size;
+   int n = 0;
 
-   entries[1].addr = ISA_START_ADDRESS;
-   entries[1].size = ISA_END_ADDRESS - ISA_START_ADDRESS;
-   entries[1].type = E820_RESERVED;
+   entries[n].addr = 0;
+   entries[n].size = ISA_START_ADDRESS;
+   entries[n].type = E820_RAM;
+   n++;
+
+   entries[n].addr = ISA_START_ADDRESS;
+   entries[n].size = ISA_END_ADDRESS - ISA_START_ADDRESS;
+   entries[n].type = E820_RESERVED;
+   n++;
 
/*
 * since we use memalign(malloc) to allocate high memory for
 * storing ACPI tables, we need to reserve them in e820 tables,
 * otherwise kernel will reclaim them and data will be corrupted
 */
-   entries[2].addr = ISA_END_ADDRESS;
-   entries[2].size = gd->relocaddr - TOTAL_MALLOC_LEN - ISA_END_ADDRESS;
-   entries[2].type = E820_RAM;
+   entries[n].addr = ISA_END_ADDRESS;
+   entries[n].size = gd->relocaddr - TOTAL_MALLOC_LEN - ISA_END_ADDRESS;
+   entries[n].type = E820_RAM;
+   n++;
 
/* for simplicity, reserve entire malloc space */
-   entries[3].addr = gd->relocaddr - TOTAL_MALLOC_LEN;
-   entries[3].size = TOTAL_MALLOC_LEN;
-   entries[3].type = E820_RESERVED;
+   entries[n].addr = gd->relocaddr - TOTAL_MALLOC_LEN;
+   entries[n].size = TOTAL_MALLOC_LEN;
+   entries[n].type = E820_RESERVED;
+   n++;
+
+   entries[n].addr = gd->relocaddr;
+   entries[n].size = qemu_get_low_memory_size() - gd->relocaddr;
+   entries[n].type = E820_RESERVED;
+   n++;
 
-   entries[4].addr = gd->relocaddr;
-   entries[4].size = gd->ram_size - gd->relocaddr;
-   entries[4].type = E820_RESERVED;
+   entries[n].addr = CONFIG_PCIE_ECAM_BASE;
+   entries[n].size = CONFIG_PCIE_ECAM_SIZE;
+   entries[n].type = E820_RESERVED;
+   n++;
 
-   entries[5].addr = CONFIG_PCIE_ECAM_BASE;
-   entries[5].size = CONFIG_PCIE_ECAM_SIZE;
-   entries[5].type = E820_RESERVED;
+   high_mem_size = qemu_get_high_memory_size();
+   if (high_mem_size) {
+   entries[n].addr = SZ_4G;
+   entries[n].size = high_mem_size;
+   entries[n].type = E820_RAM;
+   n++;
+   }
 
-   return 6;
+   return n;
 }
-- 
2.7.4

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

[U-Boot] [PATCH 3/4] x86: qemu: Support getting high memory size

[Bin Meng]

At present only size of memory that is below 4GiB is retrieved from
QEMU. Add a function that gets size of memory that is above 4GiB.

Signed-off-by: Bin Meng 
---

 arch/x86/cpu/qemu/dram.c  | 27 +--
 arch/x86/include/asm/arch-qemu/qemu.h | 11 +++
 2 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/arch/x86/cpu/qemu/dram.c b/arch/x86/cpu/qemu/dram.c
index c29b073..6707b7b 100644
--- a/arch/x86/cpu/qemu/dram.c
+++ b/arch/x86/cpu/qemu/dram.c
@@ -22,9 +22,24 @@ u32 qemu_get_low_memory_size(void)
return ram * 1024;
 }
 
+u64 qemu_get_high_memory_size(void)
+{
+   u64 ram;
+
+   outb(HIGH_HIGHRAM_ADDR, CMOS_ADDR_PORT);
+   ram = ((u64)inb(CMOS_DATA_PORT)) << 22;
+   outb(MID_HIGHRAM_ADDR, CMOS_ADDR_PORT);
+   ram |= ((u64)inb(CMOS_DATA_PORT)) << 14;
+   outb(LOW_HIGHRAM_ADDR, CMOS_ADDR_PORT);
+   ram |= ((u64)inb(CMOS_DATA_PORT)) << 6;
+
+   return ram * 1024;
+}
+
 int dram_init(void)
 {
gd->ram_size = qemu_get_low_memory_size();
+   gd->ram_size += qemu_get_high_memory_size();
post_code(POST_DRAM);
 
return 0;
@@ -32,8 +47,16 @@ int dram_init(void)
 
 int dram_init_banksize(void)
 {
+   u64 high_mem_size;
+
gd->bd->bi_dram[0].start = 0;
-   gd->bd->bi_dram[0].size = gd->ram_size;
+   gd->bd->bi_dram[0].size = qemu_get_low_memory_size();
+
+   high_mem_size = qemu_get_high_memory_size();
+   if (high_mem_size) {
+   gd->bd->bi_dram[1].start = SZ_4G;
+   gd->bd->bi_dram[1].size = high_mem_size;
+   }
 
return 0;
 }
@@ -48,5 +71,5 @@ int dram_init_banksize(void)
  */
 ulong board_get_usable_ram_top(ulong total_size)
 {
-   return gd->ram_size;
+   return qemu_get_low_memory_size();
 }
diff --git a/arch/x86/include/asm/arch-qemu/qemu.h 
b/arch/x86/include/asm/arch-qemu/qemu.h
index c98deb2..061735b 100644
--- a/arch/x86/include/asm/arch-qemu/qemu.h
+++ b/arch/x86/include/asm/arch-qemu/qemu.h
@@ -32,6 +32,10 @@
 #define LOW_RAM_ADDR   0x34
 #define HIGH_RAM_ADDR  0x35
 
+#define LOW_HIGHRAM_ADDR   0x5b
+#define MID_HIGHRAM_ADDR   0x5c
+#define HIGH_HIGHRAM_ADDR  0x5d
+
 /* PM registers */
 #define PMBA   0x40
 #define PMREGMISC  0x80
@@ -44,4 +48,11 @@
  */
 u32 qemu_get_low_memory_size(void);
 
+/**
+ * qemu_get_high_memory_size() - Get high memory size
+ *
+ * @return:size of memory above 4GiB
+ */
+u64 qemu_get_high_memory_size(void);
+
 #endif /* _ARCH_QEMU_H_ */
-- 
2.7.4

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

[U-Boot] [PATCH 1/4] x86: Drop weak version board_get_usable_ram_top()

[Bin Meng]

Every x86 platform provides board_get_usable_ram_top(), hence there
is no need to provide a weak version board_get_usable_ram_top(), not
to mention there is another weak version board_get_usable_ram_top()
in common/board_f.c.

Signed-off-by: Bin Meng 
---

 arch/x86/lib/init_helpers.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/arch/x86/lib/init_helpers.c b/arch/x86/lib/init_helpers.c
index 5e19f13..4774a9b 100644
--- a/arch/x86/lib/init_helpers.c
+++ b/arch/x86/lib/init_helpers.c
@@ -10,12 +10,6 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-/* Get the top of usable RAM */
-__weak ulong board_get_usable_ram_top(ulong total_size)
-{
-   return gd->ram_size;
-}
-
 int init_cache_f_r(void)
 {
 #if CONFIG_IS_ENABLED(X86_32BIT_INIT) && !defined(CONFIG_HAVE_FSP) && \
-- 
2.7.4

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

Re: [U-Boot] [PATCH] pico-imx7d: Convert to DM_VIDEO

[Peng Fan]

> Subject: [PATCH] pico-imx7d: Convert to DM_VIDEO

Please write something here.
And use x-u-boot.dtsi for uboot specific dts change.

Regards,
Peng.

> 
> Signed-off-by: Joris Offouga 
> ---
>  arch/arm/dts/imx7d-pico.dtsi | 113
> ++-
>  board/technexion/pico-imx7d/pico-imx7d.c |  48 --
>  configs/pico-hobbit-imx7d_defconfig  |   2 +-
>  configs/pico-imx7d_bl33_defconfig|   2 +-
>  configs/pico-imx7d_defconfig |   2 +-
>  configs/pico-pi-imx7d_defconfig  |   2 +-
>  include/configs/pico-imx7d.h |   2 +-
>  7 files changed, 134 insertions(+), 37 deletions(-)
> 
> diff --git a/arch/arm/dts/imx7d-pico.dtsi b/arch/arm/dts/imx7d-pico.dtsi
> index 7cd8be24c8..ac72baf347 100644
> --- a/arch/arm/dts/imx7d-pico.dtsi
> +++ b/arch/arm/dts/imx7d-pico.dtsi
> @@ -11,6 +11,7 @@
>   aliases {
>   mmc0 = 
>   usb0 = 
> + display0 = 
>   };
> 
>   /* Will be filled by the bootloader */ @@ -75,6 +76,37 @@
>   clocks = < IMX7D_CLKO2_ROOT_DIV>;
>   clock-names = "ext_clock";
>   };
> +
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pinctrl-names = "default";
> + pinctrl-0 = <_backlight>;
> + pwms = < 0 5 0>;
> + brightness-levels = <0 36 72 108 144 180 216 255>;
> + default-brightness-level = <6>;
> + status = "okay";
> + };
> +
> + reg_lcd_3v3: regulator-lcd-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "lcd-3v3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + gpio = < 6 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + panel {
> + compatible = "vxt,vl050-8048nt-c01";
> + backlight = <>;
> + power-supply = <_lcd_3v3>;
> +
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
>  };
> 
>   {
> @@ -98,7 +130,7 @@
> < IMX7D_ENET1_TIME_ROOT_CLK>;
>   assigned-clock-parents = < IMX7D_PLL_ENET_MAIN_100M_CLK>;
>   assigned-clock-rates = <0>, <1>;
> - phy-mode = "rgmii";
> + phy-mode = "rgmii-id";
>   phy-handle = <>;
>   fsl,magic-packet;
>   phy-reset-gpios = < 11 GPIO_ACTIVE_LOW>; @@ -236,6 +268,45
> @@
>   };
>  };
> 
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_lcdif>;
> + status = "okay";
> + display = <>;
> + u-boot,dm-pre-reloc;
> +
> + port {
> + display_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> +
> + display0: display {
> + bits-per-pixel = <16>;
> + bus-width = <24>;
> +
> + display-timings {
> + native-mode = <>;
> + timing0: timing0 {
> + clock-frequency = <3326>;
> + hactive = <800>;
> + vactive = <480>;
> + hback-porch = <11>;
> + hfront-porch = <11>;
> + vback-porch = <12>;
> + vfront-porch = <11>;
> + hsync-len = <46>;
> + vsync-len = <210>;
> + hsync-active = <0>;
> + vsync-active = <0>;
> + de-active = <1>;
> + pixelclk-active = <1>;
> + interlaced =  <0>;
> + };
> + };
> + };
> +};
> +
>   {
>   pinctrl-names = "default";
>   pinctrl-0 = <_sai1>;
> @@ -356,6 +427,12 @@
>  };
> 
>   {
> + pinctrl_backlight: backlight {
> + fsl,pins = <
> + MX7D_PAD_GPIO1_IO11__PWM4_OUT   0x0
> + >;
> + };
> +
>   pinctrl_ecspi3: ecspi3grp {
>   fsl,pins = <
>   MX7D_PAD_I2C1_SCL__ECSPI3_MISO  0x2
> @@ -420,6 +497,40 @@
>   >;
>   };
> 
> + pinctrl_lcdif: lcdifgrp {
> + fsl,pins = <
> + MX7D_PAD_LCD_DATA00__LCD_DATA0  0x79
> + MX7D_PAD_LCD_DATA01__LCD_DATA1  0x79
> + MX7D_PAD_LCD_DATA02__LCD_DATA2  0x79
> + MX7D_PAD_LCD_DATA03__LCD_DATA3  0x79
> + MX7D_PAD_LCD_DATA04__LCD_DATA4  0x79
> + MX7D_PAD_LCD_DATA05__LCD_DATA5  0x79
> + MX7D_PAD_LCD_DATA06__LCD_DATA6  0x79
> + MX7D_PAD_LCD_DATA07__LCD_DATA7  0x79
> + 

Re: [U-Boot] [PATCH] mmc: dw_mmc: fix timeout calculate method

[Alexey Brodkin]

Hi Kever,

> -Original Message-
> From: Kever Yang 
> Sent: Thursday, August 29, 2019 10:17 AM
> To: Peng Fan ; u-boot@lists.denx.de
> Cc: tr...@konsulko.com; eugeniy.palt...@synopsys.com; Alexey Brodkin 
> ; Simon
> Glass 
> Subject: Re: [PATCH] mmc: dw_mmc: fix timeout calculate method
> 
> Add ARC maintainers.

Thanks for adding us in the loop.

> On 2019/8/27 下午5:58, Peng Fan wrote:
> > Hi Kever,
> >
> >> -Original Message-
> >> From: U-Boot  On Behalf Of Peng Fan
> >> Sent: 2019年8月27日 15:40
> >> To: Kever Yang ; u-boot@lists.denx.de
> >> Cc: tr...@konsulko.com
> >> Subject: Re: [U-Boot] [PATCH] mmc: dw_mmc: fix timeout calculate method
> >>
> >>> Subject: [PATCH] mmc: dw_mmc: fix timeout calculate method
> >>>
> >>> There are two cases not been considered:
> >>> - use uint for timeout, it will overflow when size bigger than 512KB for
> >>>it *8*1000 at the beginning, but we may use size up to 32MB;
> >>> - The timeout is using clock speed for data rate, but the device may not
> >>>have such high speed, eg. clock is 52MHz while the device write speed
> >> may
> >>>be less than 10MB/s.
> >>>
> >>> Fix them in this patch, the max timeout is about 6500 when size is
> >>> 32MB after fix.
> >>>
> >>> Signed-off-by: Kever Yang 
> > This patch breaks build, I need drop it.
> > See build:
> > https://travis-ci.org/MrVan/u-boot/jobs/577210464
>
> The error happens only in ARC architecture, and seems like the arc
> compiler not support 64bit div?

It's not a compiler problem but a subtle issue with libgcc.
To be independent from toolchain type (and we have quite a few flavors like
little- and big-endian, ARCv1 or ARCv2 etc) decision was made to move
libgcc into U-Boot but given full libgcc is quite large only primitives required
by up-to-date U-Boot were copied from GCC to U-Boot.

> Any idea on how to fix this?

Add missing primitives like __udivdi3() and their dependencies, see for example:
https://github.com/gcc-mirror/gcc/blob/master/libgcc/libgcc2.c#L1318.

And I'll happily do it myself but for some reason I cannot reproduce that 
problem locally.
I use the same pre-built arc-2018.09 toolchain:
>8---
# arc-linux-gcc -v
gcc version 8.2.1 20180814 (ARCv2 ISA Linux uClibc toolchain 2018.09)
>8---

And may successfully build U-Boot for HSDK from
https://github.com/MrVan/u-boot/commits/mmc-8-28-2019:
>8---
# git l
76c0bf2873 - (HEAD -> mrvan, github-mrvan/mmc-8-28-2019) ARM: dts: ast2500: Add 
SDHCI nodes (27 hours ago) 
07b000cd32 - configs: AST2500 EVB: Enable SD controller (27 hours ago) 
5f6a033f10 - mmc: Add Aspeed SD controller driver (27 hours ago) 
a6503eaa66 - clk: aspeed: Add support for SD clock (27 hours ago) 
c54e328452 - mmc: Rename timeout parameters for clarification (27 hours ago) 

be949bb19c - mmc: Fix timeout values passed to mmc_wait_dat0() (27 hours ago) 

49842f0edf - dm: mmc: remove unused U_BOOT_DRIVER(mmc) (27 hours ago) 
7b91b47f8f - Prepare v2019.10-rc3 (27 hours ago) 
>8---

That way:
>8---
./tools/buildman/buildman hsdk
boards.cfg is up to date. Nothing to do.
Building current source for 1 boards (1 thread, 48 jobs per thread)
   arc:  w+   hsdk
010 /1  hsdk
>8---

What do I do wrong?

-Alexey


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

Re: [U-Boot] What can cause gpio_request return negative value

[Nemanja Savic]

This is solved. Namely, I called gpio_request from checkboard function, and
it seems like at that point it is not possible to use gpios. When I moved
my code to board_init it started working fine.

On Thu, Aug 15, 2019 at 4:18 PM Nemanja Savic  wrote:

> And to be more precise inside gpio-uclass.c, the function gpio_to_device
> which is called by gpio_request loops through all gpio objects in order to
> search for the gpio number provided never loops in my case.
>
> puts("gpio-uclass");
> for (ret = uclass_first_device(UCLASS_GPIO, ); dev; ret =
> uclass_next_device()) {
> puts("gpio-uclass loop\n");
> ...
>
> puts inside loop is never executed, that's why I asked if I should maybe
> first declare GPIOs to the system via device tree.
>
> On Thu, Aug 15, 2019 at 4:05 PM Nemanja Savic  wrote:
>
>> It return -2 which should be -ENOENT. In the comment at the end of
>> gpio_to_device() it is written "No such GPIO".
>> Are there any prerequisites before calling gpio_request regarding device
>> tree or something else?
>>
>> On Thu, Aug 15, 2019 at 3:09 PM Adam Ford  wrote:
>>
>>> On Thu, Aug 15, 2019 at 7:46 AM Nemanja Savic 
>>> wrote:
>>> >
>>> > Hi all,
>>> >
>>> > I am struggling with porting our old board init code for a sabre auto
>>> based
>>> > custom board with i.MX6 DualLite processor. The code used to work in
>>> our
>>> > older u-boot version, but what I saw in mx6qsabreauto.c is that the new
>>> > style is by using new driver model which means the gpio should be first
>>> > requested. However gpio_request returns negative value in my case.
>>> Where
>>> > could the problem be? As far as I could see our device tree doesn't
>>> reserve
>>> > this pin for other purpose. It is even not mentioned there. The only
>>> thing
>>> > related to those pins are iomux pin definitions in the device tree but
>>> > removing that doesn't help at all. Also device tree for the Sabre Auto
>>> > board doesn't mention gpio pins that they use in their u-boot. I am
>>> dealing
>>> > with 2017.03 version of u-boot.
>>>
>>> Do you know what the negative value is?  include/linux/errno.h  should
>>> have a list of error numbers which should correlate to the error
>>> you're seeing.  That should also tell you what the error means.  From
>>> there, you should be able to search the code for where that error
>>> might return.
>>>
>>> adam
>>> > ___
>>> > U-Boot mailing list
>>> > U-Boot@lists.denx.de
>>> > https://lists.denx.de/listinfo/u-boot
>>>
>>
>>
>> --
>> Nemanja Savić
>>
>
>
> --
> Nemanja Savić
>


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

[U-Boot] [PATCH] pico-imx7d: Convert to DM_VIDEO

[Joris Offouga]

Signed-off-by: Joris Offouga 
---
 arch/arm/dts/imx7d-pico.dtsi | 113 ++-
 board/technexion/pico-imx7d/pico-imx7d.c |  48 --
 configs/pico-hobbit-imx7d_defconfig  |   2 +-
 configs/pico-imx7d_bl33_defconfig|   2 +-
 configs/pico-imx7d_defconfig |   2 +-
 configs/pico-pi-imx7d_defconfig  |   2 +-
 include/configs/pico-imx7d.h |   2 +-
 7 files changed, 134 insertions(+), 37 deletions(-)

diff --git a/arch/arm/dts/imx7d-pico.dtsi b/arch/arm/dts/imx7d-pico.dtsi
index 7cd8be24c8..ac72baf347 100644
--- a/arch/arm/dts/imx7d-pico.dtsi
+++ b/arch/arm/dts/imx7d-pico.dtsi
@@ -11,6 +11,7 @@
aliases {
mmc0 = 
usb0 = 
+   display0 = 
};
 
/* Will be filled by the bootloader */
@@ -75,6 +76,37 @@
clocks = < IMX7D_CLKO2_ROOT_DIV>;
clock-names = "ext_clock";
};
+
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pinctrl-names = "default";
+   pinctrl-0 = <_backlight>;
+   pwms = < 0 5 0>;
+   brightness-levels = <0 36 72 108 144 180 216 255>;
+   default-brightness-level = <6>;
+   status = "okay";
+   };
+
+   reg_lcd_3v3: regulator-lcd-3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "lcd-3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = < 6 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   panel {
+   compatible = "vxt,vl050-8048nt-c01";
+   backlight = <>;
+   power-supply = <_lcd_3v3>;
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
 };
 
  {
@@ -98,7 +130,7 @@
  < IMX7D_ENET1_TIME_ROOT_CLK>;
assigned-clock-parents = < IMX7D_PLL_ENET_MAIN_100M_CLK>;
assigned-clock-rates = <0>, <1>;
-   phy-mode = "rgmii";
+   phy-mode = "rgmii-id";
phy-handle = <>;
fsl,magic-packet;
phy-reset-gpios = < 11 GPIO_ACTIVE_LOW>;
@@ -236,6 +268,45 @@
};
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_lcdif>;
+   status = "okay";
+   display = <>;
+   u-boot,dm-pre-reloc;
+
+   port {
+   display_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+
+   display0: display {
+   bits-per-pixel = <16>;
+   bus-width = <24>;
+
+   display-timings {
+   native-mode = <>;
+   timing0: timing0 {
+   clock-frequency = <3326>;
+   hactive = <800>;
+   vactive = <480>;
+   hback-porch = <11>;
+   hfront-porch = <11>;
+   vback-porch = <12>;
+   vfront-porch = <11>;
+   hsync-len = <46>;
+   vsync-len = <210>;
+   hsync-active = <0>;
+   vsync-active = <0>;
+   de-active = <1>;
+   pixelclk-active = <1>;
+   interlaced =  <0>;
+   };
+   };
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_sai1>;
@@ -356,6 +427,12 @@
 };
 
  {
+   pinctrl_backlight: backlight {
+   fsl,pins = <
+   MX7D_PAD_GPIO1_IO11__PWM4_OUT   0x0
+   >;
+   };
+
pinctrl_ecspi3: ecspi3grp {
fsl,pins = <
MX7D_PAD_I2C1_SCL__ECSPI3_MISO  0x2
@@ -420,6 +497,40 @@
>;
};
 
+   pinctrl_lcdif: lcdifgrp {
+   fsl,pins = <
+   MX7D_PAD_LCD_DATA00__LCD_DATA0  0x79
+   MX7D_PAD_LCD_DATA01__LCD_DATA1  0x79
+   MX7D_PAD_LCD_DATA02__LCD_DATA2  0x79
+   MX7D_PAD_LCD_DATA03__LCD_DATA3  0x79
+   MX7D_PAD_LCD_DATA04__LCD_DATA4  0x79
+   MX7D_PAD_LCD_DATA05__LCD_DATA5  0x79
+   MX7D_PAD_LCD_DATA06__LCD_DATA6  0x79
+   MX7D_PAD_LCD_DATA07__LCD_DATA7  0x79
+   MX7D_PAD_LCD_DATA08__LCD_DATA8  0x79
+   MX7D_PAD_LCD_DATA09__LCD_DATA9  0x79
+   MX7D_PAD_LCD_DATA10__LCD_DATA10 0x79
+   MX7D_PAD_LCD_DATA11__LCD_DATA11 

[U-Boot] [PATCH] arc: emsdp: Add initialization of PSRAM

[Alexey Brodkin]

If the "Page Mode" is not enabled on the device,
read operations from PSRAM may result in incorrect data.

Signed-off-by: Alexey Brodkin 
---
 board/synopsys/emsdp/emsdp.c | 37 +
 configs/emsdp_defconfig  |  1 +
 2 files changed, 38 insertions(+)

diff --git a/board/synopsys/emsdp/emsdp.c b/board/synopsys/emsdp/emsdp.c
index c0770b58c1..3bf4a1879b 100644
--- a/board/synopsys/emsdp/emsdp.c
+++ b/board/synopsys/emsdp/emsdp.c
@@ -48,6 +48,43 @@ int mach_cpu_init(void)
return 0;
 }
 
+int board_early_init_r(void)
+{
+#define EMSDP_PSRAM_BASE   0xf2001000
+#define PSRAM_FLASH_CONFIG_REG_0   (void *)(EMSDP_PSRAM_BASE + 0x10)
+#define PSRAM_FLASH_CONFIG_REG_1   (void *)(EMSDP_PSRAM_BASE + 0x14)
+#define CRE_ENABLE BIT(31)
+#define CRE_DRIVE_CMD  BIT(6)
+
+#define PSRAM_RCR_DPD  BIT(4)
+#define PSRAM_RCR_PAGE_MODEBIT(7)
+
+/*
+ * PSRAM_FLASH_CONFIG_REG_x[30:15] to the address lines[16:1] of flash,
+ * thus "<< 1".
+ */
+#define PSRAM_RCR_SETUP((PSRAM_RCR_DPD | PSRAM_RCR_PAGE_MODE) 
<< 1)
+
+   // Switch PSRAM controller to command mode
+   writel(CRE_ENABLE | CRE_DRIVE_CMD, PSRAM_FLASH_CONFIG_REG_0);
+   // Program Refresh Configuration Register (RCR) for BANK0
+   writew(0, (void *)(0x1000 + PSRAM_RCR_SETUP));
+   // Switch PSRAM controller back to memory mode
+   writel(0, PSRAM_FLASH_CONFIG_REG_0);
+
+
+   // Switch PSRAM controller to command mode
+   writel(CRE_ENABLE | CRE_DRIVE_CMD, PSRAM_FLASH_CONFIG_REG_1);
+   // Program Refresh Configuration Register (RCR) for BANK1
+   writew(0, (void *)(0x1080 + PSRAM_RCR_SETUP));
+   // Switch PSRAM controller back to memory mode
+   writel(0, PSRAM_FLASH_CONFIG_REG_1);
+
+   printf("PSRAM initialized.\n");
+
+   return 0;
+}
+
 int board_mmc_init(bd_t *bis)
 {
struct dwmci_host *host = NULL;
diff --git a/configs/emsdp_defconfig b/configs/emsdp_defconfig
index 64281d0529..5e55e3e2b2 100644
--- a/configs/emsdp_defconfig
+++ b/configs/emsdp_defconfig
@@ -7,6 +7,7 @@ CONFIG_ENV_SIZE=0x1000
 CONFIG_SYS_CLK_FREQ=4000
 # CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
 CONFIG_VERSION_VARIABLE=y
+CONFIG_BOARD_EARLY_INIT_R=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="emsdp# "
 # CONFIG_CMD_BOOTD is not set
-- 
2.16.2

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

Re: [U-Boot] Travis test/py sandbox_spl test fail【请注意，邮件由s...@google.com代发】

[Kever Yang]

On 2019/8/24 下午12:19, Simon Glass wrote:

Hi Kever,

On Mon, 19 Aug 2019 at 19:53, Kever Yang  wrote:

Hi Stephen,

On 2019/8/20 上午1:34, Stephen Warren wrote:

On 8/18/19 7:01 PM, Kever Yang wrote:

Hi Simon, Stephen,

  Could you help to comment on my other mail, which patch cause
this failure.

If you run "git bisect", you should be able to track down which patch
introduced the problem.


I already locate the patch,  and it seems some but in sandbox_spl or
test, but not the driver,

see below:

https://patchwork.ozlabs.org/patch/1100742/

Here's what I found:

$ gdb --args /tmp/b/sandbox_spl/u-boot -D
GNU gdb (Debian 8.1-4+build1) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /tmp/b/sandbox_spl/u-boot...done.
(gdb) r
Starting program: /tmp/b/sandbox_spl/u-boot -D
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
bloblist_init() Existing bloblist not found: creating new bloblist

Program received signal SIGSEGV, Segmentation fault.
0x55617db5 in strcmp (cs=cs@entry=0x556602cf "root_driver",
 ct=0x1 )
 at /home/sjg/c/src/third_party/u-boot/files/lib/string.c:190
190 if ((__res = *cs - *ct++) != 0 || !*cs++)
(gdb) up
#1  0x555a9f91 in lists_driver_lookup_name
(name=0x556602cf "root_driver")
 at /home/sjg/c/src/third_party/u-boot/files/drivers/core/lists.c:28
28 if (!strcmp(name, entry->name))
(gdb) print entry->name
$1 = 0x0
(gdb) print *entry
$2 = {name = 0x0, id = UCLASS_ROOT, of_match = 0x0, bind =
0x5569b660, probe = 0x3e,
   remove = 0x556fd1e0 , unbind = 0x555d0ad6 ,
   ofdata_to_platdata = 0x555d0a77 , child_post_bind =
0x0, child_pre_probe = 0x0,
   child_post_remove = 0x0, priv_auto_alloc_size = 0,
platdata_auto_alloc_size = 0,
   per_child_auto_alloc_size = 0, per_child_platdata_auto_alloc_size =
0, ops = 0x0, flags = 4}


Here you have a rockchip driver in UCLASS_ROOT with no name.

The symbol is _u_boot_list_2_driver_2_pmic_rk8xx so perhaps it is
getting corrupted?



But I don't understand how this corrupt happen, does this area should be 
RO data?
When I compare the good case and error case, I got below difference, the 
'fill' data

only present at error case, does it suppose to be there?

 .u_boot_list_2_driver_2_pmic_pm8916
    0x003b14f0   0x78 drivers/power/pmic/built-in.o
    0x003b14f0 _u_boot_list_2_driver_2_pmic_pm8916
 *fill* 0x003b1568 0x18
 .u_boot_list_2_driver_2_pmic_rk8xx
    0x003b1580   0x78 drivers/power/pmic/built-in.o
    0x003b1580 _u_boot_list_2_driver_2_pmic_rk8xx


Thanks,
- Kever


(gdb) where
#0  0x55617db5 in strcmp (cs=cs@entry=0x556602cf "root_driver",
 ct=0x1 )
 at /home/sjg/c/src/third_party/u-boot/files/lib/string.c:190
#1  0x555a9f91 in lists_driver_lookup_name
(name=0x556602cf "root_driver")
 at /home/sjg/c/src/third_party/u-boot/files/drivers/core/lists.c:28
#2  0x555a9561 in device_bind_by_name (parent=parent@entry=0x0,
 pre_reloc_only=pre_reloc_only@entry=false,
info=info@entry=0x556fa560 ,
 devp=0x7fffdd08) at
/home/sjg/c/src/third_party/u-boot/files/drivers/core/device.c:250
#3  0x555aa423 in dm_init (of_live=)
 at /home/sjg/c/src/third_party/u-boot/files/drivers/core/root.c:148
#4  0x555aa558 in dm_init_and_scan
(pre_reloc_only=pre_reloc_only@entry=true)
 at /home/sjg/c/src/third_party/u-boot/files/drivers/core/root.c:373
#5  0x5559381a in initf_dm () at
/home/sjg/c/src/third_party/u-boot/files/common/board_f.c:807
#6  0x5559395a in initcall_run_list
(init_sequence=0x556fe840 )
 at /home/sjg/c/src/third_party/u-boot/files/include/initcall.h:38
#7  board_init_f (boot_flags=)
 at /home/sjg/c/src/third_party/u-boot/files/common/board_f.c:986
#8  0x555774d6 in main (argc=2, argv=0x7fffdf58)
 at /home/sjg/c/src/third_party/u-boot/files/arch/sandbox/cpu/start.c:360
(gdb) q



Regards,
Simon


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

Re: [U-Boot] [PATCH v1] pci: add DM based mpc85xx driver

[Z.q. Hou]

Hi Heiko,

> -Original Message-
> From: Heiko Schocher 
> Sent: 2019年7月16日 11:36
> To: u-boot@lists.denx.de
> Cc: Heiko Schocher ; Alexander Graf ;
> Andrew F. Davis ; Xiaowei Bao ; Bin
> Meng ; Eugen Hristev
> ; Heinrich Schuchardt
> ; Horatiu Vultur ;
> Z.q. Hou ; Krzysztof Kozlowski ;
> Liviu Dudau ; Marek Vasut
> ; Mario Six ; Michal Simek
> ; Neil Armstrong ;
> Prabhakar Kushwaha ; Ryder Lee
> ; Simon Glass ; Stefan
> Roese 
> Subject: [PATCH v1] pci: add DM based mpc85xx driver
> 
> add DM based PCI Configuration space access support for MPC85xx PCI
> Bridge

Seems you're converting the arch/powerpc/cpu/mpc85xx/pci.c to driver model,
but not every mpc85xx platform uses this driver, platforms mpc8536, 8544,
8548 and 8568 use the drivers/pci/fsl_pci_init.c, please take them into account.

Note: The platforms using arch/powerpc/cpu/mpc85xx/pci.c set up PCI LAWs in
file arch/powerpc/cpu/mpc8xxx/law.c, while other platforms set up PCI LAWs in
PCI driver. So I think you can move the PCI LAWs set-up into this DM PCI driver
And remove the PCI entries from law.c.

> 
> Signed-off-by: Heiko Schocher 
> 
> ---
> Travis build, see:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftravis
> -ci.org%2Fhsdenx%2Fu-boot-test%2Fbuilds%2F558855544data=02%7
> C01%7CZhiqiang.Hou%40nxp.com%7C231ac8975b2242ea5bfb08d7099eccc
> 8%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63698844995746
> 0734sdata=lQcXtvh5a0G9r%2BFlXnnGQ5VgDYvcR%2FEGWpShJ324su
> U%3Dreserved=0
> 
>  MAINTAINERS   |   5 ++
>  drivers/pci/Kconfig   |   7 ++
>  drivers/pci/Makefile  |   1 +
>  drivers/pci/pci_mpc85xx.c | 132
> ++
>  4 files changed, 145 insertions(+)
>  create mode 100644 drivers/pci/pci_mpc85xx.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e91684191f..01faa67a6d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -639,6 +639,11 @@ S:   Maintained
>  F:   drivers/pci_endpoint/
>  F:  include/pci_ep.h
> 
> +PCI MPC85xx
> +M:   Heiko Schocher 
> +S:   Maintained
> +F:   drivers/pci/pci_mpc85xx.c
> +
>  POWER
>  M:   Jaehoon Chung 
>  S:   Maintained
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig index
> 3fe38f7315..88db0067b4 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -68,6 +68,13 @@ config PCIE_FSL
> PowerPC MPC85xx, MPC86xx, B series, P series and T series SoCs.
> This driver does not support SRIO_PCIE_BOOT feature.
> 
> +config PCI_MPC85XX
> + bool "MPC85XX PowerPC PCI support"
> + depends on DM_PCI
> + help
> +   Say Y here if you want to enable PCI controller support on FSL
> +   PowerPC MPC85xx SoC.
> +
>  config PCI_RCAR_GEN2
>   bool "Renesas RCar Gen2 PCIe driver"
>   depends on DM_PCI
> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile index
> b5ebd50c85..929f119fb3 100644
> --- a/drivers/pci/Makefile
> +++ b/drivers/pci/Makefile
> @@ -19,6 +19,7 @@ obj-$(CONFIG_PCIE_ECAM_GENERIC) +=
> pcie_ecam_generic.o
>  obj-$(CONFIG_FSL_PCI_INIT) += fsl_pci_init.o
>  obj-$(CONFIG_PCI_INDIRECT_BRIDGE) += pci_indirect.o
>  obj-$(CONFIG_PCI_GT64120) += pci_gt64120.o
> +obj-$(CONFIG_PCI_MPC85XX) += pci_mpc85xx.o
>  obj-$(CONFIG_PCI_MSC01) += pci_msc01.o
>  obj-$(CONFIG_PCIE_IMX) += pcie_imx.o
>  obj-$(CONFIG_FTPCI100) += pci_ftpci100.o diff --git
> a/drivers/pci/pci_mpc85xx.c b/drivers/pci/pci_mpc85xx.c new file mode
> 100644 index 00..c0d35f7f2c
> --- /dev/null
> +++ b/drivers/pci/pci_mpc85xx.c
> @@ -0,0 +1,132 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * (C) Copyright 2019
> + * Heiko Schocher, DENX Software Engineering, h...@denx.de.
> + *
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct mpc85xx_pci_priv {
> + void __iomem*cfg_addr;
> + void __iomem*cfg_data;
> +};
> +
> +static int mpc85xx_pci_dm_read_config(struct udevice *dev, pci_dev_t bdf,
> +   uint offset, ulong *value,
> +   enum pci_size_t size)
> +{
> + struct mpc85xx_pci_priv *priv = dev_get_priv(dev);
> + u32 addr;
> +
> + addr = bdf | (offset & 0xfc) | ((offset & 0xf00) << 16) | 0x8000;
> + out_be32(priv->cfg_addr, addr);
> + sync();
> + *value = pci_conv_32_to_size(in_le32(priv->cfg_data), offset, size);
> +
> + return 0;
> +}
> +
> +static int mpc85xx_pci_dm_write_config(struct udevice *dev, pci_dev_t
> bdf,
> +uint offset, ulong value,
> +enum pci_size_t size)
> +{
> + struct mpc85xx_pci_priv *priv = dev_get_priv(dev);
> + u32 addr;
> +
> + addr = bdf | (offset & 0xfc) | ((offset & 0xf00) << 16) | 0x8000;
> + out_be32(priv->cfg_addr, addr);
> + sync();
> + out_le32(priv->cfg_data, pci_conv_size_to_32(0, value, offset, size));
> +
> + return 0;
> +}
> +
> +static int mpc85xx_pci_dm_probe(struct udevice *dev) {
> + struct 

[U-Boot] [PATCH v2] mmc: dw_mmc: fix timeout calculate method

[Kever Yang]

There are two cases not been considered:
- use uint for timeout, it will overflow when size bigger than 512KB for
  it *8*1000 at the beginning, but we may use size up to 32MB; The
  'timeout' will overflow if size bigger than 51.2MB after this fix, which
  should be enough for U-Boot;
- The timeout is using clock speed for data rate, but the device may not
  have such high speed, eg. clock is 52MHz while the device write speed may
  be less than 10MB/s, and we may use up to 150MHz clock.

Fix them in this patch, the max timeout is about 6500 when size is 32MB
after fix.

Signed-off-by: Kever Yang 
---

Changes in v2:
- use u32 instead of u64 to fix undefined reference to `__udivdi3' in
  arc architecure.

 drivers/mmc/dw_mmc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 22f6c7eefd..ebe7bcdd90 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -119,11 +119,12 @@ static unsigned int dwmci_get_timeout(struct mmc *mmc, 
const unsigned int size)
 {
unsigned int timeout;
 
-   timeout = size * 8 * 1000;  /* counting in bits and msec */
-   timeout *= 2;   /* wait twice as long */
+   timeout = size * 8; /* counting in bits */
+   timeout *= 10;  /* wait 10 times as long */
timeout /= mmc->clock;
timeout /= mmc->bus_width;
timeout /= mmc->ddr_mode ? 2 : 1;
+   timeout *= 1000;/* counting in msec */
timeout = (timeout < 1000) ? 1000 : timeout;
 
return timeout;
-- 
2.17.1

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

Re: [U-Boot] [PATCH] mmc: dw_mmc: fix timeout calculate method

[Kever Yang]

Add ARC maintainers.


On 2019/8/27 下午5:58, Peng Fan wrote:

Hi Kever,


-Original Message-
From: U-Boot  On Behalf Of Peng Fan
Sent: 2019年8月27日 15:40
To: Kever Yang ; u-boot@lists.denx.de
Cc: tr...@konsulko.com
Subject: Re: [U-Boot] [PATCH] mmc: dw_mmc: fix timeout calculate method


Subject: [PATCH] mmc: dw_mmc: fix timeout calculate method

There are two cases not been considered:
- use uint for timeout, it will overflow when size bigger than 512KB for
   it *8*1000 at the beginning, but we may use size up to 32MB;
- The timeout is using clock speed for data rate, but the device may not
   have such high speed, eg. clock is 52MHz while the device write speed

may

   be less than 10MB/s.

Fix them in this patch, the max timeout is about 6500 when size is
32MB after fix.

Signed-off-by: Kever Yang 

This patch breaks build, I need drop it.
See build:
https://travis-ci.org/MrVan/u-boot/jobs/577210464
The error happens only in ARC architecture, and seems like the arc 
compiler not support


64bit div?

Any idea on how to fix this?


Thanks,
- Kever


Regards,
Peng.


Applied to mmc/master.

Thanks,
Peng.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.d
enx.de%2Flistinfo%2Fu-bootdata=02%7C01%7CPeng.Fan%40nxp.com
%7Cec929026da5f42951b6108d72ac1c446%7C686ea1d3bc2b4c6fa92cd99c
5c301635%7C0%7C0%7C637024884027193189sdata=SPBna8IBqgpo9
%2F6ab1YO5sbpX6NGgkCowt0oLclRHEk%3Dreserved=0



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

Re: [U-Boot] toolchain for riscv?

[Rick Chen]

Hi Hannes

> > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Hannes
> > Schmelzer
> > Sent: Thursday, August 22, 2019 6:21 PM
> > To: U-Boot Mailing List
> > Subject: [U-Boot] toolchain for riscv?
> >
> > hi,
> >
> > just tried to run moveconfig.py, having trouble to find the toolchain for
> > "riscv".
> >
> > I already did run "tools/buildman/buildman.py --fetch-arch=all", but no
> > toolchain for riscv was downloaded.
> >
> > where to get correct toolchain?

You can download from
https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/

B.R
Rick

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

[U-Boot] Pull request for UEFI sub-system for v2019.10-rc4

[Heinrich Schuchardt]

The following changes since commit e4b8dd9b34021241cd05d5cc9d24b4ae34657830:

  Merge https://gitlab.denx.de/u-boot/custodians/u-boot-mpc85xx
(2019-08-27 07:11:37 -0400)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git
tags/efi-2019-10-rc4

for you to fetch changes up to 53c701720c3d5e5ae107454ea9b9f680bc399006:

  efi_selftest: use standalone UEFI program for exception (2019-08-29
05:54:26 +0200)

No errors were reported by Gitlab.

Primary key fingerprint:
6DC4 F9C7 1F29 A6FA 06B7  6D33 C481 DBBC 2C05 1AC4


Pull request for UEFI sub-system for v2019.10-rc4

Enable the unit test for UEFI runtime service Exit() on x86_64.
Use as standalone UEFI binary for testing the handling of exceptions.


Heinrich Schuchardt (2):
  efi_selftest: enable Exit() unit test on x86_64
  efi_selftest: use standalone UEFI program for exception

 lib/efi_selftest/Makefile |  16 ++-
 lib/efi_selftest/efi_selftest_exception.c | 141
++
 lib/efi_selftest/efi_selftest_miniapp_exception.c |  41 +++
 3 files changed, 172 insertions(+), 26 deletions(-)
 create mode 100644 lib/efi_selftest/efi_selftest_miniapp_exception.c
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] x86: efi_loader: Fix invalid address return from efi_alloc()

[Bin Meng]

Hi Heinrich,

On Thu, Aug 29, 2019 at 1:25 PM Heinrich Schuchardt  wrote:
>
> On 8/29/19 7:04 AM, Bin Meng wrote:
> > Hi Aiden,
> >
> > On Thu, Aug 29, 2019 at 12:02 PM Park, Aiden  wrote:
> >>
> >> Hi Bin,
> >>
> >>> -Original Message-
> >>> From: Bin Meng [mailto:bmeng...@gmail.com]
> >>> Sent: Wednesday, August 28, 2019 8:37 PM
> >>> To: Park, Aiden ; Heinrich Schuchardt
> >>> 
> >>> Cc: Simon Glass ; u-boot@lists.denx.de
> >>> Subject: Re: [PATCH 1/1] x86: efi_loader: Fix invalid address return from
> >>> efi_alloc()
> >>>
> >>> +Heinrich,
> >>>
> >>> On Wed, Aug 28, 2019 at 2:35 AM Park, Aiden  wrote:
> 
>  This issue can be seen on 32bit operation when one of E820_RAM type
>  entries is greater than 4GB memory space.
> 
>  The efi_alloc() finds a free memory in the conventional memory which
>  is greater than 4GB. But, it does type cast to 32bit address space and
>  eventually returns invalid address.
> 
>  Signed-off-by: Aiden Park 
>  ---
>    arch/x86/lib/e820.c | 22 +-
>    1 file changed, 21 insertions(+), 1 deletion(-)
> 
>  diff --git a/arch/x86/lib/e820.c b/arch/x86/lib/e820.c index
>  d6ae2c4e9d..3e93931231 100644
>  --- a/arch/x86/lib/e820.c
>  +++ b/arch/x86/lib/e820.c
>  @@ -41,11 +41,15 @@ void efi_add_known_memory(void)  {
>   struct e820_entry e820[E820MAX];
>   unsigned int i, num;
>  -   u64 start, pages;
>  +   u64 start, pages, ram_top;
>   int type;
> 
>   num = install_e820_map(ARRAY_SIZE(e820), e820);
> 
>  +   ram_top = (u64)gd->ram_top & ~EFI_PAGE_MASK;
>  +   if (!ram_top)
> >>>
> >>> So for the logic here to work, gd->ram_top is already zero in 32-bit, 
> >>> right? I was
> >>> wondering how U-Boot could boot on such target?
> >>>
> >> The efi_add_known_memory() in lib/efi_loader/efi_memory.c covers this case.
> >>
>  +   ram_top = 0x1ULL;
>  +
>   for (i = 0; i < num; ++i) {
>   start = e820[i].addr;
>   pages = ALIGN(e820[i].size, EFI_PAGE_SIZE) >>
>  EFI_PAGE_SHIFT; @@ -70,6 +74,22 @@ void efi_add_known_memory(void)
>   }
> 
>   efi_add_memory_map(start, pages, type, false);
>  +
>  +   if (type == EFI_CONVENTIONAL_MEMORY) {
>  +   u64 end = start + (pages << EFI_PAGE_SHIFT);
>  +
>  +   /* reserve the memory region greater than 
>  ram_top */
>  +   if (ram_top < start) {
>  +   efi_add_memory_map(start, pages,
>  +  
>  EFI_BOOT_SERVICES_DATA,
>  +  true);
> >>>
> >>> Heinrich, could you please review the changes here?
> >>>
>  +   } else if (start < ram_top && ram_top < end) {
>  +   pages = (end - ram_top) >> 
>  EFI_PAGE_SHIFT;
>  +   efi_add_memory_map(ram_top, pages,
>  +  
>  EFI_BOOT_SERVICES_DATA,
>  +  true);
>  +   }
>  +   }
>   }
>    }
>    #endif /* CONFIG_IS_ENABLED(EFI_LOADER) */
>  --
> >>>
> >>> Regards,
> >>> Bin
> >>
> >> I have replicated this issue with qemu-x86_defconfig as below.
> >>
> >> diff --git a/arch/x86/cpu/qemu/e820.c b/arch/x86/cpu/qemu/e820.c
> >> index e682486547..7e5ae38c07 100644
> >> --- a/arch/x86/cpu/qemu/e820.c
> >> +++ b/arch/x86/cpu/qemu/e820.c
> >> @@ -42,5 +42,9 @@ unsigned int install_e820_map(unsigned int max_entries,
> >>  entries[5].size = CONFIG_PCIE_ECAM_SIZE;
> >>  entries[5].type = E820_RESERVED;
> >>
> >> -   return 6;
> >> +   entries[6].addr = 0x1ULL;
> >> +   entries[6].size = 0x1ULL;
> >> +   entries[6].type = E820_RAM;
> >> +
> >> +   return 7;
> >>   }
> >> diff --git a/configs/qemu-x86_defconfig b/configs/qemu-x86_defconfig
> >> index e71b8a0ee1..2998d18bdd 100644
> >> --- a/configs/qemu-x86_defconfig
> >> +++ b/configs/qemu-x86_defconfig
> >> @@ -41,3 +41,4 @@ CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
> >>   CONFIG_FRAMEBUFFER_VESA_MODE_USER=y
> >>   CONFIG_FRAMEBUFFER_VESA_MODE=0x144
> >>   CONFIG_CONSOLE_SCROLL_LINES=5
> >> +CONFIG_CMD_BOOTEFI_HELLO=y
> >>
> >> $ qemu-system-i386 -nographic -bios u-boot.rom -m 8192
> >> => bootefi hello
> >
> > OK, thanks for the test case. However I believe this never broke QEMU x86.
> >
> > As in arch/x86/cpu/qemu/dram.c::dram_init():
> >
> > gd->ram_size will be always set to 3GiB when "-m 4G" or more memory is
> > specified for QEMU target, hence gd->ram_top is always set to 3GiB.
>
> Why would we have such an