[U-Boot] [PATCH] ARM: make timer variables in gt_t available for all ARM platforms
After ARM relocation,
any code executed directly or indirectly by board_init_f() have
global (BSS) variables need to be fixed. mostly timer.c needs to
fix on most of the ARM platforms.
This patch makes timer related variables in gd_t available for
all ARM implementation
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
arch/arm/include/asm/global_data.h |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h
index ada3fbb..efb502e 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -55,7 +55,9 @@ typedef struct global_data {
unsigned long plla_rate_hz;
unsigned long pllb_rate_hz;
unsigned long at91_pllb_usb_init;
- /* static data needed by at91's timer.c */
+#endif
+#ifdef CONFIG_ARM
+ /* static data needed by most of timer.c on ARM platforms */
unsigned long timer_rate_hz;
unsigned long tbl;
unsigned long tbu;
--
1.6.0.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] onenand_ipl config.mk cleanup (was: no subject)
Dear Minkyu Kang, In message aanlktik64heh+ooov9k10pixh9h=gdxqrqyys8er-...@mail.gmail.com you wrote: onenand_ipl/board/apollon/config.mk and onenand_ipl/board/vpac270/config.mk define CONFIG_SYS_TEXT_BASE; do you think it is possible to move these definitions into the respective board config files and remove the then empty config.mk files? It is hard to move into board config file, because of usually use different TEXT_BASE on IPL. Well, we can probably use #ifdef's, like we do for boards that boot from NAND flash, which have essentially the same situation. I think, it can be moved into Makefile directly. No, that's not a good idea. Makefiles should not contain configuration data. I want to move as much of this as possible into the board config files, so we have it all in a single place. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A failure will not appear until a unit has passed final inspection. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [TEST] arm:board_init_f(): mirror BSS and check after each init_fnc()
This is only a patch to test if BSS was accessed in any function in init
function array!
DO NOT APPLY TO MAINLINE!
To run the test adopt the bss_mirror value to point somwhere in RAM with
sufficient space!
A step by step guide is like this:
* apply the patch
* adopt bss_mirror in arch/arm/lib/board.c:board_init_f()
* build and run like always
* search for something like: 'BSS got corrupted after init_fnc @ 0x20100478'
after banner
* use objdump to search the symbol
---8---
arm-unknown-linux-gnueabi-objdump -S ../build_uboot-at91rm9200ek/u-boot |
grep 20100478
20100478 timer_init:
20100478:e59f3064ldr r3, [pc, #100] ; 201004e4
timer_init+0x6c
---8---
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
---
arch/arm/lib/board.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 1fd5f83..890e6f1 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -274,6 +274,10 @@ void board_init_f (ulong bootflag)
init_fnc_t **init_fnc_ptr;
gd_t *id;
ulong addr, addr_sp;
+ uint32_t *bss_mirror;
+ uint32_t *bss_start;
+ size_t bss_length;
+ init_fnc_t *break_bss = NULL;
/* Pointer is writable since we allocated a register for it */
gd = (gd_t *) (CONFIG_SYS_INIT_SP_ADDR);
@@ -284,12 +288,26 @@ void board_init_f (ulong bootflag)
gd-mon_len = _bss_end_ofs;
+ /* take a location in SDRAM which might be free */
+ bss_mirror = (uint32_t*)(CONFIG_SYS_SDRAM_BASE + 0x60);
+ bss_start = (uint32_t*)(_bss_start_ofs + _TEXT_BASE);
+ bss_length = _bss_end_ofs - _bss_start_ofs;
+ memcpy((void*)bss_mirror, (void*)bss_start, bss_length);
+
for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
if ((*init_fnc_ptr)() != 0) {
hang ();
}
+ if (!break_bss)
+ if (memcmp((void*)bss_mirror, bss_start, bss_length) !=
0)
+ break_bss = *init_fnc_ptr;
}
+ if (break_bss)
+ printf(BSS got corrupted after init_fnc @ 0x%p\n, *break_bss);
+ else
+ printf(BSS is still OK after init_fnc\n);
+
debug (monitor len: %08lX\n, gd-mon_len);
/*
* Ram is setup, size stored in gd !!
--
1.7.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] BLOCK: Add freescale IMX51 PATA driver
On 12/01/2010 06:34 AM, Wolfgang Denk wrote: Dear Marek Vasut, In message 201012010346.21897.marek.va...@gmail.com you wrote: On efikamx, I'll soon submit it mainline (when I clean it up enough). Here's the relevant part of configuration file (the #define __io is actually the important thing): Is there a way to do without this? #define __io I mean, these empty defines look pretty bogus to me. I have found several boards with the same behavior: include/configs/mv-common.h:#define __io include/configs/r2dplus.h:#define __io include/configs/edminiv2.h:#define __io include/configs/nhk8815.h:#define __io(a)((void __iomem *)(PCI_IO_VADDR + (a))) include/configs/r7780mp.h:#define __io __io is defined if CMD_IDE is set for most of them, meaning CMD_IDE requires this define, even if it has no particular meaning for the processor we are using. It seems to me that defining __io is only required for enabling the switch inside arch/arm/include/asm/io.h: #ifdef __io #define outsb(p,d,l)__raw_writesb(__io(p),d,l) ... Really __io should accept a parameter to make some casting, as I can see in the blackfin architecture. Except the nhk8815 board, no parameter is accepted and the define enables only the #ifdef switch. Probably there is a better way to do this ;-). Could be maybe better to define __io inside io.h if it is not already defined by a board ? 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] [TEST] arm:board_init_f(): mirror BSS and check after each init_fnc()
Le 01/12/2010 09:10, Andreas Bießmann a écrit : This is only a patch to test if BSS was accessed in any function in init function array! DO NOT APPLY TO MAINLINE! Nice helping tool. Thanks! One small question * adopt bss_mirror in arch/arm/lib/board.c:board_init_f() What do you mean exactly by this? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2010.12-rc2 released
Hi Ben, On Wed, Dec 01, 2010 at 01:20:36, Ben Gardiner wrote: On Tue, Nov 30, 2010 at 10:00 AM, Wolfgang Denk w...@denx.de wrote: Hello everybody. I apologise for being a bit late with this announcement: * U-Boot v2010.12-rc2 was released on Sunday, November 28. * Release v2010.12 is (still) scheduled in 13 days: on December 13, 2010. Please help testing, and check if all your relevant patches have been included. da850evm was broken by commit 4f6fc15b42776b12244af8aa28da42c8e6497742 Author: Sekhar Nori nsek...@ti.com Date: Fri Nov 19 11:39:48 2010 -0500 DA850 EVM: passing maximum clock rate information to kernel The TI DA850/OMAP-L138/AM18x EVM can be populated with devices having different maximum allowed CPU clock rating. The maximum clock the chip can support can only be determined from the label on the package (not software readable). Introduce a method to pass the maximum allowed clock rate information to kernel using ATAG_REVISION. The kernel uses this information to determine the maximum cpu clock rate reachable using cpufreq. Note that U-Boot itself does not set the CPU clock rate. The CPU clock is setup by a primary bootloader (UBL). The rate setup by UBL could be different from the maximum clock rate supported by the device. Signed-off-by: Sekhar Nori nsek...@ti.com Signed-off-by: Sandeep Paulraj s-paul...@ti.com With the introduction of this patch the board freezes after UBL jumps to 0xC108; however, I don't think it was the implementation in this patch that caused the breakage. Hmm, I had tested DA850 EVM yesterday with U-Boot 2010.12-rc2, and was able to successfully boot (at least most of the times). ---logs Booting with TI UBL Device OPP (300MHz, 1.2V) U-Boot 2010.12-rc2 (Nov 30 2010 - 11:55:35) I2C: ready DRAM: 128 MiB Using default environment In:serial Out: serial Err: serial Net: Ethernet PHY: GENERIC @ 0x00 DA850-evm Some of the times, the boot hung after printing DRAM: 128 MiB, but never did it hang without printing anything. Removing the added #define CONFIG_REVISION_TAG does not fix the freeze. Furthermore, reverting the patch on top of 2010.12-rc2 does not fix the freeze either. Finally to add to the (/my) confusion, Ah, that is a sure indication that the issue is elsewhere. adding OPTFLAGS=-O0 -g to 4f6fc15b42776b12244af8aa28da42c8e6497742^ (the commit parent) results in a boot freeze, where there was none before the addition of the compiler flags. I suppose we should be suspecting the timers? I think I recall hearing that the time code can mix poorly with relocation. I am not sure about that (haven't been following all the relocation related changes lately). Since it is booting for me, may be it is related to the build environment? I am using CodeSourcery 2009q1-203 for building the U-Boot. Thanks, Sekhar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [TEST] arm:board_init_f(): mirror BSS and check after each init_fnc()
Dear Albert ARIBAUD, Am 01.12.2010 10:37, schrieb Albert ARIBAUD: Le 01/12/2010 09:10, Andreas Bießmann a écrit : * adopt bss_mirror in arch/arm/lib/board.c:board_init_f() What do you mean exactly by this? this parameter needs to be adopted by SoC/board tester. In short words, adopt that line to your needs: ---8--- + bss_mirror = (uint32_t*)(CONFIG_SYS_SDRAM_BASE + 0x60); ---8--- The tester have to place the 'bss_mirror' space to an appropriate value. at91rm9200ek does have 32MiB of SDRAM, the topmost part is always used for stack, GD, u-boot after relocation a.s.o. I usually use the RAMBOOT configuration of at91rm9200ek. In that case TEXT_BASE is SDRAM_BASE + 0x10. Therefore I use here 0x60 (u-boot size plus safety). I can not recommend a proper place for all boards cause this parameter is highly is board specific. regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] TR: u-boot SquashFS
De : PHINEO - ABESSOLO, Gaetan Envoyé : mercredi 1 décembre 2010 10:54 À : 'u-boot-us...@lists.sourceforge.net' Cc : RADA, KAMAL Objet : u-boot SquashFS HI, I am looking for a u-boot that handles SquashFS filesystem ? Did it exist ? if not can I have some indication or recommendation Because I want to try to upgrade u-boot such that it handles SquashFS Regards Gaëtan ABESSOLO Développement des Systèmes Embarqués (DSE) Département Développement des Produits Fixes (DPF) Bouygues Télécom - Technopôle B1-29 Fixe: +33181751379 Mobile: +33616065864 gabes...@bouyguestelecom.frmailto:lmarc...@bouyguestelecom.fr L'intégrité de ce message n'étant pas assurée sur internet, la société expéditrice ne peut être tenue responsable de son contenu ni de ses pièces jointes. Toute utilisation ou diffusion non autorisée est interdite. Si vous n'êtes pas destinataire de ce message, merci de le détruire et d'avertir l'expéditeur. The integrity of this message cannot be guaranteed on the Internet. The company that sent this message cannot therefore be held liable for its content nor attachments. Any unauthorized use or dissemination is prohibited. If you are not the intended recipient of this message, then please delete it and notify the sender. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 0/7] Add Marvell New Soc Support ARMADA100
This patch series adds basic ARMADA100 support, with minimal drivers (UART, MFP) support and Aspenite-DB board support for simple boot Changelog v2: 1. This patch series is in sync latest u-boot 2. config.mk removed 3. CONFIG_SYS_NS16550_IER used for serial drivers 4. mv-common.h updated for aspenite support 5. c-struct used for dram.c 6. All review feedback for v1 implemented Changelog v3: 1. timer.c: timer variables in gt_t used insted of locally defined global variables 2. timer.c: register global pointer moved to respective functions 3. timer.c: Macro READ_TIMER converted to function read_timer() 4. armada100.h: c-struc in armada100.h fixed for wrong padding 5. macro defination CONFIG_SYS_NS16550_IER moved from ns16550.h to ns16550.c 6. Removed reordiring of header files in serial.c, the diff is only limited to include armada100.h 7. mv-common.h: CONFIG_ARCH_CPU_INIT moved out of #ifdef 8. aspenite.h: #define DEBUG removed These patches are tested on board Fo sucessfull build, these patches are dependent upon a patch. ARM: make timer variables in gt_t available for all ARM platforms ref: http://lists.denx.de/pipermail/u-boot/2010-December/082834.html Regards.. Prafulla . . *** BLURB HERE *** Prafulla WADASKAR (2): arm: Add Support for Marvell ARMADA 100 Familiy SoCs. Armada100: Add Board Support for Marvell Aspenite-DB Prafulla Wadaskar (5): gpio: Add Multi-Function-Pin configuration driver for Marvell SoCs add Multi Function Pin configuration support for ARMADA100 Serial: ns16550: Add support for CONFIG_SYS_NS16550_IER macro Serial: Add UART support for Marvell ARMADA 100 SoCs. mv-common.h: Add support for ARMADA100 Platforms MAINTAINERS |1 + MAKEALL |1 + arch/arm/cpu/arm926ejs/armada100/Makefile | 46 + arch/arm/cpu/arm926ejs/armada100/cpu.c | 92 ++ arch/arm/cpu/arm926ejs/armada100/dram.c | 131 ++ arch/arm/cpu/arm926ejs/armada100/timer.c| 207 + arch/arm/include/asm/arch-armada100/armada100.h | 121 + arch/arm/include/asm/arch-armada100/cpu.h | 53 ++ arch/arm/include/asm/arch-armada100/mfp.h | 218 +++ board/Marvell/aspenite/Makefile | 52 ++ board/Marvell/aspenite/aspenite.c | 53 ++ boards.cfg |1 + drivers/gpio/Makefile |1 + drivers/gpio/mfp.c | 105 +++ drivers/serial/ns16550.c|8 +- drivers/serial/serial.c |5 +- include/configs/aspenite.h | 63 +++ include/configs/mv-common.h | 65 +-- include/mfp.h | 97 ++ 19 files changed, 1300 insertions(+), 20 deletions(-) create mode 100644 arch/arm/cpu/arm926ejs/armada100/Makefile create mode 100644 arch/arm/cpu/arm926ejs/armada100/cpu.c create mode 100644 arch/arm/cpu/arm926ejs/armada100/dram.c create mode 100644 arch/arm/cpu/arm926ejs/armada100/timer.c create mode 100644 arch/arm/include/asm/arch-armada100/armada100.h create mode 100644 arch/arm/include/asm/arch-armada100/cpu.h create mode 100755 arch/arm/include/asm/arch-armada100/mfp.h create mode 100644 board/Marvell/aspenite/Makefile create mode 100644 board/Marvell/aspenite/aspenite.c create mode 100644 drivers/gpio/mfp.c create mode 100644 include/configs/aspenite.h create mode 100644 include/mfp.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/7] gpio: Add Multi-Function-Pin configuration driver for Marvell SoCs
Most of the Marvell SoCs has Multi Function Pin (MFP) configuration registers
For ex. ARMADA100.
These registers are programmed to expose the specific functionality
associated with respective SoC Pins
This driver provides configuration APIs,
using them, configuration need to be done in board specific code
for ex- following code configures MFPs 107 and 108 for UART_TX/RX functionality
int board_early_init_f(void)
{
u32 mfp_cfg[] = {
/* Console on UART1 */
MFP107_UART1_RXD,
MFP108_UART1_TXD,
MFP_EOC /*End of configureation*/
};
/* configure MFP's */
mfp_config(mfp_cfg);
return 0;
}
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
drivers/gpio/Makefile |1 +
drivers/gpio/mfp.c| 105 +
include/mfp.h | 97 +
3 files changed, 203 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/mfp.c
create mode 100644 include/mfp.h
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 398024c..f6903d5 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -27,6 +27,7 @@ LIB := $(obj)libgpio.o
COBJS-$(CONFIG_AT91_GPIO) += at91_gpio.o
COBJS-$(CONFIG_KIRKWOOD_GPIO) += kw_gpio.o
+COBJS-$(CONFIG_MFP)+= mfp.o
COBJS-$(CONFIG_MXC_GPIO) += mxc_gpio.o
COBJS-$(CONFIG_PCA953X)+= pca953x.o
COBJS-$(CONFIG_S5P)+= s5p_gpio.o
diff --git a/drivers/gpio/mfp.c b/drivers/gpio/mfp.c
new file mode 100644
index 000..a0278db
--- /dev/null
+++ b/drivers/gpio/mfp.c
@@ -0,0 +1,105 @@
+/*
+ * (C) Copyright 2010
+ * Marvell Semiconductor www.marvell.com
+ * Written-by: Prafulla Wadaskar prafu...@marvell.com,
+ *
+ * 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
+ */
+
+#include common.h
+#include asm/io.h
+#include mfp.h
+#include asm/arch/mfp.h
+#ifdef CONFIG_ARMADA100
+#include asm/arch/armada100.h
+#define MFPR_BASE ARMD1_MFPR_BASE;
+#else
+#error Unsupported SoC...
+#endif
+
+/*
+ * mfp_config
+ *
+ * On most of Marvell SoCs (ex. ARMADA100) there is Multi-Funtion-Pin
+ * configuration registers to configure each GPIO/Function pin on the
+ * SoC.
+ *
+ * This function reads the array of values for
+ * MFPR_X registers and programms them into respective
+ * Multi-Function Pin registers.
+ * It supports - Alternate Function Selection programming.
+ *
+ * Whereas,
+ * The Configureation value is constructed using ARMD_MFP()
+ * array consists of 32bit values as-
+ * Bits 31-16 : Mfp instance number (i.e. MFPR no. to be programmed)
+ * Bits 15-13 : PULL_UP/PULL_DOWN selection
+ * Bits 11:10 : Pin Driver strength
+ * Bits 6-4: Edge detection configuration
+ * Bits 2-0: Alternate Function Selection
+ *
+ * For more details please refer respective Product Software Manual
+ */
+void mfp_config(u32 *mfp_cfgs)
+{
+ u32 *p_mfpr = NULL;
+ u32 val, cfg_val, mfpr_no;
+
+ do {
+ cfg_val = *mfp_cfgs++;
+ /* exit if End of configuration table detected */
+ if (cfg_val == MFP_EOC)
+ break;
+ /* abstract mfpr tobe programmed from configuration value */
+ mfpr_no = (cfg_val MFP_PINNO_MASK) 16;
+ BUG_ON(mfpr_no = MFP_PIN_MAX);
+
+ /* the offset address are divided in three regions and not
+* consecutive, this corrects the same (Ref: Specs: A1.1) */
+ p_mfpr = (u32 *)MFPR_BASE;
+ if ( mfpr_no 37)
+ p_mfpr += (0x004c / 4) + mfpr_no;
+ else if ( mfpr_no = 56)
+ p_mfpr += (0x00e0 / 4) + (mfpr_no - 56);
+ else
+ p_mfpr += (mfpr_no - 37);
+ /*p_mfpr contains address of register to be programmed */
+
+ val = readl(p_mfpr) ~MFP_AF_MASK;
+ /* Abstract and program Afternate-Function Selection from
cfg_val */
+ if (cfg_val MFP_CFG_AF)
+ val |= cfg_val MFP_AF_MASK;
+ /* Abstract and program Edge configuration from
[U-Boot] [PATCH v3 1/7] arm: Add Support for Marvell ARMADA 100 Familiy SoCs.
From: Prafulla WADASKAR prafu...@marvell.com
ARMADA 100 Family processors are highly integrated SoCs
based on Sheeva_88SV331x-v5 PJ1 cpu core.
Ref: http://www.marvell.com/products/processors/applications/armada_100
SoC versions Supported:
1) ARMADA168/88AP168(Aspen P)
2) ARMADA166/88AP166(Aspen M)
3) ARMADA162/88AP162(Aspen L)
Contributors:
Eric Miao eric.y.m...@marvell.com
Lei Wen lei...@marvell.com
Mahavir Jain mj...@marvell.com
Signed-off-by: Mahavir Jain mj...@marvell.com
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
Change log V2:
1. C-struct used for dram.c
2. lib declaration changed from .a to .o
3. Implemented review feedback for v1
Changelog V3:
1. timer variables in gt_t used insted of locally defined global variables
2. register global pointer moved to respective functions
3. Macro READ_TIMER converted to function read_timer()
4. c-struc in armada100.h fixed for wrong padding
arch/arm/cpu/arm926ejs/armada100/Makefile | 46 +
arch/arm/cpu/arm926ejs/armada100/cpu.c | 92 ++
arch/arm/cpu/arm926ejs/armada100/dram.c | 131 ++
arch/arm/cpu/arm926ejs/armada100/timer.c| 207 +++
arch/arm/include/asm/arch-armada100/armada100.h | 121 +
arch/arm/include/asm/arch-armada100/cpu.h | 53 ++
6 files changed, 650 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/cpu/arm926ejs/armada100/Makefile
create mode 100644 arch/arm/cpu/arm926ejs/armada100/cpu.c
create mode 100644 arch/arm/cpu/arm926ejs/armada100/dram.c
create mode 100644 arch/arm/cpu/arm926ejs/armada100/timer.c
create mode 100644 arch/arm/include/asm/arch-armada100/armada100.h
create mode 100644 arch/arm/include/asm/arch-armada100/cpu.h
diff --git a/arch/arm/cpu/arm926ejs/armada100/Makefile
b/arch/arm/cpu/arm926ejs/armada100/Makefile
new file mode 100644
index 000..76bd06d
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/armada100/Makefile
@@ -0,0 +1,46 @@
+#
+# (C) Copyright 2010
+# Marvell Semiconductor www.marvell.com
+# Written-by: Prafulla Wadaskar prafu...@marvell.com
+#
+# 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
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(SOC).o
+
+COBJS-y= cpu.o timer.o dram.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS-y))
+
+all: $(obj).depend $(LIB)
+
+$(LIB):$(OBJS)
+ $(AR) $(ARFLAGS) $@ $(OBJS)
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/arch/arm/cpu/arm926ejs/armada100/cpu.c
b/arch/arm/cpu/arm926ejs/armada100/cpu.c
new file mode 100644
index 000..62aa175
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/armada100/cpu.c
@@ -0,0 +1,92 @@
+/*
+ * (C) Copyright 2010
+ * Marvell Semiconductor www.marvell.com
+ * Written-by: Prafulla Wadaskar prafu...@marvell.com
+ * Contributor: Mahavir Jain mj...@marvell.com
+ *
+ * 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
+ */
+
+#include common.h
+#include asm/arch/armada100.h
+#include asm/io.h
+
+#define UARTCLK14745KHZ(APBC_APBCLK | APBC_FNCLK | APBC_FNCLKSEL(1))
+#define SET_MRVL_ID(18)
+#define L2C_RAM_SEL(14)
+
+int arch_cpu_init(void)
+{
+ u32 val;
+ struct armd1cpu_registers *cpuregs =
+ (struct armd1cpu_registers
[U-Boot] [PATCH v3 3/7] add Multi Function Pin configuration support for ARMADA100
This patch adds the support MFP support for Marvell ARMADA100 SoCs Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- arch/arm/include/asm/arch-armada100/mfp.h | 218 + 1 files changed, 218 insertions(+), 0 deletions(-) create mode 100755 arch/arm/include/asm/arch-armada100/mfp.h diff --git a/arch/arm/include/asm/arch-armada100/mfp.h b/arch/arm/include/asm/arch-armada100/mfp.h new file mode 100755 index 000..eddcef7 --- /dev/null +++ b/arch/arm/include/asm/arch-armada100/mfp.h @@ -0,0 +1,218 @@ +/* + * Based on linux/arch/arm/mach-mpp/include/mfp-pxa168.h + * (C) Copyright 2007 + * Marvell Semiconductor www.marvell.com + * 2007-08-21: eric miao eric.m...@marvell.com + * + * (C) Copyright 2010 + * Marvell Semiconductor www.marvell.com + * Written-by: Prafulla Wadaskar prafu...@marvell.com + * Contributor: Mahavir Jain mj...@marvell.com + * + * 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 __ARMADA100_MFP_H +#define __ARMADA100_MFP_H + +/* By default Pin Drive is set to medium */ +#define MFPD(x)MFP(x) | MFP_DRIVE(MEDIUM) + +/* GPIOs */ +#defineGPIOAF(x) (if (x = 15) ? 5 : \ +if (x == 16) ? 0 : \ +if (x == 17) ? 5 : \ +if (x == 18) ? 0 : \ +if (x == 19) ? 5 : \ +if (x == 20) ? 0 : \ +if (x = 25) ? 5 : \ +if (x == 26) ? 0 : \ +if (x == 33) ? 5 : 0) + +#define MFP_GPIO(x)MFPD(x) | MFP_AF(GPIOAF(x)) + +/* UART2 */ +#define MFP47_UART2_RXDMFPD(47) | MFP_AF(6) +#define MFP48_UART2_TXDMFPD(48) | MFP_AF(6) +#define MFP88_UART2_RXDMFPD(88) | MFP_AF(2) +#define MFP89_UART2_TXDMFPD(89) | MFP_AF(2) + +/* UART3 */ +#define GPIO8_UART3_RXD MFPD(8) | MFP_AF(2) +#define GPIO9_UART3_TXD MFPD(9) | MFP_AF(2) + +/* MFU */ +#define MFP86_TX_CLK MFPD(86) | MFP_AF(5) +#define MFP87_TX_ENMFPD(87) | MFP_AF(5) +#define MFP88_TX_DQ3 MFPD(88) | MFP_AF(5) +#define MFP89_TX_DQ2 MFPD(89) | MFP_AF(5) +#define MFP90_TX_DQ1 MFPD(90) | MFP_AF(5) +#define MFP91_TX_DQ0 MFPD(91) | MFP_AF(5) +#define MFP92_MII_CRS MFPD(92) | MFP_AF(5) +#define MFP93_MII_COL MFPD(93) | MFP_AF(5) +#define MFP94_RX_CLK MFPD(94) | MFP_AF(5) +#define MFP95_RX_ERMFPD(95) | MFP_AF(5) +#define MFP96_RX_DQ3 MFPD(96) | MFP_AF(5) +#define MFP97_RX_DQ2 MFPD(97) | MFP_AF(5) +#define MFP98_RX_DQ1 MFPD(98) | MFP_AF(5) +#define MFP99_RX_DQ0 MFPD(99) | MFP_AF(5) +#define MFP100_MII_MDC MFPD(100) | MFP_AF(5) +#define MFP101_MII_MDIOMFPD(101) | MFP_AF(5) +#define MFP103_RX_DV MFPD(103) | MFP_AF(5) + +/* SSP2*/ +#define MFP107_SPI_NOR_RXD MFPD(107) | MFP_AF(4) +#define MFP108_SPI_NOR_TXD MFPD(108) | MFP_AF(4) +#define MFP109_SPI_NOR_SYSCLK MFPD(109) | MFP_AF(4) +#define MFP111_SPI_NOR_CLK MFPD(111) | MFP_AF(4) + +/* DFI */ +#define MFP0_DFI_D15 MFPD(0) | MFP_AF(0) +#define MFP1_DFI_D14 MFPD(1) | MFP_AF(0) +#define MFP2_DFI_D13 MFPD(2) | MFP_AF(0) +#define MFP3_DFI_D12 MFPD(3) | MFP_AF(0) +#define MFP4_DFI_D11 MFPD(4) | MFP_AF(0) +#define MFP5_DFI_D10 MFPD(5) | MFP_AF(0) +#define MFP6_DFI_D9MFPD(6) | MFP_AF(0) +#define MFP7_DFI_D8MFPD(7) | MFP_AF(0) +#define MFP8_DFI_D7MFPD(8) | MFP_AF(0) +#define MFP9_DFI_D6MFPD(9) | MFP_AF(0) +#define MFP10_DFI_D5 MFPD(10) | MFP_AF(0) +#define MFP11_DFI_D4 MFPD(11) | MFP_AF(0) +#define MFP12_DFI_D3 MFPD(12) | MFP_AF(0) +#define MFP13_DFI_D2 MFPD(13) | MFP_AF(0) +#define MFP14_DFI_D1 MFPD(14) | MFP_AF(0) +#define MFP15_DFI_D0 MFPD(15) | MFP_AF(0) + +#define MFP30_DFI_ADDR0MFPD(30) | MFP_AF(0) +#define MFP31_DFI_ADDR1MFPD(31) | MFP_AF(0)
[U-Boot] [PATCH v3 4/7] Serial: ns16550: Add support for CONFIG_SYS_NS16550_IER macro
On some processors this ier register configuration is different
for ex. Marvell Armada100
This patch introduce CONFIG_SYS_NS16550_IER macro support to
unconditionally initialize this register.
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
Changelog v3:
macro defination CONFIG_SYS_NS16550_IER moved from ns16550.h to ns16550.c
drivers/serial/ns16550.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 32f24de..8eeb48f 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -24,9 +24,13 @@
#define serial_in(y) readb(y)
#endif
+#ifndef CONFIG_SYS_NS16550_IER
+#define CONFIG_SYS_NS16550_IER 0x00
+#endif /* CONFIG_SYS_NS16550_IER */
+
void NS16550_init (NS16550_t com_port, int baud_divisor)
{
- serial_out(0x00, com_port-ier);
+ serial_out(CONFIG_SYS_NS16550_IER, com_port-ier);
#if defined(CONFIG_OMAP) !defined(CONFIG_OMAP3_ZOOM2)
serial_out(0x7, com_port-mdr1); /* mode select reset TL16C750*/
#endif
@@ -52,7 +56,7 @@ void NS16550_init (NS16550_t com_port, int baud_divisor)
#ifndef CONFIG_NS16550_MIN_FUNCTIONS
void NS16550_reinit (NS16550_t com_port, int baud_divisor)
{
- serial_out(0x00, com_port-ier);
+ serial_out(CONFIG_SYS_NS16550_IER, com_port-ier);
serial_out(UART_LCR_BKSE | UART_LCRVAL, com_port-lcr);
serial_out(0, com_port-dll);
serial_out(0, com_port-dlm);
--
1.6.0.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 5/7] Serial: Add UART support for Marvell ARMADA 100 SoCs.
ARMADA 100 SoCs has NS16550 compatible UART peripheral This patch enables the same for ARMADA100 platforms Signed-off-by: Mahavir Jain mj...@marvell.com Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- Change log for v2: defined CONFIG_SYS_NS16550_IER macro in Soc heder file Change log for v3: Removed reordiring of header files, the diff is only limited to include armada100.h drivers/serial/serial.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/serial/serial.c b/drivers/serial/serial.c index 1073ac0..cd3439e 100644 --- a/drivers/serial/serial.c +++ b/drivers/serial/serial.c @@ -29,9 +29,10 @@ #endif #ifdef CONFIG_KIRKWOOD #include asm/arch/kirkwood.h -#endif -#ifdef CONFIG_ORION5X +#elif defined(CONFIG_ORION5X) #include asm/arch/orion5x.h +#elif defined(CONFIG_ARMADA100) +#include asm/arch/armada100.h #endif #if defined (CONFIG_SERIAL_MULTI) -- 1.6.0.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 6/7] mv-common.h: Add support for ARMADA100 Platforms
This patch adds commonly used macros for ARMADA100 based baords, Also some code reshuffled and updated for typos and comments Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- Changelog v3: CONFIG_ARCH_CPU_INIT moved out of #ifdef include/configs/mv-common.h | 65 -- 1 files changed, 49 insertions(+), 16 deletions(-) diff --git a/include/configs/mv-common.h b/include/configs/mv-common.h index de0121e..894d005 100644 --- a/include/configs/mv-common.h +++ b/include/configs/mv-common.h @@ -39,6 +39,7 @@ #define CONFIG_MARVELL 1 #define CONFIG_ARM926EJS 1 /* Basic Architecture */ +/* Kirkwood Platform Common Definations */ #if defined(CONFIG_KIRKWOOD) #define CONFIG_MD5 /* get_random_hex on krikwood needs MD5 support */ #define CONFIG_KIRKWOOD_EGIGA_INIT /* Enable GbePort0/1 for kernel */ @@ -54,27 +55,45 @@ #defineCONFIG_SYS_KWD_CONFIG $(SRCTREE)/$(CONFIG_BOARDDIR)/kwbimage.cfg #endif /* CONFIG_SYS_KWD_CONFIG */ -/* - * CONFIG_SYS_TEXT_BASE can be defined in board specific header file, if needed - */ -#ifndef CONFIG_SYS_TEXT_BASE -#defineCONFIG_SYS_TEXT_BASE0x0060 -#endif /* CONFIG_SYS_TEXT_BASE */ +/* Kirkwood has 2k of Security SRAM, use it for SP */ +#define CONFIG_SYS_INIT_SP_ADDR0xC8012000 +#define CONFIG_NR_DRAM_BANKS_MAX 2 #define CONFIG_I2C_MVTWSI_BASE KW_TWSI_BASE -#define MV_UART0_BASE KW_UART0_BASE +#define MV_UART_CONSOLE_BASE KW_UART0_BASE #define MV_SATA_BASE KW_SATA_BASE #define MV_SATA_PORT0_OFFSET KW_SATA_PORT0_OFFSET #define MV_SATA_PORT1_OFFSET KW_SATA_PORT1_OFFSET +/* ARMADA100 Platform Common Definations */ +#elif defined (CONFIG_ARMADA100) + +#define CONFIG_SYS_TCLK(14745600) /* NS16550 clk config */ +#define CONFIG_SYS_HZ_CLOCK(325) /* Timer Freq. 3.25MHZ */ +#define CONFIG_MFP /* Enable MFP driver */ +#define MV_UART_CONSOLE_BASE ARMD1_UART1_BASE +#define CONFIG_SYS_NS16550_IER (1 6)/* Bit 6 in UART_IER register + represents UART Unit Enable */ +/* + * There is no internal RAM in ARMADA100, using DRAM + * TBD: dcache to be used for this + */ +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_TEXT_BASE - 0x0020) +#define CONFIG_NR_DRAM_BANKS_MAX 2 + #else -#error Unsupported SoC +#error Unsupported SoC Platform... #endif +/* + * Custom CONFIG_SYS_TEXT_BASE can be done in board.h + */ +#ifndef CONFIG_SYS_TEXT_BASE +#defineCONFIG_SYS_TEXT_BASE0x0060 +#endif /* CONFIG_SYS_TEXT_BASE */ + /* additions for new ARM relocation support */ -#define CONFIG_SYS_SDRAM_BASE 0x -/* Kirkwood has 2k of Security SRAM, use it for SP */ -#define CONFIG_SYS_INIT_SP_ADDR0xC8012000 +#define CONFIG_SYS_SDRAM_BASE 0x /* * CLKs configurations @@ -88,7 +107,7 @@ #define CONFIG_SYS_NS16550_SERIAL #define CONFIG_SYS_NS16550_REG_SIZE(-4) #define CONFIG_SYS_NS16550_CLK CONFIG_SYS_TCLK -#define CONFIG_SYS_NS16550_COM1MV_UART0_BASE +#define CONFIG_SYS_NS16550_COM1MV_UART_CONSOLE_BASE /* * Serial Port configuration @@ -156,25 +175,37 @@ #define CONFIG_CMDLINE_EDITING #define CONFIG_CONSOLE_INFO_QUIET /* some code reduction */ #define CONFIG_ARCH_CPU_INIT /* call arch_cpu_init() */ +#ifndef CONFIG_ARMADA100 /* will be removed latter */ #define CONFIG_ARCH_MISC_INIT /* call arch_misc_init() */ +#endif /* CONFIG_ARMADA100 */ #define CONFIG_BOARD_EARLY_INIT_F /* call board_init_f for early inits */ #define CONFIG_DISPLAY_CPUINFO /* Display cpu info */ -#define CONFIG_NR_DRAM_BANKS 4 #define CONFIG_STACKSIZE 0x0010 /* regular stack- 1M */ #define CONFIG_SYS_LOAD_ADDR 0x0080 /* default load adr- 8M */ -#define CONFIG_SYS_MEMTEST_START 0x0040/* 4M */ -#define CONFIG_SYS_MEMTEST_END 0x007f /*(_8M -1) */ +#define CONFIG_SYS_MEMTEST_START 0x0080/* 8M */ +#define CONFIG_SYS_MEMTEST_END 0x00ff /*(_16M -1) */ #define CONFIG_SYS_RESET_ADDRESS 0x/* Rst Vector Adr */ #define CONFIG_SYS_MAXARGS 16 /* max number of command args */ /* + * DRAM Banks configuration, Custom config can be done in board.h + */ +#ifndef CONFIG_NR_DRAM_BANKS +#define CONFIG_NR_DRAM_BANKS CONFIG_NR_DRAM_BANKS_MAX +#else +#if (CONFIG_NR_DRAM_BANKS CONFIG_NR_DRAM_BANKS_MAX) +#error CONFIG_NR_DRAM_BANKS Configurated more than available +#endif +#endif /* CONFIG_NR_DRAM_BANKS */ + +/* * Ethernet Driver configuration */ #ifdef CONFIG_CMD_NET #define CONFIG_CMD_MII #define CONFIG_NETCONSOLE /* include NetConsole support */ #define CONFIG_NET_MULTI /* specify more that one ports available */ -#defineCONFIG_MII /* expose smi ove miiphy interface */ +#define CONFIG_MII /*
[U-Boot] [PATCH v3 7/7] Armada100: Add Board Support for Marvell Aspenite-DB
From: Prafulla WADASKAR prafu...@marvell.com Aspenite is a Development Board for ASPEN/ARMADA168(88AP168) with * Processor upto 1.2GHz * Parallel 1Gb x8 DDR2-1066 MHz * 16 Mb x16 NOR, 4Gb x8 SLC NAND, footprint for SPI NOR * Footprints for eMMC/eSD NAND MMC x8 card * 4-in-1 card reader (xD, MMC/SD/MS Pro), CF True IDE socket * SEAF memory board, subset of PISMO2 With Peripherals: * 4.3â WVGA 24-bit LCD * Audio codecs (AC97 I2S), TSI * VGA camera * Video in via 3 RCA jacks, and HDMI type C out * Marvell 88W8688 802.11bg/BT module * GPS RF IC * Dual analog mics speakers, headset jack, LED, ambient light sensor * USB2.0 HS host (A), OTG (micro AB) * FE PHY, PCIE Mini Card slot * GPIO, GPIO expander with DIP switches for easier selection UART serial over USB, CIR This patch adds basic board support with DRAM and UART functionality The patch is tested for boot from DRAM using XDB Signed-off-by: Mahavir Jain mj...@marvell.com Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- Change log for v2: used mv-common.h defined CONFIG_SYS_NS16550_IER macro in Soc heder file removed config.mk Change log for v3: DEBUG removed from aspenite.h MAINTAINERS |1 + MAKEALL |1 + board/Marvell/aspenite/Makefile | 52 ++ board/Marvell/aspenite/aspenite.c | 53 +++ boards.cfg|1 + include/configs/aspenite.h| 63 + 6 files changed, 171 insertions(+), 0 deletions(-) create mode 100644 board/Marvell/aspenite/Makefile create mode 100644 board/Marvell/aspenite/aspenite.c create mode 100644 include/configs/aspenite.h diff --git a/MAINTAINERS b/MAINTAINERS index 9bf52fa..66f8585 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -838,6 +838,7 @@ Matt Waddel matt.wad...@linaro.org Prafulla Wadaskar prafu...@marvell.com + aspeniteARM926EJS (ARMADA100 88AP168 SoC) mv88f6281gtw_ge ARM926EJS (Kirkwood SoC) rd6281a ARM926EJS (Kirkwood SoC) sheevaplug ARM926EJS (Kirkwood SoC) diff --git a/MAKEALL b/MAKEALL index 767d561..e83c9d7 100755 --- a/MAKEALL +++ b/MAKEALL @@ -326,6 +326,7 @@ LIST_ARM9= \ ap926ejs\ ap946es \ ap966 \ + aspenite\ cp920t \ cp922_XA10 \ cp926ejs\ diff --git a/board/Marvell/aspenite/Makefile b/board/Marvell/aspenite/Makefile new file mode 100644 index 000..cb1b65f --- /dev/null +++ b/board/Marvell/aspenite/Makefile @@ -0,0 +1,52 @@ +# +# (C) Copyright 2010 +# Marvell Semiconductor www.marvell.com +# Written-by: Prafulla Wadaskar prafu...@marvell.com +# Contributor: Mahavir Jain mj...@marvell.com +# +# 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 +# + +include $(TOPDIR)/config.mk + +LIB = $(obj)lib$(BOARD).o + +COBJS := aspenite.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak .depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/Marvell/aspenite/aspenite.c b/board/Marvell/aspenite/aspenite.c new file mode 100644 index 000..e7bc3eb --- /dev/null +++ b/board/Marvell/aspenite/aspenite.c @@ -0,0 +1,53 @@ +/* + * (C) Copyright 2010 + * Marvell Semiconductor www.marvell.com + * Written-by: Prafulla Wadaskar prafu...@marvell.com + * Contributor: Mahavir Jain mj...@marvell.com + * + * 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
Re: [U-Boot] TR: u-boot SquashFS
Dear PHINEO - ABESSOLO, Gaetan, In message 3de1e8ba73bbb34c98eb4c91a7fa69650102948d3...@bt1fmsgs11.bt0d.w2k.bouyguestelecom.fr you wrote: I am looking for a u-boot that handles SquashFS filesystem ? Did it exist ? if not can I have some indication or recommendation Because I want to try to upgrade u-boot such that it handles SquashFS I don't know if any custom ports with support for SquashFS exist, but in any case no such code has been submitted to mainline yet. L'int=E9grit=E9 de ce message n'=E9tant pas assur=E9e sur internet, la soci= =E9t=E9 exp=E9ditrice ne peut =EAtre tenue responsable de son contenu ni de= ses pi=E8ces jointes. Toute utilisation ou diffusion non autoris=E9e est i= nterdite. Si vous n'=EAtes pas destinataire de ce message, merci de le d=E9= truire et d'avertir l'exp=E9diteur. Please omit such crap when posting to a public mailing list. 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 Cigarette, n.: A fire at one end, a fool at the other, and a bit of tobacco in between. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2010.12-rc2 released
On Tuesday, November 30, 2010 10:00:20 Wolfgang Denk wrote: Current status is still a bit wobbly. Power Architecture appears to look reasonably well again. ARM has still a lot of broken boards (which is not unexpected), but a number of fixes have been sent recently, so I guess we will see some improvment in the next few days. I didn't test much for other architectures. Comments and especially patches welcome. Blackfin seems to be ok now that your env patches have been merged -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [TEST] arm:board_init_f(): mirror BSS and check after each init_fnc()
hi Andreas, Le 01/12/2010 11:05, Andreas Bießmann a écrit : I can not recommend a proper place for all boards cause this parameter is highly is board specific. Understood -- each board maintainer must select an adapted location for the mirror. regards Andreas Bießmann Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] boot cmds: convert to getenv_yesno() with autostart
On Sunday, November 28, 2010 16:02:49 Wolfgang Denk wrote: Mike Frysinger wrote: Use the new helper func to clean up duplicate logic handling of the autostart env var. Signed-off-by: Mike Frysinger vap...@gentoo.org --- common/cmd_fdc.c |3 +-- common/cmd_fdos.c |2 +- common/cmd_ide.c |2 +- common/cmd_nand.c |4 ++-- common/cmd_net.c |2 +- common/cmd_scsi.c |2 +- common/cmd_usb.c |2 +- 7 files changed, 8 insertions(+), 9 deletions(-) Applied to next branch, thanks. hrm, after running this through our test bench, it seems the old code and new code are not functionality equivalent. it boils down to default values when the env var is not set. some places interpret this to mean yes while others expect no. getenv_yesno() takes the no default which doesnt always work. i can update the API to take a 2nd arg (the default value), or we can punt this patch. it's in next, so there's less pressure to get it fixed immediately ... -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/7] [REPOST] gpio: Add Multi-Function-Pin configuration driver for Marvell SoCs
Most of the Marvell SoCs has Multi Function Pin (MFP) configuration registers
For ex. ARMADA100.
These registers are programmed to expose the specific functionality
associated with respective SoC Pins
This driver provides configuration APIs,
using them, configuration need to be done in board specific code
for ex- following code configures MFPs 107 and 108 for UART_TX/RX functionality
int board_early_init_f(void)
{
u32 mfp_cfg[] = {
/* Console on UART1 */
MFP107_UART1_RXD,
MFP108_UART1_TXD,
MFP_EOC /*End of configureation*/
};
/* configure MFP's */
mfp_config(mfp_cfg);
return 0;
}
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
Please Ignore earlier patch, below bufix is added to this patch
Change log v3:
Fixed: Read-modify-Write a mfg register as per configuration
ANDed with MASK value before ORing for each configuration
drivers/gpio/Makefile |1 +
drivers/gpio/mfp.c| 110 +
include/mfp.h | 97 +++
3 files changed, 208 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/mfp.c
create mode 100644 include/mfp.h
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 398024c..f6903d5 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -27,6 +27,7 @@ LIB := $(obj)libgpio.o
COBJS-$(CONFIG_AT91_GPIO) += at91_gpio.o
COBJS-$(CONFIG_KIRKWOOD_GPIO) += kw_gpio.o
+COBJS-$(CONFIG_MFP)+= mfp.o
COBJS-$(CONFIG_MXC_GPIO) += mxc_gpio.o
COBJS-$(CONFIG_PCA953X)+= pca953x.o
COBJS-$(CONFIG_S5P)+= s5p_gpio.o
diff --git a/drivers/gpio/mfp.c b/drivers/gpio/mfp.c
new file mode 100644
index 000..f26af97
--- /dev/null
+++ b/drivers/gpio/mfp.c
@@ -0,0 +1,110 @@
+/*
+ * (C) Copyright 2010
+ * Marvell Semiconductor www.marvell.com
+ * Written-by: Prafulla Wadaskar prafu...@marvell.com,
+ *
+ * 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
+ */
+
+#include common.h
+#include asm/io.h
+#include mfp.h
+#include asm/arch/mfp.h
+#ifdef CONFIG_ARMADA100
+#include asm/arch/armada100.h
+#define MFPR_BASE ARMD1_MFPR_BASE;
+#else
+#error Unsupported SoC...
+#endif
+
+/*
+ * mfp_config
+ *
+ * On most of Marvell SoCs (ex. ARMADA100) there is Multi-Funtion-Pin
+ * configuration registers to configure each GPIO/Function pin on the
+ * SoC.
+ *
+ * This function reads the array of values for
+ * MFPR_X registers and programms them into respective
+ * Multi-Function Pin registers.
+ * It supports - Alternate Function Selection programming.
+ *
+ * Whereas,
+ * The Configureation value is constructed using ARMD_MFP()
+ * array consists of 32bit values as-
+ * Bits 31-16 : Mfp instance number (i.e. MFPR no. to be programmed)
+ * Bits 15-13 : PULL_UP/PULL_DOWN selection
+ * Bits 11:10 : Pin Driver strength
+ * Bits 6-4: Edge detection configuration
+ * Bits 2-0: Alternate Function Selection
+ *
+ * For more details please refer respective Product Software Manual
+ */
+void mfp_config(u32 *mfp_cfgs)
+{
+ u32 *p_mfpr = NULL;
+ u32 val, cfg_val, mfpr_no;
+
+ do {
+ cfg_val = *mfp_cfgs++;
+ /* exit if End of configuration table detected */
+ if (cfg_val == MFP_EOC)
+ break;
+ /* abstract mfpr tobe programmed from configuration value */
+ mfpr_no = (cfg_val MFP_PINNO_MASK) 16;
+ BUG_ON(mfpr_no = MFP_PIN_MAX);
+
+ /* the offset address are divided in three regions and not
+* consecutive, this corrects the same (Ref: Specs: A1.1) */
+ p_mfpr = (u32 *)MFPR_BASE;
+ if ( mfpr_no 37)
+ p_mfpr += (0x004c / 4) + mfpr_no;
+ else if ( mfpr_no = 56)
+ p_mfpr += (0x00e0 / 4) + (mfpr_no - 56);
+ else
+ p_mfpr += (mfpr_no - 37);
+ /*p_mfpr contains address of register to be programmed */
+
+ /* Read-modify-Write a mfg register as per configuration */
+ val =
[U-Boot] [PATCH v3 3/7] [REPOST-1] gpio: Add Multi-Function-Pin configuration driver for Marvell SoCs
Most of the Marvell SoCs has Multi Function Pin (MFP) configuration registers
For ex. ARMADA100.
These registers are programmed to expose the specific functionality
associated with respective SoC Pins
This driver provides configuration APIs,
using them, configuration need to be done in board specific code
for ex- following code configures MFPs 107 and 108 for UART_TX/RX functionality
int board_early_init_f(void)
{
u32 mfp_cfg[] = {
/* Console on UART1 */
MFP107_UART1_RXD,
MFP108_UART1_TXD,
MFP_EOC /*End of configureation*/
};
/* configure MFP's */
mfp_config(mfp_cfg);
return 0;
}
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
Please Ignore earlier patch, below bufix is added to this patch
Change log v3:
Fixed: Read-modify-Write a mfg register as per configuration
ANDed with MASK value before ORing for each configuration
REPOST-V1:
I am sorry for the repost-V1 :-(
MASK values changed to relevent (copy paste mistake)
Regards..
Prafulla . .
drivers/gpio/Makefile |1 +
drivers/gpio/mfp.c| 110 +
include/mfp.h | 97 +++
3 files changed, 208 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/mfp.c
create mode 100644 include/mfp.h
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 398024c..f6903d5 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -27,6 +27,7 @@ LIB := $(obj)libgpio.o
COBJS-$(CONFIG_AT91_GPIO) += at91_gpio.o
COBJS-$(CONFIG_KIRKWOOD_GPIO) += kw_gpio.o
+COBJS-$(CONFIG_MFP)+= mfp.o
COBJS-$(CONFIG_MXC_GPIO) += mxc_gpio.o
COBJS-$(CONFIG_PCA953X)+= pca953x.o
COBJS-$(CONFIG_S5P)+= s5p_gpio.o
diff --git a/drivers/gpio/mfp.c b/drivers/gpio/mfp.c
new file mode 100644
index 000..f26af97
--- /dev/null
+++ b/drivers/gpio/mfp.c
@@ -0,0 +1,110 @@
+/*
+ * (C) Copyright 2010
+ * Marvell Semiconductor www.marvell.com
+ * Written-by: Prafulla Wadaskar prafu...@marvell.com,
+ *
+ * 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
+ */
+
+#include common.h
+#include asm/io.h
+#include mfp.h
+#include asm/arch/mfp.h
+#ifdef CONFIG_ARMADA100
+#include asm/arch/armada100.h
+#define MFPR_BASE ARMD1_MFPR_BASE;
+#else
+#error Unsupported SoC...
+#endif
+
+/*
+ * mfp_config
+ *
+ * On most of Marvell SoCs (ex. ARMADA100) there is Multi-Funtion-Pin
+ * configuration registers to configure each GPIO/Function pin on the
+ * SoC.
+ *
+ * This function reads the array of values for
+ * MFPR_X registers and programms them into respective
+ * Multi-Function Pin registers.
+ * It supports - Alternate Function Selection programming.
+ *
+ * Whereas,
+ * The Configureation value is constructed using ARMD_MFP()
+ * array consists of 32bit values as-
+ * Bits 31-16 : Mfp instance number (i.e. MFPR no. to be programmed)
+ * Bits 15-13 : PULL_UP/PULL_DOWN selection
+ * Bits 11:10 : Pin Driver strength
+ * Bits 6-4: Edge detection configuration
+ * Bits 2-0: Alternate Function Selection
+ *
+ * For more details please refer respective Product Software Manual
+ */
+void mfp_config(u32 *mfp_cfgs)
+{
+ u32 *p_mfpr = NULL;
+ u32 val, cfg_val, mfpr_no;
+
+ do {
+ cfg_val = *mfp_cfgs++;
+ /* exit if End of configuration table detected */
+ if (cfg_val == MFP_EOC)
+ break;
+ /* abstract mfpr tobe programmed from configuration value */
+ mfpr_no = (cfg_val MFP_PINNO_MASK) 16;
+ BUG_ON(mfpr_no = MFP_PIN_MAX);
+
+ /* the offset address are divided in three regions and not
+* consecutive, this corrects the same (Ref: Specs: A1.1) */
+ p_mfpr = (u32 *)MFPR_BASE;
+ if ( mfpr_no 37)
+ p_mfpr += (0x004c / 4) + mfpr_no;
+ else if ( mfpr_no = 56)
+ p_mfpr += (0x00e0 / 4) + (mfpr_no - 56);
+ else
+ p_mfpr += (mfpr_no - 37);
+ /*p_mfpr contains address of register
Re: [U-Boot] [STATUS] v2010.12-rc2 released
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wolfgang Denk Sent: Tuesday, November 30, 2010 8:30 PM To: u-boot@lists.denx.de Subject: [U-Boot] [STATUS] v2010.12-rc2 released Hello everybody. I apologise for being a bit late with this announcement: * U-Boot v2010.12-rc2 was released on Sunday, November 28. * Release v2010.12 is (still) scheduled in 13 days: on December 13, 2010. Please help testing, and check if all your relevant patches have been included. Tested for Kirkwood boards, build and execution is sucessfull. Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [TEST] arm:board_init_f(): mirror BSS and check after each init_fnc()
Dear Albert ARIBAUD, Am 01.12.2010 12:36, schrieb Albert ARIBAUD: hi Andreas, Le 01/12/2010 11:05, Andreas Bießmann a écrit : I can not recommend a proper place for all boards cause this parameter is highly is board specific. Understood -- each board maintainer must select an adapted location for the mirror. Yes, but I have one thing to mention. This test does only detect writing to BSS values in one of the init_sequence[] functions. In my case I detected arch/arm/cpu/arm920t/at91/timer.c as faulty. But I still have some issues booting at91rm9200ek from NOR flash. None of the init_sequence[] functions writes to a BSS value in that case ... So if the 'corrupted .dyn.rel' thing is my problem in NOR booting case .dyn.rel got corrupted before board_init_f() or by some other function call between for loop of init_sequence[] and relocate_code() ... I don't know if I get this until release of v2010.12. Maybe another maintainer is more lucky ... regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [TEST] arm:board_init_f(): mirror BSS and check after each init_fnc()
Hi Andreas, Le 01/12/2010 13:12, Andreas Bießmann a écrit : But I still have some issues booting at91rm9200ek from NOR flash. None of the init_sequence[] functions writes to a BSS value in that case ... So if the 'corrupted .dyn.rel' thing is my problem in NOR booting case .dyn.rel got corrupted before board_init_f() or by some other function call between for loop of init_sequence[] and relocate_code() ... I don't know if I get this until release of v2010.12. Please post a new message (or an update to the existing thread) for this issue; indicate the exact symptom, the build chain in case it matters, which commit/branch/tag you last tried and any patches necessary. I'll try to reproduce the build and analyze the readelf/objdump to see if (and then hopefully why) the .rel.dyn and .dynsym tables get corrupted. regards Andreas Bießmann Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [TEST] arm:board_init_f(): mirror BSS and check after each init_fnc()
Dear Albert ARIBAUD, In message 4cf63345.9020...@free.fr you wrote: I can not recommend a proper place for all boards cause this parameter is highly is board specific. Understood -- each board maintainer must select an adapted location for the mirror. I'm not conviced that ech board maintainer should do that, and I somewhat doubt the approach taken. The main purpose of the patch (as I see it) is to find out which functions might be candidates to write to bss too early. There is not that much board specific code involved there. If we can generate a slist of functions that are called before relocation, we can use nm to check if these refernce any sumbols in bss. We could even generate black / white lists. 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 Roses are red Violets are blue Some poems rhyme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] at91rm9200ek NOR booting is broken
Dear Albert Aribaud, as mentioned in another thread here is the description of broken at91rm9200ek NOR booting. I use the patchset posted in http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/89974 on top of v2010.12-rc2 tag. I configure the code for 'at91rm9200ek_config' and build that with a homebrew 4.5.1 toolchain with 2.20.1 binutils (I think the toolchain does not matter). The same board configured with 'at91rm9200ek_ram_config' do work with an JTAG. The JTAG configuration is copied from u-boot (just to mention the SDRAM and clock initialisation is sane). regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [TEST] arm:board_init_f(): mirror BSS and check after each init_fnc()
Le 01/12/2010 13:35, Wolfgang Denk a écrit : Dear Albert ARIBAUD, In message4cf63345.9020...@free.fr you wrote: I can not recommend a proper place for all boards cause this parameter is highly is board specific. Understood -- each board maintainer must select an adapted location for the mirror. I'm not conviced that ech board maintainer should do that, and I somewhat doubt the approach taken. The main purpose of the patch (as I see it) is to find out which functions might be candidates to write to bss too early. There is not that much board specific code involved there. If we can generate a slist of functions that are called before relocation, we can use nm to check if these refernce any sumbols in bss. We could even generate black / white lists. Just to clarify: I see Andreas' proposal as a debug tool, notintended to ever be applied to a branch, but to be kept and applied to local developer repositories during debug. It seems you, Wolfgang, are considering this more like a tool that would end up in the u-boot source tree and be e.g. run systematically after a build, even if the builder had no intent of debugging. Am I right? If so, then yes, a tool that would analyze the ELF binary would be a good approach. Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] at91rm9200ek NOR booting is broken
thanks Andreas, Le 01/12/2010 13:37, Andreas Bießmann a écrit : Dear Albert Aribaud, as mentioned in another thread here is the description of broken at91rm9200ek NOR booting. I use the patchset posted in http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/89974 on top of v2010.12-rc2 tag. I configure the code for 'at91rm9200ek_config' and build that with a homebrew 4.5.1 toolchain with 2.20.1 binutils (I think the toolchain does not matter). The same board configured with 'at91rm9200ek_ram_config' do work with an JTAG. The JTAG configuration is copied from u-boot (just to mention the SDRAM and clock initialisation is sane). What is the exact symptom? does the board display anything on its console, or does it stay completely silent? regards Andreas Bießmann Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/8xxx: Fix _POST_WORD_ADDR on 85xx 86xx systems
We intended to use the PIC TFRR register however we where missing adding in the PIC register base offset from IMMR when we defined _POST_WORD_ADDR. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- include/post.h |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/include/post.h b/include/post.h index 957ce3b..519cef1 100644 --- a/include/post.h +++ b/include/post.h @@ -58,11 +58,13 @@ #elif defined (CONFIG_MPC85xx) #include asm/immap_85xx.h -#define _POST_WORD_ADDR(CONFIG_SYS_IMMR + offsetof(ccsr_pic_t, tfrr)) +#define _POST_WORD_ADDR(CONFIG_SYS_IMMR + CONFIG_SYS_MPC85xx_PIC_OFFSET + \ + offsetof(ccsr_pic_t, tfrr)) #elif defined (CONFIG_MPC86xx) #include asm/immap_86xx.h -#define _POST_WORD_ADDR(CONFIG_SYS_IMMR + offsetof(ccsr_pic_t, tfrr)) +#define _POST_WORD_ADDR(CONFIG_SYS_IMMR + CONFIG_SYS_MPC86xx_PIC_OFFSET + \ + offsetof(ccsr_pic_t, tfrr)) #elif defined (CONFIG_4xx) #define _POST_WORD_ADDR \ -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] hwconfig: Fix handling of env_hwconfig, board_hwconfig, and cpu_hwconfig
On Nov 30, 2010, at 6:09 PM, Timur Tabi wrote: On Tue, Nov 30, 2010 at 3:58 PM, Kumar Gala ga...@kernel.crashing.org wrote: The handling of env_hwconfig, board_hwconfig, and cpu_hwconfig got broken when we removed the boards defining dummy board_hwconfig cpu_hwconfig values. We fix this by handling the various strings in priority order. If hwconfig_parse returns NULL for a given string we check the next one in order (env_hwconfig, board_hwconfig, followed by cpu_hwconfig). Signed-off-by: Kumar Gala ga...@kernel.crashing.org I think the P1022DS is broken without this fix, but I can't get this patch to apply. Is there a pre-requisite patch that I'm missing? -- Timur Tabi Linux kernel developer at Freescale Try the latest HEAD of tree, Wolfgang pulled in the pre-req patch: http://patchwork.ozlabs.org/patch/73656/ - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] p1022ds: fix switching of DIU/LBC signals
On Nov 30, 2010, at 7:50 PM, Scott Wood wrote:
On Tue, 30 Nov 2010 18:36:25 -0600
Timur Tabi ti...@freescale.com wrote:
@@ -244,8 +266,15 @@ void flash_write64(u64 value, void *addr)
/* There is no __raw_writeq(), so do the write manually */
*(volatile u64 *)addr = value;
-if (sw)
+if (sw) {
+/*
+ * To ensure the post-write is completed to eLBC, software must
+ * perform a dummy read from one valid address from eLBC space
+ * before changing the eLBC_DIU from NOR mode to DIU mode.
+ */
+__raw_readb(addr);
set_mux_to_diu();
+}
Careful with the barriers.
You've got a raw readback, which means it's not going to wait for
completion with the twi/isync hack.
Ordinarily that would be OK, since you only need ordering between the
readb and the first access in set_mux_to_diu(). Unfortunately, that
first access is an 8-bit access, which for some strange reason does
sync differently than 16/32-bit accesses. The latter do sync+write,
but 8-bit does write+eieio. So there's no barrier between the read
and the write.
Any reason not to use in_8 here?
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] p1022ds: fix switching of DIU/LBC signals
/* There is no __raw_writeq(), so do the write manually */
*(volatile u64 *)addr = value;
-if (sw)
+if (sw) {
+/*
+ * To ensure the post-write is completed to eLBC, software must
+ * perform a dummy read from one valid address from eLBC space
+ * before changing the eLBC_DIU from NOR mode to DIU mode.
+ */
+__raw_readb(addr);
set_mux_to_diu();
+}
Careful with the barriers.
You've got a raw readback, which means it's not going to wait for
completion with the twi/isync hack.
Ordinarily that would be OK, since you only need ordering between the
readb and the first access in set_mux_to_diu(). Unfortunately, that
first access is an 8-bit access, which for some strange reason does
sync differently than 16/32-bit accesses. The latter do sync+write,
but 8-bit does write+eieio. So there's no barrier between the read
and the write.
Any reason not to use in_8 here?
Timur,
Any reason not to use in_be8?
The first version code is finished by me some months ago. at that time I used
the in_be8.
Thanks,
Dave
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2010.12-rc2 released
On Tue, Nov 30, 2010 at 3:54 PM, Wolfgang Denk w...@denx.de wrote: Dear Albert ARIBAUD, In message 4cf55ade.4010...@free.fr you wrote: I suppose we should be suspecting the timers? I think I recall hearing that the time code can mix poorly with relocation. There is no issue with relocation and timers per se, but with the use of BSS variables before relocation. Any code run in the course of executing board_init_f() and which accesses globals can cause problems. Correct. And I would also like to pont out that the problem existed before, it just was not as clearly visible. [...] Wolfgang you are correct in pointing that out; I agree that is an important distinction: the failure was not _caused_ by anything that Sekhar did in that patch. Thanks for the clarification, Albert. I guess that leaves a lot of territory open for possible culprits though. Sudhakar, this is not a problem that I am prepared to fix; I hope that as the da850evm maintainer you will be able to. On Wed, Dec 1, 2010 at 4:46 AM, Nori, Sekhar nsek...@ti.com wrote: Removing the added #define CONFIG_REVISION_TAG does not fix the freeze. Furthermore, reverting the patch on top of 2010.12-rc2 does not fix the freeze either. Finally to add to the (/my) confusion, Ah, that is a sure indication that the issue is elsewhere. Yes, absolutely. I'm sorry to make it sound like it was your change that caused the failure. In retrospect, the upside is that you have replied and also CC'd Sudhakar, so maybe he will come back and fix the problem. [...] I am not sure about that (haven't been following all the relocation related changes lately). Since it is booting for me, may be it is related to the build environment? I am using CodeSourcery 2009q1-203 for building the U-Boot. I am using the exact same toolchain, sadly. $arm-none-linux-gnueabi-gcc --version arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2009q1-203) 4.3.3 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I built from the v2010.12-rc2 tag (with zero changes to the config), git checkout v2010.12-rc2; make mrproper ;make da850evm_config; make -j9 all Then I flashed it to SPI using the mono-based sfh_OMAP-L138.exe provided by TI, booted and observed: OMAP-L138 initialization passed! Booting TI User Boot Loader UBL Version: 1.65 UBL Flashtype: SPI Starting SPI Memory Copy... Valid magicnum, 0x55424CBB, found at offset 0x0001. DONE Jumping to entry point at 0xC108. Nothing is printed after 'Jumping to entry point.' It looks like I have a different UBL than you, perhaps that is the culprit? Best Regards, Ben Gardiner --- Nanometrics Inc. http://www.nanometrics.ca ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] p1022ds: fix switching of DIU/LBC signals
On Dec 1, 2010, at 7:51 AM, Liu Dave-R63238 r63...@freescale.com wrote Timur, Any reason not to use in_be8? The first version code is finished by me some months ago. at that time I used the in_be8. What first version code? Did you implement this feature, too? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/7] [REPOST-1] gpio: Add Multi-Function-Pin configuration driver for Marvell SoCs
Hi Prafulla,
On Thu, Dec 2, 2010 at 12:01 AM, Prafulla Wadaskar prafu...@marvell.com wrote:
Most of the Marvell SoCs has Multi Function Pin (MFP) configuration registers
For ex. ARMADA100.
These registers are programmed to expose the specific functionality
associated with respective SoC Pins
This driver provides configuration APIs,
using them, configuration need to be done in board specific code
for ex- following code configures MFPs 107 and 108 for UART_TX/RX
functionality
int board_early_init_f(void)
{
u32 mfp_cfg[] = {
/* Console on UART1 */
MFP107_UART1_RXD,
MFP108_UART1_TXD,
MFP_EOC /*End of configureation*/
};
/* configure MFP's */
mfp_config(mfp_cfg);
return 0;
}
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
Please Ignore earlier patch, below bufix is added to this patch
Change log v3:
Fixed: Read-modify-Write a mfg register as per configuration
ANDed with MASK value before ORing for each configuration
REPOST-V1:
I am sorry for the repost-V1 :-(
MASK values changed to relevent (copy paste mistake)
Regards..
Prafulla . .
drivers/gpio/Makefile | 1 +
drivers/gpio/mfp.c | 110
+
include/mfp.h | 97 +++
3 files changed, 208 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/mfp.c
create mode 100644 include/mfp.h
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 398024c..f6903d5 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -27,6 +27,7 @@ LIB := $(obj)libgpio.o
COBJS-$(CONFIG_AT91_GPIO) += at91_gpio.o
COBJS-$(CONFIG_KIRKWOOD_GPIO) += kw_gpio.o
+COBJS-$(CONFIG_MFP) += mfp.o
COBJS-$(CONFIG_MXC_GPIO) += mxc_gpio.o
COBJS-$(CONFIG_PCA953X) += pca953x.o
COBJS-$(CONFIG_S5P) += s5p_gpio.o
diff --git a/drivers/gpio/mfp.c b/drivers/gpio/mfp.c
new file mode 100644
index 000..f26af97
--- /dev/null
+++ b/drivers/gpio/mfp.c
@@ -0,0 +1,110 @@
+/*
+ * (C) Copyright 2010
+ * Marvell Semiconductor www.marvell.com
+ * Written-by: Prafulla Wadaskar prafu...@marvell.com,
+ *
+ * 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
+ */
+
+#include common.h
+#include asm/io.h
+#include mfp.h
+#include asm/arch/mfp.h
+#ifdef CONFIG_ARMADA100
+#include asm/arch/armada100.h
+#define MFPR_BASE ARMD1_MFPR_BASE;
+#else
+#error Unsupported SoC...
+#endif
+
+/*
+ * mfp_config
+ *
+ * On most of Marvell SoCs (ex. ARMADA100) there is Multi-Funtion-Pin
+ * configuration registers to configure each GPIO/Function pin on the
+ * SoC.
+ *
+ * This function reads the array of values for
+ * MFPR_X registers and programms them into respective
+ * Multi-Function Pin registers.
+ * It supports - Alternate Function Selection programming.
+ *
+ * Whereas,
+ * The Configureation value is constructed using ARMD_MFP()
+ * array consists of 32bit values as-
+ * Bits 31-16 : Mfp instance number (i.e. MFPR no. to be programmed)
+ * Bits 15-13 : PULL_UP/PULL_DOWN selection
+ * Bits 11:10 : Pin Driver strength
+ * Bits 6-4 : Edge detection configuration
+ * Bits 2-0 : Alternate Function Selection
+ *
+ * For more details please refer respective Product Software Manual
+ */
+void mfp_config(u32 *mfp_cfgs)
+{
+ u32 *p_mfpr = NULL;
+ u32 val, cfg_val, mfpr_no;
+
+ do {
+ cfg_val = *mfp_cfgs++;
+ /* exit if End of configuration table detected */
+ if (cfg_val == MFP_EOC)
+ break;
+ /* abstract mfpr tobe programmed from configuration value */
+ mfpr_no = (cfg_val MFP_PINNO_MASK) 16;
+ BUG_ON(mfpr_no = MFP_PIN_MAX);
+
+ /* the offset address are divided in three regions and not
+ * consecutive, this corrects the same (Ref: Specs: A1.1) */
+ p_mfpr = (u32 *)MFPR_BASE;
+ if ( mfpr_no 37)
+ p_mfpr += (0x004c / 4) + mfpr_no;
+
Re: [U-Boot] [PATCH] p1022ds: fix switching of DIU/LBC signals
Timur, Any reason not to use in_be8? The first version code is finished by me some months ago. at that time I used the in_be8. What first version code? Did you implement this feature, too? http://git.ap.freescale.net/gitweb/?p=u-boot-p1022.git;a=commitdiff;h=45 ddca32e5f288e81a444cf781c1f1a64cb1bfba;hp=e002776d6cbd647e0f410706d9aa8f 3bb96e7f8a ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build failures with older toolchain
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Tuesday, November 30, 2010 7:56 PM To: u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Monday, November 29, 2010 8:38 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain [snip]...[snip] I am process of downloading the 2009q3 version from codesourcery Albert mentioned he is using it. Are you on the same version as well? No, I'm using ELDk 4.2 [sp] Okay, so I downloaded both 2009-q3 and 2010.09-50 versions of the Codesourcery Lite edition. There is no difference in the observations between 2009q3 and 2010q1. [snip]...[snip] There were some good patches posted recently esp the bss_debug tool and fix for ARM relocation from Andreas. Applied them in order to get more information. In addition, added print indicating the function being called in for (init_funcptr= ) loop within board_init_f(). Also added a print in the function omap3_evm_get_revision() just to see if it ever gets called in due to incorrect sequencing. I could confirm that functions in init_sequence[] are called and omap3_evm_get_revision() is not called in this sequence. When everything failed, I went back to the u-boot.lds and changed the way overlay is defined. ...AND PROBLEM SEEMS TO BE SOLVED! I can now compile u-boot with both 2009q1 and 2010q1 without any error. (yet to try with 2010.09) To verify, I wanted to do a before-and-after comparison but couldn't have done for the omap3_evm - used omap3_beagle instead. I haven't yet tried running the binary on the board; but here are top level observations: 1) .bss and .rel.dyn are starting at same address. 2) The size of .rodata has increased. (Why? not yet spent time on?) Sending the patch in next few mins: ~sanjeev (Comparison: before and after) 753c753 .rodata 0x80035578 0x9f38 --- .rodata 0x80035578 0x9f46 757c757 .rodata0x8003571c 0xbc arch/arm/lib/libarm.o --- === [contents deleted] === .u_boot_cmd 0x80041aac 0x658 --- .u_boot_cmd 0x80041abc 0x658 === [contents deleted] === 967,968c967,973 .rel.dyn0x80042104 0x5af0 0x80042104__rel_dyn_start = . --- .dynsym 0x80042114 0xa0 0x80042114__dynsym_start = . *(.dynsym) .dynsym0x80042114 0xa0 arch/arm/cpu/armv7/start.o .rel.dyn0x800421b4 0x5af0 0x800421b4__rel_dyn_start = . === [contents deleted] === 984,985c986,987 .bss0x800421040x31ba8 0x80042104__bss_start = . --- .bss0x800421b40x31bb4 load address 0x80047ca4 0x80073d68__bss_start = . === [contents deleted] === .dynbss 0x80073cac0x0 --- .dynbss 0x80073d680x0 load address 0x80079858 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build failures with older toolchain
Le 01/12/2010 15:56, Premi, Sanjeev a écrit : When everything failed, I went back to the u-boot.lds and changed the way overlay is defined. ...AND PROBLEM SEEMS TO BE SOLVED! This most probably means some of the code running before relocation uses BSS; see below. I can now compile u-boot with both 2009q1 and 2010q1 without any error. (yet to try with 2010.09) To verify, I wanted to do a before-and-after comparison but couldn't have done for the omap3_evm - used omap3_beagle instead. I haven't yet tried running the binary on the board; but here are top level observations: 1) .bss and .rel.dyn are starting at same address. This is normal and should not have any negative impact as long as code that runs before relocation does not access BSS -- and it should not, since BSS only exists after relocation. 2) The size of .rodata has increased. (Why? not yet spent time on?) Weird. Can you provide all necessary info for duplicating these two builds? Sending the patch in next few mins: If that's a patch to remove the overlay in the .lds, it's a Nak from me already. ~sanjeev Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] at91rm9200ek NOR booting is broken
Dear Albert ARIBAUD, Am 01.12.2010 13:49, schrieb Albert ARIBAUD: thanks Andreas, What is the exact symptom? does the board display anything on its console, or does it stay completely silent? I see the banner and 'DRAM: 32 MiB' on serial console. If I activate DEBUG in a/a/l/board.c I can see the debug messages up to 'relocation Offset is ...' regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
This patch fixes the linker problems noticed while
building the omap3_evm with Codesourcery toolchains
2009q1, 2009q3 and 2010q1.
The compilation was tested as success for both
omap3_evm and omap3_beagle with toolchain versions
2009q1 and 2010q1.
[1] http://marc.info/?l=u-bootm=129104332808386w=2
Signed-off-by: Sanjeev Premi pr...@ti.com
---
The patch touches all ARMv7 architectures, will need
to be reviewed thoroughly.
I am getting hang of relocation feature, but definitely
hands-on. Impact would have to be reviewd as well.
This is the reason for sending the patch early - before
i start testing on the evm.
arch/arm/cpu/armv7/u-boot.lds | 26 +++---
1 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/arch/arm/cpu/armv7/u-boot.lds b/arch/arm/cpu/armv7/u-boot.lds
index 5725c30..faf6ad8 100644
--- a/arch/arm/cpu/armv7/u-boot.lds
+++ b/arch/arm/cpu/armv7/u-boot.lds
@@ -55,22 +55,26 @@ SECTIONS
. = ALIGN(4);
- .rel.dyn : {
- __rel_dyn_start = .;
- *(.rel*)
- __rel_dyn_end = .;
- }
-
.dynsym : {
__dynsym_start = .;
*(.dynsym)
}
- .bss __rel_dyn_start (OVERLAY) : {
- __bss_start = .;
- *(.bss)
-. = ALIGN(4);
- _end = .;
+ OVERLAY : NOCROSSREFS
+ {
+ .rel.dyn {
+ __rel_dyn_start = .;
+ *(.rel*)
+ __rel_dyn_end = .;
+ }
+
+ .bss
+ {
+ __bss_start = .;
+ *(.bss)
+. = ALIGN(4);
+ _end = .;
+ }
}
/DISCARD/ : { *(.dynstr*) }
--
1.7.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build failures with older toolchain
-Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Wednesday, December 01, 2010 8:33 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de; Wolfgang Denk Subject: Re: [U-Boot] Build failures with older toolchain Le 01/12/2010 15:56, Premi, Sanjeev a écrit : When everything failed, I went back to the u-boot.lds and changed the way overlay is defined. ...AND PROBLEM SEEMS TO BE SOLVED! This most probably means some of the code running before relocation uses BSS; see below. I can now compile u-boot with both 2009q1 and 2010q1 without any error. (yet to try with 2010.09) To verify, I wanted to do a before-and-after comparison but couldn't have done for the omap3_evm - used omap3_beagle instead. I haven't yet tried running the binary on the board; but here are top level observations: 1) .bss and .rel.dyn are starting at same address. This is normal and should not have any negative impact as long as code that runs before relocation does not access BSS -- and it should not, since BSS only exists after relocation. [sp] Yes. This is what I wanted to confirm to ensure that relocation isn't breaking after the changes. In a way it was my testcase to see that I get similar map for omap3_beagle before and after making changes. 2) The size of .rodata has increased. (Why? not yet spent time on?) Weird. Can you provide all necessary info for duplicating these two builds? Sending the patch in next few mins: If that's a patch to remove the overlay in the .lds, it's a Nak from me already. [sp] No. I am not removing relocation. Do look at the patch. I just sent from my Linux box.. ~sanjeev Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] the mips cache code question ?
On Dec 1, 2010 12:26 AM, 奥刘 happyo...@gmail.com wrote: In the file .\cpu\mips\cache.s , i found some code confounded . line 152 to line 156 : cache_op Index_Store_Tag_I t0 PTR_ADDU t0, a2 bne t0, t1, 1b /* fill once, so data field parity is correct */ PTR_LI t0, INDEX_BASE the code 'PTR_LI t0, INDEX_BASE' is in the branch delay slot , so this instruction will be implement every branch cycle. Is it right ? Then the cache operation logic seems wrong . From a quick glance I think the code is OK. I would suggest disassembling the executable code to make sure of what the assembler did. The answer depends on what mode the assembler is in. For MIPS assembler there is a 'reorder mode' where the assembler will fill in the branch delay slot for you or place a nop if necessary, and the next instruction in the source is really the one after the delay slot, or there is noreorder mode where the next instruction after the branch is what is put in the delay slot. Normally the assembler runs in reorder mode, and you use a '.set reorder' and '.set noreorder' to switch between them. Noreorder mode is commonly used in code that requires precise control of where instructions get executed (cache tlb handling) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb_ether: register usb ethernet gadget at each eth init
Hi Vitaly, On Wed, Dec 1, 2010 at 12:41 AM, Vitaly Kuzmichev vkuzmic...@mvista.com wrote: Hi Lei, Lei Wen wrote: [...] For current ether.c state, there is no usb_gadget_unregister_driver in it. Even it has, we still need usb_gadget_register_driver call in each eth_init(). Yes, if we do 'unregister' we should do 'register' somewhere before. If we do 'register' we should do 'unregister' somewhere after. This is the symmetry such like in dynamic data allocation (like malloc/free), and we should comply it. The reason why there is no 'usb_gadget_unregister_driver' in the Ether driver yet is that there is no symmetrical function for 'usb_eth_initialize' because there is no way to remove a network device from the U-Boot environment. What we need to do is not trying to remove the network device, but to register another gadget when we want to switch from tftp to fastboot, and make UDC take a different protocol to communicate with host. I have not asked you to remove network device, I have talked about the reason for the following: For current ether.c state, there is no usb_gadget_unregister_driver in it. [...] Right, if at the same time certainly need to return error. So your code that expects successful register will make Ether gadget broken... Don't understand here, why the Ether gadget would be broken? Because UDC driver does not allow to register more than 1 gadget driver in the same time. It just returns EBUSY. Even if the first gadget driver is idle (when Ether gadget driver is registered but tftp command is not issued). This is done to protect against memory leaks. Just checkout cdc-at91 branch in u-boot-usb.git for example of UDC driver (drivers/usb/gadget/at91_udc.c). Or look at any UDC driver in linux kernel. I add unregister function in eth_halt, then the udc driver could do the proper memory free to prevent the memory leak. [...] This means that if you want 2 gadgets you need to register each one right before transferring data and unregister right after the data was transferred. By doing gadget unregister you will free allocated resources (such as USB endpoints and USB requests) in UDC and Ether drivers properly. Otherwise you will have memory leaks. Sure, so we comes into a conclusion that add register call in the eth_init and unregister call in eth_halt? In unregister call, the UDC driver should free the ep as you said. Yes, it will free by 'eth_unbind' called from 'usb_gadget_unregister_driver'. Note that 'usb_gadget_register_driver' should be removed from 'usb_eth_initialize' and dev-gadget checking should be added in eth_halt. Ack this idea. Apply to the next patch. Best regards, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] usb_ether: register usb ethernet gadget at each eth init
Since the ether may not be the only one usb gadget would be used
in the uboot, it is neccessary to do the register each time the
eth begin to work to make usb gadget driver less confussed when
we want to use two different usb gadget at the same time.
Usb gadget driver could simple ignore the register operation, if
it find the driver has been registered already.
Signed-off-by: Lei Wen lei...@marvell.com
---
V1: delete the usb_gadget_register_driver in usb_eth_initialize,
and judge whether gadget is registered at eth_halt.
drivers/usb/gadget/ether.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 5a18e03..261cf7e 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -1456,6 +1456,7 @@ static void eth_unbind(struct usb_gadget *gadget)
/* unregister_netdev (dev-net);*/
/* free_netdev(dev-net);*/
+ dev-gadget = NULL;
set_gadget_data(gadget, NULL);
}
@@ -1788,6 +1789,8 @@ static int usb_eth_init(struct eth_device *netdev, bd_t
*bd)
error(received NULL ptr);
goto fail;
}
+ if (usb_gadget_register_driver(eth_driver) 0)
+ goto fail;
dev-network_started = 0;
@@ -1895,7 +1898,12 @@ void usb_eth_halt(struct eth_device *netdev)
return;
}
+ /* If the gadget not registered, simple return */
+ if (!dev-gadget)
+ return;
+
usb_gadget_disconnect(dev-gadget);
+ usb_gadget_unregister_driver(eth_driver);
}
static struct usb_gadget_driver eth_driver = {
@@ -1957,10 +1965,6 @@ int usb_eth_initialize(bd_t *bi)
if (status)
goto fail;
- status = usb_gadget_register_driver(eth_driver);
- if (status 0)
- goto fail;
-
eth_register(netdev);
return 0;
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/8] powerpc/85xx: do not reloc l2srbar if CONFIG_FLASH_BASE is not defined
From: Haiying Wang haiying.w...@freescale.com
This fixes the compiling error for the board which doesn't have NOR flash
(so CONFIG_FLASH_BASE is not defined)
Signed-off-by: Haiying Wang haiying.w...@freescale.com
---
arch/powerpc/cpu/mpc85xx/cpu_init.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 27236a0..4b8faa5 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -327,7 +327,7 @@ int cpu_init_r(void)
if (l2cache-l2ctl MPC85xx_L2CTL_L2E) {
puts(already enabled);
l2srbar = l2cache-l2srbar0;
-#ifdef CONFIG_SYS_INIT_L2_ADDR
+#if defined(CONFIG_SYS_INIT_L2_ADDR) defined(CONFIG_SYS_FLASH_BASE)
if (l2cache-l2ctl MPC85xx_L2CTL_L2SRAM_ENTIRE
l2srbar = CONFIG_SYS_FLASH_BASE) {
l2srbar = CONFIG_SYS_INIT_L2_ADDR;
--
1.7.3.1.50.g1e633
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/8 v2] Add support to tpl boot and p1021mds board
This is the second version of patchset to add support of TPL(Tertiary Program Loader) and P1021MDS board. Compared with the previous version, patch #3 is splitted into two patches and incorporates the comments from Wolfgang and Mike. Patch#4 has changes based on 2010.12-rc2 release. The other patches remain unchanged. [PATCH 1/8] powerpc/85xx: do not reloc l2srbar if CONFIG_FLASH_BASE is not defined [PATCH 2/8] 8xxx/ddr: add support to only compute the ddr sdram size [PATCH 3/8 v2] Introduce the Tertiary Program loader [PATCH 4/8 v2] powerpc/85xx: add TPL_BOOT support [PATCH 5/8 v2] P1021MDS: add P1021MDS board support [PATCH 6/8] powerpc/p1021: add more P1021 defines. [PATCH 7/8] powerpc/85xx: do not initialize QE if QE's firmware is in nand flash [PATCH 8/8] p1021mds: add QE and UEC support ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/8] 8xxx/ddr: add support to only compute the ddr sdram size
From: Haiying Wang haiying.w...@freescale.com
This patch adds fsl_ddr_sdram_size to only calculate the ddr sdram size, in
case that the DDR SDRAM is initialized in the 2nd stage uboot and should not
be intialized again in the final stage uboot.
Signed-off-by: Haiying Wang haiying.w...@freescale.com
---
arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c | 10 -
arch/powerpc/cpu/mpc8xxx/ddr/ddr.h |8 --
arch/powerpc/cpu/mpc8xxx/ddr/main.c | 31 +
3 files changed, 40 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c
b/arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c
index 3fec100..8fdafdb 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c
@@ -1176,7 +1176,8 @@ compute_fsl_memctl_config_regs(const memctl_options_t
*popts,
fsl_ddr_cfg_regs_t *ddr,
const common_timing_params_t *common_dimm,
const dimm_params_t *dimm_params,
- unsigned int dbw_cap_adj)
+ unsigned int dbw_cap_adj,
+ unsigned int size_only)
{
unsigned int i;
unsigned int cas_latency;
@@ -1394,6 +1395,13 @@ compute_fsl_memctl_config_regs(const memctl_options_t
*popts,
printf(CS%d is disabled.\n, i);
}
+ /*
+* In the case we only need to compute the ddr sdram size, we only need
+* to set csn registers, so return from here.
+*/
+ if (size_only)
+ return 0;
+
set_ddr_eor(ddr, popts);
#if !defined(CONFIG_FSL_DDR1)
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/ddr.h
b/arch/powerpc/cpu/mpc8xxx/ddr/ddr.h
index 98acb8d..8c24131 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/ddr.h
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/ddr.h
@@ -1,5 +1,5 @@
/*
- * Copyright 2008 Freescale Semiconductor, Inc.
+ * Copyright 2008-2010 Freescale Semiconductor, Inc.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -55,7 +55,8 @@ typedef struct {
#define STEP_ALL 0xFFF
extern unsigned long long
-fsl_ddr_compute(fsl_ddr_info_t *pinfo, unsigned int start_step);
+fsl_ddr_compute(fsl_ddr_info_t *pinfo, unsigned int start_step,
+ unsigned int size_only);
extern const char * step_to_string(unsigned int step);
@@ -64,7 +65,8 @@ compute_fsl_memctl_config_regs(const memctl_options_t *popts,
fsl_ddr_cfg_regs_t *ddr,
const common_timing_params_t *common_dimm,
const dimm_params_t *dimm_parameters,
- unsigned int dbw_capacity_adjust);
+ unsigned int dbw_capacity_adjust,
+ unsigned int size_only);
extern unsigned int
compute_lowest_common_dimm_parameters(const dimm_params_t *dimm_params,
common_timing_params_t *outpdimm,
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/main.c
b/arch/powerpc/cpu/mpc8xxx/ddr/main.c
index 6d582e9..b89b471 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/main.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/main.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2008 Freescale Semiconductor, Inc.
+ * Copyright 2008-2010 Freescale Semiconductor, Inc.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -233,7 +233,8 @@ int step_assign_addresses(fsl_ddr_info_t *pinfo,
}
unsigned long long
-fsl_ddr_compute(fsl_ddr_info_t *pinfo, unsigned int start_step)
+fsl_ddr_compute(fsl_ddr_info_t *pinfo, unsigned int start_step,
+ unsigned int size_only)
{
unsigned int i, j;
unsigned int all_controllers_memctl_interleaving = 0;
@@ -338,7 +339,8 @@ fsl_ddr_compute(fsl_ddr_info_t *pinfo, unsigned int
start_step)
pinfo-memctl_opts[i],
ddr_reg[i], timing_params[i],
pinfo-dimm_params[i],
- dbw_capacity_adjust[i]);
+ dbw_capacity_adjust[i],
+ size_only);
}
default:
@@ -405,7 +407,7 @@ phys_size_t fsl_ddr_sdram(void)
memset(info, 0, sizeof(fsl_ddr_info_t));
/* Compute it once normally. */
- total_memory = fsl_ddr_compute(info, STEP_GET_SPD);
+ total_memory = fsl_ddr_compute(info, STEP_GET_SPD, 0);
/* Check for memory controller interleaving. */
memctl_interleaved = 0;
@@ -430,7 +432,8 @@ phys_size_t fsl_ddr_sdram(void)
info.memctl_opts[i].memctl_interleaving = 0;
[U-Boot] [PATCH 3/8 v2] Introduce the Tertiary Program loader
From: Haiying Wang haiying.w...@freescale.com
TPL is introduced to enable a loader stub that boots out of some type of RAM,
after being loaded by an SPL or similar platform-specific mechanism.
One example of using this tpl loader is to initialize the ddr through spd code
in case the L2 SRAM size is not big enough to hold the final uboot image and
the nand spl code needs to be limitated to 4K byte, then tpl code will load the
final uboot image after ddr is initialized.
Signed-off-by: Haiying Wang haiying.w...@freescale.com
---
Incorporate Mike's comment to use new variable NAND_SPL_OBJS-y
Makefile | 17 +++--
README | 27 +++
2 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 87a383d..94af465 100644
--- a/Makefile
+++ b/Makefile
@@ -290,6 +290,10 @@ LDPPFLAGS += \
$(shell $(LD) --version | \
sed -ne 's/GNU ld version
\([0-9][0-9]*\)\.\([0-9][0-9]*\).*/-DLD_MAJOR=\1 -DLD_MINOR=\2/p')
+ifeq ($(CONFIG_TPL_U_BOOT),y)
+TPL_BOOT = tpl
+endif
+
ifeq ($(CONFIG_NAND_U_BOOT),y)
NAND_SPL = nand_spl
U_BOOT_NAND = $(obj)u-boot-nand.bin
@@ -407,8 +411,15 @@ $(obj)u-boot.lds: $(LDSCRIPT)
$(NAND_SPL): $(TIMESTAMP_FILE) $(VERSION_FILE) depend
$(MAKE) -C nand_spl/board/$(BOARDDIR) all
-$(U_BOOT_NAND):$(NAND_SPL) $(obj)u-boot.bin
- cat $(obj)nand_spl/u-boot-spl-16k.bin $(obj)u-boot.bin
$(obj)u-boot-nand.bin
+$(TPL_BOOT): $(TIMESTAMP_FILE) $(VERSION_FILE) depend
+ $(MAKE) -C tpl/board/$(BOARDDIR) all
+
+NAND_SPL_OBJS-y += $(obj)nand_spl/u-boot-spl-16k.bin
+NAND_SPL_OBJS-$(CONFIG_TPL_U_BOOT) += $(obj)tpl/u-boot-tpl.bin
+NAND_SPL_OBJS-y += $(obj)u-boot.bin
+
+$(U_BOOT_NAND): $(NAND_SPL) $(TPL_BOOT) $(obj)u-boot.bin
+ cat $(NAND_SPL_OBJS-y) u-boot-nand.bin
$(ONENAND_IPL):$(TIMESTAMP_FILE) $(VERSION_FILE)
$(obj)include/autoconf.mk
$(MAKE) -C onenand_ipl/board/$(BOARDDIR) all
@@ -1226,6 +1237,7 @@ clean:
@rm -f $(obj)lib/asm-offsets.s
@rm -f $(obj)nand_spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,System.map}
@rm -f $(obj)onenand_ipl/onenand-{ipl,ipl.bin,ipl.map}
+ @rm -f $(obj)tpl/{u-boot-tpl,u-boot-tpl.map}
@rm -f $(ONENAND_BIN)
@rm -f $(obj)onenand_ipl/u-boot.lds
@rm -f $(TIMESTAMP_FILE) $(VERSION_FILE)
@@ -1250,6 +1262,7 @@ clobber: clean
@rm -fr $(obj)include/generated
@[ ! -d $(obj)nand_spl ] || find $(obj)nand_spl -name * -type l
-print | xargs rm -f
@[ ! -d $(obj)onenand_ipl ] || find $(obj)onenand_ipl -name * -type l
-print | xargs rm -f
+ @[ ! -d $(obj)tpl ] || find $(obj)tpl -name * -type l -print | xargs
rm -f
ifeq ($(OBJTREE),$(SRCTREE))
mrproper \
diff --git a/README b/README
index 68f5fb0..9c7d40d 100644
--- a/README
+++ b/README
@@ -2108,6 +2108,33 @@ FIT uImage format:
Adds the MTD partitioning infrastructure from the Linux
kernel. Needed for UBI support.
+- NAND Boot Support
+ CONFIG_NAND_U_BOOT
+
+ Builds a U-Boot image that boots from NAND, prefixed by a small
+ loader stub (secondary program loader -- SPL) that loads the
+ rest of U-Boot into RAM. This symbol will be set in all build
+ phases.
+
+ CONFIG_NAND_SPL
+
+ This is set by the build system when compiling code to go into
+ the SPL. It is not set when building the code that the SPL
+ loads.
+
+- TPL Boot Support
+ CONFIG_TPL_U_BOOT
+
+ Builds a U-Boot image that contains a loader stub (tertiary
+ program loader -- TPL) that boots out of some type of RAM,
+ after being loaded by an SPL or similar platform-specific
+ mechanism. This symbol will be set in all build phases.
+
+ CONFIG_TPL_BOOT
+
+ This is set by the build system when compiling code to go into
+ the TPL. It is not set when building the code that the TPL
+ loads, or when building the SPL.
Modem Support:
--
--
1.7.3.1.50.g1e633
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TR: u-boot SquashFS
Hi Gaëtan, I am looking for a u-boot that handles SquashFS filesystem ? Did it exist ? if not can I have some indication or recommendation Because I want to try to upgrade u-boot such that it handles SquashFS Tuxbox has such an u-boot version, see: http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/boot/ However, IIRC the patches are against an acient version of u-boot and only cover squashfs v3. Thanks, Jochen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/8 v2] powerpc/85xx: add TPL_BOOT support
From: Haiying Wang haiying.w...@freescale.com
Signed-off-by: Haiying Wang haiying.w...@freescale.com
---
Splitted from TPL patch to only address 85xx changes
arch/powerpc/cpu/mpc85xx/cpu_init_nand.c | 34 ++-
arch/powerpc/cpu/mpc85xx/start.S | 12 ++--
arch/powerpc/cpu/mpc85xx/u-boot-tpl.lds | 99 ++
3 files changed, 137 insertions(+), 8 deletions(-)
create mode 100644 arch/powerpc/cpu/mpc85xx/u-boot-tpl.lds
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init_nand.c
b/arch/powerpc/cpu/mpc85xx/cpu_init_nand.c
index 8fb27ab..decedca 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init_nand.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init_nand.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2009 Freescale Semiconductor, Inc.
+ * Copyright 2010 Freescale Semiconductor, Inc.
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -40,7 +40,8 @@ void cpu_init_f(void)
#error CONFIG_NAND_BR_PRELIM, CONFIG_NAND_OR_PRELIM must be defined
#endif
-#if defined(CONFIG_SYS_RAMBOOT) defined(CONFIG_SYS_INIT_L2_ADDR)
+#if defined(CONFIG_SYS_RAMBOOT) defined(CONFIG_SYS_INIT_L2_ADDR) \
+!defined(CONFIG_TPL_BOOT)
ccsr_l2cache_t *l2cache = (void *)CONFIG_SYS_MPC85xx_L2_ADDR;
char *l2srbar;
int i;
@@ -60,4 +61,33 @@ void cpu_init_f(void)
for (i = 0; i CONFIG_SYS_L2_SIZE; i++)
l2srbar[i] = 0;
#endif
+#ifdef CONFIG_TPL_BOOT
+ init_used_tlb_cams();
+#endif
+}
+
+#ifdef CONFIG_TPL_BOOT
+/*
+ * Because the primary cpu's info is enough for the 2nd stage, we define the
+ * cpu number to 1 so as to keep code size for 2nd stage binary as small as
+ * possible.
+ */
+int cpu_numcores()
+{
+ return 1;
+}
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/*
+ * Get timebase clock frequency
+ */
+unsigned long get_tbclk(void)
+{
+#ifdef CONFIG_FSL_CORENET
+ return (gd-bus_clk + 8) / 16;
+#else
+ return (gd-bus_clk + 4UL)/8UL;
+#endif
}
+#endif /* CONFIG_TPL_BOOT */
diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
index 945c1b8..12b0ebb 100644
--- a/arch/powerpc/cpu/mpc85xx/start.S
+++ b/arch/powerpc/cpu/mpc85xx/start.S
@@ -58,12 +58,12 @@
GOT_ENTRY(_GOT2_TABLE_)
GOT_ENTRY(_FIXUP_TABLE_)
-#ifndef CONFIG_NAND_SPL
+#if !defined(CONFIG_NAND_SPL) !defined(CONFIG_TPL_BOOT)
GOT_ENTRY(_start)
GOT_ENTRY(_start_of_vectors)
GOT_ENTRY(_end_of_vectors)
GOT_ENTRY(transfer_to_handler)
-#endif
+#endif /* !CONFIG_TPL_BOOT || !CONFIG_NAND_SPL*/
GOT_ENTRY(__init_end)
GOT_ENTRY(_end)
@@ -435,7 +435,7 @@ _start_cont:
/* NOTREACHED - board_init_f() does not return */
-#ifndef CONFIG_NAND_SPL
+#if !defined(CONFIG_NAND_SPL) !defined(CONFIG_TPL_BOOT)
. = EXC_OFF_SYS_RESET
.globl _start_of_vectors
_start_of_vectors:
@@ -877,7 +877,7 @@ in32:
in32r:
lwbrx r3,r0,r3
blr
-#endif /* !CONFIG_NAND_SPL */
+#endif /* !CONFIG_NAND_SPL !CONFIG_TPL_BOOT */
/*--*/
@@ -1067,7 +1067,7 @@ clear_bss:
mr r4,r10 /* Destination Address */
bl board_init_r
-#ifndef CONFIG_NAND_SPL
+#if !defined(CONFIG_NAND_SPL) !defined(CONFIG_TPL_BOOT)
/*
* Copy exception vector code to low memory
*
@@ -1207,4 +1207,4 @@ setup_ivors:
#include fixed_ivor.S
blr
-#endif /* !CONFIG_NAND_SPL */
+#endif /* !CONFIG_NAND_SPL !CONFIG_TPL_BOOT */
diff --git a/arch/powerpc/cpu/mpc85xx/u-boot-tpl.lds
b/arch/powerpc/cpu/mpc85xx/u-boot-tpl.lds
new file mode 100644
index 000..1c17acf
--- /dev/null
+++ b/arch/powerpc/cpu/mpc85xx/u-boot-tpl.lds
@@ -0,0 +1,99 @@
+/*
+ * Copyright 2010 Freescale Semiconductor, Inc.
+ *
+ * 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
+ */
+
+OUTPUT_ARCH(powerpc)
+PHDRS
+{
+ text PT_LOAD;
+ bss PT_LOAD;
+}
+
+SECTIONS
+{
+ /* Read-only sections, merged into text segment: */
+ . = + SIZEOF_HEADERS;
+ .interp : { *(.interp) }
+ .text :
+ {
+*(.text*)
+ } :text
+_etext = .;
+PROVIDE (etext = .);
+.rodata:
+ {
+*(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*)))
+ } :text
[U-Boot] [PATCH 6/8] powerpc/p1021: add more P1021 defines.
From: Haiying Wang haiying.w...@freescale.com
Signed-off-by: Haiying Wang haiying.w...@freescale.com
---
arch/powerpc/include/asm/immap_85xx.h |6 ++
arch/powerpc/include/asm/immap_qe.h |9 +++--
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/immap_85xx.h
b/arch/powerpc/include/asm/immap_85xx.h
index 30c64eb..9eb106c 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -1963,6 +1963,12 @@ typedef struct ccsr_gur {
u8 res10b[76];
par_io_t qe_par_io[7];
u8 res10c[1600];
+#elif defined(CONFIG_P1021)
+ u8 res10b1[12];
+ u32 iovselsr;
+ u8 res10b2[60];
+ par_io_t qe_par_io[3];
+ u8 res10c[1496];
#else
u8 res10b[1868];
#endif
diff --git a/arch/powerpc/include/asm/immap_qe.h
b/arch/powerpc/include/asm/immap_qe.h
index 531cfc8..74c9013 100644
--- a/arch/powerpc/include/asm/immap_qe.h
+++ b/arch/powerpc/include/asm/immap_qe.h
@@ -3,7 +3,7 @@
* The Internal Memory Map for devices with QE on them. This
* is the superset of all QE devices (8360, etc.).
*
- * Copyright (c) 2006-2009 Freescale Semiconductor, Inc.
+ * Copyright (c) 2006-2010 Freescale Semiconductor, Inc.
* Author: Shlomi Gridih grid...@freescale.com
*
* This program is free software; you can redistribute it and/or modify it
@@ -588,6 +588,9 @@ typedef struct qe_immap {
#elif defined(CONFIG_MPC8569)
u8 muram[0x2]; /* 0x1_ - 0x3_ Multi-user RAM */
u8 res17[0x1]; /* 0x3_ - 0x4_ */
+#elif defined(CONFIG_P1021)
+ u8 muram[0x06000]; /* 0x1_ - 0x1_6000 Multi-user RAM */
+ u8 res17[0x1a000]; /* 0x1_6000 - 0x3_ */
#else
u8 muram[0xC000]; /* 0x11 - 0x11C000 Multi-user RAM */
u8 res17[0x24000]; /* 0x11C000 - 0x14 */
@@ -601,13 +604,15 @@ extern qe_map_t *qe_immr;
#define QE_MURAM_SIZE 0x1UL
#elif defined(CONFIG_MPC8569)
#define QE_MURAM_SIZE 0x2UL
+#elif defined(CONFIG_P1021)
+#define QE_MURAM_SIZE 0x6000UL
#elif defined(CONFIG_MPC8360)
#define QE_MURAM_SIZE 0xc000UL
#elif defined(CONFIG_MPC832x)
#define QE_MURAM_SIZE 0x4000UL
#endif
-#if defined(CONFIG_MPC8323)
+#if defined(CONFIG_MPC8323) || defined(CONFIG_P1021)
#define MAX_QE_RISC 1
#define QE_NUM_OF_SNUM 28
#elif defined(CONFIG_MPC8569)
--
1.7.3.1.50.g1e633
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/8] powerpc/85xx: do not initialize QE if QE's firmware is in nand flash
From: Haiying Wang haiying.w...@freescale.com For some board which doesn't have NOR flash and the QE's firmware(ucode) is saved in its NAND flash, we don't want call qe_init in cpu_init_r, but will call it later after nand is initialized. Signed-off-by: Haiying Wang haiying.w...@freescale.com --- arch/powerpc/cpu/mpc85xx/cpu_init.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c b/arch/powerpc/cpu/mpc85xx/cpu_init.c index 4b8faa5..eb34378 100644 --- a/arch/powerpc/cpu/mpc85xx/cpu_init.c +++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c @@ -369,7 +369,7 @@ int cpu_init_r(void) enable_cpc(); -#ifdef CONFIG_QE +#if defined(CONFIG_QE) !defined(CONFIG_SYS_QE_FW_IN_NAND) uint qe_base = CONFIG_SYS_IMMR + 0x0008; /* QE immr base */ qe_init(qe_base); qe_reset(); -- 1.7.3.1.50.g1e633 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8] powerpc/85xx: do not initialize QE if QE's firmware is in nand flash
On Dec 1, 2010, at 9:50 AM, haiying.w...@freescale.com haiying.w...@freescale.com wrote: From: Haiying Wang haiying.w...@freescale.com For some board which doesn't have NOR flash and the QE's firmware(ucode) is saved in its NAND flash, we don't want call qe_init in cpu_init_r, but will call it later after nand is initialized. Signed-off-by: Haiying Wang haiying.w...@freescale.com --- arch/powerpc/cpu/mpc85xx/cpu_init.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c b/arch/powerpc/cpu/mpc85xx/cpu_init.c index 4b8faa5..eb34378 100644 --- a/arch/powerpc/cpu/mpc85xx/cpu_init.c +++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c @@ -369,7 +369,7 @@ int cpu_init_r(void) enable_cpc(); -#ifdef CONFIG_QE +#if defined(CONFIG_QE) !defined(CONFIG_SYS_QE_FW_IN_NAND) uint qe_base = CONFIG_SYS_IMMR + 0x0008; /* QE immr base */ qe_init(qe_base); qe_reset(); -- 1.7.3.1.50.g1e633 Any reason to just not move QE init for everyone? - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
-Original Message-
From: Premi, Sanjeev
Sent: Wednesday, December 01, 2010 8:47 PM
To: u-boot@lists.denx.de
Cc: Premi, Sanjeev
Subject: [PATCH] ARMv7: Fix linker errors across toolchain versions
This patch fixes the linker problems noticed while
building the omap3_evm with Codesourcery toolchains
2009q1, 2009q3 and 2010q1.
The compilation was tested as success for both
omap3_evm and omap3_beagle with toolchain versions
2009q1 and 2010q1.
[1] http://marc.info/?l=u-bootm=129104332808386w=2
Signed-off-by: Sanjeev Premi pr...@ti.com
---
The patch touches all ARMv7 architectures, will need
to be reviewed thoroughly.
I am getting hang of relocation feature, but definitely
hands-on. Impact would have to be reviewd as well.
This is the reason for sending the patch early - before
i start testing on the evm.
arch/arm/cpu/armv7/u-boot.lds | 26 +++---
1 files changed, 15 insertions(+), 11 deletions(-)
[snip]...[snip]
The u-boot built after this change alone gets stuck somewhere after
dram_init(). However, removing the sort from LIBS (as suggested
by Wolfgang), the u-boot comes up fine on the omap3_evm.
[patch]
diff --git a/Makefile b/Makefile
index 87a383d..a530261 100644
--- a/Makefile
+++ b/Makefile
@@ -263,7 +263,7 @@ ifeq ($(SOC),s5pc2xx)
LIBS += $(CPUDIR)/s5p-common/libs5p-common.o
endif
-LIBS := $(addprefix $(obj),$(sort $(LIBS)))
+LIBS := $(addprefix $(obj),$(LIBS))
.PHONY : $(LIBS) $(TIMESTAMP_FILE) $(VERSION_FILE)
LIBBOARD = board/$(BOARDDIR)/lib$(BOARD).o
[/patch]
U-Boot 2010.12-rc2-00030-g4998cdc-dirty (Dec 01 2010 - 21:09:59)
OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 mHz
OMAP3 EVM board + LPDDR/NAND
I2C: ready
DRAM: 256 MiB
NAND: 256 MiB
In:serial
Out: serial
Err: serial
Read back SMSC id 0x9220
Die ID #6092000404032d460c01201a
Net: smc911x-0
Hit any key to stop autoboot: 0
OMAP3_EVM #
OMAP3_EVM #
Here is my git-log (including the patch above):
premi # g-log-10
4998cdc : ARMv7: Fix linker errors across toolchain versions
49733aa : Merge branch 'master' of /home/wd/git/u-boot/custodians
f8264e0 : Merge branch 'master' of git://git.denx.de/u-boot-arm
b194577 : hwconfig: Fix dummy initialization of {board, cpu}_hwconfig
a55bb83 : powerpc/85xx: Introduce CONFIG_SYS_EXTRA_ENV_RELOC
52eb2c7 : Merge branch 'master' of git://git.denx.de/u-boot-samsung
83b622a : Merge branch 'master' of /home/wd/git/u-boot/custodians
3410a99 : Merge branch 'master' of git://git.denx.de/u-boot-sh
a7bf3ec : Merge branch 'master' of /home/wd/git/u-boot/custodians
e45c98a : mpc83xx: Make it boot again
premi #
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] powerpc/85xx: do not reloc l2srbar if CONFIG_FLASH_BASE is not defined
On Dec 1, 2010, at 9:35 AM, haiying.w...@freescale.com haiying.w...@freescale.com wrote: From: Haiying Wang haiying.w...@freescale.com This fixes the compiling error for the board which doesn't have NOR flash (so CONFIG_FLASH_BASE is not defined) Signed-off-by: Haiying Wang haiying.w...@freescale.com --- arch/powerpc/cpu/mpc85xx/cpu_init.c |2 +- 1 files changed, 1 insertions(+), 1 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] powerpc/85xx: Enable HWCONFIG on MPC8572DS
On Nov 19, 2010, at 8:55 AM, Kumar Gala wrote: We need HWCONFIG to allow configuration of DDR params Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- include/configs/MPC8572DS.h |1 + 1 files changed, 1 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] TR: u-boot SquashFS
Thanks a lot -Message d'origine- De : Jochen Friedrich [mailto:joc...@scram.de] Envoyé : mercredi 1 décembre 2010 16:30 À : PHINEO - ABESSOLO, Gaetan Cc : u-boot@lists.denx.de Objet : Re: [U-Boot] TR: u-boot SquashFS Hi Gaëtan, I am looking for a u-boot that handles SquashFS filesystem ? Did it exist ? if not can I have some indication or recommendation Because I want to try to upgrade u-boot such that it handles SquashFS Tuxbox has such an u-boot version, see: http://cvs.tuxbox.org/cgi-bin/viewcvs.cgi/tuxbox/boot/ However, IIRC the patches are against an acient version of u-boot and only cover squashfs v3. Thanks, Jochen L'intégrité de ce message n'étant pas assurée sur internet, la société expéditrice ne peut être tenue responsable de son contenu ni de ses pièces jointes. Toute utilisation ou diffusion non autorisée est interdite. Si vous n'êtes pas destinataire de ce message, merci de le détruire et d'avertir l'expéditeur. The integrity of this message cannot be guaranteed on the Internet. The company that sent this message cannot therefore be held liable for its content nor attachments. Any unauthorized use or dissemination is prohibited. If you are not the intended recipient of this message, then please delete it and notify the sender. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8] powerpc/85xx: do not initialize QE if QE's firmware is in nand flash
On Wed, 2010-12-01 at 08:56 -0700, Kumar Gala wrote: diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c b/arch/powerpc/cpu/mpc85xx/cpu_init.c index 4b8faa5..eb34378 100644 --- a/arch/powerpc/cpu/mpc85xx/cpu_init.c +++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c @@ -369,7 +369,7 @@ int cpu_init_r(void) enable_cpc(); -#ifdef CONFIG_QE +#if defined(CONFIG_QE) !defined(CONFIG_SYS_QE_FW_IN_NAND) uint qe_base = CONFIG_SYS_IMMR + 0x0008; /* QE immr base */ qe_init(qe_base); qe_reset(); -- 1.7.3.1.50.g1e633 Any reason to just not move QE init for everyone? That was based on Wolfgang's comment: http://lists.denx.de/pipermail/u-boot/2010-August/075657.html Haiying ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 8/8] p1021mds: add QE and UEC support
From: Haiying Wang haiying.w...@freescale.com
P1021 has some QE pins which need to be set in pmuxcr register before using QE
functions. In this patch, pin QE0 and QE3 are set for UCC1 and UCC5 in Eth mode.
QE9 and QE12 are set for MII management. QE12 needs to be released after MII
access because QE12 pin is muxed with LBCTL signal.
P1021MDS has to load the microcode from NAND flash, this patch defines
misc_init_r() for loading ucode and initializing qe.
Signed-off-by: Haiying Wang haiying.w...@freescale.com
---
arch/powerpc/cpu/mpc85xx/speed.c |4 ++
arch/powerpc/include/asm/immap_85xx.h | 13 +
board/freescale/p1021mds/p1021mds.c | 82 +
drivers/qe/uec.c | 38 +++
include/configs/P1021MDS.h| 47 +++
5 files changed, 184 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/speed.c b/arch/powerpc/cpu/mpc85xx/speed.c
index dd4c6b3..6f1aa7b 100644
--- a/arch/powerpc/cpu/mpc85xx/speed.c
+++ b/arch/powerpc/cpu/mpc85xx/speed.c
@@ -163,10 +163,14 @@ void get_sys_info (sys_info_t * sysInfo)
#endif
#ifdef CONFIG_QE
+#ifdef CONFIG_P1021
+ sysInfo-freqQE = sysInfo-freqSystemBus;
+#else
qe_ratio = ((gur-porpllsr) MPC85xx_PORPLLSR_QE_RATIO)
MPC85xx_PORPLLSR_QE_RATIO_SHIFT;
sysInfo-freqQE = qe_ratio * CONFIG_SYS_CLK_FREQ;
#endif
+#endif
#if defined(CONFIG_SYS_LBC_LCRR)
/* We will program LCRR to this value later */
diff --git a/arch/powerpc/include/asm/immap_85xx.h
b/arch/powerpc/include/asm/immap_85xx.h
index 9eb106c..1e4dae9 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -1924,6 +1924,19 @@ typedef struct ccsr_gur {
#define MPC85xx_PMUXCR_SD_DATA 0x8000
#define MPC85xx_PMUXCR_SDHC_CD 0x4000
#define MPC85xx_PMUXCR_SDHC_WP 0x2000
+#define MPC85xx_PMUXCR_QE0 0x8000
+#define MPC85xx_PMUXCR_QE1 0x4000
+#define MPC85xx_PMUXCR_QE2 0x2000
+#define MPC85xx_PMUXCR_QE3 0x1000
+#define MPC85xx_PMUXCR_QE4 0x0800
+#define MPC85xx_PMUXCR_QE5 0x0400
+#define MPC85xx_PMUXCR_QE6 0x0200
+#define MPC85xx_PMUXCR_QE7 0x0100
+#define MPC85xx_PMUXCR_QE8 0x0080
+#define MPC85xx_PMUXCR_QE9 0x0040
+#define MPC85xx_PMUXCR_QE100x0020
+#define MPC85xx_PMUXCR_QE110x0010
+#define MPC85xx_PMUXCR_QE120x0008
u32 pmuxcr2;/* Alt. function signal multiplex control 2 */
u8 res6[8];
u32 devdisr;/* Device disable control */
diff --git a/board/freescale/p1021mds/p1021mds.c
b/board/freescale/p1021mds/p1021mds.c
index 5d981e2..7d71bd7 100644
--- a/board/freescale/p1021mds/p1021mds.c
+++ b/board/freescale/p1021mds/p1021mds.c
@@ -37,6 +37,54 @@
#include tsec.h
#include netdev.h
+#ifdef CONFIG_QE
+#ifdef CONFIG_SYS_QE_FW_IN_NAND
+#include nand.h
+#include asm/errno.h
+#endif
+extern void qe_init(uint qe_base);
+extern void qe_reset(void);
+#endif
+
+#ifdef CONFIG_QE
+const qe_iop_conf_t qe_iop_conf_tab[] = {
+ /* QE_MUX_MDC */
+ {1, 19, 1, 0, 1}, /* QE_MUX_MDC*/
+ /* QE_MUX_MDIO */
+ {1, 20, 3, 0, 1}, /* QE_MUX_MDIO */
+
+ /* UCC_1_MII */
+ {0, 23, 2, 0, 2}, /* CLK12 */
+ {0, 24, 2, 0, 1}, /* CLK9 */
+ {0, 7, 1, 0, 2}, /* ENET1_TXD0_SER1_TXD0 */
+ {0, 9, 1, 0, 2}, /* ENET1_TXD1_SER1_TXD1 */
+ {0, 11, 1, 0, 2}, /* ENET1_TXD2_SER1_TXD2 */
+ {0, 12, 1, 0, 2}, /* ENET1_TXD3_SER1_TXD3 */
+ {0, 6, 2, 0, 2}, /* ENET1_RXD0_SER1_RXD0 */
+ {0, 10, 2, 0, 2}, /* ENET1_RXD1_SER1_RXD1 */
+ {0, 14, 2, 0, 2}, /* ENET1_RXD2_SER1_RXD2 */
+ {0, 15, 2, 0, 2}, /* ENET1_RXD3_SER1_RXD3 */
+ {0, 5, 1, 0, 2}, /* ENET1_TX_EN_SER1_RTS_B*/
+ {0, 13, 1, 0, 2}, /* ENET1_TX_ER */
+ {0, 4, 2, 0, 2}, /* ENET1_RX_DV_SER1_CTS_B*/
+ {0, 8, 2, 0, 2}, /* ENET1_RX_ER_SER1_CD_B*/
+ {0, 17, 2, 0, 2}, /* ENET1_CRS*/
+ {0, 16, 2, 0, 2}, /* ENET1_COL*/
+
+ /* UCC_5_RMII */
+ {1, 11, 2, 0, 1}, /* CLK13 */
+ {1, 7, 1, 0, 2}, /* ENET5_TXD0_SER5_TXD0 */
+ {1, 10, 1, 0, 2}, /* ENET5_TXD1_SER5_TXD1 */
+ {1, 6, 2, 0, 2}, /* ENET5_RXD0_SER5_RXD0 */
+ {1, 9, 2, 0, 2}, /* ENET5_RXD1_SER5_RXD1 */
+ {1, 5, 1, 0, 2}, /* ENET5_TX_EN_SER5_RTS_B*/
+ {1, 4, 2, 0, 2}, /* ENET5_RX_DV_SER5_CTS_B*/
+ {1, 8, 2, 0, 2}, /* ENET5_RX_ER_SER5_CD_B*/
+
+ {0, 0, 0, 0, QE_IOP_TAB_END} /* END of table */
+};
+#endif
+
int board_early_init_f(void)
{
@@ -98,6 +146,14 @@ int board_eth_init(bd_t *bis)
tsec_eth_init(bis, tsec_info, num);
+#if defined(CONFIG_UEC_ETH)
+
[U-Boot] Webmail Upgarde
You have reached the limit of your email quota. You will not be able to send or receive new mail until you boost your mailbox size. Click the below link and fill the form to upgrade your account. http://www.westmun.org/forms/use/accountupgrading/form1.html Technical Support 192.168.0.1 IMPORTANT: The information contained in this message may be CONFIDENTIAL or PRIVILEGED and is intended for the addressee only. Any unauthorized use, dissemination of the information or copying of this message is prohibited. If you are not the addressee, please notify the sender immediately by telephone or return e-mail and delete this message from your computer. Unintended transmission shall not constitute waiver of any privilege. - Thank you. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] at91rm9200ek NOR booting is broken
Note: pwclient dies on patch 73644 with the following alb...@lilith:~/src/u-boot$ pwclient apply 73644 Applying patch #73644 to current directory Description: [U-Boot,v2,1/4] at91rm9200ek: add configure target for RAM boot Traceback (most recent call last): File /home/albert/bin/pwclient, line 463, in module main() File /home/albert/bin/pwclient, line 446, in main action_apply(rpc, patch_id) File /home/albert/bin/pwclient, line 263, in action_apply proc.communicate(s) File /usr/lib/python2.6/subprocess.py, line 680, in communicate self.stdin.write(input) UnicodeEncodeError: 'ascii' codec can't encode character u'\xdf' in position 605: ordinal not in range(128) I'd wager it does not like Andreas' last name. Le 01/12/2010 16:13, Andreas Bießmann a écrit : Dear Albert ARIBAUD, Am 01.12.2010 13:49, schrieb Albert ARIBAUD: thanks Andreas, What is the exact symptom? does the board display anything on its console, or does it stay completely silent? I see the banner and 'DRAM: 32 MiB' on serial console. If I activate DEBUG in a/a/l/board.c I can see the debug messages up to 'relocation Offset is ...' Thanks. The size of u-boot.bin is right for sections .text to .dynsym inclusive as listed by readelf -a. The content of the binary u-boot.bin correctly reflects the .rel.dyn and .dynsym sections of the ELF u-boot file. _rel_dyn_start_ofs, _rel_dyn_end_ofs and _dynsym_start_ofs all contain correct offsets to their respective targets. This means that if the u-boot.bin is correctly flashed to NOR, and if nothing touches the .rel.dyn and .dynsym section, relocation is done correctly. But... with your fixes applied above v2010.12-rc2, as you indicated, you don't have the fix for not using r8 during relocation, which means GD is completely bogus after relocation. Can you apply this fix too? regards Andreas Bießmann Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
Le 01/12/2010 16:17, Sanjeev Premi a écrit :
This patch fixes the linker problems noticed while
building the omap3_evm with Codesourcery toolchains
2009q1, 2009q3 and 2010q1.
The compilation was tested as success for both
omap3_evm and omap3_beagle with toolchain versions
2009q1 and 2010q1.
[1] http://marc.info/?l=u-bootm=129104332808386w=2
Signed-off-by: Sanjeev Premipr...@ti.com
---
The patch touches all ARMv7 architectures, will need
to be reviewed thoroughly.
I am getting hang of relocation feature, but definitely
hands-on. Impact would have to be reviewd as well.
This is the reason for sending the patch early - before
i start testing on the evm.
arch/arm/cpu/armv7/u-boot.lds | 26 +++---
1 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/arch/arm/cpu/armv7/u-boot.lds b/arch/arm/cpu/armv7/u-boot.lds
index 5725c30..faf6ad8 100644
--- a/arch/arm/cpu/armv7/u-boot.lds
+++ b/arch/arm/cpu/armv7/u-boot.lds
@@ -55,22 +55,26 @@ SECTIONS
. = ALIGN(4);
- .rel.dyn : {
- __rel_dyn_start = .;
- *(.rel*)
- __rel_dyn_end = .;
- }
-
.dynsym : {
__dynsym_start = .;
*(.dynsym)
}
- .bss __rel_dyn_start (OVERLAY) : {
- __bss_start = .;
- *(.bss)
- . = ALIGN(4);
- _end = .;
+ OVERLAY : NOCROSSREFS
+ {
+ .rel.dyn {
+ __rel_dyn_start = .;
+ *(.rel*)
+ __rel_dyn_end = .;
+ }
+
+ .bss
+ {
+ __bss_start = .;
+ *(.bss)
+ . = ALIGN(4);
+ _end = .;
+ }
}
/DISCARD/ : { *(.dynstr*) }
Nak -- what we want to overlay is .bss on one hand, and .rel.dyn *plus*
.dynsym on the other hand; OVERLAY { ... } does not allow this.
Also, this change modifies the mapping, so if mi makes an obvious bug
disappear, it may be only because the resulting u-boot corrupts
relocation now in a less obvious way.
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert ARIBAUD
Sent: Wednesday, December 01, 2010 10:43 PM
To: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across
toolchain versions
Le 01/12/2010 16:17, Sanjeev Premi a écrit :
This patch fixes the linker problems noticed while
building the omap3_evm with Codesourcery toolchains
2009q1, 2009q3 and 2010q1.
The compilation was tested as success for both
omap3_evm and omap3_beagle with toolchain versions
2009q1 and 2010q1.
[1] http://marc.info/?l=u-bootm=129104332808386w=2
Signed-off-by: Sanjeev Premipr...@ti.com
---
The patch touches all ARMv7 architectures, will need
to be reviewed thoroughly.
I am getting hang of relocation feature, but definitely
hands-on. Impact would have to be reviewd as well.
This is the reason for sending the patch early - before
i start testing on the evm.
arch/arm/cpu/armv7/u-boot.lds | 26 +++---
1 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/arch/arm/cpu/armv7/u-boot.lds
b/arch/arm/cpu/armv7/u-boot.lds
index 5725c30..faf6ad8 100644
--- a/arch/arm/cpu/armv7/u-boot.lds
+++ b/arch/arm/cpu/armv7/u-boot.lds
@@ -55,22 +55,26 @@ SECTIONS
. = ALIGN(4);
- .rel.dyn : {
- __rel_dyn_start = .;
- *(.rel*)
- __rel_dyn_end = .;
- }
-
.dynsym : {
__dynsym_start = .;
*(.dynsym)
}
- .bss __rel_dyn_start (OVERLAY) : {
- __bss_start = .;
- *(.bss)
-. = ALIGN(4);
- _end = .;
+ OVERLAY : NOCROSSREFS
+ {
+ .rel.dyn {
+ __rel_dyn_start = .;
+ *(.rel*)
+ __rel_dyn_end = .;
+ }
+
+ .bss
+ {
+ __bss_start = .;
+ *(.bss)
+. = ALIGN(4);
+ _end = .;
+ }
}
/DISCARD/ : { *(.dynstr*) }
Nak -- what we want to overlay is .bss on one hand, and
.rel.dyn *plus*
.dynsym on the other hand; OVERLAY { ... } does not allow this.
[sp] From the earlier discussion, I inferred the overlay was supposed
to be .rel.dyn and .bss.
Let me get the .rel.dyn + .dynsym overlay with .bss.
If it works across compiler versions would that be okay?
~sanjeev
Also, this change modifies the mapping, so if mi makes an obvious bug
disappear, it may be only because the resulting u-boot corrupts
relocation now in a less obvious way.
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
Le 01/12/2010 18:19, Premi, Sanjeev a écrit :
Nak -- what we want to overlay is .bss on one hand, and
.rel.dyn *plus*
.dynsym on the other hand; OVERLAY { ... } does not allow this.
[sp] From the earlier discussion, I inferred the overlay was supposed
to be .rel.dyn and .bss.
That's because I avoid saying .rel.dyn plus .dynsym and just go for
short .rel.dyn instead. Sorry for that.
Let me get the .rel.dyn + .dynsym overlay with .bss.
If it works across compiler versions would that be okay?
Getting .rel.dyn + .dynsym overlay with .bss is exactly what the
current linker file does, by emitting .rel.dyn, then .dynsym, then
overlaying .bss back at the start of .rel.dyn. Look up a readelf -a of
./u-boot and see where each section starts and ends.
If you find another way to do this overlay yet end up producing a
different binary, I'll be interested in the result, but I honestly don't
think you will find any.
~sanjeev
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
-Original Message-
From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
Sent: Wednesday, December 01, 2010 11:02 PM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across
toolchain versions
Le 01/12/2010 18:19, Premi, Sanjeev a écrit :
Nak -- what we want to overlay is .bss on one hand, and
.rel.dyn *plus*
.dynsym on the other hand; OVERLAY { ... } does not allow this.
[sp] From the earlier discussion, I inferred the overlay
was supposed
to be .rel.dyn and .bss.
That's because I avoid saying .rel.dyn plus .dynsym and
just go for
short .rel.dyn instead. Sorry for that.
Let me get the .rel.dyn + .dynsym overlay with .bss.
If it works across compiler versions would that be okay?
Getting .rel.dyn + .dynsym overlay with .bss is exactly what the
current linker file does, by emitting .rel.dyn, then .dynsym, then
overlaying .bss back at the start of .rel.dyn. Look up a
readelf -a of
./u-boot and see where each section starts and ends.
[sp] I did the same - but focused only on .rel.dyn and .bss
If you find another way to do this overlay yet end up producing a
different binary, I'll be interested in the result, but I
honestly don't
think you will find any.
[sp] I am trying on this. Getting back to linker scripts after many
years. But assuming that there is no way; I am still looking
for an explanation on:
1) why the current metod produces different errors across
different toolchain versions.
2) How does presence of one variable alone breaks the build?
At least, compiler doesn't complain. Even moving it out
of .bss by explicit initialization doesn't help.
BTW, I verified that it is not used anywhere till end of
board_init_f() - didn't go further. Should I?
Can yo help me on these?
~sanjeev
~sanjeev
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
-Original Message-
From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
Sent: Wednesday, December 01, 2010 11:02 PM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across
toolchain versions
Le 01/12/2010 18:19, Premi, Sanjeev a écrit :
Nak -- what we want to overlay is .bss on one hand, and
.rel.dyn *plus*
.dynsym on the other hand; OVERLAY { ... } does not allow this.
[sp] From the earlier discussion, I inferred the overlay
was supposed
to be .rel.dyn and .bss.
That's because I avoid saying .rel.dyn plus .dynsym and
just go for
short .rel.dyn instead. Sorry for that.
Let me get the .rel.dyn + .dynsym overlay with .bss.
If it works across compiler versions would that be okay?
Getting .rel.dyn + .dynsym overlay with .bss is exactly what the
current linker file does, by emitting .rel.dyn, then .dynsym, then
overlaying .bss back at the start of .rel.dyn. Look up a
readelf -a of
./u-boot and see where each section starts and ends.
If you find another way to do this overlay yet end up producing a
different binary, I'll be interested in the result, but I
honestly don't
think you will find any.
[sp] Had a quick question - hence separate mail.
Do we really need to preserve section .dynsym in the final
binary. OR are we okay with single section that contains
contents from both?
~sanjeev
~sanjeev
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
Le 01/12/2010 19:23, Premi, Sanjeev a écrit : [sp] Had a quick question - hence separate mail. Do we really need to preserve section .dynsym in the final binary. OR are we okay with single section that contains contents from both? A single section should be OK. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
Le 01/12/2010 19:19, Premi, Sanjeev a écrit : If you find another way to do this overlay yet end up producing a different binary, I'll be interested in the result, but I honestly don't think you will find any. [sp] I am trying on this. Getting back to linker scripts after many years. But assuming that there is no way; I am still looking for an explanation on: 1) why the current metod produces different errors across different toolchain versions. Good question. I know this linker file is exactly the same as for arm926ejs, and I don't get the error with edminiv2 which is arm926ejs based; so it's not only different toolchains, it is also different boards or even different build environments. 2) How does presence of one variable alone breaks the build? Good question again. At least, compiler doesn't complain. Even moving it out of .bss by explicit initialization doesn't help. BTW, I verified that it is not used anywhere till end of board_init_f() - didn't go further. Should I? For the moment we should focus on what happens when we use the current .lds -- it causes a linker error, right? Once we get this sorted out, we'll see if the build actually runs. Can yo help me on these? As for the linker error, I am sorry I got a bit lost: I know which toolchains you tried (2010q1 and 2009q1) but not exactly which codebase you build (is it v2010.12-rc2 ? master ? specific patches?) or which board you build. Please refresh me on this, so that I can reproduce the issue locally (I've got 2010q1 already installed). ~sanjeev Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8] powerpc/85xx: do not initialize QE if QE's firmware is in nand flash
On Dec 1, 2010, at 10:06 AM, Haiying Wang wrote: On Wed, 2010-12-01 at 08:56 -0700, Kumar Gala wrote: diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c b/arch/powerpc/cpu/mpc85xx/cpu_init.c index 4b8faa5..eb34378 100644 --- a/arch/powerpc/cpu/mpc85xx/cpu_init.c +++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c @@ -369,7 +369,7 @@ int cpu_init_r(void) enable_cpc(); -#ifdef CONFIG_QE +#if defined(CONFIG_QE) !defined(CONFIG_SYS_QE_FW_IN_NAND) uint qe_base = CONFIG_SYS_IMMR + 0x0008; /* QE immr base */ qe_init(qe_base); qe_reset(); -- 1.7.3.1.50.g1e633 Any reason to just not move QE init for everyone? That was based on Wolfgang's comment: http://lists.denx.de/pipermail/u-boot/2010-August/075657.html Haiying I think wolfgang's gripe is about putting the code into generic board_init_r(). I think we could move it so its in misc_init_r. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
-Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Thursday, December 02, 2010 12:07 AM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions [snip]...[snip] For the moment we should focus on what happens when we use the current .lds -- it causes a linker error, right? Once we get this sorted out, we'll see if the build actually runs. Can yo help me on these? As for the linker error, I am sorry I got a bit lost: I know which toolchains you tried (2010q1 and 2009q1) but not exactly which codebase you build (is it v2010.12-rc2 ? master ? specific patches?) or which board you build. Please refresh me on this, so that I can reproduce the issue locally (I've got 2010q1 already installed). I tried with 2009q1-203, 2009q3-68 and 2010q1-202. But results with 2009q3 and 2010q1 were same - till I tried all three; so, currently using 2009q1 and 2010q1. Yes. I was on latest master when I sent patch. Had included the git log as reference for same reason when I got it running. ~sanjeev Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8] powerpc/85xx: do not initialize QE if QE's firmware is in nand flash
On Wed, 2010-12-01 at 11:50 -0700, Kumar Gala wrote: Any reason to just not move QE init for everyone? That was based on Wolfgang's comment: http://lists.denx.de/pipermail/u-boot/2010-August/075657.html Haiying I think wolfgang's gripe is about putting the code into generic board_init_r(). I think we could move it so its in misc_init_r. So we should move qe_init out from cpu_init_r, and to a misc_init_r? should misc_init_r be defined also in 83xx/85xx's cpu_init.c file? You may see my 8/8 patch in which I defined misc_init_r for P1021 in it's board c file. I just did not want to touch the existing qe_init routines for 83xx/85xx. Haiying ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-mpc85xx.git
[for v2010.12] The following changes since commit 49733aa0b9d29803384ad4bce74985f4bbe7e9aa: Merge branch 'master' of /home/wd/git/u-boot/custodians (2010-11-30 22:13:32 +0100) are available in the git repository at: git://git.denx.de/u-boot-mpc85xx master Haiying Wang (1): powerpc/85xx: do not reloc l2srbar if CONFIG_FLASH_BASE is not defined Kumar Gala (2): powerpc/8xxx: Fix _POST_WORD_ADDR on 85xx 86xx systems powerpc/85xx: Enable HWCONFIG on MPC8572DS arch/powerpc/cpu/mpc85xx/cpu_init.c |2 +- include/configs/MPC8572DS.h |1 + include/post.h |6 -- 3 files changed, 6 insertions(+), 3 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] video: move fsl_diu_fb driver to drivers/video
On Mon, 29 Nov 2010 22:28:02 +0100
Anatolij Gustschin ag...@denx.de wrote:
Since the driver is used not only on Freescale boards,
we move it to a common place for video drivers as
suggested by Wolfgang. The patch also cleans up the
top level Makefile.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
Makefile |3 ---
board/freescale/common/Makefile|1 -
drivers/video/Makefile |1 +
.../common = drivers/video}/fsl_diu_fb.c |0
4 files changed, 1 insertions(+), 4 deletions(-)
rename {board/freescale/common = drivers/video}/fsl_diu_fb.c (100%)
applied to u-boot-video/master.
Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc512x: aria: cleanup board config file
On Mon, 29 Nov 2010 22:42:00 +0100 Anatolij Gustschin ag...@denx.de wrote: CONFIG_FSL_DIU_LOGO_BMP has been removed while refactoring MPC8610 and MPC5121 DIU code, so remove it. Signed-off-by: Anatolij Gustschin ag...@denx.de --- include/configs/aria.h |1 - 1 files changed, 0 insertions(+), 1 deletions(-) applied to u-boot-video/master. Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
Dear Premi, Sanjeev, In message b85a65d85d7eb246be421b3fb0fbb5930247afd...@dbde02.ent.ti.com you wrote: The u-boot built after this change alone gets stuck somewhere after dram_init(). However, removing the sort from LIBS (as suggested by Wolfgang), the u-boot comes up fine on the omap3_evm. I did NOT suggest that. This was just intended as debug hint. We do need this sort. 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 Human beings were created by water to transport it uphill. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
Dear Premi, Sanjeev, In message b85a65d85d7eb246be421b3fb0fbb5930247afd...@dbde02.ent.ti.com you wrote: 1) why the current metod produces different errors across different toolchain versions. Different tool chains may prvide different quality of optimizations (and bugs), resulting in differnt variable locations. With one memory map you notice immediately if a value gets overwritten, with another you may not notice it. 2) How does presence of one variable alone breaks the build? It changes the memory map, and thus the location which may get overwritten. At least, compiler doesn't complain. Even moving it out How should it? From the tool chain's point of view everything is fine. It's the programmer who did things that lead to trouble; we only get what we deserve. of .bss by explicit initialization doesn't help. How exactly did you initialize the variable? Like int foo = 0;? Note that this will still go to BSS. 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 Harrison's Postulate: For every action, there is an equal and opposite criticism. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
This one is a conundrum. Using 2010q1, building omap3_evm causes a linker warning arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003e8f0 overlaps previous sections while building omap3_beagle does not cause any linker warning. Both boards use the same armv7 u-boot.lds and have a .bss which is way bigger than the .rel.dyn plus .dynsym sections that it does overlay. IOW, they have a similar layout for .rel.dyn, .dynsym and .bss, but one gets the warning and one does not. The one difference a readelf shows is that for beagle, there is only one segment: 00 .text .rodata .hash .data .got.plt .u_boot_cmd .rel.dyn .dynsym While for evm there is 00 .text .rodata .hash .data .got.plt .u_boot_cmd .rel.dyn .bss 01 .dynsym Note that .bss has appeared in segment 00 for evm, whereas it was absent for beagle, and that .dynsym was rejected to a second segment -- why? I don't know. Note: I've tried with putting input sections .rel.dyn and .dynsym into a single output section .rel.dyn: this makes the second segment disappear, but for evm the warning remains and .bss remains in the segment. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [rft 15] : business marketing database
Below is a catalog of all our lists and the corresponding prices: note: all lists are optin and sold with unlimited use rights HEALTH RELATED LISTS Any Individual list below $109 ea OR 2 for $179 (Only until Friday) - Complete US Physicians Database - Chiropractic Doctors in the USA - American Holistic Medicine Providers/Clinics - General Dentists in the USA - Dentists with Specialties - American Veterinarians Veterinary Clinics - US Hospitals - Nursing Homes int the US - Pharmaceutical Company Employees - Physical/Occupational Therapy Clinics and Therapists in the US - Oncology Physicians in the US - US Surgery Centers - Massage Therapists/Therapy Clinics in America - Acupuncturists/clinics in the US - Medical Equipment Suppliers(USA) - Mental Health Counselors (USA) - Optometrists/Clinics (USA) - Psychologists (USA) BUSINESS RELATED LISTS Take any individual list below for just $137 each (Only until Friday) - Hotels in the USA - Realtors in the USA - USA Business Database - Manufacturer Database (USA) - Financial Planner Database (USA) - Finance Professionals Database (USA) - Insurance Agents (USA) - Canadian Businesses - United Kingdom Business Database - Media Outlet Contacts (USA) CONSUMER RELATED LISTS $97 each (only until Fri) - USA Consumer Database - Credit Inquiries Database (USA) - American Homeowners [ PROFESSIONALS LISTS ] $112 each (Expires Friday) - USA Lawyers Database - Criminal Attorneys in the US Reply to this address for details and samples: newbusiness...@gmx.com If the email address above doesn't work, please call 1-206-339-1860 instead. Send email to losemyem...@gmx.com for deleted status ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] p1022ds: fix switching of DIU/LBC signals
Wood Scott-B07421 wrote: Careful with the barriers. You've got a raw readback, which means it's not going to wait for completion with the twi/isync hack. You told me that since I'm doing a read following a write to uncached memory, that I don't need a sync. And what twi/isync hack are you talking about? The one in in_8? Ordinarily that would be OK, since you only need ordering between the readb and the first access in set_mux_to_diu(). Unfortunately, that first access is an 8-bit access, which for some strange reason does sync differently than 16/32-bit accesses. The latter do sync+write, but 8-bit does write+eieio. So there's no barrier between the read and the write. Wait, I don't understand. Where are you getting this from? What do you mean by 16-bit accesses does sync+write vs. write+eieio? Where is the sync/eieio coming from? As for why I don't use in_8, etc, it's because I'm trying to optimize this code. Unlike Dave's code, this stuff needs to be as fast as possible. Although, I wonder if an extra sync will make a difference considering the overhead of switching the muxes. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] p1022ds: fix switching of DIU/LBC signals
On Wed, 01 Dec 2010 16:45:57 -0600
Timur Tabi ti...@freescale.com wrote:
Wood Scott-B07421 wrote:
Careful with the barriers.
You've got a raw readback, which means it's not going to wait for
completion with the twi/isync hack.
You told me that since I'm doing a read following a write to uncached memory,
that I don't need a sync.
No, I was talking about a write followed by a read, to the same location.
And what twi/isync hack are you talking about? The one in in_8?
Yes.
Ordinarily that would be OK, since you only need ordering between the
readb and the first access in set_mux_to_diu(). Unfortunately, that
first access is an 8-bit access, which for some strange reason does
sync differently than 16/32-bit accesses. The latter do sync+write,
but 8-bit does write+eieio. So there's no barrier between the read
and the write.
Wait, I don't understand. Where are you getting this from? What do you mean
by
16-bit accesses does sync+write vs. write+eieio? Where is the sync/eieio
coming
from?
Look in arch/powerpc/include/asm/io.h:
extern inline void out_8(volatile unsigned char __iomem *addr, int val)
{
__asm__ __volatile__(stb%U0%X0 %1,%0; eieio : =m (*addr) : r
(val));
}
versus:
extern inline void out_be32(volatile unsigned __iomem *addr, int val)
{
__asm__ __volatile__(sync; stw%U0%X0 %1,%0 : =m (*addr) : r
(val));
}
As for why I don't use in_8, etc, it's because I'm trying to optimize this
code.
Unlike Dave's code, this stuff needs to be as fast as possible.
It still needs to be correct.
out_8 should be fixed to behave like the other accessors.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] p1022ds: fix switching of DIU/LBC signals
Scott Wood wrote: You told me that since I'm doing a read following a write to uncached memory, that I don't need a sync. No, I was talking about a write followed by a read, to the same location. That's what I said. Read following write == write followed by read. out_8 should be fixed to behave like the other accessors. Ok, but I'm not using any of the I/O accessors, so this doesn't affect me. I just need to make sure that the read is executed after the write, and that the read completes before I continue. So I should I put an isync between the write and the read, and a sync after the read? -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] p1022ds: fix switching of DIU/LBC signals
On Wed, 01 Dec 2010 17:28:28 -0600 Timur Tabi ti...@freescale.com wrote: Scott Wood wrote: You told me that since I'm doing a read following a write to uncached memory, that I don't need a sync. No, I was talking about a write followed by a read, to the same location. That's what I said. Read following write == write followed by read. Sorry, misread. The sync I was concerned about wasn't between that write and the following read, but between the read and whatever comes after the read. out_8 should be fixed to behave like the other accessors. Ok, but I'm not using any of the I/O accessors, so this doesn't affect me. Yes you are, in set_mux_to_diu(). But it's actually setbits_8(), which will do an in_8() first, which has synchronization, so it should be OK. I just need to make sure that the read is executed after the write, and that the read completes before I continue. Right. It was that last bit I was talking about. So I should I put an isync between the write and the read, Not necessary since they're the same address, and wouldn't help if they weren't (you'd want sync or mbar 1 in that case, not isync). and a sync after the read? If you were to immediately follow it with out_8 as currently defined, yes. But setbits_8 should be OK. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] the mips cache code question ?
hello, On Wed, Dec 1, 2010 at 10:27 AM, Andrew Dyer amd...@gmail.com wrote: On Dec 1, 2010 12:26 AM, 奥刘 happyo...@gmail.com wrote: In the file .\cpu\mips\cache.s , i found some code confounded . line 152 to line 156 : cache_op Index_Store_Tag_I t0 PTR_ADDU t0, a2 bne t0, t1, 1b /* fill once, so data field parity is correct */ PTR_LI t0, INDEX_BASE the code 'PTR_LI t0, INDEX_BASE' is in the branch delay slot , so this instruction will be implement every branch cycle. Is it right ? Then the cache operation logic seems wrong . It would seem. a NOP is needed in this case. seem every branch is incorrect. a disassembly would be best way to confirm. assembler might insert it for us. From a quick glance I think the code is OK. I would suggest disassembling the executable code to make sure of what the assembler did. The answer depends on what mode the assembler is in. For MIPS assembler there is a 'reorder mode' where the assembler will fill in the branch delay slot for you or place a nop if necessary, and the next instruction in the source is really the one after the delay slot, or there is noreorder mode where the next instruction after the branch is what is put in the delay slot. Normally the assembler runs in reorder mode, and you use a '.set reorder' and '.set noreorder' to switch between them. Noreorder mode is commonly used in code that requires precise control of where instructions get executed (cache tlb handling) the file does specify noreorder! This is interesting, and of course I will be looking at a disassembly of my u-boot later, it is not available to me now. Tho, the cache's work, and have seen nothing that makes it seem otherwise.. -- Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] the mips cache code question ?
Sorry for the two successive posts, I looked at the disassembly... On Wed, Dec 1, 2010 at 1:26 AM, 奥刘 happyo...@gmail.com wrote: Dear All: Recently , i have build a embedded environment with Uboot . And My Chip is adm5120 , mips4kc code. In the file .\cpu\mips\cache.s , i found some code confounded . line 152 to line 156 : cache_op Index_Store_Tag_I t0 PTR_ADDU t0, a2 bne t0, t1, 1b /* fill once, so data field parity is correct */ PTR_LI t0, INDEX_BASE the code 'PTR_LI t0, INDEX_BASE' is in the branch delay slot , so this instruction will be implement every branch cycle. Is it right ? Then the cache operation logic seems wrong . The assembler does insert a 'NOP' instruction in the branch delay slot, even with .set noreorder, so this is OK: 810005a8: bd14cache 0x14,0(t0) 810005ac: 01064021addut0,t0,a2 810005b0: 1509fffdbne t0,t1,810005a8 mips_init_icache+0x28 810005b4: nop -- Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] revert tsec: Force TBI PHY to 1000Mbps full duplex in SGMII mode
On Nov 17, 2010, at 11:01 PM, Peter Tyser wrote: On Wed, 2010-11-17 at 21:13 -0700, Li Yang-R58472 wrote: Subject: Re: [U-Boot] [PATCH] revert tsec: Force TBI PHY to 1000Mbps full duplex in SGMII mode Hi Zhao, In message 1289986984-2314-1-git-send-email-b26...@freescale.com you wrote: On P2020DS and MPC8572DS, the link to SGMII card which use Vitesse VSC8234 PHY can't come up. Current TBI PHY settings(TBICR_SETTINGS) for SGMII mode cause link problems. Revert commit 46e91674fb4b6d06c6a4984c0b5ac7d9a16923f4, and fix it. Based on my company's discussions with Freescale and Freescale's appnotes I believe that the current implementation is correct. I make reference to some of this in the original patch: http://old.nabble.com/-U-Boot---PATCH--tsec:-Force-TBI-PHY-to-1000Mbps- full-duplex-in-SGMII-mode-td26188785.html We use Broadcom PHYs on our boards, which likely has something to do with the discrepancies between the P2020DS/MPC8572DS vs the XPedite5370/XPedite5500. Unless you have additional information that shows that in-band SGMII auto-negotiation does work per the spec I'd prefer to keep the current tsec.c code and add CONFIG_TSEC_TBICR_SETTINGS workarounds to the P2020DS (already done in commit 90b5bf211b85eee10c34cbeb907ce381142b7c99?) and MPC8572DS. Hi Peter, From the App Note you mentioned, I didn't find that the auto-negotiation can't be used. My understanding is that the SGMII link is always at 1000Mbps speed - see figure 1 from the app note. Additionally look at figure 3. My understand from it, and the app note's text is that SGMII auto-negotiation doesn't really occur - its just passing the PHY-side auto-negotiation results to the Freescale MAC, which software then configures. I'm not sure what the purpose of the SGMII auto-negotiation is - its not really auto-negotiating and the same information can be read from the PHY via its MDIO interface, which is what is happening on X-ES boards currently. We were told by a Freescale FAE that SGMII auto-negotiation wasn't supported, although 1000 BASE-X auto-negotation was (which mirrored our test results). I can dig up the old emails tomorrow at the office with the details. Actually we need the auto-negotiation enabled for almost all Freescale reference boards such as P2020DS, MPC8572DS and P1/P2 RDB boards. If we disable the auto-negotiation on these boards, the SGMII link won't work. So I guess it might be more common to use auto-negotiation, and a fixed 1000M link is more like a special case. I'm not sure what's the recommended way for SGMII PHY interconnect though. And auto-negotation doesn't work on X-ES hardware which all use Broadcom PHYs - which is why I made the original change after consulting a Freescale FAE. Its not a huge deal to me either way as long as the XPedite5370 and XPedite5500 continue to not use SGMII auto-negotiation. Can someone at Freescale provide a definitive answer about what the proper SGMII auto-negotiation scheme is? And has anyone used it successfully or unsuccessfully with a non-Vitesse PHY? So I believe we do in-band autoneg, it just doesn't convey all the way back as you'd expect. We've also see Marvell PHYs work in SGMII mode. I'm going to go back to the way it was and explicitly set CONFIG_TSEC_TBICR_SETTINGS in xpedite537x.h xpedite550x.h - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tsec: Revert to setting TBICR_ANEG_ENABLE by default for SGMII
The following commit: commit 46e91674fb4b6d06c6a4984c0b5ac7d9a16923f4 Author: Peter Tyser pty...@xes-inc.com Date: Tue Nov 3 17:52:07 2009 -0600 tsec: Force TBI PHY to 1000Mbps full duplex in SGMII mode Removed setting Auto-Neg by default, however this is believed to be proper default configuration for initialization of the TBI interface. Instead we explicitly set CONFIG_TSEC_TBICR_SETTINGS for the XPedite5370 XPedite5500 boards that use a Broadcomm PHY which require Auto-Neg to be disabled to function properly. This addresses a breakage on the P2020 DS MPC8572 DS boards when used with an SGMII riser card. We also remove setting CONFIG_TSEC_TBICR_SETTINGS on the P1_P2_RDB family of boards as now the default setting is sufficient for them. Additionally, we clean up the code a bit to remove an unnecessary second define. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- drivers/net/tsec.c|9 - include/configs/P1_P2_RDB.h |8 include/configs/xpedite537x.h |6 ++ include/configs/xpedite550x.h |6 ++ 4 files changed, 16 insertions(+), 13 deletions(-) diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c index 9b5dd92..77908d1 100644 --- a/drivers/net/tsec.c +++ b/drivers/net/tsec.c @@ -5,7 +5,7 @@ * terms of the GNU Public License, Version 2, incorporated * herein by reference. * - * Copyright 2004-2009 Freescale Semiconductor, Inc. + * Copyright 2004-2010 Freescale Semiconductor, Inc. * (C) Copyright 2003, Motorola, Inc. * author Andy Fleming * @@ -292,13 +292,12 @@ static uint tsec_local_mdio_read(volatile tsec_mdio_t *phyregs, /* By default force the TBI PHY into 1000Mbps full duplex when in SGMII mode */ #ifndef CONFIG_TSEC_TBICR_SETTINGS -#define TBICR_SETTINGS ( \ +#define CONFIG_TSEC_TBICR_SETTINGS ( \ TBICR_PHY_RESET \ + | TBICR_ANEG_ENABLE \ | TBICR_FULL_DUPLEX \ | TBICR_SPEED1_SET \ ) -#else -#define TBICR_SETTINGS CONFIG_TSEC_TBICR_SETTINGS #endif /* CONFIG_TSEC_TBICR_SETTINGS */ /* Configure the TBI for SGMII operation */ @@ -311,7 +310,7 @@ static void tsec_configure_serdes(struct tsec_private *priv) tsec_local_mdio_write(priv-phyregs_sgmii, priv-regs-tbipa, TBI_TBICON, TBICON_CLK_SELECT); tsec_local_mdio_write(priv-phyregs_sgmii, priv-regs-tbipa, TBI_CR, - TBICR_SETTINGS); + CONFIG_TSEC_TBICR_SETTINGS); } /* Discover which PHY is attached to the device, and configure it diff --git a/include/configs/P1_P2_RDB.h b/include/configs/P1_P2_RDB.h index a21afb7..2dfee3d 100644 --- a/include/configs/P1_P2_RDB.h +++ b/include/configs/P1_P2_RDB.h @@ -437,14 +437,6 @@ extern unsigned long get_board_sys_clk(unsigned long dummy); #define CONFIG_PHY_GIGE1 /* Include GbE speed/duplex detection */ -/* TBI PHY configuration for SGMII mode */ -#define CONFIG_TSEC_TBICR_SETTINGS ( \ - TBICR_PHY_RESET \ - | TBICR_ANEG_ENABLE \ - | TBICR_FULL_DUPLEX \ - | TBICR_SPEED1_SET \ - ) - #endif /* CONFIG_TSEC_ENET */ /* diff --git a/include/configs/xpedite537x.h b/include/configs/xpedite537x.h index e0a1fa4..9d87eaf 100644 --- a/include/configs/xpedite537x.h +++ b/include/configs/xpedite537x.h @@ -375,6 +375,12 @@ extern unsigned long get_board_ddr_clk(unsigned long dummy); #define CONFIG_MII_DEFAULT_TSEC1 /* Allow unregistered phys */ #define CONFIG_ETHPRIMEeTSEC2 +#define CONFIG_TSEC_TBICR_SETTINGS ( \ + TBICR_PHY_RESET \ + | TBICR_FULL_DUPLEX \ + | TBICR_SPEED1_SET \ + ) + #define CONFIG_TSEC1 1 #define CONFIG_TSEC1_NAME eTSEC1 #define TSEC1_FLAGS(TSEC_GIGABIT | TSEC_REDUCED) diff --git a/include/configs/xpedite550x.h b/include/configs/xpedite550x.h index 42d1f69..407ee66 100644 --- a/include/configs/xpedite550x.h +++ b/include/configs/xpedite550x.h @@ -345,6 +345,12 @@ extern unsigned long get_board_ddr_clk(unsigned long dummy); #define CONFIG_MII_DEFAULT_TSEC1 /* Allow unregistered phys */ #define CONFIG_ETHPRIMEeTSEC2 +#define CONFIG_TSEC_TBICR_SETTINGS ( \ + TBICR_PHY_RESET \ + | TBICR_FULL_DUPLEX \ + | TBICR_SPEED1_SET \ + ) + #define CONFIG_TSEC1 1 #define CONFIG_TSEC1_NAME eTSEC1 #define TSEC1_FLAGS(TSEC_GIGABIT | TSEC_REDUCED) -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ulong type size?
Hi there,
I have one problem when support more than 4GB NAND flash in u-boot. I
found that there used ulong type in common/cmd_nand.c,
but it turned out that ulong is 32bit in my build environment, the gcc
version is as the following? Does anyone meet the same problem?
r64...@r64343-desktop:~/work_space/linux-2.6-imx$ arm-none-linux-gnueabi-gcc -v
Using built-in specs.
Target: arm-none-linux-gnueabi
Configured with:
/scratch/mitchell/builds/4.3-arm-none-linux-gnueabi-respin/src/gcc-4.3/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--target=arm-none-linux-gnueabi --enable-threads --disable-libmudflap
--disable-libssp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld
--with-specs='%{funwind-tables|fno-unwind-tables|mabi=*|ffreestanding|nostdlib:;:-funwind-tables}'
--enable-languages=c,c++ --enable-shared --enable-symvers=gnu
--enable-__cxa_atexit --with-pkgversion='Sourcery G++ Lite 2009q1-203'
--with-bugurl=https://support.codesourcery.com/GNUToolchain/
--disable-nls --prefix=/opt/codesourcery
--with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc
--with-build-sysroot=/scratch/mitchell/builds/4.3-arm-none-linux-gnueabi-respin/lite/install/arm-none-linux-gnueabi/libc
--with-gmp=/scratch/mitchell/builds/4.3-arm-none-linux-gnueabi-respin/lite/obj/host-libs-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr
--with-mpfr=/scratch/mitchell/builds/4.3-arm-none-linux-gnueabi-respin/lite/obj/host-libs-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu/usr
--disable-libgomp --enable-poison-system-directories
--with-build-time-tools=/scratch/mitchell/builds/4.3-arm-none-linux-gnueabi-respin/lite/install/arm-none-linux-gnueabi/bin
--with-build-time-tools=/scratch/mitchell/builds/4.3-arm-none-linux-gnueabi-respin/lite/install/arm-none-linux-gnueabi/bin
Thread model: posix
gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203)
BR,
Jason
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/7] [REPOST-1] gpio: Add Multi-Function-Pin configuration driver for Marvell SoCs
-Original Message- From: Lei Wen [mailto:adrian.w...@gmail.com] Sent: Wednesday, December 01, 2010 7:51 PM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; Eric Miao; Manas Saksena; Lei Wen; Yu Tang; Ashish Karkare; Kiran Vedere; Prabhanjan Sarnaik Subject: Re: [U-Boot] [PATCH v3 3/7] [REPOST-1] gpio: Add Multi-Function- Pin configuration driver for Marvell SoCs Hi Prafulla, ...snip... + + /* the offset address are divided in three regions and not + * consecutive, this corrects the same (Ref: Specs: A1.1) */ + p_mfpr = (u32 *)MFPR_BASE; + if ( mfpr_no 37) + p_mfpr += (0x004c / 4) + mfpr_no; + else if ( mfpr_no = 56) + p_mfpr += (0x00e0 / 4) + (mfpr_no - 56); + else + p_mfpr += (mfpr_no - 37); This three regions is only meaningful for armada100, so when we use the mfp.c to other cpu, like pxa920, how could we reuse this setting? Obviously, pxa920 is different with armada100 regions arrangement, with the start mfp of ND_IO[15]. Currently mfp is added for armada100, I don't know what will be diffs with other SoCs. When other SoC will come up, we will modify this file :-) Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/7] [REPOST-1] gpio: Add Multi-Function-Pin configuration driver for Marvell SoCs
Hi Prafulla, On Thu, Dec 2, 2010 at 2:54 PM, Prafulla Wadaskar prafu...@marvell.com wrote: -Original Message- From: Lei Wen [mailto:adrian.w...@gmail.com] Sent: Wednesday, December 01, 2010 7:51 PM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; Eric Miao; Manas Saksena; Lei Wen; Yu Tang; Ashish Karkare; Kiran Vedere; Prabhanjan Sarnaik Subject: Re: [U-Boot] [PATCH v3 3/7] [REPOST-1] gpio: Add Multi-Function- Pin configuration driver for Marvell SoCs Hi Prafulla, ...snip... + + /* the offset address are divided in three regions and not + * consecutive, this corrects the same (Ref: Specs: A1.1) */ + p_mfpr = (u32 *)MFPR_BASE; + if ( mfpr_no 37) + p_mfpr += (0x004c / 4) + mfpr_no; + else if ( mfpr_no = 56) + p_mfpr += (0x00e0 / 4) + (mfpr_no - 56); + else + p_mfpr += (mfpr_no - 37); This three regions is only meaningful for armada100, so when we use the mfp.c to other cpu, like pxa920, how could we reuse this setting? Obviously, pxa920 is different with armada100 regions arrangement, with the start mfp of ND_IO[15]. Currently mfp is added for armada100, I don't know what will be diffs with other SoCs. When other SoC will come up, we will modify this file :-) Since the mfp.c is for generic case, and should be made as generic at the beginning... Current this is only hard coding, I think provide some kind of mapping would be good. Best regards, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
Le 01/12/2010 22:39, Albert ARIBAUD a écrit : This one is a conundrum. Using 2010q1, building omap3_evm causes a linker warning arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003e8f0 overlaps previous sections while building omap3_beagle does not cause any linker warning. Both boards use the same armv7 u-boot.lds and have a .bss which is way bigger than the .rel.dyn plus .dynsym sections that it does overlay. IOW, they have a similar layout for .rel.dyn, .dynsym and .bss, but one gets the warning and one does not. The one difference a readelf shows is that for beagle, there is only one segment: 00 .text .rodata .hash .data .got.plt .u_boot_cmd .rel.dyn .dynsym While for evm there is 00 .text .rodata .hash .data .got.plt .u_boot_cmd .rel.dyn .bss 01 .dynsym Note that .bss has appeared in segment 00 for evm, whereas it was absent for beagle, and that .dynsym was rejected to a second segment -- why? I don't know. Note: I've tried with putting input sections .rel.dyn and .dynsym into a single output section .rel.dyn: this makes the second segment disappear, but for evm the warning remains and .bss remains in the segment. I have a tiny clue. Starting with the fact that the linker issue is only for one board, omap3_evm, I looked up the board-specific code. First thing that I noticed was static u8 omap3_evm_version; I changed this to static u8 omap3_evm_version = 1; so that the static was moved out of BSS and the linker warning disappeared (reminder: v2010.12-rc2, omap3_evm, arm-2010q1). Now this is not the first static BSS variable we use in U-Boot, and the others did not cause linker warnings (not *all* the others, at least), so the real cause is yet unknown to me. But that's at least a lead we can follow. If this BSS variable is used before relocation (I haven't checked this), then anyway it'll have to move; in that case I'll keep an eye on this linker warning and try to sort it out if I get time. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/7] [REPOST-1] gpio: Add Multi-Function-Pin configuration driver for Marvell SoCs
-Original Message- From: Lei Wen [mailto:adrian.w...@gmail.com] Sent: Thursday, December 02, 2010 12:29 PM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; Eric Miao; Manas Saksena; Lei Wen; Yu Tang; Ashish Karkare; Kiran Vedere; Prabhanjan Sarnaik Subject: Re: [U-Boot] [PATCH v3 3/7] [REPOST-1] gpio: Add Multi-Function- Pin configuration driver for Marvell SoCs Hi Prafulla, On Thu, Dec 2, 2010 at 2:54 PM, Prafulla Wadaskar prafu...@marvell.com wrote: -Original Message- From: Lei Wen [mailto:adrian.w...@gmail.com] Sent: Wednesday, December 01, 2010 7:51 PM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; Eric Miao; Manas Saksena; Lei Wen; Yu Tang; Ashish Karkare; Kiran Vedere; Prabhanjan Sarnaik Subject: Re: [U-Boot] [PATCH v3 3/7] [REPOST-1] gpio: Add Multi- Function- Pin configuration driver for Marvell SoCs Hi Prafulla, ...snip... + + /* the offset address are divided in three regions and not + * consecutive, this corrects the same (Ref: Specs: A1.1) */ + p_mfpr = (u32 *)MFPR_BASE; + if ( mfpr_no 37) + p_mfpr += (0x004c / 4) + mfpr_no; + else if ( mfpr_no = 56) + p_mfpr += (0x00e0 / 4) + (mfpr_no - 56); + else + p_mfpr += (mfpr_no - 37); This three regions is only meaningful for armada100, so when we use the mfp.c to other cpu, like pxa920, how could we reuse this setting? Obviously, pxa920 is different with armada100 regions arrangement, with the start mfp of ND_IO[15]. Currently mfp is added for armada100, I don't know what will be diffs with other SoCs. When other SoC will come up, we will modify this file :-) Since the mfp.c is for generic case, and should be made as generic at the beginning... Sure.. but I don't know how it will be on other SoCs? Apart from that what would be other impact? So in my opinion, let's keep it for future updates. With reference to your precise concern, I will create a macro in asm/arch/mfp.h moving below code there. + if ( mfpr_no 37) + p_mfpr += (0x004c / 4) + mfpr_no; + else if ( mfpr_no = 56) + p_mfpr += (0x00e0 / 4) + (mfpr_no - 56); + else + p_mfpr += (mfpr_no - 37) This will help to isolate it as SoC specific implementation, I will post REPOST-2 for the same Thanks and Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-boot networking not working
Hi, I've got an sbc6000x from www.armkits.com. I've been working through how to put debian onto this board and was making some progress (im just a beginner), but now I dont have network access when at the U-boot prompt. The Board is connected to the network as the link light is on on the interface. As soon as I try to ping the board itself ie ping 192.192.192.200 (the default ip address) the link light goes out. this is from the command line U-Boot ping 192.192.192.200 dm9000 i/o: 0x3000, id: 0x9a46 DM9000: running in 16 bit mode MAC: de:ad:be:ef:01:01 operating at 100M full duplex mode ping failed; host 192.192.192.200 is not alive now if I go ahead and boot the board i can ping once im in the linux root file system that is currently on the board (I've changed the IP address on bootup in the linux image.) ~ $ ping 192.168.0.21 PING 192.168.0.21 (192.168.0.21): 56 data bytes 64 bytes from 192.168.0.21: icmp_seq=0 ttl=64 time=0.5 ms 64 bytes from 192.168.0.21: icmp_seq=1 ttl=64 time=0.3 ms 64 bytes from 192.168.0.21: icmp_seq=2 ttl=64 time=0.3 ms is there a setting in u-boot that could mean that the network is turned off? following are the environment variables of u-boot U-Boot printenv bootcmd=nand read 0x2200 0x1A 0x20; bootm 0x2200 bootdelay=3 baudrate=115200 ethaddr=DE:AD:BE:EF:01:01 ipaddr=192.192.192.200 serverip=192.192.192.105 gatewayip=192.192.192.101 netmask=255.255.255.0 splashimage=0x2100 bootlogo=0 lcdtype=480x272 bootargs=console=ttyS0,115200 tft=480x272 root=/dev/mtdblock6 mtdparts=at91_nand:128k(bootstrap)ro,256k(uboot)ro,128k(env1)ro,128k(env2)ro,1M(logo)ro,2M(linux),-(root) rw rootfstype=yaffs2 Environment size: 455/131067 bytes im using u-boot 1.3.4. Any help with this would be great! Regards Mark ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ulong type size?
Dear Jason Liu, In message aanlktikded9zrxvem6rtgtgxtgcvl-j0b6sez5scd...@mail.gmail.com you wrote: I have one problem when support more than 4GB NAND flash in u-boot. I found that there used ulong type in common/cmd_nand.c, but it turned out that ulong is 32bit in my build environment, the gcc version is as the following? Does anyone meet the same problem? I expected that someone hits this barrier sooner or later. Seems some code-rework is needed. Patches welcome. 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 Misquotation is, in fact, the pride and privilege of the learned. A widely-read man never quotes accurately, for the rather obvious reason that he has read too widely. - Hesketh Pearson _Common Misquotations_ introduction ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
Dear Albert ARIBAUD, In message 4cf743e6.60...@free.fr you wrote: Starting with the fact that the linker issue is only for one board, omap3_evm, I looked up the board-specific code. First thing that I noticed was static u8 omap3_evm_version; I changed this to static u8 omap3_evm_version = 1; so that the static was moved out of BSS and the linker warning disappeared (reminder: v2010.12-rc2, omap3_evm, arm-2010q1). Now this is not the first static BSS variable we use in U-Boot, and the others did not cause linker warnings (not *all* the others, at least), so the real cause is yet unknown to me. But that's at least a lead we can follow. Write access is only in omap3_evm_get_revision() which in turn only gets called in misc_init_r(), i. e. after relocation. Read access is only in get_omap3_evm_rev() [which is not called outside this file and thus should be made static!] which gets called only in omap3_evm_need_extvbus() which gets acalled only in musb_platform_init(), i. e. during USB init. This should be safe. You could try out what happens if you make get_omap3_evm_rev() static... 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 Without followers, evil cannot spread. -- Spock, And The Children Shall Lead, stardate 5029.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot networking not working
Dear Mark Underwood, In message 1291273748.31320.3.ca...@bertha you wrote: I've got an sbc6000x from www.armkits.com. I've been working through how to put debian onto this board and was making some progress (im just a beginner), but now I dont have network access when at the U-boot prompt. The Board is connected to the network as the link light is on on the interface. As soon as I try to ping the board itself ie ping 192.192.192.200 (the default ip address) the link light goes out. this is from the command line Well, I guess you did not read the FAQ... U-Boot printenv bootcmd=nand read 0x2200 0x1A 0x20; bootm 0x2200 bootdelay=3 baudrate=115200 ethaddr=DE:AD:BE:EF:01:01 Ouch. See FAQ 14.2.13. Ethernet Does Not Work See also 14.2.14. Where Can I Get a Valid MAC Address from? 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 What if is a trademark of Hewlett Packard, so stop using it in your sentences without permission, or risk being sued. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
Hi Wolfgang, Le 02/12/2010 08:34, Wolfgang Denk a écrit : Dear Albert ARIBAUD, In message4cf743e6.60...@free.fr you wrote: Starting with the fact that the linker issue is only for one board, omap3_evm, I looked up the board-specific code. First thing that I noticed was static u8 omap3_evm_version; I changed this to static u8 omap3_evm_version = 1; so that the static was moved out of BSS and the linker warning disappeared (reminder: v2010.12-rc2, omap3_evm, arm-2010q1). Now this is not the first static BSS variable we use in U-Boot, and the others did not cause linker warnings (not *all* the others, at least), so the real cause is yet unknown to me. But that's at least a lead we can follow. Write access is only in omap3_evm_get_revision() which in turn only gets called in misc_init_r(), i. e. after relocation. Read access is only in get_omap3_evm_rev() [which is not called outside this file and thus should be made static!] which gets called only in omap3_evm_need_extvbus() which gets acalled only in musb_platform_init(), i. e. during USB init. This should be safe. Alright. You could try out what happens if you make get_omap3_evm_rev() static... No change: the warning remains, and so do the two segments. Maybe I should subscribe the binutils list and ask there. Meanwhile, this variable could be initialized to some safe value such as OMAP3EVM_BOARD_UNKNOWN. BTW... Why on Earth is it an uint8? Probably a space saving measure, but one I think is not really fruitful, because of probable paddings and alignments; making it an int would allow using smsc_id directly as values for the OMAP3EVM_BOARD_GEN_1 and OMAP3EVM_BOARD_GEN_2... ... plus it removes the linker warning! I thus suggest turning omap3_evm_version from uint8 to int and get on with debugging the board. Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
