[U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board

[U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board

[Pavel Machek]

Altera Cyclone 5 board is very different board (big, rectangular,
expensive) than EBV Socrates (small, circular, cheap) board. Different
parts are used there, too, but same configuration of u-boot works on
both. Nevertheless, printing wrong name confuses users.

Therefore this splits the configuration so that u-boot knows they are
different. So far it is only used for correcting the puts, but there
may be other uses in future.

Signed-off-by: Pavel Machek <pavel@denx.de>

diff --git a/board/altera/socfpga/socfpga_cyclone5.c b/board/altera/socfpga/socfpga_cyclone5.c
index 576066b..4540b1b 100644
--- a/board/altera/socfpga/socfpga_cyclone5.c
+++ b/board/altera/socfpga/socfpga_cyclone5.c
@@ -26,7 +26,7 @@ int print_cpuinfo(void)
  */
 int checkboard(void)
 {
-	puts("BOARD : Altera SOCFPGA Cyclone5 Board\n");
+	puts("BOARD : " ALTERA_BOARD_NAME "\n");
 	return 0;
 }
 
diff --git a/boards.cfg b/boards.cfg
index 375f2d4..20534c3 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -340,6 +340,7 @@ Active  arm         armv7          rmobile     kmc             kzm9g
 Active  arm         armv7          s5pc1xx     samsung         goni                s5p_goni                             -                                                                                                                                 Minkyu Kang <mk7.kang@samsung.com>
 Active  arm         armv7          s5pc1xx     samsung         smdkc100            smdkc100                             -                                                                                                                                 Minkyu Kang <mk7.kang@samsung.com>
 Active  arm         armv7          socfpga     altera          socfpga             socfpga_cyclone5                     -                                                                                                                                 -
+Active  arm         armv7          socfpga     altera          socfpga             socfpga_socrates                     -                                                                                                                                 -
 Active  arm         armv7          u8500       st-ericsson     snowball            snowball                             -                                                                                                                                 Mathieu Poirier <mathieu.poirier@linaro.org>
 Active  arm         armv7          u8500       st-ericsson     u8500               u8500_href                           -                                                                                                                                 -
 Active  arm         armv7          vf610       freescale       vf610twr            vf610twr                             vf610twr:IMX_CONFIG=board/freescale/vf610twr/imximage.cfg                                                                         Alison Wang <b18965@freescale.com>
diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
new file mode 100644
index 0000000..6d4dfcf
--- /dev/null
+++ b/include/configs/socfpga_common.h
@@ -0,0 +1,240 @@
+/*
+ *  Copyright (C) 2012 Altera Corporation <www.altera.com>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+#ifndef __CONFIG_COMMON_H
+#define __CONFIG_COMMON_H
+
+#include <asm/arch/socfpga_base_addrs.h>
+#include "../../board/altera/socfpga/pinmux_config.h"
+
+/*
+ * High level configuration
+ */
+/* Virtual target or real hardware */
+#define CONFIG_SOCFPGA_VIRTUAL_TARGET
+
+#define CONFIG_ARMV7
+#define CONFIG_L2_OFF
+#define CONFIG_SYS_DCACHE_OFF
+#undef CONFIG_USE_IRQ
+
+#define CONFIG_MISC_INIT_R
+#define CONFIG_SINGLE_BOOTLOADER
+#define CONFIG_SOCFPGA
+
+/* base address for .text section */
+#ifdef CONFIG_SOCFPGA_VIRTUAL_TARGET
+#define CONFIG_SYS_TEXT_BASE		0x08000040
+#else
+#define CONFIG_SYS_TEXT_BASE		0x01000040
+#endif
+#define CONFIG_SYS_LOAD_ADDR		0x7fc0
+
+/* Console I/O Buffer Size */
+#define CONFIG_SYS_CBSIZE		256
+/* Monitor Command Prompt */
+#define CONFIG_SYS_PROMPT		"SOCFPGA_CYCLONE5 # "
+#define CONFIG_SYS_PBSIZE		(CONFIG_SYS_CBSIZE + \
+					sizeof(CONFIG_SYS_PROMPT) + 16)
+
+/*
+ * Display CPU and Board Info
+ */
+#define CONFIG_DISPLAY_CPUINFO
+#define CONFIG_DISPLAY_BOARDINFO
+
+/*
+ * Enable early stage initialization at C environment
+ */
+#define CONFIG_BOARD_EARLY_INIT_F
+
+/* flat device tree */
+#define CONFIG_OF_LIBFDT
+/* skip updating the FDT blob */
+#define CONFIG_FDT_BLOB_SKIP_UPDATE
+/* Initial Memory map size for Linux, minus 4k alignment for DFT blob */
+#define CONFIG_SYS_BOOTMAPSZ		((256*1024*1024) - (4*1024))
+
+#define CONFIG_SPL_RAM_DEVICE
+#define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR
+#define CONFIG_SYS_SPL_MALLOC_START ((unsigned long) (&__malloc_start))
+#define CONFIG_SYS_SPL_MALLOC_SIZE (&__malloc_end - &__malloc_start)
+
+/*
+ * Memory allocation (MALLOC)
+ */
+/* Room required on the stack for the environment data */
+#define CONFIG_ENV_SIZE			1024
+/* Size of DRAM reserved for malloc() use */
+#define CONFIG_SYS_MALLOC_LEN		(CONFIG_ENV_SIZE + 128*1024)
+
+/* SP location before relocation, must use scratch RAM */
+#define CONFIG_SYS_INIT_RAM_ADDR	0xFFFF0000
+/* Reserving 0x100 space at back of scratch RAM for debug info */
+#define CONFIG_SYS_INIT_RAM_SIZE	(0x10000 - 0x100)
+/* Stack pointer prior relocation, must situated at on-chip RAM */
+#define CONFIG_SYS_INIT_SP_ADDR		(CONFIG_SYS_INIT_RAM_ADDR + \
+					 CONFIG_SYS_INIT_RAM_SIZE - \
+					 GENERATED_GBL_DATA_SIZE)
+
+
+/*
+ * Command line configuration.
+ */
+#define CONFIG_SYS_NO_FLASH
+#include <config_cmd_default.h>
+/* FAT file system support */
+#define CONFIG_CMD_FAT
+
+
+/*
+ * Misc
+ */
+#define CONFIG_DOS_PARTITION            1
+
+#ifdef CONFIG_SPL_BUILD
+#undef CONFIG_PARTITIONS
+#endif
+
+/*
+ * Environment setup
+ */
+
+/* Delay before automatically booting the default image */
+#define CONFIG_BOOTDELAY		3
+/* Enable auto completion of commands using TAB */
+#define CONFIG_AUTO_COMPLETE
+/* use "hush" command parser */
+#define CONFIG_SYS_HUSH_PARSER
+#define CONFIG_SYS_PROMPT_HUSH_PS2	"> "
+#define CONFIG_CMD_RUN
+
+#define CONFIG_BOOTCOMMAND "run ramboot"
+
+/*
+ * arguments passed to the bootm command. The value of
+ * CONFIG_BOOTARGS goes into the environment value "bootargs".
+ * Do note the value will overide also the chosen node in FDT blob.
+ */
+#define CONFIG_BOOTARGS "console=ttyS0,57600,mem=256M at 0x0"
+
+#define CONFIG_EXTRA_ENV_SETTINGS \
+	"verify=n\0" \
+	"loadaddr= " __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
+	"ramboot=setenv bootargs " CONFIG_BOOTARGS ";" \
+		"bootm ${loadaddr} - ${fdt_addr}\0" \
+	"bootimage=uImage\0" \
+	"fdt_addr=100\0" \
+	"fsloadcmd=ext2load\0" \
+		"bootm ${loadaddr} - ${fdt_addr}\0" \
+	"qspiroot=/dev/mtdblock0\0" \
+	"qspirootfstype=jffs2\0" \
+	"qspiboot=setenv bootargs " CONFIG_BOOTARGS \
+		" root=${qspiroot} rw rootfstype=${qspirootfstype};"\
+		"bootm ${loadaddr} - ${fdt_addr}\0"
+
+/* using environment setting for stdin, stdout, stderr */
+#define CONFIG_SYS_CONSOLE_IS_IN_ENV
+/* Enable the call to overwrite_console() */
+#define CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE
+/* Enable overwrite of previous console environment settings */
+#define CONFIG_SYS_CONSOLE_ENV_OVERWRITE
+
+/* max number of command args	 */
+#define CONFIG_SYS_MAXARGS		16
+
+
+/*
+ * Hardware drivers
+ */
+
+/*
+ * SDRAM Memory Map
+ */
+/* We have 1 bank of DRAM */
+#define CONFIG_NR_DRAM_BANKS		1
+/* SDRAM Bank #1 */
+#define CONFIG_SYS_SDRAM_BASE		0x00000000
+/* SDRAM memory size */
+#define PHYS_SDRAM_1_SIZE		0x40000000
+
+#define PHYS_SDRAM_1			CONFIG_SYS_SDRAM_BASE
+#define CONFIG_SYS_MEMTEST_START	0x00000000
+#define CONFIG_SYS_MEMTEST_END		PHYS_SDRAM_1_SIZE
+
+/*
+ * NS16550 Configuration
+ */
+#define UART0_BASE			SOCFPGA_UART0_ADDRESS
+#define CONFIG_SYS_NS16550
+#define CONFIG_SYS_NS16550_SERIAL
+#define CONFIG_SYS_NS16550_REG_SIZE	-4
+#define CONFIG_SYS_NS16550_CLK          V_NS16550_CLK
+#define CONFIG_CONS_INDEX               1
+#define CONFIG_SYS_NS16550_COM1		UART0_BASE
+#define CONFIG_SYS_BAUDRATE_TABLE {4800, 9600, 19200, 38400, 57600, 115200}
+#ifdef CONFIG_SOCFPGA_VIRTUAL_TARGET
+#define V_NS16550_CLK			1000000
+#else
+#define V_NS16550_CLK			100000000
+#endif
+#define CONFIG_BAUDRATE			115200
+
+/*
+ * FLASH
+ */
+#define CONFIG_SYS_NO_FLASH
+
+/*
+ * L4 OSC1 Timer 0
+ */
+/* This timer use eosc1 where the clock frequency is fixed
+ * throughout any condition */
+#define CONFIG_SYS_TIMERBASE		SOCFPGA_OSC1TIMER0_ADDRESS
+/* reload value when timer count to zero */
+#define TIMER_LOAD_VAL			0xFFFFFFFF
+/* Timer info */
+#ifdef CONFIG_SOCFPGA_VIRTUAL_TARGET
+#define CONFIG_SYS_TIMER_RATE		2400000
+#else
+#define CONFIG_SYS_TIMER_RATE		25000000
+#endif
+#define CONFIG_SYS_TIMER_COUNTER	(CONFIG_SYS_TIMERBASE + 0x4)
+
+#define CONFIG_ENV_IS_NOWHERE
+
+/*
+ * SPL "Second Program Loader" aka Initial Software
+ */
+
+/* Enable building of SPL globally */
+#define CONFIG_SPL
+#define CONFIG_SPL_FRAMEWORK
+
+/* TEXT_BASE for linking the SPL binary */
+#define CONFIG_SPL_TEXT_BASE		0xFFFF0000
+
+/* Stack size for SPL */
+#define CONFIG_SPL_STACK_SIZE		(4 * 1024)
+
+/* MALLOC size for SPL */
+#define CONFIG_SPL_MALLOC_SIZE		(5 * 1024)
+
+#define CONFIG_SPL_SERIAL_SUPPORT
+#define CONFIG_SPL_BOARD_INIT
+
+#define CHUNKSZ_CRC32			(1 * 1024)
+
+#define CONFIG_CRC32_VERIFY
+
+/* Linker script for SPL */
+#define CONFIG_SPL_LDSCRIPT "arch/arm/cpu/armv7/socfpga/u-boot-spl.lds"
+
+/* Support for common/libcommon.o in SPL binary */
+#define CONFIG_SPL_LIBCOMMON_SUPPORT
+/* Support for lib/libgeneric.o in SPL binary */
+#define CONFIG_SPL_LIBGENERIC_SUPPORT
+
+#endif	/* __CONFIG_COMMON_H */
diff --git a/include/configs/socfpga_cyclone5.h b/include/configs/socfpga_cyclone5.h
index 980636c..87de4d2 100644
--- a/include/configs/socfpga_cyclone5.h
+++ b/include/configs/socfpga_cyclone5.h
@@ -6,235 +6,12 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-#include <asm/arch/socfpga_base_addrs.h>
-#include "../../board/altera/socfpga/pinmux_config.h"
+#include <configs/socfpga_common.h>
 
-/*
- * High level configuration
- */
-/* Virtual target or real hardware */
-#define CONFIG_SOCFPGA_VIRTUAL_TARGET
-
-#define CONFIG_ARMV7
-#define CONFIG_L2_OFF
-#define CONFIG_SYS_DCACHE_OFF
-#undef CONFIG_USE_IRQ
-
-#define CONFIG_MISC_INIT_R
-#define CONFIG_SINGLE_BOOTLOADER
-#define CONFIG_SOCFPGA
-
-/* base address for .text section */
 #ifdef CONFIG_SOCFPGA_VIRTUAL_TARGET
-#define CONFIG_SYS_TEXT_BASE		0x08000040
+#define ALTERA_BOARD_NAME "Altera VTDEV5XS1 Virtual Board"
 #else
-#define CONFIG_SYS_TEXT_BASE		0x01000040
-#endif
-#define CONFIG_SYS_LOAD_ADDR		0x7fc0
-
-/* Console I/O Buffer Size */
-#define CONFIG_SYS_CBSIZE		256
-/* Monitor Command Prompt */
-#define CONFIG_SYS_PROMPT		"SOCFPGA_CYCLONE5 # "
-#define CONFIG_SYS_PBSIZE		(CONFIG_SYS_CBSIZE + \
-					sizeof(CONFIG_SYS_PROMPT) + 16)
-
-/*
- * Display CPU and Board Info
- */
-#define CONFIG_DISPLAY_CPUINFO
-#define CONFIG_DISPLAY_BOARDINFO
-
-/*
- * Enable early stage initialization at C environment
- */
-#define CONFIG_BOARD_EARLY_INIT_F
-
-/* flat device tree */
-#define CONFIG_OF_LIBFDT
-/* skip updating the FDT blob */
-#define CONFIG_FDT_BLOB_SKIP_UPDATE
-/* Initial Memory map size for Linux, minus 4k alignment for DFT blob */
-#define CONFIG_SYS_BOOTMAPSZ		((256*1024*1024) - (4*1024))
-
-#define CONFIG_SPL_RAM_DEVICE
-#define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR
-#define CONFIG_SYS_SPL_MALLOC_START ((unsigned long) (&__malloc_start))
-#define CONFIG_SYS_SPL_MALLOC_SIZE (&__malloc_end - &__malloc_start)
-
-/*
- * Memory allocation (MALLOC)
- */
-/* Room required on the stack for the environment data */
-#define CONFIG_ENV_SIZE			1024
-/* Size of DRAM reserved for malloc() use */
-#define CONFIG_SYS_MALLOC_LEN		(CONFIG_ENV_SIZE + 128*1024)
-
-/* SP location before relocation, must use scratch RAM */
-#define CONFIG_SYS_INIT_RAM_ADDR	0xFFFF0000
-/* Reserving 0x100 space at back of scratch RAM for debug info */
-#define CONFIG_SYS_INIT_RAM_SIZE	(0x10000 - 0x100)
-/* Stack pointer prior relocation, must situated at on-chip RAM */
-#define CONFIG_SYS_INIT_SP_ADDR		(CONFIG_SYS_INIT_RAM_ADDR + \
-					 CONFIG_SYS_INIT_RAM_SIZE - \
-					 GENERATED_GBL_DATA_SIZE)
-
-
-/*
- * Command line configuration.
- */
-#define CONFIG_SYS_NO_FLASH
-#include <config_cmd_default.h>
-/* FAT file system support */
-#define CONFIG_CMD_FAT
-
-
-/*
- * Misc
- */
-#define CONFIG_DOS_PARTITION            1
-
-#ifdef CONFIG_SPL_BUILD
-#undef CONFIG_PARTITIONS
+#define ALTERA_BOARD_NAME "Altera SOCFPGA Cyclone 5 Board"
 #endif
 
-/*
- * Environment setup
- */
-
-/* Delay before automatically booting the default image */
-#define CONFIG_BOOTDELAY		3
-/* Enable auto completion of commands using TAB */
-#define CONFIG_AUTO_COMPLETE
-/* use "hush" command parser */
-#define CONFIG_SYS_HUSH_PARSER
-#define CONFIG_SYS_PROMPT_HUSH_PS2	"> "
-#define CONFIG_CMD_RUN
-
-#define CONFIG_BOOTCOMMAND "run ramboot"
-
-/*
- * arguments passed to the bootm command. The value of
- * CONFIG_BOOTARGS goes into the environment value "bootargs".
- * Do note the value will overide also the chosen node in FDT blob.
- */
-#define CONFIG_BOOTARGS "console=ttyS0,57600,mem=256M at 0x0"
-
-#define CONFIG_EXTRA_ENV_SETTINGS \
-	"verify=n\0" \
-	"loadaddr= " __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
-	"ramboot=setenv bootargs " CONFIG_BOOTARGS ";" \
-		"bootm ${loadaddr} - ${fdt_addr}\0" \
-	"bootimage=uImage\0" \
-	"fdt_addr=100\0" \
-	"fsloadcmd=ext2load\0" \
-		"bootm ${loadaddr} - ${fdt_addr}\0" \
-	"qspiroot=/dev/mtdblock0\0" \
-	"qspirootfstype=jffs2\0" \
-	"qspiboot=setenv bootargs " CONFIG_BOOTARGS \
-		" root=${qspiroot} rw rootfstype=${qspirootfstype};"\
-		"bootm ${loadaddr} - ${fdt_addr}\0"
-
-/* using environment setting for stdin, stdout, stderr */
-#define CONFIG_SYS_CONSOLE_IS_IN_ENV
-/* Enable the call to overwrite_console() */
-#define CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE
-/* Enable overwrite of previous console environment settings */
-#define CONFIG_SYS_CONSOLE_ENV_OVERWRITE
-
-/* max number of command args	 */
-#define CONFIG_SYS_MAXARGS		16
-
-
-/*
- * Hardware drivers
- */
-
-/*
- * SDRAM Memory Map
- */
-/* We have 1 bank of DRAM */
-#define CONFIG_NR_DRAM_BANKS		1
-/* SDRAM Bank #1 */
-#define CONFIG_SYS_SDRAM_BASE		0x00000000
-/* SDRAM memory size */
-#define PHYS_SDRAM_1_SIZE		0x40000000
-
-#define PHYS_SDRAM_1			CONFIG_SYS_SDRAM_BASE
-#define CONFIG_SYS_MEMTEST_START	0x00000000
-#define CONFIG_SYS_MEMTEST_END		PHYS_SDRAM_1_SIZE
-
-/*
- * NS16550 Configuration
- */
-#define UART0_BASE			SOCFPGA_UART0_ADDRESS
-#define CONFIG_SYS_NS16550
-#define CONFIG_SYS_NS16550_SERIAL
-#define CONFIG_SYS_NS16550_REG_SIZE	-4
-#define CONFIG_SYS_NS16550_CLK          V_NS16550_CLK
-#define CONFIG_CONS_INDEX               1
-#define CONFIG_SYS_NS16550_COM1		UART0_BASE
-#define CONFIG_SYS_BAUDRATE_TABLE {4800, 9600, 19200, 38400, 57600, 115200}
-#ifdef CONFIG_SOCFPGA_VIRTUAL_TARGET
-#define V_NS16550_CLK			1000000
-#else
-#define V_NS16550_CLK			100000000
-#endif
-#define CONFIG_BAUDRATE			115200
-
-/*
- * FLASH
- */
-#define CONFIG_SYS_NO_FLASH
-
-/*
- * L4 OSC1 Timer 0
- */
-/* This timer use eosc1 where the clock frequency is fixed
- * throughout any condition */
-#define CONFIG_SYS_TIMERBASE		SOCFPGA_OSC1TIMER0_ADDRESS
-/* reload value when timer count to zero */
-#define TIMER_LOAD_VAL			0xFFFFFFFF
-/* Timer info */
-#ifdef CONFIG_SOCFPGA_VIRTUAL_TARGET
-#define CONFIG_SYS_TIMER_RATE		2400000
-#else
-#define CONFIG_SYS_TIMER_RATE		25000000
-#endif
-#define CONFIG_SYS_TIMER_COUNTER	(CONFIG_SYS_TIMERBASE + 0x4)
-
-#define CONFIG_ENV_IS_NOWHERE
-
-/*
- * SPL "Second Program Loader" aka Initial Software
- */
-
-/* Enable building of SPL globally */
-#define CONFIG_SPL
-#define CONFIG_SPL_FRAMEWORK
-
-/* TEXT_BASE for linking the SPL binary */
-#define CONFIG_SPL_TEXT_BASE		0xFFFF0000
-
-/* Stack size for SPL */
-#define CONFIG_SPL_STACK_SIZE		(4 * 1024)
-
-/* MALLOC size for SPL */
-#define CONFIG_SPL_MALLOC_SIZE		(5 * 1024)
-
-#define CONFIG_SPL_SERIAL_SUPPORT
-#define CONFIG_SPL_BOARD_INIT
-
-#define CHUNKSZ_CRC32			(1 * 1024)
-
-#define CONFIG_CRC32_VERIFY
-
-/* Linker script for SPL */
-#define CONFIG_SPL_LDSCRIPT "arch/arm/cpu/armv7/socfpga/u-boot-spl.lds"
-
-/* Support for common/libcommon.o in SPL binary */
-#define CONFIG_SPL_LIBCOMMON_SUPPORT
-/* Support for lib/libgeneric.o in SPL binary */
-#define CONFIG_SPL_LIBGENERIC_SUPPORT
-
 #endif	/* __CONFIG_H */
diff --git a/include/configs/socfpga_socrates.h b/include/configs/socfpga_socrates.h
new file mode 100644
index 0000000..2f1c3a4
--- /dev/null
+++ b/include/configs/socfpga_socrates.h
@@ -0,0 +1,13 @@
+/*
+ *  Copyright (C) 2012 Altera Corporation <www.altera.com>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+#include <configs/socfpga_common.h>
+
+#define ALTERA_BOARD_NAME "EBV SoCrates - Cyclone V SoC FPGA Board"
+
+#endif	/* __CONFIG_H */

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board

[Chin Liang See]

Hi Pavel,

On Mon, 2013-11-11 at 20:26 +0100, ZY - pavel wrote:
> Altera Cyclone 5 board is very different board (big, rectangular,
> expensive) than EBV Socrates (small, circular, cheap) board. Different
> parts are used there, too, but same configuration of u-boot works on
> both. Nevertheless, printing wrong name confuses users.
> 
> Therefore this splits the configuration so that u-boot knows they are
> different. So far it is only used for correcting the puts, but there
> may be other uses in future.
> 
> Signed-off-by: Pavel Machek <pavel@denx.de>
> 

Looks good to me. 
Reviewed-by: Chin Liang See <clsee@altera.com>

In fact, we already make this change at our git at
http://rocketboards.org/gitweb/?p=u-boot-socfpga.git;a=shortlog;h=refs/heads/socfpga_v2013.01.01. Hopefully I can continue to upstream few new patches in coming days. Thanks

Chin Liang

[U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board

[Tom Rini]

On Mon, Nov 11, 2013 at 08:26:02PM +0100, Pavel Machek wrote:

> Altera Cyclone 5 board is very different board (big, rectangular,
> expensive) than EBV Socrates (small, circular, cheap) board. Different
> parts are used there, too, but same configuration of u-boot works on
> both. Nevertheless, printing wrong name confuses users.
> 
> Therefore this splits the configuration so that u-boot knows they are
> different. So far it is only used for correcting the puts, but there
> may be other uses in future.
> 
> Signed-off-by: Pavel Machek <pavel@denx.de>

Is there any way at run time to tell which board we are on?

-- 
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/20131111/cf516238/attachment.pgp>

[U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board

[Michal Simek]

On 11/11/2013 09:33 PM, Tom Rini wrote:
> On Mon, Nov 11, 2013 at 08:26:02PM +0100, Pavel Machek wrote:
> 
>> Altera Cyclone 5 board is very different board (big, rectangular,
>> expensive) than EBV Socrates (small, circular, cheap) board. Different
>> parts are used there, too, but same configuration of u-boot works on
>> both. Nevertheless, printing wrong name confuses users.
>>
>> Therefore this splits the configuration so that u-boot knows they are
>> different. So far it is only used for correcting the puts, but there
>> may be other uses in future.
>>
>> Signed-off-by: Pavel Machek <pavel@denx.de>
> 
> Is there any way at run time to tell which board we are on?

Why do you care about board name in general?
Just write that it is socfpga and that's it.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131112/d9973edb/attachment.pgp>

[U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board

[Detlev Zundel]

Hi Tom,

> On Mon, Nov 11, 2013 at 08:26:02PM +0100, Pavel Machek wrote:
>
>> Altera Cyclone 5 board is very different board (big, rectangular,
>> expensive) than EBV Socrates (small, circular, cheap) board. Different
>> parts are used there, too, but same configuration of u-boot works on
>> both. Nevertheless, printing wrong name confuses users.
>> 
>> Therefore this splits the configuration so that u-boot knows they are
>> different. So far it is only used for correcting the puts, but there
>> may be other uses in future.
>> 
>> Signed-off-by: Pavel Machek <pavel@denx.de>
>
> Is there any way at run time to tell which board we are on?

I'll try to find out, but currently I don't know of any way.

Best wishes
  Detlev

-- 
Man gelangt nicht dazu, gluecklich zu sein, aber man macht Feststellungen
ueber die Gruende, die uns daran hindern es zu sein.
                                                -- Marcel Proust
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board

[Detlev Zundel]

Hi Michal,

> On 11/11/2013 09:33 PM, Tom Rini wrote:
>> On Mon, Nov 11, 2013 at 08:26:02PM +0100, Pavel Machek wrote:
>> 
>>> Altera Cyclone 5 board is very different board (big, rectangular,
>>> expensive) than EBV Socrates (small, circular, cheap) board. Different
>>> parts are used there, too, but same configuration of u-boot works on
>>> both. Nevertheless, printing wrong name confuses users.
>>>
>>> Therefore this splits the configuration so that u-boot knows they are
>>> different. So far it is only used for correcting the puts, but there
>>> may be other uses in future.
>>>
>>> Signed-off-by: Pavel Machek <pavel@denx.de>
>> 
>> Is there any way at run time to tell which board we are on?
>
> Why do you care about board name in general?

We care for board names for a very long time in U-Boot and I'd like to
keep this.  I actually expect a sensible board name on any platform that
I touch.  The board name is an important extra information additional to
the SoC name.  So the question is the other way round - since when do we
_not_ care about board names?

Cheers
  Detlev

-- 
A language that doesn't affect the way you think about programming, is
not worth knowing.             -- Alan Perlis, Epigrams on Programming
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board

[Michal Simek]

On 11/12/2013 10:56 AM, Detlev Zundel wrote:
> Hi Michal,
> 
>> On 11/11/2013 09:33 PM, Tom Rini wrote:
>>> On Mon, Nov 11, 2013 at 08:26:02PM +0100, Pavel Machek wrote:
>>>
>>>> Altera Cyclone 5 board is very different board (big, rectangular,
>>>> expensive) than EBV Socrates (small, circular, cheap) board. Different
>>>> parts are used there, too, but same configuration of u-boot works on
>>>> both. Nevertheless, printing wrong name confuses users.
>>>>
>>>> Therefore this splits the configuration so that u-boot knows they are
>>>> different. So far it is only used for correcting the puts, but there
>>>> may be other uses in future.
>>>>
>>>> Signed-off-by: Pavel Machek <pavel@denx.de>
>>>
>>> Is there any way at run time to tell which board we are on?
>>
>> Why do you care about board name in general?
> 
> We care for board names for a very long time in U-Boot and I'd like to
> keep this.  I actually expect a sensible board name on any platform that
> I touch.  The board name is an important extra information additional to
> the SoC name.  So the question is the other way round - since when do we
> _not_ care about board names?

There could be i2c memory on board where you can find out this information but that's
problematic if it is empty or you want to use this i2c for something else.
For all microblaze boards I use XILINX_BOARD_NAME which reflects hw design
(if user is smart enough board name is the part of hw design name).
For zynq/socfpga sensible solution is probably to load this name for DTS.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131112/52bc615b/attachment.pgp>

[U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board

[Chin Liang See]

Hi all,

On Tue, 2013-11-12 at 11:17 +0100, Michal Simek wrote:
> On 11/12/2013 10:56 AM, Detlev Zundel wrote:
> > Hi Michal,
> > 
> >> On 11/11/2013 09:33 PM, Tom Rini wrote:
> >>> On Mon, Nov 11, 2013 at 08:26:02PM +0100, Pavel Machek wrote:
> >>>
> >>>> Altera Cyclone 5 board is very different board (big, rectangular,
> >>>> expensive) than EBV Socrates (small, circular, cheap) board. Different
> >>>> parts are used there, too, but same configuration of u-boot works on
> >>>> both. Nevertheless, printing wrong name confuses users.
> >>>>
> >>>> Therefore this splits the configuration so that u-boot knows they are
> >>>> different. So far it is only used for correcting the puts, but there
> >>>> may be other uses in future.
> >>>>
> >>>> Signed-off-by: Pavel Machek <pavel@denx.de>
> >>>
> >>> Is there any way at run time to tell which board we are on?
> >>
> >> Why do you care about board name in general?
> > 
> > We care for board names for a very long time in U-Boot and I'd like to
> > keep this.  I actually expect a sensible board name on any platform that
> > I touch.  The board name is an important extra information additional to
> > the SoC name.  So the question is the other way round - since when do we
> > _not_ care about board names?
> 
> There could be i2c memory on board where you can find out this information but that's
> problematic if it is empty or you want to use this i2c for something else.
> For all microblaze boards I use XILINX_BOARD_NAME which reflects hw design
> (if user is smart enough board name is the part of hw design name).
> For zynq/socfpga sensible solution is probably to load this name for DTS.
> 

Currently, the SOCFPGA SPL is customized through a set of handoff files
which located at board folders. These handoff files are generated by
tools based on board and user design in FPGA. With that, not much
decision being made during run time based on the board. With this
handoff and tools approach, it will shield off the complexity of
hardware configuration and errors (if user change it manually without
tools help). Thanks

Chin Liang



> Thanks,
> Michal
> 

[U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board

[Michal Simek]

On 11/12/2013 03:46 PM, Chin Liang See wrote:
> Hi all,
> 
> On Tue, 2013-11-12 at 11:17 +0100, Michal Simek wrote:
>> On 11/12/2013 10:56 AM, Detlev Zundel wrote:
>>> Hi Michal,
>>>
>>>> On 11/11/2013 09:33 PM, Tom Rini wrote:
>>>>> On Mon, Nov 11, 2013 at 08:26:02PM +0100, Pavel Machek wrote:
>>>>>
>>>>>> Altera Cyclone 5 board is very different board (big, rectangular,
>>>>>> expensive) than EBV Socrates (small, circular, cheap) board. Different
>>>>>> parts are used there, too, but same configuration of u-boot works on
>>>>>> both. Nevertheless, printing wrong name confuses users.
>>>>>>
>>>>>> Therefore this splits the configuration so that u-boot knows they are
>>>>>> different. So far it is only used for correcting the puts, but there
>>>>>> may be other uses in future.
>>>>>>
>>>>>> Signed-off-by: Pavel Machek <pavel@denx.de>
>>>>>
>>>>> Is there any way at run time to tell which board we are on?
>>>>
>>>> Why do you care about board name in general?
>>>
>>> We care for board names for a very long time in U-Boot and I'd like to
>>> keep this.  I actually expect a sensible board name on any platform that
>>> I touch.  The board name is an important extra information additional to
>>> the SoC name.  So the question is the other way round - since when do we
>>> _not_ care about board names?
>>
>> There could be i2c memory on board where you can find out this information but that's
>> problematic if it is empty or you want to use this i2c for something else.
>> For all microblaze boards I use XILINX_BOARD_NAME which reflects hw design
>> (if user is smart enough board name is the part of hw design name).
>> For zynq/socfpga sensible solution is probably to load this name for DTS.
>>
> 
> Currently, the SOCFPGA SPL is customized through a set of handoff files
> which located at board folders. These handoff files are generated by
> tools based on board and user design in FPGA. With that, not much
> decision being made during run time based on the board. With this
> handoff and tools approach, it will shield off the complexity of
> hardware configuration and errors (if user change it manually without
> tools help). Thanks

Which nice copy of our approach. :-)
But anyway I believe that you are also generating one macro which define
name of this configuration based on hw design/board you are using.
And then you can use this macro for showing board/design name in u-boot.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131112/d533c8bd/attachment.pgp>

[U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board

[Tom Rini]

On Tue, Nov 12, 2013 at 10:56:29AM +0100, Detlev Zundel wrote:
> Hi Michal,
> 
> > On 11/11/2013 09:33 PM, Tom Rini wrote:
> >> On Mon, Nov 11, 2013 at 08:26:02PM +0100, Pavel Machek wrote:
> >> 
> >>> Altera Cyclone 5 board is very different board (big, rectangular,
> >>> expensive) than EBV Socrates (small, circular, cheap) board. Different
> >>> parts are used there, too, but same configuration of u-boot works on
> >>> both. Nevertheless, printing wrong name confuses users.
> >>>
> >>> Therefore this splits the configuration so that u-boot knows they are
> >>> different. So far it is only used for correcting the puts, but there
> >>> may be other uses in future.
> >>>
> >>> Signed-off-by: Pavel Machek <pavel@denx.de>
> >> 
> >> Is there any way at run time to tell which board we are on?
> >
> > Why do you care about board name in general?
> 
> We care for board names for a very long time in U-Boot and I'd like to
> keep this.  I actually expect a sensible board name on any platform that
> I touch.  The board name is an important extra information additional to
> the SoC name.  So the question is the other way round - since when do we
> _not_ care about board names?

We have a few different and somewhat conflicting concerns right now, and
this particular platform is an example of a few of them:
1) It's not only possible, but desirable (seemingly, in this case) to
support N boards with a single binary.  The space-cost is outweighed by
the usability-gain.  We're seeing this in Freescale and TI parts, and I
bet if I looked a tiny bit harder, other vendors too.
2) We want to know what particular board we're on, and perhaps even as
part of deployment build something more trimmed down to just what we're
running on.

-- 
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/20131112/8346c9d3/attachment.pgp>

[U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board

[Dinh Nguyen]

On Tue, Nov 12, 2013 at 9:17 AM, Michal Simek <monstr@monstr.eu> wrote:

> On 11/12/2013 03:46 PM, Chin Liang See wrote:
> > Hi all,
> >
> > On Tue, 2013-11-12 at 11:17 +0100, Michal Simek wrote:
> >> On 11/12/2013 10:56 AM, Detlev Zundel wrote:
> >>> Hi Michal,
> >>>
> >>>> On 11/11/2013 09:33 PM, Tom Rini wrote:
> >>>>> On Mon, Nov 11, 2013 at 08:26:02PM +0100, Pavel Machek wrote:
> >>>>>
> >>>>>> Altera Cyclone 5 board is very different board (big, rectangular,
> >>>>>> expensive) than EBV Socrates (small, circular, cheap) board.
> Different
> >>>>>> parts are used there, too, but same configuration of u-boot works on
> >>>>>> both. Nevertheless, printing wrong name confuses users.
> >>>>>>
> >>>>>> Therefore this splits the configuration so that u-boot knows they
> are
> >>>>>> different. So far it is only used for correcting the puts, but there
> >>>>>> may be other uses in future.
> >>>>>>
> >>>>>> Signed-off-by: Pavel Machek <pavel@denx.de>
> >>>>>
> >>>>> Is there any way at run time to tell which board we are on?
> >>>>
> >>>> Why do you care about board name in general?
> >>>
> >>> We care for board names for a very long time in U-Boot and I'd like to
> >>> keep this.  I actually expect a sensible board name on any platform
> that
> >>> I touch.  The board name is an important extra information additional
> to
> >>> the SoC name.  So the question is the other way round - since when do
> we
> >>> _not_ care about board names?
> >>
> >> There could be i2c memory on board where you can find out this
> information but that's
> >> problematic if it is empty or you want to use this i2c for something
> else.
> >> For all microblaze boards I use XILINX_BOARD_NAME which reflects hw
> design
> >> (if user is smart enough board name is the part of hw design name).
> >> For zynq/socfpga sensible solution is probably to load this name for
> DTS.
> >>
> >
> > Currently, the SOCFPGA SPL is customized through a set of handoff files
> > which located at board folders. These handoff files are generated by
> > tools based on board and user design in FPGA. With that, not much
> > decision being made during run time based on the board. With this
> > handoff and tools approach, it will shield off the complexity of
> > hardware configuration and errors (if user change it manually without
> > tools help). Thanks
>
> Which nice copy of our approach. :-)
>

Ugh...that came from you guys? I can't  stand that approach. Coming from
the i.MX world, this
makes the end user so reliant on proprietary tools.

Dinh


> But anyway I believe that you are also generating one macro which define
> name of this configuration based on hw design/board you are using.
> And then you can use this macro for showing board/design name in u-boot.
>
> Thanks,
> Michal
>
> --
> Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
> w: www.monstr.eu p: +42-0-721842854
> Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
> Maintainer of Linux kernel - Xilinx Zynq ARM architecture
> Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
>
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>

[U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board

[Chin Liang See]

On Tue, 2013-11-12 at 16:17 +0100, Michal Simek wrote:
> On 11/12/2013 03:46 PM, Chin Liang See wrote:
> > Hi all,
> > 
> > On Tue, 2013-11-12 at 11:17 +0100, Michal Simek wrote:
> >> On 11/12/2013 10:56 AM, Detlev Zundel wrote:
> >>> Hi Michal,
> >>>
> >>>> On 11/11/2013 09:33 PM, Tom Rini wrote:
> >>>>> On Mon, Nov 11, 2013 at 08:26:02PM +0100, Pavel Machek wrote:
> >>>>>
> >>>>>> Altera Cyclone 5 board is very different board (big, rectangular,
> >>>>>> expensive) than EBV Socrates (small, circular, cheap) board. Different
> >>>>>> parts are used there, too, but same configuration of u-boot works on
> >>>>>> both. Nevertheless, printing wrong name confuses users.
> >>>>>>
> >>>>>> Therefore this splits the configuration so that u-boot knows they are
> >>>>>> different. So far it is only used for correcting the puts, but there
> >>>>>> may be other uses in future.
> >>>>>>
> >>>>>> Signed-off-by: Pavel Machek <pavel@denx.de>
> >>>>>
> >>>>> Is there any way at run time to tell which board we are on?
> >>>>
> >>>> Why do you care about board name in general?
> >>>
> >>> We care for board names for a very long time in U-Boot and I'd like to
> >>> keep this.  I actually expect a sensible board name on any platform that
> >>> I touch.  The board name is an important extra information additional to
> >>> the SoC name.  So the question is the other way round - since when do we
> >>> _not_ care about board names?
> >>
> >> There could be i2c memory on board where you can find out this information but that's
> >> problematic if it is empty or you want to use this i2c for something else.
> >> For all microblaze boards I use XILINX_BOARD_NAME which reflects hw design
> >> (if user is smart enough board name is the part of hw design name).
> >> For zynq/socfpga sensible solution is probably to load this name for DTS.
> >>
> > 
> > Currently, the SOCFPGA SPL is customized through a set of handoff files
> > which located at board folders. These handoff files are generated by
> > tools based on board and user design in FPGA. With that, not much
> > decision being made during run time based on the board. With this
> > handoff and tools approach, it will shield off the complexity of
> > hardware configuration and errors (if user change it manually without
> > tools help). Thanks
> 
> Which nice copy of our approach. :-)

Hmmm... is it true? This approach being used since few years back at
NIOS soft processor. Besides that, we are utilizing the SPL framework
for our second stage boot loader. I believe you guys are not using SPL
right? It seems you guys would need tools to generate and even build you
guys own version of boot loader. It creates high dependency for user to
your tools. 

For our solution, customer can just grab the code from git and build it
using the normal U-Boot way (if they don't want to use the tools). With
the SPL also, we are taking advantage of open source community power to
make our second stage boot loader more powerful and user friendly to
user. Our user can grab any drivers or leverage the supports from the
open community too. I believe that is the power of open source :) 

Chin Liang


> But anyway I believe that you are also generating one macro which define
> name of this configuration based on hw design/board you are using.
> And then you can use this macro for showing board/design name in u-boot.
> 
> Thanks,
> Michal
> 

[U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board

[Michal Simek]

On 11/13/2013 03:39 PM, Chin Liang See wrote:
> On Tue, 2013-11-12 at 16:17 +0100, Michal Simek wrote:
>> On 11/12/2013 03:46 PM, Chin Liang See wrote:
>>> Hi all,
>>>
>>> On Tue, 2013-11-12 at 11:17 +0100, Michal Simek wrote:
>>>> On 11/12/2013 10:56 AM, Detlev Zundel wrote:
>>>>> Hi Michal,
>>>>>
>>>>>> On 11/11/2013 09:33 PM, Tom Rini wrote:
>>>>>>> On Mon, Nov 11, 2013 at 08:26:02PM +0100, Pavel Machek wrote:
>>>>>>>
>>>>>>>> Altera Cyclone 5 board is very different board (big, rectangular,
>>>>>>>> expensive) than EBV Socrates (small, circular, cheap) board. Different
>>>>>>>> parts are used there, too, but same configuration of u-boot works on
>>>>>>>> both. Nevertheless, printing wrong name confuses users.
>>>>>>>>
>>>>>>>> Therefore this splits the configuration so that u-boot knows they are
>>>>>>>> different. So far it is only used for correcting the puts, but there
>>>>>>>> may be other uses in future.
>>>>>>>>
>>>>>>>> Signed-off-by: Pavel Machek <pavel@denx.de>
>>>>>>>
>>>>>>> Is there any way at run time to tell which board we are on?
>>>>>>
>>>>>> Why do you care about board name in general?
>>>>>
>>>>> We care for board names for a very long time in U-Boot and I'd like to
>>>>> keep this.  I actually expect a sensible board name on any platform that
>>>>> I touch.  The board name is an important extra information additional to
>>>>> the SoC name.  So the question is the other way round - since when do we
>>>>> _not_ care about board names?
>>>>
>>>> There could be i2c memory on board where you can find out this information but that's
>>>> problematic if it is empty or you want to use this i2c for something else.
>>>> For all microblaze boards I use XILINX_BOARD_NAME which reflects hw design
>>>> (if user is smart enough board name is the part of hw design name).
>>>> For zynq/socfpga sensible solution is probably to load this name for DTS.
>>>>
>>>
>>> Currently, the SOCFPGA SPL is customized through a set of handoff files
>>> which located at board folders. These handoff files are generated by
>>> tools based on board and user design in FPGA. With that, not much
>>> decision being made during run time based on the board. With this
>>> handoff and tools approach, it will shield off the complexity of
>>> hardware configuration and errors (if user change it manually without
>>> tools help). Thanks
>>
>> Which nice copy of our approach. :-)
> 
> Hmmm... is it true? This approach being used since few years back at
> NIOS soft processor. Besides that, we are utilizing the SPL framework
> for our second stage boot loader. I believe you guys are not using SPL
> right? It seems you guys would need tools to generate and even build you
> guys own version of boot loader. It creates high dependency for user to
> your tools. 

Interesting discussion. :-)
I believe we will use SPL at some point in future for Microblaze
just because of easier maintenance . But will see.

I don't understand your point regarding to tool dependency. For DTSes
I believe you are also generating this structure from design tools
or you can write it by hand.
We are also generating U-boot configuration but if someone wants to write
it by hand they can.

> For our solution, customer can just grab the code from git and build it
> using the normal U-Boot way (if they don't want to use the tools). With
> the SPL also, we are taking advantage of open source community power to
> make our second stage boot loader more powerful and user friendly to
> user. Our user can grab any drivers or leverage the supports from the
> open community too. I believe that is the power of open source :) 

We have the same for Microblaze and Zynq.

Cheers,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131113/315f0a8f/attachment.pgp>

[U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board

[Chin Liang See]

Hi,

> >>>>
> >>>
> >>> Currently, the SOCFPGA SPL is customized through a set of handoff files
> >>> which located at board folders. These handoff files are generated by
> >>> tools based on board and user design in FPGA. With that, not much
> >>> decision being made during run time based on the board. With this
> >>> handoff and tools approach, it will shield off the complexity of
> >>> hardware configuration and errors (if user change it manually without
> >>> tools help). Thanks
> >>
> >> Which nice copy of our approach. :-)
> > 
> > Hmmm... is it true? This approach being used since few years back at
> > NIOS soft processor. Besides that, we are utilizing the SPL framework
> > for our second stage boot loader. I believe you guys are not using SPL
> > right? It seems you guys would need tools to generate and even build you
> > guys own version of boot loader. It creates high dependency for user to
> > your tools. 
> 
> Interesting discussion. :-)
> I believe we will use SPL at some point in future for Microblaze
> just because of easier maintenance . But will see.

Yup, utilizing SPL will gain you the power of open source :)

