Re: [U-Boot] [PATCH v6 00/15] Add PSCI support for Jetson TK1/Tegra124 + CNTFRQ fix

2015-04-17 Thread Jan Kiszka
On 2015-04-14 16:30, Ian Campbell wrote:
 On Tue, 2015-04-14 at 16:12 +0200, Jan Kiszka wrote:
 On 2015-04-14 16:06, Stephen Warren wrote:
 On 04/14/2015 07:46 AM, Tom Rini wrote:
 On Mon, Apr 13, 2015 at 06:48:05AM +0200, Jan Kiszka wrote:

 Changes in v6:
   - rebased over master
   - included Thierry's SMMU enabling patch
   - moved activation patch at the end so that it can be held back

 This version can also be found at
 https://github.com/siemens/u-boot/tree/jetson-tk1-v6.

 So what level of coordination do we need on applying this series so that
 kernels (both old and new) can continue to function?  And perhaps README
 updates or similar?  Thanks!

 Hopefully this series doesn't change anything by default, and simply
 allows people to turn on support for booting kernels in non-secure mode
 if they want to? If so, there shouldn't be any co-ordination required.
 If it changes the default behaviour, co-ordination is probably required,
 and that'd be a bad thing.

 Sorry, forgot to mention: I can't flip the default behaviour to leave
 virtualization support off only for the TK1. That's a generic default.
 
 Would enabling it in the compile but adding bootm_boot_mode=sec to the
 default environment (so it isn't used by default) be considered
 sufficiently backwards compatible?

This turned out to not work as expected: booting in secure mode seems
to prevent that Linux can bring up CPUs 1-3. Not sure if this is to be
expected or a bug, but I will now take a different route:

diff --git a/arch/arm/cpu/armv7/Kconfig b/arch/arm/cpu/armv7/Kconfig
index 61e7c82..e5d4dcc 100644
--- a/arch/arm/cpu/armv7/Kconfig
+++ b/arch/arm/cpu/armv7/Kconfig
@@ -27,7 +27,7 @@ config ARMV7_BOOT_SEC_DEFAULT
 config ARMV7_VIRT
boolean Enable support for hardware virtualization if EXPERT
depends on CPU_V7_HAS_VIRT  ARMV7_NONSEC
-   default y
+   default y if !TEGRA
---help---
Say Y here to boot in hypervisor (HYP) mode when booting non-secure.
 

A patch to be inserted before the last one (and to be reverted once
Linux is fixed) will follow.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] spi and block bits

2015-04-17 Thread Michael Walle

Am 2015-04-16 20:32, schrieb Jagan Teki:

On 9 February 2015 at 04:57, Michael Walle mich...@walle.cc wrote:

Hi there,

I stumbled across a situation where the SPI flash on my board was 
write
protected and i could not unlock it in the bootloader. This is 
especially
unfortunate because the recovery mechanism relies on the bootloader to 
be

able to erase the environment.


Which flash vendor it is? seems like there is a hardware write 
protected

mechanism in ST MICRON flashes.


it is a st micron. (see include/configs/lsxl.h)


Please refer that, may be this looks similar to that W#/Vpp
CONFIG_SYS_SPI_ST_ENABLE_WP_PIN


But it isn't related to that.

My point was, if linux enables the lock bits, there is no way you can 
write to the flash in the bootloader anymore. Because it is not possible 
to clear these bits in u-boot. If you have a macronix or an ST flash the 
block protection bits are cleared on probe. see sf_probe.c:



/* Flash powers up read-only, so clear BP# bits */
#if defined(CONFIG_SPI_FLASH_ATMEL) || \
defined(CONFIG_SPI_FLASH_MACRONIX) || \
defined(CONFIG_SPI_FLASH_SST)
spi_flash_cmd_write_status(flash, 0);
#endif

Although as the comment says, it is because these chips power up in 
read-only state by default. In my case, linux would set these bits.


To be more precise, the fw_setenv will leave the flash write protected 
and i cannot modify the environment in the bootloader anymore.



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


Re: [U-Boot] [U-boot][PATCH 0/2] drivers/ddr/altera: Add the DDR controller driver for SoCFPGA

2015-04-17 Thread Dinh Nguyen


On 4/16/15 1:32 AM, Marek Vasut wrote:
 On Wednesday, April 15, 2015 at 11:14:50 PM, dingu...@opensource.altera.com 
 wrote:
 From: Dinh Nguyen dingu...@opensource.altera.com

 Hello,

 The following 2 patches adds the DDR controller driver that is in the
 Altera SoCFPGA platform. This driver is needed for the SPL on the
 platform.
 
 Hi,
 
 current u-boot-socfpga/master doesn't build. Can you please send me
 a patch(set) for it, so it builds, so I can send it upstream before
 I start digging in these DRAM patches ?
 

Oops, apologize for that, will rebase and resend.

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


[U-Boot] [PATCH 14.5/15] tegra: Keep virt support disabled by default

2015-04-17 Thread Jan Kiszka
Upstream Linux is broken with default configs when PSCI is enabled.
So the user should explicitly enable virtualization, e.g. when she
disabled CONFIG_CPU_IDLE in Linux (in which case it's safe to use). We
can revert this workaround once Linux got fixed.

Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
 arch/arm/cpu/armv7/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/Kconfig b/arch/arm/cpu/armv7/Kconfig
index 61e7c82..e5d4dcc 100644
--- a/arch/arm/cpu/armv7/Kconfig
+++ b/arch/arm/cpu/armv7/Kconfig
@@ -27,7 +27,7 @@ config ARMV7_BOOT_SEC_DEFAULT
 config ARMV7_VIRT
boolean Enable support for hardware virtualization if EXPERT
depends on CPU_V7_HAS_VIRT  ARMV7_NONSEC
-   default y
+   default y if !TEGRA
---help---
Say Y here to boot in hypervisor (HYP) mode when booting non-secure.
 
-- 
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [ANN] U-Boot v2015.04 released

2015-04-17 Thread Wolfgang Denk
Dear Tom,

In message 20150413172047.GG16702@bill-the-cat you wrote:
 
 I've pushed v2015.04 out to the repository and tarballs should exist
 soon.

Thanks.

Raeball is out now, sorry for the delay.

Here is the usual release statistics (full, unabbreviated lists as
usual on the web site); one comment:   I'm especially happy about the
growing number of developers:

2014.04 -  769 csets from 109 developers 
2014.07 - 1074 csets from 146 developers 
2014.10 -  csets from 145 developers 
2015.01 - 1588 csets from 162 developers 
2015.04 - 1585 csets from 169 developers 

That's a nice indication for a spritely project.  Thanks to everone
who contributes and helps to bring this forward!


Processed 1585 csets from 169 developers
33 employers found
A total of 99448 lines added, 166603 removed (delta -67155)

Developers with the most changesets
Simon Glass225 (14.2%)
Masahiro Yamada158 (10.0%)
Hans de Goede  140 (8.8%)
Bin Meng67 (4.2%)
Michal Simek52 (3.3%)
Alexey Brodkin  39 (2.5%)
Nikita Kiryanov 39 (2.5%)
Fabio Estevam   36 (2.3%)
Bo Shen 33 (2.1%)
Przemyslaw Marczak  31 (2.0%)
...

Developers with the most changed lines
Matthias Fuchs88995 (35.4%)
Masahiro Yamada   59572 (23.7%)
Stefan Roese  19549 (7.8%)
Simon Glass   12844 (5.1%)
Bin Meng   9774 (3.9%)
Hans de Goede  5613 (2.2%)
Albert ARIBAUD \(3ADEV\)   4474 (1.8%)
Vladimir Barinov   3047 (1.2%)
Nobuhiro Iwamatsu  2782 (1.1%)
gaurav rana1937 (0.8%)
...

Developers with the most lines removed
Matthias Fuchs88963 (53.4%)
Masahiro Yamada   54187 (32.5%)
Peter Tyser 339 (0.2%)
Paul Burton 231 (0.1%)
Daniel Schwierzeck  193 (0.1%)
Grazvydas Ignotas   105 (0.1%)
Thomas Langer   102 (0.1%)
Anthoine Bourgeois   88 (0.1%)
Wu, Josh 81 (0.0%)
James Doublesin  62 (0.0%)
...

Developers with the most signoffs (total 219)
Hans de Goede   49 (22.4%)
Minkyu Kang 41 (18.7%)
Tom Warren  33 (15.1%)
Nobuhiro Iwamatsu   11 (5.0%)
Simon Glass  7 (3.2%)
Andreas Bießmann 6 (2.7%)
Michal Simek 6 (2.7%)
Alexey Brodkin   6 (2.7%)
Tom Rini 4 (1.8%)
Joe Hershberger  4 (1.8%)
...

Developers with the most reviews (total 293)
Simon Glass 93 (31.7%)
York Sun58 (19.8%)
Bin Meng32 (10.9%)
Tom Rini26 (8.9%)
Masahiro Yamada 19 (6.5%)
Luka Perkov 14 (4.8%)
Stefan Roese 9 (3.1%)
Jagannadha Sutradharudu Teki 8 (2.7%)
Lukasz Majewski  7 (2.4%)
Stephen Warren   6 (2.0%)
...

Developers with the most test credits (total 117)
Simon Glass 31 (26.5%)
Bo Shen 14 (12.0%)
Wu, Josh13 (11.1%)
Matt Porter 11 (9.4%)
Bin Meng 8 (6.8%)
Heiko Schocher   6 (5.1%)
Stephen Warren   4 (3.4%)
Tom Rini 2 (1.7%)
Lukasz Majewski  2 (1.7%)
Alexey Brodkin   2 (1.7%)
...

Developers who gave the most tested-by credits (total 117)
Nikita Kiryanov 32 (27.4%)
Simon Glass 15 (12.8%)
Akshay Saraswat 11 (9.4%)
Nishanth Menon   8 (6.8%)
Ajay Kumar   8 (6.8%)
Peter Tyser  5 (4.3%)
Masahiro Yamada  4 (3.4%)
Przemyslaw Marczak   4 (3.4%)
Hans de Goede3 (2.6%)
James Doublesin  3 (2.6%)
...

Developers with the most report credits (total 24)
Stephen Warren   4 (16.7%)
York Sun 3 (12.5%)
Albert ARIBAUD   3 (12.5%)
Masahiro Yamada  2 (8.3%)
Tom Rini 2 (8.3%)
Stefan Roese 1 (4.2%)
Jan Kiszka   1 (4.2%)
Chee-Yang Chau   1 (4.2%)
Matthew Gerlach  1 (4.2%)
Matt Ranostay1 (4.2%)
...

Developers who gave the most report credits (total 24)
Simon Glass  7 (29.2%)
Masahiro Yamada  6 (25.0%)
Tom Rini 2 (8.3%)
Stephen Warren   1 (4.2%)
Nishanth Menon   1 (4.2%)
Hans de Goede1 (4.2%)
Fabio Estevam1 (4.2%)
Pantelis Antoniou1 (4.2%)
Michal Simek 1 (4.2%)
Michal Marek 1 (4.2%)
...

Top changeset contributors by employer
(Unknown)  493 (31.1%)
Google, Inc.   226 (14.3%)
Freescale  165 (10.4%)
Red Hat140 (8.8%)
Panasonic  109 (6.9%)
Samsung  

Re: [U-Boot] [PATCH 1/2] armv8: caches: Disable dcache after flush

2015-04-17 Thread Mark Rutland
   Now in the flush_dcache_all we are invoking the actual asm call to
   flush dcache which may wipeout the stored return value in stack with
   cahe contents(main memory). Hence the return from the flush_dcahe_all
   will fail.
  
   To confirm this I modified the dcache_disable in the below way and it
  worked fine.
   1. Disable the dcache.
   2. Now I called the __asm_flush_dcache_all(); and then flush_l3_cache();
  instead of calling the flush_dcache_all().
  
  That also is unsafe; implicit (e.g. stack) accesses at any point after 
  SCTLR.C is
  cleared and before flush_l3_cache() has completed may see stale data, or
  get overwritten by stale data.
  
  Set/Way ops only flush the CPU-local caches, so you only guarantee that
  these are clean (and potentially dirty cache lines for the stack could be 
  sat in
  L3 and written back at any time). So your flush_l3_cache() function might 
  not
  work.
  
  Per ARMv8 the L3 _must_ respect maintenance by VA, so after disabling the
  MMU you can flush the memory region corresponding to your stack (and any
  other data you need) by VA to the PoC before executing flush_l3_cache(), in
  addition to the Set/Way ops used to empty the CPU-local caches.
 Thanks for explanation.
 So in that case, the flushing of the required stack or any other data
 which needs to be flushed should be part of board specific. Am I
 correct?

It could be done in generic code, assuming we know the bounds of memory
which will be used, because maintenance by VA should always work.

Do we know which memory U-Boot might use (e.g. does it all fall within
some static carveout?), or can it dynamically allocate from anywhere in
memory?

 If yes, then this disable_dcache() should contain a asm call to a
 routine() (which might be board specific) after disabling the cache to
 flush the required data and then flush_dcache_all() followed by flush
 L3 cache.. 

You could probably get away with:

* Load the memory bounds that we need to flush into some registers, or
  flush some datastructure containing these to memory.
* In assembly:
  - disable the MMU.
  - flush the PA range(s) we need to use to be able to use C safely.
  - flush by Set/Way to empry the CPU-local caches
* Implementation-specific L3 flushing for anything else.

If we only map a small amount of memory, we could simply flush this by
VA (knowing that this will drain the CPU and L3 caches, without any
special maintenance).

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


Re: [U-Boot] [PATCH] video, ipu: make ldb clock frequenz overwriteable through board code

2015-04-17 Thread Heiko Schocher

Hello Eric,

Am 16.04.2015 02:27, schrieb Eric Nelson:

Hi Heiko,

On 04/12/2015 01:19 AM, Heiko Schocher wrote:

the ldb clock can be setup in board code (for example set through PLL5).
Update the ldb_clock rate also through board code.

This should be removed, if a clock framework is availiable.


Any chance you're up to the task?

Searching for 'clk_get' in the sources shows a proliferation
of attempts for various SOCs and drivers.


Yes ... but it seems, I get no time for such a job :-(


Signed-off-by: Heiko Schocher h...@denx.de
---

  drivers/video/ipu.h|  1 +
  drivers/video/ipu_common.c | 11 +++
  2 files changed, 12 insertions(+)

diff --git a/drivers/video/ipu.h b/drivers/video/ipu.h
index 091b58f..f13934f 100644
--- a/drivers/video/ipu.h
+++ b/drivers/video/ipu.h
@@ -266,4 +266,5 @@ void ipu_dp_uninit(ipu_channel_t channel);
  void ipu_dp_dc_disable(ipu_channel_t channel, unsigned char swap);
  ipu_color_space_t format_to_colorspace(uint32_t fmt);



I'd rather see this in imx-common/video.h to avoid #includes
out of the driver tree.


ok, moved.


+int ipu_set_ldb_clock(int rate);
  #endif
diff --git a/drivers/video/ipu_common.c b/drivers/video/ipu_common.c
index 1a209d4..dc054bc 100644
--- a/drivers/video/ipu_common.c
+++ b/drivers/video/ipu_common.c
@@ -1198,3 +1198,14 @@ ipu_color_space_t format_to_colorspace(uint32_t fmt)
}
return RGB;
  }
+
+/* should removed when clk framework is availiable */
+int ipu_set_ldb_clock(int rate)
+{


This forces a tight dependency on when this is called that
using ldb_clk directly would prevent.


Sorry, did not understand you here ...


+   if (g_ldb_clk == NULL)
+   return -ENOENT;
+
+   g_ldb_clk-rate = rate;
+
+   return 0;
+}



The use of g_ldb_clk seems pretty dodgy everywhere in the
IPU driver.

Otherwise:

Tested-by: Eric Nelson eric.nel...@boundarydevices.com


Thanks for testing.

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 4/6] zynqmp: Add SPI driver support for ZynqMP

2015-04-17 Thread Jagan Teki
On 17 April 2015 at 11:02, Michal Simek michal.si...@xilinx.com wrote:
 On 04/16/2015 08:13 PM, Jagan Teki wrote:
 On 15 April 2015 at 19:03, Michal Simek michal.si...@xilinx.com wrote:
 From: Siva Durga Prasad Paladugu siva.durga.palad...@xilinx.com

 Added the SPI driver support for ZynqMP
 The controller is same as zynq SPI controller

 Signed-off-by: Siva Durga Prasad Paladugu siva...@xilinx.com
 Signed-off-by: Michal Simek michal.si...@xilinx.com
 ---

  arch/arm/include/asm/arch-zynqmp/hardware.h | 3 +++
  include/configs/xilinx_zynqmp.h | 8 
  2 files changed, 11 insertions(+)

 diff --git a/arch/arm/include/asm/arch-zynqmp/hardware.h 
 b/arch/arm/include/asm/arch-zynqmp/hardware.h
 index 1fedb1bb4b94..c9dc49d78317 100644
 --- a/arch/arm/include/asm/arch-zynqmp/hardware.h
 +++ b/arch/arm/include/asm/arch-zynqmp/hardware.h
 @@ -11,6 +11,9 @@
  #define ZYNQ_SERIAL_BASEADDR0  0xFF00
  #define ZYNQ_SERIAL_BASEADDR1  0xFF001000

 +#define ZYNQ_SPI_BASEADDR0 0xFF04
 +#define ZYNQ_SPI_BASEADDR1 0xFF05
 +
  #define ZYNQ_I2C_BASEADDR0 0xFF02
  #define ZYNQ_I2C_BASEADDR1 0xFF03

 diff --git a/include/configs/xilinx_zynqmp.h 
 b/include/configs/xilinx_zynqmp.h
 index 54bca6d47b72..df7541b85baf 100644
 --- a/include/configs/xilinx_zynqmp.h
 +++ b/include/configs/xilinx_zynqmp.h
 @@ -71,6 +71,14 @@
  #define CONFIG_CMD_ELF
  #define CONFIG_MP

 +/* SPI */
 +#ifdef CONFIG_ZYNQ_SPI
 +# define CONFIG_SPI_FLASH
 +# define CONFIG_SPI_FLASH_SST
 +# define CONFIG_CMD_SPI

 CMD_SPI is never been verified I suppose, if so not required at this
 point of time.

 It is enabled on 75 platforms that's why I can't see any problem with
 it. If something is not verified then it should be verified. If it is
 completely broken it should be removed.

I do understand that it uses more boards based on their usage and need,
I believe zynq_spi mostly for flash related ops, if ie the case CMD_SF
enough I guess.

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


Re: [U-Boot] [PATCH v3 1/9] sf: Update SST flash params

2015-04-17 Thread Jagan Teki
Hi Bin,

On 17 April 2015 at 07:14, Bin Meng bmeng...@gmail.com wrote:
 Hi Jagan,

 On Fri, Apr 17, 2015 at 2:09 AM, Jagan Teki jagannadh.t...@gmail.com wrote:
 Hi Bin,

 I think you have a different interpretation of sector size here-

 /* The size listed here is what works with SPINOR_OP_SE, which isn't
  * necessarily called a sector by the vendor.
  */
 Say for example SST25VF040B has 8 sectors of which each sector size is
 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or
 64K sector erase through flags.

 Linux does follow the same-
 /* SST -- large erase sizes are overlays, sectors are 4K */
 { sst25vf040b, INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K |
 SST_WRITE) },
 { sst25vf080b, INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
 SST_WRITE) },
 { sst25vf016b, INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
 SST_WRITE) },
 { sst25vf032b, INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |
 SST_WRITE) },

 Please check it.


 Yes, I know this pretty well. And I want to change this behavior, as
 my cover letter says.

 Currently the 'sf erase' command operates on a 64KB granularity, while
 the actual erase command is 4KB granularity, which is inconsistent and
 causes confusion.

It never related to 'sf erase' instead based on the 'params-flags'
sf_probe will decide which erase_cmd with erase_size will use.
/* Compute erase sector and command */
if (params-flags  SECT_4K) {
flash-erase_cmd = CMD_ERASE_4K;
flash-erase_size = 4096  flash-shift;
} else if (params-flags  SECT_32K) {
flash-erase_cmd = CMD_ERASE_32K;
flash-erase_size = 32768  flash-shift;
} else {
flash-erase_cmd = CMD_ERASE_64K;
flash-erase_size = flash-sector_size;
}

And to be honest, these flashes were tested with lowest ie 4KB so even if they
do support 64KB, we mentioned on 4KB on 'params-flags' as we tested
well with that
and it works consistently.


 On 10 December 2014 at 18:21, Bin Meng bmeng...@gmail.com wrote:
 Update SST25VF064C read command to RD_EXTN per datasheet.
 Also change flash sector size to 4KiB to match SECT_4K.

 Signed-off-by: Bin Meng bmeng...@gmail.com
 ---

  drivers/mtd/spi/sf_params.c | 20 ++--
  1 file changed, 10 insertions(+), 10 deletions(-)

 diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
 index 30875b3..5482700 100644
 --- a/drivers/mtd/spi/sf_params.c
 +++ b/drivers/mtd/spi/sf_params.c
 @@ -89,16 +89,16 @@ const struct spi_flash_params spi_flash_params_table[] 
 = {
 {N25Q1024A,  0x20bb21, 0x0,   64 * 1024,  2048, RD_FULL, 
 WR_QPP | E_FSR | SECT_4K},
  #endif
  #ifdef CONFIG_SPI_FLASH_SST/* SST */
 -   {SST25VF040B,0xbf258d, 0x0,   64 * 1024, 8, RD_NORM,  
 SECT_4K | SST_WR},
 -   {SST25VF080B,0xbf258e, 0x0,   64 * 1024,16, RD_NORM,  
 SECT_4K | SST_WR},
 -   {SST25VF016B,0xbf2541, 0x0,   64 * 1024,32, RD_NORM,  
 SECT_4K | SST_WR},
 -   {SST25VF032B,0xbf254a, 0x0,   64 * 1024,64, RD_NORM,  
 SECT_4K | SST_WR},
 -   {SST25VF064C,0xbf254b, 0x0,   64 * 1024,   128, RD_NORM,  
  SECT_4K},
 -   {SST25WF512, 0xbf2501, 0x0,   64 * 1024, 1, RD_NORM,  
 SECT_4K | SST_WR},
 -   {SST25WF010, 0xbf2502, 0x0,   64 * 1024, 2, RD_NORM,  
 SECT_4K | SST_WR},
 -   {SST25WF020, 0xbf2503, 0x0,   64 * 1024, 4, RD_NORM,  
 SECT_4K | SST_WR},
 -   {SST25WF040, 0xbf2504, 0x0,   64 * 1024, 8, RD_NORM,  
 SECT_4K | SST_WR},
 -   {SST25WF080, 0xbf2505, 0x0,   64 * 1024,16, RD_NORM,  
 SECT_4K | SST_WR},
 +   {SST25VF040B,0xbf258d, 0x0,4 * 1024,   128, RD_NORM,  
 SECT_4K | SST_WR},
 +   {SST25VF080B,0xbf258e, 0x0,4 * 1024,   256, RD_NORM,  
 SECT_4K | SST_WR},
 +   {SST25VF016B,0xbf2541, 0x0,4 * 1024,   512, RD_NORM,  
 SECT_4K | SST_WR},
 +   {SST25VF032B,0xbf254a, 0x0,4 * 1024,  1024, RD_NORM,  
 SECT_4K | SST_WR},
 +   {SST25VF064C,0xbf254b, 0x0,4 * 1024,  2048, RD_EXTN,  
  SECT_4K},
 +   {SST25WF512, 0xbf2501, 0x0,4 * 1024,16, RD_NORM,  
 SECT_4K | SST_WR},
 +   {SST25WF010, 0xbf2502, 0x0,4 * 1024,32, RD_NORM,  
 SECT_4K | SST_WR},
 +   {SST25WF020, 0xbf2503, 0x0,4 * 1024,64, RD_NORM,  
 SECT_4K | SST_WR},
 +   {SST25WF040, 0xbf2504, 0x0,4 * 1024,   128, RD_NORM,  
 SECT_4K | SST_WR},
 +   {SST25WF080, 0xbf2505, 0x0,4 * 1024,   256, RD_NORM,  
 SECT_4K | SST_WR},
  #endif
  #ifdef CONFIG_SPI_FLASH_WINBOND/* WINBOND */
 {W25P80, 0xef2014, 0x0,   64 * 

Re: [U-Boot] [PATCH v3 7/7] colibri_vf: Enable USB support for Colibri Vybrid

2015-04-17 Thread maitysanchayan
Hello,

On 15-04-16 22:21:11, Marek Vasut wrote:
 On Wednesday, April 15, 2015 at 12:54:28 PM, Sanchayan Maity wrote:
  Enable USB support on Toradex Colibri Vybrid Modules.
  
  Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
  ---
   board/toradex/colibri_vf/colibri_vf.c | 25 +--
   include/configs/colibri_vf.h  | 37
  +++ 2 files changed, 60 insertions(+), 2
  deletions(-)
  
  diff --git a/board/toradex/colibri_vf/colibri_vf.c
  b/board/toradex/colibri_vf/colibri_vf.c index e7bc6c1..054e6f9 100644
  --- a/board/toradex/colibri_vf/colibri_vf.c
  +++ b/board/toradex/colibri_vf/colibri_vf.c
  @@ -197,7 +197,8 @@ static void clock_init(void)
  clrsetbits_le32(ccm-ccgr0, CCM_REG_CTRL_MASK,
  CCM_CCGR0_UART0_CTRL_MASK);
  clrsetbits_le32(ccm-ccgr1, CCM_REG_CTRL_MASK,
  -   CCM_CCGR1_PIT_CTRL_MASK | CCM_CCGR1_WDOGA5_CTRL_MASK);
  +   CCM_CCGR1_PIT_CTRL_MASK | CCM_CCGR1_WDOGA5_CTRL_MASK |
  +   CCM_CCGR1_USBC0_CTRL_MASK);
 
 You probably want to flip these CCM regs only if CONFIG_CI_UDC is enabled
 or something along those lines, right ?

Yes, that would be be better. Will send a new corrected patch for this. 
I assume since there are no issues with the rest of the patchset so 
sending a respin of this last patch would do?!

Thanks for the feedback and catching this.

 
 Best regards,
 Marek Vasut

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


Re: [U-Boot] [PATCH v3 7/7] colibri_vf: Enable USB support for Colibri Vybrid

2015-04-17 Thread Marek Vasut
On Friday, April 17, 2015 at 11:21:03 AM, maitysancha...@gmail.com wrote:
 Hello,
 
 On 15-04-16 22:21:11, Marek Vasut wrote:
  On Wednesday, April 15, 2015 at 12:54:28 PM, Sanchayan Maity wrote:
   Enable USB support on Toradex Colibri Vybrid Modules.
   
   Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
   ---
   
board/toradex/colibri_vf/colibri_vf.c | 25 +--
include/configs/colibri_vf.h  | 37
   
   +++ 2 files changed, 60 insertions(+),
   2 deletions(-)
   
   diff --git a/board/toradex/colibri_vf/colibri_vf.c
   b/board/toradex/colibri_vf/colibri_vf.c index e7bc6c1..054e6f9 100644
   --- a/board/toradex/colibri_vf/colibri_vf.c
   +++ b/board/toradex/colibri_vf/colibri_vf.c
   @@ -197,7 +197,8 @@ static void clock_init(void)
   
 clrsetbits_le32(ccm-ccgr0, CCM_REG_CTRL_MASK,
 
 CCM_CCGR0_UART0_CTRL_MASK);
 
 clrsetbits_le32(ccm-ccgr1, CCM_REG_CTRL_MASK,
   
   - CCM_CCGR1_PIT_CTRL_MASK | CCM_CCGR1_WDOGA5_CTRL_MASK);
   + CCM_CCGR1_PIT_CTRL_MASK | CCM_CCGR1_WDOGA5_CTRL_MASK |
   + CCM_CCGR1_USBC0_CTRL_MASK);
  
  You probably want to flip these CCM regs only if CONFIG_CI_UDC is enabled
  or something along those lines, right ?
 
 Yes, that would be be better. Will send a new corrected patch for this.
 I assume since there are no issues with the rest of the patchset so
 sending a respin of this last patch would do?!
 
 Thanks for the feedback and catching this.

Yup, resending just the last patch is fine :)

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 RESEND 1/3] driver/ddr/altera: Add DDR driver for Altera's SDRAM controller

2015-04-17 Thread Pavel Machek
Hi!

 +#ifndef  _SDRAM_H_
 +#define  _SDRAM_H_
 +
 +#ifndef __ASSEMBLY__
 +
 +/* function declaration */

You can delete this comment.

 +#define \
 +SDR_CTRLGRP_MPTHRESHOLDRST_0_THRESHOLDRSTCYCLES_31_0_LSB 0
 +#define  \
 +SDR_CTRLGRP_MPTHRESHOLDRST_0_THRESHOLDRSTCYCLES_31_0_MASK \
 +0x
 +/* Register template: sdr::ctrlgrp::mpthresholdrst::mpthresholdrst_1   */
 +#define \
 +SDR_CTRLGRP_MPTHRESHOLDRST_1_THRESHOLDRSTCYCLES_63_32_LSB 0
 +#define \
 +SDR_CTRLGRP_MPTHRESHOLDRST_1_THRESHOLDRSTCYCLES_63_32_MASK \
 +0x
 +/* Register template: sdr::ctrlgrp::mpthresholdrst::mpthresholdrst_2   */
 +#define \
 +SDR_CTRLGRP_MPTHRESHOLDRST_2_THRESHOLDRSTCYCLES_79_64_LSB 0
 +#define \
 +SDR_CTRLGRP_MPTHRESHOLDRST_2_THRESHOLDRSTCYCLES_79_64_MASK \
 +0x

Can we get slightly shorter define names?

 +/* Register template: sdr::ctrlgrp::remappriority  */
 +#define SDR_CTRLGRP_REMAPPRIORITY_PRIORITYREMAP_LSB 0
 +#define SDR_CTRLGRP_REMAPPRIORITY_PRIORITYREMAP_MASK 0x00ff
 +/* Register template: sdr::ctrlgrp::phyctrl::phyctrl_0 */
 +#define SDR_CTRLGRP_PHYCTRL_PHYCTRL_0_SAMPLECOUNT_19_0_LSB 12
 +#define SDR_CTRLGRP_PHYCTRL_PHYCTRL_0_SAMPLECOUNT_19_0_WIDTH 20
 +#define SDR_CTRLGRP_PHYCTRL_PHYCTRL_0_SAMPLECOUNT_19_0_SET(x) \
 + (((x)  12)  0xf000)
 +#define SDR_CTRLGRP_PHYCTRL_PHYCTRL_0_ADDLATSEL_SET(x) \
 + (((x)  10)  0x0c00)
 +#define SDR_CTRLGRP_PHYCTRL_PHYCTRL_0_DQSLOGICDELAYEN_SET(x) \
 + (((x)  6)  0x00c0)
 +#define SDR_CTRLGRP_PHYCTRL_PHYCTRL_0_RESETDELAYEN_SET(x) \
 + (((x)  8)  0x0100)
 +#define SDR_CTRLGRP_PHYCTRL_PHYCTRL_0_LPDDRDIS_SET(x) \
 + (((x)  9)  0x0200)
 +#define SDR_CTRLGRP_PHYCTRL_PHYCTRL_0_DQSDELAYEN_SET(x) \
 + (((x)  4)  0x0030)
 +#define SDR_CTRLGRP_PHYCTRL_PHYCTRL_0_DQDELAYEN_SET(x) \
 + (((x)  2)  0x000c)
 +#define SDR_CTRLGRP_PHYCTRL_PHYCTRL_0_ACDELAYEN_SET(x) \
 + (((x)  0)  0x0003)
 +/* Register template: sdr::ctrlgrp::phyctrl::phyctrl_1 */
 +#define SDR_CTRLGRP_PHYCTRL_PHYCTRL_1_LONGIDLESAMPLECOUNT_19_0_WIDTH 20
 +#define SDR_CTRLGRP_PHYCTRL_PHYCTRL_1_LONGIDLESAMPLECOUNT_19_0_SET(x) \
 + (((x)  12)  0xf000)
 +#define SDR_CTRLGRP_PHYCTRL_PHYCTRL_1_SAMPLECOUNT_31_20_SET(x) \
 + (((x)  0)  0x0fff)
 +/* Register template: sdr::ctrlgrp::phyctrl::phyctrl_2 */
 +#define SDR_CTRLGRP_PHYCTRL_PHYCTRL_2_LONGIDLESAMPLECOUNT_31_20_SET(x) \
 + (((x)  0)  0x0fff)

Too long names here, too..

 --- /dev/null
 +++ b/arch/arm/include/asm/arch-socfpga/sdram_config.h
 @@ -0,0 +1,100 @@
 +/*
 + * Copyright Altera Corporation (C) 2012-2015
 + *
 + * SPDX-License-Identifier:BSD-3-Clause
 + */
 +

If this file is autogenerated, you should mention it here.

 +#ifdef CONFIG_SOCFPGA_ARRIA5
 +/* The if..else... is not required if generated by tools */

What does this comment say?

 +#define CONFIG_HPS_SDR_CTRLCFG_MPPACING_1_THRESHOLD2_3_0 0
 +#define CONFIG_HPS_SDR_CTRLCFG_MPPACING_2_THRESHOLD2_35_40x41041041
 +#define CONFIG_HPS_SDR_CTRLCFG_MPPACING_3_THRESHOLD2_59_36   0x410410
 +#define CONFIG_HPS_SDR_CTRLCFG_MPTHRESHOLDRST_0_THRESHOLDRSTCYCLES_31_0 \
 +0x01010101
 +#define CONFIG_HPS_SDR_CTRLCFG_MPTHRESHOLDRST_1_THRESHOLDRSTCYCLES_63_32 \
 +0x01010101
 +#define CONFIG_HPS_SDR_CTRLCFG_MPTHRESHOLDRST_2_THRESHOLDRSTCYCLES_79_64 \
 +0x0101

Drop HPS and CTRLCFG from the config names... they should still be
unique and you'll not hit 80 column limits with just the name?

 +#define COMPARE_FAIL_ACTION  return 1;

Macros that change control flow are nasty.

 +/* Below function only applicable for SPL */

Function below?

Add ifdef so that it is not available for u-boot proper?

 +typedef struct _sdram_prot_rule {
 + uint64_tsdram_start;/* SDRAM start address */
 + uint64_tsdram_end;  /* SDRAM end address */
 + uint32_trule;   /* SDRAM protection rule number: 0-19 */
 + int valid;  /* Rule valid or not? 1 - valid, 0 not*/
 +
 + uint32_tsecurity;
 + uint32_tportmask;
 + uint32_tresult;
 + uint32_tlo_prot_id;
 + uint32_thi_prot_id;
 +} sdram_prot_rule, *psdram_prot_rule;

Struct typedefs are nasty. Just use struct sdram_prot_rule?

 +static void sdram_get_rule(psdram_prot_rule prule)
 +{
 + uint32_t protruleaddr;
 + uint32_t protruleid;
 + uint32_t protruledata;

Remove protrule from local variables, as it is clear from context?

 +static void sdram_set_protection_config(uint64_t sdram_start, uint64_t 
 sdram_end)
 +{
 + sdram_prot_rule rule;
 + int rules;
 +
 + /* Start with accepting all SDRAM transaction */
 + writel(0x0, sdr_ctrl-protport_default);
 +
 + /* Clear all protection rules for warm boot case */
 +
 + rule.sdram_start = 0;

Kill last empty line. And actually... maybe memset?

 +static void set_sdr_addr_rw(void)
 +{
 + int cs = 

Re: [U-Boot] Commit d3cfcb3 breaks beagle_x15 build

2015-04-17 Thread Lokesh Vutla
Hi Albert,
On Thursday 16 April 2015 02:20 PM, Albert ARIBAUD wrote:
 Hello,
 
 Commit d3cfcb3 (ARM: DRA7: Enable clocks for USB OTGSS and USB PHY)
 breaks beagle_x15 build:
 
 Building current source for 1 boards (1 thread, 8 jobs per thread)
arm:  +   beagle_x15
 +board/ti/beagle_x15/board.c: In function 'board_usb_init':
 +board/ti/beagle_x15/board.c:393:1: error: 'const struct prcm_regs' has no 
 member named 'cm_l3init_usb_otg_ss_clkctrl'
 +make[2]: *** [board/ti/beagle_x15/board.o] Error 1
 +make[1]: *** [board/ti/beagle_x15] Error 2
 +make: *** [sub-make] Error 2
Thanks for pointing this. Kishon has sent a patch fixing this.
https://patchwork.ozlabs.org/patch/461734/

Thanks and regards,
Lokesh
 
 Cc:ing the committer and author.
 
 Kishon, can you look into this?
 
 Amicalement,
 

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


Re: [U-Boot] [PATCH 07/10] sunxi: Fix end of kernel memory alignment for A33

2015-04-17 Thread Mark Rutland
On Thu, Apr 16, 2015 at 08:12:31PM +0100, Hans de Goede wrote:
 Hi,
 
 On 16-04-15 19:35, Mark Rutland wrote:
  On Thu, Apr 16, 2015 at 08:32:03AM +0100, Hans de Goede wrote:
  Hi,
 
  On 15-04-15 21:57, Ian Campbell wrote:
  On Tue, 2015-04-14 at 18:06 +0200, Hans de Goede wrote:
  For unknown reasons the A33 needs the end of the memory we report to the
  kernel to be aligned to a multiple of 4 MiB.
 
  Do you really mean the A33 needs (as in the processor itself) or do
  you actually mean the A33 kernel port?
 
  If the latter than can't that be investigated/fixed instead of hacked
  here? That would be far more preferable.
 
  I mean the former, it seems that the SoC itself cannot handle dram
  ranges with different cache policies which are not aligned to 4 MiB,
  at least that is my WAG what is going on here.
 
  That sounds incredibly suspicious.
 
  What do you mean w.r.t. different cache policies -- what does that have
  to do with the end of DRAM?
 
 We carve out a framebuffer at the end of DRAM, and then report less
 DRAM then we actually have to the kernel. This framebuffer then gets
 picked up by the kernel through simplefb, which will map it with a different
 cache policy then the normal part of the DRAM has.

I see. Thanks for the clarification.

  What problem do you see?
 
 Depending on the framebuffer-size the kernel either boots or does not boot,
 when it does not boot it does nothing (I've a serial console) earlyprintk
 does not help, I was looking into setting up an early console (should be
 a matter of just putting in the right parameters) when I found out that if
 I modify the framebuffer size that fixes things.

Ok. So we don't know if the kernel is stuck somewhere or everything is
completely hosed, then?

I take it you can't get JTAG worknig via the SD card slot?

 After experimenting more it seems that keeping the last pixel of the
 framebuffer at the very end of DRAM is not a problem (so this does not seem
 to be a display engine problem), things start to work when I make the carve
 out at the end bigger.
 
 On the very similar A23 giving the kernel all of the DRAM except for the
 framebuffer (aligned to a multiple of 4k) works just fine.
 
 Sometimes I can get away with just making the carve-out bigger without
 aligning it to a multiple of 4 MiB, but an alignment to 4 MiB seems to
 always work independent of the framebuffer size.
 
  It would be worth reporting this on lakml.
 
 If you still think that after the above explanation I'll start a new thread
 on lakml with contents more targeted at kernel devs.

I think it would be worthwhile. This could be one instance of an issue
in the memory system that we might hit elsewhere. Even if we don't come
to another solution, it'll at least make it visible to others.

  I've been using an a23 dtb + generic multi-platform kernel for my testing
  (as said before the a33 really is almost the same design), and that boots
  fine without this alignment hack on an actual A23 device, so this is not
  a kernel limitation.
 
  Not necessarily. Is RAM at the same location on both SoCs? What about
  other devices and carevouts?
 
 Everything is the same on both SoCs except that one has 2 Cortex A7
 cores and the new one with the problem has 4 Cortex A7 cores, and a
 new dram controller / mbus subsystem to keep the 4 cores fed.
 
  It could be htat the stars happen to align and we're finally caught out
  by some dodgy maths.
 
 I don't think that that is the case here.

Yeah. The memory subsystem differences sound like the chief suspects.

Do we know if the A7s in the A23 and A33 are different revisions (and
which bits are set in their aux registers)? It could be that some
memory system features is enabled on one but not the other, or something
like that.

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


Re: [U-Boot] [PATCH] zynq: spi: Remove unnecessary error condition

2015-04-17 Thread Jagan Teki
On 15 April 2015 at 16:43, Michal Simek michal.si...@xilinx.com wrote:
 From: Siva Durga Prasad Paladugu siva.durga.palad...@xilinx.com

 Removed the unnecessary error check from spi_xfer
 as the bitlen zero is possible now to deassert the
 chip select for which no data is required to be transfered.

 Signed-off-by: Siva Durga Prasad Paladugu siva...@xilinx.com
 Signed-off-by: Michal Simek michal.si...@xilinx.com
 ---

  drivers/spi/zynq_spi.c | 3 ---
  1 file changed, 3 deletions(-)

 diff --git a/drivers/spi/zynq_spi.c b/drivers/spi/zynq_spi.c
 index 5da87591ceef..e9129da79d99 100644
 --- a/drivers/spi/zynq_spi.c
 +++ b/drivers/spi/zynq_spi.c
 @@ -227,9 +227,6 @@ int spi_xfer(struct spi_slave *slave, unsigned int 
 bitlen, const void *dout,
 debug(spi_xfer: bus:%i cs:%i bitlen:%i len:%i flags:%lx\n,
   slave-bus, slave-cs, bitlen, len, flags);

 -   if (bitlen == 0)
 -   return -1;
 -
 if (bitlen % 8) {
 debug(spi_xfer: Non byte aligned SPI transfer\n);
 return -1;
 --
 2.3.5


Applied to  u-boot-spi/master

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


Re: [U-Boot] [PATCH] sf: Correct the macros as per new array fast read command

2015-04-17 Thread Jagan Teki
On 11 March 2015 at 14:52, Siva Durga Prasad Paladugu
siva.durga.palad...@xilinx.com wrote:
 Correct the macros as per insertion of array fast read
 command CMD_READ_ARRAY_FAST in spi_read_cmds_array in file
 sf_probe.c

 Signed-off-by: Siva Durga Prasad Paladugu siva...@xilinx.com
 ---
  include/spi.h | 11 ++-
  1 file changed, 6 insertions(+), 5 deletions(-)

 diff --git a/include/spi.h b/include/spi.h
 index c58e453..7829063 100644
 --- a/include/spi.h
 +++ b/include/spi.h
 @@ -38,11 +38,12 @@

  /* SPI RX operation modes */
  #define SPI_OPM_RX_AS  (1  0)
 -#define SPI_OPM_RX_DOUT(1  1)
 -#define SPI_OPM_RX_DIO (1  2)
 -#define SPI_OPM_RX_QOF (1  3)
 -#define SPI_OPM_RX_QIOF(1  4)
 -#define SPI_OPM_RX_EXTN(SPI_OPM_RX_AS | SPI_OPM_RX_DOUT | \
 +#define SPI_OPM_RX_AF  (1  1)
 +#define SPI_OPM_RX_DOUT(1  2)
 +#define SPI_OPM_RX_DIO (1  3)
 +#define SPI_OPM_RX_QOF (1  4)
 +#define SPI_OPM_RX_QIOF(1  5)
 +#define SPI_OPM_RX_EXTN(SPI_OPM_RX_AS | SPI_OPM_RX_AF | 
 SPI_OPM_RX_DOUT | \
 SPI_OPM_RX_DIO | SPI_OPM_RX_QOF | \
 SPI_OPM_RX_QIOF)


Applied to  u-boot-spi/master

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


Re: [U-Boot] [PATCH] sf: Poll both the read status and flag status

2015-04-17 Thread Jagan Teki
On 10 April 2015 at 17:43, Jagan Teki jagannadh.t...@gmail.com wrote:
 Hi Siva Durga Prasad,

 On 11 March 2015 at 14:47, Siva Durga Prasad Paladugu
 siva.durga.palad...@xilinx.com wrote:
 Poll both the Read status and Flag status registers
 for sucessful erase and program operations for the
 Micron devices with E_FSR flag set in params table.

 There is hw DIE transition from 256 to 512 and 1G, Did you test these?


 Signed-off-by: Siva Durga Prasad Paladugu siva...@xilinx.com
 ---
  drivers/mtd/spi/sf_ops.c | 32 +---
  1 file changed, 25 insertions(+), 7 deletions(-)

 diff --git a/drivers/mtd/spi/sf_ops.c b/drivers/mtd/spi/sf_ops.c
 index 34bc54e..38592f5 100644
 --- a/drivers/mtd/spi/sf_ops.c
 +++ b/drivers/mtd/spi/sf_ops.c
 @@ -154,21 +154,17 @@ static void spi_flash_dual_flash(struct spi_flash 
 *flash, u32 *addr)
  }
  #endif

 -int spi_flash_cmd_wait_ready(struct spi_flash *flash, unsigned long timeout)
 +static int spi_flash_poll_status(struct spi_slave *spi, unsigned long 
 timeout,
 +u8 cmd, u8 poll_bit)
  {
 -   struct spi_slave *spi = flash-spi;
 unsigned long timebase;
 unsigned long flags = SPI_XFER_BEGIN;
 int ret;
 u8 status;
 u8 check_status = 0x0;
 -   u8 poll_bit = STATUS_WIP;
 -   u8 cmd = flash-poll_cmd;

 -   if (cmd == CMD_FLAG_STATUS) {
 -   poll_bit = STATUS_PEC;
 +   if (cmd == CMD_FLAG_STATUS)
 check_status = poll_bit;
 -   }

  #ifdef CONFIG_SF_DUAL_FLASH
 if (spi-flags  SPI_XFER_U_PAGE)
 @@ -204,6 +200,28 @@ int spi_flash_cmd_wait_ready(struct spi_flash *flash, 
 unsigned long timeout)
 return -1;
  }

 +int spi_flash_cmd_wait_ready(struct spi_flash *flash, unsigned long timeout)
 +{
 +   struct spi_slave *spi = flash-spi;
 +   int ret;
 +   u8 poll_bit = STATUS_WIP;
 +   u8 cmd = CMD_READ_STATUS;
 +
 +   ret = spi_flash_poll_status(spi, timeout, cmd, poll_bit);
 +   if (ret  0)
 +   return ret;
 +
 +   if (flash-poll_cmd == CMD_FLAG_STATUS) {
 +   poll_bit = STATUS_PEC;
 +   cmd = CMD_FLAG_STATUS;
 +   ret = spi_flash_poll_status(spi, timeout, cmd, poll_bit);
 +   if (ret  0)
 +   return ret;
 +   }
 +
 +   return 0;
 +}
 +
  int spi_flash_write_common(struct spi_flash *flash, const u8 *cmd,
 size_t cmd_len, const void *buf, size_t buf_len)
  {
 --

Applied to  u-boot-spi/master

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


Re: [U-Boot] Compile minnowboard max error

2015-04-17 Thread Simon Glass
Hi,

On 13 April 2015 at 22:39, li yuqian liyuqia...@outlook.com wrote:
 Hi Simon

 Can you please put your response below my reply? This thread is all
 over the place

 This looks right to me. Can you post the entire build output
 somewhere, built with V=1 so I can see everything? There must be
 something different.

 Regards,
 Simon


 Thank you, here is output i enabled the ifdtool.c debug

 make -f ./scripts/Makefile.build obj=lib/rsa

   gcc -Wp,-MD,lib/.display_options.o.d  -nostdinc -isystem
 /usr/lib/gcc/i686-linux-gnu/4.9/include -Iinclude  -I./arch/x86/include
 -include ./include/linux/kconfig.h -D__KERNEL__ -D__UBOOT__
 -DCONFIG_SYS_TEXT_BASE=0xfff0 -Wall -Wstrict-prototypes
 -Wno-format-security -fno-builtin -ffreestanding -Os -fno-stack-protector -g
 -fstack-usage -Wno-format-nonliteral -Werror=date-time -fno-strict-aliasing
 -mregparm=3 -fomit-frame-pointer -fno-toplevel-reorder
 -mpreferred-stack-boundary=2 -fno-dwarf2-cfi-asm -march=i386 -m32 -D__I386__
 -Werror -ffunction-sections -fvisibility=hidden -pipe
 -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(display_options)
 -DKBUILD_MODNAME=KBUILD_STR(display_options) -c -o lib/display_options.o
 lib/display_options.c

ld.bfd   --emit-relocs -Bsymbolic -Bsymbolic-functions -m elf_i386   -r
 -o lib/built-in.o lib/rsa/built-in.o lib/lzo/built-in.o
 lib/libfdt/built-in.o lib/crc7.o lib/crc8.o lib/crc16.o lib/fdtdec_common.o
 lib/fdtdec.o lib/initcall.o lib/lmb.o lib/ldiv.o lib/md5.o lib/net_utils.o
 lib/physmem.o lib/qsort.o lib/sha1.o lib/sha256.o lib/strmhz.o lib/tpm.o
 lib/list_sort.o lib/hashtable.o lib/errno.o lib/display_options.o
 lib/crc32.o lib/ctype.o lib/div64.o lib/hang.o lib/linux_compat.o
 lib/linux_string.o lib/string.o lib/time.o lib/uuid.o lib/vsprintf.o

 make -f ./scripts/Makefile.build obj=net

 make -f ./scripts/Makefile.build obj=test

 make -f ./scripts/Makefile.build obj=test/dm

 make -f ./scripts/Makefile.build obj=examples

 make -f ./scripts/Makefile.build obj=examples/standalone

   ld.bfd   --emit-relocs -Bsymbolic -Bsymbolic-functions -m elf_i386
 --gc-sections -pie --wrap=__divdi3 --wrap=__udivdi3 --wrap=__moddi3
 --wrap=__umoddi3 -Bstatic -Ttext 0xfff0 -o u-boot -T u-boot.lds
 arch/x86/cpu/start.o --start-group  arch/x86/cpu/built-in.o
 arch/x86/lib/built-in.o  board/intel/minnowmax/built-in.o  common/built-in.o
 disk/built-in.o  drivers/built-in.o  drivers/dma/built-in.o
 drivers/gpio/built-in.o  drivers/i2c/built-in.o  drivers/mmc/built-in.o
 drivers/mtd/built-in.o  drivers/mtd/onenand/built-in.o
 drivers/mtd/spi/built-in.o  drivers/net/built-in.o
 drivers/net/phy/built-in.o  drivers/pci/built-in.o  drivers/power/built-in.o
 drivers/power/battery/built-in.o  drivers/power/fuel_gauge/built-in.o
 drivers/power/mfd/built-in.o  drivers/power/pmic/built-in.o
 drivers/serial/built-in.o  drivers/spi/built-in.o
 drivers/usb/eth/built-in.o  drivers/usb/gadget/built-in.o
 drivers/usb/host/built-in.o  drivers/usb/musb-new/built-in.o
 drivers/usb/musb/built-in.o  drivers/usb/phy/built-in.o
 drivers/usb/ulpi/built-in.o  fs/built-in.o  lib/built-in.o  net/built-in.o
 test/built-in.o  test/dm/built-in.o --end-group arch/x86/lib/lib.a -Map
 u-boot.map

   objcopy  --gap-fill=0xff -O srec u-boot u-boot.srec

   objcopy  --gap-fill=0xff -O binary -R .start16 -R .resetvec u-boot
 u-boot.bin

 make -f ./scripts/Makefile.build obj=dts dtbs

 make -f ./scripts/Makefile.build obj=arch/x86/dts dtbs

 test -e arch/x86/dts/minnowmax.dtb || ( \

 echo 2; \

 echo 2 Device Tree Source is not correctly specified.; \

 echo 2 Please define 'CONFIG_DEFAULT_DEVICE_TREE'; \

 echo 2 or build with 'DEVICE_TREE=device_tree' argument; \

 echo 2; \

 /bin/false)

   cat u-boot.bin dts/dt.dtb  u-boot-dtb.bin

   objcopy  --gap-fill=0xff -O binary -j .start16 -j .resetvec u-boot
 u-boot-x86-16bit.bin

   ./tools/ifdtool -c -r 0x80 u-boot.tmp; ./tools/ifdtool -D
 ./board/intel/minnowmax/descriptor.bin -i ME:./board/intel/minnowmax/me.bin
 u-boot.tmp; ./tools/ifdtool -f 0:./u-boot.dtb -m 0xfff016d4 -U
 0xfff0:./u-boot.bin -w 0xf800:./u-boot-x86-16bit.bin -w
 0xfffc:./board/intel/minnowmax/fsp.bin -w
 0xfff9:./board/intel/minnowmax/vga.bin u-boot.tmp; mv u-boot.tmp
 u-boot.rom

 ROM size 8388608

 File u-boot.tmp is 0 bytes

 ROM size changed to 8388608 bytes

 File u-boot.tmp is 8388608 bytes

 File ./board/intel/minnowmax/descriptor.bin is 4096 bytes

 Writing ./board/intel/minnowmax/descriptor.bin to offset 0

 Found Flash Descriptor signature at 0x0010

 File ./board/intel/minnowmax/me.bin is 5238784 bytes

 Adding ./board/intel/minnowmax/me.bin as the Intel ME section

 File u-boot.tmp is 8388608 bytes

 File ./u-boot.bin is 369640 bytes

 Writing ./u-boot.bin to offset 0x807f

 Output file is too small. (8388608  -2138725401) 807f - 5a3e8

 Makefile:1004: recipe for target 'u-boot.rom' failed

 make: *** [u-boot.rom] Error 1

 root@ubuntu:/usr/src/uboot/u-boot#




I just tried the equivalent on 

Re: [U-Boot] [PATCH v6 00/15] Add PSCI support for Jetson TK1/Tegra124 + CNTFRQ fix

2015-04-17 Thread Stephen Warren

On 04/17/2015 08:20 AM, Jan Kiszka wrote:

On 2015-04-17 16:12, Stephen Warren wrote:

On 04/17/2015 08:02 AM, Jan Kiszka wrote:

On 2015-04-17 15:57, Stephen Warren wrote:

On 04/17/2015 12:47 AM, Jan Kiszka wrote:

On 2015-04-14 16:30, Ian Campbell wrote:

On Tue, 2015-04-14 at 16:12 +0200, Jan Kiszka wrote:

On 2015-04-14 16:06, Stephen Warren wrote:

On 04/14/2015 07:46 AM, Tom Rini wrote:

On Mon, Apr 13, 2015 at 06:48:05AM +0200, Jan Kiszka wrote:


Changes in v6:
 - rebased over master
 - included Thierry's SMMU enabling patch
 - moved activation patch at the end so that it can be held
back

This version can also be found at
https://github.com/siemens/u-boot/tree/jetson-tk1-v6.


So what level of coordination do we need on applying this series
so that
kernels (both old and new) can continue to function?  And perhaps
README
updates or similar?  Thanks!


Hopefully this series doesn't change anything by default, and simply
allows people to turn on support for booting kernels in non-secure
mode
if they want to? If so, there shouldn't be any co-ordination
required.
If it changes the default behaviour, co-ordination is probably
required,
and that'd be a bad thing.


Sorry, forgot to mention: I can't flip the default behaviour to leave
virtualization support off only for the TK1. That's a generic
default.


Would enabling it in the compile but adding bootm_boot_mode=sec
to the
default environment (so it isn't used by default) be considered
sufficiently backwards compatible?


This turned out to not work as expected: booting in secure mode seems
to prevent that Linux can bring up CPUs 1-3. Not sure if this is to be
expected or a bug, but I will now take a different route:


That was the whole point of the environment variable suggestion; the
environment variable would default to off so nobody got new behaviour,
but anyone who wanted to boot in secure mode could simply set the
environment variable and get it. That way, nobody who doesn't want the
feature needs to co-ordinate U-Boot and kernel updates. Why doesn't that
work?


Because it breaks SMP on Linux, namely the boot of secondary cores.
Don't ask me why, I didn't debug the details. But you can probably
reproduce by specifying bootm_boot_mode=sec with current U-boot and
recent upstream kernels.


I suspect the environment variable isn't working, and Linux is still
being booted in non-secure mode. That would be a bug in U-Boot.


Yes, might be. Linux reports being started (with that single CPU) in SVC
mode. I'll recheck if it is a regression of my series.

Anyway, even if it worked, I think the cleaner way is flipping defaults
at the config root level (virt support) as long as things are not
working out of the box with Linux. That's what my other patch is doing
now. Any concerns regarding it?


Yes.

This should be runtime configurable so that there's no need for a user 
to co-ordinate U-Boot and kernel updates. This also allows users to 
easily test the kernel in secure and NS mode without having to rebuild a 
bootloader.

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


[U-Boot] [PATCH v4 7/7] colibri_vf: Enable USB support for Colibri Vybrid

2015-04-17 Thread Sanchayan Maity
Enable USB support on Toradex Colibri Vybrid Modules.

Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
---
 board/toradex/colibri_vf/colibri_vf.c | 24 +++
 include/configs/colibri_vf.h  | 37 +++
 2 files changed, 61 insertions(+)

diff --git a/board/toradex/colibri_vf/colibri_vf.c 
b/board/toradex/colibri_vf/colibri_vf.c
index e7bc6c1..31ebb19 100644
--- a/board/toradex/colibri_vf/colibri_vf.c
+++ b/board/toradex/colibri_vf/colibri_vf.c
@@ -216,6 +216,14 @@ static void clock_init(void)
clrsetbits_le32(ccm-ccgr10, CCM_REG_CTRL_MASK,
CCM_CCGR10_NFC_CTRL_MASK);
 
+#ifdef CONFIG_CI_UDC
+   setbits_le32(ccm-ccgr1, CCM_CCGR1_USBC0_CTRL_MASK);
+#endif
+
+#ifdef CONFIG_USB_EHCI
+   setbits_le32(ccm-ccgr7, CCM_CCGR7_USBC1_CTRL_MASK);
+#endif
+
clrsetbits_le32(anadig-pll5_ctrl, ANADIG_PLL5_CTRL_BYPASS |
ANADIG_PLL5_CTRL_POWERDOWN, ANADIG_PLL5_CTRL_ENABLE |
ANADIG_PLL5_CTRL_DIV_SELECT);
@@ -359,3 +367,19 @@ int checkboard(void)
 
return 0;
 }
+
+int g_dnl_bind_fixup(struct usb_device_descriptor *dev, const char *name)
+{
+   unsigned short usb_pid;
+
+   put_unaligned(CONFIG_TRDX_VID, dev-idVendor);
+
+   if (is_colibri_vf61())
+   usb_pid = CONFIG_TRDX_PID_COLIBRI_VF61IT;
+   else
+   usb_pid = CONFIG_TRDX_PID_COLIBRI_VF50IT;
+
+   put_unaligned(usb_pid, dev-idProduct);
+
+   return 0;
+}
diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h
index 84ffbe8..414600a 100644
--- a/include/configs/colibri_vf.h
+++ b/include/configs/colibri_vf.h
@@ -146,6 +146,8 @@
 
 #define CONFIG_BOOTCOMMAND run ubiboot; run sdboot; run nfsboot
 
+#define DFU_ALT_NAND_INFO vf-bcb part 0,1;u-boot part 0,2;ubi part 0,4
+
 #define CONFIG_EXTRA_ENV_SETTINGS \
kernel_addr_r=0x8200\0 \
fdt_addr_r=0x8400\0 \
@@ -165,6 +167,7 @@
source ${loadaddr}\0 \
setupdate=run setsdupdate || run setusbupdate\0 \
mtdparts= MTDPARTS_DEFAULT \0 \
+   dfu_alt_info= DFU_ALT_NAND_INFO \0 \
SD_BOOTCMD \
NFS_BOOTCMD \
UBI_BOOTCMD
@@ -231,4 +234,38 @@
 
 #define CONFIG_SYS_CACHELINE_SIZE 32
 
+/* USB Host Support */
+#define CONFIG_CMD_USB
+#define CONFIG_USB_EHCI
+#define CONFIG_USB_EHCI_VF
+#define CONFIG_USB_MAX_CONTROLLER_COUNT 2
+#define CONFIG_EHCI_HCD_INIT_AFTER_RESET
+
+/* USB Client Support */
+#define CONFIG_USB_GADGET
+#define CONFIG_CI_UDC
+#define CONFIG_USB_GADGET_DUALSPEED
+#define CONFIG_USB_GADGET_VBUS_DRAW  2
+#define CONFIG_TRDX_VID  0x1B67
+#define CONFIG_TRDX_PID_COLIBRI_VF50 0x0016
+#define CONFIG_TRDX_PID_COLIBRI_VF61 0x0017
+#define CONFIG_TRDX_PID_COLIBRI_VF61IT   0x0018
+#define CONFIG_TRDX_PID_COLIBRI_VF50IT   0x0019
+#define CONFIG_G_DNL_MANUFACTURERToradex
+#define CONFIG_G_DNL_VENDOR_NUM  CONFIG_TRDX_VID
+#define CONFIG_G_DNL_PRODUCT_NUM CONFIG_TRDX_PID_COLIBRI_VF50
+
+/* USB DFU */
+#define CONFIG_USBDOWNLOAD_GADGET
+#define CONFIG_CMD_DFU
+#define CONFIG_DFU_FUNCTION
+#define CONFIG_DFU_NAND
+#define CONFIG_DFU_MMC
+#define CONFIG_SYS_DFU_DATA_BUF_SIZE (1024 * 1024)
+
+/* USB Storage */
+#define CONFIG_USB_STORAGE
+#define CONFIG_USB_GADGET_MASS_STORAGE
+#define CONFIG_CMD_USB_MASS_STORAGE
+
 #endif /* __CONFIG_H */
-- 
2.3.5

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


Re: [U-Boot] [PATCH v6 00/15] Add PSCI support for Jetson TK1/Tegra124 + CNTFRQ fix

2015-04-17 Thread Jan Kiszka
On 2015-04-17 15:57, Stephen Warren wrote:
 On 04/17/2015 12:47 AM, Jan Kiszka wrote:
 On 2015-04-14 16:30, Ian Campbell wrote:
 On Tue, 2015-04-14 at 16:12 +0200, Jan Kiszka wrote:
 On 2015-04-14 16:06, Stephen Warren wrote:
 On 04/14/2015 07:46 AM, Tom Rini wrote:
 On Mon, Apr 13, 2015 at 06:48:05AM +0200, Jan Kiszka wrote:

 Changes in v6:
- rebased over master
- included Thierry's SMMU enabling patch
- moved activation patch at the end so that it can be held back

 This version can also be found at
 https://github.com/siemens/u-boot/tree/jetson-tk1-v6.

 So what level of coordination do we need on applying this series
 so that
 kernels (both old and new) can continue to function?  And perhaps
 README
 updates or similar?  Thanks!

 Hopefully this series doesn't change anything by default, and simply
 allows people to turn on support for booting kernels in non-secure
 mode
 if they want to? If so, there shouldn't be any co-ordination required.
 If it changes the default behaviour, co-ordination is probably
 required,
 and that'd be a bad thing.

 Sorry, forgot to mention: I can't flip the default behaviour to leave
 virtualization support off only for the TK1. That's a generic default.

 Would enabling it in the compile but adding bootm_boot_mode=sec to the
 default environment (so it isn't used by default) be considered
 sufficiently backwards compatible?

 This turned out to not work as expected: booting in secure mode seems
 to prevent that Linux can bring up CPUs 1-3. Not sure if this is to be
 expected or a bug, but I will now take a different route:
 
 That was the whole point of the environment variable suggestion; the
 environment variable would default to off so nobody got new behaviour,
 but anyone who wanted to boot in secure mode could simply set the
 environment variable and get it. That way, nobody who doesn't want the
 feature needs to co-ordinate U-Boot and kernel updates. Why doesn't that
 work?

Because it breaks SMP on Linux, namely the boot of secondary cores.
Don't ask me why, I didn't debug the details. But you can probably
reproduce by specifying bootm_boot_mode=sec with current U-boot and
recent upstream kernels.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v6 00/15] Add PSCI support for Jetson TK1/Tegra124 + CNTFRQ fix

2015-04-17 Thread Ian Campbell
On Fri, 2015-04-17 at 07:57 -0600, Stephen Warren wrote:
 On 04/17/2015 12:47 AM, Jan Kiszka wrote:
  On 2015-04-14 16:30, Ian Campbell wrote:
  Would enabling it in the compile but adding bootm_boot_mode=sec to the
  default environment (so it isn't used by default) be considered
  sufficiently backwards compatible?
 
  This turned out to not work as expected: booting in secure mode seems
  to prevent that Linux can bring up CPUs 1-3. Not sure if this is to be
  expected or a bug, but I will now take a different route:
 
 That was the whole point of the environment variable suggestion; the 
 environment variable would default to off so nobody got new behaviour, 
 but anyone who wanted to boot in secure mode could simply set the 
 environment variable and get it. That way, nobody who doesn't want the 
 feature needs to co-ordinate U-Boot and kernel updates. Why doesn't that 
 work?

Right, if this doesn't work then it is certainly a bug somewhere on the
u-boot side.

I fixed one such issue a while back (ARM: bootm: do not add PSCI to fdt
when booting in secure mode.) but that's ancient history, but I know
that at that time it was working for me (I'm reasonably sure that was on
Tegra with my earlier PSCI patches)

Ian.



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


Re: [U-Boot] [PATCH v6 00/15] Add PSCI support for Jetson TK1/Tegra124 + CNTFRQ fix

2015-04-17 Thread Stephen Warren

On 04/17/2015 12:47 AM, Jan Kiszka wrote:

On 2015-04-14 16:30, Ian Campbell wrote:

On Tue, 2015-04-14 at 16:12 +0200, Jan Kiszka wrote:

On 2015-04-14 16:06, Stephen Warren wrote:

On 04/14/2015 07:46 AM, Tom Rini wrote:

On Mon, Apr 13, 2015 at 06:48:05AM +0200, Jan Kiszka wrote:


Changes in v6:
   - rebased over master
   - included Thierry's SMMU enabling patch
   - moved activation patch at the end so that it can be held back

This version can also be found at
https://github.com/siemens/u-boot/tree/jetson-tk1-v6.


So what level of coordination do we need on applying this series so that
kernels (both old and new) can continue to function?  And perhaps README
updates or similar?  Thanks!


Hopefully this series doesn't change anything by default, and simply
allows people to turn on support for booting kernels in non-secure mode
if they want to? If so, there shouldn't be any co-ordination required.
If it changes the default behaviour, co-ordination is probably required,
and that'd be a bad thing.


Sorry, forgot to mention: I can't flip the default behaviour to leave
virtualization support off only for the TK1. That's a generic default.


Would enabling it in the compile but adding bootm_boot_mode=sec to the
default environment (so it isn't used by default) be considered
sufficiently backwards compatible?


This turned out to not work as expected: booting in secure mode seems
to prevent that Linux can bring up CPUs 1-3. Not sure if this is to be
expected or a bug, but I will now take a different route:


That was the whole point of the environment variable suggestion; the 
environment variable would default to off so nobody got new behaviour, 
but anyone who wanted to boot in secure mode could simply set the 
environment variable and get it. That way, nobody who doesn't want the 
feature needs to co-ordinate U-Boot and kernel updates. Why doesn't that 
work?



diff --git a/arch/arm/cpu/armv7/Kconfig b/arch/arm/cpu/armv7/Kconfig
index 61e7c82..e5d4dcc 100644
--- a/arch/arm/cpu/armv7/Kconfig
+++ b/arch/arm/cpu/armv7/Kconfig
@@ -27,7 +27,7 @@ config ARMV7_BOOT_SEC_DEFAULT
  config ARMV7_VIRT
boolean Enable support for hardware virtualization if EXPERT
depends on CPU_V7_HAS_VIRT  ARMV7_NONSEC
-   default y
+   default y if !TEGRA
---help---
Say Y here to boot in hypervisor (HYP) mode when booting non-secure.


A patch to be inserted before the last one (and to be reverted once
Linux is fixed) will follow.

Jan



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


Re: [U-Boot] [PATCH 08/10] sunxi: Add basic A33 basic support

2015-04-17 Thread Ian Campbell
On Thu, 2015-04-16 at 09:35 +0200, Hans de Goede wrote:
 Hi,
 
 On 15-04-15 22:00, Ian Campbell wrote:
  On Tue, 2015-04-14 at 18:06 +0200, Hans de Goede wrote:
  From: Vishnu Patekar vishnupatekar0...@gmail.com
 
  A quick comment on what basic here means, i.e. prcm, rsb, clocks as
  per sun6i, etc would be good.
 
 Actually the Basic is misleading here, since this adds full support,
 usb controller, display output, etc. everything works, so I'll drop the
 Basic from the Subject and add a proper commit message.
 
 
  Signed-off-by: Vishnu Patekar vishnupatekar0...@gmail.com
  Signed-off-by: Hans de Goede hdego...@redhat.com
 
  Did you make non-trivial mods or is this S-o-b just a passing it along
  one? (In the latter case I won't bother to review deeply myself unless
  you want me to)
 
 I made non-trivial mods, both the display driver and usb driver changes
 are all from my hand.
 
  @@ -103,6 +107,10 @@ static void usb_phy_write(struct sunxi_usbc_hcd 
  *sunxi_usbc, int addr,
 int j = 0, usbc_bit = 0;
 void *dest = sunxi_usbc_get_io_base(0) + SUNXI_USB_CSR;
 
  +#ifdef CONFIG_MACH_SUN8I_A33
  +  writel(0, dest);
  +#endif
 
  Some undocumented/commented magic?
 
 Pretty much, I took this from the Allwinner sources which have a comment
 along the lines of this needs to be explicitly initialized to 0 on A33,
 I can add such a comment if you want me to.

I think a comment would be good, lest someone in the future think it was
put there for as known reason.

Ian.


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


Re: [U-Boot] [PATCH 03/10] sunxi: Introduce a hidden ARCH_SUN6I Kconfig bool

2015-04-17 Thread Ian Campbell
On Thu, 2015-04-16 at 09:23 +0200, Hans de Goede wrote:
 Hi,
 
 On 15-04-15 21:47, Ian Campbell wrote:
  On Wed, 2015-04-15 at 10:45 +0200, Michal Suchanek wrote:
  It is not obvious which MACH_SUN?I are ARCH_SUN6I derived. So if you
  can come up with a descriptive name for 'a number of things in common,
  such as having separate ahb reset registers in the ccm' that's fine
  otherwise this obfuscates the code, not clarifies.
 
  I don't particularly object to the patch but this occurred to me too. I
  suppose the rule is first sunxi to look this way.
 
  How about we call groups of similar SoCs a generation, i.e.
  ARCH_SUNXI_GEN2 is what is called ARCH_SUN6I here, meaning GEN1 would be
  SUN4/5/7I.
 
 I like the GEN idea, but not the numbering as it is a bit too arbitrary
 how about: ARCH_SUNXI_GEN_SUN6I or (better I think) just SUNXI_GEN_SUN6I ?

Works for me (I agree the second is better too).

 
 I know that does not solve the fact that MACH_SUN7I is SUNXI_GEN_SUN4I
 but we cannot fix that, at least this way it will be explicit.
 
 Regards,
 
 Hans
 


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


Re: [U-Boot] [PATCH 1/2] armv8: caches: Disable dcache after flush

2015-04-17 Thread Siva Durga Prasad Paladugu
Hi Mark,

 -Original Message-
 From: Mark Rutland [mailto:mark.rutl...@arm.com]
 Sent: Friday, April 17, 2015 3:36 PM
 To: Siva Durga Prasad Paladugu
 Cc: Michal Simek; u-boot@lists.denx.de; Tom Rini; Varun Sethi; Arnab Basu;
 York Sun
 Subject: Re: [U-Boot] [PATCH 1/2] armv8: caches: Disable dcache after flush

Now in the flush_dcache_all we are invoking the actual asm call to
flush dcache which may wipeout the stored return value in stack
with cahe contents(main memory). Hence the return from the
flush_dcahe_all will fail.
   
To confirm this I modified the dcache_disable in the below way and
it
   worked fine.
1. Disable the dcache.
2. Now I called the __asm_flush_dcache_all(); and then
flush_l3_cache();
   instead of calling the flush_dcache_all().
  
   That also is unsafe; implicit (e.g. stack) accesses at any point
   after SCTLR.C is cleared and before flush_l3_cache() has completed
   may see stale data, or get overwritten by stale data.
  
   Set/Way ops only flush the CPU-local caches, so you only guarantee
   that these are clean (and potentially dirty cache lines for the
   stack could be sat in
   L3 and written back at any time). So your flush_l3_cache() function
   might not work.
  
   Per ARMv8 the L3 _must_ respect maintenance by VA, so after
   disabling the MMU you can flush the memory region corresponding to
   your stack (and any other data you need) by VA to the PoC before
   executing flush_l3_cache(), in addition to the Set/Way ops used to empty
 the CPU-local caches.
  Thanks for explanation.
  So in that case, the flushing of the required stack or any other data
  which needs to be flushed should be part of board specific. Am I
  correct?

 It could be done in generic code, assuming we know the bounds of memory
 which will be used, because maintenance by VA should always work.

 Do we know which memory U-Boot might use (e.g. does it all fall within some
 static carveout?), or can it dynamically allocate from anywhere in memory?

  If yes, then this disable_dcache() should contain a asm call to a
  routine() (which might be board specific) after disabling the cache to
  flush the required data and then flush_dcache_all() followed by flush
  L3 cache..

 You could probably get away with:

 * Load the memory bounds that we need to flush into some registers, or
   flush some datastructure containing these to memory.
 * In assembly:
   - disable the MMU.
   - flush the PA range(s) we need to use to be able to use C safely.
   - flush by Set/Way to empry the CPU-local caches
 * Implementation-specific L3 flushing for anything else.

 If we only map a small amount of memory, we could simply flush this by VA
 (knowing that this will drain the CPU and L3 caches, without any special
 maintenance).
I just looked at one of the old patch from York in the link below. Can you look 
at this.
http://lists.denx.de/pipermail/u-boot/2015-January/200514.html

Regards,
DP

 Mark.


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

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


[U-Boot] [PATCH v1] dm: sf: Add Atmel DataFlash spi flash driver

2015-04-17 Thread Haikun Wang
Atmel DataFlash chips have commands different from common spi
flash commands.
Atmel DataFlash also have special page-size.
This driver add support for accessing Atmel DataFlash.
It is based on the Driver Model.

Signed-off-by: Haikun Wang haikun.w...@freescale.com
---
 drivers/mtd/spi/Makefile|   1 +
 drivers/mtd/spi/spi_dataflash.c | 674 
 2 files changed, 675 insertions(+)
 create mode 100644 drivers/mtd/spi/spi_dataflash.c

diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
index c61b784..51de583 100644
--- a/drivers/mtd/spi/Makefile
+++ b/drivers/mtd/spi/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_SPL_SPI_LOAD)+= spi_spl_load.o
 obj-$(CONFIG_SPL_SPI_BOOT) += fsl_espi_spl.o
 endif
 
+obj-$(CONFIG_DM_SPI_DATAFLASH) += spi_dataflash.o
 #ifndef CONFIG_DM_SPI
 obj-$(CONFIG_SPI_FLASH) += sf_probe.o
 #endif
diff --git a/drivers/mtd/spi/spi_dataflash.c b/drivers/mtd/spi/spi_dataflash.c
new file mode 100644
index 000..0b92964
--- /dev/null
+++ b/drivers/mtd/spi/spi_dataflash.c
@@ -0,0 +1,674 @@
+/*
+ *
+ * Atmel DataFlash probing
+ *
+ * Copyright (C) 2004-2009, 2015 Freescale Semiconductor, Inc.
+ * Haikun Wang (haikun.w...@freescale.com)
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+*/
+#include common.h
+#include dm.h
+#include errno.h
+#include fdtdec.h
+#include malloc.h
+#include spi.h
+#include spi_flash.h
+#include asm/io.h
+#include div64.h
+#include linux/err.h
+#include linux/math64.h
+
+#include sf_internal.h
+
+/*
+ * DataFlash is a kind of SPI flash.  Most AT45 chips have two buffers in
+ * each chip, which may be used for double buffered I/O; but this driver
+ * doesn't (yet) use these for any kind of i/o overlap or prefetching.
+ *
+ * Sometimes DataFlash is packaged in MMC-format cards, although the
+ * MMC stack can't (yet?) distinguish between MMC and DataFlash
+ * protocols during enumeration.
+ */
+
+/* reads can bypass the buffers */
+#define OP_READ_CONTINUOUS 0xE8
+#define OP_READ_PAGE   0xD2
+
+/* group B requests can run even while status reports busy */
+#define OP_READ_STATUS 0xD7/* group B */
+
+/* move data between host and buffer */
+#define OP_READ_BUFFER10xD4/* group B */
+#define OP_READ_BUFFER20xD6/* group B */
+#define OP_WRITE_BUFFER1   0x84/* group B */
+#define OP_WRITE_BUFFER2   0x87/* group B */
+
+/* erasing flash */
+#define OP_ERASE_PAGE  0x81
+#define OP_ERASE_BLOCK 0x50
+
+/* move data between buffer and flash */
+#define OP_TRANSFER_BUF1   0x53
+#define OP_TRANSFER_BUF2   0x55
+#define OP_MREAD_BUFFER1   0xD4
+#define OP_MREAD_BUFFER2   0xD6
+#define OP_MWERASE_BUFFER1 0x83
+#define OP_MWERASE_BUFFER2 0x86
+#define OP_MWRITE_BUFFER1  0x88/* sector must be pre-erased */
+#define OP_MWRITE_BUFFER2  0x89/* sector must be pre-erased */
+
+/* write to buffer, then write-erase to flash */
+#define OP_PROGRAM_VIA_BUF10x82
+#define OP_PROGRAM_VIA_BUF20x85
+
+/* compare buffer to flash */
+#define OP_COMPARE_BUF10x60
+#define OP_COMPARE_BUF20x61
+
+/* read flash to buffer, then write-erase to flash */
+#define OP_REWRITE_VIA_BUF10x58
+#define OP_REWRITE_VIA_BUF20x59
+
+/* newer chips report JEDEC manufacturer and device IDs; chip
+ * serial number and OTP bits; and per-sector writeprotect.
+ */
+#define OP_READ_ID 0x9F
+#define OP_READ_SECURITY   0x77
+#define OP_WRITE_SECURITY_REVC 0x9A
+#define OP_WRITE_SECURITY  0x9B/* revision D */
+
+
+struct dataflash {
+   uint8_t command[16];
+   unsigned short  page_offset;/* offset in flash address */
+   struct spi_flash*flash;
+};
+
+/* . */
+
+/*
+ * Return the status of the DataFlash device.
+ */
+static inline int dataflash_status(struct spi_slave *spi)
+{
+   int ret;
+   char status;
+   /* NOTE:  at45db321c over 25 MHz wants to write
+* a dummy byte after the opcode...
+*/
+   ret = spi_flash_cmd(spi, OP_READ_STATUS, status, 1);
+   return ret ? -EIO : status;
+}
+
+/*
+ * Poll the DataFlash device until it is READY.
+ * This usually takes 5-20 msec or so; more for sector erase.
+ * ready: return  0
+ */
+static int dataflash_waitready(struct spi_slave *spi)
+{
+   int status;
+   int timeout = 1000;
+
+   for (; timeout-- ;) {
+   status = dataflash_status(spi);
+   if (status  0)
+   status = 0;
+
+   if (status  (1  7))  /* RDY/nBSY */
+   return status;
+
+   mdelay(3);
+   }
+
+   return -ETIME;
+}
+
+/* . */
+
+/*
+ * Erase pages of flash.
+ */
+static int spi_dataflash_erase(struct udevice *dev, u32 offset, 

Re: [U-Boot] [PATCH v6 00/15] Add PSCI support for Jetson TK1/Tegra124 + CNTFRQ fix

2015-04-17 Thread Stephen Warren

On 04/17/2015 08:02 AM, Jan Kiszka wrote:

On 2015-04-17 15:57, Stephen Warren wrote:

On 04/17/2015 12:47 AM, Jan Kiszka wrote:

On 2015-04-14 16:30, Ian Campbell wrote:

On Tue, 2015-04-14 at 16:12 +0200, Jan Kiszka wrote:

On 2015-04-14 16:06, Stephen Warren wrote:

On 04/14/2015 07:46 AM, Tom Rini wrote:

On Mon, Apr 13, 2015 at 06:48:05AM +0200, Jan Kiszka wrote:


Changes in v6:
- rebased over master
- included Thierry's SMMU enabling patch
- moved activation patch at the end so that it can be held back

This version can also be found at
https://github.com/siemens/u-boot/tree/jetson-tk1-v6.


So what level of coordination do we need on applying this series
so that
kernels (both old and new) can continue to function?  And perhaps
README
updates or similar?  Thanks!


Hopefully this series doesn't change anything by default, and simply
allows people to turn on support for booting kernels in non-secure
mode
if they want to? If so, there shouldn't be any co-ordination required.
If it changes the default behaviour, co-ordination is probably
required,
and that'd be a bad thing.


Sorry, forgot to mention: I can't flip the default behaviour to leave
virtualization support off only for the TK1. That's a generic default.


Would enabling it in the compile but adding bootm_boot_mode=sec to the
default environment (so it isn't used by default) be considered
sufficiently backwards compatible?


This turned out to not work as expected: booting in secure mode seems
to prevent that Linux can bring up CPUs 1-3. Not sure if this is to be
expected or a bug, but I will now take a different route:


That was the whole point of the environment variable suggestion; the
environment variable would default to off so nobody got new behaviour,
but anyone who wanted to boot in secure mode could simply set the
environment variable and get it. That way, nobody who doesn't want the
feature needs to co-ordinate U-Boot and kernel updates. Why doesn't that
work?


Because it breaks SMP on Linux, namely the boot of secondary cores.
Don't ask me why, I didn't debug the details. But you can probably
reproduce by specifying bootm_boot_mode=sec with current U-boot and
recent upstream kernels.


I suspect the environment variable isn't working, and Linux is still 
being booted in non-secure mode. That would be a bug in U-Boot.

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


[U-Boot] [PATCH] ahci: mmio_base is a virtual address

2015-04-17 Thread Scott Wood
Don't store it in a u32.

Don't dereference the bus address as if it were a virtual address
(fixes 284231e49a2b4 (ahci: Support splitting of read transactions
into multiple chunks)).

Fixes crash on boot in MPC8641HPCN_36BIT target.

Signed-off-by: Scott Wood scottw...@freescale.com
Cc: Vadim Bendebury vben...@chromium.org
Cc: York Sun york...@freescale.com
---
 arch/arm/cpu/armv7/omap-common/boot-common.c |  2 +-
 arch/arm/cpu/armv7/omap-common/sata.c|  6 +++---
 board/highbank/highbank.c|  2 +-
 board/sunxi/ahci.c   |  2 +-
 drivers/block/ahci.c | 11 ++-
 drivers/block/dwc_ahsata.c   |  2 +-
 include/ahci.h   |  6 +++---
 7 files changed, 16 insertions(+), 15 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/boot-common.c 
b/arch/arm/cpu/armv7/omap-common/boot-common.c
index 17500f2..f2f6897 100644
--- a/arch/arm/cpu/armv7/omap-common/boot-common.c
+++ b/arch/arm/cpu/armv7/omap-common/boot-common.c
@@ -159,6 +159,6 @@ void __noreturn jump_to_image_no_args(struct spl_image_info 
*spl_image)
 #ifdef CONFIG_SCSI_AHCI_PLAT
 void arch_preboot_os(void)
 {
-   ahci_reset(DWC_AHSATA_BASE);
+   ahci_reset((void __iomem *)DWC_AHSATA_BASE);
 }
 #endif
diff --git a/arch/arm/cpu/armv7/omap-common/sata.c 
b/arch/arm/cpu/armv7/omap-common/sata.c
index d18bc50..2c2d1bc 100644
--- a/arch/arm/cpu/armv7/omap-common/sata.c
+++ b/arch/arm/cpu/armv7/omap-common/sata.c
@@ -69,7 +69,7 @@ int init_sata(int dev)
val = TI_SATA_IDLE_NO | TI_SATA_STANDBY_NO;
writel(val, TI_SATA_WRAPPER_BASE + TI_SATA_SYSCONFIG);
 
-   ret = ahci_init(DWC_AHSATA_BASE);
+   ret = ahci_init((void __iomem *)DWC_AHSATA_BASE);
 
return ret;
 }
@@ -88,6 +88,6 @@ void scsi_init(void)
 
 void scsi_bus_reset(void)
 {
-   ahci_reset(DWC_AHSATA_BASE);
-   ahci_init(DWC_AHSATA_BASE);
+   ahci_reset((void __iomem *)DWC_AHSATA_BASE);
+   ahci_init((void __iomem *)DWC_AHSATA_BASE);
 }
diff --git a/board/highbank/highbank.c b/board/highbank/highbank.c
index fc2385c..ba1beb5 100644
--- a/board/highbank/highbank.c
+++ b/board/highbank/highbank.c
@@ -57,7 +57,7 @@ void scsi_init(void)
u32 reg = readl(HB_SREG_A9_PWRDOM_STAT);
 
if (reg  PWRDOM_STAT_SATA) {
-   ahci_init(HB_AHCI_BASE);
+   ahci_init((void __iomem *)HB_AHCI_BASE);
scsi_scan(1);
}
 }
diff --git a/board/sunxi/ahci.c b/board/sunxi/ahci.c
index b7f0dda..6d51b9b 100644
--- a/board/sunxi/ahci.c
+++ b/board/sunxi/ahci.c
@@ -83,5 +83,5 @@ void scsi_init(void)
if (sunxi_ahci_phy_init(SUNXI_SATA_BASE)  0)
return;
 
-   ahci_init(SUNXI_SATA_BASE);
+   ahci_init((void __iomem *)SUNXI_SATA_BASE);
 }
diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index 88b90e0..6508648 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -137,10 +137,10 @@ static void sunxi_dma_init(volatile u8 *port_mmio)
 }
 #endif
 
-int ahci_reset(u32 base)
+int ahci_reset(void __iomem *base)
 {
int i = 1000;
-   u32 host_ctl_reg = base + HOST_CTL;
+   u32 __iomem *host_ctl_reg = base + HOST_CTL;
u32 tmp = readl(host_ctl_reg); /* global controller reset */
 
if ((tmp  HOST_RESET) == 0)
@@ -419,8 +419,9 @@ static int ahci_init_one(pci_dev_t pdev)
probe_ent-pio_mask = 0x1f;
probe_ent-udma_mask = 0x7f;/*Fixme,assume to support UDMA6 */
 
-   pci_read_config_dword(pdev, PCI_BASE_ADDRESS_5, probe_ent-mmio_base);
-   debug(ahci mmio_base=0x%08x\n, probe_ent-mmio_base);
+   probe_ent-mmio_base = pci_map_bar(pdev, PCI_BASE_ADDRESS_5,
+  PCI_REGION_MEM);
+   debug(ahci mmio_base=0x%p\n, probe_ent-mmio_base);
 
/* Take from kernel:
 * JMicron-specific fixup:
@@ -939,7 +940,7 @@ void scsi_low_level_init(int busdevfunc)
 }
 
 #ifdef CONFIG_SCSI_AHCI_PLAT
-int ahci_init(u32 base)
+int ahci_init(void __iomem *base)
 {
int i, rc = 0;
u32 linkmap;
diff --git a/drivers/block/dwc_ahsata.c b/drivers/block/dwc_ahsata.c
index 01a4148..cf3ef6b 100644
--- a/drivers/block/dwc_ahsata.c
+++ b/drivers/block/dwc_ahsata.c
@@ -343,7 +343,7 @@ static int ahci_init_one(int pdev)
| ATA_FLAG_PIO_DMA
| ATA_FLAG_NO_ATAPI;
 
-   probe_ent-mmio_base = CONFIG_DWC_AHSATA_BASE_ADDR;
+   probe_ent-mmio_base = (void __iomem *)CONFIG_DWC_AHSATA_BASE_ADDR;
 
/* initialize adapter */
rc = ahci_host_init(probe_ent);
diff --git a/include/ahci.h b/include/ahci.h
index e8dee53..6d91712 100644
--- a/include/ahci.h
+++ b/include/ahci.h
@@ -151,7 +151,7 @@ struct ahci_probe_ent {
u32 hard_port_no;
u32 host_flags;
u32 host_set_flags;
-   u32 mmio_base;
+   void __iomem *mmio_base;
u32 pio_mask;
u32 

Re: [U-Boot] [PATCH v6 00/15] Add PSCI support for Jetson TK1/Tegra124 + CNTFRQ fix

2015-04-17 Thread Jan Kiszka
On 2015-04-17 16:12, Stephen Warren wrote:
 On 04/17/2015 08:02 AM, Jan Kiszka wrote:
 On 2015-04-17 15:57, Stephen Warren wrote:
 On 04/17/2015 12:47 AM, Jan Kiszka wrote:
 On 2015-04-14 16:30, Ian Campbell wrote:
 On Tue, 2015-04-14 at 16:12 +0200, Jan Kiszka wrote:
 On 2015-04-14 16:06, Stephen Warren wrote:
 On 04/14/2015 07:46 AM, Tom Rini wrote:
 On Mon, Apr 13, 2015 at 06:48:05AM +0200, Jan Kiszka wrote:

 Changes in v6:
 - rebased over master
 - included Thierry's SMMU enabling patch
 - moved activation patch at the end so that it can be held
 back

 This version can also be found at
 https://github.com/siemens/u-boot/tree/jetson-tk1-v6.

 So what level of coordination do we need on applying this series
 so that
 kernels (both old and new) can continue to function?  And perhaps
 README
 updates or similar?  Thanks!

 Hopefully this series doesn't change anything by default, and simply
 allows people to turn on support for booting kernels in non-secure
 mode
 if they want to? If so, there shouldn't be any co-ordination
 required.
 If it changes the default behaviour, co-ordination is probably
 required,
 and that'd be a bad thing.

 Sorry, forgot to mention: I can't flip the default behaviour to leave
 virtualization support off only for the TK1. That's a generic
 default.

 Would enabling it in the compile but adding bootm_boot_mode=sec
 to the
 default environment (so it isn't used by default) be considered
 sufficiently backwards compatible?

 This turned out to not work as expected: booting in secure mode seems
 to prevent that Linux can bring up CPUs 1-3. Not sure if this is to be
 expected or a bug, but I will now take a different route:

 That was the whole point of the environment variable suggestion; the
 environment variable would default to off so nobody got new behaviour,
 but anyone who wanted to boot in secure mode could simply set the
 environment variable and get it. That way, nobody who doesn't want the
 feature needs to co-ordinate U-Boot and kernel updates. Why doesn't that
 work?

 Because it breaks SMP on Linux, namely the boot of secondary cores.
 Don't ask me why, I didn't debug the details. But you can probably
 reproduce by specifying bootm_boot_mode=sec with current U-boot and
 recent upstream kernels.
 
 I suspect the environment variable isn't working, and Linux is still
 being booted in non-secure mode. That would be a bug in U-Boot.

Yes, might be. Linux reports being started (with that single CPU) in SVC
mode. I'll recheck if it is a regression of my series.

Anyway, even if it worked, I think the cleaner way is flipping defaults
at the config root level (virt support) as long as things are not
working out of the box with Linux. That's what my other patch is doing
now. Any concerns regarding it?

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Please pull u-boot-dm.git [take 2]

2015-04-17 Thread Hans de Goede

Hi Tom and Simon,

On 17-04-15 18:54, Simon Glass wrote:

Hi Tom,

On 17 April 2015 at 10:46, Tom Rini tr...@konsulko.com wrote:

On Fri, Apr 17, 2015 at 10:30:36AM -0600, Simon Glass wrote:

Hi Tom,

On 17 April 2015 at 10:27, Tom Rini tr...@konsulko.com wrote:


On Thu, Apr 16, 2015 at 09:15:26PM -0600, Simon Glass wrote:


Hi Tom,

As mentioned I reverted this patch as it conflicted with the dm tree
and I suspect it might be buggy:

cd749658 usb_storage : scan all interfaces to find a storage device

Assuming this is OK and applies successfully I will rebase and resend
this patch, then reply with some comments I have on the patch.


The following changes since commit 4564faeafbf11feb839e2e3f927be2f1a919ba96:

   ti: dwc3: Enable clocks in enable_basic_clocks() in hw_data.c
(2015-04-16 15:08:36 -0400)

are available in the git repository at:

   http://git.denx.de/u-boot-dm.git

for you to fetch changes up to 2e6263093b3a5c2d2c586afaedfd346d6628f784:

   sandbox: exynos: Move CONFIG_SOUND_SANDBOX to Kconfig (2015-04-16
20:47:57 -0600)


With this PR, am335x_boneblack (which has DM enabled) no longer
functions.  I'm running a bisect now, but heads up.


OK, I'll wait for your bisect - also what is the console output when it breaks?


OK, disregard Beaglebone Black error, that was me (need to remember that
eMMC boot only works off of am335x_boneblack_config).  But,
A20-OLinuXino-Lime2_defconfig is broken by this.  The error log:
Command(A20 OLinuXino Lime2 console) on
(user:trini) Power turned on

U-Boot SPL 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45)
DRAM: 1024 MiB
CPU: 91200Hz, AXI/AHB/APB: 3/2/2


U-Boot 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
SCSI:  SUNXI SCSI INIT
SATA link 0 timeout.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst
Net:   dwmac.1c5
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices...
U-Boot SPL 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45)
DRAM: 1024 MiB
CPU: 91200Hz, AXI/AHB/APB: 3/2/2
MMC Device 0 not found
spl: mmc device not found!!
### ERROR ### Please RESET the board ###

And good:
Command(A20 OLinuXino Lime2 console) on
(user:trini) Power turned on

U-Boot SPL 2015.04-00121-g4564fae (Apr 17 2015 - 12:42:40)
DRAM: 1024 MiB
CPU: 91200Hz, AXI/AHB/APB: 3/2/2


U-Boot 2015.04-00121-g4564fae (Apr 17 2015 - 12:42:40) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
SCSI:  SUNXI SCSI INIT
SATA link 0 timeout.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst
Net:   dwmac.1c5
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
USB1:   USB EHCI 1.00
scanning bus 1 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
sunxi#

So... we cause a reset during USB scan and then fail to boot a second
time?


Thanks for testing this.

I'm not sure if I have a Lime (I might do, will need to look). I was
testing sunxi on a pcduino3 but USB does not work on that for reasons
I was looking into (it just says lowlevel init failure due to moving
to driver model for GPIO).

I will take a look. In the meantime, which commit breaks this? I could
perhaps issue a pull for commits up to that point to reduce the load.


I've been working on moving more sunxi boards over to dm (all of them to be
precise) sofar I've mostly been doing some ground work, so I've not yet run
any tests. I'll run some tests on another Olinuxino A20 board, and an A10 Lime
with current u-boot-dm/master, and assuming I can reproduce I'll try to come up
with a fix.

Regards,

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


Re: [U-Boot] u-boot for Snow problem

2015-04-17 Thread Michal Suchanek
On 15 April 2015 at 19:01, Michal Suchanek hramr...@gmail.com wrote:
 On 15 April 2015 at 17:00, Simon Glass s...@chromium.org wrote:
 Hi Michal,

 On 14 April 2015 at 16:10, Michal Suchanek hramr...@gmail.com wrote:
 Hello,

 On 4 March 2015 at 00:46, Simon Glass s...@chromium.org wrote:
 Hi Michal,

 On 2 March 2015 at 04:25, Michal Suchanek hramr...@gmail.com wrote:
 Hello,

 On 18 February 2015 at 06:24, Michal Suchanek hramr...@gmail.com wrote:
 On 18 February 2015 at 03:27, Simon Glass s...@chromium.org wrote:
 Hi Michal,

 On 16 February 2015 at 04:41, Michal Suchanek hramr...@gmail.com 
 wrote:
 On 13 February 2015 at 05:51, Simon Glass s...@chromium.org wrote:
 Hi Michal,

 On 11 February 2015 at 10:16, Michal Suchanek hramr...@gmail.com 
 wrote:

 Hello,

 I changed the SYS_START to work around the bug in the manufacturer
 firmware, applied snow_defconfig, built u-boot.bin, packed it into
 kernel uimage, signed it, copied it to a kernel partition, bumped
 priority of the partition, and rebooted.


 Do you mean u-boot-dtb.bin? If not you won't get a device tree and it
 won't work.

 No, u-boot.bin. With u-boot-dtb.bin I get a snow # prompt on the
 built-in LCD, and working keyboard.

 OK sounds like it is working, good! I wonder if we should have a page
 on elinux.org?

 It is working to some extent.

 I managed to load kernel from the emmc which works fine but the kernel
 cannot read the emmc after it boots because it does not properly parse
 the partitioning scheme. This should be trivially fixable in the
 kernel and might actually work if I updated my sources but rebasing
 the extra patches required for Snow is not automatically handled.

 On the other hand, the linux kernel has no problem with the SDXC card
 in the SD slot and can read it just fine. Unfortunately, u-boot
 complains about EFI partition errors and won't load anything from the
 card. I tried two different GPT partitioning tools on the card and
 both say that the partition layout is fine and that I have the default
 128 entries.

 How can I tell why u-boot does not like my GPT label?

 You could debug it in U-Boot and see what is going wrong.


 Apparently the problem is that the dw mmc controller fails and the
 sectors are unreadable. U-boot sometimes reports timeout, sometimes
 data error, and sometimes nothing because the result has already been
 cached probably. And the reason the dw mmc controller fails is that
 port 1 is disabled. Not using disabled controllers would probably
 solve the problem.

 Seems strange. Can you post details of which commit you are building
 and the console output? I could try it too.


 Sorry, I don't have the tree anymore.

 None of my trees has the commit to relocate away from the address
 clobbered by the Snow ro firmware.

 I tried looking again what actually happens but none of the mmc
 commands shows which exact mmc interfaces I have. U-boot somehow picks
 2 of the 4 dwmmc interfaces the Exynos chip has and I suspect the
 second one is picked or multiplexed wrong. The mmc0 to which emmc is
 connected works fine but mmc2 connected to the external slot always
 fails (on Snow mmc1 is unused and mmc3 is WiFi).


Ok, I did the chainload dance and I am running u-boot master patched
so it prints the IO address in mmc list and now

1) both mmc interfaces work
2) I can see the correct mmc interface is used in mmc list

So it was broken for whatever reason and is fixed.

Thanks

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


[U-Boot] U-Boot

2015-04-17 Thread wehner . junior
Hello,

I want to add a fixed phy connection to describe the rgmii interface between a 
cpu and an ethernet switch.

What is the recommended way over the phylib?

Kind regards,

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


[U-Boot] [PATCH 1/1] mmc: bcm2835_sdhci: Use calloc to allocate bcm2835_sdhci_host

2015-04-17 Thread Alexander Stein
We need to clear the allocated memory explicitly as the included
struct sdhci_host has function pointers. Those are compared to NULL to
test if this (optional) feature is supported. Leaving them undefined let
u-boot jump to arbitrary memory.

Signed-off-by: Alexander Stein alexander...@web.de
---
 drivers/mmc/bcm2835_sdhci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/bcm2835_sdhci.c b/drivers/mmc/bcm2835_sdhci.c
index 92f7d89..127dbe3 100644
--- a/drivers/mmc/bcm2835_sdhci.c
+++ b/drivers/mmc/bcm2835_sdhci.c
@@ -154,9 +154,9 @@ int bcm2835_sdhci_init(u32 regbase, u32 emmc_freq)
struct bcm2835_sdhci_host *bcm_host;
struct sdhci_host *host;
 
-   bcm_host = malloc(sizeof(*bcm_host));
+   bcm_host = calloc(1, sizeof(*bcm_host));
if (!bcm_host) {
-   printf(sdhci_host malloc fail!\n);
+   printf(sdhci_host calloc fail!\n);
return 1;
}
 
-- 
2.3.5

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


Re: [U-Boot] CONFIG_SPL vs CONFIG_SYS_EXTRA_OPTIONS

2015-04-17 Thread Fabio Estevam
Hi Nikolay,

On Fri, Apr 17, 2015 at 2:03 PM, Nikolay Dimitrov picmas...@mail.bg wrote:

 Sorry if you felt like this, but I wasn't pointing at you specifically.

No problem. Just to clarify: during the hummingboard patch submission
Tom Rini suggested me to remove the 'SPL'.

So I did it (among other things) and sent a v2.

Regards,

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


Re: [U-Boot] [PATCH v3] powerpc/t1040qds: Add support of SD boot for T1040QDS Board

2015-04-17 Thread York Sun
On 02/13/2015 07:25 AM, Vijay Rai wrote:
 Add support of 2 stage SD boot loader using SPL framework.
 here, PBL initialise the internal SRAM and copy SPL(160KB). This further
 initialise DDR using SPD environment and copy u-boot(768 KB) from NAND to DDR.
 Finally SPL transer control to u-boot.
 
 Initialise/create followings required for SPL framework
   - Add spl.c which defines board_init_f, board_init_r
   - Update tlb and ddr accordingly
 
 Add T1040QDS_SDCARD_defconfig
 Update t1040_pbi.cfg to support errata A-007662, A-008007 and LAW for CPC1
 
 Signed-off-by: Vijay Rai vijay@freescale.com
 Signed-off-by: Priyanka Jain priyanka.j...@freescale.com
 ---
 changes from v2:
  - Updated Copyright to 2015
  - Updated board_need_mem_reset, now it resets DDR by default, earlier
it was disabling the reset for NOR boot which is wrong
  - tested NOR boot and SD boot 
 

Please rebase your patch and test. I see compiling errors and warnings.

York

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


Re: [U-Boot] [PATCH] board/p2020rdb: fix the FDT_ERR_NOTFOUND issue

2015-04-17 Thread York Sun


On 03/24/2015 12:48 AM, ying.zh...@freescale.com wrote:
 From: Ying Zhang b40...@freescale.com
 
 Because the function ft_board_setup() delete the USB2 device node, it
 leads to can't find the device node and hung up.
 
 In fact only P1020RDB needs to delete the USB2 node, this patch fixes
 this issue.
 
 Signed-off-by: Ying Zhang b40...@freescale.com
 ---
  board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 4 
  1 file changed, 4 insertions(+)
 
 diff --git a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c 
 b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
 index 3f47cfb..0c60fc3 100644
 --- a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
 +++ b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
 @@ -428,8 +428,10 @@ int ft_board_setup(void *blob, bd_t *bd)
  {
   phys_addr_t base;
   phys_size_t size;
 +#if defined(CONFIG_P1020RDB_PD) || defined(CONFIG_P1020RDB_PC)
   const char *soc_usb_compat = fsl-usb2-dr;
   int err, usb1_off, usb2_off;
 +#endif

err is used elsewhere. Your change causes compiling error on these boards

P1025RDB_SDCARD P2020RDB-PC_36BIT_SPIFLASH P1021RDB-PC_36BIT_SPIFLASH
P2020RDB-PC_SPIFLASH P1020MBG-PC_36BIT_SDCARD P1024RDB_SPIFLASH
P1021RDB-PC_SPIFLASH P1020MBG-PC_SDCARD P2020RDB-PC_36BIT_SDCARD
P1021RDB-PC_SDCARD P2020RDB-PC_SDCARD P1024RDB_SDCARD P1025RDB_SPIFLASH
P1020UTM-PC_36BIT_SDCARD P1021RDB-PC_36BIT_SDCARD P1020UTM-PC_SDCARD

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


Re: [U-Boot] Please pull u-boot-dm.git [take 2]

2015-04-17 Thread Tom Rini
On Fri, Apr 17, 2015 at 10:54:21AM -0600, Simon Glass wrote:
 Hi Tom,
 
 On 17 April 2015 at 10:46, Tom Rini tr...@konsulko.com wrote:
  On Fri, Apr 17, 2015 at 10:30:36AM -0600, Simon Glass wrote:
  Hi Tom,
 
  On 17 April 2015 at 10:27, Tom Rini tr...@konsulko.com wrote:
  
   On Thu, Apr 16, 2015 at 09:15:26PM -0600, Simon Glass wrote:
  
Hi Tom,
   
As mentioned I reverted this patch as it conflicted with the dm tree
and I suspect it might be buggy:
   
cd749658 usb_storage : scan all interfaces to find a storage device
   
Assuming this is OK and applies successfully I will rebase and resend
this patch, then reply with some comments I have on the patch.
   
   
The following changes since commit 
4564faeafbf11feb839e2e3f927be2f1a919ba96:
   
  ti: dwc3: Enable clocks in enable_basic_clocks() in hw_data.c
(2015-04-16 15:08:36 -0400)
   
are available in the git repository at:
   
  http://git.denx.de/u-boot-dm.git
   
for you to fetch changes up to 
2e6263093b3a5c2d2c586afaedfd346d6628f784:
   
  sandbox: exynos: Move CONFIG_SOUND_SANDBOX to Kconfig (2015-04-16
20:47:57 -0600)
  
   With this PR, am335x_boneblack (which has DM enabled) no longer
   functions.  I'm running a bisect now, but heads up.
 
  OK, I'll wait for your bisect - also what is the console output when it 
  breaks?
 
  OK, disregard Beaglebone Black error, that was me (need to remember that
  eMMC boot only works off of am335x_boneblack_config).  But,
  A20-OLinuXino-Lime2_defconfig is broken by this.  The error log:
  Command(A20 OLinuXino Lime2 console) on
  (user:trini) Power turned on
 
  U-Boot SPL 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45)
  DRAM: 1024 MiB
  CPU: 91200Hz, AXI/AHB/APB: 3/2/2
 
 
  U-Boot 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45) Allwinner Technology
 
  CPU:   Allwinner A20 (SUN7I)
  I2C:   ready
  DRAM:  1 GiB
  MMC:   SUNXI SD/MMC: 0
  *** Warning - bad CRC, using default environment
 
  In:serial
  Out:   serial
  Err:   serial
  SCSI:  SUNXI SCSI INIT
  SATA link 0 timeout.
  AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
  flags: ncq stag pm led clo only pmp pio slum part ccc apst
  Net:   dwmac.1c5
  starting USB...
  USB0:   USB EHCI 1.00
  scanning bus 0 for devices...
  U-Boot SPL 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45)
  DRAM: 1024 MiB
  CPU: 91200Hz, AXI/AHB/APB: 3/2/2
  MMC Device 0 not found
  spl: mmc device not found!!
  ### ERROR ### Please RESET the board ###
 
  And good:
  Command(A20 OLinuXino Lime2 console) on
  (user:trini) Power turned on
 
  U-Boot SPL 2015.04-00121-g4564fae (Apr 17 2015 - 12:42:40)
  DRAM: 1024 MiB
  CPU: 91200Hz, AXI/AHB/APB: 3/2/2
 
 
  U-Boot 2015.04-00121-g4564fae (Apr 17 2015 - 12:42:40) Allwinner Technology
 
  CPU:   Allwinner A20 (SUN7I)
  I2C:   ready
  DRAM:  1 GiB
  MMC:   SUNXI SD/MMC: 0
  *** Warning - bad CRC, using default environment
 
  In:serial
  Out:   serial
  Err:   serial
  SCSI:  SUNXI SCSI INIT
  SATA link 0 timeout.
  AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
  flags: ncq stag pm led clo only pmp pio slum part ccc apst
  Net:   dwmac.1c5
  starting USB...
  USB0:   USB EHCI 1.00
  scanning bus 0 for devices... 1 USB Device(s) found
  USB1:   USB EHCI 1.00
  scanning bus 1 for devices... 1 USB Device(s) found
 scanning usb for storage devices... 0 Storage Device(s) found
  Hit any key to stop autoboot:  0
  sunxi#
 
  So... we cause a reset during USB scan and then fail to boot a second
  time?
 
 Thanks for testing this.
 
 I'm not sure if I have a Lime (I might do, will need to look). I was
 testing sunxi on a pcduino3 but USB does not work on that for reasons
 I was looking into (it just says lowlevel init failure due to moving
 to driver model for GPIO).
 
 I will take a look. In the meantime, which commit breaks this? I could
 perhaps issue a pull for commits up to that point to reduce the load.

I haven't had a chance to bisect yet but I will in a few hours.

-- 
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] ahci: mmio_base is a virtual address

2015-04-17 Thread York Sun


On 04/17/2015 07:19 AM, Scott Wood wrote:
 Don't store it in a u32.
 
 Don't dereference the bus address as if it were a virtual address
 (fixes 284231e49a2b4 (ahci: Support splitting of read transactions
 into multiple chunks)).
 
 Fixes crash on boot in MPC8641HPCN_36BIT target.
 
 Signed-off-by: Scott Wood scottw...@freescale.com
 Cc: Vadim Bendebury vben...@chromium.org
 Cc: York Sun york...@freescale.com
 ---

Acked-by: York Sun york...@freescale.com

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


Re: [U-Boot] [PATCH v3] usb_storage : scan all interfaces to find a storage device

2015-04-17 Thread Simon Glass
+Tom

Hi Franck,

On 4 March 2015 at 13:07,  franck.jull...@gmail.com wrote:
 From: Franck Jullien franck.jull...@gmail.com

 Mass storage is not necessary present on interface 0. This
 patch allow usb_stor_scan to look in every available interface.

 Signed-off-by: Franck Jullien franck.jull...@gmail.com
 ---

 v2: create a new function to improve indentation

 v3: more indentation improvement

  common/usb_storage.c |   45 -
  1 files changed, 28 insertions(+), 17 deletions(-)

 diff --git a/common/usb_storage.c b/common/usb_storage.c
 index 1411737..05c96a8 100644
 --- a/common/usb_storage.c
 +++ b/common/usb_storage.c
 @@ -208,6 +208,30 @@ static unsigned int usb_get_max_lun(struct us_data *us)
 return (len  0) ? *result : 0;
  }

 +static int usb_storage_register(struct usb_device *dev, unsigned char iface)
 +{
 +   int lun, max_lun, start = usb_max_devs;
 +   int nb_dev = 0;
 +
 +   if (!usb_storage_probe(dev, iface, usb_stor[usb_max_devs]))
 +   return nb_dev;
 +
 +   /*
 +* OK, it's a storage device.  Iterate over its LUNs
 +* and populate `usb_dev_desc'.
 +*/
 +   max_lun = usb_get_max_lun(usb_stor[usb_max_devs]);
 +   for (lun = 0; lun = max_lun  usb_max_devs  USB_MAX_STOR_DEV; 
 lun++) {
 +   usb_dev_desc[usb_max_devs].lun = lun;
 +   if (usb_stor_get_info(dev, usb_stor[start],
 +   usb_dev_desc[usb_max_devs]) == 1) {
 +   nb_dev++;

Should start or usb_max_devs increase here? This will use the same
block_dev_desc_t for each device, won't it?

 +   }
 +   }
 +
 +   return nb_dev;
 +}
 +
  
 /***
   * scan the usb and reports device info
   * to the user if mode = 1
 @@ -215,7 +239,7 @@ static unsigned int usb_get_max_lun(struct us_data *us)
   */
  int usb_stor_scan(int mode)
  {
 -   unsigned char i;
 +   unsigned char i, iface;
 struct usb_device *dev;

 if (mode == 1)
 @@ -241,23 +265,10 @@ int usb_stor_scan(int mode)
 if (dev == NULL)
 break; /* no more devices available */

 -   if (usb_storage_probe(dev, 0, usb_stor[usb_max_devs])) {
 -   /* OK, it's a storage device.  Iterate over its LUNs
 -* and populate `usb_dev_desc'.
 -*/
 -   int lun, max_lun, start = usb_max_devs;
 -
 -   max_lun = usb_get_max_lun(usb_stor[usb_max_devs]);
 -   for (lun = 0;
 -lun = max_lun  usb_max_devs  
 USB_MAX_STOR_DEV;
 -lun++) {
 -   usb_dev_desc[usb_max_devs].lun = lun;
 -   if (usb_stor_get_info(dev, usb_stor[start],
 -   usb_dev_desc[usb_max_devs]) == 1) {
 -   usb_max_devs++;
 -   }
 -   }
 +   for (iface = 0; iface  dev-config.no_of_if; iface++) {
 +   usb_max_devs += usb_storage_register(dev, iface);
 }
 +
 /* if storage device */
 if (usb_max_devs == USB_MAX_STOR_DEV) {
 printf(max USB Storage Device reached: %d 
 stopping\n,
 --
 1.7.1


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


Re: [U-Boot] Please pull u-boot-dm.git [take 2]

2015-04-17 Thread Simon Glass
Hi Tom,

On 17 April 2015 at 10:46, Tom Rini tr...@konsulko.com wrote:
 On Fri, Apr 17, 2015 at 10:30:36AM -0600, Simon Glass wrote:
 Hi Tom,

 On 17 April 2015 at 10:27, Tom Rini tr...@konsulko.com wrote:
 
  On Thu, Apr 16, 2015 at 09:15:26PM -0600, Simon Glass wrote:
 
   Hi Tom,
  
   As mentioned I reverted this patch as it conflicted with the dm tree
   and I suspect it might be buggy:
  
   cd749658 usb_storage : scan all interfaces to find a storage device
  
   Assuming this is OK and applies successfully I will rebase and resend
   this patch, then reply with some comments I have on the patch.
  
  
   The following changes since commit 
   4564faeafbf11feb839e2e3f927be2f1a919ba96:
  
 ti: dwc3: Enable clocks in enable_basic_clocks() in hw_data.c
   (2015-04-16 15:08:36 -0400)
  
   are available in the git repository at:
  
 http://git.denx.de/u-boot-dm.git
  
   for you to fetch changes up to 2e6263093b3a5c2d2c586afaedfd346d6628f784:
  
 sandbox: exynos: Move CONFIG_SOUND_SANDBOX to Kconfig (2015-04-16
   20:47:57 -0600)
 
  With this PR, am335x_boneblack (which has DM enabled) no longer
  functions.  I'm running a bisect now, but heads up.

 OK, I'll wait for your bisect - also what is the console output when it 
 breaks?

 OK, disregard Beaglebone Black error, that was me (need to remember that
 eMMC boot only works off of am335x_boneblack_config).  But,
 A20-OLinuXino-Lime2_defconfig is broken by this.  The error log:
 Command(A20 OLinuXino Lime2 console) on
 (user:trini) Power turned on

 U-Boot SPL 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45)
 DRAM: 1024 MiB
 CPU: 91200Hz, AXI/AHB/APB: 3/2/2


 U-Boot 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45) Allwinner Technology

 CPU:   Allwinner A20 (SUN7I)
 I2C:   ready
 DRAM:  1 GiB
 MMC:   SUNXI SD/MMC: 0
 *** Warning - bad CRC, using default environment

 In:serial
 Out:   serial
 Err:   serial
 SCSI:  SUNXI SCSI INIT
 SATA link 0 timeout.
 AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
 flags: ncq stag pm led clo only pmp pio slum part ccc apst
 Net:   dwmac.1c5
 starting USB...
 USB0:   USB EHCI 1.00
 scanning bus 0 for devices...
 U-Boot SPL 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45)
 DRAM: 1024 MiB
 CPU: 91200Hz, AXI/AHB/APB: 3/2/2
 MMC Device 0 not found
 spl: mmc device not found!!
 ### ERROR ### Please RESET the board ###

 And good:
 Command(A20 OLinuXino Lime2 console) on
 (user:trini) Power turned on

 U-Boot SPL 2015.04-00121-g4564fae (Apr 17 2015 - 12:42:40)
 DRAM: 1024 MiB
 CPU: 91200Hz, AXI/AHB/APB: 3/2/2


 U-Boot 2015.04-00121-g4564fae (Apr 17 2015 - 12:42:40) Allwinner Technology

 CPU:   Allwinner A20 (SUN7I)
 I2C:   ready
 DRAM:  1 GiB
 MMC:   SUNXI SD/MMC: 0
 *** Warning - bad CRC, using default environment

 In:serial
 Out:   serial
 Err:   serial
 SCSI:  SUNXI SCSI INIT
 SATA link 0 timeout.
 AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
 flags: ncq stag pm led clo only pmp pio slum part ccc apst
 Net:   dwmac.1c5
 starting USB...
 USB0:   USB EHCI 1.00
 scanning bus 0 for devices... 1 USB Device(s) found
 USB1:   USB EHCI 1.00
 scanning bus 1 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
 Hit any key to stop autoboot:  0
 sunxi#

 So... we cause a reset during USB scan and then fail to boot a second
 time?

Thanks for testing this.

I'm not sure if I have a Lime (I might do, will need to look). I was
testing sunxi on a pcduino3 but USB does not work on that for reasons
I was looking into (it just says lowlevel init failure due to moving
to driver model for GPIO).

I will take a look. In the meantime, which commit breaks this? I could
perhaps issue a pull for commits up to that point to reduce the load.

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


Re: [U-Boot] [PATCH v2 1/4] mmc: fsl_esdhc: Add adapter card type identification support

2015-04-17 Thread York Sun
+Pantelis

On 04/16/2015 09:51 PM, Yangbo Lu wrote:
 Add adapter card type identification support by reading
 FPGA STAT_PRES1 register SDHC Card ID[0:2] bits. To use this function,
 define CONFIG_FSL_ESDHC_ADAPTER_IDENT.
 
 Signed-off-by: Yangbo Lu yangbo...@freescale.com
 Cc: York Sun york...@freescale.com
 ---
 Changes for v2:
   - Document CONFIG_FSL_ESDHC_ADAPTER_IDENT
 ---
  arch/powerpc/include/asm/global_data.h |  3 +++
  board/freescale/common/qixis.h | 14 +
  doc/README.fsl-esdhc   | 25 ++
  drivers/mmc/fsl_esdhc.c| 38 
 +-
  drivers/mmc/mmc.c  |  6 ++
  drivers/mmc/mmc_private.h  |  3 +++
  include/fsl_esdhc.h|  4 
  7 files changed, 88 insertions(+), 5 deletions(-)
 
 diff --git a/arch/powerpc/include/asm/global_data.h 
 b/arch/powerpc/include/asm/global_data.h
 index c57d9c0..4090975 100644
 --- a/arch/powerpc/include/asm/global_data.h
 +++ b/arch/powerpc/include/asm/global_data.h
 @@ -15,6 +15,9 @@
  struct arch_global_data {
  #if defined(CONFIG_FSL_ESDHC)
   u32 sdhc_clk;
 +#if defined(CONFIG_FSL_ESDHC_ADAPTER_IDENT)
 + u8 sdhc_adapter;
 +#endif
  #endif
  #if defined(CONFIG_8xx)
   unsigned long brg_clk;
 diff --git a/board/freescale/common/qixis.h b/board/freescale/common/qixis.h
 index 52d2021..51ce9c3 100644
 --- a/board/freescale/common/qixis.h
 +++ b/board/freescale/common/qixis.h
 @@ -115,4 +115,18 @@ void qixis_write_i2c(unsigned int reg, u8 value);
   qixis_write_i2c(offsetof(struct qixis, reg), value)
  #endif
  
 +/* Use for SDHC adapter card type identification and operation */
 +#ifdef CONFIG_FSL_ESDHC_ADAPTER_IDENT
 +#define QIXIS_SDID_MASK 0x07
 +#define QIXIS_ESDHC_ADAPTER_TYPE_EMMC45 0x1  /* eMMC Card Rev4.5 */
 +#define QIXIS_ESDHC_ADAPTER_TYPE_SDMMC_LEGACY   0x2  /* SD/MMC Legacy Card */
 +#define QIXIS_ESDHC_ADAPTER_TYPE_EMMC44 0x3  /* eMMC Card Rev4.4 */
 +#define QIXIS_ESDHC_ADAPTER_TYPE_RSV0x4  /* Reserved */
 +#define QIXIS_ESDHC_ADAPTER_TYPE_MMC0x5  /* MMC Card */
 +#define QIXIS_ESDHC_ADAPTER_TYPE_SD 0x6  /* SD Card Rev2.0 3.0 */
 +#define QIXIS_ESDHC_NO_ADAPTER  0x7  /* No Card is Present*/
 +#define QIXIS_SDCLKIN0x08
 +#define QIXIS_SDCLKOUT   0x02
 +#endif
 +
  #endif
 diff --git a/doc/README.fsl-esdhc b/doc/README.fsl-esdhc
 index b70f271..29cc661 100644
 --- a/doc/README.fsl-esdhc
 +++ b/doc/README.fsl-esdhc
 @@ -1,5 +1,22 @@
 -CONFIG_SYS_FSL_ESDHC_LE means ESDHC IP is in little-endian mode.
 -CONFIG_SYS_FSL_ESDHC_BE means ESDHC IP is in big-endian mode.
 +Freescale esdhc-specific options
  
 -Accessing ESDHC registers can be determined by ESDHC IP's endian
 -mode or processor's endian mode.
 + - CONFIG_FSL_ESDHC_ADAPTER_IDENT
 + Support Freescale adapter card type identification. This is 
 implemented by
 + operating Qixis FPGA relevant registers. The STAT_PRES1 
 register has SDHC
 + Card ID[0:2] bits showing the type of card installed in the 
 SDHC Adapter Slot.
 +
 + SDHC Card ID[0:2]   Adapter Card Type
 + 0b000   reserved
 + 0b001   eMMC Card Rev4.5
 + 0b010   SD/MMC Legacy Card
 + 0b011   eMMC Card Rev4.4
 + 0b100   reserved
 + 0b101   MMC Card
 + 0b110   SD Card Rev2.0/3.0
 + 0b111   No card is present
 + - CONFIG_SYS_FSL_ESDHC_LE
 + ESDHC IP is in little-endian mode. Accessing ESDHC registers 
 can be
 + determined by ESDHC IP's endian mode or processor's endian mode.
 + - CONFIG_SYS_FSL_ESDHC_BE
 + ESDHC IP is in big-endian mode. Accessing ESDHC registers can 
 be determined
 + by ESDHC IP's endian mode or processor's endian mode.
 diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
 index f5d2ccb..355cada 100644
 --- a/drivers/mmc/fsl_esdhc.c
 +++ b/drivers/mmc/fsl_esdhc.c
 @@ -643,6 +643,39 @@ int fsl_esdhc_mmc_init(bd_t *bis)
   return fsl_esdhc_initialize(bis, cfg);
  }
  
 +#ifdef CONFIG_FSL_ESDHC_ADAPTER_IDENT
 +void mmc_adapter_card_type_ident(void)
 +{
 + u8 card_id;
 + u8 value;
 +
 + card_id = QIXIS_READ(present)  QIXIS_SDID_MASK;
 + gd-arch.sdhc_adapter = card_id;
 +
 + switch (card_id) {
 + case QIXIS_ESDHC_ADAPTER_TYPE_EMMC45:
 + break;
 + case QIXIS_ESDHC_ADAPTER_TYPE_SDMMC_LEGACY:
 + break;
 + case QIXIS_ESDHC_ADAPTER_TYPE_EMMC44:
 + value = QIXIS_READ(brdcfg[5]);
 + value |= (QIXIS_SDCLKIN | QIXIS_SDCLKOUT);
 + QIXIS_WRITE(brdcfg[5], value);
 + break;
 + case 

[U-Boot] Clock tree in U-Boot

2015-04-17 Thread Eric Nelson
Hi all,

Heiko's recent patch set [1] to control the LDB clock on i.MX5/6 boards
makes it painfully obvious that some semblance of clock tree is needed,
even if it starts off as a shell.

We currently have routines declared in [2] that should be moved into
a more common spot:

void clk_enable(struct clk *clk);
void clk_disable(struct clk *clk);
u32 clk_get_rate(struct clk *clk);
int clk_set_rate(struct clk *clk, unsigned long rate);
long clk_round_rate(struct clk *clk, unsigned long rate);
int clk_set_parent(struct clk *clk, struct clk *parent);
int clk_get_usecount(struct clk *clk);
struct clk *clk_get_parent(struct clk *clk);

Can we get some agreement on a proper subset of [3] that's appropriate
for use in U-Boot?

My thought is that the list above, plus some form of clk_get() and/or
clk_get_sys() would be a good start.

Please advise,


Eric

[1] http://lists.denx.de/pipermail/u-boot/2015-April/thread.html#210677
[2] http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/video/ipu.h#l245
[3]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/clk.h?id=refs/tags/v4.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] CONFIG_SPL vs CONFIG_SYS_EXTRA_OPTIONS

2015-04-17 Thread Fabio Estevam
Hi Nikolay,

On Fri, Apr 17, 2015 at 1:48 PM, Nikolay Dimitrov picmas...@mail.bg wrote:
 Hi guys,

 Why is required to add SPL to CONFIG_SYS_EXTRA_OPTIONS, when we have
 also CONFIG_SPL? I found the following mx6 boards are doing it:

 configs/mx6sabresd_spl_defconfig

Yes, not needed. I will remove it.

 configs/cm_fx6_defconfig
 configs/mx6cuboxi_spl_defconfig

I remove the 'SPL' in v2.

Regards,

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


Re: [U-Boot] CONFIG_SPL vs CONFIG_SYS_EXTRA_OPTIONS

2015-04-17 Thread Nikolay Dimitrov

Hi Fabio,

On 04/17/2015 07:50 PM, Fabio Estevam wrote:

Hi Nikolay,

On Fri, Apr 17, 2015 at 1:48 PM, Nikolay Dimitrov picmas...@mail.bg wrote:

Hi guys,

Why is required to add SPL to CONFIG_SYS_EXTRA_OPTIONS, when we have
also CONFIG_SPL? I found the following mx6 boards are doing it:

configs/mx6sabresd_spl_defconfig


Yes, not needed. I will remove it.


configs/cm_fx6_defconfig
configs/mx6cuboxi_spl_defconfig


I remove the 'SPL' in v2.


Sorry if you felt like this, but I wasn't pointing at you specifically.

I'm just not sure what's the proper way to configure SPL support these
days, after so many updates to the SPL code  Kconfig migration.

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


Re: [U-Boot] [PATCH RESEND 1/3] driver/ddr/altera: Add DDR driver for Altera's SDRAM controller

2015-04-17 Thread Dinh Nguyen
Hi Pavel,

On 04/17/2015 07:31 AM, Pavel Machek wrote:
 Hi!
 
 +#ifndef _SDRAM_H_
 +#define _SDRAM_H_
 +
 +#ifndef __ASSEMBLY__
 +
 +/* function declaration */
 
 You can delete this comment.
 

Ok...

 +#define \
 +SDR_CTRLGRP_MPTHRESHOLDRST_0_THRESHOLDRSTCYCLES_31_0_LSB 0
 +#define  \
 +SDR_CTRLGRP_MPTHRESHOLDRST_0_THRESHOLDRSTCYCLES_31_0_MASK \
 +0x
 +/* Register template: sdr::ctrlgrp::mpthresholdrst::mpthresholdrst_1   
 */
 +#define \
 +SDR_CTRLGRP_MPTHRESHOLDRST_1_THRESHOLDRSTCYCLES_63_32_LSB 0
 +#define \
 +SDR_CTRLGRP_MPTHRESHOLDRST_1_THRESHOLDRSTCYCLES_63_32_MASK \
 +0x
 +/* Register template: sdr::ctrlgrp::mpthresholdrst::mpthresholdrst_2   
 */
 +#define \
 +SDR_CTRLGRP_MPTHRESHOLDRST_2_THRESHOLDRSTCYCLES_79_64_LSB 0
 +#define \
 +SDR_CTRLGRP_MPTHRESHOLDRST_2_THRESHOLDRSTCYCLES_79_64_MASK \
 +0x
 
 Can we get slightly shorter define names?

I did think about shortening these defines a bit, but came to this
reason that I should leave these alone. These defines are generated from
the tools AFAICT. I don't think any sane person would try to have
defines this long. So I still want to try to save the use case that the
driver can still be used with the autogenerated header file from the
tools in some form.

 
 +/* Register template: sdr::ctrlgrp::remappriority  
 */
 +#define SDR_CTRLGRP_REMAPPRIORITY_PRIORITYREMAP_LSB 0
 +#define SDR_CTRLGRP_REMAPPRIORITY_PRIORITYREMAP_MASK 0x00ff
 +/* Register template: sdr::ctrlgrp::phyctrl::phyctrl_0 
 */
 +#define SDR_CTRLGRP_PHYCTRL_PHYCTRL_0_SAMPLECOUNT_19_0_LSB 12
 +#define SDR_CTRLGRP_PHYCTRL_PHYCTRL_0_SAMPLECOUNT_19_0_WIDTH 20
 +#define SDR_CTRLGRP_PHYCTRL_PHYCTRL_0_SAMPLECOUNT_19_0_SET(x) \
 + (((x)  12)  0xf000)
 +#define SDR_CTRLGRP_PHYCTRL_PHYCTRL_0_ADDLATSEL_SET(x) \
 + (((x)  10)  0x0c00)
 +#define SDR_CTRLGRP_PHYCTRL_PHYCTRL_0_DQSLOGICDELAYEN_SET(x) \
 + (((x)  6)  0x00c0)
 +#define SDR_CTRLGRP_PHYCTRL_PHYCTRL_0_RESETDELAYEN_SET(x) \
 + (((x)  8)  0x0100)
 +#define SDR_CTRLGRP_PHYCTRL_PHYCTRL_0_LPDDRDIS_SET(x) \
 + (((x)  9)  0x0200)
 +#define SDR_CTRLGRP_PHYCTRL_PHYCTRL_0_DQSDELAYEN_SET(x) \
 + (((x)  4)  0x0030)
 +#define SDR_CTRLGRP_PHYCTRL_PHYCTRL_0_DQDELAYEN_SET(x) \
 + (((x)  2)  0x000c)
 +#define SDR_CTRLGRP_PHYCTRL_PHYCTRL_0_ACDELAYEN_SET(x) \
 + (((x)  0)  0x0003)
 +/* Register template: sdr::ctrlgrp::phyctrl::phyctrl_1 
 */
 +#define SDR_CTRLGRP_PHYCTRL_PHYCTRL_1_LONGIDLESAMPLECOUNT_19_0_WIDTH 20
 +#define SDR_CTRLGRP_PHYCTRL_PHYCTRL_1_LONGIDLESAMPLECOUNT_19_0_SET(x) \
 + (((x)  12)  0xf000)
 +#define SDR_CTRLGRP_PHYCTRL_PHYCTRL_1_SAMPLECOUNT_31_20_SET(x) \
 + (((x)  0)  0x0fff)
 +/* Register template: sdr::ctrlgrp::phyctrl::phyctrl_2 
 */
 +#define SDR_CTRLGRP_PHYCTRL_PHYCTRL_2_LONGIDLESAMPLECOUNT_31_20_SET(x) \
 + (((x)  0)  0x0fff)
 
 Too long names here, too..
 
 --- /dev/null
 +++ b/arch/arm/include/asm/arch-socfpga/sdram_config.h
 @@ -0,0 +1,100 @@
 +/*
 + * Copyright Altera Corporation (C) 2012-2015
 + *
 + * SPDX-License-Identifier:BSD-3-Clause
 + */
 +
 
 If this file is autogenerated, you should mention it here.
 

Ok...

 +#ifdef CONFIG_SOCFPGA_ARRIA5
 +/* The if..else... is not required if generated by tools */
 
 What does this comment say?
 

I have no idea, but will clean up.

 +#define CONFIG_HPS_SDR_CTRLCFG_MPPACING_1_THRESHOLD2_3_00
 +#define CONFIG_HPS_SDR_CTRLCFG_MPPACING_2_THRESHOLD2_35_4   0x41041041
 +#define CONFIG_HPS_SDR_CTRLCFG_MPPACING_3_THRESHOLD2_59_36  0x410410
 +#define CONFIG_HPS_SDR_CTRLCFG_MPTHRESHOLDRST_0_THRESHOLDRSTCYCLES_31_0 \
 +0x01010101
 +#define CONFIG_HPS_SDR_CTRLCFG_MPTHRESHOLDRST_1_THRESHOLDRSTCYCLES_63_32 \
 +0x01010101
 +#define CONFIG_HPS_SDR_CTRLCFG_MPTHRESHOLDRST_2_THRESHOLDRSTCYCLES_79_64 \
 +0x0101
 
 Drop HPS and CTRLCFG from the config names... they should still be
 unique and you'll not hit 80 column limits with just the name?
 

Same reasoning as I had for previous comment regarding long define names.

 +#define COMPARE_FAIL_ACTION return 1;
 
 Macros that change control flow are nasty.
 

Will remove...

 +/* Below function only applicable for SPL */
 
 Function below?

Will clean..

 
 Add ifdef so that it is not available for u-boot proper?
 
 +typedef struct _sdram_prot_rule {
 +uint64_tsdram_start;/* SDRAM start address */
 +uint64_tsdram_end;  /* SDRAM end address */
 +uint32_trule;   /* SDRAM protection rule number: 0-19 */
 +int valid;  /* Rule valid or not? 1 - valid, 0 not*/
 +
 +uint32_tsecurity;
 +uint32_tportmask;
 +uint32_tresult;
 +uint32_tlo_prot_id;
 +uint32_thi_prot_id;
 +} sdram_prot_rule, *psdram_prot_rule;
 
 Struct typedefs are nasty. Just use struct sdram_prot_rule?

Yeah...will clean up...

 
 +static void sdram_get_rule(psdram_prot_rule prule)
 +{
 

[U-Boot] CONFIG_SPL vs CONFIG_SYS_EXTRA_OPTIONS

2015-04-17 Thread Nikolay Dimitrov

Hi guys,

Why is required to add SPL to CONFIG_SYS_EXTRA_OPTIONS, when we have
also CONFIG_SPL? I found the following mx6 boards are doing it:

configs/mx6sabresd_spl_defconfig
configs/cm_fx6_defconfig
configs/mx6cuboxi_spl_defconfig

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


Re: [U-Boot] [PATCH] video, ipu: make ldb clock frequenz overwriteable through board code

2015-04-17 Thread Eric Nelson
Hi Heiko,

On 04/17/2015 12:53 AM, Heiko Schocher wrote:

 +int ipu_set_ldb_clock(int rate);
   #endif
 diff --git a/drivers/video/ipu_common.c b/drivers/video/ipu_common.c
 index 1a209d4..dc054bc 100644
 --- a/drivers/video/ipu_common.c
 +++ b/drivers/video/ipu_common.c
 @@ -1198,3 +1198,14 @@ ipu_color_space_t
 format_to_colorspace(uint32_t fmt)
   }
   return RGB;
   }
 +
 +/* should removed when clk framework is availiable */
 +int ipu_set_ldb_clock(int rate)
 +{

 This forces a tight dependency on when this is called that
 using ldb_clk directly would prevent.
 
 Sorry, did not understand you here ...
 

The variable g_ldb is initialized in ipu_probe(), so this routine
must be called at a very particular time.

You must have noticed it, since you put in a check for NULL.

 +if (g_ldb_clk == NULL)
 +return -ENOENT;
 +

If you replace this with ldb_clk.rate, the dependency goes
away.

 +g_ldb_clk-rate = rate;
 +
 +return 0;
 +}


Separately, I don't see any reason not to have g_ldb_clk
statically initialized... i.e.

struct clk *g_ldb_clk = ldb_clk;


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


Re: [U-Boot] Please pull u-boot-dm.git [take 2]

2015-04-17 Thread Tom Rini
On Thu, Apr 16, 2015 at 09:15:26PM -0600, Simon Glass wrote:

 Hi Tom,
 
 As mentioned I reverted this patch as it conflicted with the dm tree
 and I suspect it might be buggy:
 
 cd749658 usb_storage : scan all interfaces to find a storage device
 
 Assuming this is OK and applies successfully I will rebase and resend
 this patch, then reply with some comments I have on the patch.
 
 
 The following changes since commit 4564faeafbf11feb839e2e3f927be2f1a919ba96:
 
   ti: dwc3: Enable clocks in enable_basic_clocks() in hw_data.c
 (2015-04-16 15:08:36 -0400)
 
 are available in the git repository at:
 
   http://git.denx.de/u-boot-dm.git
 
 for you to fetch changes up to 2e6263093b3a5c2d2c586afaedfd346d6628f784:
 
   sandbox: exynos: Move CONFIG_SOUND_SANDBOX to Kconfig (2015-04-16
 20:47:57 -0600)

With this PR, am335x_boneblack (which has DM enabled) no longer
functions.  I'm running a bisect now, but heads up.

-- 
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 01/10] Move board_init_f_mem() into a common location

2015-04-17 Thread Masahiro Yamada
Hi Simon,


2015-04-16 10:14 GMT+09:00 Simon Glass s...@chromium.org:
 This function will be used by both SPL and U-Boot proper. So move it into
 a common place.

 Signed-off-by: Simon Glass s...@chromium.org
 ---

  Makefile  |  1 +
  common/board_f.c  | 22 +-
  common/init/Makefile  |  7 +++
  common/init/global_data.c | 33 +
  scripts/Makefile.spl  |  1 +
  5 files changed, 43 insertions(+), 21 deletions(-)
  create mode 100644 common/init/Makefile
  create mode 100644 common/init/global_data.c

 diff --git a/Makefile b/Makefile
 index 343f416..7f6af72 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -659,6 +659,7 @@ libs-y += drivers/usb/musb-new/
  libs-y += drivers/usb/phy/
  libs-y += drivers/usb/ulpi/
  libs-y += common/
 +libs-y += common/init/
  libs-$(CONFIG_API) += api/
  libs-$(CONFIG_HAS_POST) += post/
  libs-y += test/

[snip]

 diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
 index fcacb7f..60042ea 100644
 --- a/scripts/Makefile.spl
 +++ b/scripts/Makefile.spl
 @@ -51,6 +51,7 @@ HAVE_VENDOR_COMMON_LIB = $(if $(wildcard 
 $(srctree)/board/$(VENDOR)/common/Makef
  libs-y += $(if $(BOARDDIR),board/$(BOARDDIR)/)
  libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/

 +libs-y += common/init/
  libs-$(CONFIG_SPL_FRAMEWORK) += common/spl/
  libs-$(CONFIG_SPL_LIBCOMMON_SUPPORT) += common/
  libs-$(CONFIG_SPL_LIBDISK_SUPPORT) += disk/


Please do not increase the top-level entry any more.

How about adding obj-y += init/ into common/Makefile ?




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


Re: [U-Boot] u-boot for Snow problem

2015-04-17 Thread Simon Glass
Hi Michal,

On 17 April 2015 at 12:49, Michal Suchanek hramr...@gmail.com wrote:
 On 15 April 2015 at 19:01, Michal Suchanek hramr...@gmail.com wrote:
 On 15 April 2015 at 17:00, Simon Glass s...@chromium.org wrote:
 Hi Michal,

 On 14 April 2015 at 16:10, Michal Suchanek hramr...@gmail.com wrote:
 Hello,

 On 4 March 2015 at 00:46, Simon Glass s...@chromium.org wrote:
 Hi Michal,

 On 2 March 2015 at 04:25, Michal Suchanek hramr...@gmail.com wrote:
 Hello,

 On 18 February 2015 at 06:24, Michal Suchanek hramr...@gmail.com wrote:
 On 18 February 2015 at 03:27, Simon Glass s...@chromium.org wrote:
 Hi Michal,

 On 16 February 2015 at 04:41, Michal Suchanek hramr...@gmail.com 
 wrote:
 On 13 February 2015 at 05:51, Simon Glass s...@chromium.org wrote:
 Hi Michal,

 On 11 February 2015 at 10:16, Michal Suchanek hramr...@gmail.com 
 wrote:

 Hello,

 I changed the SYS_START to work around the bug in the manufacturer
 firmware, applied snow_defconfig, built u-boot.bin, packed it into
 kernel uimage, signed it, copied it to a kernel partition, bumped
 priority of the partition, and rebooted.


 Do you mean u-boot-dtb.bin? If not you won't get a device tree and it
 won't work.

 No, u-boot.bin. With u-boot-dtb.bin I get a snow # prompt on the
 built-in LCD, and working keyboard.

 OK sounds like it is working, good! I wonder if we should have a page
 on elinux.org?

 It is working to some extent.

 I managed to load kernel from the emmc which works fine but the kernel
 cannot read the emmc after it boots because it does not properly parse
 the partitioning scheme. This should be trivially fixable in the
 kernel and might actually work if I updated my sources but rebasing
 the extra patches required for Snow is not automatically handled.

 On the other hand, the linux kernel has no problem with the SDXC card
 in the SD slot and can read it just fine. Unfortunately, u-boot
 complains about EFI partition errors and won't load anything from the
 card. I tried two different GPT partitioning tools on the card and
 both say that the partition layout is fine and that I have the default
 128 entries.

 How can I tell why u-boot does not like my GPT label?

 You could debug it in U-Boot and see what is going wrong.


 Apparently the problem is that the dw mmc controller fails and the
 sectors are unreadable. U-boot sometimes reports timeout, sometimes
 data error, and sometimes nothing because the result has already been
 cached probably. And the reason the dw mmc controller fails is that
 port 1 is disabled. Not using disabled controllers would probably
 solve the problem.

 Seems strange. Can you post details of which commit you are building
 and the console output? I could try it too.


 Sorry, I don't have the tree anymore.

 None of my trees has the commit to relocate away from the address
 clobbered by the Snow ro firmware.

 I tried looking again what actually happens but none of the mmc
 commands shows which exact mmc interfaces I have. U-boot somehow picks
 2 of the 4 dwmmc interfaces the Exynos chip has and I suspect the
 second one is picked or multiplexed wrong. The mmc0 to which emmc is
 connected works fine but mmc2 connected to the external slot always
 fails (on Snow mmc1 is unused and mmc3 is WiFi).


 Ok, I did the chainload dance and I am running u-boot master patched
 so it prints the IO address in mmc list and now

 1) both mmc interfaces work
 2) I can see the correct mmc interface is used in mmc list

 So it was broken for whatever reason and is fixed.

OK great. If you have time you could post the details at elinux.org or similar.

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


Re: [U-Boot] u-boot for Snow problem

2015-04-17 Thread Michal Suchanek
On 17 April 2015 at 20:57, Simon Glass s...@chromium.org wrote:
 Hi Michal,

 On 17 April 2015 at 12:49, Michal Suchanek hramr...@gmail.com wrote:


 Ok, I did the chainload dance and I am running u-boot master patched
 so it prints the IO address in mmc list and now

 1) both mmc interfaces work
 2) I can see the correct mmc interface is used in mmc list

 So it was broken for whatever reason and is fixed.

 OK great. If you have time you could post the details at elinux.org or 
 similar.

I have actually written the details here
http://chrodyssey.blogspot.de/ because I always forget how to put the
different guides together.

Thanks

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


Re: [U-Boot] [PATCH v4 7/7] colibri_vf: Enable USB support for Colibri Vybrid

2015-04-17 Thread Marek Vasut
On Friday, April 17, 2015 at 03:26:42 PM, Sanchayan Maity wrote:
 Enable USB support on Toradex Colibri Vybrid Modules.
 
 Signed-off-by: Sanchayan Maity maitysancha...@gmail.com

Acked-by: Marek Vasut ma...@denx.de

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


Re: [U-Boot] Please pull u-boot-dm.git [take 2]

2015-04-17 Thread Hans de Goede

Hi,

On 17-04-15 21:28, Hans de Goede wrote:

Hi,

On 17-04-15 19:53, Tom Rini wrote:

On Fri, Apr 17, 2015 at 10:54:21AM -0600, Simon Glass wrote:

Hi Tom,

On 17 April 2015 at 10:46, Tom Rini tr...@konsulko.com wrote:

On Fri, Apr 17, 2015 at 10:30:36AM -0600, Simon Glass wrote:

Hi Tom,

On 17 April 2015 at 10:27, Tom Rini tr...@konsulko.com wrote:


On Thu, Apr 16, 2015 at 09:15:26PM -0600, Simon Glass wrote:


Hi Tom,

As mentioned I reverted this patch as it conflicted with the dm tree
and I suspect it might be buggy:

cd749658 usb_storage : scan all interfaces to find a storage device

Assuming this is OK and applies successfully I will rebase and resend
this patch, then reply with some comments I have on the patch.


The following changes since commit 4564faeafbf11feb839e2e3f927be2f1a919ba96:

   ti: dwc3: Enable clocks in enable_basic_clocks() in hw_data.c
(2015-04-16 15:08:36 -0400)

are available in the git repository at:

   http://git.denx.de/u-boot-dm.git

for you to fetch changes up to 2e6263093b3a5c2d2c586afaedfd346d6628f784:

   sandbox: exynos: Move CONFIG_SOUND_SANDBOX to Kconfig (2015-04-16
20:47:57 -0600)


With this PR, am335x_boneblack (which has DM enabled) no longer
functions.  I'm running a bisect now, but heads up.


OK, I'll wait for your bisect - also what is the console output when it breaks?


OK, disregard Beaglebone Black error, that was me (need to remember that
eMMC boot only works off of am335x_boneblack_config).  But,
A20-OLinuXino-Lime2_defconfig is broken by this.  The error log:
Command(A20 OLinuXino Lime2 console) on
(user:trini) Power turned on

U-Boot SPL 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45)
DRAM: 1024 MiB
CPU: 91200Hz, AXI/AHB/APB: 3/2/2


U-Boot 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
SCSI:  SUNXI SCSI INIT
SATA link 0 timeout.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst
Net:   dwmac.1c5
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices...
U-Boot SPL 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45)
DRAM: 1024 MiB
CPU: 91200Hz, AXI/AHB/APB: 3/2/2
MMC Device 0 not found
spl: mmc device not found!!
### ERROR ### Please RESET the board ###

And good:
Command(A20 OLinuXino Lime2 console) on
(user:trini) Power turned on

U-Boot SPL 2015.04-00121-g4564fae (Apr 17 2015 - 12:42:40)
DRAM: 1024 MiB
CPU: 91200Hz, AXI/AHB/APB: 3/2/2


U-Boot 2015.04-00121-g4564fae (Apr 17 2015 - 12:42:40) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
SCSI:  SUNXI SCSI INIT
SATA link 0 timeout.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst
Net:   dwmac.1c5
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
USB1:   USB EHCI 1.00
scanning bus 1 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
sunxi#

So... we cause a reset during USB scan and then fail to boot a second
time?


Thanks for testing this.

I'm not sure if I have a Lime (I might do, will need to look). I was
testing sunxi on a pcduino3 but USB does not work on that for reasons
I was looking into (it just says lowlevel init failure due to moving
to driver model for GPIO).

I will take a look. In the meantime, which commit breaks this? I could
perhaps issue a pull for commits up to that point to reduce the load.


I haven't had a chance to bisect yet but I will in a few hours.


No need to, I've just completed a bisect, it points to:

5bca5a6303f3526ab2cf9c0a62cd26c16e0d5c2f is the first bad commit
commit 5bca5a6303f3526ab2cf9c0a62cd26c16e0d5c2f
Author: Simon Glass s...@chromium.org
Date:   Wed Mar 25 12:22:27 2015 -0600

 dm: usb: Drop the EHCI weak functions

 These are a pain with driver model because we might have different EHCI
 drivers which want to implement them differently. Now that they use
 consistent function signatures, we can in good conscience move them to
 a struct.

 Signed-off-by: Simon Glass s...@chromium.org
 Reviewed-by: Marek Vasut ma...@denx.de

I'm going to first spend some time with my family now, I may look into
this later tonight, or otherwise this weekend. I'll be sure to check mail
first to avoid double work, so feel free to fix the problem while I'm
relaxing :)


Ok, so I could not help myself and took a quick look at the patch causing the
issue, this fixes the reset on usb scan problem:

diff --git a/drivers/usb/host/ehci-sunxi.c b/drivers/usb/host/ehci-sunxi.c
index eda9f69..a847ac5 100644
--- 

Re: [U-Boot] Please pull u-boot-dm.git [take 2]

2015-04-17 Thread Hans de Goede

Hi,

On 17-04-15 19:53, Tom Rini wrote:

On Fri, Apr 17, 2015 at 10:54:21AM -0600, Simon Glass wrote:

Hi Tom,

On 17 April 2015 at 10:46, Tom Rini tr...@konsulko.com wrote:

On Fri, Apr 17, 2015 at 10:30:36AM -0600, Simon Glass wrote:

Hi Tom,

On 17 April 2015 at 10:27, Tom Rini tr...@konsulko.com wrote:


On Thu, Apr 16, 2015 at 09:15:26PM -0600, Simon Glass wrote:


Hi Tom,

As mentioned I reverted this patch as it conflicted with the dm tree
and I suspect it might be buggy:

cd749658 usb_storage : scan all interfaces to find a storage device

Assuming this is OK and applies successfully I will rebase and resend
this patch, then reply with some comments I have on the patch.


The following changes since commit 4564faeafbf11feb839e2e3f927be2f1a919ba96:

   ti: dwc3: Enable clocks in enable_basic_clocks() in hw_data.c
(2015-04-16 15:08:36 -0400)

are available in the git repository at:

   http://git.denx.de/u-boot-dm.git

for you to fetch changes up to 2e6263093b3a5c2d2c586afaedfd346d6628f784:

   sandbox: exynos: Move CONFIG_SOUND_SANDBOX to Kconfig (2015-04-16
20:47:57 -0600)


With this PR, am335x_boneblack (which has DM enabled) no longer
functions.  I'm running a bisect now, but heads up.


OK, I'll wait for your bisect - also what is the console output when it breaks?


OK, disregard Beaglebone Black error, that was me (need to remember that
eMMC boot only works off of am335x_boneblack_config).  But,
A20-OLinuXino-Lime2_defconfig is broken by this.  The error log:
Command(A20 OLinuXino Lime2 console) on
(user:trini) Power turned on

U-Boot SPL 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45)
DRAM: 1024 MiB
CPU: 91200Hz, AXI/AHB/APB: 3/2/2


U-Boot 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
SCSI:  SUNXI SCSI INIT
SATA link 0 timeout.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst
Net:   dwmac.1c5
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices...
U-Boot SPL 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45)
DRAM: 1024 MiB
CPU: 91200Hz, AXI/AHB/APB: 3/2/2
MMC Device 0 not found
spl: mmc device not found!!
### ERROR ### Please RESET the board ###

And good:
Command(A20 OLinuXino Lime2 console) on
(user:trini) Power turned on

U-Boot SPL 2015.04-00121-g4564fae (Apr 17 2015 - 12:42:40)
DRAM: 1024 MiB
CPU: 91200Hz, AXI/AHB/APB: 3/2/2


U-Boot 2015.04-00121-g4564fae (Apr 17 2015 - 12:42:40) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
SCSI:  SUNXI SCSI INIT
SATA link 0 timeout.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst
Net:   dwmac.1c5
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
USB1:   USB EHCI 1.00
scanning bus 1 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
sunxi#

So... we cause a reset during USB scan and then fail to boot a second
time?


Thanks for testing this.

I'm not sure if I have a Lime (I might do, will need to look). I was
testing sunxi on a pcduino3 but USB does not work on that for reasons
I was looking into (it just says lowlevel init failure due to moving
to driver model for GPIO).

I will take a look. In the meantime, which commit breaks this? I could
perhaps issue a pull for commits up to that point to reduce the load.


I haven't had a chance to bisect yet but I will in a few hours.


No need to, I've just completed a bisect, it points to:

5bca5a6303f3526ab2cf9c0a62cd26c16e0d5c2f is the first bad commit
commit 5bca5a6303f3526ab2cf9c0a62cd26c16e0d5c2f
Author: Simon Glass s...@chromium.org
Date:   Wed Mar 25 12:22:27 2015 -0600

dm: usb: Drop the EHCI weak functions

These are a pain with driver model because we might have different EHCI
drivers which want to implement them differently. Now that they use
consistent function signatures, we can in good conscience move them to
a struct.

Signed-off-by: Simon Glass s...@chromium.org
Reviewed-by: Marek Vasut ma...@denx.de

I'm going to first spend some time with my family now, I may look into
this later tonight, or otherwise this weekend. I'll be sure to check mail
first to avoid double work, so feel free to fix the problem while I'm
relaxing :)

Regards,

Hans


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


Re: [U-Boot] Please pull u-boot-dm.git [take 2]

2015-04-17 Thread Tom Rini
On Fri, Apr 17, 2015 at 09:28:20PM +0200, Hans de Goede wrote:
 Hi,
 
 On 17-04-15 19:53, Tom Rini wrote:
 On Fri, Apr 17, 2015 at 10:54:21AM -0600, Simon Glass wrote:
 Hi Tom,
 
 On 17 April 2015 at 10:46, Tom Rini tr...@konsulko.com wrote:
 On Fri, Apr 17, 2015 at 10:30:36AM -0600, Simon Glass wrote:
 Hi Tom,
 
 On 17 April 2015 at 10:27, Tom Rini tr...@konsulko.com wrote:
 
 On Thu, Apr 16, 2015 at 09:15:26PM -0600, Simon Glass wrote:
 
 Hi Tom,
 
 As mentioned I reverted this patch as it conflicted with the dm tree
 and I suspect it might be buggy:
 
 cd749658 usb_storage : scan all interfaces to find a storage device
 
 Assuming this is OK and applies successfully I will rebase and resend
 this patch, then reply with some comments I have on the patch.
 
 
 The following changes since commit 
 4564faeafbf11feb839e2e3f927be2f1a919ba96:
 
ti: dwc3: Enable clocks in enable_basic_clocks() in hw_data.c
 (2015-04-16 15:08:36 -0400)
 
 are available in the git repository at:
 
http://git.denx.de/u-boot-dm.git
 
 for you to fetch changes up to 2e6263093b3a5c2d2c586afaedfd346d6628f784:
 
sandbox: exynos: Move CONFIG_SOUND_SANDBOX to Kconfig (2015-04-16
 20:47:57 -0600)
 
 With this PR, am335x_boneblack (which has DM enabled) no longer
 functions.  I'm running a bisect now, but heads up.
 
 OK, I'll wait for your bisect - also what is the console output when it 
 breaks?
 
 OK, disregard Beaglebone Black error, that was me (need to remember that
 eMMC boot only works off of am335x_boneblack_config).  But,
 A20-OLinuXino-Lime2_defconfig is broken by this.  The error log:
 Command(A20 OLinuXino Lime2 console) on
 (user:trini) Power turned on
 
 U-Boot SPL 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45)
 DRAM: 1024 MiB
 CPU: 91200Hz, AXI/AHB/APB: 3/2/2
 
 
 U-Boot 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45) Allwinner Technology
 
 CPU:   Allwinner A20 (SUN7I)
 I2C:   ready
 DRAM:  1 GiB
 MMC:   SUNXI SD/MMC: 0
 *** Warning - bad CRC, using default environment
 
 In:serial
 Out:   serial
 Err:   serial
 SCSI:  SUNXI SCSI INIT
 SATA link 0 timeout.
 AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
 flags: ncq stag pm led clo only pmp pio slum part ccc apst
 Net:   dwmac.1c5
 starting USB...
 USB0:   USB EHCI 1.00
 scanning bus 0 for devices...
 U-Boot SPL 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45)
 DRAM: 1024 MiB
 CPU: 91200Hz, AXI/AHB/APB: 3/2/2
 MMC Device 0 not found
 spl: mmc device not found!!
 ### ERROR ### Please RESET the board ###
 
 And good:
 Command(A20 OLinuXino Lime2 console) on
 (user:trini) Power turned on
 
 U-Boot SPL 2015.04-00121-g4564fae (Apr 17 2015 - 12:42:40)
 DRAM: 1024 MiB
 CPU: 91200Hz, AXI/AHB/APB: 3/2/2
 
 
 U-Boot 2015.04-00121-g4564fae (Apr 17 2015 - 12:42:40) Allwinner Technology
 
 CPU:   Allwinner A20 (SUN7I)
 I2C:   ready
 DRAM:  1 GiB
 MMC:   SUNXI SD/MMC: 0
 *** Warning - bad CRC, using default environment
 
 In:serial
 Out:   serial
 Err:   serial
 SCSI:  SUNXI SCSI INIT
 SATA link 0 timeout.
 AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
 flags: ncq stag pm led clo only pmp pio slum part ccc apst
 Net:   dwmac.1c5
 starting USB...
 USB0:   USB EHCI 1.00
 scanning bus 0 for devices... 1 USB Device(s) found
 USB1:   USB EHCI 1.00
 scanning bus 1 for devices... 1 USB Device(s) found
 scanning usb for storage devices... 0 Storage Device(s) found
 Hit any key to stop autoboot:  0
 sunxi#
 
 So... we cause a reset during USB scan and then fail to boot a second
 time?
 
 Thanks for testing this.
 
 I'm not sure if I have a Lime (I might do, will need to look). I was
 testing sunxi on a pcduino3 but USB does not work on that for reasons
 I was looking into (it just says lowlevel init failure due to moving
 to driver model for GPIO).
 
 I will take a look. In the meantime, which commit breaks this? I could
 perhaps issue a pull for commits up to that point to reduce the load.
 
 I haven't had a chance to bisect yet but I will in a few hours.
 
 No need to, I've just completed a bisect, it points to:
 
 5bca5a6303f3526ab2cf9c0a62cd26c16e0d5c2f is the first bad commit
 commit 5bca5a6303f3526ab2cf9c0a62cd26c16e0d5c2f
 Author: Simon Glass s...@chromium.org
 Date:   Wed Mar 25 12:22:27 2015 -0600
 
 dm: usb: Drop the EHCI weak functions
 
 These are a pain with driver model because we might have different EHCI
 drivers which want to implement them differently. Now that they use
 consistent function signatures, we can in good conscience move them to
 a struct.
 
 Signed-off-by: Simon Glass s...@chromium.org
 Reviewed-by: Marek Vasut ma...@denx.de
 
 I'm going to first spend some time with my family now, I may look into
 this later tonight, or otherwise this weekend. I'll be sure to check mail
 first to avoid double work, so feel free to fix the problem while I'm
 relaxing :)

I was 2/3rds done with the bisect when I saw this (and only about 1/3rd
done when you sent this :)) and I've found 

Re: [U-Boot] [PATCH] dm: usb: Make usb_lowlevel_init set the default ops pointer

2015-04-17 Thread Simon Glass
Hi Tom,

On 17 April 2015 at 14:31, Tom Rini tr...@konsulko.com wrote:
 In order to switch to a set of function pointers for certain operations
 we need to ensure that the defaults are first set so that they can be
 overriden as needed by SoC/board specific code.

 Signed-off-by: Tom Rini tr...@konsulko.com
 ---
  drivers/usb/host/ehci-hcd.c |   10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

 diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
 index 79cf3b3..e7c438c 100644
 --- a/drivers/usb/host/ehci-hcd.c
 +++ b/drivers/usb/host/ehci-hcd.c
 @@ -945,9 +945,7 @@ const struct ehci_ops default_ehci_ops = {

  static void ehci_setup_ops(struct ehci_ctrl *ctrl, const struct ehci_ops 
 *ops)
  {
 -   if (!ops) {
 -   ctrl-ops = default_ehci_ops;
 -   } else {

Do we need to remove this? I think this will break when driver model
is used, if NULL is passed in to select the default ops.

 +   if (ops) {
 ctrl-ops = *ops;
 if (!ctrl-ops.set_usb_mode)
 ctrl-ops.set_usb_mode = ehci_set_usbmode;
 @@ -1095,6 +1093,12 @@ int usb_lowlevel_init(int index, enum usb_init_type 
 init, void **controller)
 uint tweaks = 0;
 int rc;

 +   /**
 +* Set ops to default_ehci_ops, ehci_hcd_init should call
 +* ehci_set_controller_priv to change any of these function pointers.
 +*/
 +   ctrl-ops = default_ehci_ops;
 +

OK what I missed is that lots of things call ehci_hcd_init(). I only
changed a few to call ehci_set_controller_priv().

 rc = ehci_hcd_init(index, init, ctrl-hccr, ctrl-hcor);
 if (rc)
 return rc;
 --
 1.7.9.5


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


[U-Boot] [PATCH] dm: usb: Make usb_lowlevel_init set the default ops pointer

2015-04-17 Thread Tom Rini
In order to switch to a set of function pointers for certain operations
we need to ensure that the defaults are first set so that they can be
overriden as needed by SoC/board specific code.

Signed-off-by: Tom Rini tr...@konsulko.com
---
 drivers/usb/host/ehci-hcd.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 79cf3b3..e7c438c 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -945,9 +945,7 @@ const struct ehci_ops default_ehci_ops = {
 
 static void ehci_setup_ops(struct ehci_ctrl *ctrl, const struct ehci_ops *ops)
 {
-   if (!ops) {
-   ctrl-ops = default_ehci_ops;
-   } else {
+   if (ops) {
ctrl-ops = *ops;
if (!ctrl-ops.set_usb_mode)
ctrl-ops.set_usb_mode = ehci_set_usbmode;
@@ -1095,6 +1093,12 @@ int usb_lowlevel_init(int index, enum usb_init_type 
init, void **controller)
uint tweaks = 0;
int rc;
 
+   /**
+* Set ops to default_ehci_ops, ehci_hcd_init should call
+* ehci_set_controller_priv to change any of these function pointers.
+*/
+   ctrl-ops = default_ehci_ops;
+
rc = ehci_hcd_init(index, init, ctrl-hccr, ctrl-hcor);
if (rc)
return rc;
-- 
1.7.9.5

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


Re: [U-Boot] Please pull u-boot-dm.git [take 2]

2015-04-17 Thread Tom Rini
On Fri, Apr 17, 2015 at 09:39:50PM +0200, Hans de Goede wrote:
 Hi,
 
 On 17-04-15 21:28, Hans de Goede wrote:
 Hi,
 
 On 17-04-15 19:53, Tom Rini wrote:
 On Fri, Apr 17, 2015 at 10:54:21AM -0600, Simon Glass wrote:
 Hi Tom,
 
 On 17 April 2015 at 10:46, Tom Rini tr...@konsulko.com wrote:
 On Fri, Apr 17, 2015 at 10:30:36AM -0600, Simon Glass wrote:
 Hi Tom,
 
 On 17 April 2015 at 10:27, Tom Rini tr...@konsulko.com wrote:
 
 On Thu, Apr 16, 2015 at 09:15:26PM -0600, Simon Glass wrote:
 
 Hi Tom,
 
 As mentioned I reverted this patch as it conflicted with the dm tree
 and I suspect it might be buggy:
 
 cd749658 usb_storage : scan all interfaces to find a storage device
 
 Assuming this is OK and applies successfully I will rebase and resend
 this patch, then reply with some comments I have on the patch.
 
 
 The following changes since commit 
 4564faeafbf11feb839e2e3f927be2f1a919ba96:
 
ti: dwc3: Enable clocks in enable_basic_clocks() in hw_data.c
 (2015-04-16 15:08:36 -0400)
 
 are available in the git repository at:
 
http://git.denx.de/u-boot-dm.git
 
 for you to fetch changes up to 
 2e6263093b3a5c2d2c586afaedfd346d6628f784:
 
sandbox: exynos: Move CONFIG_SOUND_SANDBOX to Kconfig (2015-04-16
 20:47:57 -0600)
 
 With this PR, am335x_boneblack (which has DM enabled) no longer
 functions.  I'm running a bisect now, but heads up.
 
 OK, I'll wait for your bisect - also what is the console output when it 
 breaks?
 
 OK, disregard Beaglebone Black error, that was me (need to remember that
 eMMC boot only works off of am335x_boneblack_config).  But,
 A20-OLinuXino-Lime2_defconfig is broken by this.  The error log:
 Command(A20 OLinuXino Lime2 console) on
 (user:trini) Power turned on
 
 U-Boot SPL 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45)
 DRAM: 1024 MiB
 CPU: 91200Hz, AXI/AHB/APB: 3/2/2
 
 
 U-Boot 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45) Allwinner 
 Technology
 
 CPU:   Allwinner A20 (SUN7I)
 I2C:   ready
 DRAM:  1 GiB
 MMC:   SUNXI SD/MMC: 0
 *** Warning - bad CRC, using default environment
 
 In:serial
 Out:   serial
 Err:   serial
 SCSI:  SUNXI SCSI INIT
 SATA link 0 timeout.
 AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
 flags: ncq stag pm led clo only pmp pio slum part ccc apst
 Net:   dwmac.1c5
 starting USB...
 USB0:   USB EHCI 1.00
 scanning bus 0 for devices...
 U-Boot SPL 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45)
 DRAM: 1024 MiB
 CPU: 91200Hz, AXI/AHB/APB: 3/2/2
 MMC Device 0 not found
 spl: mmc device not found!!
 ### ERROR ### Please RESET the board ###
 
 And good:
 Command(A20 OLinuXino Lime2 console) on
 (user:trini) Power turned on
 
 U-Boot SPL 2015.04-00121-g4564fae (Apr 17 2015 - 12:42:40)
 DRAM: 1024 MiB
 CPU: 91200Hz, AXI/AHB/APB: 3/2/2
 
 
 U-Boot 2015.04-00121-g4564fae (Apr 17 2015 - 12:42:40) Allwinner 
 Technology
 
 CPU:   Allwinner A20 (SUN7I)
 I2C:   ready
 DRAM:  1 GiB
 MMC:   SUNXI SD/MMC: 0
 *** Warning - bad CRC, using default environment
 
 In:serial
 Out:   serial
 Err:   serial
 SCSI:  SUNXI SCSI INIT
 SATA link 0 timeout.
 AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
 flags: ncq stag pm led clo only pmp pio slum part ccc apst
 Net:   dwmac.1c5
 starting USB...
 USB0:   USB EHCI 1.00
 scanning bus 0 for devices... 1 USB Device(s) found
 USB1:   USB EHCI 1.00
 scanning bus 1 for devices... 1 USB Device(s) found
 scanning usb for storage devices... 0 Storage Device(s) found
 Hit any key to stop autoboot:  0
 sunxi#
 
 So... we cause a reset during USB scan and then fail to boot a second
 time?
 
 Thanks for testing this.
 
 I'm not sure if I have a Lime (I might do, will need to look). I was
 testing sunxi on a pcduino3 but USB does not work on that for reasons
 I was looking into (it just says lowlevel init failure due to moving
 to driver model for GPIO).
 
 I will take a look. In the meantime, which commit breaks this? I could
 perhaps issue a pull for commits up to that point to reduce the load.
 
 I haven't had a chance to bisect yet but I will in a few hours.
 
 No need to, I've just completed a bisect, it points to:
 
 5bca5a6303f3526ab2cf9c0a62cd26c16e0d5c2f is the first bad commit
 commit 5bca5a6303f3526ab2cf9c0a62cd26c16e0d5c2f
 Author: Simon Glass s...@chromium.org
 Date:   Wed Mar 25 12:22:27 2015 -0600
 
  dm: usb: Drop the EHCI weak functions
 
  These are a pain with driver model because we might have different EHCI
  drivers which want to implement them differently. Now that they use
  consistent function signatures, we can in good conscience move them to
  a struct.
 
  Signed-off-by: Simon Glass s...@chromium.org
  Reviewed-by: Marek Vasut ma...@denx.de
 
 I'm going to first spend some time with my family now, I may look into
 this later tonight, or otherwise this weekend. I'll be sure to check mail
 first to avoid double work, so feel free to fix the problem while I'm
 relaxing :)
 
 Ok, so I could not help myself and took a quick 

Re: [U-Boot] [PATCH RESEND 1/3] driver/ddr/altera: Add DDR driver for Altera's SDRAM controller

2015-04-17 Thread Pavel Machek
Hi!

  +#define \
  +SDR_CTRLGRP_MPTHRESHOLDRST_0_THRESHOLDRSTCYCLES_31_0_LSB 0
  +#define  \
  +SDR_CTRLGRP_MPTHRESHOLDRST_0_THRESHOLDRSTCYCLES_31_0_MASK \
  +0x
  +/* Register template: sdr::ctrlgrp::mpthresholdrst::mpthresholdrst_1  
   */
  +#define \
  +SDR_CTRLGRP_MPTHRESHOLDRST_1_THRESHOLDRSTCYCLES_63_32_LSB 0
  +#define \
  +SDR_CTRLGRP_MPTHRESHOLDRST_1_THRESHOLDRSTCYCLES_63_32_MASK \
  +0x
  +/* Register template: sdr::ctrlgrp::mpthresholdrst::mpthresholdrst_2  
   */
  +#define \
  +SDR_CTRLGRP_MPTHRESHOLDRST_2_THRESHOLDRSTCYCLES_79_64_LSB 0
  +#define \
  +SDR_CTRLGRP_MPTHRESHOLDRST_2_THRESHOLDRSTCYCLES_79_64_MASK \
  +0x
  
  Can we get slightly shorter define names?
 
 I did think about shortening these defines a bit, but came to this
 reason that I should leave these alone. These defines are generated from
 the tools AFAICT. I don't think any sane person would try to have
 defines this long. So I still want to try to save the use case that the
 driver can still be used with the autogenerated header file from the
 tools in some form.

Ok.

[I'd suggest placing the defines on single lines, ignoring 80 column
rule, but then checkpatch would scream, so I guess it is ok as it is.]

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] Please pull u-boot-dm.git [take 2]

2015-04-17 Thread Tom Rini
On Fri, Apr 17, 2015 at 09:39:50PM +0200, Hans de Goede wrote:
 Hi,
 
 On 17-04-15 21:28, Hans de Goede wrote:
 Hi,
 
 On 17-04-15 19:53, Tom Rini wrote:
 On Fri, Apr 17, 2015 at 10:54:21AM -0600, Simon Glass wrote:
 Hi Tom,
 
 On 17 April 2015 at 10:46, Tom Rini tr...@konsulko.com wrote:
 On Fri, Apr 17, 2015 at 10:30:36AM -0600, Simon Glass wrote:
 Hi Tom,
 
 On 17 April 2015 at 10:27, Tom Rini tr...@konsulko.com wrote:
 
 On Thu, Apr 16, 2015 at 09:15:26PM -0600, Simon Glass wrote:
 
 Hi Tom,
 
 As mentioned I reverted this patch as it conflicted with the dm tree
 and I suspect it might be buggy:
 
 cd749658 usb_storage : scan all interfaces to find a storage device
 
 Assuming this is OK and applies successfully I will rebase and resend
 this patch, then reply with some comments I have on the patch.
 
 
 The following changes since commit 
 4564faeafbf11feb839e2e3f927be2f1a919ba96:
 
ti: dwc3: Enable clocks in enable_basic_clocks() in hw_data.c
 (2015-04-16 15:08:36 -0400)
 
 are available in the git repository at:
 
http://git.denx.de/u-boot-dm.git
 
 for you to fetch changes up to 
 2e6263093b3a5c2d2c586afaedfd346d6628f784:
 
sandbox: exynos: Move CONFIG_SOUND_SANDBOX to Kconfig (2015-04-16
 20:47:57 -0600)
 
 With this PR, am335x_boneblack (which has DM enabled) no longer
 functions.  I'm running a bisect now, but heads up.
 
 OK, I'll wait for your bisect - also what is the console output when it 
 breaks?
 
 OK, disregard Beaglebone Black error, that was me (need to remember that
 eMMC boot only works off of am335x_boneblack_config).  But,
 A20-OLinuXino-Lime2_defconfig is broken by this.  The error log:
 Command(A20 OLinuXino Lime2 console) on
 (user:trini) Power turned on
 
 U-Boot SPL 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45)
 DRAM: 1024 MiB
 CPU: 91200Hz, AXI/AHB/APB: 3/2/2
 
 
 U-Boot 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45) Allwinner 
 Technology
 
 CPU:   Allwinner A20 (SUN7I)
 I2C:   ready
 DRAM:  1 GiB
 MMC:   SUNXI SD/MMC: 0
 *** Warning - bad CRC, using default environment
 
 In:serial
 Out:   serial
 Err:   serial
 SCSI:  SUNXI SCSI INIT
 SATA link 0 timeout.
 AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
 flags: ncq stag pm led clo only pmp pio slum part ccc apst
 Net:   dwmac.1c5
 starting USB...
 USB0:   USB EHCI 1.00
 scanning bus 0 for devices...
 U-Boot SPL 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45)
 DRAM: 1024 MiB
 CPU: 91200Hz, AXI/AHB/APB: 3/2/2
 MMC Device 0 not found
 spl: mmc device not found!!
 ### ERROR ### Please RESET the board ###
 
 And good:
 Command(A20 OLinuXino Lime2 console) on
 (user:trini) Power turned on
 
 U-Boot SPL 2015.04-00121-g4564fae (Apr 17 2015 - 12:42:40)
 DRAM: 1024 MiB
 CPU: 91200Hz, AXI/AHB/APB: 3/2/2
 
 
 U-Boot 2015.04-00121-g4564fae (Apr 17 2015 - 12:42:40) Allwinner 
 Technology
 
 CPU:   Allwinner A20 (SUN7I)
 I2C:   ready
 DRAM:  1 GiB
 MMC:   SUNXI SD/MMC: 0
 *** Warning - bad CRC, using default environment
 
 In:serial
 Out:   serial
 Err:   serial
 SCSI:  SUNXI SCSI INIT
 SATA link 0 timeout.
 AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
 flags: ncq stag pm led clo only pmp pio slum part ccc apst
 Net:   dwmac.1c5
 starting USB...
 USB0:   USB EHCI 1.00
 scanning bus 0 for devices... 1 USB Device(s) found
 USB1:   USB EHCI 1.00
 scanning bus 1 for devices... 1 USB Device(s) found
 scanning usb for storage devices... 0 Storage Device(s) found
 Hit any key to stop autoboot:  0
 sunxi#
 
 So... we cause a reset during USB scan and then fail to boot a second
 time?
 
 Thanks for testing this.
 
 I'm not sure if I have a Lime (I might do, will need to look). I was
 testing sunxi on a pcduino3 but USB does not work on that for reasons
 I was looking into (it just says lowlevel init failure due to moving
 to driver model for GPIO).
 
 I will take a look. In the meantime, which commit breaks this? I could
 perhaps issue a pull for commits up to that point to reduce the load.
 
 I haven't had a chance to bisect yet but I will in a few hours.
 
 No need to, I've just completed a bisect, it points to:
 
 5bca5a6303f3526ab2cf9c0a62cd26c16e0d5c2f is the first bad commit
 commit 5bca5a6303f3526ab2cf9c0a62cd26c16e0d5c2f
 Author: Simon Glass s...@chromium.org
 Date:   Wed Mar 25 12:22:27 2015 -0600
 
  dm: usb: Drop the EHCI weak functions
 
  These are a pain with driver model because we might have different EHCI
  drivers which want to implement them differently. Now that they use
  consistent function signatures, we can in good conscience move them to
  a struct.
 
  Signed-off-by: Simon Glass s...@chromium.org
  Reviewed-by: Marek Vasut ma...@denx.de
 
 I'm going to first spend some time with my family now, I may look into
 this later tonight, or otherwise this weekend. I'll be sure to check mail
 first to avoid double work, so feel free to fix the problem while I'm
 relaxing :)
 
 Ok, so I could not help myself and took a quick 

Re: [U-Boot] Please pull u-boot-dm.git [take 2]

2015-04-17 Thread Simon Glass
Hi Tom,

On 17 April 2015 at 15:13, Tom Rini tr...@konsulko.com wrote:

 On Fri, Apr 17, 2015 at 09:39:50PM +0200, Hans de Goede wrote:
  Hi,
 
  On 17-04-15 21:28, Hans de Goede wrote:
  Hi,
  
  On 17-04-15 19:53, Tom Rini wrote:
  On Fri, Apr 17, 2015 at 10:54:21AM -0600, Simon Glass wrote:
  Hi Tom,
  
  On 17 April 2015 at 10:46, Tom Rini tr...@konsulko.com wrote:
  On Fri, Apr 17, 2015 at 10:30:36AM -0600, Simon Glass wrote:
  Hi Tom,
  
  On 17 April 2015 at 10:27, Tom Rini tr...@konsulko.com wrote:
  
  On Thu, Apr 16, 2015 at 09:15:26PM -0600, Simon Glass wrote:
  
  Hi Tom,
  
  As mentioned I reverted this patch as it conflicted with the dm tree
  and I suspect it might be buggy:
  
  cd749658 usb_storage : scan all interfaces to find a storage device
  
  Assuming this is OK and applies successfully I will rebase and resend
  this patch, then reply with some comments I have on the patch.
  
  
  The following changes since commit 
  4564faeafbf11feb839e2e3f927be2f1a919ba96:
  
 ti: dwc3: Enable clocks in enable_basic_clocks() in hw_data.c
  (2015-04-16 15:08:36 -0400)
  
  are available in the git repository at:
  
 http://git.denx.de/u-boot-dm.git
  
  for you to fetch changes up to 
  2e6263093b3a5c2d2c586afaedfd346d6628f784:
  
 sandbox: exynos: Move CONFIG_SOUND_SANDBOX to Kconfig (2015-04-16
  20:47:57 -0600)
  
  With this PR, am335x_boneblack (which has DM enabled) no longer
  functions.  I'm running a bisect now, but heads up.
  
  OK, I'll wait for your bisect - also what is the console output when 
  it breaks?
  
  OK, disregard Beaglebone Black error, that was me (need to remember that
  eMMC boot only works off of am335x_boneblack_config).  But,
  A20-OLinuXino-Lime2_defconfig is broken by this.  The error log:
  Command(A20 OLinuXino Lime2 console) on
  (user:trini) Power turned on
  
  U-Boot SPL 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45)
  DRAM: 1024 MiB
  CPU: 91200Hz, AXI/AHB/APB: 3/2/2
  
  
  U-Boot 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45) Allwinner 
  Technology
  
  CPU:   Allwinner A20 (SUN7I)
  I2C:   ready
  DRAM:  1 GiB
  MMC:   SUNXI SD/MMC: 0
  *** Warning - bad CRC, using default environment
  
  In:serial
  Out:   serial
  Err:   serial
  SCSI:  SUNXI SCSI INIT
  SATA link 0 timeout.
  AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
  flags: ncq stag pm led clo only pmp pio slum part ccc apst
  Net:   dwmac.1c5
  starting USB...
  USB0:   USB EHCI 1.00
  scanning bus 0 for devices...
  U-Boot SPL 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45)
  DRAM: 1024 MiB
  CPU: 91200Hz, AXI/AHB/APB: 3/2/2
  MMC Device 0 not found
  spl: mmc device not found!!
  ### ERROR ### Please RESET the board ###
  
  And good:
  Command(A20 OLinuXino Lime2 console) on
  (user:trini) Power turned on
  
  U-Boot SPL 2015.04-00121-g4564fae (Apr 17 2015 - 12:42:40)
  DRAM: 1024 MiB
  CPU: 91200Hz, AXI/AHB/APB: 3/2/2
  
  
  U-Boot 2015.04-00121-g4564fae (Apr 17 2015 - 12:42:40) Allwinner 
  Technology
  
  CPU:   Allwinner A20 (SUN7I)
  I2C:   ready
  DRAM:  1 GiB
  MMC:   SUNXI SD/MMC: 0
  *** Warning - bad CRC, using default environment
  
  In:serial
  Out:   serial
  Err:   serial
  SCSI:  SUNXI SCSI INIT
  SATA link 0 timeout.
  AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
  flags: ncq stag pm led clo only pmp pio slum part ccc apst
  Net:   dwmac.1c5
  starting USB...
  USB0:   USB EHCI 1.00
  scanning bus 0 for devices... 1 USB Device(s) found
  USB1:   USB EHCI 1.00
  scanning bus 1 for devices... 1 USB Device(s) found
  scanning usb for storage devices... 0 Storage Device(s) found
  Hit any key to stop autoboot:  0
  sunxi#
  
  So... we cause a reset during USB scan and then fail to boot a second
  time?
  
  Thanks for testing this.
  
  I'm not sure if I have a Lime (I might do, will need to look). I was
  testing sunxi on a pcduino3 but USB does not work on that for reasons
  I was looking into (it just says lowlevel init failure due to moving
  to driver model for GPIO).
  
  I will take a look. In the meantime, which commit breaks this? I could
  perhaps issue a pull for commits up to that point to reduce the load.
  
  I haven't had a chance to bisect yet but I will in a few hours.
  
  No need to, I've just completed a bisect, it points to:
  
  5bca5a6303f3526ab2cf9c0a62cd26c16e0d5c2f is the first bad commit
  commit 5bca5a6303f3526ab2cf9c0a62cd26c16e0d5c2f
  Author: Simon Glass s...@chromium.org
  Date:   Wed Mar 25 12:22:27 2015 -0600
  
   dm: usb: Drop the EHCI weak functions
  
   These are a pain with driver model because we might have different 
   EHCI
   drivers which want to implement them differently. Now that they use
   consistent function signatures, we can in good conscience move them to
   a struct.
  
   Signed-off-by: Simon Glass s...@chromium.org
   Reviewed-by: Marek Vasut ma...@denx.de
  
  I'm going to first spend some time with my family 

Re: [U-Boot] [PATCH] dm: usb: Make usb_lowlevel_init set the default ops pointer

2015-04-17 Thread Tom Rini
On Fri, Apr 17, 2015 at 03:28:30PM -0600, Simon Glass wrote:
 Hi Tom,
 
 On 17 April 2015 at 14:31, Tom Rini tr...@konsulko.com wrote:
  In order to switch to a set of function pointers for certain operations
  we need to ensure that the defaults are first set so that they can be
  overriden as needed by SoC/board specific code.
 
  Signed-off-by: Tom Rini tr...@konsulko.com
  ---
   drivers/usb/host/ehci-hcd.c |   10 +++---
   1 file changed, 7 insertions(+), 3 deletions(-)
 
  diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
  index 79cf3b3..e7c438c 100644
  --- a/drivers/usb/host/ehci-hcd.c
  +++ b/drivers/usb/host/ehci-hcd.c
  @@ -945,9 +945,7 @@ const struct ehci_ops default_ehci_ops = {
 
   static void ehci_setup_ops(struct ehci_ctrl *ctrl, const struct ehci_ops 
  *ops)
   {
  -   if (!ops) {
  -   ctrl-ops = default_ehci_ops;
  -   } else {
 
 Do we need to remove this? I think this will break when driver model
 is used, if NULL is passed in to select the default ops.

Nope, just cleaning up the code as-is.

  +   if (ops) {
  ctrl-ops = *ops;
  if (!ctrl-ops.set_usb_mode)
  ctrl-ops.set_usb_mode = ehci_set_usbmode;
  @@ -1095,6 +1093,12 @@ int usb_lowlevel_init(int index, enum usb_init_type 
  init, void **controller)
  uint tweaks = 0;
  int rc;
 
  +   /**
  +* Set ops to default_ehci_ops, ehci_hcd_init should call
  +* ehci_set_controller_priv to change any of these function 
  pointers.
  +*/
  +   ctrl-ops = default_ehci_ops;
  +
 
 OK what I missed is that lots of things call ehci_hcd_init(). I only
 changed a few to call ehci_set_controller_priv().

Yes, you changed the ehci_hcd_init()'s that need to call
ehci_set_controller_priv() to either set a priv or now to set the ops
pointer.  Most need neither so I think this is the right solution.

-- 
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 01/10] Move board_init_f_mem() into a common location

2015-04-17 Thread Simon Glass
Hi Masahiro,

On 17 April 2015 at 10:37, Masahiro Yamada
yamada.masah...@socionext.com wrote:
 Hi Simon,


 2015-04-16 10:14 GMT+09:00 Simon Glass s...@chromium.org:
 This function will be used by both SPL and U-Boot proper. So move it into
 a common place.

 Signed-off-by: Simon Glass s...@chromium.org
 ---

  Makefile  |  1 +
  common/board_f.c  | 22 +-
  common/init/Makefile  |  7 +++
  common/init/global_data.c | 33 +
  scripts/Makefile.spl  |  1 +
  5 files changed, 43 insertions(+), 21 deletions(-)
  create mode 100644 common/init/Makefile
  create mode 100644 common/init/global_data.c

 diff --git a/Makefile b/Makefile
 index 343f416..7f6af72 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -659,6 +659,7 @@ libs-y += drivers/usb/musb-new/
  libs-y += drivers/usb/phy/
  libs-y += drivers/usb/ulpi/
  libs-y += common/
 +libs-y += common/init/
  libs-$(CONFIG_API) += api/
  libs-$(CONFIG_HAS_POST) += post/
  libs-y += test/

 [snip]

 diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
 index fcacb7f..60042ea 100644
 --- a/scripts/Makefile.spl
 +++ b/scripts/Makefile.spl
 @@ -51,6 +51,7 @@ HAVE_VENDOR_COMMON_LIB = $(if $(wildcard 
 $(srctree)/board/$(VENDOR)/common/Makef
  libs-y += $(if $(BOARDDIR),board/$(BOARDDIR)/)
  libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/

 +libs-y += common/init/
  libs-$(CONFIG_SPL_FRAMEWORK) += common/spl/
  libs-$(CONFIG_SPL_LIBCOMMON_SUPPORT) += common/
  libs-$(CONFIG_SPL_LIBDISK_SUPPORT) += disk/


 Please do not increase the top-level entry any more.

 How about adding obj-y += init/ into common/Makefile ?

The problem I had was that common/ is not included for SPL unless you
enable CONFIG_SPL_LIBCOMMON_SUPPORT. Is there another way?

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


Re: [U-Boot] [PATCH] dm: usb: Make usb_lowlevel_init set the default ops pointer

2015-04-17 Thread Simon Glass
Hi Tom.

On 17 April 2015 at 16:02, Tom Rini tr...@konsulko.com wrote:
 On Fri, Apr 17, 2015 at 03:28:30PM -0600, Simon Glass wrote:
 Hi Tom,

 On 17 April 2015 at 14:31, Tom Rini tr...@konsulko.com wrote:
  In order to switch to a set of function pointers for certain operations
  we need to ensure that the defaults are first set so that they can be
  overriden as needed by SoC/board specific code.
 
  Signed-off-by: Tom Rini tr...@konsulko.com
  ---
   drivers/usb/host/ehci-hcd.c |   10 +++---
   1 file changed, 7 insertions(+), 3 deletions(-)
 
  diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
  index 79cf3b3..e7c438c 100644
  --- a/drivers/usb/host/ehci-hcd.c
  +++ b/drivers/usb/host/ehci-hcd.c
  @@ -945,9 +945,7 @@ const struct ehci_ops default_ehci_ops = {
 
   static void ehci_setup_ops(struct ehci_ctrl *ctrl, const struct ehci_ops 
  *ops)
   {
  -   if (!ops) {
  -   ctrl-ops = default_ehci_ops;
  -   } else {

 Do we need to remove this? I think this will break when driver model
 is used, if NULL is passed in to select the default ops.

 Nope, just cleaning up the code as-is.

I'm missing something though. For ehci_register() it calls this will
ops possibly equal to NULL, expecting it to set up the ops.


  +   if (ops) {
  ctrl-ops = *ops;
  if (!ctrl-ops.set_usb_mode)
  ctrl-ops.set_usb_mode = ehci_set_usbmode;
  @@ -1095,6 +1093,12 @@ int usb_lowlevel_init(int index, enum usb_init_type 
  init, void **controller)
  uint tweaks = 0;
  int rc;
 
  +   /**
  +* Set ops to default_ehci_ops, ehci_hcd_init should call
  +* ehci_set_controller_priv to change any of these function 
  pointers.
  +*/
  +   ctrl-ops = default_ehci_ops;
  +

 OK what I missed is that lots of things call ehci_hcd_init(). I only
 changed a few to call ehci_set_controller_priv().

 Yes, you changed the ehci_hcd_init()'s that need to call
 ehci_set_controller_priv() to either set a priv or now to set the ops
 pointer.  Most need neither so I think this is the right solution.

Sounds good.


 --
 Tom

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


Re: [U-Boot] [PATCH] dm: usb: Make usb_lowlevel_init set the default ops pointer

2015-04-17 Thread Tom Rini
On Fri, Apr 17, 2015 at 04:38:19PM -0600, Simon Glass wrote:
 Hi Tom.
 
 On 17 April 2015 at 16:02, Tom Rini tr...@konsulko.com wrote:
  On Fri, Apr 17, 2015 at 03:28:30PM -0600, Simon Glass wrote:
  Hi Tom,
 
  On 17 April 2015 at 14:31, Tom Rini tr...@konsulko.com wrote:
   In order to switch to a set of function pointers for certain operations
   we need to ensure that the defaults are first set so that they can be
   overriden as needed by SoC/board specific code.
  
   Signed-off-by: Tom Rini tr...@konsulko.com
   ---
drivers/usb/host/ehci-hcd.c |   10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
  
   diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
   index 79cf3b3..e7c438c 100644
   --- a/drivers/usb/host/ehci-hcd.c
   +++ b/drivers/usb/host/ehci-hcd.c
   @@ -945,9 +945,7 @@ const struct ehci_ops default_ehci_ops = {
  
static void ehci_setup_ops(struct ehci_ctrl *ctrl, const struct 
   ehci_ops *ops)
{
   -   if (!ops) {
   -   ctrl-ops = default_ehci_ops;
   -   } else {
 
  Do we need to remove this? I think this will break when driver model
  is used, if NULL is passed in to select the default ops.
 
  Nope, just cleaning up the code as-is.
 
 I'm missing something though. For ehci_register() it calls this will
 ops possibly equal to NULL, expecting it to set up the ops.

OK, I missed a case too then, drop this hunk when you squash it in :)

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


Re: [U-Boot] Clock tree in U-Boot

2015-04-17 Thread Simon Glass
Hi Eric,

On 17 April 2015 at 10:12, Eric Nelson eric.nel...@boundarydevices.com wrote:
 Hi all,

 Heiko's recent patch set [1] to control the LDB clock on i.MX5/6 boards
 makes it painfully obvious that some semblance of clock tree is needed,
 even if it starts off as a shell.

 We currently have routines declared in [2] that should be moved into
 a more common spot:

 void clk_enable(struct clk *clk);
 void clk_disable(struct clk *clk);
 u32 clk_get_rate(struct clk *clk);
 int clk_set_rate(struct clk *clk, unsigned long rate);
 long clk_round_rate(struct clk *clk, unsigned long rate);
 int clk_set_parent(struct clk *clk, struct clk *parent);
 int clk_get_usecount(struct clk *clk);
 struct clk *clk_get_parent(struct clk *clk);

 Can we get some agreement on a proper subset of [3] that's appropriate
 for use in U-Boot?

 My thought is that the list above, plus some form of clk_get() and/or
 clk_get_sys() would be a good start.

 Please advise,

I'd like to see this. It should use driver model I think. The above
list looks good to me.

For clk_get(), we could support claiming of clocks so we know when we
can turn off its parent / automatically enable it / etc. But perhaps
as a first step just implementing a uclass and a driver for one device
would be a good start.



 Eric

 [1] http://lists.denx.de/pipermail/u-boot/2015-April/thread.html#210677
 [2] http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/video/ipu.h#l245
 [3]
 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/clk.h?id=refs/tags/v4.0

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


Re: [U-Boot] [PATCH 01/10] Move board_init_f_mem() into a common location

2015-04-17 Thread Simon Glass
Hi Jeroen,

On 16 April 2015 at 03:32, Jeroen Hofstee jer...@myspectrum.nl wrote:
 Hello Simon,

 On 16-04-15 03:14, Simon Glass wrote:

 +
 +DECLARE_GLOBAL_DATA_PTR;
 +
 +ulong board_init_f_mem(ulong top)
 +{
 +   /* TODO(s...@chromium.org): Figure out how x86 can use this */
 +#ifndef CONFIG_X86
 +   /* Leave space for the stack we are running with now */
 +   top -= 0x40;
 +
 +   top -= sizeof(struct global_data);
 +   top = ALIGN(top, 16);
 +   gd = (struct global_data *)top;
 +   memset((void *)gd, '\0', sizeof(*gd));
 +


 Above piece of code is on my TODO list as well. Like x86, clang cannot
 directly assign gd. What I still need to check is why this reassignment is
 needed in the first place. Typically, at least for ARM, allocating an
 initial
 gd in _main and copying it over in relocate suffices for common boards.

 This doesn't work if there is a valid use case for needing gd before calling
 main, but I am not aware of any (but haven't found time to google for any
 as well, so it doesn't mean there isn't any).

 That said, if there is valid reason to reassign gd, clang could do that if
 there
 was a macro e.g. set_gd(new_gd) instead of a direct assignment. Since this
 is a
 cross arch patchset, that might be something to consider (and likely solves
 the
 Figure out how x86 can use this as well).

Yes. I'm fiddling with x86 again so may figure something out here for v2.

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


Re: [U-Boot] [PATCH] dm: usb: Make usb_lowlevel_init set the default ops pointer

2015-04-17 Thread Tom Rini
On Fri, Apr 17, 2015 at 04:45:18PM -0600, Simon Glass wrote:
 Hi Tom,
 
 On 17 April 2015 at 16:43, Tom Rini tr...@konsulko.com wrote:
  On Fri, Apr 17, 2015 at 04:38:19PM -0600, Simon Glass wrote:
  Hi Tom.
 
  On 17 April 2015 at 16:02, Tom Rini tr...@konsulko.com wrote:
   On Fri, Apr 17, 2015 at 03:28:30PM -0600, Simon Glass wrote:
   Hi Tom,
  
   On 17 April 2015 at 14:31, Tom Rini tr...@konsulko.com wrote:
In order to switch to a set of function pointers for certain 
operations
we need to ensure that the defaults are first set so that they can be
overriden as needed by SoC/board specific code.
   
Signed-off-by: Tom Rini tr...@konsulko.com
---
 drivers/usb/host/ehci-hcd.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)
   
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 79cf3b3..e7c438c 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -945,9 +945,7 @@ const struct ehci_ops default_ehci_ops = {
   
 static void ehci_setup_ops(struct ehci_ctrl *ctrl, const struct 
ehci_ops *ops)
 {
-   if (!ops) {
-   ctrl-ops = default_ehci_ops;
-   } else {
  
   Do we need to remove this? I think this will break when driver model
   is used, if NULL is passed in to select the default ops.
  
   Nope, just cleaning up the code as-is.
 
  I'm missing something though. For ehci_register() it calls this will
  ops possibly equal to NULL, expecting it to set up the ops.
 
  OK, I missed a case too then, drop this hunk when you squash it in :)
 
 Will do. My plan is:
 
 - pull in this patch
 - figure out what else broke with the keyboard since my terrible
 conflict resolution attempt
 
 Anything else?

Fix anything else that's broken? ;)  That's all I've noticed but if you
can do some usb card reader + hub on both a DM and non-DM board that'd
probably cover most cases along with keyboard testing.

-- 
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] dm: usb: Make usb_lowlevel_init set the default ops pointer

2015-04-17 Thread Simon Glass
Hi Tom,

On 17 April 2015 at 16:43, Tom Rini tr...@konsulko.com wrote:
 On Fri, Apr 17, 2015 at 04:38:19PM -0600, Simon Glass wrote:
 Hi Tom.

 On 17 April 2015 at 16:02, Tom Rini tr...@konsulko.com wrote:
  On Fri, Apr 17, 2015 at 03:28:30PM -0600, Simon Glass wrote:
  Hi Tom,
 
  On 17 April 2015 at 14:31, Tom Rini tr...@konsulko.com wrote:
   In order to switch to a set of function pointers for certain operations
   we need to ensure that the defaults are first set so that they can be
   overriden as needed by SoC/board specific code.
  
   Signed-off-by: Tom Rini tr...@konsulko.com
   ---
drivers/usb/host/ehci-hcd.c |   10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
  
   diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
   index 79cf3b3..e7c438c 100644
   --- a/drivers/usb/host/ehci-hcd.c
   +++ b/drivers/usb/host/ehci-hcd.c
   @@ -945,9 +945,7 @@ const struct ehci_ops default_ehci_ops = {
  
static void ehci_setup_ops(struct ehci_ctrl *ctrl, const struct 
   ehci_ops *ops)
{
   -   if (!ops) {
   -   ctrl-ops = default_ehci_ops;
   -   } else {
 
  Do we need to remove this? I think this will break when driver model
  is used, if NULL is passed in to select the default ops.
 
  Nope, just cleaning up the code as-is.

 I'm missing something though. For ehci_register() it calls this will
 ops possibly equal to NULL, expecting it to set up the ops.

 OK, I missed a case too then, drop this hunk when you squash it in :)

Will do. My plan is:

- pull in this patch
- figure out what else broke with the keyboard since my terrible
conflict resolution attempt

Anything else?

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


[U-Boot] [PATCH] powerpc/mpc85xx: Don't deref NULL if qman portal lacks cell-index

2015-04-17 Thread Scott Wood
Signed-off-by: Scott Wood scottw...@freescale.com
Cc: Madalin-Cristian Bucur madalin.bu...@freescale.com
---
 arch/powerpc/cpu/mpc85xx/portals.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/portals.c 
b/arch/powerpc/cpu/mpc85xx/portals.c
index ec3b292..3777c6f 100644
--- a/arch/powerpc/cpu/mpc85xx/portals.c
+++ b/arch/powerpc/cpu/mpc85xx/portals.c
@@ -249,8 +249,13 @@ void fdt_fixup_qportals(void *blob)
 #ifdef CONFIG_FSL_CORENET
u32 liodns[2];
 #endif
-   const int *ci = fdt_getprop(blob, off, cell-index, NULL);
-   int i = *ci;
+   const int *ci = fdt_getprop(blob, off, cell-index, err);
+   int i;
+
+   if (!ci)
+   goto err;
+
+   i = *ci;
 #ifdef CONFIG_SYS_DPAA_FMAN
int j;
 #endif
-- 
2.1.0

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


Re: [U-Boot] Please pull u-boot-dm.git [take 2]

2015-04-17 Thread Tom Rini
On Fri, Apr 17, 2015 at 10:30:36AM -0600, Simon Glass wrote:
 Hi Tom,
 
 On 17 April 2015 at 10:27, Tom Rini tr...@konsulko.com wrote:
 
  On Thu, Apr 16, 2015 at 09:15:26PM -0600, Simon Glass wrote:
 
   Hi Tom,
  
   As mentioned I reverted this patch as it conflicted with the dm tree
   and I suspect it might be buggy:
  
   cd749658 usb_storage : scan all interfaces to find a storage device
  
   Assuming this is OK and applies successfully I will rebase and resend
   this patch, then reply with some comments I have on the patch.
  
  
   The following changes since commit 
   4564faeafbf11feb839e2e3f927be2f1a919ba96:
  
 ti: dwc3: Enable clocks in enable_basic_clocks() in hw_data.c
   (2015-04-16 15:08:36 -0400)
  
   are available in the git repository at:
  
 http://git.denx.de/u-boot-dm.git
  
   for you to fetch changes up to 2e6263093b3a5c2d2c586afaedfd346d6628f784:
  
 sandbox: exynos: Move CONFIG_SOUND_SANDBOX to Kconfig (2015-04-16
   20:47:57 -0600)
 
  With this PR, am335x_boneblack (which has DM enabled) no longer
  functions.  I'm running a bisect now, but heads up.
 
 OK, I'll wait for your bisect - also what is the console output when it 
 breaks?

OK, disregard Beaglebone Black error, that was me (need to remember that
eMMC boot only works off of am335x_boneblack_config).  But,
A20-OLinuXino-Lime2_defconfig is broken by this.  The error log:
Command(A20 OLinuXino Lime2 console) on
(user:trini) Power turned on

U-Boot SPL 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45)
DRAM: 1024 MiB
CPU: 91200Hz, AXI/AHB/APB: 3/2/2


U-Boot 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
SCSI:  SUNXI SCSI INIT
SATA link 0 timeout.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst 
Net:   dwmac.1c5
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 
U-Boot SPL 2015.04-00342-g2e62630 (Apr 17 2015 - 12:40:45)
DRAM: 1024 MiB
CPU: 91200Hz, AXI/AHB/APB: 3/2/2
MMC Device 0 not found
spl: mmc device not found!!
### ERROR ### Please RESET the board ###

And good:
Command(A20 OLinuXino Lime2 console) on
(user:trini) Power turned on

U-Boot SPL 2015.04-00121-g4564fae (Apr 17 2015 - 12:42:40)
DRAM: 1024 MiB
CPU: 91200Hz, AXI/AHB/APB: 3/2/2


U-Boot 2015.04-00121-g4564fae (Apr 17 2015 - 12:42:40) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
SCSI:  SUNXI SCSI INIT
SATA link 0 timeout.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst 
Net:   dwmac.1c5
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
USB1:   USB EHCI 1.00
scanning bus 1 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0 
sunxi#

So... we cause a reset during USB scan and then fail to boot a second
time?

-- 
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] Please pull u-boot-dm.git [take 2]

2015-04-17 Thread Simon Glass
Hi Tom,

On 17 April 2015 at 10:27, Tom Rini tr...@konsulko.com wrote:

 On Thu, Apr 16, 2015 at 09:15:26PM -0600, Simon Glass wrote:

  Hi Tom,
 
  As mentioned I reverted this patch as it conflicted with the dm tree
  and I suspect it might be buggy:
 
  cd749658 usb_storage : scan all interfaces to find a storage device
 
  Assuming this is OK and applies successfully I will rebase and resend
  this patch, then reply with some comments I have on the patch.
 
 
  The following changes since commit 4564faeafbf11feb839e2e3f927be2f1a919ba96:
 
ti: dwc3: Enable clocks in enable_basic_clocks() in hw_data.c
  (2015-04-16 15:08:36 -0400)
 
  are available in the git repository at:
 
http://git.denx.de/u-boot-dm.git
 
  for you to fetch changes up to 2e6263093b3a5c2d2c586afaedfd346d6628f784:
 
sandbox: exynos: Move CONFIG_SOUND_SANDBOX to Kconfig (2015-04-16
  20:47:57 -0600)

 With this PR, am335x_boneblack (which has DM enabled) no longer
 functions.  I'm running a bisect now, but heads up.

OK, I'll wait for your bisect - also what is the console output when it breaks?

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


Re: [U-Boot] [PATCH v3] usb_storage : scan all interfaces to find a storage device

2015-04-17 Thread Franck Jullien
Hi Simon,

2015-04-17 18:33 GMT+02:00 Simon Glass s...@chromium.org:
 +Tom

 Hi Franck,

 On 4 March 2015 at 13:07,  franck.jull...@gmail.com wrote:
 From: Franck Jullien franck.jull...@gmail.com

 Mass storage is not necessary present on interface 0. This
 patch allow usb_stor_scan to look in every available interface.

 Signed-off-by: Franck Jullien franck.jull...@gmail.com
 ---

 v2: create a new function to improve indentation

 v3: more indentation improvement

  common/usb_storage.c |   45 -
  1 files changed, 28 insertions(+), 17 deletions(-)

 diff --git a/common/usb_storage.c b/common/usb_storage.c
 index 1411737..05c96a8 100644
 --- a/common/usb_storage.c
 +++ b/common/usb_storage.c
 @@ -208,6 +208,30 @@ static unsigned int usb_get_max_lun(struct us_data *us)
 return (len  0) ? *result : 0;
  }

 +static int usb_storage_register(struct usb_device *dev, unsigned char iface)
 +{
 +   int lun, max_lun, start = usb_max_devs;
 +   int nb_dev = 0;
 +
 +   if (!usb_storage_probe(dev, iface, usb_stor[usb_max_devs]))
 +   return nb_dev;
 +
 +   /*
 +* OK, it's a storage device.  Iterate over its LUNs
 +* and populate `usb_dev_desc'.
 +*/
 +   max_lun = usb_get_max_lun(usb_stor[usb_max_devs]);
 +   for (lun = 0; lun = max_lun  usb_max_devs  USB_MAX_STOR_DEV; 
 lun++) {
 +   usb_dev_desc[usb_max_devs].lun = lun;
 +   if (usb_stor_get_info(dev, usb_stor[start],
 +   usb_dev_desc[usb_max_devs]) == 1) {
 +   nb_dev++;

 Should start or usb_max_devs increase here? This will use the same
 block_dev_desc_t for each device, won't it?


Good catch. I'll write a patch when I have some time (or someone can do that).
However, I won't be able to test it on hardware because I don't have
access to it anymore.

We could also revert this patch. Sorry for my mistake.

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