[U-Boot] [PATCH 4/4] net: NC-SI setup and handling
Add the handling of NC-SI ethernet frames, and add a check at the start
of net_loop() to configure NC-SI before starting other network commands.
This also adds an "ncsi" command to manually start NC-SI configuration.
Signed-off-by: Samuel Mendoza-Jonas
---
cmd/Kconfig | 6 ++
cmd/net.c | 18 ++
include/net.h | 2 +-
net/net.c | 27 ++-
4 files changed, 51 insertions(+), 2 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index ea1a325eb3..0b5df0db90 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1296,6 +1296,12 @@ config CMD_LINK_LOCAL
help
Acquire a network IP address using the link-local protocol
+config CMD_NCSI
+ bool "ncsi"
+ depends on PHY_NCSI
+ help
+ Configure the attached NIC via NC-SI
+
endif
config CMD_ETHSW
diff --git a/cmd/net.c b/cmd/net.c
index 89721b8f8b..7d2c21ba4d 100644
--- a/cmd/net.c
+++ b/cmd/net.c
@@ -457,3 +457,21 @@ U_BOOT_CMD(
);
#endif /* CONFIG_CMD_LINK_LOCAL */
+
+#if defined(CONFIG_CMD_NCSI)
+static int do_ncsi(cmd_tbl_t *cmdtp, int flag, int argc,
+ char * const argv[])
+{
+ if (net_loop(NCSI) < 0)
+ return CMD_RET_FAILURE;
+
+ return CMD_RET_SUCCESS;
+}
+
+U_BOOT_CMD(
+ ncsi, 1, 1, do_ncsi,
+ "Configure attached NIC via NC-SI",
+ ""
+);
+
+#endif /* CONFIG_CMD_NCSI */
diff --git a/include/net.h b/include/net.h
index 4f7ba211b6..82a71c5219 100644
--- a/include/net.h
+++ b/include/net.h
@@ -538,7 +538,7 @@ extern int net_restart_wrap; /* Tried all
network devices */
enum proto_t {
BOOTP, RARP, ARP, TFTPGET, DHCP, PING, DNS, NFS, CDP, NETCONS, SNTP,
- TFTPSRV, TFTPPUT, LINKLOCAL, FASTBOOT, WOL
+ TFTPSRV, TFTPPUT, LINKLOCAL, FASTBOOT, WOL, NCSI
};
extern charnet_boot_file_name[1024];/* Boot File name */
diff --git a/net/net.c b/net/net.c
index a5a216c3ee..16ca2b0e18 100644
--- a/net/net.c
+++ b/net/net.c
@@ -95,6 +95,7 @@
#include
#include
#include
+#include
#if defined(CONFIG_LED_STATUS)
#include
#include
@@ -411,6 +412,16 @@ int net_loop(enum proto_t protocol)
net_try_count = 1;
debug_cond(DEBUG_INT_STATE, "--- net_loop Entry\n");
+#ifdef CONFIG_PHY_NCSI
+ if (protocol != NCSI && !ncsi_active()) {
+ printf("%s: configuring NCSI first\n", __func__);
+ if (net_loop(NCSI) < 0)
+ return ret;
+ eth_init_state_only();
+ goto restart;
+ }
+#endif
+
bootstage_mark_name(BOOTSTAGE_ID_ETH_START, "eth_start");
net_init();
if (eth_is_on_demand_init() || protocol != NETCONS) {
@@ -424,6 +435,7 @@ int net_loop(enum proto_t protocol)
} else {
eth_init_state_only();
}
+
restart:
#ifdef CONFIG_USB_KEYBOARD
net_busy_flag = 0;
@@ -530,6 +542,11 @@ restart:
case WOL:
wol_start();
break;
+#endif
+#if defined(CONFIG_CMD_NCSI)
+ case NCSI:
+ ncsi_probe_packages();
+ break;
#endif
default:
break;
@@ -641,7 +658,7 @@ restart:
env_set_hex("filesize", net_boot_file_size);
env_set_hex("fileaddr", load_addr);
}
- if (protocol != NETCONS)
+ if (protocol != NETCONS && protocol != NCSI)
eth_halt();
else
eth_halt_state_only();
@@ -1324,6 +1341,11 @@ void net_process_received_packet(uchar *in_packet, int
len)
case PROT_WOL:
wol_receive(ip, len);
break;
+#endif
+#ifdef CONFIG_PHY_NCSI
+ case PROT_NCSI:
+ ncsi_receive(et, ip, len);
+ break;
#endif
}
}
@@ -1385,6 +1407,9 @@ common:
#ifdef CONFIG_CMD_RARP
case RARP:
+#endif
+#ifdef CONFIG_CMD_NCSI
+ case NCSI:
#endif
case BOOTP:
case CDP:
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/4] net/ftgmac100: Add NC-SI mode support
Update the ftgmac100 driver to support NC-SI instead of an mdio phy
where available. This is a common setup for Aspeed AST2x00 platforms.
NC-SI mode is determined from the device-tree if either phy-mode sets it
or the use-ncsi property exists. If set then normal mdio setup is
skipped in favour of the NC-SI phy.
Signed-off-by: Samuel Mendoza-Jonas
---
drivers/net/ftgmac100.c | 39 +--
1 file changed, 29 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c
index 92c38a81bd..c0100e91c7 100644
--- a/drivers/net/ftgmac100.c
+++ b/drivers/net/ftgmac100.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "ftgmac100.h"
@@ -81,6 +82,7 @@ struct ftgmac100_data {
struct mii_dev *bus;
u32 phy_mode;
u32 max_speed;
+ bool ncsi_mode;
struct clk_bulk clks;
@@ -181,7 +183,7 @@ static int ftgmac100_phy_adjust_link(struct ftgmac100_data
*priv)
struct phy_device *phydev = priv->phydev;
u32 maccr;
- if (!phydev->link) {
+ if (!phydev->link && !priv->ncsi_mode) {
dev_err(phydev->dev, "No link\n");
return -EREMOTEIO;
}
@@ -217,7 +219,8 @@ static int ftgmac100_phy_init(struct udevice *dev)
if (!phydev)
return -ENODEV;
- phydev->supported &= PHY_GBIT_FEATURES;
+ if (!priv->ncsi_mode)
+ phydev->supported &= PHY_GBIT_FEATURES;
if (priv->max_speed) {
ret = phy_set_supported(phydev, priv->max_speed);
if (ret)
@@ -275,7 +278,8 @@ static void ftgmac100_stop(struct udevice *dev)
writel(0, >maccr);
- phy_shutdown(priv->phydev);
+ if (!priv->ncsi_mode)
+ phy_shutdown(priv->phydev);
}
static int ftgmac100_start(struct udevice *dev)
@@ -513,6 +517,7 @@ static int ftgmac100_ofdata_to_platdata(struct udevice *dev)
pdata->iobase = devfdt_get_addr(dev);
pdata->phy_interface = -1;
phy_mode = dev_read_string(dev, "phy-mode");
+
if (phy_mode)
pdata->phy_interface = phy_get_interface_by_name(phy_mode);
if (pdata->phy_interface == -1) {
@@ -537,8 +542,13 @@ static int ftgmac100_probe(struct udevice *dev)
{
struct eth_pdata *pdata = dev_get_platdata(dev);
struct ftgmac100_data *priv = dev_get_priv(dev);
+ const char *phy_mode;
int ret;
+ phy_mode = dev_read_string(dev, "phy-mode");
+ priv->ncsi_mode = dev_read_bool(dev, "use-ncsi") ||
+ (phy_mode && strcmp(phy_mode, "NC-SI") == 0);
+
priv->iobase = (struct ftgmac100 *)pdata->iobase;
priv->phy_mode = pdata->phy_interface;
priv->max_speed = pdata->max_speed;
@@ -548,10 +558,15 @@ static int ftgmac100_probe(struct udevice *dev)
if (ret)
goto out;
- ret = ftgmac100_mdio_init(dev);
- if (ret) {
- dev_err(dev, "Failed to initialize mdiobus: %d\n", ret);
- goto out;
+ if (priv->ncsi_mode) {
+ printf("%s - NCSI detected\n", __func__);
+ } else {
+ ret = ftgmac100_mdio_init(dev);
+ if (ret) {
+ dev_err(dev, "Failed to initialize mdiobus: %d\n", ret);
+ goto out;
+ }
+
}
ret = ftgmac100_phy_init(dev);
@@ -571,9 +586,13 @@ static int ftgmac100_remove(struct udevice *dev)
{
struct ftgmac100_data *priv = dev_get_priv(dev);
- free(priv->phydev);
- mdio_unregister(priv->bus);
- mdio_free(priv->bus);
+ if (!priv->ncsi_mode) {
+ free(priv->phydev);
+ mdio_unregister(priv->bus);
+ mdio_free(priv->bus);
+ } else {
+ free(priv->phydev);
+ }
clk_release_bulk(>clks);
return 0;
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/4] phy: Add support for the NC-SI protocol
This introduces support for the NC-SI protocol, modelled as a phy driver
for other ethernet drivers to consume.
NC-SI (Network Controller Sideband Interface) is a protocol to manage a
sideband connection to a proper network interface, for example a BMC
(Baseboard Management Controller) sharing the NIC of the host system.
Probing and configuration occurs by communicating with the "remote" NIC
via NC-SI control frames (Ethernet header 0x88f8).
This implementation is roughly based on the upstream Linux
implementation[0], with a reduced feature set and an emphasis on getting
a link up as fast as possible rather than probing the full possible
topology of the bus.
The current phy model relies on the network being "up", sending NC-SI
command frames via net_send_packet() and receiving them from the
net_loop() loop (added in a following patch).
The ncsi-pkt.h header[1] is copied from the Linux kernel for consistent
field definitions.
[0]: https://github.com/torvalds/linux/tree/master/net/ncsi
[1]: https://github.com/torvalds/linux/blob/master/net/ncsi/ncsi-pkt.h
Signed-off-by: Samuel Mendoza-Jonas
---
drivers/net/phy/Kconfig | 4 +
drivers/net/phy/Makefile | 1 +
drivers/net/phy/ncsi.c | 892 +++
include/net.h| 1 +
include/net/ncsi-pkt.h | 415 ++
include/net/ncsi.h | 14 +
include/phy.h| 1 +
7 files changed, 1328 insertions(+)
create mode 100644 drivers/net/phy/ncsi.c
create mode 100644 include/net/ncsi-pkt.h
create mode 100644 include/net/ncsi.h
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 3dc0822d9c..f6dde8af1c 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -227,4 +227,8 @@ config PHY_FIXED
on, the link is always up with fixed speed and fixed duplex-setting.
More information: doc/device-tree-bindings/net/fixed-link.txt
+config PHY_NCSI
+ bool "NC-SI based PHY"
+ depends on DM_ETH
+
endif #PHYLIB
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 555da83630..32a8409a85 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -30,3 +30,4 @@ obj-$(CONFIG_PHY_XILINX) += xilinx_phy.o
obj-$(CONFIG_PHY_VITESSE) += vitesse.o
obj-$(CONFIG_PHY_MSCC) += mscc.o
obj-$(CONFIG_PHY_FIXED) += fixed.o
+obj-$(CONFIG_PHY_NCSI) += ncsi.o
diff --git a/drivers/net/phy/ncsi.c b/drivers/net/phy/ncsi.c
new file mode 100644
index 00..b1b717ed5c
--- /dev/null
+++ b/drivers/net/phy/ncsi.c
@@ -0,0 +1,892 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * NC-SI protocol configuration
+ *
+ * Copyright (C) 2019, IBM Corporation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define NCSI_PACKAGE_MAX 8
+#define NCSI_CHANNEL_MAX 31
+
+#define NCSI_PACKAGE_SHIFT 5
+#define NCSI_PACKAGE_INDEX(c) (((c) >> NCSI_PACKAGE_SHIFT) & 0x7)
+#define NCSI_RESERVED_CHANNEL 0x1f
+#define NCSI_CHANNEL_INDEX(c) ((c) & ((1 << NCSI_PACKAGE_SHIFT) - 1))
+#define NCSI_TO_CHANNEL(p, c) (((p) << NCSI_PACKAGE_SHIFT) | (c))
+
+#define NCSI_PKT_REVISION 0x01
+
+#define NCSI_CAP_GENERIC_MASK 0x7f
+#define NCSI_CAP_BC_MASK 0x0f
+#define NCSI_CAP_MC_MASK 0x3f
+#define NCSI_CAP_AEN_MASK 0x07
+#define NCSI_CAP_VLAN_MASK 0x07
+
+static void ncsi_send_ebf(unsigned int np, unsigned int nc);
+static void ncsi_send_ae(unsigned int np, unsigned int nc);
+static void ncsi_send_gls(unsigned int np, unsigned int nc);
+static int ncsi_send_command(unsigned int np, unsigned int nc, unsigned int
cmd,
+uchar *payload, int len, bool wait);
+
+struct ncsi_channel {
+ unsigned intid;
+ boolhas_link;
+
+ /* capabilities */
+ u32 cap_generic;
+ u32 cap_bc;
+ u32 cap_mc;
+ u32 cap_buffer;
+ u32 cap_aen;
+ u32 cap_vlan;
+
+ /* version information */
+ struct {
+ u32 version;/* Supported BCD encoded NCSI version */
+ u32 alpha2; /* Supported BCD encoded NCSI version */
+ u8 fw_name[12];/* Firmware name string */
+ u32 fw_version; /* Firmware version */
+ u16 pci_ids[4]; /* PCI identification */
+ u32 mf_id; /* Manufacture ID */
+ } version;
+
+};
+
+struct ncsi_package {
+ unsigned intid;
+ unsigned intn_channels;
+ struct ncsi_channel *channels;
+};
+
+struct ncsi {
+ enum {
+ NCSI_PROBE_PACKAGE_SP,
+ NCSI_PROBE_PACKAGE_DP,
+ NCSI_PROBE_CHANNEL_SP,
+ NCSI_PROBE_CHANNEL,
+ NCSI_CONFIG,
+ } state;
+
+ unsigned intpending_requests;
+ unsigned intrequests[256];
+ unsigned intlast_request;
+
+ unsigned int
[U-Boot] [PATCH 2/4] phy: Include NC-SI in phy setup
Add NC-SI to the usual phy handling. This makes two notable changes:
- Somewhat similar to a fixed phy, phy_connect() will create an NC-SI
phy if CONFIG_PHY_NCSI is defined.
- An early return is added to phy_read() and phy_write() to handle a
case like the NC-SI phy which does not define a bus.
Signed-off-by: Samuel Mendoza-Jonas
---
drivers/net/phy/phy.c | 8
include/phy.h | 11 +++
include/phy_interface.h | 2 ++
3 files changed, 21 insertions(+)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index cda4caa803..c2bc57c45d 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -527,6 +527,9 @@ int phy_init(void)
#endif
#ifdef CONFIG_PHY_FIXED
phy_fixed_init();
+#endif
+#ifdef CONFIG_PHY_NCSI
+ phy_ncsi_init();
#endif
return 0;
}
@@ -902,6 +905,11 @@ struct phy_device *phy_connect(struct mii_dev *bus, int
addr,
sn = fdt_next_subnode(gd->fdt_blob, sn);
}
#endif
+
+#ifdef CONFIG_PHY_NCSI
+ phydev = phy_device_create(bus, 0, PHY_NCSI_ID, interface);
+#endif
+
if (!phydev)
phydev = phy_find_by_mask(bus, 1 << addr, interface);
diff --git a/include/phy.h b/include/phy.h
index f0c9df46c6..e1d546a81f 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -154,6 +154,11 @@ static inline int phy_read(struct phy_device *phydev, int
devad, int regnum)
{
struct mii_dev *bus = phydev->bus;
+ if (!bus || !bus->read) {
+ debug("%s: No bus configured\n", __func__);
+ return -1;
+ }
+
return bus->read(bus, phydev->addr, devad, regnum);
}
@@ -162,6 +167,11 @@ static inline int phy_write(struct phy_device *phydev, int
devad, int regnum,
{
struct mii_dev *bus = phydev->bus;
+ if (!bus || !bus->read) {
+ debug("%s: No bus configured\n", __func__);
+ return -1;
+ }
+
return bus->write(bus, phydev->addr, devad, regnum, val);
}
@@ -241,6 +251,7 @@ int phy_vitesse_init(void);
int phy_xilinx_init(void);
int phy_mscc_init(void);
int phy_fixed_init(void);
+int phy_ncsi_init(void);
int board_phy_config(struct phy_device *phydev);
int get_phy_id(struct mii_dev *bus, int addr, int devad, u32 *phy_id);
diff --git a/include/phy_interface.h b/include/phy_interface.h
index c6823189f8..9e334bb47d 100644
--- a/include/phy_interface.h
+++ b/include/phy_interface.h
@@ -31,6 +31,7 @@ typedef enum {
PHY_INTERFACE_MODE_XLAUI,
PHY_INTERFACE_MODE_CAUI2,
PHY_INTERFACE_MODE_CAUI4,
+ PHY_INTERFACE_MODE_NCSI,
PHY_INTERFACE_MODE_NONE,/* Must be last */
PHY_INTERFACE_MODE_COUNT,
@@ -58,6 +59,7 @@ static const char * const phy_interface_strings[] = {
[PHY_INTERFACE_MODE_XLAUI] = "xlaui4",
[PHY_INTERFACE_MODE_CAUI2] = "caui2",
[PHY_INTERFACE_MODE_CAUI4] = "caui4",
+ [PHY_INTERFACE_MODE_NCSI] = "NC-SI",
[PHY_INTERFACE_MODE_NONE] = "",
};
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/4] NC-SI PHY Support
This series introduces support for the NC-SI protocol to u-boot, functionality which so far has only been available in vendor trees. NC-SI (Network Controller Sideband Interface) is a protocol to manage a sideband connection to a proper network interface, for example a BMC (Baseboard Management Controller) sharing the NIC of the host system. Probing and configuration occurs by communicating with the "remote" NIC via NC-SI control frames (Ethernet header 0x88f8). Since the RFC[0] the changes have been split out into a few different patches to make the overall changes more obvious. Additionally a few small improvements have been added including adding a check to see if NC-SI is already configured, and marking the PHY bus "reset" as invalid since it does not define a bus. An example of NC-SI setup before a normal network command: => dhcp net_loop: configuring NCSI first ethernet@1e66: link up, 100 Mbps full-duplex mac:0c:c4:7a:d5:48:43 NCSI: probing channels NCSI: configuring channel 0 NCSI: configuration done! BOOTP broadcast 1 BOOTP broadcast 2 DHCP client bound to address 10.61.161.188 (255 ms) [0]: https://patchwork.ozlabs.org/patch/1107087/ Samuel Mendoza-Jonas (4): phy: Add support for the NC-SI protocol phy: Include NC-SI in phy setup net/ftgmac100: Add NC-SI mode support net: NC-SI setup and handling cmd/Kconfig | 6 + cmd/net.c| 18 + drivers/net/ftgmac100.c | 39 +- drivers/net/phy/Kconfig | 4 + drivers/net/phy/Makefile | 1 + drivers/net/phy/ncsi.c | 892 +++ drivers/net/phy/phy.c| 8 + include/net.h| 3 +- include/net/ncsi-pkt.h | 415 ++ include/net/ncsi.h | 14 + include/phy.h| 12 + include/phy_interface.h | 2 + net/net.c| 27 +- 13 files changed, 1429 insertions(+), 12 deletions(-) create mode 100644 drivers/net/phy/ncsi.c create mode 100644 include/net/ncsi-pkt.h create mode 100644 include/net/ncsi.h -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] x86: SPI flash broken with SPI NOR
On 05/06/19 8:17 PM, Bin Meng wrote:
> Hi Vignesh,
>
> On Wed, Jun 5, 2019 at 9:40 PM Bin Meng wrote:
>>
>> Hi Vignesh,
>>
>> On Sat, Apr 27, 2019 at 12:26 AM Vignesh Raghavendra wrote:
>>>
>>> Bin,
>>>
>>> On 26/04/19 7:33 PM, Bin Meng wrote:
Hi Simon,
On Fri, Apr 26, 2019 at 7:26 AM Simon Glass wrote:
>
> Hi Bin,
>
> I find that 'sf test 0 1000' does not work anymore since this commit:
>
> c4e8862308 mtd: spi: Switch to new SPI NOR framework
>
> Have you seen any problems? This seems to prevent proper SPI flash
> writing (not sure about reading).
Yes, this seems to be broken. I just tested it on MinnowMax.
>>>
>>> What is the flash part on this board?
>>>
>>>
'sf probe' does not succeed anymore.
>>>
>>> Could you enable all debug prints in spi_mem_exec_op() in spi-mem.c:
>>> https://elixir.bootlin.com/u-boot/latest/source/drivers/spi/spi-mem.c#L376
>>>
>>> And the post the full log here. If the log is too big please paste it to
>>> pastebin.ubuntu.com
>>>
>>> Also please apply http://patchwork.ozlabs.org/patch/1090121/ on top of
>>> latest tree before doing any write to flash
>>>
>>> Sorry for the trouble.
>>>
>>
>> Sorry for the long delay. I finally got time to look into this.
>>
>> However with the latest u-boot/master, the SPI flash seems to work
>> again on Intel MinnowMax. Did you recall anything changes in the
>> spi-nor recently?
>
> The thing I know is:
>
> v2019.07-rc1: Intel ich-spi driver was broken
> v2019.07-rc2: Intel ich-spi driver worked again
>
> So I did a 'git bisect', although I used it in a reverse direction :)
>
> This is the commit that makes the Intel ich-spi driver work again.
That's great to know! There is a patch on ML to convert ich-spi to
spi-mem which should make driver much simpler[1]. It would be great to
have that patch tested and merged.
[]1https://patchwork.ozlabs.org/patch/1072475/
Regards
Vignesh
>
> commit 60e2bf46784ebbd30ff29b3d3c7c97e56b11e86a
> Author: Weijie Gao
> Date: Fri Apr 26 17:22:19 2019 +0800
>
> mtd: spi-nor: fix page program issue when using spi-mem driver
>
> Some SPI controllers can't write nor->page_size bytes in a single step
> because their TX FIFO is too small, but when that happens we should
> make sure a WRITE_EN command before each write access and READ_SR command
> after each write access is issued.
>
> We should allow nor->write() to return a size that is smaller than the
> requested write size to gracefully handle this case.
>
> Also, the spi_nor_write_data() should return the actual number of bytes
> that were written during the spi_mem_exec_op() operation.
>
> This patch is a combination of two commits backported from kernel:
>
> commit 630d6bd8a3b4 ("mtd: spi-nor: Support controllers with limit ...")
> commit 3baa8ec88c2f ("mtd: devices: m25p80: Make sure WRITE_EN is ...")
>
> Cc: Vignesh R
> Signed-off-by: Weijie Gao
> Acked-by: Vignesh R
> Tested-by: Shyam Saini # microzed
> Acked-by: Jagan Teki
>
> Hi Simon,
>
> Could you please confirm that on the Chromebook?
>
> Regards,
> Bin
>
--
Regards
Vignesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] lib: Makefile: build fdtdec_common.c when OF_LIBFDT selected
> Subject: Re: [PATCH] lib: Makefile: build fdtdec_common.c when OF_LIBFDT > selected > > On 5/31/19 5:11 AM, Peng Fan wrote: > > When build SPL_OF_PLATDATA on i.MX6, meet issue the fdtdec_get_int not > > defined, however fdtdec.c will use fdtdec_get_int, so let's compile > > fdtdec_common.c when OF_LIBFDT selected. > > > > Signed-off-by: Peng Fan > > --- > > lib/Makefile | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/lib/Makefile b/lib/Makefile index 09c45b8122..66ab6295a5 > > 100644 > > --- a/lib/Makefile > > +++ b/lib/Makefile > > @@ -88,7 +88,7 @@ obj-y += crc32.o > > obj-$(CONFIG_CRC32C) += crc32c.o > > obj-y += ctype.o > > obj-y += div64.o > > -obj-$(CONFIG_OF_LIBFDT) += fdtdec.o > > +obj-$(CONFIG_OF_LIBFDT) += fdtdec.o fdtdec_common.o > > Shouldn't this be CONFIG_$(SPL_TPL_)OF_LIBFDT? You are right. I'll use this and do a CI build. If no issue, I'll post out v2. Thanks, Peng > > Regards > > Heinrich > > > obj-y += hang.o > > obj-y += linux_compat.o > > obj-y += linux_string.o > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX > container format file > > On Wed, Jun 05, 2019 at 03:24:40PM +0200, Marek Vasut wrote: > > On 6/5/19 5:03 AM, Peng Fan wrote: > > [...] > > > It is not duplication of FIT. Container support the similar > > > function of FIT image, but it is not only that. > > > > So what is it ? > > >>> > > >>> > > >> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > >>> > > >> > nxp.com%2Fdocs%2Fen%2Freference-manual%2FIMX8DQXPRM.pdfda > > >> ta=02%7C > > >>> > > >> > 01%7Cpeng.fan%40nxp.com%7C72216052f4234a93ad1f08d6e95ed782%7C6 > > >> 86ea1d3b > > >>> > > >> > c2b4c6fa92cd99c5c301635%7C0%7C1%7C636952990895125305sdat > > >> a=KO%2B0e > > >>> > > >> > E3v%2FkHuJ%2BhR7mBgc4NWXxbMUupfubXXu%2BueIWo%3Dreserv > > >> ed=0 > > >>> Chapter 5 has information about container set and container. > > >> > > >> Thanks, any specific part of those 80 pages ? > > > > > > Figure 5-24. Container Format has a picture about a single container. > > > i.MX8 container also support container sets, support encrypt blob, > > > certificates, SRK management. Support signature to the whole > > > container, no need single image inside container. > > > > Isn't that all supported in fitImage too ? > > This is neither the first nor last time functionality has been essentially > duplicated, sadly, for reasons. I'll share the fit things to our ROM stakeholders, but they take decision on new SoC design. > > > I don't think I get it. Why would I, as an iMX8 user, want to > > pick custom new vendor-specific format over years-proven generic > fitImage? > > >>> > > >>> We not against FIT, we already use FIT on i.MX8M, to let spl to > > >>> authenticate FIT image using ROM HAB, not using crypto driver. > > >> > > >> Great > > >> > > What is the selling point here ? > > >>> > > >>> We would not introduce cypto driver in SPL stage, that means HAB > > >>> FIT and AHAB container needs to be dropped when SPL loading other > images. > > >>> ROM already provides API for bootloader to authenticate images, > > >>> introducing complex crypto driver in SPL could enlarge code size > > >>> and make things complicated. > > >> > > >> Ah I see, so it's all making the whole crypto simpler by offloading > > >> the hard parts into the firmware, which just magically handles > > >> everything , without having much extra code in the SPL ? > > > > > > Yes. Use what ROM provides will make things easier for U-Boot. > > > > Is it possible to perform a security audit on the ROM as easily as on > > U-Boot ? I mean, U-Boot is free software, the source is available, so > > security researchers can easily scrutinize it. Is the ROM ? > > So, here's my two cents (and it may or may not seem contradictory with my > opinions in the secure boot thread going on currently on the Linaro Boot > Architecture list). Yes, it would and IMHO is better when we use free and > open software to solve our problems (and an aside to the RISC-V folks as this > is yet another area they can make the world a better place in). But I am a > believe in dealing with the world as it stands at times too. The question > isn't > "can we get NXP to re-spin i.MX8 to use the FIT image format?" as that's > obviously going to be "No.". The question is, "can we support this format in > a clean manner?" and the answer is obviously "Yes.". So please lets keep > that in mind with reviewing the code as at the end of the day it is more > beneficial for this to be supported in mainline U-Boot than only supported in > the vendor tree. Thanks. So I think you agree the current approach. Could I get any A-b or R-b tags from the list? Thanks, Peng. > Thanks! > > -- > Tom ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] i.MX8MM mapped register access causes crashes
> Subject: Re: [U-Boot] i.MX8MM mapped register access causes crashes > > On Wed, Jun 5, 2019 at 10:52 PM Peng Fan wrote: > > > You need to pass an arg after `md 0x302d`. Default it will dump a > > lot registers, might 40 registers. It surely will crash, because there > > are only a few registers in GPT1 which is the address you are dumping. > > Other suggestion is to make sure that the clock for the peripheral you are > trying to access is turned on. Dump `md 0x302d 1` will surely work, but dump `md 0x302d 100` will surely crash. The clock already on. It is that GPT1 does not have 100 registers, and trigger error when dumping non-existed registers. Regards, Peng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] i.MX8MM mapped register access causes crashes
On Wed, Jun 5, 2019 at 10:52 PM Peng Fan wrote: > You need to pass an arg after `md 0x302d`. Default it will dump > a lot registers, might 40 registers. It surely will crash, because there > are only a few registers in GPT1 which is the address you are dumping. Other suggestion is to make sure that the clock for the peripheral you are trying to access is turned on. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] i.MX8MM mapped register access causes crashes
> Subject: i.MX8MM mapped register access causes crashes > > Hi Peng, > > I'm still trying to get my i.MX8MM board running with mainline U-Boot. > I'm using your patches and added some modifications, so I'm now able to run > SPL and U-Boot proper. > > One problem I have is, that accessing some regions in the memory map for > peripheral register access, U-Boot crashes or hangs. > > Example: > > => md 0x302d You need to pass an arg after `md 0x302d`. Default it will dump a lot registers, might 40 registers. It surely will crash, because there are only a few registers in GPT1 which is the address you are dumping. Regards, Peng > 302d: 0743 e031 C...1... > 302d0010: > 302d0020: 001012ec"Synchronous Abort" handler, esr 0x96000210 > elr: 40251b84 lr : 40251ba0 (reloc) > elr: bffa3b84 lr : bffa3ba0 > x0 : bffb9000 x1 : 308800b4 > x2 : bff6e9b4 x3 : 302d0028 > x4 : x5 : bffb96a2 > x6 : 0004 x7 : bbf3c330 > x8 : bbf3c2f0 x9 : 000c > x10: ffd8 x11: 0006 > x12: 0001869f x13: 4238 > x14: bbf3c59c x15: 0008 > x16: b900 x17: ae80 > x18: bbf41d70 x19: 0038 > x20: 302d0020 x21: 302d0020 > x22: bffb8e5f x23: 0008 > x24: 0004 x25: 0004 > x26: 0004 x27: bbf3c3b8 > x28: 0002 x29: bbf3c330 > > Do you have any idea what might be wrong or how I could debug this issue? > > Thanks, > Frieder ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Pull request, u-boot-tegra/master
Tom,
Please pull u-boot-tegra/master into U-Boot/master. Thanks!
All Tegra builds are OK, and Stephen's automated test system reports that
all tests pass.
The following changes since commit 6d93d245c148f10f15724601650fab3a665f102c:
Merge git://git.denx.de/u-boot-riscv (2019-06-05 10:07:31 -0400)
are available in the git repository at:
git://git.denx.de/u-boot-tegra.git master
for you to fetch changes up to 879a3bc1c2f3e2aadd6f05e6427cf4d97a272f9a:
ARM: tegra: Mark built-in Ethernet as default on Jetson TX2 (2019-06-05
09:16:35 -0700)
Thierry Reding (26):
fdtdec: Add fdtdec_set_ethernet_mac_address()
lib: Implement strndup()
ARM: tegra: Fix mux type for disp1 and disp2 clocks on Tegra210
ARM: tegra: Remove disp1 clock initialization on Tegra210
ARM: tegra: Use common header for PMU declarations
ARM: tegra: Guard clock code with a Kconfig symbol
ARM: tegra: Guard GP pad control code with a Kconfig symbol
ARM: tegra: Guard memory controller code with a Kconfig symbol
ARM: tegra: Guard pin controller code with a Kconfig symbol
ARM: tegra: Guard powergate code with a Kconfig symbol
ARM: tegra: Fix save_boot_params() prototype
ARM: tegra: Allow boards to override boot target devices
ARM: tegra: Support TZ-only access to PMC
ARM: tegra: Workaround UDC boot issues only if necessary
ARM: tegra: Restore DRAM bank count
ARM: tegra: Unify Tegra186 builds
ARM: tegra: Implement cboot_save_boot_params() in C
ARM: tegra: Implement cboot_get_ethaddr()
ARM: tegra: Import cbootargs value from cboot DTB
ARM: tegra: Enable position independent build for 64-bit
p2371-2180: Pass Ethernet MAC to the kernel
p2771-: Pass Ethernet MAC to the kernel
p2371-2180: Add support for framebuffer carveouts
p2771-: Add support for framebuffer carveouts
ARM: tegra: Rename pcie-controller to pcie
ARM: tegra: Mark built-in Ethernet as default on Jetson TX2
arch/arm/dts/tegra124-apalis.dts | 2 +-
arch/arm/dts/tegra124-cei-tk1-som.dts | 2 +-
arch/arm/dts/tegra124-jetson-tk1.dts | 2 +-
arch/arm/dts/tegra124.dtsi | 2 +-
arch/arm/dts/tegra186-p2771--000.dts | 2 +-
arch/arm/dts/tegra186-p2771--500.dts | 2 +-
arch/arm/dts/tegra186-p2771-.dtsi | 2 +
arch/arm/dts/tegra186.dtsi | 2 +-
arch/arm/dts/tegra20-harmony.dts | 2 +-
arch/arm/dts/tegra20-trimslice.dts | 2 +-
arch/arm/dts/tegra20.dtsi | 2 +-
arch/arm/dts/tegra210-p2371-2180.dts | 2 +-
arch/arm/dts/tegra210.dtsi | 2 +-
arch/arm/dts/tegra30-apalis.dts| 2 +-
arch/arm/dts/tegra30-beaver.dts| 2 +-
arch/arm/dts/tegra30-cardhu.dts| 2 +-
arch/arm/dts/tegra30.dtsi | 2 +-
arch/arm/include/asm/arch-tegra/cboot.h| 45 ++
arch/arm/include/asm/arch-tegra/pmc.h | 20 +-
.../include/asm/{arch-tegra20 => arch-tegra}/pmu.h | 6 +-
arch/arm/include/asm/arch-tegra/tegra.h| 6 +
arch/arm/include/asm/arch-tegra114/pmu.h | 12 -
arch/arm/include/asm/arch-tegra124/pmu.h | 13 -
arch/arm/include/asm/arch-tegra210/pmu.h | 13 -
arch/arm/include/asm/arch-tegra30/pmu.h| 12 -
arch/arm/mach-tegra/Kconfig| 32 ++
arch/arm/mach-tegra/Makefile | 16 +-
arch/arm/mach-tegra/board.c| 41 +-
arch/arm/mach-tegra/board186.c | 32 --
arch/arm/mach-tegra/board2.c | 37 +-
arch/arm/mach-tegra/cache.c| 2 +
arch/arm/mach-tegra/cboot.c| 620
+
arch/arm/mach-tegra/clock.c| 13 +-
arch/arm/mach-tegra/cmd_enterrcm.c | 6 +-
arch/arm/mach-tegra/cpu.c | 20 +-
arch/arm/mach-tegra/emc.c | 2 +-
arch/arm/mach-tegra/lowlevel_init.S| 39 --
arch/arm/mach-tegra/pmc.c | 92 +++
arch/arm/mach-tegra/powergate.c| 11 +-
arch/arm/mach-tegra/tegra186/Makefile | 4 -
arch/arm/mach-tegra/tegra186/nvtboot_board.c | 332 ---
arch/arm/mach-tegra/tegra186/nvtboot_ll.S | 20 -
arch/arm/mach-tegra/tegra186/nvtboot_mem.c | 172 --
arch/arm/mach-tegra/tegra210/clock.c | 11 +-
board/nvidia/p2371-2180/p2371-2180.c | 97
board/nvidia/p2771-/p2771-.c | 111 +++-
configs/e2220-1170_defconfig | 2 +-
Re: [U-Boot] [PATCH 2/2] mmc: Register only the first MMC device on MMC_TINY
On Sat, 25 May 2019 at 19:26, Ezequiel Garcia wrote:
>
> When MMC_TINY is enabled, support for only one MMC device
> is provided. Boards that register more than one device,
> will just write over mmc_static keeping only the last one
> registered.
>
> This commit prevents this, keeping only the first MMC
> device created. A debug warning message is added, if nothing
> else, as a hint/documentation for developers.
>
> Signed-off-by: Ezequiel Garcia
Not sure if it's too early for an gently ping here.
I just want to make sure these two will get some eyes.
Thanks,
Eze
> ---
> drivers/mmc/mmc_legacy.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/mmc/mmc_legacy.c b/drivers/mmc/mmc_legacy.c
> index 66a7cda440cd..b0f5cf58a2b3 100644
> --- a/drivers/mmc/mmc_legacy.c
> +++ b/drivers/mmc/mmc_legacy.c
> @@ -150,6 +150,15 @@ struct mmc *mmc_create(const struct mmc_config *cfg,
> void *priv)
> {
> struct mmc *mmc = _static;
>
> + /* First MMC device registered, fail to register a new one.
> +* Given users are not expecting this to fail, instead
> +* of failing let's just return the only MMC device
> +*/
> + if (mmc->cfg) {
> + debug("Warning: MMC_TINY doesn't support multiple MMC
> devices\n");
> + return mmc;
> + }
> +
> mmc->cfg = cfg;
> mmc->priv = priv;
>
> --
> 2.20.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] board/km: update maintainer e-mail
On Tue, Jun 04, 2019 at 02:10:32PM +0200, holger.bru...@ch.abb.com wrote: > From: Holger Brunck > > Signed-off-by: Holger Brunck Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2] arm: omap3: Manually initialize GPIO if OF_CONTROL doesn't
On Wed, May 29, 2019 at 03:42:53PM -0500, Adam Ford wrote: > The commong initialization code manually initializes the GPIO > even when OF_CONTROL does it, so we can reduce the code size a > bit by not doing it manually when we have device tree support. > > Using the omap3_logic board (dm3730), the sizes shrunk: > > Before: > >text data bss dec hex filename > 561066 28596 116880 706542 ac7ee u-boot > 55245 16051888 58738e572 spl/u-boot-spl > > After > text data bss dec hex filename > 560898 28548 116872 706318 ac70e u-boot > 55121 15571888 58566e4c6 spl/u-boot-spl > > Signed-off-by: Adam Ford Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2] ARM: DTS: imx6q-logicpd: Resync with Linux 5.1
On Fri, May 31, 2019 at 07:09:22AM -0500, Adam Ford wrote: > Resync imx6q-logicpd with Kernel 5.1.5 > > Signed-off-by: Adam Ford Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: da850evm: Fix reading MAC from SPI
On Wed, May 29, 2019 at 09:36:58AM -0500, Adam Ford wrote: > The MAC address is located at at the last 64K of SPI Flash, and > it's 6 bytes long. This patch corrects both the length and > starting byte of the MAC address. > > Signed-off-by: Adam Ford > > diff --git a/board/davinci/da8xxevm/da850evm.c > b/board/davinci/da8xxevm/da850evm.c > index 1bc26828bf..a90b7a3538 100644 Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] ARM: davinci: SPL: fix BSS initialization
On Thu, May 30, 2019 at 07:04:55PM +0530, Sekhar Nori wrote:
> U-Boot README recommends initializing SDRAM in board_init_f(). DA850
> was doing it as part of board_init_r() (through call to spl_board_init()
> which calls arch_cpu_init() which calls da850_ddr_setup())
>
> This worked fine till commit 15b8c7505819 ("davinci:
> da850evm/omapl138-lcdk: Move BSS to SDRAM because SRAM is full") moved
> BSS to SDRAM.
>
> Functions like mmc_initialize() called in board_init_r() assume BSS is
> available. Since SDRAM was not initialized when arch/arm/lib/crt0.S tried
> to initialize BSS to 0, BSS is not initialized correctly.
>
> Fix this by simply calling arch_cpu_init() from board_init_f(). Also move
> preloader_console_init() there to help debug issues with board_init_r().
>
> With this spl_board_init() is no longer needed, we remove it.
>
> Tested using MMC/SD boot on OMAP-L138 LCDK board.
>
> Tested-by: Adam Ford #da850evm
> Signed-off-by: Sekhar Nori
> Tested-by: Peter Howard #omapl138_lcdk
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] arm: davinci: remove leftover assembly
On Wed, May 29, 2019 at 10:02:00AM +0200, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > There are no more users of lowlevel_init.S. Remove the file. > > Suggested-by: Adam Ford > Signed-off-by: Bartosz Golaszewski Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] ARM: davinci: omal138_lcdk: fix MMC boot breakage due to driver model conversion
On Thu, May 30, 2019 at 07:04:54PM +0530, Sekhar Nori wrote:
> commit 21af33ed0319 ("ARM: davinci: omapl138_lcdk: Enable DM_MMC")
> wanted to enable DM_MMC only for U-Boot and not for SPL.
>
> But CONFIG_DM_MMC is defined for SPL build too. Because of this
> MMC device was not getting registered for SPL causing MMC/SD
> boot breakage.
>
> Instead use CONFIG_IS_ENABLED(DM_MMC) which will remain false until
> CONFIG_SPL_DM_MMC is defined.
>
> Tested-by: Adam Ford #da850evm
> Signed-off-by: Sekhar Nori
> Tested-by: Peter Howard #omapl138_lcdk
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: davinci: Remove ipam390 linker script from Kconfig
On Thu, May 30, 2019 at 06:04:44PM -0500, Adam Ford wrote: > With ipam390 support removed in we can remove the reference to the > linker script since that case will never be true. > > Signed-off-by: Adam Ford > Reviewed-by: Bartosz Golaszewski > > diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig > index 61e84e5129..adc50922c8 100644 Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] board: am335x/mux: configure the pins for 8-bit data transfer on MMC1
On Thu, May 23, 2019 at 02:07:23PM +0200, Jean-Jacques Hiblot wrote: > This is required for proper operation of the 8-bit data transfers. > This fixes transient errors seen on BeagleBone Black. > > Signed-off-by: Jean-Jacques Hiblot Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] configs/legoev3: define CONFIG_SKIP_LOWLEVEL_INIT
On Wed, May 29, 2019 at 10:01:59AM +0200, Bartosz Golaszewski wrote: > From: David Lechner > > This adds a define for CONFIG_SKIP_LOWLEVEL_INIT in the legoev3 config. > On the EV3, U-Boot is loaded into RAM by another bootloader, so we > don't need the lowlevel init in U-Boot. > > Signed-off-by: David Lechner > Signed-off-by: Bartosz Golaszewski Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] board/BuR/common: fix detection for PSC/STM resetcontroller
On Fri, May 10, 2019 at 11:22:00AM +0200, Hannes Schmelzer wrote: > Signed-off-by: Hannes Schmelzer Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd/led: check subcommand "list" instead "l"
On Mon, May 27, 2019 at 08:14:16AM +0200, Heiko Schocher wrote: > current implementation for checking if "led list" > command is called checks only if "l" is passed to the > led command. This prevents switching leds with name > which starts also with a "l". So check for passing > "list". > > While at it, also fix a typo in led command usage. > > Signed-off-by: Heiko Schocher Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] doc: Remove duplicated documentation directory
Commit ad7061ed742e ("doc: Move device tree bindings documentation to
doc/device-tree-bindings") moved all device tree binding documentation
to doc/device-tree-bindings directory.
The current U-Boot project still have two documentation directories:
- doc/
- Documentation/
Move all documentation and sphinx files to doc directory so all content
can be in a common place.
Signed-off-by: Breno Lima
---
MAINTAINERS| 2 +-
Makefile | 6 +++---
{Documentation => doc}/Makefile| 10 +-
{Documentation => doc}/conf.py | 0
.../device-tree-bindings}/arm/l2c2x0.txt | 0
.../device-tree-bindings}/axi/gdsys,ihs_axi.txt| 0
.../board/gdsys,board_gazerbeam.txt| 0
.../device-tree-bindings/clock}/fsl,mpc83xx-clk.txt| 0
.../device-tree-bindings}/cpu/fsl,mpc83xx.txt | 0
.../misc}/misc/fsl,mpc83xx-serdes.txt | 0
.../misc}/misc/gdsys,io-endpoint.txt | 0
.../misc}/misc/gdsys,iocon_fpga.txt| 0
.../misc}/misc/gdsys,iocpu_fpga.txt| 0
.../device-tree-bindings/misc}/misc/gdsys,soc.txt | 0
.../ram/fsl,mpc83xx-mem-controller.txt | 0
.../reserved-memory/reserved-memory.txt| 0
.../device-tree-bindings}/timer/fsl,mpc83xx-timer.txt | 0
{Documentation => doc}/efi.rst | 0
{Documentation => doc}/index.rst | 0
{Documentation => doc}/linker_lists.rst| 0
{Documentation => doc}/media/Makefile | 4 ++--
.../media/linker_lists.h.rst.exceptions| 0
{Documentation => doc}/serial.rst | 0
.../sphinx-static/theme_overrides.css | 0
{Documentation => doc}/sphinx/cdomain.py | 0
{Documentation => doc}/sphinx/kernel_include.py| 0
{Documentation => doc}/sphinx/kerneldoc.py | 0
{Documentation => doc}/sphinx/kfigure.py | 0
{Documentation => doc}/sphinx/load_config.py | 0
{Documentation => doc}/sphinx/parse-headers.pl | 2 +-
{Documentation => doc}/sphinx/requirements.txt | 0
{Documentation => doc}/sphinx/rstFlatTable.py | 2 +-
32 files changed, 13 insertions(+), 13 deletions(-)
rename {Documentation => doc}/Makefile (91%)
rename {Documentation => doc}/conf.py (100%)
rename {Documentation/devicetree/bindings =>
doc/device-tree-bindings}/arm/l2c2x0.txt (100%)
rename {Documentation/devicetree/bindings =>
doc/device-tree-bindings}/axi/gdsys,ihs_axi.txt (100%)
rename {Documentation/devicetree/bindings =>
doc/device-tree-bindings}/board/gdsys,board_gazerbeam.txt (100%)
rename {Documentation/devicetree/bindings/clk =>
doc/device-tree-bindings/clock}/fsl,mpc83xx-clk.txt (100%)
rename {Documentation/devicetree/bindings =>
doc/device-tree-bindings}/cpu/fsl,mpc83xx.txt (100%)
rename {Documentation/devicetree/bindings =>
doc/device-tree-bindings/misc}/misc/fsl,mpc83xx-serdes.txt (100%)
rename {Documentation/devicetree/bindings =>
doc/device-tree-bindings/misc}/misc/gdsys,io-endpoint.txt (100%)
rename {Documentation/devicetree/bindings =>
doc/device-tree-bindings/misc}/misc/gdsys,iocon_fpga.txt (100%)
rename {Documentation/devicetree/bindings =>
doc/device-tree-bindings/misc}/misc/gdsys,iocpu_fpga.txt (100%)
rename {Documentation/devicetree/bindings =>
doc/device-tree-bindings/misc}/misc/gdsys,soc.txt (100%)
rename {Documentation/devicetree/bindings =>
doc/device-tree-bindings}/ram/fsl,mpc83xx-mem-controller.txt (100%)
rename {Documentation/devicetree/bindings =>
doc/device-tree-bindings}/reserved-memory/reserved-memory.txt (100%)
rename {Documentation/devicetree/bindings =>
doc/device-tree-bindings}/timer/fsl,mpc83xx-timer.txt (100%)
rename {Documentation => doc}/efi.rst (100%)
rename {Documentation => doc}/index.rst (100%)
rename {Documentation => doc}/linker_lists.rst (100%)
rename {Documentation => doc}/media/Makefile (89%)
rename {Documentation => doc}/media/linker_lists.h.rst.exceptions (100%)
rename {Documentation => doc}/serial.rst (100%)
rename {Documentation => doc}/sphinx-static/theme_overrides.css (100%)
rename {Documentation => doc}/sphinx/cdomain.py (100%)
rename {Documentation => doc}/sphinx/kernel_include.py (100%)
rename {Documentation => doc}/sphinx/kerneldoc.py (100%)
rename {Documentation => doc}/sphinx/kfigure.py (100%)
rename {Documentation => doc}/sphinx/load_config.py (100%)
rename {Documentation => doc}/sphinx/parse-headers.pl (99%)
rename {Documentation => doc}/sphinx/requirements.txt (100%)
rename {Documentation => doc}/sphinx/rstFlatTable.py (99%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 33fd4652a4..78872169cd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -474,7 +474,7 @@ S: Maintained
T: git
[U-Boot] Pull request for UEFI sub-system for v2019.07-rc4 (2)
The following changes since commit 8a802a2eefd36865eaa3d927d1db7af63bb2d922: Merge tag 'rockchip-for-v2019.07-rc3' of git://git.denx.de/u-boot-rockchip (2019-05-31 07:17:09 -0400) are available in the Git repository at: git://git.denx.de/u-boot-efi.git tags/efi-2019-07-rc4-2 for you to fetch changes up to 4b27a761321fd17536e02644d0ec0373150eb570: cmd: env: add -nv option for UEFI non-volatile variable (2019-06-04 23:56:14 +0200) Travis CI has no complains: https://travis-ci.org/xypron2/u-boot/builds/541464942 Primary key fingerprint: 6DC4 F9C7 1F29 A6FA 06B7 6D33 C481 DBBC 2C05 1AC4 Pull request for UEFI sub-system for v2019.07-rc4-2 Support for managing the non-volatile attribute of UEFI variables is added though we do not have a backend for persistence yet. Error messages for changes of UEFI variables are provided. UEFI boottime service implementations are corrected. AKASHI Takahiro (6): efi_loader: bootmgr: print a message when loading from BootNext failed cmd: env: print a message when setting UEFI variable failed efi_loader: variable: support non-volatile attribute efi_loader: bootmgr: make BootNext non-volatile cmd: efidebug: make some boot variables non-volatile cmd: env: add -nv option for UEFI non-volatile variable Heinrich Schuchardt (6): efi_loader: DisconnectController() with no driver lib: time: export usec_to_tick() efi_loader: check timer events in Stall() efi_loader: fix EnableCursor() efi_loader: close protocols in UnloadImage() efi_loader: notify memory map changes arch/arm/mach-rockchip/rk_timer.c | 7 - cmd/efidebug.c| 3 +++ cmd/nvedit.c | 3 ++- cmd/nvedit_efi.c | 25 +++--- include/time.h| 9 +++ lib/efi_loader/efi_bootmgr.c | 9 +-- lib/efi_loader/efi_boottime.c | 55 +++ lib/efi_loader/efi_console.c | 1 + lib/efi_loader/efi_memory.c | 11 lib/efi_loader/efi_variable.c | 12 ++--- lib/time.c| 2 +- 11 files changed, 114 insertions(+), 23 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Using fw_setenv to set negative numbers
Hi, have you tried quoting your value? fw_setenv bootdelay "-2" or fw_setenv bootdelay '-2' regards Frank > Gesendet: Mittwoch, 05. Juni 2019 um 16:57 Uhr > Von: "Ken Sloat" > An: "u-boot@lists.denx.de" > Cc: "Ken Sloat" > Betreff: [U-Boot] Using fw_setenv to set negative numbers > > Hello, > > I had a question regarding the use of fw_setenv. I am currently running > U-Boot 2018.07 > > How can I set a negative number using the standard command call to fw_setenv? > For example, if want to set bootdelay to a value of -2 (boot without delay), > I currently > cannot just say: > fw_setenv bootdelay -2 > > fw_setenv thinks 2 is an option I am trying to pass. What is the correct way > to do this > (if any)? One work around is to place the name value pair in a script file > and call it > With the --script option but was just wondering if there was direct way to > accomplish > this. Otherwise, this might be a needed change in the future. > > Thanks, > Ken Sloat > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] watchdog: Split WDT from SPL_WDT
Hi Marek,
> On Sun, 12 May 2019 23:34:52 +0200
> Marek Vasut wrote:
>
> > Use CONFIG_IS_ENABLED(WDT) to permit use of WDT in SPL without DM,
> > while the full U-Boot can use rich DM/DT WDT driver.
> >
> > Signed-off-by: Marek Vasut
> > Cc: Peng Fan
> > Cc: Stefano Babic
> > ---
> > common/board_r.c | 2 +-
> > common/spl/spl.c | 2 +-
> > drivers/watchdog/Makefile | 2 +-
> > include/asm-generic/global_data.h | 2 +-
> > include/wdt.h | 2 +-
> > 5 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/common/board_r.c b/common/board_r.c
> > index 150e8cd424..988e40abb2 100644
> > --- a/common/board_r.c
> > +++ b/common/board_r.c
> > @@ -678,7 +678,7 @@ static init_fnc_t init_sequence_r[] = {
> > #ifdef CONFIG_DM
> > initr_dm,
> > #endif
> > -#if defined(CONFIG_WDT)
> > +#if CONFIG_IS_ENABLED(WDT)
> > initr_watchdog,
> > #endif
> > #if defined(CONFIG_ARM) || defined(CONFIG_NDS32) ||
> > defined(CONFIG_RISCV) || \ diff --git a/common/spl/spl.c
> > b/common/spl/spl.c index 0a6a47c202..f22f854718 100644
> > --- a/common/spl/spl.c
> > +++ b/common/spl/spl.c
> > @@ -601,7 +601,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
> > spl_board_init();
> > #endif
> >
> > -#if defined(CONFIG_SPL_WATCHDOG_SUPPORT) && defined(CONFIG_WDT)
> > +#if defined(CONFIG_SPL_WATCHDOG_SUPPORT) && CONFIG_IS_ENABLED(WDT)
> > initr_watchdog();
> > #endif
> >
> > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> > index 40b2f4bc66..4b94ae988c 100644
> > --- a/drivers/watchdog/Makefile
> > +++ b/drivers/watchdog/Makefile
> > @@ -16,7 +16,7 @@ obj-$(CONFIG_OMAP_WATCHDOG) += omap_wdt.o
> > obj-$(CONFIG_DESIGNWARE_WATCHDOG) += designware_wdt.o
> > obj-$(CONFIG_TANGIER_WATCHDOG) += tangier_wdt.o
> > obj-$(CONFIG_ULP_WATCHDOG) += ulp_wdog.o
> > -obj-$(CONFIG_WDT) += wdt-uclass.o
> > +obj-$(CONFIG_$(SPL_TPL_)WDT) += wdt-uclass.o
> > obj-$(CONFIG_WDT_SANDBOX) += sandbox_wdt.o
> > obj-$(CONFIG_WDT_ARMADA_37XX) += armada-37xx-wdt.o
> > obj-$(CONFIG_WDT_ASPEED) += ast_wdt.o
> > diff --git a/include/asm-generic/global_data.h
> > b/include/asm-generic/global_data.h index 02a3ed6838..7c2220643b
> > 100644 --- a/include/asm-generic/global_data.h
> > +++ b/include/asm-generic/global_data.h
> > @@ -137,7 +137,7 @@ typedef struct global_data {
> > #if defined(CONFIG_TRANSLATION_OFFSET)
> > fdt_addr_t translation_offset; /* optional
> > translation offset */ #endif
> > -#if defined(CONFIG_WDT)
> > +#if CONFIG_IS_ENABLED(WDT)
> > struct udevice *watchdog_dev;
> > #endif
> > } gd_t;
> > diff --git a/include/wdt.h b/include/wdt.h
> > index aa77d3e9b4..5bcff24ab3 100644
> > --- a/include/wdt.h
> > +++ b/include/wdt.h
> > @@ -106,7 +106,7 @@ struct wdt_ops {
> > int (*expire_now)(struct udevice *dev, ulong flags);
> > };
> >
> > -#if defined(CONFIG_WDT)
> > +#if CONFIG_IS_ENABLED(WDT)
> > #ifndef CONFIG_WATCHDOG_TIMEOUT_MSECS
> > #define CONFIG_WATCHDOG_TIMEOUT_MSECS (60 * 1000)
> > #endif
>
> Tested-by: Lukasz Majewski
>
> Test HW: display5 i.MX6Q device
>
Unfortunately this series causes build break when run on Travis-CI for
some Atmel/Microchip:
arm: + picosam9g45
+lib/built-in.o: In function `udelay':
+lib/time.c:167: undefined reference to `watchdog_reset'
+drivers/built-in.o: In function `atmel_serial_getc':
+drivers/serial/atmel_usart.c:103: undefined reference to
`watchdog_reset' +make[2]: *** [spl/u-boot-spl] Error 1
+make[1]: *** [spl/u-boot-spl] Error 2
+make: *** [sub-make] Error 2
14 381 /53 axm
boards.cfg is up to date. Nothing to do.
Summary of current source for 53 boards (2 threads, 1 job per thread)
u-boot master SHA1: e1a2ed7180adeefb6164239a18249dca5701319d
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> lu...@denx.de
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgp8q1IOwpEHn.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Using fw_setenv to set negative numbers
On Wed, 5 Jun 2019 15:57:55 + Ken Sloat ksl...@aampglobal.com wrote: ... > How can I set a negative number using the standard command call to fw_setenv? > For example, if want to set bootdelay to a value of -2 (boot without delay), > I currently > cannot just say: > fw_setenv bootdelay -2 Try using "fw_setenv bootdelay -- -2" command, it should work. -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Using fw_setenv to set negative numbers
Hello, I had a question regarding the use of fw_setenv. I am currently running U-Boot 2018.07 How can I set a negative number using the standard command call to fw_setenv? For example, if want to set bootdelay to a value of -2 (boot without delay), I currently cannot just say: fw_setenv bootdelay -2 fw_setenv thinks 2 is an option I am trying to pass. What is the correct way to do this (if any)? One work around is to place the name value pair in a script file and call it With the --script option but was just wondering if there was direct way to accomplish this. Otherwise, this might be a needed change in the future. Thanks, Ken Sloat ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/12] System Firmware Loader for TI K3 family SoCs
On Wed, Jun 05, 2019 at 11:52:52AM +0530, Lokesh Vutla wrote: > > > On 05/06/19 4:25 AM, Andreas Dannenberg wrote: > > Updated version of the SYSFW loader series for K3 family AM654x devices. > > The fundamantal approach of tapping into the SPL loader framework has > > been kept for reasons discussed already. The series also still uses > > "early BSS" in SPL's board_init_f(). I'm well aware of the concerns > > previously brought up regarding this mainly by Simon Glass but I have > > not been able to find a better / more universal solution for this yet > > (one proposal was to move SYSFW loading into board_init_r() which is not > > easily solvable as SYSFW is needed to bring up DDR on K3 SoCs). Long > > story short I propose to consider the current proposed approach > > nevertheless (as it is also used by other platforms) at least as an > > initial step, and then migrate once a better solution is available. > > tested this series on AM654 evm using SD boot. FWIW: > Tested-by: Lokesh Vutla Thanks Lokesh. > > I have not yet included support for TI's newest K3 family J721E SoC > > which Lokesh posted an initial patch series [5] for due to the > > complex dependencies of all the different series we have currently > > posted/pending (if I were to add support for J721E which eventually will > > be required then the SYSFW loader series would have Lokesh's series as a > > pre-requisite as well). > > > > This being said I would like to propose the following staging sequence > > for the different TI K3 SoCs patches currently under review: > > > > Step 1) Faiz' "Add Support for eMMC in Am65x-evm" series [1]. It needs > > a small update to actuall allow for eMMC boot I posted earlier. > > Step 2) The SYSFW loader series proposed here > > Step 3) An updated version (v3) of the AM654x EEPROM support [3]. > > Will post this today. > > I would like to see the above 3 series be merged first. Will take care of the > rest of the J721e support and other. Yes that's what I'm proposing. > > Step 4) An updated version of Lokesh's "arm: k3: Allow for exclusive > > and shared device requests" series. In addition to a rebase > > such an updated series should include updating power domain > > properties for devices that were added during the previous > > steps. > > Step 5) An updated version of Lokesh's "arm: k3: arm64: Initial support > > Texas Instrument's J721E Platform" series [5] also adding > > in the few lines of codes to leverage SYSFW. > > Step 6 & beyond) Various rproc patches, etc. > > I have a slightly different order that you mentioned. Will repost everything > once the first 3 steps are sorted out. I don't have an issue with changing the order of what happens past step 3. But without the first three things (or first two, really) in place, we are kind of stuck turning in circles... :) -- Andreas Dannenberg Texas Instruments Inc ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] x86: SPI flash broken with SPI NOR
Hi Bin,
On Wed, 5 Jun 2019 at 08:47, Bin Meng wrote:
>
> Hi Vignesh,
>
> On Wed, Jun 5, 2019 at 9:40 PM Bin Meng wrote:
> >
> > Hi Vignesh,
> >
> > On Sat, Apr 27, 2019 at 12:26 AM Vignesh Raghavendra
> > wrote:
> > >
> > > Bin,
> > >
> > > On 26/04/19 7:33 PM, Bin Meng wrote:
> > > > Hi Simon,
> > > >
> > > > On Fri, Apr 26, 2019 at 7:26 AM Simon Glass wrote:
> > > >>
> > > >> Hi Bin,
> > > >>
> > > >> I find that 'sf test 0 1000' does not work anymore since this commit:
> > > >>
> > > >> c4e8862308 mtd: spi: Switch to new SPI NOR framework
> > > >>
> > > >> Have you seen any problems? This seems to prevent proper SPI flash
> > > >> writing (not sure about reading).
> > > >
> > > > Yes, this seems to be broken. I just tested it on MinnowMax.
> > > >
> > >
> > > What is the flash part on this board?
> > >
> > >
> > > > 'sf probe' does not succeed anymore.
> > > >
> > >
> > > Could you enable all debug prints in spi_mem_exec_op() in spi-mem.c:
> > > https://elixir.bootlin.com/u-boot/latest/source/drivers/spi/spi-mem.c#L376
> > >
> > > And the post the full log here. If the log is too big please paste it to
> > > pastebin.ubuntu.com
> > >
> > > Also please apply http://patchwork.ozlabs.org/patch/1090121/ on top of
> > > latest tree before doing any write to flash
> > >
> > > Sorry for the trouble.
> > >
> >
> > Sorry for the long delay. I finally got time to look into this.
> >
> > However with the latest u-boot/master, the SPI flash seems to work
> > again on Intel MinnowMax. Did you recall anything changes in the
> > spi-nor recently?
>
> The thing I know is:
>
> v2019.07-rc1: Intel ich-spi driver was broken
> v2019.07-rc2: Intel ich-spi driver worked again
>
> So I did a 'git bisect', although I used it in a reverse direction :)
>
> This is the commit that makes the Intel ich-spi driver work again.
>
> commit 60e2bf46784ebbd30ff29b3d3c7c97e56b11e86a
> Author: Weijie Gao
> Date: Fri Apr 26 17:22:19 2019 +0800
>
> mtd: spi-nor: fix page program issue when using spi-mem driver
>
> Some SPI controllers can't write nor->page_size bytes in a single step
> because their TX FIFO is too small, but when that happens we should
> make sure a WRITE_EN command before each write access and READ_SR command
> after each write access is issued.
>
> We should allow nor->write() to return a size that is smaller than the
> requested write size to gracefully handle this case.
>
> Also, the spi_nor_write_data() should return the actual number of bytes
> that were written during the spi_mem_exec_op() operation.
>
> This patch is a combination of two commits backported from kernel:
>
> commit 630d6bd8a3b4 ("mtd: spi-nor: Support controllers with limit ...")
> commit 3baa8ec88c2f ("mtd: devices: m25p80: Make sure WRITE_EN is ...")
>
> Cc: Vignesh R
> Signed-off-by: Weijie Gao
> Acked-by: Vignesh R
> Tested-by: Shyam Saini # microzed
> Acked-by: Jagan Teki
>
> Hi Simon,
>
> Could you please confirm that on the Chromebook?
I was broken when I last tested a few weeks ago. I'll try again.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] board/friendlyarm: Add support for friendlyarm nanopi neo4 board
On Tue, Jun 04, 2019 at 02:17:03PM +0530, Shyam Saini wrote:
> This initial support includes:
> Linux v5.2-rc1
> Custom U-Boot
> Arm Trusted Firmware v2.0
> Buildroot default packages
>
> Signed-off-by: Shyam Saini
> ---
> .gitlab-ci.yml | 1 +
> DEVELOPERS | 2 ++
> board/friendlyarm/nanopi-neo4/extlinux.conf | 4 +++
> board/friendlyarm/nanopi-neo4/genimage.cfg | 22
> board/friendlyarm/nanopi-neo4/post-build.sh | 9 +
> board/friendlyarm/nanopi-neo4/readme.txt| 53 +++
> configs/nanopi_neo4_defconfig | 55
> +
> 7 files changed, 146 insertions(+)
> create mode 100644 board/friendlyarm/nanopi-neo4/extlinux.conf
> create mode 100644 board/friendlyarm/nanopi-neo4/genimage.cfg
> create mode 100755 board/friendlyarm/nanopi-neo4/post-build.sh
> create mode 100644 board/friendlyarm/nanopi-neo4/readme.txt
> create mode 100644 configs/nanopi_neo4_defconfig
>
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index 5ed1b8f4d5..2f41bcf7c6 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -181,6 +181,7 @@ nanopi_m1_defconfig: { extends: .defconfig }
> nanopi_m1_plus_defconfig: { extends: .defconfig }
> nanopi_m4_defconfig: { extends: .defconfig }
> nanopi_neo_defconfig: { extends: .defconfig }
> +nanopi_neo4_defconfig: { extends: .defconfig }
> nexbox_a95x_defconfig: { extends: .defconfig }
> nitrogen6sx_defconfig: { extends: .defconfig }
> nitrogen6x_defconfig: { extends: .defconfig }
We don't have gitlab-ci setup in mainline, so this won't apply as-is. I
would however very much like to see what you have as I'd posted
elsewhere my gitlab-ci file that converts what we do in travis to
gitlab. 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] x86: SPI flash broken with SPI NOR
Hi Vignesh,
On Wed, Jun 5, 2019 at 9:40 PM Bin Meng wrote:
>
> Hi Vignesh,
>
> On Sat, Apr 27, 2019 at 12:26 AM Vignesh Raghavendra wrote:
> >
> > Bin,
> >
> > On 26/04/19 7:33 PM, Bin Meng wrote:
> > > Hi Simon,
> > >
> > > On Fri, Apr 26, 2019 at 7:26 AM Simon Glass wrote:
> > >>
> > >> Hi Bin,
> > >>
> > >> I find that 'sf test 0 1000' does not work anymore since this commit:
> > >>
> > >> c4e8862308 mtd: spi: Switch to new SPI NOR framework
> > >>
> > >> Have you seen any problems? This seems to prevent proper SPI flash
> > >> writing (not sure about reading).
> > >
> > > Yes, this seems to be broken. I just tested it on MinnowMax.
> > >
> >
> > What is the flash part on this board?
> >
> >
> > > 'sf probe' does not succeed anymore.
> > >
> >
> > Could you enable all debug prints in spi_mem_exec_op() in spi-mem.c:
> > https://elixir.bootlin.com/u-boot/latest/source/drivers/spi/spi-mem.c#L376
> >
> > And the post the full log here. If the log is too big please paste it to
> > pastebin.ubuntu.com
> >
> > Also please apply http://patchwork.ozlabs.org/patch/1090121/ on top of
> > latest tree before doing any write to flash
> >
> > Sorry for the trouble.
> >
>
> Sorry for the long delay. I finally got time to look into this.
>
> However with the latest u-boot/master, the SPI flash seems to work
> again on Intel MinnowMax. Did you recall anything changes in the
> spi-nor recently?
The thing I know is:
v2019.07-rc1: Intel ich-spi driver was broken
v2019.07-rc2: Intel ich-spi driver worked again
So I did a 'git bisect', although I used it in a reverse direction :)
This is the commit that makes the Intel ich-spi driver work again.
commit 60e2bf46784ebbd30ff29b3d3c7c97e56b11e86a
Author: Weijie Gao
Date: Fri Apr 26 17:22:19 2019 +0800
mtd: spi-nor: fix page program issue when using spi-mem driver
Some SPI controllers can't write nor->page_size bytes in a single step
because their TX FIFO is too small, but when that happens we should
make sure a WRITE_EN command before each write access and READ_SR command
after each write access is issued.
We should allow nor->write() to return a size that is smaller than the
requested write size to gracefully handle this case.
Also, the spi_nor_write_data() should return the actual number of bytes
that were written during the spi_mem_exec_op() operation.
This patch is a combination of two commits backported from kernel:
commit 630d6bd8a3b4 ("mtd: spi-nor: Support controllers with limit ...")
commit 3baa8ec88c2f ("mtd: devices: m25p80: Make sure WRITE_EN is ...")
Cc: Vignesh R
Signed-off-by: Weijie Gao
Acked-by: Vignesh R
Tested-by: Shyam Saini # microzed
Acked-by: Jagan Teki
Hi Simon,
Could you please confirm that on the Chromebook?
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] pci: Avoid assigning PCI resources that are below 0x1000
Hi Bin,
On 05.06.19 16:10, Bin Meng wrote:
Hi Stefan,
On Wed, Jun 5, 2019 at 9:53 PM Stefan Roese wrote:
On 05.06.19 15:07, Bin Meng wrote:
commit b7598a43f2b4 ("[PATCH] Avoid assigning PCI resources from
zero address") only moved the bus lower address to 0x1000 if the
given bus start address is zero. The comment said 0x1000 is a
reasonable starting value, hence we'd better apply the same
adjustment when the given bus start address is below 0x1000.
Signed-off-by: Bin Meng
---
drivers/pci/pci_auto_common.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci_auto_common.c b/drivers/pci/pci_auto_common.c
index 1837873..3ff42f2 100644
--- a/drivers/pci/pci_auto_common.c
+++ b/drivers/pci/pci_auto_common.c
@@ -21,9 +21,12 @@ void pciauto_region_init(struct pci_region *res)
/*
* Avoid allocating PCI resources from address 0 -- this is illegal
* according to PCI 2.1 and moreover, this is known to cause Linux IDE
- * drivers to fail. Use a reasonable starting value of 0x1000 instead.
+ * drivers to fail. Use a reasonable starting value of 0x1000 instead
+ * if the bus start address is below 0x1000.
*/
- res->bus_lower = res->bus_start ? res->bus_start : 0x1000;
+ if (res->bus_start < 0x1000)
+ res->bus_start = 0x1000;
+ res->bus_lower = res->bus_start;
}
void pciauto_region_align(struct pci_region *res, pci_size_t size)
Reviewed-by: Stefan Roese
Thanks for the review. I just re-considered it a little bit, and
thought that we should not change res->bus_start here, as the original
logic did not change too. I will send a v2.
Even better. I was a bit reluctant when I saw this change, but trusted
you to have thought it through. ;)
BTW: Where did you spot a problem with the current implementation?
What issue did hit you exactly?
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] pci: Avoid assigning PCI resources that are below 0x1000
commit b7598a43f2b4 ("[PATCH] Avoid assigning PCI resources from
zero address") only moved the bus lower address to 0x1000 if the
given bus start address is zero. The comment said 0x1000 is a
reasonable starting value, hence we'd better apply the same
adjustment when the given bus start address is below 0x1000.
Signed-off-by: Bin Meng
---
Changes in v2:
- avoid changing res->bus_start
drivers/pci/pci_auto_common.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci_auto_common.c b/drivers/pci/pci_auto_common.c
index 1837873..84908e6 100644
--- a/drivers/pci/pci_auto_common.c
+++ b/drivers/pci/pci_auto_common.c
@@ -21,9 +21,10 @@ void pciauto_region_init(struct pci_region *res)
/*
* Avoid allocating PCI resources from address 0 -- this is illegal
* according to PCI 2.1 and moreover, this is known to cause Linux IDE
-* drivers to fail. Use a reasonable starting value of 0x1000 instead.
+* drivers to fail. Use a reasonable starting value of 0x1000 instead
+* if the bus start address is below 0x1000.
*/
- res->bus_lower = res->bus_start ? res->bus_start : 0x1000;
+ res->bus_lower = res->bus_start < 0x1000 ? 0x1000 : res->bus_start;
}
void pciauto_region_align(struct pci_region *res, pci_size_t size)
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-riscv/master
On Wed, Jun 05, 2019 at 06:27:38PM +0800, ub...@andestech.com wrote: > Hi Tom, > > Please pull some riscv updates: > > - Support Microchip MPFS Icicle board. > - Enable e1000 and nvme support for qemu. > - Enable PCI host ECAM generic driver for qemu. > - Increase the environment size to 128kB for qemu. > > https://travis-ci.org/rickchen36/u-boot-riscv/builds/541565696 > > Thanks > Rick > > > The following changes since commit 38c2a8a00132b4dcc6a0bb5baf5146b9eb9eb2d2: > > Merge tag 'efi-2019-07-rc4' of git://git.denx.de/u-boot-efi (2019-06-02 > 18:19:45 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-riscv.git > > for you to fetch changes up to 39494822e3a639c8b5d60538d1dcae17bcf3c5f6: > > riscv: Add Microchip MPFS Icicle board support (2019-06-05 13:19:24 +0800) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-marvell/master
On Tue, Jun 04, 2019 at 08:39:58AM +0200, Stefan Roese wrote: > Hi Tom, > > please pull the following Marvell related fix: > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] pci: Avoid assigning PCI resources that are below 0x1000
Hi Stefan,
On Wed, Jun 5, 2019 at 9:53 PM Stefan Roese wrote:
>
> On 05.06.19 15:07, Bin Meng wrote:
> > commit b7598a43f2b4 ("[PATCH] Avoid assigning PCI resources from
> > zero address") only moved the bus lower address to 0x1000 if the
> > given bus start address is zero. The comment said 0x1000 is a
> > reasonable starting value, hence we'd better apply the same
> > adjustment when the given bus start address is below 0x1000.
> >
> > Signed-off-by: Bin Meng
> > ---
> >
> > drivers/pci/pci_auto_common.c | 7 +--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/pci_auto_common.c b/drivers/pci/pci_auto_common.c
> > index 1837873..3ff42f2 100644
> > --- a/drivers/pci/pci_auto_common.c
> > +++ b/drivers/pci/pci_auto_common.c
> > @@ -21,9 +21,12 @@ void pciauto_region_init(struct pci_region *res)
> > /*
> >* Avoid allocating PCI resources from address 0 -- this is illegal
> >* according to PCI 2.1 and moreover, this is known to cause Linux IDE
> > - * drivers to fail. Use a reasonable starting value of 0x1000 instead.
> > + * drivers to fail. Use a reasonable starting value of 0x1000 instead
> > + * if the bus start address is below 0x1000.
> >*/
> > - res->bus_lower = res->bus_start ? res->bus_start : 0x1000;
> > + if (res->bus_start < 0x1000)
> > + res->bus_start = 0x1000;
> > + res->bus_lower = res->bus_start;
> > }
> >
> > void pciauto_region_align(struct pci_region *res, pci_size_t size)
> >
>
> Reviewed-by: Stefan Roese
>
Thanks for the review. I just re-considered it a little bit, and
thought that we should not change res->bus_start here, as the original
logic did not change too. I will send a v2.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] RSA in U-Boot
On Wed, Jun 05, 2019 at 02:27:32PM +0900, AKASHI Takahiro wrote: > Tom, Wolfgang, > > On Wed, May 22, 2019 at 02:48:42PM +0900, AKASHI Takahiro wrote: > > Wolfgang, > > > > Thank you for your comments. > > > > On Fri, May 17, 2019 at 10:47:56AM +0200, Wolfgang Denk wrote: > > > Dear Akashi Takahiro, > > > > > > In message <20190517001206.gx11...@linaro.org> you wrote: > > > > > > > > > Who: usually the responsible custodians > > > > > > > > "Custodians" don't always mean sub-system maintainers. Right? > > > > > > It's just a different name for the same thing. > > > > Okay. > > > > > > In fact, I have already imported relevant kernel code into U-Boot > > > > and it now works perfectly with my experimental UEFI secure boot patch, > > > > but see the total size (and numbers) of files imported is quite big. > > > > I wonder who is willing to maintain them: > > > ... > > > > 37 files changed, 6409 insertions(+), 11 deletions(-) > > > > > > Well, if you compare for example against libressl-portable , then > > > this git repository has 180 files with more than 20,000 lines. > > > > I think that there are two different approaches in using > > external code (library). > > 1.import necessary source files into U-Boot repository, customize them > > and build them with the rest of U-Boot > > 2.build it as a static library, either totally outside of U-Boot > > or as a git submodule, and link it, i.e. only needed binary blobs, > > to U-Boot. > > (I don't know any existing libraries like this in U-Boot though.) > > > > We can adopt only (1) for kernel code, but *in general* (2) as well > > for a library. That way, we may potentially save/minimize our own > > maintenance cost, again *in general.* > > > > Those said, it seems to me that, gnutls, for instance, is not well > > optimized for smaller (or purpose-specific) systems. For example, > > _wrap_nettle_pk_verify(), public key verification function, supports > > not only RSA, but also DSA, ECDSA and so on with no "opt-out" options > > while UEFI secure boot only needs and supports RSA. > > > > > We are adding a lot of functionality, and anyone who wants to use > > > this will have to pay the price. But this is what I mentioned > > > before: I think the kernel code has already been tweaked with an > > > eye on resource consumption, while standard public libraries have > > > not. > > > > I'm not very sure about your last statement above, but as far as > > the customisability is concerned some libraries may have an issue > > in (2) as I mentioned above. > > > > In this sense, I still want to seek a possibility of using other > > smaller libraries, like mbedTLS. > > (mbedTLS has another issue, lacking pkcs7 parser.) > > > > > The kernel code may be big, but I would be surprised if there are > > > smaller and leaner alternatives with similar quality? > > > > > > As for who is willing to maintain it: I have no idea. Usually it > > > turns out to be the original implementoer / who pushed the code > > > upstream into U-Boot. > > > > Okay, but for most of examples you mentioned as linux-origin code, > > there are no explicit maintainers. Right? > > Do you have any further comments regarding maintainability? > (The *quality*, or trustworthiness, of the original code is > an orthogonal issue.) No, I see it as a rather settled point that we leverage the linux kernel code as much as possible, when possible, as a rule of thumb even for the project. -- 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] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
On 6/5/19 3:52 PM, Tom Rini wrote: > On Wed, Jun 05, 2019 at 03:24:40PM +0200, Marek Vasut wrote: >> On 6/5/19 5:03 AM, Peng Fan wrote: >> [...] >>> It is not duplication of FIT. Container support the similar function >>> of FIT image, but it is not only that. >> >> So what is it ? > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > nxp.com%2Fdocs%2Fen%2Freference-manual%2FIMX8DQXPRM.pdfda ta=02%7C > 01%7Cpeng.fan%40nxp.com%7C72216052f4234a93ad1f08d6e95ed782%7C6 86ea1d3b > c2b4c6fa92cd99c5c301635%7C0%7C1%7C636952990895125305sdat a=KO%2B0e > E3v%2FkHuJ%2BhR7mBgc4NWXxbMUupfubXXu%2BueIWo%3Dreserv ed=0 > Chapter 5 has information about container set and container. Thanks, any specific part of those 80 pages ? >>> >>> Figure 5-24. Container Format has a picture about a single container. >>> i.MX8 container also support container sets, support encrypt blob, >>> certificates, SRK management. Support signature to the whole container, >>> no need single image inside container. >> >> Isn't that all supported in fitImage too ? > > This is neither the first nor last time functionality has been > essentially duplicated, sadly, for reasons. > >> I don't think I get it. Why would I, as an iMX8 user, want to pick >> custom new vendor-specific format over years-proven generic fitImage? > > We not against FIT, we already use FIT on i.MX8M, to let spl to > authenticate FIT image using ROM HAB, not using crypto driver. Great >> What is the selling point here ? > > We would not introduce cypto driver in SPL stage, that means HAB FIT > and AHAB container needs to be dropped when SPL loading other images. > ROM already provides API for bootloader to authenticate images, > introducing complex crypto driver in SPL could enlarge code size and > make things complicated. Ah I see, so it's all making the whole crypto simpler by offloading the hard parts into the firmware, which just magically handles everything , without having much extra code in the SPL ? >>> >>> Yes. Use what ROM provides will make things easier for U-Boot. >> >> Is it possible to perform a security audit on the ROM as easily as on >> U-Boot ? I mean, U-Boot is free software, the source is available, so >> security researchers can easily scrutinize it. Is the ROM ? > > So, here's my two cents (and it may or may not seem contradictory with > my opinions in the secure boot thread going on currently on the Linaro > Boot Architecture list). Yes, it would and IMHO is better when we use > free and open software to solve our problems (and an aside to the RISC-V > folks as this is yet another area they can make the world a better place > in). But I am a believe in dealing with the world as it stands at times > too. The question isn't "can we get NXP to re-spin i.MX8 to use the FIT > image format?" as that's obviously going to be "No.". The question is, > "can we support this format in a clean manner?" and the answer is > obviously "Yes.". So please lets keep that in mind with reviewing the > code as at the end of the day it is more beneficial for this to be > supported in mainline U-Boot than only supported in the vendor tree. I agree with this. I would still like to have an open alternative available though. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC 5/6] ARM: dts: colibri_imx7: Add lcdif node
Hi Fabio,
On Wed, Jun 5, 2019 at 4:29 PM Igor Opaniuk wrote:
>
> Hi Fabio,
>
> On Wed, Jun 5, 2019 at 1:06 AM Fabio Estevam wrote:
> >
> > Hi Igor,
> >
> > On Mon, Jun 3, 2019 at 6:06 PM Igor Opaniuk wrote:
> >
> > > + {
> > > + u-boot,dm-pre-reloc;
> > > + status = "okay";
> > > +
> > > + display-timings {
> > > + native-mode = <_vga>;
> > > +
> > > + /* Standard VGA timing */
> > > + timing_vga: 640x480 {
> > > + u-boot,dm-pre-reloc;
> > > + clock-frequency = <25175000>;
> > > + hactive = <640>;
> > > + vactive = <480>;
> > > + hback-porch = <48>;
> > > + hfront-porch = <16>;
> > > + vback-porch = <33>;
> > > + vfront-porch = <10>;
> > > + hsync-len = <96>;
> > > + vsync-len = <2>;
> > > +
> > > + de-active = <1>;
> > > + hsync-active = <0>;
> > > + vsync-active = <0>;
> > > + pixelclk-active = <0>
> >
> > This is the deprecated style mxsfb fbdev binding.
> >
> > In the kernel we no longer use this style as documented in
> > Documentation/devicetree/bindings/display/mxsfb.txt
> >
> > If we follow this route in U-Boot then we will diverge from the kernel
> > recommended bindings.
>
> Initially I copy-pasted the whole DT node "as it is" from the linux
> kernel dts, but found out that existing
> DT wrapper for parsing display timings
> (ofnode_decode_display_timing())) isn't able to parse it properly,
> so I just changed it to conform the same structure as similar nodes in
> other DTS files.
>
> Thanks for letting me know, probably ofnode_decode_display_timing()
> implementation should
> be adjusted as well.
Nevermind, I've double-checked ofnode_decode_display_timing()
implementation and all instances of display-timings nodes,
it definitely should be able parse the same structure as defined in
the Linux devicetree bindings.
Probably I just messed up with something.
> Regards,
> Igor
>
>
>
> --
> Best regards - Freundliche Grüsse - Meilleures salutations
>
> Igor Opaniuk
>
> mailto: igor.opan...@gmail.com
> skype: igor.opanyuk
> +380 (93) 836 40 67
> http://ua.linkedin.com/in/iopaniuk
--
Best regards - Freundliche Grüsse - Meilleures salutations
Igor Opaniuk
mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] pci: Avoid assigning PCI resources that are below 0x1000
On 05.06.19 15:07, Bin Meng wrote:
commit b7598a43f2b4 ("[PATCH] Avoid assigning PCI resources from
zero address") only moved the bus lower address to 0x1000 if the
given bus start address is zero. The comment said 0x1000 is a
reasonable starting value, hence we'd better apply the same
adjustment when the given bus start address is below 0x1000.
Signed-off-by: Bin Meng
---
drivers/pci/pci_auto_common.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci_auto_common.c b/drivers/pci/pci_auto_common.c
index 1837873..3ff42f2 100644
--- a/drivers/pci/pci_auto_common.c
+++ b/drivers/pci/pci_auto_common.c
@@ -21,9 +21,12 @@ void pciauto_region_init(struct pci_region *res)
/*
* Avoid allocating PCI resources from address 0 -- this is illegal
* according to PCI 2.1 and moreover, this is known to cause Linux IDE
-* drivers to fail. Use a reasonable starting value of 0x1000 instead.
+* drivers to fail. Use a reasonable starting value of 0x1000 instead
+* if the bus start address is below 0x1000.
*/
- res->bus_lower = res->bus_start ? res->bus_start : 0x1000;
+ if (res->bus_start < 0x1000)
+ res->bus_start = 0x1000;
+ res->bus_lower = res->bus_start;
}
void pciauto_region_align(struct pci_region *res, pci_size_t size)
Reviewed-by: Stefan Roese
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
On Wed, Jun 05, 2019 at 03:24:40PM +0200, Marek Vasut wrote: > On 6/5/19 5:03 AM, Peng Fan wrote: > [...] > > It is not duplication of FIT. Container support the similar function > > of FIT image, but it is not only that. > > So what is it ? > >>> > >>> > >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > >>> > >> nxp.com%2Fdocs%2Fen%2Freference-manual%2FIMX8DQXPRM.pdfda > >> ta=02%7C > >>> > >> 01%7Cpeng.fan%40nxp.com%7C72216052f4234a93ad1f08d6e95ed782%7C6 > >> 86ea1d3b > >>> > >> c2b4c6fa92cd99c5c301635%7C0%7C1%7C636952990895125305sdat > >> a=KO%2B0e > >>> > >> E3v%2FkHuJ%2BhR7mBgc4NWXxbMUupfubXXu%2BueIWo%3Dreserv > >> ed=0 > >>> Chapter 5 has information about container set and container. > >> > >> Thanks, any specific part of those 80 pages ? > > > > Figure 5-24. Container Format has a picture about a single container. > > i.MX8 container also support container sets, support encrypt blob, > > certificates, SRK management. Support signature to the whole container, > > no need single image inside container. > > Isn't that all supported in fitImage too ? This is neither the first nor last time functionality has been essentially duplicated, sadly, for reasons. > I don't think I get it. Why would I, as an iMX8 user, want to pick > custom new vendor-specific format over years-proven generic fitImage? > >>> > >>> We not against FIT, we already use FIT on i.MX8M, to let spl to > >>> authenticate FIT image using ROM HAB, not using crypto driver. > >> > >> Great > >> > What is the selling point here ? > >>> > >>> We would not introduce cypto driver in SPL stage, that means HAB FIT > >>> and AHAB container needs to be dropped when SPL loading other images. > >>> ROM already provides API for bootloader to authenticate images, > >>> introducing complex crypto driver in SPL could enlarge code size and > >>> make things complicated. > >> > >> Ah I see, so it's all making the whole crypto simpler by offloading the > >> hard > >> parts into the firmware, which just magically handles everything , without > >> having much extra code in the SPL ? > > > > Yes. Use what ROM provides will make things easier for U-Boot. > > Is it possible to perform a security audit on the ROM as easily as on > U-Boot ? I mean, U-Boot is free software, the source is available, so > security researchers can easily scrutinize it. Is the ROM ? So, here's my two cents (and it may or may not seem contradictory with my opinions in the secure boot thread going on currently on the Linaro Boot Architecture list). Yes, it would and IMHO is better when we use free and open software to solve our problems (and an aside to the RISC-V folks as this is yet another area they can make the world a better place in). But I am a believe in dealing with the world as it stands at times too. The question isn't "can we get NXP to re-spin i.MX8 to use the FIT image format?" as that's obviously going to be "No.". The question is, "can we support this format in a clean manner?" and the answer is obviously "Yes.". So please lets keep that in mind with reviewing the code as at the end of the day it is more beneficial for this to be supported in mainline U-Boot than only supported in the vendor tree. 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] [PATCH] imx: Select the pinctrl drivers when DM is used
Hi Fabio,
> On Fri, 24 May 2019 09:50:53 -0300
> Fabio Estevam wrote:
>
> > When using device model it is required to select the pinctrl
> > drivers so that the pins can be properly configured via
> > devicetree.
> >
> > mx6sabreauto board is an example of a target that uses DM and does
> > not select the pinctrl drivers.
> >
> > Instead of doing the pinctrl driver selection in each individual
> > defconfig file, select it at SoC level when DM is used.
> >
> > Signed-off-by: Fabio Estevam
> > ---
> > arch/arm/Kconfig | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index efb9aab390..4c361c9a1d 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -787,6 +787,8 @@ config ARCH_MX31
> > config ARCH_MX7ULP
> > bool "NXP MX7ULP"
> > select CPU_V7A
> > + select PINCTRL if DM
> > + select PINCTRL_IMX7ULP if DM
> > select ROM_UNIFIED_SECTIONS
> > imply MXC_GPIO
> >
> > @@ -795,6 +797,8 @@ config ARCH_MX7
> > select ARCH_MISC_INIT
> > select BOARD_EARLY_INIT_F
> > select CPU_V7A
> > + select PINCTRL if DM
> > + select PINCTRL_IMX7 if DM
> > select SYS_FSL_HAS_SEC if SECURE_BOOT
> > select SYS_FSL_SEC_COMPAT_4
> > select SYS_FSL_SEC_LE
> > @@ -803,6 +807,8 @@ config ARCH_MX7
> > config ARCH_MX6
> > bool "Freescale MX6"
> > select CPU_V7A
> > + select PINCTRL if DM
> > + select PINCTRL_IMX6 if DM
> > select SYS_FSL_HAS_SEC if SECURE_BOOT
> > select SYS_FSL_SEC_COMPAT_4
> > select SYS_FSL_SEC_LE
> > @@ -818,6 +824,8 @@ config ARCH_MX5
> > bool "Freescale MX5"
> > select BOARD_EARLY_INIT_F
> > select CPU_V7A
> > + select PINCTRL if DM
> > + select PINCTRL_IMX5 if DM
> > imply MXC_GPIO
> >
> > config ARCH_OWL
>
> Reviewed-by: Lukasz Majewski
>
Unfortunately, after some testing it turned out that this patch causes
build break for "display5_factory_defconfig"
The build break is as follows:
WARNING: unmet direct dependencies detected for PINCTRL_IMX6
Depends on [n]: ARCH_MX6 [=y] && PINCTRL_FULL [=n]
Selected by [y]:
- ARCH_MX6 [=y] && && DM [=y]
WARNING: unmet direct dependencies detected for PINCTRL_IMX6
Depends on [n]: ARCH_MX6 [=y] && PINCTRL_FULL [=n]
Selected by [y]:
- ARCH_MX6 [=y] && && DM [=y]
../drivers/pinctrl/nxp/pinctrl-imx6.c:32:32:
warning: ?imx6_pinctrl_match? defined but not used
[-Wunused-const-variable=] static const struct udevice_id
imx6_pinctrl_match[] = { ^~ drivers/built-in.o: In
function `imx6_pinctrl_probe':
build/../drivers/pinctrl/nxp/pinctrl-imx6.c:29: undefined reference to
`imx_pinctrl_probe'
drivers/built-in.o:(.u_boot_list_2_driver_2_imx6_pinctrl+0x14):
undefined reference to `imx_pinctrl_remove'
drivers/built-in.o:(.u_boot_list_2_driver_2_imx6_pinctrl+0x3c):
undefined reference to `imx_pinctrl_ops' arm-linux-gnueabihf-ld.bfd:
BFD (Linaro_Binutils-2017.05) 2.27.0.20161019 assertion
fail
/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-linux-gnueabihf/snapshots/binutils-gdb.git~linaro-local~linaro_binutils-2_27-branch/bfd/elf32-arm.c:8784
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> lu...@denx.de
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpHaAFZZiXCG.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] sf probe failed on Intel DNV-NS platform
Hi Hilbert, On Tue, Jun 4, 2019 at 7:18 PM Hilbert Tu(杜睿哲_Pegatron) wrote: > > Hi, > > I got following error message when using U-Boot as payload of Coreboot on > Intel DNV-NS platform. I am checking if my dts file was incorrect configured > for SPI flash device. Can anyone help? Thanks. > Errors: > Invalid bus 0 (err=-19) > Failed to initialize SPI flash at 0:0 (error -19) Which U-Boot version is this? Could you retest with latest u-boot/master? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] x86: SPI flash broken with SPI NOR
Hi Vignesh, On Sat, Apr 27, 2019 at 12:26 AM Vignesh Raghavendra wrote: > > Bin, > > On 26/04/19 7:33 PM, Bin Meng wrote: > > Hi Simon, > > > > On Fri, Apr 26, 2019 at 7:26 AM Simon Glass wrote: > >> > >> Hi Bin, > >> > >> I find that 'sf test 0 1000' does not work anymore since this commit: > >> > >> c4e8862308 mtd: spi: Switch to new SPI NOR framework > >> > >> Have you seen any problems? This seems to prevent proper SPI flash writing > >> (not sure about reading). > > > > Yes, this seems to be broken. I just tested it on MinnowMax. > > > > What is the flash part on this board? > > > > 'sf probe' does not succeed anymore. > > > > Could you enable all debug prints in spi_mem_exec_op() in spi-mem.c: > https://elixir.bootlin.com/u-boot/latest/source/drivers/spi/spi-mem.c#L376 > > And the post the full log here. If the log is too big please paste it to > pastebin.ubuntu.com > > Also please apply http://patchwork.ozlabs.org/patch/1090121/ on top of latest > tree before doing any write to flash > > Sorry for the trouble. > Sorry for the long delay. I finally got time to look into this. However with the latest u-boot/master, the SPI flash seems to work again on Intel MinnowMax. Did you recall anything changes in the spi-nor recently? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC 5/6] ARM: dts: colibri_imx7: Add lcdif node
Hi Fabio,
On Wed, Jun 5, 2019 at 1:06 AM Fabio Estevam wrote:
>
> Hi Igor,
>
> On Mon, Jun 3, 2019 at 6:06 PM Igor Opaniuk wrote:
>
> > + {
> > + u-boot,dm-pre-reloc;
> > + status = "okay";
> > +
> > + display-timings {
> > + native-mode = <_vga>;
> > +
> > + /* Standard VGA timing */
> > + timing_vga: 640x480 {
> > + u-boot,dm-pre-reloc;
> > + clock-frequency = <25175000>;
> > + hactive = <640>;
> > + vactive = <480>;
> > + hback-porch = <48>;
> > + hfront-porch = <16>;
> > + vback-porch = <33>;
> > + vfront-porch = <10>;
> > + hsync-len = <96>;
> > + vsync-len = <2>;
> > +
> > + de-active = <1>;
> > + hsync-active = <0>;
> > + vsync-active = <0>;
> > + pixelclk-active = <0>
>
> This is the deprecated style mxsfb fbdev binding.
>
> In the kernel we no longer use this style as documented in
> Documentation/devicetree/bindings/display/mxsfb.txt
>
> If we follow this route in U-Boot then we will diverge from the kernel
> recommended bindings.
Initially I copy-pasted the whole DT node "as it is" from the linux
kernel dts, but found out that existing
DT wrapper for parsing display timings
(ofnode_decode_display_timing())) isn't able to parse it properly,
so I just changed it to conform the same structure as similar nodes in
other DTS files.
Thanks for letting me know, probably ofnode_decode_display_timing()
implementation should
be adjusted as well.
Regards,
Igor
--
Best regards - Freundliche Grüsse - Meilleures salutations
Igor Opaniuk
mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
On 6/5/19 5:03 AM, Peng Fan wrote: [...] > It is not duplication of FIT. Container support the similar function > of FIT image, but it is not only that. So what is it ? >>> >>> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. >>> >> nxp.com%2Fdocs%2Fen%2Freference-manual%2FIMX8DQXPRM.pdfda >> ta=02%7C >>> >> 01%7Cpeng.fan%40nxp.com%7C72216052f4234a93ad1f08d6e95ed782%7C6 >> 86ea1d3b >>> >> c2b4c6fa92cd99c5c301635%7C0%7C1%7C636952990895125305sdat >> a=KO%2B0e >>> >> E3v%2FkHuJ%2BhR7mBgc4NWXxbMUupfubXXu%2BueIWo%3Dreserv >> ed=0 >>> Chapter 5 has information about container set and container. >> >> Thanks, any specific part of those 80 pages ? > > Figure 5-24. Container Format has a picture about a single container. > i.MX8 container also support container sets, support encrypt blob, > certificates, SRK management. Support signature to the whole container, > no need single image inside container. Isn't that all supported in fitImage too ? >> I don't think I get it. Why would I, as an iMX8 user, want to pick custom new vendor-specific format over years-proven generic fitImage? >>> >>> We not against FIT, we already use FIT on i.MX8M, to let spl to >>> authenticate FIT image using ROM HAB, not using crypto driver. >> >> Great >> What is the selling point here ? >>> >>> We would not introduce cypto driver in SPL stage, that means HAB FIT >>> and AHAB container needs to be dropped when SPL loading other images. >>> ROM already provides API for bootloader to authenticate images, >>> introducing complex crypto driver in SPL could enlarge code size and >>> make things complicated. >> >> Ah I see, so it's all making the whole crypto simpler by offloading the hard >> parts into the firmware, which just magically handles everything , without >> having much extra code in the SPL ? > > Yes. Use what ROM provides will make things easier for U-Boot. Is it possible to perform a security audit on the ROM as easily as on U-Boot ? I mean, U-Boot is free software, the source is available, so security researchers can easily scrutinize it. Is the ROM ? -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] pci: Avoid assigning PCI resources that are below 0x1000
commit b7598a43f2b4 ("[PATCH] Avoid assigning PCI resources from
zero address") only moved the bus lower address to 0x1000 if the
given bus start address is zero. The comment said 0x1000 is a
reasonable starting value, hence we'd better apply the same
adjustment when the given bus start address is below 0x1000.
Signed-off-by: Bin Meng
---
drivers/pci/pci_auto_common.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci_auto_common.c b/drivers/pci/pci_auto_common.c
index 1837873..3ff42f2 100644
--- a/drivers/pci/pci_auto_common.c
+++ b/drivers/pci/pci_auto_common.c
@@ -21,9 +21,12 @@ void pciauto_region_init(struct pci_region *res)
/*
* Avoid allocating PCI resources from address 0 -- this is illegal
* according to PCI 2.1 and moreover, this is known to cause Linux IDE
-* drivers to fail. Use a reasonable starting value of 0x1000 instead.
+* drivers to fail. Use a reasonable starting value of 0x1000 instead
+* if the bus start address is below 0x1000.
*/
- res->bus_lower = res->bus_start ? res->bus_start : 0x1000;
+ if (res->bus_start < 0x1000)
+ res->bus_start = 0x1000;
+ res->bus_lower = res->bus_start;
}
void pciauto_region_align(struct pci_region *res, pci_size_t size)
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] usb: gadget: f_sdp: Allow SPL to load and boot FIT via SDP
On Wed, Jun 5, 2019 at 4:25 AM Sjoerd Simons wrote: > Sorry closing the device would be the right jargon for i.mx. My point > really is, isn't it something to be fixed in imx_usb_loader if it can't > upload unsigned FIT images rather then in u-boot? Yes, I think imx_usb_loader needs to be fixed to load FIT images. However, since the current FIT format for i.MX6 does not contain an IVT, this would cause issues when running secure boot. So in my opinion if we could change the i.MX6 FIT format to also add an IVT, then I think we could fix the imx_usb_loader and secure boot issues. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/9] miscellaneous ubispl and ubi improvements
Hello Heiko On Wed, May 15, 2019 at 03:15:51PM +0200, Markus Klotzbuecher wrote: >From: Markus Klotzbuecher > >This series contains a couple of UBI and UBI SPL improvements, notably >a ubispl extension to allow loading volumes by name. The motivation is >to use the UBI atomic volume rename functionality to allow double copy >software updates of U-Boot on UBI. To do that we configured the SPL to >always load the same volume name (e.g. "u-boot"), and the software >updater always installs into the secondary volume "u-boot_r". After a >successful upgrade, these two volume names are switched. > >This extension is protected by #ifdefs as it will somewhat slow down >loading of volumes by id. This is because the code needs to disable >the optimization of ignoring all volume ids which are not >to-be-loaded, since these can only be resolved after attaching. > >We have tested both with and without fastmap enabled and both paths >seems to work reliably. > >As per Heikos request, this v2 adds two patches that migrate the >omap2plus and at91 CONFIG_ENV_* to defconfigs and likewise for the two >boards using ubispl. The first migration was supported by an extension >to the moveconfig script (patch 1) to expand simple expressions. Both >migrations were tested to be binary equal before and after the change. > >Changes v2: >- Add a patch (1) for moveconfig to expand simple expressions >- Add patch (3) to move at91 and omap2plus CONFIG_ENV_ to defconfigs >- Add patch (7) to migrate boards using ubispl to KConfig >- Add missing commit messages >- Indicate version of kernel code which was used in ubispl I don't mean to bug, just wanted to ask if there's anything missing for this v2 series... Thanks, Markus -- Markus Klotzbuecher Freelancer Embedded, Distributed & Real-time Am See 28, 78465 Konstanz, Germany ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC 0/6] efi_loader: support runtime variable access via cache
On 6/5/19 6:21 AM, AKASHI Takahiro wrote: > EBBR v1.0 section 2.5.3 says > Even when SetVariable() is not supported during runtime services, > firmware should cache variable names and values in EfiRuntimeServicesData > memory so that GetVariable() and GetNextVeriableName() can behave as > specified. > > This is an experimental patch set and the aim is to enable this feature. Hello Takahiro, thanks a lot for all the effort you put in this. Reusing parts of env is a valid possibility but I am not sure if this is the right approach for something that has to work at runtime. I will need some time to layout my ideas of the design. Unfortunately I am on a sea kayaking trip this weekend. So I may need until June 16th for a thorough suggestion. I have already picked the trivial patches from this patch series and will put them into the next pull request. http://git.denx.de/?p=u-boot-efi.git;a=shortlog;h=refs/tags/efi-2019-07-rc4-2 Best regards Heinich > > Cache buffer is in the same format as U-Boot environment hash table, > but we cannot use functions in hashtable.c partly because most of U-Boot > code are not available at UEFI runtime and partly because entries in > a table are allocated by malloc(), which are again not available > at UEFI runtime. It is quite painful to modify exiting U-Boot code > so as to make it executable at UEFI runtime. > > So I implemented a limited version of hsearch_r(). This may be > a discussion. Given that there are not so many UEFI variables, > we may want to use a simpler table format for caching. > > Known issues: > * Currently I test this feature with a test which is temporarily embedded > in ExitBootServices. > * After SetVirtualAddressMap, it won't work (TODO). > ConvertPointer was implemented here just for this future work. > * So how can we test the feature? > We can't use "printenv" command as its relocation won't take place. > * I see some Travis CI errors. > This is probably due to no storage configured for UEFI variables. > > Patch#1 to #4 are preparatory patches. > Patch#5 is mainly for testing. > Patch#6 is core part of this patch set. > > AKASHI Takahiro (5): > efi_loader: runtime: make SetVirtualAddressMap configurable > efi: add RuntimeServicesSupported variable > efi_loader: support convert_pointer at runtime > cmd: efidebug: add "boot exit" sub-command > efi_loader: variable: support runtime variable access via cache > > Alexander Graf (1): > efi_loader: Patch non-runtime code out at ExitBootServices already > > cmd/efidebug.c | 63 > include/efi_api.h | 15 + > include/efi_loader.h | 22 ++ > lib/efi_loader/Kconfig | 24 ++ > lib/efi_loader/efi_boottime.c | 11 +- > lib/efi_loader/efi_runtime.c | 155 -- > lib/efi_loader/efi_setup.c | 5 + > lib/efi_loader/efi_variable.c | 467 + > test/py/tests/test_efi_selftest.py | 4 +- > 9 files changed, 735 insertions(+), 31 deletions(-) > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Pull request: u-boot-riscv/master
Hi Tom, Please pull some riscv updates: - Support Microchip MPFS Icicle board. - Enable e1000 and nvme support for qemu. - Enable PCI host ECAM generic driver for qemu. - Increase the environment size to 128kB for qemu. https://travis-ci.org/rickchen36/u-boot-riscv/builds/541565696 Thanks Rick The following changes since commit 38c2a8a00132b4dcc6a0bb5baf5146b9eb9eb2d2: Merge tag 'efi-2019-07-rc4' of git://git.denx.de/u-boot-efi (2019-06-02 18:19:45 -0400) are available in the Git repository at: git://git.denx.de/u-boot-riscv.git for you to fetch changes up to 39494822e3a639c8b5d60538d1dcae17bcf3c5f6: riscv: Add Microchip MPFS Icicle board support (2019-06-05 13:19:24 +0800) Bin Meng (2): riscv: qemu: Enable PCI host ECAM generic driver riscv: qemu: Enable e1000 and nvme support Karsten Merker (1): riscv: increase the environment size for the qemu-riscv platform to 128kB Padmarao Begari (1): riscv: Add Microchip MPFS Icicle board support arch/riscv/Kconfig| 4 board/emulation/qemu-riscv/Kconfig| 6 ++ board/microchip/mpfs_icicle/Kconfig | 26 ++ board/microchip/mpfs_icicle/MAINTAINERS | 7 +++ board/microchip/mpfs_icicle/Makefile | 7 +++ board/microchip/mpfs_icicle/mpfs_icicle.c | 30 ++ configs/microchip_mpfs_icicle_defconfig | 8 include/configs/microchip_mpfs_icicle.h | 63 +++ include/configs/qemu-riscv.h | 2 +- 9 files changed, 152 insertions(+), 1 deletion(-) create mode 100644 board/microchip/mpfs_icicle/Kconfig create mode 100644 board/microchip/mpfs_icicle/MAINTAINERS create mode 100644 board/microchip/mpfs_icicle/Makefile create mode 100644 board/microchip/mpfs_icicle/mpfs_icicle.c create mode 100644 configs/microchip_mpfs_icicle_defconfig create mode 100644 include/configs/microchip_mpfs_icicle.h ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Uboot send pull request
Hi Tom
Please drop this mail.
It is wrong mail sending
Sorry about it.
B.R
Rick
> From: Open Source Project uboot
> Sent: Wednesday, June 05, 2019 6:21 PM
> To: tr...@konsulko.com; u-boot@lists.denx.de; Open Source Project uboot; Rick
> Jian-Zhi Chen(陳建志)
> Subject: Uboot send pull request
>
> Hi Tom,
>
> Please pull some riscv update:
> 1. Add DM drivers to support RISC-V CPU and timer, plus some bug fixes.
> 2. Support SiFive UART
> 3. Rename ax25-ae350 defconfig
>
> https://travis-ci.org/rickchen36/u-boot-riscv/builds/469364551
>
> Thanks
>
> Rick
>
>
> The following changes since commit 1f2e948d6d53f77a2ddb2dde3531b0d5bc2815ad:
>
> Prepare v2019.01-rc2 (2018-12-17 20:25:24 -0500)
>
> are available in the Git repository at:
>
> git://git.denx.de/u-boot-riscv.git
>
> for you to fetch changes up to 368ff57805b03bebf99e97e703ce07aec721bc71:
>
> doc: README.ae350: Sync for ax25-ae350 rename (2018-12-18 13:26:02 +0800)
>
>
> Anup Patel (4):
> riscv: Introduce a Kconfig option for machine mode
> riscv: Implement riscv_get_time() API using rdtime instruction
> drivers: serial: Add SiFive UART driver
> riscv: qemu: Imply SIFIVE_SERIAL for emulation
>
> Bin Meng (22):
> dm: cpu: Add timebase frequency to the platdata
> riscv: qemu: Create a simple-bus driver for the soc node
> cpu: Add a RISC-V CPU driver
> timer: Add generic driver for RISC-V privileged architecture defined
> timer
> riscv: ax25: Hide the ax25-specific Kconfig option
> riscv: Add a SYSCON driver for SiFive's Core Local Interruptor
> riscv: qemu: Add platform-specific Kconfig options
> riscv: Enlarge the default SYS_MALLOC_F_LEN
> riscv: Probe cpus during boot
> riscv: Remove non-DM version of print_cpuinfo()
> riscv: Add CSR numbers
> riscv: Add exception codes for xcause register
> riscv: Update supports_extension() to use desc from cpu driver
> riscv: Add indirect stringification to csr_xxx ops
> riscv: Do some basic architecture level cpu initialization
> riscv: Move trap handler codes to mtrap.S
> riscv: Fix context restore before returning from trap handler
> riscv: Return to previous privilege level after trap handling
> riscv: Adjust the _exit_trap() position to come before handle_trap()
> riscv: Save boot hart id to the global data
> riscv: bootm: Change to use boot_hart from global data
> riscv: Remove ae350.dts
>
> Lukas Auer (1):
> riscv: add Kconfig entries for the code model
>
> Rick Chen (2):
> riscv: configs: Rename ax25-ae350 defconfig
> doc: README.ae350: Sync for ax25-ae350 rename
>
> arch/riscv/Kconfig| 60
> +--
> arch/riscv/Makefile | 9 +++-
> arch/riscv/cpu/Makefile | 2 +-
> arch/riscv/cpu/ax25/Kconfig | 17 +--
> arch/riscv/cpu/ax25/cache.c | 12 ++---
> arch/riscv/cpu/cpu.c | 98
> ++
> arch/riscv/cpu/mtrap.S| 103
>
> arch/riscv/cpu/qemu/Kconfig | 12 +
> arch/riscv/cpu/qemu/cpu.c | 14 ++
> arch/riscv/cpu/start.S| 93
> ++--
> arch/riscv/dts/ae350.dts | 229
>
> arch/riscv/include/asm/csr.h | 16 ---
> arch/riscv/include/asm/encoding.h | 236
> +++
> arch/riscv/include/asm/global_data.h | 4 ++
> arch/riscv/include/asm/syscon.h | 19
> arch/riscv/lib/Makefile | 2 +
> arch/riscv/lib/asm-offsets.c | 19
> arch/riscv/lib/bootm.c| 2 +-
> arch/riscv/lib/interrupts.c | 62
>
> arch/riscv/lib/rdtime.c | 38
> +++
> arch/riscv/lib/sifive_clint.c | 84
> +
> board/AndesTech/ax25-ae350/Kconfig| 4 ++
> board/AndesTech/ax25-ae350/MAINTAINERS| 5 +-
> board/emulation/qemu-riscv/Kconfig| 2 +
> configs/{a25-ae350_32_defconfig => ae350_rv32_defconfig} | 0
> configs/{ax25-ae350_64_defconfig => ae350_rv64_defconfig} |
Re: [U-Boot] [PATCH v2 3/3] usb: gadget: f_sdp: Allow SPL to load and boot FIT via SDP
Hi Sjoerd,
> On Wed, 2019-06-05 at 11:40 +0200, Lukasz Majewski wrote:
> > Hi Fabio, Sjoerd
> >
> > > On Tue, Jun 4, 2019 at 5:41 PM Sjoerd Simons
> > > wrote:
> > >
> > > > Small steps right; Ooi what imx_usb_loader
> > > > configuration/commands are you using to test this? (I find its
> > > > config rather tricky to grasp).
> > >
> > > I simply run:
> > >
> > > sudo ./imx_usb SPL
> > >
> > > and then
> > >
> > > sudo ./imx_usb u-boot-dtb.img
> > >
> > > I suggest you to try U-Boot 2019.01 on a mx6sabreauto first.
> > >
> >
> > Tested-by: Lukasz Majewski
> >
> > Test HW: i.MX6Q Display5 factory setup.
> >
> >
> >
> > However, one thing puzzles me - the VID / PID used.When I run uuu
> > (mfgtools: SHA1: 13d187304f4faa473d2141409419c5b6f052addb):
> >
> > I see that "Build in config" has following VID/PID:
> > SDPU:SPL 0x0525 0xb4a4 [0x..0x04ff]
> > [1] SDPV:SPL10x0525 0xb4a4 [0x0500..0x9998]
> > SDPU:SPL 0x0525 0xb4a4 [0x..0x]
> >
> > But to make the SDPU command working I had to adjust it to be
> > similar to sabreauto (CONFIG_USB_GADGET_VENDOR_NUM=0x0525
> > CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5). Those match to "FB"
> > (fastboot?).
> >
> > Is this a bug or just the "Build in config" information is outdated?
> > With VID/PID set as for [1] (and as we use SDPU command, not FB),
> > the uuu doesn't connect to loaded SPL.
>
> So u-boot for the spl does (arch/arm/mach-imx/spl.c):
> ```
> int g_dnl_bind_fixup(struct usb_device_descriptor *dev, const char
> *name) {
> put_unaligned(CONFIG_USB_GADGET_PRODUCT_NUM + 0xfff,
> >idProduct); ``
Ach... Right.
Thanks for pointing this out.
>
> Iotw with CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 in the config when in
> the SPL the product will be 0xb4a4, which uuu recognizes.
>
> Once in the main u-boot image in principle you shoudl be able to use
> `FB:`, however it doesn't seem `FB: ucmd` is supported for mainline u-
> boot so...
>
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgprsZewFn3XZ.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Uboot send pull request
Hi Tom,
Please pull some riscv update:
1. Add DM drivers to support RISC-V CPU and timer, plus some bug fixes.
2. Support SiFive UART
3. Rename ax25-ae350 defconfig
https://travis-ci.org/rickchen36/u-boot-riscv/builds/469364551
Thanks
Rick
The following changes since commit 1f2e948d6d53f77a2ddb2dde3531b0d5bc2815ad:
Prepare v2019.01-rc2 (2018-12-17 20:25:24 -0500)
are available in the Git repository at:
git://git.denx.de/u-boot-riscv.git
for you to fetch changes up to 368ff57805b03bebf99e97e703ce07aec721bc71:
doc: README.ae350: Sync for ax25-ae350 rename (2018-12-18 13:26:02 +0800)
Anup Patel (4):
riscv: Introduce a Kconfig option for machine mode
riscv: Implement riscv_get_time() API using rdtime instruction
drivers: serial: Add SiFive UART driver
riscv: qemu: Imply SIFIVE_SERIAL for emulation
Bin Meng (22):
dm: cpu: Add timebase frequency to the platdata
riscv: qemu: Create a simple-bus driver for the soc node
cpu: Add a RISC-V CPU driver
timer: Add generic driver for RISC-V privileged architecture defined timer
riscv: ax25: Hide the ax25-specific Kconfig option
riscv: Add a SYSCON driver for SiFive's Core Local Interruptor
riscv: qemu: Add platform-specific Kconfig options
riscv: Enlarge the default SYS_MALLOC_F_LEN
riscv: Probe cpus during boot
riscv: Remove non-DM version of print_cpuinfo()
riscv: Add CSR numbers
riscv: Add exception codes for xcause register
riscv: Update supports_extension() to use desc from cpu driver
riscv: Add indirect stringification to csr_xxx ops
riscv: Do some basic architecture level cpu initialization
riscv: Move trap handler codes to mtrap.S
riscv: Fix context restore before returning from trap handler
riscv: Return to previous privilege level after trap handling
riscv: Adjust the _exit_trap() position to come before handle_trap()
riscv: Save boot hart id to the global data
riscv: bootm: Change to use boot_hart from global data
riscv: Remove ae350.dts
Lukas Auer (1):
riscv: add Kconfig entries for the code model
Rick Chen (2):
riscv: configs: Rename ax25-ae350 defconfig
doc: README.ae350: Sync for ax25-ae350 rename
arch/riscv/Kconfig| 60
+--
arch/riscv/Makefile | 9 +++-
arch/riscv/cpu/Makefile | 2 +-
arch/riscv/cpu/ax25/Kconfig | 17 +--
arch/riscv/cpu/ax25/cache.c | 12 ++---
arch/riscv/cpu/cpu.c | 98
++
arch/riscv/cpu/mtrap.S| 103
arch/riscv/cpu/qemu/Kconfig | 12 +
arch/riscv/cpu/qemu/cpu.c | 14 ++
arch/riscv/cpu/start.S| 93
++--
arch/riscv/dts/ae350.dts | 229
arch/riscv/include/asm/csr.h | 16 ---
arch/riscv/include/asm/encoding.h | 236
+++
arch/riscv/include/asm/global_data.h | 4 ++
arch/riscv/include/asm/syscon.h | 19
arch/riscv/lib/Makefile | 2 +
arch/riscv/lib/asm-offsets.c | 19
arch/riscv/lib/bootm.c| 2 +-
arch/riscv/lib/interrupts.c | 62
arch/riscv/lib/rdtime.c | 38 +++
arch/riscv/lib/sifive_clint.c | 84
+
board/AndesTech/ax25-ae350/Kconfig| 4 ++
board/AndesTech/ax25-ae350/MAINTAINERS| 5 +-
board/emulation/qemu-riscv/Kconfig| 2 +
configs/{a25-ae350_32_defconfig => ae350_rv32_defconfig} | 0
configs/{ax25-ae350_64_defconfig => ae350_rv64_defconfig} | 0
doc/README.ae350 | 2 +-
drivers/cpu/Kconfig | 6 +++
drivers/cpu/Makefile | 1 +
drivers/cpu/riscv_cpu.c | 116
+
drivers/serial/Kconfig| 13 +
drivers/serial/Makefile | 1 +
Re: [U-Boot] [PATCH 1/2] riscv: qemu: Enable PCI host ECAM generic driver
Hi Rick, On Wed, Jun 5, 2019 at 6:04 PM Rick Chen wrote: > > Hi Bin > > Bin Meng 於 2019年6月5日 週三 下午5:29寫道： > > > > Hi Rick, > > > > On Wed, Jun 5, 2019 at 1:55 PM Rick Chen wrote: > > > > > > Hi Bin > > > > > > Bin Meng 於 2019年6月4日 週二 下午2:27寫道： > > > > > > > > Hi Rick, > > > > > > > > On Tue, Jun 4, 2019 at 1:35 PM Rick Chen wrote: > > > > > > > > > > > > > > > > > Hi BIn > > > > > > > > > > > > > Hi Rick, > > > > > > > > > > > > > > On Mon, May 27, 2019 at 4:40 PM Auer, Lukas > > > > > > > wrote: > > > > > > > > > > > > > > > > On Wed, 2019-05-15 at 08:42 -0700, Bin Meng wrote: > > > > > > > > > QEMU 4.0.0 'virt' target integrates a generic ECAM PCI host. > > > > > > > > > Enable the driver for it. > > > > > > > > > > > > > > > > > > Signed-off-by: Bin Meng > > > > > > > > > --- > > > > > > > > > > > > > > > > > > board/emulation/qemu-riscv/Kconfig | 4 > > > > > > > > > 1 file changed, 4 insertions(+) > > > > > > > > > > > > > > > > > > > > > > > > > Reviewed-by: Lukas Auer > > > > > > > > Tested-by: Lukas Auer > > > > > > > > > > > > > > Could you please apply this series for v2019.07? > > > > > > > > > > > > > > > > > Applied to u-boot-riscv/master, thanks! > > > > > > > > Thanks for applying. > > > > > > > > By searching riscv patches from patchwork, it seems there are some old > > > > patches that are not cleaned up. I am not sure about their status. > > > > Maybe they are already applied. > > > > > > I will rebase to u-boot/master before applying the patchs. > > > If they are already applied, there will have conflictions, right ? > > > > > > > Not sure if there will be conflicts, so simply not applied (skipped). > > You can try. > > > > > > > > > > http://patchwork.ozlabs.org/project/uboot/list/?seriesriscv== > > > > > > > > Could you please do some house keeping? > > > > > > I am not sure what do you mean about house keeping ? > > > > I meant that you should clean up all these patches in your queue. > > Either mark them as accepted, or superseded, etc. > > > > I just applied your patchs yesterday. And its state became Accepted. I cleaned up my patches because I have the privilege to change patch status. > https://patchwork.ozlabs.org/project/uboot/list/?order=delegate=* > > I thought it will change by my actions automatically. No, it won't. > How can I change state from New to Accepted ? > You need change the state manually. I don't know other patches' status, so I left them to you. In the end, you are the RISC-V custodian. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4 v2] test: dm: Add a test for PCI Enhanced Allocation
Hi Alex,
On Tue, Jun 4, 2019 at 8:46 PM Alex Marginean wrote:
>
> This test is built on top of the existing swap_case driver. It adds EA
> capability structure support to swap_case and uses that to map BARs.
> BAR1 works as it used to, swapping upper/lower case. BARs 2,4 map to a
> couple of magic values.
>
> Signed-off-by: Alex Marginean
> ---
>
> Changes in v2:
> - new patch, v1 didn't have a test
>
> arch/sandbox/dts/test.dts | 8 +++
> arch/sandbox/include/asm/test.h | 13
> drivers/misc/swap_case.c| 102 +++-
> test/dm/pci.c | 50
> 4 files changed, 172 insertions(+), 1 deletion(-)
>
Well done!
Reviewed-by: Bin Meng
Tested-by: Bin Meng
But please see some nits below:
> diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> index 46d8a56d0f..dd50a951a8 100644
> --- a/arch/sandbox/dts/test.dts
> +++ b/arch/sandbox/dts/test.dts
> @@ -434,6 +434,14 @@
> compatible = "sandbox,swap-case";
> };
> };
> + pci@1,0 {
> + compatible = "pci-generic";
> + reg = <0x0800 0 0 0 0>;
> + emul@0,0 {
> + compatible = "sandbox,swap-case";
> + use-ea;
> + };
> + };
> pci@1f,0 {
> compatible = "pci-generic";
> reg = <0xf800 0 0 0 0>;
> diff --git a/arch/sandbox/include/asm/test.h b/arch/sandbox/include/asm/test.h
> index e956a05262..32125f3037 100644
> --- a/arch/sandbox/include/asm/test.h
> +++ b/arch/sandbox/include/asm/test.h
> @@ -19,6 +19,7 @@
> #define PCI_CAP_ID_PM_OFFSET 0x50
> #define PCI_CAP_ID_EXP_OFFSET 0x60
> #define PCI_CAP_ID_MSIX_OFFSET 0x70
> +#define PCI_CAP_ID_EA_OFFSET 0x80
>
> #define PCI_EXT_CAP_ID_ERR_OFFSET 0x100
> #define PCI_EXT_CAP_ID_VC_OFFSET 0x200
> @@ -30,6 +31,18 @@
>
> #define SANDBOX_CLK_RATE 32768
>
> +/* Macros used to test PCI EA capability structure */
> +#define PCI_CAP_EA_BASE_LO00x0010
> +#define PCI_CAP_EA_BASE_LO10x0011
> +#define PCI_CAP_EA_BASE_LO20x0012
> +#define PCI_CAP_EA_BASE_LO40x0014
> +#define PCI_CAP_EA_BASE_HI20x0002ULL
> +#define PCI_CAP_EA_BASE_HI40x0004ULL
> +#define PCI_CAP_EA_SIZE_LO 0x
> +#define PCI_CAP_EA_SIZE_HI 0x0010ULL
> +#define PCI_EA_BAR2_MAGIC 0x72727272
> +#define PCI_EA_BAR4_MAGIC 0x74747474
> +
> /* System controller driver data */
> enum {
> SYSCON0 = 32,
> diff --git a/drivers/misc/swap_case.c b/drivers/misc/swap_case.c
> index fa608cec1b..949ef0fdd7 100644
> --- a/drivers/misc/swap_case.c
> +++ b/drivers/misc/swap_case.c
> @@ -61,11 +61,63 @@ static int sandbox_swap_case_get_devfn(struct udevice
> *dev)
> return plat->devfn;
> }
>
> +static int sandbox_swap_use_ea(struct udevice *dev)
nits: for consistency, name it as "sandbox_swap_case_use_ea"
> +{
> + return !!ofnode_get_property(dev->node, "use-ea", NULL);
> +}
> +
> +/* Please keep these macros in sync with ea_regs below */
> +#define PCI_CAP_ID_EA_SIZE (sizeof(ea_regs) + 4)
> +#define PCI_CAP_ID_EA_ENTRY_CNT4
> +/* Hardcoded EA structure, excluding 1st DW. */
> +static const u32 ea_regs[] = {
> + /* BEI=0, ES=2, BAR0 32b Base + 32b MaxOffset, I/O space */
> + (2 << 8) | 2,
> + PCI_CAP_EA_BASE_LO0,
> + 0,
> + /* BEI=1, ES=2, BAR1 32b Base + 32b MaxOffset */
> + (1 << 4) | 2,
> + PCI_CAP_EA_BASE_LO1,
> + MEM_TEXT_SIZE - 1,
> + /* BEI=2, ES=3, BAR2 64b Base + 32b MaxOffset */
> + (2 << 4) | 3,
> + PCI_CAP_EA_BASE_LO2 | PCI_EA_IS_64,
> + PCI_CAP_EA_SIZE_LO,
> + PCI_CAP_EA_BASE_HI2,
> + /* BEI=4, ES=4, BAR4 63b Base + 64b MaxOffset */
nits: typo of '63b'
> + (4 << 4) | 4,
> + PCI_CAP_EA_BASE_LO4 | PCI_EA_IS_64,
> + PCI_CAP_EA_SIZE_LO | PCI_EA_IS_64,
> + PCI_CAP_EA_BASE_HI4,
> + PCI_CAP_EA_SIZE_HI,
> +};
> +
> +static int sandbox_swap_case_read_ea(struct udevice *emul, uint offset,
> +ulong *valuep, enum pci_size_t size)
> +{
> + u32 reg;
> +
> + offset = offset - PCI_CAP_ID_EA_OFFSET - 4;
> + reg = ea_regs[offset >> 2];
> + reg >>= (offset % 4) * 8;
> +
> + *valuep = reg;
> + return 0;
> +}
> +
> static int sandbox_swap_case_read_config(struct udevice *emul, uint offset,
> ulong *valuep, enum pci_size_t size)
> {
> struct swap_case_platdata *plat = dev_get_platdata(emul);
>
> + /*
> +* The content of the EA capability structure is handled
Re: [U-Boot] [PATCH 4/4 v2] drivers: pci: add API to issue FLR on a PCI function if supported
On Tue, Jun 4, 2019 at 8:46 PM Alex Marginean wrote: > > Adds dm_pci_flr API that issues a Function Level reset on a PCI-e function, > if FLR is supported. > > Signed-off-by: Alex Marginean > --- > > Changes in v2: > - Use kernel PCI_EXP macros for register offsets > > drivers/pci/pci-uclass.c | 24 > include/pci.h| 14 ++ > 2 files changed, 38 insertions(+) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4 v2] drivers: pci: add map_bar support for Enhanced Allocation
On Tue, Jun 4, 2019 at 8:46 PM Alex Marginean wrote: > > Makes dm_pci_map_bar API available for integrated PCI devices that > support Enhanced Allocation instead of the original PCI BAR mechanism. > > Signed-off-by: Alex Marginean > --- > > Changes in v2: > - fixed parsing for BAR1+ > - fixed an issue with EA entry size > - don't look up EA capability structure twice > - use phys_addr_t for EA addresses > - use kernel MACROS for EA registers > > drivers/pci/pci-uclass.c | 46 > include/pci.h| 13 > 2 files changed, 59 insertions(+) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4 v2] pci: fixed dm_pci_map_bar comment
On Tue, Jun 4, 2019 at 8:46 PM Alex Marginean wrote: > > The comment now indicates that the input argument bar is a register offset, > not a BAR index. > It also mentions which BARs are supported for type 0/1 and that the > function can return 0 on error. > > Signed-off-by: Alex Marginean > --- > > Changes in v2: > - new patch > > include/pci.h | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] riscv: qemu: Enable PCI host ECAM generic driver
Hi Bin Bin Meng 於 2019年6月5日 週三 下午5:29寫道： > > Hi Rick, > > On Wed, Jun 5, 2019 at 1:55 PM Rick Chen wrote: > > > > Hi Bin > > > > Bin Meng 於 2019年6月4日 週二 下午2:27寫道： > > > > > > Hi Rick, > > > > > > On Tue, Jun 4, 2019 at 1:35 PM Rick Chen wrote: > > > > > > > > > > > > > > Hi BIn > > > > > > > > > > > Hi Rick, > > > > > > > > > > > > On Mon, May 27, 2019 at 4:40 PM Auer, Lukas > > > > > > wrote: > > > > > > > > > > > > > > On Wed, 2019-05-15 at 08:42 -0700, Bin Meng wrote: > > > > > > > > QEMU 4.0.0 'virt' target integrates a generic ECAM PCI host. > > > > > > > > Enable the driver for it. > > > > > > > > > > > > > > > > Signed-off-by: Bin Meng > > > > > > > > --- > > > > > > > > > > > > > > > > board/emulation/qemu-riscv/Kconfig | 4 > > > > > > > > 1 file changed, 4 insertions(+) > > > > > > > > > > > > > > > > > > > > > > Reviewed-by: Lukas Auer > > > > > > > Tested-by: Lukas Auer > > > > > > > > > > > > Could you please apply this series for v2019.07? > > > > > > > > > > > > > > Applied to u-boot-riscv/master, thanks! > > > > > > Thanks for applying. > > > > > > By searching riscv patches from patchwork, it seems there are some old > > > patches that are not cleaned up. I am not sure about their status. > > > Maybe they are already applied. > > > > I will rebase to u-boot/master before applying the patchs. > > If they are already applied, there will have conflictions, right ? > > > > Not sure if there will be conflicts, so simply not applied (skipped). > You can try. > > > > > > > http://patchwork.ozlabs.org/project/uboot/list/?seriesriscv== > > > > > > Could you please do some house keeping? > > > > I am not sure what do you mean about house keeping ? > > I meant that you should clean up all these patches in your queue. > Either mark them as accepted, or superseded, etc. > I just applied your patchs yesterday. And its state became Accepted. https://patchwork.ozlabs.org/project/uboot/list/?order=delegate=* I thought it will change by my actions automatically. How can I change state from New to Accepted ? Thanks Rick > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] usb: gadget: f_sdp: Allow SPL to load and boot FIT via SDP
On Wed, 2019-06-05 at 11:40 +0200, Lukasz Majewski wrote:
> Hi Fabio, Sjoerd
>
> > On Tue, Jun 4, 2019 at 5:41 PM Sjoerd Simons
> > wrote:
> >
> > > Small steps right; Ooi what imx_usb_loader configuration/commands
> > > are you using to test this? (I find its config rather tricky to
> > > grasp).
> >
> > I simply run:
> >
> > sudo ./imx_usb SPL
> >
> > and then
> >
> > sudo ./imx_usb u-boot-dtb.img
> >
> > I suggest you to try U-Boot 2019.01 on a mx6sabreauto first.
> >
>
> Tested-by: Lukasz Majewski
>
> Test HW: i.MX6Q Display5 factory setup.
>
>
>
> However, one thing puzzles me - the VID / PID used.When I run uuu
> (mfgtools: SHA1: 13d187304f4faa473d2141409419c5b6f052addb):
>
> I see that "Build in config" has following VID/PID:
> SDPU:SPL 0x0525 0xb4a4 [0x..0x04ff] [1]
> SDPV:SPL10x0525 0xb4a4 [0x0500..0x9998]
> SDPU:SPL 0x0525 0xb4a4 [0x..0x]
>
> But to make the SDPU command working I had to adjust it to be similar
> to sabreauto (CONFIG_USB_GADGET_VENDOR_NUM=0x0525
> CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5). Those match to "FB"
> (fastboot?).
>
> Is this a bug or just the "Build in config" information is outdated?
> With VID/PID set as for [1] (and as we use SDPU command, not FB), the
> uuu doesn't connect to loaded SPL.
So u-boot for the spl does (arch/arm/mach-imx/spl.c):
```
int g_dnl_bind_fixup(struct usb_device_descriptor *dev, const char *name)
{
put_unaligned(CONFIG_USB_GADGET_PRODUCT_NUM + 0xfff, >idProduct);
``
Iotw with CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 in the config when in
the SPL the product will be 0xb4a4, which uuu recognizes.
Once in the main u-boot image in principle you shoudl be able to use
`FB:`, however it doesn't seem `FB: ucmd` is supported for mainline u-
boot so...
--
Sjoerd Simons
Collabora Ltd.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] usb: gadget: f_sdp: Allow SPL to load and boot FIT via SDP
Hi Fabio, Sjoerd > On Tue, Jun 4, 2019 at 5:41 PM Sjoerd Simons > wrote: > > > Small steps right; Ooi what imx_usb_loader configuration/commands > > are you using to test this? (I find its config rather tricky to > > grasp). > > I simply run: > > sudo ./imx_usb SPL > > and then > > sudo ./imx_usb u-boot-dtb.img > > I suggest you to try U-Boot 2019.01 on a mx6sabreauto first. > Tested-by: Lukasz Majewski Test HW: i.MX6Q Display5 factory setup. However, one thing puzzles me - the VID / PID used.When I run uuu (mfgtools: SHA1: 13d187304f4faa473d2141409419c5b6f052addb): I see that "Build in config" has following VID/PID: SDPU:SPL 0x0525 0xb4a4 [0x..0x04ff] [1] SDPV:SPL10x0525 0xb4a4 [0x0500..0x9998] SDPU:SPL 0x0525 0xb4a4 [0x..0x] But to make the SDPU command working I had to adjust it to be similar to sabreauto (CONFIG_USB_GADGET_VENDOR_NUM=0x0525 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5). Those match to "FB" (fastboot?). Is this a bug or just the "Build in config" information is outdated? With VID/PID set as for [1] (and as we use SDPU command, not FB), the uuu doesn't connect to loaded SPL. To make it working (on host): cat << EOF > display5_recovery.lst uuu_version 1.2.135 SDP: boot -f /srv/tftp/SPL SDPU: write -f /srv/tftp/u-boot-dtb.img -addr 0x1000 SDPU: jump -addr 0x1000 SDPU: done EOF sudo ./uuu/uuu display5_recovery.lst > U-Boot 2019.01 is prior to the DM / fit conversion and loading SPL + > u-boot.img with the method above works fine. > > > One of the next things I will need to look at is actually secure > > boot.. That said why does imx_usb_loader if the board isn't > > locked? > > Not sure what you mean by locked. > > We have been using imx_usb_loader for a long time. After DM / fit > comvesion the IVT piece is not added into the final .img. > > From the main Makefile: > > ifdef CONFIG_SPL_LOAD_FIT > MKIMAGEFLAGS_u-boot.img = -f auto -A $(ARCH) -T firmware -C none -O > u-boot \ -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \ > -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" -E \ > $(patsubst %,-b arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) > else > MKIMAGEFLAGS_u-boot.img = -A $(ARCH) -T firmware -C none -O u-boot \ > -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \ > -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" > MKIMAGEFLAGS_u-boot-ivt.img = -A $(ARCH) -T firmware_ivt -C none -O > u-boot \ -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \ > -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" > u-boot-ivt.img: MKIMAGEOUTPUT = u-boot-ivt.img.log > CLEAN_FILES += u-boot-ivt.img.log u-boot-dtb.imx.log SPL.log > u-boot.imx.log endif > > we can see that the ivt is not added for the CONFIG_SPL_LOAD_FIT > case. > > I tried to change this logic, but so far was not able to make it work. Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgp72sBfK5YMM.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] riscv: ax25: use CCTL to flush d-cache
Hi Rick,
On Wed, Jun 5, 2019 at 5:38 PM Rick Chen wrote:
>
> Hi Bin
>
> >
> > Hi Rick,
> >
> > On Tue, May 28, 2019 at 5:45 PM Andes wrote:
> > >
> > > From: Rick Chen
> > >
> > > Use CCTL command to do d-cache write back and invalidate
> > > instead of fence.
> > >
> > > Signed-off-by: Rick Chen
> > > Cc: Greentime Hu
> > > ---
> > > arch/riscv/cpu/ax25/cache.c | 22 +-
> > > 1 file changed, 13 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/arch/riscv/cpu/ax25/cache.c b/arch/riscv/cpu/ax25/cache.c
> > > index 228fc55..d30071e 100644
> > > --- a/arch/riscv/cpu/ax25/cache.c
> > > +++ b/arch/riscv/cpu/ax25/cache.c
> > > @@ -5,17 +5,21 @@
> > > */
> > >
> > > #include
> > > +#include
> > > +
> > > +#ifdef CONFIG_RISCV_NDS_CACHE
> > > +/* mcctlcommand */
> > > +#define CCTL_REG_MCCTLCOMMAND_NUM 0x7cc
> > > +
> > > +/* D-cache operation */
> > > +#define CCTL_L1D_WBINVAL_ALL 6
> > > +#endif
> > >
> > > void flush_dcache_all(void)
> > > {
> > > - /*
> > > -* Andes' AX25 does not have a coherence agent. U-Boot must use
> > > data
> > > -* cache flush and invalidate functions to keep data in the system
> > > -* coherent.
> > > -* The implementation of the fence instruction in the AX25
> > > flushes the
> > > -* data cache and is used for this purpose.
> > > -*/
> > > - asm volatile ("fence" ::: "memory");
> > > +#ifdef CONFIG_RISCV_NDS_CACHE
> > > + csr_write(CCTL_REG_MCCTLCOMMAND_NUM, CCTL_L1D_WBINVAL_ALL);
> >
> > I think CCTL_REG_MCCTLCOMMAND_NUM is a vendor specific CSR. Does
> > upstream GCC support this CSR?
>
> Yes. It is a vendor specific CSR. Upstream GCC shall not support it.
> So I isolate it by CONFIG_RISCV_NDS_CACHE.
>
OK, but I suspect you will need do something for the travis build
since upstream gcc is used?
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] riscv: ax25: use CCTL to flush d-cache
Hi Bin
>
> Hi Rick,
>
> On Tue, May 28, 2019 at 5:45 PM Andes wrote:
> >
> > From: Rick Chen
> >
> > Use CCTL command to do d-cache write back and invalidate
> > instead of fence.
> >
> > Signed-off-by: Rick Chen
> > Cc: Greentime Hu
> > ---
> > arch/riscv/cpu/ax25/cache.c | 22 +-
> > 1 file changed, 13 insertions(+), 9 deletions(-)
> >
> > diff --git a/arch/riscv/cpu/ax25/cache.c b/arch/riscv/cpu/ax25/cache.c
> > index 228fc55..d30071e 100644
> > --- a/arch/riscv/cpu/ax25/cache.c
> > +++ b/arch/riscv/cpu/ax25/cache.c
> > @@ -5,17 +5,21 @@
> > */
> >
> > #include
> > +#include
> > +
> > +#ifdef CONFIG_RISCV_NDS_CACHE
> > +/* mcctlcommand */
> > +#define CCTL_REG_MCCTLCOMMAND_NUM 0x7cc
> > +
> > +/* D-cache operation */
> > +#define CCTL_L1D_WBINVAL_ALL 6
> > +#endif
> >
> > void flush_dcache_all(void)
> > {
> > - /*
> > -* Andes' AX25 does not have a coherence agent. U-Boot must use data
> > -* cache flush and invalidate functions to keep data in the system
> > -* coherent.
> > -* The implementation of the fence instruction in the AX25 flushes
> > the
> > -* data cache and is used for this purpose.
> > -*/
> > - asm volatile ("fence" ::: "memory");
> > +#ifdef CONFIG_RISCV_NDS_CACHE
> > + csr_write(CCTL_REG_MCCTLCOMMAND_NUM, CCTL_L1D_WBINVAL_ALL);
>
> I think CCTL_REG_MCCTLCOMMAND_NUM is a vendor specific CSR. Does
> upstream GCC support this CSR?
Yes. It is a vendor specific CSR. Upstream GCC shall not support it.
So I isolate it by CONFIG_RISCV_NDS_CACHE.
Thanks
Rick
>
> > +#endif
> > }
> >
> > void flush_dcache_range(unsigned long start, unsigned long end)
> > @@ -72,8 +76,8 @@ void dcache_disable(void)
> > {
> > #ifndef CONFIG_SYS_DCACHE_OFF
> > #ifdef CONFIG_RISCV_NDS_CACHE
> > + csr_write(CCTL_REG_MCCTLCOMMAND_NUM, CCTL_L1D_WBINVAL_ALL);
> > asm volatile (
> > - "fence\n\t"
> > "csrr t1, mcache_ctl\n\t"
> > "andi t0, t1, ~0x2\n\t"
> > "csrw mcache_ctl, t0\n\t"
> > --
>
> Regards,
> Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] riscv: dts: move out AE350 L2 node from cpus node
Hi Bin
Bin Meng 於 2019年6月4日 週二 上午10:48寫道：
>
> Hi Rick,
>
> On Tue, May 28, 2019 at 5:44 PM Andes wrote:
> >
> > From: Rick Chen
> >
> > When L2 node exists inside cpus node, uclass_get_device
> > can not parse L2 node successfully. So move it outside
> > from cpus node.
> >
> > Also add tag-ram-ctl and data-ram-ctl attributes for
> > v5l2 cache controller driver. This can adjust timing
> > by requirement from dtb to improve performance.
> >
> > Signed-off-by: Rick Chen
> > Cc: Greentime Hu
> > ---
> > arch/riscv/dts/ae350_32.dts | 17 +++--
> > arch/riscv/dts/ae350_64.dts | 17 +++--
> > 2 files changed, 22 insertions(+), 12 deletions(-)
> >
> > diff --git a/arch/riscv/dts/ae350_32.dts b/arch/riscv/dts/ae350_32.dts
> > index cb6ee13..83abfcb 100644
> > --- a/arch/riscv/dts/ae350_32.dts
> > +++ b/arch/riscv/dts/ae350_32.dts
> > @@ -62,13 +62,18 @@
> > compatible = "riscv,cpu-intc";
> > };
> > };
> > + };
> >
> > - L2: l2-cache@e050 {
> > - compatible = "cache";
> > - cache-level = <2>;
> > - cache-size = <0x4>;
> > - reg = <0x0 0xe050 0x0 0x4>;
> > - };
> > + L2: l2-cache@e050 {
> > + compatible = "cache";
>
> too generic compatible string (see my previous comments in patch [1/6])
Same replying in patch [1/6]
>
> > + cache-level = <2>;
> > + cache-size = <0x4>;
> > + reg = <0xe050 0x4>;
> > + andes,inst-prefetch = <3>;
> > + andes,data-prefetch = <3>;
> > + // The value format is
>
> nits: no //, use /* */
OK
I will use /* */ instead of //
>
> > + andes,tag-ram-ctl = <0 0>;
> > + andes,data-ram-ctl = <0 0>;
> > };
> >
> > memory@0 {
> > diff --git a/arch/riscv/dts/ae350_64.dts b/arch/riscv/dts/ae350_64.dts
> > index 705491a..7009bdc 100644
> > --- a/arch/riscv/dts/ae350_64.dts
> > +++ b/arch/riscv/dts/ae350_64.dts
> > @@ -62,13 +62,18 @@
> > compatible = "riscv,cpu-intc";
> > };
> > };
> > + };
> >
> > - L2: l2-cache@e050 {
> > - compatible = "cache";
> > - cache-level = <2>;
> > - cache-size = <0x4>;
> > - reg = <0x0 0xe050 0x0 0x4>;
> > - };
> > + L2: l2-cache@e050 {
> > + compatible = "cache";
> > + cache-level = <2>;
> > + cache-size = <0x4>;
> > + reg = <0x0 0xe050 0x0 0x4>;
> > + andes,inst-prefetch = <3>;
> > + andes,data-prefetch = <3>;
> > + // The value format is
>
> nits: no //, use /* */
I will use /* */ instead of //
Thanks
Rick
>
> > + andes,tag-ram-ctl = <0 0>;
> > + andes,data-ram-ctl = <0 0>;
> > };
> >
> > memory@0 {
> > --
>
> Regards,
> Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] riscv: qemu: Enable PCI host ECAM generic driver
Hi Rick, On Wed, Jun 5, 2019 at 1:55 PM Rick Chen wrote: > > Hi Bin > > Bin Meng 於 2019年6月4日 週二 下午2:27寫道： > > > > Hi Rick, > > > > On Tue, Jun 4, 2019 at 1:35 PM Rick Chen wrote: > > > > > > > > > > > Hi BIn > > > > > > > > > Hi Rick, > > > > > > > > > > On Mon, May 27, 2019 at 4:40 PM Auer, Lukas > > > > > wrote: > > > > > > > > > > > > On Wed, 2019-05-15 at 08:42 -0700, Bin Meng wrote: > > > > > > > QEMU 4.0.0 'virt' target integrates a generic ECAM PCI host. > > > > > > > Enable the driver for it. > > > > > > > > > > > > > > Signed-off-by: Bin Meng > > > > > > > --- > > > > > > > > > > > > > > board/emulation/qemu-riscv/Kconfig | 4 > > > > > > > 1 file changed, 4 insertions(+) > > > > > > > > > > > > > > > > > > > Reviewed-by: Lukas Auer > > > > > > Tested-by: Lukas Auer > > > > > > > > > > Could you please apply this series for v2019.07? > > > > > > > > > > > Applied to u-boot-riscv/master, thanks! > > > > Thanks for applying. > > > > By searching riscv patches from patchwork, it seems there are some old > > patches that are not cleaned up. I am not sure about their status. > > Maybe they are already applied. > > I will rebase to u-boot/master before applying the patchs. > If they are already applied, there will have conflictions, right ? > Not sure if there will be conflicts, so simply not applied (skipped). You can try. > > > > http://patchwork.ozlabs.org/project/uboot/list/?seriesriscv== > > > > Could you please do some house keeping? > > I am not sure what do you mean about house keeping ? I meant that you should clean up all these patches in your queue. Either mark them as accepted, or superseded, etc. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] riscv: ae350: add imply v5l2 cache controller
Hi Bin > > Hi Rick, > > On Tue, May 28, 2019 at 5:44 PM Andes wrote: > > > > From: Rick Chen > > > > Select the v5l2 UCLASS_CACHE driver for AE350. > > > > Signed-off-by: Rick Chen > > Cc: Greentime Hu > > --- > > board/AndesTech/ax25-ae350/Kconfig | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/board/AndesTech/ax25-ae350/Kconfig > > b/board/AndesTech/ax25-ae350/Kconfig > > index 5e682b6..dd299d9 100644 > > --- a/board/AndesTech/ax25-ae350/Kconfig > > +++ b/board/AndesTech/ax25-ae350/Kconfig > > @@ -25,5 +25,6 @@ config BOARD_SPECIFIC_OPTIONS # dummy > > def_bool y > > select RISCV_NDS > > imply SMP > > + imply V5L2_CACHE > > I believe L2 cache is a CPU specific feature, hence this should be > implied from arch/riscv/cpu/ax25/Kconfig OK I will move it to arch/riscv/cpu/ax25/Kconfig Thanks Rick > > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] riscv: cache: Flush L2 cache before jump to linux
Hi Bin > > Hi Rick, > > On Tue, May 28, 2019 at 5:44 PM Andes wrote: > > > > From: Rick Chen > > > > Flush and disable cache in cleanup_before_linux() > > which will be called before jump to linux. > > > > The sequence will be preferred as below: > > L1 flush -> L1 disable -> L2 flush -> L2 disable > > > > Signed-off-by: Rick Chen > > Cc: Greentime Hu > > --- > > arch/riscv/cpu/ax25/cpu.c | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/arch/riscv/cpu/ax25/cpu.c b/arch/riscv/cpu/ax25/cpu.c > > index 76689b2..9e7579a 100644 > > --- a/arch/riscv/cpu/ax25/cpu.c > > +++ b/arch/riscv/cpu/ax25/cpu.c > > @@ -7,6 +7,7 @@ > > /* CPU specific code */ > > #include > > #include > > +#include > > > > /* > > * cleanup_before_linux() is called just before we call linux > > @@ -22,6 +23,9 @@ int cleanup_before_linux(void) > > cache_flush(); > > icache_disable(); > > dcache_disable(); > > +#ifdef CONFIG_RISCV_NDS_CACHE > > + v5l2_disable(); > > +#endif > > The direct call into a driver should be avoided. Instead, use a proper > DM cache uclass driver API (see my review comments in patch [1/6]) OK I will use DM cache uclass driver API to disable L2 driver. Thanks Rick > > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] i.MX8MM mapped register access causes crashes
Hi Peng, I'm still trying to get my i.MX8MM board running with mainline U-Boot. I'm using your patches and added some modifications, so I'm now able to run SPL and U-Boot proper. One problem I have is, that accessing some regions in the memory map for peripheral register access, U-Boot crashes or hangs. Example: => md 0x302d 302d: 0743 e031 C...1... 302d0010: 302d0020: 001012ec"Synchronous Abort" handler, esr 0x96000210 elr: 40251b84 lr : 40251ba0 (reloc) elr: bffa3b84 lr : bffa3ba0 x0 : bffb9000 x1 : 308800b4 x2 : bff6e9b4 x3 : 302d0028 x4 : x5 : bffb96a2 x6 : 0004 x7 : bbf3c330 x8 : bbf3c2f0 x9 : 000c x10: ffd8 x11: 0006 x12: 0001869f x13: 4238 x14: bbf3c59c x15: 0008 x16: b900 x17: ae80 x18: bbf41d70 x19: 0038 x20: 302d0020 x21: 302d0020 x22: bffb8e5f x23: 0008 x24: 0004 x25: 0004 x26: 0004 x27: bbf3c3b8 x28: 0002 x29: bbf3c330 Do you have any idea what might be wrong or how I could debug this issue? Thanks, Frieder ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] pinctrl: meson: add support for pinmux status
On 04/06/2019 11:04, Neil Armstrong wrote: > In order to support the "pinmux status" command, fix the GX pinctrl > drivers and add the necessary functions callbacks. > > Neil Armstrong (4): > pinctrl: meson-gx: fix GPIO_TEST_N and GPIOCLK_ groups > pinctrl: meson: add common function to get pins name > pinctrl: meson-gx: add support for getting pinmux status > pinctrl: meson-axg: add support for getting pinmux status > > drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c | 48 +++ > drivers/pinctrl/meson/pinctrl-meson-gx-pmx.c | 44 + > drivers/pinctrl/meson/pinctrl-meson-gxbb.c| 7 ++- > drivers/pinctrl/meson/pinctrl-meson-gxl.c | 6 ++- > drivers/pinctrl/meson/pinctrl-meson.c | 24 ++ > drivers/pinctrl/meson/pinctrl-meson.h | 3 ++ > 6 files changed, 128 insertions(+), 4 deletions(-) > Applied to u-boot-amlogic ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] riscv: ae350: use the v5l2 driver to configure the cache
Hi Bin
Bin Meng 於 2019年6月4日 週二 上午10:48寫道：
>
> Hi Rick,
>
> On Tue, May 28, 2019 at 5:44 PM Andes wrote:
> >
> > From: Rick Chen
> >
> > Find the UCLASS_CACHE driver to configure the cache controller's
> > settings.
> >
> > Signed-off-by: Rick Chen
> > Cc: Greentime Hu
> > ---
> > board/AndesTech/ax25-ae350/ax25-ae350.c | 15 +++
> > 1 file changed, 15 insertions(+)
> >
> > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > index 3d65ce7..686ec4a 100644
> > --- a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > +++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > @@ -11,6 +11,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > DECLARE_GLOBAL_DATA_PTR;
> >
> > @@ -93,10 +94,24 @@ int smc_init(void)
> > return 0;
> > }
> >
> > +int v5l2_init(void)
> > +{
> > + struct udevice *dev;
> > + int ret;
> > +
> > + ret = uclass_get_device(UCLASS_CACHE, 0, );
> > +
> > + if (ret)
> > + return ret;
> > +
> > + return 0;
> > +}
> > +
> > #ifdef CONFIG_BOARD_EARLY_INIT_F
> > int board_early_init_f(void)
> > {
> > smc_init();
> > + v5l2_init();
>
> Please check the return value here, or you can make v512_init() returns void.
OK.
I will check the return value here.
>
> >
> > return 0;
> > }
> > --
>
> Regards,
> Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] Add drive-strength-microamp in Meson pinctrl driver
On 04/06/2019 13:53, Guillaume La Roque wrote: > The purpose of this patchset is to add drive-strength-microamp support in > meson pinconf > driver. This is a new feature that was added on the g12a. It is critical for > us > to support this since many functions are failing with default pad > drive-strength. > > The value achievable by the SoC are 500uA, 2500uA, 3000uA and 4000uA and the > DT property > 'drive-strength-microamp' is expressed in uA. > So this patch add another generic property "drive-strength-microamp". The > change to do so > would be minimal and could be benefit to other platforms later on. > > it's backport from linux : > https://lore.kernel.org/lkml/20190514082652.20686-1-glaro...@baylibre.com/ > > Cheers > Guillaume > > Guillaume La Roque (3): > dm: pinctrl: Add driver-strength-microamp property > pinctrl: meson: add support of drive-strength-microamp > pinctrl: meson: g12a: add DS bank value > > drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c | 1 + > drivers/pinctrl/meson/pinctrl-meson-g12a.c| 20 > drivers/pinctrl/meson/pinctrl-meson.c | 46 ++- > drivers/pinctrl/meson/pinctrl-meson.h | 43 +++-- > include/dm/pinctrl.h | 3 ++ > 5 files changed, 89 insertions(+), 24 deletions(-) > Applied to u-boot-amlogic ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] pinctrl: meson-gxbb: add hdmi related pins
On 04/06/2019 22:26, Maxime Jourdan wrote:
> The GXBB pinctrl is missing pins related to HDMI, namely hot plug
> detection (hpd) and I2C (sda + scl).
>
> This fixes HDMI support for GXBB in u-boot.
>
> Reported-by: Mohammad Rasim
> Signed-off-by: Maxime Jourdan
> ---
> drivers/pinctrl/meson/pinctrl-meson-gxbb.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
> b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
> index 59b5be6211..9e2e151164 100644
> --- a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
> +++ b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
> @@ -61,6 +61,10 @@ static const unsigned int eth_txd1_pins[] = {
> PIN(GPIOZ_11, EE_OFF) };
> static const unsigned int eth_txd2_pins[]= { PIN(GPIOZ_12, EE_OFF) };
> static const unsigned int eth_txd3_pins[]= { PIN(GPIOZ_13, EE_OFF) };
>
> +static const unsigned int hdmi_hpd_pins[]= { PIN(GPIOH_0, EE_OFF) };
> +static const unsigned int hdmi_sda_pins[]= { PIN(GPIOH_1, EE_OFF) };
> +static const unsigned int hdmi_scl_pins[]= { PIN(GPIOH_2, EE_OFF) };
> +
> static const unsigned int uart_tx_ao_a_pins[]= { PIN(GPIOAO_0, 0) };
> static const unsigned int uart_rx_ao_a_pins[]= { PIN(GPIOAO_1, 0) };
> static const unsigned int uart_cts_ao_a_pins[] = { PIN(GPIOAO_2, 0) };
> @@ -232,6 +236,11 @@ static struct meson_pmx_group
> meson_gxbb_periphs_groups[] = {
> GROUP(eth_txd2, 6, 3),
> GROUP(eth_txd3, 6, 2),
>
> + /* Bank H */
> + GROUP(hdmi_hpd, 1, 26),
> + GROUP(hdmi_sda, 1, 25),
> + GROUP(hdmi_scl, 1, 24),
> +
> /* Bank DV */
> GROUP(uart_tx_b,2, 29),
> GROUP(uart_rx_b,2, 28),
> @@ -351,6 +360,14 @@ static const char * const eth_groups[] = {
> "eth_txd0", "eth_txd1", "eth_txd2", "eth_txd3",
> };
>
> +static const char * const hdmi_hpd_groups[] = {
> + "hdmi_hpd",
> +};
> +
> +static const char * const hdmi_i2c_groups[] = {
> + "hdmi_sda", "hdmi_scl",
> +};
> +
> static const char * const gpio_aobus_groups[] = {
> "GPIOAO_0", "GPIOAO_1", "GPIOAO_2", "GPIOAO_3", "GPIOAO_4",
> "GPIOAO_5", "GPIOAO_6", "GPIOAO_7", "GPIOAO_8", "GPIOAO_9",
> @@ -383,6 +400,8 @@ static struct meson_pmx_func
> meson_gxbb_periphs_functions[] = {
> FUNCTION(uart_b),
> FUNCTION(uart_c),
> FUNCTION(eth),
> + FUNCTION(hdmi_hpd),
> + FUNCTION(hdmi_i2c),
> };
>
> static struct meson_pmx_func meson_gxbb_aobus_functions[] = {
>
Applied to u-boot-amlogic
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] riscv: ae350: use the v5l2 driver to configure the cache
Bin Meng 於 2019年6月4日 週二 上午10:48寫道：
>
> Hi Rick,
>
> On Tue, May 28, 2019 at 5:44 PM Andes wrote:
> >
> > From: Rick Chen
> >
> > Find the UCLASS_CACHE driver to configure the cache controller's
> > settings.
> >
> > Signed-off-by: Rick Chen
> > Cc: Greentime Hu
> > ---
> > board/AndesTech/ax25-ae350/ax25-ae350.c | 15 +++
> > 1 file changed, 15 insertions(+)
> >
> > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > index 3d65ce7..686ec4a 100644
> > --- a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > +++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > @@ -11,6 +11,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > DECLARE_GLOBAL_DATA_PTR;
> >
> > @@ -93,10 +94,24 @@ int smc_init(void)
> > return 0;
> > }
> >
> > +int v5l2_init(void)
> > +{
> > + struct udevice *dev;
> > + int ret;
> > +
> > + ret = uclass_get_device(UCLASS_CACHE, 0, );
> > +
> > + if (ret)
> > + return ret;
> > +
> > + return 0;
> > +}
> > +
> > #ifdef CONFIG_BOARD_EARLY_INIT_F
> > int board_early_init_f(void)
> > {
> > smc_init();
> > + v5l2_init();
>
> Please check the return value here, or you can make v512_init() returns void.
>
> >
> > return 0;
> > }
> > --
>
> Regards,
> Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] dm: cache: add v5l2 cache controller driver
Hi Bin
Bin Meng 於 2019年6月4日 週二 上午10:48寫道：
>
> Hi Rick,
>
> On Tue, May 28, 2019 at 5:44 PM Andes wrote:
> >
> > From: Rick Chen
> >
> > Add a v5l2 cache controller driver that is usually found on
> > Andes RISC-V ae350 platform. It will parse the cache settings
> > from the dtb.
> >
> > In this version tag and data ram control timing can be adjusted
> > by the requirement from the dtb.
> >
> > Signed-off-by: Rick Chen
> > Cc: Greentime Hu
> > ---
> > arch/riscv/include/asm/global_data.h | 3 ++
> > arch/riscv/include/asm/v5l2cache.h | 61 +
> > drivers/cache/Kconfig| 9
> > drivers/cache/Makefile | 1 +
> > drivers/cache/cache-v5l2.c | 102
> > +++
> > 5 files changed, 176 insertions(+)
> > create mode 100644 arch/riscv/include/asm/v5l2cache.h
> > create mode 100644 drivers/cache/cache-v5l2.c
> >
> > diff --git a/arch/riscv/include/asm/global_data.h
> > b/arch/riscv/include/asm/global_data.h
> > index b74bd7e..6e52d5d 100644
> > --- a/arch/riscv/include/asm/global_data.h
> > +++ b/arch/riscv/include/asm/global_data.h
> > @@ -24,6 +24,9 @@ struct arch_global_data {
> > #ifdef CONFIG_ANDES_PLMT
> > void __iomem *plmt; /* plmt base address */
> > #endif
> > +#ifdef CONFIG_V5L2_CACHE
> > + void __iomem *v5l2; /* v5l2 base address */
> > +#endif
>
> Please do not expose this to global data if it is only used inside a
> driver. Anything that is here is for "global" usage.
OK.
I will remove it.
>
> > #ifdef CONFIG_SMP
> > struct ipi_data ipi[CONFIG_NR_CPUS];
> > #endif
> > diff --git a/arch/riscv/include/asm/v5l2cache.h
> > b/arch/riscv/include/asm/v5l2cache.h
> > new file mode 100644
> > index 000..8ed1c6c
> > --- /dev/null
> > +++ b/arch/riscv/include/asm/v5l2cache.h
>
> Please create arch/riscv/include/asm/arch-ax25/v5l2cache.h. Speaking
> of the name, would it be more readable to name it as v5_l2cache.h? Or
> even add more information to v5, for me, I don't know what v5 stands
> for :)
OK
I will create arch/riscv/include/asm/arch-ax25/v5_l2cache.h
>
> > @@ -0,0 +1,61 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * Copyright (C) 2019 Andes Technology Corporation
> > + * Rick Chen, Andes Technology Corporation
> > + */
> > +
> > +#ifndef _ASM_V5_L2CACHE_H
> > +#define _ASM_V5_L2CACHE_H
> > +
> > +struct l2cache {
> > + volatile u64configure;
>
> checkpatch.pl will report warnings against volatile usage. I think we
> should drop these.
I know that checkpatch.pl will report this warning.
But I still need to add volatile. It help to fix some unpredictable problem.
Without this some driver code flows will be optimized and go wrong somehow.
>
> > + volatile u64control;
> > + volatile u64hpm0;
> > + volatile u64hpm1;
> > + volatile u64hpm2;
> > + volatile u64hpm3;
> > + volatile u64error_status;
> > + volatile u64ecc_error;
> > + volatile u64cctl_command0;
> > + volatile u64cctl_access_line0;
> > + volatile u64cctl_command1;
> > + volatile u64cctl_access_line1;
> > + volatile u64cctl_command2;
> > + volatile u64cctl_access_line2;
> > + volatile u64cctl_command3;
> > + volatile u64cctl_access_line4;
> > + volatile u64cctl_status;
> > +};
> > +
> > +/* Control Register */
> > +#define L2_ENABLE 0x1
> > +/* prefetch */
> > +#define IPREPETCH_OFF 3
> > +#define DPREPETCH_OFF 5
> > +#define IPREPETCH_MSK (3 << IPREPETCH_OFF)
> > +#define DPREPETCH_MSK (3 << DPREPETCH_OFF)
> > +/* tag ram */
> > +#define TRAMOCTL_OFF 8
> > +#define TRAMICTL_OFF 10
> > +#define TRAMOCTL_MSK (3 << TRAMOCTL_OFF)
> > +#define TRAMICTL_MSK BIT(TRAMICTL_OFF)
> > +/* data ram */
> > +#define DRAMOCTL_OFF 11
> > +#define DRAMICTL_OFF 13
> > +#define DRAMOCTL_MSK (3 << DRAMOCTL_OFF)
> > +#define DRAMICTL_MSK BIT(DRAMICTL_OFF)
> > +
> > +/* CCTL Command Register */
> > +#define CCTL_CMD_REG(base, hart) ((ulong)(base) + 0x40 + (hart) *
> > 0x10)
> > +#define L2_WBINVAL_ALL 0x12
> > +
> > +/* CCTL Status Register */
> > +#define CCTL_STATUS_MSK(hart) (0xf << ((hart) * 4))
> > +#define CCTL_STATUS_IDLE(hart) (0 << ((hart) * 4))
> > +#define CCTL_STATUS_PROCESS(hart) (1 << ((hart) * 4))
> > +#define CCTL_STATUS_ILLEGAL(hart) (2 << ((hart) * 4))
> > +
> > +void v5l2_enable(void);
> > +void v5l2_disable(void);
> > +
> > +#endif /* _ASM_V5_L2CACHE_H */
> > diff --git a/drivers/cache/Kconfig b/drivers/cache/Kconfig
> > index 24def7a..665689a 100644
> > --- a/drivers/cache/Kconfig
> > +++ b/drivers/cache/Kconfig
> > @@ -22,4 +22,13 @@ config L2X0_CACHE
> > ARMv7(32-bit) devices. The driver configures the cache settings
> > found in the device tree.
> >
> > +config V5L2_CACHE
> > + tristate "Andes V5L2 cache driver"
>
> This should
Re: [U-Boot] [PATCH] video: meson: hdmi-supply regulator should be optional
On Tue, 4 Jun 2019 22:26:19 +0200 Maxime Jourdan mjour...@baylibre.com wrote: > --- > drivers/video/meson/meson_dw_hdmi.c | 14 ++ > 1 file changed, 10 insertions(+), 4 deletions(-) Applied to u-boot-video/master, thanks! -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] video: meson: hdmi-supply regulator should be optional
On 19/06/04 10:26PM, Maxime Jourdan wrote:
> Some boards don't have such a regulator, and don't need one to enable
> HDMI display. Make it optional, fixing hdmi display for those boards.
>
> Also surround the regulator code with a config check on DM_REGULATOR.
>
> Reported-by: Mohammad Rasim
> Signed-off-by: Maxime Jourdan
> ---
> drivers/video/meson/meson_dw_hdmi.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/meson/meson_dw_hdmi.c
> b/drivers/video/meson/meson_dw_hdmi.c
> index 7a1c060856..483c93f6b6 100644
> --- a/drivers/video/meson/meson_dw_hdmi.c
> +++ b/drivers/video/meson/meson_dw_hdmi.c
> @@ -361,13 +361,19 @@ static int meson_dw_hdmi_probe(struct udevice *dev)
> priv->hdmi.i2c_clk_high = 0x67;
> priv->hdmi.i2c_clk_low = 0x78;
>
> +#if CONFIG_IS_ENABLED(DM_REGULATOR)
> ret = device_get_supply_regulator(dev, "hdmi-supply", );
> - if (ret)
> + if (ret && ret != -ENOENT) {
> + pr_err("Failed to get HDMI regulator\n");
> return ret;
> + }
>
> - ret = regulator_set_enable(supply, true);
> - if (ret)
> - return ret;
> + if (!ret) {
> + ret = regulator_set_enable(supply, true);
> + if (ret)
> + return ret;
> + }
> +#endif
>
> ret = reset_get_bulk(dev, );
> if (ret)
> --
> 2.21.0
>
Tested-by: Mohammad Rasim
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] pinctrl: meson-gxbb: add hdmi related pins
On 19/06/04 10:26PM, Maxime Jourdan wrote:
> The GXBB pinctrl is missing pins related to HDMI, namely hot plug
> detection (hpd) and I2C (sda + scl).
>
> This fixes HDMI support for GXBB in u-boot.
>
> Reported-by: Mohammad Rasim
> Signed-off-by: Maxime Jourdan
> ---
> drivers/pinctrl/meson/pinctrl-meson-gxbb.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
> b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
> index 59b5be6211..9e2e151164 100644
> --- a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
> +++ b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
> @@ -61,6 +61,10 @@ static const unsigned int eth_txd1_pins[] = {
> PIN(GPIOZ_11, EE_OFF) };
> static const unsigned int eth_txd2_pins[]= { PIN(GPIOZ_12, EE_OFF) };
> static const unsigned int eth_txd3_pins[]= { PIN(GPIOZ_13, EE_OFF) };
>
> +static const unsigned int hdmi_hpd_pins[]= { PIN(GPIOH_0, EE_OFF) };
> +static const unsigned int hdmi_sda_pins[]= { PIN(GPIOH_1, EE_OFF) };
> +static const unsigned int hdmi_scl_pins[]= { PIN(GPIOH_2, EE_OFF) };
> +
> static const unsigned int uart_tx_ao_a_pins[]= { PIN(GPIOAO_0, 0) };
> static const unsigned int uart_rx_ao_a_pins[]= { PIN(GPIOAO_1, 0) };
> static const unsigned int uart_cts_ao_a_pins[] = { PIN(GPIOAO_2, 0) };
> @@ -232,6 +236,11 @@ static struct meson_pmx_group
> meson_gxbb_periphs_groups[] = {
> GROUP(eth_txd2, 6, 3),
> GROUP(eth_txd3, 6, 2),
>
> + /* Bank H */
> + GROUP(hdmi_hpd, 1, 26),
> + GROUP(hdmi_sda, 1, 25),
> + GROUP(hdmi_scl, 1, 24),
> +
> /* Bank DV */
> GROUP(uart_tx_b,2, 29),
> GROUP(uart_rx_b,2, 28),
> @@ -351,6 +360,14 @@ static const char * const eth_groups[] = {
> "eth_txd0", "eth_txd1", "eth_txd2", "eth_txd3",
> };
>
> +static const char * const hdmi_hpd_groups[] = {
> + "hdmi_hpd",
> +};
> +
> +static const char * const hdmi_i2c_groups[] = {
> + "hdmi_sda", "hdmi_scl",
> +};
> +
> static const char * const gpio_aobus_groups[] = {
> "GPIOAO_0", "GPIOAO_1", "GPIOAO_2", "GPIOAO_3", "GPIOAO_4",
> "GPIOAO_5", "GPIOAO_6", "GPIOAO_7", "GPIOAO_8", "GPIOAO_9",
> @@ -383,6 +400,8 @@ static struct meson_pmx_func
> meson_gxbb_periphs_functions[] = {
> FUNCTION(uart_b),
> FUNCTION(uart_c),
> FUNCTION(eth),
> + FUNCTION(hdmi_hpd),
> + FUNCTION(hdmi_i2c),
> };
>
> static struct meson_pmx_func meson_gxbb_aobus_functions[] = {
> --
> 2.21.0
>
Tested-by: Mohammad Rasim
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] i2c: designware_i2c: Restore enable state after set speed
Before calling __dw_i2c_set_bus_speed(),
the I2C could already be set as ether enable or disable,
we should restore the original setting instead of enable i2c anyway.
This patch fix a bug happened in init function:
__dw_i2c_init(){
/* Disable i2c */
...
__dw_i2c_set_bus_speed(i2c_base, NULL, speed);
writel(slaveaddr, _base->ic_sar);
/* Enable i2c */
}
In this case, enable i2c inside __dw_i2c_set_bus_speed() function
will cause ic_sar write fail.
Signed-off-by: Jun Chen
---
drivers/i2c/designware_i2c.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
index 9ccc241..d11d47d 100644
--- a/drivers/i2c/designware_i2c.c
+++ b/drivers/i2c/designware_i2c.c
@@ -82,6 +82,7 @@ static unsigned int __dw_i2c_set_bus_speed(struct i2c_regs
*i2c_base,
{
unsigned int cntl;
unsigned int hcnt, lcnt;
+ unsigned int ena;
int i2c_spd;
if (speed >= I2C_MAX_SPEED)
@@ -91,6 +92,9 @@ static unsigned int __dw_i2c_set_bus_speed(struct i2c_regs
*i2c_base,
else
i2c_spd = IC_SPEED_MODE_STANDARD;
+ /* Get enable setting for restore later */
+ ena = readl(_base->ic_enable) & IC_ENABLE_0B;
+
/* to set speed cltr must be disabled */
dw_i2c_enable(i2c_base, false);
@@ -146,8 +150,9 @@ static unsigned int __dw_i2c_set_bus_speed(struct i2c_regs
*i2c_base,
if (scl_sda_cfg)
writel(scl_sda_cfg->sda_hold, _base->ic_sda_hold);
- /* Enable back i2c now speed set */
- dw_i2c_enable(i2c_base, true);
+ /* Restore back i2c now speed set */
+ if (ena == IC_ENABLE_0B)
+ dw_i2c_enable(i2c_base, true);
return 0;
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] riscv: add Kconfig entries for the F and D ISA extensions support
Hi Bin > > Hi Eric, > > On Tue, Jun 4, 2019 at 1:51 PM Eric Lin wrote: > > > > This patch adds Kconfig entries for the F (Single-Precision) > > and D (Double-Precision) floating point instruction-set extensions. > > > > Signed-off-by: Eric Lin > > --- > > Changes for v2: > > - Grammatical correction in commit message "adds" > > - Fixed the config name to indicate both F and D > > > > arch/riscv/Kconfig | 7 +++ > > arch/riscv/Makefile | 12 > > 2 files changed, 15 insertions(+), 4 deletions(-) > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > > index 362f3cdc65..e7a76c67cc 100644 > > --- a/arch/riscv/Kconfig > > +++ b/arch/riscv/Kconfig > > @@ -91,6 +91,13 @@ config RISCV_ISA_C > > when building U-Boot, which results in compressed instructions in > > the > > U-Boot binary. > > > > +config RISCV_ISA_FD > > Again like I said in the v1 patch, I am not in favor of adding such to > U-Boot, but if we have to add such, I think we need add finer control > of single-precision and double-precision via 2 options, one for ISA_F > and one for ISA_D. It's possible that toolchain only supports ISA_F, > although I should say that's a bit weird. > OK, I see. I'll modify the patch as below: +config RISCV_ISA_F + bool "Emit single-precision floating-point instructions" + help + Adds "F" to the ISA subsets that the toolchain is allowed to emit + when building U-Boot, which results in single-precision instructions + in the U-Boot binary. + +config RISCV_ISA_D + bool "Emit double-precision floating-point instructions" + help + Adds "D" to the ISA subsets that the toolchain is allowed to emit + when building U-Boot, which results in double-precision instructions + in the U-Boot binary. ifeq ($(CONFIG_RISCV_ISA_A),y) ARCH_A = a endif +ifeq ($(CONFIG_RISCV_ISA_F),y) + ARCH_F = f + ABI := $(ABI)f +endif +ifeq ($(CONFIG_RISCV_ISA_D),y) + ARCH_D = fd + ABI := $(ABI)d +endif ifeq ($(CONFIG_RISCV_ISA_C),y) ARCH_C = c endif -ARCH_FLAGS = -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_C) -mabi=$(ABI) \ --mcmodel=$(CMODEL) +ARCH_FLAGS = -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_F)$(ARCH_D)$(ARCH_C) -mabi=$(ABI) \ +-mcmodel=$(CMODEL) The ISA_D -march will imply fd > > + bool "Emit Floating-point instructions" > > + help > > + Adds "F" and "D" to the ISA subsets that the toolchain is allowed > > to emit > > + when building U-Boot, which results in Single and > > Double-precision instructions > > + in the U-Boot binary. > > + > > config RISCV_ISA_A > > def_bool y > > > > diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile > > index 0b80eb8d86..5a5c8e75f0 100644 > > --- a/arch/riscv/Makefile > > +++ b/arch/riscv/Makefile > > @@ -5,15 +5,19 @@ > > > > ifeq ($(CONFIG_ARCH_RV64I),y) > > ARCH_BASE = rv64im > > - ABI = lp64 > > + ABI := lp64 > > endif > > ifeq ($(CONFIG_ARCH_RV32I),y) > > ARCH_BASE = rv32im > > - ABI = ilp32 > > + ABI := ilp32 > > endif > > ifeq ($(CONFIG_RISCV_ISA_A),y) > > ARCH_A = a > > endif > > +ifeq ($(CONFIG_RISCV_ISA_FD),y) > > + ARCH_FD = fd > > + ABI := $(ABI)d > > +endif > > ifeq ($(CONFIG_RISCV_ISA_C),y) > > ARCH_C = c > > endif > > @@ -24,8 +28,8 @@ ifeq ($(CONFIG_CMODEL_MEDANY),y) > > CMODEL = medany > > endif > > > > -ARCH_FLAGS = -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_C) -mabi=$(ABI) \ > > --mcmodel=$(CMODEL) > > +ARCH_FLAGS = -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_FD)$(ARCH_C) -mabi=$(ABI) \ > > +-mcmodel=$(CMODEL) > > > > PLATFORM_CPPFLAGS += $(ARCH_FLAGS) > > CFLAGS_EFI += $(ARCH_FLAGS) > > -- > > Regards, > Bin Thanks for your review Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] usb: gadget: f_sdp: Allow SPL to load and boot FIT via SDP
On Tue, 2019-06-04 at 18:56 -0300, Fabio Estevam wrote: > On Tue, Jun 4, 2019 at 5:41 PM Sjoerd Simons > wrote: > > > Small steps right; Ooi what imx_usb_loader configuration/commands > > are > > you using to test this? (I find its config rather tricky to grasp). > > I simply run: > > sudo ./imx_usb SPL > > and then > > sudo ./imx_usb u-boot-dtb.img > > I suggest you to try U-Boot 2019.01 on a mx6sabreauto first. > U-Boot 2019.01 is prior to the DM / fit conversion and loading SPL + > u-boot.img with the method above works fine. Right; I've used that method on a fair few boards but none of those use FIT. For loading the SPL mx6_usb_sdp_spl.conf of imx_usb_loader has: `hid,uboot_header,1024,0x1000,1G,0x00907000,0x31000` So my guess was that it was simply failing as a fit image doesn't have a uboot header ;). I did have a quick look at seeing how to convince imx_usb_loader to upload a FIT image, but failed to do so (hence my question). uuu turned to be simpler to get to comply :) > > One of the next things I will need to look at is actually secure > > boot.. > > That said why does imx_usb_loader if the board isn't locked? > > Not sure what you mean by locked. Sorry closing the device would be the right jargon for i.mx. My point really is, isn't it something to be fixed in imx_usb_loader if it can't upload unsigned FIT images rather then in u-boot? > We have been using imx_usb_loader for a long time. After DM / fit > comvesion the IVT piece is not added into the final .img. > > From the main Makefile: > > ifdef CONFIG_SPL_LOAD_FIT > MKIMAGEFLAGS_u-boot.img = -f auto -A $(ARCH) -T firmware -C none -O > u-boot \ > -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \ > -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" -E \ > $(patsubst %,-b arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) > else > MKIMAGEFLAGS_u-boot.img = -A $(ARCH) -T firmware -C none -O u-boot \ > -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \ > -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" > MKIMAGEFLAGS_u-boot-ivt.img = -A $(ARCH) -T firmware_ivt -C none -O > u-boot \ > -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \ > -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" > u-boot-ivt.img: MKIMAGEOUTPUT = u-boot-ivt.img.log > CLEAN_FILES += u-boot-ivt.img.log u-boot-dtb.imx.log SPL.log u- > boot.imx.log > endif > > we can see that the ivt is not added for the CONFIG_SPL_LOAD_FIT > case. > > I tried to change this logic, but so far was not able to make it > work. Right; Thanks for the pointer -- Sjoerd Simons Collabora Ltd. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] pinctrl: meson-gxbb: add hdmi related pins
On 04/06/2019 22:26, Maxime Jourdan wrote:
> The GXBB pinctrl is missing pins related to HDMI, namely hot plug
> detection (hpd) and I2C (sda + scl).
>
> This fixes HDMI support for GXBB in u-boot.
>
> Reported-by: Mohammad Rasim
> Signed-off-by: Maxime Jourdan
> ---
> drivers/pinctrl/meson/pinctrl-meson-gxbb.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
> b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
> index 59b5be6211..9e2e151164 100644
> --- a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
> +++ b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
> @@ -61,6 +61,10 @@ static const unsigned int eth_txd1_pins[] = {
> PIN(GPIOZ_11, EE_OFF) };
> static const unsigned int eth_txd2_pins[]= { PIN(GPIOZ_12, EE_OFF) };
> static const unsigned int eth_txd3_pins[]= { PIN(GPIOZ_13, EE_OFF) };
>
> +static const unsigned int hdmi_hpd_pins[]= { PIN(GPIOH_0, EE_OFF) };
> +static const unsigned int hdmi_sda_pins[]= { PIN(GPIOH_1, EE_OFF) };
> +static const unsigned int hdmi_scl_pins[]= { PIN(GPIOH_2, EE_OFF) };
> +
> static const unsigned int uart_tx_ao_a_pins[]= { PIN(GPIOAO_0, 0) };
> static const unsigned int uart_rx_ao_a_pins[]= { PIN(GPIOAO_1, 0) };
> static const unsigned int uart_cts_ao_a_pins[] = { PIN(GPIOAO_2, 0) };
> @@ -232,6 +236,11 @@ static struct meson_pmx_group
> meson_gxbb_periphs_groups[] = {
> GROUP(eth_txd2, 6, 3),
> GROUP(eth_txd3, 6, 2),
>
> + /* Bank H */
> + GROUP(hdmi_hpd, 1, 26),
> + GROUP(hdmi_sda, 1, 25),
> + GROUP(hdmi_scl, 1, 24),
> +
> /* Bank DV */
> GROUP(uart_tx_b,2, 29),
> GROUP(uart_rx_b,2, 28),
> @@ -351,6 +360,14 @@ static const char * const eth_groups[] = {
> "eth_txd0", "eth_txd1", "eth_txd2", "eth_txd3",
> };
>
> +static const char * const hdmi_hpd_groups[] = {
> + "hdmi_hpd",
> +};
> +
> +static const char * const hdmi_i2c_groups[] = {
> + "hdmi_sda", "hdmi_scl",
> +};
> +
> static const char * const gpio_aobus_groups[] = {
> "GPIOAO_0", "GPIOAO_1", "GPIOAO_2", "GPIOAO_3", "GPIOAO_4",
> "GPIOAO_5", "GPIOAO_6", "GPIOAO_7", "GPIOAO_8", "GPIOAO_9",
> @@ -383,6 +400,8 @@ static struct meson_pmx_func
> meson_gxbb_periphs_functions[] = {
> FUNCTION(uart_b),
> FUNCTION(uart_c),
> FUNCTION(eth),
> + FUNCTION(hdmi_hpd),
> + FUNCTION(hdmi_i2c),
> };
>
> static struct meson_pmx_func meson_gxbb_aobus_functions[] = {
>
Thanks,
Acked-by: Neil Armstrong
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] video: meson: hdmi-supply regulator should be optional
On 04/06/2019 22:26, Maxime Jourdan wrote:
> Some boards don't have such a regulator, and don't need one to enable
> HDMI display. Make it optional, fixing hdmi display for those boards.
>
> Also surround the regulator code with a config check on DM_REGULATOR.
>
> Reported-by: Mohammad Rasim
> Signed-off-by: Maxime Jourdan
> ---
> drivers/video/meson/meson_dw_hdmi.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/meson/meson_dw_hdmi.c
> b/drivers/video/meson/meson_dw_hdmi.c
> index 7a1c060856..483c93f6b6 100644
> --- a/drivers/video/meson/meson_dw_hdmi.c
> +++ b/drivers/video/meson/meson_dw_hdmi.c
> @@ -361,13 +361,19 @@ static int meson_dw_hdmi_probe(struct udevice *dev)
> priv->hdmi.i2c_clk_high = 0x67;
> priv->hdmi.i2c_clk_low = 0x78;
>
> +#if CONFIG_IS_ENABLED(DM_REGULATOR)
> ret = device_get_supply_regulator(dev, "hdmi-supply", );
> - if (ret)
> + if (ret && ret != -ENOENT) {
> + pr_err("Failed to get HDMI regulator\n");
> return ret;
> + }
>
> - ret = regulator_set_enable(supply, true);
> - if (ret)
> - return ret;
> + if (!ret) {
> + ret = regulator_set_enable(supply, true);
> + if (ret)
> + return ret;
> + }
> +#endif
>
> ret = reset_get_bulk(dev, );
> if (ret)
>
Good catch !
Reviewed-by: Neil Armstrong
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] pinctrl: meson-gx: add support for getting pinmux status
On 04/06/2019 11:04, Neil Armstrong wrote:
In order to support the "pinmux status" command, use the common functions
to get the pins count and names, and add the GX specific function to get
the current function from registers.
Signed-off-by: Neil Armstrong
---
drivers/pinctrl/meson/pinctrl-meson-gx-pmx.c | 44
1 file changed, 44 insertions(+)
diff --git a/drivers/pinctrl/meson/pinctrl-meson-gx-pmx.c
b/drivers/pinctrl/meson/pinctrl-meson-gx-pmx.c
index cf72576b6c..b37b517fe5 100644
--- a/drivers/pinctrl/meson/pinctrl-meson-gx-pmx.c
+++ b/drivers/pinctrl/meson/pinctrl-meson-gx-pmx.c
@@ -72,6 +72,47 @@ static int meson_gx_pinmux_group_set(struct udevice *dev,
return 0;
}
+static int meson_gx_pinmux_get(struct udevice *dev,
+ unsigned int selector,
+ char *buf, int size)
+{
+ struct meson_pinctrl *priv = dev_get_priv(dev);
+ struct meson_pmx_group *group;
+ struct meson_gx_pmx_data *pmx_data;
+ void __iomem *addr;
+ int i, j, pos = 0;
+ unsigned int pin;
+ u32 reg;
+
+ pin = selector + priv->data->pin_base;
+
+ for (i = 0; i < priv->data->num_groups; i++) {
+ group = >data->groups[i];
+ pmx_data = (struct meson_gx_pmx_data *)group->data;
+ if (pmx_data->is_gpio)
+ continue;
+
+ for (j = 0; j < group->num_pins; j++) {
+ if (group->pins[j] == pin) {
+ /* We have found a group using the pin */
+ addr = priv->reg_mux + pmx_data->reg * 4;
+ reg = readl(addr) & BIT(pmx_data->bit);
+ if (reg) {
+ pos += snprintf(buf + pos, size - pos,
+ "%s ", group->name) - 1;
+ return 0;
+ }
+ }
+ }
+ }
+
+ /* Fallback, must be used as GPIO */
+ snprintf(buf, size, "%s or Unknown",
+priv->data->groups[selector].name);
+
+ return 0;
+}
+
const struct pinconf_param meson_gx_pinconf_params[] = {
{ "bias-disable", PIN_CONFIG_BIAS_DISABLE, 0 },
{ "bias-pull-up", PIN_CONFIG_BIAS_PULL_UP, 1 },
@@ -89,6 +130,9 @@ const struct pinctrl_ops meson_gx_pinctrl_ops = {
.pinconf_num_params = ARRAY_SIZE(meson_gx_pinconf_params),
.pinconf_set = meson_pinconf_set,
.pinconf_group_set = meson_pinconf_group_set,
+ .get_pin_name = meson_pinctrl_get_pin_name,
+ .get_pins_count = meson_pinctrl_get_pins_count,
+ .get_pin_muxing = meson_gx_pinmux_get,
};
static const struct dm_gpio_ops meson_gx_gpio_ops = {
Tested-by: Maxime Jourdan
Tested on a ODROID-C2 (gxbb) using the command 'pinmux status -a'
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/18] Add EEPROM-based board detect support for TI K3 SoCs
On 05/06/19 4:38 AM, Andreas Dannenberg wrote: > This is an updated EEPROM-based board detection series that can applied > if staged with other patches in the sequence proposed earlier [1]. > > For completeness here is the proposed sequence again, avoiding merge > conflicts, but this time from the perspective of this patch series. > > Step 1) Faiz' "Add Support for eMMC in Am65x-evm" series [2]. It needs > a small update to actuall allow for eMMC boot I posted earlier. > Step 2) The updated (v2) SYSFW loader series just posted [3] > Step 3) The updated AM654x EEPROM support proposed with this series > Step 4) An updated version of Lokesh's "arm: k3: Allow for exclusive > and shared device requests" series [4]. In addition to a rebase > such an updated series should include updating power domain > properties for devices that were added during the previous > steps. > Step 5) An updated version of Lokesh's "arm: k3: arm64: Initial support > Texas Instrument's J721E Platform" series [5] also adding > in the few lines of codes to leverage SYSFW. > Step 6 & beyond) Various rproc patches, etc. > tested this series on AM654 evm using SD boot. FWIW: Tested-by: Lokesh Vutla Thanks and regards, Lokesh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/12] System Firmware Loader for TI K3 family SoCs
On 05/06/19 4:25 AM, Andreas Dannenberg wrote: > Updated version of the SYSFW loader series for K3 family AM654x devices. > The fundamantal approach of tapping into the SPL loader framework has > been kept for reasons discussed already. The series also still uses > "early BSS" in SPL's board_init_f(). I'm well aware of the concerns > previously brought up regarding this mainly by Simon Glass but I have > not been able to find a better / more universal solution for this yet > (one proposal was to move SYSFW loading into board_init_r() which is not > easily solvable as SYSFW is needed to bring up DDR on K3 SoCs). Long > story short I propose to consider the current proposed approach > nevertheless (as it is also used by other platforms) at least as an > initial step, and then migrate once a better solution is available. tested this series on AM654 evm using SD boot. FWIW: Tested-by: Lokesh Vutla > > I have not yet included support for TI's newest K3 family J721E SoC > which Lokesh posted an initial patch series [5] for due to the > complex dependencies of all the different series we have currently > posted/pending (if I were to add support for J721E which eventually will > be required then the SYSFW loader series would have Lokesh's series as a > pre-requisite as well). > > This being said I would like to propose the following staging sequence > for the different TI K3 SoCs patches currently under review: > > Step 1) Faiz' "Add Support for eMMC in Am65x-evm" series [1]. It needs > a small update to actuall allow for eMMC boot I posted earlier. > Step 2) The SYSFW loader series proposed here > Step 3) An updated version (v3) of the AM654x EEPROM support [3]. > Will post this today. I would like to see the above 3 series be merged first. Will take care of the rest of the J721e support and other. > Step 4) An updated version of Lokesh's "arm: k3: Allow for exclusive > and shared device requests" series. In addition to a rebase > such an updated series should include updating power domain > properties for devices that were added during the previous > steps. > Step 5) An updated version of Lokesh's "arm: k3: arm64: Initial support > Texas Instrument's J721E Platform" series [5] also adding > in the few lines of codes to leverage SYSFW. > Step 6 & beyond) Various rproc patches, etc. I have a slightly different order that you mentioned. Will repost everything once the first 3 steps are sorted out. Thanks and regards, Lokesh > > > The above is to allow for things to build in a logical order while > avoiding merge conflicts. 1+2+3 added will provide a pretty good initial > working U-Boot using eMMC and SD media for AM654x which is a device > available today plus a foundation for everything else, hence it is at > the top of the list. > > > Changes since initial submission: > - Dropped patch "armv7R: dts: k3: am654: Update mmc nodes for loading > sysfw". This is taken care off by the "Add Support for eMMC in > Am65x-evm" patch series [1] which this series was rebased on. > - Replaced patch "spl: Allow skipping clearing BSS during relocation" > with a functionally equivalent patch "spl: Allow performing BSS init > early before board_init_f()" which is a bit more elegant solution > which itself is a slight evolution what previously posted by Simon > Goldschmidt [2] > - Collected various review tags > > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=111723 > [2] https://patchwork.ozlabs.org/patch/1067363/ > [3] https://patchwork.ozlabs.org/project/uboot/list/?series=109266 > [4] https://patchwork.ozlabs.org/project/uboot/list/?series=109163 > [5] https://patchwork.ozlabs.org/project/uboot/list/?series=109296 > > > -- > Andreas Dannenberg > Texas Instruments Inc > > > Andreas Dannenberg (10): > mmc: am654_sdhci: Allow driver to probe without PDs specified > spl: Allow performing BSS init early before board_init_f() > spl: Make image loader infrastructure more universal > arm: K3: Introduce System Firmware loader framework > armV7R: K3: am654: Allow using SPL BSS pre-relocation > armv7R: K3: am654: Use full malloc implementation in SPL > armV7R: K3: am654: Load SYSFW binary and config from boot media > configs: am65x_evm_r5: All sysfw to be loaded via MMC > configs: am65x_hs_evm_r5: All sysfw to be loaded via MMC > configs: am65x_hs_evm: Add Support for eMMC boot > > Faiz Abbas (2): > configs: am65x_evm: Add Support for eMMC boot > am65x: README: Add eMMC layout and flash instructions > > arch/arm/lib/crt0.S | 53 ++-- > arch/arm/mach-k3/Kconfig | 39 +++ > arch/arm/mach-k3/Makefile| 3 + > arch/arm/mach-k3/am6_init.c | 27 +- > arch/arm/mach-k3/include/mach/sysfw-loader.h | 12 + > arch/arm/mach-k3/sysfw-loader.c | 260 +++ > board/ti/am65x/Kconfig
