On Wed, 9 Sep 2020 at 14:39, Sean Anderson wrote:
>
> On 6/30/20 5:55 AM, Sean Anderson wrote:
> > On 3/20/20 3:10 AM, Lukasz Majewski wrote:
> >> On Fri, 20 Mar 2020 01:53:16 -0400
> >> Sean Anderson wrote:
> >>
> >>> Some of the debug messages in the clock subsystem can be made more
> >>>
On 9/10/20 3:30 PM, Tom Rini wrote:
> On Tue, Sep 01, 2020 at 07:23:01PM +0200, Robert Marko wrote:
>
>> Add driver for Qualcomm DWC3 based dual role xHCI USB controller.
>> Currently tested on IPQ40xx, but should support other Qualcomm SoC families
>> as well.
>>
>> Only host mode is supported.
On Thu, Sep 10, 2020 at 01:09:00PM +0200, Robert Marko wrote:
> This patch series builds on the previously merged basic
> Qualcomm IPQ40xx series support.
>
> v2 series drops custom USB driver and instead uses existing
> DWC3 generic driver.
>
> Signed-off-by: Robert Marko
> Cc: Luka Perkov
On Tue, Sep 01, 2020 at 07:23:00PM +0200, Robert Marko wrote:
> PHY handling functions should depend also on CONFIG_USB_DWC3 aka DM DWC3
> version.
> Otherwise when using the non DM version with PHY subsystem enabled there will
> be a linking error due to missing dwc3_setup_phy and
On Tue, Sep 01, 2020 at 07:23:01PM +0200, Robert Marko wrote:
> Add driver for Qualcomm DWC3 based dual role xHCI USB controller.
> Currently tested on IPQ40xx, but should support other Qualcomm SoC families
> as well.
>
> Only host mode is supported.
>
> Signed-off-by: Robert Marko
> Cc:
On 10/09/2020 13:38, Michal Simek wrote:
>
>
> On 09. 09. 20 19:07, Edgar E. Iglesias wrote:
>> From: "Edgar E. Iglesias"
>>
>> Trap non-PIE builds early if the start address doesn't match
>> between run-time and link-time. This will trap the startup
>> sequence rather than letting it run into
On 09. 09. 20 19:07, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Trap non-PIE builds early if the start address doesn't match
> between run-time and link-time. This will trap the startup
> sequence rather than letting it run into obscure errors.
>
> Signed-off-by: Edgar E.
Hi Jasper,
On Thu, Sep 10, 2020 at 11:19:29AM +0200, Jasper van Santen wrote:
I had already seen the movie, the book would have been better ;)
I feel that way too... ;)
Fortunately I build U-Boot with buildroot, so i have the source code.
It is a big meager, but I ended up grepping the man
ot-stm32-20200909' of
https://gitlab.denx.de/u-boot/custodians/u-boot-stm (2020-09-09 12:59:02 -0400)
are available in the Git repository at:
https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic.git
tags/u-boot-amlogic-20200910
for you to fetch changes up to 92f10e61351d730c49c00cdbbd19
Hi Stefan,
On Thu, Sep 10, 2020, 1:16 PM Stefan Roese wrote:
> On 10.09.20 07:58, Rayagonda Kokatanur wrote:
> > Hi Stefan,
> >
> > On Thu, Sep 10, 2020 at 10:53 AM Stefan Roese wrote:
> >>
> >> Hi Rayagonda,
> >>
> >> On 09.09.20 19:15, Rayagonda Kokatanur wrote:
> >>> Hi Stefan,
> >>>
> >>>
On 10.09.20 13:04, Sean Anderson wrote:
> On 9/10/20 7:00 AM, Heinrich Schuchardt wrote:
>> Function set_gd() is needed in the UEFI sub-system if the global data
>> pointer is stored in a register.
>>
>> Signed-off-by: Heinrich Schuchardt
>> ---
>> arch/riscv/include/asm/global_data.h | 9
On 09. 09. 20 19:07, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Linking a U-Boot larger than 1MB fails with PIE enabled:
> u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): relocation
> truncated to fit: R_AARCH64_ADR_PREL_LO21 against symbol `__rel_dyn_end'
> defined in
correction in delay implementation before we exit out of tx timeout.
Signed-off-by: Chaitanya Sakinam
---
drivers/net/pfe_eth/pfe_eth.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/pfe_eth/pfe_eth.c b/drivers/net/pfe_eth/pfe_eth.c
index 6e22041..5bfcaa4
PFE DDR addresses are now stored on to a stack varaiable rather
dynamic allocation.
Signed-off-by: Chaitanya Sakinam
---
drivers/net/pfe_eth/pfe_eth.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/net/pfe_eth/pfe_eth.c
Lot of Qualcomm SoC-s use DWC3 controller for both USB2.0 and USB3.0
ports.
Qualcomm has some custom config registers on top of the generic ones,
but for host mode these are not needed.
So lets add the neccessary compatible string.
Signed-off-by: Robert Marko
Cc: Luka Perkov
---
Add a driver to setup the USB PHY-s on Qualcomm IPQ40xx series SoCs.
The driver sets up HS and SS phys.
Signed-off-by: Robert Marko
Cc: Luka Perkov
---
MAINTAINERS| 1 +
drivers/phy/Kconfig| 6 ++
drivers/phy/Makefile | 1 +
There are drivers to support built in USB controller and PHY-s now, so lets add
the USB nodes to DTSI.
Signed-off-by: Robert Marko
Cc: Luka Perkov
---
arch/arm/dts/qcom-ipq4019.dtsi | 76 ++
1 file changed, 76 insertions(+)
diff --git
This patch series builds on the previously merged basic
Qualcomm IPQ40xx series support.
v2 series drops custom USB driver and instead uses existing
DWC3 generic driver.
Signed-off-by: Robert Marko
Cc: Luka Perkov
Robert Marko (8):
dt-bindings: clock: import Qualcomm IPQ4019 bindings
There is already existing driver for SMEM so lets enable it for IPQ40xx as well.
Signed-off-by: Robert Marko
Cc: Luka Perkov
---
arch/arm/Kconfig | 2 ++
arch/arm/dts/qcom-ipq4019.dtsi | 5 +
drivers/smem/Kconfig | 2 +-
3 files changed, 8 insertions(+), 1
Since we have a driver for the reset controller, lets add the necessary node.
Signed-off-by: Robert Marko
Cc: Luka Perkov
---
arch/arm/Kconfig | 1 +
arch/arm/dts/qcom-ipq4019.dtsi | 9 +
2 files changed, 10 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
On Qualcomm IPQ40xx SoC series, GCC clock IP also handles the resets.
So since this will be needed by further drivers, lets add a driver for the
reset controller.
Signed-off-by: Robert Marko
Cc: Luka Perkov
---
MAINTAINERS | 2 +
drivers/reset/Kconfig
Its common to use dt-bindings instead of hard-coding clocks or resets.
So lets use the imported Linux GCC bindings on IPQ40xx target.
Signed-off-by: Robert Marko
Cc: Luka Perkov
---
arch/arm/dts/qcom-ipq4019.dtsi| 3 ++-
arch/arm/mach-ipq40xx/clock-ipq4019.c | 4 +++-
2 files changed,
Import Qualcomm IPQ4019 GCC bindings from Linux.
This will enable using bindings instead of raw clock numbers both in the driver
and DTS like Linux does.
Signed-off-by: Robert Marko
Cc: Luka Perkov
---
MAINTAINERS | 1 +
On 10.09.20 13:03, Sean Anderson wrote:
>
> On 9/10/20 7:00 AM, Heinrich Schuchardt wrote:
>> On the RISC-V platform register gp (x3) is used as global data pointer in
>> U-Boot. When executing a UEFI binary we cannot assume that the payload
>> will restore the register before calling the UEFI
From: "hui.song"
add gpio0 gpio1 gpio3 DT nodes to fsl-lx21600.dtsi
Signed-off-by: hui.song
---
arch/arm/dts/fsl-lx2160a.dtsi | 33 +
1 file changed, 33 insertions(+)
diff --git a/arch/arm/dts/fsl-lx2160a.dtsi b/arch/arm/dts/fsl-lx2160a.dtsi
index
On 9/10/20 7:00 AM, Heinrich Schuchardt wrote:
> Function set_gd() is needed in the UEFI sub-system if the global data
> pointer is stored in a register.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> arch/riscv/include/asm/global_data.h | 9 +
> 1 file changed, 9 insertions(+)
>
>
Hi Ralph,
Thanks a lot for the info.
I had already seen the movie, the book would have been better ;)
Unfortunately I don't have easy access to the prompt since it's embedded.
So i can't prompt for help.
Fortunately I build U-Boot with buildroot, so i have the source code.
It is a big meager,
On 9/10/20 7:00 AM, Heinrich Schuchardt wrote:
> On the RISC-V platform register gp (x3) is used as global data pointer in
> U-Boot. When executing a UEFI binary we cannot assume that the payload
> will restore the register before calling the UEFI API. So U-Boot must
> take care of saving the
if conditions should match.
Fixes: a18d09ea384f ("fpga: zynqmp: Add secure bitstream loading for ZynqMP")
Signed-off-by: Michal Simek
---
drivers/fpga/zynqmppl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/fpga/zynqmppl.c b/drivers/fpga/zynqmppl.c
index
On the RISC-V platform register gp (x3) is used as global data pointer in
U-Boot. When executing a UEFI binary we cannot assume that the payload
will restore the register before calling the UEFI API. So U-Boot must
take care of saving the register value before invoking the payload and
restoring it
Function set_gd() is needed in the UEFI sub-system if the global data
pointer is stored in a register.
Signed-off-by: Heinrich Schuchardt
---
arch/riscv/include/asm/global_data.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/riscv/include/asm/global_data.h
On RISC-V the global data pointer is stored in register gp. When a UEFI
binary calls the EFI API we have to restore it.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_boottime.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git
Before calling do_reset() in the EFI selftest we must restore the global
data pointer.
Fixes: fa63753f86cc ("efi_selftest: substitute ResetSystem() by do_reset()")
Signed-off-by: Heinrich Schuchardt
---
lib/efi_selftest/efi_selftest.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
The patch does sed 's/SPL_FPGA_SUPPORT/SPL_FPGA/g' but also fixing Makefile
and zynqmp.c to simplify if/endif logic in zynqmp.c.
This change is mostly done to be able to use CONFIG_IS_ENABLED macro and
obj-$(CONFIG_$(SPL_)FPGA) in Makefile. For them symbols need to be in sync.
And removing one
On 9/10/20 3:08 AM, Rick Chen wrote:
> Hi Sean
>
>> On 9/8/20 10:02 PM, Rick Chen wrote:
>>> Hi Sean
>>>
On the K210, the prior stage bootloader does not clear IPIs. This presents
a problem, because U-Boot up until this point assumes (with one exception)
that IPIs are cleared when
There is no need to use these macros because enum pm_api_id can be used
instead.
Signed-off-by: Michal Simek
---
drivers/fpga/zynqmppl.c | 8
include/zynqmppl.h | 3 ---
2 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/fpga/zynqmppl.c
Add support for AQR113C PHY
Signed-off-by: Madalin Bucur
---
drivers/net/phy/aquantia.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/net/phy/aquantia.c b/drivers/net/phy/aquantia.c
index 68cd3d0..9061afa 100644
--- a/drivers/net/phy/aquantia.c
+++
On 9/10/20 2:39 AM, Rick Chen wrote:
> Hi Sean
>
>> On 9/9/20 3:50 AM, Rick Chen wrote:
>>> Hi Sean
>>>
Clearing MIP doesn't do anything. Whoops. The following commits should
tackle this problem in a more robust manner.
>>>
>>> I still not catch your points about that this commit
The environment variable test uses function validate_empty() to check that
a variable is not defined. If the hush parser is not enabled, we cannot
refer to a variable by $var_name but only by ${var_name}.
Signed-off-by: Heinrich Schuchardt
---
test/py/tests/test_env.py | 2 +-
1 file changed, 1
From: Grigore Popescu
The next DPMAC was always verified if it is enabled. In case of
DPMAC@6, the DPMAC@7 is verified. As DPMAC@7 is disabled, DPMAC@6 will
be considered disabled and not detected by uboot.
Signed-off-by: Grigore Popescu
Signed-off-by: Ioana Ciornei
---
> -Original Message-
> From: Ang, Chee Hong
> Sent: Monday, August 17, 2020 12:34 PM
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Simon Goldschmidt
> ; Tom Rini ; See,
> Chin Liang ; Tan, Ley Foon
> ; Ang, Chee Hong ;
> Chee, Tien Fong ; Lim, Elly Siew Chin
>
> Subject: [PATCH v1
From: Laurentiu Tudor
In the current implementation, u-boot creates iommu mappings only
for PCI devices enumarated at boot time thus does not take into
account more dynamic scenarios such as SR-IOV or PCI hot-plug.
Add an u-boot env var and a device tree property (to be used for
example in more
From: Laurentiu Tudor
Add a few defines related to PCI ARI configuration.
Signed-off-by: Laurentiu Tudor
---
include/pci.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/pci.h b/include/pci.h
index 1c5b36617e..d1ccf6c963 100644
--- a/include/pci.h
+++ b/include/pci.h
@@
From: Laurentiu Tudor
In the current implementation, u-boot creates iommu mappings only
for PCI devices enumarated at boot time thus does not take into
account more dynamic scenarios such as SR-IOV or PCI hot-plug.
Add support for specifying extra IOMMU mappings for PCI
controllers through a
From: Laurentiu Tudor
Fix duplication of this code by placing it in a common function.
Furthermore, the resulting function will be re-used in upcoming
patches.
Signed-off-by: Laurentiu Tudor
---
drivers/pci/pcie_layerscape_fixup.c | 76 +
1 file changed, 34
From: Laurentiu Tudor
Move the pci device related fdt fixup in a function in order to
re-use it in a following patch. While at it, improve the error
handling.
Signed-off-by: Laurentiu Tudor
---
drivers/pci/pcie_layerscape_fixup.c | 60 -
1 file changed, 34
From: Etienne Carriere
OP-TEE reserved memory node must set property "no-map" to prevent
Linux kernel from mapping secure memory unless what non-secure world
speculative accesses of the CPU can violate the memory firmware
configuration.
Fixes: 6ccb05eae01b ("image: fdt: copy possible optee
Enable unique mac address generation from SoC serial on S400 board.
Signed-off-by: Neil Armstrong
---
board/amlogic/s400/s400.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/board/amlogic/s400/s400.c b/board/amlogic/s400/s400.c
index 7e2f0cdae3..b081942dcc 100644
---
From: Etienne Carriere
Add boolean input argument @no_map to helper function
fdtdec_add_reserved_memory() to add or not "no-map" property
for an added reserved memory node.
Property no-map is used by the Linux kernel to not not map memory
in its static memory mapping. It is needed for example
Add a test to verify that the no-map property is added in reserved-memory
node when fdtdec_add_reserved_memory() no-map parameter is set to true.
Signed-off-by: Patrice Chotard
Reviewed-by: Simon Glass
---
(no changes since v2)
Changes in v2:
- Add no-map property test into fdtdec test
Add the correcly architectured USB Glue node for Meson AXG and the
S400 board in -u-boot.dtsi until support in upstream Linux then
backported.
Signed-off-by: Neil Armstrong
---
arch/arm/dts/meson-axg-s400-u-boot.dtsi | 12 +
arch/arm/dts/meson-axg-u-boot.dtsi | 62
Enable USB Host & Gadget on the Amlogic S400 board.
Signed-off-by: Neil Armstrong
---
configs/s400_defconfig | 15 +++
1 file changed, 15 insertions(+)
diff --git a/configs/s400_defconfig b/configs/s400_defconfig
index 3c9509411b..16c162434b 100644
--- a/configs/s400_defconfig
+++
The registers which are managed by the meson-gxl-usb3 PHY driver are
actually "USB control" registers (which are "glue" registers which
manage OTG detection and routing of the OTG capable port between the
DWC2 peripheral-only controller and the DWC3 host-only controller).
Drop the meson-gxl-usb3
Add the board_usb_init()/cleanup() for USB gadget for AXG based
on the code for the G12A architecture.
Signed-off-by: Neil Armstrong
---
arch/arm/mach-meson/board-axg.c | 128
1 file changed, 128 insertions(+)
diff --git a/arch/arm/mach-meson/board-axg.c
Enable build of meson-gxl-usb PHY for the AXG architecture aswell.
Signed-off-by: Neil Armstrong
---
drivers/phy/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 9c775107e9..912e29f7b5 100644
--- a/drivers/phy/Kconfig
The USB support was initialy done with a set of PHYs and dwc3-of-simple
because the architecture of the USB complex was not understood correctly
at the time (and proper documentation was missing...).
But with the G12A family, the USB complex was correctly understood and
implemented correctly.
This imports the AXG, GXL & GXM SoC and boards DT changes from the Linux
commit b3a9e3b9622a ("Linux 5.8-rc1").
This change also removes GXL & GXM u-boot.dtsi hacks for USB gadget.
Signed-off-by: Neil Armstrong
---
arch/arm/dts/meson-axg.dtsi | 6 +-
Use the new Amlogic GXL/GXM USB Glue instead of the set of USB3 PHY
and Simple DWC3 wrapper.
Signed-off-by: Neil Armstrong
---
arch/arm/mach-meson/board-gx.c | 127 +++
configs/khadas-vim2_defconfig| 2 +-
configs/khadas-vim_defconfig | 2 +-
This serie follows the recent work under Linux to rework and update support of
the USB complex in the Amlogic GXL, GXM & AXG SoCs.
This rework follows the clean implementation for the G12A & following SoCs to
support
Host, Device & OTG functionnality.
The GXL, GXM & AXG USB complex is
Hi Sean
> On 9/9/20 5:01 AM, Rick Chen wrote:
> > Hi Sean
> >
> >> Hi Sean
> >>
> >>> Some IPIs may already be pending when U-Boot is started. This could be a
> >>> problem if a secondary hart tries to handle an IPI before the boot hart
> >>> has
> >>> initialized the IPI device.
> >>>
> >>>
> -Original Message-
> From: Ang, Chee Hong
> Sent: Monday, August 17, 2020 12:34 PM
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Simon Goldschmidt
> ; Tom Rini ; See,
> Chin Liang ; Tan, Ley Foon
> ; Ang, Chee Hong ;
> Chee, Tien Fong ; Lim, Elly Siew Chin
>
> Subject: [PATCH v1
Hi Alexandru
On 9/9/20 11:54 PM, Alexandru Gagniuc wrote:
> mmc_of_parse() can populate the 'f_max' and 'host_caps' fields of
> struct mmc_config from devicetree.
> The same logic is duplicated in stm32_sdmmc2_probe(). Use
> mmc_of_parse(), which is more generic.
>
> Signed-off-by: Alexandru
On 10.09.20 07:58, Rayagonda Kokatanur wrote:
Hi Stefan,
On Thu, Sep 10, 2020 at 10:53 AM Stefan Roese wrote:
Hi Rayagonda,
On 09.09.20 19:15, Rayagonda Kokatanur wrote:
Hi Stefan,
On Wed, Sep 9, 2020 at 1:57 PM Stefan Roese wrote:
On 09.09.20 10:14, Priyanka Jain wrote:
This is
On 09/09/2020 21:20, Petr Tesarik wrote:
On Wed, 9 Sep 2020 10:13:50 +0200
Matthias Brugger wrote:
Hi Tom,
Please have a look at the second round of patches for the RPi. Two patches fixes
the network driver of the RPi4 which didn't work reliable. Another patch enables
USB keyboard for 32
> -Original Message-
> From: Ang, Chee Hong
> Sent: Monday, August 17, 2020 12:34 PM
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Simon Goldschmidt
> ; Tom Rini ; See,
> Chin Liang ; Tan, Ley Foon
> ; Ang, Chee Hong ;
> Chee, Tien Fong ; Lim, Elly Siew Chin
>
> Subject: [PATCH v1
>-Original Message-
>From: Meenakshi Aggarwal
>Sent: Wednesday, September 9, 2020 2:06 PM
>To: u-boot@lists.denx.de; Priyanka Jain
>Cc: Varun Sethi ; Meenakshi Aggarwal
>; Thirupathaiah Annapureddy
>
>Subject: [PATCH] armv8: lx2160a: fix reset sequence
>
>From: Meenakshi Aggarwal
>
Hi Sean
> On 9/8/20 10:02 PM, Rick Chen wrote:
> > Hi Sean
> >
> >> On the K210, the prior stage bootloader does not clear IPIs. This presents
> >> a problem, because U-Boot up until this point assumes (with one exception)
> >> that IPIs are cleared when it starts. This series attempts to fix
> -Original Message-
> From: Nico Becker
> Sent: Wednesday, September 9, 2020 8:02 PM
> To: u-boot@lists.denx.de; ma...@denx.de;
> simon.k.r.goldschm...@gmail.com; Tan, Ley Foon
> Cc: Nico Becker
> Subject: [RESEND PATCH v5] Add board support for ic-automation Moritz III
>
> Add
Hi Simon,
-"Simon Glass" schrieb: -
> Betreff: Re: [PATCH] acpi: device: Fix check for sequence number
>
> Hi Wolfgang,
>
> On Thu, 13 Aug 2020 at 01:23, Wolfgang Wallner
> wrote:
> >
> > Hi Simon,
> >
> > -"Simon Glass" schrieb: -
> > > Betreff: Re: [PATCH] acpi: device: Fix
Hi Sean
> On 9/9/20 3:50 AM, Rick Chen wrote:
> > Hi Sean
> >
> >> Clearing MIP doesn't do anything. Whoops. The following commits should
> >> tackle this problem in a more robust manner.
> >
> > I still not catch your points about that this commit 947263033 really
> > help to fix pending IPIs
101 - 170 of 170 matches
Mail list logo
