Re: [U-Boot] [PATCHv2][RESEND] spi: Add support for N25Q016A
On 14 July 2016 at 00:00, Moritz Fischer wrote: > Signed-off-by: Moritz Fischer > --- > drivers/mtd/spi/sf_params.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c > index 4f37e33..8ae4eea 100644 > --- a/drivers/mtd/spi/sf_params.c > +++ b/drivers/mtd/spi/sf_params.c > @@ -83,6 +83,7 @@ const struct spi_flash_params spi_flash_params_table[] = { > {"M25P64", 0x202017, 0x0, 64 * 1024, 128, RD_NORM, > 0}, > {"M25P128",0x202018, 0x0, 256 * 1024,64, RD_NORM, > 0}, > {"M25PX64",0x207117, 0x0, 64 * 1024, 128, RD_NORM, > SECT_4K}, > + {"N25Q016A", 0x20bb15, 0x1000,64 * 1024,32, RD_NORM, > SECT_4K}, Why would we need this ext_id (0x1000) here? I understand this is true number for this part but it shouldn't require for probe or require somewhere else? thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] fdt_support: define stub for fdt_fixup_mtdparts
On 07/13/2016 12:37 AM, christopher.spinr...@rwth-aachen.de wrote: > From: Christopher Spinrath > > Define an inline stub for fdt_fixup_mtdparts in the case that > CONFIG_FDT_FIXUP_PARTITIONS is not defined. This avoids the need > to guard every call to this function by a proper #ifdef in board > files. > > Signed-off-by: Christopher Spinrath Thanks! Reviewed-by: Igor Grinberg -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] ARM: board: cm_fx6: fixup mtd partitions in the fdt
On 07/13/2016 12:37 AM, christopher.spinr...@rwth-aachen.de wrote: > From: Christopher Spinrath > > The cm-fx6 module has an on-board st,m25p compatible spi flash chip > used for U-Boot (binary & environment). Overwrite the partitions in > the device tree by the partition table provided in the mtdparts > environment variable, if it is set. > > This allows to specify a kernel independent partitioning in the > environment and provides a convient way for the user to adapt the > partition table. > > Signed-off-by: Christopher Spinrath Acked-by: Igor Grinberg -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] ARM: configs: cm_fx6: add mtd support
On 07/13/2016 12:37 AM, christopher.spinr...@rwth-aachen.de wrote: > From: Christopher Spinrath > > The cm-fx6 module has an on-board spi flash chip. Enable mtd support > and the mtdparts command. Also define a default partitioning, add > it to the default environment, and enable support to overwrite the > partitioning defined in a device tree by it. Finally, probe for the > chip on preboot to register the flash chip and, thus, establish the > connection between the mtd environment settings and the actual device. > > These changes move the effective default partitioning from the device > tree shipped with the vendor kernels to U-Boot which becomes the single > point of definition for the partitioning for all device tree based > kernels (in particular, for the upstream Linux kernel which does not > have a default partitioning defined in its device tree). > > Signed-off-by: Christopher Spinrath Acked-by: Igor Grinberg -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] powerpc/mpc85xx: T104x: Add nand secure boot target
For mpc85xx SoCs, the core begins execution from address 0xFFFC. In non-secure boot scenario from NAND, this address will map to CPC configured as SRAM. But in case of secure boot, this default address always maps to IBR (Internal Boot ROM). The IBR code requires that the bootloader(U-boot) must lie in 0 to 3.5G address space i.e. 0x0 - 0xDFFF. For secure boot target from NAND, the text base for SPL is kept same as non-secure boot target i.e. 0xFFFx_ but the SPL U-boot binary will be copied to CPC configured as SRAM with address in 0-3.5G(0xBFFC_) As a the virtual and physical address of CPC would be different. The virtual address 0xFFFx_ needs to be mapped to physical address 0xBFFx_. Create a new PBI file to configure CPC as SRAM with address 0xBFFC and update DCFG SCRTACH1 register with location of Header required for secure boot. The changes are similar to commit 467a40dfe35f48d830f01a72617207d03ca85b4d powerpc/mpc85xx: SECURE BOOT- NAND secure boot target for P3041 While P3041 has a 1MB CPC and does not require SPL. On T104x, CPC is only 256K and thus SPL framework is used. The changes are only applicable for SPL U-Boot running out of CPC SRAM and not the next level U-Boot loaded on DDR. Reviewed-by: Ruchika Gupta Reviewed-by: Simon Glass Signed-off-by: Aneesh Bansal Signed-off-by: Sumit Garg --- Changes PATCH v5->PATCH v6: Incorporated review comments regarding comment style. Changes PATCH v4->PATCH v5: No change. Changes PATCH v3->PATCH v4: No change. Changes PATCH v2->PATCH v3: Patches rebased Changes PATCH->PATCH v2: Patches rebased arch/powerpc/cpu/mpc85xx/cpu_init.c| 4 +-- arch/powerpc/cpu/mpc85xx/start.S | 12 ++-- arch/powerpc/include/asm/fsl_secure_boot.h | 10 ++- board/freescale/t104xrdb/t104x_pbi_sb.cfg | 38 ++ board/freescale/t104xrdb/tlb.c | 15 +- configs/T1042RDB_PI_NAND_SECURE_BOOT_defconfig | 30 include/configs/T104xRDB.h | 29 +++- 7 files changed, 130 insertions(+), 8 deletions(-) create mode 100644 board/freescale/t104xrdb/t104x_pbi_sb.cfg create mode 100644 configs/T1042RDB_PI_NAND_SECURE_BOOT_defconfig diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c b/arch/powerpc/cpu/mpc85xx/cpu_init.c index 61f5639..ace4279 100644 --- a/arch/powerpc/cpu/mpc85xx/cpu_init.c +++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c @@ -439,7 +439,7 @@ ulong cpu_init_f(void) #ifdef CONFIG_SYS_DCSRBAR_PHYS ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR); #endif -#if defined(CONFIG_SECURE_BOOT) +#if defined(CONFIG_SECURE_BOOT) && !defined(CONFIG_SYS_RAMBOOT) struct law_entry law; #endif #ifdef CONFIG_MPC8548 @@ -459,7 +459,7 @@ ulong cpu_init_f(void) disable_tlb(14); disable_tlb(15); -#if defined(CONFIG_SECURE_BOOT) +#if defined(CONFIG_SECURE_BOOT) && !defined(CONFIG_SYS_RAMBOOT) /* Disable the LAW created for NOR flash by the PBI commands */ law = find_law(CONFIG_SYS_PBI_FLASH_BASE); if (law.index != -1) diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S index 4c51225..c3e1234 100644 --- a/arch/powerpc/cpu/mpc85xx/start.S +++ b/arch/powerpc/cpu/mpc85xx/start.S @@ -1069,17 +1069,23 @@ create_init_ram_area: #elif !defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_SECURE_BOOT) /* create a temp mapping in AS = 1 for Flash mapping * created by PBL for ISBC code - */ +*/ create_tlb1_entry 15, \ 1, BOOKE_PAGESZ_1M, \ CONFIG_SYS_MONITOR_BASE & 0xfff0, MAS2_I|MAS2_G, \ CONFIG_SYS_PBI_FLASH_WINDOW & 0xfff0, MAS3_SX|MAS3_SW|MAS3_SR, \ 0, r6 -#elif defined(CONFIG_RAMBOOT_PBL) && defined(CONFIG_SECURE_BOOT) +/* + * For Targets without CONFIG_SPL like P3, P5 + * and for targets with CONFIG_SPL like T1, T2, T4, only for + * u-boot-spl i.e. CONFIG_SPL_BUILD + */ +#elif defined(CONFIG_RAMBOOT_PBL) && defined(CONFIG_SECURE_BOOT) && \ + (!defined(CONFIG_SPL) || defined(CONFIG_SPL_BUILD)) /* create a temp mapping in AS = 1 for mapping CONFIG_SYS_MONITOR_BASE * to L3 Address configured by PBL for ISBC code - */ +*/ create_tlb1_entry 15, \ 1, BOOKE_PAGESZ_1M, \ CONFIG_SYS_MONITOR_BASE & 0xfff0, MAS2_I|MAS2_G, \ diff --git a/arch/powerpc/include/asm/fsl_secure_boot.h b/arch/powerpc/include/asm/fsl_secure_boot.h index 9420021..2e2d565 100644 --- a/arch/powerpc/include/asm/fsl_secure_boot.h +++ b/arch/powerpc/include/asm/fsl_secure_boot.h @@ -35,7 +35,9 @@ defined(CONFIG_T104xD4RDB) || \ defined(CONFIG_PPC_T1023) || \ defined(CONFIG_PPC_T1024) +#ifndef CONFIG_SYS_RAMBOOT #define CONFIG_SYS_CPC_REINIT_F +#endif #define CONFIG_KEY_REVOCATION #undef CONFIG_SYS_INIT_L3_ADDR #define CONFIG_SYS_INIT_L3_ADDR
[U-Boot] [PATCH 1/3] powerpc/mpc85xx: SECURE BOOT- Enable chain of trust in SPL
As part of Chain of Trust for Secure boot, the SPL U-Boot will validate the next level U-boot image. Add a new function spl_validate_uboot to perform the validation. Enable hardware crypto operations in SPL using SEC block. In case of Secure Boot, PAMU is not bypassed. For allowing SEC block access to CPC configured as SRAM, configure PAMU. Reviewed-by: Ruchika Gupta Signed-off-by: Aneesh Bansal Signed-off-by: Sumit Garg --- Changes PATCH v5->PATCH v6: Incorporated review comments regarding comment style. Changes PATCH v4->PATCH v5: Check for def CONFIG_SPL_DM and ndef CONFIG_SPL_FRAMEWORK instead of def CONFIG_DM macro to include call to dm_init_and_scan(). As dm_init_and_scan() is called as part of common SPL framework, so no need to call it again but in case of powerpc platforms which currently do not use common SPL framework, so need to include this function call here. Changes PATCH v3->PATCH v4: Generic changes in lib, drivers, common Makefiles removed from this patchset. Rebased this patchset on top of patch [1], so this patchset is dependent on patch [1]. Changes PATCH v2->PATCH v3: Patches rebased Changes PATCH->PATCH v2: Patches rebased [1]https://patchwork.ozlabs.org/patch/627664/ arch/powerpc/cpu/mpc8xxx/fsl_pamu.c | 8 + arch/powerpc/cpu/mpc8xxx/pamu_table.c | 8 + arch/powerpc/include/asm/fsl_secure_boot.h | 31 +++- board/freescale/common/fsl_chain_of_trust.c | 56 + drivers/crypto/fsl/jr.c | 17 + drivers/mtd/nand/fsl_ifc_spl.c | 24 + include/fsl_validate.h | 7 7 files changed, 150 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/cpu/mpc8xxx/fsl_pamu.c b/arch/powerpc/cpu/mpc8xxx/fsl_pamu.c index 9421f1e..ede8e66 100644 --- a/arch/powerpc/cpu/mpc8xxx/fsl_pamu.c +++ b/arch/powerpc/cpu/mpc8xxx/fsl_pamu.c @@ -239,15 +239,23 @@ int pamu_init(void) spaact_size = sizeof(struct paace) * NUM_SPAACT_ENTRIES; /* Allocate space for Primary PAACT Table */ +#if (defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_PPAACT_ADDR)) + ppaact = (void *)CONFIG_SPL_PPAACT_ADDR; +#else ppaact = memalign(PAMU_TABLE_ALIGNMENT, ppaact_size); if (!ppaact) return -1; +#endif memset(ppaact, 0, ppaact_size); /* Allocate space for Secondary PAACT Table */ +#if (defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_SPAACT_ADDR)) + sec = (void *)CONFIG_SPL_SPAACT_ADDR; +#else sec = memalign(PAMU_TABLE_ALIGNMENT, spaact_size); if (!sec) return -1; +#endif memset(sec, 0, spaact_size); ppaact_phys = virt_to_phys((void *)ppaact); diff --git a/arch/powerpc/cpu/mpc8xxx/pamu_table.c b/arch/powerpc/cpu/mpc8xxx/pamu_table.c index 26c5ea4..a8e6f51 100644 --- a/arch/powerpc/cpu/mpc8xxx/pamu_table.c +++ b/arch/powerpc/cpu/mpc8xxx/pamu_table.c @@ -28,6 +28,14 @@ void construct_pamu_addr_table(struct pamu_addr_tbl *tbl, int *num_entries) i++; #endif +#if (defined(CONFIG_SPL_BUILD) && (CONFIG_SYS_INIT_L3_VADDR)) + tbl->start_addr[i] = + (uint64_t)virt_to_phys((void *)CONFIG_SYS_INIT_L3_VADDR); + tbl->size[i] = 256 * 1024; /* 256K CPC flash */ + tbl->end_addr[i] = tbl->start_addr[i] + tbl->size[i] - 1; + + i++; +#endif debug("PAMU address\t\t\tsize\n"); for (j = 0; j < i ; j++) debug("%llx \t\t\t%llx\n", tbl->start_addr[j], tbl->size[j]); diff --git a/arch/powerpc/include/asm/fsl_secure_boot.h b/arch/powerpc/include/asm/fsl_secure_boot.h index 826f9c9..9420021 100644 --- a/arch/powerpc/include/asm/fsl_secure_boot.h +++ b/arch/powerpc/include/asm/fsl_secure_boot.h @@ -72,6 +72,32 @@ #ifdef CONFIG_CHAIN_OF_TRUST +#ifdef CONFIG_SPL_BUILD +#define CONFIG_SPL_DM 1 +#define CONFIG_SPL_CRYPTO_SUPPORT +#define CONFIG_SPL_HASH_SUPPORT +#define CONFIG_SPL_RSA +#define CONFIG_SPL_DRIVERS_MISC_SUPPORT +/* + * PPAACT and SPAACT table for PAMU must be placed on DDR after DDR init + * due to space crunch on CPC and thus malloc will not work. + */ +#define CONFIG_SPL_PPAACT_ADDR 0x2e00 +#define CONFIG_SPL_SPAACT_ADDR 0x2f00 +#define CONFIG_SPL_JR0_LIODN_S 454 +#define CONFIG_SPL_JR0_LIODN_NS458 +/* + * Define the key hash for U-Boot here if public/private key pair used to + * sign U-boot are different from the SRK hash put in the fuse + * Example of defining KEY_HASH is + * #define CONFIG_SPL_UBOOT_KEY_HASH \ + * "41066b564c6ffcef40ccbc1e0a5d0d519604000c785d97bbefd25e4d288d1c8b" + * else leave it defined as NULL + */ + +#define CONFIG_SPL_UBOOT_KEY_HASH NULL +#endif /* ifdef CONFIG_SPL_BUILD */ + #define CONFIG_CMD_ESBC_VALIDATE #define CONFIG_CMD_BLOB #define CONFIG_FSL_SEC_MON @@ -82,7 +108,9 @@ #define CONFIG_FSL_CAAM #endif -/* fsl_setenv_chain_of_trust() must be called from +#ifndef CONFIG_SPL_BUIL
[U-Boot] [PATCH 3/3] doc: SPL: Add README for secure boot support
Adds information regarding SPL handling validation process of main u-boot image on power/mpc85xx and arm/layerscape platforms. Signed-off-by: Sumit Garg --- Changes PATCH v5->PATCH v6: Added README for SECURE BOOT support in SPL framework. doc/SPL/README.spl-secure-boot | 18 ++ 1 file changed, 18 insertions(+) create mode 100644 doc/SPL/README.spl-secure-boot diff --git a/doc/SPL/README.spl-secure-boot b/doc/SPL/README.spl-secure-boot new file mode 100644 index 000..f2f8d78 --- /dev/null +++ b/doc/SPL/README.spl-secure-boot @@ -0,0 +1,18 @@ +Overview of SPL verified boot on powerpc/mpc85xx & arm/layerscape platforms +=== + +Introduction + + +This document provides an overview of how SPL verified boot works on powerpc/ +mpc85xx & arm/layerscape platforms. + +Methodology +--- + +The SPL image is responsible for loading the next stage boot loader, which is +the main u-boot image. For secure boot process on these platforms ROM verifies +SPL image, so to continue chain of trust SPL image verifies U-boot image using +spl_validate_uboot(). This function uses QorIQ Trust Architecture header +(appended to U-boot image) to validate the U-boot binary just before passing +control to it. -- 1.8.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] does u-boot automatically determine valid command abbreviations?
i just want to confirm that u-boot *automatically* determines the valid prefix abbreviations for u-boot commands, correct? as in, there is no registration or configuration to do that, it's done automatically based on the commands that have been configured into u-boot and whether a command abbreviation represents a unique prefix for all configured commands, yes? i'm making that assumption based on this routine from common/command.c: /* find command table entry for a command */ cmd_tbl_t *find_cmd_tbl(const char *cmd, cmd_tbl_t *table, int table_len) { #ifdef CONFIG_CMDLINE cmd_tbl_t *cmdtp; cmd_tbl_t *cmdtp_temp = table; /* Init value */ const char *p; int len; int n_found = 0; if (!cmd) return NULL; /* * Some commands allow length modifiers (like "cp.b"); * compare command name only until first dot. */ len = ((p = strchr(cmd, '.')) == NULL) ? strlen (cmd) : (p - cmd); for (cmdtp = table; cmdtp != table + table_len; cmdtp++) { if (strncmp(cmd, cmdtp->name, len) == 0) { if (len == strlen(cmdtp->name)) return cmdtp; /* full match */ cmdtp_temp = cmdtp; /* abbreviated command ? */ n_found++; } } if (n_found == 1) { /* exactly one match */ return cmdtp_temp; } #endif /* CONFIG_CMDLINE */ return NULL;/* not found or ambiguous command */ } so am i reading that correctly that any unique prefix for configured commands will work? i ask only because, recently, someone made the claim in some u-boot instructions i'm reading: * Use “setenv” command instead of “set” for target boards. u-boot source is not yet modified to alias “setenv” to “set”. Other commands like “printenv” and “saveenv” can still be called as “print” and “save”. huh? why would someone have to "modify" the source to allow "set" to be a valid abbreviation for "setenv"? (aside: these instructions mix advice for both current and very old versions of u-boot, so maybe that claim is only for very old versions.) anyway, clarifiation would be appreciated. thank you kindly. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] crypto/fsl: Update blob cmd to accept 64bit addresses
Update blob cmd to accept 64bit source, key modifier and destination addresses. Also correct output result print format for fsl specific implementation of blob cmd. Signed-off-by: Sumit Garg --- cmd/blob.c| 2 +- drivers/crypto/fsl/fsl_blob.c | 13 ++--- 2 files changed, 11 insertions(+), 4 deletions(-) diff --git a/cmd/blob.c b/cmd/blob.c index ac8b268..bdd4cfd 100644 --- a/cmd/blob.c +++ b/cmd/blob.c @@ -54,7 +54,7 @@ __weak int blob_encap(u8 *key_mod, u8 *src, u8 *dst, u32 len) */ static int do_blob(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[]) { - uint32_t key_addr, src_addr, dst_addr, len; + ulong key_addr, src_addr, dst_addr, len; uint8_t *km_ptr, *src_ptr, *dst_ptr; int enc, ret = 0; diff --git a/drivers/crypto/fsl/fsl_blob.c b/drivers/crypto/fsl/fsl_blob.c index 8b25921..d24b8fc 100644 --- a/drivers/crypto/fsl/fsl_blob.c +++ b/drivers/crypto/fsl/fsl_blob.c @@ -18,7 +18,7 @@ int blob_decap(u8 *key_mod, u8 *src, u8 *dst, u32 len) int ret, i = 0; u32 *desc; - printf("\nDecapsulating data to form blob\n"); + printf("\nDecapsulating blob to get data\n"); desc = malloc(sizeof(int) * MAX_CAAM_DESCSIZE); if (!desc) { debug("Not enough memory for descriptor allocation\n"); @@ -27,12 +27,15 @@ int blob_decap(u8 *key_mod, u8 *src, u8 *dst, u32 len) inline_cnstr_jobdesc_blob_decap(desc, key_mod, src, dst, len); + debug("Descriptor dump:\n"); for (i = 0; i < 14; i++) - printf("%x\n", *(desc + i)); + debug("Word[%d]: %08x\n", i, *(desc + i)); ret = run_descriptor_jr(desc); if (ret) printf("Error in Decapsulation %d\n", ret); + else + printf("Decapsulation Success\n"); free(desc); return ret; @@ -51,12 +54,16 @@ int blob_encap(u8 *key_mod, u8 *src, u8 *dst, u32 len) } inline_cnstr_jobdesc_blob_encap(desc, key_mod, src, dst, len); + + debug("Descriptor dump:\n"); for (i = 0; i < 14; i++) - printf("%x\n", *(desc + i)); + debug("Word[%d]: %08x\n", i, *(desc + i)); ret = run_descriptor_jr(desc); if (ret) printf("Error in Encapsulation %d\n", ret); + else + printf("Encapsulation Success\n"); free(desc); return ret; -- 1.8.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] dm: clk: Remove simple version of clk_get_by_index()
Simple version of clk_get_by_index() added by: "dm: clk: Add a simple version of clk_get_by_index()" (sha1: a4b10c088c4f6ef2e2bba33e8cfea369bcbbce44) is not sufficient if you use multiple clocks in the system because clk->id is phandle id which for example fixed-clock is not able to handle. Use the same implementation as is used in full version. Signed-off-by: Michal Simek --- Diff for ZynqMP is 773 B based on buildman. --- drivers/clk/clk-uclass.c | 55 1 file changed, 18 insertions(+), 37 deletions(-) diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c index 6e4d67220a16..c6c5ba2f2511 100644 --- a/drivers/clk/clk-uclass.c +++ b/drivers/clk/clk-uclass.c @@ -21,30 +21,29 @@ static inline struct clk_ops *clk_dev_ops(struct udevice *dev) #if CONFIG_IS_ENABLED(OF_CONTROL) #ifdef CONFIG_SPL_BUILD -int clk_get_by_index(struct udevice *dev, int index, struct clk *clk) -{ - int ret; - u32 cell[2]; - - if (index != 0) - return -ENOSYS; - assert(clk); - ret = uclass_get_device(UCLASS_CLK, 0, &clk->dev); - if (ret) - return ret; - ret = fdtdec_get_int_array(gd->fdt_blob, dev->of_offset, "clocks", - cell, 2); - if (ret) - return ret; - clk->id = cell[1]; - return 0; -} - int clk_get_by_name(struct udevice *dev, const char *name, struct clk *clk) { return -ENOSYS; } #else +int clk_get_by_name(struct udevice *dev, const char *name, struct clk *clk) +{ + int index; + + debug("%s(dev=%p, name=%s, clk=%p)\n", __func__, dev, name, clk); + + index = fdt_find_string(gd->fdt_blob, dev->of_offset, "clock-names", + name); + if (index < 0) { + debug("fdt_find_string() failed: %d\n", index); + return index; + } + + return clk_get_by_index(dev, index, clk); +} +#endif +#endif + static int clk_of_xlate_default(struct clk *clk, struct fdtdec_phandle_args *args) { @@ -102,24 +101,6 @@ int clk_get_by_index(struct udevice *dev, int index, struct clk *clk) return clk_request(dev_clk, clk); } -int clk_get_by_name(struct udevice *dev, const char *name, struct clk *clk) -{ - int index; - - debug("%s(dev=%p, name=%s, clk=%p)\n", __func__, dev, name, clk); - - index = fdt_find_string(gd->fdt_blob, dev->of_offset, "clock-names", - name); - if (index < 0) { - debug("fdt_find_string() failed: %d\n", index); - return index; - } - - return clk_get_by_index(dev, index, clk); -} -#endif -#endif - int clk_request(struct udevice *dev, struct clk *clk) { struct clk_ops *ops = clk_dev_ops(dev); -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] Enable SECURE BOOT in SPL framework
> -Original Message- > From: Prabhakar Kushwaha > Sent: Thursday, July 14, 2016 5:00 PM > To: Sumit Garg ; u-boot@lists.denx.de > Cc: york sun ; Ruchika Gupta ; > s...@google.com; teddy.r...@gmail.com; dannenb...@ti.com; > tr...@konsulko.com; Sumit Garg > Subject: RE: [PATCH 0/3] Enable SECURE BOOT in SPL framework > > Dear Sumit, > > > -Original Message- > > From: Sumit Garg [mailto:sumit.g...@nxp.com] > > Sent: Thursday, July 14, 2016 9:58 PM > > To: u-boot@lists.denx.de > > Cc: york sun ; Ruchika Gupta > > ; Prabhakar Kushwaha > > ; s...@google.com; > teddy.r...@gmail.com; > > dannenb...@ti.com; tr...@konsulko.com; Sumit Garg > > > Subject: [PATCH 0/3] Enable SECURE BOOT in SPL framework > > > > Patch version history is missing from patch header. > If you get any comments then please incorporate in next patch-set. > > --prabhakar Yes you are right, I missed it. Sure I will incorporate it in next patch set if I get any comments. --Sumit ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] Enable SECURE BOOT in SPL framework
The patch-set does the following: 1. Enable SECURE BOOT framework in SPL for powerpc/mpc85xx and arm/layerscape platform. 2. Add NAND SECURE BOOT support for powerpc/mpc85xx T104x platform. Changes PATCH v5->PATCH v6: Added README for SECURE BOOT support in SPL framework. Also incorporated review comments regarding comment style. Also patch [1] has been accepted in upstream, so no dependency. Changes PATCH v4->PATCH v5: Check for def CONFIG_SPL_DM and ndef CONFIG_SPL_FRAMEWORK instead of def CONFIG_DM macro to include call to dm_init_and_scan(). As dm_init_and_scan() is called as part of common SPL framework, so no need to call it again but in case of powerpc platforms which currently do not use common SPL framework, so need to include this function call here. Changes PATCH v3->PATCH v4: Generic changes in lib, drivers, common Makefiles removed from this patchset. Rebased this patchset on top of patch [1], so this patchset is dependent on patch [1]. Changes PATCH v2->PATCH v3: Patches rebased Changes PATCH->PATCH v2: Patches rebased [1]https://patchwork.ozlabs.org/patch/627664/ Sumit Garg (3): powerpc/mpc85xx: SECURE BOOT- Enable chain of trust in SPL powerpc/mpc85xx: T104x: Add nand secure boot target doc: SPL: Add README for secure boot support arch/powerpc/cpu/mpc85xx/cpu_init.c| 4 +- arch/powerpc/cpu/mpc85xx/start.S | 12 -- arch/powerpc/cpu/mpc8xxx/fsl_pamu.c| 8 arch/powerpc/cpu/mpc8xxx/pamu_table.c | 8 arch/powerpc/include/asm/fsl_secure_boot.h | 41 ++- board/freescale/common/fsl_chain_of_trust.c| 56 ++ board/freescale/t104xrdb/t104x_pbi_sb.cfg | 38 + board/freescale/t104xrdb/tlb.c | 15 ++- configs/T1042RDB_PI_NAND_SECURE_BOOT_defconfig | 30 ++ doc/SPL/README.spl-secure-boot | 18 + drivers/crypto/fsl/jr.c| 17 drivers/mtd/nand/fsl_ifc_spl.c | 24 +++ include/configs/T104xRDB.h | 29 - include/fsl_validate.h | 7 14 files changed, 298 insertions(+), 9 deletions(-) create mode 100644 board/freescale/t104xrdb/t104x_pbi_sb.cfg create mode 100644 configs/T1042RDB_PI_NAND_SECURE_BOOT_defconfig create mode 100644 doc/SPL/README.spl-secure-boot -- 1.8.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to support ATF on u-boot
Hi Andre, On 07/13/2016 08:45 PM, Andre Przywara wrote: Hi, On 13/07/16 13:27, Andreas Färber wrote: Hi Kever, Am 20.06.2016 um 04:59 schrieb Kever Yang: I want to upstream a new SoC named RK3399 from Rockchip which is AARCH64/ARMv8, we need to support Arm Trust Firmware base on U-boot. Right now we are using a miniloader(just like SPL in U-boot) to load ATF/U-boot, and PC jump from miniloader to ATF and then to U-boot(with CPU change to EL2 mode or nsEL1), then U-boot load kernel/rootfs as usual. The ATF support for RK3399 has already upstream Could you give your opinion on how to support ATF on U-boot upstream? When I asked Simon Glass offline, he suggest if we can build ATF as part of the U-boot build process, perhaps with a script in U-boot tree, Perhaps something like: make rk3399_board_defconfig make ./scripts/build-atf-image rk3399_board ^^ new script I am not sure we should trigger an ATF build on building U-Boot. In my build process for the Pine64 I just point to the compiled binary and leave it up to the user to take care of compiling that. ATF builds are really easy and fast, for the Pine64 it's just: "make PLAT=sun50iw1p1 bl31" for instance and takes only a few seconds. I have send my patch set today, get bl31 from ATF is easy, still need some rockchip tools to do the package and load the image. In any case, a good README would help. I've started looking into RK3368 for my GeekBox, which raises a similar issue. Are you working on that as well or just RK3399? Personally I think that the approach the HiKey has taken is the best, i.e. decouple U-Boot from ATF and just supply a README for how to make it work with U-Boot as ATF payload. Interestingly ATF itself considers U-Boot a payload, as it provides its own bootstrapping parts which take a similar role as U-Boot's SPL. So the official ATF build process (at least for Juno) lets you specify the location of the U-Boot binary to be included in their FIP image. OTOH, some boards (like the Pine64) only use the runtime component of ATF, so including it in U-Boot makes more sense (see below). I guess this is similar for Rockchip? Yes for now, but I think there might be a secure OS in the future. Obviously it would help to integrate your loaderimage tool into mkimage. FWIW, I extended SPL's FIT loading to support loading multiple images. With this I was able to combine (non-SPL) U-Boot, ATF and multiple DTs into one FIT image and attach that to the SPL. I even managed to include a kernel and initrd in there, fwiw. I will post those patches soonish. Great, good news! Simon also want to enable the SPL support for ATF when we discuss this issue offline, so I think we can see this feature enabled very soon. Thanks, - Kever Cheers, Andre. Also, what is the difference between your trust_merger tool and ATF's fip_create / fiptool? Regards, Andreas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] ARM64: zynqmp: Enable CLK and SPL_CLK by default
Serial driver starts to use clk framework that's why enable it by default. Signed-off-by: Michal Simek --- arch/arm/Kconfig | 2 ++ configs/xilinx_zynqmp_ep_defconfig | 2 -- configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 2 -- configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 2 -- configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig | 2 -- configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig | 2 -- configs/xilinx_zynqmp_zcu102_defconfig | 2 -- configs/xilinx_zynqmp_zcu102_revB_defconfig | 2 -- 8 files changed, 2 insertions(+), 14 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 3237a74f7223..f01eadf69f5e 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -669,6 +669,8 @@ config ARCH_ZYNQMP select OF_CONTROL select DM_SERIAL select SUPPORT_SPL + select CLK + select SPL_CLK config TEGRA bool "NVIDIA Tegra" diff --git a/configs/xilinx_zynqmp_ep_defconfig b/configs/xilinx_zynqmp_ep_defconfig index fa380ef7f08f..b02ab0883543 100644 --- a/configs/xilinx_zynqmp_ep_defconfig +++ b/configs/xilinx_zynqmp_ep_defconfig @@ -42,8 +42,6 @@ CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_OF_EMBED=y CONFIG_NET_RANDOM_ETHADDR=y -CONFIG_CLK=y -CONFIG_SPL_CLK=y CONFIG_SYS_I2C_CADENCE=y CONFIG_DM_MMC=y CONFIG_ZYNQ_SDHCI=y diff --git a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig index 35226d6fd3c9..b11586211adb 100644 --- a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig +++ b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig @@ -33,8 +33,6 @@ CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_OF_EMBED=y CONFIG_NET_RANDOM_ETHADDR=y -CONFIG_CLK=y -CONFIG_SPL_CLK=y CONFIG_SYS_I2C_CADENCE=y CONFIG_DM_MMC=y CONFIG_ZYNQ_SDHCI=y diff --git a/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig b/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig index cc13179a1e5f..d1e8778dc4c8 100644 --- a/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig +++ b/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig @@ -33,8 +33,6 @@ CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_OF_EMBED=y CONFIG_NET_RANDOM_ETHADDR=y -CONFIG_CLK=y -CONFIG_SPL_CLK=y CONFIG_SYS_I2C_CADENCE=y CONFIG_DM_MMC=y CONFIG_NAND_ARASAN=y diff --git a/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig b/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig index 65703481ae31..4342e0546b0c 100644 --- a/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig +++ b/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig @@ -29,8 +29,6 @@ CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_OF_EMBED=y CONFIG_NET_RANDOM_ETHADDR=y -CONFIG_CLK=y -CONFIG_SPL_CLK=y CONFIG_SYS_I2C_CADENCE=y CONFIG_DM_MMC=y CONFIG_ZYNQ_SDHCI=y diff --git a/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig b/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig index e1fc8b0ee271..06c07c128a65 100644 --- a/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig +++ b/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig @@ -28,8 +28,6 @@ CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_OF_EMBED=y -CONFIG_CLK=y -CONFIG_SPL_CLK=y CONFIG_SYS_I2C_CADENCE=y CONFIG_DM_MMC=y CONFIG_ZYNQ_SDHCI=y diff --git a/configs/xilinx_zynqmp_zcu102_defconfig b/configs/xilinx_zynqmp_zcu102_defconfig index 28290296853d..140b80017295 100644 --- a/configs/xilinx_zynqmp_zcu102_defconfig +++ b/configs/xilinx_zynqmp_zcu102_defconfig @@ -32,8 +32,6 @@ CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_OF_EMBED=y CONFIG_NET_RANDOM_ETHADDR=y -CONFIG_CLK=y -CONFIG_SPL_CLK=y CONFIG_DM_MMC=y CONFIG_ZYNQ_SDHCI=y CONFIG_SPI_FLASH=y diff --git a/configs/xilinx_zynqmp_zcu102_revB_defconfig b/configs/xilinx_zynqmp_zcu102_revB_defconfig index 92633d6fcc98..727e22c267ab 100644 --- a/configs/xilinx_zynqmp_zcu102_revB_defconfig +++ b/configs/xilinx_zynqmp_zcu102_revB_defconfig @@ -32,8 +32,6 @@ CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_OF_EMBED=y CONFIG_NET_RANDOM_ETHADDR=y -CONFIG_CLK=y -CONFIG_SPL_CLK=y CONFIG_DM_MMC=y CONFIG_ZYNQ_SDHCI=y CONFIG_SPI_FLASH=y -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] serial: zynq: Read information about clock from DT
Read information about clock frequency from DT. Signed-off-by: Michal Simek --- drivers/serial/serial_zynq.c | 28 +++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/drivers/serial/serial_zynq.c b/drivers/serial/serial_zynq.c index 66d54e32ab38..4f6e7e442fa2 100644 --- a/drivers/serial/serial_zynq.c +++ b/drivers/serial/serial_zynq.c @@ -5,6 +5,7 @@ * SPDX-License-Identifier:GPL-2.0+ */ +#include #include #include #include @@ -108,8 +109,33 @@ static int _uart_zynq_serial_putc(struct uart_zynq *regs, const char c) int zynq_serial_setbrg(struct udevice *dev, int baudrate) { struct zynq_uart_priv *priv = dev_get_priv(dev); - unsigned long clock = get_uart_clk(0); + unsigned long clock; +#if defined(CONFIG_CLK) || defined(CONFIG_SPL_CLK) + int ret; + struct clk clk; + + ret = clk_get_by_index(dev, 0, &clk); + if (ret < 0) { + dev_err(dev, "failed to get clock\n"); + return ret; + } + + clock = clk_get_rate(&clk); + if (IS_ERR_VALUE(clock)) { + dev_err(dev, "failed to get rate\n"); + return clock; + } + debug("%s: CLK %ld\n", __func__, clock); + + ret = clk_enable(&clk); + if (ret && ret != -ENOSYS) { + dev_err(dev, "failed to enable clock\n"); + return ret; + } +#else + clock = get_uart_clk(0); +#endif _uart_zynq_serial_setbrg(priv->regs, clock, baudrate); return 0; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] ARM64: zynqmp: Remove get_uart_clk()
ZynqMP will use reading clock freq directly from DT. Signed-off-by: Michal Simek --- arch/arm/cpu/armv8/zynqmp/clk.c| 16 arch/arm/include/asm/arch-zynqmp/clk.h | 1 - 2 files changed, 17 deletions(-) diff --git a/arch/arm/cpu/armv8/zynqmp/clk.c b/arch/arm/cpu/armv8/zynqmp/clk.c index 690c72dd6683..f7e5ebfa6343 100644 --- a/arch/arm/cpu/armv8/zynqmp/clk.c +++ b/arch/arm/cpu/armv8/zynqmp/clk.c @@ -12,22 +12,6 @@ DECLARE_GLOBAL_DATA_PTR; -unsigned long get_uart_clk(int dev_id) -{ - u32 ver = zynqmp_get_silicon_version(); - - switch (ver) { - case ZYNQMP_CSU_VERSION_VELOCE: - return 48000; - case ZYNQMP_CSU_VERSION_EP108: - return 2500; - case ZYNQMP_CSU_VERSION_QEMU: - return 13300; - } - - return 1; -} - unsigned long zynqmp_get_system_timer_freq(void) { u32 ver = zynqmp_get_silicon_version(); diff --git a/arch/arm/include/asm/arch-zynqmp/clk.h b/arch/arm/include/asm/arch-zynqmp/clk.h index b18333d1ca25..bfd53b530584 100644 --- a/arch/arm/include/asm/arch-zynqmp/clk.h +++ b/arch/arm/include/asm/arch-zynqmp/clk.h @@ -8,7 +8,6 @@ #ifndef _ASM_ARCH_CLK_H_ #define _ASM_ARCH_CLK_H_ -unsigned long get_uart_clk(int dev_id); unsigned long zynqmp_get_system_timer_freq(void); #endif /* _ASM_ARCH_CLK_H_ */ -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] fs/fat/fatwrite: Local variable as buffer to store dir_slot entries
fill_dir_slot use get_contents_vfatname_block as a temporary buffer for constructing a list of dir_slot entries. To save the memory and providing correct type of memory for above usage, a local buffer with accurate size declaration is introduced. The local array size 640 is used because for long file name entry, each entry use 32 bytes, one entry can store up to 13 characters. The maximum number of entry possible is 20. So, total size is 32*20=640bytes. Signed-off-by: Genevieve Chan Signed-off-by: Tien Fong Chee Cc: Dinh Nguyen Cc: Dinh Nguyen Cc: ChinLiang Cc: Vagrant Cascadian Cc: Simon Glass Cc: Stephen Warren Cc: Benoît Thébaudeau --- fs/fat/fat_write.c |3 ++- include/fat.h |3 +++ 2 files changed, 5 insertions(+), 1 deletions(-) diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c index eb3a916..c1d48c5 100644 --- a/fs/fat/fat_write.c +++ b/fs/fat/fat_write.c @@ -323,7 +323,8 @@ static void flush_dir_table(fsdata *mydata, dir_entry **dentptr); static void fill_dir_slot(fsdata *mydata, dir_entry **dentptr, const char *l_name) { - dir_slot *slotptr = (dir_slot *)get_contents_vfatname_block; + __u8 temp_dir_slot_buffer[MAX_LFN_SLOT * sizeof(dir_slot)]; + dir_slot *slotptr = (dir_slot *)temp_dir_slot_buffer; __u8 counter = 0, checksum; int idx = 0, ret; char s_name[16]; diff --git a/include/fat.h b/include/fat.h index 9d053e6..90fdeba 100644 --- a/include/fat.h +++ b/include/fat.h @@ -33,6 +33,9 @@ #define FAT16BUFSIZE (FATBUFSIZE/2) #define FAT32BUFSIZE (FATBUFSIZE/4) +/* Maximum number of entry for long file name according to spec */ +#define MAX_LFN_SLOT 20 + /* Filesystem identifiers */ #define FAT12_SIGN "FAT12 " -- 1.7.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/9] mx7: add Colibri iMX7S/iMX7D support
From: Stefan Agner This patchset adds support for the Toradex i.MX 7Solo and 7Dual based computer on modules Colibri iMX7S/iMX7D. It also brings several smaller i.MX 7 related fixes/cleanups. Changes since v1: - Dropped Ricoh RN5T567 PMIC support (for now) - Use CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG for runtime variables - Convert USB OTG Power Pin Polarity to Kconfig - Use gpio_request in lcd_setup Stefan Agner (9): dm: imx: serial: Support DTE mode when using driver model usb: move CONFIG_USB_EHCI_MX7 to Kconfig usb: ehci-mx6: configure power polarity in usb_power_config usb: ehci-mx6: introduce config for high active power pin mx7: set soc environment according to exact SoC type mx7_common: Put display board info config into board file mx7_common: use Kconfig for ARMv7 non-secure mode imx_watchdog: add weak attribute to reset_cpu function colibri_imx7: add Colibri iMX7S/iMX7D module support arch/arm/cpu/armv7/mx7/Kconfig| 9 + arch/arm/cpu/armv7/mx7/soc.c | 14 + board/toradex/colibri_imx7/Kconfig| 12 + board/toradex/colibri_imx7/MAINTAINERS| 6 + board/toradex/colibri_imx7/Makefile | 6 + board/toradex/colibri_imx7/colibri_imx7.c | 420 ++ board/toradex/colibri_imx7/imximage.cfg | 150 +++ configs/colibri_imx7_defconfig| 40 +++ configs/mx7dsabresd_defconfig | 3 + configs/warp7_defconfig | 4 + drivers/serial/serial_mxc.c | 9 +- drivers/usb/host/Kconfig | 16 ++ drivers/usb/host/ehci-mx6.c | 14 +- drivers/watchdog/imx_watchdog.c | 2 +- include/configs/colibri_imx7.h| 248 ++ include/configs/mx7_common.h | 10 +- include/configs/mx7dsabresd.h | 4 +- include/configs/warp7.h | 4 +- include/dm/platform_data/serial_mxc.h | 1 + 19 files changed, 953 insertions(+), 19 deletions(-) create mode 100644 board/toradex/colibri_imx7/Kconfig create mode 100644 board/toradex/colibri_imx7/MAINTAINERS create mode 100644 board/toradex/colibri_imx7/Makefile create mode 100644 board/toradex/colibri_imx7/colibri_imx7.c create mode 100644 board/toradex/colibri_imx7/imximage.cfg create mode 100644 configs/colibri_imx7_defconfig create mode 100644 include/configs/colibri_imx7.h -- 2.9.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Ability to load linux kernel on rock2 RK3288
I did a little more on this, and talked to someone else here. It seems that my problem with loading the kernel including these patches is specific to our kernel and after applying a local patch we have, it appears to load fine. So this patchset gets me back to the same functionality in v2016.03. We're left with the puzzle of what's wrong on the RK3288 regarding caching and memory. Sandy Patterson On Mon, Jul 11, 2016 at 1:38 PM, Sandy Patterson wrote: > I wasn't able to load the linux kernel using a Rock2 board > using the latest master branch. The board hangs after it has > handed executing over to the kernel. I found that the latest release > that worked was v2016.03. > > I did some searching and I suspect the problem may be cache related. > > This patchset allows the kernel to start by reverting two problem > commits and disabling EFI_LOADER which I suspect rubs the caching the > wrong way. We also found that the 512M limit for fdt and initrd is now > 256M. > I'm not sure why this is. > > This still doesn't work 100%. I think it's not initializing the SD card > volages correctly, but at least the Kernel is loading. > > I also am not sure changing the caching for all armv7 is the right > answer. I wasn't too sure about the revert. I am not very familiar with > this low level stuff. > > Sandy Patterson > > > Sandy Patterson (4): > Revert "arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_CLEAN_INVAL_ALL) > with asm code" > Revert "arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_INVAL_ALL) with > asm code" > Disable CONFIG_EFI_LOADER for rock2. > RK3288 needs fdt and initrd below 256M now. > > arch/arm/cpu/armv7/Makefile | 2 +- > arch/arm/cpu/armv7/cache_v7.c| 135 ++- > arch/arm/cpu/armv7/cache_v7_asm.S| 154 > --- > arch/arm/mach-uniphier/arm32/lowlevel_init.S | 67 +++- > configs/rock2_defconfig | 1 + > include/configs/rk3288_common.h | 6 +- > 6 files changed, 201 insertions(+), 164 deletions(-) > delete mode 100644 arch/arm/cpu/armv7/cache_v7_asm.S > > -- > 1.9.1 > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] fs/fat/fat: Optimizes memory size with single global variable instead of 3
Single 64KB get_contents_vfatname_block global variable would be used for all FAT implementation instead of allocating additional two global variables which are get_denfromdir_block and do_fat_read_at_block. This implementation can help in saving up 128KB memory space. Signed-off-by: Tien Fong Chee Cc: Dinh Nguyen Cc: Dinh Nguyen Cc: ChinLiang Cc: Vagrant Cascadian Cc: Simon Glass Cc: Stephen Warren Cc: Benoît Thébaudeau --- fs/fat/fat.c |6 ++ 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/fs/fat/fat.c b/fs/fat/fat.c index 826bd85..5d1afe6 100644 --- a/fs/fat/fat.c +++ b/fs/fat/fat.c @@ -579,8 +579,7 @@ static __u8 mkcksum(const char name[8], const char ext[3]) * Get the directory entry associated with 'filename' from the directory * starting at 'startsect' */ -__u8 get_dentfromdir_block[MAX_CLUSTSIZE] - __aligned(ARCH_DMA_MINALIGN); +__u8 *get_dentfromdir_block = get_contents_vfatname_block; static dir_entry *get_dentfromdir(fsdata *mydata, int startsect, char *filename, dir_entry *retdent, @@ -811,8 +810,7 @@ exit: return ret; } -__u8 do_fat_read_at_block[MAX_CLUSTSIZE] - __aligned(ARCH_DMA_MINALIGN); +__u8 *do_fat_read_at_block = get_contents_vfatname_block; int do_fat_read_at(const char *filename, loff_t pos, void *buffer, loff_t maxsize, int dols, int dogetsize, loff_t *size) -- 1.7.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] fs/fat/fatwrite: Local variable as buffer to store dir_slot entries
fill_dir_slot use get_contents_vfatname_block as a temporary buffer for constructing a list of dir_slot entries. To save the memory and providing correct type of memory for above usage, a local buffer with accurate size declaration is introduced. The local array size 640 is used because for long file name entry, each entry use 32 bytes, one entry can store up to 13 characters. The maximum number of entry possible is 20. So, total size is 32*20=640bytes. Signed-off-by: Genevieve Chan Signed-off-by: Tien Fong Chee Cc: Dinh Nguyen Cc: Dinh Nguyen Cc: ChinLiang Cc: Vagrant Cascadian Cc: Simon Glass Cc: Stephen Warren Cc: Benoît Thébaudeau --- fs/fat/fat_write.c |3 ++- include/fat.h |3 +++ 2 files changed, 5 insertions(+), 1 deletions(-) diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c index eb3a916..c1d48c5 100644 --- a/fs/fat/fat_write.c +++ b/fs/fat/fat_write.c @@ -323,7 +323,8 @@ static void flush_dir_table(fsdata *mydata, dir_entry **dentptr); static void fill_dir_slot(fsdata *mydata, dir_entry **dentptr, const char *l_name) { - dir_slot *slotptr = (dir_slot *)get_contents_vfatname_block; + __u8 temp_dir_slot_buffer[MAX_LFN_SLOT * sizeof(dir_slot)]; + dir_slot *slotptr = (dir_slot *)temp_dir_slot_buffer; __u8 counter = 0, checksum; int idx = 0, ret; char s_name[16]; diff --git a/include/fat.h b/include/fat.h index 9d053e6..90fdeba 100644 --- a/include/fat.h +++ b/include/fat.h @@ -33,6 +33,9 @@ #define FAT16BUFSIZE (FATBUFSIZE/2) #define FAT32BUFSIZE (FATBUFSIZE/4) +/* Maximum number of entry for long file name according to spec */ +#define MAX_LFN_SLOT 20 + /* Filesystem identifiers */ #define FAT12_SIGN "FAT12 " -- 1.7.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] fs/fat/fat: Optimizes memory size with single global variable instead of 3
Dear Benoît, On Wed, 2016-07-13 at 12:56 +0200, Benoît Thébaudeau wrote: > Dear Tien Fong Chee, > > On Jul 13, 2016 at 11:01 AM, Tien Fong Chee wrote: > > Single 64KB get_contents_vfatname_block global variable would be > > used for > > all FAT implementation instead of allocating additional two global > > variables > > which are get_denfromdir_block and do_fat_read_at_block. This > > implementation > > can help in saving up 128KB memory space. > > > > Signed-off-by: Tien Fong Chee > > Cc: Dinh Nguyen > > Cc: Dinh Nguyen > > Cc: ChinLiang > > Cc: Vagrant Cascadian > > Cc: Simon Glass > > Cc: Stephen Warren > > Cc: Benoît Thébaudeau > > --- > > fs/fat/fat.c |6 ++ > > 1 files changed, 2 insertions(+), 4 deletions(-) > > > > diff --git a/fs/fat/fat.c b/fs/fat/fat.c > > index 826bd85..5d1afe6 100644 > > --- a/fs/fat/fat.c > > +++ b/fs/fat/fat.c > > @@ -579,8 +579,7 @@ static __u8 mkcksum(const char name[8], const > > char ext[3]) > > * Get the directory entry associated with 'filename' from the > > directory > > * starting at 'startsect' > > */ > > -__u8 get_dentfromdir_block[MAX_CLUSTSIZE] > > - __aligned(ARCH_DMA_MINALIGN); > > +__u8 *get_dentfromdir_block = get_contents_vfatname_block; > > > > static dir_entry *get_dentfromdir(fsdata *mydata, int startsect, > > char *filename, dir_entry > > *retdent, > > @@ -811,8 +810,7 @@ exit: > > return ret; > > } > > > > -__u8 do_fat_read_at_block[MAX_CLUSTSIZE] > > - __aligned(ARCH_DMA_MINALIGN); > > +__u8 *do_fat_read_at_block = get_contents_vfatname_block; > > > > int do_fat_read_at(const char *filename, loff_t pos, void *buffer, > >loff_t maxsize, int dols, int dogetsize, loff_t > > *size) > > This probably breaks at least fat_write.c, which uses: > memcpy(get_dentfromdir_block, get_contents_vfatname_block, > > Best regards, > Benoît With this patch, this line code "memcpy(get_dentfromdir_block, get_contents_vfatname_block," is not required anymore since both get_dentfromdir_block and get_contents_vfatname_block are sharing the same content and memory. So, this line code can be removed or leaving in there. However, there is only one place within fill_dir_slot_buffer function where it can corrupt the the global memory, and it is fixed by replacing with local buffer. This was sent out with another patch called "[PATCH 1/2] fs/fat/fatwrite: Local variable as buffer to store dir_slot entries". Overall, applying these two patches, a lot memory space can be saved and fitting into small OCRAM, but need to be very careful when modifying the code related to global memory. Best regards, Tien Fong ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/4] rockchip: rk3288: add fastboot support
Hi Ziyuan Xu, On 2016/7/14 14:52, Ziyuan Xu wrote: From: Xu Ziyuan Enable fastboot feature on rk3288. This path doesn't support the fastboot flash function command entirely. We will hit "cannot find partition" assertion without specified partition environment. Define gpt partition layout in specified board such as firefly-rk3288, then enjoy it! Signed-off-by: Ziyuan Xu --- Changes in v4: - Add fifo size for rk3288 - Get usb_phy's dt_node Changes in v3: - Achieve UOC_CON_OFFSET physical address from DT Changes in v2: - Achieve the regs_phy from DT - Update comments a little arch/arm/dts/rk3288.dtsi| 1 + arch/arm/mach-rockchip/board.c | 72 + include/configs/rk3288_common.h | 26 +++ 3 files changed, 99 insertions(+) diff --git a/arch/arm/dts/rk3288.dtsi b/arch/arm/dts/rk3288.dtsi index 3dab0fc..bcf051a 100644 --- a/arch/arm/dts/rk3288.dtsi +++ b/arch/arm/dts/rk3288.dtsi @@ -454,6 +454,7 @@ interrupts = ; clocks = <&cru HCLK_OTG0>; clock-names = "otg"; + dr_mode = "otg"; phys = <&usbphy0>; phy-names = "usb2-phy"; status = "disabled"; diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c index 816540e..ab41877 100644 --- a/arch/arm/mach-rockchip/board.c +++ b/arch/arm/mach-rockchip/board.c @@ -52,6 +52,78 @@ void lowlevel_init(void) { } +#if defined(CONFIG_USB_GADGET) && defined(CONFIG_USB_GADGET_DWC2_OTG) +#include +#include + +static struct dwc2_plat_otg_data rk3288_otg_data = { + .rx_fifo_sz = 512, + .np_tx_fifo_sz = 16, + .tx_fifo_sz = 512, +}; + rk3288 otg port total fifo size is only 0x3cc (972,this value is in terms of 32-bit words), read from GHWCFG3 register bit[31:16], it's smaller than the total fifo size you configured. +int board_usb_init(int index, enum usb_init_type init) +{ + int node, phy_node; + const char *mode; + bool matched = false; + const void *blob = gd->fdt_blob; + u32 grf_phy_offset; + + /* find the usb_otg node */ + node = fdt_node_offset_by_compatible(blob, -1, + "rockchip,rk3288-usb"); + + while (node > 0) { + mode = fdt_getprop(blob, node, "dr_mode", NULL); + if (mode && strcmp(mode, "otg") == 0) { + matched = true; + break; + } + + node = fdt_node_offset_by_compatible(blob, node, + "rockchip,rk3288-usb"); + } + if (!matched) { + debug("Not found usb_otg device\n"); + return -ENODEV; + } + rk3288_otg_data.regs_otg = fdtdec_get_addr(blob, node, "reg"); + + node = fdtdec_lookup_phandle(blob, node, "phys"); + if (node <= 0) { + debug("Not found usb phy device\n"); + return -ENODEV; + } + + phy_node = fdt_parent_offset(blob, node); + if (phy_node <= 0) { + debug("Not found usb phy device\n"); + return -ENODEV; + } + + rk3288_otg_data.phy_of_node = phy_node; + grf_phy_offset = fdtdec_get_addr(blob, node, "reg"); + + /* find the grf node */ + node = fdt_node_offset_by_compatible(blob, -1, + "rockchip,rk3288-grf"); + if (node <= 0) { + debug("Not found grf device\n"); + return -ENODEV; + } + rk3288_otg_data.regs_phy = grf_phy_offset + + fdtdec_get_addr(blob, node, "reg"); + + return dwc2_udc_probe(&rk3288_otg_data); +} + +int board_usb_cleanup(int index, enum usb_init_type init) +{ + return 0; +} +#endif + static int do_clock(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) { diff --git a/include/configs/rk3288_common.h b/include/configs/rk3288_common.h index 8adc26f..2040cdd 100644 --- a/include/configs/rk3288_common.h +++ b/include/configs/rk3288_common.h @@ -79,6 +79,32 @@ #define CONFIG_SPI #define CONFIG_SF_DEFAULT_SPEED 2000 +/* usb otg */ +#define CONFIG_USB_GADGET +#define CONFIG_USB_GADGET_DUALSPEED +#define CONFIG_USB_GADGET_DWC2_OTG +#define CONFIG_ROCKCHIP_USB2_PHY +#define CONFIG_USB_GADGET_VBUS_DRAW0 + +/* fastboot */ +#define CONFIG_CMD_FASTBOOT +#define CONFIG_USB_FUNCTION_FASTBOOT +#define CONFIG_FASTBOOT_FLASH +#define CONFIG_FASTBOOT_FLASH_MMC_DEV 1 /* eMMC */ +/* stroe safely fastboot buffer data to the middle of bank */ +#define CONFIG_FASTBOOT_BUF_ADDR (CONFIG_SYS_SDRAM_BASE \ + + SDRAM_BANK_SIZE / 2) +#define CONFIG_FASTBOOT_BUF_SIZE 0x0800 + +#define CONFIG_USB_GADGET_DOWNLOAD +#define CONFIG_G_DNL_MANUFACTURER "Rockchip" +#define CONFIG_G_DNL_VENDOR_NUM0x2207 +#defi
Re: [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs
Hi Tom, Simon, On Mon, Jun 27, 2016 at 09:19:15AM -0500, Andreas Dannenberg wrote: > This is an updated version of a patch series that introduces a generic way > to optionally post-process blobs as they get extracted by the SPL from the > u-boot.img FIT image, and uses this scheme to perform some authentication/ > decryption related processing on TI's high-secure (HS) SoC variants. For > additional background please see here [1]. just wanted to send a quick ping on this patch series. My optimistic understanding from the review and comments is that it should be in a reasonable state right now. Please let me know if there is anything else gating the acceptance other perhaps you wanting it to give more time for others to chime in. Thanks and Regards, Andreas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] best way to submit a patch for numerous, tree-wide typoz?
what is the best way to send in a patch for quite a number of tree-wide (ie., unrelated) typos throughout the source? almost all of them are innocuous -- either comments or in printed strings, so they *shouldn't* break anything. these days, i have a separate "typos" git branch where i just collect typos i run across, and keep rebasing it against "master" to stay up to date. and since this appears to be the u-boot merge window, i figure now is a good time to send it in. but, as i said, it's spread all over the tree, so is a single patch even a good idea, or should i try to break it into smaller, bite-size pieces? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs
On Thu, Jul 14, 2016 at 08:55:21AM -0500, Andreas Dannenberg wrote: > Hi Tom, Simon, > > On Mon, Jun 27, 2016 at 09:19:15AM -0500, Andreas Dannenberg wrote: > > This is an updated version of a patch series that introduces a generic way > > to optionally post-process blobs as they get extracted by the SPL from the > > u-boot.img FIT image, and uses this scheme to perform some authentication/ > > decryption related processing on TI's high-secure (HS) SoC variants. For > > additional background please see here [1]. > > just wanted to send a quick ping on this patch series. My optimistic > understanding from the review and comments is that it should be in a > reasonable state right now. Please let me know if there is anything else > gating the acceptance other perhaps you wanting it to give more time for > others to chime in. I'm giving people a little more time to chime in and will pick it up soon. Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs
Hi Andreas, On 14 July 2016 at 07:55, Andreas Dannenberg wrote: > Hi Tom, Simon, > > On Mon, Jun 27, 2016 at 09:19:15AM -0500, Andreas Dannenberg wrote: >> This is an updated version of a patch series that introduces a generic way >> to optionally post-process blobs as they get extracted by the SPL from the >> u-boot.img FIT image, and uses this scheme to perform some authentication/ >> decryption related processing on TI's high-secure (HS) SoC variants. For >> additional background please see here [1]. > > just wanted to send a quick ping on this patch series. My optimistic > understanding from the review and comments is that it should be in a > reasonable state right now. Please let me know if there is anything else > gating the acceptance other perhaps you wanting it to give more time for > others to chime in. It looks fine to me. I think it should go through Tom's tree, but I'm happy to pick it up via dm if needed. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/4] usb: dwc2: invalidate dcache before starting DMA
On 12 July 2016 at 19:06, Ziyuan Xu wrote: > > > On 2016年07月12日 20:59, Simon Glass wrote: >> >> Hi Ziyuan, >> >> On 6 July 2016 at 03:34, Ziyuan Xu wrote: >>> >>> From: Xu Ziyuan >>> >>> Invalidate dcache before starting the DMA to ensure coherency. In case >>> there are any dirty lines from the DMA buffer in the cache, subsequent >>> cache-line replacements may corrupt the buffer in memory while the DMA >>> is still going on. Cache-line replacement can happen if the CPU tries to >>> bring some other memory locations into the cache while the DMA is going >>> on. >>> >>> Signed-off-by: Ziyuan Xu >>> --- >>> >>> Changes in v3: >>> - New commit since v3 to fix the coherence issue between memory and >>> cache >>> >>> Changes in v2: None >>> >>> drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c >>> b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c >>> index 12f5c85..0d6d2fb 100644 >>> --- a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c >>> +++ b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c >>> @@ -110,6 +110,9 @@ static int setdma_rx(struct dwc2_ep *ep, struct >>> dwc2_request *req) >>> >>> ctrl = readl(®->out_endp[ep_num].doepctl); >>> >>> + invalidate_dcache_range((unsigned long) ep->dma_buf, >>> + (unsigned long) ep->dma_buf + ep->len); >> >> There is an invalidate in complete_rx() which is one of the callers >> for this function. It seems to me that we should not have this in two >> places. Why do we have this problem? Is it because the other calls to >> setdma_rx() don't invalidate? > > > Yup, invoke invalidate method twice during one complete transmission: > 1- invalidate in setdma_rx() in case of the write back cache, present from > cache-line replacement after DMA transmission complete. > i.e. > 1) dma_buf = "123456789abcd"; > 2) didn't invalidate in setdma_rx() > 3) DMA complete interrupt coming > 4) invalidate in complete_rx() > 5) read dma_buf, it's "123456789abcd" > > If invalidate in step 2, we will achieve correct data. > I think it's necessary to invalidate before starting DMA, and > doc/README.arm-caches describe details. > 2- invalidate in complete_rx(), cpu read the dma_buf from memory directly. > >> I think the invalidate should happen just before reading the data. Can >> you please check if the other invalidate is needed? Also see how it >> cache-aligns the end address. > > memalign(CONFIG_SYS_CACHELINE_SIZE, EP_BUFFER_SIZE); > cache-aligns: 64 bytes. > dma_buffer size: 4096 > > I had check cache-aligins and end address, rightful. > Furthermore, everything works fine with noncached_alloc(). > OK, thanks for the details. Can the invalidate in (4) be dropped? We should only need one invalidate. Reviewed-by: Simon Glass >> >>> + >>> writel((unsigned int) ep->dma_buf, >>> ®->out_endp[ep_num].doepdma); >>> writel(DOEPT_SIZ_PKT_CNT(pktcnt) | DOEPT_SIZ_XFER_SIZE(length), >>> ®->out_endp[ep_num].doeptsiz); >>> -- >>> 1.9.1 >>> >>> >> Regards, >> Simon >> >> >> > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs
Hi Tom, On Thu, Jul 14, 2016 at 10:57:34AM -0400, Tom Rini wrote: > On Thu, Jul 14, 2016 at 08:55:21AM -0500, Andreas Dannenberg wrote: > > Hi Tom, Simon, > > > > On Mon, Jun 27, 2016 at 09:19:15AM -0500, Andreas Dannenberg wrote: > > > This is an updated version of a patch series that introduces a generic way > > > to optionally post-process blobs as they get extracted by the SPL from the > > > u-boot.img FIT image, and uses this scheme to perform some authentication/ > > > decryption related processing on TI's high-secure (HS) SoC variants. For > > > additional background please see here [1]. > > > > just wanted to send a quick ping on this patch series. My optimistic > > understanding from the review and comments is that it should be in a > > reasonable state right now. Please let me know if there is anything else > > gating the acceptance other perhaps you wanting it to give more time for > > others to chime in. > > I'm giving people a little more time to chime in and will pick it up > soon. Thanks! Understood, that's what I thought since it touches rather "global" files. I also just re-applied the patch series to the latest 'master' branch and it still applies cleanly and the resulting MLO/u-boot.img images still perform as expected. Thanks and Regards, Andreas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/4] usb: dwc2: invalidate dcache before starting DMA
Hi Simon, On 2016年07月14日 23:00, Simon Glass wrote: On 12 July 2016 at 19:06, Ziyuan Xu wrote: On 2016年07月12日 20:59, Simon Glass wrote: Hi Ziyuan, On 6 July 2016 at 03:34, Ziyuan Xu wrote: From: Xu Ziyuan Invalidate dcache before starting the DMA to ensure coherency. In case there are any dirty lines from the DMA buffer in the cache, subsequent cache-line replacements may corrupt the buffer in memory while the DMA is still going on. Cache-line replacement can happen if the CPU tries to bring some other memory locations into the cache while the DMA is going on. Signed-off-by: Ziyuan Xu --- Changes in v3: - New commit since v3 to fix the coherence issue between memory and cache Changes in v2: None drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c index 12f5c85..0d6d2fb 100644 --- a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c +++ b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c @@ -110,6 +110,9 @@ static int setdma_rx(struct dwc2_ep *ep, struct dwc2_request *req) ctrl = readl(®->out_endp[ep_num].doepctl); + invalidate_dcache_range((unsigned long) ep->dma_buf, + (unsigned long) ep->dma_buf + ep->len); There is an invalidate in complete_rx() which is one of the callers for this function. It seems to me that we should not have this in two places. Why do we have this problem? Is it because the other calls to setdma_rx() don't invalidate? Yup, invoke invalidate method twice during one complete transmission: 1- invalidate in setdma_rx() in case of the write back cache, present from cache-line replacement after DMA transmission complete. i.e. 1) dma_buf = "123456789abcd"; 2) didn't invalidate in setdma_rx() 3) DMA complete interrupt coming 4) invalidate in complete_rx() 5) read dma_buf, it's "123456789abcd" If invalidate in step 2, we will achieve correct data. I think it's necessary to invalidate before starting DMA, and doc/README.arm-caches describe details. 2- invalidate in complete_rx(), cpu read the dma_buf from memory directly. I think the invalidate should happen just before reading the data. Can you please check if the other invalidate is needed? Also see how it cache-aligns the end address. memalign(CONFIG_SYS_CACHELINE_SIZE, EP_BUFFER_SIZE); cache-aligns: 64 bytes. dma_buffer size: 4096 I had check cache-aligins and end address, rightful. Furthermore, everything works fine with noncached_alloc(). OK, thanks for the details. Can the invalidate in (4) be dropped? We should only need one invalidate. We also need invalidate in after DMA transfer completed, because in some processors memory contents can spontaneouslycome to the cache due to speculative memory access by the CPU. If this happens with the DMA buffer while DMA is going on we have a coherency problem. Thanks for your review! Reviewed-by: Simon Glass + writel((unsigned int) ep->dma_buf, ®->out_endp[ep_num].doepdma); writel(DOEPT_SIZ_PKT_CNT(pktcnt) | DOEPT_SIZ_XFER_SIZE(length), ®->out_endp[ep_num].doeptsiz); -- 1.9.1 Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/4] ARM: imx: enhance support for the cm-fx6 module
Hi Christopher, Stefano, Whole series: Acked-by: Nikita Kiryanov On Tue, Jul 12, 2016 at 11:37:33PM +0200, christopher.spinr...@rwth-aachen.de wrote: > Hi, > > this is v2 of the series. To address the review comments of v1, v2 has an > addtional patch (2/4) touching include/fdt_support.h (thus, I added Simon > to the recipients). > > The original cover letter was (for a discussion cf. [2]): > > this series aims at enhancing support for the cm-fx6 module. In > particular, with respect to the upstream linux kernel. > > The first patch improves the default environment. It is non-functional > but makes it more convenient to adapt certain settings. > > The later two patches add mtd partition support for the on-board spi > flash chip. They pick up the discussion about specifying a default > partitioning in the device tree from here [1]. In short: adding the > default partitioning to the device tree was rejected by the linux/ > device tree community during mainlining large parts of the device tree. > It was proposed to implement the partition/mtd handling in u-boot. > On the other hand, it was argued that the flash chip becomes some > kind of "black-box" since there will be no partition labeling (in > particular, with old u-boot versions). > > IMHO defining the mtd partitioning has the following (dis-)advantages: > > Advantages: > - It is easier for the user to change the partitioning (e.g. to use > the unsued 1MB free space). > > - The flash ship is used entirely for u-boot. So it is quite natural > that u-boot manages it. Also, moving the partition table to it > allows us to change the layout in future versions of u-boot (almost > independently of the kernel - there are still non-device tree kernels). > > - U-Boot becomes the single point of definition for all device tree > kernels. Otherwise, each kernel (vendor vs. upstream + version) > would ship its own partitioning. Moreover, u-boot has to know > something about the partitioning, too, because it has to know where > the environment is saved. > > Disadvantages: > - Users of the upstream linux kernel have to use a recent u-boot > version to avoid the "black box" effect. A concrete impact is > that the update routine (described/proposed by CompuLab) does > not work out of the box with older u-boot versions. > > - Updating u-boot is something users might not want or miss to do. > > However, I think nowadays it is ok to demand a recent u-boot in > combination with the upstream kernel. The cm-fx6 wouldn't be > the first board doing so. Hence, I propose these patches here. > > Cheers, > Christopher > > [1] > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-June/434562.html > [2] http://lists.denx.de/pipermail/u-boot/2016-June/258546.html > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/4] rockchip: rk3288: add fastboot support
Hi William, On 2016年07月14日 19:06, William.wu wrote: Hi Ziyuan Xu, On 2016/7/14 14:52, Ziyuan Xu wrote: From: Xu Ziyuan Enable fastboot feature on rk3288. This path doesn't support the fastboot flash function command entirely. We will hit "cannot find partition" assertion without specified partition environment. Define gpt partition layout in specified board such as firefly-rk3288, then enjoy it! Signed-off-by: Ziyuan Xu --- Changes in v4: - Add fifo size for rk3288 - Get usb_phy's dt_node Changes in v3: - Achieve UOC_CON_OFFSET physical address from DT Changes in v2: - Achieve the regs_phy from DT - Update comments a little arch/arm/dts/rk3288.dtsi| 1 + arch/arm/mach-rockchip/board.c | 72 + include/configs/rk3288_common.h | 26 +++ 3 files changed, 99 insertions(+) diff --git a/arch/arm/dts/rk3288.dtsi b/arch/arm/dts/rk3288.dtsi index 3dab0fc..bcf051a 100644 --- a/arch/arm/dts/rk3288.dtsi +++ b/arch/arm/dts/rk3288.dtsi @@ -454,6 +454,7 @@ interrupts = ; clocks = <&cru HCLK_OTG0>; clock-names = "otg"; +dr_mode = "otg"; phys = <&usbphy0>; phy-names = "usb2-phy"; status = "disabled"; diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c index 816540e..ab41877 100644 --- a/arch/arm/mach-rockchip/board.c +++ b/arch/arm/mach-rockchip/board.c @@ -52,6 +52,78 @@ void lowlevel_init(void) { } +#if defined(CONFIG_USB_GADGET) && defined(CONFIG_USB_GADGET_DWC2_OTG) +#include +#include + +static struct dwc2_plat_otg_data rk3288_otg_data = { +.rx_fifo_sz= 512, +.np_tx_fifo_sz= 16, +.tx_fifo_sz= 512, +}; + rk3288 otg port total fifo size is only 0x3cc (972,this value is in terms of 32-bit words), read from GHWCFG3 register bit[31:16], it's smaller than the total fifo size you configured. I understand what you concern, but fifo size is in terms of 1 byte above, please take a look on v4 2/4(http://patchwork.ozlabs.org/patch/648237/).I remove >> 2 on the former code. Let me know if you still disagree with it. Thanks! +int board_usb_init(int index, enum usb_init_type init) +{ +int node, phy_node; +const char *mode; +bool matched = false; +const void *blob = gd->fdt_blob; +u32 grf_phy_offset; + +/* find the usb_otg node */ +node = fdt_node_offset_by_compatible(blob, -1, +"rockchip,rk3288-usb"); + +while (node > 0) { +mode = fdt_getprop(blob, node, "dr_mode", NULL); +if (mode && strcmp(mode, "otg") == 0) { +matched = true; +break; +} + +node = fdt_node_offset_by_compatible(blob, node, +"rockchip,rk3288-usb"); +} +if (!matched) { +debug("Not found usb_otg device\n"); +return -ENODEV; +} +rk3288_otg_data.regs_otg = fdtdec_get_addr(blob, node, "reg"); + +node = fdtdec_lookup_phandle(blob, node, "phys"); +if (node <= 0) { +debug("Not found usb phy device\n"); +return -ENODEV; +} + +phy_node = fdt_parent_offset(blob, node); +if (phy_node <= 0) { +debug("Not found usb phy device\n"); +return -ENODEV; +} + +rk3288_otg_data.phy_of_node = phy_node; +grf_phy_offset = fdtdec_get_addr(blob, node, "reg"); + +/* find the grf node */ +node = fdt_node_offset_by_compatible(blob, -1, +"rockchip,rk3288-grf"); +if (node <= 0) { +debug("Not found grf device\n"); +return -ENODEV; +} +rk3288_otg_data.regs_phy = grf_phy_offset + +fdtdec_get_addr(blob, node, "reg"); + +return dwc2_udc_probe(&rk3288_otg_data); +} + +int board_usb_cleanup(int index, enum usb_init_type init) +{ +return 0; +} +#endif + static int do_clock(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) { diff --git a/include/configs/rk3288_common.h b/include/configs/rk3288_common.h index 8adc26f..2040cdd 100644 --- a/include/configs/rk3288_common.h +++ b/include/configs/rk3288_common.h @@ -79,6 +79,32 @@ #define CONFIG_SPI #define CONFIG_SF_DEFAULT_SPEED 2000 +/* usb otg */ +#define CONFIG_USB_GADGET +#define CONFIG_USB_GADGET_DUALSPEED +#define CONFIG_USB_GADGET_DWC2_OTG +#define CONFIG_ROCKCHIP_USB2_PHY +#define CONFIG_USB_GADGET_VBUS_DRAW0 + +/* fastboot */ +#define CONFIG_CMD_FASTBOOT +#define CONFIG_USB_FUNCTION_FASTBOOT +#define CONFIG_FASTBOOT_FLASH +#define CONFIG_FASTBOOT_FLASH_MMC_DEV1/* eMMC */ +/* stroe safely fastboot buffer data to the middle of bank */ +#define CONFIG_FASTBOOT_BUF_ADDR(CONFIG_SYS_SDRAM_BASE \ ++ SDRAM_BANK_SIZE / 2) +#define CONFIG_FASTBOOT_BUF_SIZE0x0800 + +#define CONFIG_USB_GADGET_DOWNLOAD +#define CONFIG_G_DNL_MANUFACTURER"Rockchip" +#define CONFIG_G_DNL_VENDOR_NUM0x2207 +#define CONFIG_G_DNL_PRODUCT_NUM0x320a + +/* Enable gpt partit
[U-Boot] [PATCH v4.1 3/4] rockchip: rk3288: add fastboot support
From: Xu Ziyuan Enable fastboot feature on rk3288. This path doesn't support the fastboot flash function command entirely. We will hit "cannot find partition" assertion without specified partition environment. Define gpt partition layout in specified board such as firefly-rk3288, then enjoy it! Signed-off-by: Ziyuan Xu --- Changes in v4.1: - Revise tx_fifo_sz to 128 Changes in v4: - Add fifo size for rk3288 - Get usb_phy's dt_node Changes in v3: - Achieve UOC_CON_OFFSET physical address from DT Changes in v2: - Achieve the regs_phy from DT - Update comments a little arch/arm/dts/rk3288.dtsi| 1 + arch/arm/mach-rockchip/board.c | 72 + include/configs/rk3288_common.h | 26 +++ 3 files changed, 99 insertions(+) diff --git a/arch/arm/dts/rk3288.dtsi b/arch/arm/dts/rk3288.dtsi index 3dab0fc..bcf051a 100644 --- a/arch/arm/dts/rk3288.dtsi +++ b/arch/arm/dts/rk3288.dtsi @@ -454,6 +454,7 @@ interrupts = ; clocks = <&cru HCLK_OTG0>; clock-names = "otg"; + dr_mode = "otg"; phys = <&usbphy0>; phy-names = "usb2-phy"; status = "disabled"; diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c index 816540e..1458e80 100644 --- a/arch/arm/mach-rockchip/board.c +++ b/arch/arm/mach-rockchip/board.c @@ -52,6 +52,78 @@ void lowlevel_init(void) { } +#if defined(CONFIG_USB_GADGET) && defined(CONFIG_USB_GADGET_DWC2_OTG) +#include +#include + +static struct dwc2_plat_otg_data rk3288_otg_data = { + .rx_fifo_sz = 512, + .np_tx_fifo_sz = 16, + .tx_fifo_sz = 128, +}; + +int board_usb_init(int index, enum usb_init_type init) +{ + int node, phy_node; + const char *mode; + bool matched = false; + const void *blob = gd->fdt_blob; + u32 grf_phy_offset; + + /* find the usb_otg node */ + node = fdt_node_offset_by_compatible(blob, -1, + "rockchip,rk3288-usb"); + + while (node > 0) { + mode = fdt_getprop(blob, node, "dr_mode", NULL); + if (mode && strcmp(mode, "otg") == 0) { + matched = true; + break; + } + + node = fdt_node_offset_by_compatible(blob, node, + "rockchip,rk3288-usb"); + } + if (!matched) { + debug("Not found usb_otg device\n"); + return -ENODEV; + } + rk3288_otg_data.regs_otg = fdtdec_get_addr(blob, node, "reg"); + + node = fdtdec_lookup_phandle(blob, node, "phys"); + if (node <= 0) { + debug("Not found usb phy device\n"); + return -ENODEV; + } + + phy_node = fdt_parent_offset(blob, node); + if (phy_node <= 0) { + debug("Not found usb phy device\n"); + return -ENODEV; + } + + rk3288_otg_data.phy_of_node = phy_node; + grf_phy_offset = fdtdec_get_addr(blob, node, "reg"); + + /* find the grf node */ + node = fdt_node_offset_by_compatible(blob, -1, + "rockchip,rk3288-grf"); + if (node <= 0) { + debug("Not found grf device\n"); + return -ENODEV; + } + rk3288_otg_data.regs_phy = grf_phy_offset + + fdtdec_get_addr(blob, node, "reg"); + + return dwc2_udc_probe(&rk3288_otg_data); +} + +int board_usb_cleanup(int index, enum usb_init_type init) +{ + return 0; +} +#endif + static int do_clock(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) { diff --git a/include/configs/rk3288_common.h b/include/configs/rk3288_common.h index 8adc26f..2040cdd 100644 --- a/include/configs/rk3288_common.h +++ b/include/configs/rk3288_common.h @@ -79,6 +79,32 @@ #define CONFIG_SPI #define CONFIG_SF_DEFAULT_SPEED 2000 +/* usb otg */ +#define CONFIG_USB_GADGET +#define CONFIG_USB_GADGET_DUALSPEED +#define CONFIG_USB_GADGET_DWC2_OTG +#define CONFIG_ROCKCHIP_USB2_PHY +#define CONFIG_USB_GADGET_VBUS_DRAW0 + +/* fastboot */ +#define CONFIG_CMD_FASTBOOT +#define CONFIG_USB_FUNCTION_FASTBOOT +#define CONFIG_FASTBOOT_FLASH +#define CONFIG_FASTBOOT_FLASH_MMC_DEV 1 /* eMMC */ +/* stroe safely fastboot buffer data to the middle of bank */ +#define CONFIG_FASTBOOT_BUF_ADDR (CONFIG_SYS_SDRAM_BASE \ + + SDRAM_BANK_SIZE / 2) +#define CONFIG_FASTBOOT_BUF_SIZE 0x0800 + +#define CONFIG_USB_GADGET_DOWNLOAD +#define CONFIG_G_DNL_MANUFACTURER "Rockchip" +#define CONFIG_G_DNL_VENDOR_NUM0x2207 +#define CONFIG_G_DNL_PRODUCT_NUM 0x320a + +/* Enable gpt partition table */ +#define CONFIG_CMD_GPT +#define CONFIG_EFI_PARTITION + #ifndef CONFIG_SPL_BUILD #include -- 1.9.1 ___
[U-Boot] Please investigate T2080QDS U-Boot
Shengzhou, Can you investigate this message on T2080QDS (see log below)? Looks like some issue with NAND flash. It doesn't happen on T4240QDS. York U-Boot 2016.07-00067-gb8e5997 (Jul 14 2016 - 09:58:11 -0700) CPU0: T2080E, Version: 1.1, (0x85380011) Core: e6500, Version: 2.0, (0x80400120) Clock Configuration: CPU0:1800 MHz, CPU1:1800 MHz, CPU2:1800 MHz, CPU3:1800 MHz, CCB:600 MHz, DDR:933.333 MHz (1866.667 MT/s data rate) (Asynchronous), IFC:150 MHz FMAN1: 700 MHz QMAN: 300 MHz PME: 600 MHz L1:D-cache 32 KiB enabled I-cache 32 KiB enabled Reset Configuration Word (RCW): : 0c070012 0e00 0010: 6c2d0002 ec027000 c100 0020: 000307fc 0030: 0004 Board: T2080QDS, Sys ID: 0x28, Board Arch: V1, Board Version: A, boot from vBank4 FPGA: v11 (T1040QDS_2014_0318_1724), build 317 on Tue Mar 18 21:24:26 2014 SERDES Reference Clocks: SD1_CLK1=156.25MHZ, SD1_CLK2=100.00MHz SD2_CLK1=100.00MHz, SD2_CLK2=100.00MHz I2C: ready SPI: ready DRAM: Initializingusing SPD Detected UDIMM 6 GiB left unmapped 8 GiB (DDR3, 64-bit, CL=13, ECC on) DDR Chip-Select Interleaving Mode: CS0+CS1 Flash: 128 MiB L2:2 MiB enabled Corenet Platform Cache: 512 KiB enabled Using SERDES1 Protocol: 108 (0x6c) Using SERDES2 Protocol: 45 (0x2d) SRIO1: enabled SRIO2: enabled SEC0: RNG instantiated NAND: fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: clk: Remove simple version of clk_get_by_index()
On 07/14/2016 05:24 AM, Michal Simek wrote: Simple version of clk_get_by_index() added by: "dm: clk: Add a simple version of clk_get_by_index()" (sha1: a4b10c088c4f6ef2e2bba33e8cfea369bcbbce44) is not sufficient if you use multiple clocks in the system because clk->id is phandle id which for example fixed-clock is not able to handle. Use the same implementation as is used in full version. It took me a while to work out what failure case you were describing. It might be worth more explicitly pointing out that the existing simple implementation fails in any case where #clock-cells=<0>, or for larger #clock-cells, where the clock ID isn't in the first cell. To be honest, I'd be inclined to always include the real clk_get_by_name() in SPL builds too. If it's never called, the function will be dropped by the linker. If it is called, the dummy implementation probably actively causes failures that we should avoid by using the real implementation. I'm not sure why the original SPL-specific code existed, unless the 773 byte code increase you mention is actually problematic for some specific build? Signed-off-by: Michal Simek --- Diff for ZynqMP is 773 B based on buildman. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] does u-boot automatically determine valid command abbreviations?
Dear Robert, In message you wrote: > > i just want to confirm that u-boot *automatically* determines the > valid prefix abbreviations for u-boot commands, correct? as in, there > is no registration or configuration to do that, it's done > automatically based on the commands that have been configured into > u-boot and whether a command abbreviation represents a unique prefix > for all configured commands, yes? Correct. > i ask only because, recently, someone made the > claim in some u-boot instructions i'm reading: > > * Use “setenv” command instead of “set” for target boards. u-boot > source is not yet modified to alias “setenv” to “set”. Other > commands like “printenv” and “saveenv” can still be called as > “print” and “save”. > > huh? why would someone have to "modify" the source to allow "set" to > be a valid abbreviation for "setenv"? (aside: these instructions mix > advice for both current and very old versions of u-boot, so maybe that > claim is only for very old versions.) I cannot comment on the "modify" part, as it makes no sense to me. But I can comment on the background of the story: In the early days of U-Boot, actually for ages, it has been more or less standard habit to most experienced users to just write "set" instead of "setenv", as this was sufficient to uniquely identify that command. This was also used in a ton of scripts. Then, at some point, a new command (can't remember which one it was; eventually "setdcr"?) was added, and "set" was no longer a unique prefix, old habits and a ton of scripts broke. So habits had to be adjusted to type "sete" instead. So were scripts. The word was fine again. You guess what happened? Right - then the command "setexpr" was added, and again "sete" was no longer unique. Moral of the stroy: use "env set" ;-) Best regards, Wolfgang Denk -- 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 Work 8 hours, sleep 8 hours; but not the same 8 hours. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] does u-boot automatically determine valid command abbreviations?
On Thu, 14 Jul 2016, Wolfgang Denk wrote: > Dear Robert, ... snip ... > Then, at some point, a new command (can't remember which one it was; > eventually "setdcr"?) was added, and "set" was no longer a unique > prefix, old habits and a ton of scripts broke. > > So habits had to be adjusted to type "sete" instead. So were > scripts. The word was fine again. > > You guess what happened? Right - then the command "setexpr" was > added, and again "sete" was no longer unique. > > Moral of the stroy: use "env set" ;-) i'm embarrassed to admit i didn't even know the "env" command existed. learn something new every day. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] Enable SECURE BOOT in SPL framework
Dear Sumit, > -Original Message- > From: Sumit Garg [mailto:sumit.g...@nxp.com] > Sent: Thursday, July 14, 2016 9:58 PM > To: u-boot@lists.denx.de > Cc: york sun ; Ruchika Gupta ; > Prabhakar Kushwaha ; s...@google.com; > teddy.r...@gmail.com; dannenb...@ti.com; tr...@konsulko.com; Sumit Garg > > Subject: [PATCH 0/3] Enable SECURE BOOT in SPL framework > Patch version history is missing from patch header. If you get any comments then please incorporate in next patch-set. --prabhakar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] fs/fat/fatwrite: Local variable as buffer to store dir_slot entries
On 07/13/2016 03:01 AM, Tien Fong Chee wrote: fill_dir_slot use get_contents_vfatname_block as a temporary buffer for constructing a list of dir_slot entries. To save the memory and providing correct type of memory for above usage, a local buffer with accurate size declaration is introduced. The local array size 640 is used because for long file name entry, each entry use 32 bytes, one entry can store up to 13 characters. The maximum number of entry possible is 20. So, total size is 32*20=640bytes. I'm fairly sure this series is correct[1], although the FAT write code is a little hard to follow. [1] except in the face of disk read errors or corrupted data while parsing long filename entries, but the code already looks broken in the case of disk errors, and the corrupted data case probably isn't much worse now. diff --git a/include/fat.h b/include/fat.h +/* Maximum number of entry for long file name according to spec */ +#define MAX_LFN_SLOT 20 + /* Filesystem identifiers */ #define FAT12_SIGN"FAT12 " Why 2 blank lines there? Also, I'd suggest simply deleting get_contents_vfatname_block and renaming all references to it to use get_dentfromdir_block instead. That way, anyone reading the code in the future won't assume the two "block" variables refer to different memory, when in fact they share storage. Related, there's little point keeping the now-redundant memcpy() call at the end of get_long_file_name(): memcpy(get_dentfromdir_block, get_contents_vfatname_block, mydata->clust_size * mydata->sect_size); ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: start.S: Fix startup of dragonboard410c
On Tue, Jul 12, 2016 at 11:10:28PM +0100, André Przywara wrote: > On 12/07/16 21:15, Mateusz Kulikowski wrote: > > Hi Mateusz, > > > Commit d73718f3 breaks devices where: > > - There is EL2/EL3 firmware and > > - U-Boot starts in NS EL1 and > > - EL2/EL3 firmware didn't unlocked write-access to CPUECTLR_EL1. > > > > This patch makes that change opt-out configuration option, > > and disables it for dragonboard410c. > > thanks for bringing this up! > You are totally right, as this register isn't architecturally defined, > we should never set it without checking for a particular core. > Actually even that is not enough, as it's also access restricted - even > defaulting to RO - as you mentioned. > > So I am very much for a board specific _opt-in_ solution, also as ARM > Trusted Firmware takes care of the bit already, for instance. > > Mingkai Hu, can you say for which board/SoC/family the original patch > was needed for? Layerscape? OK, I'm going to revert the original patch here (and would recommend that distros that are picking up v2016.07 do the same). Thanks all! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] xtensa: add support for the xtensa processor architecture [1/2]
Hi Simon, On Tue, Jul 12, 2016 at 03:56:01PM -0600, Simon Glass wrote: > On 8 July 2016 at 09:41, Max Filippov wrote: > > From: Chris Zankel > > > > The Xtensa processor architecture is a configurable, extensible, > > and synthesizable 32-bit RISC processor core provided by Cadence. > > > > This is the first part of the basic architecture port with changes to > > common files. The 'arch/xtensa' directory, and boards and additional > > drivers will be in separate commits. > > > > Signed-off-by: Chris Zankel > > Signed-off-by: Max Filippov > > --- > > MAINTAINERS | 5 +++ > > MAKEALL | 6 +++ > > Makefile| 10 - > > cmd/bdinfo.c| 22 ++ > > common/board_f.c| 7 ++-- > > common/image.c | 1 + > > doc/README.xtensa | 100 > > > > examples/standalone/stubs.c | 47 + > > include/image.h | 1 + > > include/linux/stat.h| 4 +- > > 10 files changed, 197 insertions(+), 6 deletions(-) > > create mode 100644 doc/README.xtensa > > Reviewed-by: Simon Glass Thanks for the review. [...] > > diff --git a/MAKEALL b/MAKEALL > > index 7e42f10..e669aa9 100755 > > --- a/MAKEALL > > +++ b/MAKEALL > > This is deprecated and will be removed soon, so you don't need to > update it. See buildman. Ok. [...] > > diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c > > index 1c4bed9..076b950 100644 > > --- a/cmd/bdinfo.c > > +++ b/cmd/bdinfo.c > > @@ -563,6 +563,28 @@ int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, > > char * const argv[]) > > return 0; > > } > > > > +#elif defined(CONFIG_XTENSA) > > + > > +int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) > > +{ > > + bd_t *bd = gd->bd; > > + > > + print_num("boot_params",(ulong)bd->bi_boot_params); > > + print_num("memstart", (ulong)bd->bi_memstart); > > + print_lnum("memsize", (u64)bd->bi_memsize); > > + print_num("flashstart", (ulong)bd->bi_flashstart); > > + print_num("flashsize", (ulong)bd->bi_flashsize); > > + print_num("flashoffset",(ulong)bd->bi_flashoffset); > > + > > +#if defined(CONFIG_CMD_NET) > > + print_eth(0); > > + printf("ip_addr = %s\n", getenv("ipaddr")); > > +#endif > > + printf("baudrate= %d bps\n", gd->baudrate); > > It would be great if you could put this in a common function so that > other archs can call it. There is a lot of duplication in this file. Ok, let me look at that. [...] > > diff --git a/doc/README.xtensa b/doc/README.xtensa > > new file mode 100644 > > index 000..a461714 > > --- /dev/null > > +++ b/doc/README.xtensa [...] > > +The header files for one particular processor configuration are inside > > +a variant specific directory located in the arch/xtensa/include/asm > > variant-specific Ok. [...] > > +Windowed ABI presents unique difficulties with the approach based on > > +keeping global data pointer in dedicated register. Because the register > > +window rotates during a call, there is no register that is constantly > > +available for the gd pointer. Therefore, a global variable is used in > > +the same manner as i386. > > Or you could make gd a simple global variable. It you keep it in the > data section that should work. gd is a simple global variable on xtensa, I haven't actually checked what 'in the same manner as i386' means now. Will fix wording. [...] > > +U-Boot for Xtensa provides a special memory exception handler to prevent > > +hanging. The memory exception handler simply skips over the offending > > +instruction. It is called for all memory exception causes that might > > +be triggered by bad user input. While this is simplistic, it's better > > +than hanging in most cases, while keeping U-Boot small and simple. > > Wouldn't it be better to print an exception message? See for example > ARM's do_prefetch_abort(). I see that on ARM such errors result in panic and reset. Sure I can do that if that's the preferred way of dealing with such errors. -- Thanks. -- Max ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] common: cli_readline: Improve command line editing
On Wed, Jun 08, 2016 at 01:49:46PM +0100, James Byrne wrote: > This improves the cread_line() function so that it will correctly > process the 'Home', 'End', 'Delete' and arrow key escape sequences > produced by various terminal emulators. This makes command line editing > a more pleasant experience. > > The previous code only supported the cursor keys and the 'Home' key, and > only for certain terminal emulator configurations. This adds support for > the 'End and 'Delete' keys, and recognises a wider range of escape > sequences. For example, the left arrow key can be 'ESC O D' instead of > 'ESC [ D', and the 'Home' key can be 'ESC [ H', 'ESC O H', 'ESC 1 ~' or > 'ESC 7 ~', depending on what terminal emulator you use and how it is > configured. > > Signed-off-by: James Byrne This introduces a new warning: common/cli_readline.c: In function ‘cli_readline_into_buffer’: common/cli_readline.c:361:4: warning: ‘act’ may be used uninitialized in this function [-Wmaybe-uninitialized] -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] xtensa: add support for the xtensa processor architecture [2/2]
Hi Simon, On Tue, Jul 12, 2016 at 03:56:05PM -0600, Simon Glass wrote: [...] > Reviewed-by: Simon Glass > > Some comments below. > > > > > diff --git a/arch/Kconfig b/arch/Kconfig > > index 566f044..a36ac2f 100644 > > --- a/arch/Kconfig > > +++ b/arch/Kconfig > > @@ -83,6 +83,13 @@ config X86 > > select DM_SPI > > select DM_SPI_FLASH > > > > +config XTENSA > > + bool "Xtensa architecture" > > + select CREATE_ARCH_SYMLINK > > + select HAVE_GENERIC_BOARD > > This doesn't exist anymore as the migration is complete. > > > + select SUPPORT_OF_CONTROL > > + select SYS_GENERIC_BOARD > > Same here. Ok, will remove both. > > diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig > > new file mode 100644 > > index 000..e4e3625 > > --- /dev/null > > +++ b/arch/xtensa/Kconfig > > @@ -0,0 +1,26 @@ > > +menu "Xtensa architecture" > > + depends on XTENSA > > + > > +config SYS_ARCH > > + string > > + default "xtensa" > > + > > +config SYS_CPU > > + string "Xtensa Core Variant" > > + > > +choice > > + prompt "Target select" > > + > > + > > +endchoice > > + > > + > > +config HAVE_SYS_ASCDISP > > + bool > > + > > +config SYS_ASCDISP > > + bool "System LCD Display" > > + default y > > + depends on HAVE_SYS_ASCDISP > > Needs a help message. Should SYS_ASCDISP go in drivers/video? Ok, will move it there and write help message. [...] > > diff --git a/arch/xtensa/cpu/cpu.c b/arch/xtensa/cpu/cpu.c > > new file mode 100644 > > index 000..fb7f810 > > --- /dev/null > > +++ b/arch/xtensa/cpu/cpu.c > > @@ -0,0 +1,92 @@ > > +/* > > + * (C) Copyright 2008 - 2013 Tensilica Inc. > > + * (C) Copyright 2014 - 2016 Cadence Design Systems Inc. > > + * > > + * SPDX-License-Identifier:GPL-2.0+ > > + */ > > + > > +/* > > + * CPU specific code > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +DECLARE_GLOBAL_DATA_PTR; > > +gd_t *gd; > > + > > +#if defined(CONFIG_DISPLAY_CPUINFO) > > +/* > > + * Print information about the CPU. > > + */ > > + > > +int print_cpuinfo(void) > > +{ > > + char buf[120], mhz[8]; > > + uint32_t id0, id1; > > + > > + asm volatile ("rsr %0, 176\n" > > + "rsr %1, 208\n" > > + : "=r"(id0), "=r"(id1)); > > + > > + sprintf(buf, "CPU: Xtensa %s (id: %08x:%08x) at %s MHz\n", > > + XCHAL_CORE_ID, id0, id1, strmhz(mhz, gd->cpu_clk)); > > + puts(buf); > > + return 0; > > +} > > +#endif > > + > > +/* > > + * Implement the "reset" command. > > + * We need support from the board, though. > > + */ > > + > > +int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) > > +{ > > + board_reset(); > > + > > + /* Shouldn't come back! */ > > + printf("** RESET FAILED **\n"); > > All of this can be replaced by a call to sysreset_walk_halt() I think, > if you have a suitable UCLASS_RESET driver. Ok, let me look at that. > > + return 0; > > +} > > + > > +/* > > + * We currently run always with caches enabled when running for mmemory. > > Do you mean 'from memory'? Yes, will fix. [...] > > diff --git a/arch/xtensa/cpu/exceptions.c b/arch/xtensa/cpu/exceptions.c > > new file mode 100644 > > index 000..412ca5f > > --- /dev/null > > +++ b/arch/xtensa/cpu/exceptions.c > > @@ -0,0 +1,64 @@ > > +/* > > + * (C) Copyright 2008 - 2013 Tensilica Inc. > > + * (C) Copyright 2014 Cadence Design Systems Inc. > > + * > > + * SPDX-License-Identifier:GPL-2.0+ > > + */ > > + > > +/* > > + * Exception handling. > > + * We currently don't handle any exception and force a reset. > > + * (Note that alloca is a special case and handled in start.S) > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +typedef void (*handler_t)(struct pt_regs *); > > + > > +void xtensa_mem_exc_dummy(struct pt_regs *); > > + > > +void unhandled_exception(struct pt_regs *regs) > > +{ > > + display_printf("!! EXCCAUSE = %2ld", regs->exccause); > > + printf("Unhandled Exception: EXCCAUSE = %ld (pc %lx)\n", > > + regs->exccause, regs->pc); > > + udelay(1000); /* 10s to read display message */ > > Probably not needed? Up to you though. I'd either drop it together with ASCII display, or leave them both. [...] > > diff --git a/arch/xtensa/cpu/start.S b/arch/xtensa/cpu/start.S > > new file mode 100644 > > index 000..ac32efb > > --- /dev/null > > +++ b/arch/xtensa/cpu/start.S [...] > > +3: /* All code and initalized data segments have been copied. */ > > + > > + /* Setup PS, PS.WOE = 1, PS.EXCM = 0, PS.INTLEVEL = EXCM level. */ > > + > > +#if __XTENSA_CALL0_ABI__ > > + movia2, XCHAL_EXCM_LEVEL > > +#else > > + movia2, (1< > +#endif > > + wsr a2, PS > > + rsync > > + > > + /* Clear BSS */ > > + > >
Re: [U-Boot] [PATCH 3/8] xtensa: add core information for the dc232b processor
Hi Simon, On Tue, Jul 12, 2016 at 03:56:46PM -0600, Simon Glass wrote: > On 8 July 2016 at 09:42, Max Filippov wrote: > > From: Chris Zankel > > Commit message? Ok, will add. > > > > Signed-off-by: Chris Zankel > > Signed-off-by: Max Filippov > > --- > > arch/xtensa/include/asm/arch-dc232b/core.h| 422 > > ++ > > arch/xtensa/include/asm/arch-dc232b/tie-asm.h | 120 > > arch/xtensa/include/asm/arch-dc232b/tie.h | 129 > > 3 files changed, 671 insertions(+) > > create mode 100644 arch/xtensa/include/asm/arch-dc232b/core.h > > create mode 100644 arch/xtensa/include/asm/arch-dc232b/tie-asm.h > > create mode 100644 arch/xtensa/include/asm/arch-dc232b/tie.h > > Reviewed-by: Simon Glass > > nits below. > > > > > diff --git a/arch/xtensa/include/asm/arch-dc232b/core.h > > b/arch/xtensa/include/asm/arch-dc232b/core.h > > new file mode 100644 > > index 000..7fd1aee > > --- /dev/null > > +++ b/arch/xtensa/include/asm/arch-dc232b/core.h > > @@ -0,0 +1,422 @@ > > +/* > > + * Xtensa processor core configuration information. > > + * > > + * Copyright (c) 1999-2007 Tensilica Inc. > > + * > > + * SPDX-License-Identifier:GPL-2.0+ > > + */ > > + > > +#ifndef _XTENSA_CORE_CONFIGURATION_H > > +#define _XTENSA_CORE_CONFIGURATION_H > > + > > + > > +/ > > + Parameters Useful for Any Code, USER or PRIVILEGED > > + > > / > > + > > +/* > > + * Note: Macros of the form XCHAL_HAVE_*** have a value of 1 if the > > option is > > + * configured, and a value of 0 otherwise. These macros are always > > defined. > > + */ > > + > > + > > +/*-- > > + ISA > > + --*/ > > + > > +#define XCHAL_HAVE_BE 0 /* big-endian byte ordering > > */ > > +#define XCHAL_HAVE_WINDOWED1 /* windowed registers > > option */ > > +#define XCHAL_NUM_AREGS32 /* num of physical > > addr regs */ > > +#define XCHAL_NUM_AREGS_LOG2 5 /* log2(XCHAL_NUM_AREGS) */ > > +#define XCHAL_MAX_INSTRUCTION_SIZE 3 /* max instr bytes (3..8) */ > > +#define XCHAL_HAVE_DEBUG 1 /* debug option */ > > +#define XCHAL_HAVE_DENSITY 1 /* 16-bit instructions */ > > +#define XCHAL_HAVE_LOOPS 1 /* zero-overhead loops */ > > +#define XCHAL_HAVE_NSA 1 /* NSA/NSAU instructions */ > > +#define XCHAL_HAVE_MINMAX 1 /* MIN/MAX instructions */ > > +#define XCHAL_HAVE_SEXT1 /* SEXT instruction > > */ > > +#define XCHAL_HAVE_CLAMPS 1 /* CLAMPS instruction */ > > +#define XCHAL_HAVE_MUL16 1 /* MUL16S/MUL16U > > instructions */ > > +#define XCHAL_HAVE_MUL32 1 /* MULL instruction */ > > +#define XCHAL_HAVE_MUL32_HIGH 0 /* MULUH/MULSH instructions > > */ > > +#define XCHAL_HAVE_DIV32 1 /* QUOS/QUOU/REMS/REMU > > instructions */ > > +#define XCHAL_HAVE_L32R1 /* L32R instruction > > */ > > +#define XCHAL_HAVE_ABSOLUTE_LITERALS 1 /* non-PC-rel (extended) > > L32R */ > > +#define XCHAL_HAVE_CONST16 0 /* CONST16 instruction */ > > +#define XCHAL_HAVE_ADDX1 /* ADDX#/SUBX# > > instructions */ > > +#define XCHAL_HAVE_WIDE_BRANCHES 0 /* B*.W18 or B*.W15 instr's > > */ > > +#define XCHAL_HAVE_PREDICTED_BRANCHES 0 /* B[EQ/EQZ/NE/NEZ]T > > instr's */ > > +#define XCHAL_HAVE_CALL4AND12 1 /* (obsolete option) */ > > +#define XCHAL_HAVE_ABS 1 /* ABS instruction */ > > +/*#define XCHAL_HAVE_POPC 0*/ /* POPC instruction */ > > +/*#define XCHAL_HAVE_CRC 0*/ /* CRC instruction */ > > +#define XCHAL_HAVE_RELEASE_SYNC1 /* L32AI/S32RI > > instructions */ > > +#define XCHAL_HAVE_S32C1I 1 /* S32C1I instruction */ > > +#define XCHAL_HAVE_SPECULATION 0 /* speculation */ > > +#define XCHAL_HAVE_FULL_RESET 1 /* all regs/state reset */ > > +#define XCHAL_NUM_CONTEXTS 1 /* */ > > +#define XCHAL_NUM_MISC_REGS2 /* num of scratch regs > > (0..4) */ > > +#define XCHAL_HAVE_TAP_MASTER 0 /* JTAG TAP control instr's > > */ > > +#define XCHAL_HAVE_PRID1 /* processor ID > > register */ > > +#define XCHAL_HAVE_THREADPTR 1 /* THREADPTR register */ > > +#define XCHAL_HAVE_BOOLEANS0 /* boolean registers */ > > +#define XCHAL_HAVE_CP 1 /* CPEN
Re: [U-Boot] [PATCH 4/8] xtensa: add core information for the dc233c processor
Hi Simon, On Tue, Jul 12, 2016 at 03:56:49PM -0600, Simon Glass wrote: > On 8 July 2016 at 09:42, Max Filippov wrote: > > Signed-off-by: Max Filippov > > --- > > Commit message? Will add. > > arch/xtensa/include/asm/arch-dc233c/core.h| 475 > > ++ > > arch/xtensa/include/asm/arch-dc233c/tie-asm.h | 193 +++ > > arch/xtensa/include/asm/arch-dc233c/tie.h | 150 > > 3 files changed, 818 insertions(+) > > create mode 100644 arch/xtensa/include/asm/arch-dc233c/core.h > > create mode 100644 arch/xtensa/include/asm/arch-dc233c/tie-asm.h > > create mode 100644 arch/xtensa/include/asm/arch-dc233c/tie.h > > > > diff --git a/arch/xtensa/include/asm/arch-dc233c/core.h > > b/arch/xtensa/include/asm/arch-dc233c/core.h > > new file mode 100644 > > index 000..3a2e53b > > --- /dev/null > > +++ b/arch/xtensa/include/asm/arch-dc233c/core.h > > @@ -0,0 +1,475 @@ > > +/* > > + * xtensa/config/core-isa.h -- HAL definitions that are dependent on Xtensa > > + * processor CORE configuration > > + * > > + * See , which includes this file, for more details. > > + */ > > + > > +/* Xtensa processor core configuration information. > > + > > + Copyright (c) 1999-2010 Tensilica Inc. > > + > > + Permission is hereby granted, free of charge, to any person obtaining > > + a copy of this software and associated documentation files (the > > + "Software"), to deal in the Software without restriction, including > > + without limitation the rights to use, copy, modify, merge, publish, > > + distribute, sublicense, and/or sell copies of the Software, and to > > + permit persons to whom the Software is furnished to do so, subject to > > + the following conditions: > > + > > + The above copyright notice and this permission notice shall be included > > + in all copies or substantial portions of the Software. > > + > > + THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > > + EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > > + MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. > > + IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY > > + CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, > > + TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE > > + SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. */ > > */ on next line > > Can you use SPDX for this? Ok. > > + > > +#ifndef _XTENSA_CORE_CONFIGURATION_H > > +#define _XTENSA_CORE_CONFIGURATION_H > > + > > + > > +/ > > + Parameters Useful for Any Code, USER or PRIVILEGED > > + > > / > > Would be better without all this * and - stuff I think. Again: autogenerated, not really meant to be edited or even read by humans. Is it worth it? -- Thanks. -- Max ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/8] xtensa: add core information for the de212 processor
Hi Simon, On Tue, Jul 12, 2016 at 03:56:51PM -0600, Simon Glass wrote: > On 8 July 2016 at 09:42, Max Filippov wrote: > > Signed-off-by: Max Filippov > > --- > > arch/xtensa/include/asm/arch-de212/core.h| 594 > > +++ > > arch/xtensa/include/asm/arch-de212/tie-asm.h | 170 > > arch/xtensa/include/asm/arch-de212/tie.h | 136 ++ > > 3 files changed, 900 insertions(+) > > create mode 100644 arch/xtensa/include/asm/arch-de212/core.h > > create mode 100644 arch/xtensa/include/asm/arch-de212/tie-asm.h > > create mode 100644 arch/xtensa/include/asm/arch-de212/tie.h > > > > Reviewed-by: Simon Glass > > Same comments as previous patch - needs commit message and could do > without all the stuff. Ok. -- Thanks. -- Max ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv3] spi: Add support for N25Q016A
This commit adds support in the spi-nor driver for the N25Q016A, a 16Mbit SPI NOR flash from Micron. Signed-off-by: Moritz Fischer --- drivers/mtd/spi/sf_params.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c index 4f37e33..0ac7971 100644 --- a/drivers/mtd/spi/sf_params.c +++ b/drivers/mtd/spi/sf_params.c @@ -83,6 +83,7 @@ const struct spi_flash_params spi_flash_params_table[] = { {"M25P64", 0x202017, 0x0, 64 * 1024, 128, RD_NORM, 0}, {"M25P128",0x202018, 0x0, 256 * 1024,64, RD_NORM, 0}, {"M25PX64",0x207117, 0x0, 64 * 1024, 128, RD_NORM, SECT_4K}, + {"N25Q016A", 0x20bb15, 0x0, 64 * 1024,32, RD_NORM, SECT_4K}, {"N25Q32", 0x20ba16, 0x0, 64 * 1024,64, RD_FULL, WR_QPP | SECT_4K}, {"N25Q32A",0x20bb16, 0x0, 64 * 1024,64, RD_FULL, WR_QPP | SECT_4K}, {"N25Q64", 0x20ba17, 0x0, 64 * 1024, 128, RD_FULL, WR_QPP | SECT_4K}, -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2][RESEND] spi: Add support for N25Q016A
Jagan, thanks for your review! On Thu, Jul 14, 2016 at 12:01 AM, Jagan Teki wrote: > On 14 July 2016 at 00:00, Moritz Fischer wrote: >> Signed-off-by: Moritz Fischer >> --- >> drivers/mtd/spi/sf_params.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c >> index 4f37e33..8ae4eea 100644 >> --- a/drivers/mtd/spi/sf_params.c >> +++ b/drivers/mtd/spi/sf_params.c >> @@ -83,6 +83,7 @@ const struct spi_flash_params spi_flash_params_table[] = { >> {"M25P64", 0x202017, 0x0, 64 * 1024, 128, RD_NORM, >> 0}, >> {"M25P128",0x202018, 0x0, 256 * 1024,64, RD_NORM, >> 0}, >> {"M25PX64",0x207117, 0x0, 64 * 1024, 128, RD_NORM, >>SECT_4K}, >> + {"N25Q016A", 0x20bb15, 0x1000,64 * 1024,32, RD_NORM, >>SECT_4K}, > > Why would we need this ext_id (0x1000) here? I understand this is true > number for this part but it shouldn't require for probe or require > somewhere else? You're right. I just sent v3. Cheers, Moritz ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] net/ethoc: support private memory configurations
Hi Simon, On Tue, Jul 12, 2016 at 03:56:54PM -0600, Simon Glass wrote: > On 8 July 2016 at 09:42, Max Filippov wrote: > > From: Chris Zankel > > > > The 'ethoc' device could also be configured to have a private memory > > region instead of having access to the main memory. In that case, > > the packets must be copied into (transmit) or out of (receive) that > > memory. > > > > This behavior is configured by defining CONFIG_SYS_ETHOC_BUFFER_ADDR. > > Make sure to have enough memory for the configured buffers > > (one for transmit, and 'PKTBUFSRX' for receive) > > > > Signed-off-by: Chris Zankel > > Signed-off-by: Max Filippov > > --- > > drivers/net/ethoc.c | 21 + > > 1 file changed, 21 insertions(+) > > > > diff --git a/drivers/net/ethoc.c b/drivers/net/ethoc.c > > index edb3c80..ee7c01e 100644 > > --- a/drivers/net/ethoc.c > > +++ b/drivers/net/ethoc.c > > @@ -248,6 +248,9 @@ static int ethoc_init_ring(struct eth_device *dev) > > { > > struct ethoc *priv = (struct ethoc *)dev->priv; > > struct ethoc_bd bd; > > +#ifdef CONFIG_SYS_ETHOC_BUFFER_ADDR > > + unsigned long addr = CONFIG_SYS_ETHOC_BUFFER_ADDR; > > These should be in Kconfig. Ok. > Also you might find bouncebuf.c useful, although it allocates memory > with malloc(). The ethoc variant that we use in XTFPGA boards can only access packets in its dedicated packet memory and we don't have other DMA, so bouncebuf doesn't look useful for our case. -- Thanks. -- Max ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] fs/fat/fat: Optimizes memory size with single global variable instead of 3
Dear Tien Fong, On Thu, Jul 14, 2016 at 12:48 PM, Tien Fong Chee wrote: > Dear Benoît, > > On Wed, 2016-07-13 at 12:56 +0200, Benoît Thébaudeau wrote: >> Dear Tien Fong Chee, >> >> On Jul 13, 2016 at 11:01 AM, Tien Fong Chee wrote: >> > Single 64KB get_contents_vfatname_block global variable would be >> > used for >> > all FAT implementation instead of allocating additional two global >> > variables >> > which are get_denfromdir_block and do_fat_read_at_block. This >> > implementation >> > can help in saving up 128KB memory space. >> > >> > Signed-off-by: Tien Fong Chee >> > Cc: Dinh Nguyen >> > Cc: Dinh Nguyen >> > Cc: ChinLiang >> > Cc: Vagrant Cascadian >> > Cc: Simon Glass >> > Cc: Stephen Warren >> > Cc: Benoît Thébaudeau >> > --- >> > fs/fat/fat.c |6 ++ >> > 1 files changed, 2 insertions(+), 4 deletions(-) >> > >> > diff --git a/fs/fat/fat.c b/fs/fat/fat.c >> > index 826bd85..5d1afe6 100644 >> > --- a/fs/fat/fat.c >> > +++ b/fs/fat/fat.c >> > @@ -579,8 +579,7 @@ static __u8 mkcksum(const char name[8], const >> > char ext[3]) >> > * Get the directory entry associated with 'filename' from the >> > directory >> > * starting at 'startsect' >> > */ >> > -__u8 get_dentfromdir_block[MAX_CLUSTSIZE] >> > - __aligned(ARCH_DMA_MINALIGN); >> > +__u8 *get_dentfromdir_block = get_contents_vfatname_block; >> > >> > static dir_entry *get_dentfromdir(fsdata *mydata, int startsect, >> > char *filename, dir_entry >> > *retdent, >> > @@ -811,8 +810,7 @@ exit: >> > return ret; >> > } >> > >> > -__u8 do_fat_read_at_block[MAX_CLUSTSIZE] >> > - __aligned(ARCH_DMA_MINALIGN); >> > +__u8 *do_fat_read_at_block = get_contents_vfatname_block; >> > >> > int do_fat_read_at(const char *filename, loff_t pos, void *buffer, >> >loff_t maxsize, int dols, int dogetsize, loff_t >> > *size) >> >> This probably breaks at least fat_write.c, which uses: >> memcpy(get_dentfromdir_block, get_contents_vfatname_block, > > With this patch, this line code "memcpy(get_dentfromdir_block, > get_contents_vfatname_block," is not required anymore since both > get_dentfromdir_block and get_contents_vfatname_block are sharing the > same content and memory. So, this line code can be removed or leaving > in there. However, there is only one place within fill_dir_slot_buffer > function where it can corrupt the the global memory, and it is fixed by > replacing with local buffer. This was sent out with another patch > called "[PATCH 1/2] fs/fat/fatwrite: Local variable as buffer to store > dir_slot entries". Overall, applying these two patches, a lot memory > space can be saved and fitting into small OCRAM, but need to be very > careful when modifying the code related to global memory. I get the point, but I am a bit concerned because these changes make the code even more fragile and hard to maintain than it currently is. Perhaps it would be time to switch to FatFs as previously suggested. Here is its memory usage: http://elm-chan.org/fsw/ff/en/appnote.html#memory I've not checked in detail all the possible code paths, but for instance, if I look at get_vfatname(), it's called twice in fat.c, once with cluster and retdent pointing to somewhere in get_dentfromdir_block, and once with them pointing to somewhere in do_fat_read_at_block (through other pointer variables), while get_vfatname() may write to get_contents_vfatname_block. get_vfatname() then uses the original data pointed to by slotptr >= retdent. To make things worse, there is a memcpy (not memmove) from realdent, which may point to somewhere in get_contents_vfatname_block, to retdent. It's almost impossible for the involved buffer areas not to overlap in that case since a whole cluster is read. I also agree with Stephen's recommendations. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8] net/ethoc: don't advertise gigabit on the connected PHY
Hi Simon, On Tue, Jul 12, 2016 at 03:56:57PM -0600, Simon Glass wrote: > On 8 July 2016 at 09:42, Max Filippov wrote: > > Introduce MDIO communication routines. Scan MDIO bus at reset to find > > attached PHYs and see if they support gigabit speeds. If they do check > > their gigabit control register: if gigabit autonegotiation is enabled > > clear it and reset the PHY. > > > > This allows using OpenCores 10/100 MAC with gigabit PHY connected to > > gigabit network. > > > > Signed-off-by: Max Filippov > > --- > > drivers/net/ethoc.c | 76 > > + > > 1 file changed, 76 insertions(+) > > > > diff --git a/drivers/net/ethoc.c b/drivers/net/ethoc.c > > index ee7c01e..8f70c0c 100644 > > --- a/drivers/net/ethoc.c > > +++ b/drivers/net/ethoc.c > > @@ -290,6 +290,80 @@ static int ethoc_init_ring(struct eth_device *dev) > > return 0; > > } > > > > +#ifdef CONFIG_SYS_ETHOC_SETUP_PHY > > This should be in Kconfig. Ok, will add. -- Thanks. -- Max ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8] net/ethoc: don't advertise gigabit on the connected PHY
Hi Michal, On Wed, Jul 13, 2016 at 08:28:44AM +0200, Michal Simek wrote: > On 8.7.2016 17:42, Max Filippov wrote: > > Introduce MDIO communication routines. Scan MDIO bus at reset to find > > attached PHYs and see if they support gigabit speeds. If they do check > > their gigabit control register: if gigabit autonegotiation is enabled > > clear it and reset the PHY. > > > > This allows using OpenCores 10/100 MAC with gigabit PHY connected to > > gigabit network. > > > > Signed-off-by: Max Filippov > > This looks kind of weird. If you have standard phy and you do it > properly in the driver you shouldn't do it in this way. > We have the same stuff for emaclite where IP can work only at 10/100 and > it can be used with 1G phy. Just look at setting there. Ok, let me look at that. -- Thanks. -- Max ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] xtensa: add support for the 'xtfpga' evaluation board
Hi Michal, On Wed, Jul 13, 2016 at 08:35:37AM +0200, Michal Simek wrote: > On 8.7.2016 17:42, Max Filippov wrote: > > From: Chris Zankel > > > > The 'xtfpga' board is actually a set of FPGA evaluation boards that > > can be configured to run an Xtensa processor. > > > > - Avnet Xilinx LX60 > > - Avnet Xilinx LX110 > > - Avnet Xilinx LX200 > > - Xilinx ML605 > > - Xilinx KC705 > > > > These boards share the same components (open-ethernet, ns16550 serial, > > lcd display, flash, etc.). > > > > Signed-off-by: Chris Zankel > > Signed-off-by: Max Filippov > > --- [...] > > diff --git a/board/cadence/xtfpga/Kconfig b/board/cadence/xtfpga/Kconfig > > new file mode 100644 > > index 000..a7b65ef > > --- /dev/null > > +++ b/board/cadence/xtfpga/Kconfig > > @@ -0,0 +1,43 @@ > > +if TARGET_XTFPGA > > + > > +choice > > + prompt "XTFPGA board type select" > > + > > +config XTFPGA_LX60 > > + bool "Support Avnet LX60" > > + select HAVE_SYS_ASCDISP > > +config XTFPGA_LX110 > > + bool "Support Avnet LX110" > > + select HAVE_SYS_ASCDISP > > +config XTFPGA_LX200 > > + bool "Support Avnet LX200" > > +config XTFPGA_ML605 > > + bool "Support Xilinx ML605" > > + select HAVE_SYS_ASCDISP > > +config XTFPGA_KC705 > > + bool "Support Xilinx KC705" > > + select HAVE_SYS_ASCDISP > > + > > +endchoice > > + > > +config SYS_BOARD > > + string > > + default "xtfpga" > > + > > +config SYS_VENDOR > > + string > > + default "cadence" > > + > > +config SYS_CONFIG_NAME > > + string > > + default "xtfpga" > > +V > > +config BOARD_SDRAM_SIZE > > + hex > > + default 0x0400 if XTFPGA_LX60 > > + default 0x0300 if XTFPGA_LX110 > > + default 0x0600 if XTFPGA_LX200 > > + default 0x1800 if XTFPGA_ML605 > > + default 0x3800 if XTFPGA_KC705 > > You should read this directly from DTS files. > The same you have below in config. We have it this way so that we could calculate the location of monitor below the top of available RAM at compile time and use it in the linker script. Thus we avoid doing generic relocations at startup and just copy monitor to the address it was linked for. -- Thanks. -- Max ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] wandboard: move environment partition farther from u-boot.img
On Sat, Jul 9, 2016 at 9:42 AM, Alexey Brodkin wrote: > Recently I started to notice that u-boot.img built for Wandboard > by some toolchains becomes so large that it basically overlaps with > U-Boot environment area on SD-card. > > According to > http://wiki.wandboard.org/index.php/Boot-process#sdcard_boot_data_layout > Wandboard's SD-card layout is as follows: > -->8--- > == > 1. 0x Reserved For MBR > 2. 0x0200 512 Secondary Image Table (optional) > 3. 0x0400 1024uBoot Image (Starting From IVT) > 4. 0x0006 393216 start of uboot env (size:8k) > 5. 0x00062000 end of uboot env > 6. 0x0010 1048576 Linux kernel start > 7. 0x0076AC00 280 start of partition 1 > -->8--- > > So for U-Boot we have 383kB (392192 bytes). > > But in up to date U-Boot for Wandboard we build separately > a) SPL > b) u-boot.img > > which gives us a bit more detailed SD-card layout: > -->8--- > == > 1. 0x Reserved For MBR > 2. 0x0200 512 Secondary Image Table (optional) > 3. 0x0400 1024SPL > 4. 0x00011400 70656 u-boot.img > 5. 0x0006 393216 start of uboot env (size:8k) > 6. 0x00062000 end of uboot env > ... > -->8--- > > From that layout we may calculate amount of space reserved for > u-boot.img. It's just 315kb (322560 bytes). > > Now if I build U-Boot with Sourcery CodeBench ARM 2014.05 produced > u-boot.img is already more than we expected > (323840 bytes instead of "< 322560"): > -->8--- > ls -la u-boot.img > -rw-rw-r-- 1 user user 323840 Jul 5 07:38 u-boot.img > -->8--- > > Funny enough if I rebuild U-Boot with ARM toolchain available in > my Fedora 23 distro u-boot.img becomes a little bit smaller: > -->8--- > ls -la u-boot.img > -rw-rw-r-- 1 user user 322216 Jul 5 07:39 u-boot.img > -->8--- > > What's worse this problem might not affect people most of the time > because what happens people would just copy u-boot.img on SD-card and > live in happiness with it... well until somebody attempts to save > environment in U-Boot with "saveenv" command which will simply > overwrite the very end of u-boot.img. > That will lead to unusable SD-card until user dd u-boot.img on > SD-card again. > > I may foresee this issue in the future to become more visible once we > add more features in U-Boot for Wandboard or just existing code base > becomes bulkier and people will consistently get larger u-boot.img > files produced. > > IMHO there's an obvious solution for all that - just move U-Boot's env > to the very end of the gap between U-Boot and the first real partition > on the SD-card. This patch will follow > 8fb9eea5653796 ("mx6sabre_common: Fix U-Boot corruption after 'saveenv'"). > So env is still not in the very end of the gap (obviously 256kb is way > too much for U-Boot's env) but at least we have now the same > partitioning for i.MX6 boards. > > Signed-off-by: Alexey Brodkin > Cc: Fabio Estevam > Cc: Otavio Salvador > Cc: Peter Robinson > Cc: Tom Rini > Cc: Peter Korsgaard > Cc: Wolfgang Denk Acked-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] xtensa: add support for the 'xtfpga' evaluation board
Hi Simon, On Tue, Jul 12, 2016 at 03:57:00PM -0600, Simon Glass wrote: > On 8 July 2016 at 09:42, Max Filippov wrote: > > From: Chris Zankel > > > > The 'xtfpga' board is actually a set of FPGA evaluation boards that > > can be configured to run an Xtensa processor. > > > > - Avnet Xilinx LX60 > > - Avnet Xilinx LX110 > > - Avnet Xilinx LX200 > > - Xilinx ML605 > > - Xilinx KC705 > > > > These boards share the same components (open-ethernet, ns16550 serial, > > lcd display, flash, etc.). > > > > Signed-off-by: Chris Zankel > > Signed-off-by: Max Filippov > > --- [...] > > board/cadence/xtfpga/lcd.c | 88 ++ > > This should be in drivers/video and use driver model (UCLASS_VIDEO). Ok, will move. > > diff --git a/board/cadence/xtfpga/xtfpga.c b/board/cadence/xtfpga/xtfpga.c > > new file mode 100644 > > index 000..35de2f3 > > --- /dev/null > > +++ b/board/cadence/xtfpga/xtfpga.c > > @@ -0,0 +1,173 @@ > > +/* > > + * (C) Copyright 2007 - 2013 Tensilica Inc. > > + * (C) Copyright 2014 - 2016 Cadence Design Systems Inc. > > + * > > + * SPDX-License-Identifier:GPL-2.0+ > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include "lcd.h" > > + > > +DECLARE_GLOBAL_DATA_PTR; > > + > > +/* > > + * Check board idendity. > > + * (Print information about the board to stdout.) > > + */ > > + > > + > > +#if defined(CONFIG_XTFPGA_LX60) > > +const char *board = "XT_AV60"; > > +const char *description = "Avnet Xilinx LX60 FPGA Evaluation Board / "; > > +#elif defined(CONFIG_XTFPGA_LX110) > > +const char *board = "XT_AV110"; > > +const char *description = "Avnet Xilinx Virtex-5 LX110 Evaluation Kit / "; > > +#elif defined(CONFIG_XTFPGA_LX200) > > +const char *board = "XT_AV200"; > > +const char *description = "Avnet Xilinx Virtex-4 LX200 Evaluation Kit / "; > > +#elif defined(CONFIG_XTFPGA_ML605) > > +const char *board = "XT_ML605"; > > +const char *description = "Xilinx Virtex-6 FPGA ML605 Evaluation Kit / "; > > +#elif defined(CONFIG_XTFPGA_KC705) > > +const char *board = "XT_KC705"; > > +const char *description = "Xilinx Kintex-7 FPGA KC705 Evaluation Kit / "; > > +#else > > +const char *board = ""; > > +const char *description = ""; > > +#endif > > Shouldn't this go in the device tree? See show_board_info(). It can, but we don't have OF_CONTROL enabled in the default XTFPGA configuration. One reason is that otherwise it wouldn't fit into the LX60 board. > > + > > +int checkboard(void) > > +{ > > + printf("Board: %s: %sTensilica bitstream\n", board, description); > > + return 0; > > +} > > + > > +void dram_init_banksize(void) > > +{ > > + gd->bd->bi_memstart = PHYSADDR(CONFIG_SYS_SDRAM_BASE); > > + gd->bd->bi_memsize = CONFIG_SYS_SDRAM_SIZE; > > +} > > + > > +int board_postclk_init(void) > > +{ > > + /* > > +* Obtain CPU clock frequency from board and cache in global > > +* data structure (Hz). Return 0 on success (OK to continue), > > +* else non-zero (hang). > > +*/ > > + > > +#ifdef CONFIG_SYS_FPGAREG_FREQ > > + gd->cpu_clk = (*(volatile unsigned long *)CONFIG_SYS_FPGAREG_FREQ); > > +#else > > + /* early Tensilica bitstreams lack this reg, but most run at 50 MHz > > */ > > + gd->cpu_clk = 5000UL; > > +#endif > > + return 0; > > +} > > + > > +/* > > + * Miscellaneous early initializations. > > + * We use this hook to initialize the LCD display. > > + */ > > + > > +int misc_init_f(void) > > +{ > > +#ifdef CONFIG_SYS_ASCDISP > > + /* Initialize the LCD. */ > > + > > + lcd_init(); > > +#endif > > + display_printf("U-Boot starting", NULL); > > Should use driver-model. Ok. -- Thanks. -- Max ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] xtensa: add support for the xtensa processor architecture [2/2]
Hi Max, On 14 July 2016 at 16:58, Max Filippov wrote: > Hi Simon, > > On Tue, Jul 12, 2016 at 03:56:05PM -0600, Simon Glass wrote: > > [...] > >> Reviewed-by: Simon Glass >> >> Some comments below. >> > >> > diff --git a/arch/xtensa/cpu/start.S b/arch/xtensa/cpu/start.S >> > new file mode 100644 >> > index 000..ac32efb >> > --- /dev/null >> > +++ b/arch/xtensa/cpu/start.S > > [...] > >> > +3: /* All code and initalized data segments have been copied. */ >> > + >> > + /* Setup PS, PS.WOE = 1, PS.EXCM = 0, PS.INTLEVEL = EXCM level. */ >> > + >> > +#if __XTENSA_CALL0_ABI__ >> > + movia2, XCHAL_EXCM_LEVEL >> > +#else >> > + movia2, (1<> > +#endif >> > + wsr a2, PS >> > + rsync >> > + >> > + /* Clear BSS */ >> > + >> > + movia2, _bss_start >> > + movia3, _bss_end >> >> Can you please use board_init_f_init_reserve(), etc.? You can copy how >> ARM does things perhaps. This should not be in assembly. > > We use them, one screen below. > What exactly should not be in assembly? BSS zeroing? Yes. I misunderstood this sorry, but the idea is to have a little as possible in assembler. Perhaps you are already doing that, but if you can avoid clearing BSS here that would be better. > >> > + >> > + __loopt a2, a3, a4, 2 >> > + s32ia0, a2, 0 >> > + __endla a2, a3, 4 >> > + >> > + /* Writeback */ >> > + >> > + ___flush_dcache_all a2, a3 >> > + >> > +#ifdef __XTENSA_WINDOWED_ABI__ >> > + /* >> > +* In windowed ABI caller and call target need to be within the >> > same >> > +* gigabyte. Put the rest of the code into the text segment and >> > jump >> > +* there. >> > +*/ >> > + >> > + movia4, .Lboard_init_code >> > + jx a4 >> > + >> > + .text >> > + .align 4 >> > +.Lboard_init_code: >> > +#endif >> > + >> > + movia0, 0 >> > + movisp, (CONFIG_SYS_TEXT_ADDR - 16) & 0xfff0 >> > + >> > +#ifdef CONFIG_DEBUG_UART >> > + movia4, debug_uart_init >> > +#ifdef __XTENSA_CALL0_ABI__ >> > + callx0 a4 >> > +#else >> > + callx4 a4 >> > +#endif >> > +#endif >> > + >> > + movia4, board_init_f_alloc_reserve >> > + >> > +#ifdef __XTENSA_CALL0_ABI__ >> > + mov a2, sp >> > + callx0 a4 >> > + mov sp, a2 >> > +#else >> > + mov a6, sp >> > + callx4 a4 >> > + movsp sp, a6 >> > +#endif >> > + >> > + movia4, board_init_f_init_reserve >> > + >> > +#ifdef __XTENSA_CALL0_ABI__ >> > + callx0 a4 >> > +#else >> > + callx4 a4 >> > +#endif >> > + >> > +/* >> > +* Call board initialization routine (never returns). >> > +*/ >> > + >> > + movia4, board_init_f >> >> As above. This is using the old approach. > > I see the same sequence in the ARM's _main in arch/arm/lib/crt0.S: > > mov r0, sp > bl board_init_f_alloc_reserve > mov sp, r0 > /* set up gd here, outside any C code */ > mov r9, r0 > bl board_init_f_init_reserve > > mov r0, #0 > bl board_init_f > > What is 'the new approach' and how does it differ from the old? The old approach was to have it all in assembler. > > [...] > >> > + /* Does not return here. */ >> >> nit: drop periods before */ > > Ok. > > [...] > >> > +fast_alloca_exception: /* must be at _WindowUnderflow4 + 16 >> >> */ ? > > Oops, right. > > [...] > >> > diff --git a/arch/xtensa/cpu/u-boot.lds b/arch/xtensa/cpu/u-boot.lds >> > new file mode 100644 >> > index 000..853ae5a >> > --- /dev/null >> > +++ b/arch/xtensa/cpu/u-boot.lds >> > @@ -0,0 +1,116 @@ >> > +/* >> > + * (C) Copyright 2008 - 2013 Tensilica, Inc. >> > + * (C) Copyright 2014 - 2016 Cadence Design Systems Inc. >> > + * >> > + * SPDX-License-Identifier:GPL-2.0+ >> > + */ >> > + >> > +#include >> > +#include >> > +#include >> > +#include >> > +#include >> > + >> > +OUTPUT_ARCH(xtensa) >> > +ENTRY(_start) >> > + >> > +/* >> > + * U-Boot resets from SYSROM and unpacks itself from a ROM store to RAM. >> > + * The reset vector is usually near the base of SYSROM and has room >> > + * above it for the ROM store into which the rest of U-Boot is packed. >> > + * The ROM store also needs to be above any other vectors that are in ROM. >> > + * If a core has its vectors near the top of ROM, this must be edited. >> > + * >> > + * Note that to run C code out of ROM, the processor would have to support >> > + * 'relocatable' exception vectors and provide a scratch memory for the >> > + * initial stack. Not all Xtensa processor configurations support that, so >> > + * we can simplify the boot process and unpack U-Boot to RAM immediately. >> > + * This, however, requires that memory have been initialized throug some >> > + * other means (serial ROM, for example) or are initialized early >> > (requiring >> > + * an assembler function.
Re: [U-Boot] [PATCH 3/8] xtensa: add core information for the dc232b processor
Hi Max, On 14 July 2016 at 17:15, Max Filippov wrote: > Hi Simon, > > On Tue, Jul 12, 2016 at 03:56:46PM -0600, Simon Glass wrote: >> On 8 July 2016 at 09:42, Max Filippov wrote: >> > From: Chris Zankel >> >> Commit message? > > Ok, will add. > >> > >> > Signed-off-by: Chris Zankel >> > Signed-off-by: Max Filippov >> > --- >> > arch/xtensa/include/asm/arch-dc232b/core.h| 422 >> > ++ >> > arch/xtensa/include/asm/arch-dc232b/tie-asm.h | 120 >> > arch/xtensa/include/asm/arch-dc232b/tie.h | 129 >> > 3 files changed, 671 insertions(+) >> > create mode 100644 arch/xtensa/include/asm/arch-dc232b/core.h >> > create mode 100644 arch/xtensa/include/asm/arch-dc232b/tie-asm.h >> > create mode 100644 arch/xtensa/include/asm/arch-dc232b/tie.h >> >> Reviewed-by: Simon Glass >> >> nits below. >> >> > +/*-- >> >> Do we need all these lines and stars? > > These files are autogenerated, so I tried to avoid editing them. > Sure I can remove these lines and start if absolutely necessary. If it is auto-generated, can you add a comment to that effect (including the tool that generated), or better yet, update the tool to emit that comment? Do you expect it to be regenerated later, or will edits be done as normal patches? Is there a source file and tool that you could submit instead, so that the build system creates the auto-generated source? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] net/ethoc: support private memory configurations
Hi Max, On 14 July 2016 at 17:34, Max Filippov wrote: > Hi Simon, > > On Tue, Jul 12, 2016 at 03:56:54PM -0600, Simon Glass wrote: >> On 8 July 2016 at 09:42, Max Filippov wrote: >> > From: Chris Zankel >> > >> > The 'ethoc' device could also be configured to have a private memory >> > region instead of having access to the main memory. In that case, >> > the packets must be copied into (transmit) or out of (receive) that >> > memory. >> > >> > This behavior is configured by defining CONFIG_SYS_ETHOC_BUFFER_ADDR. >> > Make sure to have enough memory for the configured buffers >> > (one for transmit, and 'PKTBUFSRX' for receive) >> > >> > Signed-off-by: Chris Zankel >> > Signed-off-by: Max Filippov >> > --- >> > drivers/net/ethoc.c | 21 + >> > 1 file changed, 21 insertions(+) >> > >> > diff --git a/drivers/net/ethoc.c b/drivers/net/ethoc.c >> > index edb3c80..ee7c01e 100644 >> > --- a/drivers/net/ethoc.c >> > +++ b/drivers/net/ethoc.c >> > @@ -248,6 +248,9 @@ static int ethoc_init_ring(struct eth_device *dev) >> > { >> > struct ethoc *priv = (struct ethoc *)dev->priv; >> > struct ethoc_bd bd; >> > +#ifdef CONFIG_SYS_ETHOC_BUFFER_ADDR >> > + unsigned long addr = CONFIG_SYS_ETHOC_BUFFER_ADDR; >> >> These should be in Kconfig. > > Ok. > >> Also you might find bouncebuf.c useful, although it allocates memory >> with malloc(). > > The ethoc variant that we use in XTFPGA boards can only access packets > in its dedicated packet memory and we don't have other DMA, so bouncebuf > doesn't look useful for our case. OK. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: mmc: Add the function for getting current device number
On 07/13/2016 06:57 AM, Simon Glass wrote: > Hi Jaehoon, > > On 4 July 2016 at 01:40, Jaehoon Chung wrote: >> get_mmc_num can be returned 0. Then if you use the "mmcinfo" command, it >> can't print the mmc information. >> If get_mmc_num is 0, it means that there is not mmc device. >> So it added the get_mmc_curr_num() function for getting current device >> number(index). And get_mmc_num() is returned the number of device. >> >> This patch is only tested with mmc block..so i didn't touch the >> blk-uclass.c. >> >> Signed-off-by: Jaehoon Chung >> --- >> drivers/mmc/mmc-uclass.c | 12 +++- >> 1 file changed, 11 insertions(+), 1 deletion(-) >> > > Can you please add a function comment for get_mmc_num() in the header > file? It's not really clear what is supposed to return. > > Also there are two implementations - one in the uclass and one in > mmc_legacy.c. If the latter does not need changing, can you please add > a comment in your commit as to why? Ok, I will add the explanation in more detail. > > Can you repeat this problem with sandbox? I will check this problem with sandbox. After that, i will share.. > >> diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c >> index 38ced41..a3f2463 100644 >> --- a/drivers/mmc/mmc-uclass.c >> +++ b/drivers/mmc/mmc-uclass.c >> @@ -111,6 +111,16 @@ struct mmc *find_mmc_device(int dev_num) >> >> int get_mmc_num(void) >> { >> + int devnum = blk_find_max_devnum(IF_TYPE_MMC); >> + >> + if (devnum < 0) >> + return devnum; >> + >> + return devnum + 1; >> +} >> + >> +static int get_mmc_curr_num(void) >> +{ >> return max(blk_find_max_devnum(IF_TYPE_MMC), 0); >> } >> >> @@ -118,7 +128,7 @@ int mmc_get_next_devnum(void) >> { >> int ret; >> >> - ret = get_mmc_num(); >> + ret = get_mmc_curr_num(); >> if (ret < 0) >> return ret; > > But get_mmc_curr_num() cannot return < 0 You're right. It's my mistake. Best Regards, Jaehoon Chung > >> >> -- >> 1.9.1 >> > > Regards, > Simon > > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mkimage: rockchip: add suport for rk33 serial
Hi Andreas, On 07/14/2016 12:26 PM, Andreas Färber wrote: Am 14.07.2016 um 05:51 schrieb Kever Yang: Add support for rockchip rk33 series Soc like rk3368 and rk3399 Signed-off-by: Kever Yang --- tools/rkcommon.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/rkcommon.c b/tools/rkcommon.c index 72621fd..9ec7eb2 100644 --- a/tools/rkcommon.c +++ b/tools/rkcommon.c @@ -56,6 +56,7 @@ struct spl_info { static struct spl_info spl_infos[] = { { "rk3036", "RK30", 0x1000 }, { "rk3288", "RK32", 0x8000 }, + { "rk33xx", "RK33", 0x2 }, Is xx really future-safe or would it be better to have two lines with the exact model names as before? Two information here, one is TAG 'RK33' which used by bootrom, they are the same for rk33 series SoC; another is SPL size which is depend on IRAM size, this is different for different SoC, rk3368 is smaller than rk3399. I will use rk3399 first, but we may need to optimize the size limit later for the tool, because the image in Rockchip IDB format could be two parts, one like SPL should be run in IRAM, and another one like U-boot can be run in DRAM, the tool only consider the SPL part now. Thanks, - Kever Cheers, Andreas }; static unsigned char rc4_key[16] = { ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please investigate T2080QDS U-Boot
Hi York, I am just curious about this issue. Was it coming earlier on this board or started coming now. I guess you can still access NAND flash on the board. Regards, Prabhakar > -Original Message- > From: york sun > Sent: Thursday, July 14, 2016 10:33 PM > To: Shengzhou Liu > Cc: Prabhakar Kushwaha ; u- > b...@lists.denx.de > Subject: Please investigate T2080QDS U-Boot > > Shengzhou, > > Can you investigate this message on T2080QDS (see log below)? Looks like > some issue with NAND flash. It doesn't happen on T4240QDS. > > York > > U-Boot 2016.07-00067-gb8e5997 (Jul 14 2016 - 09:58:11 -0700) > > CPU0: T2080E, Version: 1.1, (0x85380011) > Core: e6500, Version: 2.0, (0x80400120) > Clock Configuration: > CPU0:1800 MHz, CPU1:1800 MHz, CPU2:1800 MHz, CPU3:1800 MHz, > CCB:600 MHz, > DDR:933.333 MHz (1866.667 MT/s data rate) (Asynchronous), > IFC:150 MHz > FMAN1: 700 MHz > QMAN: 300 MHz > PME: 600 MHz > L1:D-cache 32 KiB enabled > I-cache 32 KiB enabled > Reset Configuration Word (RCW): > : 0c070012 0e00 > 0010: 6c2d0002 ec027000 c100 > 0020: 000307fc > 0030: 0004 > Board: T2080QDS, Sys ID: 0x28, Board Arch: V1, Board Version: A, boot > from vBank4 > FPGA: v11 (T1040QDS_2014_0318_1724), build 317 on Tue Mar 18 21:24:26 > 2014 > SERDES Reference Clocks: > SD1_CLK1=156.25MHZ, SD1_CLK2=100.00MHz > SD2_CLK1=100.00MHz, SD2_CLK2=100.00MHz > I2C: ready > SPI: ready > DRAM: Initializingusing SPD > Detected UDIMM > 6 GiB left unmapped > 8 GiB (DDR3, 64-bit, CL=13, ECC on) > DDR Chip-Select Interleaving Mode: CS0+CS1 > Flash: 128 MiB > L2:2 MiB enabled > Corenet Platform Cache: 512 KiB enabled > Using SERDES1 Protocol: 108 (0x6c) > Using SERDES2 Protocol: 45 (0x2d) > SRIO1: enabled > SRIO2: enabled > SEC0: RNG instantiated > NAND: fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please investigate T2080QDS U-Boot
I went back to last several releases and saw the same. Do we have it in SDK U-Boot? York Original Message From: Prabhakar Kushwaha Sent: Thursday, July 14, 2016 06:40 PM To: york sun ,Shengzhou Liu Subject: RE: Please investigate T2080QDS U-Boot CC: u-boot@lists.denx.de Hi York, I am just curious about this issue. Was it coming earlier on this board or started coming now. I guess you can still access NAND flash on the board. Regards, Prabhakar > -Original Message- > From: york sun > Sent: Thursday, July 14, 2016 10:33 PM > To: Shengzhou Liu > Cc: Prabhakar Kushwaha ; u- > b...@lists.denx.de > Subject: Please investigate T2080QDS U-Boot > > Shengzhou, > > Can you investigate this message on T2080QDS (see log below)? Looks like > some issue with NAND flash. It doesn't happen on T4240QDS. > > York > > U-Boot 2016.07-00067-gb8e5997 (Jul 14 2016 - 09:58:11 -0700) > > CPU0: T2080E, Version: 1.1, (0x85380011) > Core: e6500, Version: 2.0, (0x80400120) > Clock Configuration: > CPU0:1800 MHz, CPU1:1800 MHz, CPU2:1800 MHz, CPU3:1800 MHz, > CCB:600 MHz, > DDR:933.333 MHz (1866.667 MT/s data rate) (Asynchronous), > IFC:150 MHz > FMAN1: 700 MHz > QMAN: 300 MHz > PME: 600 MHz > L1:D-cache 32 KiB enabled > I-cache 32 KiB enabled > Reset Configuration Word (RCW): > : 0c070012 0e00 > 0010: 6c2d0002 ec027000 c100 > 0020: 000307fc > 0030: 0004 > Board: T2080QDS, Sys ID: 0x28, Board Arch: V1, Board Version: A, boot > from vBank4 > FPGA: v11 (T1040QDS_2014_0318_1724), build 317 on Tue Mar 18 21:24:26 > 2014 > SERDES Reference Clocks: > SD1_CLK1=156.25MHZ, SD1_CLK2=100.00MHz > SD2_CLK1=100.00MHz, SD2_CLK2=100.00MHz > I2C: ready > SPI: ready > DRAM: Initializingusing SPD > Detected UDIMM > 6 GiB left unmapped > 8 GiB (DDR3, 64-bit, CL=13, ECC on) > DDR Chip-Select Interleaving Mode: CS0+CS1 > Flash: 128 MiB > L2:2 MiB enabled > Corenet Platform Cache: 512 KiB enabled > Using SERDES1 Protocol: 108 (0x6c) > Using SERDES2 Protocol: 45 (0x2d) > SRIO1: enabled > SRIO2: enabled > SEC0: RNG instantiated > NAND: fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer > fsl_ifc_read_byte beyond end of buffer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Ability to load linux kernel on rock2 RK3288
HI Sandy, On 13 July 2016 at 11:51, Sandy Patterson wrote: > I did a little more on this, and talked to someone else here. It seems that > my problem with loading the kernel including these patches is specific to > our kernel and after applying a local patch we have, it appears to load > fine. > > So this patchset gets me back to the same functionality in v2016.03. > > We're left with the puzzle of what's wrong on the RK3288 regarding caching > and memory. So what is the status of this patch set? Should it be withdrawn? Regards, Simon > > Sandy Patterson > > On Mon, Jul 11, 2016 at 1:38 PM, Sandy Patterson > wrote: >> >> I wasn't able to load the linux kernel using a Rock2 board >> using the latest master branch. The board hangs after it has >> handed executing over to the kernel. I found that the latest release >> that worked was v2016.03. >> >> I did some searching and I suspect the problem may be cache related. >> >> This patchset allows the kernel to start by reverting two problem >> commits and disabling EFI_LOADER which I suspect rubs the caching the >> wrong way. We also found that the 512M limit for fdt and initrd is now >> 256M. >> I'm not sure why this is. >> >> This still doesn't work 100%. I think it's not initializing the SD card >> volages correctly, but at least the Kernel is loading. >> >> I also am not sure changing the caching for all armv7 is the right >> answer. I wasn't too sure about the revert. I am not very familiar with >> this low level stuff. >> >> Sandy Patterson >> >> >> Sandy Patterson (4): >> Revert "arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_CLEAN_INVAL_ALL) >> with asm code" >> Revert "arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_INVAL_ALL) with >> asm code" >> Disable CONFIG_EFI_LOADER for rock2. >> RK3288 needs fdt and initrd below 256M now. >> >> arch/arm/cpu/armv7/Makefile | 2 +- >> arch/arm/cpu/armv7/cache_v7.c| 135 >> ++- >> arch/arm/cpu/armv7/cache_v7_asm.S| 154 >> --- >> arch/arm/mach-uniphier/arm32/lowlevel_init.S | 67 +++- >> configs/rock2_defconfig | 1 + >> include/configs/rk3288_common.h | 6 +- >> 6 files changed, 201 insertions(+), 164 deletions(-) >> delete mode 100644 arch/arm/cpu/armv7/cache_v7_asm.S >> >> -- >> 1.9.1 >> > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 2/7] net: dm: Ignore unknown env_op_* constants
Hi Bernhard, On 11 July 2016 at 12:14, Bernhard Nortmann wrote: > This prevents a possible compiler warning similar to > "net/eth-uclass.c::: warning: enumeration value > 'env_op_*' not handled in switch [-Wswitch]". > > Signed-off-by: Bernhard Nortmann > --- > > net/eth-uclass.c | 2 ++ > 1 file changed, 2 insertions(+) > Reviewed-by: Simon Glass > diff --git a/net/eth-uclass.c b/net/eth-uclass.c > index c15cc4d..e38edd7 100644 > --- a/net/eth-uclass.c > +++ b/net/eth-uclass.c > @@ -230,6 +230,8 @@ static int on_ethaddr(const char *name, const char > *value, enum env_op op, > break; > case env_op_delete: > memset(pdata->enetaddr, 0, 6); > + default: > + break; /* ignore */ Presumably hitting the default would be an internal error. So in that case there is no point in returning an error, I think, and what you have is best. > } > } > > -- > 2.7.3 > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] armv8: spl: Call board_init_r from crt0_64 in SPL
Hi Jeremy, On 11 July 2016 at 16:55, Jeremy Hunt wrote: > As part of the startup process for boards using the SPL, the > meaning of board_init_f changed such that it should return normally > rather than calling board_init_r directly. > (see db910353a126d84fe8dff7a694ea792f50fcfb6a) > This was fixed in 32-bit arm, but broke when SPL was added to > 64 bit arm. This fixes crt0_64 so that it calls board_init_r > durring the SPL and removes the direct call from board_init_f > from the arm SPL example. > > Signed-off-by: Jeremy Hunt > > --- > > arch/arm/lib/crt0_64.S | 3 +-- > arch/arm/lib/spl.c | 18 +- > 2 files changed, 10 insertions(+), 11 deletions(-) > > diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S > index cad22c7..91b19e0 100644 > --- a/arch/arm/lib/crt0_64.S > +++ b/arch/arm/lib/crt0_64.S > @@ -108,6 +108,7 @@ relocation_return: > * Set up final (full) environment > */ > bl c_runtime_cpu_setup /* still call old routine */ > +#endif /* !CONFIG_SPL_BUILD */ > > /* TODO: For SPL, call spl_relocate_stack_gd() to alloc stack relocation */ > > @@ -130,6 +131,4 @@ clear_loop: > > /* NOTREACHED - board_init_r() does not return */ > > -#endif /* !CONFIG_SPL_BUILD */ > - > ENDPROC(_main) > diff --git a/arch/arm/lib/spl.c b/arch/arm/lib/spl.c > index e428868..b188834 100644 > --- a/arch/arm/lib/spl.c > +++ b/arch/arm/lib/spl.c > @@ -25,22 +25,22 @@ gd_t gdata __attribute__ ((section(".data"))); > #endif > > /* > - * In the context of SPL, board_init_f must ensure that any clocks/etc for > - * DDR are enabled, ensure that the stack pointer is valid, clear the BSS > - * and call board_init_r. We provide this version by default but mark it > - * as __weak to allow for platforms to do this in their own way if needed. > + * In the context of SPL, board_init_f() prepares the hardware for execution > + * from system RAM (DRAM, DDR...). As system RAM may not be available yet, > + * board_init_f() must use the current GD to store any data which must be > + * passed on to later stages. These data include the relocation destination, > + * the future stack, and the future GD location. BSS is cleared after this > + * function (and therefore must be accessible). > + * > + * We provide this version by default but mark it as __weak to allow for > + * platforms to do this in their own way if needed. Can you please add a comment pointing to the README also ("Board Initialisation Flow")? > */ > void __weak board_init_f(ulong dummy) > { > - /* Clear the BSS. */ > - memset(__bss_start, 0, __bss_end - __bss_start); > - > #ifndef CONFIG_SPL_DM > /* TODO: Remove settings of the global data pointer here */ > gd = &gdata; > #endif > - This is a good change, but if you are dropping the call to board_init_r() then you should drop the above code also (along with the gdata variable). I doubt any more is using it now as it has been a while. So this weak function should be empty. > - board_init_r(NULL, 0); > } > > /* > -- > 2.4.4 > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] xHCI on x86
Hi, On 13 July 2016 at 00:20, Stefan Roese wrote: > Hi! > > I'm currently trying to get xHCI working on some BayTrail based > x86 boards. For this I've added DM support to xhci-pci and made a > small change to cache.h to enable compilation of the xhci driver on > x86 (please find those 2 patches attached - I'll send then to the > list once this is resolved). But I noticed that the xhci driver > hangs in xhci_queue_command() in this line: > > xhci_writel(&ctrl->dba->doorbell[0], DB_VALUE_HOST); > > when first writing to the doorbell register. Reading from this doorbell > register still works just fine. > > IIRC, Simon has mentioned that xHCI still has some "issues" on x86. > Simon, is this what you have seen as well? Does anyone have some ideas > how to solve this? I'm really not sure what is wrong, sorry. The discussion about enabling the pin settings correctly may be relevant since I believe two GPIOs need to be set up for both ports to work, and that patch was never cleaned up and applied, so far as I know... Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9] power: pmic: add Ricoh RN5T567 PMIC support
Hi Stefan, On 13 July 2016 at 00:10, Stefan Agner wrote: > On 2016-07-03 16:18, Simon Glass wrote: >> Hi, >> >> On 3 July 2016 at 13:33, Stefan Agner wrote: >>> From: Stefan Agner >>> >>> Add power driver for Ricoh PMIC used on Colibri iMX7. >>> >>> Signed-off-by: Stefan Agner >>> Acked-by: Marcel Ziswiler >>> --- >>> >>> drivers/power/pmic/Makefile | 1 + >>> drivers/power/pmic/pmic_rn5t567.c | 32 +++ >>> include/power/rn5t567_pmic.h | 115 >>> ++ >>> 3 files changed, 148 insertions(+) >>> create mode 100644 drivers/power/pmic/pmic_rn5t567.c >>> create mode 100644 include/power/rn5t567_pmic.h >> >> Shouldn't this use driver model? > > Looked into this a bit more in detail. > > Afaict, using DM for PMIC would need to use DM for I2C too. The current > driver supports I2C DM only when using device tree, plus it would also > require DM for GPIOs, all that is currently not used by the i.MX 7 > platform. > > I would prefer to stick with the current implementation until that is > sorted, is that acceptable for now? Yes, but I hope you can resolve this quickly. It is not good to add new code to old frameworks as they get harder to remove. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: Clean up CPU selection
On 13 July 2016 at 21:09, Andreas Färber wrote: > In preparation for RK3368 and RK3399, which need to select ARM64, don't > select CPU_V7 at the ARCH_ROCKCHIP level but at the SoC level instead. > > Cc: Kever Yang > Signed-off-by: Andreas Färber > --- > arch/arm/Kconfig | 1 - > arch/arm/mach-rockchip/Kconfig | 2 ++ > 2 files changed, 2 insertions(+), 1 deletion(-) Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: Exclude rk_timer for ARM64
On 13 July 2016 at 22:22, Andreas Färber wrote: > It conflicts with the generic_timer. > > Cc: Kever Yang > Signed-off-by: Andreas Färber > --- > arch/arm/mach-rockchip/Makefile | 2 ++ > 1 file changed, 2 insertions(+) Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] rockchip: add option to change method of loading u-boot
On 12 July 2016 at 18:42, Ziyuan Xu wrote: > hi Simon, > > > On 2016年07月12日 21:28, Simon Glass wrote: >> >> On 12 July 2016 at 05:09, Ziyuan Xu wrote: >>> >>> From: Xu Ziyuan >>> >>> If we would like to boot from SD card, we have to implement mmc driver >>> in SPL stage, and get a slightly large SPL binary. Rockchip SoC's >>> bootrom code has the ability to load spl and u-boot, then boot. >>> >>> If CONFIG_ROCKCHIP_SPL_BACK_TO_BROM is enabled, the spl will return to >>> bootrom in board_init_f(), then bootrom loads u-boot binary. >>> >>> Loading sequence after rework: >>> bootrom ==> spl ==> bootrom ==> u-boot >>> >>> Signed-off-by: Ziyuan Xu >>> Acked-by: Simon Glass >>> --- >>> >>> Changes in v5: >>> - Revise some typos >>> >>> Changes in v4: >>> - Add acked flag from Simon >>> - Rename to CONFIG_ROCKCHIP_SPL_BACK_TO_BROM >>> - Add Kconfig option for this feature support >>> - Revise some nits >>> - Update comments a little >>> - Update commit message >>> >>> Changes in v3: >>> - Add CONFIG_ROCKCHIP_RK3288_SPL_BACKTO_BROM for enabling this feature >>> - Update doc/README.rockchip to instruct how to use it >>> - Detailed commit message >>> >>> Changes in v2: >>> - Add sdcard iomux initlization in board_init() to fix sdmmc command >>> sending timeout issue when booting from eMMC >>> >>> arch/arm/mach-rockchip/Kconfig | 8 ++ >>> arch/arm/mach-rockchip/Makefile| 1 + >>> arch/arm/mach-rockchip/board.c | 33 >>> ++ >>> arch/arm/mach-rockchip/rk3036/Makefile | 1 - >>> arch/arm/mach-rockchip/rk3288-board-spl.c | 5 +++- >>> .../mach-rockchip/{rk3036 => }/save_boot_param.S | 2 +- >>> doc/README.rockchip| 14 + >>> include/configs/rk3288_common.h| 5 >>> 8 files changed, 66 insertions(+), 3 deletions(-) >>> rename arch/arm/mach-rockchip/{rk3036 => }/save_boot_param.S (90%) >> >> I fixed several typos in the Kconfig help, so ended up rewording it a >> little. Your patches are good but please can you take a little more >> time to read them before sending? Also please use "U-Boot" >> consistently instead of u-boot, U-BOOT, etc. I am not claiming to be >> perfect here either - in fact I am quite bad with typos sometimes. But >> a read through will often reduce their number. >> >> Fixed, and: >> >> Applied to u-boot-rockchip, thanks! > > Thanks for your help, I will be more carefully. :-) > [snip] > A nit should be fixed. > > diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig > index d1c0dde..cf718fa 100644 > --- a/arch/arm/mach-rockchip/Kconfig > +++ b/arch/arm/mach-rockchip/Kconfig > @@ -22,7 +22,7 @@ config ROCKCHIP_SPL_BACK_TO_BROM > default y if ROCKCHIP_RK3036 > help > Rockchip SoCs have ability to load SPL & U-Boot binary. If > enabled, > - SPL will return to the boot rom, whch will then load the U-Boot > + SPL will return to the boot rom, which will then load the U-Boot >binary to keep going on. Thanks - fixed! - Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] dts: add support for rkchichip rk3399 soc
On 13 July 2016 at 23:08, Kever Yang wrote: > These files are from kernel upstream with some modification > need by uboot: > - chosen with stdout-path to uart2. > > Signed-off-by: Kever Yang > --- > > arch/arm/dts/Makefile |3 +- > arch/arm/dts/rk3399-evb.dts| 104 > arch/arm/dts/rk3399.dtsi | 1028 > > include/dt-bindings/clock/rk3399-cru.h | 746 +++ > 4 files changed, 1880 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/dts/rk3399-evb.dts > create mode 100644 arch/arm/dts/rk3399.dtsi > create mode 100644 include/dt-bindings/clock/rk3399-cru.h Acked-by: Simon Glass But please fix the typo in the commit subject. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5]
Hi Kever, On 13 July 2016 at 23:08, Kever Yang wrote: > This patchset add support for rk3399 with ATF based on > Rockchip miniloader as secondary bootloader instead of > u-boot SPL. U-Boot > > Rockchip miniloader init the DRAM and load the ATF and > u-boot to runing address, and then jump to ATF, ATM > do some init and switch to EL2/EL1 mode before jump to > next loader which is u-boot here. > > Pls reference board/rockchip/evb_rk3399/README to setup > the board. > > Will migrate to SPL once its ready for ATF. > > This patch set is based on below patch: > "board: move all the rockchip board in one folder" > > This patch set has been test on rk3399 evb board. > > > > Kever Yang (5): > dts: add support for rkchichip rk3399 soc > ARM64: rockchip: add support for rk3399 SoC based evb-board > config: add config file for evb-rk3399 > mmc: rockchip: add SDHCI driver support for rockchip soc > ARM64: evb-rk3399: add a README for this board setup I don't see this last patch on the mailing list. > > arch/arm/Kconfig |3 - > arch/arm/dts/Makefile |3 +- > arch/arm/dts/rk3399-evb.dts| 104 > arch/arm/dts/rk3399.dtsi | 1028 > > arch/arm/mach-rockchip/Kconfig | 25 +- > arch/arm/mach-rockchip/Makefile|2 +- > arch/arm/mach-rockchip/rk3399/Kconfig | 19 + > arch/arm/mach-rockchip/rk3399/Makefile |5 + > board/rockchip/evb_rk3399/Kconfig | 15 + > board/rockchip/evb_rk3399/MAINTAINERS |0 > board/rockchip/evb_rk3399/Makefile |7 + > board/rockchip/evb_rk3399/README | 73 +++ > board/rockchip/evb_rk3399/evb-rk3399.c | 41 ++ > configs/evb-rk3399_defconfig | 32 + > drivers/mmc/Kconfig|6 + > drivers/mmc/Makefile |1 + > drivers/mmc/rockchip_sdhci.c | 58 ++ > include/configs/evb_rk3399.h | 24 + > include/configs/rk3399_common.h| 84 +++ > include/dt-bindings/clock/rk3399-cru.h | 746 +++ > 20 files changed, 2270 insertions(+), 6 deletions(-) > create mode 100644 arch/arm/dts/rk3399-evb.dts > create mode 100644 arch/arm/dts/rk3399.dtsi > create mode 100644 arch/arm/mach-rockchip/rk3399/Kconfig > create mode 100644 arch/arm/mach-rockchip/rk3399/Makefile > create mode 100644 board/rockchip/evb_rk3399/Kconfig > create mode 100644 board/rockchip/evb_rk3399/MAINTAINERS > create mode 100644 board/rockchip/evb_rk3399/Makefile > create mode 100644 board/rockchip/evb_rk3399/README > create mode 100644 board/rockchip/evb_rk3399/evb-rk3399.c > create mode 100644 configs/evb-rk3399_defconfig > create mode 100644 drivers/mmc/rockchip_sdhci.c > create mode 100644 include/configs/evb_rk3399.h > create mode 100644 include/configs/rk3399_common.h > create mode 100644 include/dt-bindings/clock/rk3399-cru.h > > -- > 1.9.1 > > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] mmc: rockchip: add SDHCI driver support for rockchip soc
Hi Kever, On 13 July 2016 at 23:08, Kever Yang wrote: > Rockchip rk3399 using arasan sdhci-5.1 controller. > This patch add the controller support to enable mmc device and tested on > rk3399 evb board. > > Signed-off-by: Kever Yang > --- > > drivers/mmc/Kconfig | 6 + > drivers/mmc/Makefile | 1 + > drivers/mmc/rockchip_sdhci.c | 58 > > 3 files changed, 65 insertions(+) > create mode 100644 drivers/mmc/rockchip_sdhci.c > Can you please update this to define CONFIG_BLK and CONFIG_DM_MMC_OPS? This will give it full driver-model support. See msm_sdhci.c for an example. > diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig > index c80efc3..75c2d92 100644 > --- a/drivers/mmc/Kconfig > +++ b/drivers/mmc/Kconfig > @@ -52,6 +52,12 @@ config ZYNQ_SDHCI > help > Support for Arasan SDHCI host controller on Zynq/ZynqMP ARM SoCs > platform > > +config ROCKCHIP_SDHCI > + bool "Arasan SDHCI controller for Rockchip support" > + depends on DM_MMC && OF_CONTROL > + help > + Support for Arasan SDHCI host controller on Rockchip ARM SoCs > platform > + > config MMC_UNIPHIER > bool "UniPhier SD/MMC Host Controller support" > depends on ARCH_UNIPHIER > diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile > index 3da4817..7cb2ab0 100644 > --- a/drivers/mmc/Makefile > +++ b/drivers/mmc/Makefile > @@ -53,6 +53,7 @@ obj-$(CONFIG_SPEAR_SDHCI) += spear_sdhci.o > obj-$(CONFIG_TEGRA_MMC) += tegra_mmc.o > obj-$(CONFIG_MMC_UNIPHIER) += uniphier-sd.o > obj-$(CONFIG_ZYNQ_SDHCI) += zynq_sdhci.o > +obj-$(CONFIG_ROCKCHIP_SDHCI) += rockchip_sdhci.o > > ifdef CONFIG_SPL_BUILD > obj-$(CONFIG_SPL_MMC_BOOT) += fsl_esdhc_spl.o > diff --git a/drivers/mmc/rockchip_sdhci.c b/drivers/mmc/rockchip_sdhci.c > new file mode 100644 > index 000..bee269d > --- /dev/null > +++ b/drivers/mmc/rockchip_sdhci.c > @@ -0,0 +1,58 @@ > +/* > + * (C) Copyright 2016 Fuzhou Rockchip Electronics Co., Ltd > + * > + * Rockchip SD Host Controller Interface > + * > + * SPDX-License-Identifier:GPL-2.0+ > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* 400KHz is max freq for card ID etc. Use that as min */ > +#define EMMC_MIN_FREQ 40 > + > +static int arasan_sdhci_probe(struct udevice *dev) > +{ > + struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev); > + struct sdhci_host *host = dev_get_priv(dev); > + > + > + host->version = sdhci_readw(host, SDHCI_HOST_VERSION); > + host->quirks = SDHCI_QUIRK_WAIT_SEND_CMD; > + > + add_sdhci(host, CONFIG_ROCKCHIP_SDHCI_MAX_FREQ, EMMC_MIN_FREQ); > + > + upriv->mmc = host->mmc; > + host->mmc->dev = dev; > + > + return 0; > +} > + > +static int arasan_sdhci_ofdata_to_platdata(struct udevice *dev) > +{ > + struct sdhci_host *host = dev_get_priv(dev); > + > + host->name = dev->name; > + host->ioaddr = (void *)dev_get_addr(dev); You can use dev_get_addr_ptr() here. > + > + return 0; > +} > + > +static const struct udevice_id arasan_sdhci_ids[] = { > + { .compatible = "arasan,sdhci-5.1" }, > + { } > +}; > + > +U_BOOT_DRIVER(arasan_sdhci_drv) = { > + .name = "arasan_sdhci", > + .id = UCLASS_MMC, > + .of_match = arasan_sdhci_ids, > + .ofdata_to_platdata = arasan_sdhci_ofdata_to_platdata, > + .probe = arasan_sdhci_probe, > + .priv_auto_alloc_size = sizeof(struct sdhci_host), > +}; > -- > 1.9.1 > > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] config: add config file for evb-rk3399
On 13 July 2016 at 23:08, Kever Yang wrote: > This patch add basic config option for evb-rk3399 board. > > Signed-off-by: Kever Yang > --- > > configs/evb-rk3399_defconfig | 32 > 1 file changed, 32 insertions(+) > create mode 100644 configs/evb-rk3399_defconfig Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] ARM64: rockchip: add support for rk3399 SoC based evb-board
Hi Kever, On 13 July 2016 at 23:08, Kever Yang wrote: > RK3399 is a SoC from Rockchip with dual-core Cortex-A72 > and qual-core Cortex-A53 CPU. It supports two USB3.0 > type-C ports and two USB2.0 EHCI ports. Other interfaces > are very like RK3288, the DRAM are 32bit width address > and support address from 0 to 4GB-128MB range. > > Signed-off-by: Kever Yang > --- > > arch/arm/Kconfig | 3 -- > arch/arm/mach-rockchip/Kconfig | 25 +- > arch/arm/mach-rockchip/Makefile| 2 +- > arch/arm/mach-rockchip/rk3399/Kconfig | 19 > arch/arm/mach-rockchip/rk3399/Makefile | 5 ++ > board/rockchip/evb_rk3399/Kconfig | 15 ++ > board/rockchip/evb_rk3399/MAINTAINERS | 0 > board/rockchip/evb_rk3399/Makefile | 7 +++ > board/rockchip/evb_rk3399/evb-rk3399.c | 41 + > include/configs/evb_rk3399.h | 24 ++ > include/configs/rk3399_common.h| 84 > ++ > 11 files changed, 220 insertions(+), 5 deletions(-) > create mode 100644 arch/arm/mach-rockchip/rk3399/Kconfig > create mode 100644 arch/arm/mach-rockchip/rk3399/Makefile > create mode 100644 board/rockchip/evb_rk3399/Kconfig > create mode 100644 board/rockchip/evb_rk3399/MAINTAINERS > create mode 100644 board/rockchip/evb_rk3399/Makefile > create mode 100644 board/rockchip/evb_rk3399/evb-rk3399.c > create mode 100644 include/configs/evb_rk3399.h > create mode 100644 include/configs/rk3399_common.h Acked-by: Simon Glass nits below > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 8a9cfcc..6e4d78a 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -846,10 +846,7 @@ config STM32 > > config ARCH_ROCKCHIP > bool "Support Rockchip SoCs" > - select SUPPORT_SPL > - select SPL > select OF_CONTROL > - select CPU_V7 > select DM > > config TARGET_THUNDERX_88XX > diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig > index 2a8afac..2a739ea 100644 > --- a/arch/arm/mach-rockchip/Kconfig > +++ b/arch/arm/mach-rockchip/Kconfig > @@ -1,5 +1,8 @@ > if ARCH_ROCKCHIP > > +config RK_TIMER > + bool > + > config ROCKCHIP_RK3288 > bool "Support Rockchip RK3288" > help > @@ -8,6 +11,10 @@ config ROCKCHIP_RK3288 > video interfaces supporting HDMI and eDP, several DDR3 options > and video codec support. Peripherals include Gigabit Ethernet, > USB2 host and OTG, SDIO, I2S, UART,s, SPI, I2C and PWMs. > + select CPU_V7 > + select RK_TIMER > + select SUPPORT_SPL > + select SPL > > config ROCKCHIP_RK3036 > bool "Support Rockchip RK3036" > @@ -16,6 +23,21 @@ config ROCKCHIP_RK3036 > including NEON and GPU, Mali-400 graphics, several DDR3 options > and video codec support. Peripherals include Gigabit Ethernet, > USB2 host and OTG, SDIO, I2S, UART, SPI, I2C and PWMs. > + select CPU_V7 > + select RK_TIMER > + select SUPPORT_SPL > + select SPL > + > +config ROCKCHIP_RK3399 > + bool "Support Rockchip RK3399" > + help > + The Rockchip RK3399 is a ARM-based SoC with a dual-core Cortex-A72 > + and qual-core Cortex-A53. > + including NEON and GPU, 1MB L2 cache, Mali-T7 graphics, two > + video interfaces supporting HDMI and eDP, several DDR3 options > + and video codec support. Peripherals include Gigabit Ethernet, > + USB2 host and OTG, SDIO, I2S, UART,s, SPI, I2C and PWMs. > + select ARM64 > > config SYS_MALLOC_F > default y > @@ -42,8 +64,9 @@ config DM_GPIO > default y > > config BLK > - default y > + default y if CPU_V7 > > source "arch/arm/mach-rockchip/rk3288/Kconfig" > source "arch/arm/mach-rockchip/rk3036/Kconfig" > +source "arch/arm/mach-rockchip/rk3399/Kconfig" > endif > diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile > index 55567cb..50246f0 100644 > --- a/arch/arm/mach-rockchip/Makefile > +++ b/arch/arm/mach-rockchip/Makefile > @@ -10,6 +10,6 @@ obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o > else > obj-$(CONFIG_ROCKCHIP_RK3288) += board.o > endif > -obj-y += rk_timer.o > +obj-$(CONFIG_RK_TIMER) += rk_timer.o > obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/ > obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/ > diff --git a/arch/arm/mach-rockchip/rk3399/Kconfig > b/arch/arm/mach-rockchip/rk3399/Kconfig > new file mode 100644 > index 000..603f534 > --- /dev/null > +++ b/arch/arm/mach-rockchip/rk3399/Kconfig > @@ -0,0 +1,19 @@ > +if ROCKCHIP_RK3399 > + > +config TARGET_EVB_RK3399 > + bool "RK3399 evb board" > + help > + Firefly is a RK3288-based development board with 2 USB ports, Firefly? Please check that this help is correct. > + HDMI, VGA, micro-SD card, audio, WiFi and Gigabit Ethernet, It > + also includes on-board eMMC and 1GB of SDRAM. Expansio
Re: [U-Boot] [PATCH v4 4/4] usb: dwc2 : invalidate dcache before starting DMA
On 14 July 2016 at 00:52, Ziyuan Xu wrote: > From: Xu Ziyuan > > Invalidate dcache before starting the DMA to ensure coherency. In case > there are any dirty lines from the DMA buffer in the cache, subsequent > cache-line replacements may corrupt the buffer in memory while the DMA > is still going on. Cache-line replacement can happen if the CPU tries to > bring some other memory locations into the cache while the DMA is going > on. > > Signed-off-by: Ziyuan Xu > > --- > > Changes in v4: None > Changes in v3: > - New commit since v3 to fix the coherence issue between memory and > cache > > Changes in v2: None > > drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 3 +++ > 1 file changed, 3 insertions(+) Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/4] usb: rockchip-phy: implement USB2.0 phy control
On 14 July 2016 at 00:52, Ziyuan Xu wrote: > From: Xu Ziyuan > > So far, Rockchip SoCs have two kinds of USB2.0 phy, such as Synopsys and > Innosilicon. This patch applys dwc2 usb driver framework to implement > phy_init() and phy_off() methods for Synopsys phy on Rockchip platform. > > Signed-off-by: Ziyuan Xu > > --- > > Changes in v4: > - Implement a mechanism to be compatible with more Rockchip SoCs > - Rename rockchip_usb_syno_phy.c to rockchip_usb2_phy.c > > Changes in v3: > - Make UOC_CON registers to be unfixed which should be got from DT > > Changes in v2: > - Rename rk3288_usb_phy.c to rockchip_usb_syno_phy.c > - Rework the behaviour in otg_phy_init() and otg_phy_off() > > drivers/usb/phy/Makefile| 1 + > drivers/usb/phy/rockchip_usb2_phy.c | 107 > > include/usb/dwc2_udc.h | 2 + > 3 files changed, 110 insertions(+) > create mode 100644 drivers/usb/phy/rockchip_usb2_phy.c Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/4] usb: dwc2-otg: adjust fifo size via platform data
On 14 July 2016 at 00:52, Ziyuan Xu wrote: > From: Xu Ziyuan > > The total FIFO size of some SoCs may be different from the existen, this > patch supports fifo size setting from platform data. > > Signed-off-by: Ziyuan Xu > > --- > > Changes in v4: > - Rework fifo size getting and setting > - Update commit message > > Changes in v3: None > Changes in v2: > - Update detailed commit message > - Modify the macro's values > > drivers/usb/gadget/dwc2_udc_otg.c | 22 -- > drivers/usb/gadget/dwc2_udc_otg_regs.h | 6 +++--- > include/usb/dwc2_udc.h | 3 +++ > 3 files changed, 22 insertions(+), 9 deletions(-) Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/4] usb: dwc2: invalidate dcache before starting DMA
Hi Ziyuan, On 14 July 2016 at 09:43, Ziyuan Xu wrote: > Hi Simon, > > > On 2016年07月14日 23:00, Simon Glass wrote: >> >> On 12 July 2016 at 19:06, Ziyuan Xu wrote: >>> >>> >>> On 2016年07月12日 20:59, Simon Glass wrote: Hi Ziyuan, On 6 July 2016 at 03:34, Ziyuan Xu wrote: > > From: Xu Ziyuan > > Invalidate dcache before starting the DMA to ensure coherency. In case > there are any dirty lines from the DMA buffer in the cache, subsequent > cache-line replacements may corrupt the buffer in memory while the DMA > is still going on. Cache-line replacement can happen if the CPU tries > to > bring some other memory locations into the cache while the DMA is going > on. > > Signed-off-by: Ziyuan Xu > --- > > Changes in v3: > - New commit since v3 to fix the coherence issue between memory and > cache > > Changes in v2: None > >drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 3 +++ >1 file changed, 3 insertions(+) > > diff --git a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c > b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c > index 12f5c85..0d6d2fb 100644 > --- a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c > +++ b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c > @@ -110,6 +110,9 @@ static int setdma_rx(struct dwc2_ep *ep, struct > dwc2_request *req) > > ctrl = readl(®->out_endp[ep_num].doepctl); > > + invalidate_dcache_range((unsigned long) ep->dma_buf, > + (unsigned long) ep->dma_buf + ep->len); There is an invalidate in complete_rx() which is one of the callers for this function. It seems to me that we should not have this in two places. Why do we have this problem? Is it because the other calls to setdma_rx() don't invalidate? >>> >>> >>> Yup, invoke invalidate method twice during one complete transmission: >>> 1- invalidate in setdma_rx() in case of the write back cache, present >>> from >>> cache-line replacement after DMA transmission complete. >>> i.e. >>> 1) dma_buf = "123456789abcd"; >>> 2) didn't invalidate in setdma_rx() >>> 3) DMA complete interrupt coming >>> 4) invalidate in complete_rx() >>> 5) read dma_buf, it's "123456789abcd" >>> >>> If invalidate in step 2, we will achieve correct data. >>> I think it's necessary to invalidate before starting DMA, and >>> doc/README.arm-caches describe details. >>> 2- invalidate in complete_rx(), cpu read the dma_buf from memory >>> directly. >>> I think the invalidate should happen just before reading the data. Can you please check if the other invalidate is needed? Also see how it cache-aligns the end address. >>> >>> memalign(CONFIG_SYS_CACHELINE_SIZE, EP_BUFFER_SIZE); >>> cache-aligns: 64 bytes. >>> dma_buffer size: 4096 >>> >>> I had check cache-aligins and end address, rightful. >>> Furthermore, everything works fine with noncached_alloc(). >>> >> OK, thanks for the details. Can the invalidate in (4) be dropped? We >> should only need one invalidate. > > We also need invalidate in after DMA transfer completed, because in some > processors memory contents can spontaneouslycome to the cache due to > speculative memory access by the CPU. If this happens with the DMA buffer > while DMA is going on we have a coherency problem. Gosh that is horrible. > Thanks for your review! > > >> >> Reviewed-by: Simon Glass >> > + > writel((unsigned int) ep->dma_buf, > ®->out_endp[ep_num].doepdma); > writel(DOEPT_SIZ_PKT_CNT(pktcnt) | > DOEPT_SIZ_XFER_SIZE(length), > ®->out_endp[ep_num].doeptsiz); > -- > 1.9.1 > > Regards, Simon >>> >> >> > > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mkimage: rockchip: add suport for rk33 serial
On 13 July 2016 at 21:51, Kever Yang wrote: > Add support for rockchip rk33 series Soc like rk3368 and rk3399 > > Signed-off-by: Kever Yang > --- > > tools/rkcommon.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tools/rkcommon.c b/tools/rkcommon.c > index 72621fd..9ec7eb2 100644 > --- a/tools/rkcommon.c > +++ b/tools/rkcommon.c > @@ -56,6 +56,7 @@ struct spl_info { > static struct spl_info spl_infos[] = { > { "rk3036", "RK30", 0x1000 }, > { "rk3288", "RK32", 0x8000 }, > + { "rk33xx", "RK33", 0x2 }, > }; > > static unsigned char rc4_key[16] = { > -- > 1.9.1 > > Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4.1 3/4] rockchip: rk3288: add fastboot support
On 14 July 2016 at 10:26, Ziyuan Xu wrote: > From: Xu Ziyuan > > Enable fastboot feature on rk3288. > > This path doesn't support the fastboot flash function command entirely. patch? > We will hit "cannot find partition" assertion without specified > partition environment. Define gpt partition layout in specified board > such as firefly-rk3288, then enjoy it! > > Signed-off-by: Ziyuan Xu > > --- > > Changes in v4.1: > - Revise tx_fifo_sz to 128 > > Changes in v4: > - Add fifo size for rk3288 > - Get usb_phy's dt_node > > Changes in v3: > - Achieve UOC_CON_OFFSET physical address from DT > > Changes in v2: > - Achieve the regs_phy from DT > - Update comments a little > > arch/arm/dts/rk3288.dtsi| 1 + > arch/arm/mach-rockchip/board.c | 72 > + > include/configs/rk3288_common.h | 26 +++ > 3 files changed, 99 insertions(+) Acked-by: Simon Glass Could you please add some documentation to README.rockchip on how to use this? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: Exclude rk_timer for ARM64
On 14 July 2016 at 21:20, Simon Glass wrote: > On 13 July 2016 at 22:22, Andreas Färber wrote: >> It conflicts with the generic_timer. >> >> Cc: Kever Yang >> Signed-off-by: Andreas Färber >> --- >> arch/arm/mach-rockchip/Makefile | 2 ++ >> 1 file changed, 2 insertions(+) > > Acked-by: Simon Glass Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mkimage: rockchip: add suport for rk33 serial
On 14 July 2016 at 21:20, Simon Glass wrote: > On 13 July 2016 at 21:51, Kever Yang wrote: >> Add support for rockchip rk33 series Soc like rk3368 and rk3399 >> >> Signed-off-by: Kever Yang >> --- >> >> tools/rkcommon.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/tools/rkcommon.c b/tools/rkcommon.c >> index 72621fd..9ec7eb2 100644 >> --- a/tools/rkcommon.c >> +++ b/tools/rkcommon.c >> @@ -56,6 +56,7 @@ struct spl_info { >> static struct spl_info spl_infos[] = { >> { "rk3036", "RK30", 0x1000 }, >> { "rk3288", "RK32", 0x8000 }, >> + { "rk33xx", "RK33", 0x2 }, >> }; >> >> static unsigned char rc4_key[16] = { >> -- >> 1.9.1 >> >> > > Acked-by: Simon Glass Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/4] usb: rockchip-phy: implement USB2.0 phy control
On 14 July 2016 at 21:20, Simon Glass wrote: > On 14 July 2016 at 00:52, Ziyuan Xu wrote: >> From: Xu Ziyuan >> >> So far, Rockchip SoCs have two kinds of USB2.0 phy, such as Synopsys and >> Innosilicon. This patch applys dwc2 usb driver framework to implement >> phy_init() and phy_off() methods for Synopsys phy on Rockchip platform. >> >> Signed-off-by: Ziyuan Xu >> >> --- >> >> Changes in v4: >> - Implement a mechanism to be compatible with more Rockchip SoCs >> - Rename rockchip_usb_syno_phy.c to rockchip_usb2_phy.c >> >> Changes in v3: >> - Make UOC_CON registers to be unfixed which should be got from DT >> >> Changes in v2: >> - Rename rk3288_usb_phy.c to rockchip_usb_syno_phy.c >> - Rework the behaviour in otg_phy_init() and otg_phy_off() >> >> drivers/usb/phy/Makefile| 1 + >> drivers/usb/phy/rockchip_usb2_phy.c | 107 >> >> include/usb/dwc2_udc.h | 2 + >> 3 files changed, 110 insertions(+) >> create mode 100644 drivers/usb/phy/rockchip_usb2_phy.c > > Acked-by: Simon Glass Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/4] usb: dwc2-otg: adjust fifo size via platform data
On 14 July 2016 at 21:20, Simon Glass wrote: > On 14 July 2016 at 00:52, Ziyuan Xu wrote: >> From: Xu Ziyuan >> >> The total FIFO size of some SoCs may be different from the existen, this >> patch supports fifo size setting from platform data. >> >> Signed-off-by: Ziyuan Xu >> >> --- >> >> Changes in v4: >> - Rework fifo size getting and setting >> - Update commit message >> >> Changes in v3: None >> Changes in v2: >> - Update detailed commit message >> - Modify the macro's values >> >> drivers/usb/gadget/dwc2_udc_otg.c | 22 -- >> drivers/usb/gadget/dwc2_udc_otg_regs.h | 6 +++--- >> include/usb/dwc2_udc.h | 3 +++ >> 3 files changed, 22 insertions(+), 9 deletions(-) > > Acked-by: Simon Glass Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: Clean up CPU selection
On 14 July 2016 at 21:20, Simon Glass wrote: > On 13 July 2016 at 21:09, Andreas Färber wrote: >> In preparation for RK3368 and RK3399, which need to select ARM64, don't >> select CPU_V7 at the ARCH_ROCKCHIP level but at the SoC level instead. >> >> Cc: Kever Yang >> Signed-off-by: Andreas Färber >> --- >> arch/arm/Kconfig | 1 - >> arch/arm/mach-rockchip/Kconfig | 2 ++ >> 2 files changed, 2 insertions(+), 1 deletion(-) > > Acked-by: Simon Glass Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 03/62] spl: Drop include of i2c.h
On 4 July 2016 at 11:57, Simon Glass wrote: > This file does not appear to use I2C, so drop this include. > > Signed-off-by: Simon Glass > --- > > Changes in v3: None > Changes in v2: None > > common/spl/spl.c | 1 - > 1 file changed, 1 deletion(-) Applied to u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/4] usb: dwc2: invalidate dcache before starting DMA
On 14 July 2016 at 21:20, Simon Glass wrote: > Hi Ziyuan, > > On 14 July 2016 at 09:43, Ziyuan Xu wrote: >> Hi Simon, >> >> >> On 2016年07月14日 23:00, Simon Glass wrote: >>> >>> On 12 July 2016 at 19:06, Ziyuan Xu wrote: On 2016年07月12日 20:59, Simon Glass wrote: > > Hi Ziyuan, > > On 6 July 2016 at 03:34, Ziyuan Xu wrote: >> >> From: Xu Ziyuan >> >> Invalidate dcache before starting the DMA to ensure coherency. In case >> there are any dirty lines from the DMA buffer in the cache, subsequent >> cache-line replacements may corrupt the buffer in memory while the DMA >> is still going on. Cache-line replacement can happen if the CPU tries >> to >> bring some other memory locations into the cache while the DMA is going >> on. >> >> Signed-off-by: Ziyuan Xu >> --- >> >> Changes in v3: >> - New commit since v3 to fix the coherence issue between memory and >> cache >> >> Changes in v2: None >> >>drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 3 +++ >>1 file changed, 3 insertions(+) >> >> diff --git a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c >> b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c >> index 12f5c85..0d6d2fb 100644 >> --- a/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c >> +++ b/drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c >> @@ -110,6 +110,9 @@ static int setdma_rx(struct dwc2_ep *ep, struct >> dwc2_request *req) >> >> ctrl = readl(®->out_endp[ep_num].doepctl); >> >> + invalidate_dcache_range((unsigned long) ep->dma_buf, >> + (unsigned long) ep->dma_buf + ep->len); > > There is an invalidate in complete_rx() which is one of the callers > for this function. It seems to me that we should not have this in two > places. Why do we have this problem? Is it because the other calls to > setdma_rx() don't invalidate? Yup, invoke invalidate method twice during one complete transmission: 1- invalidate in setdma_rx() in case of the write back cache, present from cache-line replacement after DMA transmission complete. i.e. 1) dma_buf = "123456789abcd"; 2) didn't invalidate in setdma_rx() 3) DMA complete interrupt coming 4) invalidate in complete_rx() 5) read dma_buf, it's "123456789abcd" If invalidate in step 2, we will achieve correct data. I think it's necessary to invalidate before starting DMA, and doc/README.arm-caches describe details. 2- invalidate in complete_rx(), cpu read the dma_buf from memory directly. > I think the invalidate should happen just before reading the data. Can > you please check if the other invalidate is needed? Also see how it > cache-aligns the end address. memalign(CONFIG_SYS_CACHELINE_SIZE, EP_BUFFER_SIZE); cache-aligns: 64 bytes. dma_buffer size: 4096 I had check cache-aligins and end address, rightful. Furthermore, everything works fine with noncached_alloc(). >>> OK, thanks for the details. Can the invalidate in (4) be dropped? We >>> should only need one invalidate. >> >> We also need invalidate in after DMA transfer completed, because in some >> processors memory contents can spontaneouslycome to the cache due to >> speculative memory access by the CPU. If this happens with the DMA buffer >> while DMA is going on we have a coherency problem. > > Gosh that is horrible. > >> Thanks for your review! >> Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/62] sandbox: Don't print a warning for CONFIG_I2C_COMPAT
On 4 July 2016 at 11:57, Simon Glass wrote: > Sandbox includes this code to provide build coverage. While we retain this > feature we should have sandbox build it. Sandbox does not in fact use the > I2C compatibility mode. Showing a warning for sandbox is just confusing, > since no conversion is expected. > > Drop the warning for sandbox. > > Signed-off-by: Simon Glass > --- > > Changes in v3: None > Changes in v2: None > > Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied to u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 04/62] Makefile: Allow the SPL final link rule to be overridden
On 4 July 2016 at 11:57, Simon Glass wrote: > Overriding the final link rule is possible with U-Boot proper. It us used to > create a sandbox image links with host libraries. To build a sandbox SPL > image we need the same feature for SPL. > > To support this, update the SPL link rule so sandbox can override it. > > Signed-off-by: Simon Glass > --- > > Changes in v3: None > Changes in v2: None > > scripts/Makefile.spl | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) Applied to u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/62] README: Remove CONFIG_SYS_MALLOC_F_LEN comment
On 4 July 2016 at 11:57, Simon Glass wrote: > This option is now widely available, so remove the comment that it is only > available on ARM and sandbox. > > Signed-off-by: Simon Glass > --- > > Changes in v3: None > Changes in v2: None > > README | 3 --- > 1 file changed, 3 deletions(-) Applied to u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/4] usb: dwc2 : invalidate dcache before starting DMA
On 14 July 2016 at 21:20, Simon Glass wrote: > On 14 July 2016 at 00:52, Ziyuan Xu wrote: >> From: Xu Ziyuan >> >> Invalidate dcache before starting the DMA to ensure coherency. In case >> there are any dirty lines from the DMA buffer in the cache, subsequent >> cache-line replacements may corrupt the buffer in memory while the DMA >> is still going on. Cache-line replacement can happen if the CPU tries to >> bring some other memory locations into the cache while the DMA is going >> on. >> >> Signed-off-by: Ziyuan Xu >> >> --- >> >> Changes in v4: None >> Changes in v3: >> - New commit since v3 to fix the coherence issue between memory and >> cache >> >> Changes in v2: None >> >> drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c | 3 +++ >> 1 file changed, 3 insertions(+) > > Acked-by: Simon Glass Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/62] sandbox: Support building an SPL image
On 4 July 2016 at 11:57, Simon Glass wrote: > When building an SPL image, override the link flags so that it uses the > system libraries. This is similar to the way the non-SPL image is built. > > Signed-off-by: Simon Glass > --- > > Changes in v3: None > Changes in v2: None > > arch/sandbox/config.mk | 5 + > 1 file changed, 5 insertions(+) Applied to u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 05/62] sandbox: Allow chaining from SPL to U-Boot proper
On 4 July 2016 at 11:57, Simon Glass wrote: > SPL is expected to load and run U-Boot. This needs to work with sandbox also. > Provide a function to locate the U-Boot image, and another to start it. This > allows SPL to function on sandbox as it does on other archs. > > Signed-off-by: Simon Glass > --- > > Changes in v3: None > Changes in v2: None > > arch/sandbox/cpu/os.c | 51 > +++ > include/os.h | 25 + > 2 files changed, 76 insertions(+) Applied to u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 08/62] sandbox: Add some missing headers in cpu.c
On 4 July 2016 at 11:57, Simon Glass wrote: > These headers are needed in case they are not transitively included. > > Signed-off-by: Simon Glass > --- > > Changes in v3: None > Changes in v2: None > > arch/sandbox/cpu/cpu.c | 2 ++ > 1 file changed, 2 insertions(+) Applied to u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 07/62] sandbox: Correct header file order in cpu.c
On 4 July 2016 at 11:57, Simon Glass wrote: > The dm/ file should go at the end. Move it. > > Signed-off-by: Simon Glass > --- > > Changes in v3: None > Changes in v2: None > > arch/sandbox/cpu/cpu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied to u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 10/62] sandbox: Don't include the main loop in SPL
On 4 July 2016 at 11:57, Simon Glass wrote: > SPL does not have a command interface so we should not include the main loop > code. > > Signed-off-by: Simon Glass > --- > > Changes in v3: None > Changes in v2: None > > arch/sandbox/cpu/start.c | 2 ++ > 1 file changed, 2 insertions(+) Applied to u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/62] sandbox: Don't use PCI in SPL
On 4 July 2016 at 11:57, Simon Glass wrote: > PCI is not supported in SPL for sandbox, so avoid using it. > > Signed-off-by: Simon Glass > --- > > Changes in v3: None > Changes in v2: None > > arch/sandbox/cpu/cpu.c| 2 +- > arch/sandbox/lib/Makefile | 2 ++ > 2 files changed, 3 insertions(+), 1 deletion(-) Applied to u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 11/62] sandbox: Add basic SPL implementation
On 4 July 2016 at 11:57, Simon Glass wrote: > Add an sandbox implementation for the generic SPL framework. This supports > locating and running U-Boot proper. > > Signed-off-by: Simon Glass > --- > > Changes in v3: None > Changes in v2: None > > arch/sandbox/cpu/Makefile | 1 + > arch/sandbox/cpu/spl.c | 51 > ++ > arch/sandbox/include/asm/spl.h | 23 +++ > 3 files changed, 75 insertions(+) > create mode 100644 arch/sandbox/cpu/spl.c > create mode 100644 arch/sandbox/include/asm/spl.h Applied to u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 13/62] sandbox: serial: Don't sync video in SPL
On 4 July 2016 at 11:57, Simon Glass wrote: > SPL does not support an LCD display so there is no need to sync the video > when there is serial output. > > Signed-off-by: Simon Glass > --- > > Changes in v3: None > Changes in v2: None > > drivers/serial/sandbox.c | 2 ++ > 1 file changed, 2 insertions(+) Applied to u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot