Re: [U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Pavel Machek]

(Please, trim your emails when replying)

On Mon 2015-12-14 01:58:04, Marek Vasut wrote:
> On Monday, December 14, 2015 at 01:43:58 AM, Chin Liang See wrote:
> > On Mon, 2015-12-14 at 01:22 +0100, Marek Vasut wrote:
> > > On Monday, December 14, 2015 at 01:11:27 AM, Chin Liang See wrote:
> > > > On Sun, 2015-12-13 at 16:42 +0100, Marek Vasut wrote:
> > > > > On Sunday, December 13, 2015 at 02:03:02 PM, Chin Liang See

> > After grabbing a coffee
> 
> That's a good idea, though I think I will make do with a green tea (抹茶).
> 
> > and rethinking, we can have 2 MTD_PARTITION
> > where one for backward compatiblity (supporting raw) while another for
> > UBI.
> > 
> > MTDPARTS_RAW
> > 256k(spl),
> > 256k(env),
> > 15872k(boot),
> > -(rootfs)
> > 
> > MTDPARTS_UBI
> > 256k(spl),
> > 256k(env),
> > -(UBI)
> > 
> > We should make UBI as default then. If user care about backward
> > compatiblity, they shall use the MTDPARTS_RAW then.
> 
> Try this:
> 
> mtdparts=1m(u-boot),256k(env1),256k(env2),14848k(boot),112m(root),-@1536k(UBI)
> 
> This will create overlapping partitions "boot,root" and "UBI" .

Just because you can does not mean that you should. This looks like a
nasty trap for a user.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARMv7 MMU shareability issue

[Pavel Machek]

Hi!

> This patch has several effects:
> 
> - it selects proper ARMv7 translation table level 1 bit definitions;
> - it provides proper ARMv7 definitions for WT/WB/WA;
> - it selects proper ARMv7 settings for TTBR0.
> 
> All these are correct as per the docs I have (although I may have missed
> something during the readings (and cross-readings with Marek) of these
> last hours/days.
> 
> Now, one specific effect goes against performance, and it is the
> setting of bit S in all TT entries. This bit makes the corresponding
> region shareable, but for all I know, in U-Boot we don't have more than
> one core accessing the same memory or registers sets so -- at least for
> the major part of its execution -- there is no reason for any region to
> be shareable.

Well, I'm currently working on AMP patch, which will mean two
processors at the same time in u-boot.

Also... we provide memory modify operations for the user. User may
be trying to communicate with second core.

> /That/ effect I certainly don't want.

How big is the slowdown from S bit?

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/5] spi: Use mode instead of op_mode_tx

[Jagan Teki]

Hi Bin,

On Monday 14 December 2015 01:04 PM, Bin Meng wrote:

On Mon, Dec 14, 2015 at 2:57 PM, Jagan Teki  wrote:

Used mode member from spi_slave{} instead of op_mode_tx.

Cc: Bin Meng 
Cc: Simon Glass 
Signed-off-by: Jagan Teki 
---
Changes for v2:
 - none

  drivers/mtd/spi/sf_probe.c  | 2 +-
  drivers/mtd/spi/spi_flash.c | 4 ++--
  drivers/spi/ich.c   | 2 +-
  include/spi.h   | 8 ++--
  4 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index 0cafc29..3519ffd 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -128,7 +128,7 @@ static int spi_flash_std_write(struct udevice *dev, u32 
offset, size_t len,

  #if defined(CONFIG_SPI_FLASH_SST)
 if (flash->flags & SNOR_F_SST_WR) {
-   if (flash->spi->op_mode_tx & SPI_OPM_TX_BP)
+   if (flash->spi->mode & SPI_TX_BP)
 return sst_write_bp(flash, offset, len, buf);
 else
 return sst_write_wp(flash, offset, len, buf);
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 30a381b..836aad9 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -968,7 +968,7 @@ int spi_flash_scan(struct spi_flash *flash)
 flash->write = spi_flash_cmd_write_ops;
  #if defined(CONFIG_SPI_FLASH_SST)
 if (flash->flags & SNOR_F_SST_WR) {
-   if (spi->op_mode_tx & SPI_OPM_TX_BP)
+   if (spi->mode & SPI_TX_BP)
 flash->write = sst_write_bp;
 else
 flash->write = sst_write_wp;
@@ -1042,7 +1042,7 @@ int spi_flash_scan(struct spi_flash *flash)
 }

 /* Not require to look for fastest only two write cmds yet */
-   if (params->flags & WR_QPP && spi->op_mode_tx & SPI_OPM_TX_QPP)
+   if (params->flags & WR_QPP && spi->mode & SPI_TX_QPP)
 flash->write_cmd = CMD_QUAD_PAGE_PROGRAM;
 else
 /* Go for default supported write cmd */
diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c
index f85af9c..64322dd 100644
--- a/drivers/spi/ich.c
+++ b/drivers/spi/ich.c
@@ -753,7 +753,7 @@ static int ich_spi_child_pre_probe(struct udevice *dev)
  */
 if (plat->ich_version == 7) {
 slave->op_mode_rx = SPI_OPM_RX_AS;
-   slave->op_mode_tx = SPI_OPM_TX_BP;
+   slave->mode = SPI_TX_BP;
 }

 return 0;
diff --git a/include/spi.h b/include/spi.h
index 713bab9..2b36c5a 100644
--- a/include/spi.h
+++ b/include/spi.h
@@ -23,6 +23,8 @@
  #defineSPI_LOOP0x20/* loopback mode */
  #defineSPI_SLAVE   0x40/* slave mode */
  #defineSPI_PREAMBLE0x80/* Skip preamble bytes 
*/
+#define SPI_TX_BP  0x100   /* transmit with 1 wire byte */
+#define SPI_TX_QPP 0x200   /* transmit with 4 wires */

  /* SPI transfer flags */
  #define SPI_XFER_BEGIN 0x01/* Assert CS before transfer */
@@ -32,10 +34,6 @@
  #define SPI_XFER_ONCE  (SPI_XFER_BEGIN | SPI_XFER_END)
  #define SPI_XFER_U_PAGE(1 << 5)

-/* SPI TX operation modes */
-#define SPI_OPM_TX_QPP (1 << 0)
-#define SPI_OPM_TX_BP  (1 << 1)
-
  /* SPI RX operation modes */
  #define SPI_OPM_RX_AS  (1 << 0)
  #define SPI_OPM_RX_AF  (1 << 1)


And what about RX mode flags? Do you have plan to merge op_mode_rx
into spi->mode as well?


Tried the same but for rx there is simple algo for finding fastest read 
using fls, so that fls in-deed need rx as separate member.


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

Re: [U-Boot] [PATCH 4/7] lib: Split panic functions out of vsprintf.c

[Sjoerd Simons]

On Sun, 2015-12-13 at 20:45 -0700, Simon Glass wrote:
> On 8 December 2015 at 12:38, Simon Glass  wrote:
> > Hi Scott,
> > 
> > On 8 December 2015 at 12:36, Scott Wood 
> > wrote:
> > > On Tue, 2015-12-08 at 12:34 -0700, Simon Glass wrote:
> > > > Hi Sjoerd,
> > > > 
> > OK, so how about this:
> > 
> > > > ifdef CONFIG_SPL_BUILD
> > > > # SPL U-Boot may use full-printf, tiny-printf or none at all
> > 
> > obj-$(CONFIG_SPL_SERIAL_SUPPORT) += panic.o strto.o
> > 
> > > > ifdef CONFIG_USE_TINY_PRINTF
> > obj-$(CONFIG_SPL_SERIAL_SUPPORT) += tiny-printf.o
> > > > else
> > obj-$(CONFIG_SPL_SERIAL_SUPPORT) += vsprintf.o
> > > > endif
> > > > else
> > > > # Main U-Boot always uses the full printf support
> > > > obj-y += vsprintf.o panic.o strto.o
> > > > endif
> 
> It's just a nit so I'm going to leave it as is for now.
> 
> Applied to u-boot-rockchip, thanks!

Heh, i just did an update series last night to send this morning :)
lovely timing.

I'll drop you some patches for these nits later this week while i still
remember them :) (I agree your suggestion here is nicer).


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

Re: [U-Boot] [PATCH 00/11] Add support for Synology DS414 and some related fixes

[Stefan Roese]

Hi Phil,

(added Luka to Cc)

On 13.12.2015 01:29, Phil Sutter wrote:

This patch series ultimately adds support for Synology DS414 NAS after a
few fixes:
* Patches 1-3 and 5 fix various files for enabled debugging.
* Patch 4 updates the board porting guide in README file.
* Patches 6-8 hold crucial fixes necessary for DS414 support.
* Patches 9 and 10 contain the actual board support, split into a generic
   part for MV78230 SoC and a board specific part for clarity.
* Patch 11 adds a new command to deal with Synology specialties.

In case you would like me to split this into multiple series, just let me
know and I will resend.


Very nice to see other Armada XP based boards getting supported
in mainline U-Boot. I'm currently also working on a new XP board
based on the MV78260. And stumbled over a few of the problems
you have met in your Armada XP support as well.

Since I'm currently preparing a new patchset for all this,
including the full DM SPL support as well, perhaps it would
be best, if you base your MV78230 work in top of my new
patches. I will send the new patches to the list later today.
And will also publish a git branch for easier work with it.
Since there are some dependencies with other patches as well.

BTW: With this work you should be able to drop all those
"non-DM" patches from your series.

Thanks,
Stefan

PS: Please keep Luka and me on Cc on all mvebu related patches.

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

Re: [U-Boot] [PATCH v2 3/5] spi: Use mode instead of op_mode_tx

[Jagan Teki]

On Monday 14 December 2015 01:01 PM, Bin Meng wrote:

Hi Jagan,

On Mon, Dec 14, 2015 at 2:57 PM, Jagan Teki  wrote:

Used mode member from spi_slave{} instead of op_mode_tx.

