Re: [U-Boot] [PATCH] libfdt: use CONFIG_IS_ENABLED for OF_LIBFDT

2017-02-13 Thread Lokesh Vutla


On Monday 13 February 2017 01:04 PM, Vignesh R wrote:
> Use CONFIG_IS_ENABLED() macro to check whether OF_LIBFDT is enabled, so
> that code block is compiled irrespective of SPL or U-Boot build
> depending on CONFIG_SPL_OF_LIBFDT(for SPL) or CONFIG_OF_LIBFDT(for
> U-Boot).
> 
> Signed-off-by: Vignesh R 

Reviewed-by: Lokesh Vutla 

Thanks and regards,
Lokesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] of-platdata address map decode for 64-bits

2017-02-13 Thread Kever Yang

Hi Simon,

On 02/08/2017 01:10 PM, Simon Glass wrote:

Hi Kever,

On 4 February 2017 at 16:30, Kever Yang  wrote:

Hi Simon,

 For rk3399, the data for sdram driver in dts is big, I don't want to do
the copy for it,

Are you referring to the call to fdtdec_get_int_array()? Don't you
have heaps of SRAM though? So why does it matter? If you are really
worried about it you could loop through the data word by word instead.


I don't understand how to "loop through the data word by word".

But why?


so I think use of-platdata is a good method, and for image size, its
smaller, then it's sooner to load.

Yes it reduces the image size, but only by a small amount. I have not
checked it on ARM64 but it should be around 5KB. I don't think it is
very important.


Here is why I insist on no more extra operation and extra code in SPL,
- The CPU in bootrom usually running in pretty low frequency, the copy 
may be slow;

- The eMMC in bootrom is running in pretty low frequency, the read is slow;
- Not like kernel or U-Boot, I don't think the dts values much for SPL,
Most of driver used in SPL is one time init, and may totally 
different in
different SoC, including clock/cru driver, pinctrl/grf driver, dram 
driver, only

storage driver is shared in different SoC and different boot stage.
IMO, the SPL suppose to be simple, fast to init dram and load next stage 
image(if

we do not go back to bootrom).

For production, I have do many times to speed up the boot duration in 
different SoCs,
so I hope the upstream U-Boot for Rockchip SoC is not only for 
developers. We should
care about the size even if the size is enough for boot, the size design 
is not only consider
the boot, but also for some application in system suspend which dram 
suspend.


Thanks,
- Kever


Regards,
Simon



Thanks,
- Kever

On 01/26/2017 10:22 PM, Simon Glass wrote:

Hi Kever,

On 17 January 2017 at 23:37, Kever Yang  wrote:

Hi Simon,

  For my rk3399(64bit) dts, the address is described as below:
#address-cells = <2>;
reg = <0x0 0xfe32 0x0 0x4000>;

not like 32-bit soc which reg address describe like:
reg = <0xfe32 0x4000>;

  There should have some update for this dts decode, right?
like:
map_sysmem()
regmap_init_mem_platdata()

  Do you have a idea to update all these kind of function call?
It will be very great if you can send a patch for it.

Thanks,
- Kever


Yes I think so.

But first I'd like to understand why we need to use of-platdata on
this very modern SoC. Can you tell me the maximum SPL size you can
support on this SoC? I thought you had removed the 30KB limit?

Using of-platdata only saves 3-4KB.

Regards,
Simon











___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] regmap: add support for address cell 2

2017-02-13 Thread Kever Yang
ARM64 is using 64bit address which address cell is 2 instead of 1,
update to support it when of-platdata enabled.

Signed-off-by: Kever Yang 
---

 drivers/core/regmap.c | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
index c68bcba..a1c0983 100644
--- a/drivers/core/regmap.c
+++ b/drivers/core/regmap.c
@@ -39,6 +39,16 @@ static struct regmap *regmap_alloc_count(int count)
 }
 
 #if CONFIG_IS_ENABLED(OF_PLATDATA)
+u64 fdtdec_get_number(const u32 *ptr, unsigned int cells)
+{
+   u64 number = 0;
+
+   while (cells--)
+   number = (number << 32) | (*ptr++);
+
+   return number;
+}
+
 int regmap_init_mem_platdata(struct udevice *dev, u32 *reg, int count,
 struct regmap **mapp)
 {
@@ -48,13 +58,19 @@ int regmap_init_mem_platdata(struct udevice *dev, u32 *reg, 
int count,
map = regmap_alloc_count(count);
if (!map)
return -ENOMEM;
-
+#ifdef CONFIG_ARM64
+   map->base = fdtdec_get_number(reg, 2);
+   for (range = map->range; count > 0; reg += 4, range++, count--) {
+   range->start = fdtdec_get_number(reg, 2);
+   range->size = fdtdec_get_number(reg + 2, 2);
+   }
+#else
map->base = *reg;
for (range = map->range; count > 0; reg += 2, range++, count--) {
range->start = *reg;
range->size = reg[1];
}
-
+#endif
*mapp = map;
 
return 0;
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] tiny-printf: add static to locally used functions

2017-02-13 Thread Stefan Roese

On 12.02.2017 10:08, Masahiro Yamada wrote:

These two functions are only used in lib/tiny-printf.c .

Signed-off-by: Masahiro Yamada 
---

 lib/tiny-printf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/tiny-printf.c b/lib/tiny-printf.c
index dfa8432..6def8f9 100644
--- a/lib/tiny-printf.c
+++ b/lib/tiny-printf.c
@@ -22,7 +22,7 @@ struct printf_info {
void (*putc)(struct printf_info *info, char ch);
 };

-void putc_normal(struct printf_info *info, char ch)
+static void putc_normal(struct printf_info *info, char ch)
 {
putc(ch);
 }
@@ -52,7 +52,7 @@ static void div_out(struct printf_info *info, unsigned long 
*num,
out_dgt(info, dgt);
 }

-int _vprintf(struct printf_info *info, const char *fmt, va_list va)
+static int _vprintf(struct printf_info *info, const char *fmt, va_list va)
 {
char ch;
char *p;



Reviewed-by: Stefan Roese 

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3] spi: ich: Configure SPI BIOS parameters

2017-02-13 Thread Bin Meng
Hi Stefan,

On Fri, Feb 10, 2017 at 6:17 PM, Stefan Roese  wrote:
> Hi Bin,
>
> On 10.02.2017 06:45, Bin Meng wrote:
>
> 
>
>
>>> @@ -127,6 +120,44 @@ struct spi_trans {
>>>  #define SPI_OPCODE_WREN0x06
>>>  #define SPI_OPCODE_FAST_READ   0x0b
>>>
>>> +#define SPI_OPCODE_TYPE_READ_NO_ADDRESS0
>>> +#define SPI_OPCODE_TYPE_WRITE_NO_ADDRESS   1
>>> +#define SPI_OPCODE_TYPE_READ_WITH_ADDRESS  2
>>> +#define SPI_OPCODE_TYPE_WRITE_WITH_ADDRESS 3
>>> +
>>
>>
>> Thanks for changing this.
>>
>>> +#define SPI_OPMENU_0   0x01 /* WRSR: Write Status Register */
>>> +#define SPI_OPTYPE_0   SPI_OPCODE_TYPE_WRITE_NO_ADDRESS
>>> +
>>> +#define SPI_OPMENU_1   0x02 /* BYPR: Byte Program */
>>> +#define SPI_OPTYPE_1   SPI_OPCODE_TYPE_WRITE_WITH_ADDRESS
>>> +
>>> +#define SPI_OPMENU_2   0x03 /* READ: Read Data */
>>> +#define SPI_OPTYPE_2   SPI_OPCODE_TYPE_READ_WITH_ADDRESS
>>> +
>>> +#define SPI_OPMENU_3   0x05 /* RDSR: Read Status Register */
>>> +#define SPI_OPTYPE_3   SPI_OPCODE_TYPE_READ_NO_ADDRESS
>>> +
>>> +#define SPI_OPMENU_4   0x20 /* SE20: Sector Erase 0x20 */
>>> +#define SPI_OPTYPE_4   SPI_OPCODE_TYPE_WRITE_WITH_ADDRESS
>>> +
>>> +#define SPI_OPMENU_5   0x9f /* RDID: Read ID */
>>> +#define SPI_OPTYPE_5   SPI_OPCODE_TYPE_READ_NO_ADDRESS
>>> +
>>> +#define SPI_OPMENU_6   0xd8 /* BED8: Block Erase 0xd8 */
>>> +#define SPI_OPTYPE_6   SPI_OPCODE_TYPE_WRITE_WITH_ADDRESS
>>> +
>>> +#define SPI_OPMENU_7   0x0b /* FAST: Fast Read */
>>> +#define SPI_OPTYPE_7   SPI_OPCODE_TYPE_READ_WITH_ADDRESS
>>> +
>>
>>
>> These are SPI flash commands. Should we name them similarly like
>> SPI_OPCODE_WREN and SPI_OPCODE_FAST_READ?
>
>
> I've thought about this as well but neglected doing this (for now).
> If you think its "better" that way, I'll send a v4 shortly. Just
> let me know.
>

OK, let's leave it for now.

>>> +#define SPI_OPTYPE ((SPI_OPTYPE_7 << 14) | (SPI_OPTYPE_6 << 12) | \
>>> +   (SPI_OPTYPE_5 << 10) | (SPI_OPTYPE_4 <<  8) | \
>>> +   (SPI_OPTYPE_3 <<  6) | (SPI_OPTYPE_2 <<  4) | \
>>> +   (SPI_OPTYPE_1 <<  2) | (SPI_OPTYPE_0 <<  0))
>>> +#define SPI_OPMENU_UPPER ((SPI_OPMENU_7 << 24) | (SPI_OPMENU_6 << 16) |
>>> \
>>> + (SPI_OPMENU_5 <<  8) | (SPI_OPMENU_4 <<  0))
>>> +#define SPI_OPMENU_LOWER ((SPI_OPMENU_3 << 24) | (SPI_OPMENU_2 << 16) |
>>> \
>>> + (SPI_OPMENU_1 <<  8) | (SPI_OPMENU_0 <<  0))
>>> +
>>
>>
>> What if the board mounts a flash with a different SPI flash command
>> set? Will this work?
>
>
> Frankly, I can't tell for sure but its very likely. As you might
> have guessed, these defines are taken from coreboot where they are
> usually board specific and written in the last stage before booting
> into the OS (IIRC). It would definitely make sense to add a mechanism
> to configure these BIOS parameters in a board-specific way. So that
> boards can choose to (optionally) provide different values.
>
> An easy way to do this, would be to make the newly created function
> spi_controller_config() a wear default. This way, board can always
> overwrite these default values (and / or do other stuff) in their
> board specific code. This could also be added in a follow up patch
> once this is needed though. I still have to see such a case of an
> "incompatible" SPI flash on x86, and IIRC all values in coreboot
> were identical.

I am OK with the weak implementation, but I know Simon dislikes weak
:) Maybe he has a better idea.

Let's hear what others think.

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] tools: kwbimage: Fix unchecked return value and fd leak

2017-02-13 Thread Mario Six
The return value of fstat was not checked in kwbimage, and in the case
of an error, the already open file was not closed. Fix both errors.

Reported-by: Coverity (CID: 155971)
Reported-by: Coverity (CID: 155969)
Signed-off-by: Mario Six 
---
 tools/kwbimage.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 93797c99da..2c637c7446 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -992,7 +992,11 @@ int add_binary_header_v1(uint8_t *cur)
return -1;
}
 
-   fstat(fileno(bin), &s);
+   if (fstat(fileno(bin), &s)) {
+   fprintf(stderr, "Cannot stat binary file %s\n",
+   binarye->binary.file);
+   goto err_close;
+   }
 
binhdrsz = sizeof(struct opt_hdr_v1) +
(binarye->binary.nargs + 2) * sizeof(uint32_t) +
@@ -1022,7 +1026,7 @@ int add_binary_header_v1(uint8_t *cur)
fprintf(stderr,
"Could not read binary image %s\n",
binarye->binary.file);
-   return -1;
+   goto err_close;
}
 
fclose(bin);
@@ -1040,6 +1044,11 @@ int add_binary_header_v1(uint8_t *cur)
cur += sizeof(uint32_t);
 
return 0;
+
+err_close:
+   fclose(bin);
+
+   return -1;
 }
 
 #if defined(CONFIG_KWB_SECURE)
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 2/2] rsa: Fix deprecated warnings for OpenSSL 1.1.x

2017-02-13 Thread Jelle van der Waa
ERR_remove_thread_state is deprecated in OpenSSL 1.1.x and does not do
anything anymore. Thread initialisation and deinitialisation is now
handled by the OpenSSL library.

Signed-off-by: Jelle van der Waa 
---
 lib/rsa/rsa-sign.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
index 965fb00f95..347a6aa89e 100644
--- a/lib/rsa/rsa-sign.c
+++ b/lib/rsa/rsa-sign.c
@@ -16,10 +16,6 @@
 #include 
 #include 
 
-#if OPENSSL_VERSION_NUMBER >= 0x1000L
-#define HAVE_ERR_REMOVE_THREAD_STATE
-#endif
-
 #if OPENSSL_VERSION_NUMBER < 0x1010L
 void RSA_get0_key(const RSA *r,
  const BIGNUM **n, const BIGNUM **e, const BIGNUM **d)
@@ -356,9 +352,9 @@ static void rsa_remove(void)
 {
CRYPTO_cleanup_all_ex_data();
ERR_free_strings();
-#ifdef HAVE_ERR_REMOVE_THREAD_STATE
+#if OPENSSL_VERSION_NUMBER >= 0x1000L && OPENSSL_VERSION_NUMBER < 
0x1010L
ERR_remove_thread_state(NULL);
-#else
+#elif OPENSSL_VERSION_NUMBER < 0x1000L
ERR_remove_state(0);
 #endif
EVP_cleanup();
-- 
2.11.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 1/2] rsa: Fix build with OpenSSL 1.1.x

2017-02-13 Thread Jelle van der Waa
The rsa_st struct has been made opaque in 1.1.x, add forward compatible
code to access the n, e, d members of rsa_struct.

EVP_MD_CTX_cleanup has been removed in 1.1.x and EVP_MD_CTX_reset should be
called to reinitialise an already created structure.
---
 lib/rsa/rsa-sign.c | 33 +++--
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
index 8c6637e328..965fb00f95 100644
--- a/lib/rsa/rsa-sign.c
+++ b/lib/rsa/rsa-sign.c
@@ -20,6 +20,19 @@
 #define HAVE_ERR_REMOVE_THREAD_STATE
 #endif
 
