[U-Boot] Sharing a hardware lab
Hi Tom, I have been meaning to have a crack at setting up a little hardware lab for a while. I made some progress recently and hooked up a rpi_3 with sdwire for USB/SD, ykush for power and a little computer to control it. It builds U-Boot, sticks it on the SD card and runs pytest. I pushed a tree here and hopefully you can see the 'hwlab' thing at the end: https://gitlab.denx.de/u-boot/custodians/u-boot-dm/pipelines/148 So far it is just running the 'help' test. It seems to hang with serial console problems if I try to do more. It is not 100% reliable yet. I based it on Stephen's test hooks: https://github.com/sglass68/uboot-test-hooks Is it possible to share this so that others can use the lab when they push trees? Is it as simple as adding to the .gitlab-ci.yml file as I have done here? https://gitlab.denx.de/u-boot/custodians/u-boot-dm/blob/gitlab-working/.gitlab-ci.yml I also got tbot going in a similar way, to test booting into Linux. Should we look at integrating that at the same time? It should be fairly easy to do. I have quite a lot of random boards and in principle it should not be too hard to hook up some more of them, with sufficient SDwires, hubs and patience. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: tftp: Fix too small block size
On Sat, Nov 23, 2019 at 11:59 AM Andre Przywara wrote:
>
> Commit b618b3707633 ("net: Convert CONFIG_TFTP_BLOCKSIZE to Kconfig")
> accidentally set the default *option* TFTP block size to 512 bytes, even
> though the comment in the code says that this is a terrible choice. Most
> boards didn't define the symbol before, so they got the default block size
> of 1468 bytes before, but now use 512 bytes, which is also the fallback.
> This leads to both abysmal performance and a lot of hashes printed
> on the screen (one character for every 5K), which is both annoying and
> slow over serial links.
>
> Set the default block size in Kconfig back to the value it had before.
>
> This improves TFTP performance from 2.8 MB/s to 6.9 MB/s on a Pine64.
>
> Fixes: b618b3707633 ("net: Convert CONFIG_TFTP_BLOCKSIZE to Kconfig")
> Signed-off-by: Andre Przywara
Acked-by: Joe Hershberger
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: ftgmac100: align RX/TX descriptors on ARCH_DMA_MINALIGN
On Thu, Nov 28, 2019 at 6:37 AM Cédric Le Goater wrote:
>
> Fixes: e766849713ff ("net: ftgmac100: convert the RX/TX descriptor arrays")
> Signed-off-by: Cédric Le Goater
Acked-by: Joe Hershberger
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: phy: micrel: make sure the factory test bit is cleared
On Wed, Oct 23, 2019 at 5:47 AM wrote: > > From: Nicolas Ferre > > The KSZ8081 PHY has a factory test mode which is set at the de-assertion > of the reset line based on the RXER (KSZ8081RNA/RND) or TXC > (KSZ8081MNX/RNB) pin. If a pull-down is missing, or if the pin has a > pull-up, the factory test mode should be cleared by manually writing a 0 > (according to the datasheet). > Create another ksz8081_config function to handle this case. > > Suggested-by: Antoine Tenart > Signed-off-by: Nicolas Ferre Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: phy: aquantia: wait for phy init sequence to finish
On Mon, Oct 14, 2019 at 9:27 AM Florin Chiculita
wrote:
>
> Aquantia quad-phys may take longer to initialize. This commit adds
> a polling mechanism for a global alarm bit that tells if phy init
> sequence is completed.
>
> Signed-off-by: Florin Chiculita
Acked-by: Joe Hershberger
> ---
> drivers/net/phy/aquantia.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/net/phy/aquantia.c b/drivers/net/phy/aquantia.c
> index 465ec2d..ae3112c 100644
> --- a/drivers/net/phy/aquantia.c
> +++ b/drivers/net/phy/aquantia.c
> @@ -37,6 +37,9 @@
> #define GLOBAL_FAULT 0xc850
> #define GLOBAL_RSTATUS_1 0xc885
>
> +#define GLOBAL_ALARM_1 0xcc00
> +#define SYSTEM_READY_BIT 0x40
> +
> #define GLOBAL_STANDARD_CONTROL 0x0
> #define SOFT_RESET BIT(15)
> #define LOW_POWER BIT(11)
> @@ -258,6 +261,17 @@ int aquantia_config(struct phy_device *phydev)
> {
> u32 val, id, rstatus, fault;
> u32 reg_val1 = 0;
> + int num_retries = 5;
> +
> + /* check if the system is out of reset and init sequence completed.
I'll be fixing up this comment format.
> +* chip-wide reset for gen1 quad phys takes longer
> +*/
> + while (--num_retries) {
> + rstatus = phy_read(phydev, MDIO_MMD_VEND1, GLOBAL_ALARM_1);
> + if (rstatus & SYSTEM_READY_BIT)
> + break;
> + mdelay(10);
> + }
>
> id = phy_read(phydev, MDIO_MMD_VEND1, GLOBAL_FIRMWARE_ID);
> rstatus = phy_read(phydev, MDIO_MMD_VEND1, GLOBAL_RSTATUS_1);
> --
> 1.9.3
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 9/9] phy: atheros: consolidate {ar8031|ar8035}_config()
On Fri, Oct 25, 2019 at 7:29 PM Michael Walle wrote: > > The two functions are now exactly the same, remove one of them. > > Signed-off-by: Michael Walle Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9] phy: atheros: ar8035: remove static clock config
On Fri, Oct 25, 2019 at 7:29 PM Michael Walle wrote: > > We can configure the clock output in the device tree. Disable the > hardcoded one in here. This is highly board-specific and should have > never been enabled in the PHY driver. > > If bisecting shows that this commit breaks your board it probably > depends on the clock output of your Atheros AR8035 PHY. Please have a > look at doc/device-tree-bindings/net/phy/atheros.txt. You need to set > "clk-out-frequency = <12500>" because that value was the hardcoded > value until this commit. > > Signed-off-by: Michael Walle Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 7/9] phy: atheros: Add device tree bindings and config
On Fri, Oct 25, 2019 at 7:29 PM Michael Walle wrote: > > Add support for configuring the CLK_25M pin as well as the RGMII I/O > voltage by the device tree. > > By default the AT803x PHYs outputs the 25MHz clock of the XTAL input. > But this output can also be changed by software to other frequencies. > This commit introduces a generic way to configure this output. > > Also the PHY supports different RGMII I/O voltages: 1.5V, 1.8V and 2.5V. > An internal LDO is able to provide 1.5V (default) and 1.8V. The 2.5V > option needs an external supply voltage. This commit adds support to > switch the internal LDO to 1.8V. > > Signed-off-by: Michael Walle Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/9] phy: atheros: fix delay configuration
On Fri, Oct 25, 2019 at 7:30 PM Michael Walle wrote: > > The delay_config() code could only set the delay bit. Thus, it could > only enable the delay mode, but not disable it. To make things worse, > the RX delay mode is enabled by default after a hardware reset, so it > could never be disabled. Fix this, by always setting or clearing the > bits. This is also how the linux kernel configures the PHY. > > If bisecting shows that this commit breaks your board you probably have > a wrong PHY interface mode. You probably want the > PHY_INTERFACE_MODE_RGMII_RXID or PHY_INTERFACE_MODE_RGMII_ID mode. > > Signed-off-by: Michael Walle Either the offending dts's are already updated or they will be when this breaks them. It's been 6 months. Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/9] phy: atheros: ar8035: use phy_{read|write}_mmd()
On Fri, Oct 25, 2019 at 7:31 PM Michael Walle wrote: > > Signed-off-by: Michael Walle Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/9] phy: atheros: don't overwrite debug register values
On Fri, Oct 25, 2019 at 7:30 PM Michael Walle wrote: > > Instead of doing a hard write, do a read-modify-write. > > Signed-off-by: Michael Walle Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] phy: atheros: ar8035: remove extra delay config
On Fri, Oct 25, 2019 at 7:29 PM Michael Walle wrote: > > Remove the hard-coded delay configuration. The AR8035 config() always > enabled the TX delay mode, although it will be set according to the PHY > interface mode, too. > > If bisecting shows that this commit breaks your board you probably have > a wrong PHY interface mode. You probably want the > PHY_INTERFACE_MODE_RGMII_TXID or PHY_INTERFACE_MODE_RGMII_ID mode. > > Signed-off-by: Michael Walle Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9] phy: atheros: move delay config to common function
On Fri, Oct 25, 2019 at 7:28 PM Michael Walle wrote: > > Signed-off-by: Michael Walle Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9] phy: atheros: introduce debug read and write functions
On Fri, Oct 25, 2019 at 7:28 PM Michael Walle wrote: > > Provide functions to read and write the Atheros debug registers. > > Signed-off-by: Michael Walle Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] phy: atheros: add some debug output
On Sun, Oct 27, 2019 at 3:38 PM Michael Walle wrote: > > The network driver has to set the PHY node correctly. If that is not the > case, ar803x_of_init() will fail. Add some debugging output. > > If the device tree binding is not working for you have a look at the > ar803x_of_init: found PHY node: phy@0 > output. In the case above "phy@0" is the phy node in the device tree. If > instead the node of your network device is displayed, you have to set > the phydev->node property in your network device driver. For example, > the following patch adds it to the fsl_enetc driver: > https://patchwork.ozlabs.org/patch/1184523/ > > Signed-off-by: Michael Walle Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: eth-uclass: ignore unavailable devices
On Mon, Oct 21, 2019 at 6:03 PM Michael Walle wrote: > > device_probe() may fail in which case the seq_id will be -1. Don't > display these devices during startup. While this is only a cosmetic > change, the return value of eth_initialize() will also change to the > actual number of available devices. The return value is only used in > spl_net to decide whether there are any devices to boot from. So > returning only available devices is also more correct in that case. > > Signed-off-by: Michael Walle Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] net: macb: let miiphy_read/_write pass arbitrary addresses
On Wed, Oct 2, 2019 at 2:46 PM Josef Holzmayr wrote: > > This allows passing arbitrary addresses through macb_miiphy_read and > macb_miiphy_write, therefore enabling the mii command to access > all mdio bus devices instead of only the defined phy. > > Signed-off-by: Josef Holzmayr Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net: macb: explicitly pass phy_adr to mdio read and write
On Wed, Oct 2, 2019 at 2:47 PM Josef Holzmayr wrote: > > To support accessing arbitrary addresses the mii/mdio bus it is > neccesary that the macb_mdio_read and macb_mdio_write functions > do not implicitly use the address of the connected phy. > > The function signature is extended according to the Linux kernel > equivalent. > > Signed-off-by: Josef Holzmayr Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: phy: Increase link up delay in genphy_update_link()
On Mon, Sep 30, 2019 at 3:33 AM Stefan Roese wrote: > > I've noticed that in most cases when genphy_update_link() is called, the > ethernet driver (mt7628-eth in this case) fails with the first ethernet > packets. Resulting in a timeout of the first tftp command. Increasing > the delay in the link check look from 1 to 50 ms and moving it below the > BMSR register read fixes this issue, resulting in a stable ethernet > traffic, even after initial link autonogotiation. > > Signed-off-by: Stefan Roese > Cc: Weijie Gao > Cc: Joe Hershberger Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: rtl8169: Support RTL-8168c/8111c
On Wed, Sep 11, 2019 at 12:19 PM Thierry Reding wrote: > > From: Thierry Reding > > This version of the RTL-8168 chip can be found on some add-in cards sold > by CSL-Computer GmbH & Co. KG. The chip isn't special in any way, but it > needs to have the ChipCmd register programmed after the DMA descriptors > have been set up, so make sure that happens by adding an entry to the > chip information table. > > Signed-off-by: Thierry Reding Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 5/5] net: mvpp2: MVPP2 now needs MVMDIO
On Thu, Aug 15, 2019 at 5:09 PM wrote: > > From: Nevo Hed > > Changes to mvpp2.c require the MVMDIO module which in turn uses > DM_MDIO. > > Signed-off-by: Nevo Hed Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/5] net: mvpp2: use new MVMDIO driver
On Thu, Aug 15, 2019 at 5:09 PM wrote: > > From: Nevo Hed > > This commit ports mvpp2 to use the recently introduced Marvell MDIO > (MVMDIO) driver. It removes direct interaction with the SMI & XSMI > busses. This commit is based in part on earlier work by > Ken Ma in Marvell's own downstream repo: > https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/c81dc39. > > The above refrenced work was based on an MVMDIO implementation that > never made it into U-Boot. With this patch the mvpp2 driver switches > to use the new MVMDIO driver that is based on a more universal > mdio-uclass implementation. > > Signed-off-by: Nevo Hed Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/5] arm: dts: armada-cp110-*dtsi: add xmdio nodes
On Thu, Aug 15, 2019 at 5:09 PM wrote: > > From: Nevo Hed > > Based on upstream-linux > See https://github.com/torvalds/linux/commit/f66b2aff. > > However made the XSMI register window 0x16 (22) bytes per my reading > of the functional spec. Similar commits in Marvels own repo bump it > to 0x200 (512) bytes but I did not see the reasoning for that. > > https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/4d932b4. > > Also added device-name attributes to prevent ambiguity in the `mdio` > command. > > Signed-off-by: Nevo Hed Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/5] net: mvpp2: mark phy as invalid in case of missing appropriate driver
On Thu, Aug 15, 2019 at 5:09 PM wrote: > > From: Grzegorz Jaszczyk > > If the phy doesn't match with any existing u-boot drivers, the phy > framework will connect it to the generic one which uid == > 0x. In this case, act as if the phy wouldn't be declared in > dts. Otherwise, in case of 3310 (for which the driver doesn't exist) > the link is marked as always down. Removing phy entry from dts in case > of 3310 is not a good option because it is required for the > phy_fw_down procedure. > > This patch fixes the issue with the link always down on MCBIN board. > > nhed: added NULL deref test. > > Signed-off-by: Grzegorz Jaszczyk > Reviewed-by: Igal Liberman > Tested-by: Igal Liberman > Signed-off-by: Nevo Hed Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/5] net: mvpp2x: fix traffic stuck after PHY start error
On Thu, Aug 15, 2019 at 5:09 PM wrote: > > From: Stefan Chulski > > Issue: > - Network stuck if autonegotion fails. > > Issue root cause: > > - When autonegotiation fails during port open procedure, the packet > processor configuration does not finish and open procedure exits > with error. > - However, this doesn't prevent u-boot network framework from > calling send and receive procedures. > - Using transmit and receive functions of misconfigured packet > processor will cause traffic to get stuck. > > Fix: > > - Continue packet processor configuration even if autonegotiation > fails. Only error message is triggered in this case. > - Exit transmit and receive functions if there is no PHY link > indication. > - U-boot network framework now calls open procedure again during next > transmit initiation. > > Signed-off-by: Stefan Chulski > Reviewed-by: Igal Liberman > Tested-by: Igal Liberman Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/6] net: introduce DSA class for Ethernet switches
Hi Alex,
On Mon, Nov 25, 2019 at 9:54 AM Alex Marginean
wrote:
>
> DSA stands for Distributed Switch Architecture and it covers switches that
> are connected to the CPU through an Ethernet link and generally use frame
> tags to pass information about the source/destination ports to/from CPU.
> Front panel ports are presented as regular ethernet devices in U-Boot and
> they are expected to support the typical networking commands.
> DSA switches may be cascaded, DSA class code does not currently support
> this.
Is it expected to eventually retrofit the other switch drivers that we
have in U-Boot to use this?
>
> Signed-off-by: Alex Marginean
> ---
> drivers/net/Kconfig| 13 ++
> include/dm/uclass-id.h | 1 +
> include/dsa.h | 140
Please use include/net/dsa.h
> net/Makefile | 1 +
> net/dsa-uclass.c | 369 +
> 5 files changed, 524 insertions(+)
> create mode 100644 include/dsa.h
> create mode 100644 net/dsa-uclass.c
>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 4182897d89..a4157cb122 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -37,6 +37,19 @@ config DM_MDIO_MUX
> This is currently implemented in net/mdio-mux-uclass.c
> Look in include/miiphy.h for details.
>
> +config DM_DSA
> + bool "Enable Driver Model for DSA switches"
> + depends on DM_ETH && DM_MDIO
> + help
> + Enable Driver Model for DSA switches
> +
> + Adds UCLASS_DSA class supporting switches that follow the
> Distributed
> + Switch Architecture (DSA). These switches rely on the presence of a
> + management switch port connected to an Ethernet controller capable
> of
> + receiving frames from the switch. This host Ethernet controller is
> + called "master" and "cpu" in DSA terminology.
> + This is currently implemented in net/dsa-uclass.c
> +
> config MDIO_SANDBOX
> depends on DM_MDIO && SANDBOX
> default y
> diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
> index 0c563d898b..8f37a91488 100644
> --- a/include/dm/uclass-id.h
> +++ b/include/dm/uclass-id.h
> @@ -42,6 +42,7 @@ enum uclass_id {
> UCLASS_DISPLAY, /* Display (e.g. DisplayPort, HDMI) */
> UCLASS_DSI_HOST,/* Display Serial Interface host */
> UCLASS_DMA, /* Direct Memory Access */
> + UCLASS_DSA, /* Distributed (Ethernet) Switch Architecture
> */
> UCLASS_EFI, /* EFI managed devices */
> UCLASS_ETH, /* Ethernet device */
> UCLASS_FIRMWARE,/* Firmware */
> diff --git a/include/dsa.h b/include/dsa.h
> new file mode 100644
> index 00..707a1d7e6f
> --- /dev/null
> +++ b/include/dsa.h
> @@ -0,0 +1,140 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (c) 2019 NXP
> + */
> +
> +#ifndef __DSA_H__
> +#define __DSA_H__
> +
> +#include
> +#include
> +#include
> +
> +/**
> + * DSA stands for Distributed Switch Architecture and it is infrastructure
> + * intended to support drivers for Switches that rely on an intermediary
> + * Ethernet device for I/O. These switches may support cascading allowing
> + * them to be arranged as a tree.
> + * DSA is documented in detail in the Linux kernel documentation under
> + * Documentation/networking/dsa/dsa.txt
> + * The network layout of such a switch is shown below:
> + *
> + * |---
> + * | CPU network device (eth0)|
> + *
> + * | + * | |
> + * | |
> + * |tag added by CPU> |
> + * ||
> + * | Switch driver |
> + * ||
> + * |||| ||
> + * |---| |---| |---|
> + * | sw0p0 | | sw0p1 | | sw0p2 |
> + * |---| |---| |---|
> + *
> + * In U-Boot the intent is to allow acces to front panel ports (shown at the
acces -> access
> + * bottom of the picture) though the master Ethernet port (eth0 in the
> picture).
> + * Front panel ports are presented as regular ethernet devices in U-Boot and
ethernet -> Ethernet
> + * they are expected to support the typical networking commands.
> + * In general DSA switches require the use of tags, extra headers added both
> by
> + * software on Tx and by the switch on Rx. These tags carry at a minimum
> port
> + * information and switch information for cascaded set-ups.
> + * In U-Boot these tags are inserted and parsed by the DSA switch driver, the
> + * class code helps with headroom/tailroom for the extra headers.
> + *
> + * TODO:
> + * - handle switch cascading, for now U-Boot only supports stand-alone
> switches.
> + * - put master Eth in
Re: [U-Boot] [PATCH] drivers: net: fsl_enetc: register internal MDIO bus
On Mon, Nov 25, 2019 at 9:58 AM Alex Marginean wrote: > > This bus is used to access internal SoC PHYs. These PHYs are configured > by the ENETC driver directly, but it's useful to have command line access > to this MDIO to debug the system especially when using new external PHYs. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] drivers: net: fsl_enetc_mdio: return with time-out if HW is stuck
On Thu, Nov 14, 2019 at 10:59 AM Alex Marginean wrote: > > On some boards MDIO may get stuck if it detects echo on the line. This is > a know hardware issue, there is a board fix for it. In case we're running > on a board that doesn't have the fix, we don't want to loop here forever > and freeze U-Boot. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] drivers: net: fsl_enetc: Add 2.5Gbps to supported link speeds
On Thu, Nov 14, 2019 at 10:59 AM Alex Marginean wrote: > > The original code enabled link speeds up to 1Gbps, but the interface can > go up to 2.5G, enable that speed to in PHY AN mask. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] drivers: net: fsl_enetc: move PCS and PHY config to probe
On Thu, Nov 14, 2019 at 10:59 AM Alex Marginean wrote: > > This reduces the time needed to establish a link as we don't reset the link > each time the interface is used. Our Link capabilities do not change at > run-time so there is no need to re-apply PHY configuration each time. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 11/11] drivers: net: fsl_enetc: use XFI, USXGMII interface type macros
On Thu, Nov 14, 2019 at 10:31 AM Alex Marginean wrote: > > Apply 10G PCS init for USXGMII, XFI interface types. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 10/11] doc: bindings: Aquantia PHY node binding
On Thu, Nov 14, 2019 at 10:34 AM Alex Marginean wrote: > > A couple of optional properties have been introduced for Aquantia PHY > allowing the driver to set up wiring related configuration points that > are otherwise driven by firmware. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/11] doc: bindings: add bindings document for PHY nodes
On Thu, Nov 14, 2019 at 10:33 AM Alex Marginean wrote: > > It defines that PHY nodes must be children on MDIO bus nodes and defines > the only required property in U-Boot, reg. This property along with the > example provided are copied over from Linux. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 08/11] drivers: net: aquantia: check system interface too when checking for link up
On Thu, Nov 14, 2019 at 10:32 AM Alex Marginean wrote: > > In some cases the link on the system interface of the aquantia PHY comes up > after the link on line interface. The link state loop only checks the line > side, which may result in first packet sent being lost. > Use aquantia_link_is_up instead, which checks both system and line side on > gen 2/3 PHYs to avoid losing the 1st packet. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 07/11] drivers: net: aquantia: set SMBus addr based on DT property
On Thu, Nov 14, 2019 at 10:31 AM Alex Marginean wrote: > > Aquantia PHYs have a SMBus interface mostly used for debug. The addresses > on this interface are normally set up by PHY firmware, but depending on the > board they may end up not being unique. Add an optional DT property used > to change SMBus address if needed. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/11] drivers: net: aquantia: set MDI reversal based on DT property
On Thu, Nov 14, 2019 at 10:34 AM Alex Marginean wrote: > > MDI pins up to the RJ45 connector may be reversed on the board and the > default PHY configuration applied by firmware may or may not match that. > Add an optional DT property to configure MDI reversal for this case. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 05/11] drivers: net: aquantia: set up SI protocol based on interface type
On Thu, Nov 14, 2019 at 10:33 AM Alex Marginean wrote: > > If PHY is not ready for data by the time _config is called, reconfigure the > PHY system interface to use the proper protocol based on phydev->interface, > just in case the defaults set by PHY firmware don't match current > configuration. > > Signed-off-by: Florin Laurentiu Chiculita > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 04/11] drivers: net: aquantia: add PHY generation information
On Thu, Nov 14, 2019 at 10:32 AM Alex Marginean wrote: > > Uses the data field in phy_driver structure to identify the PHY generation. > This is useful for custom configuration as non-generic PHY registers are > not 100% compatible between generations. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 03/11] drivers: net: aquantia: use XFI, USXGMII interface types
On Thu, Nov 14, 2019 at 10:35 AM Alex Marginean wrote: > > The PHY supports XFI and USXGMII, the notable difference being that USX AN > is enabled for USXGMII. Legacy code uses XGMII for any 10G proto and > detects whether USX AN should be enabled or not using a PHY status > register. Keep that functionality too, so we don't break existing drivers. > > Signed-off-by: Razvan Ionut Cirjan > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/11] include: phy: add data field for private driver data
On Thu, Nov 14, 2019 at 10:30 AM Alex Marginean wrote: > > This is useful to carry custom information between the driver structure > associated with a specific HW and the driver code. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/11] include: phy: define XFI and USXGMII interface types
On Thu, Nov 14, 2019 at 10:31 AM Alex Marginean wrote: > > Drivers currently use XGMII for XFI and USXGMII and, where needed, use > other information to identify the actual protocol on the board. With these > two defined drivers can now rely on DT phy-mode property. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/3] drivers: net: fsl_enetc: use the new MDIO DM helper functions
On Mon, Nov 25, 2019 at 9:17 AM Alex Marginean wrote: > > Uses the new dm_eth_phy_connect helper to connect to the PHY to simplify > the code. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/3] net: mdio-uclass: add dm_eth_phy_connect helper function
On Mon, Nov 25, 2019 at 9:17 AM Alex Marginean wrote: > > The function connects an ethernet device to a PHY using DT information. > This API is only available for eth devices with an associated device tree > node. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/3] net: mdio-uclass: rename arguments of dm_mdio_phy_connect for clarity
On Mon, Nov 25, 2019 at 9:17 AM Alex Marginean wrote: > > Renamed dm_mdio_phy_connect arguments dev to mdiodev and addr to phyaddr > for a bit more clarity and consistency with the following patches. > Also use NULL instead of 0 on error return path. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [GIT] Pull request: u-boot-dfu (29.11.2019)
On 11/30/19 12:25 AM, Lukasz Majewski wrote: > Dear Marek, Hi, > The following changes since commit > dbcbdad92caf4b42a6279da6e65180532bc45620: > > sandbox: enable USB_KEYBOARD_FN_KEYS (2019-11-25 13:28:53 +0100) > > are available in the Git repository at: > > g...@gitlab.denx.de:u-boot/custodians/u-boot-dfu.git > > > BRANCH: master > https://gitlab.denx.de/u-boot/custodians/u-boot-dfu/commits/master > > Merge tag info: > > - Add optional timeout (in seconds) parameter to DFU command. After > this timeout the dfu ends its execution (to avoid waiting forever) > > Note: > > I would prefer if you add those patches into your USB -next branch. So obvious question, why is this not in your u-boot-dfu -next branch ? Is this for next release ? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [GIT] Pull request: u-boot-dfu (29.11.2019)
Dear Marek, The following changes since commit dbcbdad92caf4b42a6279da6e65180532bc45620: sandbox: enable USB_KEYBOARD_FN_KEYS (2019-11-25 13:28:53 +0100) are available in the Git repository at: g...@gitlab.denx.de:u-boot/custodians/u-boot-dfu.git BRANCH: master https://gitlab.denx.de/u-boot/custodians/u-boot-dfu/commits/master Merge tag info: - Add optional timeout (in seconds) parameter to DFU command. After this timeout the dfu ends its execution (to avoid waiting forever) Note: I would prefer if you add those patches into your USB -next branch. for you to fetch changes up to 28e360c6b511a3599ecbfbc33e2d6e96f305985f: x86: edison: Enable DFU timeout (2019-11-29 10:06:40 +0100) Travis-CI: https://travis-ci.org/lmajewski/u-boot-dfu/builds/618507384 Andy Shevchenko (4): dfu: Drop unused prototype of dfu_trigger_reset() dfu: Refactor do_dfu() to handle optional argument dfu: Add optional timeout parameter x86: edison: Enable DFU timeout cmd/dfu.c| 28 +--- common/dfu.c | 17 + configs/edison_defconfig | 1 + doc/README.dfu | 8 ++-- drivers/dfu/Kconfig | 6 ++ drivers/dfu/dfu.c| 15 +++ include/dfu.h| 6 +- 7 files changed, 71 insertions(+), 10 deletions(-) Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpeWdyez4DZj.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] gcc-9: silence 'address-of-packed-member' warning
On Fri, Nov 29, 2019 at 09:29:51PM +0100, Simon Goldschmidt wrote: > > [bringing this back to the list, seems like I accidentally hit the single > reply button before] > > On 29.11.19 21:02, Andy Shevchenko wrote: > > On Fri, Nov 29, 2019 at 06:56:44PM +0100, Simon Goldschmidt wrote: > > > Andy Shevchenko schrieb am Fr., 29. > > > Nov. 2019, 18:48: > > > > > > > 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. > > > > > > > > Repeating Linus' Torvalds commit 6f303d60534c in the Linux kernel. > > > > > > > > Original commit message: > > > > > > > >We already did this for clang, but now gcc has that warning too. > > > >Yes, yes, the address may be unaligned. And that's kind of the > > > > point. > > > > > > > > This in particular hides the warnings like > > > > > > > > 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); > > > > > > > > > > Is it really ok to hide this warning? This address is used for an u16 > > > pointer later, so it needs to be aligned. How do we ensure that wData is > > > correctly aligned? > > > > Why should it be? > > Because this code is working on a packed struct, which may be unaligned. If > it's not, why not remove packing on struct usb_string_descriptor instead of > silencing this warning altogether? > > > It worked before it will work after. > > Who guarantees this struct is aligned/will stay aligned in the future? > > Most of the platforms I know nowadays do work with unaligned access but are > slow, so I think having the compiler warn here is good, no? > > > > > > I took a different approach and fixed the called function to use byte > > > access: > > > > > > https://patchwork.ozlabs.org/patch/1199138/ > > > > So, that commit can be reverted then. > > I admit this commit increases code size, but I'm not convinced that it's not > necessary. If the access is always aligned, let's remove structure packing > instead of reducing compiler warnings. (I still think most compiler warnings > are good, not bad.) In general terms, I agree that warnings can be helpful and good to know when they exist. Perhaps it's worth pursing this in the kernel community to move this from and always-disable to something enabled at a non-default W= number? In more specific terms, we care so very much about binary size, especially when it's not clearly a user-visible performance hit. I do not disagree with "X is technically wrong and should be fixed, now that we see the warning showing it". I also don't disagree with "with some performance profiling we can see that unaligned access $here is a problem". But I do disagree with speculation on future CPUs not supporting unaligned access or that it may be a performance problem. We don't control the former and can investigate the latter. I also don't disagree with "as custodian for X I'm going to fix this problem in my area.". Thanks all! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] gcc-9: silence 'address-of-packed-member' warning
[bringing this back to the list, seems like I accidentally hit the single reply button before] On 29.11.19 21:02, Andy Shevchenko wrote: On Fri, Nov 29, 2019 at 06:56:44PM +0100, Simon Goldschmidt wrote: Andy Shevchenko schrieb am Fr., 29. Nov. 2019, 18:48: 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. Repeating Linus' Torvalds commit 6f303d60534c in the Linux kernel. Original commit message: We already did this for clang, but now gcc has that warning too. Yes, yes, the address may be unaligned. And that's kind of the point. This in particular hides the warnings like 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); Is it really ok to hide this warning? This address is used for an u16 pointer later, so it needs to be aligned. How do we ensure that wData is correctly aligned? Why should it be? Because this code is working on a packed struct, which may be unaligned. If it's not, why not remove packing on struct usb_string_descriptor instead of silencing this warning altogether? > It worked before it will work after. Who guarantees this struct is aligned/will stay aligned in the future? Most of the platforms I know nowadays do work with unaligned access but are slow, so I think having the compiler warn here is good, no? I took a different approach and fixed the called function to use byte access: https://patchwork.ozlabs.org/patch/1199138/ So, that commit can be reverted then. I admit this commit increases code size, but I'm not convinced that it's not necessary. If the access is always aligned, let's remove structure packing instead of reducing compiler warnings. (I still think most compiler warnings are good, not bad.) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/4] cmd: dtimg: Get start and size based on --id and --rev
Currently, it is only possible to get the ${index}'s entry of a DTB/DTBO
image [*]. The "dtimg" command is agnostic on the "id" and "rev" fields
and is unable to take them as input for a more fine-grained DTB/DTBO
search/retrieval.
This is a major limitation, as users would like [**] to employ the
"id"/"rev" fields to e.g. differentiate between DTBs/DTBOs
associated to multiple HW revisions or several platforms.
Given a sample DTBO image [***], the new options work like below:
=> dtimg start 0x4800 0 --id invalid
Error: Bad value '--id=invalid'
=> dtimg start 0x4800 0 --id 0x100
Error: No #0 entry having id=0x100 && rev=0x0
=> dtimg start 0x4800 0 --id 00779000
0x480006ac
=> dtimg start 0x4800 1 --id 00779000
0x48000b46
=> dtimg start 0x4800 2 --id 00779000
Error: No #2 entry having id=0x779000 && rev=0x0
=> dtimg start 0x4800 99 --id 00779000
Error: index >= dt_entry_count (99 >= 6)
=> dtimg start 0x4800 0
0x48e0
=> dtimg start 0x4800 1
0x48e0
=> dtimg start 0x4800 2
0x480004d0
=> dtimg start 0x4800 3
0x480005be
=> dtimg start 0x4800 4
0x480006ac
=> dtimg start 0x4800 5
0x48000b46
=> dtimg start 0x4800 6
Error: index >= dt_entry_count (6 >= 6)
=> dtimg size 0x4800 0 --id 00779000
0x49a
=> dtimg size 0x4800 1 --id 00779000
0x248
[*] https://source.android.com/devices/architecture/dto/partitions
[**] https://patchwork.ozlabs.org/patch/958594/#2302310
[***] Sample/dummy DTBO image:
=> dtimg dump 0x4800
dt_table_header:
magic = d7b7ab1e
total_size = 3470
header_size = 32
dt_entry_size = 32
dt_entry_count = 6
dt_entries_offset = 32
page_size = 4096
version = 0
dt_table_entry[0]:
dt_size = 1008
dt_offset = 224
id = 0b779530
rev =
custom[0] =
custom[1] =
custom[2] =
custom[3] =
(FDT)size = 1008
(FDT)compatible = (unknown)
dt_table_entry[1]:
dt_size = 1008
dt_offset = 224
id = 0b779520
rev =
custom[0] =
custom[1] =
custom[2] =
custom[3] =
(FDT)size = 1008
(FDT)compatible = (unknown)
dt_table_entry[2]:
dt_size = 238
dt_offset = 1232
id = 0b779530
rev =
custom[0] =
custom[1] =
custom[2] =
custom[3] =
(FDT)size = 238
(FDT)compatible = (unknown)
dt_table_entry[3]:
dt_size = 238
dt_offset = 1470
id = 0b779520
rev =
custom[0] =
custom[1] =
custom[2] =
custom[3] =
(FDT)size = 238
(FDT)compatible = (unknown)
dt_table_entry[4]:
dt_size = 1178
dt_offset = 1708
id = 00779000
rev =
custom[0] =
custom[1] =
custom[2] =
custom[3] =
(FDT)size = 1178
(FDT)compatible = (unknown)
dt_table_entry[5]:
dt_size = 584
dt_offset = 2886
id = 00779000
rev =
custom[0] =
custom[1] =
custom[2] =
custom[3] =
(FDT)size = 584
(FDT)compatible = (unknown)
Signed-off-by: Eugeniu Rosca
---
cmd/dtimg.c| 81 +++---
common/image-android-dt.c | 64 --
include/image-android-dt.h | 5 ++-
3 files changed, 138 insertions(+), 12 deletions(-)
diff --git a/cmd/dtimg.c b/cmd/dtimg.c
index 5348a4ad46e8..10e909ce551b 100644
--- a/cmd/dtimg.c
+++ b/cmd/dtimg.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
enum cmd_dtimg_info {
CMD_DTIMG_START = 0,
@@ -48,6 +49,61 @@ static int do_dtimg_dump(cmd_tbl_t *cmdtp, int flag, int
argc,
return CMD_RET_SUCCESS;
}
+static int dtimg_get_opthex(int *argcp, char * const *argvp[], u32 *valp)
+{
+ char *endp;
+ u32 val;
+
+ if (!argcp || !argvp || !valp)
+ return CMD_RET_FAILURE;
+
+ if (*argcp < 2) {
+ printf("Error: Option '%s' expects an argument\n", (*argvp)[0]);
+ return CMD_RET_FAILURE;
+ }
+
+ val = simple_strtoul((*argvp)[1], , 16);
+ if (*endp != '\0') {
+ printf("Error: Bad value '%s=%s'\n", (*argvp)[0], (*argvp)[1]);
+ return
[U-Boot] [PATCH 3/4] cmd: dtimg: Make an optional argument
Unlike dtimg, U-Boot commands like part [1], fstype [2] and uuid [3]
accept an _optional_ parameter, which means that they will
output the result to console whenever is skipped. This is
extremely useful during development.
Allow "dtimg" to behave in a similar fashion [4]. In addition:
- replace env_set() by env_set_hex()
- track and report the failures of env_set_hex()
- amend command's help/usage text
[1] => part start mmc 0 1
800
=> part start mmc 0 1 myvar; print myvar
myvar=800
[2] => fstype mmc 0:1
ext4
=> fstype mmc 0:1 myvar; print myvar
myvar=ext4
[3] => uuid
b3909b50-55df-4173-b83c-b05343d2d5d2
=> uuid myvar; print myvar
myvar=4c04b15f-d0c1-4f98-9aca-ab62a66be864
[4] => dtimg start 0x4800 0
0x48e0
=> dtimg start 0x4800 0 myvar; print myvar
myvar=48e0
Signed-off-by: Eugeniu Rosca
---
cmd/dtimg.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/cmd/dtimg.c b/cmd/dtimg.c
index 5989081b0c14..5348a4ad46e8 100644
--- a/cmd/dtimg.c
+++ b/cmd/dtimg.c
@@ -55,9 +55,10 @@ static int dtimg_get_fdt(int argc, char * const argv[], enum
cmd_dtimg_info cmd)
char *endp;
ulong fdt_addr;
u32 fdt_size;
- char buf[65];
+ ulong envval;
+ int ret;
- if (argc != 4)
+ if (argc < 3)
return CMD_RET_USAGE;
if (dtimg_get_argv_addr(argv[1], _addr) != CMD_RET_SUCCESS)
@@ -74,17 +75,24 @@ static int dtimg_get_fdt(int argc, char * const argv[],
enum cmd_dtimg_info cmd)
switch (cmd) {
case CMD_DTIMG_START:
- snprintf(buf, sizeof(buf), "%lx", fdt_addr);
+ envval = fdt_addr;
break;
case CMD_DTIMG_SIZE:
- snprintf(buf, sizeof(buf), "%x", fdt_size);
+ envval = fdt_size;
break;
default:
printf("Error: Unknown cmd_dtimg_info value: %d\n", cmd);
return CMD_RET_FAILURE;
}
- env_set(argv[3], buf);
+ if (argv[3]) {
+ ret = env_set_hex(argv[3], envval);
+ if (ret)
+ printf("Error(%d) env-setting '%s=0x%lx'\n",
+ ret, argv[3], envval);
+ } else {
+ printf("0x%lx\n", envval);
+ }
return CMD_RET_SUCCESS;
}
@@ -131,12 +139,12 @@ U_BOOT_CMD(
"dump \n"
"- parse specified image and print its structure info\n"
" : image address in RAM, in hex\n"
- "dtimg start \n"
+ "dtimg start []\n"
"- get address (hex) of FDT in the image, by index\n"
" : image address in RAM, in hex\n"
" : index of desired FDT in the image\n"
" : name of variable where to store address of FDT\n"
- "dtimg size \n"
+ "dtimg size []\n"
"- get size (hex, bytes) of FDT in the image, by index\n"
" : image address in RAM, in hex\n"
" : index of desired FDT in the image\n"
--
2.24.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/4] cmd: dtimg: Merge duplicated prints
Getting DTB/DTBO header address happens twice (in do_dtimg_dump and
in dtimg_get_fdt) with duplicating below error messages:
- Error: Wrong image address
- Error: DT image header is incorrect
Reduce the duplication and improve the error message by appending
the faulty address value:
- Error: Wrong image address '0x4800z'
Signed-off-by: Eugeniu Rosca
---
cmd/dtimg.c | 36 +++-
1 file changed, 19 insertions(+), 17 deletions(-)
diff --git a/cmd/dtimg.c b/cmd/dtimg.c
index 2317c859953d..5989081b0c14 100644
--- a/cmd/dtimg.c
+++ b/cmd/dtimg.c
@@ -13,18 +13,13 @@ enum cmd_dtimg_info {
CMD_DTIMG_SIZE,
};
-static int do_dtimg_dump(cmd_tbl_t *cmdtp, int flag, int argc,
-char * const argv[])
+static int dtimg_get_argv_addr(char * const str, ulong *hdr_addrp)
{
char *endp;
- ulong hdr_addr;
+ ulong hdr_addr = simple_strtoul(str, , 16);
- if (argc != 2)
- return CMD_RET_USAGE;
-
- hdr_addr = simple_strtoul(argv[1], , 16);
if (*endp != '\0') {
- printf("Error: Wrong image address\n");
+ printf("Error: Wrong image address '%s'\n", str);
return CMD_RET_FAILURE;
}
@@ -32,6 +27,21 @@ static int do_dtimg_dump(cmd_tbl_t *cmdtp, int flag, int
argc,
printf("Error: DT image header is incorrect\n");
return CMD_RET_FAILURE;
}
+ *hdr_addrp = hdr_addr;
+
+ return CMD_RET_SUCCESS;
+}
+
+static int do_dtimg_dump(cmd_tbl_t *cmdtp, int flag, int argc,
+char * const argv[])
+{
+ ulong hdr_addr;
+
+ if (argc != 2)
+ return CMD_RET_USAGE;
+
+ if (dtimg_get_argv_addr(argv[1], _addr) != CMD_RET_SUCCESS)
+ return CMD_RET_FAILURE;
android_dt_print_contents(hdr_addr);
@@ -50,16 +60,8 @@ static int dtimg_get_fdt(int argc, char * const argv[], enum
cmd_dtimg_info cmd)
if (argc != 4)
return CMD_RET_USAGE;
- hdr_addr = simple_strtoul(argv[1], , 16);
- if (*endp != '\0') {
- printf("Error: Wrong image address\n");
+ if (dtimg_get_argv_addr(argv[1], _addr) != CMD_RET_SUCCESS)
return CMD_RET_FAILURE;
- }
-
- if (!android_dt_check_header(hdr_addr)) {
- printf("Error: DT image header is incorrect\n");
- return CMD_RET_FAILURE;
- }
index = simple_strtoul(argv[2], , 0);
if (*endp != '\0') {
--
2.24.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/4] cmd: dtimg: Report invalid index argument
Being user-friendly is paramount to make any product likeable and
easy to use. Hence, instead of [1], print [2].
[1] dtimg start 0x4800 not-a-number myvar
Error: Wrong index
[2] dtimg start 0x4800 not-a-number myvar
Error: Wrong index 'not-a-number'
Signed-off-by: Eugeniu Rosca
---
cmd/dtimg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cmd/dtimg.c b/cmd/dtimg.c
index 6c5d53cc6808..2317c859953d 100644
--- a/cmd/dtimg.c
+++ b/cmd/dtimg.c
@@ -63,7 +63,7 @@ static int dtimg_get_fdt(int argc, char * const argv[], enum
cmd_dtimg_info cmd)
index = simple_strtoul(argv[2], , 0);
if (*endp != '\0') {
- printf("Error: Wrong index\n");
+ printf("Error: Wrong index '%s'\n", argv[2]);
return CMD_RET_FAILURE;
}
--
2.24.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/4] cmd: dtimg: Enhance with --id and --rev options (take #1)
Dear U-Boot community, As summarized in the title, the motivation behind the series is to primarly allow the Android "dtimg" command (credits to Sam for having it) to actually leverage the specification described in [*]. There are a few collateral improvements and optimizations added as well. The individual patches should be verbose and descriptive enough. The series has been tested on R-Car H3ULCB. All available static analysis tools [**] have been silenced. Your comments would be highly appreciated. [*] https://source.android.com/devices/architecture/dto/partitions [**] smatch, cppecheck, sparse, make W=1 Eugeniu Rosca (4): cmd: dtimg: Report invalid index argument cmd: dtimg: Merge duplicated prints cmd: dtimg: Make an optional argument cmd: dtimg: Get start and size based on --id and --rev cmd/dtimg.c| 133 + common/image-android-dt.c | 64 -- include/image-android-dt.h | 5 +- 3 files changed, 169 insertions(+), 33 deletions(-) -- 2.24.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] gcc-9: silence 'address-of-packed-member' warning
On Fri, Nov 29, 2019 at 07:47:59PM +0200, Andy Shevchenko wrote: > 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. > > Repeating Linus' Torvalds commit 6f303d60534c in the Linux kernel. > > Original commit message: > > We already did this for clang, but now gcc has that warning too. > Yes, yes, the address may be unaligned. And that's kind of the point. > > This in particular hides the warnings like > > 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); > > Signed-off-by: Andy Shevchenko > --- > Makefile | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Makefile b/Makefile > index 7485bc2594..a0469f6a9c 100644 > --- a/Makefile > +++ b/Makefile > @@ -672,11 +672,12 @@ endif > endif > > KBUILD_CFLAGS += $(call cc-option,-Wno-format-nonliteral) > +KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member) > + > ifeq ($(cc-name),clang) > KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,) > KBUILD_CFLAGS += $(call cc-disable-warning, format-invalid-specifier) > KBUILD_CFLAGS += $(call cc-disable-warning, gnu) > -KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member) > KBUILD_CFLAGS += $(call cc-option, -fcatch-undefined-behavior) > endif Ooh, I wish I had thought to look at the kernel a while ago. I very much like this idea and need to run a test to see how much space we re-grain with this patch and reverting the handful of reworks that might not make as much long term sense to do. 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] Load Debian/Fedora via EFI
On 11/29/19 11:16 AM, Michal Simek wrote:
Hi,
I tried to boot latest debian and fedora rootfs via distro boot and
getting errors.
I have tried to run just one command and it is failing.
ZynqMP> bootefi bootmgr ${fdtcontroladdr}
BootOrder not defined
EFI boot manager: Cannot load any image
How to define BootOrder?
Thanks,
Michal
# Booting via boot manager
U-Boot currently has no runtime support for variables. But Linaro is
working on it. So update-grub cannot set the variables for you.
You can use the efidebug command to prepare for booting via the boot
manager:
=> efidebug boot add 0001 Debian mmc 0:1 \
efi/debian/grubarm.efi console=${console}
There seems to be a bug with communication lines in U-Boot. So you
actually have to put this into a single line.
=> efidebug boot order 0001
Use saveenv if you want to save the settings.
If you do not want to use the internal device tree load the proper
device tree, e.g.
=> load mmc 0:2 $fdt_addr_r dtb
Now you are ready to boot via the boot manager:
=> bootefi bootmgr $fdt_addr_r
# Booting via distro defaults
DISTRO_DEFAULTS tries to load the devicetree from ${fdtfile} and the
UEFI binary from efi/boot/bootaa64.efi on ARM64. See
./include/config_distro_bootcmd.h.
OpenBSD and FreeBSD follow the distro boot convention, Debian GRUB does not.
# Booting via boot script.
On Debian I use package flash-kernel to keep /boot/dtb in sync with the
kernel and have a u-boot.scr.uimg script with something like the
following lines:
setenv bootargs console=${console}
load mmc 2:1 ${kernel_addr_r} EFI/debian/grubarm.efi
load mmc 2:2 ${fdt_addr_r} dtb
bootefi ${kernel_addr_r} ${fdt_addr_r}
Alternatively you could use package flash-kernel and implement the
/etc/flash-kernel/preboot.d/
hook to start GRUB, cf.
/etc/flash-kernel/bootscript/bootscr.uboot-generic
I currently have no Fedora system in use.
Best regards
Heinrich
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1] gcc-9: silence 'address-of-packed-member' warning
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. Repeating Linus' Torvalds commit 6f303d60534c in the Linux kernel. Original commit message: We already did this for clang, but now gcc has that warning too. Yes, yes, the address may be unaligned. And that's kind of the point. This in particular hides the warnings like 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); Signed-off-by: Andy Shevchenko --- Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 7485bc2594..a0469f6a9c 100644 --- a/Makefile +++ b/Makefile @@ -672,11 +672,12 @@ endif endif KBUILD_CFLAGS += $(call cc-option,-Wno-format-nonliteral) +KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member) + ifeq ($(cc-name),clang) KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,) KBUILD_CFLAGS += $(call cc-disable-warning, format-invalid-specifier) KBUILD_CFLAGS += $(call cc-disable-warning, gnu) -KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member) KBUILD_CFLAGS += $(call cc-option, -fcatch-undefined-behavior) endif -- 2.24.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Raspberry Pi Compute Module 1 mini-UART
I've done some more digging, and have made a bit of progress (I think).
After fiddling with the device-tree, I've managed to get the serial port to
show up when running `dm tree`. I appended this block to the end of
bcm2835-rpi-b.dts:
{
pinctrl-names = "default";
pinctrl-0 = <_gpio40>;
status = "okay";
};
And the relevant output of `dm tree is:
Classindex Probed Driver Name
-
...
pinconfig 32 [ + ] pinconfig | | |-- uart0_gpio14
...
pinconfig 42 [ ] pinconfig | | |-- uart1_gpio40
...
serial 0 [ + ] bcm283x_pl | |-- serial@7e201000
serial 1 [ ] serial_bcm | |-- serial@7e215040
So that indicates that it sees the serial port, knows which driver to use,
and has the correct address. However it has not probed the device, nor has
it probed the pinconfig that MUXes it to the pin I've set in the dts file.
It also appears to have an index , however specifying CONFIG_CONS_INDEX
doesn't change the port that is used, nor does it change the output of
`dm-tree`.
So I'm still a bit stuck. How do I force uboot to use a different (already
known) serial port for the console? The drivers are there, it sees the port,
it just doesn't want to use it...
--
Sent from: http://u-boot.10912.n7.nabble.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] rockchip: misc: protect serial# from getting overwritten
From: Heiko Stuebner
serial# is one of the vendor properties and thus protected from being
overwritten if already set. If env_set is called anyway this result in
some nasty warnings, so check for presence before trying that.
In the same direction check for the presence of cpuid# and compare it
to the actual hardware and emit a warning if they don't match.
Signed-off-by: Heiko Stuebner
---
arch/arm/mach-rockchip/misc.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-rockchip/misc.c b/arch/arm/mach-rockchip/misc.c
index d0fb3d07a7..545b98baad 100644
--- a/arch/arm/mach-rockchip/misc.c
+++ b/arch/arm/mach-rockchip/misc.c
@@ -91,6 +91,7 @@ int rockchip_cpuid_set(const u8 *cpuid, const u32
cpuid_length)
char cpuid_str[cpuid_length * 2 + 1];
u64 serialno;
char serialno_str[17];
+ const char *oldid;
int i;
memset(cpuid_str, 0, sizeof(cpuid_str));
@@ -112,8 +113,16 @@ int rockchip_cpuid_set(const u8 *cpuid, const u32
cpuid_length)
serialno |= (u64)crc32_no_comp(serialno, high, 8) << 32;
snprintf(serialno_str, sizeof(serialno_str), "%016llx", serialno);
+ oldid = env_get("cpuid#");
+ if (oldid && strcmp(oldid, cpuid_str) != 0)
+ printf("cpuid: value %s present in env does not match hardware
%s\n",
+ oldid, cpuid_str);
+
env_set("cpuid#", cpuid_str);
- env_set("serial#", serialno_str);
+
+ /* Only generate serial# when none is set yet */
+ if (!env_get("serial#"))
+ env_set("serial#", serialno_str);
return 0;
}
--
2.24.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] rockchip: misc: don't fail if eth_addr already set
From: Heiko Stuebner
rockchip_setup_macaddr() runs from an initcall, so returning an error
code will make that initcall fail thus breaking the boot process.
And if an ethernet address is already set this is definitly not a
cause for that, so just return success in that case.
Fixes: 04825384999f ("rockchip: rk3399: derive ethaddr from cpuid");
Signed-off-by: Heiko Stuebner
---
arch/arm/mach-rockchip/misc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-rockchip/misc.c b/arch/arm/mach-rockchip/misc.c
index bed4317f7e..d0fb3d07a7 100644
--- a/arch/arm/mach-rockchip/misc.c
+++ b/arch/arm/mach-rockchip/misc.c
@@ -29,7 +29,7 @@ int rockchip_setup_macaddr(void)
/* Only generate a MAC address, if none is set in the environment */
if (env_get("ethaddr"))
- return -1;
+ return 0;
if (!cpuid) {
debug("%s: could not retrieve 'cpuid#'\n", __func__);
--
2.24.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot-Custodians] [RFC] Eliminate boards not using CONFIG_DM=y
On Fri, Nov 29, 2019 at 06:46:40AM +, Priyanka Jain wrote: > > > >-Original Message- > >From: U-Boot-Custodians On > >Behalf Of Heinrich Schuchardt > >Sent: Tuesday, November 26, 2019 4:46 AM > >To: u-boot-custodi...@lists.denx.de; u-boot-board- > >maintain...@lists.denx.de; U-Boot Mailing List > >Subject: [U-Boot-Custodians] [RFC] Eliminate boards not using CONFIG_DM=y > > > >Dear maintainers, > > > >we have been trying to move to the driver model for several years now. > >Starting in 2018 we have added warnings to the Makefile that boards not > >supporting the driver model will be eliminated. Still 24 % of the > >configuration > >files have not been converted and do not even use CONFIG_DM=y. > > > >If we want to get rid of legacy drivers, at some point we have to remove the > >347 configuration files in the list below not using the driver model. > > > >I suggest to do this directly after the release of v2020.01 scheduled January > >6th. > > > >This should not stop the maintainers from reinserting the boards after > >conversion to the driver model. > > > >Best regards > > > >Heinrich > > > >am3517_crane_defconfig > >apf27_defconfig > >apx4devkit_defconfig > >aristainetos2b_defconfig > >aristainetos2_defconfig > >aristainetos_defconfig > >aspenite_defconfig > >at91rm9200ek_defconfig > >at91rm9200ek_ram_defconfig > >B4420QDS_defconfig > >B4420QDS_NAND_defconfig > >B4420QDS_SPIFLASH_defconfig > >B4860QDS_defconfig > >B4860QDS_NAND_defconfig > >B4860QDS_SPIFLASH_defconfig > >B4860QDS_SRIO_PCIE_BOOT_defconfig > >bcm11130_defconfig > >bcm11130_nand_defconfig > >bcm23550_w1d_defconfig > >bcm28155_ap_defconfig > >bcm28155_w1d_defconfig > >bcm911360_entphn_defconfig > >bcm911360_entphn-ns_defconfig > >bcm911360k_defconfig > >bcm958300k_defconfig > >bcm958300k-ns_defconfig > >bcm958305k_defconfig > >bcm958622hr_defconfig > >bcm958712k_defconfig > >bg0900_defconfig > >BSC9131RDB_NAND_defconfig > >BSC9131RDB_NAND_SYSCLK100_defconfig > >BSC9131RDB_SPIFLASH_defconfig > >BSC9131RDB_SPIFLASH_SYSCLK100_defconfig > >BSC9132QDS_NAND_DDRCLK100_defconfig > >BSC9132QDS_NAND_DDRCLK133_defconfig > >BSC9132QDS_NOR_DDRCLK100_defconfig > >BSC9132QDS_NOR_DDRCLK133_defconfig > >BSC9132QDS_SDCARD_DDRCLK100_defconfig > >BSC9132QDS_SDCARD_DDRCLK133_defconfig > >BSC9132QDS_SPIFLASH_DDRCLK100_defconfig > >BSC9132QDS_SPIFLASH_DDRCLK133_defconfig > >C29XPCIE_defconfig > >C29XPCIE_NAND_defconfig > >C29XPCIE_SPIFLASH_defconfig > >caddy2_defconfig > >cm_t35_defconfig > >cm_t54_defconfig > >Cyrus_P5020_defconfig > >Cyrus_P5040_defconfig > >d2net_v2_defconfig > >dms-ba16-1g_defconfig > >dms-ba16_defconfig > >dockstar_defconfig > >duovero_defconfig > >edb9315a_defconfig > >edminiv2_defconfig > >flea3_defconfig > >gplugd_defconfig > >highbank_defconfig > >hrcon_defconfig > >hrcon_dh_defconfig > >ib62x0_defconfig > >iconnect_defconfig > >inetspace_v2_defconfig > >kc1_defconfig > >kmcoge4_defconfig > >kmcoge5ne_defconfig > >kmeter1_defconfig > >kmopti2_defconfig > >kmsupx5_defconfig > >kmtegr1_defconfig > >kmtepr2_defconfig > >ls2080a_emu_defconfig > >ls2080a_simu_defconfig > >MigoR_defconfig > >mpc8308_p1m_defconfig > >MPC8308RDB_defconfig > >MPC8313ERDB_33_defconfig > >MPC8313ERDB_66_defconfig > >MPC8313ERDB_NAND_33_defconfig > >MPC8313ERDB_NAND_66_defconfig > >MPC8315ERDB_defconfig > >MPC8323ERDB_defconfig > >MPC832XEMDS_ATM_defconfig > >MPC832XEMDS_defconfig > >MPC832XEMDS_HOST_33_defconfig > >MPC832XEMDS_HOST_66_defconfig > >MPC832XEMDS_SLAVE_defconfig > >MPC8349EMDS_defconfig > >MPC8349EMDS_PCI64_defconfig > >MPC8349EMDS_SDRAM_defconfig > >MPC8349EMDS_SLAVE_defconfig > >MPC8349ITX_defconfig > >MPC8349ITXGP_defconfig > >MPC8349ITX_LOWBOOT_defconfig > >MPC837XEMDS_defconfig > >MPC837XEMDS_HOST_defconfig > >MPC837XEMDS_SLAVE_defconfig > >MPC837XERDB_defconfig > >MPC837XERDB_SLAVE_defconfig > >MPC8536DS_36BIT_defconfig > >MPC8536DS_defconfig > >MPC8536DS_SDCARD_defconfig > >MPC8536DS_SPIFLASH_defconfig > >MPC8541CDS_defconfig > >MPC8541CDS_legacy_defconfig > >MPC8544DS_defconfig > >MPC8555CDS_defconfig > >MPC8555CDS_legacy_defconfig > >MPC8568MDS_defconfig > >MPC8569MDS_ATM_defconfig > >MPC8569MDS_defconfig > >MPC8572DS_36BIT_defconfig > >MPC8572DS_defconfig > >MPC8610HPCD_defconfig > >MPC8641HPCN_36BIT_defconfig > >MPC8641HPCN_defconfig > >mx23evk_defconfig > >mx23_olinuxino_defconfig > >mx25pdk_defconfig > >mx28evk_auart_console_defconfig > >mx28evk_defconfig > >mx28evk_nand_defconfig > >mx28evk_spi_defconfig > >mx31pdk_defconfig > >mx35pdk_defconfig > >mx51evk_defconfig > >mx53ard_defconfig > >mx53evk_defconfig > >mx53loco_defconfig > >mx53smd_defconfig > >mx6dlarm2_defconfig > >mx6dlarm2_lpddr2_defconfig > >mx6memcal_defconfig > >mx6qarm2_defconfig > >mx6qarm2_lpddr2_defconfig > >net2big_v2_defconfig > >netspace_lite_v2_defconfig > >netspace_max_v2_defconfig > >netspace_mini_v2_defconfig > >netspace_v2_defconfig > >nokia_rx51_defconfig > >nsa310s_defconfig > >omap3_ha_defconfig > >omap4_panda_defconfig >
[U-Boot] amlogic a96 mini
Hi, I'm trying to run mainline u-boot on amlogic a96mini device but before I try to flash it does anybody have an idea if it will work on mainline. As I have limited number of devices and I know that after flashing I can brick the board so would like to ask if anybody have experience with this device and running mainline. Thanks and BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Load Debian/Fedora via EFI
Hi,
I tried to boot latest debian and fedora rootfs via distro boot and
getting errors.
I have tried to run just one command and it is failing.
ZynqMP> bootefi bootmgr ${fdtcontroladdr}
BootOrder not defined
EFI boot manager: Cannot load any image
How to define BootOrder?
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [v2 6/8] dm: arm: ls1043a: add i2c DM support
This supports i2c DM and enables CONFIG_DM_I2C
for SoC LS1043A
Signed-off-by: Biwen Li
---
Changes in v2:
- merge some patches to one patch
arch/arm/include/asm/gpio.h | 2 +-
board/freescale/ls1043aqds/ls1043aqds.c | 97 +--
configs/ls1043aqds_defconfig | 2 +
configs/ls1043aqds_lpuart_defconfig | 2 +
configs/ls1043aqds_nand_defconfig | 2 +
configs/ls1043aqds_nor_ddr3_defconfig | 2 +
configs/ls1043aqds_qspi_defconfig | 2 +
configs/ls1043aqds_sdcard_ifc_defconfig | 2 +
configs/ls1043aqds_sdcard_qspi_defconfig | 2 +
configs/ls1043aqds_tfa_SECURE_BOOT_defconfig | 2 +
configs/ls1043aqds_tfa_defconfig | 2 +
configs/ls1043ardb_SECURE_BOOT_defconfig | 2 +
configs/ls1043ardb_defconfig | 2 +
configs/ls1043ardb_nand_SECURE_BOOT_defconfig | 2 +
configs/ls1043ardb_nand_defconfig | 2 +
.../ls1043ardb_sdcard_SECURE_BOOT_defconfig | 2 +
configs/ls1043ardb_sdcard_defconfig | 2 +
configs/ls1043ardb_tfa_SECURE_BOOT_defconfig | 2 +
configs/ls1043ardb_tfa_defconfig | 2 +
include/configs/ls1043a_common.h | 5 +
20 files changed, 131 insertions(+), 7 deletions(-)
diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h
index 9f8c9da564..45cb04801c 100644
--- a/arch/arm/include/asm/gpio.h
+++ b/arch/arm/include/asm/gpio.h
@@ -3,7 +3,7 @@
!defined(CONFIG_ARCH_BCM63158) && !defined(CONFIG_ARCH_ROCKCHIP) && \
!defined(CONFIG_ARCH_LX2160A) && !defined(CONFIG_ARCH_LS1028A) && \
!defined(CONFIG_ARCH_LS2080A) && !defined(CONFIG_ARCH_LS1088A) && \
- !defined(CONFIG_ARCH_LS1012A) && \
+ !defined(CONFIG_ARCH_LS1012A) && !defined(CONFIG_ARCH_LS1043A) && \
!defined(CONFIG_ARCH_ASPEED)
#include
#endif
diff --git a/board/freescale/ls1043aqds/ls1043aqds.c
b/board/freescale/ls1043aqds/ls1043aqds.c
index 8c96b962b7..a0680d513e 100644
--- a/board/freescale/ls1043aqds/ls1043aqds.c
+++ b/board/freescale/ls1043aqds/ls1043aqds.c
@@ -271,11 +271,24 @@ unsigned long get_board_ddr_clk(void)
return ;
}
-int select_i2c_ch_pca9547(u8 ch)
+int select_i2c_ch_pca9547(u8 ch, int bus_num)
{
int ret;
+#ifdef CONFIG_DM_I2C
+ struct udevice *dev;
+
+ ret = i2c_get_chip_for_busnum(bus_num, I2C_MUX_PCA_ADDR_PRI,
+ 1, );
+ if (ret) {
+ printf("%s: Cannot find udev for a bus %d\n", __func__,
+ bus_num);
+ return ret;
+ }
+ ret = dm_i2c_write(dev, 0, , 1);
+#else
ret = i2c_write(I2C_MUX_PCA_ADDR_PRI, 0, 1, , 1);
+#endif
if (ret) {
puts("PCA: failed to select proper channel\n");
return ret;
@@ -290,8 +303,10 @@ int dram_init(void)
* When resuming from deep sleep, the I2C channel may not be
* in the default channel. So, switch to the default channel
* before accessing DDR SPD.
+*
+* PCA9547 mount on I2C1 bus
*/
- select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT);
+ select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT, 0);
fsl_initdram();
#if (!defined(CONFIG_SPL) && !defined(CONFIG_TFABOOT)) || \
defined(CONFIG_SPL_BUILD)
@@ -304,16 +319,83 @@ int dram_init(void)
int i2c_multiplexer_select_vid_channel(u8 channel)
{
- return select_i2c_ch_pca9547(channel);
+ return select_i2c_ch_pca9547(channel, 0);
}
void board_retimer_init(void)
{
u8 reg;
+ int bus_num = 0;
/* Retimer is connected to I2C1_CH7_CH5 */
- select_i2c_ch_pca9547(I2C_MUX_CH7);
+ select_i2c_ch_pca9547(I2C_MUX_CH7, bus_num);
reg = I2C_MUX_CH5;
+#ifdef CONFIG_DM_I2C
+ struct udevice *dev;
+ int ret;
+
+ ret = i2c_get_chip_for_busnum(bus_num, I2C_MUX_PCA_ADDR_SEC,
+ 1, );
+ if (ret) {
+ printf("%s: Cannot find udev for a bus %d\n", __func__,
+ bus_num);
+ return;
+ }
+ dm_i2c_write(dev, 0, , 1);
+
+ /* Access to Control/Shared register */
+ ret = i2c_get_chip_for_busnum(bus_num, I2C_RETIMER_ADDR,
+ 1, );
+ if (ret) {
+ printf("%s: Cannot find udev for a bus %d\n", __func__,
+ bus_num);
+ return;
+ }
+
+ reg = 0x0;
+ dm_i2c_write(dev, 0xff, , 1);
+
+ /* Read device revision and ID */
+ dm_i2c_read(dev, 1, , 1);
+ debug("Retimer version id = 0x%x\n", reg);
+
+ /* Enable Broadcast. All writes target all channel register sets */
+ reg = 0x0c;
+ dm_i2c_write(dev, 0xff, , 1);
+
+ /* Reset Channel Registers */
+ dm_i2c_read(dev, 0, , 1);
+ reg |= 0x4;
+ dm_i2c_write(dev, 0, , 1);
+
+ /* Enable override
[U-Boot] [v2 5/8] dm: ls1012a: add i2c DM support
This supports i2c DM and enables CONFIG_DM_I2C
for SoC LS1012A
Signed-off-by: Biwen Li
---
Changes in v2:
- merge some patches to one patch
arch/arm/include/asm/gpio.h | 1 +
board/freescale/ls1012aqds/ls1012aqds.c | 20 ++-
board/freescale/ls1012ardb/eth.c | 35 +
board/freescale/ls1012ardb/ls1012ardb.c | 147 +++---
configs/ls1012a2g5rdb_qspi_defconfig | 3 +
configs/ls1012a2g5rdb_tfa_defconfig | 3 +
configs/ls1012afrdm_qspi_defconfig| 3 +
configs/ls1012afrdm_tfa_defconfig | 3 +
.../ls1012afrwy_qspi_SECURE_BOOT_defconfig| 3 +
configs/ls1012afrwy_qspi_defconfig| 3 +
configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig | 3 +
configs/ls1012afrwy_tfa_defconfig | 3 +
configs/ls1012aqds_qspi_defconfig | 3 +
configs/ls1012aqds_tfa_SECURE_BOOT_defconfig | 3 +
configs/ls1012aqds_tfa_defconfig | 3 +
configs/ls1012ardb_qspi_SECURE_BOOT_defconfig | 3 +
configs/ls1012ardb_qspi_defconfig | 3 +
configs/ls1012ardb_tfa_SECURE_BOOT_defconfig | 3 +
configs/ls1012ardb_tfa_defconfig | 3 +
include/configs/ls1012a_common.h | 5 +
20 files changed, 227 insertions(+), 26 deletions(-)
diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h
index 6ff5f42424..9f8c9da564 100644
--- a/arch/arm/include/asm/gpio.h
+++ b/arch/arm/include/asm/gpio.h
@@ -3,6 +3,7 @@
!defined(CONFIG_ARCH_BCM63158) && !defined(CONFIG_ARCH_ROCKCHIP) && \
!defined(CONFIG_ARCH_LX2160A) && !defined(CONFIG_ARCH_LS1028A) && \
!defined(CONFIG_ARCH_LS2080A) && !defined(CONFIG_ARCH_LS1088A) && \
+ !defined(CONFIG_ARCH_LS1012A) && \
!defined(CONFIG_ARCH_ASPEED)
#include
#endif
diff --git a/board/freescale/ls1012aqds/ls1012aqds.c
b/board/freescale/ls1012aqds/ls1012aqds.c
index 86c72ee357..30bf1047d5 100644
--- a/board/freescale/ls1012aqds/ls1012aqds.c
+++ b/board/freescale/ls1012aqds/ls1012aqds.c
@@ -107,10 +107,26 @@ int board_early_init_f(void)
int misc_init_r(void)
{
u8 mux_sdhc_cd = 0x80;
-
- i2c_set_bus_num(0);
+ int bus_num = 0;
+
+#ifdef CONFIG_DM_I2C
+ struct udevice *dev;
+ int ret;
+
+ ret = i2c_get_chip_for_busnum(bus_num, CONFIG_SYS_I2C_FPGA_ADDR,
+ 1, );
+ if (ret) {
+ printf("%s: Cannot find udev for a bus %d\n", __func__,
+ bus_num);
+ return ret;
+ }
+ dm_i2c_write(dev, 0x5a, _sdhc_cd, 1);
+#else
+ i2c_set_bus_num(bus_num);
i2c_write(CONFIG_SYS_I2C_FPGA_ADDR, 0x5a, 1, _sdhc_cd, 1);
+#endif
+
return 0;
}
#endif
diff --git a/board/freescale/ls1012ardb/eth.c b/board/freescale/ls1012ardb/eth.c
index b35d5343e4..0f33128996 100644
--- a/board/freescale/ls1012ardb/eth.c
+++ b/board/freescale/ls1012ardb/eth.c
@@ -27,12 +27,47 @@ static inline void ls1012ardb_reset_phy(void)
{
#ifdef CONFIG_TARGET_LS1012ARDB
/* Through reset IO expander reset both RGMII and SGMII PHYs */
+#ifdef CONFIG_DM_I2C
+ struct udevice *dev;
+ int ret;
+
+ /*
+* The I2C IO-expander PCAL9555A is mouted on I2C1 bus(bus number is 0).
+*/
+ ret = i2c_get_chip_for_busnum(0, I2C_MUX_IO2_ADDR,
+ 1, );
+ if (ret) {
+ printf("%s: Cannot find udev for a bus %d\n", __func__,
+ 0);
+ return;
+ }
+ /* Config port 0
+* - config pin IOXP_RST_ETH1_B and IOXP_RST_ETH2_B
+* are enabled as an output.
+*/
+ dm_i2c_reg_write(dev, 6, __PHY_MASK);
+
+ /*
+* Set port 0 output a value to reset ETH2 interface
+* - pin IOXP_RST_ETH2_B output 0b0
+*/
+ dm_i2c_reg_write(dev, 2, __PHY_ETH2_MASK);
+ mdelay(10);
+ dm_i2c_reg_write(dev, 2, __PHY_ETH1_MASK);
+ /*
+* Set port 0 output a value to reset ETH1 interface
+* - pin IOXP_RST_ETH1_B output 0b0
+*/
+ mdelay(10);
+ dm_i2c_reg_write(dev, 2, 0xFF);
+#else
i2c_reg_write(I2C_MUX_IO2_ADDR, 6, __PHY_MASK);
i2c_reg_write(I2C_MUX_IO2_ADDR, 2, __PHY_ETH2_MASK);
mdelay(10);
i2c_reg_write(I2C_MUX_IO2_ADDR, 2, __PHY_ETH1_MASK);
mdelay(10);
i2c_reg_write(I2C_MUX_IO2_ADDR, 2, 0xFF);
+#endif
mdelay(50);
#endif
}
diff --git a/board/freescale/ls1012ardb/ls1012ardb.c
b/board/freescale/ls1012ardb/ls1012ardb.c
index e4527c19b8..271227a976 100644
--- a/board/freescale/ls1012ardb/ls1012ardb.c
+++ b/board/freescale/ls1012ardb/ls1012ardb.c
@@ -32,13 +32,27 @@ int checkboard(void)
{
#ifdef CONFIG_TARGET_LS1012ARDB
u8 in1;
+ int ret, bus_num = 0;
puts("Board: LS1012ARDB ");
/* Initialize i2c early for Serial flash bank information */
-
[U-Boot] [v2 7/8] dm: arm: ls1046a: add i2c DM support
This supports i2c DM and enables CONFIG_DM_I2C
for SoC LS1046A
Signed-off-by: Biwen Li
---
Changes in v2:
- merge some patches to one patch
arch/arm/dts/fsl-ls1046a-frwy.dts | 3 ++
arch/arm/dts/fsl-ls1046a-qds.dtsi | 4 ++
arch/arm/dts/fsl-ls1046a-rdb.dts | 8
arch/arm/include/asm/gpio.h | 1 +
board/freescale/ls1046afrwy/ls1046afrwy.c | 17 ++-
board/freescale/ls1046aqds/ls1046aqds.c | 24 --
configs/ls1046afrwy_tfa_defconfig | 2 +
configs/ls1046aqds_SECURE_BOOT_defconfig | 2 +
configs/ls1046aqds_defconfig | 2 +
configs/ls1046aqds_lpuart_defconfig | 2 +
configs/ls1046aqds_nand_defconfig | 2 +
configs/ls1046aqds_qspi_defconfig | 2 +
configs/ls1046aqds_sdcard_ifc_defconfig | 2 +
configs/ls1046aqds_sdcard_qspi_defconfig | 2 +
configs/ls1046aqds_tfa_SECURE_BOOT_defconfig | 2 +
configs/ls1046aqds_tfa_defconfig | 2 +
configs/ls1046ardb_emmc_defconfig | 2 +
configs/ls1046ardb_qspi_SECURE_BOOT_defconfig | 2 +
configs/ls1046ardb_qspi_defconfig | 2 +
configs/ls1046ardb_qspi_spl_defconfig | 2 +
.../ls1046ardb_sdcard_SECURE_BOOT_defconfig | 2 +
configs/ls1046ardb_sdcard_defconfig | 2 +
configs/ls1046ardb_tfa_SECURE_BOOT_defconfig | 2 +
configs/ls1046ardb_tfa_defconfig | 2 +
drivers/power/power_i2c.c | 45 ++-
include/configs/ls1046a_common.h | 6 +++
26 files changed, 136 insertions(+), 8 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1046a-frwy.dts
b/arch/arm/dts/fsl-ls1046a-frwy.dts
index 3d41e3bd44..d39159322a 100644
--- a/arch/arm/dts/fsl-ls1046a-frwy.dts
+++ b/arch/arm/dts/fsl-ls1046a-frwy.dts
@@ -32,3 +32,6 @@
};
+ {
+ status = "okay";
+};
diff --git a/arch/arm/dts/fsl-ls1046a-qds.dtsi
b/arch/arm/dts/fsl-ls1046a-qds.dtsi
index c95f44fc36..76dc397328 100644
--- a/arch/arm/dts/fsl-ls1046a-qds.dtsi
+++ b/arch/arm/dts/fsl-ls1046a-qds.dtsi
@@ -80,3 +80,7 @@
{
status = "okay";
};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/dts/fsl-ls1046a-rdb.dts b/arch/arm/dts/fsl-ls1046a-rdb.dts
index a05c9e9b9e..83e34ab02a 100644
--- a/arch/arm/dts/fsl-ls1046a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1046a-rdb.dts
@@ -43,3 +43,11 @@
{
status = "okay";
};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h
index 45cb04801c..9adebf6c04 100644
--- a/arch/arm/include/asm/gpio.h
+++ b/arch/arm/include/asm/gpio.h
@@ -4,6 +4,7 @@
!defined(CONFIG_ARCH_LX2160A) && !defined(CONFIG_ARCH_LS1028A) && \
!defined(CONFIG_ARCH_LS2080A) && !defined(CONFIG_ARCH_LS1088A) && \
!defined(CONFIG_ARCH_LS1012A) && !defined(CONFIG_ARCH_LS1043A) && \
+ !defined(CONFIG_ARCH_LS1046A) && \
!defined(CONFIG_ARCH_ASPEED)
#include
#endif
diff --git a/board/freescale/ls1046afrwy/ls1046afrwy.c
b/board/freescale/ls1046afrwy/ls1046afrwy.c
index ac2f8ee436..4a9189b3ee 100644
--- a/board/freescale/ls1046afrwy/ls1046afrwy.c
+++ b/board/freescale/ls1046afrwy/ls1046afrwy.c
@@ -35,11 +35,24 @@
DECLARE_GLOBAL_DATA_PTR;
-int select_i2c_ch_pca9547(u8 ch)
+int select_i2c_ch_pca9547(u8 ch, int bus_num)
{
int ret;
+#ifdef CONFIG_DM_I2C
+ struct udevice *dev;
+
+ ret = i2c_get_chip_for_busnum(bus_num, I2C_MUX_PCA_ADDR_PRI,
+ 1, );
+ if (ret) {
+ printf("%s: Cannot find udev for a bus %d\n", __func__,
+ bus_num);
+ return ret;
+ }
+ ret = dm_i2c_write(dev, 0, , 1);
+#else
ret = i2c_write(I2C_MUX_PCA_ADDR_PRI, 0, 1, , 1);
+#endif
if (ret) {
puts("PCA: failed to select proper channel\n");
return ret;
@@ -144,7 +157,7 @@ val = (in_le32(SMMU_SCR0) | SCR0_CLIENTPD_MASK) &
~(SCR0_USFCFG_MASK);
sec_init();
#endif
- select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT);
+ select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT, 0);
return 0;
}
diff --git a/board/freescale/ls1046aqds/ls1046aqds.c
b/board/freescale/ls1046aqds/ls1046aqds.c
index aac5d9aa84..e8d321b6c1 100644
--- a/board/freescale/ls1046aqds/ls1046aqds.c
+++ b/board/freescale/ls1046aqds/ls1046aqds.c
@@ -269,11 +269,23 @@ u32 get_lpuart_clk(void)
}
#endif
-int select_i2c_ch_pca9547(u8 ch)
+int select_i2c_ch_pca9547(u8 ch, int bus_num)
{
int ret;
+#ifdef CONFIG_DM_I2C
+ struct udevice *dev;
+ ret = i2c_get_chip_for_busnum(bus_num, I2C_MUX_PCA_ADDR_PRI,
+ 1, );
+ if (ret) {
+ printf("%s: Cannot find udev for a bus %d\n", __func__,
+ bus_num);
+ return ret;
+ }
+ ret = dm_i2c_write(dev, 0, , 1);
+#else
ret =
[U-Boot] [v2 2/8] armv8: fsl-layerscape: spl: fix build error when enabled CONFIG_DM_I2C
This is used to fix build error as follows: - arch/arm/cpu/armv8/built-in.o: In function `board_init_f: arch/arm/cpu/armv8/fsl-layerscape/spl.c:74: undefined reference to `i2c_init_all' arch/arm/cpu/armv8/fsl-layerscape/spl.c:74:(.text.board_init_f+0x30): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `i2c_init_all' make[2]: *** [spl/u-boot-spl] Error 1 make[1]: *** [spl/u-boot-spl] Error 2 make: *** [sub-make] Error 2 arch/arm/cpu/armv8/fsl-layerscape/spl.c: In function 'board_init_f': arch/arm/cpu/armv8/fsl-layerscape/spl.c:74:2: warning: implicit declaration of function 'i2c_init_all'; did you mean 'misc_init_r'? [-Wimplicit-function-declaration]` Signed-off-by: Biwen Li --- Changes in v2: - none arch/arm/cpu/armv8/fsl-layerscape/spl.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/spl.c b/arch/arm/cpu/armv8/fsl-layerscape/spl.c index 3f6a5f6a42..f792db9cd8 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/spl.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/spl.c @@ -70,9 +70,11 @@ void board_init_f(ulong dummy) preloader_console_init(); spl_set_bd(); +#ifdef CONFIG_SYS_I2C #ifdef CONFIG_SPL_I2C_SUPPORT i2c_init_all(); #endif +#endif #ifdef CONFIG_VID init_func_vid(); #endif -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [v2 8/8] dm: arm: ls1021a: add i2c DM support
This supports i2c DM and enables CONFIG_DM_I2C
for SoC LS1021A
Signed-off-by: Biwen Li
---
Changes in v2:
- merge some patches to one patch
board/freescale/common/dcu_sii9022a.c | 94 +++
board/freescale/common/diu_ch7301.c | 79
board/freescale/ls1021aqds/dcu.c | 43 -
board/freescale/ls1021aqds/ls1021aqds.c | 20 +++-
board/freescale/ls1021atwr/ls1021atwr.c | 26 -
configs/ls1021aiot_qspi_defconfig | 2 +
configs/ls1021aiot_sdcard_defconfig | 2 +
configs/ls1021aqds_ddr4_nor_defconfig | 2 +
configs/ls1021aqds_ddr4_nor_lpuart_defconfig | 2 +
configs/ls1021aqds_nand_defconfig | 2 +
configs/ls1021aqds_nor_SECURE_BOOT_defconfig | 2 +
configs/ls1021aqds_nor_defconfig | 2 +
configs/ls1021aqds_nor_lpuart_defconfig | 2 +
configs/ls1021aqds_qspi_defconfig | 2 +
configs/ls1021aqds_sdcard_ifc_defconfig | 2 +
configs/ls1021aqds_sdcard_qspi_defconfig | 2 +
configs/ls1021atsn_qspi_defconfig | 2 +
configs/ls1021atsn_sdcard_defconfig | 2 +
configs/ls1021atwr_nor_SECURE_BOOT_defconfig | 2 +
configs/ls1021atwr_nor_defconfig | 2 +
configs/ls1021atwr_nor_lpuart_defconfig | 2 +
configs/ls1021atwr_qspi_defconfig | 2 +
...s1021atwr_sdcard_ifc_SECURE_BOOT_defconfig | 2 +
configs/ls1021atwr_sdcard_ifc_defconfig | 2 +
configs/ls1021atwr_sdcard_qspi_defconfig | 2 +
include/configs/ls1021aiot.h | 3 +
include/configs/ls1021aqds.h | 2 +
include/configs/ls1021atsn.h | 2 +
include/configs/ls1021atwr.h | 3 +
29 files changed, 305 insertions(+), 7 deletions(-)
diff --git a/board/freescale/common/dcu_sii9022a.c
b/board/freescale/common/dcu_sii9022a.c
index 3bf71abf55..736b689e08 100644
--- a/board/freescale/common/dcu_sii9022a.c
+++ b/board/freescale/common/dcu_sii9022a.c
@@ -63,7 +63,100 @@ int dcu_set_dvi_encoder(struct fb_videomode *videomode)
u8 temp;
u16 temp1, temp2;
u32 temp3;
+#ifdef CONFIG_DM_I2C
+ struct udevice *dev;
+ int ret;
+
+ ret = i2c_get_chip_for_busnum(CONFIG_SYS_I2C_DVI_BUS_NUM,
CONFIG_SYS_I2C_DVI_ADDR,
+ 1, );
+ if (ret) {
+ printf("%s: Cannot find udev for a bus %d\n", __func__,
+ CONFIG_SYS_I2C_DVI_BUS_NUM);
+ return ret;
+ }
+ /* Enable TPI transmitter mode */
+ temp = TPI_TRANS_MODE_ENABLE;
+ dm_i2c_write(dev, TPI_TRANS_MODE_REG, , 1);
+
+ /* Enter into D0 state, full operation */
+ dm_i2c_read(dev, TPI_PWR_STAT_REG, , 1);
+ temp &= ~TPI_PWR_STAT_MASK;
+ temp |= TPI_PWR_STAT_D0;
+ dm_i2c_write(dev, TPI_PWR_STAT_REG, , 1);
+
+ /* Enable source termination */
+ temp = TPI_SET_PAGE_SII9022A;
+ dm_i2c_write(dev, TPI_SET_PAGE_REG, , 1);
+ temp = TPI_SET_OFFSET_SII9022A;
+ dm_i2c_write(dev, TPI_SET_OFFSET_REG, , 1);
+
+ dm_i2c_read(dev, TPI_RW_ACCESS_REG, , 1);
+ temp |= TPI_RW_EN_SRC_TERMIN;
+ dm_i2c_write(dev, TPI_RW_ACCESS_REG, , 1);
+
+ /* Set TPI system control */
+ temp = TPI_SYS_TMDS_OUTPUT | TPI_SYS_AV_NORAML | TPI_SYS_DVI_MODE;
+ dm_i2c_write(dev, TPI_SYS_CTRL_REG, , 1);
+
+ /* Set pixel clock */
+ temp1 = PICOS2KHZ(videomode->pixclock) / 10;
+ temp = (u8)(temp1 & 0xFF);
+ dm_i2c_write(dev, PIXEL_CLK_LSB_REG, , 1);
+ temp = (u8)(temp1 >> 8);
+ dm_i2c_write(dev, PIXEL_CLK_MSB_REG, , 1);
+
+ /* Set total pixels per line */
+ temp1 = videomode->hsync_len + videomode->left_margin +
+ videomode->xres + videomode->right_margin;
+ temp = (u8)(temp1 & 0xFF);
+ dm_i2c_write(dev, TOTAL_PIXELS_LSB_REG, , 1);
+ temp = (u8)(temp1 >> 8);
+ dm_i2c_write(dev, TOTAL_PIXELS_MSB_REG, , 1);
+
+ /* Set total lines */
+ temp2 = videomode->vsync_len + videomode->upper_margin +
+ videomode->yres + videomode->lower_margin;
+ temp = (u8)(temp2 & 0xFF);
+ dm_i2c_write(dev, TOTAL_LINES_LSB_REG, , 1);
+ temp = (u8)(temp2 >> 8);
+ dm_i2c_write(dev, TOTAL_LINES_MSB_REG, , 1);
+
+ /* Set vertical frequency in Hz */
+ temp3 = temp1 * temp2;
+ temp3 = (PICOS2KHZ(videomode->pixclock) * 1000) / temp3;
+ temp1 = (u16)temp3 * 100;
+ temp = (u8)(temp1 & 0xFF);
+ dm_i2c_write(dev, VERT_FREQ_LSB_REG, , 1);
+ temp = (u8)(temp1 >> 8);
+ dm_i2c_write(dev, VERT_FREQ_MSB_REG, , 1);
+
+ /* Set TPI input bus and pixel repetition data */
+ temp = TPI_INBUS_CLOCK_RATIO_1 | TPI_INBUS_FULL_PIXEL_WIDE |
+ TPI_INBUS_RISING_EDGE;
+ dm_i2c_write(dev, TPI_INBUS_FMT_REG, , 1);
+
+ /* Set TPI AVI Input format data */
+ temp =
[U-Boot] [v2 4/8] Kconfigs: layerscape: use a convenient default value for SYS_MALLOC_F_LEN
The default value of CONFIG_SYS_MALLOC_F_LEN (0x400) leaves U-Boot with not enough memory to do this, causing it to hang. Fix this problem by providing a convenient default value for CONFIG_SYS_MALLOC_F_LEN. Relative SoC: - LS1012A - LS1021A - LS1043A - LS1046A Signed-off-by: Biwen Li --- Changes in v2: - none Kconfig | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Kconfig b/Kconfig index e22417ec44..3e6d9f26ea 100644 --- a/Kconfig +++ b/Kconfig @@ -146,7 +146,9 @@ config SYS_MALLOC_F_LEN default 0x1000 if AM33XX default 0x2800 if SANDBOX default 0x2000 if (ARCH_IMX8 || ARCH_IMX8M || ARCH_MX7 || \ - ARCH_MX7ULP || ARCH_MX6 || ARCH_MX5) + ARCH_MX7ULP || ARCH_MX6 || ARCH_MX5 || \ + ARCH_LS1012A || ARCH_LS1021A || ARCH_LS1043A || \ + ARCH_LS1046A) default 0x400 help Before relocation, memory is very limited on many platforms. Still, -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [v2 3/8] i2c: mxc_i2c: add DM_FLAG_PRE_RELOC flag
This adds DM_FLAG_PRE_RELOC flag to probe i2c driver
before relocation
Signed-off-by: Biwen Li
---
Changes in v2:
- none
drivers/i2c/mxc_i2c.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c
index 786b5a2226..6b7ce985b3 100644
--- a/drivers/i2c/mxc_i2c.c
+++ b/drivers/i2c/mxc_i2c.c
@@ -1049,5 +1049,6 @@ U_BOOT_DRIVER(i2c_mxc) = {
.probe = mxc_i2c_probe,
.priv_auto_alloc_size = sizeof(struct mxc_i2c_bus),
.ops = _i2c_ops,
+ .flags = DM_FLAG_PRE_RELOC,
};
#endif
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [v2 1/8] rtc: pcf8563: support driver model
This supports driver model to
drop warning as follows:
- drivers/rtc/pcf8563.c: In function rtc_read:
drivers/rtc/pcf8563.c:111:10: warning: implicit declaration of function
i2c_reg_read; did you mean dm_i2c_reg_read? [-Wimplicit-function-declaration
drivers/rtc/pcf8563.c: In function rtc_write:
drivers/rtc/pcf8563.c:116:2: warning: implicit declaration of function
i2c_reg_write; did you mean dm_i2c_reg_write? [-Wimplicit-function-declaration]
Signed-off-by: Biwen Li
---
Changes in v2:
- none
drivers/rtc/pcf8563.c | 107 ++
1 file changed, 107 insertions(+)
diff --git a/drivers/rtc/pcf8563.c b/drivers/rtc/pcf8563.c
index a839d6cc98..44204e133e 100644
--- a/drivers/rtc/pcf8563.c
+++ b/drivers/rtc/pcf8563.c
@@ -12,9 +12,11 @@
#include
#include
+#include
#include
#include
+#if !CONFIG_IS_ENABLED(DM_RTC)
static uchar rtc_read (uchar reg);
static void rtc_write (uchar reg, uchar val);
@@ -115,3 +117,108 @@ static void rtc_write (uchar reg, uchar val)
{
i2c_reg_write (CONFIG_SYS_I2C_RTC_ADDR, reg, val);
}
+#else
+static int pcf8563_rtc_get(struct udevice *dev, struct rtc_time *tmp)
+{
+ int rel = 0;
+ uchar sec, min, hour, mday, wday, mon_cent, year;
+
+ sec = dm_i2c_reg_read(dev, 0x02);
+ min = dm_i2c_reg_read(dev, 0x03);
+ hour= dm_i2c_reg_read(dev, 0x04);
+ mday= dm_i2c_reg_read(dev, 0x05);
+ wday= dm_i2c_reg_read(dev, 0x06);
+ mon_cent = dm_i2c_reg_read(dev, 0x07);
+ year= dm_i2c_reg_read(dev, 0x08);
+
+ debug ("Get RTC year: %02x mon/cent: %02x mday: %02x wday: %02x "
+ "hr: %02x min: %02x sec: %02x\n",
+ year, mon_cent, mday, wday,
+ hour, min, sec);
+ debug ("Alarms: wday: %02x day: %02x hour: %02x min: %02x\n",
+ dm_i2c_reg_read(dev, 0x0C),
+ dm_i2c_reg_read(dev, 0x0B),
+ dm_i2c_reg_read(dev, 0x0A),
+ dm_i2c_reg_read(dev, 0x09));
+
+ if (sec & 0x80) {
+ puts ("### Warning: RTC Low Voltage - date/time not
reliable\n");
+ rel = -1;
+ }
+
+ tmp->tm_sec = bcd2bin (sec & 0x7F);
+ tmp->tm_min = bcd2bin (min & 0x7F);
+ tmp->tm_hour = bcd2bin (hour & 0x3F);
+ tmp->tm_mday = bcd2bin (mday & 0x3F);
+ tmp->tm_mon = bcd2bin (mon_cent & 0x1F);
+ tmp->tm_year = bcd2bin (year) + ((mon_cent & 0x80) ? 1900 : 2000);
+ tmp->tm_wday = bcd2bin (wday & 0x07);
+ tmp->tm_yday = 0;
+ tmp->tm_isdst = 0;
+
+ debug ("Get DATE: %4d-%02d-%02d (wday=%d) TIME: %2d:%02d:%02d\n",
+ tmp->tm_year, tmp->tm_mon, tmp->tm_mday, tmp->tm_wday,
+ tmp->tm_hour, tmp->tm_min, tmp->tm_sec);
+
+ return rel;
+}
+
+static int pcf8563_rtc_set(struct udevice *dev, const struct rtc_time *tmp)
+{
+ uchar century;
+
+ debug ("Set DATE: %4d-%02d-%02d (wday=%d) TIME: %2d:%02d:%02d\n",
+ tmp->tm_year, tmp->tm_mon, tmp->tm_mday, tmp->tm_wday,
+ tmp->tm_hour, tmp->tm_min, tmp->tm_sec);
+
+ dm_i2c_reg_write(dev, 0x08, bin2bcd(tmp->tm_year % 100));
+
+ century = (tmp->tm_year >= 2000) ? 0 : 0x80;
+ dm_i2c_reg_write(dev, 0x07, bin2bcd(tmp->tm_mon) | century);
+
+ dm_i2c_reg_write(dev, 0x06, bin2bcd(tmp->tm_wday));
+ dm_i2c_reg_write(dev, 0x05, bin2bcd(tmp->tm_mday));
+ dm_i2c_reg_write(dev, 0x04, bin2bcd(tmp->tm_hour));
+ dm_i2c_reg_write(dev, 0x03, bin2bcd(tmp->tm_min));
+ dm_i2c_reg_write(dev, 0x02, bin2bcd(tmp->tm_sec));
+
+ return 0;
+}
+
+static int pcf8563_rtc_reset(struct udevice *dev)
+{
+ /* clear all control & status registers */
+ dm_i2c_reg_write(dev, 0x00, 0x00);
+ dm_i2c_reg_write(dev, 0x01, 0x00);
+ dm_i2c_reg_write(dev, 0x0D, 0x00);
+
+ /* clear Voltage Low bit */
+ dm_i2c_reg_write(dev, 0x02, dm_i2c_reg_read (dev, 0x02) & 0x7F);
+
+ /* reset all alarms */
+ dm_i2c_reg_write(dev, 0x09, 0x00);
+ dm_i2c_reg_write(dev, 0x0A, 0x00);
+ dm_i2c_reg_write(dev, 0x0B, 0x00);
+ dm_i2c_reg_write(dev, 0x0C, 0x00);
+
+ return 0;
+}
+
+static const struct rtc_ops pcf8563_rtc_ops = {
+ .get = pcf8563_rtc_get,
+ .set = pcf8563_rtc_set,
+ .reset = pcf8563_rtc_reset,
+};
+
+static const struct udevice_id pcf8563_rtc_ids[] = {
+ { .compatible = "nxp,pcf8563" },
+ { }
+};
+
+U_BOOT_DRIVER(rtc_pcf8563) = {
+ .name = "rtc-pcf8563",
+ .id = UCLASS_RTC,
+ .of_match = pcf8563_rtc_ids,
+ .ops= _rtc_ops,
+};
+#endif
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] ARM: imx6: DHCOM i.MX6 PDK: Fixing reset
Hi Robert,
On 28/11/2019 17.17, Robert Hancock wrote:
> On 2019-11-28 6:34 a.m., Harald Seiler wrote:
>> Hello Claudius,
>>
>> On Thu, 2019-11-28 at 13:06 +0100, Claudius Heine wrote:
>>> Hi,
>>>
>>> currently the reset on the DHCOM i.MX6 board is brocken in u-boot.
>>>
>>> This patchset fixes that by integrating the sysreset and watchdog dm driver.
>>
>> I think you should clarify that reset was broken by commit f2929d11a639
>> ("watchdog: imx: Use immediate reset bits for expire_now") which changed
>> reset to, by default, only assert the external reset [1]. DHCOM i.MX6
>> needs the internal reset though, which previously was asserted as as
>> well. Maybe you can add a `Fixes:` line to one of your commits?
>
> The behavior of the driver in the DM mode should match what the Linux
> IMX watchdog driver is doing for both the watchdog timeout and reset
> operations. The reset operation there explicitly uses either internal
> reset or external reset, not both. For the actual watchdog timeout, they
> both set the WDT bit or not depending on whether ext-reset is set, which
> it seems would result in either internal+external reset or just internal
> reset (it doesn't look like you can trigger only an external reset on
> timeout).
>
>>
>> Additionally, I am still unsure whether the current default behavior is
>> correct. I'd rather assert both external and internal reset, which is
>> what the i.MX watchdog does on timeout as well (as long as WDT bit is
>> set, which we do by default [2]). There is also an inconsistency
>> between the non-DM implementation (external by default) and DM
>> implementation (internal by default).
>
> The legacy non-DM implementation kept the settings for timeout the same
> as they were before. For the reset, it appears that it used to do
> internal+external reset whereas now it does external only, so it's
> possible that might cause an issue on some boards. However, they should
> really be switching to DM and setting the ext-reset attribute properly
> depending on which reset they actually want, as that's needed to get
> proper watchdog timeout/restart behavior in Linux as well. I doubt any
> board actually needs both internal and external resets since then Linux
> would be unable to reboot properly.
Thx, for the explanation! An issue I could think of is in the SPL, where
DM is not possible because of size limitations. If that SPL wants to
trigger a reset, will that not cause only an external reset and boards
that need a internal one will just hang?
If that is the case, then there probably should be a way to configure
that or let it trigger both like it did before.
regards,
Claudius
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: c...@denx.de
PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 B153
Keyserver: hkp://pool.sks-keyservers.net
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] ARM: imx6: DHCOM i.MX6 PDK: Enable sysreset driver and wdt command
The SPL does not have DM enabled and therefor still needs to use the
hardware watchdog interface provided by the imx-watchdog driver.
Fixes: broken reset command after f2929d11a639 ("watchdog: imx: Use
immediate reset bits for expire_now")
Signed-off-by: Claudius Heine
---
configs/dh_imx6_defconfig | 3 +++
include/configs/dh_imx6.h | 5 +
2 files changed, 8 insertions(+)
diff --git a/configs/dh_imx6_defconfig b/configs/dh_imx6_defconfig
index 4055812007..e5c44381b2 100644
--- a/configs/dh_imx6_defconfig
+++ b/configs/dh_imx6_defconfig
@@ -37,6 +37,7 @@ CONFIG_CMD_MMC=y
CONFIG_CMD_SATA=y
CONFIG_CMD_USB=y
CONFIG_CMD_USB_MASS_STORAGE=y
+CONFIG_CMD_WDT=y
CONFIG_CMD_CACHE=y
CONFIG_CMD_TIME=y
CONFIG_CMD_EXT4_WRITE=y
@@ -77,6 +78,8 @@ CONFIG_DM_SCSI=y
CONFIG_SPI=y
CONFIG_DM_SPI=y
CONFIG_MXC_SPI=y
+CONFIG_SYSRESET=y
+CONFIG_SYSRESET_WATCHDOG=y
CONFIG_USB=y
CONFIG_DM_USB=y
CONFIG_USB_GADGET=y
diff --git a/include/configs/dh_imx6.h b/include/configs/dh_imx6.h
index d4bd88f511..77074aaa06 100644
--- a/include/configs/dh_imx6.h
+++ b/include/configs/dh_imx6.h
@@ -87,6 +87,11 @@
#endif
/* Watchdog */
+#if defined(CONFIG_SPL_BUILD)
+#undef CONFIG_WDT
+#undef CONFIG_WATCHDOG
+#define CONFIG_HW_WATCHDOG
+#endif
/* allow to overwrite serial and ethaddr */
#define CONFIG_ENV_OVERWRITE
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/2] ARM: imx6: DHCOM i.MX6 PDK: Fixing reset
Hi, here the second version of those patches. regards, Claudius Changes from v1: - u-boot specific wdt-reboot device node now in separate dtsi - Squashed patch 2 to 4, because possible bisecting issues in certain configurations (when SPL needs to use do_reset) - Improved patch description: more detailed and descriptive Claudius Heine (2): ARM: dts: dh-imx6: add u-boot specific wdt-reboot node ARM: imx6: DHCOM i.MX6 PDK: Enable sysreset driver and wdt command arch/arm/dts/imx6q-dhcom-pdk2-u-boot.dtsi | 11 +++ configs/dh_imx6_defconfig | 3 +++ include/configs/dh_imx6.h | 5 + 3 files changed, 19 insertions(+) create mode 100644 arch/arm/dts/imx6q-dhcom-pdk2-u-boot.dtsi -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] ARM: dts: dh-imx6: add u-boot specific wdt-reboot node
The wdt-reboot node is needed for the sysreset_watchdog driver to
register a watchdog as a reset handler in case 'CONFIG_SYSRESET' is
enabled.
Signed-off-by: Claudius Heine
---
arch/arm/dts/imx6q-dhcom-pdk2-u-boot.dtsi | 11 +++
1 file changed, 11 insertions(+)
create mode 100644 arch/arm/dts/imx6q-dhcom-pdk2-u-boot.dtsi
diff --git a/arch/arm/dts/imx6q-dhcom-pdk2-u-boot.dtsi
b/arch/arm/dts/imx6q-dhcom-pdk2-u-boot.dtsi
new file mode 100644
index 00..b94231edb3
--- /dev/null
+++ b/arch/arm/dts/imx6q-dhcom-pdk2-u-boot.dtsi
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: (GPL-2.0+)
+/*
+ * Copyright (C) 2019 Claudius Heine
+ */
+
+/ {
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ wdt = <>;
+ };
+};
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