Cc: Bin Meng 
Cc: Simon Glass 
Signed-off-by: Jagan Teki 
---
Changes for v2:
 - none

  drivers/mtd/spi/sf_probe.c  | 2 +-
  drivers/mtd/spi/spi_flash.c | 4 ++--
  drivers/spi/ich.c   | 2 +-
  include/spi.h   | 8 ++--
  4 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index 0cafc29..3519ffd 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -128,7 +128,7 @@ static int spi_flash_std_write(struct udevice *dev, u32 
offset, size_t len,

  #if defined(CONFIG_SPI_FLASH_SST)
 if (flash->flags & SNOR_F_SST_WR) {
-   if (flash->spi->op_mode_tx & SPI_OPM_TX_BP)
+   if (flash->spi->mode & SPI_TX_BP)


Did you ever build this? spi->mode is declared as a u8, but SPI_TX_BP is 0x100.


Look like I sent the wrong patch, I made mode as uint will send that.

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

Re: [U-Boot] [PATCH v2 3/5] spi: Use mode instead of op_mode_tx

[Bin Meng]

On Mon, Dec 14, 2015 at 2:57 PM, Jagan Teki  wrote:
> Used mode member from spi_slave{} instead of op_mode_tx.
>
> Cc: Bin Meng 
> Cc: Simon Glass 
> Signed-off-by: Jagan Teki 
> ---
> Changes for v2:
> - none
>
>  drivers/mtd/spi/sf_probe.c  | 2 +-
>  drivers/mtd/spi/spi_flash.c | 4 ++--
>  drivers/spi/ich.c   | 2 +-
>  include/spi.h   | 8 ++--
>  4 files changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
> index 0cafc29..3519ffd 100644
> --- a/drivers/mtd/spi/sf_probe.c
> +++ b/drivers/mtd/spi/sf_probe.c
> @@ -128,7 +128,7 @@ static int spi_flash_std_write(struct udevice *dev, u32 
> offset, size_t len,
>
>  #if defined(CONFIG_SPI_FLASH_SST)
> if (flash->flags & SNOR_F_SST_WR) {
> -   if (flash->spi->op_mode_tx & SPI_OPM_TX_BP)
> +   if (flash->spi->mode & SPI_TX_BP)
> return sst_write_bp(flash, offset, len, buf);
> else
> return sst_write_wp(flash, offset, len, buf);
> diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
> index 30a381b..836aad9 100644
> --- a/drivers/mtd/spi/spi_flash.c
> +++ b/drivers/mtd/spi/spi_flash.c
> @@ -968,7 +968,7 @@ int spi_flash_scan(struct spi_flash *flash)
> flash->write = spi_flash_cmd_write_ops;
>  #if defined(CONFIG_SPI_FLASH_SST)
> if (flash->flags & SNOR_F_SST_WR) {
> -   if (spi->op_mode_tx & SPI_OPM_TX_BP)
> +   if (spi->mode & SPI_TX_BP)
> flash->write = sst_write_bp;
> else
> flash->write = sst_write_wp;
> @@ -1042,7 +1042,7 @@ int spi_flash_scan(struct spi_flash *flash)
> }
>
> /* Not require to look for fastest only two write cmds yet */
> -   if (params->flags & WR_QPP && spi->op_mode_tx & SPI_OPM_TX_QPP)
> +   if (params->flags & WR_QPP && spi->mode & SPI_TX_QPP)
> flash->write_cmd = CMD_QUAD_PAGE_PROGRAM;
> else
> /* Go for default supported write cmd */
> diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c
> index f85af9c..64322dd 100644
> --- a/drivers/spi/ich.c
> +++ b/drivers/spi/ich.c
> @@ -753,7 +753,7 @@ static int ich_spi_child_pre_probe(struct udevice *dev)
>  */
> if (plat->ich_version == 7) {
> slave->op_mode_rx = SPI_OPM_RX_AS;
> -   slave->op_mode_tx = SPI_OPM_TX_BP;
> +   slave->mode = SPI_TX_BP;
> }
>
> return 0;
> diff --git a/include/spi.h b/include/spi.h
> index 713bab9..2b36c5a 100644
> --- a/include/spi.h
> +++ b/include/spi.h
> @@ -23,6 +23,8 @@
>  #defineSPI_LOOP0x20/* loopback mode */
>  #defineSPI_SLAVE   0x40/* slave mode */
>  #defineSPI_PREAMBLE0x80/* Skip preamble 
> bytes */
> +#define SPI_TX_BP  0x100   /* transmit with 1 wire byte 
> */
> +#define SPI_TX_QPP 0x200   /* transmit with 4 wires */
>
>  /* SPI transfer flags */
>  #define SPI_XFER_BEGIN 0x01/* Assert CS before transfer */
> @@ -32,10 +34,6 @@
>  #define SPI_XFER_ONCE  (SPI_XFER_BEGIN | SPI_XFER_END)
>  #define SPI_XFER_U_PAGE(1 << 5)
>
> -/* SPI TX operation modes */
> -#define SPI_OPM_TX_QPP (1 << 0)
> -#define SPI_OPM_TX_BP  (1 << 1)
> -
>  /* SPI RX operation modes */
>  #define SPI_OPM_RX_AS  (1 << 0)
>  #define SPI_OPM_RX_AF  (1 << 1)

And what about RX mode flags? Do you have plan to merge op_mode_rx
into spi->mode as well?

> @@ -107,7 +105,6 @@ struct dm_spi_slave_platdata {
>   * @cs:ID of the chip select connected to the slave.
>   * @mode:  SPI mode to use for this slave (see SPI mode flags)
>   * @op_mode_rx:SPI RX operation mode.
> - * @op_mode_tx:SPI TX operation mode.
>   * @wordlen:   Size of SPI word in number of bits
>   * @max_write_size:If non-zero, the maximum number of bytes which can
>   * be written at once, excluding command bytes.
> @@ -126,7 +123,6 @@ struct spi_slave {
>  #endif
> u8 mode;
> u8 op_mode_rx;
> -   u8 op_mode_tx;
> unsigned int wordlen;
> unsigned int max_write_size;
> void *memory_map;
> --

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

Re: [U-Boot] [PATCH 1/2] microblaze: spl: Do not call mem_malloc_init and use early alloc

[Michal Simek]

On 14.12.2015 04:47, Simon Glass wrote:
> Hi Michal,
> 
> On 3 February 2015 at 08:39, Michal Simek  wrote:
>>
>> This patch has some parts connected together:
>> - Use _gd in bss section which is automatically cleared
>>   Location at SPL_MALLOC_END wasn't cleared at all
>> - Use MALLOC_F_LEN(early alloc) instead of FULL MALLOC
>>   (mem_malloc_init is not called at all)
>> - Simplify malloc and stack init.
>>   At the end of SPL addr is malloc area and below is stack
>>
>> Signed-off-by: Michal Simek 
>> ---
>>
>>  arch/microblaze/cpu/start.S  |  6 +-
>>  include/configs/microblaze-generic.h | 32 +++-
>>  2 files changed, 16 insertions(+), 22 deletions(-)
>>
>> diff --git a/arch/microblaze/cpu/start.S b/arch/microblaze/cpu/start.S
>> index cf9ee7e3e6ad..953d3a15eef2 100644
>> --- a/arch/microblaze/cpu/start.S
>> +++ b/arch/microblaze/cpu/start.S
>> @@ -162,7 +162,11 @@ clear_bss:
>>  #endif
>> braiboard_init_f
>>  #else
>> -   addir31, r0, CONFIG_SYS_SPL_MALLOC_END
>> +   addir31, r0, _gd
>> +#if defined(CONFIG_SYS_MALLOC_F_LEN)
>> +   addir6, r0, CONFIG_SPL_STACK_ADDR
>> +   swi r6, r31, GD_MALLOC_BASE
>> +#endif
>> braiboard_init_r
>>  #endif
>>  1: bri 1b
>> diff --git a/include/configs/microblaze-generic.h 
>> b/include/configs/microblaze-generic.h
>> index 770acbea691b..166ab4f05654 100644
>> --- a/include/configs/microblaze-generic.h
>> +++ b/include/configs/microblaze-generic.h
>> @@ -113,7 +113,12 @@
>>  #endif
>>
>>  #define CONFIG_SYS_MALLOC_LEN  0xC
>> -#define CONFIG_SYS_MALLOC_F_LEN1024
>> +#ifndef CONFIG_SPL_BUILD
>> +# define CONFIG_SYS_MALLOC_F_LEN   1024
>> +#else
>> +# define CONFIG_SYS_MALLOC_SIMPLE
>> +# define CONFIG_SYS_MALLOC_F_LEN   0x150
>> +#endif
> 
> These should be set via Kconfig - e.g. default values for your arch,
> or perhaps individual values in the defconfig files. At present this
> breaks when driver model is enabled by default.
> 
> Can you please take a look?
> 

Already did. Here is follow up patch.

http://lists.denx.de/pipermail/u-boot/2015-December/237468.html

Thanks,
Michal

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

Re: [U-Boot] [RFC V1] arm: config: enforce -fno-pic for gcc

[Peng Fan]

Hi Albert,

Do you have any comments on this patch?

Regards,
Peng.

On Sat, Dec 05, 2015 at 03:53:46PM +0800, Peng Fan wrote:
>Android's tool chain enable the -mandroid at default.
>This option will enable the -fpic, which cause uboot compilation
>failure:
>"
> LD  u-boot
> u-boot contains unexpected relocations: R_ARM_ABS32
> R_ARM_RELATIVE
>"
>
>In my testcase, arm-linux-androideabi-gcc-4.9 internally
>enables '-fpic', so when compiling code, there will be
>relocation entries using type R_ARM_GOT_BREL and .got
>section. When linking all the built-in.o using ld, there
>will be R_ARM_ABS32 relocation entry and .got section
>in the final u-boot elf image. This can not be handled
>by u-boot, since u-boot only expects R_ARM_RELATIVE
>relocation entry.
>arm-poky-linux-gnueabi-gcc-4.9 default does not enable '-fpic',
>so there is not .got section and R_ARM_GOT_BREL in built-in.o.
>And in the final u-boot elf image, all relocation entries are
>R_ARM_RELATIVE.
>
>we can pass '-fno-pic' to xxx-gcc to disable pic. whether
>the toolchain internally enables or disables pic, '-fno-pic'
>can work well.
>
>Signed-off-by: Peng Fan 
>Cc: Albert Aribaud 
>---
> arch/arm/config.mk | 1 +
> 1 file changed, 1 insertion(+)
>
>diff --git a/arch/arm/config.mk b/arch/arm/config.mk
>index 0550225..2b6322a 100644
>--- a/arch/arm/config.mk
>+++ b/arch/arm/config.mk
>@@ -106,6 +106,7 @@ ALL-y += checkarmreloc
> # instruction. Relocation is not supported for that case, so disable
> # such usage by requiring word relocations.
> PLATFORM_CPPFLAGS += $(call cc-option, -mword-relocations)
>+PLATFORM_CPPFLAGS += $(call cc-option, -fno-pic)
> endif
> 
> # limit ourselves to the sections we want in the .bin.
>-- 
>2.6.2
>
>

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

Re: [U-Boot] [PATCH v2 3/5] spi: Use mode instead of op_mode_tx

[Bin Meng]

Hi Jagan,

On Mon, Dec 14, 2015 at 2:57 PM, Jagan Teki  wrote:
> Used mode member from spi_slave{} instead of op_mode_tx.
>
> Cc: Bin Meng 
> Cc: Simon Glass 
> Signed-off-by: Jagan Teki 
> ---
> Changes for v2:
> - none
>
>  drivers/mtd/spi/sf_probe.c  | 2 +-
>  drivers/mtd/spi/spi_flash.c | 4 ++--
>  drivers/spi/ich.c   | 2 +-
>  include/spi.h   | 8 ++--
>  4 files changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
> index 0cafc29..3519ffd 100644
> --- a/drivers/mtd/spi/sf_probe.c
> +++ b/drivers/mtd/spi/sf_probe.c
> @@ -128,7 +128,7 @@ static int spi_flash_std_write(struct udevice *dev, u32 
> offset, size_t len,
>
>  #if defined(CONFIG_SPI_FLASH_SST)
> if (flash->flags & SNOR_F_SST_WR) {
> -   if (flash->spi->op_mode_tx & SPI_OPM_TX_BP)
> +   if (flash->spi->mode & SPI_TX_BP)

Did you ever build this? spi->mode is declared as a u8, but SPI_TX_BP is 0x100.

> return sst_write_bp(flash, offset, len, buf);
> else
> return sst_write_wp(flash, offset, len, buf);
> diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
> index 30a381b..836aad9 100644
> --- a/drivers/mtd/spi/spi_flash.c
> +++ b/drivers/mtd/spi/spi_flash.c
> @@ -968,7 +968,7 @@ int spi_flash_scan(struct spi_flash *flash)
> flash->write = spi_flash_cmd_write_ops;
>  #if defined(CONFIG_SPI_FLASH_SST)
> if (flash->flags & SNOR_F_SST_WR) {
> -   if (spi->op_mode_tx & SPI_OPM_TX_BP)
> +   if (spi->mode & SPI_TX_BP)
> flash->write = sst_write_bp;
> else
> flash->write = sst_write_wp;
> @@ -1042,7 +1042,7 @@ int spi_flash_scan(struct spi_flash *flash)
> }
>
> /* Not require to look for fastest only two write cmds yet */
> -   if (params->flags & WR_QPP && spi->op_mode_tx & SPI_OPM_TX_QPP)
> +   if (params->flags & WR_QPP && spi->mode & SPI_TX_QPP)
> flash->write_cmd = CMD_QUAD_PAGE_PROGRAM;
> else
> /* Go for default supported write cmd */
> diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c
> index f85af9c..64322dd 100644
> --- a/drivers/spi/ich.c
> +++ b/drivers/spi/ich.c
> @@ -753,7 +753,7 @@ static int ich_spi_child_pre_probe(struct udevice *dev)
>  */
> if (plat->ich_version == 7) {
> slave->op_mode_rx = SPI_OPM_RX_AS;
> -   slave->op_mode_tx = SPI_OPM_TX_BP;
> +   slave->mode = SPI_TX_BP;
> }
>
> return 0;
> diff --git a/include/spi.h b/include/spi.h
> index 713bab9..2b36c5a 100644
> --- a/include/spi.h
> +++ b/include/spi.h
> @@ -23,6 +23,8 @@
>  #defineSPI_LOOP0x20/* loopback mode */
>  #defineSPI_SLAVE   0x40/* slave mode */
>  #defineSPI_PREAMBLE0x80/* Skip preamble 
> bytes */
> +#define SPI_TX_BP  0x100   /* transmit with 1 wire byte 
> */
> +#define SPI_TX_QPP 0x200   /* transmit with 4 wires */
>
>  /* SPI transfer flags */
>  #define SPI_XFER_BEGIN 0x01/* Assert CS before transfer */
> @@ -32,10 +34,6 @@
>  #define SPI_XFER_ONCE  (SPI_XFER_BEGIN | SPI_XFER_END)
>  #define SPI_XFER_U_PAGE(1 << 5)
>
> -/* SPI TX operation modes */
> -#define SPI_OPM_TX_QPP (1 << 0)
> -#define SPI_OPM_TX_BP  (1 << 1)
> -
>  /* SPI RX operation modes */
>  #define SPI_OPM_RX_AS  (1 << 0)
>  #define SPI_OPM_RX_AF  (1 << 1)
> @@ -107,7 +105,6 @@ struct dm_spi_slave_platdata {
>   * @cs:ID of the chip select connected to the slave.
>   * @mode:  SPI mode to use for this slave (see SPI mode flags)
>   * @op_mode_rx:SPI RX operation mode.
> - * @op_mode_tx:SPI TX operation mode.
>   * @wordlen:   Size of SPI word in number of bits
>   * @max_write_size:If non-zero, the maximum number of bytes which can
>   * be written at once, excluding command bytes.
> @@ -126,7 +123,6 @@ struct spi_slave {
>  #endif
> u8 mode;
> u8 op_mode_rx;
> -   u8 op_mode_tx;
> unsigned int wordlen;
> unsigned int max_write_size;
> void *memory_map;
> --

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

Re: [U-Boot] [PATCH 1/2] spl: dm: Add SPL_DM_SEQ_ALIAS config option

[Michal Simek]

On 14.12.2015 07:26, Stefan Roese wrote:
> On 12.12.2015 15:08, Nathan Rossi wrote:
>> On Sat, Dec 12, 2015 at 10:05 PM, Stefan Roese  wrote:
>>> On 11.12.2015 18:32, Marek Vasut wrote:

 On Friday, December 11, 2015 at 04:46:40 PM, Michal Simek wrote:
>
> On 11.12.2015 16:07, Marek Vasut wrote:
>>
>> On Friday, December 11, 2015 at 03:48:09 PM, Nathan Rossi wrote:
>>>
>>> The Device Model sequence alias feature is required by some
>>> Uclasses.
>>> Instead of disabling the feature for all SPL targets allow it to be
>>> configured.
>>>
>>> The config option is disabled by default to reduce code size for
>>> targets
>>> that are not interested or do not require this feature.
>>>
>>> Signed-off-by: Nathan Rossi 
>>> Cc: Simon Glass 
>>> Cc: Masahiro Yamada 
>>> Cc: Linus Walleij 
>>> Cc: Marek Vasut 
>>> Cc: Michal Simek 
>>> ---
>>> Based on a small amount of inspection for the Zynq platform,
>>> enabling
>>> this config option adds ~1KB of code size.
>>>
>>> Also on a side note, this might affect the socfpga target as it
>>> forcibly
>>> overrides the #undef from config_uncmd_spl.h in its common header. I
>>> have Cc'd the respective maintainer for this reason.
>>
>>
>> The fix for SoCFPGA is easy -- enable the SPL_DM_SEQ_ALIAS in
>> configs/socfpga*. It is needed for booting from QSPI NOR.
>>
>> I will add a patch to this series, depending on how it is agreed to
>> enable this option.
>>
>
>
> That's probably not the best solution. But of course we can use it.
> IRC Stefan had the same problem.
>>
>> So would a better solution be to force the ARCH_ZYNQ config (and
>> others ARCH_SOCFPGA/ARCH_MVEBU) to 'select SPL_DM_SEQ_ALIAS' instead
>> of enabling them separately for each defconfig? like is done for
>> SPL_OF_CONTROL/etc.
> 
> Yes, please. Autoselecting this option is definitely better.

TBH I don't think this is the best solution. We should select things
which are required all the time. For zynq case this selection is
necessary just for qspi boot mode. There are other boot modes which
doesn't require it that's why for these mods this is just additional code.
If you think that this is need/good to select by default for your SoC
then this can be done separately.

Note: Agree with Marek that will be good to check where exactly the
problem is that this config option is necessary to enable even for case
where only on qspi is in the system.

Acked-by: Michal Simek 

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

Re: [U-Boot] ARMv7 MMU shareability issue

[Albert ARIBAUD]

Hello Marek,

On Thu, 10 Dec 2015 04:53:01 +0100, Marek Vasut  wrote:
> On Thursday, December 10, 2015 at 03:27:08 AM, Tom Rini wrote:
> > On Wed, Dec 09, 2015 at 03:09:13PM +0100, Marek Vasut wrote:
> > > On Wednesday, December 09, 2015 at 02:02:03 PM, Stefan Roese wrote:
> > > > Hi All!
> > > > 
> > > > On 09.12.2015 09:09, Albert ARIBAUD wrote:
> > > > > On Tue,  8 Dec 2015 14:43:42 +0100, Marek Vasut  wrote:
> > > > >> The arch/arm/lib/cache-cp15.c checks for CONFIG_ARMV7 and if this
> > > > >> macro is set, it configures TTBR0 register. This register must be
> > > > >> configured for the cache on ARMv7 to operate correctly.
> > > > >> 
> > > > >> The problem is that noone actually sets the CONFIG_ARMV7 macro and
> > > > >> thus the TTBR0 is not configured at all. On SoCFPGA, this produces
> > > > >> all sorts of minor issues which are hard to replicate, for example
> > > > >> certain USB sticks are not detected or QSPI NOR sometimes fails to
> > > > >> write pages completely.
> > > > >> 
> > > > >> The solution is to replace CONFIG_ARMV7 test with CONFIG_CPU_V7 one.
> > > > >> This is correct because the code which added the test(s) for
> > > > >> CONFIG_ARMV7 was added shortly after CONFIG_ARMV7 was replaced by
> > > > >> CONFIG_CPU_V7 and this code was not adjusted correctly to reflect
> > > > >> that change.
> > > > > 
> > > > > Note:
> > > > > 
> > > > > As discussed with Marek on IRC, this patch enables what is supposed
> > > > > to be the correct MMU settings for ARMv7, which causes a sharp
> > > > > Ethernet performance drop (40%) but also a strong general memory
> > > > > access performance hit (a copy of 4 MB is almost instantaneous
> > > > > without the patch and takes 2-3 seconds with it).
> > > > 
> > > > I've tested Marek's patch on my current Armada XP platform (also
> > > > ARMv7). And also noticed a performance drop by about 30-40%.
> > > > The dhrystone command can be used for this testing as well
> > > > (CONFIG_CMD_DHRYSTONE).
> > > > 
> > > > So this is definitely a NAK from me to this current patch.
> > > 
> > > This is a wrong approach, this patch just fixes another patch which was
> > > broken from the getgo and the TTBR0 reg was not programmed correctly due
> > > to that. This patch must be applied, but what we need to decide is
> > > whether we need _another_ patch which removes the S-bit from the
> > > pagetable or how to deal with that part.
> > 
> > No, we don't have to apply this patch.  The original patch here
> > (97840b5) was likely not run-time tested when submitted as it was using
> > the then-defunct CONFIG_ARMV7 symbol, and was likely a bugfix in an
> > internal tree that was pushed upstream (which is on the whole, good).
> 
> I find it surprising that such a patch, which modifies common code even,
> was not scrutinized enough.
> 
> > So in sum U-Boot has always been as broken in some specific regard
> > before that patch as it is after that patch.  So we have time to see
> > what we need to do about enabling this feature correctly and even
> > ensuring that we don't happen to say break things once Linux is up too.
> 
> In that case, I am looking forward to better suggestions.
> 
> I still disagree that this patch should not be applied, it corrects code
> which was broken. The slowdown caused by the original patch is a separate
> issue and should be corrected by a separate patch. If these two patches
> get applied at once, that is fine.

This patch has several effects:

- it selects proper ARMv7 translation table level 1 bit definitions;
- it provides proper ARMv7 definitions for WT/WB/WA;
- it selects proper ARMv7 settings for TTBR0.

All these are correct as per the docs I have (although I may have missed
something during the readings (and cross-readings with Marek) of these
last hours/days.

Now, one specific effect goes against performance, and it is the
setting of bit S in all TT entries. This bit makes the corresponding
region shareable, but for all I know, in U-Boot we don't have more than
one core accessing the same memory or registers sets so -- at least for
the major part of its execution -- there is no reason for any region to
be shareable.

/That/ effect I certainly don't want.

The rest I am fine with.

So, if we apply this patch minus the inclusion of the S bit in the
definition of DCACHE_OFF (and hence of all DCACHE_* enum members after
it), then we get code that is more correct from a theoretical
standpoint, and does not degrade performance (which is a hint,
admittedly weak, to me that it is not incorrect from a practical
standpoint.

It does not fix the USB and QSPI issues in the socfpga case, but I am
not sure these are caused by the S bit being zero.

> Best regards,
> Marek Vasut

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

Re: [U-Boot] [PATCH] eth: dtsec: fix TBI ANA setting bug in dtsec_configure_serdes()

[Shaohui Xie]

Hi,

As mentioned, the value 0x4001 is the desired one in AN3869 for SGMII setting,
quoted as below:
" Program TBI ANA = 0x4001 (SGMII) or 0x01A0 (1000BASE-X). "

I think the AN3869 should be followed, change SGMII setting just because it 
worked on P2041rdb is not a good reason.

To distinguish SGMII from other connections should be the way to program TBI 
ANA,
This is also follow the AN3869.

Best Regards, 
Shaohui Xie


> -Original Message-
> From: York Sun [mailto:york...@freescale.com]
> Sent: Monday, December 14, 2015 11:55 AM
> To: 李远正; Xie Shaohui-B21989
> Cc: Ciubotariu Codrin Constantin-B43658; u-boot@lists.denx.de; Liu Dave-
> R63238
> Subject: Re: [PATCH] eth: dtsec: fix TBI ANA setting bug in
> dtsec_configure_serdes()
> 
> Shaohui,
> 
> Please comment/confirm.
> 
> York
> 
> On 12/09/2015 10:25 PM, 李远正 wrote:
> > The value TBIANA_SETTINGS is also work on the p2041rdb board, so it
> > can work on the both phy and phyless connections.
> >
> >
> >
> > At 2015-11-26 12:17:42, "Shaohui Xie"  wrote:
> >>> -Original Message-
> >>> From: York Sun [mailto:york...@freescale.com]
> >>> Sent: Thursday, November 26, 2015 1:03 AM
> >>> To: Xie Shaohui-B21989; Ciubotariu Codrin Constantin-B43658
> >>> Cc: Yuanzheng Li; u-boot@lists.denx.de; Liu Dave-R63238
> >>> Subject: Re: [PATCH] eth: dtsec: fix TBI ANA setting bug in
> >>> dtsec_configure_serdes()
> >>>
> >>> + Experts
> >>>
> >>> On 11/24/2015 11:04 PM, Yuanzheng Li wrote:
> >>> > The TBI_ANA register is configurated with the wrong value 0x4001,
> >>> > refer to QorIQ Data Path Acceleration Architecture (DPAA)
> >>> > Reference
> >>> Manual.
> >>> > It set the reserved areas, bit 1 and bit 11 to bit 15 in big
> >>> > endian, which should be cleared. But the normal functions of the
> >>> > auto-negotiation, e.g. Pause and Full Duplex, do not be set.
> >>[S.H] The value 0x4001 is so special, as mentioned, it does not match
> >>the DPAA RM, So I dig some docs and found AN3869, in which the 0x4001
> >>is the desired one to write to TBI_ANA for SGMII.
> >>
> >>> >
> >>> > There is no problem in the p2041rdb board, because the ppc is
> >>> > connected directly with the phy chip which support
> >>> > auto-negotiation by default in SGMII interface. But the link
> >>> > problem will occur when it is connected with a switch chip like
> >>> > BCM5389, the switch chip disable auto-negotiation by default, and
> >>> > the ppc also disable auto-negotiation, then there is no link
> between them.
> >>[S.H] This seems a phyless connection. If BCM5389 disables AN, then
> >>PPC should Also disable AN by setting TBI_CR.
> >>
> >>> >
> >>> > So use the vlue TBIANA_SETTINGS to enable the ppc's auto-
> negotiation.
> >>[S.H] The TBI_ANA is " AN Advertisement Register ", it does not
> enable/disable AN.
> >>A proper way should be to distinguish the phy and phyless connections
> >>and configure The TBI registers accordingly.
> >>
> >>Thanks,
> >>Shaohui
> >>
> >>> >
> >>> > Signed-off-by: Yuanzheng Li 
> >>> > Cc: York Sun 
> >>> > ---
> >>> >  drivers/net/fm/eth.c |2 +-
> >>> >  1 files changed, 1 insertions(+), 1 deletions(-)
> >>> >
> >>> > diff --git a/drivers/net/fm/eth.c b/drivers/net/fm/eth.c index
> >>> > eb8e936..78c0988 100644
> >>> > --- a/drivers/net/fm/eth.c
> >>> > +++ b/drivers/net/fm/eth.c
> >>> > @@ -81,7 +81,7 @@ qsgmii_loop:
> >>> > tsec_local_mdio_write(phyregs, in_be32(®s->tbipa), 0,
> TBI_TBICON,
> >>> > TBICON_CLK_SELECT);
> >>> > tsec_local_mdio_write(phyregs, in_be32(®s->tbipa), 0,
> TBI_ANA,
> >>> > -   TBIANA_SGMII_ACK);
> >>> > +   TBIANA_SETTINGS);
> >>> > tsec_local_mdio_write(phyregs, in_be32(®s->tbipa), 0,
> >>> > TBI_CR, TBICR_SETTINGS);
> >>> >  #endif
> >>> >
> >>>
> >>> Yuanzheng,
> >>>
> >>> After your change, TBIANA_SGMII_ACK is not used and should be removed.
> >>>
> >>> Shaohui and Codrin,
> >>>
> >>> Please comment.
> >>>
> >>> York
> >
> >
> >
> >
> >
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] spi: fsl_espi: Return all data read from device unmodified

[Jagan Teki]

On 12 December 2015 at 22:40, Joakim Tjernlund
 wrote:
> On Fri, 2015-12-11 at 21:19 -0500, Dale P. Smith wrote:
>> Signed-off-by: Dale P. Smith 
>> ---
>> Changes for v2:
>>- First attempt at using git format-patch
>> Changes for v3:
>>- Fix subject.
>>- Add changelog
>
> While this is a step in the right direction, this driver needs a rewrite.
> - The malloc/memcpy crap need to go.
> - TXing 4 bytes a time while while word size is still one byte makes Not 
> full/Not empty
>   HW flags useless.
> There is no real maintainer of this driver though so I am afraid nobody will 
> do make this happen.

Please try to write it in driver model format, let me know for any help.

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

[U-Boot] [PATCH v2 5/5] sf: Move spi_read_cmds_array locally

[Jagan Teki]

Since spi_read_cmds_array is used locally in
spi_flash_scan, so move array to locally used
function instead of defining global array.

Reviewed-by: Bin Meng 
Signed-off-by: Jagan Teki 
---
Changes for v2:
- none

 drivers/mtd/spi/spi_flash.c | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 513d9ad..32b2d15 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -29,16 +29,6 @@ static void spi_flash_addr(u32 addr, u8 *cmd)
cmd[3] = addr >> 0;
 }
 
-/* Read commands array */
-static u8 spi_read_cmds_array[] = {
-   CMD_READ_ARRAY_SLOW,
-   CMD_READ_ARRAY_FAST,
-   CMD_READ_DUAL_OUTPUT_FAST,
-   CMD_READ_DUAL_IO_FAST,
-   CMD_READ_QUAD_OUTPUT_FAST,
-   CMD_READ_QUAD_IO_FAST,
-};
-
 static int read_sr(struct spi_flash *flash, u8 *rs)
 {
int ret;
@@ -909,9 +899,15 @@ int spi_flash_scan(struct spi_flash *flash)
struct spi_slave *spi = flash->spi;
const struct spi_flash_params *params;
u16 jedec, ext_jedec;
-   u8 idcode[5];
-   u8 cmd;
+   u8 cmd, idcode[5];
int ret;
+   static u8 spi_read_cmds_array[] = {
+   CMD_READ_ARRAY_SLOW,
+   CMD_READ_ARRAY_FAST,
+   CMD_READ_DUAL_OUTPUT_FAST,
+   CMD_READ_DUAL_IO_FAST,
+   CMD_READ_QUAD_OUTPUT_FAST,
+   CMD_READ_QUAD_IO_FAST };
 
/* Read the ID codes */
ret = spi_flash_cmd(spi, CMD_READ_ID, idcode, sizeof(idcode));
-- 
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/5] spi: make mode visible to both dm and non-dm

[Jagan Teki]

Couldn't find the exact reason to define 'mode' for dm,
probably it is not using in non-dm drivers but it need
to visible both dm and non-dm as mode data is getting
dereferred in spi flash core ie common to both.

Cc: Bin Meng 
Cc: Simon Glass 
Signed-off-by: Jagan Teki 
---
Changes for v2:
- newly added

 include/spi.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/spi.h b/include/spi.h
index b4d2723..713bab9 100644
--- a/include/spi.h
+++ b/include/spi.h
@@ -99,13 +99,13 @@ struct dm_spi_slave_platdata {
  *
  * @dev:   SPI slave device
  * @max_hz:Maximum speed for this slave
- * @mode:  SPI mode to use for this slave (see SPI mode flags)
  * @speed: Current bus speed. This is 0 until the bus is first
  * claimed.
  * @bus:   ID of the bus that the slave is attached to. For
  * driver model this is the sequence number of the SPI
  * bus (bus->seq) so does not need to be stored
  * @cs:ID of the chip select connected to the slave.
+ * @mode:  SPI mode to use for this slave (see SPI mode flags)
  * @op_mode_rx:SPI RX operation mode.
  * @op_mode_tx:SPI TX operation mode.
  * @wordlen:   Size of SPI word in number of bits
@@ -120,11 +120,11 @@ struct spi_slave {
struct udevice *dev;/* struct spi_slave is dev->parentdata */
uint max_hz;
uint speed;
-   uint mode;
 #else
unsigned int bus;
unsigned int cs;
 #endif
+   u8 mode;
u8 op_mode_rx;
u8 op_mode_tx;
unsigned int wordlen;
-- 
1.9.1

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

[U-Boot] [PATCH v2 3/5] spi: Use mode instead of op_mode_tx

[Jagan Teki]

Used mode member from spi_slave{} instead of op_mode_tx.

Cc: Bin Meng 
Cc: Simon Glass 
Signed-off-by: Jagan Teki 
---
Changes for v2:
- none

 drivers/mtd/spi/sf_probe.c  | 2 +-
 drivers/mtd/spi/spi_flash.c | 4 ++--
 drivers/spi/ich.c   | 2 +-
 include/spi.h   | 8 ++--
 4 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index 0cafc29..3519ffd 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -128,7 +128,7 @@ static int spi_flash_std_write(struct udevice *dev, u32 
offset, size_t len,
 
 #if defined(CONFIG_SPI_FLASH_SST)
if (flash->flags & SNOR_F_SST_WR) {
-   if (flash->spi->op_mode_tx & SPI_OPM_TX_BP)
+   if (flash->spi->mode & SPI_TX_BP)
return sst_write_bp(flash, offset, len, buf);
else
return sst_write_wp(flash, offset, len, buf);
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 30a381b..836aad9 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -968,7 +968,7 @@ int spi_flash_scan(struct spi_flash *flash)
flash->write = spi_flash_cmd_write_ops;
 #if defined(CONFIG_SPI_FLASH_SST)
if (flash->flags & SNOR_F_SST_WR) {
-   if (spi->op_mode_tx & SPI_OPM_TX_BP)
+   if (spi->mode & SPI_TX_BP)
flash->write = sst_write_bp;
else
flash->write = sst_write_wp;
@@ -1042,7 +1042,7 @@ int spi_flash_scan(struct spi_flash *flash)
}
 
/* Not require to look for fastest only two write cmds yet */
-   if (params->flags & WR_QPP && spi->op_mode_tx & SPI_OPM_TX_QPP)
+   if (params->flags & WR_QPP && spi->mode & SPI_TX_QPP)
flash->write_cmd = CMD_QUAD_PAGE_PROGRAM;
else
/* Go for default supported write cmd */
diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c
index f85af9c..64322dd 100644
--- a/drivers/spi/ich.c
+++ b/drivers/spi/ich.c
@@ -753,7 +753,7 @@ static int ich_spi_child_pre_probe(struct udevice *dev)
 */
if (plat->ich_version == 7) {
slave->op_mode_rx = SPI_OPM_RX_AS;
-   slave->op_mode_tx = SPI_OPM_TX_BP;
+   slave->mode = SPI_TX_BP;
}
 
return 0;
diff --git a/include/spi.h b/include/spi.h
index 713bab9..2b36c5a 100644
--- a/include/spi.h
+++ b/include/spi.h
@@ -23,6 +23,8 @@
 #defineSPI_LOOP0x20/* loopback mode */
 #defineSPI_SLAVE   0x40/* slave mode */
 #defineSPI_PREAMBLE0x80/* Skip preamble bytes 
*/
+#define SPI_TX_BP  0x100   /* transmit with 1 wire byte */
+#define SPI_TX_QPP 0x200   /* transmit with 4 wires */
 
 /* SPI transfer flags */
 #define SPI_XFER_BEGIN 0x01/* Assert CS before transfer */
@@ -32,10 +34,6 @@
 #define SPI_XFER_ONCE  (SPI_XFER_BEGIN | SPI_XFER_END)
 #define SPI_XFER_U_PAGE(1 << 5)
 
-/* SPI TX operation modes */
-#define SPI_OPM_TX_QPP (1 << 0)
-#define SPI_OPM_TX_BP  (1 << 1)
-
 /* SPI RX operation modes */
 #define SPI_OPM_RX_AS  (1 << 0)
 #define SPI_OPM_RX_AF  (1 << 1)
@@ -107,7 +105,6 @@ struct dm_spi_slave_platdata {
  * @cs:ID of the chip select connected to the slave.
  * @mode:  SPI mode to use for this slave (see SPI mode flags)
  * @op_mode_rx:SPI RX operation mode.
- * @op_mode_tx:SPI TX operation mode.
  * @wordlen:   Size of SPI word in number of bits
  * @max_write_size:If non-zero, the maximum number of bytes which can
  * be written at once, excluding command bytes.
@@ -126,7 +123,6 @@ struct spi_slave {
 #endif
u8 mode;
u8 op_mode_rx;
-   u8 op_mode_tx;
unsigned int wordlen;
unsigned int max_write_size;
void *memory_map;
-- 
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/5] sf: Get spi locally from spi_flash

[Jagan Teki]

For better code readabilty, get the spi pointer from
spi_flash{} locally and use it instead of direct
dereferring spi pinter as flash->spi->*

Cc: Bin Meng 
Signed-off-by: Jagan Teki 
---
Changes for v2:
- Fixed missing spi declaration for sst_write_*

 drivers/mtd/spi/spi_flash.c | 51 ++---
 1 file changed, 29 insertions(+), 22 deletions(-)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 7ffa136..30a381b 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -177,13 +177,15 @@ bank_end:
 #ifdef CONFIG_SF_DUAL_FLASH
 static void spi_flash_dual(struct spi_flash *flash, u32 *addr)
 {
+   struct spi_slave *spi = flash->spi;
+
switch (flash->dual_flash) {
case SF_DUAL_STACKED_FLASH:
if (*addr >= (flash->size >> 1)) {
*addr -= flash->size >> 1;
-   flash->spi->flags |= SPI_XFER_U_PAGE;
+   spi->flags |= SPI_XFER_U_PAGE;
} else {
-   flash->spi->flags &= ~SPI_XFER_U_PAGE;
+   spi->flags &= ~SPI_XFER_U_PAGE;
}
break;
case SF_DUAL_PARALLEL_FLASH:
@@ -268,7 +270,7 @@ int spi_flash_write_common(struct spi_flash *flash, const 
u8 *cmd,
if (buf == NULL)
timeout = SPI_FLASH_PAGE_ERASE_TIMEOUT;
 
-   ret = spi_claim_bus(flash->spi);
+   ret = spi_claim_bus(spi);
if (ret) {
debug("SF: unable to claim SPI bus\n");
return ret;
@@ -353,6 +355,7 @@ int spi_flash_cmd_erase_ops(struct spi_flash *flash, u32 
offset, size_t len)
 int spi_flash_cmd_write_ops(struct spi_flash *flash, u32 offset,
size_t len, const void *buf)
 {
+   struct spi_slave *spi = flash->spi;
unsigned long byte_addr, page_size;
u32 write_addr;
size_t chunk_len, actual;
@@ -385,9 +388,9 @@ int spi_flash_cmd_write_ops(struct spi_flash *flash, u32 
offset,
byte_addr = offset % page_size;
chunk_len = min(len - actual, (size_t)(page_size - byte_addr));
 
-   if (flash->spi->max_write_size)
+   if (spi->max_write_size)
chunk_len = min(chunk_len,
-   (size_t)flash->spi->max_write_size);
+   (size_t)spi->max_write_size);
 
spi_flash_addr(write_addr, cmd);
 
@@ -413,7 +416,7 @@ int spi_flash_read_common(struct spi_flash *flash, const u8 
*cmd,
struct spi_slave *spi = flash->spi;
int ret;
 
-   ret = spi_claim_bus(flash->spi);
+   ret = spi_claim_bus(spi);
if (ret) {
debug("SF: unable to claim SPI bus\n");
return ret;
@@ -438,6 +441,7 @@ void __weak spi_flash_copy_mmap(void *data, void *offset, 
size_t len)
 int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 offset,
size_t len, void *data)
 {
+   struct spi_slave *spi = flash->spi;
u8 *cmd, cmdsz;
u32 remain_len, read_len, read_addr;
int bank_sel = 0;
@@ -445,15 +449,15 @@ int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 
offset,
 
/* Handle memory-mapped SPI */
if (flash->memory_map) {
-   ret = spi_claim_bus(flash->spi);
+   ret = spi_claim_bus(spi);
if (ret) {
debug("SF: unable to claim SPI bus\n");
return ret;
}
-   spi_xfer(flash->spi, 0, NULL, NULL, SPI_XFER_MMAP);
+   spi_xfer(spi, 0, NULL, NULL, SPI_XFER_MMAP);
spi_flash_copy_mmap(data, flash->memory_map + offset, len);
-   spi_xfer(flash->spi, 0, NULL, NULL, SPI_XFER_MMAP_END);
-   spi_release_bus(flash->spi);
+   spi_xfer(spi, 0, NULL, NULL, SPI_XFER_MMAP_END);
+   spi_release_bus(spi);
return 0;
}
 
@@ -505,6 +509,7 @@ int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 
offset,
 #ifdef CONFIG_SPI_FLASH_SST
 static int sst_byte_write(struct spi_flash *flash, u32 offset, const void *buf)
 {
+   struct spi_slave *spi = flash->spi;
int ret;
u8 cmd[4] = {
CMD_SST_BP,
@@ -514,13 +519,13 @@ static int sst_byte_write(struct spi_flash *flash, u32 
offset, const void *buf)
};
 
debug("BP[%02x]: 0x%p => cmd = { 0x%02x 0x%06x }\n",
- spi_w8r8(flash->spi, CMD_READ_STATUS), buf, cmd[0], offset);
+ spi_w8r8(spi, CMD_READ_STATUS), buf, cmd[0], offset);
 
ret = spi_flash_cmd_write_enable(flash);
if (ret)
return ret;
 
-   ret = spi_flash_cmd_write(flash->spi, cmd, sizeof(cmd), buf, 1);
+   ret = spi_flash_cmd_write(spi, cmd, sizeof(cmd), buf, 1);
if (ret)
return ret;
 
@@ -530,11 +535,12 @@ static int sst_byte_write

[U-Boot] [PATCH v2 4/5] spi: Rename SPI_TX_BP|QPP to SPI_TX_BYTE|QUAD

[Jagan Teki]

Since SPI_TX_* are spi_slave{} members so use spi protocol
notation instead spi flash programming, like

SPI_TX_BP  => SPI_TX_BYTE
SPI_TX_QPP => SPI_TX_QUAD

Cc: Bin Meng 
Cc: Simon Glass 
Signed-off-by: Jagan Teki 
---
Changes for v2:
- none

 drivers/mtd/spi/sf_probe.c  | 2 +-
 drivers/mtd/spi/spi_flash.c | 4 ++--
 drivers/spi/ich.c   | 2 +-
 include/spi.h   | 4 ++--
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index 3519ffd..daa1d5b 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -128,7 +128,7 @@ static int spi_flash_std_write(struct udevice *dev, u32 
offset, size_t len,
 
 #if defined(CONFIG_SPI_FLASH_SST)
if (flash->flags & SNOR_F_SST_WR) {
-   if (flash->spi->mode & SPI_TX_BP)
+   if (flash->spi->mode & SPI_TX_BYTE)
return sst_write_bp(flash, offset, len, buf);
else
return sst_write_wp(flash, offset, len, buf);
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 836aad9..513d9ad 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -968,7 +968,7 @@ int spi_flash_scan(struct spi_flash *flash)
flash->write = spi_flash_cmd_write_ops;
 #if defined(CONFIG_SPI_FLASH_SST)
if (flash->flags & SNOR_F_SST_WR) {
-   if (spi->mode & SPI_TX_BP)
+   if (spi->mode & SPI_TX_BYTE)
flash->write = sst_write_bp;
else
flash->write = sst_write_wp;
@@ -1042,7 +1042,7 @@ int spi_flash_scan(struct spi_flash *flash)
}
 
/* Not require to look for fastest only two write cmds yet */
-   if (params->flags & WR_QPP && spi->mode & SPI_TX_QPP)
+   if (params->flags & WR_QPP && spi->mode & SPI_TX_QUAD)
flash->write_cmd = CMD_QUAD_PAGE_PROGRAM;
else
/* Go for default supported write cmd */
diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c
index 64322dd..d11132c 100644
--- a/drivers/spi/ich.c
+++ b/drivers/spi/ich.c
@@ -753,7 +753,7 @@ static int ich_spi_child_pre_probe(struct udevice *dev)
 */
if (plat->ich_version == 7) {
slave->op_mode_rx = SPI_OPM_RX_AS;
-   slave->mode = SPI_TX_BP;
+   slave->mode = SPI_TX_BYTE;
}
 
return 0;
diff --git a/include/spi.h b/include/spi.h
index 2b36c5a..8ffd9aa 100644
--- a/include/spi.h
+++ b/include/spi.h
@@ -23,8 +23,8 @@
 #defineSPI_LOOP0x20/* loopback mode */
 #defineSPI_SLAVE   0x40/* slave mode */
 #defineSPI_PREAMBLE0x80/* Skip preamble bytes 
*/
-#define SPI_TX_BP  0x100   /* transmit with 1 wire byte */
-#define SPI_TX_QPP 0x200   /* transmit with 4 wires */
+#define SPI_TX_BYTE0x100   /* transmit with 1 wire byte */
+#define SPI_TX_QUAD0x200   /* transmit with 4 wires */
 
 /* SPI transfer flags */
 #define SPI_XFER_BEGIN 0x01/* Assert CS before transfer */
-- 
1.9.1

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

Re: [U-Boot] [PATCH] arm: mvebu: Add SolidRun ClearFog Armada 38x initial support

[Stefan Roese]

Hi Dennis, Hi Luka,

On 13.12.2015 23:02, Luka Perkov wrote:

On Sun, Dec 13, 2015 at 11:33:46AM -0600, Dennis Gilmore wrote:

Trying to test this  I have hit an error with CONFIG_PHY_ADDR not defined.

I am guessing that I am missing some other sets of patches. digging through
patchwork I am not able to figure it out.  there is a bunch of patches in
patchwork that say they are in NEW state however they are in the tree so not
labeled correctly.  Any clues as to which patch sets this depends on are
appreciated.


I've asked Stefan to put the patches up on some git repo for easier
review and pull on my side. I'm also very eager to test this patchset!


Right. And I've not done so until now, since the basis for the SPL DM
support for MVEBU has not accepted by Simon yet. But it seems that we
may have an acceptable solution now after a longer discussion.

I have a few new patches in the queue as well and will post them
later today (or in the next days). And will also publish a git
branch with all the pending MVEBU patches. Including the ClearFog
support.

I'll keep you informed on this...

Thanks,
Stefan

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

Re: [U-Boot] [PATCH 0/3] rockchip: Use the standard debug UART on rockchip

[hl]

Hi Simon.

Thank you for updating this series patch, i have verified it in 
evb-rk3036 board,

it worked.


On 14/12/15 12:36, Simon Glass wrote:

The RK3036 has only 8KB of RAM available for SPL. At present it uses its own
debug UART code.

By allowing the ns16550 driver to provide a debug UART without providing a
full serial driver, we can enable a UART with a very small overhead. This
requires addition Kconfig options. The debug UART supports printhex8(),
printascii() and a few other functions.

The root driver and uclass are pulled in by this series, but their size is
very small. It would possible to drop these by disabling CONFIG_DM_SERIAL.
However the ns16550 driver makes this hard, due to it supporting operation
without driver model, and operating differently in this case.


Simon Glass (3):
   dm: serial: Allow the UART driver to be dropped from the image
   dm: ns16550: Allow the driver to be omitted if requested
   rockchip: Use the debug UART on rk3036

  arch/arm/mach-rockchip/Makefile   |  1 -
  arch/arm/mach-rockchip/rk3036-board-spl.c |  9 -
  arch/arm/mach-rockchip/rk_early_print.c   | 63 ---
  configs/evb-rk3036_defconfig  |  6 +++
  drivers/serial/Kconfig| 20 ++
  drivers/serial/ns16550.c  |  2 +
  drivers/serial/serial-uclass.c|  2 +
  include/configs/rk3036_common.h   |  2 +
  8 files changed, 40 insertions(+), 65 deletions(-)
  delete mode 100644 arch/arm/mach-rockchip/rk_early_print.c



--
Lin Huang


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

Re: [U-Boot] [PATCH 1/2] spl: dm: Add SPL_DM_SEQ_ALIAS config option

[Stefan Roese]

On 12.12.2015 15:08, Nathan Rossi wrote:

On Sat, Dec 12, 2015 at 10:05 PM, Stefan Roese  wrote:

On 11.12.2015 18:32, Marek Vasut wrote:


On Friday, December 11, 2015 at 04:46:40 PM, Michal Simek wrote:


On 11.12.2015 16:07, Marek Vasut wrote:


On Friday, December 11, 2015 at 03:48:09 PM, Nathan Rossi wrote:


The Device Model sequence alias feature is required by some Uclasses.
Instead of disabling the feature for all SPL targets allow it to be
configured.

The config option is disabled by default to reduce code size for
targets
that are not interested or do not require this feature.

Signed-off-by: Nathan Rossi 
Cc: Simon Glass 
Cc: Masahiro Yamada 
Cc: Linus Walleij 
Cc: Marek Vasut 
Cc: Michal Simek 
---
Based on a small amount of inspection for the Zynq platform, enabling
this config option adds ~1KB of code size.

Also on a side note, this might affect the socfpga target as it
forcibly
overrides the #undef from config_uncmd_spl.h in its common header. I
have Cc'd the respective maintainer for this reason.



The fix for SoCFPGA is easy -- enable the SPL_DM_SEQ_ALIAS in
configs/socfpga*. It is needed for booting from QSPI NOR.


I will add a patch to this series, depending on how it is agreed to
enable this option.




That's probably not the best solution. But of course we can use it.
IRC Stefan had the same problem.


So would a better solution be to force the ARCH_ZYNQ config (and
others ARCH_SOCFPGA/ARCH_MVEBU) to 'select SPL_DM_SEQ_ALIAS' instead
of enabling them separately for each defconfig? like is done for
SPL_OF_CONTROL/etc.


Yes, please. Autoselecting this option is definitely better.




So what is the solution ?



I added

#define CONFIG_DM_SEQ_ALIAS1

to the common config header for MVEBU. If its possible to set this
via Kconfig in a way where its not #undef'ed by config_uncmd_spl.h,
that would be even better.


As with socfpga, would you like me to do the same for MVEBU, add a
patch to this series to enable it for MVEBU?


Yes, please do so.

Thanks,
Stefan

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

[U-Boot] [PATCH v2 1/4] sf: Get spi locally from spi_flash

[Jagan Teki]

For better code readabilty, get the spi pointer from
spi_flash{} locally and use it instead of direct
dereferring spi pinter as flash->spi->*

Cc: Bin Meng 
Signed-off-by: Jagan Teki 
---
Changes for v2:
- Fixed missing spi declaration for sst_write_*

 drivers/mtd/spi/spi_flash.c | 51 ++---
 1 file changed, 29 insertions(+), 22 deletions(-)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 7ffa136..30a381b 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -177,13 +177,15 @@ bank_end:
 #ifdef CONFIG_SF_DUAL_FLASH
 static void spi_flash_dual(struct spi_flash *flash, u32 *addr)
 {
+   struct spi_slave *spi = flash->spi;
+
switch (flash->dual_flash) {
case SF_DUAL_STACKED_FLASH:
if (*addr >= (flash->size >> 1)) {
*addr -= flash->size >> 1;
-   flash->spi->flags |= SPI_XFER_U_PAGE;
+   spi->flags |= SPI_XFER_U_PAGE;
} else {
-   flash->spi->flags &= ~SPI_XFER_U_PAGE;
+   spi->flags &= ~SPI_XFER_U_PAGE;
}
break;
case SF_DUAL_PARALLEL_FLASH:
@@ -268,7 +270,7 @@ int spi_flash_write_common(struct spi_flash *flash, const 
u8 *cmd,
if (buf == NULL)
timeout = SPI_FLASH_PAGE_ERASE_TIMEOUT;
 
-   ret = spi_claim_bus(flash->spi);
+   ret = spi_claim_bus(spi);
if (ret) {
debug("SF: unable to claim SPI bus\n");
return ret;
@@ -353,6 +355,7 @@ int spi_flash_cmd_erase_ops(struct spi_flash *flash, u32 
offset, size_t len)
 int spi_flash_cmd_write_ops(struct spi_flash *flash, u32 offset,
size_t len, const void *buf)
 {
+   struct spi_slave *spi = flash->spi;
unsigned long byte_addr, page_size;
u32 write_addr;
size_t chunk_len, actual;
@@ -385,9 +388,9 @@ int spi_flash_cmd_write_ops(struct spi_flash *flash, u32 
offset,
byte_addr = offset % page_size;
chunk_len = min(len - actual, (size_t)(page_size - byte_addr));
 
-   if (flash->spi->max_write_size)
+   if (spi->max_write_size)
chunk_len = min(chunk_len,
-   (size_t)flash->spi->max_write_size);
+   (size_t)spi->max_write_size);
 
spi_flash_addr(write_addr, cmd);
 
@@ -413,7 +416,7 @@ int spi_flash_read_common(struct spi_flash *flash, const u8 
*cmd,
struct spi_slave *spi = flash->spi;
int ret;
 
-   ret = spi_claim_bus(flash->spi);
+   ret = spi_claim_bus(spi);
if (ret) {
debug("SF: unable to claim SPI bus\n");
return ret;
@@ -438,6 +441,7 @@ void __weak spi_flash_copy_mmap(void *data, void *offset, 
size_t len)
 int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 offset,
size_t len, void *data)
 {
+   struct spi_slave *spi = flash->spi;
u8 *cmd, cmdsz;
u32 remain_len, read_len, read_addr;
int bank_sel = 0;
@@ -445,15 +449,15 @@ int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 
offset,
 
/* Handle memory-mapped SPI */
if (flash->memory_map) {
-   ret = spi_claim_bus(flash->spi);
+   ret = spi_claim_bus(spi);
if (ret) {
debug("SF: unable to claim SPI bus\n");
return ret;
}
-   spi_xfer(flash->spi, 0, NULL, NULL, SPI_XFER_MMAP);
+   spi_xfer(spi, 0, NULL, NULL, SPI_XFER_MMAP);
spi_flash_copy_mmap(data, flash->memory_map + offset, len);
-   spi_xfer(flash->spi, 0, NULL, NULL, SPI_XFER_MMAP_END);
-   spi_release_bus(flash->spi);
+   spi_xfer(spi, 0, NULL, NULL, SPI_XFER_MMAP_END);
+   spi_release_bus(spi);
return 0;
}
 
@@ -505,6 +509,7 @@ int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 
offset,
 #ifdef CONFIG_SPI_FLASH_SST
 static int sst_byte_write(struct spi_flash *flash, u32 offset, const void *buf)
 {
+   struct spi_slave *spi = flash->spi;
int ret;
u8 cmd[4] = {
CMD_SST_BP,
@@ -514,13 +519,13 @@ static int sst_byte_write(struct spi_flash *flash, u32 
offset, const void *buf)
};
 
debug("BP[%02x]: 0x%p => cmd = { 0x%02x 0x%06x }\n",
- spi_w8r8(flash->spi, CMD_READ_STATUS), buf, cmd[0], offset);
+ spi_w8r8(spi, CMD_READ_STATUS), buf, cmd[0], offset);
 
ret = spi_flash_cmd_write_enable(flash);
if (ret)
return ret;
 
-   ret = spi_flash_cmd_write(flash->spi, cmd, sizeof(cmd), buf, 1);
+   ret = spi_flash_cmd_write(spi, cmd, sizeof(cmd), buf, 1);
if (ret)
return ret;
 
@@ -530,11 +535,12 @@ static int sst_byte_write

Re: [U-Boot] [PATCH 6/6] dm: x86: Drop the weak cpu_irq_init() function

[Bin Meng]

On Tue, Dec 1, 2015 at 12:47 PM, Simon Glass  wrote:
> There are no callers now. Platforms which need to set up interrupts their
> own way can implement an interrupt driver. Drop this function.
>
> Signed-off-by: Simon Glass 
> ---
>

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

Re: [U-Boot] [PATCH 3/6] dm: x86: Add a common PIRQ init function

[Bin Meng]

On Tue, Dec 1, 2015 at 12:47 PM, Simon Glass  wrote:
> Most x86 interrupt drivers will want to use the standard PIRQ routing and
> table setup. Put this code in a common function so it can be used by those
> drivers that want it.
>
> Signed-off-by: Simon Glass 
> ---
>

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

Re: [U-Boot] [PATCH 5/6] dm: x86: queensbay: Add an interrupt driver

[Bin Meng]

On Tue, Dec 1, 2015 at 12:47 PM, Simon Glass  wrote:
> Add a driver for interrupts on queensbay and move the code currently in
> cpu_irq_init() into its probe() method.
>
> Signed-off-by: Simon Glass 
> ---
>

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

Re: [U-Boot] [PATCH 4/6] dm: x86: quark: Add an interrupt driver

[Bin Meng]

On Tue, Dec 1, 2015 at 12:47 PM, Simon Glass  wrote:
> Add a driver for interrupts on quark and move the code currently in
> cpu_irq_init() into its probe() method.
>
> Signed-off-by: Simon Glass 
> ---
>

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

[U-Boot] [PATCH v2] mmc: implement mmc power on write protect function

[Lin Huang]

set the mmc specific addresss and range as power on
write protection, you can't earse and write this range
of data if you enable it after mmc power on.

Signed-off-by: Lin Huang 
---
Changes in v2:
- Adviced by Simon:
- use standard way of doing function comments
Changes in v1:
- Adviced by Simon:
- use real error in errno.h to return
- add full function comments for new function

 drivers/mmc/mmc.c | 87 +++
 include/mmc.h | 36 +++
 2 files changed, 123 insertions(+)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 3a34028..1308ce9 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1821,6 +1821,93 @@ int mmc_initialize(bd_t *bis)
return 0;
 }
 
+int mmc_get_wp_status(struct mmc *mmc, lbaint_t addr, char *status)
+{
+   struct mmc_cmd cmd;
+   struct mmc_data data;
+   int err;
+
+   cmd.cmdidx = MMC_CMD_WRITE_PROT_TYPE;
+   cmd.resp_type = MMC_RSP_R1;
+   cmd.cmdarg = addr;
+
+   data.dest = status;
+   data.blocksize = 8;
+   data.blocks = 1;
+   data.flags = MMC_DATA_READ;
+
+   err = mmc_send_cmd(mmc, &cmd, &data);
+
+   return err;
+}
+
+int mmc_usr_power_on_wp(struct mmc *mmc, lbaint_t addr, unsigned int size)
+{
+   int err;
+   unsigned int wp_group_size, wp_grp_num, i;
+   struct mmc_cmd cmd;
+   unsigned int timeout = 1000;
+   ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
+
+   size = size / MMC_MAX_BLOCK_LEN;
+
+   err = mmc_send_ext_csd(mmc, ext_csd);
+   if (err)
+   return err;
+
+   if ((ext_csd[EXT_CSD_USER_WP] & EXT_CSD_USER_PERM_WP_EN) ||
+   (ext_csd[EXT_CSD_USER_WP] & EXT_CSD_USER_PWR_WP_DIS)) {
+   printf("Power on protection is disabled\n");
+   return -EINVAL;
+   }
+
+   if (ext_csd[EXT_CSD_ERASE_GROUP_DEF])
+   wp_group_size = ext_csd[EXT_CSD_HC_WP_GRP_SIZE] *
+   ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE] * 1024;
+   else {
+   int erase_gsz, erase_gmul, wp_grp_size;
+
+   erase_gsz = (mmc->csd[2] & 0x7c00) >> 10;
+   erase_gmul = (mmc->csd[2] & 0x03e0) >> 5;
+   wp_grp_size = (mmc->csd[2] & 0x001f);
+   wp_group_size = (erase_gsz + 1) * (erase_gmul + 1) *
+   (wp_grp_size + 1);
+   }
+
+   if (size < wp_group_size) {
+   printf("wrong size, fail to set power on wp\n");
+   return -EINVAL;
+   }
+
+   err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL,
+EXT_CSD_USER_WP, EXT_CSD_USER_PWR_WP_EN);
+   if (err)
+   return err;
+
+   wp_grp_num = DIV_ROUND_UP(size, wp_group_size);
+   cmd.cmdidx = MMC_CMD_WRITE_PROT;
+   cmd.resp_type = MMC_RSP_R1b;
+
+   for (i = 0; i < wp_grp_num; i++) {
+   cmd.cmdarg = addr + i * wp_group_size;
+   err = mmc_send_cmd(mmc, &cmd, NULL);
+   if (err)
+   return err;
+
+   /* CMD28/CMD29 ON failure returns address out of range error */
+   if ((cmd.response[0] >> 31) & 0x01) {
+   printf("address for CMD28/29 out of range\n");
+   return -EINVAL;
+   }
+
+   err = mmc_send_status(mmc, timeout);
+   if (err)
+   return err;
+   }
+
+   return 0;
+}
+
 #ifdef CONFIG_SUPPORT_EMMC_BOOT
 /*
  * This function changes the size of boot partition and the size of rpmb
diff --git a/include/mmc.h b/include/mmc.h
index cda9a19..dd9e803 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -89,6 +89,8 @@
 #define MMC_CMD_SET_BLOCK_COUNT 23
 #define MMC_CMD_WRITE_SINGLE_BLOCK 24
 #define MMC_CMD_WRITE_MULTIPLE_BLOCK   25
+#define MMC_CMD_WRITE_PROT 28
+#define MMC_CMD_WRITE_PROT_TYPE31
 #define MMC_CMD_ERASE_GROUP_START  35
 #define MMC_CMD_ERASE_GROUP_END36
 #define MMC_CMD_ERASE  38
@@ -175,6 +177,7 @@
 #define EXT_CSD_WR_REL_PARAM   166 /* R */
 #define EXT_CSD_WR_REL_SET 167 /* R/W */
 #define EXT_CSD_RPMB_MULT  168 /* RO */
+#define EXT_CSD_USER_WP171
 #define EXT_CSD_ERASE_GROUP_DEF175 /* R/W */
 #define EXT_CSD_BOOT_BUS_WIDTH 177
 #define EXT_CSD_PART_CONF  179 /* R/W */
@@ -231,6 +234,10 @@
 #define EXT_CSD_WR_DATA_REL_USR(1 << 0)/* user data 
area WR_REL */
 #define EXT_CSD_WR_DATA_REL_GP(x)  (1 << ((x)+1))  /* GP part (x+1) WR_REL 
*/
 
+#define EXT_CSD_USER_PWR_WP_DIS(1 << 3) /* disable power-on 
write protect*/
+#define EXT_CSD_USER_PERM_WP_EN(1 << 2) /* enable permanent 
write protect */
+#define EXT_CSD_USER_PWR_WP_EN (1 << 0) /* enable power-on write 

Re: [U-Boot] [PATCH 2/6] dm: x86: Set up interrupt routing from interrupt_init()

[Bin Meng]

On Tue, Dec 1, 2015 at 12:47 PM, Simon Glass  wrote:
> At present interrupt routing is set up from arch_misc_init(). We can do it
> a little later instead, in interrupt_init().
>
> This removes the manual pirq_init() call. Where the platform does not have
> an interrupt router defined in its device tree, no error is generated. Some
> platforms do not have this.
>
> Drop pirq_init() since it is no-longer used.
>
> Signed-off-by: Simon Glass 
> ---
>

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

Re: [U-Boot] [PATCH 1/6] dm: x86: Create a driver for x86 interrupts

[Bin Meng]

Hi Simon,

On Tue, Dec 1, 2015 at 12:46 PM, Simon Glass  wrote:
> It seems likely that at some point we will want a generic interrupt uclass.
> But this is a big undertaking as it involves unifying code across multiple
> architectures.
>
> As a first step, create a simple IRQ uclass and a driver for x86. This can
> be generalised later as required.
>
> Adjust pirq_init() to probe this driver, which has the effect of creating
> routing tables and setting up the interrupt routing. This is a start
> towards making interrupts fit better with driver model.
>
> Signed-off-by: Simon Glass 
> ---
>

Reviewed-by: Bin Meng 

I will test this series when all previous DM changes are applied.

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

Re: [U-Boot] [PATCH 1/4] sf: Get spi locally from spi_flash

[Bin Meng]

Hi Jagan,

On Mon, Dec 14, 2015 at 12:52 AM, Jagan Teki  wrote:
> For better code readabilty, get the spi pointer from
> spi_flash{} locally and use it instead of direct
> dereferring spi pinter as flash->spi->*
>
> Signed-off-by: Jagan Teki 
> ---
>  drivers/mtd/spi/spi_flash.c | 48 
> -
>  1 file changed, 26 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
> index 7ffa136..ebf8b9c 100644
> --- a/drivers/mtd/spi/spi_flash.c
> +++ b/drivers/mtd/spi/spi_flash.c
> @@ -177,13 +177,15 @@ bank_end:
>  #ifdef CONFIG_SF_DUAL_FLASH
>  static void spi_flash_dual(struct spi_flash *flash, u32 *addr)
>  {
> +   struct spi_slave *spi = flash->spi;
> +
> switch (flash->dual_flash) {
> case SF_DUAL_STACKED_FLASH:
> if (*addr >= (flash->size >> 1)) {
> *addr -= flash->size >> 1;
> -   flash->spi->flags |= SPI_XFER_U_PAGE;
> +   spi->flags |= SPI_XFER_U_PAGE;
> } else {
> -   flash->spi->flags &= ~SPI_XFER_U_PAGE;
> +   spi->flags &= ~SPI_XFER_U_PAGE;
> }
> break;
> case SF_DUAL_PARALLEL_FLASH:
> @@ -268,7 +270,7 @@ int spi_flash_write_common(struct spi_flash *flash, const 
> u8 *cmd,
> if (buf == NULL)
> timeout = SPI_FLASH_PAGE_ERASE_TIMEOUT;
>
> -   ret = spi_claim_bus(flash->spi);
> +   ret = spi_claim_bus(spi);
> if (ret) {
> debug("SF: unable to claim SPI bus\n");
> return ret;
> @@ -353,6 +355,7 @@ int spi_flash_cmd_erase_ops(struct spi_flash *flash, u32 
> offset, size_t len)
>  int spi_flash_cmd_write_ops(struct spi_flash *flash, u32 offset,
> size_t len, const void *buf)
>  {
> +   struct spi_slave *spi = flash->spi;
> unsigned long byte_addr, page_size;
> u32 write_addr;
> size_t chunk_len, actual;
> @@ -385,9 +388,9 @@ int spi_flash_cmd_write_ops(struct spi_flash *flash, u32 
> offset,
> byte_addr = offset % page_size;
> chunk_len = min(len - actual, (size_t)(page_size - 
> byte_addr));
>
> -   if (flash->spi->max_write_size)
> +   if (spi->max_write_size)
> chunk_len = min(chunk_len,
> -   (size_t)flash->spi->max_write_size);
> +   (size_t)spi->max_write_size);
>
> spi_flash_addr(write_addr, cmd);
>
> @@ -413,7 +416,7 @@ int spi_flash_read_common(struct spi_flash *flash, const 
> u8 *cmd,
> struct spi_slave *spi = flash->spi;
> int ret;
>
> -   ret = spi_claim_bus(flash->spi);
> +   ret = spi_claim_bus(spi);
> if (ret) {
> debug("SF: unable to claim SPI bus\n");
> return ret;
> @@ -438,6 +441,7 @@ void __weak spi_flash_copy_mmap(void *data, void *offset, 
> size_t len)
>  int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 offset,
> size_t len, void *data)
>  {
> +   struct spi_slave *spi = flash->spi;
> u8 *cmd, cmdsz;
> u32 remain_len, read_len, read_addr;
> int bank_sel = 0;
> @@ -445,15 +449,15 @@ int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 
> offset,
>
> /* Handle memory-mapped SPI */
> if (flash->memory_map) {
> -   ret = spi_claim_bus(flash->spi);
> +   ret = spi_claim_bus(spi);
> if (ret) {
> debug("SF: unable to claim SPI bus\n");
> return ret;
> }
> -   spi_xfer(flash->spi, 0, NULL, NULL, SPI_XFER_MMAP);
> +   spi_xfer(spi, 0, NULL, NULL, SPI_XFER_MMAP);
> spi_flash_copy_mmap(data, flash->memory_map + offset, len);
> -   spi_xfer(flash->spi, 0, NULL, NULL, SPI_XFER_MMAP_END);
> -   spi_release_bus(flash->spi);
> +   spi_xfer(spi, 0, NULL, NULL, SPI_XFER_MMAP_END);
> +   spi_release_bus(spi);
> return 0;
> }
>
> @@ -514,13 +518,13 @@ static int sst_byte_write(struct spi_flash *flash, u32 
> offset, const void *buf)
> };
>
> debug("BP[%02x]: 0x%p => cmd = { 0x%02x 0x%06x }\n",
> - spi_w8r8(flash->spi, CMD_READ_STATUS), buf, cmd[0], offset);
> + spi_w8r8(spi, CMD_READ_STATUS), buf, cmd[0], offset);

This does not build as spi is undeclared.

>
> ret = spi_flash_cmd_write_enable(flash);
> if (ret)
> return ret;
>
> -   ret = spi_flash_cmd_write(flash->spi, cmd, sizeof(cmd), buf, 1);
> +   ret = spi_flash_cmd_write(spi, cmd, sizeof(cmd), buf, 1);
> if (ret)
> return ret;
>
> @@ -534,7 +538,7 @@ int sst_write_wp(struct spi_flash *flash, u32 offset, 
> size_t len,
> int ret;
>  

Re: [U-Boot] [PATCH 4/4] sf: Move spi_read_cmds_array locally

[Bin Meng]

On Mon, Dec 14, 2015 at 12:52 AM, Jagan Teki  wrote:
> Since spi_read_cmds_array is used locally in
> spi_flash_scan, so move array to locally used
> function instead of defining global array.
>
> Signed-off-by: Jagan Teki 
> ---

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

[U-Boot] [PATCH 1/3] dm: serial: Allow the UART driver to be dropped from the image

[Simon Glass]

In very very space-constrained devices even the full UART driver is too
large. In this case the debug UART can still be used in some cases.

Add options to enable the UART driver in SPL and U-Boot proper. Enable both
options by default.

Signed-off-by: Simon Glass 
---

 drivers/serial/Kconfig | 20 
 drivers/serial/serial-uclass.c |  2 ++
 2 files changed, 22 insertions(+)

diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 1fc287e..04541c9 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -15,6 +15,26 @@ config REQUIRE_SERIAL_CONSOLE
  during serial port initialization (default y). Set this to n on
  boards which have no debug serial port whatsoever.
 
+config SERIAL_PRESENT
+   bool "Provide a serial driver"
+   depends on DM_SERIAL
+   default y
+   help
+ In very space-constrained devices even the full UART driver is too
+ large. In this case the debug UART can still be used in some cases.
+ This option enables the full UART in U-Boot, so if is it disabled,
+ the full UART driver will be omitted, thus saving space.
+
+config SPL_SERIAL_PRESENT
+   bool "Provide a serial driver in SPL"
+   depends on DM_SERIAL
+   default y
+   help
+ In very space-constrained devices even the full UART driver is too
+ large. In this case the debug UART can still be used in some cases.
+ This option enables the full UART in SPL, so if is it disabled,
+ the full UART driver will be omitted, thus saving space.
+
 config DM_SERIAL
bool "Enable Driver Model for serial drivers"
depends on DM
diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
index 4bf9a5c..95c3b91 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -287,6 +287,7 @@ static int on_baudrate(const char *name, const char *value, 
enum env_op op,
 }
 U_BOOT_ENV_CALLBACK(baudrate, on_baudrate);
 
+#if CONFIG_IS_ENABLED(SERIAL_PRESENT)
 static int serial_post_probe(struct udevice *dev)
 {
struct dm_serial_ops *ops = serial_get_ops(dev);
@@ -356,3 +357,4 @@ UCLASS_DRIVER(serial) = {
.pre_remove = serial_pre_remove,
.per_device_auto_alloc_size = sizeof(struct serial_dev_priv),
 };
+#endif
-- 
2.6.0.rc2.230.g3dd15c0

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

[U-Boot] [PATCH 3/3] rockchip: Use the debug UART on rk3036

[Simon Glass]

Rather than using a new debug UART implementation, use the standard one
provided by U-Boot.
Signed-off-by: Simon Glass 
---

 arch/arm/mach-rockchip/Makefile   |  1 -
 arch/arm/mach-rockchip/rk3036-board-spl.c |  9 -
 arch/arm/mach-rockchip/rk_early_print.c   | 63 ---
 configs/evb-rk3036_defconfig  |  6 +++
 include/configs/rk3036_common.h   |  2 +
 5 files changed, 16 insertions(+), 65 deletions(-)
 delete mode 100644 arch/arm/mach-rockchip/rk_early_print.c

diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index b703c3c..1cc4a96 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -11,7 +11,6 @@ else
 obj-$(CONFIG_ROCKCHIP_RK3288) += board.o
 endif
 obj-y += rk_timer.o
-obj-y += rk_early_print.o
 obj-$(CONFIG_$(SPL_)ROCKCHIP_COMMON) += common.o
 obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288/
 obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036/
diff --git a/arch/arm/mach-rockchip/rk3036-board-spl.c 
b/arch/arm/mach-rockchip/rk3036-board-spl.c
index 3a1491c..8015481 100644
--- a/arch/arm/mach-rockchip/rk3036-board-spl.c
+++ b/arch/arm/mach-rockchip/rk3036-board-spl.c
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -34,7 +35,7 @@ void board_init_f(ulong dummy)
 GPIO1C2_MASK << GPIO1C2_SHIFT,
 GPIO1C3_UART2_SOUT << GPIO1C3_SHIFT |
 GPIO1C2_UART2_SIN << GPIO1C2_SHIFT);
-   rk_uart_init((void *)DEBUG_UART_BASE);
+   debug_uart_init();
 #endif
rockchip_timer_init();
sdram_init();
@@ -53,3 +54,9 @@ void board_init_r(gd_t *id, ulong dest_addr)
while (1)
;
 }
+
+void hang(void)
+{
+   while (1)
+   ;
+}
diff --git a/arch/arm/mach-rockchip/rk_early_print.c 
b/arch/arm/mach-rockchip/rk_early_print.c
deleted file mode 100644
index a1c14b0..000
--- a/arch/arm/mach-rockchip/rk_early_print.c
+++ /dev/null
@@ -1,63 +0,0 @@
-/*
- * (C) Copyright 2015 Rockchip Electronics Co., Ltd
- *
- * SPDX-License-Identifier: GPL-2.0+
- */
-
-#include 
-#include 
-#include 
-
-static struct rk_uart *uart_ptr;
-
-static void uart_wrtie_byte(char byte)
-{
-   writel(byte, &uart_ptr->rbr);
-   while (!(readl(&uart_ptr->lsr) & 0x40))
-   ;
-}
-
-void print(char *s)
-{
-   while (*s) {
-   if (*s == '\n')
-   uart_wrtie_byte('\r');
-   uart_wrtie_byte(*s);
-   s++;
-   }
-}
-
-void print_hex(unsigned int n)
-{
-   int i;
-   int temp;
-
-   uart_wrtie_byte('0');
-   uart_wrtie_byte('x');
-
-   for (i = 8; i > 0; i--) {
-   temp = (n >> (i - 1) * 4) & 0x0f;
-   if (temp < 10)
-   uart_wrtie_byte((char)(temp + '0'));
-   else
-   uart_wrtie_byte((char)(temp - 10 + 'a'));
-   }
-   uart_wrtie_byte('\n');
-   uart_wrtie_byte('\r');
-}
-
-/*
- * TODO: since rk3036 only 4K sram to use in SPL, for saving space,
- * we implement uart driver this way, we should convert this to use
- * ns16550 driver in future, which support DEBUG_UART in the standard way
- */
-void rk_uart_init(void *base)
-{
-   uart_ptr = (struct rk_uart *)base;
-   writel(0x83, &uart_ptr->lcr);
-   writel(0x0d, &uart_ptr->rbr);
-   writel(0x03, &uart_ptr->lcr);
-
-   /* fifo enable, sfe is shadow register of FCR[0] */
-   writel(0x01, &uart_ptr->sfe);
-}
diff --git a/configs/evb-rk3036_defconfig b/configs/evb-rk3036_defconfig
index 2e915ff..c196bd6 100644
--- a/configs/evb-rk3036_defconfig
+++ b/configs/evb-rk3036_defconfig
@@ -24,3 +24,9 @@ CONFIG_DM_MMC=y
 CONFIG_USE_PRIVATE_LIBGCC=y
 CONFIG_CMD_DHRYSTONE=y
 CONFIG_ERRNO_STR=y
+CONFIG_DEBUG_UART=y
+CONFIG_DEBUG_UART_NS16550=y
+CONFIG_DEBUG_UART_BASE=0x20068000
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_DEBUG_UART_SHIFT=2
+# CONFIG_SPL_SERIAL_PRESENT is not set
diff --git a/include/configs/rk3036_common.h b/include/configs/rk3036_common.h
index f753e68..d22ea74 100644
--- a/include/configs/rk3036_common.h
+++ b/include/configs/rk3036_common.h
@@ -24,6 +24,8 @@
 #define CONFIG_SYS_TIMER_BASE  0x200440a0 /* TIMER5 */
 #define CONFIG_SYS_TIMER_COUNTER   (CONFIG_SYS_TIMER_BASE + 8)
 
+#define CONFIG_SPL_SERIAL_SUPPORT
+
 #define CONFIG_SYS_NS16550
 #define CONFIG_SYS_NS16550_MEM32
 
-- 
2.6.0.rc2.230.g3dd15c0

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

[U-Boot] [PATCH 0/3] rockchip: Use the standard debug UART on rockchip

[Simon Glass]

The RK3036 has only 8KB of RAM available for SPL. At present it uses its own
debug UART code.

By allowing the ns16550 driver to provide a debug UART without providing a
full serial driver, we can enable a UART with a very small overhead. This
requires addition Kconfig options. The debug UART supports printhex8(),
printascii() and a few other functions.

The root driver and uclass are pulled in by this series, but their size is
very small. It would possible to drop these by disabling CONFIG_DM_SERIAL.
However the ns16550 driver makes this hard, due to it supporting operation
without driver model, and operating differently in this case.


Simon Glass (3):
  dm: serial: Allow the UART driver to be dropped from the image
  dm: ns16550: Allow the driver to be omitted if requested
  rockchip: Use the debug UART on rk3036

 arch/arm/mach-rockchip/Makefile   |  1 -
 arch/arm/mach-rockchip/rk3036-board-spl.c |  9 -
 arch/arm/mach-rockchip/rk_early_print.c   | 63 ---
 configs/evb-rk3036_defconfig  |  6 +++
 drivers/serial/Kconfig| 20 ++
 drivers/serial/ns16550.c  |  2 +
 drivers/serial/serial-uclass.c|  2 +
 include/configs/rk3036_common.h   |  2 +
 8 files changed, 40 insertions(+), 65 deletions(-)
 delete mode 100644 arch/arm/mach-rockchip/rk_early_print.c

-- 
2.6.0.rc2.230.g3dd15c0

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

[U-Boot] [PATCH 2/3] dm: ns16550: Allow the driver to be omitted if requested

[Simon Glass]

Allow the ns16550 debug UART to be used without the full driver.

Signed-off-by: Simon Glass 
---

 drivers/serial/ns16550.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 3fab3f1..2025423 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -440,6 +440,7 @@ static const struct udevice_id ns16550_serial_ids[] = {
 };
 #endif
 
+#if CONFIG_IS_ENABLED(SERIAL_PRESENT)
 U_BOOT_DRIVER(ns16550_serial) = {
.name   = "ns16550_serial",
.id = UCLASS_SERIAL,
@@ -453,4 +454,5 @@ U_BOOT_DRIVER(ns16550_serial) = {
.ops= &ns16550_serial_ops,
.flags  = DM_FLAG_PRE_RELOC,
 };
+#endif
 #endif /* CONFIG_DM_SERIAL */
-- 
2.6.0.rc2.230.g3dd15c0

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

Re: [U-Boot] [PATCH] eth: dtsec: fix TBI ANA setting bug in dtsec_configure_serdes()

[York Sun]

Shaohui,

Please comment/confirm.

York

On 12/09/2015 10:25 PM, 李远正 wrote:
> The value TBIANA_SETTINGS is also work on the p2041rdb board, so it can work 
> on the both phy and phyless connections.
> 
> 
> 
> At 2015-11-26 12:17:42, "Shaohui Xie"  wrote:
>>> -Original Message-
>>> From: York Sun [mailto:york...@freescale.com]
>>> Sent: Thursday, November 26, 2015 1:03 AM
>>> To: Xie Shaohui-B21989; Ciubotariu Codrin Constantin-B43658
>>> Cc: Yuanzheng Li; u-boot@lists.denx.de; Liu Dave-R63238
>>> Subject: Re: [PATCH] eth: dtsec: fix TBI ANA setting bug in
>>> dtsec_configure_serdes()
>>> 
>>> + Experts
>>> 
>>> On 11/24/2015 11:04 PM, Yuanzheng Li wrote:
>>> > The TBI_ANA register is configurated with the wrong value 0x4001,
>>> > refer to QorIQ Data Path Acceleration Architecture (DPAA) Reference
>>> Manual.
>>> > It set the reserved areas, bit 1 and bit 11 to bit 15 in big endian,
>>> > which should be cleared. But the normal functions of the
>>> > auto-negotiation, e.g. Pause and Full Duplex, do not be set.
>>[S.H] The value 0x4001 is so special, as mentioned, it does not match the 
>>DPAA RM, So I dig some docs and found AN3869, in which the 0x4001 is the
>>desired one to write to TBI_ANA for SGMII.
>> 
>>> >
>>> > There is no problem in the p2041rdb board, because the ppc is
>>> > connected directly with the phy chip which support auto-negotiation by
>>> > default in SGMII interface. But the link problem will occur when it is
>>> > connected with a switch chip like BCM5389, the switch chip disable
>>> > auto-negotiation by default, and the ppc also disable
>>> > auto-negotiation, then there is no link between them.
>>[S.H] This seems a phyless connection. If BCM5389 disables AN, then PPC should
>>Also disable AN by setting TBI_CR.
>>
>>> >
>>> > So use the vlue TBIANA_SETTINGS to enable the ppc's auto-negotiation.
>>[S.H] The TBI_ANA is " AN Advertisement Register ", it does not 
>>enable/disable AN.
>>A proper way should be to distinguish the phy and phyless connections and 
>>configure
>>The TBI registers accordingly.
>>
>>Thanks,
>>Shaohui
>>
>>> >
>>> > Signed-off-by: Yuanzheng Li 
>>> > Cc: York Sun 
>>> > ---
>>> >  drivers/net/fm/eth.c |2 +-
>>> >  1 files changed, 1 insertions(+), 1 deletions(-)
>>> >
>>> > diff --git a/drivers/net/fm/eth.c b/drivers/net/fm/eth.c index
>>> > eb8e936..78c0988 100644
>>> > --- a/drivers/net/fm/eth.c
>>> > +++ b/drivers/net/fm/eth.c
>>> > @@ -81,7 +81,7 @@ qsgmii_loop:
>>> >   tsec_local_mdio_write(phyregs, in_be32(®s->tbipa), 0, TBI_TBICON,
>>> >   TBICON_CLK_SELECT);
>>> >   tsec_local_mdio_write(phyregs, in_be32(®s->tbipa), 0, TBI_ANA,
>>> > - TBIANA_SGMII_ACK);
>>> > + TBIANA_SETTINGS);
>>> >   tsec_local_mdio_write(phyregs, in_be32(®s->tbipa), 0,
>>> >   TBI_CR, TBICR_SETTINGS);
>>> >  #endif
>>> >
>>> 
>>> Yuanzheng,
>>> 
>>> After your change, TBIANA_SGMII_ACK is not used and should be removed.
>>> 
>>> Shaohui and Codrin,
>>> 
>>> Please comment.
>>> 
>>> York
> 
> 
> 
>  
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v1] set the mmc specific addresss and range as power on write protection, you can't earse and write this range of data if you enable it after mmc power on.

[Simon Glass]

Hi Lin,

On 13 December 2015 at 19:14, Lin Huang  wrote:
> Signed-off-by: Lin Huang 
> ---
> Changes in v1:
> - Adviced by Simon:
> - use real error in errno.h to return
> - add full function comments for new function
>
>  drivers/mmc/mmc.c | 87 
> +++
>  include/mmc.h | 37 +++
>  2 files changed, 124 insertions(+)
>

This looks OK except that you seem to have put the commit message into
the subject. Can you please fix that?

Also we have a standard way of doing function comments - please see below.

> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 3a34028..1308ce9 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1821,6 +1821,93 @@ int mmc_initialize(bd_t *bis)
> return 0;
>  }
>
> +int mmc_get_wp_status(struct mmc *mmc, lbaint_t addr, char *status)
> +{
> +   struct mmc_cmd cmd;
> +   struct mmc_data data;
> +   int err;
> +
> +   cmd.cmdidx = MMC_CMD_WRITE_PROT_TYPE;
> +   cmd.resp_type = MMC_RSP_R1;
> +   cmd.cmdarg = addr;
> +
> +   data.dest = status;
> +   data.blocksize = 8;
> +   data.blocks = 1;
> +   data.flags = MMC_DATA_READ;
> +
> +   err = mmc_send_cmd(mmc, &cmd, &data);
> +
> +   return err;
> +}
> +
> +int mmc_usr_power_on_wp(struct mmc *mmc, lbaint_t addr, unsigned int size)
> +{
> +   int err;
> +   unsigned int wp_group_size, wp_grp_num, i;
> +   struct mmc_cmd cmd;
> +   unsigned int timeout = 1000;
> +   ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
> +
> +   size = size / MMC_MAX_BLOCK_LEN;
> +
> +   err = mmc_send_ext_csd(mmc, ext_csd);
> +   if (err)
> +   return err;
> +
> +   if ((ext_csd[EXT_CSD_USER_WP] & EXT_CSD_USER_PERM_WP_EN) ||
> +   (ext_csd[EXT_CSD_USER_WP] & EXT_CSD_USER_PWR_WP_DIS)) {
> +   printf("Power on protection is disabled\n");
> +   return -EINVAL;
> +   }
> +
> +   if (ext_csd[EXT_CSD_ERASE_GROUP_DEF])
> +   wp_group_size = ext_csd[EXT_CSD_HC_WP_GRP_SIZE] *
> +   ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE] * 1024;
> +   else {
> +   int erase_gsz, erase_gmul, wp_grp_size;
> +
> +   erase_gsz = (mmc->csd[2] & 0x7c00) >> 10;
> +   erase_gmul = (mmc->csd[2] & 0x03e0) >> 5;
> +   wp_grp_size = (mmc->csd[2] & 0x001f);
> +   wp_group_size = (erase_gsz + 1) * (erase_gmul + 1) *
> +   (wp_grp_size + 1);
> +   }
> +
> +   if (size < wp_group_size) {
> +   printf("wrong size, fail to set power on wp\n");
> +   return -EINVAL;
> +   }
> +
> +   err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL,
> +EXT_CSD_USER_WP, EXT_CSD_USER_PWR_WP_EN);
> +   if (err)
> +   return err;
> +
> +   wp_grp_num = DIV_ROUND_UP(size, wp_group_size);
> +   cmd.cmdidx = MMC_CMD_WRITE_PROT;
> +   cmd.resp_type = MMC_RSP_R1b;
> +
> +   for (i = 0; i < wp_grp_num; i++) {
> +   cmd.cmdarg = addr + i * wp_group_size;
> +   err = mmc_send_cmd(mmc, &cmd, NULL);
> +   if (err)
> +   return err;
> +
> +   /* CMD28/CMD29 ON failure returns address out of range error 
> */
> +   if ((cmd.response[0] >> 31) & 0x01) {
> +   printf("address for CMD28/29 out of range\n");
> +   return -EINVAL;
> +   }
> +
> +   err = mmc_send_status(mmc, timeout);
> +   if (err)
> +   return err;
> +   }
> +
> +   return 0;
> +}
> +
>  #ifdef CONFIG_SUPPORT_EMMC_BOOT
>  /*
>   * This function changes the size of boot partition and the size of rpmb
> diff --git a/include/mmc.h b/include/mmc.h
> index cda9a19..2f13eea 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -89,6 +89,8 @@
>  #define MMC_CMD_SET_BLOCK_COUNT 23
>  #define MMC_CMD_WRITE_SINGLE_BLOCK 24
>  #define MMC_CMD_WRITE_MULTIPLE_BLOCK   25
> +#define MMC_CMD_WRITE_PROT 28
> +#define MMC_CMD_WRITE_PROT_TYPE31
>  #define MMC_CMD_ERASE_GROUP_START  35
>  #define MMC_CMD_ERASE_GROUP_END36
>  #define MMC_CMD_ERASE  38
> @@ -175,6 +177,7 @@
>  #define EXT_CSD_WR_REL_PARAM   166 /* R */
>  #define EXT_CSD_WR_REL_SET 167 /* R/W */
>  #define EXT_CSD_RPMB_MULT  168 /* RO */
> +#define EXT_CSD_USER_WP171
>  #define EXT_CSD_ERASE_GROUP_DEF175 /* R/W */
>  #define EXT_CSD_BOOT_BUS_WIDTH 177
>  #define EXT_CSD_PART_CONF  179 /* R/W */
> @@ -231,6 +234,10 @@
>  #define EXT_CSD_WR_DATA_REL_USR(1 << 0)/* user data 
> area WR_REL */
>  #define EXT_CSD_WR_DATA_REL_GP(x)  (1 << ((x)+1))  /* GP part (x

Re: [U-Boot] [PATCH 1/2] microblaze: spl: Do not call mem_malloc_init and use early alloc

[Simon Glass]

Hi Michal,

On 3 February 2015 at 08:39, Michal Simek  wrote:
>
> This patch has some parts connected together:
> - Use _gd in bss section which is automatically cleared
>   Location at SPL_MALLOC_END wasn't cleared at all
> - Use MALLOC_F_LEN(early alloc) instead of FULL MALLOC
>   (mem_malloc_init is not called at all)
> - Simplify malloc and stack init.
>   At the end of SPL addr is malloc area and below is stack
>
> Signed-off-by: Michal Simek 
> ---
>
>  arch/microblaze/cpu/start.S  |  6 +-
>  include/configs/microblaze-generic.h | 32 +++-
>  2 files changed, 16 insertions(+), 22 deletions(-)
>
> diff --git a/arch/microblaze/cpu/start.S b/arch/microblaze/cpu/start.S
> index cf9ee7e3e6ad..953d3a15eef2 100644
> --- a/arch/microblaze/cpu/start.S
> +++ b/arch/microblaze/cpu/start.S
> @@ -162,7 +162,11 @@ clear_bss:
>  #endif
> braiboard_init_f
>  #else
> -   addir31, r0, CONFIG_SYS_SPL_MALLOC_END
> +   addir31, r0, _gd
> +#if defined(CONFIG_SYS_MALLOC_F_LEN)
> +   addir6, r0, CONFIG_SPL_STACK_ADDR
> +   swi r6, r31, GD_MALLOC_BASE
> +#endif
> braiboard_init_r
>  #endif
>  1: bri 1b
> diff --git a/include/configs/microblaze-generic.h 
> b/include/configs/microblaze-generic.h
> index 770acbea691b..166ab4f05654 100644
> --- a/include/configs/microblaze-generic.h
> +++ b/include/configs/microblaze-generic.h
> @@ -113,7 +113,12 @@
>  #endif
>
>  #define CONFIG_SYS_MALLOC_LEN  0xC
> -#define CONFIG_SYS_MALLOC_F_LEN1024
> +#ifndef CONFIG_SPL_BUILD
> +# define CONFIG_SYS_MALLOC_F_LEN   1024
> +#else
> +# define CONFIG_SYS_MALLOC_SIMPLE
> +# define CONFIG_SYS_MALLOC_F_LEN   0x150
> +#endif

These should be set via Kconfig - e.g. default values for your arch,
or perhaps individual values in the defconfig files. At present this
breaks when driver model is enabled by default.

Can you please take a look?

>
>  /* Stack location before relocation */
>  #define CONFIG_SYS_INIT_SP_OFFSET  CONFIG_SYS_TEXT_BASE
> @@ -426,25 +431,11 @@
>  /* BRAM start */
>  #define CONFIG_SYS_INIT_RAM_ADDR   0x0
>  /* BRAM size - will be generated */
> -#define CONFIG_SYS_INIT_RAM_SIZE   0x1
> -/* Stack pointer prior relocation, must situated at on-chip RAM */
> -#define CONFIG_SYS_SPL_MALLOC_END  (CONFIG_SYS_INIT_RAM_ADDR + \
> -CONFIG_SYS_INIT_RAM_SIZE - \
> -GENERATED_GBL_DATA_SIZE)
> +#define CONFIG_SYS_INIT_RAM_SIZE   0x10
>
> -#define CONFIG_SYS_SPL_MALLOC_SIZE 0x100
> -
> -/*
> - * The main reason to do it in this way is that MALLOC_START
> - * can't be defined - common/spl/spl.c
> - */
> -#if (CONFIG_SYS_SPL_MALLOC_SIZE != 0)
> -# define CONFIG_SYS_SPL_MALLOC_START   (CONFIG_SYS_SPL_MALLOC_END - \
> -CONFIG_SYS_SPL_MALLOC_SIZE)
> -# define CONFIG_SPL_STACK_ADDR CONFIG_SYS_SPL_MALLOC_START
> -#else
> -# define CONFIG_SPL_STACK_ADDR CONFIG_SYS_SPL_MALLOC_END
> -#endif
> +# define CONFIG_SPL_STACK_ADDR (CONFIG_SYS_INIT_RAM_ADDR + \
> +CONFIG_SYS_INIT_RAM_SIZE - \
> +CONFIG_SYS_MALLOC_F_LEN)
>
>  /* Just for sure that there is a space for stack */
>  #define CONFIG_SPL_STACK_SIZE  0x100
> @@ -453,8 +444,7 @@
>
>  #define CONFIG_SPL_MAX_FOOTPRINT   (CONFIG_SYS_INIT_RAM_SIZE - \
>  CONFIG_SYS_INIT_RAM_ADDR - \
> -GENERATED_GBL_DATA_SIZE - \
> -CONFIG_SYS_SPL_MALLOC_SIZE - \
> +CONFIG_SYS_MALLOC_F_LEN - \
>  CONFIG_SPL_STACK_SIZE)
>
>  #endif /* __CONFIG_H */
> --
> 1.8.2.3

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

Re: [U-Boot] [PATCH v2 25/26] dm: net: usb: Refactor mcs7830 driver ready for DM conversion

[Simon Glass]

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

Re: [U-Boot] [PATCH v2 24/26] pci: Tidy up comments in pci_bind_bus_devices()

[Simon Glass]

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

Re: [U-Boot] [PATCH v2 26/26] dm: net: usb: Convert mcs7830 driver to support driver model

[Simon Glass]

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

Re: [U-Boot] [PATCH v2 22/26] dm: usb: Convert echi-pci to use new DM PCI API

[Simon Glass]

Hi Marek,

On 29 November 2015 at 13:43, Marek Vasut  wrote:
> On Sunday, November 29, 2015 at 09:18:07 PM, Simon Glass wrote:
>> Convert this driver to use the new driver model PCI API.
>>
>> Signed-off-by: Simon Glass 
>> Reviewed-by: Bin Meng 
>
> ad subject -- it's EHCI, not ECHI .
>
>> ---
>>
>> Changes in v2:
>> - Use u32 instead of uint32_t
>> - Use uintptr_t to cast the hcor address
>>
>>  drivers/usb/host/ehci-pci.c | 51
>> ++--- 1 file changed, 39
>> insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
>> index d607088..cda1c6d 100644
>> --- a/drivers/usb/host/ehci-pci.c
>> +++ b/drivers/usb/host/ehci-pci.c
>> @@ -18,32 +18,34 @@ struct ehci_pci_priv {
>>   struct ehci_ctrl ehci;
>>  };
>>
>> -static void ehci_pci_common_init(pci_dev_t pdev, struct ehci_hccr
>> **ret_hccr, -  struct ehci_hcor **ret_hcor)
>> +#ifdef CONFIG_DM_USB
>> +
>> +static void ehci_pci_init(struct udevice *dev, struct ehci_hccr
>> **ret_hccr, +   struct ehci_hcor **ret_hcor)
>>  {
>>   struct ehci_hccr *hccr;
>>   struct ehci_hcor *hcor;
>> - uint32_t cmd;
>> + u32 cmd;
>>
>> - hccr = (struct ehci_hccr *)pci_map_bar(pdev,
>> + hccr = (struct ehci_hccr *)dm_pci_map_bar(dev,
>>   PCI_BASE_ADDRESS_0, PCI_REGION_MEM);
>> - hcor = (struct ehci_hcor *)((uint32_t) hccr +
>> + hcor = (struct ehci_hcor *)((uintptr_t) hccr +
>>   HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
>>
>>   debug("EHCI-PCI init hccr 0x%x and hcor 0x%x hc_length %d\n",
>> -   (uint32_t)hccr, (uint32_t)hcor,
>> -   (uint32_t)HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
>> +   (u32)hccr, (u32)hcor,
>> +   (u32)HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
>
> Use uintptr here as well then ?

That's a length rather than a pointer isn't it? Also it looks the same
as the other example.

>
>>   *ret_hccr = hccr;
>>   *ret_hcor = hcor;
>>
>>   /* enable busmaster */
>> - pci_read_config_dword(pdev, PCI_COMMAND, &cmd);
>> + dm_pci_read_config32(dev, PCI_COMMAND, &cmd);
>>   cmd |= PCI_COMMAND_MASTER;
>> - pci_write_config_dword(pdev, PCI_COMMAND, cmd);
>> + dm_pci_write_config32(dev, PCI_COMMAND, cmd);
>>  }
>
> Looks good otherwise,
>
> Acked-by: Marek Vasut 

I can always update this with a patch or even rework this patch. But for now:

Applied to u-boot-dm/next.

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

Re: [U-Boot] [PATCH v2 21/26] dm: ahci: Convert to use new DM PCI API

[Simon Glass]

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

Re: [U-Boot] [PATCH v2 23/26] dm: Convert PCI MMC over to use DM PCI API

[Simon Glass]

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

Re: [U-Boot] [PATCH v2 18/26] dm: pci: Add driver model API functions for address mapping

[Simon Glass]

On 7 December 2015 at 04:14, Bin Meng  wrote:
> Hi Simon,
>
> On Mon, Nov 30, 2015 at 4:18 AM, Simon Glass  wrote:
>> At present the PCI address map functions use the old API. Add new functions
>> for this so that drivers can be converted.
>>
>> Signed-off-by: Simon Glass 
>> ---
>>
>> Changes in v2:
>> - Add missing code in dm_pci_phys_to_bus()
>> - Rename _dm_pci_hose_bus_to_phys() to _dm_pci_bus_to_phys()
>>
>>  drivers/pci/pci-uclass.c | 136 
>> +++
>>  include/pci.h|  59 
>>  2 files changed, 195 insertions(+)
>>
>> diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
>> index 7a886f2..80e234b 100644
>> --- a/drivers/pci/pci-uclass.c
>> +++ b/drivers/pci/pci-uclass.c
>> @@ -11,6 +11,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -1068,6 +1069,141 @@ u32 dm_pci_read_bar32(struct udevice *dev, int 
>> barnum)
>> return addr & PCI_BASE_ADDRESS_MEM_MASK;
>>  }
>>
>> +static int _dm_pci_bus_to_phys(struct udevice *ctlr,
>> +   pci_addr_t bus_addr, unsigned long flags,
>> +   unsigned long skip_mask, phys_addr_t *pa)
>
> nits: the indention of the above 2 lines looks wrong.
>
>> +{
>> +   struct pci_controller *hose = dev_get_uclass_priv(ctlr);
>> +   struct pci_region *res;
>> +   int i;
>> +
>> +   for (i = 0; i < hose->region_count; i++) {
>> +   res = &hose->regions[i];
>> +
>> +   if (((res->flags ^ flags) & PCI_REGION_TYPE) != 0)
>> +   continue;
>> +
>> +   if (res->flags & skip_mask)
>> +   continue;
>> +
>> +   if (bus_addr >= res->bus_start &&
>> +   (bus_addr - res->bus_start) < res->size) {
>> +   *pa = (bus_addr - res->bus_start + res->phys_start);
>> +   return 0;
>> +   }
>> +   }
>> +
>> +   return 1;
>> +}
>> +
>> +phys_addr_t dm_pci_bus_to_phys(struct udevice *dev, pci_addr_t bus_addr,
>> +  unsigned long flags)
>> +{
>> +   phys_addr_t phys_addr = 0;
>> +   struct udevice *ctlr;
>> +   int ret;
>> +
>> +   /* The root controller has the region information */
>> +   ctlr = pci_get_controller(dev);
>> +
>> +   /*
>> +* if PCI_REGION_MEM is set we do a two pass search with preference
>> +* on matches that don't have PCI_REGION_SYS_MEMORY set
>> +*/
>> +   if ((flags & PCI_REGION_TYPE) == PCI_REGION_MEM) {
>> +   ret = _dm_pci_bus_to_phys(ctlr, bus_addr,
>> +  flags, PCI_REGION_SYS_MEMORY,
>> +  &phys_addr);
>
> nits: the indention of the above 2 lines looks wrong.
>
>> +   if (!ret)
>> +   return phys_addr;
>> +   }
>> +
>> +   ret = _dm_pci_bus_to_phys(ctlr, bus_addr, flags, 0, &phys_addr);
>> +
>> +   if (ret)
>> +   puts("pci_hose_bus_to_phys: invalid physical address\n");
>> +
>> +   return phys_addr;
>> +}
>> +
>> +int _dm_pci_phys_to_bus(struct udevice *dev, phys_addr_t phys_addr,
>> +   unsigned long flags, unsigned long skip_mask,
>> +   pci_addr_t *ba)
>> +{
>> +   struct pci_region *res;
>> +   struct udevice *ctlr;
>> +   pci_addr_t bus_addr;
>> +   int i;
>> +   struct pci_controller *hose;
>> +
>> +   /* The root controller has the region information */
>> +   ctlr = pci_get_controller(dev);
>> +   hose = dev_get_uclass_priv(ctlr);
>> +
>> +   for (i = 0; i < hose->region_count; i++) {
>> +   res = &hose->regions[i];
>> +
>> +   if (((res->flags ^ flags) & PCI_REGION_TYPE) != 0)
>> +   continue;
>> +
>> +   if (res->flags & skip_mask)
>> +   continue;
>> +
>> +   bus_addr = phys_addr - res->phys_start + res->bus_start;
>> +
>> +   if (bus_addr >= res->bus_start &&
>> +   (bus_addr - res->bus_start) < res->size) {
>> +   *ba = bus_addr;
>> +   return 0;
>> +   }
>> +   }
>> +
>> +   return 1;
>> +}
>> +
>> +pci_addr_t dm_pci_phys_to_bus(struct udevice *dev, phys_addr_t phys_addr,
>> + unsigned long flags)
>> +{
>> +   pci_addr_t bus_addr = 0;
>> +   int ret;
>> +
>> +   /*
>> +* if PCI_REGION_MEM is set we do a two pass search with preference
>> +* on matches that don't have PCI_REGION_SYS_MEMORY set
>> +*/
>> +   if ((flags & PCI_REGION_TYPE) == PCI_REGION_MEM) {
>> +   ret = _dm_pci_phys_to_bus(dev, phys_addr, flags,
>> + PCI_REGION_SYS_MEMORY, &bus_addr);
>> +   

Re: [U-Boot] [PATCH v2 17/26] dm: test: Convert PCI tests to use the DM PCI API

[Simon Glass]

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

Re: [U-Boot] [PATCH v2 16/26] dm: tegra: net: Convert tegra boards to driver model for Ethernet

[Simon Glass]

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

Re: [U-Boot] [PATCH v2 19/26] dm: net: Convert rtl8169 to use DM PCI API

[Simon Glass]

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

Re: [U-Boot] [PATCH v2 20/26] dm: pci: Switch to DM API for PCI address mapping

[Simon Glass]

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

Re: [U-Boot] [PATCH v2 15/26] dm: pci: Drop the old version of pci_find_class()

[Simon Glass]

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

Re: [U-Boot] [PATCH v2 08/26] dm: pci: Add a function to read a PCI BAR

[Simon Glass]

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

Re: [U-Boot] [PATCH v2 11/26] dm: Convert bios_interrupts to use DM PCI API

[Simon Glass]

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

Re: [U-Boot] [PATCH v2 13/26] dm: x86: pci: Adjust bios_run_on_x86() to use the DM PCI API

[Simon Glass]

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

Re: [U-Boot] [PATCH v2 10/26] dm: x86: ivybridge: Convert graphics init to use DM PCI API

[Simon Glass]

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

Re: [U-Boot] [PATCH v2 12/26] dm: pci: video: Convert video and pci_rom to use DM PCI API

[Simon Glass]

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

Re: [U-Boot] [PATCH v2 14/26] dm: pci: Drop the old version of pci_find_device/s()

[Simon Glass]

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

Re: [U-Boot] [PATCH v2 09/26] dm: serial: Convert ns16550 driver to use driver model PCI API

[Simon Glass]

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

Re: [U-Boot] [PATCH v2 05/26] dm: pci: Add a driver-model version of pci_find_device()

[Simon Glass]

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

Re: [U-Boot] [PATCH v2 03/26] dm: pci: Add a dm_ prefix to pci_bus_find_bdf()

[Simon Glass]

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

Re: [U-Boot] [PATCH v2 06/26] dm: pci: scsi: Use driver-model PCI API

[Simon Glass]

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

Re: [U-Boot] [PATCH v2 07/26] dm: pci: Add a driver-model version of pci_find_class()

[Simon Glass]

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

Re: [U-Boot] [PATCH 6/7] mmc: mmc: Don't use sprintf when using tiny-printf

[Simon Glass]

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/7] lib: split out strtoxxxx functions out of vsprintf.c

[Simon Glass]

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 02/26] dm: pci: Add a dm_ prefix to pci_get_bdf()

[Simon Glass]

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

Re: [U-Boot] [PATCH v2 01/26] dm: pci: Mark legacy files as such

[Simon Glass]

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

Re: [U-Boot] [PATCH 7/7] rockchip: firefly: Use tiny-printf

[Simon Glass]

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 04/26] dm: pci: Use driver model PCI API in auto-config

[Simon Glass]

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

Re: [U-Boot] [PATCH v2 3/3] rockchip: doc: add imagename

[Simon Glass]

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/7] lib: Split panic functions out of vsprintf.c

[Simon Glass]

On 8 December 2015 at 12:38, Simon Glass  wrote:
> Hi Scott,
>
> On 8 December 2015 at 12:36, Scott Wood  wrote:
>> On Tue, 2015-12-08 at 12:34 -0700, Simon Glass wrote:
>>> Hi Sjoerd,
>>>
>>> On 8 December 2015 at 00:27, Sjoerd Simons
>>>  wrote:
>>> >
>>> > On Mon, 2015-12-07 at 17:39 -0700, Simon Glass wrote:
>>> > > > diff --git a/lib/Makefile b/lib/Makefile
>>> > > > index 1f1ff6f..ae84833 100644
>>> > > > --- a/lib/Makefile
>>> > > > +++ b/lib/Makefile
>>> > > > @@ -85,13 +85,13 @@ obj-$(CONFIG_LIB_RAND) += rand.o
>>> > > >  ifdef CONFIG_SPL_BUILD
>>> > > >  # SPL U-Boot may use full-printf, tiny-printf or none at all
>>> > > >  ifdef CONFIG_USE_TINY_PRINTF
>>> > > > -obj-$(CONFIG_SPL_SERIAL_SUPPORT) += tiny-printf.o
>>> > > > +obj-$(CONFIG_SPL_SERIAL_SUPPORT) += tiny-printf.o panic.o
>>> > > >  else
>>> > > > -obj-$(CONFIG_SPL_SERIAL_SUPPORT) += vsprintf.o
>>> > > > +obj-$(CONFIG_SPL_SERIAL_SUPPORT) += vsprintf.o panic.o
>>> > > >  endif
>>> > > >  else
>>> > > >  # Main U-Boot always uses the full printf support
>>> > > > -obj-y += vsprintf.o
>>> > > > +obj-y += vsprintf.o panic.o
>>> > > >  endif
>>> > >
>>> > > Why not just add this outside all the ifdef stuff:
>>> > >
>>> > > obj-y += panic.o
>>> >
>>> > Just keeping the old behaviour, that code was not build for SPL builds
>>> > without serial support before. Do you see a benefit of just always
>>> > building it ?
>>>
>>> I cannot see a case where you don't build it:
>>>
>>> ifdef CONFIG_SPL_BUILD
>>> # SPL U-Boot may use full-printf, tiny-printf or none at all
>>> ifdef CONFIG_USE_TINY_PRINTF
>>> obj-$(CONFIG_SPL_SERIAL_SUPPORT) += tiny-printf.o panic.o strto.o
>>> else
>>> obj-$(CONFIG_SPL_SERIAL_SUPPORT) += vsprintf.o panic.o strto.o
>>> endif
>>> else
>>> # Main U-Boot always uses the full printf support
>>> obj-y += vsprintf.o panic.o strto.o
>>> endif
>>>
>>>
>>> Every case has panic.o and strto.o. What am I missing?
>>
>> The dependency on CONFIG_SPL_SERIAL_SUPPORT.
>
> OK, so how about this:
>
>>> ifdef CONFIG_SPL_BUILD
>>> # SPL U-Boot may use full-printf, tiny-printf or none at all
>
> obj-$(CONFIG_SPL_SERIAL_SUPPORT) += panic.o strto.o
>
>>> ifdef CONFIG_USE_TINY_PRINTF
> obj-$(CONFIG_SPL_SERIAL_SUPPORT) += tiny-printf.o
>>> else
> obj-$(CONFIG_SPL_SERIAL_SUPPORT) += vsprintf.o
>>> endif
>>> else
>>> # Main U-Boot always uses the full printf support
>>> obj-y += vsprintf.o panic.o strto.o
>>> endif

It's just a nit so I'm going to leave it as is for now.

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/7] spl: use panic_str instead of panic

[Simon Glass]

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/3] rockchip: mkimage: use imagename to select spl hdr & spl size

[Simon Glass]

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/7] lib/tiny-printf.c: Implement vprintf

[Simon Glass]

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] help - u-boot on powerpc qemu

[Miao Yan]

2015-12-13 20:29 GMT+08:00 吴红青 :
> hello,i am using u-boot on powerpc qemu,my u-boot version is
> u-boot-2016.01-rc2,i make uboot as below:
>
> cd u-boot-2016.01-rc2
> make clean
> make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- qemu-ppce500_defconfig
> make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu-
>
> then ,t execute u-boot bay qemu as below:
>
> qemu-system-ppc -M ppce500  -serial stdio -kernel u-boot -m 1024
>
> uboot show some msg as below:
>
> U-Boot 2016.01-rc2 (Dec 13 2015 - 19:54:13 +0800)
>
> CPU:   Unknown, Version: 0.0, (0x)
> Core:  e500, Version: 3.0, (0x80210030)
> Clock Configuration:
>CPU0:400  MHz,
>CCB:400  MHz,
>DDR:200  MHz (400 MT/s data rate), LBC: unknown (LCRR[CLKDIV] = 0x00)
> L1:D-cache 32 KiB enabled
>I-cache 32 KiB enabled
> DRAM:  1 GiB
> L2:disabled
> Using default environment
>
>
> PCI: base address e0008000
>   00:01.0 - 1af4:1000 - Network controller
> PCI1: Bus 00 - 00
>
> In:serial
> Out:   serial
> Err:   serial
> Net:   No ethernet found.
> Hit any key to stop autoboot:  0
> WARNING: adjusting available memory to 3000
> Wrong Image Format for bootm command
> ERROR: can't get kernel image!
> =>
>
> why no net card? can you help me?


Because you didn't specify any emulated NIC in qemu command line.

Here's a link maybe you can refer:

https://www.suse.com/documentation/sles11/book_kvm/data/cha_qemu_running_networking.html


See the "Defining a Network Interface Card" section. The commonly
used model with U-Boot should be e1000 or rtl8139 (rtl8139 is
not converted to driver model though)



Miao


>
> thanks you!!!
>
> ___
> 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] spl: mmc: use block device number, not hard-coded 0

[Eric Nelson]

Hi Tom,

On 12/13/2015 06:21 PM, Tom Rini wrote:
> On Sat, Dec 05, 2015 at 12:32:28PM -0700, Eric Nelson wrote:
>
>> In order to support boot from multiple devices through board_boot_order,
>> it's necessary to use the block number of a device.
>>
>> The use of a hard-coded 0 for the device number also creates a need
>> to re-order block devices for use in SPL like this:
>>  
>> http://git.denx.de/?p=u-boot.git;a=blob;f=board/freescale/mx6slevk/mx6slevk.c;hb=HEAD#l195
> 
> We also do similar'ish things for TI parts (we only register what we're
> booting from).
>
> So, before this can be applied don't we also need a patch for mx6slevk
> and for TI ones too (but that should be "easier" since I think it
> just becomes we always use the normal board_mmc_init) ?

We don't **need** a patch to support existing use cases because the
patch uses the dev number in the block device directly
(mmc->block_dev.dev).

https://patchwork.ozlabs.org/patch/553026/

I'm not sure about TI boards, but the i.MX6SL EVK code swaps the
non-SPL ordering of mmc devices when compiled for SPL in order
to handle the hard-coded zero:


http://git.denx.de/?p=u-boot.git;a=blob;f=board/freescale/mx6slevk/mx6slevk.c;hb=HEAD#l195

In other words, "mmc 0" becomes "mmc 1" and vice versa.

The trouble with this approach is that you can't allow for multiple
MMC devices through board_boot_order, because the second will be
device number 1.

Regards,


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

Re: [U-Boot] [PATCH] mmc: implement mmc power on write protect function

[hl]

Hi Simon,

Thanks for reviewing, i have upload a new patch to fix your comment.

On 11/12/15 11:20, Simon Glass wrote:

Hi Lin,

On 3 December 2015 at 01:34, Lin Huang  wrote:

set the mmc specific addresss and range as power on
write protection, and can't earse and write this range
if you enable it after mmc power on.

Signed-off-by: Lin Huang 
---
  drivers/mmc/mmc.c | 89 +++
  include/mmc.h | 10 ++-
  2 files changed, 98 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 2a58702..60ff5be 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1819,6 +1819,95 @@ int mmc_initialize(bd_t *bis)
 return 0;
  }

+int mmc_get_wp_status(struct mmc *mmc, lbaint_t addr, char *status)
+{
+   struct mmc_cmd cmd;
+   struct mmc_data data;
+   int err;
+
+   cmd.cmdidx = MMC_CMD_WRITE_PROT_TYPE;
+   cmd.resp_type = MMC_RSP_R1;
+   cmd.cmdarg = addr;
+
+   data.dest = status;
+   data.blocksize = 8;
+   data.blocks = 1;
+   data.flags = MMC_DATA_READ;
+
+   err = mmc_send_cmd(mmc, &cmd, &data);
+   if (err)
+   return err;
+   return err;

return 0 I think

Unless you just want to always return err.


+}
+
+int mmc_usr_power_on_wp(struct mmc *mmc, lbaint_t addr, unsigned int size)
+{
+   int err;
+   unsigned int wp_group_size, wp_grp_num, i;
+   struct mmc_cmd cmd;
+   unsigned int timeout = 1000;
+

drop blank line


+   ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
+
+   size = size / MMC_MAX_BLOCK_LEN;
+
+   err = mmc_send_ext_csd(mmc, ext_csd);
+   if (err)
+   return err;
+
+   if ((ext_csd[EXT_CSD_USER_WP] & EXT_CSD_USER_PERM_WP_EN) ||
+   (ext_csd[EXT_CSD_USER_WP] & EXT_CSD_USER_PWR_WP_DIS)) {
+   printf("Power on protection is disabled\n");
+   return -1;

Can you run a real error in errno.h to return?


+   }
+
+   if (ext_csd[EXT_CSD_ERASE_GROUP_DEF])
+   wp_group_size = ext_csd[EXT_CSD_HC_WP_GRP_SIZE] *
+   ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE] * 1024;
+   else {
+   int erase_gsz, erase_gmul, wp_grp_size;
+
+   erase_gsz = (mmc->csd[2] & 0x7c00) >> 10;
+   erase_gmul = (mmc->csd[2] & 0x03e0) >> 5;
+   wp_grp_size = (mmc->csd[2] & 0x001f);
+   wp_group_size = (erase_gsz + 1) * (erase_gmul + 1) *
+   (wp_grp_size + 1);
+   }
+
+   if (size < wp_group_size) {
+   printf("wrong size, fail to set power on wp\n");
+   return -1;

Can you run a real error in errno.h to return?


+   }
+
+   err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL,
+EXT_CSD_USER_WP, EXT_CSD_USER_PWR_WP_EN);
+   if (err)
+   return err;
+
+   wp_grp_num = DIV_ROUND_UP(size, wp_group_size);
+   cmd.cmdidx = MMC_CMD_WRITE_PROT;
+   cmd.resp_type = MMC_RSP_R1b;
+
+   for (i = 0; i < wp_grp_num; i++) {
+   cmd.cmdarg = addr + i * wp_group_size;
+   err = mmc_send_cmd(mmc, &cmd, NULL);
+   if (err)
+   return err;
+
+   /* CMD28/CMD29 ON failure returns address out of range error */
+   if ((cmd.response[0] >> 31) & 0x01) {
+   printf("address for CMD28/29 out of range\n");
+   return -1;

-EINVAL?


+   }
+
+   err = mmc_send_status(mmc, timeout);
+   if (err)
+   return err;
+   }
+
+   return 0;
+}
+
  #ifdef CONFIG_SUPPORT_EMMC_BOOT
  /*
   * This function changes the size of boot partition and the size of rpmb
diff --git a/include/mmc.h b/include/mmc.h
index cda9a19..448d5a8 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -89,6 +89,8 @@
  #define MMC_CMD_SET_BLOCK_COUNT 23
  #define MMC_CMD_WRITE_SINGLE_BLOCK 24
  #define MMC_CMD_WRITE_MULTIPLE_BLOCK   25
+#define MMC_CMD_WRITE_PROT 28
+#define MMC_CMD_WRITE_PROT_TYPE31
  #define MMC_CMD_ERASE_GROUP_START  35
  #define MMC_CMD_ERASE_GROUP_END36
  #define MMC_CMD_ERASE  38
@@ -175,6 +177,7 @@
  #define EXT_CSD_WR_REL_PARAM   166 /* R */
  #define EXT_CSD_WR_REL_SET 167 /* R/W */
  #define EXT_CSD_RPMB_MULT  168 /* RO */
+#define EXT_CSD_USER_WP171
  #define EXT_CSD_ERASE_GROUP_DEF175 /* R/W */
  #define EXT_CSD_BOOT_BUS_WIDTH 177
  #define EXT_CSD_PART_CONF  179 /* R/W */
@@ -231,6 +234,10 @@
  #define EXT_CSD_WR_DATA_REL_USR(1 << 0)/* user data 
area WR_REL */
  #define EXT_CSD_WR_DATA_REL_GP(x)  (1 << ((x)+1))  /* GP part (x+1) 
WR_REL */

+#define EXT_CSD_USER_PWR_WP_DIS   

[U-Boot] [PATCH v1] set the mmc specific addresss and range as power on write protection, you can't earse and write this range of data if you enable it after mmc power on.

[Lin Huang]

Signed-off-by: Lin Huang 
---
Changes in v1:
- Adviced by Simon:
- use real error in errno.h to return
- add full function comments for new function

 drivers/mmc/mmc.c | 87 +++
 include/mmc.h | 37 +++
 2 files changed, 124 insertions(+)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 3a34028..1308ce9 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1821,6 +1821,93 @@ int mmc_initialize(bd_t *bis)
return 0;
 }
 
+int mmc_get_wp_status(struct mmc *mmc, lbaint_t addr, char *status)
+{
+   struct mmc_cmd cmd;
+   struct mmc_data data;
+   int err;
+
+   cmd.cmdidx = MMC_CMD_WRITE_PROT_TYPE;
+   cmd.resp_type = MMC_RSP_R1;
+   cmd.cmdarg = addr;
+
+   data.dest = status;
+   data.blocksize = 8;
+   data.blocks = 1;
+   data.flags = MMC_DATA_READ;
+
+   err = mmc_send_cmd(mmc, &cmd, &data);
+
+   return err;
+}
+
+int mmc_usr_power_on_wp(struct mmc *mmc, lbaint_t addr, unsigned int size)
+{
+   int err;
+   unsigned int wp_group_size, wp_grp_num, i;
+   struct mmc_cmd cmd;
+   unsigned int timeout = 1000;
+   ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
+
+   size = size / MMC_MAX_BLOCK_LEN;
+
+   err = mmc_send_ext_csd(mmc, ext_csd);
+   if (err)
+   return err;
+
+   if ((ext_csd[EXT_CSD_USER_WP] & EXT_CSD_USER_PERM_WP_EN) ||
+   (ext_csd[EXT_CSD_USER_WP] & EXT_CSD_USER_PWR_WP_DIS)) {
+   printf("Power on protection is disabled\n");
+   return -EINVAL;
+   }
+
+   if (ext_csd[EXT_CSD_ERASE_GROUP_DEF])
+   wp_group_size = ext_csd[EXT_CSD_HC_WP_GRP_SIZE] *
+   ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE] * 1024;
+   else {
+   int erase_gsz, erase_gmul, wp_grp_size;
+
+   erase_gsz = (mmc->csd[2] & 0x7c00) >> 10;
+   erase_gmul = (mmc->csd[2] & 0x03e0) >> 5;
+   wp_grp_size = (mmc->csd[2] & 0x001f);
+   wp_group_size = (erase_gsz + 1) * (erase_gmul + 1) *
+   (wp_grp_size + 1);
+   }
+
+   if (size < wp_group_size) {
+   printf("wrong size, fail to set power on wp\n");
+   return -EINVAL;
+   }
+
+   err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL,
+EXT_CSD_USER_WP, EXT_CSD_USER_PWR_WP_EN);
+   if (err)
+   return err;
+
+   wp_grp_num = DIV_ROUND_UP(size, wp_group_size);
+   cmd.cmdidx = MMC_CMD_WRITE_PROT;
+   cmd.resp_type = MMC_RSP_R1b;
+
+   for (i = 0; i < wp_grp_num; i++) {
+   cmd.cmdarg = addr + i * wp_group_size;
+   err = mmc_send_cmd(mmc, &cmd, NULL);
+   if (err)
+   return err;
+
+   /* CMD28/CMD29 ON failure returns address out of range error */
+   if ((cmd.response[0] >> 31) & 0x01) {
+   printf("address for CMD28/29 out of range\n");
+   return -EINVAL;
+   }
+
+   err = mmc_send_status(mmc, timeout);
+   if (err)
+   return err;
+   }
+
+   return 0;
+}
+
 #ifdef CONFIG_SUPPORT_EMMC_BOOT
 /*
  * This function changes the size of boot partition and the size of rpmb
diff --git a/include/mmc.h b/include/mmc.h
index cda9a19..2f13eea 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -89,6 +89,8 @@
 #define MMC_CMD_SET_BLOCK_COUNT 23
 #define MMC_CMD_WRITE_SINGLE_BLOCK 24
 #define MMC_CMD_WRITE_MULTIPLE_BLOCK   25
+#define MMC_CMD_WRITE_PROT 28
+#define MMC_CMD_WRITE_PROT_TYPE31
 #define MMC_CMD_ERASE_GROUP_START  35
 #define MMC_CMD_ERASE_GROUP_END36
 #define MMC_CMD_ERASE  38
@@ -175,6 +177,7 @@
 #define EXT_CSD_WR_REL_PARAM   166 /* R */
 #define EXT_CSD_WR_REL_SET 167 /* R/W */
 #define EXT_CSD_RPMB_MULT  168 /* RO */
+#define EXT_CSD_USER_WP171
 #define EXT_CSD_ERASE_GROUP_DEF175 /* R/W */
 #define EXT_CSD_BOOT_BUS_WIDTH 177
 #define EXT_CSD_PART_CONF  179 /* R/W */
@@ -231,6 +234,10 @@
 #define EXT_CSD_WR_DATA_REL_USR(1 << 0)/* user data 
area WR_REL */
 #define EXT_CSD_WR_DATA_REL_GP(x)  (1 << ((x)+1))  /* GP part (x+1) WR_REL 
*/
 
+#define EXT_CSD_USER_PWR_WP_DIS(1 << 3) /* disable power-on 
write protect*/
+#define EXT_CSD_USER_PERM_WP_EN(1 << 2) /* enable permanent 
write protect */
+#define EXT_CSD_USER_PWR_WP_EN (1 << 0) /* enable power-on write 
protect */
+
 #define R1_ILLEGAL_COMMAND (1 << 22)
 #define R1_APP_CMD (1 << 5)
 
@@ -478,6 +485,36 @@ int mmc_get_env_addr(struct mmc *mmc, int copy, u32 
*env_addr);
 
 struct pci_device_id;
 
+/*
+ 

Re: [U-Boot] [PATCH 3/5][v5] include/linux: move typdef for uintptr_t

[York Sun]

Resend with my freescale id.

I would like to merge this patch if no objection.

York


On 12/08/2015 08:45 AM, York Sun wrote:
> 
> 
> On 12/08/2015 12:24 AM, Aneesh Bansal wrote:
>> uintptr_t which is a typdef for unsigned long is needed for creating
>> pointers (32 or 64 bit depending on Core) from 32 bit variables
>> storing the address.
>> If a 32 bit variable (u32) is typecasted to a pointer (void *),
>> compiler gives a warning in case size of pointer on the core is 64 bit.
>>
>> The typdef has been moved from include/compiler.h to include/linux/types.h
>>
>> Signed-off-by: Aneesh Bansal 
>> ---
>> Changes in v5:
>> New patch instead of http://patchwork.ozlabs.org/patch/546319/
>>
>> Changes in v4: None
>>
>> Changes in v3: None
>>
>> Changes in v2: None
>>
>>  include/compiler.h| 3 ---
>>  include/linux/types.h | 1 +
>>  2 files changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/include/compiler.h b/include/compiler.h
>> index 47c296e..f853ed4 100644
>> --- a/include/compiler.h
>> +++ b/include/compiler.h
>> @@ -115,9 +115,6 @@ typedef unsigned int uint;
>>  #ifdef CONFIG_USE_STDINT
>>  /* Provided by gcc. */
>>  #include 
>> -#else
>> -/* Type for `void *' pointers. */
>> -typedef unsigned long int uintptr_t;
>>  #endif
>>  
>>  #include 
>> diff --git a/include/linux/types.h b/include/linux/types.h
>> index 6f75be4..c7e8fdb 100644
>> --- a/include/linux/types.h
>> +++ b/include/linux/types.h
>> @@ -124,6 +124,7 @@ typedef  __UINT64_TYPE__ u_int64_t;
>>  typedef __INT64_TYPE__  int64_t;
>>  #endif
>>  
>> +typedef unsigned long uintptr_t;
>>  /*
>>   * Below are truly Linux-specific types that should never collide with
>>   * any application/library that wants linux/types.h.
>>
> 
> Tom,
> 
> Please help review this change. I can compile test for power and arm but I 
> don't
> have the setup for other platforms.
> 
> York
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/5][v5] include/linux: move typdef for uintptr_t

[York Sun]

I would like to merge this one if no objection.

York


On 12/08/2015 08:45 AM, York Sun wrote:
> 
> 
> On 12/08/2015 12:24 AM, Aneesh Bansal wrote:
>> uintptr_t which is a typdef for unsigned long is needed for creating
>> pointers (32 or 64 bit depending on Core) from 32 bit variables
>> storing the address.
>> If a 32 bit variable (u32) is typecasted to a pointer (void *),
>> compiler gives a warning in case size of pointer on the core is 64 bit.
>>
>> The typdef has been moved from include/compiler.h to include/linux/types.h
>>
>> Signed-off-by: Aneesh Bansal 
>> ---
>> Changes in v5:
>> New patch instead of http://patchwork.ozlabs.org/patch/546319/
>>
>> Changes in v4: None
>>
>> Changes in v3: None
>>
>> Changes in v2: None
>>
>>  include/compiler.h| 3 ---
>>  include/linux/types.h | 1 +
>>  2 files changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/include/compiler.h b/include/compiler.h
>> index 47c296e..f853ed4 100644
>> --- a/include/compiler.h
>> +++ b/include/compiler.h
>> @@ -115,9 +115,6 @@ typedef unsigned int uint;
>>  #ifdef CONFIG_USE_STDINT
>>  /* Provided by gcc. */
>>  #include 
>> -#else
>> -/* Type for `void *' pointers. */
>> -typedef unsigned long int uintptr_t;
>>  #endif
>>  
>>  #include 
>> diff --git a/include/linux/types.h b/include/linux/types.h
>> index 6f75be4..c7e8fdb 100644
>> --- a/include/linux/types.h
>> +++ b/include/linux/types.h
>> @@ -124,6 +124,7 @@ typedef  __UINT64_TYPE__ u_int64_t;
>>  typedef __INT64_TYPE__  int64_t;
>>  #endif
>>  
>> +typedef unsigned long uintptr_t;
>>  /*
>>   * Below are truly Linux-specific types that should never collide with
>>   * any application/library that wants linux/types.h.
>>
> 
> Tom,
> 
> Please help review this change. I can compile test for power and arm but I 
> don't
> have the setup for other platforms.
> 
> York
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Marek Vasut]

On Monday, December 14, 2015 at 02:22:32 AM, Chin Liang See wrote:

[..]

> > > After grabbing a coffee
> > 
> > That's a good idea, though I think I will make do with a green tea
> > (抹茶).
> 
> Yeah, beside green tea, genmaicha (玄米茶) is one of my top choice too. :)

The one with baked rice in it, right ? I love that as well :)

> > > and rethinking, we can have 2 MTD_PARTITION
> > > where one for backward compatiblity (supporting raw) while another
> > > for
> > > UBI.
> > > 
> > > MTDPARTS_RAW
> > > 256k(spl),
> > > 256k(env),
> > > 15872k(boot),
> > > -(rootfs)
> > > 
> > > MTDPARTS_UBI
> > > 256k(spl),
> > > 256k(env),
> > > -(UBI)
> > > 
> > > We should make UBI as default then. If user care about backward
> > > compatiblity, they shall use the MTDPARTS_RAW then.
> > 
> > Try this:
> > 
> > mtdparts=1m(u-boot),256k(env1),256k(env2),14848k(boot),112m(root),
> > -@1536k(UBI)
> > 
> > This will create overlapping partitions "boot,root" and "UBI" .
> 
> Nice, let me give it a try.

Make sure to test it in Linux too ;-)

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 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Chin Liang See]

On Mon, 2015-12-14 at 01:58 +0100, Marek Vasut wrote:
> On Monday, December 14, 2015 at 01:43:58 AM, Chin Liang See wrote:
> > On Mon, 2015-12-14 at 01:22 +0100, Marek Vasut wrote:
> > > On Monday, December 14, 2015 at 01:11:27 AM, Chin Liang See
> > > wrote:
> > > > On Sun, 2015-12-13 at 16:42 +0100, Marek Vasut wrote:
> > > > > On Sunday, December 13, 2015 at 02:03:02 PM, Chin Liang See
> > > > > 
> > > > > wrote:
> > > > > > On Sun, 2015-12-13 at 04:14 +0100, Marek Vasut wrote:
> > > > > > > On Sunday, December 13, 2015 at 01:49:06 AM, Chin Liang
> > > > > > > See
> > > > > > > 
> > > > > > > wrote:
> > > > > > > > On Sun, 2015-12-13 at 01:01 +0100, Marek Vasut wrote:
> > > > > > > > > On Sunday, December 13, 2015 at 12:59:48 AM, Chin
> > > > > > > > > Liang
> > > > > > > > > See
> > > > > > > > > 
> > > > > > > > > wrote:
> > > > > > > > > > On Sat, 2015-12-12 at 16:36 +0100, Marek Vasut
> > > > > > > > > > wrote:
> > > > > > > > > > > On Saturday, December 12, 2015 at 07:30:46 AM,
> > > > > > > > > > > Chin
> > > > > > > > > > > Liang
> > > > > > > > > > > See
> > > > > > > > > > 
> > > > > > > > > > > wrote:
> > > > > > > > > > [...]
> > > > > > > > > > 
> > > > > > > > > > > > > Can you share the final layout before you
> > > > > > > > > > > > > roll
> > > > > > > > > > > > > out
> > > > > > > > > > > > > patches ?
> > > > > > > > > > > > 
> > > > > > > > > > > > Sure, plan to do so but need to away from desk
> > > > > > > > > > > > just
> > > > > > > > > > > > now.
> > > > > > > > > > > > 
> > > > > > > > > > > > Here is the old layout
> > > > > > > > > > > > 256k(spl)
> > > > > > > > > > > > 64k(env)
> > > > > > > > > > > > 64k(dtb)
> > > > > > > > > > > > 256k(boot)
> > > > > > > > > > > > 16m(kernel)
> > > > > > > > > > > > 16m(rootfs)
> > > > > > > > > > > > 
> > > > > > > > > > > > The new one would like this
> > > > > > > > > > > > 256k(spl)
> > > > > > > > > > > 
> > > > > > > > > > > I'd say you should just call this u-boot, see
> > > > > > > > > > > above
> > > > > > > > > > > for
> > > > > > > > > > > the
> > > > > > > > > > > rationale.
> > > > > > > > > > > 
> > > > > > > > > > > > 256k(env)
> > > > > > > > > > > > 15872k(boot)
> > > > > > > > > > > > 16m(rootfs)
> > > > > > > > > > > > 
> > > > > > > > > > > > The boot partition can be used as ubi part or
> > > > > > > > > > > > raw
> > > > > > > > > > > > partition.
> > > > > > > > > > > > It contains the linux dtb, u-boot and linux
> > > > > > > > > > > > images.
> > > > > > > > > > > 
> > > > > > > > > > > Is that an UBIFS partition ? If so, why don't you
> > > > > > > > > > > just
> > > > > > > > > > > use
> > > > > > > > > > > two
> > > > > > > > > > > UBI
> > > > > > > > > > > volumes ?
> > > > > > > > > > 
> > > > > > > > > > For backward compatibility, it can be raw if user
> > > > > > > > > > want
> > > > > > > > > > to
> > > > > > > > > > stick
> > > > > > > > > > with
> > > > > > > > > > old way.
> > > > > > > > > 
> > > > > > > > > If you're breaking the partitioning layout anyway,
> > > > > > > > > you
> > > > > > > > > don't
> > > > > > > > > have
> > > > > > > > > to
> > > > > > > > > care about the "old way", right ?
> > > > > > > > 
> > > > > > > > Actually this partition can be used as raw partition if
> > > > > > > > user
> > > > > > > > don't
> > > > > > > > want
> > > > > > > > to store zimage and dtb as raw binary.
> > > > > > > 
> > > > > > > You should never store raw zImage/dtb in a flash on a
> > > > > > > production
> > > > > > > system.
> > > > > > > This is real bad and can result in a corruption in the
> > > > > > > future
> > > > > > > when
> > > > > > > the
> > > > > > > system is in the field for a long time. I'd suggest to
> > > > > > > just
> > > > > > > use
> > > > > > > two
> > > > > > > UBI
> > > > > > > volumes, one for fitImage and the other for rootfs.
> > > > > > 
> > > > > > Yup, we are trying to move the raw away by having UBI
> > > > > > enabled.
> > > > > > I
> > > > > > presume when you refer 2 UBI volumes, I presume its still
> > > > > > single
> > > > > > UBI
> > > > > > partition?
> > > > > 
> > > > > Yeah, one UBI partition with two UBI volumes -- boot and
> > > > > root.
> > > > 
> > > > Ok I grasp you correctly. In this case, I would suggest to opt
> > > > for
> > > > 2
> > > > partitions instead of 2 volumes. User can just use sf erase
> > > > rootfs
> > > > instead of checking for volume offset. I suspect the ubi part
> > > > will
> > > > take
> > > > longer time if we are having one partition only. I shall send
> > > > out
> > > > the
> > > > new revision if this works for you :)
> > > 
> > > Oh, I see what you're concerned about. On the other hand, you are
> > > not
> > > supposed
> > > to erase UBI partition, since that'd nuke the UBI erase counters
> > > and
> > > UBI would
> > > loose track of how many times each block was erased, which helps
> > > with
> > > wear
> > > leveling.
> > > 
> > > If you're adamant about two UBI partitions , you can try the
> > > trick
> > > where 

Re: [U-Boot] spl: mmc: use block device number, not hard-coded 0

[Tom Rini]

On Sat, Dec 05, 2015 at 12:32:28PM -0700, Eric Nelson wrote:
> In order to support boot from multiple devices through board_boot_order,
> it's necessary to use the block number of a device.
> 
> The use of a hard-coded 0 for the device number also creates a need
> to re-order block devices for use in SPL like this:
>   
> http://git.denx.de/?p=u-boot.git;a=blob;f=board/freescale/mx6slevk/mx6slevk.c;hb=HEAD#l195

We also do similar'ish things for TI parts (we only register what we're
booting from).  So, before this can be applied don't we also need a
patch for mx6slevk and for TI ones too (but that should be "easier"
since I think it just becomes we always use the normal board_mmc_init) ?
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: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Chin Liang See]

On Mon, 2015-12-14 at 01:22 +0100, Marek Vasut wrote:
> On Monday, December 14, 2015 at 01:11:27 AM, Chin Liang See wrote:
> > On Sun, 2015-12-13 at 16:42 +0100, Marek Vasut wrote:
> > > On Sunday, December 13, 2015 at 02:03:02 PM, Chin Liang See
> > > wrote:
> > > > On Sun, 2015-12-13 at 04:14 +0100, Marek Vasut wrote:
> > > > > On Sunday, December 13, 2015 at 01:49:06 AM, Chin Liang See
> > > > > 
> > > > > wrote:
> > > > > > On Sun, 2015-12-13 at 01:01 +0100, Marek Vasut wrote:
> > > > > > > On Sunday, December 13, 2015 at 12:59:48 AM, Chin Liang
> > > > > > > See
> > > > > > > 
> > > > > > > wrote:
> > > > > > > > On Sat, 2015-12-12 at 16:36 +0100, Marek Vasut wrote:
> > > > > > > > > On Saturday, December 12, 2015 at 07:30:46 AM, Chin
> > > > > > > > > Liang
> > > > > > > > > See
> > > > > > > > 
> > > > > > > > > wrote:
> > > > > > > > [...]
> > > > > > > > 
> > > > > > > > > > > Can you share the final layout before you roll
> > > > > > > > > > > out
> > > > > > > > > > > patches ?
> > > > > > > > > > 
> > > > > > > > > > Sure, plan to do so but need to away from desk just
> > > > > > > > > > now.
> > > > > > > > > > 
> > > > > > > > > > Here is the old layout
> > > > > > > > > > 256k(spl)
> > > > > > > > > > 64k(env)
> > > > > > > > > > 64k(dtb)
> > > > > > > > > > 256k(boot)
> > > > > > > > > > 16m(kernel)
> > > > > > > > > > 16m(rootfs)
> > > > > > > > > > 
> > > > > > > > > > The new one would like this
> > > > > > > > > > 256k(spl)
> > > > > > > > > 
> > > > > > > > > I'd say you should just call this u-boot, see above
> > > > > > > > > for
> > > > > > > > > the
> > > > > > > > > rationale.
> > > > > > > > > 
> > > > > > > > > > 256k(env)
> > > > > > > > > > 15872k(boot)
> > > > > > > > > > 16m(rootfs)
> > > > > > > > > > 
> > > > > > > > > > The boot partition can be used as ubi part or raw
> > > > > > > > > > partition.
> > > > > > > > > > It contains the linux dtb, u-boot and linux images.
> > > > > > > > > 
> > > > > > > > > Is that an UBIFS partition ? If so, why don't you
> > > > > > > > > just
> > > > > > > > > use
> > > > > > > > > two
> > > > > > > > > UBI
> > > > > > > > > volumes ?
> > > > > > > > 
> > > > > > > > For backward compatibility, it can be raw if user want
> > > > > > > > to
> > > > > > > > stick
> > > > > > > > with
> > > > > > > > old way.
> > > > > > > 
> > > > > > > If you're breaking the partitioning layout anyway, you
> > > > > > > don't
> > > > > > > have
> > > > > > > to
> > > > > > > care about the "old way", right ?
> > > > > > 
> > > > > > Actually this partition can be used as raw partition if
> > > > > > user
> > > > > > don't
> > > > > > want
> > > > > > to store zimage and dtb as raw binary.
> > > > > 
> > > > > You should never store raw zImage/dtb in a flash on a
> > > > > production
> > > > > system.
> > > > > This is real bad and can result in a corruption in the future
> > > > > when
> > > > > the
> > > > > system is in the field for a long time. I'd suggest to just
> > > > > use
> > > > > two
> > > > > UBI
> > > > > volumes, one for fitImage and the other for rootfs.
> > > > 
> > > > Yup, we are trying to move the raw away by having UBI enabled.
> > > > I
> > > > presume when you refer 2 UBI volumes, I presume its still
> > > > single
> > > > UBI
> > > > partition?
> > > 
> > > Yeah, one UBI partition with two UBI volumes -- boot and root.
> > 
> > Ok I grasp you correctly. In this case, I would suggest to opt for
> > 2
> > partitions instead of 2 volumes. User can just use sf erase rootfs
> > instead of checking for volume offset. I suspect the ubi part will
> > take
> > longer time if we are having one partition only. I shall send out
> > the
> > new revision if this works for you :)
> 
> Oh, I see what you're concerned about. On the other hand, you are not
> supposed 
> to erase UBI partition, since that'd nuke the UBI erase counters and
> UBI would
> loose track of how many times each block was erased, which helps with
> wear 
> leveling.
> 
> If you're adamant about two UBI partitions , you can try the trick
> where you can
> create overlapping mtd partitions, that way you'd have both options
> available.
> (it is actually a legal construction, you can check the kernel MTD
> docs).

After grabbing a coffee and rethinking, we can have 2 MTD_PARTITION
where one for backward compatiblity (supporting raw) while another for
UBI. 

MTDPARTS_RAW
256k(spl),
256k(env),
15872k(boot),
-(rootfs)

MTDPARTS_UBI
256k(spl),
256k(env),
-(UBI)

We should make UBI as default then. If user care about backward compatiblity, 
they shall use the MTDPARTS_RAW then.

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

Re: [U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Marek Vasut]

On Monday, December 14, 2015 at 01:43:58 AM, Chin Liang See wrote:
> On Mon, 2015-12-14 at 01:22 +0100, Marek Vasut wrote:
> > On Monday, December 14, 2015 at 01:11:27 AM, Chin Liang See wrote:
> > > On Sun, 2015-12-13 at 16:42 +0100, Marek Vasut wrote:
> > > > On Sunday, December 13, 2015 at 02:03:02 PM, Chin Liang See
> > > > 
> > > > wrote:
> > > > > On Sun, 2015-12-13 at 04:14 +0100, Marek Vasut wrote:
> > > > > > On Sunday, December 13, 2015 at 01:49:06 AM, Chin Liang See
> > > > > > 
> > > > > > wrote:
> > > > > > > On Sun, 2015-12-13 at 01:01 +0100, Marek Vasut wrote:
> > > > > > > > On Sunday, December 13, 2015 at 12:59:48 AM, Chin Liang
> > > > > > > > See
> > > > > > > > 
> > > > > > > > wrote:
> > > > > > > > > On Sat, 2015-12-12 at 16:36 +0100, Marek Vasut wrote:
> > > > > > > > > > On Saturday, December 12, 2015 at 07:30:46 AM, Chin
> > > > > > > > > > Liang
> > > > > > > > > > See
> > > > > > > > > 
> > > > > > > > > > wrote:
> > > > > > > > > [...]
> > > > > > > > > 
> > > > > > > > > > > > Can you share the final layout before you roll
> > > > > > > > > > > > out
> > > > > > > > > > > > patches ?
> > > > > > > > > > > 
> > > > > > > > > > > Sure, plan to do so but need to away from desk just
> > > > > > > > > > > now.
> > > > > > > > > > > 
> > > > > > > > > > > Here is the old layout
> > > > > > > > > > > 256k(spl)
> > > > > > > > > > > 64k(env)
> > > > > > > > > > > 64k(dtb)
> > > > > > > > > > > 256k(boot)
> > > > > > > > > > > 16m(kernel)
> > > > > > > > > > > 16m(rootfs)
> > > > > > > > > > > 
> > > > > > > > > > > The new one would like this
> > > > > > > > > > > 256k(spl)
> > > > > > > > > > 
> > > > > > > > > > I'd say you should just call this u-boot, see above
> > > > > > > > > > for
> > > > > > > > > > the
> > > > > > > > > > rationale.
> > > > > > > > > > 
> > > > > > > > > > > 256k(env)
> > > > > > > > > > > 15872k(boot)
> > > > > > > > > > > 16m(rootfs)
> > > > > > > > > > > 
> > > > > > > > > > > The boot partition can be used as ubi part or raw
> > > > > > > > > > > partition.
> > > > > > > > > > > It contains the linux dtb, u-boot and linux images.
> > > > > > > > > > 
> > > > > > > > > > Is that an UBIFS partition ? If so, why don't you
> > > > > > > > > > just
> > > > > > > > > > use
> > > > > > > > > > two
> > > > > > > > > > UBI
> > > > > > > > > > volumes ?
> > > > > > > > > 
> > > > > > > > > For backward compatibility, it can be raw if user want
> > > > > > > > > to
> > > > > > > > > stick
> > > > > > > > > with
> > > > > > > > > old way.
> > > > > > > > 
> > > > > > > > If you're breaking the partitioning layout anyway, you
> > > > > > > > don't
> > > > > > > > have
> > > > > > > > to
> > > > > > > > care about the "old way", right ?
> > > > > > > 
> > > > > > > Actually this partition can be used as raw partition if
> > > > > > > user
> > > > > > > don't
> > > > > > > want
> > > > > > > to store zimage and dtb as raw binary.
> > > > > > 
> > > > > > You should never store raw zImage/dtb in a flash on a
> > > > > > production
> > > > > > system.
> > > > > > This is real bad and can result in a corruption in the future
> > > > > > when
> > > > > > the
> > > > > > system is in the field for a long time. I'd suggest to just
> > > > > > use
> > > > > > two
> > > > > > UBI
> > > > > > volumes, one for fitImage and the other for rootfs.
> > > > > 
> > > > > Yup, we are trying to move the raw away by having UBI enabled.
> > > > > I
> > > > > presume when you refer 2 UBI volumes, I presume its still
> > > > > single
> > > > > UBI
> > > > > partition?
> > > > 
> > > > Yeah, one UBI partition with two UBI volumes -- boot and root.
> > > 
> > > Ok I grasp you correctly. In this case, I would suggest to opt for
> > > 2
> > > partitions instead of 2 volumes. User can just use sf erase rootfs
> > > instead of checking for volume offset. I suspect the ubi part will
> > > take
> > > longer time if we are having one partition only. I shall send out
> > > the
> > > new revision if this works for you :)
> > 
> > Oh, I see what you're concerned about. On the other hand, you are not
> > supposed
> > to erase UBI partition, since that'd nuke the UBI erase counters and
> > UBI would
> > loose track of how many times each block was erased, which helps with
> > wear
> > leveling.
> > 
> > If you're adamant about two UBI partitions , you can try the trick
> > where you can
> > create overlapping mtd partitions, that way you'd have both options
> > available.
> > (it is actually a legal construction, you can check the kernel MTD
> > docs).
> 
> After grabbing a coffee

That's a good idea, though I think I will make do with a green tea (抹茶).

> and rethinking, we can have 2 MTD_PARTITION
> where one for backward compatiblity (supporting raw) while another for
> UBI.
> 
> MTDPARTS_RAW
> 256k(spl),
> 256k(env),
> 15872k(boot),
> -(rootfs)
> 
> MTDPARTS_UBI
> 256k(spl),
> 256k(env),
> -(UBI)
> 
> We should make UBI as default then. If user care about backward
> compatiblity, they shall use the MT

Re: [U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Marek Vasut]

On Monday, December 14, 2015 at 01:11:27 AM, Chin Liang See wrote:
> On Sun, 2015-12-13 at 16:42 +0100, Marek Vasut wrote:
> > On Sunday, December 13, 2015 at 02:03:02 PM, Chin Liang See wrote:
> > > On Sun, 2015-12-13 at 04:14 +0100, Marek Vasut wrote:
> > > > On Sunday, December 13, 2015 at 01:49:06 AM, Chin Liang See
> > > > 
> > > > wrote:
> > > > > On Sun, 2015-12-13 at 01:01 +0100, Marek Vasut wrote:
> > > > > > On Sunday, December 13, 2015 at 12:59:48 AM, Chin Liang See
> > > > > > 
> > > > > > wrote:
> > > > > > > On Sat, 2015-12-12 at 16:36 +0100, Marek Vasut wrote:
> > > > > > > > On Saturday, December 12, 2015 at 07:30:46 AM, Chin Liang
> > > > > > > > See
> > > > > > > 
> > > > > > > > wrote:
> > > > > > > [...]
> > > > > > > 
> > > > > > > > > > Can you share the final layout before you roll out
> > > > > > > > > > patches ?
> > > > > > > > > 
> > > > > > > > > Sure, plan to do so but need to away from desk just
> > > > > > > > > now.
> > > > > > > > > 
> > > > > > > > > Here is the old layout
> > > > > > > > > 256k(spl)
> > > > > > > > > 64k(env)
> > > > > > > > > 64k(dtb)
> > > > > > > > > 256k(boot)
> > > > > > > > > 16m(kernel)
> > > > > > > > > 16m(rootfs)
> > > > > > > > > 
> > > > > > > > > The new one would like this
> > > > > > > > > 256k(spl)
> > > > > > > > 
> > > > > > > > I'd say you should just call this u-boot, see above for
> > > > > > > > the
> > > > > > > > rationale.
> > > > > > > > 
> > > > > > > > > 256k(env)
> > > > > > > > > 15872k(boot)
> > > > > > > > > 16m(rootfs)
> > > > > > > > > 
> > > > > > > > > The boot partition can be used as ubi part or raw
> > > > > > > > > partition.
> > > > > > > > > It contains the linux dtb, u-boot and linux images.
> > > > > > > > 
> > > > > > > > Is that an UBIFS partition ? If so, why don't you just
> > > > > > > > use
> > > > > > > > two
> > > > > > > > UBI
> > > > > > > > volumes ?
> > > > > > > 
> > > > > > > For backward compatibility, it can be raw if user want to
> > > > > > > stick
> > > > > > > with
> > > > > > > old way.
> > > > > > 
> > > > > > If you're breaking the partitioning layout anyway, you don't
> > > > > > have
> > > > > > to
> > > > > > care about the "old way", right ?
> > > > > 
> > > > > Actually this partition can be used as raw partition if user
> > > > > don't
> > > > > want
> > > > > to store zimage and dtb as raw binary.
> > > > 
> > > > You should never store raw zImage/dtb in a flash on a production
> > > > system.
> > > > This is real bad and can result in a corruption in the future
> > > > when
> > > > the
> > > > system is in the field for a long time. I'd suggest to just use
> > > > two
> > > > UBI
> > > > volumes, one for fitImage and the other for rootfs.
> > > 
> > > Yup, we are trying to move the raw away by having UBI enabled. I
> > > presume when you refer 2 UBI volumes, I presume its still single
> > > UBI
> > > partition?
> > 
> > Yeah, one UBI partition with two UBI volumes -- boot and root.
> 
> Ok I grasp you correctly. In this case, I would suggest to opt for 2
> partitions instead of 2 volumes. User can just use sf erase rootfs
> instead of checking for volume offset. I suspect the ubi part will take
> longer time if we are having one partition only. I shall send out the
> new revision if this works for you :)

Oh, I see what you're concerned about. On the other hand, you are not supposed 
to erase UBI partition, since that'd nuke the UBI erase counters and UBI would
loose track of how many times each block was erased, which helps with wear 
leveling.

If you're adamant about two UBI partitions , you can try the trick where you can
create overlapping mtd partitions, that way you'd have both options available.
(it is actually a legal construction, you can check the kernel MTD docs).
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Chin Liang See]

On Sun, 2015-12-13 at 16:42 +0100, Marek Vasut wrote:
> On Sunday, December 13, 2015 at 02:03:02 PM, Chin Liang See wrote:
> > On Sun, 2015-12-13 at 04:14 +0100, Marek Vasut wrote:
> > > On Sunday, December 13, 2015 at 01:49:06 AM, Chin Liang See
> > > wrote:
> > > > On Sun, 2015-12-13 at 01:01 +0100, Marek Vasut wrote:
> > > > > On Sunday, December 13, 2015 at 12:59:48 AM, Chin Liang See
> > > > > 
> > > > > wrote:
> > > > > > On Sat, 2015-12-12 at 16:36 +0100, Marek Vasut wrote:
> > > > > > > On Saturday, December 12, 2015 at 07:30:46 AM, Chin Liang
> > > > > > > See
> > > > > > 
> > > > > > > wrote:
> > > > > > [...]
> > > > > > 
> > > > > > > > > Can you share the final layout before you roll out
> > > > > > > > > patches ?
> > > > > > > > 
> > > > > > > > Sure, plan to do so but need to away from desk just
> > > > > > > > now.
> > > > > > > > 
> > > > > > > > Here is the old layout
> > > > > > > > 256k(spl)
> > > > > > > > 64k(env)
> > > > > > > > 64k(dtb)
> > > > > > > > 256k(boot)
> > > > > > > > 16m(kernel)
> > > > > > > > 16m(rootfs)
> > > > > > > > 
> > > > > > > > The new one would like this
> > > > > > > > 256k(spl)
> > > > > > > 
> > > > > > > I'd say you should just call this u-boot, see above for
> > > > > > > the
> > > > > > > rationale.
> > > > > > > 
> > > > > > > > 256k(env)
> > > > > > > > 15872k(boot)
> > > > > > > > 16m(rootfs)
> > > > > > > > 
> > > > > > > > The boot partition can be used as ubi part or raw
> > > > > > > > partition.
> > > > > > > > It contains the linux dtb, u-boot and linux images.
> > > > > > > 
> > > > > > > Is that an UBIFS partition ? If so, why don't you just
> > > > > > > use
> > > > > > > two
> > > > > > > UBI
> > > > > > > volumes ?
> > > > > > 
> > > > > > For backward compatibility, it can be raw if user want to
> > > > > > stick
> > > > > > with
> > > > > > old way.
> > > > > 
> > > > > If you're breaking the partitioning layout anyway, you don't
> > > > > have
> > > > > to
> > > > > care about the "old way", right ?
> > > > 
> > > > Actually this partition can be used as raw partition if user
> > > > don't
> > > > want
> > > > to store zimage and dtb as raw binary.
> > > 
> > > You should never store raw zImage/dtb in a flash on a production
> > > system.
> > > This is real bad and can result in a corruption in the future
> > > when
> > > the
> > > system is in the field for a long time. I'd suggest to just use
> > > two
> > > UBI
> > > volumes, one for fitImage and the other for rootfs.
> > 
> > Yup, we are trying to move the raw away by having UBI enabled. I
> > presume when you refer 2 UBI volumes, I presume its still single
> > UBI
> > partition?
> 
> Yeah, one UBI partition with two UBI volumes -- boot and root.

Ok I grasp you correctly. In this case, I would suggest to opt for 2
partitions instead of 2 volumes. User can just use sf erase rootfs
instead of checking for volume offset. I suspect the ubi part will take
longer time if we are having one partition only. I shall send out the
new revision if this works for you :)

Thanks
Chin Liang

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

Re: [U-Boot] [PATCH v2 1/3] Revert "rockchip: Add max spl size & spl header configs"

[Simon Glass]

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] arm: mxs: add support for I2SE's Duckbill boards

[Marek Vasut]

On Sunday, December 13, 2015 at 10:53:30 PM, Michael Heimpold wrote:
> Hi Marek,

Hi!

> thanks for your review. My comments inline below.

np :)

> Am Sunday 13 December 2015, 16:40:14 schrieb Marek Vasut:
> > On Sunday, December 13, 2015 at 12:09:58 PM, Michael Heimpold wrote:
> > 
> > Commit message describing the board would be real nice.
> 
> Ok, I'll add it in v3.
> 
> [...]
> 
> > >  #define MACH_TYPE_COLIBRI_T30  4493
> > >  #define MACH_TYPE_APALIS_T30   4513
> > >  #define MACH_TYPE_OMAPL138_LCDK2495
> > > 
> > > +#define MACH_TYPE_DUCKBILL 4754
> > 
> > This board is still using mach id to boot kernel ? Wow ...
> 
> Not really. But I looked at other iMX28 boards and all still define such
> a MACH_TYPE. For historic reasons, only?

Yes, they are (probably) capable of booting some obscure pre-DT kernel versions.

> However, I think it does not hurt,
> so some customers who think they still need to go with old Freescale kernel
> could use this...

OK

> [...]
> 
> > > +
> > > +#ifdef   CONFIG_CMD_MMC
> > 
> > #ifdef[SPACE] please, not [TAB]
> 
> I heavily used m28evk and mx28evk as reference, so I thought
> that tab is the preferred style, but I can change, have no strong opinion
> on this...

Space please ;-)

> > [...]
> > 
> > > +void mx28_adjust_mac(int dev_id, unsigned char *mac)
> > > +{
> > > + mac[0] = 0x00;
> > > + mac[1] = 0x01;
> > > + mac[2] = 0x87;

HERE

> > > +}
> > > +#endif
> > > +
> > > +#ifdef CONFIG_OF_BOARD_SETUP
> > > +int ft_board_setup(void *blob, bd_t *bd)
> > > +{
> > > + uint8_t enetaddr[6];
> > > + u32 mac = 0;
> > > +
> > > + enetaddr[0] = 0x00;
> > > + enetaddr[1] = 0x01;
> > > + enetaddr[2] = 0x87;

HERE

> > Looks like there are two copies of the same OUI ?
> 
> I'm not sure, whether I understand the question correctly?

See the "HERE" markers above, you have two copies of the same thing in
the code for whatever reason.

> All Duckbill devices only have one Ethernet interface. For this
> interface the MAC is programmed into the first OTP fuse register
> as this seems to be best practise on this platform. Since this register
> is only 24 bit, the first two byte must be adjusted by board code.
> The "Duckbill SPI" is an evaluation platform for QCA7000 powerline
> chip. On this devices, the second OTP register is programmed with
> a second MAC adress, but this address must be passed via DT to kernel.
> Both addresses usually have the same OUI, thats correct.

See above, it's just a nitpick.

> > > +#ifdef CONFIG_MXS_OCOTP
> > > + /* only Duckbill SPI has a MAC for the QCA7k */
> > > + fuse_read(0, 1, &mac);
> > > +#endif
> > > +
> > > + if (mac != 0) {
> > > + enetaddr[3] = (mac >> 16) & 0xff;
> > > + enetaddr[4] = (mac >>  8) & 0xff;
> > > + enetaddr[5] =  mac& 0xff;
> > > +
> > > + fdt_find_and_setprop(blob,
> > > +
> > > "/apb@8000/apbh@8000/ssp@80014000/ethernet@0", +
> > > 
> > > "local-mac-address", enetaddr, 6, 1);
> > 
> > You can use aliases {} to locate the ethernet node here.
> 
> "can" == "should" ? :-)

Yes, it's a good idea. It's also how U-Boot patches $ethaddr into the
DT, it uses the aliases to do that.

> I'll have a look, but AFAIR in linux' imx28.dtsi, ethernet1 alias is
> already used for mac1. I'm not sure, if I can redefine it in board DT
> to point to SPI node...

You can always define ethernet2 .

> [...]
> 
> > > +
> > > + /* MX28_PAD_LCD_D17__GPIO_1_17: v1 = pull-down, v2 = pull-up */
> > > + system_rev =
> > > + gpio_get_value(MX28_PAD_LCD_D17__GPIO_1_17);
> > 
> > Does gpio_get_value() always return 0/1 value ? I don't think so.
> 
> Hm, on mxs this seems to be the case, and include/asm-generic/gpio.h
> tells this, too - but also tells, that this interface described there is
> deprecated? It seems that I do not see the forest for the trees looking
> for the API docu... Anyway, I would simply add !! to do the trick...

I think that's a good idea, I wouldn't depend on it returning 0/1 .

> [...]
> 
> > > +/* FEC Ethernet on SoC */
> > > +#ifdef   CONFIG_CMD_NET
> > > +#define CONFIG_FEC_MXC
> > > +#define CONFIG_NET_MULTI
> > > +#define CONFIG_MX28_FEC_MAC_IN_OCOTP
> > > +#define CONFIG_FEC_MXC_PHYADDR   1
> > > +#define IMX_FEC_BASE MXS_ENET0_BASE
> > 
> > This IMX_FEC_BASE is definitelly unused on MXS.
> 
> I use fecmxc_initialize in the board setup, not fecmxc_initialize_multi,
> and thus this define is required. However, I could switch to
> fecmxc_initialize_multi and the I could drop CONFIG_FEC_MXC_PHYADDR
> and IMX_FEC_BASE...

Oh I see. Whichever you prefer then.

> > > +#endif
> > > +
> > > +#define CONFIG_IPADDR192.168.1.10
> > > +#define CONFIG_SERVERIP  192.168.1.1
> > > +#define CONFIG_NETMASK   255.255.255.0
> > > +#define CONFIG_GATEWAYIP 192.168.1.254
> > 
> > Definitelly remove these, you should never ever hard-code these settings
> > into U-Boot.
> 
> I don't understand. This are only default 

Re: [U-Boot] [PATCH] arm: mvebu: Add SolidRun ClearFog Armada 38x initial support

[Luka Perkov]

Hi Dennis,

On Sun, Dec 13, 2015 at 11:33:46AM -0600, Dennis Gilmore wrote:
> Trying to test this  I have hit an error with CONFIG_PHY_ADDR not defined.
> 
> I am guessing that I am missing some other sets of patches. digging through 
> patchwork I am not able to figure it out.  there is a bunch of patches in 
> patchwork that say they are in NEW state however they are in the tree so not 
> labeled correctly.  Any clues as to which patch sets this depends on are 
> appreciated.

I've asked Stefan to put the patches up on some git repo for easier
review and pull on my side. I'm also very eager to test this patchset!

Regards,
Luka

> Dennis
> 
> 
> On Friday, November 27, 2015 04:15:17 PM Stefan Roese wrote:
> > This patch adds basic support for the SolidRun ClearFog Armada 38x based
> > board to mainline U-Boot. Supported interfaces / devices are:
> > - DDR3
> > - UART
> > - MMC
> > - Ethernet port 0 (connected to dedicated PHY)
> > - I2C
> > 
> > The included DT source was taken from Russell King's ftp server:
> > http://www.home.arm.linux.org.uk/~rmk/clearfog/
> > 
> > With only minor modifications, like the addition of some aliases and the
> > "u-boot,dm-pre-reloc" property.
> > 
> > Signed-off-by: Stefan Roese 
> > Cc: Rabeeh Khoury 
> > Cc: Luka Perkov 
> > ---
> >  arch/arm/Kconfig |   1 +
> >  arch/arm/dts/Makefile|   1 +
> >  arch/arm/dts/armada-388-clearfog.dts | 509
> > +++ arch/arm/mach-mvebu/Kconfig  | 
> >  3 +
> >  board/solidrun/clearfog/Kconfig  |  12 +
> >  board/solidrun/clearfog/MAINTAINERS  |   6 +
> >  board/solidrun/clearfog/Makefile |   7 +
> >  board/solidrun/clearfog/README   |  18 ++
> >  board/solidrun/clearfog/clearfog.c   | 156 +++
> >  board/solidrun/clearfog/kwbimage.cfg |  12 +
> >  configs/clearfog_defconfig   |  20 ++
> >  include/configs/clearfog.h   | 183 +
> >  12 files changed, 928 insertions(+)
> >  create mode 100644 arch/arm/dts/armada-388-clearfog.dts
> >  create mode 100644 board/solidrun/clearfog/Kconfig
> >  create mode 100644 board/solidrun/clearfog/MAINTAINERS
> >  create mode 100644 board/solidrun/clearfog/Makefile
> >  create mode 100644 board/solidrun/clearfog/README
> >  create mode 100644 board/solidrun/clearfog/clearfog.c
> >  create mode 100644 board/solidrun/clearfog/kwbimage.cfg
> >  create mode 100644 configs/clearfog_defconfig
> >  create mode 100644 include/configs/clearfog.h
> > 
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 4ddc2de..0c4794b 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -801,6 +801,7 @@ source "board/siemens/draco/Kconfig"
> >  source "board/siemens/pxm2/Kconfig"
> >  source "board/siemens/rut/Kconfig"
> >  source "board/silica/pengwyn/Kconfig"
> > +source "board/solidrun/clearfog/Kconfig"
> >  source "board/spear/spear300/Kconfig"
> >  source "board/spear/spear310/Kconfig"
> >  source "board/spear/spear320/Kconfig"
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index 9719103..0494997 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -47,6 +47,7 @@ dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
> > tegra210-p2571.dtb
> > 
> >  dtb-$(CONFIG_ARCH_MVEBU) +=\
> > +   armada-388-clearfog.dtb \
> > armada-388-gp.dtb   \
> > armada-xp-gp.dtb\
> > armada-xp-maxbcm.dtb
> > diff --git a/arch/arm/dts/armada-388-clearfog.dts
> > b/arch/arm/dts/armada-388-clearfog.dts new file mode 100644
> > index 000..b2dfd56
> > --- /dev/null
> > +++ b/arch/arm/dts/armada-388-clearfog.dts
> > @@ -0,0 +1,509 @@
> > +/*
> > + * Device Tree file for SolidRun Clearfog revision A1 rev 2.0 (88F6828)
> > + *
> > + *  Copyright (C) 2015 Russell King
> > + *
> > + * This board is in development; the contents of this file work with
> > + * the A1 rev 2.0 of the board, which does not represent final
> > + * production board.  Things will change, don't expect this file to
> > + * remain compatible info the future.
> > + *
> > + * 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
> > + * version 2 as published by the Free Software Foundation.
> > + *
> > + * 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
> 

Re: [U-Boot] [PATCH v2] arm: mxs: add support for I2SE's Duckbill boards

[Michael Heimpold]

Hi Marek,

thanks for your review. My comments inline below.

Am Sunday 13 December 2015, 16:40:14 schrieb Marek Vasut:
> On Sunday, December 13, 2015 at 12:09:58 PM, Michael Heimpold wrote:
> 
> Commit message describing the board would be real nice.
> 

Ok, I'll add it in v3.

[...]
> > 
> >  #define MACH_TYPE_COLIBRI_T30  4493
> >  #define MACH_TYPE_APALIS_T30   4513
> >  #define MACH_TYPE_OMAPL138_LCDK2495
> > 
> > +#define MACH_TYPE_DUCKBILL 4754
> 
> This board is still using mach id to boot kernel ? Wow ...

Not really. But I looked at other iMX28 boards and all still define such
a MACH_TYPE. For historic reasons, only? However, I think it does not hurt,
so some customers who think they still need to go with old Freescale kernel
could use this...

[...]

> > +
> > +#ifdef CONFIG_CMD_MMC
> 
> #ifdef[SPACE] please, not [TAB]
> 

I heavily used m28evk and mx28evk as reference, so I thought
that tab is the preferred style, but I can change, have no strong opinion
on this...

> [...]
> 
> > +void mx28_adjust_mac(int dev_id, unsigned char *mac)
> > +{
> > +   mac[0] = 0x00;
> > +   mac[1] = 0x01;
> > +   mac[2] = 0x87;
> > +}
> > +#endif
> > +
> > +#ifdef CONFIG_OF_BOARD_SETUP
> > +int ft_board_setup(void *blob, bd_t *bd)
> > +{
> > +   uint8_t enetaddr[6];
> > +   u32 mac = 0;
> > +
> > +   enetaddr[0] = 0x00;
> > +   enetaddr[1] = 0x01;
> > +   enetaddr[2] = 0x87;
> 
> Looks like there are two copies of the same OUI ?

I'm not sure, whether I understand the question correctly?
All Duckbill devices only have one Ethernet interface. For this
interface the MAC is programmed into the first OTP fuse register
as this seems to be best practise on this platform. Since this register
is only 24 bit, the first two byte must be adjusted by board code.
The "Duckbill SPI" is an evaluation platform for QCA7000 powerline
chip. On this devices, the second OTP register is programmed with
a second MAC adress, but this address must be passed via DT to kernel.
Both addresses usually have the same OUI, thats correct.

> 
> > +#ifdef CONFIG_MXS_OCOTP
> > +   /* only Duckbill SPI has a MAC for the QCA7k */
> > +   fuse_read(0, 1, &mac);
> > +#endif
> > +
> > +   if (mac != 0) {
> > +   enetaddr[3] = (mac >> 16) & 0xff;
> > +   enetaddr[4] = (mac >>  8) & 0xff;
> > +   enetaddr[5] =  mac& 0xff;
> > +
> > +   fdt_find_and_setprop(blob,
> > +
> > "/apb@8000/apbh@8000/ssp@80014000/ethernet@0", +
> > 
> > "local-mac-address", enetaddr, 6, 1);
> 
> You can use aliases {} to locate the ethernet node here.

"can" == "should" ? :-)
I'll have a look, but AFAIR in linux' imx28.dtsi, ethernet1 alias is
already used for mac1. I'm not sure, if I can redefine it in board DT
to point to SPI node...

[...]
> > +
> > +   /* MX28_PAD_LCD_D17__GPIO_1_17: v1 = pull-down, v2 = pull-up */
> > +   system_rev =
> > +   gpio_get_value(MX28_PAD_LCD_D17__GPIO_1_17);
> 
> Does gpio_get_value() always return 0/1 value ? I don't think so.
> 

Hm, on mxs this seems to be the case, and include/asm-generic/gpio.h
tells this, too - but also tells, that this interface described there is
deprecated? It seems that I do not see the forest for the trees looking
for the API docu... Anyway, I would simply add !! to do the trick...

[...]

> > +/* FEC Ethernet on SoC */
> > +#ifdef CONFIG_CMD_NET
> > +#define CONFIG_FEC_MXC
> > +#define CONFIG_NET_MULTI
> > +#define CONFIG_MX28_FEC_MAC_IN_OCOTP
> > +#define CONFIG_FEC_MXC_PHYADDR 1
> > +#define IMX_FEC_BASE   MXS_ENET0_BASE
> 
> This IMX_FEC_BASE is definitelly unused on MXS.
> 
I use fecmxc_initialize in the board setup, not fecmxc_initialize_multi,
and thus this define is required. However, I could switch to
fecmxc_initialize_multi and the I could drop CONFIG_FEC_MXC_PHYADDR
and IMX_FEC_BASE...

> > +#endif
> > +
> > +#define CONFIG_IPADDR  192.168.1.10
> > +#define CONFIG_SERVERIP192.168.1.1
> > +#define CONFIG_NETMASK 255.255.255.0
> > +#define CONFIG_GATEWAYIP   192.168.1.254
> 
> Definitelly remove these, you should never ever hard-code these settings
> into U-Boot.

I don't understand. This are only default settings in case, U-Boot starts with
an empty environment. Other boards do the same, so what's wrong here?
> 
> > +/* BOOTP options */
> > +#define CONFIG_BOOTP_SUBNETMASK
> > +#define CONFIG_BOOTP_GATEWAY
> > +#define CONFIG_BOOTP_HOSTNAME
> 
> DTTO

These defines affect what is requested in the DHCP/BOOTP packet. I do not
think, it can drop it.

> 
> > +/* SPI */
> > +#ifdef CONFIG_CMD_SPI
> > +#define CONFIG_DEFAULT_SPI_BUS 2
> 
> Add default CS please

I think I'll prefer to drop the SPI block completely, no real usage.

> 
> > +#define CONFIG_DEFAULT_SPI_MODESPI_MODE_0
> > +#endif
> > +
> > +/* Boot Linux */
> > +#define CONFIG_BOOTDELAY   1
> > +#define CONFIG_BOOTFILE"zImage"
> 
> Why don't you switch to fitImage 

Re: [U-Boot] [PATCH 0/8] m68k, mips, powerpc, kbuild: move CONFIG_SYS_TEXT_BASE

[Angelo Dureghello]

On 11/12/2015 04:22, Masahiro Yamada wrote:

Currently, CONFIG_SYS_TEXT_BASE is defined in various ways:

[1] by board/${VENDOR}/${BOARD}/config.mk

[2] by CONFIG_SYS_EXTRA_OPTIONS
 (This was "options" field of boards.cfg before Kconfig conversion)

[3] by include/configs/${BOARD}.h

[4] by configs/${BOARD}_defconfig

Kbuild is still keeping some tricky code for [1].
We have some boards using [1] for M68K, MIPS, PowerPC.

Convert them and drop the workaround code from Kbuild.

I built all the boards and compared the checksum of the binary images
for all of them.
I confirmed no impact on these moves.  This series should be OK.



Masahiro Yamada (8):
   m68k: move CONFIG_SYS_TEXT_BASE to defconfig files
   m68k: M54418TWR: drop board/freescale/m54418twr/config.mk
   microblaze: move CONFIG_SYS_TEXT_BASE to defconfig
   mips: vct: move CONFIG_SYS_TEXT_BASE away from config.mk
   mips: dbau1x00: move CONFIG_SYS_TEXT_BASE away from config.mk
   mips: pb1x00: move CONFIG_SYS_TEXT_BASE away from config.mk
   powerpc: yucca: drop redundant CONFIG_SYS_TEXT_BASE from config.mk
   kbuild: drop workaround for old style CONFIG_SYS_TEXT_BASE defines

  Kconfig   |  3 ++-
  Makefile  |  6 --
  arch/m68k/cpu/mcf5445x/start.S|  8 
  board/amcc/yucca/config.mk|  6 --
  board/cobra5272/config.mk |  9 -
  board/dbau1x00/config.mk  | 16 
  board/freescale/m5208evbe/config.mk   |  9 -
  board/freescale/m5249evb/config.mk|  9 -
  board/freescale/m5253demo/config.mk   |  9 -
  board/freescale/m5253evbe/config.mk   |  9 -
  board/freescale/m5272c3/config.mk |  9 -
  board/freescale/m5275evb/config.mk|  9 -
  board/freescale/m5282evb/config.mk|  9 -
  board/freescale/m53017evb/config.mk   |  9 -
  board/freescale/m5329evb/config.mk|  9 -
  board/freescale/m5373evb/config.mk|  9 -
  board/freescale/m54418twr/config.mk   |  7 ---
  board/freescale/m547xevb/config.mk|  9 -
  board/freescale/m548xevb/config.mk|  9 -
  board/micronas/vct/config.mk  | 13 -
  board/pb1x00/config.mk| 16 
  board/sysam/amcore/config.mk  |  7 ---
  board/xilinx/microblaze-generic/config.mk |  2 --
  configs/M5208EVBE_defconfig   |  1 +
  configs/M52277EVB_defconfig   |  3 ++-
  configs/M52277EVB_stmicro_defconfig   |  3 ++-
  configs/M5235EVB_Flash32_defconfig|  3 ++-
  configs/M5235EVB_defconfig|  2 +-
  configs/M5249EVB_defconfig|  1 +
  configs/M5253DEMO_defconfig   |  1 +
  configs/M5253EVBE_defconfig   |  1 +
  configs/M5272C3_defconfig |  1 +
  configs/M5275EVB_defconfig|  1 +
  configs/M5282EVB_defconfig|  1 +
  configs/M53017EVB_defconfig   |  1 +
  configs/M5329AFEE_defconfig   |  1 +
  configs/M5329BFEE_defconfig   |  1 +
  configs/M5373EVB_defconfig|  1 +
  configs/M54418TWR_defconfig   |  3 ++-
  configs/M54418TWR_nand_mii_defconfig  |  3 ++-
  configs/M54418TWR_nand_rmii_defconfig |  3 ++-
  configs/M54418TWR_nand_rmii_lowfreq_defconfig |  3 ++-
  configs/M54418TWR_serial_mii_defconfig|  3 ++-
  configs/M54418TWR_serial_rmii_defconfig   |  3 ++-
  configs/M54451EVB_defconfig   |  3 ++-
  configs/M54451EVB_stmicro_defconfig   |  3 ++-
  configs/M54455EVB_a66_defconfig   |  3 ++-
  configs/M54455EVB_defconfig   |  3 ++-
  configs/M54455EVB_i66_defconfig   |  3 ++-
  configs/M54455EVB_intel_defconfig |  3 ++-
  configs/M54455EVB_stm33_defconfig |  3 ++-
  configs/M5475AFE_defconfig|  1 +
  configs/M5475BFE_defconfig|  1 +
  configs/M5475CFE_defconfig|  1 +
  configs/M5475DFE_defconfig|  1 +
  configs/M5475EFE_defconfig|  1 +
  configs/M5475FFE_defconfig|  1 +
  configs/M5475GFE_defconfig|  1 +
  configs/M5485AFE_defconfig|  1 +
  configs/M5485BFE_defconfig|  1 +
  configs/M5485CFE_defconfig|  1 +
  configs/M5485DFE_defconfig|  1 +
  configs/M5485EFE_defconfig|  1 +
  configs/M5485FFE_defconfig|  1 +
  configs/M5485GFE_defconfig|  1 +
  configs/M5485HFE_defconfig|  1

Re: [U-Boot] [PATCH v3] dm: Add timeline and guide for porting serial drivers

[Marek Vasut]

On Friday, November 20, 2015 at 06:48:47 PM, Simon Glass wrote:
> Add a README with a brief guide to porting serial drivers over to use
> driver model.
> 
> Add a timeline also. All serial drivers should be converted by the end
> of January 2016.
> 
> Signed-off-by: Simon Glass 
> ---
> To avoid anyone missing out on this, I have added to Cc the all U-Boot
> maintainers using this:
> 
> (for f in $(find . -name MAINTAINERS); do grep ^M: $f; done) | \
>   awk '{$1=""; print "Series-cc:" $0}' |sort | uniq
> 
> This is about 229 email address, of which 217 seem to be different people.
> 
> Changes in v3:
> - Fix the date to avoid time machine issues
> 
> Changes in v2:
> - Copy the patch to all maintainers
> - Move the timeline back to January
> 
>  doc/driver-model/serial-howto.txt | 58
> +++ 1 file changed, 58 insertions(+)
>  create mode 100644 doc/driver-model/serial-howto.txt
> 
> diff --git a/doc/driver-model/serial-howto.txt
> b/doc/driver-model/serial-howto.txt new file mode 100644
> index 000..60483a4
> --- /dev/null
> +++ b/doc/driver-model/serial-howto.txt
> @@ -0,0 +1,58 @@
> +How to port a serial driver to driver model
> +===
> +
> +About 16 of 33 serial drivers have been converted as at September 2015. It
> +is time for maintainers to start converting over the remaining serial
> drivers: +
> +   altera_jtag_uart.c
> +   altera_uart.c

These are probably already converted.

> +   arm_dcc.c
> +   lpc32xx_hsuart.c
> +   mcfuart.c
> +   mxs_auart.c

^ This system does not use DM at all.

> +   opencores_yanu.c
> +   serial_bfin.c
> +   serial_imx.c

DTTO

> +   serial_lpuart.c
> +   serial_max3100.c
> +   serial_pxa.c

DTTO

> +   serial_s3c24x0.c

DTTO

> +   serial_sa1100.c

This driver is probably dead code

> +   serial_stm32.c
> +   serial_xuartlite.c
> +   usbtty.c
> +
> +You should complete this by the end of January 2016.

So what do you suggest to do with boards which do not use DM at all ?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/8] m68k: move CONFIG_SYS_TEXT_BASE to defconfig files

[Angelo Dureghello]

On 11/12/2015 04:22, Masahiro Yamada wrote:

For historical reason, CONFIG_SYS_TEXT_BASE has been specified
in various ways:

[1] by board/${VENDOR}/${BOARD}/config.mk

[2] by CONFIG_SYS_EXTRA_OPTIONS
 (This was "options" field of boards.cfg before Kconfig conversion)

[3] by include/configs/${BOARD}.h

[4] by configs/${BOARD}_defconfig

Most of M68K boards use either [1] or [2], both of which we want to
deprecate.  Switch them into [4], which is the newest way (Kconfig).

We still allow [3] too, because it is still used by many boards and
we expect much time for conversion.

Signed-off-by: Masahiro Yamada 
---

  Kconfig   | 3 ++-
  board/cobra5272/config.mk | 9 -
  board/freescale/m5208evbe/config.mk   | 9 -
  board/freescale/m5249evb/config.mk| 9 -
  board/freescale/m5253demo/config.mk   | 9 -
  board/freescale/m5253evbe/config.mk   | 9 -
  board/freescale/m5272c3/config.mk | 9 -
  board/freescale/m5275evb/config.mk| 9 -
  board/freescale/m5282evb/config.mk| 9 -
  board/freescale/m53017evb/config.mk   | 9 -
  board/freescale/m5329evb/config.mk| 9 -
  board/freescale/m5373evb/config.mk| 9 -
  board/freescale/m547xevb/config.mk| 9 -
  board/freescale/m548xevb/config.mk| 9 -
  board/sysam/amcore/config.mk  | 7 ---
  configs/M5208EVBE_defconfig   | 1 +
  configs/M52277EVB_defconfig   | 3 ++-
  configs/M52277EVB_stmicro_defconfig   | 3 ++-
  configs/M5235EVB_Flash32_defconfig| 3 ++-
  configs/M5235EVB_defconfig| 2 +-
  configs/M5249EVB_defconfig| 1 +
  configs/M5253DEMO_defconfig   | 1 +
  configs/M5253EVBE_defconfig   | 1 +
  configs/M5272C3_defconfig | 1 +
  configs/M5275EVB_defconfig| 1 +
  configs/M5282EVB_defconfig| 1 +
  configs/M53017EVB_defconfig   | 1 +
  configs/M5329AFEE_defconfig   | 1 +
  configs/M5329BFEE_defconfig   | 1 +
  configs/M5373EVB_defconfig| 1 +
  configs/M54418TWR_defconfig   | 3 ++-
  configs/M54418TWR_nand_mii_defconfig  | 3 ++-
  configs/M54418TWR_nand_rmii_defconfig | 3 ++-
  configs/M54418TWR_nand_rmii_lowfreq_defconfig | 3 ++-
  configs/M54418TWR_serial_mii_defconfig| 3 ++-
  configs/M54418TWR_serial_rmii_defconfig   | 3 ++-
  configs/M54451EVB_defconfig   | 3 ++-
  configs/M54451EVB_stmicro_defconfig   | 3 ++-
  configs/M54455EVB_a66_defconfig   | 3 ++-
  configs/M54455EVB_defconfig   | 3 ++-
  configs/M54455EVB_i66_defconfig   | 3 ++-
  configs/M54455EVB_intel_defconfig | 3 ++-
  configs/M54455EVB_stm33_defconfig | 3 ++-
  configs/M5475AFE_defconfig| 1 +
  configs/M5475BFE_defconfig| 1 +
  configs/M5475CFE_defconfig| 1 +
  configs/M5475DFE_defconfig| 1 +
  configs/M5475EFE_defconfig| 1 +
  configs/M5475FFE_defconfig| 1 +
  configs/M5475GFE_defconfig| 1 +
  configs/M5485AFE_defconfig| 1 +
  configs/M5485BFE_defconfig| 1 +
  configs/M5485CFE_defconfig| 1 +
  configs/M5485DFE_defconfig| 1 +
  configs/M5485EFE_defconfig| 1 +
  configs/M5485FFE_defconfig| 1 +
  configs/M5485GFE_defconfig| 1 +
  configs/M5485HFE_defconfig| 1 +
  configs/amcore_defconfig  | 1 +
  configs/cobra5272_defconfig   | 1 +
  configs/eb_cpu5282_defconfig  | 3 ++-
  configs/eb_cpu5282_internal_defconfig | 3 ++-
  62 files changed, 67 insertions(+), 144 deletions(-)
  delete mode 100644 board/cobra5272/config.mk
  delete mode 100644 board/freescale/m5208evbe/config.mk
  delete mode 100644 board/freescale/m5249evb/config.mk
  delete mode 100644 board/freescale/m5253demo/config.mk
  delete mode 100644 board/freescale/m5253evbe/config.mk
  delete mode 100644 board/freescale/m5272c3/config.mk
  delete mode 100644 board/freescale/m5275evb/config.mk
  delete mode 100644 board/freescale/m5282evb/config.mk
  delete mode 100644 board/freescale/m53017evb/config.mk
  delete mode 100644 board/freescale/m5329evb/config.mk
  delete mode 100644 board/freescale/m5373evb/config.mk
  delete mode 100644 board/freescale/m547xevb/config.mk
  delete mode 100644 board/freescale/m548xevb/config.mk
  delete mode 100644 board/sysam/amcore/config.mk

diff --git a/Kconfig b/Kconfig
index 821b464..9b

Re: [U-Boot] [PATCH 2/8] m68k: M54418TWR: drop board/freescale/m54418twr/config.mk

[Angelo Dureghello]

On 11/12/2015 04:22, Masahiro Yamada wrote:

The board/freescale/m54418twr/config.mk defined TEXT_BASE, which has
the same value as CONFIG_SYS_TEXT_BASE.  The TEXT_BASE is referenced
by two files:
  - arch/m68k/cpu/mcf5445x/start.S and include/
  - include/configs/M54418TWR.h

Replace the references with CONFIG_SYS_TEXT_BASE and delete
board/freescale/m54418twr/config.mk.

Signed-off-by: Masahiro Yamada 
---

  arch/m68k/cpu/mcf5445x/start.S  | 8 
  board/freescale/m54418twr/config.mk | 7 ---
  include/configs/M54418TWR.h | 2 +-
  3 files changed, 5 insertions(+), 12 deletions(-)
  delete mode 100644 board/freescale/m54418twr/config.mk

diff --git a/arch/m68k/cpu/mcf5445x/start.S b/arch/m68k/cpu/mcf5445x/start.S
index 979eb5a..ae261b1 100644
--- a/arch/m68k/cpu/mcf5445x/start.S
+++ b/arch/m68k/cpu/mcf5445x/start.S
@@ -34,7 +34,7 @@

  #if defined(CONFIG_SERIAL_BOOT)
  #define ASM_DRAMINIT  (asm_dram_init - CONFIG_SYS_TEXT_BASE + 
CONFIG_SYS_INIT_RAM_ADDR)
-#define ASM_DRAMINIT_N (asm_dram_init - TEXT_BASE)
+#define ASM_DRAMINIT_N (asm_dram_init - CONFIG_SYS_TEXT_BASE)
  #define ASM_SBF_IMG_HDR   (asm_sbf_img_hdr - CONFIG_SYS_TEXT_BASE + 
CONFIG_SYS_INIT_RAM_ADDR)
  #endif

@@ -490,7 +490,7 @@ asm_dspi_rd_status:
/* copy 4 boot pages to dram as soon as possible */
/* each page is 996 bytes (1056 total with 60 ECC bytes */
move.l  #0x, %a1/* src */
-   move.l  #TEXT_BASE, %a2 /* dst */
+   move.l  #CONFIG_SYS_TEXT_BASE, %a2  /* dst */
move.l  #0x3E0, %d0 /* sz in long */

  asm_boot_nand_copy:
@@ -571,7 +571,7 @@ asm_nand_init:
move.l  #4, %d2 /* start at 4 */
move.l  #0xFC0FFF04, %a0/* cmd2 */
move.l  #0xFC0FFF0C, %a1/* rar */
-   move.l  #(TEXT_BASE + 0xF80), %a2   /* dst */
+   move.l  #(CONFIG_SYS_TEXT_BASE + 0xF80), %a2/* dst */

  asm_nand_read:
move.l  #0x1100, %d0/* rar */
@@ -609,7 +609,7 @@ asm_nand_copy:
bgt asm_nand_read

/* jump to memory and execute */
-   move.l  #(TEXT_BASE + 0x400), %a0
+   move.l  #(CONFIG_SYS_TEXT_BASE + 0x400), %a0
jmp (%a0)

  #endif/* CONFIG_SYS_NAND_BOOT */
diff --git a/board/freescale/m54418twr/config.mk 
b/board/freescale/m54418twr/config.mk
deleted file mode 100644
index 07f52e0..000
--- a/board/freescale/m54418twr/config.mk
+++ /dev/null
@@ -1,7 +0,0 @@
-# Copyright 2010-2012 Freescale Semiconductor, Inc.
-# TsiChung Liew (tsi-chung.l...@freescale.com)
-#
-# SPDX-License-Identifier: GPL-2.0+
-#
-
-PLATFORM_CPPFLAGS += -DTEXT_BASE=$(CONFIG_SYS_TEXT_BASE)
diff --git a/include/configs/M54418TWR.h b/include/configs/M54418TWR.h
index 05ba13b..826de5b 100644
--- a/include/configs/M54418TWR.h
+++ b/include/configs/M54418TWR.h
@@ -267,7 +267,7 @@
  #endif

  #if defined(CONFIG_SERIAL_BOOT)
-#define CONFIG_SYS_MONITOR_BASE(TEXT_BASE + 0x400)
+#define CONFIG_SYS_MONITOR_BASE(CONFIG_SYS_TEXT_BASE + 0x400)
  #else
  #define CONFIG_SYS_MONITOR_BASE   (CONFIG_SYS_FLASH_BASE + 0x400)
  #endif



Acked-by: Angelo Dureghello 


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

Re: [U-Boot] [PATCH 1/7] usb: increase USB descriptor buffer size

[Marek Vasut]

On Sunday, December 13, 2015 at 07:35:19 PM, Stefan Bruens wrote:
> On Sunday 13 December 2015 05:49:24 Marek Vasut wrote:
> > On Sunday, December 13, 2015 at 05:47:18 AM, Stefan Brüns wrote:
> > > The configuration descriptor includes all interface, endpoint and
> > > auxiliary descriptors (e.g. report, union) so 512 may not be enough.
> > > 
> > > Signed-off-by: Stefan Brüns 
> > 
> > Can the size be determined in a dynamic manner instead of this ad-hoc
> > random number ?
> 
> Currently the buffer is allocated on the stack with
> ALLOC_CACHE_ALIGN_BUFFER in usb_select_config(... The buffer is passed to
> usb_get_configuration_no(...), but the buffer size is implicit.
> 
> usb_get_configuration_no(...) already determines and checks the descriptor
> size, but as it can not readjust the buffer it just bails out if it is
> to small.
> 
> The absolute maximum size for the descriptor is 64kB.
> 
> So yes, this is possible, but needs a little bit more work.

Do you feel like working on it ?

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 1/7] usb: increase USB descriptor buffer size

[Stefan Bruens]

On Sunday 13 December 2015 05:49:24 Marek Vasut wrote:
> On Sunday, December 13, 2015 at 05:47:18 AM, Stefan Brüns wrote:
> > The configuration descriptor includes all interface, endpoint and
> > auxiliary descriptors (e.g. report, union) so 512 may not be enough.
> > 
> > Signed-off-by: Stefan Brüns 
> 
> Can the size be determined in a dynamic manner instead of this ad-hoc
> random number ?

Currently the buffer is allocated on the stack with ALLOC_CACHE_ALIGN_BUFFER
in usb_select_config(... The buffer is passed to 
usb_get_configuration_no(...), but the buffer size is implicit.

usb_get_configuration_no(...) already determines and checks the descriptor 
size, but as it can not readjust the buffer it just bails out if it is
to small.

The absolute maximum size for the descriptor is 64kB.

So yes, this is possible, but needs a little bit more work.

Kind regards,

Stefan

-- 
Stefan Brüns  /  Bergstraße 21  /  52062 Aachen
home: +49 241 53809034 mobile: +49 151 50412019
work: +49 2405 49936-424
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] is it worth contributing a SATA SIL3512 driver to u-boot?

[Fabio Estevam]

On Sun, Dec 13, 2015 at 11:37 AM, Robert P. J. Day
 wrote:

>   i can check with the higher-ups about their willingness to
> contribute a new board definition and, if they have no objection,
> would that be sufficient to submit a patch to add a new board so that
> we don't have to carry all this patch material around?
>
>   am i thinking about this the right way?

I don't see any problems with this approach.

Just submit the patches to the list and maintainer when you can and it
will go through the standard review process.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/2] sf: Rename spi_flash_set_* functions

[Jagan Teki]

Since quad_mode functions are local to spi flash core,
rename them to a meaningful and readable names.

Signed-off-by: Jagan Teki 
---
 drivers/mtd/spi/spi_flash.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 781e275..f58a587 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -797,7 +797,7 @@ int stm_unlock(struct spi_flash *flash, u32 ofs, size_t len)
 
 
 #ifdef CONFIG_SPI_FLASH_MACRONIX
-static int spi_flash_set_qeb_mxic(struct spi_flash *flash)
+static int macronix_quad_enable(struct spi_flash *flash)
 {
u8 qeb_status;
int ret;
@@ -819,7 +819,7 @@ static int spi_flash_set_qeb_mxic(struct spi_flash *flash)
 #endif
 
 #if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_WINBOND)
-static int spi_flash_set_qeb_winspan(struct spi_flash *flash)
+static int spansion_quad_enable(struct spi_flash *flash)
 {
u8 qeb_status;
int ret;
@@ -840,17 +840,17 @@ static int spi_flash_set_qeb_winspan(struct spi_flash 
*flash)
 }
 #endif
 
-static int spi_flash_set_qeb(struct spi_flash *flash, u8 idcode0)
+static int set_quad_mode(struct spi_flash *flash, u8 idcode0)
 {
switch (idcode0) {
 #ifdef CONFIG_SPI_FLASH_MACRONIX
case SPI_FLASH_CFI_MFR_MACRONIX:
-   return spi_flash_set_qeb_mxic(flash);
+   return macronix_quad_enable(flash);
 #endif
 #if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_WINBOND)
case SPI_FLASH_CFI_MFR_SPANSION:
case SPI_FLASH_CFI_MFR_WINBOND:
-   return spi_flash_set_qeb_winspan(flash);
+   return spansion_quad_enable(flash);
 #endif
 #ifdef CONFIG_SPI_FLASH_STMICRO
case SPI_FLASH_CFI_MFR_STMICRO:
@@ -1045,7 +1045,7 @@ int spi_flash_scan(struct spi_flash *flash)
if ((flash->read_cmd == CMD_READ_QUAD_OUTPUT_FAST) ||
(flash->read_cmd == CMD_READ_QUAD_IO_FAST) ||
(flash->write_cmd == CMD_QUAD_PAGE_PROGRAM)) {
-   ret = spi_flash_set_qeb(flash, idcode[0]);
+   ret = set_quad_mode(flash, idcode[0]);
if (ret) {
debug("SF: Fail to set QEB for %02x\n", idcode[0]);
return -EINVAL;
-- 
1.9.1

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

[U-Boot] [PATCH 2/2] sf: Rename bank_end to bar_end in read_bar

[Jagan Teki]

bar_end gives more meaningfull compared to bank_end and
spi_flash_write_bar uses bar_end so replaced bank_end with
bar_end in spi_flash_read_bar

Signed-off-by: Jagan Teki 
---
 drivers/mtd/spi/spi_flash.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index f58a587..9ffaf7d 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -139,7 +139,7 @@ static int spi_flash_read_bar(struct spi_flash *flash, u8 
idcode0)
int ret;
 
if (flash->size <= SPI_FLASH_16MB_BOUN)
-   goto bank_end;
+   goto bar_end;
 
switch (idcode0) {
case SPI_FLASH_CFI_MFR_SPANSION:
@@ -158,7 +158,7 @@ static int spi_flash_read_bar(struct spi_flash *flash, u8 
idcode0)
return ret;
}
 
-bank_end:
+bar_end:
flash->bank_curr = curr_bank;
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] arm: mvebu: Add SolidRun ClearFog Armada 38x initial support

[Dennis Gilmore]

Trying to test this  I have hit an error with CONFIG_PHY_ADDR not defined.

I am guessing that I am missing some other sets of patches. digging through 
patchwork I am not able to figure it out.  there is a bunch of patches in 
patchwork that say they are in NEW state however they are in the tree so not 
labeled correctly.  Any clues as to which patch sets this depends on are 
appreciated.

Dennis


On Friday, November 27, 2015 04:15:17 PM Stefan Roese wrote:
> This patch adds basic support for the SolidRun ClearFog Armada 38x based
> board to mainline U-Boot. Supported interfaces / devices are:
> - DDR3
> - UART
> - MMC
> - Ethernet port 0 (connected to dedicated PHY)
> - I2C
> 
> The included DT source was taken from Russell King's ftp server:
> http://www.home.arm.linux.org.uk/~rmk/clearfog/
> 
> With only minor modifications, like the addition of some aliases and the
> "u-boot,dm-pre-reloc" property.
> 
> Signed-off-by: Stefan Roese 
> Cc: Rabeeh Khoury 
> Cc: Luka Perkov 
> ---
>  arch/arm/Kconfig |   1 +
>  arch/arm/dts/Makefile|   1 +
>  arch/arm/dts/armada-388-clearfog.dts | 509
> +++ arch/arm/mach-mvebu/Kconfig  | 
>  3 +
>  board/solidrun/clearfog/Kconfig  |  12 +
>  board/solidrun/clearfog/MAINTAINERS  |   6 +
>  board/solidrun/clearfog/Makefile |   7 +
>  board/solidrun/clearfog/README   |  18 ++
>  board/solidrun/clearfog/clearfog.c   | 156 +++
>  board/solidrun/clearfog/kwbimage.cfg |  12 +
>  configs/clearfog_defconfig   |  20 ++
>  include/configs/clearfog.h   | 183 +
>  12 files changed, 928 insertions(+)
>  create mode 100644 arch/arm/dts/armada-388-clearfog.dts
>  create mode 100644 board/solidrun/clearfog/Kconfig
>  create mode 100644 board/solidrun/clearfog/MAINTAINERS
>  create mode 100644 board/solidrun/clearfog/Makefile
>  create mode 100644 board/solidrun/clearfog/README
>  create mode 100644 board/solidrun/clearfog/clearfog.c
>  create mode 100644 board/solidrun/clearfog/kwbimage.cfg
>  create mode 100644 configs/clearfog_defconfig
>  create mode 100644 include/configs/clearfog.h
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 4ddc2de..0c4794b 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -801,6 +801,7 @@ source "board/siemens/draco/Kconfig"
>  source "board/siemens/pxm2/Kconfig"
>  source "board/siemens/rut/Kconfig"
>  source "board/silica/pengwyn/Kconfig"
> +source "board/solidrun/clearfog/Kconfig"
>  source "board/spear/spear300/Kconfig"
>  source "board/spear/spear310/Kconfig"
>  source "board/spear/spear320/Kconfig"
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 9719103..0494997 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -47,6 +47,7 @@ dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
>   tegra210-p2571.dtb
> 
>  dtb-$(CONFIG_ARCH_MVEBU) +=  \
> + armada-388-clearfog.dtb \
>   armada-388-gp.dtb   \
>   armada-xp-gp.dtb\
>   armada-xp-maxbcm.dtb
> diff --git a/arch/arm/dts/armada-388-clearfog.dts
> b/arch/arm/dts/armada-388-clearfog.dts new file mode 100644
> index 000..b2dfd56
> --- /dev/null
> +++ b/arch/arm/dts/armada-388-clearfog.dts
> @@ -0,0 +1,509 @@
> +/*
> + * Device Tree file for SolidRun Clearfog revision A1 rev 2.0 (88F6828)
> + *
> + *  Copyright (C) 2015 Russell King
> + *
> + * This board is in development; the contents of this file work with
> + * the A1 rev 2.0 of the board, which does not represent final
> + * production board.  Things will change, don't expect this file to
> + * remain compatible info the future.
> + *
> + * 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
> + * version 2 as published by the Free Software Foundation.
> + *
> + * 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:
> + *
>