> 
> I don't understand your point regarding to tool dependency. For DTSes
> I believe you are also generating this structure from design tools
> or you can write it by hand.
> We are also generating U-boot configuration but if someone wants to write
> it by hand they can.

I believe we have misalignment on the term used. For us, second stage
bootloader is referring to the bootloader loaded by BootROM. I believe
you guys are referring that as FSBL. 

> > For our solution, customer can just grab the code from git and build it
> > using the normal U-Boot way (if they don't want to use the tools). With
> > the SPL also, we are taking advantage of open source community power to
> > make our second stage boot loader more powerful and user friendly to
> > user. Our user can grab any drivers or leverage the supports from the
> > open community too. I believe that is the power of open source :) 
> 
> We have the same for Microblaze and Zynq.

Same as above, I believe both of us are using U-Boot. But for bootloader
before U-Boot, we are using SPL while you guys using FSBL which is not
SPL framework, right? With that, I believe you guys would need a
proprietary tools to compile and build the FSBL. We would not have this
dependency when building the SPL code.

Thanks
Chin Liang

> 
> Cheers,
> Michal
> 

[U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board

[Michal Simek]

On 11/13/2013 06:57 PM, Chin Liang See wrote:
> Hi,
> 
>>>>>>
>>>>>
>>>>> Currently, the SOCFPGA SPL is customized through a set of handoff files
>>>>> which located at board folders. These handoff files are generated by
>>>>> tools based on board and user design in FPGA. With that, not much
>>>>> decision being made during run time based on the board. With this
>>>>> handoff and tools approach, it will shield off the complexity of
>>>>> hardware configuration and errors (if user change it manually without
>>>>> tools help). Thanks
>>>>
>>>> Which nice copy of our approach. :-)
>>>
>>> Hmmm... is it true? This approach being used since few years back at
>>> NIOS soft processor. Besides that, we are utilizing the SPL framework
>>> for our second stage boot loader. I believe you guys are not using SPL
>>> right? It seems you guys would need tools to generate and even build you
>>> guys own version of boot loader. It creates high dependency for user to
>>> your tools. 
>>
>> Interesting discussion. :-)
>> I believe we will use SPL at some point in future for Microblaze
>> just because of easier maintenance . But will see.
> 
> Yup, utilizing SPL will gain you the power of open source :)

I agree with you but still we both have strong dependency on tools
regarding to configuration that's why you can do it without tools
but still you have to go through tools to get at least bitstream
for PL.

>>
>> I don't understand your point regarding to tool dependency. For DTSes
>> I believe you are also generating this structure from design tools
>> or you can write it by hand.
>> We are also generating U-boot configuration but if someone wants to write
>> it by hand they can.
> 
> I believe we have misalignment on the term used. For us, second stage
> bootloader is referring to the bootloader loaded by BootROM. I believe
> you guys are referring that as FSBL. 

zynq:
bootrom->fsbl->u-boot-> whatever
or
bootrom->fsbl-> whatever

microblaze:
fsboot->u-boot->whatever.

For you I believe it is for socfpga
bootrom->SPL->u-boot-> whatever or
bootrom->SPL->whatever

I am not quite sure what you are using for NIOS.



>>> For our solution, customer can just grab the code from git and build it
>>> using the normal U-Boot way (if they don't want to use the tools). With
>>> the SPL also, we are taking advantage of open source community power to
>>> make our second stage boot loader more powerful and user friendly to
>>> user. Our user can grab any drivers or leverage the supports from the
>>> open community too. I believe that is the power of open source :) 
>>
>> We have the same for Microblaze and Zynq.
> 
> Same as above, I believe both of us are using U-Boot. But for bootloader
> before U-Boot, we are using SPL while you guys using FSBL which is not
> SPL framework, right? With that, I believe you guys would need a
> proprietary tools to compile and build the FSBL. We would not have this
> dependency when building the SPL code.

Yes that's correct.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131114/2d5d0f99/attachment.pgp>

[U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board

[Albert ARIBAUD]

Hi Pavel,

On Mon, 11 Nov 2013 20:26:02 +0100, Pavel Machek <pavel@denx.de> wrote:

> 
> Altera Cyclone 5 board is very different board (big, rectangular,
> expensive) than EBV Socrates (small, circular, cheap) board. Different
> parts are used there, too, but same configuration of u-boot works on
> both. Nevertheless, printing wrong name confuses users.
> 
> Therefore this splits the configuration so that u-boot knows they are
> different. So far it is only used for correcting the puts, but there
> may be other uses in future.
> 
> Signed-off-by: Pavel Machek <pavel@denx.de>

[weird: I don't see the commit separation line here ("---"). Not that it
matters much, just surprising.]

I assume the discussion on this patch is not actually related to the
change itself, which is thus OK.

However, it does not apply cleanly on current ARM tree.

Amicalement,
-- 
Albert.

[U-Boot] [PATCH v2] Separate EBV Socrates board from Altera Cyclone 5 board and from Virtual Target

[Pavel Machek]

Altera Cyclone 5 board is very different board (big, rectangular,
expensive) than EBV Socrates (small, circular, cheap) board. Different
parts are used there, too, but same configuration of u-boot works on
both. Nevertheless, printing wrong name confuses users. Virtual target
is completely different, and board configured for it will not boot on
physical targets.

Therefore this splits the configuration so that u-boot knows they are
different. So far it is only used for correcting the puts, but there
may be other uses in future.

Signed-off-by: Pavel Machek <pavel@denx.de>

---

Diff from v1: separate virtual target, too, and make it apply to
recent u-boot.

diff --git a/board/altera/socfpga/socfpga_cyclone5.c b/board/altera/socfpga/socfpga_cyclone5.c
index a960eb6..33946b6 100644
--- a/board/altera/socfpga/socfpga_cyclone5.c
+++ b/board/altera/socfpga/socfpga_cyclone5.c
@@ -28,7 +28,7 @@ int print_cpuinfo(void)
  */
 int checkboard(void)
 {
-	puts("BOARD : Altera SOCFPGA Cyclone5 Board\n");
+	puts("BOARD : " ALTERA_BOARD_NAME "\n");
 	return 0;
 }
 
diff --git a/boards.cfg b/boards.cfg
index 221b7f8..6eebbf5 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -379,6 +379,8 @@ Active  arm         armv7          rmobile     renesas         lager
 Active  arm         armv7          s5pc1xx     samsung         goni                s5p_goni                              -                                                                                                                                 Przemyslaw Marczak <p.marczak@samsung.com>
 Active  arm         armv7          s5pc1xx     samsung         smdkc100            smdkc100                              -                                                                                                                                 Minkyu Kang <mk7.kang@samsung.com>
 Active  arm         armv7          socfpga     altera          socfpga             socfpga_cyclone5                      -                                                                                                                                 -
+Active  arm         armv7          socfpga     altera          socfpga             socfpga_virtual                      -                                                                                                                                 -
+Active  arm         armv7          socfpga     altera          socfpga             socfpga_socrates                      -                                                                                                                                 -
 Active  arm         armv7          u8500       st-ericsson     snowball            snowball                              -                                                                                                                                 Mathieu Poirier <mathieu.poirier@linaro.org>
 Active  arm         armv7          u8500       st-ericsson     u8500               u8500_href                            -                                                                                                                                 -
 Active  arm         armv7          vf610       freescale       vf610twr            vf610twr                              vf610twr:IMX_CONFIG=board/freescale/vf610twr/imximage.cfg                                                                         Alison Wang <b18965@freescale.com>
diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
new file mode 100644
index 0000000..4d90952
--- /dev/null
+++ b/include/configs/socfpga_common.h
@@ -0,0 +1,240 @@
+/*
+ *  Copyright (C) 2012 Altera Corporation <www.altera.com>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+#ifndef __CONFIG_COMMON_H
+#define __CONFIG_COMMON_H
+
+#include <asm/arch/socfpga_base_addrs.h>
+#include "../../board/altera/socfpga/pinmux_config.h"
+#include "../../board/altera/socfpga/pll_config.h"
+
+/*
+ * High level configuration
+ */
+
+#define CONFIG_SYS_GENERIC_BOARD
+
+#define CONFIG_ARMV7
+#define CONFIG_SYS_DCACHE_OFF
+#undef CONFIG_USE_IRQ
+
+#define CONFIG_MISC_INIT_R
+#define CONFIG_SINGLE_BOOTLOADER
+#define CONFIG_SOCFPGA
+
+/* base address for .text section */
+#ifdef CONFIG_SOCFPGA_VIRTUAL_TARGET
+#define CONFIG_SYS_TEXT_BASE		0x08000040
+#else
+#define CONFIG_SYS_TEXT_BASE		0x01000040
+#endif
+#define CONFIG_SYS_LOAD_ADDR		0x7fc0
+
+/* Console I/O Buffer Size */
+#define CONFIG_SYS_CBSIZE		256
+/* Monitor Command Prompt */
+#define CONFIG_SYS_PROMPT		"SOCFPGA_CYCLONE5 # "
+#define CONFIG_SYS_PBSIZE		(CONFIG_SYS_CBSIZE + \
+					sizeof(CONFIG_SYS_PROMPT) + 16)
+
+/*
+ * Display CPU and Board Info
+ */
+#define CONFIG_DISPLAY_CPUINFO
+#define CONFIG_DISPLAY_BOARDINFO
+
+/*
+ * Enable early stage initialization at C environment
+ */
+#define CONFIG_BOARD_EARLY_INIT_F
+
+/* flat device tree */
+#define CONFIG_OF_LIBFDT
+/* skip updating the FDT blob */
+#define CONFIG_FDT_BLOB_SKIP_UPDATE
+/* Initial Memory map size for Linux, minus 4k alignment for DFT blob */
+#define CONFIG_SYS_BOOTMAPSZ		((256*1024*1024) - (4*1024))
+
+#define CONFIG_SPL_RAM_DEVICE
+#define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR
+#define CONFIG_SYS_SPL_MALLOC_START ((unsigned long) (&__malloc_start))
+#define CONFIG_SYS_SPL_MALLOC_SIZE (&__malloc_end - &__malloc_start)
+
+/*
+ * Memory allocation (MALLOC)
+ */
+/* Room required on the stack for the environment data */
+#define CONFIG_ENV_SIZE			1024
+/* Size of DRAM reserved for malloc() use */
+#define CONFIG_SYS_MALLOC_LEN		(CONFIG_ENV_SIZE + 128*1024)
+
+/* SP location before relocation, must use scratch RAM */
+#define CONFIG_SYS_INIT_RAM_ADDR	0xFFFF0000
+/* Reserving 0x100 space at back of scratch RAM for debug info */
+#define CONFIG_SYS_INIT_RAM_SIZE	(0x10000 - 0x100)
+/* Stack pointer prior relocation, must situated at on-chip RAM */
+#define CONFIG_SYS_INIT_SP_ADDR		(CONFIG_SYS_INIT_RAM_ADDR + \
+					 CONFIG_SYS_INIT_RAM_SIZE - \
+					 GENERATED_GBL_DATA_SIZE)
+
+
+/*
+ * Command line configuration.
+ */
+#define CONFIG_SYS_NO_FLASH
+#include <config_cmd_default.h>
+/* FAT file system support */
+#define CONFIG_CMD_FAT
+
+
+/*
+ * Misc
+ */
+#define CONFIG_DOS_PARTITION            1
+
+#ifdef CONFIG_SPL_BUILD
+#undef CONFIG_PARTITIONS
+#endif
+
+/*
+ * Environment setup
+ */
+
+/* Delay before automatically booting the default image */
+#define CONFIG_BOOTDELAY		3
+/* Enable auto completion of commands using TAB */
+#define CONFIG_AUTO_COMPLETE
+/* use "hush" command parser */
+#define CONFIG_SYS_HUSH_PARSER
+#define CONFIG_SYS_PROMPT_HUSH_PS2	"> "
+#define CONFIG_CMD_RUN
+
+#define CONFIG_BOOTCOMMAND "run ramboot"
+
+/*
+ * arguments passed to the bootm command. The value of
+ * CONFIG_BOOTARGS goes into the environment value "bootargs".
+ * Do note the value will overide also the chosen node in FDT blob.
+ */
+#define CONFIG_BOOTARGS "console=ttyS0,57600,mem=256M at 0x0"
+
+#define CONFIG_EXTRA_ENV_SETTINGS \
+	"verify=n\0" \
+	"loadaddr= " __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
+	"ramboot=setenv bootargs " CONFIG_BOOTARGS ";" \
+		"bootm ${loadaddr} - ${fdt_addr}\0" \
+	"bootimage=uImage\0" \
+	"fdt_addr=100\0" \
+	"fsloadcmd=ext2load\0" \
+		"bootm ${loadaddr} - ${fdt_addr}\0" \
+	"qspiroot=/dev/mtdblock0\0" \
+	"qspirootfstype=jffs2\0" \
+	"qspiboot=setenv bootargs " CONFIG_BOOTARGS \
+		" root=${qspiroot} rw rootfstype=${qspirootfstype};"\
+		"bootm ${loadaddr} - ${fdt_addr}\0"
+
+/* using environment setting for stdin, stdout, stderr */
+#define CONFIG_SYS_CONSOLE_IS_IN_ENV
+/* Enable the call to overwrite_console() */
+#define CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE
+/* Enable overwrite of previous console environment settings */
+#define CONFIG_SYS_CONSOLE_ENV_OVERWRITE
+
+/* max number of command args	 */
+#define CONFIG_SYS_MAXARGS		16
+
+
+/*
+ * Hardware drivers
+ */
+
+/*
+ * SDRAM Memory Map
+ */
+/* We have 1 bank of DRAM */
+#define CONFIG_NR_DRAM_BANKS		1
+/* SDRAM Bank #1 */
+#define CONFIG_SYS_SDRAM_BASE		0x00000000
+/* SDRAM memory size */
+#define PHYS_SDRAM_1_SIZE		0x40000000
+
+#define PHYS_SDRAM_1			CONFIG_SYS_SDRAM_BASE
+#define CONFIG_SYS_MEMTEST_START	0x00000000
+#define CONFIG_SYS_MEMTEST_END		PHYS_SDRAM_1_SIZE
+
+/*
+ * NS16550 Configuration
+ */
+#define UART0_BASE			SOCFPGA_UART0_ADDRESS
+#define CONFIG_SYS_NS16550
+#define CONFIG_SYS_NS16550_SERIAL
+#define CONFIG_SYS_NS16550_REG_SIZE	-4
+#define CONFIG_SYS_NS16550_CLK          V_NS16550_CLK
+#define CONFIG_CONS_INDEX               1
+#define CONFIG_SYS_NS16550_COM1		UART0_BASE
+#define CONFIG_SYS_BAUDRATE_TABLE {4800, 9600, 19200, 38400, 57600, 115200}
+#ifdef CONFIG_SOCFPGA_VIRTUAL_TARGET
+#define V_NS16550_CLK			1000000
+#else
+#define V_NS16550_CLK			100000000
+#endif
+#define CONFIG_BAUDRATE			115200
+
+/*
+ * FLASH
+ */
+#define CONFIG_SYS_NO_FLASH
+
+/*
+ * L4 OSC1 Timer 0
+ */
+/* This timer use eosc1 where the clock frequency is fixed
+ * throughout any condition */
+#define CONFIG_SYS_TIMERBASE		SOCFPGA_OSC1TIMER0_ADDRESS
+/* reload value when timer count to zero */
+#define TIMER_LOAD_VAL			0xFFFFFFFF
+/* Timer info */
+#ifdef CONFIG_SOCFPGA_VIRTUAL_TARGET
+#define CONFIG_SYS_TIMER_RATE		2400000
+#else
+#define CONFIG_SYS_TIMER_RATE		25000000
+#endif
+#define CONFIG_SYS_TIMER_COUNTER	(CONFIG_SYS_TIMERBASE + 0x4)
+
+#define CONFIG_ENV_IS_NOWHERE
+
+/*
+ * SPL "Second Program Loader" aka Initial Software
+ */
+
+/* Enable building of SPL globally */
+#define CONFIG_SPL
+#define CONFIG_SPL_FRAMEWORK
+
+/* TEXT_BASE for linking the SPL binary */
+#define CONFIG_SPL_TEXT_BASE		0xFFFF0000
+
+/* Stack size for SPL */
+#define CONFIG_SPL_STACK_SIZE		(4 * 1024)
+
+/* MALLOC size for SPL */
+#define CONFIG_SPL_MALLOC_SIZE		(5 * 1024)
+
+#define CONFIG_SPL_SERIAL_SUPPORT
+#define CONFIG_SPL_BOARD_INIT
+
+#define CHUNKSZ_CRC32			(1 * 1024)
+
+#define CONFIG_CRC32_VERIFY
+
+/* Linker script for SPL */
+#define CONFIG_SPL_LDSCRIPT "arch/arm/cpu/armv7/socfpga/u-boot-spl.lds"
+
+/* Support for common/libcommon.o in SPL binary */
+#define CONFIG_SPL_LIBCOMMON_SUPPORT
+/* Support for lib/libgeneric.o in SPL binary */
+#define CONFIG_SPL_LIBGENERIC_SUPPORT
+
+#endif	/* __CONFIG_COMMON_H */
diff --git a/include/configs/socfpga_cyclone5.h b/include/configs/socfpga_cyclone5.h
index 517070c..d5d59d2 100644
--- a/include/configs/socfpga_cyclone5.h
+++ b/include/configs/socfpga_cyclone5.h
@@ -1,242 +1,16 @@
 /*
- *  Copyright (C) 2012 Altera Corporation <www.altera.com>
+ *  Copyright (C) 2014 Pavel Machek <pavel@denx.de>
  *
- * SPDX-License-Identifier:	GPL-2.0+
+ * SPDX-License-Identifier:    GPL-2.0+
  */
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-#include <asm/arch/socfpga_base_addrs.h>
-#include "../../board/altera/socfpga/pinmux_config.h"
-#include "../../board/altera/socfpga/pll_config.h"
-
-/*
- * High level configuration
- */
 /* Virtual target or real hardware */