+#if OPENSSL_VERSION_NUMBER < 0x1010L
+void RSA_get0_key(const RSA *r,
+ const BIGNUM **n, const BIGNUM **e, const BIGNUM **d)
+{
+   if (n != NULL)
+   *n = r->n;
+   if (e != NULL)
+   *e = r->e;
+   if (d != NULL)
+   *d = r->d;
+}
+#endif
+
 static int rsa_err(const char *msg)
 {
unsigned long sslErr = ERR_get_error();
@@ -409,7 +422,11 @@ static int rsa_sign_with_key(RSA *rsa, struct 
checksum_algo *checksum_algo,
ret = rsa_err("Could not obtain signature");
goto err_sign;
}
-   EVP_MD_CTX_cleanup(context);
+   #if OPENSSL_VERSION_NUMBER < 0x1010L
+   EVP_MD_CTX_cleanup(context);
+   #else
+   EVP_MD_CTX_reset(context);
+   #endif
EVP_MD_CTX_destroy(context);
EVP_PKEY_free(key);
 
@@ -479,6 +496,7 @@ static int rsa_get_exponent(RSA *key, uint64_t *e)
 {
int ret;
BIGNUM *bn_te;
+   const BIGNUM *key_e;
uint64_t te;
 
ret = -EINVAL;
@@ -487,17 +505,18 @@ static int rsa_get_exponent(RSA *key, uint64_t *e)
if (!e)
goto cleanup;
 
-   if (BN_num_bits(key->e) > 64)
+   RSA_get0_key(key, NULL, &key_e, NULL);
+   if (BN_num_bits(key_e) > 64)
goto cleanup;
 
-   *e = BN_get_word(key->e);
+   *e = BN_get_word(key_e);
 
-   if (BN_num_bits(key->e) < 33) {
+   if (BN_num_bits(key_e) < 33) {
ret = 0;
goto cleanup;
}
 
-   bn_te = BN_dup(key->e);
+   bn_te = BN_dup(key_e);
if (!bn_te)
goto cleanup;
 
@@ -527,6 +546,7 @@ int rsa_get_params(RSA *key, uint64_t *exponent, uint32_t 
*n0_invp,
 {
BIGNUM *big1, *big2, *big32, *big2_32;
BIGNUM *n, *r, *r_squared, *tmp;
+   const BIGNUM *key_n;
BN_CTX *bn_ctx = BN_CTX_new();
int ret = 0;
 
@@ -548,7 +568,8 @@ int rsa_get_params(RSA *key, uint64_t *exponent, uint32_t 
*n0_invp,
if (0 != rsa_get_exponent(key, exponent))
ret = -1;
 
-   if (!BN_copy(n, key->n) || !BN_set_word(big1, 1L) ||
+   RSA_get0_key(key, NULL, &key_n, NULL);
+   if (!BN_copy(n, key_n) || !BN_set_word(big1, 1L) ||
!BN_set_word(big2, 2L) || !BN_set_word(big32, 32L))
ret = -1;
 
-- 
2.11.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] U-Boot of-platdata issue

2017-02-13 Thread Kever Yang

Hi Simon,

On 01/16/2017 12:15 PM, Simon Glass wrote:

Hi Kever,

On 15 January 2017 at 18:28, Kever Yang  wrote:

Hi Simon,

 I met two issue when using of-platdata

1. compitable name with '.'
I get compile error as below:
In file included from include/dt-structs.h:16:0,
  from spl/dts/dt-platdata.c:3:
include/generated/dt-structs.h:26:35: error: expected identifier or ‘(’
before numeric constant
  struct dtd_rockchip_rk3399_sdhci_5.1 {
^
spl/dts/dt-platdata.c:41:42: error: expected identifier or ‘(’ before
numeric constant
  static struct dtd_rockchip_rk3399_sdhci_5.1 dtv_sdhci_at_fe33 = {
   ^
spl/dts/dt-platdata.c:55:15: error: ‘dtv_sdhci_at_fe33’ undeclared here
(not in a function)
   .platdata = &dtv_sdhci_at_fe33,
^
make[2]: *** [spl/dts/dt-platdata.o] Error 1
make[1]: *** [spl/u-boot-spl] Error 2
make: *** [__build_one_by_one] Error 2

The dts node starts like this:
 sdhci: sdhci@fe33 {
 u-boot,dm-pre-reloc;
 compatible = "rockchip,rk3399-sdhci-5.1",
"arasan,sdhci-5.1";
...

That just involves replacing '.' with '_'. I sent a patch.


2. multi compatible name
When a dts node have more than one compatible name, which is prefer to use?
for example, we have two dwmmc compatible name in rk3399, the tool is using
the first one,
while the source code using the last one.

"drivers/mmc/rockchip_dw_mmc.c"
  23 struct rockchip_mmc_plat {
  24 #if CONFIG_IS_ENABLED(OF_PLATDATA)
  25 struct dtd_rockchip_rk3288_dw_mshc dtplat;
  26 #endif
  27 struct mmc_config cfg;
  28 struct mmc mmc;
  29 };
...
dts node
 sdmmc: dwmmc@fe32 {
compatible = "rockchip,rk3399-dw-mshc",
  "rockchip,rk3288-dw-mshc";

I'm not sure of the best solution here (other than putting more
on-chip SRAM in your devices hint hint :-)

One option is something like:

struct rockchip_mmc_plat {
#if CONFIG_IS_ENABLED(OF_PLATDATA)
#ifdef CONFIG_ROCKCHIP_RK3288
 struct dtd_rockchip_rk3288_dw_mshc dtplat;
#elif defined(CONFIG_ROCKCHIP_RK399)
 struct dtd_rockchip_rk399_dw_mshc dtplat;
#endif
#endif

Obviously we don't want that as it is putting SoC-specific stuff in the driver.

IMO the compatible strings are being misused a bit. Can there not be a
compatible string which is common to all rockchip devices which use
this IP? Something like "rockchip,dw-mshc-v1"? Then you can avoid
adding a new compatible string every time you use the same IP in a
device.


Agree, but... this is from kernel, we can't control it unless all kernel 
maintainers

have the same idea.


Another option would be for dtoc to #define each compatible string to
the first one. If you think that would work, I could do a patch.


I think we can try with the first one in the driver for of-platdata,
this would have problem for the first compatible name is different but
they share the same driver, like syscon. For syscon, you have resolved with
a special dirver, not sure if other driver has the same problem.

Could you help to make a patch for this solution?

Thanks,
- Kever


Regards,
Simon






___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2 3/9] clk: rk3399: update driver for spl

2017-02-13 Thread Kever Yang
Add ddr clock setting, add rockchip_get_pmucru API,
and enable of-platdata support.

Signed-off-by: Kever Yang 
Reviewed-by: Simon Glass 
---

Changes in v2: None
Changes in v1: None

 arch/arm/include/asm/arch-rockchip/clock.h  |  7 ++
 arch/arm/include/asm/arch-rockchip/cru_rk3399.h |  5 ++
 arch/arm/mach-rockchip/rk3399/clk_rk3399.c  | 21 ++
 drivers/clk/rockchip/clk_rk3399.c   | 89 ++---
 include/dt-bindings/clock/rk3399-cru.h  | 16 +++--
 5 files changed, 123 insertions(+), 15 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/clock.h 
b/arch/arm/include/asm/arch-rockchip/clock.h
index 804c77b..6f7e755 100644
--- a/arch/arm/include/asm/arch-rockchip/clock.h
+++ b/arch/arm/include/asm/arch-rockchip/clock.h
@@ -63,6 +63,13 @@ static inline u32 clk_get_divisor(ulong input_rate, uint 
output_rate)
  */
 void *rockchip_get_cru(void);
 
+/**
+ * rockchip_get_pmucru() - get a pointer to the clock/reset unit registers
+ *
+ * @return pointer to registers, or -ve error on error
+ */
+void *rockchip_get_pmucru(void);
+
 struct rk3288_cru;
 struct rk3288_grf;
 
diff --git a/arch/arm/include/asm/arch-rockchip/cru_rk3399.h 
b/arch/arm/include/asm/arch-rockchip/cru_rk3399.h
index 98fba2b..cf830d0 100644
--- a/arch/arm/include/asm/arch-rockchip/cru_rk3399.h
+++ b/arch/arm/include/asm/arch-rockchip/cru_rk3399.h
@@ -15,6 +15,11 @@ struct rk3399_clk_priv {
ulong rate;
 };
 
+struct rk3399_pmuclk_priv {
+   struct rk3399_pmucru *pmucru;
+   ulong rate;
+};
+
 struct rk3399_pmucru {
u32 ppll_con[6];
u32 reserved[0x1a];
diff --git a/arch/arm/mach-rockchip/rk3399/clk_rk3399.c 
b/arch/arm/mach-rockchip/rk3399/clk_rk3399.c
index ce706a6..cf5b8c9 100644
--- a/arch/arm/mach-rockchip/rk3399/clk_rk3399.c
+++ b/arch/arm/mach-rockchip/rk3399/clk_rk3399.c
@@ -31,3 +31,24 @@ void *rockchip_get_cru(void)
 
return priv->cru;
 }
+
+static int rockchip_get_pmucruclk(struct udevice **devp)
+{
+   return uclass_get_device_by_driver(UCLASS_CLK,
+   DM_GET_DRIVER(rockchip_rk3399_pmuclk), devp);
+}
+
+void *rockchip_get_pmucru(void)
+{
+   struct rk3399_pmuclk_priv *priv;
+   struct udevice *dev;
+   int ret;
+
+   ret = rockchip_get_pmucruclk(&dev);
+   if (ret)
+   return ERR_PTR(ret);
+
+   priv = dev_get_priv(dev);
+
+   return priv->pmucru;
+}
diff --git a/drivers/clk/rockchip/clk_rk3399.c 
b/drivers/clk/rockchip/clk_rk3399.c
index 2e87e4b..8e3860b 100644
--- a/drivers/clk/rockchip/clk_rk3399.c
+++ b/drivers/clk/rockchip/clk_rk3399.c
@@ -7,7 +7,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -18,10 +20,16 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-struct rk3399_pmuclk_priv {
-   struct rk3399_pmucru *pmucru;
+#if CONFIG_IS_ENABLED(OF_PLATDATA)
+struct rk3399_clk_plat {
+   struct dtd_rockchip_rk3399_cru dtd;
 };
 
+struct rk3399_pmuclk_plat {
+   struct dtd_rockchip_rk3399_pmucru dtd;
+};
+#endif
+
 struct pll_div {
u32 refdiv;
u32 fbdiv;
@@ -381,6 +389,7 @@ static int pll_para_config(u32 freq_hz, struct pll_div *div)
return 0;
 }
 
+#ifdef CONFIG_SPL_BUILD
 static void rkclk_init(struct rk3399_cru *cru)
 {
u32 aclk_div;
@@ -456,6 +465,7 @@ static void rkclk_init(struct rk3399_cru *cru)
 hclk_div << HCLK_PERILP1_DIV_CON_SHIFT |
 HCLK_PERILP1_PLL_SEL_GPLL << HCLK_PERILP1_PLL_SEL_SHIFT);
 }
+#endif
 
 void rk3399_configure_cpu(struct rk3399_cru *cru,
  enum apll_l_frequencies apll_l_freq)
@@ -709,6 +719,44 @@ static ulong rk3399_mmc_set_clk(struct rk3399_cru *cru,
return rk3399_mmc_get_clk(cru, clk_id);
 }
 
+#define PMUSGRF_DDR_RGN_CON16 0xff330040
+static ulong rk3399_ddr_set_clk(struct rk3399_cru *cru,
+   ulong set_rate)
+{
+   struct pll_div dpll_cfg;
+
+   /*  IC ECO bug, need to set this register */
+   writel(0xc000c000, PMUSGRF_DDR_RGN_CON16);
+
+   /*  clk_ddrc == DPLL = 24MHz / refdiv * fbdiv / postdiv1 / postdiv2 */
+   switch (set_rate) {
+   case 200*MHz:
+   dpll_cfg = (struct pll_div)
+   {.refdiv = 1, .fbdiv = 50, .postdiv1 = 6, .postdiv2 = 1};
+   break;
+   case 300*MHz:
+   dpll_cfg = (struct pll_div)
+   {.refdiv = 2, .fbdiv = 100, .postdiv1 = 4, .postdiv2 = 1};
+   break;
+   case 666*MHz:
+   dpll_cfg = (struct pll_div)
+   {.refdiv = 2, .fbdiv = 111, .postdiv1 = 2, .postdiv2 = 1};
+   break;
+   case 800*MHz:
+   dpll_cfg = (struct pll_div)
+   {.refdiv = 1, .fbdiv = 100, .postdiv1 = 3, .postdiv2 = 1};
+   break;
+   case 933*MHz:
+   dpll_cfg = (struct pll_div)
+   {.refdiv = 1, .fbdiv = 116, .postdiv1 = 3, .postdiv2 = 1};
+   break;
+   de

[U-Boot] [PATCH v2 2/9] arm64: rk3399: move grf register definitions to grf_rk3399.h

2017-02-13 Thread Kever Yang
rk3399 grf register bit defenitions should locate in header
file, so that not only pinctrl can use it.

Signed-off-by: Kever Yang 
Reviewed-by: Simon Glass 
---

Changes in v2: None
Changes in v1: None

 arch/arm/include/asm/arch-rockchip/grf_rk3399.h | 118 
 drivers/pinctrl/rockchip/pinctrl_rk3399.c   | 106 -
 2 files changed, 118 insertions(+), 106 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3399.h 
b/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
index d3d1467..62d8496 100644
--- a/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
+++ b/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
@@ -318,4 +318,122 @@ struct rk3399_pmusgrf_regs {
 };
 check_member(rk3399_pmusgrf_regs, slv_secure_con4, 0xe3d4);
 
+enum {
+   /* GRF_GPIO2B_IOMUX */
+   GRF_GPIO2B1_SEL_SHIFT   = 0,
+   GRF_GPIO2B1_SEL_MASK= 3 << GRF_GPIO2B1_SEL_SHIFT,
+   GRF_SPI2TPM_RXD = 1,
+   GRF_GPIO2B2_SEL_SHIFT   = 2,
+   GRF_GPIO2B2_SEL_MASK= 3 << GRF_GPIO2B2_SEL_SHIFT,
+   GRF_SPI2TPM_TXD = 1,
+   GRF_GPIO2B3_SEL_SHIFT   = 6,
+   GRF_GPIO2B3_SEL_MASK= 3 << GRF_GPIO2B3_SEL_SHIFT,
+   GRF_SPI2TPM_CLK = 1,
+   GRF_GPIO2B4_SEL_SHIFT   = 8,
+   GRF_GPIO2B4_SEL_MASK= 3 << GRF_GPIO2B4_SEL_SHIFT,
+   GRF_SPI2TPM_CSN0= 1,
+
+   /* GRF_GPIO3A_IOMUX */
+   GRF_GPIO3A4_SEL_SHIFT   = 8,
+   GRF_GPIO3A4_SEL_MASK= 3 << GRF_GPIO3A4_SEL_SHIFT,
+   GRF_SPI0NORCODEC_RXD= 2,
+   GRF_GPIO3A5_SEL_SHIFT   = 10,
+   GRF_GPIO3A5_SEL_MASK= 3 << GRF_GPIO3A5_SEL_SHIFT,
+   GRF_SPI0NORCODEC_TXD= 2,
+   GRF_GPIO3A6_SEL_SHIFT   = 12,
+   GRF_GPIO3A6_SEL_MASK= 3 << GRF_GPIO3A6_SEL_SHIFT,
+   GRF_SPI0NORCODEC_CLK= 2,
+   GRF_GPIO3A7_SEL_SHIFT   = 14,
+   GRF_GPIO3A7_SEL_MASK= 3 << GRF_GPIO3A7_SEL_SHIFT,
+   GRF_SPI0NORCODEC_CSN0   = 2,
+
+   /* GRF_GPIO3B_IOMUX */
+   GRF_GPIO3B0_SEL_SHIFT   = 0,
+   GRF_GPIO3B0_SEL_MASK= 3 << GRF_GPIO3B0_SEL_SHIFT,
+   GRF_SPI0NORCODEC_CSN1   = 2,
+
+   /* GRF_GPIO4B_IOMUX */
+   GRF_GPIO4B0_SEL_SHIFT   = 0,
+   GRF_GPIO4B0_SEL_MASK= 3 << GRF_GPIO4B0_SEL_SHIFT,
+   GRF_SDMMC_DATA0 = 1,
+   GRF_UART2DBGA_SIN   = 2,
+   GRF_GPIO4B1_SEL_SHIFT   = 2,
+   GRF_GPIO4B1_SEL_MASK= 3 << GRF_GPIO4B1_SEL_SHIFT,
+   GRF_SDMMC_DATA1 = 1,
+   GRF_UART2DBGA_SOUT  = 2,
+   GRF_GPIO4B2_SEL_SHIFT   = 4,
+   GRF_GPIO4B2_SEL_MASK= 3 << GRF_GPIO4B2_SEL_SHIFT,
+   GRF_SDMMC_DATA2 = 1,
+   GRF_GPIO4B3_SEL_SHIFT   = 6,
+   GRF_GPIO4B3_SEL_MASK= 3 << GRF_GPIO4B3_SEL_SHIFT,
+   GRF_SDMMC_DATA3 = 1,
+   GRF_GPIO4B4_SEL_SHIFT   = 8,
+   GRF_GPIO4B4_SEL_MASK= 3 << GRF_GPIO4B4_SEL_SHIFT,
+   GRF_SDMMC_CLKOUT= 1,
+   GRF_GPIO4B5_SEL_SHIFT   = 10,
+   GRF_GPIO4B5_SEL_MASK= 3 << GRF_GPIO4B5_SEL_SHIFT,
+   GRF_SDMMC_CMD   = 1,
+
+   /*  GRF_GPIO4C_IOMUX */
+   GRF_GPIO4C0_SEL_SHIFT   = 0,
+   GRF_GPIO4C0_SEL_MASK= 3 << GRF_GPIO4C0_SEL_SHIFT,
+   GRF_UART2DGBB_SIN   = 2,
+   GRF_GPIO4C1_SEL_SHIFT   = 2,
+   GRF_GPIO4C1_SEL_MASK= 3 << GRF_GPIO4C1_SEL_SHIFT,
+   GRF_UART2DGBB_SOUT  = 2,
+   GRF_GPIO4C2_SEL_SHIFT   = 4,
+   GRF_GPIO4C2_SEL_MASK= 3 << GRF_GPIO4C2_SEL_SHIFT,
+   GRF_PWM_0   = 1,
+   GRF_GPIO4C3_SEL_SHIFT   = 6,
+   GRF_GPIO4C3_SEL_MASK= 3 << GRF_GPIO4C3_SEL_SHIFT,
+   GRF_UART2DGBC_SIN   = 1,
+   GRF_GPIO4C4_SEL_SHIFT   = 8,
+   GRF_GPIO4C4_SEL_MASK= 3 << GRF_GPIO4C4_SEL_SHIFT,
+   GRF_UART2DBGC_SOUT  = 1,
+   GRF_GPIO4C6_SEL_SHIFT   = 12,
+   GRF_GPIO4C6_SEL_MASK= 3 << GRF_GPIO4C6_SEL_SHIFT,
+   GRF_PWM_1   = 1,
+
+   /* GRF_SOC_CON7 */
+   GRF_UART_DBG_SEL_SHIFT  = 10,
+   GRF_UART_DBG_SEL_MASK   = 3 << GRF_UART_DBG_SEL_SHIFT,
+   GRF_UART_DBG_SEL_C  = 2,
+
+   /*  PMUGRF_GPIO0A_IOMUX */
+   PMUGRF_GPIO0A6_SEL_SHIFT= 12,
+   PMUGRF_GPIO0A6_SEL_MASK = 3 << PMUGRF_GPIO0A6_SEL_SHIFT,
+   PMUGRF_PWM_3A   = 1,
+
+   /*  PMUGRF_GPIO1A_IOMUX */
+   PMUGRF_GPIO1A7_SEL_SHIFT= 14,
+   PMUGRF_GPIO1A7_SEL_MASK = 3 << PMUGRF_GPIO1A7_SEL_SHIFT,
+   PMUGRF_SPI1EC_RXD   = 2,
+
+   /*  PMUGRF_GPIO1B_IOMUX */
+   PMUGRF_GPIO1B0_SEL_SHIFT= 0,
+   PMUGRF_GPIO1B0_SEL_MASK = 3 << PMUGRF_GPIO1B0_SEL_SHIFT,
+   PMUGRF_SPI1EC_TXD   = 2,
+   PMUGRF_GPIO1B1_SEL_SHIFT= 2,
+   PMUGRF_GPIO1B1_SEL_MASK = 3 << PMUGRF_GPIO1B1_SEL_SHIFT,
+   PMUGRF_SPI1EC_CLK   = 2,
+   PMUGRF_GPIO1B2_SEL_SHIFT= 4,
+   PMUGRF_GPIO1B2_SEL_MASK = 3 << PMUGRF_GPIO1B2_SEL_SHIFT,
+   PMUGRF_SPI1EC_CSN0  = 2,
+   PMUGRF_GPIO1B6_SEL_SHIFT= 12,
+   PMUGRF_GPIO1B6_SEL_MASK = 3 << PMUGRF_GP

[U-Boot] [PATCH v2 0/9] rk3399: enable SPL driver

2017-02-13 Thread Kever Yang

This series patch enable basic driver for rk3399 SPL, the ATF support
has been split as a separate patch.

SPL_OF_PLATDATA is consider to be must because the dram driver has much
configuration parameter from dts, but we don't want to do the copy.

Other driver like clock, pinctrl, sdhci has update to support
OF-PLATDATA.


Changes in v2:
- use lower-case hex for input dts data
- using rk3288 like style to encode/decode sys_reg
- gather some parameters as base params in rk3399_sdram_params
- add some missing comment
- split SPL patch into 4 patches

Changes in v1:
- use dts for parameter
- get all controller base address from dts instead of hard code
- gather all controller into dram_info instead of separate global
  variables.
- add return value for error case

Kever Yang (9):
  arm64: rk3399: add ddr controller driver
  arm64: rk3399: move grf register definitions to grf_rk3399.h
  clk: rk3399: update driver for spl
  sdhci: rk3399: update driver to support of-platdata
  pinctrl: rk3399: add the of-platdata support
  arm64: rk3399: syscon addition for rk3399
  dts: rk3399: update for spl require driver
  arm64: rk3399: add SPL support
  config: rk3399: enable SPL config for evb-rk3399

 arch/arm/Kconfig  |1 +
 arch/arm/dts/rk3399-evb.dts   |2 +
 arch/arm/dts/rk3399-sdram-lpddr3-4GB-1600.dtsi| 1536 +
 arch/arm/dts/rk3399.dtsi  |   44 +
 arch/arm/include/asm/arch-rockchip/clock.h|9 +
 arch/arm/include/asm/arch-rockchip/cru_rk3399.h   |5 +
 arch/arm/include/asm/arch-rockchip/grf_rk3399.h   |  118 ++
 arch/arm/include/asm/arch-rockchip/sdram_rk3399.h |  124 ++
 arch/arm/mach-rockchip/Kconfig|2 +
 arch/arm/mach-rockchip/Makefile   |1 +
 arch/arm/mach-rockchip/rk3399-board-spl.c |  158 +++
 arch/arm/mach-rockchip/rk3399/Makefile|1 +
 arch/arm/mach-rockchip/rk3399/clk_rk3399.c|   21 +
 arch/arm/mach-rockchip/rk3399/sdram_rk3399.c  | 1259 +
 arch/arm/mach-rockchip/rk3399/syscon_rk3399.c |   40 +
 configs/evb-rk3399_defconfig  |   18 +
 drivers/clk/rockchip/clk_rk3399.c |   89 +-
 drivers/mmc/rockchip_sdhci.c  |   17 +-
 drivers/pinctrl/rockchip/pinctrl_rk3399.c |  111 +-
 include/configs/rk3399_common.h   |   11 +
 include/dt-bindings/clock/rk3399-cru.h|   16 +-
 21 files changed, 3460 insertions(+), 123 deletions(-)
 create mode 100644 arch/arm/dts/rk3399-sdram-lpddr3-4GB-1600.dtsi
 create mode 100644 arch/arm/include/asm/arch-rockchip/sdram_rk3399.h
 create mode 100644 arch/arm/mach-rockchip/rk3399-board-spl.c
 create mode 100644 arch/arm/mach-rockchip/rk3399/sdram_rk3399.c

-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2 1/9] arm64: rk3399: add ddr controller driver

2017-02-13 Thread Kever Yang
RK3399 support DDR3, LPDDR3, DDR4 sdram, this patch is porting from
coreboot, support 4GB lpddr3 in this version.

Signed-off-by: Kever Yang 
---

Changes in v2:
- use lower-case hex for input dts data
- using rk3288 like style to encode/decode sys_reg
- gather some parameters as base params in rk3399_sdram_params
- add some missing comment

Changes in v1:
- use dts for parameter
- get all controller base address from dts instead of hard code
- gather all controller into dram_info instead of separate global
  variables.
- add return value for error case

 arch/arm/dts/rk3399-sdram-lpddr3-4GB-1600.dtsi| 1536 +
 arch/arm/include/asm/arch-rockchip/sdram_rk3399.h |  124 ++
 arch/arm/mach-rockchip/rk3399/Makefile|1 +
 arch/arm/mach-rockchip/rk3399/sdram_rk3399.c  | 1259 +
 4 files changed, 2920 insertions(+)
 create mode 100644 arch/arm/dts/rk3399-sdram-lpddr3-4GB-1600.dtsi
 create mode 100644 arch/arm/include/asm/arch-rockchip/sdram_rk3399.h
 create mode 100644 arch/arm/mach-rockchip/rk3399/sdram_rk3399.c

diff --git a/arch/arm/dts/rk3399-sdram-lpddr3-4GB-1600.dtsi 
b/arch/arm/dts/rk3399-sdram-lpddr3-4GB-1600.dtsi
new file mode 100644
index 000..65dfc38
--- /dev/null
+++ b/arch/arm/dts/rk3399-sdram-lpddr3-4GB-1600.dtsi
@@ -0,0 +1,1536 @@
+/*
+ * (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+&dmc {
+   rockchip,sdram-params = <
+   0x2
+   0xa
+   0x3
+   0x2
+   0x2
+   0x0
+   0xf
+   0xf
+   1
+   0x1d191519
+   0x14040808
+   0x0002
+   0x6226
+   0x0054
+   0x
+   0x2
+   0xa
+   0x3
+   0x2
+   0x2
+   0x0
+   0xf
+   0xf
+   1
+   0x1d191519
+   0x14040808
+   0x0002
+   0x6226
+   0x0054
+   0x
+   800
+   6
+   2
+   13
+   1
+   0x0700
+   0x
+   0x
+   0x
+   0x
+   0x0050
+   0x00027100
+   0x0320
+   0x1f40
+   0x0050
+   0x00027100
+   0x0320
+   0x1f40
+   0x0050
+   0x00027100
+   0x0320
+   0x01001f40
+   0x
+   0x0101
+   0x00020100
+   0x00a0
+   0x0190
+   0x
+   0x0618
+   0x00061800
+   0x04000618
+   0x33080004
+   0x280f0622
+   0x22330800
+   0x00280f06
+   0x06223308
+   0x0600280f
+   0x0a0a
+   0x0600dac0
+   0x0a0a060c
+   0x0600dac0
+   0x0a0a060c
+   0x0600dac0
+   0x0203000c
+   0x0f0c0f00
+   0x040c0f0c
+   0x14000a0a
+   0x03030a0a
+   0x00010003
+   0x031b1b1b
+   0x0011
+   0x
+   0x0301
+   0x0c2800a8
+   0x0c2800a8
+   0x0c2800a8
+   0x
+   0x00060006
+   0x00140006
+   0x00140014
+   0x000f0f0f
+   0x
+   0x
+   0x
+   0x00b0
+   0x00b000b0
+   0x00b000b0
+   0x00b0
+   0x
+   0x
+   0x
+   0x
+   0x
+   0x
+   0x0301
+   0x0001
+   0x
+   0x
+   0x0100
+   0x80104002
+   0x00040003
+   0x00040005
+   0x0003
+   0x00050004
+   0x0004
+   0x00040003
+   0x00040005
+   0x30a0
+   0x1850
+   0x185030a0
+   0x30a0
+   0x1850
+   0x
+   0x
+   0x
+   0x
+   0x
+   0x02020200
+   0x00020202
+   0x00030200
+   0x00040700
+   0x0302
+   0x02000407
+   0x0003
+   0x00030f04
+   0x00070004
+   0x
+ 

[U-Boot] [PATCH v2 5/9] pinctrl: rk3399: add the of-platdata support

2017-02-13 Thread Kever Yang
Do not use the API which of-platdata not support.

Signed-off-by: Kever Yang 
Reviewed-by: Simon Glass 
---

Changes in v2: None
Changes in v1: None

 drivers/pinctrl/rockchip/pinctrl_rk3399.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/rockchip/pinctrl_rk3399.c 
b/drivers/pinctrl/rockchip/pinctrl_rk3399.c
index 2f8aa64..f7417d5 100644
--- a/drivers/pinctrl/rockchip/pinctrl_rk3399.c
+++ b/drivers/pinctrl/rockchip/pinctrl_rk3399.c
@@ -253,6 +253,7 @@ static int rk3399_pinctrl_request(struct udevice *dev, int 
func, int flags)
 static int rk3399_pinctrl_get_periph_id(struct udevice *dev,
struct udevice *periph)
 {
+#if !CONFIG_IS_ENABLED(OF_PLATDATA)
u32 cell[3];
int ret;
 
@@ -283,7 +284,7 @@ static int rk3399_pinctrl_get_periph_id(struct udevice *dev,
case 65:
return PERIPH_ID_SDMMC1;
}
-
+#endif
return -ENOENT;
 }
 
@@ -328,6 +329,8 @@ U_BOOT_DRIVER(pinctrl_rk3399) = {
.of_match   = rk3399_pinctrl_ids,
.priv_auto_alloc_size = sizeof(struct rk3399_pinctrl_priv),
.ops= &rk3399_pinctrl_ops,
+#if !CONFIG_IS_ENABLED(OF_PLATDATA)
.bind   = dm_scan_fdt_dev,
+#endif
.probe  = rk3399_pinctrl_probe,
 };
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2 8/9] arm64: rk3399: add SPL support

2017-02-13 Thread Kever Yang
Add SPL support for rk3399, default with of-platdata enabled.

Signed-off-by: Kever Yang 
---

Changes in v2:
- split SPL patch into 4 patches

Changes in v1: None

 arch/arm/Kconfig  |   1 +
 arch/arm/mach-rockchip/Kconfig|   2 +
 arch/arm/mach-rockchip/Makefile   |   1 +
 arch/arm/mach-rockchip/rk3399-board-spl.c | 158 ++
 include/configs/rk3399_common.h   |   6 ++
 5 files changed, 168 insertions(+)
 create mode 100644 arch/arm/mach-rockchip/rk3399-board-spl.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d871a45..9a0efe4 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -882,6 +882,7 @@ config ARCH_ROCKCHIP
select DM
select SPL_DM if SPL
select SYS_MALLOC_F
+   select SPL_SEPARATE_BSS if SPL
select SPL_SYS_MALLOC_SIMPLE if SPL
select DM_GPIO
select DM_I2C
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 5c4a4c2..cd8fef8 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -26,6 +26,8 @@ config ROCKCHIP_RK3288
 config ROCKCHIP_RK3399
bool "Support Rockchip RK3399"
select ARM64
+   select SUPPORT_SPL
+   select SPL
help
  The Rockchip RK3399 is a ARM-based SoC with a dual-core Cortex-A72
  and quad-core Cortex-A53.
diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 6e79fed..b58c02d 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -7,6 +7,7 @@
 ifdef CONFIG_SPL_BUILD
 obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
 obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288-board-spl.o
+obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399-board-spl.o
 obj-$(CONFIG_ROCKCHIP_SPL_BACK_TO_BROM) += save_boot_param.o
 else
 obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288-board.o
diff --git a/arch/arm/mach-rockchip/rk3399-board-spl.c 
b/arch/arm/mach-rockchip/rk3399-board-spl.c
new file mode 100644
index 000..8ae3055
--- /dev/null
+++ b/arch/arm/mach-rockchip/rk3399-board-spl.c
@@ -0,0 +1,158 @@
+/*
+ * (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+u32 spl_boot_device(void)
+{
+   return BOOT_DEVICE_MMC1;
+}
+
+u32 spl_boot_mode(const u32 boot_device)
+{
+   return MMCSD_MODE_RAW;
+}
+
+#define TIMER_CHN10_BASE   0xff8680a0
+#define TIMER_END_COUNT_L  0x00
+#define TIMER_END_COUNT_H  0x04
+#define TIMER_INIT_COUNT_L 0x10
+#define TIMER_INIT_COUNT_H 0x14
+#define TIMER_CONTROL_REG  0x1c
+
+#define TIMER_EN   0x1
+#defineTIMER_FMODE (0 << 1)
+#defineTIMER_RMODE (1 << 1)
+
+void secure_timer_init(void)
+{
+   writel(0x, TIMER_CHN10_BASE + TIMER_END_COUNT_L);
+   writel(0x, TIMER_CHN10_BASE + TIMER_END_COUNT_H);
+   writel(0, TIMER_CHN10_BASE + TIMER_INIT_COUNT_L);
+   writel(0, TIMER_CHN10_BASE + TIMER_INIT_COUNT_H);
+   writel(TIMER_EN | TIMER_FMODE, TIMER_CHN10_BASE + TIMER_CONTROL_REG);
+}
+
+#define GRF_EMMCCORE_CON11 0xff77f02c
+void board_init_f(ulong dummy)
+{
+   struct udevice *pinctrl;
+   struct udevice *dev;
+   int ret;
+
+   /* Example code showing how to enable the debug UART on RK3288 */
+#include 
+   /* Enable early UART2 channel C on the RK3399 */
+#define GRF_BASE   0xff77
+   struct rk3399_grf_regs * const grf = (void *)GRF_BASE;
+
+   rk_clrsetreg(&grf->gpio4c_iomux,
+GRF_GPIO4C3_SEL_MASK,
+GRF_UART2DGBC_SIN << GRF_GPIO4C3_SEL_SHIFT);
+   rk_clrsetreg(&grf->gpio4c_iomux,
+GRF_GPIO4C4_SEL_MASK,
+GRF_UART2DBGC_SOUT << GRF_GPIO4C4_SEL_SHIFT);
+   /* Set channel C as UART2 input */
+   rk_clrsetreg(&grf->soc_con7,
+GRF_UART_DBG_SEL_MASK,
+GRF_UART_DBG_SEL_C << GRF_UART_DBG_SEL_SHIFT);
+#define EARLY_UART
+#ifdef EARLY_UART
+   /*
+* Debug UART can be used from here if required:
+*
+* debug_uart_init();
+* printch('a');
+* printhex8(0x1234);
+* printascii("string");
+*/
+   debug_uart_init();
+   printascii("U-Boot SPL board init");
+#endif
+   /*  Emmc clock generator: disable the clock multipilier */
+   rk_clrreg(GRF_EMMCCORE_CON11, 0x0ff);
+
+   ret = spl_init();
+   if (ret) {
+   debug("spl_init() failed: %d\n", ret);
+   hang();
+   }
+
+   secure_timer_init();
+
+   ret = uclass_get_device(UCLASS_PINCTRL, 0, &pinctrl);
+   if (ret) {
+   debug("Pinctrl init failed: %d\n", ret);
+   return;
+

[U-Boot] [PATCH v2 7/9] dts: rk3399: update for spl require driver

2017-02-13 Thread Kever Yang
Add syscon and dmc node, and 'u-boot,dm-pre-reloc' option for
required driver.

Signed-off-by: Kever Yang 
---

Changes in v2: None
Changes in v1: None

 arch/arm/dts/rk3399-evb.dts |  2 ++
 arch/arm/dts/rk3399.dtsi| 44 
 2 files changed, 46 insertions(+)

diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts
index fa60e19..a959989 100644
--- a/arch/arm/dts/rk3399-evb.dts
+++ b/arch/arm/dts/rk3399-evb.dts
@@ -7,6 +7,7 @@
 /dts-v1/;
 #include 
 #include "rk3399.dtsi"
+#include "rk3399-sdram-lpddr3-4GB-1600.dtsi"
 
 / {
model = "Rockchip RK3399 Evaluation Board";
@@ -69,6 +70,7 @@
 };
 
 &sdmmc {
+   bus-width = <4>;
status = "okay";
 };
 
diff --git a/arch/arm/dts/rk3399.dtsi b/arch/arm/dts/rk3399.dtsi
index 22277ff..379e04b 100644
--- a/arch/arm/dts/rk3399.dtsi
+++ b/arch/arm/dts/rk3399.dtsi
@@ -183,6 +183,7 @@
};
 
sdhci: sdhci@fe33 {
+   u-boot,dm-pre-reloc;
compatible = "rockchip,rk3399-sdhci-5.1", "arasan,sdhci-5.1";
reg = <0x0 0xfe33 0x0 0x1>;
interrupts = ;
@@ -416,6 +417,7 @@
};
 
pmugrf: syscon@ff32 {
+   u-boot,dm-pre-reloc;
compatible = "rockchip,rk3399-pmugrf", "syscon", "simple-mfd";
reg = <0x0 0xff32 0x0 0x1000>;
#address-cells = <1>;
@@ -427,6 +429,12 @@
};
};
 
+   pmusgrf: syscon@ff33 {
+   u-boot,dm-pre-reloc;
+   compatible = "rockchip,rk3399-pmusgrf", "syscon";
+   reg = <0x0 0xff33 0x0 0xe3d4>;
+   };
+
spi3: spi@ff35 {
compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
reg = <0x0 0xff35 0x0 0x1000>;
@@ -497,7 +505,40 @@
status = "disabled";
};
 
+   cic: syscon@ff62 {
+   u-boot,dm-pre-reloc;
+   compatible = "rockchip,rk3399-cic", "syscon";
+   reg = <0x0 0xff62 0x0 0x100>;
+   };
+
+   dfi: dfi@ff63 {
+   reg = <0x00 0xff63 0x00 0x4000>;
+   compatible = "rockchip,rk3399-dfi";
+   rockchip,pmu = <&pmugrf>;
+   clocks = <&cru PCLK_DDR_MON>;
+   clock-names = "pclk_ddr_mon";
+   status = "disabled";
+   };
+
+   dmc: dmc {
+   u-boot,dm-pre-reloc;
+   compatible = "rockchip,rk3399-dmc";
+   devfreq-events = <&dfi>;
+   interrupts = ;
+   clocks = <&cru SCLK_DDRCLK>;
+   clock-names = "dmc_clk";
+   reg = <0x0 0xffa8 0x0 0x0800
+  0x0 0xffa80800 0x0 0x1800
+  0x0 0xffa82000 0x0 0x2000
+  0x0 0xffa84000 0x0 0x1000
+  0x0 0xffa88000 0x0 0x0800
+  0x0 0xffa88800 0x0 0x1800
+  0x0 0xffa8a000 0x0 0x2000
+  0x0 0xffa8c000 0x0 0x1000>;
+   };
+
pmucru: pmu-clock-controller@ff75 {
+   u-boot,dm-pre-reloc;
compatible = "rockchip,rk3399-pmucru";
reg = <0x0 0xff75 0x0 0x1000>;
#clock-cells = <1>;
@@ -507,6 +548,7 @@
};
 
cru: clock-controller@ff76 {
+   u-boot,dm-pre-reloc;
compatible = "rockchip,rk3399-cru";
reg = <0x0 0xff76 0x0 0x1000>;
#clock-cells = <1>;
@@ -530,6 +572,7 @@
};
 
grf: syscon@ff77 {
+   u-boot,dm-pre-reloc;
compatible = "rockchip,rk3399-grf", "syscon", "simple-mfd";
reg = <0x0 0xff77 0x0 0x1>;
#address-cells = <1>;
@@ -607,6 +650,7 @@
};
 
pinctrl: pinctrl {
+   u-boot,dm-pre-reloc;
compatible = "rockchip,rk3399-pinctrl";
rockchip,grf = <&grf>;
rockchip,pmu = <&pmugrf>;
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2 4/9] sdhci: rk3399: update driver to support of-platdata

2017-02-13 Thread Kever Yang
Change some API in order to enable of-platdata.

Signed-off-by: Kever Yang 
Reviewed-by: Simon Glass 
---

Changes in v2: None
Changes in v1: None

 drivers/mmc/rockchip_sdhci.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/rockchip_sdhci.c b/drivers/mmc/rockchip_sdhci.c
index e33e35e..1ea5db4 100644
--- a/drivers/mmc/rockchip_sdhci.c
+++ b/drivers/mmc/rockchip_sdhci.c
@@ -8,9 +8,11 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -19,6 +21,9 @@ DECLARE_GLOBAL_DATA_PTR;
 #define EMMC_MIN_FREQ  40
 
 struct rockchip_sdhc_plat {
+#if CONFIG_IS_ENABLED(OF_PLATDATA)
+   struct dtd_rockchip_rk3399_sdhci_5_1 dtplat;
+#endif
struct mmc_config cfg;
struct mmc mmc;
 };
@@ -37,10 +42,18 @@ static int arasan_sdhci_probe(struct udevice *dev)
int max_frequency, ret;
struct clk clk;
 
+#if CONFIG_IS_ENABLED(OF_PLATDATA)
+   struct dtd_rockchip_rk3399_sdhci_5_1 *dtplat = &plat->dtplat;
 
+   host->name = dev->name;
+   host->ioaddr = map_sysmem(dtplat->reg[1], dtplat->reg[3]);
+   max_frequency = dtplat->max_frequency;
+   ret = clk_get_by_index_platdata(dev, 0, dtplat->clocks, &clk);
+#else
max_frequency = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
"max-frequency", 0);
ret = clk_get_by_index(dev, 0, &clk);
+#endif
if (!ret) {
ret = clk_set_rate(&clk, max_frequency);
if (IS_ERR_VALUE(ret))
@@ -66,10 +79,12 @@ static int arasan_sdhci_probe(struct udevice *dev)
 
 static int arasan_sdhci_ofdata_to_platdata(struct udevice *dev)
 {
+#if !CONFIG_IS_ENABLED(OF_PLATDATA)
struct sdhci_host *host = dev_get_priv(dev);
 
host->name = dev->name;
host->ioaddr = dev_get_addr_ptr(dev);
+#endif
 
return 0;
 }
@@ -87,7 +102,7 @@ static const struct udevice_id arasan_sdhci_ids[] = {
 };
 
 U_BOOT_DRIVER(arasan_sdhci_drv) = {
-   .name   = "arasan_sdhci",
+   .name   = "rockchip_rk3399_sdhci_5_1",
.id = UCLASS_MMC,
.of_match   = arasan_sdhci_ids,
.ofdata_to_platdata = arasan_sdhci_ofdata_to_platdata,
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2 6/9] arm64: rk3399: syscon addition for rk3399

2017-02-13 Thread Kever Yang
rk3399 has different syscon registers which may used in spl,
add to support rk3399 spl.

Signed-off-by: Kever Yang 
---

Changes in v2: None
Changes in v1: None

 arch/arm/include/asm/arch-rockchip/clock.h|  2 ++
 arch/arm/mach-rockchip/rk3399/syscon_rk3399.c | 40 +++
 2 files changed, 42 insertions(+)

diff --git a/arch/arm/include/asm/arch-rockchip/clock.h 
b/arch/arm/include/asm/arch-rockchip/clock.h
index 6f7e755..b06bb6c 100644
--- a/arch/arm/include/asm/arch-rockchip/clock.h
+++ b/arch/arm/include/asm/arch-rockchip/clock.h
@@ -17,6 +17,8 @@ enum {
ROCKCHIP_SYSCON_SGRF,
ROCKCHIP_SYSCON_PMU,
ROCKCHIP_SYSCON_PMUGRF,
+   ROCKCHIP_SYSCON_PMUSGRF,
+   ROCKCHIP_SYSCON_CIC,
 };
 
 /* Standard Rockchip clock numbers */
diff --git a/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c 
b/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c
index 2cef68b..d32985b 100644
--- a/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c
+++ b/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c
@@ -12,6 +12,8 @@
 static const struct udevice_id rk3399_syscon_ids[] = {
{ .compatible = "rockchip,rk3399-grf", .data = ROCKCHIP_SYSCON_GRF },
{ .compatible = "rockchip,rk3399-pmugrf", .data = 
ROCKCHIP_SYSCON_PMUGRF },
+   { .compatible = "rockchip,rk3399-pmusgrf", .data = 
ROCKCHIP_SYSCON_PMUSGRF },
+   { .compatible = "rockchip,rk3399-cic", .data = ROCKCHIP_SYSCON_CIC },
 };
 
 U_BOOT_DRIVER(syscon_rk3399) = {
@@ -19,3 +21,41 @@ U_BOOT_DRIVER(syscon_rk3399) = {
.id = UCLASS_SYSCON,
.of_match = rk3399_syscon_ids,
 };
+
+#if CONFIG_IS_ENABLED(OF_PLATDATA)
+static int rk3399_syscon_bind_of_platdata(struct udevice *dev)
+{
+   dev->driver_data = dev->driver->of_match->data;
+   debug("syscon: %s %d\n", dev->name, (uint)dev->driver_data);
+
+   return 0;
+}
+
+U_BOOT_DRIVER(rockchip_rk3399_grf) = {
+   .name = "rockchip_rk3399_grf",
+   .id = UCLASS_SYSCON,
+   .of_match = rk3399_syscon_ids,
+   .bind = rk3399_syscon_bind_of_platdata,
+};
+
+U_BOOT_DRIVER(rockchip_rk3399_pmugrf) = {
+   .name = "rockchip_rk3399_pmugrf",
+   .id = UCLASS_SYSCON,
+   .of_match = rk3399_syscon_ids + 1,
+   .bind = rk3399_syscon_bind_of_platdata,
+};
+
+U_BOOT_DRIVER(rockchip_rk3399_pmusgrf) = {
+   .name = "rockchip_rk3399_pmusgrf",
+   .id = UCLASS_SYSCON,
+   .of_match = rk3399_syscon_ids + 2,
+   .bind = rk3399_syscon_bind_of_platdata,
+};
+
+U_BOOT_DRIVER(rockchip_rk3399_cic) = {
+   .name = "rockchip_rk3399_cic",
+   .id = UCLASS_SYSCON,
+   .of_match = rk3399_syscon_ids + 3,
+   .bind = rk3399_syscon_bind_of_platdata,
+};
+#endif
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2 9/9] config: rk3399: enable SPL config for evb-rk3399

2017-02-13 Thread Kever Yang
Enable all the CONFIGs which need by SPL.

Signed-off-by: Kever Yang 
---

Changes in v2: None
Changes in v1: None

 configs/evb-rk3399_defconfig| 18 ++
 include/configs/rk3399_common.h |  5 +
 2 files changed, 23 insertions(+)

diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index 40a8295..abfabc5 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -3,7 +3,16 @@ CONFIG_ARCH_ROCKCHIP=y
 CONFIG_ROCKCHIP_RK3399=y
 CONFIG_DEFAULT_DEVICE_TREE="rk3399-evb"
 CONFIG_FIT=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_OF_LIBFDT=y
+CONFIG_SPL_ATF_SUPPORT=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x200
+CONFIG_SPL_ATF_TEXT_BASE=0x0001
 # CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_ADDR=0x8
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
+CONFIG_SYS_MALLOC_F_LEN=0x4000
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_IMLS is not set
@@ -16,18 +25,27 @@ CONFIG_CMD_EXT2=y
 CONFIG_CMD_EXT4=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_CMD_PXE=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names 
interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
+CONFIG_SPL_OF_PLATDATA=y
 CONFIG_REGMAP=y
+CONFIG_SPL_REGMAP=y
 CONFIG_SYSCON=y
+CONFIG_SPL_SYSCON=y
 CONFIG_CLK=y
+CONFIG_SPL_CLK=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_ROCKCHIP_DWMMC=y
 CONFIG_ROCKCHIP_SDHCI=y
 CONFIG_PINCTRL=y
+CONFIG_SPL_PINCTRL=y
 CONFIG_ROCKCHIP_RK3399_PINCTRL=y
 CONFIG_PWM_ROCKCHIP=y
 CONFIG_REGULATOR_PWM=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_RAM=y
+CONFIG_SPL_RAM=y
 CONFIG_DEBUG_UART=y
 CONFIG_DEBUG_UART_BASE=0xFF1A
 CONFIG_DEBUG_UART_CLOCK=2400
diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h
index 66b4fbc..3699a9d 100644
--- a/include/configs/rk3399_common.h
+++ b/include/configs/rk3399_common.h
@@ -17,6 +17,11 @@
 #define CONFIG_SYS_MALLOC_LEN  (32 << 20)
 #define CONFIG_SYS_CBSIZE  1024
 #define CONFIG_SKIP_LOWLEVEL_INIT
+#define CONFIG_SPL_FRAMEWORK
+#define CONFIG_SPL_DRIVERS_MISC_SUPPORT
+#define CONFIG_SPL_LIBCOMMON_SUPPORT
+#define CONFIG_SPL_LIBGENERIC_SUPPORT
+#define CONFIG_SPL_SERIAL_SUPPORT
 
 #define CONFIG_SYS_NS16550_MEM32
 
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] armv7m: Add SysTick timer driver

2017-02-13 Thread Phil Edworthy
Hi Vikas,

On 12 February 2017 20:53, Vikas MANOCHA wrote:
> > On Fri, Feb 03, 2017 at 02:48:40PM +, Phil Edworthy wrote:
> >
> > > The SysTick is a 24-bit down counter that is found on all ARM Cortex
> > > M3, M4, M7 devices and is always located at a fixed address.
> > >
> > > Signed-off-by: Phil Edworthy 
> > > ---
> > >  arch/arm/cpu/armv7m/Makefile|  2 +
> > >  arch/arm/cpu/armv7m/systick-timer.c | 91
> > > +
> > >  2 files changed, 93 insertions(+)
> > >  create mode 100644 arch/arm/cpu/armv7m/systick-timer.c
> > >
> > > diff --git a/arch/arm/cpu/armv7m/Makefile
> > > b/arch/arm/cpu/armv7m/Makefile index aff60e8..e1a6c40 100644
> > > --- a/arch/arm/cpu/armv7m/Makefile
> > > +++ b/arch/arm/cpu/armv7m/Makefile
> > > @@ -7,3 +7,5 @@
> > >
> > >  extra-y := start.o
> > >  obj-y += cpu.o
> > > +
> > > +obj-$(CONFIG_SYS_ARCH_TIMER) += systick-timer.o
> > > diff --git a/arch/arm/cpu/armv7m/systick-timer.c
> > > b/arch/arm/cpu/armv7m/systick-timer.c
> > > new file mode 100644
> > > index 000..6ccc2fb
> > > --- /dev/null
> > > +++ b/arch/arm/cpu/armv7m/systick-timer.c
> > > @@ -0,0 +1,91 @@
> > > +/*
> > > + * ARM Cortex M3/M4/M7 SysTick timer driver
> > > + * (C) Copyright 2017 Renesas Electronics Europe Ltd
> > > + *
> > > + * Based on arch/arm/mach-stm32/stm32f1/timer.c
> > > + * (C) Copyright 2015
> > > + * Kamil Lulko, 
> > > + *
> > > + * Copyright 2015 ATS Advanced Telematics Systems GmbH
> > > + * Copyright 2015 Konsulko Group, Matt Porter 
> > > + *
> > > + * SPDX-License-Identifier: GPL-2.0+
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +
> > > +DECLARE_GLOBAL_DATA_PTR;
> > > +
> > > +/* SysTick Base Address - fixed for all Cortex M3, M4 and M7 devices */
> > > +#define SYSTICK_BASE 0xE000E010
> > > +
> > > +struct cm3_systick {
> > > + uint32_t ctrl;
> > > + uint32_t reload;
> > > + uint32_t val;
> 
> This register is current timer value, write of any value clears it.
> Rename to cur_val would avoid any confusion.
Ok, though I'm not sure that cur_val is any clearer :)

> > > + uint32_t calibration;
> > > +};
> > > +
> > > +#define TIMER_LOAD_VAL   0x00FF
> > > +#define SYSTICK_CTRL_EN  BIT(0)
> > > +/* Clock source: 0 = Ref clock, 1 = CPU clock */
> > > +#define SYSTICK_CTRL_CPU_CLK BIT(2)
> > > +
> > > +/* read the 24-bit timer */
> > > +static ulong read_timer(void)
> > > +{
> > > + struct cm3_systick *systick = (struct cm3_systick *)SYSTICK_BASE;
> > > +
> > > + /* The timer counts down, therefore convert to an incrementing timer */
> > > + return TIMER_LOAD_VAL - readl(&systick->val); }
> 
> use mask to be sure of 24bit timer counter value.
Why? It's a 24-bit timer, the other bits are always zero.
 
> > > +
> > > +int timer_init(void)
> > > +{
> > > + struct cm3_systick *systick = (struct cm3_systick *)SYSTICK_BASE;
> > > +
> > > + writel(TIMER_LOAD_VAL, &systick->reload);
> > > + writel(TIMER_LOAD_VAL, &systick->val);
> 
> Writing load value gives the impression that it is load register, in fact it 
> is only
> clearing countflag.
Ok

> > > +
> > > +#ifdef CONFIG_ARMCORTEXM3_SYSTICK_CPU
> 
> Cortex M3 systick has only cpu clock source ?
No, it can have cpu clock or another clock external to the M3 core.
In our case we use the external clock because it is much slower than the
cpu clock, making the timer usable without interrupts. I can't imagine
anyone using the cpu clock unless they add code to handle the interrupt.
I'll add a comment to that effect.

Thanks
Phil

> Cheers,
> Vikas
> 
> > > + /* Use CPU clock, no interrupts */
> > > + writel(SYSTICK_CTRL_EN | SYSTICK_CTRL_CPU_CLK, &systick->ctrl);
> > > +#else
> > > + /* Use external clock, no interrupts */
> > > + writel(SYSTICK_CTRL_EN, &systick->ctrl); #endif
> > > +
> > > + gd->arch.tbl = 0;
> > > + gd->arch.tbu = 0;
> > > + gd->arch.lastinc = read_timer();
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +/* return milli-seconds timer value */ ulong get_timer(ulong base) {
> > > + unsigned long long t = get_ticks() * 1000;
> > > +
> > > + return (ulong)((t / CONFIG_SYS_HZ_CLOCK)) - base; }
> > > +
> > > +unsigned long long get_ticks(void)
> > > +{
> > > + u32 now = read_timer();
> > > +
> > > + if (now >= gd->arch.lastinc)
> > > + gd->arch.tbl += (now - gd->arch.lastinc);
> > > + else
> > > + gd->arch.tbl += (TIMER_LOAD_VAL - gd->arch.lastinc) + now;
> > > +
> > > + gd->arch.lastinc = now;
> > > +
> > > + return gd->arch.tbl;
> > > +}
> > > +
> > > +ulong get_tbclk(void)
> > > +{
> > > + return CONFIG_SYS_HZ_CLOCK;
> > > +}
> >
> > And (cc'ing maintainers) we could use this in place of arch/arm/mach-
> stm32/*/timer.c I assume, yes?  Thanks!
> >
> > --
> > Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] armv7m: Add SysTick timer driver

2017-02-13 Thread Phil Edworthy
Hi Vikas,

On 12 February 2017 21:10, Vikas MANOCHA wrote:
> Hi Phil,
> 
> > -Original Message-
> > From: Phil Edworthy [mailto:phil.edwor...@renesas.com]
> > Sent: Tuesday, February 07, 2017 6:34 AM
> > To: Tom Rini 
> > Cc: Kamil Lulko ; Vikas MANOCHA
> ; Michael Kurz ;
> > Albert Aribaud ; U-Boot Mailing List  b...@lists.denx.de>
> > Subject: RE: [U-Boot] [PATCH] armv7m: Add SysTick timer driver
> >
> > Hi Tom,
> >
> > On 07 February 2017 14:23, Tom Rini wrote:
> > > On Tue, Feb 07, 2017 at 02:19:39PM +, Phil Edworthy wrote:
> > > > Hi Kamil,
> > > >
> > > > On 07 February 2017 14:12, Kamil Lulko wrote:
> > > > > On Mon, Feb 6, 2017 at 12:16 AM, Tom Rini  wrote:
> > > > > > On Fri, Feb 03, 2017 at 02:48:40PM +, Phil Edworthy wrote:
> > > > > >
> > > > > > > The SysTick is a 24-bit down counter that is found on all ARM
> > > > > > > Cortex M3, M4, M7 devices and is always located at a fixed 
> > > > > > > address.
> > > > > > >
> > > > > > > Signed-off-by: Phil Edworthy 
> > > > > > > ---
> > > > > > >  arch/arm/cpu/armv7m/Makefile|  2 +
> > > > > > >  arch/arm/cpu/armv7m/systick-timer.c | 91
> > > > > +
> > > > > > >  2 files changed, 93 insertions(+)  create mode 100644
> > > > > > > arch/arm/cpu/armv7m/systick-timer.c
> > > > > > >
> > > > > > > diff --git a/arch/arm/cpu/armv7m/Makefile
> > > > > b/arch/arm/cpu/armv7m/Makefile
> > > > > > > index aff60e8..e1a6c40 100644
> > > > > > > --- a/arch/arm/cpu/armv7m/Makefile
> > > > > > > +++ b/arch/arm/cpu/armv7m/Makefile
> > > > > > > @@ -7,3 +7,5 @@
> > > > > > >
> > > > > > >  extra-y := start.o
> > > > > > >  obj-y += cpu.o
> > > > > > > +
> > > > > > > +obj-$(CONFIG_SYS_ARCH_TIMER) += systick-timer.o
> > > > > > > diff --git a/arch/arm/cpu/armv7m/systick-timer.c
> > > > > b/arch/arm/cpu/armv7m/systick-timer.c
> > > > > > > new file mode 100644
> > > > > > > index 000..6ccc2fb
> > > > > > > --- /dev/null
> > > > > > > +++ b/arch/arm/cpu/armv7m/systick-timer.c
> > > > > > > @@ -0,0 +1,91 @@
> > > > > > > +/*
> > > > > > > + * ARM Cortex M3/M4/M7 SysTick timer driver
> > > > > > > + * (C) Copyright 2017 Renesas Electronics Europe Ltd
> > > > > > > + *
> > > > > > > + * Based on arch/arm/mach-stm32/stm32f1/timer.c
> > > > > > > + * (C) Copyright 2015
> > > > > > > + * Kamil Lulko, 
> > > > > > > + *
> > > > > > > + * Copyright 2015 ATS Advanced Telematics Systems GmbH
> > > > > > > + * Copyright 2015 Konsulko Group, Matt Porter
> > > 
> > > > > > > + *
> > > > > > > + * SPDX-License-Identifier: GPL-2.0+
> > > > > > > + */
> > > > > > > +
> > > > > > > +#include 
> > > > > > > +#include 
> > > > > > > +
> > > > > > > +DECLARE_GLOBAL_DATA_PTR;
> > > > > > > +
> > > > > > > +/* SysTick Base Address - fixed for all Cortex M3, M4 and M7 
> > > > > > > devices
> */
> > > > > > > +#define SYSTICK_BASE 0xE000E010
> > > > > > > +
> > > > > > > +struct cm3_systick {
> > > > > > > + uint32_t ctrl;
> > > > > > > + uint32_t reload;
> > > > > > > + uint32_t val;
> > > > > > > + uint32_t calibration;
> > > > > > > +};
> > > > > > > +
> > > > > > > +#define TIMER_LOAD_VAL   0x00FF
> > > > > > > +#define SYSTICK_CTRL_EN  BIT(0)
> > > > > > > +/* Clock source: 0 = Ref clock, 1 = CPU clock */ #define
> > > > > > > +SYSTICK_CTRL_CPU_CLK BIT(2)
> > > > > > > +
> > > > > > > +/* read the 24-bit timer */
> > > > > > > +static ulong read_timer(void) {
> > > > > > > + struct cm3_systick *systick = (struct cm3_systick
> > > > > > > +*)SYSTICK_BASE;
> > > > > > > +
> > > > > > > + /* The timer counts down, therefore convert to an
> > > > > > > + incrementing timer
> > > */
> > > > > > > + return TIMER_LOAD_VAL - readl(&systick->val); }
> > > > > > > +
> > > > > > > +int timer_init(void)
> > > > > > > +{
> > > > > > > + struct cm3_systick *systick = (struct cm3_systick
> > > > > > > +*)SYSTICK_BASE;
> > > > > > > +
> > > > > > > + writel(TIMER_LOAD_VAL, &systick->reload);
> > > > > > > + writel(TIMER_LOAD_VAL, &systick->val);
> > > > > > > +
> > > > > > > +#ifdef CONFIG_ARMCORTEXM3_SYSTICK_CPU
> > > > > > > + /* Use CPU clock, no interrupts */
> > > > > > > + writel(SYSTICK_CTRL_EN | SYSTICK_CTRL_CPU_CLK,
> > > > > > > +&systick->ctrl); #else
> > > > > > > + /* Use external clock, no interrupts */
> > > > > > > + writel(SYSTICK_CTRL_EN, &systick->ctrl); #endif
> > > > > > > +
> > > > > > > + gd->arch.tbl = 0;
> > > > > > > + gd->arch.tbu = 0;
> > > > > > > + gd->arch.lastinc = read_timer();
> > > > > > > +
> > > > > > > + return 0;
> > > > > > > +}
> > > > > > > +
> > > > > > > +/* return milli-seconds timer value */ ulong get_timer(ulong
> > > > > > > +base) {
> > > > > > > + unsigned long long t = get_ticks() * 1000;
> > > > > > > +
> > > > > > > + return (ulong)((t / CONFIG_SYS_HZ_CLOCK)) - base; }
> > > > > > > +
> > > > > > > +unsigned long long get_ticks(void) {
> > > > > > > + u32 now = read_

Re: [U-Boot] U-Boot of-platdata issue

2017-02-13 Thread Jaehoon Chung
On 02/13/2017 06:23 PM, Kever Yang wrote:
> Hi Simon,
> 
> On 01/16/2017 12:15 PM, Simon Glass wrote:
>> Hi Kever,
>>
>> On 15 January 2017 at 18:28, Kever Yang  wrote:
>>> Hi Simon,
>>>
>>>  I met two issue when using of-platdata
>>>
>>> 1. compitable name with '.'
>>> I get compile error as below:
>>> In file included from include/dt-structs.h:16:0,
>>>   from spl/dts/dt-platdata.c:3:
>>> include/generated/dt-structs.h:26:35: error: expected identifier or ‘(’
>>> before numeric constant
>>>   struct dtd_rockchip_rk3399_sdhci_5.1 {
>>> ^
>>> spl/dts/dt-platdata.c:41:42: error: expected identifier or ‘(’ before
>>> numeric constant
>>>   static struct dtd_rockchip_rk3399_sdhci_5.1 dtv_sdhci_at_fe33 = {
>>>^
>>> spl/dts/dt-platdata.c:55:15: error: ‘dtv_sdhci_at_fe33’ undeclared here
>>> (not in a function)
>>>.platdata = &dtv_sdhci_at_fe33,
>>> ^
>>> make[2]: *** [spl/dts/dt-platdata.o] Error 1
>>> make[1]: *** [spl/u-boot-spl] Error 2
>>> make: *** [__build_one_by_one] Error 2
>>>
>>> The dts node starts like this:
>>>  sdhci: sdhci@fe33 {
>>>  u-boot,dm-pre-reloc;
>>>  compatible = "rockchip,rk3399-sdhci-5.1",
>>> "arasan,sdhci-5.1";
>>> ...
>> That just involves replacing '.' with '_'. I sent a patch.
>>
>>> 2. multi compatible name
>>> When a dts node have more than one compatible name, which is prefer to use?
>>> for example, we have two dwmmc compatible name in rk3399, the tool is using
>>> the first one,
>>> while the source code using the last one.
>>>
>>> "drivers/mmc/rockchip_dw_mmc.c"
>>>   23 struct rockchip_mmc_plat {
>>>   24 #if CONFIG_IS_ENABLED(OF_PLATDATA)
>>>   25 struct dtd_rockchip_rk3288_dw_mshc dtplat;
>>>   26 #endif
>>>   27 struct mmc_config cfg;
>>>   28 struct mmc mmc;
>>>   29 };
>>> ...
>>> dts node
>>>  sdmmc: dwmmc@fe32 {
>>> compatible = "rockchip,rk3399-dw-mshc",
>>>   "rockchip,rk3288-dw-mshc";
>> I'm not sure of the best solution here (other than putting more
>> on-chip SRAM in your devices hint hint :-)
>>
>> One option is something like:
>>
>> struct rockchip_mmc_plat {
>> #if CONFIG_IS_ENABLED(OF_PLATDATA)
>> #ifdef CONFIG_ROCKCHIP_RK3288
>>  struct dtd_rockchip_rk3288_dw_mshc dtplat;
>> #elif defined(CONFIG_ROCKCHIP_RK399)
>>  struct dtd_rockchip_rk399_dw_mshc dtplat;
>> #endif
>> #endif
>>
>> Obviously we don't want that as it is putting SoC-specific stuff in the 
>> driver.
>>
>> IMO the compatible strings are being misused a bit. Can there not be a
>> compatible string which is common to all rockchip devices which use
>> this IP? Something like "rockchip,dw-mshc-v1"? Then you can avoid
>> adding a new compatible string every time you use the same IP in a
>> device.
> 
> Agree, but... this is from kernel, we can't control it unless all kernel 
> maintainers
> have the same idea.

does it use just "rockchip,dw-mshc"? Maybe this can be common compatible for 
rockchip.
If it needs add the other compatible in future, it should be added the specific 
compatible at that time.

>>
>> Another option would be for dtoc to #define each compatible string to
>> the first one. If you think that would work, I could do a patch.
> 
> I think we can try with the first one in the driver for of-platdata,
> this would have problem for the first compatible name is different but
> they share the same driver, like syscon. For syscon, you have resolved with
> a special dirver, not sure if other driver has the same problem.
> 
> Could you help to make a patch for this solution?
> 
> Thanks,
> - Kever
>>
>> Regards,
>> Simon
>>
>>
>>
> 
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v4 0/16] sunxi: Add support for the CHIP Pro

2017-02-13 Thread Maxime Ripard
Hi Jagan, Scott,

On Mon, Jan 23, 2017 at 02:46:42PM +0100, Maxime Ripard wrote:
> The CHIP Pro is a SoM made by NextThing Co, and that embeds a GR8 SIP, an
> AXP209 PMIC, a WiFi BT chip and a 512MB SLC NAND.
> 
> Since the first Allwinner device coming whit an SLC NAND that doesn't have
> the shortcomings (and breakages) the MLC NAND has, we can finally enable
> the NAND support on a board by default.
> 
> This is the occasion to introduce a bunch of additions needed imo to be
> able to come up with a sane NAND support for our users.
> 
> The biggest pain point is that the BROM uses a different ECC and randomizer
> configuration than for the rest of the NAND. In order to lessen the number
> of bitflips, you also need to pad with random data the SPL image.
> 
> Since it's quite tedious to do right (and most users won't be able to
> figure it out) and since if it is not done right, it will eventually turn
> into an unusable system (which is bad UX), we think that the best solution
> is to generate an SPL image that already embeds all this. We'll possible
> have to do the same thing for the U-Boot image (at least for the random
> padding) on MLC NANDs.
> 
> The only drawback from that is that you need to flash it raw, instead of
> using the usual nand write, but it's just a different command, nothing
> major anyway.
> 
> In order to flash it, from a device switched in FEL, on your host:
> sunxi-fel spl spl/sunxi-spl.bin
> sunxi-fel write 0x4a00 u-boot-dtb.bin
> sunxi-fel write 0x4300 spl/sunxi-spl-with-ecc.bin
> sunxi-fel exe 0x4a00
> 
> And on the board, once u-boot is running (assuming the NAND is already
> erased):
> 
> nand write.raw.noverify 0x4300 0 40
> nand write.raw.noverify 0x4300 0x40 40
> 
> nand write 0x4a00 0x80 0xc

Any objections to merging that?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/2] rsa: Fix build with OpenSSL 1.1.x

2017-02-13 Thread Peter Robinson
On Mon, Feb 13, 2017 at 9:00 AM, Jelle van der Waa  wrote:
> The rsa_st struct has been made opaque in 1.1.x, add forward compatible
> code to access the n, e, d members of rsa_struct.
>
> EVP_MD_CTX_cleanup has been removed in 1.1.x and EVP_MD_CTX_reset should be
> called to reinitialise an already created structure.

You can add my tested by. Built on Fedora 26 with 1.1.0d. gcc 7 etc.

Peter

> ---
>  lib/rsa/rsa-sign.c | 33 +++--
>  1 file changed, 27 insertions(+), 6 deletions(-)
>
> diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
> index 8c6637e328..965fb00f95 100644
> --- a/lib/rsa/rsa-sign.c
> +++ b/lib/rsa/rsa-sign.c
> @@ -20,6 +20,19 @@
>  #define HAVE_ERR_REMOVE_THREAD_STATE
>  #endif
>
> +#if OPENSSL_VERSION_NUMBER < 0x1010L
> +void RSA_get0_key(const RSA *r,
> + const BIGNUM **n, const BIGNUM **e, const BIGNUM **d)
> +{
> +   if (n != NULL)
> +   *n = r->n;
> +   if (e != NULL)
> +   *e = r->e;
> +   if (d != NULL)
> +   *d = r->d;
> +}
> +#endif
> +
>  static int rsa_err(const char *msg)
>  {
> unsigned long sslErr = ERR_get_error();
> @@ -409,7 +422,11 @@ static int rsa_sign_with_key(RSA *rsa, struct 
> checksum_algo *checksum_algo,
> ret = rsa_err("Could not obtain signature");
> goto err_sign;
> }
> -   EVP_MD_CTX_cleanup(context);
> +   #if OPENSSL_VERSION_NUMBER < 0x1010L
> +   EVP_MD_CTX_cleanup(context);
> +   #else
> +   EVP_MD_CTX_reset(context);
> +   #endif
> EVP_MD_CTX_destroy(context);
> EVP_PKEY_free(key);
>
> @@ -479,6 +496,7 @@ static int rsa_get_exponent(RSA *key, uint64_t *e)
>  {
> int ret;
> BIGNUM *bn_te;
> +   const BIGNUM *key_e;
> uint64_t te;
>
> ret = -EINVAL;
> @@ -487,17 +505,18 @@ static int rsa_get_exponent(RSA *key, uint64_t *e)
> if (!e)
> goto cleanup;
>
> -   if (BN_num_bits(key->e) > 64)
> +   RSA_get0_key(key, NULL, &key_e, NULL);
> +   if (BN_num_bits(key_e) > 64)
> goto cleanup;
>
> -   *e = BN_get_word(key->e);
> +   *e = BN_get_word(key_e);
>
> -   if (BN_num_bits(key->e) < 33) {
> +   if (BN_num_bits(key_e) < 33) {
> ret = 0;
> goto cleanup;
> }
>
> -   bn_te = BN_dup(key->e);
> +   bn_te = BN_dup(key_e);
> if (!bn_te)
> goto cleanup;
>
> @@ -527,6 +546,7 @@ int rsa_get_params(RSA *key, uint64_t *exponent, uint32_t 
> *n0_invp,
>  {
> BIGNUM *big1, *big2, *big32, *big2_32;
> BIGNUM *n, *r, *r_squared, *tmp;
> +   const BIGNUM *key_n;
> BN_CTX *bn_ctx = BN_CTX_new();
> int ret = 0;
>
> @@ -548,7 +568,8 @@ int rsa_get_params(RSA *key, uint64_t *exponent, uint32_t 
> *n0_invp,
> if (0 != rsa_get_exponent(key, exponent))
> ret = -1;
>
> -   if (!BN_copy(n, key->n) || !BN_set_word(big1, 1L) ||
> +   RSA_get0_key(key, NULL, &key_n, NULL);
> +   if (!BN_copy(n, key_n) || !BN_set_word(big1, 1L) ||
> !BN_set_word(big2, 2L) || !BN_set_word(big32, 32L))
> ret = -1;
>
> --
> 2.11.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v4 0/16] sunxi: Add support for the CHIP Pro

2017-02-13 Thread Jagan Teki

On Monday 13 February 2017 03:23 PM, Maxime Ripard wrote:

Hi Jagan, Scott,

On Mon, Jan 23, 2017 at 02:46:42PM +0100, Maxime Ripard wrote:

The CHIP Pro is a SoM made by NextThing Co, and that embeds a GR8 SIP, an
AXP209 PMIC, a WiFi BT chip and a 512MB SLC NAND.

Since the first Allwinner device coming whit an SLC NAND that doesn't have
the shortcomings (and breakages) the MLC NAND has, we can finally enable
the NAND support on a board by default.

This is the occasion to introduce a bunch of additions needed imo to be
able to come up with a sane NAND support for our users.

The biggest pain point is that the BROM uses a different ECC and randomizer
configuration than for the rest of the NAND. In order to lessen the number
of bitflips, you also need to pad with random data the SPL image.

Since it's quite tedious to do right (and most users won't be able to
figure it out) and since if it is not done right, it will eventually turn
into an unusable system (which is bad UX), we think that the best solution
is to generate an SPL image that already embeds all this. We'll possible
have to do the same thing for the U-Boot image (at least for the random
padding) on MLC NANDs.

The only drawback from that is that you need to flash it raw, instead of
using the usual nand write, but it's just a different command, nothing
major anyway.

In order to flash it, from a device switched in FEL, on your host:
sunxi-fel spl spl/sunxi-spl.bin
sunxi-fel write 0x4a00 u-boot-dtb.bin
sunxi-fel write 0x4300 spl/sunxi-spl-with-ecc.bin
sunxi-fel exe 0x4a00

And on the board, once u-boot is running (assuming the NAND is already
erased):

nand write.raw.noverify 0x4300 0 40
nand write.raw.noverify 0x4300 0x40 40

nand write 0x4a00 0x80 0xc


Any objections to merging that?


I've few comments, and answered then as well. Let me comeback with those 
rest look OK to me.


thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2 0/6] arm: am57xx: cl-som-am57x: fix usb

2017-02-13 Thread Uri Mashiach
Various USB related comits for the CL-SOM-AM57x module.

---
V1 -> V2: Replace commit "fix XHCI registers base address" with "reintroduce 
the CONFIG_AM57XX symbol".

Uri Mashiach (6):
  arm: am57xx: reintroduce the CONFIG_AM57XX symbol
  usb: host: xhci-omap: fix double weak board_usb_init functions
  arm: am57xx: cl-som-am57x: invoke clock API to enable/disable clocks
  arm: am57xx: cl-som-am57x: fix USB scan
  arm: am57xx: cl-som-am57x: enable USB storage
  arm: am57xx: cl-som-am57x: enable USB commands

 board/compulab/cl-som-am57x/cl-som-am57x.c | 10 --
 board/ti/am43xx/board.c|  4 ++--
 board/ti/am57xx/board.c|  4 ++--
 board/ti/dra7xx/evm.c  |  4 ++--
 configs/cl-som-am57x_defconfig |  2 ++
 drivers/usb/host/xhci-omap.c   | 19 +--
 include/configs/am57xx_evm.h   |  1 +
 include/configs/cl-som-am57x.h |  5 +++--
 include/linux/usb/xhci-omap.h  |  2 +-
 scripts/config_whitelist.txt   |  1 +
 10 files changed, 31 insertions(+), 21 deletions(-)

-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2 1/6] arm: am57xx: reintroduce the CONFIG_AM57XX symbol

2017-02-13 Thread Uri Mashiach
The SOC family symbol CONFIG_AM57XX was removed by the commit
3891a54: "ARM: DRA7x/AM57xx: Get rid of CONFIG_AM57XX".

The symbol is needed by the XHCI OMAP USB driver.
Without the symbol all the AM57x targets symbols should be ored in the
ifdef'ery.

Signed-off-by: Uri Mashiach 
---
V1 -> V2: Replace the commit "fix XHCI registers base address".

 include/configs/am57xx_evm.h   | 1 +
 include/configs/cl-som-am57x.h | 1 +
 include/linux/usb/xhci-omap.h  | 2 +-
 scripts/config_whitelist.txt   | 1 +
 4 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/configs/am57xx_evm.h b/include/configs/am57xx_evm.h
index 3d8b996..2896628 100644
--- a/include/configs/am57xx_evm.h
+++ b/include/configs/am57xx_evm.h
@@ -15,6 +15,7 @@
 #include 
 
 #define CONFIG_DRA7XX
+#define CONFIG_AM57XX
 
 #ifdef CONFIG_SPL_BUILD
 #define CONFIG_IODELAY_RECALIBRATION
diff --git a/include/configs/cl-som-am57x.h b/include/configs/cl-som-am57x.h
index e1f724b..4d1ceff 100644
--- a/include/configs/cl-som-am57x.h
+++ b/include/configs/cl-som-am57x.h
@@ -12,6 +12,7 @@
 #define __CONFIG_CL_SOM_AM57X_H
 
 #define CONFIG_DRA7XX
+#define CONFIG_AM57XX
 
 #define CONFIG_NR_DRAM_BANKS   2
 
diff --git a/include/linux/usb/xhci-omap.h b/include/linux/usb/xhci-omap.h
index 9de80d7..ba21d60 100644
--- a/include/linux/usb/xhci-omap.h
+++ b/include/linux/usb/xhci-omap.h
@@ -14,7 +14,7 @@
 #define OMAP_XHCI_BASE 0x488d
 #define OMAP_OCP1_SCP_BASE 0x4A081000
 #define OMAP_OTG_WRAPPER_BASE 0x488c
-#elif defined CONFIG_TARGET_AM57XX_EVM
+#elif defined CONFIG_AM57XX
 #define OMAP_XHCI_BASE 0x4889
 #define OMAP_OCP1_SCP_BASE 0x4A084c00
 #define OMAP_OTG_WRAPPER_BASE 0x4888
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index d21589b..7c7f372 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -85,6 +85,7 @@ CONFIG_AM335X_USB0_MODE
 CONFIG_AM335X_USB1
 CONFIG_AM335X_USB1_MODE
 CONFIG_AM437X_USB2PHY2_HOST
+CONFIG_AM57XX
 CONFIG_AMBAPP_IOAREA
 CONFIG_AMCC_DEF_ENV
 CONFIG_AMCC_DEF_ENV_NOR_UPD
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2 2/6] usb: host: xhci-omap: fix double weak board_usb_init functions

2017-02-13 Thread Uri Mashiach
A weak version of the function board_usb_init is implemented in:
common/usb.c
drivers/usb/host/xhci-omap.c

To fix the double implementations:
* Convert the board_usb_init function in drivers/usb/host/xhci-omap.c
  normal (not weak).
* The function board_usb_init in drivers/usb/host/xhci-omap.c calls to
  the weak function omap_xhci_board_usb_init.
* Rename board version of the function board_usb_init to
  omap_xhci_board_usb_init.
  Done only for boards that defines CONFIG_USB_XHCI_OMAP.

To achieve the same flexibility with the function board_usb_cleanup:
* Add a normal (not weak) implementation of the function
  board_usb_cleanup in drivers/usb/host/xhci-omap.c
* The function board_usb_cleanup in drivers/usb/host/xhci-omap.c calls
  to the weak function omap_xhci_board_usb_cleanup.
* Rename board version of the function board_usb_cleanup to
  omap_xhci_board_usb_cleanup.
  Done only for boards that defines CONFIG_USB_XHCI_OMAP.

Signed-off-by: Uri Mashiach 
---
V1 -> V2: Use __weak instead of attribute block

 board/compulab/cl-som-am57x/cl-som-am57x.c |  2 +-
 board/ti/am43xx/board.c|  4 ++--
 board/ti/am57xx/board.c|  4 ++--
 board/ti/dra7xx/evm.c  |  4 ++--
 drivers/usb/host/xhci-omap.c   | 17 +++--
 5 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/board/compulab/cl-som-am57x/cl-som-am57x.c 
b/board/compulab/cl-som-am57x/cl-som-am57x.c
index bdd0a2b..fe1468f 100644
--- a/board/compulab/cl-som-am57x/cl-som-am57x.c
+++ b/board/compulab/cl-som-am57x/cl-som-am57x.c
@@ -54,7 +54,7 @@ int board_mmc_init(bd_t *bis)
 #endif /* CONFIG_GENERIC_MMC */
 
 #ifdef CONFIG_USB_XHCI_OMAP
-int board_usb_init(int index, enum usb_init_type init)
+int omap_xhci_board_usb_init(int index, enum usb_init_type init)
 {
setbits_le32((*prcm)->cm_l3init_usb_otg_ss1_clkctrl,
 OTG_SS_CLKCTRL_MODULEMODE_HW | OPTFCLKEN_REFCLK960M);
diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index 390cc16..2572029 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -694,7 +694,7 @@ int usb_gadget_handle_interrupts(int index)
 #endif /* CONFIG_USB_DWC3 */
 
 #if defined(CONFIG_USB_DWC3) || defined(CONFIG_USB_XHCI_OMAP)
-int board_usb_init(int index, enum usb_init_type init)
+int omap_xhci_board_usb_init(int index, enum usb_init_type init)
 {
enable_usb_clocks(index);
 #ifdef CONFIG_USB_DWC3
@@ -725,7 +725,7 @@ int board_usb_init(int index, enum usb_init_type init)
return 0;
 }
 
-int board_usb_cleanup(int index, enum usb_init_type init)
+int omap_xhci_board_usb_cleanup(int index, enum usb_init_type init)
 {
 #ifdef CONFIG_USB_DWC3
switch (index) {
diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index 5f2d4df..96fad0f 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -616,7 +616,7 @@ int usb_gadget_handle_interrupts(int index)
 #endif /* CONFIG_USB_DWC3 */
 
 #if defined(CONFIG_USB_DWC3) || defined(CONFIG_USB_XHCI_OMAP)
-int board_usb_init(int index, enum usb_init_type init)
+int omap_xhci_board_usb_init(int index, enum usb_init_type init)
 {
enable_usb_clocks(index);
switch (index) {
@@ -650,7 +650,7 @@ int board_usb_init(int index, enum usb_init_type init)
return 0;
 }
 
-int board_usb_cleanup(int index, enum usb_init_type init)
+int omap_xhci_board_usb_cleanup(int index, enum usb_init_type init)
 {
 #ifdef CONFIG_USB_DWC3
switch (index) {
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index bd1c809..21fa824 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -727,7 +727,7 @@ static struct ti_usb_phy_device usb_phy2_device = {
.index = 1,
 };
 
-int board_usb_init(int index, enum usb_init_type init)
+int  omap_xhci_board_usb_init(int index, enum usb_init_type init)
 {
enable_usb_clocks(index);
switch (index) {
@@ -764,7 +764,7 @@ int board_usb_init(int index, enum usb_init_type init)
return 0;
 }
 
-int board_usb_cleanup(int index, enum usb_init_type init)
+int omap_xhci_board_usb_cleanup(int index, enum usb_init_type init)
 {
switch (index) {
case 0:
diff --git a/drivers/usb/host/xhci-omap.c b/drivers/usb/host/xhci-omap.c
index b881b19..a1b4f2f 100644
--- a/drivers/usb/host/xhci-omap.c
+++ b/drivers/usb/host/xhci-omap.c
@@ -27,12 +27,25 @@ DECLARE_GLOBAL_DATA_PTR;
 
 static struct omap_xhci omap;
 
-__weak int __board_usb_init(int index, enum usb_init_type init)
+__weak int omap_xhci_board_usb_init(int index, enum usb_init_type init)
 {
return 0;
 }
+
 int board_usb_init(int index, enum usb_init_type init)
-   __attribute__((weak, alias("__board_usb_init")));
+{
+   return omap_xhci_board_usb_init(index, init);
+}
+
+__weak int omap_xhci_board_usb_cleanup(int index, enum usb_init_type init)
+{
+   return 0;
+}
+
+int board_usb_cleanup(int index, enum usb_init_type init)
+{
+   return omap_xhci_board_us

[U-Boot] [PATCH v2 3/6] arm: am57xx: cl-som-am57x: invoke clock API to enable/disable clocks

2017-02-13 Thread Uri Mashiach
Invoke enable_usb_clocks during board_usb_init and disable_usb_clocks
during board_usb_exit to enable and disable clocks respectively.

Modifications:
* Enable USB clocks in the OMAP version of the function
  board_usb_init.
* Disable USB clocks in the OMAP version of the function
  board_usb_cleanup.

Signed-off-by: Uri Mashiach 
Reviewed-by: Marek Vasut 
Reviewed-by: Tom Rini 
---
V1 -> V2: none

 board/compulab/cl-som-am57x/cl-som-am57x.c | 10 --
 drivers/usb/host/xhci-omap.c   |  2 ++
 2 files changed, 2 insertions(+), 10 deletions(-)

diff --git a/board/compulab/cl-som-am57x/cl-som-am57x.c 
b/board/compulab/cl-som-am57x/cl-som-am57x.c
index fe1468f..4701b71 100644
--- a/board/compulab/cl-som-am57x/cl-som-am57x.c
+++ b/board/compulab/cl-som-am57x/cl-som-am57x.c
@@ -53,16 +53,6 @@ int board_mmc_init(bd_t *bis)
 }
 #endif /* CONFIG_GENERIC_MMC */
 
-#ifdef CONFIG_USB_XHCI_OMAP
-int omap_xhci_board_usb_init(int index, enum usb_init_type init)
-{
-   setbits_le32((*prcm)->cm_l3init_usb_otg_ss1_clkctrl,
-OTG_SS_CLKCTRL_MODULEMODE_HW | OPTFCLKEN_REFCLK960M);
-
-   return 0;
-}
-#endif /* CONFIG_USB_XHCI_OMAP */
-
 int misc_init_r(void)
 {
cl_print_pcb_info();
diff --git a/drivers/usb/host/xhci-omap.c b/drivers/usb/host/xhci-omap.c
index a1b4f2f..d6c5744 100644
--- a/drivers/usb/host/xhci-omap.c
+++ b/drivers/usb/host/xhci-omap.c
@@ -29,6 +29,7 @@ static struct omap_xhci omap;
 
 __weak int omap_xhci_board_usb_init(int index, enum usb_init_type init)
 {
+   enable_usb_clocks(index);
return 0;
 }
 
@@ -39,6 +40,7 @@ int board_usb_init(int index, enum usb_init_type init)
 
 __weak int omap_xhci_board_usb_cleanup(int index, enum usb_init_type init)
 {
+   disable_usb_clocks(index);
return 0;
 }
 
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2 4/6] arm: am57xx: cl-som-am57x: fix USB scan

2017-02-13 Thread Uri Mashiach
USB bus scan attempt:
--cut--
=> usb start
starting USB...
USB0:   Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus 0 for devices... data abort
pc : []  lr : []
reloc pc : [<8081b40e>]lr : [<8081b3b3>]
sp : fdf42930  ip : fdf42960 fp : 
r10: 0001  r9 : fdf42ef0 r8 : 48890020
r7 : 0002  r6 : fffa5840 r5 : fff8b140  r4 : fdf429c0
r3 :   r2 : 0004 r1 :   r0 : 
Flags: nZcv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

resetting ...
--cut--

Fix by enabling USB configuration in the SPL.

Signed-off-by: Uri Mashiach 
Reviewed-by: Tom Rini 
Reviewed-by: Igor Grinberg 
---
V1 -> V2: none

 include/configs/cl-som-am57x.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/configs/cl-som-am57x.h b/include/configs/cl-som-am57x.h
index 4d1ceff..ebc7d67 100644
--- a/include/configs/cl-som-am57x.h
+++ b/include/configs/cl-som-am57x.h
@@ -86,6 +86,8 @@
 #define CONFIG_SYS_I2C_PCA953X_ADDR 0x20
 #define CONFIG_SYS_I2C_PCA953X_WIDTH{ {0x20, 16} }
 
+#endif /* !CONFIG_SPL_BUILD */
+
 /* USB xHCI HOST */
 #define CONFIG_USB_XHCI_OMAP
 #define CONFIG_SYS_USB_XHCI_MAX_ROOT_PORTS 2
@@ -100,8 +102,6 @@
 #define CONFIG_USB_ETHER_ASIX
 #define CONFIG_USB_ETHER_MCS7830
 
-#endif /* !CONFIG_SPL_BUILD */
-
 /* CPSW Ethernet */
 #define CONFIG_DRIVER_TI_CPSW
 #define CONFIG_MII
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2 5/6] arm: am57xx: cl-som-am57x: enable USB storage

2017-02-13 Thread Uri Mashiach
Add CONFIG_USB_STORAGE to the defconfig file.

Signed-off-by: Uri Mashiach 
Reviewed-by: Tom Rini 
---
 V1 -> V2: none

configs/cl-som-am57x_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/cl-som-am57x_defconfig b/configs/cl-som-am57x_defconfig
index 916b836..1831f45 100644
--- a/configs/cl-som-am57x_defconfig
+++ b/configs/cl-som-am57x_defconfig
@@ -47,4 +47,5 @@ CONFIG_TI_QSPI=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_STORAGE=y
 CONFIG_OF_LIBFDT=y
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2 6/6] arm: am57xx: cl-som-am57x: enable USB commands

2017-02-13 Thread Uri Mashiach
Add CONFIG_CMD_USB to the defconfig file.

Signed-off-by: Uri Mashiach 
Reviewed-by: Tom Rini 
---
V1 -> V2: none

 configs/cl-som-am57x_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/cl-som-am57x_defconfig b/configs/cl-som-am57x_defconfig
index 1831f45..83d7bd0 100644
--- a/configs/cl-som-am57x_defconfig
+++ b/configs/cl-som-am57x_defconfig
@@ -15,6 +15,7 @@ CONFIG_CMD_PART=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_SPI=y
 CONFIG_CMD_I2C=y
+CONFIG_CMD_USB=y
 CONFIG_CMD_GPIO=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_DHCP=y
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/6] arm: am57xx: cl-som-am57x: fix XHCI registers base address

2017-02-13 Thread Lokesh Vutla


On Sunday 12 February 2017 09:17 PM, Tom Rini wrote:
> On Sun, Feb 12, 2017 at 10:55:27AM +0200, Uri Mashiach wrote:
>> Hi Tom,
>>
>> On 02/09/2017 10:29 PM, Tom Rini wrote:
>>> On Thu, Feb 09, 2017 at 09:00:26AM +0200, Uri Mashiach wrote:
>>>
 The following XHCI registers base address are set to OMAP5 values:
 OMAP_XHCI_BASE, OMAP_OCP1_SCP_BASE, OMAP_OTG_WRAPPER_BASE

 Captured crash for "usb start" command:
 --cut--
 => usb start
 starting USB...
 USB0:   data abort
 pc : []  lr : []
 reloc pc : [<8081cd22>]lr : [<8081cb63>]
 sp : fdf42d08  ip : fff9e040 fp : fdf42d50
 r10: fff8a998  r9 : fdf42ef0 r8 : 
 r7 : fdf42d28  r6 : fdf42d2c r5 : fffa5c00  r4 : 
 r3 : 4a02  r2 :  r1 : fdf42e78  r0 : fffa5c00
 Flags: nzCv  IRQs off  FIQs off  Mode SVC_32
 Resetting CPU ...

 resetting ...
 --cut--

 Fix by adding the CL-SOM-AM57x target to the XHCI registers base address
 ifdef'ery.
 A better fix should be based on a SOC family defines (currently
 missing).
>>>
>>> Can you please go add the Kconfig symbols that would be the better
>>> solution please?  Thanks!
>>
>> The SOC family symbol CONFIG_AM57XX was removed by the commit
>> 3891a54: "ARM: DRA7x/AM57xx: Get rid of CONFIG_AM57XX".
>> Maybe the symbol should be reintroduced just for the XHCI registers
>> section?
> 
> Yes, sounds like we do have a case where DRA7xx is not the same as
> AM57xx then?
> 

No that's not right. It is just DRA74x_EVM and AM57XX evm is using
different instances of XHCI. Ideally this base address should be coming
from DT. I don't think it is a good idea to introduce CONFIG_AM57XX.

Thanks and regards,
Lokesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] am335x: musb: mass storage device issue

2017-02-13 Thread Yegor Yefremov
My am335x based board doesn't detect USB sticks:

U-Boot 2017.03-rc1 (Feb 13 2017 - 12:46:54 +0100)

CPU  : AM335X-GP rev 2.1
I2C:   ready
DRAM:  256 MiB
NAND:  256 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

Net:not set. Validating first E-fuse MAC
cpsw
Hit any key to stop autoboot:  0
=> usb reset
resetting USB...
USB0:   scanning bus 0 for devices... 2 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found


=> usb tree
USB device tree:
  1  Hub (480 Mb/s, 100mA)
  |   USB2.0 Hub
  |
  +-2  Vendor specific (480 Mb/s, 500mA)
   Quectel, Incorporated UMTS/HSPA Module

U-Boot finds a hub and a 3g modem attached to it, but the USB drive,
that is also attached to this hub won't be detected.

So far I haven't tried to bisect the issue (have to find a working
commit including my board), but the same setup is working for 2014.07
u-boot. Am I the only one or are other am335x based also affected?

Regards,
Yegor
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/6] arm: am57xx: cl-som-am57x: fix XHCI registers base address

2017-02-13 Thread Uri Mashiach



On 02/13/2017 01:46 PM, Lokesh Vutla wrote:



On Sunday 12 February 2017 09:17 PM, Tom Rini wrote:

On Sun, Feb 12, 2017 at 10:55:27AM +0200, Uri Mashiach wrote:

Hi Tom,

On 02/09/2017 10:29 PM, Tom Rini wrote:

On Thu, Feb 09, 2017 at 09:00:26AM +0200, Uri Mashiach wrote:


The following XHCI registers base address are set to OMAP5 values:
OMAP_XHCI_BASE, OMAP_OCP1_SCP_BASE, OMAP_OTG_WRAPPER_BASE

Captured crash for "usb start" command:
--cut--
=> usb start
starting USB...
USB0:   data abort
pc : []  lr : []
reloc pc : [<8081cd22>]lr : [<8081cb63>]
sp : fdf42d08  ip : fff9e040 fp : fdf42d50
r10: fff8a998  r9 : fdf42ef0 r8 : 
r7 : fdf42d28  r6 : fdf42d2c r5 : fffa5c00  r4 : 
r3 : 4a02  r2 :  r1 : fdf42e78  r0 : fffa5c00
Flags: nzCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

resetting ...
--cut--

Fix by adding the CL-SOM-AM57x target to the XHCI registers base address
ifdef'ery.
A better fix should be based on a SOC family defines (currently
missing).


Can you please go add the Kconfig symbols that would be the better
solution please?  Thanks!


The SOC family symbol CONFIG_AM57XX was removed by the commit
3891a54: "ARM: DRA7x/AM57xx: Get rid of CONFIG_AM57XX".
Maybe the symbol should be reintroduced just for the XHCI registers
section?


Yes, sounds like we do have a case where DRA7xx is not the same as
AM57xx then?



No that's not right. It is just DRA74x_EVM and AM57XX evm is using
different instances of XHCI. Ideally this base address should be coming
from DT. I don't think it is a good idea to introduce CONFIG_AM57XX.

Thanks and regards,
Lokesh


It seems that the address of register is SOC dependent.
In the current method all the target boards that use the relevant SOC 
should be included in the ifdef'ery - redundant maintenance.


--
Regards,
Uri
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 0/2] omapl: mmc boot help

2017-02-13 Thread Axel Haslam
The omapl-138 board can boot the ais image from mmc,
but the right offset needs to be provided to SPL.

This series fixes the uboot raw offset config option
and adds help text for the user to copy the AIS image
to the sd card.

Axel Haslam (2):
  da850: Add instructions to copy AIS image to an MMC card
  omapl138_lcdk: Set uboot raw mmc sector to 0x41

 board/davinci/da8xxevm/README.da850 | 16 
 configs/omapl138_lcdk_defconfig |  2 +-
 2 files changed, 17 insertions(+), 1 deletion(-)

-- 
2.9.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 1/2] da850: Add instructions to copy AIS image to an MMC card

2017-02-13 Thread Axel Haslam
The da850 soc's can boot from a external mmc card, but
the AIS image should be written to the correct sector.

Add instructions to copy the AIS image to a MMC card.

Signed-off-by: Axel Haslam 
---
 board/davinci/da8xxevm/README.da850 | 16 
 1 file changed, 16 insertions(+)

diff --git a/board/davinci/da8xxevm/README.da850 
b/board/davinci/da8xxevm/README.da850
index 313a1ef..e8fec3e 100644
--- a/board/davinci/da8xxevm/README.da850
+++ b/board/davinci/da8xxevm/README.da850
@@ -47,6 +47,22 @@ U-Boot > sf erase 0 +32
 U-Boot > tftp u-boot.ais
 U-Boot > sf write c070 0 $filesize
 
+Flashing the images to MMC
+==
+If the boot pins are set to boot from mmc, the RBL will try to load the
+next boot stage form the first couple of sectors of an external mmc card.
+As sector 0 is usually used for storing the partition information, the
+AIS image should be written after the first sector, but before the first
+partition begins. (e.g: make sure to leave at least 500KB of unallocated
+space at the start of the mmc when creating the partitions)
+
+To skip the first sector, the AIS image can then written using
+the following dd command:
+dd if=u-boot.ais of=/dev/mmcblk0 seek=1 bs=512 conv=fsync
+
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR is used by SPL, and should
+point to the sector were the u-boot image starts on the MMC card.
+(eg. after SPL).
 
 Recovery
 
-- 
2.9.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [U-Boot, v5, 1/2] gpio: at91_gpio: Remove CPU_HAS_PIO3 macro

2017-02-13 Thread Wenyou.Yang
Hi Andreas,

> -Original Message-
> From: Andreas Bießmann [mailto:andr...@biessmann.org]
> Sent: 2017年2月13日 7:42
> To: Tony Yang - A41535 
> Cc: U-Boot Mailing List ; Stephen Warren
> 
> Subject: Re: [U-Boot,v5,1/2] gpio: at91_gpio: Remove CPU_HAS_PIO3 macro
> 
> On Tue, Feb 07, 2017 at 02:07:18PM +0800, Wenyou Yang wrote:
> > The intention of this patch is the preparation to introduce
> > the pinctrl driver for AT91 PIO.
> >
> > Use "union" to make the PIO3 and PIO2's registers be together
> > and make their offset aligned.
> >
> 
> This patch breaks on at91 devices without PIO3 due to missing PIO_SCDR_DIV
> define, please fix this. First one failing for me using buildman is pm9g45.

Fixed, will send a new version.

> 
> Andreas
> 

Best Regards,
Wenyou Yang

> > Signed-off-by: Wenyou Yang 
> > ---
> >
> > Changes in v5: None
> > Changes in v4:
> >  - Fix the incomplete conversion of the peripheral configurations on
> >the sama5d3, sam9x5, and sam9n12.
> >
> > Changes in v3: None
> > Changes in v2: None
> >
> >  arch/arm/mach-at91/arm926ejs/at91sam9n12_devices.c | 106 ++--
> >  arch/arm/mach-at91/arm926ejs/at91sam9x5_devices.c  | 112 ++---
> >  arch/arm/mach-at91/armv7/sama5d3_devices.c | 140 
> >  arch/arm/mach-at91/include/mach/at91_pio.h |  61 +++
> >  arch/arm/mach-at91/include/mach/at91sam9x5.h   |   1 -
> >  arch/arm/mach-at91/include/mach/sama5d3.h  |   1 -
> >  arch/arm/mach-at91/include/mach/sama5d4.h  |   1 -
> >  board/atmel/at91sam9n12ek/at91sam9n12ek.c  |  10 +-
> >  board/atmel/at91sam9x5ek/at91sam9x5ek.c|  90 +--
> >  board/atmel/sama5d3xek/sama5d3xek.c|  64 
> >  board/atmel/sama5d4_xplained/sama5d4_xplained.c| 148 -
> >  board/atmel/sama5d4ek/sama5d4ek.c  | 136 
> >  board/denx/ma5d4evk/ma5d4evk.c | 178 
> > ++---
> >  board/l+g/vinco/vinco.c|  70 
> >  drivers/gpio/at91_gpio.c   | 142 ++--
> >  15 files changed, 656 insertions(+), 604 deletions(-)
> >
> > diff --git a/arch/arm/mach-at91/arm926ejs/at91sam9n12_devices.c
> b/arch/arm/mach-at91/arm926ejs/at91sam9n12_devices.c
> > index a03abfc310..28c8cf260a 100644
> > --- a/arch/arm/mach-at91/arm926ejs/at91sam9n12_devices.c
> > +++ b/arch/arm/mach-at91/arm926ejs/at91sam9n12_devices.c
> > @@ -18,45 +18,45 @@ unsigned int has_lcdc()
> >
> >  void at91_serial0_hw_init(void)
> >  {
> > -   at91_set_a_periph(AT91_PIO_PORTA, 0, 1);/* TXD0 */
> > -   at91_set_a_periph(AT91_PIO_PORTA, 1, 0);/* RXD0 */
> > +   at91_pio3_set_a_periph(AT91_PIO_PORTA, 0, 1);   /* TXD0 */
> > +   at91_pio3_set_a_periph(AT91_PIO_PORTA, 1, 0);   /* RXD0
> */
> > at91_periph_clk_enable(ATMEL_ID_USART0);
> >  }
> >
> >  void at91_serial1_hw_init(void)
> >  {
> > -   at91_set_a_periph(AT91_PIO_PORTA, 5, 1);/* TXD1 */
> > -   at91_set_a_periph(AT91_PIO_PORTA, 6, 0);/* RXD1 */
> > +   at91_pio3_set_a_periph(AT91_PIO_PORTA, 5, 1);   /* TXD1 */
> > +   at91_pio3_set_a_periph(AT91_PIO_PORTA, 6, 0);   /* RXD1
> */
> > at91_periph_clk_enable(ATMEL_ID_USART1);
> >  }
> >
> >  void at91_serial2_hw_init(void)
> >  {
> > -   at91_set_a_periph(AT91_PIO_PORTA, 7, 1);/* TXD2 */
> > -   at91_set_a_periph(AT91_PIO_PORTA, 8, 0);/* RXD2 */
> > +   at91_pio3_set_a_periph(AT91_PIO_PORTA, 7, 1);   /* TXD2 */
> > +   at91_pio3_set_a_periph(AT91_PIO_PORTA, 8, 0);   /* RXD2
> */
> > at91_periph_clk_enable(ATMEL_ID_USART2);
> >  }
> >
> >  void at91_serial3_hw_init(void)
> >  {
> > -   at91_set_b_periph(AT91_PIO_PORTC, 22, 1);   /* TXD3 */
> > -   at91_set_b_periph(AT91_PIO_PORTC, 23, 0);   /* RXD3 */
> > +   at91_pio3_set_b_periph(AT91_PIO_PORTC, 22, 1);  /* TXD3 */
> > +   at91_pio3_set_b_periph(AT91_PIO_PORTC, 23, 0);  /* RXD3
> */
> > at91_periph_clk_enable(ATMEL_ID_USART3);
> >  }
> >
> >  void at91_seriald_hw_init(void)
> >  {
> > -   at91_set_a_periph(AT91_PIO_PORTA, 10, 1);   /* DTXD */
> > -   at91_set_a_periph(AT91_PIO_PORTA, 9, 0);/* DRXD */
> > +   at91_pio3_set_a_periph(AT91_PIO_PORTA, 10, 1);  /* DTXD
> */
> > +   at91_pio3_set_a_periph(AT91_PIO_PORTA, 9, 0);   /* DRXD
> */
> > at91_periph_clk_enable(ATMEL_ID_SYS);
> >  }
> >
> >  #ifdef CONFIG_ATMEL_SPI
> >  void at91_spi0_hw_init(unsigned long cs_mask)
> >  {
> > -   at91_set_a_periph(AT91_PIO_PORTA, 11, 0);   /* SPI0_MISO */
> > -   at91_set_a_periph(AT91_PIO_PORTA, 12, 0);   /* SPI0_MOSI */
> > -   at91_set_a_periph(AT91_PIO_PORTA, 13, 0);   /* SPI0_SPCK */
> > +   at91_pio3_set_a_periph(AT91_PIO_PORTA, 11, 0);  /* SPI0_MISO */
> > +   at91_pio3_set_a_periph(AT91_PIO_PORTA, 12, 0);  /*

Re: [U-Boot] [PATCH v1] usb: gadget: f_dfu: write req->actual bytes

2017-02-13 Thread Felipe Balbi

Hi,

Marek Vasut  writes:
> On 02/10/2017 05:32 PM, Andy Shevchenko wrote:
>> From: Felipe Balbi 
>> 
>> If last packet is short, we shouldn't write req->length bytes to
>> non-volatile media, we should write only what's available to us, which
>> is held in req->actual.
>> 
>> Signed-off-by: Felipe Balbi 
>> Signed-off-by: Andy Shevchenko 
>
> Since I have no clue about DFU internals, I will wait for Lukasz's Ack.

you don't need to have any clues about DFU internals to realise that
this fixes an actual bug, see below:

>>  drivers/usb/gadget/f_dfu.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/usb/gadget/f_dfu.c b/drivers/usb/gadget/f_dfu.c
>> index 8e7c981657..64cdfa7c98 100644
>> --- a/drivers/usb/gadget/f_dfu.c
>> +++ b/drivers/usb/gadget/f_dfu.c
>> @@ -159,7 +159,7 @@ static void dnload_request_complete(struct usb_ep *ep, 
>> struct usb_request *req)
>>  int ret;
>>  
>>  ret = dfu_write(dfu_get_entity(f_dfu->altsetting), req->buf,
>> -req->length, f_dfu->blk_seq_num);
>> +req->actual, f_dfu->blk_seq_num);

DFU driver queues a request to USB controller. Per the gadget API
req->length contains maximum amount of data to be
transmitted. req->actual is written by USB controller with the actual
amount of data that we transmitted.

In the case of IN (TX), upon completion req->length and req->actual
should always be equal (unless errors show up, etc)

In the case of OUT (RX), upon completion req->actual MAY BE less than
req->length and that's not an error. Say host sent us a short packet
which causes early termination of transfer.

With that in mind, let's consider the situation where we're receiving
data from host using DFU. Let's assume that we have a 4096 byte buffer
for transfers and we're receiving a binary that's 7679 bytes in size.

Here's what we will do (pseudo-code):

int remaining = 7679;
char buf[4096];

while (remaining) {
req->length = 4096;
req->buf = buf;
usb_ep_queue(req);

/* wait for completion */

remaining -= req->actual;

dfu_write(buf, req->length);  /* this is the error */
}

Can you see here that in the last packet we will write 4096 bytes when
we should write only 3583?

-- 
balbi


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v1] usb: gadget: f_dfu: write req->actual bytes

2017-02-13 Thread Felipe Balbi

Hi Lukasz,

Lukasz Majewski  writes:
> Hi Felipe,
>
> Thanks for the patch.
> Please see my comments below.
>
> On 13 Feb 2017 11:42 am, Felipe Balbi  wrote:
>
>  Hi, 
>
>  Marek Vasut  writes: 
>  > On 02/10/2017 05:32 PM, Andy Shevchenko wrote: 
>  >> From: Felipe Balbi  
>  >> 
>  >> If last packet is short, we shouldn't write req->length bytes to 
>  >> non-volatile media, we should write only what's available to us, which 
>  >> is held in req->actual. 
>  >> 
>  >> Signed-off-by: Felipe Balbi  
>  >> Signed-off-by: Andy Shevchenko  
>  > 
>  > Since I have no clue about DFU internals, I will wait for Lukasz's Ack. 
>
>  you don't need to have any clues about DFU internals to realise that 
>  this fixes an actual bug, see below: 
>
> I don't know your exact use case. Please keep in mind that we most

eMMC :-)

> work on NAND and eMMC, which require the whole block write.

Well, then the file should have been padded already before sending it
over USB, right? :-)

You shouldn't write req->length if you don't receive req->length as you
are, potentially, writing garbage to the storage medium :-)

> However, I will setup test environment (after changing the job it was
> gone), test your patch and then let you know.

cool

>  >> drivers/usb/gadget/f_dfu.c | 2 +- 
>  >> 1 file changed, 1 insertion(+), 1 deletion(-) 
>  >> 
>  >> diff --git a/drivers/usb/gadget/f_dfu.c b/drivers/usb/gadget/f_dfu.c 
>  >> index 8e7c981657..64cdfa7c98 100644 
>  >> --- a/drivers/usb/gadget/f_dfu.c 
>  >> +++ b/drivers/usb/gadget/f_dfu.c 
>  >> @@ -159,7 +159,7 @@ static void dnload_request_complete(struct usb_ep 
> *ep, struct usb_request *req) 
>  >> int ret; 
>  >> 
>  >> ret = dfu_write(dfu_get_entity(f_dfu->altsetting), req->buf, 
>  >> - req->length, f_dfu->blk_seq_num); 
>  >> + req->actual, f_dfu->blk_seq_num); 
>
>  DFU driver queues a request to USB controller. Per the gadget API 
>  req->length contains maximum amount of data to be 
>  transmitted. req->actual is written by USB controller with the actual 
>  amount of data that we transmitted. 
>
>  In the case of IN (TX), upon completion req->length and req->actual 
>  should always be equal (unless errors show up, etc) 
>
>  In the case of OUT (RX), upon completion req->actual MAY BE less than 
>  req->length and that's not an error. Say host sent us a short packet 
>  which causes early termination of transfer. 
>
>  With that in mind, let's consider the situation where we're receiving 
>  data from host using DFU. Let's assume that we have a 4096 byte buffer 
>  for transfers and we're receiving a binary that's 7679 bytes in size. 
>
>  Here's what we will do (pseudo-code): 
>
>  int remaining = 7679; 
>  char buf[4096]; 
>
>  while (remaining) { 
>  req->length = 4096; 
>  req->buf = buf; 
>  usb_ep_queue(req); 
>
>  /* wait for completion */ 
>
>  remaining -= req->actual; 
>
>  dfu_write(buf, req->length); /* this is the error */ 
>  } 
>
>  Can you see here that in the last packet we will write 4096 bytes when 
>  we should write only 3583? 
>
> In principle you are right. I need to check if this change will not
> introduce regressions.
>
> Can you share your use case?

Intel Edison running v2017.03-rc1 + patches (see [1]), flashing
u-boot.bin over DFU (see [2] for details). Without $subject, image has
to be aligned to 4096 bytes as below:

$ dd if=u-boot.bin of=u-boot-4k.bin bs=4k seek=1 && truncate -s %4096 
u-boot-4k.bin

With $subject, I don't need truncate. We still need the 4096 byte of
zeroes in the beginning of the image for other reasons (which I really
don't know why at this point).

[1] https://github.com/andy-shev/u-boot/tree/edison
[2] https://communities.intel.com/message/435516#435516

-- 
balbi


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 2/2] omapl138_lcdk: Set uboot raw mmc sector to 0x41

2017-02-13 Thread Axel Haslam
The uboot binary on the AIS file starts at offset 0x8000.
This would be sector 0x40 on a mmc card with 512 bytes per
sector: 0x8000/0x200 = 0x40.

But because we usually skip the first mmc sector to preserve
the partition table, the ais image is written starting
on sector 0x1, and the u-boot binary ends up at sector 0x41.

Set the address of the u-boot binary to 0x41 so that spl
can correctly jump to it.

Signed-off-by: Axel Haslam 
---
 configs/omapl138_lcdk_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/omapl138_lcdk_defconfig b/configs/omapl138_lcdk_defconfig
index d20af19..a249ebd 100644
--- a/configs/omapl138_lcdk_defconfig
+++ b/configs/omapl138_lcdk_defconfig
@@ -12,7 +12,7 @@ CONFIG_VERSION_VARIABLE=y
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_BOARD_EARLY_INIT_F=y
 CONFIG_SPL=y
-CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0xb5
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x41
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="U-Boot > "
 CONFIG_CMD_BOOTZ=y
-- 
2.9.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/2] kconfig: re-sync with Linux 4.10

2017-02-13 Thread Tom Rini
On Sat, Feb 11, 2017 at 12:39:54PM +0900, Masahiro Yamada wrote:

> Re-sync all files under the scripts/kconfig directory with
> Linux 4.10.
> 
> Some parts include U-Boot own modification.  I made sure to not
> revert the following commits:
> 
>  5b8031ccb4ed ("Add more SPDX-License-Identifier tags")
>  192bc6948b02 ("Fix GCC format-security errors and convert sprintfs.")
>  da58dec86616 ("Various Makefiles: Add SPDX-License-Identifier tags")
>  20c20826efab ("Kconfig: Enable usage of escape char '\' in string values")
> 
> Signed-off-by: Masahiro Yamada 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] i2c: sandbox: remove code snippet from Kconfig help

2017-02-13 Thread Tom Rini
On Sat, Feb 11, 2017 at 12:39:55PM +0900, Masahiro Yamada wrote:

> With the Kconfig re-sync with Linux 4.10, characters such as
> '}', ';' in Kconfig help message cause warnings:
> 
> $ make defconfig
> *** Default configuration is based on 'sandbox_defconfig'
> drivers/i2c/Kconfig:132:warning: ignoring unsupported character '}'
> drivers/i2c/Kconfig:132:warning: ignoring unsupported character ';'
> 
> Drop the Device Tree fragment from the help.
> 
> Signed-off-by: Masahiro Yamada 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/6] arm: am57xx: cl-som-am57x: fix XHCI registers base address

2017-02-13 Thread Lokesh Vutla


On Monday 13 February 2017 05:42 PM, Uri Mashiach wrote:
> 
> 
> On 02/13/2017 01:46 PM, Lokesh Vutla wrote:
>>
>>
>> On Sunday 12 February 2017 09:17 PM, Tom Rini wrote:
>>> On Sun, Feb 12, 2017 at 10:55:27AM +0200, Uri Mashiach wrote:
 Hi Tom,

 On 02/09/2017 10:29 PM, Tom Rini wrote:
> On Thu, Feb 09, 2017 at 09:00:26AM +0200, Uri Mashiach wrote:
>
>> The following XHCI registers base address are set to OMAP5 values:
>> OMAP_XHCI_BASE, OMAP_OCP1_SCP_BASE, OMAP_OTG_WRAPPER_BASE
>>
>> Captured crash for "usb start" command:
>> --cut--
>>
>> => usb start
>> starting USB...
>> USB0:   data abort
>> pc : []  lr : []
>> reloc pc : [<8081cd22>]lr : [<8081cb63>]
>> sp : fdf42d08  ip : fff9e040 fp : fdf42d50
>> r10: fff8a998  r9 : fdf42ef0 r8 : 
>> r7 : fdf42d28  r6 : fdf42d2c r5 : fffa5c00  r4 : 
>> r3 : 4a02  r2 :  r1 : fdf42e78  r0 : fffa5c00
>> Flags: nzCv  IRQs off  FIQs off  Mode SVC_32
>> Resetting CPU ...
>>
>> resetting ...
>> --cut--
>>
>>
>> Fix by adding the CL-SOM-AM57x target to the XHCI registers base
>> address
>> ifdef'ery.
>> A better fix should be based on a SOC family defines (currently
>> missing).
>
> Can you please go add the Kconfig symbols that would be the better
> solution please?  Thanks!

 The SOC family symbol CONFIG_AM57XX was removed by the commit
 3891a54: "ARM: DRA7x/AM57xx: Get rid of CONFIG_AM57XX".
 Maybe the symbol should be reintroduced just for the XHCI registers
 section?
>>>
>>> Yes, sounds like we do have a case where DRA7xx is not the same as
>>> AM57xx then?
>>>
>>
>> No that's not right. It is just DRA74x_EVM and AM57XX evm is using
>> different instances of XHCI. Ideally this base address should be coming
>> from DT. I don't think it is a good idea to introduce CONFIG_AM57XX.
>>
>> Thanks and regards,
>> Lokesh
>>
> It seems that the address of register is SOC dependent.
> In the current method all the target boards that use the relevant SOC
> should be included in the ifdef'ery - redundant maintenance.

Please have a look at the TRMs. DRA7xx[1], AM57xx[2]. Both has the above
two instances of XHCI. There is no difference.

[1] http://www.ti.com/lit/ug/sprui30b/sprui30b.pdf
[2] http://www.ti.com/lit/ug/spruhz6h/spruhz6h.pdf

Thanks and regards,
Lokesh

> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 0/3] ARM: AM43xx: Enable SPL_DM

2017-02-13 Thread Lokesh Vutla
Enable SPL_DM on all AM4xx based boards.

This series depends on:
- DRA7 SPL_DM series[1]
- http://patchwork.ozlabs.org/patch/727106/

[1] https://www.mail-archive.com/u-boot@lists.denx.de/msg238751.html

Lokesh Vutla (3):
  ARM: dts: am43xx: Add u-boot specific dtsi
  config: am43xx_usbhost_boot: sync with am43xx_evm
  configs: am43xx_evm: Enable SPL_DM

 arch/arm/dts/am437x-gp-evm-u-boot.dtsi| 38 +++
 configs/am43xx_evm_defconfig  |  7 +-
 configs/am43xx_evm_usbhost_boot_defconfig | 12 +-
 configs/am43xx_hs_evm_defconfig   |  7 +-
 include/configs/am43xx_evm.h  |  4 
 5 files changed, 61 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/dts/am437x-gp-evm-u-boot.dtsi

-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 1/3] ARM: dts: am43xx: Add u-boot specific dtsi

2017-02-13 Thread Lokesh Vutla
Add u-boot specific dtsi for am43xx-gp-evm so
that it will be used for SPL.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/dts/am437x-gp-evm-u-boot.dtsi | 38 ++
 1 file changed, 38 insertions(+)
 create mode 100644 arch/arm/dts/am437x-gp-evm-u-boot.dtsi

diff --git a/arch/arm/dts/am437x-gp-evm-u-boot.dtsi 
b/arch/arm/dts/am437x-gp-evm-u-boot.dtsi
new file mode 100644
index 00..885a9a92db
--- /dev/null
+++ b/arch/arm/dts/am437x-gp-evm-u-boot.dtsi
@@ -0,0 +1,38 @@
+/*
+ * Copyright (C) 2017 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ * Based on "dra7.dtsi"
+ */
+
+/{
+   ocp {
+   u-boot,dm-pre-reloc;
+   };
+};
+
+&uart0 {
+   u-boot,dm-pre-reloc;
+};
+
+&mmc1 {
+   u-boot,dm-pre-reloc;
+};
+
+&mac {
+   u-boot,dm-pre-reloc;
+};
+
+&davinci_mdio {
+   u-boot,dm-pre-reloc;
+};
+
+&cpsw_emac0 {
+   u-boot,dm-pre-reloc;
+};
+
+&phy_sel {
+   u-boot,dm-pre-reloc;
+};
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 2/3] config: am43xx_usbhost_boot: sync with am43xx_evm

2017-02-13 Thread Lokesh Vutla
am43xx_evm defconfig has been modified without making changes
in am43xx_usbhost_boot defconfig. Synce here.

Signed-off-by: Lokesh Vutla 
---
- The only reason to have usbhost defconfig is that the
  load address is different from that of other bootmodes.

 configs/am43xx_evm_usbhost_boot_defconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/configs/am43xx_evm_usbhost_boot_defconfig 
b/configs/am43xx_evm_usbhost_boot_defconfig
index 5775ab16dd..e22bc7fbdb 100644
--- a/configs/am43xx_evm_usbhost_boot_defconfig
+++ b/configs/am43xx_evm_usbhost_boot_defconfig
@@ -48,13 +48,18 @@ CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
 CONFIG_DFU_SF=y
 CONFIG_DM_GPIO=y
+CONFIG_DM_I2C=y
 CONFIG_DM_MMC=y
 # CONFIG_DM_MMC_OPS is not set
 CONFIG_MMC_OMAP_HS=y
+CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_DM_ETH=y
 CONFIG_DM_SERIAL=y
 CONFIG_SYS_NS16550=y
+CONFIG_DM_SPI=y
 CONFIG_TI_QSPI=y
 CONFIG_TIMER=y
 CONFIG_OMAP_TIMER=y
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 3/3] configs: am43xx_evm: Enable SPL_DM

2017-02-13 Thread Lokesh Vutla
Enable SPL_DM on all AM43xx based platforms

Signed-off-by: Lokesh Vutla 
---
 configs/am43xx_evm_defconfig  | 7 ++-
 configs/am43xx_evm_usbhost_boot_defconfig | 7 ++-
 configs/am43xx_hs_evm_defconfig   | 7 ++-
 include/configs/am43xx_evm.h  | 4 
 4 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/configs/am43xx_evm_defconfig b/configs/am43xx_evm_defconfig
index 6fb2053f33..4b0f5c6106 100644
--- a/configs/am43xx_evm_defconfig
+++ b/configs/am43xx_evm_defconfig
@@ -10,7 +10,9 @@ CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=1,NAND"
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
 CONFIG_SPL=y
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_STACK_R=y
+CONFIG_SPL_SEPARATE_BSS=y
 CONFIG_SPL_MTD_SUPPORT=y
 CONFIG_SPL_OS_BOOT=y
 CONFIG_HUSH_PARSER=y
@@ -38,8 +40,12 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_ISO_PARTITION=y
 CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
 CONFIG_OF_LIST="am437x-gp-evm am437x-sk-evm am43x-epos-evm am437x-idk-evm"
 CONFIG_DM=y
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_SPL_OF_TRANSLATE=y
 # CONFIG_BLK is not set
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
@@ -73,4 +79,3 @@ CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
 CONFIG_G_DNL_VENDOR_NUM=0x0403
 CONFIG_G_DNL_PRODUCT_NUM=0xbd00
-CONFIG_SPL_OF_LIBFDT=y
diff --git a/configs/am43xx_evm_usbhost_boot_defconfig 
b/configs/am43xx_evm_usbhost_boot_defconfig
index e22bc7fbdb..6e408d101f 100644
--- a/configs/am43xx_evm_usbhost_boot_defconfig
+++ b/configs/am43xx_evm_usbhost_boot_defconfig
@@ -11,7 +11,9 @@ CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND"
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
 CONFIG_SPL=y
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_STACK_R=y
+CONFIG_SPL_SEPARATE_BSS=y
 CONFIG_SPL_MTD_SUPPORT=y
 CONFIG_SPL_OS_BOOT=y
 CONFIG_SPL_USB_HOST_SUPPORT=y
@@ -41,8 +43,12 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_ISO_PARTITION=y
 CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
 CONFIG_OF_LIST="am437x-gp-evm am437x-sk-evm am43x-epos-evm am437x-idk-evm"
 CONFIG_DM=y
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_SPL_OF_TRANSLATE=y
 # CONFIG_BLK is not set
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
@@ -76,4 +82,3 @@ CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
 CONFIG_G_DNL_VENDOR_NUM=0x0403
 CONFIG_G_DNL_PRODUCT_NUM=0xbd00
-CONFIG_SPL_OF_LIBFDT=y
diff --git a/configs/am43xx_hs_evm_defconfig b/configs/am43xx_hs_evm_defconfig
index 6bcbfd77ed..016f16f630 100644
--- a/configs/am43xx_hs_evm_defconfig
+++ b/configs/am43xx_hs_evm_defconfig
@@ -14,7 +14,9 @@ CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=1,NAND"
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
 CONFIG_SPL=y
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_STACK_R=y
+CONFIG_SPL_SEPARATE_BSS=y
 CONFIG_SPL_ETH_SUPPORT=y
 CONFIG_SPL_MTD_SUPPORT=y
 CONFIG_SPL_NET_SUPPORT=y
@@ -48,8 +50,12 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_ISO_PARTITION=y
 CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
 CONFIG_OF_LIST="am437x-gp-evm am437x-sk-evm am43x-epos-evm am437x-idk-evm"
 CONFIG_DM=y
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_SPL_OF_TRANSLATE=y
 # CONFIG_BLK is not set
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
@@ -82,4 +88,3 @@ CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
 CONFIG_G_DNL_VENDOR_NUM=0x0403
 CONFIG_G_DNL_PRODUCT_NUM=0xbd00
-CONFIG_SPL_OF_LIBFDT=y
diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h
index 1d622eff2f..1997145863 100644
--- a/include/configs/am43xx_evm.h
+++ b/include/configs/am43xx_evm.h
@@ -20,7 +20,6 @@
 #define CONFIG_SYS_NS16550_CLK 4800
 #if defined(CONFIG_SPL_BUILD) || !defined(CONFIG_DM_SERIAL)
 #define CONFIG_SYS_NS16550_SERIAL
-#define CONFIG_SYS_NS16550_REG_SIZE(-4)
 #endif
 
 /* I2C Configuration */
@@ -111,9 +110,6 @@
  * DM support in SPL
  */
 #ifdef CONFIG_SPL_BUILD
-#undef CONFIG_DM_MMC
-#undef CONFIG_DM_SPI
-#undef CONFIG_DM_SPI_FLASH
 #undef CONFIG_TIMER
 #endif
 
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] Fwd: how to trigger DM rescan ?

2017-02-13 Thread Hannes Schmelzer

Hi Simon,

forwarding this directly to you since nobody did response on the 
mailinglist.

Maybe you have some suggestion to me.

many thanks,
Hannes


 Forwarded Message 
Subject:how to trigger DM rescan ?
Date:   Wed, 8 Feb 2017 08:05:31 +0100
From:   Hannes Schmelzer 
To: u-boot@lists.denx.de 



Hello,

i've following trouble on a new custom zynq board:

There is a axi4pcie root-complex implemented within the FPGA, i added
this to my devicetree:

pci_express: axi-pcie@9000 {
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
status = "disabled";
compatible = "xlnx,axi-pcie-host-1.00.a";
reg = < 0x9000 0x100 >;
device_type = "pci";
interrupts = < 0 116 4 >;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &pcie_intc 1>,
<0 0 0 2 &pcie_intc 2>,
<0 0 0 3 &pcie_intc 3>,
<0 0 0 4 &pcie_intc 4>;
ranges = < 0x0200 0 0x8000 0x8000 0 0x1000 >;

pcie_intc: interrupt-controller {
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <1>;
};
};

As you can see the node is "disabled". For me this makes sense since
during very first come up of u-boot the FPGA is not configured yet and
the registers of the root-complex aren't accessible.
Later on, during "board_init(...)" i bring up the FPGA (load bitstream
from spi flash into FPGA) and set the fdt-node property status to "okay".

Trouble is that dm-scan, probe, ... is already done at this point and
the root-complex is left ofter uninitialized and is not in the dm-tree
at all (since it was disabled through first scan).

=> dm tree
 Class   Probed   Name

 root[ + ]root_driver
 simple_bus  [ + ]`-- amba
 gpio[ + ]|-- gpio@e000a000
 i2c [   ]|-- i2c@e0004000
 i2c [ + ]|-- i2c@e0005000
 i2c_generic [ + ]|   `-- generic_60
 serial  [ + ]|-- serial@e000
 serial  [   ]|-- serial@e0001000
 spi [ + ]|-- spi@e000d000
 spi_flash   [ + ]|   `-- spiflash@0
 eth [   ]|-- ethernet@e000b000
 mmc [ + ]|-- sdhci@e010
 blk [   ]|   `-- sd...@e010.blk
 mmc [ + ]|-- sdhci@e0101000
 blk [   ]|   `-- sd...@e0101000.blk
 simple_bus  [   ]|-- slcr@f800
 usb [   ]`-- usb@e0003000
=>

Is there a possibility to trigger a dm-scan after bringing up such new
devices ?
Or is it the wrong way having the node "disabled" first and enabled it
later ? are there better ways to prevent accessing not yet ready devices
from access ?

many thanks for your help and
best regards,
Hannes



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] ZYNQ direct MAC connection

2017-02-13 Thread Hannes Schmelzer

Hello,

did anybody setup successfully setup a direct MAC connection using RGMII 
with a zynq ?

For example to a switch.

The zynq_gem driver wants to probe for phy by itself.
I already made a connection with very bad hacks in various files.

In linux such things are working with "fixed-link". Also the i.mx6 FEC 
driver (not using DM) can operate in direct-connection mode.


many thanks and best regards,
Hannes

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] omapl138_lcdk: Set uboot raw mmc sector to 0x41

2017-02-13 Thread Tom Rini
On Mon, Feb 13, 2017 at 11:44:57AM +0100, Axel Haslam wrote:
> The uboot binary on the AIS file starts at offset 0x8000.
> This would be sector 0x40 on a mmc card with 512 bytes per
> sector: 0x8000/0x200 = 0x40.
> 
> But because we usually skip the first mmc sector to preserve
> the partition table, the ais image is written starting
> on sector 0x1, and the u-boot binary ends up at sector 0x41.
> 
> Set the address of the u-boot binary to 0x41 so that spl
> can correctly jump to it.
> 
> Signed-off-by: Axel Haslam 
> ---
>  configs/omapl138_lcdk_defconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configs/omapl138_lcdk_defconfig b/configs/omapl138_lcdk_defconfig
> index d20af19..a249ebd 100644
> --- a/configs/omapl138_lcdk_defconfig
> +++ b/configs/omapl138_lcdk_defconfig
> @@ -12,7 +12,7 @@ CONFIG_VERSION_VARIABLE=y
>  # CONFIG_DISPLAY_BOARDINFO is not set
>  CONFIG_BOARD_EARLY_INIT_F=y
>  CONFIG_SPL=y
> -CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0xb5
> +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x41

Since we're changing a default here, and one that will lead to
non-booting boards if you don't notice, where did the old value come
from, and is it actually in use anywhere?  Thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/6] arm: am57xx: reintroduce the CONFIG_AM57XX symbol

2017-02-13 Thread Tom Rini
On Mon, Feb 13, 2017 at 01:34:52PM +0200, Uri Mashiach wrote:

> The SOC family symbol CONFIG_AM57XX was removed by the commit
> 3891a54: "ARM: DRA7x/AM57xx: Get rid of CONFIG_AM57XX".
> 
> The symbol is needed by the XHCI OMAP USB driver.
> Without the symbol all the AM57x targets symbols should be ored in the
> ifdef'ery.
> 
> Signed-off-by: Uri Mashiach 

We need to introduce it into Kconfig files now, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 00/10] Add Marvell ESPRESSOBin community board support

2017-02-13 Thread kostap
From: Konstantin Porotchkin 

This patch set adds support for Marvell ESPRESSOBin community board.
The Marvell ESPRESSOBin is a tiny board made by Globalscale
and available on KickStarter site.
It has (current board version 3.1.1):
- Dual core Cortex-A53 @1.2GHz CPU (Marvell Armada-3720)
- 512MB/1GB/2GB DDR3 RAM (depends on selected configuration)
- Mini-PCIe 2.0 slot
- Single SATA-3 port with Molex SATA power connector
- USB 2.0 port 
- USB 3.0 port
- Gigabit Ethernet switch with 3 ports
- Micro-SD socket 
- Two 46-pin GPIO connectors.
- SPI boot flash
- Boot source selection jumpers (SPI/SATA/UART/Auto)
- Micro JTAG connector (10 pin)
- Micro USB serial port 

Konstantin Porotchkin (10):
  arm64: a37xx: Enable Marvell ETH PHY support
  arm64: a37xx: Enable bubt command support on A3720-DB
  arm64: a37xx: dts: Add pin control nodes to DT
  arm64: a37xx: Handle pin controls in early board init
  mvebu: neta: Add support for board init function
  mvebu: neta: a37xx: Add fixed link support to neta driver
  mvebu: a37xx: Add init for ESPRESSBin Topaz switch
  arm64: dts: Add device tree for ESPRESSOBin board
  arm64: mvebu: Add default config for ESPRESSOBin board
  arm64: a3720: Disable DB configurations on ESPRESSOBin board

 arch/arm/dts/Makefile   |   1 +
 arch/arm/dts/armada-3720-espressobin.dts| 135 
 arch/arm/dts/armada-37xx.dtsi   |  14 +++
 board/Marvell/mvebu_db-88f3720/board.c  |  83 -
 configs/mvebu_db-88f3720_defconfig  |   3 +
 configs/mvebu_espressobin-88f3720_defconfig |  67 ++
 drivers/net/mvneta.c| 125 --
 include/configs/mvebu_db-88f3720.h  |   1 +
 8 files changed, 400 insertions(+), 29 deletions(-)
 create mode 100644 arch/arm/dts/armada-3720-espressobin.dts
 create mode 100644 configs/mvebu_espressobin-88f3720_defconfig

-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 01/10] arm64: a37xx: Enable Marvell ETH PHY support

2017-02-13 Thread kostap
From: Konstantin Porotchkin 

Enable support for Marvell Ethernet PHYs on A37xx platforms

Signed-off-by: Konstantin Porotchkin 
Cc: Stefan Roese 
Cc: Igal Liberman 
---
 include/configs/mvebu_db-88f3720.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/mvebu_db-88f3720.h 
b/include/configs/mvebu_db-88f3720.h
index 753ed1e..fb30073 100644
--- a/include/configs/mvebu_db-88f3720.h
+++ b/include/configs/mvebu_db-88f3720.h
@@ -93,6 +93,7 @@
 #define CONFIG_PHY_GIGE/* GbE speed/duplex detect */
 #define CONFIG_ARP_TIMEOUT 200
 #define CONFIG_NET_RETRY_COUNT 50
+#define CONFIG_PHY_MARVELL
 
 /* USB 2.0 */
 #define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 02/10] arm64: a37xx: Enable bubt command support on A3720-DB

2017-02-13 Thread kostap
From: Konstantin Porotchkin 

Enable mvebu bubt command support on A3720 DB

Signed-off-by: Konstantin Porotchkin 
Cc: Stefan Roese 
Cc: Igal Liberman 
---
 configs/mvebu_db-88f3720_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/mvebu_db-88f3720_defconfig 
b/configs/mvebu_db-88f3720_defconfig
index 80f2599..7478b74 100644
--- a/configs/mvebu_db-88f3720_defconfig
+++ b/configs/mvebu_db-88f3720_defconfig
@@ -33,6 +33,9 @@ CONFIG_CMD_FS_GENERIC=y
 CONFIG_MAC_PARTITION=y
 CONFIG_ISO_PARTITION=y
 CONFIG_EFI_PARTITION=y
+CONFIG_CMD_MVEBU_BUBT=y
+CONFIG_SHA1=y
+CONFIG_SHA256=y
 CONFIG_BLOCK_CACHE=y
 CONFIG_DM_I2C=y
 CONFIG_DM_I2C_COMPAT=y
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 03/10] arm64: a37xx: dts: Add pin control nodes to DT

2017-02-13 Thread kostap
From: Konstantin Porotchkin 

Add pin control nodes for North and South bridges to
Armada-37xx DT

Signed-off-by: Konstantin Porotchkin 
Cc: Stefan Roese 
Cc: Igal Liberman 
---
 arch/arm/dts/armada-37xx.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/dts/armada-37xx.dtsi b/arch/arm/dts/armada-37xx.dtsi
index 062f2a6..5bea63b 100644
--- a/arch/arm/dts/armada-37xx.dtsi
+++ b/arch/arm/dts/armada-37xx.dtsi
@@ -193,6 +193,20 @@
status = "disabled";
};
 
+   pinctl0: pinctl@13830 { /* north bridge */
+   compatible = "marvell,armada-3700-pinctl";
+   bank-name = "armada-3700-nb";
+   reg = <0x13830 0x4>;
+   pin-count = <36>;
+   };
+
+   pinctl1: pinctl@18830 { /* south bridge */
+   compatible = "marvell,armada-3700-pinctl";
+   bank-name = "armada-3700-sb";
+   reg = <0x18830 0x4>;
+   pin-count = <30>;
+   };
+
comphy: comphy@18300 {
compatible = "marvell,mvebu-comphy", 
"marvell,comphy-armada-3700";
reg = <0x18300 0x28>,
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 06/10] mvebu: neta: a37xx: Add fixed link support to neta driver

2017-02-13 Thread kostap
From: Konstantin Porotchkin 

Add support for fixed link to NETA driver.
This feature requred for proper support of SFP modules
and onboard connected devices like Ethernet switches

Signed-off-by: Konstantin Porotchkin 
Signed-off-by: Terry Zhou 
Cc: Stefan Roese 
Cc: Igal Liberman 
---
 drivers/net/mvneta.c | 109 ++-
 1 file changed, 82 insertions(+), 27 deletions(-)

diff --git a/drivers/net/mvneta.c b/drivers/net/mvneta.c
index a1e2136..8881cc7 100644
--- a/drivers/net/mvneta.c
+++ b/drivers/net/mvneta.c
@@ -191,11 +191,16 @@ DECLARE_GLOBAL_DATA_PTR;
 #define MVNETA_GMAC_AUTONEG_CONFIG   0x2c0c
 #define  MVNETA_GMAC_FORCE_LINK_DOWN BIT(0)
 #define  MVNETA_GMAC_FORCE_LINK_PASS BIT(1)
+#define  MVNETA_GMAC_FORCE_LINK_UP   (BIT(0) | BIT(1))
+#define  MVNETA_GMAC_IB_BYPASS_AN_EN BIT(3)
 #define  MVNETA_GMAC_CONFIG_MII_SPEEDBIT(5)
 #define  MVNETA_GMAC_CONFIG_GMII_SPEED   BIT(6)
 #define  MVNETA_GMAC_AN_SPEED_EN BIT(7)
+#define  MVNETA_GMAC_SET_FC_EN   BIT(8)
+#define  MVNETA_GMAC_ADVERT_FC_ENBIT(9)
 #define  MVNETA_GMAC_CONFIG_FULL_DUPLEX  BIT(12)
 #define  MVNETA_GMAC_AN_DUPLEX_ENBIT(13)
+#define  MVNETA_GMAC_SAMPLE_TX_CFG_ENBIT(15)
 #define MVNETA_MIB_COUNTERS_BASE 0x3080
 #define  MVNETA_MIB_LATE_COLLISION   0x7c
 #define MVNETA_DA_FILT_SPEC_MCAST0x3400
@@ -566,6 +571,13 @@ static void mvneta_rxq_buf_size_set(struct mvneta_port *pp,
mvreg_write(pp, MVNETA_RXQ_SIZE_REG(rxq->id), val);
 }
 
