Re: [U-Boot] [PATCH V6] ARM: mx6: Add support for Kosagi Novena
Hi Marek, On 10/11/2014 04:24 AM, Marek Vasut wrote: On Friday, October 10, 2014 at 03:39:08 AM, Nikolay Dimitrov wrote: Hi Marek, The usual stuff follows :D. On 10/10/2014 02:22 AM, Marek Vasut wrote: +#define NOVENA_BUTTON_GPIO IMX_GPIO_NR(4, 14) +#define NOVENA_SD_WP IMX_GPIO_NR(1, 2) +#define NOVENA_SD_CD IMX_GPIO_NR(1, 4) NOVENA_BUTTON_GPIO is initialized as input in this source file, but the NOVENA_SD_WP and NOVENA_SD_CD are not. They're initialized only in novena_spl.c, and if you change the SPL configuration, they won't be explicitly initialized. While by pure luck the iomuxc reset values are those of the GPIO pins, I would vote for explicit initialization of WP CD. And btw, it's cool that you added the WP pin, I totally missed this out last time I was staring at the schematic. I disagree that doing the initialization of pinmux twice is necessary, the SPL will always run before the rest of the software, so it will do the pinmux init. If you mean GPIO direction, then that's done in V7. I also agree that there's no need to pinmux twice. And yes, what I meant was to set the WP/CD GPIOs pin directions, so thanks for fixing that. Regards, Nikolay ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] sf: Add support for flag status register on Micron chips
Enter 3 Byte address mode at first, because it may change to 4 Byte
address mode in kernel driver and not reset to 3 Byte address mode
after reboot.
Add clear flag status register operation that some Micron SPI flash
chips required after reading the flag status register to check some
operations completion.
Signed-off-by: Hou Zhiqiang b48...@freescale.com
Signed-off-by: Mingkai.Hu mingkai...@freescale.com
---
V1:
Based on git://git.denx.de/u-boot.git.
Also can be applied to git://www.denx.de/git/u-boot-mpc85xx.git.
Tested on board T2080QDS and T2080RDB.
V2:
Add the operation of enter 3 Byte address mode in probe.
drivers/mtd/spi/sf_internal.h | 17
drivers/mtd/spi/sf_ops.c | 64 +--
drivers/mtd/spi/sf_probe.c| 5
3 files changed, 78 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 19d4914..49e5a2c 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -36,6 +36,11 @@
#define CMD_WRITE_ENABLE 0x06
#define CMD_READ_CONFIG0x35
#define CMD_FLAG_STATUS0x70
+#define CMD_CLEAR_FLAG_STATUS 0x50
+
+/* Used for Macronix and Winbond flashes */
+#defineCMD_ENTER_4B_ADDR 0xB7
+#defineCMD_EXIT_4B_ADDR0xE9
/* Read commands */
#define CMD_READ_ARRAY_SLOW0x03
@@ -59,6 +64,8 @@
#define STATUS_QEB_WINSPAN (1 1)
#define STATUS_QEB_MXIC(1 6)
#define STATUS_PEC (1 7)
+#define STATUS_PROT(1 1)
+#define STATUS_ERASE (1 5)
#ifdef CONFIG_SYS_SPI_ST_ENABLE_WP_PIN
#define STATUS_SRWD(1 7) /* SR write protect */
@@ -124,6 +131,12 @@ static inline int spi_flash_cmd_write_disable(struct
spi_flash *flash)
return spi_flash_cmd(flash-spi, CMD_WRITE_DISABLE, NULL, 0);
}
+/* Clear flag status register */
+static inline int spi_flash_cmd_clear_flag_status(struct spi_flash *flash)
+{
+ return spi_flash_cmd(flash-spi, CMD_CLEAR_FLAG_STATUS, NULL, 0);
+}
+
/*
* Send the read status command to the device and wait for the wip
* (write-in-progress) bit to clear itself.
@@ -160,4 +173,8 @@ int spi_flash_read_common(struct spi_flash *flash, const u8
*cmd,
int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 offset,
size_t len, void *data);
+#if defined(CONFIG_SPI_FLASH_STMICRO)
+int spi_flash_cmd_4B_addr_switch(struct spi_flash *flash, int enable);
+#endif
+
#endif /* _SF_INTERNAL_H_ */
diff --git a/drivers/mtd/spi/sf_ops.c b/drivers/mtd/spi/sf_ops.c
index 85cf22d..8a532b8 100644
--- a/drivers/mtd/spi/sf_ops.c
+++ b/drivers/mtd/spi/sf_ops.c
@@ -93,6 +93,30 @@ int spi_flash_cmd_write_config(struct spi_flash *flash, u8
wc)
}
#endif
+#if defined(CONFIG_SPI_FLASH_STMICRO)
+int spi_flash_cmd_4B_addr_switch(struct spi_flash *flash, int enable)
+{
+ int ret;
+ u8 cmd;
+
+ cmd = enable ? CMD_ENTER_4B_ADDR : CMD_EXIT_4B_ADDR;
+
+ ret = spi_claim_bus(flash-spi);
+ if (ret) {
+ debug(SF: unable to claim SPI bus\n);
+ return ret;
+ }
+
+ ret = spi_flash_cmd_write_enable(flash);
+ if (ret 0) {
+ debug(SF: enabling write failed\n);
+ return ret;
+ }
+
+ return spi_flash_cmd(flash-spi, cmd, NULL, 0);
+}
+#endif
+
#ifdef CONFIG_SPI_FLASH_BAR
static int spi_flash_cmd_bankaddr_write(struct spi_flash *flash, u8 bank_sel)
{
@@ -160,6 +184,7 @@ int spi_flash_cmd_wait_ready(struct spi_flash *flash,
unsigned long timeout)
unsigned long timebase;
unsigned long flags = SPI_XFER_BEGIN;
int ret;
+ int out_of_time = 1;
u8 status;
u8 check_status = 0x0;
u8 poll_bit = STATUS_WIP;
@@ -186,22 +211,45 @@ int spi_flash_cmd_wait_ready(struct spi_flash *flash,
unsigned long timeout)
WATCHDOG_RESET();
ret = spi_xfer(spi, 8, NULL, status, 0);
- if (ret)
+ if (ret) {
+ spi_xfer(spi, 0, NULL, NULL, SPI_XFER_END);
return -1;
+ }
- if ((status poll_bit) == check_status)
+ if ((status poll_bit) == check_status) {
+ out_of_time = 0;
break;
+ }
} while (get_timer(timebase) timeout);
spi_xfer(spi, 0, NULL, NULL, SPI_XFER_END);
- if ((status poll_bit) == check_status)
- return 0;
+ if (out_of_time) {
+ /* Timed out */
+ debug(SF: time out!\n);
+ if (cmd == CMD_FLAG_STATUS) {
+ if (spi_flash_cmd_clear_flag_status(flash) 0)
+ debug(SF: clear flag status failed\n);
+ }
+ ret =
Re: [U-Boot] [PULL] u-boot-socfpga/topic/arm/socfpga-20141010
Hi Marek, On Sat, 11 Oct 2014 01:11:46 +0200, Marek Vasut ma...@denx.de wrote: The following changes since commit db67801bf92f7fae6131dbc0d387131698fb9490: Merge branch 'master' of git://git.denx.de/u-boot-nand-flash (2014-10-10 09:45:16 -0400) are available in the git repository at: git://git.denx.de/u-boot-socfpga.git topic/arm/socfpga-20141010 for you to fetch changes up to 5a1d0ad3ee1ba98ca273c4b35c68618f107ccadd: arm: socfpga: Use EMAC1 on SoCDK (2014-10-11 00:50:33 +0200) Marek Vasut (1): arm: socfpga: Use EMAC1 on SoCDK Pavel Machek (1): arm: socfpga: add MAINTAINERS entry MAINTAINERS| 7 +++ include/configs/socfpga_cyclone5.h | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] kconfig: add CONFIG_SUPPORT_TPL
Hi Masahiro, On Thu, 25 Sep 2014 18:19:07 +0900, Masahiro Yamada yamad...@jp.panasonic.com wrote: CONFIG_TPL should not be enabled for boards that do not have TPL. CONFIG_SUPPORT_TPL introduced by this commit should be selected by boards with TPL support and CONFIG_TPL should depend on it. Actually, I see no CONFIG_SUPPORT_TPL in the patch, only HAVE_TPL_SUPPORT. The commit message should match the patch content on this point, should it not? Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- Kconfig | 5 - arch/powerpc/cpu/mpc85xx/Kconfig | 5 + 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/Kconfig b/Kconfig index 29e0b92..0b9be50 100644 --- a/Kconfig +++ b/Kconfig @@ -73,6 +73,9 @@ config TPL_BUILD config SUPPORT_SPL bool +config HAVE_TPL_SUPPORT + bool + config SPL bool depends on SUPPORT_SPL @@ -83,7 +86,7 @@ config SPL config TPL bool - depends on SPL + depends on SPL HAVE_TPL_SUPPORT prompt Enable TPL if !SPL_BUILD default y if TPL_BUILD default n diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig index 6dcc45a..c5ebd40 100644 --- a/arch/powerpc/cpu/mpc85xx/Kconfig +++ b/arch/powerpc/cpu/mpc85xx/Kconfig @@ -31,6 +31,7 @@ config TARGET_BSC9132QDS config TARGET_C29XPCIE bool Support C29XPCIE select SUPPORT_SPL + select SUPPORT_TPL config TARGET_P3041DS bool Support P3041DS @@ -77,10 +78,12 @@ config TARGET_MPC8572DS config TARGET_P1010RDB bool Support P1010RDB select SUPPORT_SPL + select SUPPORT_TPL config TARGET_P1022DS bool Support P1022DS select SUPPORT_SPL + select SUPPORT_TPL config TARGET_P1023RDB bool Support P1023RDB @@ -88,10 +91,12 @@ config TARGET_P1023RDB config TARGET_P1_P2_RDB bool Support P1_P2_RDB select SUPPORT_SPL + select SUPPORT_TPL config TARGET_P1_P2_RDB_PC bool Support p1_p2_rdb_pc select SUPPORT_SPL + select SUPPORT_TPL config TARGET_P1_TWR bool Support p1_twr Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] arm: relocate the exception vectors
Hi Georges,
On Sat, 27 Sep 2014 21:48:10 +0200, Georges Savoundararadj
savou...@gmail.com wrote:
This commit relocates the exception vectors.
As ARM1176 and ARMv7 have the security extensions, it uses VBAR. For
the other ARM processors, it copies the relocated exception vectors to
the correct address: 0x or 0x.
Signed-off-by: Georges Savoundararadj savou...@gmail.com
Cc: Albert Aribaud albert.u.b...@aribaud.net
Cc: Tom Warren twar...@nvidia.com
---
This patch needs some tests because it impacts many boards. I have
tested it with my raspberry pi in the two cases: using VBAR and
using the copied exception vectors.
Changes in v2:
- Relocate exception vectors also on processors which do not support
security extensions
- Reword the commit message
arch/arm/cpu/armv7/start.S | 6 --
arch/arm/lib/relocate.S| 30 ++
2 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index fedd7c8..fdc05b9 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -81,12 +81,6 @@ ENTRY(c_runtime_cpu_setup)
mcr p15, 0, r0, c7, c10, 4 @ DSB
mcr p15, 0, r0, c7, c5, 4 @ ISB
#endif
-/*
- * Move vector table
- */
- /* Set vector address in CP15 VBAR register */
- ldr r0, =_start
- mcr p15, 0, r0, c12, c0, 0 @Set VBAR
bx lr
diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
index 8035251..88a478e 100644
--- a/arch/arm/lib/relocate.S
+++ b/arch/arm/lib/relocate.S
@@ -6,6 +6,8 @@
* SPDX-License-Identifier: GPL-2.0+
*/
+#include asm-offsets.h
+#include config.h
#include linux/linkage.h
/*
@@ -52,6 +54,34 @@ fixnext:
cmp r2, r3
blo fixloop
+ /*
+ * Relocate the exception vectors
+ */
+#if (defined(CONFIG_ARM1176) || defined(CONFIG_ARMV7))
I would prefer a single CONFIG_HAS_VBAR symbol defined through
Kconfig.
+ /*
+ * If the ARM processor has the security extensions,
+ * use VBAR to relocate the exception vectors.
+ */
+ ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd-relocaddr */
+ mcr p15, 0, r0, c12, c0, 0 /* Set VBAR */
+#else
+ /*
+ * Copy the relocated exception vectors to the
+ * correct address
+ * CP15 c1 V bit gives us the location of the vectors:
+ * 0x or 0x.
+ */
+ ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd-relocaddr */
+ mrc p15, 0, r2, c1, c0, 0 /* V bit (bit[13]) in CP15 c1 */
+ andsr2, r2, #(1 13)
+ ldreq r1, =0x /* If V=0 */
+ ldrne r1, =0x /* If V=1 */
+ ldmia r0!, {r2-r8,r10}
+ stmia r1!, {r2-r8,r10}
+ ldmia r0!, {r2-r8,r10}
+ stmia r1!, {r2-r8,r10}
+#endif
+
relocate_done:
#ifdef __XSCALE__
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ARM: prevent compiler warnings from bootm.c
Hi Eric,
On Tue, 30 Sep 2014 15:40:01 -0700, Eric Nelson
eric.nel...@boundarydevices.com wrote:
Without preceding declarations, make C=1 generates
Should it be static? warnings for symbols
do_bootm_linux,
boot_prep_vxworks, and
boot_jump_vxworks
Include of bootm.h also identified a signature mismatch
(const on argv[]).
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
arch/arm/lib/bootm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 39fe7a1..4949d57 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -22,6 +22,8 @@
#include asm/bootm.h
#include asm/secure.h
#include linux/compiler.h
+#include bootm.h
+#include vxworks.h
#if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
#include asm/armv7.h
@@ -299,7 +301,8 @@ static void boot_jump_linux(bootm_headers_t *images, int
flag)
* DIFFERENCE: Instead of calling prep and go at the end
* they are called if subcommand is equal 0.
*/
-int do_bootm_linux(int flag, int argc, char *argv[], bootm_headers_t *images)
+int do_bootm_linux(int flag, int argc, char * const argv[],
+bootm_headers_t *images)
{
/* No need for those on ARM */
if (flag BOOTM_STATE_OS_BD_T || flag BOOTM_STATE_OS_CMDLINE)
Acked-by: Albert ARIBAUD albert.u.b...@aribaud.net
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] ARMv8: PSCI: Add linker section to hold PSCI code
Hi Albert,
On Fri, 19 Sep 2014 18:04:14 +0200, Albert ARIBAUD
albert.u.b...@aribaud.net wrote:
Hi Marc,
On Thu, 18 Sep 2014 16:28:52 +0100, Marc Zyngier marc.zyng...@arm.com
wrote:
On Thu, Sep 18 2014 at 10:12:17 AM, Albert ARIBAUD
albert.u.b...@aribaud.net wrote:
Hi Arnab,
On Thu, 28 Aug 2014 01:59:57 +0530, Arnab Basu
arnab.b...@freescale.com wrote:
A separate linker section makes it possible to keep this code either
in DDR or in some secure memory location provided specifically for the
purpose.
So far no one is using this section.
Signed-off-by: Arnab Basu arnab.b...@freescale.com
Reviewed-by: Bhupesh Sharma bhupesh.sha...@freescale.com
Cc: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/config.mk|2 +-
arch/arm/cpu/armv8/u-boot.lds | 30 ++
2 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index c339e6d..9272e9c 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -111,7 +111,7 @@ endif
# limit ourselves to the sections we want in the .bin.
ifdef CONFIG_ARM64
-OBJCOPYFLAGS += -j .text -j .rodata -j .data -j .u_boot_list -j
.rela.dyn
+OBJCOPYFLAGS += -j .text -j .secure_text -j .rodata -j .data -j
.u_boot_list -j .rela.dyn
else
OBJCOPYFLAGS += -j .text -j .secure_text -j .rodata -j .hash -j .data
-j .got.plt -j .u_boot_list -j .rel.dyn
endif
diff --git a/arch/arm/cpu/armv8/u-boot.lds
b/arch/arm/cpu/armv8/u-boot.lds
index 4c1..bd95fff 100644
--- a/arch/arm/cpu/armv8/u-boot.lds
+++ b/arch/arm/cpu/armv8/u-boot.lds
@@ -8,6 +8,8 @@
* SPDX-License-Identifier: GPL-2.0+
*/
+#include config.h
+
OUTPUT_FORMAT(elf64-littleaarch64, elf64-littleaarch64,
elf64-littleaarch64)
OUTPUT_ARCH(aarch64)
ENTRY(_start)
@@ -23,6 +25,34 @@ SECTIONS
*(.text*)
}
+#ifdef CONFIG_ARMV8_PSCI
+
+#ifndef CONFIG_ARMV8_SECURE_BASE
+#define CONFIG_ARMV8_SECURE_BASE
+#endif
+
+.__secure_start : {
+. = ALIGN(0x1000);
+*(.__secure_start)
+}
+
+.secure_text CONFIG_ARMV8_SECURE_BASE :
+AT(ADDR(.__secure_start) + SIZEOF(.__secure_start))
+{
+*(._secure.text)
+}
+
+. = LOADADDR(.__secure_start) +
+SIZEOF(.__secure_start) +
+SIZEOF(.secure_text);
+
+__secure_end_lma = .;
+.__secure_end : AT(__secure_end_lma) {
+*(.__secure_end)
+LONG(0x1d1071c);/* Must output something to
reset LMA */
Can you explain in more detail what issue this fixes?
If you use AT to force a new load address (LMA), you must ensure that
you actually output something at this address. Here, if *(.__secure_end)
ends up being empty, whatever follows would be as if the AT never
happened, ending up at the wrong LMA.
The workaround is to force the output of a dummy value in all
cases, ensuring that the rest of the text is at a sensible LMA. This is
an issue that has been in GNU ld for years, and this workaround is a
copy/paste of the same one in the ARMv7 ld script.
I see. Does the ld bug have an identifier that we could mention in a
comment in the linker script as a reference?
Ping.
Thanks,
M.
Amicalement,
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/7] arm: ls102xa: Add SD boot support for LS1021AQDS board
Hi Huan,
On Wed, 8 Oct 2014 09:53:03 +, Huan Wang
alison.w...@freescale.com wrote:
Hi, Albert,
On Thu, 25 Sep 2014 06:45:00 +, Huan Wang
alison.w...@freescale.com wrote:
Hi, Albert,
On Mon, 22 Sep 2014 06:46:20 +, Huan Wang
alison.w...@freescale.com wrote:
Hi, Albert,
On Thu, 18 Sep 2014 13:47:18 +0800, Alison Wang
b18...@freescale.com
wrote:
+
+ . = ALIGN(4);
+ .u_boot_list : {
+ KEEP(*(SORT(.u_boot_list*_i2c_*)));
+ }
IS this required? And if it is, could it not be added to the
arch/arm/cpu/u-boot-spl.lds file? This way you would not need
an .lds file at all.
[Alison Wang] Yes, it is required.
Ok -- what for? :)
[Alison Wang] In SPL part, DDR is initialized by reading SPD
through
I2C interface.
For I2C, ll_entry_count() is called, and it returns the number of
elements of a linker-generated array placed into subsection of
.u_boot_list section specified by _list argument. So I need to
add
this to make I2C work in SPL.
Understood. So your SPL code uses I2C, and for I2C, you need a
linker list. But then:
I would like to add it in arch/arm/cpu/u-boot-spl.lds. I was
not sure adding it in arch/arm/cpu/u-boot-spl.lds is
acceptable or
not.
(assuming the reason why it is needed is valid) If it causes no
change to boards which do not use it right now (and I mean 'no
change' ad 'binary identical') then this is acceptable. Make
sure you check the binary invariance and that you mention it in
the
commit.
[Alison Wang] It will cause the binary is not identical for other
board.
Is this a prediction or an actual observation of compared builds
with and without the I2C linker liste addition to the generic
SPL .lds?
[Alison Wang] I use mx31pdk as example. I compared the binaries with
and Without the I2C linker list in arch/arm/cpu/u-boot-spl.lds. The
binaries are not identical.
I have just checked mx31pdk: the u-boot binaries (u-boot, u-boot.bin,
u-boot-with-spl.bin, u-boot.map, u-boot.srec) are indeed different, but
that's just normal considering the repository state and build date and
time are included in the binaries [1].
OTOH, I see that the u-boot-spl.bin files are identical.
The only change I made between the two builds was inserting
. = ALIGN(4);
+ .u_boot_list : {
+ KEEP(*(SORT(.u_boot_list*_i2c_*)));
+ }
in arch/arm/cpu/u-boot-spl.lds at line 34.
Can you re-check?
[Alison Wang] Yes, you are right. u-boot-spl.bin files are identical. The
u-boot binaries
(u-boot, u-boot.bin, u-boot-with-spl.bin, u-boot.map, u-boot.srec) are
different only in build date and time.
[1] BTW, how do you folks out here proceed when trying to compare u-
boot.bin files from different builds of the same target without the
repo state or build date and time affecting the comparison? I use a
patch to Makefile that fakes the commit and repo state, and I also use
fakelib to force timestamps, but there might be a simpler way.
[Alison Wang] Oh, your way is very good. I just used vimdiff.
I'll run a larger-scale check today, to see which SPLs are affected by
adding u-boot_list*, not just u_boot_list*_i2c_*, i.e., maybe we can
make this identical in u-boot.lds and u-boot-spl.lds for ARM.
Best Regards,
Alison Wang
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: compiler.h: Fix build on FreeBSD
On Tue, Oct 07, 2014 at 10:42:27PM +0200, Jeroen Hofstee wrote: Commit 832472 tools: socfpga: Add socfpga preloader signing to mkimage added tools/socfpga.c which relies on htole32, le32toh and friends. While compiler.h includes these protypes for linux from endian.h, it doesn't do so for FreeBSD. Hence include sys/endian.h for FreeBSD. Cc: Marek Vasut ma...@denx.de CC: Tom Rini tr...@ti.com Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-arm/master
On Sat, Oct 11, 2014 at 02:38:24AM +0200, Albert ARIBAUD wrote: Hi Tom, The following changes since commit db67801bf92f7fae6131dbc0d387131698fb9490: Merge branch 'master' of git://git.denx.de/u-boot-nand-flash (2014-10-10 09:45:16 -0400) are available in the git repository at: git://git.denx.de/u-boot-arm master for you to fetch changes up to 3d420cbd355a5f09e4f113eb10579a264a8ef138: Merge branch 'u-boot-socfpga/topic/arm/socfpga-20141010' into 'u-boot-arm/master' (2014-10-11 01:20:55 +0200) Albert ARIBAUD (4): Merge remote-tracking branch 'u-boot-imx/master' Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master' Merge branch 'u-boot/master' into 'u-boot-arm/master' Merge branch 'u-boot-socfpga/topic/arm/socfpga-20141010' into 'u-boot-arm/master' Andreas Bießmann (2): macb: simplify gmac initialisation sama5d3xek: run PHY's config Andrew Ruder (2): arm: mx31: use common timer functions arm: mx35: use common timer functions Bo Shen (1): ARM: atmel: switch at91sam9263ek to generic board Christian Gmeiner (1): imx6: add Bachmann OT1200 board Diego Rondini (1): nitrogen6x: config: allow boot to USB stick Eric Nelson (23): nitrogen6x: Update DDR timings for 2G memory arrangement nitrogen6x: implement board_cfb_skip() to disable text output nitrogen6x: configure SD2 pads for SDIO on USDHC2 nitrogen6x: power-down miscellanous peripherals nitrogen6x: staticize board file nitrogen6x: prevent warnings about board_ehci* callbacks nitrogen6x: display: add qvga panel nitrogen6x: display: add support for LG-9.7 LVDS display nitrogen6x: display: add LDB-WXGA-S for SPWG 1280x800 displays nitrogen6x: display: add support for fusion 7 display nitrogen6x: display: add svga display (800x600) nitrogen6x: display: add Ampire 1024x600 panel nitrogen6x: display: add wvga-lvds panel nitrogen6x: display use I2C detect for HDMI nitrogen6x: config: add USB Mass Storage (ums) support nitrogen6x: config: add initrd_high nitrogen6x: config: expose SATA, then MMC over USB nitrogen6x: config: enable USB keyboard support nitrogen6x: config: add CONFIG_CMD_MEMTEST nitrogen6x: config: enable i2c edid nitrogen6x: config: disable logo nitrogen6x: config: add gpio command nitrogen6x: config: enable Android fastboot Fabio Estevam (9): mx6sxsabresd: Staticize i2c_pad_info1 mx6qsabreauto: Staticize when possible cm_fx6: Remove CONFIG_NETMASK mx51evk: Fix CONFIG_SYS_FSL_ESDHC_ADDR mx51evk: Add generic board support mx25pdk: Fix CONFIG_SYS_FSL_ESDHC_ADDR mx25pdk: Add generic board support wandboard: Select CONFIG_CMD_FUSE mx6sxsabresd: Fix PCI reset and power GPIO assignments Guillaume GARDET (1): imx: nitrogen6x: Make use of both uSD and SD slots to load script or kernel on Sabrelite board Heiko Schocher (1): arm, at91: add generic board support for the taurus and corvus board Kevin Mihelich (2): nitrogen6x: config: use FS_GENERIC load command nitrogen6x: config: enable EXT4 filesystem Marek Vasut (12): usb: ehci: mxs: Add board-specific callbacks arm: mxs: Wait when disabling VDDMEM current limiter arm: mxs: Wait for DRAM to start arm: mxs: olinuxino: Enable USB only when needed arm: mxs: olinuxino: Fine-tune DRAM configuration arm: m28evk: Test if bootscript exists before loading it arm: m53evk: Test if bootscript exists before loading it arm: m28evk: Enable FS_GENERIC arm: m53evk: Enable FS_GENERIC arm: m28evk: Zap superfluous tab in env arm: m53evk: Zap superfluous tab in env arm: socfpga: Use EMAC1 on SoCDK Masahiro Yamada (1): exynos: update maintainer of Snow and SMDK5420 board Minkyu Kang (3): Revert odroid: set MPLL clock to 880MHz Merge branch 'master' of http://git.denx.de/u-boot-samsung Merge branch 'uboot' Nikita Kiryanov (1): compulab: eeprom: add default eeprom bus Nitin Garg (3): imx: ddr: Move mx6q_4x_mt41j128.cfg to mx6sabresd board imx: Support i.MX6 High Assurance Boot authentication imx6sx: Fix i.MX6SX HAB api function table offset Nobuhiro Iwamatsu (11): arm: rmobile: lager: Fix value of CONFIG_SH_SCIF_CLK_FREQ arm: rmobile: lager: Add CONFIG_SCIF_USE_EXT_CLK arm: rmobile: koelsch: Add CONFIG_SCIF_USE_EXT_CLK arm: rmobile: koelsch: Update QoS initialization to version 0.334 arm: rmobile: alt: Update QoS initialization to version 0.11 arm: rmobile: lager: Update Qos setting to version 0.955 arm: rmobile: lager: Add Qos setting for ES2 arm: rmobile:
Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
Hi Nikolay, On Sat, Oct 11, 2014 at 2:01 AM, Nikolay Dimitrov picmas...@mail.bg wrote: We had some discussions about the PHY reset sequence and timing, but still not a common opinion, so I suggested to leave this fix for a consequent patch. Ok, understood. Just curious: which Ethernet PHY is used on the novena board? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
On 11/10/2014 21:56, Fabio Estevam wrote: Hi Nikolay, On Sat, Oct 11, 2014 at 2:01 AM, Nikolay Dimitrov picmas...@mail.bg wrote: We had some discussions about the PHY reset sequence and timing, but still not a common opinion, so I suggested to leave this fix for a consequent patch. Ok, understood. Just curious: which Ethernet PHY is used on the novena board? It's the same Micrel PHY used on the Sabrelite, the KSZ9021. Sean ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Discussion topics / issues
Dear Jeroen, In message 5437e778.3050...@myspectrum.nl you wrote: calling printf(%s\n, string) gets translated into puts by the compiler. There should be no difference in the binary. Interesting, I didn't know that. Is this somewhere documented? Is there any comprehensive list of such magic optimizations? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Research is what I'm doing when I don't know what I'm doing. -- Wernher von Braun ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Discussion topics / issues
Dear Jeroen,
In message 54384450.3000...@myspectrum.nl you wrote:
If you ask to disable it, it is good if it does so, don't see a problem
with that. Anyway, it is not an u-boot issue, anything below -O2 is not
supported anyway.
I'm not sure what you mean here. Gcc certainly does this replacement
with -Os as used for U-Boot.
I would almost take this as an insult, I hope u-boot folks know or at
least check before they assume a compiler does XYZ. And yes
compilers will replace simple printf call with their simpler equivalent
and has been doing so for quite a while (and that is an understatement).
I wonder how many people know about this - and where it is documented?
So to turn it around: just use printf: you don't lose much but you
can only win.
Sorry, but I disagree here.
First, we have a compatibility problem here. GCC assumes that puts()
will add a newline character after the string; U-Boot puts() does NOT
do this. So the GCC auto-converted printf()s will all be wrong, as
they are missing the newline. [1]
Second, using puts() insteas of printf() is also a means of
documenting your code. It shows your intention to print a constant
string. Just one example: compare
A:
void add_header(const char *s)
{
printf(MY HEADER: %s\n, s);
}
versus
B:
void add_header(const char *s)
{
puts(MY HEADER: );
puts(s);
/* Assuming U-Boot puts() - no automatic \n added */
putc('\n');
}
Which is better? A is obviously much shorter and more elegant; but
B is much more robust - A will happily crash your system when you try
to print a string like s%s%s%s%s%s%s%s%s%s%s (not to mention that
this may open a classic attack vector to break into a running system).
So yes, it does make sense to explicitly use puts().
[1] One might argue that this is a bug in U-Boot and should be fixed,
but that is another topic.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A verbal contract isn't worth the paper it's written on.
-- Samuel Goldwyn
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Discussion topics / issues
Dear Jeroen, In message 20141011150346.150c0383...@gemini.denx.de i wrote: Which is better? A is obviously much shorter and more elegant; but B is much more robust - A will happily crash your system when you try to print a string like s%s%s%s%s%s%s%s%s%s%s (not to mention that this may open a classic attack vector to break into a running system). Ignore me. This example was obviously crap. What I had in mind was something where you would use char *s; ... printf(s); Sorry... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing. - Dick Brandon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] ARM: sunxi: Move watchdog register definitions to separate file
On Sat, 2014-10-04 at 20:37 +0800, Chen-Yu Tsai wrote: On later Allwinner SoCs, the watchdog hardware is by all means a separate hardware block, with its own address range and interrupt line. Move the register definitions to a separate file to facilitate supporting newer SoCs. Signed-off-by: Chen-Yu Tsai w...@csie.org Acked-by: Ian Campbell i...@hellion.org.uk (nb: this isn't pure code motion, please mention that in the commit log in the future). ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] ARM: sunxi: Add sun6i/sun8i timer block register definition
On Sat, 2014-10-04 at 20:37 +0800, Chen-Yu Tsai wrote:
The RTC hardware has been moved out of the timer block on sun6i/sun8i.
In addition, there are more watchdogs available.
Also note that the timer block definition is not completely accurate
for sun5i/sun7i. Various blocks are missing or have been moved out.
Signed-off-by: Chen-Yu Tsai w...@csie.org
Acked-by: Ian Campbell i...@hellion.org.uk
---
arch/arm/include/asm/arch-sunxi/timer.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/include/asm/arch-sunxi/timer.h
b/arch/arm/include/asm/arch-sunxi/timer.h
index 8ed383e..03a0684 100644
--- a/arch/arm/include/asm/arch-sunxi/timer.h
+++ b/arch/arm/include/asm/arch-sunxi/timer.h
@@ -67,7 +67,9 @@ struct sunxi_timer_reg {
struct sunxi_timer timer[6];/* We have 6 timers */
u8 res2[16];
struct sunxi_avs avs;
+#if defined(CONFIG_SUN4I) || defined(CONFIG_SUN5I) || defined(CONFIG_SUN7I)
struct sunxi_wdog wdog; /* 0x90 */
+ /* XXX the following is not accurate for sun5i/sun7i */
struct sunxi_64cnt cnt64; /* 0xa0 */
u8 res4[0x58];
struct sunxi_rtc rtc;
@@ -75,6 +77,10 @@ struct sunxi_timer_reg {
struct sunxi_tgp tgp[4];
u8 res5[8];
u32 cpu_cfg;
+#else /* CONFIG_SUN6I || CONFIG_SUN8I || ... */
+ u8 res3[16];
+ struct sunxi_wdog wdog[5]; /* We have 5 watchdogs */
+#endif
};
#endif /* __ASSEMBLY__ */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] ARM: sunxi: Fix reset command on sun6i/sun8i
On Sat, 2014-10-04 at 20:37 +0800, Chen-Yu Tsai wrote:
+#else /* CONFIG_SUN6I || CONFIG_SUN8I || .. */
+ static const struct sunxi_wdog *wdog =
+ ((struct sunxi_timer_reg *)SUNXI_TIMER_BASE)-wdog;
+
+ /* Set the watchdog for its shortest interval (.5s) and wait */
+ writel(WDT_CFG_RESET, wdog-cfg);
+ writel(WDT_MODE_EN, wdog-mode);
+ writel(WDT_CTRL_KEY | WDT_CTRL_RESTART, wdog-ctl);
That's annoyingly close to the 4/5/7i version, but not quite close
enough to allow any meaningful sharing :-/
+ while (1) {
+ /* sun5i sometimes gets stuck without this */
Is this not therefore unnecessary on 6i/8i?
+ writel(WDT_MODE_EN, wdog-mode);
+ }
+#endif
}
/* do some early init */
diff --git a/arch/arm/include/asm/arch-sunxi/watchdog.h
b/arch/arm/include/asm/arch-sunxi/watchdog.h
index 5b755e3..ccc8fa3 100644
--- a/arch/arm/include/asm/arch-sunxi/watchdog.h
+++ b/arch/arm/include/asm/arch-sunxi/watchdog.h
@@ -12,6 +12,9 @@
#define WDT_CTRL_RESTART (0x1 0)
#define WDT_CTRL_KEY (0x0a57 1)
+
+#if defined(CONFIG_SUN4I) || defined(CONFIG_SUN5I) || defined(CONFIG_SUN7I)
+
#define WDT_MODE_EN (0x1 0)
#define WDT_MODE_RESET_EN(0x1 1)
@@ -21,4 +24,21 @@ struct sunxi_wdog {
u32 res[2];
};
+#else
+
+#define WDT_CFG_RESET(0x1)
+#define WDT_MODE_EN (0x1)
+
+struct sunxi_wdog {
+ u32 irq_en; /* 0x00 */
+ u32 irq_sta;/* 0x04 */
+ u32 res1[2];
+ u32 ctl;/* 0x10 */
+ u32 cfg;/* 0x14 */
+ u32 mode; /* 0x18 */
+ u32 res2;
+};
+
+#endif
+
#endif /* _SUNXI_WATCHDOG_H_ */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/5] sunxi: Add mmc card-detect functionality
On Mon, 2014-10-06 at 19:57 +0200, Hans de Goede wrote: Signed-off-by: Hans de Goede hdego...@redhat.com I presume that adding GPIO support to SPL isn't a problem size wise? --- board/sunxi/Kconfig| 26 ++ drivers/mmc/sunxi_mmc.c| 21 + include/configs/sunxi-common.h | 1 + 3 files changed, 48 insertions(+) diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index 622f7b4..497b093 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -32,4 +32,30 @@ config USB_KEYBOARD Say Y here to add support for using a USB keyboard (typically used in combination with a graphical console on HDMI). +config MMC0_CD_PIN + string Card detect pin for mmc0 + default + ---help--- + Set the card detect pin for mmc0, leave empty to not use cd. sunxi_name_to_gpio() doesn't handle the empty string directly, but I think it will do the right thing (i.e. return -1) via a more or less convoluted path. Did you check this? Assuming you have then: Acked-by: Ian Campbell i...@hellion.org.uk Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/5] sunxi: Turn MMC_SUNXI_SLOT_EXTRA into a proper Kconfig option
On Mon, 2014-10-06 at 19:57 +0200, Hans de Goede wrote: Note we also drop the SPL check for initializing the 2nd mmc slot, the SPL check is not necessary with Kconfig, because only options explicitly marked as also being for the SPL get set during SPL builds. Signed-off-by: Hans de Goede hdego...@redhat.com --- board/sunxi/Kconfig | 8 board/sunxi/board.c | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index 497b093..cb4a881 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -32,6 +32,14 @@ config USB_KEYBOARD Say Y here to add support for using a USB keyboard (typically used in combination with a graphical console on HDMI). +config MMC_SUNXI_SLOT_EXTRA + int mmc extra slot number + default -1 + ---help--- + sunxi builds always enable mmc0, some boards also have a sdcard slot + or emmc on mmc2 or mmc3. Setting this to 2 or 3 will enable support + for this. What happened to mmc1? Regardless: Acked-by: Ian Campbell i...@hellion.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/5] sunxi: When we've both mmc0 and mmc2, detect from which one we're booting
On Mon, 2014-10-06 at 19:57 +0200, Hans de Goede wrote:
@@ -108,11 +109,31 @@ static void mmc_pinmux_setup(int sdc)
int board_mmc_init(bd_t *bis)
{
+ __maybe_unused struct mmc *mmc0, *mmc1;
+ __maybe_unused char buf[512];
+
mmc_pinmux_setup(CONFIG_MMC_SUNXI_SLOT);
- sunxi_mmc_init(CONFIG_MMC_SUNXI_SLOT);
+ mmc0 = sunxi_mmc_init(CONFIG_MMC_SUNXI_SLOT);
#if CONFIG_MMC_SUNXI_SLOT_EXTRA != -1
mmc_pinmux_setup(CONFIG_MMC_SUNXI_SLOT_EXTRA);
- sunxi_mmc_init(CONFIG_MMC_SUNXI_SLOT_EXTRA);
+ mmc1 = sunxi_mmc_init(CONFIG_MMC_SUNXI_SLOT_EXTRA);
+#endif
+
+#if CONFIG_MMC_SUNXI_SLOT == 0 CONFIG_MMC_SUNXI_SLOT_EXTRA == 2
+ /*
+ * Both mmc0 and mmc2 are bootable, figure out where we're booting
+ * from. Try mmc0 first, just like the brom does.
+ */
+ if (mmc_getcd(mmc0) mmc_init(mmc0) == 0
If sunxi_mmx_init failed then mmc0 might be NULL here.
+ mmc0-block_dev.block_read(0, 16, 1, buf) == 1) {
+ buf[12] = 0;
+ if (strcmp(buf[4], eGON.BT0) == 0)
+ return 0;
+ }
+
+ /* no bootable card in mmc0, so we must be booting from mmc2, swap */
+ mmc0-block_dev.dev = 1;
+ mmc1-block_dev.dev = 0;
and mmc1 could be NULL here.
Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/5] sunxi: Use PG3 - PG8 as io-pins for mmc1
On Mon, 2014-10-06 at 19:57 +0200, Hans de Goede wrote:
None of the known sunxi devices actually use mmc1 routed through PH, where
as some devices do actually use mmc1 routed through PG, so change the routing
of mmc1 to PG. If in the future we encounter devices with mmc1 routed through
PH, we will need to change things to be a bit more flexible.
Signed-off-by: Hans de Goede hdego...@redhat.com
Acked-by: Ian Campbell i...@hellion.org.uk
(right address this time ;-))
---
arch/arm/include/asm/arch-sunxi/gpio.h | 2 ++
board/sunxi/board.c| 6 +++---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
b/arch/arm/include/asm/arch-sunxi/gpio.h
index f7f3d8c..3f46f78 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -117,6 +117,8 @@ enum sunxi_gpio_number {
#define SUN5I_GPB19_UART0_TX 2
#define SUN5I_GPB20_UART0_RX 2
+#define SUN5I_GPG3_SDC1 2
+
#define SUN5I_GPG3_UART1_TX 4
#define SUN5I_GPG4_UART1_RX 4
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 0a7be31..23f8887 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -75,9 +75,9 @@ static void mmc_pinmux_setup(int sdc)
break;
case 1:
- /* CMD-PH22, CLK-PH23, D0~D3-PH24~27 : 5 */
- for (pin = SUNXI_GPH(22); pin = SUNXI_GPH(27); pin++) {
- sunxi_gpio_set_cfgpin(pin, SUN4I_GPH22_SDC1);
+ /* CMD-PG3, CLK-PG4, D0~D3-PG5-8 */
+ for (pin = SUNXI_GPG(3); pin = SUNXI_GPG(8); pin++) {
+ sunxi_gpio_set_cfgpin(pin, SUN5I_GPG3_SDC1);
sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
sunxi_gpio_set_drv(pin, 2);
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] sunxi: Enable second sdcard slot found on some boards
On Mon, 2014-10-06 at 19:57 +0200, Hans de Goede wrote: Enable the second sdcard slot found on some boards. Note that we do not set CONFIG_MMC_SUNXI_SLOT_EXTRA for the SPL, as having it there is not useful, Except for on the Mele-M3 where the second sdcard is an eMMC, from which the device can also boot, and there we want to have both in the SPL, so that a single u-boot binary can both from both. So for the M3 we do prefix the defconfig setting with the special +S: syntax so that it applies to the SPL too. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9] ARM: sunxi: Fix build break when CONFIG_MMC is not defined
On Tue, 2014-10-07 at 15:11 +0800, Chen-Yu Tsai wrote: BOOT_TARGET_DEVICES includes MMC unconditionally. This breaks when CONFIG_CMD_MMC is not defined. Use a secondary macro to conditionally include it when CONFIG_MMC is enabled, as we do for CONFIG_AHCI. This is used when we want to use uart0 from port F, which conflicts with mmc0. Signed-off-by: Chen-Yu Tsai w...@csie.org Acked-by: Ian Campbell i...@hellion.org.uk Hans, this made me think back to your Enable second sdcard slot found on some boards series -- do you not want to add mmc1 as a boot target device when MMC_SUNXI_SLOT_EXTRA is enabled? --- include/configs/sunxi-common.h | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index a31656e..7571e0e 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -227,6 +227,12 @@ pxefile_addr_r=0x4320\0 \ ramdisk_addr_r=0x4330\0 +#ifdef CONFIG_MMC +#define BOOT_TARGET_DEVICES_MMC(func) func(MMC, mmc, 0) +#else +#define BOOT_TARGET_DEVICES_MMC(func) +#endif + #ifdef CONFIG_AHCI #define BOOT_TARGET_DEVICES_SCSI(func) func(SCSI, scsi, 0) #else @@ -240,7 +246,7 @@ #endif #define BOOT_TARGET_DEVICES(func) \ - func(MMC, mmc, 0) \ + BOOT_TARGET_DEVICES_MMC(func) \ BOOT_TARGET_DEVICES_SCSI(func) \ BOOT_TARGET_DEVICES_USB(func) \ func(PXE, pxe, na) \ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9] ARM: sunxi: Add sun8i (A23) UART0 pin mux support
On Tue, 2014-10-07 at 15:11 +0800, Chen-Yu Tsai wrote:
UART0 pin muxes on the A23 have a different function value.
Signed-off-by: Chen-Yu Tsai w...@csie.org
Sigh, why can't silicon folks resist fiddling with stuff ;-)
Acked-by: Ian Campbell i...@hellion.org.uk
---
arch/arm/include/asm/arch-sunxi/gpio.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
b/arch/arm/include/asm/arch-sunxi/gpio.h
index ba7e69b..b94ec4d 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -125,8 +125,14 @@ enum sunxi_gpio_number {
#define SUNXI_GPF0_SDC0 2
#define SUNXI_GPF2_SDC0 2
+
+#ifdef CONFIG_SUN8I
+#define SUNXI_GPF2_UART0_TX 3
+#define SUNXI_GPF4_UART0_RX 3
+#else
#define SUNXI_GPF2_UART0_TX 4
#define SUNXI_GPF4_UART0_RX 4
+#endif
#define SUN4I_GPG0_SDC1 4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] ARM: sunxi: Add support for uart0 on port F (mmc0)
On Tue, 2014-10-07 at 15:11 +0800, Chen-Yu Tsai wrote:
Allwinner SoCs provide uart0 muxed with mmc0, which can then be used
with a micro SD breakout board. On the A23, this is the only way to
use uart0.
Signed-off-by: Chen-Yu Tsai w...@csie.org
Acked-by: Ian Campbell i...@hellion.org.uk
---
arch/arm/cpu/armv7/sunxi/board.c | 11 ++-
include/configs/sunxi-common.h | 2 ++
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/sunxi/board.c
b/arch/arm/cpu/armv7/sunxi/board.c
index b6d63db..29d45b6 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -50,7 +50,16 @@ u32 spl_boot_mode(void)
int gpio_init(void)
{
-#if CONFIG_CONS_INDEX == 1 (defined(CONFIG_SUN4I) ||
defined(CONFIG_SUN7I))
+#if CONFIG_CONS_INDEX == 1 defined(CONFIG_UART0_PORT_F)
+#if defined(CONFIG_SUN4I) || defined(CONFIG_SUN7I)
+ /* disable GPB22,23 as uart0 tx,rx to avoid conflict */
+ sunxi_gpio_set_cfgpin(SUNXI_GPB(22), SUNXI_GPIO_INPUT);
+ sunxi_gpio_set_cfgpin(SUNXI_GPB(23), SUNXI_GPIO_INPUT);
+#endif
+ sunxi_gpio_set_cfgpin(SUNXI_GPF(2), SUNXI_GPF2_UART0_TX);
+ sunxi_gpio_set_cfgpin(SUNXI_GPF(4), SUNXI_GPF4_UART0_RX);
+ sunxi_gpio_set_pull(SUNXI_GPF(4), 1);
+#elif CONFIG_CONS_INDEX == 1 (defined(CONFIG_SUN4I) ||
defined(CONFIG_SUN7I))
sunxi_gpio_set_cfgpin(SUNXI_GPB(22), SUN4I_GPB22_UART0_TX);
sunxi_gpio_set_cfgpin(SUNXI_GPB(23), SUN4I_GPB23_UART0_RX);
sunxi_gpio_set_pull(SUNXI_GPB(23), SUNXI_GPIO_PULL_UP);
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 7571e0e..7857a56 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -77,6 +77,7 @@
#define CONFIG_INITRD_TAG
/* mmc config */
+#if !defined(CONFIG_UART0_PORT_F)
#define CONFIG_MMC
#define CONFIG_GENERIC_MMC
#define CONFIG_CMD_MMC
@@ -84,6 +85,7 @@
#define CONFIG_MMC_SUNXI_SLOT0
#define CONFIG_ENV_IS_IN_MMC
#define CONFIG_SYS_MMC_ENV_DEV 0 /* first detected MMC
controller */
+#endif
/* 4MB of malloc() pool */
#define CONFIG_SYS_MALLOC_LEN(CONFIG_ENV_SIZE + (4 20))
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/9] mmc: sunxi: Add support for sun8i (A23)
On Tue, 2014-10-07 at 15:11 +0800, Chen-Yu Tsai wrote:
The Allwinner A23 SoC has reset controls like the A31 (sun6i).
The FIFO address is also the same as sun6i.
Re-use code added for sun6i.
Signed-off-by: Chen-Yu Tsai w...@csie.org
Acked-by: Ian Campbell i...@hellion.org.uk
---
arch/arm/include/asm/arch-sunxi/mmc.h | 2 +-
drivers/mmc/sunxi_mmc.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/mmc.h
b/arch/arm/include/asm/arch-sunxi/mmc.h
index 6a31184..5836ae9 100644
--- a/arch/arm/include/asm/arch-sunxi/mmc.h
+++ b/arch/arm/include/asm/arch-sunxi/mmc.h
@@ -43,7 +43,7 @@ struct sunxi_mmc {
u32 chda; /* 0x90 */
u32 cbda; /* 0x94 */
u32 res1[26];
-#if defined(CONFIG_SUN6I)
+#if defined(CONFIG_SUN6I) || defined(CONFIG_SUN8I)
u32 res2[64];
#endif
u32 fifo; /* 0x100 (0x200 on sun6i) FIFO access address */
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 8f4b50b..23a2ec0 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -73,7 +73,7 @@ static int mmc_clk_io_on(int sdc_no)
/* config ahb clock */
setbits_le32(ccm-ahb_gate0, 1 AHB_GATE_OFFSET_MMC(sdc_no));
-#if defined(CONFIG_SUN6I)
+#if defined(CONFIG_SUN6I) || defined(CONFIG_SUN8I)
/* unassert reset */
setbits_le32(ccm-ahb_reset0_cfg, 1 AHB_RESET_OFFSET_MMC(sdc_no));
#endif
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/9] ARM: sunxi: Add basic A23 support
On Tue, 2014-10-07 at 15:11 +0800, Chen-Yu Tsai wrote:
The basic blocks of the A23 are similar to the A31 (sun6i). Re-use
sun6i code for initial clock, gpio, and uart setup.
Do I take it that sun8i is also in the same position wrt DRAM bring up
code not existing yet and there therefore being no SPL yet?
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
arch/arm/Kconfig| 3 +++
arch/arm/cpu/armv7/sunxi/Makefile | 2 ++
arch/arm/cpu/armv7/sunxi/board.c| 3 ++-
arch/arm/cpu/armv7/sunxi/cpu_info.c | 2 ++
arch/arm/include/asm/arch-sunxi/clock.h | 2 +-
board/sunxi/Kconfig | 9 -
include/configs/sun8i.h | 23 +++
7 files changed, 41 insertions(+), 3 deletions(-)
create mode 100644 include/configs/sun8i.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e3e7e78..cb691b2 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -450,6 +450,9 @@ config TARGET_SUN6I
config TARGET_SUN7I
bool Support sun7i
+config TARGET_SUN8I
+ bool Support sun8i
+
config TARGET_SNOWBALL
bool Support snowball
diff --git a/arch/arm/cpu/armv7/sunxi/Makefile
b/arch/arm/cpu/armv7/sunxi/Makefile
index 2a42dca..24f1dae 100644
--- a/arch/arm/cpu/armv7/sunxi/Makefile
+++ b/arch/arm/cpu/armv7/sunxi/Makefile
@@ -12,10 +12,12 @@ obj-y += board.o
obj-y+= clock.o
obj-y+= pinmux.o
obj-$(CONFIG_SUN6I) += prcm.o
+obj-$(CONFIG_SUN8I) += prcm.o
obj-$(CONFIG_SUN4I) += clock_sun4i.o
obj-$(CONFIG_SUN5I) += clock_sun4i.o
obj-$(CONFIG_SUN6I) += clock_sun6i.o
obj-$(CONFIG_SUN7I) += clock_sun4i.o
+obj-$(CONFIG_SUN8I) += clock_sun6i.o
ifndef CONFIG_SPL_BUILD
obj-y+= cpu_info.o
diff --git a/arch/arm/cpu/armv7/sunxi/board.c
b/arch/arm/cpu/armv7/sunxi/board.c
index 29d45b6..61c1ba9 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -100,7 +100,8 @@ void reset_cpu(ulong addr)
/* do some early init */
void s_init(void)
{
-#if !defined CONFIG_SPL_BUILD (defined CONFIG_SUN7I || defined
CONFIG_SUN6I)
+#if !defined CONFIG_SPL_BUILD (defined CONFIG_SUN7I || \
+ defined CONFIG_SUN6I || defined CONFIG_SUN8I)
At some point we should refactor this to use a common Kconfig thing
(SUNXI_SMP etc) which the relevant targets select.
/* Enable SMP mode for CPU0, by setting bit 6 of Auxiliary Ctl reg */
asm volatile(
mrc p15, 0, r0, c1, c0, 1\n
diff --git a/arch/arm/cpu/armv7/sunxi/cpu_info.c
b/arch/arm/cpu/armv7/sunxi/cpu_info.c
index 40c4e13..4f2a09c 100644
--- a/arch/arm/cpu/armv7/sunxi/cpu_info.c
+++ b/arch/arm/cpu/armv7/sunxi/cpu_info.c
@@ -27,6 +27,8 @@ int print_cpuinfo(void)
puts(CPU: Allwinner A31 (SUN6I)\n);
#elif defined CONFIG_SUN7I
puts(CPU: Allwinner A20 (SUN7I)\n);
+#elif defined CONFIG_SUN8I
+ puts(CPU: Allwinner A23 (SUN8I)\n);
#else
#warning Please update cpu_info.c with correct CPU information
puts(CPU: SUNXI Family\n);
diff --git a/arch/arm/include/asm/arch-sunxi/clock.h
b/arch/arm/include/asm/arch-sunxi/clock.h
index 8f5d860..012c2af 100644
--- a/arch/arm/include/asm/arch-sunxi/clock.h
+++ b/arch/arm/include/asm/arch-sunxi/clock.h
@@ -15,7 +15,7 @@
#define CLK_GATE_CLOSE 0x0
/* clock control module regs definition */
-#ifdef CONFIG_SUN6I
+#if defined(CONFIG_SUN6I) || defined(CONFIG_SUN8I)
#include asm/arch/clock_sun6i.h
#else
#include asm/arch/clock_sun4i.h
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 05defac..16f6db4 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -27,7 +27,14 @@ config SYS_CONFIG_NAME
endif
-if TARGET_SUN4I || TARGET_SUN5I || TARGET_SUN6I || TARGET_SUN7I
+if TARGET_SUN8I
+
+config SYS_CONFIG_NAME
+ default sun8i
+
+endif
+
+if TARGET_SUN4I || TARGET_SUN5I || TARGET_SUN6I || TARGET_SUN7I ||
TARGET_SUN8I
config SYS_CPU
default armv7
diff --git a/include/configs/sun8i.h b/include/configs/sun8i.h
new file mode 100644
index 000..1c1a7cd
--- /dev/null
+++ b/include/configs/sun8i.h
@@ -0,0 +1,23 @@
+/*
+ * (C) Copyright 2014 Chen-Yu Tsai w...@csie.org
+ *
+ * Configuration settings for the Allwinner A23 (sun8i) CPU
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+/*
+ * A23 specific configuration
+ */
+#define CONFIG_SUN8I /* sun8i SoC generation */
+#define CONFIG_SYS_PROMPTsun8i#
+
+/*
+ * Include common sunxi configuration where most the settings are
+ */
+#include configs/sunxi-common.h
+
+#endif /* __CONFIG_H */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/9] ARM: sunxi: Add support for R_PIO gpio banks
On Tue, 2014-10-07 at 15:11 +0800, Chen-Yu Tsai wrote:
From: Hans de Goede hdego...@redhat.com
The A31, A23 and later SoCs have an extra pin controller, called CPUs_PIO
or R_PIO, which handles pin banks L and beyond.
Does it also have enough space for 9 banks? Since you overlay a struct
sunxi_gpio_reg on it which has a gpio_bank[SUNXI_GPIO_BANKS] over it.
SUNXI_GPIO_BANKS is now also confusingly named since it is really
number of banks on the first/original GPIO controller. Eventually
someone will use it as the actual total and be very sad.
I think it might be best if we retcon some distinct name onto the
original GPIO controller so we can have SUNXIO_GPIO_BLA_BANKS and
SUNXI_GPIO_R_BANKS (or even just call them controller 0 and 1 and have
SUNXI_GPIO0_BANKS and SUNXI_GPIO1_BANKS, if that's not too confusing)
If we still need SUNXI_GPIO_BANKS after that then it would be the sum of
those two.
Signed-off-by: Hans de Goede hdego...@redhat.com
[w...@csie.org: expanded commit message]
[w...@csie.org: add pin bank M and expand comments]
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
arch/arm/include/asm/arch-sunxi/gpio.h | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
b/arch/arm/include/asm/arch-sunxi/gpio.h
index b94ec4d..bbe815a 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -10,6 +10,7 @@
#define _SUNXI_GPIO_H
#include linux/types.h
+#include asm/arch/cpu.h
/*
* sunxi has 9 banks of gpio, they are:
@@ -29,6 +30,19 @@
#define SUNXI_GPIO_I 8
#define SUNXI_GPIO_BANKS 9
+/*
+ * sun6i/sun8i and later SoCs have an additional GPIO controller (R_PIO)
+ * at a different register offset.
+ *
+ * sun6i has 2 banks:
+ * PL0 - PL8 | PM0 - PM7
+ *
+ * sun8i has 1 bank:
+ * PL0 - PL11
+ */
+#define SUNXI_GPIO_L 9
+#define SUNXI_GPIO_M 10
+
struct sunxi_gpio {
u32 cfg[4];
u32 dat;
@@ -50,8 +64,9 @@ struct sunxi_gpio_reg {
struct sunxi_gpio_int gpio_int;
};
-#define BANK_TO_GPIO(bank) \
- ((struct sunxi_gpio_reg *)SUNXI_PIO_BASE)-gpio_bank[bank]
+#define BANK_TO_GPIO(bank) (((bank) SUNXI_GPIO_BANKS) ? \
+ ((struct sunxi_gpio_reg *)SUNXI_PIO_BASE)-gpio_bank[bank] : \
+ ((struct sunxi_gpio_reg *)SUNXI_R_PIO_BASE)-gpio_bank[(bank) -
SUNXI_GPIO_BANKS])
#define GPIO_BANK(pin) ((pin) 5)
#define GPIO_NUM(pin)((pin) 0x1f)
@@ -75,6 +90,8 @@ struct sunxi_gpio_reg {
#define SUNXI_GPIO_G_NR 32
#define SUNXI_GPIO_H_NR 32
#define SUNXI_GPIO_I_NR 32
+#define SUNXI_GPIO_L_NR 32
+#define SUNXI_GPIO_M_NR 32
#define SUNXI_GPIO_NEXT(__gpio) \
((__gpio##_START) + (__gpio##_NR) + 0)
@@ -89,6 +106,8 @@ enum sunxi_gpio_number {
SUNXI_GPIO_G_START = SUNXI_GPIO_NEXT(SUNXI_GPIO_F),
SUNXI_GPIO_H_START = SUNXI_GPIO_NEXT(SUNXI_GPIO_G),
SUNXI_GPIO_I_START = SUNXI_GPIO_NEXT(SUNXI_GPIO_H),
+ SUNXI_GPIO_L_START = SUNXI_GPIO_NEXT(SUNXI_GPIO_I),
+ SUNXI_GPIO_M_START = SUNXI_GPIO_NEXT(SUNXI_GPIO_L),
};
/* SUNXI GPIO number definitions */
@@ -101,6 +120,8 @@ enum sunxi_gpio_number {
#define SUNXI_GPG(_nr) (SUNXI_GPIO_G_START + (_nr))
#define SUNXI_GPH(_nr) (SUNXI_GPIO_H_START + (_nr))
#define SUNXI_GPI(_nr) (SUNXI_GPIO_I_START + (_nr))
+#define SUNXI_GPL(_nr) (SUNXI_GPIO_L_START + (_nr))
+#define SUNXI_GPM(_nr) (SUNXI_GPIO_M_START + (_nr))
/* GPIO pin function config */
#define SUNXI_GPIO_INPUT 0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/9] ARM: sunxi: Allow specifying module in prcm apb0 init function
On Tue, 2014-10-07 at 15:11 +0800, Chen-Yu Tsai wrote:
The prcm apb0 controls multiple modules. Allow specifying which
modules to enable clocks and de-assert resets so the function
can be reused.
How come this isn't actually called on sun6i?
(naughty of me not to notice this when it was submitted!)
Is it going to be called by anything in this series? I have a feeling
this is a precursor for SPL which should have been left out of the sun6i
series, but oh well what's done is done.
Without a caller it's hard to make a judgement call on parameters vs
#ifdef in the function, although my inclination would generally be
towards parameters, if there's just going to be an ifdef at the call
site instead it's not really buying us much.
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
arch/arm/cpu/armv7/sunxi/prcm.c| 12 +++-
arch/arm/include/asm/arch-sunxi/prcm.h | 2 +-
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/prcm.c b/arch/arm/cpu/armv7/sunxi/prcm.c
index 7b3ee89..19b4938 100644
--- a/arch/arm/cpu/armv7/sunxi/prcm.c
+++ b/arch/arm/cpu/armv7/sunxi/prcm.c
@@ -21,13 +21,15 @@
#include asm/arch/prcm.h
#include asm/arch/sys_proto.h
-void prcm_init_apb0(void)
+/* APB0 clock gate and reset bit offsets are the same. */
Is this absolutely guaranteed?
+void prcm_apb0_enable(u32 flags)
{
struct sunxi_prcm_reg *prcm =
(struct sunxi_prcm_reg *)SUNXI_PRCM_BASE;
- setbits_le32(prcm-apb0_gate, PRCM_APB0_GATE_P2WI |
-PRCM_APB0_GATE_PIO);
- setbits_le32(prcm-apb0_reset, PRCM_APB0_RESET_P2WI |
- PRCM_APB0_RESET_PIO);
+ /* open the clock for module */
+ setbits_le32(prcm-apb0_gate, flags);
+
+ /* deassert reset for module */
+ setbits_le32(prcm-apb0_reset, flags);
}
diff --git a/arch/arm/include/asm/arch-sunxi/prcm.h
b/arch/arm/include/asm/arch-sunxi/prcm.h
index 1b40f09..3d3bfa6 100644
--- a/arch/arm/include/asm/arch-sunxi/prcm.h
+++ b/arch/arm/include/asm/arch-sunxi/prcm.h
@@ -233,6 +233,6 @@ struct sunxi_prcm_reg {
u32 dram_tst; /* 0x190 */
};
-void prcm_init_apb0(void);
+void prcm_apb0_enable(u32 flags);
#endif /* __ASSEMBLY__ */
#endif /* _PRCM_H */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/9] ARM: sunxi: Allow specifying module in prcm apb0 init function
On Sat, 2014-10-11 at 17:11 +0100, Ian Campbell wrote:
On Tue, 2014-10-07 at 15:11 +0800, Chen-Yu Tsai wrote:
The prcm apb0 controls multiple modules. Allow specifying which
modules to enable clocks and de-assert resets so the function
can be reused.
How come this isn't actually called on sun6i?
(naughty of me not to notice this when it was submitted!)
Is it going to be called by anything in this series? I have a feeling
this is a precursor for SPL which should have been left out of the sun6i
series, but oh well what's done is done.
Without a caller it's hard to make a judgement call on parameters vs
#ifdef in the function, although my inclination would generally be
towards parameters, if there's just going to be an ifdef at the call
site instead it's not really buying us much.
I should have read the next patch more carefully before commenting...
Signed-off-by: Chen-Yu Tsai w...@csie.org
Acked-by: Ian Campbell i...@hellion.org.uk
---
arch/arm/cpu/armv7/sunxi/prcm.c| 12 +++-
arch/arm/include/asm/arch-sunxi/prcm.h | 2 +-
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/prcm.c
b/arch/arm/cpu/armv7/sunxi/prcm.c
index 7b3ee89..19b4938 100644
--- a/arch/arm/cpu/armv7/sunxi/prcm.c
+++ b/arch/arm/cpu/armv7/sunxi/prcm.c
@@ -21,13 +21,15 @@
#include asm/arch/prcm.h
#include asm/arch/sys_proto.h
-void prcm_init_apb0(void)
+/* APB0 clock gate and reset bit offsets are the same. */
Is this absolutely guaranteed?
+void prcm_apb0_enable(u32 flags)
{
struct sunxi_prcm_reg *prcm =
(struct sunxi_prcm_reg *)SUNXI_PRCM_BASE;
- setbits_le32(prcm-apb0_gate, PRCM_APB0_GATE_P2WI |
- PRCM_APB0_GATE_PIO);
- setbits_le32(prcm-apb0_reset, PRCM_APB0_RESET_P2WI |
- PRCM_APB0_RESET_PIO);
+ /* open the clock for module */
+ setbits_le32(prcm-apb0_gate, flags);
+
+ /* deassert reset for module */
+ setbits_le32(prcm-apb0_reset, flags);
}
diff --git a/arch/arm/include/asm/arch-sunxi/prcm.h
b/arch/arm/include/asm/arch-sunxi/prcm.h
index 1b40f09..3d3bfa6 100644
--- a/arch/arm/include/asm/arch-sunxi/prcm.h
+++ b/arch/arm/include/asm/arch-sunxi/prcm.h
@@ -233,6 +233,6 @@ struct sunxi_prcm_reg {
u32 dram_tst; /* 0x190 */
};
-void prcm_init_apb0(void);
+void prcm_apb0_enable(u32 flags);
#endif /* __ASSEMBLY__ */
#endif /* _PRCM_H */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9] ARM: sunxi: Add support for using R_UART as console
On Tue, 2014-10-07 at 15:11 +0800, Chen-Yu Tsai wrote:
The A23 only has UART0 muxed with MMC0. Some of the boards we
encountered expose R_UART as a set of pads.
Add support for R_UART so we can have a console while using mmc.
I suppose R_UART is the h/w doc name. UARTR would fit the code better
but I suppose sticking with the h/w names is fine.
CONFIG_CONS_INDEX is also getting a bit out of hand, eventually we
should make it a Kconfig choice option.
Signed-off-by: Chen-Yu Tsai w...@csie.org
Acked-by: Ian Campbell i...@hellion.org.uk
---
arch/arm/cpu/armv7/sunxi/board.c | 4
arch/arm/cpu/armv7/sunxi/clock_sun6i.c | 6 ++
arch/arm/include/asm/arch-sunxi/cpu.h | 1 +
arch/arm/include/asm/arch-sunxi/gpio.h | 3 +++
include/configs/sunxi-common.h | 1 +
5 files changed, 15 insertions(+)
diff --git a/arch/arm/cpu/armv7/sunxi/board.c
b/arch/arm/cpu/armv7/sunxi/board.c
index 61c1ba9..aeb2c2f 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -75,6 +75,10 @@ int gpio_init(void)
sunxi_gpio_set_cfgpin(SUNXI_GPG(3), SUN5I_GPG3_UART1_TX);
sunxi_gpio_set_cfgpin(SUNXI_GPG(4), SUN5I_GPG4_UART1_RX);
sunxi_gpio_set_pull(SUNXI_GPG(4), SUNXI_GPIO_PULL_UP);
+#elif CONFIG_CONS_INDEX == 5 defined(CONFIG_SUN8I)
+ sunxi_gpio_set_cfgpin(SUNXI_GPL(2), SUN8I_GPL2_R_UART_TX);
+ sunxi_gpio_set_cfgpin(SUNXI_GPL(3), SUN8I_GPL3_R_UART_RX);
+ sunxi_gpio_set_pull(SUNXI_GPL(3), SUNXI_GPIO_PULL_UP);
#else
#error Unsupported console port number. Please fix pin mux settings in
board.c
#endif
diff --git a/arch/arm/cpu/armv7/sunxi/clock_sun6i.c
b/arch/arm/cpu/armv7/sunxi/clock_sun6i.c
index 8387b93..1eae976 100644
--- a/arch/arm/cpu/armv7/sunxi/clock_sun6i.c
+++ b/arch/arm/cpu/armv7/sunxi/clock_sun6i.c
@@ -13,6 +13,7 @@
#include common.h
#include asm/io.h
#include asm/arch/clock.h
+#include asm/arch/prcm.h
#include asm/arch/sys_proto.h
void clock_init_uart(void)
@@ -20,6 +21,7 @@ void clock_init_uart(void)
struct sunxi_ccm_reg *const ccm =
(struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+#if CONFIG_CONS_INDEX 5
/* uart clock source is apb2 */
writel(APB2_CLK_SRC_OSC24M|
APB2_CLK_RATE_N_1|
@@ -35,6 +37,10 @@ void clock_init_uart(void)
setbits_le32(ccm-apb2_reset_cfg,
1 (APB2_RESET_UART_SHIFT +
CONFIG_CONS_INDEX - 1));
+#else
+ /* enable R_PIO and R_UART clocks, and de-assert resets */
+ prcm_apb0_enable(PRCM_APB0_GATE_PIO | PRCM_APB0_GATE_UART);
+#endif
/* Dup with clock_init_safe(), drop once sun6i SPL support lands */
writel(PLL6_CFG_DEFAULT, ccm-pll6_cfg);
diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h
b/arch/arm/include/asm/arch-sunxi/cpu.h
index 313e6c8..0de79a0 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu.h
@@ -111,6 +111,7 @@
#define SUNXI_AVG_BASE 0x01ea
#define SUNXI_PRCM_BASE 0x01f01400
+#define SUNXI_R_UART_BASE0x01f02800
#define SUNXI_R_PIO_BASE 0x01f02c00
#define SUNXI_P2WI_BASE 0x01f03400
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
b/arch/arm/include/asm/arch-sunxi/gpio.h
index bbe815a..c216960 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -164,6 +164,9 @@ enum sunxi_gpio_number {
#define SUN4I_GPI4_SDC3 2
+#define SUN8I_GPL2_R_UART_TX 2
+#define SUN8I_GPL3_R_UART_RX 2
+
/* GPIO pin pull-up/down config */
#define SUNXI_GPIO_PULL_DISABLE 0
#define SUNXI_GPIO_PULL_UP 1
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 7857a56..7e54296 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -42,6 +42,7 @@
#define CONFIG_SYS_NS16550_COM2 SUNXI_UART1_BASE
#define CONFIG_SYS_NS16550_COM3 SUNXI_UART2_BASE
#define CONFIG_SYS_NS16550_COM4 SUNXI_UART3_BASE
+#define CONFIG_SYS_NS16550_COM5 SUNXI_R_UART_BASE
/* DRAM Base */
#define CONFIG_SYS_SDRAM_BASE0x4000
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 9/9] ARM: sunxi: Add Ippo-q8h-v5 A23 tablet board defconfig
On Tue, 2014-10-07 at 15:11 +0800, Chen-Yu Tsai wrote: Ippo q8h is a series of A23 tablet boards. This defconfig is for v5 of these boards, though for u-boot purposes they are mostly the same. Any differences worth mentioning? See: http://linux-sunxi.org/Ippo_q8h BTW, this says The port is then used by the OpenRISC core to dump debug messages. Whether this port can be used by the primary system is still unknown. but your previous patches suggest this is now known? Signed-off-by: Chen-Yu Tsai w...@csie.org Acked-by: Ian Campbell i...@hellion.org.uk --- board/sunxi/MAINTAINERS| 5 + configs/Ippo_q8h_defconfig | 4 2 files changed, 9 insertions(+) create mode 100644 configs/Ippo_q8h_defconfig diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS index 7afe45e..febd126 100644 --- a/board/sunxi/MAINTAINERS +++ b/board/sunxi/MAINTAINERS @@ -50,3 +50,8 @@ COLOMBUS BOARD M: Maxime Ripard maxime.rip...@free-electrons.com S: Maintained F: configs/Colombus_defconfig + +IPPO-Q8H-V5 BOARD +M: CHen-Yu Tsai w...@csie.org +S: Maintained +F: configs/Ippo_q8h_v5_defconfig diff --git a/configs/Ippo_q8h_defconfig b/configs/Ippo_q8h_defconfig new file mode 100644 index 000..781f137 --- /dev/null +++ b/configs/Ippo_q8h_defconfig @@ -0,0 +1,4 @@ +CONFIG_SYS_EXTRA_OPTIONS=IPPO_Q8H_V5,CONS_INDEX=5 +CONFIG_ARM=y +CONFIG_TARGET_SUN8I=y +CONFIG_DEFAULT_DEVICE_TREE=sun8i-a23-ippo-q8h-v5.dtb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] ARMv8: PSCI: Add linker section to hold PSCI code
On 2014-10-11 12:27, Albert ARIBAUD wrote:
Hi Albert,
On Fri, 19 Sep 2014 18:04:14 +0200, Albert ARIBAUD
albert.u.b...@aribaud.net wrote:
Hi Marc,
On Thu, 18 Sep 2014 16:28:52 +0100, Marc Zyngier
marc.zyng...@arm.com
wrote:
On Thu, Sep 18 2014 at 10:12:17 AM, Albert ARIBAUD
albert.u.b...@aribaud.net wrote:
Hi Arnab,
On Thu, 28 Aug 2014 01:59:57 +0530, Arnab Basu
arnab.b...@freescale.com wrote:
A separate linker section makes it possible to keep this code
either
in DDR or in some secure memory location provided specifically
for the
purpose.
So far no one is using this section.
Signed-off-by: Arnab Basu arnab.b...@freescale.com
Reviewed-by: Bhupesh Sharma bhupesh.sha...@freescale.com
Cc: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/config.mk|2 +-
arch/arm/cpu/armv8/u-boot.lds | 30
++
2 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index c339e6d..9272e9c 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -111,7 +111,7 @@ endif
# limit ourselves to the sections we want in the .bin.
ifdef CONFIG_ARM64
-OBJCOPYFLAGS += -j .text -j .rodata -j .data -j .u_boot_list
-j .rela.dyn
+OBJCOPYFLAGS += -j .text -j .secure_text -j .rodata -j .data
-j .u_boot_list -j .rela.dyn
else
OBJCOPYFLAGS += -j .text -j .secure_text -j .rodata -j .hash
-j .data -j .got.plt -j .u_boot_list -j .rel.dyn
endif
diff --git a/arch/arm/cpu/armv8/u-boot.lds
b/arch/arm/cpu/armv8/u-boot.lds
index 4c1..bd95fff 100644
--- a/arch/arm/cpu/armv8/u-boot.lds
+++ b/arch/arm/cpu/armv8/u-boot.lds
@@ -8,6 +8,8 @@
* SPDX-License-Identifier: GPL-2.0+
*/
+#include config.h
+
OUTPUT_FORMAT(elf64-littleaarch64, elf64-littleaarch64,
elf64-littleaarch64)
OUTPUT_ARCH(aarch64)
ENTRY(_start)
@@ -23,6 +25,34 @@ SECTIONS
*(.text*)
}
+#ifdef CONFIG_ARMV8_PSCI
+
+#ifndef CONFIG_ARMV8_SECURE_BASE
+#define CONFIG_ARMV8_SECURE_BASE
+#endif
+
+ .__secure_start : {
+ . = ALIGN(0x1000);
+ *(.__secure_start)
+ }
+
+ .secure_text CONFIG_ARMV8_SECURE_BASE :
+ AT(ADDR(.__secure_start) + SIZEOF(.__secure_start))
+ {
+ *(._secure.text)
+ }
+
+ . = LOADADDR(.__secure_start) +
+ SIZEOF(.__secure_start) +
+ SIZEOF(.secure_text);
+
+ __secure_end_lma = .;
+ .__secure_end : AT(__secure_end_lma) {
+ *(.__secure_end)
+ LONG(0x1d1071c);/* Must output something to reset LMA */
Can you explain in more detail what issue this fixes?
If you use AT to force a new load address (LMA), you must ensure
that
you actually output something at this address. Here, if
*(.__secure_end)
ends up being empty, whatever follows would be as if the AT never
happened, ending up at the wrong LMA.
The workaround is to force the output of a dummy value in all
cases, ensuring that the rest of the text is at a sensible LMA.
This is
an issue that has been in GNU ld for years, and this workaround is
a
copy/paste of the same one in the ARMv7 ld script.
I see. Does the ld bug have an identifier that we could mention in a
comment in the linker script as a reference?
The only report I'm aware of is this one:
https://sourceware.org/bugzilla/show_bug.cgi?id=948
There may be other ways to work around this, but my linker-foo is
admittedly pretty limited.
Thanks,
M.
--
Fast, cheap, reliable. Pick two.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd_sf: add handler for +len arg for all commands
On Friday, October 10, 2014 at 11:16:05 PM, Maxime Hadjinlian wrote: Hi all, Hi! [...] +CC Altera guys, they might help too. Hmmm quite strange to write for sector aligned. Wonder the write related to filesystem access? Within Cadence QSPI controller, read and write access need to be done within a page. But that would be taken care by controller when the access beyond the next page. From software perspective, we just tell controller the numbers of bytes to be transfer (for indirect transfer setup). My needs have evolved a bit, and I no longer require this function. But I wasn't able to right a file tftp into RAM using 'sf update' without this patch. I could try to reproduce the errors and maybe dig in a little more. This would be really helpful. Esp. since the Cadence QSPI driver is coming to mainline in next MW. Thank you! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 03/10] mtd: nand: s3c: Fix data type width in debug()
Printing u32 with %02x is just a bad idea, fix it.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Scott Wood scottw...@freescale.com
Cc: Vladimir Zapolskiy v...@mleia.com
---
drivers/mtd/nand/s3c2410_nand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/s3c2410_nand.c b/drivers/mtd/nand/s3c2410_nand.c
index db87d07..399f2bc 100644
--- a/drivers/mtd/nand/s3c2410_nand.c
+++ b/drivers/mtd/nand/s3c2410_nand.c
@@ -43,7 +43,7 @@ static void s3c2410_hwcontrol(struct mtd_info *mtd, int cmd,
unsigned int ctrl)
struct nand_chip *chip = mtd-priv;
struct s3c2410_nand *nand = s3c2410_get_base_nand();
- debug(hwcontrol(): 0x%02x 0x%02x\n, cmd, ctrl);
+ debug(hwcontrol(): 0x%02x 0x%08x\n, cmd 0xff, ctrl);
if (ctrl NAND_CTRL_CHANGE) {
ulong IO_ADDR_W = (ulong)nand;
--
2.1.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 01/10] video: Add S3C24xx framebuffer support
Add basic framebuffer driver for the S3C24xx family of CPUs.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Anatolij Gustschin ag...@denx.de
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Vladimir Zapolskiy v...@mleia.com
V2: Keep the Makefile sorted.
---
drivers/video/Makefile | 1 +
drivers/video/cfb_console.c | 2 +-
drivers/video/s3c-fb.c | 172
3 files changed, 174 insertions(+), 1 deletion(-)
create mode 100644 drivers/video/s3c-fb.c
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 14a6781..0e407d0 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_VIDEO_MX3) += mx3fb.o videomodes.o
obj-$(CONFIG_VIDEO_IPUV3) += mxc_ipuv3_fb.o ipu_common.o ipu_disp.o
obj-$(CONFIG_VIDEO_MXS) += mxsfb.o videomodes.o
obj-$(CONFIG_VIDEO_OMAP3) += omap3_dss.o
+obj-$(CONFIG_VIDEO_S3C) += s3c-fb.o videomodes.o
obj-$(CONFIG_VIDEO_SANDBOX_SDL) += sandbox_sdl.o
obj-$(CONFIG_VIDEO_SED13806) += sed13806.o
obj-$(CONFIG_VIDEO_SM501) += sm501.o
diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index 9231927..98d10e3 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -135,7 +135,7 @@
#endif
#endif
-#ifdef CONFIG_VIDEO_MXS
+#if defined(CONFIG_VIDEO_MXS) || defined(CONFIG_VIDEO_S3C)
#define VIDEO_FB_16BPP_WORD_SWAP
#endif
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
new file mode 100644
index 000..521eb75
--- /dev/null
+++ b/drivers/video/s3c-fb.c
@@ -0,0 +1,172 @@
+/*
+ * S3C24x0 LCD driver
+ *
+ * NOTE: Only 16/24 bpp operation with TFT LCD is supported.
+ *
+ * Copyright (C) 2014 Marek Vasut ma...@denx.de
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include common.h
+#include malloc.h
+#include video_fb.h
+
+#include asm/errno.h
+#include asm/io.h
+#include asm/arch/s3c24x0_cpu.h
+
+#include videomodes.h
+
+static GraphicDevice panel;
+
+/* S3C requires the FB to be 4MiB aligned. */
+#define S3CFB_ALIGN(4 20)
+
+#define S3CFB_LCDCON1_CLKVAL(x)((x) 8)
+#define S3CFB_LCDCON1_PNRMODE_TFT (0x3 5)
+#define S3CFB_LCDCON1_BPPMODE_TFT_16BPP(0xc 1)
+#define S3CFB_LCDCON1_BPPMODE_TFT_24BPP(0xd 1)
+
+#define S3CFB_LCDCON2_VBPD(x) ((x) 24)
+#define S3CFB_LCDCON2_LINEVAL(x) ((x) 14)
+#define S3CFB_LCDCON2_VFPD(x) ((x) 6)
+#define S3CFB_LCDCON2_VSPW(x) ((x) 0)
+
+#define S3CFB_LCDCON3_HBPD(x) ((x) 19)
+#define S3CFB_LCDCON3_HOZVAL(x)((x) 8)
+#define S3CFB_LCDCON3_HFPD(x) ((x) 0)
+
+#define S3CFB_LCDCON4_HSPW(x) ((x) 0)
+
+#define S3CFB_LCDCON5_BPP24BL (1 12)
+#define S3CFB_LCDCON5_FRM565 (1 11)
+#define S3CFB_LCDCON5_HWSWP(1 0)
+
+#definePS2KHZ(ps) (10UL / (ps))
+
+/*
+ * Example:
+ * setenv videomode video=ctfb:x:800,y:480,depth:16,mode:0,\
+ *pclk:30066,le:41,ri:89,up:45,lo:12,
+ *hs:1,vs:1,sync:100663296,vmode:0
+ */
+static void s3c_lcd_init(GraphicDevice *panel,
+ struct ctfb_res_modes *mode, int bpp)
+{
+ uint32_t clk_divider;
+ struct s3c24x0_lcd *regs = s3c24x0_get_base_lcd();
+
+ /* Stop the controller. */
+ clrbits_le32(regs-lcdcon1, 1);
+
+ /* Calculate clock divider. */
+ clk_divider = (get_HCLK() / PS2KHZ(mode-pixclock)) / 1000;
+ clk_divider = DIV_ROUND_UP(clk_divider, 2);
+ if (clk_divider)
+ clk_divider -= 1;
+
+ /* Program LCD configuration. */
+ switch (bpp) {
+ case 16:
+ writel(S3CFB_LCDCON1_BPPMODE_TFT_16BPP |
+ S3CFB_LCDCON1_PNRMODE_TFT |
+ S3CFB_LCDCON1_CLKVAL(clk_divider),
+ regs-lcdcon1);
+ writel(S3CFB_LCDCON5_HWSWP | S3CFB_LCDCON5_FRM565,
+ regs-lcdcon5);
+ break;
+ case 24:
+ writel(S3CFB_LCDCON1_BPPMODE_TFT_24BPP |
+ S3CFB_LCDCON1_PNRMODE_TFT |
+ S3CFB_LCDCON1_CLKVAL(clk_divider),
+ regs-lcdcon1);
+ writel(S3CFB_LCDCON5_BPP24BL, regs-lcdcon5);
+ break;
+ }
+
+ writel(S3CFB_LCDCON2_LINEVAL(mode-yres - 1) |
+ S3CFB_LCDCON2_VBPD(mode-upper_margin - 1) |
+ S3CFB_LCDCON2_VFPD(mode-lower_margin - 1) |
+ S3CFB_LCDCON2_VSPW(mode-vsync_len - 1),
+ regs-lcdcon2);
+
+ writel(S3CFB_LCDCON3_HBPD(mode-right_margin - 1) |
+ S3CFB_LCDCON3_HFPD(mode-left_margin - 1) |
+ S3CFB_LCDCON3_HOZVAL(mode-xres - 1),
+ regs-lcdcon3);
+
+ writel(S3CFB_LCDCON4_HSPW(mode-hsync_len - 1),
+ regs-lcdcon4);
+
+ /* Write FB address. */
+
[U-Boot] [PATCH 02/10] arm: s3c24xx: Fix incorrect CONFIG_SYS_S3C2410_NAND_HWECC name
The correct name of this symbol is CONFIG_S3C2410_NAND_HWECC , the _SYS is redundant. Signed-off-by: Marek Vasut ma...@denx.de Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Lukasz Majewski l.majew...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com Cc: Scott Wood scottw...@freescale.com Cc: Vladimir Zapolskiy v...@mleia.com --- include/configs/VCMA9.h| 2 +- include/configs/smdk2410.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/configs/VCMA9.h b/include/configs/VCMA9.h index d40185e..a2ce7c5 100644 --- a/include/configs/VCMA9.h +++ b/include/configs/VCMA9.h @@ -201,7 +201,7 @@ /* NAND configuration */ #ifdef CONFIG_CMD_NAND #define CONFIG_NAND_S3C2410 -#define CONFIG_SYS_S3C2410_NAND_HWECC +#define CONFIG_S3C2410_NAND_HWECC #define CONFIG_SYS_MAX_NAND_DEVICE 1 #define CONFIG_SYS_NAND_BASE 0x4E00 #define CONFIG_S3C24XX_CUSTOM_NAND_TIMING diff --git a/include/configs/smdk2410.h b/include/configs/smdk2410.h index d4ae19f..0d0da28 100644 --- a/include/configs/smdk2410.h +++ b/include/configs/smdk2410.h @@ -172,7 +172,7 @@ */ #ifdef CONFIG_CMD_NAND #define CONFIG_NAND_S3C2410 -#define CONFIG_SYS_S3C2410_NAND_HWECC +#define CONFIG_S3C2410_NAND_HWECC #define CONFIG_SYS_MAX_NAND_DEVICE 1 #define CONFIG_SYS_NAND_BASE 0x4E00 #endif -- 2.1.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 08/10] i2c: s3c: Implant support for S3C2440
This is a matter of simple additional ifdefery to cater
for the different register layout of the S3C2440 chip.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Heiko Schocher h...@denx.de
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Vladimir Zapolskiy v...@mleia.com
---
drivers/i2c/s3c24x0_i2c.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/s3c24x0_i2c.c b/drivers/i2c/s3c24x0_i2c.c
index fd328f0..927cf61 100644
--- a/drivers/i2c/s3c24x0_i2c.c
+++ b/drivers/i2c/s3c24x0_i2c.c
@@ -153,7 +153,7 @@ static int GetI2CSDA(void)
{
struct s3c24x0_gpio *gpio = s3c24x0_get_base_gpio();
-#ifdef CONFIG_S3C2410
+#if defined(CONFIG_S3C2410) || defined(CONFIG_S3C2440)
return (readl(gpio-gpedat) 0x8000) 15;
#endif
#ifdef CONFIG_S3C2400
@@ -165,7 +165,7 @@ static void SetI2CSCL(int x)
{
struct s3c24x0_gpio *gpio = s3c24x0_get_base_gpio();
-#ifdef CONFIG_S3C2410
+#if defined(CONFIG_S3C2410) || defined(CONFIG_S3C2440)
writel((readl(gpio-gpedat) ~0x4000) |
(x 1) 14, gpio-gpedat);
#endif
@@ -427,7 +427,7 @@ static void s3c24x0_i2c_init(struct i2c_adapter *adap, int
speed, int slaveadd)
int i;
if ((readl(i2c-iicstat) I2CSTAT_BSY) || GetI2CSDA() == 0) {
-#ifdef CONFIG_S3C2410
+#if defined(CONFIG_S3C2410) || defined(CONFIG_S3C2440)
ulong old_gpecon = readl(gpio-gpecon);
#endif
#ifdef CONFIG_S3C2400
@@ -436,7 +436,7 @@ static void s3c24x0_i2c_init(struct i2c_adapter *adap, int
speed, int slaveadd)
/* bus still busy probably by (most) previously interrupted
transfer */
-#ifdef CONFIG_S3C2410
+#if defined(CONFIG_S3C2410) || defined(CONFIG_S3C2440)
/* set I2CSDA and I2CSCL (GPE15, GPE14) to GPIO */
writel((readl(gpio-gpecon) ~0xF000) | 0x1000,
gpio-gpecon);
@@ -462,7 +462,7 @@ static void s3c24x0_i2c_init(struct i2c_adapter *adap, int
speed, int slaveadd)
udelay(1000);
/* restore pin functions */
-#ifdef CONFIG_S3C2410
+#if defined(CONFIG_S3C2410) || defined(CONFIG_S3C2440)
writel(old_gpecon, gpio-gpecon);
#endif
#ifdef CONFIG_S3C2400
--
2.1.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 10/10] net: smc911x: Keep MAC programmed
Make sure to keep the MAC address programmed in the SMC911x ADDRH
and ADDRL registers. Linux can read those registers to determine
the MAC address on EEPROM-less configurations.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Joe Hershberger joe.hershber...@ni.com
Cc: Tom Rini tr...@ti.com
---
drivers/net/smc911x.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index b097c1a..5959672 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -187,6 +187,7 @@ static int smc911x_send(struct eth_device *dev, void
*packet, int length)
static void smc911x_halt(struct eth_device *dev)
{
smc911x_reset(dev);
+ smc911x_handle_mac_address(dev);
}
static int smc911x_rx(struct eth_device *dev)
--
2.1.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 09/10] gpio: s3c: Fix the GPIO driver
The GPIO driver didn't correctly compute the bank offset
from the GPIO number and caused random writes into the
GPIO block address space. Fix the driver so it actually
does the writes correctly. While at it, make use of the
clrsetbits_le32() mechanisms.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Vladimir Zapolskiy v...@mleia.com
---
drivers/gpio/s3c2440_gpio.c | 75 +
1 file changed, 42 insertions(+), 33 deletions(-)
diff --git a/drivers/gpio/s3c2440_gpio.c b/drivers/gpio/s3c2440_gpio.c
index e1e2d3f..d6c7eeb 100644
--- a/drivers/gpio/s3c2440_gpio.c
+++ b/drivers/gpio/s3c2440_gpio.c
@@ -8,53 +8,50 @@
#include asm/arch/s3c2440.h
#include asm/gpio.h
#include asm/io.h
+#include errno.h
#define GPIO_INPUT 0x0
#define GPIO_OUTPUT 0x1
-/* 0x4 means that we want DAT and not CON register */
-#define GPIO_PORT(x) x) 5) 0x3) + 0x4)
-#define GPIO_BIT(x)((x) 0x3f)
+#define S3C_GPIO_CON 0x0
+#define S3C_GPIO_DAT 0x4
-/*
- * It's how we calculate the full port address
- * We have to get the number of the port + 1 (Port A is at 0x5601 ...)
- * We move it at the second digit, and finally we add 0x4 because we want
- * to modify GPIO DAT and not CON
- */
-#define GPIO_FULLPORT(x) (S3C24X0_GPIO_BASE | ((GPIO_PORT(gpio) + 1) 1))
+static uint32_t s3c_gpio_get_bank_addr(unsigned gpio)
+{
+ /* There is up to 16 pins per bank, one bank is 0x10 big. */
+ uint32_t addr = gpio ~0xf;
+
+ if (addr = 0x80 addr != 0xd0) { /* Wrong GPIO bank. */
+ printf(Invalid GPIO bank (bank %02x)\n, addr);
+ return 0x;
+ }
+
+ return addr | S3C24X0_GPIO_BASE;
+}
int gpio_set_value(unsigned gpio, int value)
{
- unsigned l = readl(GPIO_FULLPORT(gpio));
- unsigned bit;
- unsigned port = GPIO_FULLPORT(gpio);
-
- /*
-* All GPIO Port have a configuration on
-* 2 bits excepted the first GPIO (A) which
-* have only 1 bit of configuration.
-*/
- if (!GPIO_PORT(gpio))
- bit = (0x1 GPIO_BIT(gpio));
- else
- bit = (0x3 GPIO_BIT(gpio));
+ uint32_t addr = s3c_gpio_get_bank_addr(gpio);
+
+ if (addr == 0x)
+ return -EINVAL;
if (value)
- l |= bit;
+ setbits_le32(addr | S3C_GPIO_DAT, 1 (gpio 0xf));
else
- l = ~bit;
+ clrbits_le32(addr | S3C_GPIO_DAT, 1 (gpio 0xf));
- return writel(l, port);
+ return 0;
}
int gpio_get_value(unsigned gpio)
{
- unsigned l = readl(GPIO_FULLPORT(gpio));
+ uint32_t addr = s3c_gpio_get_bank_addr(gpio);
+
+ if (addr == 0x)
+ return -EINVAL;
- if (GPIO_PORT(gpio) == 0) /* PORT A */
- return (l GPIO_BIT(gpio)) 0x1;
- return (l GPIO_BIT(gpio)) 0x3;
+ return !!(readl(addr | S3C_GPIO_DAT) (1 (gpio 0xf)));
}
int gpio_request(unsigned gpio, const char *label)
@@ -67,13 +64,25 @@ int gpio_free(unsigned gpio)
return 0;
}
+static int s3c_gpio_direction(unsigned gpio, uint8_t dir)
+{
+ uint32_t addr = s3c_gpio_get_bank_addr(gpio);
+ const uint32_t mask = 0x3 ((gpio 0xf) 1);
+ const uint32_t dirm = dir ((gpio 0xf) 1);
+
+ if (addr == 0x)
+ return -EINVAL;
+
+ clrsetbits_le32(addr | S3C_GPIO_CON, mask, dirm);
+ return 0;
+}
+
int gpio_direction_input(unsigned gpio)
{
- return writel(GPIO_INPUT GPIO_BIT(gpio), GPIO_FULLPORT(gpio));
+ return s3c_gpio_direction(gpio, GPIO_INPUT);
}
int gpio_direction_output(unsigned gpio, int value)
{
- writel(GPIO_OUTPUT GPIO_BIT(gpio), GPIO_FULLPORT(gpio));
- return gpio_set_value(gpio, value);
+ return s3c_gpio_direction(gpio, GPIO_OUTPUT);
}
--
2.1.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 05/10] mtd: nand: s3c: Add S3C2440 specifics
Add support for S3C2440 into the NAND driver by filling in the
S3C2440 bits and differences.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Scott Wood scottw...@freescale.com
Cc: Vladimir Zapolskiy v...@mleia.com
---
drivers/mtd/nand/s3c2410_nand.c | 55 -
1 file changed, 43 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/nand/s3c2410_nand.c b/drivers/mtd/nand/s3c2410_nand.c
index 8db432f..4971342 100644
--- a/drivers/mtd/nand/s3c2410_nand.c
+++ b/drivers/mtd/nand/s3c2410_nand.c
@@ -12,13 +12,22 @@
#include asm/io.h
#define S3C2410_NFCONF_EN (115)
+#define S3C2440_NFCONT_EN (10)
#define S3C2410_NFCONF_512BYTE (114)
#define S3C2410_NFCONF_4STEP (113)
#define S3C2410_NFCONF_INITECC (112)
+#define S3C2440_NFCONT_INITECC (14)
#define S3C2410_NFCONF_nFCE(111)
+#define S3C2440_NFCONT_nFCE(11)
+#ifdef CONFIG_S3C2410
#define S3C2410_NFCONF_TACLS(x)((x)8)
#define S3C2410_NFCONF_TWRPH0(x) ((x)4)
#define S3C2410_NFCONF_TWRPH1(x) ((x)0)
+#else /* S3C2412, S3C2440 */
+#define S3C2410_NFCONF_TACLS(x)((x)12)
+#define S3C2410_NFCONF_TWRPH0(x) ((x)8)
+#define S3C2410_NFCONF_TWRPH1(x) ((x)4)
+#endif
#define S3C2410_ADDR_NALE 4
#define S3C2410_ADDR_NCLE 8
@@ -42,25 +51,30 @@ static void s3c24x0_hwcontrol(struct mtd_info *mtd, int
cmd, unsigned int ctrl)
{
struct nand_chip *chip = mtd-priv;
struct s3c24x0_nand *nand = s3c24x0_get_base_nand();
+ uint32_t sel_reg, sel_bit;
debug(hwcontrol(): 0x%02x 0x%08x\n, cmd 0xff, ctrl);
if (ctrl NAND_CTRL_CHANGE) {
- ulong IO_ADDR_W = (ulong)nand;
+ chip-IO_ADDR_W = nand-nfconf;
if (!(ctrl NAND_CLE))
- IO_ADDR_W |= S3C2410_ADDR_NCLE;
+ chip-IO_ADDR_W = nand-nfaddr;
if (!(ctrl NAND_ALE))
- IO_ADDR_W |= S3C2410_ADDR_NALE;
+ chip-IO_ADDR_W = nand-nfcmd;
- chip-IO_ADDR_W = (void *)IO_ADDR_W;
+#ifdef CONFIG_S3C2410
+ sel_reg = (uint32_t)nand-nfconf;
+ sel_bit = S3C2410_NFCONF_nFCE;
+#else
+ sel_reg = (uint32_t)nand-nfcont;
+ sel_bit = S3C2440_NFCONT_nFCE;
+#endif
if (ctrl NAND_NCE)
- writel(readl(nand-nfconf) ~S3C2410_NFCONF_nFCE,
- nand-nfconf);
+ clrbits_le32(sel_reg, sel_bit);
else
- writel(readl(nand-nfconf) | S3C2410_NFCONF_nFCE,
- nand-nfconf);
+ setbits_le32(sel_reg, sel_bit);
}
if (cmd != NAND_CMD_NONE)
@@ -79,16 +93,27 @@ void s3c24x0_nand_enable_hwecc(struct mtd_info *mtd, int
mode)
{
struct s3c24x0_nand *nand = s3c24x0_get_base_nand();
debug(s3c24x0_nand_enable_hwecc(%p, %d)\n, mtd, mode);
- writel(readl(nand-nfconf) | S3C2410_NFCONF_INITECC, nand-nfconf);
+#ifdef CONFIG_S3C2410
+ setbits_le32(nand-nfconf, S3C2410_NFCONF_INITECC);
+#else
+ setbits_le32(nand-nfcont, S3C2440_NFCONT_INITECC);
+#endif
}
static int s3c24x0_nand_calculate_ecc(struct mtd_info *mtd, const u_char *dat,
u_char *ecc_code)
{
struct s3c24x0_nand *nand = s3c24x0_get_base_nand();
+#ifdef CONFIG_S3C2410
ecc_code[0] = readb(nand-nfecc);
ecc_code[1] = readb(nand-nfecc + 1);
ecc_code[2] = readb(nand-nfecc + 2);
+#else
+ uint32_t ecc = readl(nand-nfmecc0);
+ ecc_code[0] = ecc;
+ ecc_code[1] = ecc 8;
+ ecc_code[2] = ecc 16;
+#endif
debug(s3c24x0_nand_calculate_hwecc(%p,): 0x%02x 0x%02x 0x%02x\n,
mtd , ecc_code[0], ecc_code[1], ecc_code[2]);
@@ -110,14 +135,14 @@ static int s3c24x0_nand_correct_data(struct mtd_info
*mtd, u_char *dat,
int board_nand_init(struct nand_chip *nand)
{
- u_int32_t cfg;
+ uint32_t cfg = 0;
u_int8_t tacls, twrph0, twrph1;
struct s3c24x0_clock_power *clk_power = s3c24x0_get_base_clock_power();
struct s3c24x0_nand *nand_reg = s3c24x0_get_base_nand();
debug(board_nand_init()\n);
- writel(readl(clk_power-clkcon) | (1 4), clk_power-clkcon);
+ setbits_le32(clk_power-clkcon, 1 4);
/* initialize hardware */
#if defined(CONFIG_S3C24XX_CUSTOM_NAND_TIMING)
@@ -130,12 +155,18 @@ int board_nand_init(struct nand_chip *nand)
twrph1 = 8;
#endif
- cfg = S3C2410_NFCONF_EN;
+#ifdef CONFIG_S3C2410
+ cfg |= S3C2410_NFCONF_EN;
+#endif
cfg |= S3C2410_NFCONF_TACLS(tacls - 1);
cfg |= S3C2410_NFCONF_TWRPH0(twrph0 - 1);
cfg |= S3C2410_NFCONF_TWRPH1(twrph1 - 1);
writel(cfg, nand_reg-nfconf);
+#ifndef CONFIG_S3C2410
+
[U-Boot] [PATCH 07/10] mtd: nand: s3c: Add missing correction and select_chip functions
Implant a missing ECC correction implementation and select_chip
implementation from Linux.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Scott Wood scottw...@freescale.com
Cc: Vladimir Zapolskiy v...@mleia.com
---
drivers/mtd/nand/s3c2410_nand.c | 89 ++---
1 file changed, 84 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/s3c2410_nand.c b/drivers/mtd/nand/s3c2410_nand.c
index 91db6ca..f23a1c8 100644
--- a/drivers/mtd/nand/s3c2410_nand.c
+++ b/drivers/mtd/nand/s3c2410_nand.c
@@ -157,16 +157,93 @@ static int s3c24x0_nand_calculate_ecc(struct mtd_info
*mtd, const u_char *dat,
static int s3c24x0_nand_correct_data(struct mtd_info *mtd, u_char *dat,
u_char *read_ecc, u_char *calc_ecc)
{
- if (read_ecc[0] == calc_ecc[0]
- read_ecc[1] == calc_ecc[1]
- read_ecc[2] == calc_ecc[2])
+ unsigned int diff0, diff1, diff2;
+ unsigned int bit, byte;
+
+ debug(%s(%p,%p,%p,%p)\n, __func__, mtd, dat, read_ecc, calc_ecc);
+
+ diff0 = read_ecc[0] ^ calc_ecc[0];
+ diff1 = read_ecc[1] ^ calc_ecc[1];
+ diff2 = read_ecc[2] ^ calc_ecc[2];
+
+ debug(%s: rd %*phN calc %*phN diff %02x%02x%02x\n,
+ __func__, 3, read_ecc, 3, calc_ecc,
+ diff0, diff1, diff2);
+
+ if (diff0 == 0 diff1 == 0 diff2 == 0)
+ return 0; /* ECC is ok */
+
+ /* sometimes people do not think about using the ECC, so check
+* to see if we have an 0xff,0xff,0xff read ECC and then ignore
+* the error, on the assumption that this is an un-eccd page.
+*/
+ if (read_ecc[0] == 0xff read_ecc[1] == 0xff read_ecc[2] == 0xff
+ /* info-platform-ignore_unset_ecc*/)
return 0;
- printf(s3c24x0_nand_correct_data: not implemented\n);
+ /* Can we correct this ECC (ie, one row and column change).
+* Note, this is similar to the 256 error code on smartmedia */
+
+ if (((diff0 ^ (diff0 1)) 0x55) == 0x55
+ ((diff1 ^ (diff1 1)) 0x55) == 0x55
+ ((diff2 ^ (diff2 1)) 0x55) == 0x55) {
+ /* calculate the bit position of the error */
+
+ bit = ((diff2 3) 1) |
+ ((diff2 4) 2) |
+ ((diff2 5) 4);
+
+ /* calculate the byte position of the error */
+
+ byte = ((diff2 7) 0x100) |
+ ((diff1 0) 0x80) |
+ ((diff1 1) 0x40) |
+ ((diff1 2) 0x20) |
+ ((diff1 3) 0x10) |
+ ((diff0 4) 0x08) |
+ ((diff0 3) 0x04) |
+ ((diff0 2) 0x02) |
+ ((diff0 1) 0x01);
+
+ debug(correcting error bit %d, byte %d\n, bit, byte);
+
+ dat[byte] ^= (1 bit);
+ return 1;
+ }
+
+ /* if there is only one bit difference in the ECC, then
+* one of only a row or column parity has changed, which
+* means the error is most probably in the ECC itself */
+
+ diff0 |= (diff1 8);
+ diff0 |= (diff2 16);
+
+ if ((diff0 ~(1fls(diff0))) == 0)
+ return 1;
+
return -1;
}
#endif
+static void s3c24x0_nand_select_chip(struct mtd_info *mtd, int chip)
+{
+ struct s3c24x0_nand *nand = s3c24x0_get_base_nand();
+ uint32_t sel_reg, sel_bit;
+
+#ifdef CONFIG_S3C2410
+ sel_reg = (uint32_t)nand-nfconf;
+ sel_bit = S3C2410_NFCONF_nFCE;
+#else
+ sel_reg = (uint32_t)nand-nfcont;
+ sel_bit = S3C2440_NFCONT_nFCE;
+#endif
+
+ if (chip == -1)
+ setbits_le32(sel_reg, sel_bit);
+ else
+ clrbits_le32(sel_reg, sel_bit);
+}
+
int board_nand_init(struct nand_chip *nand)
{
uint32_t cfg = 0;
@@ -205,7 +282,7 @@ int board_nand_init(struct nand_chip *nand)
nand-IO_ADDR_R = (void *)nand_reg-nfdata;
nand-IO_ADDR_W = (void *)nand_reg-nfdata;
- nand-select_chip = NULL;
+ nand-select_chip = s3c24x0_nand_select_chip;
/* read_buf and write_buf are default */
/* read_byte and write_byte are default */
@@ -221,6 +298,8 @@ int board_nand_init(struct nand_chip *nand)
nand-dev_ready = s3c24x0_dev_ready;
+ nand-chip_delay = 50;
+
#ifdef CONFIG_S3C2410_NAND_HWECC
nand-ecc.hwctl = s3c24x0_nand_enable_hwecc;
nand-ecc.calculate = s3c24x0_nand_calculate_ecc;
--
2.1.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/10] mtd: nand: s3c: Unify the register definition and naming
Merge struct s3c2410_nand and struct s3c2440_nand into one unified
struct s3c24x0_nand. While at it, fix up and rename the functions
to retrieve the NAND base address and fix up the s3c NAND driver to
reflect this change.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Scott Wood scottw...@freescale.com
Cc: Vladimir Zapolskiy v...@mleia.com
---
arch/arm/include/asm/arch-s3c24x0/s3c2410.h | 4 +--
arch/arm/include/asm/arch-s3c24x0/s3c2440.h | 4 +--
arch/arm/include/asm/arch-s3c24x0/s3c24x0.h | 31 ---
drivers/mtd/nand/s3c2410_nand.c | 38 ++---
4 files changed, 38 insertions(+), 39 deletions(-)
diff --git a/arch/arm/include/asm/arch-s3c24x0/s3c2410.h
b/arch/arm/include/asm/arch-s3c24x0/s3c2410.h
index ce4186f..8773ce3 100644
--- a/arch/arm/include/asm/arch-s3c24x0/s3c2410.h
+++ b/arch/arm/include/asm/arch-s3c24x0/s3c2410.h
@@ -83,9 +83,9 @@ static inline struct s3c24x0_lcd *s3c24x0_get_base_lcd(void)
return (struct s3c24x0_lcd *)S3C24X0_LCD_BASE;
}
-static inline struct s3c2410_nand *s3c2410_get_base_nand(void)
+static inline struct s3c24x0_nand *s3c24x0_get_base_nand(void)
{
- return (struct s3c2410_nand *)S3C2410_NAND_BASE;
+ return (struct s3c24x0_nand *)S3C2410_NAND_BASE;
}
static inline struct s3c24x0_uart
diff --git a/arch/arm/include/asm/arch-s3c24x0/s3c2440.h
b/arch/arm/include/asm/arch-s3c24x0/s3c2440.h
index 3f44bdc..7a525f2 100644
--- a/arch/arm/include/asm/arch-s3c24x0/s3c2440.h
+++ b/arch/arm/include/asm/arch-s3c24x0/s3c2440.h
@@ -81,9 +81,9 @@ static inline struct s3c24x0_lcd *s3c24x0_get_base_lcd(void)
return (struct s3c24x0_lcd *)S3C24X0_LCD_BASE;
}
-static inline struct s3c2440_nand *s3c2440_get_base_nand(void)
+static inline struct s3c24x0_nand *s3c24x0_get_base_nand(void)
{
- return (struct s3c2440_nand *)S3C2440_NAND_BASE;
+ return (struct s3c24x0_nand *)S3C2440_NAND_BASE;
}
static inline struct s3c24x0_uart
diff --git a/arch/arm/include/asm/arch-s3c24x0/s3c24x0.h
b/arch/arm/include/asm/arch-s3c24x0/s3c24x0.h
index ed9df34..2dae9fc 100644
--- a/arch/arm/include/asm/arch-s3c24x0/s3c24x0.h
+++ b/arch/arm/include/asm/arch-s3c24x0/s3c24x0.h
@@ -135,34 +135,33 @@ struct s3c24x0_lcd {
};
-#ifdef CONFIG_S3C2410
-/* NAND FLASH (see S3C2410 manual chapter 6) */
-struct s3c2410_nand {
- u32 nfconf;
- u32 nfcmd;
- u32 nfaddr;
- u32 nfdata;
- u32 nfstat;
- u32 nfecc;
-};
-#endif
-#ifdef CONFIG_S3C2440
-/* NAND FLASH (see S3C2440 manual chapter 6) */
-struct s3c2440_nand {
+/* NAND FLASH (see manual chapter 6) */
+struct s3c24x0_nand {
u32 nfconf;
+#ifndef CONFIG_S3C2410
u32 nfcont;
+#endif
u32 nfcmd;
u32 nfaddr;
u32 nfdata;
+#ifndef CONFIG_S3C2410
u32 nfeccd0;
u32 nfeccd1;
u32 nfeccd;
+#endif
u32 nfstat;
+#ifdef CONFIG_S3C2410
+ u32 nfecc;
+#else
u32 nfstat0;
u32 nfstat1;
-};
+ u32 nfmecc0;
+ u32 nfmecc1;
+ u32 nfsecc;
+ u32 nfsblk;
+ u32 nfeblk;
#endif
-
+};
/* UART (see manual chapter 11) */
struct s3c24x0_uart {
diff --git a/drivers/mtd/nand/s3c2410_nand.c b/drivers/mtd/nand/s3c2410_nand.c
index 399f2bc..8db432f 100644
--- a/drivers/mtd/nand/s3c2410_nand.c
+++ b/drivers/mtd/nand/s3c2410_nand.c
@@ -38,10 +38,10 @@ static void nand_read_buf(struct mtd_info *mtd, u_char
*buf, int len)
}
#endif
-static void s3c2410_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl)
+static void s3c24x0_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl)
{
struct nand_chip *chip = mtd-priv;
- struct s3c2410_nand *nand = s3c2410_get_base_nand();
+ struct s3c24x0_nand *nand = s3c24x0_get_base_nand();
debug(hwcontrol(): 0x%02x 0x%08x\n, cmd 0xff, ctrl);
@@ -67,35 +67,35 @@ static void s3c2410_hwcontrol(struct mtd_info *mtd, int
cmd, unsigned int ctrl)
writeb(cmd, chip-IO_ADDR_W);
}
-static int s3c2410_dev_ready(struct mtd_info *mtd)
+static int s3c24x0_dev_ready(struct mtd_info *mtd)
{
- struct s3c2410_nand *nand = s3c2410_get_base_nand();
+ struct s3c24x0_nand *nand = s3c24x0_get_base_nand();
debug(dev_ready\n);
return readl(nand-nfstat) 0x01;
}
#ifdef CONFIG_S3C2410_NAND_HWECC
-void s3c2410_nand_enable_hwecc(struct mtd_info *mtd, int mode)
+void s3c24x0_nand_enable_hwecc(struct mtd_info *mtd, int mode)
{
- struct s3c2410_nand *nand = s3c2410_get_base_nand();
- debug(s3c2410_nand_enable_hwecc(%p, %d)\n, mtd, mode);
+ struct s3c24x0_nand *nand = s3c24x0_get_base_nand();
+ debug(s3c24x0_nand_enable_hwecc(%p, %d)\n, mtd, mode);
writel(readl(nand-nfconf) | S3C2410_NFCONF_INITECC,
[U-Boot] [PATCH 06/10] mtd: nand: s3c: Add S3C2440 buffer reading
Add buffer reading code, should make the IO a little faster.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Scott Wood scottw...@freescale.com
Cc: Vladimir Zapolskiy v...@mleia.com
---
drivers/mtd/nand/s3c2410_nand.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/drivers/mtd/nand/s3c2410_nand.c b/drivers/mtd/nand/s3c2410_nand.c
index 4971342..91db6ca 100644
--- a/drivers/mtd/nand/s3c2410_nand.c
+++ b/drivers/mtd/nand/s3c2410_nand.c
@@ -10,6 +10,7 @@
#include nand.h
#include asm/arch/s3c24x0_cpu.h
#include asm/io.h
+#include asm/unaligned.h
#define S3C2410_NFCONF_EN (115)
#define S3C2440_NFCONT_EN (10)
@@ -45,6 +46,39 @@ static void nand_read_buf(struct mtd_info *mtd, u_char *buf,
int len)
for (i = 0; i len; i++)
buf[i] = readb(this-IO_ADDR_R);
}
+#elif !defined(CONFIG_S3C2410)
+static void s3c2440_read_buf(struct mtd_info *mtd, u_char *buf, int len)
+{
+ struct s3c24x0_nand *nand = s3c24x0_get_base_nand();
+ uint32_t data;
+
+ while (len = 4) {
+ data = readl(nand-nfdata);
+ put_unaligned_le32(data, buf);
+ buf += 4;
+ len -= 4;
+ }
+
+ for (; len 3; len--)
+ *buf++ = readb(nand-nfdata);
+}
+
+static void s3c2440_write_buf(struct mtd_info *mtd, const u_char *buf,
+ int len)
+{
+ struct s3c24x0_nand *nand = s3c24x0_get_base_nand();
+ uint32_t data;
+
+ while (len = 4) {
+ data = get_unaligned_le32(buf);
+ writel(data, nand-nfdata);
+ buf += 4;
+ len -= 4;
+ }
+
+ for (; len 3; len--, buf++)
+ writeb(*buf, nand-nfdata);
+}
#endif
static void s3c24x0_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl)
@@ -177,6 +211,9 @@ int board_nand_init(struct nand_chip *nand)
/* read_byte and write_byte are default */
#ifdef CONFIG_NAND_SPL
nand-read_buf = nand_read_buf;
+#elif !defined(CONFIG_S3C2410)
+ nand-read_buf = s3c2440_read_buf;
+ nand-write_buf = s3c2440_write_buf;
#endif
/* hwcontrol always must be implemented */
--
2.1.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] kconfig: add CONFIG_SUPPORT_TPL
Hi Albert, 2014-10-11 17:56 GMT+09:00 Albert ARIBAUD albert.u.b...@aribaud.net: Hi Masahiro, On Thu, 25 Sep 2014 18:19:07 +0900, Masahiro Yamada yamad...@jp.panasonic.com wrote: CONFIG_TPL should not be enabled for boards that do not have TPL. CONFIG_SUPPORT_TPL introduced by this commit should be selected by boards with TPL support and CONFIG_TPL should depend on it. Actually, I see no CONFIG_SUPPORT_TPL in the patch, only HAVE_TPL_SUPPORT. The commit message should match the patch content on this point, should it not? I am guessing you are seeing the old patch (v1) that has been already Superseded. The newest of this patch is v3: http://patchwork.ozlabs.org/patch/397543/ -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 05/29] dm: spi: Add a uclass for SPI
Hi Simon, On 11 October 2014 04:56, Simon Glass s...@chromium.org wrote: Hi Jagan, On 10 October 2014 12:37, Jagan Teki jagannadh.t...@gmail.com wrote: Hi Simon, On 10 October 2014 23:35, Simon Glass s...@chromium.org wrote: Hi Jagan, On 10 October 2014 11:31, Jagan Teki jagannadh.t...@gmail.com wrote: Hi Simon, Can you please see my comments below, I'm relating more about cs and bus valid scenario which is available on current drivers wrt dm-spi. On 30 September 2014 01:05, Simon Glass s...@chromium.org wrote: Add a uclass which provides access to SPI buses and includes operations required by SPI. For a time driver model will need to co-exist with the legacy SPI interface so some parts of the header file are changed depending on which is in use. The exports are adjusted also since some functions are not available with driver model. Boards must define CONFIG_DM_SPI to use driver model for SPI. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: - Add a cs_info() method to the driver model SPI API I think this gives the enough info regarding cs on particular controller what about the bus usage - which is also specific to controller it self, right? Say - spi controller on a particular soc, have spi0, spi1 means two buses and 4 cs lines, cs0-cs3. How is this works in that case? And also I saw tegra20_sflash.c validates only cs int tegra20_sflash_cs_info(struct udevice *bus, unsigned int cs, struct spi_cs_info *info) What about bus number check this particular tegra spi controller is concern. The bus device is passed in as a pointer. The bus number gets looked up to find the device for that bus number. See spi_get_bus_and_cs() for that. This is good because drivers no longer need to validate the bus number. Agreed, but for controlling sf probe bus:cs options bus number should get from the respective driver. I wonder if the issue here is a difference of understanding about bus and chip select. In my mind, bus is just a device. We use the bus number to specify which device we mean, but it is just a a convenience. If there were some other way of finding the device we would use it (as we do with device tree, for example). Yes, I do believe that by mentioning bus spi0, spi1 on the devicetree so the respective bus get's bind'ed till that fine. But as we use runtime probe using sf probe bus:cs where I would mention # sf probe 2:0 selecting spi2 which is of third bus on the same controller driver will that spi_cs_is_valid() will show spi2 is invalid for this particular driver? Similarly, chip select is just a device. We look at the bus device, find the appropriate chip select number, and end up with a child device which is referred to by that chip select. Just like validating supported cs, through cs_info I assume the same works for bus as well as this is a pure driver specific theory. I have a suggestion, like in spi_find_bus_and_cs() or spi_get_bus_and_cs() we have a function calls for uclass_get_device_by_seq() and spi_find_bus_and_cs() along with that ops-cs_info(bus, cs, info) by adding bus number check for the driver. So-that there is no requirement to call spi_cs_is_valid from any other location as bus and cs validates through commands itself. At present spi_cs_info() calls spi_find_chip_select(). I think I see what you are getting at - you don't want a device to be created unless cs_info() allows it, right? I will take a look. Yes ie my point, along with that instead of a separate caller for spi_cs_info() why can't we call in the probe time, either from command or at the time of bus_cs binding. Once the bus_cs binding done, and validate the mentioned bus and cs from command or devicetree and return. Does this make sense, please comment? BTW: in tegra20_sflash.c, how does tegra20_sflash_cs_info() called? Only if someone calls spi_cs_info(). I don't think there are any callers at present. With tegra using device tree I'm not sure it would have any purpose - the chip selects and buses are all known. Yes devicetree will help to take but validating should be require as driver only knows how many bus's with respective supported chip-selects based on this command user may verify the same. what do think? - Add a uclass for a generic SPI device (for use with the 'sspi' command) - Add missing comments to spi.h - Correct typo where 'slave' should say 'bus' - Fix two comment typos - Put the cs member back into spi_slave - Use an explicit chip select value instead of reusing device sequence number Changes in v2: - Add missing comments for struct spi_slave - Fix code nits from Daniel Schwierzeck - Use 'bus' instead of 'dev' to make the API clearer common/exports.c | 4 +- drivers/spi/Makefile | 4 + drivers/spi/spi-uclass.c | 390 +++ include/dm/uclass-id.h | 2 + include/spi.h| 254
Re: [U-Boot] [PATCH v3 05/29] dm: spi: Add a uclass for SPI
Hi Jagan, On 11 October 2014 11:33, Jagan Teki jagannadh.t...@gmail.com wrote: Hi Simon, On 11 October 2014 04:56, Simon Glass s...@chromium.org wrote: Hi Jagan, On 10 October 2014 12:37, Jagan Teki jagannadh.t...@gmail.com wrote: Hi Simon, On 10 October 2014 23:35, Simon Glass s...@chromium.org wrote: Hi Jagan, On 10 October 2014 11:31, Jagan Teki jagannadh.t...@gmail.com wrote: Hi Simon, Can you please see my comments below, I'm relating more about cs and bus valid scenario which is available on current drivers wrt dm-spi. On 30 September 2014 01:05, Simon Glass s...@chromium.org wrote: Add a uclass which provides access to SPI buses and includes operations required by SPI. For a time driver model will need to co-exist with the legacy SPI interface so some parts of the header file are changed depending on which is in use. The exports are adjusted also since some functions are not available with driver model. Boards must define CONFIG_DM_SPI to use driver model for SPI. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: - Add a cs_info() method to the driver model SPI API I think this gives the enough info regarding cs on particular controller what about the bus usage - which is also specific to controller it self, right? Say - spi controller on a particular soc, have spi0, spi1 means two buses and 4 cs lines, cs0-cs3. How is this works in that case? And also I saw tegra20_sflash.c validates only cs int tegra20_sflash_cs_info(struct udevice *bus, unsigned int cs, struct spi_cs_info *info) What about bus number check this particular tegra spi controller is concern. The bus device is passed in as a pointer. The bus number gets looked up to find the device for that bus number. See spi_get_bus_and_cs() for that. This is good because drivers no longer need to validate the bus number. Agreed, but for controlling sf probe bus:cs options bus number should get from the respective driver. I wonder if the issue here is a difference of understanding about bus and chip select. In my mind, bus is just a device. We use the bus number to specify which device we mean, but it is just a a convenience. If there were some other way of finding the device we would use it (as we do with device tree, for example). Yes, I do believe that by mentioning bus spi0, spi1 on the devicetree so the respective bus get's bind'ed till that fine. But as we use runtime probe using sf probe bus:cs where I would mention # sf probe 2:0 selecting spi2 which is of third bus on the same controller driver will that spi_cs_is_valid() will show spi2 is invalid for this particular driver? Run-time binding of SPI buses is supported by driver model (just call device_bind()) but not by the sf probe command. We should know what SPI buses exist through device tree or platform data. So no, the that method is intended to validate a chip select, not a bus. Similarly, chip select is just a device. We look at the bus device, find the appropriate chip select number, and end up with a child device which is referred to by that chip select. Just like validating supported cs, through cs_info I assume the same works for bus as well as this is a pure driver specific theory. Not at present. In fact I feel that both bus and cs should be known in advance, but to keep compatibility (and since there is no platform data available for chip selects) I have added the auto-bind used by the 'sf probe' and 'sspi' commands. I have a suggestion, like in spi_find_bus_and_cs() or spi_get_bus_and_cs() we have a function calls for uclass_get_device_by_seq() and spi_find_bus_and_cs() along with that ops-cs_info(bus, cs, info) by adding bus number check for the driver. So-that there is no requirement to call spi_cs_is_valid from any other location as bus and cs validates through commands itself. At present spi_cs_info() calls spi_find_chip_select(). I think I see what you are getting at - you don't want a device to be created unless cs_info() allows it, right? I will take a look. Yes ie my point, along with that instead of a separate caller for spi_cs_info() why can't we call in the probe time, either from command or at the time of bus_cs binding. Once the bus_cs binding done, and validate the mentioned bus and cs from command or devicetree and return. Does this make sense, please comment? I'm starting to feel that (beyond the idea of using cs_info() more) what you are referring to here is best handled in follow-up discussion and patches once this initial support is merged. There seem to be several questions that are hard to answer until we actually come to implementation: - qspi (could be implemented in sandbox, I don't have a qspi board at present) - chip selects via GPIO (I am planning to look at this before long) - platform data for chip selects (likely will be used for at91 or something like that BTW: in
Re: [U-Boot] [PATCH v3 05/29] dm: spi: Add a uclass for SPI
Hi Simon, On 11 October 2014 23:13, Simon Glass s...@chromium.org wrote: Hi Jagan, On 11 October 2014 11:33, Jagan Teki jagannadh.t...@gmail.com wrote: Hi Simon, On 11 October 2014 04:56, Simon Glass s...@chromium.org wrote: Hi Jagan, On 10 October 2014 12:37, Jagan Teki jagannadh.t...@gmail.com wrote: Hi Simon, On 10 October 2014 23:35, Simon Glass s...@chromium.org wrote: Hi Jagan, On 10 October 2014 11:31, Jagan Teki jagannadh.t...@gmail.com wrote: Hi Simon, Can you please see my comments below, I'm relating more about cs and bus valid scenario which is available on current drivers wrt dm-spi. On 30 September 2014 01:05, Simon Glass s...@chromium.org wrote: Add a uclass which provides access to SPI buses and includes operations required by SPI. For a time driver model will need to co-exist with the legacy SPI interface so some parts of the header file are changed depending on which is in use. The exports are adjusted also since some functions are not available with driver model. Boards must define CONFIG_DM_SPI to use driver model for SPI. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: - Add a cs_info() method to the driver model SPI API I think this gives the enough info regarding cs on particular controller what about the bus usage - which is also specific to controller it self, right? Say - spi controller on a particular soc, have spi0, spi1 means two buses and 4 cs lines, cs0-cs3. How is this works in that case? And also I saw tegra20_sflash.c validates only cs int tegra20_sflash_cs_info(struct udevice *bus, unsigned int cs, struct spi_cs_info *info) What about bus number check this particular tegra spi controller is concern. The bus device is passed in as a pointer. The bus number gets looked up to find the device for that bus number. See spi_get_bus_and_cs() for that. This is good because drivers no longer need to validate the bus number. Agreed, but for controlling sf probe bus:cs options bus number should get from the respective driver. I wonder if the issue here is a difference of understanding about bus and chip select. In my mind, bus is just a device. We use the bus number to specify which device we mean, but it is just a a convenience. If there were some other way of finding the device we would use it (as we do with device tree, for example). Yes, I do believe that by mentioning bus spi0, spi1 on the devicetree so the respective bus get's bind'ed till that fine. But as we use runtime probe using sf probe bus:cs where I would mention # sf probe 2:0 selecting spi2 which is of third bus on the same controller driver will that spi_cs_is_valid() will show spi2 is invalid for this particular driver? Run-time binding of SPI buses is supported by driver model (just call device_bind()) but not by the sf probe command. We should know what SPI buses exist through device tree or platform data. So no, the that method is intended to validate a chip select, not a bus. Similarly, chip select is just a device. We look at the bus device, find the appropriate chip select number, and end up with a child device which is referred to by that chip select. Just like validating supported cs, through cs_info I assume the same works for bus as well as this is a pure driver specific theory. Not at present. In fact I feel that both bus and cs should be known in advance, but to keep compatibility (and since there is no platform data available for chip selects) I have added the auto-bind used by the 'sf probe' and 'sspi' commands. I have a suggestion, like in spi_find_bus_and_cs() or spi_get_bus_and_cs() we have a function calls for uclass_get_device_by_seq() and spi_find_bus_and_cs() along with that ops-cs_info(bus, cs, info) by adding bus number check for the driver. So-that there is no requirement to call spi_cs_is_valid from any other location as bus and cs validates through commands itself. At present spi_cs_info() calls spi_find_chip_select(). I think I see what you are getting at - you don't want a device to be created unless cs_info() allows it, right? I will take a look. Yes ie my point, along with that instead of a separate caller for spi_cs_info() why can't we call in the probe time, either from command or at the time of bus_cs binding. Once the bus_cs binding done, and validate the mentioned bus and cs from command or devicetree and return. Does this make sense, please comment? I'm starting to feel that (beyond the idea of using cs_info() more) what you are referring to here is best handled in follow-up discussion and patches once this initial support is merged. There seem to be several questions that are hard to answer until we actually come to implementation: - qspi (could be implemented in sandbox, I don't have a qspi board at present) - chip selects via GPIO (I am planning to look at this before long) - platform data
Re: [U-Boot] [SoCFPGA] next steps
Hi Marek, 2014-10-07 21:45 GMT+09:00 Marek Vasut ma...@denx.de: Hey, given that we now have most of the u-boot socfpga stuff in mainline, I decided it would be a good idea to list what we're still missing and we should also decide how to move on now. Can you refactor arch/arm/include/asm/spl.h and arch/arm/include/asm/arch-socfpga/spl.h ? I mean, I want all the SoCs to use BOOT_DEVICE_* defined in arch/arm/include/asm/spl.h rather than duplicating it in arch/arm/include/asm/arch-*/spl.h I am expecting something like what Michal did for Zynq in commit dbc31f6a and commit ae2ee77f98. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/29] Introduce driver model support for SPI, SPI flash, cros_ec
On 30 September 2014 01:04, Simon Glass s...@chromium.org wrote: Up until now driver model has not been used for any type of bus. Buses have some unique properties and needs, so we cannot claim that driver model can cover all the common cases unless we have converted a bus over to driver model. SPI is a reasonable choice for this next step. It has a fairly simple API and not too many dependencies. The main one is SPI flash so we may as well convert that also. Since the boards I test with have cros_ec I have also included that, for SPI only. The technique used is make use of driver model's supported data structures to hold information currently kept by each subsystem in a private data structure. Since 'struct spi_slave' relates to the slave device on the bus it is stored in the 'parent' data with each child device of the bus. Since 'struct spi_flash' is a standard interface used for each SPI flash driver, it is stored in the SPI FLash uclass's private data for each device. New defines are created to enable driver model for each subsystem. These are: CONFIG_DM_SPI CONFIG_DM_SPI_FLASH CONFIG_DM_CROS_EC This allows us to move some boards and drivers to driver model, while leaving others behind. A 'big bang' conversion of everything to driver model, even at a subsystem level, is never going to work. There is some cost in changing the uclass interface after it is created, so if you have limited time, please spend it reviewing the uclass interfaces in spi.h and spi_flash.h. These need to be supported by each driver, so changing them later may involve changing multiple drivers. To assist with the conversion of other SPI drivers, a README file is added to walk through the process. So far, sandbox, exynos and tegra drivers are converted over. As always, driver model patches are available at u-boot-dm.git branch 'working'. There is a branch for just this series called 'spi-working'. Changes in v3: - Add a cs_info() method to the driver model SPI API - Add a debug() in the probe method - Add a few more debug() statements - Add a function comment for sandbox_spi_get_emul() - Add a missing tab character - Add a uclass for a generic SPI device (for use with the 'sspi' command) - Add implementation/comment for the cs_info() method - Add missing comments to spi.h - Add new functions to iterate through device children - Add new patch to add a clarifying comment on struct udevice's seq member - Add new patch to add aliases for spi on tegra30 boards - Add new patch to allow parents to pass data to children during probe - Add new patch to convert Tegra SPI to driver model - Add spi.h header to 3 sh boards - Correct typo where 'slave' should say 'bus' - Expand SPI tests to cover compatibility functions - Fix two comment typos - Make sure the old device is both removed and unbound in 'sf probe' - Minor renames for clarity - Put the cs member back into spi_slave - Rebase to master - Remove the child_pre_probe() method which is no longer needed - Update for the new cs_info() method - Use a generic SPI device for the 'sspi command' - Use an explicit chip select value instead of reusing device sequence number - Word-wrap the first paragraph of the binding Changes in v2: - Add additional debug() statements - Add missing comments for struct spi_slave - Add spi.h header to dfu_sf.c - Adjust binding to avoid Linux-specific mentions - Adjust xfer() method for new API - Correct sandbox's xfer() method signature - Create a 'spi.bin' file for the SPI tests - Fix a typo in the commit message - Fix code nits from Daniel Schwierzeck - Fix comment on 'slave' parameter to match the parameter name - Fix typos reported by Jagannadha Sutradharudu Teki - Update for changes to exynos driver - Use 'bus' instead of 'dev' to distinguish bus from slave - Use 'bus' instead of 'dev' to make the API clearer Simon Glass (29): sandbox: dts: Add a SPI device and cros_ec device Reviewed-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com dm: core: Add functions for iterating through device children dm: core: Allow parents to pass data to children during probe dm: core: Add a clarifying comment on struct udevice's seq member Acked-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com dm: spi: Add a uclass for SPI Discussed some follow-up comments which will address in future add-ons dm: sandbox: Add a SPI emulation uclass dm: Remove spi_init() from board_r.c when using driver model dm: Add spi.h header to a few files dm: spi: Adjust cmd_spi to work with driver model dm: sandbox: spi: Move to driver model dm: spi: Rename soft_spi.c to soft_spi_legacy.c dm: spi: Remove SPI_INIT feature dm: spi: Add soft_spi implementation dm: exynos: Convert SPI to driver model dm: spi: Add documentation on how to convert over SPI drivers exynos: universal_c210: Move to driver model soft_spi sf: Tidy up public and
Re: [U-Boot] [PATCH v3 05/29] dm: spi: Add a uclass for SPI
Hi Jagan, On 11 October 2014 12:06, Jagan Teki jagannadh.t...@gmail.com wrote: Hi Simon, On 11 October 2014 23:13, Simon Glass s...@chromium.org wrote: Hi Jagan, On 11 October 2014 11:33, Jagan Teki jagannadh.t...@gmail.com wrote: Hi Simon, On 11 October 2014 04:56, Simon Glass s...@chromium.org wrote: Hi Jagan, On 10 October 2014 12:37, Jagan Teki jagannadh.t...@gmail.com wrote: Hi Simon, On 10 October 2014 23:35, Simon Glass s...@chromium.org wrote: Hi Jagan, On 10 October 2014 11:31, Jagan Teki jagannadh.t...@gmail.com wrote: Hi Simon, Can you please see my comments below, I'm relating more about cs and bus valid scenario which is available on current drivers wrt dm-spi. On 30 September 2014 01:05, Simon Glass s...@chromium.org wrote: Add a uclass which provides access to SPI buses and includes operations required by SPI. For a time driver model will need to co-exist with the legacy SPI interface so some parts of the header file are changed depending on which is in use. The exports are adjusted also since some functions are not available with driver model. Boards must define CONFIG_DM_SPI to use driver model for SPI. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: - Add a cs_info() method to the driver model SPI API I think this gives the enough info regarding cs on particular controller what about the bus usage - which is also specific to controller it self, right? Say - spi controller on a particular soc, have spi0, spi1 means two buses and 4 cs lines, cs0-cs3. How is this works in that case? And also I saw tegra20_sflash.c validates only cs int tegra20_sflash_cs_info(struct udevice *bus, unsigned int cs, struct spi_cs_info *info) What about bus number check this particular tegra spi controller is concern. The bus device is passed in as a pointer. The bus number gets looked up to find the device for that bus number. See spi_get_bus_and_cs() for that. This is good because drivers no longer need to validate the bus number. Agreed, but for controlling sf probe bus:cs options bus number should get from the respective driver. I wonder if the issue here is a difference of understanding about bus and chip select. In my mind, bus is just a device. We use the bus number to specify which device we mean, but it is just a a convenience. If there were some other way of finding the device we would use it (as we do with device tree, for example). Yes, I do believe that by mentioning bus spi0, spi1 on the devicetree so the respective bus get's bind'ed till that fine. But as we use runtime probe using sf probe bus:cs where I would mention # sf probe 2:0 selecting spi2 which is of third bus on the same controller driver will that spi_cs_is_valid() will show spi2 is invalid for this particular driver? Run-time binding of SPI buses is supported by driver model (just call device_bind()) but not by the sf probe command. We should know what SPI buses exist through device tree or platform data. So no, the that method is intended to validate a chip select, not a bus. Similarly, chip select is just a device. We look at the bus device, find the appropriate chip select number, and end up with a child device which is referred to by that chip select. Just like validating supported cs, through cs_info I assume the same works for bus as well as this is a pure driver specific theory. Not at present. In fact I feel that both bus and cs should be known in advance, but to keep compatibility (and since there is no platform data available for chip selects) I have added the auto-bind used by the 'sf probe' and 'sspi' commands. I have a suggestion, like in spi_find_bus_and_cs() or spi_get_bus_and_cs() we have a function calls for uclass_get_device_by_seq() and spi_find_bus_and_cs() along with that ops-cs_info(bus, cs, info) by adding bus number check for the driver. So-that there is no requirement to call spi_cs_is_valid from any other location as bus and cs validates through commands itself. At present spi_cs_info() calls spi_find_chip_select(). I think I see what you are getting at - you don't want a device to be created unless cs_info() allows it, right? I will take a look. Yes ie my point, along with that instead of a separate caller for spi_cs_info() why can't we call in the probe time, either from command or at the time of bus_cs binding. Once the bus_cs binding done, and validate the mentioned bus and cs from command or devicetree and return. Does this make sense, please comment? I'm starting to feel that (beyond the idea of using cs_info() more) what you are referring to here is best handled in follow-up discussion and patches once this initial support is merged. There seem to be several questions that are hard to answer until we actually come to implementation: - qspi (could be implemented in sandbox, I don't have a qspi board at present) -
Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
On Saturday, October 11, 2014 at 03:44:06 AM, Fabio Estevam wrote: On Fri, Oct 10, 2014 at 10:14 PM, Marek Vasut ma...@denx.de wrote: +/* PCI express */ +#undef CONFIG_CMD_PCI /* Disable to prevent Linux from hanging on MX6 */ This has been fixed recently by this commit: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/dri vers/pci/host/pci-imx6.c?id=3e3e406e3807235906ee0b7c697664ea6dfd88de Are you positive it is possible to completely fix the PCI on MX6 ? What is the latest official statement from FSL on the PCI in MX6 please? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-socfpga/topic/arm/socfpga-20141010
On Saturday, October 11, 2014 at 01:36:53 AM, Albert ARIBAUD wrote: Hi Marek, Hi Albert, On Sat, 11 Oct 2014 01:11:46 +0200, Marek Vasut ma...@denx.de wrote: The following changes since commit db67801bf92f7fae6131dbc0d387131698fb9490: Merge branch 'master' of git://git.denx.de/u-boot-nand-flash (2014-10-10 09:45:16 -0400) are available in the git repository at: git://git.denx.de/u-boot-socfpga.git topic/arm/socfpga-20141010 In the U-Boot process, PRs are done from a master branch to a master branch. There are exceptions of course, for instance when a repo collects patches for more than one architecture, as does u-boot-sh; it has a master branch for its SH stuff, and a 'rmobile' branch for its ARM stuff. But here, the branch is topical. This is very unusual and only happened, AFAIR, in very few cases of big changes across all arches, where by agreement the patch series was directly maintained as a branch. Will u-boot-socfpga keep on using this branch system, or will it in the future converge toward the U-Boot master+next branch system? Yes, the next MW will be taking the standard course through master+next combo. 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 2/2] kconfig: add CONFIG_SUPPORT_TPL
Hi Masahiro, On Sun, 12 Oct 2014 02:04:36 +0900, Masahiro YAMADA yamad...@jp.panasonic.com wrote: Hi Albert, 2014-10-11 17:56 GMT+09:00 Albert ARIBAUD albert.u.b...@aribaud.net: Hi Masahiro, On Thu, 25 Sep 2014 18:19:07 +0900, Masahiro Yamada yamad...@jp.panasonic.com wrote: CONFIG_TPL should not be enabled for boards that do not have TPL. CONFIG_SUPPORT_TPL introduced by this commit should be selected by boards with TPL support and CONFIG_TPL should depend on it. Actually, I see no CONFIG_SUPPORT_TPL in the patch, only HAVE_TPL_SUPPORT. The commit message should match the patch content on this point, should it not? I am guessing you are seeing the old patch (v1) that has been already Superseded. The newest of this patch is v3: http://patchwork.ozlabs.org/patch/397543/ My bad -- I'd missed this indeed. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
On Sat, Oct 11, 2014 at 3:43 PM, Marek Vasut ma...@denx.de wrote: Are you positive it is possible to completely fix the PCI on MX6 ? What is the I don't see the hang with that patch applied. Do you? Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
On Sat, Oct 11, 2014 at 11:21 AM, Sean Cross x...@kosagi.com wrote: Ok, understood. Just curious: which Ethernet PHY is used on the novena board? It's the same Micrel PHY used on the Sabrelite, the KSZ9021. nitrogen/sabrelite holds Ethernet PHY reset low for 10ms, which is in accordance with ksz9021 datasheet. Shouldn't we wait 10ms here as well? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: mxs: Define bootscript env variable on m28evk
The patch below failed to define the variable, so define it to make it consistent with M53EVK. commit a428ac914b2b6db851c1feac98622f2d9844db45 Author: Lothar Rubusch lot...@denx.de Date: Thu Jun 26 11:01:29 2014 +0200 ARM: m28evk: Update default environment Signed-off-by: Marek Vasut ma...@denx.de Cc: Tom Rini tr...@ti.com Cc: Wolfgang Denk w...@denx.de Cc: Stefano Babic sba...@denx.de --- include/configs/m28evk.h | 1 + 1 file changed, 1 insertion(+) NOTE: I'd like to have this in 2014.10 , since it fixes incorrect behavior of the board when this variable is not defined. diff --git a/include/configs/m28evk.h b/include/configs/m28evk.h index efe770b..5c20991 100644 --- a/include/configs/m28evk.h +++ b/include/configs/m28evk.h @@ -171,6 +171,7 @@ #define CONFIG_EXTRA_ENV_SETTINGS \ consdev=ttyAMA0\0 \ baudrate=115200\0 \ + bootscript=boot.scr\0 \ bootdev=/dev/mmcblk0p2\0 \ rootdev=/dev/mmcblk0p3\0 \ netdev=eth0\0 \ -- 2.0.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-atmel/master - u-boot-arm/master
Hi Andreas, On Fri, 10 Oct 2014 22:00:31 +0200, Andreas Bießmann andreas.de...@googlemail.com wrote: Dear Albert Aribaud, please pull these changes into u-boot-arm/master. They are two generic board conversions which are trivial and a fix for gigabit ethernet on sama5d3xek. The following changes since commit ebf8644a113a36b163c2e06fe1e081c73f563c3a: Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master' (2014-10-10 08:56:01 +0200) are available in the git repository at: git://git.denx.de/u-boot-atmel.git master for you to fetch changes up to d0b3723034aa865b8618428739efe1d98b1a2e2b: arm, at91: add generic board support for the taurus and corvus board (2014-10-10 21:51:19 +0200) Andreas Bießmann (2): macb: simplify gmac initialisation sama5d3xek: run PHY's config Bo Shen (1): ARM: atmel: switch at91sam9263ek to generic board Heiko Schocher (1): arm, at91: add generic board support for the taurus and corvus board board/atmel/sama5d3xek/sama5d3xek.c | 29 - drivers/net/macb.c | 25 - include/configs/at91sam9263ek.h |2 ++ include/configs/corvus.h|2 ++ include/configs/taurus.h|2 ++ 5 files changed, 34 insertions(+), 26 deletions(-) Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] ARM: mxs: tools: Add support for boot progress display flag
On Saturday, October 11, 2014 at 11:43:30 PM, Alexey Ignatov wrote: mkimage -T mxs now support new flag in config file: DISPLAYPROGRESS - makes boot process print HTLLC characters for each BootROM instruction. Signed-off-by: Alexey Ignatov lexsz...@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] [PATCH 3/3] ARM: sunxi: Fix reset command on sun6i/sun8i
On Sat, Oct 11, 2014 at 11:33 PM, Ian Campbell i...@hellion.org.uk wrote:
On Sat, 2014-10-04 at 20:37 +0800, Chen-Yu Tsai wrote:
+#else /* CONFIG_SUN6I || CONFIG_SUN8I || .. */
+ static const struct sunxi_wdog *wdog =
+ ((struct sunxi_timer_reg *)SUNXI_TIMER_BASE)-wdog;
+
+ /* Set the watchdog for its shortest interval (.5s) and wait */
+ writel(WDT_CFG_RESET, wdog-cfg);
+ writel(WDT_MODE_EN, wdog-mode);
+ writel(WDT_CTRL_KEY | WDT_CTRL_RESTART, wdog-ctl);
That's annoyingly close to the 4/5/7i version, but not quite close
enough to allow any meaningful sharing :-/
I suppose it is possible to share using clrsetbits...
+ while (1) {
+ /* sun5i sometimes gets stuck without this */
Is this not therefore unnecessary on 6i/8i?
The kernel restart driver uses this.
But Allwinner's original code does not.
ChenYu
+ writel(WDT_MODE_EN, wdog-mode);
+ }
+#endif
}
/* do some early init */
diff --git a/arch/arm/include/asm/arch-sunxi/watchdog.h
b/arch/arm/include/asm/arch-sunxi/watchdog.h
index 5b755e3..ccc8fa3 100644
--- a/arch/arm/include/asm/arch-sunxi/watchdog.h
+++ b/arch/arm/include/asm/arch-sunxi/watchdog.h
@@ -12,6 +12,9 @@
#define WDT_CTRL_RESTART (0x1 0)
#define WDT_CTRL_KEY (0x0a57 1)
+
+#if defined(CONFIG_SUN4I) || defined(CONFIG_SUN5I) || defined(CONFIG_SUN7I)
+
#define WDT_MODE_EN (0x1 0)
#define WDT_MODE_RESET_EN(0x1 1)
@@ -21,4 +24,21 @@ struct sunxi_wdog {
u32 res[2];
};
+#else
+
+#define WDT_CFG_RESET(0x1)
+#define WDT_MODE_EN (0x1)
+
+struct sunxi_wdog {
+ u32 irq_en; /* 0x00 */
+ u32 irq_sta;/* 0x04 */
+ u32 res1[2];
+ u32 ctl;/* 0x10 */
+ u32 cfg;/* 0x14 */
+ u32 mode; /* 0x18 */
+ u32 res2;
+};
+
+#endif
+
#endif /* _SUNXI_WATCHDOG_H_ */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/9] ARM: sunxi: Add basic A23 support
On Sat, Oct 11, 2014 at 11:58 PM, Ian Campbell i...@hellion.org.uk wrote:
On Tue, 2014-10-07 at 15:11 +0800, Chen-Yu Tsai wrote:
The basic blocks of the A23 are similar to the A31 (sun6i). Re-use
sun6i code for initial clock, gpio, and uart setup.
Do I take it that sun8i is also in the same position wrt DRAM bring up
code not existing yet and there therefore being no SPL yet?
That is correct.
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
arch/arm/Kconfig| 3 +++
arch/arm/cpu/armv7/sunxi/Makefile | 2 ++
arch/arm/cpu/armv7/sunxi/board.c| 3 ++-
arch/arm/cpu/armv7/sunxi/cpu_info.c | 2 ++
arch/arm/include/asm/arch-sunxi/clock.h | 2 +-
board/sunxi/Kconfig | 9 -
include/configs/sun8i.h | 23 +++
7 files changed, 41 insertions(+), 3 deletions(-)
create mode 100644 include/configs/sun8i.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e3e7e78..cb691b2 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -450,6 +450,9 @@ config TARGET_SUN6I
config TARGET_SUN7I
bool Support sun7i
+config TARGET_SUN8I
+ bool Support sun8i
+
config TARGET_SNOWBALL
bool Support snowball
diff --git a/arch/arm/cpu/armv7/sunxi/Makefile
b/arch/arm/cpu/armv7/sunxi/Makefile
index 2a42dca..24f1dae 100644
--- a/arch/arm/cpu/armv7/sunxi/Makefile
+++ b/arch/arm/cpu/armv7/sunxi/Makefile
@@ -12,10 +12,12 @@ obj-y += board.o
obj-y+= clock.o
obj-y+= pinmux.o
obj-$(CONFIG_SUN6I) += prcm.o
+obj-$(CONFIG_SUN8I) += prcm.o
obj-$(CONFIG_SUN4I) += clock_sun4i.o
obj-$(CONFIG_SUN5I) += clock_sun4i.o
obj-$(CONFIG_SUN6I) += clock_sun6i.o
obj-$(CONFIG_SUN7I) += clock_sun4i.o
+obj-$(CONFIG_SUN8I) += clock_sun6i.o
ifndef CONFIG_SPL_BUILD
obj-y+= cpu_info.o
diff --git a/arch/arm/cpu/armv7/sunxi/board.c
b/arch/arm/cpu/armv7/sunxi/board.c
index 29d45b6..61c1ba9 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -100,7 +100,8 @@ void reset_cpu(ulong addr)
/* do some early init */
void s_init(void)
{
-#if !defined CONFIG_SPL_BUILD (defined CONFIG_SUN7I || defined
CONFIG_SUN6I)
+#if !defined CONFIG_SPL_BUILD (defined CONFIG_SUN7I || \
+ defined CONFIG_SUN6I || defined CONFIG_SUN8I)
At some point we should refactor this to use a common Kconfig thing
(SUNXI_SMP etc) which the relevant targets select.
I agree. We can do this as we move further to Kconfig.
ChenYu
/* Enable SMP mode for CPU0, by setting bit 6 of Auxiliary Ctl reg */
asm volatile(
mrc p15, 0, r0, c1, c0, 1\n
diff --git a/arch/arm/cpu/armv7/sunxi/cpu_info.c
b/arch/arm/cpu/armv7/sunxi/cpu_info.c
index 40c4e13..4f2a09c 100644
--- a/arch/arm/cpu/armv7/sunxi/cpu_info.c
+++ b/arch/arm/cpu/armv7/sunxi/cpu_info.c
@@ -27,6 +27,8 @@ int print_cpuinfo(void)
puts(CPU: Allwinner A31 (SUN6I)\n);
#elif defined CONFIG_SUN7I
puts(CPU: Allwinner A20 (SUN7I)\n);
+#elif defined CONFIG_SUN8I
+ puts(CPU: Allwinner A23 (SUN8I)\n);
#else
#warning Please update cpu_info.c with correct CPU information
puts(CPU: SUNXI Family\n);
diff --git a/arch/arm/include/asm/arch-sunxi/clock.h
b/arch/arm/include/asm/arch-sunxi/clock.h
index 8f5d860..012c2af 100644
--- a/arch/arm/include/asm/arch-sunxi/clock.h
+++ b/arch/arm/include/asm/arch-sunxi/clock.h
@@ -15,7 +15,7 @@
#define CLK_GATE_CLOSE 0x0
/* clock control module regs definition */
-#ifdef CONFIG_SUN6I
+#if defined(CONFIG_SUN6I) || defined(CONFIG_SUN8I)
#include asm/arch/clock_sun6i.h
#else
#include asm/arch/clock_sun4i.h
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 05defac..16f6db4 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -27,7 +27,14 @@ config SYS_CONFIG_NAME
endif
-if TARGET_SUN4I || TARGET_SUN5I || TARGET_SUN6I || TARGET_SUN7I
+if TARGET_SUN8I
+
+config SYS_CONFIG_NAME
+ default sun8i
+
+endif
+
+if TARGET_SUN4I || TARGET_SUN5I || TARGET_SUN6I || TARGET_SUN7I ||
TARGET_SUN8I
config SYS_CPU
default armv7
diff --git a/include/configs/sun8i.h b/include/configs/sun8i.h
new file mode 100644
index 000..1c1a7cd
--- /dev/null
+++ b/include/configs/sun8i.h
@@ -0,0 +1,23 @@
+/*
+ * (C) Copyright 2014 Chen-Yu Tsai w...@csie.org
+ *
+ * Configuration settings for the Allwinner A23 (sun8i) CPU
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+/*
+ * A23 specific configuration
+ */
+#define CONFIG_SUN8I /* sun8i SoC generation */
+#define CONFIG_SYS_PROMPTsun8i#
+
+/*
+ * Include common sunxi configuration where most the settings are
+ */
+#include configs/sunxi-common.h
+
+#endif /* __CONFIG_H */
___
U-Boot mailing list
U-Boot@lists.denx.de