-#define CONFIG_SOCFPGA_VIRTUAL_TARGET
-
-#define CONFIG_SYS_GENERIC_BOARD
-
-#define CONFIG_ARMV7
-#define CONFIG_SYS_DCACHE_OFF
-#undef CONFIG_USE_IRQ
-
-#define CONFIG_MISC_INIT_R
-#define CONFIG_SINGLE_BOOTLOADER
-#define CONFIG_SOCFPGA
-
-/* base address for .text section */
-#ifdef CONFIG_SOCFPGA_VIRTUAL_TARGET
-#define CONFIG_SYS_TEXT_BASE		0x08000040
-#else
-#define CONFIG_SYS_TEXT_BASE		0x01000040
-#endif
-#define CONFIG_SYS_LOAD_ADDR		0x7fc0
-
-/* Console I/O Buffer Size */
-#define CONFIG_SYS_CBSIZE		256
-/* Monitor Command Prompt */
-#define CONFIG_SYS_PROMPT		"SOCFPGA_CYCLONE5 # "
-#define CONFIG_SYS_PBSIZE		(CONFIG_SYS_CBSIZE + \
-					sizeof(CONFIG_SYS_PROMPT) + 16)
-
-/*
- * Display CPU and Board Info
- */
-#define CONFIG_DISPLAY_CPUINFO
-#define CONFIG_DISPLAY_BOARDINFO
-
-/*
- * Enable early stage initialization at C environment
- */
-#define CONFIG_BOARD_EARLY_INIT_F
-
-/* flat device tree */
-#define CONFIG_OF_LIBFDT
-/* skip updating the FDT blob */
-#define CONFIG_FDT_BLOB_SKIP_UPDATE
-/* Initial Memory map size for Linux, minus 4k alignment for DFT blob */
-#define CONFIG_SYS_BOOTMAPSZ		((256*1024*1024) - (4*1024))
-
-#define CONFIG_SPL_RAM_DEVICE
-#define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR
-#define CONFIG_SYS_SPL_MALLOC_START ((unsigned long) (&__malloc_start))
-#define CONFIG_SYS_SPL_MALLOC_SIZE (&__malloc_end - &__malloc_start)
-
-/*
- * Memory allocation (MALLOC)
- */
-/* Room required on the stack for the environment data */
-#define CONFIG_ENV_SIZE			1024
-/* Size of DRAM reserved for malloc() use */
-#define CONFIG_SYS_MALLOC_LEN		(CONFIG_ENV_SIZE + 128*1024)
-
-/* SP location before relocation, must use scratch RAM */
-#define CONFIG_SYS_INIT_RAM_ADDR	0xFFFF0000
-/* Reserving 0x100 space at back of scratch RAM for debug info */
-#define CONFIG_SYS_INIT_RAM_SIZE	(0x10000 - 0x100)
-/* Stack pointer prior relocation, must situated at on-chip RAM */
-#define CONFIG_SYS_INIT_SP_ADDR		(CONFIG_SYS_INIT_RAM_ADDR + \
-					 CONFIG_SYS_INIT_RAM_SIZE - \
-					 GENERATED_GBL_DATA_SIZE)
-
-
-/*
- * Command line configuration.
- */
-#define CONFIG_SYS_NO_FLASH
-#include <config_cmd_default.h>
-/* FAT file system support */
-#define CONFIG_CMD_FAT
-
-
-/*
- * Misc
- */
-#define CONFIG_DOS_PARTITION            1
-
-#ifdef CONFIG_SPL_BUILD
-#undef CONFIG_PARTITIONS
-#endif
-
-/*
- * Environment setup
- */
-
-/* Delay before automatically booting the default image */
-#define CONFIG_BOOTDELAY		3
-/* Enable auto completion of commands using TAB */
-#define CONFIG_AUTO_COMPLETE
-/* use "hush" command parser */
-#define CONFIG_SYS_HUSH_PARSER
-#define CONFIG_SYS_PROMPT_HUSH_PS2	"> "
-#define CONFIG_CMD_RUN
-
-#define CONFIG_BOOTCOMMAND "run ramboot"
-
-/*
- * arguments passed to the bootm command. The value of
- * CONFIG_BOOTARGS goes into the environment value "bootargs".
- * Do note the value will overide also the chosen node in FDT blob.
- */
-#define CONFIG_BOOTARGS "console=ttyS0,57600,mem=256M at 0x0"
-
-#define CONFIG_EXTRA_ENV_SETTINGS \
-	"verify=n\0" \
-	"loadaddr= " __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
-	"ramboot=setenv bootargs " CONFIG_BOOTARGS ";" \
-		"bootm ${loadaddr} - ${fdt_addr}\0" \
-	"bootimage=uImage\0" \
-	"fdt_addr=100\0" \
-	"fsloadcmd=ext2load\0" \
-		"bootm ${loadaddr} - ${fdt_addr}\0" \
-	"qspiroot=/dev/mtdblock0\0" \
-	"qspirootfstype=jffs2\0" \
-	"qspiboot=setenv bootargs " CONFIG_BOOTARGS \
-		" root=${qspiroot} rw rootfstype=${qspirootfstype};"\
-		"bootm ${loadaddr} - ${fdt_addr}\0"
-
-/* using environment setting for stdin, stdout, stderr */
-#define CONFIG_SYS_CONSOLE_IS_IN_ENV
-/* Enable the call to overwrite_console() */
-#define CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE
-/* Enable overwrite of previous console environment settings */
-#define CONFIG_SYS_CONSOLE_ENV_OVERWRITE
-
-/* max number of command args	 */
-#define CONFIG_SYS_MAXARGS		16
-
-
-/*
- * Hardware drivers
- */
-
-/*
- * SDRAM Memory Map
- */
-/* We have 1 bank of DRAM */
-#define CONFIG_NR_DRAM_BANKS		1
-/* SDRAM Bank #1 */
-#define CONFIG_SYS_SDRAM_BASE		0x00000000
-/* SDRAM memory size */
-#define PHYS_SDRAM_1_SIZE		0x40000000
-
-#define PHYS_SDRAM_1			CONFIG_SYS_SDRAM_BASE
-#define CONFIG_SYS_MEMTEST_START	0x00000000
-#define CONFIG_SYS_MEMTEST_END		PHYS_SDRAM_1_SIZE
-
-/*
- * NS16550 Configuration
- */
-#define UART0_BASE			SOCFPGA_UART0_ADDRESS
-#define CONFIG_SYS_NS16550
-#define CONFIG_SYS_NS16550_SERIAL
-#define CONFIG_SYS_NS16550_REG_SIZE	-4
-#define CONFIG_SYS_NS16550_CLK          V_NS16550_CLK
-#define CONFIG_CONS_INDEX               1
-#define CONFIG_SYS_NS16550_COM1		UART0_BASE
-#define CONFIG_SYS_BAUDRATE_TABLE {4800, 9600, 19200, 38400, 57600, 115200}
-#ifdef CONFIG_SOCFPGA_VIRTUAL_TARGET
-#define V_NS16550_CLK			1000000
-#else
-#define V_NS16550_CLK			100000000
-#endif
-#define CONFIG_BAUDRATE			115200
-
-/*
- * FLASH
- */
-#define CONFIG_SYS_NO_FLASH
-
-/*
- * L4 OSC1 Timer 0
- */
-/* This timer use eosc1 where the clock frequency is fixed
- * throughout any condition */
-#define CONFIG_SYS_TIMERBASE		SOCFPGA_OSC1TIMER0_ADDRESS
-/* reload value when timer count to zero */
-#define TIMER_LOAD_VAL			0xFFFFFFFF
-/* Timer info */
-#ifdef CONFIG_SOCFPGA_VIRTUAL_TARGET
-#define CONFIG_SYS_TIMER_RATE		2400000
-#else
-#define CONFIG_SYS_TIMER_RATE		25000000
-#endif
-#define CONFIG_SYS_TIMER_COUNTER	(CONFIG_SYS_TIMERBASE + 0x4)
-
-#define CONFIG_ENV_IS_NOWHERE
-
-/*
- * SPL "Second Program Loader" aka Initial Software
- */
-
-/* Enable building of SPL globally */
-#define CONFIG_SPL
-#define CONFIG_SPL_FRAMEWORK
-
-/* TEXT_BASE for linking the SPL binary */
-#define CONFIG_SPL_TEXT_BASE		0xFFFF0000
-
-/* Stack size for SPL */
-#define CONFIG_SPL_STACK_SIZE		(4 * 1024)
-
-/* MALLOC size for SPL */
-#define CONFIG_SPL_MALLOC_SIZE		(5 * 1024)
-
-#define CONFIG_SPL_SERIAL_SUPPORT
-#define CONFIG_SPL_BOARD_INIT
-
-#define CHUNKSZ_CRC32			(1 * 1024)
-
-#define CONFIG_CRC32_VERIFY
+#undef CONFIG_SOCFPGA_VIRTUAL_TARGET
 
-/* Linker script for SPL */
-#define CONFIG_SPL_LDSCRIPT "arch/arm/cpu/armv7/socfpga/u-boot-spl.lds"
+#include <configs/socfpga_common.h>
 
-/* Support for common/libcommon.o in SPL binary */
-#define CONFIG_SPL_LIBCOMMON_SUPPORT
-/* Support for lib/libgeneric.o in SPL binary */
-#define CONFIG_SPL_LIBGENERIC_SUPPORT
+#define ALTERA_BOARD_NAME "Altera SOCFPGA Cyclone5 Board"
 
-#endif	/* __CONFIG_H */
+#endif /* __CONFIG_H */
diff --git a/include/configs/socfpga_socrates.h b/include/configs/socfpga_socrates.h
new file mode 100644
index 0000000..27e0261
--- /dev/null
+++ b/include/configs/socfpga_socrates.h
@@ -0,0 +1,16 @@
+/*
+ *  Copyright (C) 2014 Pavel Machek <pavel@denx.de>
+ *
+ * SPDX-License-Identifier:    GPL-2.0+
+ */
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+/* Virtual target or real hardware */
+#undef CONFIG_SOCFPGA_VIRTUAL_TARGET
+
+#include <configs/socfpga_common.h>
+
+#define ALTERA_BOARD_NAME "EBV SoCrates - Cyclone V SoC FPGA Board"
+
+#endif /* __CONFIG_H */
diff --git a/include/configs/socfpga_virtual.h b/include/configs/socfpga_virtual.h
new file mode 100644
index 0000000..cf871e2
--- /dev/null
+++ b/include/configs/socfpga_virtual.h
@@ -0,0 +1,16 @@
+/*
+ *  Copyright (C) 2014 Pavel Machek <pavel@denx.de>
+ *
+ * SPDX-License-Identifier:    GPL-2.0+
+ */
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+/* Virtual target or real hardware */
+#define CONFIG_SOCFPGA_VIRTUAL_TARGET
+
+#include <configs/socfpga_common.h>
+
+#define ALTERA_BOARD_NAME "SOCFPGA Virtual Board"
+
+#endif /* __CONFIG_H */
 


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] [PATCH v2] Separate EBV Socrates board from Altera Cyclone 5 board and from Virtual Target

[Detlev Zundel]

Hi Pavel,

> Altera Cyclone 5 board is very different board (big, rectangular,
> expensive) than EBV Socrates (small, circular, cheap) board. Different
> parts are used there, too, but same configuration of u-boot works on
> both. Nevertheless, printing wrong name confuses users. Virtual target
> is completely different, and board configured for it will not boot on
> physical targets.

Thanks for the initiative again.

> Therefore this splits the configuration so that u-boot knows they are
> different. So far it is only used for correcting the puts, but there
> may be other uses in future.
>
> Signed-off-by: Pavel Machek <pavel@denx.de>
>
> ---
>
> Diff from v1: separate virtual target, too, and make it apply to
> recent u-boot.
>
> diff --git a/board/altera/socfpga/socfpga_cyclone5.c b/board/altera/socfpga/socfpga_cyclone5.c
> index a960eb6..33946b6 100644
> --- a/board/altera/socfpga/socfpga_cyclone5.c
> +++ b/board/altera/socfpga/socfpga_cyclone5.c
> @@ -28,7 +28,7 @@ int print_cpuinfo(void)
>   */
>  int checkboard(void)
>  {
> -	puts("BOARD : Altera SOCFPGA Cyclone5 Board\n");
> +	puts("BOARD : " ALTERA_BOARD_NAME "\n");
>  	return 0;
>  }
>  
> diff --git a/boards.cfg b/boards.cfg
> index 221b7f8..6eebbf5 100644
> --- a/boards.cfg
> +++ b/boards.cfg
> @@ -379,6 +379,8 @@ Active  arm         armv7          rmobile     renesas         lager
>  Active  arm         armv7          s5pc1xx     samsung         goni                s5p_goni                              -                                                                                                                                 Przemyslaw Marczak <p.marczak@samsung.com>
>  Active  arm         armv7          s5pc1xx     samsung         smdkc100            smdkc100                              -                                                                                                                                 Minkyu Kang <mk7.kang@samsung.com>
>  Active  arm         armv7          socfpga     altera          socfpga             socfpga_cyclone5                      -                                                                                                                                 -
> +Active  arm         armv7          socfpga     altera          socfpga             socfpga_virtual                      -                                                                                                                                 -
> +Active  arm         armv7          socfpga     altera          socfpga             socfpga_socrates

As you correctly note, the socrates is sold by EBV and not Altera so I
guess the 5th column needs to be changed.  Will this still work?

Other than that:

Acked-by: Detlev Zundel <dzu@denx.de>

Cheers
  Detlev
  
-- 
Those who would give up essential liberty to purchase a little
temporary safety, deserve neither liberty nor safety.
                                     -- Benjamin Franklin
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] [PATCH v2] Separate EBV Socrates board from Altera Cyclone 5 board and from Virtual Target

[Pavel Machek]

Hi, Detlev!

> > Altera Cyclone 5 board is very different board (big, rectangular,
> > expensive) than EBV Socrates (small, circular, cheap) board. Different
> > parts are used there, too, but same configuration of u-boot works on
> > both. Nevertheless, printing wrong name confuses users. Virtual target
> > is completely different, and board configured for it will not boot on
> > physical targets.
> 
> Thanks for the initiative again.

I'm celebrating mainline u-boot on my target :-).

> > --- a/boards.cfg
> > +++ b/boards.cfg
> > @@ -379,6 +379,8 @@ Active  arm         armv7          rmobile     renesas         lager
> >  Active  arm         armv7          s5pc1xx     samsung         goni                s5p_goni                              -                                                                                                                                 Przemyslaw Marczak <p.marczak@samsung.com>
> >  Active  arm         armv7          s5pc1xx     samsung         smdkc100            smdkc100                              -                                                                                                                                 Minkyu Kang <mk7.kang@samsung.com>
> >  Active  arm         armv7          socfpga     altera          socfpga             socfpga_cyclone5                      -                                                                                                                                 -
> > +Active  arm         armv7          socfpga     altera          socfpga             socfpga_virtual                      -                                                                                                                                 -
> > +Active  arm         armv7          socfpga     altera          socfpga             socfpga_socrates
> 
> As you correctly note, the socrates is sold by EBV and not Altera so I
> guess the 5th column needs to be changed.  Will this still work?

That will result in:

  CC      arch/arm/lib/eabi_compat.o
scripts/Makefile.build:64:
/home/pavel/wagabuibui/u-boot/board/ebv/socfpga/Makefile: No such file
or directory
make[2]: *** No rule to make target
`/home/pavel/wagabuibui/u-boot/board/ebv/socfpga/Makefile'.  Stop.

...and I don't think we want to do board/{altera,ebv} symlink. Are
there any other options? Or is "altera" in the boards file simply
acceptable?

Thanks,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] [PATCH v2] Separate EBV Socrates board from Altera Cyclone 5 board and from Virtual Target

[Detlev Zundel]

Hi Pavel,

> Hi, Detlev!
>
>> > Altera Cyclone 5 board is very different board (big, rectangular,
>> > expensive) than EBV Socrates (small, circular, cheap) board. Different
>> > parts are used there, too, but same configuration of u-boot works on
>> > both. Nevertheless, printing wrong name confuses users. Virtual target
>> > is completely different, and board configured for it will not boot on
>> > physical targets.
>> 
>> Thanks for the initiative again.
>
> I'm celebrating mainline u-boot on my target :-).

Yay!

>> > --- a/boards.cfg
>> > +++ b/boards.cfg
>> > @@ -379,6 +379,8 @@ Active arm armv7 rmobile renesas lager
>> >  Active arm armv7 s5pc1xx samsung goni s5p_goni - Przemyslaw
>> > Marczak <p.marczak@samsung.com>
>> >  Active arm armv7 s5pc1xx samsung smdkc100 smdkc100 - Minkyu Kang
>> > <mk7.kang@samsung.com>
>> >  Active arm armv7 socfpga altera socfpga socfpga_cyclone5 - -
>> > +Active arm armv7 socfpga altera socfpga socfpga_virtual - -
>> > +Active arm armv7 socfpga altera socfpga socfpga_socrates
>> 
>> As you correctly note, the socrates is sold by EBV and not Altera so I
>> guess the 5th column needs to be changed.  Will this still work?
>
> That will result in:
>
>   CC      arch/arm/lib/eabi_compat.o
> scripts/Makefile.build:64:
> /home/pavel/wagabuibui/u-boot/board/ebv/socfpga/Makefile: No such file
> or directory
> make[2]: *** No rule to make target
> `/home/pavel/wagabuibui/u-boot/board/ebv/socfpga/Makefile'.  Stop.

I feared as much, so thats why I asked ;)

> ...and I don't think we want to do board/{altera,ebv} symlink. Are
> there any other options? Or is "altera" in the boards file simply
> acceptable?

This is a problem that will turn up in the future even more, so I
propose to solve it correctly now.  It will not be long before we want
to have our own configuration for our MCV module and this will certainly
be sold by DENX.  I think we need an infrastructure to allow for boards
sold by arbitrary manufacturers all using the Altera chip.

The situation as such is not uncommon, so maybe you can follow examples
from different CPUs?  I.e. how is the imx6 handled on the different base
boards?

Cheers
  Detlev
  
-- 
LISP has survived for 21 years because it is an approximate local
optimum in the space of programming languages.
                                           -- John McCarthy (1980)
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] [PATCH v2] Separate EBV Socrates board from Altera Cyclone 5 board and from Virtual Target

[Pavel Machek]

Hi!

> > /home/pavel/wagabuibui/u-boot/board/ebv/socfpga/Makefile: No such file
> > or directory
> > make[2]: *** No rule to make target
> > `/home/pavel/wagabuibui/u-boot/board/ebv/socfpga/Makefile'.  Stop.
> 
> I feared as much, so thats why I asked ;)
> 
> > ...and I don't think we want to do board/{altera,ebv} symlink. Are
> > there any other options? Or is "altera" in the boards file simply
> > acceptable?
> 
> This is a problem that will turn up in the future even more, so I
> propose to solve it correctly now.  It will not be long before we
 > want

Well, OTOH it is orthogonal problem to the "board name is shared
between socrates and altera" and "config is shared between altera and
virtual target". And this patch is going to go stale rather quickly.

> to have our own configuration for our MCV module and this will certainly
> be sold by DENX.  I think we need an infrastructure to allow for boards
> sold by arbitrary manufacturers all using the Altera chip.
> 
> The situation as such is not uncommon, so maybe you can follow examples
> from different CPUs?  I.e. how is the imx6 handled on the different base
> boards?

The examples I seen were different: there different board vendors
actually needed different code.

AFAICT, one solution would be to put "-" in that column, and do "git
mv board/altera/ board/socfpga/".

But if we decide to go that way, it should really be separate patch.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] [PATCH v2] Separate EBV Socrates board from Altera Cyclone 5 board and from Virtual Target

[Detlev Zundel]

Hi Pavel,

> Hi!
>
>> > /home/pavel/wagabuibui/u-boot/board/ebv/socfpga/Makefile: No such file
>> > or directory
>> > make[2]: *** No rule to make target
>> > `/home/pavel/wagabuibui/u-boot/board/ebv/socfpga/Makefile'.  Stop.
>> 
>> I feared as much, so thats why I asked ;)
>> 
>> > ...and I don't think we want to do board/{altera,ebv} symlink. Are
>> > there any other options? Or is "altera" in the boards file simply
>> > acceptable?
>> 
>> This is a problem that will turn up in the future even more, so I
>> propose to solve it correctly now.  It will not be long before we
>  > want
>
> Well, OTOH it is orthogonal problem to the "board name is shared
> between socrates and altera" and "config is shared between altera and
> virtual target". And this patch is going to go stale rather quickly.

I admit, I do not understand that fully.

>> to have our own configuration for our MCV module and this will certainly
>> be sold by DENX.  I think we need an infrastructure to allow for boards
>> sold by arbitrary manufacturers all using the Altera chip.
>> 
>> The situation as such is not uncommon, so maybe you can follow examples
>> from different CPUs?  I.e. how is the imx6 handled on the different base
>> boards?
>
> The examples I seen were different: there different board vendors
> actually needed different code.
>
> AFAICT, one solution would be to put "-" in that column, and do "git
> mv board/altera/ board/socfpga/".

Putting "-" in the vendor column just doesn't feel right.  How about
using a minimal board C file for socrates under ebv/socrates that only
implements checkboard and shares the rest?

> But if we decide to go that way, it should really be separate patch.

I still like to see a solution that scales to things we already know
will happen ;)  Looking at the original patch, with this in mind even
the #define ALTERA_BOARD_NAME doesn't look right any longer.

Thanks
  Detlev

-- 
We have a live-manual.  It's called emacs-devel at gnu.org.
You can stick to just reading it, but you can skip to a specific chapter
by simply sending an email asking for it ;-)
                                    -- Stefan Monnier
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] [PATCH v2] Separate EBV Socrates board from Altera Cyclone 5 board and from Virtual Target

[Pavel Machek]

Hi!

> > Well, OTOH it is orthogonal problem to the "board name is shared
> > between socrates and altera" and "config is shared between altera and
> > virtual target". And this patch is going to go stale rather quickly.
> 
> I admit, I do not understand that fully.

There are no differences between EBV socrates and socfpga boards,
currently.

> >> to have our own configuration for our MCV module and this will certainly
> >> be sold by DENX.  I think we need an infrastructure to allow for boards
> >> sold by arbitrary manufacturers all using the Altera chip.
> >> 
> >> The situation as such is not uncommon, so maybe you can follow examples
> >> from different CPUs?  I.e. how is the imx6 handled on the different base
> >> boards?
> >
> > The examples I seen were different: there different board vendors
> > actually needed different code.
> >
> > AFAICT, one solution would be to put "-" in that column, and do "git
> > mv board/altera/ board/socfpga/".
> 
> Putting "-" in the vendor column just doesn't feel right.  

That's what mx6 did, AFAICT.

> How about
> using a minimal board C file for socrates under ebv/socrates that only
> implements checkboard and shares the rest?

That does not feel right, either. (Too much changes for too little gain.)

Actually.. there's nothing Altera specific in board/altera (it works
on ebv just fine), so board/socfpga sounds like a better name. But I
don't think such rename should be done lightly, so I still believe the
patch as submitted is the best way to go.

> > But if we decide to go that way, it should really be separate patch.
> 
> I still like to see a solution that scales to things we already know
> will happen ;)  Looking at the original patch, with this in mind even
> the #define ALTERA_BOARD_NAME doesn't look right any longer.

I don't know what will happen next. Albert asked me to resubmit patch
updated to newer code, which I did.

Best regards,
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] [PATCH v2] Separate EBV Socrates board from Altera Cyclone 5 board and from Virtual Target

[Wolfgang Denk]

Dear Pavel,

In message <20140528124910.GA24478@amd.pavel.ucw.cz> you wrote:
> 
> There are no differences between EBV socrates and socfpga boards,
> currently.

Well, for one thing, the board vendor and the board name differ...

> > > AFAICT, one solution would be to put "-" in that column, and do "git
> > > mv board/altera/ board/socfpga/".
> > 
> > Putting "-" in the vendor column just doesn't feel right.  
> 
> That's what mx6 did, AFAICT.

I think Detlev is right here.  We do have specific board vendors
directories, and there are a number of reasons to keep this used
(just to give one example: say a vendor wants to use a similar look
and feel for the default environment settings etc. for all boards).

If there is code which is identical for several (or all?) boards we
should ask ourself if it really belongs into the board/ directory at
all?

> Actually.. there's nothing Altera specific in board/altera (it works
> on ebv just fine), so board/socfpga sounds like a better name. But I
> don't think such rename should be done lightly, so I still believe the
> patch as submitted is the best way to go.

I think board/altera as such makes sense, with Altera being the vendor
of that specific board.  However, if there is common code there, this
code should be moved out of board/ .

[Note that I'm just commenting from an outside point of view; I did
not check to what extent the "common" code under discussion here is
truely common to all possible board configs.]

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
 The software required `Windows 95 or better', so I installed Linux.

[U-Boot] [PATCH v2] Separate EBV Socrates board from Altera Cyclone 5 board and from Virtual Target

[Pavel Machek]

Hi!

On Wed 2014-05-28 16:29:50, Wolfgang Denk wrote:
> In message <20140528124910.GA24478@amd.pavel.ucw.cz> you wrote:
> > 
> > There are no differences between EBV socrates and socfpga boards,
> > currently.
> 
> Well, for one thing, the board vendor and the board name differ...

I meant from current code in u-boot point of view...

> > > > AFAICT, one solution would be to put "-" in that column, and do "git
> > > > mv board/altera/ board/socfpga/".
> > > 
> > > Putting "-" in the vendor column just doesn't feel right.  
> > 
> > That's what mx6 did, AFAICT.
> 
> I think Detlev is right here.  We do have specific board vendors
> directories, and there are a number of reasons to keep this used
> (just to give one example: say a vendor wants to use a similar look
> and feel for the default environment settings etc. for all boards).

> If there is code which is identical for several (or all?) boards we
> should ask ourself if it really belongs into the board/ directory at
> all?

That might be the case. It seems that current code in board/altera is
SoC-specific, as it works on both Altera and EBV boards. 

> > Actually.. there's nothing Altera specific in board/altera (it works
> > on ebv just fine), so board/socfpga sounds like a better name. But I
> > don't think such rename should be done lightly, so I still believe the
> > patch as submitted is the best way to go.
> 
> I think board/altera as such makes sense, with Altera being the vendor
> of that specific board.  However, if there is common code there, this
> code should be moved out of board/ .

It seems there's currently 99.99% of SoC-specific code there.

What would be the right place for that code?
arch/arm/cpu/armv7/socfpga/ ? But it is not really armv7-specific.
drivers/misc ? Do we need to make a soc/ directory?

And then... who does the move? It is not going to make merging between
rocketboards.org and mainline even trickier than it already is :-(.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] [PATCH v2] Separate EBV Socrates board from Altera Cyclone 5 board and from Virtual Target

[Detlev Zundel]

Hi Pavel,

> On Wed 2014-05-28 16:29:50, Wolfgang Denk wrote:
>> In message <20140528124910.GA24478@amd.pavel.ucw.cz> you wrote:
>> > 
>> > There are no differences between EBV socrates and socfpga boards,
>> > currently.
>> 
>> Well, for one thing, the board vendor and the board name differ...
>
> I meant from current code in u-boot point of view...

But as we all agree, this may change quickly and for multiple boards.

>> > > > AFAICT, one solution would be to put "-" in that column, and
>> > > > do "git
>> > > > mv board/altera/ board/socfpga/".
>> > > 
>> > > Putting "-" in the vendor column just doesn't feel right.  
>> > 
>> > That's what mx6 did, AFAICT.
>> 
>> I think Detlev is right here.  We do have specific board vendors
>> directories, and there are a number of reasons to keep this used
>> (just to give one example: say a vendor wants to use a similar look
>> and feel for the default environment settings etc. for all boards).
>
>> If there is code which is identical for several (or all?) boards we
>> should ask ourself if it really belongs into the board/ directory at
>> all?
>
> That might be the case. It seems that current code in board/altera is
> SoC-specific, as it works on both Altera and EBV boards. 

Then we are in agreement that it does not belong below board/ ;)

>> > Actually.. there's nothing Altera specific in board/altera (it works
>> > on ebv just fine), so board/socfpga sounds like a better name. But I
>> > don't think such rename should be done lightly, so I still believe the
>> > patch as submitted is the best way to go.
>> 
>> I think board/altera as such makes sense, with Altera being the vendor
>> of that specific board.  However, if there is common code there, this
>> code should be moved out of board/ .
>
> It seems there's currently 99.99% of SoC-specific code there.
>
> What would be the right place for that code?

Depends on what exactly it implements.  Apart from that we can also take
a look at where the code is in a Linux tree and take that as an
example.  After all, we want people developing the Linux kernel to also
feel at home in the U-Boot sources.

> arch/arm/cpu/armv7/socfpga/ ? But it is not really armv7-specific.
> drivers/misc ? Do we need to make a soc/ directory?

We have arch/arm/imx-common for example, but I'm not so sure if this is
a good approach.  Maybe there is not a _single_ correct place, but we
have to distribute the files to multiple directories?

> And then... who does the move? It is not going to make merging between
> rocketboards.org and mainline even trickier than it already is :-(.

This is a good question and we should certainly not answer it lightly.
Usually we care only to a certain degree for non-mainline code, though.
Blocking ourselves because of non-mainline code would allow "external"
control which I think is not really helpful for the project.

Cheers
  Detlev
  
-- 
I think that level of generalization is too abstract for useful thinking.
             -- Richard Stallman in <E19N344-0006Q9-Bt@fencepost.gnu.org>
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] [PATCH v2] Separate EBV Socrates board from Altera Cyclone 5 board and from Virtual Target

[Chin Liang See]

Hi guys,


On Fri, 2014-05-30 at 11:41 +0200, Detlev Zundel wrote:
> Hi Pavel,
> 
> > On Wed 2014-05-28 16:29:50, Wolfgang Denk wrote:
> >> In message <20140528124910.GA24478@amd.pavel.ucw.cz> you wrote:
> >> > 
> >> > There are no differences between EBV socrates and socfpga boards,
> >> > currently.
> >> 
> >> Well, for one thing, the board vendor and the board name differ...
> >
> > I meant from current code in u-boot point of view...
> 
> But as we all agree, this may change quickly and for multiple boards.


Yup, some other board vendors are using different HW configuration. Some
of the difference are Altera dev kit have EEPROM and using Micrel PHY
for EMAC. I presume Socrates board should have their own board path such
as board/socrates/socfpga.


> 
> >> > > > AFAICT, one solution would be to put "-" in that column, and
> >> > > > do "git
> >> > > > mv board/altera/ board/socfpga/".
> >> > > 
> >> > > Putting "-" in the vendor column just doesn't feel right.  
> >> > 
> >> > That's what mx6 did, AFAICT.
> >> 
> >> I think Detlev is right here.  We do have specific board vendors
> >> directories, and there are a number of reasons to keep this used
> >> (just to give one example: say a vendor wants to use a similar look
> >> and feel for the default environment settings etc. for all boards).
> >
> >> If there is code which is identical for several (or all?) boards we
> >> should ask ourself if it really belongs into the board/ directory at
> >> all?
> >
> > That might be the case. It seems that current code in board/altera is
> > SoC-specific, as it works on both Altera and EBV boards. 
> 
> Then we are in agreement that it does not belong below board/ ;)


Within board/altera, there are 2 types of files as below:

1. HW configuration handoff files (such as pinmux_config, pll_config).
   Pinmux might be different as certain board might have different
routing (normally to optimize the board layout and shorter PCB trace
length).
   
2. Board specific code (socfpga_cyclone5.c)
   These functions include board_init, board_early_init, checkboard.
   I believe that the function print_cpuinfo and overwrite _console
should goto arch/arm/cpu/armv7/socfpga/misc.c.
   I will create the patch to change this later (as I already did this
at rocketboard.org).

 
> 
> >> > Actually.. there's nothing Altera specific in board/altera (it works
> >> > on ebv just fine), so board/socfpga sounds like a better name. But I
> >> > don't think such rename should be done lightly, so I still believe the
> >> > patch as submitted is the best way to go.
> >> 
> >> I think board/altera as such makes sense, with Altera being the vendor
> >> of that specific board.  However, if there is common code there, this
> >> code should be moved out of board/ .
> >
> > It seems there's currently 99.99% of SoC-specific code there.
> >
> > What would be the right place for that code?
> 
> Depends on what exactly it implements.  Apart from that we can also take
> a look at where the code is in a Linux tree and take that as an
> example.  After all, we want people developing the Linux kernel to also
> feel at home in the U-Boot sources.
> 
> > arch/arm/cpu/armv7/socfpga/ ? But it is not really armv7-specific.
> > drivers/misc ? Do we need to make a soc/ directory?
> 
> We have arch/arm/imx-common for example, but I'm not so sure if this is
> a good approach.  Maybe there is not a _single_ correct place, but we
> have to distribute the files to multiple directories?
> 
> > And then... who does the move? It is not going to make merging between
> > rocketboards.org and mainline even trickier than it already is :-(.
> 
> This is a good question and we should certainly not answer it lightly.
> Usually we care only to a certain degree for non-mainline code, though.
> Blocking ourselves because of non-mainline code would allow "external"
> control which I think is not really helpful for the project.
> 


As above, I can move some common function to
arch/arm/cpu/armv7/socfpga/misc.c.

Thanks
Chin Liang


> Cheers
>   Detlev
>   

[U-Boot] [PATCH v2] Separate EBV Socrates board from Altera Cyclone 5 board and from Virtual Target

[Chin Liang See]

Hi Pavel,

On Tue, 2014-05-27 at 15:12 +0200, ZY - pavel wrote:
> Altera Cyclone 5 board is very different board (big, rectangular,
> expensive) than EBV Socrates (small, circular, cheap) board. Different
> parts are used there, too, but same configuration of u-boot works on
> both. Nevertheless, printing wrong name confuses users. Virtual target
> is completely different, and board configured for it will not boot on
> physical targets.
> 
> Therefore this splits the configuration so that u-boot knows they are
> different. So far it is only used for correcting the puts, but there
> may be other uses in future.
> 
> Signed-off-by: Pavel Machek <pavel@denx.de>
> 
> ---
> 
> Diff from v1: separate virtual target, too, and make it apply to
> recent u-boot.
> 
> diff --git a/board/altera/socfpga/socfpga_cyclone5.c b/board/altera/socfpga/socfpga_cyclone5.c
> index a960eb6..33946b6 100644
> --- a/board/altera/socfpga/socfpga_cyclone5.c
> +++ b/board/altera/socfpga/socfpga_cyclone5.c
> @@ -28,7 +28,7 @@ int print_cpuinfo(void)
>   */
>  int checkboard(void)
>  {
> -	puts("BOARD : Altera SOCFPGA Cyclone5 Board\n");
> +	puts("BOARD : " ALTERA_BOARD_NAME "\n");
>  	return 0;
>  }
>  
> diff --git a/boards.cfg b/boards.cfg
> index 221b7f8..6eebbf5 100644
> --- a/boards.cfg
> +++ b/boards.cfg
> @@ -379,6 +379,8 @@ Active  arm         armv7          rmobile     renesas         lager
>  Active  arm         armv7          s5pc1xx     samsung         goni                s5p_goni                              -                                                                                                                                 Przemyslaw Marczak <p.marczak@samsung.com>
>  Active  arm         armv7          s5pc1xx     samsung         smdkc100            smdkc100                              -                                                                                                                                 Minkyu Kang <mk7.kang@samsung.com>
>  Active  arm         armv7          socfpga     altera          socfpga             socfpga_cyclone5                      -                                                                                                                                 -
> +Active  arm         armv7          socfpga     altera          socfpga             socfpga_virtual                      -                                                                                                                                 -
> +Active  arm         armv7          socfpga     altera          socfpga             socfpga_socrates                      -                                                                                                                                 -
>  Active  arm         armv7          u8500       st-ericsson     snowball            snowball                              -                                                                                                                                 Mathieu Poirier <mathieu.poirier@linaro.org>
>  Active  arm         armv7          u8500       st-ericsson     u8500               u8500_href                            -                                                                                                                                 -
>  Active  arm         armv7          vf610       freescale       vf610twr            vf610twr                              vf610twr:IMX_CONFIG=board/freescale/vf610twr/imximage.cfg                                                                         Alison Wang <b18965@freescale.com>
> diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
> new file mode 100644
> index 0000000..4d90952
> --- /dev/null
> +++ b/include/configs/socfpga_common.h
> @@ -0,0 +1,240 @@
> +/*
> + *  Copyright (C) 2012 Altera Corporation <www.altera.com>
> + *
> + * SPDX-License-Identifier:	GPL-2.0+
> + */
> +#ifndef __CONFIG_COMMON_H
> +#define __CONFIG_COMMON_H
> +
> +#include <asm/arch/socfpga_base_addrs.h>
> +#include "../../board/altera/socfpga/pinmux_config.h"
> +#include "../../board/altera/socfpga/pll_config.h"
> +


I believe these should go to board specific header file such as
socfpga_cyclone5 and socfpga_socrates. These are HW configuration
handoff files and different from board to board.


> +/*
> + * Hardware drivers
> + */
> +
> +/*
> + * SDRAM Memory Map
> + */
> +/* We have 1 bank of DRAM */
> +#define CONFIG_NR_DRAM_BANKS		1
> +/* SDRAM Bank #1 */
> +#define CONFIG_SYS_SDRAM_BASE		0x00000000
> +/* SDRAM memory size */
> +#define PHYS_SDRAM_1_SIZE		0x40000000
> +


Just a quick comments. In newer version SPL at rocketboard.org, we won't
need to specify the size. It will be calculated based on HW registers.
We will change this together with SPL SDRAM patch.


> diff --git a/include/configs/socfpga_cyclone5.h b/include/configs/socfpga_cyclone5.h
> index 517070c..d5d59d2 100644
> --- a/include/configs/socfpga_cyclone5.h
> +++ b/include/configs/socfpga_cyclone5.h
> @@ -1,242 +1,16 @@
>  /*
> - *  Copyright (C) 2012 Altera Corporation <www.altera.com>
> + *  Copyright (C) 2014 Pavel Machek <pavel@denx.de>
>   *
> - * SPDX-License-Identifier:	GPL-2.0+
> + * SPDX-License-Identifier:    GPL-2.0+
>   */
>  #ifndef __CONFIG_H
>  #define __CONFIG_H
>  
> -#include <asm/arch/socfpga_base_addrs.h>
> -#include "../../board/altera/socfpga/pinmux_config.h"
> -#include "../../board/altera/socfpga/pll_config.h"
> -


Same as above. We need to retain the handoff path in board specific
header file instead common.

Thanks
Chin Liang

[U-Boot] [PATCH v2] Separate EBV Socrates board from Altera Cyclone 5 board and from Virtual Target

[Detlev Zundel]

Hi Chian,

> Hi guys,
>
>
> On Fri, 2014-05-30 at 11:41 +0200, Detlev Zundel wrote:
>> Hi Pavel,
>>
>> > On Wed 2014-05-28 16:29:50, Wolfgang Denk wrote:
>> >> In message <20140528124910.GA24478@amd.pavel.ucw.cz> you wrote:
>> >> >
>> >> > There are no differences between EBV socrates and socfpga boards,
>> >> > currently.
>> >>
>> >> Well, for one thing, the board vendor and the board name differ...
>> >
>> > I meant from current code in u-boot point of view...
>>
>> But as we all agree, this may change quickly and for multiple boards.
>
>
> Yup, some other board vendors are using different HW configuration. Some
> of the difference are Altera dev kit have EEPROM and using Micrel PHY
> for EMAC. I presume Socrates board should have their own board path such
> as board/socrates/socfpga.

We are using a "board/<vendor>" scheme, so it should be
"board/ebv/socrates", but otherwise we agree.

>> >> > > > AFAICT, one solution would be to put "-" in that column, and
>> >> > > > do "git
>> >> > > > mv board/altera/ board/socfpga/".
>> >> > >
>> >> > > Putting "-" in the vendor column just doesn't feel right.
>> >> >
>> >> > That's what mx6 did, AFAICT.
>> >>
>> >> I think Detlev is right here.  We do have specific board vendors
>> >> directories, and there are a number of reasons to keep this used
>> >> (just to give one example: say a vendor wants to use a similar look
>> >> and feel for the default environment settings etc. for all boards).
>> >
>> >> If there is code which is identical for several (or all?) boards we
>> >> should ask ourself if it really belongs into the board/ directory at
>> >> all?
>> >
>> > That might be the case. It seems that current code in board/altera is
>> > SoC-specific, as it works on both Altera and EBV boards.
>>
>> Then we are in agreement that it does not belong below board/ ;)
>
>
> Within board/altera, there are 2 types of files as below:
>
> 1. HW configuration handoff files (such as pinmux_config, pll_config).
>    Pinmux might be different as certain board might have different
> routing (normally to optimize the board layout and shorter PCB trace
> length).
>
> 2. Board specific code (socfpga_cyclone5.c)
>    These functions include board_init, board_early_init, checkboard.
>    I believe that the function print_cpuinfo and overwrite _console
> should goto arch/arm/cpu/armv7/socfpga/misc.c.
>    I will create the patch to change this later (as I already did this
> at rocketboard.org).

Thanks in advance!

>> >> > Actually.. there's nothing Altera specific in board/altera (it works
>> >> > on ebv just fine), so board/socfpga sounds like a better name. But I
>> >> > don't think such rename should be done lightly, so I still believe the
>> >> > patch as submitted is the best way to go.
>> >>
>> >> I think board/altera as such makes sense, with Altera being the vendor
>> >> of that specific board.  However, if there is common code there, this
>> >> code should be moved out of board/ .
>> >
>> > It seems there's currently 99.99% of SoC-specific code there.
>> >
>> > What would be the right place for that code?
>>
>> Depends on what exactly it implements.  Apart from that we can also take
>> a look at where the code is in a Linux tree and take that as an
>> example.  After all, we want people developing the Linux kernel to also
>> feel at home in the U-Boot sources.
>>
>> > arch/arm/cpu/armv7/socfpga/ ? But it is not really armv7-specific.
>> > drivers/misc ? Do we need to make a soc/ directory?
>>
>> We have arch/arm/imx-common for example, but I'm not so sure if this is
>> a good approach.  Maybe there is not a _single_ correct place, but we
>> have to distribute the files to multiple directories?
>>
>> > And then... who does the move? It is not going to make merging between
>> > rocketboards.org and mainline even trickier than it already is :-(.
>>
>> This is a good question and we should certainly not answer it lightly.
>> Usually we care only to a certain degree for non-mainline code, though.
>> Blocking ourselves because of non-mainline code would allow "external"
>> control which I think is not really helpful for the project.
>>
>
>
> As above, I can move some common function to
> arch/arm/cpu/armv7/socfpga/misc.c.

Sounds good.

Thanks
  Detlev
  
-- 
A statistician can have his head in an oven and his feet in ice, and
he will say that on the average he feels fine.
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de