Re: [U-Boot] [U-Boot, v6, 07/10] smbios: Generate type 4 on non-x86 systems
On 10/14/2016 07:21 AM, Bin Meng wrote: On Fri, Oct 14, 2016 at 1:13 PM, Alexander Graf wrote: Am 14.10.2016 um 03:50 schrieb Bin Meng : On Thu, Oct 13, 2016 at 10:35 PM, Alexander Graf wrote: The type 4 table generation code is very x86 centric today. Refactor things out into the device model cpu class to allow the tables to get generated for other architectures as well. Signed-off-by: Alexander Graf Reviewed-by: Simon Glass Reviewed-by: Bin Meng Thanks, applied to Applied to where? Sorry, my efi-next tree. At which repo? I don't see it at git.denx.de. I thought it was going to be applied by Tom directly. We're moving to a model where I apply efi patches, the custodian tree just isn't set up yet, so I pushed it to: https://github.com/agraf/u-boot/tree/efi-next instead, but wanted to notify people that there is indeed progress on their patches. Alex ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] ARM: zynq(mp): remove unneeded CONFIG_USB_MAX_CONTROLLER_COUNT defines
On 13.10.2016 17:40, Masahiro Yamada wrote: > ARCH_ZYNQ(MP) selects DM_USB, where CONFIG_USB_MAX_CONTROLLER_COUNT > is not used. > > Signed-off-by: Masahiro Yamada > --- > > include/configs/xilinx_zynqmp.h | 1 - > include/configs/zynq-common.h | 1 - > 2 files changed, 2 deletions(-) > > diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h > index adc42cf..c8e1ffa 100644 > --- a/include/configs/xilinx_zynqmp.h > +++ b/include/configs/xilinx_zynqmp.h > @@ -110,7 +110,6 @@ > #define CONFIG_SYS_LOAD_ADDR 0x800 > > #if defined(CONFIG_ZYNQMP_USB) > -#define CONFIG_USB_MAX_CONTROLLER_COUNT 2 > #define CONFIG_SYS_USB_XHCI_MAX_ROOT_PORTS 2 > #define CONFIG_USB_XHCI_ZYNQMP > > diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h > index 0118fd2..7cca83f 100644 > --- a/include/configs/zynq-common.h > +++ b/include/configs/zynq-common.h > @@ -86,7 +86,6 @@ > > #ifdef CONFIG_USB_EHCI_ZYNQ > # define CONFIG_EHCI_IS_TDI > -# define CONFIG_USB_MAX_CONTROLLER_COUNT 2 > > # define CONFIG_SYS_DFU_DATA_BUF_SIZE0x60 > # define DFU_DEFAULT_POLL_TIMEOUT300 > Acked-by: Michal Simek Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [IGNORE PATCH 0/9] tbot demo patches, please ignore
do not apply this patches to mainline! I move the patches to my ToDo list, until a tbot patchwork user is created. This is for a simple test to create a tbot demo video, which will demonstrate: - Step 1: - clone mainline u-boot, compile, install it on a board, and start a simple uboot help cmd testcase on it. - Step 2: - get all patchwork patches from a ToDo list - check them with scripts/checkpatch.pl - apply the patches to u-boot source with "git am" - compile, install and call a simple u-boot testcase for the help command, which gets intentionally broken with this testpatches - Step 3: start an automated git bisect testcase - as the patches break u-boot, start an automated "git bisect" testcase to find out, which commit breaks ... If video is finished, I give feedback here ... Heiko Schocher (9): README: simple change 1 README: simple change 2 README: simple change 3 README: simple change 4 README: simple change 5 cmd, help: break the help command README: simple change 6 README: simple change 7 README: simple change 8 README | 9 + cmd/help.c | 2 +- 2 files changed, 10 insertions(+), 1 deletion(-) -- 2.5.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [IGNORE PATCH 1/9] README: simple change 1
do not apply this patch to mainline, simple test for a tbot demo, please ignore. Signed-off-by: Heiko Schocher do not apply this patch to mainline, simple test for a tbot demo. --- README | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README b/README index 68d6a49..50e53a1 100644 --- a/README +++ b/README @@ -5,6 +5,8 @@ # SPDX-License-Identifier: GPL-2.0+ # +Test + Summary: -- 2.5.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [IGNORE PATCH 2/9] README: simple change 2
do not apply this patch to mainline, simple test for a tbot demo, please ignore. Signed-off-by: Heiko Schocher --- README | 1 + 1 file changed, 1 insertion(+) diff --git a/README b/README index 50e53a1..5cb82f7 100644 --- a/README +++ b/README @@ -6,6 +6,7 @@ # Test +Test 2 Summary: -- 2.5.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [IGNORE PATCH 8/9] README: simple change 7
do not apply this patch to mainline, simple test for a tbot demo, please ignore. Signed-off-by: Heiko Schocher --- README | 1 + 1 file changed, 1 insertion(+) diff --git a/README b/README index 1f56fdc..adfdf1a 100644 --- a/README +++ b/README @@ -11,6 +11,7 @@ Test 3 Test 4 Test 5 Test 6 +Test 7 Summary: -- 2.5.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [IGNORE PATCH 3/9] README: simple change 3
do not apply this patch to mainline, simple test for a tbot demo, please ignore. Signed-off-by: Heiko Schocher --- README | 1 + 1 file changed, 1 insertion(+) diff --git a/README b/README index 5cb82f7..812febb 100644 --- a/README +++ b/README @@ -7,6 +7,7 @@ Test Test 2 +Test 3 Summary: -- 2.5.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [IGNORE PATCH 4/9] README: simple change 4
do not apply this patch to mainline, simple test for a tbot demo, please ignore. Signed-off-by: Heiko Schocher --- README | 1 + 1 file changed, 1 insertion(+) diff --git a/README b/README index 812febb..cf98e7c 100644 --- a/README +++ b/README @@ -8,6 +8,7 @@ Test Test 2 Test 3 +Test 4 Summary: -- 2.5.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [IGNORE PATCH 7/9] README: simple change 6
do not apply this patch to mainline, simple test for a tbot demo, please ignore. Signed-off-by: Heiko Schocher --- README | 1 + 1 file changed, 1 insertion(+) diff --git a/README b/README index 2305a77..1f56fdc 100644 --- a/README +++ b/README @@ -10,6 +10,7 @@ Test 2 Test 3 Test 4 Test 5 +Test 6 Summary: -- 2.5.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [IGNORE PATCH 9/9] README: simple change 8
do not apply this patch to mainline, simple test for a tbot demo, please ignore. Signed-off-by: Heiko Schocher --- README | 1 + 1 file changed, 1 insertion(+) diff --git a/README b/README index adfdf1a..921d79d 100644 --- a/README +++ b/README @@ -12,6 +12,7 @@ Test 4 Test 5 Test 6 Test 7 +Test 8 Summary: -- 2.5.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [IGNORE PATCH 5/9] README: simple change 5
do not apply this patch to mainline, simple test for a tbot demo, please ignore. Signed-off-by: Heiko Schocher --- README | 1 + 1 file changed, 1 insertion(+) diff --git a/README b/README index cf98e7c..2305a77 100644 --- a/README +++ b/README @@ -9,6 +9,7 @@ Test Test 2 Test 3 Test 4 +Test 5 Summary: -- 2.5.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [IGNORE PATCH 6/9] cmd, help: break the help command
do not apply this patch to mainline, simple test for a tbot demo, please ignore. Signed-off-by: Heiko Schocher --- cmd/help.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cmd/help.c b/cmd/help.c index 701ae7e..d58bbdd 100644 --- a/cmd/help.c +++ b/cmd/help.c @@ -30,7 +30,7 @@ U_BOOT_CMD( /* This does not use the U_BOOT_CMD macro as ? can't be used in symbol names */ ll_entry_declare(cmd_tbl_t, question_mark, cmd) = { - "?",CONFIG_SYS_MAXARGS, 1, do_help, + "??", CONFIG_SYS_MAXARGS, 1, do_help, "alias for 'help'", #ifdef CONFIG_SYS_LONGHELP "" -- 2.5.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] ARM: zynq(mp): remove unneeded CONFIG_USB_MAX_CONTROLLER_COUNT defines
On Fri, Oct 14, 2016 at 9:29 AM, Michal Simek wrote: > On 13.10.2016 17:40, Masahiro Yamada wrote: >> ARCH_ZYNQ(MP) selects DM_USB, where CONFIG_USB_MAX_CONTROLLER_COUNT >> is not used. >> >> Signed-off-by: Masahiro Yamada >> --- >> >> include/configs/xilinx_zynqmp.h | 1 - >> include/configs/zynq-common.h | 1 - >> 2 files changed, 2 deletions(-) >> >> diff --git a/include/configs/xilinx_zynqmp.h >> b/include/configs/xilinx_zynqmp.h >> index adc42cf..c8e1ffa 100644 >> --- a/include/configs/xilinx_zynqmp.h >> +++ b/include/configs/xilinx_zynqmp.h >> @@ -110,7 +110,6 @@ >> #define CONFIG_SYS_LOAD_ADDR 0x800 >> >> #if defined(CONFIG_ZYNQMP_USB) >> -#define CONFIG_USB_MAX_CONTROLLER_COUNT 2 >> #define CONFIG_SYS_USB_XHCI_MAX_ROOT_PORTS 2 >> #define CONFIG_USB_XHCI_ZYNQMP >> >> diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h >> index 0118fd2..7cca83f 100644 >> --- a/include/configs/zynq-common.h >> +++ b/include/configs/zynq-common.h >> @@ -86,7 +86,6 @@ >> >> #ifdef CONFIG_USB_EHCI_ZYNQ >> # define CONFIG_EHCI_IS_TDI >> -# define CONFIG_USB_MAX_CONTROLLER_COUNT 2 >> >> # define CONFIG_SYS_DFU_DATA_BUF_SIZE0x60 >> # define DFU_DEFAULT_POLL_TIMEOUT300 >> > > Acked-by: Michal Simek Acked-by: Moritz Fischer Cheers, Moritz ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NFS and timeouts?
Hi, Le 14/10/2016 à 01:00, Joe Hershberger a écrit : On Fri, Oct 14, 2016 at 12:52 AM, Simon Glass wrote: Hi Tom, On 13 October 2016 at 13:11, Tom Rini wrote: Hey all, I've noticed now, but not dug into a problem that goes like this. On every platform that I have tried NFS on now (and I wasn't a user before the test came in) I see: # nfs 8000 /tftpboot/1MiBtest.bin link up on port 0, speed 1000, full duplex # # # ##T T T T done Bytes transferred = 1048576 (10 hex) for the same 1MiB file. The link line will vary from board to board but the end result is that I always see 4 T (for timeout) at the end of the transfer. On boards where I am doing this on gigabit the initial transfer is fast enough that the timeout doesn't cause failure. On the boards where I'm at 100Mbit instead however, I fail. I have seen this also - what type of interface are you using? Does this happen in your testing, Guillaume? No, I never saw those timeouts. I will try to reproduce here. On which boards does it happen? Guillaume ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] 0/4] Add Pl330 DMA support
On 10/10/2016 05:52 PM, Dinh Nguyen wrote: > Hi, Hi, > This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform makes > use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit. Is there some considerable performance benefit over memset() in this case ? > This is only an RFC because after rebasing to v2016.11-rc1, I had to revert > the following patch "a78cd8613204 ARM: Rework and correct barrier definitions" > in order for this patch set to work correctly. With the above patch applied, > after the SDRAM scrubbing is complete, the SPL is failing to find the MMC > device. > > I'm continue to debug this, but would like to solicit comments with this > patchset. > > Thanks, > Dinh > > > Dinh Nguyen (4): > drivers: dma: Add the ARM PL330 DMA driver > dma: Kconfig: Add CONFIG_PL330_DMA entry > dm: add DMA_SUPPORTS_DEV_TO_MEM type to DMA_UCLASS > arm: socfpga: scrub the SDRAM to properly enable ECC support > > arch/arm/include/asm/pl330.h | 105 +++ > arch/arm/mach-socfpga/include/mach/reset_manager.h | 21 + > arch/arm/mach-socfpga/include/mach/sdram.h | 2 + > arch/arm/mach-socfpga/spl.c| 8 + > arch/arm/mach-socfpga/wrap_sdram_config.c | 28 + > configs/socfpga_cyclone5_defconfig | 2 + > drivers/dma/Kconfig| 4 + > drivers/dma/Makefile | 1 + > drivers/dma/dma-uclass.c | 3 +- > drivers/dma/pl330.c| 942 > + > 10 files changed, 1115 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/include/asm/pl330.h > create mode 100644 drivers/dma/pl330.c > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] ext4: Fix handling of direntlen in unlink_filename
Hi Stefan, > The direntlen checks were quite bogus, i.e. the loop termination used > "len + offset == blocksize" (exact match only), and checked for a > direntlen less than 0. The latter can never happen as the len is > unsigned, this has been reported by Coverity, CID 153384. > > Use the same code as in search_dir for directory traversal. This code > has the correct checks for direntlen >= sizeof(struct dirent), and > offset < blocksize. > > Signed-off-by: Stefan Brüns > --- > fs/ext4/ext4_common.c | 45 > + 1 file changed, 17 > insertions(+), 28 deletions(-) > > diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c > index 699a640..11be0b7 100644 > --- a/fs/ext4/ext4_common.c > +++ b/fs/ext4/ext4_common.c > @@ -854,16 +854,15 @@ fail: > > static int unlink_filename(char *filename, unsigned int blknr) > { > - int templength = 0; > - int status, inodeno; > - int found = 0; > + int status; > + int inodeno = 0; > int offset; > char *block_buffer = NULL; > struct ext2_dirent *dir = NULL; > - struct ext2_dirent *previous_dir = NULL; > - char *ptr = NULL; > + struct ext2_dirent *previous_dir; > struct ext_filesystem *fs = get_fs(); > int ret = -1; > + char *direntname; > > block_buffer = zalloc(fs->blksz); > if (!block_buffer) > @@ -877,20 +876,18 @@ static int unlink_filename(char *filename, > unsigned int blknr) > if (ext4fs_log_journal(block_buffer, blknr)) > goto fail; > - dir = (struct ext2_dirent *)block_buffer; > - ptr = (char *)dir; > offset = 0; > - while (le16_to_cpu(dir->direntlen) >= 0) { > - /* > - * blocksize-offset because last > - * directory length i.e., *dir->direntlen > - * is free availble space in the block that > - * means it is a last entry of directory entry > - */ > + do { > + previous_dir = dir; > + dir = (struct ext2_dirent *)(block_buffer + offset); > + direntname = (char *)(dir) + sizeof(struct > ext2_dirent); + > + int direntlen = le16_to_cpu(dir->direntlen); > + if (direntlen < sizeof(struct ext2_dirent)) > + break; > + > if (dir->inode && (strlen(filename) == dir->namelen) > && > - (strncmp(ptr + sizeof(struct ext2_dirent), > - filename, dir->namelen) == 0)) { > - printf("file found, deleting\n"); > + (strncmp(direntname, filename, dir->namelen) == > 0)) { inodeno = le32_to_cpu(dir->inode); > if (previous_dir) { > uint16_t new_len; > @@ -900,23 +897,15 @@ static int unlink_filename(char *filename, > unsigned int blknr) } else { > dir->inode = 0; > } > - found = 1; > break; > } > > - if (fs->blksz - offset == > le16_to_cpu(dir->direntlen)) > - break; > + offset += direntlen; > > - /* traversing the each directory entry */ > - templength = le16_to_cpu(dir->direntlen); > - offset = offset + templength; > - previous_dir = dir; > - dir = (struct ext2_dirent *)((char *)dir + > templength); > - ptr = (char *)dir; > - } > + } while (offset < fs->blksz); > > + if (inodeno > 0) { > > - if (found == 1) { > if (ext4fs_put_metadata(block_buffer, blknr)) > goto fail; > ret = inodeno; Reviewed-by: Lukasz Majewski -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] ext4: Only write journal entries for modified blocks in unlink_filename
Hi Stefan, > Instead of creating a journal entry for each directory block, even > if the block is unmodified, only log the modified block. > > Signed-off-by: Stefan Brüns > --- > fs/ext4/ext4_common.c | 23 +-- > 1 file changed, 13 insertions(+), 10 deletions(-) > > diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c > index 11be0b7..ec02eec 100644 > --- a/fs/ext4/ext4_common.c > +++ b/fs/ext4/ext4_common.c > @@ -874,8 +874,6 @@ static int unlink_filename(char *filename, > unsigned int blknr) if (status == 0) > goto fail; > > - if (ext4fs_log_journal(block_buffer, blknr)) > - goto fail; > offset = 0; > do { > previous_dir = dir; > @@ -889,14 +887,6 @@ static int unlink_filename(char *filename, > unsigned int blknr) if (dir->inode && (strlen(filename) == > dir->namelen) && (strncmp(direntname, filename, dir->namelen) == 0)) { > inodeno = le32_to_cpu(dir->inode); > - if (previous_dir) { > - uint16_t new_len; > - new_len = > le16_to_cpu(previous_dir->direntlen); > - new_len += > le16_to_cpu(dir->direntlen); > - previous_dir->direntlen = > cpu_to_le16(new_len); > - } else { > - dir->inode = 0; > - } > break; > } > > @@ -905,7 +895,20 @@ static int unlink_filename(char *filename, > unsigned int blknr) } while (offset < fs->blksz); > > if (inodeno > 0) { > + printf("file found, deleting\n"); > + if (ext4fs_log_journal(block_buffer, blknr)) > + goto fail; > > + if (previous_dir) { > + /* merge dir entry with predecessor */ > + uint16_t new_len; > + new_len = > le16_to_cpu(previous_dir->direntlen); > + new_len += le16_to_cpu(dir->direntlen); > + previous_dir->direntlen = > cpu_to_le16(new_len); > + } else { > + /* invalidate dir entry */ > + dir->inode = 0; > + } > if (ext4fs_put_metadata(block_buffer, blknr)) > goto fail; > ret = inodeno; Reviewed-by: Lukasz Majewski -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] spi: ti_qspi: Fix baudrate divider calculation
Fix the divider calculation logic to choose a value so that the resulting baudrate is either equal to or closest possible baudrate less than the requested value. While at that, cleanup ti_spi_set_speed(). Signed-off-by: Vignesh R --- v2: cleanup ti_spi_set_speed() a bit. drivers/spi/ti_qspi.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c index 52520dff6325..b5de70bf40e3 100644 --- a/drivers/spi/ti_qspi.c +++ b/drivers/spi/ti_qspi.c @@ -16,6 +16,7 @@ #include #include #include +#include DECLARE_GLOBAL_DATA_PTR; @@ -118,21 +119,19 @@ static void ti_spi_set_speed(struct ti_qspi_priv *priv, uint hz) if (!hz) clk_div = 0; else - clk_div = (priv->fclk / hz) - 1; - - debug("ti_spi_set_speed: hz: %d, clock divider %d\n", hz, clk_div); + clk_div = DIV_ROUND_UP(priv->fclk, hz) - 1; /* disable SCLK */ writel(readl(&priv->base->clk_ctrl) & ~QSPI_CLK_EN, &priv->base->clk_ctrl); - /* assign clk_div values */ - if (clk_div < 0) - clk_div = 0; - else if (clk_div > QSPI_CLK_DIV_MAX) + /* truncate clk_div value to QSPI_CLK_DIV_MAX */ + if (clk_div > QSPI_CLK_DIV_MAX) clk_div = QSPI_CLK_DIV_MAX; - /* enable SCLK */ + debug("ti_spi_set_speed: hz: %d, clock divider %d\n", hz, clk_div); + + /* enable SCLK and program the clk divider */ writel(QSPI_CLK_EN | clk_div, &priv->base->clk_ctrl); } -- 2.10.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] spi: ti_qspi: Fix baudrate divider calculation
On 10/14/2016 12:27 PM, Jagan Teki wrote: > On Fri, Oct 14, 2016 at 10:54 AM, Vignesh R wrote: ... DECLARE_GLOBAL_DATA_PTR; @@ -118,7 +119,7 @@ static void ti_spi_set_speed(struct ti_qspi_priv *priv, uint hz) if (!hz) clk_div = 0; else - clk_div = (priv->fclk / hz) - 1; + clk_div = DIV_ROUND_UP(priv->fclk, hz) - 1; >>> >>> Better to have a checks for min and max divider values or mask. >> >> That code already exists in this function. > > True but it's unnecessary to print the wrong baud prior to checking. > Do the check, then print/debug and finally write reg. > Posted a v2 in reply to the patch. Thanks for the review! Regards Vignesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PicoZed] Error uenvboot script
Hi everyone, I'm trying to boot u-boot from uEnv.txt. And I've got a problem. I'm using zynq_picozed_defconfig The problem is I've got this error after the uEnv.txt is read: --- ... eth0: ethernet@e000b000 Hit any key to stop autoboot: 0 Device: sdhci@e010 Manufacturer ID: 3 OEM: 5344 Name: SL16G Tran Speed: 5000 Rd Block Len: 512 SD version 3.0 High Capacity: Yes Capacity: 14.8 GiB Bus Width: 4-bit Erase Group Size: 512 Bytes reading uEnv.txt 754 bytes read in 15 ms (48.8 KiB/s) Loaded environment from uEnv.txt Importing environment from SD ... test - minimal test like /bin/sh Usage: test [args..] --- It seems to be that fail to run the script: uenvboot=if run loadbootenv; then echo Loaded environment from ${bootenv}; run importbootenv; fi; if test -n $uenvcmd; then echo Running uenvcmd ...; run uenvcmd; fi When the test -n $uenvcmd is executed, but I don't understand why, because when I execute the script, run uenvcmd runs fine. Any suggestion? It seems to be when the console is ready the test function works fine, but before it fails. Best regards. Oscar Gomez Fuente. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] efi_loader: Rename EFI_RUNTIME_{TEXT, DATA} to __efi_runtime{, _data}
Compiler attributes are more commonly __foo style tags rather than big upper case eye sores like EFI_RUNTIME_TEXT. Simon Glass felt quite strongly about this, so this patch converts our existing defines over to more eye friendly ones. Signed-off-by: Alexander Graf --- arch/arm/cpu/armv8/fwcall.c | 12 ++-- include/efi_loader.h | 12 ++-- lib/efi_loader/efi_boottime.c | 6 +++--- lib/efi_loader/efi_runtime.c | 20 ++-- 4 files changed, 25 insertions(+), 25 deletions(-) diff --git a/arch/arm/cpu/armv8/fwcall.c b/arch/arm/cpu/armv8/fwcall.c index 64539f9..7dfd270 100644 --- a/arch/arm/cpu/armv8/fwcall.c +++ b/arch/arm/cpu/armv8/fwcall.c @@ -18,7 +18,7 @@ * x0~x7: input arguments * x0~x3: output arguments */ -static void EFI_RUNTIME_TEXT hvc_call(struct pt_regs *args) +static void __efi_runtime hvc_call(struct pt_regs *args) { asm volatile( "ldr x0, %0\n" @@ -52,7 +52,7 @@ static void EFI_RUNTIME_TEXT hvc_call(struct pt_regs *args) * x0~x3: output arguments */ -void EFI_RUNTIME_TEXT smc_call(struct pt_regs *args) +void __efi_runtime smc_call(struct pt_regs *args) { asm volatile( "ldr x0, %0\n" @@ -82,9 +82,9 @@ void EFI_RUNTIME_TEXT smc_call(struct pt_regs *args) * use PSCI on U-Boot running below a hypervisor, please detect * this and set the flag accordingly. */ -static const EFI_RUNTIME_DATA bool use_smc_for_psci = true; +static const __efi_runtime_data bool use_smc_for_psci = true; -void __noreturn EFI_RUNTIME_TEXT psci_system_reset(void) +void __noreturn __efi_runtime psci_system_reset(void) { struct pt_regs regs; @@ -99,7 +99,7 @@ void __noreturn EFI_RUNTIME_TEXT psci_system_reset(void) ; } -void __noreturn EFI_RUNTIME_TEXT psci_system_off(void) +void __noreturn __efi_runtime psci_system_off(void) { struct pt_regs regs; @@ -121,7 +121,7 @@ void reset_misc(void) } #ifdef CONFIG_EFI_LOADER -void EFI_RUNTIME_TEXT EFIAPI efi_reset_system( +void __efi_runtime EFIAPI efi_reset_system( enum efi_reset_type reset_type, efi_status_t reset_status, unsigned long data_size, void *reset_data) diff --git a/include/efi_loader.h b/include/efi_loader.h index 871499f..35b3fe2 100644 --- a/include/efi_loader.h +++ b/include/efi_loader.h @@ -156,8 +156,8 @@ static inline void ascii2unicode(u16 *unicode, const char *ascii) * Use these to indicate that your code / data should go into the EFI runtime * section and thus still be available when the OS is running */ -#define EFI_RUNTIME_DATA __attribute__ ((section ("efi_runtime_data"))) -#define EFI_RUNTIME_TEXT __attribute__ ((section ("efi_runtime_text"))) +#define __efi_runtime_data __attribute__ ((section ("efi_runtime_data"))) +#define __efi_runtime __attribute__ ((section ("efi_runtime_text"))) /* Call this with mmio_ptr as the _pointer_ to a pointer to an MMIO region * to make it available at runtime */ @@ -165,13 +165,13 @@ void efi_add_runtime_mmio(void *mmio_ptr, u64 len); /* Boards may provide the functions below to implement RTS functionality */ -void EFI_RUNTIME_TEXT EFIAPI efi_reset_system( +void __efi_runtime EFIAPI efi_reset_system( enum efi_reset_type reset_type, efi_status_t reset_status, unsigned long data_size, void *reset_data); void efi_reset_system_init(void); -efi_status_t EFI_RUNTIME_TEXT EFIAPI efi_get_time( +efi_status_t __efi_runtime EFIAPI efi_get_time( struct efi_time *time, struct efi_time_cap *capabilities); void efi_get_time_init(void); @@ -179,8 +179,8 @@ void efi_get_time_init(void); #else /* defined(EFI_LOADER) && !defined(CONFIG_SPL_BUILD) */ /* Without CONFIG_EFI_LOADER we don't have a runtime section, stub it out */ -#define EFI_RUNTIME_DATA -#define EFI_RUNTIME_TEXT +#define __efi_runtime_data +#define __efi_runtime static inline void efi_add_runtime_mmio(void **mmio_ptr, u64 len) { } /* No loader configured, stub out EFI_ENTRY */ diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c index 476ef1b..1fdddf4 100644 --- a/lib/efi_loader/efi_boottime.c +++ b/lib/efi_loader/efi_boottime.c @@ -37,7 +37,7 @@ static bool efi_is_direct_boot = true; * In most cases we want to pass an FDT to the payload, so reserve one slot of * config table space for it. The pointer gets populated by do_bootefi_exec(). */ -static struct efi_configuration_table EFI_RUNTIME_DATA efi_conf_table[2]; +static struct efi_configuration_table __efi_runtime_data efi_conf_table[2]; #ifdef CONFIG_ARM /* @@ -790,10 +790,10 @@ static const struct efi_boot_services efi_boot_services = { }; -static uint16_t EFI_RUNTIME_DATA firmware_vendor[] = +static uint16_t __efi_runtime_data firmware_vendor[] = { 'D','a','s',' ','U','-','b','o','o','t',0 }; -struct efi_s
Re: [U-Boot] [PATCH v2 1/3] driver: net: cpsw: add support for RGMII id mode support and RMII clock source selection
Joe, On 02/09/16 17:53, Tom Rini wrote: > On Wed, Aug 24, 2016 at 03:35:49PM +0300, Roger Quadros wrote: > >> From: Mugunthan V N >> >> cpsw driver supports only selection of phy mode in control module >> but control module has more setting like RGMII ID mode selection, >> RMII clock source selection. So ported to cpsw-phy-sel driver >> from kernel to u-boot. >> >> [Lokesh Vutla] >> - Update for am43xx variants. >> - Use DT data to configure external chip clock for RMII mode. >> >> Signed-off-by: Mugunthan V N >> Signed-off-by: Lokesh Vutla >> Signed-off-by: Roger Quadros > > Reviewed-by: Tom Rini > Seems like you have missed this patch and picked the remaining two in this series. cheers, -roger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] 0/4] Add Pl330 DMA support
On 10/14/2016 02:23 AM, Marek Vasut wrote: > On 10/10/2016 05:52 PM, Dinh Nguyen wrote: >> Hi, > > Hi, > >> This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform makes >> use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit. > > Is there some considerable performance benefit over memset() in this case ? > Yes, with the DMA, it takes ~1.5 secs, with memset, it's ~15 secs. Dinh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] power: twl6030: fix code refactoring
Le jeudi 13 octobre 2016 à 13:47 +0300, Nicolae Rosia a écrit : > From: Nicolae Rosia > > Commit a85362fb3e1fc7833723accddbbae431091d06b8 refactored the code > but the register read ended up in the wrong if branch. > Currently, the else branch checks a variable which is always 0. Good catch! Sorry for including that regression in the first place, I should have checked the patch more thoroughly. See comment below. > Signed-off-by: Nicolae Rosia > --- > drivers/power/twl6030.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/power/twl6030.c b/drivers/power/twl6030.c > index 05c79be..cd53200 100644 > --- a/drivers/power/twl6030.c > +++ b/drivers/power/twl6030.c > @@ -231,9 +231,9 @@ void twl6030_power_mmc_init(int dev_index) > /* Enable P1 output for VMMC */ > twl6030_i2c_write_u8(TWL6030_CHIP_PM, TWL6030_VMMC_CFG_STATE, > TWL6030_CFG_STATE_P1 | TWL6030_CFG_STATE_ON); > - > - twl6030_i2c_read_u8(TWL6030_CHIP_PM, TWL6030_PH_STS_BOOT, > &value); > } else if (dev_index == 1) { > + twl6030_i2c_read_u8(TWL6030_CHIP_PM, TWL6030_PH_STS_BOOT, > + &value); The indentation before &value is inconsistent with what is done in the rest of the file. I think you should either just move the line as it was or only use one extra tab indent for the new line. Since this file breaks the 80 chars limit in a few places, I would tend to prefer the former. > /* BOOT2 indicates 1.8V/2.8V VAUX1 for eMMC */ > if (value & TWL6030_PH_STS_BOOT2) { > /* 1.8V voltage output for VAUX1 */ -- Paul Kocialkowski, developer of low-level free software for embedded devices Website: https://www.paulk.fr/ Coding blog: https://code.paulk.fr/ Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/ signature.asc Description: This is a digitally signed message part ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NFS and timeouts?
On Fri, Oct 14, 2016 at 11:13:11AM +0200, Guillaume Gardet wrote: > Hi, > > > Le 14/10/2016 à 01:00, Joe Hershberger a écrit : > >On Fri, Oct 14, 2016 at 12:52 AM, Simon Glass wrote: > >>Hi Tom, > >> > >>On 13 October 2016 at 13:11, Tom Rini wrote: > >>>Hey all, > >>> > >>>I've noticed now, but not dug into a problem that goes like this. On > >>>every platform that I have tried NFS on now (and I wasn't a user before > >>>the test came in) I see: > >>># nfs 8000 /tftpboot/1MiBtest.bin > >>>link up on port 0, speed 1000, full duplex > >>># > >>> # > >>> # > >>> ##T T T T > >>>done > >>>Bytes transferred = 1048576 (10 hex) > >>> > >>>for the same 1MiB file. The link line will vary from board to board but > >>>the end result is that I always see 4 T (for timeout) at the end of the > >>>transfer. On boards where I am doing this on gigabit the initial > >>>transfer is fast enough that the timeout doesn't cause failure. On the > >>>boards where I'm at 100Mbit instead however, I fail. > >>I have seen this also - what type of interface are you using? > >Does this happen in your testing, Guillaume? > > > > No, I never saw those timeouts. I will try to reproduce here. > On which boards does it happen? AM335x GP EVM, DRA72x EVM ("J6 Eco"), Beagleboard xM, RPi 3 (32 or 64bit mode). I suspect it's something either config or network related. Everything is on the same 24 port gigabit switch. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] ARM: AMx3xx: Centralize early clock initialization
On Fri, Oct 14, 2016 at 10:35:24AM +0530, Lokesh Vutla wrote: > This is similar to Commit 93e6253d11030 ("ARM: OMAP4/5: Centralize > early clock initialization") that was done for OMAP4+, reflecting the same > for AM33xx and AM43xx SoCs to centralize clock initialization. > > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] board: ti: amx3xx: Remove multiple EEPROM reads
On Fri, Oct 14, 2016 at 10:35:25AM +0530, Lokesh Vutla wrote: > Detect the board very early and avoid reading eeprom multiple times. > > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] ARM: AMx3xx: Allow arch specific code to use early DM
On Fri, Oct 14, 2016 at 10:35:23AM +0530, Lokesh Vutla wrote: > Early system initialization is being done before initf_dm is being called > in U-Boot. Then system will fail to boot if any of the DM enabled driver > is being called in this system initialization code. So, rearrange the > code a bit so that DM enabled drivers can be called during early system > initialization. This is inspired by commit e850ed82bce8 ("ARM: OMAP4+: Allow > arch specific code to use early DM") > > Signed-off-by: Lokesh Vutla Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] 0/4] Add Pl330 DMA support
On 10/14/2016 03:08 PM, Dinh Nguyen wrote: > > > On 10/14/2016 02:23 AM, Marek Vasut wrote: >> On 10/10/2016 05:52 PM, Dinh Nguyen wrote: >>> Hi, >> >> Hi, >> >>> This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform >>> makes >>> use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit. >> >> Is there some considerable performance benefit over memset() in this case ? >> > > Yes, with the DMA, it takes ~1.5 secs, with memset, it's ~15 secs. Understood, thanks. I hope the scrubbing can be disabled in non-ECC case ? > Dinh > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 2/4] dma: Kconfig: Add CONFIG_PL330_DMA entry
On 10/10/2016 05:52 PM, Dinh Nguyen wrote: > From: Dinh Nguyen > > Add PL330_DMA entry. > > Signed-off-by: Dinh Nguyen This should be wrapped into 1/4 > --- > drivers/dma/Kconfig | 4 > drivers/dma/Makefile | 1 + > 2 files changed, 5 insertions(+) > > diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig > index 1b92c77..d95f959 100644 > --- a/drivers/dma/Kconfig > +++ b/drivers/dma/Kconfig > @@ -19,4 +19,8 @@ config TI_EDMA3 > This driver support data transfer between memory > regions. > > +config PL330_DMA > + bool "PL330 DMA driver" > + help > + Enable the ARM PL330 DMA driver. > endmenu # menu "DMA Support" > diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile > index 39b78b2..d287512 100644 > --- a/drivers/dma/Makefile > +++ b/drivers/dma/Makefile > @@ -13,3 +13,4 @@ obj-$(CONFIG_FSL_DMA) += fsl_dma.o > obj-$(CONFIG_TI_KSNAV) += keystone_nav.o keystone_nav_cfg.o > obj-$(CONFIG_TI_EDMA3) += ti-edma3.o > obj-$(CONFIG_DMA_LPC32XX) += lpc32xx_dma.o > +obj-$(CONFIG_PL330_DMA) += pl330.o > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 3/4] dm: add DMA_SUPPORTS_DEV_TO_MEM type to DMA_UCLASS
On 10/10/2016 05:52 PM, Dinh Nguyen wrote: > From: Dinh Nguyen > > Add DMA_SUPPORTS_DEV_TO_MEM type to the DMA uclass. > > Signed-off-by: Dinh Nguyen > --- > drivers/dma/dma-uclass.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/dma/dma-uclass.c b/drivers/dma/dma-uclass.c > index ea21fd9..a021395 100644 > --- a/drivers/dma/dma-uclass.c > +++ b/drivers/dma/dma-uclass.c > @@ -49,7 +49,8 @@ int dma_memcpy(void *dst, void *src, size_t len) > const struct dma_ops *ops; > int ret; > > - ret = dma_get_device(DMA_SUPPORTS_MEM_TO_MEM, &dev); > + ret = dma_get_device(DMA_SUPPORTS_MEM_TO_MEM | > + DMA_SUPPORTS_DEV_TO_MEM, &dev); > if (ret < 0) > return ret; > > The memcpy() is not used for doing dev-to-mem transfers, it's only used for mem-to-mem transfers, so this patch is wrong. I believe the driver needs to be corrected if it supports mem2mem transfers but doesn't advertise them. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board/ls2080qds: add the procedure to deply QSPI image.
On 10/13/2016 11:45 PM, Yao Yuan wrote: > On 10/12/2016 08:00 PM, York Sun wrote: >> On 10/11/2016 08:00 PM, Yao Yuan wrote: Yuan Yao, I think the procedure can be applied to many of our boards with QSPI, right? It may be better to move this information out of ls2080aqds. >>> >>> Hi York, >>> >>> Yes, but a little difference for "CCSR write" for different boards. >>> But the "CCSR write" should be wrote into uboot code or cw. >>> So, should I remove the notes for "CCSR write" and then move this >>> information for all the boards which support QSPI boot? >>> >> >> I think you can put the common practice together with specific examples for >> LS2080A, and other SoCs. >> > > Hi York, > > If move this information out of ls2080aqds. > Do you think where can I put the procedure for all the boards? > In every board's README or somewhere for the common procedure? > Yao, Take a look at these locations and decide which one fits best. arch/arm/cpu/armv8/fsl-layerscape/doc/README.* doc/README.fsl-qspi (you can create this) York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 2/2] armv8: Fix flush_dcache_all function
Previously it was believed L3 cache has to be flushed in order to guarantee data integrity in main memory. However, flushing L3 cache may require EL3, depending on SoC implementation. Flushing with virtual address can also put data into main memory. The trick is to find the correct address range. For U-Boot to function correctly, the stack needs to be flushed, up to the top of ram used by U-Boot. Signed-off-by: York Sun Thierry Reding , Radha Mohan Chintakuntla , Alison Wang , Albert Aribaud , Sergey Temerkhanov , Stephen Warren --- Stephen Warren, your recently added flushing L3 cache for tegra (8e5d804). Can you check if your board still works with this proposed change? arch/arm/cpu/armv8/cache_v8.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c index 92d6277..f5494f8 100644 --- a/arch/arm/cpu/armv8/cache_v8.c +++ b/arch/arm/cpu/armv8/cache_v8.c @@ -430,14 +430,13 @@ void invalidate_dcache_all(void) */ inline void flush_dcache_all(void) { - int ret; + ulong sp; + asm("mov %0, sp" : "=r"(sp) : ); + /* Flush stack to the top of ram */ + __asm_flush_dcache_range(sp, gd->ram_top); + /* Flush cache by way/set */ __asm_flush_dcache_all(); - ret = __asm_flush_l3_cache(); - if (ret) - debug("flushing dcache returns 0x%x\n", ret); - else - debug("flushing dcache successfully.\n"); } /* -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 0/2] Fix armv8 cache flushing
I have been puzzled by the need to flush external L3 cache for Freescale Layerscape series SoCs. Flushing L3 requires EL3. It is the case now, but this may change in the future. Implementing a SMC call to perform this task is possible but only if necessary. Recent investigation shows we can flush by virtual address most of the time. The only exception is when dcache_disable() is called. I think this can be addressed by flushing the stack U-Boot is using and skip flushing L3 totally. Once this is proved to work, we can drop flushing L3 all together. During this investigation, I found the procedure of turning off d-cache seems wrong. The data is lost if d-cache is off first. I am not sure if this only happens to Freescale Layerscape SoCs. Wondering why no one else reports any issue, expecially those SoCs without L3 cache. York Sun (2): armv8: Fix dcache disable function armv8: Fix flush_dcache_all function arch/arm/cpu/armv8/cache_v8.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 1/2] armv8: Fix dcache disable function
Current code turns off d-cache first, then flush all levels of cache. This results data loss. As soon as d-cache is off, the dirty cache is discarded according to the test on LS2080A. This issue was not seen as long as external L3 cache was flushed to push the data to main memory. However, external L3 cache is not guaranteed to have the data. To fix this, flush the d-cache by way/set first to make sure cache is clean before turning it off. Signed-off-by: York Sun CC: David Feng --- arch/arm/cpu/armv8/cache_v8.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c index cd3f6c1..92d6277 100644 --- a/arch/arm/cpu/armv8/cache_v8.c +++ b/arch/arm/cpu/armv8/cache_v8.c @@ -478,9 +478,9 @@ void dcache_disable(void) if (!(sctlr & CR_C)) return; + flush_dcache_all(); set_sctlr(sctlr & ~(CR_C|CR_M)); - flush_dcache_all(); __asm_invalidate_tlb_all(); } -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Resend RFC PATCH 2/2] armv8: Fix flush_dcache_all function
Previously it was believed L3 cache has to be flushed in order to guarantee data integrity in main memory. However, flushing L3 cache may require EL3, depending on SoC implementation. Flushing with virtual address can also put data into main memory. The trick is to find the correct address range. For U-Boot to function correctly, the stack needs to be flushed, up to the top of ram used by U-Boot. Signed-off-by: York Sun --- Stephen Warren, your recently added flushing L3 cache for tegra (8e5d804). Can you check if your board still works with this proposed change? arch/arm/cpu/armv8/cache_v8.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c index 92d6277..f5494f8 100644 --- a/arch/arm/cpu/armv8/cache_v8.c +++ b/arch/arm/cpu/armv8/cache_v8.c @@ -430,14 +430,13 @@ void invalidate_dcache_all(void) */ inline void flush_dcache_all(void) { - int ret; + ulong sp; + asm("mov %0, sp" : "=r"(sp) : ); + /* Flush stack to the top of ram */ + __asm_flush_dcache_range(sp, gd->ram_top); + /* Flush cache by way/set */ __asm_flush_dcache_all(); - ret = __asm_flush_l3_cache(); - if (ret) - debug("flushing dcache returns 0x%x\n", ret); - else - debug("flushing dcache successfully.\n"); } /* -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Resend RFC PATCH 1/2] armv8: Fix dcache disable function
Current code turns off d-cache first, then flush all levels of cache. This results data loss. As soon as d-cache is off, the dirty cache is discarded according to the test on LS2080A. This issue was not seen as long as external L3 cache was flushed to push the data to main memory. However, external L3 cache is not guaranteed to have the data. To fix this, flush the d-cache by way/set first to make sure cache is clean before turning it off. Signed-off-by: York Sun CC: David Feng --- arch/arm/cpu/armv8/cache_v8.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c index cd3f6c1..92d6277 100644 --- a/arch/arm/cpu/armv8/cache_v8.c +++ b/arch/arm/cpu/armv8/cache_v8.c @@ -478,9 +478,9 @@ void dcache_disable(void) if (!(sctlr & CR_C)) return; + flush_dcache_all(); set_sctlr(sctlr & ~(CR_C|CR_M)); - flush_dcache_all(); __asm_invalidate_tlb_all(); } -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Resend RFC PATCH 0/2] Fix armv8 cache flushing
I have been puzzled by the need to flush external L3 cache for Freescale Layerscape series SoCs. Flushing L3 requires EL3. It is the case now, but this may change in the future. Implementing a SMC call to perform this task is possible but only if necessary. Recent investigation shows we can flush by virtual address most of the time. The only exception is when dcache_disable() is called. I think this can be addressed by flushing the stack U-Boot is using and skip flushing L3 totally. Once this is proved to work, we can drop flushing L3 all together. During this investigation, I found the procedure of turning off d-cache seems wrong. The data is lost if d-cache is off first. I am not sure if this only happens to Freescale Layerscape SoCs. Wondering why no one else reports any issue, expecially those SoCs without L3 cache. York Sun (2): armv8: Fix dcache disable function armv8: Fix flush_dcache_all function arch/arm/cpu/armv8/cache_v8.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 2/2] armv8: Fix flush_dcache_all function
On 10/14/2016 01:01 PM, York Sun wrote: > Previously it was believed L3 cache has to be flushed in order to guarantee > data integrity in main memory. However, flushing L3 cache may require EL3, > depending on SoC implementation. Flushing with virtual address can also > put data into main memory. The trick is to find the correct address range. > For U-Boot to function correctly, the stack needs to be flushed, up to the > top of ram used by U-Boot. > > Signed-off-by: York Sun > Pardon me for this mess up. I thought I put the following addresses in Series-cc. But evidentially I did it wrong. York > Thierry Reding , > Radha Mohan Chintakuntla , > Alison Wang , > Albert Aribaud , > Sergey Temerkhanov , > Stephen Warren ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Resend RFC PATCH 1/2] armv8: Fix dcache disable function
On 10/14/2016 02:17 PM, York Sun wrote: Current code turns off d-cache first, then flush all levels of cache. This results data loss. As soon as d-cache is off, the dirty cache is discarded according to the test on LS2080A. This issue was not seen as long as external L3 cache was flushed to push the data to main memory. However, external L3 cache is not guaranteed to have the data. To fix this, flush the d-cache by way/set first to make sure cache is clean before turning it off. diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c index cd3f6c1..92d6277 100644 --- a/arch/arm/cpu/armv8/cache_v8.c +++ b/arch/arm/cpu/armv8/cache_v8.c @@ -478,9 +478,9 @@ void dcache_disable(void) if (!(sctlr & CR_C)) return; + flush_dcache_all(); set_sctlr(sctlr & ~(CR_C|CR_M)); - flush_dcache_all(); __asm_invalidate_tlb_all(); } This one makes sense. I'll try and test it soon. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Resend RFC PATCH 2/2] armv8: Fix flush_dcache_all function
On 10/14/2016 02:17 PM, York Sun wrote: Previously it was believed L3 cache has to be flushed in order to guarantee data integrity in main memory. However, flushing L3 cache may require EL3, depending on SoC implementation. Flushing with virtual address can also put data into main memory. The trick is to find the correct address range. For U-Boot to function correctly, the stack needs to be flushed, up to the top of ram used by U-Boot. Signed-off-by: York Sun --- Stephen Warren, your recently added flushing L3 cache for tegra (8e5d804). Can you check if your board still works with this proposed change? I'm not convinced this is safe. If we do flush by VA rather than any other mechanism, we should at least iterate over the entire page table and find all regions marked cacheable, rather than assuming the delta between stack pointer and ram_top is the only relevant region. That said, I'm not sure even doing that will completely guarantee that the cache is fully clean; I think by-set/-way is the only way. I think it's better to leave this part as-is. BTW, in the very near future (I've been meaning to do this for the last couple of days), I expect to send a patch which adds hooks for SoC-/CPU-/system-specific hooks to all 3 of invalidate_dcache_all(), flush_dcache_all(), invalidate_icache_all(). That patch will rename __asm_flush_l3_cache() for consistency with the other hooks, and remove "l3" from the function name because the function isn't only necessary for L3 flushing, but can also be required by other aspects of multi-cluster systems. As such, the following definitely won't work for Tegra: - ret = __asm_flush_l3_cache(); ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Resend RFC PATCH 2/2] armv8: Fix flush_dcache_all function
On 10/14/2016 01:30 PM, Stephen Warren wrote: > On 10/14/2016 02:17 PM, York Sun wrote: >> Previously it was believed L3 cache has to be flushed in order to guarantee >> data integrity in main memory. However, flushing L3 cache may require EL3, >> depending on SoC implementation. Flushing with virtual address can also >> put data into main memory. The trick is to find the correct address range. >> For U-Boot to function correctly, the stack needs to be flushed, up to the >> top of ram used by U-Boot. >> >> Signed-off-by: York Sun >> >> --- >> Stephen Warren, your recently added flushing L3 cache for tegra (8e5d804). >> Can you check if your board still works with this proposed change? > > I'm not convinced this is safe. If we do flush by VA rather than any > other mechanism, we should at least iterate over the entire page table > and find all regions marked cacheable, rather than assuming the delta > between stack pointer and ram_top is the only relevant region. That > said, I'm not sure even doing that will completely guarantee that the > cache is fully clean; I think by-set/-way is the only way. I think it's > better to leave this part as-is. I agree this is not same as flush_all. I had internal discussion with our people. I acknowledge we have other memory potentially needs a flush. There are many possibility that a user put something in the memory and expect the data persists when OS comes up. My target is to eliminate flushing external cache. Consider how we boot Linux. The kernel image is flushed by VA, then d-cache off, MMU off. When kernel comes up, it enables d-cache. As far as the data is not accessed for that, we don't have to flush it in U-Boot. I understand this is only not the whole picture. Sending out this RFC patch meant to start this discussion. > > BTW, in the very near future (I've been meaning to do this for the last > couple of days), I expect to send a patch which adds hooks for > SoC-/CPU-/system-specific hooks to all 3 of invalidate_dcache_all(), > flush_dcache_all(), invalidate_icache_all(). That patch will rename > __asm_flush_l3_cache() for consistency with the other hooks, and remove > "l3" from the function name because the function isn't only necessary > for L3 flushing, but can also be required by other aspects of > multi-cluster systems. As such, the following definitely won't work for > Tegra: > >> -ret = __asm_flush_l3_cache(); > > Let's see what the patches will be. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-fdt (take 2)
On Thu, Oct 13, 2016 at 04:53:40PM -0600, Simon Glass wrote: > Hi Tom, > > Here is a second attempt with this patch pulled in: > > http://patchwork.ozlabs.org/patch/681814/ > > > The following changes since commit c69f6d04ec66433f2360490a5cd0263c83aab18f: > > Merge branch 'master' of http://git.denx.de/u-boot-mmc (2016-10-13 > 08:13:56 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-fdt.git > > for you to fetch changes up to 42b7600d62ae288a8c12431d232b89b26ec61721: > > libfdt: Drop inlining of fdt_path_offset() (2016-10-13 14:12:40 -0600) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tpm: tpm_tis_lpc: Add support for AT97SC3204
The Atmel AT97SC3204 is also TIS compliant. Modify the tpm_tis_lpc driver to check for the vid/did used by the Atmel AT97SC3204 and report an appropriate description. Signed-off-by: George McCollister --- drivers/tpm/tpm_tis_lpc.c | 37 - 1 file changed, 28 insertions(+), 9 deletions(-) diff --git a/drivers/tpm/tpm_tis_lpc.c b/drivers/tpm/tpm_tis_lpc.c index b4efbb5..316993a 100644 --- a/drivers/tpm/tpm_tis_lpc.c +++ b/drivers/tpm/tpm_tis_lpc.c @@ -21,6 +21,21 @@ #define PREFIX "lpc_tpm: " +enum i2c_chip_type { + SLB9635, + AT97SC3204, +}; + +static const char * const chip_name[] = { + [SLB9635] = "Infineon SLB9635 TT 1.2", + [AT97SC3204] = "Atmel AT97SC3204", +}; + +static const u32 chip_didvid[] = { + [SLB9635] = 0xb15d1, + [AT97SC3204] = 0x32041114, +}; + struct tpm_locality { u32 access; u8 padding0[4]; @@ -146,9 +161,9 @@ static int tis_wait_reg(struct tpm_tis_lpc_priv *priv, u32 *reg, u8 mask, static int tpm_tis_lpc_probe(struct udevice *dev) { struct tpm_tis_lpc_priv *priv = dev_get_priv(dev); - u32 vid, did; fdt_addr_t addr; u32 didvid; + ulong chip_type = dev_get_driver_data(dev); addr = dev_get_addr(dev); if (addr == FDT_ADDR_T_NONE) @@ -156,15 +171,16 @@ static int tpm_tis_lpc_probe(struct udevice *dev) priv->regs = map_sysmem(addr, 0); didvid = tpm_read_word(priv, &priv->regs[0].did_vid); - vid = didvid & 0x; - did = (didvid >> 16) & 0x; - if (vid != 0x15d1 || did != 0xb) { + if (didvid == chip_didvid[chip_type]) { + debug("Found TPM: %s\n", chip_name[chip_type]); + } else { + u32 vid, did; + vid = didvid & 0x; + did = (didvid >> 16) & 0x; debug("Invalid vendor/device ID %04x/%04x\n", vid, did); return -ENOSYS; } - debug("Found TPM %s by %s\n", "SLB9635 TT 1.2", "Infineon"); - return 0; } @@ -421,11 +437,13 @@ static int tpm_tis_lpc_close(struct udevice *dev) static int tpm_tis_get_desc(struct udevice *dev, char *buf, int size) { + ulong chip_type = dev_get_driver_data(dev); + if (size < 50) return -ENOSPC; - return snprintf(buf, size, "1.2 TPM (vendor %s, chip %s)", - "Infineon", "SLB9635 TT 1.2"); + return snprintf(buf, size, "1.2 TPM (%s)", + chip_name[chip_type]); } @@ -438,7 +456,8 @@ static const struct tpm_ops tpm_tis_lpc_ops = { }; static const struct udevice_id tpm_tis_lpc_ids[] = { - { .compatible = "infineon,slb9635lpc" }, + { .compatible = "infineon,slb9635lpc", .data = SLB9635 }, + { .compatible = "atmel,at97sc3204", .data = AT97SC3204 }, { } }; -- 2.9.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] 0/4] Add Pl330 DMA support
On 10/10/2016 10:52 AM, Dinh Nguyen wrote: > Hi, > > This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform makes > use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit. > > This is only an RFC because after rebasing to v2016.11-rc1, I had to revert > the following patch "a78cd8613204 ARM: Rework and correct barrier definitions" > in order for this patch set to work correctly. With the above patch applied, > after the SDRAM scrubbing is complete, the SPL is failing to find the MMC > device. > I kinda figured out why patch "a78cd8613204 ARM: Rework and correct barrier definitions" is causing SPL to fail after the SDRAM scrub operation. It appears that before the above mentioned patch, the dmb() operation is defined as this: #define dmb() __asm__ __volatile__ ("" : : : "memory") after the patch, the dmb is now: #define DMBasm volatile ("dmb sy" : : : "memory") So the "dmb sy" as described in the ARM documentation is a "Full system DMB operation". For whatever reason, this change is causing the SPL error after the SDRAM scrub operation. Dinh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] 0/4] Add Pl330 DMA support
On 10/14/2016 10:09 AM, Marek Vasut wrote: > On 10/14/2016 03:08 PM, Dinh Nguyen wrote: >> >> >> On 10/14/2016 02:23 AM, Marek Vasut wrote: >>> On 10/10/2016 05:52 PM, Dinh Nguyen wrote: Hi, >>> >>> Hi, >>> This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform makes use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit. >>> >>> Is there some considerable performanCONFIG_HPS_SDR_CTRLCFG_CTRLCFG_ECCENce >>> benefit over memset() in this case ? >>> >> >> Yes, with the DMA, it takes ~1.5 secs, with memset, it's ~15 secs. > > Understood, thanks. I hope the scrubbing can be disabled in non-ECC case ? > Yes, the scrubbing is only done if CONFIG_HPS_SDR_CTRLCFG_CTRLCFG_ECCEN == 1. Dinh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] ARM: sunxi: remove unneeded CONFIG_USB_MAX_CONTROLLER_COUNT defines
On Thu, Oct 13, 2016 at 9:10 PM, Masahiro Yamada wrote: > ARCH_SUNXI selects DM_USB, where CONFIG_USB_MAX_CONTROLLER_COUNT > is not used. > > Signed-off-by: Masahiro Yamada > --- Reviewed-by: Jagan Teki thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Issue with USB mass storage (thumb drives)
Hi Uboot team, Is this problem of EHCI timed out on TD - token=0x80008d80 already resolved ? If yes can soneone please point me to the solution. I am seeing this read timeout failure with 2 n 4 GB Usb drives. Its a no go for our project, please help or advise. Thanks, Mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] spi: ti_qspi: Fix baudrate divider calculation
On Fri, Oct 14, 2016 at 10:54 AM, Vignesh R wrote: > Hi, > > On Thursday 13 October 2016 05:41 PM, Jagan Teki wrote: >> On Wed, Oct 12, 2016 at 9:46 AM, Vignesh R wrote: >>> Fix the divider calculation logic to choose a value so that the >>> resulting baudrate is either equal to or closest possible baudrate less >>> than the requested value. >>> >>> Signed-off-by: Vignesh R >>> --- >>> drivers/spi/ti_qspi.c | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c >>> index 52520dff6325..d97e2479d1b3 100644 >>> --- a/drivers/spi/ti_qspi.c >>> +++ b/drivers/spi/ti_qspi.c >>> @@ -16,6 +16,7 @@ >>> #include >>> #include >>> #include >>> +#include >>> >>> DECLARE_GLOBAL_DATA_PTR; >>> >>> @@ -118,7 +119,7 @@ static void ti_spi_set_speed(struct ti_qspi_priv *priv, >>> uint hz) >>> if (!hz) >>> clk_div = 0; >>> else >>> - clk_div = (priv->fclk / hz) - 1; >>> + clk_div = DIV_ROUND_UP(priv->fclk, hz) - 1; >> >> Better to have a checks for min and max divider values or mask. > > That code already exists in this function. True but it's unnecessary to print the wrong baud prior to checking. Do the check, then print/debug and finally write reg. thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: Add defconfig and dts file for Orange Pi One SBC
Hello hi, my name is jean-philippe theroux. i'm rather new to linux and tonight i had the crazy idea to try to recompile the kernel on a orange pi plus Soc. i am using a somewhat recent distribution and i believe it's not even been released with the actual config and all the fixes i made (to the img) i am quite computer educated started in 1983... just i never compiled a linux kernel being a microsoft idiot for nearly 25 years... i am rather far in the process, i installed the compiler stuff already and everything needed for the recompilation, downloaded kernel sources (loboris) but i'm stuck at some point im using this tutorial which i tried to follow https://github.com/umiddelb/armhf/wiki/How-To-compile-a-custom-Linux-kernel-for-your-ARM-device can i kindly ask for your help? thanks your for your time Jean-Philippe theroux ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] test/py/tests/test_sleep.py: Add check for CONFIG_CMD_MISC
We can only run this command if the sleep command is enabled and that depends on CONFIG_CMD_MISC Signed-off-by: Tom Rini --- test/py/tests/test_sleep.py | 2 ++ 1 file changed, 2 insertions(+) diff --git a/test/py/tests/test_sleep.py b/test/py/tests/test_sleep.py index 5c1a2623fefa..b59a4cfc0fc2 100644 --- a/test/py/tests/test_sleep.py +++ b/test/py/tests/test_sleep.py @@ -9,6 +9,8 @@ def test_sleep(u_boot_console): """Test the sleep command, and validate that it sleeps for approximately the correct amount of time.""" +if u_boot_console.config.buildconfig.get('config_cmd_misc', 'n') != 'y': +pytest.skip('sleep command not supported') # 3s isn't too long, but is enough to cross a few second boundaries. sleep_time = 3 tstart = time.time() -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] qemu-x86 issues
Hey guys, After making Stephen's scripts work with qemu today, I've started testing out what platforms I can test out via qemu. I've found two problems with qemu-x86. First, there's a real problem with the network. I run qemu with "-nographic -cpu qemu32 -netdev user,id=net0,tftp=/tftpboot -device e1000,netdev=net0" so that I can tftpboot things in and I'm getting crc32 mismatches. Second, the sleep command is not at all accurate. It's returning the 3 second test in less than 1 second. Any ideas, or places I should try poking to solve these issues? I'm going to kludge around this for now by disabling these tests locally. Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: mpc512x: Add support for get_svr() for mpc512x devices
>From: Bin Meng [mailto:bmeng...@gmail.com] >On Fri, Oct 14, 2016 at 1:49 PM, Sriram Dash wrote: >> Defines get_svr() for mpc512x devices >> >> Signed-off-by: Sriram Dash >> --- >> arch/powerpc/cpu/mpc512x/start.S | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/arch/powerpc/cpu/mpc512x/start.S >b/arch/powerpc/cpu/mpc512x/start.S >> index 471d401..2507842 100644 >> --- a/arch/powerpc/cpu/mpc512x/start.S >> +++ b/arch/powerpc/cpu/mpc512x/start.S >> @@ -443,6 +443,11 @@ get_pvr: >> mfspr r3, PVR >> blr >> >> + .globl get_svr >> +get_svr: >> + mfspr r3,SVR > >nits: need a space after , > Ok. Will take care in next version. >> + blr >> + > >Other than that, >Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, RFC] ARM: create .secure_stack section only for PSCI
On Mon, Sep 26, 2016 at 02:21:30PM +0900, Masahiro Yamada wrote: > Jon Master reports that QEMU refuses to load a U-Boot image built > with CONFIG_ARMV7_NONSEC, but without CONFIG_ARMV7_PSCI since > commit 5a3aae68c74e ("ARM: armv7: guard memory reserve for PSCI > with #ifdef CONFIG_ARMV7_PSCI"). > > It looks like only PSCI that needs the Secure stack, so move > the #ifdef to guard the whole of .secure_stack allocation in order > not to create the empty section. > > Signed-off-by: Masahiro Yamada > Reported-by: Jon Masters > Link: http://patchwork.ozlabs.org/patch/664025/ Applied to u-boot/master, thanks! ... and no, I don't know how / why this caused build failures before, but it did and I replicated it at the time too. But I just got a clean build everywhere. And I've added vexpress-a15 and vexpress-a9 via QEMU to my test setup now. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] test/py/tests/test_sleep.py: Add check for CONFIG_CMD_MISC
On Fri, Oct 14, 2016 at 07:13:01PM -0400, Tom Rini wrote: > We can only run this command if the sleep command is enabled and that > depends on CONFIG_CMD_MISC > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] watchdog: Fix Watchdog Reset while in U-Boot Prompt
On Mon, Sep 19, 2016 at 01:59:44PM +0200, Andreas Reichel wrote: > Hi Tom, > > is my patch going to be applied or is the problem resolved > otherwhise? Sorry, lost in my patchwork queue. I'll pick this up soon now. > > Kind regards > Andreas > > On Mo, Sep 05, 2016 at 07:04:53 -0600, Simon Glass wrote: > > +Tom, in case this should go into the release. > > > > On 1 August 2016 at 05:49, Andreas J. Reichel > > wrote: > > > This patch fixes unwanted watchdog resets while the user enters > > > a command at the U-Boot prompt. > > > > > > As found on the CM-FX6 board from Compulab, when having enabled the > > > watchdog, a missing WATCHDOG_RESET call in _serial_tstc() in > > > (/drivers/serial/serial-uclass.c) causes this and alike boards to > > > reset when the watchdog's timeout has elapsed while waiting at the > > > U-Boot prompt. > > > > > > Despite the user could press several keys within the watchdog > > > timeout limit, the while loop in cli_readline.c, line 261, does only > > > call WATCHDOG_RESET if first == 1, which gets set to 0 in the 1st > > > loop iteration. This leads to a watchdog timeout no matter if the > > > user presses keys or not. > > > > > > The problem is solved with a call to WATCHDOG_RESET in _serial_tstc, > > > defined in drivers/serial/serial-uclass.c. > > > > > > Since the macro WATCHDOG_RESET expands to {} if watchdog support > > > isn't configured, there's no need to surround it by #ifdef in this > > > case. > > > > > > * Symptom: > > >U-Boot resets after watchdog times out when in commandline prompt > > >and watchdog is enabled. > > > > > > * Reasoning: > > >When U-Boot shows the commandline prompt, the following function > > >call stack is executed while waiting for a keypress: > > > > > >common/main.c: > > > main_loop => common/cli.c: cli_loop() => > > >common/cli_hush.c: > > > parse_file_outer => parse_stream_outer => > > > parse_stream => b_getch(i) => > > > i->get(i) => file_get => > > > get_user_input => cmdedit_read_input => > > > uboot_cli_readline => > > >common/cli_readline.c: > > > cli_readline => cli_readline_into_buffer => > > > cread_line => getcmd_getch (== getc) => > > >commonn/console.c: > > > fgetc => console_tstc > > > > > >- in console_tstc line 181: > > >If dev->tstc(dev) returns 0, the global tstcdev variable doesn't > > >get set. This is the case if no character is in the serial buffer. > > > > > >- in fgetc(int file), line 297: > > >Program flow keeps looping because tstcdev does not get set. > > >Therefore WATCHDOG_RESET is not called, as mx_serial_tstc from > > >drivers/serial/serial_mxc.c does not call it. > > > > > >- Initialization calls drv_system_init in stdio.c, which sets > > >dev.tstc = stdio_serial_tstc. Thus, dev->tstc(dev) calls serial_tstc() > > >which in turn calls _serial_tstc(). > > > > > >Hence, _serial_tstc() needs to call WATCHDOG_RESET() to periodically > > >reset the watchdog while cli_readline waits for user input. > > > > > > Signed-off-by: Christian Storm > > > Signed-off-by: Jan Kiszka > > > Signed-off-by: Andreas J. Reichel > > > --- > > > > > > Changes in v2: > > > - Move WATCHDOG_RESET() call from common/console.c to > > >drivers/serial/serial-uclass.c. > > > > > > drivers/serial/serial-uclass.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/drivers/serial/serial-uclass.c > > > b/drivers/serial/serial-uclass.c > > > index 0ce5c44..72cf808 100644 > > > --- a/drivers/serial/serial-uclass.c > > > +++ b/drivers/serial/serial-uclass.c > > > @@ -155,6 +155,7 @@ static int _serial_tstc(struct udevice *dev) > > > { > > > struct dm_serial_ops *ops = serial_get_ops(dev); > > > > > > + WATCHDOG_RESET(); > > > if (ops->pending) > > > return ops->pending(dev, true); > > > > Great explanation, thank you. > > > > Acked-by: Simon Glass > > > > > > > > -- > > > 2.8.2 > > > > > -- > Andreas Reichel > Dipl.-Phys. (Univ.) > Software Consultant > > andreas.reic...@tngtech.com > +49-174-3180074 > > TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterföhring > Geschäftsführer: Henrik Klagges, Christoph Stock, Dr. Robert Dahlke > Sitz: Unterföhring * Amtsgericht München * HRB 135082 -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot