[U-Boot] [PATCH 1/1] efi_add_handle() - description of efi_add_handle()
Correct the comments describing function efi_add_handle(). Signed-off-by: Heinrich Schuchardt --- lib/efi_loader/efi_boottime.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c index 601b0a2cb8..cbf912f72b 100644 --- a/lib/efi_loader/efi_boottime.c +++ b/lib/efi_loader/efi_boottime.c @@ -423,10 +423,12 @@ static efi_status_t EFIAPI efi_free_pool_ext(void *buffer) } /** - * efi_add_handle() - add a new object to the object list - * @obj: object to be added + * efi_add_handle() - add a new handle to the object list * - * The protocols list is initialized. The object handle is set. + * @handle:handle to be added + * + * The protocols list is initialized. The handle is added to the list of known + * UEFI objects. */ void efi_add_handle(efi_handle_t handle) { -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/1] efi_loader: description of efi_add_handle()
Correct the comments describing function efi_add_handle(). Signed-off-by: Heinrich Schuchardt --- v2 title should start with efi_loader --- lib/efi_loader/efi_boottime.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c index 601b0a2cb8..cbf912f72b 100644 --- a/lib/efi_loader/efi_boottime.c +++ b/lib/efi_loader/efi_boottime.c @@ -423,10 +423,12 @@ static efi_status_t EFIAPI efi_free_pool_ext(void *buffer) } /** - * efi_add_handle() - add a new object to the object list - * @obj: object to be added + * efi_add_handle() - add a new handle to the object list * - * The protocols list is initialized. The object handle is set. + * @handle:handle to be added + * + * The protocols list is initialized. The handle is added to the list of known + * UEFI objects. */ void efi_add_handle(efi_handle_t handle) { -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v2] fit: Support compression for non-kernel components (e.g. FDT)
On 01.05.19 00:34, Julius Werner wrote: On Tue, Apr 30, 2019 at 11:25 AM Simon Goldschmidt wrote: Am 18.04.2019 um 23:08 schrieb Julius Werner: This patch adds support for compressing non-kernel image nodes in a FIT image (kernel nodes could already be compressed previously). This can reduce the size of FIT images and therefore improve boot times (especially when an image bundles many different kernel FDTs). The images will automatically be decompressed on load. This patch does not support extracting compatible strings from compressed FDTs, so it's not very helpful in conjunction with CONFIG_FIT_BEST_MATCH yet, but it can already be used in environments that select the configuration to load explicitly. Signed-off-by: Julius Werner --- common/image-fit.c | 83 +++--- 1 file changed, 49 insertions(+), 34 deletions(-) diff --git a/common/image-fit.c b/common/image-fit.c index ac901e131c..006e828b79 100644 --- a/common/image-fit.c +++ b/common/image-fit.c @@ -22,6 +22,7 @@ DECLARE_GLOBAL_DATA_PTR; #endif /* !USE_HOSTCC*/ +#include #include #include #include @@ -1576,6 +1577,13 @@ int fit_conf_find_compat(const void *fit, const void *fdt) kfdt_name); continue; } + + if (!fit_image_check_comp(fit, kfdt_noffset, IH_COMP_NONE)) { + debug("Can't extract compat from \"%s\" (compressed)\n", + kfdt_name); + continue; + } + What's this block good for in this patch? Looks like it belongs to 2/2? This is necessary because I'm removing the (image_type == IH_TYPE_FLATDT && !fit_image_check_comp(fit, noffset, IH_COMP_NONE)) check below. Previously, this function would just always hard fail with compressed FDTs. With this patch, compressed FDTs can be loaded, but they can't be used for compat string matching -- that's why I need to add this check here to prevent it. You can still use compressed FDTs when selecting a configuration explicitly (e.g. bootm 0x100#conf@1). The next patch will then add another feature that makes it possible to have compat string matching with compressed FDTs. Oh, ok. Guess I was just surprised that it says "can't extract compat" when it tries to check "comp"... /* * Get a pointer to this configuration's fdt. */ @@ -1795,11 +1803,12 @@ int fit_image_load(bootm_headers_t *images, ulong addr, const char *fit_uname_config; const char *fit_base_uname_config; const void *fit; - const void *buf; + void *buf; + void *loadbuf; size_t size; int type_ok, os_ok; - ulong load, data, len; - uint8_t os; + ulong load, load_end, data, len; + uint8_t os, comp; #ifndef USE_HOSTCC uint8_t os_arch; #endif @@ -1895,12 +1904,6 @@ int fit_image_load(bootm_headers_t *images, ulong addr, images->os.arch = os_arch; #endif - if (image_type == IH_TYPE_FLATDT && - !fit_image_check_comp(fit, noffset, IH_COMP_NONE)) { - puts("FDT image is compressed"); - return -EPROTONOSUPPORT; - } - bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ALL); type_ok = fit_image_check_type(fit, noffset, image_type) || fit_image_check_type(fit, noffset, IH_TYPE_FIRMWARE) || @@ -1931,7 +1934,8 @@ int fit_image_load(bootm_headers_t *images, ulong addr, bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ALL_OK); /* get image data address and length */ - if (fit_image_get_data_and_size(fit, noffset, &buf, &size)) { + if (fit_image_get_data_and_size(fit, noffset, + (const void **)&buf, &size)) { printf("Could not find %s subimage data!\n", prop_name); bootstage_error(bootstage_id + BOOTSTAGE_SUB_GET_DATA); return -ENOENT; @@ -1939,30 +1943,15 @@ int fit_image_load(bootm_headers_t *images, ulong addr, #if !defined(USE_HOSTCC) && defined(CONFIG_FIT_IMAGE_POST_PROCESS) /* perform any post-processing on the image data */ - board_fit_image_post_process((void **)&buf, &size); + board_fit_image_post_process(&buf, &size); #endif len = (ulong)size; - /* verify that image data is a proper FDT blob */ - if (image_type == IH_TYPE_FLATDT && fdt_check_header(buf)) { - puts("Subimage data is not a FDT"); - return -ENOEXEC; - } - bootstage_mark(bootstage_id + BOOTSTAGE_SUB_GET_DATA_OK); - /* - * Work-around for eldk-4.2 which gives this warning if we try to - * cast in the unmap_sysmem() call: - * warning: initialization discards qualifiers from pointer target type - */ - { - void *vbuf = (void *)buf; - - data = map_to_sysmem(vbuf); - } - + data = map_to_sysmem(buf); + load = data;
Re: [U-Boot] [PATCH v2 3/4] watchdog: stm32mp: Add watchdog driver
On 30.04.19 17:26, Patrice Chotard wrote: This patch adds IWDG (Independent WatchDoG) support for STM32MP platform. Signed-off-by: Christophe Kerello Signed-off-by: Patrice Chotard --- Changes in v2: - Rename timeout variable in timeout_ms in stm32mp_wdt_start() 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] [PATCH v2 2/2] RISCV: image: Parse Image.gz support in booti.
On 5/1/19 12:06 AM, Atish Patra wrote: > On 4/30/19 2:42 PM, Marek Vasut wrote: >> On 4/30/19 10:38 PM, Atish Patra wrote: >>> On 4/30/19 12:11 PM, Marek Vasut wrote: On 4/30/19 8:13 PM, Atish Patra wrote: > On 4/30/19 2:52 AM, Marek Vasut wrote: >> On 4/30/19 3:27 AM, Atish Patra wrote: >> >> [...] >> > Yes. FIT image parsing can be done in that way. However, the idea > was > here to load Image.gz directly. Image.gz is default compressed > Linux > kernel image format in RISC-V. Sigh, and the image header is compressed as well, so there's no way to identify the image format, right ? And there's no decompressor, so the dcompressing has to be done by bootloader, which would need some sort of very smart way of figuring out which exact compression method is used ? >>> Yes. Image.gz is always gunzip. So checking first two bytes is >>> enough to >>> confirm that it is a gz file. >> >> What happens once people start feeding it more exotic compression >> methods, like LZ4 or LZO or LZMA for example ? >> > > booti command help will clearly state that it can only boot kernel > from > Image or Image.gz. > > static char booti_help_text[] = > "[addr [initrd[:size]] [fdt]]\n" > - " - boot arm64 Linux Image stored in memory\n" > + " - boot arm64 Linux Image or riscv Linux Image/Image.gz > stored > in memory\n" Obvious question -- does this Image.gz stuff apply to arm64 ? >>> >>> arm64 builds Image.gz but booti for arm64 doesn't use it. I guess >>> Image.gz can be used in FIT image for ARM64 but I am not sure which >>> platform actually uses it. >>> >>> This patch only enables support for RISC-V. >> >> Can't this be made generic ? >> > > I think so if I just move the gzip detection and decompression code to > cmd/booti.c. > > I will update the v3 patch with this. Nice, thanks. But since you're basically implementing file(1)-lite, I wonder whether there isn't similar code somewhere in u-boot already. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] mtd: spi-nor: fix page program issue when using spi-mem driver
Hi Weijie, > 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 > --- > drivers/mtd/spi/spi-nor-core.c | 27 --- > 1 file changed, 8 insertions(+), 19 deletions(-) > > diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c > index c4e2f6a..1acff74 100644 > --- a/drivers/mtd/spi/spi-nor-core.c > +++ b/drivers/mtd/spi/spi-nor-core.c > @@ -116,7 +116,6 @@ static ssize_t spi_nor_write_data(struct spi_nor *nor, > loff_t to, size_t len, >SPI_MEM_OP_ADDR(nor->addr_width, to, 1), >SPI_MEM_OP_NO_DUMMY, >SPI_MEM_OP_DATA_OUT(len, buf, 1)); > - size_t remaining = len; > int ret; > > /* get transfer protocols. */ > @@ -127,22 +126,16 @@ static ssize_t spi_nor_write_data(struct spi_nor *nor, > loff_t to, size_t len, > if (nor->program_opcode == SPINOR_OP_AAI_WP && nor->sst_write_second) > op.addr.nbytes = 0; > > - while (remaining) { > - op.data.nbytes = remaining < UINT_MAX ? remaining : UINT_MAX; > - ret = spi_mem_adjust_op_size(nor->spi, &op); > - if (ret) > - return ret; > - > - ret = spi_mem_exec_op(nor->spi, &op); > - if (ret) > - return ret; > + ret = spi_mem_adjust_op_size(nor->spi, &op); > + if (ret) > + return ret; > + op.data.nbytes = len < op.data.nbytes ? len : op.data.nbytes; > > - op.addr.val += op.data.nbytes; > - remaining -= op.data.nbytes; > - op.data.buf.out += op.data.nbytes; > - } > + ret = spi_mem_exec_op(nor->spi, &op); > + if (ret) > + return ret; > > - return len; > + return op.data.nbytes; > } > > /* > @@ -1101,10 +1094,6 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t > to, size_t len, > goto write_err; > *retlen += written; > i += written; > - if (written != page_remain) { > - ret = -EIO; > - goto write_err; > - } > } > I've tested it on Zynq MicroZed board and it is working, so Tested-by: Shyam Saini ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] net: mscc: luton: Update network driver for pcb90
Update Luton network driver to have support also for pcb90. The pcb90 has 24 ports from which 12 ports are connected to SerDes6G. Signed-off-by: Horatiu Vultur --- drivers/net/mscc_eswitch/Makefile | 2 +- drivers/net/mscc_eswitch/luton_switch.c | 415 2 files changed, 258 insertions(+), 159 deletions(-) diff --git a/drivers/net/mscc_eswitch/Makefile b/drivers/net/mscc_eswitch/Makefile index 9c208d1..02f39a7 100644 --- a/drivers/net/mscc_eswitch/Makefile +++ b/drivers/net/mscc_eswitch/Makefile @@ -1,6 +1,6 @@ obj-$(CONFIG_MSCC_OCELOT_SWITCH) += ocelot_switch.o mscc_xfer.o mscc_mac_table.o -obj-$(CONFIG_MSCC_LUTON_SWITCH) += luton_switch.o mscc_miim.o mscc_xfer.o mscc_mac_table.o +obj-$(CONFIG_MSCC_LUTON_SWITCH) += luton_switch.o mscc_xfer.o mscc_mac_table.o obj-$(CONFIG_MSCC_JR2_SWITCH) += jr2_switch.o mscc_xfer.o obj-$(CONFIG_MSCC_SERVALT_SWITCH) += servalt_switch.o mscc_xfer.o obj-$(CONFIG_MSCC_SERVAL_SWITCH) += serval_switch.o mscc_xfer.o mscc_mac_table.o diff --git a/drivers/net/mscc_eswitch/luton_switch.c b/drivers/net/mscc_eswitch/luton_switch.c index 6667614..94852b0 100644 --- a/drivers/net/mscc_eswitch/luton_switch.c +++ b/drivers/net/mscc_eswitch/luton_switch.c @@ -15,10 +15,21 @@ #include #include -#include "mscc_miim.h" #include "mscc_xfer.h" #include "mscc_mac_table.h" +#define GCB_MIIM_MII_STATUS0x0 +#defineGCB_MIIM_STAT_BUSY BIT(3) +#define GCB_MIIM_MII_CMD 0x8 +#defineGCB_MIIM_MII_CMD_OPR_WRITE BIT(1) +#defineGCB_MIIM_MII_CMD_OPR_READ BIT(2) +#defineGCB_MIIM_MII_CMD_WRDATA(x) ((x) << 4) +#defineGCB_MIIM_MII_CMD_REGAD(x) ((x) << 20) +#defineGCB_MIIM_MII_CMD_PHYAD(x) ((x) << 25) +#defineGCB_MIIM_MII_CMD_VLDBIT(31) +#define GCB_MIIM_DATA 0xC +#defineGCB_MIIM_DATA_ERROR (0x2 << 16) + #define ANA_PORT_VLAN_CFG(x) (0x00 + 0x80 * (x)) #defineANA_PORT_VLAN_CFG_AWARE_ENA BIT(20) #defineANA_PORT_VLAN_CFG_POP_CNT(x)((x) << 18) @@ -136,61 +147,53 @@ #define PGID_UNICAST 29 #define PGID_SRC 80 -enum luton_target { - PORT0, - PORT1, - PORT2, - PORT3, - PORT4, - PORT5, - PORT6, - PORT7, - PORT8, - PORT9, - PORT10, - PORT11, - PORT12, - PORT13, - PORT14, - PORT15, - PORT16, - PORT17, - PORT18, - PORT19, - PORT20, - PORT21, - PORT22, - PORT23, - SYS, +static const char * const regs_names[] = { + "port0", "port1", "port2", "port3", "port4", "port5", "port6", "port7", + "port8", "port9", "port10", "port11", "port12", "port13", "port14", + "port15", "port16", "port17", "port18", "port19", "port20", "port21", + "port22", "port23", + "sys", "ana", "rew", "gcb", "qs", "hsio", +}; + +#define REGS_NAMES_COUNT ARRAY_SIZE(regs_names) + 1 +#define MAX_PORT 24 + +enum luton_ctrl_regs { + SYS = MAX_PORT, ANA, REW, GCB, QS, - HSIO, - TARGET_MAX, + HSIO }; -#define MAX_PORT (PORT23 - PORT0 + 1) +#define MIN_INT_PORT 0 +#define PORT10 10 +#define PORT11 11 +#define MAX_INT_PORT 12 +#define MIN_EXT_PORT MAX_INT_PORT +#define MAX_EXT_PORT MAX_PORT -#define MIN_INT_PORT PORT0 -#define MAX_INT_PORT (PORT11 - PORT0 + 1) -#define MIN_EXT_PORT PORT12 -#define MAX_EXT_PORT MAX_PORT +#define LUTON_MIIM_BUS_COUNT 2 -enum luton_mdio_target { - MIIM, - TARGET_MDIO_MAX, +struct luton_phy_port_t { + size_t phy_addr; + struct mii_dev *bus; + u8 serdes_index; + u8 phy_mode; }; -enum luton_phy_id { - INTERNAL, - EXTERNAL, - NUM_PHY, +struct luton_private { + void __iomem *regs[REGS_NAMES_COUNT]; + struct mii_dev *bus[LUTON_MIIM_BUS_COUNT]; + struct luton_phy_port_t ports[MAX_PORT]; }; -struct luton_private { - void __iomem *regs[TARGET_MAX]; - struct mii_dev *bus[NUM_PHY]; +struct mscc_miim_dev { + void __iomem *regs; + phys_addr_t miim_base; + unsigned long miim_size; + struct mii_dev *bus; }; static const unsigned long luton_regs_qs[] = { @@ -207,53 +210,85 @@ static const unsigned long luton_regs_ana_table[] = { [MSCC_ANA_TABLES_MACACCESS] = 0x11b8, }; -static struct mscc_miim_dev miim[NUM_PHY]; +static struct mscc_miim_dev miim[LUTON_MIIM_BUS_COUNT]; +static int miim_count = -1; -static struct mii_dev *luton_mdiobus_init(struct udevice *dev, - int mdiobus_id) +static int mscc_miim_wait_ready(struct mscc_miim_dev *miim) +{ + return wait_f
[U-Boot] [PATCH 0/3] Update Luton network driver
Update Luton network driver to add support for all the ports on pcb90. The existing support is only for first 12 ports, with this patch adds support for another 12 ports. This patch series is based on u-boot-mips/master. Horatiu Vultur (3): net: mscc: luton: Update network driver for pcb90 board: mscc: luton: Update MSCC Luton board net: mscc: ocelot: Update DTS for Luton pcb90 arch/mips/dts/luton_pcb090.dts | 228 ++ arch/mips/dts/luton_pcb091.dts | 132 ++ arch/mips/dts/mscc,luton.dtsi | 126 ++ board/mscc/luton/luton.c| 13 +- drivers/net/mscc_eswitch/Makefile | 2 +- drivers/net/mscc_eswitch/luton_switch.c | 415 include/dt-bindings/mscc/luton_data.h | 17 ++ 7 files changed, 576 insertions(+), 357 deletions(-) create mode 100644 include/dt-bindings/mscc/luton_data.h -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] board: mscc: luton: Update MSCC Luton board
Implement method board_phy_config to configure the external phys on the pcb90. Signed-off-by: Horatiu Vultur --- board/mscc/luton/luton.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/board/mscc/luton/luton.c b/board/mscc/luton/luton.c index 807c717..114f7fd 100644 --- a/board/mscc/luton/luton.c +++ b/board/mscc/luton/luton.c @@ -6,8 +6,7 @@ #include #include #include - -DECLARE_GLOBAL_DATA_PTR; +#include enum { BOARD_TYPE_PCB090 = 0xAABBCD00, @@ -36,6 +35,16 @@ int board_early_init_r(void) return 0; } +int board_phy_config(struct phy_device *phydev) +{ + phy_write(phydev, 0, 31, 0x10); + phy_write(phydev, 0, 18, 0x80A0); + while (phy_read(phydev, 0, 18) & 0x8000) + ; + phy_write(phydev, 0, 31, 0); + return 0; +} + static void do_board_detect(void) { u32 chipid = (readl(BASE_DEVCPU_GCB + CHIP_ID) >> 12) & 0x; -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] net: mscc: ocelot: Update DTS for Luton pcb90
Update device tree for luton to add support for luton pcb90. This pcb has 24 ports from which 12 ports are connected to SerDes6G. Signed-off-by: Horatiu Vultur --- arch/mips/dts/luton_pcb090.dts| 228 +++--- arch/mips/dts/luton_pcb091.dts| 132 +--- arch/mips/dts/mscc,luton.dtsi | 126 +++ include/dt-bindings/mscc/luton_data.h | 17 +++ 4 files changed, 307 insertions(+), 196 deletions(-) create mode 100644 include/dt-bindings/mscc/luton_data.h diff --git a/arch/mips/dts/luton_pcb090.dts b/arch/mips/dts/luton_pcb090.dts index fe457ba..ea3e3b7 100644 --- a/arch/mips/dts/luton_pcb090.dts +++ b/arch/mips/dts/luton_pcb090.dts @@ -5,6 +5,7 @@ /dts-v1/; #include "mscc,luton.dtsi" +#include / { model = "Luton26 PCB090 Reference Board"; @@ -57,52 +58,195 @@ &mdio0 { status = "okay"; -}; - -&port0 { - phy-handle = <&phy0>; -}; - -&port1 { - phy-handle = <&phy1>; -}; - -&port2 { - phy-handle = <&phy2>; -}; - -&port3 { - phy-handle = <&phy3>; -}; - -&port4 { - phy-handle = <&phy4>; -}; - -&port5 { - phy-handle = <&phy5>; -}; - -&port6 { - phy-handle = <&phy6>; -}; - -&port7 { - phy-handle = <&phy7>; -}; -&port8 { - phy-handle = <&phy8>; + phy0: ethernet-phy@0 { + reg = <0>; + }; + phy1: ethernet-phy@1 { + reg = <1>; + }; + phy2: ethernet-phy@2 { + reg = <2>; + }; + phy3: ethernet-phy@3 { + reg = <3>; + }; + phy4: ethernet-phy@4 { + reg = <4>; + }; + phy5: ethernet-phy@5 { + reg = <5>; + }; + phy6: ethernet-phy@6 { + reg = <6>; + }; + phy7: ethernet-phy@7 { + reg = <7>; + }; + phy8: ethernet-phy@8 { + reg = <8>; + }; + phy9: ethernet-phy@9 { + reg = <9>; + }; + phy10: ethernet-phy@10 { + reg = <10>; + }; + phy11: ethernet-phy@11 { + reg = <11>; + }; }; -&port9 { - phy-handle = <&phy9>; -}; +&mdio1 { + status = "okay"; -&port10 { - phy-handle = <&phy10>; + phy12: ethernet-phy@12 { + reg = <0>; + }; + phy13: ethernet-phy@13 { + reg = <1>; + }; + phy14: ethernet-phy@14 { + reg = <2>; + }; + phy15: ethernet-phy@15 { + reg = <3>; + }; + phy16: ethernet-phy@16 { + reg = <4>; + }; + phy17: ethernet-phy@17 { + reg = <5>; + }; + phy18: ethernet-phy@18 { + reg = <6>; + }; + phy19: ethernet-phy@19 { + reg = <7>; + }; + phy20: ethernet-phy@20 { + reg = <8>; + }; + phy21: ethernet-phy@21 { + reg = <9>; + }; + phy22: ethernet-phy@22 { + reg = <10>; + }; + phy23: ethernet-phy@23 { + reg = <11>; + }; }; -&port11 { - phy-handle = <&phy11>; +&switch { + ethernet-ports { + port0: port@0 { + reg = <0>; + phy-handle = <&phy0>; + }; + port1: port@1 { + reg = <1>; + phy-handle = <&phy1>; + }; + port2: port@2 { + reg = <2>; + phy-handle = <&phy2>; + }; + port3: port@3 { + reg = <3>; + phy-handle = <&phy3>; + }; + port4: port@4 { + reg = <4>; + phy-handle = <&phy4>; + }; + port5: port@5 { + reg = <5>; + phy-handle = <&phy5>; + }; + port6: port@6 { + reg = <6>; + phy-handle = <&phy6>; + }; + port7: port@7 { + reg = <7>; + phy-handle = <&phy7>; + }; + port8: port@8 { + reg = <8>; + phy-handle = <&phy8>; + }; + port9: port@9 { + reg = <9>; + phy-handle = <&phy9>; + }; + port10: port@10 { + reg = <10>; + phy-handle = <&phy10>; + }; + port11: port@11 { + reg = <11>; + phy-handle = <&phy11>; + }; + port12: port@12 { + reg = <12>; + phy-handle = <&phy12>; + phys = <&serdes_hsio 12 SERDES6G(1) PHY_MODE_QSG
Re: [U-Boot] Pull request: u-boot-imx u-boot-imx-20190426
On Tue, Apr 30, 2019 at 06:09:59PM +0200, Stefano Babic wrote: > Hi Tom, > > next chunk of patches, another big chunk will follow. Please pull from > u-boot-imx, thanks ! > > Travis: 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 2/2] ti: Add am335x-pocketbeagle to am335x_evm_defconfig.
On Mon, Apr 29, 2019 at 04:12:30PM -0700, Vagrant Cascadian wrote: > Add am335x-pocketbeagle to CONFIG_OF_LIST in am335x_evm_defconfig. > > Signed-off-by: Vagrant Cascadian Reviewed-by: Tom Rini -- 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 02/50] binman: Don't show image-skip message by default
On Fri, Apr 26, 2019 at 11:59 AM Simon Glass wrote: > > This message is not very important since it is simply indicating that the > user's instructions are being followed. Only show it when the verbosity > level is above the default. > > Also drop the unnecessary extra newline on this message, which causes two > line breaks. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Update commit message to mention dropping the \n > - Update testSelectImage() to test in normal and verbose modes > > tools/binman/control.py | 4 ++-- > tools/binman/ftest.py | 26 +++--- > 2 files changed, 21 insertions(+), 9 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 v2 05/50] cros_ec: Use a hyphen in the uclass name
Hi Simon, On Fri, Apr 26, 2019 at 11:59 AM Simon Glass wrote: > > Device-tree rules require that aliases use a hyphen rather than a > underscore. Update the uclass name to fit with this. > > This allows device-tree aliases to be used to refer to cros-ec devices, > for example: > > aliases { > cros-ec0 = &ec; > cros-ec1 = &pd; > }; Thanks for adding the explanation here. But I was wondering since this is required by DT rules for the aliases node, do we have to require all UCLASS_DRIVERs to have name with hyphen instead of underscore? > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Update the commit message to explain the implications on aliases > > drivers/misc/cros_ec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/50] spl: Allow sandbox to build a device-tree file
On Fri, Apr 26, 2019 at 11:59 AM Simon Glass wrote: > > At present only OF_SEPARATE is considered valid for building a device-tree > file in SPL. However sandbox uses OF_HOSTFILE instead. Update the logic to > handle this and make it easier to understand. > > Note that the new logic is not quite the same as the old logic. It was > previously assumed that checking for: > >$(CONFIG_$(SPL_TPL_)OF_CONTROL) >$(CONFIG_OF_SEPARATE) >$(CONFIG_$(SPL_TPL_)OF_PLATDATA) > > producing 'yy' meant that the first two were 'y' and the last was empty. > Strictly speaking it would be possible for any two of the three to be 'y' > and still yield the same result. However, that was not the intention of > the new logic, since OF_PLATDATA always ensures that no device-tree file > is included. So in effect the new logic is the same, with the addition of > OF_HOSTFILE as an option for OP_SEPARATE. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Add a better explanation of the logic change, in the commit message > > scripts/Makefile.spl | 14 +- > 1 file changed, 13 insertions(+), 1 deletion(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 07/50] binman: Allow sections to have an offset
On Fri, Apr 26, 2019 at 11:59 AM Simon Glass wrote: > > At present sections are always placed automatically. Even if an 'offset' > property is provided it is ignored. Update the logic to support an offset > for sections. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Fix map output when section offset is not set (make it 0) > - Add a test for sections with offsets > > tools/binman/README | 7 + > tools/binman/bsection.py | 9 +++--- > tools/binman/etype/section.py | 3 +- > tools/binman/ftest.py | 18 > tools/binman/test/101_sections_offset.dts | 35 +++ > 5 files changed, 67 insertions(+), 5 deletions(-) > create mode 100644 tools/binman/test/101_sections_offset.dts > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Booting imx_4.14.98_2.0.0_ga on i.MX8QM MEK Board
Hi Peng, Stefano and Fabio We are currently trying to boot the Linux kernel from NXP's downstream Linux BSP 4.14.98_2.0.0_ga with mainline U-Boot. However, that currently seems to crash as follows: ... [1.563380] 5a09.serial: ttyLP3 at MMIO 0x5a090010 (irq = 72, base_baud = 500) is a FSL_LPUART [1.575723] arm-smmu 5140.iommu: probing hardware configuration... [1.582278] arm-smmu 5140.iommu: SMMUv2 with: [1.586993] Synchronous External Abort: synchronous external abort (0x96000210) at 0x0fa40020 [1.596233] Internal error: : 96000210 [#1] PREEMPT SMP [1.601458] Modules linked in: [1.604521] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.14.98- imx_4.14.98_2.0.0_ga+g5d6cbea #1 [1.613132] Hardware name: Freescale i.MX8QM MEK (DT) [1.618180] task: 8008f6c98000 task.stack: 08068000 [1.624119] PC is at arm_smmu_device_probe+0x334/0xc58 [1.629256] LR is at arm_smmu_device_probe+0x334/0xc58 [1.634399] pc : [] lr : [] pstate: 4045 [1.641792] sp : 0806bbf0 [1.645100] x29: 0806bbf0 x28: 094dab58 [1.650417] x27: 0007 x26: 093b046c [1.655733] x25: x24: [1.661050] x23: 0fa40020 x22: 8008f72e3410 [1.666367] x21: 0021 x20: 0fa4 [1.671684] x19: 8008f78e3218 x18: 0010 [1.677000] x17: 0001 x16: [1.682308] x15: x14: 896a5547 [1.687625] x13: 096a x12: 094f8df8 [1.692942] x11: 086373a0 x10: 0806b850 [1.698259] x9 : 0006 x8 : 203276554d4d5320 [1.703575] x7 : 3a756d6d6f692e30 x6 : 00e4 [1.708892] x5 : x4 : [1.714209] x3 : x2 : 09512f68 [1.719526] x1 : 8008f6c98000 x0 : 0025 [1.724845] Process swapper/0 (pid: 1, stack limit = 0x08068000) [1.731545] Call trace: [1.733994] Exception stack(0x0806bab0 to 0x0806bbf0) [1.740441] baa0: 0025 8008f6c98000 [1.748275] bac0: 09512f68 [1.756111] bae0: 00e4 3a756d6d6f692e30 203276554d4d5320 0006 [1.763947] bb00: 0806b850 086373a0 094f8df8 096a [1.771783] bb20: 896a5547 0001 [1.779619] bb40: 0010 8008f78e3218 0fa4 0021 [1.787458] bb60: 8008f72e3410 0fa40020 [1.795292] bb80: 093b046c 0007 094dab58 0806bbf0 [1.803130] bba0: 0865108c 0806bbf0 0865108c 4045 [1.810964] bbc0: 0002 [1.818799] bbe0: 0806bbf0 0865108c [1.823678] [] arm_smmu_device_probe+0x334/0xc58 [1.829867] [] platform_drv_probe+0x58/0xb8 [1.835612] [] driver_probe_device+0x210/0x2d0 [1.841624] [] __driver_attach+0xbc/0xc0 [1.847117] [] bus_for_each_dev+0x4c/0x98 [1.852691] [] driver_attach+0x20/0x28 [1.858001] [] bus_add_driver+0x1b8/0x228 [1.863575] [] driver_register+0x60/0xf8 [1.869057] [] __platform_driver_register+0x40/0x48 [1.875502] [] arm_smmu_driver_init+0x1c/0x24 [1.881424] [] do_one_initcall+0x38/0x128 [1.887004] [] kernel_init_freeable+0x188/0x22c [1.893102] [] kernel_init+0x10/0x108 [1.898325] [] ret_from_fork+0x10/0x18 [1.903637] Code: 911ac021 1a9f17e2 11000442 94020db0 (b94002f7) [1.909748] ---[ end trace c4668f185ae22c3f ]--- [1.914394] Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b [1.914394] [1.923532] SMP: stopping secondary CPUs [1.927458] Kernel Offset: disabled [1.930950] CPU features: 0x180200c [1.934441] Memory Limit: none [1.937501] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b [1.937501] Does any of you know what exactly could be going on? BTW: The exact same crash is observed on Apalis iMX8 as well, while both the i.MX8QXP MEK as well as Colibri iMX8QXP boot that same downstream Linux kernel just fine. Must be something i.MX 8QuadMax specific... Cheers Marcel ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 17/50] x86: broadwell: Allow SDRAM init from SPL
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > At present, for broadwell, SDRAM is always set up in U-Boot proper since > the 64-bit mode (which uses SDRAM init in SPL) is not supported. > > Update the code to allow SDRAM init in SPL instead so that U-Boot proper > can be loaded into SDRAM and run from there. This allows U-Boot to be > compressed to reduce space, since it is not necessary to run it directly > from flash. It could later allow us to support 64-bit U-Boot on broadwell. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Update commit message to make it clear this patch is just for broadwell > - Bring in sdram_console_tx_byte() to allow debugging > > arch/x86/cpu/broadwell/Makefile | 2 +- > arch/x86/cpu/broadwell/northbridge.c | 100 +++ > arch/x86/cpu/broadwell/sdram.c | 93 - > 3 files changed, 101 insertions(+), 94 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 v2 20/50] x86: Add support for starting from SPL/TPL
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > When a previous phase of U-Boot has run we need to adjust the init of > subsequent states to avoid messing up the CPU state. > > Add a new version of the start logic for SPL, when it boots from TPL > (start_from tpl.c) and a new version for U-Boot when it boots from SPL. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Add xorl to TPL code also > - Update comments in start_from_tpl to correctly explain SPL state > > arch/x86/Makefile | 12 ++ > arch/x86/cpu/Makefile | 15 +++- > arch/x86/cpu/start_from_spl.S | 71 +++ > arch/x86/cpu/start_from_tpl.S | 49 > 4 files changed, 146 insertions(+), 1 deletion(-) > create mode 100644 arch/x86/cpu/start_from_spl.S > create mode 100644 arch/x86/cpu/start_from_tpl.S > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/10] rockchip: enable DEBUG_UART_BOARD_INIT by default
> All Rockchip SoCs use DEBUG_UART_BOARD_INIT to init per board > UART IOMUX, enable it by default. > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > --- > > arch/arm/Kconfig | 1 + > arch/arm/mach-rockchip/Kconfig | 4 > 2 files changed, 1 insertion(+), 4 deletions(-) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/10] rockchip; kylin-rk3036: enabl DEBUG UART
> Enable debug uart for kylin board in defconfig. > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > --- > > configs/kylin-rk3036_defconfig | 4 > 1 file changed, 4 insertions(+) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/10] rockchip: rk3188: add board_debug_uart_init()
> Use board_debug_uart_init() for UART iomux init instead of > do it in board_init_f, and move the function to soc file so > that we can find all the soc/board setting in soc file and > use a common board file. > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > --- > > arch/arm/mach-rockchip/rk3188-board-spl.c | 28 +- > arch/arm/mach-rockchip/rk3188/Makefile| 1 + > arch/arm/mach-rockchip/rk3188/rk3188.c| 36 +++ > 3 files changed, 38 insertions(+), 27 deletions(-) > create mode 100644 arch/arm/mach-rockchip/rk3188/rk3188.c > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 05/10] rockchip: rk322x: move board_debug_uart_init() to rk322x.c
> Move the function to soc file so > that we can find all the soc/board setting in soc file and > use a common board file later for all rockchip SoCs. > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > --- > > arch/arm/mach-rockchip/rk322x-board-spl.c | 44 ++- > arch/arm/mach-rockchip/rk322x-board.c | 30 +--- > arch/arm/mach-rockchip/rk322x/Makefile| 2 +- > arch/arm/mach-rockchip/rk322x/rk322x.c| 44 +++ > 4 files changed, 48 insertions(+), 72 deletions(-) > create mode 100644 arch/arm/mach-rockchip/rk322x/rk322x.c > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/10] rockchip: rk3288: use grf structure to access soc_con2
> Prefer to use structure to access register if we can. > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > --- > > arch/arm/mach-rockchip/rk3288/rk3288.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/10] rockchip: rk3368: move board_debug_uart_init() to rk3368.c
> Move the function to soc file so > that we can find all the soc/board setting in soc file and > use a common board file later for all rockchip SoCs. > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > Tested-by: Andy Yan > --- > > arch/arm/mach-rockchip/rk3368-board-spl.c | 8 -- > arch/arm/mach-rockchip/rk3368-board-tpl.c | 33 +-- > arch/arm/mach-rockchip/rk3368/rk3368.c| 31 + > 3 files changed, 32 insertions(+), 40 deletions(-) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/10] rockchip: rk3036: add board_debug_uart_init()
> Use board_debug_uart_init() for UART iomux init instead of > do it in board_init_f, and move the function to soc file so > that we can find all the soc/board setting in soc file and > use a common board file. > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > --- > > arch/arm/mach-rockchip/rk3036-board-spl.c | 20 +--- > arch/arm/mach-rockchip/rk3036/Makefile| 1 + > arch/arm/mach-rockchip/rk3036/rk3036.c| 39 +++ > 3 files changed, 41 insertions(+), 19 deletions(-) > create mode 100644 arch/arm/mach-rockchip/rk3036/rk3036.c > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/10] rockchip: rk3399: add board_debug_uart_init()
> Use board_debug_uart_init() for UART iomux init instead of > do it in board_init_f, and move the function to soc file so > that we can find all the soc/board setting in soc file and > use a common board file for all rockchip SoCs later. > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > --- > > arch/arm/mach-rockchip/rk3399-board-spl.c | 50 +-- > arch/arm/mach-rockchip/rk3399/rk3399.c| 50 +++ > 2 files changed, 51 insertions(+), 49 deletions(-) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 07/10] rockchip: rk3288: add board_debug_uart_init()
> Use board_debug_uart_init() for UART iomux init instead of > do it in board_init_f, and move the function to soc file so > that we can find all the soc/board setting in soc file and > use a common board file for all rockchip SoCs later. > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > --- > > arch/arm/mach-rockchip/rk3288-board-spl.c | 12 ++-- > arch/arm/mach-rockchip/rk3288-board-tpl.c | 16 ++-- > arch/arm/mach-rockchip/rk3288/rk3288.c| 13 + > 3 files changed, 17 insertions(+), 24 deletions(-) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/10] rockchip: rk3399: use grf structure to access reg
> Prefer to use structure to access register if we could. > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > Tested-by: Andy Yan > --- > > arch/arm/mach-rockchip/rk3399/rk3399.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] rockchip: correct ARCH_SOC name
> The ARCH_SOC name default as 'rockchip' and we put all the > header file in 'arch/arm/include/asm/arch-rockchip/', but > the 'rockchip' is not the SOC name, let's correct it after > we update all the source file. > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsiich > --- > > arch/arm/mach-rockchip/rk3036/Kconfig | 2 +- > arch/arm/mach-rockchip/rk3128/Kconfig | 2 +- > arch/arm/mach-rockchip/rk3188/Kconfig | 2 +- > arch/arm/mach-rockchip/rk322x/Kconfig | 2 +- > arch/arm/mach-rockchip/rk3288/Kconfig | 2 +- > arch/arm/mach-rockchip/rk3328/Kconfig | 2 +- > arch/arm/mach-rockchip/rk3368/Kconfig | 2 +- > arch/arm/mach-rockchip/rk3399/Kconfig | 2 +- > arch/arm/mach-rockchip/rv1108/Kconfig | 2 +- > 9 files changed, 9 insertions(+), 9 deletions(-) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] rockchip: use 'arch-rockchip' as header file path
> Rockchip use 'arch-rockchip' instead of arch-$(SOC) as common > header file path, so that we can get the correct path directly. > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > --- > > .../include/asm/arch-rockchip/ddr_rk3188.h| 2 +- > arch/arm/mach-rockchip/Kconfig| 2 +- > arch/arm/mach-rockchip/boot_mode.c| 2 +- > arch/arm/mach-rockchip/bootrom.c | 4 ++-- > arch/arm/mach-rockchip/rk3036-board-spl.c | 12 +-- > arch/arm/mach-rockchip/rk3036-board.c | 10 +- > arch/arm/mach-rockchip/rk3036/clk_rk3036.c| 4 ++-- > arch/arm/mach-rockchip/rk3036/sdram_rk3036.c | 12 +-- > arch/arm/mach-rockchip/rk3036/syscon_rk3036.c | 2 +- > arch/arm/mach-rockchip/rk3128-board.c | 10 +- > arch/arm/mach-rockchip/rk3128/clk_rk3128.c| 4 ++-- > arch/arm/mach-rockchip/rk3128/syscon_rk3128.c | 2 +- > arch/arm/mach-rockchip/rk3188-board-spl.c | 16 +++ > arch/arm/mach-rockchip/rk3188-board.c | 10 +- > arch/arm/mach-rockchip/rk3188/clk_rk3188.c| 4 ++-- > arch/arm/mach-rockchip/rk3188/syscon_rk3188.c | 2 +- > arch/arm/mach-rockchip/rk322x-board-spl.c | 12 +-- > arch/arm/mach-rockchip/rk322x-board.c | 10 +- > arch/arm/mach-rockchip/rk322x/clk_rk322x.c| 4 ++-- > arch/arm/mach-rockchip/rk322x/syscon_rk322x.c | 2 +- > arch/arm/mach-rockchip/rk3288-board-spl.c | 20 +-- > arch/arm/mach-rockchip/rk3288-board-tpl.c | 14 ++--- > arch/arm/mach-rockchip/rk3288-board.c | 12 +-- > arch/arm/mach-rockchip/rk3288/clk_rk3288.c| 4 ++-- > arch/arm/mach-rockchip/rk3288/rk3288.c| 2 +- > arch/arm/mach-rockchip/rk3288/syscon_rk3288.c | 2 +- > arch/arm/mach-rockchip/rk3328/clk_rk3328.c| 4 ++-- > arch/arm/mach-rockchip/rk3328/rk3328.c| 2 +- > arch/arm/mach-rockchip/rk3328/syscon_rk3328.c | 2 +- > arch/arm/mach-rockchip/rk3368-board-spl.c | 10 +- > arch/arm/mach-rockchip/rk3368-board-tpl.c | 12 +-- > arch/arm/mach-rockchip/rk3368/clk_rk3368.c| 4 ++-- > arch/arm/mach-rockchip/rk3368/rk3368.c| 6 +++--- > arch/arm/mach-rockchip/rk3368/syscon_rk3368.c | 2 +- > arch/arm/mach-rockchip/rk3399-board-spl.c | 12 +-- > arch/arm/mach-rockchip/rk3399-board.c | 2 +- > arch/arm/mach-rockchip/rk3399/clk_rk3399.c| 4 ++-- > arch/arm/mach-rockchip/rk3399/rk3399.c| 2 +- > arch/arm/mach-rockchip/rk3399/syscon_rk3399.c | 2 +- > arch/arm/mach-rockchip/rk_timer.c | 2 +- > arch/arm/mach-rockchip/rv1108/clk_rv1108.c| 4 ++-- > arch/arm/mach-rockchip/rv1108/syscon_rv1108.c | 2 +- > arch/arm/mach-rockchip/sdram_common.c | 2 +- > board/elgin/elgin_rv1108/elgin_rv1108.c | 4 ++-- > board/rockchip/evb_rk3036/evb_rk3036.c| 4 ++-- > board/rockchip/evb_rk3229/evb_rk3229.c| 2 +- > board/rockchip/evb_rk3399/evb-rk3399.c| 2 +- > board/rockchip/evb_rv1108/evb_rv1108.c| 4 ++-- > board/rockchip/kylin_rk3036/kylin_rk3036.c| 4 ++-- > board/rockchip/sheep_rk3368/sheep_rk3368.c| 4 ++-- > .../lion_rk3368/lion_rk3368.c | 6 +++--- > .../puma_rk3399/puma-rk3399.c | 10 +- > board/vamrs/rock960_rk3399/rock960-rk3399.c | 2 +- > cmd/rockusb.c | 2 +- > drivers/clk/rockchip/clk_rk3036.c | 6 +++--- > drivers/clk/rockchip/clk_rk3128.c | 6 +++--- > drivers/clk/rockchip/clk_rk3188.c | 8 > drivers/clk/rockchip/clk_rk322x.c | 6 +++--- > drivers/clk/rockchip/clk_rk3288.c | 8 > drivers/clk/rockchip/clk_rk3328.c | 8 > drivers/clk/rockchip/clk_rk3368.c | 6 +++--- > drivers/clk/rockchip/clk_rk3399.c | 6 +++--- > drivers/clk/rockchip/clk_rv1108.c | 6 +++--- > drivers/gpio/rk_gpio.c| 3 ++- > drivers/i2c/rk_i2c.c | 6 +++--- > drivers/mmc/rockchip_dw_mmc.c | 4 ++-- > drivers/net/gmac_rockchip.c | 18 - > drivers/pwm/rk_pwm.c | 2 +- > drivers/ram/rockchip/dmc-rk3368.c | 12 +-- > drivers/ram/rockchip/sdram_rk3128.c | 6 +++--- > drivers/ram/rockchip/sdram_rk3188.c | 14 ++--- > drivers/ram/rockchip/sdram_rk322x.c | 16 +++ > drivers/ram/rockchip/sdram_rk3288.c | 14 ++--- > drivers/ram/rockchip/sdram_rk3328.c | 6 +++--- > drivers/ram/rockchip/sdram_rk3399.c | 12 +-- > drivers/reset/reset-rockchip.c| 2 +- > drivers/serial/serial_rockchip.c | 2 +- > drivers/sound/rockchip_sound.c| 2 +- > drivers/spi/rk_spi.c
Re: [U-Boot] [PATCH 1/3] rockchip: arm: use 'arch-rockchip' for common header
> rockchip platform header file is in 'arch-rockchip' > instead of arch-$(SOC) for all SoCs. > > Signed-off-by: Kever Yang > Reviewed-by: Philipp Tomsich > --- > > arch/arm/cpu/armv8/start.S | 4 > arch/arm/include/asm/gpio.h | 2 +- > arch/arm/lib/vectors.S | 5 - > 3 files changed, 9 insertions(+), 2 deletions(-) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 30/50] x86: ivybridge: Implement PCH_REQ_PMBASE_INFO
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > Implement this ioctl() to support power off. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Add new patch to implement PCH_REQ_PMBASE_INFO on ivybridge > > arch/x86/cpu/ivybridge/bd82x6x.c | 15 +++ > 1 file changed, 15 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 v2 28/50] x86: sysreset: Separate out the EFI code
+Heinrich, On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > The EFI implementation of reset sits inside the driver and is called > directly from outside the driver, breaking the normal driver-model > conventions. Worse, it passed NULL as the device pointer, hoping that > the called function won't use it, which breaks as soon as code is added > to use it. > > Separate out the implementation to improve the situation enough to allow > a future patch to add new sysreset features. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Add new patch to separate out the EFI code in sysreset > > drivers/sysreset/sysreset_x86.c | 16 +++- > 1 file changed, 11 insertions(+), 5 deletions(-) > > diff --git a/drivers/sysreset/sysreset_x86.c b/drivers/sysreset/sysreset_x86.c > index 009f3766027..d484ec5de49 100644 > --- a/drivers/sysreset/sysreset_x86.c > +++ b/drivers/sysreset/sysreset_x86.c > @@ -12,8 +12,7 @@ > #include > #include > > -static __efi_runtime int x86_sysreset_request(struct udevice *dev, > - enum sysreset_t type) I remember last time I tried when booting Linux from EFI loader on U-Boot, calling from kernel into the EFI runtime was broken. Not sure what the latest status is. > +static int x86_sysreset_request(struct udevice *dev, enum sysreset_t type) > { > int value; > > @@ -39,11 +38,18 @@ void __efi_runtime EFIAPI efi_reset_system( > efi_status_t reset_status, > unsigned long data_size, void *reset_data) > { > + int value; > + > + /* > +* inline this code since we are not caused in the context of a > +* udevice and passing NULL to x86_sysreset_request() is too horrible. > +*/ > if (reset_type == EFI_RESET_COLD || > reset_type == EFI_RESET_PLATFORM_SPECIFIC) > - x86_sysreset_request(NULL, SYSRESET_COLD); > - else if (reset_type == EFI_RESET_WARM) > - x86_sysreset_request(NULL, SYSRESET_WARM); > + value = SYS_RST | RST_CPU | FULL_RST; > + else /* assume EFI_RESET_WARM since we cannot return an error */ > + value = SYS_RST | RST_CPU; > + outb(value, IO_PORT_RESET); > > /* TODO EFI_RESET_SHUTDOWN */ > > -- Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 29/50] x86: pch: Add an ioctl to read power-management info
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > Add a new ioctl() request to read information about the power-management > system. This can be used to power off the device. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Add new patch to add an ioctl to read power-management info > > include/pch.h | 18 ++ > 1 file changed, 18 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/6] arm: dts: imx8qm: add lpuart1, lpuart2, lpuart3, lpuart4
Reviewed-by: Max Krummenacher On Tue, 2019-04-30 at 12:06 +0200, Marcel Ziswiler wrote: > From: Marcel Ziswiler > > Add support for lpuart1, lpuart2, lpuart3 and lpuart4. > > Signed-off-by: Marcel Ziswiler > > --- > > arch/arm/dts/fsl-imx8qm.dtsi | 80 > 1 file changed, 80 insertions(+) > > diff --git a/arch/arm/dts/fsl-imx8qm.dtsi b/arch/arm/dts/fsl-imx8qm.dtsi > index b39c40bd98..db01959990 100644 > --- a/arch/arm/dts/fsl-imx8qm.dtsi > +++ b/arch/arm/dts/fsl-imx8qm.dtsi > @@ -22,6 +22,10 @@ > ethernet0 = &fec1; > ethernet1 = &fec2; > serial0 = &lpuart0; > + serial1 = &lpuart1; > + serial2 = &lpuart2; > + serial3 = &lpuart3; > + serial4 = &lpuart4; > mmc0 = &usdhc1; > mmc1 = &usdhc2; > mmc2 = &usdhc3; > @@ -193,6 +197,30 @@ > power-domains = <&pd_dma>; > wakeup-irq = <345>; > }; > + pd_dma_lpuart1: PD_DMA_UART1 { > + reg = ; > + #power-domain-cells = <0>; > + power-domains = <&pd_dma>; > + wakeup-irq = <346>; > + }; > + pd_dma_lpuart2: PD_DMA_UART2 { > + reg = ; > + #power-domain-cells = <0>; > + power-domains = <&pd_dma>; > + wakeup-irq = <347>; > + }; > + pd_dma_lpuart3: PD_DMA_UART3 { > + reg = ; > + #power-domain-cells = <0>; > + power-domains = <&pd_dma>; > + wakeup-irq = <348>; > + }; > + pd_dma_lpuart4: PD_DMA_UART4 { > + reg = ; > + #power-domain-cells = <0>; > + power-domains = <&pd_dma>; > + wakeup-irq = <349>; > + }; > }; > }; > > @@ -297,6 +325,58 @@ > status = "disabled"; > }; > > + lpuart1: serial@5a07 { > + compatible = "fsl,imx8qm-lpuart"; > + reg = <0x0 0x5a07 0x0 0x1000>; > + interrupts = ; > + clocks = <&clk IMX8QM_UART1_CLK>, > + <&clk IMX8QM_UART1_IPG_CLK>; > + clock-names = "per", "ipg"; > + assigned-clocks = <&clk IMX8QM_UART1_CLK>; > + assigned-clock-rates = <8000>; > + power-domains = <&pd_dma_lpuart1>; > + status = "disabled"; > + }; > + > + lpuart2: serial@5a08 { > + compatible = "fsl,imx8qm-lpuart"; > + reg = <0x0 0x5a08 0x0 0x1000>; > + interrupts = ; > + clocks = <&clk IMX8QM_UART2_CLK>, > + <&clk IMX8QM_UART2_IPG_CLK>; > + clock-names = "per", "ipg"; > + assigned-clocks = <&clk IMX8QM_UART2_CLK>; > + assigned-clock-rates = <8000>; > + power-domains = <&pd_dma_lpuart2>; > + status = "disabled"; > + }; > + > + lpuart3: serial@5a09 { > + compatible = "fsl,imx8qm-lpuart"; > + reg = <0x0 0x5a09 0x0 0x1000>; > + interrupts = ; > + clocks = <&clk IMX8QM_UART3_CLK>, > + <&clk IMX8QM_UART3_IPG_CLK>; > + clock-names = "per", "ipg"; > + assigned-clocks = <&clk IMX8QM_UART3_CLK>; > + assigned-clock-rates = <8000>; > + power-domains = <&pd_dma_lpuart3>; > + status = "disabled"; > + }; > + > + lpuart4: serial@5a0a { > + compatible = "fsl,imx8qm-lpuart"; > + reg = <0x0 0x5a0a 0x0 0x1000>; > + interrupts = ; > + clocks = <&clk IMX8QM_UART4_CLK>, > + <&clk IMX8QM_UART4_IPG_CLK>; > + clock-names = "per", "ipg"; > + assigned-clocks = <&clk IMX8QM_UART4_CLK>; > + assigned-clock-rates = <8000>; > + power-domains = <&pd_dma_lpuart4>; > + status = "disabled"; > + }; > + > usdhc1: usdhc@5b01 { > compatible = "fsl,imx8qm-usdhc", "fsl,imx6sl-usdhc"; > interrupt-parent = <&gic>; ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] board: toradex: add apalis imx8qm 4gb wb it v1.0b module support
See review comments below. (Marked with 'Review Max:') With the issue resolved: Reviewed-by: Max Krummenacher On Tue, 2019-04-30 at 12:06 +0200, Marcel Ziswiler wrote: > From: Marcel Ziswiler > > This commit adds initial support for the Toradex Apalis iMX8QM 4GB WB IT > V1.0B module. Unlike the V1.0A early access samples exclusively booting > from SD card, they are now strapped to boot from eFuses which are > factory fused to properly boot from their on-module eMMC. U-Boot > supports either booting from the on-module eMMC or may be used for > recovery purpose using the universal update utility (uuu) aka mfgtools > 3.0. > > Functionality wise the following is known to be working: > - eMMC, 8-bit and 4-bit MMC/SD card slots > - Gigabit Ethernet > - GPIOs > - I2C > > Unfortunately, there is no USB functionality for the i.MX 8QM as of yet. > > Signed-off-by: Marcel Ziswiler > > --- > > arch/arm/dts/Makefile | 1 + > arch/arm/dts/fsl-imx8qm-apalis-u-boot.dtsi | 128 > arch/arm/dts/fsl-imx8qm-apalis.dts | 615 > arch/arm/mach-imx/imx8/Kconfig | 6 + > board/toradex/apalis-imx8qm/Kconfig | 30 + > board/toradex/apalis-imx8qm/MAINTAINERS | 9 + > board/toradex/apalis-imx8qm/Makefile| 6 + > board/toradex/apalis-imx8qm/README | 66 +++ > board/toradex/apalis-imx8qm/apalis-imx8qm.c | 157 + > board/toradex/apalis-imx8qm/imximage.cfg| 24 + > configs/apalis-imx8qm_defconfig | 56 ++ > include/configs/apalis-imx8qm.h | 178 ++ > 12 files changed, 1276 insertions(+) > create mode 100644 arch/arm/dts/fsl-imx8qm-apalis-u-boot.dtsi > create mode 100644 arch/arm/dts/fsl-imx8qm-apalis.dts > create mode 100644 board/toradex/apalis-imx8qm/Kconfig > create mode 100644 board/toradex/apalis-imx8qm/MAINTAINERS > create mode 100644 board/toradex/apalis-imx8qm/Makefile > create mode 100644 board/toradex/apalis-imx8qm/README > create mode 100644 board/toradex/apalis-imx8qm/apalis-imx8qm.c > create mode 100644 board/toradex/apalis-imx8qm/imximage.cfg > create mode 100644 configs/apalis-imx8qm_defconfig > create mode 100644 include/configs/apalis-imx8qm.h > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile > index e1f18c2833..c7260968b5 100644 > --- a/arch/arm/dts/Makefile > +++ b/arch/arm/dts/Makefile > @@ -567,6 +567,7 @@ dtb-$(CONFIG_MX7) += imx7d-sdb.dtb \ > dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb > > dtb-$(CONFIG_ARCH_IMX8) += \ > + fsl-imx8qm-apalis.dtb \ > fsl-imx8qm-mek.dtb \ > fsl-imx8qxp-colibri.dtb \ > fsl-imx8qxp-mek.dtb > diff --git a/arch/arm/dts/fsl-imx8qm-apalis-u-boot.dtsi > b/arch/arm/dts/fsl-imx8qm-apalis-u-boot.dtsi > new file mode 100644 > index 00..7b1a9550e4 > --- /dev/null > +++ b/arch/arm/dts/fsl-imx8qm-apalis-u-boot.dtsi > @@ -0,0 +1,128 @@ > +// SPDX-License-Identifier: GPL-2.0+ OR X11 > +/* > + * Copyright 2019 Toradex AG > + */ > + > +&mu { > + u-boot,dm-spl; > +}; > + > +&clk { > + u-boot,dm-spl; > +}; > + > +&iomuxc { > + u-boot,dm-spl; > +}; > + > +&pd_lsio { > + u-boot,dm-spl; > +}; > + > +&pd_lsio_gpio0 { > + u-boot,dm-spl; > +}; > + > +&pd_lsio_gpio1 { > + u-boot,dm-spl; > +}; > + > +&pd_lsio_gpio2 { > + u-boot,dm-spl; > +}; > + > +&pd_lsio_gpio3 { > + u-boot,dm-spl; > +}; > + > +&pd_lsio_gpio4 { > + u-boot,dm-spl; > +}; > + > +&pd_lsio_gpio5 { > + u-boot,dm-spl; > +}; > + > +&pd_lsio_gpio6 { > + u-boot,dm-spl; > +}; > + > +&pd_lsio_gpio7 { > + u-boot,dm-spl; > +}; > + > +&pd_conn { > + u-boot,dm-spl; > +}; > + > +&pd_conn_sdch0 { > + u-boot,dm-spl; > +}; > + > +&pd_conn_sdch1 { > + u-boot,dm-spl; > +}; > + > +&pd_conn_sdch2 { > + u-boot,dm-spl; > +}; > + > +&gpio0 { > + u-boot,dm-spl; > +}; > + > +&gpio1 { > + u-boot,dm-spl; > +}; > + > +&gpio2 { > + u-boot,dm-spl; > +}; > + > +&gpio3 { > + u-boot,dm-spl; > +}; > + > +&gpio4 { > + u-boot,dm-spl; > +}; > + > +&gpio5 { > + u-boot,dm-spl; > +}; > + > +&gpio6 { > + u-boot,dm-spl; > +}; > + > +&gpio7 { > + u-boot,dm-spl; > +}; > + > +&lpuart0 { > + u-boot,dm-spl; > +}; > + > +&lpuart1 { > + u-boot,dm-spl; > +}; > + > +&lpuart2 { > + u-boot,dm-spl; > +}; > + > +&lpuart3 { > + u-boot,dm-spl; > +}; > + > +&usdhc1 { > + u-boot,dm-spl; > +}; > + > +&usdhc2 { > + u-boot,dm-spl; > +}; > + > +&usdhc3 { > + u-boot,dm-spl; > +}; > diff --git a/arch/arm/dts/fsl-imx8qm-apalis.dts > b/arch/arm/dts/fsl-imx8qm-apalis.dts > new file mode 100644 > index 00..9b1f8aa32d > --- /dev/null > +++ b/arch/arm/dts/fsl-imx8qm-apalis.dts > @@ -0,0 +1,615 @@ > +// SPDX-License-Identifier: GPL-2.0+ OR X11 > +/* > + * Copyright 2017-2019 Toradex > + */ > + > +/dts-v1/; > + > +/* First 128KB is for PSCI ATF. */ > +/memreserve/ 0x8000 0x0002; > + > +#include "fsl-imx8qm.dtsi" > +#include "fsl-imx8qm-apalis-u-boot.dtsi" > + > +/ { >
Re: [U-Boot] [PATCH 4/6] imx8qm: fix cpu frequency reporting
See review comment below. With the issue resolved: Reviewed-by: Max Krummenacher On Tue, 2019-04-30 at 12:06 +0200, Marcel Ziswiler wrote: > CPU frequency reporting failed with the following error message being > printed: > > sc_pm_get_clock_rate: resource:507 clk:2: res:3 > Could not read CPU frequency: -22 > CPU: NXP i.MX8QM RevB A53 at 0 MHz > > Fix this by differentiating between the A35 as found on the i.MX 8QXP > and the A53 as found on the i.MX 8QM SoCs. > > Signed-off-by: Marcel Ziswiler > > --- > > arch/arm/mach-imx/imx8/cpu.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/mach-imx/imx8/cpu.c b/arch/arm/mach-imx/imx8/cpu.c > index 12716e7e9e..0d01e3fc3b 100644 > --- a/arch/arm/mach-imx/imx8/cpu.c > +++ b/arch/arm/mach-imx/imx8/cpu.c > @@ -654,8 +654,9 @@ static ulong imx8_get_cpu_rate(void) > { > ulong rate; > int ret; > + int type = is_cortex_a35() ? SC_R_A35 : SC_R_A53; The related get_core_name() below foresees that the code could run on a cortex_a72. So we should here also test with is_cortex_a72 and then use SC_R_A72 to avoid a follow-up patch for a future i.MX8 SKU or changed configuration. Regards, Max > > - ret = sc_pm_get_clock_rate(-1, SC_R_A35, SC_PM_CLK_CPU, > + ret = sc_pm_get_clock_rate(-1, type, SC_PM_CLK_CPU, > (sc_pm_clock_rate_t *)&rate); > if (ret) { > printf("Could not read CPU frequency: %d\n", ret); ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] arm: dts: imx8qm: add support for i2c0, i2c1, i2c2, i2c3 and i2c4
Reviewed-by: Max Krummenacher On Tue, 2019-04-30 at 12:06 +0200, Marcel Ziswiler wrote: > From: Marcel Ziswiler > > Add support for i2c0, i2c1, i2c2, i2c3 and i2c4. > > Signed-off-by: Marcel Ziswiler > > --- > > arch/arm/dts/fsl-imx8qm.dtsi | 75 > 1 file changed, 75 insertions(+) > > diff --git a/arch/arm/dts/fsl-imx8qm.dtsi b/arch/arm/dts/fsl-imx8qm.dtsi > index db01959990..af060db3a1 100644 > --- a/arch/arm/dts/fsl-imx8qm.dtsi > +++ b/arch/arm/dts/fsl-imx8qm.dtsi > @@ -29,6 +29,11 @@ > mmc0 = &usdhc1; > mmc1 = &usdhc2; > mmc2 = &usdhc3; > + i2c0 = &i2c0; > + i2c1 = &i2c1; > + i2c2 = &i2c2; > + i2c3 = &i2c3; > + i2c4 = &i2c4; > }; > > memory@8000 { > @@ -224,6 +229,76 @@ > }; > }; > > + i2c0: i2c@5a80 { > + compatible = "fsl,imx8qm-lpi2c", "fsl,imx7ulp-lpi2c"; > + reg = <0x0 0x5a80 0x0 0x4000>; > + interrupts = ; > + interrupt-parent = <&gic>; > + clocks = <&clk IMX8QM_I2C0_CLK>, > + <&clk IMX8QM_I2C0_IPG_CLK>; > + clock-names = "per", "ipg"; > + assigned-clocks = <&clk IMX8QM_I2C0_CLK>; > + assigned-clock-rates = <2400>; > + power-domains = <&pd_dma_lpi2c0>; > + status = "disabled"; > + }; > + > + i2c1: i2c@5a81 { > + compatible = "fsl,imx8qm-lpi2c", "fsl,imx7ulp-lpi2c"; > + reg = <0x0 0x5a81 0x0 0x4000>; > + interrupts = ; > + interrupt-parent = <&gic>; > + clocks = <&clk IMX8QM_I2C1_CLK>, > + <&clk IMX8QM_I2C1_IPG_CLK>; > + clock-names = "per", "ipg"; > + assigned-clocks = <&clk IMX8QM_I2C1_CLK>; > + assigned-clock-rates = <2400>; > + power-domains = <&pd_dma_lpi2c1>; > + status = "disabled"; > + }; > + > + i2c2: i2c@5a82 { > + compatible = "fsl,imx8qm-lpi2c", "fsl,imx7ulp-lpi2c"; > + reg = <0x0 0x5a82 0x0 0x4000>; > + interrupts = ; > + interrupt-parent = <&gic>; > + clocks = <&clk IMX8QM_I2C2_CLK>, > + <&clk IMX8QM_I2C2_IPG_CLK>; > + clock-names = "per", "ipg"; > + assigned-clocks = <&clk IMX8QM_I2C2_CLK>; > + assigned-clock-rates = <2400>; > + power-domains = <&pd_dma_lpi2c2>; > + status = "disabled"; > + }; > + > + i2c3: i2c@5a83 { > + compatible = "fsl,imx8qm-lpi2c", "fsl,imx7ulp-lpi2c"; > + reg = <0x0 0x5a83 0x0 0x4000>; > + interrupts = ; > + interrupt-parent = <&gic>; > + clocks = <&clk IMX8QM_I2C3_CLK>, > + <&clk IMX8QM_I2C3_IPG_CLK>; > + clock-names = "per", "ipg"; > + assigned-clocks = <&clk IMX8QM_I2C3_CLK>; > + assigned-clock-rates = <2400>; > + power-domains = <&pd_dma_lpi2c3>; > + status = "disabled"; > + }; > + > + i2c4: i2c@5a84 { > + compatible = "fsl,imx8qm-lpi2c", "fsl,imx7ulp-lpi2c"; > + reg = <0x0 0x5a84 0x0 0x4000>; > + interrupts = ; > + interrupt-parent = <&gic>; > + clocks = <&clk IMX8QM_I2C4_CLK>, > + <&clk IMX8QM_I2C4_IPG_CLK>; > + clock-names = "per", "ipg"; > + assigned-clocks = <&clk IMX8QM_I2C4_CLK>; > + assigned-clock-rates = <2400>; > + power-domains = <&pd_dma_lpi2c4>; > + status = "disabled"; > + }; > + > gpio0: gpio@5d08 { > compatible = "fsl,imx8qm-gpio", "fsl,imx35-gpio"; > reg = <0x0 0x5d08 0x0 0x1>; ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] imx8: fuse: fix fuse driver
Reviewed-by: Max Krummenacher On Tue, 2019-04-30 at 12:06 +0200, Marcel Ziswiler wrote: > This fixes the i.MX 8 fuse driver to actually build for i.MX 8QM as > well. > > Signed-off-by: Marcel Ziswiler > > --- > > drivers/misc/imx8/fuse.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/misc/imx8/fuse.c b/drivers/misc/imx8/fuse.c > index 29d2256a22..2f2fad2c17 100644 > --- a/drivers/misc/imx8/fuse.c > +++ b/drivers/misc/imx8/fuse.c > @@ -15,13 +15,11 @@ DECLARE_GLOBAL_DATA_PTR; > #define FSL_ECC_WORD_START_1 0x10 > #define FSL_ECC_WORD_END_10x10F > > -#ifdef CONFIG_IMX8QXP > #define FSL_ECC_WORD_START_2 0x220 > #define FSL_ECC_WORD_END_20x31F > > #define FSL_QXP_FUSE_GAP_START0x110 > #define FSL_QXP_FUSE_GAP_END 0x21F > -#endif > > #define FSL_SIP_OTP_READ 0xc20A > #define FSL_SIP_OTP_WRITE0xc20B ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] core: ofnode: Fix ASAN-reported stack-buffer-overflow in of_get_address
On Tue, 2019-04-30 at 14:28 +0200, Eugeniu Rosca wrote: > Hi Jeremy, > > Would you kindly feedback if it's possible to include commit > https://github.com/getpatchwork/patchwork/commit/67faf96ab96d932 > into U-Boot's patchwork to avoid occasional glitches in the > description of U-Boot commits? This is included in 2.1.1 [1] which patchwork.ozlabs.org was recently updated to [2], so you should have this fix now. Let me know if I've missed something. Stephen [1] https://github.com/getpatchwork/patchwork/commit/8060b9a671 [2] https://lists.ozlabs.org/pipermail/patchwork/2019-April/005746.html > On Sun, Apr 14, 2019 at 07:39:19PM -0400, Tom Rini wrote: > > On Sun, Apr 14, 2019 at 10:13:15PM +0200, Eugeniu Rosca wrote: > > > Hi Simon, > > > CC: Tom, Yamada-san, Jiri, Stephen, > > > > > > On Sat, Mar 30, 2019 at 03:19:23PM -0600, Simon Glass wrote: > > > > Hi Eugeniu, > > > > > > > > On Mon, 25 Mar 2019 at 04:44, Eugeniu Rosca < > > > > ero...@de.adit-jv.com> wrote: > > > > > Hello Simon, > > > > > > > > > > On Sun, Mar 10, 2019 at 03:51:47PM -0600, Simon Glass wrote: > > > > > [..] > > > > > > Reviewed-by: Simon Glass > > > > > > > > > > Can this fix go to u-boot-dm or is more review required? > > > > > > > > > > > > > Yes it looks like it is in my queue. > > > > > > > > Regards, > > > > Simon > > > > > > First, many thanks for pushing the fix to u-boot-dm. > > > > > > Second, I would like to (repeatedly [0]) point out a pretty rare > > > corruption of patch metadata, which places the 'Reviewed-by:' > > > (and actually any other "*-by: ") signature on top of the '=' > > > line if the latter is present in commit description (see [1]). > > > > > > As Yamada-san pointed out in [0], this is presumably caused by a > > > patchwork bug and after some grepping through the patchwork git > > > history, it looks like the issue is already fixed in patchwork > > > master > > > thanks to Jiri and Stephen via commit [2]. > > > > > > My guess is that the U-Boot patchwork version might not be > > > containing > > > this recent fix, hence still showcasing the wrong behavior? > > > > > > FWIW, at least below U-Boot commits exhibit the same > > > inconsistency: > > > > > > u-boot $> for c in $(git log --format=%h --grep "^==="); \ > > > do \ > > > git log --format=%B -1 $c | grep -B 2 "^===" | > > > \ > > > grep -q "by:.*@" && git --no-pager log --oneline -1 > > > $c; \ > > > done > > > > > > 0506620f4f49 sata: sata_mv: Add DM support to enable CONFIG_BLK > > > usage > > > 9bfacf249b10 core: ofnode: Fix ASAN-reported stack-buffer- > > > overflow in of_get_address > > > e1904f4530a3 common: avb_verify: Fix division by zero in > > > mmc_byte_io() > > > e91610da7c8a kconfig: re-sync with Linux 4.17-rc4 > > > e810565e23cd i.MX6DL: mamoj: Add PFUZE100 support > > > dda9892171c3 i.MX6DL: mamoj: Add I2C support > > > a0b0ff0ae643 arm: dra7xx: Fix Linux boot from eMMC > > > f6d245b8c56c arm: am57xx: Fix Linux boot from eMMC > > > 67ff9e11f397 wandboard: move environment partition farther from > > > u-boot.img > > > > > > [0] https://marc.info/?l=u-boot&m=152643616902958&w=2 > > > [1] http://git.denx.de/?p=u-boot.git;a=commitdiff;h=9bfacf249b10 > > > [2] > > > https://github.com/getpatchwork/patchwork/commit/67faf96ab96d932 > > > ("parser: fix parsing of patches with headings") > > > > Adding in Jeremy since we just use the ozlabs patchwork, thanks! > > > > -- > > Tom ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3] Convert CONFIG_SUPPORT_EMMC_BOOT to Kconfig
This converts the following to Kconfig: CONFIG_SUPPORT_EMMC_BOOT As requested by Michal Simek , these boards have no eMMC so CONFIG_SUPPORT_EMMC_BOOT has not been migrated: xilinx_zynqmp_zc1275_revB xilinx_zynqmp_zc1751_xm018_dc4 xilinx_zynqmp_zc1751_xm019_dc5 xilinx_zynqmp_zcu100_revC xilinx_zynqmp_zcu102_rev1_0 xilinx_zynqmp_zcu102_revA xilinx_zynqmp_zcu102_revB xilinx_zynqmp_zcu104_revA xilinx_zynqmp_zcu104_revC xilinx_zynqmp_zcu106_revA xilinx_zynqmp_zcu111_revA Signed-off-by: Alex Kiernan Acked-by: Lukasz Majewski Acked-by: Patrick Delaunay Acked-by: Ramon Fried Reviewed-by: Andy Shevchenko Tested-by: Sébastien Szymanski --- Green travis build: https://travis-ci.org/akiernan/u-boot/builds/526591535 Testing for configuration changes shows just the expected xilinx_zynqmp boards: boards.cfg is up to date. Nothing to do. Summary of 2 commits for 1365 boards (4 threads, 1 job per thread) 01: Prepare v2019.07-rc1 arm: w+ blanche db-88f6281-bp-nand Nintendo_NES_Classic_Edition ts4600 kc1 vining_2000 topic_miamilite bcm7260 tqma6dl_mba6_spi dserve_dsrv9703c m68k: w+ M5485BFE powerpc: w+ MPC8313ERDB_NAND_66 P3041DS_SRIO_PCIE_BOOT P1022DS_36BIT_NAND xpedite550x P5040DS_SDCARD Cyrus_P5040 T2080RDB_SRIO_PCIE_BOOT 02: Convert CONFIG_SUPPORT_EMMC_BOOT to Kconfig x86: + conga-qeval20-qa3-e3845-internal-uart theadorable-x86-conga-qa3-e3845-pcie-x4 bayleybay dfi-bt700-q7x-151 theadorable-x86-dfi-bt700 galileo theadorable-x86-conga-qa3-e3845 minnowmax som-db5800-som-6867 conga-qeval20-qa3-e3845 aarch64: w+ ls1088ardb_sdcard_qspi_SECURE_BOOT am65x_hs_evm_a53 pine_h64 pinebook pine64-lts bananapi_m2_plus_h5 xilinx_versal_mini_emmc1 xilinx_versal_mini_emmc0 mvebu_espressobin-88f3720 ls1012aqds_tfa_SECURE_BOOT bubblegum_96 bcm958712k amarula_a64_relic uDPU oceanic_5205_5inmfd libretech_all_h3_cc_h5 nanopi_neo2 bananapi_m64 orangepi_prime hikey orangepi_pc2 nanopi_neo_plus2 s32v234evb pine64_plus orangepi_one_plus emlid_neutis_n5_devboard turris_mox orangepi_win a64-olinuxino imx8qxp_mek xilinx_zynqmp_mini_emmc1 ls2080aqds_nand rpi_3 ls2080aqds_qspi xilinx_zynqmp_mini_emmc0 ls2080aqds_sdcard am65x_evm_a53 orangepi_zero_plus socfpga_stratix10 ls1046ardb_sdcard_SECURE_BOOT imx8mq_evk orangepi_lite2 ls2080a_simu nanopi_a64 ls1043ardb_sdcard_SECURE_BOOT mvebu_mcbin-88f8040 mvebu_db_armada8k sopine_baseboard orangepi_zero_plus2 clearfog_gt_8k mvebu_db-88f3720 powerpc: w+ T4240RDB T1024RDB_SPIFLASH T2081QDS_SRIO_PCIE_BOOT T2080QDS_SPIFLASH P3041DS_NAND P1020RDB-PC_36BIT MPC837XEMDS_HOST P1024RDB_SPIFLASH P2020RDB-PC_36BIT_SPIFLASH P1010RDB-PB_SPIFLASH_SECBOOT hrcon P5020DS_NAND T1024QDS_SPIFLASH P1010RDB-PA_36BIT_NAND P1021RDB-PC P1010RDB-PB_SDCARD P1010RDB-PB_36BIT_NOR T1024QDS_DDR4_SECURE_BOOT P1020UTM-PC_36BIT controlcenterd_36BIT_SDCARD P5020DS_SRIO_PCIE_BOOT P1020MBG-PC_36BIT_SDCARD BSC9132QDS_SDCARD_DDRCLK133_SECURE P2041RDB_SPIFLASH P3041DS T2081QDS P1025RDB_SDCARD T2080QDS T4240QDS T1040D4RDB BSC9132QDS_NAND_DDRCLK133_SECURE P1010RDB-PA_36BIT_SPIFLASH_SECBOOT T4240RDB_SDCARD TWR-P1025 P1010RDB-PB_36BIT_NAND T1023RDB_NAND P1022DS_36BIT_SDCARD P2041RDB_SECURE_BOOT T1024QDS_NAND P1021RDB-PC_SPIFLASH P5020DS_NAND_SECURE_BOOT P1010RDB-PA_SPIFLASH_SECBOOT MPC8536DS_SDCARD T1040RDB_SPIFLASH BSC9132QDS_SDCARD_DDRCLK100 T1024RDB_NAND T2081QDS_SPIFLASH P1010RDB-PB_36BIT_NOR_SECBOOT P5020DS BSC9132QDS_NOR_DDRCLK100_SECURE T1023RDB_SDCARD P1020UTM-PC P3041DS_SECURE_BOOT Cyrus_P5020 P1010RDB-PB_36BIT_SDCARD P2020RDB-PC UCP1020 T4160QDS_NAND P1020MBG-PC_36BIT P1020RDB-PC_36BIT_NAND T1042D4RDB_SECURE_BOOT P5040DS_SECURE_BOOT P1020RDB-PC_SDCARD T2080RDB P1025RDB_36BIT P5040DS_NAND T4240QDS_SECURE_BOOT P3041DS_SDCARD T1024QDS P5040DS_NAND_SECURE_BOOT T1042RDB_PI_NAND P1010RDB-PA_SPIFLASH P1020RDB-PD_SPIFLASH T2080RDB_NAND P1010RDB-PB_36BIT_SPIFLASH_SECBOOT P1010RDB-PB_NAND_SECBOOT P1022DS_SDCARD P1020RDB-PC_36BIT_SPIFLASH T1042RDB_PI_SDCARD BSC9132QDS_SPIFLASH_DDRCLK100_SECURE P3041DS_NAND_SECURE_BOOT T2081QDS_NAND BSC9132QDS_SDCARD_DDRCLK133 T4160QDS_SDCARD T2080QDS_SDCARD P1020RDB-PC_SPIFLASH T1042RDB T4160QDS_SECURE_BOOT P1021RDB-PC_NAND P1020RDB-PD P2041RDB_SDCARD T1040D4RDB_SPIFLASH T2080RDB_SECURE_BOOT P1010RDB-PA_36BIT_NOR_SECBOOT T1040QDS P1010RDB-PA_36BIT_NOR T1042D4RDB P1021RDB-PC_SDCARD P1025RDB P2020RDB-PC_SPIFLASH MPC837XEMDS P4080DS_SECURE_BOOT T1040QDS_SECURE_BOOT strider_con_dp T1040QDS_DDR4 P1010RDB-PA_36BIT_SDCARD P1010RDB-PB_NOR T2080RDB_SPIFLASH P1021RDB-PC_36BIT_SPIFLASH P1020RDB-PC_36BIT_SDCARD T1024QDS_DDR4 P1010RDB-PB_36BIT_NAND_SECBOOT P1020RDB-PC_NAND T2080QDS_NAND BSC9132QDS_SPIFLASH_DDRCLK133 controlcenterd_36BIT_SDCARD_DEVELOP strider_cpu_dp P5020DS_SDCARD P1010RDB-PA_NOR T2080QDS_SRIO_PCIE_BOOT P5020DS_SPIFLASH P1022DS_SPIFLASH UCP1020_SPIFLASH BSC9132QDS_NAND_DDRCLK100 MPC8308RDB T1040D4RDB_NAND T4160QDS P1010RDB-PA_NAND_SECBOOT T4160RDB BSC9132QDS_SPIFLASH_DDRCLK133_SECURE P1010RDB-PA_NOR_SECBOOT controlcenterd_TRAILBLAZER
[U-Boot] [PATCH] tools/Makefile: fix HOSTCFLAGS with CROSS_BUILD_TOOLS
When CROSS_BUILD_TOOLS is set, set HOSTCFLAGS to CFLAGS otherwise CC will be used with HOSTCFLAGS which seems wrong Signed-off-by: Fabrice Fontaine --- tools/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/Makefile b/tools/Makefile index 12a3027e23..eadeba417d 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -272,6 +272,7 @@ subdir- += env ifneq ($(CROSS_BUILD_TOOLS),) override HOSTCC = $(CC) +override HOSTCFLAGS = $(CFLAGS) quiet_cmd_crosstools_strip = STRIP $^ cmd_crosstools_strip = $(STRIP) $^; touch $@ -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] clk: imx8qm: fix usdhc2 clocks
Reviewed-by: Max Krummenacher On Tue, 2019-04-30 at 12:06 +0200, Marcel Ziswiler wrote: > Trying to bring up uSDHC2 the following error message was observed: > > MMC: imx8_clk_set_rate(Invalid clk ID #60) > imx8_clk_set_rate(Invalid clk ID #60) > usdhc@5b03 - probe failed: -22 > > This commit fixes this by properly setting resp. clocks. > > Signed-off-by: Marcel Ziswiler > > --- > > drivers/clk/imx/clk-imx8qm.c | 18 ++ > 1 file changed, 18 insertions(+) > > diff --git a/drivers/clk/imx/clk-imx8qm.c b/drivers/clk/imx/clk-imx8qm.c > index 6b5561e178..a6b09d2109 100644 > --- a/drivers/clk/imx/clk-imx8qm.c > +++ b/drivers/clk/imx/clk-imx8qm.c > @@ -80,6 +80,12 @@ ulong imx8_clk_get_rate(struct clk *clk) > resource = SC_R_SDHC_1; > pm_clk = SC_PM_CLK_PER; > break; > + case IMX8QM_SDHC2_IPG_CLK: > + case IMX8QM_SDHC2_CLK: > + case IMX8QM_SDHC2_DIV: > + resource = SC_R_SDHC_2; > + pm_clk = SC_PM_CLK_PER; > + break; > case IMX8QM_UART0_IPG_CLK: > case IMX8QM_UART0_CLK: > resource = SC_R_UART_0; > @@ -185,6 +191,12 @@ ulong imx8_clk_set_rate(struct clk *clk, unsigned long > rate) > resource = SC_R_SDHC_1; > pm_clk = SC_PM_CLK_PER; > break; > + case IMX8QM_SDHC2_IPG_CLK: > + case IMX8QM_SDHC2_CLK: > + case IMX8QM_SDHC2_DIV: > + resource = SC_R_SDHC_2; > + pm_clk = SC_PM_CLK_PER; > + break; > case IMX8QM_ENET0_IPG_CLK: > case IMX8QM_ENET0_AHB_CLK: > case IMX8QM_ENET0_REF_DIV: > @@ -273,6 +285,12 @@ int __imx8_clk_enable(struct clk *clk, bool enable) > resource = SC_R_SDHC_1; > pm_clk = SC_PM_CLK_PER; > break; > + case IMX8QM_SDHC2_IPG_CLK: > + case IMX8QM_SDHC2_CLK: > + case IMX8QM_SDHC2_DIV: > + resource = SC_R_SDHC_2; > + pm_clk = SC_PM_CLK_PER; > + break; > case IMX8QM_ENET0_IPG_CLK: > case IMX8QM_ENET0_AHB_CLK: > case IMX8QM_ENET0_REF_DIV: ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 31/50] x86: broadwell: Implement PCH_REQ_PMBASE_INFO
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > Implement this ioctl() to support power off. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Add new patch to implement PCH_REQ_PMBASE_INFO on broadwell > > arch/x86/cpu/broadwell/pch.c | 25 + > 1 file changed, 25 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 v3] Convert CONFIG_SUPPORT_EMMC_BOOT to Kconfig
On Wed, May 01, 2019 at 07:58:27AM +, Alex Kiernan wrote: > This converts the following to Kconfig: >CONFIG_SUPPORT_EMMC_BOOT > > As requested by Michal Simek , these boards > have no eMMC so CONFIG_SUPPORT_EMMC_BOOT has not been migrated: > > xilinx_zynqmp_zc1275_revB > xilinx_zynqmp_zc1751_xm018_dc4 > xilinx_zynqmp_zc1751_xm019_dc5 > xilinx_zynqmp_zcu100_revC > xilinx_zynqmp_zcu102_rev1_0 > xilinx_zynqmp_zcu102_revA > xilinx_zynqmp_zcu102_revB > xilinx_zynqmp_zcu104_revA > xilinx_zynqmp_zcu104_revC > xilinx_zynqmp_zcu106_revA > xilinx_zynqmp_zcu111_revA > > Signed-off-by: Alex Kiernan > Acked-by: Lukasz Majewski > Acked-by: Patrick Delaunay > Acked-by: Ramon Fried > Reviewed-by: Andy Shevchenko > Tested-by: Sébastien Szymanski > --- > Green travis build: > > https://travis-ci.org/akiernan/u-boot/builds/526591535 > > Testing for configuration changes shows just the expected xilinx_zynqmp > boards: So, FWIW, what I do (and will do for this patch when I check it out before pushing) ends up as: $ export SOURCE_DATE_EPOCH=`date +%s` $ ./tools/buildman/buildman -o /tmp/test -b master --force-build --step 0 \ -SCdvel \ 'arc|arm|sandbox|x86|aarch64|powerpc|m68k|nios2|nds32|sh|mips|xtensa|riscv' $ ./tools/buildman/buildman -o /tmp/test -b master --step 0 -Ssdel \ 'arc|arm|sandbox|x86|aarch64|powerpc|m68k|nios2|nds32|sh|mips|xtensa|riscv' With the patch applied in some branch that has 'master' as the upstream. This is basically a world-build and will size compare before/after, noting changes. If I see a size difference (outside of a few boards that include the config in the binary and so grow slightly on conversions), I use: $ export SOURCE_DATE_EPOCH=`date +%s` $ ./tools/buildman/buildman -o /tmp/brd -b master --step 0 -SBCdevlk BOARD $ ./tools/buildman/buildman -o /tmp/brd -b master --step 0 -SsBdevlk BOARD Which probably has a few more flags than required but will also tell which functions within the binary have changed and so a good place to hunt down what didn't convert correctly and why. -- 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 32/50] x86: sysreset: Implement power-off if available
Hi Simon, On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > On modern x86 devices we can power the system off using the power- > management features of the PCH. Add an implementation for this. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Add new patch to implement power-off if available > > drivers/sysreset/sysreset_x86.c | 82 + > 1 file changed, 82 insertions(+) > > diff --git a/drivers/sysreset/sysreset_x86.c b/drivers/sysreset/sysreset_x86.c > index d484ec5de49..bd759aa8bf4 100644 > --- a/drivers/sysreset/sysreset_x86.c > +++ b/drivers/sysreset/sysreset_x86.c > @@ -7,14 +7,80 @@ > > #include > #include > +#include > #include > #include > #include > #include > > +struct x86_sysreset_platdata { > + struct udevice *pch; > +}; > + > +#define PWRBTN_STS (1 << 8) > + > +#define SLP_EN (1 << 13) > +#define SLP_TYP (7 << 10) > +#defineSLP_TYP_S5 7 > + There are macros from acpi_s3.h that can be used directly here. > +/* > + * Power down the machine by using the power management sleep control > + * of the chipset. This will currently only work on Intel chipsets. > + * However, adapting it to new chipsets is fairly simple. You will > + * have to find the IO address of the power management register block > + * in your southbridge, and look up the appropriate SLP_TYP_S5 value > + * from your southbridge's data sheet. > + * > + * This function never returns. > + */ > +int pch_sysreset_power_off(struct udevice *dev) > +{ > + struct x86_sysreset_platdata *plat = dev_get_platdata(dev); > + struct pch_pmbase_info pm; > + u32 reg32; > + int ret; > + > + if (!plat->pch) > + return -ENOENT; > + ret = pch_ioctl(plat->pch, PCH_REQ_PMBASE_INFO, &pm, sizeof(pm)); > + if (ret) > + return ret; > + > + > + /* Mask interrupts or system might stay in a coma nits: wrong multi-line comment format > +* (not executing code anymore, but not powered off either) > +*/ > + asm("cli"); > + > + /* > +* Avoid any GPI waking the system from S5* or the system might stay > in > +* a coma > +*/ > + outl(0x, pm.base + pm.gpio0_en_ofs); > + > + /* Clear Power Button Status */ > + outw(PWRBTN_STS, pm.base + pm.pm1_sts_ofs); > + > + /* PMBASE + 4, Bit 10-12, Sleeping Type, * set to 111 -> S5, soft_off > */ > + reg32 = inl(pm.base + pm.pm1_cnt_ofs); > + > + /* Set Sleeping Type to S5 (poweroff) */ > + reg32 &= ~(SLP_EN | SLP_TYP); > + reg32 |= SLP_TYP_S5; > + outl(reg32, pm.base + pm.pm1_cnt_ofs); > + > + /* Now set the Sleep Enable bit */ > + reg32 |= SLP_EN; > + outl(reg32, pm.base + pm.pm1_cnt_ofs); > + > + for (;;) > + asm("hlt"); > +} > + > static int x86_sysreset_request(struct udevice *dev, enum sysreset_t type) > { > int value; > + int ret; > > switch (type) { > case SYSRESET_WARM: > @@ -23,6 +89,11 @@ static int x86_sysreset_request(struct udevice *dev, enum > sysreset_t type) > case SYSRESET_COLD: > value = SYS_RST | RST_CPU | FULL_RST; > break; > + case SYSRESET_POWER_OFF: > + ret = pch_sysreset_power_off(dev); > + if (ret) > + return ret; > + return -EINPROGRESS; > default: > return -ENOSYS; > } > @@ -57,6 +128,15 @@ void __efi_runtime EFIAPI efi_reset_system( > } > #endif > > +static int x86_sysreset_probe(struct udevice *dev) > +{ > + struct x86_sysreset_platdata *plat = dev_get_platdata(dev); > + > + /* Locate the PCH if there is one. It isn't essential */ > + uclass_first_device(UCLASS_PCH, &plat->pch); > + > + return 0; > +} > > static const struct udevice_id x86_sysreset_ids[] = { > { .compatible = "x86,reset" }, > @@ -72,4 +152,6 @@ U_BOOT_DRIVER(x86_sysreset) = { > .id = UCLASS_SYSRESET, > .of_match = x86_sysreset_ids, > .ops = &x86_sysreset_ops, > + .probe = x86_sysreset_probe, > + .platdata_auto_alloc_size = sizeof(struct > x86_sysreset_platdata), > }; > -- Other than above two, Reviewed-by: Bin Meng Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] EFIBootGuard for CIP and SecureBoot
On Sat, Apr 27, 2019 at 09:56:08AM +0200, Alexander Graf wrote: > > >>> UEFI gets a bad rap at being complicated, but I think the U-Boot work > >>> has shown that implementing the core UEFI ABI doesn't require much code > >>> and isn't the complicated mess they everyone fears it to be. > >> Depends on how much you start to rely on UEFI features. > > The format for a UEFI capsule is described in the > > EFI_FIRMWARE_MANAGEMENT_PROTOCOL chapter of the UEFI spec. Essentially > > Are you sure? I thought that protocol was about other devices in the > system, not the main firmware. It also seems to be optional - so we > could just have a board specific function to implement CapsuleUpdate, > but no cruft for all the other bits in the spec. There's no requirement to use that format in order to use capsule updates, but some vendors have found it convenient. There's also no requirement to implement the EFI_FIRMWARE_MANAGEMENT_PROTOCOL at all - and the only place it's distinctly useful from an application point of view (i.e. while trying to drive a firmware update) is if you want to independently update two of the same kind of peripheral device's firmware from within a UEFI application. It's not clear to me that's a very interesting use case from an EBBR point of view - I'm haven't seen much demand for it on server, laptop, or desktop systems either. But it's also how option ROMs register their firmware to be updated via UpdateCapsule(). That's interesting on machines where you regularly expect peripherals to be in PCIe slots, but I'm still not sure it's that useful for EBBR style devices. I guess it could be useful in the thunderbolt case, but I think in order to avoid thwarting DMA attack mitigations, that would best be done from the OS just like for USB devices. > That's where the idea came from to just put a fit image into the capsule > body (set CapsuleGUID to a newly defined FIT-GUID). With that, we could > share a lot of code inside of U-Boot, as DT parsing is already there. We > could then have individual segments, that can either be data or command > payloads and thus a capsule update could basically just be a few data > segments with a U-Boot script. This makes a lot of sense to me, though there have been some pain points about this approach in the past. The biggest one is because the EFI_FIRMWARE_MANAGEMENT_PROTOCOL capsule format has a header on it that's the same as the EFI_CAPSULE_HEADER structure, which we have to add in fwupd if we can't find it. If we plan on recommending that vendors implement these ad-hoc firmware blobs, we should also require that when they do so, they already include the EFI_CAPSULE_HEADER on the image, with a GUID that matches what's in the ESRT, and is specifically not EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID. > > it is a file containing multiple UEFI binaries which are individually > > signed and can be loaded as UEFI boottime drivers. Further payloads are > > passed to the SetImage() method of the EFI_FIRMWARE_MANAGEMENT_PROTOCOL. > > > > Two ways for the delivery of a capsule are defined. Three, I think? I'm not seeing why an application can't also call FMP->SetImage() to do this when it's present. I'm not sure it's worth supporting at all, though. > > Capsules can be delivered by placing a file in the > > \EFI\UpdateCapsule directory or by calling the UpdateCapsule() boot > > service. The UpdateCapsule() boot service can either be implemented > > as available at boottime only or as a full runtime service. Right now in fwupd we support only boot-service calls to do this, because of the history of bugs with SetVirtualAddressMap() and ExitBootServices(), and because it's the only thing required to be tested for Windows logo cert. I suspect MS has made that the case because of the exact same bugs. The path-based mechanism makes a lot of sense with EBBR, but runtime UpdateCapsule() is a lot more viable here than on the desktop or servers as well. The reason I say that is because with these devices we're more in a situation where the hardware vendor is likely to be producing the kernel as well, so there's a better integration testing story here. -- Peter ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/50] binman: Don't generate an error in 'text' entry constructor
On Fri, Apr 26, 2019 at 11:59 AM Simon Glass wrote: > > It is not good practice to raise an exception in a constructor. In this > case the 'text' entry may not actually be used, if -i is used to filter > out the images that get built. > > Move the exception to where the data is actually used. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > > tools/binman/etype/text.py | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/50] binman: Don't show image-skip message by default
On Wed, May 1, 2019 at 7:59 PM Bin Meng wrote: > > On Fri, Apr 26, 2019 at 11:59 AM Simon Glass wrote: > > > > This message is not very important since it is simply indicating that the > > user's instructions are being followed. Only show it when the verbosity > > level is above the default. > > > > Also drop the unnecessary extra newline on this message, which causes two > > line breaks. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v2: > > - Update commit message to mention dropping the \n > > - Update testSelectImage() to test in normal and verbose modes > > > > tools/binman/control.py | 4 ++-- > > tools/binman/ftest.py | 26 +++--- > > 2 files changed, 21 insertions(+), 9 deletions(-) > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/50] binman: Add a missing comment in Entry_vblock
On Fri, Apr 26, 2019 at 11:59 AM Simon Glass wrote: > > An important property is missing. Update the entry comment to include > this. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > > tools/binman/etype/vblock.py | 1 + > 1 file changed, 1 insertion(+) > applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/50] dm: core: Fix translate condition in ofnode_get_addr_size()
On Fri, Apr 26, 2019 at 11:59 AM Simon Glass wrote: > > Update the condition to translate only if this is enabled for SPL. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > > drivers/core/ofnode.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/50] x86: Add a way to reinit the cpu
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > We cannot init the CPU fully both than once during a boot. Add a new > function which can be called to figure out the CPU identity, but which > does not change anything. For x86_64, this is empty for now. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > > arch/x86/cpu/i386/cpu.c | 113 ++ > arch/x86/cpu/x86_64/cpu.c | 5 ++ > arch/x86/include/asm/u-boot-x86.h | 20 ++ > 3 files changed, 94 insertions(+), 44 deletions(-) > applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 07/50] binman: Allow sections to have an offset
On Wed, May 1, 2019 at 8:13 PM Bin Meng wrote: > > On Fri, Apr 26, 2019 at 11:59 AM Simon Glass wrote: > > > > At present sections are always placed automatically. Even if an 'offset' > > property is provided it is ignored. Update the logic to support an offset > > for sections. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v2: > > - Fix map output when section offset is not set (make it 0) > > - Add a test for sections with offsets > > > > tools/binman/README | 7 + > > tools/binman/bsection.py | 9 +++--- > > tools/binman/etype/section.py | 3 +- > > tools/binman/ftest.py | 18 > > tools/binman/test/101_sections_offset.dts | 35 +++ > > 5 files changed, 67 insertions(+), 5 deletions(-) > > create mode 100644 tools/binman/test/101_sections_offset.dts > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/50] x86: start64: Fix copyright message
On Fri, Apr 26, 2019 at 11:59 AM Simon Glass wrote: > > There is a typo in this header. Fix it. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > > arch/x86/cpu/start64.S | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/50] x86: mp_init: Use proper error numbers
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > At present many of the functions in this file return -1 as an error > number. which is -EPERM. Update the code to use real error numbers. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > > arch/x86/cpu/mp_init.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/50] spl: Allow sandbox to build a device-tree file
On Wed, May 1, 2019 at 8:13 PM Bin Meng wrote: > > On Fri, Apr 26, 2019 at 11:59 AM Simon Glass wrote: > > > > At present only OF_SEPARATE is considered valid for building a device-tree > > file in SPL. However sandbox uses OF_HOSTFILE instead. Update the logic to > > handle this and make it easier to understand. > > > > Note that the new logic is not quite the same as the old logic. It was > > previously assumed that checking for: > > > >$(CONFIG_$(SPL_TPL_)OF_CONTROL) > >$(CONFIG_OF_SEPARATE) > >$(CONFIG_$(SPL_TPL_)OF_PLATDATA) > > > > producing 'yy' meant that the first two were 'y' and the last was empty. > > Strictly speaking it would be possible for any two of the three to be 'y' > > and still yield the same result. However, that was not the intention of > > the new logic, since OF_PLATDATA always ensures that no device-tree file > > is included. So in effect the new logic is the same, with the addition of > > OF_HOSTFILE as an option for OP_SEPARATE. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v2: > > - Add a better explanation of the logic change, in the commit message > > > > scripts/Makefile.spl | 14 +- > > 1 file changed, 13 insertions(+), 1 deletion(-) > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/50] x86: dts: Add device-tree labels for rtc and reset
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > Add labels for these nodes so that board DT files can reference them. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > > arch/x86/dts/reset.dtsi | 2 +- > arch/x86/dts/rtc.dtsi | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 13/50] x86: Support SPL and TPL
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > At present only chromebook_link64 supports SPL. It is useful to eb able to > support both TPL and SPL to implement verified boot on x86. > > Enable the options for both along with some suitable default options > needed to boot through these phases. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > > arch/Kconfig | 31 +++ > arch/x86/Kconfig | 1 - > 2 files changed, 31 insertions(+), 1 deletion(-) > applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 12/50] x86: Update a stale comment about ifdtool
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > We use binman to build the x86 image now. Update a comment which still > refers to ifdtool. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: > - Update the comment in fsp_cap.S too > > arch/x86/cpu/intel_common/car.S | 2 +- > arch/x86/lib/fsp/fsp_car.S | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 15/50] x86: Add a handoff header file
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > Add an arch-specific handoff header so that we can use the HANDOFF feature > on x86 devices. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > > arch/x86/include/asm/handoff.h | 15 +++ > 1 file changed, 15 insertions(+) > create mode 100644 arch/x86/include/asm/handoff.h > applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 14/50] x86: Support booting with TPL
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > Some boards want to use TPL as the first phase of U-Boot. This allows > selection of A or B SPL phases, thus allowing the memory init to be > upgraded in the field. > > Add a new Kconfig option for this. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > > arch/x86/Kconfig | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 16/50] x86: broadwell: Improve SDRAM debugging output
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > Add debugging during SDRAM init so that problems are easier to > diagnose. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > > arch/x86/cpu/broadwell/sdram.c | 32 > 1 file changed, 20 insertions(+), 12 deletions(-) > applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 20/50] x86: Add support for starting from SPL/TPL
On Wed, May 1, 2019 at 9:03 PM Bin Meng wrote: > > On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > > > When a previous phase of U-Boot has run we need to adjust the init of > > subsequent states to avoid messing up the CPU state. > > > > Add a new version of the start logic for SPL, when it boots from TPL > > (start_from tpl.c) and a new version for U-Boot when it boots from SPL. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v2: > > - Add xorl to TPL code also > > - Update comments in start_from_tpl to correctly explain SPL state > > > > arch/x86/Makefile | 12 ++ > > arch/x86/cpu/Makefile | 15 +++- > > arch/x86/cpu/start_from_spl.S | 71 +++ > > arch/x86/cpu/start_from_tpl.S | 49 > > 4 files changed, 146 insertions(+), 1 deletion(-) > > create mode 100644 arch/x86/cpu/start_from_spl.S > > create mode 100644 arch/x86/cpu/start_from_tpl.S > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 17/50] x86: broadwell: Allow SDRAM init from SPL
On Wed, May 1, 2019 at 9:03 PM Bin Meng wrote: > > On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > > > At present, for broadwell, SDRAM is always set up in U-Boot proper since > > the 64-bit mode (which uses SDRAM init in SPL) is not supported. > > > > Update the code to allow SDRAM init in SPL instead so that U-Boot proper > > can be loaded into SDRAM and run from there. This allows U-Boot to be > > compressed to reduce space, since it is not necessary to run it directly > > from flash. It could later allow us to support 64-bit U-Boot on broadwell. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v2: > > - Update commit message to make it clear this patch is just for broadwell > > - Bring in sdram_console_tx_byte() to allow debugging > > > > arch/x86/cpu/broadwell/Makefile | 2 +- > > arch/x86/cpu/broadwell/northbridge.c | 100 +++ > > arch/x86/cpu/broadwell/sdram.c | 93 - > > 3 files changed, 101 insertions(+), 94 deletions(-) > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 18/50] x86: Move init of debug UART to cpu.c
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > At present the debug UART is set up in sdram.c which is not the best place > since it has nothing in particular to do with SDRAM. Since we want to > support initing this in SPL too, move it to a common file. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > > arch/x86/cpu/broadwell/cpu.c | 13 + > arch/x86/cpu/broadwell/sdram.c | 11 --- > 2 files changed, 13 insertions(+), 11 deletions(-) > applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 19/50] x86: broadwell: Split CPU init
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > Split the CPU init into two parts - the 'full' init which happens in the > first U-Boot phase, and the rest of the init that happens on subsequent > stages. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > > arch/x86/cpu/broadwell/Makefile | 1 + > arch/x86/cpu/broadwell/cpu.c | 673 - > arch/x86/cpu/broadwell/cpu_full.c | 694 ++ > 3 files changed, 695 insertions(+), 673 deletions(-) > create mode 100644 arch/x86/cpu/broadwell/cpu_full.c > applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 21/50] x86: Allow 16-bit init to be in TPL
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > At present we support having 16-bit init be in SPL or U-Boot proper, but > not TPL. Add support for this so that TPL can boot. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > > Makefile | 1 + > arch/x86/Makefile | 4 ++-- > arch/x86/cpu/intel_common/Makefile | 2 +- > arch/x86/cpu/u-boot-spl.lds| 2 +- > scripts/Makefile.spl | 10 +- > 5 files changed, 14 insertions(+), 5 deletions(-) > applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 22/50] x86: broadwell: Allow booting from SPL
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > At present broadwell only supports booting straight into U-Boot proper. > Add a separate init file to boot from SPL into U-Boot proper, and select > it when SPL is in use. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > > arch/x86/cpu/broadwell/Makefile | 15 +++ > arch/x86/cpu/broadwell/cpu_from_spl.c | 63 +++ > 2 files changed, 78 insertions(+) > create mode 100644 arch/x86/cpu/broadwell/cpu_from_spl.c > applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 25/50] x86: Support saving MRC data from SPL
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > When SPL is used to set up the memory controller we want to save the MRC > data in SPL to avoid needing to pass it up to U-Boot proper to save. Add a > function to handle that. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > > arch/x86/include/asm/mrccache.h | 11 ++ > arch/x86/lib/mrccache.c | 36 - > 2 files changed, 38 insertions(+), 9 deletions(-) > applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 24/50] x86: Add common Intel code for SPL
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > Add an implementation of arch_cpu_init_f() so that the x86 SPL code builds > and identifies the CPU. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > > arch/x86/cpu/intel_common/Makefile | 6 ++ > arch/x86/cpu/intel_common/cpu_from_spl.c | 27 > 2 files changed, 33 insertions(+) > create mode 100644 arch/x86/cpu/intel_common/cpu_from_spl.c > applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 23/50] x86: broadwell: Select refcode and CPU code for SPL
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > Allow broadwell to build for SPL and include the reference code. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > > arch/x86/cpu/broadwell/Makefile | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 26/50] x86: Add a simple TPL implementation
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > Add the required CPU code so that TPL builds correctly. Also update the > SPL code to deal with being booted from TPL. > > Reviewed-by: Bin Meng > Signed-off-by: Simon Glass > --- > > Changes in v2: None > > arch/x86/include/asm/spl.h| 17 - > arch/x86/lib/Makefile | 9 ++- > arch/x86/lib/spl.c| 44 ++- > arch/x86/lib/tpl.c| 118 ++ > include/configs/chromebook_link.h | 3 - > include/configs/qemu-x86.h| 3 - > 6 files changed, 183 insertions(+), 11 deletions(-) > create mode 100644 arch/x86/lib/tpl.c > This patch does not apply cleanly. Applying: x86: Add a simple TPL implementation error: patch failed: include/configs/chromebook_link.h:20 error: include/configs/chromebook_link.h: patch does not apply error: patch failed: include/configs/qemu-x86.h:37 error: include/configs/qemu-x86.h: patch does not apply Patch failed at 0001 x86: Add a simple TPL implementation Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 27/50] x86: mrccache: Add more debugging
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > When the MRC cache fails to save it is useful to have some debugging info > to indicate what when wrong. Add some more debug() calls. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > > arch/x86/lib/mrccache.c | 16 > 1 file changed, 12 insertions(+), 4 deletions(-) > applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 29/50] x86: pch: Add an ioctl to read power-management info
On Wed, May 1, 2019 at 9:42 PM Bin Meng wrote: > > On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > > > Add a new ioctl() request to read information about the power-management > > system. This can be used to power off the device. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v2: > > - Add new patch to add an ioctl to read power-management info > > > > include/pch.h | 18 ++ > > 1 file changed, 18 insertions(+) > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 30/50] x86: ivybridge: Implement PCH_REQ_PMBASE_INFO
On Wed, May 1, 2019 at 9:42 PM Bin Meng wrote: > > On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > > > Implement this ioctl() to support power off. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v2: > > - Add new patch to implement PCH_REQ_PMBASE_INFO on ivybridge > > > > arch/x86/cpu/ivybridge/bd82x6x.c | 15 +++ > > 1 file changed, 15 insertions(+) > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 33/50] x86: Support TPL in Intel common code
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > Update the Makefie rules to ensure that the correct files are built when > TPL is being used. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > > arch/x86/cpu/intel_common/Makefile | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 31/50] x86: broadwell: Implement PCH_REQ_PMBASE_INFO
On Wed, May 1, 2019 at 10:50 PM Bin Meng wrote: > > On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > > > Implement this ioctl() to support power off. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v2: > > - Add new patch to implement PCH_REQ_PMBASE_INFO on broadwell > > > > arch/x86/cpu/broadwell/pch.c | 25 + > > 1 file changed, 25 insertions(+) > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 35/50] x86: Don't generate a bootstage report in SPL
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > This report is normally generated by U-Boot proper. Correct the condition > here so that it respects the Kconfig options for bootstage. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > > arch/x86/lib/bootm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 34/50] x86: Don't set up MTRRs in SPL
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > The MTRRs are normally set up in U-Boot proper, so avoid setting them up > in SPL as well. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > > arch/x86/lib/init_helpers.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 36/50] x86: Support PCI VGA ROM when TPL is used
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > When TPL is in use, U-Boot proper should support initing the VGA ROM even > though the 32-bit init portion is in SPL. Update the condition to handle > this. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > > drivers/pci/pci_rom.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 37/50] x86: sysreset: Implement the get_last() method
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > Add a default implementation of this method which always indicates that > the last reset was a power-on reset. This is the most likely type of reset > and without a PCH-specific driver we cannot determine any other type. > > Signed-off-by: Simon Glass > --- > > Changes in v2: None > > drivers/sysreset/sysreset_x86.c | 6 ++ > 1 file changed, 6 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 v3] Convert CONFIG_SUPPORT_EMMC_BOOT to Kconfig
On Wed, May 1, 2019 at 3:49 PM Tom Rini wrote: > > On Wed, May 01, 2019 at 07:58:27AM +, Alex Kiernan wrote: > > This converts the following to Kconfig: > >CONFIG_SUPPORT_EMMC_BOOT > > > > As requested by Michal Simek , these boards > > have no eMMC so CONFIG_SUPPORT_EMMC_BOOT has not been migrated: > > > > xilinx_zynqmp_zc1275_revB > > xilinx_zynqmp_zc1751_xm018_dc4 > > xilinx_zynqmp_zc1751_xm019_dc5 > > xilinx_zynqmp_zcu100_revC > > xilinx_zynqmp_zcu102_rev1_0 > > xilinx_zynqmp_zcu102_revA > > xilinx_zynqmp_zcu102_revB > > xilinx_zynqmp_zcu104_revA > > xilinx_zynqmp_zcu104_revC > > xilinx_zynqmp_zcu106_revA > > xilinx_zynqmp_zcu111_revA > > > > Signed-off-by: Alex Kiernan > > Acked-by: Lukasz Majewski > > Acked-by: Patrick Delaunay > > Acked-by: Ramon Fried > > Reviewed-by: Andy Shevchenko > > Tested-by: Sébastien Szymanski > > --- > > Green travis build: > > > > https://travis-ci.org/akiernan/u-boot/builds/526591535 > > > > Testing for configuration changes shows just the expected xilinx_zynqmp > > boards: > > So, FWIW, what I do (and will do for this patch when I check it out > before pushing) ends up as: > $ export SOURCE_DATE_EPOCH=`date +%s` > $ ./tools/buildman/buildman -o /tmp/test -b master --force-build --step 0 \ > -SCdvel \ > 'arc|arm|sandbox|x86|aarch64|powerpc|m68k|nios2|nds32|sh|mips|xtensa|riscv' > $ ./tools/buildman/buildman -o /tmp/test -b master --step 0 -Ssdel \ > 'arc|arm|sandbox|x86|aarch64|powerpc|m68k|nios2|nds32|sh|mips|xtensa|riscv' > > With the patch applied in some branch that has 'master' as the upstream. > This is basically a world-build and will size compare before/after, > noting changes. If I see a size difference (outside of a few boards > that include the config in the binary and so grow slightly on > conversions), I use: > $ export SOURCE_DATE_EPOCH=`date +%s` > $ ./tools/buildman/buildman -o /tmp/brd -b master --step 0 -SBCdevlk BOARD > $ ./tools/buildman/buildman -o /tmp/brd -b master --step 0 -SsBdevlk BOARD > > Which probably has a few more flags than required but will also tell > which functions within the binary have changed and so a good place to > hunt down what didn't convert correctly and why. > That's a useful set of snippets - thanks! -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 39/50] x86: samus: Update device tree for SPL
Hi Simon, On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > Add tags to allow required nodes to be present in SPL / TPL. Also enable > the sysreset driver. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > > arch/x86/dts/chromebook_samus.dts | 38 +++ > 1 file changed, 34 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/dts/chromebook_samus.dts > b/arch/x86/dts/chromebook_samus.dts > index 35211ed81b1..6664c3b7d36 100644 > --- a/arch/x86/dts/chromebook_samus.dts > +++ b/arch/x86/dts/chromebook_samus.dts > @@ -17,6 +17,7 @@ > spi0 = &spi; > usb0 = &usb_0; > usb1 = &usb_1; > + cros-ec0 = &cros_ec; > }; > > config { > @@ -73,6 +74,7 @@ > > /* Put this first: it is the default */ > gpio_unused: gpio-unused { > + u-boot,dm-pre-reloc; > mode-gpio; > direction = ; > owner = ; > @@ -80,6 +82,7 @@ > }; > > gpio_acpi_sci: acpi-sci { > + u-boot,dm-pre-reloc; > mode-gpio; > direction = ; > invert; > @@ -87,6 +90,7 @@ > }; > > gpio_acpi_smi: acpi-smi { > + u-boot,dm-pre-reloc; > mode-gpio; > direction = ; > invert; > @@ -94,12 +98,14 @@ > }; > > gpio_input: gpio-input { > + u-boot,dm-pre-reloc; > mode-gpio; > direction = ; > owner = ; > }; > > gpio_input_invert: gpio-input-invert { > + u-boot,dm-pre-reloc; > mode-gpio; > direction = ; > owner = ; > @@ -107,9 +113,11 @@ > }; > > gpio_native: gpio-native { > + u-boot,dm-pre-reloc; > }; > > gpio_out_high: gpio-out-high { > + u-boot,dm-pre-reloc; > mode-gpio; > direction = ; > output-value = <1>; > @@ -118,6 +126,7 @@ > }; > > gpio_out_low: gpio-out-low { > + u-boot,dm-pre-reloc; > mode-gpio; > direction = ; > output-value = <0>; > @@ -126,6 +135,7 @@ > }; > > gpio_pirq: gpio-pirq { > + u-boot,dm-pre-reloc; > mode-gpio; > direction = ; > owner = ; > @@ -133,6 +143,7 @@ > }; > > soc_gpio@0 { > + u-boot,dm-pre-reloc; > config = > <0 &gpio_unused 0>, /* unused */ > <1 &gpio_unused 0>, /* unused */ > @@ -250,8 +261,10 @@ > spd { > #address-cells = <1>; > #size-cells = <0>; > + u-boot,dm-pre-reloc; > samsung_4 { > reg = <6>; > + u-boot,dm-pre-reloc; > data = [91 20 f1 03 04 11 05 0b > 03 11 01 08 0a 00 50 01 > 78 78 90 50 90 11 50 e0 > @@ -291,6 +304,7 @@ > * columns 10, density 4096 mb, x32 > */ > reg = <8>; > + u-boot,dm-pre-reloc; > data = [91 20 f1 03 04 11 05 0b > 03 11 01 08 0a 00 50 01 > 78 78 90 50 90 11 50 e0 > @@ -326,6 +340,7 @@ > }; > samsung_8 { > reg = <10>; > + u-boot,dm-pre-reloc; > data = [91 20 f1 03 04 12 05 0a > 03 11 01 08 0a 00 50 01 > 78 78 90 50 90 11 50 e0 > @@ -365,6 +380,7 @@ > * columns 11, density 4096 mb, x16 > */ > reg = <12>; > +
Re: [U-Boot] [PATCH v2 41/50] x86: Update device tree for TPL
Hi Simon, On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > Add TPL binaries to the device x86 binman desciption. When enabled, TPL > will start first, doing the 16-bit init, then jump to SPL and finally > U-Boot proper. > > Signed-off-by: Simon Glass > --- > > Changes in v2: None > > arch/x86/dts/u-boot.dtsi | 26 -- > 1 file changed, 24 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/dts/u-boot.dtsi b/arch/x86/dts/u-boot.dtsi > index 1050236330a..70e9c8f7acd 100644 > --- a/arch/x86/dts/u-boot.dtsi > +++ b/arch/x86/dts/u-boot.dtsi > @@ -22,7 +22,21 @@ > filename = CONFIG_INTEL_ME_FILE; > }; > #endif > -#ifdef CONFIG_SPL > +#ifdef CONFIG_TPL > + u-boot-spl { > + offset = ; > + }; > + u-boot-spl-dtb { > + }; > + u-boot-tpl-with-ucode-ptr { > + offset = ; > + }; > + u-boot-tpl-dtb { > + }; nits: since TPL starts before SPL, can we put the TPL* nodes before SPL* nodes? > + u-boot { > + offset = ; > + }; > +#elif defined(CONFIG_SPL) > u-boot-spl-with-ucode-ptr { > offset = ; > }; > @@ -31,7 +45,11 @@ > type = "u-boot-dtb-with-ucode"; > }; > u-boot { > +#if CONFIG_SYS_TEXT_BASE == 0x111 The magic number comparison does not look good. > offset = <0xfff0>; > +#else > + offset = ; > +#endif > }; > #else > u-boot-with-ucode-ptr { > @@ -77,7 +95,11 @@ > offset = ; > }; > #endif > -#ifdef CONFIG_SPL > +#ifdef CONFIG_TPL > + x86-start16-tpl { > + offset = ; > + }; > +#elif defined(CONFIG_SPL) > x86-start16-spl { > offset = ; > }; > -- Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 45/50] Revert "pci: Scale MAX_PCI_REGIONS based on CONFIG_NR_DRAM_BANKS"
+Thierry On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > This reverts commit aec4298ccb337106fd0115b91d846a022fdf301d. > > Unfortunately this has a dramatic impact on the pre-relocation memory > used on x86 platforms (increasing it by 2KB) since it increases the > overhead for each PCI device from 220 bytes to 412 bytes. > > The offending line is in UCLASS_DRIVER(pci): > > .per_device_auto_alloc_size = sizeof(struct pci_controller), > > This means that all PCI devices have the controller struct associated > with them. The solution is to move the regions[] member out of the array, > makes its size dynamic, or split UCLASS_PCI into controllers and > non-controllers, as the comment suggests. > > For now, revert the commit to get things running again. > > Signed-off-by: Simon Glass > --- > > Changes in v2: None > > include/pci.h | 6 +- > 1 file changed, 1 insertion(+), 5 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 v2 46/50] x86: Enable the RTC on all boards
Hi Simon, On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > With the move to Kconfig this option should be set in Kconfig, not in the > config header file. Move it. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Add new patch to enable the RTC in Kconfig > > arch/Kconfig | 1 + > configs/chromebook_link_defconfig | 1 + > include/configs/x86-common.h | 1 - > 3 files changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/Kconfig b/arch/Kconfig > index a1d1ac301d6..2a93b72dbc4 100644 > --- a/arch/Kconfig > +++ b/arch/Kconfig > @@ -165,6 +165,7 @@ config X86 > imply USB_ETHER_SMSC95XX > imply USB_HOST_ETHER > imply PCH > + imply RTC_MC146818 > > # Thing to enable for when SPL/TPL are enabled: SPL > imply SPL_DM > diff --git a/configs/chromebook_link_defconfig > b/configs/chromebook_link_defconfig > index 6058dfaf0f2..b1c5095ec92 100644 > --- a/configs/chromebook_link_defconfig > +++ b/configs/chromebook_link_defconfig > @@ -53,6 +53,7 @@ CONFIG_DM_I2C=y > CONFIG_SYS_I2C_INTEL=y > CONFIG_CROS_EC=y > CONFIG_CROS_EC_LPC=y > +CONFIG_RTC_MC146818=y This has been implied in arch/Kconfig above, why adding another one here? > CONFIG_SYS_NS16550=y > CONFIG_SOUND=y > CONFIG_SPI=y Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 47/50] x86: Update the memory map a little
Hi Simon, On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > The memory map currently omits the environment and the MRC region. Add > these in for completeness. > I think the commit tile should be updated to add the "samus" tag. > Signed-off-by: Simon Glass > --- > > Changes in v2: None > > doc/README.x86 | 2 ++ > 1 file changed, 2 insertions(+) > Reviewed-by: Bin Meng Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 48/50] x86: broadwell: Update PCH to work in TPL
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > The early init should only happen once. Update the probe method to > deal with TPL, SPL and U-Boot proper. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Add a new patch to update PCH to work in TPL > > arch/x86/cpu/broadwell/pch.c | 12 +--- > 1 file changed, 9 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 v2 49/50] x86: Add a way to jump from TPL to SPL
Hi Simon, On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: > > When TPL finishes it needs to jump to SPL with the stack set up correctly. > Add a function to handle this. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Add a new patch allowing jumping from TPL to SPL > > arch/x86/cpu/start.S | 13 + > 1 file changed, 13 insertions(+) > Reviewed-by: Bin Meng But I don't see any patch in this series that makes use of this new jump_to_spl()? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/50] x86: Add support for booting from TPL
Hi Simon, On Fri, Apr 26, 2019 at 11:59 AM Simon Glass wrote: > > At present SPL is used on 64-bit platforms, to allow SPL to be built as > a 32-bit program and U-Boot proper to be built as 64-bit. > > However it is useful to be able to use SPL on any x86 platform, where > U-Boot needs to be updated in the field. Then SPL can select which U-Boot > to run (A or B) and most of the code can be updated. Similarly, using TPL > allows both SPL and U-Boot to be updated. This is the best approach, since > it means that all of U-Boot proper as well as SPL (in particular SDRAM > init) can be updated in the field. This provides for the smallest possible > amount of read-only (non-updateable) code: just the TPL code. > > This series contains a number of changes to allow x86 boards to use TPL, > SPL and U-Boot proper. As a test, it is enabled for samus with a new > chromebook_samus_tpl board. > I've applied 32 patches in this series to u-boot-x86/master. Remaining patches need to rebase on that. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_selftest: test exit_data
Amend the unit test 'start image exit' to transfer a string as exit data. Signed-off-by: Heinrich Schuchardt --- include/efi_selftest.h | 2 +- lib/efi_selftest/efi_selftest_miniapp_exit.c| 17 - lib/efi_selftest/efi_selftest_startimage_exit.c | 15 ++- 3 files changed, 27 insertions(+), 7 deletions(-) diff --git a/include/efi_selftest.h b/include/efi_selftest.h index 49d3d6d0b4..dd42e49023 100644 --- a/include/efi_selftest.h +++ b/include/efi_selftest.h @@ -16,7 +16,7 @@ #define EFI_ST_SUCCESS 0 #define EFI_ST_FAILURE 1 - +#define EFI_ST_SUCCESS_STR L"SUCCESS" /* * Prints a message. */ diff --git a/lib/efi_selftest/efi_selftest_miniapp_exit.c b/lib/efi_selftest/efi_selftest_miniapp_exit.c index b3ca109d81..6b5cfb01cf 100644 --- a/lib/efi_selftest/efi_selftest_miniapp_exit.c +++ b/lib/efi_selftest/efi_selftest_miniapp_exit.c @@ -9,7 +9,7 @@ */ #include -#include +#include static efi_guid_t loaded_image_protocol_guid = EFI_LOADED_IMAGE_PROTOCOL_GUID; @@ -66,15 +66,22 @@ efi_status_t EFIAPI efi_main(efi_handle_t handle, struct efi_system_table *systable) { struct efi_simple_text_output_protocol *con_out = systable->con_out; - efi_status_t ret = EFI_UNSUPPORTED; + efi_status_t ret; + u16 text[] = EFI_ST_SUCCESS_STR; con_out->output_string(con_out, L"EFI application calling Exit\n"); - if (check_loaded_image_protocol(handle, systable) != EFI_SUCCESS) + if (check_loaded_image_protocol(handle, systable) != EFI_SUCCESS) { + con_out->output_string(con_out, + L"Loaded image protocol missing\n"); ret = EFI_NOT_FOUND; + goto out; + } - /* The return value is checked by the calling test */ - systable->boottime->exit(handle, ret, 0, NULL); + /* This return value is expected by the calling test */ + ret = EFI_UNSUPPORTED; +out: + systable->boottime->exit(handle, ret, sizeof(text), text); /* * This statement should not be reached. diff --git a/lib/efi_selftest/efi_selftest_startimage_exit.c b/lib/efi_selftest/efi_selftest_startimage_exit.c index fa4b7d4a9b..96049dea86 100644 --- a/lib/efi_selftest/efi_selftest_startimage_exit.c +++ b/lib/efi_selftest/efi_selftest_startimage_exit.c @@ -123,6 +123,9 @@ static int execute(void) { efi_status_t ret; efi_handle_t handle; + efi_uintn_t exit_data_size = 0; + u16 *exit_data = NULL; + u16 expected_text[] = EFI_ST_SUCCESS_STR; ret = boottime->load_image(false, image_handle, NULL, image, img.length, &handle); @@ -130,11 +133,21 @@ static int execute(void) efi_st_error("Failed to load image\n"); return EFI_ST_FAILURE; } - ret = boottime->start_image(handle, NULL, NULL); + ret = boottime->start_image(handle, &exit_data_size, &exit_data); if (ret != EFI_UNSUPPORTED) { efi_st_error("Wrong return value from application\n"); return EFI_ST_FAILURE; } + if (!exit_data || exit_data_size != sizeof(expected_text) || + efi_st_memcmp(exit_data, expected_text, sizeof(expected_text))) { + efi_st_error("Incorrect exit data\n"); + return EFI_ST_FAILURE; + } + ret = boottime->free_pool(exit_data); + if (ret != EFI_SUCCESS) { + efi_st_error("Failed to free exit data\n"); + return EFI_ST_FAILURE; + } return EFI_ST_SUCCESS; } -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] RISCV: image: Parse Image.gz support in booti.
On 5/1/19 3:34 AM, Marek Vasut wrote: On 5/1/19 12:06 AM, Atish Patra wrote: On 4/30/19 2:42 PM, Marek Vasut wrote: On 4/30/19 10:38 PM, Atish Patra wrote: On 4/30/19 12:11 PM, Marek Vasut wrote: On 4/30/19 8:13 PM, Atish Patra wrote: On 4/30/19 2:52 AM, Marek Vasut wrote: On 4/30/19 3:27 AM, Atish Patra wrote: [...] Yes. FIT image parsing can be done in that way. However, the idea was here to load Image.gz directly. Image.gz is default compressed Linux kernel image format in RISC-V. Sigh, and the image header is compressed as well, so there's no way to identify the image format, right ? And there's no decompressor, so the dcompressing has to be done by bootloader, which would need some sort of very smart way of figuring out which exact compression method is used ? Yes. Image.gz is always gunzip. So checking first two bytes is enough to confirm that it is a gz file. What happens once people start feeding it more exotic compression methods, like LZ4 or LZO or LZMA for example ? booti command help will clearly state that it can only boot kernel from Image or Image.gz. static char booti_help_text[] = "[addr [initrd[:size]] [fdt]]\n" - " - boot arm64 Linux Image stored in memory\n" + " - boot arm64 Linux Image or riscv Linux Image/Image.gz stored in memory\n" Obvious question -- does this Image.gz stuff apply to arm64 ? arm64 builds Image.gz but booti for arm64 doesn't use it. I guess Image.gz can be used in FIT image for ARM64 but I am not sure which platform actually uses it. This patch only enables support for RISC-V. Can't this be made generic ? I think so if I just move the gzip detection and decompression code to cmd/booti.c. I will update the v3 patch with this. Nice, thanks. But since you're basically implementing file(1)-lite, I wonder whether there isn't similar code somewhere in u-boot already. I was hoping to find one as well. But I couldn't. I can add a generic gz detection function(same file(1)-lite approach) to a lib/gunzip.c Regards, Atish ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] WaRP7 nok on master
Hi Fabio, Stefano, Just FYI, I just tested the U-Boot master branch (with u-boot-imx merges). And I have some problems when the WaRP7 boot-up. In fact, no output... However, on u-boot-imx, everything works well (tags/u-boot-imx-20190426). After some manipulation with git bisect, it appears that the problem comes from commit [1]. So, with a git revert 3a7c45f6a7725808e2e82908be4bc90d4d78e737, everything works again. Without this revert, the WaRP7 is not functional (also the pico-pi i.MX7 if DM_SERIAL is implemented, tested by Joris in CC). Thanks BR /Pierre-Jean [1] https://github.com/trini/u-boot/commit/3a7c45f6a7725808e2e82908be4bc90d4d78e737 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 28/50] x86: sysreset: Separate out the EFI code
On 5/1/19 3:42 PM, Bin Meng wrote: +Heinrich, On Fri, Apr 26, 2019 at 12:00 PM Simon Glass wrote: The EFI implementation of reset sits inside the driver and is called directly from outside the driver, breaking the normal driver-model conventions. Worse, it passed NULL as the device pointer, hoping that the called function won't use it, which breaks as soon as code is added to use it. Separate out the implementation to improve the situation enough to allow a future patch to add new sysreset features. Signed-off-by: Simon Glass --- Changes in v2: - Add new patch to separate out the EFI code in sysreset drivers/sysreset/sysreset_x86.c | 16 +++- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/drivers/sysreset/sysreset_x86.c b/drivers/sysreset/sysreset_x86.c index 009f3766027..d484ec5de49 100644 --- a/drivers/sysreset/sysreset_x86.c +++ b/drivers/sysreset/sysreset_x86.c @@ -12,8 +12,7 @@ #include #include -static __efi_runtime int x86_sysreset_request(struct udevice *dev, - enum sysreset_t type) I remember last time I tried when booting Linux from EFI loader on U-Boot, calling from kernel into the EFI runtime was broken. Not sure what the latest status is. I have no x86 system using U-Boot. On ARM I am not aware of problems. Last year I had no success booting up qemu-x86_defconfig with Linux via EFI. Maybe I should retry. Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] lib: uuid: Improve randomness of uuid values on RANDOM_UUID=y
Hi Heinrich, Thank you for reviewing this series. On Tue, Apr 30, 2019 at 09:07:09PM +0200, Heinrich Schuchardt wrote: [..] > This patch may ameliorate the situation for GUIDs a bit. But I dislike: In general, we can find reasons to dislike anything, since there is room for improvement in virtually anything. > > - This patch is a uuid only solution to introduce time ticks as source > of entropy. I would like to clarify once again what this patch is about. It _fixes_ (hence I will rewrite the summary line in the next patch revision) a concrete real-life problem of providing repeatable (not predictable - which implies some effort in my mind - but literally repeatable) uuid values on enabling CONFIG_RANDOM_UUID. It is my understanding that CONFIG_RANDOM_UUID (based on its name and help message) does promise random uuids to the user. If so, then U-Boot simply breaks this promise. While doing additional research on PRNG, it looks to me that there is an established class of PRNG-specific problems, commonly known as "unseeded randomness" for which I am also able to find below CVE/CWE: - https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0285 ("CVE-2015-0285 openssl: handshake with unseeded PRNG") - https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-9019 ("CVE-2015-9019 libxslt: math.random() in xslt uses unseeded randomness") - https://cwe.mitre.org/data/definitions/336.html ("CWE-336: Same Seed in Pseudo-Random Number Generator (PRNG)") The above tells me that using the same seed yields the same sequence of random numbers. That's precisely the topic of this patch: simply switching from unseeded PRNG to seeded PRNG. And yes, this patch is deliberately limited to UUID naming function, since it is lib/uuid's responsibility to seed the PRNG. The same is true for other callers of rand() and rand_r(). All of them seed the PRNG prior to getting a random value from it. > - With timer ticks you possibly introduce very little entropy. Theoretically, yes. Practically, the improvement to the current state of affairs is huge and this has been testified by the test results linked in the description. Again, this patch is not about improving the random pattern of the UUID values (sorry for the misleading title). It is really about _enabling_ any kind of randomness in those values at all. > - Our random number generator with only 32 state bits remains > sub-standard. I believe this is orthogonal to my patch and can be improved independently. In addition, whatever is the bit-width of U-Boot PRNG (I can find shootouts between various 64/128/256-bit PRNG) its essence will not change. It will remain a deterministic number generator, whose randomness will still be dictated by the seed. > > This is the current situation: > > net/bootp.c uses the MAC address to seed the random number generator and > uses random numbers for defining waits. > > lib/uuid.c is using it for UUID generation. I can see that rfc4122 suggests including MAC address in the UUID, but it also warns that MAC address could be unavailable: --- For systems with no IEEE address, a randomly or pseudo-randomly generated value may be used; --- The guess is right. Some SoCs like R-Car3 (in contrast to e.g. i.MX6) don't provide any OTP memory/register containing their unique MAC address. Needless to say some machines would never connect to IEEE network. So, it looks to me that MAC address cannot be taken as consistent source of entropy for UUID in U-Boot. > > In the UEFI sub-system I would like to implement the EFI_RNG_PROTOCOL. > Linux uses it for randomizing memory layout. iPXE needs it for secure > network connections. This requires a good random number generator with > sufficient entropy. > > We already have implemented a single hardware random number generator in > drivers/crypto/ace_sha.c (CONFIG_EXYNOS_ACE_SHA). > > Many other CPUs come with a hardware random number generator. In Linux's > drivers/char/hw_random/ I found, e.g. > > - meson-rng.c (Amlogic) > - mtk-rng.c (MediaTek) > - st-rng.c (STMicroelectronics) > - imx-rng.c (Freescale) To the best of my knowledge, there is no HW RNG on R-Car3, so our only option is currently U-Boot PRNG. > > I think we should have a u-class for hardware RNGs as one source of entropy. > > I would like a random number generator with a high number of state bits > (> 127) that we initialize with hardware RNG bits and other sources of > entropy. A nice discussion of how Linux does it can be found in [1]. All sound like future topics to me, orthogonal to this patch. Let me know if I misunderstood anything. TIA! > > Best regards > > Heinrich > > [1] > https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/LinuxRNG/LinuxRNG_EN.pdf > -- Best Regards, Eugeniu. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] lib: uuid: Improve randomness of uuid values on RANDOM_UUID=y
On Wed, May 01, 2019 at 09:08:31PM +0200, Eugeniu Rosca wrote: > Hi Heinrich, > > Thank you for reviewing this series. > > On Tue, Apr 30, 2019 at 09:07:09PM +0200, Heinrich Schuchardt wrote: > [..] > > This patch may ameliorate the situation for GUIDs a bit. But I dislike: > > In general, we can find reasons to dislike anything, since there is room > for improvement in virtually anything. > > > > > - This patch is a uuid only solution to introduce time ticks as source > > of entropy. > > I would like to clarify once again what this patch is about. It _fixes_ > (hence I will rewrite the summary line in the next patch revision) a > concrete real-life problem of providing repeatable (not predictable - > which implies some effort in my mind - but literally repeatable) uuid > values on enabling CONFIG_RANDOM_UUID. > > It is my understanding that CONFIG_RANDOM_UUID (based on its name > and help message) does promise random uuids to the user. If so, then > U-Boot simply breaks this promise. > > While doing additional research on PRNG, it looks to me that there is > an established class of PRNG-specific problems, commonly known as > "unseeded randomness" for which I am also able to find below CVE/CWE: > - https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0285 >("CVE-2015-0285 openssl: handshake with unseeded PRNG") > - https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-9019 >("CVE-2015-9019 libxslt: math.random() in xslt uses unseeded randomness") > - https://cwe.mitre.org/data/definitions/336.html >("CWE-336: Same Seed in Pseudo-Random Number Generator (PRNG)") > > The above tells me that using the same seed yields the same sequence > of random numbers. That's precisely the topic of this patch: simply > switching from unseeded PRNG to seeded PRNG. > > And yes, this patch is deliberately limited to UUID naming function, > since it is lib/uuid's responsibility to seed the PRNG. The same is > true for other callers of rand() and rand_r(). All of them seed the > PRNG prior to getting a random value from it. > > > - With timer ticks you possibly introduce very little entropy. > > Theoretically, yes. Practically, the improvement to the current state > of affairs is huge and this has been testified by the test results > linked in the description. > > Again, this patch is not about improving the random pattern of the UUID > values (sorry for the misleading title). It is really about _enabling_ > any kind of randomness in those values at all. > > > - Our random number generator with only 32 state bits remains > > sub-standard. > > I believe this is orthogonal to my patch and can be improved > independently. In addition, whatever is the bit-width of U-Boot PRNG > (I can find shootouts between various 64/128/256-bit PRNG) its essence > will not change. It will remain a deterministic number generator, > whose randomness will still be dictated by the seed. > > > > > This is the current situation: > > > > net/bootp.c uses the MAC address to seed the random number generator and > > uses random numbers for defining waits. > > > > lib/uuid.c is using it for UUID generation. > > I can see that rfc4122 suggests including MAC address in the UUID, but > it also warns that MAC address could be unavailable: > > --- >For systems with no IEEE address, a randomly or pseudo-randomly >generated value may be used; > --- > > The guess is right. Some SoCs like R-Car3 (in contrast to e.g. i.MX6) > don't provide any OTP memory/register containing their unique MAC > address. Needless to say some machines would never connect to IEEE > network. So, it looks to me that MAC address cannot be taken as > consistent source of entropy for UUID in U-Boot. Indeed, we have a lot of platforms where the MAC is not a great source. > > In the UEFI sub-system I would like to implement the EFI_RNG_PROTOCOL. > > Linux uses it for randomizing memory layout. iPXE needs it for secure > > network connections. This requires a good random number generator with > > sufficient entropy. > > > > We already have implemented a single hardware random number generator in > > drivers/crypto/ace_sha.c (CONFIG_EXYNOS_ACE_SHA). > > > > Many other CPUs come with a hardware random number generator. In Linux's > > drivers/char/hw_random/ I found, e.g. > > > > - meson-rng.c (Amlogic) > > - mtk-rng.c (MediaTek) > > - st-rng.c (STMicroelectronics) > > - imx-rng.c (Freescale) > > To the best of my knowledge, there is no HW RNG on R-Car3, so our only > option is currently U-Boot PRNG. And we have a lot of systems without HW RNG. > > I think we should have a u-class for hardware RNGs as one source of entropy. > > > > I would like a random number generator with a high number of state bits > > (> 127) that we initialize with hardware RNG bits and other sources of > > entropy. A nice discussion of how Linux does it can be found in [1]. > > All sound like future topics to me, orthogonal to this patch. > Let me k
[U-Boot] [v3 PATCH] RISCV: image: Add booti support.
This patch adds booti support for RISC-V Linux kernel. The existing bootm method will also continue to work as it is. It depends on the following kernel patch which adds the header to the flat Image. Gzip compressed Image (Image.gz) support is not enabled with this patch. https://patchwork.kernel.org/patch/10925543/ Tested on HiFive Unleashed and QEMU. Signed-off-by: Atish Patra -- Changes from v2->v3 1. Updated the image header structure as per kernel patch. 2. Removed Image.gz support as it will be added as separate RFC patch. --- arch/riscv/lib/Makefile | 1 + arch/riscv/lib/image.c | 55 + cmd/Kconfig | 2 +- cmd/booti.c | 8 -- 4 files changed, 63 insertions(+), 3 deletions(-) create mode 100644 arch/riscv/lib/image.c diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile index 1c332db436a9..6ae6ebbeafda 100644 --- a/arch/riscv/lib/Makefile +++ b/arch/riscv/lib/Makefile @@ -7,6 +7,7 @@ # Rick Chen, Andes Technology Corporation obj-$(CONFIG_CMD_BOOTM) += bootm.o +obj-$(CONFIG_CMD_BOOTI) += bootm.o image.o obj-$(CONFIG_CMD_GO) += boot.o obj-y += cache.o obj-$(CONFIG_RISCV_RDTIME) += rdtime.o diff --git a/arch/riscv/lib/image.c b/arch/riscv/lib/image.c new file mode 100644 index ..d063beb7dfbe --- /dev/null +++ b/arch/riscv/lib/image.c @@ -0,0 +1,55 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2019 Western Digital Corporation or its affiliates. + * Authors: + * Atish Patra + * Based on arm/lib/image.c + */ + +#include +#include +#include +#include +#include + +DECLARE_GLOBAL_DATA_PTR; + +/* ASCII version of "RISCV" defined in Linux kernel */ +#define LINUX_RISCV_IMAGE_MAGIC 0x5643534952 + +struct linux_image_h { + uint32_tcode0; /* Executable code */ + uint32_tcode1; /* Executable code */ + uint64_ttext_offset;/* Image load offset */ + uint64_timage_size; /* Effective Image size */ + uint64_tres1; /* reserved */ + uint64_tres2; /* reserved */ + uint64_tres3; /* reserved */ + uint64_tmagic; /* Magic number */ + uint32_tres4; /* reserved */ + uint32_tres5; /* reserved */ +}; + +int booti_setup(ulong image, ulong *relocated_addr, ulong *size, + bool force_reloc) +{ + struct linux_image_h *lhdr; + + lhdr = (struct linux_image_h *)map_sysmem(image, 0); + + if (lhdr->magic != LINUX_RISCV_IMAGE_MAGIC) { + puts("Bad Linux RISCV Image magic!\n"); + return -EINVAL; + } + + if (lhdr->image_size == 0) { + puts("Image lacks image_size field, error!\n"); + return -EINVAL; + } + *size = lhdr->image_size; + *relocated_addr = gd->ram_base + lhdr->text_offset; + + unmap_sysmem(lhdr); + + return 0; +} diff --git a/cmd/Kconfig b/cmd/Kconfig index 2bdbfcb3d091..d427b66d3714 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -212,7 +212,7 @@ config CMD_BOOTZ config CMD_BOOTI bool "booti" - depends on ARM64 + depends on ARM64 || RISCV default y help Boot an AArch64 Linux Kernel image from memory. diff --git a/cmd/booti.c b/cmd/booti.c index 04353b68eccc..c22ba9bae2e4 100644 --- a/cmd/booti.c +++ b/cmd/booti.c @@ -77,7 +77,11 @@ int do_booti(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) bootm_disable_interrupts(); images.os.os = IH_OS_LINUX; + #ifdef CONFIG_RISCV_SMODE + images.os.arch = IH_ARCH_RISCV; + #elif CONFIG_ARM64 images.os.arch = IH_ARCH_ARM64; + #endif ret = do_bootm_states(cmdtp, flag, argc, argv, #ifdef CONFIG_SYS_BOOT_RAMDISK_HIGH BOOTM_STATE_RAMDISK | @@ -92,7 +96,7 @@ int do_booti(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) #ifdef CONFIG_SYS_LONGHELP static char booti_help_text[] = "[addr [initrd[:size]] [fdt]]\n" - "- boot arm64 Linux Image stored in memory\n" + "- boot arm64/riscv Linux Image stored in memory\n" "\tThe argument 'initrd' is optional and specifies the address\n" "\tof an initrd in memory. The optional parameter ':size' allows\n" "\tspecifying the size of a RAW initrd.\n" @@ -107,5 +111,5 @@ static char booti_help_text[] = U_BOOT_CMD( booti, CONFIG_SYS_MAXARGS, 1, do_booti, - "boot arm64 Linux Image image from memory", booti_help_text + "boot arm64/riscv Linux Image image from memory", booti_help_text ); -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [v3 PATCH] RISCV: image: Add booti support.
On Wed, May 01, 2019 at 01:07:31PM -0700, Atish Patra wrote: > This patch adds booti support for RISC-V Linux kernel. The existing > bootm method will also continue to work as it is. > > It depends on the following kernel patch which adds the header to the > flat Image. Gzip compressed Image (Image.gz) support is not enabled with > this patch. > > https://patchwork.kernel.org/patch/10925543/ > > Tested on HiFive Unleashed and QEMU. > > Signed-off-by: Atish Patra > -- > Changes from v2->v3 > 1. Updated the image header structure as per kernel patch. > 2. Removed Image.gz support as it will be added as separate RFC patch. Reviewed-by: Tom Rini -- 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 u-boot-marvell v2.1 15/15] i2c: mvtwsi: fix reading status register after interrupt
The twsi_wait function reads the control register for interrupt flag, and if interrupt flag is present, it immediately reads status register. On our device this sometimes causes bad value being read from status register, as if the value was not yet updated. My theory is that the controller does approximately this: 1. sets interrupt flag in control register, 2. sets the value of status register, 3. causes an interrupt In U-Boot we do not use interrupts, so I think that it is possible that sometimes the status register in the twsi_wait function is read between points 1 and 2. The bug does not appear if I add a small delay before reading status register. Wait 100ns (which in U-Boot currently means 1 us, because ndelay(i) function calls udelay(DIV_ROUND_UP(i, 1000))) before reading the status register. Signed-off-by: Marek Behún Acked-by: Heiko Schocher Cc: Mario Six Cc: Stefan Roese Cc: Baruch Siach --- drivers/i2c/mvtwsi.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c index 74ac0a4aa7..0a2dafcec6 100644 --- a/drivers/i2c/mvtwsi.c +++ b/drivers/i2c/mvtwsi.c @@ -271,6 +271,17 @@ static int twsi_wait(struct mvtwsi_registers *twsi, int expected_status, do { control = readl(&twsi->control); if (control & MVTWSI_CONTROL_IFLG) { + /* +* On Armada 38x it seems that the controller works as +* if it first set the MVTWSI_CONTROL_IFLAG in the +* control register and only after that it changed the +* status register. +* This sometimes caused weird bugs which only appeared +* on selected I2C speeds and even then only sometimes. +* We therefore add here a simple ndealy(100), which +* seems to fix this weird bug. +*/ + ndelay(100); status = readl(&twsi->status); if (status == expected_status) return 0; -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot