Re: [U-Boot] [PATCH 1/1] microblaze: generic: enable FDT support
Stephan Linz wrote: Signed-off-by: Stephan Linz l...@li-pro.net --- include/configs/microblaze-generic.h |4 1 files changed, 4 insertions(+), 0 deletions(-) Added to microblaze custodian repo. Michal diff --git a/include/configs/microblaze-generic.h b/include/configs/microblaze-generic.h index 15544a1..009a253 100644 --- a/include/configs/microblaze-generic.h +++ b/include/configs/microblaze-generic.h @@ -327,4 +327,8 @@ # define CONFIG_SYS_PROMPT_HUSH_PS2 #endif +/* pass open firmware flat tree */ +#define CONFIG_FIT 1 +#define CONFIG_OF_LIBFDT 1 + #endif /* __CONFIG_H */ -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [NEXT]arm: Enable dcache in jadecpu
Enabling d cache leads to greatly improved image decompression times. Signed-off-by: Matthias Weisser weiss...@arcor.de --- board/syteco/jadecpu/jadecpu.c |1 + include/configs/jadecpu.h |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/board/syteco/jadecpu/jadecpu.c b/board/syteco/jadecpu/jadecpu.c index 69476f8..4919e06 100644 --- a/board/syteco/jadecpu/jadecpu.c +++ b/board/syteco/jadecpu/jadecpu.c @@ -44,6 +44,7 @@ int board_init(void) gd-bd-bi_boot_params = PHYS_SDRAM + PHYS_SDRAM_SIZE - 0x1; icache_enable(); + dcache_enable(); return 0; } diff --git a/include/configs/jadecpu.h b/include/configs/jadecpu.h index c119392..5a41c89 100644 --- a/include/configs/jadecpu.h +++ b/include/configs/jadecpu.h @@ -129,6 +129,7 @@ #define CONFIG_CMD_FAT 1 #define CONFIG_CMD_PING1 #define CONFIG_CMD_USB 1 +#define CONFIG_CMD_CACHE #define CONFIG_SYS_HUSH_PARSER #define CONFIG_SYS_PROMPT_HUSH_PS2 -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/1] net: fix some bugs in LL TEMAC driver
Stephan Linz wrote: * avoid using link variable uninitialized * avoid using phy_addr variable with invalid value * reorganize phy control: first looking for phy than link * return with error (result value 0) if no phy/link was found * fix boolean mistake in wait for link: wait as long as we got phy register 1 has no link indication (BMSR != 0x24) * expand the 'first run' flag handling in ll_temac_init() in respect to possible error detection in xps_ll_temac_phy_ctrl() Signed-off-by: Stephan Linz l...@li-pro.net --- drivers/net/xilinx_ll_temac.c | 52 ++--- 1 files changed, 38 insertions(+), 14 deletions(-) diff --git a/drivers/net/xilinx_ll_temac.c b/drivers/net/xilinx_ll_temac.c index 72a1632..ff93c1f 100644 --- a/drivers/net/xilinx_ll_temac.c +++ b/drivers/net/xilinx_ll_temac.c @@ -225,24 +225,21 @@ static void read_phy_reg (struct eth_device *dev, int phy_addr) #endif static int phy_addr = -1; -static int link; +static int link = 0; Static variables are always initialized to 0. I fixed this in your patch. Added to microblaze custodian repository. Thanks, Michal -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] include/linux/mii.h: update for supporting GE
On Friday, December 03, 2010 00:24:00 macp...@andestech.com wrote: Also replace the whitespace to tab characters. Because I'm wondering when next time we update the same file from Linux kernel to u-boot, We will might need extra effort to reduce the size of diff (patch) file. i wouldnt worry about it. just use the style from the kernel ... easier to quickly compare via `diff` without worrying about whitespace noise -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] davinci: Rewrite timer.c to use tbl/tbu emulation variables in gd
Hi Nick, On Thu, Dec 02, 2010 at 19:27:24, Nick Thompson wrote: This change allows the davinci timer functions to be used before relocation since it avoids using static variables prior to BSS being made available. The code is based on that used in the at91 timers, modified to use a davinci specific hardware timer. It also maintains reset_timer() to allow deprecated timer usage to continue to work (for example, in nand_base.c) Signed-off-by: Nick Thompson nick.thomp...@ge.com --- This patch relies on http://patchwork.ozlabs.org/patch/73758/ which has not been accepted yet. I have made a comment on it, suggesting that it should be changed: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/90040/focus=90162 arch/arm/cpu/arm926ejs/davinci/timer.c | 77 1 files changed, 28 insertions(+), 49 deletions(-) I applied this patch on top of http://patchwork.ozlabs.org/patch/73758/ and tested on DM365 without any config changes. Now the board boots fine without any hang. Tested-by: Sudhakar Rajashekhara sudhakar@ti.com Thanks, Sudhakar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] net: Add LL TEMAC driver to u-boot
Dear Wolfgang,
Wolfgang Denk wrote:
Dear Michal Simek,
sorry for the long delay. We're still lacking a (new) network
custodian...
In message 1280753377-2894-4-git-send-email-mon...@monstr.eu you wrote:
Add Xilinx LL Temac driver to u-boot.
Signed-off-by: Michal Simek mon...@monstr.eu
+++ b/drivers/net/xilinx_ll_temac.c
@@ -0,0 +1,561 @@
+/*
+ *
Drop blank line.
done
+ * Copyright (C) 2008 - 2009 Michal Simek mon...@monstr.eu
+ * June 2008 Microblaze optimalization, FIFO mode support
2009? Not 2010 ?
done
+/* XPS_LL_TEMAC direct registers definition */
+#define TEMAC_RAF0 (dev-iobase + 0x00)
+#define TEMAC_TPF0 (dev-iobase + 0x04)
+#define TEMAC_IFGP0 (dev-iobase + 0x08)
+#define TEMAC_IS0 (dev-iobase + 0x0c)
+#define TEMAC_IP0 (dev-iobase + 0x10)
+#define TEMAC_IE0 (dev-iobase + 0x14)
+
+#define TEMAC_MSW0 (dev-iobase + 0x20)
+#define TEMAC_LSW0 (dev-iobase + 0x24)
+#define TEMAC_CTL0 (dev-iobase + 0x28)
+#define TEMAC_RDY0 (dev-iobase + 0x2c)
Please use a C struct to describe the register layout.
not fixed.
+/* XPS_LL_TEMAC indirect registers offset definition */
+
+#define RCW00x200
not used
+#define RCW10x240
+#define TC 0x280
+#define FCC 0x2c0
not used
+#define EMMC0x300
+#define PHYC0x320
not used
+#define MC 0x340
+#define UAW00x380
+#define UAW10x384
+#define MAW00x388
not used
+#define MAW10x38c
not used
+#define AFM 0x390
+#define TIS 0x3a0
not used
+#define TIE 0x3a4
not used
+#define MIIMWD 0x3b0
+#define MIIMAI 0x3b4
Ditto.
They are offset for indirect accesses that's why should be just values.
+out_be32((u32 *)TEMAC_LSW0, phy_data);
+out_be32((u32 *)TEMAC_CTL0, CNTLREG_WRITE_ENABLE_MASK | MIIMWD);
+out_be32((u32 *)TEMAC_LSW0, (phy_addr 5) | (reg_addr));
+out_be32((u32 *)TEMAC_CTL0, \
+CNTLREG_WRITE_ENABLE_MASK | MIIMAI | (emac 10));
+while (!(in_be32((u32 *)TEMAC_RDY0) XTE_RSE_MIIM_WR_MASK))
The need to have all these casts should ring some alarm bell to you.
Please use a proper C struct instead.
sure.
+out_be32((u32 *)TEMAC_LSW0, reg_data);
+out_be32((u32 *)TEMAC_CTL0, \
+CNTLREG_WRITE_ENABLE_MASK | (emac 10) | reg_offset);
Drop the backslash.
done
+debug (%d: 0x%x , j, result);
+}
+debug (\n);
No spaces between function name and '('. Please fix globally.
Consider running your patch through checkpatch...
done
+while (retries--
+((xps_ll_temac_hostif_get(dev, 0, phy_addr, 1) 0x24) == 0x24))
+;
Bad indentation.
done.
+if (i == 0x7c0a3) {
...
+if (i == 0x1410cc2) {
Please use self-explaining symbolic names for these magic numbers,
and/or add sufficient comments what these mean.
There is option which I prefer which is phy lib.
+static void debugll(int count)
+{
+printf (%d fifo isr 0x%08x, fifo_ier 0x%08x, fifo_rdfr 0x%08x,
+fifo_rdfo 0x%08x fifo_rlr 0x%08x\n, count, ll_fifo-isr, \
+ll_fifo-ier, ll_fifo-rdfr, ll_fifo-rdfo, ll_fifo-rlf);
Drop the backslash. Please check fix globally.
done.
I have fixed some simple issues which you reported but not everything.
(microblaze custodian tree)
I am still not convince that I even would like to push this driver
mainline and keep responsibility for it.
The next thing is that there is missing phy lib support which will be
good to use.
Microblaze systems are slightly moving to new AXI bus where will be
different eth IP core which will require new u-boot driver. Not sure
if will be based on this ll_temac driver.
Stephan: If you are willing to fix issues which Wolfgang reported, I am
happy to test them.
Best regards,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] arm: Activating dcache breaks 'usb start' and 'tftpboot' on jadecpu
Hi I just activated the dcache on our jadecpu board but it seems to me that this breaks some commands. jade dcache Data (writethrough) Cache is OFF jade usb start (Re)start USB... USB: scanning bus for devices... 2 USB Device(s) found scanning bus for storage devices... 1 Storage Device(s) found jade dcache on Data (writethrough) Cache is ON jade usb start (Re)start USB... USB: scanning bus for devices... ERROR: CTL:TIMEOUT 2 USB Device(s) found scanning bus for storage devices... 0 Storage Device(s) found jade dcache off Data (writethrough) Cache is OFF jade usb start (Re)start USB... USB: scanning bus for devices... 2 USB Device(s) found scanning bus for storage devices... 1 Storage Device(s) found jade Same goes for tftpboot on this machine and also on a imx25 based system which is currently not in mainline. As there is a timeout involved I had the timer implementation under suspicion where some static variables may be used before relocation but moving them to gd_t didn't help. Has anyone an explanation for this behavior? Is anyone out there having dcache running on an ARM926 and working usb/tftpboot? Many thanks, Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm: Activating dcache breaks 'usb start' and 'tftpboot' on jadecpu
Dear =?ISO-8859-15?Q?Matthias_Wei=DFer?=, In message 4cf8fe3e.9010...@arcor.de you wrote: I just activated the dcache on our jadecpu board but it seems to me that this breaks some commands. I am not surprised. Has anyone an explanation for this behavior? Is anyone out there having dcache running on an ARM926 and working usb/tftpboot? Many drivers have not been written to work with enabled caches. As far as USB is concerned, you might be lucky that your system usies a EHCI controller, so setting CONFIG_EHCI_DCACHE should help. As for the network driver, you will probably have to figure out yourself how to fix that. Patches welcome. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de When all is said and done, more is said than done. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm: Activating dcache breaks 'usb start' and 'tftpboot' on jadecpu
Hello Wolfgang Am 03.12.2010 15:47, schrieb Wolfgang Denk: Has anyone an explanation for this behavior? Is anyone out there having dcache running on an ARM926 and working usb/tftpboot? Many drivers have not been written to work with enabled caches. What is the reason that special handling is needed when dcache is enabled? If a driver doesn't use any DMA there should be no need as the dcache is only enabled for the RAM and not for any memory mapped IO if I understand the code in arch/arm/lib/cache-cp15.c right. As far as USB is concerned, you might be lucky that your system usies a EHCI controller, so setting CONFIG_EHCI_DCACHE should help. No, only OHCI. As for the network driver, you will probably have to figure out yourself how to fix that. As the memory mapped network controller (SMSC9221) is not cached it shouldn't be a problem or do I miss something here? Patches welcome. If someone can give me a little push into the right direction I will try but currently I have no idea what to do besides activating the cache right before the default bootm booting. Thanks a lot Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] add print_cpuinfo to s3c24x0
Hello
This patch adds support for print_cpuinfo on Samsung s3c24x0
based targets. If activated by #define CONFIG_DISPLAY_CPUINFO, the
chip ID and the 3 main cpu frequencies will be displayed.
Dave
Signed-off-by: David Müller d.muel...@elsoft.ch
diff --git a/arch/arm/cpu/arm920t/s3c24x0/Makefile
b/arch/arm/cpu/arm920t/s3c24x0/Makefile
index bd53724..0029700 100644
--- a/arch/arm/cpu/arm920t/s3c24x0/Makefile
+++ b/arch/arm/cpu/arm920t/s3c24x0/Makefile
@@ -26,6 +26,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(SOC).o
COBJS-$(CONFIG_USE_IRQ) += interrupts.o
+COBJS-$(CONFIG_DISPLAY_CPUINFO)+= cpu_info.o
COBJS-y+= speed.o
COBJS-y+= timer.o
COBJS-y+= usb.o
diff --git a/arch/arm/cpu/arm920t/s3c24x0/cpu_info.c
b/arch/arm/cpu/arm920t/s3c24x0/cpu_info.c
new file mode 100644
index 000..14c5c6a
--- /dev/null
+++ b/arch/arm/cpu/arm920t/s3c24x0/cpu_info.c
@@ -0,0 +1,54 @@
+/*
+ * (C) Copyright 2010
+ * David Mueller d.muel...@elsoft.ch
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include asm/io.h
+#include asm/arch/s3c24x0_cpu.h
+
+typedef ulong (*getfreq)(void);
+
+static const getfreq freq_f[] = {
+ get_FCLK,
+ get_HCLK,
+ get_PCLK,
+};
+
+static const char freq_c[] = { 'F', 'H', 'P' };
+
+int print_cpuinfo(void)
+{
+ int i;
+ char buf[32];
+/* the S3C2400 seems to be lacking a CHIP ID register */
+#ifndef CONFIG_S3C2400
+ ulong cpuid;
+ struct s3c24x0_gpio * const gpio = s3c24x0_get_base_gpio();
+
+ cpuid = readl(gpio-gstatus1);
+ printf(CPUID: %8lX\n, cpuid);
+#endif
+ for (i = 0; i ARRAY_SIZE(freq_f); i++)
+ printf(%cCLK: %8s MHz\n, freq_c[i], strmhz(buf, freq_f[i]()));
+
+ return 0;
+}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm: Activating dcache breaks 'usb start' and 'tftpboot' on jadecpu
Dear =?ISO-8859-1?Q?Matthias_Wei=DFer?=, In message 4cf90819.7040...@arcor.de you wrote: Has anyone an explanation for this behavior? Is anyone out there having dcache running on an ARM926 and working usb/tftpboot? Many drivers have not been written to work with enabled caches. What is the reason that special handling is needed when dcache is enabled? If a driver doesn't use any DMA there should be no need as the dcache is only enabled for the RAM and not for any memory mapped IO if I understand the code in arch/arm/lib/cache-cp15.c right. On ARM, device write accesses are typically just store instructions (in C: assignments to a volatile pointer). With caches on, these accesses will be - guess what? cached, i. e. they are NOT written to the device, at least not immediately. And if you repeatedly read a register (like when polling for some status bit to change) these accesses will be cached, too. You need to make sure that caches are properly flushed / invalidated at the right points. As far as USB is concerned, you might be lucky that your system usies a EHCI controller, so setting CONFIG_EHCI_DCACHE should help. No, only OHCI. Bad luck. As the memory mapped network controller (SMSC9221) is not cached it shouldn't be a problem or do I miss something here? You said you had enabled the data cache, so why do you think these accesses are not cached? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Blast medicine anyway! We've learned to tie into every organ in the human body but one. The brain! The brain is what life is all about. -- McCoy, The Menagerie, stardate 3012.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] DaVinci DM6446: Config Update
From: Sandeep Paulraj s-paul...@ti.com The DM6446 does not build due to the ARM relocation patch. Also the board does not build in the NOR mode. Changed default to NAND to ensure no build failure. While at it removed CONFIG_CMD_KGDB Signed-off-by: Sandeep Paulraj s-paul...@ti.com --- include/configs/davinci_dvevm.h | 19 +++ 1 files changed, 11 insertions(+), 8 deletions(-) diff --git a/include/configs/davinci_dvevm.h b/include/configs/davinci_dvevm.h index e1b1db1..45214fa 100644 --- a/include/configs/davinci_dvevm.h +++ b/include/configs/davinci_dvevm.h @@ -50,7 +50,7 @@ /*===*/ #define DV_EVM #define CONFIG_SYS_NAND_SMALLPAGE -#define CONFIG_SYS_USE_NOR +#define CONFIG_SYS_USE_NAND #define CONFIG_DISPLAY_CPUINFO /*===*/ /* SoC Configuration */ @@ -78,6 +78,7 @@ #define CONFIG_STACKSIZE (256*1024) /* regular stack */ #define PHYS_SDRAM_1 0x8000 /* DDR Start */ #define PHYS_SDRAM_1_SIZE 0x1000 /* DDR size 256MB */ + #define DDR_8BANKS /* 8-bank DDR2 (256MB) */ /**/ /* Serial Driver info */ @@ -228,11 +229,13 @@ #define CONFIG_PREBOOT usb start #endif #endif -/*===*/ -/* KGDB support (if any) */ -/*===*/ -#ifdef CONFIG_CMD_KGDB -#define CONFIG_KGDB_BAUDRATE 115200 /* speed to run kgdb serial port */ -#define CONFIG_KGDB_SER_INDEX 1 /* which serial port to use */ -#endif + +#define CONFIG_MAX_RAM_BANK_SIZE (256 20) /* 256 MB */ + +#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 +#define CONFIG_SYS_INIT_RAM_SIZE 0x1000 +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_SDRAM_BASE + \ +CONFIG_SYS_INIT_RAM_SIZE - \ +GENERATED_GBL_DATA_SIZE) + #endif /* __CONFIG_H */ -- 1.6.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] update SMDK2410 port
Hello
This patch brings the SMDK2410 port in sync with the latest U-Boot
version by doing the following:
- do the necessary adjustments to support the ARM relocation feature
- use the CFI flash driver (and removing the old one)
Dave
Signed-off-by: David Müller d.muel...@elsoft.ch
diff --git a/board/samsung/smdk2410/Makefile b/board/samsung/smdk2410/Makefile
index bda8898..0afe1e2 100644
--- a/board/samsung/smdk2410/Makefile
+++ b/board/samsung/smdk2410/Makefile
@@ -25,7 +25,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).o
-COBJS := smdk2410.o flash.o
+COBJS := smdk2410.o
SOBJS := lowlevel_init.o
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
diff --git a/board/samsung/smdk2410/config.mk b/board/samsung/smdk2410/config.mk
index c8d1b1f..2357f39 100644
--- a/board/samsung/smdk2410/config.mk
+++ b/board/samsung/smdk2410/config.mk
@@ -8,18 +8,10 @@
# see http://www.samsung.com/ for more information on SAMSUNG
#
-#
-# SMDK2410 has 1 bank of 64 MB DRAM
-#
-# 3000' to 3400'
-#
# Linux-Kernel is expected to be at 3000'8000, entry 3000'8000
-# optionally with a ramdisk at 3080'
+# optionally with a ramdisk at 3040'
#
-# we load ourself to 33F8'
+# NOR flash is mapped at address 0
#
-# download area is 3300'
-#
-
-CONFIG_SYS_TEXT_BASE = 0x33F8
+CONFIG_SYS_TEXT_BASE = 0x0
diff --git a/board/samsung/smdk2410/flash.c b/board/samsung/smdk2410/flash.c
deleted file mode 100644
index 132d752..000
--- a/board/samsung/smdk2410/flash.c
+++ /dev/null
@@ -1,433 +0,0 @@
-/*
- * (C) Copyright 2002
- * Sysgo Real-Time Solutions, GmbH www.elinos.com
- * Alex Zuepke a...@sysgo.de
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-
-#include common.h
-
-ulong myflush (void);
-
-
-#define FLASH_BANK_SIZEPHYS_FLASH_SIZE
-#define MAIN_SECT_SIZE 0x1/* 64 KB */
-
-flash_info_t flash_info[CONFIG_SYS_MAX_FLASH_BANKS];
-
-
-#define CMD_READ_ARRAY 0x00F0
-#define CMD_UNLOCK10x00AA
-#define CMD_UNLOCK20x0055
-#define CMD_ERASE_SETUP0x0080
-#define CMD_ERASE_CONFIRM 0x0030
-#define CMD_PROGRAM0x00A0
-#define CMD_UNLOCK_BYPASS 0x0020
-
-#define MEM_FLASH_ADDR1(*(volatile u16
*)(CONFIG_SYS_FLASH_BASE + (0x0555 1)))
-#define MEM_FLASH_ADDR2(*(volatile u16
*)(CONFIG_SYS_FLASH_BASE + (0x02AA 1)))
-
-#define BIT_ERASE_DONE 0x0080
-#define BIT_RDY_MASK 0x0080
-#define BIT_PROGRAM_ERROR 0x0020
-#define BIT_TIMEOUT0x8000 /* our flag */
-
-#define READY 1
-#define ERR 2
-#define TMO 4
-
-/*---
- */
-
-ulong flash_init (void)
-{
- int i, j;
- ulong size = 0;
-
- for (i = 0; i CONFIG_SYS_MAX_FLASH_BANKS; i++) {
- ulong flashbase = 0;
-
- flash_info[i].flash_id =
-#if defined(CONFIG_AMD_LV400)
- (AMD_MANUFACT FLASH_VENDMASK) |
- (AMD_ID_LV400B FLASH_TYPEMASK);
-#elif defined(CONFIG_AMD_LV800)
- (AMD_MANUFACT FLASH_VENDMASK) |
- (AMD_ID_LV800B FLASH_TYPEMASK);
-#else
-#error Unknown flash configured
-#endif
- flash_info[i].size = FLASH_BANK_SIZE;
- flash_info[i].sector_count = CONFIG_SYS_MAX_FLASH_SECT;
- memset (flash_info[i].protect, 0, CONFIG_SYS_MAX_FLASH_SECT);
- if (i == 0)
- flashbase = PHYS_FLASH_1;
- else
- panic (configured too many flash banks!\n);
- for (j = 0; j flash_info[i].sector_count; j++) {
- if (j = 3) {
- /* 1st one is 16 KB */
- if (j == 0) {
- flash_info[i].start[j] =
- flashbase + 0;
- }
-
- /* 2nd and 3rd are both 8 KB */
- if ((j == 1) || (j == 2)) {
-
Re: [U-Boot] [PATCH 2/4] UBIFS: Add ubifsumount command to unmount an active volume
On Thursday 28 October 2010 14:09:22 Stefan Roese wrote: This new ubifsumount command allows the user to unmount a previously mounted UBIFS volume. Applied to u-boot-ubi/master. Thanks. Cheers, 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: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] UBIFS: Change ubifs mount to ubifsmount in ubifsls output
On Thursday 28 October 2010 14:09:29 Stefan Roese wrote: Signed-off-by: Stefan Roese s...@denx.de Applied to u-boot-ubi/master. Thanks. Cheers, 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: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4 v2] UBIFS: Change ubifsload to not read beyond the requested size
On Monday 01 November 2010 17:28:00 Stefan Roese wrote: Until now ubifsload pads the destination with 0 up to a multiple of UBIFS_BLOCK_SIZE (4KiB) while reading a file to memory. This patch changes this behaviour to only read to the requested length. This is either the file length or the length/size provided as parameter to the ubifsload command. Applied to u-boot-ubi/master. Thanks. Cheers, 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: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] UBI/UBIFS: Automatically unmount UBIFS volume upon UBI partition change
On Monday 01 November 2010 17:28:22 Stefan Roese wrote: Automatically unmount UBIFS partition when user changes the UBI device. Otherwise the following UBIFS commands will crash. Applied to u-boot-ubi/master. Thanks. Cheers, 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: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ubifs.c: BUG: Error following links
On Thursday 02 December 2010 15:02:35 Ricardo Ribalda Delgado wrote: The link_name variable is declared inside the if block and it is used outside it through the name pointer. Applied to u-boot-ubi/master. Thanks. Cheers, 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: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-ubi/master
Hi Wolfgang, The following changes since commit 49733aa0b9d29803384ad4bce74985f4bbe7e9aa: Merge branch 'master' of /home/wd/git/u-boot/custodians (2010-11-30 22:13:32 +0100) are available in the git repository at: git://www.denx.de/git/u-boot-ubi.git master Ricardo Ribalda Delgado (1): ubifs.c: BUG: Error following links Stefan Roese (4): UBIFS: Add ubifsumount command to unmount an active volume UBIFS: Change ubifs mount to ubifsmount in ubifsls output UBIFS: Change ubifsload to not read beyond the requested size UBI/UBIFS: Automatically unmount UBIFS volume upon UBI partition change common/cmd_ubi.c | 11 common/cmd_ubifs.c | 47 - fs/ubifs/super.c |2 +- fs/ubifs/ubifs.c | 73 ++-- 4 files changed, 117 insertions(+), 16 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/13] mpc85xx boards: initdram() cleanup/bugfix
Hi Becky,
+/* Common ddr init for non-corenet fsl 85xx platforms */
+#ifndef CONFIG_FSL_CORENET
+phys_size_t initdram(int board_type)
+{
+ phys_size_t dram_size = 0;
+
+ puts(Initializing\n);
Any chance we can remove the puts() above? DRAM: is always printed
out directly before initdram is called, so I don't think the
Initializing message adds much benefit and slightly dirties the
output. For reference:
I2C: ready
DRAM: Initializing
DDR: 2 GiB (DDR2, 64-bit, CL=5, ECC on)
FLASH: Executed from FLASH1
FLASH: 256 MiB
vs
I2C: ready
DRAM: DDR: 2 GiB (DDR2, 64-bit, CL=5, ECC on)
FLASH: Executed from FLASH1
FLASH: 256 MiB
Otherwise it looked good. I tested on the xpedite5170 that was a corner
case, and the xpedite5370 (mpc8572-based).
Acked-by: Peter Tyser pty...@xes-inc.com
Tested-by: Peter Tyser pty...@xes-inc.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ubi/master
Hi Wolfgang, On Friday 03 December 2010 16:59:31 Stefan Roese wrote: The following changes since commit 49733aa0b9d29803384ad4bce74985f4bbe7e9aa: Merge branch 'master' of /home/wd/git/u-boot/custodians (2010-11-30 22:13:32 +0100) are available in the git repository at: git://www.denx.de/git/u-boot-ubi.git master Sorry, please wait with pulling. I've noticed a problem with one of the patches and will publish an updated version shortly. Cheers, 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: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH/next] 74xx_7xx/mpc86xx/ppmc7xx: Fix do_reset() declaration
The following commit:
commit 882b7d726febe65579d6502c271412ecb05821d7
Author: Mike Frysinger vap...@gentoo.org
Date: Wed Oct 20 03:41:17 2010 -0400
do_reset: unify duplicate prototypes
missed the 74xx_7xx and mpc86xx arches and the ppmc7xx board do_reset()
functions which resulted in build errors such as:
cpu.c:128: error: conflicting types for 'do_reset'
include/command.h:102: error: previous declaration of 'do_reset' was here
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
arch/powerpc/cpu/74xx_7xx/cpu.c | 10 +++---
arch/powerpc/cpu/mpc86xx/cpu.c |5 +++--
board/ppmc7xx/ppmc7xx.c |7 +--
3 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/cpu/74xx_7xx/cpu.c b/arch/powerpc/cpu/74xx_7xx/cpu.c
index ab6f11d..b6a31b4 100644
--- a/arch/powerpc/cpu/74xx_7xx/cpu.c
+++ b/arch/powerpc/cpu/74xx_7xx/cpu.c
@@ -234,8 +234,7 @@ soft_restart(unsigned long addr)
!defined(CONFIG_ELPPC)\
!defined(CONFIG_PPMC7XX)
/* no generic way to do board reset. simply call soft_reset. */
-void
-do_reset (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
ulong addr;
/* flush and disable I/D cache */
@@ -263,7 +262,12 @@ do_reset (cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
addr = CONFIG_SYS_MONITOR_BASE - sizeof (ulong);
#endif
soft_restart(addr);
- while(1); /* not reached */
+
+ /* not reached */
+ while(1)
+ ;
+
+ return 1;
}
#endif
diff --git a/arch/powerpc/cpu/mpc86xx/cpu.c b/arch/powerpc/cpu/mpc86xx/cpu.c
index 4e90fd2..ffcc8e6 100644
--- a/arch/powerpc/cpu/mpc86xx/cpu.c
+++ b/arch/powerpc/cpu/mpc86xx/cpu.c
@@ -123,8 +123,7 @@ checkcpu(void)
}
-void
-do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
volatile immap_t *immap = (immap_t *)CONFIG_SYS_IMMR;
volatile ccsr_gur_t *gur = immap-im_gur;
@@ -137,6 +136,8 @@ do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const
argv[])
while (1)
;
+
+ return 1;
}
diff --git a/board/ppmc7xx/ppmc7xx.c b/board/ppmc7xx/ppmc7xx.c
index 5e7427f..432d366 100644
--- a/board/ppmc7xx/ppmc7xx.c
+++ b/board/ppmc7xx/ppmc7xx.c
@@ -88,7 +88,7 @@ int misc_init_r( void )
*
* Shell command to reset the board.
*/
-void do_reset( cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[] )
+int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
printf( Resetting...\n );
@@ -100,7 +100,10 @@ void do_reset( cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[] )
_start();
/* Should never get here */
- while(1);
+ while(1)
+ ;
+
+ return 1;
}
int board_eth_init(bd_t *bis)
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] PowerPC, nand_spl: Add relocation support for -fpic
By rearranging the linker script we get support for relocation of -fpic for free. Move __got2_entries outside _GOT2_TABLE_ defining scope matching the rest of PowerPC Signed-off-by: Joakim Tjernlund joakim.tjernl...@transmode.se --- nand_spl/board/freescale/mpc8313erdb/u-boot.lds |4 +++- nand_spl/board/freescale/mpc8315erdb/u-boot.lds |4 +++- nand_spl/board/sheldon/simpc8313/u-boot.lds |4 +++- 3 files changed, 9 insertions(+), 3 deletions(-) diff --git a/nand_spl/board/freescale/mpc8313erdb/u-boot.lds b/nand_spl/board/freescale/mpc8313erdb/u-boot.lds index 138e427..f1649f8 100644 --- a/nand_spl/board/freescale/mpc8313erdb/u-boot.lds +++ b/nand_spl/board/freescale/mpc8313erdb/u-boot.lds @@ -39,8 +39,10 @@ SECTIONS *(.sdata*) _GOT2_TABLE_ = .; KEEP(*(.got2)) - __got2_entries = (. - _GOT2_TABLE_) 2; + KEEP(*(.got)) + PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4); } + __got2_entries = ((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_) 2) - 1; . = ALIGN(8); __bss_start = .; diff --git a/nand_spl/board/freescale/mpc8315erdb/u-boot.lds b/nand_spl/board/freescale/mpc8315erdb/u-boot.lds index 138e427..f1649f8 100644 --- a/nand_spl/board/freescale/mpc8315erdb/u-boot.lds +++ b/nand_spl/board/freescale/mpc8315erdb/u-boot.lds @@ -39,8 +39,10 @@ SECTIONS *(.sdata*) _GOT2_TABLE_ = .; KEEP(*(.got2)) - __got2_entries = (. - _GOT2_TABLE_) 2; + KEEP(*(.got)) + PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4); } + __got2_entries = ((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_) 2) - 1; . = ALIGN(8); __bss_start = .; diff --git a/nand_spl/board/sheldon/simpc8313/u-boot.lds b/nand_spl/board/sheldon/simpc8313/u-boot.lds index ad82589..1da4287 100644 --- a/nand_spl/board/sheldon/simpc8313/u-boot.lds +++ b/nand_spl/board/sheldon/simpc8313/u-boot.lds @@ -40,8 +40,10 @@ SECTIONS *(.sdata*) _GOT2_TABLE_ = .; *(.got2) - __got2_entries = (. - _GOT2_TABLE_) 2; + KEEP(*(.got)) + PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4); } + __got2_entries = ((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_) 2) - 1; . = ALIGN(8); __bss_start = .; -- 1.7.2.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] PowerPC: Add relocation support for -fpic
By rearranging the linker script we get support for
relocation of -fpic for free.
Signed-off-by: Joakim Tjernlund joakim.tjernl...@transmode.se
---
arch/powerpc/cpu/74xx_7xx/u-boot.lds |5 +++--
arch/powerpc/cpu/mpc512x/u-boot.lds |5 +++--
arch/powerpc/cpu/mpc5xx/u-boot.lds |5 +++--
arch/powerpc/cpu/mpc5xxx/u-boot.lds |5 +++--
arch/powerpc/cpu/mpc8220/u-boot.lds |5 +++--
arch/powerpc/cpu/mpc824x/u-boot.lds |5 +++--
arch/powerpc/cpu/mpc8260/u-boot.lds |5 +++--
arch/powerpc/cpu/mpc83xx/u-boot.lds |5 +++--
arch/powerpc/cpu/mpc85xx/u-boot.lds |5 +++--
arch/powerpc/cpu/mpc86xx/u-boot.lds |5 +++--
arch/powerpc/cpu/ppc4xx/u-boot.lds |5 +++--
11 files changed, 33 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/cpu/74xx_7xx/u-boot.lds
b/arch/powerpc/cpu/74xx_7xx/u-boot.lds
index 771a845..8429f33 100644
--- a/arch/powerpc/cpu/74xx_7xx/u-boot.lds
+++ b/arch/powerpc/cpu/74xx_7xx/u-boot.lds
@@ -43,13 +43,14 @@ SECTIONS
PROVIDE (erotext = .);
.reloc :
{
-KEEP(*(.got))
_GOT2_TABLE_ = .;
KEEP(*(.got2))
+KEEP(*(.got))
+PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
_FIXUP_TABLE_ = .;
KEEP(*(.fixup))
}
- __got2_entries = (_FIXUP_TABLE_ - _GOT2_TABLE_) 2;
+ __got2_entries = ((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_) 2) - 1;
__fixup_entries = (. - _FIXUP_TABLE_)2;
.data:
diff --git a/arch/powerpc/cpu/mpc512x/u-boot.lds
b/arch/powerpc/cpu/mpc512x/u-boot.lds
index 361e714..ab9303f 100644
--- a/arch/powerpc/cpu/mpc512x/u-boot.lds
+++ b/arch/powerpc/cpu/mpc512x/u-boot.lds
@@ -37,14 +37,15 @@ SECTIONS
PROVIDE (erotext = .);
.reloc :
{
-KEEP(*(.got))
_GOT2_TABLE_ = .;
KEEP(*(.got2))
+KEEP(*(.got))
+PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
_FIXUP_TABLE_ = .;
KEEP(*(.fixup))
*(.fixup)
}
- __got2_entries = (_FIXUP_TABLE_ - _GOT2_TABLE_) 2;
+ __got2_entries = ((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_) 2) - 1;
__fixup_entries = (. - _FIXUP_TABLE_) 2;
.data:
diff --git a/arch/powerpc/cpu/mpc5xx/u-boot.lds
b/arch/powerpc/cpu/mpc5xx/u-boot.lds
index b7fd4bc..69bd7aa 100644
--- a/arch/powerpc/cpu/mpc5xx/u-boot.lds
+++ b/arch/powerpc/cpu/mpc5xx/u-boot.lds
@@ -46,13 +46,14 @@ SECTIONS
PROVIDE (erotext = .);
.reloc :
{
-KEEP(*(.got))
_GOT2_TABLE_ = .;
KEEP(*(.got2))
+KEEP(*(.got))
+PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
_FIXUP_TABLE_ = .;
KEEP(*(.fixup))
}
- __got2_entries = (_FIXUP_TABLE_ - _GOT2_TABLE_) 2;
+ __got2_entries = ((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_) 2) - 1;
__fixup_entries = (. - _FIXUP_TABLE_)2;
.data:
diff --git a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
b/arch/powerpc/cpu/mpc5xxx/u-boot.lds
index eeeff6c..7e3b70a 100644
--- a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
+++ b/arch/powerpc/cpu/mpc5xxx/u-boot.lds
@@ -41,13 +41,14 @@ SECTIONS
PROVIDE (erotext = .);
.reloc :
{
-KEEP(*(.got))
_GOT2_TABLE_ = .;
KEEP(*(.got2))
+KEEP(*(.got))
+PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
_FIXUP_TABLE_ = .;
KEEP(*(.fixup))
}
- __got2_entries = (_FIXUP_TABLE_ - _GOT2_TABLE_) 2;
+ __got2_entries = ((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_) 2) - 1;
__fixup_entries = (. - _FIXUP_TABLE_) 2;
.data:
diff --git a/arch/powerpc/cpu/mpc8220/u-boot.lds
b/arch/powerpc/cpu/mpc8220/u-boot.lds
index 63cbbd7..72ff671 100644
--- a/arch/powerpc/cpu/mpc8220/u-boot.lds
+++ b/arch/powerpc/cpu/mpc8220/u-boot.lds
@@ -40,13 +40,14 @@ SECTIONS
PROVIDE (erotext = .);
.reloc :
{
-KEEP(*(.got))
_GOT2_TABLE_ = .;
KEEP(*(.got2))
+KEEP(*(.got))
+PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
_FIXUP_TABLE_ = .;
KEEP(*(.fixup))
}
- __got2_entries = (_FIXUP_TABLE_ - _GOT2_TABLE_) 2;
+ __got2_entries = ((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_) 2) - 1;
__fixup_entries = (. - _FIXUP_TABLE_) 2;
.data:
diff --git a/arch/powerpc/cpu/mpc824x/u-boot.lds
b/arch/powerpc/cpu/mpc824x/u-boot.lds
index e7f2837..3b9299c 100644
--- a/arch/powerpc/cpu/mpc824x/u-boot.lds
+++ b/arch/powerpc/cpu/mpc824x/u-boot.lds
@@ -41,13 +41,14 @@ SECTIONS
PROVIDE (erotext = .);
.reloc :
{
-KEEP(*(.got))
_GOT2_TABLE_ = .;
KEEP(*(.got2))
+KEEP(*(.got))
+PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
_FIXUP_TABLE_ = .;
KEEP(*(.fixup))
}
- __got2_entries = (_FIXUP_TABLE_ - _GOT2_TABLE_) 2;
+ __got2_entries = ((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_) 2) - 1;
__fixup_entries = (. - _FIXUP_TABLE_) 2;
.data:
diff --git a/arch/powerpc/cpu/mpc8260/u-boot.lds
b/arch/powerpc/cpu/mpc8260/u-boot.lds
index ad2ce37..c76555e 100644
--- a/arch/powerpc/cpu/mpc8260/u-boot.lds
+++ b/arch/powerpc/cpu/mpc8260/u-boot.lds
@@ -40,13 +40,14 @@ SECTIONS
PROVIDE (erotext = .);
.reloc :
{
-KEEP(*(.got))
_GOT2_TABLE_ = .;
KEEP(*(.got2))
+KEEP(*(.got))
+PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
Re: [U-Boot] arm: Activating dcache breaks 'usb start' and 'tftpboot' on jadecpu
Le 03/12/2010 16:33, Wolfgang Denk a écrit : What is the reason that special handling is needed when dcache is enabled? If a driver doesn't use any DMA there should be no need as the dcache is only enabled for the RAM and not for any memory mapped IO if I understand the code in arch/arm/lib/cache-cp15.c right. On ARM, device write accesses are typically just store instructions (in C: assignments to a volatile pointer). With caches on, these accesses will be - guess what? cached, i. e. they are NOT written to the device, at least not immediately. And if you repeatedly read a register (like when polling for some status bit to change) these accesses will be cached, too. In addition to making sure that register reads/write are not bitten by caching, note that some controllers have DMA capabilities which require proper cache handling for DMA memory buffers -- typically flushing them from cache before a DMA to the device, and invalidating their cache entries after a DMA from the device. Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] DaVinci DM6446: Config Update
Hi Sandeep, Le 03/12/2010 16:37, s-paul...@ti.com a écrit : From: Sandeep Paulrajs-paul...@ti.com The DM6446 does not build due to the ARM relocation patch. Also the board does not build in the NOR mode. Changed default to NAND to ensure no build failure. What exactly is the build error message in NOR mode? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm: Activating dcache breaks 'usb start' and 'tftpboot' on jadecpu
Hello Wolfgang Am 03.12.2010 16:33, schrieb Wolfgang Denk: Dear =?ISO-8859-1?Q?Matthias_Wei=DFer?=, In message 4cf90819.7040...@arcor.de you wrote: Has anyone an explanation for this behavior? Is anyone out there having dcache running on an ARM926 and working usb/tftpboot? Many drivers have not been written to work with enabled caches. What is the reason that special handling is needed when dcache is enabled? If a driver doesn't use any DMA there should be no need as the dcache is only enabled for the RAM and not for any memory mapped IO if I understand the code in arch/arm/lib/cache-cp15.c right. On ARM, device write accesses are typically just store instructions (in C: assignments to a volatile pointer). With caches on, these accesses will be - guess what? cached, i. e. they are NOT written to the device, at least not immediately. And if you repeatedly read a register (like when polling for some status bit to change) these accesses will be cached, too. I understand this behavior. But it is only true if the memory area in question is marked as cacheable. As the memory mapped network controller (SMSC9221) is not cached it shouldn't be a problem or do I miss something here? You said you had enabled the data cache, so why do you think these accesses are not cached? Please see arch/arm/lib/cache-cp15.c The code there creates 4096 page table entries (1MB each) for the whole 4GB address space and initializes each entry in a way that it is not cacheable (mmu_setup():71). It then changes the page table entries which are pointing to a RAM area to make these, and only these, cacheable (dram_bank_mmu_setup():57). If the whole address space would be cached I would expect that even writing to NOR flash fails as the write accesses wouldn't reach the flash chip. But that works perfect on both of my systems. Thanks Matthias Weißer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm: Activating dcache breaks 'usb start' and 'tftpboot' on jadecpu
Am 03.12.2010 17:34, schrieb Albert ARIBAUD: In addition to making sure that register reads/write are not bitten by caching, note that some controllers have DMA capabilities which require proper cache handling for DMA memory buffers -- typically flushing them from cache before a DMA to the device, and invalidating their cache entries after a DMA from the device. This is true. DMA and caching can be a lot of fun for a driver developer :-) But I can guarantee that the network driver doesn't use any DMA transfer as the hardware doesn't support it. Thanks Matthias Weißer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm: Activating dcache breaks 'usb start' and 'tftpboot' on jadecpu
Dear =?ISO-8859-1?Q?Matthias_Wei=DFer?=, In message 4cf91e29.7000...@arcor.de you wrote: You said you had enabled the data cache, so why do you think these accesses are not cached? Please see arch/arm/lib/cache-cp15.c The code there creates 4096 page table entries (1MB each) for the whole 4GB address space and initializes each entry in a way that it is not cacheable (mmu_setup():71). It then changes the page table entries which are pointing to a RAM area to make these, and only these, cacheable (dram_bank_mmu_setup():57). You did not mention this before. You just said: I enabled dcache which for e sounds as if you did this globally. Well, I'm not an export for AT91 in any way... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The human mind treats a new idea the way the body treats a strange protein - it rejects it. - P. Medawar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] at91rm9200: fix lowlevel_init() SMRDATA size
Am 2010-12-03 08:26, schrieb Andreas Bießmann: SMRDATA in a/a/c/arm920t/at91/lowlevel_init.c has wrong size. This patch reduces it to correct size of 40 byte. Signed-off-by: Andreas Bießmann biessm...@corscience.de --- Dear all, I thougt about a problem in lowlevel_init() cause of errornous booting from NOR flash on at91rm9200ek last night . This morning I detected this, but the patch is untested! I can not test it til sunday, if one can test it before please send a mail (Jens?). Can you describe the symptoms? I will test tomorrow? regards Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] UBI/UBIFS: Automatically unmount UBIFS volume upon UBI partition change
Automatically unmount UBIFS partition when user changes the UBI device.
Otherwise the following UBIFS commands will crash.
Signed-off-by: Stefan Roese s...@denx.de
---
v2:
- Only try to unmount the ubifs partition if UBIFS is is really enabled.
Otherwise compiling fails.
common/cmd_ubi.c | 15 +++
common/cmd_ubifs.c | 26 --
2 files changed, 35 insertions(+), 6 deletions(-)
diff --git a/common/cmd_ubi.c b/common/cmd_ubi.c
index 7692ac7..b486ca8 100644
--- a/common/cmd_ubi.c
+++ b/common/cmd_ubi.c
@@ -42,6 +42,11 @@ struct selected_dev {
static struct selected_dev ubi_dev;
+#ifdef CONFIG_CMD_UBIFS
+int ubifs_is_mounted(void);
+void cmd_ubifs_umount(void);
+#endif
+
static void ubi_dump_vol_info(const struct ubi_volume *vol)
{
ubi_msg(volume information dump:);
@@ -472,6 +477,16 @@ static int do_ubi(cmd_tbl_t * cmdtp, int flag, int argc,
char * const argv[])
if (argc 3)
return cmd_usage(cmdtp);
+#ifdef CONFIG_CMD_UBIFS
+ /*
+* Automatically unmount UBIFS partition when user
+* changes the UBI device. Otherwise the following
+* UBIFS commands will crash.
+*/
+ if (ubifs_is_mounted())
+ cmd_ubifs_umount();
+#endif
+
/* todo: get dev number for NAND... */
ubi_dev.nr = 0;
diff --git a/common/cmd_ubifs.c b/common/cmd_ubifs.c
index 9526780..3cd2d8f 100644
--- a/common/cmd_ubifs.c
+++ b/common/cmd_ubifs.c
@@ -72,6 +72,25 @@ int do_ubifs_mount(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
return 0;
}
+int ubifs_is_mounted(void)
+{
+ return ubifs_mounted;
+}
+
+void cmd_ubifs_umount(void)
+{
+
+ if (ubifs_sb) {
+ printf(Unmounting UBIFS volume %s!\n,
+ ((struct ubifs_info *)(ubifs_sb-s_fs_info))-vi.name);
+ ubifs_umount(ubifs_sb-s_fs_info);
+ }
+
+ ubifs_sb = NULL;
+ ubifs_mounted = 0;
+ ubifs_initialized = 0;
+}
+
int do_ubifs_umount(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
if (argc != 1)
@@ -82,12 +101,7 @@ int do_ubifs_umount(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
return -1;
}
- if (ubifs_sb)
- ubifs_umount(ubifs_sb-s_fs_info);
-
- ubifs_sb = NULL;
- ubifs_mounted = 0;
- ubifs_initialized = 0;
+ cmd_ubifs_umount();
return 0;
}
--
1.7.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Jobs Openings in Canada
* You've waited long enough! It's time to firm up that getaway, to let loose, to create some memories. There's no time like the present to make it all happen,PEWCA is currently having great openings for proffesionals. Openings Petro Enwest Canada - PEWCA http://www.petroenerwestcanada.com/ Company Name : Petro Enerwest Ca Category : Employer www.petroenerwestcanada.com www.petroenerwestca.com PetroEnerwestca Address: A20, 2 Street SE, Calgary, Alberta, Canada Post Code T2H 2L8 Petro Enerwest Canada is currently among the largest natural gas companies in North America, committed to providing an abundant supply of natural gas - the cleanest burning fossil fuel - to our communities. We conduct our business ethically and responsibly while ensuring the health and safety of our employees and contractors, and respecting the integrity of our environment. Our people... are the foundation of our success. They share ideas to decrease costs, increase production, create a safer place to work and protect our environment. The talent, ingenuity, and technical leadership of our more than 3,800 employees and contractors means that we are able to invest for the long term. Our strategic focus... is natural gas, consisting of an unparalleled portfolio of eight key resource plays across Canada and the United States and Mexico. These resource plays are capable of delivering steady, reliable gas production for generations. We are a dynamic search firm that specializes in the placement of Engineers, Geologists, Geophysicists (including Professionals, In-Training and Technologists) in the oil gas industry in Western Canada. We recruit and place both technical and managerial candidates within all sectors of the marketplace. Our clients include a wide range of oil and gas companies such as Exploration Production, Midstream Pipeline, Engineering, Procurement Construction Management (EPCM), as well as service companies and fabrication shops. Specialization Petro Enerwest Canada focuses on Engineers, Technologists, Geologists and Geophysicists for the Canadian Oil and Gas marketplace. We talk to qualified professionals every day. Petro Enerwest Canada is firmly focused on the Oil and Gas industry. Our database of qualified candidates with relevant experience in Western Canada and the worldwide oil and gas market is unmatched. Rate Petro Enerwest Canada. performs permanent and contract recruiting services on a contingency basis. Fees will only be invoiced when an applicant, introduced by Petro Enerwest Canada accepts with your firm. The fee is determined by discipline and level of experience required. Petro Enerwest Canada continuously recruits talented, skilled employees in a broad range of disciplines including: Executives (Managers and VPs) ProcessExploitation ReservoirGeophysics Project EngineersCivil / Structural Operations Landmen Project Managers Drafting Facilities Environmental Electrical Procurement Drilling Business Development Instrumentation Controls Project Controls Pipeline Integrity QA / QC Mechanical Regualtory Geology We maintain one of the most skilled candidate databases in Calgary. Our recruitment process includes making every effort to gain a clear understanding of your staffing requirements, organizational values and the characteristics unique to your company. At Petro Enerwest Canada , we select only the most qualified individuals to service our clients. We fill permanent and contract positions with experienced professionals, helping in the formation of exceptional teams that succeed. All of our candidates are carefully pre-screened to ensure high standards. You’re a professional with solid experience. Now it’s time for the next step in your career: becoming part of a continuing success story. When you join Petro Enerwest Canada, you’re signing on with a major North American energy producer and marketer, and the first company to commercially produce crude oil from Alberta’s oil sands. At Petro Enerwest Canada, you’ll find a solid foundation for business and employee success: industry-leading experience, a reputation for social and environmental responsibility, an achievement-oriented culture, unlimited opportunities for career growth and a rewarding compensation package. Petro Enerwest Canada has good job opportunities for experienced professionals — engineers, accountants, project managers, geologists, administrative assistants, to name a few. If you’re ready to take your career in exciting new directions, view our career openings. Petro Enerwest Canada Position Name: (Contract) Workforce Mobility Advisor Job Family: Human Resources Country: Canada Province: Alberta City: Calgary Job Description: BUSINESS OVERVIEW: Take a close look at Petro Enerwest Canada . Being a pioneer and leader in of the oil sands industry, Petro Enerwest Canada’s team is one of the most talented in the energy industry. And that talented team is committed to growing our company in a sustainable, ethical way.
[U-Boot] [PATCH] powerpc: fix implementation of out_8 to match the other out_XX functions
Signed-off-by: Timur Tabi ti...@freescale.com
---
arch/powerpc/include/asm/io.h |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index 4ddad26..56ac9fe 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -175,7 +175,10 @@ extern inline int in_8(const volatile unsigned char
__iomem *addr)
extern inline void out_8(volatile unsigned char __iomem *addr, int val)
{
- __asm__ __volatile__(stb%U0%X0 %1,%0; eieio : =m (*addr) : r
(val));
+ __asm__ __volatile__(sync;\n
+stb%U0%X0 %1,%0;\n
+: =m (*addr)
+: r (val));
}
extern inline int in_le16(const volatile unsigned short __iomem *addr)
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [v2] p1022ds: fix switching of DIU/LBC signals
On the P1022, the pins which drive the video display (DIU) are muxed with the
local bus controller (LBC), so if the DIU is active, the pins need to be
temporarily muxed to LBC whenever accessing NOR flash.
The code which handled this transition is checking and changing the wrong
bits in PMUXCR.
Also add a follow-up read after a write to NOR flash if we're going to
mux back to DIU after the write, as described in the P1022 RM.
Signed-off-by: Timur Tabi ti...@freescale.com
---
I have no idea how this ever worked before, but without this fix, video on
the P1022DS is completely broken.
board/freescale/p1022ds/diu.c | 67 ++--
1 files changed, 57 insertions(+), 10 deletions(-)
diff --git a/board/freescale/p1022ds/diu.c b/board/freescale/p1022ds/diu.c
index 12b40a0..8f5305c 100644
--- a/board/freescale/p1022ds/diu.c
+++ b/board/freescale/p1022ds/diu.c
@@ -32,6 +32,7 @@
#define PMUXCR_ELBCDIU_MASK0xc000
#define PMUXCR_ELBCDIU_NOR16 0x8000
+#define PMUXCR_ELBCDIU_DIU 0x4000
/*
* DIU Area Descriptor
@@ -131,9 +132,8 @@ int platform_diu_init(unsigned int *xres, unsigned int
*yres)
px_brdcfg0 = in_8(lbc_lcs1_ba);
out_8(lbc_lcs1_ba, px_brdcfg0 | PX_BRDCFG0_ELBC_DIU);
- /* Setting PMUXCR to switch to DVI from ELBC */
- clrsetbits_be32(gur-pmuxcr,
- PMUXCR_ELBCDIU_MASK, PMUXCR_ELBCDIU_NOR16);
+ /* Set PMUXCR to switch the muxed pins from the LBC to the DIU */
+ clrsetbits_be32(gur-pmuxcr, PMUXCR_ELBCDIU_MASK, PMUXCR_ELBCDIU_DIU);
pmuxcr = in_be32(gur-pmuxcr);
return fsl_diu_init(*xres, pixel_format, 0);
@@ -161,7 +161,7 @@ static int set_mux_to_lbc(void)
ccsr_gur_t *gur = (void *)CONFIG_SYS_MPC85xx_GUTS_ADDR;
/* Switch the muxes only if they're currently set to DIU mode */
- if ((in_be32(gur-pmuxcr) PMUXCR_ELBCDIU_MASK) ==
+ if ((in_be32(gur-pmuxcr) PMUXCR_ELBCDIU_MASK) !=
PMUXCR_ELBCDIU_NOR16) {
/*
* In DIU mode, the PIXIS can only be accessed indirectly
@@ -216,8 +216,17 @@ void flash_write8(u8 value, void *addr)
int sw = set_mux_to_lbc();
__raw_writeb(value, addr);
- if (sw)
+ if (sw) {
+ /*
+* To ensure the post-write is completed to eLBC, software must
+* perform a dummy read from one valid address from eLBC space
+* before changing the eLBC_DIU from NOR mode to DIU mode.
+* set_mux_to_diu() includes a sync that will ensure the
+* __raw_readb() completes before it switches the mux.
+*/
+ __raw_readb(addr);
set_mux_to_diu();
+ }
}
void flash_write16(u16 value, void *addr)
@@ -225,8 +234,17 @@ void flash_write16(u16 value, void *addr)
int sw = set_mux_to_lbc();
__raw_writew(value, addr);
- if (sw)
+ if (sw) {
+ /*
+* To ensure the post-write is completed to eLBC, software must
+* perform a dummy read from one valid address from eLBC space
+* before changing the eLBC_DIU from NOR mode to DIU mode.
+* set_mux_to_diu() includes a sync that will ensure the
+* __raw_readb() completes before it switches the mux.
+*/
+ __raw_readb(addr);
set_mux_to_diu();
+ }
}
void flash_write32(u32 value, void *addr)
@@ -234,18 +252,47 @@ void flash_write32(u32 value, void *addr)
int sw = set_mux_to_lbc();
__raw_writel(value, addr);
- if (sw)
+ if (sw) {
+ /*
+* To ensure the post-write is completed to eLBC, software must
+* perform a dummy read from one valid address from eLBC space
+* before changing the eLBC_DIU from NOR mode to DIU mode.
+* set_mux_to_diu() includes a sync that will ensure the
+* __raw_readb() completes before it switches the mux.
+*/
+ __raw_readb(addr);
set_mux_to_diu();
+ }
}
void flash_write64(u64 value, void *addr)
{
int sw = set_mux_to_lbc();
+ uint32_t *p = addr;
- /* There is no __raw_writeq(), so do the write manually */
- *(volatile u64 *)addr = value;
- if (sw)
+ /*
+* There is no __raw_writeq(), so do the write manually. We don't trust
+* the compiler, so we use inline assembly.
+*/
+ __asm__ __volatile__(
+ stw%U0%X0 %2,%0;\n
+ stw%U1%X1 %3,%1;\n
+ : =m (*p), =m (*(p + 1))
+ : r ((uint32_t) (value 32)), r ((uint32_t) (value)));
+
+ if (sw) {
+ /*
+* To ensure the post-write is completed to eLBC, software must
+* perform a dummy read from one valid address from eLBC space
+
[U-Boot] RFC: Not overriding device-tree memory nodes
I am playing with loading of multiple Linux images on individual cores on a multi core system (P2020RDB for example) and would like to be able to provide the memory information for each node via the DTB as opposed to using the bootm_low and bootm_size environment variables. The env variables work; however, setting the environment variable for each node when we're already using the DTB to partition devices on the system seems confusing from the perspective of someone who is trying to configure and deploy a complex multi-core environment (8, 16, and more cores). Using the DTB's memory node is easily accomplished by adding some code to the ft_board_setup() to check if a valid memory/reg property exists (valid meaning that it is within the [bd_memstart, bd_memstart + bd_memsize] range) and honoring that. The issue that comes up is what to do when there is a valid range in the DTB and the user has also set a bootm_range. For example the user is doing some quick testing and wants to change the amount of memory for a node or two just for one run via the variables instead of re-building the DTB. My thought is to prioritize the environment variable over the DTB; however calling getenv_bootm_low() returns a valid value even if the user has not set so there's no way to tell if the user set it or not. I'd like to do one of two following to deal with this: 1) Add a parameter to getenv_bootm_low() that returns whether the variable is user set or a default value, getenv_bootm_low(user_set) for example. 2) Just make an assumption in ft_board_setup() if (bootm_low + bootm_size == bd_memstart + bd_memsize), the user did not set the value and we should honor what is in the DTB. I'm leaning with option 2 as it is not intrusive to other callers and less confusing in my opinion and I'll likely wrap the code to check for an existing memory/reg DTB entry in a new ft_bootm_fixup() function that can be used by any existing and future boards that implement CONFIG_OF_BOARD_SETUP. Thoughts? ~Deepak ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Best methodology for establishing memory timing parameters
Hello, I'm just getting started on targeting an MPC8641D design with Uboot. On our board design the memory is soldered-down so there's no SPD to read from. I'm using a BDI3000 and just trying to establish a valid 'config' file that initializes the processor and memory. The BDI3000 comes with a template config file for the mpc8641 so I'm naturally starting with that. However, it's rather painful to peruse the DDR data sheets and infer from their description what the proper values are for various memory-related config values for the mpc8641 processor (such as TIMING_CFG_0, DDR_SDRAM_IVAL, etc). What I'm wondering is if there is a quicker way to establish the proper memory params for the BDI3000 config and ultimately uboot. I have a listing of all the SPD params from the DDR manufacturer. Is there some place within the Uboot source code where I can plug-in all these values directly (into an array or struct) and just boot Uboot from flash and have it initialize the memory from that information... or do I just have to man-up and do it the hard way;) Thanks, Brent bbart...@xembedded.commailto:bbart...@xembedded.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/13] SBC8560: #define CONFIG_SYS_LBC_NO_SDRAM_INIT
On Dec 2, 2010, at 8:26 PM, Timur Tabi wrote: On Thu, Dec 2, 2010 at 5:45 PM, Becky Bruce bec...@kernel.crashing.org wrote: This is for boards that use the SDRAM mode on the LBC but don't require any additional setup. I'm merging all the initdram() calls into a single function for 85xx, and have to be able to distinguish between boards that require an sdram_init() function, and those that do not. We could have defined an empty sdram_init() but I hate doing that. Would a weak function be a better way to do this? Eeney meeney meiney mo. If the peanut gallery prefers, I can go that way. I don't actually like either solution very much. -B ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/13] SBC8560: #define CONFIG_SYS_LBC_NO_SDRAM_INIT
On Dec 2, 2010, at 8:26 PM, Peter Tyser wrote:
Hi Becky,
+/* Common ddr init for non-corenet fsl 85xx platforms */
+#ifndef CONFIG_FSL_CORENET
+phys_size_t initdram(int board_type)
+{
+phys_size_t dram_size = 0;
+
+puts(Initializing\n);
Any chance we can remove the puts() above? DRAM: is always printed
out directly before initdram is called, so I don't think the
Initializing message adds much benefit and slightly dirties the
output. For reference:
That's fine with me does anybody object to this? It's certainly easy to
change this now.
-Becky
I2C: ready
DRAM: Initializing
DDR: 2 GiB (DDR2, 64-bit, CL=5, ECC on)
FLASH: Executed from FLASH1
FLASH: 256 MiB
vs
I2C: ready
DRAM: DDR: 2 GiB (DDR2, 64-bit, CL=5, ECC on)
FLASH: Executed from FLASH1
FLASH: 256 MiB
Otherwise it looked good. I tested on the xpedite5170 that was a corner
case, and the xpedite5370 (mpc8572-based).
Acked-by: Peter Tyser pty...@xes-inc.com
Tested-by: Peter Tyser pty...@xes-inc.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2010.12-rc2 released
On Thu, 2010-12-02 at 20:40 -0800, Prafulla Wadaskar wrote: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Carlo Caione Sent: Friday, December 03, 2010 3:11 AM To: U-Boot@lists.denx.de Subject: Re: [U-Boot] [STATUS] v2010.12-rc2 released Some of the times, the boot hung after printing DRAM: 128 MiB, but never did it hang without printing anything. The same here. Beagleboard xM rev.A hangs after DRAM: 256 MiB For fix this, needs to change global variables in timer.c REF: http://lists.denx.de/pipermail/u-boot/2010-December/082834.html Applied but nothing is changed: Texas Instruments X-Loader 1.4.4ss (Dec 2 2010 - 21:40:58) Beagle xM Rev A Reading boot sector Loading u-boot.bin from mmc U-Boot 2010.12-rc2-00029-g49733aa-dirty (Dec 03 2010 - 22:05:44) OMAP3630/3730-GP ES1.0, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz OMAP3 Beagle board + LPDDR/NAND I2C: ready DRAM: 512 MiB Regards, -- Carlo Caione ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/13] SBC8560: #define CONFIG_SYS_LBC_NO_SDRAM_INIT
On Fri, 2010-12-03 at 14:54 -0600, Becky Bruce wrote:
On Dec 2, 2010, at 8:26 PM, Peter Tyser wrote:
Hi Becky,
+/* Common ddr init for non-corenet fsl 85xx platforms */
+#ifndef CONFIG_FSL_CORENET
+phys_size_t initdram(int board_type)
+{
+ phys_size_t dram_size = 0;
+
+ puts(Initializing\n);
Any chance we can remove the puts() above? DRAM: is always printed
out directly before initdram is called, so I don't think the
Initializing message adds much benefit and slightly dirties the
output. For reference:
That's fine with me does anybody object to this? It's certainly easy to
change this now.
I just noticed it now, but I'd also be in favor of getting rid of the
DDR: puts() at the end of initdram(). It doesn't add much value since
the specific DDR type is already printed out in board_add_ram_info().
Best,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] at91rm9200: fix lowlevel_init() SMRDATA size
Dear Jens, Am 03.12.2010 um 18:09 schrieb Jens Scharsig: Am 2010-12-03 08:26, schrieb Andreas Bießmann: SMRDATA in a/a/c/arm920t/at91/lowlevel_init.c has wrong size. This patch reduces it to correct size of 40 byte. Signed-off-by: Andreas Bießmann biessm...@corscience.de --- Dear all, I thougt about a problem in lowlevel_init() cause of errornous booting from NOR flash on at91rm9200ek last night . This morning I detected this, but the patch is untested! I can not test it til sunday, if one can test it before please send a mail (Jens?). Can you describe the symptoms? at91rm9200ek booting from NOR flash does not work with v2010.12-rc2 plus patchset 'get at91rm9200ek working with ARM relocation'. I can boot the at91rm9200ek_ram_config build with JTAG and confirm that no BSS values get written from beginning of board_init_f() til calling of relocate_code() cause of a modified version of the test-patch 'arm:board_init_f(): mirror BSS and check after each init_fnc()'. Cause of the fact that NOR booting and 'SDRAM booting' via JTAG only differ in TEXT_BASE and SKIP_LOWLEVEL_INIT I thought there might be an error in lowlevel_init(). I did not find any statement in a/a/c/arm920t/at91/lowlevel_init.c which may fail the boot, but I found out the SMRDATA section is wrongly handled. The SMRDATA is a list of ADDRESS:VALUE which is handled in pllloop() to initially setup PMC and SMC. However the register setup just before pllloop() is wrong (SMRDATA is not 80 byte big, it is 40 byte!) and therefore we take some data from SMRDATA1 section (again address:value list for SDRAM setup). Cause of that we write some SDRAM configuration registers twice. I assume the wrong parameter does not break the setup (maybe it does ... thats to find out). Nevertheless the setup is wrong. Beside that the whole lowlevel_init() for arm920t/at91 is not really well coded, this could be done better ... I will test tomorrow? It would be great if you can test that pllloop thing to indicate the wrong counter (80 instead of 40) did (or not) break anything. So the question is do we need that specific patch in v2010.12 to get arm920t/at91 boards working or is it a 'nice to have' for future releases, e.g. when we do a complete rework of the lowlevel_init() for arm920t/at91. regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/next] 74xx_7xx/mpc86xx/ppmc7xx: Fix do_reset() declaration
On Friday, December 03, 2010 11:28:47 Peter Tyser wrote: The following commit: commit 882b7d726febe65579d6502c271412ecb05821d7 Author: Mike Frysinger vap...@gentoo.org Date: Wed Oct 20 03:41:17 2010 -0400 do_reset: unify duplicate prototypes missed the 74xx_7xx and mpc86xx arches and the ppmc7xx board do_reset() functions which resulted in build errors such as: cpu.c:128: error: conflicting types for 'do_reset' include/command.h:102: error: previous declaration of 'do_reset' was here yeah, i just noticed this last nite too. when the patch was written, most boards were broken due to other common changes, so i had a hard time finding all the locations. examples/api/libgenwrap.c needs updating too, but we can post that in a diff chageset. Signed-off-by: Mike Frysinger vap...@gentoo.org -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/13] SBC8560: #define CONFIG_SYS_LBC_NO_SDRAM_INIT
On Dec 3, 2010, at 2:44 PM, Becky Bruce wrote: On Dec 2, 2010, at 8:26 PM, Timur Tabi wrote: On Thu, Dec 2, 2010 at 5:45 PM, Becky Bruce bec...@kernel.crashing.org wrote: This is for boards that use the SDRAM mode on the LBC but don't require any additional setup. I'm merging all the initdram() calls into a single function for 85xx, and have to be able to distinguish between boards that require an sdram_init() function, and those that do not. We could have defined an empty sdram_init() but I hate doing that. Would a weak function be a better way to do this? Eeney meeney meiney mo. If the peanut gallery prefers, I can go that way. I don't actually like either solution very much. I'd prefer reduce the number of #defines - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/next] 74xx_7xx/mpc86xx/ppmc7xx: Fix do_reset() declaration
On Friday, December 03, 2010 16:35:17 Mike Frysinger wrote: On Friday, December 03, 2010 11:28:47 Peter Tyser wrote: The following commit: commit 882b7d726febe65579d6502c271412ecb05821d7 Author: Mike Frysinger vap...@gentoo.org Date: Wed Oct 20 03:41:17 2010 -0400 do_reset: unify duplicate prototypes missed the 74xx_7xx and mpc86xx arches and the ppmc7xx board do_reset() functions which resulted in build errors such as: cpu.c:128: error: conflicting types for 'do_reset' include/command.h:102: error: previous declaration of 'do_reset' was here yeah, i just noticed this last nite too. when the patch was written, most boards were broken due to other common changes, so i had a hard time finding all the locations. examples/api/libgenwrap.c needs updating too, but we can post that in a diff chageset. also, because this is [next], i'm not sure if wolfgang will want to squash these fixes into the existing change -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] env_nand: Use nand_read_skip_bad instead of nand_read
The nand-read function returns an error code if correctable errors have
occurred.
This is not desirable, since the errors have been corrected!
This patch switches to the nand_read_skip_bad function which does not
return an error code if the errors are correctable.
Signed-off-by: Steve Sakoman steve.sako...@linaro.org
---
diff --git a/common/env_nand.c b/common/env_nand.c
index 4e8307a..7f6c917 100644
--- a/common/env_nand.c
+++ b/common/env_nand.c
@@ -297,7 +297,7 @@ int readenv(size_t offset, u_char * buf)
offset += blocksize;
} else {
char_ptr = buf[amount_loaded];
- if (nand_read(nand_info[0], offset, len, char_ptr))
+ if (nand_read_skip_bad(nand_info[0], offset, len,
char_ptr))
return 1;
offset += blocksize;
amount_loaded += len;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 0/2] Add support for bootstrap stage and compressed U-Boot image
Hi,
On 11/30/2010 11:35 PM, Luigi 'Comio' Mantellini wrote:
Look the following benchmark (qemu-mips board):
U-Boot Vanilla
179600 bytes u-boot.bin
Bootstrap code w/o compresion (memcpy)
189224 bytes u-boot-bootstrap.bin
-- size 105%
Bootstrap code using BZIP2 compression
114388 bytes u-boot-bootstrap.bin
--size 64%
Bootstrap code using GZIP compression
114204 bytes u-boot-bootstrap.bin
--size 64%
Bootstrap code using LZMA compression
89456 bytes u-boot-bootstrap.bin
--size 50% -- BEST
Bootstrap code using LZO compression
104388 bytes u-boot-bootstrap.bin
--size 58%
Personally, I don't much care about the size of U-Boot bin itself
(179kB or 104kB), but it depends. And I'd like to see how much boot
time of U-Boot improved on your environment.
The following patches introduce the bootstrap support that enable to have a
compressed U-Boot image. The bootstrap code supports the uncompressed as
well as compressed payloads, using LZMA, GZIP, BZIP2 and LZO.
Actually I developed just the mips version (using qemu-mips board)...
Please see the Patch #1 for the required defines to enable the required
features.
Not having a closer look at the patch yet, some general comments:
* Two patches posted, but contains multiple logical changes:
- CONFIG_BOOTSTRAP* build infrastructure (main body)
- common: Introduce console_bootstrap
- MIPS: Separate _machine_restart() and do_reset() into reset.c
- MIPS: config.mk: Append -g debug option to PLATFORM_CPPFLAGS,
which is already provided by $(TOPDIR)/config.mk.
- MIPS: qemu_mips: bootstrap support enablement (experimental)
Please break into logical changes, please.
* '_bootstrap' suffixed files are almost identical to the original
ones:
- arch/mips/cpu/reset{,_bootstrap}.c
- arch/mips/cpu/start{,_bootstrap}.S
- board/qemu-mips/u-boot{,_bootstrap}.lds
Is there any way not to duplicate them? Do we really need to have
_bootstrap files separated?
Once this bootstrap feature approved as general U-Boot feature, I'd
like to take MIPS-related changes.
Thanks,
Ralf
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 0/2] Add support for bootstrap stage and compressed U-Boot image
On 12/04/2010 11:32 AM, Shinya Kuribayashi wrote: Once this bootstrap feature approved as general U-Boot feature, I'd like to take MIPS-related changes. Thanks, Ralf Not Ralf! Needs two cups of coffee to wake up... Shinya ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 1/2] Add support for bootstrap stage that allows to have a compressed U-Boot image. The final image will named u-boot-bootstrap.
On Tuesday, November 30, 2010 05:30:47 luigi.mantell...@idf-hit.com wrote: /u-boot.bin +/u-boot.bin.bz2 +/u-boot.bin.gz +/u-boot.bin.lzma +/u-boot.bin.lzo better to have just one i think: /u-boot.bin* +/u-boot-bootstrap +/u-boot-bootstrap.hex +/u-boot-bootstrap.map +/u-boot-bootstrap.bin +/u-boot-bootstrap.bin.bz2 +/u-boot-bootstrap.bin.gz +/u-boot-bootstrap.bin.lzma +/u-boot-bootstrap.bin.lzo +/u-boot-bootstrap.dis +/u-boot-bootstrap.srec +/u-boot-bootstrap.ldr +/u-boot-bootstrap.ldr.hex +/u-boot-bootstrap.ldr.srec +/u-boot-bootstrap.lds same here: /u-boot-bootstrap* -COBJS-$(CONFIG_LZO) += lzo1x_decompress.o +COBJS-$(CONFIG_LZO)$(CONFIG_BOOTSTRAP_LZO) += lzo1x_decompress.o + +COBJS-y += $(OBJS-yy) you sure this works when both config symbols are set ? -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC 0/3] Enhance env tools
There are circustances where it is desirable to run the environment tools on your build machine in order to create an environment image that can be written to the target machine at a later time. This patch series introduces a number of enhancements to the tools that make this possible. The first patch allows allows one to override the default location of the tool config file by setting a FW_CONFIG_FILE environment variable. The second patch allows the environment to be written to a regular file. The third patch increases the devname length to 4096 in order to support writing to normal files in addition to mtd devices. Loïc Minier (3): tools/env: Default to the config specified in FW_CONFIG_FILE tools/env: Support writing to files tools/env: Bump devname length to PATH_MAX for filenames tools/env/fw_env.c | 107 1 files changed, 74 insertions(+), 33 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC 1/3] tools/env: Default to the config specified in FW_CONFIG_FILE
From: Loïc Minier loic.min...@linaro.org
This patch allows one to override the default location of
the config file by setting FW_CONFIG_FILE environment variable.
Signed-off-by: Loïc Minier loic.min...@linaro.org
Tested-by: Steve Sakoman st...@sakoman.com
---
tools/env/fw_env.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index 8ff7052..75f6a98 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -1224,8 +1224,15 @@ static int parse_config ()
struct stat st;
#if defined(CONFIG_FILE)
+ /* Default to the config file specified in FW_CONFIG_FILE */
+ char *config_file = getenv(FW_CONFIG_FILE);
+ if (!config_file || !strlen(config_file)) {
+ /* If unset or empty use the default config file */
+ config_file = CONFIG_FILE;
+ }
+
/* Fills in DEVNAME(), ENVSIZE(), DEVESIZE(). Or don't. */
- if (get_config (CONFIG_FILE)) {
+ if (get_config (config_file)) {
fprintf (stderr,
Cannot parse config file: %s\n, strerror (errno));
return -1;
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC 2/3] tools/env: Support writing to files
From: Loïc Minier loic.min...@linaro.org
Track st_mode and use it to skip ioctls on file-backed fds. This allows
writing to regular files transparently.
Signed-off-by: Loïc Minier loic.min...@linaro.org
Tested-by: Steve Sakoman steve.sako...@linaro.org
---
tools/env/fw_env.c | 92 ++-
1 files changed, 61 insertions(+), 31 deletions(-)
diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index 75f6a98..d2f9748 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -60,6 +60,7 @@ struct envdev_s {
ulong erase_size; /* device erase size */
ulong env_sectors; /* number of environment sectors */
uint8_t mtd_type; /* type of the MTD device */
+ mode_t st_mode; /* protection / file type */
};
static struct envdev_s envdevices[2] =
@@ -78,6 +79,7 @@ static int dev_current;
#define DEVESIZE(i) envdevices[(i)].erase_size
#define ENVSECTORS(i) envdevices[(i)].env_sectors
#define DEVTYPE(i)envdevices[(i)].mtd_type
+#define STMODE(i) envdevices[(i)].st_mode
#define CONFIG_ENV_SIZE ENVSIZE(dev_current)
@@ -633,8 +635,12 @@ int fw_parse_script(char *fname)
* 0 - block is bad
* 0 - failed to test
*/
-static int flash_bad_block (int fd, uint8_t mtd_type, loff_t *blockstart)
+static int flash_bad_block (int fd, uint8_t mtd_type, loff_t *blockstart,
+ int is_mtd)
{
+ if (!is_mtd)
+ return 0;
+
if (mtd_type == MTD_NANDFLASH) {
int badblock = ioctl (fd, MEMGETBADBLOCK, blockstart);
@@ -661,7 +667,7 @@ static int flash_bad_block (int fd, uint8_t mtd_type,
loff_t *blockstart)
* the DEVOFFSET (dev) block. On NOR the loop is only run once.
*/
static int flash_read_buf (int dev, int fd, void *buf, size_t count,
- off_t offset, uint8_t mtd_type)
+ off_t offset, uint8_t mtd_type, int is_mtd)
{
size_t blocklen;/* erase / write length - one block on NAND,
0 on NOR */
@@ -683,7 +689,7 @@ static int flash_read_buf (int dev, int fd, void *buf,
size_t count,
/* Offset inside a block */
block_seek = offset - blockstart;
- if (mtd_type == MTD_NANDFLASH) {
+ if (!is_mtd || mtd_type == MTD_NANDFLASH) {
/*
* NAND: calculate which blocks we are reading. We have
* to read one block at a time to skip bad blocks.
@@ -707,7 +713,7 @@ static int flash_read_buf (int dev, int fd, void *buf,
size_t count,
/* This only runs once on NOR flash */
while (processed count) {
- rc = flash_bad_block (fd, mtd_type, blockstart);
+ rc = flash_bad_block (fd, mtd_type, blockstart, is_mtd);
if (rc 0) /* block test failed */
return -1;
@@ -754,7 +760,7 @@ static int flash_read_buf (int dev, int fd, void *buf,
size_t count,
* the whole data at once.
*/
static int flash_write_buf (int dev, int fd, void *buf, size_t count,
- off_t offset, uint8_t mtd_type)
+ off_t offset, uint8_t mtd_type, int is_mtd)
{
void *data;
struct erase_info_user erase;
@@ -812,7 +818,7 @@ static int flash_write_buf (int dev, int fd, void *buf,
size_t count,
}
rc = flash_read_buf (dev, fd, data, write_total, erase_offset,
-mtd_type);
+mtd_type, is_mtd);
if (write_total != rc)
return -1;
@@ -826,7 +832,7 @@ static int flash_write_buf (int dev, int fd, void *buf,
size_t count,
data = buf;
}
- if (mtd_type == MTD_NANDFLASH) {
+ if (!is_mtd || mtd_type == MTD_NANDFLASH) {
/*
* NAND: calculate which blocks we are writing. We have
* to write one block at a time to skip bad blocks.
@@ -840,7 +846,7 @@ static int flash_write_buf (int dev, int fd, void *buf,
size_t count,
/* This only runs once on NOR flash */
while (processed write_total) {
- rc = flash_bad_block (fd, mtd_type, blockstart);
+ rc = flash_bad_block (fd, mtd_type, blockstart, is_mtd);
if (rc 0) /* block test failed */
return rc;
@@ -854,14 +860,16 @@ static int flash_write_buf (int dev, int fd, void *buf,
size_t count,
continue;
}
- erase.start = blockstart;
- ioctl (fd, MEMUNLOCK, erase);
+ if (is_mtd) {
+ erase.start = blockstart;
+ ioctl (fd, MEMUNLOCK, erase);
- if (ioctl (fd, MEMERASE, erase) != 0) {
- fprintf (stderr, MTD erase
[U-Boot] [RFC 3/3] tools/env: Bump devname length to PATH_MAX for filenames
From: Loïc Minier loic.min...@linaro.org
This patch increases the devname length to 4096 in order to support writing
to normal files in addition to mtd devices.
Signed-off-by: Loïc Minier loic.min...@linaro.org
Tested-by: Steve Sakoman steve.sako...@linaro.org
---
tools/env/fw_env.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index d2f9748..a75b73b 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -53,8 +53,12 @@
(void) (_min1 == _min2); \
_min1 _min2 ? _min1 : _min2; })
+#ifndef PATH_MAX
+#define PATH_MAX 4096
+#endif
+
struct envdev_s {
- char devname[16]; /* Device name */
+ char devname[PATH_MAX]; /* Device name */
ulong devoff; /* Device offset */
ulong env_size; /* environment size */
ulong erase_size; /* device erase size */
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] OMAP: Hang after memory init, was: [STATUS] v2010.12-rc2 released
On 03.12.2010 22:11, Carlo Caione wrote: On Thu, 2010-12-02 at 20:40 -0800, Prafulla Wadaskar wrote: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Carlo Caione Sent: Friday, December 03, 2010 3:11 AM To: U-Boot@lists.denx.de Subject: Re: [U-Boot] [STATUS] v2010.12-rc2 released Some of the times, the boot hung after printing DRAM: 128 MiB, but never did it hang without printing anything. The same here. Beagleboard xM rev.A hangs after DRAM: 256 MiB For fix this, needs to change global variables in timer.c REF: http://lists.denx.de/pipermail/u-boot/2010-December/082834.html Applied but nothing is changed: Texas Instruments X-Loader 1.4.4ss (Dec 2 2010 - 21:40:58) Beagle xM Rev A Reading boot sector Loading u-boot.bin from mmc U-Boot 2010.12-rc2-00029-g49733aa-dirty (Dec 03 2010 - 22:05:44) OMAP3630/3730-GP ES1.0, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz OMAP3 Beagle board + LPDDR/NAND I2C: ready DRAM: 512 MiB I'm not totally sure, so sorry if I'm wrong. But: I understood the link given by Prafulla above only as a reference what has to be done to fix the OMAP hang. I don't think the given patch fixes the issue itself. Most probably we additionally need something like http://lists.denx.de/pipermail/u-boot/2010-December/082965.html for OMAP, too? Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH][NEXT] mpc52xx: add support for tqm52xx based board charon
- serial console in PSC1
- 128MiB DRAM
- 32MiB Flash
- FEC Ethernet
- 2 I2C busses
- FPGA on CS3
- IDE
- VGA SMI501
Signed-off-by: Heiko Schocher h...@denx.de
---
MAINTAINERS |1 +
board/tqc/tqm5200/tqm5200.c | 170 ++-
boards.cfg |1 +
include/configs/TQM5200.h | 26 --
include/configs/charon.h| 80
5 files changed, 268 insertions(+), 10 deletions(-)
create mode 100644 include/configs/charon.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 986e0dc..fc6bae9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -414,6 +414,7 @@ Georg Schardt scha...@team-ctech.de
Heiko Schocher h...@denx.de
+ charon MPC5200
ids8247 MPC8247
jupiter MPC5200
kmeter1 MPC8360
diff --git a/board/tqc/tqm5200/tqm5200.c b/board/tqc/tqm5200/tqm5200.c
index 263a2af..419dec0 100644
--- a/board/tqc/tqm5200/tqm5200.c
+++ b/board/tqc/tqm5200/tqm5200.c
@@ -54,6 +54,47 @@ DECLARE_GLOBAL_DATA_PTR;
void ps2mult_early_init(void);
#endif
+#if defined(CONFIG_VIDEO)
+/*
+ * EDID block has been generated using Phoenix EDID Designer 1.3.
+ * This tool creates a text file containing:
+ *
+ * EDID BYTES:
+ *
+ * 0x 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
+ *
+ * 00 | 00 FF FF FF FF FF FF 00 04 21 00 00 00 00 00 00
+ * 10 | 01 00 01 03 00 00 00 00 00 00 00 00 00 00 00 00
+ * 20 | 00 00 00 21 00 00 01 01 01 01 01 01 01 01 01 01
+ * 30 | 01 01 01 01 01 01 64 00 00 00 00 00 00 00 00 00
+ * 40 | 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00
+ * 50 | 00 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00
+ * 60 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10
+ * 70 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 17
+ *
+ * Then this data has been manually converted to the char
+ * array below.
+ */
+static unsigned char edid_buf[128] = {
+ 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00,
+ 0x04, 0x21, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x01, 0x00, 0x01, 0x03, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x21, 0x00, 0x00, 0x01, 0x01,
+ 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
+ 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x64, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x17,
+};
+#endif
+
#ifndef CONFIG_SYS_RAMBOOT
static void sdram_start (int hi_addr)
{
@@ -251,6 +292,8 @@ int checkboard (void)
# define CARRIER_NAME CAM5200
#elif defined(CONFIG_FO300)
# define CARRIER_NAME FO300
+#elif defined(CONFIG_CHARON)
+# define CARRIER_NAME CHARON
#else
# error UNKNOWN
#endif
@@ -429,6 +472,111 @@ int board_early_init_f (void)
}
#endif /* CONFIG_FO300 */
+#if defined(CONFIG_CHARON)
+#include i2c.h
+#include asm/io.h
+
+/* The TFP410 registers */
+#define TFP410_REG_VEN_ID_L 0x00
+#define TFP410_REG_VEN_ID_H 0x01
+#define TFP410_REG_DEV_ID_L 0x02
+#define TFP410_REG_DEV_ID_H 0x03
+#define TFP410_REG_REV_ID 0x04
+
+#define TFP410_REG_CTL_1_MODE 0x08
+#define TFP410_REG_CTL_2_MODE 0x09
+#define TFP410_REG_CTL_3_MODE 0x0A
+
+#define TFP410_REG_CFG 0x0B
+
+#define TFP410_REG_DE_DLY 0x32
+#define TFP410_REG_DE_CTL 0x33
+#define TFP410_REG_DE_TOP 0x34
+#define TFP410_REG_DE_CNT_L 0x36
+#define TFP410_REG_DE_CNT_H 0x37
+#define TFP410_REG_DE_LIN_L 0x38
+#define TFP410_REG_DE_LIN_H 0x39
+
+#define TFP410_REG_H_RES_L 0x3A
+#define TFP410_REG_H_RES_H 0x3B
+#define TFP410_REG_V_RES_L 0x3C
+#define TFP410_REG_V_RES_H 0x3D
+
+static int tfp410_read_reg(int reg, uchar *buf)
+{
+ if (i2c_read(CONFIG_SYS_TFP410_ADDR, reg, 1, buf, 1) != 0) {
+ puts (Error reading the chip.\n);
+ return 1;
+ }
+ return 0;
+}
+
+static int tfp410_write_reg(int reg, uchar buf)
+{
+ if (i2c_write(CONFIG_SYS_TFP410_ADDR, reg, 1, buf, 1) != 0) {
+ puts (Error writing the chip.\n);
+ return 1;
+ }
+ return 0;
+}
+
+typedef struct _tfp410_config {
+ int reg;
+ uchar val;
+}TFP410_CONFIG;
+
+static TFP410_CONFIG tfp410_configtbl[] = {
+ {TFP410_REG_CTL_1_MODE, 0x37},
+ {TFP410_REG_CTL_2_MODE, 0x20},
+ {TFP410_REG_CTL_3_MODE, 0x80},
+ {TFP410_REG_DE_DLY, 0x90},
+ {TFP410_REG_DE_CTL, 0x00},
+ {TFP410_REG_DE_TOP, 0x23},
+ {TFP410_REG_DE_CNT_H, 0x02},
+ {TFP410_REG_DE_CNT_L, 0x80},
+ {TFP410_REG_DE_LIN_H, 0x01},
+
