Re: [U-Boot] [PATCH] gunzip: cache-align write buffer memory
On Mon, Aug 29, 2016 at 05:10:36PM +0200, Clemens Gruber wrote: > When using gzwrite to eMMC on an i.MX6Q board, the following warning > occurs repeatedly: > CACHE: Misaligned operation at range [4fd63318, 4fe63318] > > This patch cache-aligns the memory allocation for the gzwrite writebuf, > therefore avoiding the misaligned dcache flush and the warning from > check_cache_range. > > Signed-off-by: Clemens Gruber > --- > lib/gunzip.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/lib/gunzip.c b/lib/gunzip.c > index bc746d6..832b306 100644 > --- a/lib/gunzip.c > +++ b/lib/gunzip.c > @@ -11,6 +11,7 @@ > #include > #include > #include > +#include > #include > #include > > @@ -193,7 +194,7 @@ int gzwrite(unsigned char *src, int len, > > s.next_in = src + i; > s.avail_in = payload_size+8; > - writebuf = (unsigned char *)malloc(szwritebuf); > + writebuf = (unsigned char *)malloc_cache_aligned(szwritebuf); > > /* decompress until deflate stream ends or end of file */ > do { > -- > 2.9.3 > Hi, are there any blockers for this patch to get merged? Thanks, Clemens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] crypto/fsl: fix obj-yy in Makefile
When enabling CONFIG_CMD_BLOB and/or CONFIG_CMD_DEKBLOB, the build fails with a linker error: ... LD u-boot arch/arm/mach-imx/built-in.o: In function `blob_encap_dek': /home/clemens/dev/u-boot/arch/arm/mach-imx/cmd_dek.c:46: undefined reference to `blob_dek' This is due to an error in the Makefile, resulting in obj-yy/obj-yn/.. and fsl_blob.o is therefore not linked. Fix it by splitting it up into two obj-y lines. Signed-off-by: Clemens Gruber --- drivers/crypto/fsl/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/crypto/fsl/Makefile b/drivers/crypto/fsl/Makefile index fd736cf3be..ea878e1822 100644 --- a/drivers/crypto/fsl/Makefile +++ b/drivers/crypto/fsl/Makefile @@ -6,5 +6,6 @@ obj-y += sec.o obj-$(CONFIG_FSL_CAAM) += jr.o fsl_hash.o jobdesc.o error.o -obj-$(CONFIG_CMD_BLOB)$(CONFIG_CMD_DEKBLOB) += fsl_blob.o +obj-$(CONFIG_CMD_BLOB) += fsl_blob.o +obj-$(CONFIG_CMD_DEKBLOB) += fsl_blob.o obj-$(CONFIG_RSA_FREESCALE_EXP) += fsl_rsa.o -- 2.14.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] i.MX6 CAAM BLOB problem: Invalid KEY Command
Hi, I am experimenting with the BLOB feature of the CAAM on an i.MX6Q. However, CAAM does not accept the KEY Command, necessary for the blob OPERATION. I want to encapsulate data within U-Boot as a "red blob" to allow storing it in an unsecure location and ensure that it can only be decapsulated on the same system and only if it is in HAB secure state. Here is what I did in my board code: hab_caam_clock_enable(1); sec_init(); uint8_t *km = malloc(16); strncpy((char*)km, "My Key Modifier", 16); uint8_t *plaintext = malloc(64); strncpy((char*)plaintext, "My Test Plaintext", 64); uint8_t *blob = malloc(32+64+16); blob_encap(km, plaintext, blob, 64); When enabling DEBUG, I see the following: 01: operation 02: jump 03: load_imm_u32 05: operation : No error: SEC0: RNG instantiated Encapsulating data to form blob 01: key 03: seq_in_ptr 03: seq_in_ptr_extlen 06: seq_out_ptr 06: seq_out_ptr_extlen 09: operation Descriptor dump: Word[0]: b08a Word[1]: 0410 Word[2]: 4fd7ab20 Word[3]: f040 Word[4]: 4fd7a9f8 Word[5]: 0040 Word[6]: f840 Word[7]: 4fd7ab38 Word[8]: 0070 Word[9]: 870d Word[10]: 206d6574 Word[11]: 65736572 Word[12]: 2e2e2074 Word[13]: 72203b20 4006: DECO: desc idx 0: Invalid KEY Command Error 4006 Error in Encapsulation 1073741830 -- I read through the i.MX6DQ Security Reference Manual [1], but could not find out why this Invalid KEY Command error occurs. The KEY command (Word[1..2]) looks OK: CTYPE = 0b (KEY), CLASS = 0b10 (Class 2), No SGF, No IMM, No ENC, LENGTH=0b1 (16 bytes) Any ideas what's causing this? Are blob_encap/blob_decap (or CMD_BLOB from CLI) working for you? (Not sure if it's important, but I am successfully using HAB on this system and get_hab_status does not report any errors/events, so the chip comes up in secure mode and should - if it were working - use the OTPMK + the key modifier for the BKEK) Best regards, Clemens -- [1] https://www.nxp.com/webapp/sps/download/mod_download.jsp?colCode=IMX6DQ6SDLSRM&appType=moderatedWithoutFAE ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] crypto/fsl: fix BLOB encapsulation and decapsulation
The blob_encap and blob_decap functions were not flushing the dcache before passing data to CAAM/DMA and not invalidating the dcache when getting data back. Therefore, blob encapsulation and decapsulation failed with errors like the following due to data cache incoherency: "4006: DECO: desc idx 0: Invalid KEY command" To ensure coherency, we allocate aligned memory to store the data passed to/from CAAM and flush/invalidate the memory regions. Blobs can now be encapsulated and decapsulated with the blob cmd as well as from board code by calling blob_encap and blob_decap directly. Tested on an i.MX6Q board. Signed-off-by: Clemens Gruber --- drivers/crypto/fsl/fsl_blob.c | 99 --- 1 file changed, 83 insertions(+), 16 deletions(-) diff --git a/drivers/crypto/fsl/fsl_blob.c b/drivers/crypto/fsl/fsl_blob.c index 38c6f9486b..65ce21f4af 100644 --- a/drivers/crypto/fsl/fsl_blob.c +++ b/drivers/crypto/fsl/fsl_blob.c @@ -7,6 +7,7 @@ #include #include +#include #include #include #include "jobdesc.h" @@ -15,56 +16,122 @@ int blob_decap(u8 *key_mod, u8 *src, u8 *dst, u32 len) { - int ret, i = 0; + ALLOC_CACHE_ALIGN_BUFFER(u8, aligned_key_mod, 16); + u8 *aligned_src, *aligned_dst; + int ret, size, i = 0; u32 *desc; printf("\nDecapsulating blob to get data\n"); - desc = malloc(sizeof(int) * MAX_CAAM_DESCSIZE); + desc = malloc_cache_aligned(sizeof(int) * MAX_CAAM_DESCSIZE); if (!desc) { debug("Not enough memory for descriptor allocation\n"); - return -1; + return -ENOMEM; } - inline_cnstr_jobdesc_blob_decap(desc, key_mod, src, dst, len); + aligned_src = malloc_cache_aligned(BLOB_SIZE(len)); + aligned_dst = malloc_cache_aligned(len); + if (!aligned_src || !aligned_dst) { + debug("Not enough memory for blob allocations\n"); + return -ENOMEM; + } + + memcpy(aligned_key_mod, key_mod, 16); + size = ALIGN(16, ARCH_DMA_MINALIGN); + flush_dcache_range((unsigned long)aligned_key_mod, + (unsigned long)aligned_key_mod + size); + + memcpy(aligned_src, src, BLOB_SIZE(len)); + size = ALIGN(BLOB_SIZE(len), ARCH_DMA_MINALIGN); + flush_dcache_range((unsigned long)aligned_src, + (unsigned long)aligned_src + size); + + inline_cnstr_jobdesc_blob_decap(desc, aligned_key_mod, aligned_src, + aligned_dst, len); debug("Descriptor dump:\n"); for (i = 0; i < 14; i++) debug("Word[%d]: %08x\n", i, *(desc + i)); + + size = ALIGN(sizeof(int) * MAX_CAAM_DESCSIZE, ARCH_DMA_MINALIGN); + flush_dcache_range((unsigned long)desc, + (unsigned long)desc + size); + ret = run_descriptor_jr(desc); - if (ret) - printf("Error in Decapsulation %d\n", ret); - else - printf("Decapsulation Success\n"); + if (ret) { + printf("Error in blob decapsulation: %d\n", ret); + } else { + size = ALIGN(len, ARCH_DMA_MINALIGN); + invalidate_dcache_range((unsigned long)aligned_dst, + (unsigned long)aligned_dst + size); + memcpy(dst, aligned_dst, len); + + puts("Blob decapsulation successful.\n"); + } + free(aligned_dst); + free(aligned_src); free(desc); return ret; } int blob_encap(u8 *key_mod, u8 *src, u8 *dst, u32 len) { - int ret, i = 0; + ALLOC_CACHE_ALIGN_BUFFER(u8, aligned_key_mod, 16); + u8 *aligned_src, *aligned_dst; + int ret, size, i = 0; u32 *desc; printf("\nEncapsulating data to form blob\n"); - desc = malloc(sizeof(int) * MAX_CAAM_DESCSIZE); + desc = malloc_cache_aligned(sizeof(int) * MAX_CAAM_DESCSIZE); if (!desc) { debug("Not enough memory for descriptor allocation\n"); - return -1; + return -ENOMEM; } - inline_cnstr_jobdesc_blob_encap(desc, key_mod, src, dst, len); + aligned_src = malloc_cache_aligned(len); + aligned_dst = malloc_cache_aligned(BLOB_SIZE(len)); + if (!aligned_src || !aligned_dst) { + debug("Not enough memory for blob allocations\n"); + return -ENOMEM; + } + + memcpy(aligned_key_mod, key_mod, 16); + size = ALIGN(16, ARCH_DMA_MINALIGN); + flush_dcache_range((unsigned long)aligned_key_mod, + (unsigned long)aligned_key_mod + size); + + memcpy(aligned_src, src, len); + size = ALIGN(len, ARCH_DMA_MINALIGN); + flush_dcache_range((unsigned l
Re: [U-Boot] [PATCH] crypto/fsl: fix BLOB encapsulation and decapsulation
Hi Breno, On Thu, Dec 21, 2017 at 07:18:44PM -0200, Breno Matheus Lima wrote: > Hi Clemens, > > 2017-12-20 20:08 GMT-02:00 Clemens Gruber : > > The blob_encap and blob_decap functions were not flushing the dcache > > before passing data to CAAM/DMA and not invalidating the dcache when > > getting data back. > > Therefore, blob encapsulation and decapsulation failed with errors like > > the following due to data cache incoherency: > > "4006: DECO: desc idx 0: Invalid KEY command" > > > > To ensure coherency, we allocate aligned memory to store the data passed > > to/from CAAM and flush/invalidate the memory regions. > > Blobs can now be encapsulated and decapsulated with the blob cmd as well > > as from board code by calling blob_encap and blob_decap directly. > > > > Tested on an i.MX6Q board. > > I tested your patch on a closed i.MX6QSabreAuto and the functions > blob_encap() and blob_decap() are working fine. Thanks for testing! > In my environment I had to add a small modification in function > do_blob() in cmd/blob.c file to get the cmd blob working: > > + hab_caam_clock_enable(1); > + sec_init(); > > I will investigate this and provide a fix. Yes, I did need these two too and put them in my board code. But it's probably better to do this in do_blob, otherwise the command won't work as is for most boards and changing all of them is probably not an option. Thank you for looking into it. Cheers, Clemens > > > > Signed-off-by: Clemens Gruber > Tested-by: Breno Lima > > Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] crypto/fsl: fix BLOB encapsulation and decapsulation
Hi Fabio, Hi York, On Thu, Jan 04, 2018 at 07:59:13PM -0200, Fabio Estevam wrote: > Hi Clemens, > > On Thu, Jan 4, 2018 at 7:31 PM, Fabio Estevam wrote: > > Hi York, > > > > On Thu, Jan 4, 2018 at 7:12 PM, York Sun wrote: > > > >> This patch causes errors in almost all Freescale secure boot targets, > > ... > > > >> The error is undefined reference to `BLOB_SIZE'. Please fix. > > > > You are right. The BLOB_SIZE() macro is currently only defined for imx. > > > > Clemens, > > > > Please include the change below within your patch: > > Nevermind. I did a v2 with this change integrated and now it can build > ls2080ardb_SECURE_BOOT_defconfig. Thanks for fixing up my patch and sorry for not noticing the breakage of other configs. Will use buildman the next time I send a patch! Cheers, Clemens ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] crypto/fsl: fix BLOB encapsulation and decapsulation
Hi Sumit, Fabio, York, On Fri, Jan 05, 2018 at 06:47:36AM +, Sumit Garg wrote: > Hi Clemens, York, Fabio, > > > -Original Message- > > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Fabio > > Estevam > > Sent: Friday, January 05, 2018 3:27 AM > > To: York Sun > > Cc: Breno Matheus Lima ; u-boot@lists.denx.de; > > clemens.gru...@pqgruber.com; Fabio Estevam > > Subject: [U-Boot] [PATCH v2] crypto/fsl: fix BLOB encapsulation and > > decapsulation > > > > > > > > > int blob_decap(u8 *key_mod, u8 *src, u8 *dst, u32 len) { > > - int ret, i = 0; > > + ALLOC_CACHE_ALIGN_BUFFER(u8, aligned_key_mod, 16); > > + u8 *aligned_src, *aligned_dst; > > + int ret, size, i = 0; > > u32 *desc; > > > > printf("\nDecapsulating blob to get data\n"); > > - desc = malloc(sizeof(int) * MAX_CAAM_DESCSIZE); > > + desc = malloc_cache_aligned(sizeof(int) * MAX_CAAM_DESCSIZE); > > if (!desc) { > > debug("Not enough memory for descriptor allocation\n"); > > - return -1; > > + return -ENOMEM; > > } > > > > - inline_cnstr_jobdesc_blob_decap(desc, key_mod, src, dst, len); > > + aligned_src = malloc_cache_aligned(BLOB_SIZE(len)); > > + aligned_dst = malloc_cache_aligned(len); > > Please don't use malloc here as these blob_encap and blob_decap commands are > used to blobify or deblobify images of maximum sizes upto 32 MB. > > But u-boot malloc pool is of size: > > /* Size of malloc() pool */ > #define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 2048 * 1024) > > So please remove malloc from this patch for source and destination images as > it will fail for larger images. I could use ALLOC_CACHE_ALIGN_BUFFER to store the aligned_src and _dst buffers on the stack instead of the malloc pool. Or would you rather remove the copying and require the caller of blob_encap/_decap to pass correctly aligned addresses? York: Should I send a v3 or a fixup patch ontop of v2. Thanks, Clemens ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3] crypto/fsl: fix BLOB encapsulation and decapsulation
The blob_encap and blob_decap functions were not flushing the dcache before passing data to CAAM/DMA and not invalidating the dcache when getting data back. Therefore, blob encapsulation and decapsulation failed with errors like the following due to data cache incoherency: "4006: DECO: desc idx 0: Invalid KEY command" To ensure coherency, we require the key_mod, src and dst buffers to be aligned to the cache line size and flush/invalidate the memory regions. The same requirements apply to the job descriptor. Tested on an i.MX6Q board. Signed-off-by: Clemens Gruber --- Changes since v2: - Removed copying to aligned buffers and require addresses to be aligned - Added function comments and notes about the alignment requirements - Added parentheses around BLOB_SIZE macro parameter x - Adapted commit text Changes since v1: - Moved BLOB_SIZE define to be available for all platforms (Fabio) drivers/crypto/fsl/fsl_blob.c | 103 -- include/fsl_sec.h | 4 +- 2 files changed, 91 insertions(+), 16 deletions(-) diff --git a/drivers/crypto/fsl/fsl_blob.c b/drivers/crypto/fsl/fsl_blob.c index 38c6f9486b..cb315dfd89 100644 --- a/drivers/crypto/fsl/fsl_blob.c +++ b/drivers/crypto/fsl/fsl_blob.c @@ -7,63 +7,138 @@ #include #include +#include #include #include #include "jobdesc.h" #include "desc.h" #include "jr.h" +/** + * blob_decap() - Decapsulate the data from a blob + * @key_mod:- Key modifier address + * @src:- Source address (blob) + * @dst:- Destination address (data) + * @len:- Size of decapsulated data + * + * Note: Start and end of the key_mod, src and dst buffers have to be aligned to + * the cache line size (ARCH_DMA_MINALIGN) for the CAAM operation to succeed. + * + * Returns zero on success, negative on error. + */ int blob_decap(u8 *key_mod, u8 *src, u8 *dst, u32 len) { - int ret, i = 0; + int ret, size, i = 0; u32 *desc; + if (!IS_ALIGNED((uintptr_t)key_mod, ARCH_DMA_MINALIGN) || + !IS_ALIGNED((uintptr_t)src, ARCH_DMA_MINALIGN) || + !IS_ALIGNED((uintptr_t)dst, ARCH_DMA_MINALIGN)) { + puts("Error: blob_decap: Address arguments are not aligned!\n"); + return -EINVAL; + } + printf("\nDecapsulating blob to get data\n"); - desc = malloc(sizeof(int) * MAX_CAAM_DESCSIZE); + desc = malloc_cache_aligned(sizeof(int) * MAX_CAAM_DESCSIZE); if (!desc) { debug("Not enough memory for descriptor allocation\n"); - return -1; + return -ENOMEM; } + size = ALIGN(16, ARCH_DMA_MINALIGN); + flush_dcache_range((unsigned long)key_mod, + (unsigned long)key_mod + size); + + size = ALIGN(BLOB_SIZE(len), ARCH_DMA_MINALIGN); + flush_dcache_range((unsigned long)src, + (unsigned long)src + size); + inline_cnstr_jobdesc_blob_decap(desc, key_mod, src, dst, len); debug("Descriptor dump:\n"); for (i = 0; i < 14; i++) debug("Word[%d]: %08x\n", i, *(desc + i)); + + size = ALIGN(sizeof(int) * MAX_CAAM_DESCSIZE, ARCH_DMA_MINALIGN); + flush_dcache_range((unsigned long)desc, + (unsigned long)desc + size); + ret = run_descriptor_jr(desc); - if (ret) - printf("Error in Decapsulation %d\n", ret); - else - printf("Decapsulation Success\n"); + if (ret) { + printf("Error in blob decapsulation: %d\n", ret); + } else { + size = ALIGN(len, ARCH_DMA_MINALIGN); + invalidate_dcache_range((unsigned long)dst, + (unsigned long)dst + size); + + puts("Blob decapsulation successful.\n"); + } free(desc); return ret; } +/** + * blob_encap() - Encapsulate the data as a blob + * @key_mod:- Key modifier address + * @src:- Source address (data) + * @dst:- Destination address (blob) + * @len:- Size of data to be encapsulated + * + * Note: Start and end of the key_mod, src and dst buffers have to be aligned to + * the cache line size (ARCH_DMA_MINALIGN) for the CAAM operation to succeed. + * + * Returns zero on success, negative on error. + */ int blob_encap(u8 *key_mod, u8 *src, u8 *dst, u32 len) { - int ret, i = 0; + int ret, size, i = 0; u32 *desc; + if (!IS_ALIGNED((uintptr_t)key_mod, ARCH_DMA_MINALIGN) || + !IS_ALIGNED((uintptr_t)src, ARCH_DMA_MINALIGN) || + !IS_ALIGNED((uintptr_t)dst, ARCH_DMA_MINALIGN)) { + puts("Error: blob_encap: Address arguments are not aligned!\n"); + return -EINVAL; + } + printf
[PATCH] net: phy: marvell: Unify 88E151x series phy_driver
The PHY models of the Marvell 88E151x series are not reliably distinguishable by their uid / PHY identifiers. The 88E1510, 88E1512, 88E1514 and 88E1518 all have the same OUI and model number and bits 3:0 in the PHY Identifier 2 (Page 0, Reg 3) are described as HW revision number, but both 88E1510 and 88E1518 PHYs were observed with the same HW rev number (1). Before commit 83cfbeb0df9f ("net: phy: Fix mask so that we can identify Marvell 88E1518"), the 88E151x were detected because the HW revision bits were masked from the uid. After that change, 88E1510/12/18 were all detected as 88E1518 and the 88E1510 specific code was no longer run. I modified the mask to again ignore all four HW revision bits, removed the 88E1510 specific code (board-specific LED/INTn setup), which was not called since late 2016 anyway and renamed the config function and phy_driver struct to the better fitting 88e151x. The uid and mask bits 3:0 are now again the same as in the Linux kernel. Signed-off-by: Clemens Gruber --- drivers/net/phy/marvell.c | 65 ++- 1 file changed, 10 insertions(+), 55 deletions(-) diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c index efbbd31ff7..93cf44ad4c 100644 --- a/drivers/net/phy/marvell.c +++ b/drivers/net/phy/marvell.c @@ -303,9 +303,9 @@ static int m88es_config(struct phy_device *phydev) } /** - * m88e1518_phy_writebits - write bits to a register + * m88e151x_phy_writebits - write bits to a register */ -void m88e1518_phy_writebits(struct phy_device *phydev, +void m88e151x_phy_writebits(struct phy_device *phydev, u8 reg_num, u16 offset, u16 len, u16 data) { u16 reg, mask; @@ -323,7 +323,7 @@ void m88e1518_phy_writebits(struct phy_device *phydev, phy_write(phydev, MDIO_DEVAD_NONE, reg_num, reg); } -static int m88e1518_config(struct phy_device *phydev) +static int m88e151x_config(struct phy_device *phydev) { u16 reg; @@ -350,11 +350,11 @@ static int m88e1518_config(struct phy_device *phydev) phy_write(phydev, MDIO_DEVAD_NONE, MIIM_88E1118_PHY_PAGE, 18); /* In reg 20, write MODE[2:0] = 0x1 (SGMII to Copper) */ - m88e1518_phy_writebits(phydev, MIIM_88E151x_GENERAL_CTRL, + m88e151x_phy_writebits(phydev, MIIM_88E151x_GENERAL_CTRL, 0, 3, MIIM_88E151x_MODE_SGMII); /* PHY reset is necessary after changing MODE[2:0] */ - m88e1518_phy_writebits(phydev, MIIM_88E151x_GENERAL_CTRL, + m88e151x_phy_writebits(phydev, MIIM_88E151x_GENERAL_CTRL, MIIM_88E151x_RESET_OFFS, 1, 1); /* Reset page selection */ @@ -401,33 +401,6 @@ static int m88e1518_config(struct phy_device *phydev) return 0; } -/* Marvell 88E1510 */ -static int m88e1510_config(struct phy_device *phydev) -{ - /* Select page 3 */ - phy_write(phydev, MDIO_DEVAD_NONE, MIIM_88E1118_PHY_PAGE, - MIIM_88E1118_PHY_LED_PAGE); - - /* Enable INTn output on LED[2] */ - m88e1518_phy_writebits(phydev, MIIM_88E151x_LED_TIMER_CTRL, - MIIM_88E151x_INT_EN_OFFS, 1, 1); - - /* Configure LEDs */ - /* LED[0]:0011 (ACT) */ - m88e1518_phy_writebits(phydev, MIIM_88E151x_LED_FUNC_CTRL, - MIIM_88E151x_LED0_OFFS, MIIM_88E151x_LED_FLD_SZ, - MIIM_88E151x_LED0_ACT); - /* LED[1]:0110 (LINK 100/1000 Mbps) */ - m88e1518_phy_writebits(phydev, MIIM_88E151x_LED_FUNC_CTRL, - MIIM_88E151x_LED1_OFFS, MIIM_88E151x_LED_FLD_SZ, - MIIM_88E151x_LED1_100_1000_LINK); - - /* Reset page selection */ - phy_write(phydev, MDIO_DEVAD_NONE, MIIM_88E1118_PHY_PAGE, 0); - - return m88e1518_config(phydev); -} - /* Marvell 88E1118 */ static int m88e1118_config(struct phy_device *phydev) { @@ -685,29 +658,12 @@ static struct phy_driver M88E1149S_driver = { .shutdown = &genphy_shutdown, }; -static struct phy_driver M88E1510_driver = { - .name = "Marvell 88E1510", - .uid = 0x1410dd0, - .mask = 0xfff, - .features = PHY_GBIT_FEATURES, - .config = &m88e1510_config, - .startup = &m88e1011s_startup, - .shutdown = &genphy_shutdown, - .readext = &m88e1xxx_phy_extread, - .writeext = &m88e1xxx_phy_extwrite, -}; - -/* - * This supports: - * 88E1518, uid 0x1410dd1 - * 88E1512, uid 0x1410dd4 - */ -static struct phy_driver M88E1518_driver = { - .name = "Marvell 88E1518", +static struct phy_driver M88E151x_driver = { + .name = "Marvell 88E151x", .uid = 0x1410dd0, - .mask = 0xffa, + .mask = 0xff0, .features = PHY_GBIT_FEATURES, - .config = &m88e1518_config, +
[PATCH] rtc: ds1337: fix compatible string typo
The driver supports the ds1339 as well, which was probably intended by the author but prevented by a typo. Fix the typo. Signed-off-by: Clemens Gruber --- drivers/rtc/ds1337.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/ds1337.c b/drivers/rtc/ds1337.c index 4986c96f86..486c01f9ba 100644 --- a/drivers/rtc/ds1337.c +++ b/drivers/rtc/ds1337.c @@ -306,7 +306,7 @@ static const struct rtc_ops ds1337_rtc_ops = { static const struct udevice_id ds1337_rtc_ids[] = { { .compatible = "ds1337" }, { .compatible = "ds1338" }, - { .compatible = "ds1338" }, + { .compatible = "ds1339" }, { } }; -- 2.33.1
[U-Boot] [PATCH] Add support for the Marvell 88E1510 phy, based on the existing 88E1518 support
Signed-off-by: Clemens Gruber --- drivers/net/phy/marvell.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c index 9437c3b..e501769 100644 --- a/drivers/net/phy/marvell.c +++ b/drivers/net/phy/marvell.c @@ -539,6 +539,16 @@ static struct phy_driver M88E1149S_driver = { .shutdown = &genphy_shutdown, }; +static struct phy_driver M88E1510_driver = { + .name = "Marvell 88E1510", + .uid = 0x1410dd0, + .mask = 0xff0, + .features = PHY_GBIT_FEATURES, + .config = &m88e1518_config, + .startup = &m88e1011s_startup, + .shutdown = &genphy_shutdown, +}; + static struct phy_driver M88E1518_driver = { .name = "Marvell 88E1518", .uid = 0x1410dd1, @@ -569,6 +579,7 @@ int phy_marvell_init(void) phy_register(&M88E1118R_driver); phy_register(&M88ES_driver); phy_register(&M88E1011S_driver); + phy_register(&M88E1510_driver); phy_register(&M88E1518_driver); return 0; -- 2.4.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Do not mux and setup SPI if disabled in the config
This allows baseboards without SPI to compile. Signed-off-by: Clemens Gruber Cc: Markus Niebel Cc: Tom Rini --- board/tqc/tqma6/tqma6.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/board/tqc/tqma6/tqma6.c b/board/tqc/tqma6/tqma6.c index 29db838..5c4d104 100644 --- a/board/tqc/tqma6/tqma6.c +++ b/board/tqc/tqma6/tqma6.c @@ -131,6 +131,8 @@ int board_mmc_init(bd_t *bis) return 0; } +#if defined(CONFIG_MXC_SPI) + static iomux_v3_cfg_t const tqma6_ecspi1_pads[] = { /* SS1 */ NEW_PAD_CTRL(MX6_PAD_EIM_D19__GPIO3_IO19, SPI_PAD_CTRL), @@ -161,6 +163,8 @@ int board_spi_cs_gpio(unsigned bus, unsigned cs) (cs == CONFIG_SF_DEFAULT_CS)) ? TQMA6_SF_CS_GPIO : -1; } +#endif /* defined(CONFIG_MXC_SPI) */ + static struct i2c_pads_info tqma6_i2c3_pads = { /* I2C3: on board LM75, M24C64, */ .scl = { @@ -201,7 +205,9 @@ int board_init(void) /* address of boot parameters */ gd->bd->bi_boot_params = PHYS_SDRAM + 0x100; +#if defined(CONFIG_MXC_SPI) tqma6_iomuxc_spi(); +#endif tqma6_setup_i2c(); tqma6_bb_board_init(); -- 2.5.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Do not mux and setup SPI if disabled in the config
Hi Stefan, On Wed, Aug 05, 2015 at 07:19:02AM +0200, Stefan Roese wrote: > (added Stefano as imx custodian) Thanks. > > On 04.08.2015 19:28, Clemens Gruber wrote: > > This allows baseboards without SPI to compile. > > > > Signed-off-by: Clemens Gruber > > Cc: Markus Niebel > > Cc: Tom Rini > > --- > > board/tqc/tqma6/tqma6.c | 6 ++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/board/tqc/tqma6/tqma6.c b/board/tqc/tqma6/tqma6.c > > index 29db838..5c4d104 100644 > > --- a/board/tqc/tqma6/tqma6.c > > +++ b/board/tqc/tqma6/tqma6.c > > @@ -131,6 +131,8 @@ int board_mmc_init(bd_t *bis) > > return 0; > > } > > > > +#if defined(CONFIG_MXC_SPI) > > + > > static iomux_v3_cfg_t const tqma6_ecspi1_pads[] = { > > /* SS1 */ > > NEW_PAD_CTRL(MX6_PAD_EIM_D19__GPIO3_IO19, SPI_PAD_CTRL), > > @@ -161,6 +163,8 @@ int board_spi_cs_gpio(unsigned bus, unsigned cs) > > (cs == CONFIG_SF_DEFAULT_CS)) ? TQMA6_SF_CS_GPIO : -1; > > } > > > > +#endif /* defined(CONFIG_MXC_SPI) */ > > + > > static struct i2c_pads_info tqma6_i2c3_pads = { > > /* I2C3: on board LM75, M24C64, */ > > .scl = { > > @@ -201,7 +205,9 @@ int board_init(void) > > /* address of boot parameters */ > > gd->bd->bi_boot_params = PHYS_SDRAM + 0x100; > > > > +#if defined(CONFIG_MXC_SPI) > > tqma6_iomuxc_spi(); > > +#endif > > tqma6_setup_i2c(); > > Hmmm. This should not be necessary. Please take a look at the wru4 > baseboard addition that is already in mainline. Especially this > patch: I noticed your patch but then we would still have to define CONFIG_SF_DEFAULT_BUS and CONFIG_SF_DEFAULT_CS in our board config or include the tqma6.h config, which defines too many things we do not need. The problem is, we have different clocks and more c files, so we use a separate board directory and a separate board config without SPI defines and just use obj-y += ../../tqc/tqma6/tqma6.o in front of our object files in the Makefile. If we don't exclude those SPI parts, we would either have to define those SPI config options (which does not make sense) or move all of our board code in one file under tqc/tqma6 which is not an option, we also define additional clocks via a separate IMX_CONFIG file. Wouldn't it be better to always exclude this code when not using SPI instead of weakly defining the tqma6_iomuxc_spi function? Then small baseboards could be put in tqc/tqma6 and larger projects could still just link to tqma6.o and put all their stuff in a separate board directory. > > commit 34ee786e5b388625e5a0e0891ee69d4bbf34178b > Author: Stefan Roese > Date: Thu Mar 12 13:34:30 2015 +0100 > > arm: mx6: tqma6: Update to optionally configure an alternative SPI setup > > By making the tqma6_iomuxc_spi() weak, this patch adds the possibility to > add a different function for this SPI configuration. This can be used > by other baseboards, that might have a different SPI setup. > > This patch will be used by the upcoming WRU-IV board support which also > uses the TQMa6 SoM. > > Signed-off-by: Stefan Roese > > > This is enough in your baseboard file now: > > void tqma6_iomuxc_spi(void) > { > /* No SPI on this baseboard */ > } > > Thanks, > Stefan > Regards, Clemens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Do not mux and setup SPI if disabled in the config
Hi Stefan, On Wed, Aug 05, 2015 at 10:05:10AM +0200, Stefan Roese wrote: > How about this patch: > > diff --git a/board/tqc/tqma6/tqma6.c b/board/tqc/tqma6/tqma6.c > index 29db838..345930f 100644 > --- a/board/tqc/tqma6/tqma6.c > +++ b/board/tqc/tqma6/tqma6.c > @@ -28,6 +28,13 @@ > > #include "tqma6_bb.h" > > +#ifndef CONFIG_SF_DEFAULT_BUS > +#define CONFIG_SF_DEFAULT_BUS 0 > +#endif > +#ifndef CONFIG_SF_DEFAULT_CS > +#define CONFIG_SF_DEFAULT_CS 0 > +#endif > > Does this work for you? This should work, but wouldn't it be cleaner to just exclude the SPI parts? Why add 7 LOC when 4 LOC are enough to exclude the SPI parts? Besides that, it reduces the binary size. Then we could also remove the empty SPI function from all board files, if SPI is not used. > > Thanks, > Stefan Regards, Clemens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Do not mux and setup SPI if disabled in the config
On Wed, Aug 05, 2015 at 01:46:42PM +0530, Jagan Teki wrote: > On 5 August 2015 at 13:35, Stefan Roese wrote: > > How about this patch: > > > > diff --git a/board/tqc/tqma6/tqma6.c b/board/tqc/tqma6/tqma6.c > > index 29db838..345930f 100644 > > --- a/board/tqc/tqma6/tqma6.c > > +++ b/board/tqc/tqma6/tqma6.c > > @@ -28,6 +28,13 @@ > > > > #include "tqma6_bb.h" > > > > +#ifndef CONFIG_SF_DEFAULT_BUS > > +#define CONFIG_SF_DEFAULT_BUS 0 > > +#endif > > +#ifndef CONFIG_SF_DEFAULT_CS > > +#define CONFIG_SF_DEFAULT_CS 0 > > +#endif > > Why would need this - it's already part of spi_flash.h I am also wondering about commit f85764cc1f6ab01ffc60dd78de9c4de4cff2b5ce, which defines CONFIG_SPI_FLASH in the WRU4 defconfig file, even though it does not need SPI flash support, just to work around undefined reference errors regarding spi_flash_free, etc. Couldn't those workarounds be avoided by excluding the SPI parts via ifdefs, as I did in my patch today? > > > > > Does this work for you? > > thanks! > -- > Jagan | openedev. Thanks, Clemens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: mx6: Remove SPI support from WRU-IV baseboard
Hi Stefano, Hi Stefan, On Wed, Aug 05, 2015 at 11:00:56AM +0200, Stefano Babic wrote: > Hi Stefan, Clemens, > > I read the thread - Clemens, can you send your Tested-by after you > tested with success the patch ? I will apply it, then.. > > Best regards, > Stefano Babic Although I am not convinced that ifdefs are as bad as Stefan thinks they are, the new patch works fine too. Thank you! Tested-by: Clemens Gruber Regards, Clemens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] net: Support Marvell 88E1510 and fix 88E151x init
Hi, I improved the Errata fixup for Marvell 88E151x Ethernet PHYs and added support for the 88E1510 which is very similar to the 88E1518. I also configured the LEDs and the INTn output for the 88E1510. Best regards, Clemens Gruber Clemens Gruber (2): net: Improve 88E151x PHY initialization net: Add support for Marvell 88E1510 PHY drivers/net/phy/marvell.c | 67 +-- 1 file changed, 53 insertions(+), 14 deletions(-) -- 2.4.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] net: Improve 88E151x PHY initialization
- The EEE fixup magic should also be enabled for RGMII - Improved comments Signed-off-by: Clemens Gruber Cc: Joe Hershberger Cc: Hao Zhang Cc: Michal Simek --- drivers/net/phy/marvell.c | 37 +++-- 1 file changed, 23 insertions(+), 14 deletions(-) diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c index 9437c3b..cff5c87 100644 --- a/drivers/net/phy/marvell.c +++ b/drivers/net/phy/marvell.c @@ -303,24 +303,33 @@ static int m88e1518_config(struct phy_device *phydev) * As per Marvell Release Notes - Alaska 88E1510/88E1518/88E1512 * /88E1514 Rev A0, Errata Section 3.1 */ + + /* EEE initialization */ + phy_write(phydev, MDIO_DEVAD_NONE, 22, 0x00ff); + phy_write(phydev, MDIO_DEVAD_NONE, 17, 0x214B); + phy_write(phydev, MDIO_DEVAD_NONE, 16, 0x2144); + phy_write(phydev, MDIO_DEVAD_NONE, 17, 0x0C28); + phy_write(phydev, MDIO_DEVAD_NONE, 16, 0x2146); + phy_write(phydev, MDIO_DEVAD_NONE, 17, 0xB233); + phy_write(phydev, MDIO_DEVAD_NONE, 16, 0x214D); + phy_write(phydev, MDIO_DEVAD_NONE, 17, 0xCC0C); + phy_write(phydev, MDIO_DEVAD_NONE, 16, 0x2159); + phy_write(phydev, MDIO_DEVAD_NONE, 22, 0x); + + /* SGMII-to-Copper mode initialization */ if (phydev->interface == PHY_INTERFACE_MODE_SGMII) { - phy_write(phydev, MDIO_DEVAD_NONE, 22, 0x00ff); /* page 0xff */ - phy_write(phydev, MDIO_DEVAD_NONE, 17, 0x214B); - phy_write(phydev, MDIO_DEVAD_NONE, 16, 0x2144); - phy_write(phydev, MDIO_DEVAD_NONE, 17, 0x0C28); - phy_write(phydev, MDIO_DEVAD_NONE, 16, 0x2146); - phy_write(phydev, MDIO_DEVAD_NONE, 17, 0xB233); - phy_write(phydev, MDIO_DEVAD_NONE, 16, 0x214D); - phy_write(phydev, MDIO_DEVAD_NONE, 17, 0xCC0C); - phy_write(phydev, MDIO_DEVAD_NONE, 16, 0x2159); - phy_write(phydev, MDIO_DEVAD_NONE, 22, 0x); /* reg page 0 */ - phy_write(phydev, MDIO_DEVAD_NONE, 22, 18);/* reg page 18 */ - /* Write HWCFG_MODE = SGMII to Copper */ + /* Select page 18 */ + phy_write(phydev, MDIO_DEVAD_NONE, 22, 18); + + /* In reg 20, write MODE[2:0] = 0x1 (SGMII to Copper) */ m88e1518_phy_writebits(phydev, 20, 0, 3, 1); - /* Phy reset */ + /* PHY reset is necessary after changing MODE[2:0] */ m88e1518_phy_writebits(phydev, 20, 15, 1, 1); - phy_write(phydev, MDIO_DEVAD_NONE, 22, 0); /* reg page 18 */ + + /* Reset page selection */ + phy_write(phydev, MDIO_DEVAD_NONE, 22, 0); + udelay(100); } -- 2.4.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] net: Add support for Marvell 88E1510 PHY
Support the 88E1510 PHY which is very similar to the 88E1518. I also set the INTn output and configured the LEDs. Signed-off-by: Clemens Gruber Cc: Joe Hershberger Cc: Hao Zhang Cc: Michal Simek --- This replaces the previously sent patch http://patchwork.ozlabs.org/patch/478488/ --- drivers/net/phy/marvell.c | 30 ++ 1 file changed, 30 insertions(+) diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c index cff5c87..eab1558 100644 --- a/drivers/net/phy/marvell.c +++ b/drivers/net/phy/marvell.c @@ -336,6 +336,25 @@ static int m88e1518_config(struct phy_device *phydev) return m88es_config(phydev); } +/* Marvell 88E1510 */ +static int m88e1510_config(struct phy_device *phydev) +{ + /* Select page 3 */ + phy_write(phydev, MDIO_DEVAD_NONE, 22, 3); + + /* Enable INTn output on LED[2] */ + m88e1518_phy_writebits(phydev, 18, 7, 1, 1); + + /* Configure LEDs */ + m88e1518_phy_writebits(phydev, 16, 0, 4, 3); /* LED[0]:0011 (ACT) */ + m88e1518_phy_writebits(phydev, 16, 4, 4, 6); /* LED[1]:0110 (LINK) */ + + /* Reset page selection */ + phy_write(phydev, MDIO_DEVAD_NONE, 22, 0); + + return m88e1518_config(phydev); +} + /* Marvell 88E1118 */ static int m88e1118_config(struct phy_device *phydev) { @@ -548,6 +567,16 @@ static struct phy_driver M88E1149S_driver = { .shutdown = &genphy_shutdown, }; +static struct phy_driver M88E1510_driver = { + .name = "Marvell 88E1510", + .uid = 0x1410dd0, + .mask = 0xff0, + .features = PHY_GBIT_FEATURES, + .config = &m88e1510_config, + .startup = &m88e1011s_startup, + .shutdown = &genphy_shutdown, +}; + static struct phy_driver M88E1518_driver = { .name = "Marvell 88E1518", .uid = 0x1410dd1, @@ -578,6 +607,7 @@ int phy_marvell_init(void) phy_register(&M88E1118R_driver); phy_register(&M88ES_driver); phy_register(&M88E1011S_driver); + phy_register(&M88E1510_driver); phy_register(&M88E1518_driver); return 0; -- 2.4.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] env_mmc: support overriding mmc dev from board code
This enables boards to choose where to/from the environment should be saved/loaded. They can then for example support using the same device (dynamically) from which the bootloader was launched to load and save env data and do not have to define CONFIG_SYS_MMC_ENV_DEV statically. In my use case, the environment needs to be on the same device I booted from. It can be the eMMC or an optional SD card. I therefore would override mmc_get_env_dev in the board code, read the CPU registers to determine where we booted from and return the corresponding device index. Cc: Tom Rini Cc: Stephen Warren Cc: Tim Harvey Cc: Simon Glass Cc: Hans de Goede Signed-off-by: Clemens Gruber --- common/env_mmc.c | 19 --- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/common/env_mmc.c b/common/env_mmc.c index 15aa43d..bdb452e 100644 --- a/common/env_mmc.c +++ b/common/env_mmc.c @@ -54,6 +54,11 @@ __weak int mmc_get_env_addr(struct mmc *mmc, int copy, u32 *env_addr) return 0; } +__weak int mmc_get_env_dev(void) +{ + return CONFIG_SYS_MMC_ENV_DEV; +} + int env_init(void) { /* use default */ @@ -74,7 +79,7 @@ static unsigned char env_mmc_orig_hwpart; static int mmc_set_env_part(struct mmc *mmc) { uint part = mmc_get_env_part(mmc); - int dev = CONFIG_SYS_MMC_ENV_DEV; + int dev = mmc_get_env_dev(); int ret = 0; #ifdef CONFIG_SPL_BUILD @@ -109,7 +114,7 @@ static const char *init_mmc_for_env(struct mmc *mmc) static void fini_mmc_for_env(struct mmc *mmc) { #ifdef CONFIG_SYS_MMC_ENV_PART - int dev = CONFIG_SYS_MMC_ENV_DEV; + int dev = mmc_get_env_dev(); #ifdef CONFIG_SPL_BUILD dev = 0; @@ -140,7 +145,8 @@ static unsigned char env_flags; int saveenv(void) { ALLOC_CACHE_ALIGN_BUFFER(env_t, env_new, 1); - struct mmc *mmc = find_mmc_device(CONFIG_SYS_MMC_ENV_DEV); + int dev = mmc_get_env_dev(); + struct mmc *mmc = find_mmc_device(dev); u32 offset; int ret, copy = 0; const char *errmsg; @@ -167,8 +173,7 @@ int saveenv(void) goto fini; } - printf("Writing to %sMMC(%d)... ", copy ? "redundant " : "", - CONFIG_SYS_MMC_ENV_DEV); + printf("Writing to %sMMC(%d)... ", copy ? "redundant " : "", dev); if (write_env(mmc, CONFIG_ENV_SIZE, offset, (u_char *)env_new)) { puts("failed\n"); ret = 1; @@ -212,7 +217,7 @@ void env_relocate_spec(void) int crc1_ok = 0, crc2_ok = 0; env_t *ep; int ret; - int dev = CONFIG_SYS_MMC_ENV_DEV; + int dev = mmc_get_env_dev(); const char *errmsg = NULL; ALLOC_CACHE_ALIGN_BUFFER(env_t, tmp_env1, 1); @@ -298,7 +303,7 @@ void env_relocate_spec(void) struct mmc *mmc; u32 offset; int ret; - int dev = CONFIG_SYS_MMC_ENV_DEV; + int dev = mmc_get_env_dev(); const char *errmsg; #ifdef CONFIG_SPL_BUILD -- 2.7.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] env_mmc: support overriding mmc dev from board code
On Tue, Jan 26, 2016 at 10:53:58AM +0800, Peng Fan wrote: > Yeah. The patch I wrote include fix write_env, and a function prototype in > header file. > > If the current patch already applied, I can write a follow up patch. > > Thanks, > Peng. > Hi Peng, sorry, I did not know there was already a similar patch. However, now when looking over your patch, it tries to fix read_env and write_env, which is not necessary, because the device number is stored in struct mmc. What's missing though is the function prototype in the header. Tom, should I send a v2 of the patch or a follow-up? Or do you want to fix this up, Peng? Thanks. Clemens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mmc: add missing prototype for mmc_get_env_dev
This is a follow-up patch to e92029c0f4 and adds a prototype for the weak mmc_get_env_dev function. Cc: Tom Rini Cc: Stephen Warren Signed-off-by: Clemens Gruber --- include/mmc.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/mmc.h b/include/mmc.h index 465daeb..d652c14 100644 --- a/include/mmc.h +++ b/include/mmc.h @@ -479,6 +479,7 @@ void board_mmc_power_init(void); int board_mmc_init(bd_t *bis); int cpu_mmc_init(bd_t *bis); int mmc_get_env_addr(struct mmc *mmc, int copy, u32 *env_addr); +int mmc_get_env_dev(void); struct pci_device_id; -- 2.7.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] CACHE: Misaligned operation
Hi, I just tested the current U-Boot master on my i.MX6Q board and the following two warnings showed up on the console: U-Boot 2016.09-rc1-00377-gb8698a2 CPU: Freescale i.MX6Q rev1.5 at 792 MHz Reset cause: POR DRAM: 1 GiB CACHE: Misaligned operation at range [4fff, 4fff0004] CACHE: Misaligned operation at range [4fff0024, 4fff0028] (But everything works fine, as far as I can tell for now) I did a git bisect and found out that these two warning messages are shown since commit 96e451bfa39b (arm: Show cache warnings in U-Boot proper only), where a debug statement was changed to a non-SPL warning. Was this intentional and is this warning something to be worried about? If not, we could add a new macro debug_non_spl with debug_cond !_SPL_BUILD && DEBUG and use that in check_cache_range. What do you think? Thanks, Clemens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] CACHE: Misaligned operation
Hi, On Fri, Aug 12, 2016 at 09:27:29AM -0600, Simon Glass wrote: > Yes it means there is an error in the calling code. If you can figure > out who is calling this then it is worth fixing. But also see recent > discussions on the mailing list. Also possibly this patch? > > http://patchwork.ozlabs.org/patch/656474/ Thank you! Yes, this patch seems to fix the error. At least I can see no more warnings at boot. Will look into it more thoroughly next week and report back if there is still a problem. Regards, Clemens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] mmc: fsl_esdhc: fix misaligned cache operation warning
When using gzwrite to eMMC on an i.MX6Q board, the following warning occurs repeatedly: CACHE: Misaligned operation at range [4fd63318, 4fe63318] I tried to cache-line align the start and end parameter for flush_dcache_range in esdhc_setup_data. (Same approach as in https://patchwork.ozlabs.org/patch/656470/) After that, the "Misaligned operation" error message disappeared and everything still works for me. But is this safe and should I send the patch again with [PATCH] ? Signed-off-by: Clemens Gruber --- drivers/mmc/fsl_esdhc.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index 103b32e..f40b424 100644 --- a/drivers/mmc/fsl_esdhc.c +++ b/drivers/mmc/fsl_esdhc.c @@ -222,6 +222,7 @@ static int esdhc_setup_data(struct mmc *mmc, struct mmc_data *data) dma_addr_t addr; #endif uint wml_value; + ulong start, end; wml_value = data->blocksize/4; @@ -243,9 +244,11 @@ static int esdhc_setup_data(struct mmc *mmc, struct mmc_data *data) #endif } else { #ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO - flush_dcache_range((ulong)data->src, - (ulong)data->src+data->blocks -*data->blocksize); + start = (ulong)data->src; + start &= ~(CONFIG_SYS_CACHELINE_SIZE - 1); + end = ALIGN((ulong)data->src + data->blocks * data->blocksize, + CONFIG_SYS_CACHELINE_SIZE); + flush_dcache_range(start, end); #endif if (wml_value > WML_WR_WML_MAX) wml_value = WML_WR_WML_MAX_VAL; -- 2.9.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] gunzip: cache-align write buffer memory
When using gzwrite to eMMC on an i.MX6Q board, the following warning occurs repeatedly: CACHE: Misaligned operation at range [4fd63318, 4fe63318] This patch cache-aligns the memory allocation for the gzwrite writebuf, therefore avoiding the misaligned dcache flush and the warning from check_cache_range. Signed-off-by: Clemens Gruber --- lib/gunzip.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/gunzip.c b/lib/gunzip.c index bc746d6..832b306 100644 --- a/lib/gunzip.c +++ b/lib/gunzip.c @@ -11,6 +11,7 @@ #include #include #include +#include #include #include @@ -193,7 +194,7 @@ int gzwrite(unsigned char *src, int len, s.next_in = src + i; s.avail_in = payload_size+8; - writebuf = (unsigned char *)malloc(szwritebuf); + writebuf = (unsigned char *)malloc_cache_aligned(szwritebuf); /* decompress until deflate stream ends or end of file */ do { -- 2.9.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] mmc: fsl_esdhc: fix misaligned cache operation warning
Hi, On Sun, Aug 28, 2016 at 04:55:36PM -0700, Stefan Agner wrote: > Hm, that seems dangerous to me, especially the src rounding... > > Not sure where that memory gets aligned, but I guess we should use > memalign and align the length to cache size or the like... Yes, you are right. I looked into this some more and found the source of the problem is actually in lib/gunzip.c and not the flush_dcache_range call in fsl_esdhc.c. I sent a new patch to cache-align the memory allocation in gzwrite. Regards, Clemens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot