Re: [U-Boot] [PATCH v2] sf: bar: Clean BA24 Bank Address Register bit after read/write/erase operation
On Mon, Sep 25, 2017 at 4:10 PM, Lukasz Majewskiwrote: > The content of Bank Address Register (BAR) is volatile. It is cleared > after power cycle or reset command (RESET F0h). > > Some memories (like e.g. s25fl256s) use it to access memory larger than > 0x100 (16 MiB). > > The problem shows up when one: > > 1. Reads/writes/erases memory > 16 MiB > 2. Calls "reset" u-boot command (which is not causing BAR to be cleared) > > In the above scenario, the SoC ROM sends 0x00 address to read SPL. > Unfortunately, the BA24 bit is still set and hence it receives content > from 0x100 (16 MiB) memory address. > As a result the SoC aborts and we hang. Only power cycle can take the > SoC out of this state. > > How to reproduce/test: > > sf probe; sf erase 0x120 0x80; reset > sf probe; sf erase 0x120 0x80; sf write 0x1100 0x120 > 0x80; reset > sf probe; sf read 0x1100 0x120 0x80; reset Sorry, I didn't follow this test.. are you writing on at 18MiB offset and doing reset how it will reproduce? because we can write it 0x0 and after reset the ROM look for 16MiB on this flash this is what you concern about right? 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 https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] DDR training code for Armada 38x
Hi Chris, On 26.09.2017 00:29, Chris Packham wrote: For the internet historians, On Thu, Sep 21, 2017 at 4:25 PM, Chris Packhamwrote: On Wed, Sep 20, 2017 at 5:31 PM, Stefan Roese wrote: Hi Chris, On 19.09.2017 20:58, Chris Packham wrote: When you did the port from Marvell's source did you script any of the tidy-up that you did along the way? Not really. At least not in a reproducible way. I spent long hours running Lindent, recursive-replace tools and especially manual code inspection and re-formatting on this huge code. Still the outcome is far from perfect, but hopefully better that the original version. I'm running up a new board and with the upstream u-boot DDR training occasionally fails. But with the Marvell bootloader it doesn't fail. The initial port was done from TIP-1.29 but Marvell are now up to TIP-1.55 so there is probably some difference that results in my board working. One difference I've spotted so far is that Marvell enable 2T timing mode for all Armada 38x boards (the comment says "resolve low freq instability"). But doing that doesn't magically make my board work. Did you compare all DDR register values (the "good" ones and the "bad" ones) and only the the 2T timing is different? There are more differences. 2T was the one that stuckout. As you know working backwards from register values to where the code sets them can be tricky with this code. I'm thinking I need to compare TIP-1.29 with TIP-1.55 to look for other differences but obviously that's going to be hard given the style changes. Has the style changed in between the Marvell versions as well? I have not looked into this code for quite some time. What I meant was u-boot has 1.29 and I have 1.55 from Marvell. The oldest Marvell version I have is 1.34 which helped me find the 2T thing. I'm wondering what differences exist between 1.29 and 1.34. 1.55 also has support for some newer integrated switch+CPU chips so it is a little hard to separate those bits from the A38X code. If you have any scripts (or even just a record of the regexes) that you used would you be able to share them? Please find some scripts attached, I've located that I have used while doing this porting. Thanks. That's a start at least. In the end once I fixed the ecc_scrubbing[1] I stopped seeing the training failures so I've basically stopped looking at the differences between the Marvell bootloader and u-boot. But in the meantime I can summarize the differences I have identified in case they might help someone in the future. * Marvell unconditionally enable 2T timing for A38X * Different settings for RD/WR ODT particularly in situations using only one chip-select. There are more differences in the register dumps but I haven't looked into the meaning of them. Thanks for the update Chris. I'm currently build-testing the MVEBU patches in Travis and will send the pull request, once this completes without issues. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 15/19] arm: socfpga: Add support to memory allocation in SPL
On Isn, 2017-09-25 at 11:21 +0200, Marek Vasut wrote: > On 09/25/2017 10:40 AM, tien.fong.c...@intel.com wrote: > > > > From: Tien Fong Chee> > > > Add support to memory allocation in SPL for preparation to enable > > FAT > > in SPL. Memory allocation is needed by FAT to work properly. > > > > Signed-off-by: Tien Fong Chee > Gen 5 does have malloc support in SPL, so what's the deal here ? > For FAT to work properly in Arria 10 SPL, SPL malloc need to be enabled, and the min of SPL malloc size is 0x2000. FAT needed in Arria 10 SPL, because u-boot.img is stored in FAT partition. > > > > --- > > include/configs/socfpga_common.h | 23 ++- > > 1 file changed, 22 insertions(+), 1 deletion(-) > > > > diff --git a/include/configs/socfpga_common.h > > b/include/configs/socfpga_common.h > > index 7549ee8..9b6719e 100644 > > --- a/include/configs/socfpga_common.h > > +++ b/include/configs/socfpga_common.h > > @@ -280,17 +280,34 @@ unsigned int > > cm_get_qspi_controller_clk_hz(void); > > /* > > * SPL > > * > > - * SRAM Memory layout: > > + * SRAM Memory layout for gen 5: > > * > > * 0x_ .. Start of SRAM > > * 0x_ .. Top of stack (grows down) > > * 0x_ .. Malloc area > > * 0x_ .. Global Data > > * 0x_FF00 .. End of SRAM > > + * > > + * SRAM Memory layout for Arria 10: > > + * 0xFFE0_ .. Start of SRAM (bottom) > > + * 0xFFEx_ .. Top of stack (grows down to bottom) > > + * 0xFFEy_ .. Malloc area (grows up to top) > > + * 0xFFEz_ .. Global Data > > + * 0xFFE3_ .. End of SRAM (top) > > */ > > #define CONFIG_SPL_FRAMEWORK > > #define CONFIG_SPL_TEXT_BASE CONFIG_SYS_INIT_RAM_AD > > DR > > #define CONFIG_SPL_MAX_SIZECONFIG_SYS_INIT_RAM_SIZ > > E > > +#if defined(CONFIG_TARGET_SOCFPGA_ARRIA10) > > +/* SPL memory allocation configuration, it is required by FAT > > feature */ > > +#ifndef CONFIG_SYS_SPL_MALLOC_START > > +#define CONFIG_SYS_SPL_MALLOC_SIZE 0x2000 > > +#define CONFIG_SYS_SPL_MALLOC_START(CONFIG_SYS_INIT_RAM_SI > > ZE - \ > > + GENERATED_GBL_DATA_SIZE - > > \ > > + CONFIG_SYS_SPL_MALLOC_SIZ > > E + \ > > + CONFIG_SYS_INIT_RAM_ADDR) > > +#endif > > +#endif > > > > /* SPL SDMMC boot support */ > > #ifdef CONFIG_SPL_MMC_SUPPORT > > @@ -320,7 +337,11 @@ unsigned int > > cm_get_qspi_controller_clk_hz(void); > > /* > > * Stack setup > > */ > > +#if defined(CONFIG_TARGET_SOCFPGA_GEN5) > > #define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR > > +#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10) > > +#define CONFIG_SPL_STACK (CONFIG_SYS_SPL_MALLOC_STA > > RT - 1) > > +#endif > > > > /* Extra Environment */ > > #ifndef CONFIG_SPL_BUILD > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 14/19] arm: socfpga: Enable build for DDR Arria 10
On Isn, 2017-09-25 at 11:20 +0200, Marek Vasut wrote: > On 09/25/2017 10:40 AM, tien.fong.c...@intel.com wrote: > > > > From: Tien Fong Chee> > > > This patch is for enabling the DDR support on Arria 10. > > > > Signed-off-by: Tien Fong Chee > > --- > > drivers/ddr/altera/Makefile | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/ddr/altera/Makefile > > b/drivers/ddr/altera/Makefile > > index ac4ab85..02f8b7c 100644 > > --- a/drivers/ddr/altera/Makefile > > +++ b/drivers/ddr/altera/Makefile > > @@ -10,4 +10,5 @@ > > > > ifdef CONFIG_ALTERA_SDRAM > > obj-$(CONFIG_TARGET_SOCFPGA_GEN5) += sdram_gen5.o sequencer.o > > +obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += sdram_arria10.o > > endif > > > This should be part of the patch which added the sdram_arria10.c > Okay. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ZynqMP qspi
On Tue, Sep 26, 2017 at 9:07 AM, Liam Beguinwrote: > > Resending with proper CC since the email came back. > > On 24/09/17 09:36 PM, Liam Beguin wrote: >> Hi, >> >> I'm testing a new Xilinx zynqmp dev board and was not able to probe the >> qspi with the latest mainline U-Boot. I see that there is a 'zynqmp_qspi' >> driver in the Xilinx tree [1] but nothing in mainline. After a little >> digging, I found a thread on the list [2] (and [3]) and was wondering in >> what state this was now. >> >> [1] >> https://github.com/Xilinx/u-boot-xlnx/blob/master/drivers/spi/zynqmp_qspi.c >> [2] https://lists.denx.de/pipermail/u-boot/2016-July/261003.html >> [3] https://lists.denx.de/pipermail/u-boot/2016-November/273650.html I think, Siva is working on it. and he would be best to comment this. 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 https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: mvebu: add SAR frequency values for 1.8/2.0GHz
Hi Chris, On 26.09.2017 00:21, Chris Packham wrote: On Tue, Sep 5, 2017 at 5:03 PM, Chris Packhamwrote: The Armada-38x has 1.8GHz and 2.0GHz variants. Add entries for these variants to the sar_freq_tab. Signed-off-by: Chris Packham --- arch/arm/mach-mvebu/cpu.c | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c index f7f83bfa3655..74a63dd6560b 100644 --- a/arch/arm/mach-mvebu/cpu.c +++ b/arch/arm/mach-mvebu/cpu.c @@ -112,13 +112,15 @@ static const struct sar_freq_modes sar_freq_tab[] = { #elif defined(CONFIG_ARMADA_38X) /* SAR frequency values for Armada 38x */ static const struct sar_freq_modes sar_freq_tab[] = { - { 0x0, 0x0, 666, 333, 333 }, - { 0x2, 0x0, 800, 400, 400 }, - { 0x4, 0x0, 1066, 533, 533 }, - { 0x6, 0x0, 1200, 600, 600 }, - { 0x8, 0x0, 1332, 666, 666 }, - { 0xc, 0x0, 1600, 800, 800 }, - { 0xff, 0xff,0, 0, 0 } /* 0xff marks end of array */ + { 0x0, 0x0, 666, 333, 333 }, + { 0x2, 0x0, 800, 400, 400 }, + { 0x4, 0x0, 1066, 533, 533 }, + { 0x6, 0x0, 1200, 600, 600 }, + { 0x8, 0x0, 1332, 666, 666 }, + { 0xc, 0x0, 1600, 800, 800 }, + { 0x10, 0x0, 1866, 933, 933 }, + { 0x13, 0x0, 2000, 1000, 933 }, + { 0xff, 0xff,0,0, 0 } /* 0xff marks end of array */ }; #else /* SAR frequency values for Armada XP */ -- 2.14.1 Ping? I've been waiting for some patch updates, which have broken compilation for MVEBU boards. I'll pull hopefully today. Sorry for the delay. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 16/19] arm: socfpga: Enhance Intel SoCFPGA program header to support Arria 10
On Isn, 2017-09-25 at 11:23 +0200, Marek Vasut wrote: > On 09/25/2017 10:40 AM, tien.fong.c...@intel.com wrote: > > > > From: Tien Fong Chee> > > > Enhance preloader header with both additional program length and > > program > > entry offset attributes, which offset is relative to the start of > > program > > header. > > > > Signed-off-by: Tien Fong Chee > > --- > > arch/arm/mach-socfpga/include/mach/boot0.h | 11 +-- > > 1 file changed, 9 insertions(+), 2 deletions(-) > > > > diff --git a/arch/arm/mach-socfpga/include/mach/boot0.h > > b/arch/arm/mach-socfpga/include/mach/boot0.h > > index 22d9e7f..33c9368 100644 > > --- a/arch/arm/mach-socfpga/include/mach/boot0.h > > +++ b/arch/arm/mach-socfpga/include/mach/boot0.h > > @@ -11,8 +11,15 @@ > > .balignl 64,0xf33db33f; > > > > .word 0x1337c0d3; /* SoCFPGA preloader > > validation word */ > > - .word 0xc01df00d; /* Version, flags, length > > */ > > - .word 0xcafec0d3; /* Checksum, zero-pad */ > > + .word 0xc01df00d; /* Header > > length(2B),flags(1B),version(1B) */ > > +#ifndef CONFIG_TARGET_SOCFPGA_GEN5 > > + .word 0xfeedface; /* Program length(4B) */ > Keep this indent intact, then it won't generate these crappy - > entries. > Are you saying to keep the comment indent intact, and allign with 1st comment /* SoCFPGA preloader validation word */ ? > > > > + .word 0xf00dcafe; /* > > + * Program entry offset(4B),relative > > to > > + * the start of program header > > + */ > > +#endif > > + .word 0xcafec0d3; /* Simple > > checksum(2B),spare offset(2B) */ > > nop; > > > > b reset;/* SoCFPGA jumps here */ > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 17/19] arm: socfpga: Adding clock frequency info for U-boot
On Isn, 2017-09-25 at 11:23 +0200, Marek Vasut wrote: > On 09/25/2017 10:40 AM, tien.fong.c...@intel.com wrote: > > > > From: Tien Fong Chee> > > > Clock frequency info is required in U-boot. > > > > Signed-off-by: Tien Fong Chee > I want a TB on Gen 5 > What is TB? > > > > --- > > arch/arm/mach-socfpga/board.c | 6 ++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/arch/arm/mach-socfpga/board.c b/arch/arm/mach- > > socfpga/board.c > > index 965f9dc..a00f63b 100644 > > --- a/arch/arm/mach-socfpga/board.c > > +++ b/arch/arm/mach-socfpga/board.c > > @@ -8,7 +8,10 @@ > > > > #include > > #include > > +#include > > #include > > +#include > > +#include > > #include > > > > #include > > @@ -26,6 +29,9 @@ int board_init(void) > > /* Address of boot parameters for ATAG (if ATAG is used) > > */ > > gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100; > > > > + /* configuring the clock based on handoff */ > > + cm_basic_init(gd->fdt_blob); > > + > > return 0; > > } > > > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 19/19] arm: socfpga: Enable SPL loading U-boot to DDR and booting U-boot
On Isn, 2017-09-25 at 11:24 +0200, Marek Vasut wrote: > On 09/25/2017 10:40 AM, tien.fong.c...@intel.com wrote: > > > > From: Tien Fong Chee> > > > Enable SPL loading U-boot from SDMMC to DDR and booting U-boot. > This patch seems to be doing more than just one thing ... > I can split into two patches: 1) Enable DDR up by configuring FPGA so SPL able loading U-boot to DDR 2) Setting up configs so SPL can boot U-boot from FAT. > > > > Signed-off-by: Tien Fong Chee > > --- > > arch/arm/mach-socfpga/spl.c | 55 > > + > > common/spl/spl_mmc.c | 2 +- > > configs/socfpga_arria10_defconfig | 57 > > ++- > > include/spl.h | 2 ++ > > 4 files changed, 108 insertions(+), 8 deletions(-) > > > > diff --git a/arch/arm/mach-socfpga/spl.c b/arch/arm/mach- > > socfpga/spl.c > > index aba116d..9b381bb 100644 > > --- a/arch/arm/mach-socfpga/spl.c > > +++ b/arch/arm/mach-socfpga/spl.c > > @@ -15,6 +15,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -22,6 +23,10 @@ > > #include > > #include > > #include > > +#include > > +#include > > +#include > > +#include > > #include > > #if defined(CONFIG_TARGET_SOCFPGA_ARRIA10) > > #include > > @@ -29,6 +34,9 @@ > > > > DECLARE_GLOBAL_DATA_PTR; > > > > +#define BSIZE 4096 > > +#define PERIPH_RBF 0 > > + > > #if defined(CONFIG_TARGET_SOCFPGA_GEN5) > > static struct pl310_regs *const pl310 = > > (struct pl310_regs *)CONFIG_SYS_PL310_BASE; > > @@ -197,6 +205,12 @@ void board_init_f(ulong dummy) > > #elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10) > > void spl_board_init(void) > > { > > + int rval = 0; > > + int len = 0; > > + u32 buffer[BSIZE] __aligned(ARCH_DMA_MINALIGN); > > + struct spl_boot_device bootdev; > > + fpga_fs_info fpga_fsinfo; > > + > > /* configuring the clock based on handoff */ > > cm_basic_init(gd->fdt_blob); > > WATCHDOG_RESET(); > > @@ -214,6 +228,47 @@ void spl_board_init(void) > > > > /* Add device descriptor to FPGA device table */ > > socfpga_fpga_add(); > > + > > + bootdev.boot_device = spl_boot_device(); > > + > > + if (BOOT_DEVICE_MMC1 == bootdev.boot_device) { > > + struct mmc *mmc = NULL; > > + int err = 0; > > + > > + spl_mmc_find_device(, bootdev.boot_device); > > + > > + err = mmc_init(mmc); > > + > > + if (err) { > > +#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT > > + printf("spl: mmc init failed with error: > > %d\n", err); > > +#endif > > + } > > + > > + fpga_fsinfo.dev_part = (char *)get_cff_devpart(gd- > > >fdt_blob, > > + & > > len); > > + > > + fpga_fsinfo.filename = (char > > *)get_cff_filename(gd->fdt_blob, > > + & > > len, > > + PE > > RIPH_RBF); > > + > > + fpga_fsinfo.interface = "mmc"; > > + > > + fpga_fsinfo.fstype = FS_TYPE_FAT; > > + } else { > > + printf("Invalid boot device!\n"); > > + return; > > + } > > + > > + /* Program peripheral RBF */ > > + if (fpga_fsinfo.filename && fpga_fsinfo.dev_part && (len > > > 0)) > > + rval = fpga_fsload(0, buffer, BSIZE, > > _fsinfo); > > + > > + if (rval > 0) { > > + config_pins(gd->fdt_blob, "shared"); > > + > > + ddr_calibration_sequence(); > > + } > > } > > > > void board_init_f(ulong dummy) > > diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c > > index b26..159443f 100644 > > --- a/common/spl/spl_mmc.c > > +++ b/common/spl/spl_mmc.c > > @@ -113,7 +113,7 @@ static int spl_mmc_get_device_index(u32 > > boot_device) > > return -ENODEV; > > } > > > > -static int spl_mmc_find_device(struct mmc **mmcp, u32 boot_device) > > +int spl_mmc_find_device(struct mmc **mmcp, u32 boot_device) > > { > > #if CONFIG_IS_ENABLED(DM_MMC) > > struct udevice *dev; > > diff --git a/configs/socfpga_arria10_defconfig > > b/configs/socfpga_arria10_defconfig > > index 4c73d73..2ff9801 100644 > > --- a/configs/socfpga_arria10_defconfig > > +++ b/configs/socfpga_arria10_defconfig > > @@ -2,33 +2,76 @@ CONFIG_ARM=y > > CONFIG_ARCH_SOCFPGA=y > > CONFIG_SYS_MALLOC_F_LEN=0x2000 > > CONFIG_TARGET_SOCFPGA_ARRIA10_SOCDK=y > > +CONFIG_SPL_STACK_R_ADDR=0x0080 > > CONFIG_IDENT_STRING="socfpga_arria10" > > CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc" > > -CONFIG_USE_BOOTARGS=y > > -CONFIG_BOOTARGS="console=ttyS0,115200" > > CONFIG_DEFAULT_FDT_FILE="socfpga_arria10_socdk_sdmmc.dtb" > > +CONFIG_FIT=y > > +CONFIG_SYS_CONSOLE_IS_IN_ENV=y > > +CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y > > +CONFIG_SYS_CONSOLE_ENV_OVERWRITE=y > > +CONFIG_SPL_ENV_SUPPORT=y >
[U-Boot] [PATCH] linux/bitfield.h: import from Linux 4.13
Copied from Linux 4.13. Commit log of 3e9b3112ec74 of Linux explains well why this header is useful. Signed-off-by: Masahiro Yamada--- In order to use this header, http://patchwork.ozlabs.org/patch/814471/ must be applied. is highly dependent on include/linux/bitfield.h | 106 +++ 1 file changed, 106 insertions(+) create mode 100644 include/linux/bitfield.h diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h new file mode 100644 index 000..8b9d6ff --- /dev/null +++ b/include/linux/bitfield.h @@ -0,0 +1,106 @@ +/* + * Copyright (C) 2014 Felix Fietkau + * Copyright (C) 2004 - 2009 Ivo van Doorn + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 + * as published by the Free Software Foundation + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef _LINUX_BITFIELD_H +#define _LINUX_BITFIELD_H + +#include + +/* + * Bitfield access macros + * + * FIELD_{GET,PREP} macros take as first parameter shifted mask + * from which they extract the base mask and shift amount. + * Mask must be a compilation time constant. + * + * Example: + * + * #define REG_FIELD_A GENMASK(6, 0) + * #define REG_FIELD_B BIT(7) + * #define REG_FIELD_C GENMASK(15, 8) + * #define REG_FIELD_D GENMASK(31, 16) + * + * Get: + * a = FIELD_GET(REG_FIELD_A, reg); + * b = FIELD_GET(REG_FIELD_B, reg); + * + * Set: + * reg = FIELD_PREP(REG_FIELD_A, 1) | + * FIELD_PREP(REG_FIELD_B, 0) | + * FIELD_PREP(REG_FIELD_C, c) | + * FIELD_PREP(REG_FIELD_D, 0x40); + * + * Modify: + * reg &= ~REG_FIELD_C; + * reg |= FIELD_PREP(REG_FIELD_C, c); + */ + +#define __bf_shf(x) (__builtin_ffsll(x) - 1) + +#define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx) \ + ({ \ + BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask), \ +_pfx "mask is not constant"); \ + BUILD_BUG_ON_MSG(!(_mask), _pfx "mask is zero");\ + BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ? \ +~((_mask) >> __bf_shf(_mask)) & (_val) : 0, \ +_pfx "value too large for the field"); \ + BUILD_BUG_ON_MSG((_mask) > (typeof(_reg))~0ull, \ +_pfx "type of reg too small for mask"); \ + __BUILD_BUG_ON_NOT_POWER_OF_2((_mask) + \ + (1ULL << __bf_shf(_mask))); \ + }) + +/** + * FIELD_FIT() - check if value fits in the field + * @_mask: shifted mask defining the field's length and position + * @_val: value to test against the field + * + * Return: true if @_val can fit inside @_mask, false if @_val is too big. + */ +#define FIELD_FIT(_mask, _val) \ + ({ \ + __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_FIT: "); \ + !typeof(_mask))_val) << __bf_shf(_mask)) & ~(_mask)); \ + }) + +/** + * FIELD_PREP() - prepare a bitfield element + * @_mask: shifted mask defining the field's length and position + * @_val: value to put in the field + * + * FIELD_PREP() masks and shifts up the value. The result should + * be combined with other fields of the bitfield using logical OR. + */ +#define FIELD_PREP(_mask, _val) \ + ({ \ + __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: ");\ + ((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask); \ + }) + +/** + * FIELD_GET() - extract a bitfield element + * @_mask: shifted mask defining the field's length and position + * @_reg: 32bit value of entire bitfield + * + * FIELD_GET() extracts the field specified by @_mask from the + * bitfield passed in as @_reg by masking and shifting it down. + */ +#define FIELD_GET(_mask, _reg) \ + ({ \ + __BF_FIELD_CHECK(_mask, _reg, 0U, "FIELD_GET: "); \ + (typeof(_mask))(((_reg) & (_mask)) >> __bf_shf(_mask)); \ + }) + +#endif -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 8/8] dm: define dev_*() log functions in DM header
Hi Simon, 2017-09-25 11:15 GMT+09:00 Simon Glass: > On 15 September 2017 at 23:10, Masahiro Yamada > wrote: >> Many drivers use dev_err, dev_info, etc. for logging. Currently, >> we are relying on , but I guess the best home is >> , taking into account that Linux defines them in >> . >> >> For now, I am keeping the ones in because lots of >> Linux-originated code uses dev_*() just for the purpose of syncing, >> but the first argument is not struct udevice, so we need to ignore >> it. Once this issue is ironed out, it would be possible to prefix >> log messages with a device name that emitted it, like Linux. >> >> Signed-off-by: Masahiro Yamada >> --- >> >> Changes in v2: >> - newly added >> >> include/dm/device.h| 72 >> ++ >> include/linux/compat.h | 17 >> 2 files changed, 89 insertions(+) > > Reviewed-by: Simon Glass > > But shouldn't it be emerg rather than emerge? > Good catch! I just moved the macros from include/linux/compat.h but it should be dev_emerg() Currently, there is no user of this macro, so it is better to rename it. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 8/8] dm: define dev_*() log functions in DM header
Many drivers had started to use dev_err, dev_info, etc. for log functions. Currently, we are relying on , but I guess the best home is , taking into account that Linux defines them in . For now, I am leaving the ones in because lots of Linux-originated code uses dev_*(), but the first argument is not struct udevice, so we need to ignore the bogus argument. More efforts are needed to iron out the issues. Signed-off-by: Masahiro YamadaReviewed-by: Simon Glass --- Changes in v3: - Rename dev_emerge to dev_emerg to adjust to Linux Changes in v2: - Newly added include/dm/device.h| 72 ++ include/linux/compat.h | 17 2 files changed, 89 insertions(+) diff --git a/include/dm/device.h b/include/dm/device.h index 4866f7c..813e49f 100644 --- a/include/dm/device.h +++ b/include/dm/device.h @@ -18,6 +18,7 @@ #include #include #include +#include struct driver_info; @@ -879,4 +880,75 @@ static inline void devm_kfree(struct udevice *dev, void *ptr) #endif /* ! CONFIG_DEVRES */ +/* + * REVISIT: + * remove the following after resolving conflicts with + */ +#ifdef dev_dbg +#undef dev_dbg +#endif +#ifdef dev_vdbg +#undef dev_vdbg +#endif +#ifdef dev_info +#undef dev_info +#endif +#ifdef dev_err +#undef dev_err +#endif +#ifdef dev_warn +#undef dev_warn +#endif + +/* + * REVISIT: + * print device name like Linux + */ +#define dev_printk(dev, fmt, ...) \ +({ \ + printk(fmt, ##__VA_ARGS__); \ +}) + +#define __dev_printk(level, dev, fmt, ...) \ +({ \ + if (level < CONFIG_VAL(LOGLEVEL)) \ + dev_printk(dev, fmt, ##__VA_ARGS__);\ +}) + +#define dev_emerg(dev, fmt, ...) \ + __dev_printk(0, dev, fmt, ##__VA_ARGS__) +#define dev_alert(dev, fmt, ...) \ + __dev_printk(1, dev, fmt, ##__VA_ARGS__) +#define dev_crit(dev, fmt, ...) \ + __dev_printk(2, dev, fmt, ##__VA_ARGS__) +#define dev_err(dev, fmt, ...) \ + __dev_printk(3, dev, fmt, ##__VA_ARGS__) +#define dev_warn(dev, fmt, ...) \ + __dev_printk(4, dev, fmt, ##__VA_ARGS__) +#define dev_notice(dev, fmt, ...) \ + __dev_printk(5, dev, fmt, ##__VA_ARGS__) +#define dev_info(dev, fmt, ...) \ + __dev_printk(6, dev, fmt, ##__VA_ARGS__) + +#ifdef DEBUG +#define dev_dbg(dev, fmt, ...) \ + __dev_printk(7, dev, fmt, ##__VA_ARGS__) +#else +#define dev_dbg(dev, fmt, ...) \ +({ \ + if (0) \ + __dev_printk(7, dev, fmt, ##__VA_ARGS__); \ +}) +#endif + +#ifdef VERBOSE_DEBUG +#define dev_vdbg dev_dbg +#else +#define dev_vdbg(dev, fmt, ...)\ +({ \ + if (0) \ + __dev_printk(7, dev, fmt, ##__VA_ARGS__); \ +}) +#endif + #endif diff --git a/include/linux/compat.h b/include/linux/compat.h index 1b3f089..8711fe2 100644 --- a/include/linux/compat.h +++ b/include/linux/compat.h @@ -15,6 +15,23 @@ struct p_current{ extern struct p_current *current; +/* avoid conflict with */ +#ifdef dev_dbg +#undef dev_dbg +#endif +#ifdef dev_vdbg +#undef dev_vdbg +#endif +#ifdef dev_info +#undef dev_info +#endif +#ifdef dev_err +#undef dev_err +#endif +#ifdef dev_warn +#undef dev_warn +#endif + #define dev_dbg(dev, fmt, args...) \ debug(fmt, ##args) #define dev_vdbg(dev, fmt, args...)\ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V4 11/12] imx: mx6sabresd: enable dm drivers
Hi Stefano, > -Original Message- > From: Stefano Babic [mailto:sba...@denx.de] > Sent: Monday, September 25, 2017 10:12 PM > To: Peng Fan; sba...@denx.de > Cc: van.free...@gmail.com; u-boot@lists.denx.de; Fabio Estevam > > Subject: Re: [PATCH V4 11/12] imx: mx6sabresd: enable dm drivers > > Hi Peng, > > On 30/08/2017 08:14, Peng Fan wrote: > > Enable DM MMC/I2C/PMIC/GPIO/REGULATOR. > > > > Signed-off-by: Peng Fan > > Cc: Fabio Estevam > > Cc: Stefano Babic > > --- > > > > V2->V4: none > > [..] > > > > Enabling DM drivers seems to break sabresd: > > arm: + mx6sabresd > +common/usb_storage.c: In function 'usb_stor_probe_device': > +common/usb_storage.c:218:30: error: 'struct usb_device' has no member > named 'dev' > + data = dev_get_platdata(udev->dev); > + ^ > +common/usb_storage.c:228:32: error: 'struct usb_device' has no member > named 'dev' > + ret = blk_create_devicef(udev->dev, "usb_storage_blk", str, > +^ > > > Can you take a look ? I build mx6sabresd_defconfig, I met the following warning based on imx master branch, but did not met the build error. CC spl/common/spl/spl_fit.o common/spl/spl_fit.c: In function 'spl_load_fit_image': common/spl/spl_fit.c:201:7: warning: passing argument 4 of 'gunzip' from incompatible pointer type [enabled by default] src, )) { ^ In file included from common/spl/spl_fit.c:8:0: include/common.h:627:5: note: expected 'long unsigned int *' but argument is of type 'size_t *' int gunzip(void *, int, unsigned char *, unsigned long *); ^ Thanks, Peng. > > Best regards, > Stefano > > > -- > > = > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de > > = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
On Tue, Sep 26, 2017 at 07:10:21AM +0800, Bin Meng wrote: > Hi Marek, > > On Tue, Sep 26, 2017 at 12:41 AM, Marek Vasutwrote: > > The following changes since commit 1f6049e2501b5c35c61435dbc05ba96743202674: > > > > tools/mkimage: Make the path to the dtc binary that mkimage calls > > configurable (2017-09-24 07:33:03 -0400) > > > > are available in the git repository at: > > > > git://git.denx.de/u-boot-usb.git master > > > > for you to fetch changes up to 0184c6fb34b49f0bb1ffc7b0e35a597de339353e: > > > > usb: dwc2: Align size of invalidating dcache before starting DMA > > (2017-09-24 18:45:56 +0200) > > > > > > Bin Meng (6): > > dm: usb: Add a new USB controller operation 'get_max_xfer_size' > > dm: usb: xhci: Implement get_max_xfer_size() operation > > dm: usb: ehci: Implement get_max_xfer_size() operation > > usb: storage: Refactor to use max_xfer_blk from struct us_data > > dm: usb: storage: Fix broken read/write when both EHCD and xHCD > > are enabled > > usb: kbd: Set a default polling mechanism for USB keyboard > > > > I see this new PR does not contain the xHCI updates while previous one > had. Any reason to drop that? Yes, these break some of the tests in test/py/ as seen by 'make tests', thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
Hi Marek, On Tue, Sep 26, 2017 at 12:41 AM, Marek Vasutwrote: > The following changes since commit 1f6049e2501b5c35c61435dbc05ba96743202674: > > tools/mkimage: Make the path to the dtc binary that mkimage calls > configurable (2017-09-24 07:33:03 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-usb.git master > > for you to fetch changes up to 0184c6fb34b49f0bb1ffc7b0e35a597de339353e: > > usb: dwc2: Align size of invalidating dcache before starting DMA > (2017-09-24 18:45:56 +0200) > > > Bin Meng (6): > dm: usb: Add a new USB controller operation 'get_max_xfer_size' > dm: usb: xhci: Implement get_max_xfer_size() operation > dm: usb: ehci: Implement get_max_xfer_size() operation > usb: storage: Refactor to use max_xfer_blk from struct us_data > dm: usb: storage: Fix broken read/write when both EHCD and xHCD > are enabled > usb: kbd: Set a default polling mechanism for USB keyboard > I see this new PR does not contain the xHCI updates while previous one had. Any reason to drop that? > Eddie Cai (4): > usb: rockchip: add the rockusb gadget > usb: rockchip: add rockusb command > rockchip:usb: add a simple readme for rockusb > rockchip: rk3288: enable rockusb support on rk3288 based device > > Marek Vasut (1): > usb: xhci: Set number of event segments and entries to 1 > > Philipp Tomsich (3): > rockchip: xhci: Convert to livetree > usb: dwc2: convert to livetree > usb: host: ehci-generic: convert to livetree > > Seung-Woo Kim (1): > usb: dwc2: Align size of invalidating dcache before starting DMA > Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] DDR training code for Armada 38x
For the internet historians, On Thu, Sep 21, 2017 at 4:25 PM, Chris Packhamwrote: > On Wed, Sep 20, 2017 at 5:31 PM, Stefan Roese wrote: >> Hi Chris, >> >> On 19.09.2017 20:58, Chris Packham wrote: >>> >>> When you did the port from Marvell's source did you script any of the >>> tidy-up that you did along the way? >> >> >> Not really. At least not in a reproducible way. I spent long >> hours running Lindent, recursive-replace tools and especially >> manual code inspection and re-formatting on this huge code. >> Still the outcome is far from perfect, but hopefully better >> that the original version. >> >>> I'm running up a new board and with the upstream u-boot DDR training >>> occasionally fails. But with the Marvell bootloader it doesn't fail. >>> The initial port was done from TIP-1.29 but Marvell are now up to >>> TIP-1.55 so there is probably some difference that results in my board >>> working. >>> >>> One difference I've spotted so far is that Marvell enable 2T timing >>> mode for all Armada 38x boards (the comment says "resolve low freq >>> instability"). But doing that doesn't magically make my board work. >> >> >> Did you compare all DDR register values (the "good" ones and the "bad" >> ones) and only the the 2T timing is different? >> > > There are more differences. 2T was the one that stuckout. As you know > working backwards from register values to where the code sets them can > be tricky with this code. > >>> I'm thinking I need to compare TIP-1.29 with TIP-1.55 to look for >>> other differences but obviously that's going to be hard given the >>> style changes. >> >> >> Has the style changed in between the Marvell versions as well? I >> have not looked into this code for quite some time. >> > > What I meant was u-boot has 1.29 and I have 1.55 from Marvell. The > oldest Marvell version I have is 1.34 which helped me find the 2T > thing. I'm wondering what differences exist between 1.29 and 1.34. > 1.55 also has support for some newer integrated switch+CPU chips so it > is a little hard to separate those bits from the A38X code. > >>> If you have any scripts (or even just a record of the >>> regexes) that you used would you be able to share them? >> >> >> Please find some scripts attached, I've located that I have used while >> doing this porting. > > Thanks. That's a start at least. In the end once I fixed the ecc_scrubbing[1] I stopped seeing the training failures so I've basically stopped looking at the differences between the Marvell bootloader and u-boot. But in the meantime I can summarize the differences I have identified in case they might help someone in the future. * Marvell unconditionally enable 2T timing for A38X * Different settings for RD/WR ODT particularly in situations using only one chip-select. There are more differences in the register dumps but I haven't looked into the meaning of them. -- [1] - https://lists.denx.de/pipermail/u-boot/2017-September/307243.html ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARM: rmobile: Enable pinconf
Enable pinconf since it's now implemented and used in the DTs. Signed-off-by: Marek VasutCc: Nobuhiro Iwamatsu --- configs/r8a7795_salvator-x_defconfig | 1 + configs/r8a7795_ulcb_defconfig | 1 + configs/r8a7796_salvator-x_defconfig | 1 + configs/r8a7796_ulcb_defconfig | 1 + 4 files changed, 4 insertions(+) diff --git a/configs/r8a7795_salvator-x_defconfig b/configs/r8a7795_salvator-x_defconfig index 4b7a2d4572..1ff5dd6475 100644 --- a/configs/r8a7795_salvator-x_defconfig +++ b/configs/r8a7795_salvator-x_defconfig @@ -42,6 +42,7 @@ CONFIG_PHY_MICREL_KSZ90X1=y CONFIG_DM_ETH=y CONFIG_RENESAS_RAVB=y CONFIG_PINCTRL=y +CONFIG_PINCONF=y CONFIG_PINCTRL_PFC=y CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_FIXED=y diff --git a/configs/r8a7795_ulcb_defconfig b/configs/r8a7795_ulcb_defconfig index 1aa2e69ac6..58ba3fdf2a 100644 --- a/configs/r8a7795_ulcb_defconfig +++ b/configs/r8a7795_ulcb_defconfig @@ -35,6 +35,7 @@ CONFIG_MMC_UNIPHIER=y CONFIG_DM_ETH=y CONFIG_RENESAS_RAVB=y CONFIG_PINCTRL=y +CONFIG_PINCONF=y CONFIG_PINCTRL_PFC=y CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_FIXED=y diff --git a/configs/r8a7796_salvator-x_defconfig b/configs/r8a7796_salvator-x_defconfig index 083a832c56..e71b37fa97 100644 --- a/configs/r8a7796_salvator-x_defconfig +++ b/configs/r8a7796_salvator-x_defconfig @@ -43,6 +43,7 @@ CONFIG_PHY_MICREL_KSZ90X1=y CONFIG_DM_ETH=y CONFIG_RENESAS_RAVB=y CONFIG_PINCTRL=y +CONFIG_PINCONF=y CONFIG_PINCTRL_PFC=y CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_FIXED=y diff --git a/configs/r8a7796_ulcb_defconfig b/configs/r8a7796_ulcb_defconfig index cbeda77bfd..5ea832ff49 100644 --- a/configs/r8a7796_ulcb_defconfig +++ b/configs/r8a7796_ulcb_defconfig @@ -36,6 +36,7 @@ CONFIG_MMC_UNIPHIER=y CONFIG_DM_ETH=y CONFIG_RENESAS_RAVB=y CONFIG_PINCTRL=y +CONFIG_PINCONF=y CONFIG_PINCTRL_PFC=y CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_FIXED=y -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] video: test: Helper for writing strings
I'll need some more of this, let's not just copy-pasta the vidconsole_put_char() loop. Named to match vidconsole_put_char() in case that is ever useful outside of the tests. Signed-off-by: Rob Clark--- test/dm/video.c | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/test/dm/video.c b/test/dm/video.c index 4d000fa1be..6a5626c5e3 100644 --- a/test/dm/video.c +++ b/test/dm/video.c @@ -100,6 +100,14 @@ static int select_vidconsole(struct unit_test_state *uts, const char *drv_name) return 0; } +static void vidconsole_put_string(struct udevice *dev, const char *str) +{ + const char *s; + + for (s = str; *s; s++) + vidconsole_put_char(dev, *s); +} + /* Test text output works on the video console */ static int dm_test_video_text(struct unit_test_state *uts) { @@ -140,13 +148,11 @@ static int dm_test_video_chars(struct unit_test_state *uts) { struct udevice *dev, *con; const char *test_string = "Well\b\b\b\bxhe is\r \n\ta very \amodest \bman\n\t\tand Has much to\b\bto be modest about."; - const char *s; ut_assertok(select_vidconsole(uts, "vidconsole0")); ut_assertok(uclass_get_device(UCLASS_VIDEO, 0, )); ut_assertok(uclass_get_device(UCLASS_VIDEO_CONSOLE, 0, )); - for (s = test_string; *s; s++) - vidconsole_put_char(con, *s); + vidconsole_put_string(con, test_string); ut_asserteq(466, compress_frame_buffer(dev)); return 0; @@ -294,12 +300,10 @@ static int dm_test_video_truetype(struct unit_test_state *uts) { struct udevice *dev, *con; const char *test_string = "Criticism may not be agreeable, but it is necessary. It fulfils the same function as pain in the human body. It calls attention to an unhealthy state of things. Some see private enterprise as a predatory target to be shot, others as a cow to be milked, but few are those who see it as a sturdy horse pulling the wagon. The \aprice OF\b\bof greatness\n\tis responsibility.\n\nBye"; - const char *s; ut_assertok(uclass_get_device(UCLASS_VIDEO, 0, )); ut_assertok(uclass_get_device(UCLASS_VIDEO_CONSOLE, 0, )); - for (s = test_string; *s; s++) - vidconsole_put_char(con, *s); + vidconsole_put_string(con, test_string); ut_asserteq(12619, compress_frame_buffer(dev)); return 0; @@ -312,7 +316,6 @@ static int dm_test_video_truetype_scroll(struct unit_test_state *uts) struct sandbox_sdl_plat *plat; struct udevice *dev, *con; const char *test_string = "Criticism may not be agreeable, but it is necessary. It fulfils the same function as pain in the human body. It calls attention to an unhealthy state of things. Some see private enterprise as a predatory target to be shot, others as a cow to be milked, but few are those who see it as a sturdy horse pulling the wagon. The \aprice OF\b\bof greatness\n\tis responsibility.\n\nBye"; - const char *s; ut_assertok(uclass_find_device(UCLASS_VIDEO, 0, )); ut_assert(!device_active(dev)); @@ -321,8 +324,7 @@ static int dm_test_video_truetype_scroll(struct unit_test_state *uts) ut_assertok(uclass_get_device(UCLASS_VIDEO, 0, )); ut_assertok(uclass_get_device(UCLASS_VIDEO_CONSOLE, 0, )); - for (s = test_string; *s; s++) - vidconsole_put_char(con, *s); + vidconsole_put_string(con, test_string); ut_asserteq(33849, compress_frame_buffer(dev)); return 0; @@ -335,7 +337,6 @@ static int dm_test_video_truetype_bs(struct unit_test_state *uts) struct sandbox_sdl_plat *plat; struct udevice *dev, *con; const char *test_string = "...Criticism may or may\b\b\b\b\b\bnot be agreeable, but seldom it is necessary\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\bit is necessary. It fulfils the same function as pain in the human body. It calls attention to an unhealthy state of things."; - const char *s; ut_assertok(uclass_find_device(UCLASS_VIDEO, 0, )); ut_assert(!device_active(dev)); @@ -344,8 +345,7 @@ static int dm_test_video_truetype_bs(struct unit_test_state *uts) ut_assertok(uclass_get_device(UCLASS_VIDEO, 0, )); ut_assertok(uclass_get_device(UCLASS_VIDEO_CONSOLE, 0, )); - for (s = test_string; *s; s++) - vidconsole_put_char(con, *s); + vidconsole_put_string(con, test_string); ut_asserteq(34871, compress_frame_buffer(dev)); return 0; -- 2.13.5 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] cl-som-imx7: initial support
Hi Uri, On Sun, Sep 24, 2017 at 3:00 AM, Uri Mashiachwrote: > This patch series adds support for CompuLab CL-SOM-iMX7, SBC-iMX7, > SBC-IOT-iMX7 > and IOT-GATE-iMX7. > > CL-SOM-iMX7 is a miniature System-on-Module (SoM) based on > NXP i.MX7 processor family. > > SBC-iMX7 is a single board computer, implemented with the CL-SOM-iMX7 module > and the SB-SOM-iMX7 carrier board. > The CL-SOM-iMX7 providing most of the functions and the SB-SOM-iMX7 providing > additional peripheral functions and connectors. > > SBC-IOT-iMX7 is a internet of things single board computer, implemented with > the CL-SOM-iMX7 module and the SB-IOT-iMX7 carrier board. > The CL-SOM-iMX7 providing most of the functions and the SB-IOT-iMX7 providing > additional peripheral functions and connectors. > > The CL-SOM-iMX7 has the following features: > > CPU:NXP (Freescale) i.MX 7Dual ARM Cortex-A7, 1GHz processor > (dual-core) or > NXP (Freescale) i.MX 7Solo ARM Cortex-A7, 800MHz processor > (single-core) > > RAM:256MB – 2GB, DDR3L-1066 > > Storage:SLC NAND flash, 128MB - 1GB or > eMMC flash, 4GB - 32GB > > Ethernet: Up to 2x 10/100/1000Mbps Ethernet ports (MAC+PHY) > > WiFi: 802.11b/g/n WiFi interface (TI WiLink 8 WL1801 chipset) or > Dual-band 2x2 802.11a/b/g/n WiFi interface (TI WiLink 8 > WL1837 chipset) > > Bluetooth: Bluetooth 4.1 BLE > > Analog Audio: Audio codec with stereo output, stereo input and microphone > support > > Digital Audio: I2S compliant digital audio interface, MQS audio interface > > Display:Parallel 24-bit display interface, up to 1920 x 1080 @60Hz, > LVDS, up to 1400 x 1050 @60Hz > MIPI-DSI, 2 data lanes, up to 1400 x 1050 @60Hz > > More details can be found here: > > http://www.compulab.com/products/computer-on-modules/cl-som-imx7-freescale-i-mx-7-system-on-module/ > > http://www.compulab.com/products/sbcs/sbc-imx7-freescale-i-mx-7-single-board-computer/ > > http://www.compulab.com/products/sbcs/sbc-iot-imx7-nxp-i-mx-7-internet-of-things-single-board-computer/ > > http://www.compulab.com/products/iot-gateways/iot-gate-imx7-nxp-i-mx-7-internet-of-things-gateway/ > > Ilya Ledvich (1): > arm: imx7d: add support for Compulab cl-som-imx7 > > Uri Mashiach (3): > imx: mx7: fix the CCM_ macros > imx: mx7: DDR controller configuration for the i.MX7 architecture > imx: mx7: SPL support for i.MX7 I didn't have a chance to test it yet, but I don't want to block this work. Your series looks good, thanks: Reviewed-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/4] fs/fat: Fix pathnames using '..' that lead to the root directory
If we end up back in the root directory via a '..' directory entry, set itr->is_root accordingly. Failing to do that gives spews like "Invalid FAT entry" and being unable to access directory entries located past the first cluster of the root directory. Fixes: 8eafae209c35 ("fat/fs: convert to directory iterators") Reviewed-by: Tom RiniSigned-off-by: Tuomas Tynkkynen --- v2: Add Reviewed-by --- fs/fat/fat.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/fat/fat.c b/fs/fat/fat.c index 36a309c73c..3d3e17e8fa 100644 --- a/fs/fat/fat.c +++ b/fs/fat/fat.c @@ -710,13 +710,14 @@ static void fat_itr_child(fat_itr *itr, fat_itr *parent) itr->fsdata = parent->fsdata; if (clustnum > 0) { itr->clust = clustnum; + itr->is_root = 0; } else { itr->clust = parent->fsdata->root_cluster; + itr->is_root = 1; } itr->dent = NULL; itr->remaining = 0; itr->last_cluster = 0; - itr->is_root = 0; } static void *next_cluster(fat_itr *itr) -- 2.13.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 4/4] fs-test: Add test for a filename using '..' to go back to the root
The previous commit fixed a problem in FAT code where going back to the root directory using '..' wouldn't work correctly on FAT12 or FAT16. Add a test to exercise this case (which was once fixed in commit 18a10d46f26 "fat: handle paths that include ../" but reintroduced due to the directory iterator refactoring). This test only very barely catches the problem - without the fix the size command still gives valid output but the additional spurious "Invalid FAT entry" error message makes it not get caught in the 'egrep -A3 ' output. I tried to make a proper test that grows the root directory to two clusters lots of with dummy files but that causes the write tests to crash the sandbox totally... Signed-off-by: Tuomas Tynkkynen--- v2: - Increase context of the 'ls' test to also pass on ext4 (due to the added SUBDIR subdirectory) - Update the result summary in the header --- test/fs/fs-test.sh | 38 -- 1 file changed, 24 insertions(+), 14 deletions(-) diff --git a/test/fs/fs-test.sh b/test/fs/fs-test.sh index 0ac34983a1..20d5dd8a47 100755 --- a/test/fs/fs-test.sh +++ b/test/fs/fs-test.sh @@ -9,18 +9,18 @@ # It currently tests the fs/sb and native commands for ext4 and fat partitions # Expected results are as follows: # EXT4 tests: -# fs-test.sb.ext4.out: Summary: PASS: 23 FAIL: 0 -# fs-test.ext4.out: Summary: PASS: 23 FAIL: 0 -# fs-test.fs.ext4.out: Summary: PASS: 23 FAIL: 0 +# fs-test.sb.ext4.out: Summary: PASS: 24 FAIL: 0 +# fs-test.ext4.out: Summary: PASS: 24 FAIL: 0 +# fs-test.fs.ext4.out: Summary: PASS: 24 FAIL: 0 # FAT16 tests: -# fs-test.sb.fat16.out: Summary: PASS: 23 FAIL: 0 -# fs-test.fat16.out: Summary: PASS: 20 FAIL: 3 -# fs-test.fs.fat16.out: Summary: PASS: 20 FAIL: 3 +# fs-test.sb.fat16.out: Summary: PASS: 24 FAIL: 0 +# fs-test.fat16.out: Summary: PASS: 21 FAIL: 3 +# fs-test.fs.fat16.out: Summary: PASS: 21 FAIL: 3 # FAT32 tests: -# fs-test.sb.fat32.out: Summary: PASS: 23 FAIL: 0 -# fs-test.fat32.out: Summary: PASS: 20 FAIL: 3 -# fs-test.fs.fat32.out: Summary: PASS: 20 FAIL: 3 -# Total Summary: TOTAL PASS: 195 TOTAL FAIL: 12 +# fs-test.sb.fat32.out: Summary: PASS: 24 FAIL: 0 +# fs-test.fat32.out: Summary: PASS: 21 FAIL: 3 +# fs-test.fs.fat32.out: Summary: PASS: 21 FAIL: 3 +# Total Summary: TOTAL PASS: 204 TOTAL FAIL: 12 # pre-requisite binaries list. PREREQ_BINS="md5sum mkfs mount umount dd fallocate mkdir" @@ -229,10 +229,14 @@ ${PREFIX}ls host${SUFFIX} $6 # We want ${PREFIX}size host 0:0 $3 for host commands and # sb size hostfs - $3 for hostfs commands. # 1MB is 0x0010 -# Test Case 2 - size of small file +# Test Case 2a - size of small file ${PREFIX}size host${SUFFIX} ${FPATH}$FILE_SMALL printenv filesize setenv filesize +# Test Case 2b - size of small file via a path using '..' +${PREFIX}size host${SUFFIX} ${FPATH}SUBDIR/../$FILE_SMALL +printenv filesize +setenv filesize # 2.5GB (1024*1024*2500) is 0x9C40 # Test Case 3 - size of big file @@ -347,6 +351,9 @@ function create_files() { mkdir -p "$MOUNT_DIR" sudo mount -o loop,rw "$1" "$MOUNT_DIR" + # Create a subdirectory. + sudo mkdir -p "$MOUNT_DIR/SUBDIR" + # Create big file in this image. # Note that we work only on the start 1MB, couple MBs in the 2GB range # and the last 1 MB of the huge 2.5GB file. @@ -453,16 +460,19 @@ function check_results() { FAIL=0 # Check if the ls is showing correct results for 2.5 gb file - grep -A6 "Test Case 1 " "$1" | egrep -iq "262144 *$4" + grep -A7 "Test Case 1 " "$1" | egrep -iq "262144 *$4" pass_fail "TC1: ls of $4" # Check if the ls is showing correct results for 1 mb file - grep -A6 "Test Case 1 " "$1" | egrep -iq "1048576 *$3" + grep -A7 "Test Case 1 " "$1" | egrep -iq "1048576 *$3" pass_fail "TC1: ls of $3" # Check size command on 1MB.file - egrep -A3 "Test Case 2 " "$1" | grep -q "filesize=10" + egrep -A3 "Test Case 2a " "$1" | grep -q "filesize=10" pass_fail "TC2: size of $3" + # Check size command on 1MB.file via a path using '..' + egrep -A3 "Test Case 2b " "$1" | grep -q "filesize=10" + pass_fail "TC2: size of $3 via a path using '..'" # Check size command on 2.5GB.file egrep -A3 "Test Case 3 " "$1" | grep -q "filesize=9c40" -- 2.13.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/4] fs-test: Add FAT16 support
Currently we can only test FAT32 which is the default FAT version that mkfs.vfat creates by default. Instead make it explicitly create either a FAT16 or a FAT32 volume. This allows us to exercise more code, for instance the root directory handling is done differently in FAT32 than the older FATs. Adding FAT12 support is a much bigger job since the test creates a 2.5GB file and the FAT12 maximum partition size is way smaller than that. Signed-off-by: Tuomas Tynkkynen--- v2: Update result summary in the header --- test/fs/fs-test.sh | 55 +++--- 1 file changed, 36 insertions(+), 19 deletions(-) diff --git a/test/fs/fs-test.sh b/test/fs/fs-test.sh index b19486419e..0ac34983a1 100755 --- a/test/fs/fs-test.sh +++ b/test/fs/fs-test.sh @@ -12,11 +12,15 @@ # fs-test.sb.ext4.out: Summary: PASS: 23 FAIL: 0 # fs-test.ext4.out: Summary: PASS: 23 FAIL: 0 # fs-test.fs.ext4.out: Summary: PASS: 23 FAIL: 0 -# FAT tests: -# fs-test.sb.fat.out: Summary: PASS: 23 FAIL: 0 -# fs-test.fat.out: Summary: PASS: 20 FAIL: 3 -# fs-test.fs.fat.out: Summary: PASS: 20 FAIL: 3 -# Total Summary: TOTAL PASS: 132 TOTAL FAIL: 6 +# FAT16 tests: +# fs-test.sb.fat16.out: Summary: PASS: 23 FAIL: 0 +# fs-test.fat16.out: Summary: PASS: 20 FAIL: 3 +# fs-test.fs.fat16.out: Summary: PASS: 20 FAIL: 3 +# FAT32 tests: +# fs-test.sb.fat32.out: Summary: PASS: 23 FAIL: 0 +# fs-test.fat32.out: Summary: PASS: 20 FAIL: 3 +# fs-test.fs.fat32.out: Summary: PASS: 20 FAIL: 3 +# Total Summary: TOTAL PASS: 195 TOTAL FAIL: 12 # pre-requisite binaries list. PREREQ_BINS="md5sum mkfs mount umount dd fallocate mkdir" @@ -41,7 +45,7 @@ SMALL_FILE="1MB.file" BIG_FILE="2.5GB.file" # $MD5_FILE will have the expected md5s when we do the test -# They shall have a suffix which represents their file system (ext4/fat) +# They shall have a suffix which represents their file system (ext4/fat16/...) MD5_FILE="${OUT_DIR}/md5s.list" # $OUT shall be the prefix of the test output. Their suffix will be .out @@ -104,15 +108,25 @@ function prepare_env() { } # 1st parameter is the name of the image file to be created -# 2nd parameter is the filesystem - fat ext4 etc +# 2nd parameter is the filesystem - fat16 ext4 etc # -F cant be used with fat as it means something else. function create_image() { # Create image if not already present - saves time, while debugging - if [ "$2" = "ext4" ]; then + case "$2" in + fat16) + MKFS_OPTION="-F 16" + FS_TYPE="fat" + ;; + fat32) + MKFS_OPTION="-F 32" + FS_TYPE="fat" + ;; + ext4) MKFS_OPTION="-F" - else - MKFS_OPTION="" - fi + FS_TYPE="ext4" + ;; + esac + if [ ! -f "$1" ]; then fallocate -l 3G "$1" &> /dev/null if [ $? -ne 0 ]; then @@ -123,8 +137,8 @@ function create_image() { exit $? fi fi - mkfs -t "$2" $MKFS_OPTION "$1" &> /dev/null - if [ $? -ne 0 -a "$2" = "fat" ]; then + mkfs -t "$FS_TYPE" $MKFS_OPTION "$1" &> /dev/null + if [ $? -ne 0 -a "$FS_TYPE" = "fat" ]; then # If we fail and we did fat, try vfat. mkfs -t vfat $MKFS_OPTION "$1" &> /dev/null fi @@ -136,7 +150,7 @@ function create_image() { } # 1st parameter is image file -# 2nd parameter is file system type - fat/ext4 +# 2nd parameter is file system type - fat16/ext4/... # 3rd parameter is name of small file # 4th parameter is name of big file # 5th parameter is fs/nonfs/sb - to dictate generic fs commands or @@ -149,7 +163,7 @@ function test_image() { length="0x0010" case "$2" in - fat) + fat*) FPATH="" PREFIX="fat" WRITE="write" @@ -550,7 +564,7 @@ TOTAL_PASS=0 # In each loop, for a given file system image, we test both the # fs command, like load/size/write, the file system specific command # like: ext4load/ext4size/ext4write and the sb load/ls/save commands. -for fs in ext4 fat; do +for fs in ext4 fat16 fat32; do echo "Creating $fs image if not already present." IMAGE=${IMG}.${fs}.img @@ -563,11 +577,14 @@ for fs in ext4 fat; do # Lets mount the image and test sb hostfs commands mkdir -p "$MOUNT_DIR" - if [ "$fs" = "fat" ]; then + case "$fs" in + fat*) uid="uid=`id -u`" - else + ;; + *) uid="" - fi + ;; + esac sudo mount -o loop,rw,$uid "$IMAGE" "$MOUNT_DIR" sudo chmod 777 "$MOUNT_DIR" -- 2.13.0 ___ U-Boot mailing list
[U-Boot] [PATCH v2 1/4] fs/ext4: Fix group descriptor checksum calculation
The current code doesn't compute the group descriptor checksum correctly for the filesystems that e2fsprogs 1.43.4 creates (they have 'Group descriptor size: 64' as reported by tune2fs). Extend the checksum calculation to be done as ext4_group_desc_csum() does in Linux. This fixes these errors in dmesg from running fs-test.sh and makes it succeed again: [1671902.620699] EXT4-fs (loop1): ext4_check_descriptors: Checksum for group 0 failed (35782!=10965) [1671902.620706] EXT4-fs (loop1): group descriptors corrupted! Signed-off-by: Tuomas Tynkkynen--- v2: New patch --- fs/ext4/ext4_common.c | 4 1 file changed, 4 insertions(+) diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c index 621c61e5c7..31952f48b9 100644 --- a/fs/ext4/ext4_common.c +++ b/fs/ext4/ext4_common.c @@ -432,6 +432,10 @@ uint16_t ext4fs_checksum_update(uint32_t i) crc = ext2fs_crc16(crc, desc, offset); offset += sizeof(desc->bg_checksum);/* skip checksum */ assert(offset == sizeof(*desc)); + if (offset < fs->gdsize) { + crc = ext2fs_crc16(crc, (__u8 *)desc + offset, + fs->gdsize - offset); + } } return crc; -- 2.13.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Issues with mx6 (cubox/wandboard) with 2017.09
Hi Peter, On Mon, Sep 25, 2017 at 3:54 PM, Peter Robinsonwrote: > Hi Fabio, > > I'm seeing some issues with some of the i.MX6 devices with the latest > stable release. It loads the SPL and then just seems to loop: > > U-Boot SPL 2017.09 (Sep 25 2017 - 18:42:10) > Trying to boot from MMC1 > > U-Boot SPL 2017.09 (Sep 25 2017 - 18:42:10) > Trying to boot from MMC1 > > U-Boot SPL 2017.09 (Sep 25 2017 - 18:42:10) > Trying to boot from MMC1 > > This is built on Fedora with latest gcc7 so I'm not sure if that's a > possible issue. Is this something people are aware of and I've missed > the fix. I haven't tested it with gcc7 yet, but if I use gcc6 I do not see the problem: U-Boot SPL 2017.09 (Sep 25 2017 - 15:55:59) Trying to boot from MMC1 U-Boot 2017.09 (Sep 25 2017 - 15:55:59 -0300) CPU: Freescale i.MX6Q rev1.2 at 792 MHz Reset cause: POR Board: Wandboard rev B1 I2C: ready DRAM: 2 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 No panel detected: default to HDMI Display: HDMI (1024x768) In:serial Out: serial Err: serial Net: FEC [PRIME] Hit any key to stop autoboot: 0 => So maybe this issue could be related to gcc7? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Issues with mx6 (cubox/wandboard) with 2017.09
Hi Fabio, I'm seeing some issues with some of the i.MX6 devices with the latest stable release. It loads the SPL and then just seems to loop: U-Boot SPL 2017.09 (Sep 25 2017 - 18:42:10) Trying to boot from MMC1 U-Boot SPL 2017.09 (Sep 25 2017 - 18:42:10) Trying to boot from MMC1 U-Boot SPL 2017.09 (Sep 25 2017 - 18:42:10) Trying to boot from MMC1 This is built on Fedora with latest gcc7 so I'm not sure if that's a possible issue. Is this something people are aware of and I've missed the fix. Thanks, Peter ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mx6: toradex: Remove custom CONFIG_SPL_PAD_TO definition
From: Fabio EstevamCONFIG_SPL_PAD_TO is already defined inside "imx6_spl.h", so there is no need to redefine it in the board config files. Signed-off-by: Fabio Estevam --- include/configs/apalis_imx6.h | 1 - include/configs/colibri_imx6.h | 1 - 2 files changed, 2 deletions(-) diff --git a/include/configs/apalis_imx6.h b/include/configs/apalis_imx6.h index a15f19d..51bf61c 100644 --- a/include/configs/apalis_imx6.h +++ b/include/configs/apalis_imx6.h @@ -23,7 +23,6 @@ #ifdef CONFIG_SPL #include "imx6_spl.h" -#define CONFIG_SPL_PAD_TO 0x11000 /* 4k IVT/DCD, 64k SPL */ #endif #define CONFIG_CMDLINE_TAG diff --git a/include/configs/colibri_imx6.h b/include/configs/colibri_imx6.h index db71369..ac9a23d 100644 --- a/include/configs/colibri_imx6.h +++ b/include/configs/colibri_imx6.h @@ -21,7 +21,6 @@ #ifdef CONFIG_SPL #include "imx6_spl.h" -#define CONFIG_SPL_PAD_TO 0x11000 /* 4k IVT/DCD, 64k SPL */ #endif #define CONFIG_CMDLINE_TAG -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] disk: Provide API to get partition by name for specific type
Hi Simon, On 24 September 2017 at 19:14, Simon Glasswrote: > Hi Sam, > > On 21 September 2017 at 16:51, Sam Protsenko > wrote: >> There is already existing function part_get_info_by_name(). >> But sometimes user is particularly interested in looking for only >> specific partition type. This patch implements such an API that >> provides partition searching by name for specified partition type. >> >> Signed-off-by: Sam Protsenko >> --- >> disk/part.c| 15 +-- >> include/part.h | 15 +++ >> 2 files changed, 28 insertions(+), 2 deletions(-) > > Reviewed-by: Simon Glass > > nit below > >> >> diff --git a/disk/part.c b/disk/part.c >> index aa9183d696..66b8101f98 100644 >> --- a/disk/part.c >> +++ b/disk/part.c >> @@ -21,6 +21,9 @@ >> #define PRINTF(fmt,args...) >> #endif >> >> +/* Check all partition types */ >> +#define PART_TYPE_ALL -1 >> + >> DECLARE_GLOBAL_DATA_PTR; >> >> #ifdef HAVE_BLOCK_DEVICE >> @@ -626,8 +629,8 @@ cleanup: >> return ret; >> } >> >> -int part_get_info_by_name(struct blk_desc *dev_desc, const char *name, >> - disk_partition_t *info) >> +int part_get_info_by_name_type(struct blk_desc *dev_desc, const char *name, >> + disk_partition_t *info, int part_type) >> { >> struct part_driver *first_drv = >> ll_entry_start(struct part_driver, part_driver); >> @@ -638,6 +641,8 @@ int part_get_info_by_name(struct blk_desc *dev_desc, >> const char *name, >> int ret; >> int i; >> for (i = 1; i < part_drv->max_entries; i++) { >> + if (part_type >= 0 && part_type != >> part_drv->part_type) >> + break; >> ret = part_drv->get_info(dev_desc, i, info); >> if (ret != 0) { >> /* no more entries in table */ >> @@ -652,6 +657,12 @@ int part_get_info_by_name(struct blk_desc *dev_desc, >> const char *name, >> return -1; >> } >> >> +int part_get_info_by_name(struct blk_desc *dev_desc, const char *name, >> + disk_partition_t *info) >> +{ >> + return part_get_info_by_name_type(dev_desc, name, info, >> PART_TYPE_ALL); >> +} >> + >> void part_set_generic_name(const struct blk_desc *dev_desc, >> int part_num, char *name) >> { >> diff --git a/include/part.h b/include/part.h >> index 86117a7ce5..1a61518722 100644 >> --- a/include/part.h >> +++ b/include/part.h >> @@ -173,6 +173,21 @@ int blk_get_device_part_str(const char *ifname, const >> char *dev_part_str, >> struct blk_desc **dev_desc, >> disk_partition_t *info, int allow_whole_dev); >> >> +/** >> + * part_get_info_by_name_type() - Search for a partition by name >> + *for only specified partition type >> + * >> + * @param dev_desc - block device descriptor >> + * @param gpt_name - the specified table entry name >> + * @param info - returns the disk partition info >> + * @param part_type - only search in partitions of this type > > Can you reference the PART_TYPE_ #define here (since we don't have an enum). > If you mean PART_TYPE_ALL, I'd prefer not to, because for all driver types you need to use part_get_info_by_name() API instead of new part_get_info_by_name_type(). Basically I just copied that doxygen block from part_get_info_by_name(), so if we should fix the description, we should probably do that for both functions, in separate patch. We can create corresponding enum in that patch as well. You agree? Also, the format of those doxygen comments is a bit wrong, we should either fix them, or switch to kernel-doc format. Actually, it bring the question: which format (doxygen or kernel-doc) we should use in U-Boot? Because right now it's a mix of both. So if you have an idea how it should look like, please share, so that I can rework this in one patch. As for this patch -- I'd really like it to be applied as is, so we can keep things atomic. Hope it's fine with you? Thanks. >> + * >> + * @return - the partition number on match (starting on 1), -1 on no match, >> + * otherwise error >> + */ >> +int part_get_info_by_name_type(struct blk_desc *dev_desc, const char *name, >> + disk_partition_t *info, int part_type); >> + >> /** >> * part_get_info_by_name() - Search for a partition by name >> * among all available registered partitions >> -- >> 2.14.1 >> > > Regards, > Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8: ls1046ardb: disable PPA loading during SPL stage for SD boot
On 09/18/2017 12:16 AM, Yangbo Lu wrote: > PPA loading during SPL stage is not required for nornal > SD boot scenario. > > Signed-off-by: Yangbo Lu> --- Applied to fsl-qoriq mater. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [v2] armv8: ls1043a: disable IFC in SPL only when QSPI is used
On 09/14/2017 07:09 PM, Yangbo Lu wrote: > Current u-boot disables IFC support for SD boot on all ls1043a > boards. Actually IFC only conflicts with QSPI on ls1043a hardware. > Only when QSPI is used, IFC should be disabled. Otherwise, > the u-boot with ls1043aqds_sdcard_ifc_defconfig would not work. > > Signed-off-by: Yangbo Lu> --- > Changes for v2: > - Modified the commit message. Applied to fsl-qoriq mater. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8: ls1043ardb: disable PPA loading during SPL stage for SD boot
On 09/18/2017 12:16 AM, Yangbo Lu wrote: > PPA loading during SPL stage is not required for nornal > SD boot scenario. > > Signed-off-by: Yangbo Lu> --- Applied to fsl-qoriq mater. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH][v3]board/ls2080ardb: Update board env based on SoC
On 09/14/2017 09:49 PM, Priyanka Jain wrote: > As per current implementation, default value of board env is > based on board filename i.e ls2080ardb. > > With distro support changes, this env is used to decide upon > kernel dtb which is different for other SoCs (ls2088a, ls2081a) > combination supported with this board. > > Add support to modify board env at runtime based on SoC type > > Signed-off-by: Priyanka Jain> --- > Changes for v3: >Corrected v2 patch for >Replace setenv() with env_set() > > Changes for v2: >Replace setenv() with env_set() > Applied to fsl-qoriq mater. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] board/ls2080ardb: Add mcmemsize variable in default env
On 08/29/2017 02:50 AM, Priyanka Jain wrote: > For most of ls2080ardb use-cases, mc private DRAM block is required > to be of 1.75GB. > Henc set mcmemsize=0x7000 in default env > > Signed-off-by: Priyanka Jain> --- Applied to fsl-qoriq mater. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8: fsl: i2c: Put I2C related code under CONFIG_SYS_I2C
On 09/04/2017 03:15 AM, Sriram Dash wrote: > I2C code is put under CONFIG_SYS_I2C > > Signed-off-by: Sriram Dash> --- Applied to fsl-qoriq mater. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8: fsl: ifc: Put IFC related code under CONFIG_FSL_IFC
On 09/04/2017 03:14 AM, Sriram Dash wrote: > IFC code is put under CONFIG_FSL_IFC > > Signed-off-by: Sriram Dash> --- Applied to fsl-qoriq mater. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] pci: layerscape: Fixup iommu-map for LS208xA
On 08/31/2017 12:59 AM, Bharat Bhushan wrote: > "pci: layerscape: Fixup device tree node for ls2088a" added > support for LS208xA devices but fixing iommu-map property > is missing. This patch adds support for fixing iommu-map. > > Signed-off-by: Bharat Bhushan> Signed-off-by: Ioana Ciornei > --- Revised commit message. Applied to fsl-qoriq mater. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] board/ls2081ardb: Update QSPI flash type from n25q512a to s25fs512s
On 08/18/2017 02:47 AM, Santan Kumar wrote: > As per updated board design, different QSPI flash > is connected on boards, hence change QSPI flash type > from Micron n25q512a device to spansion s25fs512s > device in dts and config. > > Signed-off-by: Santan Kumar> Signed-off-by: Yogesh Gaur > Signed-off-by: Priyanka Jain > --- Applied to fsl-qoriq mater. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] board/ls2080ardb: Remove CONFIG_DISPLAY_BOARDINFO_LATE
On 08/18/2017 02:47 AM, Santan Kumar wrote: > CONFIG_DISPLAY_BOARDINFO_LATE config is used to delay > the prints of boardinfo late in cycle during uboot boot. > This feature is not required in case of QSPI_BOOT. > > Signed-off-by: Santan Kumar> Signed-off-by: Priyanka Jain > --- Applied to fsl-qoriq mater. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8: fsl-layerscape: Put SATA code under SATA configs
On 08/17/2017 10:24 PM, Ashish Kumar wrote: > It is not necessary for every SoC to have 2 SATA controller. > So put SATA1, SATA2 code under respective defines. > > Signed-off-by: Prabhakar Kushwaha> Signed-off-by: Ashish Kumar > --- Applied to fsl-qoriq mater. Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] armv7: ls1021a: Fix marco CONFIG_LS102XA
On 09/14/2017 12:53 PM, York Sun wrote: > Commit a8ecb39e accidentally reverted config macro CONFIG_ARCH_LS1021A > to CONFIG_LS102XA. > > Signed-off-by: York Sun> --- Applied to fsl-qoriq mater. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] u-boot-usb/master sandbox unit test failure
On 09/25/2017 10:40 AM, Marek Vasut wrote: On 09/25/2017 06:13 PM, Stephen Warren wrote: Marek, +CC Bin I will drop the xhci patchset and hope to get a fixed one from him. The latest branch content (0184c6fb34b4 "usb: dwc2: Align size of invalidating dcache before starting DMA") passes the tests. The latest u-boot-usb master branch breaks the following unit tests for the sandbox target (as run by test/py): 8 failed ... test_ut[ut_dm_blk_usb] ... test_ut[ut_dm_usb_flash] ... test_ut[ut_dm_usb_keyb] ... test_ut[ut_dm_usb_multi] ... test_ut[ut_dm_usb_remove] ... test_ut[ut_dm_usb_tree] ... test_ut[ut_dm_usb_tree_remove] ... test_ut[ut_dm_usb_tree_reorder] The first failure is: => ut dm blk_usb Test: dm_test_blk_usb: blk.c USB0: scanning bus 1 for devices... usb_setup_descriptor: invalid max packet size failed, error -5 /var/lib/jenkins/workspace/u-boot-denx_uboot_usb-master-build/src/u-boot/test/dm/blk.c:78, dm_test_blk_usb(): 0 == uclass_get_device(UCLASS_MASS_STORAGE, 0, _dev): Expected 0, got -19 Test: dm_test_blk_usb: blk.c (flat tree) USB0: scanning bus 1 for devices... usb_setup_descriptor: invalid max packet size failed, error -5 /var/lib/jenkins/workspace/u-boot-denx_uboot_usb-master-build/src/u-boot/test/dm/blk.c:78, dm_test_blk_usb(): 0 == uclass_get_device(UCLASS_MASS_STORAGE, 0, _dev): Expected 0, got -19 Failures: 2 The others all look essentially the same. It looks like this was introduced sometime on Saturday (US time, ignoring my Jenkins polling delay), and the two subsequent pushes on Sunday and Monday didn't solve this. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/7] armv8: layerscape: Eanble falcon boot
On 09/25/2017 07:17 AM, Łukasz Majewski wrote: > Hi York, > > If you don't mind, I would like to ask you for some help and > clarification regarding your work. > >> Add jump_to_image_linux() for arm64. Add "noreturn" flag to >> armv8_switch_to_el2(). Add hooks to fsl-layerscape to enable falcon >> boot. > > I'm trying to do the same on imx6q board (armv7). > >> >> Signed-off-by: York Sun>> >> --- >> >> Changes in v2: >> Relace getenv_f() with env_get_f() after rebasing to latet master. >> >>.../arm/cpu/armv8/fsl-layerscape/doc/README.falcon | 140 >> + >>arch/arm/cpu/armv8/fsl-layerscape/spl.c| 29 + >>arch/arm/include/asm/system.h | 2 +- >>arch/arm/lib/spl.c | 11 ++ >>4 files changed, 181 insertions(+), 1 deletion(-) >>create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/doc/README.falcon >> >> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.falcon >> b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.falcon >> new file mode 100644 >> index 000..282b19f >> --- /dev/null >> +++ b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.falcon >> @@ -0,0 +1,140 @@ >> +Falcon boot option >> +-- >> +Falcon boot is a short cut boot method for SD/eMMC targets. It skips >> loading the >> +RAM version U-Boot. Instead, it loads FIT image and boot directly to Linux. >> +CONFIG_SPL_OS_BOOT enables falcon boot. CONFIG_SPL_LOAD_FIT enables the FIT > ^^ - this is a bit cumbersome, > since it requires some stub > for dtb creation (but this can be fixed for boards not yet supporting > dts u-boot configuration). > >> +image support (also need CONFIG_SPL_OF_LIBFDT, CONFIG_SPL_FIT and optionally >> +CONFIG_SPL_GZIP). >> + >> +To enable falcon boot, a hook function spl_start_uboot() returns 0 to >> indicate >> +booting U-Boot is not the first choice. The kernel FIT image needs to be put >> +at CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR. SPL mmc driver reads the header >> to >> +determine if this is a FIT image. If true, FIT image components are parsed >> and >> +copied or decompressed (if applicable) to their desitinations. If FIT image >> is >> +not found, normal U-Boot flow will follow. > > This part is similar to the one for old, venerable uImage. > >> + >> +An important part of falcon boot is to prepare the device tree. A normal >> U-Boot >> +does FDT fixups when booting Linux. For falcon boot, Linux boots directly >> from >> +SPL, skipping the normal U-Boot. The device tree has to be prepared in >> advance. >> +A command "spl export" should be called under the normal RAM version U-Boot. >> +It is equivalent to go through "bootm" step-by-step until device tree fixup >> is >> +done. The device tree in memory is the one needed for falcon boot. Falcon >> boot >> +flow suggests to save this image to SD/eMMC at the location pointed by macro >> +CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR, with maximum size specified by macro >> +CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS. However, when FIT image is used for >> +Linux, the device tree stored in FIT image overwrites the memory loaded by >> spl >> +driver from these sectors. We could change this loading order to favor the >> +stored sectors. But when secure boot is enabled, these sectors are used for >> +signature header and needs to be loaded before the FIT image. So it is >> important >> +to understand the device tree in FIT image should be the one actually used, >> or >> +leave it abscent to favor the stored sectors. It is easier to deploy the FIT >> +image with embedded static device tree to multiple boards. >> + >> +Macro CONFIG_SYS_SPL_ARGS_ADDR serves two purposes. One is the pointer to >> load >> +the stored sectors to. Normally this is the static device tree. The second >> +purpose is the memory location of signature header for secure boot. After >> the >> +FIT image is loaded into memory, it is validated against the signature >> header >> +before individual components are extracted (and optionally decompressed) >> into >> +their final memory locations, respectivelly. After the validation, the >> header >> +is no longer used. The static device tree is copied into this location. So >> +this macro is passed as the location of device tree when booting Linux. > > I've not yet go to this point -> Please look into below comments. > > I'm just curious - how can I specify the DTBs precedence? I mean how to > decide if one from FIT or from eMMC sector are used? By the order of loading ARGS first, then FIT. If you have static device tree in FIT image, it can overwrite the image loaded from ARGS. For my testing, I have verified FIT image without device tree in which case the device tree is loaded from ARGS. > > >> +components. Otherwise U-Boot cannot load them correctly. >> + >> +Generate FIT image with static device tree >>
Re: [U-Boot] u-boot-usb/master sandbox unit test failure
On 09/25/2017 06:13 PM, Stephen Warren wrote: > Marek, +CC Bin I will drop the xhci patchset and hope to get a fixed one from him. > The latest u-boot-usb master branch breaks the following unit tests for > the sandbox target (as run by test/py): > > 8 failed > ... test_ut[ut_dm_blk_usb] > ... test_ut[ut_dm_usb_flash] > ... test_ut[ut_dm_usb_keyb] > ... test_ut[ut_dm_usb_multi] > ... test_ut[ut_dm_usb_remove] > ... test_ut[ut_dm_usb_tree] > ... test_ut[ut_dm_usb_tree_remove] > ... test_ut[ut_dm_usb_tree_reorder] > > The first failure is: > >> => ut dm blk_usb >> Test: dm_test_blk_usb: blk.c >> USB0: scanning bus 1 for devices... usb_setup_descriptor: invalid >> max packet size >> failed, error -5 >> /var/lib/jenkins/workspace/u-boot-denx_uboot_usb-master-build/src/u-boot/test/dm/blk.c:78, >> dm_test_blk_usb(): 0 == uclass_get_device(UCLASS_MASS_STORAGE, 0, >> _dev): Expected 0, got -19 >> Test: dm_test_blk_usb: blk.c (flat tree) >> USB0: scanning bus 1 for devices... usb_setup_descriptor: invalid >> max packet size >> failed, error -5 >> /var/lib/jenkins/workspace/u-boot-denx_uboot_usb-master-build/src/u-boot/test/dm/blk.c:78, >> dm_test_blk_usb(): 0 == uclass_get_device(UCLASS_MASS_STORAGE, 0, >> _dev): Expected 0, got -19 >> Failures: 2 > > The others all look essentially the same. > > It looks like this was introduced sometime on Saturday (US time, > ignoring my Jenkins polling delay), and the two subsequent pushes on > Sunday and Monday didn't solve this. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: uniphier-sd: Add vqmmc regulator support
On 09/15/2017 09:10 PM, Marek Vasut wrote: > Add initial support for setting the vqmmc regulator. Since we do not > support 1V8 modes, set the regulator to 3V3 and enable it. > > Signed-off-by: Marek Vasut> Cc: Masahiro Yamada > Cc: Jaehoon Chung Anything ?! I don't see this in the PR ... > --- > drivers/mmc/uniphier-sd.c | 13 + > 1 file changed, 13 insertions(+) > > diff --git a/drivers/mmc/uniphier-sd.c b/drivers/mmc/uniphier-sd.c > index 3c52161067..0d1203cb76 100644 > --- a/drivers/mmc/uniphier-sd.c > +++ b/drivers/mmc/uniphier-sd.c > @@ -14,6 +14,7 @@ > #include > #include > #include > +#include > #include > > DECLARE_GLOBAL_DATA_PTR; > @@ -756,6 +757,9 @@ static int uniphier_sd_probe(struct udevice *dev) > fdt_addr_t base; > struct clk clk; > int ret; > +#ifdef CONFIG_DM_REGULATOR > + struct udevice *vqmmc_dev; > +#endif > > base = devfdt_get_addr(dev); > if (base == FDT_ADDR_T_NONE) > @@ -765,6 +769,15 @@ static int uniphier_sd_probe(struct udevice *dev) > if (!priv->regbase) > return -ENOMEM; > > +#ifdef CONFIG_DM_REGULATOR > + ret = device_get_supply_regulator(dev, "vqmmc-supply", _dev); > + if (!ret) { > + /* Set the regulator to 3.3V until we support 1.8V modes */ > + regulator_set_value(vqmmc_dev, 330); > + regulator_set_enable(vqmmc_dev, true); > + } > +#endif > + > ret = clk_get_by_index(dev, 0, ); > if (ret < 0) { > dev_err(dev, "failed to get host clock\n"); > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
The following changes since commit 1f6049e2501b5c35c61435dbc05ba96743202674: tools/mkimage: Make the path to the dtc binary that mkimage calls configurable (2017-09-24 07:33:03 -0400) are available in the git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to 0184c6fb34b49f0bb1ffc7b0e35a597de339353e: usb: dwc2: Align size of invalidating dcache before starting DMA (2017-09-24 18:45:56 +0200) Bin Meng (6): dm: usb: Add a new USB controller operation 'get_max_xfer_size' dm: usb: xhci: Implement get_max_xfer_size() operation dm: usb: ehci: Implement get_max_xfer_size() operation usb: storage: Refactor to use max_xfer_blk from struct us_data dm: usb: storage: Fix broken read/write when both EHCD and xHCD are enabled usb: kbd: Set a default polling mechanism for USB keyboard Eddie Cai (4): usb: rockchip: add the rockusb gadget usb: rockchip: add rockusb command rockchip:usb: add a simple readme for rockusb rockchip: rk3288: enable rockusb support on rk3288 based device Marek Vasut (1): usb: xhci: Set number of event segments and entries to 1 Philipp Tomsich (3): rockchip: xhci: Convert to livetree usb: dwc2: convert to livetree usb: host: ehci-generic: convert to livetree Seung-Woo Kim (1): usb: dwc2: Align size of invalidating dcache before starting DMA arch/arm/include/asm/arch-rockchip/f_rockusb.h | 132 + arch/arm/mach-rockchip/Kconfig | 2 + cmd/Kconfig| 9 ++ cmd/Makefile | 1 + cmd/rockusb.c | 74 ++ common/usb_storage.c | 64 ++--- configs/Cyrus_P5020_defconfig | 1 - configs/Cyrus_P5040_defconfig | 1 - configs/MPC8610HPCD_defconfig | 1 - configs/MPC8641HPCN_36BIT_defconfig| 1 - configs/MPC8641HPCN_defconfig | 1 - configs/apalis_imx6_defconfig | 1 - configs/apalis_imx6_nospl_com_defconfig| 1 - configs/apalis_imx6_nospl_it_defconfig | 1 - configs/chromebit_mickey_defconfig | 8 ++ configs/chromebook_jerry_defconfig | 8 ++ configs/chromebook_minnie_defconfig| 8 ++ configs/colibri_imx6_defconfig | 1 - configs/colibri_imx6_nospl_defconfig | 1 - configs/evb-rk3288_defconfig | 10 ++ configs/fennec-rk3288_defconfig| 6 + configs/firefly-rk3288_defconfig | 7 +- configs/miqi-rk3288_defconfig | 6 + configs/mx6cuboxi_defconfig| 1 - configs/phycore-rk3288_defconfig | 7 + configs/popmetal-rk3288_defconfig | 6 + configs/rock2_defconfig| 9 ++ configs/rpi_2_defconfig| 1 - configs/rpi_3_32b_defconfig| 1 - configs/rpi_3_defconfig| 1 - configs/rpi_defconfig | 1 - configs/sandbox_defconfig | 1 - configs/sandbox_flattree_defconfig | 1 - configs/sandbox_noblk_defconfig| 1 - configs/sandbox_spl_defconfig | 1 - configs/seaboard_defconfig | 1 - configs/tinker-rk3288_defconfig| 6 + configs/ventana_defconfig | 1 - doc/README.rockusb | 51 +++ drivers/usb/Kconfig| 2 +- drivers/usb/gadget/Kconfig | 8 ++ drivers/usb/gadget/Makefile| 1 + drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 3 +- drivers/usb/gadget/f_rockusb.c | 691 + drivers/usb/host/dwc2.c| 2 +- drivers/usb/host/ehci-generic.c| 2 +- drivers/usb/host/ehci-hcd.c| 12 ++ drivers/usb/host/usb-uclass.c | 11 ++ drivers/usb/host/xhci-rockchip.c | 4 +- drivers/usb/host/xhci.c| 15 ++ drivers/usb/host/xhci.h| 4 +- include/configs/rk3288_common.h| 12 ++ include/usb.h | 22 ++- 53 files changed, 1173 insertions(+), 51 deletions(-) create mode 100644 arch/arm/include/asm/arch-rockchip/f_rockusb.h create mode 100644 cmd/rockusb.c create mode 100644 doc/README.rockusb create mode 100644 drivers/usb/gadget/f_rockusb.c ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] u-boot-usb/master sandbox unit test failure
Marek, The latest u-boot-usb master branch breaks the following unit tests for the sandbox target (as run by test/py): 8 failed ... test_ut[ut_dm_blk_usb] ... test_ut[ut_dm_usb_flash] ... test_ut[ut_dm_usb_keyb] ... test_ut[ut_dm_usb_multi] ... test_ut[ut_dm_usb_remove] ... test_ut[ut_dm_usb_tree] ... test_ut[ut_dm_usb_tree_remove] ... test_ut[ut_dm_usb_tree_reorder] The first failure is: => ut dm blk_usb Test: dm_test_blk_usb: blk.c USB0: scanning bus 1 for devices... usb_setup_descriptor: invalid max packet size failed, error -5 /var/lib/jenkins/workspace/u-boot-denx_uboot_usb-master-build/src/u-boot/test/dm/blk.c:78, dm_test_blk_usb(): 0 == uclass_get_device(UCLASS_MASS_STORAGE, 0, _dev): Expected 0, got -19 Test: dm_test_blk_usb: blk.c (flat tree) USB0: scanning bus 1 for devices... usb_setup_descriptor: invalid max packet size failed, error -5 /var/lib/jenkins/workspace/u-boot-denx_uboot_usb-master-build/src/u-boot/test/dm/blk.c:78, dm_test_blk_usb(): 0 == uclass_get_device(UCLASS_MASS_STORAGE, 0, _dev): Expected 0, got -19 Failures: 2 The others all look essentially the same. It looks like this was introduced sometime on Saturday (US time, ignoring my Jenkins polling delay), and the two subsequent pushes on Sunday and Monday didn't solve this. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers: pci: imx: add imx_pcie_remove function
On Fri, Sep 22, 2017 at 7:00 AM, David Müller (ELSOFT AG)wrote: > Hello > > Does the code below really work? Hi Dave, This patch does work to resolve the issue stated in the commit log which was to fix failing to boot on a 4.11+ kernel which stems from the fact that we have no reliable way to reset the PCIe host controller for IMX6SDL/DQ. This code used to be in the kernel [1] but was removed in 4.11 because it was seen as a workaround for the bootloader failing to put the PCIe host controller back in a sane state (something normally not needed to be done if these hardware blocks have a reset available). However, your right you do end up hanging on a 'soft reset' likely for the same reason the kernel used to - the PCIe host controller is not left in a sane state because this code isn't run in that case. > > On my custom MX6Q board, the code hangs on the read of the > "PCIE_PL_PFLR". Please note that this code sequence is not entered the > first time after a power up; I have to execute a U-Boot reset to > actually trigger the hang. Any ideas what is going wrong? > > > While debugging it, I also noticed the two problems below. > > Tim Harvey wrote: > >> + if (is_mx6dq()) { >> + u32 val, gpr1, gpr12; >> + >> + gpr1 = readl(_regs->gpr[1]); >> + gpr12 = readl(_regs->gpr[12]); >> + if ((gpr1 & IOMUXC_GPR1_PCIE_REF_CLK_EN) && >> + (gpr12 & IOMUXC_GPR12_PCIE_CTL_2)) { > > This could be (gpr12 & IOMUXC_GPR12_APPS_LTSSM_ENABLE)) { Currently IOMUXC_GPR12_PCIE_CTL_2 is defined as GPR12[10] likely because that's how it was defined in an early reference manual but I would agree it should be changed for readability - its not a bug. > >> + val = readl(MX6_DBI_ADDR + PCIE_PL_PFLR); >> + val &= ~PCIE_PL_PFLR_LINK_STATE_MASK; >> + val |= PCIE_PL_PFLR_FORCE_LINK; >> + >> + imx_pcie_fix_dabt_handler(true); >> + writel(val, MX6_DBI_ADDR + PCIE_PL_PFLR); >> + imx_pcie_fix_dabt_handler(false); >> + >> + gpr12 &= ~IOMUXC_GPR12_PCIE_CTL_2; >> + writel(val, _regs->gpr[12]); > > I think this should be > writel(gpr12, _regs->gpr[12]); > > or even better > clrbits_le32(_regs->gpr[12], > IOMUXC_GPR12_APPS_LTSSM_ENABLE); Yes this is a bug for sure, however it doesn't appear to resolve your issue. Lucas, does barebox suffer from a hang on PCI init on chip-level reset and if not do you know what could be causing the read of PCIE_PL_PFLR to hang here? Regards, Tim [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/host/pci-imx6.c?h=v4.10#n270 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/7] armv8: layerscape: Eanble falcon boot
On 09/25/2017 04:17 PM, Łukasz Majewski wrote: Nit -- Eanble in subject . ^^ Enable Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/7] armv8: layerscape: Eanble falcon boot
Hi York, If you don't mind, I would like to ask you for some help and clarification regarding your work. Add jump_to_image_linux() for arm64. Add "noreturn" flag to armv8_switch_to_el2(). Add hooks to fsl-layerscape to enable falcon boot. I'm trying to do the same on imx6q board (armv7). Signed-off-by: York Sun--- Changes in v2: Relace getenv_f() with env_get_f() after rebasing to latet master. .../arm/cpu/armv8/fsl-layerscape/doc/README.falcon | 140 + arch/arm/cpu/armv8/fsl-layerscape/spl.c| 29 + arch/arm/include/asm/system.h | 2 +- arch/arm/lib/spl.c | 11 ++ 4 files changed, 181 insertions(+), 1 deletion(-) create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/doc/README.falcon diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.falcon b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.falcon new file mode 100644 index 000..282b19f --- /dev/null +++ b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.falcon @@ -0,0 +1,140 @@ +Falcon boot option +-- +Falcon boot is a short cut boot method for SD/eMMC targets. It skips loading the +RAM version U-Boot. Instead, it loads FIT image and boot directly to Linux. +CONFIG_SPL_OS_BOOT enables falcon boot. CONFIG_SPL_LOAD_FIT enables the FIT ^^ - this is a bit cumbersome, since it requires some stub for dtb creation (but this can be fixed for boards not yet supporting dts u-boot configuration). +image support (also need CONFIG_SPL_OF_LIBFDT, CONFIG_SPL_FIT and optionally +CONFIG_SPL_GZIP). + +To enable falcon boot, a hook function spl_start_uboot() returns 0 to indicate +booting U-Boot is not the first choice. The kernel FIT image needs to be put +at CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR. SPL mmc driver reads the header to +determine if this is a FIT image. If true, FIT image components are parsed and +copied or decompressed (if applicable) to their desitinations. If FIT image is +not found, normal U-Boot flow will follow. This part is similar to the one for old, venerable uImage. + +An important part of falcon boot is to prepare the device tree. A normal U-Boot +does FDT fixups when booting Linux. For falcon boot, Linux boots directly from +SPL, skipping the normal U-Boot. The device tree has to be prepared in advance. +A command "spl export" should be called under the normal RAM version U-Boot. +It is equivalent to go through "bootm" step-by-step until device tree fixup is +done. The device tree in memory is the one needed for falcon boot. Falcon boot +flow suggests to save this image to SD/eMMC at the location pointed by macro +CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR, with maximum size specified by macro +CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS. However, when FIT image is used for +Linux, the device tree stored in FIT image overwrites the memory loaded by spl +driver from these sectors. We could change this loading order to favor the +stored sectors. But when secure boot is enabled, these sectors are used for +signature header and needs to be loaded before the FIT image. So it is important +to understand the device tree in FIT image should be the one actually used, or +leave it abscent to favor the stored sectors. It is easier to deploy the FIT +image with embedded static device tree to multiple boards. + +Macro CONFIG_SYS_SPL_ARGS_ADDR serves two purposes. One is the pointer to load +the stored sectors to. Normally this is the static device tree. The second +purpose is the memory location of signature header for secure boot. After the +FIT image is loaded into memory, it is validated against the signature header +before individual components are extracted (and optionally decompressed) into +their final memory locations, respectivelly. After the validation, the header +is no longer used. The static device tree is copied into this location. So +this macro is passed as the location of device tree when booting Linux. I've not yet go to this point -> Please look into below comments. I'm just curious - how can I specify the DTBs precedence? I mean how to decide if one from FIT or from eMMC sector are used? +components. Otherwise U-Boot cannot load them correctly. + +Generate FIT image with static device tree +-- +Example: + +/dts-v1/; I'm trying to load fitImage (with kernel + 2 dtbs) from eMMC directly by SPL. The fitImage has been generated with OE-core recipe. The same results are with one generated with mkimage. + +/ { + description = "Image file for the LS1043A Linux Kernel"; + #address-cells = <1>; + + images { + kernel@1 { + description = "ARM64 Linux kernel"; + data = /incbin/("./arch/arm64/boot/Image.gz"); + type = "kernel"; + arch = "arm64"; + os = "linux"; +
Re: [U-Boot] [PATCH V4 11/12] imx: mx6sabresd: enable dm drivers
Hi Peng, On 30/08/2017 08:14, Peng Fan wrote: > Enable DM MMC/I2C/PMIC/GPIO/REGULATOR. > > Signed-off-by: Peng Fan> Cc: Fabio Estevam > Cc: Stefano Babic > --- > > V2->V4: none > > board/freescale/mx6sabresd/mx6sabresd.c | 326 > +--- > configs/mx6sabresd_defconfig| 15 ++ > include/configs/mx6sabresd.h| 15 +- > 3 files changed, 146 insertions(+), 210 deletions(-) > > diff --git a/board/freescale/mx6sabresd/mx6sabresd.c > b/board/freescale/mx6sabresd/mx6sabresd.c > index fa75ab0..2123a9d 100644 > --- a/board/freescale/mx6sabresd/mx6sabresd.c > +++ b/board/freescale/mx6sabresd/mx6sabresd.c > @@ -12,7 +12,6 @@ > #include > #include > #include > -#include > #include > #include > #include > @@ -24,7 +23,6 @@ > #include > #include > #include > -#include > #include > #include > #include "../common/pfuze.h" > @@ -46,14 +44,6 @@ DECLARE_GLOBAL_DATA_PTR; > #define SPI_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_SPEED_MED | \ > PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST) > > -#define I2C_PAD_CTRL (PAD_CTL_PUS_100K_UP | \ > - PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \ > - PAD_CTL_ODE | PAD_CTL_SRE_FAST) > - > -#define I2C_PMIC 1 > - > -#define I2C_PAD MUX_PAD_CTRL(I2C_PAD_CTRL) > - > #define DISP0_PWR_EN IMX_GPIO_NR(1, 21) > > #define KEY_VOL_UP IMX_GPIO_NR(1, 4) > @@ -93,6 +83,7 @@ static void setup_iomux_enet(void) > { > SETUP_IOMUX_PADS(enet_pads); > > + gpio_request(IMX_GPIO_NR(1, 25), "phy_rst"); > /* Reset AR8031 PHY */ > gpio_direction_output(IMX_GPIO_NR(1, 25) , 0); > mdelay(10); > @@ -100,47 +91,6 @@ static void setup_iomux_enet(void) > udelay(100); > } > > -static iomux_v3_cfg_t const usdhc2_pads[] = { > - IOMUX_PADS(PAD_SD2_CLK__SD2_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_SD2_CMD__SD2_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_SD2_DAT0__SD2_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_SD2_DAT1__SD2_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_SD2_DAT2__SD2_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_SD2_DAT3__SD2_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_NANDF_D4__SD2_DATA4 | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_NANDF_D5__SD2_DATA5 | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_NANDF_D6__SD2_DATA6 | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_NANDF_D7__SD2_DATA7 | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_NANDF_D2__GPIO2_IO02 | MUX_PAD_CTRL(NO_PAD_CTRL)), > /* CD */ > -}; > - > -static iomux_v3_cfg_t const usdhc3_pads[] = { > - IOMUX_PADS(PAD_SD3_CLK__SD3_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_SD3_CMD__SD3_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_SD3_DAT0__SD3_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_SD3_DAT1__SD3_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_SD3_DAT2__SD3_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_SD3_DAT3__SD3_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_SD3_DAT4__SD3_DATA4 | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_SD3_DAT5__SD3_DATA5 | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_SD3_DAT6__SD3_DATA6 | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_SD3_DAT7__SD3_DATA7 | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_NANDF_D0__GPIO2_IO00| MUX_PAD_CTRL(NO_PAD_CTRL)), /* > CD */ > -}; > - > -static iomux_v3_cfg_t const usdhc4_pads[] = { > - IOMUX_PADS(PAD_SD4_CLK__SD4_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_SD4_CMD__SD4_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_SD4_DAT0__SD4_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_SD4_DAT1__SD4_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_SD4_DAT2__SD4_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_SD4_DAT3__SD4_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_SD4_DAT4__SD4_DATA4 | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_SD4_DAT5__SD4_DATA5 | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_SD4_DAT6__SD4_DATA6 | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > - IOMUX_PADS(PAD_SD4_DAT7__SD4_DATA7 | MUX_PAD_CTRL(USDHC_PAD_CTRL)), > -}; > - > static iomux_v3_cfg_t const ecspi1_pads[] = { > IOMUX_PADS(PAD_KEY_COL0__ECSPI1_SCLK | MUX_PAD_CTRL(SPI_PAD_CTRL)), > IOMUX_PADS(PAD_KEY_COL1__ECSPI1_MISO | MUX_PAD_CTRL(SPI_PAD_CTRL)), > @@ -187,6 +137,7 @@ static iomux_v3_cfg_t const bl_pads[] = { > static void enable_backlight(void) > { > SETUP_IOMUX_PADS(bl_pads); > + gpio_request(DISP0_PWR_EN, "disp0_pwr_en"); > gpio_direction_output(DISP0_PWR_EN, 1); > } > > @@ -201,32 +152,6 @@ static void enable_lvds(struct
Re: [U-Boot] [PATCH V4 01/12] scripts: spl: fix typo
On 30/08/2017 08:14, Peng Fan wrote: > Typo fix: CONIFG->CONFIG > > Signed-off-by: Peng Fan> Cc: Tom Rini > --- > > V2: new > V3: none > V4: none > > scripts/Makefile.uncmd_spl | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/scripts/Makefile.uncmd_spl b/scripts/Makefile.uncmd_spl > index 15d0836..b399411 100644 > --- a/scripts/Makefile.uncmd_spl > +++ b/scripts/Makefile.uncmd_spl > @@ -9,7 +9,7 @@ ifdef CONFIG_SPL_BUILD > ifndef CONFIG_SPL_DM > CONFIG_DM_SERIAL= > CONFIG_DM_GPIO= > -CONIFG_DM_I2C= > +CONFIG_DM_I2C= > CONFIG_DM_SPI= > CONFIG_DM_SPI_FLASH= > endif > Applied to u-boot-imx, -master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] apalis_imx6: Avoid calling setup_display() from SPL code
On 24/09/2017 13:27, Max Krummenacher wrote: > Hi > > > I propose to drop my patches in favor of Fabio's solution. > > Agree, I will merge them. Regards, Stefano > Reviewed-by: Max Krummenacher> > > Max > > > *Von:* Anatolij Gustschin > *Gesendet:* Samstag, 23. September 2017 21:06:57 > *An:* Stefano Babic > *Cc:* Fabio Estevam; u-boot@lists.denx.de; Max Krummenacher; Fabio Estevam > *Betreff:* Re: [PATCH 5/6] apalis_imx6: Avoid calling setup_display() > from SPL code > > Hi Stefano, > > On Sat, 23 Sep 2017 10:43:55 +0200 > Stefano Babic sba...@denx.de wrote: > ... >> Max has already fixed apalis / colibri, see for example >> http://patchwork.ozlabs.org/patch/817053/. I will apply Max's patches >> and drop 5/6 from your series. Anyway, thanks for having thought to >> these two boards, too. > > I would prefer patch from Fabio, so I applied all them to a build test > branch and building with [1] passed now. There is a pull request for them. > > Thanks, > Anatolij > > [1] http://patchwork.ozlabs.org/patch/806755 -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] apalis_imx6: Avoid calling setup_display() from SPL code
Hi Fabio, On 23/09/2017 17:11, Fabio Estevam wrote: > On Sat, Sep 23, 2017 at 10:01 AM, Fabio Estevamwrote: >> Hi Stefano, >> >> On Sat, Sep 23, 2017 at 5:43 AM, Stefano Babic wrote: >> >>> Max has already fixed apalis / colibri, see for example >>> http://patchwork.ozlabs.org/patch/817053/. I will apply Max's patches >>> and drop 5/6 from your series. Anyway, thanks for having thought to >>> these two boards, too. >> >> Yes, I saw Max's patches too. When I tried the same approach on >> cgtqmx6eval I got build failures: >> >> board/congatec/cgtqmx6eval/built-in.o: In function `setup_display': >> /home/fabio/u-boot-imx/board/congatec/cgtqmx6eval/cgtqmx6eval.c:632: >> undefined reference to `enable_ipu_clock' >> /home/fabio/u-boot-imx/board/congatec/cgtqmx6eval/cgtqmx6eval.c:633: >> undefined reference to `imx_setup_hdmi' >> >> It is true that Max's patches fix the warnings for Toradex boards, but >> if in future someone rework the IPU code like it is done in >> cgtqmx6eval, then failure would happen. >> >> So I thought that a more robust solution was to simply prevent making >> explicit calls to setup_display() from SPL like I did here. >> >> This also has the benefit to have the same solution across several mx6 >> boards. > > One more advantage of my proposal is that it does not rely on adding > logic to include/configs/. You're right, I agree. > > This is particularly important when someone moves the IPU related > config symbols into Kconfig. > +1 Best regards, Stefano -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/5] arm: dts: da850: Migrate da850-evm DTS files from Linux 4.13-RC5
On Sep 25, 2017 3:11 AM, "Jagan Teki"wrote: On Mon, Sep 18, 2017 at 7:13 AM, Adam Ford wrote: > A few small additional items are needed to support DM_SPI and > DM_SERIAL, so those were added to da850-evm-u-boot.dtsi > > Signed-off-by: Adam Ford > --- > V4: Re-sync with latest master > V3: New to series. I forgot to generate this before. This is required before > The rest of the files in the series. > diff --git a/arch/arm/dts/da850-evm-u-boot.dtsi b/arch/arm/dts/da850-evm-u-boot.dtsi > new file mode 100644 > index 000..5cca47d > --- /dev/null > +++ b/arch/arm/dts/da850-evm-u-boot.dtsi > @@ -0,0 +1,22 @@ > +/* > + * da850-evm U-Boot Additions > + * > + * Copyright (C) 2017 Logic PD, Inc. > + * Copyright (C) Adam Ford > + * > + * SPDX-License-Identifier:GPL-2.0+ > + */ > + > +/ { > + chosen { > + stdout-path = > + }; > + > + aliases { > + spi0 = > + }; > +}; > + > + { > + compatible = "m25p64", "spi-flash"; > +}; So, re-updating compatible to match with 'spi-flash' ? Yes. I was having difficulty recognizing the spi-flash without it. I wasn't happy about it, but it worked. I am away from my computer for the next week, so I am unable to try anything else for now. Adam 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 https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] u-boot Boot issue about rk3188
Am Montag, 25. September 2017, 19:49:01 CEST schrieb Andy Yan: > Hi Heiko: > > On 2017年09月25日 18:29, Heiko Stübner wrote: > > Hi Andy, > > > > Am Montag, 25. September 2017, 17:45:03 CEST schrieb Andy Yan: > >> On 2017年09月22日 13:56, Heiko Stuebner wrote: > >>> Am Freitag, 22. September 2017, 08:50:49 CEST schrieb Andy Yan: > Hi Heiko: > > On 2017年09月22日 08:24, Andy Yan wrote: > > Hi Heiko: > > > > On 2017年09月21日 22:55, Heiko Stübner wrote: > >> Hi Andy, > >> > >> Am Donnerstag, 21. September 2017, 22:03:32 CEST schrieb Andy Yan: > >>> Hi Heiko: > >>> I try to boot the upstream u-boot-rockchip branch on my rk3188 > >>> board > >>> with(rock_defconfig) > >>> > >>> But I got this error: > >>> early_init() > >>> nit_and_scan() returned error -22 > >>> early_init() failed: -22 > >>> ERROR ### Please RESET the board ### > >>> > >>> the current commit head is: 782088d("rockchip: imply ADC and > >>> SARADC_ROCKCHIP > >>> on supported SoCs") Do you ever meet something like this? > >> > >> that is very strange. When testing Philipp's branch, I was also > >> testing the > >> commit you mention to see if anything broke since I last changed > >> u-boot > >> on my radxa rock. And the above commit started just fine, when > >> starting > >> from an sd-card. > >> > >> Not sure from which medium you're starting though. But from what I > >> remember Pawel got nand working in his rk3066 series, but that is not > >> yet merged. > >> > > I boot from emmc, I will go on hack on it. > > > I finally can boot it with the rock_defconfig. But the way to > > package the tpl spl u-boot a little different. > > cat ${DIR}/out/tpl/u-boot-tpl.bin > tplspl.bin > truncate -s 1020 tplspl.bin > > sed -i "/^/{1s/^/RK31/}" tplspl.bin > cat ${DIR}/out/spl/u-boot-spl.bin > spl.bin > truncate -s %2048 spl.bin > cat spl.bin >> tplspl.bin > > Then the tplspl.bin + u-boot.bin should package by > > boot_merger(tplsplb.in for FLashData, u-boot.bin for FlashBoot) from > > rockchip downstream u-boot repo: > ./tools/boot_merger ./tools/rk_tools/RKBOOT/RK310BMINIALL.ini > > download to emmc by "upgrade_tool ul" command. According to our > > bootrom code author, the rk31(maybe include rk30) bootrom has a > limitation that the idbblock > couldn't accessed by upgrade_tool wl command. > >>> > >>> I do have a script handling that [0]. At least for the sd-card variant > >>> a simple "openssl rc4" works just as well as the legacy boot_merger :-) > >>> > >>> Heiko > >>> > >>> [0] > >>> https://github.com/mmind/u-boot-rockchip/commit/81458bde873d6cf588e082cc > >>> f > >>> 556e818f46ad9df > >>> > >> Is there a way to download the out that generated by[0] to > >> > >> emmc/flash? It seems that the upgrate_tool can't access 0x40 of the > >> emmc/nand on rk3188. > > > > you have the @rock-chips.com address, so I'd guess you might even have > > the better resources to find out ;-) . > > Actually, as I mail last week, I can download the image packaged by > boot_merge (with ddr bin from rockchip as 471 and rk30usbplug as 472, > tplspl as Flashdata u-boot.bing as Flashboot) to nand/emmc. > > When you mentioned your scripts, I though you have a better way. Sadly not really, as I'm just using a sd-card in rk3188, I normally just dd the image to the card and everything works then. > > In any case, as I said I haven't looked at all at the internal storage on > > my radxarock so far. > > > > But as the rk3066 and rk3188 are so similar I've added Paweł. > > > > @Paweł: you had uboot starting from nand on your rk3066 board, maybe you > > could describe how you wrote it to the board so maybe Andy can check if > > he needs to adapt anything? > > > > > > Thanks > > Heiko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] u-boot Boot issue about rk3188
Hi Heiko: On 2017年09月25日 18:29, Heiko Stübner wrote: Hi Andy, Am Montag, 25. September 2017, 17:45:03 CEST schrieb Andy Yan: On 2017年09月22日 13:56, Heiko Stuebner wrote: Am Freitag, 22. September 2017, 08:50:49 CEST schrieb Andy Yan: Hi Heiko: On 2017年09月22日 08:24, Andy Yan wrote: Hi Heiko: On 2017年09月21日 22:55, Heiko Stübner wrote: Hi Andy, Am Donnerstag, 21. September 2017, 22:03:32 CEST schrieb Andy Yan: Hi Heiko: I try to boot the upstream u-boot-rockchip branch on my rk3188 board with(rock_defconfig) But I got this error: early_init() nit_and_scan() returned error -22 early_init() failed: -22 ERROR ### Please RESET the board ### the current commit head is: 782088d("rockchip: imply ADC and SARADC_ROCKCHIP on supported SoCs") Do you ever meet something like this? that is very strange. When testing Philipp's branch, I was also testing the commit you mention to see if anything broke since I last changed u-boot on my radxa rock. And the above commit started just fine, when starting from an sd-card. Not sure from which medium you're starting though. But from what I remember Pawel got nand working in his rk3066 series, but that is not yet merged. I boot from emmc, I will go on hack on it. I finally can boot it with the rock_defconfig. But the way to package the tpl spl u-boot a little different. cat ${DIR}/out/tpl/u-boot-tpl.bin > tplspl.bin truncate -s 1020 tplspl.bin sed -i "/^/{1s/^/RK31/}" tplspl.bin cat ${DIR}/out/spl/u-boot-spl.bin > spl.bin truncate -s %2048 spl.bin cat spl.bin >> tplspl.bin Then the tplspl.bin + u-boot.bin should package by boot_merger(tplsplb.in for FLashData, u-boot.bin for FlashBoot) from rockchip downstream u-boot repo: ./tools/boot_merger ./tools/rk_tools/RKBOOT/RK310BMINIALL.ini download to emmc by "upgrade_tool ul" command. According to our bootrom code author, the rk31(maybe include rk30) bootrom has a limitation that the idbblock couldn't accessed by upgrade_tool wl command. I do have a script handling that [0]. At least for the sd-card variant a simple "openssl rc4" works just as well as the legacy boot_merger :-) Heiko [0] https://github.com/mmind/u-boot-rockchip/commit/81458bde873d6cf588e082ccf 556e818f46ad9df Is there a way to download the out that generated by[0] to emmc/flash? It seems that the upgrate_tool can't access 0x40 of the emmc/nand on rk3188. you have the @rock-chips.com address, so I'd guess you might even have the better resources to find out ;-) . Actually, as I mail last week, I can download the image packaged by boot_merge (with ddr bin from rockchip as 471 and rk30usbplug as 472, tplspl as Flashdata u-boot.bing as Flashboot) to nand/emmc. When you mentioned your scripts, I though you have a better way. In any case, as I said I haven't looked at all at the internal storage on my radxarock so far. But as the rk3066 and rk3188 are so similar I've added Paweł. @Paweł: you had uboot starting from nand on your rk3066 board, maybe you could describe how you wrote it to the board so maybe Andy can check if he needs to adapt anything? Thanks Heiko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sf: bar: Clean BA24 Bank Address Register bit after read/write/erase operation
Hi Jagan, On Wed, Sep 13, 2017 at 3:09 PM, Lukasz Majewskiwrote: The content of Bank Address Register (BAR) is volatile. It is cleared after power cycle or reset command (RESET F0h). Some memories (like e.g. s25fl256s) use it to access memory larger than 0x100 (16 MiB). The problem shows up when one: 1. Reads/writes/erases memory > 16 MiB 2. Calls "reset" u-boot command (which is not causing BAR to be cleared) In the above scenario, the SoC ROM sends 0x00 address to read SPL. Unfortunately, the BA24 bit is still set and hence it receives content from 0x100 memory address. As a result the SoC aborts and we hang. Only power cycle can take the SoC out of this state. How to reproduce/test: sf probe; sf erase 0x120 0x80; reset sf probe; sf erase 0x120 0x80; sf write 0x1100 0x120 0x80; reset sf probe; sf read 0x1100 0x120 0x80; reset Signed-off-by: Lukasz Majewski --- drivers/mtd/spi/spi_flash.c | 33 + 1 file changed, 33 insertions(+) diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c index 34f6888..d19d64a 100644 --- a/drivers/mtd/spi/spi_flash.c +++ b/drivers/mtd/spi/spi_flash.c @@ -113,6 +113,27 @@ static int write_cr(struct spi_flash *flash, u8 wc) #endif #ifdef CONFIG_SPI_FLASH_BAR +/* + * This "cleanup" is necessary in a situation when one was accessing + * spi flash memory > 16 MiB by using Bank Address Register's BA24 bit. + * + * After it the BA24 bit shall be cleared to allow access to correct + * memory region after SW reset (by calling "reset" command). + * + * Otherwise, the BA24 bit may be left set and then after reset, the + * ROM would seek for SPL from 0x100, not 0x0. This need to change, SPL will look 16 MiB * bank_sel Ok. I will update the description. + */ +static int cleanup_bar(struct spi_flash *flash) what about clear_bar? Ok. I will change the name. thanks! -- Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/5] arm: dts: da850: Migrate da850-evm DTS files from Linux 4.13-RC5
On Mon, Sep 18, 2017 at 7:13 AM, Adam Fordwrote: > A few small additional items are needed to support DM_SPI and > DM_SERIAL, so those were added to da850-evm-u-boot.dtsi > > Signed-off-by: Adam Ford > --- > V4: Re-sync with latest master > V3: New to series. I forgot to generate this before. This is required before > The rest of the files in the series. > diff --git a/arch/arm/dts/da850-evm-u-boot.dtsi > b/arch/arm/dts/da850-evm-u-boot.dtsi > new file mode 100644 > index 000..5cca47d > --- /dev/null > +++ b/arch/arm/dts/da850-evm-u-boot.dtsi > @@ -0,0 +1,22 @@ > +/* > + * da850-evm U-Boot Additions > + * > + * Copyright (C) 2017 Logic PD, Inc. > + * Copyright (C) Adam Ford > + * > + * SPDX-License-Identifier:GPL-2.0+ > + */ > + > +/ { > + chosen { > + stdout-path = > + }; > + > + aliases { > + spi0 = > + }; > +}; > + > + { > + compatible = "m25p64", "spi-flash"; > +}; So, re-updating compatible to match with 'spi-flash' ? 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 https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] SPL: SPI: sunxi: add SPL FIT image support
On Fri, Sep 22, 2017 at 09:57:22PM +, Andre Przywara wrote: > The sunxi-specific SPI load routine only knows how to load a legacy > U-Boot image. > Teach it how to handle FIT images as well, simply by providing the > existing SPL FIT loader with the right loader routine to access the SPI > NOR flash. > > Signed-off-by: Andre Przywara> Reported-by: Peter Kosa Acked-by: Maxime Ripard Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com 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] sf: bar: Clean BA24 Bank Address Register bit after read/write/erase operation
On Wed, Sep 13, 2017 at 3:09 PM, Lukasz Majewskiwrote: > The content of Bank Address Register (BAR) is volatile. It is cleared > after power cycle or reset command (RESET F0h). > > Some memories (like e.g. s25fl256s) use it to access memory larger than > 0x100 (16 MiB). > > The problem shows up when one: > > 1. Reads/writes/erases memory > 16 MiB > 2. Calls "reset" u-boot command (which is not causing BAR to be cleared) > > In the above scenario, the SoC ROM sends 0x00 address to read SPL. > Unfortunately, the BA24 bit is still set and hence it receives content > from 0x100 memory address. > As a result the SoC aborts and we hang. Only power cycle can take the > SoC out of this state. > > How to reproduce/test: > > sf probe; sf erase 0x120 0x80; reset > sf probe; sf erase 0x120 0x80; sf write 0x1100 0x120 > 0x80; reset > sf probe; sf read 0x1100 0x120 0x80; reset > > Signed-off-by: Lukasz Majewski > --- > drivers/mtd/spi/spi_flash.c | 33 + > 1 file changed, 33 insertions(+) > > diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c > index 34f6888..d19d64a 100644 > --- a/drivers/mtd/spi/spi_flash.c > +++ b/drivers/mtd/spi/spi_flash.c > @@ -113,6 +113,27 @@ static int write_cr(struct spi_flash *flash, u8 wc) > #endif > > #ifdef CONFIG_SPI_FLASH_BAR > +/* > + * This "cleanup" is necessary in a situation when one was accessing > + * spi flash memory > 16 MiB by using Bank Address Register's BA24 bit. > + * > + * After it the BA24 bit shall be cleared to allow access to correct > + * memory region after SW reset (by calling "reset" command). > + * > + * Otherwise, the BA24 bit may be left set and then after reset, the > + * ROM would seek for SPL from 0x100, not 0x0. This need to change, SPL will look 16 MiB * bank_sel > + */ > +static int cleanup_bar(struct spi_flash *flash) what about clear_bar? 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 https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 15/19] arm: socfpga: Add support to memory allocation in SPL
On 09/25/2017 10:40 AM, tien.fong.c...@intel.com wrote: > From: Tien Fong Chee> > Add support to memory allocation in SPL for preparation to enable FAT > in SPL. Memory allocation is needed by FAT to work properly. > > Signed-off-by: Tien Fong Chee Gen 5 does have malloc support in SPL, so what's the deal here ? > --- > include/configs/socfpga_common.h | 23 ++- > 1 file changed, 22 insertions(+), 1 deletion(-) > > diff --git a/include/configs/socfpga_common.h > b/include/configs/socfpga_common.h > index 7549ee8..9b6719e 100644 > --- a/include/configs/socfpga_common.h > +++ b/include/configs/socfpga_common.h > @@ -280,17 +280,34 @@ unsigned int cm_get_qspi_controller_clk_hz(void); > /* > * SPL > * > - * SRAM Memory layout: > + * SRAM Memory layout for gen 5: > * > * 0x_ .. Start of SRAM > * 0x_ .. Top of stack (grows down) > * 0x_ .. Malloc area > * 0x_ .. Global Data > * 0x_FF00 .. End of SRAM > + * > + * SRAM Memory layout for Arria 10: > + * 0xFFE0_ .. Start of SRAM (bottom) > + * 0xFFEx_ .. Top of stack (grows down to bottom) > + * 0xFFEy_ .. Malloc area (grows up to top) > + * 0xFFEz_ .. Global Data > + * 0xFFE3_ .. End of SRAM (top) > */ > #define CONFIG_SPL_FRAMEWORK > #define CONFIG_SPL_TEXT_BASE CONFIG_SYS_INIT_RAM_ADDR > #define CONFIG_SPL_MAX_SIZE CONFIG_SYS_INIT_RAM_SIZE > +#if defined(CONFIG_TARGET_SOCFPGA_ARRIA10) > +/* SPL memory allocation configuration, it is required by FAT feature */ > +#ifndef CONFIG_SYS_SPL_MALLOC_START > +#define CONFIG_SYS_SPL_MALLOC_SIZE 0x2000 > +#define CONFIG_SYS_SPL_MALLOC_START (CONFIG_SYS_INIT_RAM_SIZE - \ > + GENERATED_GBL_DATA_SIZE - \ > + CONFIG_SYS_SPL_MALLOC_SIZE + \ > + CONFIG_SYS_INIT_RAM_ADDR) > +#endif > +#endif > > /* SPL SDMMC boot support */ > #ifdef CONFIG_SPL_MMC_SUPPORT > @@ -320,7 +337,11 @@ unsigned int cm_get_qspi_controller_clk_hz(void); > /* > * Stack setup > */ > +#if defined(CONFIG_TARGET_SOCFPGA_GEN5) > #define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR > +#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10) > +#define CONFIG_SPL_STACK (CONFIG_SYS_SPL_MALLOC_START - 1) > +#endif > > /* Extra Environment */ > #ifndef CONFIG_SPL_BUILD > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 17/19] arm: socfpga: Adding clock frequency info for U-boot
On 09/25/2017 10:40 AM, tien.fong.c...@intel.com wrote: > From: Tien Fong Chee> > Clock frequency info is required in U-boot. > > Signed-off-by: Tien Fong Chee I want a TB on Gen 5 > --- > arch/arm/mach-socfpga/board.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/arch/arm/mach-socfpga/board.c b/arch/arm/mach-socfpga/board.c > index 965f9dc..a00f63b 100644 > --- a/arch/arm/mach-socfpga/board.c > +++ b/arch/arm/mach-socfpga/board.c > @@ -8,7 +8,10 @@ > > #include > #include > +#include > #include > +#include > +#include > #include > > #include > @@ -26,6 +29,9 @@ int board_init(void) > /* Address of boot parameters for ATAG (if ATAG is used) */ > gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100; > > + /* configuring the clock based on handoff */ > + cm_basic_init(gd->fdt_blob); > + > return 0; > } > > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 19/19] arm: socfpga: Enable SPL loading U-boot to DDR and booting U-boot
On 09/25/2017 10:40 AM, tien.fong.c...@intel.com wrote: > From: Tien Fong Chee> > Enable SPL loading U-boot from SDMMC to DDR and booting U-boot. This patch seems to be doing more than just one thing ... > Signed-off-by: Tien Fong Chee > --- > arch/arm/mach-socfpga/spl.c | 55 + > common/spl/spl_mmc.c | 2 +- > configs/socfpga_arria10_defconfig | 57 > ++- > include/spl.h | 2 ++ > 4 files changed, 108 insertions(+), 8 deletions(-) > > diff --git a/arch/arm/mach-socfpga/spl.c b/arch/arm/mach-socfpga/spl.c > index aba116d..9b381bb 100644 > --- a/arch/arm/mach-socfpga/spl.c > +++ b/arch/arm/mach-socfpga/spl.c > @@ -15,6 +15,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -22,6 +23,10 @@ > #include > #include > #include > +#include > +#include > +#include > +#include > #include > #if defined(CONFIG_TARGET_SOCFPGA_ARRIA10) > #include > @@ -29,6 +34,9 @@ > > DECLARE_GLOBAL_DATA_PTR; > > +#define BSIZE4096 > +#define PERIPH_RBF 0 > + > #if defined(CONFIG_TARGET_SOCFPGA_GEN5) > static struct pl310_regs *const pl310 = > (struct pl310_regs *)CONFIG_SYS_PL310_BASE; > @@ -197,6 +205,12 @@ void board_init_f(ulong dummy) > #elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10) > void spl_board_init(void) > { > + int rval = 0; > + int len = 0; > + u32 buffer[BSIZE] __aligned(ARCH_DMA_MINALIGN); > + struct spl_boot_device bootdev; > + fpga_fs_info fpga_fsinfo; > + > /* configuring the clock based on handoff */ > cm_basic_init(gd->fdt_blob); > WATCHDOG_RESET(); > @@ -214,6 +228,47 @@ void spl_board_init(void) > > /* Add device descriptor to FPGA device table */ > socfpga_fpga_add(); > + > + bootdev.boot_device = spl_boot_device(); > + > + if (BOOT_DEVICE_MMC1 == bootdev.boot_device) { > + struct mmc *mmc = NULL; > + int err = 0; > + > + spl_mmc_find_device(, bootdev.boot_device); > + > + err = mmc_init(mmc); > + > + if (err) { > +#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT > + printf("spl: mmc init failed with error: %d\n", err); > +#endif > + } > + > + fpga_fsinfo.dev_part = (char *)get_cff_devpart(gd->fdt_blob, > + ); > + > + fpga_fsinfo.filename = (char *)get_cff_filename(gd->fdt_blob, > + , > + PERIPH_RBF); > + > + fpga_fsinfo.interface = "mmc"; > + > + fpga_fsinfo.fstype = FS_TYPE_FAT; > + } else { > + printf("Invalid boot device!\n"); > + return; > + } > + > + /* Program peripheral RBF */ > + if (fpga_fsinfo.filename && fpga_fsinfo.dev_part && (len > 0)) > + rval = fpga_fsload(0, buffer, BSIZE, _fsinfo); > + > + if (rval > 0) { > + config_pins(gd->fdt_blob, "shared"); > + > + ddr_calibration_sequence(); > + } > } > > void board_init_f(ulong dummy) > diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c > index b26..159443f 100644 > --- a/common/spl/spl_mmc.c > +++ b/common/spl/spl_mmc.c > @@ -113,7 +113,7 @@ static int spl_mmc_get_device_index(u32 boot_device) > return -ENODEV; > } > > -static int spl_mmc_find_device(struct mmc **mmcp, u32 boot_device) > +int spl_mmc_find_device(struct mmc **mmcp, u32 boot_device) > { > #if CONFIG_IS_ENABLED(DM_MMC) > struct udevice *dev; > diff --git a/configs/socfpga_arria10_defconfig > b/configs/socfpga_arria10_defconfig > index 4c73d73..2ff9801 100644 > --- a/configs/socfpga_arria10_defconfig > +++ b/configs/socfpga_arria10_defconfig > @@ -2,33 +2,76 @@ CONFIG_ARM=y > CONFIG_ARCH_SOCFPGA=y > CONFIG_SYS_MALLOC_F_LEN=0x2000 > CONFIG_TARGET_SOCFPGA_ARRIA10_SOCDK=y > +CONFIG_SPL_STACK_R_ADDR=0x0080 > CONFIG_IDENT_STRING="socfpga_arria10" > CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc" > -CONFIG_USE_BOOTARGS=y > -CONFIG_BOOTARGS="console=ttyS0,115200" > CONFIG_DEFAULT_FDT_FILE="socfpga_arria10_socdk_sdmmc.dtb" > +CONFIG_FIT=y > +CONFIG_SYS_CONSOLE_IS_IN_ENV=y > +CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y > +CONFIG_SYS_CONSOLE_ENV_OVERWRITE=y > +CONFIG_SPL_ENV_SUPPORT=y > +CONFIG_VERSION_VARIABLE=y > CONFIG_SPL=y > +CONFIG_HUSH_PARSER=y > CONFIG_SPL_FPGA_SUPPORT=y > +CONFIG_SPL_FAT_SUPPORT=y > +CONFIG_FS_FAT_MAX_CLUSTSIZE=32768 > CONFIG_CMD_BOOTZ=y > # CONFIG_CMD_IMLS is not set > CONFIG_CMD_ASKENV=y > CONFIG_CMD_GREPENV=y > # CONFIG_CMD_FLASH is not set > -CONFIG_CMD_GPIO=y > +CONFIG_SPL_LIBDISK_SUPPORT=y > +CONFIG_CMD_PART=y > CONFIG_CMD_MMC=y > +CONFIG_CMD_SF=y > +CONFIG_CMD_SPI=y > +CONFIG_CMD_I2C=y > +CONFIG_SYS_I2C_DW=y >
Re: [U-Boot] [PATCH] drivers: pci: imx: add imx_pcie_remove function
On 09/25/2017 11:05 AM, David Müller (ELSOFT AG) wrote: > Marek Vasut wrote: > >> On 09/22/2017 04:00 PM, David Müller (ELSOFT AG) wrote: >>> On my custom MX6Q board, the code hangs on the read of the >>> "PCIE_PL_PFLR". Please note that this code sequence is not entered >>> the first time after a power up; I have to execute a U-Boot reset >>> to actually trigger the hang. Any ideas what is going wrong? >> >> MX6Q PCIe reset breakage strikes again ? > > I thought this piece of code was added as work-around to fix the "MX6Q > PCIe reset" problem. Or are you talking about something different? That's exactly what I'm talking about ... -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/19] fs: Enable generic filesystems interface support in SPL.
On 09/25/2017 10:40 AM, tien.fong.c...@intel.com wrote: > From: Tien Fong Chee> > Enable generic filesystem interface drivers(fs.c and fat/) build > for SPL. This would allow generic filesystem being used in SPL. > > Signed-off-by: Tien Fong Chee +CC Simon, I'd like a RB on this one. > --- > common/spl/Kconfig | 8 > doc/README.SPL | 1 + > fs/Makefile| 1 + > 3 files changed, 10 insertions(+) > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig > index 9446cd9..5f4bd92 100644 > --- a/common/spl/Kconfig > +++ b/common/spl/Kconfig > @@ -304,6 +304,14 @@ config SPL_ETH_SUPPORT > is required since the network stack uses a number of environment > variables. See also SPL_NET_SUPPORT. > > +config SPL_FS_GENERIC > + bool "Support Generic filesystems interface driver" > + help > + Enable support for generic filesystems interface with SPL. This > + permits U-Boot (or Linux in Falcon mode) to be loaded from a generic > + filesystem from within SPL. Support for the underlying block > + device (e.g. MMC or USB) must be enabled separately. > + > config SPL_EXT_SUPPORT > bool "Support EXT filesystems" > help > diff --git a/doc/README.SPL b/doc/README.SPL > index 3ba313c..32628a4 100644 > --- a/doc/README.SPL > +++ b/doc/README.SPL > @@ -55,6 +55,7 @@ CONFIG_SPL_SPI_FLASH_SUPPORT > (drivers/mtd/spi/libspi_flash.o) > CONFIG_SPL_SPI_SUPPORT (drivers/spi/libspi.o) > CONFIG_SPL_FAT_SUPPORT (fs/fat/libfat.o) > CONFIG_SPL_EXT_SUPPORT > +CONFIG_SPL_FS_GENERIC (fs/fs.o fat/) > CONFIG_SPL_LIBGENERIC_SUPPORT (lib/libgeneric.o) > CONFIG_SPL_POWER_SUPPORT (drivers/power/libpower.o) > CONFIG_SPL_NAND_SUPPORT (drivers/mtd/nand/libnand.o) > diff --git a/fs/Makefile b/fs/Makefile > index 5770f41..fdacac8 100644 > --- a/fs/Makefile > +++ b/fs/Makefile > @@ -7,6 +7,7 @@ > # > > ifdef CONFIG_SPL_BUILD > +obj-$(CONFIG_SPL_FS_GENERIC) += fs.o fat/ > obj-$(CONFIG_SPL_FAT_SUPPORT) += fat/ > obj-$(CONFIG_SPL_EXT_SUPPORT) += ext4/ > else > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 14/19] arm: socfpga: Enable build for DDR Arria 10
On 09/25/2017 10:40 AM, tien.fong.c...@intel.com wrote: > From: Tien Fong Chee> > This patch is for enabling the DDR support on Arria 10. > > Signed-off-by: Tien Fong Chee > --- > drivers/ddr/altera/Makefile | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/ddr/altera/Makefile b/drivers/ddr/altera/Makefile > index ac4ab85..02f8b7c 100644 > --- a/drivers/ddr/altera/Makefile > +++ b/drivers/ddr/altera/Makefile > @@ -10,4 +10,5 @@ > > ifdef CONFIG_ALTERA_SDRAM > obj-$(CONFIG_TARGET_SOCFPGA_GEN5) += sdram_gen5.o sequencer.o > +obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += sdram_arria10.o > endif > This should be part of the patch which added the sdram_arria10.c -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 16/19] arm: socfpga: Enhance Intel SoCFPGA program header to support Arria 10
On 09/25/2017 10:40 AM, tien.fong.c...@intel.com wrote: > From: Tien Fong Chee> > Enhance preloader header with both additional program length and program > entry offset attributes, which offset is relative to the start of program > header. > > Signed-off-by: Tien Fong Chee > --- > arch/arm/mach-socfpga/include/mach/boot0.h | 11 +-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/mach-socfpga/include/mach/boot0.h > b/arch/arm/mach-socfpga/include/mach/boot0.h > index 22d9e7f..33c9368 100644 > --- a/arch/arm/mach-socfpga/include/mach/boot0.h > +++ b/arch/arm/mach-socfpga/include/mach/boot0.h > @@ -11,8 +11,15 @@ > .balignl 64,0xf33db33f; > > .word 0x1337c0d3; /* SoCFPGA preloader validation word */ > - .word 0xc01df00d; /* Version, flags, length */ > - .word 0xcafec0d3; /* Checksum, zero-pad */ > + .word 0xc01df00d; /* Header length(2B),flags(1B),version(1B) */ > +#ifndef CONFIG_TARGET_SOCFPGA_GEN5 > + .word 0xfeedface; /* Program length(4B) */ Keep this indent intact, then it won't generate these crappy - entries. > + .word 0xf00dcafe; /* > + * Program entry offset(4B),relative to > + * the start of program header > + */ > +#endif > + .word 0xcafec0d3; /* Simple checksum(2B),spare offset(2B) */ > nop; > > b reset;/* SoCFPGA jumps here */ > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 05/19] arm: socfpga: Enhance FPGA program write rbf data with size >= 4 bytes
On 09/25/2017 10:40 AM, tien.fong.c...@intel.com wrote: > From: Tien Fong Chee> > Existing FPGA program write is always assume RBF data >= 32 bytes, so > any rbf data less than 32 bytes writing to FPGA would be failed. > This patch enhances the FPGA program write to support rbf data with > size >= 4 bytes. > > Signed-off-by: Tien Fong Chee Applied, thanks > --- > drivers/fpga/socfpga.c | 14 -- > 1 file changed, 8 insertions(+), 6 deletions(-) > > diff --git a/drivers/fpga/socfpga.c b/drivers/fpga/socfpga.c > index 28fa16b..6e14ebd 100644 > --- a/drivers/fpga/socfpga.c > +++ b/drivers/fpga/socfpga.c > @@ -1,5 +1,5 @@ > /* > - * Copyright (C) 2012 Altera Corporation > + * Copyright (C) 2012-2017 Altera Corporation > * All rights reserved. > * > * SPDX-License-Identifier: BSD-3-Clause > @@ -55,18 +55,20 @@ void fpgamgr_program_write(const void *rbf_data, size_t > rbf_size) > uint32_t loops4 = DIV_ROUND_UP(rbf_size % 32, 4); > > asm volatile( > + " cmp %2, #0\n" > + " beq 2f\n" > "1: ldmia %0!,{r0-r7}\n" > " stmia %1!,{r0-r7}\n" > " sub %1, #32\n" > " subs%2, #1\n" > " bne 1b\n" > - " cmp %3, #0\n" > - " beq 3f\n" > - "2: ldr %2, [%0], #4\n" > + "2: cmp %3, #0\n" > + " beq 4f\n" > + "3: ldr %2, [%0], #4\n" > " str %2, [%1]\n" > " subs%3, #1\n" > - " bne 2b\n" > - "3: nop\n" > + " bne 3b\n" > + "4: nop\n" > : "+r"(src), "+r"(dst), "+r"(loops32), "+r"(loops4) : > : "r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7", "cc"); > } > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 12/19] arm: socfpga: Add DDR driver for Arria 10
On 09/25/2017 10:40 AM, tien.fong.c...@intel.com wrote: > From: Tien Fong Chee> > Add DDR driver suppport for Arria 10. > > Signed-off-by: Tien Fong Chee > --- > arch/arm/mach-socfpga/include/mach/sdram.h | 2 + > arch/arm/mach-socfpga/include/mach/sdram_arria10.h | 103 ++- > drivers/ddr/altera/sdram_arria10.c | 735 > + > 3 files changed, 839 insertions(+), 1 deletion(-) > create mode 100644 drivers/ddr/altera/sdram_arria10.c > > diff --git a/arch/arm/mach-socfpga/include/mach/sdram.h > b/arch/arm/mach-socfpga/include/mach/sdram.h > index 4a9754e..b833fc2 100644 > --- a/arch/arm/mach-socfpga/include/mach/sdram.h > +++ b/arch/arm/mach-socfpga/include/mach/sdram.h > @@ -10,6 +10,8 @@ > > #if defined(CONFIG_TARGET_SOCFPGA_GEN5) > #include > +#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10) > +#include > #endif > > #endif > diff --git a/arch/arm/mach-socfpga/include/mach/sdram_arria10.h > b/arch/arm/mach-socfpga/include/mach/sdram_arria10.h > index 1d7b7c1..7af9431 100644 > --- a/arch/arm/mach-socfpga/include/mach/sdram_arria10.h > +++ b/arch/arm/mach-socfpga/include/mach/sdram_arria10.h > @@ -1,5 +1,5 @@ > /* > - * Copyright (C) 2015-2017 Intel Corporation > + * Copyright (C) 2017 Intel Corporation > * > * SPDX-License-Identifier: GPL-2.0 > */ > @@ -8,6 +8,7 @@ > #define _SOCFPGA_SDRAM_ARRIA10_H_ > > #ifndef __ASSEMBLY__ > +int ddr_calibration_sequence(void); > > struct socfpga_ecc_hmc { > u32 ip_rev_id; > @@ -204,6 +205,106 @@ struct socfpga_io48_mmr { > u32 niosreserve1; > u32 niosreserve2; > }; > + > +union dramaddrw_reg { > + struct { > + u32 cfg_col_addr_width:5; > + u32 cfg_row_addr_width:5; > + u32 cfg_bank_addr_width:4; > + u32 cfg_bank_group_addr_width:2; > + u32 cfg_cs_addr_width:3; > + u32 reserved:13; > + }; Use regular macros for bitfields, not this crap. > + u32 word; > +}; > + > +union ctrlcfg0_reg { > + struct { > + u32 cfg_mem_type:4; > + u32 cfg_dimm_type:3; > + u32 cfg_ac_pos:2; > + u32 cfg_ctrl_burst_len:5; > + u32 reserved:18; /* Other fields unused */ > + }; > + u32 word; > +}; [...] > diff --git a/drivers/ddr/altera/sdram_arria10.c > b/drivers/ddr/altera/sdram_arria10.c > new file mode 100644 > index 000..f22a726 > --- /dev/null > +++ b/drivers/ddr/altera/sdram_arria10.c > @@ -0,0 +1,735 @@ > +/* > + * Copyright (C) 2017 Intel Corporation > + * > + * SPDX-License-Identifier:GPL-2.0 > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include Why does an SDRAM init driver need access to ns16550 UART , MMC and NAND ? > +#include > +#include > +#include > +#include > +#include > + > +DECLARE_GLOBAL_DATA_PTR; > + > +static void sdram_mmr_init(void); > +static unsigned long long sdram_size_calc(void); > + > +/* FAWBANK - Number of Bank of a given device involved in the FAW period. */ > +#define ARRIA10_SDR_ACTIVATE_FAWBANK (0x1) > + > +#define ARRIA_DDR_CONFIG(A, B, C, R) ((A<<24)|(B<<16)|(C<<8)|R) Missing parenthesis around (A), (B) etc. ... > +#define DDR_CONFIG_ELEMENTS (sizeof(ddr_config)/sizeof(u32)) So this is ARRAY_SIZE() ? > +#define DDR_REG_SEQ2CORE0xFFD0507C > +#define DDR_REG_CORE2SEQ0xFFD05078 > +#define DDR_READ_LATENCY_DELAY 40 > +#define DDR_SIZE_2GB_HEX 0x8000 > +#define DDR_MAX_TRIES0x0010 > + > +#define IO48_MMR_DRAMSTS 0xFFCFA0EC > +#define IO48_MMR_NIOS2_RESERVE0 0xFFCFA110 > +#define IO48_MMR_NIOS2_RESERVE1 0xFFCFA114 > +#define IO48_MMR_NIOS2_RESERVE2 0xFFCFA118 > + > +#define SEQ2CORE_MASK0xF > +#define CORE2SEQ_INT_REQ 0xF > +#define SEQ2CORE_INT_RESP_BIT3 > + > +static const struct socfpga_ecc_hmc *socfpga_ecc_hmc_base = > + (void *)SOCFPGA_SDR_ADDRESS; > +static const struct socfpga_noc_ddr_scheduler > *socfpga_noc_ddr_scheduler_base = > + (void *)SOCFPGA_SDR_SCHEDULER_ADDRESS; > +static const struct socfpga_noc_fw_ddr_mpu_fpga2sdram > + *socfpga_noc_fw_ddr_mpu_fpga2sdram_base = > + (void *)SOCFPGA_SDR_FIREWALL_MPU_FPGA_ADDRESS; > +static const struct socfpga_noc_fw_ddr_l3 *socfpga_noc_fw_ddr_l3_base = > + (void *)SOCFPGA_SDR_FIREWALL_L3_ADDRESS; > +static const struct socfpga_io48_mmr *socfpga_io48_mmr_base = > + (void *)SOCFPGA_HMC_MMR_IO48_ADDRESS; > + > +/* The followring are the supported configurations */ > +static u32 ddr_config[] = { > + /* Chip - Row - Bank - Column Style */ > + /* All Types */ > + ARRIA_DDR_CONFIG(0, 3, 10, 12), > + ARRIA_DDR_CONFIG(0, 3, 10, 13), > + ARRIA_DDR_CONFIG(0, 3, 10, 14), > + ARRIA_DDR_CONFIG(0, 3, 10, 15), > + ARRIA_DDR_CONFIG(0, 3, 10, 16), > +
Re: [U-Boot] [PATCH v2 11/19] arm: socfpga: Add DRAM bank size initialization function
On 09/25/2017 10:40 AM, tien.fong.c...@intel.com wrote: > From: Tien Fong Chee> > Add function for both multiple DRAM bank and single DRAM bank size > initialization. This common functionality could be used by every single > SOCFPGA board. > > Signed-off-by: Tien Fong Chee I'd like TB on Gen5. > --- > arch/arm/mach-socfpga/board.c| 7 +++ > include/configs/socfpga_common.h | 1 + > 2 files changed, 8 insertions(+) > > diff --git a/arch/arm/mach-socfpga/board.c b/arch/arm/mach-socfpga/board.c > index a41d089..965f9dc 100644 > --- a/arch/arm/mach-socfpga/board.c > +++ b/arch/arm/mach-socfpga/board.c > @@ -29,6 +29,13 @@ int board_init(void) > return 0; > } > > +int dram_init_banksize(void) > +{ > + fdtdec_setup_memory_banksize(); > + > + return 0; > +} > + > #ifdef CONFIG_USB_GADGET > struct dwc2_plat_otg_data socfpga_otg_data = { > .usb_gusbcfg= 0x1417, > diff --git a/include/configs/socfpga_common.h > b/include/configs/socfpga_common.h > index eadce2d..7549ee8 100644 > --- a/include/configs/socfpga_common.h > +++ b/include/configs/socfpga_common.h > @@ -47,6 +47,7 @@ > (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET) > > #define CONFIG_SYS_SDRAM_BASEPHYS_SDRAM_1 > +#define CONFIG_SYS_SDRAM_SIZEPHYS_SDRAM_1_SIZE > #ifdef CONFIG_SOCFPGA_VIRTUAL_TARGET > #define CONFIG_SYS_TEXT_BASE 0x0840 > #else > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/19] arm: socfpga: Add drivers for programing FPGA from flash
On 09/25/2017 10:40 AM, tien.fong.c...@intel.com wrote: > From: Tien Fong Chee> > These drivers handle FPGA program operation from flash loading > RBF to memory and then to program FPGA. > > Signed-off-by: Tien Fong Chee Did you run checkpatch on this before submitting ? I presume no ... > --- > .../include/mach/fpga_manager_arria10.h| 27 ++ > drivers/fpga/socfpga_arria10.c | 391 > - > include/altera.h | 6 + > include/configs/socfpga_common.h | 4 + > 4 files changed, 425 insertions(+), 3 deletions(-) [...] > @@ -112,13 +122,14 @@ static int wait_for_nconfig_pin_and_nstatus_pin(void) > unsigned long mask = ALT_FPGAMGR_IMGCFG_STAT_F2S_NCONFIG_PIN_SET_MSK | > ALT_FPGAMGR_IMGCFG_STAT_F2S_NSTATUS_PIN_SET_MSK; > > - /* Poll until f2s_nconfig_pin and f2s_nstatus_pin; loop until > de-asserted, > - * timeout at 1000ms > + /* > + * Poll until f2s_nconfig_pin and f2s_nstatus_pin; loop until > + * de-asserted, timeout at 1000ms >*/ > return wait_for_bit(__func__, > _manager_base->imgcfg_stat, > mask, > - false, FPGA_TIMEOUT_MSEC, false); > + true, FPGA_TIMEOUT_MSEC, false); > } Seems more like a fix, split this out. > static int wait_for_f2s_nstatus_pin(unsigned long value) > @@ -469,6 +480,7 @@ int socfpga_load(Altera_desc *desc, const void *rbf_data, > size_t rbf_size) > > /* Initialize the FPGA Manager */ > status = fpgamgr_program_init((u32 *)rbf_data, rbf_size); > + > if (status) > return status; > > @@ -477,3 +489,376 @@ int socfpga_load(Altera_desc *desc, const void > *rbf_data, size_t rbf_size) > > return fpgamgr_program_finish(); > } > + > +#if defined(CONFIG_CMD_FPGA_LOADFS) > +const char *get_cff_filename(const void *fdt, int *len, u32 core) > +{ > + const char *cff_filename = NULL; > + const char *cell; > + int nodeoffset; > + nodeoffset = fdtdec_next_compatible(fdt, 0, > + COMPAT_ALTERA_SOCFPGA_FPGA0); > + > + if (nodeoffset >= 0) { > + if (core) > + cell = fdt_getprop(fdt, > + nodeoffset, > + "bitstream_core", > + len); > + else > + cell = fdt_getprop(fdt, nodeoffset, "bitstream_periph", > + len); > + > + if (cell) > + cff_filename = cell; > + } > + > + return cff_filename; > +} > + > +const char *get_cff_devpart(const void *fdt, int *len) > +{ > + const char *cff_devpart = NULL; > + const char *cell; > + int nodeoffset; > + nodeoffset = fdtdec_next_compatible(fdt, 0, > + COMPAT_ALTERA_SOCFPGA_FPGA0); > + > + cell = fdt_getprop(fdt, nodeoffset, "bitstream_devpart", len); > + > + if (cell) > + cff_devpart = cell; > + > + return cff_devpart; > +} Take a look at splash*.c , I believe that can be reworked into generic firmware loader , which you could then use here. [...] > diff --git a/include/configs/socfpga_common.h > b/include/configs/socfpga_common.h > index 9897e11..eadce2d 100644 > --- a/include/configs/socfpga_common.h > +++ b/include/configs/socfpga_common.h > @@ -27,7 +27,11 @@ > */ > #define CONFIG_NR_DRAM_BANKS 1 > #define PHYS_SDRAM_1 0x0 > +#if defined(CONFIG_TARGET_SOCFPGA_GEN5) > #define CONFIG_SYS_MALLOC_LEN(64 * 1024 * 1024) > +#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10) > +#define CONFIG_SYS_MALLOC_LEN(128 * 1024 * 1024) > +#endif You definitely don't need 128 MiB of malloc area. > #define CONFIG_SYS_MEMTEST_START PHYS_SDRAM_1 > #define CONFIG_SYS_MEMTEST_END PHYS_SDRAM_1_SIZE > #if defined(CONFIG_TARGET_SOCFPGA_GEN5) > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/19] arm: socfpga: Rename the gen5 sdram driver to more specific name
On 09/25/2017 10:40 AM, tien.fong.c...@intel.com wrote: > From: Tien Fong Chee> > Current sdram driver is only applied to gen5 device, hence it is better > to rename sdram driver to more specific name which is related to gen5 > device. > > Signed-off-by: Tien Fong Chee > --- > arch/arm/mach-socfpga/include/mach/sdram.h | 434 > + > .../include/mach/{sdram.h => sdram_gen5.h} | 6 +- > drivers/ddr/altera/Makefile| 2 +- > drivers/ddr/altera/{sdram.c => sdram_gen5.c} | 0 > 4 files changed, 8 insertions(+), 434 deletions(-) > copy arch/arm/mach-socfpga/include/mach/{sdram.h => sdram_gen5.h} (99%) > rename drivers/ddr/altera/{sdram.c => sdram_gen5.c} (100%) > > diff --git a/arch/arm/mach-socfpga/include/mach/sdram.h > b/arch/arm/mach-socfpga/include/mach/sdram.h > index b11228f..4a9754e 100644 > --- a/arch/arm/mach-socfpga/include/mach/sdram.h > +++ b/arch/arm/mach-socfpga/include/mach/sdram.h > @@ -1,5 +1,5 @@ > /* > - * Copyright Altera Corporation (C) 2014-2015 > + * Copyright (C) 2017 Intel Corporation Retain the old copyright ? > * > * SPDX-License-Identifier: GPL-2.0+ > */ > @@ -8,435 +8,9 @@ > > #ifndef __ASSEMBLY__ What's with this massive deletion here ? > -unsigned long sdram_calculate_size(void); > -int sdram_mmr_init_full(unsigned int sdr_phy_reg); > -int sdram_calibration_full(void); > - > -const struct socfpga_sdram_config *socfpga_get_sdram_config(void); > - > -void socfpga_get_seq_ac_init(const u32 **init, unsigned int *nelem); > -void socfpga_get_seq_inst_init(const u32 **init, unsigned int *nelem); > -const struct socfpga_sdram_rw_mgr_config > *socfpga_get_sdram_rwmgr_config(void); [...] -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 07/19] fdt: Add compatible strings for Arria 10
On 09/25/2017 10:40 AM, tien.fong.c...@intel.com wrote: > From: Tien Fong Chee> > Add compatible strings for Intel Arria 10 SoCFPGA device. > > Signed-off-by: Tien Fong Chee Applied, thanks > --- > include/fdtdec.h | 2 ++ > lib/fdtdec.c | 2 ++ > 2 files changed, 4 insertions(+) > > diff --git a/include/fdtdec.h b/include/fdtdec.h > index 4a0947c..095ff36 100644 > --- a/include/fdtdec.h > +++ b/include/fdtdec.h > @@ -157,6 +157,8 @@ enum fdt_compat_id { > COMPAT_ALTERA_SOCFPGA_F2SDR0, /* SoCFPGA fpga2SDRAM0 bridge */ > COMPAT_ALTERA_SOCFPGA_F2SDR1, /* SoCFPGA fpga2SDRAM1 bridge */ > COMPAT_ALTERA_SOCFPGA_F2SDR2, /* SoCFPGA fpga2SDRAM2 bridge */ > + COMPAT_ALTERA_SOCFPGA_FPGA0,/* SOCFPGA FPGA manager */ > + COMPAT_ALTERA_SOCFPGA_NOC, /* SOCFPGA Arria 10 NOC */ > > COMPAT_COUNT, > }; > diff --git a/lib/fdtdec.c b/lib/fdtdec.c > index 107a892..03ff75e 100644 > --- a/lib/fdtdec.c > +++ b/lib/fdtdec.c > @@ -70,6 +70,8 @@ static const char * const compat_names[COMPAT_COUNT] = { > COMPAT(ALTERA_SOCFPGA_F2SDR0, "altr,socfpga-fpga2sdram0-bridge"), > COMPAT(ALTERA_SOCFPGA_F2SDR1, "altr,socfpga-fpga2sdram1-bridge"), > COMPAT(ALTERA_SOCFPGA_F2SDR2, "altr,socfpga-fpga2sdram2-bridge"), > + COMPAT(ALTERA_SOCFPGA_FPGA0, "altr,socfpga-a10-fpga-mgr"), > + COMPAT(ALTERA_SOCFPGA_NOC, "altr,socfpga-a10-noc"), > }; > > const char *fdtdec_get_compatible(enum fdt_compat_id id) > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/19] doc: dtbinding: Description on FPGA RBF properties at Arria 10 FPGA manager
On 09/25/2017 10:39 AM, tien.fong.c...@intel.com wrote: > From: Tien Fong Chee> > This patch adds description on properties about location of FPGA RBFs are > stored, type and functionality of RBF used to configure FPGA. > > Signed-off-by: Tien Fong Chee > --- > doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt | 11 > +++ > 1 file changed, 11 insertions(+) > > diff --git a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt > b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt > index 2fd8e7a..7abb746 100644 > --- a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt > +++ b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt > @@ -7,6 +7,14 @@ Required properties: > - The second index is for writing FPGA configuration data. > - resets : Phandle and reset specifier for the device's reset. > - clocks : Clocks used by the device. > +- bitstream_periph : FPGA peripheral raw binary file which is used to > + initialize FPGA IOs, PLL, IO48 and DDR. > +- bitstream_core : FPGA core raw binary file contains FPGA design which is > used > + to program FPGA CRAM and ERAM. > +- bitstream_devpart : Partition of flash device where bitstream files are > +stored. > + - dev is flash device number, part is > flash > + device partition. > > Example: > > @@ -16,4 +24,7 @@ Example: > 0xffcfe400 0x20>; > clocks = <_mp_clk>; > resets = < FPGAMGR_RESET>; > + bitstream_periph = "ghrd_10as066n2.periph.rbf.mkimage"; > + bitstream_core = "ghrd_10as066n2.core.rbf.mkimage"; > + bitstream_devpart = "0:1"; These should probably be altr,something-something ... they are definitely not generic bindings > }; > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/19] arm: socfpga: Add Arria 10 SoCFPGA programming interface
On 09/25/2017 10:40 AM, tien.fong.c...@intel.com wrote: > From: Tien Fong Chee> > Add code necessary into the FPGA driver framework in U-Boot > so it can be used via the 'fpga' command for programing Arria 10 > SoCFPGA. > > Signed-off-by: Tien Fong Chee > --- [...] > +#if defined(CONFIG_CMD_FPGA_LOADFS) > +int altera_loadfs(Altera_desc *desc, const void *buf, size_t bsize, > +fpga_fs_info *fpga_fsinfo) > +{ > + const struct altera_fpga *fpga = altera_desc_to_fpga(desc, __func__); > + > + if (!fpga) > + return FPGA_FAIL; > + > + debug_cond(FPGA_DEBUG, "%s: Launching the %s FS Loader...\n", > +__func__, fpga->name); > + if (fpga->loadfs) > + return fpga->loadfs(desc, buf, bsize, fpga_fsinfo); > + return 0; return -EINVAL , since the loader could not be started ? > +} > +#endif [...] -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/19] doc: dtbinding: Description on FPGA RBF properties at Arria 10 FPGA manager
On 09/25/2017 10:39 AM, tien.fong.c...@intel.com wrote: > From: Tien Fong Chee> > This patch adds description on properties about location of FPGA RBFs are > stored, type and functionality of RBF used to configure FPGA. > > Signed-off-by: Tien Fong Chee Why does this patch have different tags than 1/19 ? Please keep things consistent ... > --- > doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt | 11 > +++ > 1 file changed, 11 insertions(+) > > diff --git a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt > b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt > index 2fd8e7a..7abb746 100644 > --- a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt > +++ b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt > @@ -7,6 +7,14 @@ Required properties: > - The second index is for writing FPGA configuration data. > - resets : Phandle and reset specifier for the device's reset. > - clocks : Clocks used by the device. > +- bitstream_periph : FPGA peripheral raw binary file which is used to > + initialize FPGA IOs, PLL, IO48 and DDR. > +- bitstream_core : FPGA core raw binary file contains FPGA design which is > used > + to program FPGA CRAM and ERAM. > +- bitstream_devpart : Partition of flash device where bitstream files are > +stored. > + - dev is flash device number, part is > flash > + device partition. > > Example: > > @@ -16,4 +24,7 @@ Example: > 0xffcfe400 0x20>; > clocks = <_mp_clk>; > resets = < FPGAMGR_RESET>; > + bitstream_periph = "ghrd_10as066n2.periph.rbf.mkimage"; > + bitstream_core = "ghrd_10as066n2.core.rbf.mkimage"; > + bitstream_devpart = "0:1"; > }; > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/19] ARM: socfpga: add bindings doc for arria10 fpga manager
On 09/25/2017 10:39 AM, tien.fong.c...@intel.com wrote: > From: Tien Fong Chee> > This DT binding doc is porting from Linux DT binding doc. > commit 1adcbea4201a6852362aa5ece573f1f169b28113 > > Add a device tree bindings document for the SoCFPGA Arria10 > FPGA Manager driver. > > Signed-off-by: Alan Tull > Acked-by: Rob Herring > Acked-By: Moritz Fischer > Signed-off-by: Rob Herring > Signed-off-by: Tien Fong Chee Applied, thanks > --- > .../fpga/altera-socfpga-a10-fpga-mgr.txt | 19 > +++ > 1 file changed, 19 insertions(+) > create mode 100644 > doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt > > diff --git a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt > b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt > new file mode 100644 > index 000..2fd8e7a > --- /dev/null > +++ b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt > @@ -0,0 +1,19 @@ > +Altera SOCFPGA Arria10 FPGA Manager > + > +Required properties: > +- compatible : should contain "altr,socfpga-a10-fpga-mgr" > +- reg: base address and size for memory mapped io. > + - The first index is for FPGA manager register access. > + - The second index is for writing FPGA configuration data. > +- resets : Phandle and reset specifier for the device's reset. > +- clocks : Clocks used by the device. > + > +Example: > + > + fpga_mgr: fpga-mgr@ffd03000 { > + compatible = "altr,socfpga-a10-fpga-mgr"; > + reg = <0xffd03000 0x100 > +0xffcfe400 0x20>; > + clocks = <_mp_clk>; > + resets = < FPGAMGR_RESET>; > + }; > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] u-boot Boot issue about rk3188
Hi Heiko: On 2017年09月22日 13:56, Heiko Stuebner wrote: Am Freitag, 22. September 2017, 08:50:49 CEST schrieb Andy Yan: Hi Heiko: On 2017年09月22日 08:24, Andy Yan wrote: Hi Heiko: On 2017年09月21日 22:55, Heiko Stübner wrote: Hi Andy, Am Donnerstag, 21. September 2017, 22:03:32 CEST schrieb Andy Yan: Hi Heiko: I try to boot the upstream u-boot-rockchip branch on my rk3188 board with(rock_defconfig) But I got this error: early_init() nit_and_scan() returned error -22 early_init() failed: -22 ERROR ### Please RESET the board ### the current commit head is: 782088d("rockchip: imply ADC and SARADC_ROCKCHIP on supported SoCs") Do you ever meet something like this? that is very strange. When testing Philipp's branch, I was also testing the commit you mention to see if anything broke since I last changed u-boot on my radxa rock. And the above commit started just fine, when starting from an sd-card. Not sure from which medium you're starting though. But from what I remember Pawel got nand working in his rk3066 series, but that is not yet merged. I boot from emmc, I will go on hack on it. I finally can boot it with the rock_defconfig. But the way to package the tpl spl u-boot a little different. cat ${DIR}/out/tpl/u-boot-tpl.bin > tplspl.bin truncate -s 1020 tplspl.bin sed -i "/^/{1s/^/RK31/}" tplspl.bin cat ${DIR}/out/spl/u-boot-spl.bin > spl.bin truncate -s %2048 spl.bin cat spl.bin >> tplspl.bin Then the tplspl.bin + u-boot.bin should package by boot_merger(tplsplb.in for FLashData, u-boot.bin for FlashBoot) from rockchip downstream u-boot repo: ./tools/boot_merger ./tools/rk_tools/RKBOOT/RK310BMINIALL.ini download to emmc by "upgrade_tool ul" command. According to our bootrom code author, the rk31(maybe include rk30) bootrom has a limitation that the idbblock couldn't accessed by upgrade_tool wl command. I do have a script handling that [0]. At least for the sd-card variant a simple "openssl rc4" works just as well as the legacy boot_merger :-) Heiko [0] https://github.com/mmind/u-boot-rockchip/commit/81458bde873d6cf588e082ccf556e818f46ad9df Is there a way to download the out that generated by[0] to emmc/flash? It seems that the upgrate_tool can't access 0x40 of the emmc/nand on rk3188. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 01/19] ARM: socfpga: add bindings doc for arria10 fpga manager
From: Tien Fong CheeThis DT binding doc is porting from Linux DT binding doc. commit 1adcbea4201a6852362aa5ece573f1f169b28113 Add a device tree bindings document for the SoCFPGA Arria10 FPGA Manager driver. Signed-off-by: Alan Tull Acked-by: Rob Herring Acked-By: Moritz Fischer Signed-off-by: Rob Herring Signed-off-by: Tien Fong Chee --- .../fpga/altera-socfpga-a10-fpga-mgr.txt | 19 +++ 1 file changed, 19 insertions(+) create mode 100644 doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt diff --git a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt new file mode 100644 index 000..2fd8e7a --- /dev/null +++ b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt @@ -0,0 +1,19 @@ +Altera SOCFPGA Arria10 FPGA Manager + +Required properties: +- compatible : should contain "altr,socfpga-a10-fpga-mgr" +- reg: base address and size for memory mapped io. + - The first index is for FPGA manager register access. + - The second index is for writing FPGA configuration data. +- resets : Phandle and reset specifier for the device's reset. +- clocks : Clocks used by the device. + +Example: + + fpga_mgr: fpga-mgr@ffd03000 { + compatible = "altr,socfpga-a10-fpga-mgr"; + reg = <0xffd03000 0x100 + 0xffcfe400 0x20>; + clocks = <_mp_clk>; + resets = < FPGAMGR_RESET>; + }; -- 2.2.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers: pci: imx: add imx_pcie_remove function
Marek Vasut wrote: > On 09/22/2017 04:00 PM, David Müller (ELSOFT AG) wrote: >> On my custom MX6Q board, the code hangs on the read of the >> "PCIE_PL_PFLR". Please note that this code sequence is not entered >> the first time after a power up; I have to execute a U-Boot reset >> to actually trigger the hang. Any ideas what is going wrong? > > MX6Q PCIe reset breakage strikes again ? I thought this piece of code was added as work-around to fix the "MX6Q PCIe reset" problem. Or are you talking about something different? Dave ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] tegra: fdt: create initial files and changes to support the tegra124 based nyan-kitty chromebase by acer
The intent of this patch is to create the initial files necessary to support the nyan-kitty device by copying nyan-big files and renaming all the nyan-big references and tags to be nyan-kitty. This will make a u-boot that will act exactly like the nyan-big build, except will say "nyan-kitty" where applicable. the problem with this is that nyan-kitty doesn't have a uart header on the board and the activated serial port will cause garbage input to u-boot and cause it to crash. I have done further work to disable the uart, but this will cause a build that locks up before display since the input, output, error ,macro will specify a serial device to use that doesn't exist. This requires some reworking of the macro to get it to work without a serial device. also since there is no keyboard built in to the device, usb keyboard needs to be enabled to allow input. I do not include these changes mentioned in this paragraph in these patches. +++ /home/ben/tegra/uboot/new/u-boot-initial/arch/arm/dts/tegra124-nyan-kitty.dts 2017-08-22 23:24:27.864516000 -0400 +/dts-v1/; + +#include "tegra124-nyan.dtsi" + +/ { +model = "Acer Chromebase DC221HQ"; +compatible = "google,nyan-kitty", "google,nyan", "nvidia,tegra124"; + +aliases { +console = +i2c0 = "/i2c@7000d000"; +i2c1 = "/i2c@7000c000"; +i2c2 = "/i2c@7000c400"; +i2c3 = "/i2c@7000c500"; +i2c4 = "/i2c@7000c700"; +i2c5 = "/i2c@7000d100"; +rtc0 = "/i2c@7000d000/pmic@40"; +rtc1 = "/rtc@7000e000"; +mmc0 = "/sdhci@700b0600"; +mmc1 = "/sdhci@700b0400"; +spi0 = "/spi@7000d400"; +spi1 = "/spi@7000da00"; +usb0 = "/usb@7d00"; +usb1 = "/usb@7d008000"; +usb2 = "/usb@7d004000"; +}; + +chosen { +stdout-path = +}; + +host1x@5000 { +dc@5420 { +display-timings { +timing@0 { +clock-frequency = <6950>; +hactive = <1366>; +vactive = <768>; +hsync-len = <32>; +hfront-porch = <48>; +hback-porch = <20>; +vfront-porch = <3>; +vback-porch = <13>; +vsync-len = <6>; +}; +}; +}; + +dc@5424 { +status = "disabled"; +}; + +}; + +panel: panel { +compatible = "auo,b133xtn01"; + +backlight = <>; +ddc-i2c-bus = <>; +}; + +sdhci@700b0400 { /* SD Card on this bus */ +wp-gpios = < TEGRA_GPIO(Q, 4) GPIO_ACTIVE_LOW>; +}; + +sound { +compatible = "nvidia,tegra-audio-max98090-nyan-kitty", + "nvidia,tegra-audio-max98090-nyan", + "nvidia,tegra-audio-max98090"; +nvidia,model = "GoogleNyanKitty"; +}; + + +pinmux@7868 { +pinctrl-names = "default"; +pinctrl-0 = <_default>; + +pinmux_default: common { +clk_32k_out_pa0 { +nvidia,pins = "clk_32k_out_pa0"; +nvidia,pull = ; +nvidia,tristate = ; +nvidia,enable-input = ; +}; +uart3_cts_n_pa1 { +nvidia,pins = "uart3_cts_n_pa1"; +nvidia,function = "gmi"; +nvidia,pull = ; +nvidia,tristate = ; +nvidia,enable-input = ; +}; +dap2_fs_pa2 { +nvidia,pins = "dap2_fs_pa2"; +nvidia,function = "i2s1"; +nvidia,pull = ; +nvidia,tristate = ; +nvidia,enable-input = ; +}; +dap2_sclk_pa3 { +nvidia,pins = "dap2_sclk_pa3"; +nvidia,function = "i2s1"; +nvidia,pull = ; +nvidia,tristate = ; +nvidia,enable-input = ; +}; +dap2_din_pa4 { +nvidia,pins = "dap2_din_pa4"; +nvidia,function = "i2s1"; +nvidia,pull = ; +nvidia,tristate = ; +nvidia,enable-input = ; +}; +dap2_dout_pa5 { +nvidia,pins = "dap2_dout_pa5"; +nvidia,function = "i2s1"; +nvidia,pull = ; +nvidia,tristate = ; +nvidia,enable-input = ; +}; +sdmmc3_clk_pa6 { +nvidia,pins = "sdmmc3_clk_pa6"; +nvidia,function = "sdmmc3"; +nvidia,pull = ; +nvidia,tristate = ; +nvidia,enable-input = ; +}; +sdmmc3_cmd_pa7 { +nvidia,pins = "sdmmc3_cmd_pa7"; +nvidia,function = "sdmmc3"; +nvidia,pull = ; +nvidia,tristate = ; +nvidia,enable-input = ; +}; +
Re: [U-Boot] [PATCH v3 0/6] rockchip: back-to-bootrom: replace assembly-implementation with C-code
Andy, Excellent news. Looks like Heiko and I figured out what breaks the series last week (i.e. the SPL corrupts the TPL’s stack—so my chaining will break things). I’ll resubmit without the chained returns later and then we can have a final test tomorrow. Regards, Philipp. > On 25 Sep 2017, at 10:46, Andy Yanwrote: > > Hi Philipp, Heiko: > > > I finally got the upstream u-boot run on a rk3188 board which can be attached > by DS5 debugger, > > if you have some registers info want to check, please let me know. > > > On 2017年09月21日 18:44, Heiko Stübner wrote: >> Am Donnerstag, 21. September 2017, 12:25:17 CEST schrieb Dr. Philipp Tomsich: On 21 Sep 2017, at 11:44, Heiko Stuebner wrote: Am Donnerstag, 21. September 2017, 11:09:49 CEST schrieb Heiko Stuebner: > Am Donnerstag, 21. September 2017, 10:19:23 CEST schrieb Philipp Tomsich: >> Recent discussions confirmed (what the code always assumed): the >> Rockchip BROM always enters U-Boot with the stack-pointer valid >> (i.e. the U-Boot startup code is running off the BROM stack). >> >> We can thus replace the back-to-bootrom code (i.e. both the >> save_boot_params and back_to_bootrom implementations) using C-code >> based on setjmp/longjmp. The new implementation is already structured >> to allow an easy drop-in of Andy's changes to enter download-mode when >> returning to the BROM. >> >> This turned out to require a some tweaking to system.h (making sure >> that the prototype for save_boot_params_ret is visible for A64)and >> start.S (so binutils knows that this is a possible function entry and >> it can correctly insert A32-to-Thumb transitions) and taking the axe >> to setjmp.h (which created quite a few issues with it not expecting >> A32/T32/Thumb call-sites and some fragility from GCC being smart about >> the clobber-list of the inline assembly... which led to r9 not being >> saved or restored). > This is missing information on dependant series. Using the > u-boot-rockchip > repository which is at > 782088de7be7 ("rockchip: imply ADC and SARADC_ROCKCHIP on supported > SoCs") > > patches 1-3 apply, but patch 4 fails to apply as I seem to be missing > some > dependencies. > > And the u-boot mailinglist seems to be configured very strangely, as it > seems to rip apart patch-series only sending me some parts. > > So far I can at least say, that the u-boot-rockchip repo at the above > commit still boots. Could you please point me to mbox versions > of needed base patches? Also, with patches 1-3 and 5 applied the radxarock board fails to start. I see the SPL banner and a "Returning to boot ROM..." and then nothing. I do belive it may have something to do with the TPL's + SPL's stack both being at the end of SRAM? Having the SPL go back to TPL and then back to bootrom was my original intention as well, but didn't work at the time. >>> I didn’t expect the stacks to overlap… so returning from SPL to TPL can’t >>> work. However, the jump_to_spl() is at least partially to blame (we already >>> have a working C-runtime and there’s no point in reentering through the >>> reset entry-point). >>> >>> I need to ponder this a bit, but my gut feeling is that the TPL->SPL >>> transition can be done in a less intrusive way and may allow us to retain >>> the TPL stack. >> Alternatively, if you can think of an easier solution we could do away with >> the TPL in its current form. When I did the rk3188 support, this looked like >> the least-messy way to me, but it really only does the one jump back >> to the bootrom - so I'm not sure if there isn't simply an easier solution. >> >> And for example the (still wip?) rk3066 series did use spl+tpl in a different >> way due to bootrom-nand-limitations. rk3066 and rk3188 are quite similar >> with the rk3066 simply not having the sd-boot capability, so if we want to >> have nand-boot on rk3188 as well in the future, this may need a different >> rework again. >> >> >> Heiko >> >> >> > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-spi/master
On Mon, Sep 25, 2017 at 2:11 PM, Łukasz Majewskiwrote: > Hi Jagan, > >> Hi Tom, >> >> Please pull this PR. > > > Would you find some time and look into following patch: > > http://patchwork.ozlabs.org/patch/813266/ Of-course, will comment on respective patch itself. 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 https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 16/19] arm: socfpga: Enhance Intel SoCFPGA program header to support Arria 10
From: Tien Fong CheeEnhance preloader header with both additional program length and program entry offset attributes, which offset is relative to the start of program header. Signed-off-by: Tien Fong Chee --- arch/arm/mach-socfpga/include/mach/boot0.h | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-socfpga/include/mach/boot0.h b/arch/arm/mach-socfpga/include/mach/boot0.h index 22d9e7f..33c9368 100644 --- a/arch/arm/mach-socfpga/include/mach/boot0.h +++ b/arch/arm/mach-socfpga/include/mach/boot0.h @@ -11,8 +11,15 @@ .balignl 64,0xf33db33f; .word 0x1337c0d3; /* SoCFPGA preloader validation word */ - .word 0xc01df00d; /* Version, flags, length */ - .word 0xcafec0d3; /* Checksum, zero-pad */ + .word 0xc01df00d; /* Header length(2B),flags(1B),version(1B) */ +#ifndef CONFIG_TARGET_SOCFPGA_GEN5 + .word 0xfeedface; /* Program length(4B) */ + .word 0xf00dcafe; /* +* Program entry offset(4B),relative to +* the start of program header +*/ +#endif + .word 0xcafec0d3; /* Simple checksum(2B),spare offset(2B) */ nop; b reset;/* SoCFPGA jumps here */ -- 2.2.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-spi/master
Hi Jagan, Hi Tom, Please pull this PR. Would you find some time and look into following patch: http://patchwork.ozlabs.org/patch/813266/ Thanks in advance, Łukasz thanks! Jagan. The following changes since commit 1f6049e2501b5c35c61435dbc05ba96743202674: tools/mkimage: Make the path to the dtc binary that mkimage calls configurable (2017-09-24 07:33:03 -0400) are available in the git repository at: git://git.denx.de/u-boot-spi.git master for you to fetch changes up to db10809c17c7cd8960d0c45248bbef6e76251ad7: Fix s25fl256s position in spi_flash_ids list (2017-09-25 13:00:34 +0530) Marek Vasut (1): sf: Fix S25FL116K entry Peng Fan (1): spi: mxc_spi: support driver model Suresh Gupta (1): spi: fsl_qspi: Add controller busy check before new spi operation Vsevolod Gribov (1): Fix s25fl256s position in spi_flash_ids list Yogesh Gaur (1): mtd/spi: Add MT35XU512ABA1G12 NOR flash support drivers/mtd/spi/spi_flash_ids.c | 5 +- drivers/spi/fsl_qspi.c | 28 ++- drivers/spi/fsl_qspi.h | 4 + drivers/spi/mxc_spi.c | 181 +--- 4 files changed, 183 insertions(+), 35 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot -- Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 13/19] configs: Add DDR Kconfig support for Arria 10
From: Tien Fong CheeThis patch enables DDR Kconfig support for Arria 10. Signed-off-by: Tien Fong Chee --- arch/arm/mach-socfpga/Kconfig | 1 + drivers/ddr/altera/Kconfig| 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig index 45e5379..3e7a68a 100644 --- a/arch/arm/mach-socfpga/Kconfig +++ b/arch/arm/mach-socfpga/Kconfig @@ -40,6 +40,7 @@ config TARGET_SOCFPGA_ARRIA5 config TARGET_SOCFPGA_ARRIA10 bool select SPL_BOARD_INIT if SPL + select ALTERA_SDRAM config TARGET_SOCFPGA_CYCLONE5 bool diff --git a/drivers/ddr/altera/Kconfig b/drivers/ddr/altera/Kconfig index 021ec1d..2b28a97 100644 --- a/drivers/ddr/altera/Kconfig +++ b/drivers/ddr/altera/Kconfig @@ -1,5 +1,5 @@ config ALTERA_SDRAM bool "SoCFPGA DDR SDRAM driver" - depends on TARGET_SOCFPGA_GEN5 + depends on TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10 help Enable DDR SDRAM controller for the SoCFPGA devices. -- 2.2.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 08/19] fs: Enable generic filesystems interface support in SPL.
From: Tien Fong CheeEnable generic filesystem interface drivers(fs.c and fat/) build for SPL. This would allow generic filesystem being used in SPL. Signed-off-by: Tien Fong Chee --- common/spl/Kconfig | 8 doc/README.SPL | 1 + fs/Makefile| 1 + 3 files changed, 10 insertions(+) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index 9446cd9..5f4bd92 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -304,6 +304,14 @@ config SPL_ETH_SUPPORT is required since the network stack uses a number of environment variables. See also SPL_NET_SUPPORT. +config SPL_FS_GENERIC + bool "Support Generic filesystems interface driver" + help + Enable support for generic filesystems interface with SPL. This + permits U-Boot (or Linux in Falcon mode) to be loaded from a generic + filesystem from within SPL. Support for the underlying block + device (e.g. MMC or USB) must be enabled separately. + config SPL_EXT_SUPPORT bool "Support EXT filesystems" help diff --git a/doc/README.SPL b/doc/README.SPL index 3ba313c..32628a4 100644 --- a/doc/README.SPL +++ b/doc/README.SPL @@ -55,6 +55,7 @@ CONFIG_SPL_SPI_FLASH_SUPPORT (drivers/mtd/spi/libspi_flash.o) CONFIG_SPL_SPI_SUPPORT (drivers/spi/libspi.o) CONFIG_SPL_FAT_SUPPORT (fs/fat/libfat.o) CONFIG_SPL_EXT_SUPPORT +CONFIG_SPL_FS_GENERIC (fs/fs.o fat/) CONFIG_SPL_LIBGENERIC_SUPPORT (lib/libgeneric.o) CONFIG_SPL_POWER_SUPPORT (drivers/power/libpower.o) CONFIG_SPL_NAND_SUPPORT (drivers/mtd/nand/libnand.o) diff --git a/fs/Makefile b/fs/Makefile index 5770f41..fdacac8 100644 --- a/fs/Makefile +++ b/fs/Makefile @@ -7,6 +7,7 @@ # ifdef CONFIG_SPL_BUILD +obj-$(CONFIG_SPL_FS_GENERIC) += fs.o fat/ obj-$(CONFIG_SPL_FAT_SUPPORT) += fat/ obj-$(CONFIG_SPL_EXT_SUPPORT) += ext4/ else -- 2.2.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 06/19] dts: Enable fpga-mgr node build for Arria 10 SPL
From: Tien Fong Cheefpga-mgr node is required in SPL, because SPL needs information from the node to configure FPGA in Arria 10. Signed-off-by: Tien Fong Chee --- arch/arm/dts/socfpga_arria10.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/dts/socfpga_arria10.dtsi b/arch/arm/dts/socfpga_arria10.dtsi index d4368ce..188a039 100644 --- a/arch/arm/dts/socfpga_arria10.dtsi +++ b/arch/arm/dts/socfpga_arria10.dtsi @@ -532,6 +532,7 @@ }; fpga_mgr: fpga-mgr@ffd03000 { + u-boot,dm-pre-reloc; compatible = "altr,socfpga-a10-fpga-mgr"; reg = <0xffd03000 0x100 0xffcfe400 0x20>; -- 2.2.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 17/19] arm: socfpga: Adding clock frequency info for U-boot
From: Tien Fong CheeClock frequency info is required in U-boot. Signed-off-by: Tien Fong Chee --- arch/arm/mach-socfpga/board.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/mach-socfpga/board.c b/arch/arm/mach-socfpga/board.c index 965f9dc..a00f63b 100644 --- a/arch/arm/mach-socfpga/board.c +++ b/arch/arm/mach-socfpga/board.c @@ -8,7 +8,10 @@ #include #include +#include #include +#include +#include #include #include @@ -26,6 +29,9 @@ int board_init(void) /* Address of boot parameters for ATAG (if ATAG is used) */ gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100; + /* configuring the clock based on handoff */ + cm_basic_init(gd->fdt_blob); + return 0; } -- 2.2.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/6] rockchip: back-to-bootrom: replace assembly-implementation with C-code
Hi Philipp, Heiko: I finally got the upstream u-boot run on a rk3188 board which can be attached by DS5 debugger, if you have some registers info want to check, please let me know. On 2017年09月21日 18:44, Heiko Stübner wrote: Am Donnerstag, 21. September 2017, 12:25:17 CEST schrieb Dr. Philipp Tomsich: On 21 Sep 2017, at 11:44, Heiko Stuebnerwrote: Am Donnerstag, 21. September 2017, 11:09:49 CEST schrieb Heiko Stuebner: Am Donnerstag, 21. September 2017, 10:19:23 CEST schrieb Philipp Tomsich: Recent discussions confirmed (what the code always assumed): the Rockchip BROM always enters U-Boot with the stack-pointer valid (i.e. the U-Boot startup code is running off the BROM stack). We can thus replace the back-to-bootrom code (i.e. both the save_boot_params and back_to_bootrom implementations) using C-code based on setjmp/longjmp. The new implementation is already structured to allow an easy drop-in of Andy's changes to enter download-mode when returning to the BROM. This turned out to require a some tweaking to system.h (making sure that the prototype for save_boot_params_ret is visible for A64)and start.S (so binutils knows that this is a possible function entry and it can correctly insert A32-to-Thumb transitions) and taking the axe to setjmp.h (which created quite a few issues with it not expecting A32/T32/Thumb call-sites and some fragility from GCC being smart about the clobber-list of the inline assembly... which led to r9 not being saved or restored). This is missing information on dependant series. Using the u-boot-rockchip repository which is at 782088de7be7 ("rockchip: imply ADC and SARADC_ROCKCHIP on supported SoCs") patches 1-3 apply, but patch 4 fails to apply as I seem to be missing some dependencies. And the u-boot mailinglist seems to be configured very strangely, as it seems to rip apart patch-series only sending me some parts. So far I can at least say, that the u-boot-rockchip repo at the above commit still boots. Could you please point me to mbox versions of needed base patches? Also, with patches 1-3 and 5 applied the radxarock board fails to start. I see the SPL banner and a "Returning to boot ROM..." and then nothing. I do belive it may have something to do with the TPL's + SPL's stack both being at the end of SRAM? Having the SPL go back to TPL and then back to bootrom was my original intention as well, but didn't work at the time. I didn’t expect the stacks to overlap… so returning from SPL to TPL can’t work. However, the jump_to_spl() is at least partially to blame (we already have a working C-runtime and there’s no point in reentering through the reset entry-point). I need to ponder this a bit, but my gut feeling is that the TPL->SPL transition can be done in a less intrusive way and may allow us to retain the TPL stack. Alternatively, if you can think of an easier solution we could do away with the TPL in its current form. When I did the rk3188 support, this looked like the least-messy way to me, but it really only does the one jump back to the bootrom - so I'm not sure if there isn't simply an easier solution. And for example the (still wip?) rk3066 series did use spl+tpl in a different way due to bootrom-nand-limitations. rk3066 and rk3188 are quite similar with the rk3066 simply not having the sd-boot capability, so if we want to have nand-boot on rk3188 as well in the future, this may need a different rework again. Heiko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 09/19] arm: socfpga: Add drivers for programing FPGA from flash
From: Tien Fong CheeThese drivers handle FPGA program operation from flash loading RBF to memory and then to program FPGA. Signed-off-by: Tien Fong Chee --- .../include/mach/fpga_manager_arria10.h| 27 ++ drivers/fpga/socfpga_arria10.c | 391 - include/altera.h | 6 + include/configs/socfpga_common.h | 4 + 4 files changed, 425 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h b/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h index 9cbf696..93a9122 100644 --- a/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h +++ b/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h @@ -8,6 +8,8 @@ #ifndef _FPGA_MANAGER_ARRIA10_H_ #define _FPGA_MANAGER_ARRIA10_H_ +#include + #define ALT_FPGAMGR_IMGCFG_STAT_F2S_CRC_ERROR_SET_MSK BIT(0) #define ALT_FPGAMGR_IMGCFG_STAT_F2S_EARLY_USERMODE_SET_MSK BIT(1) #define ALT_FPGAMGR_IMGCFG_STAT_F2S_USERMODE_SET_MSK BIT(2) @@ -89,11 +91,36 @@ struct socfpga_fpga_manager { u32 imgcfg_fifo_status; }; +#if defined(CONFIG_CMD_FPGA_LOADFS) +enum rbf_type {unknown, periph_section, core_section}; +enum rbf_security {invalid, unencrypted, encrypted}; + +struct rbf_info { + enum rbf_type section; + enum rbf_security security; +}; + +struct flash_info { + char *interface; + char *dev_part; + char *filename; + int fstype; + u32 remaining; + u32 flash_offset; + struct rbf_info rbfinfo; + struct image_header header; +}; +#endif + /* Functions */ int fpgamgr_program_init(u32 * rbf_data, size_t rbf_size); int fpgamgr_program_finish(void); int is_fpgamgr_user_mode(void); int fpgamgr_wait_early_user_mode(void); +#if defined(CONFIG_CMD_FPGA_LOADFS) +const char *get_cff_filename(const void *fdt, int *len, u32 core); +const char *get_cff_devpart(const void *fdt, int *len); +#endif #endif /* __ASSEMBLY__ */ diff --git a/drivers/fpga/socfpga_arria10.c b/drivers/fpga/socfpga_arria10.c index 5c1a68a..5fe57ef 100644 --- a/drivers/fpga/socfpga_arria10.c +++ b/drivers/fpga/socfpga_arria10.c @@ -13,6 +13,12 @@ #include #include #include +#include +#include +#include +#include +#include +#include #include #include @@ -22,6 +28,10 @@ #define COMPRESSION_OFFSET 229 #define FPGA_TIMEOUT_MSEC 1000 /* timeout in ms */ #define FPGA_TIMEOUT_CNT 0x100 +#define RBF_UNENCRYPTED0xa65c +#define RBF_ENCRYPTED 0xa65d +#define ARRIA10RBF_PERIPH 0x0001 +#define ARRIA10RBF_CORE0x8001 DECLARE_GLOBAL_DATA_PTR; @@ -112,13 +122,14 @@ static int wait_for_nconfig_pin_and_nstatus_pin(void) unsigned long mask = ALT_FPGAMGR_IMGCFG_STAT_F2S_NCONFIG_PIN_SET_MSK | ALT_FPGAMGR_IMGCFG_STAT_F2S_NSTATUS_PIN_SET_MSK; - /* Poll until f2s_nconfig_pin and f2s_nstatus_pin; loop until de-asserted, -* timeout at 1000ms + /* +* Poll until f2s_nconfig_pin and f2s_nstatus_pin; loop until +* de-asserted, timeout at 1000ms */ return wait_for_bit(__func__, _manager_base->imgcfg_stat, mask, - false, FPGA_TIMEOUT_MSEC, false); + true, FPGA_TIMEOUT_MSEC, false); } static int wait_for_f2s_nstatus_pin(unsigned long value) @@ -469,6 +480,7 @@ int socfpga_load(Altera_desc *desc, const void *rbf_data, size_t rbf_size) /* Initialize the FPGA Manager */ status = fpgamgr_program_init((u32 *)rbf_data, rbf_size); + if (status) return status; @@ -477,3 +489,376 @@ int socfpga_load(Altera_desc *desc, const void *rbf_data, size_t rbf_size) return fpgamgr_program_finish(); } + +#if defined(CONFIG_CMD_FPGA_LOADFS) +const char *get_cff_filename(const void *fdt, int *len, u32 core) +{ + const char *cff_filename = NULL; + const char *cell; + int nodeoffset; + nodeoffset = fdtdec_next_compatible(fdt, 0, +COMPAT_ALTERA_SOCFPGA_FPGA0); + + if (nodeoffset >= 0) { + if (core) + cell = fdt_getprop(fdt, + nodeoffset, + "bitstream_core", + len); + else + cell = fdt_getprop(fdt, nodeoffset, "bitstream_periph", +len); + + if (cell) + cff_filename = cell; + } + + return cff_filename; +} + +const char *get_cff_devpart(const void *fdt, int *len) +{ + const char *cff_devpart = NULL; + const char *cell; + int nodeoffset; + nodeoffset =
[U-Boot] [PATCH v2 11/19] arm: socfpga: Add DRAM bank size initialization function
From: Tien Fong CheeAdd function for both multiple DRAM bank and single DRAM bank size initialization. This common functionality could be used by every single SOCFPGA board. Signed-off-by: Tien Fong Chee --- arch/arm/mach-socfpga/board.c| 7 +++ include/configs/socfpga_common.h | 1 + 2 files changed, 8 insertions(+) diff --git a/arch/arm/mach-socfpga/board.c b/arch/arm/mach-socfpga/board.c index a41d089..965f9dc 100644 --- a/arch/arm/mach-socfpga/board.c +++ b/arch/arm/mach-socfpga/board.c @@ -29,6 +29,13 @@ int board_init(void) return 0; } +int dram_init_banksize(void) +{ + fdtdec_setup_memory_banksize(); + + return 0; +} + #ifdef CONFIG_USB_GADGET struct dwc2_plat_otg_data socfpga_otg_data = { .usb_gusbcfg= 0x1417, diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h index eadce2d..7549ee8 100644 --- a/include/configs/socfpga_common.h +++ b/include/configs/socfpga_common.h @@ -47,6 +47,7 @@ (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET) #define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 +#define CONFIG_SYS_SDRAM_SIZE PHYS_SDRAM_1_SIZE #ifdef CONFIG_SOCFPGA_VIRTUAL_TARGET #define CONFIG_SYS_TEXT_BASE 0x0840 #else -- 2.2.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 15/19] arm: socfpga: Add support to memory allocation in SPL
From: Tien Fong CheeAdd support to memory allocation in SPL for preparation to enable FAT in SPL. Memory allocation is needed by FAT to work properly. Signed-off-by: Tien Fong Chee --- include/configs/socfpga_common.h | 23 ++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h index 7549ee8..9b6719e 100644 --- a/include/configs/socfpga_common.h +++ b/include/configs/socfpga_common.h @@ -280,17 +280,34 @@ unsigned int cm_get_qspi_controller_clk_hz(void); /* * SPL * - * SRAM Memory layout: + * SRAM Memory layout for gen 5: * * 0x_ .. Start of SRAM * 0x_ .. Top of stack (grows down) * 0x_ .. Malloc area * 0x_ .. Global Data * 0x_FF00 .. End of SRAM + * + * SRAM Memory layout for Arria 10: + * 0xFFE0_ .. Start of SRAM (bottom) + * 0xFFEx_ .. Top of stack (grows down to bottom) + * 0xFFEy_ .. Malloc area (grows up to top) + * 0xFFEz_ .. Global Data + * 0xFFE3_ .. End of SRAM (top) */ #define CONFIG_SPL_FRAMEWORK #define CONFIG_SPL_TEXT_BASE CONFIG_SYS_INIT_RAM_ADDR #define CONFIG_SPL_MAX_SIZECONFIG_SYS_INIT_RAM_SIZE +#if defined(CONFIG_TARGET_SOCFPGA_ARRIA10) +/* SPL memory allocation configuration, it is required by FAT feature */ +#ifndef CONFIG_SYS_SPL_MALLOC_START +#define CONFIG_SYS_SPL_MALLOC_SIZE 0x2000 +#define CONFIG_SYS_SPL_MALLOC_START(CONFIG_SYS_INIT_RAM_SIZE - \ +GENERATED_GBL_DATA_SIZE - \ +CONFIG_SYS_SPL_MALLOC_SIZE + \ +CONFIG_SYS_INIT_RAM_ADDR) +#endif +#endif /* SPL SDMMC boot support */ #ifdef CONFIG_SPL_MMC_SUPPORT @@ -320,7 +337,11 @@ unsigned int cm_get_qspi_controller_clk_hz(void); /* * Stack setup */ +#if defined(CONFIG_TARGET_SOCFPGA_GEN5) #define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR +#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10) +#define CONFIG_SPL_STACK (CONFIG_SYS_SPL_MALLOC_START - 1) +#endif /* Extra Environment */ #ifndef CONFIG_SPL_BUILD -- 2.2.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 07/19] fdt: Add compatible strings for Arria 10
From: Tien Fong CheeAdd compatible strings for Intel Arria 10 SoCFPGA device. Signed-off-by: Tien Fong Chee --- include/fdtdec.h | 2 ++ lib/fdtdec.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/include/fdtdec.h b/include/fdtdec.h index 4a0947c..095ff36 100644 --- a/include/fdtdec.h +++ b/include/fdtdec.h @@ -157,6 +157,8 @@ enum fdt_compat_id { COMPAT_ALTERA_SOCFPGA_F2SDR0, /* SoCFPGA fpga2SDRAM0 bridge */ COMPAT_ALTERA_SOCFPGA_F2SDR1, /* SoCFPGA fpga2SDRAM1 bridge */ COMPAT_ALTERA_SOCFPGA_F2SDR2, /* SoCFPGA fpga2SDRAM2 bridge */ + COMPAT_ALTERA_SOCFPGA_FPGA0,/* SOCFPGA FPGA manager */ + COMPAT_ALTERA_SOCFPGA_NOC, /* SOCFPGA Arria 10 NOC */ COMPAT_COUNT, }; diff --git a/lib/fdtdec.c b/lib/fdtdec.c index 107a892..03ff75e 100644 --- a/lib/fdtdec.c +++ b/lib/fdtdec.c @@ -70,6 +70,8 @@ static const char * const compat_names[COMPAT_COUNT] = { COMPAT(ALTERA_SOCFPGA_F2SDR0, "altr,socfpga-fpga2sdram0-bridge"), COMPAT(ALTERA_SOCFPGA_F2SDR1, "altr,socfpga-fpga2sdram1-bridge"), COMPAT(ALTERA_SOCFPGA_F2SDR2, "altr,socfpga-fpga2sdram2-bridge"), + COMPAT(ALTERA_SOCFPGA_FPGA0, "altr,socfpga-a10-fpga-mgr"), + COMPAT(ALTERA_SOCFPGA_NOC, "altr,socfpga-a10-noc"), }; const char *fdtdec_get_compatible(enum fdt_compat_id id) -- 2.2.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 12/19] arm: socfpga: Add DDR driver for Arria 10
From: Tien Fong CheeAdd DDR driver suppport for Arria 10. Signed-off-by: Tien Fong Chee --- arch/arm/mach-socfpga/include/mach/sdram.h | 2 + arch/arm/mach-socfpga/include/mach/sdram_arria10.h | 103 ++- drivers/ddr/altera/sdram_arria10.c | 735 + 3 files changed, 839 insertions(+), 1 deletion(-) create mode 100644 drivers/ddr/altera/sdram_arria10.c diff --git a/arch/arm/mach-socfpga/include/mach/sdram.h b/arch/arm/mach-socfpga/include/mach/sdram.h index 4a9754e..b833fc2 100644 --- a/arch/arm/mach-socfpga/include/mach/sdram.h +++ b/arch/arm/mach-socfpga/include/mach/sdram.h @@ -10,6 +10,8 @@ #if defined(CONFIG_TARGET_SOCFPGA_GEN5) #include +#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10) +#include #endif #endif diff --git a/arch/arm/mach-socfpga/include/mach/sdram_arria10.h b/arch/arm/mach-socfpga/include/mach/sdram_arria10.h index 1d7b7c1..7af9431 100644 --- a/arch/arm/mach-socfpga/include/mach/sdram_arria10.h +++ b/arch/arm/mach-socfpga/include/mach/sdram_arria10.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2015-2017 Intel Corporation + * Copyright (C) 2017 Intel Corporation * * SPDX-License-Identifier:GPL-2.0 */ @@ -8,6 +8,7 @@ #define _SOCFPGA_SDRAM_ARRIA10_H_ #ifndef __ASSEMBLY__ +int ddr_calibration_sequence(void); struct socfpga_ecc_hmc { u32 ip_rev_id; @@ -204,6 +205,106 @@ struct socfpga_io48_mmr { u32 niosreserve1; u32 niosreserve2; }; + +union dramaddrw_reg { + struct { + u32 cfg_col_addr_width:5; + u32 cfg_row_addr_width:5; + u32 cfg_bank_addr_width:4; + u32 cfg_bank_group_addr_width:2; + u32 cfg_cs_addr_width:3; + u32 reserved:13; + }; + u32 word; +}; + +union ctrlcfg0_reg { + struct { + u32 cfg_mem_type:4; + u32 cfg_dimm_type:3; + u32 cfg_ac_pos:2; + u32 cfg_ctrl_burst_len:5; + u32 reserved:18; /* Other fields unused */ + }; + u32 word; +}; + +union ctrlcfg1_reg { + struct { + u32 cfg_dbc3_burst_len:5; + u32 cfg_addr_order:2; + u32 cfg_ctrl_enable_ecc:1; + u32 reserved:24; /* Other fields unused */ + }; + u32 word; +}; + +union caltiming0_reg { + struct { + u32 cfg_act_to_rdwr:6; + u32 cfg_act_to_pch:6; + u32 cfg_act_to_act:6; + u32 cfg_act_to_act_db:6; + u32 reserved:8; /* Other fields unused */ + }; + u32 word; +}; + +union caltiming1_reg { + struct { + u32 cfg_rd_to_rd:6; + u32 cfg_rd_to_rd_dc:6; + u32 cfg_rd_to_rd_db:6; + u32 cfg_rd_to_wr:6; + u32 cfg_rd_to_wr_dc:6; + u32 reserved:2; + }; + u32 word; +}; + +union caltiming2_reg { + struct { + u32 cfg_rd_to_wr_db:6; + u32 cfg_rd_to_pch:6; + u32 cfg_rd_ap_to_valid:6; + u32 cfg_wr_to_wr:6; + u32 cfg_wr_to_wr_dc:6; + u32 reserved:2; + }; + u32 word; +}; + +union caltiming3_reg { + struct { + u32 cfg_wr_to_wr_db:6; + u32 cfg_wr_to_rd:6; + u32 cfg_wr_to_rd_dc:6; + u32 cfg_wr_to_rd_db:6; + u32 cfg_wr_to_pch:6; + u32 reserved:2; + }; + u32 word; +}; + +union caltiming4_reg { + struct { + u32 cfg_wr_ap_to_valid:6; + u32 cfg_pch_to_valid:6; + u32 cfg_pch_all_to_valid:6; + u32 cfg_arf_to_valid:8; + u32 cfg_pdn_to_valid:6; + }; + u32 word; +}; + +union caltiming9_reg { + struct { + u32 cfg_4_act_to_act:8; + u32 reserved:24; + }; + u32 word; +}; + #endif /*__ASSEMBLY__*/ #define IO48_MMR_CTRLCFG0_DB2_BURST_LENGTH_MASK0x1F00 diff --git a/drivers/ddr/altera/sdram_arria10.c b/drivers/ddr/altera/sdram_arria10.c new file mode 100644 index 000..f22a726 --- /dev/null +++ b/drivers/ddr/altera/sdram_arria10.c @@ -0,0 +1,735 @@ +/* + * Copyright (C) 2017 Intel Corporation + * + * SPDX-License-Identifier:GPL-2.0 + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +DECLARE_GLOBAL_DATA_PTR; + +static void sdram_mmr_init(void); +static unsigned long long sdram_size_calc(void); + +/* FAWBANK - Number of Bank of a given device involved in the FAW period. */ +#define ARRIA10_SDR_ACTIVATE_FAWBANK (0x1) + +#define ARRIA_DDR_CONFIG(A, B, C, R) ((A<<24)|(B<<16)|(C<<8)|R) +#define DDR_CONFIG_ELEMENTS(sizeof(ddr_config)/sizeof(u32)) +#define DDR_REG_SEQ2CORE0xFFD0507C +#define DDR_REG_CORE2SEQ
[U-Boot] [PATCH v2 10/19] arm: socfpga: Rename the gen5 sdram driver to more specific name
From: Tien Fong CheeCurrent sdram driver is only applied to gen5 device, hence it is better to rename sdram driver to more specific name which is related to gen5 device. Signed-off-by: Tien Fong Chee --- arch/arm/mach-socfpga/include/mach/sdram.h | 434 + .../include/mach/{sdram.h => sdram_gen5.h} | 6 +- drivers/ddr/altera/Makefile| 2 +- drivers/ddr/altera/{sdram.c => sdram_gen5.c} | 0 4 files changed, 8 insertions(+), 434 deletions(-) copy arch/arm/mach-socfpga/include/mach/{sdram.h => sdram_gen5.h} (99%) rename drivers/ddr/altera/{sdram.c => sdram_gen5.c} (100%) diff --git a/arch/arm/mach-socfpga/include/mach/sdram.h b/arch/arm/mach-socfpga/include/mach/sdram.h index b11228f..4a9754e 100644 --- a/arch/arm/mach-socfpga/include/mach/sdram.h +++ b/arch/arm/mach-socfpga/include/mach/sdram.h @@ -1,5 +1,5 @@ /* - * Copyright Altera Corporation (C) 2014-2015 + * Copyright (C) 2017 Intel Corporation * * SPDX-License-Identifier:GPL-2.0+ */ @@ -8,435 +8,9 @@ #ifndef __ASSEMBLY__ -unsigned long sdram_calculate_size(void); -int sdram_mmr_init_full(unsigned int sdr_phy_reg); -int sdram_calibration_full(void); - -const struct socfpga_sdram_config *socfpga_get_sdram_config(void); - -void socfpga_get_seq_ac_init(const u32 **init, unsigned int *nelem); -void socfpga_get_seq_inst_init(const u32 **init, unsigned int *nelem); -const struct socfpga_sdram_rw_mgr_config *socfpga_get_sdram_rwmgr_config(void); -const struct socfpga_sdram_io_config *socfpga_get_sdram_io_config(void); -const struct socfpga_sdram_misc_config *socfpga_get_sdram_misc_config(void); - -#define SDR_CTRLGRP_ADDRESS(SOCFPGA_SDR_ADDRESS | 0x5000) - -struct socfpga_sdr_ctrl { - u32 ctrl_cfg; - u32 dram_timing1; - u32 dram_timing2; - u32 dram_timing3; - u32 dram_timing4; /* 0x10 */ - u32 lowpwr_timing; - u32 dram_odt; - u32 extratime1; - u32 __padding0[3]; - u32 dram_addrw; /* 0x2c */ - u32 dram_if_width; /* 0x30 */ - u32 dram_dev_width; - u32 dram_sts; - u32 dram_intr; - u32 sbe_count; /* 0x40 */ - u32 dbe_count; - u32 err_addr; - u32 drop_count; - u32 drop_addr; /* 0x50 */ - u32 lowpwr_eq; - u32 lowpwr_ack; - u32 static_cfg; - u32 ctrl_width; /* 0x60 */ - u32 cport_width; - u32 cport_wmap; - u32 cport_rmap; - u32 rfifo_cmap; /* 0x70 */ - u32 wfifo_cmap; - u32 cport_rdwr; - u32 port_cfg; - u32 fpgaport_rst; /* 0x80 */ - u32 __padding1; - u32 fifo_cfg; - u32 protport_default; - u32 prot_rule_addr; /* 0x90 */ - u32 prot_rule_id; - u32 prot_rule_data; - u32 prot_rule_rdwr; - u32 __padding2[3]; - u32 mp_priority;/* 0xac */ - u32 mp_weight0; /* 0xb0 */ - u32 mp_weight1; - u32 mp_weight2; - u32 mp_weight3; - u32 mp_pacing0; /* 0xc0 */ - u32 mp_pacing1; - u32 mp_pacing2; - u32 mp_pacing3; - u32 mp_threshold0; /* 0xd0 */ - u32 mp_threshold1; - u32 mp_threshold2; - u32 __padding3[29]; - u32 phy_ctrl0; /* 0x150 */ - u32 phy_ctrl1; - u32 phy_ctrl2; -}; - -/* SDRAM configuration structure for the SPL. */ -struct socfpga_sdram_config { - u32 ctrl_cfg; - u32 dram_timing1; - u32 dram_timing2; - u32 dram_timing3; - u32 dram_timing4; - u32 lowpwr_timing; - u32 dram_odt; - u32 extratime1; - u32 dram_addrw; - u32 dram_if_width; - u32 dram_dev_width; - u32 dram_intr; - u32 lowpwr_eq; - u32 static_cfg; - u32 ctrl_width; - u32 cport_width; - u32 cport_wmap; - u32 cport_rmap; - u32 rfifo_cmap; - u32 wfifo_cmap; - u32 cport_rdwr; - u32 port_cfg; - u32 fpgaport_rst; - u32 fifo_cfg; - u32 mp_priority; - u32 mp_weight0; - u32 mp_weight1; - u32 mp_weight2; - u32 mp_weight3; - u32 mp_pacing0; - u32 mp_pacing1; - u32 mp_pacing2; - u32 mp_pacing3; - u32 mp_threshold0; - u32 mp_threshold1; - u32 mp_threshold2; - u32 phy_ctrl0; -}; - -struct socfpga_sdram_rw_mgr_config { - u8 activate_0_and_1; - u8 activate_0_and_1_wait1; - u8 activate_0_and_1_wait2; - u8 activate_1; - u8 clear_dqs_enable; - u8 guaranteed_read; - u8
[U-Boot] [PATCH v2 14/19] arm: socfpga: Enable build for DDR Arria 10
From: Tien Fong CheeThis patch is for enabling the DDR support on Arria 10. Signed-off-by: Tien Fong Chee --- drivers/ddr/altera/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/ddr/altera/Makefile b/drivers/ddr/altera/Makefile index ac4ab85..02f8b7c 100644 --- a/drivers/ddr/altera/Makefile +++ b/drivers/ddr/altera/Makefile @@ -10,4 +10,5 @@ ifdef CONFIG_ALTERA_SDRAM obj-$(CONFIG_TARGET_SOCFPGA_GEN5) += sdram_gen5.o sequencer.o +obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += sdram_arria10.o endif -- 2.2.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 03/19] dts: Add FPGA bitstream properties to Arria 10 DTS
From: Tien Fong CheeThese FPGA bitstream properties would help bootloader to understand how to configure FPGA and where to look the FPGA RBF files during booting. Signed-off-by: Tien Fong Chee --- arch/arm/dts/socfpga_arria10.dtsi | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/dts/socfpga_arria10.dtsi b/arch/arm/dts/socfpga_arria10.dtsi index 377700d..d4368ce 100644 --- a/arch/arm/dts/socfpga_arria10.dtsi +++ b/arch/arm/dts/socfpga_arria10.dtsi @@ -538,6 +538,9 @@ clocks = <_mp_clk>; resets = < FPGAMGR_RESET>; reset-names = "fpgamgr"; + bitstream_periph = "ghrd_10as066n2.periph.rbf.mkimage"; + bitstream_core = "ghrd_10as066n2.core.rbf.mkimage"; + bitstream_devpart = "0:1"; }; i2c0: i2c@ffc02200 { -- 2.2.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 05/19] arm: socfpga: Enhance FPGA program write rbf data with size >= 4 bytes
From: Tien Fong CheeExisting FPGA program write is always assume RBF data >= 32 bytes, so any rbf data less than 32 bytes writing to FPGA would be failed. This patch enhances the FPGA program write to support rbf data with size >= 4 bytes. Signed-off-by: Tien Fong Chee --- drivers/fpga/socfpga.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/fpga/socfpga.c b/drivers/fpga/socfpga.c index 28fa16b..6e14ebd 100644 --- a/drivers/fpga/socfpga.c +++ b/drivers/fpga/socfpga.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2012 Altera Corporation + * Copyright (C) 2012-2017 Altera Corporation * All rights reserved. * * SPDX-License-Identifier:BSD-3-Clause @@ -55,18 +55,20 @@ void fpgamgr_program_write(const void *rbf_data, size_t rbf_size) uint32_t loops4 = DIV_ROUND_UP(rbf_size % 32, 4); asm volatile( + " cmp %2, #0\n" + " beq 2f\n" "1: ldmia %0!,{r0-r7}\n" " stmia %1!,{r0-r7}\n" " sub %1, #32\n" " subs%2, #1\n" " bne 1b\n" - " cmp %3, #0\n" - " beq 3f\n" - "2: ldr %2, [%0], #4\n" + "2: cmp %3, #0\n" + " beq 4f\n" + "3: ldr %2, [%0], #4\n" " str %2, [%1]\n" " subs%3, #1\n" - " bne 2b\n" - "3: nop\n" + " bne 3b\n" + "4: nop\n" : "+r"(src), "+r"(dst), "+r"(loops32), "+r"(loops4) : : "r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7", "cc"); } -- 2.2.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 04/19] arm: socfpga: Add Arria 10 SoCFPGA programming interface
From: Tien Fong CheeAdd code necessary into the FPGA driver framework in U-Boot so it can be used via the 'fpga' command for programing Arria 10 SoCFPGA. Signed-off-by: Tien Fong Chee --- cmd/fpga.c| 2 +- drivers/fpga/altera.c | 39 +++ drivers/fpga/fpga.c | 8 include/fpga.h| 2 ++ 4 files changed, 42 insertions(+), 9 deletions(-) diff --git a/cmd/fpga.c b/cmd/fpga.c index ac6f504..3cb0bcd 100644 --- a/cmd/fpga.c +++ b/cmd/fpga.c @@ -363,7 +363,7 @@ U_BOOT_CMD(fpga, 6, 1, do_fpga, "(Xilinx only)\n" #endif #if defined(CONFIG_CMD_FPGA_LOADFS) - "Load device from filesystem (FAT by default) (Xilinx only)\n" + "Load device from filesystem (FAT by default)\n" " loadfs [dev] [address] [image size] [blocksize] \n" "[ ] \n" #endif diff --git a/drivers/fpga/altera.c b/drivers/fpga/altera.c index 135a357..e2bee99 100644 --- a/drivers/fpga/altera.c +++ b/drivers/fpga/altera.c @@ -23,25 +23,31 @@ static const struct altera_fpga { enum altera_family family; const char *name; int (*load)(Altera_desc *, const void *, size_t); + int (*loadfs)(Altera_desc *, const void *, size_t, fpga_fs_info *); int (*dump)(Altera_desc *, const void *, size_t); int (*info)(Altera_desc *); } altera_fpga[] = { #if defined(CONFIG_FPGA_ACEX1K) - { Altera_ACEX1K, "ACEX1K", ACEX1K_load, ACEX1K_dump, ACEX1K_info }, - { Altera_CYC2, "ACEX1K", ACEX1K_load, ACEX1K_dump, ACEX1K_info }, + { Altera_ACEX1K, "ACEX1K", ACEX1K_load, NULL, ACEX1K_dump, +ACEX1K_info }, + { Altera_CYC2, "ACEX1K", ACEX1K_load, NULL, ACEX1K_dump, +ACEX1K_info }, #elif defined(CONFIG_FPGA_CYCLON2) - { Altera_ACEX1K, "CycloneII", CYC2_load, CYC2_dump, CYC2_info }, - { Altera_CYC2, "CycloneII", CYC2_load, CYC2_dump, CYC2_info }, + { Altera_ACEX1K, "CycloneII", CYC2_load, NULL, CYC2_dump, CYC2_info }, + { Altera_CYC2, "CycloneII", CYC2_load, NULL, CYC2_dump, CYC2_info }, #endif #if defined(CONFIG_FPGA_STRATIX_II) - { Altera_StratixII, "StratixII", StratixII_load, + { Altera_StratixII, "StratixII", StratixII_load, NULL, StratixII_dump, StratixII_info }, #endif #if defined(CONFIG_FPGA_STRATIX_V) - { Altera_StratixV, "StratixV", stratixv_load, NULL, NULL }, + { Altera_StratixV, "StratixV", stratixv_load, NULL, NULL, NULL }, #endif -#if defined(CONFIG_FPGA_SOCFPGA) - { Altera_SoCFPGA, "SoC FPGA", socfpga_load, NULL, NULL }, +#if defined(CONFIG_FPGA_SOCFPGA) && defined(CONFIG_CMD_FPGA_LOADFS) + { Altera_SoCFPGA, "SoC FPGA", socfpga_load, socfpga_loadfs, NULL, +NULL }, +#elif defined(CONFIG_FPGA_SOCFPGA) + { Altera_SoCFPGA, "SoC FPGA", socfpga_load, NULL, NULL, NULL }, #endif }; @@ -174,3 +180,20 @@ int altera_info(Altera_desc *desc) return FPGA_SUCCESS; } + +#if defined(CONFIG_CMD_FPGA_LOADFS) +int altera_loadfs(Altera_desc *desc, const void *buf, size_t bsize, + fpga_fs_info *fpga_fsinfo) +{ + const struct altera_fpga *fpga = altera_desc_to_fpga(desc, __func__); + + if (!fpga) + return FPGA_FAIL; + + debug_cond(FPGA_DEBUG, "%s: Launching the %s FS Loader...\n", + __func__, fpga->name); + if (fpga->loadfs) + return fpga->loadfs(desc, buf, bsize, fpga_fsinfo); + return 0; +} +#endif diff --git a/drivers/fpga/fpga.c b/drivers/fpga/fpga.c index e0fb1b4..42e901e 100644 --- a/drivers/fpga/fpga.c +++ b/drivers/fpga/fpga.c @@ -198,6 +198,14 @@ int fpga_fsload(int devnum, const void *buf, size_t size, fpga_no_sup((char *)__func__, "Xilinx devices"); #endif break; +#if defined(CONFIG_FPGA_ALTERA) + case fpga_altera: + ret_val = altera_loadfs(desc->devdesc, buf, size, + fpga_fsinfo); +#else + fpga_no_sup((char *)__func__, "Altera devices"); +#endif + break; default: printf("%s: Invalid or unsupported device type %d\n", __func__, desc->devtype); diff --git a/include/fpga.h b/include/fpga.h index d768fb1..8920016 100644 --- a/include/fpga.h +++ b/include/fpga.h @@ -56,8 +56,10 @@ int fpga_count(void); const fpga_desc *const fpga_get_desc(int devnum); int fpga_load(int devnum, const void *buf, size_t bsize, bitstream_type bstype); +#if defined(CONFIG_CMD_FPGA_LOADFS) int fpga_fsload(int devnum, const void *buf, size_t size, fpga_fs_info *fpga_fsinfo); +#endif int fpga_loadbitstream(int devnum, char *fpgadata, size_t size,
[U-Boot] [PATCH v2 01/19] ARM: socfpga: add bindings doc for arria10 fpga manager
From: Tien Fong CheeThis DT binding doc is porting from Linux DT binding doc. commit 1adcbea4201a6852362aa5ece573f1f169b28113 Add a device tree bindings document for the SoCFPGA Arria10 FPGA Manager driver. Signed-off-by: Alan Tull Acked-by: Rob Herring Acked-By: Moritz Fischer Signed-off-by: Rob Herring Signed-off-by: Tien Fong Chee --- .../fpga/altera-socfpga-a10-fpga-mgr.txt | 19 +++ 1 file changed, 19 insertions(+) create mode 100644 doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt diff --git a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt new file mode 100644 index 000..2fd8e7a --- /dev/null +++ b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt @@ -0,0 +1,19 @@ +Altera SOCFPGA Arria10 FPGA Manager + +Required properties: +- compatible : should contain "altr,socfpga-a10-fpga-mgr" +- reg: base address and size for memory mapped io. + - The first index is for FPGA manager register access. + - The second index is for writing FPGA configuration data. +- resets : Phandle and reset specifier for the device's reset. +- clocks : Clocks used by the device. + +Example: + + fpga_mgr: fpga-mgr@ffd03000 { + compatible = "altr,socfpga-a10-fpga-mgr"; + reg = <0xffd03000 0x100 + 0xffcfe400 0x20>; + clocks = <_mp_clk>; + resets = < FPGAMGR_RESET>; + }; -- 2.2.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot