[U-Boot] [PATCH V4 0/4] update SMDK2410 port
This patch serie brings the SMDK2410 port in sync with the latest U-Boot version by doing the following: - do the necessary adjustments to support the ARM relocation feature - use the CFI flash driver (and removing the old one) - remove the unneeded config.mk file --- board/samsung/smdk2410/Makefile |2 +- board/samsung/smdk2410/config.mk | 25 --- board/samsung/smdk2410/flash.c| 433 - board/samsung/smdk2410/smdk2410.c | 73 --- include/configs/smdk2410.h| 178 ++- 5 files changed, 165 insertions(+), 546 deletions(-) Changes for V2: - deleted config.mk Changes for V3: - adjusted patch meta info Changes for V4: - split patch into smaller pieces ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 1/4] activate ARM relocation feature
Signed-off-by: David Müller d.muel...@elsoft.ch --- include/configs/smdk2410.h |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/include/configs/smdk2410.h b/include/configs/smdk2410.h index 62fe97e..38b5684 100644 --- a/include/configs/smdk2410.h +++ b/include/configs/smdk2410.h @@ -179,4 +179,11 @@ #defineCONFIG_ENV_IS_IN_FLASH 1 #define CONFIG_ENV_SIZE0x1 /* Total Size of Environment Sector */ +/* additions for new relocation code, must be added to all boards */ +#undef CONFIG_SYS_ARM_WITHOUT_RELOC +#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_SDRAM_BASE + 0x1000 - \ + GENERATED_GBL_DATA_SIZE) + + #endif /* __CONFIG_H */ -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 2/4] remove unneeded config.mk
Signed-off-by: David Müller d.muel...@elsoft.ch --- board/samsung/smdk2410/config.mk | 25 - include/configs/smdk2410.h |2 ++ 2 files changed, 2 insertions(+), 25 deletions(-) delete mode 100644 board/samsung/smdk2410/config.mk diff --git a/board/samsung/smdk2410/config.mk b/board/samsung/smdk2410/config.mk deleted file mode 100644 index c8d1b1f..000 --- a/board/samsung/smdk2410/config.mk +++ /dev/null @@ -1,25 +0,0 @@ -# -# (C) Copyright 2002 -# Gary Jennejohn, DENX Software Engineering, ga...@denx.de -# David Mueller, ELSOFT AG, d.muel...@elsoft.ch -# -# SAMSUNG SMDK2410 board with S3C2410X (ARM920T) cpu -# -# see http://www.samsung.com/ for more information on SAMSUNG -# - -# -# SMDK2410 has 1 bank of 64 MB DRAM -# -# 3000' to 3400' -# -# Linux-Kernel is expected to be at 3000'8000, entry 3000'8000 -# optionally with a ramdisk at 3080' -# -# we load ourself to 33F8' -# -# download area is 3300' -# - - -CONFIG_SYS_TEXT_BASE = 0x33F8 diff --git a/include/configs/smdk2410.h b/include/configs/smdk2410.h index 38b5684..3b037c4 100644 --- a/include/configs/smdk2410.h +++ b/include/configs/smdk2410.h @@ -38,6 +38,8 @@ #define CONFIG_S3C2410 1 /* specifically a SAMSUNG S3C2410 SoC */ #define CONFIG_SMDK24101 /* on a SAMSUNG SMDK2410 Board */ +#define CONFIG_SYS_TEXT_BASE 0x0 + /* input clock of PLL */ #define CONFIG_SYS_CLK_FREQ1200/* the SMDK2410 has 12MHz input clock */ -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 4/4] various cleanups/code style fixes
Signed-off-by: David Müller d.muel...@elsoft.ch
---
board/samsung/smdk2410/smdk2410.c | 61 +---
include/configs/smdk2410.h| 141 ++---
2 files changed, 133 insertions(+), 69 deletions(-)
diff --git a/board/samsung/smdk2410/smdk2410.c
b/board/samsung/smdk2410/smdk2410.c
index 1abc4ba..e9ba922 100644
--- a/board/samsung/smdk2410/smdk2410.c
+++ b/board/samsung/smdk2410/smdk2410.c
@@ -3,7 +3,7 @@
* Sysgo Real-Time Solutions, GmbH www.elinos.com
* Marius Groeger mgroe...@sysgo.de
*
- * (C) Copyright 2002
+ * (C) Copyright 2002, 2010
* David Mueller, ELSOFT AG, d.muel...@elsoft.ch
*
* See file CREDITS for list of people who contributed to this
@@ -27,6 +27,7 @@
#include common.h
#include netdev.h
+#include asm/io.h
#include asm/arch/s3c24x0_cpu.h
DECLARE_GLOBAL_DATA_PTR;
@@ -55,7 +56,7 @@ DECLARE_GLOBAL_DATA_PTR;
#define U_M_SDIV 0x2
#endif
-static inline void delay (unsigned long loops)
+static inline void pll_delay(unsigned long loops)
{
__asm__ volatile (1:\n
subs %0, %1, #1\n
@@ -66,44 +67,51 @@ static inline void delay (unsigned long loops)
* Miscellaneous platform dependent initialisations
*/
-int board_init (void)
+int board_early_init_f(void)
{
struct s3c24x0_clock_power * const clk_power =
s3c24x0_get_base_clock_power();
struct s3c24x0_gpio * const gpio = s3c24x0_get_base_gpio();
/* to reduce PLL lock time, adjust the LOCKTIME register */
- clk_power-locktime = 0xFF;
+ writel(0xFF, clk_power-locktime);
/* configure MPLL */
- clk_power-mpllcon = ((M_MDIV 12) + (M_PDIV 4) + M_SDIV);
+ writel((M_MDIV 12) + (M_PDIV 4) + M_SDIV,
+ clk_power-mpllcon);
/* some delay between MPLL and UPLL */
- delay (4000);
+ pll_delay(4000);
/* configure UPLL */
- clk_power-upllcon = ((U_M_MDIV 12) + (U_M_PDIV 4) + U_M_SDIV);
+ writel((U_M_MDIV 12) + (U_M_PDIV 4) + U_M_SDIV,
+ clk_power-upllcon);
/* some delay between MPLL and UPLL */
- delay (8000);
+ pll_delay(8000);
/* set up the I/O ports */
- gpio-gpacon = 0x007F;
- gpio-gpbcon = 0x00044555;
- gpio-gpbup = 0x07FF;
- gpio-gpccon = 0x;
- gpio-gpcup = 0x;
- gpio-gpdcon = 0x;
- gpio-gpdup = 0x;
- gpio-gpecon = 0x;
- gpio-gpeup = 0x;
- gpio-gpfcon = 0x55AA;
- gpio-gpfup = 0x00FF;
- gpio-gpgcon = 0xFF95FFBA;
- gpio-gpgup = 0x;
- gpio-gphcon = 0x002AFAAA;
- gpio-gphup = 0x07FF;
+ writel(0x007F, gpio-gpacon);
+ writel(0x00044555, gpio-gpbcon);
+ writel(0x07FF, gpio-gpbup);
+ writel(0x, gpio-gpccon);
+ writel(0x, gpio-gpcup);
+ writel(0x, gpio-gpdcon);
+ writel(0x, gpio-gpdup);
+ writel(0x, gpio-gpecon);
+ writel(0x, gpio-gpeup);
+ writel(0x55AA, gpio-gpfcon);
+ writel(0x00FF, gpio-gpfup);
+ writel(0xFF95FFBA, gpio-gpgcon);
+ writel(0x, gpio-gpgup);
+ writel(0x002AFAAA, gpio-gphcon);
+ writel(0x07FF, gpio-gphup);
+
+ return 0;
+}
+int board_init(void)
+{
/* arch number of SMDK2410-Board */
gd-bd-bi_arch_number = MACH_TYPE_SMDK2410;
@@ -116,11 +124,10 @@ int board_init (void)
return 0;
}
-int dram_init (void)
+int dram_init(void)
{
- gd-bd-bi_dram[0].start = PHYS_SDRAM_1;
- gd-bd-bi_dram[0].size = PHYS_SDRAM_1_SIZE;
-
+ /* dram_init must store complete ramsize in gd-ram_size */
+ gd-ram_size = PHYS_SDRAM_1_SIZE;
return 0;
}
diff --git a/include/configs/smdk2410.h b/include/configs/smdk2410.h
index 88e7171..87a4a46 100644
--- a/include/configs/smdk2410.h
+++ b/include/configs/smdk2410.h
@@ -33,24 +33,23 @@
* High Level Configuration Options
* (easy to change)
*/
-#define CONFIG_ARM920T 1 /* This is an ARM920T Core */
-#define CONFIG_S3C24X0 1 /* in a SAMSUNG S3C24x0-type SoC*/
-#define CONFIG_S3C2410 1 /* specifically a SAMSUNG S3C2410 SoC */
-#define CONFIG_SMDK24101 /* on a SAMSUNG SMDK2410 Board */
+#define CONFIG_ARM920T /* This is an ARM920T Core */
+#define CONFIG_S3C24X0 /* in a SAMSUNG S3C24x0-type SoC*/
+#define CONFIG_S3C2410 /* specifically a SAMSUNG S3C2410 SoC */
+#define CONFIG_SMDK2410/* on a SAMSUNG SMDK2410 Board
*/
#define CONFIG_SYS_TEXT_BASE 0x0
-/* input clock of PLL */
-#define CONFIG_SYS_CLK_FREQ1200/* the SMDK2410 has 12MHz input clock */
+#define CONFIG_SYS_ARM_CACHE_WRITETHROUGH
+/* input clock of PLL (the SMDK2410 has 12MHz input clock) */
+#define CONFIG_SYS_CLK_FREQ1200
[U-Boot] [PATCH V4 3/4] use the CFI driver (and remove the old one)
Signed-off-by: David Müller d.muel...@elsoft.ch
---
board/samsung/smdk2410/Makefile |2 +-
board/samsung/smdk2410/flash.c| 433 -
board/samsung/smdk2410/smdk2410.c | 12 +
include/configs/smdk2410.h| 32 +--
4 files changed, 25 insertions(+), 454 deletions(-)
delete mode 100644 board/samsung/smdk2410/flash.c
diff --git a/board/samsung/smdk2410/Makefile b/board/samsung/smdk2410/Makefile
index bda8898..0afe1e2 100644
--- a/board/samsung/smdk2410/Makefile
+++ b/board/samsung/smdk2410/Makefile
@@ -25,7 +25,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).o
-COBJS := smdk2410.o flash.o
+COBJS := smdk2410.o
SOBJS := lowlevel_init.o
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
diff --git a/board/samsung/smdk2410/flash.c b/board/samsung/smdk2410/flash.c
deleted file mode 100644
index 132d752..000
--- a/board/samsung/smdk2410/flash.c
+++ /dev/null
@@ -1,433 +0,0 @@
-/*
- * (C) Copyright 2002
- * Sysgo Real-Time Solutions, GmbH www.elinos.com
- * Alex Zuepke a...@sysgo.de
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-
-#include common.h
-
-ulong myflush (void);
-
-
-#define FLASH_BANK_SIZEPHYS_FLASH_SIZE
-#define MAIN_SECT_SIZE 0x1/* 64 KB */
-
-flash_info_t flash_info[CONFIG_SYS_MAX_FLASH_BANKS];
-
-
-#define CMD_READ_ARRAY 0x00F0
-#define CMD_UNLOCK10x00AA
-#define CMD_UNLOCK20x0055
-#define CMD_ERASE_SETUP0x0080
-#define CMD_ERASE_CONFIRM 0x0030
-#define CMD_PROGRAM0x00A0
-#define CMD_UNLOCK_BYPASS 0x0020
-
-#define MEM_FLASH_ADDR1(*(volatile u16
*)(CONFIG_SYS_FLASH_BASE + (0x0555 1)))
-#define MEM_FLASH_ADDR2(*(volatile u16
*)(CONFIG_SYS_FLASH_BASE + (0x02AA 1)))
-
-#define BIT_ERASE_DONE 0x0080
-#define BIT_RDY_MASK 0x0080
-#define BIT_PROGRAM_ERROR 0x0020
-#define BIT_TIMEOUT0x8000 /* our flag */
-
-#define READY 1
-#define ERR 2
-#define TMO 4
-
-/*---
- */
-
-ulong flash_init (void)
-{
- int i, j;
- ulong size = 0;
-
- for (i = 0; i CONFIG_SYS_MAX_FLASH_BANKS; i++) {
- ulong flashbase = 0;
-
- flash_info[i].flash_id =
-#if defined(CONFIG_AMD_LV400)
- (AMD_MANUFACT FLASH_VENDMASK) |
- (AMD_ID_LV400B FLASH_TYPEMASK);
-#elif defined(CONFIG_AMD_LV800)
- (AMD_MANUFACT FLASH_VENDMASK) |
- (AMD_ID_LV800B FLASH_TYPEMASK);
-#else
-#error Unknown flash configured
-#endif
- flash_info[i].size = FLASH_BANK_SIZE;
- flash_info[i].sector_count = CONFIG_SYS_MAX_FLASH_SECT;
- memset (flash_info[i].protect, 0, CONFIG_SYS_MAX_FLASH_SECT);
- if (i == 0)
- flashbase = PHYS_FLASH_1;
- else
- panic (configured too many flash banks!\n);
- for (j = 0; j flash_info[i].sector_count; j++) {
- if (j = 3) {
- /* 1st one is 16 KB */
- if (j == 0) {
- flash_info[i].start[j] =
- flashbase + 0;
- }
-
- /* 2nd and 3rd are both 8 KB */
- if ((j == 1) || (j == 2)) {
- flash_info[i].start[j] =
- flashbase + 0x4000 + (j -
- 1) *
- 0x2000;
- }
-
- /* 4th 32 KB */
- if (j == 3) {
- flash_info[i].start[j] =
- flashbase + 0x8000;
- }
- } else {
-
Re: [U-Boot] [PATCH 1/2] ARM: MX31: print WRSR to indicate the source of the last reset
On Thu, 10 Mar 2011 16:07:49 +0100 Stefano Babic sba...@denx.de wrote: On 03/10/2011 11:53 AM, Anatolij Gustschin wrote: Add output of the WRSR register content while booting so that we can see the source of the last reset. Signed-off-by: Anatolij Gustschin ag...@denx.de Hi Antolij, Hi Stefano, ... + printf(CPU: Freescale i.MX31 at %d MHz (WRSR=0x%04x)\n, + mx31_get_mcu_main_clk() / 100, wdog-wrsr); Why is it better to use the wrsr register instead of the rcsr register ? We are actually using the rcsr register for other i.MX processors (MX51/MX53/MX35). And if we want to print the reset cause, I think it should be better to write directly the cause as string instead of the register value. The reason for using wrsr register is that when reading this register, we can also recognize the software reset cause (SWFT, bit 0 is set). In our use case we have this requirement. U-Boot and Linux for iMX31 assert system reset by clearing SRS bit in wcr. This software reset is reported by SWFT in the wrsr register. When I read rcsr after a software reset, I always get watchdog timeout reset cause (probably because the reset was performed by writing to the watchdog module register wcr). But actually this reset was a software reset. I'm fine with using strings for reset cause if there is no objection. I do not think printing the reset cause should be implemented in print_cpuinfo(), because it manages a different issue (reset cause against CPU information). The print_cpuinfo() should have only CPU related values, as clock values, and so on, as it is implemented now for this and other processors. Better to add a different function for the reset cause. Were should we call this different function? Should be put it into init_sequence[]? Best regards, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] MX31: mx31pdk: Print the cause of reset
On Wed, 9 Mar 2011 13:35:44 -0300
Fabio Estevam fabio.este...@freescale.com wrote:
...
+++ b/board/freescale/mx31pdk/mx31pdk.c
@@ -86,7 +86,30 @@ int board_late_init(void)
int checkboard(void)
{
- printf(Board: i.MX31 MAX PDK (3DS)\n);
+ u32 cause;
+ struct clock_control_regs *ccm =
+ (struct clock_control_regs *)CCM_BASE;
+ puts(Board: MX31PDK [);
+
+ cause = ccm-rcsr 0x03;
The mask should be 0x07, since ...
+ case 0x0006:
+ puts(JTAG);
+ break;
we check if bit 2 is set here.
Best regards,
Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 2/6] Mips: Purple: Adapt u-boot.lds to changed CPU directory layout
On 3/9/11 10:16 PM, daniel.schwierz...@googlemail.com wrote: This fixes a linker error introduced by the previous commit. If so, such fix should be made along with that previous commit. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/6] Mips: Move content of arch/mips/cpu to arch/mips/cpu/mips32
On 3/9/11 10:16 PM, daniel.schwierz...@googlemail.com wrote: All current CPUs and SoCs are based on Mips32 arch. The complete Is that true? What about purple SoC? IIUC It's based on MIPS 5Kc and capable of 64-bit, which MIPS32 is 32-bit only architecture. code resides in the global arch/mips/cpu directory. This is not suitable if other Mips architectures like Mips64 or Octeon should be supported in the future. Just for the record. Personally, Octeon is sort of a special case. It's based on MIPS64 architecture, and definitely a MIPS SoC, but not usual MIPS machine. As Aaron already mentioned before, we have very few files sharable with other MIPS machines even in the Linux kernel case. I think it will take long time the Octeon port gets merged to upstream, regard- less of my opinions, because they have a lot of things need to be resolved prior to Octeon itself. To achieve this the current CPU code is moved to its own mips32 subdirectory. All Mips32 boards have to use mips32 as config switch in board.cfg. Signed-off-by: Daniel Schwierzeckdaniel.schwierz...@googlemail.com Cc: Shinya Kuribayashiskuri...@pobox.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/6] Mips: Refactoring of CPU and SoC code
On 3/9/11 10:16 PM, daniel.schwierz...@googlemail.com wrote: This patch series refactors the Mips CPU directory and put all current code into an own mips32 subdirectory. Furthermore the SoC specific code of IncaIP, Purple and Au1x00 is moved to separate SoC subdirectories. Personally I'm not a big fan of current arch/arch/cpu/ directory usages in the U-Boot tree. But that's a matter of personal preference, and I've already ended up regarding this area a few years ago. Not having strong opinions now. When they get ready for merge, please let me know. Then I'll queue them up for the next release, thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/6] Mips: Refactoring of CPU and SoC code
By the way, please use MIPS: next time, not Mips: Thanks in advance, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] p4080ds starts OS with MSR[EE]=1 and DEC armed?
On Mar 3, 2011, at 8:59 AM, Jimi Xenidis wrote: I was surprised to find myself at the decrement interrupt when running my new stuff. That is against ePAPR, right? Does u-boot at least make sure that the DEC is set to some large value before it leaps at me? I don't mind forcing EE=0 but I'd like to make sure I make it that far into the code :) -JX Jimi, Not sure how or why you are seeing this, but u-boot should disable interrupts in common/cmd_bootm.c Look for disable_interrupts() - this should set MSR[EE] = 0. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/6] Mips: Move content of arch/mips/cpu to arch/mips/cpu/mips32
Hi Shinya,
On 03/12/2011 03:43 PM, Shinya Kuribayashi wrote:
On 3/9/11 10:16 PM, daniel.schwierz...@googlemail.com wrote:
All current CPUs and SoCs are based on Mips32 arch. The complete
Is that true? What about purple SoC? IIUC It's based on MIPS 5Kc
and capable of 64-bit, which MIPS32 is 32-bit only architecture.
that was an assumption. I could not find any information about Purple.
This patch series is a suggestion. Maybe there are better approaches
like arch/mips/cpu/{mips4k|mips5k|mips24k|...|octeon}.
code resides in the global arch/mips/cpu directory. This is not
suitable if other Mips architectures like Mips64 or Octeon should
be supported in the future.
Just for the record.
Personally, Octeon is sort of a special case. It's based on MIPS64
architecture, and definitely a MIPS SoC, but not usual MIPS machine.
As Aaron already mentioned before, we have very few files sharable
with other MIPS machines even in the Linux kernel case. I think it
will take long time the Octeon port gets merged to upstream, regard-
less of my opinions, because they have a lot of things need to be
resolved prior to Octeon itself.
My original intention was cleaning up the MIPS CPU directory as
preparation to support new SoCs. I included this patch because Aaron
asked for this separation some weeks ago but no one answered or commented ;)
However I posted this series to get some feedback if such a change is
wanted or acceptable. If so I prepare a new patch series. At least I
hope the SoC separation is acceptable.
Cheers,
Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
