[PATCH] rtc: ds1337: fix compatible string typo

[Clemens Gruber]

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

[PATCH] net: phy: marvell: Unify 88E151x series phy_driver

[Clemens Gruber]

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 = _shutdown,
 };
 
-static struct phy_driver M88E1510_driver = {
-   .name = "Marvell 88E1510",
-   .uid = 0x1410dd0,
-   .mask = 0xfff,
-   .features = PHY_GBIT_FEATURES,
-   .config = _config,
-   .startup = _startup,
-   .shutdown = _shutdown,
-   .readext = _phy_extread,
-   .writeext = _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 = _config,
+   .config = _config,
.startup = _startup,
.shutdown = _shutdown,
.readext

[U-Boot] [PATCH v3] crypto/fsl: fix BLOB encapsulation and decapsulation

[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 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 <clemens.gru...@pqgruber.com>
---

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");
+   re

Re: [U-Boot] [PATCH v2] crypto/fsl: fix BLOB encapsulation and decapsulation

[Clemens Gruber]

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

Re: [U-Boot] [PATCH] crypto/fsl: fix BLOB encapsulation and decapsulation

[Clemens Gruber]

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] crypto/fsl: fix BLOB encapsulation and decapsulation

[Clemens Gruber]

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 <clemens.gru...@pqgruber.com>:
> > 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 <clemens.gru...@pqgruber.com>
> Tested-by: Breno Lima <breno.l...@nxp.com>
> 
> Thanks
___
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

[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.

Signed-off-by: Clemens Gruber <clemens.gru...@pqgruber.com>
---
 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);
+   fl

[U-Boot] i.MX6 CAAM BLOB problem: Invalid KEY Command

[Clemens Gruber]

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=moderatedWithoutFAE
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] crypto/fsl: fix obj-yy in Makefile

[Clemens Gruber]

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 <clemens.gru...@pqgruber.com>
---
 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

Re: [U-Boot] [PATCH] gunzip: cache-align write buffer memory

[Clemens Gruber]

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 <clemens.gru...@pqgruber.com>
> ---
>  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

Re: [U-Boot] [RFC] mmc: fsl_esdhc: fix misaligned cache operation warning

[Clemens Gruber]

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

[U-Boot] [PATCH] gunzip: cache-align write buffer memory

[Clemens Gruber]

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 <clemens.gru...@pqgruber.com>
---
 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

[U-Boot] [RFC] mmc: fsl_esdhc: fix misaligned cache operation warning

[Clemens Gruber]

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 <clemens.gru...@pqgruber.com>
---
 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

Re: [U-Boot] CACHE: Misaligned operation

[Clemens Gruber]

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] CACHE: Misaligned operation

[Clemens Gruber]

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] env_mmc: support overriding mmc dev from board code

[Clemens Gruber]

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

[Clemens Gruber]

This is a follow-up patch to e92029c0f4 and adds a prototype for
the weak mmc_get_env_dev function.

Cc: Tom Rini <tr...@konsulko.com>
Cc: Stephen Warren <swar...@nvidia.com>

Signed-off-by: Clemens Gruber <clemens.gru...@pqgruber.com>
---
 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] [PATCH] env_mmc: support overriding mmc dev from board code

[Clemens Gruber]

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 <tr...@konsulko.com>
Cc: Stephen Warren <swar...@nvidia.com>
Cc: Tim Harvey <thar...@gateworks.com>
Cc: Simon Glass <s...@chromium.org>
Cc: Hans de Goede <hdego...@redhat.com>

Signed-off-by: Clemens Gruber <clemens.gru...@pqgruber.com>

---
 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] [PATCH] Do not mux and setup SPI if disabled in the config

[Clemens Gruber]

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 clemens.gru...@pqgruber.com
  Cc: Markus Niebel markus.nie...@tq-group.com
  Cc: Tom Rini tr...@konsulko.com
  ---
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 s...@denx.de
 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 s...@denx.de
 
 
 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

[Clemens Gruber]

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

[Clemens Gruber]

On Wed, Aug 05, 2015 at 01:46:42PM +0530, Jagan Teki wrote:
 On 5 August 2015 at 13:35, Stefan Roese s...@denx.de 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

[Clemens Gruber]

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 clemens.gru...@pqgruber.com

Regards,
Clemens
___
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

[Clemens Gruber]

This allows baseboards without SPI to compile.

Signed-off-by: Clemens Gruber clemens.gru...@pqgruber.com
Cc: Markus Niebel markus.nie...@tq-group.com
Cc: Tom Rini tr...@konsulko.com
---
 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

[U-Boot] [PATCH 1/2] net: Improve 88E151x PHY initialization

[Clemens Gruber]

- The EEE fixup magic should also be enabled for RGMII
- Improved comments

Signed-off-by: Clemens Gruber clemens.gru...@pqgruber.com
Cc: Joe Hershberger joe.hershber...@ni.com
Cc: Hao Zhang hzh...@ti.com
Cc: Michal Simek michal.si...@xilinx.com
---
 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

[Clemens Gruber]

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 clemens.gru...@pqgruber.com
Cc: Joe Hershberger joe.hershber...@ni.com
Cc: Hao Zhang hzh...@ti.com
Cc: Michal Simek michal.si...@xilinx.com

---
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 0/2] net: Support Marvell 88E1510 and fix 88E151x init

[Clemens Gruber]

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] Add support for the Marvell 88E1510 phy, based on the existing 88E1518 support

[Clemens Gruber]

Signed-off-by: Clemens Gruber clemens.gru...@pqgruber.com
---
 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