On 4/30/20 3:03 PM, Jan Kiszka wrote:
> Hi all,
>
> I've noticed that building am65x_evm_a53_defconfig causes the dtbs to be
> built twice, once for the main u-boot and once for the spl. This is
> because of an extra dependency in mach-k3/config_secure.mk added by
> 508369672ca3. Why should the pr
Hi All,
I noticed some recent(ish) commits in u-boot.git are missing a
sign-off from the maintainer. Is this an omission or an intentional
change in process?
I don't have a problem either way but if it was an omission I thought
I'd point it out. If it's intentional then this message can go to
/de
This patch add support for USB2PHY and PCIe PHY driver
on rockchip platform and tested the same in rk3399.
Basic code is referenced from Linux, hence all the
license SPDX are reused.
The reason behind sending this as RFC is PHY devices
for u2phy, pcie_phy nodes are unable to get via
Generic PHY
Add the Rockchip PCIe PHY driver as part of
Generic PHY framework.
Signed-off-by: Jagan Teki
---
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/phy/rockchip/Kconfig | 9 +
drivers/phy/rockchip/Makefile| 6 +
Enable/Disable the USB2PHY clk for rk3399.
CLK is clear in enable and set in disable functionality.
Signed-off-by: Jagan Teki
---
drivers/clk/rockchip/clk_rk3399.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/clk/rockchip/clk_rk3399.c
b/drivers/clk/rockchip/clk_rk3
Add Rockchip USB2PHY driver with initial support.
This will help to use it for EHCI controller in host
mode, and USB 3.0 controller in otg mode.
More functionality like charge, vbus detection will
add it in future changes.
Signed-off-by: Jagan Teki
---
drivers/phy/rockchip/Kconfig
Yes, This is changing the actual device tree pcie_phy
structure but the problem with the current Generic PHY
subsystem is unable to find PHY if the PHY node is not
part of the root structure and also PHY parent is
non-PHY type.
This will be reverted once we support the PHY subsystem
to get the PHY
Yes, This is changing the actual device tree u2phy
structure but the problem with the current Generic
PHY subsystem is unable to find PHY if the PHY node
is not part of the root structure.
This will be reverted once we support the PHY subsystem
to get the PHY even though it is not part of the root
Now, we have a PCIe PHY driver as part of the Generic
PHY framework. Let's use it instead of legacy PHY driver.
Signed-off-by: Jagan Teki
---
drivers/pci/pcie_rockchip.c | 20 ++--
drivers/pci/pcie_rockchip.h | 5 +
2 files changed, 15 insertions(+), 10 deletions(-)
diff --
Drop the legacy PHY driver and it's associated code since
the PHY handling driver now part of Generic PHY framework.
Signed-off-by: Jagan Teki
---
drivers/pci/Makefile| 2 +-
drivers/pci/pcie_rockchip.c | 75 +++-
drivers/pci/pcie_rockchip.h | 147 -
On Thu, Apr 30, 2020 at 05:54:26PM +0200, Heinrich Schuchardt wrote:
> The following changes since commit 6864fc8704661878294d1f0f981f47e864ef470f:
>
> Merge https://gitlab.denx.de/u-boot/custodians/u-boot-sh (2020-04-29
> 10:39:18 -0400)
>
> are available in the Git repository at:
>
> http
On Fri, May 01, 2020 at 02:33:17AM +0530, Jagan Teki wrote:
> On Thu, Apr 30, 2020 at 8:16 PM Tom Rini wrote:
> >
> > On Thu, Apr 30, 2020 at 12:34:05PM +0530, Jagan Teki wrote:
> >
> > > Some drivers and other bsp code not only poll the
> > > register with timeout but also required to delay
> > >
On Wed, Apr 29, 2020 at 03:24:28PM +0200, Frank Wunderlich wrote:
> Hi,
>
> I hope the mtk xhci series can be merged because further xhci-development for
> mt7622/23 depends on this.
If Marek is happy with the code, I won't object.
>
> Regards Frank
>
> Am 29. April 2020 14:49:05 MESZ schrieb
On 4/30/20 4:36 AM, David Wu wrote:
> When using rgmii Gigabit mode, the wait_for_bit_le32()
> reset method resulting in RX can not receive data, after
> this patch, works well.
> diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
> + limit = eqos->config->swr_wait / 10;
> +
On 4/30/20 4:36 AM, David Wu wrote:
> It can be seen that most of the Socs using STM mac, "snps,reset-gpio"
> gpio is used, adding this option makes reset function more general.
> diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
> @@ -1712,11 +1724,29 @@ static int eqos_probe_re
On 4/30/20 4:36 AM, David Wu wrote:
> After moving to eqos_ops, if eqos_config is defined
> outside, can not export interface() definition.
Looking at the patch itself, I think this patch just moves a function
pointer from the config to the ops structure which makes sense. However,
I can't underst
On 4/30/20 4:36 PM, Stephen Warren wrote:
> On 4/30/20 4:36 AM, David Wu wrote:
>> It can be seen that most of the Socs using STM mac, "snps,reset-gpio"
>> gpio is used, adding this option makes reset function more general.
>
>> diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
>
On 4/30/20 4:43 AM, David Wu wrote:
> For others using, clk_rx and clk_tx may not be necessary,
> and their clock names are different.
> diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
> @@ -1691,20 +1699,16 @@ static int eqos_probe_resources_stm32(struct udevice
> *dev)
>
On 4/30/20 4:45 AM, David Wu wrote:
> Open structure data and interface, so that Soc using dw_eth_qos
> controller can reference.
This shouldn't be necessary; nothing outside of this driver should need
access to the registers.
At most, perhaps implement some additional functions so that other cod
On 4/30/20 4:45 AM, David Wu wrote:
> Change the original data structure so that Rockchip's Soc
> gmac controller can support the designware.c and dwc_eth_qos.c
> drivers, a Soc can only support one.
I'm really confused; with a filename like gmac_rockchip.c that sounds
like it's driver for a MAC d
At present this function copies U-Boot from the last 1MB of ROM. This is
not the right way to do it. Instead, the binman symbol should provide the
location.
But in any case the code should live in the caller,
spl_board_load_image(), so that the 64-bit jump function can be used
elsewhere. Move it.
At present this function is only available in 32-bit code. Move it to the
common cpu file so it can be used by 64-bit U-Boot too.
Signed-off-by: Simon Glass
---
Changes in v3:
- Add new patch to make coreboot detection work in 64-bit code
Changes in v2: None
arch/x86/cpu/cpu.c | 25 +
Coreboot runs in 32-bit mode and cannot run a 64-bit U-Boot. To get around
this we can build a combined image with 32-bit SPL and 64-bit U-Boot. Add
a build rule and binman definition for this.
Signed-off-by: Simon Glass
---
Changes in v3: None
Changes in v2: None
Makefile
This series creates a new 64-bit 'coreboot64' build which can be launched
from coreboot. It uses SPL to effect the jump to 64-bit mode.
This was done in an attempt to get the Ubuntu FirmwareTestSuite[1]
working. Unfortunately the latest version shows a splash screen and hangs,
perhaps due to some
At present SPL only works on bare-metal builds. With a few tweaks it can
be used for coreboot also.
Signed-off-by: Simon Glass
---
Changes in v3: None
Changes in v2: None
arch/x86/lib/spl.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/x86/lib/spl.c b/arch
Add a build for running 64-bit U-Boot from coreboot (which is 32-bit).
This uses binman to create an image with a 32-bit SPL and a 64-bit U-Boot.
Coreboot boots into SPL and then SPL boots into U-Boot.
This allows running 64-bit EFI images on x86.
Signed-off-by: Simon Glass
---
Changes in v3: N
Make a few adjustments to allow us to build an SPL image for coreboot.
Signed-off-by: Simon Glass
---
Changes in v3: None
Changes in v2: None
arch/x86/cpu/Makefile| 4 +++-
arch/x86/cpu/coreboot/Makefile | 8 +++-
arch/x86/cpu/coreboot/coreboot.c | 3 ++-
arch/
It is useful to know what mode U-Boot is running in. Add a message at the
end of the 'bdinfo' output.
Signed-off-by: Simon Glass
Suggested-by: Mark Kettenis
---
Changes in v3:
- Show bit width for all archs, use sizeof(void *)
Changes in v2:
- Add a new patch to indicate 32/64-bit in bdinfo
Am May 1, 2020 3:21:44 AM UTC schrieb Simon Glass :
>It is useful to know what mode U-Boot is running in. Add a message at
>the
>end of the 'bdinfo' output.
>
>Signed-off-by: Simon Glass
>Suggested-by: Mark Kettenis
>---
>
>Changes in v3:
>- Show bit width for all archs, use sizeof(void *)
>
>Cha
Am May 1, 2020 3:21:45 AM UTC schrieb Simon Glass :
>Add a build for running 64-bit U-Boot from coreboot (which is 32-bit).
>This uses binman to create an image with a 32-bit SPL and a 64-bit
>U-Boot.
>
>Coreboot boots into SPL and then SPL boots into U-Boot.
>
>This allows running 64-bit EFI image
Hi Heinrich,
On Thu, 30 Apr 2020 at 21:39, Heinrich Schuchardt wrote:
>
> Am May 1, 2020 3:21:44 AM UTC schrieb Simon Glass :
> >It is useful to know what mode U-Boot is running in. Add a message at
> >the
> >end of the 'bdinfo' output.
> >
> >Signed-off-by: Simon Glass
> >Suggested-by: Mark Ket
It is useful to know what mode U-Boot is running in. Add a message at the
end of the 'bdinfo' output.
Signed-off-by: Simon Glass
Suggested-by: Mark Kettenis
---
Changes in v4:
- Fix signed/unsigned mismatch in printf()
Changes in v3:
- Show bit width for all archs, use sizeof(void *)
Changes
HI Heinrich,
On Thu, 30 Apr 2020 at 21:57, Heinrich Schuchardt wrote:
>
> Am May 1, 2020 3:21:45 AM UTC schrieb Simon Glass :
> >Add a build for running 64-bit U-Boot from coreboot (which is 32-bit).
> >This uses binman to create an image with a 32-bit SPL and a 64-bit
> >U-Boot.
> >
> >Coreboot
Hi Tom,
On Thu, 30 Apr 2020 at 09:05, Tom Rini wrote:
> On Tue, Apr 28, 2020 at 04:40:47PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, 28 Apr 2020 at 09:52, Tom Rini wrote:
> > >
> > > On Tue, Apr 28, 2020 at 09:41:14AM -0600, Simon Glass wrote:
> > > > Hi Tom.
> > > >
> > > > On Tue,
Am May 1, 2020 4:04:06 AM UTC schrieb Simon Glass :
>HI Heinrich,
>
>On Thu, 30 Apr 2020 at 21:57, Heinrich Schuchardt
>wrote:
>>
>> Am May 1, 2020 3:21:45 AM UTC schrieb Simon Glass :
>> >Add a build for running 64-bit U-Boot from coreboot (which is
>32-bit).
>> >This uses binman to create an ima
On 5/1/20 6:02 AM, Simon Glass wrote:
> It is useful to know what mode U-Boot is running in. Add a message at the
> end of the 'bdinfo' output.
>
> Signed-off-by: Simon Glass
> Suggested-by: Mark Kettenis
Reviewed-by: Heinrich Schuchardt
> ---
>
> Changes in v4:
> - Fix signed/unsigned mismatc
On Fri, 1 May 2020 at 00:57, Tom Rini wrote:
> On Fri, May 01, 2020 at 12:38:45AM +0530, Sughosh Ganu wrote:
> > On Fri, 1 May 2020 at 00:07, Heinrich Schuchardt
> wrote:
> >
> > > On 4/30/20 7:36 PM, Sughosh Ganu wrote:
> > > > Add documentation highlighting the steps for using the uefi capsule
On 4/21/20 2:38 AM, AKASHI Takahiro wrote:
> "if (left < esl->signature_size)" is not reachable in a while loop.
> But it is still valuable in case that a given signature database is
> somehow corrupted. So fix the while loop condition.
>
> Signed-off-by: AKASHI Takahiro
> Reported-by: Heinrich Sc
On 4/21/20 2:39 AM, AKASHI Takahiro wrote:
> efi_set_secure_stat() provides the common code for each stat transition
> caused by efi_transfer_secure_state().
>
> Signed-off-by: AKASHI Takahiro
> Suggested-by: Heinrich Schuchardt
> ---
> lib/efi_loader/efi_variable.c | 194 +++
On Wed, Apr 29, 2020 at 11:38 AM Chunfeng Yun wrote:
>
> Add a test item for the phy_bulk API
>
> Signed-off-by: Chunfeng Yun
> Reviewed-by: Weijie Gao
> Reviewed-by: Simon Glass
> ---
Reviewed-by: Jagan Teki
On Thu, Apr 30, 2020 at 7:47 AM Frank Wang wrote:
>
> Add a quirk to clear the GUSB2PHYCFG.ENBLSLPM bit, which controls
> whether the PHY receives the suspend signal from the controller.
>
> Refer to commit ec791d149bca("usb: dwc3: Add dis_enblslpm_quirk")
> in Linux Kernel.
>
> Signed-off-by: Fra
201 - 241 of 241 matches
Mail list logo
