Re: [U-Boot] [PATCH 1/2] I2C: add Marvell TWSI simple driver
Le 27/08/2010 07:25, Heiko Schocher a écrit : +#defineMVTWSI_STATUS_DATA_R_NAK0x58 /* our NAK, not the slave's */ line too long. Checkpatch did not complain on this one. Is there a specific line length contraint beside passing checkpatch? Yep, 78 characters. Ok. I added a possibility for checkpatch to accept a custom line length; I'll try and push that to the lkml. Meanwhile, it showed me three lines beyond 78 characters, fixed. Which blank line exactly? Between the comment block and code? If so, Yes. does this apply everywhere, i.e. after the topmost license comment block, before blocks of #define, etc? No, there, it is Ok. Fixed, thanks. As a side note, if V2 gets Acked by Prafulla and you, can you add the commit to your i2c tree and ask for a new pull? Anyway, Wolfgang said he won't resume activity on u-boot before sep 5th. Yes, if I and Prafulla accept it, this is the usual way. Here you go, then. :) Thanks for your review. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 0/4] Improve I2C for orion5x, kirkwood and ED Mini V2
SUMMARY: This patchset improves the driver for the Marvell TWSI interface found on orion5x and kirkwood SoCs and adds I2C support to the orion5x-based ED Mini V2 board. The mvtwsi driver is a complete rewrite, 50% shorter in source code lines, 25% smaller in object size, much simpler and way faster than the kirkwood_i2c driver it replaces. PATCH SET: Patch 1 removes dependencies on kirwkood_i2c from suen3, the only board that mentioned it. Patch 2 renames the driver from kirkwood_i2c to mvtwsi. Patch 3 replaces the old code with the new one. Patch 4 adds support for I2C in orion5x-based ED Mini V2. TESTS: This driver has been tested on an ED Mini V2 with basic u-boot i2c commands, on an 5C372a RTC and an HT24LC08 1 KB eeprom (read+write). HISTORY: V1: Initial submission as an addition rather than a replacement. V2: Fixed copyright line. Made mvtwsi a replacement for kirkwood_i2c. Made patches checkpatch-clean: 0 errors, 0 warnings. Various cosmetic changes. Removed useless i2c_end() function. V3: Reduced line lengths below 78 characters. Removed blank line after function description block comment. Albert Aribaud (4): suen3: remove CONFIG_HARD_I2C and related defines i2c: rename kirkwood_i2c to mvtwsi i2c: rewrite mvtwsi, support orion5x and kirkwood edminiv2: add I2C support using mvtwsi driver drivers/i2c/Makefile |2 +- drivers/i2c/kirkwood_i2c.c | 496 drivers/i2c/mvtwsi.c | 422 + include/configs/edminiv2.h |9 + include/configs/km_arm.h |8 - 5 files changed, 432 insertions(+), 505 deletions(-) delete mode 100644 drivers/i2c/kirkwood_i2c.c create mode 100644 drivers/i2c/mvtwsi.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 1/4] suen3: remove CONFIG_HARD_I2C and related defines
These are not used on this board, which uses soft I2C instead. Signed-off-by: Albert Aribaud albert.arib...@free.fr --- include/configs/km_arm.h |8 1 files changed, 0 insertions(+), 8 deletions(-) diff --git a/include/configs/km_arm.h b/include/configs/km_arm.h index 6519c90..1617e69 100644 --- a/include/configs/km_arm.h +++ b/include/configs/km_arm.h @@ -142,16 +142,8 @@ /* * I2C related stuff */ -#undef CONFIG_HARD_I2C /* I2C with hardware support */ #defineCONFIG_SOFT_I2C /* I2C bit-banged */ -#if defined(CONFIG_HARD_I2C) -#defineCONFIG_I2C_KIRKWOOD -#defineCONFIG_I2C_KW_REG_BASE KW_TWSI_BASE -#defineCONFIG_SYS_I2C_SLAVE0x0 -#defineCONFIG_SYS_I2C_SPEED10 -#endif - #defineCONFIG_KIRKWOOD_GPIO/* Enable GPIO Support */ #if defined(CONFIG_SOFT_I2C) #ifndef __ASSEMBLY__ -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 2/4] i2c: rename kirkwood_i2c to mvtwsi
This driver is not kirkwood-specific and can also be used
e.g. by orion5x. Rename to a SoC-neutral name.
Signed-off-by: Albert Aribaud albert.arib...@free.fr
---
drivers/i2c/Makefile |2 +-
drivers/i2c/{kirkwood_i2c.c = mvtwsi.c} |0
2 files changed, 1 insertions(+), 1 deletions(-)
rename drivers/i2c/{kirkwood_i2c.c = mvtwsi.c} (100%)
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index d2c2515..ae04d53 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -28,7 +28,7 @@ LIB := $(obj)libi2c.a
COBJS-$(CONFIG_BFIN_TWI_I2C) += bfin-twi_i2c.o
COBJS-$(CONFIG_DRIVER_DAVINCI_I2C) += davinci_i2c.o
COBJS-$(CONFIG_FSL_I2C) += fsl_i2c.o
-COBJS-$(CONFIG_I2C_KIRKWOOD) += kirkwood_i2c.o
+COBJS-$(CONFIG_I2C_DRIVER_MVTWSI) += mvtwsi.o
COBJS-$(CONFIG_I2C_MXC) += mxc_i2c.o
COBJS-$(CONFIG_DRIVER_OMAP1510_I2C) += omap1510_i2c.o
COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o
diff --git a/drivers/i2c/kirkwood_i2c.c b/drivers/i2c/mvtwsi.c
similarity index 100%
rename from drivers/i2c/kirkwood_i2c.c
rename to drivers/i2c/mvtwsi.c
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 4/4] edminiv2: add I2C support using mvtwsi driver
Signed-off-by: Albert Aribaud albert.arib...@free.fr --- include/configs/edminiv2.h |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/include/configs/edminiv2.h b/include/configs/edminiv2.h index 57dd165..36ed392 100644 --- a/include/configs/edminiv2.h +++ b/include/configs/edminiv2.h @@ -182,6 +182,15 @@ #endif /* CMD_IDE */ /* + * I2C related stuff + */ +#define CONFIG_I2C_DRIVER_MVTWSI +#define CONFIG_I2C_MVTWSI_BASE ORION5X_TWSI_BASE +#define CONFIG_SYS_I2C_SLAVE 0x0 +#define CONFIG_SYS_I2C_SPEED 10 +#define CONFIG_CMD_I2C + +/* * Environment variables configurations */ #define CONFIG_ENV_IS_IN_FLASH 1 -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 3/4] i2c: rewrite mvtwsi, support orion5x and kirkwood
This rewrite of the mvtwsi driver is 25% smaller and much
faster and simpler than the previous code.
Signed-off-by: Albert Aribaud albert.arib...@free.fr
---
drivers/i2c/mvtwsi.c | 742 +++---
1 files changed, 334 insertions(+), 408 deletions(-)
diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c
index a4409be..e7f08ac 100644
--- a/drivers/i2c/mvtwsi.c
+++ b/drivers/i2c/mvtwsi.c
@@ -1,10 +1,7 @@
/*
- * Driver for the i2c controller on the Marvell line of host bridges
- * (e.g, gt642[46]0, mv643[46]0, mv644[46]0, Orion SoC family),
- * and Kirkwood family.
+ * Driver for the TWSI (i2c) controller on the Marvell orion5x
*
- * Based on:
- * Author: Mark A. Greer mgr...@mvista.com
+ * Author: Albert Aribaud albert.arib...@free.fr
* 2005 (c) MontaVista, Software, Inc.
*
* See file CREDITS for list of people who contributed to this
@@ -24,473 +21,402 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
* MA 02110-1301 USA
- *
- * ported from Linux to u-boot
- * (C) Copyright 2009
- * Heiko Schocher, DENX Software Engineering, h...@denx.de.
*/
+
#include common.h
#include i2c.h
-#include asm/arch/kirkwood.h
#include asm/errno.h
#include asm/io.h
-DECLARE_GLOBAL_DATA_PTR;
+/*
+ * include a file that will provide CONFIG_I2C_MVTWSI_BASE
+ * and possibly other settings
+ */
-static unsigned int i2c_bus_num __attribute__ ((section (.data))) = 0;
-#if defined(CONFIG_I2C_MUX)
-static unsigned int i2c_bus_num_mux __attribute__ ((section (data))) = 0;
+#if defined(CONFIG_ORION5X)
+#include asm/arch/orion5x.h
+#else
+#error Driver mvtwsi not supported by SoC or board
#endif
-/* Register defines */
-#defineKW_I2C_REG_SLAVE_ADDR 0x00
-#defineKW_I2C_REG_DATA 0x04
-#defineKW_I2C_REG_CONTROL 0x08
-#defineKW_I2C_REG_STATUS 0x0c
-#defineKW_I2C_REG_BAUD 0x0c
-#defineKW_I2C_REG_EXT_SLAVE_ADDR 0x10
-#defineKW_I2C_REG_SOFT_RESET 0x1c
-
-#defineKW_I2C_REG_CONTROL_ACK 0x0004
-#defineKW_I2C_REG_CONTROL_IFLG 0x0008
-#defineKW_I2C_REG_CONTROL_STOP 0x0010
-#defineKW_I2C_REG_CONTROL_START0x0020
-#defineKW_I2C_REG_CONTROL_TWSIEN 0x0040
-#defineKW_I2C_REG_CONTROL_INTEN0x0080
-
-/* Ctlr status values */
-#defineKW_I2C_STATUS_BUS_ERR 0x00
-#defineKW_I2C_STATUS_MAST_START0x08
-#defineKW_I2C_STATUS_MAST_REPEAT_START 0x10
-#defineKW_I2C_STATUS_MAST_WR_ADDR_ACK 0x18
-#defineKW_I2C_STATUS_MAST_WR_ADDR_NO_ACK 0x20
-#defineKW_I2C_STATUS_MAST_WR_ACK 0x28
-#defineKW_I2C_STATUS_MAST_WR_NO_ACK0x30
-#defineKW_I2C_STATUS_MAST_LOST_ARB 0x38
-#defineKW_I2C_STATUS_MAST_RD_ADDR_ACK 0x40
-#defineKW_I2C_STATUS_MAST_RD_ADDR_NO_ACK 0x48
-#defineKW_I2C_STATUS_MAST_RD_DATA_ACK 0x50
-#defineKW_I2C_STATUS_MAST_RD_DATA_NO_ACK 0x58
-#defineKW_I2C_STATUS_MAST_WR_ADDR_2_ACK0xd0
-#defineKW_I2C_STATUS_MAST_WR_ADDR_2_NO_ACK 0xd8
-#defineKW_I2C_STATUS_MAST_RD_ADDR_2_ACK0xe0
-#defineKW_I2C_STATUS_MAST_RD_ADDR_2_NO_ACK 0xe8
-#defineKW_I2C_STATUS_NO_STATUS 0xf8
-
-/* Driver states */
-enum {
- KW_I2C_STATE_INVALID,
- KW_I2C_STATE_IDLE,
- KW_I2C_STATE_WAITING_FOR_START_COND,
- KW_I2C_STATE_WAITING_FOR_ADDR_1_ACK,
- KW_I2C_STATE_WAITING_FOR_ADDR_2_ACK,
- KW_I2C_STATE_WAITING_FOR_SLAVE_ACK,
- KW_I2C_STATE_WAITING_FOR_SLAVE_DATA,
-};
+/*
+ * TWSI register structure
+ */
-/* Driver actions */
-enum {
- KW_I2C_ACTION_INVALID,
- KW_I2C_ACTION_CONTINUE,
- KW_I2C_ACTION_SEND_START,
- KW_I2C_ACTION_SEND_ADDR_1,
- KW_I2C_ACTION_SEND_ADDR_2,
- KW_I2C_ACTION_SEND_DATA,
- KW_I2C_ACTION_RCV_DATA,
- KW_I2C_ACTION_RCV_DATA_STOP,
- KW_I2C_ACTION_SEND_STOP,
+struct mvtwsi_registers {
+ u32 slave_address;
+ u32 data;
+ u32 control;
+ union {
+ u32 status; /* when reading */
+ u32 baudrate; /* when writing */
+ };
+ u32 extended_slave_address;
+ u32 reserved[2];
+ u32 soft_reset;
};
-/* defines to get compatible with Linux driver */
-#define IRQ_NONE 0x0
-#define IRQ_HANDLED0x01
+/*
+ * Control register fields
+ */
-#define I2C_M_TEN 0x01
-#define I2C_M_RD 0x02
-#defineI2C_M_REV_DIR_ADDR 0x04;
+#defineMVTWSI_CONTROL_ACK 0x0004
+#defineMVTWSI_CONTROL_IFLG
[U-Boot] Kernel panic - not syncing: No init found. Try passing init= option to kernel.
Hello All, Even though there are several posts on the net on the same, I could not find a concrete solution for the same. I am using the prebuilt binaries from the www.AT91.com for AT91SAM9G20 linux kernel and jffs2 file system. I strongly feel if there is an issue with the bootargs and hence the U-boot environment is also available below. Please help me to solve this problem. U-Boot printenv bootcmd=nand read 0x2200 0xA 0x20; bootm bootdelay=3 baudrate=115200 ethact=macb0 ethaddr=3e:36:65:ba:6f:be ipaddr=199.63.247.50 serverip=199.63.247.100 stdin=serial stdout=serial stderr=serial bootargs=mem=64M console=ttyS0,115200 root=mtd2 rw rootfstype=jffs2 Environment size: 274/131067 bytes U-Boot tftp 0x2140 genericfs.arm_nofpu.jffs2 macb0: link up, 100Mbps full-duplex (lpa: 0xc5e1) Using macb0 device TFTP from server 199.63.247.100; our IP address is 199.63.247.50 Filename 'genericfs.arm_nofpu.jffs2'. Load address: 0x2140 Loading: # # # # # # # # # # # # # done Bytes transferred = 12985524 (c624b4 hex) U-Boot nand write.jffs2 0x2140 0x2A 0xc624b4 NAND write: device 0 offset 0x2a, size 0xc624b4 Writing data at 0xf02000 -- 100% complete. 12985524 bytes written: OK U-Boot tftp 0x2140 linux-2.6.27.bin macb0: link up, 100Mbps full-duplex (lpa: 0xc5e1) Using macb0 device TFTP from server 199.63.247.100; our IP address is 199.63.247.50 Filename 'linux-2.6.27.bin'. Load address: 0x2140 Loading: # ## done Bytes transferred = 1498980 (16df64 hex) U-Boot bootm ## Booting kernel from Legacy Image at 2140 ... Image Name: linux-2.6 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1498916 Bytes = 1.4 MB Load Address: 20008000 Entry Point: 20008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux. done, booting the kernel. Linux version 2.6.27 (nfe...@bendor) (gcc version 4.2.0 20070413 (prerelease) (CodeSourcery Sourcery G++ Lite 2007q1-10)) #1 Thu Sep 24 17:26:24 CEST 2009 CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 Machine: Atmel AT91SAM9G20-EK Memory policy: ECC disabled, Data cache writeback Clocks: CPU 396 MHz, master 132 MHz, main 18.432 MHz CPU0: D VIVT write-back cache CPU0: I cache: 32768 bytes, associativity 4, 32 byte lines, 256 sets CPU0: D cache: 32768 bytes, associativity 4, 32 byte lines, 256 sets Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: mem=64M console=ttyS0,115200 root=mtd2 rw rootfstype=jffs2 AT91: 96 gpio irqs in 3 banks PID hash table entries: 256 (order: 8, 1024 bytes) Console: colour dummy device 80x30 console [ttyS0] enabled Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 64MB = 64MB total Memory: 61760KB available (2756K code, 225K data, 120K init) Calibrating delay loop... 197.83 BogoMIPS (lpj=989184) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok net_namespace: 288 bytes NET: Registered protocol family 16 AT91: Power Management AT91: Starting after general reset SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 2048 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered NET: Registered protocol family 1 NetWinder Floating Point Emulator V0.97 (double precision) JFFS2 version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc. msgmni has been set to 120 io scheduler noop registered io scheduler anticipatory registered (default) atmel_usart.0: ttyS0 at MMIO 0xfefff200 (irq = 1) is a ATMEL_SERIAL atmel_usart.1: ttyS1 at
Re: [U-Boot] TFTP timeout issue while downloading the linux kernel in openpxa vpac270 u-boot source code
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Marek Vasut Sent: Thursday, August 26, 2010 9:00 PM To: StephenPaulraj Chinnadurai-ERS,HCLTech Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] TFTP timeout issue while downloading the linux kernel in openpxa vpac270 u-boot source code Dne Čt 26. srpna 2010 17:06:08 StephenPaulraj Chinnadurai-ERS,HCLTech napsal(a): -Original Message- From: Marek Vasut [mailto:marek.va...@gmail.com] Sent: Thursday, August 26, 2010 5:56 PM To: StephenPaulraj Chinnadurai-ERS,HCLTech Cc: u-boot@lists.denx.de; Wolfgang Denk Subject: Re: [U-Boot] TFTP timeout issue while downloading the linux kernel in openpxa vpac270 u-boot source code Dne St 25. srpna 2010 11:03:30 StephenPaulraj Chinnadurai-ERS,HCLTech napsal(a): Hello Marek, I increased the memory clock speed from 104 MHz to 208 MHz in the PXA270 controller by including the following lines of in the .macro pxa_clock_setup (macro.h file) ldr r0, =0x8 mcr p14, 0, r0, c6, c0, 0 After increasing the memory clock speed, I can download the zImage (2.8MB) through tftp without any timeout. Your memory seems misconfigured. Can you run mtest on it ? I executed the mtest command and waited for an hour, u-boot doesn't displayed any error. The memory start and end address is defined as follow in the include/configs/myboard.h file. #define CONFIG_SYS_MEMTEST_START0xa040 /* memtest works on */ #define CONFIG_SYS_MEMTEST_END 0xa080 /* 4 ... 8 MB in DRAM */ #define CONFIG_SYS_LOAD_ADDR(0xa100) Pattern 04BF Writing...Reading... Pattern FB40 Writing...Reading... Pattern 04C0 Writing...Reading... Pattern FB3F Writing...Reading... Pattern 04C1 Writing...Reading... Test some bigger area then ... at best the one where you're downloading the image. I changed the board/myboard/config.mk to load the u-boot at the 0xa7F0 location in the SDRAM. The environment variable is placed at the 0xa7e0 loation. Memory test with: 1. start address a000 end address a3ff is successful. 2. start address a400 end address a7df is successful. 3. start address a350 end address a500 is successful. But the memory test with start address a000 and end address a500 misbehaved. Check my observation 4: (mtest a000 a500 a55aa55a 3) The giving pattern (a55aa55a) is written only once into the memory but the u-boot read the pattern from the memory 3 times (iteration count). The write loop is not executed. I don't know the reason. I executed the (mtest a000 a500 a55aa55a 3) command several times and every time the write loop is not executed and the mtest result also not displayed. Kindly find the memory test observation below: Observation 1: MDT-Boot mtest a000 a3ff a5a55a5a 5 Pattern A5A55A5A Writing...Reading... Pattern 5A5AA5A6 Writing...Reading... Pattern A5A55A59 Writing...Reading... Pattern 5A5AA5A7 Writing...Reading... Pattern A5A55A58 Writing...Reading...Tested 5 iteration(s) with 0 errors. Observation 2: MDT-Boot mtest a400 a7df a5a5a5a5 3 Pattern A5A5A5A5 Writing...Reading... Pattern 5A5A5A5B Writing...Reading... Pattern A5A5A5A4 Writing...Reading...Tested 3 iteration(s) with 0 errors. Observation 3: MDT-Boot mtest a350 a500 a5a55a5a 3 Pattern A5A55A5A Writing...Reading... Pattern 5A5AA5A6 Writing...Reading... Pattern A5A55A59 Writing...Reading...Tested 3 iteration(s) with 0 errors. Observation 4: MDT-Boot mtest a000 a500 a55aa55a 3 Pattern A55AA55A Writing... Reading...Reading...Reading...MDT-Boot But I can't download system.img (android system image file of 55MB) into the SDRAM. Our customize board has LAN91C111Ii-NU controller connected to the static memory 4 (nCS4) of PXA270, and uses 32 bit connection. Below are my observations while using tftpboot command: Observation 1: Exactly after downloading 3498200 bytes the first timeout is occurring, sometimes it is recovering and most of the times it is not recovering, and Retry count exceeded message is displayed. MDT-Boot tftp a130 SMC9: MAC 00:00:70:26:1e:01 TFTP blocksize = 1468, timeout = 5 s Using SMC9-0 device TFTP from server 10.100.144.245; our IP address is 10.100.144.90 Filename ''. Load address: 0xa130 Loading: * #
[U-Boot] Standalone application using saveenv
Hi, I will write a standalone application and I want to use saveenv from it. But saveenv is not included in exports.h. Are there any intentions to add saveenv function to exports.h in later U-boot releases? I don't want the standalone application to be a GPL program. What I understand when I have read some mailing list threads it is not allowed by myself to add new functions to be exported through the jump table without the standalone application must be a GPL program. What I mean with new functions are functions which already exists in U-boot but not already included in exports.h file, for example saveenv. Best regards /Hans Törnquist ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] APM82xxx: Add CPU support
Hi Marri,
On Thursday 26 August 2010 23:05:44 tma...@apm.com wrote:
From: Tirumala Marri tma...@apm.com
APM82XXX is a new line of SoCs which are derivatives of
PPC44X family of processors. This patch adds support of CPU, cache,
tlb, 32k ocm, bootstraps, PLB and AHB bus.
Thanks. General comment: Please add me on Cc on these PPC4xx
related patches. More comments below.
Signed-off-by: Tirumala R Marri tma...@apm.com
---
arch/powerpc/cpu/ppc4xx/cpu.c| 35
+++-- arch/powerpc/cpu/ppc4xx/cpu_init.c |
9 ---
arch/powerpc/cpu/ppc4xx/start.S | 10 +++-
arch/powerpc/include/asm/processor.h |1 +
4 files changed, 46 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/cpu/ppc4xx/cpu.c b/arch/powerpc/cpu/ppc4xx/cpu.c
index 851065c..5fe5d8c 100644
--- a/arch/powerpc/cpu/ppc4xx/cpu.c
+++ b/arch/powerpc/cpu/ppc4xx/cpu.c
@@ -80,7 +80,8 @@ static int pci_async_enabled(void)
#endif /* CONFIG_PCI */
#if defined(CONFIG_PCI) !defined(CONFIG_IOP480) \
-!defined(CONFIG_405) !defined(CONFIG_405EX)
+!defined(CONFIG_405) !defined(CONFIG_405EX) \
+!defined(CONFIG_APM82XXX)
int pci_arbiter_enabled(void)
{
#if defined(CONFIG_405GP)
@@ -250,6 +251,21 @@ static char *bootstrap_str[] = {
};
static char bootstrap_char[] = { 'A', 'B', 'C', 'D', 'E', 'G', 'F', 'H' };
#endif
+#if defined(CONFIG_APM82XXX)
+#define SDR0_PINSTP_SHIFT 29
+static char *bootstrap_str[] = {
+ RESERVED,
+ RESERVED,
+ RESERVED,
+ NAND (8 bits),
+ NOR (8 bits),
+ NOR (8 bits) w/PLL Bypassed,
+ I2C (Addr 0x54),
+ I2C (Addr 0x52),
+};
+static char bootstrap_char[] = { 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H' };
+#endif
+
#if defined(SDR0_PINSTP_SHIFT)
static int bootstrap_option(void)
@@ -285,7 +301,7 @@ int checkcpu (void)
uint pvr = get_pvr();
ulong clock = gd-cpu_clk;
char buf[32];
-#if defined(CONFIG_460EX) || defined(CONFIG_460GT)
+#if defined(CONFIG_460EX) || defined(CONFIG_460GT) ||
defined(CONFIG_APM82XXX) u32 reg;
#endif
@@ -304,6 +320,8 @@ int checkcpu (void)
#if defined(CONFIG_XILINX_440)
puts(IBM PowerPC 4);
+#elif defined(CONFIG_APM82XXX)
+ puts(APM PowerPC APM82);
#else
puts(AMCC PowerPC 4);
#endif
@@ -316,7 +334,7 @@ int checkcpu (void)
#if defined(CONFIG_440)
#if defined(CONFIG_460EX) || defined(CONFIG_460GT)
puts(60);
-#else
+#elif !defined(CONFIG_APM82XXX)
puts(40);
#endif
#endif
@@ -598,7 +616,18 @@ int checkcpu (void)
puts(GX Rev. A);
strcpy(addstr, No Security support);
break;
+#if defined(CONFIG_APM82XXX)
+ case PVR_APM82XXX_RA:
+ mfsdr(SDR0_ECID3, reg);
+ if (reg 0x0020)
+ puts(181 Rev. A);
+ if (reg 0x0010)
+ strcpy(addstr, No Security support);
+ else
+ strcpy(addstr, Security support);
+ break;
+#endif
case PVR_VIRTEX5:
puts(x5 VIRTEX5);
break;
diff --git a/arch/powerpc/cpu/ppc4xx/cpu_init.c
b/arch/powerpc/cpu/ppc4xx/cpu_init.c index c04eede..2308051 100644
--- a/arch/powerpc/cpu/ppc4xx/cpu_init.c
+++ b/arch/powerpc/cpu/ppc4xx/cpu_init.c
@@ -35,7 +35,6 @@ DECLARE_GLOBAL_DATA_PTR;
#ifndef CONFIG_SYS_PLL_RECONFIG
#define CONFIG_SYS_PLL_RECONFIG 0
#endif
-
Why did you remove this empty line?
Please fix and resubmit. 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 2/8] APM82xxx: Add Common register definitions
Hi Marri, On Thursday 26 August 2010 23:05:49 tma...@apm.com wrote: From: Tirumala Marri tma...@apm.com This patch adds APM82XXX specific definitions, which include clock and boot strap. Please find some comments below. Signed-off-by: Tirumala R Marri tma...@apm.com --- include/ppc440.h | 57 - include/ppc4xx.h | 7 +++-- 2 files changed, 59 insertions(+), 5 deletions(-) diff --git a/include/ppc440.h b/include/ppc440.h index c807dda..3bd8e98 100644 --- a/include/ppc440.h +++ b/include/ppc440.h @@ -58,6 +58,25 @@ | Clocking Controller +- ---*/ /* values for clkcfga register - indirect addressing of these regs */ +#if defined(CONFIG_APM82XXX) +#define CPR0_CLKUPD 0x0020 +#define CPR0_PLLC0x0040 +#define CPR0_PLLC_SEL(pllc) (((pllc) 0x0100) 24) +#define CPR0_PLLD0x0060 +#define CPR0_PLLD_FDV(plld) (((plld) 0xff00) 24) +#define CPR0_PLLD_FWDVA(plld)(((plld) 0x000f) 16) +#define CPR0_CPUD0x0080 +#define CPR0_CPUD_CPUDV(cpud)(((cpud) 0x0700) 24) +#define CPR0_PLB2D 0x00a0 +#define CPR0_PLB2D_PLB2DV(plb2d) (((plb2d) 0x0600) 25) +#define CPR0_OPBD0x00c0 +#define CPR0_OPBD_OPBDV(opbd)(((opbd) 0x0300) 24) +#define CPR0_PERD 0x00e0 +#define CPR0_PERD_PERDV(perd)(((perd) 0x0300) 24) +#define CPR0_DDR2D 0x0100 +#define CPR0_DDR2D_DDR2DV(ddr2d) (((ddr2d) 0x0600) 25) +#define CLK_ICFG 0x0140 +#else #define CPR0_PLLC0x0040 #define CPR0_PLLD0x0060 #define CPR0_PRIMAD0 0x0080 @@ -67,6 +86,7 @@ #define CPR0_MALD0x0100 #define CPR0_SPCID 0x0120 #define CPR0_ICFG0x0140 +#endif /*if defined(CONFIG_APM82XXX) */ /* 440EPX boot strap options */ #define BOOT_STRAP_OPTION_A 0x @@ -1275,7 +1295,36 @@ #define SDR0_AHB_CFG 0x370 #define SDR0_USB2HOST_CFG0x371 #endif /* CONFIG_460EX || CONFIG_460GT */ +#if defined(CONFIG_APM82XXX) + +#define SDR0_DDR00x00E1 +#define SDR0_DDR0_DDRM_ENCODE(n) unsigned long)(n))0x03)29) +#define SDR0_DDR0_DDRM_DECODE(n) unsigned long)(n))29)0x03) +#define SDR0_DDR0_TUNE_ENCODE(n) unsigned long)(n))0x2FF)0) +#define SDR0_DDR0_TUNE_DECODE(n) unsigned long)(n))0)0x2FF) Add spaces around the operators. I suggest to replace unsigned int with u32 to reduce the line-size resulting in this: #define SDR0_DDR0_DDRM_ENCODE(n)u32)(n)) 0x03) 29) #define SDR0_DDR0_DDRM_DECODE(n)u32)(n)) 29) 0x03) #define SDR0_DDR0_TUNE_ENCODE(n)u32)(n)) 0x2FF) 0) #define SDR0_DDR0_TUNE_DECODE(n)u32)(n)) 0) 0x2FF) BTW: I couldn't find any reference to this SDR0_DDR0 register (0xe1) in the APM8xxx users manual. You might want to add this description there. +#define SDR_SDSTP1_RL_DECODE(x) ((x 0x000C) 18) Missing braces around x. +#define SDR_SDSTP1_RL_EBC 0x0 +#define SDR_SDSTP1_RL_NDFC 0x2 + +/* ECID */ +#define SDR0_ECID0 0x0080 +#define SDR0_ECID1 0x0081 +#define SDR0_ECID2 0x0082 +#define SDR0_ECID3 0x0083 + +/* AHB config. */ +#define AHB_TOP 0xA4 +#define AHB_BOT 0xA5 +#define SDR0_AHB_CFG0x370 + +/* DDR SDRAM Controller clock (CPR register)*/ +#define SDR0_DDRCE 0x00E0 /* SDR register */ +#define CPR0_DDR2D 0x0100 /* CPR register */ +#define CPR0_DDR2D_DDR2DV_ENCODE(n)unsigned long)(n))0x03)25) +#define CPR0_DDR2D_DDR2DV_DECODE(n)unsigned long)(n))25)0x03) Again, please add spaces and change to u32. Please change and resubmit. 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 1/8] APM82xxx: Add CPU support
Hi Marri, On Friday 27 August 2010 11:01:56 Stefan Roese wrote: APM82XXX is a new line of SoCs which are derivatives of PPC44X family of processors. This patch adds support of CPU, cache, tlb, 32k ocm, bootstraps, PLB and AHB bus. Thanks. General comment: Please add me on Cc on these PPC4xx related patches. More comments below. Another general comment: The email address open-source-rev...@apm.com doesn't seem to be public accessible. Please fix or remove from further mails. 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 7/8] APM82xxx: Add bluestone board support
Hi Marri, On Thursday 26 August 2010 23:06:15 tma...@apm.com wrote: From: Tirumala Marri tma...@apm.com Add support code for bluestone board wth APM82XXX processor based. This patch includes early board init, misc init, configure EBC, and initializes UIC. Again, some comments below. Signed-off-by: Tirumala R Marri tma...@apm.com --- arch/powerpc/include/asm/ppc4xx-ebc.h |4 + board/amcc/bluestone/Makefile | 52 board/amcc/bluestone/bluestone.c | 213 board/amcc/bluestone/config.mk| 40 ++ board/amcc/bluestone/init.S | 55 include/configs/bluestone.h | 218 + 6 files changed, 582 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/include/asm/ppc4xx-ebc.h b/arch/powerpc/include/asm/ppc4xx-ebc.h index 9c17e46..245e487 100644 --- a/arch/powerpc/include/asm/ppc4xx-ebc.h +++ b/arch/powerpc/include/asm/ppc4xx-ebc.h @@ -73,6 +73,10 @@ #define EBC_NUM_BANKS3 #endif +#if defined(CONFIG_APM82XXX) +#define EBC_NUM_BANKS 3 +#endif + /* Bank Configuration Register */ #define EBC_BXCR(n) (n) #define EBC_BXCR_BANK_SIZE(n)(0x10 (((n) EBC_BXCR_BS_MASK) 17)) diff --git a/board/amcc/bluestone/Makefile b/board/amcc/bluestone/Makefile new file mode 100644 index 000..637d20d --- /dev/null +++ b/board/amcc/bluestone/Makefile @@ -0,0 +1,52 @@ +# +# Copyright (c) 2010, Applied Micro Circuits Corporation +# All rights reserved. Tirumala R Marri tma...@apm.com IIRC, then this statement All rights reserved interferes with the GPL. Please remove it from all your files. +# +# 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 $(TOPDIR)/config.mk + +LIB = $(obj)lib$(BOARD).a + +COBJS-y := $(BOARD).o +SOBJS:= init.o + +COBJS := $(COBJS-y) +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS:= $(addprefix $(obj),$(SOBJS)) + +$(LIB): $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/amcc/bluestone/bluestone.c b/board/amcc/bluestone/bluestone.c new file mode 100644 index 000..b13e84a --- /dev/null +++ b/board/amcc/bluestone/bluestone.c @@ -0,0 +1,213 @@ +/* + * Bluestone board support + * + * Copyright (c) 2010, Applied Micro Circuits Corporation + * All rights reserved. Tirumala R Marri tma...@apm.com + * + * 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 ppc440.h +#include libfdt.h +#include fdt_support.h +#include i2c.h +#include asm/processor.h +#include asm/io.h +#include asm/mmu.h +#include asm/gpio.h + +DECLARE_GLOBAL_DATA_PTR; + +#define SDR_AHB_CFG 0x370 Starting here... +/* Define Boot devices */ +#define BOOT_FROM_8BIT_SRAM 0x00 +#define BOOT_FROM_8BIT_SRAM_FULL_ADDR 0x01 +#define BOOT_FROM_8BIT_NAND 0x02 +#define BOOT_FROM_8BIT_NOR 0x03 +#define BOOT_FROM_8BIT_NOR_FULL_ADDR 0x04 +#define BOOT_DEVICE_UNKNOWN 0xff + +#define APM82161_MASK
Re: [U-Boot] TFTP timeout issue while downloading the linux kernel in openpxa vpac270 u-boot source code
Dne Pá 27. srpna 2010 10:52:45 StephenPaulraj Chinnadurai-ERS,HCLTech napsal(a): -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Marek Vasut Sent: Thursday, August 26, 2010 9:00 PM To: StephenPaulraj Chinnadurai-ERS,HCLTech Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] TFTP timeout issue while downloading the linux kernel in openpxa vpac270 u-boot source code Dne Čt 26. srpna 2010 17:06:08 StephenPaulraj Chinnadurai-ERS,HCLTech napsal(a): -Original Message- From: Marek Vasut [mailto:marek.va...@gmail.com] Sent: Thursday, August 26, 2010 5:56 PM To: StephenPaulraj Chinnadurai-ERS,HCLTech Cc: u-boot@lists.denx.de; Wolfgang Denk Subject: Re: [U-Boot] TFTP timeout issue while downloading the linux kernel in openpxa vpac270 u-boot source code Dne St 25. srpna 2010 11:03:30 StephenPaulraj Chinnadurai-ERS,HCLTech napsal(a): Hello Marek, I increased the memory clock speed from 104 MHz to 208 MHz in the PXA270 controller by including the following lines of in the .macro pxa_clock_setup (macro.h file) ldr r0, =0x8 mcr p14, 0, r0, c6, c0, 0 After increasing the memory clock speed, I can download the zImage (2.8MB) through tftp without any timeout. Your memory seems misconfigured. Can you run mtest on it ? I executed the mtest command and waited for an hour, u-boot doesn't displayed any error. The memory start and end address is defined as follow in the include/configs/myboard.h file. #define CONFIG_SYS_MEMTEST_START0xa040 /* memtest works on */ #define CONFIG_SYS_MEMTEST_END 0xa080 /* 4 ... 8 MB in DRAM */ #define CONFIG_SYS_LOAD_ADDR(0xa100) Pattern 04BF Writing...Reading... Pattern FB40 Writing...Reading... Pattern 04C0 Writing...Reading... Pattern FB3F Writing...Reading... Pattern 04C1 Writing...Reading... Test some bigger area then ... at best the one where you're downloading the image. I changed the board/myboard/config.mk to load the u-boot at the 0xa7F0 location in the SDRAM. The environment variable is placed at the 0xa7e0 loation. Memory test with: 1. start address a000 end address a3ff is successful. 2. start address a400 end address a7df is successful. 3. start address a350 end address a500 is successful. But the memory test with start address a000 and end address a500 misbehaved. Check my observation 4: (mtest a000 a500 a55aa55a 3) The giving pattern (a55aa55a) is written only once into the memory but the u-boot read the pattern from the memory 3 times (iteration count). The write loop is not executed. I don't know the reason. I executed the (mtest a000 a500 a55aa55a 3) command several times and every time the write loop is not executed and the mtest result also not displayed. Kindly find the memory test observation below: Observation 1: MDT-Boot mtest a000 a3ff a5a55a5a 5 Pattern A5A55A5A Writing...Reading... Pattern 5A5AA5A6 Writing...Reading... Pattern A5A55A59 Writing...Reading... Pattern 5A5AA5A7 Writing...Reading... Pattern A5A55A58 Writing...Reading...Tested 5 iteration(s) with 0 errors. Observation 2: MDT-Boot mtest a400 a7df a5a5a5a5 3 Pattern A5A5A5A5 Writing...Reading... Pattern 5A5A5A5B Writing...Reading... Pattern A5A5A5A4 Writing...Reading...Tested 3 iteration(s) with 0 errors. Observation 3: MDT-Boot mtest a350 a500 a5a55a5a 3 Pattern A5A55A5A Writing...Reading... Pattern 5A5AA5A6 Writing...Reading... Pattern A5A55A59 Writing...Reading...Tested 3 iteration(s) with 0 errors. Observation 4: MDT-Boot mtest a000 a500 a55aa55a 3 Pattern A55AA55A Writing... Reading...Reading...Reading...MDT-Boot Just run ... mtest 0xa000 0xa700 and see if it screams. If it does, your memory's misconfigured. (I assume you have at least 0x0800 bytes of RAM and uboot is loaded past 0xa700). But I can't download system.img (android system image file of 55MB) into the SDRAM. Our customize board has LAN91C111Ii-NU controller connected to the static memory 4 (nCS4) of PXA270, and uses 32 bit connection. Below are my observations while using tftpboot command: Observation 1: Exactly after downloading 3498200 bytes the first timeout is occurring, sometimes it is recovering and most of the times it is not recovering, and Retry count exceeded
Re: [U-Boot] [PATCH 8/8] APM82xxx: Add top level common file changes
Hi Marri, On Thursday 26 August 2010 23:06:20 tma...@apm.com wrote: From: Tirumala Marri tma...@apm.com Add bluestone board name to the board.cfg. Change Makefile to include bluestone board support. Not needed with board.cfg now. Please remove your changes to Makefile. Compiling bluestone results in this warning: [ste...@stefan-desktop u-boot (apm82xxx)]$ ./MAKEALL bluestone Configuring for bluestone board... cpu_init.c: In function 'cpu_init_f': cpu_init.c:226: warning: unused variable 'val' Please fix and resubmit. 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] Disaligned buffer in print_buffer
Stefano Babic schrieb:
As linebuf is accessed with 32-bit pointers, its address
must be 32 bit aligned to avoid misaligned access.
Signed-off-by: Stefano Babic sba...@denx.de
---
lib/display_options.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/display_options.c b/lib/display_options.c
index 20319e6..30374f9 100644
--- a/lib/display_options.c
+++ b/lib/display_options.c
@@ -101,7 +101,7 @@ void print_size(unsigned long long size, const char *s)
#define DEFAULT_LINE_LENGTH_BYTES (16)
int print_buffer (ulong addr, void* data, uint width, uint count, uint
linelen)
{
- uint8_t linebuf[MAX_LINE_LENGTH_BYTES + 1];
+ uint8_t linebuf[MAX_LINE_LENGTH_BYTES + 1]
__attribute__((__aligned__(4)));
uint32_t *uip = (void*)linebuf;
uint16_t *usp = (void*)linebuf;
uint8_t *ucp = (void*)linebuf;
Why not just declare it as
uint_32t linebuf[MAX_LINE_LENGTH_BYTES/4+1];
?
Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] MTD/SPI/FLASH: add support for Ramtron FRAMs using SPI
From: Reinhard Meyer i...@emk-elektronik.de
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
drivers/mtd/spi/Makefile |1 +
drivers/mtd/spi/ramtron.c| 312 ++
drivers/mtd/spi/spi_flash.c | 54 ++-
drivers/mtd/spi/spi_flash_internal.h |1 +
4 files changed, 363 insertions(+), 5 deletions(-)
create mode 100644 drivers/mtd/spi/ramtron.c
diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
index 4f11b36..a082ca7 100644
--- a/drivers/mtd/spi/Makefile
+++ b/drivers/mtd/spi/Makefile
@@ -32,6 +32,7 @@ COBJS-$(CONFIG_SPI_FLASH_SPANSION)+= spansion.o
COBJS-$(CONFIG_SPI_FLASH_SST) += sst.o
COBJS-$(CONFIG_SPI_FLASH_STMICRO) += stmicro.o
COBJS-$(CONFIG_SPI_FLASH_WINBOND) += winbond.o
+COBJS-$(CONFIG_SPI_FRAM_RAMTRON) += ramtron.o
COBJS-$(CONFIG_SPI_M95XXX) += eeprom_m95xxx.o
COBJS := $(COBJS-y)
diff --git a/drivers/mtd/spi/ramtron.c b/drivers/mtd/spi/ramtron.c
new file mode 100644
index 000..ecdb5d2
--- /dev/null
+++ b/drivers/mtd/spi/ramtron.c
@@ -0,0 +1,312 @@
+/*
+ * (C) Copyright 2010
+ * Reinhard Meyer, EMK Elektronik, reinhard.me...@emk-elektronik.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
+ */
+
+/*
+ * Note: RAMTRON SPI FRAMs are ferroelectric, nonvolatile RAMs
+ * with an interface identical to SPI flash devices.
+ * However since they behave like RAM there are no delays or
+ * busy polls required. They can sustain read or write at the
+ * allowed SPI bus speed, which can be 40 MHz for some devices.
+ *
+ * Unfortunately, some RAMTRON FRAMs do not have a means of
+ * identifying them. We use an environment variable to select
+ * the device we will handle. The variable fram_device should
+ * be set from VPD data.
+ */
+
+#include common.h
+#include malloc.h
+#include spi_flash.h
+#include spi_flash_internal.h
+
+/* RAMTRON commands common to all devices */
+#define CMD_RAMTRON_WREN 0x06/* Write Enable */
+#define CMD_RAMTRON_WRDI 0x04/* Write Disable */
+#define CMD_RAMTRON_RDSR 0x05/* Read Status Register */
+#define CMD_RAMTRON_WRSR 0x01/* Write Status Register */
+#define CMD_RAMTRON_READ 0x03/* Read Data Bytes */
+#define CMD_RAMTRON_WRITE 0x02/* Write Data Bytes */
+/* not all have those: */
+#define CMD_RAMTRON_FSTRD 0x0b/* Fast Read (for compatibility - not
used here) */
+#define CMD_RAMTRON_SLEEP 0xb9/* Enter Sleep Mode */
+#define CMD_RAMTRON_RDID 0x9f/* Read ID */
+#define CMD_RAMTRON_SNR0xc3/* Read Serial Number */
+
+/*
+ * Properties of supported FRAMs
+ * Note: speed is currently not used because we have no method to deliver that
+ * value to the upper layers
+ */
+struct ramtron_spi_fram_params {
+ u32 size; /* size in bytes */
+ u8 addr_len; /* number of address bytes */
+ u8 merge_cmd; /* some address bits are in the command byte */
+ u8 id1;/* device ID 1 (family, density) */
+ u8 id2;/* device ID 2 (sub, rev, rsvd) */
+ u32 speed; /* max. SPI clock in Hz */
+ const char *name; /* name for display and/or matching */
+};
+
+struct ramtron_spi_fram {
+ struct spi_flash flash;
+ const struct ramtron_spi_fram_params *params;
+};
+
+static inline struct ramtron_spi_fram *to_ramtron_spi_fram(struct spi_flash
+*flash)
+{
+ return container_of(flash, struct ramtron_spi_fram, flash);
+}
+
+/*
+ * table describing supported FRAM chips:
+ * chips without RDID command must have the values 0xff for id1 and id2
+ */
+static const struct ramtron_spi_fram_params ramtron_spi_fram_table[] = {
+ {
+ .size = 32*1024,
+ .addr_len = 2,
+ .merge_cmd = 0,
+ .id1 = 0x22,
+ .id2 = 0x00,
+ .speed = 4000,
+ .name = FM25V02,
+ },
+ {
+ .size = 32*1024,
+ .addr_len = 2,
+ .merge_cmd = 0,
+ .id1 = 0x22,
+ .id2 = 0x01,
+
Re: [U-Boot] u-boot-x86
Hi Graeme, I notice there is a work in progress for coreboot on only one Intel Atom motherboard (the D945GCLF) - Not a lot of support there. I would imagine that it is _very_ difficult to get at the information one needs to write such low-level software. During private talks I got the impression that the manuals/data sheets which actually put you into a position to use a hardware component from software is not what the Intel Atom is known for - if you know what I mean. Cheers Detlev -- .. most of the finest products of an applied mathematician's fancy must be rejected, as soon as they have been created, for the brutal but sufficient reason that they do not fit the facts.-- G. H. Hardy -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NFS 'Loading: *_*** ERROR: Cannot mount'
Hi Stephen, I am getting following error message when tried to download zImage to the SDRAM. MDT-Boot MDT-Boot nfs a130 10.100.144.245:/var/bin/lib/tftpboot/zImage SMC9: MAC 00:00:70:26:1e:01 Using SMC9-0 device File transfer via NFS from server 10.100.144.245; our IP address is 10.100.144.90 Filename '/var/lib/tftpboot/zImage'. Load address: 0xa130 Loading: *_*** ERROR: Cannot mount Abort MDT-Boot What is that I need to do to make nfs work? Install a proper NFS server - test that you can access the NFS area from a regular Linux PC and fix the problems. Then try again with U-Boot. ALso a packet-sniffer like Wireshark can help in diagnosing such problems. Cheers Detlev -- I talk to planets baby -- Dave Wyndorf (Monstermagnet) -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/8] APM82xxx: Add UIC support
Hello. tma...@apm.com wrote: From: Tirumala Marri tma...@apm.com This patch adds Universal Interrupt Controller support for APM82XXX processor. Signed-off-by: Tirumala R Marri tma...@apm.com [...] diff --git a/arch/powerpc/include/asm/ppc4xx-uic.h b/arch/powerpc/include/asm/ppc4xx-uic.h index 782d045..238b70b 100644 --- a/arch/powerpc/include/asm/ppc4xx-uic.h +++ b/arch/powerpc/include/asm/ppc4xx-uic.h [...] @@ -252,7 +252,8 @@ #define VECNUM_ETH0 (32 + 28) #endif /* CONFIG_440SPE */ -#if defined(CONFIG_460EX) || defined(CONFIG_460GT) +#if defined(CONFIG_460EX) || defined(CONFIG_460GT) ||\ Please add space before \ to keep the style consistent. +defined(CONFIG_APM82XXX) WBR, Sergei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] APM82xxx: Add SRAM support
Hello. tma...@apm.com wrote: From: Tirumala Marri tma...@apm.com This patch adds L2Cache/SRAM and OCM register definitions. Signed-off-by: Tirumala R Marri tma...@apm.com [...] diff --git a/arch/powerpc/include/asm/ppc4xx-isram.h b/arch/powerpc/include/asm/ppc4xx-isram.h index d6d17ac..b723401 100644 --- a/arch/powerpc/include/asm/ppc4xx-isram.h +++ b/arch/powerpc/include/asm/ppc4xx-isram.h @@ -25,7 +25,8 @@ /* * Internal SRAM */ -#if defined(CONFIG_440EPX) || defined(CONFIG_440GRX) +#if defined(CONFIG_440EPX) || defined(CONFIG_440GRX) ||\ Please add space before \ to keep the style consistent. +defined(CONFIG_APM82XXX) #define ISRAM0_DCR_BASE 0x380 #else #define ISRAM0_DCR_BASE 0x020 @@ -42,7 +43,8 @@ #define ISRAM0_REVID (ISRAM0_DCR_BASE+0x09) /* SRAM bus revision id reg */ #define ISRAM0_DPC (ISRAM0_DCR_BASE+0x0a) /* SRAM data parity check reg */ -#if defined(CONFIG_460EX) || defined(CONFIG_460GT) +#if defined(CONFIG_460EX) || defined(CONFIG_460GT) ||\ Same here... +defined(CONFIG_APM82XXX) #define ISRAM1_DCR_BASE 0x0B0 #define ISRAM1_SB0CR (ISRAM1_DCR_BASE+0x00) /* SRAM1 bank config 0*/ #define ISRAM1_BEAR (ISRAM1_DCR_BASE+0x04) /* SRAM1 bus error addr reg */ WBR, Sergei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] cmp_bmp: allow negative X, Y values for display command
Hi Timur, The 'bmp display' command accepts optional X and Y values for the position of the image to be displayed. Change the code which parses the command line to accept negative values. This feature is useful if you want to use a frame buffer for the console, and you want a banner displayed on the top of the screen that never scrolls off. This can be accomplished by declaring that the width and height of the video screen is smaller than it really is, and then drawing an image in the undeclared area. For example, if you have 1280x1024 monitor, and you want to display a banner on the top of the screen that's 100 pixels tall, then video_hw_init() should say that display is really 1280x924, and then the banner should be drawn at position (0, -100). Ugh. I have to admit that I really dislike this patch. What you effectively do is to erase the aboluteness of coordinates. Instead of the current 1:1 correspondence between a pixel coordinate and its location on the physical display, you introduce virtual coordinates without any possibility to inquire about the virtual coordinate system in use. Currently if we display an image at (0, 0) we can be sure that it appears at the edge of the display. With your system one cannot tell without knowing the complete context. Can't you come up with a scheme which does not destroy this valuable property of our coordinates? Cheers Detlev -- When you loosen yourself from all the obvious delusions - religion, ideology, Communism - you're still left with the myth of your own goodness. Which is the final delusion. -- Philip Roth -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ELDK] Not able to Uncompress Multi Image
Hi Zoolu, I am trying to boot my mutli image ( Kernel + Ramdisk) on my target and i am not able to boot beyond below given log. I can not see (Uncompressing Multi-File Image ... OK) .. OK does not come up. I guess the image is hung while uncompressing the image ??? But to my surprise the same image boots on a different board with all same hardware. So the problem is only with this board i guess any pointer on this would be of great help. Do you use the same U-Boot versions on both the good and the bad board? It's because in the last time we reworked the boot process thoroughly and the multi-image file is deprecated in favour of the FIT images (cf. doc/uImage.FIT). So maybe the non-working board has a U-Boot with a problem in the multi-image file handling... --- Load address: 0x400 Loading: # # # # # # # ## done Bytes transferred = 2583735 (276cb7 hex) ## Booting image at 0400 ... Image Name: Boot Image Image Type: PowerPC Linux Multi-File Image (gzip compressed) Data Size:2583671 Bytes = 2.5 MB Load Address: Entry Point: Contents: Image 0: 1268075 Bytes = 1.2 MB Image 1: 1315583 Bytes = 1.3 MB Verifying Checksum ... OK Uncompressing Multi-File Image ... Thanks Regards, Zoolu Apart from that, you should use the U-Boot mailing list more appropriate for such topics (I added a CC and set f'up). Thanks Detlev -- A GNU manual should give a good introduction to a beginner reading through from the start, and should also provide all the details that hackers want. --- GNU Coding Standards -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] orion5x: fix comment-in-comment typo in cpu.h
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud
Sent: Friday, August 27, 2010 6:37 AM
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] orion5x: fix comment-in-comment
typo in cpu.h
Signed-off-by: Albert Aribaud albert.arib...@free.fr
---
arch/arm/include/asm/arch-orion5x/cpu.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/arch-orion5x/cpu.h
b/arch/arm/include/asm/arch-orion5x/cpu.h
index 80717f8..6ce02a9 100644
--- a/arch/arm/include/asm/arch-orion5x/cpu.h
+++ b/arch/arm/include/asm/arch-orion5x/cpu.h
@@ -76,7 +76,7 @@ enum orion5x_cpu_attrib {
/*
* Device Address MAP BAR values
-/*
+ *
* All addresses and sizes not defined by board code
* will be given default values here.
*/
Applied to u-boot-marvell.git master branch
Regards..
Prafulla . .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] cmp_bmp: allow negative X, Y values for display command
Detlev Zundel wrote: Can't you come up with a scheme which does not destroy this valuable property of our coordinates? I'm only doing two things: 1) Exposing a feature of the existing code. Notice that I only had to change two lines in the cmd_bmp code, not any of the core bitmap code, which already takes signed integers. 2) Trying to use the existing bitmap code to do the same thing that we do with the Freescale-specific bitmap code. If you can tell me how I can display a logo on top of the screen, and have all of the boot text appear below the logo, I'll be happy to do that instead. The logo will then scroll off the top of the screen, but that's okay. -- Timur Tabi Linux kernel developer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/4] i2c: rename kirkwood_i2c to mvtwsi
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud
Sent: Friday, August 27, 2010 11:42 AM
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V3 2/4] i2c: rename kirkwood_i2c to mvtwsi
This driver is not kirkwood-specific and can also be used
e.g. by orion5x. Rename to a SoC-neutral name.
Signed-off-by: Albert Aribaud albert.arib...@free.fr
---
drivers/i2c/Makefile |2 +-
drivers/i2c/{kirkwood_i2c.c = mvtwsi.c} |0
2 files changed, 1 insertions(+), 1 deletions(-)
rename drivers/i2c/{kirkwood_i2c.c = mvtwsi.c} (100%)
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index d2c2515..ae04d53 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -28,7 +28,7 @@ LIB := $(obj)libi2c.a
COBJS-$(CONFIG_BFIN_TWI_I2C) += bfin-twi_i2c.o
COBJS-$(CONFIG_DRIVER_DAVINCI_I2C) += davinci_i2c.o
COBJS-$(CONFIG_FSL_I2C) += fsl_i2c.o
-COBJS-$(CONFIG_I2C_KIRKWOOD) += kirkwood_i2c.o
+COBJS-$(CONFIG_I2C_DRIVER_MVTWSI) += mvtwsi.o
This makefile needs separate spin for cleanup
But I think _DRIVER_ can be removed here to make it short at this moment
Regards..
Prafulla ..
COBJS-$(CONFIG_I2C_MXC) += mxc_i2c.o
COBJS-$(CONFIG_DRIVER_OMAP1510_I2C) += omap1510_i2c.o
COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o
diff --git a/drivers/i2c/kirkwood_i2c.c b/drivers/i2c/mvtwsi.c
similarity index 100%
rename from drivers/i2c/kirkwood_i2c.c
rename to drivers/i2c/mvtwsi.c
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 4/4] edminiv2: add I2C support using mvtwsi driver
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud Sent: Friday, August 27, 2010 11:42 AM To: u-boot@lists.denx.de Subject: [U-Boot] [PATCH V3 4/4] edminiv2: add I2C support using mvtwsi driver Signed-off-by: Albert Aribaud albert.arib...@free.fr --- include/configs/edminiv2.h |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/include/configs/edminiv2.h b/include/configs/edminiv2.h index 57dd165..36ed392 100644 --- a/include/configs/edminiv2.h +++ b/include/configs/edminiv2.h @@ -182,6 +182,15 @@ #endif /* CMD_IDE */ /* + * I2C related stuff + */ +#define CONFIG_I2C_DRIVER_MVTWSI +#define CONFIG_I2C_MVTWSI_BASE ORION5X_TWSI_BASE +#define CONFIG_SYS_I2C_SLAVE 0x0 +#define CONFIG_SYS_I2C_SPEED 10 +#define CONFIG_CMD_I2C Can you pls encapsulate this in #ifdef CONFIG_CMD_I2C ? Regards.. Prafulla . . + +/* * Environment variables configurations */ #define CONFIG_ENV_IS_IN_FLASH 1 -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 3/4] i2c: rewrite mvtwsi, support orion5x and kirkwood
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud
Sent: Friday, August 27, 2010 11:42 AM
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V3 3/4] i2c: rewrite mvtwsi, support
orion5x and kirkwood
This rewrite of the mvtwsi driver is 25% smaller and much
faster and simpler than the previous code.
Signed-off-by: Albert Aribaud albert.arib...@free.fr
---
drivers/i2c/mvtwsi.c | 742
+++---
1 files changed, 334 insertions(+), 408 deletions(-)
diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c
index a4409be..e7f08ac 100644
--- a/drivers/i2c/mvtwsi.c
+++ b/drivers/i2c/mvtwsi.c
@@ -1,10 +1,7 @@
/*
- * Driver for the i2c controller on the Marvell line of host bridges
- * (e.g, gt642[46]0, mv643[46]0, mv644[46]0, Orion SoC family),
- * and Kirkwood family.
+ * Driver for the TWSI (i2c) controller on the Marvell orion5x
Don't you think Kirkwood is missing here ?
*
- * Based on:
- * Author: Mark A. Greer mgr...@mvista.com
+ * Author: Albert Aribaud albert.arib...@free.fr
* 2005 (c) MontaVista, Software, Inc.
I hope this line is not there in earlier version, pls confirm..
*
* See file CREDITS for list of people who contributed to this
@@ -24,473 +21,402 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
* MA 02110-1301 USA
- *
- * ported from Linux to u-boot
- * (C) Copyright 2009
- * Heiko Schocher, DENX Software Engineering, h...@denx.de.
*/
+
#include common.h
#include i2c.h
-#include asm/arch/kirkwood.h
#include asm/errno.h
#include asm/io.h
-DECLARE_GLOBAL_DATA_PTR;
+/*
+ * include a file that will provide CONFIG_I2C_MVTWSI_BASE
+ * and possibly other settings
+ */
-static unsigned int i2c_bus_num __attribute__ ((section
(.data))) = 0;
-#if defined(CONFIG_I2C_MUX)
-static unsigned int i2c_bus_num_mux __attribute__ ((section
(data))) = 0;
+#if defined(CONFIG_ORION5X)
+#include asm/arch/orion5x.h
+#else
+#error Driver mvtwsi not supported by SoC or board
#endif
-/* Register defines */
-#define KW_I2C_REG_SLAVE_ADDR 0x00
-#define KW_I2C_REG_DATA 0x04
-#define KW_I2C_REG_CONTROL 0x08
-#define KW_I2C_REG_STATUS 0x0c
-#define KW_I2C_REG_BAUD 0x0c
-#define KW_I2C_REG_EXT_SLAVE_ADDR 0x10
-#define KW_I2C_REG_SOFT_RESET 0x1c
-
-#define KW_I2C_REG_CONTROL_ACK 0x0004
-#define KW_I2C_REG_CONTROL_IFLG 0x0008
-#define KW_I2C_REG_CONTROL_STOP 0x0010
-#define KW_I2C_REG_CONTROL_START0x0020
-#define KW_I2C_REG_CONTROL_TWSIEN 0x0040
-#define KW_I2C_REG_CONTROL_INTEN0x0080
-
-/* Ctlr status values */
-#define KW_I2C_STATUS_BUS_ERR 0x00
-#define KW_I2C_STATUS_MAST_START0x08
-#define KW_I2C_STATUS_MAST_REPEAT_START 0x10
-#define KW_I2C_STATUS_MAST_WR_ADDR_ACK 0x18
-#define KW_I2C_STATUS_MAST_WR_ADDR_NO_ACK 0x20
-#define KW_I2C_STATUS_MAST_WR_ACK 0x28
-#define KW_I2C_STATUS_MAST_WR_NO_ACK0x30
-#define KW_I2C_STATUS_MAST_LOST_ARB 0x38
-#define KW_I2C_STATUS_MAST_RD_ADDR_ACK 0x40
-#define KW_I2C_STATUS_MAST_RD_ADDR_NO_ACK 0x48
-#define KW_I2C_STATUS_MAST_RD_DATA_ACK 0x50
-#define KW_I2C_STATUS_MAST_RD_DATA_NO_ACK 0x58
-#define KW_I2C_STATUS_MAST_WR_ADDR_2_ACK0xd0
-#define KW_I2C_STATUS_MAST_WR_ADDR_2_NO_ACK 0xd8
-#define KW_I2C_STATUS_MAST_RD_ADDR_2_ACK0xe0
-#define KW_I2C_STATUS_MAST_RD_ADDR_2_NO_ACK 0xe8
-#define KW_I2C_STATUS_NO_STATUS 0xf8
-
-/* Driver states */
-enum {
- KW_I2C_STATE_INVALID,
- KW_I2C_STATE_IDLE,
- KW_I2C_STATE_WAITING_FOR_START_COND,
- KW_I2C_STATE_WAITING_FOR_ADDR_1_ACK,
- KW_I2C_STATE_WAITING_FOR_ADDR_2_ACK,
- KW_I2C_STATE_WAITING_FOR_SLAVE_ACK,
- KW_I2C_STATE_WAITING_FOR_SLAVE_DATA,
-};
+/*
+ * TWSI register structure
+ */
-/* Driver actions */
-enum {
- KW_I2C_ACTION_INVALID,
- KW_I2C_ACTION_CONTINUE,
- KW_I2C_ACTION_SEND_START,
- KW_I2C_ACTION_SEND_ADDR_1,
- KW_I2C_ACTION_SEND_ADDR_2,
- KW_I2C_ACTION_SEND_DATA,
- KW_I2C_ACTION_RCV_DATA,
- KW_I2C_ACTION_RCV_DATA_STOP,
- KW_I2C_ACTION_SEND_STOP,
+struct mvtwsi_registers {
+ u32 slave_address;
+ u32 data;
+ u32 control;
+ union {
+ u32 status; /* when reading */
+ u32 baudrate; /* when writing */
+ };
+ u32
Re: [U-Boot] [PATCH V3 3/4] i2c: rewrite mvtwsi, support orion5x and kirkwood
Le 27/08/2010 14:34, Prafulla Wadaskar a écrit : -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud Sent: Friday, August 27, 2010 11:42 AM To: u-boot@lists.denx.de Subject: [U-Boot] [PATCH V3 3/4] i2c: rewrite mvtwsi, support orion5x and kirkwood This rewrite of the mvtwsi driver is 25% smaller and much faster and simpler than the previous code. Signed-off-by: Albert Aribaudalbert.arib...@free.fr --- drivers/i2c/mvtwsi.c | 742 +++--- 1 files changed, 334 insertions(+), 408 deletions(-) diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c index a4409be..e7f08ac 100644 --- a/drivers/i2c/mvtwsi.c +++ b/drivers/i2c/mvtwsi.c @@ -1,10 +1,7 @@ /* - * Driver for the i2c controller on the Marvell line of host bridges - * (e.g, gt642[46]0, mv643[46]0, mv644[46]0, Orion SoC family), - * and Kirkwood family. + * Driver for the TWSI (i2c) controller on the Marvell orion5x Don't you think Kirkwood is missing here ? * - * Based on: - * Author: Mark A. Greermgr...@mvista.com + * Author: Albert Aribaudalbert.arib...@free.fr * 2005 (c) MontaVista, Software, Inc. I hope this line is not there in earlier version, pls confirm.. The Montavista (c) line is in the kirkwood_i2c file from which I copy-pasted the GPL notice. I'd even posted a remark myself on V1 of the patch, stating that this copyright line was a leftover of the old driver, and that I would fix it on V2. Somehow I missed it. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] cmp_bmp: allow negative X, Y values for display command
Hi Timur, Detlev Zundel wrote: Can't you come up with a scheme which does not destroy this valuable property of our coordinates? I'm only doing two things: 1) Exposing a feature of the existing code. Notice that I only had to change two lines in the cmd_bmp code, not any of the core bitmap code, which already takes signed integers. Yes, I fully expected such an answer. Please show me the existing feature which started to leak in such virtual coordinates into the code. We should take a look at this and re-evaluate it. 2) Trying to use the existing bitmap code to do the same thing that we do with the Freescale-specific bitmap code. If you can tell me how I can display a logo on top of the screen, and have all of the boot text appear below the logo, I'll be happy to do that instead. The logo will then scroll off the top of the screen, but that's okay. We can discuss this once I see the code that makes virtual coordinates neccessary. Cheers Detlev -- Quality isn't something you lay on top of subjects and objects like tinsel on a christmas tree. Real Quality must be the source of the subjects and objects, the cone from which the tree must start. -- Robert M. Pirsig -- 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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 4/4] edminiv2: add I2C support using mvtwsi driver
Le 27/08/2010 14:20, Prafulla Wadaskar a écrit : Can you pls encapsulate this in #ifdef CONFIG_CMD_I2C ? Done, and moved #define CONFIG_CMD_I2C up right after #define CONFIG_CMD_IDE. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/4] mtdparts: show net size in mtdparts list
Hi Scott,
Thank you for reviewing patches 2-4.
On Thu, Aug 26, 2010 at 2:57 PM, Scott Wood scottw...@freescale.com wrote:
On Mon, Aug 09, 2010 at 04:43:58PM -0400, Ben Gardiner wrote:
diff --git a/common/cmd_mtdparts.c b/common/cmd_mtdparts.c
index 772ad54..500a38e 100644
--- a/common/cmd_mtdparts.c
+++ b/common/cmd_mtdparts.c
@@ -1215,18 +1215,65 @@ static int generate_mtdparts_save(char *buf, u32
buflen)
return ret;
}
+#if defined(CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES)
/**
- * Format and print out a partition list for each device from global device
- * list.
+ * Get the net size (w/o bad blocks) of the given partition.
+ *
+ * @param mtd the mtd info
+ * @param part the partition
+ * @return the calculated net size of this partition
*/
-static void list_partitions(void)
+static u32 net_part_size(struct mtd_info *mtd, struct part_info *part)
Don't assume partition size fits in 32 bits. part-size is uint64_t.
My mistake.
+{
+ if (mtd-block_isbad) {
+ u32 i, bb_delta = 0;
+
+ for (i = 0; i part-size; i += mtd-erasesize) {
+ if (mtd-block_isbad(mtd, part-offset + i))
+ bb_delta += mtd-erasesize;
+ }
+
+ return part-size - bb_delta;
Seems like it'd be slightly simpler to just count up the good blocks,
rather than count the bad blocks and subtract.
Will do.
+ } else {
+ return part-size;
+ }
It's usually more readable to do this:
if (can't do this)
return;
do this;
than this
if (can do this)
do this;
else
don't;
When do this is more than a line or two, and there's nothing else to be
done in the function afterward.
Right. I think you told me this in the env.oob review also. I'll keep
this in mind for future submissions.
+}
+#endif
+
+static void print_partition_table(void)
{
struct list_head *dentry, *pentry;
struct part_info *part;
struct mtd_device *dev;
int part_num;
- debug(\n---list_partitions---\n);
+#if defined(CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES)
+ list_for_each(dentry, devices) {
+ struct mtd_info *mtd;
+
+ dev = list_entry(dentry, struct mtd_device, link);
+ printf(\ndevice %s%d %s, # parts = %d\n,
+ MTD_DEV_TYPE(dev-id-type), dev-id-num,
+ dev-id-mtd_id, dev-num_parts);
+ printf( #: name\t\tsize\t\tnet size\toffset\t\tmask_flags\n);
+
+ if (get_mtd_info(dev-id-type, dev-id-num, mtd))
+ return;
+
+ /* list partitions for given device */
+ part_num = 0;
+ list_for_each(pentry, dev-parts) {
+ u32 net_size;
+ char *size_note;
+
+ part = list_entry(pentry, struct part_info, link);
+ net_size = net_part_size(mtd, part);
+ size_note = part-size == net_size ? : (!);
+ printf(%2d: %-20s0x%08x\t0x%08x%s\t0x%08x\t%d\n,
+ part_num, part-name, part-size,
+ net_size, size_note, part-offset,
+ part-mask_flags);
+#else /* !defined(CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES) */
list_for_each(dentry, devices) {
dev = list_entry(dentry, struct mtd_device, link);
printf(\ndevice %s%d %s, # parts = %d\n,
@@ -1241,12 +1288,25 @@ static void list_partitions(void)
printf(%2d: %-20s0x%08x\t0x%08x\t%d\n,
part_num, part-name, part-size,
part-offset, part-mask_flags);
-
+#endif /* defined(CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES) */
Is there any way you could share more of this between the two branches?
I definitely could. :)
I had everything-possible shared between the branches in v3 but I
think I took it too far since:
On Sat, Aug 7, 2010 at 4:08 PM, Wolfgang Denk w...@denx.de wrote:
This is way too much #ifdef's here. Please separate the code and use a
single #ifdef only.
I'll try my best to strike a balance here in v5.
Best Regards,
Ben Gardiner
---
Nanometrics Inc.
http://www.nanometrics.ca
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/4] mtdparts: add new sub-command spread
On Thu, Aug 26, 2010 at 5:12 PM, Scott Wood scottw...@freescale.com wrote:
On Mon, Aug 09, 2010 at 04:43:59PM -0400, Ben Gardiner wrote:
+static void spread_partition(struct mtd_info *mtd, struct part_info *part,
+ u32 *next_offset)
As in patch 2, change u32 to uint64_t.
Ok.
+{
+ if (!mtd-block_isbad)
+ goto out;
+
+ u32 i, bb_delta = 0;
+
+ for (i = part-offset; i - bb_delta part-offset + part-size;
+ i += mtd-erasesize) {
+ if (mtd-block_isbad(mtd, i))
+ bb_delta += mtd-erasesize;
+ }
+
+ /*
+ * Absorb bad blocks immeadiately following this
+ * partition also into the partition, such that
+ * the next partition starts with a good block.
+ */
+ while (i mtd-size mtd-block_isbad(mtd, i)) {
+ bb_delta += mtd-erasesize;
+ i += mtd-erasesize;
+ }
Could this be refactored with get_len_incl_bad()? It should return both the
updated length and a flag indicating whether it was truncated.
Yes, I think so. Good point.
+ debug(spread_partitions: device = %s%d, partition %d
=
+ (%s) 0x%...@0x%08x\n,
+ MTD_DEV_TYPE(dev-id-type), dev-id-num,
+ part_num, part-name, part-size,
+ part-offset);
Why the extra indent on that last line?
IMHO, it's also nicer to line up continuation lines like this:
debug(spread_partitions...
(%s) ...
MTD_DEV...
part_num...
part-offset);
Right. I think I forgot also about this formatting requirement which
you pointed out in the env.oob review. I'll get it right soon enough.
Best Regards,
Ben Gardiner
---
Nanometrics Inc.
http://www.nanometrics.ca
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/4] mtdparts: new add.spread: add part skipping bad blocks
On Thu, Aug 26, 2010 at 6:26 PM, Scott Wood scottw...@freescale.com wrote:
On Mon, Aug 09, 2010 at 04:44:00PM -0400, Ben Gardiner wrote:
+#if defined(CONFIG_CMD_MTDPARTS_SPREAD)
+ s = strchr(argv[1], '.');
+
+ if (get_mtd_info(dev-id-type, dev-id-num, mtd))
+ return 1;
+#endif
+
if ((dev_tmp = device_find(dev-id-type, dev-id-num)) ==
NULL) {
+#if defined(CONFIG_CMD_MTDPARTS_SPREAD)
+ if (s !strcmp(s, .spread)) {
No need for the strchr, just do if (!strcmp(argv[1][3], .spread)).
Thanks for pointing that out -- I see it now.
+ p = list_entry(dev-parts.next,
+ struct part_info, link);
+ spread_partition(mtd, p, next_offset);
+
+ debug(increased %s to %d bytes\n, p-name,
+ p-size);
+ }
+#endif
device_add(dev);
} else {
/* merge new partition with existing ones*/
p = list_entry(dev-parts.next, struct part_info,
link);
+#if defined(CONFIG_CMD_MTDPARTS_SPREAD)
+ if (s !strcmp(s, .spread)) {
+ spread_partition(mtd, p, next_offset);
+
+ debug(increased %s to %d bytes\n, p-name,
+ p-size);
+ }
+#endif
Don't duplicate this on both sides of the if; instead do something like:
p = list_entry(dev-parts.next...);
if (!strcmp(argv[1][3], .spread))
spread_partition(mtd, p, next_offset);
if ((dev_tmp = ...) {
device_add(dev);
} else if (part_add(dev_tmp, p)) {
device_del(dev);
return 1;
}
Ok, I'll give it a shot.
Thank you again for your review and detailed comments. I appreciate
you taking the time to help me get these patches prepared. I will
integrate your comments on patches 2-4 shortly.
Best Regards,
Ben Gardiner
---
Nanometrics Inc.
http://www.nanometrics.ca
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] cmp_bmp: allow negative X, Y values for display command
On Aug 27, 2010, at 8:14 AM, Detlev Zundel d...@denx.de wrote: We can discuss this once I see the code that makes virtual coordinates If you can help me figure out how to get the boot text to appear below the logo, I won't need to use virtual coordinates. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] cmp_bmp: allow negative X, Y values for display command
Dear Timur, On Aug 27, 2010, at 8:14 AM, Detlev Zundeld...@denx.de wrote: We can discuss this once I see the code that makes virtual coordinates If you can help me figure out how to get the boot text to appear below the logo, I won't need to use virtual coordinates. 1. would it be possible to output several line-feeds before u-boot starts its output? 2. would it be possible to just manipulate the initial Y for text output? 3. most elegant, however, would be to add a scroll area feature... just my 0.001 € ;) Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] cmp_bmp: allow negative X, Y values for display command
On Aug 27, 2010, at 9:10 AM, Reinhard Meyer u-b...@emk-elektronik.de wrote: 2. would it be possible to just manipulate the initial Y for text output? I'll try this approach. It should be simple enough. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 3/4] i2c: rewrite mvtwsi, support orion5x and kirkwood
-Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Friday, August 27, 2010 6:33 PM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik Subject: Re: [U-Boot] [PATCH V3 3/4] i2c: rewrite mvtwsi, support orion5x and kirkwood Le 27/08/2010 14:34, Prafulla Wadaskar a écrit : -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud Sent: Friday, August 27, 2010 11:42 AM To: u-boot@lists.denx.de Subject: [U-Boot] [PATCH V3 3/4] i2c: rewrite mvtwsi, support orion5x and kirkwood This rewrite of the mvtwsi driver is 25% smaller and much faster and simpler than the previous code. Signed-off-by: Albert Aribaudalbert.arib...@free.fr --- drivers/i2c/mvtwsi.c | 742 +++--- 1 files changed, 334 insertions(+), 408 deletions(-) diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c index a4409be..e7f08ac 100644 --- a/drivers/i2c/mvtwsi.c +++ b/drivers/i2c/mvtwsi.c @@ -1,10 +1,7 @@ /* - * Driver for the i2c controller on the Marvell line of host bridges - * (e.g, gt642[46]0, mv643[46]0, mv644[46]0, Orion SoC family), - * and Kirkwood family. + * Driver for the TWSI (i2c) controller on the Marvell orion5x Don't you think Kirkwood is missing here ? Hi Albert Any commetns for this? Regards.. Prafulla . . * - * Based on: - * Author: Mark A. Greermgr...@mvista.com + * Author: Albert Aribaudalbert.arib...@free.fr * 2005 (c) MontaVista, Software, Inc. I hope this line is not there in earlier version, pls confirm.. The Montavista (c) line is in the kirkwood_i2c file from which I copy-pasted the GPL notice. I'd even posted a remark myself on V1 of the patch, stating that this copyright line was a leftover of the old driver, and that I would fix it on V2. Somehow I missed it. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 3/4] i2c: rewrite mvtwsi, support orion5x and kirkwood
Le 27/08/2010 16:30, Prafulla Wadaskar a écrit : - * Driver for the i2c controller on the Marvell line of host bridges - * (e.g, gt642[46]0, mv643[46]0, mv644[46]0, Orion SoC family), - * and Kirkwood family. + * Driver for the TWSI (i2c) controller on the Marvell orion5x Don't you think Kirkwood is missing here ? Hi Albert Any commetns for this? No worries: all your remarks are being applied in V4, especially those to which I did not reply; I've added kirkwood to the supported SoC list. :) Speaking of which, I thought I might as well directly add orion5x *and* kirkwood includes, i.e patch V4 will have: #if defined(CONFIG_ORION5X) #include asm/arch/orion5x.h #elif defined(CONFIG_KIRKWOOD) #include asm/arch/kirkwood.h #else #error Driver mvtwsi not supported by SoC or board #endif ... even though I won't be adding I2C support on any kirkwood board in this patchset. Regards.. Prafulla . . Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/4] mtdparts: show net size in mtdparts list
On Thu, Aug 26, 2010 at 2:57 PM, Scott Wood scottw...@freescale.com wrote: On Mon, Aug 09, 2010 at 04:43:58PM -0400, Ben Gardiner wrote: diff --git a/common/cmd_mtdparts.c b/common/cmd_mtdparts.c index 772ad54..500a38e 100644 --- a/common/cmd_mtdparts.c +++ b/common/cmd_mtdparts.c @@ -1215,18 +1215,65 @@ static int generate_mtdparts_save(char *buf, u32 buflen) return ret; } +#if defined(CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES) /** - * Format and print out a partition list for each device from global device - * list. + * Get the net size (w/o bad blocks) of the given partition. + * + * @param mtd the mtd info + * @param part the partition + * @return the calculated net size of this partition */ -static void list_partitions(void) +static u32 net_part_size(struct mtd_info *mtd, struct part_info *part) Don't assume partition size fits in 32 bits. part-size is uint64_t. I understand that (at some point) we need to support part-size uint64_t but the HEAD of u-boot [1], u-boot-nand-flash/master [2] and u-boot-nand-flash/next [3] have u32 for part-size. Changing this to uint64_t would require reformatting the list_partitions size column as a 64bit hex number -- as would treating the net_size there as a uint64_t. This would be a change with impact of greater scope than intended with this patchset. I hope it will be acceptable to do the net_part_size return as uin64_t and continue treating both the part-size and net_size as u32? Best Regards, Ben Gardiner [1] http://git.denx.de/?p=u-boot.git;a=blob;f=include/jffs2/load_kernel.h;h=906eb3d3cdbe9f5b539c6341c873ed87de876be5;hb=HEAD#l49 [2] http://git.denx.de/?p=u-boot/u-boot-nand-flash.git;a=blob;f=include/jffs2/load_kernel.h;h=906eb3d3cdbe9f5b539c6341c873ed87de876be5;hb=refs/heads/master#l49 [3] http://git.denx.de/?p=u-boot/u-boot-nand-flash.git;a=blob;f=include/jffs2/load_kernel.h;h=906eb3d3cdbe9f5b539c6341c873ed87de876be5;hb=refs/heads/next#l49 --- Nanometrics Inc. http://www.nanometrics.ca ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 2/4] i2c: rename kirkwood_i2c to mvtwsi
This driver is not kirkwood-specific and can also be used
e.g. by orion5x. Rename to a SoC-neutral name.
Signed-off-by: Albert Aribaud albert.arib...@free.fr
---
drivers/i2c/Makefile |2 +-
drivers/i2c/{kirkwood_i2c.c = mvtwsi.c} |0
2 files changed, 1 insertions(+), 1 deletions(-)
rename drivers/i2c/{kirkwood_i2c.c = mvtwsi.c} (100%)
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index d2c2515..8921ff9 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -28,7 +28,7 @@ LIB := $(obj)libi2c.a
COBJS-$(CONFIG_BFIN_TWI_I2C) += bfin-twi_i2c.o
COBJS-$(CONFIG_DRIVER_DAVINCI_I2C) += davinci_i2c.o
COBJS-$(CONFIG_FSL_I2C) += fsl_i2c.o
-COBJS-$(CONFIG_I2C_KIRKWOOD) += kirkwood_i2c.o
+COBJS-$(CONFIG_I2C_MVTWSI) += mvtwsi.o
COBJS-$(CONFIG_I2C_MXC) += mxc_i2c.o
COBJS-$(CONFIG_DRIVER_OMAP1510_I2C) += omap1510_i2c.o
COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o
diff --git a/drivers/i2c/kirkwood_i2c.c b/drivers/i2c/mvtwsi.c
similarity index 100%
rename from drivers/i2c/kirkwood_i2c.c
rename to drivers/i2c/mvtwsi.c
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 3/4] i2c: rewrite mvtwsi, support orion5x and kirkwood
This rewrite of the mvtwsi driver is 25% smaller and much
faster and simpler than the previous code.
Signed-off-by: Albert Aribaud albert.arib...@free.fr
---
drivers/i2c/mvtwsi.c | 750 +++---
1 files changed, 341 insertions(+), 409 deletions(-)
diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c
index a4409be..16a536f 100644
--- a/drivers/i2c/mvtwsi.c
+++ b/drivers/i2c/mvtwsi.c
@@ -1,11 +1,9 @@
/*
- * Driver for the i2c controller on the Marvell line of host bridges
- * (e.g, gt642[46]0, mv643[46]0, mv644[46]0, Orion SoC family),
- * and Kirkwood family.
+ * Driver for the TWSI (i2c) controller found on the Marvell
+ * orion5x and kirkwood SoC families.
*
- * Based on:
- * Author: Mark A. Greer mgr...@mvista.com
- * 2005 (c) MontaVista, Software, Inc.
+ * Author: Albert Aribaud albert.arib...@free.fr
+ * Copyright (c) 2010 Albert Aribaud.
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -24,473 +22,407 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
* MA 02110-1301 USA
- *
- * ported from Linux to u-boot
- * (C) Copyright 2009
- * Heiko Schocher, DENX Software Engineering, h...@denx.de.
*/
+
#include common.h
#include i2c.h
-#include asm/arch/kirkwood.h
#include asm/errno.h
#include asm/io.h
-DECLARE_GLOBAL_DATA_PTR;
+/*
+ * include a file that will provide CONFIG_I2C_MVTWSI_BASE
+ * and possibly other settings
+ */
-static unsigned int i2c_bus_num __attribute__ ((section (.data))) = 0;
-#if defined(CONFIG_I2C_MUX)
-static unsigned int i2c_bus_num_mux __attribute__ ((section (data))) = 0;
+#if defined(CONFIG_ORION5X)
+#include asm/arch/orion5x.h
+#elif defined(CONFIG_KIRKWOOD)
+#include asm/arch/kirkwood.h
+#else
+#error Driver mvtwsi not supported by SoC or board
#endif
-/* Register defines */
-#defineKW_I2C_REG_SLAVE_ADDR 0x00
-#defineKW_I2C_REG_DATA 0x04
-#defineKW_I2C_REG_CONTROL 0x08
-#defineKW_I2C_REG_STATUS 0x0c
-#defineKW_I2C_REG_BAUD 0x0c
-#defineKW_I2C_REG_EXT_SLAVE_ADDR 0x10
-#defineKW_I2C_REG_SOFT_RESET 0x1c
-
-#defineKW_I2C_REG_CONTROL_ACK 0x0004
-#defineKW_I2C_REG_CONTROL_IFLG 0x0008
-#defineKW_I2C_REG_CONTROL_STOP 0x0010
-#defineKW_I2C_REG_CONTROL_START0x0020
-#defineKW_I2C_REG_CONTROL_TWSIEN 0x0040
-#defineKW_I2C_REG_CONTROL_INTEN0x0080
-
-/* Ctlr status values */
-#defineKW_I2C_STATUS_BUS_ERR 0x00
-#defineKW_I2C_STATUS_MAST_START0x08
-#defineKW_I2C_STATUS_MAST_REPEAT_START 0x10
-#defineKW_I2C_STATUS_MAST_WR_ADDR_ACK 0x18
-#defineKW_I2C_STATUS_MAST_WR_ADDR_NO_ACK 0x20
-#defineKW_I2C_STATUS_MAST_WR_ACK 0x28
-#defineKW_I2C_STATUS_MAST_WR_NO_ACK0x30
-#defineKW_I2C_STATUS_MAST_LOST_ARB 0x38
-#defineKW_I2C_STATUS_MAST_RD_ADDR_ACK 0x40
-#defineKW_I2C_STATUS_MAST_RD_ADDR_NO_ACK 0x48
-#defineKW_I2C_STATUS_MAST_RD_DATA_ACK 0x50
-#defineKW_I2C_STATUS_MAST_RD_DATA_NO_ACK 0x58
-#defineKW_I2C_STATUS_MAST_WR_ADDR_2_ACK0xd0
-#defineKW_I2C_STATUS_MAST_WR_ADDR_2_NO_ACK 0xd8
-#defineKW_I2C_STATUS_MAST_RD_ADDR_2_ACK0xe0
-#defineKW_I2C_STATUS_MAST_RD_ADDR_2_NO_ACK 0xe8
-#defineKW_I2C_STATUS_NO_STATUS 0xf8
-
-/* Driver states */
-enum {
- KW_I2C_STATE_INVALID,
- KW_I2C_STATE_IDLE,
- KW_I2C_STATE_WAITING_FOR_START_COND,
- KW_I2C_STATE_WAITING_FOR_ADDR_1_ACK,
- KW_I2C_STATE_WAITING_FOR_ADDR_2_ACK,
- KW_I2C_STATE_WAITING_FOR_SLAVE_ACK,
- KW_I2C_STATE_WAITING_FOR_SLAVE_DATA,
-};
+/*
+ * TWSI register structure
+ */
-/* Driver actions */
-enum {
- KW_I2C_ACTION_INVALID,
- KW_I2C_ACTION_CONTINUE,
- KW_I2C_ACTION_SEND_START,
- KW_I2C_ACTION_SEND_ADDR_1,
- KW_I2C_ACTION_SEND_ADDR_2,
- KW_I2C_ACTION_SEND_DATA,
- KW_I2C_ACTION_RCV_DATA,
- KW_I2C_ACTION_RCV_DATA_STOP,
- KW_I2C_ACTION_SEND_STOP,
+struct mvtwsi_registers {
+ u32 slave_address;
+ u32 data;
+ u32 control;
+ union {
+ u32 status; /* when reading */
+ u32 baudrate; /* when writing */
+ };
+ u32 xtnd_slave_addr;
+ u32 reserved[2];
+ u32 soft_reset;
};
-/* defines to get compatible with Linux driver */
-#define IRQ_NONE 0x0
-#define IRQ_HANDLED0x01
+/*
+ * Control register fields
+ */
-#define I2C_M_TEN 0x01
-#define I2C_M_RD
Re: [U-Boot] [PATCH v4 2/4] mtdparts: show net size in mtdparts list
On 08/27/2010 10:44 AM, Ben Gardiner wrote: On Thu, Aug 26, 2010 at 2:57 PM, Scott Woodscottw...@freescale.com wrote: Don't assume partition size fits in 32 bits. part-size is uint64_t. I understand that (at some point) we need to support part-size uint64_t but the HEAD of u-boot [1], u-boot-nand-flash/master [2] and u-boot-nand-flash/next [3] have u32 for part-size. I see, I was looking at mtd_partition, not part_info. Why are we using jffs2's partition struct for anything other than jffs2? Why does jffs2 have its own partition struct at all? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 1/4] suen3: remove CONFIG_HARD_I2C and related defines
These are not used on this board, which uses soft I2C instead. Signed-off-by: Albert Aribaud albert.arib...@free.fr --- include/configs/km_arm.h |8 1 files changed, 0 insertions(+), 8 deletions(-) diff --git a/include/configs/km_arm.h b/include/configs/km_arm.h index 6519c90..1617e69 100644 --- a/include/configs/km_arm.h +++ b/include/configs/km_arm.h @@ -142,16 +142,8 @@ /* * I2C related stuff */ -#undef CONFIG_HARD_I2C /* I2C with hardware support */ #defineCONFIG_SOFT_I2C /* I2C bit-banged */ -#if defined(CONFIG_HARD_I2C) -#defineCONFIG_I2C_KIRKWOOD -#defineCONFIG_I2C_KW_REG_BASE KW_TWSI_BASE -#defineCONFIG_SYS_I2C_SLAVE0x0 -#defineCONFIG_SYS_I2C_SPEED10 -#endif - #defineCONFIG_KIRKWOOD_GPIO/* Enable GPIO Support */ #if defined(CONFIG_SOFT_I2C) #ifndef __ASSEMBLY__ -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 0/4] Improve I2C for orion5x, kirkwood and ED Mini V2
SUMMARY: This patchset improves the driver for the Marvell TWSI interface found on orion5x and kirkwood SoCs and adds I2C support to the orion5x-based ED Mini V2 board. The mvtwsi driver is a complete rewrite, 50% shorter in source code lines, 25% smaller in object size, much simpler and way faster than the kirkwood_i2c driver it replaces. PATCH SET: Patch 1 removes dependencies on kirwkood_i2c from suen3, the only board that mentioned it. Patch 2 renames the driver from kirkwood_i2c to mvtwsi. Patch 3 replaces the old code with the new one. Patch 4 adds support for I2C in orion5x-based ED Mini V2. TESTS: This driver has been tested on an ED Mini V2 with basic u-boot i2c commands, on an 5C372a RTC and an HT24LC08 1 KB eeprom (read+write). HISTORY: V1: Initial submission as an addition rather than a replacement. V2: Fixed copyright line. Made mvtwsi a replacement for kirkwood_i2c. Made patches checkpatch-clean: 0 errors, 0 warnings. Various cosmetic changes. Removed useless i2c_end() function. V3: Reduced line lengths below 78 characters. Removed blank line after function description block comment. V4: Changed CONFIG_I2C_DRIVER_MVTWSI into CONFIG_I2C_MVTWSI. Really fixed copyright line. Added and documented kirkwood support. Shortened extended_slave_address into xtnd_slave_addr. Added explanation on default/init baudrate value. Moved I2C config settings under #ifdef CONFIG_CMD_I2C. Albert Aribaud (4): suen3: remove CONFIG_HARD_I2C and related defines i2c: rename kirkwood_i2c to mvtwsi i2c: rewrite mvtwsi, support orion5x and kirkwood edminiv2: add I2C support using mvtwsi driver drivers/i2c/Makefile |2 +- drivers/i2c/kirkwood_i2c.c | 496 drivers/i2c/mvtwsi.c | 428 ++ include/configs/edminiv2.h | 11 + include/configs/km_arm.h |8 - 5 files changed, 440 insertions(+), 505 deletions(-) delete mode 100644 drivers/i2c/kirkwood_i2c.c create mode 100644 drivers/i2c/mvtwsi.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 4/4] edminiv2: add I2C support using mvtwsi driver
Signed-off-by: Albert Aribaud albert.arib...@free.fr --- include/configs/edminiv2.h | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/include/configs/edminiv2.h b/include/configs/edminiv2.h index 57dd165..ccfc660 100644 --- a/include/configs/edminiv2.h +++ b/include/configs/edminiv2.h @@ -132,6 +132,7 @@ */ #include config_cmd_default.h #define CONFIG_CMD_IDE +#define CONFIG_CMD_I2C /* * Network @@ -182,6 +183,16 @@ #endif /* CMD_IDE */ /* + * I2C related stuff + */ +#ifdef CONFIG_CMD_I2C +#define CONFIG_I2C_MVTWSI +#define CONFIG_I2C_MVTWSI_BASE ORION5X_TWSI_BASE +#define CONFIG_SYS_I2C_SLAVE 0x0 +#define CONFIG_SYS_I2C_SPEED 10 +#endif + +/* * Environment variables configurations */ #define CONFIG_ENV_IS_IN_FLASH 1 -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/4] mtdparts: show net size in mtdparts list
On Fri, Aug 27, 2010 at 12:02 PM, Scott Wood scottw...@freescale.com wrote: On 08/27/2010 10:44 AM, Ben Gardiner wrote: On Thu, Aug 26, 2010 at 2:57 PM, Scott Woodscottw...@freescale.com wrote: Don't assume partition size fits in 32 bits. part-size is uint64_t. I understand that (at some point) we need to support part-size uint64_t but the HEAD of u-boot [1], u-boot-nand-flash/master [2] and u-boot-nand-flash/next [3] have u32 for part-size. I see, I was looking at mtd_partition, not part_info. Why are we using jffs2's partition struct for anything other than jffs2? Why does jffs2 have its own partition struct at all? I don't know why. I can only offer the following information: Cscope says that include/jffs2/load_kernel.h is the file in which part_info is defined. 'git blame' indicates that part_info has been used in common/cmd_mtdparts.c since 68d7d65100e84df00bca971c114092731b441090 when Stefan Roese s...@denx.de extracted the command from common/cmd_jffs2.c The users of mtd_partition (add_one_partition and add_mtd_partitions) are called from ubi_dev_scan where the mtd_partition structure is intialized from a part_info structure. Best Regards, Ben Gardiner --- Nanometrics Inc. +1 (613) 592-6776 x239 http://www.nanometrics.ca ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Disaligned buffer in print_buffer
On Friday, August 27, 2010 05:41:08 Reinhard Meyer wrote:
Stefano Babic schrieb:
--- a/lib/display_options.c
+++ b/lib/display_options.c
@@ -101,7 +101,7 @@ void print_size(unsigned long long size, const char
*s)
#define DEFAULT_LINE_LENGTH_BYTES (16)
int print_buffer (ulong addr, void* data, uint width, uint count, uint
linelen) {
- uint8_t linebuf[MAX_LINE_LENGTH_BYTES + 1];
+ uint8_t linebuf[MAX_LINE_LENGTH_BYTES + 1]
__attribute__((__aligned__(4)));
uint32_t *uip = (void*)linebuf;
uint16_t *usp = (void*)linebuf;
uint8_t *ucp = (void*)linebuf;
Why not just declare it as
uint_32t linebuf[MAX_LINE_LENGTH_BYTES/4+1];
?
i guess that'd be another way of doing it
-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] Disaligned buffer in print_buffer
Reinhard Meyer wrote: Hi Reinhard, Why not just declare it as uint_32t linebuf[MAX_LINE_LENGTH_BYTES/4+1]; ? Yes, we do not need any special compiler attribute. I forward to Albert, he sent previously an analog patch to solve this issue. 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: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8] APM82xxx: Add bluestone board support
Hi Stefan: Our legal is out at the moment. Why is this an issue, since it is on many of the files in U-Boot. Our legal indicated without the statement the Copyright would not stand. Thanks Feng +# Copyright (c) 2010, Applied Micro Circuits Corporation +# All rights reserved. Tirumala R Marri tma...@apm.com IIRC, then this statement All rights reserved interferes with the GPL. Please remove it from all your files. +# +# 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 $(TOPDIR)/config.mk + +LIB = $(obj)lib$(BOARD).a + +COBJS-y := $(BOARD).o +SOBJS := init.o + +COBJS := $(COBJS-y) +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB): $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/amcc/bluestone/bluestone.c b/board/amcc/bluestone/bluestone.c new file mode 100644 index 000..b13e84a --- /dev/null +++ b/board/amcc/bluestone/bluestone.c @@ -0,0 +1,213 @@ +/* + * Bluestone board support + * + * Copyright (c) 2010, Applied Micro Circuits Corporation + * All rights reserved. Tirumala R Marri tma...@apm.com + * + * 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 ppc440.h +#include libfdt.h +#include fdt_support.h +#include i2c.h +#include asm/processor.h +#include asm/io.h +#include asm/mmu.h +#include asm/gpio.h + +DECLARE_GLOBAL_DATA_PTR; + +#define SDR_AHB_CFG 0x370 Starting here... +/* Define Boot devices */ +#define BOOT_FROM_8BIT_SRAM 0x00 +#define BOOT_FROM_8BIT_SRAM_FULL_ADDR 0x01 +#define BOOT_FROM_8BIT_NAND 0x02 +#define BOOT_FROM_8BIT_NOR 0x03 +#define BOOT_FROM_8BIT_NOR_FULL_ADDR 0x04 +#define BOOT_DEVICE_UNKNOWN 0xff + +#define APM82161_MASK (u32)(0x1 21) + +/* NOR Flash */ +#define EBC_BXAP_NOR (EBC_BXAP_BME_DISABLED | \ + EBC_BXAP_TWT_ENCODE(64) | \ + EBC_BXAP_BCE_DISABLE | \ + EBC_BXAP_BCT_2TRANS | \ + EBC_BXAP_CSN_ENCODE(1) | \ + EBC_BXAP_OEN_ENCODE(2) | \ + EBC_BXAP_WBN_ENCODE(2) | \ + EBC_BXAP_WBF_ENCODE(2) | \ + EBC_BXAP_TH_ENCODE(7) | \ + EBC_BXAP_SOR_DELAYED | \ + EBC_BXAP_BEM_WRITEONLY | \ + EBC_BXAP_PEN_DISABLED) +/* Peripheral Bank Configuration Register - EBC_BxCR */ +#define EBC_BXCR_8BIT_NOR \ + (EBC_BXCR_BAS_ENCODE(CONFIG_SYS_FLASH_BASE) | \ + EBC_BXCR_BS_1MB | \ + EBC_BXCR_BU_RW | \ + EBC_BXCR_BW_8BIT) + +#define EBC_BXCR_8BIT_SRAM \ + (EBC_BXCR_BAS_ENCODE(CONFIG_SYS_EXTSRAM_BASE) | \ + EBC_BXCR_BS_1MB | \ + EBC_BXCR_BU_RW | \ + EBC_BXCR_BW_8BIT) ... till here. Why do you add these defines to this C file? These should be located in the general header files (ppc440.h) and/or the board config
Re: [U-Boot] [PATCH] Disaligned buffer in print_buffer
On 27.08.2010 20:24, Stefano Babic wrote: Reinhard Meyer wrote: Hi Reinhard, Why not just declare it as uint_32t linebuf[MAX_LINE_LENGTH_BYTES/4+1]; ? Yes, we do not need any special compiler attribute. I forward to Albert, he sent previously an analog patch to solve this issue. Stefano If you need a patch for this, I have made the change here this morning. I can format and email one instantly. Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] display_buffer: fix misaligned buffer
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
lib/display_options.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/display_options.c b/lib/display_options.c
index 20319e6..9048a8a 100644
--- a/lib/display_options.c
+++ b/lib/display_options.c
@@ -101,7 +101,7 @@ void print_size(unsigned long long size, const char *s)
#define DEFAULT_LINE_LENGTH_BYTES (16)
int print_buffer (ulong addr, void* data, uint width, uint count, uint linelen)
{
- uint8_t linebuf[MAX_LINE_LENGTH_BYTES + 1];
+ uint32_t linebuf[MAX_LINE_LENGTH_BYTES/4 + 1];
uint32_t *uip = (void*)linebuf;
uint16_t *usp = (void*)linebuf;
uint8_t *ucp = (void*)linebuf;
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] video: cfb_console: fix definition and usage of CURSOR_xxx macros
The CURSOR_ON, CURSOR_OFF, and CURSOR_SET macros are defined incorrectly. If
cursor support is disabled, then these macros are defined to nothing, but
then they are used like this:
if (console_col CONSOLE_COLS)
CURSOR_OFF
console_row++;
which was compiled like this:
if (console_col CONSOLE_COLS)
console_row++;
This is obviously not what was intended.
Signed-off-by: Timur Tabi ti...@freescale.com
---
This patch depends on
video: cfb_console: add support for 4bpp bitmaps with GDF_32BIT_X888RGB
drivers/video/cfb_console.c | 24 ++--
1 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index 1d52819..52e7fb4 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -230,8 +230,8 @@ CONFIG_VIDEO_HW_CURSOR: - Uses the hardware cursor
capability of the
#error only one of
CONFIG_CONSOLE_CURSOR,CONFIG_VIDEO_SW_CURSOR,CONFIG_VIDEO_HW_CURSOR can be
defined
#endif
void console_cursor (int state);
-#define CURSOR_ON console_cursor(1);
-#define CURSOR_OFF console_cursor(0);
+#define CURSOR_ON console_cursor(1)
+#define CURSOR_OFF console_cursor(0)
#define CURSOR_SET
#ifndef CONFIG_I8042_KBD
#warning Cursor drawing on/off needs timer function s.a. drivers/input/i8042.c
@@ -248,8 +248,8 @@ voidconsole_cursor (int state);
#endif
#define CURSOR_ON
#define CURSOR_OFF video_putchar(console_col * VIDEO_FONT_WIDTH,\
-console_row * VIDEO_FONT_HEIGHT, ' ');
-#define CURSOR_SET video_set_cursor();
+console_row * VIDEO_FONT_HEIGHT, ' ')
+#define CURSOR_SET video_set_cursor()
#endif /* CONFIG_VIDEO_SW_CURSOR */
@@ -260,7 +260,7 @@ voidconsole_cursor (int state);
#define CURSOR_ON
#define CURSOR_OFF
#define CURSOR_SET video_set_hw_cursor(console_col * VIDEO_FONT_WIDTH, \
- (console_row * VIDEO_FONT_HEIGHT) + video_logo_height);
+ (console_row * VIDEO_FONT_HEIGHT) + video_logo_height)
#endif /* CONFIG_VIDEO_HW_CURSOR */
#ifdef CONFIG_VIDEO_LOGO
@@ -651,7 +651,8 @@ static void console_scrollup (void)
static void console_back (void)
{
- CURSOR_OFF console_col--;
+ CURSOR_OFF;
+ console_col--;
if (console_col 0) {
console_col = CONSOLE_COLS - 1;
@@ -674,7 +675,7 @@ static void console_newline (void)
is = CONSOLE_COLS
*/
if (console_col CONSOLE_COLS)
- CURSOR_OFF
+ CURSOR_OFF;
console_row++;
console_col = 0;
@@ -690,7 +691,8 @@ static void console_newline (void)
static void console_cr (void)
{
- CURSOR_OFF console_col = 0;
+ CURSOR_OFF;
+ console_col = 0;
}
/*/
@@ -711,7 +713,8 @@ void video_putc (const char c)
break;
case 9: /* tab 8 */
- CURSOR_OFF console_col |= 0x0008;
+ CURSOR_OFF;
+ console_col |= 0x0008;
console_col = ~0x0007;
if (console_col = CONSOLE_COLS)
@@ -734,7 +737,8 @@ void video_putc (const char c)
nl = 0;
}
}
-CURSOR_SET}
+ CURSOR_SET;
+}
/*/
--
1.7.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] cmp_bmp: allow negative X, Y values for display command
I'm rescinding this patch. I have some new code that doesn't need this hack. On Wed, Aug 25, 2010 at 4:36 PM, Timur Tabi ti...@freescale.com wrote: The 'bmp display' command accepts optional X and Y values for the position of the image to be displayed. Change the code which parses the command line to accept negative values. This feature is useful if you want to use a frame buffer for the console, and you want a banner displayed on the top of the screen that never scrolls off. This can be accomplished by declaring that the width and height of the video screen is smaller than it really is, and then drawing an image in the undeclared area. For example, if you have 1280x1024 monitor, and you want to display a banner on the top of the screen that's 100 pixels tall, then video_hw_init() should say that display is really 1280x924, and then the banner should be drawn at position (0, -100). Signed-off-by: Timur Tabi ti...@freescale.com -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] mpc8610: refactor DIU initialization code to use existing bitmap function
I'm rescinding this patch. I'll have v2 some time next week. On Thu, Aug 26, 2010 at 3:59 PM, Timur Tabi ti...@freescale.com wrote: The Freescale MPC8610 DIU code has its own bitmap-drawing function, fsl_diu_display_bmp(), which is redundant. Instead, use the existing function video_display_bitmap(). Replacing fsl_diu_display_bmp() with video_display_bitmap() also requires refactoring the DIU initialization code. Signed-off-by: Timur Tabi ti...@freescale.com -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/7] fix dma for 36bit addressing
Use more bits to support 36-bit addressing
Signed-off-by: York Sun york...@freescale.com
---
drivers/dma/fsl_dma.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/fsl_dma.c b/drivers/dma/fsl_dma.c
index df33e7a..09c18c1 100644
--- a/drivers/dma/fsl_dma.c
+++ b/drivers/dma/fsl_dma.c
@@ -114,8 +114,12 @@ int dmacpy(phys_addr_t dest, phys_addr_t src, phys_size_t
count) {
while (count) {
xfer_size = MIN(FSL_DMA_MAX_SIZE, count);
- out_dma32(dma-dar, (uint) dest);
- out_dma32(dma-sar, (uint) src);
+ out_dma32(dma-dar, (u32) (dest 0x));
+ out_dma32(dma-sar, (u32) (src 0x));
+ out_dma32(dma-satr,
+ in_dma32(dma-satr) | (u32)((u64)src 32));
+ out_dma32(dma-datr,
+ in_dma32(dma-datr) | (u32)((u64)dest 32));
out_dma32(dma-bcr, xfer_size);
dma_sync();
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/7] Enable POST memory test for P2020DS
Signed-off-by: York Sun york...@freescale.com --- include/configs/P2020DS.h |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/include/configs/P2020DS.h b/include/configs/P2020DS.h index ee21d8b..8b76057 100644 --- a/include/configs/P2020DS.h +++ b/include/configs/P2020DS.h @@ -73,8 +73,9 @@ #define CONFIG_SYS_NUM_ADDR_MAP16 /* number of TLB1 entries */ #endif -#define CONFIG_SYS_MEMTEST_START 0x /* memtest works on */ -#define CONFIG_SYS_MEMTEST_END 0x7fff +#define CONFIG_POST CONFIG_SYS_POST_MEMORY /* test POST memory test */ +#define CONFIG_SYS_MEMTEST_START 0x0020 /* memtest works on */ +#define CONFIG_SYS_MEMTEST_END 0x0040 #define CONFIG_PANIC_HANG /* do not reset board on panic */ /* @@ -270,6 +271,7 @@ #define CONFIG_SYS_GBL_DATA_SIZE 128 /* num bytes initial data */ #define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_INIT_RAM_END - CONFIG_SYS_GBL_DATA_SIZE) +#define CONFIG_SYS_POST_WORD_ADDR (CONFIG_SYS_MPC85xx_PIC_ADDR + offsetof(ccsr_pic_t, tfrr)) #define CONFIG_SYS_INIT_SP_OFFSET CONFIG_SYS_GBL_DATA_OFFSET #define CONFIG_SYS_MONITOR_LEN (256 * 1024) /* Reserve 256 kB for Mon */ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/7] Fix parameters to support RDIMM for P2020DS
Signed-off-by: York Sun york...@freescale.com
---
arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c |1 +
board/freescale/p2020ds/ddr.c|4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c
b/arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c
index dccb7aa..e82082e 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c
@@ -613,6 +613,7 @@ static void set_ddr_sdram_cfg_2(fsl_ddr_cfg_regs_t *ddr,
#if defined(CONFIG_FSL_DDR3)
md_en = popts-mirrored_dimm;
#endif
+ rcw_en = popts-registered_dimm_en;
qd_en = popts-quad_rank_present ? 1 : 0;
ddr-ddr_sdram_cfg_2 = (0
| ((frc_sr 0x1) 31)
diff --git a/board/freescale/p2020ds/ddr.c b/board/freescale/p2020ds/ddr.c
index 30d640f..9a1b075 100644
--- a/board/freescale/p2020ds/ddr.c
+++ b/board/freescale/p2020ds/ddr.c
@@ -68,7 +68,7 @@ const board_specific_parameters_t
board_specific_parameters[][20] = {
{550, 680,1,4, 0x1f,3, 0},
{681, 850,1,4, 0x1f,4, 0}
#else
- { 0, 850,2,4, 0x1f,4, 0},
+ { 0, 850,2,6, 0x1f,4, 0},
{ 0, 850,1,4, 0x1f,4, 0}
#endif
},
@@ -120,7 +120,7 @@ void fsl_ddr_board_options(memctl_options_t *popts,
/* Write leveling override */
popts-wrlvl_override = 1;
popts-wrlvl_sample = 0xa;
- popts-wrlvl_start = 0x7;
+ popts-wrlvl_start = 0x8;
/* Rtt and Rtt_WR override */
popts-rtt_override = 1;
popts-rtt_override_value = DDR3_RTT_120_OHM;
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/7] Enabled POST for generic mpc85xx
Using PIC TFRR register for post word load/store for generic.
Fix post_word_store, post_word_load offset for mpc85xx with cpm
Signed-off-by: York Sun york...@freescale.com
---
arch/powerpc/cpu/mpc85xx/commproc.c |4 ++--
arch/powerpc/cpu/mpc85xx/cpu.c | 17 +
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/commproc.c
b/arch/powerpc/cpu/mpc85xx/commproc.c
index f0fd1cb..1671b5e 100644
--- a/arch/powerpc/cpu/mpc85xx/commproc.c
+++ b/arch/powerpc/cpu/mpc85xx/commproc.c
@@ -189,7 +189,7 @@ m8560_cpm_extcbrg(uint brg, uint rate, uint extclk, int
pinsel)
void post_word_store (ulong a)
{
volatile ulong *save_addr =
- (volatile ulong *)(CONFIG_SYS_IMMR + CPM_POST_WORD_ADDR);
+ (volatile ulong *)(CONFIG_SYS_MPC85xx_CPM_ADDR +
CPM_POST_WORD_ADDR);
*save_addr = a;
}
@@ -197,7 +197,7 @@ void post_word_store (ulong a)
ulong post_word_load (void)
{
volatile ulong *save_addr =
- (volatile ulong *)(CONFIG_SYS_IMMR + CPM_POST_WORD_ADDR);
+ (volatile ulong *)(CONFIG_SYS_MPC85xx_CPM_ADDR +
CPM_POST_WORD_ADDR);
return *save_addr;
}
diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c
index 634a0cd..9f3aa99 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu.c
@@ -286,6 +286,23 @@ void mpc85xx_reginfo(void)
print_lbc_regs();
}
+#ifdef CONFIG_POST
+
+__attribute__((weak))
+void post_word_store(ulong a)
+{
+ void *save_addr = (void *)(CONFIG_SYS_POST_WORD_ADDR);
+ out_be32(save_addr, a);
+}
+__attribute__((weak))
+ulong post_word_load(void)
+{
+ void *save_addr = (void *)(CONFIG_SYS_POST_WORD_ADDR);
+ return in_be32(save_addr);
+}
+
+#endif /* CONFIG_POST */
+
#if CONFIG_POST CONFIG_SYS_POST_MEMORY
/* Board-specific functions defined in each board's ddr.c */
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/7] Enable POST memory test for corenet_ds
Signed-off-by: York Sun york...@freescale.com --- include/configs/corenet_ds.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/configs/corenet_ds.h b/include/configs/corenet_ds.h index cf316e0..627f851 100644 --- a/include/configs/corenet_ds.h +++ b/include/configs/corenet_ds.h @@ -87,6 +87,7 @@ #define CONFIG_SYS_NUM_ADDR_MAP64 /* number of TLB1 entries */ #endif +#define CONFIG_POST CONFIG_SYS_POST_MEMORY /* test POST memory test */ #define CONFIG_SYS_MEMTEST_START 0x0020 /* memtest works on */ #define CONFIG_SYS_MEMTEST_END 0x0040 #define CONFIG_SYS_ALT_MEMTEST @@ -272,6 +273,7 @@ #define CONFIG_SYS_GBL_DATA_SIZE 128 /* num bytes initial data */ #define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_INIT_RAM_END - CONFIG_SYS_GBL_DATA_SIZE) +#define CONFIG_SYS_POST_WORD_ADDR (CONFIG_SYS_MPC85xx_PIC_ADDR + offsetof(ccsr_pic_t, tfrr)) #define CONFIG_SYS_INIT_SP_OFFSET CONFIG_SYS_GBL_DATA_OFFSET #define CONFIG_SYS_MONITOR_LEN (512 * 1024) -- 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 v4 3/4] mtdparts: add new sub-command spread
On Fri, Aug 27, 2010 at 9:51 AM, Ben Gardiner
bengardi...@nanometrics.ca wrote:
On Thu, Aug 26, 2010 at 5:12 PM, Scott Wood scottw...@freescale.com wrote:
+{
+ if (!mtd-block_isbad)
+ goto out;
+
+ u32 i, bb_delta = 0;
+
+ for (i = part-offset; i - bb_delta part-offset + part-size;
+ i += mtd-erasesize) {
+ if (mtd-block_isbad(mtd, i))
+ bb_delta += mtd-erasesize;
+ }
+
+ /*
+ * Absorb bad blocks immeadiately following this
+ * partition also into the partition, such that
+ * the next partition starts with a good block.
+ */
+ while (i mtd-size mtd-block_isbad(mtd, i)) {
+ bb_delta += mtd-erasesize;
+ i += mtd-erasesize;
+ }
Could this be refactored with get_len_incl_bad()? It should return both the
updated length and a flag indicating whether it was truncated.
Yes, I think so. Good point.
I have performed a refactoring but I have reached an impasse: the
'mtdparts spread' command is written for mtd devices whereas the
get_len_incl_bad() function is for NAND devices. I extracted a
function, mtd_get_len_incl_bad(), to which both the spread_partition
and nand_utils.c:get_len_incl_bad() function then delegated. But since
a board may have NAND enabled but not MTD_DEVICE (i.e. guruplug) I get
link errors sometimes. ATM I'm thinking of leaving the original
implementation of get_len_incl_bad in an #else. An alternative is to
move 'mtdparts spread' to 'nand mtdparts.spread' -- only OneNAND and
NAND devices (currently) have bad_block functions.
Best Regards,
Ben Gardiner
---
Nanometrics Inc.
+1 (613) 592-6776 x239
http://www.nanometrics.ca
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Why does logo_plot() not use video_display_bitmap()?
logo_plot() has its own code for rendering a bitmap, but this code is much less capable than video_display_bitmap(). Why doesn't logo_plot() just call video_display_bitmap() to draw the actual bitmap? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/4] mtdparts: add new sub-command spread
On Fri, Aug 27, 2010 at 5:46 PM, Scott Wood scottw...@freescale.com wrote: On 08/27/2010 04:36 PM, Ben Gardiner wrote: On Fri, Aug 27, 2010 at 9:51 AM, Ben Gardiner bengardi...@nanometrics.ca wrote: But since a board may have NAND enabled but not MTD_DEVICE (i.e. guruplug) I get link errors sometimes. Grr... Eventually we ought to make NAND depend on MTD_DEVICE. It's 808 bytes currently in my build, but if we could get rid of/reduce specialized client code, it could more than make up for it. For now, I guess don't worry about sharing the code. Ok -- thanks, Scott. I'll re-spin on Monday. ATM I'm thinking of leaving the original implementation of get_len_incl_bad in an #else. An alternative is to move 'mtdparts spread' to 'nand mtdparts.spread' -- only OneNAND and NAND devices (currently) have bad_block functions. There's too much duplication between NAND and OneNAND as is; I'd rather do it at the MTD layer. Whew -- I'm glad I don't have to migrate all of the patches to new files. :) Best Regards, Ben Gardiner --- Nanometrics Inc. http://www.nanometrics.ca ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/4] mtdparts: add new sub-command spread
On 08/27/2010 04:46 PM, Scott Wood wrote: On 08/27/2010 04:36 PM, Ben Gardiner wrote: On Fri, Aug 27, 2010 at 9:51 AM, Ben Gardiner bengardi...@nanometrics.ca wrote: I have performed a refactoring but I have reached an impasse: the 'mtdparts spread' command is written for mtd devices whereas the get_len_incl_bad() function is for NAND devices. I extracted a function, mtd_get_len_incl_bad(), to which both the spread_partition and nand_utils.c:get_len_incl_bad() function then delegated. I figured the NAND code could just call the MTD-ized get_len_incl_bad() directly. But since a board may have NAND enabled but not MTD_DEVICE (i.e. guruplug) I get link errors sometimes. Grr... Eventually we ought to make NAND depend on MTD_DEVICE. It's 808 bytes currently in my build, but if we could get rid of/reduce specialized client code, it could more than make up for it. For now, I guess don't worry about sharing the code. Plus, I've got some changes to the NAND command/util code I'm about to send out that touch this -- if sharing is going to be a pain, I can go back to the version that only passes back fits with bad blocks, fits with no bad blocks, or doesn't fit, and doesn't deal with 64-bit sizes because it's only used by read/write which is limited by pointer size. That simpler version is 128 bytes smaller in my build. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/4] mtdparts: add new sub-command spread
On 08/27/2010 04:36 PM, Ben Gardiner wrote: On Fri, Aug 27, 2010 at 9:51 AM, Ben Gardiner bengardi...@nanometrics.ca wrote: I have performed a refactoring but I have reached an impasse: the 'mtdparts spread' command is written for mtd devices whereas the get_len_incl_bad() function is for NAND devices. I extracted a function, mtd_get_len_incl_bad(), to which both the spread_partition and nand_utils.c:get_len_incl_bad() function then delegated. I figured the NAND code could just call the MTD-ized get_len_incl_bad() directly. But since a board may have NAND enabled but not MTD_DEVICE (i.e. guruplug) I get link errors sometimes. Grr... Eventually we ought to make NAND depend on MTD_DEVICE. It's 808 bytes currently in my build, but if we could get rid of/reduce specialized client code, it could more than make up for it. For now, I guess don't worry about sharing the code. ATM I'm thinking of leaving the original implementation of get_len_incl_bad in an #else. An alternative is to move 'mtdparts spread' to 'nand mtdparts.spread' -- only OneNAND and NAND devices (currently) have bad_block functions. There's too much duplication between NAND and OneNAND as is; I'd rather do it at the MTD layer. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Request to become a member of u-boot-users mailing list
Hi, I would like to become a memeber of u-boot-user mailing list. can you please add or allow me a memeber of u-boot-user mailing list. Thanks, Chandrasekhar N ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] UnCorrectable RS-ECC Error occurs when reading NAND flash under u-boot 2009.08 for i.mx25
Hi, every one.
This is my first time of posting a message here, firstly , thanks for any
body who builds such a nice platform give help.
In recent two weeks, I added a NAND flash driver support for Micron's
MT29F2G08ABD (SLC;page size: x8 2048+64bytes; Block size: 64 pages; Device
size: 2Gb) memory chip base on u-boot 2009.08 for i.mx25. Block Erasing and
Page Programming functions worked properly, but when I do page reading
operation, UnCorrectable RS-ECC Error error message prompted. I checked
the NFC (NAND Flash Controller) spare area buffer and found that the 4th
512-byte spare area buffer's data were very weird, there is not any ECC code
that should be generated by the FEC but contained the data what I programmed
to the memory.
In order to easy to do troubleshooting works, I make a simply testing
process, what I do is, firstly, I only erase page 0 of block 0, and later I
program the erased page with a 2k file which consisted of 2048 same
character 'E', at last I read the page back , but UnCorrectable RS-ECC
Error occurs. I pasted the contents of NFC's spare area buffer as
following:
bb001000: 66ff bab935d1 22446bbd...f.5...kD
bb001010: b935d166 ffba f.5.
bb001020: 5f7467b9 21650de8 4d97fbd0 3166372c.gt_..e!...M,7f1
bb001030: 3b7e8bef b1cf62a5 bb8f50f6 de0031b3..~;.b...P...1..
bb001040: 66ff bab935d1 22446bbd...f.5...kD
bb001050: b935d166 ffba f.5.
bb001060: bafcf1fa 0c0698ef 09089d72 e6200c80r. .
bb001070: d638f5ef 20130b40 591dd763 e224f527@.. c..Y'.$.
bb001080: 66ff bab935d1 22446bbd...f.5...kD
bb001090: b935d166 ffba f.5.
bb0010a0: 76fa88ba 7a648809 d27bbc43 6b2b81cf...v..dzC.{...+k
bb0010b0: f6b95e3b 1286638e 73d324fb 22880ce5;^...c...$.s...
bb0010c0: 45454545 45454545 45454545 45454545
bb0010d0: 45454545 45454545 45454545 45454545
bb0010e0: 36d8f3d5 0099a9e7 eb289d07 11664624...6..(.$Ff.
bb0010f0: 4fbb9f24 505ab041 25ff61f6 43280406$..OA.ZP.a.%..(C
Contents written in red characters should be ECC code, but changed to what
I programmed to the memory in preverious programming process.
Any advice, please feel free to tell me. Thanks very much in advance.
--
View this message in context:
http://old.nabble.com/%22UnCorrectable-RS-ECC-Error%22-occurs-when-reading-NAND-flash-under-u-boot-2009.08-for-i.mx25-tp29558468p29558468.html
Sent from the Uboot - Users mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/4] mtdparts: add new sub-command spread
On Fri, Aug 27, 2010 at 5:59 PM, Scott Wood scottw...@freescale.com wrote: On 08/27/2010 04:46 PM, Scott Wood wrote: For now, I guess don't worry about sharing the code. Plus, I've got some changes to the NAND command/util code I'm about to send out that touch this -- if sharing is going to be a pain, I can go back to the version that only passes back fits with bad blocks, fits with no bad blocks, or doesn't fit, and doesn't deal with 64-bit sizes because it's only used by read/write which is limited by pointer size. That simpler version is 128 bytes smaller in my build. I imagine you don't have to go back. I wouldn't want to make the merge harder; but as long as there is a way to get the the size-including-bad-blocks and truncation status given an offset and target size. Please continue your work and I'll find a way to make 'mtdparts spread' fit with it after your post.. Best Regards, Ben Gardiner --- Nanometrics Inc. +1 (613) 592-6776 x239 http://www.nanometrics.ca ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] UnCorrectable RS-ECC Error occurs when reading NAND flash under u-boot 2009.08 for i.mx25
because characters couldn't be written in red, so I put the wrong contents as
following:
bb0010c0: 45454545 45454545 45454545 45454545
bb0010d0: 45454545 45454545 45454545 45454545
I really appreciate any suggestions very much.
dajiang.zhong wrote:
Hi, every one.
This is my first time of posting a message here, firstly , thanks for any
body who builds such a nice platform give help.
In recent two weeks, I added a NAND flash driver support for Micron's
MT29F2G08ABD (SLC;page size: x8 2048+64bytes; Block size: 64 pages; Device
size: 2Gb) memory chip base on u-boot 2009.08 for i.mx25. Block Erasing
and Page Programming functions worked properly, but when I do page
reading operation, UnCorrectable RS-ECC Error error message prompted.
I checked the NFC (NAND Flash Controller) spare area buffer and found that
the 4th 512-byte spare area buffer's data were very weird, there is not
any ECC code that should be generated by the FEC but contained the data
what I programmed to the memory.
In order to easy to do troubleshooting works, I make a simply testing
process, what I do is, firstly, I only erase page 0 of block 0, and later
I program the erased page with a 2k file which consisted of 2048 same
character 'E', at last I read the page back , but UnCorrectable RS-ECC
Error occurs. I pasted the contents of NFC's spare area buffer as
following:
bb001000: 66ff bab935d1 22446bbd...f.5...kD
bb001010: b935d166 ffba f.5.
bb001020: 5f7467b9 21650de8 4d97fbd0 3166372c.gt_..e!...M,7f1
bb001030: 3b7e8bef b1cf62a5 bb8f50f6 de0031b3..~;.b...P...1..
bb001040: 66ff bab935d1 22446bbd...f.5...kD
bb001050: b935d166 ffba f.5.
bb001060: bafcf1fa 0c0698ef 09089d72 e6200c80r. .
bb001070: d638f5ef 20130b40 591dd763 e224f527@.. c..Y'.$.
bb001080: 66ff bab935d1 22446bbd...f.5...kD
bb001090: b935d166 ffba f.5.
bb0010a0: 76fa88ba 7a648809 d27bbc43 6b2b81cf...v..dzC.{...+k
bb0010b0: f6b95e3b 1286638e 73d324fb 22880ce5;^...c...$.s...
bb0010c0: 45454545 45454545 45454545 45454545
bb0010d0: 45454545 45454545 45454545 45454545
bb0010e0: 36d8f3d5 0099a9e7 eb289d07 11664624...6..(.$Ff.
bb0010f0: 4fbb9f24 505ab041 25ff61f6 43280406$..OA.ZP.a.%..(C
Contents written in red characters should be ECC code, but changed to
what I programmed to the memory in preverious programming process.
Any advice, please feel free to tell me. Thanks very much in advance.
Thanks Regards,
Leon Zhong
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
--
View this message in context:
http://old.nabble.com/-U-Boot--%22UnCorrectable-RS-ECC-Error%22-occurs-when-reading-NAND-flash-under-u-boot-2009.08-for-i.mx25-tp29558415p29558524.html
Sent from the Uboot - Users mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Orion5x: bugfix: window size (mis)calculation
Hello Albert,
Le 27/08/2010 07:37, Albert ARIBAUD a écrit :
Le 27/08/2010 07:00, Chris Moore a écrit :
I think your proposal to handle size 0 as meaning '4 MB' is fine,
since there is no way to express 4MB and a zero size is meaningless as
such.
s/MB/GiB/
I agree that it is the most useful.
It also gives the shortest code as it needs no special handling ;-)
If I have misunderstood, please tell me and I'll rewrite.
That's fine. Do you want me to resubmit a V2 patch with your change,
or will you subit it yourself?
I'd prefer you to submit it if you don't mind as I don't have a U-Boot
git tree ATM.
Please consider the following version where I have tried to improve the
comments.
The only other changes are:
a) to keep the return value an unsigned int as in the original.
b) to copy the argument to a local variable.
This enables me to have an argument with a descriptive name and a
variable with a short name to stay within 78 columns.
/*
* The spammers are right: size *is* important ;-)
* This version will not work if sizeval is more than 32 bits.
* I have therefore made it a u32 to underline this.
* The return value does not need to be a u32 so I left it as an
unsigned int.
*/
unsigned int orion5x_winctrl_calcsize_CM_fast(u32 sizeval)
{
u32 x = sizeval;
/*
* Requesting a window with a size of 0 bytes makes no sense.
* A sizeval of 0 therefore needs special handling such as:
* a) treat 0 as 4 GiB.
* b) treat 0 as an error.
* c) treat 0 as requiring one 64 KiB block.
*
* The most useful is probably to treat 0 as 4 GiB as we do here.
* This occurs naturally and needs no special handling.
*/
/*
* Step 1: Get the most significant one (MSO) in the correct bit
position.
*
* Calculate the number of 64 KiB blocks needed minus one (rounding up).
* For x 0 this is equivalent to x = (u32) ceil((double) x /
65536.0) - 1
*/
x = (x - 1) 16;
/*
* Step 2: Force all bits to the right of the MSO to one.
*
* The right shift above ensures that the 16 MSB of x are zero.
* So, for a u32, there are never more than 15 bits to the right of
the MSO.
* We 'or' the MSO into them which forces them to one.
*/
x |= x 1; /* Force the first bit to the right of the MSO to one */
x |= x 2; /* Force the next 2 bits to the right of the MSO to one */
x |= x 4; /* Force the next 4 bits to the right of the MSO to one */
x |= x 8; /* Force the next 8 bits to the right of the MS0 to one */
return x;
}
Without comments I think the code would be difficult to understand.
However it may now be overcommented.
Please feel free to modify the comments.
If necessary you can add my SOB.
Cheers,
Chris
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
