[U-Boot] Pull request: u-boot-riscv/master
Hi Tom, Please pull some riscv updates: - Fix sifive serial y-modem transfer. - Access CSRs using CSR numbers. - Update doc sifive-fu540 - Support big endian hosts and target. https://travis-ci.org/rickchen36/u-boot-riscv/builds/572159567 Thanks Rick The following changes since commit df33f8646855e65b8e7232c7fd5739e1ae1eb58b: configs: Resync with savedefconfig (2019-08-14 08:11:27 -0400) are available in the Git repository at: g...@gitlab.denx.de:u-boot/custodians/u-boot-riscv.git for you to fetch changes up to 4539926a9c47638951f29f550f3a640e4c223032: riscv: tools: Add big endian target support to prelink-riscv (2019-08-15 13:42:28 +0800) Anup Patel (1): doc: sifive-fu540: Update README to explicitly load DTB for Linux Bin Meng (2): riscv: Sync csr.h with Linux kernel v5.2 riscv: Access CSRs using CSR numbers Marcus Comstedt (2): riscv: tools: Fix prelink-riscv to work on big endian hosts riscv: tools: Add big endian target support to prelink-riscv Sagar Shrikant Kadam (1): riscv : serial: use rx watermark to indicate rx data is present arch/riscv/cpu/cpu.c | 9 ++- arch/riscv/cpu/start.S| 3 +- arch/riscv/include/asm/asm.h | 68 arch/riscv/include/asm/csr.h | 74 +- arch/riscv/include/asm/encoding.h | 238 + doc/board/sifive/fu540.rst| 396 --- drivers/serial/serial_sifive.c| 23 +++ tools/prelink-riscv.c | 39 +--- tools/prelink-riscv.inc | 60 ++ 9 files changed, 426 insertions(+), 484 deletions(-) create mode 100644 arch/riscv/include/asm/asm.h ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4 v5] watchdog: Implement generic watchdog_reset() version
Hi Bin,
On 15.08.19 16:19, Bin Meng wrote:
Hi Stefan,
On Thu, Aug 15, 2019 at 2:07 PM Stefan Roese wrote:
Hi Simon,
On 14.08.19 21:35, Simon Glass wrote:
Hi,
On Wed, 14 Aug 2019 at 00:22, Stefan Roese wrote:
Hi Simon,
(added Simon Glass and Bin to Cc)
On 13.08.19 22:16, Simon Goldschmidt wrote:
Am 25.04.2019 um 09:17 schrieb Stefan Roese:
This patch tries to implement a generic watchdog_reset() function that
can be used by all boards that want to service the watchdog device in
U-Boot. This watchdog servicing is enabled via CONFIG_WATCHDOG.
Without this approach, new boards or platforms needed to implement a
board specific version of this functionality, mostly copy'ing the same
code over and over again into their board or platforms code base.
With this new generic function, the scattered other functions are now
removed to be replaced by the generic one. The new version also enables
the configuration of the watchdog timeout via the DT "timeout-sec"
property (if enabled via CONFIG_OF_CONTROL).
This patch also adds a new flag to the GD flags, to flag that the
watchdog is ready to use and adds the pointer to the watchdog device
to the GD. This enables us to remove the global "watchdog_dev"
variable, which was prone to cause problems because of its potentially
very early use in watchdog_reset(), even before the BSS is cleared.
Signed-off-by: Stefan Roese
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -133,6 +133,9 @@ typedef struct global_data {
struct spl_handoff *spl_handoff;
# endif
#endif
+#if defined(CONFIG_WDT)
+struct udevice *watchdog_dev;
+#endif
} gd_t;
#endif
@@ -161,5 +164,6 @@ typedef struct global_data {
#define GD_FLG_ENV_DEFAULT0x02000 /* Default variable flag
*/
#define GD_FLG_SPL_EARLY_INIT 0x04000 /* Early SPL init is done
*/
#define GD_FLG_LOG_READY 0x08000 /* Log system is ready for use */
+#define GD_FLG_WDT_READY0x1 /* Watchdog is ready for use */
Sorry to warm up a thread that is more than 4 months old, but I just
stumbled accross this line when searching for space in 'gd':
The comment some lines above in global_data.h clearly states that the
top 16 bits of flags are reserved for arch-specific flags, and your
patch here uses the lowest of these 16 arch-specific flags for generic code.
I totally missed this comment.
Is this a problem? Does any arch code use the upper 16 bits? I would
have thought you'd at least need to adjust the comment to reflect your
new usage...
As stated above, I did not check about any other (arch-specific)
GD_FLG_ definitions outside of this file.
The reason I ask is that I'd need a place to put some (~5?)
'is_initialized' bits for some code running in SPL in the 'board_init_f'
code where BSS shouldn't be used. gd->flags would be ideal for that, but
I'm hesistant to dive in further into the 'arch-specific' upper 16 bits...
And you should be. A quick grep shows that we already have a problem with
my patch touching the upper bits:
$ git grep "define GD_FLG_"
arch/x86/include/asm/global_data.h:#define GD_FLG_COLD_BOOT 0x1 /* Cold
Boot */
arch/x86/include/asm/global_data.h:#define GD_FLG_WARM_BOOT 0x2 /* Warm
Boot */
This should definitely be fixed. I see 3 options right now:
a) Reserve only the upper 8 bits for arch-specific stuff
b) Use a new variable (gd->flags_arch ?) for this arch
c) Remove the arch-specific GD_FLG's completely
I can't tell if c) is doable - Bin and / or Simon Glass might know,
if the x86 GD_FLG_foo_BOOT are really needed in gd->flags. I see that
both are assigned in the .S files, but only GD_FLG_COLD_BOOT is
referenced later on:
Probably we can drop warm boot.
Bin, do you think so as well?
I believe we can drop these 2 flags completely. Currently usage of
warm/cold boot flags is only limited to coreboot codes.
arch/x86/cpu/coreboot/coreboot.c::last_stage_init()
if (gd->flags & GD_FLG_COLD_BOOT)
timestamp_add_to_bootstage();
timestamp_add_to_bootstage() will never be called for coreboot.
Why is this the case? Will GD_FLG_COLD_BOOT never be set for the
coreboot target?
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] 答复: [PATCH v2 1/4] USB: gadget: Add the cadence USB3 gadget driver
Hi Marek
>
> On 8/14/19 2:16 PM, sherry sun wrote:
> > From: Sherry Sun
> >
> > This driver is ported from NXP i.MX U-Boot version imx_v2019.04 and
> > some changes have also been made to adapt to U-Boot.
> >
> > Add the Cadence USB3 IP(CDNS3) driver for the gadget (device mode).
> > The CDNS3 gadget driver support DM mode. CONFIG_DM_USB_GADGET
> should
> > be enabled when use this driver. And gadget_is_cdns3 checking is added
> > to provide bcdUSB value in device descriptor.
>
> The cadence core isn't xhci compatible ? Sigh ...
>
Actually, I'm not very understand what the xhci compatible means?
The cadence core can support usb peripheral and host. But for now,
we just done the gadget part in the core code. If it needed later, we
can add the host part to it.
> [...]
>
> > +++ b/doc/device-tree-bindings/usb/cdns-usb3.txt
> > @@ -0,0 +1,39 @@
> > +* Cadence USB3 Controller
> > +
> > +Required properties:
> > +- compatible: "Cadence,usb3";
>
> cdns , no ?
Yes, I have already changed all compatible to "cdns,usb3".
>
> [...]
>
> > +static int cdns3_generic_peripheral_clk_init(struct udevice *dev,
> > +struct cdns3_generic_peripheral
> > +*priv)
> > +{
> > + int ret;
> > +
> > + ret = clk_get_bulk(dev, >clks);
> > + if (ret)
> > + return ret;
> > +
> > +#if CONFIG_IS_ENABLED(CLK)
>
> Why is the ifdef protecting only half of the clock functions ?
Because the clk_get_bulk() also has function define even if CONFIG_CLK is not
defined.
So this way would not cause undefined reference error.
But for the sake of uniformity, I will move clk_get_bulk() into the ifdef
protecting.
>
> > + ret = clk_enable_bulk(>clks);
> > + if (ret) {
> > + clk_release_bulk(>clks);
> > + return ret;
> > + }
> > +#endif
> > +
> > + return 0;
> > +}
>
>
> [...]
>
> > +static void cdns3_set_role(struct cdns3 *cdns, enum cdns3_roles role)
> > +{
> > + u32 value;
> > + int timeout_us = 10;
> > + struct cdns3_generic_peripheral *priv = container_of(cdns,
> > + struct cdns3_generic_peripheral, cdns3);
> > +
> > + if (role == CDNS3_ROLE_END)
> > + return;
> > +
> > + /* Wait clk value */
> > + value = readl(cdns->none_core_regs + USB3_SSPHY_STATUS);
> > + writel(value, cdns->none_core_regs + USB3_SSPHY_STATUS);
> > + udelay(1);
> > + value = readl(cdns->none_core_regs + USB3_SSPHY_STATUS);
> > + while ((value & 0xf000) != 0xf000 && timeout_us-- > 0) {
> > + value = readl(cdns->none_core_regs + USB3_SSPHY_STATUS);
> > + udelay(1);
> > + }
>
> Is this like wait_for_bit() ?
Yes, thanks for the reminder, I have already use wait_for_bit_le32() to replace
these.
>
> > + if (timeout_us <= 0)
> > + dev_err(cdns->dev, "wait clkvld timeout\n");
> > +
> > + /* Set all Reset bits */
> > + setbits_le32(cdns->none_core_regs + USB3_CORE_CTRL1,
> ALL_SW_RESET);
> > + udelay(1);
> > +
> > + if (role == CDNS3_ROLE_HOST) {
>
> Do we need custom controller role definition ? I don't think so, just use the
> one in the USB stack.
>
Actually we need create an array with two elements to store the corresponding
host/gadge
function pointer in struct cdns3. And use CDNS3_ROLE_END to do the check.
If we use the role define in USB stack, the array[USB_DR_MODE_UNKNOWN] will
always be
defined but not used. So I think the controller role definition is needed here.
But if you really think the controller role definition isn’t appropriate, I
will change it.
10 enum cdns3_roles {
11 CDNS3_ROLE_HOST = 0,
12 CDNS3_ROLE_GADGET,
13 CDNS3_ROLE_END,
14 };
12 enum usb_dr_mode {
13 USB_DR_MODE_UNKNOWN,
14 USB_DR_MODE_HOST,
15 USB_DR_MODE_PERIPHERAL,
16 USB_DR_MODE_OTG,
17 };
> Also, use clrsetbits_le32()
Sure.
>
> > + value = readl(cdns->none_core_regs + USB3_CORE_CTRL1);
> > + value = (value & ~MODE_STRAP_MASK) | HOST_MODE |
> OC_DISABLE;
> > + writel(value, cdns->none_core_regs + USB3_CORE_CTRL1);
> > + clrbits_le32(cdns->none_core_regs + USB3_CORE_CTRL1,
> > +PHYAHB_SW_RESET);
> > + mdelay(1);
> > + generic_phy_init(>phy);
> > + setbits_le32(cdns->phy_regs + TB_ADDR_TX_RCVDETSC_CTRL,
> > +RXDET_IN_P3_32KHZ);
> > + udelay(10);
> > + /* Force B Session Valid as 1 */
> > + writel(0x0060, cdns->phy_regs + 0x380a4);
> > + mdelay(1);
> > +
> > + setbits_le32(cdns->none_core_regs + USB3_INT_REG,
> HOST_INT1_EN);
> > +
> > + clrbits_le32(cdns->none_core_regs + USB3_CORE_CTRL1,
> > +ALL_SW_RESET);
> > +
> > + dev_dbg(cdns->dev, "wait xhci_power_on_ready\n");
> > +
> > + value = readl(cdns->none_core_regs + USB3_CORE_STATUS);
> > + timeout_us = 10;
> > +
Re: [U-Boot] [PATCH] Revert "net: macb: Fixed reading MII_LPA register"
On Wed, Aug 14, 2019 at 4:01 PM Bin Meng wrote:
>
> This reverts commit 1b0c9914cc75d1570359181ebd493cd5746cb0ed.
>
> Commit 1b0c9914cc75 ("net: macb: Fixed reading MII_LPA register")
> causes 100Mbps does not work any more with SiFive FU540 GEM on the
> HiFive Unleashed board. Revert it.
>
> Signed-off-by: Bin Meng
> ---
>
> drivers/net/macb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> index c99cf66..25f7913 100644
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -643,7 +643,7 @@ static int macb_phy_init(struct macb_device *macb, const
> char *name)
>
> /* First check for GMAC and that it is GiB capable */
> if (gem_is_gigabit_capable(macb)) {
> - lpa = macb_mdio_read(macb, MII_LPA);
> + lpa = macb_mdio_read(macb, MII_STAT1000);
You can do this selectively by having boolean flag in macb_config which is
only set for SiFive Unleashed.
Regards,
Anup
>
> if (lpa & (LPA_1000FULL | LPA_1000HALF | LPA_1000XFULL |
> LPA_1000XHALF)) {
> --
> 2.7.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] armv8: fsl-layerscape: Fix a typo of Layerscape PCIe config entry
From: Hou Zhiqiang The correct config entry is CONFIG_PCIE_LAYERSCAPE, this typo result in skipping the fixup of Linux PCIe DT nodes. Fixes: 4da0e52c9dc0 (armv8: fsl-layerscape: fix config dependency for layerscape pci code) Signed-off-by: Hou Zhiqiang --- arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c index fabe0f0359..a5d6c335d3 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c @@ -435,7 +435,7 @@ void ft_cpu_setup(void *blob, bd_t *bd) do_fixup_by_path_u32(blob, "/sysclk", "clock-frequency", CONFIG_SYS_CLK_FREQ, 1); -#ifdef CONFIG_PCI_LAYERSCAPE +#ifdef CONFIG_PCIE_LAYERSCAPE ft_pci_setup(blob, bd); #endif -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] doc: arch: correct links in x86.rst
On Fri, Aug 16, 2019 at 3:21 AM Heinrich Schuchardt wrote: > > Correctly reference uefi/uefi.rst and uefi/u-boot_on_efi.rst. > > Signed-off-by: Heinrich Schuchardt > --- > doc/arch/x86.rst | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > Reviewed-by: Bin Meng Tested-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] doc: formatting slimbootloader.rst
On Fri, Aug 16, 2019 at 3:02 AM Heinrich Schuchardt wrote: > > Avoid a warning when building the 'make htmldocs' target: > > doc/board/intel/slimbootloader.rst:90: WARNING: Title underline too short. > > Signed-off-by: Heinrich Schuchardt > --- > doc/board/intel/slimbootloader.rst | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Bin Meng Tested-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] easylogo: avoid buffer overrun
On 8/15/19 11:54 PM, Heinrich Schuchardt wrote: Building easylogo with `HOST_TOOLS_ALL=y make tools` results in a build warning due to a possible buffer overrun: tools/easylogo/easylogo.c:453:4: note: ‘sprintf’ output between 7 and 262 bytes into a destination of size 256 sprintf (str, "%s, 0x%02x", app, *dataptr++); ^~~~ Truncate the output to fit into the destination buffer. Signed-off-by: Heinrich Schuchardt Could we change .travis.yml and .gitlab-ci.yml to build all tools? Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 4/5] net: mvpp2: use new MVMDIO driver
From: Nevo Hed
This commit ports mvpp2 to use the recently introduced Marvell MDIO
(MVMDIO) driver. It removes direct interaction with the SMI & XSMI
busses. This commit is based in part on earlier work by
Ken Ma in Marvell's own downstream repo:
https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/c81dc39.
The above refrenced work was based on an MVMDIO implementation that
never made it into U-Boot. With this patch the mvpp2 driver switches
to use the new MVMDIO driver that is based on a more universal
mdio-uclass implementation.
Signed-off-by: Nevo Hed
---
drivers/net/mvpp2.c | 195
1 file changed, 18 insertions(+), 177 deletions(-)
diff --git a/drivers/net/mvpp2.c b/drivers/net/mvpp2.c
index 4ba6f9be3e..cfd119da37 100644
--- a/drivers/net/mvpp2.c
+++ b/drivers/net/mvpp2.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -62,8 +63,6 @@ do {
\
#define MTU1500
#define RX_BUFFER_SIZE (ALIGN(MTU + WRAP, ARCH_DMA_MINALIGN))
-#define MVPP2_SMI_TIMEOUT 1
-
/* RX Fifo Registers */
#define MVPP2_RX_DATA_FIFO_SIZE_REG(port) (0x00 + 4 * (port))
#define MVPP2_RX_ATTR_FIFO_SIZE_REG(port) (0x20 + 4 * (port))
@@ -490,23 +489,8 @@ do {
\
#define MVPP2_QUEUE_NEXT_DESC(q, index) \
(((index) < (q)->last_desc) ? ((index) + 1) : 0)
-/* SMI: 0xc0054 -> offset 0x54 to lms_base */
-#define MVPP21_SMI 0x0054
/* PP2.2: SMI: 0x12a200 -> offset 0x1200 to iface_base */
#define MVPP22_SMI 0x1200
-#define MVPP2_PHY_REG_MASK 0x1f
-/* SMI register fields */
-#define MVPP2_SMI_DATA_OFFS0 /* Data */
-#define MVPP2_SMI_DATA_MASK(0x <<
MVPP2_SMI_DATA_OFFS)
-#define MVPP2_SMI_DEV_ADDR_OFFS16 /* PHY device address */
-#define MVPP2_SMI_REG_ADDR_OFFS21 /* PHY device reg addr*/
-#define MVPP2_SMI_OPCODE_OFFS 26 /* Write/Read opcode */
-#define MVPP2_SMI_OPCODE_READ (1 << MVPP2_SMI_OPCODE_OFFS)
-#define MVPP2_SMI_READ_VALID (1 << 27) /* Read Valid */
-#define MVPP2_SMI_BUSY (1 << 28) /* Busy */
-
-#define MVPP2_PHY_ADDR_MASK0x1f
-#define MVPP2_PHY_REG_MASK 0x1f
/* Additional PPv2.2 offsets */
#define MVPP22_MPCS0x007000
@@ -952,7 +936,6 @@ struct mvpp2_port {
/* Per-port registers' base address */
void __iomem *base;
- void __iomem *mdio_base;
struct mvpp2_rx_queue **rxqs;
struct mvpp2_tx_queue **txqs;
@@ -973,9 +956,8 @@ struct mvpp2_port {
struct phy_device *phy_dev;
phy_interface_t phy_interface;
- int phy_node;
int phyaddr;
- struct mii_dev *bus;
+ struct udevice *mdio_dev;
#ifdef CONFIG_DM_GPIO
struct gpio_desc phy_reset_gpio;
struct gpio_desc phy_tx_disable_gpio;
@@ -4499,8 +4481,8 @@ static void mvpp2_phy_connect(struct udevice *dev, struct
mvpp2_port *port)
struct phy_device *phy_dev;
if (!port->init || port->link == 0) {
- phy_dev = phy_connect(port->bus, port->phyaddr, dev,
- port->phy_interface);
+ phy_dev = dm_mdio_phy_connect(port->mdio_dev, port->phyaddr,
+ dev, port->phy_interface);
/*
* If the phy doesn't match with any existing u-boot drivers the
@@ -4585,7 +4567,7 @@ static int mvpp2_open(struct udevice *dev, struct
mvpp2_port *port)
return err;
}
- if (port->phy_node) {
+ if (port->phyaddr < PHY_MAX_ADDR) {
mvpp2_phy_connect(dev, port);
mvpp2_link_event(port);
} else {
@@ -4724,35 +4706,25 @@ static int phy_info_parse(struct udevice *dev, struct
mvpp2_port *port)
u32 id;
u32 phyaddr = 0;
int phy_mode = -1;
-
- /* Default mdio_base from the same eth base */
- if (port->priv->hw_version == MVPP21)
- port->mdio_base = port->priv->lms_base + MVPP21_SMI;
- else
- port->mdio_base = port->priv->iface_base + MVPP22_SMI;
+ int ret;
phy_node = fdtdec_lookup_phandle(gd->fdt_blob, port_node, "phy");
if (phy_node > 0) {
- ofnode phy_ofnode;
- fdt_addr_t phy_base;
-
+ int parent;
phyaddr = fdtdec_get_int(gd->fdt_blob, phy_node, "reg", 0);
if (phyaddr < 0) {
dev_err(>dev, "could not find phy address\n");
[U-Boot] [PATCH v4 1/5] net: mvpp2x: fix traffic stuck after PHY start error
From: Stefan Chulski
Issue:
- Network stuck if autonegotion fails.
Issue root cause:
- When autonegotiation fails during port open procedure, the packet
processor configuration does not finish and open procedure exits
with error.
- However, this doesn't prevent u-boot network framework from
calling send and receive procedures.
- Using transmit and receive functions of misconfigured packet
processor will cause traffic to get stuck.
Fix:
- Continue packet processor configuration even if autonegotiation
fails. Only error message is triggered in this case.
- Exit transmit and receive functions if there is no PHY link
indication.
- U-boot network framework now calls open procedure again during next
transmit initiation.
Signed-off-by: Stefan Chulski
Reviewed-by: Igal Liberman
Tested-by: Igal Liberman
---
drivers/net/mvpp2.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/net/mvpp2.c b/drivers/net/mvpp2.c
index bd89725e77..f36c8236b1 100644
--- a/drivers/net/mvpp2.c
+++ b/drivers/net/mvpp2.c
@@ -4494,7 +4494,7 @@ static void mvpp2_stop_dev(struct mvpp2_port *port)
gop_port_enable(port, 0);
}
-static int mvpp2_phy_connect(struct udevice *dev, struct mvpp2_port *port)
+static void mvpp2_phy_connect(struct udevice *dev, struct mvpp2_port *port)
{
struct phy_device *phy_dev;
@@ -4504,7 +4504,7 @@ static int mvpp2_phy_connect(struct udevice *dev, struct
mvpp2_port *port)
port->phy_dev = phy_dev;
if (!phy_dev) {
netdev_err(port->dev, "cannot connect to phy\n");
- return -ENODEV;
+ return;
}
phy_dev->supported &= PHY_GBIT_FEATURES;
phy_dev->advertising = phy_dev->supported;
@@ -4516,18 +4516,14 @@ static int mvpp2_phy_connect(struct udevice *dev,
struct mvpp2_port *port)
phy_config(phy_dev);
phy_startup(phy_dev);
- if (!phy_dev->link) {
+ if (!phy_dev->link)
printf("%s: No link\n", phy_dev->dev->name);
- return -1;
- }
-
- port->init = 1;
+ else
+ port->init = 1;
} else {
mvpp2_egress_enable(port);
mvpp2_ingress_enable(port);
}
-
- return 0;
}
static int mvpp2_open(struct udevice *dev, struct mvpp2_port *port)
@@ -4567,10 +4563,7 @@ static int mvpp2_open(struct udevice *dev, struct
mvpp2_port *port)
}
if (port->phy_node) {
- err = mvpp2_phy_connect(dev, port);
- if (err < 0)
- return err;
-
+ mvpp2_phy_connect(dev, port);
mvpp2_link_event(port);
} else {
mvpp2_egress_enable(port);
@@ -5175,6 +5168,10 @@ static int mvpp2_recv(struct udevice *dev, int flags,
uchar **packetp)
struct mvpp2_rx_queue *rxq;
u8 *data;
+ if (port->phy_node)
+ if (!port->phy_dev->link)
+ return 0;
+
/* Process RX packets */
rxq = port->rxqs[0];
@@ -5240,6 +5237,10 @@ static int mvpp2_send(struct udevice *dev, void *packet,
int length)
int tx_done;
int timeout;
+ if (port->phy_node)
+ if (!port->phy_dev->link)
+ return 0;
+
txq = port->txqs[0];
aggr_txq = >priv->aggr_txqs[smp_processor_id()];
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 3/5] arm: dts: armada-cp110-*dtsi: add xmdio nodes
From: Nevo Hed
Based on upstream-linux
See https://github.com/torvalds/linux/commit/f66b2aff.
However made the XSMI register window 0x16 (22) bytes per my reading
of the functional spec. Similar commits in Marvels own repo bump it
to 0x200 (512) bytes but I did not see the reasoning for that.
https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/4d932b4.
Also added device-name attributes to prevent ambiguity in the `mdio`
command.
Signed-off-by: Nevo Hed
---
arch/arm/dts/armada-cp110-master.dtsi | 9 +
arch/arm/dts/armada-cp110-slave.dtsi | 9 +
2 files changed, 18 insertions(+)
diff --git a/arch/arm/dts/armada-cp110-master.dtsi
b/arch/arm/dts/armada-cp110-master.dtsi
index e4c17e9f4b..cd5c974482 100644
--- a/arch/arm/dts/armada-cp110-master.dtsi
+++ b/arch/arm/dts/armada-cp110-master.dtsi
@@ -99,6 +99,15 @@
device-name = "cpm-mdio";
};
+ cpm_xmdio: mdio@12a600 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "marvell,xmdio";
+ reg = <0x12a600 0x16>;
+ status = "disabled";
+ device-name = "cpm-xmdio";
+ };
+
cpm_syscon0: system-controller@44 {
compatible = "marvell,cp110-system-controller0",
"syscon";
diff --git a/arch/arm/dts/armada-cp110-slave.dtsi
b/arch/arm/dts/armada-cp110-slave.dtsi
index 2fbd7b5514..b426a4eb69 100644
--- a/arch/arm/dts/armada-cp110-slave.dtsi
+++ b/arch/arm/dts/armada-cp110-slave.dtsi
@@ -99,6 +99,15 @@
device-name = "cps-mdio";
};
+ cps_xmdio: mdio@12a600 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "marvell,xmdio";
+ reg = <0x12a600 0x16>;
+ status = "disabled";
+ device-name = "cps-xmdio";
+ };
+
cps_syscon0: system-controller@44 {
compatible = "marvell,cp110-system-controller0",
"syscon";
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 0/5] Switch MVPP2 to use new MVMDIO
From: Nevo Hed This patchset includes a couple of commits form Marvell's downstream repo and a change to replace mvpp2's SMI implementation with the new MVMDIO driver. The mvpp2 change is based partially on Ken Ma's mods against an earlier (his) version of MVMDIO that never made it to upstream and has since been re-implemented by Alex Marginean and seems to be in line for inclusion [1]. Puicked a few other mvpp2 patches from the afformentioned Marvell repo as they seemed important yet missing from upstream. Changes since v3: - Squashed the NULL dereference fix - Fixed multi-line comment format - Squashed the two mvpp2.c changes to use MVMDIO tinto a single one that can stand on its own. Changes since v2: - Removed `Reviewed-on` lines from Marvell commits, they are meaningless in upstream U-Boot - Commit messages rewording - Split out Kconfig (select of MVMDIO & DM_MDIO by MVPP2) - reworded heading on dtsi change to match last commit (due to noticing no delegates weere listed on patchworks) Changes since v1: - removes a redaundant fixed-link patch [1] https://patchwork.ozlabs.org/cover/1136769/ Grzegorz Jaszczyk (1): net: mvpp2: mark phy as invalid in case of missing appropriate driver Nevo Hed (3): arm: dts: armada-cp110-*dtsi: add xmdio nodes net: mvpp2: use new MVMDIO driver net: mvpp2: MVPP2 now needs MVMDIO Stefan Chulski (1): net: mvpp2x: fix traffic stuck after PHY start error arch/arm/dts/armada-cp110-master.dtsi | 9 + arch/arm/dts/armada-cp110-slave.dtsi | 9 + drivers/net/Kconfig | 2 + drivers/net/mvpp2.c | 241 ++ 4 files changed, 73 insertions(+), 188 deletions(-) -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 2/5] net: mvpp2: mark phy as invalid in case of missing appropriate driver
From: Grzegorz Jaszczyk
If the phy doesn't match with any existing u-boot drivers, the phy
framework will connect it to the generic one which uid ==
0x. In this case, act as if the phy wouldn't be declared in
dts. Otherwise, in case of 3310 (for which the driver doesn't exist)
the link is marked as always down. Removing phy entry from dts in case
of 3310 is not a good option because it is required for the
phy_fw_down procedure.
This patch fixes the issue with the link always down on MCBIN board.
nhed: added NULL deref test.
Signed-off-by: Grzegorz Jaszczyk
Reviewed-by: Igal Liberman
Tested-by: Igal Liberman
Signed-off-by: Nevo Hed
---
drivers/net/mvpp2.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/net/mvpp2.c b/drivers/net/mvpp2.c
index f36c8236b1..4ba6f9be3e 100644
--- a/drivers/net/mvpp2.c
+++ b/drivers/net/mvpp2.c
@@ -4501,6 +4501,29 @@ static void mvpp2_phy_connect(struct udevice *dev,
struct mvpp2_port *port)
if (!port->init || port->link == 0) {
phy_dev = phy_connect(port->bus, port->phyaddr, dev,
port->phy_interface);
+
+ /*
+* If the phy doesn't match with any existing u-boot drivers the
+* phy framework will connect it to generic one which
+* uid == 0x. In this case act as if the phy wouldn't be
+* declared in dts. Otherwise in case of 3310 (for which the
+* driver doesn't exist) the link will not be correctly
+* detected. Removing phy entry from dts in case of 3310 is not
+* an option because it is required for the phy_fw_down
+* procedure.
+*/
+ if (phy_dev &&
+ phy_dev->drv->uid == 0x) {/* Generic phy */
+ netdev_warn(port->dev,
+ "Marking phy as invalid, link will not be
checked\n");
+ /* set phy_addr to invalid value */
+ port->phyaddr = PHY_MAX_ADDR;
+ mvpp2_egress_enable(port);
+ mvpp2_ingress_enable(port);
+
+ return;
+ }
+
port->phy_dev = phy_dev;
if (!phy_dev) {
netdev_err(port->dev, "cannot connect to phy\n");
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 5/5] net: mvpp2: MVPP2 now needs MVMDIO
From: Nevo Hed Changes to mvpp2.c require the MVMDIO module which in turn uses DM_MDIO. Signed-off-by: Nevo Hed --- drivers/net/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 5fd31b03cf..81f39d0928 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -297,6 +297,8 @@ config MVPP2 bool "Marvell Armada 375/7K/8K network interface support" depends on ARMADA_375 || ARMADA_8K select PHYLIB + select MVMDIO + select DM_MDIO help This driver supports the network interface units in the Marvell ARMADA 375, 7K and 8K SoCs. -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] easylogo: avoid buffer overrun
Building easylogo with `HOST_TOOLS_ALL=y make tools` results in a build warning due to a possible buffer overrun: tools/easylogo/easylogo.c:453:4: note: ‘sprintf’ output between 7 and 262 bytes into a destination of size 256 sprintf (str, "%s, 0x%02x", app, *dataptr++); ^~~~ Truncate the output to fit into the destination buffer. Signed-off-by: Heinrich Schuchardt --- tools/easylogo/easylogo.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/easylogo/easylogo.c b/tools/easylogo/easylogo.c index 4ba86bf760..ed4bf203dd 100644 --- a/tools/easylogo/easylogo.c +++ b/tools/easylogo/easylogo.c @@ -450,7 +450,8 @@ int image_save_header (image_t * image, char *filename, char *varname) default: strcpy (app, str); - sprintf (str, "%s, 0x%02x", app, *dataptr++); + sprintf(str, "%.*s, 0x%02x", (int)sizeof(str) - 7, app, + *dataptr++); col++; count--; break; -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/7] arm: K3: common: Allow for early console functionality
Implement an early console functionality in SPL that can be used before
the main console is being brought up. This helps in situations where the
main console is dependent on System Firmware (SYSFW) being up and running,
which is usually not the case during the very early stages of boot. Using
this early console functionality will allow for an alternate serial port
to be used to support things like UART-based boot and early diagnostic
messages until the main console is ready to get activated.
Signed-off-by: Andreas Dannenberg
---
arch/arm/mach-k3/Kconfig | 21 +
arch/arm/mach-k3/common.c | 26 ++
arch/arm/mach-k3/common.h | 1 +
3 files changed, 48 insertions(+)
diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index 9652c96a78..a878277e39 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -66,6 +66,27 @@ config SYS_K3_BOOT_CORE_ID
int
default 16
+config K3_EARLY_CONS
+ bool "Activate to allow for an early console during SPL"
+ depends on SPL
+ help
+ Turn this option on to enable an early console functionality in SPL
+ before the main console is being brought up. This can be useful in
+ situations where the main console is dependent on System Firmware
+ (SYSFW) being up and running, which is usually not the case during
+ the very early stages of boot. Using this early console functionality
+ will allow for an alternate serial port to be used to support things
+ like UART-based boot and early diagnostic messages until the main
+ console is ready to get activated.
+
+config K3_EARLY_CONS_IDX
+ depends on K3_EARLY_CONS
+ int "Index of serial device to use for SPL early console"
+ default 1
+ help
+ Use this option to set the index of the serial device to be used
+ for the early console during SPL execution.
+
config K3_LOAD_SYSFW
bool
depends on SPL
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index bab5ffdf40..279bd96467 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -27,6 +27,32 @@ struct ti_sci_handle *get_ti_sci_handle(void)
return (struct ti_sci_handle *)ti_sci_get_handle_from_sysfw(dev);
}
+DECLARE_GLOBAL_DATA_PTR;
+
+#ifdef CONFIG_K3_EARLY_CONS
+int early_console_init(void)
+{
+ struct udevice *dev;
+ int ret;
+
+ gd->baudrate = CONFIG_BAUDRATE;
+
+ ret = uclass_get_device_by_seq(UCLASS_SERIAL, CONFIG_K3_EARLY_CONS_IDX,
+ );
+ if (ret) {
+ printf("Error getting serial dev for early console! (%d)\n",
+ ret);
+ return ret;
+ }
+
+ gd->cur_serial_dev = dev;
+ gd->flags |= GD_FLG_SERIAL_READY;
+ gd->have_console = 1;
+
+ return 0;
+}
+#endif
+
#ifdef CONFIG_SYS_K3_SPL_ATF
void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
{
diff --git a/arch/arm/mach-k3/common.h b/arch/arm/mach-k3/common.h
index ac7e80d9af..ab68e14de8 100644
--- a/arch/arm/mach-k3/common.h
+++ b/arch/arm/mach-k3/common.h
@@ -9,3 +9,4 @@
#include
void setup_k3_mpu_regions(void);
+int early_console_init(void);
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/7] Implement UART-based boot of TI K3 AM65x SoCs
This series enables UART-based boot of TI K3 AM65x SoCs by extending the TI K3 System Firmware (SYSFW) loader with support for UART-based loading of SYSFW. This is done by tapping into the existing SPL Y-Modem serial loader framework to accomplish the actual loading functionality. The series also implements a feature called "early console" which allows setting up an alternate full console (as required by Y-Modem) provided through an alternate serial port (a serial port different from what will be used by U-Boot proper/Linux in a system) which can be configured and used prior to SYSFW being available Specifically, the MAIN_UART0 in case of AM654x SoCs can't be used in the early boot process (on R5 SPL) to load SYSFW as it is not clocked. However since the MCU_UART0 is readily available prior to loading SYSFW we use it during the early boot process via said "early console" functionality, and then later switch over to using MAIN_UART0 both for the continued boot process as well as for the actual U-Boot console itself (and Linux, etc.) This series depends on [1] to be able to boot to prompt on the TI AM654x EVM. Sample instructions on how to boot are provided in the updates to the board-specific README. [1] https://patchwork.ozlabs.org/patch/1142068/ Andreas Dannenberg (7): spl: ymodem: Fix FIT loading termination handling spl: ymodem: Make SPL Y-Modem loader framework accessible arm: K3: common: Allow for early console functionality arm: K3: sysfw-loader: Allow loading SYSFW via Y-Modem armv7R: dts: k3: am654: Add MCU_UART0 related definitions configs: am65x_evm_r5: Activate early console functionality board: ti: am65x: Add UART boot procedure in README arch/arm/dts/k3-am654-r5-base-board.dts | 19 +++ arch/arm/mach-k3/Kconfig| 21 arch/arm/mach-k3/common.c | 26 arch/arm/mach-k3/common.h | 1 + arch/arm/mach-k3/sysfw-loader.c | 21 board/ti/am65x/README | 32 + common/spl/spl_ymodem.c | 9 +++ configs/am65x_evm_r5_defconfig | 1 + include/spl.h | 3 +++ 9 files changed, 129 insertions(+), 4 deletions(-) -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/7] spl: ymodem: Fix FIT loading termination handling
During FIT reading through ymodem_read_fit() the function
xyzModem_stream_read() is being used which returns zero once the end
of a stream has been reached. This could lead to an premature exit from
ymodem_read_fit() with certain-sized FIT images reporting that zero
bytes overall were read. Such a premature exit would then result in an
-EIO failure being triggered within the spl_load_simple_fit() caller
function and ultimately lead to a boot failure.
Fix this logic by simply aborting the stream read loops and continuing
with the regular code flow which ultimately would lead to returning
the number of bytes to be read ('size') as expected by the callers of
ymodem_read_fit().
Fixes: fa715193c083 ("spl: Add an option to load a FIT containing U-Boot from
UART")
Signed-off-by: Andreas Dannenberg
---
common/spl/spl_ymodem.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/common/spl/spl_ymodem.c b/common/spl/spl_ymodem.c
index 20f4260062..8ad580d8ae 100644
--- a/common/spl/spl_ymodem.c
+++ b/common/spl/spl_ymodem.c
@@ -44,7 +44,8 @@ static ulong ymodem_read_fit(struct spl_load_info *load,
ulong offset,
while (info->image_read < offset) {
res = xyzModem_stream_read(buf, BUF_SIZE, );
if (res <= 0)
- return res;
+ break;
+
info->image_read += res;
}
@@ -57,7 +58,7 @@ static ulong ymodem_read_fit(struct spl_load_info *load,
ulong offset,
while (info->image_read < offset + size) {
res = xyzModem_stream_read(buf, BUF_SIZE, );
if (res <= 0)
- return res;
+ break;
memcpy(addr, buf, res);
info->image_read += res;
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/7] arm: K3: sysfw-loader: Allow loading SYSFW via Y-Modem
In order to allow booting TI K3 family SoCs via Y-Modem add support for
loading System Firmware by tapping into the associated SPL core loader
function.
In this context also make sure a console is available and if not go
ahead and activate the early console feature which allows bringing up
an alternate full console before the main console is activated. Such
an alternate console is typically setup in a way that the associated
UART can be fully initialized prior to SYSFW services being available.
Signed-off-by: Andreas Dannenberg
---
arch/arm/mach-k3/sysfw-loader.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/mach-k3/sysfw-loader.c b/arch/arm/mach-k3/sysfw-loader.c
index 7a482bdc8a..5903bbe12a 100644
--- a/arch/arm/mach-k3/sysfw-loader.c
+++ b/arch/arm/mach-k3/sysfw-loader.c
@@ -12,6 +12,9 @@
#include
#include
#include
+#include "common.h"
+
+DECLARE_GLOBAL_DATA_PTR;
/* Name of the FIT image nodes for SYSFW and its config data */
#define SYSFW_FIRMWARE "sysfw.bin"
@@ -214,6 +217,24 @@ void k3_sysfw_loader(void (*config_pm_done_callback)(void))
0);
#endif
break;
+#endif
+#if CONFIG_IS_ENABLED(YMODEM_SUPPORT)
+ case BOOT_DEVICE_UART:
+#ifdef CONFIG_K3_EARLY_CONS
+ /*
+* Establish a serial console if not yet available as required
+* for UART-based boot. For this use the early console feature
+* that allows setting up a UART for use before SYSFW has been
+* brought up. Note that the associated UART module's clocks
+* must have gotten enabled by the ROM bootcode which will be
+* the case when continuing to boot serially from the same
+* UART that the ROM loaded the initial bootloader from.
+*/
+ if (!gd->have_console)
+ early_console_init();
+#endif
+ ret = spl_ymodem_load_image(_image, );
+ break;
#endif
default:
panic("Loading SYSFW image from device %u not supported!\n",
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 5/7] armv7R: dts: k3: am654: Add MCU_UART0 related definitions
Although we currently use the MAIN_UART0 for R5 SPL console output there
are cases where we require access to the MCU_UART0 as well for example in
case of UART-based Y-Modem boot. To support these scenarios add related
DTS definitions to be able to use that UART early on.
Signed-off-by: Andreas Dannenberg
---
arch/arm/dts/k3-am654-r5-base-board.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/dts/k3-am654-r5-base-board.dts
b/arch/arm/dts/k3-am654-r5-base-board.dts
index 7ed307f0d8..e31ed4fe64 100644
--- a/arch/arm/dts/k3-am654-r5-base-board.dts
+++ b/arch/arm/dts/k3-am654-r5-base-board.dts
@@ -16,6 +16,7 @@
aliases {
serial0 = _uart0;
+ serial1 = _uart0;
serial2 = _uart0;
};
@@ -118,6 +119,14 @@
status = "okay";
};
+_uart0 {
+ u-boot,dm-spl;
+ pinctrl-names = "default";
+ pinctrl-0 = <_uart0_pins_default>;
+ clock-frequency = <4800>;
+ status = "okay";
+};
+
_uart0 {
power-domains = <_pds 146 TI_SCI_PD_SHARED>;
};
@@ -141,6 +150,16 @@
u-boot,dm-spl;
};
+ mcu_uart0_pins_default: mcu_uart0_pins_default {
+ pinctrl-single,pins = <
+ AM65X_WKUP_IOPAD(0x0044, PIN_INPUT, 4) /* (P4)
MCU_OSPI1_D1.MCU_UART0_RXD */
+ AM65X_WKUP_IOPAD(0x0048, PIN_OUTPUT, 4) /* (P5)
MCU_OSPI1_D2.MCU_UART0_TXD */
+ AM65X_WKUP_IOPAD(0x004C, PIN_INPUT, 4) /* (P1)
MCU_OSPI1_D3.MCU_UART0_CTSn */
+ AM65X_WKUP_IOPAD(0x0054, PIN_OUTPUT, 4) /* (N3)
MCU_OSPI1_CSn1.MCU_UART0_RTSn */
+ >;
+ u-boot,dm-spl;
+ };
+
wkup_i2c0_pins_default: wkup-i2c0-pins-default {
pinctrl-single,pins = <
AM65X_WKUP_IOPAD(0x00e0, PIN_INPUT, 0) /* (AC7)
WKUP_I2C0_SCL */
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 7/7] board: ti: am65x: Add UART boot procedure in README
am65x ROM support booting over UART. And U-Boot built for am65x EVM supports UART boot as well. Add the UART boot procedure into the README also providing a corresponding example command sequence for execution on a host PC. Signed-off-by: Andreas Dannenberg --- board/ti/am65x/README | 32 1 file changed, 32 insertions(+) diff --git a/board/ti/am65x/README b/board/ti/am65x/README index 16384e05ea..2e3fd9c4a8 100644 --- a/board/ti/am65x/README +++ b/board/ti/am65x/README @@ -261,3 +261,35 @@ To boot kernel from eMMC, use the following commands: => setenv mmcdev 0 => setenv bootpart 0 => boot + +UART: +- +ROM supports booting from MCU_UART0 via X-Modem protocol. The entire UART-based +boot process up to U-Boot (proper) prompt goes through different stages and uses +different UART peripherals as follows: + + WHO | Loading WHAT | HW Module | Protocol +--+---+-+ +Boot ROM | tiboot3.bin | MCU_UART0 | X-Modem(*) +R5 SPL| sysfw.itb| MCU_UART0 | Y-Modem(*) +R5 SPL| tispl.bin| MAIN_UART0 | Y-Modem +A53 SPL | u-boot.img | MAIN_UART0 | Y-Modem + +(*) Note that in addition to X/Y-Modem related protocol timeouts the DMSC +watchdog timeout of 3min (typ.) needs to be observed until System Firmware +is fully loaded (from sysfw.itb) and started. + +Example bash script sequence for running on a Linux host PC feeding all boot +artifacts needed to the device: + +MCU_DEV=/dev/ttyUSB1 +MAIN_DEV=/dev/ttyUSB0 + +stty -F $MCU_DEV 115200 cs8 -cstopb -parenb +stty -F $MAIN_DEV 115200 cs8 -cstopb -parenb + +sb --xmodem tiboot3.bin > $MCU_DEV < $MCU_DEV +sb --ymodem sysfw.itb > $MCU_DEV < $MCU_DEV +sb --ymodem tispl.bin > $MAIN_DEV < $MAIN_DEV +sleep 1 +sb --xmodem u-boot.img > $MAIN_DEV < $MAIN_DEV -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 6/7] configs: am65x_evm_r5: Activate early console functionality
Activate early console functionality on AM654x devices to allow for an alternate serial port to be used to support UART-based boot. This is so that System Firmware (SYSFW) can get loaded over the serial port prior to the main console being brought up and made available. Signed-off-by: Andreas Dannenberg --- configs/am65x_evm_r5_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/am65x_evm_r5_defconfig b/configs/am65x_evm_r5_defconfig index c59b7d98dc..e372599080 100644 --- a/configs/am65x_evm_r5_defconfig +++ b/configs/am65x_evm_r5_defconfig @@ -5,6 +5,7 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_SYS_MALLOC_F_LEN=0x55000 CONFIG_SOC_K3_AM6=y +CONFIG_K3_EARLY_CONS=y CONFIG_TARGET_AM654_R5_EVM=y CONFIG_SPL_MMC_SUPPORT=y CONFIG_SPL_SERIAL_SUPPORT=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/7] spl: ymodem: Make SPL Y-Modem loader framework accessible
Expose SPL's Y-Modem core loader function via the common SPL header
file so it can be re-used for purposes other than loading U-Boot itself.
Signed-off-by: Andreas Dannenberg
---
common/spl/spl_ymodem.c | 4 ++--
include/spl.h | 3 +++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/common/spl/spl_ymodem.c b/common/spl/spl_ymodem.c
index 8ad580d8ae..c02c05624d 100644
--- a/common/spl/spl_ymodem.c
+++ b/common/spl/spl_ymodem.c
@@ -68,8 +68,8 @@ static ulong ymodem_read_fit(struct spl_load_info *load,
ulong offset,
return size;
}
-static int spl_ymodem_load_image(struct spl_image_info *spl_image,
-struct spl_boot_device *bootdev)
+int spl_ymodem_load_image(struct spl_image_info *spl_image,
+ struct spl_boot_device *bootdev)
{
ulong size = 0;
int err;
diff --git a/include/spl.h b/include/spl.h
index a90f971a23..a2c6278c00 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -356,6 +356,9 @@ int spl_mmc_load(struct spl_image_info *spl_image,
int raw_part,
unsigned long raw_sect);
+int spl_ymodem_load_image(struct spl_image_info *spl_image,
+ struct spl_boot_device *bootdev);
+
/**
* spl_invoke_atf - boot using an ARM trusted firmware image
*/
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] libavb: Fix build warnings after updating the lib
After updating libavb to most recent version from AOSP/master, two new
warnings appear:
Warning #1:
lib/libavb/avb_cmdline.c: In function 'avb_append_options':
lib/libavb/avb_cmdline.c:365:15: warning: 'dm_verity_mode' may be
used uninitialized in this function
[-Wmaybe-uninitialized]
new_ret = avb_replace(
^~~~
slot_data->cmdline, "$(ANDROID_VERITY_MODE)", dm_verity_mode);
~
lib/libavb/avb_cmdline.c:374:8: warning: 'verity_mode' may be used
uninitialized in this function
[-Wmaybe-uninitialized]
if (!cmdline_append_option(
^~
slot_data, "androidboot.veritymode", verity_mode)) {
~
Warning #2:
lib/libavb/avb_slot_verify.c: In function 'avb_slot_verify':
lib/libavb/avb_slot_verify.c:1349:23: warning: 'ret' may be used
uninitialized in this function
[-Wmaybe-uninitialized]
AvbSlotVerifyResult ret;
^~~
Fix those by providing default return values to affected functions.
Signed-off-by: Sam Protsenko
---
lib/libavb/avb_cmdline.c | 3 ++-
lib/libavb/avb_slot_verify.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/lib/libavb/avb_cmdline.c b/lib/libavb/avb_cmdline.c
index cb5b98e423..684c512bb9 100644
--- a/lib/libavb/avb_cmdline.c
+++ b/lib/libavb/avb_cmdline.c
@@ -357,7 +357,8 @@ AvbSlotVerifyResult avb_append_options(
// Should never get here because MANAGED_RESTART_AND_EIO is
// remapped by avb_manage_hashtree_error_mode().
avb_assert_not_reached();
-break;
+ret = AVB_SLOT_VERIFY_RESULT_ERROR_INVALID_ARGUMENT;
+goto out;
default:
ret = AVB_SLOT_VERIFY_RESULT_ERROR_INVALID_ARGUMENT;
goto out;
diff --git a/lib/libavb/avb_slot_verify.c b/lib/libavb/avb_slot_verify.c
index 5d400b38aa..c0defdf9c9 100644
--- a/lib/libavb/avb_slot_verify.c
+++ b/lib/libavb/avb_slot_verify.c
@@ -1346,7 +1346,7 @@ AvbSlotVerifyResult avb_slot_verify(AvbOps* ops,
AvbSlotVerifyFlags flags,
AvbHashtreeErrorMode hashtree_error_mode,
AvbSlotVerifyData** out_data) {
- AvbSlotVerifyResult ret;
+ AvbSlotVerifyResult ret = AVB_SLOT_VERIFY_RESULT_ERROR_INVALID_ARGUMENT;
AvbSlotVerifyData* slot_data = NULL;
AvbAlgorithmType algorithm_type = AVB_ALGORITHM_TYPE_NONE;
bool using_boot_for_vbmeta = false;
--
2.23.0.rc1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] libavb: Update libavb to current AOSP master
Update libavb to commit 5fbb42a189aa in AOSP/master, because new version
has support for super partition [1], which we need for implementing
Android dynamic partitions. All changes from previous patches for libavb
in U-Boot are accounted for in this commit:
- commit ecc6f6bea6a2 ("libavb: Handle wrong hashtree_error_mode in
avb_append_options()")
- commit 897a1d947e7e ("libavb: Update SPDX tag style")
- commit d8f9d2af96b3 ("avb2.0: add Android Verified Boot 2.0 library")
Tested on X15:
## Android Verified Boot 2.0 version 1.1.0
read_is_device_unlocked not supported yet
read_rollback_index not supported yet
read_is_device_unlocked not supported yet
Verification passed successfully
AVB verification OK.
Unit test passes:
$ ./test/py/test.py --bd sandbox --build -k test_avb
test/py/tests/test_android/test_avb.py ss..s.
[1]
https://android.googlesource.com/platform/external/avb/+/49936b4c0109411fdd38bd4ba3a32a01c40439a9
Signed-off-by: Sam Protsenko
---
lib/libavb/avb_cmdline.c | 52 ++-
lib/libavb/avb_cmdline.h | 4 +-
lib/libavb/avb_descriptor.c| 11 +-
lib/libavb/avb_ops.h | 41 ++-
lib/libavb/avb_sha.h | 12 +-
lib/libavb/avb_sha256.c| 36 +-
lib/libavb/avb_sha512.c| 22 +-
lib/libavb/avb_slot_verify.c | 652 +
lib/libavb/avb_slot_verify.h | 59 ++-
lib/libavb/avb_sysdeps.h | 8 +
lib/libavb/avb_sysdeps_posix.c | 16 +-
lib/libavb/avb_vbmeta_image.c | 11 +-
12 files changed, 710 insertions(+), 214 deletions(-)
diff --git a/lib/libavb/avb_cmdline.c b/lib/libavb/avb_cmdline.c
index d246699272..cb5b98e423 100644
--- a/lib/libavb/avb_cmdline.c
+++ b/lib/libavb/avb_cmdline.c
@@ -39,6 +39,14 @@ char* avb_sub_cmdline(AvbOps* ops,
char part_name[AVB_PART_NAME_MAX_SIZE];
char guid_buf[37];
+/* Don't attempt to query the partition guid unless its search string is
+ * present in the command line. Note: the original cmdline is used here,
+ * not the replaced one. See b/116010959.
+ */
+if (avb_strstr(cmdline, replace_str[n]) == NULL) {
+ continue;
+}
+
if (!avb_str_concat(part_name,
sizeof part_name,
part_name_str[n],
@@ -70,7 +78,15 @@ char* avb_sub_cmdline(AvbOps* ops,
}
}
- avb_assert(ret != NULL);
+ /* It's possible there is no _PARTUUID for replacement above.
+ * Duplicate cmdline to ret for additional substitutions below.
+ */
+ if (ret == NULL) {
+ret = avb_strdup(cmdline);
+if (ret == NULL) {
+ goto fail;
+}
+ }
/* Replace any additional substitutions. */
if (additional_substitutions != NULL) {
@@ -198,21 +214,27 @@ static int cmdline_append_hex(AvbSlotVerifyData*
slot_data,
AvbSlotVerifyResult avb_append_options(
AvbOps* ops,
+AvbSlotVerifyFlags flags,
AvbSlotVerifyData* slot_data,
AvbVBMetaImageHeader* toplevel_vbmeta,
AvbAlgorithmType algorithm_type,
-AvbHashtreeErrorMode hashtree_error_mode) {
+AvbHashtreeErrorMode hashtree_error_mode,
+AvbHashtreeErrorMode resolved_hashtree_error_mode) {
AvbSlotVerifyResult ret;
const char* verity_mode;
bool is_device_unlocked;
AvbIOResult io_ret;
- /* Add androidboot.vbmeta.device option. */
- if (!cmdline_append_option(slot_data,
- "androidboot.vbmeta.device",
- "PARTUUID=$(ANDROID_VBMETA_PARTUUID)")) {
-ret = AVB_SLOT_VERIFY_RESULT_ERROR_OOM;
-goto out;
+ /* Add androidboot.vbmeta.device option... except if not using a vbmeta
+ * partition since it doesn't make sense in that case.
+ */
+ if (!(flags & AVB_SLOT_VERIFY_FLAGS_NO_VBMETA_PARTITION)) {
+if (!cmdline_append_option(slot_data,
+ "androidboot.vbmeta.device",
+ "PARTUUID=$(ANDROID_VBMETA_PARTUUID)")) {
+ ret = AVB_SLOT_VERIFY_RESULT_ERROR_OOM;
+ goto out;
+}
}
/* Add androidboot.vbmeta.avb_version option. */
@@ -304,7 +326,7 @@ AvbSlotVerifyResult avb_append_options(
const char* dm_verity_mode;
char* new_ret;
-switch (hashtree_error_mode) {
+switch (resolved_hashtree_error_mode) {
case AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE:
if (!cmdline_append_option(
slot_data, "androidboot.vbmeta.invalidate_on_error", "yes")) {
@@ -331,6 +353,11 @@ AvbSlotVerifyResult avb_append_options(
verity_mode = "logging";
dm_verity_mode = "ignore_corruption";
break;
+ case AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO:
+// Should never get here because MANAGED_RESTART_AND_EIO is
+// remapped by avb_manage_hashtree_error_mode().
+avb_assert_not_reached();
+break;
default:
ret = AVB_SLOT_VERIFY_RESULT_ERROR_INVALID_ARGUMENT;
goto out;
@@ -349,6 +376,13 @@
[U-Boot] [PATCH v3 2/4] mmc: Add Aspeed SD controller driver
Add support for the Aspeed SD host controller engine.
Signed-off-by: Eddie James
---
arch/arm/include/asm/gpio.h | 3 +-
drivers/mmc/Kconfig | 11 ++
drivers/mmc/Makefile| 1 +
drivers/mmc/aspeed_sdhci.c | 90 +
4 files changed, 104 insertions(+), 1 deletion(-)
create mode 100644 drivers/mmc/aspeed_sdhci.c
diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h
index 370031f..38a5922 100644
--- a/arch/arm/include/asm/gpio.h
+++ b/arch/arm/include/asm/gpio.h
@@ -1,6 +1,7 @@
#if !defined(CONFIG_ARCH_UNIPHIER) && !defined(CONFIG_ARCH_STI) && \
!defined(CONFIG_ARCH_K3) && !defined(CONFIG_ARCH_BCM6858) && \
- !defined(CONFIG_ARCH_BCM63158) && !defined(CONFIG_ARCH_ROCKCHIP)
+ !defined(CONFIG_ARCH_BCM63158) && !defined(CONFIG_ARCH_ROCKCHIP) && \
+ !defined(CONFIG_ARCH_ASPEED)
#include
#endif
#include
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index c6812f6..536f66a 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -421,6 +421,17 @@ config SPL_MMC_SDHCI_ADMA
This enables support for the ADMA (Advanced DMA) defined
in the SD Host Controller Standard Specification Version 3.00 in SPL.
+config MMC_SDHCI_ASPEED
+ bool "Aspeed SDHCI controller"
+ depends on ARCH_ASPEED
+ depends on DM_MMC
+ depends on MMC_SDHCI
+ help
+ Enables support for the Aspeed SDHCI 2.0 controller present on Aspeed
+ SoCs. This device is compatible with SD 3.0 and/or MMC 4.3
+ specifications. On the AST2600, the device is also compatible with
+ MMC 5.1 and eMMC 3.0.
+
config MMC_SDHCI_ATMEL
bool "Atmel SDHCI controller support"
depends on ARCH_AT91
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 6cc018b..5594195 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_JZ47XX_MMC) += jz_mmc.o
# SDHCI
obj-$(CONFIG_MMC_SDHCI)+= sdhci.o
+obj-$(CONFIG_MMC_SDHCI_ASPEED) += aspeed_sdhci.o
obj-$(CONFIG_MMC_SDHCI_ATMEL) += atmel_sdhci.o
obj-$(CONFIG_MMC_SDHCI_BCM2835)+= bcm2835_sdhci.o
obj-$(CONFIG_MMC_SDHCI_BCMSTB) += bcmstb_sdhci.o
diff --git a/drivers/mmc/aspeed_sdhci.c b/drivers/mmc/aspeed_sdhci.c
new file mode 100644
index 000..1321ec3
--- /dev/null
+++ b/drivers/mmc/aspeed_sdhci.c
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019 IBM Corp.
+ * Eddie James
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+struct aspeed_sdhci_plat {
+ struct mmc_config cfg;
+ struct mmc mmc;
+};
+
+static int aspeed_sdhci_probe(struct udevice *dev)
+{
+ struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
+ struct aspeed_sdhci_plat *plat = dev_get_platdata(dev);
+ struct sdhci_host *host = dev_get_priv(dev);
+ u32 max_clk;
+ struct clk clk;
+ int ret;
+
+ ret = clk_get_by_index(dev, 0, );
+ if (ret)
+ return ret;
+
+ ret = clk_enable();
+ if (ret)
+ goto free;
+
+ host->name = dev->name;
+ host->ioaddr = (void *)devfdt_get_addr(dev);
+
+ max_clk = clk_get_rate();
+ if (IS_ERR_VALUE(max_clk)) {
+ ret = max_clk;
+ goto err;
+ }
+
+ host->max_clk = max_clk;
+ host->mmc = >mmc;
+ host->mmc->dev = dev;
+ host->mmc->priv = host;
+ upriv->mmc = host->mmc;
+
+ ret = sdhci_setup_cfg(>cfg, host, 0, 0);
+ if (ret)
+ goto err;
+
+ ret = sdhci_probe(dev);
+ if (ret)
+ goto err;
+
+ return 0;
+
+err:
+ clk_disable();
+free:
+ clk_free();
+ return ret;
+}
+
+static int aspeed_sdhci_bind(struct udevice *dev)
+{
+ struct aspeed_sdhci_plat *plat = dev_get_platdata(dev);
+
+ return sdhci_bind(dev, >mmc, >cfg);
+}
+
+static const struct udevice_id aspeed_sdhci_ids[] = {
+ { .compatible = "aspeed,ast2400-sdhci" },
+ { .compatible = "aspeed,ast2500-sdhci" },
+ { .compatible = "aspeed,ast2600-sdhci" },
+ { }
+};
+
+U_BOOT_DRIVER(aspeed_sdhci_drv) = {
+ .name = "aspeed_sdhci",
+ .id = UCLASS_MMC,
+ .of_match = aspeed_sdhci_ids,
+ .ops= _ops,
+ .bind = aspeed_sdhci_bind,
+ .probe = aspeed_sdhci_probe,
+ .priv_auto_alloc_size = sizeof(struct sdhci_host),
+ .platdata_auto_alloc_size = sizeof(struct aspeed_sdhci_plat),
+};
--
1.8.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 4/4] ARM: dts: ast2500: Add SDHCI nodes
Add nodes for the Aspeed SD controllers with their necessary properties.
Reviewed-by: Cédric Le Goater
Signed-off-by: Eddie James
---
arch/arm/dts/ast2500-evb.dts | 14 ++
arch/arm/dts/ast2500-u-boot.dtsi | 16
2 files changed, 30 insertions(+)
diff --git a/arch/arm/dts/ast2500-evb.dts b/arch/arm/dts/ast2500-evb.dts
index ebf44fd..4796ed4 100644
--- a/arch/arm/dts/ast2500-evb.dts
+++ b/arch/arm/dts/ast2500-evb.dts
@@ -59,3 +59,17 @@
pinctrl-names = "default";
pinctrl-0 = <_mac2link_default _mdio2_default>;
};
+
+ {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_sd1_default>;
+};
+
+ {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_sd2_default>;
+};
diff --git a/arch/arm/dts/ast2500-u-boot.dtsi b/arch/arm/dts/ast2500-u-boot.dtsi
index 7f80bad..8ac4215 100644
--- a/arch/arm/dts/ast2500-u-boot.dtsi
+++ b/arch/arm/dts/ast2500-u-boot.dtsi
@@ -34,6 +34,22 @@
apb {
u-boot,dm-pre-reloc;
+
+ sdhci0: sdhci@1e740100 {
+ compatible = "aspeed,ast2500-sdhci";
+ reg = <0x1e740100>;
+ #reset-cells = <1>;
+ clocks = < BCLK_SDCLK>;
+ resets = < AST_RESET_SDIO>;
+ };
+
+ sdhci1: sdhci@1e740200 {
+ compatible = "aspeed,ast2500-sdhci";
+ reg = <0x1e740200>;
+ #reset-cells = <1>;
+ clocks = < BCLK_SDCLK>;
+ resets = < AST_RESET_SDIO>;
+ };
};
};
--
1.8.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 0/4] ARM: Aspeed: Add SD host controller driver
This series adds support for the SD host controller on the Aspeed ast2xxx SocS. It also enables MMC and the SD controller for the ast2500 EVB. Changes since v2: - Remove mmc_initialize call in the ast2500 board init - Add OF_CONTROL to the ast2500 EVB configuration - Fix the clock-getting code in the driver probe function Changes since v1: - Split the patch up - Add defconfig and devicetree changes Eddie James (4): clk: aspeed: Add support for SD clock mmc: Add Aspeed SD controller driver configs: AST2500 EVB: Enable SD controller ARM: dts: ast2500: Add SDHCI nodes arch/arm/dts/ast2500-evb.dts | 14 arch/arm/dts/ast2500-u-boot.dtsi | 16 + arch/arm/include/asm/arch-aspeed/scu_ast2500.h | 3 + arch/arm/include/asm/gpio.h| 3 +- configs/evb-ast2500_defconfig | 8 +++ drivers/clk/aspeed/clk_ast2500.c | 27 drivers/mmc/Kconfig| 11 drivers/mmc/Makefile | 1 + drivers/mmc/aspeed_sdhci.c | 90 ++ drivers/pinctrl/aspeed/pinctrl_ast2500.c | 2 + 10 files changed, 174 insertions(+), 1 deletion(-) create mode 100644 drivers/mmc/aspeed_sdhci.c -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 3/4] configs: AST2500 EVB: Enable SD controller
Enable the MMC subsystem and the Aspeed SD controller. Also enable the use of the device tree for probing the controller. Signed-off-by: Eddie James --- configs/evb-ast2500_defconfig | 8 1 file changed, 8 insertions(+) diff --git a/configs/evb-ast2500_defconfig b/configs/evb-ast2500_defconfig index 59d41cb..b47ca5b 100644 --- a/configs/evb-ast2500_defconfig +++ b/configs/evb-ast2500_defconfig @@ -16,6 +16,7 @@ CONFIG_HUSH_PARSER=y CONFIG_CMD_I2C=y CONFIG_CMD_DHCP=y CONFIG_CMD_MII=y +CONFIG_CMD_MMC=y CONFIG_CMD_PING=y CONFIG_DEFAULT_DEVICE_TREE="ast2500-evb" CONFIG_NET_RANDOM_ETHADDR=y @@ -36,3 +37,10 @@ CONFIG_SYS_NS16550=y CONFIG_SYSRESET=y CONFIG_TIMER=y CONFIG_WDT=y +CONFIG_MMC=y +CONFIG_DM_MMC=y +CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_ASPEED=y +CONFIG_MMC_VERBOSE=y +CONFIG_OF_CONTROL=y +CONFIG_OF_EMBED=y -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/4] clk: aspeed: Add support for SD clock
Add code to enable the SD clock on the ast2500 SoC.
Reviewed-by: Cédric Le Goater
Signed-off-by: Eddie James
---
arch/arm/include/asm/arch-aspeed/scu_ast2500.h | 3 +++
drivers/clk/aspeed/clk_ast2500.c | 27 ++
drivers/pinctrl/aspeed/pinctrl_ast2500.c | 2 ++
3 files changed, 32 insertions(+)
diff --git a/arch/arm/include/asm/arch-aspeed/scu_ast2500.h
b/arch/arm/include/asm/arch-aspeed/scu_ast2500.h
index 4988ced..8db4901 100644
--- a/arch/arm/include/asm/arch-aspeed/scu_ast2500.h
+++ b/arch/arm/include/asm/arch-aspeed/scu_ast2500.h
@@ -22,6 +22,8 @@
#define SCU_MPLL_POST_MASK (0x3f << SCU_MPLL_POST_SHIFT)
#define SCU_PCLK_DIV_SHIFT 23
#define SCU_PCLK_DIV_MASK (7 << SCU_PCLK_DIV_SHIFT)
+#define SCU_SDCLK_DIV_SHIFT12
+#define SCU_SDCLK_DIV_MASK (7 << SCU_SDCLK_DIV_SHIFT)
#define SCU_HPLL_DENUM_SHIFT 0
#define SCU_HPLL_DENUM_MASK0x1f
#define SCU_HPLL_NUM_SHIFT 5
@@ -107,6 +109,7 @@
#define SCU_CLKSTOP_MAC1 (1 << 20)
#define SCU_CLKSTOP_MAC2 (1 << 21)
+#define SCU_CLKSTOP_SDCLK (1 << 27)
#define SCU_D2PLL_EXT1_OFF (1 << 0)
#define SCU_D2PLL_EXT1_BYPASS (1 << 1)
diff --git a/drivers/clk/aspeed/clk_ast2500.c b/drivers/clk/aspeed/clk_ast2500.c
index dbee13a..9249cf9 100644
--- a/drivers/clk/aspeed/clk_ast2500.c
+++ b/drivers/clk/aspeed/clk_ast2500.c
@@ -143,6 +143,17 @@ static ulong ast2500_clk_get_rate(struct clk *clk)
rate = rate / apb_div;
}
break;
+ case BCLK_SDCLK:
+ {
+ ulong apb_div = 4 + 4 * ((readl(>scu->clk_sel1)
+ & SCU_SDCLK_DIV_MASK)
+>> SCU_SDCLK_DIV_SHIFT);
+ rate = ast2500_get_hpll_rate(clkin,
+readl(>
+ scu->h_pll_param));
+ rate = rate / apb_div;
+ }
+ break;
case PCLK_UART1:
rate = ast2500_get_uart_clk_rate(priv->scu, 1);
break;
@@ -436,6 +447,22 @@ static int ast2500_clk_enable(struct clk *clk)
struct ast2500_clk_priv *priv = dev_get_priv(clk->dev);
switch (clk->id) {
+ case BCLK_SDCLK:
+ if (readl(>scu->clk_stop_ctrl1) & SCU_CLKSTOP_SDCLK) {
+ ast_scu_unlock(priv->scu);
+
+ setbits_le32(>scu->sysreset_ctrl1,
+SCU_SYSRESET_SDIO);
+ udelay(100);
+ clrbits_le32(>scu->clk_stop_ctrl1,
+SCU_CLKSTOP_SDCLK);
+ mdelay(10);
+ clrbits_le32(>scu->sysreset_ctrl1,
+SCU_SYSRESET_SDIO);
+
+ ast_scu_lock(priv->scu);
+ }
+ break;
/*
* For MAC clocks the clock rate is
* configured based on whether RGMII or RMII mode has been selected
diff --git a/drivers/pinctrl/aspeed/pinctrl_ast2500.c
b/drivers/pinctrl/aspeed/pinctrl_ast2500.c
index ed333b9..a6e9c0d 100644
--- a/drivers/pinctrl/aspeed/pinctrl_ast2500.c
+++ b/drivers/pinctrl/aspeed/pinctrl_ast2500.c
@@ -58,6 +58,8 @@ static const struct ast2500_group_config ast2500_groups[] = {
{ "MDIO1", 3, (1 << 31) | (1 << 30) },
{ "MAC2LINK", 1, (1 << 1) },
{ "MDIO2", 5, (1 << 2) },
+ { "SD1", 5, (1 << 0) },
+ { "SD2", 5, (1 << 1) },
};
static int ast2500_pinctrl_get_groups_count(struct udevice *dev)
--
1.8.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] mmc: Add Aspeed SD controller driver
On 8/14/19 10:18 AM, Cédric Le Goater wrote:
On 13/08/2019 21:31, Eddie James wrote:
Add support for the Aspeed SD host controller engine.
It looks correct and simple enough. Some comments below.
Signed-off-by: Eddie James
---
drivers/mmc/Kconfig| 11 +++
drivers/mmc/Makefile | 1 +
drivers/mmc/aspeed_sdhci.c | 78 ++
3 files changed, 90 insertions(+)
create mode 100644 drivers/mmc/aspeed_sdhci.c
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index c6812f6..536f66a 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -421,6 +421,17 @@ config SPL_MMC_SDHCI_ADMA
This enables support for the ADMA (Advanced DMA) defined
in the SD Host Controller Standard Specification Version 3.00 in SPL.
+config MMC_SDHCI_ASPEED
+ bool "Aspeed SDHCI controller"
+ depends on ARCH_ASPEED
+ depends on DM_MMC
+ depends on MMC_SDHCI
+ help
+ Enables support for the Aspeed SDHCI 2.0 controller present on Aspeed
+ SoCs. This device is compatible with SD 3.0 and/or MMC 4.3
+ specifications. On the AST2600, the device is also compatible with
+ MMC 5.1 and eMMC 3.0.
+
config MMC_SDHCI_ATMEL
bool "Atmel SDHCI controller support"
depends on ARCH_AT91
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 6cc018b..5594195 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_JZ47XX_MMC) += jz_mmc.o
# SDHCI
obj-$(CONFIG_MMC_SDHCI) += sdhci.o
+obj-$(CONFIG_MMC_SDHCI_ASPEED) += aspeed_sdhci.o
obj-$(CONFIG_MMC_SDHCI_ATMEL) += atmel_sdhci.o
obj-$(CONFIG_MMC_SDHCI_BCM2835) += bcm2835_sdhci.o
obj-$(CONFIG_MMC_SDHCI_BCMSTB)+= bcmstb_sdhci.o
diff --git a/drivers/mmc/aspeed_sdhci.c b/drivers/mmc/aspeed_sdhci.c
new file mode 100644
index 000..c292c42
--- /dev/null
+++ b/drivers/mmc/aspeed_sdhci.c
@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019 IBM Corp.
+ * Eddie James
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+struct aspeed_sdhci_plat {
+ struct mmc_config cfg;
+ struct mmc mmc;
+};
+
+static int aspeed_sdhci_probe(struct udevice *dev)
+{
+ struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
+ struct aspeed_sdhci_plat *plat = dev_get_platdata(dev);
+ struct sdhci_host *host = dev_get_priv(dev);
+ u32 max_clk;
+ struct clk clk;
+ int ret;
+
+ ret = clk_get_by_index(dev, 0, );
+ if (ret)
+ return ret;
+
+ ret = clk_enable();
+ if (ret)
+ return ret;
Don't we need to release the clock below in case of error ?
Yes.
+ host->name = dev->name;
+ host->ioaddr = (void *)devfdt_get_addr(dev);
+
+ max_clk = clk_get_rate();
+ if (!max_clk)
may be use IS_ERR_VALUE(max_clk) and return max_clk
Yep, good idea.
Thanks for the quick review!
Eddie
+ return -EINVAL;
+
+ host->max_clk = max_clk;
+ host->mmc = >mmc;
+ host->mmc->dev = dev;
+ host->mmc->priv = host;
+ upriv->mmc = host->mmc;
+
+ ret = sdhci_setup_cfg(>cfg, host, 0, 0);
+ if (ret)
+ return ret;
+
+ return sdhci_probe(dev);
+}
+
+static int aspeed_sdhci_bind(struct udevice *dev)
+{
+ struct aspeed_sdhci_plat *plat = dev_get_platdata(dev);
+
+ return sdhci_bind(dev, >mmc, >cfg);
+}
+
+static const struct udevice_id aspeed_sdhci_ids[] = {
+ { .compatible = "aspeed,ast2400-sdhci" },
+ { .compatible = "aspeed,ast2500-sdhci" },
+ { .compatible = "aspeed,ast2600-sdhci" },
+ { }
+};
+
+U_BOOT_DRIVER(aspeed_sdhci_drv) = {
+ .name = "aspeed_sdhci",
+ .id = UCLASS_MMC,
+ .of_match = aspeed_sdhci_ids,
+ .ops= _ops,
+ .bind = aspeed_sdhci_bind,
+ .probe = aspeed_sdhci_probe,
+ .priv_auto_alloc_size = sizeof(struct sdhci_host),
+ .platdata_auto_alloc_size = sizeof(struct aspeed_sdhci_plat),
+};
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] aspeed: Support SD controller on the ast2500 board
On 8/14/19 10:23 AM, Cédric Le Goater wrote:
On 13/08/2019 21:31, Eddie James wrote:
Initialize the MMC subsystem on the ast2500 board. Compile MMC and the
Aspeed SD controller on the ast2500 EVB.
Signed-off-by: Eddie James
---
arch/arm/include/asm/gpio.h | 3 ++-
arch/arm/mach-aspeed/ast2500-board.c | 3 +++
configs/evb-ast2500_defconfig| 6 ++
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h
index 370031f..38a5922 100644
--- a/arch/arm/include/asm/gpio.h
+++ b/arch/arm/include/asm/gpio.h
@@ -1,6 +1,7 @@
#if !defined(CONFIG_ARCH_UNIPHIER) && !defined(CONFIG_ARCH_STI) && \
!defined(CONFIG_ARCH_K3) && !defined(CONFIG_ARCH_BCM6858) && \
- !defined(CONFIG_ARCH_BCM63158) && !defined(CONFIG_ARCH_ROCKCHIP)
+ !defined(CONFIG_ARCH_BCM63158) && !defined(CONFIG_ARCH_ROCKCHIP) && \
+ !defined(CONFIG_ARCH_ASPEED)
#include
#endif
#include
diff --git a/arch/arm/mach-aspeed/ast2500-board.c
b/arch/arm/mach-aspeed/ast2500-board.c
index e7edd54..52a4e05 100644
--- a/arch/arm/mach-aspeed/ast2500-board.c
+++ b/arch/arm/mach-aspeed/ast2500-board.c
@@ -4,6 +4,7 @@
*/
#include
#include
+#include
#include
#include
#include
@@ -55,6 +56,8 @@ int board_init(void)
{
gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
+ mmc_initialize(gd->bd);
+
isn't that called automatically by board_init_r() already ?
You are correct, I will drop this.
Thanks,
Eddie
C.
return 0;
}
diff --git a/configs/evb-ast2500_defconfig b/configs/evb-ast2500_defconfig
index 59d41cb..bfa6b32 100644
--- a/configs/evb-ast2500_defconfig
+++ b/configs/evb-ast2500_defconfig
@@ -16,6 +16,7 @@ CONFIG_HUSH_PARSER=y
CONFIG_CMD_I2C=y
CONFIG_CMD_DHCP=y
CONFIG_CMD_MII=y
+CONFIG_CMD_MMC=y
CONFIG_CMD_PING=y
CONFIG_DEFAULT_DEVICE_TREE="ast2500-evb"
CONFIG_NET_RANDOM_ETHADDR=y
@@ -36,3 +37,8 @@ CONFIG_SYS_NS16550=y
CONFIG_SYSRESET=y
CONFIG_TIMER=y
CONFIG_WDT=y
+CONFIG_MMC=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ASPEED=y
+CONFIG_MMC_VERBOSE=y
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] doc: arch: correct links in x86.rst
Correctly reference uefi/uefi.rst and uefi/u-boot_on_efi.rst. Signed-off-by: Heinrich Schuchardt --- doc/arch/x86.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/doc/arch/x86.rst b/doc/arch/x86.rst index 2eb524cc8f..a441738ad1 100644 --- a/doc/arch/x86.rst +++ b/doc/arch/x86.rst @@ -709,7 +709,8 @@ to load a 'u-boot-payload.efi', see below test logs on QEMU. No controllers found Hit any key to stop autoboot: 0 -See README.u-boot_on_efi and README.uefi for details of EFI support in U-Boot. +See :doc:`../uefi/u-boot_on_efi` and :doc:`../uefi/uefi` for details of +EFI support in U-Boot. TODO List - -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd: avb: Fix requested partitions list
Hi Eugeniu, On Tue, Aug 13, 2019 at 7:59 PM Eugeniu Rosca wrote: > > Hi Sam, > > On Fri, Aug 09, 2019 at 07:16:03PM +0300, Sam Protsenko wrote: > > The requested_partitions[] array should contain only boot partitions. > > Usually it's only 'boot' partition, as can be seen in [1]. Also, seems > > like the requested_partitions[] are only used when there is no 'vbmeta' > > partition [2], which is not a regular use-case. > > > > Make requested_partitions[] contain only 'boot' partition as it was > > supposed to be, and also make that array to be a local in > > do_avb_verify_part() function, as nobody else needs that. > > > > [1] > > https://android.googlesource.com/platform/external/avb/+/master/test/avb_slot_verify_unittest.cc#108 > > [2] > > https://android.googlesource.com/platform/external/avb/+/master/libavb/avb_slot_verify.c#1461 > > The patches are much appreciated. Could we agree to avoid volatile > references in the links, since those will point out to wrong lines after > a couple of weeks? I think it's safer to either use the latest available > commit id or tag, e.g.: > > [1] > https://android.googlesource.com/platform/external/avb/+/5fbb42a189aa/test/avb_slot_verify_unittest.cc#108 > [2] > https://android.googlesource.com/platform/external/avb/+/5fbb42a189aa/libavb/avb_slot_verify.c#1461 > Sure, will send v2 soon. Can you please review this patch [1] please? Without this AVB doesn't work (at least on X15 board, but I presume it might affect more platforms, as code I'm fixing in that patch is common). Also I send [2] for slots support in AVB. Will appreciate your review. Thanks! [1] https://patchwork.ozlabs.org/patch/1147191/ [2] https://patchwork.ozlabs.org/patch/1144646/ > Thank you. > > -- > Best Regards, > Eugeniu. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] cmd: avb: Fix requested partitions list
The requested_partitions[] array should contain only boot partitions.
Usually it's only 'boot' partition, as can be seen in [1]. Also, seems
like the requested_partitions[] are only used when there is no 'vbmeta'
partition [2], which is not a regular use-case.
Make requested_partitions[] contain only 'boot' partition as it was
supposed to be, and also make that array to be a local in
do_avb_verify_part() function, as nobody else needs that.
[1]
https://android.googlesource.com/platform/external/avb/+/5fbb42a189aa/test/avb_slot_verify_unittest.cc#108
[2]
https://android.googlesource.com/platform/external/avb/+/5fbb42a189aa/libavb/avb_slot_verify.c#1461
Signed-off-by: Sam Protsenko
---
Changes in v2:
- fix links in commit message (suggested by Eugeniu Rosca)
cmd/avb.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/cmd/avb.c b/cmd/avb.c
index a8a95034ca..a4de5c40a2 100644
--- a/cmd/avb.c
+++ b/cmd/avb.c
@@ -15,11 +15,6 @@
#define AVB_BOOTARGS "avb_bootargs"
static struct AvbOps *avb_ops;
-static const char * const requested_partitions[] = {"boot",
-"system",
-"vendor",
-NULL};
-
int do_avb_init(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
unsigned long mmc_dev;
@@ -232,6 +227,7 @@ int do_avb_get_uuid(cmd_tbl_t *cmdtp, int flag,
int do_avb_verify_part(cmd_tbl_t *cmdtp, int flag,
int argc, char *const argv[])
{
+ const char * const requested_partitions[] = {"boot", NULL};
AvbSlotVerifyResult slot_result;
AvbSlotVerifyData *out_data;
char *cmdline;
--
2.23.0.rc1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd: avb: Fix requested partitions list
Hi Eugeniu,
On Mon, Aug 12, 2019 at 4:57 PM Eugeniu Rosca wrote:
>
> Hi all,
>
> On Mon, Aug 12, 2019 at 02:13:55PM +0300, Igor Opaniuk wrote:
> [..]
> > Current snapshot of libavb in U-boot is a bit out-dated (~2 years) and
> > before introducing patches that can leverage new features from the mainline
> > libavb(taking into account that you're referring to Jul 30, 2019 patch
> > 36d41d9223 ("Add AVB_SLOT_VERIFY_FLAGS_NO_VBMETA_PARTITION flag"))
> > it makes sense to update libavb in U-boot first:
> >
> > The best approach I see here (just to summarize what we've already
> > discussed):
> > 1. Update libavb to the latest stable version
>
> FWIW, this sounds good. jFYI, U-Boot seems to contain the
> android-o-mr1-iot-preview-8 version of libavb (heuristics applied since
> commit [1] didn't include any information about the version).
>
> FWIW, in case of an alignment to AOSP, the list of libavb commits to
> be backported is shown in [2]. The diff stats is visible in [3].
>
> FWIW w.r.t. integration strategy, we better use
> 'git cherry-pick --strategy=subtree -Xsubtree=lib/' instead of manual
> copying the libavb contents from
> https://android.googlesource.com/platform/external/avb/, since the
> latter would overwrite local U-Boot fixes like commit [4].
>
Wow, that's some real jedi git skills here :) Thanks, Eugeniu, will
use that when porting most recent libavb to U-Boot.
> [1] https://gitlab.denx.de/u-boot/u-boot/commit/d8f9d2af96b38f
> ("avb2.0: add Android Verified Boot 2.0 library")
>
> [2] avb (master) git log --oneline --no-merges --no-decorate \
> android-o-mr1-iot-preview-8..5fbb42a189aa -- libavb
> 36d41d922380 Add AVB_SLOT_VERIFY_FLAGS_NO_VBMETA_PARTITION flag.
> 3deffc556cfa Fix the identification of vbmeta partition
> 2ea684dbd612 Adds avb_strncmp helper
> 31f5f91352e6 Libavb: Check rollback index location against 0.
> 0a4e345d73f9 Fix a bug that may cause inifinite loop.
> d91e04e2c163 Fix a bug that would cause OoB read.
> 18b535905bab Fix a stack-use-after-scope bug.
> 5786fa2f2cfa Fix a memory leak bug.
> a6c9ad41f779 Fix a bug that would cause OoB memory read.
> 9ba3b6613b4e Fix AvbSlotVerifyData->cmdline might be NULL
> 5abd6bc25789 Allow system partition to be absent
> 8127dae6e4f5 Only automatically initialize new persistent digest values when
> locked
> 4f137c38f838 libavb: Use size_t instead of uint32_t for lengths in avb_sha*()
> functions.
> 818cf5674077 libavb: Only query partition GUIDs when the cmdline needs them.
> 49936b4c0109 libavb: Support vbmeta blobs in beginning of partition.
> 6f4de3181429 libavb: Add ERROR_MODE_MANAGED_RESTART_AND_EIO for managing
> dm-verity state.
> 2367b46287bd Implement initialization of new persistent digest values
>
> [3] avb (master) git diff --shortstat \
> android-o-mr1-iot-preview-8..5fbb42a189aa -- libavb
> 12 files changed, 704 insertions(+), 208 deletions(-)
>
> [4] https://gitlab.denx.de/u-boot/u-boot/commit/ecc6f6bea6a2
> ("libavb: Handle wrong hashtree_error_mode in avb_append_options()")
>
> --
> Best Regards,
> Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] arm: socfpga: gen5: add readonly clk driver
Am 15.08.2019 um 19:07 schrieb Marek Vasut: On 8/15/19 6:57 PM, Simon Goldschmidt wrote: Am 15.08.2019 um 18:34 schrieb Marek Vasut: On 8/15/19 6:22 PM, Simon Goldschmidt wrote: Hi Marek, Am 24.07.2019 um 09:45 schrieb Simon Goldschmidt: On Wed, Jul 24, 2019 at 9:31 AM Marek Vasut wrote: On 7/23/19 10:27 PM, Simon Goldschmidt wrote: This adds clk-gen5 as a readonly DM_CLK driver that can return clocks for the peripherals. Further changes are: - select DM_CLK for gen5 U-Boot and SPL - add SPL tags to clock nodes in socfpga-common-u-boot.dtsi - adjust socfpga.dtsi to provide missing src selection registers - start 'handoff.dtsi' file for socrates (conatains clock speeds for now) These should likely be separate patches then ? Well, in the end, yes. Especially the handoff.dtsi is required for *all* socfpga_gen5 boards, so I'll need to adapt the 'qts-filter.sh' script to generate it. I'll change that script and separate these patches in v2. I'm in the process of moving all of the 'qts' header files to devicetree handoff.dtsi files. CLK and DDR are already working (pinmux/iocsr not yet) - but I need to work a bit on DM memory consumption. So now I'm faced with a question: in which driver do I implement the pinmux control? From a DM point of view, it could be a UCLASS_PINCTRL driver in 'drivers/pinctrl', but since it's more or less read-only unless we'd get more details about the hardware, I'm a bit hesistant to do it that way. Also, the registers are in 'sysmgr', which is handled by the standard "syscon" driver right now, so it could well get a UCLASS_SYSCON driver? What do we need read-only pinmux driver for ? I would expect pinmux to be more write-only, from the hardware perspective that is. Well, I don't know. I just need a driver that can parse its dts subtree for the config instead of loading from the qts wrapper file. Then this driver needs to be probed at the appropriate place in SPL so that the pins are initialized. Sounds more like misc driver or something along those lines. Hmm, probing UCLASS_MISC in SPL to get the pinmux initializes sounds a bit strange, but that's probably OK. My future plan is then that such a driver could be re-probed after loading some kind of dts overlay matching an FPGA image to be programmed (as that FPGA image can contain different pin settings, e.g. when using loan IO). But then it becomes a PINMUX driver. Well, what I'm writing *is* a writeonly driver controlling the pins. However, since we don't know anything about the iocsr part, we can't implement all the functions in 'struct pinctrl_ops' (just write the given scan chain and that's it). I think PINMUX would fit best, but see below... I'm just not familiar enough with pinctrl drivers or syscon drivers and could need some input on which direction to take this... Does a syscon driver for that purpose sound better? Isn't syscon driver for system controllers, which provide e.g. regmaps to subdevices ? I think the altera pinmux shouldn't be syscon. The thing is that 'sysmgr' already *is* a syscon driver: it provides access to various control bits (e.g. used by the ethernet driver in Linux) but also pinmux registers. Of course, I could add "scanmgr@0xfff02000" as a new node in the devicetree that would be the PINMUX driver which accesses the pinmux registers in sysmgr via sysycon... That would keep sysmgr's syscon behaviour working (for other drivers). Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] kernel-doc vs Doxygen
On Thu, Aug 15, 2019 at 4:51 PM Tom Rini wrote: > > On Wed, Aug 14, 2019 at 09:16:40PM +0300, Sam Protsenko wrote: > > > Hi everyone, > > > > Quick question: which comment style is allowed in U-Boot, kernel-doc > > or Doxygen one? I have noticed that both are used currently (and I've > > sent some patches with doxy comments myself). Please tell me if > > somebody is actually running either kernel-doc or Doxygen to generate > > the U-Boot documentation. If one particular style is preferred, maybe > > it's worth to mention it somewhere in doc/ or in README. > > We're (slowly) moving towards once again following the kernel now that > there's real consistent effort on that front that we can make use of, > thanks! > Thanks, Tom. I'll stick to kernel-doc format in my patches then. > -- > Tom ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] usb: r8a66597: Convert to USB DM
On Thu, Aug 15, 2019, Marek Vasut wrote: > Convert the R8A66597 USB driver to DM and add support for DT probing. > Drop support for legacy non-DM and non-DT probing, since there are no > platform using that. I like the switch to DM :) Chris ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] image: android: Support boot image v1 and v2
In new versions of Android Boot Image next fields are added to the
header (and corresponding payloads are added to the image itself):
- v1: Recovery DTBO
- v2: DTB
Account for these new fields in next functions:
1. android_image_get_end(): as v1 and v2 have new payloads in the
image, the calculation of image end address should be extended
correspondingly; this is used e.g. by "bootm" command when booting
the kernel from Android Boot Image
2. android_print_contents(): new fields values in v1 and v2 should be
printed; the result of this function can be seen e.g. in "iminfo"
command
This commit doesn't add the means for working with new payloads in v1
and v2 images (it will be done in further commits), it only updates
existing functions w.r.t. changes in boot image v1/v2.
Signed-off-by: Sam Protsenko
---
common/image-android.c | 44 +++---
1 file changed, 33 insertions(+), 11 deletions(-)
diff --git a/common/image-android.c b/common/image-android.c
index 264bf90007..3564a64221 100644
--- a/common/image-android.c
+++ b/common/image-android.c
@@ -120,6 +120,7 @@ int android_image_check_header(const struct andr_img_hdr
*hdr)
ulong android_image_get_end(const struct andr_img_hdr *hdr)
{
ulong end;
+
/*
* The header takes a full page, the remaining components are aligned
* on page boundary
@@ -130,6 +131,12 @@ ulong android_image_get_end(const struct andr_img_hdr *hdr)
end += ALIGN(hdr->ramdisk_size, hdr->page_size);
end += ALIGN(hdr->second_size, hdr->page_size);
+ if (hdr->header_version >= 1)
+ end += ALIGN(hdr->recovery_dtbo_size, hdr->page_size);
+
+ if (hdr->header_version >= 2)
+ end += ALIGN(hdr->dtb_size, hdr->page_size);
+
return end;
}
@@ -207,21 +214,36 @@ void android_print_contents(const struct andr_img_hdr
*hdr)
u32 os_ver = hdr->os_version >> 11;
u32 os_lvl = hdr->os_version & ((1U << 11) - 1);
- printf("%skernel size: %x\n", p, hdr->kernel_size);
- printf("%skernel address: %x\n", p, hdr->kernel_addr);
- printf("%sramdisk size: %x\n", p, hdr->ramdisk_size);
- printf("%sramdisk address: %x\n", p, hdr->ramdisk_addr);
- printf("%ssecond size: %x\n", p, hdr->second_size);
- printf("%ssecond address: %x\n", p, hdr->second_addr);
- printf("%stags address: %x\n", p, hdr->tags_addr);
- printf("%spage size:%x\n", p, hdr->page_size);
+ printf("%skernel size: %x\n", p, hdr->kernel_size);
+ printf("%skernel address: %x\n", p, hdr->kernel_addr);
+ printf("%sramdisk size: %x\n", p, hdr->ramdisk_size);
+ printf("%sramdisk address: %x\n", p, hdr->ramdisk_addr);
+ printf("%ssecond size: %x\n", p, hdr->second_size);
+ printf("%ssecond address: %x\n", p, hdr->second_addr);
+ printf("%stags address: %x\n", p, hdr->tags_addr);
+ printf("%spage size:%x\n", p, hdr->page_size);
/* ver = A << 14 | B << 7 | C (7 bits for each of A, B, C)
* lvl = ((Y - 2000) & 127) << 4 | M (7 bits for Y, 4 bits for M) */
- printf("%sos_version: %x (ver: %u.%u.%u, level: %u.%u)\n",
+ printf("%sos_version: %x (ver: %u.%u.%u, level: %u.%u)\n",
p, hdr->os_version,
(os_ver >> 7) & 0x7F, (os_ver >> 14) & 0x7F, os_ver & 0x7F,
(os_lvl >> 4) + 2000, os_lvl & 0x0F);
- printf("%sname: %s\n", p, hdr->name);
- printf("%scmdline: %s\n", p, hdr->cmdline);
+ printf("%sname: %s\n", p, hdr->name);
+ printf("%scmdline: %s\n", p, hdr->cmdline);
+ printf("%sheader_version: %d\n", p, hdr->header_version);
+
+ if (hdr->header_version >= 1) {
+ printf("%srecovery dtbo size: %x\n", p,
+ hdr->recovery_dtbo_size);
+ printf("%srecovery dtbo offset: %llx\n", p,
+ hdr->recovery_dtbo_offset);
+ printf("%sheader size: %x\n", p,
+ hdr->header_size);
+ }
+
+ if (hdr->header_version >= 2) {
+ printf("%sdtb size: %x\n", p, hdr->dtb_size);
+ printf("%sdtb addr: %llx\n", p, hdr->dtb_addr);
+ }
}
#endif
--
2.23.0.rc1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] usb: r8a66597: Remove CONFIG_SUPERH_ON_CHIP_R8A66597
On Thu, Aug 15, 2019, Marek Vasut wrote: > Signed-off-by: Marek Vasut > Cc: Chris Brandt The series Looks good. Thanks Marek! Chris ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Question about GPL v3 font
On Tue, Aug 13, 2019 at 03:34:20AM -0600, Simon Glass wrote: > Hi, > > On Fri, 26 Jul 2019 at 11:07, Tom Rini wrote: > > > > On Fri, Jul 26, 2019 at 06:42:47PM +0900, Masahiro Yamada wrote: > > > > > Hi. > > > > > > According to the Kconfig entry, > > > drivers/video/fonts/nimbus_sans_l_regular.ttf > > > is licensed under GPL v3. > > > > > > How the license is handled when U-Boot is compiled with > > > CONFIG_CONSOLE_TRUETYPE_NIMBUS=y ? > > > > > > I am asking this since many companies, I guess, > > > have GPL-v3 allergy. > > > > > > > > > config CONSOLE_TRUETYPE_NIMBUS > > > bool "Nimbus Sans Regular" > > > depends on CONSOLE_TRUETYPE > > > default y > > > help > > > Nimbus Sans L is a version of Nimbus Sans using Adobe font > > > sources. > > > It was designed in 1987. A subset of Nimbus Sans L were released > > > under the GPL. Although the characters are not exactly the same, > > > Nimbus Sans L has metrics almost identical to Helvetica and > > > Arial. > > > (From Wikipedia, the free encyclopedia) > > > From: https://fontlibrary.org/en/font/nimbus-sans-l > > > License: GNU GPL v3 > > > http://www.gnu.org/copyleft/gpl.html > > > > It's a good question. I suspect the answer is that we should drop that > > font as I don't know if you can combine "GPLv2 only" and "GPLv2 or > > later" with "GPLv3". > > Yes, agreed. Can we find another similar font? Depends on who "we" is I suppose. Yes, I would love to see someone submit a new font that's GPLv2 only compatible. -- 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 5/6] arm: socfpga: gen5: add readonly clk driver
On 8/15/19 6:57 PM, Simon Goldschmidt wrote: > Am 15.08.2019 um 18:34 schrieb Marek Vasut: >> On 8/15/19 6:22 PM, Simon Goldschmidt wrote: >>> Hi Marek, >>> >>> Am 24.07.2019 um 09:45 schrieb Simon Goldschmidt: On Wed, Jul 24, 2019 at 9:31 AM Marek Vasut wrote: > > On 7/23/19 10:27 PM, Simon Goldschmidt wrote: >> This adds clk-gen5 as a readonly DM_CLK driver that can return >> clocks for >> the peripherals. >> >> Further changes are: >> - select DM_CLK for gen5 U-Boot and SPL >> - add SPL tags to clock nodes in socfpga-common-u-boot.dtsi >> - adjust socfpga.dtsi to provide missing src selection registers >> - start 'handoff.dtsi' file for socrates (conatains clock speeds for >> now) > > These should likely be separate patches then ? Well, in the end, yes. Especially the handoff.dtsi is required for *all* socfpga_gen5 boards, so I'll need to adapt the 'qts-filter.sh' script to generate it. I'll change that script and separate these patches in v2. >>> >>> I'm in the process of moving all of the 'qts' header files to devicetree >>> handoff.dtsi files. CLK and DDR are already working (pinmux/iocsr not >>> yet) - but I need to work a bit on DM memory consumption. >>> >>> So now I'm faced with a question: in which driver do I implement the >>> pinmux control? From a DM point of view, it could be a UCLASS_PINCTRL >>> driver in 'drivers/pinctrl', but since it's more or less read-only >>> unless we'd get more details about the hardware, I'm a bit hesistant to >>> do it that way. >>> >>> Also, the registers are in 'sysmgr', which is handled by the standard >>> "syscon" driver right now, so it could well get a UCLASS_SYSCON driver? >> >> What do we need read-only pinmux driver for ? I would expect pinmux to >> be more write-only, from the hardware perspective that is. > > Well, I don't know. I just need a driver that can parse its dts subtree > for the config instead of loading from the qts wrapper file. Then this > driver needs to be probed at the appropriate place in SPL so that the > pins are initialized. Sounds more like misc driver or something along those lines. > My future plan is then that such a driver could be re-probed after > loading some kind of dts overlay matching an FPGA image to be programmed > (as that FPGA image can contain different pin settings, e.g. when using > loan IO). But then it becomes a PINMUX driver. > I'm just not familiar enough with pinctrl drivers or syscon drivers and > could need some input on which direction to take this... > > Does a syscon driver for that purpose sound better? Isn't syscon driver for system controllers, which provide e.g. regmaps to subdevices ? I think the altera pinmux shouldn't be syscon. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] arm: socfpga: gen5: add readonly clk driver
Am 15.08.2019 um 18:34 schrieb Marek Vasut: On 8/15/19 6:22 PM, Simon Goldschmidt wrote: Hi Marek, Am 24.07.2019 um 09:45 schrieb Simon Goldschmidt: On Wed, Jul 24, 2019 at 9:31 AM Marek Vasut wrote: On 7/23/19 10:27 PM, Simon Goldschmidt wrote: This adds clk-gen5 as a readonly DM_CLK driver that can return clocks for the peripherals. Further changes are: - select DM_CLK for gen5 U-Boot and SPL - add SPL tags to clock nodes in socfpga-common-u-boot.dtsi - adjust socfpga.dtsi to provide missing src selection registers - start 'handoff.dtsi' file for socrates (conatains clock speeds for now) These should likely be separate patches then ? Well, in the end, yes. Especially the handoff.dtsi is required for *all* socfpga_gen5 boards, so I'll need to adapt the 'qts-filter.sh' script to generate it. I'll change that script and separate these patches in v2. I'm in the process of moving all of the 'qts' header files to devicetree handoff.dtsi files. CLK and DDR are already working (pinmux/iocsr not yet) - but I need to work a bit on DM memory consumption. So now I'm faced with a question: in which driver do I implement the pinmux control? From a DM point of view, it could be a UCLASS_PINCTRL driver in 'drivers/pinctrl', but since it's more or less read-only unless we'd get more details about the hardware, I'm a bit hesistant to do it that way. Also, the registers are in 'sysmgr', which is handled by the standard "syscon" driver right now, so it could well get a UCLASS_SYSCON driver? What do we need read-only pinmux driver for ? I would expect pinmux to be more write-only, from the hardware perspective that is. Well, I don't know. I just need a driver that can parse its dts subtree for the config instead of loading from the qts wrapper file. Then this driver needs to be probed at the appropriate place in SPL so that the pins are initialized. My future plan is then that such a driver could be re-probed after loading some kind of dts overlay matching an FPGA image to be programmed (as that FPGA image can contain different pin settings, e.g. when using loan IO). I'm just not familiar enough with pinctrl drivers or syscon drivers and could need some input on which direction to take this... Does a syscon driver for that purpose sound better? Thanks, Simon I'd appreciate your input on this, given the insight to the Altera system you have! Also, this (and holidays) are delaying this series (I want to put it all together in once series), so this will have to wait until after v2019.10, I guess? We're already in RC2, so I think so. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] arm: socfpga: gen5: add readonly clk driver
On 8/15/19 6:22 PM, Simon Goldschmidt wrote: > Hi Marek, > > Am 24.07.2019 um 09:45 schrieb Simon Goldschmidt: >> On Wed, Jul 24, 2019 at 9:31 AM Marek Vasut wrote: >>> >>> On 7/23/19 10:27 PM, Simon Goldschmidt wrote: This adds clk-gen5 as a readonly DM_CLK driver that can return clocks for the peripherals. Further changes are: - select DM_CLK for gen5 U-Boot and SPL - add SPL tags to clock nodes in socfpga-common-u-boot.dtsi - adjust socfpga.dtsi to provide missing src selection registers - start 'handoff.dtsi' file for socrates (conatains clock speeds for now) >>> >>> These should likely be separate patches then ? >> >> Well, in the end, yes. Especially the handoff.dtsi is required for *all* >> socfpga_gen5 boards, so I'll need to adapt the 'qts-filter.sh' script to >> generate it. >> >> I'll change that script and separate these patches in v2. > > I'm in the process of moving all of the 'qts' header files to devicetree > handoff.dtsi files. CLK and DDR are already working (pinmux/iocsr not > yet) - but I need to work a bit on DM memory consumption. > > So now I'm faced with a question: in which driver do I implement the > pinmux control? From a DM point of view, it could be a UCLASS_PINCTRL > driver in 'drivers/pinctrl', but since it's more or less read-only > unless we'd get more details about the hardware, I'm a bit hesistant to > do it that way. > > Also, the registers are in 'sysmgr', which is handled by the standard > "syscon" driver right now, so it could well get a UCLASS_SYSCON driver? What do we need read-only pinmux driver for ? I would expect pinmux to be more write-only, from the hardware perspective that is. > I'd appreciate your input on this, given the insight to the Altera > system you have! > > Also, this (and holidays) are delaying this series (I want to put it all > together in once series), so this will have to wait until after > v2019.10, I guess? We're already in RC2, so I think so. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] arm: socfpga: gen5: add readonly clk driver
Hi Marek, Am 24.07.2019 um 09:45 schrieb Simon Goldschmidt: On Wed, Jul 24, 2019 at 9:31 AM Marek Vasut wrote: On 7/23/19 10:27 PM, Simon Goldschmidt wrote: This adds clk-gen5 as a readonly DM_CLK driver that can return clocks for the peripherals. Further changes are: - select DM_CLK for gen5 U-Boot and SPL - add SPL tags to clock nodes in socfpga-common-u-boot.dtsi - adjust socfpga.dtsi to provide missing src selection registers - start 'handoff.dtsi' file for socrates (conatains clock speeds for now) These should likely be separate patches then ? Well, in the end, yes. Especially the handoff.dtsi is required for *all* socfpga_gen5 boards, so I'll need to adapt the 'qts-filter.sh' script to generate it. I'll change that script and separate these patches in v2. I'm in the process of moving all of the 'qts' header files to devicetree handoff.dtsi files. CLK and DDR are already working (pinmux/iocsr not yet) - but I need to work a bit on DM memory consumption. So now I'm faced with a question: in which driver do I implement the pinmux control? From a DM point of view, it could be a UCLASS_PINCTRL driver in 'drivers/pinctrl', but since it's more or less read-only unless we'd get more details about the hardware, I'm a bit hesistant to do it that way. Also, the registers are in 'sysmgr', which is handled by the standard "syscon" driver right now, so it could well get a UCLASS_SYSCON driver? I'd appreciate your input on this, given the insight to the Altera system you have! Also, this (and holidays) are delaying this series (I want to put it all together in once series), so this will have to wait until after v2019.10, I guess? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net: dwc_eth_qos: Change eqos_ops function to static
On Thu, Aug 1, 2019 at 4:31 AM Patrick Delaunay wrote: > > This patch solves many warnings when compiling with W=1: > warning: no previous prototype for '' [-Wmissing-prototypes] > > Signed-off-by: Patrice Chotard > Signed-off-by: Patrick Delaunay Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] test/py: Fix MMC/SD block write test dependency
On 8/15/19 12:26 AM, Michal Simek wrote: On 14. 08. 19 17:51, Stephen Warren wrote: On 8/14/19 12:12 AM, Michal Simek wrote: On 13. 08. 19 23:21, Stephen Warren wrote: On 8/1/19 10:48 PM, Michal Simek wrote: Test is using random command which has own Kconfig symbol CMD_RANDOM which already depends on CMD_MEMORY. That's why replace cmd_memory by cmd_random. This might not always be true; I think it'd be better to keep the existing dependency list entries and just add CMD_RANDOM: Can you please tell me when exactly? I didn't see that. If in the future somebody changes the Kconfig file so that CMD_RANDOM doesn't depend on or select CMD_MEMORY. It may well not be possible right now; I just want to make sure the test doesn't rely on implementation details of CMD_RANDOM/CMD_MEMORY; if it explicitly needs both, it should simply depend on both. Do you think that we have used this rule in past? I hope so; I'd consider it a bug in a test if the test used a command but didn't explicitly depend on that command's CONFIG_ flag. We have had such bugs in the past, and fixed one or two of them. Anyway I understand what you mean but it is questionable if make sense to predict all changes which can happen. It's more about the test explicitly specifying exactly what it depends on than predicting changes. I would consider if anybody remove this dependency without fixing test suite as bug which should be fixed. Also tests should detect this and report issues to stop this before patch like this is applied. True, but people do forget such things. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4 v5] watchdog: Implement generic watchdog_reset() version
Hi Stefan,
On Thu, Aug 15, 2019 at 2:07 PM Stefan Roese wrote:
>
> Hi Simon,
>
> On 14.08.19 21:35, Simon Glass wrote:
> > Hi,
> >
> > On Wed, 14 Aug 2019 at 00:22, Stefan Roese wrote:
> >>
> >> Hi Simon,
> >>
> >> (added Simon Glass and Bin to Cc)
> >>
> >> On 13.08.19 22:16, Simon Goldschmidt wrote:
> >>> Am 25.04.2019 um 09:17 schrieb Stefan Roese:
> This patch tries to implement a generic watchdog_reset() function that
> can be used by all boards that want to service the watchdog device in
> U-Boot. This watchdog servicing is enabled via CONFIG_WATCHDOG.
>
> Without this approach, new boards or platforms needed to implement a
> board specific version of this functionality, mostly copy'ing the same
> code over and over again into their board or platforms code base.
>
> With this new generic function, the scattered other functions are now
> removed to be replaced by the generic one. The new version also enables
> the configuration of the watchdog timeout via the DT "timeout-sec"
> property (if enabled via CONFIG_OF_CONTROL).
>
> This patch also adds a new flag to the GD flags, to flag that the
> watchdog is ready to use and adds the pointer to the watchdog device
> to the GD. This enables us to remove the global "watchdog_dev"
> variable, which was prone to cause problems because of its potentially
> very early use in watchdog_reset(), even before the BSS is cleared.
>
> Signed-off-by: Stefan Roese
> >>>
> >>>
> >>>
> --- a/include/asm-generic/global_data.h
> +++ b/include/asm-generic/global_data.h
> @@ -133,6 +133,9 @@ typedef struct global_data {
> struct spl_handoff *spl_handoff;
> # endif
> #endif
> +#if defined(CONFIG_WDT)
> +struct udevice *watchdog_dev;
> +#endif
> } gd_t;
> #endif
>
> @@ -161,5 +164,6 @@ typedef struct global_data {
> #define GD_FLG_ENV_DEFAULT0x02000 /* Default variable flag
> */
> #define GD_FLG_SPL_EARLY_INIT 0x04000 /* Early SPL init is done
> */
> #define GD_FLG_LOG_READY 0x08000 /* Log system is ready for use
> */
> +#define GD_FLG_WDT_READY0x1 /* Watchdog is ready for use
> */
> >>>
> >>> Sorry to warm up a thread that is more than 4 months old, but I just
> >>> stumbled accross this line when searching for space in 'gd':
> >>>
> >>> The comment some lines above in global_data.h clearly states that the
> >>> top 16 bits of flags are reserved for arch-specific flags, and your
> >>> patch here uses the lowest of these 16 arch-specific flags for generic
> >>> code.
> >>
> >> I totally missed this comment.
> >>
> >>> Is this a problem? Does any arch code use the upper 16 bits? I would
> >>> have thought you'd at least need to adjust the comment to reflect your
> >>> new usage...
> >>
> >> As stated above, I did not check about any other (arch-specific)
> >> GD_FLG_ definitions outside of this file.
> >>
> >>> The reason I ask is that I'd need a place to put some (~5?)
> >>> 'is_initialized' bits for some code running in SPL in the 'board_init_f'
> >>> code where BSS shouldn't be used. gd->flags would be ideal for that, but
> >>> I'm hesistant to dive in further into the 'arch-specific' upper 16 bits...
> >>
> >> And you should be. A quick grep shows that we already have a problem with
> >> my patch touching the upper bits:
> >>
> >> $ git grep "define GD_FLG_"
> >> arch/x86/include/asm/global_data.h:#define GD_FLG_COLD_BOOT 0x1 /*
> >> Cold Boot */
> >> arch/x86/include/asm/global_data.h:#define GD_FLG_WARM_BOOT 0x2 /*
> >> Warm Boot */
> >>
> >> This should definitely be fixed. I see 3 options right now:
> >>
> >> a) Reserve only the upper 8 bits for arch-specific stuff
> >> b) Use a new variable (gd->flags_arch ?) for this arch
> >> c) Remove the arch-specific GD_FLG's completely
> >>
> >> I can't tell if c) is doable - Bin and / or Simon Glass might know,
> >> if the x86 GD_FLG_foo_BOOT are really needed in gd->flags. I see that
> >> both are assigned in the .S files, but only GD_FLG_COLD_BOOT is
> >> referenced later on:
> >
> > Probably we can drop warm boot.
>
> Bin, do you think so as well?
>
I believe we can drop these 2 flags completely. Currently usage of
warm/cold boot flags is only limited to coreboot codes.
arch/x86/cpu/coreboot/coreboot.c::last_stage_init()
if (gd->flags & GD_FLG_COLD_BOOT)
timestamp_add_to_bootstage();
timestamp_add_to_bootstage() will never be called for coreboot.
> >>
> >> arch/x86/cpu/coreboot/coreboot.c: if (gd->flags & GD_FLG_COLD_BOOT)
> >>
> >> If c) is not an option, then I would prefer to implement b). Here
> >> we could also only add this new "flags_arch" variable for arch's
> >> that implement such flags (e.g. x86 right now). I could work on such
> >> a patch, if we agree on this
Re: [U-Boot] What can cause gpio_request return negative value
And to be more precise inside gpio-uclass.c, the function gpio_to_device
which is called by gpio_request loops through all gpio objects in order to
search for the gpio number provided never loops in my case.
puts("gpio-uclass");
for (ret = uclass_first_device(UCLASS_GPIO, ); dev; ret =
uclass_next_device()) {
puts("gpio-uclass loop\n");
...
puts inside loop is never executed, that's why I asked if I should maybe
first declare GPIOs to the system via device tree.
On Thu, Aug 15, 2019 at 4:05 PM Nemanja Savic wrote:
> It return -2 which should be -ENOENT. In the comment at the end of
> gpio_to_device() it is written "No such GPIO".
> Are there any prerequisites before calling gpio_request regarding device
> tree or something else?
>
> On Thu, Aug 15, 2019 at 3:09 PM Adam Ford wrote:
>
>> On Thu, Aug 15, 2019 at 7:46 AM Nemanja Savic wrote:
>> >
>> > Hi all,
>> >
>> > I am struggling with porting our old board init code for a sabre auto
>> based
>> > custom board with i.MX6 DualLite processor. The code used to work in our
>> > older u-boot version, but what I saw in mx6qsabreauto.c is that the new
>> > style is by using new driver model which means the gpio should be first
>> > requested. However gpio_request returns negative value in my case. Where
>> > could the problem be? As far as I could see our device tree doesn't
>> reserve
>> > this pin for other purpose. It is even not mentioned there. The only
>> thing
>> > related to those pins are iomux pin definitions in the device tree but
>> > removing that doesn't help at all. Also device tree for the Sabre Auto
>> > board doesn't mention gpio pins that they use in their u-boot. I am
>> dealing
>> > with 2017.03 version of u-boot.
>>
>> Do you know what the negative value is? include/linux/errno.h should
>> have a list of error numbers which should correlate to the error
>> you're seeing. That should also tell you what the error means. From
>> there, you should be able to search the code for where that error
>> might return.
>>
>> adam
>> > ___
>> > U-Boot mailing list
>> > U-Boot@lists.denx.de
>> > https://lists.denx.de/listinfo/u-boot
>>
>
>
> --
> Nemanja Savić
>
--
Nemanja Savić
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] What can cause gpio_request return negative value
It return -2 which should be -ENOENT. In the comment at the end of gpio_to_device() it is written "No such GPIO". Are there any prerequisites before calling gpio_request regarding device tree or something else? On Thu, Aug 15, 2019 at 3:09 PM Adam Ford wrote: > On Thu, Aug 15, 2019 at 7:46 AM Nemanja Savic wrote: > > > > Hi all, > > > > I am struggling with porting our old board init code for a sabre auto > based > > custom board with i.MX6 DualLite processor. The code used to work in our > > older u-boot version, but what I saw in mx6qsabreauto.c is that the new > > style is by using new driver model which means the gpio should be first > > requested. However gpio_request returns negative value in my case. Where > > could the problem be? As far as I could see our device tree doesn't > reserve > > this pin for other purpose. It is even not mentioned there. The only > thing > > related to those pins are iomux pin definitions in the device tree but > > removing that doesn't help at all. Also device tree for the Sabre Auto > > board doesn't mention gpio pins that they use in their u-boot. I am > dealing > > with 2017.03 version of u-boot. > > Do you know what the negative value is? include/linux/errno.h should > have a list of error numbers which should correlate to the error > you're seeing. That should also tell you what the error means. From > there, you should be able to search the code for where that error > might return. > > adam > > ___ > > U-Boot mailing list > > U-Boot@lists.denx.de > > https://lists.denx.de/listinfo/u-boot > -- Nemanja Savić ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] kernel-doc vs Doxygen
On Wed, Aug 14, 2019 at 09:16:40PM +0300, Sam Protsenko wrote: > Hi everyone, > > Quick question: which comment style is allowed in U-Boot, kernel-doc > or Doxygen one? I have noticed that both are used currently (and I've > sent some patches with doxy comments myself). Please tell me if > somebody is actually running either kernel-doc or Doxygen to generate > the U-Boot documentation. If one particular style is preferred, maybe > it's worth to mention it somewhere in doc/ or in README. We're (slowly) moving towards once again following the kernel now that there's real consistent effort on that front that we can make use of, 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] What can cause gpio_request return negative value
On Thu, Aug 15, 2019 at 7:46 AM Nemanja Savic wrote: > > Hi all, > > I am struggling with porting our old board init code for a sabre auto based > custom board with i.MX6 DualLite processor. The code used to work in our > older u-boot version, but what I saw in mx6qsabreauto.c is that the new > style is by using new driver model which means the gpio should be first > requested. However gpio_request returns negative value in my case. Where > could the problem be? As far as I could see our device tree doesn't reserve > this pin for other purpose. It is even not mentioned there. The only thing > related to those pins are iomux pin definitions in the device tree but > removing that doesn't help at all. Also device tree for the Sabre Auto > board doesn't mention gpio pins that they use in their u-boot. I am dealing > with 2017.03 version of u-boot. Do you know what the negative value is? include/linux/errno.h should have a list of error numbers which should correlate to the error you're seeing. That should also tell you what the error means. From there, you should be able to search the code for where that error might return. adam > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] What can cause gpio_request return negative value
Hi all, I am struggling with porting our old board init code for a sabre auto based custom board with i.MX6 DualLite processor. The code used to work in our older u-boot version, but what I saw in mx6qsabreauto.c is that the new style is by using new driver model which means the gpio should be first requested. However gpio_request returns negative value in my case. Where could the problem be? As far as I could see our device tree doesn't reserve this pin for other purpose. It is even not mentioned there. The only thing related to those pins are iomux pin definitions in the device tree but removing that doesn't help at all. Also device tree for the Sabre Auto board doesn't mention gpio pins that they use in their u-boot. I am dealing with 2017.03 version of u-boot. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] global_data: Move x86 specific GD flags into common flags
Hi Stefan,
On Thu, Aug 15, 2019 at 10:06 AM Stefan Roese wrote:
>
> Hi Simon,
>
> On 15.08.19 09:35, Simon Goldschmidt wrote:
> > Hi Stefan,
> >
> > On Thu, Aug 15, 2019 at 9:05 AM Stefan Roese wrote:
> >>
> >> Currently the upper 16 bits of the GD flags are reserved for
> >> architecture specific flags. But only x86 uses 2 bits of these 16 bits
> >> and sprinkling those flags in multiple headers is confusing and does not
> >> scale.
> >>
> >> This patch now moves the x86 flags into the common header and removes
> >> the comment about the reservation of the upper 16 bits.
> >>
> >> Signed-off-by: Stefan Roese
> >> Cc: Bin Meng
> >> Cc: Simon Glass
> >> Cc: Tom Rini
> >> Cc: Simon Goldschmidt
> >> ---
> >> arch/x86/include/asm/global_data.h | 6 --
> >> include/asm-generic/global_data.h | 6 +-
> >> 2 files changed, 5 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/arch/x86/include/asm/global_data.h
> >> b/arch/x86/include/asm/global_data.h
> >> index 797397e697..17a4d34491 100644
> >> --- a/arch/x86/include/asm/global_data.h
> >> +++ b/arch/x86/include/asm/global_data.h
> >> @@ -137,10 +137,4 @@ static inline __attribute__((no_instrument_function))
> >> gd_t *get_fs_gd_ptr(void)
> >>
> >> #endif
> >>
> >> -/*
> >> - * Our private Global Data Flags
> >> - */
> >> -#define GD_FLG_COLD_BOOT 0x1 /* Cold Boot */
> >> -#define GD_FLG_WARM_BOOT 0x2 /* Warm Boot */
> >> -
> >> #endif /* __ASM_GBL_DATA_H */
> >> diff --git a/include/asm-generic/global_data.h
> >> b/include/asm-generic/global_data.h
> >> index 5372d5d8cd..42ae61c781 100644
> >> --- a/include/asm-generic/global_data.h
> >> +++ b/include/asm-generic/global_data.h
> >> @@ -150,7 +150,7 @@ typedef struct global_data {
> >> #endif
> >>
> >> /*
> >> - * Global Data Flags - the top 16 bits are reserved for arch-specific
> >> flags
> >> + * Common Global Data Flags
> >>*/
> >> #define GD_FLG_RELOC 0x1 /* Code was relocated to RAM
> >> */
> >> #define GD_FLG_DEVINIT 0x2 /* Devices have been initialized
> >> */
> >> @@ -170,4 +170,8 @@ typedef struct global_data {
> >> #define GD_FLG_LOG_READY 0x08000 /* Log system is ready for use
> >> */
> >> #define GD_FLG_WDT_READY 0x1 /* Watchdog is ready for use
> >> */
> >>
> >> +/* x86 specific GD flags */
> >> +#define GD_FLG_COLD_BOOT 0x2 /* Cold Boot */
> >> +#define GD_FLG_WARM_BOOT 0x4 /* Warm Boot */
> >
> > I think this change is generally good, but I failed to find code using the
> > flag
> > GD_FLG_WARM_BOOT (it's only set, not checked). Only the cold-boot flag is
> > used
> > (in coreboot's last_stage_init).
> >
> > So, since we don't have too many bits free here, instead of wasting 2 for
> > x86,
> > could we probably remove one of these. Especially since you can either have
> > warm OR cold, but not both (so the absence of 'WARM' could mean 'COLD')?
>
> Yes. I already commented on those 2 x86 bits and their (non-)usage:
>
> https://lists.denx.de/pipermail/u-boot/2019-August/380634.html
> &
> https://lists.denx.de/pipermail/u-boot/2019-August/380800.html
>
> My suggestion is to apply this patch now and re-work the x86 flags usage
> in a later patch (most likely remove one of those bits). The main reason
> being that this double usage of 0x1 needs to get fixed quickly.
You're right. In that case:
Reviewed-by: Simon Goldschmidt
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] rk8xx: add a sysreset driver for poweroff【请注意，邮件由s...@google.com代发】
Simon, Stephen, On 2019/8/15 上午3:35, Simon Glass wrote: Hi Kever, On Tue, 13 Aug 2019 at 20:46, Kever Yang wrote: Hi Urja, Simon, This patch is not able to pass the sandbox_spl test, it reports: [1]26463 segmentation fault (core dumped) ./u-boot The driver looks good to me, no idea what cause the issue. Thanks, - Kever Urja Rannikko 于2019年5月17日周五 上午5:49写道： Based on snooping around the linux kernel rk8xx driver. Tested on an ASUS C201. Signed-off-by: Urja Rannikko --- drivers/power/pmic/Kconfig | 1 + drivers/power/pmic/rk8xx.c | 62 +++--- include/power/rk8xx_pmic.h | 4 +++ 3 files changed, 63 insertions(+), 4 deletions(-) This driver is enabled for sandbox, although I doubt it is in the device tree, so I'm not sure why it would be called. But if it is, and it directly accesses memory, then it might be the reason. You should run the test under gdb to see where it is crashing. gdb output is: Program received signal SIGSEGV, Segmentation fault. 0x556182c6 in strcmp (cs=cs@entry=0x5566023b "root_driver", ct=0x1 ) at lib/string.c:190 190 if ((__res = *cs - *ct++) != 0 || !*cs++) This does not help much for crashing reason, and I have narrow down the cause, I believe the crash related to "DM_GET_DRIVER(pmic_rk8xx)", - if I replace the 'pmic_rk8xx' in DM_GET_DRIVER() to any of other available driver, u-boot does not crash; - if I move the new 'rk8xx_sysreset' driver to other files, eg. pmic/sandbox.c, u-boot does not crash; Any more suggestion, or could you help to cherry pick this patch, and you should reproduce this issue: make sandbox_spl_defconfig all ./u-boot Thanks, - Kever Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Convert CONFIG_ARCH_CPU_INIT to Kconfig
Hi Adam, On Wed, 2019-08-14 at 08:29 -0500, Adam Ford wrote: > This converts the following to Kconfig: > CONFIG_ARCH_CPU_INIT > > Signed-off-by: Adam Ford For SBx81LIFKW, SBx81LIFXCAT, db-88f6281-bp, db-88f6820-amc, db-xc3- 24g4xg and x530 Acked-by: Chris Packham ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] arm: baltos: switch to driver model for the watchdog timer
From: Yegor Yefremov Signed-off-by: Yegor Yefremov --- Changes v1 -> v2: rebased to include the ported omap_wdt driver configs/am335x_baltos_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/am335x_baltos_defconfig b/configs/am335x_baltos_defconfig index aa8fee5125..af027a3c5d 100644 --- a/configs/am335x_baltos_defconfig +++ b/configs/am335x_baltos_defconfig @@ -69,4 +69,5 @@ CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_USB_FUNCTION_MASS_STORAGE=y CONFIG_USB_ETHER=y CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00" +CONFIG_WDT=y CONFIG_FAT_WRITE=y -- 2.17.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 2/2] part: always enable part_get_info_ptr() for driver
The partition driver has its Kconfig option, and the part_get_info_prt()
interface are mendatory interface for partition drivers, always enable the
macro to make partition driver works correctly.
Signed-off-by: Kever Yang
---
Changes in v4:
- formate commit message to ~75 columns
Changes in v3: None
Changes in v2:
- add patch to use SPL_PARTITIONS so that we don't add disk driver for
boards who don't need it.
include/part.h | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/include/part.h b/include/part.h
index ebca546db5..7d00fae56f 100644
--- a/include/part.h
+++ b/include/part.h
@@ -241,22 +241,15 @@ static inline int blk_get_device_part_str(const char
*ifname,
#endif
/*
- * We don't support printing partition information in SPL and only support
- * getting partition information in a few cases.
+ * We don't support printing partition information in SPL
*/
#ifdef CONFIG_SPL_BUILD
# define part_print_ptr(x) NULL
-# if defined(CONFIG_SPL_FS_EXT4) || defined(CONFIG_SPL_FS_FAT) || \
- defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION)
-# define part_get_info_ptr(x) x
-# else
-# define part_get_info_ptr(x) NULL
-# endif
#else
#define part_print_ptr(x) x
-#define part_get_info_ptr(x) x
#endif
+#define part_get_info_ptr(x) x
struct part_driver {
const char *name;
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 1/2] disk: update to use SPL_PARTITIONS for SPL
The SPL disk driver can not depends on SPL_FRAMEWORK & PARTITIONS, which
will enable the disk driver when we actually not need it. Use a separate
Kconfig to control the partition driver in SPL and fix the issue caused by:
Fixes: 91ff686562 ("blk: Rework guard around part_init call")
Signed-off-by: Kever Yang
Reviewed-by: Simon Glass
---
Changes in v4:
- format the commit message to ~75 columns.
Changes in v3:
- update code in blk-uclass.c
Changes in v2:
- add this patch
common/spl/Kconfig | 2 +-
disk/Kconfig | 20
disk/Makefile | 2 +-
drivers/block/blk-uclass.c | 2 +-
scripts/Makefile.spl | 2 +-
5 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 5978fb2934..094680e54d 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -544,7 +544,7 @@ config SPL_LIBCOMMON_SUPPORT
config SPL_LIBDISK_SUPPORT
bool "Support disk partitions"
- select PARTITIONS
+ select SPL_PARTITIONS
help
Enable support for disk partitions within SPL. 'Disk' is something
of a misnomer as it includes non-spinning media such as flash (as
diff --git a/disk/Kconfig b/disk/Kconfig
index 28fb81c2ee..43e76cb49d 100644
--- a/disk/Kconfig
+++ b/disk/Kconfig
@@ -4,9 +4,7 @@ menu "Partition Types"
config PARTITIONS
bool "Enable Partition Labels (disklabels) support"
default y
- select SPL_SPRINTF if SPL
select TPL_SPRINTF if TPL
- select SPL_STRTO if SPL
select TPL_STRTO if TPL
help
Partition Labels (disklabels) Supported:
@@ -23,6 +21,12 @@ config PARTITIONS
you must configure support for at least one non-MTD partition type
as well.
+config SPL_PARTITIONS
+ select SPL_SPRINTF
+ select SPL_STRTO
+ bool "Enable Partition Labels (disklabels) support for SPL"
+ depends on SPL
+
config MAC_PARTITION
bool "Enable Apple's MacOS partition table"
depends on PARTITIONS
@@ -32,7 +36,7 @@ config MAC_PARTITION
config SPL_MAC_PARTITION
bool "Enable Apple's MacOS partition table for SPL"
- depends on SPL && PARTITIONS
+ depends on SPL_PARTITIONS
default y if MAC_PARTITION
config DOS_PARTITION
@@ -45,7 +49,7 @@ config DOS_PARTITION
config SPL_DOS_PARTITION
bool "Enable MS Dos partition table for SPL"
- depends on SPL && PARTITIONS
+ depends on SPL_PARTITIONS
default y if DOS_PARTITION
config ISO_PARTITION
@@ -56,7 +60,7 @@ config ISO_PARTITION
config SPL_ISO_PARTITION
bool "Enable ISO partition table for SPL"
- depends on SPL && PARTITIONS
+ depends on SPL_PARTITIONS
config AMIGA_PARTITION
bool "Enable AMIGA partition table"
@@ -67,7 +71,7 @@ config AMIGA_PARTITION
config SPL_AMIGA_PARTITION
bool "Enable AMIGA partition table for SPL"
- depends on SPL && PARTITIONS
+ depends on SPL_PARTITIONS
default y if AMIGA_PARTITION
config EFI_PARTITION
@@ -111,7 +115,7 @@ config EFI_PARTITION_ENTRIES_OFF
config SPL_EFI_PARTITION
bool "Enable EFI GPT partition table for SPL"
- depends on SPL && PARTITIONS
+ depends on SPL_PARTITIONS
default y if EFI_PARTITION
config PARTITION_UUIDS
@@ -125,7 +129,7 @@ config PARTITION_UUIDS
config SPL_PARTITION_UUIDS
bool "Enable support of UUID for partition in SPL"
- depends on SPL && PARTITIONS
+ depends on SPL_PARTITIONS
default y if SPL_EFI_PARTITION
config PARTITION_TYPE_GUID
diff --git a/disk/Makefile b/disk/Makefile
index ccd0335959..92fcc2b4ac 100644
--- a/disk/Makefile
+++ b/disk/Makefile
@@ -5,7 +5,7 @@
#ccflags-y += -DET_DEBUG -DDEBUG
-obj-$(CONFIG_PARTITIONS) += part.o
+obj-$(CONFIG_$(SPL_)PARTITIONS) += part.o
obj-$(CONFIG_$(SPL_)MAC_PARTITION) += part_mac.o
obj-$(CONFIG_$(SPL_)DOS_PARTITION) += part_dos.o
obj-$(CONFIG_$(SPL_)ISO_PARTITION) += part_iso.o
diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
index c23b6682a6..425ec3259f 100644
--- a/drivers/block/blk-uclass.c
+++ b/drivers/block/blk-uclass.c
@@ -649,7 +649,7 @@ int blk_unbind_all(int if_type)
static int blk_post_probe(struct udevice *dev)
{
-#if defined(CONFIG_PARTITIONS) && defined(CONFIG_HAVE_BLOCK_DEVICE)
+#if CONFIG_IS_ENABLED(PARTITIONS) && defined(CONFIG_HAVE_BLOCK_DEVICE)
struct blk_desc *desc = dev_get_uclass_platdata(dev);
part_init(desc);
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 7af6b120b6..3535978634 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -82,7 +82,7 @@ else
libs-$(CONFIG_SPL_LIBCOMMON_SUPPORT) += common/ cmd/ env/
libs-$(CONFIG_SPL_LIBGENERIC_SUPPORT) += lib/
ifdef CONFIG_SPL_FRAMEWORK
-libs-$(CONFIG_PARTITIONS) += disk/
+libs-$(CONFIG_SPL_PARTITIONS) += disk/
endif
endif
--
2.17.1
Re: [U-Boot] [PATCH v4 2/2] board: Add support for iMX8QXP AI_ML board
On Thu, 15 Aug 2019 13:46:30 +0530 Manivannan Sadhasivam wrote: > Hi Lukasz, > > On Thu, Aug 15, 2019 at 09:51:25AM +0200, Lukasz Majewski wrote: > > Hi Manivannan, > > > > > Hi Lukasz, > > > > > > Thanks for the review! > > > > > > On Wed, Jul 24, 2019 at 10:07:13AM +0200, Lukasz Majewski wrote: > > > > Hi Manivannan, > > > > > > > > > This commit adds initial board support for iMX8QXP AI_ML board > > > > > from Einfochips. This board is one of the 96Boards Consumer > > > > > Edition and AI boards of the 96Boards family based on i.MX8QXP > > > > > SoC from NXP/Freescale. > > > > > > > > > > This initial supports contains following peripherals which are > > > > > tested and known to work: > > > > > > > > > > 1. Debug serial via UART2 > > > > > 2. SD card > > > > > 3. Ethernet > > > > > > > > > > More information about this board can be found in arrow > > > > > website: > > > > > https://www.arrow.com/en/products/imx8-ai-ml/arrow-development-tools > > > > > > > > > > Signed-off-by: Manivannan Sadhasivam > > > > > --- > > > > > arch/arm/mach-imx/imx8/Kconfig| 6 + > > > > > board/einfochips/imx8qxp_ai_ml/Kconfig| 12 ++ > > > > > board/einfochips/imx8qxp_ai_ml/MAINTAINERS| 6 + > > > > > board/einfochips/imx8qxp_ai_ml/Makefile | 8 ++ > > > > > board/einfochips/imx8qxp_ai_ml/README | 49 > > > > > .../einfochips/imx8qxp_ai_ml/imx8qxp_ai_ml.c | 117 > > > > > ++ > > > > > board/einfochips/imx8qxp_ai_ml/imximage.cfg | 24 > > > > > board/einfochips/imx8qxp_ai_ml/spl.c | 49 > > > > > configs/imx8qxp_ai_ml_defconfig | 83 > > > > > + include/configs/imx8qxp_ai_ml.h | > > > > > 104 10 files changed, 458 insertions(+) > > > > > create mode 100644 board/einfochips/imx8qxp_ai_ml/Kconfig > > > > > create mode 100644 board/einfochips/imx8qxp_ai_ml/MAINTAINERS > > > > > create mode 100644 board/einfochips/imx8qxp_ai_ml/Makefile > > > > > create mode 100644 board/einfochips/imx8qxp_ai_ml/README > > > > > create mode 100644 > > > > > board/einfochips/imx8qxp_ai_ml/imx8qxp_ai_ml.c create mode > > > > > 100644 board/einfochips/imx8qxp_ai_ml/imximage.cfg create > > > > > mode 100644 board/einfochips/imx8qxp_ai_ml/spl.c create mode > > > > > 100644 configs/imx8qxp_ai_ml_defconfig create mode 100644 > > > > > include/configs/imx8qxp_ai_ml.h > > > > > > > > > > diff --git a/arch/arm/mach-imx/imx8/Kconfig > > > > > b/arch/arm/mach-imx/imx8/Kconfig index bbe323d5ca..cec21f8dd2 > > > > > 100644 --- a/arch/arm/mach-imx/imx8/Kconfig > > > > > +++ b/arch/arm/mach-imx/imx8/Kconfig > > > > > @@ -37,6 +37,11 @@ config TARGET_COLIBRI_IMX8X > > > > > select BOARD_LATE_INIT > > > > > select IMX8QXP > > > > > > > > > > +config TARGET_IMX8QXP_AI_ML > > > > > + bool "Support i.MX8QXP AI_ML board" > > > > > + select BOARD_LATE_INIT > > > > > + select IMX8QXP > > > > > + > > > > > config TARGET_IMX8QM_MEK > > > > > bool "Support i.MX8QM MEK board" > > > > > select BOARD_LATE_INIT > > > > > @@ -49,6 +54,7 @@ config TARGET_IMX8QXP_MEK > > > > > > > > > > endchoice > > > > > > > > > > +source "board/einfochips/imx8qxp_ai_ml/Kconfig" > > > > > source "board/freescale/imx8qm_mek/Kconfig" > > > > > source "board/freescale/imx8qxp_mek/Kconfig" > > > > > source "board/toradex/apalis-imx8/Kconfig" > > > > > diff --git a/board/einfochips/imx8qxp_ai_ml/Kconfig > > > > > b/board/einfochips/imx8qxp_ai_ml/Kconfig new file mode 100644 > > > > > index 00..697a831013 > > > > > --- /dev/null > > > > > +++ b/board/einfochips/imx8qxp_ai_ml/Kconfig > > > > > @@ -0,0 +1,12 @@ > > > > > +if TARGET_IMX8QXP_AI_ML > > > > > + > > > > > +config SYS_BOARD > > > > > + default "imx8qxp_ai_ml" > > > > > + > > > > > +config SYS_VENDOR > > > > > + default "einfochips" > > > > > + > > > > > +config SYS_CONFIG_NAME > > > > > + default "imx8qxp_ai_ml" > > > > > + > > > > > +endif > > > > > diff --git a/board/einfochips/imx8qxp_ai_ml/MAINTAINERS > > > > > b/board/einfochips/imx8qxp_ai_ml/MAINTAINERS new file mode > > > > > 100644 index 00..add0bd9431 > > > > > --- /dev/null > > > > > +++ b/board/einfochips/imx8qxp_ai_ml/MAINTAINERS > > > > > @@ -0,0 +1,6 @@ > > > > > +i.MX8QXP AI_ML BOARD > > > > > +M: Manivannan Sadhasivam > > > > > +S:Maintained > > > > > +F: board/einfochips/imx8qxp_ai_ml/ > > > > > +F: include/configs/imx8qxp_ai_ml.h > > > > > +F: configs/imx8qxp_ai_ml_defconfig > > > > > diff --git a/board/einfochips/imx8qxp_ai_ml/Makefile > > > > > b/board/einfochips/imx8qxp_ai_ml/Makefile new file mode 100644 > > > > > index 00..e08774dc6e > > > > > --- /dev/null > > > > > +++ b/board/einfochips/imx8qxp_ai_ml/Makefile > > > > > @@ -0,0 +1,8 @@ > > > > > +# > > > > > +# Copyright 2019 Linaro Ltd. > > > > > +# > > > > > +# SPDX-License-Identifier: GPL-2.0+ > > > > > +# > > > > > + > > > > > +obj-y
[U-Boot] [PATCH v5 2/2] board: Add support for iMX8QXP AI_ML board
This commit adds initial board support for iMX8QXP AI_ML board from Einfochips. This board is one of the 96Boards Consumer Edition and AI boards of the 96Boards family based on i.MX8QXP SoC from NXP/Freescale. This initial supports contains following peripherals which are tested and known to work: 1. Debug serial via UART2 2. SD card 3. Ethernet More information about this board can be found in arrow website: https://www.arrow.com/en/products/imx8-ai-ml/arrow-development-tools Signed-off-by: Manivannan Sadhasivam Reviewed-by: Peng Fan --- arch/arm/mach-imx/imx8/Kconfig| 6 ++ board/einfochips/imx8qxp_ai_ml/Kconfig| 21 board/einfochips/imx8qxp_ai_ml/MAINTAINERS| 6 ++ board/einfochips/imx8qxp_ai_ml/Makefile | 8 ++ board/einfochips/imx8qxp_ai_ml/README | 49 ++ .../einfochips/imx8qxp_ai_ml/imx8qxp_ai_ml.c | 79 +++ board/einfochips/imx8qxp_ai_ml/imximage.cfg | 24 + board/einfochips/imx8qxp_ai_ml/spl.c | 39 configs/imx8qxp_ai_ml_defconfig | 83 include/configs/imx8qxp_ai_ml.h | 95 +++ 10 files changed, 410 insertions(+) create mode 100644 board/einfochips/imx8qxp_ai_ml/Kconfig create mode 100644 board/einfochips/imx8qxp_ai_ml/MAINTAINERS create mode 100644 board/einfochips/imx8qxp_ai_ml/Makefile create mode 100644 board/einfochips/imx8qxp_ai_ml/README create mode 100644 board/einfochips/imx8qxp_ai_ml/imx8qxp_ai_ml.c create mode 100644 board/einfochips/imx8qxp_ai_ml/imximage.cfg create mode 100644 board/einfochips/imx8qxp_ai_ml/spl.c create mode 100644 configs/imx8qxp_ai_ml_defconfig create mode 100644 include/configs/imx8qxp_ai_ml.h diff --git a/arch/arm/mach-imx/imx8/Kconfig b/arch/arm/mach-imx/imx8/Kconfig index bbe323d5ca..bb877055f8 100644 --- a/arch/arm/mach-imx/imx8/Kconfig +++ b/arch/arm/mach-imx/imx8/Kconfig @@ -37,6 +37,11 @@ config TARGET_COLIBRI_IMX8X select BOARD_LATE_INIT select IMX8QXP +config TARGET_IMX8QXP_AI_ML + bool "Support i.MX8QXP AI_ML board" + select BOARD_EARLY_INIT_F + select IMX8QXP + config TARGET_IMX8QM_MEK bool "Support i.MX8QM MEK board" select BOARD_LATE_INIT @@ -49,6 +54,7 @@ config TARGET_IMX8QXP_MEK endchoice +source "board/einfochips/imx8qxp_ai_ml/Kconfig" source "board/freescale/imx8qm_mek/Kconfig" source "board/freescale/imx8qxp_mek/Kconfig" source "board/toradex/apalis-imx8/Kconfig" diff --git a/board/einfochips/imx8qxp_ai_ml/Kconfig b/board/einfochips/imx8qxp_ai_ml/Kconfig new file mode 100644 index 00..b6806b8859 --- /dev/null +++ b/board/einfochips/imx8qxp_ai_ml/Kconfig @@ -0,0 +1,21 @@ +if TARGET_IMX8QXP_AI_ML + +config SYS_BOARD + default "imx8qxp_ai_ml" + +config SYS_VENDOR + default "einfochips" + +config SYS_CONFIG_NAME + default "imx8qxp_ai_ml" + +config SYS_MALLOC_LEN + default 0x240 + +config ENV_SIZE + default 0x1000 + +config ENV_OFFSET + default 0x40 + +endif diff --git a/board/einfochips/imx8qxp_ai_ml/MAINTAINERS b/board/einfochips/imx8qxp_ai_ml/MAINTAINERS new file mode 100644 index 00..add0bd9431 --- /dev/null +++ b/board/einfochips/imx8qxp_ai_ml/MAINTAINERS @@ -0,0 +1,6 @@ +i.MX8QXP AI_ML BOARD +M: Manivannan Sadhasivam +S: Maintained +F: board/einfochips/imx8qxp_ai_ml/ +F: include/configs/imx8qxp_ai_ml.h +F: configs/imx8qxp_ai_ml_defconfig diff --git a/board/einfochips/imx8qxp_ai_ml/Makefile b/board/einfochips/imx8qxp_ai_ml/Makefile new file mode 100644 index 00..e08774dc6e --- /dev/null +++ b/board/einfochips/imx8qxp_ai_ml/Makefile @@ -0,0 +1,8 @@ +# +# Copyright 2019 Linaro Ltd. +# +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-y += imx8qxp_ai_ml.o +obj-$(CONFIG_SPL_BUILD) += spl.o diff --git a/board/einfochips/imx8qxp_ai_ml/README b/board/einfochips/imx8qxp_ai_ml/README new file mode 100644 index 00..488920580f --- /dev/null +++ b/board/einfochips/imx8qxp_ai_ml/README @@ -0,0 +1,49 @@ +U-Boot for the Einfochips i.MX8QXP AI_ML board + +Quick Start +=== + +- Get and Build the ARM Trusted firmware +- Get scfw_tcm.bin and ahab-container.img +- Build U-Boot +- Flash the binary into the SD card +- Boot + +Get and Build the ARM Trusted firmware +== + +$ git clone https://source.codeaurora.org/external/imx/imx-atf +$ cd imx-atf/ +$ git checkout origin/imx_4.9.88_imx8qxp_beta2 -b imx_4.9.88_imx8qxp_beta2 +$ make PLAT=imx8qxp bl31 + +Get scfw_tcm.bin and ahab-container.img +=== + +$ wget https://raw.githubusercontent.com/96boards-ai-ml/binaries/master/mx8qx-aiml-scfw-tcm.bin +$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.1.bin +$ chmod +x firmware-imx-8.1.bin +$ ./firmware-imx-8.1.bin + +Copy the following binaries to U-Boot folder: + +$ cp imx-atf/build/imx8qxp/release/bl31.bin . +$ cp
[U-Boot] [PATCH v5 1/2] arm: dts: Add devicetree support for iMXQXP AI_ML board
Add devicetree support for iMXQXP AI_ML board from Einfochips.
Signed-off-by: Manivannan Sadhasivam
Reviewed-by: Peng Fan
Reviewed-by: Lukasz Majewski
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/fsl-imx8qxp-ai_ml-u-boot.dtsi | 117 +
arch/arm/dts/fsl-imx8qxp-ai_ml.dts | 181 +
3 files changed, 299 insertions(+)
create mode 100644 arch/arm/dts/fsl-imx8qxp-ai_ml-u-boot.dtsi
create mode 100644 arch/arm/dts/fsl-imx8qxp-ai_ml.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index e6680e5e98..7834a158da 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -614,6 +614,7 @@ dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb
dtb-$(CONFIG_ARCH_IMX8) += \
fsl-imx8qm-apalis.dtb \
fsl-imx8qm-mek.dtb \
+ fsl-imx8qxp-ai_ml.dtb \
fsl-imx8qxp-colibri.dtb \
fsl-imx8qxp-mek.dtb
diff --git a/arch/arm/dts/fsl-imx8qxp-ai_ml-u-boot.dtsi
b/arch/arm/dts/fsl-imx8qxp-ai_ml-u-boot.dtsi
new file mode 100644
index 00..3ca53bb945
--- /dev/null
+++ b/arch/arm/dts/fsl-imx8qxp-ai_ml-u-boot.dtsi
@@ -0,0 +1,117 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019 Linaro Ltd.
+ */
+
+&{/imx8qx-pm} {
+
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+_lsio {
+ u-boot,dm-spl;
+};
+
+_lsio_gpio0 {
+ u-boot,dm-spl;
+};
+
+_lsio_gpio1 {
+ u-boot,dm-spl;
+};
+
+_lsio_gpio2 {
+ u-boot,dm-spl;
+};
+
+_lsio_gpio3 {
+ u-boot,dm-spl;
+};
+
+_lsio_gpio4 {
+ u-boot,dm-spl;
+};
+
+_lsio_gpio5 {
+ u-boot,dm-spl;
+};
+
+_lsio_gpio6 {
+ u-boot,dm-spl;
+};
+
+_lsio_gpio7 {
+ u-boot,dm-spl;
+};
+
+_conn {
+ u-boot,dm-spl;
+};
+
+_conn_sdch0 {
+ u-boot,dm-spl;
+};
+
+_conn_sdch1 {
+ u-boot,dm-spl;
+};
+
+_conn_sdch2 {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/fsl-imx8qxp-ai_ml.dts
b/arch/arm/dts/fsl-imx8qxp-ai_ml.dts
new file mode 100644
index 00..aa85caaff5
--- /dev/null
+++ b/arch/arm/dts/fsl-imx8qxp-ai_ml.dts
@@ -0,0 +1,181 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2018 Einfochips
+ * Copyright 2019 Linaro Ltd.
+ */
+
+/dts-v1/;
+
+#include "fsl-imx8qxp.dtsi"
+#include "fsl-imx8qxp-ai_ml-u-boot.dtsi"
+
+/ {
+ model = "Einfochips i.MX8QXP AI_ML";
+ compatible = "einfochips,imx8qxp-ai_ml", "fsl,imx8qxp";
+
+ chosen {
+ bootargs = "console=ttyLP2,115200
earlycon=lpuart32,0x5a08,115200";
+ stdout-path =
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ reg = <0x 0x8000 0 0x8000>;
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_lpuart0>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_lpuart1>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_lpuart2>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_lpuart3>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_fec1>;
+ phy-mode = "rgmii";
+ phy-handle = <>;
+ fsl,ar8031-phy-fixup;
+ fsl,magic-packet;
+ phy-reset-gpios = < 14 GPIO_ACTIVE_LOW>;
+ phy-reset-duration = <10>;
+ phy-reset-post-delay = <150>;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ };
+ };
+};
+
+/* LS-I2C1 */
+ {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <10>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_lpi2c1>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_usdhc1>;
+ bus-width = <4>;
+ no-sd;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_usdhc2>;
+ bus-width = <4>;
+ cd-gpios = < 22 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+ {
+ pinctrl_fec1: fec1grp {
+ fsl,pins = <
+ SC_P_COMP_CTL_GPIO_1V8_3V3_ENET_ENETB0_PAD
0x14a0
+ SC_P_COMP_CTL_GPIO_1V8_3V3_ENET_ENETB1_PAD
0x14a0
+ SC_P_ENET0_MDC_CONN_ENET0_MDC
0x0620
+
[U-Boot] [PATCH v5 0/2] Add board support for iMX8QXP AI_ML board
Hello, This patchset adds initial board support for iMX8QXP AI_ML board from Einfochips. This board is one of the Consumer Edition and AI boards of the 96Boards family. This initial supports contains following peripherals which are tested and known to work: 1. Debug serial via UART2 2. SD card 3. Ethernet Below is the boot log from SPL to Linux kernel: === MMC: FSL_SDHC: 0, FSL_SDHC: 1 Loading Environment from MMC... *** Warning - bad CRC, using default environment In:serial@5a08 Out: serial@5a08 Err: serial@5a08 Net: Warning: ethernet@5b04 (eth0) using random MAC address - d2:46:66:cf:f5:61 eth0: ethernet@5b04 Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found /extlinux/extlinux.conf Retrieving file: /extlinux/extlinux.conf 171 bytes read in 14 ms (11.7 KiB/s) 1: ai_ml-kernel Retrieving file: /Image 24689152 bytes read in 1055 ms (22.3 MiB/s) append: earlycon console=ttyLP2,115200 rw root=/dev/mmcblk0p2 rootfstype=ext4 init=/sbin/t Retrieving file: /imx8qxp-ai_ml.dtb 12529 bytes read in 13 ms (940.4 KiB/s) ## Flattened Device Tree blob at 8300 Booting using the fdt blob at 0x8300 Using Device Tree in place at 8300, end 830060f0 Starting kernel ... [0.00] Booting Linux on physical CPU 0x00 [0x410fd042] [0.00] Linux version 5.2.0-03138-gd75da80dce39 (mani@Mani-XPS-13-9360) (gcc versi9 [0.00] Machine model: Einfochips i.MX8QXP AI_ML [0.00] efi: Getting EFI parameters from FDT: [0.00] efi: UEFI not found. [0.00] cma: Reserved 32 MiB at 0xfe00 [0.00] earlycon: lpuart32 at MMIO 0x5a08 (options '') [0.00] printk: bootconsole [lpuart32] enabled Thanks, Mani Note: This patchset depends on the below cleanup patches submitted: [U-Boot,1/2] arm: imx8: factor out uart init code [U-Boot,2/2] arm: imx8: don't duplicate build_info() Changes in v5: * Incorporated review comments from Lukasz. Changes in v4: * Incorporated review comments from Fabio. Changes in v3: * Incorporated review comments from Fabio. Major change is switching to distro_boot. * Added Reviewed-by tag from Peng Fan. Changes in v2: * Rebased the patches on top of following patches: [U-Boot,1/2] arm: imx8: factor out uart init code [U-Boot,2/2] arm: imx8: don't duplicate build_info() Manivannan Sadhasivam (2): arm: dts: Add devicetree support for iMXQXP AI_ML board board: Add support for iMX8QXP AI_ML board arch/arm/dts/Makefile | 1 + arch/arm/dts/fsl-imx8qxp-ai_ml-u-boot.dtsi| 117 +++ arch/arm/dts/fsl-imx8qxp-ai_ml.dts| 181 ++ arch/arm/mach-imx/imx8/Kconfig| 6 + board/einfochips/imx8qxp_ai_ml/Kconfig| 21 ++ board/einfochips/imx8qxp_ai_ml/MAINTAINERS| 6 + board/einfochips/imx8qxp_ai_ml/Makefile | 8 + board/einfochips/imx8qxp_ai_ml/README | 49 + .../einfochips/imx8qxp_ai_ml/imx8qxp_ai_ml.c | 79 board/einfochips/imx8qxp_ai_ml/imximage.cfg | 24 +++ board/einfochips/imx8qxp_ai_ml/spl.c | 39 configs/imx8qxp_ai_ml_defconfig | 83 include/configs/imx8qxp_ai_ml.h | 95 + 13 files changed, 709 insertions(+) create mode 100644 arch/arm/dts/fsl-imx8qxp-ai_ml-u-boot.dtsi create mode 100644 arch/arm/dts/fsl-imx8qxp-ai_ml.dts create mode 100644 board/einfochips/imx8qxp_ai_ml/Kconfig create mode 100644 board/einfochips/imx8qxp_ai_ml/MAINTAINERS create mode 100644 board/einfochips/imx8qxp_ai_ml/Makefile create mode 100644 board/einfochips/imx8qxp_ai_ml/README create mode 100644 board/einfochips/imx8qxp_ai_ml/imx8qxp_ai_ml.c create mode 100644 board/einfochips/imx8qxp_ai_ml/imximage.cfg create mode 100644 board/einfochips/imx8qxp_ai_ml/spl.c create mode 100644 configs/imx8qxp_ai_ml_defconfig create mode 100644 include/configs/imx8qxp_ai_ml.h -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3] ram: rk3399: update cap and ddrconfig for each channel after init
We need to store all the ram related cap/map info back to register
for each channel after all the init has been done in case some of register
was reset during the process.
Signed-off-by: YouMin Chen
Signed-off-by: Kever Yang
---
Changes in v3:
- update commit message
Changes in v2:
- fix compile error for non lpddr4 driver
drivers/ram/rockchip/sdram_rk3399.c | 159 ++--
1 file changed, 81 insertions(+), 78 deletions(-)
diff --git a/drivers/ram/rockchip/sdram_rk3399.c
b/drivers/ram/rockchip/sdram_rk3399.c
index 81fc71c051..ed70137ce7 100644
--- a/drivers/ram/rockchip/sdram_rk3399.c
+++ b/drivers/ram/rockchip/sdram_rk3399.c
@@ -1488,6 +1488,84 @@ static void dram_all_config(struct dram_info *dram,
clrsetbits_le32(>cru->glb_rst_con, 0x3, 0x3);
}
+static void set_cap_relate_config(const struct chan_info *chan,
+ struct rk3399_sdram_params *params,
+ unsigned int channel)
+{
+ u32 *denali_ctl = chan->pctl->denali_ctl;
+ u32 tmp;
+ struct rk3399_msch_timings *noc_timing;
+
+ if (params->base.dramtype == LPDDR3) {
+ tmp = (8 << params->ch[channel].cap_info.bw) /
+ (8 << params->ch[channel].cap_info.dbw);
+
+ /**
+* memdata_ratio
+* 1 -> 0, 2 -> 1, 4 -> 2
+*/
+ clrsetbits_le32(_ctl[197], 0x7,
+ (tmp >> 1));
+ clrsetbits_le32(_ctl[198], 0x7 << 8,
+ (tmp >> 1) << 8);
+ }
+
+ noc_timing = >ch[channel].noc_timings;
+
+ /*
+* noc timing bw relate timing is 32 bit, and real bw is 16bit
+* actually noc reg is setting at function dram_all_config
+*/
+ if (params->ch[channel].cap_info.bw == 16 &&
+ noc_timing->ddrmode.b.mwrsize == 2) {
+ if (noc_timing->ddrmode.b.burstsize)
+ noc_timing->ddrmode.b.burstsize -= 1;
+ noc_timing->ddrmode.b.mwrsize -= 1;
+ noc_timing->ddrtimingc0.b.burstpenalty *= 2;
+ noc_timing->ddrtimingc0.b.wrtomwr *= 2;
+ }
+}
+
+static u32 calculate_ddrconfig(struct rk3399_sdram_params *params, u32 channel)
+{
+ unsigned int cs0_row = params->ch[channel].cap_info.cs0_row;
+ unsigned int col = params->ch[channel].cap_info.col;
+ unsigned int bw = params->ch[channel].cap_info.bw;
+ u16 ddr_cfg_2_rbc[] = {
+ /*
+* [6]highest bit col
+* [5:3] max row(14+n)
+* [2]insertion row
+* [1:0] col(9+n),col, data bus 32bit
+*
+* highbitcol, max_row, insertion_row, col
+*/
+ ((0 << 6) | (2 << 3) | (0 << 2) | 0), /* 0 */
+ ((0 << 6) | (2 << 3) | (0 << 2) | 1), /* 1 */
+ ((0 << 6) | (1 << 3) | (0 << 2) | 2), /* 2 */
+ ((0 << 6) | (0 << 3) | (0 << 2) | 3), /* 3 */
+ ((0 << 6) | (2 << 3) | (1 << 2) | 1), /* 4 */
+ ((0 << 6) | (1 << 3) | (1 << 2) | 2), /* 5 */
+ ((1 << 6) | (0 << 3) | (0 << 2) | 2), /* 6 */
+ ((1 << 6) | (1 << 3) | (0 << 2) | 2), /* 7 */
+ };
+ u32 i;
+
+ col -= (bw == 2) ? 0 : 1;
+ col -= 9;
+
+ for (i = 0; i < 4; i++) {
+ if ((col == (ddr_cfg_2_rbc[i] & 0x3)) &&
+ (cs0_row <= (((ddr_cfg_2_rbc[i] >> 3) & 0x7) + 14)))
+ break;
+ }
+
+ if (i >= 4)
+ i = -EINVAL;
+
+ return i;
+}
+
#if !defined(CONFIG_RAM_RK3399_LPDDR4)
static int default_data_training(struct dram_info *dram, u32 channel, u8 rank,
struct rk3399_sdram_params *params)
@@ -1588,84 +1666,6 @@ static void set_ddr_stride(struct rk3399_pmusgrf_regs
*pmusgrf, u32 stride)
rk_clrsetreg(>soc_con4, 0x1f << 10, stride << 10);
}
-static void set_cap_relate_config(const struct chan_info *chan,
- struct rk3399_sdram_params *params,
- unsigned int channel)
-{
- u32 *denali_ctl = chan->pctl->denali_ctl;
- u32 tmp;
- struct rk3399_msch_timings *noc_timing;
-
- if (params->base.dramtype == LPDDR3) {
- tmp = (8 << params->ch[channel].cap_info.bw) /
- (8 << params->ch[channel].cap_info.dbw);
-
- /**
-* memdata_ratio
-* 1 -> 0, 2 -> 1, 4 -> 2
-*/
- clrsetbits_le32(_ctl[197], 0x7,
- (tmp >> 1));
- clrsetbits_le32(_ctl[198], 0x7 << 8,
- (tmp >> 1) << 8);
- }
-
- noc_timing = >ch[channel].noc_timings;
-
- /*
-* noc timing bw relate timing is 32 bit, and real bw is 16bit
-* actually noc
Re: [U-Boot] [PATCH v4 2/2] board: Add support for iMX8QXP AI_ML board
Hi Lukasz, On Thu, Aug 15, 2019 at 09:51:25AM +0200, Lukasz Majewski wrote: > Hi Manivannan, > > > Hi Lukasz, > > > > Thanks for the review! > > > > On Wed, Jul 24, 2019 at 10:07:13AM +0200, Lukasz Majewski wrote: > > > Hi Manivannan, > > > > > > > This commit adds initial board support for iMX8QXP AI_ML board > > > > from Einfochips. This board is one of the 96Boards Consumer > > > > Edition and AI boards of the 96Boards family based on i.MX8QXP > > > > SoC from NXP/Freescale. > > > > > > > > This initial supports contains following peripherals which are > > > > tested and known to work: > > > > > > > > 1. Debug serial via UART2 > > > > 2. SD card > > > > 3. Ethernet > > > > > > > > More information about this board can be found in arrow website: > > > > https://www.arrow.com/en/products/imx8-ai-ml/arrow-development-tools > > > > > > > > Signed-off-by: Manivannan Sadhasivam > > > > --- > > > > arch/arm/mach-imx/imx8/Kconfig| 6 + > > > > board/einfochips/imx8qxp_ai_ml/Kconfig| 12 ++ > > > > board/einfochips/imx8qxp_ai_ml/MAINTAINERS| 6 + > > > > board/einfochips/imx8qxp_ai_ml/Makefile | 8 ++ > > > > board/einfochips/imx8qxp_ai_ml/README | 49 > > > > .../einfochips/imx8qxp_ai_ml/imx8qxp_ai_ml.c | 117 > > > > ++ board/einfochips/imx8qxp_ai_ml/imximage.cfg | > > > > 24 board/einfochips/imx8qxp_ai_ml/spl.c | 49 > > > > configs/imx8qxp_ai_ml_defconfig | 83 > > > > + include/configs/imx8qxp_ai_ml.h | 104 > > > > 10 files changed, 458 insertions(+) > > > > create mode 100644 board/einfochips/imx8qxp_ai_ml/Kconfig > > > > create mode 100644 board/einfochips/imx8qxp_ai_ml/MAINTAINERS > > > > create mode 100644 board/einfochips/imx8qxp_ai_ml/Makefile > > > > create mode 100644 board/einfochips/imx8qxp_ai_ml/README > > > > create mode 100644 board/einfochips/imx8qxp_ai_ml/imx8qxp_ai_ml.c > > > > create mode 100644 board/einfochips/imx8qxp_ai_ml/imximage.cfg > > > > create mode 100644 board/einfochips/imx8qxp_ai_ml/spl.c > > > > create mode 100644 configs/imx8qxp_ai_ml_defconfig > > > > create mode 100644 include/configs/imx8qxp_ai_ml.h > > > > > > > > diff --git a/arch/arm/mach-imx/imx8/Kconfig > > > > b/arch/arm/mach-imx/imx8/Kconfig index bbe323d5ca..cec21f8dd2 > > > > 100644 --- a/arch/arm/mach-imx/imx8/Kconfig > > > > +++ b/arch/arm/mach-imx/imx8/Kconfig > > > > @@ -37,6 +37,11 @@ config TARGET_COLIBRI_IMX8X > > > > select BOARD_LATE_INIT > > > > select IMX8QXP > > > > > > > > +config TARGET_IMX8QXP_AI_ML > > > > + bool "Support i.MX8QXP AI_ML board" > > > > + select BOARD_LATE_INIT > > > > + select IMX8QXP > > > > + > > > > config TARGET_IMX8QM_MEK > > > > bool "Support i.MX8QM MEK board" > > > > select BOARD_LATE_INIT > > > > @@ -49,6 +54,7 @@ config TARGET_IMX8QXP_MEK > > > > > > > > endchoice > > > > > > > > +source "board/einfochips/imx8qxp_ai_ml/Kconfig" > > > > source "board/freescale/imx8qm_mek/Kconfig" > > > > source "board/freescale/imx8qxp_mek/Kconfig" > > > > source "board/toradex/apalis-imx8/Kconfig" > > > > diff --git a/board/einfochips/imx8qxp_ai_ml/Kconfig > > > > b/board/einfochips/imx8qxp_ai_ml/Kconfig new file mode 100644 > > > > index 00..697a831013 > > > > --- /dev/null > > > > +++ b/board/einfochips/imx8qxp_ai_ml/Kconfig > > > > @@ -0,0 +1,12 @@ > > > > +if TARGET_IMX8QXP_AI_ML > > > > + > > > > +config SYS_BOARD > > > > + default "imx8qxp_ai_ml" > > > > + > > > > +config SYS_VENDOR > > > > + default "einfochips" > > > > + > > > > +config SYS_CONFIG_NAME > > > > + default "imx8qxp_ai_ml" > > > > + > > > > +endif > > > > diff --git a/board/einfochips/imx8qxp_ai_ml/MAINTAINERS > > > > b/board/einfochips/imx8qxp_ai_ml/MAINTAINERS new file mode 100644 > > > > index 00..add0bd9431 > > > > --- /dev/null > > > > +++ b/board/einfochips/imx8qxp_ai_ml/MAINTAINERS > > > > @@ -0,0 +1,6 @@ > > > > +i.MX8QXP AI_ML BOARD > > > > +M: Manivannan Sadhasivam > > > > +S: Maintained > > > > +F: board/einfochips/imx8qxp_ai_ml/ > > > > +F: include/configs/imx8qxp_ai_ml.h > > > > +F: configs/imx8qxp_ai_ml_defconfig > > > > diff --git a/board/einfochips/imx8qxp_ai_ml/Makefile > > > > b/board/einfochips/imx8qxp_ai_ml/Makefile new file mode 100644 > > > > index 00..e08774dc6e > > > > --- /dev/null > > > > +++ b/board/einfochips/imx8qxp_ai_ml/Makefile > > > > @@ -0,0 +1,8 @@ > > > > +# > > > > +# Copyright 2019 Linaro Ltd. > > > > +# > > > > +# SPDX-License-Identifier: GPL-2.0+ > > > > +# > > > > + > > > > +obj-y += imx8qxp_ai_ml.o > > > > +obj-$(CONFIG_SPL_BUILD) += spl.o > > > > diff --git a/board/einfochips/imx8qxp_ai_ml/README > > > > b/board/einfochips/imx8qxp_ai_ml/README new file mode 100644 > > > > index 00..488920580f > > > > --- /dev/null > > > > +++ b/board/einfochips/imx8qxp_ai_ml/README >
[U-Boot] [PATCH 3/4] rockchip: rk3328: migrate u-boot node to -u-boot.dtsi
Move all the nodes only shown in u-boot to -u-boot.dtsi to make
rk3328.dtsi clean.
Signed-off-by: Kever Yang
---
arch/arm/dts/rk3328-evb-u-boot.dtsi| 31 +++---
arch/arm/dts/rk3328-evb.dts| 5 ---
arch/arm/dts/rk3328-rock64-u-boot.dtsi | 33 ++-
arch/arm/dts/rk3328-u-boot.dtsi| 58 ++
arch/arm/dts/rk3328.dtsi | 24 ---
5 files changed, 66 insertions(+), 85 deletions(-)
create mode 100644 arch/arm/dts/rk3328-u-boot.dtsi
diff --git a/arch/arm/dts/rk3328-evb-u-boot.dtsi
b/arch/arm/dts/rk3328-evb-u-boot.dtsi
index 58ebf52b4b..4a827063c5 100644
--- a/arch/arm/dts/rk3328-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-evb-u-boot.dtsi
@@ -1,33 +1,12 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ * (C) Copyright 2016-2019 Rockchip Electronics Co., Ltd
*/
+#include "rk3328-u-boot.dtsi"
#include "rk3328-sdram-ddr3-666.dtsi"
-/ {
- aliases {
- mmc0 =
- mmc1 =
- };
-
- chosen {
- u-boot,spl-boot-order = ,
- };
-};
-
- {
- u-boot,dm-pre-reloc;
-};
-
- {
- u-boot,dm-pre-reloc;
-};
-
- {
- u-boot,dm-pre-reloc;
-};
-
- {
- u-boot,dm-pre-reloc;
+_host0_xhci {
+ vbus-supply = <_host_xhci>;
+ status = "okay";
};
diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts
index ec594a8452..a2ee838fcd 100644
--- a/arch/arm/dts/rk3328-evb.dts
+++ b/arch/arm/dts/rk3328-evb.dts
@@ -116,11 +116,6 @@
status = "okay";
};
-_host0_xhci {
- vbus-supply = <_host_xhci>;
- status = "okay";
-};
-
{
clock-frequency = <40>;
i2c-scl-rising-time-ns = <168>;
diff --git a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
index 21c2afca3c..1d441f7124 100644
--- a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
@@ -1,38 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0+
/*
- * (C) Copyright 2018 Rockchip Electronics Co., Ltd
- *
- * SPDX-License-Identifier: GPL-2.0+
+ * (C) Copyright 2018-2019 Rockchip Electronics Co., Ltd
*/
+#include "rk3328-u-boot.dtsi"
#include "rk3328-sdram-lpddr3-1600.dtsi"
-/ {
- aliases {
- mmc0 =
- mmc1 =
- };
-
- chosen {
- u-boot,spl-boot-order = ,
- };
-};
-
- {
- u-boot,dm-pre-reloc;
-};
-
- {
- u-boot,dm-pre-reloc;
-};
-
- {
- u-boot,dm-pre-reloc;
-};
-
- {
- u-boot,dm-pre-reloc;
-};
-
_host0_xhci {
status = "okay";
};
diff --git a/arch/arm/dts/rk3328-u-boot.dtsi b/arch/arm/dts/rk3328-u-boot.dtsi
new file mode 100644
index 00..ffbd657e31
--- /dev/null
+++ b/arch/arm/dts/rk3328-u-boot.dtsi
@@ -0,0 +1,58 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2019 Rockchip Electronics Co., Ltd
+ */
+
+/ {
+ aliases {
+ mmc0 =
+ mmc1 =
+ };
+
+ chosen {
+ u-boot,spl-boot-order = ,
+ };
+
+ dmc: dmc {
+ u-boot,dm-pre-reloc;
+ compatible = "rockchip,rk3328-dmc";
+ reg = <0x0 0xff40 0x0 0x1000
+ 0x0 0xff78 0x0 0x3000
+ 0x0 0xff10 0x0 0x1000
+ 0x0 0xff44 0x0 0x1000
+ 0x0 0xff72 0x0 0x1000
+ 0x0 0xff798000 0x0 0x1000>;
+ };
+
+ usb_host0_xhci: usb@ff60 {
+ compatible = "rockchip,rk3328-xhci";
+ reg = <0x0 0xff60 0x0 0x10>;
+ interrupts = ;
+ snps,dis-enblslpm-quirk;
+ snps,phyif-utmi-bits = <16>;
+ snps,dis-u2-freeclk-exists-quirk;
+ snps,dis-u2-susphy-quirk;
+ status = "disabled";
+ };
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+ clock-frequency = <2400>;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/rk3328.dtsi b/arch/arm/dts/rk3328.dtsi
index a080ae8d69..060c84e6c0 100644
--- a/arch/arm/dts/rk3328.dtsi
+++ b/arch/arm/dts/rk3328.dtsi
@@ -186,7 +186,6 @@
};
grf: syscon@ff10 {
- u-boot,dm-pre-reloc;
compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
reg = <0x0 0xff10 0x0 0x1000>;
@@ -232,7 +231,6 @@
interrupts = ;
clocks = < SCLK_UART2>, < PCLK_UART2>;
clock-names = "baudclk", "apb_pclk";
- clock-frequency = <2400>;
reg-shift = <2>;
reg-io-width = <4>;
dmas = < 6>, < 7>;
@@ -351,17 +349,6 @@
status = "disabled";
};
- dmc: dmc {
- u-boot,dm-pre-reloc;
-
[U-Boot] [PATCH 4/4] rockchip: dts: rk3328-rock64: fix usb power supply
According to rock64 schemetic, both VCC_HOST1_5V and VCC_HOST_5V are
controlled by USB20_HOST_DRV(GPIO0A2), fix it so that we can get correct
power supply for USB HOST ports.
Signed-off-by: Kever Yang
---
arch/arm/dts/rk3328-rock64.dts | 23 ++-
1 file changed, 2 insertions(+), 21 deletions(-)
diff --git a/arch/arm/dts/rk3328-rock64.dts b/arch/arm/dts/rk3328-rock64.dts
index 7bcc53fcce..a78eb4ac6f 100644
--- a/arch/arm/dts/rk3328-rock64.dts
+++ b/arch/arm/dts/rk3328-rock64.dts
@@ -34,23 +34,10 @@
vcc_host_5v: vcc-host-5v-regulator {
compatible = "regulator-fixed";
- enable-active-high;
- gpio = < RK_PA0 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <_host_drv>;
- regulator-name = "vcc_host_5v";
- regulator-always-on;
- regulator-boot-on;
- vin-supply = <_sys>;
- };
-
- vcc_host1_5v: vcc_otg_5v: vcc-host1-5v-regulator {
- compatible = "regulator-fixed";
- enable-active-high;
- gpio = < RK_PA2 GPIO_ACTIVE_HIGH>;
+ gpio = < RK_PA2 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <_host_drv>;
- regulator-name = "vcc_host1_5v";
+ regulator-name = "vcc_host_5v";
regulator-always-on;
regulator-boot-on;
vin-supply = <_sys>;
@@ -244,12 +231,6 @@
rockchip,pins = <0 RK_PA2 RK_FUNC_GPIO _pull_none>;
};
};
-
- usb3 {
- usb30_host_drv: usb30-host-drv {
- rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO _pull_none>;
- };
- };
};
{
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/4] rockchip: dts: rk3328-rock64: enable usb3 xhci controller
Rock64 has a USB3.0 port, enable the controller so that we can use it.
Signed-off-by: Kever Yang
---
arch/arm/dts/rk3328-rock64-u-boot.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
index dbcce6ac64..21c2afca3c 100644
--- a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
@@ -32,3 +32,7 @@
{
u-boot,dm-pre-reloc;
};
+
+_host0_xhci {
+ status = "okay";
+};
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/4] rockchip: clk: rk3328: add clk_enable ops for HCLK_HOST0
Required to successfully probe the ehci generic driver
Signed-off-by: Kever Yang
---
drivers/clk/rockchip/clk_rk3328.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/clk/rockchip/clk_rk3328.c
b/drivers/clk/rockchip/clk_rk3328.c
index a89e2ecc4a..5957a00402 100644
--- a/drivers/clk/rockchip/clk_rk3328.c
+++ b/drivers/clk/rockchip/clk_rk3328.c
@@ -745,10 +745,22 @@ static int rk3328_clk_set_parent(struct clk *clk, struct
clk *parent)
return -ENOENT;
}
+static int rk3328_clk_enable(struct clk *clk)
+{
+ switch (clk->id) {
+ case HCLK_HOST0:
+ /* Required to successfully probe the ehci generic driver */
+ return 0;
+ }
+
+ return -ENOENT;
+}
+
static struct clk_ops rk3328_clk_ops = {
.get_rate = rk3328_clk_get_rate,
.set_rate = rk3328_clk_set_rate,
.set_parent = rk3328_clk_set_parent,
+ .enable = rk3328_clk_enable,
};
static int rk3328_clk_probe(struct udevice *dev)
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH v4 1/5] spl: dm: disable SPI DM flash for non-DM SPL
On Thu, 15 Aug 2019 07:57:00 + Chuanhua Han wrote: > > -Original Message- > > From: Lukasz Majewski > > Sent: 2019年8月15日 15:54 > > To: Chuanhua Han > > Cc: Jagan Teki ; Xiaowei Bao > > ; U-Boot-Denx ; Pan > > Jiafei ; Jagan Teki ; > > Ruchika Gupta > > Subject: Re: [U-Boot] [EXT] Re: [PATCH v4 1/5] spl: dm: disable SPI > > DM flash for non-DM SPL > > > > On Thu, 15 Aug 2019 07:39:45 + > > Chuanhua Han wrote: > > > > > > -Original Message- > > > > From: Lukasz Majewski > > > > Sent: 2019年8月15日 15:15 > > > > To: Chuanhua Han > > > > Cc: Jagan Teki ; Xiaowei Bao > > > > ; U-Boot-Denx ; Pan > > > > Jiafei ; Jagan Teki > > > > ; Ruchika Gupta > > > > Subject: Re: [U-Boot] [EXT] Re: [PATCH v4 1/5] spl: dm: disable > > > > SPI DM flash for non-DM SPL > > > > > > > > On Thu, 15 Aug 2019 03:35:28 + > > > > Chuanhua Han wrote: > > > > > > > > > > -Original Message- > > > > > > From: Lukasz Majewski > > > > > > Sent: 2019年8月14日 19:39 > > > > > > To: Chuanhua Han > > > > > > Cc: Jagan Teki ; Xiaowei Bao > > > > > > ; U-Boot-Denx ; > > > > > > Pan Jiafei ; Jagan Teki > > > > > > ; Ruchika Gupta > > > > > > Subject: Re: [U-Boot] [EXT] Re: [PATCH v4 1/5] spl: dm: > > > > > > disable SPI DM flash for non-DM SPL > > > > > > > > > > > > On Wed, 14 Aug 2019 11:10:46 + Chuanhua Han > > > > > > wrote: > > > > > > > > > > > > > > -Original Message- > > > > > > > > From: Lukasz Majewski > > > > > > > > Sent: 2019年8月14日 18:53 > > > > > > > > To: Chuanhua Han > > > > > > > > Cc: Jagan Teki ; Xiaowei Bao > > > > > > > > ; U-Boot-Denx > > > > > > > > ; Pan Jiafei > > > > > > > > ; Jagan Teki > > > > > > > > ; Ruchika Gupta > > > > > > > > Subject: Re: [U-Boot] [EXT] Re: > > > > > > > > [PATCH v4 1/5] spl: dm: disable SPI DM flash for non-DM > > > > > > > > SPL > > > > > > > > > > > > > > > > On Wed, 14 Aug 2019 10:41:32 + Chuanhua Han > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > > > > From: Lukasz Majewski > > > > > > > > > > Sent: 2019年8月14日 16:57 > > > > > > > > > > To: Chuanhua Han > > > > > > > > > > Cc: Jagan Teki ; > > > > > > > > > > Xiaowei Bao ; U-Boot-Denx > > > > > > > > > > ; Pan Jiafei > > > > > > > > > > ; Jagan Teki > > > > > > > > > > ; Ruchika Gupta > > > > > > > > > > Subject: Re: [U-Boot] [EXT] > > > > > > > > > > Re: [PATCH v4 1/5] spl: dm: disable SPI DM flash > > > > > > > > > > for non-DM SPL > > > > > > > > > > > > > > > > > > > > Hi Chuanhua, > > > > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > > > > > > From: Jagan Teki > > > > > > > > > > > > Sent: 2019年8月14日 15:45 > > > > > > > > > > > > To: Chuanhua Han > > > > > > > > > > > > Cc: Wolfgang Denk ; Shengzhou Liu > > > > > > > > > > > > ; Ruchika Gupta > > > > > > > > > > > > ; Jagan Teki > > > > > > > > > > > > ; Simon Glass > > > > > > > > > > > > ; Prabhakar Kushwaha > > > > > > > > > > > > ; U-Boot-Denx > > > > > > > > > > > > ; Pan Jiafei > > > > > > > > > > > > Subject: [EXT] Re: > > > > > > > > > > > > [U-Boot] [PATCH v4 1/5] spl: dm: disable SPI DM > > > > > > > > > > > > flash for non-DM SPL > > > > > > > > > > > > > > > > > > > > > > > > Caution: EXT Email > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jun 21, 2019 at 7:51 AM Chuanhua Han > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > This patch solves the problem that spiboot > > > > > > > > > > > > > cannot be performed in non-DM SPL. > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Pan Jiafei > > > > > > > > > > > > > Signed-off-by: > > > > > > > > > > > > > Chuanhua Han --- > > > > > > > > > > > > > Changes in v4: > > > > > > > > > > > > > - No change. > > > > > > > > > > > > > Changes in v3: > > > > > > > > > > > > > - Add a cover-letter for this patch > > > > > > > > > > > > > set. Changes in v2: > > > > > > > > > > > > > - No change. > > > > > > > > > > > > > > > > > > > > > > > > > > include/config_uncmd_spl.h | 1 + > > > > > > > > > > > > > 1 file changed, 1 insertion(+) > > > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/include/config_uncmd_spl.h > > > > > > > > > > > > > b/include/config_uncmd_spl.h index > > > > > > > > > > > > > c2f9735ce7..da94b3d9df 100644 --- > > > > > > > > > > > > > a/include/config_uncmd_spl.h +++ > > > > > > > > > > > > > b/include/config_uncmd_spl.h @@ -15,6 +15,7 @@ > > > > > > > > > > > > > #undef CONFIG_DM_GPIO #undef CONFIG_DM_I2C > > #undef > > > > > > > > > > > > > CONFIG_DM_SPI > > > > > > > > > > > > > +#undef CONFIG_DM_SPI_FLASH > > > > > > > > > > > > > > > > > > > > > > > > Have you made any Travis-CI run? > > > > > > > > > > > I tested it with a local board > > > > > > > > > > > > > > > > > > > > Could you be so kind and also test following > > > > > > > > > > patchset (parts from Layerscape also needs testing): > > > > > > > > > >
Re: [U-Boot] [PATCH] global_data: Move x86 specific GD flags into common flags
Hi Simon,
On 15.08.19 09:35, Simon Goldschmidt wrote:
Hi Stefan,
On Thu, Aug 15, 2019 at 9:05 AM Stefan Roese wrote:
Currently the upper 16 bits of the GD flags are reserved for
architecture specific flags. But only x86 uses 2 bits of these 16 bits
and sprinkling those flags in multiple headers is confusing and does not
scale.
This patch now moves the x86 flags into the common header and removes
the comment about the reservation of the upper 16 bits.
Signed-off-by: Stefan Roese
Cc: Bin Meng
Cc: Simon Glass
Cc: Tom Rini
Cc: Simon Goldschmidt
---
arch/x86/include/asm/global_data.h | 6 --
include/asm-generic/global_data.h | 6 +-
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/global_data.h
b/arch/x86/include/asm/global_data.h
index 797397e697..17a4d34491 100644
--- a/arch/x86/include/asm/global_data.h
+++ b/arch/x86/include/asm/global_data.h
@@ -137,10 +137,4 @@ static inline __attribute__((no_instrument_function)) gd_t
*get_fs_gd_ptr(void)
#endif
-/*
- * Our private Global Data Flags
- */
-#define GD_FLG_COLD_BOOT 0x1 /* Cold Boot */
-#define GD_FLG_WARM_BOOT 0x2 /* Warm Boot */
-
#endif /* __ASM_GBL_DATA_H */
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
index 5372d5d8cd..42ae61c781 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -150,7 +150,7 @@ typedef struct global_data {
#endif
/*
- * Global Data Flags - the top 16 bits are reserved for arch-specific flags
+ * Common Global Data Flags
*/
#define GD_FLG_RELOC 0x1 /* Code was relocated to RAM */
#define GD_FLG_DEVINIT 0x2 /* Devices have been initialized */
@@ -170,4 +170,8 @@ typedef struct global_data {
#define GD_FLG_LOG_READY 0x08000 /* Log system is ready for use */
#define GD_FLG_WDT_READY 0x1 /* Watchdog is ready for use */
+/* x86 specific GD flags */
+#define GD_FLG_COLD_BOOT 0x2 /* Cold Boot */
+#define GD_FLG_WARM_BOOT 0x4 /* Warm Boot */
I think this change is generally good, but I failed to find code using the flag
GD_FLG_WARM_BOOT (it's only set, not checked). Only the cold-boot flag is used
(in coreboot's last_stage_init).
So, since we don't have too many bits free here, instead of wasting 2 for x86,
could we probably remove one of these. Especially since you can either have
warm OR cold, but not both (so the absence of 'WARM' could mean 'COLD')?
Yes. I already commented on those 2 x86 bits and their (non-)usage:
https://lists.denx.de/pipermail/u-boot/2019-August/380634.html
&
https://lists.denx.de/pipermail/u-boot/2019-August/380800.html
My suggestion is to apply this patch now and re-work the x86 flags usage
in a later patch (most likely remove one of those bits). The main reason
being that this double usage of 0x1 needs to get fixed quickly.
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH v4 1/5] spl: dm: disable SPI DM flash for non-DM SPL
> -Original Message- > From: Lukasz Majewski > Sent: 2019年8月15日 15:54 > To: Chuanhua Han > Cc: Jagan Teki ; Xiaowei Bao > ; U-Boot-Denx ; Pan Jiafei > ; Jagan Teki ; Ruchika > Gupta > Subject: Re: [U-Boot] [EXT] Re: [PATCH v4 1/5] spl: dm: disable SPI DM flash > for > non-DM SPL > > On Thu, 15 Aug 2019 07:39:45 + > Chuanhua Han wrote: > > > > -Original Message- > > > From: Lukasz Majewski > > > Sent: 2019年8月15日 15:15 > > > To: Chuanhua Han > > > Cc: Jagan Teki ; Xiaowei Bao > > > ; U-Boot-Denx ; Pan > > > Jiafei ; Jagan Teki ; > > > Ruchika Gupta > > > Subject: Re: [U-Boot] [EXT] Re: [PATCH v4 1/5] spl: dm: disable SPI > > > DM flash for non-DM SPL > > > > > > On Thu, 15 Aug 2019 03:35:28 + > > > Chuanhua Han wrote: > > > > > > > > -Original Message- > > > > > From: Lukasz Majewski > > > > > Sent: 2019年8月14日 19:39 > > > > > To: Chuanhua Han > > > > > Cc: Jagan Teki ; Xiaowei Bao > > > > > ; U-Boot-Denx ; Pan > > > > > Jiafei ; Jagan Teki > > > > > ; Ruchika Gupta > > > > > Subject: Re: [U-Boot] [EXT] Re: [PATCH v4 1/5] spl: dm: disable > > > > > SPI DM flash for non-DM SPL > > > > > > > > > > On Wed, 14 Aug 2019 11:10:46 + Chuanhua Han > > > > > wrote: > > > > > > > > > > > > -Original Message- > > > > > > > From: Lukasz Majewski > > > > > > > Sent: 2019年8月14日 18:53 > > > > > > > To: Chuanhua Han > > > > > > > Cc: Jagan Teki ; Xiaowei Bao > > > > > > > ; U-Boot-Denx ; > > > > > > > Pan Jiafei ; Jagan Teki > > > > > > > ; Ruchika Gupta > > > > > > > Subject: Re: [U-Boot] [EXT] Re: [PATCH v4 1/5] spl: dm: > > > > > > > disable SPI DM flash for non-DM SPL > > > > > > > > > > > > > > On Wed, 14 Aug 2019 10:41:32 + Chuanhua Han > > > > > > > wrote: > > > > > > > > > > > > > > > > -Original Message- > > > > > > > > > From: Lukasz Majewski > > > > > > > > > Sent: 2019年8月14日 16:57 > > > > > > > > > To: Chuanhua Han > > > > > > > > > Cc: Jagan Teki ; Xiaowei Bao > > > > > > > > > ; U-Boot-Denx > > > > > > > > > ; Pan Jiafei > > > > > > > > > ; Jagan Teki > > > > > > > > > ; Ruchika Gupta > > > > > > > > > Subject: Re: [U-Boot] [EXT] Re: > > > > > > > > > [PATCH v4 1/5] spl: dm: disable SPI DM flash for non-DM > > > > > > > > > SPL > > > > > > > > > > > > > > > > > > Hi Chuanhua, > > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > > > > > From: Jagan Teki > > > > > > > > > > > Sent: 2019年8月14日 15:45 > > > > > > > > > > > To: Chuanhua Han > > > > > > > > > > > Cc: Wolfgang Denk ; Shengzhou Liu > > > > > > > > > > > ; Ruchika Gupta > > > > > > > > > > > ; Jagan Teki > > > > > > > > > > > ; Simon Glass > > > > > > > > > > > ; Prabhakar Kushwaha > > > > > > > > > > > ; U-Boot-Denx > > > > > > > > > > > ; Pan Jiafei > > > > > > > > > > > Subject: [EXT] Re: > > > > > > > > > > > [U-Boot] [PATCH v4 1/5] spl: dm: disable SPI DM > > > > > > > > > > > flash for non-DM SPL > > > > > > > > > > > > > > > > > > > > > > Caution: EXT Email > > > > > > > > > > > > > > > > > > > > > > On Fri, Jun 21, 2019 at 7:51 AM Chuanhua Han > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > This patch solves the problem that spiboot cannot > > > > > > > > > > > > be performed in non-DM SPL. > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Pan Jiafei > > > > > > > > > > > > Signed-off-by: > > > > > > > > > > > > Chuanhua Han --- Changes in > > > > > > > > > > > > v4: > > > > > > > > > > > > - No change. > > > > > > > > > > > > Changes in v3: > > > > > > > > > > > > - Add a cover-letter for this patch set. > > > > > > > > > > > > Changes in v2: > > > > > > > > > > > > - No change. > > > > > > > > > > > > > > > > > > > > > > > > include/config_uncmd_spl.h | 1 + > > > > > > > > > > > > 1 file changed, 1 insertion(+) > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/include/config_uncmd_spl.h > > > > > > > > > > > > b/include/config_uncmd_spl.h index > > > > > > > > > > > > c2f9735ce7..da94b3d9df 100644 --- > > > > > > > > > > > > a/include/config_uncmd_spl.h +++ > > > > > > > > > > > > b/include/config_uncmd_spl.h @@ -15,6 +15,7 @@ > > > > > > > > > > > > #undef CONFIG_DM_GPIO #undef CONFIG_DM_I2C > #undef > > > > > > > > > > > > CONFIG_DM_SPI > > > > > > > > > > > > +#undef CONFIG_DM_SPI_FLASH > > > > > > > > > > > > > > > > > > > > > > Have you made any Travis-CI run? > > > > > > > > > > I tested it with a local board > > > > > > > > > > > > > > > > > > Could you be so kind and also test following patchset > > > > > > > > > (parts from Layerscape also needs testing): > > > > > > > > > https://patchwork.ozlabs.org/cover/1146494/ > > > > > > > > I don't quite understand this patch. How can I test it? > > > > > > > > > > > > > > You need to apply it first to -master branch. > > > > > > > > > > > > > > Then apply your board code (or if it is already in mainline > > > > > > > just remove the #undef(s) from include/config_uncmd_spl.h) > > > > > > > > > > > > > >
Re: [U-Boot] [EXT] Re: [PATCH v4 1/5] spl: dm: disable SPI DM flash for non-DM SPL
On Thu, 15 Aug 2019 07:39:45 + Chuanhua Han wrote: > > -Original Message- > > From: Lukasz Majewski > > Sent: 2019年8月15日 15:15 > > To: Chuanhua Han > > Cc: Jagan Teki ; Xiaowei Bao > > ; U-Boot-Denx ; Pan > > Jiafei ; Jagan Teki ; > > Ruchika Gupta > > Subject: Re: [U-Boot] [EXT] Re: [PATCH v4 1/5] spl: dm: disable SPI > > DM flash for non-DM SPL > > > > On Thu, 15 Aug 2019 03:35:28 + > > Chuanhua Han wrote: > > > > > > -Original Message- > > > > From: Lukasz Majewski > > > > Sent: 2019年8月14日 19:39 > > > > To: Chuanhua Han > > > > Cc: Jagan Teki ; Xiaowei Bao > > > > ; U-Boot-Denx ; Pan > > > > Jiafei ; Jagan Teki > > > > ; Ruchika Gupta > > > > Subject: Re: [U-Boot] [EXT] Re: [PATCH v4 1/5] spl: dm: disable > > > > SPI DM flash for non-DM SPL > > > > > > > > On Wed, 14 Aug 2019 11:10:46 + > > > > Chuanhua Han wrote: > > > > > > > > > > -Original Message- > > > > > > From: Lukasz Majewski > > > > > > Sent: 2019年8月14日 18:53 > > > > > > To: Chuanhua Han > > > > > > Cc: Jagan Teki ; Xiaowei Bao > > > > > > ; U-Boot-Denx ; > > > > > > Pan Jiafei ; Jagan Teki > > > > > > ; Ruchika Gupta > > > > > > Subject: Re: [U-Boot] [EXT] Re: [PATCH v4 1/5] spl: dm: > > > > > > disable SPI DM flash for non-DM SPL > > > > > > > > > > > > On Wed, 14 Aug 2019 10:41:32 + Chuanhua Han > > > > > > wrote: > > > > > > > > > > > > > > -Original Message- > > > > > > > > From: Lukasz Majewski > > > > > > > > Sent: 2019年8月14日 16:57 > > > > > > > > To: Chuanhua Han > > > > > > > > Cc: Jagan Teki ; Xiaowei Bao > > > > > > > > ; U-Boot-Denx > > > > > > > > ; Pan Jiafei > > > > > > > > ; Jagan Teki > > > > > > > > ; Ruchika Gupta > > > > > > > > Subject: Re: [U-Boot] [EXT] Re: > > > > > > > > [PATCH v4 1/5] spl: dm: disable SPI DM flash for non-DM > > > > > > > > SPL > > > > > > > > > > > > > > > > Hi Chuanhua, > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > > > > From: Jagan Teki > > > > > > > > > > Sent: 2019年8月14日 15:45 > > > > > > > > > > To: Chuanhua Han > > > > > > > > > > Cc: Wolfgang Denk ; Shengzhou Liu > > > > > > > > > > ; Ruchika Gupta > > > > > > > > > > ; Jagan Teki > > > > > > > > > > ; Simon Glass > > > > > > > > > > ; Prabhakar Kushwaha > > > > > > > > > > ; U-Boot-Denx > > > > > > > > > > ; Pan Jiafei > > > > > > > > > > Subject: [EXT] Re: > > > > > > > > > > [U-Boot] [PATCH v4 1/5] spl: dm: disable SPI DM > > > > > > > > > > flash for non-DM SPL > > > > > > > > > > > > > > > > > > > > Caution: EXT Email > > > > > > > > > > > > > > > > > > > > On Fri, Jun 21, 2019 at 7:51 AM Chuanhua Han > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > This patch solves the problem that spiboot cannot > > > > > > > > > > > be performed in non-DM SPL. > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Pan Jiafei > > > > > > > > > > > Signed-off-by: > > > > > > > > > > > Chuanhua Han --- > > > > > > > > > > > Changes in v4: > > > > > > > > > > > - No change. > > > > > > > > > > > Changes in v3: > > > > > > > > > > > - Add a cover-letter for this patch set. > > > > > > > > > > > Changes in v2: > > > > > > > > > > > - No change. > > > > > > > > > > > > > > > > > > > > > > include/config_uncmd_spl.h | 1 + > > > > > > > > > > > 1 file changed, 1 insertion(+) > > > > > > > > > > > > > > > > > > > > > > diff --git a/include/config_uncmd_spl.h > > > > > > > > > > > b/include/config_uncmd_spl.h index > > > > > > > > > > > c2f9735ce7..da94b3d9df 100644 --- > > > > > > > > > > > a/include/config_uncmd_spl.h +++ > > > > > > > > > > > b/include/config_uncmd_spl.h @@ -15,6 +15,7 @@ > > > > > > > > > > > #undef CONFIG_DM_GPIO #undef CONFIG_DM_I2C > > > > > > > > > > > #undef CONFIG_DM_SPI > > > > > > > > > > > +#undef CONFIG_DM_SPI_FLASH > > > > > > > > > > > > > > > > > > > > Have you made any Travis-CI run? > > > > > > > > > I tested it with a local board > > > > > > > > > > > > > > > > Could you be so kind and also test following patchset > > > > > > > > (parts from Layerscape also needs testing): > > > > > > > > https://patchwork.ozlabs.org/cover/1146494/ > > > > > > > I don't quite understand this patch. How can I test it? > > > > > > > > > > > > You need to apply it first to -master branch. > > > > > > > > > > > > Then apply your board code (or if it is already in mainline > > > > > > just remove the #undef(s) from include/config_uncmd_spl.h) > > > > > > > > > > > > As a last step - run make menuconfig and enable SPL_DM_SPI* > > > > > > flags. > > > > > Currently, it is in the master, and SPI* in the #undef(s) from > > > > > include/ uncmd_spl.h has been deleted, but an error was > > > > > reported: CC spl/lib/display_options.o drivers/spi/spi.c: In > > > > > function 'spi_do_alloc_slave': drivers/spi/spi.c:34:8: error: > > > > > 'struct spi_slave' has no member named 'bus' slave->bus = bus; > > > > > ^~ > > > > > drivers/spi/spi.c:35:8: error: 'struct
Re: [U-Boot] [PATCH v4 2/2] board: Add support for iMX8QXP AI_ML board
Hi Manivannan, > Hi Lukasz, > > Thanks for the review! > > On Wed, Jul 24, 2019 at 10:07:13AM +0200, Lukasz Majewski wrote: > > Hi Manivannan, > > > > > This commit adds initial board support for iMX8QXP AI_ML board > > > from Einfochips. This board is one of the 96Boards Consumer > > > Edition and AI boards of the 96Boards family based on i.MX8QXP > > > SoC from NXP/Freescale. > > > > > > This initial supports contains following peripherals which are > > > tested and known to work: > > > > > > 1. Debug serial via UART2 > > > 2. SD card > > > 3. Ethernet > > > > > > More information about this board can be found in arrow website: > > > https://www.arrow.com/en/products/imx8-ai-ml/arrow-development-tools > > > > > > Signed-off-by: Manivannan Sadhasivam > > > --- > > > arch/arm/mach-imx/imx8/Kconfig| 6 + > > > board/einfochips/imx8qxp_ai_ml/Kconfig| 12 ++ > > > board/einfochips/imx8qxp_ai_ml/MAINTAINERS| 6 + > > > board/einfochips/imx8qxp_ai_ml/Makefile | 8 ++ > > > board/einfochips/imx8qxp_ai_ml/README | 49 > > > .../einfochips/imx8qxp_ai_ml/imx8qxp_ai_ml.c | 117 > > > ++ board/einfochips/imx8qxp_ai_ml/imximage.cfg | > > > 24 board/einfochips/imx8qxp_ai_ml/spl.c | 49 > > > configs/imx8qxp_ai_ml_defconfig | 83 > > > + include/configs/imx8qxp_ai_ml.h | 104 > > > 10 files changed, 458 insertions(+) > > > create mode 100644 board/einfochips/imx8qxp_ai_ml/Kconfig > > > create mode 100644 board/einfochips/imx8qxp_ai_ml/MAINTAINERS > > > create mode 100644 board/einfochips/imx8qxp_ai_ml/Makefile > > > create mode 100644 board/einfochips/imx8qxp_ai_ml/README > > > create mode 100644 board/einfochips/imx8qxp_ai_ml/imx8qxp_ai_ml.c > > > create mode 100644 board/einfochips/imx8qxp_ai_ml/imximage.cfg > > > create mode 100644 board/einfochips/imx8qxp_ai_ml/spl.c > > > create mode 100644 configs/imx8qxp_ai_ml_defconfig > > > create mode 100644 include/configs/imx8qxp_ai_ml.h > > > > > > diff --git a/arch/arm/mach-imx/imx8/Kconfig > > > b/arch/arm/mach-imx/imx8/Kconfig index bbe323d5ca..cec21f8dd2 > > > 100644 --- a/arch/arm/mach-imx/imx8/Kconfig > > > +++ b/arch/arm/mach-imx/imx8/Kconfig > > > @@ -37,6 +37,11 @@ config TARGET_COLIBRI_IMX8X > > > select BOARD_LATE_INIT > > > select IMX8QXP > > > > > > +config TARGET_IMX8QXP_AI_ML > > > + bool "Support i.MX8QXP AI_ML board" > > > + select BOARD_LATE_INIT > > > + select IMX8QXP > > > + > > > config TARGET_IMX8QM_MEK > > > bool "Support i.MX8QM MEK board" > > > select BOARD_LATE_INIT > > > @@ -49,6 +54,7 @@ config TARGET_IMX8QXP_MEK > > > > > > endchoice > > > > > > +source "board/einfochips/imx8qxp_ai_ml/Kconfig" > > > source "board/freescale/imx8qm_mek/Kconfig" > > > source "board/freescale/imx8qxp_mek/Kconfig" > > > source "board/toradex/apalis-imx8/Kconfig" > > > diff --git a/board/einfochips/imx8qxp_ai_ml/Kconfig > > > b/board/einfochips/imx8qxp_ai_ml/Kconfig new file mode 100644 > > > index 00..697a831013 > > > --- /dev/null > > > +++ b/board/einfochips/imx8qxp_ai_ml/Kconfig > > > @@ -0,0 +1,12 @@ > > > +if TARGET_IMX8QXP_AI_ML > > > + > > > +config SYS_BOARD > > > + default "imx8qxp_ai_ml" > > > + > > > +config SYS_VENDOR > > > + default "einfochips" > > > + > > > +config SYS_CONFIG_NAME > > > + default "imx8qxp_ai_ml" > > > + > > > +endif > > > diff --git a/board/einfochips/imx8qxp_ai_ml/MAINTAINERS > > > b/board/einfochips/imx8qxp_ai_ml/MAINTAINERS new file mode 100644 > > > index 00..add0bd9431 > > > --- /dev/null > > > +++ b/board/einfochips/imx8qxp_ai_ml/MAINTAINERS > > > @@ -0,0 +1,6 @@ > > > +i.MX8QXP AI_ML BOARD > > > +M: Manivannan Sadhasivam > > > +S:Maintained > > > +F: board/einfochips/imx8qxp_ai_ml/ > > > +F: include/configs/imx8qxp_ai_ml.h > > > +F: configs/imx8qxp_ai_ml_defconfig > > > diff --git a/board/einfochips/imx8qxp_ai_ml/Makefile > > > b/board/einfochips/imx8qxp_ai_ml/Makefile new file mode 100644 > > > index 00..e08774dc6e > > > --- /dev/null > > > +++ b/board/einfochips/imx8qxp_ai_ml/Makefile > > > @@ -0,0 +1,8 @@ > > > +# > > > +# Copyright 2019 Linaro Ltd. > > > +# > > > +# SPDX-License-Identifier: GPL-2.0+ > > > +# > > > + > > > +obj-y += imx8qxp_ai_ml.o > > > +obj-$(CONFIG_SPL_BUILD) += spl.o > > > diff --git a/board/einfochips/imx8qxp_ai_ml/README > > > b/board/einfochips/imx8qxp_ai_ml/README new file mode 100644 > > > index 00..488920580f > > > --- /dev/null > > > +++ b/board/einfochips/imx8qxp_ai_ml/README > > > > Thank you for preparing the README file, appreciated :-). > > > > > @@ -0,0 +1,49 @@ > > > +U-Boot for the Einfochips i.MX8QXP AI_ML board > > > + > > > +Quick Start > > > +=== > > > + > > > +- Get and Build the ARM Trusted firmware > > > +- Get scfw_tcm.bin and ahab-container.img > > > +- Build U-Boot > > > +- Flash the binary into the SD card
Re: [U-Boot] [EXT] Re: [PATCH v4 1/5] spl: dm: disable SPI DM flash for non-DM SPL
> -Original Message- > From: Lukasz Majewski > Sent: 2019年8月15日 15:15 > To: Chuanhua Han > Cc: Jagan Teki ; Xiaowei Bao > ; U-Boot-Denx ; Pan Jiafei > ; Jagan Teki ; Ruchika > Gupta > Subject: Re: [U-Boot] [EXT] Re: [PATCH v4 1/5] spl: dm: disable SPI DM flash > for > non-DM SPL > > On Thu, 15 Aug 2019 03:35:28 + > Chuanhua Han wrote: > > > > -Original Message- > > > From: Lukasz Majewski > > > Sent: 2019年8月14日 19:39 > > > To: Chuanhua Han > > > Cc: Jagan Teki ; Xiaowei Bao > > > ; U-Boot-Denx ; Pan > > > Jiafei ; Jagan Teki ; > > > Ruchika Gupta > > > Subject: Re: [U-Boot] [EXT] Re: [PATCH v4 1/5] spl: dm: disable SPI > > > DM flash for non-DM SPL > > > > > > On Wed, 14 Aug 2019 11:10:46 + > > > Chuanhua Han wrote: > > > > > > > > -Original Message- > > > > > From: Lukasz Majewski > > > > > Sent: 2019年8月14日 18:53 > > > > > To: Chuanhua Han > > > > > Cc: Jagan Teki ; Xiaowei Bao > > > > > ; U-Boot-Denx ; Pan > > > > > Jiafei ; Jagan Teki > > > > > ; Ruchika Gupta > > > > > Subject: Re: [U-Boot] [EXT] Re: [PATCH v4 1/5] spl: dm: disable > > > > > SPI DM flash for non-DM SPL > > > > > > > > > > On Wed, 14 Aug 2019 10:41:32 + Chuanhua Han > > > > > wrote: > > > > > > > > > > > > -Original Message- > > > > > > > From: Lukasz Majewski > > > > > > > Sent: 2019年8月14日 16:57 > > > > > > > To: Chuanhua Han > > > > > > > Cc: Jagan Teki ; Xiaowei Bao > > > > > > > ; U-Boot-Denx ; > > > > > > > Pan Jiafei ; Jagan Teki > > > > > > > ; Ruchika Gupta > > > > > > > Subject: Re: [U-Boot] [EXT] Re: [PATCH v4 1/5] spl: dm: > > > > > > > disable SPI DM flash for non-DM SPL > > > > > > > > > > > > > > Hi Chuanhua, > > > > > > > > > > > > > > > > -Original Message- > > > > > > > > > From: Jagan Teki > > > > > > > > > Sent: 2019年8月14日 15:45 > > > > > > > > > To: Chuanhua Han > > > > > > > > > Cc: Wolfgang Denk ; Shengzhou Liu > > > > > > > > > ; Ruchika Gupta > > > > > > > > > ; Jagan Teki > > > > > > > > > ; Simon Glass ; > > > > > > > > > Prabhakar Kushwaha ; > > > > > > > > > U-Boot-Denx ; Pan Jiafei > > > > > > > > > Subject: [EXT] Re: [U-Boot] > > > > > > > > > [PATCH v4 1/5] spl: dm: disable SPI DM flash for non-DM > > > > > > > > > SPL > > > > > > > > > > > > > > > > > > Caution: EXT Email > > > > > > > > > > > > > > > > > > On Fri, Jun 21, 2019 at 7:51 AM Chuanhua Han > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > This patch solves the problem that spiboot cannot be > > > > > > > > > > performed in non-DM SPL. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Pan Jiafei > > > > > > > > > > Signed-off-by: Chuanhua Han > > > > > > > > > > --- > > > > > > > > > > Changes in v4: > > > > > > > > > > - No change. > > > > > > > > > > Changes in v3: > > > > > > > > > > - Add a cover-letter for this patch set. > > > > > > > > > > Changes in v2: > > > > > > > > > > - No change. > > > > > > > > > > > > > > > > > > > > include/config_uncmd_spl.h | 1 + > > > > > > > > > > 1 file changed, 1 insertion(+) > > > > > > > > > > > > > > > > > > > > diff --git a/include/config_uncmd_spl.h > > > > > > > > > > b/include/config_uncmd_spl.h index > > > > > > > > > > c2f9735ce7..da94b3d9df 100644 --- > > > > > > > > > > a/include/config_uncmd_spl.h +++ > > > > > > > > > > b/include/config_uncmd_spl.h @@ -15,6 +15,7 @@ #undef > > > > > > > > > > CONFIG_DM_GPIO #undef CONFIG_DM_I2C #undef > > > > > > > > > > CONFIG_DM_SPI > > > > > > > > > > +#undef CONFIG_DM_SPI_FLASH > > > > > > > > > > > > > > > > > > Have you made any Travis-CI run? > > > > > > > > I tested it with a local board > > > > > > > > > > > > > > Could you be so kind and also test following patchset (parts > > > > > > > from Layerscape also needs testing): > > > > > > > https://patchwork.ozlabs.org/cover/1146494/ > > > > > > I don't quite understand this patch. How can I test it? > > > > > > > > > > You need to apply it first to -master branch. > > > > > > > > > > Then apply your board code (or if it is already in mainline just > > > > > remove the #undef(s) from include/config_uncmd_spl.h) > > > > > > > > > > As a last step - run make menuconfig and enable SPL_DM_SPI* > > > > > flags. > > > > Currently, it is in the master, and SPI* in the #undef(s) from > > > > include/ uncmd_spl.h has been deleted, but an error was reported: > > > > CC spl/lib/display_options.o drivers/spi/spi.c: In function > > > > 'spi_do_alloc_slave': drivers/spi/spi.c:34:8: error: 'struct > > > > spi_slave' has no member named 'bus' slave->bus = bus; > > > > ^~ > > > > drivers/spi/spi.c:35:8: error: 'struct spi_slave' has no member > > > > named 'cs' slave->cs = cs; > > > > ^~ > > > > make[3]: *** [spl/drivers/spi/spi.o] Error 1 > > > > make[3]: *** Waiting for unfinished jobs > > > > make[2]: *** [spl/drivers/spi] Error 2 > > > > make[1]: *** [spl/drivers] Error 2 > > > > make[1]: *** Waiting for unfinished jobs > > > > LD spl/lib/built-in.o > > > >
Re: [U-Boot] [PATCH] global_data: Move x86 specific GD flags into common flags
Hi Stefan,
On Thu, Aug 15, 2019 at 9:05 AM Stefan Roese wrote:
>
> Currently the upper 16 bits of the GD flags are reserved for
> architecture specific flags. But only x86 uses 2 bits of these 16 bits
> and sprinkling those flags in multiple headers is confusing and does not
> scale.
>
> This patch now moves the x86 flags into the common header and removes
> the comment about the reservation of the upper 16 bits.
>
> Signed-off-by: Stefan Roese
> Cc: Bin Meng
> Cc: Simon Glass
> Cc: Tom Rini
> Cc: Simon Goldschmidt
> ---
> arch/x86/include/asm/global_data.h | 6 --
> include/asm-generic/global_data.h | 6 +-
> 2 files changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/arch/x86/include/asm/global_data.h
> b/arch/x86/include/asm/global_data.h
> index 797397e697..17a4d34491 100644
> --- a/arch/x86/include/asm/global_data.h
> +++ b/arch/x86/include/asm/global_data.h
> @@ -137,10 +137,4 @@ static inline __attribute__((no_instrument_function))
> gd_t *get_fs_gd_ptr(void)
>
> #endif
>
> -/*
> - * Our private Global Data Flags
> - */
> -#define GD_FLG_COLD_BOOT 0x1 /* Cold Boot */
> -#define GD_FLG_WARM_BOOT 0x2 /* Warm Boot */
> -
> #endif /* __ASM_GBL_DATA_H */
> diff --git a/include/asm-generic/global_data.h
> b/include/asm-generic/global_data.h
> index 5372d5d8cd..42ae61c781 100644
> --- a/include/asm-generic/global_data.h
> +++ b/include/asm-generic/global_data.h
> @@ -150,7 +150,7 @@ typedef struct global_data {
> #endif
>
> /*
> - * Global Data Flags - the top 16 bits are reserved for arch-specific flags
> + * Common Global Data Flags
> */
> #define GD_FLG_RELOC 0x1 /* Code was relocated to RAM */
> #define GD_FLG_DEVINIT 0x2 /* Devices have been initialized */
> @@ -170,4 +170,8 @@ typedef struct global_data {
> #define GD_FLG_LOG_READY 0x08000 /* Log system is ready for use */
> #define GD_FLG_WDT_READY 0x1 /* Watchdog is ready for use */
>
> +/* x86 specific GD flags */
> +#define GD_FLG_COLD_BOOT 0x2 /* Cold Boot */
> +#define GD_FLG_WARM_BOOT 0x4 /* Warm Boot */
I think this change is generally good, but I failed to find code using the flag
GD_FLG_WARM_BOOT (it's only set, not checked). Only the cold-boot flag is used
(in coreboot's last_stage_init).
So, since we don't have too many bits free here, instead of wasting 2 for x86,
could we probably remove one of these. Especially since you can either have
warm OR cold, but not both (so the absence of 'WARM' could mean 'COLD')?
Regards,
Simon
> +
> #endif /* __ASM_GENERIC_GBL_DATA_H */
> --
> 2.22.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] board: Add support for iMX8QXP AI_ML board
Hi Lukasz, Thanks for the review! On Wed, Jul 24, 2019 at 10:07:13AM +0200, Lukasz Majewski wrote: > Hi Manivannan, > > > This commit adds initial board support for iMX8QXP AI_ML board from > > Einfochips. This board is one of the 96Boards Consumer Edition and AI > > boards of the 96Boards family based on i.MX8QXP SoC from > > NXP/Freescale. > > > > This initial supports contains following peripherals which are tested > > and known to work: > > > > 1. Debug serial via UART2 > > 2. SD card > > 3. Ethernet > > > > More information about this board can be found in arrow website: > > https://www.arrow.com/en/products/imx8-ai-ml/arrow-development-tools > > > > Signed-off-by: Manivannan Sadhasivam > > --- > > arch/arm/mach-imx/imx8/Kconfig| 6 + > > board/einfochips/imx8qxp_ai_ml/Kconfig| 12 ++ > > board/einfochips/imx8qxp_ai_ml/MAINTAINERS| 6 + > > board/einfochips/imx8qxp_ai_ml/Makefile | 8 ++ > > board/einfochips/imx8qxp_ai_ml/README | 49 > > .../einfochips/imx8qxp_ai_ml/imx8qxp_ai_ml.c | 117 > > ++ board/einfochips/imx8qxp_ai_ml/imximage.cfg | > > 24 board/einfochips/imx8qxp_ai_ml/spl.c | 49 > > configs/imx8qxp_ai_ml_defconfig | 83 + > > include/configs/imx8qxp_ai_ml.h | 104 > > 10 files changed, 458 insertions(+) > > create mode 100644 board/einfochips/imx8qxp_ai_ml/Kconfig > > create mode 100644 board/einfochips/imx8qxp_ai_ml/MAINTAINERS > > create mode 100644 board/einfochips/imx8qxp_ai_ml/Makefile > > create mode 100644 board/einfochips/imx8qxp_ai_ml/README > > create mode 100644 board/einfochips/imx8qxp_ai_ml/imx8qxp_ai_ml.c > > create mode 100644 board/einfochips/imx8qxp_ai_ml/imximage.cfg > > create mode 100644 board/einfochips/imx8qxp_ai_ml/spl.c > > create mode 100644 configs/imx8qxp_ai_ml_defconfig > > create mode 100644 include/configs/imx8qxp_ai_ml.h > > > > diff --git a/arch/arm/mach-imx/imx8/Kconfig > > b/arch/arm/mach-imx/imx8/Kconfig index bbe323d5ca..cec21f8dd2 100644 > > --- a/arch/arm/mach-imx/imx8/Kconfig > > +++ b/arch/arm/mach-imx/imx8/Kconfig > > @@ -37,6 +37,11 @@ config TARGET_COLIBRI_IMX8X > > select BOARD_LATE_INIT > > select IMX8QXP > > > > +config TARGET_IMX8QXP_AI_ML > > + bool "Support i.MX8QXP AI_ML board" > > + select BOARD_LATE_INIT > > + select IMX8QXP > > + > > config TARGET_IMX8QM_MEK > > bool "Support i.MX8QM MEK board" > > select BOARD_LATE_INIT > > @@ -49,6 +54,7 @@ config TARGET_IMX8QXP_MEK > > > > endchoice > > > > +source "board/einfochips/imx8qxp_ai_ml/Kconfig" > > source "board/freescale/imx8qm_mek/Kconfig" > > source "board/freescale/imx8qxp_mek/Kconfig" > > source "board/toradex/apalis-imx8/Kconfig" > > diff --git a/board/einfochips/imx8qxp_ai_ml/Kconfig > > b/board/einfochips/imx8qxp_ai_ml/Kconfig new file mode 100644 > > index 00..697a831013 > > --- /dev/null > > +++ b/board/einfochips/imx8qxp_ai_ml/Kconfig > > @@ -0,0 +1,12 @@ > > +if TARGET_IMX8QXP_AI_ML > > + > > +config SYS_BOARD > > + default "imx8qxp_ai_ml" > > + > > +config SYS_VENDOR > > + default "einfochips" > > + > > +config SYS_CONFIG_NAME > > + default "imx8qxp_ai_ml" > > + > > +endif > > diff --git a/board/einfochips/imx8qxp_ai_ml/MAINTAINERS > > b/board/einfochips/imx8qxp_ai_ml/MAINTAINERS new file mode 100644 > > index 00..add0bd9431 > > --- /dev/null > > +++ b/board/einfochips/imx8qxp_ai_ml/MAINTAINERS > > @@ -0,0 +1,6 @@ > > +i.MX8QXP AI_ML BOARD > > +M: Manivannan Sadhasivam > > +S: Maintained > > +F: board/einfochips/imx8qxp_ai_ml/ > > +F: include/configs/imx8qxp_ai_ml.h > > +F: configs/imx8qxp_ai_ml_defconfig > > diff --git a/board/einfochips/imx8qxp_ai_ml/Makefile > > b/board/einfochips/imx8qxp_ai_ml/Makefile new file mode 100644 > > index 00..e08774dc6e > > --- /dev/null > > +++ b/board/einfochips/imx8qxp_ai_ml/Makefile > > @@ -0,0 +1,8 @@ > > +# > > +# Copyright 2019 Linaro Ltd. > > +# > > +# SPDX-License-Identifier: GPL-2.0+ > > +# > > + > > +obj-y += imx8qxp_ai_ml.o > > +obj-$(CONFIG_SPL_BUILD) += spl.o > > diff --git a/board/einfochips/imx8qxp_ai_ml/README > > b/board/einfochips/imx8qxp_ai_ml/README new file mode 100644 > > index 00..488920580f > > --- /dev/null > > +++ b/board/einfochips/imx8qxp_ai_ml/README > > Thank you for preparing the README file, appreciated :-). > > > @@ -0,0 +1,49 @@ > > +U-Boot for the Einfochips i.MX8QXP AI_ML board > > + > > +Quick Start > > +=== > > + > > +- Get and Build the ARM Trusted firmware > > +- Get scfw_tcm.bin and ahab-container.img > > +- Build U-Boot > > +- Flash the binary into the SD card > > +- Boot > > + > > +Get and Build the ARM Trusted firmware > > +== > > + > > +$ git clone https://source.codeaurora.org/external/imx/imx-atf > > +$ cd imx-atf/ > > +$ git checkout origin/imx_4.9.88_imx8qxp_beta2 -b > > imx_4.9.88_imx8qxp_beta2 +$ make
Re: [U-Boot] [PATCH v2 3/6] cbfs: Move static variables into a struct
On Thu, Aug 15, 2019 at 9:56 AM Simon Glass wrote: > > At present there are a number of static variables in BSS. This cannot work > with SPL, at least until BSS is available in board_init_r(). > > Move the variables into a struct, so it is possible to malloc() it and use > it before BSS is available. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Make cbfs_init() static > - Move whitespace changes to next patch > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] global_data: Move x86 specific GD flags into common flags
On Thu, Aug 15, 2019 at 3:05 PM Stefan Roese wrote: > > Currently the upper 16 bits of the GD flags are reserved for > architecture specific flags. But only x86 uses 2 bits of these 16 bits > and sprinkling those flags in multiple headers is confusing and does not > scale. > > This patch now moves the x86 flags into the common header and removes > the comment about the reservation of the upper 16 bits. > > Signed-off-by: Stefan Roese > Cc: Bin Meng > Cc: Simon Glass > Cc: Tom Rini > Cc: Simon Goldschmidt > --- > arch/x86/include/asm/global_data.h | 6 -- > include/asm-generic/global_data.h | 6 +- > 2 files changed, 5 insertions(+), 7 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH v4 1/5] spl: dm: disable SPI DM flash for non-DM SPL
On Thu, 15 Aug 2019 03:35:28 +
Chuanhua Han wrote:
> > -Original Message-
> > From: Lukasz Majewski
> > Sent: 2019年8月14日 19:39
> > To: Chuanhua Han
> > Cc: Jagan Teki ; Xiaowei Bao
> > ; U-Boot-Denx ; Pan
> > Jiafei ; Jagan Teki ;
> > Ruchika Gupta
> > Subject: Re: [U-Boot] [EXT] Re: [PATCH v4 1/5] spl: dm: disable SPI
> > DM flash for non-DM SPL
> >
> > On Wed, 14 Aug 2019 11:10:46 +
> > Chuanhua Han wrote:
> >
> > > > -Original Message-
> > > > From: Lukasz Majewski
> > > > Sent: 2019年8月14日 18:53
> > > > To: Chuanhua Han
> > > > Cc: Jagan Teki ; Xiaowei Bao
> > > > ; U-Boot-Denx ; Pan
> > > > Jiafei ; Jagan Teki
> > > > ; Ruchika Gupta
> > > > Subject: Re: [U-Boot] [EXT] Re: [PATCH v4 1/5] spl: dm: disable
> > > > SPI DM flash for non-DM SPL
> > > >
> > > > On Wed, 14 Aug 2019 10:41:32 +
> > > > Chuanhua Han wrote:
> > > >
> > > > > > -Original Message-
> > > > > > From: Lukasz Majewski
> > > > > > Sent: 2019年8月14日 16:57
> > > > > > To: Chuanhua Han
> > > > > > Cc: Jagan Teki ; Xiaowei Bao
> > > > > > ; U-Boot-Denx ;
> > > > > > Pan Jiafei ; Jagan Teki
> > > > > > ; Ruchika Gupta
> > > > > > Subject: Re: [U-Boot] [EXT] Re: [PATCH v4 1/5] spl: dm:
> > > > > > disable SPI DM flash for non-DM SPL
> > > > > >
> > > > > > Hi Chuanhua,
> > > > > >
> > > > > > > > -Original Message-
> > > > > > > > From: Jagan Teki
> > > > > > > > Sent: 2019年8月14日 15:45
> > > > > > > > To: Chuanhua Han
> > > > > > > > Cc: Wolfgang Denk ; Shengzhou Liu
> > > > > > > > ; Ruchika Gupta
> > > > > > > > ; Jagan Teki
> > > > > > > > ; Simon Glass ;
> > > > > > > > Prabhakar Kushwaha ;
> > > > > > > > U-Boot-Denx ; Pan Jiafei
> > > > > > > > Subject: [EXT] Re: [U-Boot]
> > > > > > > > [PATCH v4 1/5] spl: dm: disable SPI DM flash for non-DM
> > > > > > > > SPL
> > > > > > > >
> > > > > > > > Caution: EXT Email
> > > > > > > >
> > > > > > > > On Fri, Jun 21, 2019 at 7:51 AM Chuanhua Han
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > This patch solves the problem that spiboot cannot be
> > > > > > > > > performed in non-DM SPL.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Pan Jiafei
> > > > > > > > > Signed-off-by: Chuanhua Han
> > > > > > > > > ---
> > > > > > > > > Changes in v4:
> > > > > > > > > - No change.
> > > > > > > > > Changes in v3:
> > > > > > > > > - Add a cover-letter for this patch set.
> > > > > > > > > Changes in v2:
> > > > > > > > > - No change.
> > > > > > > > >
> > > > > > > > > include/config_uncmd_spl.h | 1 +
> > > > > > > > > 1 file changed, 1 insertion(+)
> > > > > > > > >
> > > > > > > > > diff --git a/include/config_uncmd_spl.h
> > > > > > > > > b/include/config_uncmd_spl.h index
> > > > > > > > > c2f9735ce7..da94b3d9df 100644 ---
> > > > > > > > > a/include/config_uncmd_spl.h +++
> > > > > > > > > b/include/config_uncmd_spl.h @@ -15,6 +15,7 @@
> > > > > > > > > #undef CONFIG_DM_GPIO
> > > > > > > > > #undef CONFIG_DM_I2C
> > > > > > > > > #undef CONFIG_DM_SPI
> > > > > > > > > +#undef CONFIG_DM_SPI_FLASH
> > > > > > > >
> > > > > > > > Have you made any Travis-CI run?
> > > > > > > I tested it with a local board
> > > > > >
> > > > > > Could you be so kind and also test following patchset (parts
> > > > > > from Layerscape also needs testing):
> > > > > > https://patchwork.ozlabs.org/cover/1146494/
> > > > > I don't quite understand this patch. How can I test it?
> > > >
> > > > You need to apply it first to -master branch.
> > > >
> > > > Then apply your board code (or if it is already in mainline just
> > > > remove the #undef(s) from include/config_uncmd_spl.h)
> > > >
> > > > As a last step - run make menuconfig and enable SPL_DM_SPI*
> > > > flags.
> > > Currently, it is in the master, and SPI* in the #undef(s) from
> > > include/ uncmd_spl.h has been deleted, but an error was reported:
> > > CC spl/lib/display_options.o drivers/spi/spi.c: In function
> > > 'spi_do_alloc_slave': drivers/spi/spi.c:34:8: error: 'struct
> > > spi_slave' has no member named 'bus' slave->bus = bus;
> > > ^~
> > > drivers/spi/spi.c:35:8: error: 'struct spi_slave' has no member
> > > named 'cs' slave->cs = cs;
> > > ^~
> > > make[3]: *** [spl/drivers/spi/spi.o] Error 1
> > > make[3]: *** Waiting for unfinished jobs
> > > make[2]: *** [spl/drivers/spi] Error 2
> > > make[1]: *** [spl/drivers] Error 2
> > > make[1]: *** Waiting for unfinished jobs
> > > LD spl/lib/built-in.o
> > > make: *** [spl/u-boot-spl] Error 2
> >
> > If your board is in mainline (master branch) it shall build without
> > issues:
> >
> > Applied on top of -master branch:
> > 'commit feb5a02f869d ("Merge branch 'master' of
> > git://git.denx.de/u-boot-sh")' Travis-CI (clean build):
> > https://travis-ci.org/lmajewski/u-boot-dfu/builds/570594278
> >
> >
> > The patch itself:
> > https://patchwork.ozlabs.org/patch/1146377/
> 1. I git reset to this commit: feb5a02f869d
> 2. Your patch has been
[U-Boot] [PATCH] global_data: Move x86 specific GD flags into common flags
Currently the upper 16 bits of the GD flags are reserved for
architecture specific flags. But only x86 uses 2 bits of these 16 bits
and sprinkling those flags in multiple headers is confusing and does not
scale.
This patch now moves the x86 flags into the common header and removes
the comment about the reservation of the upper 16 bits.
Signed-off-by: Stefan Roese
Cc: Bin Meng
Cc: Simon Glass
Cc: Tom Rini
Cc: Simon Goldschmidt
---
arch/x86/include/asm/global_data.h | 6 --
include/asm-generic/global_data.h | 6 +-
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/global_data.h
b/arch/x86/include/asm/global_data.h
index 797397e697..17a4d34491 100644
--- a/arch/x86/include/asm/global_data.h
+++ b/arch/x86/include/asm/global_data.h
@@ -137,10 +137,4 @@ static inline __attribute__((no_instrument_function)) gd_t
*get_fs_gd_ptr(void)
#endif
-/*
- * Our private Global Data Flags
- */
-#define GD_FLG_COLD_BOOT 0x1 /* Cold Boot */
-#define GD_FLG_WARM_BOOT 0x2 /* Warm Boot */
-
#endif /* __ASM_GBL_DATA_H */
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
index 5372d5d8cd..42ae61c781 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -150,7 +150,7 @@ typedef struct global_data {
#endif
/*
- * Global Data Flags - the top 16 bits are reserved for arch-specific flags
+ * Common Global Data Flags
*/
#define GD_FLG_RELOC 0x1 /* Code was relocated to RAM */
#define GD_FLG_DEVINIT 0x2 /* Devices have been initialized */
@@ -170,4 +170,8 @@ typedef struct global_data {
#define GD_FLG_LOG_READY 0x08000 /* Log system is ready for use */
#define GD_FLG_WDT_READY 0x1 /* Watchdog is ready for use */
+/* x86 specific GD flags */
+#define GD_FLG_COLD_BOOT 0x2 /* Cold Boot */
+#define GD_FLG_WARM_BOOT 0x4 /* Warm Boot */
+
#endif /* __ASM_GENERIC_GBL_DATA_H */
--
2.22.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 8/8] usb: r8a66597: Checkpatch cleanup
Fix remaining checkpatch complaints in the driver.
Signed-off-by: Marek Vasut
Cc: Chris Brandt
---
drivers/usb/host/r8a66597-hcd.c | 65 ++---
drivers/usb/host/r8a66597.h | 473
2 files changed, 269 insertions(+), 269 deletions(-)
diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c
index 78601b67fa..17ec4b4752 100644
--- a/drivers/usb/host/r8a66597-hcd.c
+++ b/drivers/usb/host/r8a66597-hcd.c
@@ -58,17 +58,17 @@ static void get_hub_data(struct usb_device *dev, u16
*hub_devnum, u16 *hubport)
/* check a device connected to root_hub */
if ((parent && parent->devnum == 1) ||
- (dev->devnum == 1))
+ dev->devnum == 1)
return;
*hub_devnum = (u8)parent->devnum;
*hubport = parent->portnr - 1;
- printf("get_hub_data error.\n");
+ printf("%s error.\n", __func__);
}
static void set_devadd(struct r8a66597 *r8a66597, u8 r8a66597_address,
- struct usb_device *dev, int port)
+ struct usb_device *dev, int port)
{
u16 val, usbspd, upphub, hubport;
unsigned long devadd_reg = get_devadd_addr(r8a66597_address);
@@ -323,7 +323,7 @@ static int send_bulk_packet(struct r8a66597 *r8a66597,
struct usb_device *dev,
R8A66597_DPRINT("%s\n", __func__);
r8a66597_mdfy(r8a66597, MBW | BULK_OUT_PIPENUM,
- MBW | CURPIPE, CFIFOSEL);
+ MBW | CURPIPE, CFIFOSEL);
r8a66597_reg_wait(r8a66597, CFIFOSEL, CURPIPE, BULK_OUT_PIPENUM);
tmp = r8a66597_read(r8a66597, CFIFOCTR);
if ((tmp & FRDY) == 0) {
@@ -347,7 +347,7 @@ static int send_bulk_packet(struct r8a66597 *r8a66597,
struct usb_device *dev,
dev->act_len += size;
r8a66597_mdfy(r8a66597, PID_BUF, PID,
- get_pipectr_addr(BULK_OUT_PIPENUM));
+ get_pipectr_addr(BULK_OUT_PIPENUM));
while (!(r8a66597_read(r8a66597, BEMPSTS) & (1 << BULK_OUT_PIPENUM)))
if (ctrlc())
@@ -356,7 +356,7 @@ static int send_bulk_packet(struct r8a66597 *r8a66597,
struct usb_device *dev,
if (dev->act_len >= transfer_len)
r8a66597_mdfy(r8a66597, PID_NAK, PID,
- get_pipectr_addr(BULK_OUT_PIPENUM));
+ get_pipectr_addr(BULK_OUT_PIPENUM));
return 0;
}
@@ -377,17 +377,17 @@ static int receive_bulk_packet(struct r8a66597 *r8a66597,
/* prepare */
if (dev->act_len == 0) {
r8a66597_mdfy(r8a66597, PID_NAK, PID,
- get_pipectr_addr(pipenum));
+ get_pipectr_addr(pipenum));
r8a66597_write(r8a66597, ~(1 << pipenum), BRDYSTS);
r8a66597_write(r8a66597, TRCLR, get_pipetre_addr(pipenum));
r8a66597_write(r8a66597,
- (transfer_len + maxpacket - 1) / maxpacket,
+ (transfer_len + maxpacket - 1) / maxpacket,
get_pipetrn_addr(pipenum));
r8a66597_bset(r8a66597, TRENB, get_pipetre_addr(pipenum));
r8a66597_mdfy(r8a66597, PID_BUF, PID,
- get_pipectr_addr(pipenum));
+ get_pipectr_addr(pipenum));
}
r8a66597_mdfy(r8a66597, MBW | pipenum, MBW | CURPIPE, CFIFOSEL);
@@ -464,7 +464,7 @@ static int receive_control_packet(struct r8a66597 *r8a66597,
}
static int send_status_packet(struct r8a66597 *r8a66597,
- unsigned long pipe)
+ unsigned long pipe)
{
r8a66597_bset(r8a66597, SQSET, DCPCTR);
r8a66597_mdfy(r8a66597, PID_NAK, PID, DCPCTR);
@@ -555,9 +555,7 @@ static int check_usb_device_connecting(struct r8a66597
*r8a66597)
return -1; /* fail */
}
-/*-*
- * Virtual Root Hub
- *-*/
+/* Virtual Root Hub */
#include
@@ -639,34 +637,34 @@ static int r8a66597_submit_rh_msg(struct udevice *udev,
struct usb_device *dev,
switch ((wValue & 0xff00) >> 8) {
case (0x01): /* device descriptor */
len = min_t(unsigned int,
- leni,
+ leni,
min_t(unsigned int,
- sizeof(root_hub_dev_des),
+ sizeof(root_hub_dev_des),
wLength));
memcpy(buffer, root_hub_dev_des, len);
break;
case (0x02): /* configuration descriptor */
len = min_t(unsigned int,
- leni,
+
[U-Boot] [PATCH 4/8] usb: r8a66597: Remove BE support
While the USB controller can work both in LE and BE modes, there is no user for the BE mode, so drop it. If there ever is a user for it, it can be easily re-added back. Signed-off-by: Marek Vasut Cc: Chris Brandt --- drivers/usb/host/r8a66597-hcd.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c index d144b57a61..2b9f8a150a 100644 --- a/drivers/usb/host/r8a66597-hcd.c +++ b/drivers/usb/host/r8a66597-hcd.c @@ -139,9 +139,9 @@ static int enable_controller(struct r8a66597 *r8a66597) for (port = 0; port < R8A66597_MAX_ROOT_HUB; port++) r8a66597_write(r8a66597, 0, get_intenb_reg(port)); - r8a66597_bset(r8a66597, CONFIG_R8A66597_ENDIAN & BIGEND, CFIFOSEL); - r8a66597_bset(r8a66597, CONFIG_R8A66597_ENDIAN & BIGEND, D0FIFOSEL); - r8a66597_bset(r8a66597, CONFIG_R8A66597_ENDIAN & BIGEND, D1FIFOSEL); + r8a66597_bclr(r8a66597, BIGEND, CFIFOSEL); + r8a66597_bclr(r8a66597, BIGEND, D0FIFOSEL); + r8a66597_bclr(r8a66597, BIGEND, D1FIFOSEL); r8a66597_bset(r8a66597, TRNENSEL, SOFCFG); for (port = 0; port < R8A66597_MAX_ROOT_HUB; port++) -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 7/8] usb: r8a66597: Add Kconfig entry
Add missing Kconfig entry for the R8A66597 driver. Signed-off-by: Marek Vasut Cc: Chris Brandt --- drivers/usb/host/Kconfig | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 42046c8062..30c6b69be8 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -300,3 +300,12 @@ config USB_DWC2_BUFFER_SIZE because larger transactions could be split in smaller ones. endif # USB_DWC2 + +config USB_R8A66597_HCD + bool "Renesas R8A66597 USB Core support" + depends on OF_CONTROL + depends on DM_USB + select USB_HOST + ---help--- + This enables support for the on-chip Renesas R8A66597 USB 2.0 + controller, present in various RZ and SH SoCs. -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 6/8] usb: r8a66597: Convert to USB DM
Convert the R8A66597 USB driver to DM and add support for DT probing.
Drop support for legacy non-DM and non-DT probing, since there are no
platform using that.
Signed-off-by: Marek Vasut
Cc: Chris Brandt
---
drivers/usb/host/r8a66597-hcd.c | 193 +---
1 file changed, 125 insertions(+), 68 deletions(-)
diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c
index 28d0c0fcde..78601b67fa 100644
--- a/drivers/usb/host/r8a66597-hcd.c
+++ b/drivers/usb/host/r8a66597-hcd.c
@@ -7,6 +7,7 @@
#include
#include
+#include
#include
#include
#include
@@ -19,27 +20,49 @@
#define R8A66597_DPRINT(...)
#endif
-static struct r8a66597 gr8a66597;
+static inline struct usb_device *usb_dev_get_parent(struct usb_device *udev)
+{
+ struct udevice *parent = udev->dev->parent;
+
+ /*
+* When called from usb-uclass.c: usb_scan_device() udev->dev points
+* to the parent udevice, not the actual udevice belonging to the
+* udev as the device is not instantiated yet.
+*
+* If dev is an usb-bus, then we are called from usb_scan_device() for
+* an usb-device plugged directly into the root port, return NULL.
+*/
+ if (device_get_uclass_id(udev->dev) == UCLASS_USB)
+ return NULL;
+
+ /*
+* If these 2 are not the same we are being called from
+* usb_scan_device() and udev itself is the parent.
+*/
+ if (dev_get_parent_priv(udev->dev) != udev)
+ return udev;
+
+ /* We are being called normally, use the parent pointer */
+ if (device_get_uclass_id(parent) == UCLASS_USB_HUB)
+ return dev_get_parent_priv(parent);
+
+ return NULL;
+}
static void get_hub_data(struct usb_device *dev, u16 *hub_devnum, u16 *hubport)
{
- int i;
+ struct usb_device *parent = usb_dev_get_parent(dev);
*hub_devnum = 0;
*hubport = 0;
/* check a device connected to root_hub */
- if ((dev->parent && dev->parent->devnum == 1) ||
+ if ((parent && parent->devnum == 1) ||
(dev->devnum == 1))
return;
- for (i = 0; i < USB_MAXCHILDREN; i++) {
- if (dev->parent->children[i] == dev) {
- *hub_devnum = (u8)dev->parent->devnum;
- *hubport = i;
- return;
- }
- }
+ *hub_devnum = (u8)parent->devnum;
+ *hubport = parent->portnr - 1;
printf("get_hub_data error.\n");
}
@@ -538,10 +561,11 @@ static int check_usb_device_connecting(struct r8a66597
*r8a66597)
#include
-static int r8a66597_submit_rh_msg(struct usb_device *dev, unsigned long pipe,
- void *buffer, int transfer_len, struct devrequest *cmd)
+static int r8a66597_submit_rh_msg(struct udevice *udev, struct usb_device *dev,
+ unsigned long pipe, void *buffer,
+ int transfer_len, struct devrequest *cmd)
{
- struct r8a66597 *r8a66597 =
+ struct r8a66597 *r8a66597 = dev_get_priv(udev);
int leni = transfer_len;
int len = 0;
int stat = 0;
@@ -609,7 +633,7 @@ static int r8a66597_submit_rh_msg(struct usb_device *dev,
unsigned long pipe,
}
break;
case RH_SET_ADDRESS:
- gr8a66597.rh_devnum = wValue;
+ r8a66597->rh_devnum = wValue;
break;
case RH_GET_DESCRIPTOR:
switch ((wValue & 0xff00) >> 8) {
@@ -705,50 +729,21 @@ static int r8a66597_submit_rh_msg(struct usb_device *dev,
unsigned long pipe,
return stat;
}
-int submit_bulk_msg(struct usb_device *dev, unsigned long pipe, void *buffer,
- int transfer_len)
-{
- struct r8a66597 *r8a66597 =
- int ret = 0;
-
- R8A66597_DPRINT("%s\n", __func__);
- R8A66597_DPRINT("pipe = %08x, buffer = %p, len = %d, devnum = %d\n",
- pipe, buffer, transfer_len, dev->devnum);
-
- set_devadd(r8a66597, dev->devnum, dev, 0);
-
- pipe_buffer_setting(r8a66597, dev, pipe);
-
- dev->act_len = 0;
- while (dev->act_len < transfer_len && ret == 0) {
- if (ctrlc())
- return -1;
-
- if (usb_pipein(pipe))
- ret = receive_bulk_packet(r8a66597, dev, pipe, buffer,
- transfer_len);
- else
- ret = send_bulk_packet(r8a66597, dev, pipe, buffer,
- transfer_len);
- }
-
- if (ret == 0)
- dev->status = 0;
-
- return ret;
-}
-
-int submit_control_msg(struct usb_device *dev, unsigned long pipe,
- void *buffer, int transfer_len, struct devrequest *setup)
+static int
[U-Boot] [PATCH 5/8] usb: r8a66597: Replace R8A66597_BASE0
Replace R8A66597_BASE0 with proper SYSCFG0 accesses, no functional
change.
Signed-off-by: Marek Vasut
Cc: Chris Brandt
---
drivers/usb/host/r8a66597-hcd.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c
index 2b9f8a150a..28d0c0fcde 100644
--- a/drivers/usb/host/r8a66597-hcd.c
+++ b/drivers/usb/host/r8a66597-hcd.c
@@ -76,10 +76,10 @@ static int r8a66597_clock_enable(struct r8a66597 *r8a66597)
* and USB1, so we must always set the USB0 register
*/
#if (CONFIG_R8A66597_XTAL == 1)
- setbits(le16, R8A66597_BASE0, XTAL);
+ r8a66597_bset(r8a66597, XTAL, SYSCFG0);
#endif
mdelay(1);
- setbits(le16, R8A66597_BASE0, UPLLE);
+ r8a66597_bset(r8a66597, UPLLE, SYSCFG0);
mdelay(1);
r8a66597_bset(r8a66597, SUSPM, SUSPMODE0);
@@ -90,7 +90,7 @@ static void r8a66597_clock_disable(struct r8a66597 *r8a66597)
{
r8a66597_bclr(r8a66597, SUSPM, SUSPMODE0);
- clrbits(le16, R8A66597_BASE0, UPLLE);
+ r8a66597_bclr(r8a66597, UPLLE, SYSCFG0);
mdelay(1);
r8a66597_bclr(r8a66597, USBE, SYSCFG0);
mdelay(1);
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/8] usb: r8a66597: Replace IO accessors
Replace in{bwl}()/out{bwl}() IO accessors with read{bwl}()/write{bwl}(),
to make the driver compile both on SH and ARM.
Signed-off-by: Marek Vasut
Cc: Chris Brandt
---
drivers/usb/host/r8a66597.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/host/r8a66597.h b/drivers/usb/host/r8a66597.h
index 1e370cdd6c..7ad14ddfd2 100644
--- a/drivers/usb/host/r8a66597.h
+++ b/drivers/usb/host/r8a66597.h
@@ -402,7 +402,7 @@ struct r8a66597 {
static inline u16 r8a66597_read(struct r8a66597 *r8a66597, unsigned long
offset)
{
- return inw(r8a66597->reg + offset);
+ return readw(r8a66597->reg + offset);
}
static inline void r8a66597_read_fifo(struct r8a66597 *r8a66597,
@@ -416,10 +416,10 @@ static inline void r8a66597_read_fifo(struct r8a66597
*r8a66597,
count = len / 4;
for (i = 0; i < count; i++)
- p[i] = inl(r8a66597->reg + offset);
+ p[i] = readl(r8a66597->reg + offset);
if (len & 0x0003) {
- unsigned long tmp = inl(fifoaddr);
+ unsigned long tmp = readl(fifoaddr);
memcpy((unsigned char *)buf + count * 4, , len & 0x03);
}
}
@@ -427,7 +427,7 @@ static inline void r8a66597_read_fifo(struct r8a66597
*r8a66597,
static inline void r8a66597_write(struct r8a66597 *r8a66597, u16 val,
unsigned long offset)
{
- outw(val, r8a66597->reg + offset);
+ writew(val, r8a66597->reg + offset);
}
static inline void r8a66597_write_fifo(struct r8a66597 *r8a66597,
@@ -442,15 +442,15 @@ static inline void r8a66597_write_fifo(struct r8a66597
*r8a66597,
count = len / 4;
for (i = 0; i < count; i++)
- outl(p[i], fifoaddr);
+ writel(p[i], fifoaddr);
if (len & 0x0003) {
pb = (unsigned char *)buf + count * 4;
for (i = 0; i < (len & 0x0003); i++) {
if (r8a66597_read(r8a66597, CFIFOSEL) & BIGEND)
- outb(pb[i], fifoaddr + i);
+ writeb(pb[i], fifoaddr + i);
else
- outb(pb[i], fifoaddr + 3 - i);
+ writeb(pb[i], fifoaddr + 3 - i);
}
}
}
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/8] usb: r8a66597: Make CONFIG_RZA_USB default
No other platforms use this r8a66597 controller but RZ/A1,
make RZ/A1 support the default and drop all the other SoC
support to remove ifdeffery.
Signed-off-by: Marek Vasut
Cc: Chris Brandt
---
drivers/usb/host/r8a66597-hcd.c | 35 -
drivers/usb/host/r8a66597.h | 39 -
2 files changed, 74 deletions(-)
diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c
index 8cca09f6d8..d144b57a61 100644
--- a/drivers/usb/host/r8a66597-hcd.c
+++ b/drivers/usb/host/r8a66597-hcd.c
@@ -70,20 +70,6 @@ static int r8a66597_clock_enable(struct r8a66597 *r8a66597)
}
} while ((tmp & USBE) != USBE);
r8a66597_bclr(r8a66597, USBE, SYSCFG0);
-#if !defined(CONFIG_RZA_USB)
- r8a66597_mdfy(r8a66597, CONFIG_R8A66597_XTAL, XTAL, SYSCFG0);
-
- i = 0;
- r8a66597_bset(r8a66597, XCKE, SYSCFG0);
- do {
- udelay(1000);
- tmp = r8a66597_read(r8a66597, SYSCFG0);
- if (i++ > 500) {
- printf("register access fail.\n");
- return -1;
- }
- } while ((tmp & SCKE) != SCKE);
-#else
/*
* RZ/A Only:
* Bits XTAL(UCKSEL) and UPLLE in SYSCFG0 for USB0 controls both USB0
@@ -96,28 +82,18 @@ static int r8a66597_clock_enable(struct r8a66597 *r8a66597)
setbits(le16, R8A66597_BASE0, UPLLE);
mdelay(1);
r8a66597_bset(r8a66597, SUSPM, SUSPMODE0);
-#endif /* CONFIG_RZA_USB */
return 0;
}
static void r8a66597_clock_disable(struct r8a66597 *r8a66597)
{
-#if !defined(CONFIG_RZA_USB)
- r8a66597_bclr(r8a66597, SCKE, SYSCFG0);
- udelay(1);
- r8a66597_bclr(r8a66597, PLLC, SYSCFG0);
- r8a66597_bclr(r8a66597, XCKE, SYSCFG0);
- r8a66597_bclr(r8a66597, USBE, SYSCFG0);
-#else
r8a66597_bclr(r8a66597, SUSPM, SUSPMODE0);
clrbits(le16, R8A66597_BASE0, UPLLE);
mdelay(1);
r8a66597_bclr(r8a66597, USBE, SYSCFG0);
mdelay(1);
-
-#endif
}
static void r8a66597_enable_port(struct r8a66597 *r8a66597, int port)
@@ -127,10 +103,6 @@ static void r8a66597_enable_port(struct r8a66597
*r8a66597, int port)
val = port ? DRPD : DCFM | DRPD;
r8a66597_bset(r8a66597, val, get_syscfg_reg(port));
r8a66597_bset(r8a66597, HSE, get_syscfg_reg(port));
-
-#if !defined(CONFIG_RZA_USB)
- r8a66597_write(r8a66597, BURST | CPU_ADR_RD_WR, get_dmacfg_reg(port));
-#endif
}
static void r8a66597_disable_port(struct r8a66597 *r8a66597, int port)
@@ -160,9 +132,6 @@ static int enable_controller(struct r8a66597 *r8a66597)
if (ret < 0)
return ret;
-#if !defined(CONFIG_RZA_USB)
- r8a66597_bset(r8a66597, CONFIG_R8A66597_LDRV & LDRV, PINCFG);
-#endif
r8a66597_bset(r8a66597, USBE, SYSCFG0);
r8a66597_bset(r8a66597, INTL, SOFCFG);
@@ -280,16 +249,13 @@ static int send_setup_packet(struct r8a66597 *r8a66597,
struct usb_device *dev,
unsigned long setup_addr = USBREQ;
u16 intsts1;
int timeout = 3000;
-#if defined(CONFIG_RZA_USB)
u16 dcpctr;
-#endif
u16 devsel = setup->request == USB_REQ_SET_ADDRESS ? 0 : dev->devnum;
r8a66597_write(r8a66597, make_devsel(devsel) |
(8 << dev->maxpacketsize), DCPMAXP);
r8a66597_write(r8a66597, ~(SIGN | SACK), INTSTS1);
-#if defined(CONFIG_RZA_USB)
dcpctr = r8a66597_read(r8a66597, DCPCTR);
if ((dcpctr & PID) == PID_BUF) {
if (readw_poll_timeout(r8a66597->reg + DCPCTR, dcpctr,
@@ -298,7 +264,6 @@ static int send_setup_packet(struct r8a66597 *r8a66597,
struct usb_device *dev,
return -ETIMEDOUT;
}
}
-#endif
for (i = 0; i < 4; i++) {
r8a66597_write(r8a66597, le16_to_cpu(p[i]), setup_addr);
diff --git a/drivers/usb/host/r8a66597.h b/drivers/usb/host/r8a66597.h
index 4859e26355..1e370cdd6c 100644
--- a/drivers/usb/host/r8a66597.h
+++ b/drivers/usb/host/r8a66597.h
@@ -89,27 +89,14 @@
#define SUSPMODE0 0x102 /* RZ/A only */
/* System Configuration Control Register */
-#if !defined(CONFIG_RZA_USB)
-#defineXTAL0xC000 /* b15-14: Crystal selection */
-#define XTAL48 0x8000 /* 48MHz */
-#define XTAL24 0x4000 /* 24MHz */
-#define XTAL12 0x /* 12MHz */
-#defineXCKE0x2000 /* b13: External clock enable */
-#definePLLC0x0800 /* b11: PLL control */
-#defineSCKE0x0400 /* b10: USB clock enable */
-#definePCSDIS 0x0200 /* b9: not CS wakeup */
-#defineLPSME 0x0100 /* b8: Low power sleep mode */
-#endif
#defineHSE 0x0080 /* b7: Hi-speed enable */
#defineDCFM0x0040 /* b6: Controller function select */
#defineDRPD
[U-Boot] [PATCH 1/8] usb: r8a66597: Remove CONFIG_SUPERH_ON_CHIP_R8A66597
Remove CONFIG_SUPERH_ON_CHIP_R8A66597 macro, which is unused.
Signed-off-by: Marek Vasut
Cc: Chris Brandt
---
drivers/usb/host/r8a66597-hcd.c | 14 --
drivers/usb/host/r8a66597.h | 12 ++--
2 files changed, 2 insertions(+), 24 deletions(-)
diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c
index 3c263e51c1..8cca09f6d8 100644
--- a/drivers/usb/host/r8a66597-hcd.c
+++ b/drivers/usb/host/r8a66597-hcd.c
@@ -61,17 +61,6 @@ static int r8a66597_clock_enable(struct r8a66597 *r8a66597)
u16 tmp;
int i = 0;
-#if defined(CONFIG_SUPERH_ON_CHIP_R8A66597)
- do {
- r8a66597_write(r8a66597, SCKE, SYSCFG0);
- tmp = r8a66597_read(r8a66597, SYSCFG0);
- if (i++ > 1000) {
- printf("register access fail.\n");
- return -1;
- }
- } while ((tmp & SCKE) != SCKE);
- r8a66597_write(r8a66597, 0x04, 0x02);
-#else
do {
r8a66597_write(r8a66597, USBE, SYSCFG0);
tmp = r8a66597_read(r8a66597, SYSCFG0);
@@ -108,7 +97,6 @@ static int r8a66597_clock_enable(struct r8a66597 *r8a66597)
mdelay(1);
r8a66597_bset(r8a66597, SUSPM, SUSPMODE0);
#endif /* CONFIG_RZA_USB */
-#endif /* #if defined(CONFIG_SUPERH_ON_CHIP_R8A66597) */
return 0;
}
@@ -118,11 +106,9 @@ static void r8a66597_clock_disable(struct r8a66597
*r8a66597)
#if !defined(CONFIG_RZA_USB)
r8a66597_bclr(r8a66597, SCKE, SYSCFG0);
udelay(1);
-#if !defined(CONFIG_SUPERH_ON_CHIP_R8A66597)
r8a66597_bclr(r8a66597, PLLC, SYSCFG0);
r8a66597_bclr(r8a66597, XCKE, SYSCFG0);
r8a66597_bclr(r8a66597, USBE, SYSCFG0);
-#endif
#else
r8a66597_bclr(r8a66597, SUSPM, SUSPMODE0);
diff --git a/drivers/usb/host/r8a66597.h b/drivers/usb/host/r8a66597.h
index ffdb39e8bb..4859e26355 100644
--- a/drivers/usb/host/r8a66597.h
+++ b/drivers/usb/host/r8a66597.h
@@ -178,15 +178,11 @@
#defineREW 0x4000 /* b14: Buffer rewind */
#defineDCLRM 0x2000 /* b13: DMA buffer clear mode */
#defineDREQE 0x1000 /* b12: DREQ output enable */
-#if defined(CONFIG_SUPERH_ON_CHIP_R8A66597)
-#defineMBW 0x0800
-#else
#if !defined(CONFIG_RZA_USB)
#defineMBW 0x0400 /* b10: Maximum bit width for FIFO
access */
#else
#defineMBW 0x0800 /* b10: Maximum bit width for FIFO
access */
#endif
-#endif
#define MBW_8 0x /* 8bit */
#define MBW_16 0x0400 /* 16bit */
#define MBW_32 0x0800 /* 32bit */
@@ -398,11 +394,7 @@
#define R8A66597_MAX_NUM_PIPE 10
#define R8A66597_BUF_BSIZE 8
#define R8A66597_MAX_DEVICE10
-#if defined(CONFIG_SUPERH_ON_CHIP_R8A66597)
-#define R8A66597_MAX_ROOT_HUB 1
-#else
#define R8A66597_MAX_ROOT_HUB 2
-#endif
#define R8A66597_MAX_SAMPLING 5
#define R8A66597_RH_POLL_TIME 10
@@ -435,7 +427,7 @@ static inline void r8a66597_read_fifo(struct r8a66597
*r8a66597,
int len)
{
int i;
-#if defined(CONFIG_SUPERH_ON_CHIP_R8A66597) || defined(CONFIG_RZA_USB)
+#if defined(CONFIG_RZA_USB)
unsigned long fifoaddr = r8a66597->reg + offset;
unsigned long count;
unsigned long *p = buf;
@@ -469,7 +461,7 @@ static inline void r8a66597_write_fifo(struct r8a66597
*r8a66597,
{
int i;
unsigned long fifoaddr = r8a66597->reg + offset;
-#if defined(CONFIG_SUPERH_ON_CHIP_R8A66597) || defined(CONFIG_RZA_USB)
+#if defined(CONFIG_RZA_USB)
unsigned long count;
unsigned char *pb;
unsigned long *p = buf;
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: socfpga: gen5: don't zero bss in board_init_f()
On 8/14/19 8:56 PM, Simon Goldschmidt wrote: > Marek, > > Am 12.07.2019 um 20:03 schrieb Simon Goldschmidt: >> The socfpga gen5 SPL manually zeroed bss in board_init_f(). Now that the >> DDR driver does not use bss any more, bss is not used before >> board_init_r() >> and we can remove this hack. >> >> bss is normally zeroed by crt0.S, but after board_init_f(), before >> board_init_r(). socfpga just had this double-zeroing because it invalidly >> used bss in board_init_f() already (during DDR initialization). >> >> Signed-off-by: Simon Goldschmidt > > I just notice this seemed to have slipped through, could you please > apply this one? Without it, the BSS cleanup in the gen5 DDR driver was > quite useless... Applied, thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] 答复: [PATCH v2 2/4] USB: host: Add the USB3 host driver
On 8/15/19 3:38 AM, Sherry Sun wrote: > Hi Marek, > >> >> On 8/14/19 2:16 PM, sherry sun wrote: >>> From: Sherry Sun >>> >>> Add the USB3 host driver for NXP imx8 platform, and the cadence IP is >>> in it. The USB3 host driver support DM mode, it will probe USB3 host >>> node in dts. >> >> We already have a generic xhci driver, so why do we need that massive custom >> cadence driver ? > > Sorry, may I ask which generic xhci driver do you mean? See drivers/usb/host/xhci* ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] test/py: Fix MMC/SD block write test dependency
On 14. 08. 19 17:51, Stephen Warren wrote: > On 8/14/19 12:12 AM, Michal Simek wrote: >> On 13. 08. 19 23:21, Stephen Warren wrote: >>> On 8/1/19 10:48 PM, Michal Simek wrote: Test is using random command which has own Kconfig symbol CMD_RANDOM which already depends on CMD_MEMORY. That's why replace cmd_memory by cmd_random. >>> >>> This might not always be true; I think it'd be better to keep the >>> existing dependency list entries and just add CMD_RANDOM: >> >> Can you please tell me when exactly? I didn't see that. > > If in the future somebody changes the Kconfig file so that CMD_RANDOM > doesn't depend on or select CMD_MEMORY. It may well not be possible > right now; I just want to make sure the test doesn't rely on > implementation details of CMD_RANDOM/CMD_MEMORY; if it explicitly needs > both, it should simply depend on both. Do you think that we have used this rule in past? Anyway I understand what you mean but it is questionable if make sense to predict all changes which can happen. I would consider if anybody remove this dependency without fixing test suite as bug which should be fixed. Also tests should detect this and report issues to stop this before patch like this is applied. Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4 v5] watchdog: Implement generic watchdog_reset() version
Hi Simon,
On 14.08.19 21:35, Simon Glass wrote:
Hi,
On Wed, 14 Aug 2019 at 00:22, Stefan Roese wrote:
Hi Simon,
(added Simon Glass and Bin to Cc)
On 13.08.19 22:16, Simon Goldschmidt wrote:
Am 25.04.2019 um 09:17 schrieb Stefan Roese:
This patch tries to implement a generic watchdog_reset() function that
can be used by all boards that want to service the watchdog device in
U-Boot. This watchdog servicing is enabled via CONFIG_WATCHDOG.
Without this approach, new boards or platforms needed to implement a
board specific version of this functionality, mostly copy'ing the same
code over and over again into their board or platforms code base.
With this new generic function, the scattered other functions are now
removed to be replaced by the generic one. The new version also enables
the configuration of the watchdog timeout via the DT "timeout-sec"
property (if enabled via CONFIG_OF_CONTROL).
This patch also adds a new flag to the GD flags, to flag that the
watchdog is ready to use and adds the pointer to the watchdog device
to the GD. This enables us to remove the global "watchdog_dev"
variable, which was prone to cause problems because of its potentially
very early use in watchdog_reset(), even before the BSS is cleared.
Signed-off-by: Stefan Roese
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -133,6 +133,9 @@ typedef struct global_data {
struct spl_handoff *spl_handoff;
# endif
#endif
+#if defined(CONFIG_WDT)
+struct udevice *watchdog_dev;
+#endif
} gd_t;
#endif
@@ -161,5 +164,6 @@ typedef struct global_data {
#define GD_FLG_ENV_DEFAULT0x02000 /* Default variable flag
*/
#define GD_FLG_SPL_EARLY_INIT 0x04000 /* Early SPL init is done
*/
#define GD_FLG_LOG_READY 0x08000 /* Log system is ready for use */
+#define GD_FLG_WDT_READY0x1 /* Watchdog is ready for use */
Sorry to warm up a thread that is more than 4 months old, but I just
stumbled accross this line when searching for space in 'gd':
The comment some lines above in global_data.h clearly states that the
top 16 bits of flags are reserved for arch-specific flags, and your
patch here uses the lowest of these 16 arch-specific flags for generic code.
I totally missed this comment.
Is this a problem? Does any arch code use the upper 16 bits? I would
have thought you'd at least need to adjust the comment to reflect your
new usage...
As stated above, I did not check about any other (arch-specific)
GD_FLG_ definitions outside of this file.
The reason I ask is that I'd need a place to put some (~5?)
'is_initialized' bits for some code running in SPL in the 'board_init_f'
code where BSS shouldn't be used. gd->flags would be ideal for that, but
I'm hesistant to dive in further into the 'arch-specific' upper 16 bits...
And you should be. A quick grep shows that we already have a problem with
my patch touching the upper bits:
$ git grep "define GD_FLG_"
arch/x86/include/asm/global_data.h:#define GD_FLG_COLD_BOOT 0x1 /* Cold
Boot */
arch/x86/include/asm/global_data.h:#define GD_FLG_WARM_BOOT 0x2 /* Warm
Boot */
This should definitely be fixed. I see 3 options right now:
a) Reserve only the upper 8 bits for arch-specific stuff
b) Use a new variable (gd->flags_arch ?) for this arch
c) Remove the arch-specific GD_FLG's completely
I can't tell if c) is doable - Bin and / or Simon Glass might know,
if the x86 GD_FLG_foo_BOOT are really needed in gd->flags. I see that
both are assigned in the .S files, but only GD_FLG_COLD_BOOT is
referenced later on:
Probably we can drop warm boot.
Bin, do you think so as well?
arch/x86/cpu/coreboot/coreboot.c: if (gd->flags & GD_FLG_COLD_BOOT)
If c) is not an option, then I would prefer to implement b). Here
we could also only add this new "flags_arch" variable for arch's
that implement such flags (e.g. x86 right now). I could work on such
a patch, if we agree on this solution.
Any comments / suggestions?
I'm not keen on arch-specific flags here. They should be in
gd->arch... if needed. global_data is current used by generic code.
So maybe move the x86 flag to the generic header?
Yes, I also think that those flags should not be sprinkled in different
headers but collected in the generic header. I'll prepare a patch to
move the x86 flags and remove the comment about the upper 16 bits
usage. We can remove the x86 warm boot flag later, if this isn't
used at all.
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