+static int mvneta_port_is_fixed_link(struct mvneta_port *pp)
+{
+   /* phy_addr is set to invalid value for fixed link */
+   return pp->phyaddr > PHY_MAX_ADDR;
+}
+
+
 /* Start the Ethernet port RX and TX activity */
 static void mvneta_port_up(struct mvneta_port *pp)
 {
@@ -816,10 +828,12 @@ static void mvneta_defaults_set(struct mvneta_port *pp)
/* Assign port SDMA configuration */
mvreg_write(pp, MVNETA_SDMA_CONFIG, val);
 
-   /* Enable PHY polling in hardware for U-Boot */
-   val = mvreg_read(pp, MVNETA_UNIT_CONTROL);
-   val |= MVNETA_PHY_POLLING_ENABLE;
-   mvreg_write(pp, MVNETA_UNIT_CONTROL, val);
+   /* Enable PHY polling in hardware if not in fixed-link mode */
+   if (!mvneta_port_is_fixed_link(pp)) {
+   val = mvreg_read(pp, MVNETA_UNIT_CONTROL);
+   val |= MVNETA_PHY_POLLING_ENABLE;
+   mvreg_write(pp, MVNETA_UNIT_CONTROL, val);
+   }
 
mvneta_set_ucast_table(pp, -1);
mvneta_set_special_mcast_table(pp, -1);
@@ -1137,6 +1151,11 @@ static void mvneta_adjust_link(struct udevice *dev)
struct phy_device *phydev = pp->phydev;
int status_change = 0;
 
+   if (mvneta_port_is_fixed_link(pp)) {
+   debug("Using fixed link, skip link adjust\n");
+   return;
+   }
+
if (phydev->link) {
if ((pp->speed != phydev->speed) ||
(pp->duplex != phydev->duplex)) {
@@ -1507,28 +1526,54 @@ static int mvneta_start(struct udevice *dev)
mvneta_port_power_up(pp, pp->phy_interface);
 
if (!pp->init || pp->link == 0) {
-   /* Set phy address of the port */
-   mvreg_write(pp, MVNETA_PHY_ADDR, pp->phyaddr);
-   phydev = phy_connect(pp->bus, pp->phyaddr, dev,
-pp->phy_interface);
-
-   pp->phydev = phydev;
-   phy_config(phydev);
-   phy_startup(phydev);
-   if (!phydev->link) {
-   printf("%s: No link.\n", phydev->dev->name);
-   return -1;
-   }
+   if (mvneta_port_is_fixed_link(pp)) {
+   u32 val;
 
-   /* Full init on first call */
-   mvneta_init(dev);
-   pp->init = 1;
-   } else {
-   /* Upon all following calls, this is enough */
-   mvneta_port_up(pp);
-   mvneta_port_enable(pp);
+   pp->init = 1;
+   pp->link = 1;
+   mvneta_init(dev);
+
+   val = MVNETA_GMAC_FORCE_LINK_UP |
+ MVNETA_GMAC_IB_BYPASS_AN_EN |
+ MVNETA_GMAC_SET_FC_EN |
+ MVNETA_GMAC_ADVERT_FC_EN |
+ MVNETA_GMAC_SAMPLE_TX_CFG_EN;
+
+   if (pp->duplex)
+   val |= MVNETA_GMAC_CONFIG_FULL_DUPLEX;
+
+   if (pp->speed == SPEED_1000)
+   val |= MVNETA_GMAC_CONFIG_GMII_SPEED;
+   else if (pp->speed == SPEED_100)
+   val |= MVNETA_GMAC_CONFIG_MII_SPEED;
+
+   mvreg_write(pp, MVNET

[U-Boot] [PATCH 07/10] mvebu: a37xx: Add init for ESPRESSBin Topaz switch

2017-02-13 Thread kostap
From: Konstantin Porotchkin 

Implement the board-specific network init function for
ESPRESSOBin community board, setting the on-board Topaz
switch port to forward mode and allow network connection
through any of the available Etherenet ports.

Signed-off-by: Konstantin Porotchkin 
Cc: Stefan Roese 
Cc: Igal Liberman 
---
 board/Marvell/mvebu_db-88f3720/board.c | 49 ++
 1 file changed, 49 insertions(+)

diff --git a/board/Marvell/mvebu_db-88f3720/board.c 
b/board/Marvell/mvebu_db-88f3720/board.c
index 3337f3f..45098ce 100644
--- a/board/Marvell/mvebu_db-88f3720/board.c
+++ b/board/Marvell/mvebu_db-88f3720/board.c
@@ -6,6 +6,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -156,3 +157,51 @@ int board_xhci_enable(void)
 
return 0;
 }
+
+static int mii_multi_chip_mode_write(struct mii_dev *bus, int dev_smi_addr,
+int smi_addr, int reg, u16 value)
+{
+   u16 data = 0;
+
+   if (bus->write(bus, dev_smi_addr, 0, 1, value) != 0) {
+   printf("Error writing to the PHY addr=%02x reg=%02x\n",
+  smi_addr, reg);
+   return -EFAULT;
+   }
+
+   data = (1 << 15) | (1 << 12) | (1 << 10) | (smi_addr << 5) | reg;
+   if (bus->write(bus, dev_smi_addr, 0, 0, data) != 0) {
+   printf("Error writing to the PHY addr=%02x reg=%02x\n",
+  smi_addr, reg);
+   return -EFAULT;
+   }
+
+   return 0;
+}
+
+
+int board_network_enable(struct mii_dev *bus)
+{
+   if (!of_machine_is_compatible("marvell,armada-3720-espressobin"))
+   return 0;
+
+   /*
+* FIXME: remove this code once Topaz driver gets available
+* A3720 Community Board Only
+* Configure Topaz switch (88E6341)
+* Set port 0,1,2,3 to forwarding Mode
+*/
+   mii_multi_chip_mode_write(bus, 1, 16, 4, 0x7f);
+   mii_multi_chip_mode_write(bus, 1, 17, 4, 0x7f);
+   mii_multi_chip_mode_write(bus, 1, 18, 4, 0x7f);
+   mii_multi_chip_mode_write(bus, 1, 19, 4, 0x7f);
+   /* RGMII Delay on Port 0*/
+   mii_multi_chip_mode_write(bus, 1, 16, 1, 0xe002);
+   /* Power up PHY 1, 2, 3 */
+   mii_multi_chip_mode_write(bus, 1, 28, 25, 0x1140);
+   mii_multi_chip_mode_write(bus, 1, 28, 24, 0x9620);
+   mii_multi_chip_mode_write(bus, 1, 28, 24, 0x9640);
+   mii_multi_chip_mode_write(bus, 1, 28, 24, 0x9660);
+
+   return 0;
+}
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 04/10] arm64: a37xx: Handle pin controls in early board init

2017-02-13 Thread kostap
From: Konstantin Porotchkin 

Fix the default pin control values in a board-specific
function on early board init stage.
This fix allows the NETA driver to work in RGMII
mode until the full-featured pin control driver gets
introduced.

Signed-off-by: Konstantin Porotchkin 
Cc: Stefan Roese 
Cc: Igal Liberman 
---
 board/Marvell/mvebu_db-88f3720/board.c | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/board/Marvell/mvebu_db-88f3720/board.c 
b/board/Marvell/mvebu_db-88f3720/board.c
index edf88c7..3337f3f 100644
--- a/board/Marvell/mvebu_db-88f3720/board.c
+++ b/board/Marvell/mvebu_db-88f3720/board.c
@@ -19,9 +19,33 @@ DECLARE_GLOBAL_DATA_PTR;
 #define I2C_IO_REG_0_SATA_OFF  2
 #define I2C_IO_REG_0_USB_H_OFF 1
 
+#define PINCTRL_NB_REG_VALUE   0x000173fa
+#define PINCTRL_SB_REG_VALUE   0x7a23
+
 int board_early_init_f(void)
 {
-   /* Nothing to do (yet), perhaps later some pin-muxing etc */
+   const void *blob = gd->fdt_blob;
+   const char *bank_name;
+   const char *compat = "marvell,armada-3700-pinctl";
+   int off, len;
+   void __iomem *addr;
+
+   /* FIXME
+* Temporary WA for setting correct pin control values
+* until the real pin control driver is awailable.
+*/
+   off = fdt_node_offset_by_compatible(blob, -1, compat);
+   while (off != -FDT_ERR_NOTFOUND) {
+   bank_name = fdt_getprop(blob, off, "bank-name", &len);
+   addr = (void __iomem *)fdtdec_get_addr_size_auto_noparent(
+   blob, off, "reg", 0, NULL, true);
+   if (!strncmp(bank_name, "armada-3700-nb", len))
+   writel(PINCTRL_NB_REG_VALUE, addr);
+   else if (!strncmp(bank_name, "armada-3700-sb", len))
+   writel(PINCTRL_SB_REG_VALUE, addr);
+
+   off = fdt_node_offset_by_compatible(blob, off, compat);
+   }
 
return 0;
 }
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 08/10] arm64: dts: Add device tree for ESPRESSOBin board

2017-02-13 Thread kostap
From: Konstantin Porotchkin 

Initial DTS file for Marvell ESPRESSOBin comunity board
based on Armada-3720 SoC.
The Marvell ESPRESSOBin is a tiny board made by Globalscale
and available on KickStarter site. It has dual core Armv8
Marvell SoC (Armada-3720) with 512MB/1GB/2GB DDR3 RAM,
mini-PCIe 2.0 slot, single SATA-3 port, USB 2.0 and USB 3.0
interfaces, Gigabit Ethernet switch with 3 ports, micro-SD
socket and two 46-pin GPIO connectors.

Signed-off-by: Konstantin Porotchkin 
Cc: Stefan Roese 
Cc: Igal Liberman 
---
 arch/arm/dts/Makefile|   1 +
 arch/arm/dts/armada-3720-espressobin.dts | 135 +++
 2 files changed, 136 insertions(+)
 create mode 100644 arch/arm/dts/armada-3720-espressobin.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index eb68c20..d85210c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -70,6 +70,7 @@ dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
 
 dtb-$(CONFIG_ARCH_MVEBU) +=\
armada-3720-db.dtb  \
+   armada-3720-espressobin.dtb \
armada-375-db.dtb   \
armada-388-clearfog.dtb \
armada-388-gp.dtb   \
diff --git a/arch/arm/dts/armada-3720-espressobin.dts 
b/arch/arm/dts/armada-3720-espressobin.dts
new file mode 100644
index 000..aa6587a
--- /dev/null
+++ b/arch/arm/dts/armada-3720-espressobin.dts
@@ -0,0 +1,135 @@
+/*
+ * Device Tree file for Marvell Armada 3720 community board
+ * (ESPRESSOBin)
+ * Copyright (C) 2016 Marvell
+ *
+ * Gregory CLEMENT 
+ * Konstantin Porotchkin 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) 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 , 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.
+ */
+
+/dts-v1/;
+
+#include "armada-372x.dtsi"
+
+/ {
+   model = "Marvell Armada 3720 Community Board ESPRESSOBin";
+   compatible = "marvell,armada-3720-espressobin", "marvell,armada3720", 
"marvell,armada3710";
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   aliases {
+   ethernet0 = ð0;
+   i2c0 = &i2c0;
+   spi0 = &spi0;
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x 0x 0x 0x2000>;
+   };
+};
+
+&comphy {
+   max-lanes = <3>;
+   phy0 {
+   phy-type = ;
+   phy-speed = ;
+   };
+
+   phy1 {
+   phy-type = ;
+   phy-speed = ;
+   };
+
+   phy2 {
+   phy-type = ;
+   phy-speed = ;
+   };
+};
+
+ð0 {
+   status = "okay";
+   phy-mode = "rgmii";
+   phy_addr = <0x1>;
+   fixed-link {
+   speed = <1000>;
+   full-duplex;
+   };
+};
+
+&i2c0 {
+   status = "okay";
+};
+
+/* CON3 */
+&sata {
+   status = "okay";
+};
+
+&spi0 {
+   status = "okay";
+
+   spi-flash@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "st,m25p128", "spi-flash";
+   reg = <0>; /* Chip select 0 */
+

[U-Boot] [PATCH 05/10] mvebu: neta: Add support for board init function

2017-02-13 Thread kostap
From: Konstantin Porotchkin 

Add ability to use board-specific initialization flow
to NETA driver (for instance Ethernet switch bring-up)

Signed-off-by: Konstantin Porotchkin 
Cc: Stefan Roese 
Cc: Igal Liberman 
---
 drivers/net/mvneta.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/net/mvneta.c b/drivers/net/mvneta.c
index 674075f..a1e2136 100644
--- a/drivers/net/mvneta.c
+++ b/drivers/net/mvneta.c
@@ -404,6 +404,15 @@ static struct buffer_location buffer_loc;
  */
 #define BD_SPACE   (1 << 20)
 
+/*
+ * Dummy implementation that can be overwritten by a board
+ * specific function
+ */
+__weak int board_network_enable(struct mii_dev *bus)
+{
+   return 0;
+}
+
 /* Utility/helper methods */
 
 /* Write helper method */
@@ -1615,6 +1624,7 @@ static int mvneta_probe(struct udevice *dev)
struct mii_dev *bus;
unsigned long addr;
void *bd_space;
+   int ret;
 
/*
 * Allocate buffer area for descs and rx_buffers. This is only
@@ -1664,7 +1674,11 @@ static int mvneta_probe(struct udevice *dev)
bus->priv = (void *)pp;
pp->bus = bus;
 
-   return mdio_register(bus);
+   ret = mdio_register(bus);
+   if (ret)
+   return ret;
+
+   return board_network_enable(bus);
 }
 
 static void mvneta_stop(struct udevice *dev)
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 09/10] arm64: mvebu: Add default config for ESPRESSOBin board

2017-02-13 Thread kostap
From: Konstantin Porotchkin 

Add initial default configuration for Marvell ESPRESSOBin
community board based on Aramda-3720 SoC

Signed-off-by: Konstantin Porotchkin 
Cc: Stefan Roese 
Cc: Igal Liberman 
---
 configs/mvebu_espressobin-88f3720_defconfig | 67 +
 1 file changed, 67 insertions(+)
 create mode 100644 configs/mvebu_espressobin-88f3720_defconfig

diff --git a/configs/mvebu_espressobin-88f3720_defconfig 
b/configs/mvebu_espressobin-88f3720_defconfig
new file mode 100644
index 000..544e233
--- /dev/null
+++ b/configs/mvebu_espressobin-88f3720_defconfig
@@ -0,0 +1,67 @@
+CONFIG_ARM=y
+CONFIG_ARCH_MVEBU=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_TARGET_MVEBU_DB_88F3720=y
+CONFIG_DEFAULT_DEVICE_TREE="armada-3720-espressobin"
+CONFIG_AHCI=y
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SYS_CONSOLE_INFO_QUIET=y
+# CONFIG_DISPLAY_CPUINFO is not set
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_ARCH_EARLY_INIT_R=y
+CONFIG_BOARD_EARLY_INIT_F=y
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_PART=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_FPGA is not set
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TFTPPUT=y
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_TIME=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_MAC_PARTITION=y
+CONFIG_ISO_PARTITION=y
+CONFIG_EFI_PARTITION=y
+CONFIG_CMD_MVEBU_BUBT=y
+CONFIG_SHA1=y
+CONFIG_SHA256=y
+CONFIG_BLOCK_CACHE=y
+CONFIG_DM_I2C=y
+CONFIG_DM_I2C_COMPAT=y
+CONFIG_MISC=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_SDMA=y
+CONFIG_MMC_SDHCI_XENON=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_PHYLIB=y
+CONFIG_MVEBU_COMPHY_SUPPORT=y
+# CONFIG_SPL_SERIAL_PRESENT is not set
+CONFIG_DEBUG_UART=y
+CONFIG_DEBUG_MVEBU_A3700_UART=y
+CONFIG_DEBUG_UART_BASE=0xd0012000
+CONFIG_DEBUG_UART_CLOCK=25804800
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_DEBUG_UART_ANNOUNCE=y
+CONFIG_MVEBU_A3700_UART=y
+CONFIG_MVEBU_A3700_SPI=y
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_STORAGE=y
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 10/10] arm64: a3720: Disable DB configurations on ESPRESSOBin board

2017-02-13 Thread kostap
From: Konstantin Porotchkin 

Bypass XHCI and AHCi board configuration flow on ESPRESSOBin
community board.
The community board does not have i2c expander and USB VBUS
is always on, so the scan for AHCi and USB devices can be
faster.

Signed-off-by: Konstantin Porotchkin 
Cc: Stefan Roese 
Cc: Igal Liberman 
---
 board/Marvell/mvebu_db-88f3720/board.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/board/Marvell/mvebu_db-88f3720/board.c 
b/board/Marvell/mvebu_db-88f3720/board.c
index 45098ce..029ca6d 100644
--- a/board/Marvell/mvebu_db-88f3720/board.c
+++ b/board/Marvell/mvebu_db-88f3720/board.c
@@ -66,6 +66,10 @@ int board_ahci_enable(void)
int ret;
u8 buf[8];
 
+   /* There is no IO expander on ESPRESSOBin boards */
+   if (of_machine_is_compatible("marvell,armada-3720-espressobin"))
+   return 0;
+
/* Configure IO exander PCA9555: 7bit address 0x22 */
ret = i2c_get_chip_for_busnum(0, I2C_IO_EXP_ADDR, 1, &dev);
if (ret) {
@@ -100,6 +104,10 @@ int board_xhci_enable(void)
int ret;
u8 buf[8];
 
+   /* There is no IO expander on ESPRESSOBin boards */
+   if (of_machine_is_compatible("marvell,armada-3720-espressobin"))
+   return 0;
+
/* Configure IO exander PCA9555: 7bit address 0x22 */
ret = i2c_get_chip_for_busnum(0, I2C_IO_EXP_ADDR, 1, &dev);
if (ret) {
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v1] usb: gadget: f_dfu: write req->actual bytes

2017-02-13 Thread Lukasz Majewski
Hi Felipe,

> 
> Hi Lukasz,
> 
> Lukasz Majewski  writes:
> > Hi Felipe,
> >
> > Thanks for the patch.
> > Please see my comments below.
> >
> > On 13 Feb 2017 11:42 am, Felipe Balbi
> >  wrote:
> >
> >  Hi, 
> >
> >  Marek Vasut  writes: 
> >  > On 02/10/2017 05:32 PM, Andy Shevchenko wrote: 
> >  >> From: Felipe Balbi  
> >  >> 
> >  >> If last packet is short, we shouldn't write req->length bytes
> >  >> to non-volatile media, we should write only what's available to
> >  >> us, which is held in req->actual. 
> >  >> 
> >  >> Signed-off-by: Felipe Balbi  
> >  >> Signed-off-by: Andy Shevchenko
> >  >>  
> >  > 
> >  > Since I have no clue about DFU internals, I will wait for
> >  > Lukasz's Ack. 
> >
> >  you don't need to have any clues about DFU internals to realise
> > that this fixes an actual bug, see below: 
> >
> > I don't know your exact use case. Please keep in mind that we most
> 
> eMMC :-)

Ok.

> 
> > work on NAND and eMMC, which require the whole block write.
> 
> Well, then the file should have been padded already before sending it
> over USB, right? :-)
> 
> You shouldn't write req->length if you don't receive req->length as
> you are, potentially, writing garbage to the storage medium :-)

Yes. Correct

> 
> > However, I will setup test environment (after changing the job it
> > was gone), test your patch and then let you know.
> 
> cool
> 
> >  >> drivers/usb/gadget/f_dfu.c | 2 +- 
> >  >> 1 file changed, 1 insertion(+), 1 deletion(-) 
> >  >> 
> >  >> diff --git a/drivers/usb/gadget/f_dfu.c
> >  >> b/drivers/usb/gadget/f_dfu.c index 8e7c981657..64cdfa7c98
> >  >> 100644 --- a/drivers/usb/gadget/f_dfu.c 
> >  >> +++ b/drivers/usb/gadget/f_dfu.c 
> >  >> @@ -159,7 +159,7 @@ static void dnload_request_complete(struct
> >  >> usb_ep *ep, struct usb_request *req) int ret; 
> >  >> 
> >  >> ret = dfu_write(dfu_get_entity(f_dfu->altsetting), req->buf, 
> >  >> - req->length, f_dfu->blk_seq_num); 
> >  >> + req->actual, f_dfu->blk_seq_num); 
> >
> >  DFU driver queues a request to USB controller. Per the gadget API 
> >  req->length contains maximum amount of data to be 
> >  transmitted. req->actual is written by USB controller with the
> > actual amount of data that we transmitted. 
> >
> >  In the case of IN (TX), upon completion req->length and
> > req->actual should always be equal (unless errors show up, etc) 
> >
> >  In the case of OUT (RX), upon completion req->actual MAY BE less
> > than req->length and that's not an error. Say host sent us a short
> > packet which causes early termination of transfer. 
> >
> >  With that in mind, let's consider the situation where we're
> > receiving data from host using DFU. Let's assume that we have a
> > 4096 byte buffer for transfers and we're receiving a binary that's
> > 7679 bytes in size. 
> >
> >  Here's what we will do (pseudo-code): 
> >
> >  int remaining = 7679; 
> >  char buf[4096]; 
> >
> >  while (remaining) { 
> >  req->length = 4096; 
> >  req->buf = buf; 
> >  usb_ep_queue(req); 
> >
> >  /* wait for completion */ 
> >
> >  remaining -= req->actual; 
> >
> >  dfu_write(buf, req->length); /* this is the error */ 
> >  } 
> >
> >  Can you see here that in the last packet we will write 4096 bytes
> > when we should write only 3583? 
> >
> > In principle you are right. I need to check if this change will not
> > introduce regressions.
> >
> > Can you share your use case?
> 
> Intel Edison running v2017.03-rc1 + patches (see [1]), flashing
> u-boot.bin over DFU (see [2] for details). Without $subject, image has
> to be aligned to 4096 bytes as below:
> 
> $ dd if=u-boot.bin of=u-boot-4k.bin bs=4k seek=1 && truncate -s %4096
> u-boot-4k.bin
> 
> With $subject, I don't need truncate. We still need the 4096 byte of
> zeroes in the beginning of the image for other reasons (which I really
> don't know why at this point).
> 
> [1] https://github.com/andy-shev/u-boot/tree/edison
> [2] https://communities.intel.com/message/435516#435516
> 

Ok. I will check this. Thanks for pointing out :-)



Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de


pgpKrO7g5ltgt.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] omapl138_lcdk: Set uboot raw mmc sector to 0x41

