Re: [U-Boot] [PATCH v6 00/15] Add PSCI support for Jetson TK1/Tegra124 + CNTFRQ fix
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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]
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
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
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
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
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
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
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]
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
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
+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]
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
+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
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
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
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
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
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
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]
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
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
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
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
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]
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]
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]
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
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
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]
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
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]
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]
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
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
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
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
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
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
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
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
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
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]
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]
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
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
