* [U-Boot] [PATCH v2 00/11] S3C24XX: Add support to MINI2416 board
@ 2012-09-14 17:28 José Miguel Gonçalves
2012-09-14 17:28 ` [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS José Miguel Gonçalves
` (10 more replies)
0 siblings, 11 replies; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-14 17:28 UTC (permalink / raw)
To: u-boot
Support for the MINI2416 board based on a Samsung's S3C2416 SoC with
64MB DDR2 SDRAM, 256MB NAND Flash, a LAN9220 Ethernet Controller and a
WM8731 Audio CODEC.
Changes for v2:
- Coding style cleanup
- Removed new serial and rtc drivers
- Use of in-tree serial and rtc drivers
Jos? Miguel Gon?alves (11):
ARM: fix relocation on ARM926EJS
S3C24XX: Add core support for Samsung's S3C24XX SoCs
serial: Add support to 4 ports in serial_s3c24x0
serial: Use a more precise baud rate generation for serial_s3c24x0
serial: Remove unnecessary delay in serial_s3c24x0
rtc: Improve rtc_get() on s3c24x0_rtc
rtc: Fix rtc_reset() on s3c24x0_rtc
rtc: Don't allow setting unsuported years on s3c24x0_rtc
S3C24XX: Add NAND Flash driver
Add u-boot-ubl.bin target to the Makefile
S3C24XX: Add support to MINI2416 board
MAINTAINERS | 4 +
Makefile | 7 +-
arch/arm/cpu/arm926ejs/s3c24xx/Makefile | 52 ++
arch/arm/cpu/arm926ejs/s3c24xx/cpu.c | 56 +++
arch/arm/cpu/arm926ejs/s3c24xx/cpu_info.c | 57 +++
arch/arm/cpu/arm926ejs/s3c24xx/s3c2412_speed.c | 114 +++++
arch/arm/cpu/arm926ejs/s3c24xx/s3c2416_speed.c | 116 +++++
arch/arm/cpu/arm926ejs/s3c24xx/timer.c | 152 ++++++
arch/arm/cpu/arm926ejs/start.S | 4 +-
arch/arm/include/asm/arch-s3c24xx/s3c2412.h | 120 +++++
arch/arm/include/asm/arch-s3c24xx/s3c2416.h | 175 +++++++
arch/arm/include/asm/arch-s3c24xx/s3c24x0_cpu.h | 41 ++
arch/arm/include/asm/arch-s3c24xx/s3c24xx.h | 598 +++++++++++++++++++++++
arch/arm/include/asm/arch-s3c24xx/s3c24xx_cpu.h | 30 ++
board/boardcon/mini2416/Makefile | 47 ++
board/boardcon/mini2416/config.mk | 4 +
board/boardcon/mini2416/mini2416.c | 98 ++++
board/boardcon/mini2416/mini2416_spl.c | 200 ++++++++
board/boardcon/mini2416/u-boot-spl.lds | 63 +++
boards.cfg | 1 +
drivers/mtd/nand/Makefile | 1 +
drivers/mtd/nand/s3c24xx_nand.c | 245 ++++++++++
drivers/rtc/s3c24x0_rtc.c | 30 +-
drivers/serial/serial_s3c24x0.c | 52 +-
include/common.h | 1 +
include/configs/VCMA9.h | 2 +-
include/configs/mini2416.h | 200 ++++++++
include/configs/smdk2410.h | 2 +-
28 files changed, 2446 insertions(+), 26 deletions(-)
create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/Makefile
create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/cpu.c
create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/cpu_info.c
create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/s3c2412_speed.c
create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/s3c2416_speed.c
create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/timer.c
create mode 100644 arch/arm/include/asm/arch-s3c24xx/s3c2412.h
create mode 100644 arch/arm/include/asm/arch-s3c24xx/s3c2416.h
create mode 100644 arch/arm/include/asm/arch-s3c24xx/s3c24x0_cpu.h
create mode 100644 arch/arm/include/asm/arch-s3c24xx/s3c24xx.h
create mode 100644 arch/arm/include/asm/arch-s3c24xx/s3c24xx_cpu.h
create mode 100644 board/boardcon/mini2416/Makefile
create mode 100644 board/boardcon/mini2416/config.mk
create mode 100644 board/boardcon/mini2416/mini2416.c
create mode 100644 board/boardcon/mini2416/mini2416_spl.c
create mode 100644 board/boardcon/mini2416/u-boot-spl.lds
create mode 100644 drivers/mtd/nand/s3c24xx_nand.c
create mode 100644 include/configs/mini2416.h
--
1.7.9.5
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
2012-09-14 17:28 [U-Boot] [PATCH v2 00/11] S3C24XX: Add support to MINI2416 board José Miguel Gonçalves
@ 2012-09-14 17:28 ` José Miguel Gonçalves
2012-09-15 18:03 ` Marek Vasut
2012-10-04 14:24 ` Albert ARIBAUD
2012-09-14 17:28 ` [U-Boot] [PATCH v2 02/11] S3C24XX: Add core support for Samsung's S3C24XX SoCs José Miguel Gonçalves
` (9 subsequent siblings)
10 siblings, 2 replies; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-14 17:28 UTC (permalink / raw)
To: u-boot
Jumping to board_init_r is not performed due to a bug on address computation.
Relocation offsets are not needed when building SPL.
Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
---
Changes for v2:
- None
---
arch/arm/cpu/arm926ejs/start.S | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S
index 6f05f1a..2da5342 100644
--- a/arch/arm/cpu/arm926ejs/start.S
+++ b/arch/arm/cpu/arm926ejs/start.S
@@ -325,7 +325,7 @@ _nand_boot_ofs:
.word nand_boot
#else
ldr r0, _board_init_r_ofs
- ldr r1, _TEXT_BASE
+ adr r1, _start
add lr, r0, r1
add lr, lr, r9
/* setup parameters for board_init_r */
@@ -338,12 +338,14 @@ _board_init_r_ofs:
.word board_init_r - _start
#endif
+#ifndef CONFIG_SPL_BUILD
_rel_dyn_start_ofs:
.word __rel_dyn_start - _start
_rel_dyn_end_ofs:
.word __rel_dyn_end - _start
_dynsym_start_ofs:
.word __dynsym_start - _start
+#endif
/*
*************************************************************************
--
1.7.9.5
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 02/11] S3C24XX: Add core support for Samsung's S3C24XX SoCs
2012-09-14 17:28 [U-Boot] [PATCH v2 00/11] S3C24XX: Add support to MINI2416 board José Miguel Gonçalves
2012-09-14 17:28 ` [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS José Miguel Gonçalves
@ 2012-09-14 17:28 ` José Miguel Gonçalves
2012-09-14 18:03 ` Marek Vasut
2012-09-14 18:39 ` Tom Rini
2012-09-14 17:28 ` [U-Boot] [PATCH v2 03/11] serial: Add support to 4 ports in serial_s3c24x0 José Miguel Gonçalves
` (8 subsequent siblings)
10 siblings, 2 replies; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-14 17:28 UTC (permalink / raw)
To: u-boot
This patch adds the support for Samsung's S3C24XX SoCs that have an ARM926EJS core.
Currently it supports S3C2412, S3C2413, S3C2416 and S3C2450.
Tested on an S3C2416 platform.
Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
---
Changes for v2:
- Added register bit macros to avoid magic numbers
- Removed volatile attribute from register structs
- Added s3c24x0_cpu.h to be able to use drivers from s3c24x0 family
- Fixed EPLL computation in get_PLLCLK for S3C2416
- Added display of UCLK in print_cpu_info
- Use of clrsetbits_le32()
---
arch/arm/cpu/arm926ejs/s3c24xx/Makefile | 52 ++
arch/arm/cpu/arm926ejs/s3c24xx/cpu.c | 56 +++
arch/arm/cpu/arm926ejs/s3c24xx/cpu_info.c | 57 +++
arch/arm/cpu/arm926ejs/s3c24xx/s3c2412_speed.c | 114 +++++
arch/arm/cpu/arm926ejs/s3c24xx/s3c2416_speed.c | 116 +++++
arch/arm/cpu/arm926ejs/s3c24xx/timer.c | 152 ++++++
arch/arm/include/asm/arch-s3c24xx/s3c2412.h | 120 +++++
arch/arm/include/asm/arch-s3c24xx/s3c2416.h | 175 +++++++
arch/arm/include/asm/arch-s3c24xx/s3c24x0_cpu.h | 41 ++
arch/arm/include/asm/arch-s3c24xx/s3c24xx.h | 598 +++++++++++++++++++++++
arch/arm/include/asm/arch-s3c24xx/s3c24xx_cpu.h | 30 ++
include/common.h | 1 +
12 files changed, 1512 insertions(+)
create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/Makefile
create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/cpu.c
create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/cpu_info.c
create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/s3c2412_speed.c
create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/s3c2416_speed.c
create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/timer.c
create mode 100644 arch/arm/include/asm/arch-s3c24xx/s3c2412.h
create mode 100644 arch/arm/include/asm/arch-s3c24xx/s3c2416.h
create mode 100644 arch/arm/include/asm/arch-s3c24xx/s3c24x0_cpu.h
create mode 100644 arch/arm/include/asm/arch-s3c24xx/s3c24xx.h
create mode 100644 arch/arm/include/asm/arch-s3c24xx/s3c24xx_cpu.h
diff --git a/arch/arm/cpu/arm926ejs/s3c24xx/Makefile b/arch/arm/cpu/arm926ejs/s3c24xx/Makefile
new file mode 100644
index 0000000..62b8378
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/s3c24xx/Makefile
@@ -0,0 +1,52 @@
+#
+# (C) Copyright 2012 INOV - INESC Inovacao
+# Jose Goncalves <jose.goncalves@inov.pt>
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB = $(obj)lib$(SOC).o
+
+COBJS-$(CONFIG_DISPLAY_CPUINFO) += cpu_info.o
+ifeq ($(filter y,$(CONFIG_S3C2412) $(CONFIG_S3C2413)),y)
+COBJS-y += s3c2412_speed.o
+else
+COBJS-y += s3c2416_speed.o
+endif
+COBJS-y += cpu.o
+COBJS-y += timer.o
+
+SRCS := $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS-y))
+
+all: $(obj).depend $(LIB)
+
+$(LIB): $(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+#########################################################################
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#########################################################################
diff --git a/arch/arm/cpu/arm926ejs/s3c24xx/cpu.c b/arch/arm/cpu/arm926ejs/s3c24xx/cpu.c
new file mode 100644
index 0000000..e16ae73
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/s3c24xx/cpu.c
@@ -0,0 +1,56 @@
+/*
+ * (C) Copyright 2012 INOV - INESC Inovacao
+ * Jose Goncalves <jose.goncalves@inov.pt>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <common.h>
+#include <asm/io.h>
+#include <asm/arch/s3c24xx_cpu.h>
+
+void enable_caches(void)
+{
+#ifndef CONFIG_SYS_ICACHE_OFF
+ icache_enable();
+#endif
+#ifndef CONFIG_SYS_DCACHE_OFF
+ dcache_enable();
+#endif
+}
+
+/*
+ * Reset the cpu by setting up the watchdog timer and let him time out.
+ */
+void reset_cpu(ulong addr)
+{
+ struct s3c24xx_watchdog *const watchdog = s3c24xx_get_base_watchdog();
+
+ /* Disable watchdog */
+ writel(0x0000, &watchdog->wtcon);
+
+ /* Initialize watchdog timer count register */
+ writel(0x0001, &watchdog->wtcnt);
+
+ /* Enable watchdog timer; assert reset at timer timeout */
+ writel(WTCON_RSTEN | WTCON_ENABLE, &watchdog->wtcon);
+
+ while (1)
+ /* loop forever and wait for reset to happen */;
+}
diff --git a/arch/arm/cpu/arm926ejs/s3c24xx/cpu_info.c b/arch/arm/cpu/arm926ejs/s3c24xx/cpu_info.c
new file mode 100644
index 0000000..d2a8b95
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/s3c24xx/cpu_info.c
@@ -0,0 +1,57 @@
+/*
+ * (C) Copyright 2010
+ * David Mueller <d.mueller@elsoft.ch>
+ *
+ * (C) Copyright 2012 INOV - INESC Inovacao
+ * Jose Goncalves <jose.goncalves@inov.pt>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <common.h>
+#include <asm/io.h>
+#include <asm/arch/s3c24xx_cpu.h>
+
+typedef ulong(*getfreq) (void);
+
+static const getfreq freq_f[] = {
+ get_FCLK,
+ get_HCLK,
+ get_PCLK,
+ get_UCLK,
+};
+
+static const char freq_c[] = { 'F', 'H', 'P', 'U' };
+
+int print_cpuinfo(void)
+{
+ int i;
+ char buf[32];
+ ulong cpuid;
+ struct s3c24xx_gpio *const gpio = s3c24xx_get_base_gpio();
+
+ cpuid = readl(&gpio->gstatus[1]);
+ printf("CPU: %8s (id %08lX) @ %s MHz\n", s3c24xx_get_cpu_name(),
+ cpuid, strmhz(buf, get_ARMCLK()));
+ for (i = 0; i < ARRAY_SIZE(freq_f); i++)
+ printf("%cCLK: %8s MHz\n", freq_c[i],
+ strmhz(buf, freq_f[i] ()));
+
+ return 0;
+}
diff --git a/arch/arm/cpu/arm926ejs/s3c24xx/s3c2412_speed.c b/arch/arm/cpu/arm926ejs/s3c24xx/s3c2412_speed.c
new file mode 100644
index 0000000..eeadc3c
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/s3c24xx/s3c2412_speed.c
@@ -0,0 +1,114 @@
+/*
+ * (C) Copyright 2012 INOV - INESC Inovacao
+ * Jose Goncalves <jose.goncalves@inov.pt>
+ *
+ * Based on U-Boot 1.3.4 from Samsung.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <common.h>
+#include <asm/io.h>
+#include <asm/arch/s3c2412.h>
+
+#define MPLL 0
+#define UPLL 1
+
+/* ------------------------------------------------------------------------- */
+/*
+ * CONFIG_SYS_CLK_FREQ should be defined as the input frequency of the PLL.
+ *
+ * get_FCLK(), get_HCLK(), get_PCLK() and get_UCLK() return the clock of
+ * the specified bus in HZ.
+ */
+/* ------------------------------------------------------------------------- */
+
+static ulong get_PLLCLK(int pllreg)
+{
+ struct s3c2412_sysctl *const sysctl = s3c2412_get_base_sysctl();
+ u32 pllcon, f;
+ u16 mdiv, pdiv, sdiv;
+
+ if (pllreg == MPLL)
+ pllcon = readl(&sysctl->mpllcon);
+ else if (pllreg == UPLL)
+ pllcon = readl(&sysctl->upllcon);
+ else
+ hang();
+
+ mdiv = (pllcon >> 12) & 0xFF;
+ pdiv = (pllcon >> 4) & 0x3F;
+ sdiv = pllcon & 0x3;
+
+ f = (mdiv + 8) * (CONFIG_SYS_CLK_FREQ / ((pdiv + 2) << sdiv));
+ if (pllreg == MPLL)
+ f <<= 1;
+
+ return f;
+}
+
+/* return FCLK frequency */
+ulong get_FCLK(void)
+{
+ return get_PLLCLK(MPLL);
+}
+
+/* return HCLK frequency */
+ulong get_HCLK(void)
+{
+ struct s3c2412_sysctl *const sysctl = s3c2412_get_base_sysctl();
+ u32 clkdivn;
+ u16 hclk_div, arm_div;
+
+ clkdivn = readl(&sysctl->clkdivn);
+ hclk_div = (clkdivn & 0x3) + 1;
+ arm_div = ((clkdivn >> 3) & 0x1) + 1;
+
+ return get_FCLK() / (hclk_div * arm_div);
+}
+
+/* return PCLK frequency */
+ulong get_PCLK(void)
+{
+ struct s3c2412_sysctl *const sysctl = s3c2412_get_base_sysctl();
+ u32 clkdivn;
+
+ clkdivn = readl(&sysctl->clkdivn);
+
+ return (clkdivn & 0x4) ? get_HCLK() / 2 : get_HCLK();
+}
+
+/* return UCLK frequency */
+ulong get_UCLK(void)
+{
+ return get_PLLCLK(UPLL);
+}
+
+/* return ARMCORE frequency */
+ulong get_ARMCLK(void)
+{
+ struct s3c2412_sysctl *const sysctl = s3c2412_get_base_sysctl();
+ u32 clkdivn;
+
+ clkdivn = readl(&sysctl->clkdivn);
+ if (clkdivn & 0x10)
+ return get_FCLK();
+
+ return (clkdivn & 0x8) ? get_FCLK() / 2 : get_FCLK();
+}
diff --git a/arch/arm/cpu/arm926ejs/s3c24xx/s3c2416_speed.c b/arch/arm/cpu/arm926ejs/s3c24xx/s3c2416_speed.c
new file mode 100644
index 0000000..e8ea0c7
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/s3c24xx/s3c2416_speed.c
@@ -0,0 +1,116 @@
+/*
+ * (C) Copyright 2012 INOV - INESC Inovacao
+ * Jose Goncalves <jose.goncalves@inov.pt>
+ *
+ * Based on U-Boot 1.3.4 from Samsung.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <common.h>
+#include <asm/io.h>
+#include <asm/arch/s3c2416.h>
+
+#define MPLL 0
+#define EPLL 1
+
+/* ------------------------------------------------------------------------- */
+/*
+ * CONFIG_SYS_CLK_FREQ should be defined as the input frequency of the PLL.
+ *
+ * get_FCLK(), get_HCLK(), get_PCLK() and get_UCLK() return the clock of
+ * the specified bus in HZ.
+ */
+/* ------------------------------------------------------------------------- */
+
+static ulong get_PLLCLK(int pllreg)
+{
+ struct s3c2416_sysctl *const sysctl = s3c2416_get_base_sysctl();
+ u32 pllcon;
+ u16 mdiv, pdiv, sdiv;
+
+ if (pllreg == MPLL) {
+ pllcon = readl(&sysctl->mpllcon);
+ mdiv = (pllcon >> 14) & 0x3FF;
+ pdiv = (pllcon >> 5) & 0x3F;
+ } else if (pllreg == EPLL) {
+ pllcon = readl(&sysctl->epllcon);
+ mdiv = (pllcon >> 16) & 0xFF;
+ pdiv = (pllcon >> 8) & 0x3F;
+ } else {
+ hang();
+ }
+
+ sdiv = pllcon & 0x7;
+
+ return mdiv * (CONFIG_SYS_CLK_FREQ / (pdiv << sdiv));
+}
+
+/* return FCLK frequency */
+ulong get_FCLK(void)
+{
+ return get_PLLCLK(MPLL);
+}
+
+/* return HCLK frequency */
+ulong get_HCLK(void)
+{
+ struct s3c2416_sysctl *const sysctl = s3c2416_get_base_sysctl();
+ u32 clkdiv0;
+ u16 hclk_div, pre_div;
+
+ clkdiv0 = readl(&sysctl->clkdiv0);
+ hclk_div = (clkdiv0 & 0x3) + 1;
+ pre_div = ((clkdiv0 >> 4) & 0x3) + 1;
+
+ return get_FCLK() / (hclk_div * pre_div);
+}
+
+/* return PCLK frequency */
+ulong get_PCLK(void)
+{
+ struct s3c2416_sysctl *const sysctl = s3c2416_get_base_sysctl();
+ u32 clkdiv0;
+
+ clkdiv0 = readl(&sysctl->clkdiv0);
+
+ return (clkdiv0 & 0x4) ? get_HCLK() / 2 : get_HCLK();
+}
+
+/* return UCLK frequency */
+ulong get_UCLK(void)
+{
+ return get_PLLCLK(EPLL);
+}
+
+/* return ARMCORE frequency */
+ulong get_ARMCLK(void)
+{
+ struct s3c2416_sysctl *const sysctl = s3c2416_get_base_sysctl();
+ u32 clkdiv0;
+ u16 arm_div;
+
+ clkdiv0 = readl(&sysctl->clkdiv0);
+ if (clkdiv0 & 0x2000)
+ return get_FCLK();
+
+ arm_div = ((clkdiv0 >> 9) & 0x7) + 1;
+
+ return get_FCLK() / arm_div;
+}
diff --git a/arch/arm/cpu/arm926ejs/s3c24xx/timer.c b/arch/arm/cpu/arm926ejs/s3c24xx/timer.c
new file mode 100644
index 0000000..23d3343
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/s3c24xx/timer.c
@@ -0,0 +1,152 @@
+/*
+ * (C) Copyright 2012 INOV - INESC Inovacao
+ * Jose Goncalves <jose.goncalves@inov.pt>
+ *
+ * Based on arch/arm/cpu/armv7/s5p-common/timer.c and U-Boot 1.3.4 from Samsung.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <common.h>
+#include <asm/io.h>
+#include <asm/arch/s3c24xx_cpu.h>
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static ulong get_current_tick(void)
+{
+ struct s3c24xx_timers *const timers = s3c24xx_get_base_timers();
+ ulong now = readl(&timers->tcnto4);
+
+ if (gd->lastinc >= now)
+ gd->tbl += gd->lastinc - now;
+ else
+ gd->tbl += gd->lastinc + gd->tbu - now;
+
+ gd->lastinc = now;
+
+ return gd->tbl;
+}
+
+int timer_init(void)
+{
+ struct s3c24xx_timers *const timers = s3c24xx_get_base_timers();
+
+ /* use PWM Timer 4 because it has no output */
+ if (gd->tbu == 0) {
+ /* set divider value for Timer 4 to 2 */
+ clrsetbits_le32(&timers->tcfg1, TCFG1_MUX4_MASK,
+ TCFG1_MUX4_DIV2);
+ /* set prescaler value for Timer 4 to 15 */
+ clrsetbits_le32(&timers->tcfg0, TCFG0_PRESCALER1_MASK,
+ TCFG0_PRESCALER1(15));
+ /*
+ * Timer Freq(HZ) =
+ * PCLK / (prescaler_value + 1) / (divider_value)
+ */
+ gd->timer_rate_hz = get_PCLK() / (15 + 1) / 2;
+ gd->tbu = gd->timer_rate_hz / CONFIG_SYS_HZ;
+ }
+ /* load value for selected timeout */
+ writel(gd->tbu, &timers->tcntb4);
+ /* auto reload, manual update of timer 4 */
+ clrsetbits_le32(&timers->tcon, TCON_T4START,
+ TCON_T4RELOAD | TCON_T4MANUALUPD);
+ /* auto reload, start timer 4 */
+ clrsetbits_le32(&timers->tcon, TCON_T4MANUALUPD,
+ TCON_T4RELOAD | TCON_T4START);
+ gd->lastinc = 0;
+ gd->tbl = 0;
+
+ return 0;
+}
+
+ulong get_timer(ulong base)
+{
+ return get_timer_masked() - base;
+}
+
+void __udelay(unsigned long usec)
+{
+ ulong tmo, tmp;
+
+ if (usec >= 1000) {
+ /*
+ * if "big" number, spread normalization
+ * to seconds
+ * 1. start to normalize for usec to ticks per sec
+ * 2. find number of "ticks" to wait to achieve target
+ * 3. finish normalize.
+ */
+ tmo = usec / 1000;
+ tmo *= gd->timer_rate_hz;
+ tmo /= 1000;
+ } else {
+ /* else small number, don't kill it prior to HZ multiply */
+ tmo = usec * gd->timer_rate_hz;
+ tmo /= (1000 * 1000);
+ }
+
+ /* get current timestamp */
+ tmp = get_current_tick();
+
+ /* if setting this fordward will roll time stamp */
+ /* reset "advancing" timestamp to 0, set lastinc value */
+ /* else, set advancing stamp wake up time */
+ if ((tmo + tmp + 1) < tmp)
+ reset_timer_masked();
+ else
+ tmo += tmp;
+
+ /* loop till event */
+ while (get_current_tick() < tmo)
+ /* NOP */;
+}
+
+void reset_timer_masked(void)
+{
+ struct s3c24xx_timers *const timers = s3c24xx_get_base_timers();
+
+ /* reset time */
+ gd->lastinc = readl(&timers->tcnto4);
+ gd->tbl = 0;
+}
+
+ulong get_timer_masked(void)
+{
+ return get_current_tick() / gd->tbu;
+}
+
+/*
+ * This function is derived from PowerPC code (read timebase as long long).
+ * On ARM it just returns the timer value.
+ */
+unsigned long long get_ticks(void)
+{
+ return get_timer_masked();
+}
+
+/*
+ * This function is derived from PowerPC code (timebase clock frequency).
+ * On ARM it returns the number of timer ticks per second.
+ */
+ulong get_tbclk(void)
+{
+ return CONFIG_SYS_HZ;
+}
diff --git a/arch/arm/include/asm/arch-s3c24xx/s3c2412.h b/arch/arm/include/asm/arch-s3c24xx/s3c2412.h
new file mode 100644
index 0000000..f5b5b21
--- /dev/null
+++ b/arch/arm/include/asm/arch-s3c24xx/s3c2412.h
@@ -0,0 +1,120 @@
+/*
+ * (C) Copyright 2012 INOV - INESC Inovacao
+ * Jose Goncalves <jose.goncalves@inov.pt>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+/************************************************
+ * NAME : s3c2412.h
+ *
+ * Based on S3C2412 User's manual Rev 1.06a
+ ************************************************/
+
+#ifndef __S3C2412_H__
+#define __S3C2412_H__
+
+/* Base addresses for S3C2412 specific modules */
+#define S3C2412_INTERRUPT_BASE 0x4A000000
+#define S3C2412_SYSCTL_BASE 0x4C000000
+#define S3C2412_LCD_BASE 0x4D000000
+#define S3C2412_USB_DEVICE_BASE 0x52000000
+#define S3C2412_ADC_BASE 0x58000000
+#define S3C2412_SPI_BASE 0x59000000
+#define S3C2412_SDIO_BASE 0x5A000000
+
+#define S3C24XX_UART_CHANNELS 3
+#define S3C24XX_DMA_CHANNELS 4
+#define S3C24XX_SMC_BANKS 8
+
+#ifdef CONFIG_S3C2412
+#define S3C24XX_CPU_NAME "S3C2412"
+#else
+#define S3C24XX_CPU_NAME "S3C2413"
+#endif
+
+enum s3c24xx_uarts {
+ S3C24XX_UART0,
+ S3C24XX_UART1,
+ S3C24XX_UART2
+};
+
+enum s3c24xx_dmas {
+ S3C24XX_DMA0,
+ S3C24XX_DMA1,
+ S3C24XX_DMA2,
+ S3C24XX_DMA3
+};
+
+enum s3c24xx_smcs {
+ S3C24XX_SMC0,
+ S3C24XX_SMC1,
+ S3C24XX_SMC2,
+ S3C24XX_SMC3,
+ S3C24XX_SMC4,
+ S3C24XX_SMC5,
+ S3C24XX_SMC6,
+ S3C24XX_SMC7
+};
+
+/* Interrupt Controller */
+struct s3c2412_interrupt {
+ u32 srcpnd;
+ u32 intmod;
+ u32 intmsk;
+ u32 priority;
+ u32 intpnd;
+ u32 intoffset;
+ u32 subsrcpnd;
+ u32 intsubmsk;
+};
+
+/* System Controller */
+struct s3c2412_sysctl {
+ u32 locktime;
+ u32 mpllcon;
+ u32 upllcon;
+ u32 clkcon;
+ u32 _res1;
+ u32 clkdivn;
+ u32 oscset;
+ u32 clksrc;
+ u32 _res2;
+ u32 pwrcfg;
+ u32 _res3[2];
+ u32 swrstcon;
+ u32 rstcon;
+ u32 _res4[13];
+ u32 inform[4];
+};
+
+static inline struct s3c2412_interrupt *s3c2412_get_base_interrupt(void)
+{
+ return (struct s3c2412_interrupt *)S3C2412_INTERRUPT_BASE;
+}
+
+static inline struct s3c2412_sysctl *s3c2412_get_base_sysctl(void)
+{
+ return (struct s3c2412_sysctl *)S3C2412_SYSCTL_BASE;
+}
+
+/* Include common stuff */
+#include <asm/arch/s3c24xx.h>
+
+#endif /*__S3C2412_H__*/
diff --git a/arch/arm/include/asm/arch-s3c24xx/s3c2416.h b/arch/arm/include/asm/arch-s3c24xx/s3c2416.h
new file mode 100644
index 0000000..b68b8bb
--- /dev/null
+++ b/arch/arm/include/asm/arch-s3c24xx/s3c2416.h
@@ -0,0 +1,175 @@
+/*
+ * (C) Copyright 2012 INOV - INESC Inovacao
+ * Jose Goncalves <jose.goncalves@inov.pt>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+/************************************************
+ * NAME : s3c2416.h
+ *
+ * Based on S3C2416 User's manual Rev 1.40
+ ************************************************/
+
+#ifndef __S3C2416_H__
+#define __S3C2416_H__
+
+/* Base addresses for S3C2416 specific modules */
+#define S3C2416_USB_DEVICE_BASE 0x49800000
+#define S3C2416_INTERRUPT_BASE 0x4A000000
+#define S3C2416_HSMMC_BASE 0x4A800000
+#define S3C2416_SYSCTL_BASE 0x4C000000
+#define S3C2416_LCD_BASE 0x4C800000
+#define S3C2416_HSSPI_BASE 0x52000000
+#define S3C2416_ADC_BASE 0x58000000
+
+#define S3C24XX_UART_CHANNELS 4
+#define S3C24XX_DMA_CHANNELS 6
+#define S3C24XX_SMC_BANKS 6
+
+#ifdef CONFIG_S3C2416
+#define S3C24XX_CPU_NAME "S3C2416"
+#else
+#define S3C24XX_CPU_NAME "S3C2450"
+#endif
+
+enum s3c24xx_uarts {
+ S3C24XX_UART0,
+ S3C24XX_UART1,
+ S3C24XX_UART2,
+ S3C24XX_UART3
+};
+
+enum s3c24xx_dmas {
+ S3C24XX_DMA0,
+ S3C24XX_DMA1,
+ S3C24XX_DMA2,
+ S3C24XX_DMA3,
+ S3C24XX_DMA4,
+ S3C24XX_DMA5
+};
+
+enum s3c24xx_smcs {
+ S3C24XX_SMC0,
+ S3C24XX_SMC1,
+ S3C24XX_SMC2,
+ S3C24XX_SMC3,
+ S3C24XX_SMC4,
+ S3C24XX_SMC5
+};
+
+/* Interrupt Controller */
+struct s3c2416_interrupt {
+ u32 srcpnd1;
+ u32 intmod1;
+ u32 intmsk1;
+ u32 _res1;
+ u32 intpnd1;
+ u32 intoffset1;
+ u32 subsrcpnd;
+ u32 intsubmsk;
+ u32 _res2[4];
+ u32 priority_mode1;
+ u32 priority_update1;
+ u32 _res3[2];
+ u32 srcpnd2;
+ u32 intmod2;
+ u32 intmsk2;
+ u32 _res4;
+ u32 intpnd2;
+ u32 intoffset2;
+ u32 _res5[6];
+ u32 priority_mode2;
+ u32 priority_update2;
+};
+
+/* System Controller */
+struct s3c2416_sysctl {
+ u32 lockcon0;
+ u32 lockcon1;
+ u32 oscset;
+ u32 _res1;
+ u32 mpllcon;
+ u32 _res2;
+ u32 epllcon;
+ u32 epllcon_k;
+ u32 clksrc;
+ u32 clkdiv0;
+ u32 clkdiv1;
+ u32 clkdiv2;
+ u32 hclkcon;
+ u32 pclkcon;
+ u32 sclkcon;
+ u32 _res3;
+ u32 pwrmode;
+ u32 swrst;
+ u32 _res4[2];
+ u32 busprio;
+ u32 _res5[3];
+ u32 pwrcfg;
+ u32 rstcon;
+ u32 rststat;
+ u32 wkupstat;
+ u32 inform[4];
+ u32 uphyctrl;
+ u32 uphypwr;
+ u32 urstcon;
+ u32 uclkcon;
+};
+
+#define MPLLCON_MDIV_MASK (0x3FF<<14)
+#define MPLLCON_MDIV(x) ((x)<<14)
+#define MPLLCON_PDIV_MASK (0x3F<<5)
+#define MPLLCON_PDIV(x) ((x)<<5)
+#define MPLLCON_SDIV_MASK (0x7<<0)
+#define MPLLCON_SDIV(x) ((x)<<0)
+
+#define EPLLCON_MDIV_MASK (0xFF<<16)
+#define EPLLCON_MDIV(x) ((x)<<16)
+#define EPLLCON_PDIV_MASK (0x3F<<8)
+#define EPLLCON_PDIV(x) ((x)<<8)
+#define EPLLCON_SDIV_MASK (0x7<<0)
+#define EPLLCON_SDIV(x) ((x)<<0)
+
+#define CLKSRC_MSYSCLK_MPLL (1<<4)
+#define CLKSRC_ESYSCLK_EPLL (1<<6)
+
+#define CLKDIV0_HCLKDIV_MASK (3<<0)
+#define CLKDIV0_HCLKDIV(x) ((x)<<0)
+#define CLKDIV0_PCLKDIV (1<<2)
+#define CLKDIV0_HALFHCLK (1<<3)
+#define CLKDIV0_PREDIV_MASK (3<<4)
+#define CLKDIV0_PREDIV(x) ((x)<<4)
+#define CLKDIV0_ARMDIV_MASK (7<<9)
+#define CLKDIV0_ARMDIV(x) ((x)<<9)
+
+static inline struct s3c2416_interrupt *s3c2416_get_base_interrupt(void)
+{
+ return (struct s3c2416_interrupt *)S3C2416_INTERRUPT_BASE;
+}
+
+static inline struct s3c2416_sysctl *s3c2416_get_base_sysctl(void)
+{
+ return (struct s3c2416_sysctl *)S3C2416_SYSCTL_BASE;
+}
+
+/* Include common stuff */
+#include <asm/arch/s3c24xx.h>
+
+#endif /*__S3C2416_H__*/
diff --git a/arch/arm/include/asm/arch-s3c24xx/s3c24x0_cpu.h b/arch/arm/include/asm/arch-s3c24xx/s3c24x0_cpu.h
new file mode 100644
index 0000000..e54a46b
--- /dev/null
+++ b/arch/arm/include/asm/arch-s3c24xx/s3c24x0_cpu.h
@@ -0,0 +1,41 @@
+/*
+ * (C) Copyright 2012 INOV - INESC Inovacao
+ * Jose Goncalves <jose.goncalves@inov.pt>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+/* To be able to use s3c24x0 drivers */
+
+#ifndef __S3C24X0_CPU_H__
+#define __S3C24X0_CPU_H__
+
+#include <asm/arch/s3c24xx_cpu.h>
+
+#define s3c24x0_rtc s3c24xx_rtc
+#define s3c24x0_get_base_rtc s3c24xx_get_base_rtc
+
+#define S3C24X0_UART0 S3C24XX_UART0
+#define S3C24X0_UART1 S3C24XX_UART1
+#define S3C24X0_UART2 S3C24XX_UART2
+#define S3C24X0_UART3 S3C24XX_UART3
+#define s3c24x0_uart s3c24xx_uart
+#define s3c24x0_get_base_uart s3c24xx_get_base_uart
+
+#endif
diff --git a/arch/arm/include/asm/arch-s3c24xx/s3c24xx.h b/arch/arm/include/asm/arch-s3c24xx/s3c24xx.h
new file mode 100644
index 0000000..d0ce2f6
--- /dev/null
+++ b/arch/arm/include/asm/arch-s3c24xx/s3c24xx.h
@@ -0,0 +1,598 @@
+/*
+ * (C) Copyright 2012 INOV - INESC Inovacao
+ * Jose Goncalves <jose.goncalves@inov.pt>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+/******************************************************
+ * NAME : s3c24xx.h
+ *
+ * Common stuff for SAMSUNG S3C24XX SoC (ARM926EJ core)
+ ******************************************************/
+
+#ifndef __S3C24XX_H__
+#define __S3C24XX_H__
+
+/* Base addresses for S3C24XX common modules */
+#define S3C24XX_DRAMCTL_BASE 0x48000000
+#define S3C24XX_USB_HOST_BASE 0x49000000
+#define S3C24XX_DMA_BASE 0x4B000000
+#define S3C24XX_NAND_BASE 0x4E000000
+#define S3C24XX_SMC_BASE 0x4F000000
+#define S3C24XX_UART_BASE 0x50000000
+#define S3C24XX_TIMER_BASE 0x51000000
+#define S3C24XX_WATCHDOG_BASE 0x53000000
+#define S3C24XX_I2C_BASE 0x54000000
+#define S3C24XX_I2S_BASE 0x55000000
+#define S3C24XX_GPIO_BASE 0x56000000
+#define S3C24XX_RTC_BASE 0x57000000
+#define S3C24XX_ADC_BASE 0x58000000
+
+/* Mobile DRAM Controller */
+struct s3c24xx_dramctl {
+ u32 bankcfg;
+ u32 bankcon1;
+ u32 bankcon2;
+ u32 bankcon3;
+ u32 refresh;
+ u32 timeout;
+};
+
+#define BANKCFG_VAL_DDR2 0x00049253
+
+#define BANKCON1_VAL_DDR2 0x44000040
+#define BANKCON1_INIT_NORMAL 0x0
+#define BANKCON1_INIT_PALL 0x1
+#define BANKCON1_INIT_MRS 0x2
+#define BANKCON1_INIT_EMRS 0x3
+
+#define BANKCON2_VAL_DDR2 0x005D0035
+
+#define BANKCON3_VAL_EMRS1 0x44000000
+#define BANKCON3_EMRS1_CAS3 (3<<4)
+#define BANKCON3_EMRS1_OCD7 (7<<23)
+#define BANKCON3_VAL_EMRS2 0x80000000
+#define BANKCON3_VAL_EMRS3 0xC0000000
+#define BANKCON3_VAL_MRS 0x44000030
+#define BANKCON3_MRS_DLL_RESET (1<<8)
+
+/* USB Host Controller */
+struct s3c24xx_usb_host {
+ u32 HcRevision;
+ u32 HcControl;
+ u32 HcCommonStatus;
+ u32 HcInterruptStatus;
+ u32 HcInterruptEnable;
+ u32 HcInterruptDisable;
+ u32 HcHCCA;
+ u32 HcPeriodCuttendED;
+ u32 HcControlHeadED;
+ u32 HcControlCurrentED;
+ u32 HcBulkHeadED;
+ u32 HcBuldCurrentED;
+ u32 HcDoneHead;
+ u32 HcRmInterval;
+ u32 HcFmRemaining;
+ u32 HcFmNumber;
+ u32 HcPeriodicStart;
+ u32 HcLSThreshold;
+ u32 HcRhDescriptorA;
+ u32 HcRhDescriptorB;
+ u32 HcRhStatus;
+ u32 HcRhPortStatus1;
+ u32 HcRhPortStatus2;
+};
+
+/* DMA Controller */
+struct s3c24xx_dma {
+ u32 disrc;
+ u32 disrcc;
+ u32 didst;
+ u32 didstc;
+ u32 dcon;
+ u32 dstat;
+ u32 dcsrc;
+ u32 dcdst;
+ u32 dmasktrig;
+ u32 dmareqsel0;
+};
+
+/* NAND Flash Controller */
+struct s3c24xx_nand {
+ u32 nfconf;
+ u32 nfcont;
+ u32 nfcmmd;
+ u32 nfaddr;
+ u32 nfdata;
+ u32 nfmeccd[2];
+ u32 nfseccd;
+ u32 nfsblk;
+ u32 nfeblk;
+ u32 nfstat;
+ u32 nfeccerr[2];
+ u32 nfmecc[2];
+ u32 nfsecc;
+ u32 nfmlcbitpt;
+#if !(defined(CONFIG_S3C2412) || defined(CONFIG_S3C2413))
+ u32 nf8eccerr[3];
+ u32 nfm8ecc[4];
+ u32 nfmlc8bitpt[2];
+#endif
+};
+
+#if defined(CONFIG_S3C2412) || defined(CONFIG_S3C2413)
+#define NFCONF_ECCTYPE_MASK (1<<24)
+#define NFCONF_ECCTYPE_1BIT (0<<24)
+#define NFCONF_ECCTYPE_4BIT (1<<24)
+#else
+#define NFCONF_ECCTYPE_MASK (3<<23)
+#define NFCONF_ECCTYPE_1BIT (0<<23)
+#define NFCONF_ECCTYPE_8BIT (1<<23)
+#define NFCONF_ECCTYPE_4BIT (2<<23)
+#endif
+#define NFCONF_TACLS_MASK (7<<12)
+#define NFCONF_TWRPH0_MASK (7<<8)
+#define NFCONF_TWRPH1_MASK (7<<4)
+#define NFCONF_TACLS(x) ((x)<<12)
+#define NFCONF_TWRPH0(x) ((x)<<8)
+#define NFCONF_TWRPH1(x) ((x)<<4)
+
+#define NFCONT_ENABLE (1<<0)
+#define NFCONT_NCE0 (1<<1)
+#define NFCONT_NCE1 (1<<2)
+#define NFCONT_INITSECC (1<<4)
+#define NFCONT_INITMECC (1<<5)
+#define NFCONT_SECCLOCK (1<<6)
+#define NFCONT_MECCLOCK (1<<7)
+#define NFCONT_WP (1<<16)
+#define NFCONT_ECC_ENC (1<<18)
+
+#define NFSTAT_RNB (1<<0)
+
+/* SMC */
+struct s3c24xx_smc {
+ u32 smbidcy;
+ u32 smbwstrd;
+ u32 smbwstwr;
+ u32 smbwstoen;
+ u32 smbwstwen;
+ u32 smbc;
+ u32 smbs;
+ u32 smbwstbrd;
+};
+
+#define SMBC_RBLE (1<<0)
+#define SMBC_WAIT_POL (1<<1)
+#define SMBC_WAIT_EN (1<<2)
+#define SMBC_MW_MASK (0x3<<4)
+#define SMBC_MW_16BIT (1<<4)
+#define SMBC_MW_8BIT (0<<4)
+#define SMBC_DRNCS (1<<7)
+#define SMBC_RSMAVD_RD (1<<12)
+#define SMBC_DRNOWE (1<<15)
+#define SMBC_RSMAVD_WR (1<<20)
+
+/* UART */
+struct s3c24xx_uart {
+ u32 ulcon;
+ u32 ucon;
+ u32 ufcon;
+ u32 umcon;
+ u32 utrstat;
+ u32 uerstat;
+ u32 ufstat;
+ u32 umstat;
+#ifdef __BIG_ENDIAN
+ u8 _res1[3];
+ u8 utxh;
+ u8 _res2[3];
+ u8 urxh;
+#else /* Little Endian */
+ u8 utxh;
+ u8 _res1[3];
+ u8 urxh;
+ u8 _res2[3];
+#endif
+ u32 ubrdiv;
+ u32 udivslot;
+};
+
+#define ULCON_8N1 0x03
+
+#define UCON_POLL 0x005
+
+#define UMCON_NOAFC 0
+
+#define UFCON_FIFOMODE (1<<0)
+#define UFCON_RESETRX (1<<1)
+#define UFCON_RESETTX (1<<2)
+
+#define UTRSTAT_RXDR (1<<0)
+#define UTRSTAT_TXFE (1<<1)
+#define UTRSTAT_TXE (1<<2)
+
+/* PWM Timer */
+struct s3c24xx_timer {
+ u32 tcntb;
+ u32 tcmpb;
+ u32 tcnto;
+};
+
+struct s3c24xx_timers {
+ u32 tcfg0;
+ u32 tcfg1;
+ u32 tcon;
+ struct s3c24xx_timer ch[4];
+ u32 tcntb4;
+ u32 tcnto4;
+};
+
+#define TCFG0_PRESCALER1_MASK (0xFF<<8)
+#define TCFG0_PRESCALER1(x) ((x)<<8)
+
+#define TCFG1_MUX4_DIV2 (0<<16)
+#define TCFG1_MUX4_DIV4 (1<<16)
+#define TCFG1_MUX4_DIV8 (2<<16)
+#define TCFG1_MUX4_DIV16 (3<<16)
+#define TCFG1_MUX4_TCLK1 (4<<16)
+#define TCFG1_MUX4_MASK (0xF<<16)
+
+#define TCON_T4START (1<<20)
+#define TCON_T4MANUALUPD (1<<21)
+#define TCON_T4RELOAD (1<<22)
+
+/* Watchdog Timer */
+struct s3c24xx_watchdog {
+ u32 wtcon;
+ u32 wtdat;
+ u32 wtcnt;
+};
+
+#define WTCON_RSTEN (1<<0)
+#define WTCON_INTEN (1<<2)
+#define WTCON_ENABLE (1<<5)
+
+/* IIC-Bus Interface */
+struct s3c24xx_i2c {
+ u32 iiccon;
+ u32 iicstat;
+ u32 iicadd;
+ u32 iicds;
+ u32 iiclc;
+};
+
+/* IIS-Bus Interface */
+struct s3c24xx_i2s {
+ u32 iiscon;
+ u32 iismod;
+ u32 iisfic;
+ u32 iispsr;
+ u32 iistxd;
+ u32 iisrxd;
+};
+
+/* I/O Ports */
+struct s3c24xx_gpio {
+#if defined(CONFIG_S3C2412) || defined(CONFIG_S3C2413)
+ u32 gpacon;
+ u32 gpadat;
+ u32 _res1[2];
+ u32 gpbcon;
+ u32 gpbdat;
+ u32 gpbdn;
+ u32 gpbslpcon;
+ u32 gpccon;
+ u32 gpcdat;
+ u32 gpcdn;
+ u32 gpcslpcon;
+ u32 gpdcon;
+ u32 gpddat;
+ u32 gpddn;
+ u32 gpdslpcon;
+ u32 gpecon;
+ u32 gpedat;
+ u32 gpedn;
+ u32 gpeslpcon;
+ u32 gpfcon;
+ u32 gpfdat;
+ u32 gpfdn;
+ u32 _res2;
+ u32 gpgcon;
+ u32 gpgdat;
+ u32 gpgdn;
+ u32 gpgslpcon;
+ u32 gphcon;
+ u32 gphdat;
+ u32 gphdn;
+ u32 gphslpcon;
+ u32 gpjcon;
+ u32 gpjdat;
+ u32 gpjdn;
+ u32 gpjslpcon;
+
+ u32 misccr;
+ u32 dclkcon;
+ u32 extint[3];
+ u32 eintflt[4];
+ u32 eintmask;
+ u32 eintpend;
+ u32 gstatus[6];
+ u32 mstcon;
+ u32 mslcon;
+ u32 dsc[2];
+#else
+ u32 gpacon;
+ u32 gpadat;
+ u32 _res1[2];
+ u32 gpbcon;
+ u32 gpbdat;
+ u32 gpbudp;
+ u32 gpbsel;
+ u32 gpccon;
+ u32 gpcdat;
+ u32 gpcudp;
+ u32 _res2;
+ u32 gpdcon;
+ u32 gpddat;
+ u32 gpdudp;
+ u32 _res3;
+ u32 gpecon;
+ u32 gpedat;
+ u32 gpeudp;
+ u32 gpesel;
+ u32 gpfcon;
+ u32 gpfdat;
+ u32 gpfudp;
+ u32 _res4;
+ u32 gpgcon;
+ u32 gpgdat;
+ u32 gpgudp;
+ u32 _res5;
+ u32 gphcon;
+ u32 gphdat;
+ u32 gphudp;
+ u32 _res6;
+
+ u32 misccr;
+ u32 dclkcon;
+ u32 extint[3];
+ u32 _res7[2];
+ u32 eintflt2;
+ u32 eintflt3;
+ u32 eintmask;
+ u32 eintpend;
+ u32 gstatus[2];
+ u32 _res8[3];
+ u32 dsc[4];
+
+ u32 gpjcon;
+ u32 gpjdat;
+ u32 gpjudp;
+ u32 gpjsel;
+ u32 gpkcon;
+ u32 gpkdat;
+ u32 gpkudp;
+ u32 _res9;
+ u32 gplcon;
+ u32 gpldat;
+ u32 gpludp;
+ u32 gplsel;
+ u32 gpmcon;
+ u32 gpmdat;
+ u32 gpmudp;
+ u32 _res10;
+
+ u32 dsc3;
+ u32 pddmcon;
+ u32 pdsmcon;
+#endif
+};
+
+/* RTC */
+struct s3c24xx_rtc {
+#ifdef __BIG_ENDIAN
+ u8 _res1[67];
+ u8 rtccon;
+ u8 _res2[3];
+ u8 ticnt0;
+#if defined(CONFIG_S3C2412) || defined(CONFIG_S3C2413)
+ u8 _res3[4];
+#else
+ u8 _res3[3];
+ u8 ticnt2;
+#endif
+ u8 _res4[3];
+ u8 ticnt1;
+ u8 _res5[3];
+ u8 rtcalm;
+ u8 _res6[3];
+ u8 almsec;
+ u8 _res7[3];
+ u8 almmin;
+ u8 _res8[3];
+ u8 almhour;
+ u8 _res9[3];
+ u8 almdate;
+ u8 _res10[3];
+ u8 almmon;
+ u8 _res11[3];
+ u8 almyear;
+ u8 _res12[7];
+ u8 bcdsec;
+ u8 _res13[3];
+ u8 bcdmin;
+ u8 _res14[3];
+ u8 bcdhour;
+ u8 _res15[3];
+ u8 bcddate;
+ u8 _res16[3];
+ u8 bcdday;
+ u8 _res17[3];
+ u8 bcdmon;
+ u8 _res18[3];
+ u8 bcdyear;
+#if !(defined(CONFIG_S3C2412) || defined(CONFIG_S3C2413))
+ u8 _res19[3];
+ u8 tickcnt;
+#endif
+#else /* little endian */
+ u8 _res0[64];
+ u8 rtccon;
+ u8 _res1[3];
+ u8 ticnt0;
+ u8 _res2[3];
+#if defined(CONFIG_S3C2412) || defined(CONFIG_S3C2413)
+ u8 _res3[4];
+#else
+ u8 ticnt2;
+ u8 _res3[3];
+#endif
+ u8 ticnt1;
+ u8 _res4[3];
+ u8 rtcalm;
+ u8 _res5[3];
+ u8 almsec;
+ u8 _res6[3];
+ u8 almmin;
+ u8 _res7[3];
+ u8 almhour;
+ u8 _res8[3];
+ u8 almdate;
+ u8 _res9[3];
+ u8 almmon;
+ u8 _res10[3];
+ u8 almyear;
+ u8 _res11[7];
+ u8 bcdsec;
+ u8 _res12[3];
+ u8 bcdmin;
+ u8 _res13[3];
+ u8 bcdhour;
+ u8 _res14[3];
+ u8 bcddate;
+ u8 _res15[3];
+ u8 bcdday;
+ u8 _res16[3];
+ u8 bcdmon;
+ u8 _res17[3];
+ u8 bcdyear;
+ u8 _res18[3];
+#if !(defined(CONFIG_S3C2412) || defined(CONFIG_S3C2413))
+ u8 tickcnt;
+ u8 _res19[3];
+#endif
+#endif
+};
+
+#define RTCCON_RTCEN (1<<0)
+#define RTCCON_CNTSEL (1<<2)
+#define RTCCON_CLKRST (1<<3)
+#define RTCCON_TICSEL (1<<4)
+
+/* ADC & Touch Screen Interface */
+struct s3c24xx_adc {
+ u32 adccon;
+ u32 adctsc;
+ u32 adcdly;
+ u32 adcdat0;
+ u32 adcdat1;
+#if !(defined(CONFIG_S3C2412) || defined(CONFIG_S3C2413))
+ u32 adcupdn;
+ u32 adcmux;
+#endif
+};
+
+static inline struct s3c24xx_dramctl *s3c24xx_get_base_dramctl(void)
+{
+ return (struct s3c24xx_dramctl *)S3C24XX_DRAMCTL_BASE;
+}
+
+static inline struct s3c24xx_usb_host *s3c24xx_get_base_usb_host(void)
+{
+ return (struct s3c24xx_usb_host *)S3C24XX_USB_HOST_BASE;
+}
+
+static inline struct s3c24xx_dma *s3c24xx_get_base_dma(enum s3c24xx_dmas n)
+{
+#if defined(CONFIG_S3C2412) || defined(CONFIG_S3C2413)
+ return (struct s3c24xx_dma *)(S3C24XX_DMA_BASE + (n * 0x40));
+#else
+ return (struct s3c24xx_dma *)(S3C24XX_DMA_BASE + (n * 0x100));
+#endif
+}
+
+static inline struct s3c24xx_nand *s3c24xx_get_base_nand(void)
+{
+ return (struct s3c24xx_nand *)S3C24XX_NAND_BASE;
+}
+
+static inline struct s3c24xx_smc *s3c24xx_get_base_smc(enum s3c24xx_smcs n)
+{
+ return (struct s3c24xx_smc *)(S3C24XX_SMC_BASE + (n * 0x20));
+}
+
+static inline struct s3c24xx_uart *s3c24xx_get_base_uart(enum s3c24xx_uarts n)
+{
+ return (struct s3c24xx_uart *)(S3C24XX_UART_BASE + (n * 0x4000));
+}
+
+static inline struct s3c24xx_timers *s3c24xx_get_base_timers(void)
+{
+ return (struct s3c24xx_timers *)S3C24XX_TIMER_BASE;
+}
+
+static inline struct s3c24xx_watchdog *s3c24xx_get_base_watchdog(void)
+{
+ return (struct s3c24xx_watchdog *)S3C24XX_WATCHDOG_BASE;
+}
+
+static inline struct s3c24xx_i2c *s3c24xx_get_base_i2c(void)
+{
+ return (struct s3c24xx_i2c *)S3C24XX_I2C_BASE;
+}
+
+static inline struct s3c24xx_i2s *s3c24xx_get_base_i2s(void)
+{
+ return (struct s3c24xx_i2s *)S3C24XX_I2S_BASE;
+}
+
+static inline struct s3c24xx_gpio *s3c24xx_get_base_gpio(void)
+{
+ return (struct s3c24xx_gpio *)S3C24XX_GPIO_BASE;
+}
+
+static inline struct s3c24xx_rtc *s3c24xx_get_base_rtc(void)
+{
+ return (struct s3c24xx_rtc *)S3C24XX_RTC_BASE;
+}
+
+static inline struct s3c24xx_adc *s3c24xx_get_base_adc(void)
+{
+ return (struct s3c24xx_adc *)S3C24XX_ADC_BASE;
+}
+
+static inline char *s3c24xx_get_cpu_name(void)
+{
+ return S3C24XX_CPU_NAME;
+}
+
+extern ulong get_ARMCLK(void);
+
+#endif /*__S3C24XX_H__*/
diff --git a/arch/arm/include/asm/arch-s3c24xx/s3c24xx_cpu.h b/arch/arm/include/asm/arch-s3c24xx/s3c24xx_cpu.h
new file mode 100644
index 0000000..59ccfd4
--- /dev/null
+++ b/arch/arm/include/asm/arch-s3c24xx/s3c24xx_cpu.h
@@ -0,0 +1,30 @@
+/*
+ * (C) Copyright 2012 INOV - INESC Inovacao
+ * Jose Goncalves <jose.goncalves@inov.pt>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#if defined(CONFIG_S3C2412) || defined(CONFIG_S3C2413)
+#include <asm/arch/s3c2412.h>
+#elif defined(CONFIG_S3C2416) || defined(CONFIG_S3C2450)
+#include <asm/arch/s3c2416.h>
+#else
+#error Please define the S3C24XX SoC type
+#endif
diff --git a/include/common.h b/include/common.h
index 55025c0..36f0636 100644
--- a/include/common.h
+++ b/include/common.h
@@ -628,6 +628,7 @@ ulong get_OPB_freq (void);
ulong get_PCI_freq (void);
#endif
#if defined(CONFIG_S3C24X0) || \
+ defined(CONFIG_S3C24XX) || \
defined(CONFIG_LH7A40X) || \
defined(CONFIG_S3C6400) || \
defined(CONFIG_EP93XX)
--
1.7.9.5
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 03/11] serial: Add support to 4 ports in serial_s3c24x0
2012-09-14 17:28 [U-Boot] [PATCH v2 00/11] S3C24XX: Add support to MINI2416 board José Miguel Gonçalves
2012-09-14 17:28 ` [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS José Miguel Gonçalves
2012-09-14 17:28 ` [U-Boot] [PATCH v2 02/11] S3C24XX: Add core support for Samsung's S3C24XX SoCs José Miguel Gonçalves
@ 2012-09-14 17:28 ` José Miguel Gonçalves
2012-09-14 17:28 ` [U-Boot] [PATCH v2 04/11] serial: Use a more precise baud rate generation for serial_s3c24x0 José Miguel Gonçalves
` (7 subsequent siblings)
10 siblings, 0 replies; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-14 17:28 UTC (permalink / raw)
To: u-boot
S3C2416 and S3C2450 have 4 UARTs insted of 3 found on older chips.
This patch adds support to the additional UART port and changes the
mapping between CONFIG_SERIAL? and S3C24X0_UART? in order they have
a direct correspondence.
Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
---
Changes for v2:
- New patch
---
drivers/serial/serial_s3c24x0.c | 25 ++++++++++++++++++-------
include/configs/VCMA9.h | 2 +-
include/configs/smdk2410.h | 2 +-
3 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/drivers/serial/serial_s3c24x0.c b/drivers/serial/serial_s3c24x0.c
index 12bcdd3..280cd2d 100644
--- a/drivers/serial/serial_s3c24x0.c
+++ b/drivers/serial/serial_s3c24x0.c
@@ -2,6 +2,9 @@
* (C) Copyright 2002
* Gary Jennejohn, DENX Software Engineering, <garyj@denx.de>
*
+ * (C) Copyright 2012 INOV - INESC Inovacao
+ * Jose Goncalves <jose.goncalves@inov.pt>
+ *
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
@@ -24,17 +27,20 @@
DECLARE_GLOBAL_DATA_PTR;
-#ifdef CONFIG_SERIAL1
+#if defined(CONFIG_SERIAL0)
#define UART_NR S3C24X0_UART0
-#elif defined(CONFIG_SERIAL2)
+#elif defined(CONFIG_SERIAL1)
#define UART_NR S3C24X0_UART1
-#elif defined(CONFIG_SERIAL3)
+#elif defined(CONFIG_SERIAL2)
#define UART_NR S3C24X0_UART2
+#elif defined(CONFIG_SERIAL3)
+#define UART_NR S3C24X0_UART3
+
#else
-#error "Bad: you didn't configure serial ..."
+#error "You didn't configure serial."
#endif
#include <asm/io.h>
@@ -310,15 +316,20 @@ INIT_S3C_SERIAL_STRUCTURE(1, "s3ser1");
DECLARE_S3C_SERIAL_FUNCTIONS(2);
struct serial_device s3c24xx_serial2_device =
INIT_S3C_SERIAL_STRUCTURE(2, "s3ser2");
+DECLARE_S3C_SERIAL_FUNCTIONS(3);
+struct serial_device s3c24xx_serial3_device =
+INIT_S3C_SERIAL_STRUCTURE(3, "s3ser3");
__weak struct serial_device *default_serial_console(void)
{
-#if defined(CONFIG_SERIAL1)
+#if defined(CONFIG_SERIAL0)
return &s3c24xx_serial0_device;
-#elif defined(CONFIG_SERIAL2)
+#elif defined(CONFIG_SERIAL1)
return &s3c24xx_serial1_device;
-#elif defined(CONFIG_SERIAL3)
+#elif defined(CONFIG_SERIAL2)
return &s3c24xx_serial2_device;
+#elif defined(CONFIG_SERIAL3)
+ return &s3c24xx_serial3_device;
#else
#error "CONFIG_SERIAL? missing."
#endif
diff --git a/include/configs/VCMA9.h b/include/configs/VCMA9.h
index 06adc94..46bc22d 100644
--- a/include/configs/VCMA9.h
+++ b/include/configs/VCMA9.h
@@ -120,7 +120,7 @@
* select serial console configuration
*/
#define CONFIG_S3C24X0_SERIAL
-#define CONFIG_SERIAL1 1 /* we use SERIAL 1 on VCMA9 */
+#define CONFIG_SERIAL0 1 /* we use SERIAL 0 on VCMA9 */
/* USB support (currently only works with D-cache off) */
#define CONFIG_USB_OHCI
diff --git a/include/configs/smdk2410.h b/include/configs/smdk2410.h
index 1c0978d..5daa3fe 100644
--- a/include/configs/smdk2410.h
+++ b/include/configs/smdk2410.h
@@ -60,7 +60,7 @@
* select serial console configuration
*/
#define CONFIG_S3C24X0_SERIAL
-#define CONFIG_SERIAL1 1 /* we use SERIAL 1 on SMDK2410 */
+#define CONFIG_SERIAL0 1 /* we use SERIAL 0 on SMDK2410 */
/************************************************************
* USB support (currently only works with D-cache off)
--
1.7.9.5
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 04/11] serial: Use a more precise baud rate generation for serial_s3c24x0
2012-09-14 17:28 [U-Boot] [PATCH v2 00/11] S3C24XX: Add support to MINI2416 board José Miguel Gonçalves
` (2 preceding siblings ...)
2012-09-14 17:28 ` [U-Boot] [PATCH v2 03/11] serial: Add support to 4 ports in serial_s3c24x0 José Miguel Gonçalves
@ 2012-09-14 17:28 ` José Miguel Gonçalves
2012-09-14 18:05 ` Marek Vasut
2012-09-14 17:28 ` [U-Boot] [PATCH v2 05/11] serial: Remove unnecessary delay in serial_s3c24x0 José Miguel Gonçalves
` (6 subsequent siblings)
10 siblings, 1 reply; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-14 17:28 UTC (permalink / raw)
To: u-boot
Program udivslot register in order to obtain a more precise baudrate.
Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
---
Changes for v2:
- New patch
---
drivers/serial/serial_s3c24x0.c | 24 ++++++++++++++++++++----
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/serial/serial_s3c24x0.c b/drivers/serial/serial_s3c24x0.c
index 280cd2d..c9bc121 100644
--- a/drivers/serial/serial_s3c24x0.c
+++ b/drivers/serial/serial_s3c24x0.c
@@ -92,16 +92,32 @@ DECLARE_GLOBAL_DATA_PTR;
static int hwflow;
#endif
+/*
+ * The values stored in the baud rate divisor register (UBRDIVn) and dividing
+ * slot register (UDIVSLOTn), are used to determine the serial Tx/Rx clock rate
+ * (baud rate) as follows:
+ * DIV_VAL = UBRDIVn + (num of 1?s in UDIVSLOTn) / 16
+ * Using UDIVSLOT, which is the factor of floating point divisor, you can make
+ * more accurate baud rate. Section 2.1.10 of the S3C2416 User's Manual suggests
+ * using the constants on the following table.
+ */
+static const int udivslot[] = {
+ 0x0000, 0x0080, 0x0808, 0x0888, 0x2222, 0x4924, 0x4A52, 0x54AA,
+ 0x5555, 0xD555, 0xD5D5, 0xDDD5, 0xDDDD, 0xDFDD, 0xDFDF, 0xFFDF,
+};
+
void _serial_setbrg(const int dev_index)
{
struct s3c24x0_uart *uart = s3c24x0_get_base_uart(dev_index);
- unsigned int reg = 0;
+ u32 pclk;
+ u32 baudrate;
int i;
- /* value is calculated so : (int)(PCLK/16./baudrate) -1 */
- reg = get_PCLK() / (16 * gd->baudrate) - 1;
+ pclk = get_PCLK();
+ baudrate = gd->baudrate;
- writel(reg, &uart->ubrdiv);
+ writel((pclk / baudrate / 16) - 1, &uart->ubrdiv);
+ writel(udivslot[(pclk / baudrate) % 16], &uart->udivslot);
for (i = 0; i < 100; i++)
/* Delay */ ;
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 05/11] serial: Remove unnecessary delay in serial_s3c24x0
2012-09-14 17:28 [U-Boot] [PATCH v2 00/11] S3C24XX: Add support to MINI2416 board José Miguel Gonçalves
` (3 preceding siblings ...)
2012-09-14 17:28 ` [U-Boot] [PATCH v2 04/11] serial: Use a more precise baud rate generation for serial_s3c24x0 José Miguel Gonçalves
@ 2012-09-14 17:28 ` José Miguel Gonçalves
2012-09-14 18:05 ` Marek Vasut
2012-09-14 17:28 ` [U-Boot] [PATCH v2 06/11] rtc: Improve rtc_get() on s3c24x0_rtc José Miguel Gonçalves
` (5 subsequent siblings)
10 siblings, 1 reply; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-14 17:28 UTC (permalink / raw)
To: u-boot
The loop used to make a delay after baudrate setting is not necessary.
Moreover it is removed by the GCC optimizer (at least with GCC 4.6).
Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
---
Changes for v2:
- New patch
---
drivers/serial/serial_s3c24x0.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/serial/serial_s3c24x0.c b/drivers/serial/serial_s3c24x0.c
index c9bc121..ec5d1cb 100644
--- a/drivers/serial/serial_s3c24x0.c
+++ b/drivers/serial/serial_s3c24x0.c
@@ -111,15 +111,12 @@ void _serial_setbrg(const int dev_index)
struct s3c24x0_uart *uart = s3c24x0_get_base_uart(dev_index);
u32 pclk;
u32 baudrate;
- int i;
pclk = get_PCLK();
baudrate = gd->baudrate;
writel((pclk / baudrate / 16) - 1, &uart->ubrdiv);
writel(udivslot[(pclk / baudrate) % 16], &uart->udivslot);
- for (i = 0; i < 100; i++)
- /* Delay */ ;
}
#if defined(CONFIG_SERIAL_MULTI)
--
1.7.9.5
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 06/11] rtc: Improve rtc_get() on s3c24x0_rtc
2012-09-14 17:28 [U-Boot] [PATCH v2 00/11] S3C24XX: Add support to MINI2416 board José Miguel Gonçalves
` (4 preceding siblings ...)
2012-09-14 17:28 ` [U-Boot] [PATCH v2 05/11] serial: Remove unnecessary delay in serial_s3c24x0 José Miguel Gonçalves
@ 2012-09-14 17:28 ` José Miguel Gonçalves
2012-09-14 18:06 ` Marek Vasut
2012-09-14 17:28 ` [U-Boot] [PATCH v2 07/11] rtc: Fix rtc_reset() " José Miguel Gonçalves
` (4 subsequent siblings)
10 siblings, 1 reply; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-14 17:28 UTC (permalink / raw)
To: u-boot
A better approach to avoid reading the RTC during updates, as sugested in
the S3C2416 User's Manual.
Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
---
Changes for v2:
- New patch
---
drivers/rtc/s3c24x0_rtc.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/s3c24x0_rtc.c b/drivers/rtc/s3c24x0_rtc.c
index c16ff2e..7d04b74 100644
--- a/drivers/rtc/s3c24x0_rtc.c
+++ b/drivers/rtc/s3c24x0_rtc.c
@@ -65,20 +65,26 @@ int rtc_get(struct rtc_time *tmp)
uchar sec, min, hour, mday, wday, mon, year;
__maybe_unused uchar a_sec, a_min, a_hour, a_date,
a_mon, a_year, a_armed;
+ int have_retried = 0;
/* enable access to RTC registers */
SetRTC_Access(RTC_ENABLE);
/* read RTC registers */
do {
- sec = readb(&rtc->bcdsec);
min = readb(&rtc->bcdmin);
hour = readb(&rtc->bcdhour);
mday = readb(&rtc->bcddate);
wday = readb(&rtc->bcdday);
mon = readb(&rtc->bcdmon);
year = readb(&rtc->bcdyear);
- } while (sec != readb(&rtc->bcdsec));
+ sec = readb(&rtc->bcdsec);
+ /*
+ * The only way to work out whether the RTC was mid-update
+ * when we read it is to check the seconds counter.
+ * If it's zero, then we re-try the entire read.
+ */
+ } while ((sec == 0) && !(have_retried++));
/* read ALARM registers */
a_sec = readb(&rtc->almsec);
--
1.7.9.5
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 07/11] rtc: Fix rtc_reset() on s3c24x0_rtc
2012-09-14 17:28 [U-Boot] [PATCH v2 00/11] S3C24XX: Add support to MINI2416 board José Miguel Gonçalves
` (5 preceding siblings ...)
2012-09-14 17:28 ` [U-Boot] [PATCH v2 06/11] rtc: Improve rtc_get() on s3c24x0_rtc José Miguel Gonçalves
@ 2012-09-14 17:28 ` José Miguel Gonçalves
2012-09-14 18:07 ` Marek Vasut
2012-09-14 17:28 ` [U-Boot] [PATCH v2 08/11] rtc: Don't allow setting unsuported years " José Miguel Gonçalves
` (3 subsequent siblings)
10 siblings, 1 reply; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-14 17:28 UTC (permalink / raw)
To: u-boot
rtc_reset() must set the RTC date to the UNIX Epoch.
Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
---
Changes for v2:
- New patch
---
drivers/rtc/s3c24x0_rtc.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/rtc/s3c24x0_rtc.c b/drivers/rtc/s3c24x0_rtc.c
index 7d04b74..54bf6e3 100644
--- a/drivers/rtc/s3c24x0_rtc.c
+++ b/drivers/rtc/s3c24x0_rtc.c
@@ -167,10 +167,17 @@ int rtc_set(struct rtc_time *tmp)
void rtc_reset(void)
{
- struct s3c24x0_rtc *rtc = s3c24x0_get_base_rtc();
-
- writeb((readb(&rtc->rtccon) & ~0x06) | 0x08, &rtc->rtccon);
- writeb(readb(&rtc->rtccon) & ~(0x08 | 0x01), &rtc->rtccon);
+ static struct rtc_time tmp = {
+ .tm_year = 1970,
+ .tm_mon = 1,
+ .tm_mday = 1,
+ .tm_wday = 4,
+ .tm_hour = 0,
+ .tm_min = 0,
+ .tm_sec = 0,
+ };
+
+ rtc_set(&tmp);
}
#endif
--
1.7.9.5
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 08/11] rtc: Don't allow setting unsuported years on s3c24x0_rtc
2012-09-14 17:28 [U-Boot] [PATCH v2 00/11] S3C24XX: Add support to MINI2416 board José Miguel Gonçalves
` (6 preceding siblings ...)
2012-09-14 17:28 ` [U-Boot] [PATCH v2 07/11] rtc: Fix rtc_reset() " José Miguel Gonçalves
@ 2012-09-14 17:28 ` José Miguel Gonçalves
2012-09-14 18:08 ` Marek Vasut
2012-09-14 17:29 ` [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver José Miguel Gonçalves
` (2 subsequent siblings)
10 siblings, 1 reply; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-14 17:28 UTC (permalink / raw)
To: u-boot
This RTC only supports a 100 years range so rtc_set() should not allow setting
years bellow 1970 or above 2069.
Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
---
Changes for v2:
- New patch
---
drivers/rtc/s3c24x0_rtc.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/rtc/s3c24x0_rtc.c b/drivers/rtc/s3c24x0_rtc.c
index 54bf6e3..f96cb11 100644
--- a/drivers/rtc/s3c24x0_rtc.c
+++ b/drivers/rtc/s3c24x0_rtc.c
@@ -139,6 +139,11 @@ int rtc_set(struct rtc_time *tmp)
tmp->tm_year, tmp->tm_mon, tmp->tm_mday, tmp->tm_wday,
tmp->tm_hour, tmp->tm_min, tmp->tm_sec);
#endif
+ if (tmp->tm_year < 1970 || tmp->tm_year > 2069) {
+ puts("ERROR: year should be between 1970 and 2069!\n");
+ return -1;
+ }
+
year = bin2bcd(tmp->tm_year % 100);
mon = bin2bcd(tmp->tm_mon);
wday = bin2bcd(tmp->tm_wday);
--
1.7.9.5
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
2012-09-14 17:28 [U-Boot] [PATCH v2 00/11] S3C24XX: Add support to MINI2416 board José Miguel Gonçalves
` (7 preceding siblings ...)
2012-09-14 17:28 ` [U-Boot] [PATCH v2 08/11] rtc: Don't allow setting unsuported years " José Miguel Gonçalves
@ 2012-09-14 17:29 ` José Miguel Gonçalves
2012-09-14 18:21 ` Marek Vasut
2012-09-14 18:47 ` Tom Rini
2012-09-14 17:29 ` [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile José Miguel Gonçalves
2012-09-14 17:29 ` [U-Boot] [PATCH v2 11/11] S3C24XX: Add support to MINI2416 board José Miguel Gonçalves
10 siblings, 2 replies; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-14 17:29 UTC (permalink / raw)
To: u-boot
NAND Flash driver with HW ECC for the S3C24XX SoCs.
Currently it only supports SLC NAND chips.
Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
---
Changes for v2:
- Coding style cleanup
- Use of clrsetbits_le32()
- Use of register bit macros instead of magic numbers
---
drivers/mtd/nand/Makefile | 1 +
drivers/mtd/nand/s3c24xx_nand.c | 245 +++++++++++++++++++++++++++++++++++++++
2 files changed, 246 insertions(+)
create mode 100644 drivers/mtd/nand/s3c24xx_nand.c
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 29dc20e..791ec44 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -60,6 +60,7 @@ COBJS-$(CONFIG_NAND_MXS) += mxs_nand.o
COBJS-$(CONFIG_NAND_NDFC) += ndfc.o
COBJS-$(CONFIG_NAND_NOMADIK) += nomadik.o
COBJS-$(CONFIG_NAND_S3C2410) += s3c2410_nand.o
+COBJS-$(CONFIG_NAND_S3C24XX) += s3c24xx_nand.o
COBJS-$(CONFIG_NAND_S3C64XX) += s3c64xx.o
COBJS-$(CONFIG_NAND_SPEAR) += spr_nand.o
COBJS-$(CONFIG_NAND_OMAP_GPMC) += omap_gpmc.o
diff --git a/drivers/mtd/nand/s3c24xx_nand.c b/drivers/mtd/nand/s3c24xx_nand.c
new file mode 100644
index 0000000..9c0f6e2
--- /dev/null
+++ b/drivers/mtd/nand/s3c24xx_nand.c
@@ -0,0 +1,245 @@
+/*
+ * (C) Copyright 2012 INOV - INESC Inovacao
+ * Jose Goncalves <jose.goncalves@inov.pt>
+ *
+ * Based on drivers/mtd/nand/s3c64xx.c and U-Boot 1.3.4 from Samsung.
+ * Supports only SLC NAND Flash chips.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <common.h>
+#include <nand.h>
+#include <asm/io.h>
+#include <asm/arch/s3c24xx_cpu.h>
+#include <asm/errno.h>
+
+#define MAX_CHIPS 2
+static int nand_cs[MAX_CHIPS] = { 0, 1 };
+
+#ifdef CONFIG_SPL_BUILD
+#define printf(arg...) do {} while (0)
+#endif
+
+static void s3c_nand_select_chip(struct mtd_info *mtd, int chip)
+{
+ struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
+ u_long nfcont;
+
+ nfcont = readl(&nand->nfcont);
+
+ switch (chip) {
+ case -1:
+ nfcont |= NFCONT_NCE1 | NFCONT_NCE0;
+ break;
+ case 0:
+ nfcont &= ~NFCONT_NCE0;
+ break;
+ case 1:
+ nfcont &= ~NFCONT_NCE1;
+ break;
+ default:
+ return;
+ }
+
+ writel(nfcont, &nand->nfcont);
+}
+
+/*
+ * Hardware specific access to control-lines function
+ */
+static void s3c_nand_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl)
+{
+ struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
+ struct nand_chip *this = mtd->priv;
+
+ if (ctrl & NAND_CTRL_CHANGE) {
+ if (ctrl & NAND_CLE)
+ this->IO_ADDR_W = &nand->nfcmmd;
+ else if (ctrl & NAND_ALE)
+ this->IO_ADDR_W = &nand->nfaddr;
+ else
+ this->IO_ADDR_W = &nand->nfdata;
+ if (ctrl & NAND_NCE)
+ s3c_nand_select_chip(mtd, *(int *)this->priv);
+ else
+ s3c_nand_select_chip(mtd, -1);
+ }
+
+ if (cmd != NAND_CMD_NONE)
+ writeb(cmd, this->IO_ADDR_W);
+}
+
+/*
+ * Function for checking device ready pin
+ */
+static int s3c_nand_device_ready(struct mtd_info *mtdinfo)
+{
+ struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
+
+ return readl(&nand->nfstat) & NFSTAT_RNB;
+}
+
+#ifdef CONFIG_S3C24XX_NAND_HWECC
+/*
+ * This function is called before encoding ECC codes to ready ECC engine.
+ */
+static void s3c_nand_enable_hwecc(struct mtd_info *mtd, int mode)
+{
+ struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
+
+ /* Set 1-bit ECC */
+ clrsetbits_le32(&nand->nfconf, NFCONF_ECCTYPE_MASK,
+ NFCONF_ECCTYPE_1BIT);
+
+ /* Initialize & unlock ECC */
+ clrsetbits_le32(&nand->nfcont, NFCONT_MECCLOCK, NFCONT_INITMECC);
+}
+
+/*
+ * This function is called immediately after encoding ECC codes.
+ * This function returns encoded ECC codes.
+ */
+static int s3c_nand_calculate_ecc(struct mtd_info *mtd, const u_char *dat,
+ u_char *ecc_code)
+{
+ struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
+ u_long nfmecc0;
+
+ /* Lock ECC */
+ setbits_le32(&nand->nfcont, NFCONT_MECCLOCK);
+
+ /* Return 1-bit ECC */
+ nfmecc0 = readl(&nand->nfmecc[0]);
+
+ ecc_code[0] = nfmecc0 & 0xff;
+ ecc_code[1] = (nfmecc0 >> 8) & 0xff;
+ ecc_code[2] = (nfmecc0 >> 16) & 0xff;
+ ecc_code[3] = (nfmecc0 >> 24) & 0xff;
+
+ return 0;
+}
+
+/*
+ * This function determines whether read data is good or not.
+ * On SLC, must write ECC codes to controller before reading status bit.
+ * If status bit is good, return 0.
+ * If a correctable error occured, correct it and return 1.
+ * If an uncorrectable error occured, return -1.
+ */
+static int s3c_nand_correct_data(struct mtd_info *mtd, u_char *dat,
+ u_char *read_ecc, u_char *calc_ecc)
+{
+ struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
+ int ret;
+ u_long nfeccerr0, nfmeccdata0, nfmeccdata1, err_byte_addr;
+ u_char err_type, repaired;
+
+ /* SLC: Write ECC to compare */
+ nfmeccdata0 = (((u_long) read_ecc[1]) << 16) | read_ecc[0];
+ nfmeccdata1 = (((u_long) read_ecc[3]) << 16) | read_ecc[2];
+ writel(nfmeccdata0, &nand->nfmeccd[0]);
+ writel(nfmeccdata1, &nand->nfmeccd[1]);
+
+ /* Read ECC status */
+ nfeccerr0 = readl(&nand->nfeccerr[0]);
+ err_type = nfeccerr0 & 0x3;
+
+ switch (err_type) {
+ case 0: /* No error */
+ ret = 0;
+ break;
+
+ case 1:
+ /*
+ * 1 bit error (Correctable)
+ * (nfeccerr0 >> 7) & 0x7ff :error byte number
+ * (nfeccerr0 >> 4) & 0x7 :error bit number
+ */
+ err_byte_addr = (nfeccerr0 >> 7) & 0x7ff;
+ repaired = dat[err_byte_addr] ^ (1 << ((nfeccerr0 >> 4) & 0x7));
+
+ printf("S3C24XX NAND: 1 bit error detected at byte %ld. "
+ "Correcting from 0x%02x to 0x%02x\n",
+ err_byte_addr, dat[err_byte_addr], repaired);
+
+ dat[err_byte_addr] = repaired;
+
+ ret = 1;
+ break;
+
+ case 2: /* Multiple error */
+ case 3: /* ECC area error */
+ printf("S3C24XX NAND: ECC uncorrectable error detected.\n");
+ ret = -1;
+ break;
+ }
+
+ return ret;
+}
+#endif /* CONFIG_S3C24XX_NAND_HWECC */
+
+/*
+ * Board-specific NAND initialization.
+ */
+int board_nand_init(struct nand_chip *nand)
+{
+ static int chip_n;
+ struct s3c24xx_nand *const nand_reg = s3c24xx_get_base_nand();
+
+ if (chip_n == 0) {
+ /* Extend NAND timings to the maximum */
+ clrsetbits_le32(&nand_reg->nfconf,
+ NFCONF_TACLS_MASK | NFCONF_TWRPH0_MASK |
+ NFCONF_TWRPH1_MASK,
+ NFCONF_TACLS(7) | NFCONF_TWRPH0(7) |
+ NFCONF_TWRPH1(7));
+
+ /* Disable chip selects and soft lock, enable controller */
+ clrsetbits_le32(&nand_reg->nfcont, NFCONT_WP,
+ NFCONT_NCE1 | NFCONT_NCE0 | NFCONT_ENABLE);
+ } else if (chip_n >= MAX_CHIPS) {
+ return -ENODEV;
+ }
+
+ nand->IO_ADDR_R = &nand_reg->nfdata;
+ nand->IO_ADDR_W = &nand_reg->nfdata;
+ nand->cmd_ctrl = s3c_nand_hwcontrol;
+ nand->dev_ready = s3c_nand_device_ready;
+ nand->select_chip = s3c_nand_select_chip;
+ nand->options = 0;
+#ifdef CONFIG_SPL_BUILD
+ nand->read_buf = nand_read_buf;
+#endif
+
+#ifdef CONFIG_S3C24XX_NAND_HWECC
+ nand->ecc.hwctl = s3c_nand_enable_hwecc;
+ nand->ecc.calculate = s3c_nand_calculate_ecc;
+ nand->ecc.correct = s3c_nand_correct_data;
+ nand->ecc.mode = NAND_ECC_HW_OOB_FIRST;
+ nand->ecc.size = CONFIG_SYS_NAND_ECCSIZE;
+ nand->ecc.bytes = CONFIG_SYS_NAND_ECCBYTES;
+#else
+ nand->ecc.mode = NAND_ECC_SOFT;
+#endif /* ! CONFIG_S3C24XX_NAND_HWECC */
+
+ nand->priv = nand_cs + chip_n++;
+
+ return 0;
+}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
2012-09-14 17:28 [U-Boot] [PATCH v2 00/11] S3C24XX: Add support to MINI2416 board José Miguel Gonçalves
` (8 preceding siblings ...)
2012-09-14 17:29 ` [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver José Miguel Gonçalves
@ 2012-09-14 17:29 ` José Miguel Gonçalves
2012-09-14 18:22 ` Marek Vasut
2012-09-14 19:08 ` Tom Rini
2012-09-14 17:29 ` [U-Boot] [PATCH v2 11/11] S3C24XX: Add support to MINI2416 board José Miguel Gonçalves
10 siblings, 2 replies; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-14 17:29 UTC (permalink / raw)
To: u-boot
Samsung's S3C24XX SoCs need this in order to generate a binary image
with the SPL and U-Boot concatenated.
Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
---
Changes for v2:
- None
---
Makefile | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 058fb53..595b5f6 100644
--- a/Makefile
+++ b/Makefile
@@ -442,13 +442,14 @@ $(obj)u-boot.sha1: $(obj)u-boot.bin
$(obj)u-boot.dis: $(obj)u-boot
$(OBJDUMP) -d $< > $@
-$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
+$(obj)u-boot-ubl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
$(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin
cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > $(obj)u-boot-ubl.bin
+ rm $(obj)spl/u-boot-spl-pad.bin
+
+$(obj)u-boot.ubl: $(obj)u-boot-ubl.bin
$(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \
-e $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin $(obj)u-boot.ubl
- rm $(obj)u-boot-ubl.bin
- rm $(obj)spl/u-boot-spl-pad.bin
$(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
$(obj)tools/mkimage -s -n $(if $(CONFIG_AIS_CONFIG_FILE),$(CONFIG_AIS_CONFIG_FILE),"/dev/null") \
--
1.7.9.5
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 11/11] S3C24XX: Add support to MINI2416 board
2012-09-14 17:28 [U-Boot] [PATCH v2 00/11] S3C24XX: Add support to MINI2416 board José Miguel Gonçalves
` (9 preceding siblings ...)
2012-09-14 17:29 ` [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile José Miguel Gonçalves
@ 2012-09-14 17:29 ` José Miguel Gonçalves
2012-09-14 18:58 ` Tom Rini
10 siblings, 1 reply; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-14 17:29 UTC (permalink / raw)
To: u-boot
The MINI2416 board is based on a Samsung's S3C2416 SoC and has 64MB DDR2 SDRAM,
256MB NAND Flash, a LAN9220 Ethernet Controller and a WM8731 Audio CODEC.
This U-Boot port was implemented and tested on a unit bought to Boardcon
(http://www.armdesigner.com/) but there are some other chinese providers
that can supply it with a selectable NAND chip from 128MB to 1GB.
Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
---
Changes for v2:
- Coding style cleanup
- Use of Use of clrbits_le32(), setbits_le32() and clrsetbits_le32()
- Use of register bit macros instead of magic numbers
- Use of serial and rtc drivers implemented for s3c24x0
---
MAINTAINERS | 4 +
board/boardcon/mini2416/Makefile | 47 ++++++++
board/boardcon/mini2416/config.mk | 4 +
board/boardcon/mini2416/mini2416.c | 98 ++++++++++++++++
board/boardcon/mini2416/mini2416_spl.c | 200 ++++++++++++++++++++++++++++++++
board/boardcon/mini2416/u-boot-spl.lds | 63 ++++++++++
boards.cfg | 1 +
include/configs/mini2416.h | 200 ++++++++++++++++++++++++++++++++
8 files changed, 617 insertions(+)
create mode 100644 board/boardcon/mini2416/Makefile
create mode 100644 board/boardcon/mini2416/config.mk
create mode 100644 board/boardcon/mini2416/mini2416.c
create mode 100644 board/boardcon/mini2416/mini2416_spl.c
create mode 100644 board/boardcon/mini2416/u-boot-spl.lds
create mode 100644 include/configs/mini2416.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 4aabcff..593baa0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -655,6 +655,10 @@ Fabio Estevam <fabio.estevam@freescale.com>
mx53ard i.MX53
mx53smd i.MX53
+Jos? Gon?alves <jose.goncalves@inov.pt>
+
+ mini2416 ARM926EJS (S3C2416 SoC)
+
Daniel Gorsulowski <daniel.gorsulowski@esd.eu>
meesc ARM926EJS (AT91SAM9263 SoC)
diff --git a/board/boardcon/mini2416/Makefile b/board/boardcon/mini2416/Makefile
new file mode 100644
index 0000000..bf92ba1
--- /dev/null
+++ b/board/boardcon/mini2416/Makefile
@@ -0,0 +1,47 @@
+#
+# (C) Copyright 2012 INOV - INESC Inovacao
+# Jose Goncalves <jose.goncalves@inov.pt>
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB = $(obj)lib$(BOARD).o
+
+ifdef CONFIG_SPL_BUILD
+COBJS += mini2416_spl.o
+else
+COBJS += mini2416.o
+endif
+
+SRCS := $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+
+$(LIB): $(obj).depend $(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+#########################################################################
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#########################################################################
diff --git a/board/boardcon/mini2416/config.mk b/board/boardcon/mini2416/config.mk
new file mode 100644
index 0000000..f1230d0
--- /dev/null
+++ b/board/boardcon/mini2416/config.mk
@@ -0,0 +1,4 @@
+PAD_TO := 0x2000
+ifndef CONFIG_SPL_BUILD
+ALL-y += $(obj)u-boot-ubl.bin
+endif
diff --git a/board/boardcon/mini2416/mini2416.c b/board/boardcon/mini2416/mini2416.c
new file mode 100644
index 0000000..e31d2c3
--- /dev/null
+++ b/board/boardcon/mini2416/mini2416.c
@@ -0,0 +1,98 @@
+/*
+ * (C) Copyright 2012 INOV - INESC Inovacao
+ * Jose Goncalves <jose.goncalves@inov.pt>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <common.h>
+#include <netdev.h>
+#include <asm/io.h>
+#include <asm/arch/s3c24xx_cpu.h>
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static void ether_if_init(void)
+{
+ /* Ethernet chip is on memory bank 1 */
+ struct s3c24xx_smc *const smc = s3c24xx_get_base_smc(S3C24XX_SMC1);
+ struct s3c24xx_gpio *const gpio = s3c24xx_get_base_gpio();
+
+ /* Set bus timings */
+ writel(0, &smc->smbidcy); /* Idle Cycle */
+ writel(14, &smc->smbwstwr); /* Write Wait State */
+ writel(2, &smc->smbwstoen); /* Output Enable Assertion Delay */
+ writel(2, &smc->smbwstwen); /* Write Enable Assertion Delay */
+ writel(14, &smc->smbwstrd); /* Read Wait State */
+
+ /* Init SMC control register */
+ clrsetbits_le32(&smc->smbc,
+ (SMBC_RSMAVD_WR | SMBC_RSMAVD_RD | SMBC_MW_MASK |
+ SMBC_WAIT_POL),
+ (SMBC_DRNOWE | SMBC_DRNCS | SMBC_MW_16BIT |
+ SMBC_WAIT_EN | SMBC_RBLE));
+
+ /* Enable CS pin */
+ setbits_le32(&gpio->gpacon, (1 << 12));
+}
+
+int board_init(void)
+{
+ struct s3c24xx_gpio *const gpio = s3c24xx_get_base_gpio();
+
+ /* Turn LED on */
+ clrbits_le32(&gpio->gpcdat, (1 << 5));
+
+ /* Init interface with Ethernet chip */
+ ether_if_init();
+
+ /* Arch number of MINI2416 Board */
+ gd->bd->bi_arch_number = MACH_TYPE_MINI2416;
+
+ /* Address of boot parameters */
+ gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
+
+ return 0;
+}
+
+int dram_init(void)
+{
+ gd->ram_size = get_ram_size((void *)CONFIG_SYS_SDRAM_BASE,
+ CONFIG_SYS_SDRAM_SIZE);
+ return 0;
+}
+
+#ifdef CONFIG_DISPLAY_BOARDINFO
+int checkboard(void)
+{
+ printf("\nBoard: MINI2416\n");
+ return 0;
+}
+#endif
+
+#ifdef CONFIG_CMD_NET
+int board_eth_init(bd_t *bis)
+{
+ int rc = 0;
+#ifdef CONFIG_SMC911X
+ rc = smc911x_initialize(0, CONFIG_SMC911X_BASE);
+#endif
+ return rc;
+}
+#endif
diff --git a/board/boardcon/mini2416/mini2416_spl.c b/board/boardcon/mini2416/mini2416_spl.c
new file mode 100644
index 0000000..ba9bbec
--- /dev/null
+++ b/board/boardcon/mini2416/mini2416_spl.c
@@ -0,0 +1,200 @@
+/*
+ * (C) Copyright 2012 INOV - INESC Inovacao
+ * Jose Goncalves <jose.goncalves@inov.pt>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <common.h>
+#include <version.h>
+#include <nand.h>
+#include <asm/io.h>
+#include <asm/arch/s3c24xx_cpu.h>
+
+/* FCLK = 800 MHz, HCLK = 133 MHz, PCLK = 66 MHz */
+#define M_MDIV 400
+#define M_PDIV 3
+#define M_SDIV 1
+#define ARMDIV 1
+#define PREDIV 2
+#define HCLKDIV 1
+
+/* EPLLclk = 96MHz */
+#define E_MDIV 32
+#define E_PDIV 1
+#define E_SDIV 2
+
+DECLARE_GLOBAL_DATA_PTR;
+static gd_t gdata;
+
+inline void hang(void)
+{
+ serial_puts("### ERROR ### Please RESET the board ###\n");
+ for (;;)
+ /* NOP */;
+}
+
+static inline void asm_delay(ulong loops)
+{
+ asm volatile ("1:\n" "subs %0, %1, #1\n"
+ "bne 1b" : "=r" (loops) : "0"(loops));
+}
+
+static inline void watchdog_disable(void)
+{
+ struct s3c24xx_watchdog *const watchdog = s3c24xx_get_base_watchdog();
+
+ writel(0, &watchdog->wtcon);
+}
+
+static void pinmux_init(void)
+{
+ struct s3c24xx_gpio *const gpio = s3c24xx_get_base_gpio();
+
+ /* Init LED pin and turn LED off */
+ clrsetbits_le32(&gpio->gpccon, (0x3 << 10), (0x1 << 10));
+ setbits_le32(&gpio->gpcdat, (1 << 5));
+
+ /* Init UART pins */
+ writel(0x0000AAAA, &gpio->gphcon);
+
+ /* Init NAND interface */
+ setbits_le32(&gpio->gpacon, (0x3F << 17));
+}
+
+static void pll_init(void)
+{
+ struct s3c2416_sysctl *const sysctl = s3c2416_get_base_sysctl();
+
+ /* Configure clocks division ratio */
+ clrsetbits_le32(&sysctl->clkdiv0,
+ CLKDIV0_ARMDIV_MASK | CLKDIV0_PREDIV_MASK |
+ CLKDIV0_HCLKDIV_MASK,
+ CLKDIV0_ARMDIV(ARMDIV) | CLKDIV0_PREDIV(PREDIV) |
+ CLKDIV0_HALFHCLK | CLKDIV0_PCLKDIV |
+ CLKDIV0_HCLKDIV(HCLKDIV));
+
+ /* Set MPLL lock time */
+ writel(0x0E10, &sysctl->lockcon0);
+
+ /* Configure MPLL */
+ writel(MPLLCON_MDIV(M_MDIV) | MPLLCON_PDIV(M_PDIV) |
+ MPLLCON_SDIV(M_SDIV), &sysctl->mpllcon);
+
+ /* Set EPLL lock time */
+ writel(0x1780, &sysctl->lockcon1);
+
+ /* Configure EPLL */
+ writel(EPLLCON_MDIV(E_MDIV) | EPLLCON_PDIV(E_PDIV) |
+ EPLLCON_SDIV(E_SDIV), &sysctl->epllcon);
+
+ /* MSYSCLK = MPLL and ESYSCLK = EPLL */
+ setbits_le32(&sysctl->clksrc,
+ CLKSRC_MSYSCLK_MPLL | CLKSRC_ESYSCLK_EPLL);
+}
+
+static void dramctl_init(void)
+{
+ struct s3c24xx_dramctl *const dramctl = s3c24xx_get_base_dramctl();
+
+ /* Step 1: Init BANKCFG & BANKCON1 */
+ writel(BANKCFG_VAL_DDR2, &dramctl->bankcfg);
+ writel(BANKCON1_VAL_DDR2, &dramctl->bankcon1);
+
+ /* Step 2: Init BANKCON2 */
+ writel(BANKCON2_VAL_DDR2, &dramctl->bankcon2);
+
+ /* Step 3: Issue a PALL command */
+ writel(BANKCON1_VAL_DDR2 | BANKCON1_INIT_PALL, &dramctl->bankcon1);
+
+ /* Step 4: Issue a EMRS2 command */
+ writel(BANKCON3_VAL_EMRS2, &dramctl->bankcon3);
+ writel(BANKCON1_VAL_DDR2 | BANKCON1_INIT_EMRS, &dramctl->bankcon1);
+
+ /* Step 5: Issue a EMRS3 command */
+ writel(BANKCON3_VAL_EMRS3, &dramctl->bankcon3);
+ writel(BANKCON1_VAL_DDR2 | BANKCON1_INIT_EMRS, &dramctl->bankcon1);
+
+ /* Step 6: Issue a EMRS1 command */
+ writel(BANKCON3_VAL_EMRS1, &dramctl->bankcon3);
+ writel(BANKCON1_VAL_DDR2 | BANKCON1_INIT_EMRS, &dramctl->bankcon1);
+
+ /* Step 7: Issue a MRS command */
+ writel(BANKCON3_VAL_MRS | BANKCON3_MRS_DLL_RESET, &dramctl->bankcon3);
+ writel(BANKCON1_VAL_DDR2 | BANKCON1_INIT_MRS, &dramctl->bankcon1);
+
+ /* Step 8: Issue a PALL command */
+ writel(BANKCON1_VAL_DDR2 | BANKCON1_INIT_PALL, &dramctl->bankcon1);
+
+ /* Step 9: Write 0xFF into the refresh timer */
+ writel(0xFF, &dramctl->refresh);
+
+ /* Step 10: Wait more than 120 clocks */
+ asm_delay(256);
+
+ /* Step 11: Issue a MRS command */
+ writel(BANKCON3_VAL_MRS, &dramctl->bankcon3);
+ writel(BANKCON1_VAL_DDR2 | BANKCON1_INIT_MRS, &dramctl->bankcon1);
+
+ /* Step 12: Issue a EMRS1 command */
+ writel(BANKCON3_VAL_EMRS1 | BANKCON3_EMRS1_OCD7 | BANKCON3_EMRS1_CAS3,
+ &dramctl->bankcon3);
+ writel(BANKCON1_VAL_DDR2 | BANKCON1_INIT_EMRS, &dramctl->bankcon1);
+
+ writel(BANKCON3_VAL_EMRS1 | BANKCON3_EMRS1_CAS3, &dramctl->bankcon3);
+ writel(BANKCON1_VAL_DDR2 | BANKCON1_INIT_EMRS, &dramctl->bankcon1);
+
+ /* Step 13: Write 0x87 into the refresh timer */
+ writel(0x87, &dramctl->refresh);
+
+ /* Step 14: Normal Mode */
+ writel(BANKCON1_VAL_DDR2 | BANKCON1_INIT_NORMAL, &dramctl->bankcon1);
+}
+
+void board_init_f(ulong bootflag)
+{
+ watchdog_disable();
+ pinmux_init();
+ pll_init();
+
+ /*
+ * We call relocate_code() with relocation target set to the SPL entry
+ * point. This will result in relocation getting skipped and only .bss
+ * initialization is performed before jumping to board_init_r().
+ */
+ relocate_code(CONFIG_SPL_STACK, &gdata, CONFIG_SPL_TEXT_BASE);
+}
+
+void board_init_r(gd_t *id, ulong dest_addr)
+{
+ gd = id;
+ gd->baudrate = CONFIG_BAUDRATE;
+ serial_init();
+
+ /* Print U-Boot SPL version string */
+ serial_puts("\n\nU-Boot SPL " PLAIN_VERSION);
+ serial_puts(" (" U_BOOT_DATE " - " U_BOOT_TIME ")\n");
+
+ dramctl_init();
+ nand_init();
+
+ serial_puts("Loading U-Boot from NAND Flash...\n");
+
+ nand_boot();
+}
diff --git a/board/boardcon/mini2416/u-boot-spl.lds b/board/boardcon/mini2416/u-boot-spl.lds
new file mode 100644
index 0000000..d339b0d
--- /dev/null
+++ b/board/boardcon/mini2416/u-boot-spl.lds
@@ -0,0 +1,63 @@
+/*
+ * (C) Copyright 2012 INOV - INESC Inovacao
+ * Jose Goncalves <jose.goncalves@inov.pt>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+MEMORY { .iram : ORIGIN = CONFIG_SPL_TEXT_BASE, \
+ LENGTH = CONFIG_SPL_MAX_SIZE }
+MEMORY { .sram : ORIGIN = CONFIG_SPL_BSS_START_ADDR, \
+ LENGTH = CONFIG_SPL_BSS_MAX_SIZE }
+
+OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
+OUTPUT_ARCH(arm)
+ENTRY(_start)
+SECTIONS
+{
+ .text :
+ {
+ CPUDIR/start.o (.text)
+ *(.text*)
+ } > .iram
+
+ . = ALIGN(4);
+ .rodata :
+ {
+ *(SORT_BY_ALIGNMENT(.rodata*))
+ } > .iram
+
+ . = ALIGN(4);
+ .data :
+ {
+ *(SORT_BY_ALIGNMENT(.data*))
+ } > .iram
+
+ . = ALIGN(4);
+ _end = .;
+
+ .bss :
+ {
+ . = ALIGN(4);
+ __bss_start = .;
+ *(.bss*)
+ . = ALIGN(4);
+ __bss_end__ = .;
+ } >.sram
+}
diff --git a/boards.cfg b/boards.cfg
index 72e7803..bf084a0 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -193,6 +193,7 @@ omap730p2_cs0boot arm arm926ejs omap730p2 ti omap
omap730p2_cs3boot arm arm926ejs omap730p2 ti omap omap730p2:CS3_BOOT
edminiv2 arm arm926ejs - LaCie orion5x
dkb arm arm926ejs - Marvell pantheon
+mini2416 arm arm926ejs mini2416 boardcon s3c24xx
spear300 arm arm926ejs spear300 spear spear spear3xx_evb:spear300
spear300_nand arm arm926ejs spear300 spear spear spear3xx_evb:spear300,nand
spear300_usbtty arm arm926ejs spear300 spear spear spear3xx_evb:spear300,usbtty
diff --git a/include/configs/mini2416.h b/include/configs/mini2416.h
new file mode 100644
index 0000000..406a7e6
--- /dev/null
+++ b/include/configs/mini2416.h
@@ -0,0 +1,200 @@
+/*
+ * (C) Copyright 2012 INOV - INESC Inovacao
+ * Jose Goncalves <jose.goncalves@inov.pt>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+/*
+ * SoC Configuration
+ */
+#define CONFIG_ARM926EJS /* ARM926EJS CPU Core */
+#define CONFIG_S3C24XX /* SAMSUNG S3C24XX Family */
+#define CONFIG_S3C2416 /* SAMSUNG S3C2416 SoC */
+#define CONFIG_SYS_CLK_FREQ 12000000
+#define CONFIG_SYS_HZ 1000
+
+/*
+ * Memory Information
+ */
+#define CONFIG_SYS_IRAM_BASE 0x00000000 /* Steppingstone base address */
+#define CONFIG_SYS_IRAM_SIZE (8 << 10) /* 8KB of Steppingstone */
+#define CONFIG_SYS_IRAM_END (CONFIG_SYS_IRAM_BASE + CONFIG_SYS_IRAM_SIZE)
+
+#define CONFIG_SYS_SRAM_BASE 0x00002000 /* SRAM base address */
+#define CONFIG_SYS_SRAM_SIZE (56 << 10) /* 56KB of SRAM */
+#define CONFIG_SYS_SRAM_END (CONFIG_SYS_SRAM_BASE + CONFIG_SYS_SRAM_SIZE)
+
+#define CONFIG_SYS_SDRAM_BASE 0x30000000 /* DDR2 SDRAM base address */
+#define CONFIG_SYS_SDRAM_SIZE (64 << 20) /* 64MB of DDR2 SDRAM */
+#define CONFIG_SYS_SDRAM_END (CONFIG_SYS_SDRAM_BASE + CONFIG_SYS_SDRAM_SIZE)
+
+/*
+ * Linux Interface
+ */
+#define MACH_TYPE_MINI2416 3850
+#define CONFIG_MACH_TYPE MACH_TYPE_MINI2416
+#define CONFIG_CMDLINE_TAG
+#define CONFIG_SETUP_MEMORY_TAGS
+#define CONFIG_BOOTDELAY 3
+#define CONFIG_BOOTARGS "console=ttySAC3,115200n8"
+#define CONFIG_BOOTCOMMAND "" /* TBD */
+
+/*
+ * SPL
+ */
+#define CONFIG_SPL
+#define CONFIG_SPL_SERIAL_SUPPORT
+#define CONFIG_SPL_NAND_SUPPORT
+#define CONFIG_SPL_NAND_SIMPLE
+#define CONFIG_SPL_NAND_LOAD
+#define CONFIG_SPL_TEXT_BASE 0x00000000 /* CONFIG_SYS_IRAM_BASE */
+#define CONFIG_SPL_MAX_SIZE CONFIG_SYS_IRAM_SIZE
+#define CONFIG_SPL_BSS_START_ADDR CONFIG_SYS_SRAM_BASE
+#define CONFIG_SPL_BSS_MAX_SIZE (CONFIG_SYS_SRAM_SIZE - (8 << 10))
+#define CONFIG_SPL_STACK CONFIG_SYS_SRAM_END /* 8KB for stack */
+
+/*
+ * Monitor Interface
+ */
+#define CONFIG_SYS_PROMPT "MINI2416 # "
+#define CONFIG_SYS_LONGHELP
+#define CONFIG_SYS_CBSIZE 1024
+#define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + \
+ sizeof(CONFIG_SYS_PROMPT) + 16)
+#define CONFIG_SYS_MAXARGS 16
+#define CONFIG_CMDLINE_EDITING
+
+/*
+ * Command Definition
+ */
+#define CONFIG_SYS_NO_FLASH /* No NOR Flash */
+#include <config_cmd_default.h>
+#define CONFIG_CMD_CACHE
+#define CONFIG_CMD_DATE
+#define CONFIG_CMD_DHCP
+#define CONFIG_CMD_MISC
+#define CONFIG_CMD_NAND
+#define CONFIG_CMD_PING
+
+/*
+ * Miscellaneous Settings
+ */
+#define CONFIG_SKIP_LOWLEVEL_INIT
+#define CONFIG_DISPLAY_CPUINFO
+#define CONFIG_DISPLAY_BOARDINFO
+#define CONFIG_NR_DRAM_BANKS 1
+#define CONFIG_SYS_LOAD_ADDR (CONFIG_SYS_SDRAM_BASE + (1 << 20))
+#define CONFIG_SYS_MONITOR_BASE (CONFIG_SYS_SDRAM_END - (1 << 20))
+#define CONFIG_SYS_MONITOR_LEN (256 << 10)
+#define CONFIG_SYS_TEXT_BASE 0x33F00000 /* CONFIG_SYS_MONITOR_BASE */
+#define CONFIG_SYS_MALLOC_LEN (384 << 10)
+#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SRAM_END - \
+ GENERATED_GBL_DATA_SIZE)
+#define CONFIG_SYS_ALT_MEMTEST
+#define CONFIG_SYS_MEMTEST_START CONFIG_SYS_SDRAM_BASE
+#define CONFIG_SYS_MEMTEST_END CONFIG_SYS_MONITOR_BASE
+
+/*
+ * NAND Flash
+ */
+#ifdef CONFIG_CMD_NAND
+
+#define CONFIG_NAND_S3C24XX
+#define CONFIG_S3C24XX_NAND_HWECC
+#define CONFIG_SYS_NAND_BASE 0x4E000010
+#define CONFIG_SYS_MAX_NAND_DEVICE 1
+
+/* SPL NAND Driver */
+#define CONFIG_SYS_NAND_PAGE_SIZE (2 << 10)
+#define CONFIG_SYS_NAND_BLOCK_SIZE (128 << 10)
+#define CONFIG_SYS_NAND_PAGE_COUNT (CONFIG_SYS_NAND_BLOCK_SIZE / \
+ CONFIG_SYS_NAND_PAGE_SIZE)
+#define CONFIG_SYS_NAND_OOBSIZE 64
+#define CONFIG_SYS_NAND_ECCSIZE 512
+#define CONFIG_SYS_NAND_ECCBYTES 4
+#define CONFIG_SYS_NAND_ECCPOS {40, 41, 42, 43, 44, 45, 46, 47, \
+ 48, 49, 50, 51, 52, 53, 54, 55}
+#define CONFIG_SYS_NAND_BAD_BLOCK_POS 0
+#define CONFIG_SYS_NAND_HW_ECC_OOBFIRST
+#define CONFIG_SYS_NAND_5_ADDR_CYCLE
+#define CONFIG_SYS_NAND_U_BOOT_DST CONFIG_SYS_TEXT_BASE
+#define CONFIG_SYS_NAND_U_BOOT_START CONFIG_SYS_NAND_U_BOOT_DST
+#define CONFIG_SYS_NAND_U_BOOT_OFFS CONFIG_SPL_MAX_SIZE
+#define CONFIG_SYS_NAND_U_BOOT_SIZE (CONFIG_SYS_MONITOR_LEN - \
+ CONFIG_SPL_MAX_SIZE)
+
+#endif
+
+/*
+ * Serial Driver
+ */
+#define CONFIG_S3C24X0_SERIAL
+#define CONFIG_SERIAL3
+#define CONFIG_BAUDRATE 115200
+#define CONFIG_SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200 }
+
+/*
+ * Ethernet
+ */
+#ifdef CONFIG_CMD_NET
+#define CONFIG_SMC911X
+#define CONFIG_SMC911X_BASE 0x08000000
+#define CONFIG_SMC911X_16_BIT
+#define CONFIG_ETHADDR FE:11:22:33:44:55
+#define CONFIG_OVERWRITE_ETHADDR_ONCE
+#define CONFIG_IPADDR 192.168.0.10
+#define CONFIG_NETMASK 255.255.255.0
+#define CONFIG_SERVERIP 192.168.0.1
+#define CONFIG_GATEWAYIP 192.168.0.1
+#endif
+
+/*
+ * RTC
+ */
+#ifdef CONFIG_CMD_DATE
+#define CONFIG_RTC_S3C24X0
+#endif
+
+/*
+ * Environment
+ */
+#ifdef CONFIG_CMD_NAND
+#define CONFIG_ENV_IS_IN_NAND
+#define CONFIG_ENV_SIZE CONFIG_SYS_NAND_BLOCK_SIZE
+#define CONFIG_ENV_OFFSET CONFIG_SYS_MONITOR_LEN
+#define CONFIG_ENV_SIZE_REDUND CONFIG_ENV_SIZE
+#define CONFIG_ENV_OFFSET_REDUND (CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE)
+#else
+#define CONFIG_ENV_IS_NOWHERE
+#endif
+
+/*
+ * File System
+ */
+#ifdef CONFIG_CMD_NAND
+#define CONFIG_CMD_MTDPARTS
+#define CONFIG_MTD_DEVICE
+#define CONFIG_MTD_PARTITIONS
+#endif
+
+#endif /* __CONFIG_H */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 02/11] S3C24XX: Add core support for Samsung's S3C24XX SoCs
2012-09-14 17:28 ` [U-Boot] [PATCH v2 02/11] S3C24XX: Add core support for Samsung's S3C24XX SoCs José Miguel Gonçalves
@ 2012-09-14 18:03 ` Marek Vasut
[not found] ` <505375E3.6050005@inov.pt>
2012-09-14 18:39 ` Tom Rini
1 sibling, 1 reply; 84+ messages in thread
From: Marek Vasut @ 2012-09-14 18:03 UTC (permalink / raw)
To: u-boot
Dear Jos? Miguel Gon?alves,
It's getting better :)
[...]
> +
> +typedef ulong(*getfreq) (void);
Is this used?
> +static const getfreq freq_f[] = {
const array const members, no?
> + get_FCLK,
> + get_HCLK,
> + get_PCLK,
> + get_UCLK,
> +};
> +
> +static const char freq_c[] = { 'F', 'H', 'P', 'U' };
Same here.
> +int print_cpuinfo(void)
> +{
> + int i;
> + char buf[32];
> + ulong cpuid;
> + struct s3c24xx_gpio *const gpio = s3c24xx_get_base_gpio();
> +
> + cpuid = readl(&gpio->gstatus[1]);
> + printf("CPU: %8s (id %08lX) @ %s MHz\n", s3c24xx_get_cpu_name(),
> + cpuid, strmhz(buf, get_ARMCLK()));
> + for (i = 0; i < ARRAY_SIZE(freq_f); i++)
> + printf("%cCLK: %8s MHz\n", freq_c[i],
> + strmhz(buf, freq_f[i] ()));
> +
> + return 0;
> +}
[...]
> +ulong get_HCLK(void)
> +{
> + struct s3c2412_sysctl *const sysctl = s3c2412_get_base_sysctl();
> + u32 clkdivn;
> + u16 hclk_div, arm_div;
> +
> + clkdivn = readl(&sysctl->clkdivn);
> + hclk_div = (clkdivn & 0x3) + 1;
> + arm_div = ((clkdivn >> 3) & 0x1) + 1;
Magic.
> + return get_FCLK() / (hclk_div * arm_div);
> +}
> +
> +/* return PCLK frequency */
> +ulong get_PCLK(void)
> +{
> + struct s3c2412_sysctl *const sysctl = s3c2412_get_base_sysctl();
> + u32 clkdivn;
> +
> + clkdivn = readl(&sysctl->clkdivn);
> +
> + return (clkdivn & 0x4) ? get_HCLK() / 2 : get_HCLK();
Magic
> +}
> +
> +/* return UCLK frequency */
> +ulong get_UCLK(void)
> +{
> + return get_PLLCLK(UPLL);
> +}
> +
> +/* return ARMCORE frequency */
> +ulong get_ARMCLK(void)
> +{
> + struct s3c2412_sysctl *const sysctl = s3c2412_get_base_sysctl();
> + u32 clkdivn;
> +
> + clkdivn = readl(&sysctl->clkdivn);
> + if (clkdivn & 0x10)
> + return get_FCLK();
Magic above and below and in the following file
> + return (clkdivn & 0x8) ? get_FCLK() / 2 : get_FCLK();
> +}
[...]
> diff --git a/arch/arm/cpu/arm926ejs/s3c24xx/timer.c
> b/arch/arm/cpu/arm926ejs/s3c24xx/timer.c new file mode 100644
> index 0000000..23d3343
> --- /dev/null
> +++ b/arch/arm/cpu/arm926ejs/s3c24xx/timer.c
> @@ -0,0 +1,152 @@
> +/*
> + * (C) Copyright 2012 INOV - INESC Inovacao
> + * Jose Goncalves <jose.goncalves@inov.pt>
> + *
> + * Based on arch/arm/cpu/armv7/s5p-common/timer.c and U-Boot 1.3.4 from
> Samsung. + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#include <common.h>
> +#include <asm/io.h>
> +#include <asm/arch/s3c24xx_cpu.h>
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +static ulong get_current_tick(void)
> +{
> + struct s3c24xx_timers *const timers = s3c24xx_get_base_timers();
> + ulong now = readl(&timers->tcnto4);
> +
> + if (gd->lastinc >= now)
> + gd->tbl += gd->lastinc - now;
> + else
> + gd->tbl += gd->lastinc + gd->tbu - now;
> +
> + gd->lastinc = now;
> +
> + return gd->tbl;
> +}
> +
> +int timer_init(void)
> +{
> + struct s3c24xx_timers *const timers = s3c24xx_get_base_timers();
> +
> + /* use PWM Timer 4 because it has no output */
> + if (gd->tbu == 0) {
> + /* set divider value for Timer 4 to 2 */
> + clrsetbits_le32(&timers->tcfg1, TCFG1_MUX4_MASK,
> + TCFG1_MUX4_DIV2);
> + /* set prescaler value for Timer 4 to 15 */
> + clrsetbits_le32(&timers->tcfg0, TCFG0_PRESCALER1_MASK,
> + TCFG0_PRESCALER1(15));
> + /*
> + * Timer Freq(HZ) =
> + * PCLK / (prescaler_value + 1) / (divider_value)
> + */
> + gd->timer_rate_hz = get_PCLK() / (15 + 1) / 2;
> + gd->tbu = gd->timer_rate_hz / CONFIG_SYS_HZ;
> + }
> + /* load value for selected timeout */
> + writel(gd->tbu, &timers->tcntb4);
> + /* auto reload, manual update of timer 4 */
> + clrsetbits_le32(&timers->tcon, TCON_T4START,
> + TCON_T4RELOAD | TCON_T4MANUALUPD);
> + /* auto reload, start timer 4 */
> + clrsetbits_le32(&timers->tcon, TCON_T4MANUALUPD,
> + TCON_T4RELOAD | TCON_T4START);
> + gd->lastinc = 0;
> + gd->tbl = 0;
> +
> + return 0;
> +}
> +
> +ulong get_timer(ulong base)
> +{
> + return get_timer_masked() - base;
> +}
> +
> +void __udelay(unsigned long usec)
> +{
> + ulong tmo, tmp;
> +
> + if (usec >= 1000) {
> + /*
> + * if "big" number, spread normalization
> + * to seconds
> + * 1. start to normalize for usec to ticks per sec
> + * 2. find number of "ticks" to wait to achieve target
> + * 3. finish normalize.
> + */
> + tmo = usec / 1000;
> + tmo *= gd->timer_rate_hz;
> + tmo /= 1000;
> + } else {
> + /* else small number, don't kill it prior to HZ multiply */
> + tmo = usec * gd->timer_rate_hz;
> + tmo /= (1000 * 1000);
> + }
> +
> + /* get current timestamp */
> + tmp = get_current_tick();
> +
> + /* if setting this fordward will roll time stamp */
> + /* reset "advancing" timestamp to 0, set lastinc value */
> + /* else, set advancing stamp wake up time */
/*
* multi
* line
* comment
*/
> + if ((tmo + tmp + 1) < tmp)
> + reset_timer_masked();
> + else
> + tmo += tmp;
> +
> + /* loop till event */
> + while (get_current_tick() < tmo)
> + /* NOP */;
> +}
> +
> +void reset_timer_masked(void)
> +{
> + struct s3c24xx_timers *const timers = s3c24xx_get_base_timers();
> +
> + /* reset time */
> + gd->lastinc = readl(&timers->tcnto4);
> + gd->tbl = 0;
> +}
> +
> +ulong get_timer_masked(void)
> +{
> + return get_current_tick() / gd->tbu;
> +}
> +
> +/*
> + * This function is derived from PowerPC code (read timebase as long
> long). + * On ARM it just returns the timer value.
> + */
> +unsigned long long get_ticks(void)
> +{
> + return get_timer_masked();
> +}
> +
> +/*
> + * This function is derived from PowerPC code (timebase clock frequency).
> + * On ARM it returns the number of timer ticks per second.
> + */
> +ulong get_tbclk(void)
> +{
> + return CONFIG_SYS_HZ;
> +}
[...]
> diff --git a/include/common.h b/include/common.h
> index 55025c0..36f0636 100644
> --- a/include/common.h
> +++ b/include/common.h
> @@ -628,6 +628,7 @@ ulong get_OPB_freq (void);
> ulong get_PCI_freq (void);
> #endif
> #if defined(CONFIG_S3C24X0) || \
> + defined(CONFIG_S3C24XX) || \
> defined(CONFIG_LH7A40X) || \
> defined(CONFIG_S3C6400) || \
> defined(CONFIG_EP93XX)
What's this change? Split into different patch please.
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 04/11] serial: Use a more precise baud rate generation for serial_s3c24x0
2012-09-14 17:28 ` [U-Boot] [PATCH v2 04/11] serial: Use a more precise baud rate generation for serial_s3c24x0 José Miguel Gonçalves
@ 2012-09-14 18:05 ` Marek Vasut
0 siblings, 0 replies; 84+ messages in thread
From: Marek Vasut @ 2012-09-14 18:05 UTC (permalink / raw)
To: u-boot
Dear Jos? Miguel Gon?alves,
> Program udivslot register in order to obtain a more precise baudrate.
More explanatory commit message would be nice.
[...]
> +static const int udivslot[] = {
const array const members, no ?
> + 0x0000, 0x0080, 0x0808, 0x0888, 0x2222, 0x4924, 0x4A52, 0x54AA,
> + 0x5555, 0xD555, 0xD5D5, 0xDDD5, 0xDDDD, 0xDFDD, 0xDFDF, 0xFFDF,
> +};
> +
> void _serial_setbrg(const int dev_index)
> {
> struct s3c24x0_uart *uart = s3c24x0_get_base_uart(dev_index);
> - unsigned int reg = 0;
> + u32 pclk;
> + u32 baudrate;
> int i;
>
> - /* value is calculated so : (int)(PCLK/16./baudrate) -1 */
> - reg = get_PCLK() / (16 * gd->baudrate) - 1;
> + pclk = get_PCLK();
> + baudrate = gd->baudrate;
>
> - writel(reg, &uart->ubrdiv);
> + writel((pclk / baudrate / 16) - 1, &uart->ubrdiv);
> + writel(udivslot[(pclk / baudrate) % 16], &uart->udivslot);
> for (i = 0; i < 100; i++)
> /* Delay */ ;
> }
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 05/11] serial: Remove unnecessary delay in serial_s3c24x0
2012-09-14 17:28 ` [U-Boot] [PATCH v2 05/11] serial: Remove unnecessary delay in serial_s3c24x0 José Miguel Gonçalves
@ 2012-09-14 18:05 ` Marek Vasut
0 siblings, 0 replies; 84+ messages in thread
From: Marek Vasut @ 2012-09-14 18:05 UTC (permalink / raw)
To: u-boot
Dear Jos? Miguel Gon?alves,
> The loop used to make a delay after baudrate setting is not necessary.
> Moreover it is removed by the GCC optimizer (at least with GCC 4.6).
>
> Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
Acked-by: Marek Vasut <marex@denx.de>
> ---
> Changes for v2:
> - New patch
> ---
> drivers/serial/serial_s3c24x0.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/serial/serial_s3c24x0.c
> b/drivers/serial/serial_s3c24x0.c index c9bc121..ec5d1cb 100644
> --- a/drivers/serial/serial_s3c24x0.c
> +++ b/drivers/serial/serial_s3c24x0.c
> @@ -111,15 +111,12 @@ void _serial_setbrg(const int dev_index)
> struct s3c24x0_uart *uart = s3c24x0_get_base_uart(dev_index);
> u32 pclk;
> u32 baudrate;
> - int i;
>
> pclk = get_PCLK();
> baudrate = gd->baudrate;
>
> writel((pclk / baudrate / 16) - 1, &uart->ubrdiv);
> writel(udivslot[(pclk / baudrate) % 16], &uart->udivslot);
> - for (i = 0; i < 100; i++)
> - /* Delay */ ;
> }
>
> #if defined(CONFIG_SERIAL_MULTI)
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 06/11] rtc: Improve rtc_get() on s3c24x0_rtc
2012-09-14 17:28 ` [U-Boot] [PATCH v2 06/11] rtc: Improve rtc_get() on s3c24x0_rtc José Miguel Gonçalves
@ 2012-09-14 18:06 ` Marek Vasut
0 siblings, 0 replies; 84+ messages in thread
From: Marek Vasut @ 2012-09-14 18:06 UTC (permalink / raw)
To: u-boot
Dear Jos? Miguel Gon?alves,
> A better approach to avoid reading the RTC during updates, as sugested in
> the S3C2416 User's Manual.
>
> Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
> ---
> Changes for v2:
> - New patch
> ---
> drivers/rtc/s3c24x0_rtc.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/rtc/s3c24x0_rtc.c b/drivers/rtc/s3c24x0_rtc.c
> index c16ff2e..7d04b74 100644
> --- a/drivers/rtc/s3c24x0_rtc.c
> +++ b/drivers/rtc/s3c24x0_rtc.c
> @@ -65,20 +65,26 @@ int rtc_get(struct rtc_time *tmp)
> uchar sec, min, hour, mday, wday, mon, year;
> __maybe_unused uchar a_sec, a_min, a_hour, a_date,
> a_mon, a_year, a_armed;
> + int have_retried = 0;
>
> /* enable access to RTC registers */
> SetRTC_Access(RTC_ENABLE);
>
> /* read RTC registers */
> do {
> - sec = readb(&rtc->bcdsec);
> min = readb(&rtc->bcdmin);
> hour = readb(&rtc->bcdhour);
> mday = readb(&rtc->bcddate);
> wday = readb(&rtc->bcdday);
> mon = readb(&rtc->bcdmon);
> year = readb(&rtc->bcdyear);
> - } while (sec != readb(&rtc->bcdsec));
> + sec = readb(&rtc->bcdsec);
> + /*
> + * The only way to work out whether the RTC was mid-update
> + * when we read it is to check the seconds counter.
> + * If it's zero, then we re-try the entire read.
> + */
> + } while ((sec == 0) && !(have_retried++));
You don't need that parens around (have_retried++)
>
> /* read ALARM registers */
> a_sec = readb(&rtc->almsec);
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 07/11] rtc: Fix rtc_reset() on s3c24x0_rtc
2012-09-14 17:28 ` [U-Boot] [PATCH v2 07/11] rtc: Fix rtc_reset() " José Miguel Gonçalves
@ 2012-09-14 18:07 ` Marek Vasut
0 siblings, 0 replies; 84+ messages in thread
From: Marek Vasut @ 2012-09-14 18:07 UTC (permalink / raw)
To: u-boot
Dear Jos? Miguel Gon?alves,
> rtc_reset() must set the RTC date to the UNIX Epoch.
Acked-by: Marek Vasut <marex@denx.de>
> Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
> ---
> Changes for v2:
> - New patch
> ---
> drivers/rtc/s3c24x0_rtc.c | 15 +++++++++++----
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/rtc/s3c24x0_rtc.c b/drivers/rtc/s3c24x0_rtc.c
> index 7d04b74..54bf6e3 100644
> --- a/drivers/rtc/s3c24x0_rtc.c
> +++ b/drivers/rtc/s3c24x0_rtc.c
> @@ -167,10 +167,17 @@ int rtc_set(struct rtc_time *tmp)
>
> void rtc_reset(void)
> {
> - struct s3c24x0_rtc *rtc = s3c24x0_get_base_rtc();
> -
> - writeb((readb(&rtc->rtccon) & ~0x06) | 0x08, &rtc->rtccon);
> - writeb(readb(&rtc->rtccon) & ~(0x08 | 0x01), &rtc->rtccon);
> + static struct rtc_time tmp = {
> + .tm_year = 1970,
> + .tm_mon = 1,
> + .tm_mday = 1,
> + .tm_wday = 4,
> + .tm_hour = 0,
> + .tm_min = 0,
> + .tm_sec = 0,
> + };
> +
> + rtc_set(&tmp);
> }
>
> #endif
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 08/11] rtc: Don't allow setting unsuported years on s3c24x0_rtc
2012-09-14 17:28 ` [U-Boot] [PATCH v2 08/11] rtc: Don't allow setting unsuported years " José Miguel Gonçalves
@ 2012-09-14 18:08 ` Marek Vasut
0 siblings, 0 replies; 84+ messages in thread
From: Marek Vasut @ 2012-09-14 18:08 UTC (permalink / raw)
To: u-boot
Dear Jos? Miguel Gon?alves,
> This RTC only supports a 100 years range so rtc_set() should not allow
> setting years bellow 1970 or above 2069.
Acked-by: Marek Vasut <marex@denx.de>
> Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
> ---
> Changes for v2:
> - New patch
> ---
> drivers/rtc/s3c24x0_rtc.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/rtc/s3c24x0_rtc.c b/drivers/rtc/s3c24x0_rtc.c
> index 54bf6e3..f96cb11 100644
> --- a/drivers/rtc/s3c24x0_rtc.c
> +++ b/drivers/rtc/s3c24x0_rtc.c
> @@ -139,6 +139,11 @@ int rtc_set(struct rtc_time *tmp)
> tmp->tm_year, tmp->tm_mon, tmp->tm_mday, tmp->tm_wday,
> tmp->tm_hour, tmp->tm_min, tmp->tm_sec);
> #endif
> + if (tmp->tm_year < 1970 || tmp->tm_year > 2069) {
> + puts("ERROR: year should be between 1970 and 2069!\n");
> + return -1;
> + }
> +
> year = bin2bcd(tmp->tm_year % 100);
> mon = bin2bcd(tmp->tm_mon);
> wday = bin2bcd(tmp->tm_wday);
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
2012-09-14 17:29 ` [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver José Miguel Gonçalves
@ 2012-09-14 18:21 ` Marek Vasut
2012-09-14 18:45 ` José Miguel Gonçalves
` (2 more replies)
2012-09-14 18:47 ` Tom Rini
1 sibling, 3 replies; 84+ messages in thread
From: Marek Vasut @ 2012-09-14 18:21 UTC (permalink / raw)
To: u-boot
Dear Jos? Miguel Gon?alves,
> NAND Flash driver with HW ECC for the S3C24XX SoCs.
> Currently it only supports SLC NAND chips.
>
> Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
[...]
> +#include <common.h>
> +#include <nand.h>
> +#include <asm/io.h>
> +#include <asm/arch/s3c24xx_cpu.h>
> +#include <asm/errno.h>
> +
> +#define MAX_CHIPS 2
> +static int nand_cs[MAX_CHIPS] = { 0, 1 };
> +
> +#ifdef CONFIG_SPL_BUILD
> +#define printf(arg...) do {} while (0)
This doesn't seem quite right ...
1) this should be in CPU directory
2) should be enabled only if CONFIG_SPL_SERIAL_SUPPORT is not set
3) should be inline function, not a macro
> +#endif
> +
> +static void s3c_nand_select_chip(struct mtd_info *mtd, int chip)
> +{
> + struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
> + u_long nfcont;
> +
> + nfcont = readl(&nand->nfcont);
> +
> + switch (chip) {
> + case -1:
> + nfcont |= NFCONT_NCE1 | NFCONT_NCE0;
> + break;
> + case 0:
> + nfcont &= ~NFCONT_NCE0;
> + break;
> + case 1:
> + nfcont &= ~NFCONT_NCE1;
> + break;
> + default:
> + return;
> + }
> +
> + writel(nfcont, &nand->nfcont);
> +}
> +
> +/*
> + * Hardware specific access to control-lines function
> + */
> +static void s3c_nand_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int
> ctrl) +{
> + struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
> + struct nand_chip *this = mtd->priv;
> +
> + if (ctrl & NAND_CTRL_CHANGE) {
> + if (ctrl & NAND_CLE)
> + this->IO_ADDR_W = &nand->nfcmmd;
> + else if (ctrl & NAND_ALE)
> + this->IO_ADDR_W = &nand->nfaddr;
> + else
> + this->IO_ADDR_W = &nand->nfdata;
Why don't you use local variable here?
> + if (ctrl & NAND_NCE)
> + s3c_nand_select_chip(mtd, *(int *)this->priv);
Uh, how's this *(int *) supposed to work?
[...]
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
2012-09-14 17:29 ` [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile José Miguel Gonçalves
@ 2012-09-14 18:22 ` Marek Vasut
2012-09-14 19:08 ` Tom Rini
1 sibling, 0 replies; 84+ messages in thread
From: Marek Vasut @ 2012-09-14 18:22 UTC (permalink / raw)
To: u-boot
Dear Jos? Miguel Gon?alves,
> Samsung's S3C24XX SoCs need this in order to generate a binary image
> with the SPL and U-Boot concatenated.
You aren't adding it, you're modifying it.
> Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
> ---
> Changes for v2:
> - None
> ---
> Makefile | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 058fb53..595b5f6 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -442,13 +442,14 @@ $(obj)u-boot.sha1: $(obj)u-boot.bin
> $(obj)u-boot.dis: $(obj)u-boot
> $(OBJDUMP) -d $< > $@
>
> -$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
> +$(obj)u-boot-ubl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
> $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary
> $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin cat
> $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > $(obj)u-boot-ubl.bin +
rm
> $(obj)spl/u-boot-spl-pad.bin
> +
> +$(obj)u-boot.ubl: $(obj)u-boot-ubl.bin
> $(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \
> -e $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin $(obj)u-
boot.ubl
> - rm $(obj)u-boot-ubl.bin
> - rm $(obj)spl/u-boot-spl-pad.bin
Check the apollon board, won't this colide with it's NAND IPL?
> $(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
> $(obj)tools/mkimage -s -n $(if
> $(CONFIG_AIS_CONFIG_FILE),$(CONFIG_AIS_CONFIG_FILE),"/dev/null") \
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 02/11] S3C24XX: Add core support for Samsung's S3C24XX SoCs
[not found] ` <505375E3.6050005@inov.pt>
@ 2012-09-14 18:25 ` Marek Vasut
2012-09-14 19:01 ` Scott Wood
0 siblings, 1 reply; 84+ messages in thread
From: Marek Vasut @ 2012-09-14 18:25 UTC (permalink / raw)
To: u-boot
Dear Jos? Miguel Gon?alves,
> Hi Marek,
>
> On 14-09-2012 19:03, Marek Vasut wrote:
> > Dear Jos? Miguel Gon?alves,
> >
> > It's getting better :)
>
> Hopefully :-)
>
> > [...]
> >
> >> +
> >> +typedef ulong(*getfreq) (void);
> >
> > Is this used?
>
> In the array declaration bellow...
Why, these are only values, no ?
> >> +static const getfreq freq_f[] = {
> >
> > const array const members, no?
>
> Do you mean I should declare it like this:
>
> static const getfreq const freq[] = { ...
Yes
> I don't see the point because an array has no other storage besides it's
> elements. Moreover GCC generates the same object code in both ways.
Type checking, if you ever decided to write into the array, it'll prevent you
from doing so.
> >> + get_FCLK,
> >> + get_HCLK,
> >> + get_PCLK,
> >> + get_UCLK,
> >> +};
> >> +
> >> +static const char freq_c[] = { 'F', 'H', 'P', 'U' };
> >
> > Same here.
> >
> >> +int print_cpuinfo(void)
> >> +{
> >> + int i;
> >> + char buf[32];
> >> + ulong cpuid;
> >> + struct s3c24xx_gpio *const gpio = s3c24xx_get_base_gpio();
> >> +
> >> + cpuid = readl(&gpio->gstatus[1]);
> >> + printf("CPU: %8s (id %08lX) @ %s MHz\n", s3c24xx_get_cpu_name(),
> >> + cpuid, strmhz(buf, get_ARMCLK()));
> >> + for (i = 0; i < ARRAY_SIZE(freq_f); i++)
> >> + printf("%cCLK: %8s MHz\n", freq_c[i],
> >> + strmhz(buf, freq_f[i] ()));
> >> +
> >> + return 0;
> >> +}
> >
> > [...]
> >
> >> +ulong get_HCLK(void)
> >> +{
> >> + struct s3c2412_sysctl *const sysctl = s3c2412_get_base_sysctl();
> >> + u32 clkdivn;
> >> + u16 hclk_div, arm_div;
> >> +
> >> + clkdivn = readl(&sysctl->clkdivn);
> >> + hclk_div = (clkdivn & 0x3) + 1;
> >> + arm_div = ((clkdivn >> 3) & 0x1) + 1;
> >
> > Magic.
>
> Missed that... I will fix it.
>
There's more, globally please.
[...]
> >> diff --git a/include/common.h b/include/common.h
> >> index 55025c0..36f0636 100644
> >> --- a/include/common.h
> >> +++ b/include/common.h
> >> @@ -628,6 +628,7 @@ ulong get_OPB_freq (void);
> >>
> >> ulong get_PCI_freq (void);
> >> #endif
> >> #if defined(CONFIG_S3C24X0) || \
> >>
> >> + defined(CONFIG_S3C24XX) || \
> >>
> >> defined(CONFIG_LH7A40X) || \
> >> defined(CONFIG_S3C6400) || \
> >> defined(CONFIG_EP93XX)
> >
> > What's this change? Split into different patch please.
>
> This is related. I need this to export the functions get_FCLK(),
> get_HCLK(), get_PCLK() and get_UCLK() used in
> arch/arm/cpu/arm926ejs/s3c24xx/cpu_info.c
OK
> Best regards,
> Jos? Gon?alves
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 02/11] S3C24XX: Add core support for Samsung's S3C24XX SoCs
2012-09-14 17:28 ` [U-Boot] [PATCH v2 02/11] S3C24XX: Add core support for Samsung's S3C24XX SoCs José Miguel Gonçalves
2012-09-14 18:03 ` Marek Vasut
@ 2012-09-14 18:39 ` Tom Rini
1 sibling, 0 replies; 84+ messages in thread
From: Tom Rini @ 2012-09-14 18:39 UTC (permalink / raw)
To: u-boot
On Fri, Sep 14, 2012 at 06:28:53PM +0100, Jos?? Miguel Gon??alves wrote:
> This patch adds the support for Samsung's S3C24XX SoCs that have an ARM926EJS core.
> Currently it supports S3C2412, S3C2413, S3C2416 and S3C2450.
> Tested on an S3C2416 platform.
[snip]
> +/*
> + * Reset the cpu by setting up the watchdog timer and let him time out.
> + */
> +void reset_cpu(ulong addr)
> +{
> + struct s3c24xx_watchdog *const watchdog = s3c24xx_get_base_watchdog();
> +
> + /* Disable watchdog */
> + writel(0x0000, &watchdog->wtcon);
> +
> + /* Initialize watchdog timer count register */
> + writel(0x0001, &watchdog->wtcnt);
> +
> + /* Enable watchdog timer; assert reset at timer timeout */
> + writel(WTCON_RSTEN | WTCON_ENABLE, &watchdog->wtcon);
> +
> + while (1)
> + /* loop forever and wait for reset to happen */;
> +}
As we're dealing with in another series, this should be __noreturn (from
<linux/compiler.h>).
Also, please audit your new headers to make sure you aren't adding
structs / defines / etc that you aren't using by the end of the series,
and make sure to note in the cover letter that you are checkpatch clean
or explain away the false positives. Thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120914/936e5684/attachment.pgp>
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
2012-09-14 18:21 ` Marek Vasut
@ 2012-09-14 18:45 ` José Miguel Gonçalves
2012-09-14 19:01 ` Tom Rini
2012-09-14 19:24 ` Scott Wood
2012-09-17 11:11 ` José Miguel Gonçalves
2 siblings, 1 reply; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-14 18:45 UTC (permalink / raw)
To: u-boot
On 14-09-2012 19:21, Marek Vasut wrote:
> Dear Jos? Miguel Gon?alves,
>
>> NAND Flash driver with HW ECC for the S3C24XX SoCs.
>> Currently it only supports SLC NAND chips.
>>
>> Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
> [...]
>
>> +#include <common.h>
>> +#include <nand.h>
>> +#include <asm/io.h>
>> +#include <asm/arch/s3c24xx_cpu.h>
>> +#include <asm/errno.h>
>> +
>> +#define MAX_CHIPS 2
>> +static int nand_cs[MAX_CHIPS] = { 0, 1 };
>> +
>> +#ifdef CONFIG_SPL_BUILD
>> +#define printf(arg...) do {} while (0)
> This doesn't seem quite right ...
>
> 1) this should be in CPU directory
> 2) should be enabled only if CONFIG_SPL_SERIAL_SUPPORT is not set
> 3) should be inline function, not a macro
1) and 3) OK.
Don't quite understand 2). I want to remove the printfs in the SPL build, as it
would blown up the internal SoC RAM space available.
So why add a condition with CONFIG_SPL_SERIAL_SUPPORT?
>
>> +#endif
>> +
>> +static void s3c_nand_select_chip(struct mtd_info *mtd, int chip)
>> +{
>> + struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
>> + u_long nfcont;
>> +
>> + nfcont = readl(&nand->nfcont);
>> +
>> + switch (chip) {
>> + case -1:
>> + nfcont |= NFCONT_NCE1 | NFCONT_NCE0;
>> + break;
>> + case 0:
>> + nfcont &= ~NFCONT_NCE0;
>> + break;
>> + case 1:
>> + nfcont &= ~NFCONT_NCE1;
>> + break;
>> + default:
>> + return;
>> + }
>> +
>> + writel(nfcont, &nand->nfcont);
>> +}
>> +
>> +/*
>> + * Hardware specific access to control-lines function
>> + */
>> +static void s3c_nand_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int
>> ctrl) +{
>> + struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
>> + struct nand_chip *this = mtd->priv;
>> +
>> + if (ctrl & NAND_CTRL_CHANGE) {
>> + if (ctrl & NAND_CLE)
>> + this->IO_ADDR_W = &nand->nfcmmd;
>> + else if (ctrl & NAND_ALE)
>> + this->IO_ADDR_W = &nand->nfaddr;
>> + else
>> + this->IO_ADDR_W = &nand->nfdata;
> Why don't you use local variable here?
Because you need to retain the NAND controller register to use between calls to
s3c_nand_hwcontrol().
If you call the function without the NAND_CTRL_CHANGE bit set in the parameter
'ctrl' you must use the register used on the last call on the next access.
>
>> + if (ctrl & NAND_NCE)
>> + s3c_nand_select_chip(mtd, *(int *)this->priv);
> Uh, how's this *(int *) supposed to work?
>
*(int *)this->priv contains an integer that is the chip id (0 or 1).
Best regards,
Jos? Gon?alves
Best regards,
Jos? Gon?alves
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
2012-09-14 17:29 ` [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver José Miguel Gonçalves
2012-09-14 18:21 ` Marek Vasut
@ 2012-09-14 18:47 ` Tom Rini
1 sibling, 0 replies; 84+ messages in thread
From: Tom Rini @ 2012-09-14 18:47 UTC (permalink / raw)
To: u-boot
On Fri, Sep 14, 2012 at 06:29:00PM +0100, Jos?? Miguel Gon??alves wrote:
> NAND Flash driver with HW ECC for the S3C24XX SoCs.
> Currently it only supports SLC NAND chips.
>
> Signed-off-by: Jos?? Miguel Gon??alves <jose.goncalves@inov.pt>
[snip]
> +#ifdef CONFIG_SPL_BUILD
> +#define printf(arg...) do {} while (0)
> +#endif
As Marek pointed out, this isn't the right way to do this.
[snip]
> + case 2: /* Multiple error */
> + case 3: /* ECC area error */
> + printf("S3C24XX NAND: ECC uncorrectable error detected.\n");
Use puts() here.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120914/c08fc150/attachment.pgp>
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 11/11] S3C24XX: Add support to MINI2416 board
2012-09-14 17:29 ` [U-Boot] [PATCH v2 11/11] S3C24XX: Add support to MINI2416 board José Miguel Gonçalves
@ 2012-09-14 18:58 ` Tom Rini
2012-09-16 9:11 ` José Miguel Gonçalves
0 siblings, 1 reply; 84+ messages in thread
From: Tom Rini @ 2012-09-14 18:58 UTC (permalink / raw)
To: u-boot
On Fri, Sep 14, 2012 at 06:29:02PM +0100, Jos?? Miguel Gon??alves wrote:
> The MINI2416 board is based on a Samsung's S3C2416 SoC and has 64MB DDR2 SDRAM,
> 256MB NAND Flash, a LAN9220 Ethernet Controller and a WM8731 Audio CODEC.
> This U-Boot port was implemented and tested on a unit bought to Boardcon
> (http://www.armdesigner.com/) but there are some other chinese providers
> that can supply it with a selectable NAND chip from 128MB to 1GB.
[snip]
Can you please try this on top of my SPL framework series? Thanks!
--
Tom
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
2012-09-14 18:45 ` José Miguel Gonçalves
@ 2012-09-14 19:01 ` Tom Rini
2012-09-16 9:16 ` José Miguel Gonçalves
0 siblings, 1 reply; 84+ messages in thread
From: Tom Rini @ 2012-09-14 19:01 UTC (permalink / raw)
To: u-boot
On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel Gon?alves wrote:
> On 14-09-2012 19:21, Marek Vasut wrote:
> >Dear Jos? Miguel Gon?alves,
> >
> >>NAND Flash driver with HW ECC for the S3C24XX SoCs.
> >>Currently it only supports SLC NAND chips.
> >>
> >>Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
> >[...]
> >
> >>+#include <common.h>
> >>+#include <nand.h>
> >>+#include <asm/io.h>
> >>+#include <asm/arch/s3c24xx_cpu.h>
> >>+#include <asm/errno.h>
> >>+
> >>+#define MAX_CHIPS 2
> >>+static int nand_cs[MAX_CHIPS] = { 0, 1 };
> >>+
> >>+#ifdef CONFIG_SPL_BUILD
> >>+#define printf(arg...) do {} while (0)
> >This doesn't seem quite right ...
> >
> >1) this should be in CPU directory
> >2) should be enabled only if CONFIG_SPL_SERIAL_SUPPORT is not set
> >3) should be inline function, not a macro
>
> 1) and 3) OK.
> Don't quite understand 2). I want to remove the printfs in the SPL
> build, as it would blown up the internal SoC RAM space available.
> So why add a condition with CONFIG_SPL_SERIAL_SUPPORT?
You've got 8KB, based on the final patch in the series. At least in my
SPL series that's still enough to get you printf/puts (I believe 4kb was
the cutoff where that had to be dropped).
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120914/a545310e/attachment.pgp>
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 02/11] S3C24XX: Add core support for Samsung's S3C24XX SoCs
2012-09-14 18:25 ` Marek Vasut
@ 2012-09-14 19:01 ` Scott Wood
2012-09-14 19:07 ` Marek Vasut
0 siblings, 1 reply; 84+ messages in thread
From: Scott Wood @ 2012-09-14 19:01 UTC (permalink / raw)
To: u-boot
On Fri, Sep 14, 2012 at 08:25:25PM +0200, Marek Vasut wrote:
> Dear Jos? Miguel Gon?alves,
>
> > Hi Marek,
> >
> > On 14-09-2012 19:03, Marek Vasut wrote:
> > > Dear Jos? Miguel Gon?alves,
> > >
> > > It's getting better :)
> >
> > Hopefully :-)
> >
> > > [...]
> > >
> > >> +
> > >> +typedef ulong(*getfreq) (void);
> > >
> > > Is this used?
> >
> > In the array declaration bellow...
>
> Why, these are only values, no ?
They're function pointers. If they were values the compiler should
complain, because "getfreq" is used as the type of the array.
> > >> +static const getfreq freq_f[] = {
> > >
> > > const array const members, no?
> >
> > Do you mean I should declare it like this:
> >
> > static const getfreq const freq[] = { ...
>
> Yes
Why? When can you ever change what an array (not a pointer) points to?
> > I don't see the point because an array has no other storage besides it's
> > elements. Moreover GCC generates the same object code in both ways.
>
> Type checking, if you ever decided to write into the array, it'll prevent you
> from doing so.
The first const takes care of that.
-Scott
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 02/11] S3C24XX: Add core support for Samsung's S3C24XX SoCs
2012-09-14 19:01 ` Scott Wood
@ 2012-09-14 19:07 ` Marek Vasut
2012-09-14 19:17 ` Scott Wood
0 siblings, 1 reply; 84+ messages in thread
From: Marek Vasut @ 2012-09-14 19:07 UTC (permalink / raw)
To: u-boot
Dear Scott Wood,
> On Fri, Sep 14, 2012 at 08:25:25PM +0200, Marek Vasut wrote:
> > Dear Jos? Miguel Gon?alves,
> >
> > > Hi Marek,
> > >
> > > On 14-09-2012 19:03, Marek Vasut wrote:
> > > > Dear Jos? Miguel Gon?alves,
> > > >
> > > > It's getting better :)
> > >
> > > Hopefully :-)
> > >
> > > > [...]
> > > >
> > > >> +
> > > >> +typedef ulong(*getfreq) (void);
> > > >
> > > > Is this used?
> > >
> > > In the array declaration bellow...
> >
> > Why, these are only values, no ?
>
> They're function pointers. If they were values the compiler should
> complain, because "getfreq" is used as the type of the array.
>
> > > >> +static const getfreq freq_f[] = {
> > > >
> > > > const array const members, no?
> > >
> > > Do you mean I should declare it like this:
> > >
> > > static const getfreq const freq[] = { ...
> >
> > Yes
>
> Why? When can you ever change what an array (not a pointer) points to?
Uh oh ... now I see the stuff with the functions. Crazy
> > > I don't see the point because an array has no other storage besides
> > > it's elements. Moreover GCC generates the same object code in both
> > > ways.
> >
> > Type checking, if you ever decided to write into the array, it'll prevent
> > you from doing so.
>
> The first const takes care of that.
Doesn't one prevent you from manupulating the elements and the other
manipulating the array ?
> -Scott
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
2012-09-14 17:29 ` [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile José Miguel Gonçalves
2012-09-14 18:22 ` Marek Vasut
@ 2012-09-14 19:08 ` Tom Rini
2012-09-16 9:27 ` José Miguel Gonçalves
1 sibling, 1 reply; 84+ messages in thread
From: Tom Rini @ 2012-09-14 19:08 UTC (permalink / raw)
To: u-boot
On Fri, Sep 14, 2012 at 06:29:01PM +0100, Jos?? Miguel Gon??alves wrote:
> Samsung's S3C24XX SoCs need this in order to generate a binary image
> with the SPL and U-Boot concatenated.
>
> Signed-off-by: Jos?? Miguel Gon??alves <jose.goncalves@inov.pt>
> ---
> Changes for v2:
> - None
> ---
> Makefile | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 058fb53..595b5f6 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -442,13 +442,14 @@ $(obj)u-boot.sha1: $(obj)u-boot.bin
> $(obj)u-boot.dis: $(obj)u-boot
> $(OBJDUMP) -d $< > $@
>
> -$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
> +$(obj)u-boot-ubl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
> $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin
> cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > $(obj)u-boot-ubl.bin
> + rm $(obj)spl/u-boot-spl-pad.bin
> +
> +$(obj)u-boot.ubl: $(obj)u-boot-ubl.bin
> $(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \
> -e $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin $(obj)u-boot.ubl
> - rm $(obj)u-boot-ubl.bin
> - rm $(obj)spl/u-boot-spl-pad.bin
>
> $(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
> $(obj)tools/mkimage -s -n $(if $(CONFIG_AIS_CONFIG_FILE),$(CONFIG_AIS_CONFIG_FILE),"/dev/null") \
This diff is hard to read, but what exactly are you changing? The
u-boot-ubl target is also used on TI platforms. It looks like you're
making it such that u-boot-ubl.bin produces the old binary and
u-boot-ubl adds a new target which is the mkimage header on top of the
same bits as before, but without possibly padding the output image. I
suspect in your case you could just set PAD_TO to 8192 in
board/../config.mk and use the existing target.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120914/f4c1f94e/attachment.pgp>
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 02/11] S3C24XX: Add core support for Samsung's S3C24XX SoCs
2012-09-14 19:07 ` Marek Vasut
@ 2012-09-14 19:17 ` Scott Wood
0 siblings, 0 replies; 84+ messages in thread
From: Scott Wood @ 2012-09-14 19:17 UTC (permalink / raw)
To: u-boot
On Fri, Sep 14, 2012 at 09:07:12PM +0200, Marek Vasut wrote:
> Dear Scott Wood,
>
> > On Fri, Sep 14, 2012 at 08:25:25PM +0200, Marek Vasut wrote:
> > > Dear Jos? Miguel Gon?alves,
> > >
> > > > Hi Marek,
> > > >
> > > > On 14-09-2012 19:03, Marek Vasut wrote:
> > > > > Dear Jos? Miguel Gon?alves,
> > > > >
> > > > > It's getting better :)
> > > >
> > > > Hopefully :-)
> > > >
> > > > > [...]
> > > > >
> > > > >> +
> > > > >> +typedef ulong(*getfreq) (void);
> > > > >
> > > > > Is this used?
> > > >
> > > > In the array declaration bellow...
> > >
> > > Why, these are only values, no ?
> >
> > They're function pointers. If they were values the compiler should
> > complain, because "getfreq" is used as the type of the array.
> >
> > > > >> +static const getfreq freq_f[] = {
> > > > >
> > > > > const array const members, no?
> > > >
> > > > Do you mean I should declare it like this:
> > > >
> > > > static const getfreq const freq[] = { ...
> > >
> > > Yes
> >
> > Why? When can you ever change what an array (not a pointer) points to?
>
> Uh oh ... now I see the stuff with the functions. Crazy
>
> > > > I don't see the point because an array has no other storage besides
> > > > it's elements. Moreover GCC generates the same object code in both
> > > > ways.
> > >
> > > Type checking, if you ever decided to write into the array, it'll prevent
> > > you from doing so.
> >
> > The first const takes care of that.
>
> Doesn't one prevent you from manupulating the elements and the other
> manipulating the array ?
No. These are all identical:
const int foo[];
int const foo[];
const int const foo[];
const const const int const const const foo[];
If it were a pointer, then there would be a difference between these:
const int *foo; (pointed-to data is const)
int *const foo; (pointer itself is const)
const int *const foo; (both are const)
...but still there's no distinction between these:
const int *foo;
const int const *foo;
-Scott
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
2012-09-14 18:21 ` Marek Vasut
2012-09-14 18:45 ` José Miguel Gonçalves
@ 2012-09-14 19:24 ` Scott Wood
2012-09-14 20:20 ` Tom Rini
2012-09-17 11:11 ` José Miguel Gonçalves
2 siblings, 1 reply; 84+ messages in thread
From: Scott Wood @ 2012-09-14 19:24 UTC (permalink / raw)
To: u-boot
On Fri, Sep 14, 2012 at 08:21:11PM +0200, Marek Vasut wrote:
> Dear Jos? Miguel Gon?alves,
>
> > NAND Flash driver with HW ECC for the S3C24XX SoCs.
> > Currently it only supports SLC NAND chips.
> >
> > Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
>
> [...]
>
> > +#include <common.h>
> > +#include <nand.h>
> > +#include <asm/io.h>
> > +#include <asm/arch/s3c24xx_cpu.h>
> > +#include <asm/errno.h>
> > +
> > +#define MAX_CHIPS 2
> > +static int nand_cs[MAX_CHIPS] = { 0, 1 };
> > +
> > +#ifdef CONFIG_SPL_BUILD
> > +#define printf(arg...) do {} while (0)
>
> This doesn't seem quite right ...
>
> 1) this should be in CPU directory
> 2) should be enabled only if CONFIG_SPL_SERIAL_SUPPORT is not set
> 3) should be inline function, not a macro
What specifically should be in the CPU directory?
> > +#endif
> > +
> > +static void s3c_nand_select_chip(struct mtd_info *mtd, int chip)
> > +{
> > + struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
> > + u_long nfcont;
> > +
> > + nfcont = readl(&nand->nfcont);
> > +
> > + switch (chip) {
> > + case -1:
> > + nfcont |= NFCONT_NCE1 | NFCONT_NCE0;
> > + break;
> > + case 0:
> > + nfcont &= ~NFCONT_NCE0;
> > + break;
> > + case 1:
> > + nfcont &= ~NFCONT_NCE1;
> > + break;
> > + default:
> > + return;
> > + }
> > +
> > + writel(nfcont, &nand->nfcont);
> > +}
> > +
> > +/*
> > + * Hardware specific access to control-lines function
> > + */
> > +static void s3c_nand_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int
> > ctrl) +{
> > + struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
> > + struct nand_chip *this = mtd->priv;
> > +
> > + if (ctrl & NAND_CTRL_CHANGE) {
> > + if (ctrl & NAND_CLE)
> > + this->IO_ADDR_W = &nand->nfcmmd;
> > + else if (ctrl & NAND_ALE)
> > + this->IO_ADDR_W = &nand->nfaddr;
> > + else
> > + this->IO_ADDR_W = &nand->nfdata;
>
> Why don't you use local variable here?
Because then you'll access the wrong data when the function is called
again without NAND_CTRL_CHANGE. This is a common way of writing the
hwcontrol function, though the way ndfc.c does it is simpler (you can use
a local variable if you ignore NAND_CTRL_CHANGE altogether).
> > + if (ctrl & NAND_NCE)
> > + s3c_nand_select_chip(mtd, *(int *)this->priv);
>
> Uh, how's this *(int *) supposed to work?
Usually driver-private data is a struct; apparently in this driver it's
an int.
-Scott
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
2012-09-14 19:24 ` Scott Wood
@ 2012-09-14 20:20 ` Tom Rini
2012-09-14 20:29 ` Scott Wood
0 siblings, 1 reply; 84+ messages in thread
From: Tom Rini @ 2012-09-14 20:20 UTC (permalink / raw)
To: u-boot
On Fri, Sep 14, 2012 at 02:24:48PM -0500, Scott Wood wrote:
> On Fri, Sep 14, 2012 at 08:21:11PM +0200, Marek Vasut wrote:
> > Dear Jos? Miguel Gon?alves,
> >
> > > NAND Flash driver with HW ECC for the S3C24XX SoCs.
> > > Currently it only supports SLC NAND chips.
> > >
> > > Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
[snip]
> > > +/*
> > > + * Hardware specific access to control-lines function
> > > + */
> > > +static void s3c_nand_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int
> > > ctrl) +{
> > > + struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
> > > + struct nand_chip *this = mtd->priv;
> > > +
> > > + if (ctrl & NAND_CTRL_CHANGE) {
> > > + if (ctrl & NAND_CLE)
> > > + this->IO_ADDR_W = &nand->nfcmmd;
> > > + else if (ctrl & NAND_ALE)
> > > + this->IO_ADDR_W = &nand->nfaddr;
> > > + else
> > > + this->IO_ADDR_W = &nand->nfdata;
> >
> > Why don't you use local variable here?
>
> Because then you'll access the wrong data when the function is called
> again without NAND_CTRL_CHANGE. This is a common way of writing the
> hwcontrol function, though the way ndfc.c does it is simpler (you can use
> a local variable if you ignore NAND_CTRL_CHANGE altogether).
>
> > > + if (ctrl & NAND_NCE)
> > > + s3c_nand_select_chip(mtd, *(int *)this->priv);
> >
> > Uh, how's this *(int *) supposed to work?
>
> Usually driver-private data is a struct; apparently in this driver it's
> an int.
Shall we take both of these comments as requests to do things
differently (struct like everyone else does, simpiler code like ndfc.c
does) unless there's good reason to not change?
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120914/a48c29f8/attachment.pgp>
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
2012-09-14 20:20 ` Tom Rini
@ 2012-09-14 20:29 ` Scott Wood
0 siblings, 0 replies; 84+ messages in thread
From: Scott Wood @ 2012-09-14 20:29 UTC (permalink / raw)
To: u-boot
On Fri, Sep 14, 2012 at 01:20:32PM -0700, Tom Rini wrote:
> On Fri, Sep 14, 2012 at 02:24:48PM -0500, Scott Wood wrote:
> > On Fri, Sep 14, 2012 at 08:21:11PM +0200, Marek Vasut wrote:
> > > Dear Jos? Miguel Gon?alves,
> > >
> > > > NAND Flash driver with HW ECC for the S3C24XX SoCs.
> > > > Currently it only supports SLC NAND chips.
> > > >
> > > > Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
> [snip]
> > > > +/*
> > > > + * Hardware specific access to control-lines function
> > > > + */
> > > > +static void s3c_nand_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int
> > > > ctrl) +{
> > > > + struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
> > > > + struct nand_chip *this = mtd->priv;
> > > > +
> > > > + if (ctrl & NAND_CTRL_CHANGE) {
> > > > + if (ctrl & NAND_CLE)
> > > > + this->IO_ADDR_W = &nand->nfcmmd;
> > > > + else if (ctrl & NAND_ALE)
> > > > + this->IO_ADDR_W = &nand->nfaddr;
> > > > + else
> > > > + this->IO_ADDR_W = &nand->nfdata;
> > >
> > > Why don't you use local variable here?
> >
> > Because then you'll access the wrong data when the function is called
> > again without NAND_CTRL_CHANGE. This is a common way of writing the
> > hwcontrol function, though the way ndfc.c does it is simpler (you can use
> > a local variable if you ignore NAND_CTRL_CHANGE altogether).
> >
> > > > + if (ctrl & NAND_NCE)
> > > > + s3c_nand_select_chip(mtd, *(int *)this->priv);
> > >
> > > Uh, how's this *(int *) supposed to work?
> >
> > Usually driver-private data is a struct; apparently in this driver it's
> > an int.
>
> Shall we take both of these comments as requests to do things
> differently (struct like everyone else does, simpiler code like ndfc.c
> does) unless there's good reason to not change?
Sure. :-)
-Scott
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
2012-09-14 17:28 ` [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS José Miguel Gonçalves
@ 2012-09-15 18:03 ` Marek Vasut
2012-09-16 9:45 ` José Miguel Gonçalves
2012-10-04 14:24 ` Albert ARIBAUD
1 sibling, 1 reply; 84+ messages in thread
From: Marek Vasut @ 2012-09-15 18:03 UTC (permalink / raw)
To: u-boot
Dear Jos? Miguel Gon?alves,
> Jumping to board_init_r is not performed due to a bug on address
> computation.
Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any
misbehavior on my arm926 boards.
> Relocation offsets are not needed when building SPL.
Do they cause any trouble?
> Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
> ---
> Changes for v2:
> - None
> ---
> arch/arm/cpu/arm926ejs/start.S | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/cpu/arm926ejs/start.S
> b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644
> --- a/arch/arm/cpu/arm926ejs/start.S
> +++ b/arch/arm/cpu/arm926ejs/start.S
> @@ -325,7 +325,7 @@ _nand_boot_ofs:
> .word nand_boot
> #else
> ldr r0, _board_init_r_ofs
> - ldr r1, _TEXT_BASE
> + adr r1, _start
> add lr, r0, r1
> add lr, lr, r9
> /* setup parameters for board_init_r */
> @@ -338,12 +338,14 @@ _board_init_r_ofs:
> .word board_init_r - _start
> #endif
>
> +#ifndef CONFIG_SPL_BUILD
> _rel_dyn_start_ofs:
> .word __rel_dyn_start - _start
> _rel_dyn_end_ofs:
> .word __rel_dyn_end - _start
> _dynsym_start_ofs:
> .word __dynsym_start - _start
> +#endif
>
> /*
> *************************************************************************
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 11/11] S3C24XX: Add support to MINI2416 board
2012-09-14 18:58 ` Tom Rini
@ 2012-09-16 9:11 ` José Miguel Gonçalves
2012-09-17 14:39 ` Tom Rini
0 siblings, 1 reply; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-16 9:11 UTC (permalink / raw)
To: u-boot
On 09/14/2012 07:58 PM, Tom Rini wrote:
> On Fri, Sep 14, 2012 at 06:29:02PM +0100, Jos?? Miguel Gon??alves wrote:
>
>> The MINI2416 board is based on a Samsung's S3C2416 SoC and has 64MB DDR2 SDRAM,
>> 256MB NAND Flash, a LAN9220 Ethernet Controller and a WM8731 Audio CODEC.
>> This U-Boot port was implemented and tested on a unit bought to Boardcon
>> (http://www.armdesigner.com/) but there are some other chinese providers
>> that can supply it with a selectable NAND chip from 128MB to 1GB.
> [snip]
>
> Can you please try this on top of my SPL framework series? Thanks!
>
I thought I was using the latest SPL framework!
Can you please detail on what I should do different?
Best regards,
Jos? Gon?alves
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
2012-09-14 19:01 ` Tom Rini
@ 2012-09-16 9:16 ` José Miguel Gonçalves
2012-09-17 16:57 ` Tom Rini
0 siblings, 1 reply; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-16 9:16 UTC (permalink / raw)
To: u-boot
On 09/14/2012 08:01 PM, Tom Rini wrote:
> On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel Gon?alves wrote:
>> On 14-09-2012 19:21, Marek Vasut wrote:
>>> Dear Jos? Miguel Gon?alves,
>>>
>>>> NAND Flash driver with HW ECC for the S3C24XX SoCs.
>>>> Currently it only supports SLC NAND chips.
>>>>
>>>> Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
>>> [...]
>>>
>>>> +#include <common.h>
>>>> +#include <nand.h>
>>>> +#include <asm/io.h>
>>>> +#include <asm/arch/s3c24xx_cpu.h>
>>>> +#include <asm/errno.h>
>>>> +
>>>> +#define MAX_CHIPS 2
>>>> +static int nand_cs[MAX_CHIPS] = { 0, 1 };
>>>> +
>>>> +#ifdef CONFIG_SPL_BUILD
>>>> +#define printf(arg...) do {} while (0)
>>> This doesn't seem quite right ...
>>>
>>> 1) this should be in CPU directory
>>> 2) should be enabled only if CONFIG_SPL_SERIAL_SUPPORT is not set
>>> 3) should be inline function, not a macro
>> 1) and 3) OK.
>> Don't quite understand 2). I want to remove the printfs in the SPL
>> build, as it would blown up the internal SoC RAM space available.
>> So why add a condition with CONFIG_SPL_SERIAL_SUPPORT?
> You've got 8KB, based on the final patch in the series. At least in my
> SPL series that's still enough to get you printf/puts (I believe 4kb was
> the cutoff where that had to be dropped).
>
Barely:
$ size u-boot-spl
text data bss dec hex filename
3337 8 588 3933 f5d u-boot-spl
$ size u-boot-spl-printf
text data bss dec hex filename
7968 8 604 8580 2184 u-boot-spl-printf
The printf is not so important that justifies exhausting the IRAM space
available and preventing any future SPL expansion...
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
2012-09-14 19:08 ` Tom Rini
@ 2012-09-16 9:27 ` José Miguel Gonçalves
2012-09-17 6:47 ` Christian Riesch
0 siblings, 1 reply; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-16 9:27 UTC (permalink / raw)
To: u-boot
On 09/14/2012 08:08 PM, Tom Rini wrote:
> On Fri, Sep 14, 2012 at 06:29:01PM +0100, Jos?? Miguel Gon??alves wrote:
>
>> Samsung's S3C24XX SoCs need this in order to generate a binary image
>> with the SPL and U-Boot concatenated.
>>
>> Signed-off-by: Jos?? Miguel Gon??alves <jose.goncalves@inov.pt>
>> ---
>> Changes for v2:
>> - None
>> ---
>> Makefile | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/Makefile b/Makefile
>> index 058fb53..595b5f6 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -442,13 +442,14 @@ $(obj)u-boot.sha1: $(obj)u-boot.bin
>> $(obj)u-boot.dis: $(obj)u-boot
>> $(OBJDUMP) -d $< > $@
>>
>> -$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
>> +$(obj)u-boot-ubl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
>> $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin
>> cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > $(obj)u-boot-ubl.bin
>> + rm $(obj)spl/u-boot-spl-pad.bin
>> +
>> +$(obj)u-boot.ubl: $(obj)u-boot-ubl.bin
>> $(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \
>> -e $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin $(obj)u-boot.ubl
>> - rm $(obj)u-boot-ubl.bin
>> - rm $(obj)spl/u-boot-spl-pad.bin
>>
>> $(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
>> $(obj)tools/mkimage -s -n $(if $(CONFIG_AIS_CONFIG_FILE),$(CONFIG_AIS_CONFIG_FILE),"/dev/null") \
> This diff is hard to read, but what exactly are you changing? The
> u-boot-ubl target is also used on TI platforms. It looks like you're
> making it such that u-boot-ubl.bin produces the old binary and
> u-boot-ubl adds a new target which is the mkimage header on top of the
> same bits as before, but without possibly padding the output image. I
> suspect in your case you could just set PAD_TO to 8192 in
> board/../config.mk and use the existing target.
>
In the S3C2416 I don't need the mkimage stuff. I only need the raw SPL
image padded at 8KB concatenated with the standard U-Boot. What I've
done was to split the existing u-boot-ubl target in two; u-boot-ubl.bin,
that I use to program the Flash, and u-boot-ubl that remains with the
same functionality as before, just now it depends on u-boot-ubl.bin.
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
2012-09-15 18:03 ` Marek Vasut
@ 2012-09-16 9:45 ` José Miguel Gonçalves
2012-09-16 10:06 ` Marek Vasut
0 siblings, 1 reply; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-16 9:45 UTC (permalink / raw)
To: u-boot
On 09/15/2012 07:03 PM, Marek Vasut wrote:
> Dear Jos? Miguel Gon?alves,
>
>> Jumping to board_init_r is not performed due to a bug on address
>> computation.
> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any
> misbehavior on my arm926 boards.
Maybe because you are not using it to build an SPL?
Please check the same chunk of code in other start.S for arm1176 and
armv7. They have the same code that I put for arm926ejs.
>
>> Relocation offsets are not needed when building SPL.
> Do they cause any trouble?
No! Just not needed.
>
>> Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
>> ---
>> Changes for v2:
>> - None
>> ---
>> arch/arm/cpu/arm926ejs/start.S | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/cpu/arm926ejs/start.S
>> b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644
>> --- a/arch/arm/cpu/arm926ejs/start.S
>> +++ b/arch/arm/cpu/arm926ejs/start.S
>> @@ -325,7 +325,7 @@ _nand_boot_ofs:
>> .word nand_boot
>> #else
>> ldr r0, _board_init_r_ofs
>> - ldr r1, _TEXT_BASE
>> + adr r1, _start
>> add lr, r0, r1
>> add lr, lr, r9
>> /* setup parameters for board_init_r */
>> @@ -338,12 +338,14 @@ _board_init_r_ofs:
>> .word board_init_r - _start
>> #endif
>>
>> +#ifndef CONFIG_SPL_BUILD
>> _rel_dyn_start_ofs:
>> .word __rel_dyn_start - _start
>> _rel_dyn_end_ofs:
>> .word __rel_dyn_end - _start
>> _dynsym_start_ofs:
>> .word __dynsym_start - _start
>> +#endif
>>
>> /*
>> *************************************************************************
> Best regards,
> Marek Vasut
>
Best regards,
Jos? Gon?alves
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
2012-09-16 9:45 ` José Miguel Gonçalves
@ 2012-09-16 10:06 ` Marek Vasut
2012-09-16 10:16 ` José Miguel Gonçalves
0 siblings, 1 reply; 84+ messages in thread
From: Marek Vasut @ 2012-09-16 10:06 UTC (permalink / raw)
To: u-boot
Dear Jos? Miguel Gon?alves,
> On 09/15/2012 07:03 PM, Marek Vasut wrote:
> > Dear Jos? Miguel Gon?alves,
> >
> >> Jumping to board_init_r is not performed due to a bug on address
> >> computation.
> >
> > Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any
> > misbehavior on my arm926 boards.
>
> Maybe because you are not using it to build an SPL?
I do ... and I use CONFIG_SPL_TEXT_BASE properly .
> Please check the same chunk of code in other start.S for arm1176 and
> armv7. They have the same code that I put for arm926ejs.
Please wait and please first explain what is the issue.
> >> Relocation offsets are not needed when building SPL.
> >
> > Do they cause any trouble?
>
> No! Just not needed.
>
> >> Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
> >> ---
> >>
> >> Changes for v2:
> >> - None
> >>
> >> ---
> >>
> >> arch/arm/cpu/arm926ejs/start.S | 4 +++-
> >> 1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm/cpu/arm926ejs/start.S
> >> b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644
> >> --- a/arch/arm/cpu/arm926ejs/start.S
> >> +++ b/arch/arm/cpu/arm926ejs/start.S
> >>
> >> @@ -325,7 +325,7 @@ _nand_boot_ofs:
> >> .word nand_boot
> >>
> >> #else
> >>
> >> ldr r0, _board_init_r_ofs
> >>
> >> - ldr r1, _TEXT_BASE
> >> + adr r1, _start
> >>
> >> add lr, r0, r1
> >> add lr, lr, r9
> >> /* setup parameters for board_init_r */
> >>
> >> @@ -338,12 +338,14 @@ _board_init_r_ofs:
> >> .word board_init_r - _start
> >>
> >> #endif
> >>
> >> +#ifndef CONFIG_SPL_BUILD
> >>
> >> _rel_dyn_start_ofs:
> >> .word __rel_dyn_start - _start
> >>
> >> _rel_dyn_end_ofs:
> >> .word __rel_dyn_end - _start
> >>
> >> _dynsym_start_ofs:
> >> .word __dynsym_start - _start
> >>
> >> +#endif
> >>
> >> /*
> >>
> >> *********************************************************************
> >> ****
> >
> > Best regards,
> > Marek Vasut
>
> Best regards,
> Jos? Gon?alves
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
2012-09-16 10:06 ` Marek Vasut
@ 2012-09-16 10:16 ` José Miguel Gonçalves
2012-09-16 15:36 ` Marek Vasut
0 siblings, 1 reply; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-16 10:16 UTC (permalink / raw)
To: u-boot
On 09/16/2012 11:06 AM, Marek Vasut wrote:
> Dear Jos? Miguel Gon?alves,
>
>> On 09/15/2012 07:03 PM, Marek Vasut wrote:
>>> Dear Jos? Miguel Gon?alves,
>>>
>>>> Jumping to board_init_r is not performed due to a bug on address
>>>> computation.
>>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any
>>> misbehavior on my arm926 boards.
>> Maybe because you are not using it to build an SPL?
> I do ... and I use CONFIG_SPL_TEXT_BASE properly .
>
>> Please check the same chunk of code in other start.S for arm1176 and
>> armv7. They have the same code that I put for arm926ejs.
> Please wait and please first explain what is the issue.
The issue is what I've explained in the patch comments. Without this
change the code never reaches board_init_r in the SPL and I think I have
all the configurations correctly set. If the bug is not from here please
suggest me what I need to change in the configuration in order to
correctly boot my board.
>
>>>> Relocation offsets are not needed when building SPL.
>>> Do they cause any trouble?
>> No! Just not needed.
>>
>>>> Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
>>>> ---
>>>>
>>>> Changes for v2:
>>>> - None
>>>>
>>>> ---
>>>>
>>>> arch/arm/cpu/arm926ejs/start.S | 4 +++-
>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm/cpu/arm926ejs/start.S
>>>> b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644
>>>> --- a/arch/arm/cpu/arm926ejs/start.S
>>>> +++ b/arch/arm/cpu/arm926ejs/start.S
>>>>
>>>> @@ -325,7 +325,7 @@ _nand_boot_ofs:
>>>> .word nand_boot
>>>>
>>>> #else
>>>>
>>>> ldr r0, _board_init_r_ofs
>>>>
>>>> - ldr r1, _TEXT_BASE
>>>> + adr r1, _start
>>>>
>>>> add lr, r0, r1
>>>> add lr, lr, r9
>>>> /* setup parameters for board_init_r */
>>>>
>>>> @@ -338,12 +338,14 @@ _board_init_r_ofs:
>>>> .word board_init_r - _start
>>>>
>>>> #endif
>>>>
>>>> +#ifndef CONFIG_SPL_BUILD
>>>>
>>>> _rel_dyn_start_ofs:
>>>> .word __rel_dyn_start - _start
>>>>
>>>> _rel_dyn_end_ofs:
>>>> .word __rel_dyn_end - _start
>>>>
>>>> _dynsym_start_ofs:
>>>> .word __dynsym_start - _start
>>>>
>>>> +#endif
>>>>
>>>> /*
>>>>
>>>> *********************************************************************
>>>> ****
>>> Best regards,
>>> Marek Vasut
>> Best regards,
>> Jos? Gon?alves
> Best regards,
> Marek Vasut
Best regards,
Jos? Gon?alves
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
2012-09-16 10:16 ` José Miguel Gonçalves
@ 2012-09-16 15:36 ` Marek Vasut
2012-09-16 16:26 ` José Miguel Gonçalves
` (2 more replies)
0 siblings, 3 replies; 84+ messages in thread
From: Marek Vasut @ 2012-09-16 15:36 UTC (permalink / raw)
To: u-boot
Dear Jos? Miguel Gon?alves,
> On 09/16/2012 11:06 AM, Marek Vasut wrote:
> > Dear Jos? Miguel Gon?alves,
> >
> >> On 09/15/2012 07:03 PM, Marek Vasut wrote:
> >>> Dear Jos? Miguel Gon?alves,
> >>>
> >>>> Jumping to board_init_r is not performed due to a bug on address
> >>>> computation.
> >>>
> >>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any
> >>> misbehavior on my arm926 boards.
> >>
> >> Maybe because you are not using it to build an SPL?
> >
> > I do ... and I use CONFIG_SPL_TEXT_BASE properly .
>
> >> Please check the same chunk of code in other start.S for arm1176 and
> >> armv7. They have the same code that I put for arm926ejs.
> >
> > Please wait and please first explain what is the issue.
>
> The issue is what I've explained in the patch comments.
"Jumping to board_init_r is not performed due to a bug on address computation."
Ok, I don't know how to replicate the bug from this comment or what effects it
causes or ... well, anything. So please, try to be more elaborate in your patch
description next time. Anyway ..
> Without this
> change the code never reaches board_init_r in the SPL and I think I have
> all the configurations correctly set.
I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only
to load the real U-Boot from whatever media, so you usually use either NAND SPL
or something like that.
What do you boot the rest from ?
> If the bug is not from here please
> suggest me what I need to change in the configuration in order to
> correctly boot my board.
>
> >>>> Relocation offsets are not needed when building SPL.
> >>>
> >>> Do they cause any trouble?
> >>
> >> No! Just not needed.
> >>
> >>>> Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
> >>>> ---
> >>>>
> >>>> Changes for v2:
> >>>> - None
> >>>>
> >>>> ---
> >>>>
> >>>> arch/arm/cpu/arm926ejs/start.S | 4 +++-
> >>>> 1 file changed, 3 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/arch/arm/cpu/arm926ejs/start.S
> >>>> b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644
> >>>> --- a/arch/arm/cpu/arm926ejs/start.S
> >>>> +++ b/arch/arm/cpu/arm926ejs/start.S
> >>>>
> >>>> @@ -325,7 +325,7 @@ _nand_boot_ofs:
> >>>> .word nand_boot
> >>>>
> >>>> #else
> >>>>
> >>>> ldr r0, _board_init_r_ofs
> >>>>
> >>>> - ldr r1, _TEXT_BASE
> >>>> + adr r1, _start
> >>>>
> >>>> add lr, r0, r1
> >>>> add lr, lr, r9
> >>>> /* setup parameters for board_init_r */
> >>>>
> >>>> @@ -338,12 +338,14 @@ _board_init_r_ofs:
> >>>> .word board_init_r - _start
> >>>>
> >>>> #endif
> >>>>
> >>>> +#ifndef CONFIG_SPL_BUILD
> >>>>
> >>>> _rel_dyn_start_ofs:
> >>>> .word __rel_dyn_start - _start
> >>>>
> >>>> _rel_dyn_end_ofs:
> >>>> .word __rel_dyn_end - _start
> >>>>
> >>>> _dynsym_start_ofs:
> >>>> .word __dynsym_start - _start
> >>>>
> >>>> +#endif
> >>>>
> >>>> /*
> >>>>
> >>>> ******************************************************************
> >>>> *** ****
> >>>
> >>> Best regards,
> >>> Marek Vasut
> >>
> >> Best regards,
> >> Jos? Gon?alves
> >
> > Best regards,
> > Marek Vasut
>
> Best regards,
> Jos? Gon?alves
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
2012-09-16 15:36 ` Marek Vasut
@ 2012-09-16 16:26 ` José Miguel Gonçalves
2012-09-16 17:17 ` Marek Vasut
2012-09-17 6:28 ` Christian Riesch
2012-09-17 17:18 ` Tom Rini
2 siblings, 1 reply; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-16 16:26 UTC (permalink / raw)
To: u-boot
On 09/16/2012 04:36 PM, Marek Vasut wrote:
> Dear Jos? Miguel Gon?alves,
>
>> On 09/16/2012 11:06 AM, Marek Vasut wrote:
>>> Dear Jos? Miguel Gon?alves,
>>>
>>>> On 09/15/2012 07:03 PM, Marek Vasut wrote:
>>>>> Dear Jos? Miguel Gon?alves,
>>>>>
>>>>>> Jumping to board_init_r is not performed due to a bug on address
>>>>>> computation.
>>>>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any
>>>>> misbehavior on my arm926 boards.
>>>> Maybe because you are not using it to build an SPL?
>>> I do ... and I use CONFIG_SPL_TEXT_BASE properly .
>>>> Please check the same chunk of code in other start.S for arm1176 and
>>>> armv7. They have the same code that I put for arm926ejs.
>>> Please wait and please first explain what is the issue.
>> The issue is what I've explained in the patch comments.
> "Jumping to board_init_r is not performed due to a bug on address computation."
>
> Ok, I don't know how to replicate the bug from this comment or what effects it
> causes or ... well, anything. So please, try to be more elaborate in your patch
> description next time. Anyway ..
My bad. I should be more explicit on the patch description.
>> Without this
>> change the code never reaches board_init_r in the SPL and I think I have
>> all the configurations correctly set.
> I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only
> to load the real U-Boot from whatever media, so you usually use either NAND SPL
> or something like that.
>
> What do you boot the rest from ?
Both SPL and U-Boot are in NAND Flash.
The board's SPL code in board/boardcon/mini2416/mini2416_spl.c that
needs this patch was based on existing code from
arch/arm/cpu/arm926ejs/davinci/spl.c and arm/cpu/armv7/omap-common/spl.c
The need to call relocate_code() in board_init_f() is explained on the
SPL source comment, i.e., only to initialize .bss before we could use it
in board_init_r() (in the serial driver initialization).
>
>> If the bug is not from here please
>> suggest me what I need to change in the configuration in order to
>> correctly boot my board.
>>
>>>>>> Relocation offsets are not needed when building SPL.
>>>>> Do they cause any trouble?
>>>> No! Just not needed.
>>>>
>>>>>> Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
>>>>>> ---
>>>>>>
>>>>>> Changes for v2:
>>>>>> - None
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> arch/arm/cpu/arm926ejs/start.S | 4 +++-
>>>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/arch/arm/cpu/arm926ejs/start.S
>>>>>> b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644
>>>>>> --- a/arch/arm/cpu/arm926ejs/start.S
>>>>>> +++ b/arch/arm/cpu/arm926ejs/start.S
>>>>>>
>>>>>> @@ -325,7 +325,7 @@ _nand_boot_ofs:
>>>>>> .word nand_boot
>>>>>>
>>>>>> #else
>>>>>>
>>>>>> ldr r0, _board_init_r_ofs
>>>>>>
>>>>>> - ldr r1, _TEXT_BASE
>>>>>> + adr r1, _start
>>>>>>
>>>>>> add lr, r0, r1
>>>>>> add lr, lr, r9
>>>>>> /* setup parameters for board_init_r */
>>>>>>
>>>>>> @@ -338,12 +338,14 @@ _board_init_r_ofs:
>>>>>> .word board_init_r - _start
>>>>>>
>>>>>> #endif
>>>>>>
>>>>>> +#ifndef CONFIG_SPL_BUILD
>>>>>>
>>>>>> _rel_dyn_start_ofs:
>>>>>> .word __rel_dyn_start - _start
>>>>>>
>>>>>> _rel_dyn_end_ofs:
>>>>>> .word __rel_dyn_end - _start
>>>>>>
>>>>>> _dynsym_start_ofs:
>>>>>> .word __dynsym_start - _start
>>>>>>
>>>>>> +#endif
>>>>>>
>>>>>> /*
>>>>>>
>>>>>> ******************************************************************
>>>>>> *** ****
>>>>> Best regards,
>>>>> Marek Vasut
>>>> Best regards,
>>>> Jos? Gon?alves
>>> Best regards,
>>> Marek Vasut
>> Best regards,
>> Jos? Gon?alves
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
2012-09-16 16:26 ` José Miguel Gonçalves
@ 2012-09-16 17:17 ` Marek Vasut
0 siblings, 0 replies; 84+ messages in thread
From: Marek Vasut @ 2012-09-16 17:17 UTC (permalink / raw)
To: u-boot
Dear Jos? Miguel Gon?alves,
> On 09/16/2012 04:36 PM, Marek Vasut wrote:
> > Dear Jos? Miguel Gon?alves,
> >
> >> On 09/16/2012 11:06 AM, Marek Vasut wrote:
> >>> Dear Jos? Miguel Gon?alves,
> >>>
> >>>> On 09/15/2012 07:03 PM, Marek Vasut wrote:
> >>>>> Dear Jos? Miguel Gon?alves,
> >>>>>
> >>>>>> Jumping to board_init_r is not performed due to a bug on address
> >>>>>> computation.
> >>>>>
> >>>>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any
> >>>>> misbehavior on my arm926 boards.
> >>>>
> >>>> Maybe because you are not using it to build an SPL?
> >>>
> >>> I do ... and I use CONFIG_SPL_TEXT_BASE properly .
> >>>
> >>>> Please check the same chunk of code in other start.S for arm1176 and
> >>>> armv7. They have the same code that I put for arm926ejs.
> >>>
> >>> Please wait and please first explain what is the issue.
> >>
> >> The issue is what I've explained in the patch comments.
> >
> > "Jumping to board_init_r is not performed due to a bug on address
> > computation."
> >
> > Ok, I don't know how to replicate the bug from this comment or what
> > effects it causes or ... well, anything. So please, try to be more
> > elaborate in your patch description next time. Anyway ..
>
> My bad. I should be more explicit on the patch description.
>
> >> Without this
> >> change the code never reaches board_init_r in the SPL and I think I have
> >> all the configurations correctly set.
> >
> > I wonder why you'd ever want to reach board_init_r in the SPL. SPL is
> > there only to load the real U-Boot from whatever media, so you usually
> > use either NAND SPL or something like that.
> >
> > What do you boot the rest from ?
>
> Both SPL and U-Boot are in NAND Flash.
>
> The board's SPL code in board/boardcon/mini2416/mini2416_spl.c that
> needs this patch was based on existing code from
> arch/arm/cpu/arm926ejs/davinci/spl.c and arm/cpu/armv7/omap-common/spl.c
CCing Tom, he's the SPL expert.
> The need to call relocate_code() in board_init_f() is explained on the
> SPL source comment, i.e., only to initialize .bss before we could use it
> in board_init_r() (in the serial driver initialization).
>
> >> If the bug is not from here please
> >> suggest me what I need to change in the configuration in order to
> >> correctly boot my board.
> >>
> >>>>>> Relocation offsets are not needed when building SPL.
> >>>>>
> >>>>> Do they cause any trouble?
> >>>>
> >>>> No! Just not needed.
> >>>>
> >>>>>> Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
> >>>>>> ---
> >>>>>>
> >>>>>> Changes for v2:
> >>>>>> - None
> >>>>>>
> >>>>>> ---
> >>>>>>
> >>>>>> arch/arm/cpu/arm926ejs/start.S | 4 +++-
> >>>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
> >>>>>>
> >>>>>> diff --git a/arch/arm/cpu/arm926ejs/start.S
> >>>>>> b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644
> >>>>>> --- a/arch/arm/cpu/arm926ejs/start.S
> >>>>>> +++ b/arch/arm/cpu/arm926ejs/start.S
> >>>>>>
> >>>>>> @@ -325,7 +325,7 @@ _nand_boot_ofs:
> >>>>>> .word nand_boot
> >>>>>>
> >>>>>> #else
> >>>>>>
> >>>>>> ldr r0, _board_init_r_ofs
> >>>>>>
> >>>>>> - ldr r1, _TEXT_BASE
> >>>>>> + adr r1, _start
> >>>>>>
> >>>>>> add lr, r0, r1
> >>>>>> add lr, lr, r9
> >>>>>> /* setup parameters for board_init_r */
> >>>>>>
> >>>>>> @@ -338,12 +338,14 @@ _board_init_r_ofs:
> >>>>>> .word board_init_r - _start
> >>>>>>
> >>>>>> #endif
> >>>>>>
> >>>>>> +#ifndef CONFIG_SPL_BUILD
> >>>>>>
> >>>>>> _rel_dyn_start_ofs:
> >>>>>> .word __rel_dyn_start - _start
> >>>>>>
> >>>>>> _rel_dyn_end_ofs:
> >>>>>> .word __rel_dyn_end - _start
> >>>>>>
> >>>>>> _dynsym_start_ofs:
> >>>>>> .word __dynsym_start - _start
> >>>>>>
> >>>>>> +#endif
> >>>>>>
> >>>>>> /*
> >>>>>>
> >>>>>> ***************************************************************
> >>>>>> *** *** ****
> >>>>>
> >>>>> Best regards,
> >>>>> Marek Vasut
> >>>>
> >>>> Best regards,
> >>>> Jos? Gon?alves
> >>>
> >>> Best regards,
> >>> Marek Vasut
> >>
> >> Best regards,
> >> Jos? Gon?alves
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
2012-09-16 15:36 ` Marek Vasut
2012-09-16 16:26 ` José Miguel Gonçalves
@ 2012-09-17 6:28 ` Christian Riesch
2012-09-17 8:34 ` José Miguel Gonçalves
2012-09-17 17:18 ` Tom Rini
2 siblings, 1 reply; 84+ messages in thread
From: Christian Riesch @ 2012-09-17 6:28 UTC (permalink / raw)
To: u-boot
Hi,
On Sun, Sep 16, 2012 at 5:36 PM, Marek Vasut <marex@denx.de> wrote:
> Dear Jos? Miguel Gon?alves,
>
>> On 09/16/2012 11:06 AM, Marek Vasut wrote:
>> > Dear Jos? Miguel Gon?alves,
>> >
>> >> On 09/15/2012 07:03 PM, Marek Vasut wrote:
>> >>> Dear Jos? Miguel Gon?alves,
>> >>>
>> >>>> Jumping to board_init_r is not performed due to a bug on address
>> >>>> computation.
>> >>>
>> >>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any
>> >>> misbehavior on my arm926 boards.
>> >>
>> >> Maybe because you are not using it to build an SPL?
>> >
>> > I do ... and I use CONFIG_SPL_TEXT_BASE properly .
>>
>> >> Please check the same chunk of code in other start.S for arm1176 and
>> >> armv7. They have the same code that I put for arm926ejs.
>> >
>> > Please wait and please first explain what is the issue.
>>
>> The issue is what I've explained in the patch comments.
>
> "Jumping to board_init_r is not performed due to a bug on address computation."
>
> Ok, I don't know how to replicate the bug from this comment or what effects it
> causes or ... well, anything. So please, try to be more elaborate in your patch
> description next time. Anyway ..
Same for me - I have no idea what you are trying to fix here. In my
SPL configuration, _TEXT_BASE and _start point to the same location,
so please explain why they are different on your board.
>> Without this
>> change the code never reaches board_init_r in the SPL and I think I have
>> all the configurations correctly set.
>
> I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only
> to load the real U-Boot from whatever media, so you usually use either NAND SPL
> or something like that.
>
Marek, going into board_init_r is fine for SPL, for example the
davinci SPL does some hw initialization in board_init_f and then loads
u-boot in board_init_r.
Regards, Christian
> What do you boot the rest from ?
>
>> If the bug is not from here please
>> suggest me what I need to change in the configuration in order to
>> correctly boot my board.
>>
>> >>>> Relocation offsets are not needed when building SPL.
>> >>>
>> >>> Do they cause any trouble?
>> >>
>> >> No! Just not needed.
>> >>
>> >>>> Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
>> >>>> ---
>> >>>>
>> >>>> Changes for v2:
>> >>>> - None
>> >>>>
>> >>>> ---
>> >>>>
>> >>>> arch/arm/cpu/arm926ejs/start.S | 4 +++-
>> >>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>> >>>>
>> >>>> diff --git a/arch/arm/cpu/arm926ejs/start.S
>> >>>> b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644
>> >>>> --- a/arch/arm/cpu/arm926ejs/start.S
>> >>>> +++ b/arch/arm/cpu/arm926ejs/start.S
>> >>>>
>> >>>> @@ -325,7 +325,7 @@ _nand_boot_ofs:
>> >>>> .word nand_boot
>> >>>>
>> >>>> #else
>> >>>>
>> >>>> ldr r0, _board_init_r_ofs
>> >>>>
>> >>>> - ldr r1, _TEXT_BASE
>> >>>> + adr r1, _start
>> >>>>
>> >>>> add lr, r0, r1
>> >>>> add lr, lr, r9
>> >>>> /* setup parameters for board_init_r */
>> >>>>
>> >>>> @@ -338,12 +338,14 @@ _board_init_r_ofs:
>> >>>> .word board_init_r - _start
>> >>>>
>> >>>> #endif
>> >>>>
>> >>>> +#ifndef CONFIG_SPL_BUILD
>> >>>>
>> >>>> _rel_dyn_start_ofs:
>> >>>> .word __rel_dyn_start - _start
>> >>>>
>> >>>> _rel_dyn_end_ofs:
>> >>>> .word __rel_dyn_end - _start
>> >>>>
>> >>>> _dynsym_start_ofs:
>> >>>> .word __dynsym_start - _start
>> >>>>
>> >>>> +#endif
>> >>>>
>> >>>> /*
>> >>>>
>> >>>> ******************************************************************
>> >>>> *** ****
>> >>>
>> >>> Best regards,
>> >>> Marek Vasut
>> >>
>> >> Best regards,
>> >> Jos? Gon?alves
>> >
>> > Best regards,
>> > Marek Vasut
>>
>> Best regards,
>> Jos? Gon?alves
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
2012-09-16 9:27 ` José Miguel Gonçalves
@ 2012-09-17 6:47 ` Christian Riesch
2012-09-17 8:30 ` José Miguel Gonçalves
0 siblings, 1 reply; 84+ messages in thread
From: Christian Riesch @ 2012-09-17 6:47 UTC (permalink / raw)
To: u-boot
Hi,
On Sun, Sep 16, 2012 at 11:27 AM, Jos? Miguel Gon?alves
<jose.goncalves@inov.pt> wrote:
> On 09/14/2012 08:08 PM, Tom Rini wrote:
>>
>> On Fri, Sep 14, 2012 at 06:29:01PM +0100, Jos?? Miguel Gon??alves wrote:
>>
>>> Samsung's S3C24XX SoCs need this in order to generate a binary image
>>> with the SPL and U-Boot concatenated.
>>>
>>> Signed-off-by: Jos?? Miguel Gon??alves <jose.goncalves@inov.pt>
>>> ---
>>> Changes for v2:
>>> - None
>>> ---
>>> Makefile | 7 ++++---
>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/Makefile b/Makefile
>>> index 058fb53..595b5f6 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -442,13 +442,14 @@ $(obj)u-boot.sha1: $(obj)u-boot.bin
>>> $(obj)u-boot.dis: $(obj)u-boot
>>> $(OBJDUMP) -d $< > $@
>>> -$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
>>> +$(obj)u-boot-ubl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
>>> $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary
>>> $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin
>>> cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin >
>>> $(obj)u-boot-ubl.bin
>>> + rm $(obj)spl/u-boot-spl-pad.bin
>>> +
>>> +$(obj)u-boot.ubl: $(obj)u-boot-ubl.bin
>>> $(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \
>>> -e $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin
>>> $(obj)u-boot.ubl
>>> - rm $(obj)u-boot-ubl.bin
>>> - rm $(obj)spl/u-boot-spl-pad.bin
>>> $(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
>>> $(obj)tools/mkimage -s -n $(if
>>> $(CONFIG_AIS_CONFIG_FILE),$(CONFIG_AIS_CONFIG_FILE),"/dev/null") \
>>
>> This diff is hard to read, but what exactly are you changing? The
>> u-boot-ubl target is also used on TI platforms. It looks like you're
>> making it such that u-boot-ubl.bin produces the old binary and
>> u-boot-ubl adds a new target which is the mkimage header on top of the
>> same bits as before, but without possibly padding the output image. I
>> suspect in your case you could just set PAD_TO to 8192 in
>> board/../config.mk and use the existing target.
>>
>
> In the S3C2416 I don't need the mkimage stuff. I only need the raw SPL image
> padded at 8KB concatenated with the standard U-Boot. What I've done was to
> split the existing u-boot-ubl target in two; u-boot-ubl.bin, that I use to
> program the Flash, and u-boot-ubl that remains with the same functionality
> as before, just now it depends on u-boot-ubl.bin.
I think you should drop the UBL names from your padding target
(u-boot-ubl.bin) since this is TI specific, use something more
generic.
Regards, Christian
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
2012-09-17 6:47 ` Christian Riesch
@ 2012-09-17 8:30 ` José Miguel Gonçalves
2012-09-17 9:10 ` Christian Riesch
0 siblings, 1 reply; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-17 8:30 UTC (permalink / raw)
To: u-boot
On 09/17/2012 07:47 AM, Christian Riesch wrote:
> Hi,
>
> On Sun, Sep 16, 2012 at 11:27 AM, Jos? Miguel Gon?alves
> <jose.goncalves@inov.pt> wrote:
>> On 09/14/2012 08:08 PM, Tom Rini wrote:
>>> On Fri, Sep 14, 2012 at 06:29:01PM +0100, Jos?? Miguel Gon??alves wrote:
>>>
>>>> Samsung's S3C24XX SoCs need this in order to generate a binary image
>>>> with the SPL and U-Boot concatenated.
>>>>
>>>> Signed-off-by: Jos?? Miguel Gon??alves <jose.goncalves@inov.pt>
>>>> ---
>>>> Changes for v2:
>>>> - None
>>>> ---
>>>> Makefile | 7 ++++---
>>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/Makefile b/Makefile
>>>> index 058fb53..595b5f6 100644
>>>> --- a/Makefile
>>>> +++ b/Makefile
>>>> @@ -442,13 +442,14 @@ $(obj)u-boot.sha1: $(obj)u-boot.bin
>>>> $(obj)u-boot.dis: $(obj)u-boot
>>>> $(OBJDUMP) -d $< > $@
>>>> -$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
>>>> +$(obj)u-boot-ubl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
>>>> $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary
>>>> $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin
>>>> cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin >
>>>> $(obj)u-boot-ubl.bin
>>>> + rm $(obj)spl/u-boot-spl-pad.bin
>>>> +
>>>> +$(obj)u-boot.ubl: $(obj)u-boot-ubl.bin
>>>> $(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \
>>>> -e $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin
>>>> $(obj)u-boot.ubl
>>>> - rm $(obj)u-boot-ubl.bin
>>>> - rm $(obj)spl/u-boot-spl-pad.bin
>>>> $(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
>>>> $(obj)tools/mkimage -s -n $(if
>>>> $(CONFIG_AIS_CONFIG_FILE),$(CONFIG_AIS_CONFIG_FILE),"/dev/null") \
>>> This diff is hard to read, but what exactly are you changing? The
>>> u-boot-ubl target is also used on TI platforms. It looks like you're
>>> making it such that u-boot-ubl.bin produces the old binary and
>>> u-boot-ubl adds a new target which is the mkimage header on top of the
>>> same bits as before, but without possibly padding the output image. I
>>> suspect in your case you could just set PAD_TO to 8192 in
>>> board/../config.mk and use the existing target.
>>>
>> In the S3C2416 I don't need the mkimage stuff. I only need the raw SPL image
>> padded at 8KB concatenated with the standard U-Boot. What I've done was to
>> split the existing u-boot-ubl target in two; u-boot-ubl.bin, that I use to
>> program the Flash, and u-boot-ubl that remains with the same functionality
>> as before, just now it depends on u-boot-ubl.bin.
> I think you should drop the UBL names from your padding target
> (u-boot-ubl.bin) since this is TI specific, use something more
> generic.
I only reused a temporary filename used for the u-boot-ubl target and
make it a new target.
If you think this is not an adequate name, can you suggest a new one?
Best regards,
Jos? Gon?alves
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
2012-09-17 6:28 ` Christian Riesch
@ 2012-09-17 8:34 ` José Miguel Gonçalves
2012-09-17 9:03 ` Christian Riesch
0 siblings, 1 reply; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-17 8:34 UTC (permalink / raw)
To: u-boot
On 09/17/2012 07:28 AM, Christian Riesch wrote:
> Hi,
>
> On Sun, Sep 16, 2012 at 5:36 PM, Marek Vasut <marex@denx.de> wrote:
>> Dear Jos? Miguel Gon?alves,
>>
>>> On 09/16/2012 11:06 AM, Marek Vasut wrote:
>>>> Dear Jos? Miguel Gon?alves,
>>>>
>>>>> On 09/15/2012 07:03 PM, Marek Vasut wrote:
>>>>>> Dear Jos? Miguel Gon?alves,
>>>>>>
>>>>>>> Jumping to board_init_r is not performed due to a bug on address
>>>>>>> computation.
>>>>>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any
>>>>>> misbehavior on my arm926 boards.
>>>>> Maybe because you are not using it to build an SPL?
>>>> I do ... and I use CONFIG_SPL_TEXT_BASE properly .
>>>>> Please check the same chunk of code in other start.S for arm1176 and
>>>>> armv7. They have the same code that I put for arm926ejs.
>>>> Please wait and please first explain what is the issue.
>>> The issue is what I've explained in the patch comments.
>> "Jumping to board_init_r is not performed due to a bug on address computation."
>>
>> Ok, I don't know how to replicate the bug from this comment or what effects it
>> causes or ... well, anything. So please, try to be more elaborate in your patch
>> description next time. Anyway ..
> Same for me - I have no idea what you are trying to fix here. In my
> SPL configuration, _TEXT_BASE and _start point to the same location,
> so please explain why they are different on your board.
They are different because of how start.S is implemented in arm926ejs.
In my SPL map file I see:
.text 0x0000000000000000 0xc24
arch/arm/cpu/arm926ejs/start.o(.text)
.text 0x0000000000000000 0x120
arch/arm/cpu/arm926ejs/start.o
0x0000000000000000 _start
0x0000000000000040 _TEXT_BASE
0x0000000000000044 _bss_start_ofs
0x0000000000000048 _bss_end_ofs
0x000000000000004c _end_ofs
0x0000000000000050 IRQ_STACK_START_IN
0x0000000000000074 relocate_code
>>> Without this
>>> change the code never reaches board_init_r in the SPL and I think I have
>>> all the configurations correctly set.
>> I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only
>> to load the real U-Boot from whatever media, so you usually use either NAND SPL
>> or something like that.
>>
> Marek, going into board_init_r is fine for SPL, for example the
> davinci SPL does some hw initialization in board_init_f and then loads
> u-boot in board_init_r.
> Regards, Christian
>
>> What do you boot the rest from ?
>>
>>> If the bug is not from here please
>>> suggest me what I need to change in the configuration in order to
>>> correctly boot my board.
>>>
>>>>>>> Relocation offsets are not needed when building SPL.
>>>>>> Do they cause any trouble?
>>>>> No! Just not needed.
>>>>>
>>>>>>> Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
>>>>>>> ---
>>>>>>>
>>>>>>> Changes for v2:
>>>>>>> - None
>>>>>>>
>>>>>>> ---
>>>>>>>
>>>>>>> arch/arm/cpu/arm926ejs/start.S | 4 +++-
>>>>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/arch/arm/cpu/arm926ejs/start.S
>>>>>>> b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644
>>>>>>> --- a/arch/arm/cpu/arm926ejs/start.S
>>>>>>> +++ b/arch/arm/cpu/arm926ejs/start.S
>>>>>>>
>>>>>>> @@ -325,7 +325,7 @@ _nand_boot_ofs:
>>>>>>> .word nand_boot
>>>>>>>
>>>>>>> #else
>>>>>>>
>>>>>>> ldr r0, _board_init_r_ofs
>>>>>>>
>>>>>>> - ldr r1, _TEXT_BASE
>>>>>>> + adr r1, _start
>>>>>>>
>>>>>>> add lr, r0, r1
>>>>>>> add lr, lr, r9
>>>>>>> /* setup parameters for board_init_r */
>>>>>>>
>>>>>>> @@ -338,12 +338,14 @@ _board_init_r_ofs:
>>>>>>> .word board_init_r - _start
>>>>>>>
>>>>>>> #endif
>>>>>>>
>>>>>>> +#ifndef CONFIG_SPL_BUILD
>>>>>>>
>>>>>>> _rel_dyn_start_ofs:
>>>>>>> .word __rel_dyn_start - _start
>>>>>>>
>>>>>>> _rel_dyn_end_ofs:
>>>>>>> .word __rel_dyn_end - _start
>>>>>>>
>>>>>>> _dynsym_start_ofs:
>>>>>>> .word __dynsym_start - _start
>>>>>>>
>>>>>>> +#endif
>>>>>>>
>>>>>>> /*
>>>>>>>
>>>>>>> ******************************************************************
>>>>>>> *** ****
>>>>>> Best regards,
>>>>>> Marek Vasut
>>>>> Best regards,
>>>>> Jos? Gon?alves
>>>> Best regards,
>>>> Marek Vasut
>>> Best regards,
>>> Jos? Gon?alves
Best regards,
Jos? Gon?alves
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
2012-09-17 8:34 ` José Miguel Gonçalves
@ 2012-09-17 9:03 ` Christian Riesch
2012-09-17 9:20 ` José Miguel Gonçalves
0 siblings, 1 reply; 84+ messages in thread
From: Christian Riesch @ 2012-09-17 9:03 UTC (permalink / raw)
To: u-boot
Hi,
On Mon, Sep 17, 2012 at 10:34 AM, Jos? Miguel Gon?alves
<jose.goncalves@inov.pt> wrote:
> On 09/17/2012 07:28 AM, Christian Riesch wrote:
>>
>> Hi,
>>
>> On Sun, Sep 16, 2012 at 5:36 PM, Marek Vasut <marex@denx.de> wrote:
>>>
>>> Dear Jos? Miguel Gon?alves,
>>>
>>>> On 09/16/2012 11:06 AM, Marek Vasut wrote:
>>>>>
>>>>> Dear Jos? Miguel Gon?alves,
>>>>>
>>>>>> On 09/15/2012 07:03 PM, Marek Vasut wrote:
>>>>>>>
>>>>>>> Dear Jos? Miguel Gon?alves,
>>>>>>>
>>>>>>>> Jumping to board_init_r is not performed due to a bug on address
>>>>>>>> computation.
>>>>>>>
>>>>>>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any
>>>>>>> misbehavior on my arm926 boards.
>>>>>>
>>>>>> Maybe because you are not using it to build an SPL?
>>>>>
>>>>> I do ... and I use CONFIG_SPL_TEXT_BASE properly .
>>>>>>
>>>>>> Please check the same chunk of code in other start.S for arm1176 and
>>>>>> armv7. They have the same code that I put for arm926ejs.
>>>>>
>>>>> Please wait and please first explain what is the issue.
>>>>
>>>> The issue is what I've explained in the patch comments.
>>>
>>> "Jumping to board_init_r is not performed due to a bug on address
>>> computation."
>>>
>>> Ok, I don't know how to replicate the bug from this comment or what
>>> effects it
>>> causes or ... well, anything. So please, try to be more elaborate in your
>>> patch
>>> description next time. Anyway ..
>>
>> Same for me - I have no idea what you are trying to fix here. In my
>> SPL configuration, _TEXT_BASE and _start point to the same location,
>> so please explain why they are different on your board.
>
>
> They are different because of how start.S is implemented in arm926ejs.
>
> In my SPL map file I see:
>
> .text 0x0000000000000000 0xc24
> arch/arm/cpu/arm926ejs/start.o(.text)
> .text 0x0000000000000000 0x120 arch/arm/cpu/arm926ejs/start.o
> 0x0000000000000000 _start
> 0x0000000000000040 _TEXT_BASE
> 0x0000000000000044 _bss_start_ofs
> 0x0000000000000048 _bss_end_ofs
> 0x000000000000004c _end_ofs
> 0x0000000000000050 IRQ_STACK_START_IN
> 0x0000000000000074 relocate_code
So _start is 0x00000000, and in your
config/include/include/configs/mini2416.h you have
#define CONFIG_SPL_TEXT_BASE 0x00000000
and in arch/arm/cpu/arm926ejs/start.S we have
.globl _TEXT_BASE
_TEXT_BASE:
#ifdef CONFIG_NAND_SPL /* deprecated, use instead CONFIG_SPL_BUILD */
.word CONFIG_SYS_TEXT_BASE
#else
#ifdef CONFIG_SPL_BUILD
.word CONFIG_SPL_TEXT_BASE
#else
.word CONFIG_SYS_TEXT_BASE
#endif
#endif
So
ldr r1, _TEXT_BASE
should be the same as
adr r1, _start
However, if you do not load your SPL to 0x00000000 but to another
address and execute it from there, it will be different, since adr
uses relative adressing, right? Are you sure you are loading it to
0x00000000?
Regards, Christian
>
>
>
>>>> Without this
>>>> change the code never reaches board_init_r in the SPL and I think I have
>>>> all the configurations correctly set.
>>>
>>> I wonder why you'd ever want to reach board_init_r in the SPL. SPL is
>>> there only
>>> to load the real U-Boot from whatever media, so you usually use either
>>> NAND SPL
>>> or something like that.
>>>
>> Marek, going into board_init_r is fine for SPL, for example the
>> davinci SPL does some hw initialization in board_init_f and then loads
>> u-boot in board_init_r.
>> Regards, Christian
>>
>>> What do you boot the rest from ?
>>>
>>>> If the bug is not from here please
>>>> suggest me what I need to change in the configuration in order to
>>>> correctly boot my board.
>>>>
>>>>>>>> Relocation offsets are not needed when building SPL.
>>>>>>>
>>>>>>> Do they cause any trouble?
>>>>>>
>>>>>> No! Just not needed.
>>>>>>
>>>>>>>> Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> Changes for v2:
>>>>>>>> - None
>>>>>>>>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> arch/arm/cpu/arm926ejs/start.S | 4 +++-
>>>>>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>>>
>>>>>>>> diff --git a/arch/arm/cpu/arm926ejs/start.S
>>>>>>>> b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644
>>>>>>>> --- a/arch/arm/cpu/arm926ejs/start.S
>>>>>>>> +++ b/arch/arm/cpu/arm926ejs/start.S
>>>>>>>>
>>>>>>>> @@ -325,7 +325,7 @@ _nand_boot_ofs:
>>>>>>>> .word nand_boot
>>>>>>>>
>>>>>>>> #else
>>>>>>>>
>>>>>>>> ldr r0, _board_init_r_ofs
>>>>>>>>
>>>>>>>> - ldr r1, _TEXT_BASE
>>>>>>>> + adr r1, _start
>>>>>>>>
>>>>>>>> add lr, r0, r1
>>>>>>>> add lr, lr, r9
>>>>>>>> /* setup parameters for board_init_r */
>>>>>>>>
>>>>>>>> @@ -338,12 +338,14 @@ _board_init_r_ofs:
>>>>>>>> .word board_init_r - _start
>>>>>>>>
>>>>>>>> #endif
>>>>>>>>
>>>>>>>> +#ifndef CONFIG_SPL_BUILD
>>>>>>>>
>>>>>>>> _rel_dyn_start_ofs:
>>>>>>>> .word __rel_dyn_start - _start
>>>>>>>>
>>>>>>>> _rel_dyn_end_ofs:
>>>>>>>> .word __rel_dyn_end - _start
>>>>>>>>
>>>>>>>> _dynsym_start_ofs:
>>>>>>>> .word __dynsym_start - _start
>>>>>>>>
>>>>>>>> +#endif
>>>>>>>>
>>>>>>>> /*
>>>>>>>>
>>>>>>>>
>>>>>>>> ******************************************************************
>>>>>>>> *** ****
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Marek Vasut
>>>>>>
>>>>>> Best regards,
>>>>>> Jos? Gon?alves
>>>>>
>>>>> Best regards,
>>>>> Marek Vasut
>>>>
>>>> Best regards,
>>>> Jos? Gon?alves
>
>
> Best regards,
> Jos? Gon?alves
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
2012-09-17 8:30 ` José Miguel Gonçalves
@ 2012-09-17 9:10 ` Christian Riesch
2012-09-17 9:24 ` José Miguel Gonçalves
0 siblings, 1 reply; 84+ messages in thread
From: Christian Riesch @ 2012-09-17 9:10 UTC (permalink / raw)
To: u-boot
On Mon, Sep 17, 2012 at 10:30 AM, Jos? Miguel Gon?alves
<jose.goncalves@inov.pt> wrote:
> On 09/17/2012 07:47 AM, Christian Riesch wrote:
>>
>> Hi,
>>
>> On Sun, Sep 16, 2012 at 11:27 AM, Jos? Miguel Gon?alves
>> <jose.goncalves@inov.pt> wrote:
>>>
>>> On 09/14/2012 08:08 PM, Tom Rini wrote:
>>>>
>>>> On Fri, Sep 14, 2012 at 06:29:01PM +0100, Jos?? Miguel Gon??alves wrote:
>>>>
>>>>> Samsung's S3C24XX SoCs need this in order to generate a binary image
>>>>> with the SPL and U-Boot concatenated.
>>>>>
>>>>> Signed-off-by: Jos?? Miguel Gon??alves <jose.goncalves@inov.pt>
>>>>> ---
>>>>> Changes for v2:
>>>>> - None
>>>>> ---
>>>>> Makefile | 7 ++++---
>>>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/Makefile b/Makefile
>>>>> index 058fb53..595b5f6 100644
>>>>> --- a/Makefile
>>>>> +++ b/Makefile
>>>>> @@ -442,13 +442,14 @@ $(obj)u-boot.sha1: $(obj)u-boot.bin
>>>>> $(obj)u-boot.dis: $(obj)u-boot
>>>>> $(OBJDUMP) -d $< > $@
>>>>> -$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
>>>>> +$(obj)u-boot-ubl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
>>>>> $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary
>>>>> $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin
>>>>> cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin >
>>>>> $(obj)u-boot-ubl.bin
>>>>> + rm $(obj)spl/u-boot-spl-pad.bin
>>>>> +
>>>>> +$(obj)u-boot.ubl: $(obj)u-boot-ubl.bin
>>>>> $(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \
>>>>> -e $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin
>>>>> $(obj)u-boot.ubl
>>>>> - rm $(obj)u-boot-ubl.bin
>>>>> - rm $(obj)spl/u-boot-spl-pad.bin
>>>>> $(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
>>>>> $(obj)tools/mkimage -s -n $(if
>>>>> $(CONFIG_AIS_CONFIG_FILE),$(CONFIG_AIS_CONFIG_FILE),"/dev/null") \
>>>>
>>>> This diff is hard to read, but what exactly are you changing? The
>>>> u-boot-ubl target is also used on TI platforms. It looks like you're
>>>> making it such that u-boot-ubl.bin produces the old binary and
>>>> u-boot-ubl adds a new target which is the mkimage header on top of the
>>>> same bits as before, but without possibly padding the output image. I
>>>> suspect in your case you could just set PAD_TO to 8192 in
>>>> board/../config.mk and use the existing target.
>>>>
>>> In the S3C2416 I don't need the mkimage stuff. I only need the raw SPL
>>> image
>>> padded at 8KB concatenated with the standard U-Boot. What I've done was
>>> to
>>> split the existing u-boot-ubl target in two; u-boot-ubl.bin, that I use
>>> to
>>> program the Flash, and u-boot-ubl that remains with the same
>>> functionality
>>> as before, just now it depends on u-boot-ubl.bin.
>>
>> I think you should drop the UBL names from your padding target
>> (u-boot-ubl.bin) since this is TI specific, use something more
>> generic.
>
>
> I only reused a temporary filename used for the u-boot-ubl target and make
> it a new target.
> If you think this is not an adequate name, can you suggest a new one?
u-boot.pad? u-boot-pad.bin?
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
2012-09-17 9:03 ` Christian Riesch
@ 2012-09-17 9:20 ` José Miguel Gonçalves
0 siblings, 0 replies; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-17 9:20 UTC (permalink / raw)
To: u-boot
Hi Christian,
On 09/17/2012 10:03 AM, Christian Riesch wrote:
> Hi,
>
> On Mon, Sep 17, 2012 at 10:34 AM, Jos? Miguel Gon?alves
> <jose.goncalves@inov.pt> wrote:
>> On 09/17/2012 07:28 AM, Christian Riesch wrote:
>>> Hi,
>>>
>>> On Sun, Sep 16, 2012 at 5:36 PM, Marek Vasut <marex@denx.de> wrote:
>>>> Dear Jos? Miguel Gon?alves,
>>>>
>>>>> On 09/16/2012 11:06 AM, Marek Vasut wrote:
>>>>>> Dear Jos? Miguel Gon?alves,
>>>>>>
>>>>>>> On 09/15/2012 07:03 PM, Marek Vasut wrote:
>>>>>>>> Dear Jos? Miguel Gon?alves,
>>>>>>>>
>>>>>>>>> Jumping to board_init_r is not performed due to a bug on address
>>>>>>>>> computation.
>>>>>>>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any
>>>>>>>> misbehavior on my arm926 boards.
>>>>>>> Maybe because you are not using it to build an SPL?
>>>>>> I do ... and I use CONFIG_SPL_TEXT_BASE properly .
>>>>>>> Please check the same chunk of code in other start.S for arm1176 and
>>>>>>> armv7. They have the same code that I put for arm926ejs.
>>>>>> Please wait and please first explain what is the issue.
>>>>> The issue is what I've explained in the patch comments.
>>>> "Jumping to board_init_r is not performed due to a bug on address
>>>> computation."
>>>>
>>>> Ok, I don't know how to replicate the bug from this comment or what
>>>> effects it
>>>> causes or ... well, anything. So please, try to be more elaborate in your
>>>> patch
>>>> description next time. Anyway ..
>>> Same for me - I have no idea what you are trying to fix here. In my
>>> SPL configuration, _TEXT_BASE and _start point to the same location,
>>> so please explain why they are different on your board.
>>
>> They are different because of how start.S is implemented in arm926ejs.
>>
>> In my SPL map file I see:
>>
>> .text 0x0000000000000000 0xc24
>> arch/arm/cpu/arm926ejs/start.o(.text)
>> .text 0x0000000000000000 0x120 arch/arm/cpu/arm926ejs/start.o
>> 0x0000000000000000 _start
>> 0x0000000000000040 _TEXT_BASE
>> 0x0000000000000044 _bss_start_ofs
>> 0x0000000000000048 _bss_end_ofs
>> 0x000000000000004c _end_ofs
>> 0x0000000000000050 IRQ_STACK_START_IN
>> 0x0000000000000074 relocate_code
> So _start is 0x00000000, and in your
> config/include/include/configs/mini2416.h you have
>
> #define CONFIG_SPL_TEXT_BASE 0x00000000
>
> and in arch/arm/cpu/arm926ejs/start.S we have
>
> .globl _TEXT_BASE
> _TEXT_BASE:
> #ifdef CONFIG_NAND_SPL /* deprecated, use instead CONFIG_SPL_BUILD */
> .word CONFIG_SYS_TEXT_BASE
> #else
> #ifdef CONFIG_SPL_BUILD
> .word CONFIG_SPL_TEXT_BASE
> #else
> .word CONFIG_SYS_TEXT_BASE
> #endif
> #endif
>
> So
>
> ldr r1, _TEXT_BASE
>
> should be the same as
>
> adr r1, _start
>
> However, if you do not load your SPL to 0x00000000 but to another
> address and execute it from there, it will be different, since adr
> uses relative adressing, right? Are you sure you are loading it to
> 0x00000000?
Not an expert on ARM assembly, so cannot give any feedback on the
differences between adr and ldr mnemonics.
What I know for a fact is that the S3C2416, when booting from it's
internal ROM, makes a copy of the first 8KB of the NAND flash to an
internal RAM (named SteppingStone), maps it at address 0 and the jumps
to the start of it. This mapping is not clear in Samsung's user manual
but I retrieved that information from here:
http://barebox.org/documentation/barebox-2011.05.0/dev_s3c24xx_arch.html
>
> Regards, Christian
>
>>
>>
>>>>> Without this
>>>>> change the code never reaches board_init_r in the SPL and I think I have
>>>>> all the configurations correctly set.
>>>> I wonder why you'd ever want to reach board_init_r in the SPL. SPL is
>>>> there only
>>>> to load the real U-Boot from whatever media, so you usually use either
>>>> NAND SPL
>>>> or something like that.
>>>>
>>> Marek, going into board_init_r is fine for SPL, for example the
>>> davinci SPL does some hw initialization in board_init_f and then loads
>>> u-boot in board_init_r.
>>> Regards, Christian
>>>
>>>> What do you boot the rest from ?
>>>>
>>>>> If the bug is not from here please
>>>>> suggest me what I need to change in the configuration in order to
>>>>> correctly boot my board.
>>>>>
>>>>>>>>> Relocation offsets are not needed when building SPL.
>>>>>>>> Do they cause any trouble?
>>>>>>> No! Just not needed.
>>>>>>>
>>>>>>>>> Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>> Changes for v2:
>>>>>>>>> - None
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>> arch/arm/cpu/arm926ejs/start.S | 4 +++-
>>>>>>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>>>>
>>>>>>>>> diff --git a/arch/arm/cpu/arm926ejs/start.S
>>>>>>>>> b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644
>>>>>>>>> --- a/arch/arm/cpu/arm926ejs/start.S
>>>>>>>>> +++ b/arch/arm/cpu/arm926ejs/start.S
>>>>>>>>>
>>>>>>>>> @@ -325,7 +325,7 @@ _nand_boot_ofs:
>>>>>>>>> .word nand_boot
>>>>>>>>>
>>>>>>>>> #else
>>>>>>>>>
>>>>>>>>> ldr r0, _board_init_r_ofs
>>>>>>>>>
>>>>>>>>> - ldr r1, _TEXT_BASE
>>>>>>>>> + adr r1, _start
>>>>>>>>>
>>>>>>>>> add lr, r0, r1
>>>>>>>>> add lr, lr, r9
>>>>>>>>> /* setup parameters for board_init_r */
>>>>>>>>>
>>>>>>>>> @@ -338,12 +338,14 @@ _board_init_r_ofs:
>>>>>>>>> .word board_init_r - _start
>>>>>>>>>
>>>>>>>>> #endif
>>>>>>>>>
>>>>>>>>> +#ifndef CONFIG_SPL_BUILD
>>>>>>>>>
>>>>>>>>> _rel_dyn_start_ofs:
>>>>>>>>> .word __rel_dyn_start - _start
>>>>>>>>>
>>>>>>>>> _rel_dyn_end_ofs:
>>>>>>>>> .word __rel_dyn_end - _start
>>>>>>>>>
>>>>>>>>> _dynsym_start_ofs:
>>>>>>>>> .word __dynsym_start - _start
>>>>>>>>>
>>>>>>>>> +#endif
>>>>>>>>>
>>>>>>>>> /*
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ******************************************************************
>>>>>>>>> *** ****
>>>>>>>> Best regards,
>>>>>>>> Marek Vasut
>>>>>>> Best regards,
>>>>>>> Jos? Gon?alves
>>>>>> Best regards,
>>>>>> Marek Vasut
>>>>> Best regards,
>>>>> Jos? Gon?alves
>>
>> Best regards,
>> Jos? Gon?alves
>
Best regards,
Jos? Gon?alves
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
2012-09-17 9:10 ` Christian Riesch
@ 2012-09-17 9:24 ` José Miguel Gonçalves
2012-09-17 14:45 ` Tom Rini
2012-09-17 16:27 ` Scott Wood
0 siblings, 2 replies; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-17 9:24 UTC (permalink / raw)
To: u-boot
On 09/17/2012 10:10 AM, Christian Riesch wrote:
> On Mon, Sep 17, 2012 at 10:30 AM, Jos? Miguel Gon?alves
> <jose.goncalves@inov.pt> wrote:
>> On 09/17/2012 07:47 AM, Christian Riesch wrote:
>>> Hi,
>>>
>>> On Sun, Sep 16, 2012 at 11:27 AM, Jos? Miguel Gon?alves
>>> <jose.goncalves@inov.pt> wrote:
>>>> On 09/14/2012 08:08 PM, Tom Rini wrote:
>>>>> On Fri, Sep 14, 2012 at 06:29:01PM +0100, Jos?? Miguel Gon??alves wrote:
>>>>>
>>>>>> Samsung's S3C24XX SoCs need this in order to generate a binary image
>>>>>> with the SPL and U-Boot concatenated.
>>>>>>
>>>>>> Signed-off-by: Jos?? Miguel Gon??alves <jose.goncalves@inov.pt>
>>>>>> ---
>>>>>> Changes for v2:
>>>>>> - None
>>>>>> ---
>>>>>> Makefile | 7 ++++---
>>>>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>>>>
>>>>>> diff --git a/Makefile b/Makefile
>>>>>> index 058fb53..595b5f6 100644
>>>>>> --- a/Makefile
>>>>>> +++ b/Makefile
>>>>>> @@ -442,13 +442,14 @@ $(obj)u-boot.sha1: $(obj)u-boot.bin
>>>>>> $(obj)u-boot.dis: $(obj)u-boot
>>>>>> $(OBJDUMP) -d $< > $@
>>>>>> -$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
>>>>>> +$(obj)u-boot-ubl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
>>>>>> $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary
>>>>>> $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin
>>>>>> cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin >
>>>>>> $(obj)u-boot-ubl.bin
>>>>>> + rm $(obj)spl/u-boot-spl-pad.bin
>>>>>> +
>>>>>> +$(obj)u-boot.ubl: $(obj)u-boot-ubl.bin
>>>>>> $(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \
>>>>>> -e $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin
>>>>>> $(obj)u-boot.ubl
>>>>>> - rm $(obj)u-boot-ubl.bin
>>>>>> - rm $(obj)spl/u-boot-spl-pad.bin
>>>>>> $(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
>>>>>> $(obj)tools/mkimage -s -n $(if
>>>>>> $(CONFIG_AIS_CONFIG_FILE),$(CONFIG_AIS_CONFIG_FILE),"/dev/null") \
>>>>> This diff is hard to read, but what exactly are you changing? The
>>>>> u-boot-ubl target is also used on TI platforms. It looks like you're
>>>>> making it such that u-boot-ubl.bin produces the old binary and
>>>>> u-boot-ubl adds a new target which is the mkimage header on top of the
>>>>> same bits as before, but without possibly padding the output image. I
>>>>> suspect in your case you could just set PAD_TO to 8192 in
>>>>> board/../config.mk and use the existing target.
>>>>>
>>>> In the S3C2416 I don't need the mkimage stuff. I only need the raw SPL
>>>> image
>>>> padded at 8KB concatenated with the standard U-Boot. What I've done was
>>>> to
>>>> split the existing u-boot-ubl target in two; u-boot-ubl.bin, that I use
>>>> to
>>>> program the Flash, and u-boot-ubl that remains with the same
>>>> functionality
>>>> as before, just now it depends on u-boot-ubl.bin.
>>> I think you should drop the UBL names from your padding target
>>> (u-boot-ubl.bin) since this is TI specific, use something more
>>> generic.
>>
>> I only reused a temporary filename used for the u-boot-ubl target and make
>> it a new target.
>> If you think this is not an adequate name, can you suggest a new one?
> u-boot.pad? u-boot-pad.bin?
>
If no one else has anything against, I will change the name of the new
target to u-boot-pad.bin
Best regards,
Jos? Gon?alves
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
2012-09-14 18:21 ` Marek Vasut
2012-09-14 18:45 ` José Miguel Gonçalves
2012-09-14 19:24 ` Scott Wood
@ 2012-09-17 11:11 ` José Miguel Gonçalves
2 siblings, 0 replies; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-17 11:11 UTC (permalink / raw)
To: u-boot
Hi Marek,
On 14-09-2012 19:21, Marek Vasut wrote:
> Dear Jos? Miguel Gon?alves,
>
>> NAND Flash driver with HW ECC for the S3C24XX SoCs.
>> Currently it only supports SLC NAND chips.
>>
>> Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
> [...]
>
>> +#include <common.h>
>> +#include <nand.h>
>> +#include <asm/io.h>
>> +#include <asm/arch/s3c24xx_cpu.h>
>> +#include <asm/errno.h>
>> +
>> +#define MAX_CHIPS 2
>> +static int nand_cs[MAX_CHIPS] = { 0, 1 };
>> +
>> +#ifdef CONFIG_SPL_BUILD
>> +#define printf(arg...) do {} while (0)
> This doesn't seem quite right ...
>
> 1) this should be in CPU directory
> 2) should be enabled only if CONFIG_SPL_SERIAL_SUPPORT is not set
> 3) should be inline function, not a macro
>
I'm having difficulties in following this suggestion. No problem if I migrate the
printf as a macro to a header in the CPU directory. The problem is when I try to
put it as an inline function. In this case if I define it like this;
#ifdef CONFIG_SPL_BUILD
static inline int printf(const char *fmt, ...)
{
return 0;
}
#endif
I will get an "static declaration of `printf' follows non-static declaration"
error due to the printf() declaration in common.h.
If I put this inline printf function (without the static) in a .c file in the CPU
directory, it will compile but, as I expected, it will not be inlined, but it will
be compiled as a normal function.
Can you detail on how to do this?
Best regards,
Jos? Gon?alves
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 11/11] S3C24XX: Add support to MINI2416 board
2012-09-16 9:11 ` José Miguel Gonçalves
@ 2012-09-17 14:39 ` Tom Rini
2012-09-17 14:47 ` José Miguel Gonçalves
0 siblings, 1 reply; 84+ messages in thread
From: Tom Rini @ 2012-09-17 14:39 UTC (permalink / raw)
To: u-boot
On Sun, Sep 16, 2012 at 10:11:07AM +0100, Jos? Miguel Gon?alves wrote:
> On 09/14/2012 07:58 PM, Tom Rini wrote:
> >On Fri, Sep 14, 2012 at 06:29:02PM +0100, Jos?? Miguel Gon??alves wrote:
> >
> >>The MINI2416 board is based on a Samsung's S3C2416 SoC and has 64MB DDR2 SDRAM,
> >>256MB NAND Flash, a LAN9220 Ethernet Controller and a WM8731 Audio CODEC.
> >>This U-Boot port was implemented and tested on a unit bought to Boardcon
> >>(http://www.armdesigner.com/) but there are some other chinese providers
> >>that can supply it with a selectable NAND chip from 128MB to 1GB.
> >[snip]
> >
> >Can you please try this on top of my SPL framework series? Thanks!
>
> I thought I was using the latest SPL framework!
> Can you please detail on what I should do different?
Please see
http://www.mail-archive.com/u-boot at lists.denx.de/msg92156.html
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120917/2da26656/attachment.pgp>
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
2012-09-17 9:24 ` José Miguel Gonçalves
@ 2012-09-17 14:45 ` Tom Rini
2012-09-17 16:29 ` Marek Vasut
2012-09-17 16:27 ` Scott Wood
1 sibling, 1 reply; 84+ messages in thread
From: Tom Rini @ 2012-09-17 14:45 UTC (permalink / raw)
To: u-boot
On Mon, Sep 17, 2012 at 10:24:34AM +0100, Jos?? Miguel Gon??alves wrote:
> On 09/17/2012 10:10 AM, Christian Riesch wrote:
> >On Mon, Sep 17, 2012 at 10:30 AM, Jos?? Miguel Gon??alves
> ><jose.goncalves@inov.pt> wrote:
> >>On 09/17/2012 07:47 AM, Christian Riesch wrote:
> >>>Hi,
> >>>
> >>>On Sun, Sep 16, 2012 at 11:27 AM, Jos?? Miguel Gon??alves
> >>><jose.goncalves@inov.pt> wrote:
> >>>>On 09/14/2012 08:08 PM, Tom Rini wrote:
> >>>>>On Fri, Sep 14, 2012 at 06:29:01PM +0100, Jos?? Miguel Gon??alves wrote:
> >>>>>
> >>>>>>Samsung's S3C24XX SoCs need this in order to generate a binary image
> >>>>>>with the SPL and U-Boot concatenated.
> >>>>>>
> >>>>>>Signed-off-by: Jos?? Miguel Gon??alves <jose.goncalves@inov.pt>
> >>>>>>---
> >>>>>>Changes for v2:
> >>>>>> - None
> >>>>>>---
> >>>>>> Makefile | 7 ++++---
> >>>>>> 1 file changed, 4 insertions(+), 3 deletions(-)
> >>>>>>
> >>>>>>diff --git a/Makefile b/Makefile
> >>>>>>index 058fb53..595b5f6 100644
> >>>>>>--- a/Makefile
> >>>>>>+++ b/Makefile
> >>>>>>@@ -442,13 +442,14 @@ $(obj)u-boot.sha1: $(obj)u-boot.bin
> >>>>>> $(obj)u-boot.dis: $(obj)u-boot
> >>>>>> $(OBJDUMP) -d $< > $@
> >>>>>> -$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
> >>>>>>+$(obj)u-boot-ubl.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
> >>>>>> $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary
> >>>>>>$(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin
> >>>>>> cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin >
> >>>>>>$(obj)u-boot-ubl.bin
> >>>>>>+ rm $(obj)spl/u-boot-spl-pad.bin
> >>>>>>+
> >>>>>>+$(obj)u-boot.ubl: $(obj)u-boot-ubl.bin
> >>>>>> $(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \
> >>>>>> -e $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin
> >>>>>>$(obj)u-boot.ubl
> >>>>>>- rm $(obj)u-boot-ubl.bin
> >>>>>>- rm $(obj)spl/u-boot-spl-pad.bin
> >>>>>> $(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
> >>>>>> $(obj)tools/mkimage -s -n $(if
> >>>>>>$(CONFIG_AIS_CONFIG_FILE),$(CONFIG_AIS_CONFIG_FILE),"/dev/null") \
> >>>>>This diff is hard to read, but what exactly are you changing? The
> >>>>>u-boot-ubl target is also used on TI platforms. It looks like you're
> >>>>>making it such that u-boot-ubl.bin produces the old binary and
> >>>>>u-boot-ubl adds a new target which is the mkimage header on top of the
> >>>>>same bits as before, but without possibly padding the output image. I
> >>>>>suspect in your case you could just set PAD_TO to 8192 in
> >>>>>board/../config.mk and use the existing target.
> >>>>>
> >>>>In the S3C2416 I don't need the mkimage stuff. I only need the raw SPL
> >>>>image
> >>>>padded at 8KB concatenated with the standard U-Boot. What I've done was
> >>>>to
> >>>>split the existing u-boot-ubl target in two; u-boot-ubl.bin, that I use
> >>>>to
> >>>>program the Flash, and u-boot-ubl that remains with the same
> >>>>functionality
> >>>>as before, just now it depends on u-boot-ubl.bin.
> >>>I think you should drop the UBL names from your padding target
> >>>(u-boot-ubl.bin) since this is TI specific, use something more
> >>>generic.
> >>
> >>I only reused a temporary filename used for the u-boot-ubl target and make
> >>it a new target.
> >>If you think this is not an adequate name, can you suggest a new one?
> >u-boot.pad? u-boot-pad.bin?
> >
>
> If no one else has anything against, I will change the name of the
> new target to u-boot-pad.bin
I think I'm OK with that.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120917/3ef6c3cc/attachment.pgp>
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 11/11] S3C24XX: Add support to MINI2416 board
2012-09-17 14:39 ` Tom Rini
@ 2012-09-17 14:47 ` José Miguel Gonçalves
2012-09-17 15:11 ` Tom Rini
0 siblings, 1 reply; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-17 14:47 UTC (permalink / raw)
To: u-boot
On 17-09-2012 15:39, Tom Rini wrote:
> On Sun, Sep 16, 2012 at 10:11:07AM +0100, Jos? Miguel Gon?alves wrote:
>> On 09/14/2012 07:58 PM, Tom Rini wrote:
>>> On Fri, Sep 14, 2012 at 06:29:02PM +0100, Jos?? Miguel Gon??alves wrote:
>>>
>>>> The MINI2416 board is based on a Samsung's S3C2416 SoC and has 64MB DDR2 SDRAM,
>>>> 256MB NAND Flash, a LAN9220 Ethernet Controller and a WM8731 Audio CODEC.
>>>> This U-Boot port was implemented and tested on a unit bought to Boardcon
>>>> (http://www.armdesigner.com/) but there are some other chinese providers
>>>> that can supply it with a selectable NAND chip from 128MB to 1GB.
>>> [snip]
>>>
>>> Can you please try this on top of my SPL framework series? Thanks!
>> I thought I was using the latest SPL framework!
>> Can you please detail on what I should do different?
> Please see
> http://www.mail-archive.com/u-boot at lists.denx.de/msg92156.html
>
As this is still not merged, I reckon you only want to check if this new SPL
framework works fine with my board.
I'm not expected to resubmit my patch to be according with the new framework, correct?
Best regards,
Jos? Gon?alves
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 11/11] S3C24XX: Add support to MINI2416 board
2012-09-17 14:47 ` José Miguel Gonçalves
@ 2012-09-17 15:11 ` Tom Rini
2012-09-18 12:11 ` José Miguel Gonçalves
0 siblings, 1 reply; 84+ messages in thread
From: Tom Rini @ 2012-09-17 15:11 UTC (permalink / raw)
To: u-boot
On Mon, Sep 17, 2012 at 03:47:46PM +0100, Jos? Miguel Gon?alves wrote:
> On 17-09-2012 15:39, Tom Rini wrote:
> >On Sun, Sep 16, 2012 at 10:11:07AM +0100, Jos? Miguel Gon?alves wrote:
> >>On 09/14/2012 07:58 PM, Tom Rini wrote:
> >>>On Fri, Sep 14, 2012 at 06:29:02PM +0100, Jos?? Miguel Gon??alves wrote:
> >>>
> >>>>The MINI2416 board is based on a Samsung's S3C2416 SoC and has 64MB DDR2 SDRAM,
> >>>>256MB NAND Flash, a LAN9220 Ethernet Controller and a WM8731 Audio CODEC.
> >>>>This U-Boot port was implemented and tested on a unit bought to Boardcon
> >>>>(http://www.armdesigner.com/) but there are some other chinese providers
> >>>>that can supply it with a selectable NAND chip from 128MB to 1GB.
> >>>[snip]
> >>>
> >>>Can you please try this on top of my SPL framework series? Thanks!
> >>I thought I was using the latest SPL framework!
> >>Can you please detail on what I should do different?
> >Please see
> >http://www.mail-archive.com/u-boot at lists.denx.de/msg92156.html
> >
>
> As this is still not merged, I reckon you only want to check if this
> new SPL framework works fine with my board.
>
> I'm not expected to resubmit my patch to be according with the new framework, correct?
v1 of your patches was posted well after the merge window for v2012.10
closed. My SPL series will be merged to mainline shortly (taking care
of everyone elses merge requests first). So yes, to get into v2013.01
you will need to update. If you check the archives you can see how the
altera soc support changed to adapt to this framework. And if there's a
shortcoming in the framework, I really do want to know. Thanks!
--
Tom
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
2012-09-17 9:24 ` José Miguel Gonçalves
2012-09-17 14:45 ` Tom Rini
@ 2012-09-17 16:27 ` Scott Wood
2012-09-17 16:51 ` Tom Rini
1 sibling, 1 reply; 84+ messages in thread
From: Scott Wood @ 2012-09-17 16:27 UTC (permalink / raw)
To: u-boot
On 09/17/2012 04:24:34 AM, Jos? Miguel Gon?alves wrote:
> On 09/17/2012 10:10 AM, Christian Riesch wrote:
>> On Mon, Sep 17, 2012 at 10:30 AM, Jos? Miguel Gon?alves
>> <jose.goncalves@inov.pt> wrote:
>>> On 09/17/2012 07:47 AM, Christian Riesch wrote:
>>>> Hi,
>>>>
>>>> On Sun, Sep 16, 2012 at 11:27 AM, Jos? Miguel Gon?alves
>>>> <jose.goncalves@inov.pt> wrote:
>>>>> On 09/14/2012 08:08 PM, Tom Rini wrote:
>>>>>> On Fri, Sep 14, 2012 at 06:29:01PM +0100, Jos?? Miguel
>>>>>> Gon??alves wrote:
>>>>>>
>>>>>>> Samsung's S3C24XX SoCs need this in order to generate a binary
>>>>>>> image
>>>>>>> with the SPL and U-Boot concatenated.
>>>>>>>
>>>>>>> Signed-off-by: Jos?? Miguel Gon??alves <jose.goncalves@inov.pt>
>>>>>>> ---
>>>>>>> Changes for v2:
>>>>>>> - None
>>>>>>> ---
>>>>>>> Makefile | 7 ++++---
>>>>>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>>>>>
>>>>>>> diff --git a/Makefile b/Makefile
>>>>>>> index 058fb53..595b5f6 100644
>>>>>>> --- a/Makefile
>>>>>>> +++ b/Makefile
>>>>>>> @@ -442,13 +442,14 @@ $(obj)u-boot.sha1: $(obj)u-boot.bin
>>>>>>> $(obj)u-boot.dis: $(obj)u-boot
>>>>>>> $(OBJDUMP) -d $< > $@
>>>>>>> -$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin
>>>>>>> $(obj)u-boot.bin
>>>>>>> +$(obj)u-boot-ubl.bin: $(obj)spl/u-boot-spl.bin
>>>>>>> $(obj)u-boot.bin
>>>>>>> $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O
>>>>>>> binary
>>>>>>> $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin
>>>>>>> cat $(obj)spl/u-boot-spl-pad.bin
>>>>>>> $(obj)u-boot.bin >
>>>>>>> $(obj)u-boot-ubl.bin
>>>>>>> + rm $(obj)spl/u-boot-spl-pad.bin
>>>>>>> +
>>>>>>> +$(obj)u-boot.ubl: $(obj)u-boot-ubl.bin
>>>>>>> $(obj)tools/mkimage -n $(UBL_CONFIG) -T
>>>>>>> ublimage \
>>>>>>> -e $(CONFIG_SYS_TEXT_BASE) -d
>>>>>>> $(obj)u-boot-ubl.bin
>>>>>>> $(obj)u-boot.ubl
>>>>>>> - rm $(obj)u-boot-ubl.bin
>>>>>>> - rm $(obj)spl/u-boot-spl-pad.bin
>>>>>>> $(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin
>>>>>>> $(obj)u-boot.bin
>>>>>>> $(obj)tools/mkimage -s -n $(if
>>>>>>> $(CONFIG_AIS_CONFIG_FILE),$(CONFIG_AIS_CONFIG_FILE),"/dev/null")
>>>>>>> \
>>>>>> This diff is hard to read, but what exactly are you changing?
>>>>>> The
>>>>>> u-boot-ubl target is also used on TI platforms. It looks like
>>>>>> you're
>>>>>> making it such that u-boot-ubl.bin produces the old binary and
>>>>>> u-boot-ubl adds a new target which is the mkimage header on top
>>>>>> of the
>>>>>> same bits as before, but without possibly padding the output
>>>>>> image. I
>>>>>> suspect in your case you could just set PAD_TO to 8192 in
>>>>>> board/../config.mk and use the existing target.
>>>>>>
>>>>> In the S3C2416 I don't need the mkimage stuff. I only need the
>>>>> raw SPL
>>>>> image
>>>>> padded at 8KB concatenated with the standard U-Boot. What I've
>>>>> done was
>>>>> to
>>>>> split the existing u-boot-ubl target in two; u-boot-ubl.bin, that
>>>>> I use
>>>>> to
>>>>> program the Flash, and u-boot-ubl that remains with the same
>>>>> functionality
>>>>> as before, just now it depends on u-boot-ubl.bin.
>>>> I think you should drop the UBL names from your padding target
>>>> (u-boot-ubl.bin) since this is TI specific, use something more
>>>> generic.
>>>
>>> I only reused a temporary filename used for the u-boot-ubl target
>>> and make
>>> it a new target.
>>> If you think this is not an adequate name, can you suggest a new
>>> one?
>> u-boot.pad? u-boot-pad.bin?
>>
>
> If no one else has anything against, I will change the name of the
> new target to u-boot-pad.bin
What exactly is u-boot-pad.bin supposed to be? I hope that's not being
proposed as the final output file the user sees.
With old nand_spl we had u-boot-nand.bin for the final concatenated
binary, but that's not appropriate for a generic spl. I think it would
be better for the user to see "u-boot.bin" as the actual image to put
on the boot device, regardless of implementation details like spl, if
there's no requirement of a specific file format. The second stage
could become "u-boot-main.bin" or similar on builds where spl is used.
-Scott
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
2012-09-17 14:45 ` Tom Rini
@ 2012-09-17 16:29 ` Marek Vasut
2012-09-17 16:35 ` Tom Rini
0 siblings, 1 reply; 84+ messages in thread
From: Marek Vasut @ 2012-09-17 16:29 UTC (permalink / raw)
To: u-boot
Dear Tom Rini,
[...]
> > If no one else has anything against, I will change the name of the
> > new target to u-boot-pad.bin
>
> I think I'm OK with that.
What about having CPU-overridable targets ? So omap can have it's own .ubl
result and commands leading to it ... and so can s3c24xx. Such targets would
have to be shifted into CPU-specific dirs, is that possible?
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
2012-09-17 16:29 ` Marek Vasut
@ 2012-09-17 16:35 ` Tom Rini
0 siblings, 0 replies; 84+ messages in thread
From: Tom Rini @ 2012-09-17 16:35 UTC (permalink / raw)
To: u-boot
On 09/17/12 09:29, Marek Vasut wrote:
> Dear Tom Rini,
>
> [...]
>
>>> If no one else has anything against, I will change the name of the
>>> new target to u-boot-pad.bin
>>
>> I think I'm OK with that.
>
> What about having CPU-overridable targets ? So omap can have it's own .ubl
> result and commands leading to it ... and so can s3c24xx. Such targets would
> have to be shifted into CPU-specific dirs, is that possible?
The problem I see first is that "UBL" doesn't seem to mean anything in
the context of s3c24xx, it just happens to be doing some of what the
system wants.
--
Tom
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
2012-09-17 16:27 ` Scott Wood
@ 2012-09-17 16:51 ` Tom Rini
2012-09-17 17:32 ` Scott Wood
0 siblings, 1 reply; 84+ messages in thread
From: Tom Rini @ 2012-09-17 16:51 UTC (permalink / raw)
To: u-boot
On 09/17/12 09:27, Scott Wood wrote:
> On 09/17/2012 04:24:34 AM, Jos? Miguel Gon?alves wrote:
[snip]
>> If no one else has anything against, I will change the name of the new
>> target to u-boot-pad.bin
>
> What exactly is u-boot-pad.bin supposed to be? I hope that's not being
> proposed as the final output file the user sees.
>
> With old nand_spl we had u-boot-nand.bin for the final concatenated
> binary, but that's not appropriate for a generic spl. I think it would
> be better for the user to see "u-boot.bin" as the actual image to put on
> the boot device, regardless of implementation details like spl, if
> there's no requirement of a specific file format. The second stage
> could become "u-boot-main.bin" or similar on builds where spl is used.
We need some name that means "U-Boot SPL with U-Boot tacked on at the
end". This can optionally be padded to a defined size to make writing
to hardware easier. We also have the problem that "u-boot.bin" already
means something so it needs to be clear. I further fear that even if we
made an "out" directory if we put u-boot.bin in there and it's not the
same as the objcopy -O binary u-boot u-boot.bin as before we've violated
the rule of least surprise and the end user problems from people that
read "the" document (that happened to be out of date) will be our problem.
In short, at least a few people have said something along the lines of
"We need generic output nameo $mediums and targets" but there's two hard
problems, one of which is that every SoC _needs_ things tweaked just so
(no header? no boot!), sometimes wants things tweaked further (pad the
final image out to be easier to write to $medium) and sometimes needs
multiple files (the whole of 'SPL' will be read so it must fit into
$SMALL_MEMORY). The other is naming.
I don't want to block this series on this problem. I do want to say it
needs to use my updated SPL framework or show that it's inadequate (and
I owe another reply to part of this thread still) for this platform.
Call it u-boot.s3c or .s3c24xx and lets continue talking about how to
solve the general problem.
--
Tom
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
2012-09-16 9:16 ` José Miguel Gonçalves
@ 2012-09-17 16:57 ` Tom Rini
2012-09-17 17:03 ` Scott Wood
2012-09-17 17:08 ` José Miguel Gonçalves
0 siblings, 2 replies; 84+ messages in thread
From: Tom Rini @ 2012-09-17 16:57 UTC (permalink / raw)
To: u-boot
On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves wrote:
> On 09/14/2012 08:01 PM, Tom Rini wrote:
> >On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel Gon?alves wrote:
> >>On 14-09-2012 19:21, Marek Vasut wrote:
> >>>Dear Jos? Miguel Gon?alves,
> >>>
> >>>>NAND Flash driver with HW ECC for the S3C24XX SoCs.
> >>>>Currently it only supports SLC NAND chips.
> >>>>
> >>>>Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
> >>>[...]
> >>>
> >>>>+#include <common.h>
> >>>>+#include <nand.h>
> >>>>+#include <asm/io.h>
> >>>>+#include <asm/arch/s3c24xx_cpu.h>
> >>>>+#include <asm/errno.h>
> >>>>+
> >>>>+#define MAX_CHIPS 2
> >>>>+static int nand_cs[MAX_CHIPS] = { 0, 1 };
> >>>>+
> >>>>+#ifdef CONFIG_SPL_BUILD
> >>>>+#define printf(arg...) do {} while (0)
> >>>This doesn't seem quite right ...
> >>>
> >>>1) this should be in CPU directory
> >>>2) should be enabled only if CONFIG_SPL_SERIAL_SUPPORT is not set
> >>>3) should be inline function, not a macro
> >>1) and 3) OK.
> >>Don't quite understand 2). I want to remove the printfs in the SPL
> >>build, as it would blown up the internal SoC RAM space available.
> >>So why add a condition with CONFIG_SPL_SERIAL_SUPPORT?
> >You've got 8KB, based on the final patch in the series. At least in my
> >SPL series that's still enough to get you printf/puts (I believe 4kb was
> >the cutoff where that had to be dropped).
> >
>
> Barely:
>
> $ size u-boot-spl
> text data bss dec hex filename
> 3337 8 588 3933 f5d u-boot-spl
>
> $ size u-boot-spl-printf
> text data bss dec hex filename
> 7968 8 604 8580 2184 u-boot-spl-printf
>
> The printf is not so important that justifies exhausting the IRAM
> space available and preventing any future SPL expansion...
There's two parts to this:
- What else can you do in a single binary, in theory? Is there boot
medium detection and you would want to have, for example, NAND and SD
support in the same binary? I would say memory is meant for using,
but this is a board maintainer decision and that's you :)
- We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT) that toggles
printf or no printf. If we really need to say yes to
LIBCOMMON_SUPPORT and no to printf, we need finer grained config
options and then a do-nothing printf is used for SPL. Doing the
opt-out driver by driver just punts this problem down the road to the
next developer and that's not very nice (and adding
CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few
Makefiles, update a bunch of config files, add
common/spl/dummy_funcs.c and a __weak printf).
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120917/1a9e0e7a/attachment.pgp>
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
2012-09-17 16:57 ` Tom Rini
@ 2012-09-17 17:03 ` Scott Wood
2012-09-17 17:08 ` Tom Rini
2012-09-17 17:08 ` José Miguel Gonçalves
1 sibling, 1 reply; 84+ messages in thread
From: Scott Wood @ 2012-09-17 17:03 UTC (permalink / raw)
To: u-boot
On 09/17/2012 11:57:57 AM, Tom Rini wrote:
> On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves wrote:
> > On 09/14/2012 08:01 PM, Tom Rini wrote:
> > >On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel Gon?alves
> wrote:
> > >>On 14-09-2012 19:21, Marek Vasut wrote:
> > >>>Dear Jos? Miguel Gon?alves,
> > >>>
> > >>>>NAND Flash driver with HW ECC for the S3C24XX SoCs.
> > >>>>Currently it only supports SLC NAND chips.
> > >>>>
> > >>>>Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
> > >>>[...]
> > >>>
> > >>>>+#include <common.h>
> > >>>>+#include <nand.h>
> > >>>>+#include <asm/io.h>
> > >>>>+#include <asm/arch/s3c24xx_cpu.h>
> > >>>>+#include <asm/errno.h>
> > >>>>+
> > >>>>+#define MAX_CHIPS 2
> > >>>>+static int nand_cs[MAX_CHIPS] = { 0, 1 };
> > >>>>+
> > >>>>+#ifdef CONFIG_SPL_BUILD
> > >>>>+#define printf(arg...) do {} while (0)
> > >>>This doesn't seem quite right ...
> > >>>
> > >>>1) this should be in CPU directory
> > >>>2) should be enabled only if CONFIG_SPL_SERIAL_SUPPORT is not set
> > >>>3) should be inline function, not a macro
> > >>1) and 3) OK.
> > >>Don't quite understand 2). I want to remove the printfs in the SPL
> > >>build, as it would blown up the internal SoC RAM space available.
> > >>So why add a condition with CONFIG_SPL_SERIAL_SUPPORT?
> > >You've got 8KB, based on the final patch in the series. At least
> in my
> > >SPL series that's still enough to get you printf/puts (I believe
> 4kb was
> > >the cutoff where that had to be dropped).
> > >
> >
> > Barely:
> >
> > $ size u-boot-spl
> > text data bss dec hex filename
> > 3337 8 588 3933 f5d u-boot-spl
> >
> > $ size u-boot-spl-printf
> > text data bss dec hex filename
> > 7968 8 604 8580 2184
> u-boot-spl-printf
> >
> > The printf is not so important that justifies exhausting the IRAM
> > space available and preventing any future SPL expansion...
>
> There's two parts to this:
> - What else can you do in a single binary, in theory? Is there boot
> medium detection and you would want to have, for example, NAND and
> SD
> support in the same binary? I would say memory is meant for using,
> but this is a board maintainer decision and that's you :)
> - We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT) that toggles
> printf or no printf. If we really need to say yes to
> LIBCOMMON_SUPPORT and no to printf, we need finer grained config
> options and then a do-nothing printf is used for SPL. Doing the
> opt-out driver by driver just punts this problem down the road to
> the
> next developer and that's not very nice (and adding
> CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few
> Makefiles, update a bunch of config files, add
> common/spl/dummy_funcs.c and a __weak printf).
Weak symbols are not OK for configuring printf out of the SPL, as
you'll still have all the format strings and caller code in the
binary. It should be a macro (or an inline function that replaces the
standard printf declaration), but it should be in a system header (not
the CPU directory -- not sure what Marek meant there) and be based on
an appropriate CONFIG symbol.
-Scott
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
2012-09-17 16:57 ` Tom Rini
2012-09-17 17:03 ` Scott Wood
@ 2012-09-17 17:08 ` José Miguel Gonçalves
2012-09-17 17:56 ` Tom Rini
1 sibling, 1 reply; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-17 17:08 UTC (permalink / raw)
To: u-boot
On 17-09-2012 17:57, Tom Rini wrote:
> On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves wrote:
>> On 09/14/2012 08:01 PM, Tom Rini wrote:
>>> On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel Gon?alves wrote:
>>>> On 14-09-2012 19:21, Marek Vasut wrote:
>>>>> Dear Jos? Miguel Gon?alves,
>>>>>
>>>>>> NAND Flash driver with HW ECC for the S3C24XX SoCs.
>>>>>> Currently it only supports SLC NAND chips.
>>>>>>
>>>>>> Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
>>>>> [...]
>>>>>
>>>>>> +#include <common.h>
>>>>>> +#include <nand.h>
>>>>>> +#include <asm/io.h>
>>>>>> +#include <asm/arch/s3c24xx_cpu.h>
>>>>>> +#include <asm/errno.h>
>>>>>> +
>>>>>> +#define MAX_CHIPS 2
>>>>>> +static int nand_cs[MAX_CHIPS] = { 0, 1 };
>>>>>> +
>>>>>> +#ifdef CONFIG_SPL_BUILD
>>>>>> +#define printf(arg...) do {} while (0)
>>>>> This doesn't seem quite right ...
>>>>>
>>>>> 1) this should be in CPU directory
>>>>> 2) should be enabled only if CONFIG_SPL_SERIAL_SUPPORT is not set
>>>>> 3) should be inline function, not a macro
>>>> 1) and 3) OK.
>>>> Don't quite understand 2). I want to remove the printfs in the SPL
>>>> build, as it would blown up the internal SoC RAM space available.
>>>> So why add a condition with CONFIG_SPL_SERIAL_SUPPORT?
>>> You've got 8KB, based on the final patch in the series. At least in my
>>> SPL series that's still enough to get you printf/puts (I believe 4kb was
>>> the cutoff where that had to be dropped).
>>>
>> Barely:
>>
>> $ size u-boot-spl
>> text data bss dec hex filename
>> 3337 8 588 3933 f5d u-boot-spl
>>
>> $ size u-boot-spl-printf
>> text data bss dec hex filename
>> 7968 8 604 8580 2184 u-boot-spl-printf
>>
>> The printf is not so important that justifies exhausting the IRAM
>> space available and preventing any future SPL expansion...
> There's two parts to this:
> - What else can you do in a single binary, in theory? Is there boot
> medium detection and you would want to have, for example, NAND and SD
> support in the same binary? I would say memory is meant for using,
> but this is a board maintainer decision and that's you :)
That's exactly what I've got in mind when I talked about a future expansion! Being
able to boot also from an SD card.
With only 8KB for .text and .data, I can not use printfs in the SPL for this
platform (at least with the present printf support for SPL).
> - We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT) that toggles
> printf or no printf. If we really need to say yes to
> LIBCOMMON_SUPPORT and no to printf, we need finer grained config
> options and then a do-nothing printf is used for SPL. Doing the
> opt-out driver by driver just punts this problem down the road to the
> next developer and that's not very nice (and adding
> CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few
> Makefiles, update a bunch of config files, add
> common/spl/dummy_funcs.c and a __weak printf).
>
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
2012-09-17 17:03 ` Scott Wood
@ 2012-09-17 17:08 ` Tom Rini
2012-09-17 17:13 ` Scott Wood
0 siblings, 1 reply; 84+ messages in thread
From: Tom Rini @ 2012-09-17 17:08 UTC (permalink / raw)
To: u-boot
On 09/17/12 10:03, Scott Wood wrote:
> On 09/17/2012 11:57:57 AM, Tom Rini wrote:
>> On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves wrote:
>> > On 09/14/2012 08:01 PM, Tom Rini wrote:
>> > >On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel Gon?alves wrote:
>> > >>On 14-09-2012 19:21, Marek Vasut wrote:
>> > >>>Dear Jos? Miguel Gon?alves,
>> > >>>
>> > >>>>NAND Flash driver with HW ECC for the S3C24XX SoCs.
>> > >>>>Currently it only supports SLC NAND chips.
>> > >>>>
>> > >>>>Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
>> > >>>[...]
>> > >>>
>> > >>>>+#include <common.h>
>> > >>>>+#include <nand.h>
>> > >>>>+#include <asm/io.h>
>> > >>>>+#include <asm/arch/s3c24xx_cpu.h>
>> > >>>>+#include <asm/errno.h>
>> > >>>>+
>> > >>>>+#define MAX_CHIPS 2
>> > >>>>+static int nand_cs[MAX_CHIPS] = { 0, 1 };
>> > >>>>+
>> > >>>>+#ifdef CONFIG_SPL_BUILD
>> > >>>>+#define printf(arg...) do {} while (0)
>> > >>>This doesn't seem quite right ...
>> > >>>
>> > >>>1) this should be in CPU directory
>> > >>>2) should be enabled only if CONFIG_SPL_SERIAL_SUPPORT is not set
>> > >>>3) should be inline function, not a macro
>> > >>1) and 3) OK.
>> > >>Don't quite understand 2). I want to remove the printfs in the SPL
>> > >>build, as it would blown up the internal SoC RAM space available.
>> > >>So why add a condition with CONFIG_SPL_SERIAL_SUPPORT?
>> > >You've got 8KB, based on the final patch in the series. At least
>> in my
>> > >SPL series that's still enough to get you printf/puts (I believe
>> 4kb was
>> > >the cutoff where that had to be dropped).
>> > >
>> >
>> > Barely:
>> >
>> > $ size u-boot-spl
>> > text data bss dec hex filename
>> > 3337 8 588 3933 f5d u-boot-spl
>> >
>> > $ size u-boot-spl-printf
>> > text data bss dec hex filename
>> > 7968 8 604 8580 2184 u-boot-spl-printf
>> >
>> > The printf is not so important that justifies exhausting the IRAM
>> > space available and preventing any future SPL expansion...
>>
>> There's two parts to this:
>> - What else can you do in a single binary, in theory? Is there boot
>> medium detection and you would want to have, for example, NAND and SD
>> support in the same binary? I would say memory is meant for using,
>> but this is a board maintainer decision and that's you :)
>> - We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT) that toggles
>> printf or no printf. If we really need to say yes to
>> LIBCOMMON_SUPPORT and no to printf, we need finer grained config
>> options and then a do-nothing printf is used for SPL. Doing the
>> opt-out driver by driver just punts this problem down the road to the
>> next developer and that's not very nice (and adding
>> CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few
>> Makefiles, update a bunch of config files, add
>> common/spl/dummy_funcs.c and a __weak printf).
>
> Weak symbols are not OK for configuring printf out of the SPL, as you'll
> still have all the format strings and caller code in the binary. It
> should be a macro (or an inline function that replaces the standard
> printf declaration), but it should be in a system header (not the CPU
> directory -- not sure what Marek meant there) and be based on an
> appropriate CONFIG symbol.
I'm a little leery of adding #if ... into <common.h> around printf. I'd
like to not worry about the branch/return bytes until we really really
have to again but yes, the strings are more of a concern since they
won't be collected out. Just top of my head thinking above.
--
Tom
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
2012-09-17 17:08 ` Tom Rini
@ 2012-09-17 17:13 ` Scott Wood
0 siblings, 0 replies; 84+ messages in thread
From: Scott Wood @ 2012-09-17 17:13 UTC (permalink / raw)
To: u-boot
On 09/17/2012 12:08:17 PM, Tom Rini wrote:
> On 09/17/12 10:03, Scott Wood wrote:
> > Weak symbols are not OK for configuring printf out of the SPL, as
> you'll
> > still have all the format strings and caller code in the binary. It
> > should be a macro (or an inline function that replaces the standard
> > printf declaration), but it should be in a system header (not the
> CPU
> > directory -- not sure what Marek meant there) and be based on an
> > appropriate CONFIG symbol.
>
> I'm a little leery of adding #if ... into <common.h> around printf.
> I'd
> like to not worry about the branch/return bytes until we really really
> have to again but yes, the strings are more of a concern since they
> won't be collected out. Just top of my head thinking above.
Caller code won't be collected either. It's not just branch/return
bytes but argument preparation -- possibly significant chunks of code
to calculate values to be displayed, that might otherwise be optimized
out.
-Scott
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
2012-09-16 15:36 ` Marek Vasut
2012-09-16 16:26 ` José Miguel Gonçalves
2012-09-17 6:28 ` Christian Riesch
@ 2012-09-17 17:18 ` Tom Rini
2012-09-17 17:23 ` Scott Wood
` (2 more replies)
2 siblings, 3 replies; 84+ messages in thread
From: Tom Rini @ 2012-09-17 17:18 UTC (permalink / raw)
To: u-boot
On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote:
> Dear Jos? Miguel Gon?alves,
>
> > On 09/16/2012 11:06 AM, Marek Vasut wrote:
> > > Dear Jos? Miguel Gon?alves,
> > >
> > >> On 09/15/2012 07:03 PM, Marek Vasut wrote:
> > >>> Dear Jos? Miguel Gon?alves,
> > >>>
> > >>>> Jumping to board_init_r is not performed due to a bug on address
> > >>>> computation.
> > >>>
> > >>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any
> > >>> misbehavior on my arm926 boards.
> > >>
> > >> Maybe because you are not using it to build an SPL?
> > >
> > > I do ... and I use CONFIG_SPL_TEXT_BASE properly .
> >
> > >> Please check the same chunk of code in other start.S for arm1176 and
> > >> armv7. They have the same code that I put for arm926ejs.
> > >
> > > Please wait and please first explain what is the issue.
> >
> > The issue is what I've explained in the patch comments.
>
> "Jumping to board_init_r is not performed due to a bug on address computation."
>
> Ok, I don't know how to replicate the bug from this comment or what effects it
> causes or ... well, anything. So please, try to be more elaborate in your patch
> description next time. Anyway ..
>
> > Without this
> > change the code never reaches board_init_r in the SPL and I think I have
> > all the configurations correctly set.
>
> I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only
> to load the real U-Boot from whatever media, so you usually use either NAND SPL
Here's a good point for me to jump in, I think. There's two things to
understand:
- In the current in-tree SPL implementations the code flow is
board_init_f calls relocate_code() to clear the BSS _and_ get our jump
to board_init_r. It does not actually relocate the running U-Boot,
just clears the BSS. board_init_r is what calls the things to load
and boot the next stage (U-Boot or Linux).
- In my series this has been changed slightly to be board_init_f calls
memset and then board_init_r directly. So this patch should not be
needed once rebased on that series.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120917/db3c424d/attachment.pgp>
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
2012-09-17 17:18 ` Tom Rini
@ 2012-09-17 17:23 ` Scott Wood
2012-09-17 17:32 ` Tom Rini
2012-09-17 17:26 ` Marek Vasut
2012-09-17 17:27 ` José Miguel Gonçalves
2 siblings, 1 reply; 84+ messages in thread
From: Scott Wood @ 2012-09-17 17:23 UTC (permalink / raw)
To: u-boot
On 09/17/2012 12:18:31 PM, Tom Rini wrote:
> On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote:
> > Dear Jos? Miguel Gon?alves,
> >
> > > On 09/16/2012 11:06 AM, Marek Vasut wrote:
> > > > Dear Jos? Miguel Gon?alves,
> > > >
> > > >> On 09/15/2012 07:03 PM, Marek Vasut wrote:
> > > >>> Dear Jos? Miguel Gon?alves,
> > > >>>
> > > >>>> Jumping to board_init_r is not performed due to a bug on
> address
> > > >>>> computation.
> > > >>>
> > > >>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't
> detect any
> > > >>> misbehavior on my arm926 boards.
> > > >>
> > > >> Maybe because you are not using it to build an SPL?
> > > >
> > > > I do ... and I use CONFIG_SPL_TEXT_BASE properly .
> > >
> > > >> Please check the same chunk of code in other start.S for
> arm1176 and
> > > >> armv7. They have the same code that I put for arm926ejs.
> > > >
> > > > Please wait and please first explain what is the issue.
> > >
> > > The issue is what I've explained in the patch comments.
> >
> > "Jumping to board_init_r is not performed due to a bug on address
> computation."
> >
> > Ok, I don't know how to replicate the bug from this comment or what
> effects it
> > causes or ... well, anything. So please, try to be more elaborate
> in your patch
> > description next time. Anyway ..
> >
> > > Without this
> > > change the code never reaches board_init_r in the SPL and I think
> I have
> > > all the configurations correctly set.
> >
> > I wonder why you'd ever want to reach board_init_r in the SPL. SPL
> is there only
> > to load the real U-Boot from whatever media, so you usually use
> either NAND SPL
>
> Here's a good point for me to jump in, I think. There's two things to
> understand:
> - In the current in-tree SPL implementations the code flow is
> board_init_f calls relocate_code() to clear the BSS _and_ get our
> jump
> to board_init_r. It does not actually relocate the running U-Boot,
> just clears the BSS. board_init_r is what calls the things to load
> and boot the next stage (U-Boot or Linux).
>
> - In my series this has been changed slightly to be board_init_f calls
> memset and then board_init_r directly. So this patch should not be
> needed once rebased on that series.
So you've removed the ability to relocate at all? What about hardware
where you boot from an I/O buffer, that you need to get out of in order
to load more pages?
-Scott
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
2012-09-17 17:18 ` Tom Rini
2012-09-17 17:23 ` Scott Wood
@ 2012-09-17 17:26 ` Marek Vasut
2012-09-17 17:35 ` Tom Rini
2012-09-17 17:27 ` José Miguel Gonçalves
2 siblings, 1 reply; 84+ messages in thread
From: Marek Vasut @ 2012-09-17 17:26 UTC (permalink / raw)
To: u-boot
Dear Tom Rini,
> On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote:
> > Dear Jos? Miguel Gon?alves,
> >
> > > On 09/16/2012 11:06 AM, Marek Vasut wrote:
> > > > Dear Jos? Miguel Gon?alves,
> > > >
> > > >> On 09/15/2012 07:03 PM, Marek Vasut wrote:
> > > >>> Dear Jos? Miguel Gon?alves,
> > > >>>
> > > >>>> Jumping to board_init_r is not performed due to a bug on address
> > > >>>> computation.
> > > >>>
> > > >>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect
> > > >>> any misbehavior on my arm926 boards.
> > > >>
> > > >> Maybe because you are not using it to build an SPL?
> > > >
> > > > I do ... and I use CONFIG_SPL_TEXT_BASE properly .
> > > >
> > > >> Please check the same chunk of code in other start.S for arm1176 and
> > > >> armv7. They have the same code that I put for arm926ejs.
> > > >
> > > > Please wait and please first explain what is the issue.
> > >
> > > The issue is what I've explained in the patch comments.
> >
> > "Jumping to board_init_r is not performed due to a bug on address
> > computation."
> >
> > Ok, I don't know how to replicate the bug from this comment or what
> > effects it causes or ... well, anything. So please, try to be more
> > elaborate in your patch description next time. Anyway ..
> >
> > > Without this
> > > change the code never reaches board_init_r in the SPL and I think I
> > > have all the configurations correctly set.
> >
> > I wonder why you'd ever want to reach board_init_r in the SPL. SPL is
> > there only to load the real U-Boot from whatever media, so you usually
> > use either NAND SPL
>
> Here's a good point for me to jump in, I think. There's two things to
> understand:
> - In the current in-tree SPL implementations the code flow is
> board_init_f calls relocate_code() to clear the BSS _and_ get our jump
> to board_init_r. It does not actually relocate the running U-Boot,
> just clears the BSS. board_init_r is what calls the things to load
> and boot the next stage (U-Boot or Linux).
>
> - In my series this has been changed slightly to be board_init_f calls
> memset and then board_init_r directly. So this patch should not be
> needed once rebased on that series.
Do we need to do all the relocation in assembler code btw? Can it not be moved
into C code and made generic across all platforms (module the stack adjustment
and a few minor things) ?
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
2012-09-17 17:18 ` Tom Rini
2012-09-17 17:23 ` Scott Wood
2012-09-17 17:26 ` Marek Vasut
@ 2012-09-17 17:27 ` José Miguel Gonçalves
2 siblings, 0 replies; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-17 17:27 UTC (permalink / raw)
To: u-boot
On 17-09-2012 18:18, Tom Rini wrote:
> On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote:
>> Dear Jos? Miguel Gon?alves,
>>
>>> On 09/16/2012 11:06 AM, Marek Vasut wrote:
>>>> Dear Jos? Miguel Gon?alves,
>>>>
>>>>> On 09/15/2012 07:03 PM, Marek Vasut wrote:
>>>>>> Dear Jos? Miguel Gon?alves,
>>>>>>
>>>>>>> Jumping to board_init_r is not performed due to a bug on address
>>>>>>> computation.
>>>>>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any
>>>>>> misbehavior on my arm926 boards.
>>>>> Maybe because you are not using it to build an SPL?
>>>> I do ... and I use CONFIG_SPL_TEXT_BASE properly .
>>>>> Please check the same chunk of code in other start.S for arm1176 and
>>>>> armv7. They have the same code that I put for arm926ejs.
>>>> Please wait and please first explain what is the issue.
>>> The issue is what I've explained in the patch comments.
>> "Jumping to board_init_r is not performed due to a bug on address computation."
>>
>> Ok, I don't know how to replicate the bug from this comment or what effects it
>> causes or ... well, anything. So please, try to be more elaborate in your patch
>> description next time. Anyway ..
>>
>>> Without this
>>> change the code never reaches board_init_r in the SPL and I think I have
>>> all the configurations correctly set.
>> I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only
>> to load the real U-Boot from whatever media, so you usually use either NAND SPL
> Here's a good point for me to jump in, I think. There's two things to
> understand:
> - In the current in-tree SPL implementations the code flow is
> board_init_f calls relocate_code() to clear the BSS _and_ get our jump
> to board_init_r. It does not actually relocate the running U-Boot,
> just clears the BSS. board_init_r is what calls the things to load
> and boot the next stage (U-Boot or Linux).
>
> - In my series this has been changed slightly to be board_init_f calls
> memset and then board_init_r directly. So this patch should not be
> needed once rebased on that series.
OK Tom. I will start working on rebasing the MINI2416 board support on the new SPL
framework.
If I have any doubts I will get in touch with you...
Best regards,
Jos? Gon?alves
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
2012-09-17 17:23 ` Scott Wood
@ 2012-09-17 17:32 ` Tom Rini
0 siblings, 0 replies; 84+ messages in thread
From: Tom Rini @ 2012-09-17 17:32 UTC (permalink / raw)
To: u-boot
On Mon, Sep 17, 2012 at 12:23:53PM -0500, Scott Wood wrote:
> On 09/17/2012 12:18:31 PM, Tom Rini wrote:
> >On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote:
> >> Dear Jos? Miguel Gon?alves,
> >>
> >> > On 09/16/2012 11:06 AM, Marek Vasut wrote:
> >> > > Dear Jos? Miguel Gon?alves,
> >> > >
> >> > >> On 09/15/2012 07:03 PM, Marek Vasut wrote:
> >> > >>> Dear Jos? Miguel Gon?alves,
> >> > >>>
> >> > >>>> Jumping to board_init_r is not performed due to a bug on
> >address
> >> > >>>> computation.
> >> > >>>
> >> > >>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't
> >detect any
> >> > >>> misbehavior on my arm926 boards.
> >> > >>
> >> > >> Maybe because you are not using it to build an SPL?
> >> > >
> >> > > I do ... and I use CONFIG_SPL_TEXT_BASE properly .
> >> >
> >> > >> Please check the same chunk of code in other start.S for
> >arm1176 and
> >> > >> armv7. They have the same code that I put for arm926ejs.
> >> > >
> >> > > Please wait and please first explain what is the issue.
> >> >
> >> > The issue is what I've explained in the patch comments.
> >>
> >> "Jumping to board_init_r is not performed due to a bug on
> >address computation."
> >>
> >> Ok, I don't know how to replicate the bug from this comment or
> >what effects it
> >> causes or ... well, anything. So please, try to be more
> >elaborate in your patch
> >> description next time. Anyway ..
> >>
> >> > Without this
> >> > change the code never reaches board_init_r in the SPL and I
> >think I have
> >> > all the configurations correctly set.
> >>
> >> I wonder why you'd ever want to reach board_init_r in the SPL.
> >SPL is there only
> >> to load the real U-Boot from whatever media, so you usually use
> >either NAND SPL
> >
> >Here's a good point for me to jump in, I think. There's two things to
> >understand:
> >- In the current in-tree SPL implementations the code flow is
> > board_init_f calls relocate_code() to clear the BSS _and_ get
> >our jump
> > to board_init_r. It does not actually relocate the running U-Boot,
> > just clears the BSS. board_init_r is what calls the things to load
> > and boot the next stage (U-Boot or Linux).
> >
> >- In my series this has been changed slightly to be board_init_f calls
> > memset and then board_init_r directly. So this patch should not be
> > needed once rebased on that series.
>
> So you've removed the ability to relocate at all? What about
> hardware where you boot from an I/O buffer, that you need to get out
> of in order to load more pages?
Then you do that instead. Getting from board_init_f to _r is setup at
the arch level, weakly, and with what it must perform documented.
--
Tom
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
2012-09-17 16:51 ` Tom Rini
@ 2012-09-17 17:32 ` Scott Wood
2012-09-17 17:53 ` Tom Rini
0 siblings, 1 reply; 84+ messages in thread
From: Scott Wood @ 2012-09-17 17:32 UTC (permalink / raw)
To: u-boot
On 09/17/2012 11:51:52 AM, Tom Rini wrote:
> On 09/17/12 09:27, Scott Wood wrote:
> > On 09/17/2012 04:24:34 AM, Jos? Miguel Gon?alves wrote:
> [snip]
> >> If no one else has anything against, I will change the name of the
> new
> >> target to u-boot-pad.bin
> >
> > What exactly is u-boot-pad.bin supposed to be? I hope that's not
> being
> > proposed as the final output file the user sees.
> >
> > With old nand_spl we had u-boot-nand.bin for the final concatenated
> > binary, but that's not appropriate for a generic spl. I think it
> would
> > be better for the user to see "u-boot.bin" as the actual image to
> put on
> > the boot device, regardless of implementation details like spl, if
> > there's no requirement of a specific file format. The second stage
> > could become "u-boot-main.bin" or similar on builds where spl is
> used.
>
> We need some name that means "U-Boot SPL with U-Boot tacked on at the
> end". This can optionally be padded to a defined size to make writing
> to hardware easier. We also have the problem that "u-boot.bin"
> already
> means something so it needs to be clear.
u-boot.bin has traditionally (except for nand_spl and derivatives)
meant the final image ready to put into flash, after any
platform-specific layout issues are taken care of (e.g. on mpc83xx it
will have a reset control word embedded, on mpc85xx it will be padded
to 512K with a reset vector at the end, etc.). That we did the
tweaking in the linker script rather than after linking seems like an
inconsequential implementation detail.
> I further fear that even if we
> made an "out" directory if we put u-boot.bin in there and it's not the
> same as the objcopy -O binary u-boot u-boot.bin as before we've
> violated
> the rule of least surprise and the end user problems from people that
> read "the" document (that happened to be out of date) will be our
> problem.
In this case I think you can't meet one user's expectations without
violating another's. I think it's more important to make it clear to
the user what file they're supposed to put into flash. Users of
platforms that are currently supported by nand_spl would probably like
to continue seeing u-boot-nand.bin -- it's a tradeoff of historical
stability versus current consistency.
> In short, at least a few people have said something along the lines of
> "We need generic output nameo $mediums and targets" but there's two
> hard
> problems, one of which is that every SoC _needs_ things tweaked just
> so
> (no header? no boot!), sometimes wants things tweaked further (pad the
> final image out to be easier to write to $medium) and sometimes needs
> multiple files (the whole of 'SPL' will be read so it must fit into
> $SMALL_MEMORY). The other is naming.
A simple concatenation of a padded SPL plus the main U-Boot was good
enough for all the nand_spl boards AFAIK, so it's not quite every SoC
that needs something special here. For those that do require a special
format (or multiple files) with a file extension that is familiar to
people working with that platform, using that extension makes sense.
"pad" does not, and a proliferation of SoC-specific suffixes isn't much
better.
-Scott
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
2012-09-17 17:26 ` Marek Vasut
@ 2012-09-17 17:35 ` Tom Rini
2012-09-17 17:48 ` Marek Vasut
0 siblings, 1 reply; 84+ messages in thread
From: Tom Rini @ 2012-09-17 17:35 UTC (permalink / raw)
To: u-boot
On Mon, Sep 17, 2012 at 07:26:06PM +0200, Marek Vasut wrote:
> Dear Tom Rini,
>
> > On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote:
> > > Dear Jos? Miguel Gon?alves,
> > >
> > > > On 09/16/2012 11:06 AM, Marek Vasut wrote:
> > > > > Dear Jos? Miguel Gon?alves,
> > > > >
> > > > >> On 09/15/2012 07:03 PM, Marek Vasut wrote:
> > > > >>> Dear Jos? Miguel Gon?alves,
> > > > >>>
> > > > >>>> Jumping to board_init_r is not performed due to a bug on address
> > > > >>>> computation.
> > > > >>>
> > > > >>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect
> > > > >>> any misbehavior on my arm926 boards.
> > > > >>
> > > > >> Maybe because you are not using it to build an SPL?
> > > > >
> > > > > I do ... and I use CONFIG_SPL_TEXT_BASE properly .
> > > > >
> > > > >> Please check the same chunk of code in other start.S for arm1176 and
> > > > >> armv7. They have the same code that I put for arm926ejs.
> > > > >
> > > > > Please wait and please first explain what is the issue.
> > > >
> > > > The issue is what I've explained in the patch comments.
> > >
> > > "Jumping to board_init_r is not performed due to a bug on address
> > > computation."
> > >
> > > Ok, I don't know how to replicate the bug from this comment or what
> > > effects it causes or ... well, anything. So please, try to be more
> > > elaborate in your patch description next time. Anyway ..
> > >
> > > > Without this
> > > > change the code never reaches board_init_r in the SPL and I think I
> > > > have all the configurations correctly set.
> > >
> > > I wonder why you'd ever want to reach board_init_r in the SPL. SPL is
> > > there only to load the real U-Boot from whatever media, so you usually
> > > use either NAND SPL
> >
> > Here's a good point for me to jump in, I think. There's two things to
> > understand:
> > - In the current in-tree SPL implementations the code flow is
> > board_init_f calls relocate_code() to clear the BSS _and_ get our jump
> > to board_init_r. It does not actually relocate the running U-Boot,
> > just clears the BSS. board_init_r is what calls the things to load
> > and boot the next stage (U-Boot or Linux).
> >
> > - In my series this has been changed slightly to be board_init_f calls
> > memset and then board_init_r directly. So this patch should not be
> > needed once rebased on that series.
>
> Do we need to do all the relocation in assembler code btw? Can it not be moved
> into C code and made generic across all platforms (module the stack adjustment
> and a few minor things) ?
I think people have posted patches for this before and yes, once
CONFIG_NEEDS_MANUAL_RELOC dies it should be all possible to do in C, so
long as it doesn't grow in size or doesn't grow in size that would be
problematic (remember the 4kb people).
--
Tom
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
2012-09-17 17:35 ` Tom Rini
@ 2012-09-17 17:48 ` Marek Vasut
2012-09-17 18:00 ` Tom Rini
0 siblings, 1 reply; 84+ messages in thread
From: Marek Vasut @ 2012-09-17 17:48 UTC (permalink / raw)
To: u-boot
Dear Tom Rini,
> On Mon, Sep 17, 2012 at 07:26:06PM +0200, Marek Vasut wrote:
> > Dear Tom Rini,
> >
> > > On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote:
> > > > Dear Jos? Miguel Gon?alves,
> > > >
> > > > > On 09/16/2012 11:06 AM, Marek Vasut wrote:
> > > > > > Dear Jos? Miguel Gon?alves,
> > > > > >
> > > > > >> On 09/15/2012 07:03 PM, Marek Vasut wrote:
> > > > > >>> Dear Jos? Miguel Gon?alves,
> > > > > >>>
> > > > > >>>> Jumping to board_init_r is not performed due to a bug on
> > > > > >>>> address computation.
> > > > > >>>
> > > > > >>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't
> > > > > >>> detect any misbehavior on my arm926 boards.
> > > > > >>
> > > > > >> Maybe because you are not using it to build an SPL?
> > > > > >
> > > > > > I do ... and I use CONFIG_SPL_TEXT_BASE properly .
> > > > > >
> > > > > >> Please check the same chunk of code in other start.S for arm1176
> > > > > >> and armv7. They have the same code that I put for arm926ejs.
> > > > > >
> > > > > > Please wait and please first explain what is the issue.
> > > > >
> > > > > The issue is what I've explained in the patch comments.
> > > >
> > > > "Jumping to board_init_r is not performed due to a bug on address
> > > > computation."
> > > >
> > > > Ok, I don't know how to replicate the bug from this comment or what
> > > > effects it causes or ... well, anything. So please, try to be more
> > > > elaborate in your patch description next time. Anyway ..
> > > >
> > > > > Without this
> > > > > change the code never reaches board_init_r in the SPL and I think I
> > > > > have all the configurations correctly set.
> > > >
> > > > I wonder why you'd ever want to reach board_init_r in the SPL. SPL is
> > > > there only to load the real U-Boot from whatever media, so you
> > > > usually use either NAND SPL
> > >
> > > Here's a good point for me to jump in, I think. There's two things to
> > > understand:
> > > - In the current in-tree SPL implementations the code flow is
> > >
> > > board_init_f calls relocate_code() to clear the BSS _and_ get our
> > > jump to board_init_r. It does not actually relocate the running
> > > U-Boot, just clears the BSS. board_init_r is what calls the things
> > > to load and boot the next stage (U-Boot or Linux).
> > >
> > > - In my series this has been changed slightly to be board_init_f calls
> > >
> > > memset and then board_init_r directly. So this patch should not be
> > > needed once rebased on that series.
> >
> > Do we need to do all the relocation in assembler code btw? Can it not be
> > moved into C code and made generic across all platforms (module the
> > stack adjustment and a few minor things) ?
>
> I think people have posted patches for this before and yes, once
> CONFIG_NEEDS_MANUAL_RELOC dies it should be all possible to do in C, so
> long as it doesn't grow in size or doesn't grow in size that would be
> problematic (remember the 4kb people).
How does MANUAL_RELOC interfere with that? Eg. on ARM, it can already be shifted
to C. Then if we made it generic enough, those MANUAL_RELOC platforms could
simply adopt the C code.
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
2012-09-17 17:32 ` Scott Wood
@ 2012-09-17 17:53 ` Tom Rini
2012-09-17 18:16 ` Scott Wood
2012-09-17 19:52 ` Wolfgang Denk
0 siblings, 2 replies; 84+ messages in thread
From: Tom Rini @ 2012-09-17 17:53 UTC (permalink / raw)
To: u-boot
On 09/17/12 10:32, Scott Wood wrote:
> On 09/17/2012 11:51:52 AM, Tom Rini wrote:
>> On 09/17/12 09:27, Scott Wood wrote:
>> > On 09/17/2012 04:24:34 AM, Jos? Miguel Gon?alves wrote:
>> [snip]
>> >> If no one else has anything against, I will change the name of the new
>> >> target to u-boot-pad.bin
>> >
>> > What exactly is u-boot-pad.bin supposed to be? I hope that's not being
>> > proposed as the final output file the user sees.
>> >
>> > With old nand_spl we had u-boot-nand.bin for the final concatenated
>> > binary, but that's not appropriate for a generic spl. I think it would
>> > be better for the user to see "u-boot.bin" as the actual image to
>> put on
>> > the boot device, regardless of implementation details like spl, if
>> > there's no requirement of a specific file format. The second stage
>> > could become "u-boot-main.bin" or similar on builds where spl is used.
>>
>> We need some name that means "U-Boot SPL with U-Boot tacked on at the
>> end". This can optionally be padded to a defined size to make writing
>> to hardware easier. We also have the problem that "u-boot.bin" already
>> means something so it needs to be clear.
>
> u-boot.bin has traditionally (except for nand_spl and derivatives) meant
> the final image ready to put into flash, after any platform-specific
> layout issues are taken care of (e.g. on mpc83xx it will have a reset
> control word embedded, on mpc85xx it will be padded to 512K with a reset
> vector at the end, etc.). That we did the tweaking in the linker script
> rather than after linking seems like an inconsequential implementation
> detail.
Right, but it's also just objcopy (with OBJCFLAGS) -O binary of, and
this is the biggie to me, just U-Boot.
>> I further fear that even if we
>> made an "out" directory if we put u-boot.bin in there and it's not the
>> same as the objcopy -O binary u-boot u-boot.bin as before we've violated
>> the rule of least surprise and the end user problems from people that
>> read "the" document (that happened to be out of date) will be our
>> problem.
>
> In this case I think you can't meet one user's expectations without
> violating another's. I think it's more important to make it clear to
> the user what file they're supposed to put into flash. Users of
> platforms that are currently supported by nand_spl would probably like
> to continue seeing u-boot-nand.bin -- it's a tradeoff of historical
> stability versus current consistency.
Right. So I'm saying we need to set new expectations for everyone and
some human helper symlinks to help. A new top-level out or images or
something, with symlinks inside.
>> In short, at least a few people have said something along the lines of
>> "We need generic output nameo $mediums and targets" but there's two hard
>> problems, one of which is that every SoC _needs_ things tweaked just so
>> (no header? no boot!), sometimes wants things tweaked further (pad the
>> final image out to be easier to write to $medium) and sometimes needs
>> multiple files (the whole of 'SPL' will be read so it must fit into
>> $SMALL_MEMORY). The other is naming.
>
> A simple concatenation of a padded SPL plus the main U-Boot was good
> enough for all the nand_spl boards AFAIK, so it's not quite every SoC
> that needs something special here. For those that do require a special
> format (or multiple files) with a file extension that is familiar to
> people working with that platform, using that extension makes sense.
> "pad" does not, and a proliferation of SoC-specific suffixes isn't much
> better.
I think we're running into PowerPC vs ARM "fun". We've got 7 or so
different "whack the image for this SoC for this medium" type things
already.
--
Tom
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
2012-09-17 17:08 ` José Miguel Gonçalves
@ 2012-09-17 17:56 ` Tom Rini
2012-09-17 18:05 ` José Miguel Gonçalves
0 siblings, 1 reply; 84+ messages in thread
From: Tom Rini @ 2012-09-17 17:56 UTC (permalink / raw)
To: u-boot
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/17/12 10:08, Jos? Miguel Gon?alves wrote:
> On 17-09-2012 17:57, Tom Rini wrote:
>> On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves
>> wrote:
>>> On 09/14/2012 08:01 PM, Tom Rini wrote:
>>>> On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel
>>>> Gon?alves wrote:
>>>>> On 14-09-2012 19:21, Marek Vasut wrote:
>>>>>> Dear Jos? Miguel Gon?alves,
>>>>>>
>>>>>>> NAND Flash driver with HW ECC for the S3C24XX SoCs.
>>>>>>> Currently it only supports SLC NAND chips.
>>>>>>>
>>>>>>> Signed-off-by: Jos? Miguel Gon?alves
>>>>>>> <jose.goncalves@inov.pt>
>>>>>> [...]
>>>>>>
>>>>>>> +#include <common.h> +#include <nand.h> +#include
>>>>>>> <asm/io.h> +#include <asm/arch/s3c24xx_cpu.h> +#include
>>>>>>> <asm/errno.h> + +#define MAX_CHIPS 2 +static int
>>>>>>> nand_cs[MAX_CHIPS] = { 0, 1 }; + +#ifdef
>>>>>>> CONFIG_SPL_BUILD +#define printf(arg...) do {} while
>>>>>>> (0)
>>>>>> This doesn't seem quite right ...
>>>>>>
>>>>>> 1) this should be in CPU directory 2) should be enabled
>>>>>> only if CONFIG_SPL_SERIAL_SUPPORT is not set 3) should be
>>>>>> inline function, not a macro
>>>>> 1) and 3) OK. Don't quite understand 2). I want to remove
>>>>> the printfs in the SPL build, as it would blown up the
>>>>> internal SoC RAM space available. So why add a condition
>>>>> with CONFIG_SPL_SERIAL_SUPPORT?
>>>> You've got 8KB, based on the final patch in the series. At
>>>> least in my SPL series that's still enough to get you
>>>> printf/puts (I believe 4kb was the cutoff where that had to
>>>> be dropped).
>>>>
>>> Barely:
>>>
>>> $ size u-boot-spl text data bss dec
>>> hex filename 3337 8 588 3933
>>> f5d u-boot-spl
>>>
>>> $ size u-boot-spl-printf text data bss dec
>>> hex filename 7968 8 604 8580
>>> 2184 u-boot-spl-printf
>>>
>>> The printf is not so important that justifies exhausting the
>>> IRAM space available and preventing any future SPL
>>> expansion...
>> There's two parts to this: - What else can you do in a single
>> binary, in theory? Is there boot medium detection and you would
>> want to have, for example, NAND and SD support in the same
>> binary? I would say memory is meant for using, but this is a
>> board maintainer decision and that's you :)
>
> That's exactly what I've got in mind when I talked about a future
> expansion! Being able to boot also from an SD card. With only 8KB
> for .text and .data, I can not use printfs in the SPL for this
> platform (at least with the present printf support for SPL).
>
>> - We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT) that
>> toggles printf or no printf. If we really need to say yes to
>> LIBCOMMON_SUPPORT and no to printf, we need finer grained config
>> options and then a do-nothing printf is used for SPL. Doing the
>> opt-out driver by driver just punts this problem down the road to
>> the next developer and that's not very nice (and adding
>> CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few
>> Makefiles, update a bunch of config files, add
>> common/spl/dummy_funcs.c and a __weak printf).
OK, so please take a stab at option two, on top of my SPL series,
keeping in mind what Scott has said (which makes sense) because
otherwise you'll be changing a lot of MMC files too to drop out printf :)
- --
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQIcBAEBAgAGBQJQV2Q+AAoJENk4IS6UOR1W0VMP/1ToNzW5XmNApUGYIZi1d779
hJ6MieZoiTHOCnrHiRMMMAfOnPNnt+63TozmXWkhNhlPVRCs1Irx8nCpzMabjevr
ZENjnewtKsvgBsICak5rSQLbfyQBUG8tL3iBMPnYwyNhDf8CgED6rNCnxhV8Lr7j
o0gELaNHPRD7bJwglXo3TN0BxNtTrww3uSArSYh4WMVaOP908Mk7p7y8qEVSvNeh
BrdbVZK1oPmhlke9EUXfCQYqn/JdJ7mtdW1q5PdST7GFtnLZmqpj+FuOEwN3OioA
DE6J461Aqr95mGVUnUr7PxglytL6zLKJcE8YpIhu9nL6r9QRg0wm4HIKr3uTKLl5
WBs4ziJsLtm5IAZ7xg2FOsPrCkrAiL3bVQg0+7xVc1cVzKIGmtMR6oGVS+nI38Q6
lzmz0AQSuobeLkiP4+tL8C7kFkwMcj9I5LByN968ZMvbTftecIsdgYSkluOdGU5w
dwKPjplU4t8yy6d1TXbh0Xdw7q8cBZ3bjqbAKi3uo9BpEHgCDOwHp7oOTuJTDB/7
C6WxXHdQFHh7m0hxf1zkawOeh+oqd5MHAxjlckQ/zmg5UsmNWDA6RmmYgWrOBw9m
jCvN/lhe1soBnxaz2byUKwEkPIDwmBl+JgtSL7DMZ7bLfS59daXiaMNac2JPstG3
j0lBvj7SCVnQrE6SJxxa
=71I1
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
2012-09-17 17:48 ` Marek Vasut
@ 2012-09-17 18:00 ` Tom Rini
0 siblings, 0 replies; 84+ messages in thread
From: Tom Rini @ 2012-09-17 18:00 UTC (permalink / raw)
To: u-boot
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/17/12 10:48, Marek Vasut wrote:
> Dear Tom Rini,
>
>> On Mon, Sep 17, 2012 at 07:26:06PM +0200, Marek Vasut wrote:
>>> Dear Tom Rini,
>>>
>>>> On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote:
>>>>> Dear Jos? Miguel Gon?alves,
>>>>>
>>>>>> On 09/16/2012 11:06 AM, Marek Vasut wrote:
>>>>>>> Dear Jos? Miguel Gon?alves,
>>>>>>>
>>>>>>>> On 09/15/2012 07:03 PM, Marek Vasut wrote:
>>>>>>>>> Dear Jos? Miguel Gon?alves,
>>>>>>>>>
>>>>>>>>>> Jumping to board_init_r is not performed due to a
>>>>>>>>>> bug on address computation.
>>>>>>>>>
>>>>>>>>> Is your CONFIG_SYS_TEXT_BASE configured correctly?
>>>>>>>>> I don't detect any misbehavior on my arm926
>>>>>>>>> boards.
>>>>>>>>
>>>>>>>> Maybe because you are not using it to build an SPL?
>>>>>>>
>>>>>>> I do ... and I use CONFIG_SPL_TEXT_BASE properly .
>>>>>>>
>>>>>>>> Please check the same chunk of code in other start.S
>>>>>>>> for arm1176 and armv7. They have the same code that I
>>>>>>>> put for arm926ejs.
>>>>>>>
>>>>>>> Please wait and please first explain what is the
>>>>>>> issue.
>>>>>>
>>>>>> The issue is what I've explained in the patch comments.
>>>>>
>>>>> "Jumping to board_init_r is not performed due to a bug on
>>>>> address computation."
>>>>>
>>>>> Ok, I don't know how to replicate the bug from this comment
>>>>> or what effects it causes or ... well, anything. So please,
>>>>> try to be more elaborate in your patch description next
>>>>> time. Anyway ..
>>>>>
>>>>>> Without this change the code never reaches board_init_r
>>>>>> in the SPL and I think I have all the configurations
>>>>>> correctly set.
>>>>>
>>>>> I wonder why you'd ever want to reach board_init_r in the
>>>>> SPL. SPL is there only to load the real U-Boot from
>>>>> whatever media, so you usually use either NAND SPL
>>>>
>>>> Here's a good point for me to jump in, I think. There's two
>>>> things to understand: - In the current in-tree SPL
>>>> implementations the code flow is
>>>>
>>>> board_init_f calls relocate_code() to clear the BSS _and_ get
>>>> our jump to board_init_r. It does not actually relocate the
>>>> running U-Boot, just clears the BSS. board_init_r is what
>>>> calls the things to load and boot the next stage (U-Boot or
>>>> Linux).
>>>>
>>>> - In my series this has been changed slightly to be
>>>> board_init_f calls
>>>>
>>>> memset and then board_init_r directly. So this patch should
>>>> not be needed once rebased on that series.
>>>
>>> Do we need to do all the relocation in assembler code btw? Can
>>> it not be moved into C code and made generic across all
>>> platforms (module the stack adjustment and a few minor things)
>>> ?
>>
>> I think people have posted patches for this before and yes, once
>> CONFIG_NEEDS_MANUAL_RELOC dies it should be all possible to do in
>> C, so long as it doesn't grow in size or doesn't grow in size
>> that would be problematic (remember the 4kb people).
>
> How does MANUAL_RELOC interfere with that? Eg. on ARM, it can
> already be shifted to C. Then if we made it generic enough, those
> MANUAL_RELOC platforms could simply adopt the C code.
Yes, one of the platforms that already has C code for ELF relocation
(x86, iirc) could be made more generic and I think someone (Graeme?)
already started this a long time ago as part of making a generic set
of functions for board_init_{f,r}. Just can't make it for all
platforms until everyone has ELF is the point I was poorly making.
- --
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQIcBAEBAgAGBQJQV2VKAAoJENk4IS6UOR1W3McP/1htBzFzXXPULGOO+1zanoaO
T2tmJZ9f4gHNIY6gnCdU7SlW4mhZPEFlwHD+JwPmIS7ZhGcPxVn9Vgl+r0fpEZHW
VBY1bGeSGmaLhziiT+9MmaUqKUx6IFN5nZX0ypYcHS1ZTo1JztvLSUrSdOnOYHWx
DXXPwNIreUctwIpyjNrhu93e39ep1AYb1ZW+o57Sj4+uGqt8+G9FpEjdxMQrjKqh
r88j7XRgfWNPiqLwuGy+7HHEXnQGDum3Aml/ojO3WSzpZYXZQ4zC4MTND+TwzSi6
h3+nB3OfYktPgFWRDYQt8VyWPl9beVHzhac3o6sF5SiclQyya0liCCNsSbDSKf/G
Zjpjg5cOAmPMMUs1ZXq2Ve5wMxb0alArzxZuMZ/ZA1gRDjazFErvYCUzAQFkDAZz
zB6YMNc1+iCaYyaeNOqvJdMOZXAIoGLx5bbv9dzsnYc45jeU1ScDywcOQC2jTYFf
jnzmqzh/6EJW2gfWW33XdxbHsDOZeEfCzJFmK7/vEbVW0TrkiCMJjHzf/jdguABQ
jhusLwYYJr5yNlwq16RmiPxIaUhBrCFLY5cxLiSTd4v0DdbqyaTC7MEadjKQLpBW
/LA5ImhXr/ORhfNTrVQjDSRhAGdmi2L0GVTurHJ2I6SCIVesu/ioMCGY3sy+aizK
H3jl0yobGtRNFamgK+Ld
=ncZ8
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
2012-09-17 17:56 ` Tom Rini
@ 2012-09-17 18:05 ` José Miguel Gonçalves
2012-09-17 18:27 ` Tom Rini
0 siblings, 1 reply; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-17 18:05 UTC (permalink / raw)
To: u-boot
On 17-09-2012 18:56, Tom Rini wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 09/17/12 10:08, Jos? Miguel Gon?alves wrote:
>> On 17-09-2012 17:57, Tom Rini wrote:
>>> On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves
>>> wrote:
>>>> On 09/14/2012 08:01 PM, Tom Rini wrote:
>>>>> On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel
>>>>> Gon?alves wrote:
>>>>>> On 14-09-2012 19:21, Marek Vasut wrote:
>>>>>>> Dear Jos? Miguel Gon?alves,
>>>>>>>
>>>>>>>> NAND Flash driver with HW ECC for the S3C24XX SoCs.
>>>>>>>> Currently it only supports SLC NAND chips.
>>>>>>>>
>>>>>>>> Signed-off-by: Jos? Miguel Gon?alves
>>>>>>>> <jose.goncalves@inov.pt>
>>>>>>> [...]
>>>>>>>
>>>>>>>> +#include <common.h> +#include <nand.h> +#include
>>>>>>>> <asm/io.h> +#include <asm/arch/s3c24xx_cpu.h> +#include
>>>>>>>> <asm/errno.h> + +#define MAX_CHIPS 2 +static int
>>>>>>>> nand_cs[MAX_CHIPS] = { 0, 1 }; + +#ifdef
>>>>>>>> CONFIG_SPL_BUILD +#define printf(arg...) do {} while
>>>>>>>> (0)
>>>>>>> This doesn't seem quite right ...
>>>>>>>
>>>>>>> 1) this should be in CPU directory 2) should be enabled
>>>>>>> only if CONFIG_SPL_SERIAL_SUPPORT is not set 3) should be
>>>>>>> inline function, not a macro
>>>>>> 1) and 3) OK. Don't quite understand 2). I want to remove
>>>>>> the printfs in the SPL build, as it would blown up the
>>>>>> internal SoC RAM space available. So why add a condition
>>>>>> with CONFIG_SPL_SERIAL_SUPPORT?
>>>>> You've got 8KB, based on the final patch in the series. At
>>>>> least in my SPL series that's still enough to get you
>>>>> printf/puts (I believe 4kb was the cutoff where that had to
>>>>> be dropped).
>>>>>
>>>> Barely:
>>>>
>>>> $ size u-boot-spl text data bss dec
>>>> hex filename 3337 8 588 3933
>>>> f5d u-boot-spl
>>>>
>>>> $ size u-boot-spl-printf text data bss dec
>>>> hex filename 7968 8 604 8580
>>>> 2184 u-boot-spl-printf
>>>>
>>>> The printf is not so important that justifies exhausting the
>>>> IRAM space available and preventing any future SPL
>>>> expansion...
>>> There's two parts to this: - What else can you do in a single
>>> binary, in theory? Is there boot medium detection and you would
>>> want to have, for example, NAND and SD support in the same
>>> binary? I would say memory is meant for using, but this is a
>>> board maintainer decision and that's you :)
>> That's exactly what I've got in mind when I talked about a future
>> expansion! Being able to boot also from an SD card. With only 8KB
>> for .text and .data, I can not use printfs in the SPL for this
>> platform (at least with the present printf support for SPL).
>>
>>> - We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT) that
>>> toggles printf or no printf. If we really need to say yes to
>>> LIBCOMMON_SUPPORT and no to printf, we need finer grained config
>>> options and then a do-nothing printf is used for SPL. Doing the
>>> opt-out driver by driver just punts this problem down the road to
>>> the next developer and that's not very nice (and adding
>>> CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few
>>> Makefiles, update a bunch of config files, add
>>> common/spl/dummy_funcs.c and a __weak printf).
> OK, so please take a stab at option two, on top of my SPL series,
> keeping in mind what Scott has said (which makes sense) because
> otherwise you'll be changing a lot of MMC files too to drop out printf :)
The solution that I sorted out on the current SPL framework was to add this:
#ifdef CONFIG_SPL_BUILD
#define printf(arg...) do {} while (0)
#ifdef CONFIG_SPL_SERIAL_SUPPORT
#define puts(arg) serial_puts(arg)
#endif
#endif
on a CPU specific header. Marek told me to not use macros, but to use inline
functions instead, but has I told earlier on this thread, I am unable to do that.
Suggestions for doing this in a better way are welcome...
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
2012-09-17 17:53 ` Tom Rini
@ 2012-09-17 18:16 ` Scott Wood
2012-09-17 19:52 ` Wolfgang Denk
1 sibling, 0 replies; 84+ messages in thread
From: Scott Wood @ 2012-09-17 18:16 UTC (permalink / raw)
To: u-boot
On 09/17/2012 12:53:41 PM, Tom Rini wrote:
> On 09/17/12 10:32, Scott Wood wrote:
> > On 09/17/2012 11:51:52 AM, Tom Rini wrote:
> >> On 09/17/12 09:27, Scott Wood wrote:
> >> > On 09/17/2012 04:24:34 AM, Jos? Miguel Gon?alves wrote:
> >> [snip]
> >> >> If no one else has anything against, I will change the name of
> the new
> >> >> target to u-boot-pad.bin
> >> >
> >> > What exactly is u-boot-pad.bin supposed to be? I hope that's
> not being
> >> > proposed as the final output file the user sees.
> >> >
> >> > With old nand_spl we had u-boot-nand.bin for the final
> concatenated
> >> > binary, but that's not appropriate for a generic spl. I think
> it would
> >> > be better for the user to see "u-boot.bin" as the actual image to
> >> put on
> >> > the boot device, regardless of implementation details like spl,
> if
> >> > there's no requirement of a specific file format. The second
> stage
> >> > could become "u-boot-main.bin" or similar on builds where spl is
> used.
> >>
> >> We need some name that means "U-Boot SPL with U-Boot tacked on at
> the
> >> end". This can optionally be padded to a defined size to make
> writing
> >> to hardware easier. We also have the problem that "u-boot.bin"
> already
> >> means something so it needs to be clear.
> >
> > u-boot.bin has traditionally (except for nand_spl and derivatives)
> meant
> > the final image ready to put into flash, after any platform-specific
> > layout issues are taken care of (e.g. on mpc83xx it will have a
> reset
> > control word embedded, on mpc85xx it will be padded to 512K with a
> reset
> > vector at the end, etc.). That we did the tweaking in the linker
> script
> > rather than after linking seems like an inconsequential
> implementation
> > detail.
>
> Right, but it's also just objcopy (with OBJCFLAGS) -O binary of, and
> this is the biggie to me, just U-Boot.
>
> >> I further fear that even if we
> >> made an "out" directory if we put u-boot.bin in there and it's not
> the
> >> same as the objcopy -O binary u-boot u-boot.bin as before we've
> violated
> >> the rule of least surprise and the end user problems from people
> that
> >> read "the" document (that happened to be out of date) will be our
> >> problem.
> >
> > In this case I think you can't meet one user's expectations without
> > violating another's. I think it's more important to make it clear
> to
> > the user what file they're supposed to put into flash. Users of
> > platforms that are currently supported by nand_spl would probably
> like
> > to continue seeing u-boot-nand.bin -- it's a tradeoff of historical
> > stability versus current consistency.
>
> Right. So I'm saying we need to set new expectations for everyone and
> some human helper symlinks to help. A new top-level out or images or
> something, with symlinks inside.
How about something like "u-boot-final.bin"[1], "u-boot-all.bin",
"u-boot-image.bin", etc. as the end-user output, with ".bin" changed to
something else if it's a well known file type? At least for the boards
that only require one output file.
-Scott
[1] Though then LDFLAGS_FINAL becomes confusing...
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
2012-09-17 18:05 ` José Miguel Gonçalves
@ 2012-09-17 18:27 ` Tom Rini
2012-09-17 18:34 ` José Miguel Gonçalves
0 siblings, 1 reply; 84+ messages in thread
From: Tom Rini @ 2012-09-17 18:27 UTC (permalink / raw)
To: u-boot
On Mon, Sep 17, 2012 at 07:05:48PM +0100, Jos? Miguel Gon?alves wrote:
> On 17-09-2012 18:56, Tom Rini wrote:
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >On 09/17/12 10:08, Jos? Miguel Gon?alves wrote:
> >>On 17-09-2012 17:57, Tom Rini wrote:
> >>>On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves
> >>>wrote:
> >>>>On 09/14/2012 08:01 PM, Tom Rini wrote:
> >>>>>On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel
> >>>>>Gon?alves wrote:
> >>>>>>On 14-09-2012 19:21, Marek Vasut wrote:
> >>>>>>>Dear Jos? Miguel Gon?alves,
> >>>>>>>
> >>>>>>>>NAND Flash driver with HW ECC for the S3C24XX SoCs.
> >>>>>>>>Currently it only supports SLC NAND chips.
> >>>>>>>>
> >>>>>>>>Signed-off-by: Jos? Miguel Gon?alves
> >>>>>>>><jose.goncalves@inov.pt>
> >>>>>>>[...]
> >>>>>>>
> >>>>>>>>+#include <common.h> +#include <nand.h> +#include
> >>>>>>>><asm/io.h> +#include <asm/arch/s3c24xx_cpu.h> +#include
> >>>>>>>><asm/errno.h> + +#define MAX_CHIPS 2 +static int
> >>>>>>>>nand_cs[MAX_CHIPS] = { 0, 1 }; + +#ifdef
> >>>>>>>>CONFIG_SPL_BUILD +#define printf(arg...) do {} while
> >>>>>>>>(0)
> >>>>>>>This doesn't seem quite right ...
> >>>>>>>
> >>>>>>>1) this should be in CPU directory 2) should be enabled
> >>>>>>>only if CONFIG_SPL_SERIAL_SUPPORT is not set 3) should be
> >>>>>>>inline function, not a macro
> >>>>>>1) and 3) OK. Don't quite understand 2). I want to remove
> >>>>>>the printfs in the SPL build, as it would blown up the
> >>>>>>internal SoC RAM space available. So why add a condition
> >>>>>>with CONFIG_SPL_SERIAL_SUPPORT?
> >>>>>You've got 8KB, based on the final patch in the series. At
> >>>>>least in my SPL series that's still enough to get you
> >>>>>printf/puts (I believe 4kb was the cutoff where that had to
> >>>>>be dropped).
> >>>>>
> >>>>Barely:
> >>>>
> >>>>$ size u-boot-spl text data bss dec
> >>>>hex filename 3337 8 588 3933
> >>>>f5d u-boot-spl
> >>>>
> >>>>$ size u-boot-spl-printf text data bss dec
> >>>>hex filename 7968 8 604 8580
> >>>>2184 u-boot-spl-printf
> >>>>
> >>>>The printf is not so important that justifies exhausting the
> >>>>IRAM space available and preventing any future SPL
> >>>>expansion...
> >>>There's two parts to this: - What else can you do in a single
> >>>binary, in theory? Is there boot medium detection and you would
> >>>want to have, for example, NAND and SD support in the same
> >>>binary? I would say memory is meant for using, but this is a
> >>>board maintainer decision and that's you :)
> >>That's exactly what I've got in mind when I talked about a future
> >>expansion! Being able to boot also from an SD card. With only 8KB
> >>for .text and .data, I can not use printfs in the SPL for this
> >>platform (at least with the present printf support for SPL).
> >>
> >>>- We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT) that
> >>>toggles printf or no printf. If we really need to say yes to
> >>>LIBCOMMON_SUPPORT and no to printf, we need finer grained config
> >>>options and then a do-nothing printf is used for SPL. Doing the
> >>>opt-out driver by driver just punts this problem down the road to
> >>>the next developer and that's not very nice (and adding
> >>>CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few
> >>>Makefiles, update a bunch of config files, add
> >>>common/spl/dummy_funcs.c and a __weak printf).
> >OK, so please take a stab at option two, on top of my SPL series,
> >keeping in mind what Scott has said (which makes sense) because
> >otherwise you'll be changing a lot of MMC files too to drop out printf :)
>
> The solution that I sorted out on the current SPL framework was to add this:
>
> #ifdef CONFIG_SPL_BUILD
> #define printf(arg...) do {} while (0)
> #ifdef CONFIG_SPL_SERIAL_SUPPORT
> #define puts(arg) serial_puts(arg)
> #endif
> #endif
>
> on a CPU specific header. Marek told me to not use macros, but to
> use inline functions instead, but has I told earlier on this thread,
> I am unable to do that. Suggestions for doing this in a better way
> are welcome...
It's gotta go in <common.h>, and something like
/* Big comment what / why */
#if !defined(CONFIG_SPL_BUILD) || \
(CONFIG_SPL_BUILD && CONFIG_SPL_PRINTF_SUPPORT)
void putc(...);
void puts(...);
int printf(....);
#else
#define putc(c) serial_putc(c)
#define puts(s) serial_puts(s)
#define printf(arg...) do {} while (0)
#endif
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120917/725562d3/attachment.pgp>
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
2012-09-17 18:27 ` Tom Rini
@ 2012-09-17 18:34 ` José Miguel Gonçalves
2012-09-17 18:56 ` Tom Rini
0 siblings, 1 reply; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-17 18:34 UTC (permalink / raw)
To: u-boot
On 17-09-2012 19:27, Tom Rini wrote:
> On Mon, Sep 17, 2012 at 07:05:48PM +0100, Jos? Miguel Gon?alves wrote:
>> On 17-09-2012 18:56, Tom Rini wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 09/17/12 10:08, Jos? Miguel Gon?alves wrote:
>>>> On 17-09-2012 17:57, Tom Rini wrote:
>>>>> On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel Gon?alves
>>>>> wrote:
>>>>>> On 09/14/2012 08:01 PM, Tom Rini wrote:
>>>>>>> On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos? Miguel
>>>>>>> Gon?alves wrote:
>>>>>>>> On 14-09-2012 19:21, Marek Vasut wrote:
>>>>>>>>> Dear Jos? Miguel Gon?alves,
>>>>>>>>>
>>>>>>>>>> NAND Flash driver with HW ECC for the S3C24XX SoCs.
>>>>>>>>>> Currently it only supports SLC NAND chips.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Jos? Miguel Gon?alves
>>>>>>>>>> <jose.goncalves@inov.pt>
>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>>> +#include <common.h> +#include <nand.h> +#include
>>>>>>>>>> <asm/io.h> +#include <asm/arch/s3c24xx_cpu.h> +#include
>>>>>>>>>> <asm/errno.h> + +#define MAX_CHIPS 2 +static int
>>>>>>>>>> nand_cs[MAX_CHIPS] = { 0, 1 }; + +#ifdef
>>>>>>>>>> CONFIG_SPL_BUILD +#define printf(arg...) do {} while
>>>>>>>>>> (0)
>>>>>>>>> This doesn't seem quite right ...
>>>>>>>>>
>>>>>>>>> 1) this should be in CPU directory 2) should be enabled
>>>>>>>>> only if CONFIG_SPL_SERIAL_SUPPORT is not set 3) should be
>>>>>>>>> inline function, not a macro
>>>>>>>> 1) and 3) OK. Don't quite understand 2). I want to remove
>>>>>>>> the printfs in the SPL build, as it would blown up the
>>>>>>>> internal SoC RAM space available. So why add a condition
>>>>>>>> with CONFIG_SPL_SERIAL_SUPPORT?
>>>>>>> You've got 8KB, based on the final patch in the series. At
>>>>>>> least in my SPL series that's still enough to get you
>>>>>>> printf/puts (I believe 4kb was the cutoff where that had to
>>>>>>> be dropped).
>>>>>>>
>>>>>> Barely:
>>>>>>
>>>>>> $ size u-boot-spl text data bss dec
>>>>>> hex filename 3337 8 588 3933
>>>>>> f5d u-boot-spl
>>>>>>
>>>>>> $ size u-boot-spl-printf text data bss dec
>>>>>> hex filename 7968 8 604 8580
>>>>>> 2184 u-boot-spl-printf
>>>>>>
>>>>>> The printf is not so important that justifies exhausting the
>>>>>> IRAM space available and preventing any future SPL
>>>>>> expansion...
>>>>> There's two parts to this: - What else can you do in a single
>>>>> binary, in theory? Is there boot medium detection and you would
>>>>> want to have, for example, NAND and SD support in the same
>>>>> binary? I would say memory is meant for using, but this is a
>>>>> board maintainer decision and that's you :)
>>>> That's exactly what I've got in mind when I talked about a future
>>>> expansion! Being able to boot also from an SD card. With only 8KB
>>>> for .text and .data, I can not use printfs in the SPL for this
>>>> platform (at least with the present printf support for SPL).
>>>>
>>>>> - We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT) that
>>>>> toggles printf or no printf. If we really need to say yes to
>>>>> LIBCOMMON_SUPPORT and no to printf, we need finer grained config
>>>>> options and then a do-nothing printf is used for SPL. Doing the
>>>>> opt-out driver by driver just punts this problem down the road to
>>>>> the next developer and that's not very nice (and adding
>>>>> CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch, modify a few
>>>>> Makefiles, update a bunch of config files, add
>>>>> common/spl/dummy_funcs.c and a __weak printf).
>>> OK, so please take a stab at option two, on top of my SPL series,
>>> keeping in mind what Scott has said (which makes sense) because
>>> otherwise you'll be changing a lot of MMC files too to drop out printf :)
>> The solution that I sorted out on the current SPL framework was to add this:
>>
>> #ifdef CONFIG_SPL_BUILD
>> #define printf(arg...) do {} while (0)
>> #ifdef CONFIG_SPL_SERIAL_SUPPORT
>> #define puts(arg) serial_puts(arg)
>> #endif
>> #endif
>>
>> on a CPU specific header. Marek told me to not use macros, but to
>> use inline functions instead, but has I told earlier on this thread,
>> I am unable to do that. Suggestions for doing this in a better way
>> are welcome...
> It's gotta go in <common.h>, and something like
> /* Big comment what / why */
> #if !defined(CONFIG_SPL_BUILD) || \
> (CONFIG_SPL_BUILD && CONFIG_SPL_PRINTF_SUPPORT)
> void putc(...);
> void puts(...);
> int printf(....);
> #else
> #define putc(c) serial_putc(c)
> #define puts(s) serial_puts(s)
> #define printf(arg...) do {} while (0)
> #endif
>
Are macros OK to remove printf() and to replace putc()/puts() by
serial_putc()/serial_puts() in the SPL?
Shouldn?t we be using inline functions instead?
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver
2012-09-17 18:34 ` José Miguel Gonçalves
@ 2012-09-17 18:56 ` Tom Rini
0 siblings, 0 replies; 84+ messages in thread
From: Tom Rini @ 2012-09-17 18:56 UTC (permalink / raw)
To: u-boot
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/17/12 11:34, Jos? Miguel Gon?alves wrote:
> On 17-09-2012 19:27, Tom Rini wrote:
>> On Mon, Sep 17, 2012 at 07:05:48PM +0100, Jos? Miguel Gon?alves
>> wrote:
>>> On 17-09-2012 18:56, Tom Rini wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>
>>>> On 09/17/12 10:08, Jos? Miguel Gon?alves wrote:
>>>>> On 17-09-2012 17:57, Tom Rini wrote:
>>>>>> On Sun, Sep 16, 2012 at 10:16:47AM +0100, Jos? Miguel
>>>>>> Gon?alves wrote:
>>>>>>> On 09/14/2012 08:01 PM, Tom Rini wrote:
>>>>>>>> On Fri, Sep 14, 2012 at 07:45:40PM +0100, Jos?
>>>>>>>> Miguel Gon?alves wrote:
>>>>>>>>> On 14-09-2012 19:21, Marek Vasut wrote:
>>>>>>>>>> Dear Jos? Miguel Gon?alves,
>>>>>>>>>>
>>>>>>>>>>> NAND Flash driver with HW ECC for the S3C24XX
>>>>>>>>>>> SoCs. Currently it only supports SLC NAND
>>>>>>>>>>> chips.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Jos? Miguel Gon?alves
>>>>>>>>>>> <jose.goncalves@inov.pt>
>>>>>>>>>> [...]
>>>>>>>>>>
>>>>>>>>>>> +#include <common.h> +#include <nand.h>
>>>>>>>>>>> +#include <asm/io.h> +#include
>>>>>>>>>>> <asm/arch/s3c24xx_cpu.h> +#include
>>>>>>>>>>> <asm/errno.h> + +#define MAX_CHIPS 2 +static
>>>>>>>>>>> int nand_cs[MAX_CHIPS] = { 0, 1 }; + +#ifdef
>>>>>>>>>>> CONFIG_SPL_BUILD +#define printf(arg...) do {}
>>>>>>>>>>> while (0)
>>>>>>>>>> This doesn't seem quite right ...
>>>>>>>>>>
>>>>>>>>>> 1) this should be in CPU directory 2) should be
>>>>>>>>>> enabled only if CONFIG_SPL_SERIAL_SUPPORT is not
>>>>>>>>>> set 3) should be inline function, not a macro
>>>>>>>>> 1) and 3) OK. Don't quite understand 2). I want to
>>>>>>>>> remove the printfs in the SPL build, as it would
>>>>>>>>> blown up the internal SoC RAM space available. So
>>>>>>>>> why add a condition with
>>>>>>>>> CONFIG_SPL_SERIAL_SUPPORT?
>>>>>>>> You've got 8KB, based on the final patch in the
>>>>>>>> series. At least in my SPL series that's still
>>>>>>>> enough to get you printf/puts (I believe 4kb was the
>>>>>>>> cutoff where that had to be dropped).
>>>>>>>>
>>>>>>> Barely:
>>>>>>>
>>>>>>> $ size u-boot-spl text data bss
>>>>>>> dec hex filename 3337 8 588
>>>>>>> 3933 f5d u-boot-spl
>>>>>>>
>>>>>>> $ size u-boot-spl-printf text data bss
>>>>>>> dec hex filename 7968 8 604
>>>>>>> 8580 2184 u-boot-spl-printf
>>>>>>>
>>>>>>> The printf is not so important that justifies
>>>>>>> exhausting the IRAM space available and preventing any
>>>>>>> future SPL expansion...
>>>>>> There's two parts to this: - What else can you do in a
>>>>>> single binary, in theory? Is there boot medium detection
>>>>>> and you would want to have, for example, NAND and SD
>>>>>> support in the same binary? I would say memory is meant
>>>>>> for using, but this is a board maintainer decision and
>>>>>> that's you :)
>>>>> That's exactly what I've got in mind when I talked about a
>>>>> future expansion! Being able to boot also from an SD card.
>>>>> With only 8KB for .text and .data, I can not use printfs in
>>>>> the SPL for this platform (at least with the present printf
>>>>> support for SPL).
>>>>>
>>>>>> - We have a define today (CONFIG_SPL_LIBCOMMON_SUPPORT)
>>>>>> that toggles printf or no printf. If we really need to
>>>>>> say yes to LIBCOMMON_SUPPORT and no to printf, we need
>>>>>> finer grained config options and then a do-nothing printf
>>>>>> is used for SPL. Doing the opt-out driver by driver just
>>>>>> punts this problem down the road to the next developer
>>>>>> and that's not very nice (and adding
>>>>>> CONFIG_SPL_PRINTF_SUPPORT shouldn't be a big patch,
>>>>>> modify a few Makefiles, update a bunch of config files,
>>>>>> add common/spl/dummy_funcs.c and a __weak printf).
>>>> OK, so please take a stab at option two, on top of my SPL
>>>> series, keeping in mind what Scott has said (which makes
>>>> sense) because otherwise you'll be changing a lot of MMC
>>>> files too to drop out printf :)
>>> The solution that I sorted out on the current SPL framework was
>>> to add this:
>>>
>>> #ifdef CONFIG_SPL_BUILD #define printf(arg...) do {} while (0)
>>> #ifdef CONFIG_SPL_SERIAL_SUPPORT #define puts(arg)
>>> serial_puts(arg) #endif #endif
>>>
>>> on a CPU specific header. Marek told me to not use macros, but
>>> to use inline functions instead, but has I told earlier on this
>>> thread, I am unable to do that. Suggestions for doing this in a
>>> better way are welcome...
>> It's gotta go in <common.h>, and something like /* Big comment
>> what / why */ #if !defined(CONFIG_SPL_BUILD) || \
>> (CONFIG_SPL_BUILD && CONFIG_SPL_PRINTF_SUPPORT) void putc(...);
>> void puts(...); int printf(....); #else #define putc(c)
>> serial_putc(c) #define puts(s) serial_puts(s) #define
>> printf(arg...) do {} while (0) #endif
>>
>
> Are macros OK to remove printf() and to replace putc()/puts() by
> serial_putc()/serial_puts() in the SPL? Shouldn?t we be using
> inline functions instead?
As Scott pointed out, inline won't remove the string constants from
the binary so it will still be possibly too large, depending on all of
the code in question. And note the above isn't 100% right, we need a
test for SERIAL_SUPPORT in there too.
- --
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQIcBAEBAgAGBQJQV3JcAAoJENk4IS6UOR1WMe0P/RlvfaE4J6ZxdIAIy77XmqGt
KKTEnJV+dTu8/a9jrMZFmZ/lGNPNrujLlphNUgGZr2W1+lriHuCgAZx1ObsMXhx9
XGRn05gshUuUtTWRCpOy3Nzo9jPF/LYrWttBiwDfOPWZ6+6G3zGPIXV3T9HHEFMM
ti0c0zCBMu1ci5RoQg4Zb6CJqJR/giBrBzegQZlL4x8t9p/GR03MSxdVPHx+NoQ7
wTuom8Q2yE5o7xDlx+zjoGCemNAVae7HXggqyqNpjU0nDb/lBg1HcvVt6IuORx9t
U7u4yskgXom3RYetrKYdYPEE3yufONY3BkTEdHvS0lLE/dc7S8JKBLdAa0cCYEPG
PlzJtQa98cZgcWG2PCx9TT3S16FEs+xSu3yN/S5OsvD3LwmPwls45n0rVZf1qUTL
jHQ5NnFPC/xppZupRs4cr19ED8xs2YGKO7iHc3auPEz7rA6XuLGpMteFtBVM55+a
3JuZzzTMxgvP/i86VI6l+ClSLHXUHcVWPLE2bvmAvj3R2sRe6NaM8ldtWP6Wh0Hw
Ncp4mGLaCh7VkdAo9Uunnf+y0m15BoDNH5fgK0eNErYPAzH34AROTbIrTsl6JLmQ
+x1sYL3XLmw7z+nyd0a/IfcBjdDGeGZhaHItkCrIj5hOp937yZIEhtP8q8s93qxj
bURH7UFvYhsiUAp0NG4h
=Xg9g
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile
2012-09-17 17:53 ` Tom Rini
2012-09-17 18:16 ` Scott Wood
@ 2012-09-17 19:52 ` Wolfgang Denk
1 sibling, 0 replies; 84+ messages in thread
From: Wolfgang Denk @ 2012-09-17 19:52 UTC (permalink / raw)
To: u-boot
Dear Tom Rini,
In message <505763A5.1030101@ti.com> you wrote:
>
> Right. So I'm saying we need to set new expectations for everyone and
> some human helper symlinks to help. A new top-level out or images or
> something, with symlinks inside.
Why would we need that?
For the end user, any name is good enough, as long as it's clearly
documented which file to use, and what exactly to do with it. There
are so many different boot formatrequirements, that we canot expect to
come up with "good" names for all of these in any way that matches all
people's expectations because everything is completely
self-explanatory.
Make it simple, and handle it in the documentation.
> I think we're running into PowerPC vs ARM "fun". We've got 7 or so
> different "whack the image for this SoC for this medium" type things
> already.
I don't think it's an PPC versus ARM issue It's more an "good old
times" versus "brave new world" thing. Actually Shakespeare's verses
apply fully to many of teh recent SoC designs - be these PPC or ARM or
whatever based:
O wonder!
How many goodly creatures are there here!
How beauteous mankind is! O brave new world,
That has such people in't.
?William Shakespeare, The Tempest, Act V, Scene I, ll. 203?6
Thinking about features, boot image formats, boot device selection and
other boot requirements of the ROM boot loaders of any recent SoC
indeed makes me wonder "How many goodly creatures are there here!"
PS: The "good" in this reference is to be understood in the same
sense as the "best" in the name of the MPC5200 BestComm DMA
controller.
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: wd at denx.de
"In the long run, every program becomes rococo, and then rubble."
- Alan Perlis
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 11/11] S3C24XX: Add support to MINI2416 board
2012-09-17 15:11 ` Tom Rini
@ 2012-09-18 12:11 ` José Miguel Gonçalves
0 siblings, 0 replies; 84+ messages in thread
From: José Miguel Gonçalves @ 2012-09-18 12:11 UTC (permalink / raw)
To: u-boot
Hi Tom,
On 17-09-2012 16:11, Tom Rini wrote:
> On Mon, Sep 17, 2012 at 03:47:46PM +0100, Jos? Miguel Gon?alves wrote:
>> On 17-09-2012 15:39, Tom Rini wrote:
>>> On Sun, Sep 16, 2012 at 10:11:07AM +0100, Jos? Miguel Gon?alves wrote:
>>>> On 09/14/2012 07:58 PM, Tom Rini wrote:
>>>>> On Fri, Sep 14, 2012 at 06:29:02PM +0100, Jos?? Miguel Gon??alves wrote:
>>>>>
>>>>>> The MINI2416 board is based on a Samsung's S3C2416 SoC and has 64MB DDR2 SDRAM,
>>>>>> 256MB NAND Flash, a LAN9220 Ethernet Controller and a WM8731 Audio CODEC.
>>>>>> This U-Boot port was implemented and tested on a unit bought to Boardcon
>>>>>> (http://www.armdesigner.com/) but there are some other chinese providers
>>>>>> that can supply it with a selectable NAND chip from 128MB to 1GB.
>>>>> [snip]
>>>>>
>>>>> Can you please try this on top of my SPL framework series? Thanks!
>>>> I thought I was using the latest SPL framework!
>>>> Can you please detail on what I should do different?
>>> Please see
>>> http://www.mail-archive.com/u-boot at lists.denx.de/msg92156.html
>>>
>> As this is still not merged, I reckon you only want to check if this
>> new SPL framework works fine with my board.
>>
>> I'm not expected to resubmit my patch to be according with the new framework, correct?
> v1 of your patches was posted well after the merge window for v2012.10
> closed. My SPL series will be merged to mainline shortly (taking care
> of everyone elses merge requests first). So yes, to get into v2013.01
> you will need to update. If you check the archives you can see how the
> altera soc support changed to adapt to this framework. And if there's a
> shortcoming in the framework, I really do want to know. Thanks!
>
I already have my board working on the top of this new SPL framework.
It was easy to migrate and the interface is easier to use for a new U-Boot
developer (like me). Good work!
I'll resubmit my new patch later on.
Here are my board's SPL sizes for both older and new frameworks:
text data bss dec hex filename
4083 8 588 4679 1247 u-boot/spl/u-boot-spl
text data bss dec hex filename
3905 160 500 4565 11d5 u-boot-spl-framework/spl/u-boot-spl
So I get around 30 bytes of additional IRAM space (text + data).
I have a comment, though. As you use memset() to initialize the .bss, wouldn?t be
better that CONFIG_SPL_LIBGENERIC_SUPPORT would be automaticaly included when
adding CONFIG_SPL_FRAMEWORK to the board config?
Best regards,
Jos? Gon?alves
^ permalink raw reply [flat|nested] 84+ messages in thread
* [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
2012-09-14 17:28 ` [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS José Miguel Gonçalves
2012-09-15 18:03 ` Marek Vasut
@ 2012-10-04 14:24 ` Albert ARIBAUD
1 sibling, 0 replies; 84+ messages in thread
From: Albert ARIBAUD @ 2012-10-04 14:24 UTC (permalink / raw)
To: u-boot
Hi Jos?,
On Fri, 14 Sep 2012 18:28:52 +0100, Jos? Miguel Gon?alves
<jose.goncalves@inov.pt> wrote:
> Jumping to board_init_r is not performed due to a bug on address computation.
> Relocation offsets are not needed when building SPL.
>
> Signed-off-by: Jos? Miguel Gon?alves <jose.goncalves@inov.pt>
> ---
> Changes for v2:
> - None
> ---
> arch/arm/cpu/arm926ejs/start.S | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S
> index 6f05f1a..2da5342 100644
> --- a/arch/arm/cpu/arm926ejs/start.S
> +++ b/arch/arm/cpu/arm926ejs/start.S
> @@ -325,7 +325,7 @@ _nand_boot_ofs:
> .word nand_boot
> #else
> ldr r0, _board_init_r_ofs
> - ldr r1, _TEXT_BASE
> + adr r1, _start
> add lr, r0, r1
> add lr, lr, r9
> /* setup parameters for board_init_r */
> @@ -338,12 +338,14 @@ _board_init_r_ofs:
> .word board_init_r - _start
> #endif
>
> +#ifndef CONFIG_SPL_BUILD
> _rel_dyn_start_ofs:
> .word __rel_dyn_start - _start
> _rel_dyn_end_ofs:
> .word __rel_dyn_end - _start
> _dynsym_start_ofs:
> .word __dynsym_start - _start
> +#endif
>
> /*
> *************************************************************************
Deferring decision on this one until after 2012.10.
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 84+ messages in thread
end of thread, other threads:[~2012-10-04 14:24 UTC | newest]
Thread overview: 84+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-09-14 17:28 [U-Boot] [PATCH v2 00/11] S3C24XX: Add support to MINI2416 board José Miguel Gonçalves
2012-09-14 17:28 ` [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS José Miguel Gonçalves
2012-09-15 18:03 ` Marek Vasut
2012-09-16 9:45 ` José Miguel Gonçalves
2012-09-16 10:06 ` Marek Vasut
2012-09-16 10:16 ` José Miguel Gonçalves
2012-09-16 15:36 ` Marek Vasut
2012-09-16 16:26 ` José Miguel Gonçalves
2012-09-16 17:17 ` Marek Vasut
2012-09-17 6:28 ` Christian Riesch
2012-09-17 8:34 ` José Miguel Gonçalves
2012-09-17 9:03 ` Christian Riesch
2012-09-17 9:20 ` José Miguel Gonçalves
2012-09-17 17:18 ` Tom Rini
2012-09-17 17:23 ` Scott Wood
2012-09-17 17:32 ` Tom Rini
2012-09-17 17:26 ` Marek Vasut
2012-09-17 17:35 ` Tom Rini
2012-09-17 17:48 ` Marek Vasut
2012-09-17 18:00 ` Tom Rini
2012-09-17 17:27 ` José Miguel Gonçalves
2012-10-04 14:24 ` Albert ARIBAUD
2012-09-14 17:28 ` [U-Boot] [PATCH v2 02/11] S3C24XX: Add core support for Samsung's S3C24XX SoCs José Miguel Gonçalves
2012-09-14 18:03 ` Marek Vasut
[not found] ` <505375E3.6050005@inov.pt>
2012-09-14 18:25 ` Marek Vasut
2012-09-14 19:01 ` Scott Wood
2012-09-14 19:07 ` Marek Vasut
2012-09-14 19:17 ` Scott Wood
2012-09-14 18:39 ` Tom Rini
2012-09-14 17:28 ` [U-Boot] [PATCH v2 03/11] serial: Add support to 4 ports in serial_s3c24x0 José Miguel Gonçalves
2012-09-14 17:28 ` [U-Boot] [PATCH v2 04/11] serial: Use a more precise baud rate generation for serial_s3c24x0 José Miguel Gonçalves
2012-09-14 18:05 ` Marek Vasut
2012-09-14 17:28 ` [U-Boot] [PATCH v2 05/11] serial: Remove unnecessary delay in serial_s3c24x0 José Miguel Gonçalves
2012-09-14 18:05 ` Marek Vasut
2012-09-14 17:28 ` [U-Boot] [PATCH v2 06/11] rtc: Improve rtc_get() on s3c24x0_rtc José Miguel Gonçalves
2012-09-14 18:06 ` Marek Vasut
2012-09-14 17:28 ` [U-Boot] [PATCH v2 07/11] rtc: Fix rtc_reset() " José Miguel Gonçalves
2012-09-14 18:07 ` Marek Vasut
2012-09-14 17:28 ` [U-Boot] [PATCH v2 08/11] rtc: Don't allow setting unsuported years " José Miguel Gonçalves
2012-09-14 18:08 ` Marek Vasut
2012-09-14 17:29 ` [U-Boot] [PATCH v2 09/11] S3C24XX: Add NAND Flash driver José Miguel Gonçalves
2012-09-14 18:21 ` Marek Vasut
2012-09-14 18:45 ` José Miguel Gonçalves
2012-09-14 19:01 ` Tom Rini
2012-09-16 9:16 ` José Miguel Gonçalves
2012-09-17 16:57 ` Tom Rini
2012-09-17 17:03 ` Scott Wood
2012-09-17 17:08 ` Tom Rini
2012-09-17 17:13 ` Scott Wood
2012-09-17 17:08 ` José Miguel Gonçalves
2012-09-17 17:56 ` Tom Rini
2012-09-17 18:05 ` José Miguel Gonçalves
2012-09-17 18:27 ` Tom Rini
2012-09-17 18:34 ` José Miguel Gonçalves
2012-09-17 18:56 ` Tom Rini
2012-09-14 19:24 ` Scott Wood
2012-09-14 20:20 ` Tom Rini
2012-09-14 20:29 ` Scott Wood
2012-09-17 11:11 ` José Miguel Gonçalves
2012-09-14 18:47 ` Tom Rini
2012-09-14 17:29 ` [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the Makefile José Miguel Gonçalves
2012-09-14 18:22 ` Marek Vasut
2012-09-14 19:08 ` Tom Rini
2012-09-16 9:27 ` José Miguel Gonçalves
2012-09-17 6:47 ` Christian Riesch
2012-09-17 8:30 ` José Miguel Gonçalves
2012-09-17 9:10 ` Christian Riesch
2012-09-17 9:24 ` José Miguel Gonçalves
2012-09-17 14:45 ` Tom Rini
2012-09-17 16:29 ` Marek Vasut
2012-09-17 16:35 ` Tom Rini
2012-09-17 16:27 ` Scott Wood
2012-09-17 16:51 ` Tom Rini
2012-09-17 17:32 ` Scott Wood
2012-09-17 17:53 ` Tom Rini
2012-09-17 18:16 ` Scott Wood
2012-09-17 19:52 ` Wolfgang Denk
2012-09-14 17:29 ` [U-Boot] [PATCH v2 11/11] S3C24XX: Add support to MINI2416 board José Miguel Gonçalves
2012-09-14 18:58 ` Tom Rini
2012-09-16 9:11 ` José Miguel Gonçalves
2012-09-17 14:39 ` Tom Rini
2012-09-17 14:47 ` José Miguel Gonçalves
2012-09-17 15:11 ` Tom Rini
2012-09-18 12:11 ` José Miguel Gonçalves
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.