Re: [U-Boot] am335x board i2c_probe fails from nand boot

[matti kaasinen]

2017-01-04 6:46 GMT+02:00 Lokesh Vutla :

> > "Card did not respond to voltage select!" is coming from:
> > drivers/mmc/mmc.c
>
> Can you check if mmc mux is being done properly?
>

I think this message is coming because I have ejected mmc (sd card) in
order to boot from nand.

However, I went through include/configs/am335x_evm.h that I have patched
very moderately - ionly two changes:
1) disable card detect
2) feed own fdt file.
I noticed some nand related values that I'm not sure if they are correct. I
get following nand partition listed from mmc boot:
[1.230539] Creating 10 MTD partitions on "800.nand":
[1.236229] 0x-0x0002 : "NAND.SPL"
[1.243121] 0x0002-0x0004 : "NAND.SPL.backup1"
[1.250614] 0x0004-0x0006 : "NAND.SPL.backup2"
[1.258121] 0x0006-0x0008 : "NAND.SPL.backup3"
[1.265515] 0x0008-0x000c : "NAND.u-boot-spl-os"
[1.273167] 0x000c-0x001c : "NAND.u-boot"
[1.280890] 0x001c-0x001e : "NAND.u-boot-env"
[1.288255] 0x001e-0x0020 : "NAND.u-boot-env.backup1"
[1.296430] 0x0020-0x00a0 : "NAND.kernel"
[1.309941] 0x00a0-0x1000 : "NAND.file-system"

In am335x_evm.h there are following definitions:
#define CONFIG_SYS_NAND_U_BOOT_OFFS0x000c
So, this is pointing to NAND.u-boot-spl-os, i.e os parameters in nand, not
u-boot

#define CONFIG_CMD_SPL_NAND_OFS0x0008 /* os parameters */
This is pointing to NAND.SPL.backup3

#define CONFIG_SYS_NAND_SPL_KERNEL_OFFS0x0020 /* kernel offset */
This is pointing to NAND.u-boot-env.backup1, not kernel

#define CONFIG_CMD_SPL_WRITE_SIZE0x2000
0x2000 does not match with 0x8 that is reserved for NAND.u-boot-spl-os
partition.


As you told, u-boot starts, so most likely these don't matter this time.

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

Re: [U-Boot] am335x board i2c_probe fails from nand boot

[Lokesh Vutla]

On Tuesday 03 January 2017 08:07 PM, matti kaasinen wrote:
> "The Expected Linux image was not found. Please check your NAND
> configuration" message is coming from:
> common/spl/spl_nand.c
> In practice this message seems coming from the fact that header of
> kernel image can't be identified from offset after executing:
> nand_spl_load_image(CONFIG_SYS_NAND_SPL_KERNEL_OFFS,,)

This is fine as SPL_OS_BOOT is enabled by default. We are successfully
going to u-boot prompt, so no issues.

> So, something gets broken in while executing nand_spl_load_image.
> Perhaps CONFIG_SYS_NAND_SPL_KERNEL_OFFS value.
> 
> "Card did not respond to voltage select!" is coming from:
> drivers/mmc/mmc.c

Can you check if mmc mux is being done properly?

Thanks and regards,
Lokesh

> 
> 2017-01-03 15:34 GMT+02:00 matti kaasinen  >:
> 
> 
> 2017-01-03 14:33 GMT+02:00 matti kaasinen  >:
> 
> One reason why I2C configuration is wrong in nand mode could be
> the fact that I have CONFIG_TI_I2C_BOARD_DETECT variable is
> undefined (because I do not have that eeprom). But it looks that
> do_board_detect runs enable_i2c0_pin_mux() that I do not run
> separately. On the other hand, that does not explain why mmc
> boot works.
> 
> 
> 
> Now I did this I2C0 configuration separately prior to running
> i2c_probe(). Nand boot went further now. However, main u-boot did
> not start properly. I got following messages
> Trying to boot from NAND
> The Expected Linux image was not found. Please check your NAND
> configuration.
> Trying to start u-boot now...
> 
>  more messages 
> Press SPACE to abort autoboot in 2 seconds
> Card did not respond to voltage select!
> Card did not respond to voltage select!
> Card did not respond to voltage select!
> Card did not respond to voltage select!
> Card did not respond to voltage select!
> data abort
> pc : [<8ff70f94>]  lr : [<8ff701dd>]
> reloc pc : [<8081df94>]lr : [<8081d1dd>]
> sp : 8ef28678  ip : 8ff5891d fp : 0003
> r10: 8ffb3af8  r9 : 8ef32ed8 r8 : 8ef41e40
> r7 : 8ff584bd  r6 : 8ef39478 r5 : 8ef39500  r4 : 4781
> r3 : 8ff70f85  r2 : 0d8d r1 :   r0 : 8ef39500
> Flags: nZCv  IRQs off  FIQs on  Mode SVC_32
> Resetting CPU ...
> 
> resetting ...
> 
> And game over
> So, it's not quite sure that voltage adjustments went through even
> though I2C did not complain anymore.
> There could be something wrong with nand settings, too. I need to
> check where these complaints are coming.
> 
> Thanks anyway for your comments,
> Matti
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH RESEND v2 1/2] spi: cadence_qspi_apb: Use 32 bit indirect write transaction when possible

[Vignesh R]

On Tuesday 03 January 2017 07:40 PM, Jagan Teki wrote:
> On Tue, Jan 3, 2017 at 2:35 PM, R, Vignesh  wrote:
>>
>>
>> On 12/21/2016 10:42 AM, Vignesh R wrote:
>>> According to Section 11.15.4.9.2 Indirect Write Controller of K2G SoC
>>> TRM SPRUHY8D[1], the external master is only permitted to issue 32-bit
>>> data interface writes until the last word of an indirect transfer
>>> otherwise indirect writes is known to fails sometimes. So, make sure
>>> that QSPI indirect writes are 32 bit sized except for the last write. If
>>> the txbuf is unaligned then use bounce buffer to avoid data aborts.
>>>
>>> So, now that the driver uses bounce_buffer, enable CONFIG_BOUNCE_BUFFER
>>> for all boards that use Cadence QSPI driver.
>>>
>>> [1]www.ti.com/lit/ug/spruhy8d/spruhy8d.pdf
>>>
>>> Signed-off-by: Vignesh R 
>>> Reviewed-by: Marek Vasut 
>>
>> Gentle ping on the series...
> 
> Please link to other one, I couldn't find it on patchwork.
> 

Here are the two patches of the series:
https://patchwork.ozlabs.org/patch/707648/
https://patchwork.ozlabs.org/patch/707647/

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

[U-Boot] [PATCH v2 2/2] lib: net_utils: enforce '.' as octet separator in string_to_ip

[Chris Packham]

Ensure '.' is used to separate octets. If another character is seen
reject the string outright and return 0.0.0.0.

Signed-off-by: Chris Packham 
---

Changes in v2:
- new
END

 lib/net_utils.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/net_utils.c b/lib/net_utils.c
index 8f81e7801033..d06be22849fb 100644
--- a/lib/net_utils.c
+++ b/lib/net_utils.c
@@ -28,6 +28,10 @@ struct in_addr string_to_ip(const char *s)
addr.s_addr = 0;
return addr;
}
+   if (i != 3 && *e != '.') {
+   addr.s_addr = 0;
+   return addr;
+   }
addr.s_addr <<= 8;
addr.s_addr |= (val & 0xFF);
if (s) {
-- 
2.11.0.24.ge6920cf

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

[U-Boot] [PATCH v2 1/2] lib: net_utils: make string_to_ip stricter

[Chris Packham]

Previously values greater than 255 were implicitly truncated. Add some
stricter checking to reject addresses with components >255.

With the input "1234192.168.1.1" the old behaviour would truncate the
address to 192.168.1.1. New behaviour rejects the string outright and
returns 0.0.0.0, which for the purposes of IP addresses can be
considered an error.

Signed-off-by: Chris Packham 
---
This was part of my long running IPv6 patchset (which I promise I'll get
back to someday). But I feel this stands on it's own merits.

Changes in v2:
- split into 2 patches

 lib/net_utils.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/net_utils.c b/lib/net_utils.c
index cfae84275241..8f81e7801033 100644
--- a/lib/net_utils.c
+++ b/lib/net_utils.c
@@ -24,6 +24,10 @@ struct in_addr string_to_ip(const char *s)
 
for (addr.s_addr = 0, i = 0; i < 4; ++i) {
ulong val = s ? simple_strtoul(s, , 10) : 0;
+   if (val > 255) {
+   addr.s_addr = 0;
+   return addr;
+   }
addr.s_addr <<= 8;
addr.s_addr |= (val & 0xFF);
if (s) {
-- 
2.11.0.24.ge6920cf

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

[U-Boot] [U-Boot,v2,3/3] LS1046ARDB: Add QSPI Secure Boot target

[Vinitha Pillai-B57223]

From: Sumit Garg 

Add QSPI Secure Boot target. Also enable sec init.

Signed-off-by: Vinitha Pillai 
Signed-off-by: Sumit Garg 
---

Changes in v2:
Split patches logically from 2 to 3.

 board/freescale/ls1046ardb/MAINTAINERS|  4 
 board/freescale/ls1046ardb/ls1046ardb.c   | 19 +++
 configs/ls1046ardb_qspi_SECURE_BOOT_defconfig | 27 +++
 include/configs/ls1046ardb.h  |  2 ++
 4 files changed, 52 insertions(+)
 create mode 100644 configs/ls1046ardb_qspi_SECURE_BOOT_defconfig

diff --git a/board/freescale/ls1046ardb/MAINTAINERS 
b/board/freescale/ls1046ardb/MAINTAINERS
index ff42bef..758ff9d 100644
--- a/board/freescale/ls1046ardb/MAINTAINERS
+++ b/board/freescale/ls1046ardb/MAINTAINERS
@@ -7,3 +7,7 @@ F:  include/configs/ls1046ardb.h
 F: configs/ls1046ardb_qspi_defconfig
 F: configs/ls1046ardb_sdcard_defconfig
 F: configs/ls1046ardb_emmc_defconfig
+
+M: Sumit Garg 
+S: Maintained
+F: configs/ls1046ardb_qspi_SECURE_BOOT_defconfig
diff --git a/board/freescale/ls1046ardb/ls1046ardb.c 
b/board/freescale/ls1046ardb/ls1046ardb.c
index 585c807..6fadea1 100644
--- a/board/freescale/ls1046ardb/ls1046ardb.c
+++ b/board/freescale/ls1046ardb/ls1046ardb.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include "cpld.h"
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -77,6 +78,24 @@ int board_init(void)
enable_layerscape_ns_access();
 #endif
 
+#ifdef CONFIG_SECURE_BOOT
+   /*
+* In case of Secure Boot, the IBR configures the SMMU
+* to allow only Secure transactions.
+* SMMU must be reset in bypass mode.
+* Set the ClientPD bit and Clear the USFCFG Bit
+*/
+   u32 val;
+   val = (in_le32(SMMU_SCR0) | SCR0_CLIENTPD_MASK) & ~(SCR0_USFCFG_MASK);
+   out_le32(SMMU_SCR0, val);
+   val = (in_le32(SMMU_NSCR0) | SCR0_CLIENTPD_MASK) & ~(SCR0_USFCFG_MASK);
+   out_le32(SMMU_NSCR0, val);
+#endif
+
+#ifdef CONFIG_FSL_CAAM
+   sec_init();
+#endif
+
 #ifdef CONFIG_FSL_LS_PPA
ppa_init();
 #endif
diff --git a/configs/ls1046ardb_qspi_SECURE_BOOT_defconfig 
b/configs/ls1046ardb_qspi_SECURE_BOOT_defconfig
new file mode 100644
index 000..c79c875
--- /dev/null
+++ b/configs/ls1046ardb_qspi_SECURE_BOOT_defconfig
@@ -0,0 +1,27 @@
+CONFIG_ARM=y
+CONFIG_TARGET_LS1046ARDB=y
+CONFIG_DM_SPI=y
+CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1046a-rdb"
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_SYS_EXTRA_OPTIONS="SYS_FSL_DDR4,SECURE_BOOT"
+CONFIG_QSPI_BOOT=y
+CONFIG_BOOTDELAY=10
+CONFIG_HUSH_PARSER=y
+# CONFIG_CMD_IMLS is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_FAT=y
+CONFIG_OF_CONTROL=y
+CONFIG_DM=y
+CONFIG_SPI_FLASH=y
+CONFIG_SYS_NS16550=y
+CONFIG_FSL_QSPI=y
+CONFIG_RSA=y
diff --git a/include/configs/ls1046ardb.h b/include/configs/ls1046ardb.h
index 2fe8fc1..afa580e 100644
--- a/include/configs/ls1046ardb.h
+++ b/include/configs/ls1046ardb.h
@@ -234,4 +234,6 @@
"7e80.flash:16m(nand_uboot)," \
"48m(nand_kernel),448m(nand_free)"
 
+#include 
+
 #endif /* __LS1046ARDB_H__ */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/6] arm: tegra: apalis-tk1, mmc and ext clock loopback

[Tom Warren]

Marcel,

> -Original Message-
> From: Marcel Ziswiler [mailto:mar...@ziswiler.com]
> Sent: Wednesday, December 21, 2016 9:26 PM
> To: u-boot@lists.denx.de
> Cc: Max Krummenacher ; Stefan Agner
> ; Marcel Ziswiler
> ; York Sun ;
> peter.ch...@data61.csiro.au; Lokesh Vutla ; Jaehoon
> Chung ; Hans de Goede ;
> Heiko Schocher ; Albert Aribaud ;
> Prabhakar Kushwaha ; Stephen Warren
> ; Jagan Teki ; Alexander Graf
> ; Tom Warren ; Joe Hershberger
> ; Lucas Stach ; Allen Martin
> ; Stefan Roese ; Alban Bedel
> ; Simon Glass ;
> Masahiro Yamada ; Ian Campbell
> 
> Subject: [PATCH v3 0/6] arm: tegra: apalis-tk1, mmc and ext clock loopback
> 
> From: Marcel Ziswiler 
> 
> 
> This series adds support for the Toradex Apalis TK1 as well as moves the
> CONFIG_TEGRA_MMC to Kconfig and introduces a new option to disable the
> external clock loopback on SDMMC3.
> 
> The whole series is also available here:
> 
> http://git.toradex.com/cgit/u-boot-toradex.git/log/?h=for-next
> 
> Changes in v3:
> - My recent fresh install of Fedora 25 was missing an aarch64 toolchain
>   which made moveconfig.py not properly handle the 6 newer Tegras. I now
>   re-run moveconfig.py after installing an aarch64 toolchain and it all
>   looks sane. Sorry about that, Tom.
With Mashiro's recent 'mmc: move more driver config options to Kconfig' 
patchset (which is in TOT U-Boot now), your v3 patchset no longer applies 
cleanly.

I'll rebase u-boot-tegra/master against u-boot/master and push a new repo to 
Denx so you can get your Apalis-TK1 patchset to work w/all of the recent 
changes.

Thanks, and sorry for the extra work!

Tom
--
nvpublic
> - Cleaned-up defconfig using savedefconfig.
> 
> Changes in v2:
> - Added Simon's reviewed-by.
> - Added Simon's reviewed-by.
> - Added Simon's reviewed-by.
> - Added Simon's reviewed-by.
> - Added TODO(email) as suggested by Simon so it is clear this is
>   temporary and will be moved to device tree controlled approach once
>   proper kernel integration made it mainline.
> 
> Marcel Ziswiler (6):
>   arm: tegra: initial support for apalis tk1
>   mmc: tegra: introduce CONFIG_TEGRA_MMC to Kconfig
>   mmc: tegra: move CONFIG_TEGRA_MMC from headers to defconfigs
>   mmc: tegra: allow disabling external clock loopback
>   apalis-tk1: disable external clock loopback on SDMMC3
>   apalis-tk1: clean-up defconfig
> 
>  arch/arm/dts/Makefile  |1 +
>  arch/arm/dts/tegra124-apalis.dts   | 2203 
> 
>  arch/arm/include/asm/arch-tegra/tegra_mmc.h|2 +
>  arch/arm/mach-tegra/tegra124/Kconfig   |7 +
>  board/toradex/apalis-tk1/Kconfig   |   30 +
>  board/toradex/apalis-tk1/MAINTAINERS   |7 +
>  board/toradex/apalis-tk1/Makefile  |5 +
>  board/toradex/apalis-tk1/apalis-tk1.c  |  175 ++
>  board/toradex/apalis-tk1/as3722_init.c |  117 ++
>  board/toradex/apalis-tk1/as3722_init.h |   41 +
>  .../toradex/apalis-tk1/pinmux-config-apalis-tk1.h  |  287 +++
>  configs/apalis-tk1_defconfig   |   46 +
>  configs/apalis_t30_defconfig   |1 +
>  configs/beaver_defconfig   |1 +
>  configs/cardhu_defconfig   |1 +
>  configs/cei-tk1-som_defconfig  |1 +
>  configs/colibri_t20_defconfig  |1 +
>  configs/colibri_t30_defconfig  |1 +
>  configs/dalmore_defconfig  |1 +
>  configs/e2220-1170_defconfig   |9 +-
>  configs/harmony_defconfig  |1 +
>  configs/jetson-tk1_defconfig   |1 +
>  configs/medcom-wide_defconfig  |1 +
>  configs/nyan-big_defconfig |1 +
>  configs/p2371-_defconfig   |9 +-
>  configs/p2371-2180_defconfig   |9 +-
>  configs/p2571_defconfig|9 +-
>  configs/p2771--000_defconfig   |9 +-
>  configs/p2771--500_defconfig   |9 +-
>  configs/paz00_defconfig|1 +
>  configs/plutux_defconfig   |1 +
>  configs/seaboard_defconfig |1 +
>  configs/tec-ng_defconfig   |1 +
>  

Re: [U-Boot] [U-Boot, v2, 3/3] LS1046ARDB: Add QSPI Secure Boot target

[Vini Pillai]

Hi all
Please Ignore this mail
Regards,
Vinitha

-Original Message-
From: Vinitha Pillai-B57223 [mailto:b57...@freescale.com] 
Sent: Tuesday, January 03, 2017 11:01 PM
To: Udit Agarwal ; u-boot@lists.denx.de
Cc: Sumit Garg ; Ruchika Gupta ; 
Vini Pillai 
Subject: [U-Boot,v2,3/3] LS1046ARDB: Add QSPI Secure Boot target

From: Sumit Garg 

Add QSPI Secure Boot target. Also enable sec init.

Signed-off-by: Vinitha Pillai 
Signed-off-by: Sumit Garg 
---

Changes in v2:
Split patches logically from 2 to 3.

 board/freescale/ls1046ardb/MAINTAINERS|  4 
 board/freescale/ls1046ardb/ls1046ardb.c   | 19 +++
 configs/ls1046ardb_qspi_SECURE_BOOT_defconfig | 27 +++
 include/configs/ls1046ardb.h  |  2 ++
 4 files changed, 52 insertions(+)
 create mode 100644 configs/ls1046ardb_qspi_SECURE_BOOT_defconfig

diff --git a/board/freescale/ls1046ardb/MAINTAINERS 
b/board/freescale/ls1046ardb/MAINTAINERS
index ff42bef..758ff9d 100644
--- a/board/freescale/ls1046ardb/MAINTAINERS
+++ b/board/freescale/ls1046ardb/MAINTAINERS
@@ -7,3 +7,7 @@ F:  include/configs/ls1046ardb.h
 F: configs/ls1046ardb_qspi_defconfig
 F: configs/ls1046ardb_sdcard_defconfig
 F: configs/ls1046ardb_emmc_defconfig
+
+M: Sumit Garg 
+S: Maintained
+F: configs/ls1046ardb_qspi_SECURE_BOOT_defconfig
diff --git a/board/freescale/ls1046ardb/ls1046ardb.c 
b/board/freescale/ls1046ardb/ls1046ardb.c
index 585c807..6fadea1 100644
--- a/board/freescale/ls1046ardb/ls1046ardb.c
+++ b/board/freescale/ls1046ardb/ls1046ardb.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include "cpld.h"
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -77,6 +78,24 @@ int board_init(void)
enable_layerscape_ns_access();
 #endif
 
+#ifdef CONFIG_SECURE_BOOT
+   /*
+* In case of Secure Boot, the IBR configures the SMMU
+* to allow only Secure transactions.
+* SMMU must be reset in bypass mode.
+* Set the ClientPD bit and Clear the USFCFG Bit
+*/
+   u32 val;
+   val = (in_le32(SMMU_SCR0) | SCR0_CLIENTPD_MASK) & ~(SCR0_USFCFG_MASK);
+   out_le32(SMMU_SCR0, val);
+   val = (in_le32(SMMU_NSCR0) | SCR0_CLIENTPD_MASK) & ~(SCR0_USFCFG_MASK);
+   out_le32(SMMU_NSCR0, val);
+#endif
+
+#ifdef CONFIG_FSL_CAAM
+   sec_init();
+#endif
+
 #ifdef CONFIG_FSL_LS_PPA
ppa_init();
 #endif
diff --git a/configs/ls1046ardb_qspi_SECURE_BOOT_defconfig 
b/configs/ls1046ardb_qspi_SECURE_BOOT_defconfig
new file mode 100644
index 000..c79c875
--- /dev/null
+++ b/configs/ls1046ardb_qspi_SECURE_BOOT_defconfig
@@ -0,0 +1,27 @@
+CONFIG_ARM=y
+CONFIG_TARGET_LS1046ARDB=y
+CONFIG_DM_SPI=y
+CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1046a-rdb"
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_SYS_EXTRA_OPTIONS="SYS_FSL_DDR4,SECURE_BOOT"
+CONFIG_QSPI_BOOT=y
+CONFIG_BOOTDELAY=10
+CONFIG_HUSH_PARSER=y
+# CONFIG_CMD_IMLS is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_FAT=y
+CONFIG_OF_CONTROL=y
+CONFIG_DM=y
+CONFIG_SPI_FLASH=y
+CONFIG_SYS_NS16550=y
+CONFIG_FSL_QSPI=y
+CONFIG_RSA=y
diff --git a/include/configs/ls1046ardb.h b/include/configs/ls1046ardb.h index 
2fe8fc1..afa580e 100644
--- a/include/configs/ls1046ardb.h
+++ b/include/configs/ls1046ardb.h
@@ -234,4 +234,6 @@
"7e80.flash:16m(nand_uboot)," \
"48m(nand_kernel),448m(nand_free)"
 
+#include 
+
 #endif /* __LS1046ARDB_H__ */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] are DM/SPL dependencies in drivers/core/Kconfig correct?

[Robert P. J. Day]

  quite prepared to be told i'm totally off-base here, but the DM/SPL
dependencies in the drivers/core/Kconfig file seem a bit odd, but that
might be just my misunderstanding of how DM and SPL work together.

  first quick observation -- based on the naming convention i read
somewhere, it seems that the Kbuild variable "SPL_DM" should actually
be "DM_SPL". i'm sure i remember reading that the naming standard
for DM-related variables should be "CONFIG_DM_*" but that's not a big
deal. onward ...

  using a wandboard configuration, and enabling SPL, then driver model
*and* driver model for SPL, one sees (partial list only) the Kbuild
entries:

[*] Enable Driver Model
[*]   Enable Driver Model for SPL
[*]   Support numbered aliases in device tree
[ ]   Support numbered aliases in device tree in SPL
[*]   Support register maps
[*]   Support register maps in SPL
[*] Support system controllers
[*] Support system controllers in SPL
[*] Support simple-bus driver
[ ] Support simple-bus driver in SPL
[*] Translate addresses using fdt_translate_address
[ ] Translate addresses using fdt_translate_address in SPL

where the list above represents pairs of settings, one non-SPL, one
for SPL. so far, so good.

  but if one then deselects "Enable Driver Model for SPL", one is
still left with some of those (ostensibly) SPL-related entries:

[ ]   Support numbered aliases in device tree in SPL
[*]   Support register maps in SPL
[*] Support system controllers in SPL

  a quick look at the Kconfig file shows that some of those "for SPL"
entries depend on SPL_DM, while the others depend only on DM. is that
the way it's meant to be? i don't know enough about how the driver
model relates to SPL, so it's entirely possible the above is entirely
correct, it just looks a bit weird.

  in any event, that Kconfig file could still be refactored to avoid
new entries popping up in arbitrary places depending on what you
select or deselect.

  thoughts?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [U-Boot] Rockchip RK3288 regulator device table problem

[Rick Bronson]

Hi Simon,

  I'm not sure what to do about (in drivers/power/regulator/rk808.c):

static const struct rk808_reg_info rk808_ldo[] = {
{ 100, 10, LDO1_ON_VSEL, 5, },
...

  I had to change this table as my LDO values are different for this
board.  I'd like to fix it to take values from the device tree but
couldn't find an example.  Maybe you can point me to one.

  Thanks,

  Rick


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

Re: [U-Boot] [PATCH] i2c: mux: Allow muxes to work as children of i2c bus without i2c-parent

[Moritz Fischer]

Hi Michal,

On Tue, Jan 3, 2017 at 1:22 AM, Michal Simek  wrote:
> On 2.1.2017 20:20, Moritz Fischer wrote:
>> Hi Michal,
>>
>> On Mon, Jan 2, 2017 at 6:24 AM, Michal Simek  wrote:
>>> On 29.12.2016 23:50, Moritz Fischer wrote:
 For mux check if the parent is already a device of UCLASS_I2C and if yes
 just use that. Otherwise see if someone specified an i2c-parent phandle.
 This mimics the behavior found in the Kernel, as it removes the
 requirement to explicitly specify a i2c-parent phandle.

 Signed-off-by: Moritz Fischer 
 Cc: Heiko Schocher 
 Cc: Bin Meng 
 Cc: Simon Glass 
 Cc: Michal Simek 
 Cc: u-boot@lists.denx.de
 ---
  drivers/i2c/muxes/i2c-mux-uclass.c | 9 +
  1 file changed, 9 insertions(+)

 diff --git a/drivers/i2c/muxes/i2c-mux-uclass.c 
 b/drivers/i2c/muxes/i2c-mux-uclass.c
 index 7a698b6..e01b773 100644
 --- a/drivers/i2c/muxes/i2c-mux-uclass.c
 +++ b/drivers/i2c/muxes/i2c-mux-uclass.c
 @@ -86,6 +86,15 @@ static int i2c_mux_post_probe(struct udevice *mux)
   debug("%s: %s\n", __func__, mux->name);
   priv->selected = -1;

 + /* if parent is of i2c uclass already, we'll take that, otherwise
 +  * look if we find an i2c-parent phandle */
>>>
>>> Incorrect comment style.
>>
>> Yeah, wasn't flagged by checkpatch  will fix.
>>>
 + if (UCLASS_I2C == device_get_uclass_id(mux->parent)) {
 + priv->i2c_bus = dev_get_parent(mux);
 + debug("%s: bus=%p/%s\n", __func__, priv->i2c_bus,
 +   priv->i2c_bus->name);
 + return 0;
 + }
 +
   ret = uclass_get_device_by_phandle(UCLASS_I2C, mux, "i2c-parent",
  >i2c_bus);
   if (ret)

>>>
>>> The part of this will be good to also handle
>>> req_seq for mux busses. But at least this should solved part of the
>>> problems.
>>
>> I'm not sure I understand this comment.
>
> AFAIK using i2c muxes requires two changes in DTS file.
> First change is this to setup i2c-parent in DTS file which is something
> what Linux doesn't need.

Yeah this part is addressed in this patch.

> The next change is that you have to extend i2c aliases to point to i2c
> mux sub busses which is the second thing what Linux doesn't need.
> I expect that this change you have in your dts file.

Yeah, thanks for clarifying. In my dts I have aliases for each of the
mux channels,
which, I don't have a good idea on how to solve differently. In Linux
I think I don't need that.

> I think that if you detect mux with 8 ports you can simply use unique
> busid to be able to address them.

In Linux? I'll have to take another look at that. Currently I get
busses like 700,701,702 etc (which are aliases I defined).
Each of them points to a mux channel.


aliases { ...
i2c0 = 
i2c0700 = _70_0;
i2c0701 = _70_1;
i2c0702 = _70_2;
i2c0703 = _70_3;
};

...
i2cswitch@70 {
compatible = "ti,pca9548", "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x70>;
status = "okay";

i2c0_70_0: i2c@0 {
reg = <0x0>;
#address-cells = <1>;
#size-cells = <0>;

status = "okay";
};
...
  };



I Will resubmit a v2 for the other changes above

If you or Simon have ideas on how to correctly solve the alias issue,
I can take another stab at that.

Thanks,

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

Re: [U-Boot] am335x board i2c_probe fails from nand boot

[matti kaasinen]

"The Expected Linux image was not found. Please check your NAND
configuration" message is coming from:
common/spl/spl_nand.c
In practice this message seems coming from the fact that header of kernel
image can't be identified from offset after executing:
nand_spl_load_image(CONFIG_SYS_NAND_SPL_KERNEL_OFFS,,)
So, something gets broken in while executing nand_spl_load_image. Perhaps
CONFIG_SYS_NAND_SPL_KERNEL_OFFS value.

"Card did not respond to voltage select!" is coming from:
drivers/mmc/mmc.c

2017-01-03 15:34 GMT+02:00 matti kaasinen :

>
> 2017-01-03 14:33 GMT+02:00 matti kaasinen :
>
>> One reason why I2C configuration is wrong in nand mode could be the fact
>> that I have CONFIG_TI_I2C_BOARD_DETECT variable is undefined (because I do
>> not have that eeprom). But it looks that do_board_detect runs
>> enable_i2c0_pin_mux() that I do not run separately. On the other hand, that
>> does not explain why mmc boot works.
>
>
>
> Now I did this I2C0 configuration separately prior to running i2c_probe().
> Nand boot went further now. However, main u-boot did not start properly. I
> got following messages
> Trying to boot from NAND
> The Expected Linux image was not found. Please check your NAND
> configuration.
> Trying to start u-boot now...
>
>  more messages 
> Press SPACE to abort autoboot in 2 seconds
> Card did not respond to voltage select!
> Card did not respond to voltage select!
> Card did not respond to voltage select!
> Card did not respond to voltage select!
> Card did not respond to voltage select!
> data abort
> pc : [<8ff70f94>]  lr : [<8ff701dd>]
> reloc pc : [<8081df94>]lr : [<8081d1dd>]
> sp : 8ef28678  ip : 8ff5891d fp : 0003
> r10: 8ffb3af8  r9 : 8ef32ed8 r8 : 8ef41e40
> r7 : 8ff584bd  r6 : 8ef39478 r5 : 8ef39500  r4 : 4781
> r3 : 8ff70f85  r2 : 0d8d r1 :   r0 : 8ef39500
> Flags: nZCv  IRQs off  FIQs on  Mode SVC_32
> Resetting CPU ...
>
> resetting ...
>
> And game over
> So, it's not quite sure that voltage adjustments went through even though
> I2C did not complain anymore.
> There could be something wrong with nand settings, too. I need to check
> where these complaints are coming.
>
> Thanks anyway for your comments,
> Matti
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH RESEND v2 1/2] spi: cadence_qspi_apb: Use 32 bit indirect write transaction when possible

[Jagan Teki]

On Tue, Jan 3, 2017 at 2:35 PM, R, Vignesh  wrote:
>
>
> On 12/21/2016 10:42 AM, Vignesh R wrote:
>> According to Section 11.15.4.9.2 Indirect Write Controller of K2G SoC
>> TRM SPRUHY8D[1], the external master is only permitted to issue 32-bit
>> data interface writes until the last word of an indirect transfer
>> otherwise indirect writes is known to fails sometimes. So, make sure
>> that QSPI indirect writes are 32 bit sized except for the last write. If
>> the txbuf is unaligned then use bounce buffer to avoid data aborts.
>>
>> So, now that the driver uses bounce_buffer, enable CONFIG_BOUNCE_BUFFER
>> for all boards that use Cadence QSPI driver.
>>
>> [1]www.ti.com/lit/ug/spruhy8d/spruhy8d.pdf
>>
>> Signed-off-by: Vignesh R 
>> Reviewed-by: Marek Vasut 
>
> Gentle ping on the series...

Please link to other one, I couldn't find it on patchwork.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] spl: sunxi: Fix build error with CONFIG_SPL_SPI_SUNXI

[Jagan Teki]

On Mon, Jan 2, 2017 at 7:24 PM, Priit Laes  wrote:
> Fix typo introduced in ebc4ef61d76fc182773fe225151adc9b913c62eb
>
> Signed-off-by: Priit Laes 

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

Re: [U-Boot] [linux-sunxi] [PATCH v4 00/26] sunxi: Allwinner A64: SPL support

[jonsm...@gmail.com]

On Tue, Jan 3, 2017 at 5:41 AM, Jagan Teki  wrote:
> On Tue, Jan 3, 2017 at 3:38 AM, jonsm...@gmail.com  wrote:
>> I recently ran into a probably with the UARTs on the A64. Many
>> Bluetooth modules (like Ampak) use the UART. The data rate of EDR BT
>> is 3Mb/s with about 2.1Mb/s though put. To handle this most systems
>> set the speed of the BT UART to 3Mb/s.
>>
>> By default the Allwinner UART clock input is OSC24. When using OSC24
>> the maximum speed the UART can be set to is 1.5Mb/s. The clock input
>> (apb2) can be changed over to PERIPH0x2 (1.2ghz) via the device tree
>> and 3Mb/s is then supported.
>>
>> But... there's a problem, UART0 (the console) is using the same master
>> clock source. So when you change the clock input over to PERIPH0x2 the
>> console stops working. There is no mechanism in Linux to handle this
>> clock source change and adjust the dividers on active uarts. So it
>> would be best if this master clock was set very early in u-boot and
>> then the console is adjusted to use it.
>>
>> Are there any downsides to making this change in u-boot?
>
> I don't understand, did you find this behaviour with these SPL changes
> or general sunxi u-boot?

Previously the boot console uart0 was getting setup in the SPL code. I
have not been closely following these changes, is that still true?

Changing the clock parent needs to be done before uart0 is
initialized. Changing this parent should have no other impact on
u-boot other than changing the clock divisor uart0 is using.

Once Linux is up, the Linux uart code will see the changed clock
parent and allow higher baud rates to be set.

This clock parent also impacts the I2C clocks, but I don't believe I2C
is enabled in A64 uboot.


>
> thanks!
> --
> Jagan Teki
> Free Software Engineer | www.openedev.com
> U-Boot, Linux | Upstream Maintainer
> Hyderabad, India.



-- 
Jon Smirl
jonsm...@gmail.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] rpi: Fix device tree path on ARM64

[Tuomas Tynkkynen]

The directory structure of device tree files produced by the kernel's
'make dtbs_install' is different on ARM64, the RPi3 device tree file is
in a 'broadcom' subdirectory there. Make the set_fdtfile function account
for this so that the distro boot scripts can locate the DTB file.

Signed-off-by: Tuomas Tynkkynen 
---
 board/raspberrypi/rpi/rpi.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 22e87a2..dbf69f8 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -243,12 +243,14 @@ int dram_init(void)
 
 static void set_fdtfile(void)
 {
-   const char *fdtfile;
+   char fdtfile[64] = "";
 
if (getenv("fdtfile"))
return;
 
-   fdtfile = model->fdtfile;
+   if (IS_ENABLED(CONFIG_ARM64))
+   strcat(fdtfile, "broadcom/");
+   strcat(fdtfile, model->fdtfile);
setenv("fdtfile", fdtfile);
 }
 
-- 
2.10.2

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

[U-Boot] mkimage for ls1021a-twr.dtb

[zvivered]

Hello,

I'm compiling vanilla 4.1.13 for ls1021a with gcc created with crosstool-ng
Upon kernel build completion I got the file: ls1021a-twr.dtb

Then I ran:
mkimage -A arm -O Linux -C none -T kernel -n 3.14.4 -d ls1021a-twr.dtb
uImage.dtb

using tftp I downloaded:
uImage -> 0x8300
uRamdisk -> 0x8800
uImage.dtb -> 0x8F00
bootm 8300 8800 8F00

Upon booting uImage.dtb I got:
ERROR: uImage is not a fdt - must RESET the board to recover.
Could not find a valid device tree

What am I doing wrong ?

I have a uImage.dtb taken from NXP's Yocto project. 
With this file I'm getting:
## Flattened Device Tree blob at 8f00
Booting using the fdt blob at 0x8f00
Loading Kernel Image ... OK
Using Device Tree in place at 8f00, end 8f008469

With my file I'm getting:
## Flattened Device Tree from Legacy Image at 8f00
Image Name:
Iamge Type: ARM Linux ..

ERROR: uImage is not a fdt - must RESET the board to recover.
Could not find a valid device tree

Thank you in advance,
Z.V






--
View this message in context: 
http://u-boot.10912.n7.nabble.com/mkimage-for-ls1021a-twr-dtb-tp277542.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] spl: sunxi: Fix build error with CONFIG_SPL_SPI_SUNXI

[Priit Laes]

Fix typo introduced in ebc4ef61d76fc182773fe225151adc9b913c62eb

Signed-off-by: Priit Laes 
---
 drivers/mtd/spi/sunxi_spi_spl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/spi/sunxi_spi_spl.c b/drivers/mtd/spi/sunxi_spi_spl.c
index e70064c..a24c115 100644
--- a/drivers/mtd/spi/sunxi_spi_spl.c
+++ b/drivers/mtd/spi/sunxi_spi_spl.c
@@ -284,4 +284,4 @@ static int spl_spi_load_image(struct spl_image_info 
*spl_image,
return 0;
 }
 /* Use priorty 0 to override the default if it happens to be linked in */
-SPL_LOAD_IMAGE_METHOD("sunxi SPI" 0, BOOT_DEVICE_SPI, spl_spi_load_image);
+SPL_LOAD_IMAGE_METHOD("sunxi SPI", 0, BOOT_DEVICE_SPI, spl_spi_load_image);
-- 
2.9.3

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

Re: [U-Boot] [PATCH RESEND v2 1/2] spi: cadence_qspi_apb: Use 32 bit indirect write transaction when possible

[R, Vignesh]

On 12/21/2016 10:42 AM, Vignesh R wrote:
> According to Section 11.15.4.9.2 Indirect Write Controller of K2G SoC
> TRM SPRUHY8D[1], the external master is only permitted to issue 32-bit
> data interface writes until the last word of an indirect transfer
> otherwise indirect writes is known to fails sometimes. So, make sure
> that QSPI indirect writes are 32 bit sized except for the last write. If
> the txbuf is unaligned then use bounce buffer to avoid data aborts.
> 
> So, now that the driver uses bounce_buffer, enable CONFIG_BOUNCE_BUFFER
> for all boards that use Cadence QSPI driver.
> 
> [1]www.ti.com/lit/ug/spruhy8d/spruhy8d.pdf
> 
> Signed-off-by: Vignesh R 
> Reviewed-by: Marek Vasut 

Gentle ping on the series...

> ---
> 
> Resend v2: Rebased on latest rc.
> Link to v2:https://patchwork.ozlabs.org/patch/698614/
> 
>  drivers/spi/cadence_qspi_apb.c   | 26 --
>  include/configs/k2g_evm.h|  1 +
>  include/configs/socfpga_common.h |  1 +
>  include/configs/stv0991.h|  1 +
>  4 files changed, 23 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
> index df6a91fc9f7b..5d5b6f0d350b 100644
> --- a/drivers/spi/cadence_qspi_apb.c
> +++ b/drivers/spi/cadence_qspi_apb.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "cadence_qspi.h"
>  
>  #define CQSPI_REG_POLL_US1 /* 1us */
> @@ -724,6 +725,17 @@ int cadence_qspi_apb_indirect_write_execute(struct 
> cadence_spi_platdata *plat,
>   unsigned int remaining = n_tx;
>   unsigned int write_bytes;
>   int ret;
> + struct bounce_buffer bb;
> + u8 *bb_txbuf;
> +
> + /*
> +  * Handle non-4-byte aligned accesses via bounce buffer to
> +  * avoid data abort.
> +  */
> + ret = bounce_buffer_start(, (void *)txbuf, n_tx, GEN_BB_READ);
> + if (ret)
> + return ret;
> + bb_txbuf = bb.bounce_buffer;
>  
>   /* Configure the indirect read transfer bytes */
>   writel(n_tx, plat->regbase + CQSPI_REG_INDIRECTWRBYTES);
> @@ -734,11 +746,11 @@ int cadence_qspi_apb_indirect_write_execute(struct 
> cadence_spi_platdata *plat,
>  
>   while (remaining > 0) {
>   write_bytes = remaining > page_size ? page_size : remaining;
> - /* Handle non-4-byte aligned access to avoid data abort. */
> - if (((uintptr_t)txbuf % 4) || (write_bytes % 4))
> - writesb(plat->ahbbase, txbuf, write_bytes);
> - else
> - writesl(plat->ahbbase, txbuf, write_bytes >> 2);
> + writesl(plat->ahbbase, bb_txbuf, write_bytes >> 2);
> + if (write_bytes % 4)
> + writesb(plat->ahbbase,
> + bb_txbuf + rounddown(write_bytes, 4),
> + write_bytes % 4);
>  
>   ret = wait_for_bit("QSPI", plat->regbase + CQSPI_REG_SDRAMLEVEL,
>  CQSPI_REG_SDRAMLEVEL_WR_MASK <<
> @@ -748,7 +760,7 @@ int cadence_qspi_apb_indirect_write_execute(struct 
> cadence_spi_platdata *plat,
>   goto failwr;
>   }
>  
> - txbuf += write_bytes;
> + bb_txbuf += write_bytes;
>   remaining -= write_bytes;
>   }
>  
> @@ -759,6 +771,7 @@ int cadence_qspi_apb_indirect_write_execute(struct 
> cadence_spi_platdata *plat,
>   printf("Indirect write completion error (%i)\n", ret);
>   goto failwr;
>   }
> + bounce_buffer_stop();
>  
>   /* Clear indirect completion status */
>   writel(CQSPI_REG_INDIRECTWR_DONE,
> @@ -769,6 +782,7 @@ failwr:
>   /* Cancel the indirect write */
>   writel(CQSPI_REG_INDIRECTWR_CANCEL,
>  plat->regbase + CQSPI_REG_INDIRECTWR);
> + bounce_buffer_stop();
>   return ret;
>  }
>  
> diff --git a/include/configs/k2g_evm.h b/include/configs/k2g_evm.h
> index 2da0d8dd7f00..4f9c42abac7e 100644
> --- a/include/configs/k2g_evm.h
> +++ b/include/configs/k2g_evm.h
> @@ -78,6 +78,7 @@
>  #define CONFIG_CADENCE_QSPI
>  #define CONFIG_CQSPI_REF_CLK 38400
>  #define CONFIG_CQSPI_DECODER 0x0
> +#define CONFIG_BOUNCE_BUFFER
>  #endif
>  
>  #endif /* __CONFIG_K2G_EVM_H */
> diff --git a/include/configs/socfpga_common.h 
> b/include/configs/socfpga_common.h
> index 58a655084491..e50c2fac8d99 100644
> --- a/include/configs/socfpga_common.h
> +++ b/include/configs/socfpga_common.h
> @@ -208,6 +208,7 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
>  #define CONFIG_CQSPI_REF_CLK cm_get_qspi_controller_clk_hz()
>  #endif
>  #define CONFIG_CQSPI_DECODER 0
> +#define CONFIG_BOUNCE_BUFFER
>  
>  /*
>   * Designware SPI support
> diff --git a/include/configs/stv0991.h b/include/configs/stv0991.h
> index bfd1bd719285..09a3064bd6d6 100644
> --- a/include/configs/stv0991.h
> +++ b/include/configs/stv0991.h
> @@ 

Re: [U-Boot] am335x board i2c_probe fails from nand boot

[matti kaasinen]

2017-01-03 14:33 GMT+02:00 matti kaasinen :

> One reason why I2C configuration is wrong in nand mode could be the fact
> that I have CONFIG_TI_I2C_BOARD_DETECT variable is undefined (because I do
> not have that eeprom). But it looks that do_board_detect runs
> enable_i2c0_pin_mux() that I do not run separately. On the other hand, that
> does not explain why mmc boot works.



Now I did this I2C0 configuration separately prior to running i2c_probe().
Nand boot went further now. However, main u-boot did not start properly. I
got following messages
Trying to boot from NAND
The Expected Linux image was not found. Please check your NAND
configuration.
Trying to start u-boot now...

 more messages 
Press SPACE to abort autoboot in 2 seconds
Card did not respond to voltage select!
Card did not respond to voltage select!
Card did not respond to voltage select!
Card did not respond to voltage select!
Card did not respond to voltage select!
data abort
pc : [<8ff70f94>]  lr : [<8ff701dd>]
reloc pc : [<8081df94>]lr : [<8081d1dd>]
sp : 8ef28678  ip : 8ff5891d fp : 0003
r10: 8ffb3af8  r9 : 8ef32ed8 r8 : 8ef41e40
r7 : 8ff584bd  r6 : 8ef39478 r5 : 8ef39500  r4 : 4781
r3 : 8ff70f85  r2 : 0d8d r1 :   r0 : 8ef39500
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32
Resetting CPU ...

resetting ...

And game over
So, it's not quite sure that voltage adjustments went through even though
I2C did not complain anymore.
There could be something wrong with nand settings, too. I need to check
where these complaints are coming.

Thanks anyway for your comments,
Matti
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] am335x board i2c_probe fails from nand boot

[matti kaasinen]

2017-01-03 13:16 GMT+02:00 Lokesh Vutla :

> > Would anyone have idea why spl boot fails in i2c_probe when running from
> > nand but not when running from mmc card or anything at all to check?
>
> Do you have different mux configurations for different boot modes?(Just
> wondering if mux is properly configured for i2c in nand boot)
>
> No, not that I know and can detect from the board file. In fact it looks
like mmc boot has the correct configuration.

> >
> > My card is am335x based board with u-boot coming from u-boot-it v2016.05.
>
> Can you specify the tree? Also which config are you using and what board
> it it?
>
I have been using youcto/poky build system with meta-ti layer that brings
up u-boot-ti-staging.
I have patched board/ti/am335x/board.c and mux.c. I have used am335x_evm
config that I have had to patch somewhat to suit my board.
Board resembles somewhat am335x_evm but it does not have configuration
eeprom, has different ddr3 chips. Also, it has different PMIC (same as
beaglebone). Therefore I need to patch guite a lot. One reason why I2C
configuration is wrong in nand mode could be the fact that I have
CONFIG_TI_I2C_BOARD_DETECT variable is undefined (because I do not have
that eeprom). But it looks that do_board_detect runs enable_i2c0_pin_mux()
that I do not run separately. On the other hand, that does not explain why
mmc boot works.

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

Re: [U-Boot] am335x board i2c_probe fails from nand boot

[Lokesh Vutla]

On Tuesday 03 January 2017 02:56 PM, matti kaasinen wrote:
> Hi!
> 
> Would anyone have idea why spl boot fails in i2c_probe when running from
> nand but not when running from mmc card or anything at all to check?

Do you have different mux configurations for different boot modes?(Just
wondering if mux is properly configured for i2c in nand boot)

> 
> My card is am335x based board with u-boot coming from u-boot-it v2016.05.

Can you specify the tree? Also which config are you using and what board
it it?

Thanks and regards,
Lokesh

> 
> Spl boot crashes when it tries to run i2c_probe getting timeout in
> omap24.._i2c.c/wait_for_event() function. Boot enters wait_for_event() only
> once, if spl boot is coming from nand and exiting with:
> "Timed out in wait_for_event: status=
> Check if pads/pull-ups of bus are properly configured",
> 
> However, if spl comes from mmc card, everything goes well, wait_for_event
> is executed tens of times without problem.
> 
> All help very well appreciated!!
> 
> Thanks,
> Matti
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] am335x board i2c_probe fails from nand boot

[matti kaasinen]

I could try that, but how does it work properly when I run it from mmc.
Does reading spl from mmc touch I2C somehow (interrupt, speed or anything)
or does reading spl from nand do that.

2017-01-03 13:05 GMT+02:00 Yegor Yefremov :

> On Tue, Jan 3, 2017 at 12:02 PM, matti kaasinen
>  wrote:
> >
> > 2017-01-03 12:56 GMT+02:00 Yegor Yefremov :
> >>
> >> What PMIC are you using?
> >
> > It is TPS65217, so probe command is:
> >  i2c_probe(TPS65217_CHIP_PM)
>
> I had some problems with tps65910. Anyway try to reduce I2C speed up
> to 1000. The kernel can still run the full speed. It's only for
> bootloader stage.
>
> Yegor
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] am335x board i2c_probe fails from nand boot

[Yegor Yefremov]

On Tue, Jan 3, 2017 at 12:02 PM, matti kaasinen
 wrote:
>
> 2017-01-03 12:56 GMT+02:00 Yegor Yefremov :
>>
>> What PMIC are you using?
>
> It is TPS65217, so probe command is:
>  i2c_probe(TPS65217_CHIP_PM)

I had some problems with tps65910. Anyway try to reduce I2C speed up
to 1000. The kernel can still run the full speed. It's only for
bootloader stage.

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

Re: [U-Boot] am335x board i2c_probe fails from nand boot

[matti kaasinen]

2017-01-03 12:56 GMT+02:00 Yegor Yefremov :

> What PMIC are you using?
>
It is TPS65217, so probe command is:
 i2c_probe(TPS65217_CHIP_PM)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] am335x board i2c_probe fails from nand boot

[Yegor Yefremov]

Hi Matti,

On Tue, Jan 3, 2017 at 10:26 AM, matti kaasinen
 wrote:
> Hi!
>
> Would anyone have idea why spl boot fails in i2c_probe when running from
> nand but not when running from mmc card or anything at all to check?
>
> My card is am335x based board with u-boot coming from u-boot-it v2016.05.
>
> Spl boot crashes when it tries to run i2c_probe getting timeout in
> omap24.._i2c.c/wait_for_event() function. Boot enters wait_for_event() only
> once, if spl boot is coming from nand and exiting with:
> "Timed out in wait_for_event: status=
> Check if pads/pull-ups of bus are properly configured",
>
> However, if spl comes from mmc card, everything goes well, wait_for_event
> is executed tens of times without problem.
>
> All help very well appreciated!!

What PMIC are you using?

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

Re: [U-Boot] [linux-sunxi] [PATCH v4 00/26] sunxi: Allwinner A64: SPL support

[Jagan Teki]

On Tue, Jan 3, 2017 at 3:38 AM, jonsm...@gmail.com  wrote:
> I recently ran into a probably with the UARTs on the A64. Many
> Bluetooth modules (like Ampak) use the UART. The data rate of EDR BT
> is 3Mb/s with about 2.1Mb/s though put. To handle this most systems
> set the speed of the BT UART to 3Mb/s.
>
> By default the Allwinner UART clock input is OSC24. When using OSC24
> the maximum speed the UART can be set to is 1.5Mb/s. The clock input
> (apb2) can be changed over to PERIPH0x2 (1.2ghz) via the device tree
> and 3Mb/s is then supported.
>
> But... there's a problem, UART0 (the console) is using the same master
> clock source. So when you change the clock input over to PERIPH0x2 the
> console stops working. There is no mechanism in Linux to handle this
> clock source change and adjust the dividers on active uarts. So it
> would be best if this master clock was set very early in u-boot and
> then the console is adjusted to use it.
>
> Are there any downsides to making this change in u-boot?

I don't understand, did you find this behaviour with these SPL changes
or general sunxi u-boot?

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

[U-Boot] am335x board i2c_probe fails from nand boot

[matti kaasinen]

Hi!

Would anyone have idea why spl boot fails in i2c_probe when running from
nand but not when running from mmc card or anything at all to check?

My card is am335x based board with u-boot coming from u-boot-it v2016.05.

Spl boot crashes when it tries to run i2c_probe getting timeout in
omap24.._i2c.c/wait_for_event() function. Boot enters wait_for_event() only
once, if spl boot is coming from nand and exiting with:
"Timed out in wait_for_event: status=
Check if pads/pull-ups of bus are properly configured",

However, if spl comes from mmc card, everything goes well, wait_for_event
is executed tens of times without problem.

All help very well appreciated!!

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

Re: [U-Boot] [PATCH] i2c: mux: Allow muxes to work as children of i2c bus without i2c-parent

[Michal Simek]

On 2.1.2017 20:20, Moritz Fischer wrote:
> Hi Michal,
> 
> On Mon, Jan 2, 2017 at 6:24 AM, Michal Simek  wrote:
>> On 29.12.2016 23:50, Moritz Fischer wrote:
>>> For mux check if the parent is already a device of UCLASS_I2C and if yes
>>> just use that. Otherwise see if someone specified an i2c-parent phandle.
>>> This mimics the behavior found in the Kernel, as it removes the
>>> requirement to explicitly specify a i2c-parent phandle.
>>>
>>> Signed-off-by: Moritz Fischer 
>>> Cc: Heiko Schocher 
>>> Cc: Bin Meng 
>>> Cc: Simon Glass 
>>> Cc: Michal Simek 
>>> Cc: u-boot@lists.denx.de
>>> ---
>>>  drivers/i2c/muxes/i2c-mux-uclass.c | 9 +
>>>  1 file changed, 9 insertions(+)
>>>
>>> diff --git a/drivers/i2c/muxes/i2c-mux-uclass.c 
>>> b/drivers/i2c/muxes/i2c-mux-uclass.c
>>> index 7a698b6..e01b773 100644
>>> --- a/drivers/i2c/muxes/i2c-mux-uclass.c
>>> +++ b/drivers/i2c/muxes/i2c-mux-uclass.c
>>> @@ -86,6 +86,15 @@ static int i2c_mux_post_probe(struct udevice *mux)
>>>   debug("%s: %s\n", __func__, mux->name);
>>>   priv->selected = -1;
>>>
>>> + /* if parent is of i2c uclass already, we'll take that, otherwise
>>> +  * look if we find an i2c-parent phandle */
>>
>> Incorrect comment style.
> 
> Yeah, wasn't flagged by checkpatch  will fix.
>>
>>> + if (UCLASS_I2C == device_get_uclass_id(mux->parent)) {
>>> + priv->i2c_bus = dev_get_parent(mux);
>>> + debug("%s: bus=%p/%s\n", __func__, priv->i2c_bus,
>>> +   priv->i2c_bus->name);
>>> + return 0;
>>> + }
>>> +
>>>   ret = uclass_get_device_by_phandle(UCLASS_I2C, mux, "i2c-parent",
>>>  >i2c_bus);
>>>   if (ret)
>>>
>>
>> The part of this will be good to also handle
>> req_seq for mux busses. But at least this should solved part of the
>> problems.
> 
> I'm not sure I understand this comment.

AFAIK using i2c muxes requires two changes in DTS file.
First change is this to setup i2c-parent in DTS file which is something
what Linux doesn't need.
The next change is that you have to extend i2c aliases to point to i2c
mux sub busses which is the second thing what Linux doesn't need.
I expect that this change you have in your dts file.

I think that if you detect mux with 8 ports you can simply use unique
busid to be able to address them.

Thanks,
Michal

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

Re: [U-Boot] [PATCH V2 20/20] imx: mx7ulp_evk: enable mmc/regulator support

[Peng Fan]

Hi Stefano,

On Tue, Dec 27, 2016 at 12:07:40PM +, Peng Fan wrote:
>
>
>> -Original Message-
>> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Fabio
>> Estevam
>> Sent: Tuesday, December 27, 2016 7:23 PM
>> To: Peng Fan 
>> Cc: U-Boot-Denx 
>> Subject: Re: [U-Boot] [PATCH V2 20/20] imx: mx7ulp_evk: enable
>> mmc/regulator support
>> 
>> On Tue, Dec 27, 2016 at 8:04 AM, Peng Fan  wrote:
>> 
>> > +#define CONFIG_EXTRA_ENV_SETTINGS \
>> > +   "script=boot.scr\0" \
>> > +   "image=zImage\0" \
>> > +   "console=ttyLP0\0" \
>> > +   "fdt_high=0x\0" \
>> > +   "initrd_high=0x\0" \
>> > +   "fdt_file=imx7ulp-evk.dtb\0" \
>> > +   "fdt_addr=0x6300\0" \
>> > +   "boot_fdt=try\0" \
>> 
>> On this platform we will always boot from dt, so we can remove this 
>> variable...
>
>
>Fix in v3.

I do not see more comments on the patch set.
Can I post a follow up patch to fix this, but not send out a whole V3 patch set?

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

Re: [U-Boot] [PATCH] ARM: zynqmp: Make SYS_VENDOR configurable

[Michal Simek]

On 3.1.2017 09:47, Mike Looijmans wrote:
> Add a string description for SYS_VENDOR to allow configuring boards from
> other vendors than just "xilinx".
> ---
>  arch/arm/cpu/armv8/zynqmp/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/cpu/armv8/zynqmp/Kconfig 
> b/arch/arm/cpu/armv8/zynqmp/Kconfig
> index e175e6e..499e1dd 100644
> --- a/arch/arm/cpu/armv8/zynqmp/Kconfig
> +++ b/arch/arm/cpu/armv8/zynqmp/Kconfig
> @@ -28,6 +28,7 @@ config SYS_BOARD
>   default "zynqmp"
>  
>  config SYS_VENDOR
> + string "Vendor name"
>   default "xilinx"
>  
>  config SYS_SOC
> 

Applied.

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

[U-Boot] [PATCH] ARM: zynqmp: Make SYS_VENDOR configurable

[Mike Looijmans]

Add a string description for SYS_VENDOR to allow configuring boards from
other vendors than just "xilinx".
---
 arch/arm/cpu/armv8/zynqmp/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/cpu/armv8/zynqmp/Kconfig 
b/arch/arm/cpu/armv8/zynqmp/Kconfig
index e175e6e..499e1dd 100644
--- a/arch/arm/cpu/armv8/zynqmp/Kconfig
+++ b/arch/arm/cpu/armv8/zynqmp/Kconfig
@@ -28,6 +28,7 @@ config SYS_BOARD
default "zynqmp"
 
 config SYS_VENDOR
+   string "Vendor name"
default "xilinx"
 
 config SYS_SOC
-- 
1.9.1

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