Re: [U-Boot] OpenRD-{Client,Ultimate}
Hi Clint, Le 25/03/2011 03:21, Clint Adams a écrit : > What is the status of the OpenRD-Ultimate support discussed last summer? AFAIK, there were patch proposals but no final patch. Feel free to look up the list archives, find the last post and bump the topic up by responding to it, Cc:ing relevant U-boot tree maintainers and the patch submitter; if there wasn't, then try to ping the submitter. > Is there no way to detect the board type and use a single U-Boot image for > all three variants? We might be going there eventually; for the moment, let us support those variants with a 'common plus board-specific config files' approach. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-samsung/master
Le 25/03/2011 03:02, Minkyu Kang a écrit : > Dear Albert ARIBAUD, > > 2011-03-24 오후 10:57, Albert ARIBAUD 쓴 글: >> Le 24/03/2011 07:58, Minkyu Kang a écrit : >>> Dear Albert Aribaud, >>> >>> The following changes since commit 966a35d45b90fdcd694dec89b32e5b67771cfd64: >>> >>> Merge branch 'master' of git://git.denx.de/u-boot-arm (2011-02-16 >>> 08:54:52 +0900) >>> >>> are available in the git repository at: >>> >>> git://git.denx.de/u-boot-samsung master >> >> This does not seem to have been rebased to u-boot or u-boot-arm. Can you >> check? >> > Two files are both modified. > > board/samsung/smdk6400/u-boot-nand.lds > nand_spl/board/samsung/smdk6400/u-boot.lds > > modified by commit id 79f062e749d9277f89686c3948520dd8d0aab501 on u-boot-arm, > commit id 9fc36d1b4492f792617f3947bdf8cea74f236139 and > 4b7100ec4c1cedd968d3acab58de5f209b7c8bf7, > 9e88e50216279f95d7a974ac0b60907fbee1a2d4 > on u-boot-samsung. > > Hm, how we can solve it? > If possible, could you please merge it manually? There are several other merge conflict in this rebase; some appear trivial, some not, and when I try to rebase u-boot-samsung/master onto u-boot-arm/master I don't hit the same merge conflict as you do. Can you please confirm which commit ID is at the tip of your current branch when you do the rebase, and which commit ID you are rebasing to? > Thanks > Minkyu Kang. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V6 2/4] SMDK2410: remove unneeded config.mk
Signed-off-by: David Müller --- 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, -# David Mueller, ELSOFT AG, -# -# 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 17038f5..e7f9164 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 V6 3/4] SMDK2410: use the CFI driver (and remove the old one)
Signed-off-by: David Müller
---
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
- * Alex Zuepke
- *
- * 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
-
-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 {
- flash_info[i].start[j] =
-
[U-Boot] [PATCH V6 1/4] SMDK2410: activate ARM relocation feature
Signed-off-by: David Müller --- include/configs/smdk2410.h |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/include/configs/smdk2410.h b/include/configs/smdk2410.h index 62fe97e..17038f5 100644 --- a/include/configs/smdk2410.h +++ b/include/configs/smdk2410.h @@ -179,4 +179,10 @@ #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 */ +#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 V6 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 - various cleanups/code style fixes --- 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| 181 ++-- 5 files changed, 166 insertions(+), 548 deletions(-) Changes for V2: - deleted config.mk Changes for V3: - adjusted patch meta info Changes for V4: - split patch into smaller pieces Changes for V5: - prefix patches with SMDK2410 - additional tabulator cleanup in smdk2410.h Changes for V6: - remove unneeded #undef CONFIG_SYS_ARM_WITHOUT_RELOC in smdk2410.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V6 4/4] SMDK2410: various cleanup/code style fixes
Signed-off-by: David Müller
---
board/samsung/smdk2410/smdk2410.c | 61 +---
include/configs/smdk2410.h| 145 ++---
2 files changed, 135 insertions(+), 71 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
* Marius Groeger
*
- * (C) Copyright 2002
+ * (C) Copyright 2002, 2010
* David Mueller, ELSOFT AG,
*
* See file CREDITS for list of people who contributed to this
@@ -27,6 +27,7 @@
#include
#include
+#include
#include
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 102488f..a4a675b 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
-#define USE_920T_MMU 1
-#undef CONFIG_USE_IRQ
Re: [U-Boot] [PATCH] ftsmc020: enhance for features and asm support.
Hi Wolfgnag
> In message
> <1300965924-20508-1-git-send-email-macp...@andestech.com> you wrote:
> > 1. Enhance ftsmc020 according to datasheets.
> > 2. Add assembly register offsets for support lowlevel_init.S.
>
> NAK. Such register offsets should be automatically generated from the
> respective C structs using make-asm-offsets; see the
> generic-asm-offsets.h / asm-offsets.s build rules in the top level
> Makefile.
>
Neither I ran the command
"tools/scripts/make-asm-offsets include/faraday/ftsmc020.h
include/faraday/ftsmc020-genasm.h"
nor I ran
sed -ne "/^->/{s:->#\(.*\):/* \1 */:; \
s:^->\([^ ]*\) [\$#]*\([-0-9]*\) \(.*\):#define \1 (\2) /* \3 */:; \
s:^->\([^ ]*\) [\$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; \
s:->::; p;}" include/faraday/ftsmc020-genasm.h could be work.
I also tested file faraday/ftpmu010.h.
It get the same output with output 'sed: -e expression #1, char 47: unknown
command: `['.'
Did I execute the script in wrong method? Is there a problem about this script?
Moreover, the structure of ftsmc020 was nested like
struct ftsmc020 {
struct {
unsigned intcr; /* 0x00, 0x08, 0x10, 0x18 */
unsigned inttpr;/* 0x04, 0x0c, 0x14, 0x1c */
} bank[4];
unsigned intpad[8]; /* 0x20 - 0x3c */
unsigned intssr;/* 0x40 */
};
I didn't see the sed script could support this kind of nested structure
declaration.
I guess the sed script could be applied to plain structure declareation.
Maybe I have a diffcult here.
If the script is needed to be rewrote to adapt nested declaration,
It might need have some complicaticity about parse difference kind of nested
structure and array.
It seems I need to rewrite the structure to be adaptable to the sed script.
Any suggestion?
Best regards,
Macpaul Lin
CONFIDENTIALITY NOTICE:
This e-mail (and its attachments) may contain confidential and legally
privileged information or information protected from disclosure. If you are not
the intended recipient, you are hereby notified that any disclosure, copying,
distribution, or use of the information contained herein is strictly
prohibited. In this case, please immediately notify the sender by return
e-mail, delete the message (and any accompanying documents) and destroy all
printed hard copies. Thank you for your cooperation.
Copyright ANDES TECHNOLOGY CORPORATION - All Rights Reserved.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/4] Kirkwood: Add support for OpenRD-Client & OpenRD-Ultimate
From: Julian Pidancet
This patch modifies existing OpenRD-Base support to deal with all
the three OpenRD boards (OpenRD-Base, OpenRD-Client & OpenRD-Ultimate).
This is based on an original patch sent by Tanmay Upadhyay. Most of the
credits goes to him.
Previous version of this patch has been reworked to separate file renaming
from the actual addition of Client and Ultimate variants support.
A nice future improvement would be to add variant detection and configuration
at run-time as suggested on the mailing-list in a recent email. So one could
use the same binary for all board variants.
Julian Pidancet (4):
Kirkwood: Rename openrd_base board files to openrd.
Change OpenRD Base board identification string.
Add support for the Client variant of the OpenRD board.
Add support for the Ultimate variant of the OpenRD board
MAKEALL|2 +
board/Marvell/{openrd_base => openrd}/Makefile |2 +-
board/Marvell/{openrd_base => openrd}/kwbimage.cfg |0
.../{openrd_base/openrd_base.c => openrd/openrd.c} | 28 -
.../{openrd_base/openrd_base.h => openrd/openrd.h} |6 +-
boards.cfg |4 +-
include/configs/openrd.h | 107
include/configs/openrd_base.h | 85 ++--
include/configs/openrd_client.h| 44
include/configs/openrd_ultimate.h | 44
10 files changed, 235 insertions(+), 87 deletions(-)
rename board/Marvell/{openrd_base => openrd}/Makefile (98%)
rename board/Marvell/{openrd_base => openrd}/kwbimage.cfg (100%)
rename board/Marvell/{openrd_base/openrd_base.c => openrd/openrd.c} (83%)
rename board/Marvell/{openrd_base/openrd_base.h => openrd/openrd.h} (95%)
create mode 100644 include/configs/openrd.h
create mode 100644 include/configs/openrd_client.h
create mode 100644 include/configs/openrd_ultimate.h
--
Julian Pidancet
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/4] Kirkwood: Rename openrd_base board files to openrd.
From: Julian Pidancet
This patch renames openrd_base to openrd in order to add support for
other boards of the OpenRD family in future commits. The openrd_base
board name remain in use.
Signed-off-by: Julian Pidancet
rename board/Marvell/{openrd_base => openrd}/Makefile (98%)
rename board/Marvell/{openrd_base => openrd}/kwbimage.cfg (100%)
rename board/Marvell/{openrd_base/openrd_base.c => openrd/openrd.c} (97%)
rename board/Marvell/{openrd_base/openrd_base.h => openrd/openrd.h} (95%)
create mode 100644 include/configs/openrd.h
diff --git a/board/Marvell/openrd_base/Makefile b/board/Marvell/openrd/Makefile
similarity index 98%
rename from board/Marvell/openrd_base/Makefile
rename to board/Marvell/openrd/Makefile
index d6d0ed3..19020e4 100644
--- a/board/Marvell/openrd_base/Makefile
+++ b/board/Marvell/openrd/Makefile
@@ -31,7 +31,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).o
-COBJS := openrd_base.o
+COBJS := openrd.o
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
diff --git a/board/Marvell/openrd_base/kwbimage.cfg
b/board/Marvell/openrd/kwbimage.cfg
similarity index 100%
rename from board/Marvell/openrd_base/kwbimage.cfg
rename to board/Marvell/openrd/kwbimage.cfg
diff --git a/board/Marvell/openrd_base/openrd_base.c
b/board/Marvell/openrd/openrd.c
similarity index 97%
rename from board/Marvell/openrd_base/openrd_base.c
rename to board/Marvell/openrd/openrd.c
index 10109c1..b395df7 100644
--- a/board/Marvell/openrd_base/openrd_base.c
+++ b/board/Marvell/openrd/openrd.c
@@ -31,7 +31,7 @@
#include
#include
#include
-#include "openrd_base.h"
+#include "openrd.h"
DECLARE_GLOBAL_DATA_PTR;
@@ -110,7 +110,7 @@ int board_init(void)
/*
* arch number of board
*/
- gd->bd->bi_arch_number = MACH_TYPE_OPENRD_BASE;
+ gd->bd->bi_arch_number = MACH_TYPE_OPENRD;
/* adress of boot parameters */
gd->bd->bi_boot_params = kw_sdram_bar(0) + 0x100;
diff --git a/board/Marvell/openrd_base/openrd_base.h
b/board/Marvell/openrd/openrd.h
similarity index 95%
rename from board/Marvell/openrd_base/openrd_base.h
rename to board/Marvell/openrd/openrd.h
index f3daf17..638d2ff 100644
--- a/board/Marvell/openrd_base/openrd_base.h
+++ b/board/Marvell/openrd/openrd.h
@@ -27,8 +27,8 @@
* MA 02110-1301 USA
*/
-#ifndef __OPENRD_BASE_H
-#define __OPENRD_BASE_H
+#ifndef __OPENRD_H
+#define __OPENRD_H
#define OPENRD_OE_LOW (~(1<<28))/* RS232 / RS485 */
#define OPENRD_OE_HIGH (~(1<<2)) /* SD / UART1 */
@@ -43,4 +43,4 @@
#define MV88E1116_RGMII_TXTM_CTRL (1 << 4)
#define MV88E1116_RGMII_RXTM_CTRL (1 << 5)
-#endif /* __OPENRD_BASE_H */
+#endif /* __OPENRD_H */
diff --git a/boards.cfg b/boards.cfg
index 45c3102..07c904b 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -96,7 +96,7 @@ davinci_sonata arm arm926ejs sonata
davinci
suen3arm arm926ejs km_arm
keymilekirkwood
guruplug arm arm926ejs -
Marvellkirkwood
mv88f6281gtw_ge arm arm926ejs -
Marvellkirkwood
-openrd_base arm arm926ejs -
Marvellkirkwood
+openrd_base arm arm926ejs openrd
Marvellkirkwood
rd6281a arm arm926ejs -
Marvellkirkwood
sheevaplug arm arm926ejs -
Marvellkirkwood
dockstar arm arm926ejs -
Seagatekirkwood
diff --git a/include/configs/openrd.h b/include/configs/openrd.h
new file mode 100644
index 000..d7973dc
--- /dev/null
+++ b/include/configs/openrd.h
@@ -0,0 +1,107 @@
+/*
+ * (C) Copyright 2009
+ * Net Insight
+ * Written-by: Simon Kagstrom
+ *
+ * Based on sheevaplug.h:
+ * (C) Copyright 2009
+ * Marvell Semiconductor
+ * Written-by: Prafulla Wadaskar
+ *
+ * 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., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#ifndef _CONFIG_OPENRD_H
+#define _CONFIG_OPENRD_H
+
+/*
+ *
[U-Boot] [PATCH v2 2/4] Change OpenRD Base board identification string.
From: Julian Pidancet Renamed from "Openrd_base" to "OpenRD-Base" Signed-off-by: Julian Pidancet diff --git a/include/configs/openrd_base.h b/include/configs/openrd_base.h index 136d3bf..ba57d90 100644 --- a/include/configs/openrd_base.h +++ b/include/configs/openrd_base.h @@ -35,7 +35,7 @@ /* * Version number information */ -#define CONFIG_IDENT_STRING"\nOpenRD_base" +#define CONFIG_IDENT_STRING"\nOpenRD-Base" /* Machine type */ #define MACH_TYPE_OPENRD MACH_TYPE_OPENRD_BASE -- Julian Pidancet ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/4] Add support for the Client variant of the OpenRD board.
From: Julian Pidancet
This patch takes care of initializing the second PHY of the
OpenRD board.
Signed-off-by: Julian Pidancet
create mode 100644 include/configs/openrd_client.h
diff --git a/MAKEALL b/MAKEALL
index a732e6a..ddf4a70 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -361,6 +361,7 @@ LIST_ARM9=" \
omap5912osk \
omap730p2 \
openrd_base \
+ openrd_client \
rd6281a \
sbc2410x\
scb9328 \
diff --git a/board/Marvell/openrd/openrd.c b/board/Marvell/openrd/openrd.c
index b395df7..fded3f0 100644
--- a/board/Marvell/openrd/openrd.c
+++ b/board/Marvell/openrd/openrd.c
@@ -118,12 +118,11 @@ int board_init(void)
}
#ifdef CONFIG_RESET_PHY_R
-/* Configure and enable MV88E1116 PHY */
-void reset_phy(void)
+/* Configure and enable MV88E1116/MV88E1121 PHY */
+void mv_phy_init(char *name)
{
u16 reg;
u16 devadr;
- char *name = "egiga0";
if (miiphy_set_current_dev(name))
return;
@@ -150,4 +149,19 @@ void reset_phy(void)
printf("88E1116 Initialized on %s\n", name);
}
+
+void reset_phy(void)
+{
+ mv_phy_init("egiga0");
+
+#if (MACH_TYPE_OPENRD == MACH_TYPE_OPENRD_CLIENT)
+ /* Kirkwood ethernet driver is written with the assumption that in case
+* of multiple PHYs, their addresses are consecutive. But unfortunately
+* in case of OpenRD-Client, PHY addresses are not consecutive.*/
+ miiphy_write("egiga1", 0xEE, 0xEE, 24);
+
+ /* configure and initialize both PHY's */
+ mv_phy_init("egiga1");
+#endif
+}
#endif /* CONFIG_RESET_PHY_R */
diff --git a/boards.cfg b/boards.cfg
index 07c904b..5f5d2bf 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -97,6 +97,7 @@ suen3arm arm926ejs km_arm
keymile
guruplug arm arm926ejs -
Marvellkirkwood
mv88f6281gtw_ge arm arm926ejs -
Marvellkirkwood
openrd_base arm arm926ejs openrd
Marvellkirkwood
+openrd_clientarm arm926ejs openrd
Marvellkirkwood
rd6281a arm arm926ejs -
Marvellkirkwood
sheevaplug arm arm926ejs -
Marvellkirkwood
dockstar arm arm926ejs -
Seagatekirkwood
diff --git a/include/configs/openrd_client.h b/include/configs/openrd_client.h
new file mode 100644
index 000..1ffc29f
--- /dev/null
+++ b/include/configs/openrd_client.h
@@ -0,0 +1,44 @@
+/*
+ * 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., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#ifndef _CONFIG_OPENRD_CLIENT_H
+#define _CONFIG_OPENRD_CLIENT_H
+
+#include
+
+/*
+ * Version number information
+ */
+#define CONFIG_IDENT_STRING"\nOpenRD-Client"
+
+/* Machine type */
+#define MACH_TYPE_OPENRD MACH_TYPE_OPENRD_CLIENT
+
+/*
+ * Ethernet Driver configuration
+ */
+#ifdef CONFIG_CMD_NET
+/* enable both ports */
+#define CONFIG_MVGBE_PORTS {1, 1}
+#define CONFIG_PHY_BASE_ADR 0x8
+#define PHY_NO "88E1116"
+#endif /* CONFIG_CMD_NET */
+
+#endif /* _CONFIG_OPENRD_CLIENT_H */
--
Julian Pidancet
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/4] Add support for the Ultimate variant of the OpenRD board
From: Julian Pidancet
This patch adds proper initialization code for the two PHYs
present on the board.
Signed-off-by: Julian Pidancet
create mode 100644 include/configs/openrd_ultimate.h
diff --git a/MAKEALL b/MAKEALL
index ddf4a70..4b6da98 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -362,6 +362,7 @@ LIST_ARM9=" \
omap730p2 \
openrd_base \
openrd_client \
+ openrd_ultimate \
rd6281a \
sbc2410x\
scb9328 \
diff --git a/board/Marvell/openrd/openrd.c b/board/Marvell/openrd/openrd.c
index fded3f0..d1b2554 100644
--- a/board/Marvell/openrd/openrd.c
+++ b/board/Marvell/openrd/openrd.c
@@ -147,7 +147,7 @@ void mv_phy_init(char *name)
/* reset the phy */
miiphy_reset(name, devadr);
- printf("88E1116 Initialized on %s\n", name);
+ printf(PHY_NO" Initialized on %s\n", name);
}
void reset_phy(void)
@@ -162,6 +162,8 @@ void reset_phy(void)
/* configure and initialize both PHY's */
mv_phy_init("egiga1");
+#elif (MACH_TYPE_OPENRD == MACH_TYPE_OPENRD_ULTIMATE)
+ mv_phy_init("egiga1");
#endif
}
#endif /* CONFIG_RESET_PHY_R */
diff --git a/boards.cfg b/boards.cfg
index 5f5d2bf..513aa04 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -98,6 +98,7 @@ guruplug arm arm926ejs -
Marvell
mv88f6281gtw_ge arm arm926ejs -
Marvellkirkwood
openrd_base arm arm926ejs openrd
Marvellkirkwood
openrd_clientarm arm926ejs openrd
Marvellkirkwood
+openrd_ultimate arm arm926ejs openrd
Marvellkirkwood
rd6281a arm arm926ejs -
Marvellkirkwood
sheevaplug arm arm926ejs -
Marvellkirkwood
dockstar arm arm926ejs -
Seagatekirkwood
diff --git a/include/configs/openrd_ultimate.h
b/include/configs/openrd_ultimate.h
new file mode 100644
index 000..b616d6a
--- /dev/null
+++ b/include/configs/openrd_ultimate.h
@@ -0,0 +1,44 @@
+/*
+ * 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., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#ifndef _CONFIG_OPENRD_ULTIMATE_H
+#define _CONFIG_OPENRD_ULTIMATE_H
+
+#include
+
+/*
+ * Version number information
+ */
+#define CONFIG_IDENT_STRING"\nOpenRD-Ultimate"
+
+/* Machine type */
+#define MACH_TYPE_OPENRD MACH_TYPE_OPENRD_ULTIMATE
+
+/*
+ * Ethernet Driver configuration
+ */
+#ifdef CONFIG_CMD_NET
+/* enable both ports */
+#define CONFIG_MVGBE_PORTS {1, 1}
+#define CONFIG_PHY_BASE_ADR 0x0
+#define PHY_NO "88E1121"
+#endif /* CONFIG_CMD_NET */
+
+#endif /* _CONFIG_OPENRD_ULTIMATE_H */
--
Julian Pidancet
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ftsmc020: enhance for features and asm support.
Dear macp...@andestech.com,
In message <50fd90c65c53fb45badeebcd84ff07f202ec0...@atcpcs06.andestech.com>
you wrote:
> >
> Neither I ran the command
>
> "tools/scripts/make-asm-offsets include/faraday/ftsmc020.h
> include/faraday/ftsmc020-genasm.h"
> nor I ran
> sed -ne "/^->/{s:->#\(.*\):/* \1 */:; \
> s:^->\([^ ]*\) [\$#]*\([-0-9]*\) \(.*\):#define \1 (\2) /* \3 */:; \
> s:^->\([^ ]*\) [\$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; \
> s:->::; p;}" include/faraday/ftsmc020-genasm.h could be work.
>
> I also tested file faraday/ftpmu010.h.
> It get the same output with output 'sed: -e expression #1, char 47:
> unknown command: `['.'
> Did I execute the script in wrong method? Is there a problem about this
> script?
There is no (known) problem with it, but you have to be careful about
the context you are running in - the script as is is supposed to be
run in "make" context, which means different $ expansion rules then
when you try running directly under a shell.
> Moreover, the structure of ftsmc020 was nested like
> struct ftsmc020 {
> struct {
> unsigned intcr; /* 0x00, 0x08, 0x10, 0x18 */
> unsigned inttpr;/* 0x04, 0x0c, 0x14, 0x1c */
> } bank[4];
> unsigned intpad[8]; /* 0x20 - 0x3c */
> unsigned intssr;/* 0x40 */
> };
>
> I didn't see the sed script could support this kind of nested structure
> declaration.
> I guess the sed script could be applied to plain structure declareation.
> Maybe I have a diffcult here.
You could simply un-nest the structure declarations.
> If the script is needed to be rewrote to adapt nested declaration,
> It might need have some complicaticity about parse difference kind of
> nested structure and array.
If I were in your situation I'd probably rather unnest the structs.
> It seems I need to rewrite the structure to be adaptable to the sed
> script.
That seems straightforward to do, indeed.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"Whoever undertakes to set himself up as a judge of Truth and Know-
ledge is shipwrecked by the laughter of the gods." - Albert Einstein
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 7/7] modify files for ben nanonote board
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/15/2011 11:16 AM, Shinya Kuribayashi wrote: > You added targets with the same name to two places. In this case, > boards.cfg will be used to configure qi_lb60. All MIPS targets can > be configured through boards.cfg now, so please 1) remove $(TOPDIR)/ > Makefile part, and 2) get 'qi_lb60' entry work as expected, instead. thanks for the info. fixed. send the patches later today - -- Best Regards Xiangfu Liu http://www.openmobilefree.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2MWxQACgkQRRAEFRxkgLTE8ACgw1I/fOPkebQqzknd7uLqRzRn WlMAn277HMxQbepuRM2uArCns7hVodD8 =iibd -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 4/7] jz4740 nand driver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/08/2011 07:44 AM, Scott Wood wrote: > You don't set nand->options... > > Don't you want a bad block table? > hmm... some question. a little confuse. 1. I using all rest of nand as rootfs partition. do I have keep some space in nand for BBT? 2. do I have to tell u-boot where is the BBT? 3. do I need some configure in linux kernel for BBT? - -- Best Regards Xiangfu Liu http://www.openmobilefree.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2MXZ0ACgkQRRAEFRxkgLTxoACePzD7G02iYng9GEHkbEWw4Ndk 6tgAn26gxUBbZK+hVJQSqnpL15GafZcA =bIOO -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-samsung/master
Dear Albert ARIBAUD, I rebased u-boot-samsung/master. Please pull. The following changes since commit be7e8b604c88a2f85fbc25e383ba8fa83a5fe71c: Merge branch 'master' of git://git.denx.de/u-boot-arm into arm (2011-03-25 17:32:46 +0900) are available in the git repository at: git://git.denx.de/u-boot-samsung master Chander Kashyap (2): ARMV7: S5P: Fixed register offset in mmc.h S5P: mmc: Resolved interrupt error during mmc_init Donghwa Lee (1): ARM: S5P: pwm driver support Minkyu Kang (5): S5P: timer: Use pwm functions S5P: smdkc100: Enable the pwm driver S5P: goni: Enable the pwm driver S5P: universal: Enable the pwm driver S5P: timer: replace bss variable by gd seedshope (6): SMDK6400: Fix CONFIG_SYS_INIT_SP_ADDR undefined SMDK6400: Fix some label undefined in build error SMDK6400: Fix the mutiple link error SMDK6400: Add some labels to u-boot.lds to support nand_spl SMDK6400: Disable LED function in start.s on the nand booting SMDK6400: Fixup dram_init for relocation support arch/arm/cpu/arm1176/start.S |2 + arch/arm/cpu/armv7/s5p-common/Makefile |1 + arch/arm/cpu/armv7/s5p-common/pwm.c| 189 arch/arm/cpu/armv7/s5p-common/timer.c | 76 +++- arch/arm/include/asm/arch-s5pc1xx/mmc.h|5 +- arch/arm/include/asm/arch-s5pc1xx/pwm.h| 23 +++- arch/arm/include/asm/arch-s5pc2xx/mmc.h|5 +- arch/arm/include/asm/arch-s5pc2xx/pwm.h| 23 +++- board/samsung/smdk6400/smdk6400.c |8 +- board/samsung/smdk6400/u-boot-nand.lds | 28 - drivers/mmc/s5p_mmc.c |2 +- include/configs/s5p_goni.h |3 + include/configs/s5pc210_universal.h|3 + include/configs/smdk6400.h |5 + include/configs/smdkc100.h |3 + include/pwm.h | 31 + nand_spl/board/samsung/smdk6400/u-boot.lds | 17 +++- 17 files changed, 344 insertions(+), 80 deletions(-) create mode 100644 arch/arm/cpu/armv7/s5p-common/pwm.c create mode 100644 include/pwm.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx53loco: set mmc env to MMC slot1
On 03/22/2011 08:45 AM, Jason Liu wrote: > mx53loco board has two MMC slots, one is for MicroSD, > the other one is for normal SD, but the final board > design is to only boot from MicroSD. So, make the mmc > env default to slot1(MicroSD slot) > > Signed-off-by: Jason Liu > --- Applied to u-boot-imx, next branch, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OpenRD-{Client,Ultimate}
> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
> On Behalf Of Albert ARIBAUD
> Sent: Friday, March 25, 2011 12:33 PM
> To: Clint Adams
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] OpenRD-{Client,Ultimate}
>
> Hi Clint,
>
> Le 25/03/2011 03:21, Clint Adams a écrit :
> > What is the status of the OpenRD-Ultimate support discussed last
> summer?
>
> AFAIK, there were patch proposals but no final patch. Feel free to look
> up the list archives, find the last post and bump the topic up by
> responding to it, Cc:ing relevant U-boot tree maintainers and the patch
> submitter; if there wasn't, then try to ping the submitter.
Today I received new patches from Julian, This is a good start point, Let's
review them.
Regards..
Prafulla . .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] (no subject)
I have a foundation/Estate uncompleted {valued at USD 2,142,728.00} and need
you to help me finish it because of my health, Everything is available. Please
contact me for more details thank
you.(elizabeth.stev...@admin.in.th).
E-MAIL CONFIDENTIALITY NOTICE:
The information transmitted in this electronic message may be legally privileged
and confidential under applicable law, including the Family Educational Rights
and
Privacy Act (FERPA) and the Health Insurance Portability and Accountability Act
(HIPAA), and is intended only for the person or entity to which it is
addressed. If the
recipient of this message is not the above named intended recipient, you are
hereby
notified that any review, retransmission, dissemination, copy, disclosure or
other use of,
or taking any action in reliance upon, this information by persons or entities
other than
the intended recipient is prohibited. If you received this electronic
transmission in error,
please notify the Bethel Park School District at (412) 854-8402, and purge the
communication immediately from any computers, storage devices, paper or other
media
without making any copy or distribution thereof. Thank you for your cooperation.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH] arm: provide a CONFIG flag for disabling relocation
Relocation may not be needed and desirable in many cases:
* For many boards the amount of SDRAM is fixed.
So relocation is not needed.
* Relocation adds un-necessary additional overhead when
it's not needed. This delay is singificant on slower
platforms such as FPGA
* Many boards have ample memory. So reserving enough memory
for Linux in the first half is not a challenge even without
relocation
Add a CONFIG option to disable relocation on platforms that
do not need it. When this flag is enabled allocate memory
for stack heap etc at the end of memory as usual, but U-Boot
itself is not moved from TEXT_BASE.
Additionally, -pie is removed from the final link step because
it was causing the absolute value of all symbols coming from
the linker script to be 0. This affects find_cmd()
Tested on OMAP4430 SDP
Cc: Albert Aribaud
Cc: Wolfgang Denk
Signed-off-by: Aneesh V
---
arch/arm/config.mk |2 ++
arch/arm/lib/board.c|5 +
board/ti/sdp4430/config.mk |9 +++--
include/configs/omap4_sdp4430.h |2 ++
4 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 1785e73..2315bcb 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -71,5 +71,7 @@ LDSCRIPT := $(SRCTREE)/$(CPUDIR)/u-boot.lds
# needed for relocation
ifndef CONFIG_NAND_SPL
+ifndef CONFIG_SYS_SKIP_ARM_RELOCATION
LDFLAGS_u-boot += -pie
endif
+endif
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 72ee108..ed3898f 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -361,6 +361,7 @@ void board_init_f (ulong bootflag)
gd->fb_base = addr;
#endif /* CONFIG_LCD */
+#ifndef CONFIG_SYS_SKIP_ARM_RELOCATION
/*
* reserve memory for U-Boot code, data & bss
* round down to next 4 kB limit
@@ -369,6 +370,7 @@ void board_init_f (ulong bootflag)
addr &= ~(4096 - 1);
debug ("Reserving %ldk for U-Boot at: %08lx\n", gd->mon_len >> 10,
addr);
+#endif
#ifndef CONFIG_PRELOADER
/*
@@ -420,6 +422,9 @@ void board_init_f (ulong bootflag)
dram_init_banksize();
display_dram_config(); /* and display it */
+#ifdef CONFIG_SYS_SKIP_ARM_RELOCATION
+ addr = _TEXT_BASE;
+#endif
gd->relocaddr = addr;
gd->start_addr_sp = addr_sp;
gd->reloc_off = addr - _TEXT_BASE;
diff --git a/board/ti/sdp4430/config.mk b/board/ti/sdp4430/config.mk
index c62965d..8846732 100644
--- a/board/ti/sdp4430/config.mk
+++ b/board/ti/sdp4430/config.mk
@@ -28,5 +28,10 @@
# Linux-Kernel is expected to be at 8000'8000, entry 8000'8000
# (mem base + reserved)
-# 1MB into the SDRAM to allow for SPL's bss at the beginning of SDRAM
-CONFIG_SYS_TEXT_BASE = 0x8010
+# 64MB into the SDRAM
+# Assuming a minimum of 128 MB on the board:
+# - 64MB before U-Boot is more than enough for Linux when relocation is
+# disabled
+# - ~63MB after the U-Boot is more than enough for U-Boot to relocate
+# itself without stepping on itself
+CONFIG_SYS_TEXT_BASE = 0x8400
diff --git a/include/configs/omap4_sdp4430.h b/include/configs/omap4_sdp4430.h
index fff67d8..e9f76d3 100644
--- a/include/configs/omap4_sdp4430.h
+++ b/include/configs/omap4_sdp4430.h
@@ -278,4 +278,6 @@
#define CONFIG_SYS_SPL_BSS_MAX_SIZE0x8 /* 512 KB */
#define CONFIG_SYS_THUMB_BUILD
+
+#define CONFIG_SYS_SKIP_ARM_RELOCATION
#endif /* __CONFIG_H */
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] arm: provide a CONFIG flag for disabling relocation
Forgot to mention that this patch depends on my previous series for MMC
spl:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/96352
This one was anyway intended to initiate the discussion. If approved,
I shall create a cleaner patch.
On Friday 25 March 2011 06:42 PM, Aneesh V wrote:
> Relocation may not be needed and desirable in many cases:
> * For many boards the amount of SDRAM is fixed.
> So relocation is not needed.
> * Relocation adds un-necessary additional overhead when
> it's not needed. This delay is singificant on slower
> platforms such as FPGA
> * Many boards have ample memory. So reserving enough memory
> for Linux in the first half is not a challenge even without
> relocation
>
> Add a CONFIG option to disable relocation on platforms that
> do not need it. When this flag is enabled allocate memory
> for stack heap etc at the end of memory as usual, but U-Boot
> itself is not moved from TEXT_BASE.
>
> Additionally, -pie is removed from the final link step because
> it was causing the absolute value of all symbols coming from
> the linker script to be 0. This affects find_cmd()
>
> Tested on OMAP4430 SDP
>
> Cc: Albert Aribaud
> Cc: Wolfgang Denk
>
> Signed-off-by: Aneesh V
> ---
> arch/arm/config.mk |2 ++
> arch/arm/lib/board.c|5 +
> board/ti/sdp4430/config.mk |9 +++--
> include/configs/omap4_sdp4430.h |2 ++
> 4 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/config.mk b/arch/arm/config.mk
> index 1785e73..2315bcb 100644
> --- a/arch/arm/config.mk
> +++ b/arch/arm/config.mk
> @@ -71,5 +71,7 @@ LDSCRIPT := $(SRCTREE)/$(CPUDIR)/u-boot.lds
>
> # needed for relocation
> ifndef CONFIG_NAND_SPL
> +ifndef CONFIG_SYS_SKIP_ARM_RELOCATION
> LDFLAGS_u-boot += -pie
> endif
> +endif
> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
> index 72ee108..ed3898f 100644
> --- a/arch/arm/lib/board.c
> +++ b/arch/arm/lib/board.c
> @@ -361,6 +361,7 @@ void board_init_f (ulong bootflag)
> gd->fb_base = addr;
> #endif /* CONFIG_LCD */
>
> +#ifndef CONFIG_SYS_SKIP_ARM_RELOCATION
> /*
>* reserve memory for U-Boot code, data& bss
>* round down to next 4 kB limit
> @@ -369,6 +370,7 @@ void board_init_f (ulong bootflag)
> addr&= ~(4096 - 1);
>
> debug ("Reserving %ldk for U-Boot at: %08lx\n", gd->mon_len>> 10,
> addr);
> +#endif
>
> #ifndef CONFIG_PRELOADER
> /*
> @@ -420,6 +422,9 @@ void board_init_f (ulong bootflag)
> dram_init_banksize();
> display_dram_config(); /* and display it */
>
> +#ifdef CONFIG_SYS_SKIP_ARM_RELOCATION
> + addr = _TEXT_BASE;
> +#endif
> gd->relocaddr = addr;
> gd->start_addr_sp = addr_sp;
> gd->reloc_off = addr - _TEXT_BASE;
> diff --git a/board/ti/sdp4430/config.mk b/board/ti/sdp4430/config.mk
> index c62965d..8846732 100644
> --- a/board/ti/sdp4430/config.mk
> +++ b/board/ti/sdp4430/config.mk
> @@ -28,5 +28,10 @@
> # Linux-Kernel is expected to be at 8000'8000, entry 8000'8000
> # (mem base + reserved)
>
> -# 1MB into the SDRAM to allow for SPL's bss at the beginning of SDRAM
> -CONFIG_SYS_TEXT_BASE = 0x8010
> +# 64MB into the SDRAM
> +# Assuming a minimum of 128 MB on the board:
> +# - 64MB before U-Boot is more than enough for Linux when relocation is
> +# disabled
> +# - ~63MB after the U-Boot is more than enough for U-Boot to relocate
> +# itself without stepping on itself
> +CONFIG_SYS_TEXT_BASE = 0x8400
> diff --git a/include/configs/omap4_sdp4430.h b/include/configs/omap4_sdp4430.h
> index fff67d8..e9f76d3 100644
> --- a/include/configs/omap4_sdp4430.h
> +++ b/include/configs/omap4_sdp4430.h
> @@ -278,4 +278,6 @@
> #define CONFIG_SYS_SPL_BSS_MAX_SIZE 0x8 /* 512 KB */
>
> #define CONFIG_SYS_THUMB_BUILD
> +
> +#define CONFIG_SYS_SKIP_ARM_RELOCATION
> #endif /* __CONFIG_H */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: Fix PCI memory map setup on P1_P2_RDB
On Mar 24, 2011, at 9:47 AM, Kumar Gala wrote: > From: Prabhakar Kushwaha > > Update the PCIe address map to match standard FSL memory map. > Additionally, fix the TLBs so the cover the PCIe address space properly > so cards plugged in like an e1000 work correctly. > > Signed-off-by: Prabhakar Kushwaha > Signed-off-by: Kumar Gala > --- > board/freescale/p1_p2_rdb/tlb.c |4 ++-- > include/configs/P1_P2_RDB.h | 24 > 2 files changed, 14 insertions(+), 14 deletions(-) applied - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 01/13] nds32: add header files support for nds32
Hi Wolfgang, 2011/3/25 Wolfgang Denk : > Dear Macpaul Lin, > > please keep the list on Cc: > >> I did run checkpatch, >> However, "some of these files" comes from Linux kernel header. > > Well, the checkpatch comes from Linux, so your files violate the Linux > kernel coding style in the first place. The should have never been > accepted there. > >> And those files in Linux Kernel comes from arm's assembly headers. > > Well, that's not exactly a recommendation, if you ask me. > >> If I cleaned up these headers, it might cause some diffculty when those >> header >> has been update in the kernel. After I disscussed with my colledgue >> (Linux Kernel Team). >> They wish me to send the headers with Linux kernel compatibilty. > > I suggect you clean up the header files in the Linux kernel as well. > As it is a clear code cleanup (making the code match the Linux > CodingStyle requirements) this should go in easily. > >> However it might require your confirmation so that I can let my boss >> aware the headers will be different from those in Linux Kernel. > > I don't ask that they are different. On contrary, they should be > identical if possible. Here that means that the cleaned up versions > should be used both in Linux and in U-Boot. > > Note: this also and especially applies to the "volatile" and "using > I/O accessors instead of pointer acesses" issues. [If not yet, you > would probably soon run into issues when switching to GCC 4.5.x or > even GCC 4.6.] > > Best regards, > > Wolfgang Denk Thanks for your suggestions. I've forward it to the OS team of my company and inform them the possible problem in the future. Thanks a lot. -- Best regards, Macpaul Lin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: Enable various errata on P1022/P1013 SoCs
On Mar 6, 2011, at 10:15 PM, Kumar Gala wrote: > From: Jiang Yutang > > Enable workaround for errata ELBC A001, ESDHC 111 & SATA A001 on > P1022/P1013 SoCs. > > Also updated P1022DS config to properly enable CONFIG_FSL_SATA_V2. > > Signed-off-by: Jiang Yutang > Signed-off-by: Kumar Gala > --- > arch/powerpc/include/asm/config_mpc85xx.h |6 ++ > include/configs/P1022DS.h |1 + > 2 files changed, 7 insertions(+), 0 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] powerpc/85xx: Add 36-bit address map support to P1022DS
On Mar 6, 2011, at 10:17 PM, Kumar Gala wrote: > From: Jiang Yutang > > Signed-off-by: Jiang Yutang > Signed-off-by: Kumar Gala > --- > board/freescale/p1022ds/p1022ds.c |3 ++ > boards.cfg|1 + > include/configs/P1022DS.h | 46 - > 3 files changed, 49 insertions(+), 1 deletions(-) applied to 85xx next - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: Adds some P1010/P1014 SoC configuration defines
On Mar 6, 2011, at 10:15 PM, Kumar Gala wrote: > From: Poonam Aggrwal > > Add defines for FSL_SATA_V2, # of DDR controllers, reset value of CCSRBAR > and SDHC erratum. > > Signed-off-by: Poonam Aggrwal > Signed-off-by: Kumar Gala > --- > arch/powerpc/include/asm/config_mpc85xx.h |8 > 1 files changed, 8 insertions(+), 0 deletions(-) applied to 85xx next - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: Specify CONFIG_SYS_FM_MURAM_SIZE
On Mar 6, 2011, at 10:15 PM, Kumar Gala wrote: > CONFIG_SYS_FM_MURAM_SIZE varies from SoC to SoC to specify it in > config_mpc85xx.h for those parts with a Frame Manager. > > Signed-off-by: Kumar Gala > --- > arch/powerpc/include/asm/config_mpc85xx.h |8 > 1 files changed, 8 insertions(+), 0 deletions(-) applied to 85xx next - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: Corrected sdhc clock value for P1010
On Mar 6, 2011, at 10:15 PM, Kumar Gala wrote: > From: Priyanka Jain > > SDHC clock is equal to CCB on P1010 and P1014 not CCB/2. > > Signed-off-by: Priyanka Jain > Signed-off-by: Poonam Aggrwal > Signed-off-by: Kumar Gala > --- > arch/powerpc/cpu/mpc85xx/speed.c |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) applied to 85xx next - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: Support for Freescale P1024/P1025 processor
On Mar 6, 2011, at 10:15 PM, Kumar Gala wrote: > Add Support for Freescale P1024/P1025 (dual core) and > P1015/P1016 (single core) processors. > > P1024 is a variant of P1020 processor with a core frequency from > 400Mhz to 667Mhz and comes in a 561-pin wirebond power-BGA > > P1025 is a variant of P1021 processor with a core frequency from > 400Mhz to 667Mhz and comes in a 561-pin wirebond power-BGA > > P1015 is a variant of P1024 processor with single core and P1016 is a > variant of P1025 processor with single core. > > Added comments in config_mpc85xx.h to denote single core versions of > processors. > > Signed-off-by: Jin Qing > Signed-off-by: Li Yang > Signed-off-by: Kumar Gala > --- > arch/powerpc/cpu/mpc85xx/Makefile |8 + > arch/powerpc/cpu/mpc8xxx/cpu.c|8 + > arch/powerpc/include/asm/config_mpc85xx.h | 50 + > arch/powerpc/include/asm/processor.h |8 + > 4 files changed, 74 insertions(+), 0 deletions(-) applied to 85xx next - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl: obsolete NXID v0 EEPROMs, automatically upgrade them to NXID v1
On Mar 6, 2011, at 10:16 PM, Kumar Gala wrote: > From: Timur Tabi > > The NXID EEPROM format comes in two versions, v0 and v1. The only > difference is in the number of MAC addresses that can be stored. NXID v0 > supports eight addresses, and NXID v1 supports 23. > > Rather than allow a board to choose which version to support, NXID v0 is > now considered deprecated. The EEPROM code is updated to support only > NXID v1, but it can still read EEPROMs formatted with v0. In these cases, > the EEPROM data is loaded and the CRC is verified, but the data is stored > into a v1 data structure. If the EEPROM data is written back, it is > written in v1 format. This allows existing v0-formatted EEPROMs to > continue providing MAC addresses, but any changes to the data will force > an upgrade to the v1 format, while retaining all data. > > Signed-off-by: Timur Tabi > Signed-off-by: Kumar Gala > --- > board/freescale/common/sys_eeprom.c | 48 -- > 1 files changed, 39 insertions(+), 9 deletions(-) applied to 85xx next - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Removed clearing of L2-as-SRAM
At 12:59 14.02.2011 +0100, Fabian Cenedese wrote: >Removed clearing of L2 cache as SRAM as it is not necessary without ECC. >This also speeds up the booting process. > >Signed-off-by: Fabian Cenedese >Cc: Kumar Gala >--- > arch/powerpc/cpu/mpc85xx/cpu_init_nand.c |7 --- > 1 files changed, 0 insertions(+), 7 deletions(-) > >diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init_nand.c >b/arch/powerpc/cpu/mpc85xx/cpu_init_nand.c >index 8fb27ab..1c42a0b 100644 >--- a/arch/powerpc/cpu/mpc85xx/cpu_init_nand.c >+++ b/arch/powerpc/cpu/mpc85xx/cpu_init_nand.c >@@ -42,8 +42,6 @@ void cpu_init_f(void) > > #if defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_SYS_INIT_L2_ADDR) >ccsr_l2cache_t *l2cache = (void *)CONFIG_SYS_MPC85xx_L2_ADDR; >- char *l2srbar; >- int i; > >out_be32(&l2cache->l2srbar0, CONFIG_SYS_INIT_L2_ADDR); > >@@ -54,10 +52,5 @@ void cpu_init_f(void) >/* set L2E=1 & L2SRAM=001 */ >out_be32(&l2cache->l2ctl, >(MPC85xx_L2CTL_L2E | MPC85xx_L2CTL_L2SRAM_ENTIRE)); >- >- /* Initialize L2 SRAM to zero */ >- l2srbar = (char *)CONFIG_SYS_INIT_L2_ADDR; >- for (i = 0; i < CONFIG_SYS_L2_SIZE; i++) >- l2srbar[i] = 0; > #endif > } >-- >1.7.3.1.msysgit.0 There haven't been any comments about this yet. Is this ok? bye Fabi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/8xxx: Reduce NAND-SPL build size
On Mar 6, 2011, at 10:16 PM, Kumar Gala wrote: > We don't use disable_law in the SPL code so only build it if > !CONFIG_NAND_SPL. > > Signed-off-by: Kumar Gala > --- > drivers/misc/fsl_law.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) not need, fixed by --gc-sections / -ffunction-sections working properly - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] powerpc/85xx: Use DDR for RAMBOOT instead of L2 SRAM on p1_p2_rdb
On Mar 6, 2011, at 10:17 PM, Kumar Gala wrote: > From: Priyanka Jain > > Using DDR as RAMBOOT base instead of L2SRAM for SDCard and SPI Flash > boot loaders because: > - P1_P2_RDB boards have soldered DDR so no need for SPD > - Also P102x has 256K L2 cache size so becomes a limiting factor for > size of image that could be loaded in SRAM mode and would require three > stage boot loader (TPL). > > Changes done: > 1. CONFIG_SYS_TEXT_BASE to 0x1100 > 2. CONFIG_RESET_VECTOR_ADDRESS to 0x1107fffc > > Signed-off-by: Priyanka Jain > Signed-off-by: Poonam Aggrwal > Signed-off-by: Dipen Dudhat > Signed-off-by: Kumar Gala > --- > board/freescale/p1_p2_rdb/ddr.c | 15 +++ > board/freescale/p1_p2_rdb/tlb.c | 13 - > include/configs/P1_P2_RDB.h |8 > 3 files changed, 19 insertions(+), 17 deletions(-) applied to 85xx next - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] powerpc/85xx: Read board switch settings on p1_p2_rdb
On Mar 6, 2011, at 10:17 PM, Kumar Gala wrote: > From: Priyanka Jain > > PCA9557 is parallel I/O expansion device on I2C bus which stores various > board switch settings like NOR Flash-Bank selection, SD Data width. > > On board: > switch SW5[6] is to select width for eSDHC >ON - 4-bit [Enable eSPI] >OFF - 8-bit [Disable eSPI] > > switch SW4[8] is to select NOR Flash Bank for Booting >OFF - Primary Bank >ON - Secondary Bank > > Read board switch settings on p1_p2_rdb and configure corresponding > eSDHC width. > > Signed-off-by: Priyanka Jain > Signed-off-by: Dipen Dudhat > Signed-off-by: Kumar Gala > --- > board/freescale/p1_p2_rdb/p1_p2_rdb.c | 25 + > include/configs/P1_P2_RDB.h |2 ++ > 2 files changed, 27 insertions(+), 0 deletions(-) applied to 85xx next - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] powerpc/85xx: Removed P1/P2 RDB RevB support
On Mar 6, 2011, at 10:17 PM, Kumar Gala wrote: > From: Poonam Aggrwal > > RevB boards never really made it outside of Freescale and have been > replaced with RevC & RevD which had various board bug fixes. > > Signed-off-by: Poonam Aggrwal > Signed-off-by: Kumar Gala > --- > board/freescale/p1_p2_rdb/p1_p2_rdb.c | 29 +++-- > 1 files changed, 7 insertions(+), 22 deletions(-) applied to 85xx next - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] powerpc/85xx: Optimized DDR settings for 800MT/s on P1/P2 RDB
On Mar 6, 2011, at 10:17 PM, Kumar Gala wrote: > From: Poonam Aggrwal > > Changed the following DDR timing parameters for 800Mt/s: > tRRTBL/2+1 to BL/2 > tWWTBL/2+1 to BL/2 > tWRTBL/2+1 to BL/2 > tRWTBL/2+1 to BL/2 > REFINT 6500ns to 7800ns > > Signed-off-by: Poonam Aggrwal > Signed-off-by: Kumar Gala > --- > board/freescale/p1_p2_rdb/ddr.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) applied to 85xx next - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: Fix determining Fman freq on P1023
On Mar 13, 2011, at 10:31 AM, Kumar Gala wrote: > On the P1023 the Fman freq is equivalent to the system bus freq, not 1/2 > of it. Also we only have one Fman so no need for the code to deal with > a second. > > Signed-off-by: Kumar Gala > --- > arch/powerpc/cpu/mpc85xx/speed.c |5 + > 1 files changed, 1 insertions(+), 4 deletions(-) applied to 85xx next - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: Fixup determining PME, FMan freq
On Mar 6, 2011, at 10:47 PM, Kumar Gala wrote: > On CoreNet based SoCs (P2040, P3041, P4080, P5020) we have some > additional rules to determining the various frequencies that PME & FMan > IP blocks run at. > > We need to take into account: > * Reduced number of Core Complex PLL clusters > * HWA_ASYNC_DIV (allows for /2 or /4 options) > > On P2040/P3041/P5020 we only have 2 Core Complex PLLs and in such SoCs > the PME & FMan blocks utilize the second Core Complex PLL. On SoCs > like p4080 with 4 Core Complex PLLs we utilize the third Core Complex > PLL for PME & FMan blocks. > > On P2040/P3041/P5020 we have the added feature that we can divide the > PLL down further by either /2 or /4 based on HWA_ASYNC_DIV. On P4080 > this options doesn't exist, however HWA_ASYNC_DIV field in RCW should be > set to 0 and this gets a backward compatiable /2 behavior. > > Signed-off-by: Kumar Gala > --- > arch/powerpc/cpu/mpc85xx/speed.c | 38 ++--- > arch/powerpc/include/asm/config_mpc85xx.h |6 > 2 files changed, 35 insertions(+), 9 deletions(-) applied to 85xx next - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] arm: provide a CONFIG flag for disabling relocation
Dear Aneesh V, In message <1301058732-30898-1-git-send-email-ane...@ti.com> you wrote: > Relocation may not be needed and desirable in many cases: > * For many boards the amount of SDRAM is fixed. >So relocation is not needed. This is plain wrong. This has been explained a couple of times before. Please read the archives. > * Relocation adds un-necessary additional overhead when >it's not needed. This delay is singificant on slower >platforms such as FPGA Do you have numbers? How much delay do you see caused by the relocation of U-Boot? > * Many boards have ample memory. So reserving enough memory >for Linux in the first half is not a challenge even without >relocation You appear not to understand what relocation is needed for. I tend to reject your patch, unless you can come up with really convincing arguments. Also, your patch should then work for all boards - not only ARM, but also PowerPC (one of the arguments for relocation was that we want to unify the code). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "Beware of bugs in the above code; I have only proved it correct, not tried it." - Donald Knuth ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Removed clearing of L2-as-SRAM
On Mar 25, 2011, at 8:43 AM, Fabian Cenedese wrote: > At 12:59 14.02.2011 +0100, Fabian Cenedese wrote: >> Removed clearing of L2 cache as SRAM as it is not necessary without ECC. >> This also speeds up the booting process. >> >> Signed-off-by: Fabian Cenedese >> Cc: Kumar Gala >> --- >> arch/powerpc/cpu/mpc85xx/cpu_init_nand.c |7 --- >> 1 files changed, 0 insertions(+), 7 deletions(-) >> >> diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init_nand.c >> b/arch/powerpc/cpu/mpc85xx/cpu_init_nand.c >> index 8fb27ab..1c42a0b 100644 >> --- a/arch/powerpc/cpu/mpc85xx/cpu_init_nand.c >> +++ b/arch/powerpc/cpu/mpc85xx/cpu_init_nand.c >> @@ -42,8 +42,6 @@ void cpu_init_f(void) >> >> #if defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_SYS_INIT_L2_ADDR) >> ccsr_l2cache_t *l2cache = (void *)CONFIG_SYS_MPC85xx_L2_ADDR; >> - char *l2srbar; >> - int i; >> >> out_be32(&l2cache->l2srbar0, CONFIG_SYS_INIT_L2_ADDR); >> >> @@ -54,10 +52,5 @@ void cpu_init_f(void) >> /* set L2E=1 & L2SRAM=001 */ >> out_be32(&l2cache->l2ctl, >> (MPC85xx_L2CTL_L2E | MPC85xx_L2CTL_L2SRAM_ENTIRE)); >> - >> - /* Initialize L2 SRAM to zero */ >> - l2srbar = (char *)CONFIG_SYS_INIT_L2_ADDR; >> - for (i = 0; i < CONFIG_SYS_L2_SIZE; i++) >> - l2srbar[i] = 0; >> #endif >> } >> -- >> 1.7.3.1.msysgit.0 > > There haven't been any comments about this yet. Is this ok? > > bye Fabi will take a look, thanks for the reminder. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] arm: Tegra2: add support for A9 CPU init
Hi Tom,
Things look pretty good. Minor comments/questions below.
> +/*
> + * TBD: Move cold_boot() to assembly file.
> + * Values/offsets of the table vars make this difficult.
> + */
> +
> +void cold_boot(void)
> +{
> + asm volatile(
> + "msrcpsr_c, #0xD3 \n"
> + /*
> + * Check current processor: CPU or AVP?
> + * If CPU, go to CPU boot code, else continue on AVP path.
> + */
> + "movr0, %0 \n"
> + "ldrb r2, [r0, %1]\n"
> + /* are we the CPU? */
> + "cmpr2, %2 \n"
> + "movsp, %3 \n"
> + /* yep, we are the CPU */
> + "bxeq %4 \n"
> +
> + /* AVP initialization follows this path */
> + "movsp, %5 \n"
> + /* Init and start CPU */
> + "b startup_cpu \n"
> + :
> + : "i"(NV_PA_PG_UP_BASE),
> + "i"(PG_UP_TAG_0),
> + "r"(proc_tag),
> + "r"(cpu_boot_stack),
> + "r"(_armboot_start),
> + "r"(avp_boot_stack)
> + : "r0", "r2", "cc", "lr"
> + );
> +}
What errors did you encounter when this was in the assembly file? It'd
be nice to put it there now. Likely it will never get fixed if it
doesn't implemented correctly off the bat. If you post the errors
perhaps someone on the list can provide insight.
> +.globl startup_cpu
> +startup_cpu:
> + @ Initialize the AVP, clocks, and memory controller
> + @ SDRAM is guaranteed to be on at this point
> +
> + ldr r0, =cold_boot @ R0 = reset vector for CPU
> + bl start_cpu @ start the CPU
> +
> + @ Transfer control to the AVP code */
> + bl halt_avp
> +
> + @ Should never get here
> +_loop_forever2:
> + b _loop_forever2
> +
> +.globl cache_configure
> +cache_configure:
> + stmdb r13!,{r14}
> +@/* invalidate instruction cache */
It looks like there's a combination of comment forms @, @ */, and @ /*
*/. Is there a reason not to use the normal /* */ universally?
Best,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 4/7] jz4740 nand driver
On Fri, 25 Mar 2011 17:17:17 +0800 Xiangfu Liu wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 03/08/2011 07:44 AM, Scott Wood wrote: > > You don't set nand->options... > > > > Don't you want a bad block table? > > > > hmm... some question. a little confuse. > > 1. I using all rest of nand as rootfs partition. >do I have keep some space in nand for BBT? The last block or so is marked reserved for the BBT. > 2. do I have to tell u-boot where is the BBT? No, it's marked with a special OOB marker. If it isn't present, it will create it at the end of the chip. > 3. do I need some configure in linux kernel for BBT? Set the nand->options flag, same as in U-Boot. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] arm: provide a CONFIG flag for disabling relocation
Dear Wolfgang, On Friday 25 March 2011 07:42 PM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<1301058732-30898-1-git-send-email-ane...@ti.com> you wrote: >> Relocation may not be needed and desirable in many cases: >> * For many boards the amount of SDRAM is fixed. >> So relocation is not needed. > > This is plain wrong. This has been explained a couple of times > before. Please read the archives. > I read this one: http://tree.celinuxforum.org/pipermail/celinux-dev/2009-December/001916.html I also read again this discussion I had started sometime back: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/88067/focus=88262 I don't think any of these features will suffer due to my change. Please note that the memory for pRAM, frame buffer etc would still be allocated at the end of available memory. I am preventing only code relocation. My strategy is to leave enough space before and after the U-boot in the non-relocation case. Before the U-Boot for Linux, after U-boot for stack, heap and all other dynamic needs. Wouldn't that work? Am I missing something? >> * Relocation adds un-necessary additional overhead when >> it's not needed. This delay is singificant on slower >> platforms such as FPGA > > Do you have numbers? How much delay do you see caused by the > relocation of U-Boot? No, I don't have any numbers. In fact, if I enable relocation I get into some issues on the FPGA platform I am working on currently. But that seems to be a problem with the platform (For some reason, it doesn't work well when some code is copied to a new area and executed from there - maybe some issue with the memory model). But the platform is so slow that booting U-boot itself takes couple of minutes. The overhead due to relocation will surely get magnified in such cases. Another problem I have with relocation is that it makes debugging with JTAG debugers more difficult. The addresses of symbols in the ELF target are no longer valid. Of course, you can load the symbols at an offset from the original location. But one has to first enable debug prints, find the relocation offset, use it while loading the symbols before you can do source level debugging. > >> * Many boards have ample memory. So reserving enough memory >> for Linux in the first half is not a challenge even without >> relocation > > You appear not to understand what relocation is needed for. > > > I tend to reject your patch, unless you can come up with really > convincing arguments. Also, your patch should then work for all > boards - not only ARM, but also PowerPC (one of the arguments for > relocation was that we want to unify the code). I am afraid I will not be able to do that for all the archs primarily because I will not be able to test anything other than armv7 and also I do not understand their assembly languages. Sometimes, fixes in relocate_code() will be needed to make sure the special case of relocation offset = 0 works well. I had to do that for armv7(It's part of the SPL series). However, the same principles as in this patch should apply everywhere it shouldn't be very difficult to make it work for any architecture when there is a need. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] arm: Tegra2: add support for A9 CPU init
Peter,
On Fri, Mar 25, 2011 at 9:02 AM, Peter Tyser wrote:
> Hi Tom,
> Things look pretty good. Minor comments/questions below.
>
>
>
>> +/*
>> + * TBD: Move cold_boot() to assembly file.
>> + * Values/offsets of the table vars make this difficult.
>> + */
>> +
>> +void cold_boot(void)
>> +{
>> + asm volatile(
>> + "msr cpsr_c, #0xD3 \n"
>> + /*
>> + * Check current processor: CPU or AVP?
>> + * If CPU, go to CPU boot code, else continue on AVP path.
>> + */
>> + "mov r0, %0 \n"
>> + "ldrb r2, [r0, %1] \n"
>> + /* are we the CPU? */
>> + "cmp r2, %2 \n"
>> + "mov sp, %3 \n"
>> + /* yep, we are the CPU */
>> + "bxeq %4 \n"
>> +
>> + /* AVP initialization follows this path */
>> + "mov sp, %5 \n"
>> + /* Init and start CPU */
>> + "b startup_cpu \n"
>> + :
>> + : "i"(NV_PA_PG_UP_BASE),
>> + "i"(PG_UP_TAG_0),
>> + "r"(proc_tag),
>> + "r"(cpu_boot_stack),
>> + "r"(_armboot_start),
>> + "r"(avp_boot_stack)
>> + : "r0", "r2", "cc", "lr"
>> + );
>> +}
>
> What errors did you encounter when this was in the assembly file? It'd
> be nice to put it there now. Likely it will never get fixed if it
> doesn't implemented correctly off the bat. If you post the errors
> perhaps someone on the list can provide insight.
I didn't capture a log of the errors when I was trying to put the
cold_boot code into lowlevel_init.S. But I saw fixup errors and
undefined constant errors, all related to the #defines (NV_PG_UP_BASE,
avp/cpu_boot_stack, etc.) and how the compiler/assembler references
indirect and relative constants.
Note that this code works perfectly as-is, so there's no pressing need
to move it to assembly now, except for a cosmetic/procedural one. I'd
rather get this accepted into mainline, so I can move on to the
eMMC/SPI/USB drivers so people can use the code to boot an OS on our
(many) Tegra2 boards coming to market RSN.
If some ARM / gcc assembly wizard wants to attempt moving this code to
a .S file, I welcome the help - I may even attack it at a later date,
when I've got more bandwidth. But it isn't a priority for me right
now, unless someone on the list adamantly opposes the code as-s. But
I'd expect anyone with that strong an opinion about to be able to fix
it, or at least attempt it and see why I decided to defer moving it to
assembly for now.
>
>
>
>> +.globl startup_cpu
>> +startup_cpu:
>> + @ Initialize the AVP, clocks, and memory controller
>> + @ SDRAM is guaranteed to be on at this point
>> +
>> + ldr r0, =cold_boot @ R0 = reset vector for CPU
>> + bl start_cpu @ start the CPU
>> +
>> + @ Transfer control to the AVP code */
>> + bl halt_avp
>> +
>> + @ Should never get here
>> +_loop_forever2:
>> + b _loop_forever2
>> +
>> +.globl cache_configure
>> +cache_configure:
>> + stmdb r13!,{r14}
>> +@ /* invalidate instruction cache */
>
> It looks like there's a combination of comment forms @, @ */, and @ /*
> */. Is there a reason not to use the normal /* */ universally?
No, just dross left over from moving the inline assembly from .c to
.S. The rest of lowlevel_init.S uses @ for comments, so I tried to
stick with that. I'l fix it, thanks.
>
> Best,
> Peter
>
>
Thanks,
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3] arm: Tegra2: add support for A9 CPU init
Signed-off-by: Tom Warren
---
Changes for V2:
- Remove returns in void functions
- Move inline assembly code to .S file
- Simplify some if/else code, break out common code
- Minimize the use of local vars
- Inline some single-instance functions
- Remove TRUE/FALSE define, use 1/0 instead
- Replace memset of mem-mapped regs w/loop of writel's
Changes for V3:
- Fix C-style comments in lowlevel_init.S cache_configure
arch/arm/cpu/armv7/start.S | 12 +
arch/arm/cpu/armv7/tegra2/Makefile |2 +-
arch/arm/cpu/armv7/tegra2/ap20.c | 366
arch/arm/cpu/armv7/tegra2/ap20.h | 105
arch/arm/cpu/armv7/tegra2/lowlevel_init.S | 70 ++
arch/arm/include/asm/arch-tegra2/clk_rst.h | 27 ++
arch/arm/include/asm/arch-tegra2/pmc.h |8 +
arch/arm/include/asm/arch-tegra2/scu.h | 43
arch/arm/include/asm/arch-tegra2/tegra2.h |5 +
board/nvidia/common/board.c| 10 +
board/nvidia/common/board.h| 29 +++
include/configs/harmony.h |1 +
include/configs/seaboard.h |3 +-
include/configs/tegra2-common.h|2 +
14 files changed, 681 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/cpu/armv7/tegra2/ap20.c
create mode 100644 arch/arm/cpu/armv7/tegra2/ap20.h
create mode 100644 arch/arm/include/asm/arch-tegra2/scu.h
create mode 100644 board/nvidia/common/board.h
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index cb4f92f..4b36693 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -70,6 +70,18 @@ _end_vect:
_TEXT_BASE:
.word CONFIG_SYS_TEXT_BASE
+#ifdef CONFIG_TEGRA2
+/*
+ * Tegra2 uses 2 separate CPUs - the AVP (ARM7TDMI) and the CPU (dual A9s).
+ * U-Boot runs on the AVP first, setting things up for the CPU (PLLs,
+ * muxes, clocks, clamps, etc.). Then the AVP halts, and expects the CPU
+ * to pick up its reset vector, which points here.
+ */
+.globl _armboot_start
+_armboot_start:
+.word _start
+#endif
+
/*
* These are defined in the board-specific linker script.
*/
diff --git a/arch/arm/cpu/armv7/tegra2/Makefile
b/arch/arm/cpu/armv7/tegra2/Makefile
index 687c887..f1ea915 100644
--- a/arch/arm/cpu/armv7/tegra2/Makefile
+++ b/arch/arm/cpu/armv7/tegra2/Makefile
@@ -28,7 +28,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(SOC).o
SOBJS := lowlevel_init.o
-COBJS := board.o sys_info.o timer.o
+COBJS := ap20.o board.o sys_info.o timer.o
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
diff --git a/arch/arm/cpu/armv7/tegra2/ap20.c b/arch/arm/cpu/armv7/tegra2/ap20.c
new file mode 100644
index 000..d0ad41f
--- /dev/null
+++ b/arch/arm/cpu/armv7/tegra2/ap20.c
@@ -0,0 +1,366 @@
+/*
+* (C) Copyright 2010-2011
+* NVIDIA Corporation
+*
+* 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 "ap20.h"
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+u32 s_first_boot = 1;
+
+static void enable_cpu_clock(int enable)
+{
+ struct clk_rst_ctlr *clkrst = (struct clk_rst_ctlr *)NV_PA_CLK_RST_BASE;
+ u32 reg, clk;
+
+ /*
+* NOTE:
+* Regardless of whether the request is to enable or disable the CPU
+* clock, every processor in the CPU complex except the master (CPU 0)
+* will have it's clock stopped because the AVP only talks to the
+* master. The AVP does not know (nor does it need to know) that there
+* are multiple processors in the CPU complex.
+*/
+
+ if (enable) {
+ /* Wait until all clocks are stable */
+ udelay(PLL_STABILIZATION_DELAY);
+
+ writel(CCLK_BURST_POLICY, &clkrst->crc_cclk_brst_pol);
+ writel(SUPER_CCLK_DIVIDER, &clkrst->crc_super_cclk_div);
+ }
+
+ /* Fetch the register containing the main CPU complex clock enable */
+ reg = readl(&clkrst->crc_clk_out_enb_l);
+ reg |= CLK_ENB_CPU;
+
+ /*
+* Read the register containing the individual CPU clock enables and
+* always stop the cloc
Re: [U-Boot] [PATCH V2] arm: Tegra2: add support for A9 CPU init
On Fri, 2011-03-25 at 09:16 -0700, Tom Warren wrote:
> Peter,
>
> On Fri, Mar 25, 2011 at 9:02 AM, Peter Tyser wrote:
> > Hi Tom,
> > Things look pretty good. Minor comments/questions below.
> >
> >
> >
> >> +/*
> >> + * TBD: Move cold_boot() to assembly file.
> >> + * Values/offsets of the table vars make this difficult.
> >> + */
> >> +
> >> +void cold_boot(void)
> >> +{
> >> + asm volatile(
> >> + "msrcpsr_c, #0xD3 \n"
> >> + /*
> >> + * Check current processor: CPU or AVP?
> >> + * If CPU, go to CPU boot code, else continue on AVP path.
> >> + */
> >> + "movr0, %0 \n"
> >> + "ldrb r2, [r0, %1]\n"
> >> + /* are we the CPU? */
> >> + "cmpr2, %2 \n"
> >> + "movsp, %3 \n"
> >> + /* yep, we are the CPU */
> >> + "bxeq %4 \n"
> >> +
> >> + /* AVP initialization follows this path */
> >> + "movsp, %5 \n"
> >> + /* Init and start CPU */
> >> + "b startup_cpu \n"
> >> + :
> >> + : "i"(NV_PA_PG_UP_BASE),
> >> + "i"(PG_UP_TAG_0),
> >> + "r"(proc_tag),
> >> + "r"(cpu_boot_stack),
> >> + "r"(_armboot_start),
> >> + "r"(avp_boot_stack)
> >> + : "r0", "r2", "cc", "lr"
> >> + );
> >> +}
> >
> > What errors did you encounter when this was in the assembly file? It'd
> > be nice to put it there now. Likely it will never get fixed if it
> > doesn't implemented correctly off the bat. If you post the errors
> > perhaps someone on the list can provide insight.
> I didn't capture a log of the errors when I was trying to put the
> cold_boot code into lowlevel_init.S. But I saw fixup errors and
> undefined constant errors, all related to the #defines (NV_PG_UP_BASE,
> avp/cpu_boot_stack, etc.) and how the compiler/assembler references
> indirect and relative constants.
>
> Note that this code works perfectly as-is, so there's no pressing need
> to move it to assembly now, except for a cosmetic/procedural one. I'd
> rather get this accepted into mainline, so I can move on to the
> eMMC/SPI/USB drivers so people can use the code to boot an OS on our
> (many) Tegra2 boards coming to market RSN.
>
> If some ARM / gcc assembly wizard wants to attempt moving this code to
> a .S file, I welcome the help - I may even attack it at a later date,
> when I've got more bandwidth. But it isn't a priority for me right
> now, unless someone on the list adamantly opposes the code as-s. But
> I'd expect anyone with that strong an opinion about to be able to fix
> it, or at least attempt it and see why I decided to defer moving it to
> assembly for now.
I understand your perspective, but why not spend the extra 30 minutes
and do it the right way? Passing the buck to someone else who cares
about maintaining high quality code isn't the right thing to do in my
opinion. This patch isn't going to make it into the upcoming release,
so it won't gate the other eMMC/SPI/USB drivers you want to add. The
bar to get code into open source project generally is higher than "it
works" - it has to adhere to the project's design principles and
guidelines. U-Boot already needs cleanup as is without adding more
cruft. Solving this small issue now results in cleaner code, less
headache down the road, and shouldn't take long. As usual, I'm not the
maintainer, so its just my $0.02.
Best,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] arm: Tegra2: add support for A9 CPU init
Peter,
On Fri, Mar 25, 2011 at 10:22 AM, Peter Tyser wrote:
> On Fri, 2011-03-25 at 09:16 -0700, Tom Warren wrote:
>> Peter,
>>
>> On Fri, Mar 25, 2011 at 9:02 AM, Peter Tyser wrote:
>> > Hi Tom,
>> > Things look pretty good. Minor comments/questions below.
>> >
>> >
>> >
>> >> +/*
>> >> + * TBD: Move cold_boot() to assembly file.
>> >> + * Values/offsets of the table vars make this difficult.
>> >> + */
>> >> +
>> >> +void cold_boot(void)
>> >> +{
>> >> + asm volatile(
>> >> + "msr cpsr_c, #0xD3 \n"
>> >> + /*
>> >> + * Check current processor: CPU or AVP?
>> >> + * If CPU, go to CPU boot code, else continue on AVP path.
>> >> + */
>> >> + "mov r0, %0 \n"
>> >> + "ldrb r2, [r0, %1] \n"
>> >> + /* are we the CPU? */
>> >> + "cmp r2, %2 \n"
>> >> + "mov sp, %3 \n"
>> >> + /* yep, we are the CPU */
>> >> + "bxeq %4 \n"
>> >> +
>> >> + /* AVP initialization follows this path */
>> >> + "mov sp, %5 \n"
>> >> + /* Init and start CPU */
>> >> + "b startup_cpu \n"
>> >> + :
>> >> + : "i"(NV_PA_PG_UP_BASE),
>> >> + "i"(PG_UP_TAG_0),
>> >> + "r"(proc_tag),
>> >> + "r"(cpu_boot_stack),
>> >> + "r"(_armboot_start),
>> >> + "r"(avp_boot_stack)
>> >> + : "r0", "r2", "cc", "lr"
>> >> + );
>> >> +}
>> >
>> > What errors did you encounter when this was in the assembly file? It'd
>> > be nice to put it there now. Likely it will never get fixed if it
>> > doesn't implemented correctly off the bat. If you post the errors
>> > perhaps someone on the list can provide insight.
>> I didn't capture a log of the errors when I was trying to put the
>> cold_boot code into lowlevel_init.S. But I saw fixup errors and
>> undefined constant errors, all related to the #defines (NV_PG_UP_BASE,
>> avp/cpu_boot_stack, etc.) and how the compiler/assembler references
>> indirect and relative constants.
>>
>> Note that this code works perfectly as-is, so there's no pressing need
>> to move it to assembly now, except for a cosmetic/procedural one. I'd
>> rather get this accepted into mainline, so I can move on to the
>> eMMC/SPI/USB drivers so people can use the code to boot an OS on our
>> (many) Tegra2 boards coming to market RSN.
>>
>> If some ARM / gcc assembly wizard wants to attempt moving this code to
>> a .S file, I welcome the help - I may even attack it at a later date,
>> when I've got more bandwidth. But it isn't a priority for me right
>> now, unless someone on the list adamantly opposes the code as-s. But
>> I'd expect anyone with that strong an opinion about to be able to fix
>> it, or at least attempt it and see why I decided to defer moving it to
>> assembly for now.
>
> I understand your perspective, but why not spend the extra 30 minutes
> and do it the right way? Passing the buck to someone else who cares
> about maintaining high quality code isn't the right thing to do in my
> opinion. This patch isn't going to make it into the upcoming release,
> so it won't gate the other eMMC/SPI/USB drivers you want to add. The
> bar to get code into open source project generally is higher than "it
> works" - it has to adhere to the project's design principles and
> guidelines. U-Boot already needs cleanup as is without adding more
> cruft. Solving this small issue now results in cleaner code, less
> headache down the road, and shouldn't take long. As usual, I'm not the
> maintainer, so its just my $0.02.
FWIW, I spent _far_ more than 30 minutes on this .. close to a full
day of frustration/banging my head against the wall. I have other
priorities besides upstreaming Tegra2 U-Boot support, and I can't
justify spending days on this. As I originally stated, I'm no expert
in the intricacies of ARM asm programming - my expertise is in x86
CPUs, and hit a wall with this port to assembly.
I'm not passing the buck, and while I agree that this code is not the
cleanest I've seen, I don't think I'm pushing low-quality code here.
It's 8 lines of embedded assembly, plus a table. Looking at what the C
compiler produces in assembly, it's twice as long, pushes some of the
tabled values on the stack and then pulls them back into registers,
and is, IMHO, harder to understand. I could just cut-and-paste the
compiler output into lowlevel_init.S, and add some comments, but is
that really any better? Is the goal to get clean, understandable
code, or messier, harder to parse code in the right files?
As to adhering to U-Boot's design principles and guidelines, could you
point me to the section on embedded assembly in C files? I don't
remember seeing a specific section on that topic, don't see it under
U-Boot Coding Style, nor in the Linux coding guidelines, and I'd lik
Re: [U-Boot] [RFC PATCH] arm: provide a CONFIG flag for disabling relocation
Le 25/03/2011 17:12, Aneesh V a écrit : > Another problem I have with relocation is that it makes debugging with > JTAG debugers more difficult. The addresses of symbols in the ELF > target are no longer valid. Of course, you can load the symbols at an > offset from the original location. But one has to first enable debug > prints, find the relocation offset, use it while loading the symbols > before you can do source level debugging. Actually you don't need recompiling: simply set a breakpoint at the entry of relocate_code and once you hit the bp, look up r2: it contains the destination. If you want the offset rather than the absolute address, set the breakpoint right after the 'sub r9, r6, r0' round line 222: r9 will then give you the offset. Unload the current symbols, reload the symbols with the relevant offset, and there you go. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3] arm: Tegra2: add support for A9 CPU init
Le 25/03/2011 18:06, Tom Warren a écrit :
> Signed-off-by: Tom Warren
> ---
> Changes for V2:
> - Remove returns in void functions
> - Move inline assembly code to .S file
> - Simplify some if/else code, break out common code
> - Minimize the use of local vars
> - Inline some single-instance functions
> - Remove TRUE/FALSE define, use 1/0 instead
> - Replace memset of mem-mapped regs w/loop of writel's
> Changes for V3:
> - Fix C-style comments in lowlevel_init.S cache_configure
>
> arch/arm/cpu/armv7/start.S | 12 +
> arch/arm/cpu/armv7/tegra2/Makefile |2 +-
> arch/arm/cpu/armv7/tegra2/ap20.c | 366
>
> arch/arm/cpu/armv7/tegra2/ap20.h | 105
> arch/arm/cpu/armv7/tegra2/lowlevel_init.S | 70 ++
> arch/arm/include/asm/arch-tegra2/clk_rst.h | 27 ++
> arch/arm/include/asm/arch-tegra2/pmc.h |8 +
> arch/arm/include/asm/arch-tegra2/scu.h | 43
> arch/arm/include/asm/arch-tegra2/tegra2.h |5 +
> board/nvidia/common/board.c| 10 +
> board/nvidia/common/board.h| 29 +++
> include/configs/harmony.h |1 +
> include/configs/seaboard.h |3 +-
> include/configs/tegra2-common.h|2 +
> 14 files changed, 681 insertions(+), 2 deletions(-)
> create mode 100644 arch/arm/cpu/armv7/tegra2/ap20.c
> create mode 100644 arch/arm/cpu/armv7/tegra2/ap20.h
> create mode 100644 arch/arm/include/asm/arch-tegra2/scu.h
> create mode 100644 board/nvidia/common/board.h
>
> diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
> index cb4f92f..4b36693 100644
> --- a/arch/arm/cpu/armv7/start.S
> +++ b/arch/arm/cpu/armv7/start.S
> @@ -70,6 +70,18 @@ _end_vect:
> _TEXT_BASE:
> .word CONFIG_SYS_TEXT_BASE
>
> +#ifdef CONFIG_TEGRA2
> +/*
> + * Tegra2 uses 2 separate CPUs - the AVP (ARM7TDMI) and the CPU (dual A9s).
> + * U-Boot runs on the AVP first, setting things up for the CPU (PLLs,
> + * muxes, clocks, clamps, etc.). Then the AVP halts, and expects the CPU
> + * to pick up its reset vector, which points here.
> + */
> +.globl _armboot_start
> +_armboot_start:
> +.word _start
> +#endif
> +
> /*
>* These are defined in the board-specific linker script.
>*/
> diff --git a/arch/arm/cpu/armv7/tegra2/Makefile
> b/arch/arm/cpu/armv7/tegra2/Makefile
> index 687c887..f1ea915 100644
> --- a/arch/arm/cpu/armv7/tegra2/Makefile
> +++ b/arch/arm/cpu/armv7/tegra2/Makefile
> @@ -28,7 +28,7 @@ include $(TOPDIR)/config.mk
> LIB = $(obj)lib$(SOC).o
>
> SOBJS := lowlevel_init.o
> -COBJS:= board.o sys_info.o timer.o
> +COBJS:= ap20.o board.o sys_info.o timer.o
>
> SRCS:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
> OBJS:= $(addprefix $(obj),$(COBJS) $(SOBJS))
> diff --git a/arch/arm/cpu/armv7/tegra2/ap20.c
> b/arch/arm/cpu/armv7/tegra2/ap20.c
> new file mode 100644
> index 000..d0ad41f
> --- /dev/null
> +++ b/arch/arm/cpu/armv7/tegra2/ap20.c
> @@ -0,0 +1,366 @@
> +/*
> +* (C) Copyright 2010-2011
> +* NVIDIA Corporation
> +*
> +* 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 "ap20.h"
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +u32 s_first_boot = 1;
> +
> +static void enable_cpu_clock(int enable)
> +{
> + struct clk_rst_ctlr *clkrst = (struct clk_rst_ctlr *)NV_PA_CLK_RST_BASE;
> + u32 reg, clk;
> +
> + /*
> + * NOTE:
> + * Regardless of whether the request is to enable or disable the CPU
> + * clock, every processor in the CPU complex except the master (CPU 0)
> + * will have it's clock stopped because the AVP only talks to the
> + * master. The AVP does not know (nor does it need to know) that there
> + * are multiple processors in the CPU complex.
> + */
> +
> + if (enable) {
> + /* Wait until all clocks are stable */
> + udelay(PLL_STABILIZATION_DELAY);
> +
> + writel(CCLK_BURST_POLICY,&clkrst->crc_cclk_brst_pol);
> + writel(SUPER_CCLK_DIVIDER,&clkrst->crc_super_cclk_di
Re: [U-Boot] [PATCH 2/2] usb: musb: blackfin: check anomaly workarounds at runtime too
Hi, 2011/3/17 Mike Frysinger : > The anomaly workarounds we need for older silicon might break things > if used on newer versions where the anomalies don't exist. So check > the silicon rev at runtime too. > > Signed-off-by: Mike Frysinger > --- > drivers/usb/musb/blackfin_usb.c | 29 ++--- > 1 files changed, 26 insertions(+), 3 deletions(-) Applied to u-boot-usb. Thanks. Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] usb: musb: blackfin: make clkin configurable
Hi, 2011/3/17 Mike Frysinger : > Not everyone has a 24MHz clkin to the USB, so let board porters override. > > Signed-off-by: Mike Frysinger > --- > drivers/usb/musb/blackfin_usb.c | 7 ++- > 1 files changed, 6 insertions(+), 1 deletions(-) > Applied to u-boot-usb Thanks. Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Remove unnecessary reset in usb_stor_get_info
Hi, 2011/3/24 Erik Hansen : > The reset request in usb_stor_get_info is causing issues with some usb > sticks. Some of these sticks vendor_id/product_id have been hardcoded to > not reset but better is to remove the reset altogether. It is not needed. > > Signed-off-by: Erik Hansen > --- > common/usb_storage.c | 25 - > 1 files changed, 0 insertions(+), 25 deletions(-) Applied to u-boot-usb. Thanks. Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fat32 root directory handling
Hi Wolfgang,
2011/3/24 Erik Hansen :
> Fat directory handling didn't check reaching the end of the root directory. It
> relied on a stop condition based on a directory entry with a name starting
> with
> a '\0' character. This check in itself is wrong ('\0' indicates free entry,
> not
> end_of_directory) but outside the scope of this fix. For FAT32, the end of the
> rootdir is reached when the end of the cluster chain is reached. The code
> didn't
> check this condition and started to read an incorrect cluster. This caused a
> subsequent read request of a sector outside the range of the usb stick in
> use. On its turn, the usb stick protested with a stall handshake.
>
> Both FAT32 and non-FAT32 (FAT16/FAT12) end or rootdir checks have been put in.
>
> Signed-off-by: Erik Hansen
> ---
> fs/fat/fat.c | 38 --
> 1 files changed, 24 insertions(+), 14 deletions(-)
>
> diff --git a/fs/fat/fat.c b/fs/fat/fat.c
> index a75e4f2..2a3414f 100644
> --- a/fs/fat/fat.c
> +++ b/fs/fat/fat.c
> @@ -31,6 +31,7 @@
> #include
> #include
>
> +
> /*
> * Convert a string to lowercase.
> */
Any objections if I pull this patch in the U-boot USB tree after
fixing this whitespace issue?
At least here here my Ack for the remainder of this patch
Acked-by: Remy Bohmer
Kind regards,
Remy
> @@ -209,7 +210,7 @@ static __u32 get_fatent (fsdata *mydata, __u32 entry)
>
> /* Read a new block of FAT entries into the cache. */
> if (bufnum != mydata->fatbufnum) {
> - int getsize = FATBUFSIZE / FS_BLOCK_SIZE;
> + __u32 getsize = FATBUFSIZE / FS_BLOCK_SIZE;
> __u8 *bufptr = mydata->fatbuf;
> __u32 fatlength = mydata->fatlength;
> __u32 startblock = bufnum * FATBUFBLOCKS;
> @@ -279,7 +280,7 @@ static int
> get_cluster (fsdata *mydata, __u32 clustnum, __u8 *buffer,
> unsigned long size)
> {
> - int idx = 0;
> + __u32 idx = 0;
> __u32 startsect;
>
> if (clustnum > 0) {
> @@ -767,12 +768,13 @@ do_fat_read (const char *filename, void *buffer,
> unsigned long maxsize,
> dir_entry *dentptr;
> __u16 prevcksum = 0x;
> char *subname = "";
> - int cursect;
> + __u32 cursect;
> int idx, isdir = 0;
> int files = 0, dirs = 0;
> long ret = 0;
> int firsttime;
> - int root_cluster;
> + __u32 root_cluster;
> + int rootdir_size = 0;
> int j;
>
> if (read_bootsectandvi(&bs, &volinfo, &mydata->fatsize)) {
> @@ -798,8 +800,6 @@ do_fat_read (const char *filename, void *buffer, unsigned
> long maxsize,
> mydata->data_begin = mydata->rootdir_sect -
> (mydata->clust_size * 2);
> } else {
> - int rootdir_size;
> -
> rootdir_size = ((bs.dir_entries[1] * (int)256 +
> bs.dir_entries[0]) *
> sizeof(dir_entry)) /
> @@ -1006,20 +1006,18 @@ do_fat_read (const char *filename, void *buffer,
> unsigned long maxsize,
> * root directory clusters when a cluster has been
> * completely processed.
> */
> - if ((mydata->fatsize == 32) && (++j == mydata->clust_size)) {
> - int nxtsect;
> - int nxt_clust;
> + ++j;
> + int fat32_end = 0;
> + if ((mydata->fatsize == 32) && (j == mydata->clust_size)) {
> + int nxtsect = 0;
> + int nxt_clust = 0;
>
> nxt_clust = get_fatent(mydata, root_cluster);
> + fat32_end = CHECK_CLUST(nxt_clust, 32);
>
> nxtsect = mydata->data_begin +
> (nxt_clust * mydata->clust_size);
>
> - debug("END LOOP: sect=%d, root_clust=%d, "
> - "n_sect=%d, n_clust=%d\n",
> - cursect, root_cluster,
> - nxtsect, nxt_clust);
> -
> root_cluster = nxt_clust;
>
> cursect = nxtsect;
> @@ -1027,6 +1025,18 @@ do_fat_read (const char *filename, void *buffer,
> unsigned long maxsize,
> } else {
> cursect++;
> }
> +
> + /* If end of rootdir reached */
> + if ((mydata->fatsize == 32 && fat32_end) ||
> + (mydata->fatsize != 32 && j == rootdir_size)) {
> + if (dols == LS_ROOT) {
> + printf("\n%d file(s), %d dir(s)\n\n",
> + files, dirs);
> + return 0;
> + } else {
> + return -1;
> + }
> + }
> }
> rootdir_done:
>
> --
>
Re: [U-Boot] [PATCH V2] arm: Tegra2: add support for A9 CPU init
On Fri, 2011-03-25 at 11:05 -0700, Tom Warren wrote:
> Peter,
>
> On Fri, Mar 25, 2011 at 10:22 AM, Peter Tyser wrote:
> > On Fri, 2011-03-25 at 09:16 -0700, Tom Warren wrote:
> >> Peter,
> >>
> >> On Fri, Mar 25, 2011 at 9:02 AM, Peter Tyser wrote:
> >> > Hi Tom,
> >> > Things look pretty good. Minor comments/questions below.
> >> >
> >> >
> >> >
> >> >> +/*
> >> >> + * TBD: Move cold_boot() to assembly file.
> >> >> + * Values/offsets of the table vars make this difficult.
> >> >> + */
> >> >> +
> >> >> +void cold_boot(void)
> >> >> +{
> >> >> + asm volatile(
> >> >> + "msrcpsr_c, #0xD3 \n"
> >> >> + /*
> >> >> + * Check current processor: CPU or AVP?
> >> >> + * If CPU, go to CPU boot code, else continue on AVP path.
> >> >> + */
> >> >> + "movr0, %0 \n"
> >> >> + "ldrb r2, [r0, %1]\n"
> >> >> + /* are we the CPU? */
> >> >> + "cmpr2, %2 \n"
> >> >> + "movsp, %3 \n"
> >> >> + /* yep, we are the CPU */
> >> >> + "bxeq %4 \n"
> >> >> +
> >> >> + /* AVP initialization follows this path */
> >> >> + "movsp, %5 \n"
> >> >> + /* Init and start CPU */
> >> >> + "b startup_cpu \n"
> >> >> + :
> >> >> + : "i"(NV_PA_PG_UP_BASE),
> >> >> + "i"(PG_UP_TAG_0),
> >> >> + "r"(proc_tag),
> >> >> + "r"(cpu_boot_stack),
> >> >> + "r"(_armboot_start),
> >> >> + "r"(avp_boot_stack)
> >> >> + : "r0", "r2", "cc", "lr"
> >> >> + );
> >> >> +}
> >> >
> >> > What errors did you encounter when this was in the assembly file? It'd
> >> > be nice to put it there now. Likely it will never get fixed if it
> >> > doesn't implemented correctly off the bat. If you post the errors
> >> > perhaps someone on the list can provide insight.
> >> I didn't capture a log of the errors when I was trying to put the
> >> cold_boot code into lowlevel_init.S. But I saw fixup errors and
> >> undefined constant errors, all related to the #defines (NV_PG_UP_BASE,
> >> avp/cpu_boot_stack, etc.) and how the compiler/assembler references
> >> indirect and relative constants.
> >>
> >> Note that this code works perfectly as-is, so there's no pressing need
> >> to move it to assembly now, except for a cosmetic/procedural one. I'd
> >> rather get this accepted into mainline, so I can move on to the
> >> eMMC/SPI/USB drivers so people can use the code to boot an OS on our
> >> (many) Tegra2 boards coming to market RSN.
> >>
> >> If some ARM / gcc assembly wizard wants to attempt moving this code to
> >> a .S file, I welcome the help - I may even attack it at a later date,
> >> when I've got more bandwidth. But it isn't a priority for me right
> >> now, unless someone on the list adamantly opposes the code as-s. But
> >> I'd expect anyone with that strong an opinion about to be able to fix
> >> it, or at least attempt it and see why I decided to defer moving it to
> >> assembly for now.
> >
> > I understand your perspective, but why not spend the extra 30 minutes
> > and do it the right way? Passing the buck to someone else who cares
> > about maintaining high quality code isn't the right thing to do in my
> > opinion. This patch isn't going to make it into the upcoming release,
> > so it won't gate the other eMMC/SPI/USB drivers you want to add. The
> > bar to get code into open source project generally is higher than "it
> > works" - it has to adhere to the project's design principles and
> > guidelines. U-Boot already needs cleanup as is without adding more
> > cruft. Solving this small issue now results in cleaner code, less
> > headache down the road, and shouldn't take long. As usual, I'm not the
> > maintainer, so its just my $0.02.
> FWIW, I spent _far_ more than 30 minutes on this .. close to a full
> day of frustration/banging my head against the wall. I have other
> priorities besides upstreaming Tegra2 U-Boot support, and I can't
> justify spending days on this. As I originally stated, I'm no expert
> in the intricacies of ARM asm programming - my expertise is in x86
> CPUs, and hit a wall with this port to assembly.
Understood. When situations like that happen its good to ask others for
input rather than using a non-optimal solution. Then either
- Someone suggests how to fix the code, and the code improves.
- No one helps, which implies your method isn't easy to improve upon,
you gave it a good effort, and so it gets included.
As is, the current patch looks like a non-optimal solution that someone
familiar with ARM asm could have quickly helped with.
> I'm not passing the buck, and while I agree that this code is not the
> cleanest I've seen, I don't think I'm pushing low-quality code here.
Based on the fact that you tried to fix it for a day, it soun
Re: [U-Boot] [PATCH v2 0/4] Kirkwood: Add support for OpenRD-Client & OpenRD-Ultimate
Julian Pidancet wrote: > A nice future improvement would be to add variant detection and configuration > at run-time as suggested on the mailing-list in a recent email. So one could > use the same binary for all board variants. Does anyone know offhand how to do this? I have heard rumors of a GPIO method but I haven't found any details. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] arm: Tegra2: add support for A9 CPU init
> FWIW, I spent _far_ more than 30 minutes on this .. close to a full > day of frustration/banging my head against the wall. [...] I understand the feeling. I'm one of those who suggested (but not required) to put full-asm function in .S files for a reason; I personally think the reboot code may remain as it is, given the effort involved. There are minor details that may be better, but since I'm unable to suggest (and at least compile-test) them for lack of time, I'm not even listing them. Thank you very much for your efforts in following previous suggestions. /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] CFI flash broken for 8-bit bus
I am still doing some testing and just added a fix today so that if a flash chip that supports both 8 and 16-bits is on an 8-bit bus the interface is set to 8-bits. I'll try and get patches out next week. So far it's working fairly well on all of our boards, most of which have an 8- bit bus but one has a 16-bit bus. I had to change all of the defined addresses for AMD parts and calculate the 16 and 32-bit addresses by applying a mask. The CFI code *should* work if there's an 8-bit part on a 16-bit bus, but it probably will not support two 8-bit parts in parallel. That should be doable with some work. -Aaron On Thursday, March 24, 2011 09:59:07 AM Rogan Dawes wrote: > On 2011/03/24 5:07 AM, Aaron Williams wrote: > > I have it working on our 8-bit boards properly now, though I've only done > > some limited testing. > > > > I basically put in the correct addresses into cfi_flash.h and updated > > various addresses for 8-bit support. The problem was that the CFI code > > was written using the 16-bit addresses which don't work for an 8-bit > > bus. > > > > I added a mask which is used to calculate the correct address for 16 and > > 32- bit busses. I have only been able to test with 8-bit and 16-bit > > Spansion devices though. > > > > -Aaron > > Hi Aaron, > > I'm happy to test it, when you post the patch. > > Regards, > > Rogan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
