Re: [U-Boot-Users] [patch 0/6] DM9000: Several fixes/cleanups for the DM9000A controller
Remy Bohmer wrote: > In a few minutes I will post a patch which I hope it will solve this. > Can you please try it on your board? I have tried, the old error is gone, but the board hangs probably after getting the first packets: $ tftp 0xa001 u-boot.bin dm9000 i/o: 0x800, id: 0x9a46 DM9000: running in 32 bit mode MAC: 00:50:c2:3b:8f:0a operating at 100M full duplex mode TFTP from server 192.168.2.14; our IP address is 192.168.2.77 Filename 'u-boot.bin'. Load address: 0xa001 Loading:* Enabling the debug I get this output (so the first packet was received): $ tftp 0xa001 u-boot.bin eth_halt phy_write(reg:0x0, value:0x8000) eth_init() resetting DM9000 resetting the DM9000, 1st reset resetting the DM9000, 2nd reset dm9000 i/o: 0x800, id: 0x9a46 DM9000: running in 32 bit mode phy_read(0x3): 0x0 MAC: 00:50:c2:3b:8f:0a 00:50:c2:3b:8f:0a: phy_read(0x1): 0x7809 phy_read(0x1): 0x7809 phy_read(0x1): 0x7809 phy_read(0x1): 0x7809 phy_read(0x1): 0x7809 phy_read(0x1): 0x7809 [snip] phy_read(0x1): 0x780d phy_read(0x1): 0x780d phy_read(0x1): 0x780d phy_read(0x1): 0x780d [snip] phy_read(0x1): 0x780d phy_read(0x1): 0x782d phy_read(0x11): 0x8018 operating at 100M full duplex mode TFTP from server 192.168.2.14; our IP address is 192.168.2.77 Filename 'u-boot.bin'. Load address: 0xa001 Loading: eth_send: length: 42 eth_send: 00: ff ff ff ff ff ff 00 50 eth_send: 08: c2 3b 8f 0a 08 06 00 01 eth_send: 10: 08 00 06 04 00 01 00 50 eth_send: 18: c2 3b 8f 0a c0 a8 02 4d eth_send: 20: 00 00 00 00 00 00 c0 a8 eth_send: 28: 02 0e transmit done receiving packet rx status: 0x0001 rx len: 64 eth_rx: length: 64 eth_rx: 00: 01 00 40 00 00 50 c2 3b eth_rx: 08: 8f 0a 00 0b 2b 12 e3 3c eth_rx: 10: 08 06 00 01 08 00 06 04 eth_rx: 18: 00 02 00 0b 2b 12 e3 3c eth_rx: 20: c0 a8 02 0e 00 50 c2 3b eth_rx: 28: 8f 0a c0 a8 02 4d 00 00 eth_rx: 30: 00 00 00 00 00 00 00 00 eth_rx: 38: 00 00 00 00 00 00 00 00 passing packet to upper layer receiving packet rx status: 0x806d rx len: 24529 ^^^ ^--> wrong Stefano -- = 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: [EMAIL PROTECTED] = - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] 83xx SPD_EEPROM DDR2 Issues
Guys, I think I have found a reason / partial fix, after getting some parameters tweaked and pimping out the debug routine to printf() almost the entire SPD table here is what I found. 1) The SPD tables for DDR1 and DDR2 are dfferent by about 10-15%. We'll need to add a separate SPD struct to fully make this elegant, for now I think enough of it is similar to gut shoot a quick fix. i.e. byte 23, 24, 25 etc have different meanings. 2) Some DIMMs are supporting 50-Ohm ODT termination, however some newer DIMMs have disabled this feature. The spd->dev_attr holds the actual value, 0x03 is with ODT 50Ohm and 0x01 is without. The 0x01 is for weak drivers. Right now the code doesn't deal with anything on the dev_attr field. Turning on 2T timing seems to correct for this problem. So the real question begins, what happens now?? Impedance can be worked around by excessively slowing the memory bus to compensate for the noise made by unmatched impedance. However, it would be nice to make this match, and actually use what we pay for. I know Freescale has some bits in the 83xx that deal with ODT and Impedance on the drivers. We'll need to add code to handle this, but more importantly I need to find what it means if the 50-Ohm ODT is not there in the DIMM, and how we compensate. 3) Lastly the cheap, but global fix to have the SPD code work for all newer memory types is to modify the picos_to_clks() function. I added a simple "#ifdef CFG_DDR2_LOOSE_TIMING" option that simply adds one extra clk++; This made all the PC4200 and PC5300 RAM I had work. None of these is the 'correct' fix, but if somebody wants the code I'll be happy to post. I will be working with Freescale to find info on the ODT-50-ohm problem and possible other solutions. -Russ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 5:34 PM To: [EMAIL PROTECTED] Cc: 'David Hawkins'; 'Steve Hensley'; u-boot-users@lists.sourceforge.net Subject: RE: [U-Boot-Users] 83xx SPD_EEPROM DDR2 Issues "Russell McGuire" <[EMAIL PROTECTED]> wrote on 06/03/2008 04:15:55 PM: > > I haven't gone through the rest yet, but most likely if we want to keep SPD > working for DDR2, we'll have to add the DDR2 definitions SPD into the code, > as it looks like the DDR2 port is only partially complete. > > -Russ > Russ, That's pretty much jives with my recollection. One other thing that leaps to mind was the calculation for max_bus_clk. I hand cranked through that with a high clock rate as input and due to rounding errors got a bogus value. I don't remember the details right off the top of my head but it seems to me that the net result was I started with a bus clock that should have landed max_data_rate in one of those if-if-else-if cases, but it didn't. So I think that whole function (and especially the max_bus_clk calculation) needs to be gone through. Good luck. I'd help but I have my own issues with MTD :(. Bruce - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [Patch 16/17 Try 2] U-Boot-V2:ARM:OMAP3:SDP3430 Addsupport for SDP3430 board file
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Menon, Nishanth
> Sent: Wednesday, May 21, 2008 11:31 AM
> To: Sascha Hauer
> Cc: u-boot-users@lists.sourceforge.net; Kamat, Nishant; Syed Mohammed,
> Khasim; Laurent Desnogues;
> [EMAIL PROTECTED]
> Subject: [U-Boot-Users] [Patch 16/17] U-Boot-V2:ARM:OMAP3:SDP3430 Addsupport
> for SDP3430 board file
>
> This patch introduces support for SDP3430 board file.
Retry due to change in serial port mechanism.
Signed-off-by: Nishanth Menon<[EMAIL PROTECTED]>
---
board/omap/board-sdp343x.c | 680 +
board/omap/board-sdp343x.h | 33 ++
2 files changed, 713 insertions(+)
Index: u-boot.v2/board/omap/board-sdp343x.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ u-boot.v2/board/omap/board-sdp343x.c2008-06-03 23:05:53.0
-0500
@@ -0,0 +1,680 @@
+/**
+ * @file
+ * @brief SDP3430 Specific Board Initialization routines
+ *
+ * FileName: board/omap/board-sdp343x.c
+ *
+ * SDP3430 from Texas Instruments as described here:
+ * http://www.ti.com/omap3430_devplatform
+ * This file provides initialization in two stages:
+ * @li boot time initialization - do basics required to get SDRAM working.
+ * This is run from SRAM - so no case constructs and global vars can be used.
+ * @li run time initialization - this is for the rest of the initializations
+ * such as flash, uart etc.
+ *
+ * Boot time initialization includes:
+ * @li SDRAM initialization.
+ * @li Pin Muxing relevant for SDP3430.
+ *
+ * Run time initialization includes
+ * @li serial @ref serial_ns16550.c driver device definition
+ *
+ * Originally from
http://linux.omap.com/pub/bootloader/3430sdp/u-boot-v1.tar.gz
+ */
+/*
+ * (C) Copyright 2006-2008
+ * Texas Instruments,
+ * Nishanth Menon <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "board-sdp343x.h"
+
+/ Board Boot Time ***/
+static void sdrc_init(void);
+static void mux_config(void);
+
+/**
+ * @brief The basic entry point for board initialization.
+ *
+ * This is called as part of machine init (after arch init).
+ * This is again called with stack in SRAM, so not too many
+ * constructs possible here.
+ *
+ * @return void
+ */
+void board_init(void)
+{
+ int in_sdram = running_in_sdram();
+ mux_config();
+ if (!in_sdram)
+ sdrc_init();
+}
+
+/**
+ * @brief Do the SDRC initialization for 128Meg Infenion DDR for CS0
+ *
+ * @return void
+ */
+static void sdrc_init(void)
+{
+ /* issues software reset of SDRAM interface */
+ /* No idle ack and RESET enable */
+ __raw_writel(0x0A, SDRC_REG(SYSCONFIG));
+ sdelay(100);
+ /* No idle ack and RESET disable */
+ __raw_writel(0x08, SDRC_REG(SYSCONFIG));
+
+ /* SDRC Sharing register */
+ /* 32-bit SDRAM on data lane [31:0] - CS0 */
+ /* pin tri-stated = 1 */
+ __raw_writel(0x0100, SDRC_REG(SHARING));
+
+ /* - SDRC_REG(CS0 Configuration - */
+ /* SDRC_REG(MCFG0 register */
+ __raw_writel(0x02D04011, SDRC_REG(MCFG_0));
+
+ /* SDRC_REG(RFR_CTRL0 register */
+ __raw_writel(0x0003DE01, SDRC_REG(RFR_CTRL_0));
+
+ /* SDRC_REG(ACTIM_CTRLA0 register */
+ __raw_writel(0X5A9A4486, SDRC_REG(ACTIM_CTRLA_0));
+
+ /* SDRC_REG(ACTIM_CTRLB0 register */
+ __raw_writel(0x0010, SDRC_REG(ACTIM_CTRLB_0));
+
+ /* Disble Power Down of CKE cuz of 1 CKE on combo part */
+ __raw_writel(0x0081, SDRC_REG(POWER));
+
+ /* SDRC_REG(Manual command register */
+ /* NOP command */
+ __raw_writel(0x, SDRC_REG(MANUAL_0));
+ /* Precharge command */
+ __raw_writel(0x0001, SDRC_REG(MANUAL_0));
+ /* Auto-refresh command */
+ __raw_writel(0x0002, SDRC_REG(MANUAL_0));
+ /* Auto-refresh command */
+ __raw_writel(0x0002, SDRC_REG(MANUAL_0));
+
+ /* SDRC MR0 register */
+ __raw_writel(0x0032, SDRC_REG(MR_0)); /* Burst length =4 */
+
+
[U-Boot-Users] [Patch 15/17 Try 2] U-Boot-V2:ARM:OMAP3:SDP3430: Addsupport for SDP3430 support files
Sascha, > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Menon, Nishanth > Sent: Wednesday, May 21, 2008 11:31 AM > To: Sascha Hauer > Cc: u-boot-users@lists.sourceforge.net; Kamat, Nishant; Syed Mohammed, > Khasim; Laurent Desnogues; > [EMAIL PROTECTED] > Subject: [U-Boot-Users] [Patch 15/17] U-Boot-V2:ARM:OMAP3:SDP3430: Addsupport > for SDP3430 support > files > > This patch introduces support for infrastructure required for SDP3430. > Resync due to previous comments Signed-off-by: Nishanth Menon<[EMAIL PROTECTED]> --- arch/arm/configs/omap3430_sdp3430_per_uart_defconfig | 184 +++ arch/arm/mach-omap/Kconfig | 38 +++ board/omap/Kconfig | 54 + board/omap/Makefile | 25 ++ board/omap/config.h | 38 +++ board/omap/env/bin/init |1 board/omap/platform.S| 65 ++ 7 files changed, 397 insertions(+), 8 deletions(-) Index: u-boot.v2/arch/arm/configs/omap3430_sdp3430_per_uart_defconfig === --- /dev/null 1970-01-01 00:00:00.0 + +++ u-boot.v2/arch/arm/configs/omap3430_sdp3430_per_uart_defconfig 2008-06-03 22:27:55.0 -0500 @@ -0,0 +1,184 @@ +# +# Automatically generated make config: don't edit +# U-Boot version: 2.0.0-rc5-git +# Tue Jun 3 22:08:48 2008 +# +CONFIG_ARCH_TEXT_BASE=0x80e8 +CONFIG_BOARDINFO="Texas Instrument's SDP343x" +# CONFIG_BOARD_LINKER_SCRIPT is not set +CONFIG_GENERIC_LINKER_SCRIPT=y +CONFIG_ARM=y +CONFIG_ARMCORTEXA8=y +CONFIG_ARCH_OMAP=y +# CONFIG_MACH_MX1ADS is not set +# CONFIG_MACH_SCB9328 is not set +# CONFIG_MACH_PCM038 is not set +# CONFIG_MACH_IMX27ADS is not set +# CONFIG_MACH_ECO920 is not set +# CONFIG_MACH_NXDB500 is not set +# CONFIG_MACH_PCM037 is not set +CONFIG_MACH_OMAP=y + +# +# OMAP Features +# +CONFIG_ARCH_OMAP3=y +CONFIG_OMAP_CONFIG_STACKSIZE=0x8000 +CONFIG_OMAP_MALLOC_LEN=0x8000 +CONFIG_OMAP_CLOCK_ALL=y +CONFIG_OMAP_CLOCK_SOURCE_S32K=y +CONFIG_OMAP3_CLOCK_CONFIG=y +# CONFIG_OMAP3_COPY_CLOCK_SRAM is not set + +# +# OMAP Platform Features +# +CONFIG_MACH_OMAP343xSDP=y +# CONFIG_MACH_OMAP_ADVANCED_MUX is not set + +# +# Arm specific settings +# +# CONFIG_CMDLINE_TAG is not set +# CONFIG_SETUP_MEMORY_TAGS is not set +# CONFIG_INITRD_TAG is not set +# CONFIG_ARMCORTEXA8_DCACHE_SKIP is not set +CONFIG_HAS_KALLSYMS=y +CONFIG_HAS_MODULES=y +# CONFIG_CMD_MEMORY is not set + +# +# General Settings +# + +# +# memory layout +# +CONFIG_HAVE_CONFIGURABLE_TEXT_BASE=y +CONFIG_TEXT_BASE=0x4020 +CONFIG_HAVE_CONFIGURABLE_MALLOC=y +# CONFIG_MALLOC_BASE_DEFAULT is not set +CONFIG_MALLOC_BASE_FIXED=y +CONFIG_MALLOC_BASE=0x87FFFC00 +CONFIG_MALLOC_SIZE=0x40 +CONFIG_BROKEN=y +# CONFIG_EXPERIMENTAL is not set +# CONFIG_KALLSYMS is not set +CONFIG_MACH_HAS_LOWLEVEL_INIT=y +CONFIG_MACH_DO_LOWLEVEL_INIT=y +CONFIG_ARCH_HAS_LOWLEVEL_INIT=y +CONFIG_PROMPT="X-load 343x> " +CONFIG_BAUDRATE=115200 +# CONFIG_CMDLINE_EDITING is not set +CONFIG_SIMPLE_READLINE=y +CONFIG_LONGHELP=y +CONFIG_CBSIZE=1024 +CONFIG_MAXARGS=16 +# CONFIG_SHELL_HUSH is not set +CONFIG_SHELL_SIMPLE=y +# CONFIG_ERRNO_MESSAGES is not set +# CONFIG_TIMESTAMP is not set +CONFIG_CONSOLE_ACTIVATE_FIRST=y +# CONFIG_OF_FLAT_TREE is not set +# CONFIG_PARTITION is not set +# CONFIG_DEFAULT_ENVIRONMENT is not set + +# +# Debugging +# +CONFIG_DEBUG_INFO=y +# CONFIG_ENABLE_FLASH_NOISE is not set +# CONFIG_ENABLE_PARTITION_NOISE is not set +# CONFIG_ENABLE_DEVICE_NOISE is not set + +# +# Commands +# + +# +# scripting +# +# CONFIG_CMD_EDIT is not set +# CONFIG_CMD_EXEC is not set +# CONFIG_CMD_SLEEP is not set +# CONFIG_CMD_SAVEENV is not set +# CONFIG_CMD_LOADENV is not set +# CONFIG_CMD_EXPORT is not set +# CONFIG_CMD_PRINTENV is not set +# CONFIG_CMD_HELP is not set +# CONFIG_CMD_READLINE is not set + +# +# file commands +# +# CONFIG_CMD_LS is not set +# CONFIG_CMD_RM is not set +# CONFIG_CMD_CAT is not set +# CONFIG_CMD_MKDIR is not set +# CONFIG_CMD_RMDIR is not set +# CONFIG_CMD_CP is not set +# CONFIG_CMD_PWD is not set +# CONFIG_CMD_CD is not set +# CONFIG_CMD_MOUNT is not set +# CONFIG_CMD_UMOUNT is not set + +# +# console +# +# CONFIG_CMD_CLEAR is not set +# CONFIG_CMD_ECHO is not set +# CONFIG_CMD_SPLASH is not set + +# +# memory +# +CONFIG_CMD_LOADB=y +# CONFIG_CMD_LOADS is not set +# CONFIG_CMD_MEMINFO is not set +# CONFIG_CMD_CRC is not set +# CONFIG_CMD_MTEST is not set + +# +# flash +# +# CONFIG_CMD_FLASH is not set + +# +# booting +# +# CONFIG_CMD_BOOTM is not set +# CONFIG_CMD_RESET is not set +CONFIG_CMD_GO=y +# CONFIG_CMD_TIMEOUT is not set +# CONFIG_CMD_PARTITION is not set +# CONFIG_NET is not set + +# +# Drivers +# + +# +# serial drivers +# +CONFIG_DRIVER_SERIAL_NS16550=y +CONFIG_DRIVER_SERIAL_NS16550_OMAP_EXTENSIONS=y + +# +# SPI drivers +# +# CO
[U-Boot-Users] [Patch 13/17 Try 2] U-Boot-V2:ARM:OMAP3: Add generic Headers
Sascha, > -Original Message- > From: Sascha Hauer [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 03, 2008 3:27 AM > To: Menon, Nishanth > Cc: u-boot-users@lists.sourceforge.net; Laurent Desnogues; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; Gopinath, Thara; Kamat, Nishant; Syed Mohammed, Khasim > Subject: Re: [Patch 13/17] U-Boot-V2:ARM:OMAP3: Add generic Headers > > > Index: u-boot-v2.git/include/asm-arm/arch-omap/bits.h > > === > > +#define BIT30 (1<<30) > > +#define BIT31 (1<<31) > > Please don't do this. It does not really make the code shorter and every > programmer understands hwat 1<<0 means + he does not have to search > through header files for the definition of BIT0. Try 2 of the patch with bits.h removed and related cleanups. Signed-off-by: Nishanth Menon<[EMAIL PROTECTED]> --- include/asm-arm/arch-omap/control.h | 98 ++ include/asm-arm/arch-omap/gpmc.h | 105 include/asm-arm/arch-omap/intc.h | 58 + include/asm-arm/arch-omap/omap3-silicon.h | 130 ++ include/asm-arm/arch-omap/omap3-smx.h | 69 +++ include/asm-arm/arch-omap/sdrc.h | 97 ++ include/asm-arm/arch-omap/silicon.h | 36 include/asm-arm/arch-omap/sys_info.h | 97 ++ include/asm-arm/arch-omap/syslib.h| 43 + include/asm-arm/arch-omap/timers.h| 60 + include/asm-arm/arch-omap/wdt.h | 49 +++ 11 files changed, 842 insertions(+) Index: u-boot.v2/include/asm-arm/arch-omap/control.h === --- /dev/null 1970-01-01 00:00:00.0 + +++ u-boot.v2/include/asm-arm/arch-omap/control.h 2008-06-03 21:20:09.0 -0500 @@ -0,0 +1,98 @@ +/** + * @file + * @brief This file contains the Control register defines + * + * FileName: include/asm-arm/arch-omap/control.h + * + * Originally from Linux kernel: + * http://linux.omap.com/pub/kernel/3430zoom/linux-ldp-v1.0b.tar.gz + * include/asm-arm/arch-omap/omap34xx.h + */ +/* + * (C) Copyright 2008 + * Texas Instruments, + * Nishanth Menon <[EMAIL PROTECTED]> + * + * Copyright (C) 2007 Texas Instruments, + * Copyright (C) 2007 Nokia Corporation. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#ifndef __ASM_ARCH_OMAP_CONTROL_H +#define __ASM_ARCH_OMAP_CONTROL_H + +/** + * Control register defintion which unwraps to the real register + * offset + base address + */ +#define CONTROL_REG(REGNAME) (OMAP_CTRL_BASE + CONTROL_##REGNAME) + +#define CONTROL_SCALABLE_OMAP_STATUS(0x44C) +#define CONTROL_SCALABLE_OMAP_OCP (0x534) +#define CONTROL_SCRATCHPAD_BASE(0x910) +#define CONTROL_SCRATCHPAD_ROM_BASE(0x860) +#define CONTROL_STATUS (0x2f0) +#define CONTROL_SYSCONFIG (0x010) +#define CONTROL_DEVCONF0 (0x274) +#define CONTROL_DEVCONF1 (0x2D8) +#define CONTROL_IVA2_BOOTMOD (0x404) +#define CONTROL_IVA2_BOOTADDR (0x400) +#define CONTROL_PBIAS_1(0x520) +#define CONTROL_GENERAL_PURPOSE_STATUS (0x2F4) +#define CONTROL_MEM_DFTRW0 (0x278) +#define CONTROL_MEM_DFTRW1 (0x27C) +#define CONTROL_MSUSPENDMUX_0 (0x290) +#define CONTROL_MSUSPENDMUX_1 (0x294) +#define CONTROL_MSUSPENDMUX_2 (0x298) +#define CONTROL_MSUSPENDMUX_3 (0x29C) +#define CONTROL_MSUSPENDMUX_4 (0x2A0) +#define CONTROL_MSUSPENDMUX_5 (0x2A4) +#define CONTROL_SEC_CTRL (0x2B0) +#define CONTROL_CSIRXFE(0x2DC) +#define CONTROL_DEBOBS_0 (0x420) +#define CONTROL_DEBOBS_1 (0x424) +#define CONTROL_DEBOBS_2 (0x428) +#define CONTROL_DEBOBS_3 (0x42C) +#define CONTROL_DEBOBS_4 (0x430) +#define CONTROL_DEBOBS_5 (0x434) +#define CONTROL_DEBOBS_6 (0x438) +#define CONTROL_DEBOBS_7 (0x43C) +#define CONTROL_DEBOBS_8 (0x440) +#define CONTROL_PROG_IO0 (0x444) +#define CONTROL_PROG_IO1 (
[U-Boot-Users] [Patch 11/17 Try 3] U-Boot-V2:ARM:OMAP3: Add support forOMAP3Silicon files
Sascha, > -Original Message- > From: Sascha Hauer [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 03, 2008 12:49 PM > To: Menon, Nishanth > Cc: Peter Pearse; u-boot-users@lists.sourceforge.net; Kamat, Nishant; Syed > Mohammed, Khasim; Laurent > Desnogues; [EMAIL PROTECTED] > Subject: Re: [Patch 11/17 Try 2] U-Boot-V2:ARM:OMAP3: Add support > forOMAP3Silicon files > > On Tue, Jun 03, 2008 at 10:36:05AM -0500, Menon, Nishanth wrote: > > Sascha, > > > -Original Message- > > > From: Sascha Hauer [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, June 03, 2008 3:18 AM > > > To: Menon, Nishanth > > > Cc: Peter Pearse; u-boot-users@lists.sourceforge.net; Kamat, Nishant; > > > Syed Mohammed, Khasim; > Laurent > > > Desnogues; [EMAIL PROTECTED] > > > Subject: Re: [Patch 11/17 Try 2] U-Boot-V2:ARM:OMAP3: Add support for > > > OMAP3Silicon files > > > > > > On Wed, May 28, 2008 at 10:39:07AM -0500, Menon, Nishanth wrote: > > > > As per the thread in: > > > > http://www.nabble.com/-Patch-06-17--U-Boot-V2%3AARM%3A-Add-sizes.h-tt17372780.html#a17372780 > > > > sizes.h dependency is removed from the following patch. This is a > > > > resubmission. > > > > > > > > This patch introduces support for OMAP3430 - provides for generic OMAP3 > > > > files. > > > > > > Looks ok to me besides the occurences of return with the value in > > > brackets. > > > > > > Sascha > > Arrgh.. I have myself to blame for inconsistent return styles. Probably we > > need an equivalent of > checkpatch and a Lindent for U-Boot v2? I suppose the right style is return > without brackets? > > Yes it is, but that's somewhere on the boarder to nitpicking, don't know > which side though ;) With the cleanups :(. Signed-off-by: Nishanth Menon<[EMAIL PROTECTED]> --- arch/arm/mach-omap/Kconfig | 65 + arch/arm/mach-omap/Makefile| 25 ++ arch/arm/mach-omap/omap3_core.S| 101 arch/arm/mach-omap/omap3_generic.c | 450 + arch/arm/mach-omap/syslib.c| 97 +++ 5 files changed, 738 insertions(+) Index: u-boot.v2/arch/arm/mach-omap/Kconfig === --- /dev/null 1970-01-01 00:00:00.0 + +++ u-boot.v2/arch/arm/mach-omap/Kconfig2008-06-03 22:47:24.0 -0500 @@ -0,0 +1,65 @@ +# +# OMAP Architecture specific features +# +# (C) Copyright 2008 +# Texas Instruments, +# Nishanth Menon <[EMAIL PROTECTED]> +# +# 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 + +menu "OMAP Features" + depends on ARCH_OMAP + +choice + prompt "Select OMAP Variant" + +config ARCH_OMAP3 + bool "OMAP3" + select ARMCORTEXA8 + select ARCH_HAS_LOWLEVEL_INIT + help + Say Y here if you are using Texas Instrument's OMAP343x based platform + +endchoice + +config OMAP_CONFIG_STACKSIZE + prompt "STACKSIZE" + hex + default 0x0002 + help + Select the Stack Size + +config OMAP_MALLOC_LEN + prompt "MALLOC LENGTH" + hex + default 0x1000 + help + Select the Malloc Length + +config ARCH_TEXT_BASE + prompt "ARCH TEXT BASE" + hex + default 0x80e8 + help + Select the load address + +config OMAP3_CLOCK_CONFIG + depends on ARCH_OMAP + bool "Clock Configuration" + help + Say Y here if you like to have OMAP3 Clock configuration done. + +endmenu Index: u-boot.v2/arch/arm/mach-omap/Makefile === --- /dev/null 1970-01-01 00:00:00.0 + +++ u-boot.v2/arch/arm/mach-omap/Makefile 2008-06-03 22:47:24.0 -0500 @@ -0,0 +1,25 @@ +# OMAP Architecture Makefile +# +# (C) Copyright 2008 +# Texas Instruments, +# Nishanth Menon <[EMAIL PROTECTED]> +# +# 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 f
[U-Boot-Users] [Patch 12/17 Try 2] U-Boot-V2:ARM:OMAP3: Add support forOMAP3 Silicon files
Sascha,
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Menon, Nishanth
> Sent: Wednesday, May 21, 2008 11:30 AM
> To: Sascha Hauer
> Cc: u-boot-users@lists.sourceforge.net; Kamat, Nishant; Syed Mohammed,
> Khasim; Laurent Desnogues;
> [EMAIL PROTECTED]
> Subject: [U-Boot-Users] [Patch 12/17] U-Boot-V2:ARM:OMAP3: Add support
> forOMAP3 Silicon files
>
> This patch introduces support for OMAP3430 clocking infrastructure. Please
> note that SRAM based
> configuration requires GPMC values to be updated before returning to caller-
> TBD.
>
Cleanup with BIT defines and return style corrected.
Signed-off-by: Nishanth Menon<[EMAIL PROTECTED]>
---
arch/arm/mach-omap/omap3_clock.c| 379
arch/arm/mach-omap/omap3_clock_core.S | 312 ++
arch/arm/mach-omap/s32k_clksource.c | 80 ++
include/asm-arm/arch-omap/clocks.h | 48
include/asm-arm/arch-omap/omap3-clock.h | 124 ++
5 files changed, 943 insertions(+)
Index: u-boot.v2/arch/arm/mach-omap/omap3_clock.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ u-boot.v2/arch/arm/mach-omap/omap3_clock.c 2008-06-03 22:53:19.0
-0500
@@ -0,0 +1,379 @@
+/**
+ * @file
+ * @brief OMAP DPLL and various clock configuration
+ *
+ * FileName: arch/arm/mach-omap/omap3_clock.c
+ *
+ * @ref prcm_init This is the second level clock init for PRCM as defined in
+ * clocks.h -- called from SRAM, or Flash (using temp SRAM stack).
+ *
+ * During reconfiguring the clocks while in SDRAM/Flash, we can have invalid
+ * clock configuration to which ARM instruction/data fetch ops can fail.
+ * This critical path is handled by relocating the relevant functions in
+ * omap3_clock_core.S to OMAP's ISRAM and executing it there.
+ *
+ * @warning: IMPORTANT: These functions run from ISRAM stack, so no bss
sections
+ * should be used: functions cannot use global variables/switch constructs.
+ *
+ * Originally from
http://linux.omap.com/pub/bootloader/3430sdp/u-boot-v1.tar.gz
+ */
+/*
+ * (C) Copyright 2006-2008
+ * Texas Instruments,
+ * Richard Woodruff <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Following functions are exported from omap3_clock_core.S */
+#ifdef CONFIG_OMAP3_COPY_CLOCK_SRAM
+/* A.K.A go_to_speed */
+static void (*f_lock_pll) (u32, u32, u32, u32);
+#endif
+/* Helper functions */
+static u32 get_osc_clk_speed(void);
+static void get_sys_clkin_sel(u32 osc_clk, u32 *sys_clkin_sel);
+static void per_clocks_enable(void);
+
+/**
+ * @brief Determine reference oscillator speed
+ *
+ * This is based on known 32kHz clock and gptimer.
+ *
+ * @return clock speed S38_4M, S26M S24M S19_2M S13M S12M
+ */
+static u32 get_osc_clk_speed(void)
+{
+ u32 start, cstart, cend, cdiff, val;
+
+ val = __raw_readl(PRM_REG(CLKSRC_CTRL));
+ /* If SYS_CLK is being divided by 2, remove for now */
+ val = (val & (~(0x1 << 7))) | (0x1 << 6);
+ __raw_writel(val, PRM_REG(CLKSRC_CTRL));
+
+ /* enable timer2 */
+ val = __raw_readl(CM_REG(CLKSEL_WKUP)) | (0x1 << 0);
+ __raw_writel(val, CM_REG(CLKSEL_WKUP)); /* select sys_clk for GPT1 */
+
+ /* Enable I and F Clocks for GPT1 */
+ val = __raw_readl(CM_REG(ICLKEN_WKUP)) | (0x1 << 0) | (0x1 << 2);
+ __raw_writel(val, CM_REG(ICLKEN_WKUP));
+ val = __raw_readl(CM_REG(FCLKEN_WKUP)) | (0x1 << 0);
+ __raw_writel(val, CM_REG(FCLKEN_WKUP));
+ /* start counting at 0 */
+ __raw_writel(0, OMAP_GPTIMER1_BASE + TLDR);
+ /* enable clock */
+ __raw_writel(GPT_EN, OMAP_GPTIMER1_BASE + TCLR);
+ /* enable 32kHz source - enabled out of reset */
+ /* determine sys_clk via gauging */
+
+ start = 20 + __raw_readl(S32K_CR); /* start time in 20 cycles */
+ while (__raw_readl(S32K_CR) < start) ; /* dead loop till start time */
+ /* get start sys_clk count */
+ cstart = __raw_readl(OMAP_GPTIMER1_BASE + TCRR);
+ while (__raw_readl(S32K_CR) < (start + 20)) ; /* wait for 40 cycles */
+ /* get end sys_clk count */
+ cend = __
[U-Boot-Users] [Patch 10/17 Try 2] U-Boot-V2:ARM:OMAP3: Add support for OMAP and Cortex A8
Sascha, > -Original Message- > From: Menon, Nishanth > Sent: Tuesday, June 03, 2008 10:38 AM > To: 'Laurent Desnogues'; u-boot-users@lists.sourceforge.net; [EMAIL > PROTECTED]; > [EMAIL PROTECTED]; Gopinath, Thara; Kamat, Nishant; Syed Mohammed, Khasim > Subject: RE: [Patch 10/17] U-Boot-V2:ARM:OMAP3: Add support for OMAP and > Cortex A8 > > > -Original Message- > > From: Laurent Desnogues [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, June 03, 2008 3:23 AM > > To: Menon, Nishanth; u-boot-users@lists.sourceforge.net; Laurent Desnogues; > > [EMAIL PROTECTED]; [EMAIL PROTECTED]; Gopinath, Thara; Kamat, Nishant; Syed > > Subject: Re: [Patch 10/17] U-Boot-V2:ARM:OMAP3: Add support for OMAP and > > Cortex A8 > > > > On Tue, Jun 3, 2008 at 10:12 AM, Sascha Hauer <[EMAIL PROTECTED]> wrote: > > > Is this really ARMCORTEX specific or arm v7 specific? > > > > This is not Cortex A8 specific, it's v7-A (and hopefully will be the same > > in upcoming ARM architectures). > Probably ARM arch definitions need to be cleaned up a bit more? Granularity > is restricted today to > ARM CPU and not architecture.. > > > > > > Anyway, this looks > > > like the start of another ifdef mess, we should create some generic hook > > > here. > > > > You could perhaps mimic the way the Linux kernel handles cache stuff > > for the various ARM architectures. > Probably not the extent.. but yes to a lesser extent might be helpful. Common > code will still exist, > probably CP15 stuff can move out? Keeping the current code, but resyncing based on MALLOC changes. Need clean up of ARM proc specific changes pretty soon I guess. ARMV4, V6, V7 support to be independent of common code. Signed-off-by: Nishanth Menon<[EMAIL PROTECTED]> --- arch/arm/Kconfig | 23 +++- arch/arm/Makefile|6 + arch/arm/cpu/Makefile|1 arch/arm/cpu/start-arm.S | 54 +++ 4 files changed, 83 insertions(+), 1 deletion(-) Index: u-boot.v2/arch/arm/Kconfig === --- u-boot.v2.orig/arch/arm/Kconfig 2008-06-03 20:27:47.0 -0500 +++ u-boot.v2/arch/arm/Kconfig 2008-06-03 20:45:08.0 -0500 @@ -47,6 +47,9 @@ config ARM926EJS bool +config ARMCORTEXA8 + bool + # i.MX1, i.MXL, i.MX27 and i.MX31 are quite similar and thus # handled in one arch config ARCH_IMX @@ -74,6 +77,10 @@ bool select ARM926EJS +config ARCH_OMAP + bool +# ARM versions used varies on based on OMAP versions + choice prompt "Select your board" @@ -135,6 +142,12 @@ Say Y here if your are using Phytec's phyCORE-i.MX31 (pcm037) equipped with a Freescale i.MX31 Processor +config MACH_OMAP + bool "Texas Instruments' OMAP based platforms" + select ARCH_OMAP + help + Say Y if you are using Texas Instrument's OMAP based platforms + endchoice config IMX_CLKO @@ -144,8 +157,9 @@ The i.MX SoCs have a Pin which can output different reference frequencies. Say y here if you want to have the clko command which lets you select the frequency to output on this pin. - + source arch/arm/mach-netx/Kconfig +source arch/arm/mach-omap/Kconfig menu "Arm specific settings " @@ -168,6 +182,13 @@ If you want to start a 2.6 kernel and use an initrd image say y here. +config ARMCORTEXA8_DCACHE_SKIP + bool "Skip DCache Invlidate" + depends on ARMCORTEXA8 + default n + help + If your architecture configuration uses some other method of disabling caches, enable this + So that the D-Cache invalidation logic is skipped endmenu source common/Kconfig Index: u-boot.v2/arch/arm/Makefile === --- u-boot.v2.orig/arch/arm/Makefile2008-06-03 20:28:20.0 -0500 +++ u-boot.v2/arch/arm/Makefile 2008-06-03 20:42:53.0 -0500 @@ -5,6 +5,7 @@ machine-$(CONFIG_ARCH_IMX):= imx machine-$(CONFIG_ARCH_NETX) := netx machine-$(CONFIG_ARCH_AT91RM9200) := at91rm9200 +machine-$(CONFIG_ARCH_OMAP):= omap board-$(CONFIG_MACH_MX1ADS) := mx1ads board-$(CONFIG_MACH_ECO920) := eco920 board-$(CONFIG_MACH_SCB9328) := scb9328 @@ -12,6 +13,7 @@ board-$(CONFIG_MACH_IMX27ADS) := imx27ads board-$(CONFIG_MACH_NXDB500) := netx board-$(CONFIG_MACH_PCM037) := pcm037 +board-$(CONFIG_MACH_OMAP) := omap # FIXME "cpu-y" never used on ARM! cpu-$(CONFIG_ARM920T) := arm920t cpu-$(CONFIG_ARM926EJS):= arm926ejs @@ -70,6 +72,10 @@ PHONY += maketools maketools: include/asm-arm/.arch +# Add architecture specific flags +ifeq ($(CONFIG_ARMCORTEXA8),y) +CPPFLAGS += -march=armv7a +endif ifneq ($(board-y),) BOARD := board/$(board-y)/ Index: u-boot.v2/arch/arm/cpu/Makefile =
[U-Boot-Users] [Patch 09/17 Try 2] U-Boot-V2:Serial: Add support for NS16550 Driver
Sascha,
> -Original Message-
> From: Sascha Hauer [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 03, 2008 12:47 PM
> To: Menon, Nishanth
> Cc: u-boot-users@lists.sourceforge.net; Laurent Desnogues; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; Gopinath, Thara; Kamat, Nishant; Syed Mohammed, Khasim
> Subject: Re: [Patch 09/17] U-Boot-V2:Serial: Add support for NS16550Driver.`
>
> What I meant is that you should put the access functions itself into
> platform_data, not a description of their register size / padding.
> That way each board can decide which funky access functions it needs, be
> it that the 16550 is connected via SPI, memory io or whatever.
Try 2 of the patch.
Signed-off-by: Nishanth Menon<[EMAIL PROTECTED]>
---
drivers/serial/Kconfig | 13 ++
drivers/serial/Makefile |1
drivers/serial/serial_ns16550.c | 252
drivers/serial/serial_ns16550.h | 98 +++
include/ns16550.h | 55
5 files changed, 419 insertions(+)
Index: u-boot.v2/drivers/serial/Kconfig
===
--- u-boot.v2.orig/drivers/serial/Kconfig 2008-06-03 22:42:07.0
-0500
+++ u-boot.v2/drivers/serial/Kconfig2008-06-03 22:46:07.0 -0500
@@ -24,4 +24,17 @@
depends on BLACKFIN
default y
bool "Blackfin serial driver"
+
+config DRIVER_SERIAL_NS16550
+ default n
+ bool "NS16550 serial driver"
+ help
+ Enable this to get support for NS16550 based serial devices
+
+config DRIVER_SERIAL_NS16550_OMAP_EXTENSIONS
+ bool "OMAP Extensions for NS16550"
+ depends on DRIVER_SERIAL_NS16550
+ depends on ARCH_OMAP
+ help
+ Say Y here if you are using OMAP extensions to NS16550
endmenu
Index: u-boot.v2/drivers/serial/Makefile
===
--- u-boot.v2.orig/drivers/serial/Makefile 2008-06-03 22:42:06.0
-0500
+++ u-boot.v2/drivers/serial/Makefile 2008-06-03 22:46:07.0 -0500
@@ -10,3 +10,4 @@
obj-$(CONFIG_DRIVER_SERIAL_LINUX_COMSOLE) += linux_console.o
obj-$(CONFIG_DRIVER_SERIAL_MPC5XXX)+= serial_mpc5xxx.o
obj-$(CONFIG_DRIVER_SERIAL_BLACKFIN) += serial_blackfin.o
+obj-$(CONFIG_DRIVER_SERIAL_NS16550)+= serial_ns16550.o
Index: u-boot.v2/drivers/serial/serial_ns16550.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ u-boot.v2/drivers/serial/serial_ns16550.c 2008-06-03 22:46:32.0
-0500
@@ -0,0 +1,252 @@
+/**
+ * @file
+ * @brief NS16550 Driver implementation
+ *
+ * FileName: drivers/serial/serial_ns16550.c
+ *
+ * NS16550 support
+ * Modified from U-Boot V1 drivers/serial.c and drivers/ns16550.c
+ * originally from linux source (arch/ppc/boot/ns16550.c)
+ * modified to use CFG_ISA_MEM and new defines
+ */
+/*
+ * (C) Copyright 2008
+ * Texas Instruments,
+ * Nishanth Menon <[EMAIL PROTECTED]>
+ *
+ * (C) Copyright 2000
+ * Rob Taylor, Flying Pig Systems. [EMAIL PROTECTED]
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "serial_ns16550.h"
+#include
+
+/*** Private Functions **/
+
+/**
+ * @brief ns16550_calc_divisor - compute the divisor for a baud rate
+ *
+ * @param[in] cdev - pointer to console device
+ * @param[in] baudrate - baud rate
+ *
+ * @return divisor to be set
+ */
+static unsigned int ns16550_calc_divisor(struct console_device *cdev,
+unsigned int baudrate)
+{
+ struct NS16550_plat *plat = (struct NS16550_plat *)
+ cdev->dev->platform_data;
+ unsigned int clk = plat->clock;
+#ifdef CONFIG_DRIVER_SERIAL_NS16550_OMAP_EXTENSIONS
+ /* FIXME: Legacy Code copied from U-Boot V1 implementation
+*/
+#ifdef CONFIG_ARCH_OMAP1510
+ unsigned long base = cdev->dev->map_base;
+ /* If can't cleanly clock 115200 set div to 1 */
+ if ((clk == 1200) && (baudrate == 115200)) {
+ /* enable 6.5 * divisor */
+
[U-Boot-Users] [Patch 05/17 Try 2] U-Boot-V2:ARM: Introduce capability tohavedifferent stack/malloc area
Sascha,
> -Original Message-
> From: Sascha Hauer [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 03, 2008 10:24 AM
> To: Menon, Nishanth
> Cc: u-boot-users@lists.sourceforge.net; Laurent Desnogues; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; Gopinath, Thara; Kamat, Nishant; Syed Mohammed, Khasim
> Subject: Re: [Patch 05/17] U-Boot-V2:ARM: Introduce capability
> tohavedifferent stack/malloc area
>
> > Instead of modifying this for one architecture I would prefer something
> > like this (currently no implementation, only kconfig).
> > Would this solve your issues?
Modification only done for ARM.
Signed-off-by: Nishanth Menon<[EMAIL PROTECTED]>
---
arch/arm/cpu/start-arm.S | 27 +++-
arch/arm/lib/arm.c | 16 ++--
common/Kconfig | 61 +++
3 files changed, 100 insertions(+), 4 deletions(-)
Index: u-boot.v2/arch/arm/lib/arm.c
===
--- u-boot.v2.orig/arch/arm/lib/arm.c 2008-06-03 20:56:27.0 -0500
+++ u-boot.v2/arch/arm/lib/arm.c2008-06-03 20:56:46.0 -0500
@@ -4,10 +4,22 @@
#include
#include
+#ifdef CONFIG_MALLOC_BASE
+#define ARM_MALLOC_START CONFIG_MALLOC_BASE
+#else
+#define ARM_MALLOC_START _u_boot_start
+#endif
+
+#ifdef CONFIG_MALLOC_SIZE
+#define ARM_MALLOC_SIZE CONFIG_MALLOC_SIZE
+#else
+#define ARM_MALLOC_SIZE CFG_MALLOC_LEN
+#endif
+
int arm_mem_malloc_init(void)
{
- mem_malloc_init((void *)(_u_boot_start - CFG_MALLOC_LEN),
- (void *)_u_boot_start);
+ mem_malloc_init((void *)(ARM_MALLOC_START - ARM_MALLOC_SIZE),
+ (void *)ARM_MALLOC_START);
return 0;
}
Index: u-boot.v2/arch/arm/cpu/start-arm.S
===
--- u-boot.v2.orig/arch/arm/cpu/start-arm.S 2008-06-03 20:56:40.0
-0500
+++ u-boot.v2/arch/arm/cpu/start-arm.S 2008-06-03 21:08:04.0 -0500
@@ -90,11 +90,34 @@
* FIXME
*/
+#ifdef CONFIG_MALLOC_BASE
+#define ARM_MALLOC_START CONFIG_MALLOC_BASE
+#else
+#define ARM_MALLOC_START _start
+#endif
+
+#ifdef CONFIG_MALLOC_SIZE
+#define ARM_MALLOC_SIZE CONFIG_MALLOC_SIZE
+#else
+#define ARM_MALLOC_SIZE CFG_MALLOC_LEN
+#endif
_MALLOC_START:
- .word _start - CFG_MALLOC_LEN
+ .word ARM_MALLOC_START - ARM_MALLOC_SIZE
+#ifdef CONFIG_STACK_BASE
+#define ARM_STACK_START CONFIG_STACK_BASE
+#else
+#define ARM_STACK_START (ARM_MALLOC_START - ARM_MALLOC_SIZE)
+#endif
+
+#ifdef CONFIG_STACK_SIZE
+#define ARM_STACK_SIZE CONFIG_STACK_SIZE
+#else
+#define ARM_STACK_SIZE CFG_STACK_LEN
+#endif
_STACK_START:
- .word _start - CFG_MALLOC_LEN - CONFIG_STACKSIZE
+ .word ARM_STACK_START - CONFIG_STACKSIZE
+
/*
* These are defined in the board-specific linker script.
Index: u-boot.v2/common/Kconfig
===
--- u-boot.v2.orig/common/Kconfig 2008-06-03 20:56:40.0 -0500
+++ u-boot.v2/common/Kconfig2008-06-03 21:08:37.0 -0500
@@ -19,13 +19,74 @@
config BOARDINFO
string
+menu "memory layout "
+
+config HAVE_CONFIGURABLE_TEXT_BASE
+ bool
+
config TEXT_BASE
+ depends on HAVE_CONFIGURABLE_TEXT_BASE
prompt "TEXT_BASE"
hex
default ARCH_TEXT_BASE
help
The Address U-Boot gets linked at.
+config HAVE_CONFIGURABLE_STACK
+ bool
+choice
+ prompt "select stack base policy"
+ depends on HAVE_CONFIGURABLE_STACK
+ default STACK_BASE_FIXED
+
+config STACK_BASE_DEFAULT
+ bool "place stack before malloc space"
+
+config STACK_BASE_FIXED
+ bool "manually assign a stack base"
+
+endchoice
+
+config STACK_BASE
+ depends on STACK_BASE_FIXED
+ hex
+ prompt "STACK_BASE"
+
+config STACK_SIZE
+ hex
+ depends on HAVE_CONFIGURABLE_STACK
+ default 0x8000
+ prompt "Stack size"
+
+config HAVE_CONFIGURABLE_MALLOC
+ bool
+
+choice
+ prompt "select malloc base policy"
+ depends on HAVE_CONFIGURABLE_MALLOC
+
+config MALLOC_BASE_DEFAULT
+ bool
+ prompt "place malloc before U-Boot"
+
+config MALLOC_BASE_FIXED
+ bool
+ prompt "manually assign a malloc base"
+
+endchoice
+
+config MALLOC_BASE
+ depends on MALLOC_BASE_FIXED
+ hex
+ prompt "MALLOC_BASE"
+
+config MALLOC_SIZE
+ hex
+ depends on HAVE_CONFIGURABLE_MALLOC
+ default 0x40
+ prompt "malloc area size"
+endmenu
+
config BROKEN
bool
prompt "Prompt for broken or incomplete code"
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
[U-Boot-Users] [Patch 04/17 Try 2] U-Boot-V2:ARM: Remove unwanted flags from Makefile
Sascha, Makefiles were updated in last couple of days. Retrying with further fixes for sparse to work: CFLAGS: "-D __ARM__" should have been "-D__ARM__". Further -nostdinc in Makefile is redfined by commit ID:847934bc960ba1588c87e283118318dfdd78d4c0 This is unnecessary as NOSTDINC_FLAGS in root Makefile defines it Signed-off-by: Nishanth Menon<[EMAIL PROTECTED]> --- Makefile |3 +-- arch/arm/Makefile |2 +- 2 files changed, 2 insertions(+), 3 deletions(-) Index: u-boot.v2/arch/arm/Makefile === --- u-boot.v2.orig/arch/arm/Makefile2008-06-03 20:19:34.0 -0500 +++ u-boot.v2/arch/arm/Makefile 2008-06-03 20:19:50.0 -0500 @@ -1,5 +1,5 @@ -CPPFLAGS += -D __ARM__ -fno-strict-aliasing +CPPFLAGS += -D__ARM__ -fno-strict-aliasing machine-$(CONFIG_ARCH_IMX):= imx Index: u-boot.v2/Makefile === --- u-boot.v2.orig/Makefile 2008-06-03 20:19:27.0 -0500 +++ u-boot.v2/Makefile 2008-06-03 20:20:17.0 -0500 @@ -305,8 +305,7 @@ $(if $(KBUILD_SRC),-Iinclude2 -I$(srctree)/include) \ -include include/linux/autoconf.h -CPPFLAGS:= -D__KERNEL__ -D__U_BOOT__ $(LINUXINCLUDE) -fno-builtin -ffreestanding \ - -nostdinc +CPPFLAGS:= -D__KERNEL__ -D__U_BOOT__ $(LINUXINCLUDE) -fno-builtin -ffreestanding CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \ -fno-strict-aliasing -fno-common -Os -pipe - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] Question About how the CPU find the right string address in U-boot binary file ?
Dear all,
I study the U-boot.bin file using the objdump command, I don't know how the
CPU can find the right string address when puts() string.
For example, In my binary file, the string "Call backtrace: " in func
"print_backtrace()" address is :0x0002b280, the func address is
0xfff03564, How the CPU can find the 0x0002b280 when call puts ("Call
backtrace: "); ? I find the SMC serial driver
"serial_putc()" but cannot know how to find the char address in binary
file.
Below is the objdump result, can anyone explain to me ? thanks!
(PowerPC platform)
void print_backtrace(unsigned long *sp)
{
int cnt = 0;
unsigned long i;
puts ("Call backtrace: ");
while (sp) {
if ((uint)sp > END_OF_MEM)
break;
i = sp[1];
if (cnt++ % 7 == 0)
putc ('\n');
printf("%08lX ", i);
if (cnt > 32) break;
sp = (unsigned long *)*sp;
}
putc ('\n');
}
void show_regs(struct pt_regs * regs)
{
int i;
printf("NIP: %08lX XER: %08lX LR: %08lX REGS: %p TRAP: %04lx DAR: %08lX\n",
regs->nip, regs->xer, regs->link, regs, regs->trap, regs->dar);
printf("MSR: %08lx EE: %01x PR: %01x FP: %01x ME: %01x IR/DR: %01x%01x\n",
regs->msr, regs->msr&MSR_EE ? 1 : 0, regs->msr&MSR_PR ? 1 : 0,
regs->msr & MSR_FP ? 1 : 0,regs->msr&MSR_ME ? 1 : 0,
regs->msr&MSR_IR ? 1 : 0,
regs->msr&MSR_DR ? 1 : 0);
putc ('\n');
for (i = 0; i < 32; i++) {
if ((i % 8) == 0) {
printf("GPR%02d: ", i);
}
printf("%08lX ", regs->gpr[i]);
if ((i % 8) == 7) {
putc ('\n');
}
}
}
void puts (const char *s)
{
DECLARE_GLOBAL_DATA_PTR;
#ifdef CONFIG_SILENT_CONSOLE
if (gd->flags & GD_FLG_SILENT)
return;
#endif
if (gd->flags & GD_FLG_DEVINIT) {
/* Send to the standard output */
fputs (stdout, s);
} else {
/* Send directly to the handler */
serial_puts (s);
}
}
void serial_putc(const char c)
{
volatile cbd_t *tbdf;
volatile char *buf;
volatile smc_uart_t *up;
volatile immap_t *im = (immap_t *)CFG_IMMR;
if (c == '\n')
serial_putc ('\r');
up = (smc_uart_t *)&(im->im_dprambase[PROFF_SMC]);
tbdf = (cbd_t *)&im->im_dprambase[up->smc_tbase];
/* Wait for last character to go.
*/
buf = (char *)tbdf->cbd_bufaddr;
while (tbdf->cbd_sc & BD_SC_READY)
;
*buf = c;
tbdf->cbd_datlen = 1;
tbdf->cbd_sc |= BD_SC_READY;
}
hex code in u-boot.bin
string:
0002b280h: 43 61 6C 6C 20 62 61 63 6B 74 72 61 63 65 3A 20 ; Call backtrace:
0002b290h: 00 00 00 00 25 30 38 6C 58 20 00 00 4E 49 50 3A ; %08lX
..NIP:
0002b2a0h: 20 25 30 38 6C 58 20 58 45 52 3A 20 25 30 38 6C ; %08lX XER: %08l
0002b2b0h: 58 20 4C 52 3A 20 25 30 38 6C 58 20 52 45 47 53 ; X LR: %08lX
REGS
0002b2c0h: 3A 20 25 70 20 54 52 41 50 3A 20 25 30 34 6C 78 ; : %p TRAP:
%04lx
0002b2d0h: 20 44 41 52 3A 20 25 30 38 6C 58 0A 00 00 00 00 ; DAR: %08lX.
0002b2e0h: 4D 53 52 3A 20 25 30 38 6C 78 20 45 45 3A 20 25 ; MSR: %08lx EE:
%
0002b2f0h: 30 31 78 20 50 52 3A 20 25 30 31 78 20 46 50 3A ; 01x PR: %01x
FP:
0002b300h: 20 25 30 31 78 20 4D 45 3A 20 25 30 31 78 20 49 ; %01x ME: %01x I
0002b310h: 52 2F 44 52 3A 20 25 30 31 78 25 30 31 78 0A 00 ; R/DR:
%01x%01x..
0002b320h: 47 50 52 25 30 32 64 3A ; GPR%02d:
hex code in u-boot.bin
func:
print_backtrace()
3584h: 94 21 FF D8 7C 08 02 A6 42 9F 00 05 BF 61 00 14 ;
?Ø|..¦B?.¿a..
3594h: 7F C8 02 A6 90 01 00 2C 80 1E FF F0 7C 7C 1B 78 ;
?¦..,€.ð||.x
35a4h: 3B E0 00 00 7F C0 F2 14 80 7E 80 00 48 01 1B AD ;
;?.Àò.€~€.H..?
35b4h: 2C 1C 00 00 41 82 00 70 3C 00 02 00 7C 1C 00 40 ; ,...A?p<...|..@
35c4h: 3D 20 92 49 61 29 24 93 7F EB FE 70 38 60 00 0A ; = 'Ia)$?ëþp8`..
35d4h: 41 81 00 54 7C 1F 48 96 83 7C 00 04 7C 00 FA 14 ; A?T|.H–ƒ|..|.?
35e4h: 7C 00 16 70 7C 0B 00 50 1C 00 00 07 7C 00 F8 50 ;
|..p|..P|.øP
35f4h: 2C 00 00 00 3B FF 00 01 40 A2 00 08 48 01 1B 21 ;
,...;[EMAIL PROTECTED]
3604h: 80 7E 80 04 7F 64 DB 78 4C C6 31 82 48 01 1B 89 ;
€~€.dÛxL?‚H..?
3614h: 2C 1F 00 20 41 81 00 10 83 9C 00 00 2C 1C 00 00 ; ,.. A?.ƒœ..,...
3624h: 40 82 FF 98 38 60 00 0A 48 01 1A F5 BB 61 00 14 ; @??`..H..õ»a..
3634h: 80 01 00 2C 38 21 00 28 7C 08 03 A6 4E 80 00 20 ;
€..,8!.(|..¦N€.
3644h: 00 03 89 F0 ; ..‰ð
show_regs()
3648h: 94 21 FF E8 7C 08 02 A6 42 9F 00 05 BF 81 00 08 ;
?è|..¦B?.¿..
3658h: 7F C8 02 A6 90 01 00 1C 80 1E FF F0 7C 7F 1B 78 ;
?¦...€.ð|.x
3668h: 80 9F 00 80 7F E7 FB 78 7F C0 F2 14 80 BF 00 94 ;
€?€çûxÀò.€??
3678h: 80 7E 80 08 3B 80 00 00 80 DF 00 90 81 1F 00 A0 ;
€~€.;€..€?..?
3688h: 81 3F 00 A4 4C C6 31 82 48 01 1B 09 80 9F 00 84 ;
?.¤L?‚H...€??
3698h: 80 7E 80 0C 54 85 8F FE 54 86 97 FE 54 87 9F FE ;
€~€.T…†—‡Ÿ?
36a8h: 54 88 A7 FE 54 89 DF FE 54 8A E7 FE 4C C6 31 82 ;
Tˆ§‰ßŠçþL??
36b8h: 48 01 1A E1 38 60 00 0A 48 01 1A 61 73 80 00 07 ;
H..?`..H..as€..
36c8h: 7F 84 E3 78 40 A2 00 10 80 7E 80 10 4C C6 31 82 ; „ãx@
?.€~€.L??
36d8h: 48 01 1A C1 57 80 10 3A 80 7E 80 04 7C 9F 00 2E ;
H..ÁW€.:€~€.|?.
36e8h: 4C C6 31 82 48 01 1A AD 38 60 00 0A 7F 80 1E 70 ;
L?‚H..?`..€.p
36f8h: 7C 00 01 94 54 0
Re: [U-Boot-Users] [PATCH] 85xx: Add setting of cache props in the device tree.
On Jun 3, 2008, at 7:35 PM, Andy Fleming wrote:
> On Thu, May 29, 2008 at 11:22 AM, Kumar Gala <[EMAIL PROTECTED]
> > wrote:
>> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
>> ---
>> cpu/mpc85xx/fdt.c | 128 +++
>> ++
>> 1 files changed, 128 insertions(+), 0 deletions(-)
>>
>> diff --git a/cpu/mpc85xx/fdt.c b/cpu/mpc85xx/fdt.c
>> index bb87740..92952e6 100644
>> --- a/cpu/mpc85xx/fdt.c
>> +++ b/cpu/mpc85xx/fdt.c
>> @@ -26,6 +26,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> extern void ft_qe_setup(void *blob);
>> #ifdef CONFIG_MP
>> @@ -77,6 +78,131 @@ void ft_fixup_cpu(void *blob, u64 memory_limit)
>> }
>> #endif
>>
>> +#ifdef CONFIG_L2_CACHE
>> +/* return size in kilobytes */
>> +static inline u32 l2cache_size(void)
>> +{
>> + volatile ccsr_l2cache_t *l2cache = (void
>> *)CFG_MPC85xx_L2_ADDR;
>> + volatile u32 l2siz_field = (l2cache->l2ctl >> 28) & 0x3;
>> + u32 ver = SVR_SOC_VER(get_svr());
>> +
>> + switch (l2siz_field) {
>> + case 0x0:
>> + break;
>> + case 0x1:
>> + if (ver == SVR_8540 || ver == SVR_8560 ||
>> + ver == SVR_8541 || ver == SVR_8541_E ||
>> + ver == SVR_8555 || ver == SVR_8555_E)
>> + return 128;
>> + else
>> + return 256;
>> + break;
>> + case 0x2:
>> + if (ver == SVR_8540 || ver == SVR_8560 ||
>> + ver == SVR_8541 || ver == SVR_8541_E ||
>> + ver == SVR_8555 || ver == SVR_8555_E)
>> + return 256;
>> + else
>> + return 512;
>> + break;
>> + case 0x3:
>> + return 1024;
>> + break;
>> + }
>> +
>> + return 0;
>> +}
>
> How about we create a feature in the new cpu_type field you created,
> and use that to flag it. :)
Seems overkill for such a small difference and one that is just for
the "e500v1" generation of 85xx chips.
- k
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] Pull request: (optional) for u-boot-fdt repository
Dear Wolfgang, I've removed CONFIG_OF_FLAT_TREE as a cleanup. It would be nice to get it into the 1.34 release, but it can wait for 1.35 if anybody is uncomfortable with this. Since it is enabled on only two boards, it doesn't affect most boards either way. Best regards, gvb The following changes since commit 1f1554841a4c8e069d331176f0c3059fb2bb8280: Wolfgang Denk (1): Merge branch 'master' of /home/wd/git/u-boot/custodians are available in the git repository at: git://git.denx.de/u-boot-fdt.git master Gerald Van Baren (3): Convert mpc7448hpc2 to CONFIG_OF_LIBFDT Change the stxxst to CONFIG_OF_LIBFDT Remove the deprecated CONFIG_OF_FLAT_TREE README|9 +- board/freescale/mpc7448hpc2/mpc7448hpc2.c | 21 +- board/tqm8272/tqm8272.c |4 - common/Makefile |1 - common/ft_build.c | 471 - cpu/74xx_7xx/cpu.c| 35 +-- drivers/pci/tsi108_pci.c | 33 ++- include/configs/mpc7448hpc2.h |3 +- include/configs/stxxtc.h |4 +- include/ft_build.h| 71 - 10 files changed, 42 insertions(+), 610 deletions(-) delete mode 100644 common/ft_build.c delete mode 100644 include/ft_build.h - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 1/3 (v2)] Convert mpc7448hpc2 to CONFIG_OF_LIBFDT
This was configured to use the deprecated CONFIG_OF_FLAT_TREE, change
to CONFIG_OF_LIBFDT.
WARNING: This conversion is untested because I do not have a board to
test it on.
NOTE: The FDT blob (DTS) must have an /aliases/ethernet0 and (optionally)
/aliases/ethernet1 property for the ethernet to work.
Signed-off-by: Gerald Van Baren <[EMAIL PROTECTED]>
---
board/freescale/mpc7448hpc2/mpc7448hpc2.c |9 +++
cpu/74xx_7xx/cpu.c| 35
drivers/pci/tsi108_pci.c | 33 +++---
include/configs/mpc7448hpc2.h |2 +-
4 files changed, 44 insertions(+), 35 deletions(-)
diff --git a/board/freescale/mpc7448hpc2/mpc7448hpc2.c
b/board/freescale/mpc7448hpc2/mpc7448hpc2.c
index 81846eb..fcbebc0 100644
--- a/board/freescale/mpc7448hpc2/mpc7448hpc2.c
+++ b/board/freescale/mpc7448hpc2/mpc7448hpc2.c
@@ -105,3 +105,12 @@ ft_board_setup (void *blob, bd_t *bd)
}
}
#endif
+
+#if defined(CONFIG_OF_BOARD_SETUP)
+void
+ft_board_setup(void *blob, bd_t *bd)
+{
+ ft_cpu_setup(blob, bd);
+ fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
+}
+#endif
diff --git a/cpu/74xx_7xx/cpu.c b/cpu/74xx_7xx/cpu.c
index 9c8998b..a6e3426 100644
--- a/cpu/74xx_7xx/cpu.c
+++ b/cpu/74xx_7xx/cpu.c
@@ -44,6 +44,11 @@
#include <74xx_7xx.h>
#include
+#if defined(CONFIG_OF_LIBFDT)
+#include
+#include
+#endif
+
#if defined(CONFIG_OF_FLAT_TREE)
#include
#endif
@@ -301,29 +306,19 @@ watchdog_reset(void)
/* - */
-#ifdef CONFIG_OF_FLAT_TREE
-void
-ft_cpu_setup (void *blob, bd_t *bd)
+#ifdef CONFIG_OF_LIBFDT
+void ft_cpu_setup(void *blob, bd_t *bd)
{
- u32 *p;
- ulong clock;
- int len;
-
- clock = bd->bi_busfreq;
+ do_fixup_by_prop_u32(blob, "device_type", "cpu", 4,
+"timebase-frequency", bd->bi_busfreq / 4, 1);
+ do_fixup_by_prop_u32(blob, "device_type", "cpu", 4,
+"bus-frequency", bd->bi_busfreq, 1);
+ do_fixup_by_prop_u32(blob, "device_type", "cpu", 4,
+"clock-frequency", bd->bi_intfreq, 1);
- p = ft_get_prop (blob, "/cpus/" OF_CPU "/bus-frequency", &len);
- if (p != NULL)
- *p = cpu_to_be32 (clock);
+ fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
-#if defined(CONFIG_TSI108_ETH)
- p = ft_get_prop (blob, "/" OF_TSI "/[EMAIL PROTECTED]/address", &len);
- memcpy (p, bd->bi_enetaddr, 6);
-#endif
-
-#if defined(CONFIG_HAS_ETH1)
- p = ft_get_prop (blob, "/" OF_TSI "/[EMAIL PROTECTED]/address", &len);
- memcpy (p, bd->bi_enet1addr, 6);
-#endif
+ fdt_fixup_ethernet(blob, bd);
}
#endif
/* - */
diff --git a/drivers/pci/tsi108_pci.c b/drivers/pci/tsi108_pci.c
index d5f11e4..4f02cb8 100644
--- a/drivers/pci/tsi108_pci.c
+++ b/drivers/pci/tsi108_pci.c
@@ -33,8 +33,9 @@
#include
#include
#include
-#ifdef CONFIG_OF_FLAT_TREE
-#include
+#if defined(CONFIG_OF_LIBFDT)
+#include
+#include
#endif
struct pci_controller local_hose;
@@ -162,20 +163,24 @@ void pci_init_board (void)
return;
}
-#ifdef CONFIG_OF_FLAT_TREE
-void
-ft_pci_setup (void *blob, bd_t *bd)
+#if defined(CONFIG_OF_LIBFDT)
+void ft_pci_setup(void *blob, bd_t *bd)
{
- u32 *p;
- int len;
-
- p = (u32 *)ft_get_prop (blob, "/" OF_TSI "/[EMAIL
PROTECTED]/bus-range", &len);
- if (p != NULL) {
- p[0] = local_hose.first_busno;
- p[1] = local_hose.last_busno;
+ int nodeoffset;
+ int tmp[2];
+ const char *path;
+
+ nodeoffset = fdt_path_offset(blob, "/aliases");
+ if (nodeoffset >= 0) {
+ path = fdt_getprop(blob, nodeoffset, "pci", NULL);
+ if (path) {
+ tmp[0] = cpu_to_be32(local_hose.first_busno);
+ tmp[1] = cpu_to_be32(local_hose.last_busno);
+ do_fixup_by_path(blob, path, "bus-range",
+ &tmp, sizeof(tmp), 1);
+ }
}
-
}
-#endif
+#endif /* CONFIG_OF_LIBFDT */
#endif /* CONFIG_TSI108_PCI */
diff --git a/include/configs/mpc7448hpc2.h b/include/configs/mpc7448hpc2.h
index f614e67..c01d0a5 100644
--- a/include/configs/mpc7448hpc2.h
+++ b/include/configs/mpc7448hpc2.h
@@ -75,7 +75,7 @@
#define CFG_PROMPT_HUSH_PS2"> "
/* Pass open firmware flat tree */
-#define CONFIG_OF_FLAT_TREE1
+#define CONFIG_OF_LIBFDT 1
#define CONFIG_OF_BOARD_SETUP 1
#define OF_CPU "PowerPC,[EMAIL PROTECTED]"
--
1.5.5.1
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://
[U-Boot-Users] [PATCH 0/3 (v2)] Remove the deprecated CONFIG_OF_FLAT_TREE
The following troika of patches switch the final two boards (mpc7448hpc2 and stxxst) from using CONFIG_OF_FLAT_TREE to CONFIG_OF_LIBFDT and then remove support for CONFIG_OF_FLAT_TREE. Since I don't have access to the boards I could not test them. If someone can test the conversions and provide patches, I would appreciate it. For the stxxtc board, I don't see how it uses CONFIG_OF_* at all, leading me to believe that the FDT support for that board has bit-rotted away already. Again, patches are welcome. Best regards, gvb - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 2/3 (v2)] Change the stxxst to CONFIG_OF_LIBFDT
This was configured to use the deprecated CONFIG_OF_FLAT_TREE, change to CONFIG_OF_LIBFDT. WARNING: It appears that this board lost its ability to boot via a flattened device tree prior to this changeset. WARNING: This conversion was untested because I do not have a board to test it on. Signed-off-by: Gerald Van Baren <[EMAIL PROTECTED]> --- include/configs/stxxtc.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/configs/stxxtc.h b/include/configs/stxxtc.h index 97a1032..fcafba5 100644 --- a/include/configs/stxxtc.h +++ b/include/configs/stxxtc.h @@ -590,8 +590,8 @@ typedef unsigned int led_id_t; /*/ -/* pass open firmware flat tree */ -#define CONFIG_OF_FLAT_TREE1 +/* pass open firmware flattened device tree */ +#define CONFIG_OF_LIBFDT 1 #define OF_CPU "PowerPC,[EMAIL PROTECTED]" #define OF_TBCLK (MPC8XX_HZ / 16) -- 1.5.5.1 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 1/3 (v2)] Convert mpc7448hpc2 to CONFIG_OF_LIBFDT
This was configured to use the deprecated CONFIG_OF_FLAT_TREE, change
to CONFIG_OF_LIBFDT.
WARNING: This conversion is untested because I do not have a board to
test it on.
NOTE: The FDT blob (DTS) must have an /aliases/ethernet0 and (optionally)
/aliases/ethernet1 property for the ethernet to work.
Signed-off-by: Gerald Van Baren <[EMAIL PROTECTED]>
---
board/freescale/mpc7448hpc2/mpc7448hpc2.c |9 +++
cpu/74xx_7xx/cpu.c| 35
drivers/pci/tsi108_pci.c | 33 +++---
include/configs/mpc7448hpc2.h |2 +-
4 files changed, 44 insertions(+), 35 deletions(-)
diff --git a/board/freescale/mpc7448hpc2/mpc7448hpc2.c
b/board/freescale/mpc7448hpc2/mpc7448hpc2.c
index 81846eb..fcbebc0 100644
--- a/board/freescale/mpc7448hpc2/mpc7448hpc2.c
+++ b/board/freescale/mpc7448hpc2/mpc7448hpc2.c
@@ -105,3 +105,12 @@ ft_board_setup (void *blob, bd_t *bd)
}
}
#endif
+
+#if defined(CONFIG_OF_BOARD_SETUP)
+void
+ft_board_setup(void *blob, bd_t *bd)
+{
+ ft_cpu_setup(blob, bd);
+ fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
+}
+#endif
diff --git a/cpu/74xx_7xx/cpu.c b/cpu/74xx_7xx/cpu.c
index 9c8998b..a6e3426 100644
--- a/cpu/74xx_7xx/cpu.c
+++ b/cpu/74xx_7xx/cpu.c
@@ -44,6 +44,11 @@
#include <74xx_7xx.h>
#include
+#if defined(CONFIG_OF_LIBFDT)
+#include
+#include
+#endif
+
#if defined(CONFIG_OF_FLAT_TREE)
#include
#endif
@@ -301,29 +306,19 @@ watchdog_reset(void)
/* - */
-#ifdef CONFIG_OF_FLAT_TREE
-void
-ft_cpu_setup (void *blob, bd_t *bd)
+#ifdef CONFIG_OF_LIBFDT
+void ft_cpu_setup(void *blob, bd_t *bd)
{
- u32 *p;
- ulong clock;
- int len;
-
- clock = bd->bi_busfreq;
+ do_fixup_by_prop_u32(blob, "device_type", "cpu", 4,
+"timebase-frequency", bd->bi_busfreq / 4, 1);
+ do_fixup_by_prop_u32(blob, "device_type", "cpu", 4,
+"bus-frequency", bd->bi_busfreq, 1);
+ do_fixup_by_prop_u32(blob, "device_type", "cpu", 4,
+"clock-frequency", bd->bi_intfreq, 1);
- p = ft_get_prop (blob, "/cpus/" OF_CPU "/bus-frequency", &len);
- if (p != NULL)
- *p = cpu_to_be32 (clock);
+ fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
-#if defined(CONFIG_TSI108_ETH)
- p = ft_get_prop (blob, "/" OF_TSI "/[EMAIL PROTECTED]/address", &len);
- memcpy (p, bd->bi_enetaddr, 6);
-#endif
-
-#if defined(CONFIG_HAS_ETH1)
- p = ft_get_prop (blob, "/" OF_TSI "/[EMAIL PROTECTED]/address", &len);
- memcpy (p, bd->bi_enet1addr, 6);
-#endif
+ fdt_fixup_ethernet(blob, bd);
}
#endif
/* - */
diff --git a/drivers/pci/tsi108_pci.c b/drivers/pci/tsi108_pci.c
index d5f11e4..4f02cb8 100644
--- a/drivers/pci/tsi108_pci.c
+++ b/drivers/pci/tsi108_pci.c
@@ -33,8 +33,9 @@
#include
#include
#include
-#ifdef CONFIG_OF_FLAT_TREE
-#include
+#if defined(CONFIG_OF_LIBFDT)
+#include
+#include
#endif
struct pci_controller local_hose;
@@ -162,20 +163,24 @@ void pci_init_board (void)
return;
}
-#ifdef CONFIG_OF_FLAT_TREE
-void
-ft_pci_setup (void *blob, bd_t *bd)
+#if defined(CONFIG_OF_LIBFDT)
+void ft_pci_setup(void *blob, bd_t *bd)
{
- u32 *p;
- int len;
-
- p = (u32 *)ft_get_prop (blob, "/" OF_TSI "/[EMAIL
PROTECTED]/bus-range", &len);
- if (p != NULL) {
- p[0] = local_hose.first_busno;
- p[1] = local_hose.last_busno;
+ int nodeoffset;
+ int tmp[2];
+ const char *path;
+
+ nodeoffset = fdt_path_offset(blob, "/aliases");
+ if (nodeoffset >= 0) {
+ path = fdt_getprop(blob, nodeoffset, "pci", NULL);
+ if (path) {
+ tmp[0] = cpu_to_be32(local_hose.first_busno);
+ tmp[1] = cpu_to_be32(local_hose.last_busno);
+ do_fixup_by_path(blob, path, "bus-range",
+ &tmp, sizeof(tmp), 1);
+ }
}
-
}
-#endif
+#endif /* CONFIG_OF_LIBFDT */
#endif /* CONFIG_TSI108_PCI */
diff --git a/include/configs/mpc7448hpc2.h b/include/configs/mpc7448hpc2.h
index f614e67..c01d0a5 100644
--- a/include/configs/mpc7448hpc2.h
+++ b/include/configs/mpc7448hpc2.h
@@ -75,7 +75,7 @@
#define CFG_PROMPT_HUSH_PS2"> "
/* Pass open firmware flat tree */
-#define CONFIG_OF_FLAT_TREE1
+#define CONFIG_OF_LIBFDT 1
#define CONFIG_OF_BOARD_SETUP 1
#define OF_CPU "PowerPC,[EMAIL PROTECTED]"
--
1.5.5.1
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://
[U-Boot-Users] [PATCH 0/3 (v2)] Remove the deprecated CONFIG_OF_FLAT_TREE
The following troika of patches switch the final two boards (mpc7448hpc2 and stxxst) from using CONFIG_OF_FLAT_TREE to CONFIG_OF_LIBFDT and then remove support for CONFIG_OF_FLAT_TREE. Since I don't have access to the boards I could not test them. If someone can test the conversions and provide patches, I would appreciate it. For the stxxtc board, I don't see how it uses CONFIG_OF_* at all, leading me to believe that the FDT support for that board has bit-rotted away already. Again, patches are welcome. Best regards, gvb - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 3/3 (v2)] Remove the deprecated CONFIG_OF_FLAT_TREE
Use CONFIG_OF_LIBFDT instead to support flattened device trees. It is
cleaner, has better functionality, and is better supported.
Signed-off-by: Gerald Van Baren <[EMAIL PROTECTED]>
---
README|9 +-
board/freescale/mpc7448hpc2/mpc7448hpc2.c | 22 +--
board/tqm8272/tqm8272.c |4 -
common/Makefile |1 -
common/ft_build.c | 471 -
cpu/74xx_7xx/cpu.c|4 -
include/configs/mpc7448hpc2.h |1 +
include/ft_build.h| 71 -
8 files changed, 3 insertions(+), 580 deletions(-)
delete mode 100644 common/ft_build.c
delete mode 100644 include/ft_build.h
diff --git a/README b/README
index f14fb7b..21f4470 100644
--- a/README
+++ b/README
@@ -350,7 +350,7 @@ The following options need to be configured:
expect it to be in bytes, others in MB.
Define CONFIG_MEMSIZE_IN_BYTES to make it in bytes.
- CONFIG_OF_LIBFDT / CONFIG_OF_FLAT_TREE
+ CONFIG_OF_LIBFDT
New kernel versions are expecting firmware settings to be
passed using flattened device trees (based on open firmware
@@ -361,13 +361,6 @@ The following options need to be configured:
* Adds the "fdt" command
* The bootm command automatically updates the fdt
- CONFIG_OF_FLAT_TREE
-* Deprecated, see CONFIG_OF_LIBFDT
-* Original ft_build.c-based support
-* Automatically modifies the dft as part of the bootm command
-* The environment variable "disable_of", when set,
-disables this functionality.
-
OF_CPU - The proper name of the cpus node.
OF_SOC - The proper name of the soc node.
OF_TBCLK - The timebase frequency.
diff --git a/board/freescale/mpc7448hpc2/mpc7448hpc2.c
b/board/freescale/mpc7448hpc2/mpc7448hpc2.c
index fcbebc0..f6cd192 100644
--- a/board/freescale/mpc7448hpc2/mpc7448hpc2.c
+++ b/board/freescale/mpc7448hpc2/mpc7448hpc2.c
@@ -31,10 +31,7 @@
#include
#include <74xx_7xx.h>
-#if defined(CONFIG_OF_FLAT_TREE)
-#include
-extern void ft_cpu_setup (void *blob, bd_t *bd);
-#endif
+#include
#undef DEBUG
@@ -89,23 +86,6 @@ long int initdram (int board_type)
return dram_size (board_type);
}
-#if defined(CONFIG_OF_FLAT_TREE) && defined(CONFIG_OF_BOARD_SETUP)
-void
-ft_board_setup (void *blob, bd_t *bd)
-{
- u32 *p;
- int len;
-
- ft_cpu_setup (blob, bd);
-
- p = ft_get_prop (blob, "/memory/reg", &len);
- if (p != NULL) {
- *p++ = cpu_to_be32 (bd->bi_memstart);
- *p = cpu_to_be32 (bd->bi_memsize);
- }
-}
-#endif
-
#if defined(CONFIG_OF_BOARD_SETUP)
void
ft_board_setup(void *blob, bd_t *bd)
diff --git a/board/tqm8272/tqm8272.c b/board/tqm8272/tqm8272.c
index 7bd6401..ec1a37c 100644
--- a/board/tqm8272/tqm8272.c
+++ b/board/tqm8272/tqm8272.c
@@ -30,10 +30,6 @@
#include
#include
#endif
-#if CONFIG_OF_FLAT_TREE
-#include
-#include
-#endif
#if 0
#define deb_printf(fmt,arg...) \
diff --git a/common/Makefile b/common/Makefile
index 9678799..b829373 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -118,7 +118,6 @@ COBJS-y += env_nowhere.o
COBJS-y += exports.o
COBJS-y += flash.o
COBJS-y += fpga.o
-COBJS-y += ft_build.o
COBJS-y += hush.o
COBJS-y += kgdb.o
COBJS-y += lcd.o
diff --git a/common/ft_build.c b/common/ft_build.c
deleted file mode 100644
index b951178..000
--- a/common/ft_build.c
+++ /dev/null
@@ -1,471 +0,0 @@
-/*
- * OF flat tree builder
- * Written by: Pantelis Antoniou <[EMAIL PROTECTED]>
- * Updated by: Matthew McClintock <[EMAIL PROTECTED]>
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-
-#include
-#include
-#include
-
-#ifdef CONFIG_OF_FLAT_TREE
-
-#include
-#include
-
-#include
-#include
-
-#undef DEBUG
-
-/* align addr on a size boundary - adjust address up if needed -- Cort */
-#define _ALIGN(addr,size) (((addr)+(size)-1)&(~((size)-1)))
-#ifndef CONFIG_OF_BOOT_CPU
-#define CONFIG_OF_BOOT_CPU 0
-#endif
-#define SIZE_OF_RSVMAP_ENTRY (2*sizeof(u64))
-
-static void ft_put_wor
Re: [U-Boot-Users] 83xx SPD_EEPROM DDR2 Issues
All, Correct, I did some math and they almost work out for DDR1 values However into DDR2 clocks speeds it gets increasingly bad. Going through the SPD tables I have found, it looks like there is not a mathematical way to convert those values, as they are in nanoseconds but only some are actually linear. Some values like 0x3D for spd->clk_cycle can't be converted using a formula, easy enough to put into a case statement. 0x3D is intended to be 3.75ns and 0x30 is 3.00ns. So 0x0D would be 0.75ns? Doesn't work in my book. However 0x25 is a nice easy clear 2.5ns. Whomever put Hex values to represent decimal numbers probably chose a poor idea. I am just hoping that most RAM isn't putting 'exact' values in SPD tables, but rather an industry standard value that is going to work with the intended SODIMM / DIMM, our code should be using lookup tables if so, not math formulas. I have already written a flat case statement with correct values. Easy to see now why it was breaking, as the CAS latencies were all hosed over for the faster memory. -Russ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 5:34 PM To: [EMAIL PROTECTED] Cc: 'David Hawkins'; 'Steve Hensley'; u-boot-users@lists.sourceforge.net Subject: RE: [U-Boot-Users] 83xx SPD_EEPROM DDR2 Issues "Russell McGuire" <[EMAIL PROTECTED]> wrote on 06/03/2008 04:15:55 PM: > > I haven't gone through the rest yet, but most likely if we want to keep SPD > working for DDR2, we'll have to add the DDR2 definitions SPD into the code, > as it looks like the DDR2 port is only partially complete. > > -Russ > Russ, That's pretty much jives with my recollection. One other thing that leaps to mind was the calculation for max_bus_clk. I hand cranked through that with a high clock rate as input and due to rounding errors got a bogus value. I don't remember the details right off the top of my head but it seems to me that the net result was I started with a bus clock that should have landed max_data_rate in one of those if-if-else-if cases, but it didn't. So I think that whole function (and especially the max_bus_clk calculation) needs to be gone through. Good luck. I'd help but I have my own issues with MTD :(. Bruce - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] 85xx: Add setting of cache props in the device tree.
On Thu, May 29, 2008 at 11:22 AM, Kumar Gala <[EMAIL PROTECTED]> wrote:
> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
> ---
> cpu/mpc85xx/fdt.c | 128
> +
> 1 files changed, 128 insertions(+), 0 deletions(-)
>
> diff --git a/cpu/mpc85xx/fdt.c b/cpu/mpc85xx/fdt.c
> index bb87740..92952e6 100644
> --- a/cpu/mpc85xx/fdt.c
> +++ b/cpu/mpc85xx/fdt.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
>
> extern void ft_qe_setup(void *blob);
> #ifdef CONFIG_MP
> @@ -77,6 +78,131 @@ void ft_fixup_cpu(void *blob, u64 memory_limit)
> }
> #endif
>
> +#ifdef CONFIG_L2_CACHE
> +/* return size in kilobytes */
> +static inline u32 l2cache_size(void)
> +{
> + volatile ccsr_l2cache_t *l2cache = (void *)CFG_MPC85xx_L2_ADDR;
> + volatile u32 l2siz_field = (l2cache->l2ctl >> 28) & 0x3;
> + u32 ver = SVR_SOC_VER(get_svr());
> +
> + switch (l2siz_field) {
> + case 0x0:
> + break;
> + case 0x1:
> + if (ver == SVR_8540 || ver == SVR_8560 ||
> + ver == SVR_8541 || ver == SVR_8541_E ||
> + ver == SVR_8555 || ver == SVR_8555_E)
> + return 128;
> + else
> + return 256;
> + break;
> + case 0x2:
> + if (ver == SVR_8540 || ver == SVR_8560 ||
> + ver == SVR_8541 || ver == SVR_8541_E ||
> + ver == SVR_8555 || ver == SVR_8555_E)
> + return 256;
> + else
> + return 512;
> + break;
> + case 0x3:
> + return 1024;
> + break;
> + }
> +
> + return 0;
> +}
How about we create a feature in the new cpu_type field you created,
and use that to flag it. :)
Andy
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] 83xx SPD_EEPROM DDR2 Issues
"Russell McGuire" <[EMAIL PROTECTED]> wrote on 06/03/2008 04:15:55 PM: > > I haven't gone through the rest yet, but most likely if we want to keep SPD > working for DDR2, we'll have to add the DDR2 definitions SPD into the code, > as it looks like the DDR2 port is only partially complete. > > -Russ > Russ, That's pretty much jives with my recollection. One other thing that leaps to mind was the calculation for max_bus_clk. I hand cranked through that with a high clock rate as input and due to rounding errors got a bogus value. I don't remember the details right off the top of my head but it seems to me that the net result was I started with a bus clock that should have landed max_data_rate in one of those if-if-else-if cases, but it didn't. So I think that whole function (and especially the max_bus_clk calculation) needs to be gone through. Good luck. I'd help but I have my own issues with MTD :(. Bruce - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] TQM: move TQM boards to board/tqc
On Mon, Jun 2, 2008 at 6:22 PM, Andy Fleming <[EMAIL PROTECTED]> wrote: > On Wed, May 28, 2008 at 12:53 PM, <[EMAIL PROTECTED]> wrote: >> From: Wolfgang Grandegger <[EMAIL PROTECTED]> >> >> Move all TQM board directories to the vendor specific directory "tqc" >> for modules from TQ-Components GmbH (http://www.tqc.de). >> >> Note: this patch is too big for posting here and therefore I removed >> the hunks moving the files. I could provide the full patch on request. >> >> Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]> > > I have no objections to this change. However, if you want to post the > whole patch, you can generate it by passing "-M" to git-format-patch. > This will cause git to generate a patch which tells us the file was > moved, and git-am understands that, and does the right thing. That is, *please* repost the patch with everything included. Wolfgang can apply it directly, and then I can apply the other 12+ patches you sent which depend on it. Andy :) - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH v2] 85xx: Only use PORPLLSR[DDR_Ratio] on platforms that define it
On Thu, May 29, 2008 at 1:21 AM, Kumar Gala <[EMAIL PROTECTED]> wrote: > Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> > --- > > Fix warning that the first version introduced. applied, gracias - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] 83xx SPD_EEPROM DDR2 Issues
Bruce, I think you've hit upon something here. After checking the SPD tables during the intial comparison for data rates, it is clear that 1) the DDR2 bit fields are not defined properly. i.e. it looks like the big if-if-else statement specifically does not have valid DDR2 values defined for clk_cycle2 (30h, 3Dh, 50h) not DDR1, so we're going need an extra 3 defined at a minimum. I haven't gone through the rest yet, but most likely if we want to keep SPD working for DDR2, we'll have to add the DDR2 definitions SPD into the code, as it looks like the DDR2 port is only partially complete. -Russ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 3:31 PM To: [EMAIL PROTECTED] Cc: 'Maggs Bill'; 'Steve Hensley'; u-boot-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: Re: [U-Boot-Users] 83xx SPD_EEPROM DDR2 Issues > > Today, I went to my local PC store, and bought EVERY type of DDR2 > SODIMM memory they had, Kingston, Crucial, PC4200, PC5300 four > different kinds of memory, and NONE of them will boot with U-boot now. > Hay Russell, I don't have patches, and I haven't worked on this in a long time because we have a single build option for our RAM. However, I may have a pointer for you to look at if you haven't already. Way back when we we're thinking about having SPD support I did spend some time digging through spd_sdram.c and found that some of the calculations wereI won't say broken, but not exactly acurate because of they way they were done. I also found that the highest data rate speeds supported didn't go high enough to support all of the speeds DDR2 can have. Like I said, it's been a long time and someone may have already fixed it, but it had to do with calculating max_data_rate, effective_data_rate, and caslat in spd_sdram(). It was something I ment to fix and then never did because we didn't end up using it. Hope this helps. If not, sorry for the noise. Bruce - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] 83xx SPD_EEPROM DDR2 Issues
> > Today, I went to my local PC store, and bought EVERY type of DDR2 > SODIMM memory they had, Kingston, Crucial, PC4200, PC5300 four > different kinds of memory, and NONE of them will boot with U-boot now. > Hay Russell, I don't have patches, and I haven't worked on this in a long time because we have a single build option for our RAM. However, I may have a pointer for you to look at if you haven't already. Way back when we we're thinking about having SPD support I did spend some time digging through spd_sdram.c and found that some of the calculations wereI won't say broken, but not exactly acurate because of they way they were done. I also found that the highest data rate speeds supported didn't go high enough to support all of the speeds DDR2 can have. Like I said, it's been a long time and someone may have already fixed it, but it had to do with calculating max_data_rate, effective_data_rate, and caslat in spd_sdram(). It was something I ment to fix and then never did because we didn't end up using it. Hope this helps. If not, sorry for the noise. Bruce - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] 83xx SPD_EEPROM DDR2 Issues
Hi Russell, > Reposting on previous issue that is becoming a lot more painful. > > Today, I went to my local PC store, and bought EVERY type of DDR2 SODIMM > memory they had, Kingston, Crucial, PC4200, PC5300 four different kinds > of memory, and NONE of them will boot with U-boot now. > > We apparently have hit a new version of RAM in production, that I > imagine will affect EVERYONE using 83xx chips if they actually try and > purchase any recent memory. > > Has anyone got patches out for updates SPD code? > > I will work on this today and until I get it fixed, since beta testing > has come to a complete halt within our company due to this. Out of interest, have you determined what is incorrect in the SPD entries versus a working configuration for the board? Have you tried to get each DDR2 working independently of the SPD settings? For example, you could test each RAM module by plugging it into the MPC8349EA-MDS-PB, and powering it up in a PCI slot with CFG_RS[0:2] = 100h, and CFG_CLKIN = 0 for a 33MHz PCI bus, or CFG_RS[0:2] = 011h, and CFG_CLKIN = 0 for a 66MHz PCI bus (or CFG_CLKIN = 1 for 33MHz bus). See 4.3 in the EA reference manual. This will boot the board in agent mode with a hard-coded reset values for the RCWs. The DDR interface will be clocked at 133MHz, so 266MHz DDR. The core would run at 400MHz if it was enabled, but its not needed. From the x86 host, you can manually program the DDR registers and determine a configuration that works. The reason for booting the board in this way, is that during each test you need to disable the DDR controller, make changes to the settings, and then re-enable the controller. You can generate burst transactions to the DDR memory by DMAing data from the PCI host to the board, and back again. Even though the PCI clock is slower than the DDR, the I/O sequencer buffers the data, and generates burst transactions to the DDR. I used this to write a pattern to a page of memory on the host, DMA to our MPC8349EA board, DMA it back again, and check the pattern is valid. The adjust the clocks and retry. I'm pretty sure the only things that you'll want to adjust are the clock timings. There are two clock adjustment options in the DDR controller 1. CK/CK# to address/command timing DDR_SDRAM_CLK_CNTL[CLK_ADJUST] b clock launched aligned with address/command 0001b clock launched 1/8th clock after address/command 0010b clock launched 1/2th clock after address/command 0011b clock launched 3/8th clock after address/command 0100b clock launched 1/2th clock after address/command 0101b clock launched 5/8th clock after address/command 0110b clock launched 3/4th clock after address/command 0111b clock launched 7/8th clock after address/command 1000b clock launched 1 clock after address/command 1001b-b Reserved 2. write-data to DQS timing TIMING_CFG_2[WR_DATA_DELAY] 000b0 clock delay 001b 1/4 clock delay 010b 1/2 clock delay 011b 3/4 clock delay 100b1 clock delay 101b 5/4 clock delay 110b 3/2 clock delay 111b reserved Alternatively you can use the BDI2000 to initial the DDR registers, and DMA say from Flash to DDR to write patterns. Here's the configuration file I wrote for our EA board based on the settings from a running U-Boot (so the parameters were determined from working SPD decoded values): ftp://ftp.denx.de/pub/BDI2000/mpc8349ea_mds_pb.cfg You could see how different the SPD derived settings are relative to the settings in this configuration file. Hope that helps. Cheers, Dave - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] 83xx SPD_EEPROM DDR2 Issues
Guys, Reposting on previous issue that is becoming a lot more painful. Today, I went to my local PC store, and bought EVERY type of DDR2 SODIMM memory they had, Kingston, Crucial, PC4200, PC5300 four different kinds of memory, and NONE of them will boot with U-boot now. We apparently have hit a new version of RAM in production, that I imagine will affect EVERYONE using 83xx chips if they actually try and purchase any recent memory. Has anyone got patches out for updates SPD code? I will work on this today and until I get it fixed, since beta testing has come to a complete halt within our company due to this. Russell McGuire Senior Systems Engineer [EMAIL PROTECTED] 503.888.0968 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] UEC Driver - 83xx RGMII half duplex BUG FIX - RFC
On Mon, 2 Jun 2008 16:03:56 -0700 "Russell McGuire" <[EMAIL PROTECTED]> wrote: > To work around this we need to remove the clearing of the FDX bit while in > RGMII, RTBI, TBI, or GMII modes. > > The only modes that can clear the FDX bit are MII or RMII. > > Since I am not the author of the drivers, would the team want me to submit > my idea on how to fix this, or would the author like to quickly add in this > check before clearing the bit? Or alternatively before calling the > uec_set_mac_duplex function(). Though I am a fan of making all functions > self protecting against bad code. Can you submit a patch for an on-list review? Kim - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [cfi-flash] Please pull git://www.denx.de/git/u-boot-cfi-flash.git
The following changes since commit 1f1554841a4c8e069d331176f0c3059fb2bb8280: Wolfgang Denk (1): Merge branch 'master' of /home/wd/git/u-boot/custodians are available in the git repository at: git://www.denx.de/git/u-boot-cfi-flash.git master Vasiliy Leoenenko (2): cfi_flash: support of long cmd in U-boot. cfi_flash: enable M18 flash chips family support. drivers/mtd/cfi_flash.c | 41 ++--- 1 files changed, 34 insertions(+), 7 deletions(-) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] M18 flash (Sibley) support (attempt 2)
On Wednesday 07 May 2008, Vasiliy Leoenenko wrote: > cfi_flash: enable M18 flash chips family support. > > Added new command set ID. Buffered write command processing is changed in > order to support M18 flash chips family. Applied to u-boot-cfi-flash. Thanks. Best regards, Stefan = 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: [EMAIL PROTECTED] = - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] M18 flash (Sibley) support (attempt 2)
On Wednesday 07 May 2008, Vasiliy Leoenenko wrote: > cfi_flash: support of long cmd in U-boot. > > Some NOR flash chips needs support of commands with length grether than max > value size of uchar. For example all M18 family chips use 0x1ff command in > buffered write mode as value of program loops count. Applied to u-boot-cfi-flash. Thanks. Best regards, Stefan = 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: [EMAIL PROTECTED] = - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 2/2] Add board specific files for BUBBATWO
On Mon, 2 Jun 2008 15:16:02 +0200
Tor Krill <[EMAIL PROTECTED]> wrote:
> +U_BOOT_CMD (bubbacmd, 3, 1, do_bubbacmd,
> + "bubbacmd- Board specific commands for Bubba TWO\n",
> + "spindown [dev] - spin down disk dev\n"
> + "bubbacmd spinup [dev] - spin up disk dev\n"
> + "bubbacmd button - read button status\n");
> +#endif
I the spinup/spindown commands should be part of cmd_ide, no? Or
rather, should they be eliminated in favour of "Das U-Boot way" of only
powering up devices when accesses are requested? i.e, power up on a
disk read command and power down after it's done?
btw, this also prevents me from applying this board support patch
because of the sata_sil3114 driver dependency here.
> +int getboardversion (void)
> +{
> + volatile immap_t *im = (immap_t *) CFG_IMMR;
> + int rev = im->gpio[0].dat & (HW_ID0 | HW_ID1 | HW_ID2);
looks like the and op is unnecessary here..plus we're not doing
volatile i/o accesses any more - use {in,out}_be32(), {set,clr}bits32()
etc., this occurs many other places in this patch..
> +
> + rev =
> + ((rev & HW_ID0) >> 3) | ((rev & HW_ID1) >> 2) | ((rev & HW_ID2)
> <<
> + 1);
> +
> + return rev;
> +}
return ((rev & HW_ID0) >> 3) | ((rev & HW_ID1) >> 2) |
((rev & HW_ID2) << 1);
> +ulong board_flash_get_legacy (ulong base, int banknum, flash_info_t * info)
> +{
> + if (banknum == 0) { /* non-CFI boot flash */
> + info->portwidth = FLASH_CFI_16BIT;
> + info->chipwidth = FLASH_CFI_BY16;
> + info->interface = FLASH_CFI_X16;
> + return 1;
> + } else {
> + return 0;
> + }
else is superfluous
> +/* Lookup table for the different boardversions */
> +static struct {
> + u32 memsize;
> + u32 config;
> +} meminfo[] = {
> + /* 0 - revA prototypes */
> + {
> + memsize: 128, config:CFG_DDR_CONFIG_128},
> + /* 1 - revB */
> + {
> + memsize: 256, config:CFG_DDR_CONFIG_256},
> + /* 2 - empty */
> + {
> + memsize: 128, config:CFG_DDR_CONFIG_128},
> + /* 3 - empty */
> + {
> + memsize: 128, config:CFG_DDR_CONFIG_128},
> + /* 4 - empty */
> + {
> + memsize: 128, config:CFG_DDR_CONFIG_128},
> + /* 5 - empty */
> + {
> + memsize: 128, config:CFG_DDR_CONFIG_128},
> + /* 6 - empty */
> + {
> + memsize: 128, config:CFG_DDR_CONFIG_128},
> + /* 7 - empty */
> + {
> + memsize: 128, config:CFG_DDR_CONFIG_128}
> +};
would something like this be neater:
{ 128, CFG_DDR_CONFIG_128 }, /* 7 - empty */
?
Kim
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] eth0 not geting enabled
> Hi there >> But if I do that when there is no network u-boot never recovers. Can >> someone tell > me the way out. It is successful when network is >> available, >>though. >Are you using a old (really old) u-boot. This behaviour was observed >on u-boot 1.1.2, but when we upgraded to 1.2.0 and above, ping used to >timeout. I have tried u-boot 1.1.5 and 1.3.0. They both don't timeout. --Avinash - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] eth0 not geting enabled
Hi, On Mon, Jun 2, 2008 at 1:21 PM, Avinash Vijayvergia <[EMAIL PROTECTED]> wrote: > Hi there > But if I do that when there is no network u-boot never recovers. Can someone > tell > me the way out. It is successful when network is available, > though. Are you using a old (really old) u-boot. This behaviour was observed on u-boot 1.1.2, but when we upgraded to 1.2.0 and above, ping used to timeout. -- sughosh - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [ppc4xx] Please pull git://www.denx.de/git/u-boot-ppc4xx.git
The following changes since commit 10a3367955bc2033b288915f8f10d0e507fe2fa1:
Stefan Roese (1):
Merge branch 'master' of /home/stefan/git/u-boot/u-boot
are available in the git repository at:
git://www.denx.de/git/u-boot-ppc4xx.git master
Grant Erickson (3):
PPC4xx: Simplified post_word_{load, store}
ppc4xx: Enable Primordial Stack for 40x and Unify ECC Handling
ppc4xx: Enable Primordial Stack for 40x and Unify ECC Handling
Kenneth Johansson (1):
Remove shell variable UNDEF_SYM.
Matthias Fuchs (1):
ppc4xx: Cleanup CPCI405 variant's config file
Stefan Roese (8):
ppc4xx/NAND_SPL: Consolidate 405 and 440 NAND booting code in start.S
ppc4xx: Consolidate PPC4xx SDRAM/DDR/DDR2 defines, part1
ppc4xx: Consolidate PPC4xx SDRAM/DDR/DDR2 defines, part2
ppc4xx: Change Kilauea to use the common DDR2 init function
ppc4xx: Fix common ECC generation code for 440GP style platforms
ppc4xx: Use new 4xx SDRAM controller enable defines in common ECC code
ppc4xx: Remove superfluous dram_init() call or replace it by initdram()
ppc4xx: Remove implementations of testdram()
board/amcc/acadia/memory.c | 15 -
board/amcc/bamboo/bamboo.c | 67 --
board/amcc/bubinga/bubinga.c | 16 -
board/amcc/canyonlands/canyonlands.c | 38 -
board/amcc/ebony/ebony.c | 30 -
board/amcc/katmai/katmai.c | 30 -
board/amcc/kilauea/Makefile |3 +-
board/amcc/kilauea/init.S| 154
board/amcc/kilauea/memory.c | 79 --
board/amcc/luan/luan.c | 44 --
board/amcc/makalu/Makefile |2 +-
board/amcc/makalu/init.S | 125 +
board/amcc/makalu/memory.c | 188 -
board/amcc/ocotea/ocotea.c | 30 -
board/amcc/sequoia/sequoia.c | 38 -
board/amcc/taihu/taihu.c | 42 --
board/amcc/taishan/taishan.c | 30 -
board/amcc/walnut/walnut.c | 16 -
board/amcc/yosemite/yosemite.c | 52 +--
board/amcc/yucca/yucca.c | 30 -
board/amirix/ap1000/init.S |4 -
board/cray/L1/init.S | 11 -
board/csb272/csb272.c|9 +
board/csb472/csb472.c|9 +
board/eric/eric.c|8 +
board/esd/ar405/ar405.c | 22 -
board/esd/canbt/canbt.c | 19 -
board/exbitgen/exbitgen.c|9 +
board/g2000/g2000.c | 35 -
board/jse/init.S | 10 -
board/lwmon5/lwmon5.c| 38 -
board/ml2/init.S |4 -
board/mpl/mip405/init.S | 13 -
board/mpl/pip405/init.S | 13 -
board/netstal/hcu4/hcu4.c|9 -
board/netstal/hcu5/sdram.c | 26 +-
board/netstal/mcu25/mcu25.c |9 -
board/pcs440ep/pcs440ep.c| 38 -
board/prodrive/alpr/alpr.c | 30 -
board/w7o/w7o.c |8 +
board/xilinx/ml300/init.S|4 -
board/zeus/zeus.c| 45 --
cpu/ppc4xx/44x_spd_ddr.c | 200 +-
cpu/ppc4xx/44x_spd_ddr2.c| 131 -
cpu/ppc4xx/Makefile |1 +
cpu/ppc4xx/commproc.c| 26 +-
cpu/ppc4xx/cpu_init.c| 85 ---
cpu/ppc4xx/ecc.c | 122
cpu/ppc4xx/ecc.h | 69 ++
cpu/ppc4xx/sdram.c | 54 +--
cpu/ppc4xx/start.S | 522 --
cpu/ppc4xx/traps.c |9 +-
include/asm-ppc/ppc4xx-sdram.h | 1156 ++
include/asm-ppc/processor.h |6 +-
include/configs/CPCI4052.h | 38 -
include/configs/CPCI405AB.h | 22 -
include/configs/CPCI405DT.h | 33 -
include/configs/alpr.h |1 -
include/configs/bamboo.h |1 -
include/configs/ebony.h |1 -
include/configs/katmai.h |1 -
include/configs/kilauea.h| 116 +++-
include/configs/luan.h |1 -
include/configs/makalu.h | 114 +++-
include/configs/ocotea.h |1 -
include/configs/taishan.h|1 -
include/configs/yucca.h |1 -
include/ppc405.h | 527 --
include/ppc440.h | 896 ---
include/ppc4xx.h | 40 +
nand_spl/board/amcc/acadia/Makefile |2 +-
nand_spl/board/amcc/bamboo/Makefile |2 +-
nand_spl/board/amcc/canyonlands/Makefil
Re: [U-Boot-Users] [PATCH] 4xx: Cleanup CPCI405 variant's config file
On Friday 30 May 2008, Matthias Fuchs wrote: > This patch removes some dead code from CPCI405 board's > config files. JFFS2 support is also removed. It's not used and > CPCI4052 does not build anymore without some size reduction. Applied to u-boot-ppc4xx repo. Thanks. Best regards, Stefan = 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: [EMAIL PROTECTED] = - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] Remove shell variable UNDEF_SYM.
On Thursday 29 May 2008, Kenneth Johansson wrote: > UNDEF_SYM is a shell variable in the main Makefile used to force the > linker to add all u-boot commands to the final image. It has no use here. Applied to u-boot-ppc4xx repo. Thanks. Best regards, Stefan = 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: [EMAIL PROTECTED] = - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 2/2 v3] PPC4xx: Enable Primordial Stack for 40x and Unify ECC Handling
On Thursday 22 May 2008, Grant Erickson wrote: > This patch (Part 2 of 2): > > * Rolls up a suite of changes to enable correct primordial stack and > global data handling when the data cache is used for such a purpose > for PPC40x-variants (i.e. CFG_INIT_DCACHE_CS). > > * Related to the first, unifies DDR2 SDRAM and ECC initialization by > eliminating redundant ECC initialization implementations and moving > redundant SDRAM initialization out of board code into shared 4xx > code. > > * Enables MCSR visibility on the 405EX(r). > > * Enables the use of the data cache for initial RAM on > both AMCC's Kilauea and Makalu and removes a redundant > CFG_POST_MEMORY flag from each board's CONFIG_POST value. > > - Removed, per Stefan Roese's request, defunct memory.c file for > Makalu and rolled sdram_init from it into makalu.c. > > With respect to the 4xx DDR initialization and ECC unification, there > is certainly more work that can and should be done (file renaming, > etc.). However, that can be handled at a later date on a second or > third pass. As it stands, this patch moves things forward in an > incremental yet positive way for those platforms that utilize this > code and the features associated with it. Applied to u-boot-ppc4xx repo. Thanks. Best regards, Stefan = 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: [EMAIL PROTECTED] = - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/2 v3] PPC4xx: Enable Primordial Stack for 40x and Unify ECC Handling
On Thursday 22 May 2008, Grant Erickson wrote: > This patch (Part 1 of 2): > > * Rolls up a suite of changes to enable correct primordial stack and > global data handling when the data cache is used for such a purpose > for PPC40x-variants (i.e. CFG_INIT_DCACHE_CS). > > * Related to the first, unifies DDR2 SDRAM and ECC initialization by > eliminating redundant ECC initialization implementations and moving > redundant SDRAM initialization out of board code into shared 4xx > code. > > * Enables MCSR visibility on the 405EX(r). > > * Enables the use of the data cache for initial RAM on > both AMCC's Kilauea and Makalu and removes a redundant > CFG_POST_MEMORY flag from each board's CONFIG_POST value. > > - Removed, per Stefan Roese's request, defunct memory.c file for > Makalu and rolled sdram_init from it into makalu.c. > > With respect to the 4xx DDR initialization and ECC unification, there > is certainly more work that can and should be done (file renaming, > etc.). However, that can be handled at a later date on a second or > third pass. As it stands, this patch moves things forward in an > incremental yet positive way for those platforms that utilize this > code and the features associated with it. Applied to u-boot-ppc4xx repo. Thanks. Best regards, Stefan = 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: [EMAIL PROTECTED] = - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH v3] PPC4xx: Simplified post_word_{load, store}
On Wednesday 21 May 2008, Grant Erickson wrote:
> This patch simplifies post_word_{load,store} by using the preprocessor
> to eliminate redundant, copy-and-pasted code.
Applied to u-boot-ppc4xx repo. Thanks.
Best regards,
Stefan
=
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: [EMAIL PROTECTED]
=
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [patch 1/1] try to fix problem on the trizeps board DM9000 error: status check fail: 0x6d
According to the Application Notes of the DM9000, only the 2 bits 0:1 of
the status byte need to be checked to identify a valid packet in the fifo
But, The several different Application Notes do not all speak the same
language on these bits. They do not disagree, but only 1 Application Note
noted explicitly that only these 2 bits need to be checked.
Even the datasheets do not mention anything about these 2 bits.
Because the old code, and the kernel check the whole byte, I left this piece
untouched.
However, I tested all board/DM9000[A|E|EP] devices with this 2 bit check, so
it should work.
Notice, that the 2nd iteration through this receive loop (when a 2nd packet is
in the fifo) is much shorter now, compared to the older U-boot driver code,
so that we can maybe run into a hardware condition now that was never seen
before, or maybe was seen very unfrequently.
Signed-off-by: Remy Bohmer <[EMAIL PROTECTED]>
---
drivers/net/dm9000x.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Index: u-boot-git-03062008/drivers/net/dm9000x.c
===
--- u-boot-git-03062008.orig/drivers/net/dm9000x.c 2008-06-03
19:52:06.0 +0200
+++ u-boot-git-03062008/drivers/net/dm9000x.c 2008-06-03 19:54:44.0
+0200
@@ -624,8 +624,9 @@ eth_rx(void)
for (;;) {
DM9000_ior(DM9000_MRCMDX); /* Dummy read */
- /* Get most updated data */
- rxbyte = DM9000_inb(DM9000_DATA);
+ /* Get most updated data,
+ only look at bits 0:1, See application notes DM9000 */
+ rxbyte = DM9000_inb(DM9000_DATA) & 0x03;
/* Status check: this byte must be 0 or 1 */
if (rxbyte > DM9000_PKT_RDY) {
--
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [patch 0/6] DM9000: Several fixes/cleanups for the DM9000A controller
Hello Stefano, > this patch does not work on the trizeps board. I get the following error: > Loading: DM9000 error: status check fail: 0x6d I think I know where this one comes from. The code reporting this error is actually not changed, but the pace in which it is called is much faster with the new code (when a 2nd packet is in the fifo) compared to the old U-boot driver code. I can imagine you run into a race in the network driver that you never did see before, or very infrequent. I left this piece of code untouched because the Application Notes did not speak the same language on this register. One App.note explicitly mentioned only to check bit 0:1 of this register, while others did speak about it with that many words. Notice that they all did not disagree about this. Besides, the old code, and the Linux kernel, checked the whole byte. So, stupid me, left it untouched against better knowledge... In a few minutes I will post a patch which I hope it will solve this. Can you please try it on your board? If so, it can be added to the patch series earlier today. Kind Regards, Remy - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] uboot version for 8572CDS
On Jun 3, 2008, at 12:13 PM, Morrison, Tom wrote: > OK - wrong list - sorry Kumar - yes, I do have a 8572 DS system - > > So, there is no support plans in uboot 1.3.3 for sbc8572 as there > is for boards like sbc8548 and sbc8641D? You'd have to ask who ever creates the sbc8572 board that question (I'm guessing windriver). - k - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [Patch 11/17 Try 2] U-Boot-V2:ARM:OMAP3: Add support for OMAP3Silicon files
On Tue, Jun 03, 2008 at 10:36:05AM -0500, Menon, Nishanth wrote: > Sascha, > > -Original Message- > > From: Sascha Hauer [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, June 03, 2008 3:18 AM > > To: Menon, Nishanth > > Cc: Peter Pearse; u-boot-users@lists.sourceforge.net; Kamat, Nishant; Syed > > Mohammed, Khasim; Laurent > > Desnogues; [EMAIL PROTECTED] > > Subject: Re: [Patch 11/17 Try 2] U-Boot-V2:ARM:OMAP3: Add support for > > OMAP3Silicon files > > > > On Wed, May 28, 2008 at 10:39:07AM -0500, Menon, Nishanth wrote: > > > As per the thread in: > > > http://www.nabble.com/-Patch-06-17--U-Boot-V2%3AARM%3A-Add-sizes.h-tt17372780.html#a17372780 > > > sizes.h dependency is removed from the following patch. This is a > > > resubmission. > > > > > > This patch introduces support for OMAP3430 - provides for generic OMAP3 > > > files. > > > > Looks ok to me besides the occurences of return with the value in > > brackets. > > > > Sascha > Arrgh.. I have myself to blame for inconsistent return styles. Probably we > need an equivalent of checkpatch and a Lindent for U-Boot v2? I suppose the > right style is return without brackets? Yes it is, but that's somewhere on the boarder to nitpicking, don't know which side though ;) > > Regards, > Nishanth Menon > -- Pengutronix e.K. - Linux Solutions for Science and Industry --- Kontakt-Informationen finden Sie im Header dieser Mail oder auf der Webseite -> http://www.pengutronix.de/impressum/ <- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [Patch 09/17] U-Boot-V2:Serial: Add support for NS16550Driver.`
On Tue, Jun 03, 2008 at 10:29:03AM -0500, Menon, Nishanth wrote:
> Sascha,
> > -Original Message-
> > From: Sascha Hauer [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, June 03, 2008 3:09 AM
> > To: Menon, Nishanth
> > Cc: u-boot-users@lists.sourceforge.net; Laurent Desnogues; [EMAIL
> > PROTECTED];
> > [EMAIL PROTECTED]; Gopinath, Thara; Kamat, Nishant; Syed Mohammed, Khasim
> > Subject: Re: [Patch 09/17] U-Boot-V2:Serial: Add support for NS16550Driver.`
> >
> > > +
> > > +config DRIVER_SERIAL_NS16550_REG_SIZE_8_BITS_PAD_TO_64
> > > + bool "8 bit register Padded to 64 bit"
> > > + help
> > > + Say Y here if you are using a 8 bit register padded to 64 bits for
> > > NS16550
> > > +endchoice
> >
> > Please have a look at drivers/net/dm9000.c for an example on how to pass
> > data between the board and a driver via platform_data. The kconfig approach
> > for this has several disadvantages. The user is presented a couple of
> > options which he better does not change because it would break the driver.
> > Another problem is that you cannot connect two ns16550 with different
> > register widths on one board (though that's an unlikely case).
> My problem is not sending data size APIs. I do not want to maintain multiple
> different structures variable if I can avoid at compile time. I do pass the
> clock and other variant params through platform_data. If I don't use the
> #defines, I need to do something like the following:
> Pass reg_type thru platform data, then for each set of access, do:
> switch (reg_type) {
> case REG_SIZE_8_BITS_PAD_TO_64:
> com_port_8_pad64->thr = something;
> break;
> case REG_SIZE_8_BITS_PAD_TO_32:
> com_port_8_pad32->thr = something;
> break;
> etc..
What I meant is that you should put the access functions itself into
platform_data, not a description of their register size / padding.
That way each board can decide which funky access functions it needs, be
it that the 16550 is connected via SPI, memory io or whatever.
> a) code size increases
Yes, by a few bytes
> b) un-necessary overhead in performance.
I bet it's hardly measurable
> c) resultant code is going to look dirty.
> NS16550_t com_port as in the current implementation is easy to read and looks
> neat. I believe the Kconfig is a neater approach.
> If I plan on doing a #define, it will still be need a higher level definition
> to decide on this.
> The next alternative will be to:
> #define THR1 1 (for all platforms)
>
> And each platform code implement:
> unsigned long reg_read(unsigned reg)
> {
> readb(silicon_offset_of_reg);
> }
> And pass these access functions over platform_data.
> I really don't like the overhead in doing this.
>
> >
> > > +
> > > +/* Forward declaration */
> > > +static unsigned int ns16550_calc_divisor(struct console_device *cdev,
> > > + unsigned int baudrate);
> > > +static void ns16550_serial_init_port(struct console_device *cdev);
> > > +static void ns16550_putc(struct console_device *cdev, char c);
> > > +static int ns16550_getc(struct console_device *cdev);
> > > +static int ns16550_tstc(struct console_device *cdev);
> > > +static int ns16550_setbaudrate(struct console_device *cdev, int
> > > baud_rate);
> > > +static int ns16550_probe(struct device_d *dev);
> > > +static int ns16550_serial_init(void);
> >
> > Please reorder the functions to get rid of these declarations. It helps
> > reading the code when you know that a functions definition is before
> > its usage.
> It is a matter of a programmer preference I believe. Folks who do a topdown
> reading prefer to have the high level callers on tops and dig to the lower
> levels. Others do a bottom up reading. Yeah probably doing a bottom to top
> approach could be cleaner in this case. Will fix.
Yes it is. Most kernel programmers (and I think most U-Boot hackers are
kernel programmers ;) are used to read bottom to top.
>
> > > + cdev->f_caps = plat->f_caps;
> >
> > Ok, you know about platform_data ;). I suggest that you put the register
> > access functions there.
> I really would not like to do it as explained above. The code will end up
> unreadable at the end of it.
>
> Regards,
> Nishanth Menon
>
--
Pengutronix e.K. - Linux Solutions for Science and Industry
---
Kontakt-Informationen finden Sie im Header dieser Mail oder
auf der Webseite -> http://www.pengutronix.de/impressum/ <-
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] uboot version for 8572CDS
OK - wrong list - sorry Kumar - yes, I do have a 8572 DS system - So, there is no support plans in uboot 1.3.3 for sbc8572 as there is for boards like sbc8548 and sbc8641D? tom -Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 12:11 PM To: Morrison, Tom Cc: [EMAIL PROTECTED] list; Wolfgang Denk; U-Boot Users Subject: Re: uboot version for 8572CDS On Jun 3, 2008, at 9:41 AM, Morrison, Tom wrote: > I am wondering if there is a development branch that contains > support for the Freescale 8572CDS...Looking in the latest uboot > version (1.3.3) there is support for sbc8641 & sbc8548 - but > no specific support for a sbc8572? Such questions are best asked on the u-boot list. I'm not aware of a 8572 CDS, we do have a 8572 DS. And no, there isn't a public tree w/support for this board. The only code is either the FSL BSP or internal to FSL at this point. - k - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] MPC85xx: Beatify boot output of L2 cache configuration
Hi Wolfgang, > Andy Fleming wrote: >> On Wed, May 28, 2008 at 1:12 PM, Wolfgang Grandegger <[EMAIL PROTECTED]> >> wrote: >>> The boot output is now aligned poperly with other boot output >>> lines, e.g.: >>> >>> FLASH: 128 MB >>> L2:512 KB enabled >>> >>> Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]> >> >> A silly comment, but let's spell it "Beautify" > > Of course, I didn't want to beatify this part of the code. New patch > will follow. > > BTW: what is the correct way to send an updated version of a patch. > Should the subject be unchanged or is adding "v2" to [PATCH] preferred. Please change the subject, so it is easier to follow what iteration is being discussed. git-format-patch will help out nicely here: git-format-patch --subject-prefix="PATCH v2" ... Cheers Detlev -- Cyberwar is certainly not a myth. But you haven't seen it yet, despite the attacks on Estonia. Cyberwar is warfare in cyberspace. And warfare involves massive death and destruction. When you see it, you'll know it. -- Bruce Schneier, Nov. 2007 -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [patch 0/6] DM9000: Several fixes/cleanups for the DM9000A controller
Ben Warren wrote: > Wolfgang, > > Is the merge window open for the rest of today, or is it closed? If > open, I'll look at this patch set later today and act on it. Otherwise > this goes into the 'for later' bin. > Hi, this patch does not work on the trizeps board. I get the following error: $ tftp 0xa001 u-boot.bin dm9000 i/o: 0x800, id: 0x9a46 DM9000: running in 32 bit mode MAC: 00:50:c2:3b:8f:0a operating at 100M full duplex mode TFTP from server 192.168.2.14; our IP address is 192.168.2.77 Filename 'u-boot.bin'. Load address: 0xa001 Loading: DM9000 error: status check fail: 0x6d I have only applied the patches and tried a quick check...The bus width is correctly recognized but there is no data transfer. However, the ethernet controller works with the current driver: $ tftp 0xa001 u-boot.bin dm9000 i/o: 0x800, id: 0x9a46 MAC: 00:50:c2:3b:8f:0a operating at 100M full duplex mode TFTP from server 192.168.2.14; our IP address is 192.168.2.77 Filename 'u-boot.bin'. Load address: 0xa001 Loading: ### done Bytes transferred = 160180 (271b4 hex) Regards, Stefano -- = 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: [EMAIL PROTECTED] = - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH V2] ARM: Add support for Lyrtech SFF-SDRboard (ARM926EJS)
Hi Hugo, > Detlev Zundel wrote: >> Hi Wolfgang and Hugo, >> >> while studying the mail footer of Hugo, I found a slightly >> problematic phrasing: >> >>> THIS MESSAGE AND ALL... >> >> So Hugo, please get rid of that message or I will advise Wolfgang to >> heed your footer... > > I got rid of the message. Thanks a lot. > Is everything fine with the patch now? I did not see any negative reaction to your 5th version[1], so its up to the custodian now. What do you say Jean-Christophe? Cheers Detlev [1] http://news.gmane.org/find-root.php?message_id=%3c1211486942%2d8348%2d1%2dgit%2dsend%2demail%2dhugo.villeneuve%40lyrtech.com%3e -- Der Kluge tue gleich anfangs, was der Dumme erst am Ende. --- Baltasar Gracian -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [Patch 02/17 Try 2] U-Boot-V2:Common:Clock Handle caseofclockrollover for get_time_ns
Sascha, > -Original Message- > From: Sascha Hauer [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 03, 2008 10:14 AM > To: Menon, Nishanth > Cc: u-boot-users@lists.sourceforge.net; Laurent Desnogues; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; Gopinath, Thara; Kamat, Nishant; Syed Mohammed, Khasim > Subject: Re: [Patch 02/17] U-Boot-V2:Common:Clock Handle caseofclockrollover > for get_time_ns > > > Output will be: > > delta1=0xFFF8 maskdelta1=0xFFF0 delta2=0x > > > > What we will get now is maskdelta1, while delta2 is the right value. > > It's not that I thought of the code by myself, I just looked into the > kernel and it's exactly like this in the kernel code. So you either just > found a kernel bug or we both understand something wrong. Here is a revisit of this patch. The change will ensure cycle_now and last will be masked. Signed-off-by: Nishanth Menon<[EMAIL PROTECTED]> --- common/clock.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: u-boot.v2/common/clock.c === --- u-boot.v2.orig/common/clock.c 2007-10-10 21:50:14.0 -0500 +++ u-boot.v2/common/clock.c2008-06-03 11:16:05.0 -0500 @@ -41,7 +41,7 @@ uint64_t ns_offset; /* read clocksource: */ -cycle_now = cs->read(); + cycle_now = cs->read() & cs->mask; /* calculate the delta since the last call: */ cycle_delta = (cycle_now - cs->cycle_last) & cs->mask; - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] Pull request: nand-flash (updated)
The following changes since commit 1f1554841a4c8e069d331176f0c3059fb2bb8280: Wolfgang Denk (1): Merge branch 'master' of /home/wd/git/u-boot/custodians are available in the git repository at: git://www.denx.de/git/u-boot-nand-flash.git master Dirk Behme (1): nand: Correct NAND erase percentage output Scott Wood (3): NAND: Provide a sane default for NAND_MAX_CHIPS. Make onenand_uboot.h self-sufficient. Remove prototypes of nand_init() in favor of including nand.h. Stuart Wood (1): env_nand.c: Added bad block management for environment variables common/env_nand.c| 119 +++--- drivers/mtd/nand/nand_util.c |7 +++ include/linux/mtd/nand.h |4 ++ include/onenand_uboot.h |5 ++ lib_arm/board.c | 10 +--- lib_ppc/board.c |4 +- lib_sh/board.c |2 +- 7 files changed, 119 insertions(+), 32 deletions(-) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] uboot version for 8572CDS
On Jun 3, 2008, at 9:41 AM, Morrison, Tom wrote: > I am wondering if there is a development branch that contains > support for the Freescale 8572CDS…Looking in the latest uboot > version (1.3.3) there is support for sbc8641 & sbc8548 – but > no specific support for a sbc8572? Such questions are best asked on the u-boot list. I'm not aware of a 8572 CDS, we do have a 8572 DS. And no, there isn't a public tree w/support for this board. The only code is either the FSL BSP or internal to FSL at this point. - k - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [Patch 10/17] U-Boot-V2:ARM:OMAP3: Add support for OMAP and Cortex A8
> -Original Message- > From: Laurent Desnogues [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 03, 2008 3:23 AM > To: Menon, Nishanth; u-boot-users@lists.sourceforge.net; Laurent Desnogues; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; Gopinath, Thara; Kamat, Nishant; Syed > Mohammed, > Khasim > Subject: Re: [Patch 10/17] U-Boot-V2:ARM:OMAP3: Add support for OMAP and > Cortex A8 > > On Tue, Jun 3, 2008 at 10:12 AM, Sascha Hauer <[EMAIL PROTECTED]> wrote: > > Is this really ARMCORTEX specific or arm v7 specific? > > This is not Cortex A8 specific, it's v7-A (and hopefully will be the same > in upcoming ARM architectures). Probably ARM arch definitions need to be cleaned up a bit more? Granularity is restricted today to ARM CPU and not architecture.. > > > Anyway, this looks > > like the start of another ifdef mess, we should create some generic hook > > here. > > You could perhaps mimic the way the Linux kernel handles cache stuff > for the various ARM architectures. Probably not the extent.. but yes to a lesser extent might be helpful. Common code will still exist, probably CP15 stuff can move out? Regards, Nishanth Menon - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [Patch 11/17 Try 2] U-Boot-V2:ARM:OMAP3: Add support for OMAP3Silicon files
Sascha, > -Original Message- > From: Sascha Hauer [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 03, 2008 3:18 AM > To: Menon, Nishanth > Cc: Peter Pearse; u-boot-users@lists.sourceforge.net; Kamat, Nishant; Syed > Mohammed, Khasim; Laurent > Desnogues; [EMAIL PROTECTED] > Subject: Re: [Patch 11/17 Try 2] U-Boot-V2:ARM:OMAP3: Add support for > OMAP3Silicon files > > On Wed, May 28, 2008 at 10:39:07AM -0500, Menon, Nishanth wrote: > > As per the thread in: > > http://www.nabble.com/-Patch-06-17--U-Boot-V2%3AARM%3A-Add-sizes.h-tt17372780.html#a17372780 > > sizes.h dependency is removed from the following patch. This is a > > resubmission. > > > > This patch introduces support for OMAP3430 - provides for generic OMAP3 > > files. > > Looks ok to me besides the occurences of return with the value in > brackets. > > Sascha Arrgh.. I have myself to blame for inconsistent return styles. Probably we need an equivalent of checkpatch and a Lindent for U-Boot v2? I suppose the right style is return without brackets? Regards, Nishanth Menon - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [Patch 09/17] U-Boot-V2:Serial: Add support for NS16550Driver.`
Sascha,
> -Original Message-
> From: Sascha Hauer [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 03, 2008 3:09 AM
> To: Menon, Nishanth
> Cc: u-boot-users@lists.sourceforge.net; Laurent Desnogues; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; Gopinath, Thara; Kamat, Nishant; Syed Mohammed, Khasim
> Subject: Re: [Patch 09/17] U-Boot-V2:Serial: Add support for NS16550Driver.`
>
> > +
> > +config DRIVER_SERIAL_NS16550_REG_SIZE_8_BITS_PAD_TO_64
> > + bool "8 bit register Padded to 64 bit"
> > + help
> > + Say Y here if you are using a 8 bit register padded to 64 bits for
> > NS16550
> > +endchoice
>
> Please have a look at drivers/net/dm9000.c for an example on how to pass
> data between the board and a driver via platform_data. The kconfig approach
> for this has several disadvantages. The user is presented a couple of
> options which he better does not change because it would break the driver.
> Another problem is that you cannot connect two ns16550 with different
> register widths on one board (though that's an unlikely case).
My problem is not sending data size APIs. I do not want to maintain multiple
different structures variable if I can avoid at compile time. I do pass the
clock and other variant params through platform_data. If I don't use the
#defines, I need to do something like the following:
Pass reg_type thru platform data, then for each set of access, do:
switch (reg_type) {
case REG_SIZE_8_BITS_PAD_TO_64:
com_port_8_pad64->thr = something;
break;
case REG_SIZE_8_BITS_PAD_TO_32:
com_port_8_pad32->thr = something;
break;
etc..
a) code size increases
b) un-necessary overhead in performance.
c) resultant code is going to look dirty.
NS16550_t com_port as in the current implementation is easy to read and looks
neat. I believe the Kconfig is a neater approach.
If I plan on doing a #define, it will still be need a higher level definition
to decide on this.
The next alternative will be to:
#define THR1 1 (for all platforms)
And each platform code implement:
unsigned long reg_read(unsigned reg)
{
readb(silicon_offset_of_reg);
}
And pass these access functions over platform_data.
I really don't like the overhead in doing this.
>
> > +
> > +/* Forward declaration */
> > +static unsigned int ns16550_calc_divisor(struct console_device *cdev,
> > +unsigned int baudrate);
> > +static void ns16550_serial_init_port(struct console_device *cdev);
> > +static void ns16550_putc(struct console_device *cdev, char c);
> > +static int ns16550_getc(struct console_device *cdev);
> > +static int ns16550_tstc(struct console_device *cdev);
> > +static int ns16550_setbaudrate(struct console_device *cdev, int baud_rate);
> > +static int ns16550_probe(struct device_d *dev);
> > +static int ns16550_serial_init(void);
>
> Please reorder the functions to get rid of these declarations. It helps
> reading the code when you know that a functions definition is before
> its usage.
It is a matter of a programmer preference I believe. Folks who do a topdown
reading prefer to have the high level callers on tops and dig to the lower
levels. Others do a bottom up reading. Yeah probably doing a bottom to top
approach could be cleaner in this case. Will fix.
> > + cdev->f_caps = plat->f_caps;
>
> Ok, you know about platform_data ;). I suggest that you put the register
> access functions there.
I really would not like to do it as explained above. The code will end up
unreadable at the end of it.
Regards,
Nishanth Menon
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [Patch 05/17] U-Boot-V2:ARM: Introduce capability to havedifferent stack/malloc area
On Tue, Jun 03, 2008 at 10:04:29AM -0500, Menon, Nishanth wrote: > Sascha, > > > -Original Message- > > From: Sascha Hauer [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, June 03, 2008 3:08 AM > > To: Menon, Nishanth > > Cc: u-boot-users@lists.sourceforge.net; Laurent Desnogues; [EMAIL > > PROTECTED]; > > [EMAIL PROTECTED]; Gopinath, Thara; Kamat, Nishant; Syed Mohammed, Khasim > > Subject: Re: [Patch 05/17] U-Boot-V2:ARM: Introduce capability to > > havedifferent stack/malloc area > > > > This patch rises an issue we currently have in U-Boot-v2: We have as > > many stack/memory strategies as we have architectures :( > > > > Instead of modifying this for one architecture I would prefer something > > like this (currently no implementation, only kconfig). > > Would this solve your issues? > Yes, :). Couple of minor comments though.. > > > diff --git a/common/Kconfig b/common/Kconfig > > index 79a3684..d764482 100644 > > --- a/common/Kconfig > > +++ b/common/Kconfig > > @@ -19,13 +19,66 @@ menu "General Settings " > > config BOARDINFO > > string > > > > +menu "memory layout " > Curious: Why have the extra space? I see this in other places too.. it kind > of messes up the defconfig with trailing spaces :(. It's just to align the menu arrows nicely under each other in make menuconfig. > > > +choice > > + prompt "select stack base policy" > s/stack/heap? > > + depends on HAVE_CONFIGURABLE_MALLOC > > + > > +config MALLOC_BASE_DEFAULT > > + bool > > + prompt "place stack before U-Boot" > s/stack/heap? No, this is the processor stack... > > + > > +config MALLOC_BASE_FIXED > > + bool > > + prompt "manually assign a malloc base" > > + ...while this is the malloc heap. > > +endchoice > > + > > +endmenu > > + > Ack to the changes. This should be good for me. > > Regards, > Nishanth Menon > -- Pengutronix e.K. - Linux Solutions for Science and Industry --- Kontakt-Informationen finden Sie im Header dieser Mail oder auf der Webseite -> http://www.pengutronix.de/impressum/ <- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [Patch 02/17] U-Boot-V2:Common:Clock Handle case ofclockrollover for get_time_ns
On Tue, Jun 03, 2008 at 09:39:51AM -0500, Menon, Nishanth wrote:
> Sascha,
> > -Original Message-
> > From: Sascha Hauer [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, June 03, 2008 9:15 AM
> > To: Menon, Nishanth
> > Cc: u-boot-users@lists.sourceforge.net; Laurent Desnogues; [EMAIL
> > PROTECTED];
> > [EMAIL PROTECTED]; Gopinath, Thara; Kamat, Nishant; Syed Mohammed, Khasim
> > Subject: Re: [Patch 02/17] U-Boot-V2:Common:Clock Handle case
> > ofclockrollover for get_time_ns
> >
> > > Assumptions made:
> > > A) The bits masked out by cs->mask will remain constant. This may not be
> > > true.
> >
> > Eh? That's why they are masked out.
> For the sake of discussion:
> unsigned int now = 0x120;
> unsigned int last = 0x128;
> unsigned int mask = 0xFFF0;
> unsigned int delta1 = now - last;
> unsigned int delta2 = (now & mask) - (last & mask);
> printf ("delta1=0x%08X maskdelta1=0x%08X delta2=0x%08X\n",delta1, delta1 &
> mask, delta2);
>
> Output will be:
> delta1=0xFFF8 maskdelta1=0xFFF0 delta2=0x
>
> What we will get now is maskdelta1, while delta2 is the right value.
It's not that I thought of the code by myself, I just looked into the
kernel and it's exactly like this in the kernel code. So you either just
found a kernel bug or we both understand something wrong.
>
> >
> > > B) Roll over assume the min is 0 and max is cs->mask. This need not be
> > > the case.
> > > It would be good to be explicit.
> >
> > Do you know any counter that does not start counting from zero? If you
> I do not. I am just being a paranoid idiot ;)..
>
> > have, noone prevents you from substracting the value in your clocksource
> > read function.
> Max however is assumed to be cs->mask then. We could have timers which can be
> configured for ticking till a configured max. probably my paranoia kicking in
> again?
If that's the only possibility to program this timer then go out and
kill the chip designer ;)
Sascha
>
> Regards,
> Nishanth Menon
>
--
Pengutronix e.K. - Linux Solutions for Science and Industry
---
Kontakt-Informationen finden Sie im Header dieser Mail oder
auf der Webseite -> http://www.pengutronix.de/impressum/ <-
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [Patch 08/17] U-Boot-V2:Commands: Unbreak loadb support
Sascha,
> -Original Message-
> From: Sascha Hauer [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 03, 2008 3:09 AM
> To: Menon, Nishanth
> Cc: u-boot-users@lists.sourceforge.net; Laurent Desnogues; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; Gopinath, Thara; Kamat, Nishant; Syed Mohammed, Khasim
> Subject: Re: [Patch 08/17] U-Boot-V2:Commands: Unbreak loadb support
> > config CMD_LOADB
> > - depends on BROKEN
> > select CRC16
> > - tristate
> > + bool
> > prompt "loadb"
>
> Is there a reason why loadb does not work as module? othwerwise you
> should leave this to tristate.
Hmm... modules in U-Boot v2!!! :).. I missed that.. apologies -> I am still in
the learning process.. I should try that out..
> > /* pre-set offset from $loadaddr */
> > - if ((s = getenv("loadaddr")) != NULL) {
> > + s = (char *) getenv("loadaddr");
> > + if (s != NULL)
> > offset = simple_strtoul(s, NULL, 16);
>
> Parameters to commands should go via command line arguments and not
> environment variables. The use of environment variables makes it
> necessary to read the documentation (if it's there ;) or the source to
> make it clear which commands use which variables. Command line options
> on the other hand are self explaining via the -h option.
>
> Normally commands like tftp work on a file and not on a plain memory
> address. The serial commands should behave the same.
Yes. Indeed, I am facing the same issue when I thought about using nand
download over uart.. using device and ability to give an offset within the
device will be the proper approach. I will redo this patch.
> > +
> > +/* Convert a character to lower case */
> > +static inline char _tolower(char c)
> > +{
> > + if ((c >= 'A') && (c <= 'Z'))
> > + c = (c - 'A') + 'a';
> > + return c;
> > +}
>
> We already have a tolower function in include/linux/ctype.h
Yep. It has been a blind port. Will fix it as part of the revisit of this patch.
Regards,
Nishanth Menon
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [patch 0/6] DM9000: Several fixes/cleanups for the DM9000A controller
Wolfgang, Is the merge window open for the rest of today, or is it closed? If open, I'll look at this patch set later today and act on it. Otherwise this goes into the 'for later' bin. regards, Ben Remy Bohmer wrote: > The following 6 patches contain several fixes and cleanups for > the DM9000A network controller. It turned out that the U-boot DM9000 driver > was not working with this particular version of the DM9000 series. > > At low speeds (10MBit) it was sometimes capable of getting a peer-2-peer > connection, but 100MBit did not work at all, also connecting the board to a > corporate network did not work at any speed. > > Looking deeper at the code it turned out that many things where done > different than recommended in the Application Notes and Programming Guides > for these controllers. Doing the things as recommended solved the > problems with the DM9000A. > > The complete series has been tested with the Atmel AT91SAM9261-EK, and > a custom board, with the DM9000[A|E|EP] controllers. > > Signed-off-by: Remy Bohmer <[EMAIL PROTECTED]> > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [Patch 05/17] U-Boot-V2:ARM: Introduce capability to havedifferent stack/malloc area
Sascha, > -Original Message- > From: Sascha Hauer [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 03, 2008 3:08 AM > To: Menon, Nishanth > Cc: u-boot-users@lists.sourceforge.net; Laurent Desnogues; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; Gopinath, Thara; Kamat, Nishant; Syed Mohammed, Khasim > Subject: Re: [Patch 05/17] U-Boot-V2:ARM: Introduce capability to > havedifferent stack/malloc area > > This patch rises an issue we currently have in U-Boot-v2: We have as > many stack/memory strategies as we have architectures :( > > Instead of modifying this for one architecture I would prefer something > like this (currently no implementation, only kconfig). > Would this solve your issues? Yes, :). Couple of minor comments though.. > diff --git a/common/Kconfig b/common/Kconfig > index 79a3684..d764482 100644 > --- a/common/Kconfig > +++ b/common/Kconfig > @@ -19,13 +19,66 @@ menu "General Settings " > config BOARDINFO > string > > +menu "memory layout " Curious: Why have the extra space? I see this in other places too.. it kind of messes up the defconfig with trailing spaces :(. > +choice > + prompt "select stack base policy" s/stack/heap? > + depends on HAVE_CONFIGURABLE_MALLOC > + > +config MALLOC_BASE_DEFAULT > + bool > + prompt "place stack before U-Boot" s/stack/heap? > + > +config MALLOC_BASE_FIXED > + bool > + prompt "manually assign a malloc base" > + > +endchoice > + > +endmenu > + Ack to the changes. This should be good for me. Regards, Nishanth Menon - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [Patch 02/17] U-Boot-V2:Common:Clock Handle case ofclockrollover for get_time_ns
Sascha,
> -Original Message-
> From: Sascha Hauer [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 03, 2008 9:15 AM
> To: Menon, Nishanth
> Cc: u-boot-users@lists.sourceforge.net; Laurent Desnogues; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; Gopinath, Thara; Kamat, Nishant; Syed Mohammed, Khasim
> Subject: Re: [Patch 02/17] U-Boot-V2:Common:Clock Handle case ofclockrollover
> for get_time_ns
>
> > Assumptions made:
> > A) The bits masked out by cs->mask will remain constant. This may not be
> > true.
>
> Eh? That's why they are masked out.
For the sake of discussion:
unsigned int now = 0x120;
unsigned int last = 0x128;
unsigned int mask = 0xFFF0;
unsigned int delta1 = now - last;
unsigned int delta2 = (now & mask) - (last & mask);
printf ("delta1=0x%08X maskdelta1=0x%08X delta2=0x%08X\n",delta1, delta1 &
mask, delta2);
Output will be:
delta1=0xFFF8 maskdelta1=0xFFF0 delta2=0x
What we will get now is maskdelta1, while delta2 is the right value.
>
> > B) Roll over assume the min is 0 and max is cs->mask. This need not be the
> > case.
> > It would be good to be explicit.
>
> Do you know any counter that does not start counting from zero? If you
I do not. I am just being a paranoid idiot ;)..
> have, noone prevents you from substracting the value in your clocksource
> read function.
Max however is assumed to be cs->mask then. We could have timers which can be
configured for ticking till a configured max. probably my paranoia kicking in
again?
Regards,
Nishanth Menon
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [Patch 02/17] U-Boot-V2:Common:Clock Handle case of clockrollover for get_time_ns
On Tue, Jun 03, 2008 at 07:47:25AM -0500, Menon, Nishanth wrote: > Sascha, > > -Original Message- > > From: Sascha Hauer [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, June 03, 2008 3:08 AM > > To: Menon, Nishanth > > Cc: u-boot-users@lists.sourceforge.net; Laurent Desnogues; [EMAIL > > PROTECTED]; > > [EMAIL PROTECTED]; Gopinath, Thara; Kamat, Nishant; Syed Mohammed, Khasim > > Subject: Re: [Patch 02/17] U-Boot-V2:Common:Clock Handle case of > > clockrollover for get_time_ns > > > -cycle_delta = (cycle_now - cs->cycle_last) & cs->mask; > > > > Look closer, the rollover case is handled implicitly by the unsigned > > arithmetics. > Agreed for logic when mask is the max value attainable. > IMHO, The concept of cs->mask is messy. We do need a min, max and a mask. > When: > cycle_now = cs->read(); > cs->cycle_last = cycle_now; Now cycle_now == cs->cycle_last... > (cycle_now - cs->cycle_last) & cs->mask is wrong. ...so 0 & cs->mask = 0 This makes no sense, but this is not the order of execution in current code. > Assumptions made: > A) The bits masked out by cs->mask will remain constant. This may not be true. Eh? That's why they are masked out. > B) Roll over assume the min is 0 and max is cs->mask. This need not be the > case. > It would be good to be explicit. Do you know any counter that does not start counting from zero? If you have, noone prevents you from substracting the value in your clocksource read function. > > > > You are right, we do not have a possibility to detect a double rollover > > without interrupts. Normally this is not an issue as this code is used > > in timeout polling loops where the current time is polled often enough. > > Anyway, maybe some comment should mention that this function is not > > useful to measure long periods of time where 'long' is highly > > architecture specific. > > > Yes, there are indenting issue + no doxygen documentation.. It helps as > clock_source is critical implementation required in the system. > > Regards, > Nishanth Menon > -- Pengutronix e.K. - Linux Solutions for Science and Industry --- Kontakt-Informationen finden Sie im Header dieser Mail oder auf der Webseite -> http://www.pengutronix.de/impressum/ <- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [patch] Get rid of annoying/superfluous bad-checksum warning message
U-boot can complain a lot about 'checksum bad' when it is attached to the
network.
It is annoying for ordinary users who start to doubt the network connection
in general when they see messages like this.
This is caused by the routine NetCksumOk() which cannot handle IP-headers longer
than 20 bytes. Those packages can be ignored anyway by U-boot, so we trash them
now before checking the checksum.
Signed-off-by: Remy Bohmer <[EMAIL PROTECTED]>
---
net/net.c |4
1 file changed, 4 insertions(+)
Index: u-boot-git-03062008/net/net.c
===
--- u-boot-git-03062008.orig/net/net.c 2008-06-03 14:40:20.0 +0200
+++ u-boot-git-03062008/net/net.c 2008-06-03 15:46:21.0 +0200
@@ -1407,6 +1407,10 @@ NetReceive(volatile uchar * inpkt, int l
if (ip->ip_off & htons(0x1fff)) { /* Can't deal w/ fragments */
return;
}
+ /* can't deal with headers > 20 bytes */
+ if ((ip->ip_hl_v & 0x0f) > 0x05) {
+ return;
+ }
if (!NetCksumOk((uchar *)ip, IP_HDR_SIZE_NO_UDP / 2)) {
puts ("checksum bad\n");
return;
--
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [patch 3/6] DM9000: improve eth_send() routine
The eth_send routine of the U-boot DM9000x driver does not match the
DM9000 or DM9000A application notes/programming guides.
This change improves the stability of the DM9000A network controller.
This change has been tested with DM9000A, DM9000E, DM9000EP.
Signed-off-by: Remy Bohmer <[EMAIL PROTECTED]>
---
drivers/net/dm9000x.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
Index: u-boot-git-03062008/drivers/net/dm9000x.c
===
--- u-boot-git-03062008.orig/drivers/net/dm9000x.c 2008-06-03
15:19:03.0 +0200
+++ u-boot-git-03062008/drivers/net/dm9000x.c 2008-06-03 15:19:10.0
+0200
@@ -42,6 +42,9 @@ v1.2 03/18/2003 Weilun Huang
- Added autodetect of databus width.
- Made debug code compile again.
+ - Adapt eth_send such that it matches the DM9000*
+ application notes. Needed to make it work properly
+ for DM9000A.
These changes are tested with DM9000{A,EP,E} together
with a 200MHz Atmel AT91SAM92161 core
@@ -505,15 +508,16 @@ int
eth_send(volatile void *packet, int length)
{
char *data_ptr;
- u32 tmplen, i;
int tmo;
struct board_info *db = &dm9000_info;
DM9000_DMP_PACKET("eth_send", packet, length);
+ DM9000_iow(DM9000_ISR, IMR_PTM); /* Clear Tx bit in ISR */
+
/* Move data to DM9000 TX RAM */
data_ptr = (char *) packet;
- DM9000_outb(DM9000_MWCMD, DM9000_IO);
+ DM9000_outb(DM9000_MWCMD, DM9000_IO); /* Prepare for TX-data */
/* push the data to the TX-fifo */
(db->outblk)(data_ptr, length);
@@ -523,16 +527,19 @@ eth_send(volatile void *packet, int leng
DM9000_iow(DM9000_TXPLH, (length >> 8) & 0xff);
/* Issue TX polling command */
- DM9000_iow(DM9000_TCR, TCR_TXREQ); /* Cleared after TX complete */
+ DM9000_iow(DM9000_TCR, TCR_TXREQ); /* Cleared after TX complete */
/* wait for end of transmission */
tmo = get_timer(0) + 5 * CFG_HZ;
- while (DM9000_ior(DM9000_TCR) & TCR_TXREQ) {
+ while ( !(DM9000_ior(DM9000_NSR) & (NSR_TX1END | NSR_TX2END)) ||
+ !(DM9000_ior(DM9000_ISR) & IMR_PTM) ) {
if (get_timer(0) >= tmo) {
printf("transmission timeout\n");
break;
}
}
+ DM9000_iow(DM9000_ISR, IMR_PTM); /* Clear Tx bit in ISR */
+
DM9000_DBG("transmit done\n\n");
return 0;
}
--
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [patch 0/6] DM9000: Several fixes/cleanups for the DM9000A controller
The following 6 patches contain several fixes and cleanups for the DM9000A network controller. It turned out that the U-boot DM9000 driver was not working with this particular version of the DM9000 series. At low speeds (10MBit) it was sometimes capable of getting a peer-2-peer connection, but 100MBit did not work at all, also connecting the board to a corporate network did not work at any speed. Looking deeper at the code it turned out that many things where done different than recommended in the Application Notes and Programming Guides for these controllers. Doing the things as recommended solved the problems with the DM9000A. The complete series has been tested with the Atmel AT91SAM9261-EK, and a custom board, with the DM9000[A|E|EP] controllers. Signed-off-by: Remy Bohmer <[EMAIL PROTECTED]> -- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [patch 6/6] DM9000: Some minor code cleanups
Some lines of the U-boot DM9000x driver are longer than 80 characters, or
need some other minor cleanup.
Signed-off-by: Remy Bohmer <[EMAIL PROTECTED]>
---
drivers/net/dm9000x.c | 41 ++---
1 file changed, 26 insertions(+), 15 deletions(-)
Index: u-boot-git-03062008/drivers/net/dm9000x.c
===
--- u-boot-git-03062008.orig/drivers/net/dm9000x.c 2008-06-03
15:19:17.0 +0200
+++ u-boot-git-03062008/drivers/net/dm9000x.c 2008-06-03 15:19:20.0
+0200
@@ -51,6 +51,7 @@ v1.2 03/18/2003 Weilun Huang > 8) & 0xff));
DM9000_iow(DM9000_EPCR, 0xa); /* Issue phyxcer write command */
- udelay(500);/* Wait write complete */
+ udelay(500);/* Wait write complete */
DM9000_iow(DM9000_EPCR, 0x0); /* Clear phyxcer write command */
DM9000_DBG("phy_write(reg:0x%x, value:0x%x)\n", reg, value);
}
-#endif /* CONFIG_DRIVER_DM9000 */
+#endif /* CONFIG_DRIVER_DM9000 */
--
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [patch 4/6] DM9000: Improve eth_reset() routine
According to the application notes of the DM9000 v1.22 chapter 5.2 bullet 2, the reset procedure must be done twice to properly reset the DM9000 by means of software. This errata is not needed anymore for the DM9000A, but it does not bother it. This change has been tested with DM9000A, DM9000E, DM9000EP. Signed-off-by: Remy Bohmer <[EMAIL PROTECTED]> --- drivers/net/dm9000x.c | 34 +++--- 1 file changed, 31 insertions(+), 3 deletions(-) Index: u-boot-git-22052008/drivers/net/dm9000x.c === --- u-boot-git-22052008.orig/drivers/net/dm9000x.c 2008-06-03 12:06:57.0 +0200 +++ u-boot-git-22052008/drivers/net/dm9000x.c 2008-06-03 12:07:51.0 +0200 @@ -45,6 +45,8 @@ v1.2 03/18/2003 Weilun Huang not responding\n"); } /* Initilize dm9000 board -- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [patch 5/6] DM9000: Make driver work properly for DM9000A
The DM9000A network controller does not work with the U-boot DM9000x driver.
Analysis showed that many incoming packets are lost.
The DM9000A Application Notes V1.20 (section 5.6.1) recommend that the poll to
check for a valid rx packet be done on the interrupt status register, not
directly by performing the dummy read and the rx status check as is currently
the case in the u-boot driver.
When the recommended poll is done as suggested the driver starts working
correctly on 10Mbit/HD, but on 100MBit/FD packets come in faster so that there
can be more than 1 package in the fifo at the same time.
The driver must perform the rx-status check in a loop and read and handle all
packages until there is no more left _after_ the interrupt RX flag is set.
This change has been tested with DM9000A, DM9000E, DM9000EP.
Signed-off-by: Remy Bohmer <[EMAIL PROTECTED]>
---
drivers/net/dm9000x.c | 95 --
1 file changed, 55 insertions(+), 40 deletions(-)
Index: u-boot-git-03062008/drivers/net/dm9000x.c
===
--- u-boot-git-03062008.orig/drivers/net/dm9000x.c 2008-06-03
15:19:13.0 +0200
+++ u-boot-git-03062008/drivers/net/dm9000x.c 2008-06-03 15:19:17.0
+0200
@@ -40,6 +40,10 @@ v1.2 03/18/2003 Weilun Huang
06/03/2008 Remy Bohmer <[EMAIL PROTECTED]>
+ - Fixed the driver to work with DM9000A.
+ (check on ISR receive status bit before reading the
+ FIFO as described in DM9000 programming guide and
+ application notes)
- Added autodetect of databus width.
- Made debug code compile again.
- Adapt eth_send such that it matches the DM9000*
@@ -598,53 +602,64 @@ eth_rx(void)
u16 RxStatus, RxLen = 0;
struct board_info *db = &dm9000_info;
- /* Check packet ready or not */
- DM9000_ior(DM9000_MRCMDX); /* Dummy read */
- rxbyte = DM9000_inb(DM9000_DATA); /* Got most updated data */
- if (rxbyte == 0)
+ /* Check packet ready or not, we must check
+ the ISR status first for DM9000A */
+ if (!(DM9000_ior(DM9000_ISR) & 0x01)) /* Rx-ISR bit must be set. */
return 0;
- /* Status check: this byte must be 0 or 1 */
- if (rxbyte > 1) {
- DM9000_iow(DM9000_RCR, 0x00); /* Stop Device */
- DM9000_iow(DM9000_ISR, 0x80); /* Stop INT request */
- DM9000_DBG("rx status check: %d\n", rxbyte);
- }
- DM9000_DBG("receiving packet\n");
+ DM9000_iow(DM9000_ISR, 0x01); /* clear PR status latched in bit 0 */
- /* A packet ready now & Get status/length */
- DM9000_outb(DM9000_MRCMD, DM9000_IO);
+ /* There is _at least_ 1 package in the fifo, read them all */
+ for (;;) {
+ DM9000_ior(DM9000_MRCMDX); /* Dummy read */
+
+ /* Get most updated data */
+ rxbyte = DM9000_inb(DM9000_DATA);
+
+ /* Status check: this byte must be 0 or 1 */
+ if (rxbyte > DM9000_PKT_RDY) {
+ DM9000_iow(DM9000_RCR, 0x00); /* Stop Device */
+ DM9000_iow(DM9000_ISR, 0x80); /* Stop INT request */
+ printf("DM9000 error: status check fail: 0x%x\n",
+ rxbyte);
+ return 0;
+ }
- (db->rx_status)(&RxStatus, &RxLen);
+ if (rxbyte != DM9000_PKT_RDY)
+ return 0; /* No packet received, ignore */
- DM9000_DBG("rx status: 0x%04x rx len: %d\n", RxStatus, RxLen);
+ DM9000_DBG("receiving packet\n");
- /* Move data from DM9000 */
- /* Read received packet from RX SRAM */
- (db->inblk)(rdptr, RxLen);
-
- if ((RxStatus & 0xbf00) || (RxLen < 0x40)
- || (RxLen > DM9000_PKT_MAX)) {
- if (RxStatus & 0x100) {
- printf("rx fifo error\n");
- }
- if (RxStatus & 0x200) {
- printf("rx crc error\n");
- }
- if (RxStatus & 0x8000) {
- printf("rx length error\n");
- }
- if (RxLen > DM9000_PKT_MAX) {
- printf("rx length too big\n");
- dm9000_reset();
- }
- } else {
- DM9000_DMP_PACKET("eth_rx", rdptr, RxLen);
+ /* A packet ready now & Get status/length */
+ (db->rx_status)(&RxStatus, &RxLen);
- /* Pass to upper layer */
- DM9000_DBG("passing packet to upper layer\n");
- NetReceive(NetRxPackets[0], RxLen);
- return RxLen;
+ DM9000_DBG("rx status: 0x%04x rx len: %d
[U-Boot-Users] [patch 2/6] DM9000: repair debug logging
It seems that the debugging code of the DM9000x driver in U-boot has not been
compiled for a long time, because it cannot compile...
Also rearranged some loglines to get more useful info while debugging.
Signed-off-by: Remy Bohmer <[EMAIL PROTECTED]>
---
drivers/net/dm9000x.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
Index: u-boot-git-03062008/drivers/net/dm9000x.c
===
--- u-boot-git-03062008.orig/drivers/net/dm9000x.c 2008-06-03
15:18:57.0 +0200
+++ u-boot-git-03062008/drivers/net/dm9000x.c 2008-06-03 15:19:03.0
+0200
@@ -41,6 +41,7 @@ v1.2 03/18/2003 Weilun Huang
- Added autodetect of databus width.
+ - Made debug code compile again.
These changes are tested with DM9000{A,EP,E} together
with a 200MHz Atmel AT91SAM92161 core
@@ -65,10 +66,22 @@ TODO: Homerun NIC and longrun NIC are no
/* #define CONFIG_DM9000_DEBUG */
#ifdef CONFIG_DM9000_DEBUG
-#define DM9000_DBG(fmt,args...) printf(fmt ,##args)
-#else /* */
+#define DM9000_DBG(fmt,args...) printf(fmt, ##args)
+#define DM9000_DMP_PACKET(func,packet,length) \
+ do { \
+ int i; \
+ printf(func ": length: %d\n", length); \
+ for (i = 0; i < length; i++) { \
+ if (i % 8 == 0) \
+ printf("\n%s: %02x: ", func, i);\
+ printf("%02x ", ((unsigned char *) packet)[i]); \
+ } printf("\n"); \
+ } while(0)
+#else
#define DM9000_DBG(fmt,args...)
-#endif /* */
+#define DM9000_DMP_PACKET(func,packet,length)
+#endif
+
enum DM9000_PHY_mode { DM9000_10MHD = 0, DM9000_100MHD =
1, DM9000_10MFD = 4, DM9000_100MFD = 5, DM9000_AUTO =
8, DM9000_1M_HPNA = 0x10
@@ -133,7 +146,7 @@ dump_regs(void)
DM9000_DBG("TSRII (0x04): %02x\n", DM9000_ior(4));
DM9000_DBG("RCR (0x05): %02x\n", DM9000_ior(5));
DM9000_DBG("RSR (0x06): %02x\n", DM9000_ior(6));
- DM9000_DBG("ISR (0xFE): %02x\n", DM9000_ior(ISR));
+ DM9000_DBG("ISR (0xFE): %02x\n", DM9000_ior(DM9000_ISR));
DM9000_DBG("\n");
}
#endif
@@ -496,12 +509,7 @@ eth_send(volatile void *packet, int leng
int tmo;
struct board_info *db = &dm9000_info;
- DM9000_DBG("eth_send: length: %d\n", length);
- for (i = 0; i < length; i++) {
- if (i % 8 == 0)
- DM9000_DBG("\nSend: 02x: ", i);
- DM9000_DBG("%02x ", ((unsigned char *) packet)[i]);
- } DM9000_DBG("\n");
+ DM9000_DMP_PACKET("eth_send", packet, length);
/* Move data to DM9000 TX RAM */
data_ptr = (char *) packet;
@@ -596,6 +604,7 @@ eth_rx(void)
dm9000_reset();
}
} else {
+ DM9000_DMP_PACKET("eth_rx", rdptr, RxLen);
/* Pass to upper layer */
DM9000_DBG("passing packet to upper layer\n");
@@ -666,7 +675,7 @@ phy_read(int reg)
val = (DM9000_ior(DM9000_EPDRH) << 8) | DM9000_ior(DM9000_EPDRL);
/* The read data keeps on REG_0D & REG_0E */
- DM9000_DBG("phy_read(%d): %d\n", reg, val);
+ DM9000_DBG("phy_read(0x%x): 0x%x\n", reg, val);
return val;
}
@@ -686,6 +695,6 @@ phy_write(int reg, u16 value)
DM9000_iow(DM9000_EPCR, 0xa); /* Issue phyxcer write command */
udelay(500);/* Wait write complete */
DM9000_iow(DM9000_EPCR, 0x0); /* Clear phyxcer write command */
- DM9000_DBG("phy_write(reg:%d, value:%d)\n", reg, value);
+ DM9000_DBG("phy_write(reg:0x%x, value:0x%x)\n", reg, value);
}
#endif /* CONFIG_DRIVER_DM9000 */
--
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [patch 1/6] DM9000: Add data bus-width auto detection.
The U-boot DM9000x driver contains a compile time bus-width definition for
the databus connected to the network controller.
This compile check makes the code unclear, inflexible and is unneccessary.
It can be asked to the network controller what its bus-width is by reading bits
6 and 7 of the interrupt status register.
The linux kernel already uses a runtime mechanism to determine this bus-width,
so the implementation below looks somewhat like that implementation.
This change has been tested with DM9000A, DM9000E, DM9000EP.
Signed-off-by: Remy Bohmer <[EMAIL PROTECTED]>
---
drivers/net/dm9000x.c | 187 ++--
include/configs/scb9328.h |4
include/configs/trizepsiv.h |4
3 files changed, 129 insertions(+), 66 deletions(-)
Index: u-boot-git-03062008/drivers/net/dm9000x.c
===
--- u-boot-git-03062008.orig/drivers/net/dm9000x.c 2008-06-03
14:40:20.0 +0200
+++ u-boot-git-03062008/drivers/net/dm9000x.c 2008-06-03 15:18:57.0
+0200
@@ -36,7 +36,13 @@ v1.2 03/18/2003 Weilun Huang
+ 12/15/2003 Initial port to u-boot by
+ Sascha Hauer <[EMAIL PROTECTED]>
+
+ 06/03/2008 Remy Bohmer <[EMAIL PROTECTED]>
+ - Added autodetect of databus width.
+ These changes are tested with DM9000{A,EP,E} together
+ with a 200MHz Atmel AT91SAM92161 core
TODO: Homerun NIC and longrun NIC are not functional, only internal at the
moment.
@@ -84,8 +90,11 @@ typedef struct board_info {
u8 device_wait_reset; /* device state */
u8 nic_type;/* NIC type */
unsigned char srom[128];
-} board_info_t;
-board_info_t dmfe_info;
+ void (*outblk)(void *data_ptr, int count);
+ void (*inblk)(void *data_ptr, int count);
+ void (*rx_status)(u16 *RxStatus, u16 *RxLen);
+ } board_info_t;
+static board_info_t dm9000_info;
/* For module input parameter */
static int media_mode = DM9000_AUTO;
@@ -127,7 +136,81 @@ dump_regs(void)
DM9000_DBG("ISR (0xFE): %02x\n", DM9000_ior(ISR));
DM9000_DBG("\n");
}
-#endif /* */
+#endif
+
+static void dm9000_outblk_8bit(void *data_ptr, int count)
+{
+ int i;
+ for (i = 0; i < count; i++)
+ DM9000_outbu8 *) data_ptr)[i] & 0xff), DM9000_DATA);
+}
+
+static void dm9000_outblk_16bit(void *data_ptr, int count)
+{
+ int i;
+ u32 tmplen = (count + 1) / 2;
+
+ for (i = 0; i < tmplen; i++)
+ DM9000_outw(((u16 *) data_ptr)[i], DM9000_DATA);
+}
+static void dm9000_outblk_32bit(void *data_ptr, int count)
+{
+ int i;
+ u32 tmplen = (count + 3) / 4;
+
+ for (i = 0; i < tmplen; i++)
+ DM9000_outl(((u32 *) data_ptr)[i], DM9000_DATA);
+}
+
+static void dm9000_inblk_8bit(void *data_ptr, int count)
+{
+ int i;
+ for (i = 0; i < count; i++)
+ ((u8 *) data_ptr)[i] = DM9000_inb(DM9000_DATA);
+}
+
+static void dm9000_inblk_16bit(void *data_ptr, int count)
+{
+ int i;
+ u32 tmplen = (count + 1) / 2;
+
+ for (i = 0; i < tmplen; i++)
+ ((u16 *) data_ptr)[i] = DM9000_inw(DM9000_DATA);
+}
+static void dm9000_inblk_32bit(void *data_ptr, int count)
+{
+ int i;
+ u32 tmplen = (count + 3) / 4;
+
+ for (i = 0; i < tmplen; i++)
+ ((u32 *) data_ptr)[i] = DM9000_inl(DM9000_DATA);
+}
+
+static void dm9000_rx_status_32bit(u16 *RxStatus, u16 *RxLen)
+{
+ u32 tmpdata = DM9000_inl(DM9000_DATA);
+
+ DM9000_outb(DM9000_MRCMD, DM9000_IO);
+
+ *RxStatus = tmpdata;
+ *RxLen = tmpdata >> 16;
+}
+
+static void dm9000_rx_status_16bit(u16 *RxStatus, u16 *RxLen)
+{
+ DM9000_outb(DM9000_MRCMD, DM9000_IO);
+
+ *RxStatus = DM9000_inw(DM9000_DATA);
+ *RxLen = DM9000_inw(DM9000_DATA);
+}
+
+static void dm9000_rx_status_8bit(u16 *RxStatus, u16 *RxLen)
+{
+ DM9000_outb(DM9000_MRCMD, DM9000_IO);
+
+ *RxStatus = DM9000_inb(DM9000_DATA) + (DM9000_inb(DM9000_DATA) << 8);
+ *RxLen = DM9000_inb(DM9000_DATA) + (DM9000_inb(DM9000_DATA) << 8);
+}
/*
Search DM9000 board, allocate space and register it
@@ -236,7 +319,7 @@ program_dm9802(void)
static void
identify_nic(void)
{
- struct board_info *db = &dmfe_info; /* Point a board information
structure */
+ struct board_info *db = &dm9000_info;
u16 phy_reg3;
DM9000_iow(DM9000_NCR, NCR_EXT_PHY);
phy_reg3 = phy_read(3);
@@ -274,12 +357,46 @@ int
eth_init(bd_t * bd)
{
int i, oft, lnk;
+ u8 io_mode;
+ struct board_info *db = &dm9000_info;
+
DM9000_DBG("eth_init()\n");
/* RESET device */
dm9000_reset();
dm9000_probe();
+ /* Auto-detect 8/16/32 bit mode, ISR Bit 6+7 indicate bus width */
+ io_mode = DM9000_ior(D
[U-Boot-Users] [patch] Fix for CONFIG_BOOTP_RANDOM_DELAY does not compile.
The option CONFIG_BOOTP_RANDOM_DELAY does not compile, because of a missing 'extern' inside the net/bootp.h header. Signed-off-by: Remy Bohmer <[EMAIL PROTECTED]> --- net/bootp.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: u-boot-git-22052008/net/bootp.h === --- u-boot-git-22052008.orig/net/bootp.h2008-05-22 22:30:29.0 +0200 +++ u-boot-git-22052008/net/bootp.h 2008-06-03 10:24:19.0 +0200 @@ -60,7 +60,7 @@ extern ulong BootpID;/* ID of cur BOOT extern charBootFile[128]; /* Boot file name */ extern int BootpTry; #ifdef CONFIG_BOOTP_RANDOM_DELAY -ulong seed1, seed2; /* seed for random BOOTP delay */ +extern ulong seed1, seed2; /* seed for random BOOTP delay */ #endif -- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [Patch 02/17] U-Boot-V2:Common:Clock Handle case of clockrollover for get_time_ns
Sascha, > -Original Message- > From: Sascha Hauer [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 03, 2008 3:08 AM > To: Menon, Nishanth > Cc: u-boot-users@lists.sourceforge.net; Laurent Desnogues; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; Gopinath, Thara; Kamat, Nishant; Syed Mohammed, Khasim > Subject: Re: [Patch 02/17] U-Boot-V2:Common:Clock Handle case of > clockrollover for get_time_ns > > -cycle_delta = (cycle_now - cs->cycle_last) & cs->mask; > > Look closer, the rollover case is handled implicitly by the unsigned > arithmetics. Agreed for logic when mask is the max value attainable. IMHO, The concept of cs->mask is messy. We do need a min, max and a mask. When: cycle_now = cs->read(); cs->cycle_last = cycle_now; (cycle_now - cs->cycle_last) & cs->mask is wrong. Assumptions made: A) The bits masked out by cs->mask will remain constant. This may not be true. B) Roll over assume the min is 0 and max is cs->mask. This need not be the case. It would be good to be explicit. > > You are right, we do not have a possibility to detect a double rollover > without interrupts. Normally this is not an issue as this code is used > in timeout polling loops where the current time is polled often enough. > Anyway, maybe some comment should mention that this function is not > useful to measure long periods of time where 'long' is highly > architecture specific. > Yes, there are indenting issue + no doxygen documentation.. It helps as clock_source is critical implementation required in the system. Regards, Nishanth Menon - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] ata: fix the bug of signature updated
The driver need wait for the device updating signature
to host. if we don't wait for it, the driver can not detect
the device(disk) when the system power up.
Signed-off-by: Dave Liu <[EMAIL PROTECTED]>
---
drivers/block/fsl_sata.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/block/fsl_sata.c b/drivers/block/fsl_sata.c
index d14f5bc..d441a30 100644
--- a/drivers/block/fsl_sata.c
+++ b/drivers/block/fsl_sata.c
@@ -248,6 +248,10 @@ int init_sata(int dev)
else
printf(" %s ", sata->name);
+ /* Wait PHY RDY signal changed for 500ms */
+ ata_wait_register(®->hstatus, HSTATUS_PHY_RDY,
+ HSTATUS_PHY_RDY, 500);
+
/* Check PHYRDY */
val32 = in_le32(®->hstatus);
if (val32 & HSTATUS_PHY_RDY) {
@@ -258,6 +262,10 @@ int init_sata(int dev)
return -1;
}
+ /* Wait for signature updated, which is 1st D2H */
+ ata_wait_register(®->hstatus, HSTATUS_SIGNATURE,
+ HSTATUS_SIGNATURE, 1);
+
if (val32 & HSTATUS_SIGNATURE) {
sig = in_le32(®->sig);
debug("Signature updated, the sig =%08x\n\r", sig);
--
1.5.4
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [Patch 13/17] U-Boot-V2:ARM:OMAP3: Add generic Headers
On Wed, May 21, 2008 at 11:29:45AM -0500, Menon, Nishanth wrote: > This patch adds the generic OMAP headers and OMAP specific headers. > > Signed-off-by: Nishanth Menon<[EMAIL PROTECTED]> Looks mostly ok, only one comment... > > --- > include/asm-arm/arch-omap/bits.h | 65 > include/asm-arm/arch-omap/control.h | 98 ++ > include/asm-arm/arch-omap/gpmc.h | 105 +++ > include/asm-arm/arch-omap/intc.h | 58 > include/asm-arm/arch-omap/omap3-mux.h | 423 > ++ > include/asm-arm/arch-omap/omap3-silicon.h | 130 + > include/asm-arm/arch-omap/omap3-smx.h | 69 > include/asm-arm/arch-omap/sdrc.h | 97 ++ > include/asm-arm/arch-omap/silicon.h | 38 ++ > include/asm-arm/arch-omap/sys_info.h | 97 ++ > include/asm-arm/arch-omap/syslib.h| 39 ++ > include/asm-arm/arch-omap/timers.h| 60 > include/asm-arm/arch-omap/wdt.h | 49 +++ > 13 files changed, 1328 insertions(+) > > Index: u-boot-v2.git/include/asm-arm/arch-omap/bits.h > === > --- /dev/null 1970-01-01 00:00:00.0 + > +++ u-boot-v2.git/include/asm-arm/arch-omap/bits.h2008-05-20 > 18:11:10.0 -0500 > @@ -0,0 +1,65 @@ > +/** > + * @file > + * > + * @brief Provide a bunch of common BIT access macros > + * > + * FileName: include/asm-arm/arch-omap/bits.h > + * > + * Originally from > http://linux.omap.com/pub/bootloader/3430sdp/u-boot-v1.tar.gz > + */ > +/* > + * (C) Copyright 2004-2008 > + * Texas Instruments, > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation; either version 2 of > + * the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, > + * MA 02111-1307 USA > + */ > +#ifndef __ASM_OMAP_BITS_H > +#define __ASM_OMAP_BITS_H > + > +#define BIT0 (1<<0) > +#define BIT1 (1<<1) > +#define BIT2 (1<<2) > +#define BIT3 (1<<3) > +#define BIT4 (1<<4) > +#define BIT5 (1<<5) > +#define BIT6 (1<<6) > +#define BIT7 (1<<7) > +#define BIT8 (1<<8) > +#define BIT9 (1<<9) > +#define BIT10 (1<<10) > +#define BIT11 (1<<11) > +#define BIT12 (1<<12) > +#define BIT13 (1<<13) > +#define BIT14 (1<<14) > +#define BIT15 (1<<15) > +#define BIT16 (1<<16) > +#define BIT17 (1<<17) > +#define BIT18 (1<<18) > +#define BIT19 (1<<19) > +#define BIT20 (1<<20) > +#define BIT21 (1<<21) > +#define BIT22 (1<<22) > +#define BIT23 (1<<23) > +#define BIT24 (1<<24) > +#define BIT25 (1<<25) > +#define BIT26 (1<<26) > +#define BIT27 (1<<27) > +#define BIT28 (1<<28) > +#define BIT29 (1<<29) > +#define BIT30 (1<<30) > +#define BIT31 (1<<31) Please don't do this. It does not really make the code shorter and every programmer understands hwat 1<<0 means + he does not have to search through header files for the definition of BIT0. > + > +#endif /*__ASM_OMAP_BITS_H */ > Index: u-boot-v2.git/include/asm-arm/arch-omap/control.h > === > --- /dev/null 1970-01-01 00:00:00.0 + > +++ u-boot-v2.git/include/asm-arm/arch-omap/control.h 2008-05-20 > 18:11:10.0 -0500 > @@ -0,0 +1,98 @@ > +/** > + * @file > + * @brief This file contains the Control register defines > + * > + * FileName: include/asm-arm/arch-omap/control.h > + * > + * Originally from Linux kernel: > + * http://linux.omap.com/pub/kernel/3430zoom/linux-ldp-v1.0b.tar.gz > + * include/asm-arm/arch-omap/omap34xx.h > + */ > +/* > + * (C) Copyright 2008 > + * Texas Instruments, > + * Nishanth Menon <[EMAIL PROTECTED]> > + * > + * Copyright (C) 2007 Texas Instruments, > + * Copyright (C) 2007 Nokia Corporation. > + * > + * 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 Temp
Re: [U-Boot-Users] [Patch 10/17] U-Boot-V2:ARM:OMAP3: Add support for OMAP and Cortex A8
On Tue, Jun 3, 2008 at 10:12 AM, Sascha Hauer <[EMAIL PROTECTED]> wrote: > Is this really ARMCORTEX specific or arm v7 specific? This is not Cortex A8 specific, it's v7-A (and hopefully will be the same in upcoming ARM architectures). > Anyway, this looks > like the start of another ifdef mess, we should create some generic hook > here. You could perhaps mimic the way the Linux kernel handles cache stuff for the various ARM architectures. Laurent - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [Patch 11/17 Try 2] U-Boot-V2:ARM:OMAP3: Add support for OMAP3 Silicon files
On Wed, May 28, 2008 at 10:39:07AM -0500, Menon, Nishanth wrote: > As per the thread in: > http://www.nabble.com/-Patch-06-17--U-Boot-V2%3AARM%3A-Add-sizes.h-tt17372780.html#a17372780 > sizes.h dependency is removed from the following patch. This is a > resubmission. > > This patch introduces support for OMAP3430 - provides for generic OMAP3 files. Looks ok to me besides the occurences of return with the value in brackets. Sascha > > Signed-off-by: Nishanth Menon<[EMAIL PROTECTED]> > > --- > arch/arm/mach-omap/Kconfig | 65 + > arch/arm/mach-omap/Makefile| 25 ++ > arch/arm/mach-omap/omap3_core.S| 101 + > arch/arm/mach-omap/omap3_generic.c | 415 > + > arch/arm/mach-omap/syslib.c| 97 > 5 files changed, 703 insertions(+) > > Index: u-boot-v2.git/arch/arm/mach-omap/Kconfig > === > --- /dev/null 1970-01-01 00:00:00.0 + > +++ u-boot-v2.git/arch/arm/mach-omap/Kconfig 2008-05-28 10:33:04.0 > -0500 > @@ -0,0 +1,65 @@ > +# > +# OMAP Architecture specific features > +# > +# (C) Copyright 2008 > +# Texas Instruments, > +# Nishanth Menon <[EMAIL PROTECTED]> > +# > +# 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 > + > +menu "OMAP Features" > + depends on ARCH_OMAP > + > +choice > + prompt "Select OMAP Variant" > + > +config ARCH_OMAP3 > + bool "OMAP3" > + select ARMCORTEXA8 > + select ARCH_HAS_LOWLEVEL_INIT > + help > + Say Y here if you are using Texas Instrument's OMAP343x based platform > + > +endchoice > + > +config OMAP_CONFIG_STACKSIZE > + prompt "STACKSIZE" > + hex > + default 0x0002 > + help > + Select the Stack Size > + > +config OMAP_MALLOC_LEN > + prompt "MALLOC LENGTH" > + hex > + default 0x1000 > + help > + Select the Malloc Length > + > +config ARCH_TEXT_BASE > + prompt "ARCH TEXT BASE" > + hex > + default 0x80e8 > + help > + Select the load address > + > +config OMAP3_CLOCK_CONFIG > + depends on ARCH_OMAP > + bool "Clock Configuration" > + help > + Say Y here if you like to have OMAP3 Clock configuration done. > + > +endmenu > Index: u-boot-v2.git/arch/arm/mach-omap/Makefile > === > --- /dev/null 1970-01-01 00:00:00.0 + > +++ u-boot-v2.git/arch/arm/mach-omap/Makefile 2008-05-28 10:19:05.0 > -0500 > @@ -0,0 +1,25 @@ > +# OMAP Architecture Makefile > +# > +# (C) Copyright 2008 > +# Texas Instruments, > +# Nishanth Menon <[EMAIL PROTECTED]> > +# > +# 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 > +# > +obj-$(CONFIG_ARCH_OMAP) += syslib.o > +obj-$(CONFIG_OMAP_CLOCK_SOURCE_S32K) += s32k_clksource.o > +obj-$(CONFIG_ARCH_OMAP3) += omap3_core.o omap3_generic.o > +obj-$(CONFIG_OMAP3_CLOCK_CONFIG) += omap3_clock_core.o omap3_clock.o > Index: u-boot-v2.git/arch/arm/mach-omap/omap3_core.S > === > --- /dev/null 1970-01-01 00:00:00.0 + > +++ u-boot-v2.git/arch/arm/mach-omap/omap3_core.S 2008-05-28 > 10:19:05.0 -0500 > @@ -0,0 +1,101 @@ > +/** > + * @file > + * @brief Provide Architecture level Initialization > + * > + * FileName: arch/arm/mach-omap/omap3_core.S > + * > + * This provides OMAP3 Architecture initialization. Among these, > + * @li OMAP ROM Code is located in SRAM, we can piggy back on > + * the same addresses > + * @li If clock initialization is required, call the
Re: [U-Boot-Users] [Patch 10/17] U-Boot-V2:ARM:OMAP3: Add support for OMAP and Cortex A8
On Wed, May 21, 2008 at 11:28:55AM -0500, Menon, Nishanth wrote: > This patch adds support for OMAP3 platforms. This is mainly to setup the > infrastructure. ARMV7 requires a different I/D cache cleanup code which is > introduced in this patch. > > Thanks to Laurent in pointing out the Cortex-A8 D-Cache issue with my first > rev patch. > > Signed-off-by: Nishanth Menon<[EMAIL PROTECTED]> > > --- > arch/arm/Kconfig | 24 > arch/arm/Makefile|6 + > arch/arm/cpu/Makefile|1 > arch/arm/cpu/start-arm.S | 54 > +++ > 4 files changed, 84 insertions(+), 1 deletion(-) > > Index: u-boot-v2.git/arch/arm/Kconfig > === > --- u-boot-v2.git.orig/arch/arm/Kconfig 2008-05-20 18:20:54.0 > -0500 > +++ u-boot-v2.git/arch/arm/Kconfig2008-05-21 10:41:17.0 -0500 > @@ -47,6 +47,9 @@ > config ARM926EJS > bool > > +config ARMCORTEXA8 > + bool > + > # i.MX1, i.MXL, i.MX27 and i.MX31 are quite similar and thus > # handled in one arch > config ARCH_IMX > @@ -74,6 +77,10 @@ > bool > select ARM926EJS > > +config ARCH_OMAP > + bool > +# ARM versions used varies on based on OMAP versions > + > choice > prompt "Select your board" > > @@ -135,6 +142,13 @@ > Say Y here if your are using Phytec's phyCORE-i.MX31 (pcm037) equipped > with a Freescale i.MX31 Processor > > +config MACH_OMAP > + bool "Texas Instruments' OMAP based platforms" > + select ARCH_OMAP > + select MACH_CAN_MODIFY_MALLOC_START > + help > + Say Y if you are using Texas Instrument's OMAP based platforms > + > endchoice > > config IMX_CLKO > @@ -144,8 +158,9 @@ > The i.MX SoCs have a Pin which can output different reference > frequencies. > Say y here if you want to have the clko command which lets you select > the > frequency to output on this pin. > - > + > source arch/arm/mach-netx/Kconfig > +source arch/arm/mach-omap/Kconfig > > menu "Arm specific settings " > > @@ -190,6 +205,13 @@ > Provide the alternate malloc start address. Remember that the area > that will be used will be (this address) to (this address - > CFG_MALLOC_LEN - CONFIG_STACKSIZE) > > +config ARMCORTEXA8_DCACHE_SKIP > + bool "Skip DCache Invlidate" > + depends on ARMCORTEXA8 > + default n > + help > + If your architecture configuration uses some other method of > disabling caches, enable this > + So that the D-Cache invalidation logic is skipped > endmenu > > source common/Kconfig > Index: u-boot-v2.git/arch/arm/Makefile > === > --- u-boot-v2.git.orig/arch/arm/Makefile 2008-05-20 18:20:54.0 > -0500 > +++ u-boot-v2.git/arch/arm/Makefile 2008-05-20 18:20:54.0 -0500 > @@ -6,6 +6,7 @@ > machine-$(CONFIG_ARCH_IMX) := imx > machine-$(CONFIG_ARCH_NETX) := netx > machine-$(CONFIG_ARCH_AT91RM9200) := at91rm9200 > +machine-$(CONFIG_ARCH_OMAP):= omap > board-$(CONFIG_MACH_MX1ADS) := mx1ads > board-$(CONFIG_MACH_ECO920) := eco920 > board-$(CONFIG_MACH_SCB9328):= scb9328 > @@ -13,6 +14,7 @@ > board-$(CONFIG_MACH_IMX27ADS) := imx27ads > board-$(CONFIG_MACH_NXDB500) := netx > board-$(CONFIG_MACH_PCM037) := pcm037 > +board-$(CONFIG_MACH_OMAP) := omap > # FIXME "cpu-y" never used on ARM! > cpu-$(CONFIG_ARM920T) := arm920t > cpu-$(CONFIG_ARM926EJS):= arm926ejs > @@ -22,6 +24,10 @@ > CPPFLAGS += -mabi=apcs-gnu -DTEXT_BASE=$(TEXT_BASE) -P > CFLAGS += -Os > > +# Add architecture specific flags > +ifeq ($(CONFIG_ARMCORTEXA8),y) > +CPPFLAGS += -march=armv7a > +endif > > # Add cleanup flags > CPPFLAGS += -fdata-sections -ffunction-sections > Index: u-boot-v2.git/arch/arm/cpu/Makefile > === > --- u-boot-v2.git.orig/arch/arm/cpu/Makefile 2008-05-20 18:18:43.0 > -0500 > +++ u-boot-v2.git/arch/arm/cpu/Makefile 2008-05-20 18:20:54.0 > -0500 > @@ -6,4 +6,5 @@ > # > obj-$(CONFIG_ARM920T) += start-arm.o > obj-$(CONFIG_ARM926EJS) += start-arm.o > +obj-$(CONFIG_ARMCORTEXA8) += start-arm.o > obj-$(CONFIG_ARCH_IMX31) += start-arm.o > Index: u-boot-v2.git/arch/arm/cpu/start-arm.S > === > --- u-boot-v2.git.orig/arch/arm/cpu/start-arm.S 2008-05-20 > 18:20:54.0 -0500 > +++ u-boot-v2.git/arch/arm/cpu/start-arm.S2008-05-21 10:44:14.0 > -0500 > @@ -143,12 +143,66 @@ > #ifdef CONFIG_ARCH_HAS_LOWLEVEL_INIT > bl arch_init_lowlevel > #endif > + > +#ifdef CONFIG_ARMCORTEXA8 > + /* > + * Invalidate v7 I/D caches > + */ > + mov r0, #0 /* set up for MCR */ > +
Re: [U-Boot-Users] [Patch 09/17] U-Boot-V2:Serial: Add support for NS16550 Driver.`
On Wed, May 21, 2008 at 11:28:29AM -0500, Menon, Nishanth wrote: > This introduces support for NS16550 and related OMAP support. This driver is > a port from Uboot v1 driver from OMAP's Uboot tree. > OMAP U-Boot V1 source is available here: > http://linux.omap.com/pub/bootloader/3430sdp/u-boot-v1.tar.gz > > Signed-off-by: Nishanth Menon<[EMAIL PROTECTED]> > > --- > drivers/serial/Kconfig | 42 ++ > drivers/serial/Makefile |1 > drivers/serial/serial_ns16550.c | 248 > > drivers/serial/serial_ns16550.h | 183 + > include/ns16550.h | 46 +++ > 5 files changed, 520 insertions(+) > > Index: u-boot-v2.git/drivers/serial/Kconfig > === > --- u-boot-v2.git.orig/drivers/serial/Kconfig 2008-05-20 17:59:26.0 > -0500 > +++ u-boot-v2.git/drivers/serial/Kconfig 2008-05-20 18:02:28.0 > -0500 > @@ -24,4 +24,46 @@ > depends on BLACKFIN > default y > bool "Blackfin serial driver" > + > +config DRIVER_SERIAL_NS16550 > + default n > + bool "NS16550 serial driver" > + help > + Enable this to get support for NS16550 based serial devices > +choice > + prompt "NS16550 register size" > + depends on DRIVER_SERIAL_NS16550 > + > +config DRIVER_SERIAL_NS16550_REG_SIZE_8_BITS > + bool "8 bit register" > + help > + Say Y here if you are using a 8 bit register for NS16550 > + > +config DRIVER_SERIAL_NS16550_REG_SIZE_16_BITS > + bool "16 bit register" > + help > + Say Y here if you are using a 16 bit register for NS16550 > + > +config DRIVER_SERIAL_NS16550_REG_SIZE_32_BITS > + bool "32 bit register" > + help > + Say Y here if you are using a 32 bit register for NS16550 > + > +config DRIVER_SERIAL_NS16550_REG_SIZE_8_BITS_PAD_TO_32 > + bool "8 bit register Padded to 32 bit" > + help > + Say Y here if you are using a 8 bit register padded to 32 bits for > NS16550 > + > +config DRIVER_SERIAL_NS16550_REG_SIZE_8_BITS_PAD_TO_64 > + bool "8 bit register Padded to 64 bit" > + help > + Say Y here if you are using a 8 bit register padded to 64 bits for > NS16550 > +endchoice Please have a look at drivers/net/dm9000.c for an example on how to pass data between the board and a driver via platform_data. The kconfig approach for this has several disadvantages. The user is presented a couple of options which he better does not change because it would break the driver. Another problem is that you cannot connect two ns16550 with different register widths on one board (though that's an unlikely case). > + > +config DRIVER_SERIAL_NS16550_OMAP_EXTENSIONS > + bool "OMAP Extensions for NS16550" > + depends on DRIVER_SERIAL_NS16550 > + depends on ARCH_OMAP > + help > + Say Y here if you are using OMAP extensions to NS16550 > endmenu > Index: u-boot-v2.git/drivers/serial/Makefile > === > --- u-boot-v2.git.orig/drivers/serial/Makefile2008-05-20 > 17:59:25.0 -0500 > +++ u-boot-v2.git/drivers/serial/Makefile 2008-05-20 18:02:28.0 > -0500 > @@ -10,3 +10,4 @@ > obj-$(CONFIG_DRIVER_SERIAL_LINUX_COMSOLE)+= linux_console.o > obj-$(CONFIG_DRIVER_SERIAL_MPC5XXX) += serial_mpc5xxx.o > obj-$(CONFIG_DRIVER_SERIAL_BLACKFIN) += serial_blackfin.o > +obj-$(CONFIG_DRIVER_SERIAL_NS16550) += serial_ns16550.o > Index: u-boot-v2.git/drivers/serial/serial_ns16550.c > === > --- /dev/null 1970-01-01 00:00:00.0 + > +++ u-boot-v2.git/drivers/serial/serial_ns16550.c 2008-05-20 > 18:04:13.0 -0500 > @@ -0,0 +1,248 @@ > +/** > + * @file > + * @brief NS16550 Driver implementation > + * > + * FileName: drivers/serial/serial_ns16550.c > + * > + * NS16550 support > + * Modified from U-Boot V1 drivers/serial.c and drivers/ns16550.c > + * originally from linux source (arch/ppc/boot/ns16550.c) > + * modified to use CFG_ISA_MEM and new defines > + */ > +/* > + * (C) Copyright 2008 > + * Texas Instruments, > + * Nishanth Menon <[EMAIL PROTECTED]> > + * > + * (C) Copyright 2000 > + * Rob Taylor, Flying Pig Systems. [EMAIL PROTECTED] > + * > + * 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. >
Re: [U-Boot-Users] [Patch 08/17] U-Boot-V2:Commands: Unbreak loadb support
On Wed, May 21, 2008 at 11:28:12AM -0500, Menon, Nishanth wrote:
> This patch provides support for loadb and loady and enables the broken
> feature. xyzModem.c is brought in from U-Boot V1, Lindent, checkpatch and
> sparse cleaned :).
>
> Signed-off-by: Nishanth Menon<[EMAIL PROTECTED]>
>
> ---
> commands/Kconfig| 14
> commands/Makefile |1
> commands/loadb.c| 182 ---
> commands/xyzModem.c | 792
>
> lib/Makefile|1
> 5 files changed, 932 insertions(+), 58 deletions(-)
>
> Index: u-boot-v2.git/commands/Kconfig
> ===
> --- u-boot-v2.git.orig/commands/Kconfig 2008-05-20 17:53:55.0
> -0500
> +++ u-boot-v2.git/commands/Kconfig2008-05-20 17:54:18.0 -0500
> @@ -121,13 +121,23 @@
> endmenu
>
> menu "memory"
> +config LOAD_ADDR
> + depends on CMD_LOADB
> + hex
> + prompt "default load address"
> + help
> + Provide the default load address for the platform
>
> config CMD_LOADB
> - depends on BROKEN
> select CRC16
> - tristate
> + bool
> prompt "loadb"
Is there a reason why loadb does not work as module? othwerwise you
should leave this to tristate.
>
> +config CMD_LOADY
> + select CRC16
> + bool
> + prompt "loady"
> +
> config CMD_LOADS
> depends on BROKEN
> tristate
> Index: u-boot-v2.git/commands/Makefile
> ===
> --- u-boot-v2.git.orig/commands/Makefile 2008-05-20 17:53:55.0
> -0500
> +++ u-boot-v2.git/commands/Makefile 2008-05-20 17:54:18.0 -0500
> @@ -1,5 +1,6 @@
> obj-$(CONFIG_CMD_BOOTM) += bootm.o
> obj-$(CONFIG_CMD_LOADB) += loadb.o xyzModem.o
> +obj-$(CONFIG_CMD_LOADY) += loadb.o xyzModem.o
> obj-$(CONFIG_CMD_LOADS) += loads.o
> obj-$(CONFIG_CMD_ECHO) += echo.o
> obj-$(CONFIG_CMD_MEMORY) += mem.o
> Index: u-boot-v2.git/commands/loadb.c
> ===
> --- u-boot-v2.git.orig/commands/loadb.c 2008-05-20 17:53:55.0
> -0500
> +++ u-boot-v2.git/commands/loadb.c2008-05-20 17:58:05.0 -0500
> @@ -1,3 +1,12 @@
> +/**
> + * @file
> + * @brief LoadB and LoadY support.
> + *
> + * Provides loadb (over Kermit) and LoadY(over Y modem) support to download
> + * images.
> + *
> + * FileName: commands/loadb.c
> + */
> /*
> * (C) Copyright 2000-2004
> * Wolfgang Denk, DENX Software Engineering, [EMAIL PROTECTED]
> @@ -26,14 +35,16 @@
> */
> #include
> #include
> -#include
> -#include
> -#include
> #include
> +#include
> +#include
> +#include
> +#include
>
> -DECLARE_GLOBAL_DATA_PTR;
>
> +#ifdef CONFIG_CMD_LOADY
> static ulong load_serial_ymodem (ulong offset);
> +#endif
>
> #define XON_CHAR17
> #define XOFF_CHAR 19
> @@ -50,36 +61,70 @@
> #define tochar(x) ((char) (((x) + SPACE) & 0xff))
> #define untochar(x) ((int) (((x) - SPACE) & 0xff))
>
> -extern int os_data_count;
> -extern int os_data_header[8];
>
> static void set_kerm_bin_mode(unsigned long *);
> static int k_recv(void);
> static ulong load_serial_bin (ulong offset);
>
>
> -char his_eol;/* character he needs at end of packet */
> -int his_pad_count; /* number of pad chars he needs */
> -char his_pad_char; /* pad chars he needs */
> -char his_quote; /* quote chars he'll use */
> +static char his_eol;/* character he needs at end of packet */
> +static int his_pad_count; /* number of pad chars he needs */
> +static char his_pad_char; /* pad chars he needs */
> +static char his_quote; /* quote chars he'll use */
> +
>
> -int do_load_serial_bin (cmd_tbl_t *cmdtp, int argc, char *argv[])
> +/**
> + * @brief returns current used console device
> + *
> + * @return console device which is registered with CONSOLE_STDIN and
> + * CONSOLE_STDOUT
> + */
> +static struct console_device *get_current_console(void)
> +{
> + struct console_device *cdev;
> + /*
> + * Assumption to have BOTH CONSOLE_STDIN AND STDOUT in the
> + * same output console
> + */
> + for_each_console(cdev) {
> + if ((cdev->f_active & (CONSOLE_STDIN | CONSOLE_STDOUT)))
> + return cdev;
> + }
> + return NULL;
> +}
> +
> +/**
> + * @brief provide the loadb(Kermit) or loadY mode support
> + *
> + * @param cmdtp
> + * @param argc
> + * @param argv
> + *
> + * @return success or failure
> + */
> +static int do_load_serial_bin(cmd_tbl_t *cmdtp, int argc, char *argv[])
> {
> ulong offset = 0;
> ulong addr;
> int load_baudrate, current_baudrate;
> int rcode = 0;
> char *s;
> + struct console_device *cdev = get_current_console();
> + if (NULL == cdev) {
> + printf("No device wit
Re: [U-Boot-Users] [Patch 05/17] U-Boot-V2:ARM: Introduce capability to have different stack/malloc area
On Wed, May 21, 2008 at 11:26:25AM -0500, Menon, Nishanth wrote: > The default setup of ARM memory allocation is as follows: > > Stack Area > > Heap Area > --- > _u_boot_start > Rest of U-Boot.. > > This is an excellent strategy to catch stack overflow and memory buffer > overflow issues. However, in conditions where: > a) U-Boot is automatically loaded by h/w in the default location without a > writable memory area above it, this will crash, > b) Multiple non-contiguous memory areas available in system (e.g. SRAM and > SDRAM), but the area where U-Boot is loaded is restricted in size and cannot > fit the required heap and stack areas. > In these cases, we need to have ability to move the Heap and stack to the > area of our choice. This patch introduces CONFIG_MALLOC_START for machine > configurations which require this. > This would need to be enabled only if MACH_CAN_MODIFY_MALLOC_START is defined > by the machine configurations that desire it. I have clubbed both heap and > stack area to still catch some of those overflow issues. This patch rises an issue we currently have in U-Boot-v2: We have as many stack/memory strategies as we have architectures :( Instead of modifying this for one architecture I would prefer something like this (currently no implementation, only kconfig). Would this solve your issues? regards, Sascha diff --git a/common/Kconfig b/common/Kconfig index 79a3684..d764482 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -19,13 +19,66 @@ menu "General Settings " config BOARDINFO string +menu "memory layout " + config TEXT_BASE + depends on HAVE_CONFIGURABLE_TEXT_BASE prompt "TEXT_BASE" hex default ARCH_TEXT_BASE help The Address U-Boot gets linked at. +choice + prompt "select stack base policy" + depends on HAVE_CONFIGURABLE_STACK + default STACK_BASE_FIXED + +config STACK_BASE_DEFAULT + bool "place stack before malloc space" + +config STACK_BASE_FIXED + bool "manually assign a stack base" + +endchoice + +config STACK_BASE + depends on STACK_BASE_FIXED + hex + prompt "STACK_BASE" + +config STACK_SIZE + hex + depends on HAVE_CONFIGURABLE_STACK + default 0x8000 + prompt "Stack size" + +choice + prompt "select stack base policy" + depends on HAVE_CONFIGURABLE_MALLOC + +config MALLOC_BASE_DEFAULT + bool + prompt "place stack before U-Boot" + +config MALLOC_BASE_FIXED + bool + prompt "manually assign a malloc base" + +endchoice + +config MALLOC_BASE + depends on MALLOC_BASE_FIXED + hex + prompt "MALLOC_BASE" + +config MALLOC_SIZE + hex + depends on HAVE_CONFIGURABLE_MALLOC + default 0x40 + prompt "malloc area size" +endmenu + config BROKEN bool prompt "Prompt for broken or incomplete code" -- Pengutronix e.K. - Linux Solutions for Science and Industry --- Kontakt-Informationen finden Sie im Header dieser Mail oder auf der Webseite -> http://www.pengutronix.de/impressum/ <- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [Patch 02/17] U-Boot-V2:Common:Clock Handle case of clock rollover for get_time_ns
On Wed, May 21, 2008 at 11:25:15AM -0500, Menon, Nishanth wrote:
> get_time_ns does a simplistic delta = cycle_now - cycle_last. It is possible
> that the h/w counter reached max and reset back to 0.
> This patch addresses this issue by checking for rollover condition.
>
> NOTE 1: This does not guarantee that you cannot confuse get_time_ns. You
> could possibly wait for two reset cycles and then get a messed up value.
> To fix that we may need interrupt mode timer tick - something on the lines of
> jiffies on linux.
> NOTE 2: the question of cs->mask is not clear. if the mask is for the tick,
> then it is better done with (cycle_now & cs->mask) - (cs->cycle_last &
> cs->mask). Do we need min and max for register read?
>
> Signed-off-by: Nishanth Menon<[EMAIL PROTECTED]>
>
> ---
> common/clock.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> Index: u-boot-v2.git/common/clock.c
> ===
> --- u-boot-v2.git.orig/common/clock.c 2008-05-20 17:19:44.0 -0500
> +++ u-boot-v2.git/common/clock.c 2008-05-20 17:26:31.0 -0500
> @@ -37,14 +37,24 @@
> uint64_t get_time_ns(void)
> {
> struct clocksource *cs = current_clock;
> -uint64_t cycle_now, cycle_delta;
> + uint64_t cycle_now, cycle_delta = 0;
> uint64_t ns_offset;
>
> /* read clocksource: */
> cycle_now = cs->read();
>
> /* calculate the delta since the last call: */
> -cycle_delta = (cycle_now - cs->cycle_last) & cs->mask;
Look closer, the rollover case is handled implicitly by the unsigned
arithmetics.
You are right, we do not have a possibility to detect a double rollover
without interrupts. Normally this is not an issue as this code is used
in timeout polling loops where the current time is polled often enough.
Anyway, maybe some comment should mention that this function is not
useful to measure long periods of time where 'long' is highly
architecture specific.
regards,
Sascha
> +
> + /* Handle rollover case */
> + if (cycle_now < cs->cycle_last) {
> + /* FIXME: I am not convinced about the cs->mask operation..
> + * I am assuming cs->mask is max! Probably need to change
> + * clocksource structure to have min and max
> + */
> + cycle_delta = cs->mask - (cs->cycle_last & cs->mask);
> + cs->cycle_last = 0;
> + }
> + cycle_delta += (cycle_now & cs->mask) - (cs->cycle_last & cs->mask);
>
> /* convert to nanoseconds: */
> ns_offset = cyc2ns(cs, cycle_delta);
>
--
Pengutronix e.K. - Linux Solutions for Science and Industry
---
Kontakt-Informationen finden Sie im Header dieser Mail oder
auf der Webseite -> http://www.pengutronix.de/impressum/ <-
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH v2] NAND FSL UPM: driver re-write using the hwcontrol callback
NAND FSL UPM: driver re-write using the hwcontrol callback
This is a re-write of the NAND FSL UPM driver using the more universal
hwcontrol callback (instead of the cmdfunc callback). Here is a brief
list of furher modifications:
- For the time being, the UPM setup writing the UPM array has been
removed from the driver and must now be done by the board specific
code.
- The bus width definition in "struct fsl_upm_nand" is now in bits to
comply with the corresponding Linux driver and 8, 16 and 32 bit
accesses are supported.
- chip->dev_read is only set if fun->dev_ready != NULL, which is
required for boards not connecting the R/B pin.
- A few issue have been fixed with MxMR bit manipulation like in the
corresponding Linux driver.
Note: I think the "io_addr" field of "struct fsl_upm" could be removed
as well, because the address is already determined by
"nand->IO_ADDR_[RW]", but I'm not 100% sure.
This patch has been tested on a TQM8548 modules with the NAND chip
Micron MT29F8G08FABWP.
This patch is based on the following patches posted to this list a few
minutes ago:
[PATCH] PPC: add accessor macros to clear and set bits in one shot
[PATCH] 83xx/85xx/86xx: add more MxMR local bus definitions
In principle, the NAND driver of the TQM8272 should work with it as
well.
Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
Acked-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
drivers/mtd/nand/fsl_upm.c | 128 +++-
include/linux/mtd/fsl_upm.h |1
2 files changed, 46 insertions(+), 83 deletions(-)
Index: u-boot/drivers/mtd/nand/fsl_upm.c
===
--- u-boot.orig/drivers/mtd/nand/fsl_upm.c
+++ u-boot/drivers/mtd/nand/fsl_upm.c
@@ -20,112 +20,83 @@
#include
#include
-#define FSL_UPM_MxMR_OP_NO (0 << 28) /* normal operation */
-#define FSL_UPM_MxMR_OP_WA (1 << 28) /* write array */
-#define FSL_UPM_MxMR_OP_RA (2 << 28) /* read array */
-#define FSL_UPM_MxMR_OP_RP (3 << 28) /* run pattern */
+static int fsl_upm_in_pattern;
static void fsl_upm_start_pattern(struct fsl_upm *upm, u32 pat_offset)
{
- out_be32(upm->mxmr, FSL_UPM_MxMR_OP_RP | pat_offset);
+ clrsetbits_be32(upm->mxmr, MxMR_MAD_MSK, MxMR_OP_RUNP | pat_offset);
}
static void fsl_upm_end_pattern(struct fsl_upm *upm)
{
- out_be32(upm->mxmr, FSL_UPM_MxMR_OP_NO);
- while (in_be32(upm->mxmr) != FSL_UPM_MxMR_OP_NO)
+ clrbits32(upm->mxmr, MxMR_OP_RUNP);
+
+ while (in_be32(upm->mxmr) & MxMR_OP_RUNP)
eieio();
}
static void fsl_upm_run_pattern(struct fsl_upm *upm, int width, u32 cmd)
{
- out_be32(upm->mar, cmd << (32 - width * 8));
- out_8(upm->io_addr, 0x0);
-}
-
-static void fsl_upm_setup(struct fsl_upm *upm)
-{
- int i;
-
- /* write upm array */
- out_be32(upm->mxmr, FSL_UPM_MxMR_OP_WA);
-
- for (i = 0; i < 64; i++) {
- out_be32(upm->mdr, upm->array[i]);
+ out_be32(upm->mar, cmd << (32 - width));
+ switch (width) {
+ case 8:
out_8(upm->io_addr, 0x0);
+ break;
+ case 16:
+ out_be16(upm->io_addr, 0x0);
+ break;
+ case 32:
+ out_be32(upm->io_addr, 0x0);
+ break;
}
-
- /* normal operation */
- out_be32(upm->mxmr, FSL_UPM_MxMR_OP_NO);
- while (in_be32(upm->mxmr) != FSL_UPM_MxMR_OP_NO)
- eieio();
}
-static void fun_cmdfunc(struct mtd_info *mtd, unsigned command, int column,
- int page_addr)
+static void nand_hwcontrol (struct mtd_info *mtd, int cmd)
{
struct nand_chip *chip = mtd->priv;
struct fsl_upm_nand *fun = chip->priv;
- fsl_upm_start_pattern(&fun->upm, fun->upm_cmd_offset);
-
- if (command == NAND_CMD_SEQIN) {
- int readcmd;
-
- if (column >= mtd->oobblock) {
- /* OOB area */
- column -= mtd->oobblock;
- readcmd = NAND_CMD_READOOB;
- } else if (column < 256) {
- /* First 256 bytes --> READ0 */
- readcmd = NAND_CMD_READ0;
- } else {
- column -= 256;
- readcmd = NAND_CMD_READ1;
- }
- fsl_upm_run_pattern(&fun->upm, fun->width, readcmd);
+ switch (cmd) {
+ case NAND_CTL_SETCLE:
+ fsl_upm_start_pattern(&fun->upm, fun->upm_cmd_offset);
+ fsl_upm_in_pattern++;
+ break;
+ case NAND_CTL_SETALE:
+ fsl_upm_start_pattern(&fun->upm, fun->upm_addr_offset);
+ fsl_upm_in_pattern++;
+ break;
+ case NAND_CTL_CLRCLE:
+ case NAND_CTL_CLRALE:
+ fsl_upm_end_pattern(&fun->upm);
+ fsl_upm_in_pattern--;
+ break;
}
+}
- fs
Re: [U-Boot-Users] [PATCH] MPC85xx: Beatify boot output of L2 cache configuration
Andy Fleming wrote: > On Wed, May 28, 2008 at 1:12 PM, Wolfgang Grandegger <[EMAIL PROTECTED]> > wrote: >> The boot output is now aligned poperly with other boot output >> lines, e.g.: >> >> FLASH: 128 MB >> L2:512 KB enabled >> >> Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]> > > A silly comment, but let's spell it "Beautify" Of course, I didn't want to beatify this part of the code. New patch will follow. BTW: what is the correct way to send an updated version of a patch. Should the subject be unchanged or is adding "v2" to [PATCH] preferred. Wolfgang. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