2017-02-13 Thread Axel Haslam
Hi Tom

On Mon, Feb 13, 2017 at 2:23 PM, Tom Rini  wrote:
> On Mon, Feb 13, 2017 at 11:44:57AM +0100, Axel Haslam wrote:
>> The uboot binary on the AIS file starts at offset 0x8000.
>> This would be sector 0x40 on a mmc card with 512 bytes per
>> sector: 0x8000/0x200 = 0x40.
>>
>> But because we usually skip the first mmc sector to preserve
>> the partition table, the ais image is written starting
>> on sector 0x1, and the u-boot binary ends up at sector 0x41.
>>
>> Set the address of the u-boot binary to 0x41 so that spl
>> can correctly jump to it.
>>
>> Signed-off-by: Axel Haslam 
>> ---
>>  configs/omapl138_lcdk_defconfig | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/configs/omapl138_lcdk_defconfig 
>> b/configs/omapl138_lcdk_defconfig
>> index d20af19..a249ebd 100644
>> --- a/configs/omapl138_lcdk_defconfig
>> +++ b/configs/omapl138_lcdk_defconfig
>> @@ -12,7 +12,7 @@ CONFIG_VERSION_VARIABLE=y
>>  # CONFIG_DISPLAY_BOARDINFO is not set
>>  CONFIG_BOARD_EARLY_INIT_F=y
>>  CONFIG_SPL=y
>> -CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0xb5
>> +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x41
>
> Since we're changing a default here, and one that will lead to
> non-booting boards if you don't notice, where did the old value come
> from, and is it actually in use anywhere?  Thanks!
>

I think the "old offset" would be correct when you copy the AIS image
to the sd card using the uflash tool from TI. This tool adds some extra
space at the start of the mmc for UBL configuration settings, which does
not seem to be needed for the lcdk. The generated AIS image with SPL
can boot the board directly and we can just copy the resulting AIS
to the sdcard with the "dd" command.

-Axel.

> --
> Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] omapl138_lcdk: Set uboot raw mmc sector to 0x41

2017-02-13 Thread Tom Rini
On Mon, Feb 13, 2017 at 03:14:28PM +0100, Axel Haslam wrote:
> Hi Tom
> 
> On Mon, Feb 13, 2017 at 2:23 PM, Tom Rini  wrote:
> > On Mon, Feb 13, 2017 at 11:44:57AM +0100, Axel Haslam wrote:
> >> The uboot binary on the AIS file starts at offset 0x8000.
> >> This would be sector 0x40 on a mmc card with 512 bytes per
> >> sector: 0x8000/0x200 = 0x40.
> >>
> >> But because we usually skip the first mmc sector to preserve
> >> the partition table, the ais image is written starting
> >> on sector 0x1, and the u-boot binary ends up at sector 0x41.
> >>
> >> Set the address of the u-boot binary to 0x41 so that spl
> >> can correctly jump to it.
> >>
> >> Signed-off-by: Axel Haslam 
> >> ---
> >>  configs/omapl138_lcdk_defconfig | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/configs/omapl138_lcdk_defconfig 
> >> b/configs/omapl138_lcdk_defconfig
> >> index d20af19..a249ebd 100644
> >> --- a/configs/omapl138_lcdk_defconfig
> >> +++ b/configs/omapl138_lcdk_defconfig
> >> @@ -12,7 +12,7 @@ CONFIG_VERSION_VARIABLE=y
> >>  # CONFIG_DISPLAY_BOARDINFO is not set
> >>  CONFIG_BOARD_EARLY_INIT_F=y
> >>  CONFIG_SPL=y
> >> -CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0xb5
> >> +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x41
> >
> > Since we're changing a default here, and one that will lead to
> > non-booting boards if you don't notice, where did the old value come
> > from, and is it actually in use anywhere?  Thanks!
> 
> I think the "old offset" would be correct when you copy the AIS image
> to the sd card using the uflash tool from TI. This tool adds some extra
> space at the start of the mmc for UBL configuration settings, which does
> not seem to be needed for the lcdk. The generated AIS image with SPL
> can boot the board directly and we can just copy the resulting AIS
> to the sdcard with the "dd" command.

Ah yes, that tool.  What is the drive for not being compatible with that
tool in terms of offset?  With binman it should be easy enough to have
U-Boot generate a binary with sufficient padding between items.  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] am335x: musb: mass storage device issue

2017-02-13 Thread Belisko Marek
Hi Yegor,

On Mon, Feb 13, 2017 at 12:57 PM, Yegor Yefremov  wrote:

> My am335x based board doesn't detect USB sticks:
>
> U-Boot 2017.03-rc1 (Feb 13 2017 - 12:46:54 +0100)
>
> CPU  : AM335X-GP rev 2.1
> I2C:   ready
> DRAM:  256 MiB
> NAND:  256 MiB
> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> Using default environment
>
> Net:not set. Validating first E-fuse MAC
> cpsw
> Hit any key to stop autoboot:  0
> => usb reset
> resetting USB...
> USB0:   scanning bus 0 for devices... 2 USB Device(s) found
>scanning usb for storage devices... 0 Storage Device(s) found
>
>
> => usb tree
> USB device tree:
>   1  Hub (480 Mb/s, 100mA)
>   |   USB2.0 Hub
>   |
>   +-2  Vendor specific (480 Mb/s, 500mA)
>Quectel, Incorporated UMTS/HSPA Module
>
> U-Boot finds a hub and a 3g modem attached to it, but the USB drive,
> that is also attached to this hub won't be detected.
>
 maybe stupid reply but did you test on other board or with other usb
device? I can check on BBB in the evening
and post findings.

>
> So far I haven't tried to bisect the issue (have to find a working
> commit including my board), but the same setup is working for 2014.07
> u-boot. Am I the only one or are other am335x based also affected?
>
> Regards,
> Yegor
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] omapl138_lcdk: Set uboot raw mmc sector to 0x41

2017-02-13 Thread Axel Haslam
On Mon, Feb 13, 2017 at 3:17 PM, Tom Rini  wrote:
> On Mon, Feb 13, 2017 at 03:14:28PM +0100, Axel Haslam wrote:
>> Hi Tom
>>
>> On Mon, Feb 13, 2017 at 2:23 PM, Tom Rini  wrote:
>> > On Mon, Feb 13, 2017 at 11:44:57AM +0100, Axel Haslam wrote:
>> >> The uboot binary on the AIS file starts at offset 0x8000.
>> >> This would be sector 0x40 on a mmc card with 512 bytes per
>> >> sector: 0x8000/0x200 = 0x40.
>> >>
>> >> But because we usually skip the first mmc sector to preserve
>> >> the partition table, the ais image is written starting
>> >> on sector 0x1, and the u-boot binary ends up at sector 0x41.
>> >>
>> >> Set the address of the u-boot binary to 0x41 so that spl
>> >> can correctly jump to it.
>> >>
>> >> Signed-off-by: Axel Haslam 
>> >> ---
>> >>  configs/omapl138_lcdk_defconfig | 2 +-
>> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/configs/omapl138_lcdk_defconfig 
>> >> b/configs/omapl138_lcdk_defconfig
>> >> index d20af19..a249ebd 100644
>> >> --- a/configs/omapl138_lcdk_defconfig
>> >> +++ b/configs/omapl138_lcdk_defconfig
>> >> @@ -12,7 +12,7 @@ CONFIG_VERSION_VARIABLE=y
>> >>  # CONFIG_DISPLAY_BOARDINFO is not set
>> >>  CONFIG_BOARD_EARLY_INIT_F=y
>> >>  CONFIG_SPL=y
>> >> -CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0xb5
>> >> +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x41
>> >
>> > Since we're changing a default here, and one that will lead to
>> > non-booting boards if you don't notice, where did the old value come
>> > from, and is it actually in use anywhere?  Thanks!
>>
>> I think the "old offset" would be correct when you copy the AIS image
>> to the sd card using the uflash tool from TI. This tool adds some extra
>> space at the start of the mmc for UBL configuration settings, which does
>> not seem to be needed for the lcdk. The generated AIS image with SPL
>> can boot the board directly and we can just copy the resulting AIS
>> to the sdcard with the "dd" command.
>
> Ah yes, that tool.  What is the drive for not being compatible with that
> tool in terms of offset?  With binman it should be easy enough to have
> U-Boot generate a binary with sufficient padding between items.  Thanks!
>

Good point.  i will try that instead. Thanks for the tip.

Axel.

> --
> Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [GIT PULL] Xilinx fixes

2017-02-13 Thread Michal Simek
Hi Tom,

here are some fixes, please pull them to your tree.

Mike: I have rebased your origin patches because of some conflicts.
Please check when they are applied.

Thanks,
Michal


The following changes since commit f1cc97764be4383d2aeb56d5ba5415439a1d5c97:

  Merge branch 'master' of git://git.denx.de/u-boot-video (2017-02-09
14:54:09 -0500)

are available in the git repository at:


  git://www.denx.de/git/u-boot-microblaze.git tags/xilinx-fixes-for-v2017.03

for you to fetch changes up to 1d82e2c15cc2ff7eaa334aaa41dacf4242881a1d:

  microblaze: Fix endif macro command (2017-02-10 13:59:36 +0100)


Xilinx fixes for v2017.03

- defconfig alignment
- Topic.nl board updates
- Minor microblaze comment fix


Michal Simek (2):
  xilinx: Align defconfig with current Kconfig order
  microblaze: Fix endif macro command

Mike Looijmans (3):
  topic_miami_defconfig: Remove NFS and NET support
  topic_miami(plus) defconfig: Enable DFU RAM support
  configs/topic_miami.h: Correct kernel_size in default environment

 arch/microblaze/cpu/start.S  | 2 +-
 configs/microblaze-generic_defconfig | 2 +-
 configs/topic_miami_defconfig| 8 +---
 configs/topic_miamiplus_defconfig| 5 +++--
 configs/xilinx_zynqmp_ep_defconfig   | 4 ++--
 configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 4 ++--
 configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 2 +-
 configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig | 4 ++--
 configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig | 4 ++--
 configs/xilinx_zynqmp_zcu102_defconfig   | 4 ++--
 configs/xilinx_zynqmp_zcu102_revB_defconfig  | 4 ++--
 configs/zynq_microzed_defconfig  | 2 +-
 configs/zynq_picozed_defconfig   | 2 +-
 configs/zynq_zc702_defconfig | 2 +-
 configs/zynq_zc706_defconfig | 2 +-
 configs/zynq_zc770_xm010_defconfig   | 2 +-
 configs/zynq_zed_defconfig   | 2 +-
 configs/zynq_zybo_defconfig  | 2 +-
 include/configs/topic_miami.h| 2 +-
 19 files changed, 31 insertions(+), 28 deletions(-)


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs




signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v1] mmc: pci: only compile on platforms that need it

2017-02-13 Thread Andy Shevchenko
From: Felipe Balbi 

We should only compile pci_mmc.c on platforms that actually need
this. Some platforms are using generic sdhci through driver model.

Signed-off-by: Felipe Balbi 
Signed-off-by: Andy Shevchenko 
---
 drivers/mmc/Makefile | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 49413dfaf1..26db92e582 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -36,7 +36,9 @@ obj-$(CONFIG_MVEBU_MMC) += mvebu_mmc.o
 obj-$(CONFIG_MMC_OMAP_HS)  += omap_hsmmc.o
 obj-$(CONFIG_MMC_MXC)  += mxcmmc.o
 obj-$(CONFIG_MMC_MXS)  += mxsmmc.o
-obj-$(CONFIG_X86) += pci_mmc.o
+obj-$(CONFIG_INTEL_BAYTRAIL) += pci_mmc.o
+obj-$(CONFIG_INTEL_QUARK) += pci_mmc.o
+obj-$(CONFIG_INTEL_QUEENSBAY) += pci_mmc.o
 obj-$(CONFIG_PXA_MMC_GENERIC) += pxa_mmc_gen.o
 obj-$(CONFIG_SUPPORT_EMMC_RPMB) += rpmb.o
 obj-$(CONFIG_S3C_SDI) += s3c_sdi.o
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v1] usb: gadget: f_dfu: write req->actual bytes

2017-02-13 Thread Andy Shevchenko
On Mon, 2017-02-13 at 14:41 +0100, Lukasz Majewski wrote:

> > [1] https://github.com/andy-shev/u-boot/tree/edison
> > [2] https://communities.intel.com/message/435516#435516
> > 
> 
> Ok. I will check this. Thanks for pointing out :-)

Just in case, mentioned branch is occasionally rebased, so, for "stable"
code I do tags with "edison" prefix.

-- 
Andy Shevchenko 
Intel Finland Oy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] am335x: musb: mass storage device issue

2017-02-13 Thread Yegor Yefremov
On Mon, Feb 13, 2017 at 3:17 PM, Belisko Marek  wrote:
> Hi Yegor,
>
> On Mon, Feb 13, 2017 at 12:57 PM, Yegor Yefremov
>  wrote:
>>
>> My am335x based board doesn't detect USB sticks:
>>
>> U-Boot 2017.03-rc1 (Feb 13 2017 - 12:46:54 +0100)
>>
>> CPU  : AM335X-GP rev 2.1
>> I2C:   ready
>> DRAM:  256 MiB
>> NAND:  256 MiB
>> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
>> Using default environment
>>
>> Net:not set. Validating first E-fuse MAC
>> cpsw
>> Hit any key to stop autoboot:  0
>> => usb reset
>> resetting USB...
>> USB0:   scanning bus 0 for devices... 2 USB Device(s) found
>>scanning usb for storage devices... 0 Storage Device(s) found
>>
>>
>> => usb tree
>> USB device tree:
>>   1  Hub (480 Mb/s, 100mA)
>>   |   USB2.0 Hub
>>   |
>>   +-2  Vendor specific (480 Mb/s, 500mA)
>>Quectel, Incorporated UMTS/HSPA Module
>>
>> U-Boot finds a hub and a 3g modem attached to it, but the USB drive,
>> that is also attached to this hub won't be detected.
>
>  maybe stupid reply but did you test on other board or with other usb
> device? I can check on BBB in the evening
> and post findings.

And please provide your u-boot version.

>> So far I haven't tried to bisect the issue (have to find a working
>> commit including my board), but the same setup is working for 2014.07
>> u-boot. Am I the only one or are other am335x based also affected?

Bisect result:

2ef117fe4fce4e1af282ac2bbb0be36c41d15e2b is the first bad commit
commit 2ef117fe4fce4e1af282ac2bbb0be36c41d15e2b
Author: Stefan Roese 
Date:   Tue Mar 15 13:59:13 2016 +0100

usb: Remove 200 ms delay in usb_hub_port_connect_change()

This patch removes 2 mdelay(200) calls from usb_hub_port_connect_change().
These delays don't seem to be necessary. At least not in my tests. Here
the number for a custom x86 Bay Trail board (not in mainline yet) with
a quite large and complex USB hub infrastructure.

Without this patch:
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 9 USB Device(s) found

time: 28.415 seconds

With this patch:
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 9 USB Device(s) found

time: 24.003 seconds

So ~4.5 seconds of USB scanning time reduction.

Signed-off-by: Stefan Roese 
Cc: Simon Glass 
Acked-by: Hans de Goede 
Tested-by: Stephen Warren 
Cc: Marek Vasut 

:04 04 1902518572402e9b376f78b01f610e5d732ccfe4
c98db076cbb839d6a1c0975cbdb92e1ccc82cbeb M  common

Yegor
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2 3/4] drivers: ti_qspi: use syscon to get the address ctrl_mod_mmap register

2017-02-13 Thread Jean-Jacques Hiblot
We used to get the address of the optionnal ctrl_mod_mmap register as the
third memory range of the "reg" property. the linux driver moved to use a
syscon instead. In order to keep the DTS as close as possible to that of
linux, we move to using a syscon as well.

If SYSCON is not supported, the driver reverts to the old way of getting
the address from the 3rd memory range

Signed-off-by: Jean-Jacques Hiblot 
---
 drivers/spi/ti_qspi.c | 47 ++-
 1 file changed, 42 insertions(+), 5 deletions(-)

diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c
index 79955d7..3c4c9dd 100644
--- a/drivers/spi/ti_qspi.c
+++ b/drivers/spi/ti_qspi.c
@@ -17,6 +17,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -549,21 +551,56 @@ static int ti_qspi_probe(struct udevice *bus)
return 0;
 }
 
+static void *map_syscon_chipselects(struct udevice *bus)
+{
+#if CONFIG_IS_ENABLED(SYSCON)
+   struct udevice *syscon;
+   struct regmap *regmap;
+   const fdt32_t *cell;
+   int len, err;
+
+   err = uclass_get_device_by_phandle(UCLASS_SYSCON, bus,
+  "syscon-chipselects", &syscon);
+   if (err) {
+   debug("%s: unable to find syscon device (%d)\n", __func__,
+ err);
+   return NULL;
+   }
+
+   regmap = syscon_get_regmap(syscon);
+   if (IS_ERR(regmap)) {
+   debug("%s: unable to find regmap (%ld)\n", __func__,
+ PTR_ERR(regmap));
+   return NULL;
+   }
+
+   cell = fdt_getprop(gd->fdt_blob, bus->of_offset, "syscon-chipselects",
+  &len);
+   if (len < 2*sizeof(fdt32_t)) {
+   debug("%s: offset not available\n", __func__);
+   return NULL;
+   }
+
+   return fdtdec_get_number(cell + 1, 1) + regmap_get_range(regmap, 0);
+#else
+   fdt_addr_t addr;
+   addr = dev_get_addr_index(bus, 2);
+   return (addr == FDT_ADDR_T_NONE) ? NULL :
+   map_physmem(addr, 0, MAP_NOCACHE);
+#endif
+}
+
 static int ti_qspi_ofdata_to_platdata(struct udevice *bus)
 {
struct ti_qspi_priv *priv = dev_get_priv(bus);
const void *blob = gd->fdt_blob;
int node = dev_of_offset(bus);
-   fdt_addr_t addr;
-   void *mmap;
 
+   priv->ctrl_mod_mmap = map_syscon_chipselects(bus);
priv->base = map_physmem(dev_get_addr(bus), sizeof(struct ti_qspi_regs),
 MAP_NOCACHE);
priv->memory_map = map_physmem(dev_get_addr_index(bus, 1), 0,
   MAP_NOCACHE);
-   addr = dev_get_addr_index(bus, 2);
-   mmap = map_physmem(dev_get_addr_index(bus, 2), 0, MAP_NOCACHE);
-   priv->ctrl_mod_mmap = (addr == FDT_ADDR_T_NONE) ? NULL : mmap;
 
priv->max_hz = fdtdec_get_int(blob, node, "spi-max-frequency", -1);
if (priv->max_hz < 0) {
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2 1/4] libfdt: Allow the SPL to perform fdt address translation

2017-02-13 Thread Jean-Jacques Hiblot
Use OF_TRANSLATE for both u-boot and SPL to tell whether fdt address
translation should be used.

Signed-off-by: Jean-Jacques Hiblot 
---

to: s...@chromium.org

lib/fdtdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 81f47ef..1edfbf2 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -112,7 +112,7 @@ fdt_addr_t fdtdec_get_addr_size_fixed(const void *blob, int 
node,
return FDT_ADDR_T_NONE;
}
 
-#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_OF_LIBFDT)
+#if CONFIG_IS_ENABLED(OF_TRANSLATE)
if (translate)
addr = fdt_translate_address(blob, node, prop_addr);
else
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2 0/4] driver: ti_qspi: Use a SYSCON device to map the ctrl_mod_mmap register

2017-02-13 Thread Jean-Jacques Hiblot
This series allows the ti_qspi driver to use the same dts description as the
linux kernel. In Linux since 4.6 the ctrl_mod_mmap is described in the DTS as a
syscon. It used to be the 3rd memory range in "reg".

The first two patches of this series are generic ones:
 * Allow the SPL version of fdtdec_get_addr_size_fixed() to perform address
   translation
 * change the regmap initialization to take in account the required address
   translation by using fdtdec_get_addr_size_fixed().

The third patch adds the mechanism in the ti_qspi driver to get the address
of ctrl_mod_mmap from the syscon

The last patch simply enable the SYSCON feature in the default config for the
dra7xx and am57xx evms.

changes since v1:
 * rebased on top of Lokesh's series enabling support for SPL_DM][1][2]
 * Added a patch to enable address translation in fdtdec_get_addr_size_fixed()
 * use CONFIG_IS_ENABLED(XXX) instead of CONFIG_XXX and CONFIG_SPL_XXX to
   simplify the conditional code.
 

[1] https://www.mail-archive.com/u-boot@lists.denx.de/msg238751.html
[2] https://www.mail-archive.com/u-boot@lists.denx.de/msg238964.html

Jean-Jacques Hiblot (4):
  libfdt: Allow the SPL to perform fdt address translation
  regmap: use fdt address translation
  drivers: ti_qspi: use syscon to get the address ctrl_mod_mmap register
  configs: dra7x/am57x: Enable the SYSCON and REGMAP features

 configs/am57xx_evm_defconfig|  6 ++
 configs/am57xx_hs_evm_defconfig |  6 ++
 configs/dra7xx_evm_defconfig|  6 ++
 configs/dra7xx_hs_evm_defconfig |  6 ++
 drivers/core/regmap.c   | 14 ++--
 drivers/spi/ti_qspi.c   | 47 -
 lib/fdtdec.c|  2 +-
 7 files changed, 75 insertions(+), 12 deletions(-)

-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2 4/4] configs: dra7x/am57x: Enable the SYSCON and REGMAP features

2017-02-13 Thread Jean-Jacques Hiblot
This is required by the ti_qspi driver to get from the DTS the address of
the ctrl_mod_mmap register in SPL and in u-boot.

Signed-off-by: Jean-Jacques Hiblot 
---
 configs/am57xx_evm_defconfig| 6 ++
 configs/am57xx_hs_evm_defconfig | 6 ++
 configs/dra7xx_evm_defconfig| 6 ++
 configs/dra7xx_hs_evm_defconfig | 6 ++
 4 files changed, 24 insertions(+)

diff --git a/configs/am57xx_evm_defconfig b/configs/am57xx_evm_defconfig
index d9648d8..ca20e18 100644
--- a/configs/am57xx_evm_defconfig
+++ b/configs/am57xx_evm_defconfig
@@ -56,9 +56,15 @@ CONFIG_CMD_FS_GENERIC=y
 CONFIG_ISO_PARTITION=y
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
+CONFIG_SPL_OF_TRANSLATE=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_OF_LIST="am57xx-beagle-x15 am57xx-beagle-x15-revb1 am572x-idk 
am571x-idk"
 CONFIG_DM=y
 CONFIG_SPL_DM=y
+CONFIG_REGMAP=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SYSCON=y
+CONFIG_SPL_SYSCON=y
 # CONFIG_BLK is not set
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
diff --git a/configs/am57xx_hs_evm_defconfig b/configs/am57xx_hs_evm_defconfig
index a0abf34..a907008 100644
--- a/configs/am57xx_hs_evm_defconfig
+++ b/configs/am57xx_hs_evm_defconfig
@@ -59,8 +59,14 @@ CONFIG_CMD_FS_GENERIC=y
 CONFIG_ISO_PARTITION=y
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
+CONFIG_SPL_OF_TRANSLATE=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_DM=y
 CONFIG_SPL_DM=y
+CONFIG_REGMAP=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SYSCON=y
+CONFIG_SPL_SYSCON=y
 # CONFIG_BLK is not set
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
diff --git a/configs/dra7xx_evm_defconfig b/configs/dra7xx_evm_defconfig
index 42f87b3..968b8cf 100644
--- a/configs/dra7xx_evm_defconfig
+++ b/configs/dra7xx_evm_defconfig
@@ -56,9 +56,15 @@ CONFIG_CMD_FS_GENERIC=y
 CONFIG_ISO_PARTITION=y
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
+CONFIG_SPL_OF_TRANSLATE=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_OF_LIST="dra7-evm dra72-evm dra72-evm-revc dra71-evm"
 CONFIG_DM=y
 CONFIG_SPL_DM=y
+CONFIG_REGMAP=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SYSCON=y
+CONFIG_SPL_SYSCON=y
 # CONFIG_BLK is not set
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
diff --git a/configs/dra7xx_hs_evm_defconfig b/configs/dra7xx_hs_evm_defconfig
index 12f2c3a..0775183 100644
--- a/configs/dra7xx_hs_evm_defconfig
+++ b/configs/dra7xx_hs_evm_defconfig
@@ -60,9 +60,15 @@ CONFIG_CMD_FS_GENERIC=y
 CONFIG_ISO_PARTITION=y
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
+CONFIG_SPL_OF_TRANSLATE=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_OF_LIST="dra7-evm dra72-evm dra72-evm-revc dra71-evm"
 CONFIG_DM=y
 CONFIG_SPL_DM=y
+CONFIG_REGMAP=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SYSCON=y
+CONFIG_SPL_SYSCON=y
 # CONFIG_BLK is not set
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2 2/4] regmap: use fdt address translation

2017-02-13 Thread Jean-Jacques Hiblot
In the DTS, the addresses are defined relative to the parent bus. We need
to translate them to get the address as seen by the CPU core.

Signed-off-by: Jean-Jacques Hiblot 
---

to: s...@chromium.org

 drivers/core/regmap.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
index 833cd78..3bec3df 100644
--- a/drivers/core/regmap.c
+++ b/drivers/core/regmap.c
@@ -70,6 +70,7 @@ int regmap_init_mem(struct udevice *dev, struct regmap **mapp)
int addr_len, size_len, both_len;
int parent;
int len;
+   int index;
 
parent = dev_of_offset(dev->parent);
addr_len = fdt_address_cells(blob, parent);
@@ -86,13 +87,14 @@ int regmap_init_mem(struct udevice *dev, struct regmap 
**mapp)
if (!map)
return -ENOMEM;
 
-   map->base = fdtdec_get_number(cell, addr_len);
-
-   for (range = map->range; count > 0;
-count--, cell += both_len, range++) {
-   range->start = fdtdec_get_number(cell, addr_len);
-   range->size = fdtdec_get_number(cell + addr_len, size_len);
+   for (range = map->range, index = 0; count > 0;
+count--, cell += both_len, range++, index++) {
+   fdt_size_t sz;
+   range->start = fdtdec_get_addr_size_fixed(blob, dev->of_offset,
+   "reg", index, addr_len, size_len, &sz, true);
+   range->size = sz;
}
+   map->base = map->range[0].start;
 
*mapp = map;
 
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/4] libfdt: Allow the SPL to perform fdt address translation

2017-02-13 Thread Jean-Jacques Hiblot



On 13/02/2017 16:41, Lokesh Vutla wrote:


On 2/13/2017 8:47 PM, Jean-Jacques Hiblot wrote:

Use OF_TRANSLATE for both u-boot and SPL to tell whether fdt address
translation should be used.

Signed-off-by: Jean-Jacques Hiblot 

Vignesh has posted a similar patch[1].

Sorry, I had missed this one. Please ignore this patch.


[1]http://patchwork.ozlabs.org/patch/727131/

Thanks and regards,
Lokesh


---

to: s...@chromium.org

lib/fdtdec.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 81f47ef..1edfbf2 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -112,7 +112,7 @@ fdt_addr_t fdtdec_get_addr_size_fixed(const void *blob, int 
node,
return FDT_ADDR_T_NONE;
}
  
-#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_OF_LIBFDT)

+#if CONFIG_IS_ENABLED(OF_TRANSLATE)
if (translate)
addr = fdt_translate_address(blob, node, prop_addr);
else



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] omapl138_lcdk: Set uboot raw mmc sector to 0x41

2017-02-13 Thread Axel Haslam
Hi Tom

On Mon, Feb 13, 2017 at 3:23 PM, Axel Haslam  wrote:
> On Mon, Feb 13, 2017 at 3:17 PM, Tom Rini  wrote:
>> On Mon, Feb 13, 2017 at 03:14:28PM +0100, Axel Haslam wrote:
>>> Hi Tom
>>>
>>> On Mon, Feb 13, 2017 at 2:23 PM, Tom Rini  wrote:
>>> > On Mon, Feb 13, 2017 at 11:44:57AM +0100, Axel Haslam wrote:
>>> >> The uboot binary on the AIS file starts at offset 0x8000.
>>> >> This would be sector 0x40 on a mmc card with 512 bytes per
>>> >> sector: 0x8000/0x200 = 0x40.
>>> >>
>>> >> But because we usually skip the first mmc sector to preserve
>>> >> the partition table, the ais image is written starting
>>> >> on sector 0x1, and the u-boot binary ends up at sector 0x41.
>>> >>
>>> >> Set the address of the u-boot binary to 0x41 so that spl
>>> >> can correctly jump to it.
>>> >>
>>> >> Signed-off-by: Axel Haslam 
>>> >> ---
>>> >>  configs/omapl138_lcdk_defconfig | 2 +-
>>> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>>> >>
>>> >> diff --git a/configs/omapl138_lcdk_defconfig 
>>> >> b/configs/omapl138_lcdk_defconfig
>>> >> index d20af19..a249ebd 100644
>>> >> --- a/configs/omapl138_lcdk_defconfig
>>> >> +++ b/configs/omapl138_lcdk_defconfig
>>> >> @@ -12,7 +12,7 @@ CONFIG_VERSION_VARIABLE=y
>>> >>  # CONFIG_DISPLAY_BOARDINFO is not set
>>> >>  CONFIG_BOARD_EARLY_INIT_F=y
>>> >>  CONFIG_SPL=y
>>> >> -CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0xb5
>>> >> +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x41
>>> >
>>> > Since we're changing a default here, and one that will lead to
>>> > non-booting boards if you don't notice, where did the old value come
>>> > from, and is it actually in use anywhere?  Thanks!
>>>
>>> I think the "old offset" would be correct when you copy the AIS image
>>> to the sd card using the uflash tool from TI. This tool adds some extra
>>> space at the start of the mmc for UBL configuration settings, which does
>>> not seem to be needed for the lcdk. The generated AIS image with SPL
>>> can boot the board directly and we can just copy the resulting AIS
>>> to the sdcard with the "dd" command.
>>
>> Ah yes, that tool.  What is the drive for not being compatible with that
>> tool in terms of offset?  With binman it should be easy enough to have
>> U-Boot generate a binary with sufficient padding between items.  Thanks!
>>
>
> Good point.  i will try that instead. Thanks for the tip.

I looked at how the uflash tool works and it takes as input the AIS
image, which i think means we would have to have yet another
type of image specific for mmc that adds the padding.

An alternative to this would be just to document that to
write the AIS  image we need to skip 117 sectors, like so:

sudo dd if=./u-boot.ais of=/dev/mmcblk0 seek=117 bs=512

this would make u-boot fall into sector 0xb5, which would be
exactly the same that is uflash ends up writing uboot to, and
there would be no defconfig changes.

Would this be acceptable?

-Axel.



>
> Axel.
>
>> --
>> Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/4] libfdt: Allow the SPL to perform fdt address translation

2017-02-13 Thread Lokesh Vutla


On 2/13/2017 8:47 PM, Jean-Jacques Hiblot wrote:
> Use OF_TRANSLATE for both u-boot and SPL to tell whether fdt address
> translation should be used.
> 
> Signed-off-by: Jean-Jacques Hiblot 

Vignesh has posted a similar patch[1].

[1]http://patchwork.ozlabs.org/patch/727131/

Thanks and regards,
Lokesh

> ---
> 
> to: s...@chromium.org
> 
> lib/fdtdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> index 81f47ef..1edfbf2 100644
> --- a/lib/fdtdec.c
> +++ b/lib/fdtdec.c
> @@ -112,7 +112,7 @@ fdt_addr_t fdtdec_get_addr_size_fixed(const void *blob, 
> int node,
>   return FDT_ADDR_T_NONE;
>   }
>  
> -#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_OF_LIBFDT)
> +#if CONFIG_IS_ENABLED(OF_TRANSLATE)
>   if (translate)
>   addr = fdt_translate_address(blob, node, prop_addr);
>   else
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 1/3] ARM: uniphier: move MMC code to a separate file

2017-02-13 Thread Masahiro Yamada
Currently, arch/arm/mach-uniphier/boot-mode/boot-mode.c is messed up
with unrelated code; there is no reason why the "mmcsetn" command
must be placed in this file.

Split out the MMC code into arch/arm/mach-uniphier/mmc-first-dev.c.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/Makefile  |  1 +
 arch/arm/mach-uniphier/boot-mode/boot-mode.c | 38 ---
 arch/arm/mach-uniphier/mmc-first-dev.c   | 46 
 3 files changed, 47 insertions(+), 38 deletions(-)
 create mode 100644 arch/arm/mach-uniphier/mmc-first-dev.c

diff --git a/arch/arm/mach-uniphier/Makefile b/arch/arm/mach-uniphier/Makefile
index 166b41f..0eb59fb 100644
--- a/arch/arm/mach-uniphier/Makefile
+++ b/arch/arm/mach-uniphier/Makefile
@@ -19,6 +19,7 @@ obj-y += reset.o
 
 obj-$(CONFIG_MICRO_SUPPORT_CARD) += sbc/ micro-support-card.o
 obj-y += pinctrl-glue.o
+obj-$(CONFIG_MMC) += mmc-first-dev.o
 
 endif
 
diff --git a/arch/arm/mach-uniphier/boot-mode/boot-mode.c 
b/arch/arm/mach-uniphier/boot-mode/boot-mode.c
index a552770..6ce3273 100644
--- a/arch/arm/mach-uniphier/boot-mode/boot-mode.c
+++ b/arch/arm/mach-uniphier/boot-mode/boot-mode.c
@@ -100,41 +100,3 @@ u32 spl_boot_mode(const u32 boot_device)
 
return MMCSD_MODE_EMMCBOOT;
 }
-
-#if defined(CONFIG_DM_MMC) && !defined(CONFIG_SPL_BUILD)
-static int find_first_mmc_device(void)
-{
-   struct mmc *mmc;
-   int i;
-
-   for (i = 0; (mmc = find_mmc_device(i)); i++) {
-   if (!mmc_init(mmc) && IS_MMC(mmc))
-   return i;
-   }
-
-   return -ENODEV;
-}
-
-int mmc_get_env_dev(void)
-{
-   return find_first_mmc_device();
-}
-
-static int do_mmcsetn(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
argv[])
-{
-   int dev;
-
-   dev = find_first_mmc_device();
-   if (dev < 0)
-   return CMD_RET_FAILURE;
-
-   setenv_ulong("mmc_first_dev", dev);
-   return CMD_RET_SUCCESS;
-}
-
-U_BOOT_CMD(
-  mmcsetn, 1,  1,  do_mmcsetn,
-   "Set the first MMC (not SD) dev number to \"mmc_first_dev\" 
environment",
-   ""
-);
-#endif
diff --git a/arch/arm/mach-uniphier/mmc-first-dev.c 
b/arch/arm/mach-uniphier/mmc-first-dev.c
new file mode 100644
index 000..8c45229
--- /dev/null
+++ b/arch/arm/mach-uniphier/mmc-first-dev.c
@@ -0,0 +1,46 @@
+/*
+ * Copyright (C) 2016 Socionext Inc.
+ *   Author: Masahiro Yamada 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+
+static int find_first_mmc_device(void)
+{
+   struct mmc *mmc;
+   int i;
+
+   for (i = 0; (mmc = find_mmc_device(i)); i++) {
+   if (!mmc_init(mmc) && IS_MMC(mmc))
+   return i;
+   }
+
+   return -ENODEV;
+}
+
+int mmc_get_env_dev(void)
+{
+   return find_first_mmc_device();
+}
+
+static int do_mmcsetn(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
argv[])
+{
+   int dev;
+
+   dev = find_first_mmc_device();
+   if (dev < 0)
+   return CMD_RET_FAILURE;
+
+   setenv_ulong("mmc_first_dev", dev);
+   return CMD_RET_SUCCESS;
+}
+
+U_BOOT_CMD(
+  mmcsetn, 1,  1,  do_mmcsetn,
+   "Set the first MMC (not SD) dev number to \"mmc_first_dev\" 
environment",
+   ""
+);
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 2/3] ARM: uniphier: move spl_boot_mode() to a separate file

2017-02-13 Thread Masahiro Yamada
The spl_boot_mode() is unrelated to the other code in this file.
Besides, this function is only called from common/spl/spl_mmc.c,
so it is reasonable to guard with CONFIG_SPL_MMC_SUPPORT.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/Makefile  |  1 +
 arch/arm/mach-uniphier/boot-mode/boot-mode.c | 24 
 arch/arm/mach-uniphier/mmc-boot-mode.c   | 27 +++
 3 files changed, 28 insertions(+), 24 deletions(-)
 create mode 100644 arch/arm/mach-uniphier/mmc-boot-mode.c

diff --git a/arch/arm/mach-uniphier/Makefile b/arch/arm/mach-uniphier/Makefile
index 0eb59fb..7baec73 100644
--- a/arch/arm/mach-uniphier/Makefile
+++ b/arch/arm/mach-uniphier/Makefile
@@ -8,6 +8,7 @@ obj-y += boards.o
 obj-y += spl_board_init.o
 obj-y += memconf.o
 obj-y += bcu/
+obj-$(CONFIG_SPL_MMC_SUPPORT) += mmc-boot-mode.o
 
 else
 
diff --git a/arch/arm/mach-uniphier/boot-mode/boot-mode.c 
b/arch/arm/mach-uniphier/boot-mode/boot-mode.c
index 6ce3273..4e1142b 100644
--- a/arch/arm/mach-uniphier/boot-mode/boot-mode.c
+++ b/arch/arm/mach-uniphier/boot-mode/boot-mode.c
@@ -76,27 +76,3 @@ u32 spl_boot_device(void)
 
return mode;
 }
-
-u32 spl_boot_mode(const u32 boot_device)
-{
-   struct mmc *mmc;
-
-   /*
-* work around a bug in the Boot ROM of PH1-sLD3, LD4, Pro4, and sLD8:
-*
-* The boot ROM in these SoCs breaks the PARTITION_CONFIG [179] of
-* Extended CSD register; when switching to the Boot Partition 1, the
-* Boot ROM should issue the SWITCH command (CMD6) with Set Bits for
-* the Access Bits, but in fact it uses Write Byte for the Access Bits.
-* As a result, the BOOT_PARTITION_ENABLE field of the PARTITION_CONFIG
-* is lost.  This bug was fixed for PH1-Pro5 and later SoCs.
-*
-* Fixup mmc->part_config here because it is used to determine the
-* partition which the U-Boot image is read from.
-*/
-   mmc = find_mmc_device(0);
-   mmc->part_config &= ~EXT_CSD_BOOT_PART_NUM(PART_ACCESS_MASK);
-   mmc->part_config |= EXT_CSD_BOOT_PARTITION_ENABLE;
-
-   return MMCSD_MODE_EMMCBOOT;
-}
diff --git a/arch/arm/mach-uniphier/mmc-boot-mode.c 
b/arch/arm/mach-uniphier/mmc-boot-mode.c
new file mode 100644
index 000..ca13bac
--- /dev/null
+++ b/arch/arm/mach-uniphier/mmc-boot-mode.c
@@ -0,0 +1,27 @@
+#include 
+#include 
+#include 
+
+u32 spl_boot_mode(const u32 boot_device)
+{
+   struct mmc *mmc;
+
+   /*
+* work around a bug in the Boot ROM of PH1-sLD3, LD4, Pro4, and sLD8:
+*
+* The boot ROM in these SoCs breaks the PARTITION_CONFIG [179] of
+* Extended CSD register; when switching to the Boot Partition 1, the
+* Boot ROM should issue the SWITCH command (CMD6) with Set Bits for
+* the Access Bits, but in fact it uses Write Byte for the Access Bits.
+* As a result, the BOOT_PARTITION_ENABLE field of the PARTITION_CONFIG
+* is lost.  This bug was fixed for PH1-Pro5 and later SoCs.
+*
+* Fixup mmc->part_config here because it is used to determine the
+* partition which the U-Boot image is read from.
+*/
+   mmc = find_mmc_device(0);
+   mmc->part_config &= ~EXT_CSD_BOOT_PART_NUM(PART_ACCESS_MASK);
+   mmc->part_config |= EXT_CSD_BOOT_PARTITION_ENABLE;
+
+   return MMCSD_MODE_EMMCBOOT;
+}
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 3/3] ARM: uniphier: rework spl_boot_device() and related code

2017-02-13 Thread Masahiro Yamada
The current implementation has ugly switch statements here and there,
and duplicates similar code.  Rework it using table lookups for SoC
data and reduce code duplication.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/Makefile|   2 +-
 arch/arm/mach-uniphier/board_late_init.c   |   4 +-
 arch/arm/mach-uniphier/boot-device/Makefile|  19 ++
 .../boot-device-ld11.c}|  52 ++
 .../boot-device-ld4.c} |  32 +---
 .../boot-device-pro5.c}|  33 +---
 .../boot-device-pxs2.c}|  34 +---
 .../boot-device-sld3.c}|  32 +---
 arch/arm/mach-uniphier/boot-device/boot-device.c   | 203 +
 arch/arm/mach-uniphier/boot-device/boot-device.h   |  35 
 .../{boot-mode => boot-device}/spl_board.c |   0
 arch/arm/mach-uniphier/boot-mode/Makefile  |  21 ---
 arch/arm/mach-uniphier/boot-mode/boot-device.h |  29 ---
 arch/arm/mach-uniphier/boot-mode/boot-mode.c   |  78 
 arch/arm/mach-uniphier/boot-mode/cmd_pinmon.c  |  59 --
 arch/arm/mach-uniphier/clk/clk-ld11.c  |   3 +-
 arch/arm/mach-uniphier/init.h  |   3 +
 17 files changed, 299 insertions(+), 340 deletions(-)
 create mode 100644 arch/arm/mach-uniphier/boot-device/Makefile
 rename arch/arm/mach-uniphier/{boot-mode/boot-mode-ld20.c => 
boot-device/boot-device-ld11.c} (73%)
 rename arch/arm/mach-uniphier/{boot-mode/boot-mode-ld4.c => 
boot-device/boot-device-ld4.c} (80%)
 rename arch/arm/mach-uniphier/{boot-mode/boot-mode-pro5.c => 
boot-device/boot-device-pro5.c} (79%)
 rename arch/arm/mach-uniphier/{boot-mode/boot-mode-pxs2.c => 
boot-device/boot-device-pxs2.c} (78%)
 rename arch/arm/mach-uniphier/{boot-mode/boot-mode-sld3.c => 
boot-device/boot-device-sld3.c} (85%)
 create mode 100644 arch/arm/mach-uniphier/boot-device/boot-device.c
 create mode 100644 arch/arm/mach-uniphier/boot-device/boot-device.h
 rename arch/arm/mach-uniphier/{boot-mode => boot-device}/spl_board.c (100%)
 delete mode 100644 arch/arm/mach-uniphier/boot-mode/Makefile
 delete mode 100644 arch/arm/mach-uniphier/boot-mode/boot-device.h
 delete mode 100644 arch/arm/mach-uniphier/boot-mode/boot-mode.c
 delete mode 100644 arch/arm/mach-uniphier/boot-mode/cmd_pinmon.c

diff --git a/arch/arm/mach-uniphier/Makefile b/arch/arm/mach-uniphier/Makefile
index 7baec73..124a1c6 100644
--- a/arch/arm/mach-uniphier/Makefile
+++ b/arch/arm/mach-uniphier/Makefile
@@ -25,7 +25,7 @@ obj-$(CONFIG_MMC) += mmc-first-dev.o
 endif
 
 obj-y += soc-info.o
-obj-y += boot-mode/
+obj-y += boot-device/
 obj-y += clk/
 obj-y += dram/
 
diff --git a/arch/arm/mach-uniphier/board_late_init.c 
b/arch/arm/mach-uniphier/board_late_init.c
index ece761f..92dd610 100644
--- a/arch/arm/mach-uniphier/board_late_init.c
+++ b/arch/arm/mach-uniphier/board_late_init.c
@@ -13,7 +13,7 @@
 #include 
 #include <../drivers/mtd/nand/denali.h>
 
-#include "boot-mode/boot-device.h"
+#include "init.h"
 
 static void nand_denali_wp_disable(void)
 {
@@ -62,7 +62,7 @@ int board_late_init(void)
 {
puts("MODE:  ");
 
-   switch (spl_boot_device_raw()) {
+   switch (uniphier_boot_device_raw()) {
case BOOT_DEVICE_MMC1:
printf("eMMC Boot\n");
setenv("bootmode", "emmcboot");
diff --git a/arch/arm/mach-uniphier/boot-device/Makefile 
b/arch/arm/mach-uniphier/boot-device/Makefile
new file mode 100644
index 000..a54d2ac
--- /dev/null
+++ b/arch/arm/mach-uniphier/boot-device/Makefile
@@ -0,0 +1,19 @@
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y  += boot-device.o
+
+obj-$(CONFIG_ARCH_UNIPHIER_SLD3)   += boot-device-sld3.o
+obj-$(CONFIG_ARCH_UNIPHIER_LD4)+= boot-device-ld4.o
+obj-$(CONFIG_ARCH_UNIPHIER_PRO4)   += boot-device-ld4.o
+obj-$(CONFIG_ARCH_UNIPHIER_SLD8)   += boot-device-ld4.o
+obj-$(CONFIG_ARCH_UNIPHIER_PRO5)   += boot-device-pro5.o
+obj-$(CONFIG_ARCH_UNIPHIER_PXS2)   += boot-device-pxs2.o
+obj-$(CONFIG_ARCH_UNIPHIER_LD6B)   += boot-device-pxs2.o
+obj-$(CONFIG_ARCH_UNIPHIER_LD11)   += boot-device-ld11.o
+obj-$(CONFIG_ARCH_UNIPHIER_LD20)   += boot-device-ld11.o
+
+ifdef CONFIG_SPL_BUILD
+obj-$(CONFIG_SPL_BOARD_LOAD_IMAGE) += spl_board.o
+endif
diff --git a/arch/arm/mach-uniphier/boot-mode/boot-mode-ld20.c 
b/arch/arm/mach-uniphier/boot-device/boot-device-ld11.c
similarity index 73%
rename from arch/arm/mach-uniphier/boot-mode/boot-mode-ld20.c
rename to arch/arm/mach-uniphier/boot-device/boot-device-ld11.c
index 2992fd7..f1a467c 100644
--- a/arch/arm/mach-uniphier/boot-mode/boot-mode-ld20.c
+++ b/arch/arm/mach-uniphier/boot-device/boot-device-ld11.c
@@ -8,12 +8,11 @@
 #include 
 #include 
 #include 
+#include 
 
-#include "../sg-regs.h"
-#include "../soc-info.h"
 #include "boot-device.h"
 
-static struct boot_device_info boot_device_tab

Re: [U-Boot] [PATCH v2 2/6] usb: host: xhci-omap: fix double weak board_usb_init functions

2017-02-13 Thread Marek Vasut
On 02/13/2017 12:35 PM, Uri Mashiach wrote:
> A weak version of the function board_usb_init is implemented in:
> common/usb.c
> drivers/usb/host/xhci-omap.c
> 
> To fix the double implementations:
> * Convert the board_usb_init function in drivers/usb/host/xhci-omap.c
>   normal (not weak).
> * The function board_usb_init in drivers/usb/host/xhci-omap.c calls to
>   the weak function omap_xhci_board_usb_init.
> * Rename board version of the function board_usb_init to
>   omap_xhci_board_usb_init.
>   Done only for boards that defines CONFIG_USB_XHCI_OMAP.
> 
> To achieve the same flexibility with the function board_usb_cleanup:
> * Add a normal (not weak) implementation of the function
>   board_usb_cleanup in drivers/usb/host/xhci-omap.c
> * The function board_usb_cleanup in drivers/usb/host/xhci-omap.c calls
>   to the weak function omap_xhci_board_usb_cleanup.
> * Rename board version of the function board_usb_cleanup to
>   omap_xhci_board_usb_cleanup.
>   Done only for boards that defines CONFIG_USB_XHCI_OMAP.
> 
> Signed-off-by: Uri Mashiach 
> ---
> V1 -> V2: Use __weak instead of attribute block

[...]

> +++ b/board/ti/dra7xx/evm.c
> @@ -727,7 +727,7 @@ static struct ti_usb_phy_device usb_phy2_device = {
>   .index = 1,
>  };
>  
> -int board_usb_init(int index, enum usb_init_type init)
> +int  omap_xhci_board_usb_init(int index, enum usb_init_type init)
  ^
Here's a superfluous space.

>  {
>   enable_usb_clocks(index);
>   switch (index) {
> @@ -764,7 +764,7 @@ int board_usb_init(int index, enum usb_init_type init)
>   return 0;
>  }
>  
> -int board_usb_cleanup(int index, enum usb_init_type init)
> +int omap_xhci_board_usb_cleanup(int index, enum usb_init_type init)
>  {
>   switch (index) {
>   case 0:
> diff --git a/drivers/usb/host/xhci-omap.c b/drivers/usb/host/xhci-omap.c
> index b881b19..a1b4f2f 100644
> --- a/drivers/usb/host/xhci-omap.c
> +++ b/drivers/usb/host/xhci-omap.c
> @@ -27,12 +27,25 @@ DECLARE_GLOBAL_DATA_PTR;
>  
>  static struct omap_xhci omap;
>  
> -__weak int __board_usb_init(int index, enum usb_init_type init)
> +__weak int omap_xhci_board_usb_init(int index, enum usb_init_type init)
>  {
>   return 0;
>  }
> +
>  int board_usb_init(int index, enum usb_init_type init)
> - __attribute__((weak, alias("__board_usb_init")));
> +{
> + return omap_xhci_board_usb_init(index, init);
> +}
> +
> +__weak int omap_xhci_board_usb_cleanup(int index, enum usb_init_type init)
> +{
> + return 0;
> +}
> +
> +int board_usb_cleanup(int index, enum usb_init_type init)
> +{
> + return omap_xhci_board_usb_cleanup(index, init);
> +}
>  
>  static int omap_xhci_core_init(struct omap_xhci *omap)
>  {
> 


Otherwise:
Acked-by: Marek Vasut 

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3 3/3] sunxi: add support for Lichee Pi Zero

2017-02-13 Thread Icenowy Zheng

2017年2月13日 15:17于 Maxime Ripard 写道:
>
> Hi, 
>
> On Sat, Feb 11, 2017 at 07:11:02PM +0800, Icenowy Zheng wrote: 
> > @@ -0,0 +1,13 @@ 
> > +CONFIG_ARM=y 
> > +CONFIG_ARCH_SUNXI=y 
> > +# CONFIG_ARMV7_NONSEC is not set 
>
> Why? It doesn't have Trustzone? 

The CPU has Secure mode, but no TrustZone Peripheral Controller, neither SMP.

>
> Thanks, 
> Maxime 
>
> -- 
> Maxime Ripard, Free Electrons 
> Embedded Linux and Kernel engineering 
> http://free-electrons.com 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 2/6] usb: host: xhci-omap: fix double weak board_usb_init functions

2017-02-13 Thread Tom Rini
On Mon, Feb 13, 2017 at 01:35:40PM +0200, Uri Mashiach wrote:

> A weak version of the function board_usb_init is implemented in:
> common/usb.c
> drivers/usb/host/xhci-omap.c
[snip]
> diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
> index bd1c809..21fa824 100644
> --- a/board/ti/dra7xx/evm.c
> +++ b/board/ti/dra7xx/evm.c
> @@ -727,7 +727,7 @@ static struct ti_usb_phy_device usb_phy2_device = {
>   .index = 1,
>  };
>  
> -int board_usb_init(int index, enum usb_init_type init)
> +int  omap_xhci_board_usb_init(int index, enum usb_init_type init)

Extra space.  Fix that and then:

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] arm: am57xx: Set serial# variable

2017-02-13 Thread Sam Protsenko
serial# variable is used to correctly display device ID in
"fastboot devices". It also can be used further for displaying device ID
in "adb devices" (should be passed as "androidboot.serialno" to kernel
cmdline, via "bootargs" variable).

Serial number generating algorithm is described at [1].

[1] http://lists.denx.de/pipermail/u-boot/2015-March/207462.html

Signed-off-by: Sam Protsenko 
---
 board/ti/am57xx/board.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index 5f2d4dfab8..1611514417 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -487,6 +487,8 @@ int board_late_init(void)
palmas_i2c_write_u8(TPS65903X_CHIP_P1, TPS65903X_PRIMARY_SECONDARY_PAD2,
val);
 
+   omap_die_id_serial();
+
return 0;
 }
 
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] arm: am57xx: Set serial# variable

2017-02-13 Thread Tom Rini
On Mon, Feb 13, 2017 at 07:09:37PM +0200, Sam Protsenko wrote:

> serial# variable is used to correctly display device ID in
> "fastboot devices". It also can be used further for displaying device ID
> in "adb devices" (should be passed as "androidboot.serialno" to kernel
> cmdline, via "bootargs" variable).
> 
> Serial number generating algorithm is described at [1].
> 
> [1] http://lists.denx.de/pipermail/u-boot/2015-March/207462.html
> 
> Signed-off-by: Sam Protsenko 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] omapl138_lcdk: Set uboot raw mmc sector to 0x41

2017-02-13 Thread Tom Rini
On Mon, Feb 13, 2017 at 05:11:09PM +0100, Axel Haslam wrote:
> Hi Tom
> 
> On Mon, Feb 13, 2017 at 3:23 PM, Axel Haslam  wrote:
> > On Mon, Feb 13, 2017 at 3:17 PM, Tom Rini  wrote:
> >> On Mon, Feb 13, 2017 at 03:14:28PM +0100, Axel Haslam wrote:
> >>> Hi Tom
> >>>
> >>> On Mon, Feb 13, 2017 at 2:23 PM, Tom Rini  wrote:
> >>> > On Mon, Feb 13, 2017 at 11:44:57AM +0100, Axel Haslam wrote:
> >>> >> The uboot binary on the AIS file starts at offset 0x8000.
> >>> >> This would be sector 0x40 on a mmc card with 512 bytes per
> >>> >> sector: 0x8000/0x200 = 0x40.
> >>> >>
> >>> >> But because we usually skip the first mmc sector to preserve
> >>> >> the partition table, the ais image is written starting
> >>> >> on sector 0x1, and the u-boot binary ends up at sector 0x41.
> >>> >>
> >>> >> Set the address of the u-boot binary to 0x41 so that spl
> >>> >> can correctly jump to it.
> >>> >>
> >>> >> Signed-off-by: Axel Haslam 
> >>> >> ---
> >>> >>  configs/omapl138_lcdk_defconfig | 2 +-
> >>> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>> >>
> >>> >> diff --git a/configs/omapl138_lcdk_defconfig 
> >>> >> b/configs/omapl138_lcdk_defconfig
> >>> >> index d20af19..a249ebd 100644
> >>> >> --- a/configs/omapl138_lcdk_defconfig
> >>> >> +++ b/configs/omapl138_lcdk_defconfig
> >>> >> @@ -12,7 +12,7 @@ CONFIG_VERSION_VARIABLE=y
> >>> >>  # CONFIG_DISPLAY_BOARDINFO is not set
> >>> >>  CONFIG_BOARD_EARLY_INIT_F=y
> >>> >>  CONFIG_SPL=y
> >>> >> -CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0xb5
> >>> >> +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x41
> >>> >
> >>> > Since we're changing a default here, and one that will lead to
> >>> > non-booting boards if you don't notice, where did the old value come
> >>> > from, and is it actually in use anywhere?  Thanks!
> >>>
> >>> I think the "old offset" would be correct when you copy the AIS image
> >>> to the sd card using the uflash tool from TI. This tool adds some extra
> >>> space at the start of the mmc for UBL configuration settings, which does
> >>> not seem to be needed for the lcdk. The generated AIS image with SPL
> >>> can boot the board directly and we can just copy the resulting AIS
> >>> to the sdcard with the "dd" command.
> >>
> >> Ah yes, that tool.  What is the drive for not being compatible with that
> >> tool in terms of offset?  With binman it should be easy enough to have
> >> U-Boot generate a binary with sufficient padding between items.  Thanks!
> >>
> >
> > Good point.  i will try that instead. Thanks for the tip.
> 
> I looked at how the uflash tool works and it takes as input the AIS
> image, which i think means we would have to have yet another
> type of image specific for mmc that adds the padding.
> 
> An alternative to this would be just to document that to
> write the AIS  image we need to skip 117 sectors, like so:
> 
> sudo dd if=./u-boot.ais of=/dev/mmcblk0 seek=117 bs=512
> 
> this would make u-boot fall into sector 0xb5, which would be
> exactly the same that is uflash ends up writing uboot to, and
> there would be no defconfig changes.
> 
> Would this be acceptable?

Yes, changing the instructions so that we write to the same location as
the TI tool and not need to change the defconfig would be the preferred
approach, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] da850: Add instructions to copy AIS image to an MMC card

2017-02-13 Thread Axel Haslam
The da850 soc's can boot from a external mmc card, but
the AIS image should be written to the correct sector.

Add instructions to copy the AIS image to a MMC card.

Signed-off-by: Axel Haslam 
---
 board/davinci/da8xxevm/README.da850 | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/board/davinci/da8xxevm/README.da850 
b/board/davinci/da8xxevm/README.da850
index 313a1ef..29cb4ec 100644
--- a/board/davinci/da8xxevm/README.da850
+++ b/board/davinci/da8xxevm/README.da850
@@ -47,6 +47,29 @@ U-Boot > sf erase 0 +32
 U-Boot > tftp u-boot.ais
 U-Boot > sf write c070 0 $filesize
 
+Flashing the images to MMC
+==
+If the boot pins are set to boot from mmc, the RBL will try to load the
+next boot stage form the first couple of sectors of an external mmc card.
+As sector 0 is usually used for storing the partition information, the
+AIS image should be written at least after the first sector, but before the
+first partition begins. (e.g: make sure to leave at least 500KB of unallocated
+space at the start of the mmc when creating the partitions)
+
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR is used by SPL, and should
+point to the sector were the u-boot image is located. (eg. After SPL)
+
+There are 2 ways to copy the AIS image to the mmc card:
+
+ 1 - Using the TI tool "uflash"
+   $ uflash -d /dev/mmcblk0  -b ./u-boot.ais -p OMAPL138  -vv
+
+ 2 - using the "dd" command
+   $ dd if=u-boot.ais of=/dev/mmcblk0 seek=117 bs=512 conv=fsync
+
+uflash writes the AIS image at offset 117. For compatibility with uflash,
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR is set to take into account this
+offset, and the dd command is adjusted accordingly.
 
 Recovery
 
-- 
2.9.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v4 2/6] spl: Add option to enable SPL Legacy image support

2017-02-13 Thread Andrew F. Davis
Add a Kconfig option that enables Legacy image support, this allows
boards to explicitly disable this, for instance when needed for
security reasons.

Signed-off-by: Andrew F. Davis 
Reviewed-by: Simon Glass 
---
 Kconfig  |  8 
 common/spl/spl.c | 10 --
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/Kconfig b/Kconfig
index cfc8f929ee..8504199493 100644
--- a/Kconfig
+++ b/Kconfig
@@ -299,6 +299,14 @@ config SPL_RAW_IMAGE_SUPPORT
  is y. If this is not set, SPL will move on to other available
  boot media to find a suitable image.
 
+config SPL_LEGACY_IMAGE_SUPPORT
+   bool "Support SPL loading and booting of Legacy images"
+   default y
+   help
+ SPL will support loading and booting Legacy images when this option
+ is y. If this is not set, SPL will move on to other available
+ boot media to find a suitable image.
+
 config SYS_CLK_FREQ
depends on ARC || ARCH_SUNXI
int "CPU clock frequency"
diff --git a/common/spl/spl.c b/common/spl/spl.c
index da8f55eef6..3d6c0ecba1 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -93,9 +93,10 @@ void spl_set_header_raw_uboot(struct spl_image_info 
*spl_image)
 int spl_parse_image_header(struct spl_image_info *spl_image,
   const struct image_header *header)
 {
-   u32 header_size = sizeof(struct image_header);
-
if (image_get_magic(header) == IH_MAGIC) {
+#ifdef CONFIG_SPL_LEGACY_IMAGE_SUPPORT
+   u32 header_size = sizeof(struct image_header);
+
if (spl_image->flags & SPL_COPY_PAYLOAD_ONLY) {
/*
 * On some system (e.g. powerpc), the load-address and
@@ -118,6 +119,11 @@ int spl_parse_image_header(struct spl_image_info 
*spl_image,
debug("spl: payload image: %.*s load addr: 0x%lx size: %d\n",
(int)sizeof(spl_image->name), spl_image->name,
spl_image->load_addr, spl_image->size);
+#else
+   /* LEGACY image not supported */
+   debug("Legacy boot image support not enabled, proceeding to 
other boot methods");
+   return -EINVAL;
+#endif
} else {
 #ifdef CONFIG_SPL_PANIC_ON_RAW_IMAGE
/*
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v4 3/6] ARM: AM335x: Disable non-FIT based image loading for HS devices

2017-02-13 Thread Andrew F. Davis
Disable support for loading non-FIT images for AM335x platforms using
the high-security (HS) device variant.

Signed-off-by: Andrew F. Davis 
Reviewed-by: Simon Glass 
---
 configs/am335x_hs_evm_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/am335x_hs_evm_defconfig b/configs/am335x_hs_evm_defconfig
index d6224bcdfb..374540906c 100644
--- a/configs/am335x_hs_evm_defconfig
+++ b/configs/am335x_hs_evm_defconfig
@@ -14,6 +14,8 @@ CONFIG_SYS_EXTRA_OPTIONS="NAND"
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
 CONFIG_FIT_IMAGE_POST_PROCESS=y
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+# CONFIG_SPL_LEGACY_IMAGE_SUPPORT is not set
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
 CONFIG_SPL=y
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v4 6/6] ARM: DRA7xx: Disable non-FIT based image loading for HS devices

2017-02-13 Thread Andrew F. Davis
Disable support for loading non-FIT images for DRA7xx platforms using
the high-security (HS) device variant.

Signed-off-by: Andrew F. Davis 
Reviewed-by: Simon Glass 
---
 configs/dra7xx_hs_evm_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/dra7xx_hs_evm_defconfig b/configs/dra7xx_hs_evm_defconfig
index 244940cd6c..c5e7b16c8b 100644
--- a/configs/dra7xx_hs_evm_defconfig
+++ b/configs/dra7xx_hs_evm_defconfig
@@ -15,6 +15,8 @@ CONFIG_FIT=y
 CONFIG_FIT_IMAGE_POST_PROCESS=y
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+# CONFIG_SPL_LEGACY_IMAGE_SUPPORT is not set
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v4 0/6] Allow disabling non-FIT image loading from SPL

2017-02-13 Thread Andrew F. Davis
Hello all,

To address a needed feature brought up by Andreas[0], we need a way to
disable SPL from loading non-FIT images.

The function spl_parse_image_header is common to all SPL loading paths
(common/spl/spl_(nand|net|nor|etc..)) so we add the check here.

This version of the series is a bit different than the last 2 due
to suggestions by Simon, instead of a negative option disabling
non-FIT images, we allow the other image format's support to be
toggled off, and do that on HS boards.

Thanks,
Andrew

[0] https://www.mail-archive.com/u-boot@lists.denx.de/msg219253.html

Changes from v3:
 - Add debug print as suggested by Simon

Andrew F. Davis (6):
  spl: Convert CONFIG_SPL_ABORT_ON_RAW_IMAGE into a positive option
  spl: Add option to enable SPL Legacy image support
  ARM: AM335x: Disable non-FIT based image loading for HS devices
  ARM: AM43xx: Disable non-FIT based image loading for HS devices
  ARM: AM57xx: Disable non-FIT based image loading for HS devices
  ARM: DRA7xx: Disable non-FIT based image loading for HS devices

 Kconfig   | 15 +++
 README|  4 
 common/spl/spl.c  | 20 ++--
 configs/am335x_hs_evm_defconfig   |  2 ++
 configs/am43xx_hs_evm_defconfig   |  2 ++
 configs/am57xx_hs_evm_defconfig   |  2 ++
 configs/dra7xx_hs_evm_defconfig   |  2 ++
 include/configs/imx6_spl.h|  4 ++--
 include/configs/socfpga_de1_soc.h |  2 +-
 include/spl.h |  2 +-
 10 files changed, 41 insertions(+), 14 deletions(-)

-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v4 4/6] ARM: AM43xx: Disable non-FIT based image loading for HS devices

2017-02-13 Thread Andrew F. Davis
Disable support for loading non-FIT images for AM43xx platforms using
the high-security (HS) device variant.

Signed-off-by: Andrew F. Davis 
Reviewed-by: Simon Glass 
---
 configs/am43xx_hs_evm_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/am43xx_hs_evm_defconfig b/configs/am43xx_hs_evm_defconfig
index 8bb1b3535a..fabf876621 100644
--- a/configs/am43xx_hs_evm_defconfig
+++ b/configs/am43xx_hs_evm_defconfig
@@ -10,6 +10,8 @@ CONFIG_FIT=y
 CONFIG_FIT_IMAGE_POST_PROCESS=y
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+# CONFIG_SPL_LEGACY_IMAGE_SUPPORT is not set
 CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=1, NAND"
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v4 1/6] spl: Convert CONFIG_SPL_ABORT_ON_RAW_IMAGE into a positive option

2017-02-13 Thread Andrew F. Davis
CONFIG_SPL_ABORT_ON_RAW_IMAGE causes SPL to abort and move on when it
encounters RAW images, express this same functionality as a positive
option enabling support for RAW images: CONFIG_SPL_RAW_IMAGE_SUPPORT

Signed-off-by: Andrew F. Davis 
---
 Kconfig   |  7 +++
 README|  4 
 common/spl/spl.c  | 10 ++
 include/configs/imx6_spl.h|  4 ++--
 include/configs/socfpga_de1_soc.h |  2 +-
 include/spl.h |  2 +-
 6 files changed, 17 insertions(+), 12 deletions(-)

diff --git a/Kconfig b/Kconfig
index 81b4226463..cfc8f929ee 100644
--- a/Kconfig
+++ b/Kconfig
@@ -291,6 +291,13 @@ config SYS_TEXT_BASE
help
  TODO: Move CONFIG_SYS_TEXT_BASE for all the architecture
 
+config SPL_RAW_IMAGE_SUPPORT
+   bool "Support SPL loading and booting of RAW images"
+   default y
+   help
+ SPL will support loading and booting a RAW image when this option
+ is y. If this is not set, SPL will move on to other available
+ boot media to find a suitable image.
 
 config SYS_CLK_FREQ
depends on ARC || ARCH_SUNXI
diff --git a/README b/README
index 4f0dbd4fca..a45c6b88bf 100644
--- a/README
+++ b/README
@@ -3279,10 +3279,6 @@ FIT uImage format:
consider that a completely unreadable NAND block is bad,
and thus should be skipped silently.
 
-   CONFIG_SPL_ABORT_ON_RAW_IMAGE
-   When defined, SPL will proceed to another boot method
-   if the image it has loaded does not have a signature.
-
CONFIG_SPL_RELOC_STACK
Adress of the start of the stack SPL will use after
relocation.  If unspecified, this is equal to
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 766fb3d6f4..da8f55eef6 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -146,16 +146,18 @@ int spl_parse_image_header(struct spl_image_info 
*spl_image,
}
 #endif
 
-#ifdef CONFIG_SPL_ABORT_ON_RAW_IMAGE
-   /* Signature not found, proceed to other boot methods. */
-   return -EINVAL;
-#else
+#ifdef CONFIG_SPL_RAW_IMAGE_SUPPORT
/* Signature not found - assume u-boot.bin */
debug("mkimage signature not found - ih_magic = %x\n",
header->ih_magic);
spl_set_header_raw_uboot(spl_image);
+#else
+   /* RAW image not supported, proceed to other boot methods. */
+   debug("Raw boot image support not enabled, proceeding to other 
boot methods");
+   return -EINVAL;
 #endif
}
+
return 0;
 }
 
diff --git a/include/configs/imx6_spl.h b/include/configs/imx6_spl.h
index c5a035fccf..acaf81b6b9 100644
--- a/include/configs/imx6_spl.h
+++ b/include/configs/imx6_spl.h
@@ -45,14 +45,14 @@
 #if defined(CONFIG_SPL_MMC_SUPPORT)
 #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1
 #define CONFIG_SYS_MONITOR_LEN 409600  /* 400 KB */
-#define CONFIG_SPL_ABORT_ON_RAW_IMAGE
+#undef CONFIG_SPL_RAW_IMAGE_SUPPORT
 #endif
 
 /* SATA support */
 #if defined(CONFIG_SPL_SATA_SUPPORT)
 #define CONFIG_SPL_SATA_BOOT_DEVICE0
 #define CONFIG_SYS_SATA_FAT_BOOT_PARTITION 1
-#define CONFIG_SPL_ABORT_ON_RAW_IMAGE
+#undef CONFIG_SPL_RAW_IMAGE_SUPPORT
 #endif
 
 /* Define the payload for FAT/EXT support */
diff --git a/include/configs/socfpga_de1_soc.h 
b/include/configs/socfpga_de1_soc.h
index 2278357fc6..6f5506f542 100644
--- a/include/configs/socfpga_de1_soc.h
+++ b/include/configs/socfpga_de1_soc.h
@@ -50,6 +50,6 @@
 /* The rest of the configuration is shared */
 #include 
 
-#define CONFIG_SPL_ABORT_ON_RAW_IMAGE
+#undef CONFIG_SPL_RAW_IMAGE_SUPPORT
 
 #endif /* __CONFIG_TERASIC_DE1_SOC_H__ */
diff --git a/include/spl.h b/include/spl.h
index bde44374ea..270798c988 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -85,7 +85,7 @@ void spl_set_header_raw_uboot(struct spl_image_info 
*spl_image);
  * This parses the legacy image header information at @header and sets up
  * @spl_image according to what is found. If no image header is found, then
  * a raw image or bootz is assumed. If CONFIG_SPL_PANIC_ON_RAW_IMAGE is
- * enabled, then this causes a panic. If CONFIG_SPL_ABORT_ON_RAW_IMAGE is
+ * enabled, then this causes a panic. If CONFIG_SPL_RAW_IMAGE_SUPPORT is not
  * enabled then U-Boot gives up. Otherwise U-Boot sets up the image using
  * spl_set_header_raw_uboot(), or possibly the bootz header.
  *
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v4 5/6] ARM: AM57xx: Disable non-FIT based image loading for HS devices

2017-02-13 Thread Andrew F. Davis
Disable support for loading non-FIT images for AM57xx platforms using
the high-security (HS) device variant.

Signed-off-by: Andrew F. Davis 
Reviewed-by: Simon Glass 
---
 configs/am57xx_hs_evm_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/am57xx_hs_evm_defconfig b/configs/am57xx_hs_evm_defconfig
index 7e84ccddf3..4adbde427b 100644
--- a/configs/am57xx_hs_evm_defconfig
+++ b/configs/am57xx_hs_evm_defconfig
@@ -14,6 +14,8 @@ CONFIG_FIT=y
 CONFIG_FIT_IMAGE_POST_PROCESS=y
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+# CONFIG_SPL_LEGACY_IMAGE_SUPPORT is not set
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [RFC PATCH] mmc: omap_hsmmc: convert to use dm block devies

2017-02-13 Thread Grygorii Strashko


On 02/10/2017 10:21 AM, Simon Glass wrote:
> Hi,
> 
> On 2 February 2017 at 15:18, Grygorii Strashko  
> wrote:
>>
>> Convert OMAP hsmmc driver to use driver-model block devices.
>>
>> Signed-off-by: Grygorii Strashko 
>> ---
>> Hi All,
>>
>> First of all, sorry if my questions/problems are looks dumb, I'm very new 
>> with u-boot.
>>
>> This is my attampt to enable CONFIG_BLK on OMAP platforms which is blocked 
>> now
>> by omap_hsmmc driver. omap_hsmmc required to be updated to use driver-model 
>> block
>> devices at minimum (and max to use dm_mmc_ops). Also, as per my 
>> understanding,
>> CONFIG_BLK is blocker for other tasks like enabling driver model for OMAP 
>> sata devices.
>>
>> With this patch I can boot from mmc on am335x-evm, but there are
>> two problems I need help with:
>> 1) My changes in Makefiles looks really ugly, but without them SPL build will
>>   fail because undef'ing in include/configs/am335x_evm.h does not take effect
>>   in Makefile (thanks Vignesh for the information [1]) and I, honestly, do 
>> not
>>   know how to fix it in better way, so I'd be appreciated for any help.
>>   Comparing to Vignesh's case, files which need to be excluded from build
>>   are generic and I worry that there can be dependecy from CONFIG_SPL_DM.
> 
> It would be great to enable CONFIG_BLK and CONFIG_DM_MMC in SPL.
> Perhaps Tom's message (later in this thread) about the gcc bug might
> help. The size difference is small, but not 0 unfortunately.
> 
>>
>> 2) with this patch I can see error message in log "** Bad device size - mmc 
>> 0 **":
>> U-Boot 2017.03-rc1-00020-g1a3b11a-dirty (Feb 02 2017 - 12:04:01 -0600)
>>
>> CPU  : AM335X-GP rev 2.0
>> Model: TI AM335x EVM
>> DRAM:  1 GiB
>> NAND:  256 MiB
>> MMC:   mmc@4806mmc@4781OMAP SD/MMC: 0, OMAP SD/MMC: 1
>> ** Bad device size - mmc 0 **
>> Using default environment
>>
>> this message is triggered from:
>> board_r.c: initr_env()
>> - env_common.c: env_relocate()
>>  - env_fat.c: env_relocate_spec()
>>   - part.c: blk_get_device_part_str()
>> because partitions are not initialized yet, as i understood,
>>
>> Seems there are should be additional call to 
>> mmc_init():mmc_startup():part_init(),
>> but I'm not sure where/how to add it correctly.
> 
> Does this help?
> 
> http://patchwork.ozlabs.org/patch/717710/
> 

It seems like issue with "Bad device size..." was fixed
by patch "mmc: init mmc block devices on probe" [1].

This patch (my patch) with your patch [2] cause boot hang on am335x-evm when
mmc1 (mmc3 in DT) is probed (i've tried to revert [1] - result is the same).


[1] https://patchwork.ozlabs.org/patch/719652/
[2] http://patchwork.ozlabs.org/patch/717710/


-- 
regards,
-grygorii
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v6 1/2] gpio: at91_gpio: Remove CPU_HAS_PIO3 macro

2017-02-13 Thread Andreas Bießmann
Dear Wenyou,

On 13.02.17 03:07, Wenyou Yang wrote:
> The intention of this patch is the preparation to introduce
> the pinctrl driver for AT91 PIO.
> 
> Use "union" to make the PIO3 and PIO2's registers be together
> and make their offset aligned.

unfortunately there is another breakage in this patch I was not able to
discover yesterday. The at91_emac driver for at91rm9200 devices uses the
pio struct internally and therefore this patch also breaks the build for
at91rm9200.

Could you please also fix this?

Andreas

> 
> Signed-off-by: Wenyou Yang 
> ---
> 
> Changes in v6:
>  - Move PIO_SCDR_DIV define from mach/ to mach/at91_pio.h
>to fix the build error.
> 
> Changes in v5: None
> Changes in v4:
>  - Fix the incomplete conversion of the peripheral configurations on
>the sama5d3, sam9x5, and sam9n12.
> 
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/mach-at91/arm926ejs/at91sam9n12_devices.c | 106 ++--
>  arch/arm/mach-at91/arm926ejs/at91sam9x5_devices.c  | 112 ++---
>  arch/arm/mach-at91/armv7/sama5d3_devices.c | 140 
>  arch/arm/mach-at91/include/mach/at91_pio.h |  63 
>  arch/arm/mach-at91/include/mach/at91sam9x5.h   |   2 -
>  arch/arm/mach-at91/include/mach/sama5d3.h  |   2 -
>  arch/arm/mach-at91/include/mach/sama5d4.h  |   2 -
>  board/atmel/at91sam9n12ek/at91sam9n12ek.c  |  10 +-
>  board/atmel/at91sam9x5ek/at91sam9x5ek.c|  90 +--
>  board/atmel/sama5d3xek/sama5d3xek.c|  64 
>  board/atmel/sama5d4_xplained/sama5d4_xplained.c| 148 -
>  board/atmel/sama5d4ek/sama5d4ek.c  | 136 
>  board/denx/ma5d4evk/ma5d4evk.c | 178 
> ++---
>  board/l+g/vinco/vinco.c|  70 
>  drivers/gpio/at91_gpio.c   | 142 ++--
>  15 files changed, 658 insertions(+), 607 deletions(-)
> 
> diff --git a/arch/arm/mach-at91/arm926ejs/at91sam9n12_devices.c 
> b/arch/arm/mach-at91/arm926ejs/at91sam9n12_devices.c
> index a03abfc310..28c8cf260a 100644
> --- a/arch/arm/mach-at91/arm926ejs/at91sam9n12_devices.c
> +++ b/arch/arm/mach-at91/arm926ejs/at91sam9n12_devices.c
> @@ -18,45 +18,45 @@ unsigned int has_lcdc()
>  
>  void at91_serial0_hw_init(void)
>  {
> - at91_set_a_periph(AT91_PIO_PORTA, 0, 1);/* TXD0 */
> - at91_set_a_periph(AT91_PIO_PORTA, 1, 0);/* RXD0 */
> + at91_pio3_set_a_periph(AT91_PIO_PORTA, 0, 1);   /* TXD0 */
> + at91_pio3_set_a_periph(AT91_PIO_PORTA, 1, 0);   /* RXD0 */
>   at91_periph_clk_enable(ATMEL_ID_USART0);
>  }
>  
>  void at91_serial1_hw_init(void)
>  {
> - at91_set_a_periph(AT91_PIO_PORTA, 5, 1);/* TXD1 */
> - at91_set_a_periph(AT91_PIO_PORTA, 6, 0);/* RXD1 */
> + at91_pio3_set_a_periph(AT91_PIO_PORTA, 5, 1);   /* TXD1 */
> + at91_pio3_set_a_periph(AT91_PIO_PORTA, 6, 0);   /* RXD1 */
>   at91_periph_clk_enable(ATMEL_ID_USART1);
>  }
>  
>  void at91_serial2_hw_init(void)
>  {
> - at91_set_a_periph(AT91_PIO_PORTA, 7, 1);/* TXD2 */
> - at91_set_a_periph(AT91_PIO_PORTA, 8, 0);/* RXD2 */
> + at91_pio3_set_a_periph(AT91_PIO_PORTA, 7, 1);   /* TXD2 */
> + at91_pio3_set_a_periph(AT91_PIO_PORTA, 8, 0);   /* RXD2 */
>   at91_periph_clk_enable(ATMEL_ID_USART2);
>  }
>  
>  void at91_serial3_hw_init(void)
>  {
> - at91_set_b_periph(AT91_PIO_PORTC, 22, 1);   /* TXD3 */
> - at91_set_b_periph(AT91_PIO_PORTC, 23, 0);   /* RXD3 */
> + at91_pio3_set_b_periph(AT91_PIO_PORTC, 22, 1);  /* TXD3 */
> + at91_pio3_set_b_periph(AT91_PIO_PORTC, 23, 0);  /* RXD3 */
>   at91_periph_clk_enable(ATMEL_ID_USART3);
>  }
>  
>  void at91_seriald_hw_init(void)
>  {
> - at91_set_a_periph(AT91_PIO_PORTA, 10, 1);   /* DTXD */
> - at91_set_a_periph(AT91_PIO_PORTA, 9, 0);/* DRXD */
> + at91_pio3_set_a_periph(AT91_PIO_PORTA, 10, 1);  /* DTXD */
> + at91_pio3_set_a_periph(AT91_PIO_PORTA, 9, 0);   /* DRXD */
>   at91_periph_clk_enable(ATMEL_ID_SYS);
>  }
>  
>  #ifdef CONFIG_ATMEL_SPI
>  void at91_spi0_hw_init(unsigned long cs_mask)
>  {
> - at91_set_a_periph(AT91_PIO_PORTA, 11, 0);   /* SPI0_MISO */
> - at91_set_a_periph(AT91_PIO_PORTA, 12, 0);   /* SPI0_MOSI */
> - at91_set_a_periph(AT91_PIO_PORTA, 13, 0);   /* SPI0_SPCK */
> + at91_pio3_set_a_periph(AT91_PIO_PORTA, 11, 0);  /* SPI0_MISO */
> + at91_pio3_set_a_periph(AT91_PIO_PORTA, 12, 0);  /* SPI0_MOSI */
> + at91_pio3_set_a_periph(AT91_PIO_PORTA, 13, 0);  /* SPI0_SPCK */
>  
>   at91_periph_clk_enable(ATMEL_ID_SPI0);
>  
> @@ -72,9 +72,9 @@ void at91_spi0_hw_init(unsigned long cs_mask)
>  
>  void at91_spi1_hw_init(unsigned long cs_m

Re: [U-Boot] [PATCH v9 0/2] SPL: Add support to boot a partition type

2017-02-13 Thread Dalon Westergreen
On Sat, 2017-02-11 at 04:41 +0100, Marek Vasut wrote:
> On 02/11/2017 02:15 AM, Dalon Westergreen wrote:
> > 
> > This adds support for the spl to seach for and boot from an arbitrary
> > partition type rather then a specific partition number.  When
> > USE_PARTITION_TYPE is enabled, spl will search for the partition type but
> > fallback to the specified partition number.
> >  
> > SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION is moved to a Kconfig and header and
> > defconfigs for the affected boards are updated.
> > 
> > Changes in v9:
> >  - Missed moving use partition type to socfpga/Kconfig
> > Changes in v8:
> >  -> Move partition type default to arch/arm/mach-socfpga/Kconfig
> > Changes in v7:
> >  -> set part type to 0xa2 only if socfpga selected and merge previously
> > split
> > patch
> > Changes in V6:
> >  -> Fix unneeded backslash
> >  -> Move SPL socfpga Kconfig default to selec tin arch/arm/Kconfig
> >  -> Split out defconfig changes for affected boards into a separate patch
> > 
> > Dalon Westergreen (2):
> >   SPL: add support to boot from a partition type
> >   SPL: Move SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION to Kconfig
> > 
> >  arch/arm/Kconfig |  1 +
> >  common/spl/Kconfig   | 32 
> >  common/spl/spl_mmc.c | 27 ++-
> >  configs/db-88f6820-gp_defconfig  |  1 +
> >  configs/kc1_defconfig|  2 ++
> >  configs/sniper_defconfig |  2 ++
> >  disk/part_dos.c  |  1 +
> >  include/configs/db-88f6820-gp.h  |  1 -
> >  include/configs/kc1.h|  2 --
> >  include/configs/sniper.h |  2 --
> >  include/configs/socfpga_common.h |  2 --
> >  include/part.h   |  3 +++
> >  12 files changed, 60 insertions(+), 16 deletions(-)
> > 
> 
> Series
> Acked-by: Marek Vasut 

Thanks.  I am still not 100% sure on the etiquette at this point.  Is
any further action required on my parT?

Dalon

> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


  1   2   >