Re: [U-Boot] [PATCH 4/4] sunxi: board: fixup the BT address for Orange Pi 3
On 23/11/2019 04:24, Chen-Yu Tsai wrote:
On Fri, Nov 22, 2019 at 9:05 PM Andre Heider wrote:
The BCM4345C5 of the Orange Pi 3 ships with the controller default
address. Fix it up so it can function properly.
The used address is "ethaddr" with the LSB flipped.
Signed-off-by: Andre Heider
---
NOTE:
"local-bd-address" is a universal property, the kernel patch for
btbcm to use that is in bluetooth-next.
board/sunxi/board.c | 28
1 file changed, 28 insertions(+)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index bb35d6b66e..2897bf45e1 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -856,6 +856,32 @@ int misc_init_r(void)
return 0;
}
+static void fixup_bd_address(void *blob)
+{
+#if defined(CONFIG_MACH_SUN50I_H6)
+ /* Some devices ship with the controller default address.
+* Set a valid address through the device tree.
+*/
+ uchar mac[ETH_ALEN], bdaddr[ETH_ALEN];
+ int i;
+
+ if (!of_machine_is_compatible("xunlong,orangepi-3"))
+ return;
+
+ if (!eth_env_get_enetaddr("ethaddr", mac))
+ return;
+
+ /* Addresses need to be in the binary format of the corresponding stack
*/
+ for (i = 0; i < ETH_ALEN; ++i)
+ bdaddr[i] = mac[ETH_ALEN - i - 1];
+
+ bdaddr[0] ^= 1;
IIRC someone mentioned before that unlike Ethernet and WiFi,
Bluetooth does not have a "locally administered" address space,
so any address used could possibly collide with other devices.
The kernel even refuses to use the controller default address, likely
because of collisions. While this patch obviously doesn't guarantee a
unique address, I guess it's in the same ballpark as "ethaddr" for
sunxi. This at least gets BT working out of the box.
But I guess we should give the user an option to set a bdaddr of her/his
choosing. I'll add support for reading the env var "bdaddr" and fall
back to this address generation if that wasn't successful.
Or do you think we can do better?
Regards,
Andre
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] sunxi: board: fixup the BT address for Orange Pi 3
On Fri, Nov 22, 2019 at 9:05 PM Andre Heider wrote:
>
> The BCM4345C5 of the Orange Pi 3 ships with the controller default
> address. Fix it up so it can function properly.
>
> The used address is "ethaddr" with the LSB flipped.
>
> Signed-off-by: Andre Heider
> ---
>
> NOTE:
> "local-bd-address" is a universal property, the kernel patch for
> btbcm to use that is in bluetooth-next.
>
> board/sunxi/board.c | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index bb35d6b66e..2897bf45e1 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -856,6 +856,32 @@ int misc_init_r(void)
> return 0;
> }
>
> +static void fixup_bd_address(void *blob)
> +{
> +#if defined(CONFIG_MACH_SUN50I_H6)
> + /* Some devices ship with the controller default address.
> +* Set a valid address through the device tree.
> +*/
> + uchar mac[ETH_ALEN], bdaddr[ETH_ALEN];
> + int i;
> +
> + if (!of_machine_is_compatible("xunlong,orangepi-3"))
> + return;
> +
> + if (!eth_env_get_enetaddr("ethaddr", mac))
> + return;
> +
> + /* Addresses need to be in the binary format of the corresponding
> stack */
> + for (i = 0; i < ETH_ALEN; ++i)
> + bdaddr[i] = mac[ETH_ALEN - i - 1];
> +
> + bdaddr[0] ^= 1;
IIRC someone mentioned before that unlike Ethernet and WiFi,
Bluetooth does not have a "locally administered" address space,
so any address used could possibly collide with other devices.
ChenYu
> +
> + do_fixup_by_compat(blob, "brcm,bcm4345c5",
> + "local-bd-address", bdaddr, ETH_ALEN, 1);
> +#endif
> +}
> +
> int ft_board_setup(void *blob, bd_t *bd)
> {
> int __maybe_unused r;
> @@ -866,6 +892,8 @@ int ft_board_setup(void *blob, bd_t *bd)
> */
> setup_environment(blob);
>
> + fixup_bd_address(blob);
> +
> #ifdef CONFIG_VIDEO_DT_SIMPLEFB
> r = sunxi_simplefb_setup(blob);
> if (r)
> --
> 2.24.0
>
> ___
> 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] [RFC/RFT PATCH v4 3/3] image: Add compressed Image parsing support in booti.
On Wed, 2019-11-13 at 11:47 -0800, Atish Patra wrote:
> On Wed, 2019-11-13 at 15:36 +0200, David Abdurachmanov wrote:
> > On Sat, Nov 9, 2019 at 2:14 AM Atish Patra
> > wrote:
> > > Add compressed Image parsing support so that booti can parse both
> > > flat and compressed Image to boot Linux. Currently, it is
> > > difficult
> > > to calculate a safe address for every board where the compressed
> > > image can be decompressed. It is also not possible to figure out
> > > the
> > > size of the compressed file as well. Thus, user need to set two
> > > additional environment variables kernel_comp_addr_r and filesize
> > > to
> > > make this work.
> > >
> > > Following compression methods are supported for now.
> > > lzma, lzo, bzip2, gzip.
> > >
> > > lz4 support is not added as ARM64 kernel generates a lz4
> > > compressed
> > > image with legacy header which U-Boot doesn't know how to parse
> > > and
> > > decompress.
> > >
> > > Tested on HiFive Unleashed and Qemu for RISC-V.
> > > Tested on Qemu for ARM64.
> > >
> > > Signed-off-by: Atish Patra
> > > ---
> > > I could not test this patch on any ARM64 boards due to lack of
> > > access to any ARM64 board. If anybody can test it on ARM64, that
> > > would be great.
> > > ---
> > > cmd/booti.c| 40 ++-
> > > doc/README.distro | 12 +
> > > doc/board/sifive/fu540.rst | 55
> > > ++
> > > 3 files changed, 106 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/cmd/booti.c b/cmd/booti.c
> > > index c36b0235df8c..cd8670a9a8db 100644
> > > --- a/cmd/booti.c
> > > +++ b/cmd/booti.c
> > > @@ -13,6 +13,7 @@
> > > #include
> > > #include
> > >
> > > +DECLARE_GLOBAL_DATA_PTR;
> > > /*
> > > * Image booting support
> > > */
> > > @@ -23,6 +24,12 @@ static int booti_start(cmd_tbl_t *cmdtp, int
> > > flag, int argc,
> > > ulong ld;
> > > ulong relocated_addr;
> > > ulong image_size;
> > > + uint8_t *temp;
> > > + ulong dest;
> > > + ulong dest_end;
> > > + unsigned long comp_len;
> > > + unsigned long decomp_len;
> > > + int ctype;
> > >
> > > ret = do_bootm_states(cmdtp, flag, argc, argv,
> > > BOOTM_STATE_START,
> > > images, 1);
> > > @@ -37,6 +44,33 @@ static int booti_start(cmd_tbl_t *cmdtp, int
> > > flag, int argc,
> > > debug("* kernel: cmdline image address =
> > > 0x%08lx\n", ld);
> > > }
> > >
> > > + temp = map_sysmem(ld, 0);
> > > + ctype = image_decomp_type(temp, 2);
> > > + if (ctype > 0) {
> > > + dest = env_get_ulong("kernel_comp_addr_r", 16,
> > > 0);
> > > + comp_len = env_get_ulong("filesize", 16, 0);
> > > + if (!dest || !comp_len) {
> > > + puts("kernel_comp_addr_r or filesize is
> > > not
> > > provided!\n");
> > > + return -EINVAL;
> > > + }
> > > + if (dest < gd->ram_base || dest > gd->ram_top) {
> > > + puts("kernel_comp_addr_r is outside of
> > > DRAM
> > > range!\n");
> > > + return -EINVAL;
> > > + }
> > > +
> > > + debug("kernel image compression type %d size =
> > > 0x%08lx address = 0x%08lx\n",
> > > + ctype, comp_len, (ulong)dest);
> > > + decomp_len = comp_len * 10;
> > > + ret = image_decomp(ctype, 0, ld, IH_TYPE_KERNEL,
> > > +(void *)dest, (void *)ld,
> > > comp_len,
> > > +decomp_len, _end);
> > > + if (ret)
> > > + return ret;
> > > + /* dest_end contains the uncompressed Image size
> > > */
> > > + memmove((void *) ld, (void *)dest, dest_end);
> > > + }
> > > + unmap_sysmem((void *)ld);
> > > +
> > > ret = booti_setup(ld, _addr, _size,
> > > false);
> > > if (ret != 0)
> > > return 1;
> > > @@ -96,10 +130,14 @@ int do_booti(cmd_tbl_t *cmdtp, int flag, int
> > > argc, char * const argv[])
> > > #ifdef CONFIG_SYS_LONGHELP
> > > static char booti_help_text[] =
> > > "[addr [initrd[:size]] [fdt]]\n"
> > > - "- boot Linux 'Image' stored at 'addr'\n"
> > > + "- boot Linux flat or compressed 'Image' stored at
> > > 'addr'\n"
> > > "\tThe argument 'initrd' is optional and specifies the
> > > address\n"
> > > "\tof an initrd in memory. The optional parameter ':size'
> > > allows\n"
> > > "\tspecifying the size of a RAW initrd.\n"
> > > + "\tCurrently only booting from gz, bz2, lzma and lz4
> > > compression\n"
> > > + "\ttypes are supported. In order to boot from any of
> > > these
> > > compressed\n"
> > > + "\timages, user have to set kernel_comp_addr_r and
> > > filesize
> > > enviornment\n"
> > > +
Re: [U-Boot] [PATCH 2/2] drivers: usb: host: Add BRCM xHCI driver
On 11/23/19 12:31 AM, Vladimir Olovyannikov wrote:
[...]
> +#define USBAXI_AWCACHE 0xF
> +#define USBAXI_ARCACHE 0xF
> +#define USBAXI_AWPROT0x8
> +#define USBAXI_ARPROT0x8
> +#define USBAXIWR_SA_VAL ((USBAXI_AWCACHE << 4 | USBAXI_AWPROT)
> << 0)
Are the parenthesis correct here ?
Might make sense to rewrite it as ((AWCACHE << 4) | AWPROT)
> +#define USBAXIWR_SA_MASK (0xff)
Here the parenthesis are not needed.
> +#define USBAXIWR_UA_VAL ((USBAXI_AWCACHE << 4 | USBAXI_AWPROT)
> << 16)
> +#define USBAXIWR_UA_MASK ((0xff) << 16)
> +#define USBAXIRD_SA_VAL ((USBAXI_ARCACHE << 4 | USBAXI_ARPROT)
> << 0)
> +#define USBAXIRD_SA_MASK (0xff)
> +#define USBAXIRD_UA_VAL ((USBAXI_ARCACHE << 4 | USBAXI_ARPROT)
> << 16)
> +#define USBAXIRD_UA_MASK ((0xff) << 16)
> +
> +struct brcm_xhci_platdata {
> + unsigned int arcache;
> + unsigned int awcache;
> +};
> +
> +static int xhci_brcm_probe(struct udevice *dev)
> +{
> + struct xhci_hccr *hcd;
> + struct xhci_hcor *hcor;
> + struct brcm_xhci_platdata *plat = dev_get_platdata(dev);
> + int len, ret = 0;
> +
> + if (!plat) {
> + dev_err(dev, "Can't get xHCI Plat data\n");
> + return -ENOMEM;
> + }
> +
> + hcd = dev_read_addr_ptr(dev);
> + if (!hcd) {
> + dev_err(dev, "Can't get the xHCI register base address\n");
> + return -ENXIO;
> + }
> +
> + len = HC_LENGTH(xhci_readl(&(hcd)->cr_capbase));
> + hcor = (struct xhci_hcor *)((uintptr_t)hcd + len);
Please clean up the extraneous parenthesis ^
> + /* Save the default values of AXI read and write attributes */
> + plat->awcache = readl((uintptr_t)hcd + DRD2U3H_XHC_REGS_AXIWRA);
> + plat->arcache = readl((uintptr_t)hcd + DRD2U3H_XHC_REGS_AXIRDA);
> +
> + /* Enable AXI read and write attributes. */
> + clrsetbits_le32(((uintptr_t)hcd + DRD2U3H_XHC_REGS_AXIWRA),
> + (USBAXIWR_UA_MASK | USBAXIWR_SA_MASK),
> + (USBAXIWR_UA_VAL | USBAXIWR_SA_VAL));
> + clrsetbits_le32(((uintptr_t)hcd + DRD2U3H_XHC_REGS_AXIRDA),
> + (USBAXIRD_UA_MASK | USBAXIRD_SA_MASK),
> + (USBAXIRD_UA_VAL | USBAXIRD_SA_VAL));
> +
> + ret = xhci_register(dev, hcd, hcor);
> + if (ret)
> + dev_err(dev, "Failed to register xHCI\n");
> +
> + return ret;
> +}
> +
> +static int xhci_brcm_deregister(struct udevice *dev)
> +{
> + struct xhci_hccr *hcd;
> + struct brcm_xhci_platdata *plat = dev_get_platdata(dev);
> +
> + hcd = (struct xhci_hccr *)((uintptr_t)dev_read_addr(dev));
> +
> + /* Restore the default values for AXI read and write attributes */
> + writel(plat->awcache, ((uintptr_t)hcd + DRD2U3H_XHC_REGS_AXIWRA));
> + writel(plat->arcache, ((uintptr_t)hcd + DRD2U3H_XHC_REGS_AXIRDA));
Here too.
Looks good otherwise, thanks.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] dt-bindings: Documentation on BRCM xHCI controller
From: Bharat Kumar Reddy Gooty
DT bindings document for Broadcom xHCI controller.
Signed-off-by: Bharat Kumar Reddy Gooty
Signed-off-by: Vladimir Olovyannikov
---
.../devicetree/bindings/usb/brcm,generic-xhci.txt| 12
1 file changed, 12 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/brcm,generic-xhci.txt
diff --git a/Documentation/devicetree/bindings/usb/brcm,generic-xhci.txt
b/Documentation/devicetree/bindings/usb/brcm,generic-xhci.txt
new file mode 100644
index 00..621b99c9f3
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/brcm,generic-xhci.txt
@@ -0,0 +1,12 @@
+Broadcom USB xHCI Controller
+
+Required properties:
+ - compatible: "brcm,generic-xhci"
+ - reg: Base address and length of the standard xHCI register set
+
+Example:
+
+ xhci0: usb@68501000 {
+ compatible = "brcm,generic-xhci";
+ reg = <0x68501000 0x1000>;
+ };
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] drivers: usb: host: Add BRCM xHCI driver
From: Bharat Kumar Reddy Gooty
Base driver for Broadcom xHCI controllers
Signed-off-by: Bharat Kumar Reddy Gooty
Signed-off-by: Vladimir Olovyannikov
---
drivers/usb/host/Kconfig | 8 +++
drivers/usb/host/Makefile| 1 +
drivers/usb/host/xhci-brcm.c | 103 +++
3 files changed, 112 insertions(+)
create mode 100644 drivers/usb/host/xhci-brcm.c
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 0987ff25b1..94ac969058 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -88,6 +88,14 @@ config USB_XHCI_FSL
depends on !SPL_NO_USB
help
Enables support for the on-chip xHCI controller on NXP Layerscape
SoCs.
+
+config USB_XHCI_BRCM
+ bool "Broadcom USB3 Host XHCI controller"
+ depends on DM_USB
+ help
+ USB controller based on the Broadcom USB3 IP Core.
+ Supports USB2/3 functionality.
+
endif # USB_XHCI_HCD
config USB_EHCI_HCD
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 7feeff679c..b62f346094 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_USB_EHCI_RMOBILE) += ehci-rmobile.o
obj-$(CONFIG_USB_EHCI_ZYNQ) += ehci-zynq.o
# xhci
+obj-$(CONFIG_USB_XHCI_BRCM) += xhci-brcm.o
obj-$(CONFIG_USB_XHCI_HCD) += xhci.o xhci-mem.o xhci-ring.o
obj-$(CONFIG_USB_XHCI_DWC3) += xhci-dwc3.o
obj-$(CONFIG_USB_XHCI_DWC3_OF_SIMPLE) += dwc3-of-simple.o
diff --git a/drivers/usb/host/xhci-brcm.c b/drivers/usb/host/xhci-brcm.c
new file mode 100644
index 00..84ec95f804
--- /dev/null
+++ b/drivers/usb/host/xhci-brcm.c
@@ -0,0 +1,103 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2019 Broadcom.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "xhci.h"
+
+#define DRD2U3H_XHC_REGS_AXIWRA0xC08
+#define DRD2U3H_XHC_REGS_AXIRDA0xC0C
+
+#define USBAXI_AWCACHE 0xF
+#define USBAXI_ARCACHE 0xF
+#define USBAXI_AWPROT 0x8
+#define USBAXI_ARPROT 0x8
+#define USBAXIWR_SA_VAL((USBAXI_AWCACHE << 4 | USBAXI_AWPROT)
<< 0)
+#define USBAXIWR_SA_MASK (0xff)
+#define USBAXIWR_UA_VAL((USBAXI_AWCACHE << 4 | USBAXI_AWPROT)
<< 16)
+#define USBAXIWR_UA_MASK ((0xff) << 16)
+#define USBAXIRD_SA_VAL((USBAXI_ARCACHE << 4 | USBAXI_ARPROT)
<< 0)
+#define USBAXIRD_SA_MASK (0xff)
+#define USBAXIRD_UA_VAL((USBAXI_ARCACHE << 4 | USBAXI_ARPROT)
<< 16)
+#define USBAXIRD_UA_MASK ((0xff) << 16)
+
+struct brcm_xhci_platdata {
+ unsigned int arcache;
+ unsigned int awcache;
+};
+
+static int xhci_brcm_probe(struct udevice *dev)
+{
+ struct xhci_hccr *hcd;
+ struct xhci_hcor *hcor;
+ struct brcm_xhci_platdata *plat = dev_get_platdata(dev);
+ int len, ret = 0;
+
+ if (!plat) {
+ dev_err(dev, "Can't get xHCI Plat data\n");
+ return -ENOMEM;
+ }
+
+ hcd = dev_read_addr_ptr(dev);
+ if (!hcd) {
+ dev_err(dev, "Can't get the xHCI register base address\n");
+ return -ENXIO;
+ }
+
+ len = HC_LENGTH(xhci_readl(&(hcd)->cr_capbase));
+ hcor = (struct xhci_hcor *)((uintptr_t)hcd + len);
+
+ /* Save the default values of AXI read and write attributes */
+ plat->awcache = readl((uintptr_t)hcd + DRD2U3H_XHC_REGS_AXIWRA);
+ plat->arcache = readl((uintptr_t)hcd + DRD2U3H_XHC_REGS_AXIRDA);
+
+ /* Enable AXI read and write attributes. */
+ clrsetbits_le32(((uintptr_t)hcd + DRD2U3H_XHC_REGS_AXIWRA),
+ (USBAXIWR_UA_MASK | USBAXIWR_SA_MASK),
+ (USBAXIWR_UA_VAL | USBAXIWR_SA_VAL));
+ clrsetbits_le32(((uintptr_t)hcd + DRD2U3H_XHC_REGS_AXIRDA),
+ (USBAXIRD_UA_MASK | USBAXIRD_SA_MASK),
+ (USBAXIRD_UA_VAL | USBAXIRD_SA_VAL));
+
+ ret = xhci_register(dev, hcd, hcor);
+ if (ret)
+ dev_err(dev, "Failed to register xHCI\n");
+
+ return ret;
+}
+
+static int xhci_brcm_deregister(struct udevice *dev)
+{
+ struct xhci_hccr *hcd;
+ struct brcm_xhci_platdata *plat = dev_get_platdata(dev);
+
+ hcd = (struct xhci_hccr *)((uintptr_t)dev_read_addr(dev));
+
+ /* Restore the default values for AXI read and write attributes */
+ writel(plat->awcache, ((uintptr_t)hcd + DRD2U3H_XHC_REGS_AXIWRA));
+ writel(plat->arcache, ((uintptr_t)hcd + DRD2U3H_XHC_REGS_AXIRDA));
+
+ return xhci_deregister(dev);
+}
+
+static const struct udevice_id xhci_brcm_ids[] = {
+ { .compatible = "brcm,generic-xhci" },
+ { }
+};
+
+U_BOOT_DRIVER(usb_xhci) = {
+ .name = "xhci_brcm",
+ .id = UCLASS_USB,
+ .probe = xhci_brcm_probe,
+ .remove = xhci_brcm_deregister,
+
[U-Boot] [PATCH 0/2] Add Broadcom XHCI driver for iproc platforms
This patchset adds Broadcom XHCI driver for iproc platforms This USB controller is based on the Broadcom USB3 IP Core. Supports USB2/3 functionality. Bharat Kumar Reddy Gooty (2): dt-bindings: Documentation on BRCM xHCI controller drivers: usb: host: Add BRCM xHCI driver .../bindings/usb/brcm,generic-xhci.txt| 12 ++ drivers/usb/host/Kconfig | 8 ++ drivers/usb/host/Makefile | 1 + drivers/usb/host/xhci-brcm.c | 103 ++ 4 files changed, 124 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/brcm,generic-xhci.txt create mode 100644 drivers/usb/host/xhci-brcm.c -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] dt-bindings: documentation on sp805(DM) iproc driver
From: Pramod Kumar
DT documentation for sp805 DM wdt Broadcom iproc driver
used by iproc-based socs.
Signed-off-by: Pramod Kumar
Signed-off-by: Vladimir Olovyannikov
---
.../devicetree/bindings/watchdog/sp805-wdt_dm.txt | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/sp805-wdt_dm.txt
diff --git a/Documentation/devicetree/bindings/watchdog/sp805-wdt_dm.txt
b/Documentation/devicetree/bindings/watchdog/sp805-wdt_dm.txt
new file mode 100644
index 00..34b677fd64
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/sp805-wdt_dm.txt
@@ -0,0 +1,15 @@
+sp805 is an ARM Watchdog Timer (WDT) Controller (DM)
+
+Required properties:
+-compatible : Should be arm,sp805-wdt
+-reg : Base address and size of the watchdog timer registers.
+-clk-mhz : Watchdog clock in mhz
+timeout-msec : Watchdog timer expire value in msec
+
+Example:
+ wdt0: watchdog@c {
+ compatible = "arm,sp805-wdt";
+ reg = <0x000c 0x1000>;
+ clk-mhz = <1250>;
+ timeout-msec = <6>;
+ };
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] drivers: watchdog: Add brcm iproc sp805 watchdog driver
From: Pramod Kumar
Add sp805 watchdog driver for Broadcom iproc socs (DM).
Signed-off-by: Pramod Kumar
Signed-off-by: Vladimir Olovyannikov
---
drivers/watchdog/Kconfig| 10 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/sp805_wdt_dm.c | 181
3 files changed, 192 insertions(+)
create mode 100644 drivers/watchdog/sp805_wdt_dm.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 8c16d69d33..74a5319467 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -40,6 +40,16 @@ config OMAP_WATCHDOG
help
Say Y here to enable the OMAP3+ watchdog driver.
+config SP805_WATCHDOG
+ bool "Enable ARM SP805 watchdog driver (DM)"
+ depends on WDT
+ imply WATCHDOG
+ help
+ Say Y here to enable the sp805 watchdog (DM)
+
+ This provides basic infrastructure to support sp805 watchdog
+ hardware; driver model.
+
config ULP_WATCHDOG
bool "i.MX7ULP watchdog"
help
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 955caef815..aacabf1f2e 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_S5P) += s5p_wdt.o
obj-$(CONFIG_XILINX_TB_WATCHDOG) += xilinx_tb_wdt.o
obj-$(CONFIG_OMAP_WATCHDOG) += omap_wdt.o
obj-$(CONFIG_DESIGNWARE_WATCHDOG) += designware_wdt.o
+obj-$(CONFIG_SP805_WATCHDOG) += sp805_iproc_dm.o
obj-$(CONFIG_ULP_WATCHDOG) += ulp_wdog.o
obj-$(CONFIG_$(SPL_TPL_)WDT) += wdt-uclass.o
obj-$(CONFIG_WDT_SANDBOX) += sandbox_wdt.o
diff --git a/drivers/watchdog/sp805_wdt_dm.c b/drivers/watchdog/sp805_wdt_dm.c
new file mode 100644
index 00..56d0e77080
--- /dev/null
+++ b/drivers/watchdog/sp805_wdt_dm.c
@@ -0,0 +1,181 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2018 Broadcom.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* SP805 register offset */
+#define SP805_WDOG_LOAD_OFF0x000
+#define SP805_WDOG_CTR_OFF 0x008
+#define SP805_WDOG_CLR_OFF 0x00c
+#define SP805_WDOG_LOCK_OFF0xc00
+
+/* Magic word to unlock the wd registers */
+#define WDOG_UNLOCK_KEY0x1ACCE551
+
+/* Register field definitions */
+#define SP805_CTR_RESENBIT(1)
+#define SP805_CTR_INTENBIT(0)
+
+struct sp805_wdt_platdata {
+ void __iomem *regs;
+ u32 timeout_msec;
+ u32 clk_mhz;
+};
+
+/* Inline register access functions */
+
+static inline void sp805_write_wdog_load(void __iomem *base, u32 value)
+{
+ writel(value, base + SP805_WDOG_LOAD_OFF);
+}
+
+static inline void sp805_write_wdog_ctrl(void __iomem *base, u32 value)
+{
+ writel(value, base + SP805_WDOG_CTR_OFF);
+}
+
+static inline void sp805_write_wdog_lock(void __iomem *base, u32 value)
+{
+ writel(value, base + SP805_WDOG_LOCK_OFF);
+}
+
+static inline void sp805_write_wdog_kick(void __iomem *base, u32 value)
+{
+ writel(value, base + SP805_WDOG_CLR_OFF);
+}
+
+static u32 msec_to_ticks(struct udevice *dev)
+{
+ u32 timeout_msec;
+ u32 msec;
+ struct sp805_wdt_platdata *pd = dev_get_platdata(dev);
+
+ timeout_msec = env_get_ulong("wdt_timeout_msec", 16, 0);
+ if (timeout_msec) {
+ dev_dbg(dev, "Overriding timeout :%u\n", timeout_msec);
+ msec = timeout_msec;
+ } else {
+ msec = pd->timeout_msec;
+ }
+
+ timeout_msec = (msec / 2) * (pd->clk_mhz / 1000);
+
+ dev_dbg(dev, "ticks :%u\n", timeout_msec);
+
+ return timeout_msec;
+}
+
+static int sp805_wdt_expire_now(struct udevice *dev, ulong flags)
+{
+ struct sp805_wdt_platdata *pd = dev_get_platdata(dev);
+
+ sp805_write_wdog_lock(pd->regs, WDOG_UNLOCK_KEY);
+ sp805_write_wdog_load(pd->regs, 0);
+ sp805_write_wdog_lock(pd->regs, 0);
+
+ return 0;
+}
+
+static int sp805_wdt_reset(struct udevice *dev)
+{
+ struct sp805_wdt_platdata *pd = dev_get_platdata(dev);
+ u32 ticks;
+
+ ticks = msec_to_ticks(dev);
+
+ sp805_write_wdog_lock(pd->regs, WDOG_UNLOCK_KEY);
+ sp805_write_wdog_load(pd->regs, ticks);
+ sp805_write_wdog_lock(pd->regs, 0);
+
+ dev_dbg(dev, "%s ", __func__);
+
+ return 0;
+}
+
+static int sp805_wdt_stop(struct udevice *dev)
+{
+ struct sp805_wdt_platdata *pd = dev_get_platdata(dev);
+
+ sp805_write_wdog_lock(pd->regs, WDOG_UNLOCK_KEY);
+ sp805_write_wdog_ctrl(pd->regs, 0);
+
+ dev_dbg(dev, "Watchdog disabled!\n");
+
+ return 0;
+}
+
+static int sp805_wdt_start(struct udevice *dev, u64 timeout, ulong flags)
+{
+ struct sp805_wdt_platdata *pd = dev_get_platdata(dev);
+ u32 ticks;
+
+ ticks = msec_to_ticks(dev);
+
+ dev_dbg(dev, "%s:\n", __func__);
+
+ sp805_write_wdog_load(pd->regs, ticks);
+
[U-Boot] [PATCH 0/2] Add SP805 driver for iproc platforms (DM)
This patchset adds driver-model based SP805 watchdog driver for Broadcom iProc platforms Pramod Kumar (2): dt-bindings: documentation on sp805(DM) iproc driver drivers: watchdog: Add brcm iproc sp805 watchdog driver .../bindings/watchdog/sp805-wdt_dm.txt| 15 ++ drivers/watchdog/Kconfig | 10 + drivers/watchdog/Makefile | 1 + drivers/watchdog/sp805_wdt_dm.c | 181 ++ 4 files changed, 207 insertions(+) create mode 100644 Documentation/devicetree/bindings/watchdog/sp805-wdt_dm.txt create mode 100644 drivers/watchdog/sp805_wdt_dm.c -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] drivers: mmc: rpmb: Use R1 response
From: Bharat Kumar Reddy Gooty
If the host has Broken R1B, use only R1 response type.
Signed-off-by: Bharat Kumar Reddy Gooty
Signed-off-by: Vladimir Olovyannikov
---
drivers/mmc/rpmb.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mmc/rpmb.c b/drivers/mmc/rpmb.c
index 33371fe562..ee6dbe30db 100644
--- a/drivers/mmc/rpmb.c
+++ b/drivers/mmc/rpmb.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include "mmc_private.h"
@@ -91,6 +92,7 @@ static int mmc_rpmb_request(struct mmc *mmc, const struct
s_rpmb *s,
{
struct mmc_cmd cmd = {0};
struct mmc_data data;
+ struct sdhci_host *host = mmc->priv;
int ret;
ret = mmc_set_blockcount(mmc, count, is_rel_write);
@@ -105,6 +107,9 @@ static int mmc_rpmb_request(struct mmc *mmc, const struct
s_rpmb *s,
cmd.cmdarg = 0;
cmd.resp_type = MMC_RSP_R1;
+ if (host->quirks & SDHCI_QUIRK_BROKEN_R1B)
+ cmd.resp_type = MMC_RSP_R1;
+
data.src = (const char *)s;
data.blocks = 1;
data.blocksize = MMC_MAX_BLOCK_LEN;
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] drivers: spi: Add commands for Micron SPI
Add commands for dual and quad SPI transfers on Micon SPI.
Signed-off-by: Corneliu Doban
Signed-off-by: Vladimir Olovyannikov
---
include/spi.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/spi.h b/include/spi.h
index 6fbb4336ce..ae36835e95 100644
--- a/include/spi.h
+++ b/include/spi.h
@@ -30,6 +30,10 @@
#define SPI_RX_SLOWBIT(11) /* receive with 1 wire slow */
#define SPI_RX_DUALBIT(12) /* receive with 2 wires */
#define SPI_RX_QUADBIT(13) /* receive with 4 wires */
+#define SPI_RX_4X BIT(14) /*
+* addr on 1 wire
+* data on 4 wires
+*/
/* Header byte that marks the start of the message */
#define SPI_PREAMBLE_END_BYTE 0xec
@@ -115,6 +119,8 @@ struct spi_slave {
#define SPI_XFER_ONCE (SPI_XFER_BEGIN | SPI_XFER_END)
#define SPI_XFER_MMAP BIT(2) /* Memory Mapped start */
#define SPI_XFER_MMAP_END BIT(3) /* Memory Mapped End */
+#define SPI_XFER_DUAL BIT(30)
+#define SPI_XFER_QUAD BIT(31)
};
/**
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] drivers: spi: Add brcm iproc spi driver
From: Shreesha Rajashekar Add iproc spi/qspi driver for Broadcom iproc architecture based soc's. Signed-off-by: Shreesha Rajashekar Signed-off-by: Bharat Kumar Reddy Gooty Signed-off-by: Rayagonda Kokatanur Signed-off-by: Vladimir Olovyannikov --- drivers/spi/Kconfig | 26 + drivers/spi/Makefile |4 + drivers/spi/iproc_qspi.c | 1161 ++ drivers/spi/iproc_qspi.h | 47 ++ drivers/spi/iproc_spi.c | 71 +++ 5 files changed, 1309 insertions(+) create mode 100644 drivers/spi/iproc_qspi.c create mode 100644 drivers/spi/iproc_qspi.h create mode 100644 drivers/spi/iproc_spi.c diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 8588866489..b18f26d61a 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -405,6 +405,32 @@ config DAVINCI_SPI help Enable the Davinci SPI driver +config IPROC_SPI + bool "SPI support for iproc soc's" + help + This selects the iproc SPI controller. + The controller is used in iProc SoCs. + +config IPROC_PL022_SPI + bool "ARM PL022 SPI driver" + select IPROC_SPI + help + Enable the ARM PL022 (SPI) driver for iproc architecture soc's. + +config IPROC_QSPI + bool "QSPI driver for BCM iProc QSPI Controller" + select IPROC_SPI + help + This selects the BCM iProc QSPI controller. + This driver support spi flash single, quad and memory reads. + +config BCM_IPROC_USE_BSPI + bool "Broadcom BSPI driver for fast read" + depends on IPROC_QSPI + help + This selects the BCM BSPI driver for fast read mode. + Enable this mode if flash(nand/nor) supports. + config SH_SPI bool "SuperH SPI driver" depends on DEPRECATED diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index ae4f2958f8..2388bc6e93 100644 --- a/drivers/spi/Makefile +++ b/drivers/spi/Makefile @@ -32,6 +32,10 @@ obj-$(CONFIG_FSL_DSPI) += fsl_dspi.o obj-$(CONFIG_FSL_ESPI) += fsl_espi.o obj-$(CONFIG_FSL_QSPI) += fsl_qspi.o obj-$(CONFIG_ICH_SPI) += ich.o +ifndef CONFIG_DM_SPI +obj-$(CONFIG_IPROC_SPI) += iproc_spi.o +endif +obj-$(CONFIG_IPROC_QSPI) += iproc_qspi.o obj-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o obj-$(CONFIG_LPC32XX_SSP) += lpc32xx_ssp.o obj-$(CONFIG_MESON_SPIFC) += meson_spifc.o diff --git a/drivers/spi/iproc_qspi.c b/drivers/spi/iproc_qspi.c new file mode 100644 index 00..20ca94d4f3 --- /dev/null +++ b/drivers/spi/iproc_qspi.c @@ -0,0 +1,1161 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright 2017 Broadcom. + */ + +#include +#include +#include +#include +#include +#include +#include "iproc_qspi.h" + +#define QSPI_AXI_CLK17500 /* 175MHz */ + +/* default SCK frequency, unit: HZ */ +#define QSPI_DEF_SCK_FREQ 5000 + +#ifndef CONFIG_DM_SPI +/* Configurations */ +#ifndef IPROC_QSPI_BUS +#error IPROC_QSPI_BUS not defined +#endif /* !IPROC_QSPI_BUS */ +#ifndef IPROC_QSPI_CS +#error CONFIG_IPROC_QSPI_CS not defined +#endif /* !IPROC_QSPI_CS */ +#endif +#define QSPI_WAIT_TIMEOUT_MS200U /* msec */ + +/* Chip attributes */ +#define QSPI_REG_BASE IPROC_QSPI_BASE_REG +#define CRU_CONTROL_REG IPROC_QSPI_CRU_CONTROL_REG +#define SPBR_MIN8U +#define SPBR_MAX255U +#define NUM_TXRAM 32U +#define NUM_RXRAM 32U +#define NUM_CDRAM 16U + +#define CDRAM_PCS0 2 +#define CDRAM_CONT BIT(7) +#define CDRAM_BITS_EN BIT(6) +#define CDRAM_QUAD_MODE BIT(8) +#define CDRAM_RBIT_INPUTBIT(10) + +#define MSPI_SPEBIT(6) +#define MSPI_CONT_AFTER_CMD BIT(7) + +/* + * Register fields + */ +#define MSPI_SPCR0_MSB_BITS_8 0x0020 +#define BSPI_RAF_CONTROL_START_MASK 0x0001 +#define BSPI_RAF_STATUS_SESSION_BUSY_MASK 0x0001 +#define BSPI_RAF_STATUS_FIFO_EMPTY_MASK 0x0002 +#define BSPI_BITS_PER_PHASE_ADDR_MARK 0x0001 +#define BSPI_BITS_PER_CYCLE_DATA_SHIFT 0 +#define BSPI_BITS_PER_CYCLE_ADDR_SHIFT 16 +#define BSPI_STRAP_OVERRIDE_DATA_QUAD_SHIFT 3 +#define BSPI_STRAP_OVERRIDE_DATA_DUAL_SHIFT 1 +#define BSPI_STRAP_OVERRIDE_SHIFT 0 + +/* + * Flash opcode and parameters + */ +#define OPCODE_RDSR 0x05 +#define OPCODE_FAST_READ0x0B +#define OPCODE_DUAL_READ0x3b +#define OPCODE_QUAD_READ0x6b +#define OPCODE_EN4B 0xB7 +#define OPCODE_EX4B 0xE9 +#define OPCODE_BRWR 0x17 + +/* + * Check dual/quad mode configurations + */ +#ifndef CONFIG_DM_SPI +#if
[U-Boot] [PATCH 0/2] Add Broadcom SPI driver
This patchset: - adds Broadcom SPI driver for iproc-based platforms and - extends Micron SPI commands for dual and quad SPI transfers on Micon SPI. Shreesha Rajashekar (1): drivers: spi: Add brcm iproc spi driver Corneliu Doban (1): drivers: spi: Add commands for Micron SPI drivers/spi/Kconfig | 26 + drivers/spi/Makefile |4 + drivers/spi/iproc_qspi.c | 1161 ++ drivers/spi/iproc_qspi.h | 47 ++ drivers/spi/iproc_spi.c | 71 +++ include/spi.h|6 + 6 files changed, 1315 insertions(+) create mode 100644 drivers/spi/iproc_qspi.c create mode 100644 drivers/spi/iproc_qspi.h create mode 100644 drivers/spi/iproc_spi.c -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] arm: cpu: armv8: add support for arm psci reset2.
From: Rajesh Ravi
Current U-Boot has only support for psci reset.
Adding support for arm psci reset2 allows passing of reset level
and other platform sepcific parameters like strap settings
to lowlevel psci implementation.
Signed-off-by: Rajesh Ravi
Signed-off-by: Vladimir Olovyannikov
---
arch/arm/cpu/armv8/fwcall.c | 16
arch/arm/include/asm/psci.h | 4
arch/arm/include/asm/system.h | 1 +
3 files changed, 21 insertions(+)
diff --git a/arch/arm/cpu/armv8/fwcall.c b/arch/arm/cpu/armv8/fwcall.c
index b0aca1b72a..cbd35b7f4a 100644
--- a/arch/arm/cpu/armv8/fwcall.c
+++ b/arch/arm/cpu/armv8/fwcall.c
@@ -98,6 +98,22 @@ void __noreturn psci_system_reset(void)
;
}
+void __noreturn psci_system_reset2(u32 reset_level, u32 cookie)
+{
+ struct pt_regs regs;
+
+ regs.regs[0] = ARM_PSCI_0_2_FN64_SYSTEM_RESET2;
+ regs.regs[1] = PSCI_RESET2_TYPE_VENDOR | reset_level;
+ regs.regs[2] = cookie;
+ if (use_smc_for_psci)
+ smc_call();
+ else
+ hvc_call();
+
+ while (1)
+ ;
+}
+
void __noreturn psci_system_off(void)
{
struct pt_regs regs;
diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h
index 95f18e8cbc..3ddcd95a26 100644
--- a/arch/arm/include/asm/psci.h
+++ b/arch/arm/include/asm/psci.h
@@ -64,6 +64,7 @@
#define ARM_PSCI_0_2_FN64_AFFINITY_INFOARM_PSCI_0_2_FN64(4)
#define ARM_PSCI_0_2_FN64_MIGRATE ARM_PSCI_0_2_FN64(5)
#define ARM_PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU ARM_PSCI_0_2_FN64(7)
+#define ARM_PSCI_0_2_FN64_SYSTEM_RESET2ARM_PSCI_0_2_FN64(18)
/* PSCI 1.0 interface */
#define ARM_PSCI_1_0_FN_PSCI_FEATURES ARM_PSCI_0_2_FN(10)
@@ -90,6 +91,9 @@
#define PSCI_AFFINITY_LEVEL_OFF1
#define PSCI_AFFINITY_LEVEL_ON_PENDING 2
+#define PSCI_RESET2_TYPE_VENDOR_SHIFT 31
+#define PSCI_RESET2_TYPE_VENDOR
BIT(PSCI_RESET2_TYPE_VENDOR_SHIFT)
+
#ifndef __ASSEMBLY__
#include
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index a1a5e35ef6..81ccead112 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -254,6 +254,7 @@ void mmu_change_region_attr(phys_addr_t start, size_t size,
u64 attrs);
void smc_call(struct pt_regs *args);
void __noreturn psci_system_reset(void);
+void __noreturn psci_system_reset2(u32 reset_level, u32 cookie);
void __noreturn psci_system_off(void);
#ifdef CONFIG_ARMV8_PSCI
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] pinctrl: pinctrl-single: Add request api
From: Rayagonda Kokatanur
Add pinctrl_ops->request api to configure pctrl pad register
to configure in gpio mode.
Signed-off-by: Rayagonda Kokatanur
Signed-off-by: Vladimir Olovyannikov
---
drivers/pinctrl/pinctrl-single.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 6c6a33e4c5..2dcc131513 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -136,6 +136,35 @@ static int single_configure_bits(struct udevice *dev,
}
return 0;
}
+
+static int single_request(struct udevice *dev, int pin, int flags)
+{
+ struct single_pdata *pdata = dev->platdata;
+ struct single_gpiofunc_range *frange = NULL;
+ struct list_head *pos, *tmp;
+ int mux_bytes = 0;
+ u32 data;
+
+ if (!pdata->mask)
+ return -ENOTSUPP;
+
+ list_for_each_safe(pos, tmp, >gpiofuncs) {
+ frange = list_entry(pos, struct single_gpiofunc_range, node);
+ if ((pin >= frange->offset + frange->npins) ||
+ pin < frange->offset)
+ continue;
+
+ mux_bytes = pdata->width / BITS_PER_BYTE;
+ data = pdata->read(pdata->base + pin * mux_bytes);
+ data &= ~pdata->mask;
+ data |= frange->gpiofunc;
+ pdata->write(data, pdata->base + pin * mux_bytes);
+ break;
+ }
+
+ return 0;
+}
+
static int single_set_state(struct udevice *dev,
struct udevice *config)
{
@@ -235,6 +264,7 @@ static int single_ofdata_to_platdata(struct udevice *dev)
const struct pinctrl_ops single_pinctrl_ops = {
.set_state = single_set_state,
+ .request = single_request,
};
static const struct udevice_id single_pinctrl_match[] = {
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] pinctrl: pinctrl-single: Handle different register width
From: Rayagonda Kokatanur
Add support to use different register read/write api's
based on register width.
Signed-off-by: Rayagonda Kokatanur
Signed-off-by: Vladimir Olovyannikov
---
drivers/pinctrl/pinctrl-single.c | 111 ++-
1 file changed, 80 insertions(+), 31 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 1dfc97dcea..6c6a33e4c5 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -11,12 +11,23 @@
DECLARE_GLOBAL_DATA_PTR;
+/**
+ * struct single_pdata - pinctrl device instance
+ * @base first configuration register
+ * @offset index of last configuration register
+ * @mask configuration-value mask bits
+ * @width configuration register bit width
+ * @read register read function to use
+ * @write register write function to use
+ */
struct single_pdata {
- fdt_addr_t base;/* first configuration register */
- int offset; /* index of last configuration register */
- u32 mask; /* configuration-value mask bits */
- int width; /* configuration register bit width */
+ void __iomem *base;
+ int offset;
+ u32 mask;
+ int width;
bool bits_per_mux;
+ u32 (*read)(void __iomem *reg);
+ void (*write)(u32 val, void __iomem *reg);
};
struct single_fdt_pin_cfg {
@@ -30,6 +41,36 @@ struct single_fdt_bits_cfg {
fdt32_t mask; /* configuration register mask */
};
+static u32 __maybe_unused single_readb(void __iomem *reg)
+{
+ return readb(reg);
+}
+
+static u32 __maybe_unused single_readw(void __iomem *reg)
+{
+ return readw(reg);
+}
+
+static u32 __maybe_unused single_readl(void __iomem *reg)
+{
+ return readl(reg);
+}
+
+static void __maybe_unused single_writeb(u32 val, void __iomem *reg)
+{
+ writeb(val, reg);
+}
+
+static void __maybe_unused single_writew(u32 val, void __iomem *reg)
+{
+ writew(val, reg);
+}
+
+static void __maybe_unused single_writel(u32 val, void __iomem *reg)
+{
+ writel(val, reg);
+}
+
/**
* single_configure_pins() - Configure pins based on FDT data
*
@@ -55,24 +96,15 @@ static int single_configure_pins(struct udevice *dev,
for (n = 0; n < count; n++, pins++) {
reg = fdt32_to_cpu(pins->reg);
- if ((reg < 0) || (reg > pdata->offset)) {
+ if (reg > pdata->offset) {
dev_dbg(dev, " invalid register offset 0x%pa\n", );
continue;
}
- reg += pdata->base;
+ reg += (phys_addr_t)pdata->base;
val = fdt32_to_cpu(pins->val) & pdata->mask;
- switch (pdata->width) {
- case 16:
- writew((readw(reg) & ~pdata->mask) | val, reg);
- break;
- case 32:
- writel((readl(reg) & ~pdata->mask) | val, reg);
- break;
- default:
- dev_warn(dev, "unsupported register width %i\n",
-pdata->width);
- continue;
- }
+ val |= pdata->read((void __iomem *)reg) & ~pdata->mask;
+ pdata->write(val, (void __iomem *)reg);
+
dev_dbg(dev, " reg/val 0x%pa/0x%08x\n", , val);
}
return 0;
@@ -97,19 +129,9 @@ static int single_configure_bits(struct udevice *dev,
mask = fdt32_to_cpu(pins->mask);
val = fdt32_to_cpu(pins->val) & mask;
+ val |= pdata->read((void __iomem *)reg) & ~mask;
+ pdata->write(val, (void __iomem *)reg);
- switch (pdata->width) {
- case 16:
- writew((readw(reg) & ~mask) | val, reg);
- break;
- case 32:
- writel((readl(reg) & ~mask) | val, reg);
- break;
- default:
- dev_warn(dev, "unsupported register width %i\n",
-pdata->width);
- continue;
- }
dev_dbg(dev, " reg/val 0x%pa/0x%08x\n", , val);
}
return 0;
@@ -153,6 +175,32 @@ static int single_set_state(struct udevice *dev,
return len;
}
+static int single_probe(struct udevice *dev)
+{
+ struct single_pdata *pdata = dev->platdata;
+
+ switch (pdata->width) {
+ case 8:
+ pdata->read = single_readb;
+ pdata->write = single_writeb;
+ break;
+ case 16:
+ pdata->read = single_readw;
+ pdata->write = single_writew;
+ break;
+ case 32:
+ pdata->read = single_readl;
+ pdata->write = single_writel;
+ break;
+
[U-Boot] [PATCH 3/3] pinctrl: pinctrl-single: Parse gpio details from dt
From: Rayagonda Kokatanur
Parse different gpio properties from dt as part of probe
function. This detail is required to enable pinctrl pad.
Signed-off-by: Rayagonda Kokatanur
Signed-off-by: Vladimir Olovyannikov
---
drivers/pinctrl/pinctrl-single.c | 61 +++-
1 file changed, 60 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 2dcc131513..449e8a2bfe 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -5,18 +5,35 @@
#include
#include
+#include
#include
#include
#include
DECLARE_GLOBAL_DATA_PTR;
+/**
+ * struct single_gpiofunc_range - pin ranges with same mux value of gpio fun
+ * @offset:offset base of pins
+ * @npins: number pins with the same mux value of gpio function
+ * @gpiofunc: mux value of gpio function
+ * @node: list node
+ */
+struct single_gpiofunc_range {
+ u32 offset;
+ u32 npins;
+ u32 gpiofunc;
+ struct list_head node;
+};
+
/**
* struct single_pdata - pinctrl device instance
* @base first configuration register
* @offset index of last configuration register
* @mask configuration-value mask bits
* @width configuration register bit width
+ * @mutex mutex protecting the list
+ * @gpiofuncs list of gpio functions
* @read register read function to use
* @write register write function to use
*/
@@ -26,6 +43,8 @@ struct single_pdata {
u32 mask;
int width;
bool bits_per_mux;
+ struct mutex mutex;
+ struct list_head gpiofuncs;
u32 (*read)(void __iomem *reg);
void (*write)(u32 val, void __iomem *reg);
};
@@ -204,9 +223,42 @@ static int single_set_state(struct udevice *dev,
return len;
}
+static int single_add_gpio_func(struct udevice *dev,
+ struct single_pdata *pdata)
+{
+ const char *propname = "pinctrl-single,gpio-range";
+ const char *cellname = "#pinctrl-single,gpio-range-cells";
+ struct single_gpiofunc_range *range;
+ struct ofnode_phandle_args gpiospec;
+ int ret, i;
+
+ for (i = 0; ; i++) {
+ ret = ofnode_parse_phandle_with_args(dev->node, propname,
+cellname, 0, i, );
+ /* Do not treat it as error. Only treat it as end condition. */
+ if (ret) {
+ ret = 0;
+ break;
+ }
+ range = devm_kzalloc(dev, sizeof(*range), GFP_KERNEL);
+ if (!range) {
+ ret = -ENOMEM;
+ break;
+ }
+ range->offset = gpiospec.args[0];
+ range->npins = gpiospec.args[1];
+ range->gpiofunc = gpiospec.args[2];
+ mutex_lock(>mutex);
+ list_add_tail(>node, >gpiofuncs);
+ mutex_unlock(>mutex);
+ }
+ return ret;
+}
+
static int single_probe(struct udevice *dev)
{
struct single_pdata *pdata = dev->platdata;
+ int ret;
switch (pdata->width) {
case 8:
@@ -227,7 +279,14 @@ static int single_probe(struct udevice *dev)
return -EINVAL;
}
- return 0;
+ mutex_init(>mutex);
+ INIT_LIST_HEAD(>gpiofuncs);
+
+ ret = single_add_gpio_func(dev, pdata);
+ if (ret < 0)
+ dev_err(dev, "%s: Failed to add gpio functions\n", __func__);
+
+ return ret;
}
static int single_ofdata_to_platdata(struct udevice *dev)
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/3] Extend pinctrl-single driver with APIs
This patch set adds APIs for pinctrl-single driver. 1. Support to use different register read/write api's based on register width. 2. pinctrl_ops->request api to configure pctrl pad register in gpio mode. 3. Parse different gpio properties from dt as part of the probe function. This is required to enable pinctrl pad. Rayagonda Kokatanur (3): pinctrl: pinctrl-single: Handle different register width pinctrl: pinctrl-single: Add request api pinctrl: pinctrl-single: Parse gpio details from dt drivers/pinctrl/pinctrl-single.c | 200 ++- 1 file changed, 169 insertions(+), 31 deletions(-) -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] drivers: pci: Fix Host bridge bus number issue
From: Srinath Mannam
Add changes to fix bus number of host bridge is set with device
sequence number issue.
All devices are managed using device sequence number. For PCIe,
devices enabled in DTS are added under PCIE_CLASS with consecutive
device sequence numbers to scan all pcie devices in sequence using
device sequence number. If a device is a bridge then it will enumerate
all endpoints in that bridge, and give sequence numbers in that order.
However, the parent device is a root bridge.
The solution is all bus numbers are device sequence number minus
root bridge sequence number. This way, every root bridge and its
downstream EPs bus numbers start from 0.
So root bridges are different hierarchy of bus numbers.
Signed-off-by: Srinath Mannam
Signed-off-by: Vladimir Olovyannikov
---
drivers/pci/pci-uclass.c | 8 +---
drivers/pci/pci_auto.c | 6 +-
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 896cb6b23a..eb7a01fd55 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -47,8 +47,9 @@ pci_dev_t dm_pci_get_bdf(struct udevice *dev)
{
struct pci_child_platdata *pplat = dev_get_parent_platdata(dev);
struct udevice *bus = dev->parent;
+ struct udevice *ctrl = pci_get_controller(dev);
- return PCI_ADD_BUS(bus->seq, pplat->devfn);
+ return PCI_ADD_BUS(bus->seq - ctrl->seq, pplat->devfn);
}
/**
@@ -760,11 +761,12 @@ int pci_bind_bus_devices(struct udevice *bus)
pci_dev_t bdf, end;
bool found_multi;
int ret;
+ struct udevice *ctrl = pci_get_controller(bus);
found_multi = false;
- end = PCI_BDF(bus->seq, PCI_MAX_PCI_DEVICES - 1,
+ end = PCI_BDF(bus->seq - ctrl->seq, PCI_MAX_PCI_DEVICES - 1,
PCI_MAX_PCI_FUNCTIONS - 1);
- for (bdf = PCI_BDF(bus->seq, 0, 0); bdf <= end;
+ for (bdf = PCI_BDF(bus->seq - ctrl->seq, 0, 0); bdf <= end;
bdf += PCI_BDF(0, 0, 1)) {
struct pci_child_platdata *pplat;
struct udevice *dev;
diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
index 28667bde8d..42bf51fef2 100644
--- a/drivers/pci/pci_auto.c
+++ b/drivers/pci/pci_auto.c
@@ -176,8 +176,12 @@ void dm_pciauto_prescan_setup_bridge(struct udevice *dev,
int sub_bus)
struct pci_region *pci_io;
u16 cmdstat, prefechable_64;
struct udevice *ctlr = pci_get_controller(dev);
+ struct udevice *parent = dev->parent;
struct pci_controller *ctlr_hose = dev_get_uclass_priv(ctlr);
+ if (!parent)
+ return;
+
pci_mem = ctlr_hose->pci_mem;
pci_prefetch = ctlr_hose->pci_prefetch;
pci_io = ctlr_hose->pci_io;
@@ -188,7 +192,7 @@ void dm_pciauto_prescan_setup_bridge(struct udevice *dev,
int sub_bus)
/* Configure bus number registers */
dm_pci_write_config8(dev, PCI_PRIMARY_BUS,
-PCI_BUS(dm_pci_get_bdf(dev)) - ctlr->seq);
+parent->seq - ctlr->seq);
dm_pci_write_config8(dev, PCI_SECONDARY_BUS, sub_bus - ctlr->seq);
dm_pci_write_config8(dev, PCI_SUBORDINATE_BUS, 0xff);
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] drivers: pci: pci-uclass: Get PCI dma regions support
From: Srinath Mannam
Add API to parse dma-regions given in PCIe host controller
DT node.
Signed-off-by: Srinath Mannam
Signed-off-by: Vladimir Olovyannikov
---
drivers/pci/pci-uclass.c | 41
include/pci.h| 2 ++
2 files changed, 43 insertions(+)
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index eb7a01fd55..ddc2d5cf2c 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -1166,6 +1166,47 @@ ulong pci_conv_size_to_32(ulong old, ulong value, uint
offset,
return value;
}
+int pci_get_dma_regions(struct udevice *dev, struct pci_region *memp, int
index)
+{
+ int pci_addr_cells, addr_cells, size_cells;
+ int cells_per_record;
+ const u32 *prop;
+ int len;
+ int i = 0;
+
+ prop = ofnode_get_property(dev_ofnode(dev), "dma-ranges", );
+ if (!prop) {
+ dev_err(dev, "%s: Cannot decode dma-ranges\n", __func__);
+ return -EINVAL;
+ }
+
+ pci_addr_cells = ofnode_read_simple_addr_cells(dev_ofnode(dev));
+ addr_cells = ofnode_read_simple_addr_cells(dev_ofnode(dev->parent));
+ size_cells = ofnode_read_simple_size_cells(dev_ofnode(dev));
+
+ /* PCI addresses are always 3-cells */
+ len /= sizeof(u32);
+ cells_per_record = pci_addr_cells + addr_cells + size_cells;
+ debug("%s: len=%d, cells_per_record=%d\n", __func__, len,
+ cells_per_record);
+
+ while (len) {
+ memp->bus_start = fdtdec_get_number(prop + 1, 2);
+ prop += pci_addr_cells;
+ memp->phys_start = fdtdec_get_number(prop, addr_cells);
+ prop += addr_cells;
+ memp->size = fdtdec_get_number(prop, size_cells);
+ prop += size_cells;
+
+ if (i == index)
+ return 0;
+ i++;
+ len -= cells_per_record;
+ }
+
+ return -EINVAL;
+}
+
int pci_get_regions(struct udevice *dev, struct pci_region **iop,
struct pci_region **memp, struct pci_region **prefp)
{
diff --git a/include/pci.h b/include/pci.h
index ff59ac0e69..ef55f54ea5 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -1284,6 +1284,8 @@ struct udevice *pci_get_controller(struct udevice *dev);
int pci_get_regions(struct udevice *dev, struct pci_region **iop,
struct pci_region **memp, struct pci_region **prefp);
+int
+pci_get_dma_regions(struct udevice *dev, struct pci_region *memp, int index);
/**
* dm_pci_write_bar32() - Write the address of a BAR
*
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/3] Introduce APIs for multi PCIe host controller platforms
This patch set contains proposed API changes to the pci uclass for multi PCIe host controller platforms. 1. Add changes to fix bus number of a host bridge Differentiate bus numbers hierarchy for root bridges. All bus numbers are device sequence numbers minus root bridge sequence number. This way, every root bridge and its downstream EPs bus numbers start from 0. Thus, root bridges are different hierarchy of bus numbers. 2. Get next device fail with driver probe fail In Multi PCIe host controller platforms, if one PCIe host driver probe fails for any reason, the next PCIe host controller device pointer should be tried with its driver probe. Instead, currently the code simply stops enumeration. Add the feature described above. 3. Add ability to parse dma-regions given in PCIe host controller's DT node. Srinath Mannam (3): drivers: pci: Fix Host bridge bus number issue drivers: core: uclass: Get next device fail with driver probe fail drivers: pci: pci-uclass: Get PCI dma regions support drivers/core/uclass.c| 2 +- drivers/pci/pci-uclass.c | 49 +--- drivers/pci/pci_auto.c | 6 - include/pci.h| 2 ++ 4 files changed, 54 insertions(+), 5 deletions(-) -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] drivers: core: uclass: Get next device fail with driver probe fail
From: Srinath Mannam Add changes to fix get next device failed if driver probe failed issue. In Multi PCIe host controller platforms, if one PCIe host driver probe failed with any reason then it stops to find next PCIe host controller device pointer to call its driver probe. Signed-off-by: Srinath Mannam Signed-off-by: Vladimir Olovyannikov --- drivers/core/uclass.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c index c520ef113a..ab50f8f6db 100644 --- a/drivers/core/uclass.c +++ b/drivers/core/uclass.c @@ -442,7 +442,7 @@ int uclass_get_device_tail(struct udevice *dev, int ret, struct udevice **devp) assert(dev); ret = device_probe(dev); if (ret) - return ret; + dev_dbg(dev, "%s device_probe failed\n", __func__); *devp = dev; -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-sh/master
On Fri, Nov 22, 2019 at 01:39:39PM +0100, Marek Vasut wrote: > The following changes since commit 3ff1ff3ff76c15efe0451309af084ee6c096c583: > > Merge branch '2019-11-12-migrate-SYS_REDUNDAND_ENVIRONMENT' > (2019-11-12 13:40:58 -0500) > > are available in the Git repository at: > > git://git.denx.de/u-boot-sh.git master > > for you to fetch changes up to 8cdb1ff33caa4b2b8644e14e602566ded506a2fa: > > ARM: rmobile: Temporarily disable PCI dma-ranges update (2019-11-16 > 16:52:45 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-socfpga/master
On Fri, Nov 22, 2019 at 01:41:09PM +0100, Marek Vasut wrote: > The following changes since commit 8d8ee47e03ef23b0d0e842ea455a30bf0d2023b9: > > env: Add CONFIG_SYS_RELOC_GD_ENV_ADDR symbol (2019-11-20 12:24:50 -0500) > > are available in the Git repository at: > > git://git.denx.de/u-boot-socfpga.git master > > for you to fetch changes up to 0c14bb5ad3311de2c26e66e88f8a6886773b8e0a: > > arm: socfpga: stratix10: Add alias for gmac0 in S10 dts (2019-11-22 > 03:08:12 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
On Fri, Nov 22, 2019 at 01:39:05PM +0100, Marek Vasut wrote: > The following changes since commit d4a31e8ee5592072d8d5208b3e950cba2d89b6bd: > > Prepare v2020.01-rc3 (2019-11-18 21:31:49 -0500) > > are available in the Git repository at: > > git://git.denx.de/u-boot-usb.git master > > for you to fetch changes up to 7dc0ac6015718f5fb66bb79bf53df19f64fbfeee: > > usb: dwc2: fix possible alignment issues (2019-11-22 01:25:40 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] drivers: pcie: Add Broadcom IPROC PCIe driver
From: Srinath Mannam
Add support of IPROC PCIe driver for Broadcom Iproc SoCs.
Signed-off-by: Srinath Mannam
Signed-off-by: Vladimir Olovyannikov
---
drivers/pci/Kconfig |6 +
drivers/pci/Makefile |1 +
drivers/pci/pcie_iproc.c | 1238 ++
3 files changed, 1245 insertions(+)
create mode 100644 drivers/pci/pcie_iproc.c
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 13603b9d57..0adc28623c 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -75,6 +75,12 @@ config PCIE_FSL
PowerPC MPC85xx, MPC86xx, B series, P series and T series SoCs.
This driver does not support SRIO_PCIE_BOOT feature.
+config PCIE_IPROC
+ bool "Broadcom Iproc PCIe driver"
+ depends on DM_PCI
+ help
+ Say Y here if you want to enable Broadcom iProc PCIe controller.
+
config PCI_MPC85XX
bool "MPC85XX PowerPC PCI support"
depends on DM_PCI
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 219473aa79..49192ad923 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_SH4_PCI) += pci_sh4.o
obj-$(CONFIG_SH7751_PCI) +=pci_sh7751.o
obj-$(CONFIG_SH7780_PCI) +=pci_sh7780.o
obj-$(CONFIG_PCI_TEGRA) += pci_tegra.o
+obj-$(CONFIG_PCIE_IPROC) += pcie_iproc.o
obj-$(CONFIG_PCI_AARDVARK) += pci-aardvark.o
obj-$(CONFIG_PCIE_DW_MVEBU) += pcie_dw_mvebu.o
obj-$(CONFIG_PCIE_FSL) += pcie_fsl.o pcie_fsl_fixup.o
diff --git a/drivers/pci/pcie_iproc.c b/drivers/pci/pcie_iproc.c
new file mode 100644
index 00..9410f32a61
--- /dev/null
+++ b/drivers/pci/pcie_iproc.c
@@ -0,0 +1,1238 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * IPROC PCIe driver for Broadcom Iproc SoCs
+ * Copyright (C) Broadcom, 2019
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define EP_PERST_SOURCE_SELECT_SHIFT 2
+#define EP_PERST_SOURCE_SELECT BIT(EP_PERST_SOURCE_SELECT_SHIFT)
+#define EP_MODE_SURVIVE_PERST_SHIFT 1
+#define EP_MODE_SURVIVE_PERSTBIT(EP_MODE_SURVIVE_PERST_SHIFT)
+#define RC_PCIE_RST_OUTPUT_SHIFT 0
+#define RC_PCIE_RST_OUTPUT BIT(RC_PCIE_RST_OUTPUT_SHIFT)
+
+#define CFG_IND_ADDR_MASK0x1ffc
+
+#define CFG_ADDR_BUS_NUM_SHIFT 20
+#define CFG_ADDR_BUS_NUM_MASK0x0ff0
+#define CFG_ADDR_DEV_NUM_SHIFT 15
+#define CFG_ADDR_DEV_NUM_MASK0x000f8000
+#define CFG_ADDR_FUNC_NUM_SHIFT 12
+#define CFG_ADDR_FUNC_NUM_MASK 0x7000
+#define CFG_ADDR_REG_NUM_SHIFT 2
+#define CFG_ADDR_REG_NUM_MASK0x0ffc
+#define CFG_ADDR_CFG_TYPE_SHIFT 0
+#define CFG_ADDR_CFG_TYPE_MASK 0x0003
+
+#define IPROC_PCI_PM_CAP 0x48
+#define IPROC_PCI_PM_CAP_MASK0x
+#define IPROC_PCI_EXP_CAP0xac
+
+#define IPROC_PCIE_REG_INVALID 0x
+
+#define PCI_EXP_TYPE_ROOT_PORT 0x4 /* Root Port */
+#define PCI_EXP_RTCTL28 /* Root Control */
+/* CRS Software Visibility capability */
+#define PCI_EXP_RTCAP_CRSVIS 0x0001
+
+#define PCI_EXP_LNKSTA 18 /* Link Status */
+#define PCI_EXP_LNKSTA_NLW 0x03f0 /* Negotiated Link Width */
+
+#define PCIE_PHYLINKUP_SHIFT 3
+#define PCIE_PHYLINKUP BIT(PCIE_PHYLINKUP_SHIFT)
+#define PCIE_DL_ACTIVE_SHIFT 2
+#define PCIE_DL_ACTIVE BIT(PCIE_DL_ACTIVE_SHIFT)
+
+/* derive the enum index of the outbound/inbound mapping registers */
+#define MAP_REG(base_reg, index) ((base_reg) + (index) * 2)
+
+/*
+ * Maximum number of outbound mapping window sizes that can be supported by any
+ * OARR/OMAP mapping pair
+ */
+#define MAX_NUM_OB_WINDOW_SIZES 4
+
+#define OARR_VALID_SHIFT 0
+#define OARR_VALID BIT(OARR_VALID_SHIFT)
+#define OARR_SIZE_CFG_SHIFT 1
+
+/*
+ * Maximum number of inbound mapping region sizes that can be supported by an
+ * IARR
+ */
+#define MAX_NUM_IB_REGION_SIZES 9
+
+#define IMAP_VALID_SHIFT 0
+#define IMAP_VALID BIT(IMAP_VALID_SHIFT)
+
+#define APB_ERR_EN_SHIFT 0
+#define APB_ERR_EN BIT(APB_ERR_EN_SHIFT)
+/*
+ * iProc PCIe host registers
+ */
+enum iproc_pcie_reg {
+ /* clock/reset signal control */
+ IPROC_PCIE_CLK_CTRL = 0,
+
+ /*
+* To allow MSI to be steered to an external MSI controller (e.g., ARM
+* GICv3 ITS)
+*/
+ IPROC_PCIE_MSI_GIC_MODE,
+
+ /*
+* IPROC_PCIE_MSI_BASE_ADDR and IPROC_PCIE_MSI_WINDOW_SIZE define the
+* window where the MSI posted writes are written, for the writes to be
+* interpreted as MSI writes.
+*/
+ IPROC_PCIE_MSI_BASE_ADDR,
+ IPROC_PCIE_MSI_WINDOW_SIZE,
+
+ /*
+* To hold the address of the register where the MSI writes are
+* programed. When ARM GICv3 ITS is used, this should be programmed
+* with the address of the
[U-Boot] [PATCH] usb: Make USB_MUSB_PIO_ONLY conditional on USB_MUSB_{HOST, GADGET}
This ensures the USB_MUSB_PIO_ONLY config is set to an apppropriate default values from the changes enabling USB_MUSB_GADGET does. Namely, USB_MUSB_PIO_ONLY default to =y on USB_MUSB_SUNXI being y. Since USB_MUSB_SUNXI is behind the conditional, the option does not exist when using make ..._defconfig, thus the default of USB_MUSB_PIO_ONLY is kept "# ... is not set". This, _is_ counter-intuitively a set value, meaning that the default will not be applied once USB_MUSB_SUNXI is set to y by toggling USB_MUSB_GADGET via menuconfig. Signed-off-by: Samuel Dionne-Riel --- Some additional context about the bug. Using `make ..._defconfig` for a sunxi board, then using `make menuconfig` to change the option `CONFIG_USB_MUSB_GADGET=y` causes builds to fail. When the same option is set to `=y` via the defconfig file, the option work. Follows the failure: ``` CC drivers/usb/musb-new/musb_gadget.o drivers/usb/musb-new/musb_gadget.c: In function 'map_dma_buffer': drivers/usb/musb-new/musb_gadget.c:103:26: warning: implicit declaration of function 'dma_map_single'; did you mean 'malloc_simple'? [-Wimplicit-function-declaration] request->request.dma = dma_map_single( ^~ malloc_simple drivers/usb/musb-new/musb_gadget.c:108:8: error: 'DMA_TO_DEVICE' undeclared (first use in this function); did you mean 'USB_DT_DEVICE'? ? DMA_TO_DEVICE ^ USB_DT_DEVICE drivers/usb/musb-new/musb_gadget.c:108:8: note: each undeclared identifier is reported only once for each function it appears in drivers/usb/musb-new/musb_gadget.c:109:8: error: 'DMA_FROM_DEVICE' undeclared (first use in this function); did you mean 'U_BOOT_DEVICE'? : DMA_FROM_DEVICE); ^~~ U_BOOT_DEVICE drivers/usb/musb-new/musb_gadget.c:112:3: warning: implicit declaration of function 'dma_sync_single_for_device' [-Wimplicit-function-declaration] dma_sync_single_for_device(musb->controller, ^~ drivers/usb/musb-new/musb_gadget.c: In function 'unmap_dma_buffer': drivers/usb/musb-new/musb_gadget.c:135:3: warning: implicit declaration of function 'dma_unmap_single' [-Wimplicit-function-declaration] dma_unmap_single(musb->controller, ^~~~ drivers/usb/musb-new/musb_gadget.c:139:7: error: 'DMA_TO_DEVICE' undeclared (first use in this function); did you mean 'USB_DT_DEVICE'? ? DMA_TO_DEVICE ^ USB_DT_DEVICE drivers/usb/musb-new/musb_gadget.c:140:7: error: 'DMA_FROM_DEVICE' undeclared (first use in this function); did you mean 'U_BOOT_DEVICE'? : DMA_FROM_DEVICE); ^~~ U_BOOT_DEVICE drivers/usb/musb-new/musb_gadget.c:143:3: warning: implicit declaration of function 'dma_sync_single_for_cpu' [-Wimplicit-function-declaration] dma_sync_single_for_cpu(musb->controller, ^~~ make[1]: *** [scripts/Makefile.build:279: drivers/usb/musb-new/musb_gadget.o] Error 1 ``` By diffing the resulting configuration, Othe main difference found is `CONFIG_USB_MUSB_PIO_ONLY` is not set when failing, and set to `=y` when working. This was verified to be the missing option. As far as I understand it in Kconfig, "is not set" basically marks the option as using a negative "unset" value, and does not mean that it will use the default value. This difference in meaning makes it so that when toggling the option with `make menuconfig`, the option has already been set to "is not set", and it does not change to its default value. The actual bug may be that there is a regression and the code should work when this value is unset, in this case I do not know how to provide the proper fix. This fix corrects the issue by gating the option behind `if USB_MUSB_HOST || USB_MUSB_GADGET`. To me, it looks like this was the intention, in the initial patch, but might have been overlooked. I assume so since the option was defined after the `if`, rather than before, like the other options not gated behind the option. drivers/usb/musb-new/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/musb-new/Kconfig b/drivers/usb/musb-new/Kconfig index 79ad14ef66..95499f1b17 100644 --- a/drivers/usb/musb-new/Kconfig +++ b/drivers/usb/musb-new/Kconfig @@ -72,11 +72,11 @@ config USB_MUSB_DISABLE_BULK_COMBINE_SPLIT support it yet. Select this option to disable the feature until the driver adds the support. -endif - config USB_MUSB_PIO_ONLY bool "Disable DMA (always use PIO)" default y if USB_MUSB_AM35X || USB_MUSB_PIC32 || USB_MUSB_OMAP2PLUS || USB_MUSB_DSPS || USB_MUSB_SUNXI help All data is copied between memory and FIFO by the CPU. DMA controllers are ignored. + +endif -- 2.23.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] cmd: gpt: Enumerate partitions and save info into an U-Boot variable
From: Corneliu Doban
Add enumeration of gpt partitions and saving this information into
U-Boot variables.
Signed-off-by: Corneliu Doban
Signed-off-by: Vladimir Olovyannikov
---
cmd/gpt.c | 95 +++
1 file changed, 95 insertions(+)
diff --git a/cmd/gpt.c b/cmd/gpt.c
index 0c4349f4b2..061ffaa757 100644
--- a/cmd/gpt.c
+++ b/cmd/gpt.c
@@ -2,6 +2,8 @@
/*
* cmd_gpt.c -- GPT (GUID Partition Table) handling command
*
+ * Copyright (C) 2019 Broadcom
+ * author: Corneliu Doban
* Copyright (C) 2015
* Lukasz Majewski
*
@@ -804,6 +806,88 @@ static int do_rename_gpt_parts(struct blk_desc *dev_desc,
char *subcomm,
}
#endif
+/*
+ * Enumerate partition names into environment variable.
+ */
+static int gpt_enumerate(struct blk_desc *blk_dev_desc)
+{
+ disk_partition_t pinfo;
+ struct part_driver *first_drv =
+ ll_entry_start(struct part_driver, part_driver);
+ const int n_drvs = ll_entry_count(struct part_driver, part_driver);
+ struct part_driver *part_drv;
+ char part_list[2048];
+
+ part_list[0] = 0;
+
+ for (part_drv = first_drv; part_drv != first_drv + n_drvs; part_drv++) {
+ int ret;
+ int i;
+
+ for (i = 1; i < part_drv->max_entries; i++) {
+ ret = part_drv->get_info(blk_dev_desc, i, );
+ if (ret != 0) {
+ /* no more entries in table */
+ break;
+ }
+ strcat(part_list, (const char *)pinfo.name);
+ strcat(part_list, " ");
+ }
+ }
+ if (strlen(part_list) > 0)
+ part_list[strlen(part_list) - 1] = 0;
+ debug("setenv gpt_partition_list %s\n", part_list);
+ env_set("gpt_partition_list", part_list);
+ return 0;
+}
+
+/*
+ * Dynamically setup environment variables for name, index, offset and size
+ * for partition in GPT table after running "gpt setenv" for a partition name.
+ * gpt_partition_name, gpt_partition_entry, gpt_partition_addr and
+ * gpt_partition_size environment variables will be set.
+ */
+static int gpt_setenv(struct blk_desc *blk_dev_desc, const char *name)
+{
+ disk_partition_t pinfo;
+ struct part_driver *first_drv =
+ ll_entry_start(struct part_driver, part_driver);
+ const int n_drvs = ll_entry_count(struct part_driver, part_driver);
+ struct part_driver *part_drv;
+ char buf[32];
+
+ for (part_drv = first_drv; part_drv != first_drv + n_drvs; part_drv++) {
+ int ret;
+ int i;
+
+ for (i = 1; i < part_drv->max_entries; i++) {
+ ret = part_drv->get_info(blk_dev_desc, i, );
+
+ if (ret != 0) {
+ /* no more entries in table */
+ break;
+ }
+ if (strcmp(name, (const char *)pinfo.name) == 0) {
+ /* match found, setup environment variables */
+ sprintf(buf, LBAF, pinfo.start);
+ debug("setenv gpt_partition_addr %s\n", buf);
+ env_set("gpt_partition_addr", buf);
+ sprintf(buf, LBAF, pinfo.size);
+ debug("setenv gpt_partition_size %s\n", buf);
+ env_set("gpt_partition_size", buf);
+ sprintf(buf, "%d", i);
+ debug("setenv gpt_partition_entry %s\n", buf);
+ env_set("gpt_partition_entry", buf);
+ sprintf(buf, "%s", pinfo.name);
+ debug("setenv gpt_partition_name %s\n", buf);
+ env_set("gpt_partition_name", buf);
+ return 0;
+ }
+ }
+ }
+ return -1;
+}
+
/**
* do_gpt(): Perform GPT operations
*
@@ -855,6 +939,10 @@ static int do_gpt(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
(strcmp(argv[1], "rename") == 0)) {
ret = do_rename_gpt_parts(blk_dev_desc, argv[1], argv[4],
argv[5]);
#endif
+ } else if ((strcmp(argv[1], "setenv") == 0)) {
+ ret = gpt_setenv(blk_dev_desc, argv[4]);
+ } else if ((strcmp(argv[1], "enumerate") == 0)) {
+ ret = gpt_enumerate(blk_dev_desc);
} else {
return CMD_RET_USAGE;
}
@@ -897,4 +985,11 @@ U_BOOT_CMD(gpt, CONFIG_SYS_MAXARGS, 1, do_gpt,
" gpt swap mmc 0 foo bar\n"
" gpt rename mmc 0 3 foo\n"
#endif
+ " gpt setenv mmc 0 $name\n"
+ "- setup environment variables for partition $name:\n"
+ " gpt_partition_addr, gpt_partition_size,\n"
+
Re: [U-Boot] [PATCH v4 1/5] net: phy: mv88e61xx: rework to enable detection of 88E6071 devices
On Sat, Oct 26, 2019 at 6:17 PM Anatolij Gustschin wrote: > > Extend the driver to init switch register offsets from variables > instead of compile time macros and enable detection of 88E6071 and > compatible devices. Ethernet transfer (e.g. tftp) does not work yet, > so enable the registration of the 'indirect mii' bus for easier PHY > register access by 'mii' command. > > Signed-off-by: Anatolij Gustschin Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Using kernelCI infrastructure for firmware testing
"Patrick Rudolph" writes: > Hi folks, > this is an attempt to improve firmware testing by using the > infrastructure and knowledge of the kernelci community. If you think > this is not the right place, please point me in the right direction. > > I'm a coreboot[1] developer trying to make sure that the master > branch[2] doesn't regress. Currently there's no public firmware > testing, only internal validation suites used by some companies that > lack direct and automated feedback before a commit is actually merged. > As this isn't a coreboot only topic, but applies to all open source > "bios vendors", I added the u-boot project in CC as well. > > For me firmware testing looks pretty similar to kernel testing: > * flash firmware to test > * boot a known good linux kernel > * run tests in userspace and verify hardware/software works as expected > > On the hardware side we have boards in our lab that allow remote power > cycling and firmware flashing. It is attached to self hosted stock > LAVA2018. But as we are firmware engineers, we don't want to deal with > the administration of servers. > > Here are a few questions for you: > * Would it make sense to also cover open source firmware tests on kernelci? Yes. We've talked about this a few times over the years, and all the infra and tooling we have built for kernelCI would be well suited for firmware testing. The catch is mostly in time/resources invested. For now, we are primarily focused on kernel testing, but if there are contributors that want to extend this to firmware, we are an open-source project and welcome the contributions. I would say the primary challenge here is that each SoC family, and sometimes even each board has unique challenges to (re)flashing the firmware as well as the ability to recover from non-working firmware. This presents a problem not necessariuly for KernelCI but for the lab admins for that hardware, and especially those writing the LAVA device-types for those platforms. I've added the main LAVA developer Remi Durrafort to Cc since he's been doing a lot of work in LAVA to make firmware updates and recovery mode usable from LAVA. Recent versions of LAVA seem to be growing better support for this: https://docs.lavasoftware.org/lava/bootloaders.html > * Do you build the linux images yourself? We build all the linux kernel images, but rely on the lab admins to have build/flashed working firmware and bootloaders. > * Would you accept firmware images generated by a third party? As long as the source is available and can be (re)built, that's typically fine. > * Can anybody get an account for the LAVA server to run firmware test? That's up to each LAVA lab administrator. Today, KernelCI uses a distributed set of (mostly LAVA) labs. Each lab admin has given priveleges to KernelCI to send jobs. > * What communication channels do you recommend? This mailing list is a good place to start, but to be completely honest, firmware testing is relatively low on our current list of priorites. But as I said above, it's feature we will welcome with open arms, even if it's not a feature that the current set of developers will be very active on. I would say your first step is probably to get some support for the devices you care about into upstream LAVA. Once that is working, we would work on how KernelCI could start generating jobs for those devices. > * Will there be meetings or conferences to get in contact with the > community to talk about this? We just had an automated-testing summit connected to Embedded Linux Conference Europe last month, where many of us were gathered. Remi even gave a talk on bootloader testing with LAVA, maybe he can share the slides for that. Kevin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/5] Extend mv88e61xx driver to support 88E6071
Hi Joe, On Sun, 27 Oct 2019 01:14:36 +0200 Anatolij Gustschin ag...@denx.de wrote: > This series adds support for 88E6071 and compatible switches in the > mv88e61xx driver. Ping. Is there a chance to queue this for merging in v2020.01 ? Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] drivers: i2c: Add brcm iproc I2C driver support
From: Arjun Jyothi Add I2C driver support for Broadcom iproc-based socs. Signed-off-by: Arjun Jyothi Signed-off-by: Rayagonda Kokatanur Signed-off-by: Sheetal Tigadoli Signed-off-by: Vladimir Olovyannikov --- drivers/i2c/Kconfig | 623 drivers/i2c/Makefile| 2 +- drivers/i2c/iproc_i2c.c | 765 drivers/i2c/iproc_i2c.h | 356 +++ 4 files changed, 1437 insertions(+), 309 deletions(-) create mode 100644 drivers/i2c/iproc_i2c.c create mode 100644 drivers/i2c/iproc_i2c.h diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig index 03d2fed341..7a80971b12 100644 --- a/drivers/i2c/Kconfig +++ b/drivers/i2c/Kconfig @@ -5,454 +5,461 @@ menu "I2C support" config DM_I2C - bool "Enable Driver Model for I2C drivers" - depends on DM - help - Enable driver model for I2C. The I2C uclass interface: probe, read, - write and speed, is implemented with the bus drivers operations, - which provide methods for bus setting and data transfer. Each chip - device (bus child) info is kept as parent platdata. The interface - is defined in include/i2c.h. +bool "Enable Driver Model for I2C drivers" +depends on DM +help + Enable driver model for I2C. The I2C uclass interface: probe, read, + write and speed, is implemented with the bus drivers operations, + which provide methods for bus setting and data transfer. Each chip + device (bus child) info is kept as parent platdata. The interface + is defined in include/i2c.h. config I2C_CROS_EC_TUNNEL - tristate "Chrome OS EC tunnel I2C bus" - depends on CROS_EC - help - This provides an I2C bus that will tunnel i2c commands through to - the other side of the Chrome OS EC to the I2C bus connected there. - This will work whatever the interface used to talk to the EC (SPI, - I2C or LPC). Some Chromebooks use this when the hardware design - does not allow direct access to the main PMIC from the AP. +tristate "Chrome OS EC tunnel I2C bus" +depends on CROS_EC +help + This provides an I2C bus that will tunnel i2c commands through to + the other side of the Chrome OS EC to the I2C bus connected there. + This will work whatever the interface used to talk to the EC (SPI, + I2C or LPC). Some Chromebooks use this when the hardware design + does not allow direct access to the main PMIC from the AP. config I2C_CROS_EC_LDO - bool "Provide access to LDOs on the Chrome OS EC" - depends on CROS_EC - ---help--- - On many Chromebooks the main PMIC is inaccessible to the AP. This is - often dealt with by using an I2C pass-through interface provided by - the EC. On some unfortunate models (e.g. Spring) the pass-through - is not available, and an LDO message is available instead. This - option enables a driver which provides very basic access to those - regulators, via the EC. We implement this as an I2C bus which - emulates just the TPS65090 messages we know about. This is done to - avoid duplicating the logic in the TPS65090 regulator driver for - enabling/disabling an LDO. +bool "Provide access to LDOs on the Chrome OS EC" +depends on CROS_EC +---help--- +On many Chromebooks the main PMIC is inaccessible to the AP. This is +often dealt with by using an I2C pass-through interface provided by +the EC. On some unfortunate models (e.g. Spring) the pass-through +is not available, and an LDO message is available instead. This +option enables a driver which provides very basic access to those +regulators, via the EC. We implement this as an I2C bus which +emulates just the TPS65090 messages we know about. This is done to +avoid duplicating the logic in the TPS65090 regulator driver for +enabling/disabling an LDO. config I2C_SET_DEFAULT_BUS_NUM - bool "Set default I2C bus number" - depends on DM_I2C - help - Set default number of I2C bus to be accessed. This option provides - behaviour similar to old (i.e. pre DM) I2C bus driver. +bool "Set default I2C bus number" +depends on DM_I2C +help + Set default number of I2C bus to be accessed. This option provides + behaviour similar to old (i.e. pre DM) I2C bus driver. config I2C_DEFAULT_BUS_NUMBER - hex "I2C default bus number" - depends on I2C_SET_DEFAULT_BUS_NUM - default 0x0 - help - Number of default I2C bus to use +hex "I2C default bus number" +depends on I2C_SET_DEFAULT_BUS_NUM +default 0x0 +help + Number of default I2C bus to use config DM_I2C_GPIO - bool "Enable Driver Model for software emulated I2C bus driver" - depends on DM_I2C && DM_GPIO - help - Enable the i2c bus driver emulation by using the GPIOs.
Re: [U-Boot] [PATCH v4 013/100] RFC: sandbox: net: Suppress the MAC-address warnings
Hi Simon,
On Thu, Nov 21, 2019 at 10:40 PM Simon Glass wrote:
>
> These warnings appear every thing sandbox is run (see below) and dwarf the
> actual useful output. Suppress them in two ways:
>
> 1. For the mismatch warnings, only set the ethaddr environment
> variables when running tests.
>
> 2. For the 'MAC address from ROM' warning, never print this on sandbox.
>
> Signed-off-by: Simon Glass
> ---
> Unfortunately this breaks the tests so is not applicable as is:
>
> $ /tmp/b/sandbox/u-boot -T -c "ut dm eth_prime"
>
> U-Boot 2019.10-00508-g95f6257285-dirty (Oct 13 2019 - 09:21:34 -0600)
>
> Model: sandbox
> DRAM: 128 MiB
> WDT: Started with servicing (60s timeout)
> MMC: mmc2: 2 (SD), mmc1: 1 (SD), mmc0: 0 (SD)
> In:serial
> Out: vidconsole
> Err: vidconsole
> Model: sandbox
> SCSI:
> Net:
> Error: eth@10002000 address not set.
> eth-1: eth@10002000
> Error: eth@10003000 address not set.
> , eth-1: eth@10003000
> Error: sbe5 address not set.
> , eth-1: sbe5
> Error: eth@10004000 address not set.
> , eth-1: eth@10004000
> Test: dm_test_eth_prime: eth.c
> Test: dm_test_eth_prime: eth.c (flat tree)
> Failures: 0
>
> Old output:
>
> U-Boot 2019.10-rc2
>
> Model: sandbox
> DRAM: 128 MiB
>
> Warning: host_lo MAC addresses don't match:
> Address in ROM is a6:28:b7:47:28:93
> Address in environment is 00:00:11:22:33:44
>
> Warning: host_enp5s0 MAC addresses don't match:
> Address in ROM is a6:28:b7:47:28:93
> Address in environment is 00:00:11:22:33:45
>
> Warning: host_eth6 using MAC address from ROM
>
> Warning: host_docker0 MAC addresses don't match:
> Address in ROM is a6:28:b7:47:28:93
> Address in environment is 00:00:11:22:33:46
>
> Warning: host_docker_gwbridge using MAC address from ROM
>
> Warning: host_veth1118e68 MAC addresses don't match:
> Address in ROM is a6:28:b7:47:28:93
> Address in environment is 00:00:11:22:33:47
> WDT: Not found!
> MMC:
> In:cros-ec-keyb
> Out: vidconsole
> Err: vidconsole
> Model: sandbox
> SCSI:
> Net: eth0: host_lo, eth1: host_enp5s0, eth2: host_eth6, eth3: host_docker0,
> eth4: host_docker_gwbridge, eth5: host_veth1118e68
> Error: eth@10002000 address not set.
> , eth-1: eth@10002000
> Test 'pmc_base' not found
>
> Warning: host_lo MAC addresses don't match:
> Address in ROM is 2a:24:9a:31:90:f8
> Address in environment is 00:00:11:22:33:44
>
> Warning: host_enp5s0 MAC addresses don't match:
> Address in ROM is ce:23:d9:74:6f:6c
> Address in environment is 00:00:11:22:33:45
>
> Warning: host_eth6 using MAC address from ROM
>
> Warning: host_docker0 MAC addresses don't match:
> Address in ROM is ee:22:1c:3b:be:bc
> Address in environment is 00:00:11:22:33:46
>
> Warning: host_docker_gwbridge using MAC address from ROM
>
> Warning: host_veth1118e68 MAC addresses don't match:
> Address in ROM is ae:20:9e:3d:a4:9f
> Address in environment is 00:00:11:22:33:47
>
> New output:
> U-Boot 2019.10
>
> Model: sandbox
> DRAM: 128 MiB
> WDT: Not found!
> MMC:
> In:cros-ec-keyb
> Out: vidconsole
> Err: vidconsole
> Model: sandbox
> SCSI:
> Net: eth0: host_lo, eth1: host_enp5s0, eth2: host_eth6, eth3: host_docker0,
> eth4: host_docker_gwbridge, eth5: host_vethc7e1b9e
> Error: eth@10002000 address not set.
> , eth-1: eth@10002000
> Hit any key to stop autoboot: 0
> =>
>
>
> Changes in v4: None
> Changes in v3:
> - Only supress the 'MAC address from ROM' warning on sandbox
> - Set the environment variables at runtime to avoid other warnings
>
> Changes in v2: None
>
> arch/sandbox/cpu/state.c | 12 ++--
> arch/sandbox/include/asm/state.h | 5 -
> cmd/nvedit.c | 8
> include/configs/sandbox.h| 7 ++-
> include/env.h| 12
> net/eth-uclass.c | 11 +--
> test/dm/test-main.c | 2 +-
> 7 files changed, 46 insertions(+), 11 deletions(-)
>
> diff --git a/arch/sandbox/cpu/state.c b/arch/sandbox/cpu/state.c
> index dee5fde4f7..70b278e4e2 100644
> --- a/arch/sandbox/cpu/state.c
> +++ b/arch/sandbox/cpu/state.c
> @@ -351,7 +351,7 @@ bool state_get_skip_delays(void)
> return state->skip_delays;
> }
>
> -void state_reset_for_test(struct sandbox_state *state)
> +void state_reset_for_test(struct sandbox_state *state, bool eth_vars)
> {
> /* No reset yet, so mark it as such. Always allow power reset */
> state->last_sysreset = SYSRESET_COUNT;
> @@ -367,6 +367,14 @@ void state_reset_for_test(struct sandbox_state *state)
> */
> INIT_LIST_HEAD(>mapmem_head);
> state->next_tag = state->ram_size;
> +
> + if (eth_vars) {
> + /* set up some environment variables needed by the eth tests
> */
> + env_set_for_test("ethaddr", "00:00:11:22:33:44");
> + env_set_for_test("eth1addr", "00:00:11:22:33:45");
> + env_set_for_test("eth3addr",
Re: [U-Boot] Maximum size of u-boot.imx for TBS2910 board
On 11/22/19 4:44 PM, Tom Rini wrote: > On Fri, Nov 22, 2019 at 04:58:29AM +0100, Marek Vasut wrote: >> On 11/22/19 4:41 AM, Tom Rini wrote: >> [...] >>> I believe >>> the specific changes in question that once again push this board >>> over >>> fall in to that grey area. Whatever size-trimming the board >>> maintainer >>> is fine with next is fine with me, but needs to get ack'd by >>> someone. >> >> Or, the other option is, make these new extra features configurable >> and >> disable them on this board. And so there should be no size problem. > > But that direction leads to saying every slight bit of functionality > requires a new Kconfig entry. Some levels of bugfixes as well. The other option is, we will sink in bloat and suffer endless size problems. >>> >>> Yes, it is a hard balancing act. Stepping back, perhaps a "minimal" or >>> "complete" choice for USB HID devices would make sense and allow us >>> further areas to reduce size, on the minimal portion. >> >> Or maybe there is a way to help compiler optimize that USB key code >> handling better. > > Perhaps. But my point is that every little functional change or > enhancement does not need a Kconfig option. Except this leads to slow and steady accumulation of bloat, and as we already see for quite a while, this is problematic for more and more boards. >>> >>> And "bloat" and "features" are interchangable terms. >> >> Nope, bloat is unhelpful growth of size, features are actually >> helpful/useful. >> >>> I really am trying >>> to be more responsive than ever to size growth in common, rather than >>> board specific areas. And I agree, some investigation in to ways that >>> might reduce the size of binary support for USB HID devices is good. >> >> So we agree that's what this series should fix ? >> >>> Figuring out if we can make this series: >>> http://patchwork.ozlabs.org/project/uboot/list/?series=135448 >>> not also increase the overall size, or increase it less, is good. >>> Hiding the content of 2/5 behind a CONFIG option in turn brings us back >>> to "the code is too messy and full of #ifdef" lines. >> >> Which might be somewhat better than if the code is sprinkled with tiny >> chunks of random pieces of code which are never used, but in total add >> up to a lot of unused code in the binary. > > If, with your USB custodian hat on, your answer to Heinrich is that his > changes expose a more fundamental problem with the code that needs > addressing then no, I'm not overriding your objection. The fundamental problem is that we are letting too much bloat in and now it starts to take over useful functionality on existing devices. I am strongly opposed to this, that's the fundamental problem we need to deal with. Heinrichs' approach only underlined the problem. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] usb: composite: fix possible alignment issues
On 11/22/19 6:32 PM, Heinrich Schuchardt wrote: > On 11/22/19 1:14 PM, Marek Vasut wrote: >> On 11/22/19 12:58 PM, Heinrich Schuchardt wrote: >>> On 11/22/19 8:47 AM, Simon Goldschmidt wrote: On Fri, Nov 22, 2019 at 7:50 AM Heinrich Schuchardt wrote: > > On 11/22/19 1:25 AM, Marek Vasut wrote: >> On 11/21/19 10:15 PM, Simon Goldschmidt wrote: >>> Since upgrading to gcc9, warnings are issued: >>> "taking address of packed member of ‘...’ may result in an unaligned >>> pointer value" >>> >>> Fix this by converting two functions to use unaligned access since >>> packed >>> structures may be on an unaligned address, depending on USB >>> hardware. >>> >>> Signed-off-by: Simon Goldschmidt >> >> Applied both, thanks. >> > > With these two patches applied to origin/master GCC 9.2.1 does not > produce warnings anymore but for tbs2910_defconfig: > > u-boot.imx exceeds file size limit: > limit: 0x5fc00 bytes > actual: 0x60c00 bytes > excess: 0x1000 bytes > make: *** [Makefile:1159: u-boot.imx] Error 1 > make: *** Deleting file 'u-boot.imx' > > So irrespective of my patches for the USB keyboard we need to address > the size limit on TBS2910. Is that due to my cleanup patches? Can you compare the size by compiling without them? That should work if you leave away the -Werror switch. Regards, Simon >>> >>> GCC 9.2.1 without your patches but with -Wno-address-of-packed-member: >>> >>> u-boot.imx exceeds file size limit: >>> limit: 0x5fc00 bytes >>> actual: 0x60c00 bytes >>> excess: 0x1000 bytes >> >> I see, so you have additional options added to the build which trigger >> the size issue. It would be nice to mention that up front. Do you use >> any other extra options ? >> > > Dear Marek, Hi, > Simon asked me to determine if origin/master exceeds the u-boot.imx size > limit when compiled without his patches. The only way to do so is to > suppress the build warnings. > > -Wno-address-of-packed-member is the only option I added to > origin/master. This option suppresses the build error that we get > without Simon's patches. But you somehow got this -Werror into the build too, right ? > The only other difference between Gitlab CI and my setup is that I use > GCC 9.2.1 (arm-linux-gnueabihf-gcc on Debian Bullseye). That's what I use too. > These are the sizes of u-boot.bin: > > 390080 bytes with Simon's patches > 390080 bytes with Simon's patches + -Wno-address-of-packed-member > 390064 bytes origin/master + -Wno-address-of-packed-member > 386248 bytes with Simon's patches + CONFIG_REGEX=n > 390024 bytes with Simon patches + > "usb: kbd: simplify coding for arrow keys" > 390440 bytes with Simon patches + all my USB keyboard patches > > So I will add a CONFIG option to my "usb: kbd: implement special keys" > patch to avoid the code increase. There might be another option. How about improving the encoding of these escape sequences? There seem to be a lot of duplication, e.g. the leading '\e' is in all of them. So is the '[' . Maybe deduplicating those could help ? I did a quick try by putting all the sequences into a table, then removed the \e and sent it explicitly with usb_kbd_put_queue(), and got ~100 bytes saved. And then each of those strings has trailing '\0', which I don't think is needed either, so that might be another few bytes saved. $ arm-linux-gnueabi-readelf -s u-boot | sort -nk 3 | grep usb_kbd can help tracking down these bloat hotspots. > With CONFIG_REGEX=n the image fits into the current board limit in all > cases. > > Soeren could you, please, evaluate if this configuration works with your > board. It should only be relevant if multiple network interfaces are > supported by U-Boot. CONFIG_REGEX is used by setexpr to handle regexes on U-Boot command line. Hence, removing CONFIG_REGEX would degrade the board functionality and that is what I don't want to see. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] usb: composite: fix possible alignment issues
On Fri, Nov 22, 2019 at 06:32:13PM +0100, Heinrich Schuchardt wrote: > On 11/22/19 1:14 PM, Marek Vasut wrote: > > On 11/22/19 12:58 PM, Heinrich Schuchardt wrote: > > > On 11/22/19 8:47 AM, Simon Goldschmidt wrote: > > > > On Fri, Nov 22, 2019 at 7:50 AM Heinrich Schuchardt > > > > wrote: > > > > > > > > > > On 11/22/19 1:25 AM, Marek Vasut wrote: > > > > > > On 11/21/19 10:15 PM, Simon Goldschmidt wrote: > > > > > > > Since upgrading to gcc9, warnings are issued: > > > > > > > "taking address of packed member of ‘...’ may result in an > > > > > > > unaligned > > > > > > > pointer value" > > > > > > > > > > > > > > Fix this by converting two functions to use unaligned access since > > > > > > > packed > > > > > > > structures may be on an unaligned address, depending on USB > > > > > > > hardware. > > > > > > > > > > > > > > Signed-off-by: Simon Goldschmidt > > > > > > > > > > > > Applied both, thanks. > > > > > > > > > > > > > > > > With these two patches applied to origin/master GCC 9.2.1 does not > > > > > produce warnings anymore but for tbs2910_defconfig: > > > > > > > > > > u-boot.imx exceeds file size limit: > > > > > limit: 0x5fc00 bytes > > > > > actual: 0x60c00 bytes > > > > > excess: 0x1000 bytes > > > > > make: *** [Makefile:1159: u-boot.imx] Error 1 > > > > > make: *** Deleting file 'u-boot.imx' > > > > > > > > > > So irrespective of my patches for the USB keyboard we need to address > > > > > the size limit on TBS2910. > > > > > > > > Is that due to my cleanup patches? Can you compare the size by compiling > > > > without them? That should work if you leave away the -Werror switch. > > > > > > > > Regards, > > > > Simon > > > > > > GCC 9.2.1 without your patches but with -Wno-address-of-packed-member: > > > > > > u-boot.imx exceeds file size limit: > > > limit: 0x5fc00 bytes > > > actual: 0x60c00 bytes > > > excess: 0x1000 bytes > > > > I see, so you have additional options added to the build which trigger > > the size issue. It would be nice to mention that up front. Do you use > > any other extra options ? > > > > Dear Marek, > > Simon asked me to determine if origin/master exceeds the u-boot.imx size > limit when compiled without his patches. The only way to do so is to > suppress the build warnings. > > -Wno-address-of-packed-member is the only option I added to > origin/master. This option suppresses the build error that we get > without Simon's patches. For the record, with gcc 7.2, these types of fixes result in: u-boot: add: 0/0, grow: 2/0 bytes: 36/0 (36) function old new delta collect_langs 76 100 +24 composite_setup 24402452 +12 spl-u-boot-spl: add: 0/0, grow: 2/0 bytes: 36/0 (36) function old new delta collect_langs 76 100 +24 composite_setup 24402452 +12 -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] drivers: gpio: Add common Broadcom iproc gpio driver
From: Sheetal Tigadoli
Add common iproc gpio driver for Broadcom's iProc based SoCs
Signed-off-by: Sheetal Tigadoli
Signed-off-by: Vladimir Olovyannikov
---
drivers/gpio/Kconfig | 10 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/iproc_gpio.c | 258 ++
3 files changed, 269 insertions(+)
create mode 100644 drivers/gpio/iproc_gpio.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index c1ad5d64a3..5f289844a8 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -102,6 +102,16 @@ config HSDK_CREG_GPIO
help
This driver supports CREG GPIOs on Synopsys HSDK SOC.
+config IPROC_GPIO
+ bool "Broadcom iProc GPIO driver(without pinconf)"
+ default n
+ help
+ The Broadcom iProc based SoCs- Cygnus, NS2, NSP and Stingray, use
+ same GPIO Controller IP hence this driver could be used for all.
+
+ The Broadcom iProc based SoCs have multiple GPIO controllers and only
+ the always-ON GPIO controller (CRMU/AON) is supported by this driver.
+
config LPC32XX_GPIO
bool "LPC32XX GPIO driver"
depends on DM
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index ccc49e2eb0..c6f8c87584 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_ATMEL_PIO4) += atmel_pio4.o
obj-$(CONFIG_BCM6345_GPIO) += bcm6345_gpio.o
obj-$(CONFIG_INTEL_ICH6_GPIO) += intel_ich6_gpio.o
obj-$(CONFIG_INTEL_BROADWELL_GPIO) += intel_broadwell_gpio.o
+obj-$(CONFIG_IPROC_GPIO) += iproc_gpio.o
obj-$(CONFIG_KIRKWOOD_GPIO)+= kw_gpio.o
obj-$(CONFIG_KONA_GPIO)+= kona_gpio.o
obj-$(CONFIG_MARVELL_GPIO) += mvgpio.o
diff --git a/drivers/gpio/iproc_gpio.c b/drivers/gpio/iproc_gpio.c
new file mode 100644
index 00..ca6287d7f5
--- /dev/null
+++ b/drivers/gpio/iproc_gpio.c
@@ -0,0 +1,258 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Broadcom
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * There are five GPIO bank register. Each bank can configure max of 32 gpios.
+ * BANK0 - gpios 0 to 31
+ * BANK1 - gpios 32 to 63
+ * BANK2 - gpios 64 to 95
+ * BANK3 - gpios 96 to 127
+ * BANK4 - gpios 128 to 150
+ *
+ * Offset difference between consecutive bank register is 0x200
+ */
+#define IPROC_GPIO_PER_BANK 32
+#define IPROC_GPIO_SHIFT(n) ((n) % IPROC_GPIO_PER_BANK)
+#define IPROC_GPIO_BANK_OFFSET(n) (0x200 * ((n) / IPROC_GPIO_PER_BANK))
+#define IPROC_GPIO_REG(pin, reg)(IPROC_GPIO_BANK_OFFSET(pin) + (reg))
+
+#define IPROC_GPIO_DATA_IN_OFFSET 0x00
+#define IPROC_GPIO_DATA_OUT_OFFSET 0x04
+#define IPROC_GPIO_OUT_EN_OFFSET0x08
+
+struct iproc_gpio_pctrl_map {
+ u32 gpio_pin;
+ u32 pctrl_pin;
+ u32 npins;
+ struct list_head node;
+};
+
+struct iproc_gpio_platdata {
+ struct udevice *pinctrl_dev;
+ struct list_head gpiomap;
+ /* register base for this bank */
+ void __iomem *base;
+ char *name;
+ u32 ngpios;
+};
+
+/**
+ * iproc_gpio_set_bit - set or clear one bit (corresponding to the GPIO pin)
+ * in a iproc GPIO register
+ *
+ * @iproc_gpio: Iproc GPIO device
+ * @reg: register offset
+ * @gpio: GPIO pin
+ * @set: set or clear
+ */
+static inline void iproc_gpio_set_bit(struct iproc_gpio_platdata *plat,
+ u32 reg,
+ u32 gpio, bool set)
+{
+ u32 offset = IPROC_GPIO_REG(gpio, reg);
+ u32 shift = IPROC_GPIO_SHIFT(gpio);
+ u32 val;
+
+ val = readl(plat->base + offset);
+ if (set)
+ val |= BIT(shift);
+ else
+ val &= ~BIT(shift);
+ writel(val, plat->base + offset);
+}
+
+static inline bool iproc_gpio_get_bit(struct iproc_gpio_platdata *plat,
+ u32 reg,
+ u32 gpio)
+{
+ u32 offset = IPROC_GPIO_REG(gpio, reg);
+ u32 shift = IPROC_GPIO_SHIFT(gpio);
+
+ return !!(readl(plat->base + offset) & BIT(shift));
+}
+
+static u32 iproc_get_pctrl_from_gpio(struct iproc_gpio_platdata *plat, u32
gpio)
+{
+ struct iproc_gpio_pctrl_map *range = NULL;
+ struct list_head *pos, *tmp;
+ u32 ret = 0;
+
+ list_for_each_safe(pos, tmp, >gpiomap) {
+ range = list_entry(pos, struct iproc_gpio_pctrl_map, node);
+ if (gpio == range->gpio_pin ||
+ (gpio < (range->gpio_pin + range->npins))) {
+ ret = (range->pctrl_pin + (gpio - range->gpio_pin));
+ break;
+ }
+ }
+
+ return ret;
+}
+
+static int iproc_get_gpio_pctrl_mapping(struct udevice *dev)
+{
+ struct iproc_gpio_platdata *plat = dev_get_platdata(dev);
+ struct iproc_gpio_pctrl_map *range = NULL;
+ struct fdtdec_phandle_args args;
+ int node = dev_of_offset(dev);
+
Re: [U-Boot] [PATCH v2 1/2] usb: composite: fix possible alignment issues
On 11/22/19 1:14 PM, Marek Vasut wrote: On 11/22/19 12:58 PM, Heinrich Schuchardt wrote: On 11/22/19 8:47 AM, Simon Goldschmidt wrote: On Fri, Nov 22, 2019 at 7:50 AM Heinrich Schuchardt wrote: On 11/22/19 1:25 AM, Marek Vasut wrote: On 11/21/19 10:15 PM, Simon Goldschmidt wrote: Since upgrading to gcc9, warnings are issued: "taking address of packed member of ‘...’ may result in an unaligned pointer value" Fix this by converting two functions to use unaligned access since packed structures may be on an unaligned address, depending on USB hardware. Signed-off-by: Simon Goldschmidt Applied both, thanks. With these two patches applied to origin/master GCC 9.2.1 does not produce warnings anymore but for tbs2910_defconfig: u-boot.imx exceeds file size limit: limit: 0x5fc00 bytes actual: 0x60c00 bytes excess: 0x1000 bytes make: *** [Makefile:1159: u-boot.imx] Error 1 make: *** Deleting file 'u-boot.imx' So irrespective of my patches for the USB keyboard we need to address the size limit on TBS2910. Is that due to my cleanup patches? Can you compare the size by compiling without them? That should work if you leave away the -Werror switch. Regards, Simon GCC 9.2.1 without your patches but with -Wno-address-of-packed-member: u-boot.imx exceeds file size limit: limit: 0x5fc00 bytes actual: 0x60c00 bytes excess: 0x1000 bytes I see, so you have additional options added to the build which trigger the size issue. It would be nice to mention that up front. Do you use any other extra options ? Dear Marek, Simon asked me to determine if origin/master exceeds the u-boot.imx size limit when compiled without his patches. The only way to do so is to suppress the build warnings. -Wno-address-of-packed-member is the only option I added to origin/master. This option suppresses the build error that we get without Simon's patches. The only other difference between Gitlab CI and my setup is that I use GCC 9.2.1 (arm-linux-gnueabihf-gcc on Debian Bullseye). These are the sizes of u-boot.bin: 390080 bytes with Simon's patches 390080 bytes with Simon's patches + -Wno-address-of-packed-member 390064 bytes origin/master + -Wno-address-of-packed-member 386248 bytes with Simon's patches + CONFIG_REGEX=n 390024 bytes with Simon patches + "usb: kbd: simplify coding for arrow keys" 390440 bytes with Simon patches + all my USB keyboard patches So I will add a CONFIG option to my "usb: kbd: implement special keys" patch to avoid the code increase. With CONFIG_REGEX=n the image fits into the current board limit in all cases. Soeren could you, please, evaluate if this configuration works with your board. It should only be relevant if multiple network interfaces are supported by U-Boot. Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] board: ti: am43xx: remove net platform code
The TI AM43xx platform has DM_ETH and OF_CONTROL enabled,
so remove networking platform code.
Signed-off-by: Grygorii Strashko
---
board/ti/am43xx/board.c | 106 +---
1 file changed, 1 insertion(+), 105 deletions(-)
diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index f5ecf871bc..7ec9c38e6a 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -8,6 +8,7 @@
*/
#include
+#include
#include
#include
#include
@@ -26,8 +27,6 @@
#include
#include
#include
-#include
-#include
#include
#include
#include
@@ -851,109 +850,6 @@ int board_usb_cleanup(int index, enum usb_init_type init)
#endif /* defined(CONFIG_USB_DWC3) || defined(CONFIG_USB_XHCI_OMAP) */
#endif /* !CONFIG_IS_ENABLED(DM_USB_GADGET) */
-#ifdef CONFIG_DRIVER_TI_CPSW
-
-static void cpsw_control(int enabled)
-{
- /* Additional controls can be added here */
- return;
-}
-
-static struct cpsw_slave_data cpsw_slaves[] = {
- {
- .slave_reg_ofs = 0x208,
- .sliver_reg_ofs = 0xd80,
- .phy_addr = 16,
- },
- {
- .slave_reg_ofs = 0x308,
- .sliver_reg_ofs = 0xdc0,
- .phy_addr = 1,
- },
-};
-
-static struct cpsw_platform_data cpsw_data = {
- .mdio_base = CPSW_MDIO_BASE,
- .cpsw_base = CPSW_BASE,
- .mdio_div = 0xff,
- .channels = 8,
- .cpdma_reg_ofs = 0x800,
- .slaves = 1,
- .slave_data = cpsw_slaves,
- .ale_reg_ofs= 0xd00,
- .ale_entries= 1024,
- .host_port_reg_ofs = 0x108,
- .hw_stats_reg_ofs = 0x900,
- .bd_ram_ofs = 0x2000,
- .mac_control= (1 << 5),
- .control= cpsw_control,
- .host_port_num = 0,
- .version= CPSW_CTRL_VERSION_2,
-};
-
-int board_eth_init(bd_t *bis)
-{
- int rv;
- uint8_t mac_addr[6];
- uint32_t mac_hi, mac_lo;
-
- /* try reading mac address from efuse */
- mac_lo = readl(>macid0l);
- mac_hi = readl(>macid0h);
- mac_addr[0] = mac_hi & 0xFF;
- mac_addr[1] = (mac_hi & 0xFF00) >> 8;
- mac_addr[2] = (mac_hi & 0xFF) >> 16;
- mac_addr[3] = (mac_hi & 0xFF00) >> 24;
- mac_addr[4] = mac_lo & 0xFF;
- mac_addr[5] = (mac_lo & 0xFF00) >> 8;
-
- if (!env_get("ethaddr")) {
- puts(" not set. Validating first E-fuse MAC\n");
- if (is_valid_ethaddr(mac_addr))
- eth_env_set_enetaddr("ethaddr", mac_addr);
- }
-
- mac_lo = readl(>macid1l);
- mac_hi = readl(>macid1h);
- mac_addr[0] = mac_hi & 0xFF;
- mac_addr[1] = (mac_hi & 0xFF00) >> 8;
- mac_addr[2] = (mac_hi & 0xFF) >> 16;
- mac_addr[3] = (mac_hi & 0xFF00) >> 24;
- mac_addr[4] = mac_lo & 0xFF;
- mac_addr[5] = (mac_lo & 0xFF00) >> 8;
-
- if (!env_get("eth1addr")) {
- if (is_valid_ethaddr(mac_addr))
- eth_env_set_enetaddr("eth1addr", mac_addr);
- }
-
- if (board_is_eposevm()) {
- writel(RMII_MODE_ENABLE | RMII_CHIPCKL_ENABLE, >miisel);
- cpsw_slaves[0].phy_if = PHY_INTERFACE_MODE_RMII;
- cpsw_slaves[0].phy_addr = 16;
- } else if (board_is_sk()) {
- writel(RGMII_MODE_ENABLE, >miisel);
- cpsw_slaves[0].phy_if = PHY_INTERFACE_MODE_RGMII;
- cpsw_slaves[0].phy_addr = 4;
- cpsw_slaves[1].phy_addr = 5;
- } else if (board_is_idk()) {
- writel(RGMII_MODE_ENABLE, >miisel);
- cpsw_slaves[0].phy_if = PHY_INTERFACE_MODE_RGMII;
- cpsw_slaves[0].phy_addr = 0;
- } else {
- writel(RGMII_MODE_ENABLE, >miisel);
- cpsw_slaves[0].phy_if = PHY_INTERFACE_MODE_RGMII;
- cpsw_slaves[0].phy_addr = 0;
- }
-
- rv = cpsw_register(_data);
- if (rv < 0)
- printf("Error %d registering CPSW switch\n", rv);
-
- return rv;
-}
-#endif
-
#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
int ft_board_setup(void *blob, bd_t *bd)
{
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] board: ti: dra7-evm: remove net platform code
The DRA7 has DM_ETH and OF_CONTROL enabled, so remove networking platform
code.
Signed-off-by: Grygorii Strashko
---
board/ti/dra7xx/evm.c | 106 +-
1 file changed, 1 insertion(+), 105 deletions(-)
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 74d04bb1e3..b1e1e5403c 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -11,6 +11,7 @@
*/
#include
#include
+#include
#include
#include
#include
@@ -29,7 +30,6 @@
#include
#include
#include
-#include
#include "mux_data.h"
#include "../common/board_detect.h"
@@ -45,10 +45,6 @@
#define board_ti_get_emif_size() board_ti_get_emif1_size() + \
board_ti_get_emif2_size()
-#ifdef CONFIG_DRIVER_TI_CPSW
-#include
-#endif
-
DECLARE_GLOBAL_DATA_PTR;
/* GPIO 7_11 */
@@ -989,106 +985,6 @@ int spl_start_uboot(void)
}
#endif
-#ifdef CONFIG_DRIVER_TI_CPSW
-extern u32 *const omap_si_rev;
-
-static void cpsw_control(int enabled)
-{
- /* VTP can be added here */
-
- return;
-}
-
-static struct cpsw_slave_data cpsw_slaves[] = {
- {
- .slave_reg_ofs = 0x208,
- .sliver_reg_ofs = 0xd80,
- .phy_addr = 2,
- },
- {
- .slave_reg_ofs = 0x308,
- .sliver_reg_ofs = 0xdc0,
- .phy_addr = 3,
- },
-};
-
-static struct cpsw_platform_data cpsw_data = {
- .mdio_base = CPSW_MDIO_BASE,
- .cpsw_base = CPSW_BASE,
- .mdio_div = 0xff,
- .channels = 8,
- .cpdma_reg_ofs = 0x800,
- .slaves = 2,
- .slave_data = cpsw_slaves,
- .ale_reg_ofs= 0xd00,
- .ale_entries= 1024,
- .host_port_reg_ofs = 0x108,
- .hw_stats_reg_ofs = 0x900,
- .bd_ram_ofs = 0x2000,
- .mac_control= (1 << 5),
- .control= cpsw_control,
- .host_port_num = 0,
- .version= CPSW_CTRL_VERSION_2,
-};
-
-int board_eth_init(bd_t *bis)
-{
- int ret;
- uint8_t mac_addr[6];
- uint32_t mac_hi, mac_lo;
- uint32_t ctrl_val;
-
- /* try reading mac address from efuse */
- mac_lo = readl((*ctrl)->control_core_mac_id_0_lo);
- mac_hi = readl((*ctrl)->control_core_mac_id_0_hi);
- mac_addr[0] = (mac_hi & 0xFF) >> 16;
- mac_addr[1] = (mac_hi & 0xFF00) >> 8;
- mac_addr[2] = mac_hi & 0xFF;
- mac_addr[3] = (mac_lo & 0xFF) >> 16;
- mac_addr[4] = (mac_lo & 0xFF00) >> 8;
- mac_addr[5] = mac_lo & 0xFF;
-
- if (!env_get("ethaddr")) {
- printf(" not set. Validating first E-fuse MAC\n");
-
- if (is_valid_ethaddr(mac_addr))
- eth_env_set_enetaddr("ethaddr", mac_addr);
- }
-
- mac_lo = readl((*ctrl)->control_core_mac_id_1_lo);
- mac_hi = readl((*ctrl)->control_core_mac_id_1_hi);
- mac_addr[0] = (mac_hi & 0xFF) >> 16;
- mac_addr[1] = (mac_hi & 0xFF00) >> 8;
- mac_addr[2] = mac_hi & 0xFF;
- mac_addr[3] = (mac_lo & 0xFF) >> 16;
- mac_addr[4] = (mac_lo & 0xFF00) >> 8;
- mac_addr[5] = mac_lo & 0xFF;
-
- if (!env_get("eth1addr")) {
- if (is_valid_ethaddr(mac_addr))
- eth_env_set_enetaddr("eth1addr", mac_addr);
- }
-
- ctrl_val = readl((*ctrl)->control_core_control_io1) & (~0x33);
- ctrl_val |= 0x22;
- writel(ctrl_val, (*ctrl)->control_core_control_io1);
-
- if (*omap_si_rev == DRA722_ES1_0)
- cpsw_data.active_slave = 1;
-
- if (board_is_dra72x_revc_or_later()) {
- cpsw_slaves[0].phy_if = PHY_INTERFACE_MODE_RGMII_ID;
- cpsw_slaves[1].phy_if = PHY_INTERFACE_MODE_RGMII_ID;
- }
-
- ret = cpsw_register(_data);
- if (ret < 0)
- printf("Error %d registering CPSW switch\n", ret);
-
- return ret;
-}
-#endif
-
#ifdef CONFIG_BOARD_EARLY_INIT_F
/* VTT regulator enable */
static inline void vtt_regulator_enable(void)
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Maximum size of u-boot.imx for TBS2910 board
On Fri, Nov 22, 2019 at 04:58:29AM +0100, Marek Vasut wrote: > On 11/22/19 4:41 AM, Tom Rini wrote: > [...] > > I believe > > the specific changes in question that once again push this board > > over > > fall in to that grey area. Whatever size-trimming the board > > maintainer > > is fine with next is fine with me, but needs to get ack'd by > > someone. > > Or, the other option is, make these new extra features configurable > and > disable them on this board. And so there should be no size problem. > >>> > >>> But that direction leads to saying every slight bit of functionality > >>> requires a new Kconfig entry. Some levels of bugfixes as well. > >> > >> The other option is, we will sink in bloat and suffer endless size > >> problems. > > > > Yes, it is a hard balancing act. Stepping back, perhaps a "minimal" or > > "complete" choice for USB HID devices would make sense and allow us > > further areas to reduce size, on the minimal portion. > > Or maybe there is a way to help compiler optimize that USB key code > handling better. > >>> > >>> Perhaps. But my point is that every little functional change or > >>> enhancement does not need a Kconfig option. > >> > >> Except this leads to slow and steady accumulation of bloat, and as we > >> already see for quite a while, this is problematic for more and more > >> boards. > > > > And "bloat" and "features" are interchangable terms. > > Nope, bloat is unhelpful growth of size, features are actually > helpful/useful. > > > I really am trying > > to be more responsive than ever to size growth in common, rather than > > board specific areas. And I agree, some investigation in to ways that > > might reduce the size of binary support for USB HID devices is good. > > So we agree that's what this series should fix ? > > > Figuring out if we can make this series: > > http://patchwork.ozlabs.org/project/uboot/list/?series=135448 > > not also increase the overall size, or increase it less, is good. > > Hiding the content of 2/5 behind a CONFIG option in turn brings us back > > to "the code is too messy and full of #ifdef" lines. > > Which might be somewhat better than if the code is sprinkled with tiny > chunks of random pieces of code which are never used, but in total add > up to a lot of unused code in the binary. If, with your USB custodian hat on, your answer to Heinrich is that his changes expose a more fundamental problem with the code that needs addressing then no, I'm not overriding your objection. -- 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 4/4] sunxi: board: fixup the BT address for Orange Pi 3
Hey Ondřej,
On 22/11/2019 15:23, Ondřej Jirman wrote:
Hello,
On Fri, Nov 22, 2019 at 02:04:00PM +0100, Andre Heider wrote:
The BCM4345C5 of the Orange Pi 3 ships with the controller default
address. Fix it up so it can function properly.
This is very nice!
The used address is "ethaddr" with the LSB flipped.
Signed-off-by: Andre Heider
---
NOTE:
"local-bd-address" is a universal property, the kernel patch for
btbcm to use that is in bluetooth-next.
board/sunxi/board.c | 28
1 file changed, 28 insertions(+)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index bb35d6b66e..2897bf45e1 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -856,6 +856,32 @@ int misc_init_r(void)
return 0;
}
+static void fixup_bd_address(void *blob)
+{
+#if defined(CONFIG_MACH_SUN50I_H6)
This sounds useful for other sunxi boards too (many ship with broadcom
BT chips with unassigned addresses), can we have a generic config for
the fixup?
Something like CONFIG_SUNXI_BTADDR_FIXUP that can be enabled in defconfig
files, or pre-selected/implied by CONFIG_MACH_SUN* that may want it on
by default?
sure, we can do that, but note there's "brcm,bcm4345c5" used below,
hence me limiting it to opi3 for now.
So we either need to have something like
CONFIG_SUNXI_BTADDR_FIXUP="brcm,bcm4345c5"
or a dts "bluetooth" alias we can refer to.
I'd go for the former, would that be an acceptable solution?
Thanks,
Andre
+ /* Some devices ship with the controller default address.
+* Set a valid address through the device tree.
+*/
+ uchar mac[ETH_ALEN], bdaddr[ETH_ALEN];
+ int i;
+
+ if (!of_machine_is_compatible("xunlong,orangepi-3"))
+ return;
You don't need to limit this to opi3 only.
thank you and regards,
o.
+
+ if (!eth_env_get_enetaddr("ethaddr", mac))
+ return;
+
+ /* Addresses need to be in the binary format of the corresponding stack
*/
+ for (i = 0; i < ETH_ALEN; ++i)
+ bdaddr[i] = mac[ETH_ALEN - i - 1];
+
+ bdaddr[0] ^= 1;
+
+ do_fixup_by_compat(blob, "brcm,bcm4345c5",
+ "local-bd-address", bdaddr, ETH_ALEN, 1);
+#endif
+}
+
int ft_board_setup(void *blob, bd_t *bd)
{
int __maybe_unused r;
@@ -866,6 +892,8 @@ int ft_board_setup(void *blob, bd_t *bd)
*/
setup_environment(blob);
+ fixup_bd_address(blob);
+
#ifdef CONFIG_VIDEO_DT_SIMPLEFB
r = sunxi_simplefb_setup(blob);
if (r)
--
2.24.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] poweroff: add poweroff for mt6323 pmic
this adds poweroff to bananapi r2 / mt7623 / mt6323 pmic
Signed-off-by: Frank Wunderlich
---
drivers/power/Kconfig | 7 +++
drivers/power/Makefile | 1 +
drivers/power/mt6323.c | 37 +
3 files changed, 45 insertions(+)
create mode 100644 drivers/power/mt6323.c
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 9495dca33b..0ac906e86d 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -364,4 +364,11 @@ config TWL4030_POWER
The TWL4030 in a combination audio CODEC/power management with
GPIO and it is commonly used with the OMAP3 family of processors
+config POWER_MT6323
+ bool "Poweroff driver for mediatek mt6323"
+ select CMD_POWEROFF
+ help
+ This adds poweroff driver for mt6323
+ this pmic is used on mt7623 / Bananapi R2
+
endmenu
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index dd5bc0dc44..2dcc7bb99d 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -20,3 +20,4 @@ obj-$(CONFIG_DIALOG_POWER) += power_dialog.o
obj-$(CONFIG_POWER_FSL) += power_fsl.o
obj-$(CONFIG_POWER_I2C) += power_i2c.o
obj-$(CONFIG_POWER_SPI) += power_spi.o
+obj-$(CONFIG_POWER_MT6323) += mt6323.o
diff --git a/drivers/power/mt6323.c b/drivers/power/mt6323.c
new file mode 100644
index 00..566be5f39e
--- /dev/null
+++ b/drivers/power/mt6323.c
@@ -0,0 +1,37 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Frank Wunderlich
+ */
+
+#include
+#include
+#include
+
+#define PWRAP_BASE 0x1000d000
+#define PWRAP_WACS2_CMD0x9c
+
+#define PWRAP_CALC(adr, wdata) ((1 << 31) | (((adr) >> 1) << 16) | (wdata))
+
+#define MT6323_PWRC_BASE 0x8000
+#define RTC_BBPU 0x
+#define RTC_BBPU_KEY (0x43 << 8)
+#define RTC_WRTGR 0x003c
+
+int do_poweroff(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ u32 addr, val;
+
+ addr = PWRAP_BASE + PWRAP_WACS2_CMD;
+ val = PWRAP_CALC(MT6323_PWRC_BASE + RTC_BBPU, RTC_BBPU_KEY);
+ writel(val, addr);
+
+ mdelay(10);
+
+ val = PWRAP_CALC(MT6323_PWRC_BASE + RTC_WRTGR, 1);
+ writel(val, addr);
+
+ // wait some time and then print error
+ mdelay(1);
+ printf("Failed to power off!!!\n");
+ return 1;
+}
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] sunxi: board: fixup the BT address for Orange Pi 3
Hello,
On Fri, Nov 22, 2019 at 02:04:00PM +0100, Andre Heider wrote:
> The BCM4345C5 of the Orange Pi 3 ships with the controller default
> address. Fix it up so it can function properly.
This is very nice!
> The used address is "ethaddr" with the LSB flipped.
>
> Signed-off-by: Andre Heider
> ---
>
> NOTE:
> "local-bd-address" is a universal property, the kernel patch for
> btbcm to use that is in bluetooth-next.
>
> board/sunxi/board.c | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index bb35d6b66e..2897bf45e1 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -856,6 +856,32 @@ int misc_init_r(void)
> return 0;
> }
>
> +static void fixup_bd_address(void *blob)
> +{
> +#if defined(CONFIG_MACH_SUN50I_H6)
This sounds useful for other sunxi boards too (many ship with broadcom
BT chips with unassigned addresses), can we have a generic config for
the fixup?
Something like CONFIG_SUNXI_BTADDR_FIXUP that can be enabled in defconfig
files, or pre-selected/implied by CONFIG_MACH_SUN* that may want it on
by default?
> + /* Some devices ship with the controller default address.
> + * Set a valid address through the device tree.
> + */
> + uchar mac[ETH_ALEN], bdaddr[ETH_ALEN];
> + int i;
> +
> + if (!of_machine_is_compatible("xunlong,orangepi-3"))
> + return;
You don't need to limit this to opi3 only.
thank you and regards,
o.
> +
> + if (!eth_env_get_enetaddr("ethaddr", mac))
> + return;
> +
> + /* Addresses need to be in the binary format of the corresponding stack
> */
> + for (i = 0; i < ETH_ALEN; ++i)
> + bdaddr[i] = mac[ETH_ALEN - i - 1];
> +
> + bdaddr[0] ^= 1;
> +
> + do_fixup_by_compat(blob, "brcm,bcm4345c5",
> +"local-bd-address", bdaddr, ETH_ALEN, 1);
> +#endif
> +}
> +
> int ft_board_setup(void *blob, bd_t *bd)
> {
> int __maybe_unused r;
> @@ -866,6 +892,8 @@ int ft_board_setup(void *blob, bd_t *bd)
>*/
> setup_environment(blob);
>
> + fixup_bd_address(blob);
> +
> #ifdef CONFIG_VIDEO_DT_SIMPLEFB
> r = sunxi_simplefb_setup(blob);
> if (r)
> --
> 2.24.0
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Raspberry Pi updates for v2020.01
Hi Matthias, On 20.11.2019 10:10, Matthias Brugger wrote: > Hi Tom, > > On 20/11/2019 02:57, Tom Rini wrote: >> On Tue, Nov 19, 2019 at 05:02:34PM +0100, Matthias Brugger wrote: >> >>> Hi Tom, >>> >>> Please have a look at the below patches. >>> Travis-ci can be found here: >>> https://travis-ci.org/mbgg/u-boot/builds/614078145 >>> >>> Apart from this patches, I planning to send another pull request once the >>> single >>> binary series is ready to be merged. But for now, we should take this >>> patches as >>> it fixes some FAT write errors and the boot banner issue for RPi3 you >>> detected. >>> >>> Regards, >>> Matthias >>> >> NAK, this seems to break FAT in some cases: >> https://protect2.fireeye.com/url?k=2537010b-78fbcdae-25368a44-0cc47a30d446-1c9023d2fe8030d3=https://gitlab.denx.de/u-boot/u-boot/-/jobs/31682 >> https://protect2.fireeye.com/url?k=320832ee-6fc4fe4b-3209b9a1-0cc47a30d446-2f8fe5692eb397d4=https://gitlab.denx.de/u-boot/u-boot/-/jobs/31683 >> (and similar in Azure and Travis). >> > It seems that it does not break in travis, but it also seems that the CI > diverged between travis and gitlab: > https://travis-ci.org/mbgg/u-boot/jobs/614078209 > https://travis-ci.org/mbgg/u-boot/jobs/614078210 > > @Tom are you aware of that? > > @Marek can you have a look into the FAT errors please? Yes, I will take care of them. It looks that my fixes revealed bugs in other parts of fat code... Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/4] sunxi: board: Use eth_env_set_enetaddr_by_index()
That helper takes care of assembling the correct name and doesn't allow
overwriting existing env vars, so drop the checks here.
Signed-off-by: Andre Heider
---
board/sunxi/board.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index e3b2d13892..bb35d6b66e 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -807,14 +807,6 @@ static void setup_environment(const void *fdt)
if (!fdt_get_alias(fdt, ethaddr))
continue;
- if (i == 0)
- strcpy(ethaddr, "ethaddr");
- else
- sprintf(ethaddr, "eth%daddr", i);
-
- if (env_get(ethaddr))
- continue;
-
/* Non OUI / registered MAC address */
mac_addr[0] = (i << 4) | 0x02;
mac_addr[1] = (sid[0] >> 0) & 0xff;
@@ -823,7 +815,7 @@ static void setup_environment(const void *fdt)
mac_addr[4] = (sid[3] >> 8) & 0xff;
mac_addr[5] = (sid[3] >> 0) & 0xff;
- eth_env_set_enetaddr(ethaddr, mac_addr);
+ eth_env_set_enetaddr_by_index("eth", i, mac_addr);
}
if (!env_get("serial#")) {
--
2.24.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/4] arm64: dts: sun50i: Add support for Orange Pi 3
The dts is taken from kernel tag v5.4-rc8.
Signed-off-by: Andre Heider
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/sun50i-h6-orangepi-3.dts | 287 ++
board/sunxi/MAINTAINERS | 5 +
configs/orangepi_3_defconfig | 17 ++
4 files changed, 310 insertions(+)
create mode 100644 arch/arm/dts/sun50i-h6-orangepi-3.dts
create mode 100644 configs/orangepi_3_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index d8846df1bd..5040d4f50d 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -540,6 +540,7 @@ dtb-$(CONFIG_MACH_SUN50I_H5) += \
sun50i-h5-orangepi-zero-plus2.dtb
dtb-$(CONFIG_MACH_SUN50I_H6) += \
sun50i-h6-beelink-gs1.dtb \
+ sun50i-h6-orangepi-3.dtb \
sun50i-h6-orangepi-lite2.dtb \
sun50i-h6-orangepi-one-plus.dtb \
sun50i-h6-pine-h64.dtb
diff --git a/arch/arm/dts/sun50i-h6-orangepi-3.dts
b/arch/arm/dts/sun50i-h6-orangepi-3.dts
new file mode 100644
index 00..eb379cd402
--- /dev/null
+++ b/arch/arm/dts/sun50i-h6-orangepi-3.dts
@@ -0,0 +1,287 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2019 Ondřej Jirman
+ */
+
+/dts-v1/;
+
+#include "sun50i-h6.dtsi"
+
+#include
+
+/ {
+ model = "OrangePi 3";
+ compatible = "xunlong,orangepi-3", "allwinner,sun50i-h6";
+
+ aliases {
+ serial0 =
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ connector {
+ compatible = "hdmi-connector";
+ ddc-en-gpios = < 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <_out_con>;
+ };
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ power {
+ label = "orangepi:red:power";
+ gpios = <_pio 0 4 GPIO_ACTIVE_HIGH>; /* PL4 */
+ default-state = "on";
+ };
+
+ status {
+ label = "orangepi:green:status";
+ gpios = <_pio 0 7 GPIO_ACTIVE_HIGH>; /* PL7 */
+ };
+ };
+
+ reg_vcc5v: vcc5v {
+ /* board wide 5V supply directly from the DC jack */
+ compatible = "regulator-fixed";
+ regulator-name = "vcc-5v";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ };
+
+ reg_vcc33_wifi: vcc33-wifi {
+ /* Always on 3.3V regulator for WiFi and BT */
+ compatible = "regulator-fixed";
+ regulator-name = "vcc33-wifi";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ vin-supply = <_vcc5v>;
+ };
+
+ reg_vcc_wifi_io: vcc-wifi-io {
+ /* Always on 1.8V/300mA regulator for WiFi and BT IO */
+ compatible = "regulator-fixed";
+ regulator-name = "vcc-wifi-io";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ vin-supply = <_vcc33_wifi>;
+ };
+
+ wifi_pwrseq: wifi-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = < 1>;
+ clock-names = "ext_clock";
+ reset-gpios = <_pio 1 3 GPIO_ACTIVE_LOW>; /* PM3 */
+ post-power-on-delay-ms = <200>;
+ };
+};
+
+ {
+ cpu-supply = <_dcdca>;
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <_con_in>;
+ };
+};
+
+ {
+ vmmc-supply = <_cldo1>;
+ cd-gpios = < 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
+ bus-width = <4>;
+ status = "okay";
+};
+
+ {
+ vmmc-supply = <_vcc33_wifi>;
+ vqmmc-supply = <_vcc_wifi_io>;
+ mmc-pwrseq = <_pwrseq>;
+ bus-width = <4>;
+ non-removable;
+ status = "okay";
+
+ brcm: sdio-wifi@1 {
+ reg = <1>;
+ compatible = "brcm,bcm4329-fmac";
+ interrupt-parent = <_pio>;
+ interrupts = <1 0 IRQ_TYPE_LEVEL_LOW>; /* PM0 */
+ interrupt-names = "host-wake";
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ vcc-pc-supply = <_bldo2>;
+ vcc-pd-supply = <_cldo1>;
+ vcc-pg-supply = <_vcc_wifi_io>;
+};
+
+_i2c {
+ status = "okay";
+
+ axp805: pmic@36 {
+ compatible = "x-powers,axp805", "x-powers,axp806";
+ reg = <0x36>;
+
[U-Boot] [PATCH 4/4] sunxi: board: fixup the BT address for Orange Pi 3
The BCM4345C5 of the Orange Pi 3 ships with the controller default
address. Fix it up so it can function properly.
The used address is "ethaddr" with the LSB flipped.
Signed-off-by: Andre Heider
---
NOTE:
"local-bd-address" is a universal property, the kernel patch for
btbcm to use that is in bluetooth-next.
board/sunxi/board.c | 28
1 file changed, 28 insertions(+)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index bb35d6b66e..2897bf45e1 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -856,6 +856,32 @@ int misc_init_r(void)
return 0;
}
+static void fixup_bd_address(void *blob)
+{
+#if defined(CONFIG_MACH_SUN50I_H6)
+ /* Some devices ship with the controller default address.
+* Set a valid address through the device tree.
+*/
+ uchar mac[ETH_ALEN], bdaddr[ETH_ALEN];
+ int i;
+
+ if (!of_machine_is_compatible("xunlong,orangepi-3"))
+ return;
+
+ if (!eth_env_get_enetaddr("ethaddr", mac))
+ return;
+
+ /* Addresses need to be in the binary format of the corresponding stack
*/
+ for (i = 0; i < ETH_ALEN; ++i)
+ bdaddr[i] = mac[ETH_ALEN - i - 1];
+
+ bdaddr[0] ^= 1;
+
+ do_fixup_by_compat(blob, "brcm,bcm4345c5",
+ "local-bd-address", bdaddr, ETH_ALEN, 1);
+#endif
+}
+
int ft_board_setup(void *blob, bd_t *bd)
{
int __maybe_unused r;
@@ -866,6 +892,8 @@ int ft_board_setup(void *blob, bd_t *bd)
*/
setup_environment(blob);
+ fixup_bd_address(blob);
+
#ifdef CONFIG_VIDEO_DT_SIMPLEFB
r = sunxi_simplefb_setup(blob);
if (r)
--
2.24.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/4] arm64: dts: sync Allwinner H6 files
Taken from the kernel tag v5.4-rc8.
Drop the /omit-if-no-ref/ keyword as it's not supported by u-boot.
Signed-off-by: Andre Heider
---
arch/arm/dts/sun50i-h6-beelink-gs1.dts | 27 +
arch/arm/dts/sun50i-h6-orangepi.dtsi | 4 +
arch/arm/dts/sun50i-h6-pine-h64.dts| 4 +
arch/arm/dts/sun50i-h6.dtsi| 137 ++---
4 files changed, 155 insertions(+), 17 deletions(-)
diff --git a/arch/arm/dts/sun50i-h6-beelink-gs1.dts
b/arch/arm/dts/sun50i-h6-beelink-gs1.dts
index 0dc33c90dd..1d05d57014 100644
--- a/arch/arm/dts/sun50i-h6-beelink-gs1.dts
+++ b/arch/arm/dts/sun50i-h6-beelink-gs1.dts
@@ -25,6 +25,7 @@
connector {
compatible = "hdmi-connector";
type = "a";
+ ddc-en-gpios = < 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
port {
hdmi_con_in: endpoint {
@@ -51,6 +52,24 @@
regulator-max-microvolt = <500>;
regulator-always-on;
};
+
+ sound-spdif {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "sun50i-h6-spdif";
+
+ simple-audio-card,cpu {
+ sound-dai = <>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <_out>;
+ };
+ };
+
+ spdif_out: spdif-out {
+ #sound-dai-cells = <0>;
+ compatible = "linux,spdif-dit";
+ };
};
{
@@ -232,6 +251,10 @@
};
};
+_ir {
+ status = "okay";
+};
+
_pio {
/*
* PL0 and PL1 are used for PMIC I2C
@@ -243,6 +266,10 @@
vcc-pm-supply = <_aldo1>;
};
+ {
+ status = "okay";
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_ph_pins>;
diff --git a/arch/arm/dts/sun50i-h6-orangepi.dtsi
b/arch/arm/dts/sun50i-h6-orangepi.dtsi
index 62e27948a3..ec9b6a578e 100644
--- a/arch/arm/dts/sun50i-h6-orangepi.dtsi
+++ b/arch/arm/dts/sun50i-h6-orangepi.dtsi
@@ -189,6 +189,10 @@
};
};
+_ir {
+ status = "okay";
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_ph_pins>;
diff --git a/arch/arm/dts/sun50i-h6-pine-h64.dts
b/arch/arm/dts/sun50i-h6-pine-h64.dts
index 1898345183..30102daf83 100644
--- a/arch/arm/dts/sun50i-h6-pine-h64.dts
+++ b/arch/arm/dts/sun50i-h6-pine-h64.dts
@@ -255,6 +255,10 @@
};
};
+_ir {
+ status = "okay";
+};
+
_pio {
vcc-pm-supply = <_aldo1>;
};
diff --git a/arch/arm/dts/sun50i-h6.dtsi b/arch/arm/dts/sun50i-h6.dtsi
index a117f479ae..bdba221a67 100644
--- a/arch/arm/dts/sun50i-h6.dtsi
+++ b/arch/arm/dts/sun50i-h6.dtsi
@@ -56,14 +56,6 @@
status = "disabled";
};
- iosc: internal-osc-clk {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <1600>;
- clock-accuracy = <3>;
- clock-output-names = "iosc";
- };
-
osc24M: osc24M_clk {
#clock-cells = <0>;
compatible = "fixed-clock";
@@ -71,11 +63,11 @@
clock-output-names = "osc24M";
};
- osc32k: osc32k_clk {
+ ext_osc32k: ext_osc32k_clk {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <32768>;
- clock-output-names = "osc32k";
+ clock-output-names = "ext_osc32k";
};
psci {
@@ -197,7 +189,7 @@
ccu: clock@3001000 {
compatible = "allwinner,sun50i-h6-ccu";
reg = <0x03001000 0x1000>;
- clocks = <>, <>, <>;
+ clocks = <>, < 0>, < 2>;
clock-names = "hosc", "losc", "iosc";
#clock-cells = <1>;
#reset-cells = <1>;
@@ -215,7 +207,7 @@
#dma-cells = <1>;
};
- sid: sid@3006000 {
+ sid: efuse@3006000 {
compatible = "allwinner,sun50i-h6-sid";
reg = <0x03006000 0x400>;
};
@@ -225,6 +217,7 @@
"allwinner,sun6i-a31-wdt";
reg = <0x030090a0 0x20>;
interrupts = ;
+ clocks = <>;
/* Broken on some H6 boards */
status = "disabled";
};
@@ -236,7 +229,7 @@
,
,
;
- clocks = < CLK_APB1>, <>, <>;
+ clocks = < CLK_APB1>, <>, < 0>;
clock-names = "apb", "hosc", "losc";
gpio-controller;
#gpio-cells = <3>;
@@ -256,6 +249,21 @@
function =
Re: [U-Boot] [PATCH 1/1] efi_loader: default EFI_LOADER=n on ARM11
On Wed, Nov 20, 2019 at 7:04 PM Heinrich Schuchardt wrote: > Some of the ARM11 boards have tight limits on the size of U-Boots. Hence > use EFI_LOADER=n as default on ARM11. > > Set EFI_LOADER=y for the Raspberry Pi and Raspberry Pi Zero as these boards > have sufficient storage on the SD card. > > Suggested-by: Tom Rini > Signed-off-by: Heinrich Schuchardt Reviewed-by: Linus Walleij Yours, Linus Walleij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PULL] u-boot-socfpga/master
The following changes since commit 8d8ee47e03ef23b0d0e842ea455a30bf0d2023b9: env: Add CONFIG_SYS_RELOC_GD_ENV_ADDR symbol (2019-11-20 12:24:50 -0500) are available in the Git repository at: git://git.denx.de/u-boot-socfpga.git master for you to fetch changes up to 0c14bb5ad3311de2c26e66e88f8a6886773b8e0a: arm: socfpga: stratix10: Add alias for gmac0 in S10 dts (2019-11-22 03:08:12 +0100) Ley Foon Tan (2): arm: dts: Stratix10: Fix memory node address and size cells configs: Stratix10: Disable CONFIG_SPL_USE_TINY_PRINTF Marek Vasut (1): ARM: socfpga: Fix default mtdparts Ooi, Joyce (2): arm: dts: Stratix10: change pad skew values for EMAC0 PHY driver arm: socfpga: stratix10: Add alias for gmac0 in S10 dts Simon Goldschmidt (4): ddr: socfpga: gen5: constify altera_gen5_sdram_ops socfpga: fix include guard in misc.h (arch vs. global) timer: dw-apb: add reset handling spi: cadence_qspi: support DM_CLK arch/arm/dts/socfpga_stratix10_socdk.dts | 5 - arch/arm/mach-socfpga/include/mach/misc.h | 6 +++--- configs/socfpga_arria5_defconfig | 2 +- configs/socfpga_cyclone5_defconfig| 2 +- configs/socfpga_de0_nano_soc_defconfig| 2 +- configs/socfpga_is1_defconfig | 2 +- configs/socfpga_mcvevk_defconfig | 2 +- configs/socfpga_sockit_defconfig | 2 +- configs/socfpga_socrates_defconfig| 2 +- configs/socfpga_sr1500_defconfig | 2 +- configs/socfpga_stratix10_defconfig | 1 + drivers/ddr/altera/sdram_gen5.c | 2 +- drivers/spi/cadence_qspi.c| 21 +++-- drivers/spi/cadence_qspi.h| 1 + drivers/timer/dw-apb-timer.c | 18 +- 15 files changed, 54 insertions(+), 16 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PULL] u-boot-sh/master
The following changes since commit 3ff1ff3ff76c15efe0451309af084ee6c096c583: Merge branch '2019-11-12-migrate-SYS_REDUNDAND_ENVIRONMENT' (2019-11-12 13:40:58 -0500) are available in the Git repository at: git://git.denx.de/u-boot-sh.git master for you to fetch changes up to 8cdb1ff33caa4b2b8644e14e602566ded506a2fa: ARM: rmobile: Temporarily disable PCI dma-ranges update (2019-11-16 16:52:45 +0100) Marek Vasut (2): ARM: rmobile: Enable CONFIG_ARCH_FIXUP_FDT_MEMORY on Gen3 ARM: rmobile: Temporarily disable PCI dma-ranges update arch/arm/mach-rmobile/Kconfig | 1 - configs/r8a7795_salvator-x_defconfig | 1 - configs/r8a7795_ulcb_defconfig| 1 - configs/r8a77965_salvator-x_defconfig | 1 - configs/r8a77965_ulcb_defconfig | 1 - configs/r8a7796_salvator-x_defconfig | 1 - configs/r8a7796_ulcb_defconfig| 1 - configs/r8a77970_eagle_defconfig | 1 - configs/r8a77990_ebisu_defconfig | 1 - configs/r8a77995_draak_defconfig | 1 - 10 files changed, 10 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PULL] u-boot-usb/master
The following changes since commit d4a31e8ee5592072d8d5208b3e950cba2d89b6bd: Prepare v2020.01-rc3 (2019-11-18 21:31:49 -0500) are available in the Git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to 7dc0ac6015718f5fb66bb79bf53df19f64fbfeee: usb: dwc2: fix possible alignment issues (2019-11-22 01:25:40 +0100) Simon Goldschmidt (2): usb: composite: fix possible alignment issues usb: dwc2: fix possible alignment issues Vignesh Raghavendra (1): usb: cdns3: Fix include file path drivers/usb/cdns3/core.c | 2 +- drivers/usb/cdns3/host.c | 2 +- drivers/usb/gadget/composite.c | 25 ++--- drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 4 ++-- 4 files changed, 22 insertions(+), 11 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] usb: composite: fix possible alignment issues
On 11/22/19 12:58 PM, Heinrich Schuchardt wrote: > On 11/22/19 8:47 AM, Simon Goldschmidt wrote: >> On Fri, Nov 22, 2019 at 7:50 AM Heinrich Schuchardt >> wrote: >>> >>> On 11/22/19 1:25 AM, Marek Vasut wrote: On 11/21/19 10:15 PM, Simon Goldschmidt wrote: > Since upgrading to gcc9, warnings are issued: > "taking address of packed member of ‘...’ may result in an unaligned > pointer value" > > Fix this by converting two functions to use unaligned access since > packed > structures may be on an unaligned address, depending on USB hardware. > > Signed-off-by: Simon Goldschmidt Applied both, thanks. >>> >>> With these two patches applied to origin/master GCC 9.2.1 does not >>> produce warnings anymore but for tbs2910_defconfig: >>> >>> u-boot.imx exceeds file size limit: >>> limit: 0x5fc00 bytes >>> actual: 0x60c00 bytes >>> excess: 0x1000 bytes >>> make: *** [Makefile:1159: u-boot.imx] Error 1 >>> make: *** Deleting file 'u-boot.imx' >>> >>> So irrespective of my patches for the USB keyboard we need to address >>> the size limit on TBS2910. >> >> Is that due to my cleanup patches? Can you compare the size by compiling >> without them? That should work if you leave away the -Werror switch. >> >> Regards, >> Simon > > GCC 9.2.1 without your patches but with -Wno-address-of-packed-member: > > u-boot.imx exceeds file size limit: > limit: 0x5fc00 bytes > actual: 0x60c00 bytes > excess: 0x1000 bytes I see, so you have additional options added to the build which trigger the size issue. It would be nice to mention that up front. Do you use any other extra options ? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Maximum size of u-boot.imx for TBS2910 board
On 11/22/19 11:29 AM, Soeren Moch wrote: > > > On 22.11.19 04:58, Marek Vasut wrote: >> On 11/22/19 4:41 AM, Tom Rini wrote: >> [...] >>> I believe >>> the specific changes in question that once again push this board >>> over >>> fall in to that grey area. Whatever size-trimming the board >>> maintainer >>> is fine with next is fine with me, but needs to get ack'd by >>> someone. >> Or, the other option is, make these new extra features configurable >> and >> disable them on this board. And so there should be no size problem. > But that direction leads to saying every slight bit of functionality > requires a new Kconfig entry. Some levels of bugfixes as well. The other option is, we will sink in bloat and suffer endless size problems. >>> Yes, it is a hard balancing act. Stepping back, perhaps a "minimal" or >>> "complete" choice for USB HID devices would make sense and allow us >>> further areas to reduce size, on the minimal portion. >> Or maybe there is a way to help compiler optimize that USB key code >> handling better. > Perhaps. But my point is that every little functional change or > enhancement does not need a Kconfig option. Except this leads to slow and steady accumulation of bloat, and as we already see for quite a while, this is problematic for more and more boards. >>> And "bloat" and "features" are interchangable terms. >> Nope, bloat is unhelpful growth of size, features are actually >> helpful/useful. >> >>> I really am trying >>> to be more responsive than ever to size growth in common, rather than >>> board specific areas. And I agree, some investigation in to ways that >>> might reduce the size of binary support for USB HID devices is good. >> So we agree that's what this series should fix ? >> >>> Figuring out if we can make this series: >>> http://patchwork.ozlabs.org/project/uboot/list/?series=135448 >>> not also increase the overall size, or increase it less, is good. >>> Hiding the content of 2/5 behind a CONFIG option in turn brings us back >>> to "the code is too messy and full of #ifdef" lines. >> Which might be somewhat better than if the code is sprinkled with tiny >> chunks of random pieces of code which are never used, but in total add >> up to a lot of unused code in the binary. > > What a long discussion over night, so only a general answer: > > Once upon a time there was plenty of space for tbs2910 u-boot. > Then we had to convert everything to DM, for whatever reason. This > increased the binary size a lot, had absolutely no advantage for u-boot > users, was huge effort for board maintainers, and is still going on. > (DM_VIDEO conversion still pending for this board, probably more to > come, DM_SERIAL?). For all that additional space is required, apparently > nobody tries to cleanup the non-DM code for converted subsystems to > reclaim some of the space. > > Several times I tried to disable unneeded functions to trim the binary > size. After a few weeks the gained space was eaten up, apparently nobody > cares about binary size anymore as long as there is no build failure. > Even worse, since imx format is padded, people claim to not increase the > binary size with there patches (what in fact is not true), and then some > simple change / tool update again breaks everything. > > What is the solution to that? I don't see much what _I_ can do. If I > find some option to disable again, what is increasingly difficult, then > this removes the last opportunity for upcoming DM conversions. > For the "bloat" vs. "features" discussion: on long existing boards no > user expects new features in defconfig, especially if they only come > with reduced functionality somewhere else. And as hobbyist board > maintainer I don't know which features existing users actually use. I > only get bug reports about bricked boards when something is missing. Thank you for spelling this out, I fully agree with these sentiments. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Maximum size of u-boot.imx for TBS2910 board
On Fri, Nov 22, 2019 at 12:42:49PM +0100, Heinrich Schuchardt wrote: > On 11/22/19 11:29 AM, Soeren Moch wrote: > > > > > > On 22.11.19 04:58, Marek Vasut wrote: > > > On 11/22/19 4:41 AM, Tom Rini wrote: > > > [...] > > > > > > > > > > > > I believe > > > > > > > > > > > > the specific changes in question that once again push > > > > > > > > > > > > this board over > > > > > > > > > > > > fall in to that grey area. Whatever size-trimming the > > > > > > > > > > > > board maintainer > > > > > > > > > > > > is fine with next is fine with me, but needs to get > > > > > > > > > > > > ack'd by someone. > > > > > > > > > > > Or, the other option is, make these new extra features > > > > > > > > > > > configurable and > > > > > > > > > > > disable them on this board. And so there should be no > > > > > > > > > > > size problem. > > > > > > > > > > But that direction leads to saying every slight bit of > > > > > > > > > > functionality > > > > > > > > > > requires a new Kconfig entry. Some levels of bugfixes as > > > > > > > > > > well. > > > > > > > > > The other option is, we will sink in bloat and suffer endless > > > > > > > > > size problems. > > > > > > > > Yes, it is a hard balancing act. Stepping back, perhaps a > > > > > > > > "minimal" or > > > > > > > > "complete" choice for USB HID devices would make sense and > > > > > > > > allow us > > > > > > > > further areas to reduce size, on the minimal portion. > > > > > > > Or maybe there is a way to help compiler optimize that USB key > > > > > > > code > > > > > > > handling better. > > > > > > Perhaps. But my point is that every little functional change or > > > > > > enhancement does not need a Kconfig option. > > > > > Except this leads to slow and steady accumulation of bloat, and as we > > > > > already see for quite a while, this is problematic for more and more > > > > > boards. > > > > And "bloat" and "features" are interchangable terms. > > > Nope, bloat is unhelpful growth of size, features are actually > > > helpful/useful. > > > > > > > I really am trying > > > > to be more responsive than ever to size growth in common, rather than > > > > board specific areas. And I agree, some investigation in to ways that > > > > might reduce the size of binary support for USB HID devices is good. > > > So we agree that's what this series should fix ? > > > > > > > Figuring out if we can make this series: > > > > http://patchwork.ozlabs.org/project/uboot/list/?series=135448 > > > > not also increase the overall size, or increase it less, is good. > > > > Hiding the content of 2/5 behind a CONFIG option in turn brings us back > > > > to "the code is too messy and full of #ifdef" lines. > > > Which might be somewhat better than if the code is sprinkled with tiny > > > chunks of random pieces of code which are never used, but in total add > > > up to a lot of unused code in the binary. > > > > What a long discussion over night, so only a general answer: > > > > Once upon a time there was plenty of space for tbs2910 u-boot. > > Then we had to convert everything to DM, for whatever reason. This > > increased the binary size a lot, had absolutely no advantage for u-boot > > users, was huge effort for board maintainers, and is still going on. > > (DM_VIDEO conversion still pending for this board, probably more to > > come, DM_SERIAL?). For all that additional space is required, apparently > > nobody tries to cleanup the non-DM code for converted subsystems to > > reclaim some of the space. > > > > Several times I tried to disable unneeded functions to trim the binary > > size. After a few weeks the gained space was eaten up, apparently nobody > > cares about binary size anymore as long as there is no build failure. > > Even worse, since imx format is padded, people claim to not increase the > > binary size with there patches (what in fact is not true), and then some > > simple change / tool update again breaks everything. > > > > What is the solution to that? I don't see much what _I_ can do. If I > > find some option to disable again, what is increasingly difficult, then > > this removes the last opportunity for upcoming DM conversions. > > For the "bloat" vs. "features" discussion: on long existing boards no > > user expects new features in defconfig, especially if they only come > > with reduced functionality somewhere else. And as hobbyist board > > maintainer I don't know which features existing users actually use. I > > only get bug reports about bricked boards when something is missing. > > > > Soeren > > > > > Hello Soeren, > > what is your view on changing CONFIG_ENV_OFFSET=0x6 to > CONFIG_ENV_OFFSET=0xC? I am still against that move as we need to address the real underlying problem of size growth. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 000/100] x86: Add initial support for apollolake
Hi Bin, On Thu, 21 Nov 2019 at 21:19, Simon Glass wrote: > > Apollo Lake is an Intel SoC generation aimed at relatively low-end > embedded systems. It was released in 2016 but has become more popular > recently with some embedded boards using it. > > This series adds support for Apollo Lake. As an example it adds an > implementation of chromebook_coral (a large range of Chromebooks released > in 2017). > > The series provides enough support to boot to a prompt. with LCD display, > storage, USB, EC and keyboard. > > Since this is the first time U-Boot has used FSP2 there is quite a bit of > refactoring needed. > > This series is available at u-boot-dm/coral-working > > Changes in v4: > - Add a LOG_CATEGORY for silicon init Unfortunately I left out some review tags in this version. I can resend if that helps. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] usb: composite: fix possible alignment issues
On 11/22/19 8:47 AM, Simon Goldschmidt wrote: On Fri, Nov 22, 2019 at 7:50 AM Heinrich Schuchardt wrote: On 11/22/19 1:25 AM, Marek Vasut wrote: On 11/21/19 10:15 PM, Simon Goldschmidt wrote: Since upgrading to gcc9, warnings are issued: "taking address of packed member of ‘...’ may result in an unaligned pointer value" Fix this by converting two functions to use unaligned access since packed structures may be on an unaligned address, depending on USB hardware. Signed-off-by: Simon Goldschmidt Applied both, thanks. With these two patches applied to origin/master GCC 9.2.1 does not produce warnings anymore but for tbs2910_defconfig: u-boot.imx exceeds file size limit: limit: 0x5fc00 bytes actual: 0x60c00 bytes excess: 0x1000 bytes make: *** [Makefile:1159: u-boot.imx] Error 1 make: *** Deleting file 'u-boot.imx' So irrespective of my patches for the USB keyboard we need to address the size limit on TBS2910. Is that due to my cleanup patches? Can you compare the size by compiling without them? That should work if you leave away the -Werror switch. Regards, Simon GCC 9.2.1 without your patches but with -Wno-address-of-packed-member: u-boot.imx exceeds file size limit: limit: 0x5fc00 bytes actual: 0x60c00 bytes excess: 0x1000 bytes Best regards Heinrich Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Maximum size of u-boot.imx for TBS2910 board
On 11/22/19 11:29 AM, Soeren Moch wrote: On 22.11.19 04:58, Marek Vasut wrote: On 11/22/19 4:41 AM, Tom Rini wrote: [...] I believe the specific changes in question that once again push this board over fall in to that grey area. Whatever size-trimming the board maintainer is fine with next is fine with me, but needs to get ack'd by someone. Or, the other option is, make these new extra features configurable and disable them on this board. And so there should be no size problem. But that direction leads to saying every slight bit of functionality requires a new Kconfig entry. Some levels of bugfixes as well. The other option is, we will sink in bloat and suffer endless size problems. Yes, it is a hard balancing act. Stepping back, perhaps a "minimal" or "complete" choice for USB HID devices would make sense and allow us further areas to reduce size, on the minimal portion. Or maybe there is a way to help compiler optimize that USB key code handling better. Perhaps. But my point is that every little functional change or enhancement does not need a Kconfig option. Except this leads to slow and steady accumulation of bloat, and as we already see for quite a while, this is problematic for more and more boards. And "bloat" and "features" are interchangable terms. Nope, bloat is unhelpful growth of size, features are actually helpful/useful. I really am trying to be more responsive than ever to size growth in common, rather than board specific areas. And I agree, some investigation in to ways that might reduce the size of binary support for USB HID devices is good. So we agree that's what this series should fix ? Figuring out if we can make this series: http://patchwork.ozlabs.org/project/uboot/list/?series=135448 not also increase the overall size, or increase it less, is good. Hiding the content of 2/5 behind a CONFIG option in turn brings us back to "the code is too messy and full of #ifdef" lines. Which might be somewhat better than if the code is sprinkled with tiny chunks of random pieces of code which are never used, but in total add up to a lot of unused code in the binary. What a long discussion over night, so only a general answer: Once upon a time there was plenty of space for tbs2910 u-boot. Then we had to convert everything to DM, for whatever reason. This increased the binary size a lot, had absolutely no advantage for u-boot users, was huge effort for board maintainers, and is still going on. (DM_VIDEO conversion still pending for this board, probably more to come, DM_SERIAL?). For all that additional space is required, apparently nobody tries to cleanup the non-DM code for converted subsystems to reclaim some of the space. Several times I tried to disable unneeded functions to trim the binary size. After a few weeks the gained space was eaten up, apparently nobody cares about binary size anymore as long as there is no build failure. Even worse, since imx format is padded, people claim to not increase the binary size with there patches (what in fact is not true), and then some simple change / tool update again breaks everything. What is the solution to that? I don't see much what _I_ can do. If I find some option to disable again, what is increasingly difficult, then this removes the last opportunity for upcoming DM conversions. For the "bloat" vs. "features" discussion: on long existing boards no user expects new features in defconfig, especially if they only come with reduced functionality somewhere else. And as hobbyist board maintainer I don't know which features existing users actually use. I only get bug reports about bricked boards when something is missing. Soeren Hello Soeren, what is your view on changing CONFIG_ENV_OFFSET=0x6 to CONFIG_ENV_OFFSET=0xC? Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] Introduce DSA Ethernet switch class and Felix driver
On Fri, 22 Nov 2019 at 03:37, Alex Marginean wrote: > > DSA stands for Distributed Switch Architecture and it is a subsystem > introduced > in the Linux kernel to support switches that: > - have an Ethernet link up to the CPU > - use some form of tagging to identify the source/destination port for Rx/Tx > - may be cascaded in tree-like structures. > > DSA is described in depth here: > https://www.kernel.org/doc/Documentation/networking/dsa/dsa.txt > > From the doc: > > Summarized, this is basically how DSA looks like from a network device > perspective: > > > |--- > | CPU network device (eth0)| > > | | | > | | > |tag added by CPU> | > || > | Switch driver | > || > |||| || > |---| |---| |---| > | sw0p0 | | sw0p1 | | sw0p2 | > |---| |---| |---| > > This patch set introduces a DSA class in U-Boot to support drivers of such > switches. DSA drivers have to implement the following ops: > - enable/disable of switch ports, > - insert a tag in frames being transmitted, used by the switch to select the > egress port, > - parse a tag in frames being received, used for Rx traffic. > > DSA class code deals with presentation of switch ports as Ethernet interfaces, > deals with the master Ethernet device for I/O and helps with parsing of the DT > assuming the structure follows the DSA kernel binding. > > Support for switch cascading is not included yet. > > This patch set also introduces a driver for the Ethernet switch integrated > into > NXP LS1028A, called Felix. The switch has 4 front panel ports, I/O to/fom it > is > done though an ENETC Ethernet interface and meta-data is carried between the > switch and the driver though an additional header pre-pended to the original > frame. > Network commands like tftp can be used on these front panel ports. The ports > are disabled unless used so they do not cause issues on network topologies > that > include loops. > > Felix as seen on LS1028A RDB: > => dm tree > Class Index Probed DriverName > --- > .. > dsa 0 [ + ] felix-switch | |-- felix-switch > eth 4 [ + ] dsa-port | | |-- swp0 > eth 5 [ + ] dsa-port | | |-- swp1 > eth 6 [ + ] dsa-port | | |-- swp2 > eth 7 [ + ] dsa-port | | `-- swp3 > > => mdio list > .. > 10 - Vitesse VSC8514 <--> swp0 > 11 - Vitesse VSC8514 <--> swp1 > 12 - Vitesse VSC8514 <--> swp2 > 13 - Vitesse VSC8514 <--> swp3 > > => tftp 8000 test > Using swp2 device > TFTP from server 192.168.100.1; our IP address is 192.168.100.100 > Filename 'test'. > Load address: 0x8000 > Loading: # > # > > 6.8 MiB/s > done > Bytes transferred = 949880 (e7e78 hex) > > > > This patch set replaces this previous submission of the Felix driver: > https://patchwork.ozlabs.org/project/uboot/list/?series=143126=* > and depends on: > https://patchwork.ozlabs.org/project/uboot/list/?series=142858 > https://patchwork.ozlabs.org/project/uboot/list/?series=142879 > > Alex Marginean (6): > net: introduce DSA class for Ethernet switches > drivers: net: add a DSA sandbox driver > test: dm: add a simple unit test for DSA class > drivers: net: add Felix DSA switch driver > arm: dts: ls1028a: adds Ethernet switch node and its dependencies > configs: ls1028a: enable the Ethernet switch driver in defconfig > > arch/Kconfig | 1 + > arch/arm/dts/fsl-ls1028a-rdb.dts | 36 ++ > arch/arm/dts/fsl-ls1028a.dtsi| 41 +- > arch/sandbox/dts/test.dts| 49 ++ > configs/ls1028aqds_tfa_SECURE_BOOT_defconfig | 3 +- > configs/ls1028aqds_tfa_defconfig | 3 +- > configs/ls1028ardb_tfa_SECURE_BOOT_defconfig | 3 +- > configs/ls1028ardb_tfa_defconfig | 3 +- > drivers/net/Kconfig | 21 + > drivers/net/Makefile | 1 + > drivers/net/dsa_sandbox.c| 272 +++ > drivers/net/fsl_enetc.h | 5 + > drivers/net/mscc_eswitch/Kconfig | 8 + > drivers/net/mscc_eswitch/Makefile
Re: [U-Boot] Maximum size of u-boot.imx for TBS2910 board
On 22.11.19 04:58, Marek Vasut wrote: > On 11/22/19 4:41 AM, Tom Rini wrote: > [...] >> I believe >> the specific changes in question that once again push this board over >> fall in to that grey area. Whatever size-trimming the board >> maintainer >> is fine with next is fine with me, but needs to get ack'd by someone. > Or, the other option is, make these new extra features configurable > and > disable them on this board. And so there should be no size problem. But that direction leads to saying every slight bit of functionality requires a new Kconfig entry. Some levels of bugfixes as well. >>> The other option is, we will sink in bloat and suffer endless size >>> problems. >> Yes, it is a hard balancing act. Stepping back, perhaps a "minimal" or >> "complete" choice for USB HID devices would make sense and allow us >> further areas to reduce size, on the minimal portion. > Or maybe there is a way to help compiler optimize that USB key code > handling better. Perhaps. But my point is that every little functional change or enhancement does not need a Kconfig option. >>> Except this leads to slow and steady accumulation of bloat, and as we >>> already see for quite a while, this is problematic for more and more boards. >> And "bloat" and "features" are interchangable terms. > Nope, bloat is unhelpful growth of size, features are actually > helpful/useful. > >> I really am trying >> to be more responsive than ever to size growth in common, rather than >> board specific areas. And I agree, some investigation in to ways that >> might reduce the size of binary support for USB HID devices is good. > So we agree that's what this series should fix ? > >> Figuring out if we can make this series: >> http://patchwork.ozlabs.org/project/uboot/list/?series=135448 >> not also increase the overall size, or increase it less, is good. >> Hiding the content of 2/5 behind a CONFIG option in turn brings us back >> to "the code is too messy and full of #ifdef" lines. > Which might be somewhat better than if the code is sprinkled with tiny > chunks of random pieces of code which are never used, but in total add > up to a lot of unused code in the binary. What a long discussion over night, so only a general answer: Once upon a time there was plenty of space for tbs2910 u-boot. Then we had to convert everything to DM, for whatever reason. This increased the binary size a lot, had absolutely no advantage for u-boot users, was huge effort for board maintainers, and is still going on. (DM_VIDEO conversion still pending for this board, probably more to come, DM_SERIAL?). For all that additional space is required, apparently nobody tries to cleanup the non-DM code for converted subsystems to reclaim some of the space. Several times I tried to disable unneeded functions to trim the binary size. After a few weeks the gained space was eaten up, apparently nobody cares about binary size anymore as long as there is no build failure. Even worse, since imx format is padded, people claim to not increase the binary size with there patches (what in fact is not true), and then some simple change / tool update again breaks everything. What is the solution to that? I don't see much what _I_ can do. If I find some option to disable again, what is increasingly difficult, then this removes the last opportunity for upcoming DM conversions. For the "bloat" vs. "features" discussion: on long existing boards no user expects new features in defconfig, especially if they only come with reduced functionality somewhere else. And as hobbyist board maintainer I don't know which features existing users actually use. I only get bug reports about bricked boards when something is missing. Soeren ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3] travis: rework NXP layerscape jobs
remove from NXP arm32 all layerscape boards and build them instead in already existing layerscape jobs (which now not only build aarch64 boards) Signed-off-by: Heiko Schocher --- travis build: https://travis-ci.org/hsdenx/u-boot-test/builds/615388594 https://dev.azure.com/hs0298/hs/_build/results?buildId=5 Changes in v3: - add changes also to azure pipeline, as it makes sense here to keep azure configuration in sync with travis configuration Changes in v2: - collect in the layerscape jobs not only aarch64 based boards as Tom suggested. - change subject, old was "travis: split NXP ARM32 job" .azure-pipelines.yml | 26 +- .travis.yml | 28 ++-- 2 files changed, 27 insertions(+), 27 deletions(-) diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml index 44a76ebb09..cad8eea87b 100644 --- a/.azure-pipelines.yml +++ b/.azure-pipelines.yml @@ -312,19 +312,19 @@ jobs: arm_bcm: BUILDMAN: "bcm -x mips" nxp_arm32: - BUILDMAN: "freescale -x powerpc,m68k,aarch64" -nxp_aarch64_ls101x: - BUILDMAN: "freescale" -nxp_aarch64_ls102x: - BUILDMAN: "freescale" -nxp_aarch64_ls104x: - BUILDMAN: "freescale" -nxp_aarch64_ls108x: - BUILDMAN: "freescale" -nxp_aarch64_ls20xx: - BUILDMAN: "freescale" -nxp_aarch64_lx216x: - BUILDMAN: "freescale" + BUILDMAN: "freescale -x powerpc,m68k,aarch64,ls101,ls102,ls104,ls108,ls20,lx216" +nxp_ls101x: + BUILDMAN: "freescale" +nxp_ls102x: + BUILDMAN: "freescale" +nxp_ls104x: + BUILDMAN: "freescale" +nxp_ls108x: + BUILDMAN: "freescale" +nxp_ls20xx: + BUILDMAN: "freescale" +nxp_lx216x: + BUILDMAN: "freescale" imx6: BUILDMAN: "mx6 -x boundary,engicam,freescale,technexion,toradex" imx: diff --git a/.travis.yml b/.travis.yml index d973aaa653..5da046ca7e 100644 --- a/.travis.yml +++ b/.travis.yml @@ -183,27 +183,27 @@ matrix: - name: "buildman ARM bcm" env: - BUILDMAN="bcm -x mips" -- name: "buildman NXP ARM32" +- name: "buildman NXP ARM32 (catch-all)" env: -- BUILDMAN="freescale -x powerpc,m68k,aarch64" -- name: "buildman NXP AArch64 LS101x" +- BUILDMAN="freescale -x powerpc,m68k,aarch64,ls101,ls102,ls104,ls108,ls20,lx216" +- name: "buildman NXP LS101x" env: -- BUILDMAN="freescale" -- name: "buildman NXP AArch64 LS102x" +- BUILDMAN="freescale" +- name: "buildman NXP LS102x" env: -- BUILDMAN="freescale" -- name: "buildman NXP AArch64 LS104x" +- BUILDMAN="freescale" +- name: "buildman NXP LS104x" env: -- BUILDMAN="freescale" -- name: "buildman NXP AArch64 LS108x" +- BUILDMAN="freescale" +- name: "buildman NXP LS108x" env: -- BUILDMAN="freescale" -- name: "buildman NXP AArch64 LS20xx" +- BUILDMAN="freescale" +- name: "buildman NXP LS20xx" env: -- BUILDMAN="freescale" -- name: "buildman NXP AArch64 LX216x" +- BUILDMAN="freescale" +- name: "buildman NXP LX216x" env: -- BUILDMAN="freescale" +- BUILDMAN="freescale" - name: "buildman i.MX6 tqc" env: - BUILDMAN="mx6" -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] configs: ls1028a: enable CMD_DM
Since at least some of the drivers relevant to LS1028A are now following DM, it's useful to have dm command enabled by default. Signed-off-by: Alex Marginean --- Changes in v2: fixed checkpatch warning configs/ls1028aqds_tfa_SECURE_BOOT_defconfig | 1 + configs/ls1028aqds_tfa_defconfig | 1 + configs/ls1028ardb_tfa_SECURE_BOOT_defconfig | 1 + configs/ls1028ardb_tfa_defconfig | 1 + 4 files changed, 4 insertions(+) diff --git a/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig b/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig index e2fed911b1..fadb13d469 100644 --- a/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig @@ -16,6 +16,7 @@ CONFIG_BOOTDELAY=10 CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0 earlycon=uart8250,mmio,0x21c0500 ramdisk_size=0x200 default_hugepagesz=2m hugepagesz=2m hugepages=256 video=1920x1080-32@60 cma=256M" CONFIG_CMD_GREPENV=y +CONFIG_CMD_DM=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y diff --git a/configs/ls1028aqds_tfa_defconfig b/configs/ls1028aqds_tfa_defconfig index 67c9a82bcd..b690e24c7f 100644 --- a/configs/ls1028aqds_tfa_defconfig +++ b/configs/ls1028aqds_tfa_defconfig @@ -15,6 +15,7 @@ CONFIG_BOOTDELAY=10 CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0 earlycon=uart8250,mmio,0x21c0500 ramdisk_size=0x200 default_hugepagesz=2m hugepagesz=2m hugepages=256 video=1920x1080-32@60 cma=256M" CONFIG_CMD_GREPENV=y +CONFIG_CMD_DM=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y diff --git a/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig b/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig index 6b87c57ec3..cbbe649485 100644 --- a/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1028ardb_tfa_SECURE_BOOT_defconfig @@ -16,6 +16,7 @@ CONFIG_BOOTDELAY=10 CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0 earlycon=uart8250,mmio,0x21c0500 ramdisk_size=0x200 default_hugepagesz=2m hugepagesz=2m hugepages=256 video=1920x1080-32@60 cma=256M" CONFIG_CMD_GREPENV=y +CONFIG_CMD_DM=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y diff --git a/configs/ls1028ardb_tfa_defconfig b/configs/ls1028ardb_tfa_defconfig index 1fd38ca3d4..35c46d4dd7 100644 --- a/configs/ls1028ardb_tfa_defconfig +++ b/configs/ls1028ardb_tfa_defconfig @@ -15,6 +15,7 @@ CONFIG_BOOTDELAY=10 CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0 earlycon=uart8250,mmio,0x21c0500 ramdisk_size=0x200 default_hugepagesz=2m hugepagesz=2m hugepages=256 video=1920x1080-32@60 cma=256M" CONFIG_CMD_GREPENV=y +CONFIG_CMD_DM=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/5] doc: bindings: add mdio-handle property to ethernet nodes
On 11/21/2019 1:30 PM, Grygorii Strashko wrote:
Some thought, which i think might help.
- u-boot allows phy node not to have "reg" property.
- phy_connect() will return first PHY discovered on the MDIO bus if
addr<=0
So, if MDIO assignment per ethernet interface/slot is fixed DT can
look like
mdioX {
mdiox_phy0: ethernet-phy@0 {
};
}
ethernetX {
phy-handle = <_phy0>;
}
and so on. driver's parsing code can ignore PHY "reg" prop in phy
node and pass addr<=0 to phy_connect().
Functionally that's what I'm looking for, yes. There is the problem of
not strictly following the kernel binding and at the end of the day I
will have the same problem with the kernel too, so I should take this
topic to the netdev list anyway.
Having 'reg' made optional is actually an interesting idea. I think
'mdio-handle' is a bit more clear what it is, but having an actual PHY
node allows passing DT properties on to the PHY driver which is
certainly useful for some PHYs. It's like saying I don't know what PHY
I'm going to find, but if it's a PHY that has these configurable
properties here is your configuration.
Another good question is "phy-connection-type"/"phy-mode".
Are all your cards works in the same mode? And how is this solved?
These SoCs generally support multiple protocols on the serdes lanes.
The protocol is selected at power on so just using a single static
DT isn't sufficient.
For Linux DT I tried the DT overlay which seems to work fine. I'm
using it to fix up phy-connection-type based on serdes configuration
that is known to u-boot. Of course it's possible to apply an
overlay for each specific plug-in card in a given slot too, but that's
not practical especially for mixes of board with many slots combined
with many types of cards. I'm not sure this can be done automatically
in U-Boot such that the user doesn't have to do any manual configuration
when swapping cards either.
U-Boot doesn't have the luxury of having overlays applied before it
starts, we don't use SPL. I'm considering ways to have platform init
code apply some sort of fix-up or overlay for U-Boot DT based on serdes
configuration, but I don't have something running yet. Live tree is
something I want to look into to see if it would work here.
Is there anything common with SFP? Linux: bindings/net/sff,sfp.txt
They are not SFPs, they are normal MDIO driven PHYs just that they are
mounted on plug-in cards.
It seems, current Linux approach is to have PHY "reg" property as
required, but your case might be the reason to change this. >
I'll have to do a better write-up for the kernel list and we'll see
how this will go.
In the meantime any feedback on the other patches, except the one
introducing mdio-handle? For instance I should deal with fixed links
in the dm_eth_phy_connect helper too (calling phy_connect_fixed),
my intent is to take some code that is otherwise pretty generic out of
the drivers.
From one side, it look nice. From another, in my case MDIO is not a
device, so can't try it.
But, any way, I'd like to share some notes I have. It may help you or may
save your time by reducing number of possible regressions.
To be honest, there is a little mess in PHY creation area :(
Common way is to do in drivers:
phy_connect(mii_bus, phy_addr, dev, interface)
|-phy_find_by_mask()
|-get_phy_device_by_mask()
|-create_phy_by_mask()
|-create_phy_by_mask()
|-phy_device_create()
|-phy_probe()
|-phy_connect_dev(phydev, dev);
..
#ifdef CONFIG_DM_ETH
if (ofnode_valid(slave->data->phy_of_handle))
phydev->node = slave->data->phy_of_handle;
#endif
As you can see from above - the PHY probe will be called when
both phy_device->dev and phydev->node have not been initialized yet,
so no way to perform DT parsing in PHY .probe().
That is certainly inconsistent with the way other kinds of devices work.
What I did for DT based configuration on aquantia PHYs was to read the
DT properties in _config. Just from a practical stand-point that's
fine, phydev->node is presumably set up by now and ethernet drivers have
to call _config anyway and that gives the PHY driver a chance to check
the DT properties. But conceptually it is messy, it makes phy drivers
special. I suppose the solution is to make phy drivers behave like
the other udevices, either actually making them udevices or at least
introducing phy_bind ahead of probe.
On the current code, do you see any issues with dealing with the
PHY DT properties in _config, other than this inconsistency with the
other devices?
Another, not obvious, thing is that DT node for fixed phy passed
through the int addr parameter in create_phy_by_mask().
This is a work-around for the previous issue I assume.
And finally, as phy as fixed-phy may be connected to DT node which is
*not" ethernet device node and describes Port. The ethernet device is
parent DT node in this case.
Are these switch ports or on a multi-port Ethernet
Re: [U-Boot] [PATCH 1/1] arm: fix -march for ARM11
On Tue, Nov 19, 2019 at 11:16 PM Heinrich Schuchardt wrote: > -march v5 is invalid for GCC 9.2.1. ARM11 is an armv6 implementation. So > change the architecture flag for the compiler to armv6. > Cf. https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html > > Suggested-by: Fabio Estevam > Signed-off-by: Heinrich Schuchardt After I read up on it I would add something to the commit saying that the first -march=armv5 must have been wrong all the time since there are no known implementations of armv5, only armv5t, armv5te and armv5tej. Maybe add a link to this: https://gcc.gnu.org/gcc-9/changes.html Yours, Linus Walleij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
