Re: [U-Boot] [PATCH] debug_print macros support
Dear Wolfgang Denk -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Friday, April 03, 2009 11:23 PM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; Ronen Shitrit Subject: Re: [U-Boot] [PATCH] debug_print macros support Dear Prafulla Wadaskar, In message 1238759359-6544-1-git-send-email-prafu...@marvell.com you wrote: From: prafulla_wadaskar prafu...@marvell.com This debug_prints strategy provides- A. pre-formatted debug and print macros to be used in a code B. flexiblility to enable selective debug prints without modifying a source code For more details refer doc/README.debug_prints Signed-off-by: prafulla_wadaskar prafu...@marvell.com This seems to be a lot of effort, from code to command line pollution - for what exactly? Which is the problem you are trying to solve? If I understood current u-boot debugging properly, the debug statements are enabled by editing src file by adding #define DEBUG Doing this the release contents will be tampered, this may not be relevant from development point of view. But the same release will be used by validation/testing/QA guys and to debug anything out of released contents, no one would like to tamper the source code subject to condition proper debugging strategy is in place. Secondly, even during development it is a pain to enable/disable debug statements for their needs and finally remove them before release. I suffered this pain that's why discovered this strategy. The suggested patch provides totally optional strategy that offers- A) enabling selective debug statements without modifying source code B) enabling selective debug statements only from specific source file/s C) Last but not least- simple, small, easy to understand code. Again.. it is an optional value added tool for u-boot developers :-) Regards.. Prafulla . . Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Wisdom is one of the few things that looks bigger the further away it is. - Terry Pratchett, _Witches Abroad_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OneNand support broken for apollon
On Apr 05, 2009 01:40 Jean-Christophe Wrote : Your patch Fix OneNAND ipl to read CONFIG_SYS_MONITOR_LEN brake the appolon Could you take a look? - Can you please do let me know , where exactly do you see a problem ? With Regards Moorthy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] debug_print macros support
On Monday 06 April 2009 01:32:30 Prafulla Wadaskar wrote: If I understood current u-boot debugging properly, the debug statements are enabled by editing src file by adding #define DEBUG Doing this the release contents will be tampered, this may not be relevant from development point of view. But the same release will be used by validation/testing/QA guys and to debug anything out of released contents, no one would like to tamper the source code subject to condition proper debugging strategy is in place. not really true ... you can do: make DBGFLAGS=-DDEBUG but that will probably enable debug() statements in a lot of things you dont care about ... i dont really have an opinion on the idea in general -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] debug_print macros support
-Original Message- From: Mike Frysinger [mailto:vap...@gentoo.org] Sent: Monday, April 06, 2009 12:01 PM To: u-boot@lists.denx.de Cc: Prafulla Wadaskar; Wolfgang Denk; Ronen Shitrit Subject: Re: [U-Boot] [PATCH] debug_print macros support On Monday 06 April 2009 01:32:30 Prafulla Wadaskar wrote: If I understood current u-boot debugging properly, the debug statements are enabled by editing src file by adding #define DEBUG Doing this the release contents will be tampered, this may not be relevant from development point of view. But the same release will be used by validation/testing/QA guys and to debug anything out of released contents, no one would like to tamper the source code subject to condition proper debugging strategy is in place. not really true ... you can do: make DBGFLAGS=-DDEBUG but that will probably enable debug() statements in a lot of things you dont care about ... Even this can be resolved by this patch implementation Regards.. Prafulla . . i dont really have an opinion on the idea in general -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Compiling for ARMv7-a
-Original Message- From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com] Sent: Saturday, April 04, 2009 9:41 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Compiling for ARMv7-a On 21:27 Thu 02 Apr , Premi, Sanjeev wrote: Hi, I am trying to build the u-boot for ARM Cortex-A8 (OMAP3). By default the code is built for ARMv5. So, I made this change in cpu/arm_cortexa8/config.mk: # Make ARMv5 to allow more compilers to work, even though its v7a. -PLATFORM_CPPFLAGS += -march=armv5 +PLATFORM_CPPFLAGS += -march=armv7-a you do not need to modify any thing the current tree support omap3 we just not use the armv7-a optimization to be compatible with the maximum of toolchains maybe you could explain us why you need it? [sp] Only as an exercise to see if compiling for ARM v7 provides any better performance - speed and/or power-consumption. Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Macronix MX25xx MTD SPI flash driver
-Original Message-
From: Mike Frysinger [mailto:vap...@gentoo.org]
Sent: Friday, April 03, 2009 7:44 PM
To: u-boot@lists.denx.de
Cc: Prafulla Wadaskar; Ronen Shitrit
Subject: Re: [U-Boot] [PATCH] Macronix MX25xx MTD SPI flash driver
On Friday 03 April 2009 07:49:19 Prafulla Wadaskar wrote:
--- a/drivers/mtd/spi/Makefile
+++ b/drivers/mtd/spi/Makefile
@@ -28,6 +28,7 @@ LIB := $(obj)libspi_flash.a
COBJS-$(CONFIG_SPI_FLASH) += spi_flash.o
COBJS-$(CONFIG_SPI_FLASH_ATMEL)+= atmel.o
COBJS-$(CONFIG_SPI_FLASH_STMICRO) += stmicro.o
+COBJS-$(CONFIG_SPI_FLASH_MACRONIX) += macronix.o
please keep the list sorted
Done..
--- /dev/null
+++ b/drivers/mtd/spi/macronix.c
@@ -0,0 +1,319 @@
+ * Based on drivers/mtd/spi/stmicor.c
typo in file name
Corrected..
+ * You should have received a copy of the GNU General
Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+#include common.h
please add a new line there
Added..
+/* MX25Pxx-specific commands */
+#define CMD_MX25PXX_WREN 0x06/* Write Enable */
+#define CMD_MX25PXX_WRDI 0x04/* Write Disable */
+#define CMD_MX25PXX_RDSR 0x05/* Read Status Register */
+#define CMD_MX25PXX_WRSR 0x01/* Write Status Register */
+#define CMD_MX25PXX_READ 0x03/* Read Data Bytes */
+#define CMD_MX25PXX_FAST_READ 0x0b/* Read Data
Bytes at Higher Speed */
+#define CMD_MX25PXX_PP 0x02/* Page Program */
+#define CMD_MX25PXX_SE 0x20/* Sector Erase */
+#define CMD_MX25PXX_BE 0xD8/* Block Erase */
+#define CMD_MX25PXX_CE 0xc7/* Chip Erase */
+#define CMD_MX25PXX_DP 0xb9/* Deep Power-down */
+#define CMD_MX25PXX_RES0xab/* Release from
DP, and Read Signature */
is it really MX25PXX ? or should it be MX25XX ? the P looks
like a hold over from the stmicro driver.
You are right
It should be MX25LXX for 3.0 volt operation And it should be
MX27VXX for 2.5 volt operation To address a common driver for
both, I am making it MX25XX
+struct macronix_spi_flash {
+ const struct macronix_spi_flash_params *params;
+ struct spi_flash flash;
+};
the spi_flash struct needs to be the first member in order to
prevent crashes when working with the spi flash layer
Done..
+ u8 cmd[4] = { CMD_MX25PXX_RDSR, 0xff, 0xff, 0xff };
+
+ ret = spi_xfer(spi, 32, cmd[0], NULL, SPI_XFER_BEGIN);
do you actually need to read/write 4 bytes here ? shouldnt it be:
u8 cmd = CMD_MX25PXX_RDSR;
ret = spi_xfer(spi, 8, cmd, NULL, SPI_XFER_BEGIN);
Yes, I have checked specs too, we need only 8bit transfer here
Done...
+ if (ret) {
+ debug(SF: Failed to send command %02x: %d\n,
cmd[0], ret);
then you'll need to change to cmd
+ debug(SF: STMicro Page Program failed\n);
+ debug(SF: STMicro: Successfully programmed %u bytes @ 0x%x\n,
+ len, offset);
+ debug(SF: STMicro page erase failed\n);
+ debug(SF: STMicro page erase timed out\n);
+ debug(SF: STMicro: Successfully erased %u bytes @ 0x%x\n,
+ len * sector_size, offset);
+ debug(SF: Unsupported STMicro ID %02x\n, id[1]);
this isnt STMicro anymore ...
Corrected... Very sorry for this :-(
+ /* Up to 2 seconds */
+ ret = macronix_wait_ready(flash, 2 * CONFIG_SYS_HZ);
there's a common flash erase timeout define
Block erase time for Micronix are different than specified in
spi_flash_internals.h
Hence MICRONIX spefic timouts defined and used in macronix.c
+*spi_flash_probe_macronix(struct spi_slave *spi, u8 * idcode)
no space between * and idcode
Done..
+ u8 id[3];
+
+ ret = spi_flash_cmd(spi, CMD_READ_ID, id, sizeof(id));
+ if (ret)
+ return NULL;
no need to read id here ... use the idcode passed in to you
Done..
+ if (params-idcode1 == idcode[2]) {
+ break;
+ }
drop the {} braces
Dropped..
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -3,7 +3,6 @@
*
* Copyright (C) 2008 Atmel Corporation
*/
-#define DEBUG
#include common.h
#include malloc.h
#include spi.h
please drop this hunk ... it doesnt belong in this patch (and
it's already been merged elsewhere) -mike
Okay Dropped
I am ready with the updated patch,
How should I release it the community?
1. new patch with review feedback (with same name)
Or
2. Delta on the top of previous patch
Any suggestion...?
Regards..
Prafulla . .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] bin_dep.sh Support
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Friday, April 03, 2009 11:25 PM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; Ronen Shitrit Subject: Re: [U-Boot] [PATCH] bin_dep.sh Support Dear Prafulla Wadaskar, In message 1238759359-6544-2-git-send-email-prafu...@marvell.com you wrote: From: prafulla_wadaskar prafu...@marvell.com In some cases the u-boot.bin need to be processed further to create bootable u-boot binary from boot device This processing may be cpu,soc and/or board spcific bin_dep.sh provides a mechanism to execute bin_dep.sh if present in above platform specific folders Signed-off-by: prafulla_wadaskar prafu...@marvell.com --- Makefile |2 + tools/bin_dep.sh | 79 ++ 2 files changed, 81 insertions(+), 0 deletions(-) create mode 100755 tools/bin_dep.sh I don't see use cases for this. This should probably remain out of tree. Dear Wolfgang Denk Relevant use case will be Marvell Kirkwood SOC, this patch will be dependency for the same Regards.. Prafulla . . Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I can't understand it. I can't even understand the people who can understand it.- Queen Juliana of the Netherlands. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Macronix MX25xx MTD SPI flash driver
On Monday 06 April 2009 03:23:30 Prafulla Wadaskar wrote: + /* Up to 2 seconds */ + ret = macronix_wait_ready(flash, 2 * CONFIG_SYS_HZ); there's a common flash erase timeout define Block erase time for Micronix are different than specified in spi_flash_internals.h Hence MICRONIX spefic timouts defined and used in macronix.c every flash will have a different erase time, but i have a hard time believing you picked 2*HZ (2 seconds) because of your part's requirements. more likely you copied that from the stmicro driver (like every other spi flash driver until i cleaned them up). the latest tree increases the common timeouts to seconds rather than milliseconds, so unless your flash is truly truly awful and requires longer than that, you should use the common define. I am ready with the updated patch, How should I release it the community? 1. new patch with review feedback (with same name) the current accepted practice is for you to: - update the patch with all the comments - add a v2 to the subject (so it'd be [PATCH v2] Macronix .) - in the comments section of the formatted patch (after the --- marker and above the diffstat), add notes about what changed in the updated patch - send it with the reply to header set to the last relevant message in the patches' thread 2. Delta on the top of previous patch no dont ever do this :) -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/8] Blackfin fixes for 2009.05
Add some corner case fixes for some Blackfin peripheral drivers, and add some fixes for anomalies and auditing of others. One or two of the audits aren't strictly fixes (just adding /*...*/ comments(, but it makes my life easier to keep them together. Graf Yang (1): Blackfin: nand: flush peripheral before polling it Mike Frysinger (6): Blackfin: update anomaly sheets Blackfin: add workaround for anomaly 05000171 Blackfin: add workaround for anomaly 05000242 Blackfin: add comment about anomaly 05000430 avoidance Blackfin: add check for anomaly 05000362 Blackfin: audit UART for all known anomalies Todor I Mollov (1): Blackfin: spi: make cs deassert function deterministic cpu/blackfin/initcode.c | 17 ++- cpu/blackfin/serial.c | 21 - cpu/blackfin/serial.h |2 +- drivers/mtd/nand/bfin_nand.c |1 + drivers/spi/bfin_spi.c| 16 ++- include/asm-blackfin/mach-bf527/anomaly.h | 40 --- include/asm-blackfin/mach-bf533/anomaly.h | 77 +++- include/asm-blackfin/mach-bf537/anomaly.h | 67 + include/asm-blackfin/mach-bf548/anomaly.h | 18 --- include/asm-blackfin/mach-bf561/anomaly.h | 17 +++--- 10 files changed, 203 insertions(+), 73 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/8] Blackfin: update anomaly sheets
Signed-off-by: Mike Frysinger vap...@gentoo.org --- include/asm-blackfin/mach-bf527/anomaly.h | 40 --- include/asm-blackfin/mach-bf533/anomaly.h | 77 +++- include/asm-blackfin/mach-bf537/anomaly.h | 67 + include/asm-blackfin/mach-bf548/anomaly.h | 18 --- include/asm-blackfin/mach-bf561/anomaly.h | 17 +++--- 5 files changed, 150 insertions(+), 69 deletions(-) diff --git a/include/asm-blackfin/mach-bf527/anomaly.h b/include/asm-blackfin/mach-bf527/anomaly.h index df6808d..0fd7e31 100644 --- a/include/asm-blackfin/mach-bf527/anomaly.h +++ b/include/asm-blackfin/mach-bf527/anomaly.h @@ -6,9 +6,9 @@ * Licensed under the GPL-2 or later. */ -/* This file shoule be up to date with: +/* This file should be up to date with: * - Revision B, 08/12/2008; ADSP-BF526 Blackfin Processor Anomaly List - * - Revision E, 08/18/2008; ADSP-BF527 Blackfin Processor Anomaly List + * - Revision F, 03/03/2009; ADSP-BF527 Blackfin Processor Anomaly List */ #ifndef _MACH_ANOMALY_H_ @@ -25,14 +25,16 @@ # define ANOMALY_BF527 0 #endif -/* Multi-Issue Instruction with dsp32shiftimm in slot1 and P-reg Store in slot2 Not Supported */ +/* Multi-issue instruction with dsp32shiftimm in slot1 and P-reg store in slot 2 not supported */ #define ANOMALY_0574 (1) /* DMA_RUN Bit Is Not Valid after a Peripheral Receive Channel DMA Stops */ #define ANOMALY_05000119 (1) /* note: brokenness is noted in documentation, not anomaly sheet */ /* Rx.H Cannot Be Used to Access 16-bit System MMR Registers */ #define ANOMALY_05000122 (1) -/* Spurious Hardware Error from an Access in the Shadow of a Conditional Branch */ +/* False Hardware Error from an Access in the Shadow of a Conditional Branch */ #define ANOMALY_05000245 (1) +/* Incorrect Timer Pulse Width in Single-Shot PWM_OUT Mode with External Clock */ +#define ANOMALY_05000254 (1) /* Sensitivity To Noise with Slow Input Edge Rates on External SPORT TX and RX Clocks */ #define ANOMALY_05000265 (1) /* False Hardware Errors Caused by Fetches at the Boundary of Reserved Memory */ @@ -41,6 +43,8 @@ #define ANOMALY_05000313 (__SILICON_REVISION__ 2) /* Incorrect Access of OTP_STATUS During otp_write() Function */ #define ANOMALY_05000328 (ANOMALY_BF527 __SILICON_REVISION__ 2) +/* Host DMA Boot Modes Are Not Functional */ +#define ANOMALY_05000330 (__SILICON_REVISION__ 2) /* Disallowed Configuration Prevents Subsequent Allowed Configuration on Host DMA Port */ #define ANOMALY_05000337 (ANOMALY_BF527 __SILICON_REVISION__ 2) /* Ethernet MAC MDIO Reads Do Not Meet IEEE Specification */ @@ -75,8 +79,6 @@ #define ANOMALY_05000380 (ANOMALY_BF527 __SILICON_REVISION__ 2) /* 8-Bit NAND Flash Boot Mode Not Functional */ #define ANOMALY_05000382 (__SILICON_REVISION__ 2) -/* Host Must Not Read Back During Host DMA Boot */ -#define ANOMALY_05000384 (ANOMALY_BF527 __SILICON_REVISION__ 2) /* Boot from OTP Memory Not Functional */ #define ANOMALY_05000385 (ANOMALY_BF527 __SILICON_REVISION__ 2) /* bfrom_SysControl() Firmware Routine Not Functional */ @@ -129,7 +131,7 @@ #define ANOMALY_05000416 (1) /* SPORT0 Ignores External TSCLK0 on PG14 When TMR6 is an Output */ #define ANOMALY_05000417 (ANOMALY_BF527 __SILICON_REVISION__ 2) -/* tSFSPE and tHFSPE Do Not Meet Data Sheet Specifications */ +/* PPI Timing Requirements tSFSPE and tHFSPE Do Not Meet Data Sheet Specifications */ #define ANOMALY_05000418 (__SILICON_REVISION__ 2) /* USB PLL_STABLE Bit May Not Accurately Reflect the USB PLL's Status */ #define ANOMALY_05000420 (__SILICON_REVISION__ 2) @@ -143,25 +145,46 @@ #define ANOMALY_05000424 (ANOMALY_BF527 __SILICON_REVISION__ 2) /* Multichannel SPORT Channel Misalignment Under Specific Configuration */ #define ANOMALY_05000425 (__SILICON_REVISION__ 2) -/* Speculative Fetches of Indirect-Pointer Instructions Can Cause Spurious Hardware Errors */ +/* Speculative Fetches of Indirect-Pointer Instructions Can Cause False Hardware Errors */ #define ANOMALY_05000426 (1) /* WB_EDGE Bit in NFC_IRQSTAT Incorrectly Reflects Buffer Status Instead of IRQ Status */ #define ANOMALY_05000429 (__SILICON_REVISION__ 2) /* Software System Reset Corrupts PLL_LOCKCNT Register */ #define ANOMALY_05000430 (ANOMALY_BF527 __SILICON_REVISION__ 1) +/* Incorrect Use of Stack in Lockbox Firmware During Authentication */ +#define ANOMALY_05000431 (1) /* bfrom_SysControl() Does Not Clear SIC_IWR1 Before Executing PLL Programming Sequence */ #define ANOMALY_05000432 (ANOMALY_BF526) /* Certain SIC Registers are not Reset After Soft or Core Double Fault Reset */ #define ANOMALY_05000435 ((ANOMALY_BF526 __SILICON_REVISION__ 1) || ANOMALY_BF527) +/* Preboot Cannot be Used to Alter the PLL_DIV Register */ +#define ANOMALY_05000439 (1) +/* bfrom_SysControl() Cannot be Used to Write the PLL_DIV Register */ +#define ANOMALY_05000440 (1) +/* OTP Write Accesses Not Supported */
[U-Boot] [PATCH 1/8] Blackfin: spi: make cs deassert function deterministic
From: Todor I Mollov tmol...@ucsd.edu
Blackfin SPI driver was not driving the SPI chip-select high before
putting the chip-select signals into tri-state mode. This is probably
something that slipped by unnoticed in most designs. If the signals are
put directly into a tri-state mode, then the board is relying on the
pull-up resistors to pull up the chip-select before the next transaction.
Most of the time this is fine, except when you have two transactions that
follow each other very closely, such as the flash erase and read status
register commands. In this case I was seeing a 500ns separation between
the transactions. In my setup, with a 10kOhm pull-up, it would meet
timing spec about half the time and resulted in intermittent errors. (A
stronger pull up would fix this, but our design is targeted for low power
consumption and a 3.3kOhm @ 3.3v is 3.3mW of needless power consumption.)
I modified the spi_cs_deactivate() function in bfin_spi.c to drive the
chip-selects high before putting them into tri-state. For me, this
resulted in a rise time of 5ns instead of the previous rise time of about
1us, and fully satisfied the timing spec of the chip.
Signed-off-by: Todor I Mollov tmol...@ucsd.edu
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
drivers/spi/bfin_spi.c | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/bfin_spi.c b/drivers/spi/bfin_spi.c
index bc3394a..bc255cc 100644
--- a/drivers/spi/bfin_spi.c
+++ b/drivers/spi/bfin_spi.c
@@ -52,6 +52,7 @@ void spi_cs_activate(struct spi_slave *slave)
(read_SPI_FLG(bss)
~((!bss-flg 8) slave-cs)) |
(1 slave-cs));
+ SSYNC();
debug(%s: SPI_FLG:%x\n, __func__, read_SPI_FLG(bss));
}
@@ -59,7 +60,20 @@ __attribute__((weak))
void spi_cs_deactivate(struct spi_slave *slave)
{
struct bfin_spi_slave *bss = to_bfin_spi_slave(slave);
- write_SPI_FLG(bss, read_SPI_FLG(bss) ~(1 slave-cs));
+ u16 flg;
+
+ /* make sure we force the cs to deassert rather than let the
+* pin float back up. otherwise, exact timings may not be
+* met some of the time leading to random behavior (ugh).
+*/
+ flg = read_SPI_FLG(bss) | ((!bss-flg 8) slave-cs);
+ write_SPI_FLG(bss, flg);
+ SSYNC();
+ debug(%s: SPI_FLG:%x\n, __func__, read_SPI_FLG(bss));
+
+ flg = ~(1 slave-cs);
+ write_SPI_FLG(bss, flg);
+ SSYNC();
debug(%s: SPI_FLG:%x\n, __func__, read_SPI_FLG(bss));
}
--
1.6.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/8] Blackfin: nand: flush peripheral before polling it
From: Graf Yang graf.y...@analog.com We need to make sure the data written to the nand flash controller makes it there before we start polling its status register. Otherwise, we may get stale data and return before the controller is actually ready. Signed-off-by: Graf Yang graf.y...@analog.com Signed-off-by: Mike Frysinger vap...@gentoo.org --- drivers/mtd/nand/bfin_nand.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/nand/bfin_nand.c b/drivers/mtd/nand/bfin_nand.c index f6a0835..f134ef1 100644 --- a/drivers/mtd/nand/bfin_nand.c +++ b/drivers/mtd/nand/bfin_nand.c @@ -98,6 +98,7 @@ static void bfin_nfc_read_buf(struct mtd_info *mtd, uint8_t *buf, int len) /* Contents do not matter */ bfin_write_NFC_DATA_RD(0x); + SSYNC(); while (!(bfin_read_NFC_IRQSTAT() RD_RDY)) if (ctrlc()) -- 1.6.2.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/8] Blackfin: add workaround for anomaly 05000242
DESCRIPTION:
If the DF bit is set prior to a hardware reset, the PLL will continue to
divide CLKIN by 2 after the hardware reset, but the DF bit itself will be
cleared in the PLL_CTL register.
WORKAROUND:
Reprogram the PLL with DF cleared if the desire is to not divide CLKIN by
2 after reset.
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
cpu/blackfin/initcode.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cpu/blackfin/initcode.c b/cpu/blackfin/initcode.c
index d44c6a6..7f54860 100644
--- a/cpu/blackfin/initcode.c
+++ b/cpu/blackfin/initcode.c
@@ -401,7 +401,7 @@ void initcode(ADI_BOOT_DATA *bootstruct)
/* Only reprogram when needed to avoid triggering unnecessary
* PLL relock sequences.
*/
- if (bfin_read_PLL_CTL() != CONFIG_PLL_CTL_VAL) {
+ if (ANOMALY_05000242 || bfin_read_PLL_CTL() !=
CONFIG_PLL_CTL_VAL) {
serial_putc('!');
bfin_write_PLL_CTL(CONFIG_PLL_CTL_VAL);
asm(idle;);
--
1.6.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/8] Blackfin: add workaround for anomaly 05000171
DESCRIPTION:
The Boot ROM is executed at power up/reset and changes the value of the
SICA_IWR registers from their default reset value of 0x, but does not
restore them.
WORKAROUND:
User code should not rely on the default value of these registers. Set
the desired values explicitly.
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
cpu/blackfin/initcode.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/cpu/blackfin/initcode.c b/cpu/blackfin/initcode.c
index 3120447..d44c6a6 100644
--- a/cpu/blackfin/initcode.c
+++ b/cpu/blackfin/initcode.c
@@ -356,6 +356,10 @@ void initcode(ADI_BOOT_DATA *bootstruct)
#if ANOMALY_05000432
bfin_write_SIC_IWR1(-1);
#endif
+#if ANOMALY_05000171
+ bfin_write_SICA_IWR0(-1);
+ bfin_write_SICA_IWR1(-1);
+#endif
} else {
serial_putc('G');
--
1.6.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/8] Blackfin: add comment about anomaly 05000430 avoidance
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
cpu/blackfin/initcode.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/cpu/blackfin/initcode.c b/cpu/blackfin/initcode.c
index 7f54860..062cbb8 100644
--- a/cpu/blackfin/initcode.c
+++ b/cpu/blackfin/initcode.c
@@ -335,6 +335,7 @@ void initcode(ADI_BOOT_DATA *bootstruct)
if (!ANOMALY_05000386) {
serial_putc('F');
+ /* Always programming PLL_LOCKCNT avoids Anomaly 05000430 */
ADI_SYSCTRL_VALUES memory_settings;
uint32_t actions = SYSCTRL_WRITE | SYSCTRL_PLLCTL |
SYSCTRL_PLLDIV | SYSCTRL_LOCKCNT;
if (CONFIG_HAS_VR) {
@@ -379,6 +380,7 @@ void initcode(ADI_BOOT_DATA *bootstruct)
serial_putc('H');
+ /* Always programming PLL_LOCKCNT avoids Anomaly 05000430 */
bfin_write_PLL_LOCKCNT(CONFIG_PLL_LOCKCNT_VAL);
serial_putc('I');
--
1.6.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/8] Blackfin: add check for anomaly 05000362
DESCRIPTION:
The column address width settings for banks 2 and 3 are misconnected in
the SDRAM controller. Accesses to bank 2 will result in an error if the
Column Address Width for bank 3 (EB3CAW ) is not set to be the same as
that of bank 2.
WORKAROUND:
If using bank 2, make sure that banks 2 and 3 have the same column address
width settings in the EBIU_SDBCTL register. This must be the case
regardless of whether or not bank 3 is enabled.
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
cpu/blackfin/initcode.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/cpu/blackfin/initcode.c b/cpu/blackfin/initcode.c
index 062cbb8..aba00e0 100644
--- a/cpu/blackfin/initcode.c
+++ b/cpu/blackfin/initcode.c
@@ -246,6 +246,15 @@ static inline void serial_putc(char c)
#endif
#endif
+/* Conflicting Column Address Widths Causes SDRAM Errors:
+ * EB2CAW and EB3CAW must be the same
+ */
+#if ANOMALY_05000362
+# if ((CONFIG_EBIU_SDBCTL_VAL 0x3000) 8) != (CONFIG_EBIU_SDBCTL_VAL
0x0030)
+# error Anomaly 05000362: EB2CAW and EB3CAW must be the same
+# endif
+#endif
+
BOOTROM_CALLED_FUNC_ATTR
void initcode(ADI_BOOT_DATA *bootstruct)
{
--
1.6.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 8/8] Blackfin: audit UART for all known anomalies
There is no code change here, just new comments, but this keeps me from
having to do another audit from scratch in the future.
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
cpu/blackfin/serial.c | 21 -
cpu/blackfin/serial.h |2 +-
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/cpu/blackfin/serial.c b/cpu/blackfin/serial.c
index 3861955..2abda18 100644
--- a/cpu/blackfin/serial.c
+++ b/cpu/blackfin/serial.c
@@ -24,6 +24,19 @@
* Licensed under the GPL-2 or later.
*/
+/* Anomaly notes:
+ * 0586 - we don't support autobaud
+ * 0599 - we only use DR bit, so losing others is not a problem
+ * 05000100 - we don't use the UART_IIR register
+ * 05000215 - we poll the uart (no dma/interrupts)
+ * 05000225 - no workaround possible, but this shouldnt cause errors ...
+ * 05000230 - we tweak the baud rate calculation slightly
+ * 05000231 - we always use 1 stop bit
+ * 05000309 - we always enable the uart before we modify it in anyway
+ * 05000350 - we always enable the uart regardless of boot mode
+ * 05000363 - we don't support break signals, so don't generate one
+ */
+
#include common.h
#include watchdog.h
#include asm/blackfin.h
@@ -43,7 +56,9 @@ uint16_t cached_rbr[256];
size_t cache_count;
/* The LSR is read-to-clear on some parts, so we have to make sure status
- * bits aren't inadvertently lost when doing various tests.
+ * bits aren't inadvertently lost when doing various tests. This also
+ * works around anomaly 0599 at the same time by keeping a cumulative
+ * tally of all the status bits.
*/
static uint16_t uart_lsr_save;
static uint16_t uart_lsr_read(void)
@@ -59,6 +74,10 @@ static void uart_lsr_clear(void)
*pUART_LSR |= -1;
}
#else
+/* When debugging is disabled, we only care about the DR bit, so if other
+ * bits get set/cleared, we don't really care since we don't read them
+ * anyways (and thus anomaly 0599 is irrelevant).
+ */
static inline uint16_t uart_lsr_read(void) { return *pUART_LSR; }
static inline void uart_lsr_clear(void) { *pUART_LSR = -1; }
#endif
diff --git a/cpu/blackfin/serial.h b/cpu/blackfin/serial.h
index ce39148..7b47878 100644
--- a/cpu/blackfin/serial.h
+++ b/cpu/blackfin/serial.h
@@ -146,7 +146,7 @@ static inline void serial_early_init(void)
/* handle portmux crap on different Blackfins */
serial_do_portmux();
- /* Enable UART */
+ /* always enable UART -- avoids anomalies 05000309 and 05000350 */
*pUART_GCTL = UCEN;
/* Set LCR to Word Lengh 8-bit word select */
--
1.6.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] debug_print macros support
Dear Prafulla Wadaskar, In message 73173d32e9439e4abb5151606c3e19e250840...@sc-vexch1.marvell.com you wrote: This seems to be a lot of effort, from code to command line pollution - for what exactly? Which is the problem you are trying to solve? If I understood current u-boot debugging properly, the debug statements are enabled by editing src file by adding #define DEBUG Doing this the release contents will be tampered, This is just one way to solve this, which is most convenient when you want to enable debugging on a per-file level. Of course you can acchieve the same effect by just passing -DDEBUG as a compile option. The Makefile allows to do this globally - there are currently no fine-grained selections available by default. On the other hand, this is debug code which is not supposed to be present in a production release, so modifying the source seems a minor issue to me. But the same release will be used by validation/testing/QA guys and to debu g anything out of released contents, no one would like to tamper the source code subject to condition proper debugging strategy is in place. As mentioned, you can enable this by compile options as well. The suggested patch provides totally optional strategy that offers- A) enabling selective debug statements without modifying source code B) enabling selective debug statements only from specific source file/s C) Last but not least- simple, small, easy to understand code. Again.. it is an optional value added tool for u-boot developers :-) To be honest: I see more overhead added. Looks like overkill to me. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Even if you can deceive people about a product through misleading statements, sooner or later the product will speak for itself. - Hajime Karatsu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Compiling for ARMv7-a
Dear Premi, Sanjeev, In message b85a65d85d7eb246be421b3fb0fbb59301cc6fb...@dbde02.ent.ti.com you wrote: maybe you could explain us why you need it? [sp] Only as an exercise to see if compiling for ARM v7 provides any better performance - speed and/or power-consumption. ...both of which are most probably irrelevant in a boot loader, thatunder normal operating conditions has a total execution time of just a few hundred milliseconds per power-cycle. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Just because your doctor has a name for your condition doesn't mean he knows what it is. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] at91: Add support for esd MEESC board
Hi Jean-Christophe, Jean-Christophe PLAGNIOL-VILLARD wrote: On 10:24 Fri 27 Mar , Daniel Gorsulowski wrote: This patch adds support for MEESC board from esd gmbh. The MEESC is based on an Atmel AT91SAM9263 SoC. Signed-off-by: Daniel Gorsulowski daniel.gorsulow...@esd.eu --- please rebase your patch against git://git.denx.de/u-boot-at91.git branch clock Best Regards, J. sorry, but my board does not boot by this branch. Followed by the bootstrapper-RomBOOT-prompt just some cryptical characters appear. Seems like the cpu clock is not initialized correctly. The board uses an 16.0 Mhz crystal. I configured as followed: /* ARM asynchronous clock */ #define AT91_CPU_NAME AT91SAM9263 #define AT91_MAIN_CLOCK 1600/* 16.0 MHz crystal */ #define CONFIG_SYS_HZ 1000/* decrementer freq */ #define CONFIG_MEESC1 /* Board is esd MEESC */ #define CONFIG_ARM926EJS1 /* This is an ARM926EJS Core */ #define CONFIG_AT91SAM9263 1 /* It's an AT91SAM9263 SoC*/ #define CONFIG_ARCH_CPU_INIT1 ... If I build from git://git.denx.de/u-boot.git branch master after applying my patches, the board boots up correctly. Best Regards, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] bin_dep.sh Support
Dear Prafulla Wadaskar, In message 73173d32e9439e4abb5151606c3e19e250840...@sc-vexch1.marvell.com you wrote: I don't see use cases for this. This should probably remain out of tree. Relevant use case will be Marvell Kirkwood SOC, this patch will be dependen cy for the same It is obvious that you can invent some new stuff (or rather reinvent existing stuff) and then use it for your own boards. The questions remain if this makes sense, and if this should be added to mainline. From what I've seen from your image processing code, this looks largely redundant do already existing features, and I see little sense to add board-specific variants for everybody who wants to define his own private standard instead of using existing code. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de War isn't a good life, but it's life. -- Kirk, A Private Little War, stardate 4211.8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] debug_print macros support
On Monday 06 April 2009 03:56:39 Wolfgang Denk wrote: In message Prafulla Wadaskar wrote: This seems to be a lot of effort, from code to command line pollution - for what exactly? Which is the problem you are trying to solve? If I understood current u-boot debugging properly, the debug statements are enabled by editing src file by adding #define DEBUG Doing this the release contents will be tampered, This is just one way to solve this, which is most convenient when you want to enable debugging on a per-file level. Of course you can acchieve the same effect by just passing -DDEBUG as a compile option. The Makefile allows to do this globally - there are currently no fine-grained selections available by default. i havent tested it, but i think this should get fine-grained flags in a flexible manner ? (the out of tree isnt exact, but you see what i'm after) -mike diff --git a/config.mk b/config.mk index b1254e9..8791caa 100644 --- a/config.mk +++ b/config.mk @@ -209,20 +209,20 @@ exportTEXT_BASE PLATFORM_CPPFLAGS PLATFORM_RELFLAGS CPPFLAGS CFLAGS AFLAGS ifndef REMOTE_BUILD %.s: %.S - $(CPP) $(AFLAGS) -o $@ $ + $(CPP) $(AFLAGS) $(AFLAGS_$@) -o $@ $ %.o: %.S - $(CC) $(AFLAGS) -c -o $@ $ + $(CC) $(AFLAGS) $(AFLAGS_$@) -c -o $@ $ %.o: %.c - $(CC) $(CFLAGS) -c -o $@ $ + $(CC) $(CFLAGS) $(CFLAGS_$@) -c -o $@ $ else $(obj)%.s: %.S - $(CPP) $(AFLAGS) -o $@ $ + $(CPP) $(AFLAGS) $(AFLAGS_$@) -o $@ $ $(obj)%.o: %.S - $(CC) $(AFLAGS) -c -o $@ $ + $(CC) $(AFLAGS) $(AFLAGS_$@) -c -o $@ $ $(obj)%.o: %.c - $(CC) $(CFLAGS) -c -o $@ $ + $(CC) $(CFLAGS) $(CFLAGS_$@) -c -o $@ $ endif # 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 0/8] Blackfin fixes for 2009.05
Dear Mike Frysinger, In message 1239004434-13962-1-git-send-email-vap...@gentoo.org you wrote: Add some corner case fixes for some Blackfin peripheral drivers, and add some fixes for anomalies and auditing of others. One or two of the audits aren't strictly fixes (just adding /*...*/ comments(, but it makes my life easier to keep them together. nitpicking Note that, according to the updated release schedule, this will be v2009.06 ;-) /nitpicking I guess a pull request will follow soon? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Mandrell: You know what I think? Doctor: Ah, ah that's a catch question. With a brain your size you don't think, right? - Dr. Who ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/8] Blackfin fixes for 2009.05
On Monday 06 April 2009 04:07:18 Wolfgang Denk wrote: In message Mike Frysinger wrote: Add some corner case fixes for some Blackfin peripheral drivers, and add some fixes for anomalies and auditing of others. One or two of the audits aren't strictly fixes (just adding /*...*/ comments(, but it makes my life easier to keep them together. nitpicking Note that, according to the updated release schedule, this will be v2009.06 ;-) /nitpicking err, yeah, i forgot about that I guess a pull request will follow soon? for patch series, i like to let them sit for a day or two before asking for a pull request. inevitably, some one points out something i did wrong. -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] bin_dep.sh Support
Hi I'm not sure we are on the same page here, the Kirkwood has an internal bootROM which can only boot an image if this image is wrapped by a specific header. The do_image should take the u-boot bin and wrap it with this header. How do u suggest we will support this header generation for the U-Boot? Thanks for your help Ronen Shitrit -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Monday, April 06, 2009 11:05 AM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; Ronen Shitrit Subject: Re: [U-Boot] [PATCH] bin_dep.sh Support Dear Prafulla Wadaskar, In message 73173d32e9439e4abb5151606c3e19e250840...@sc-vexch1.marvell.com you wrote: I don't see use cases for this. This should probably remain out of tree. Relevant use case will be Marvell Kirkwood SOC, this patch will be dependen cy for the same It is obvious that you can invent some new stuff (or rather reinvent existing stuff) and then use it for your own boards. The questions remain if this makes sense, and if this should be added to mainline. From what I've seen from your image processing code, this looks largely redundant do already existing features, and I see little sense to add board-specific variants for everybody who wants to define his own private standard instead of using existing code. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de War isn't a good life, but it's life. -- Kirk, A Private Little War, stardate 4211.8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] bin_dep.sh Support
Dear Ronen Shitrit, In message 309002c0da137042828828fc53d7a9347e13537...@il-mb01.marvell.com you wrote: I'm not sure we are on the same page here, the Kirkwood has an internal bootROM which can only boot an image if this image is wrapped by a specific header. What a stupid (read: broken) hardware design. There are tons of standards for image formats, and even more commonly used formats I would not dare to call standard; but this processor has to invent yet another one? The do_image should take the u-boot bin and wrap it with this header. How do u suggest we will support this header generation for the U-Boot? Fix the hardware design? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de When anyone says `theoretically,' they really mean `not really.' - David Parnas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/8] Blackfin fixes for 2009.05
Dear Mike Frysinger, In message 200904060413.40502.vap...@gentoo.org you wrote: I guess a pull request will follow soon? for patch series, i like to let them sit for a day or two before asking for a pull request. inevitably, some one points out something i did wrong. Yes, of course. I just wanted to be sure. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Always try to do things in chronological order; it's less confusing that way. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] Blackfin: nand: flush peripheral before polling it
Dear Mike Frysinger, In message 1239004434-13962-3-git-send-email-vap...@gentoo.org you wrote: From: Graf Yang graf.y...@analog.com We need to make sure the data written to the nand flash controller makes it there before we start polling its status register. Otherwise, we may get stale data and return before the controller is actually ready. Signed-off-by: Graf Yang graf.y...@analog.com Signed-off-by: Mike Frysinger vap...@gentoo.org --- drivers/mtd/nand/bfin_nand.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/nand/bfin_nand.c b/drivers/mtd/nand/bfin_nand.c index f6a0835..f134ef1 100644 --- a/drivers/mtd/nand/bfin_nand.c +++ b/drivers/mtd/nand/bfin_nand.c @@ -98,6 +98,7 @@ static void bfin_nfc_read_buf(struct mtd_info *mtd, uint8_t *buf, int len) /* Contents do not matter */ bfin_write_NFC_DATA_RD(0x); + SSYNC(); Should such syncing not be integral part of the bfin_write_NFC_DATA_RD() aceessor? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de God is real, unless declared integer. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Compiling for ARMv7-a
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Monday, April 06, 2009 1:29 PM To: Premi, Sanjeev Cc: Jean-Christophe PLAGNIOL-VILLARD; u-boot@lists.denx.de Subject: Re: [U-Boot] Compiling for ARMv7-a Dear Premi, Sanjeev, In message b85a65d85d7eb246be421b3fb0fbb59301cc6fb...@dbde02.ent.ti.com you wrote: maybe you could explain us why you need it? [sp] Only as an exercise to see if compiling for ARM v7 provides any better performance - speed and/or power-consumption. ...both of which are most probably irrelevant in a boot loader, thatunder normal operating conditions has a total execution time of just a few hundred milliseconds per power-cycle. [sp] No, it was not for measuring u-boot but for a small application that I wanted to compare for power consumption. It is probably easier to play with caches, MMU, etc. in the u-boot than in Linux kernel. Application is merely a calculate-wait-calculate kind of loop. ~sanjeev Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Just because your doctor has a name for your condition doesn't mean he knows what it is. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Macronix MX25xx MTD SPI flash driver
-Original Message- From: Mike Frysinger [mailto:vap...@gentoo.org] Sent: Monday, April 06, 2009 1:09 PM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; Ronen Shitrit Subject: Re: [U-Boot] [PATCH] Macronix MX25xx MTD SPI flash driver On Monday 06 April 2009 03:23:30 Prafulla Wadaskar wrote: + /* Up to 2 seconds */ + ret = macronix_wait_ready(flash, 2 * CONFIG_SYS_HZ); there's a common flash erase timeout define Block erase time for Micronix are different than specified in spi_flash_internals.h Hence MICRONIX spefic timouts defined and used in macronix.c every flash will have a different erase time, but i have a hard time believing you picked 2*HZ (2 seconds) because of your part's requirements. more likely you copied that from the stmicro driver (like every other spi flash driver until i cleaned them up). the latest tree increases the common timeouts to seconds rather than milliseconds, so unless your flash is truly truly awful and requires longer than that, you should use the common define. The MX25L12805D specifies Block erase max time to 2sec Even sector erase time is higher (300milsec) Specs can be found at (page 37) http://www.macronix.com/QuickPlace/hq/PageLibrary4825740B00298A3B.nsf/h_Index/7CE3021F57B8EA4848257412002E26CC/$File/MX25L12805D-1.1.pdf I am ready with the updated patch, How should I release it the community? 1. new patch with review feedback (with same name) the current accepted practice is for you to: - update the patch with all the comments - add a v2 to the subject (so it'd be [PATCH v2] Macronix .) - in the comments section of the formatted patch (after the --- marker and above the diffstat), add notes about what changed in the updated patch - send it with the reply to header set to the last relevant message in the patches' thread I will do the needful accordingly 2. Delta on the top of previous patch no dont ever do this :) Thanks Stored in my mind Regards.. Prafulla . . -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] Blackfin: spi: make cs deassert function deterministic
Dear Mike Frysinger, In message 1239004434-13962-2-git-send-email-vap...@gentoo.org you wrote: ... diff --git a/drivers/spi/bfin_spi.c b/drivers/spi/bfin_spi.c index bc3394a..bc255cc 100644 --- a/drivers/spi/bfin_spi.c +++ b/drivers/spi/bfin_spi.c @@ -52,6 +52,7 @@ void spi_cs_activate(struct spi_slave *slave) (read_SPI_FLG(bss) ~((!bss-flg 8) slave-cs)) | (1 slave-cs)); + SSYNC(); Should this sync not be integral part of the write_SPI_FLG() accessor? + */ + flg = read_SPI_FLG(bss) | ((!bss-flg 8) slave-cs); + write_SPI_FLG(bss, flg); + SSYNC(); Ditto here. + debug(%s: SPI_FLG:%x\n, __func__, read_SPI_FLG(bss)); + + flg = ~(1 slave-cs); + write_SPI_FLG(bss, flg); + SSYNC(); And here. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I'd rather be led to hell than managed to heaven. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] bin_dep.sh Support
Dear Ronen Shitrit, In message 309002c0da137042828828fc53d7a9347e13537...@il-mb01.marvell.com you wrote: I'm not sure we are on the same page here, the Kirkwood has an internal bootROM which can only boot an image if this image is wrapped by a specific header. There are tons of standards for image formats, and even more commonly used formats I would not dare to call standard; but this processor has to invent yet another one? [Ronen Shitrit] I still think we are not on the same page here. This isn't another image format... Why do we need the bootrom? For example the KW doesn't have HW NAND ECC support :( But we still want to support boot from NAND and ve protected from upto 4 bit ECC. So the CPU wakes up and start running code from the bootROM (embedded ROM in the Kirkwood) this code read the NAND and verify its ECC, then according to the binary image header in the NAND it initialize the DRAM for this specific board and copy the binary image from the NAND to the DRAM and start running from there. I hope now its more clear... The do_image should take the u-boot bin and wrap it with this header. How do u suggest we will support this header generation for the U-Boot? Fix the hardware design? [Ronen Shitrit] probably won't happen... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de When anyone says `theoretically,' they really mean `not really.' - David Parnas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] Blackfin: nand: flush peripheral before polling it
On Monday 06 April 2009 04:27:10 Wolfgang Denk wrote: In message Mike Frysinger wrote: From: Graf Yang graf.y...@analog.com We need to make sure the data written to the nand flash controller makes it there before we start polling its status register. Otherwise, we may get stale data and return before the controller is actually ready. Signed-off-by: Graf Yang graf.y...@analog.com Signed-off-by: Mike Frysinger vap...@gentoo.org --- drivers/mtd/nand/bfin_nand.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/nand/bfin_nand.c b/drivers/mtd/nand/bfin_nand.c index f6a0835..f134ef1 100644 --- a/drivers/mtd/nand/bfin_nand.c +++ b/drivers/mtd/nand/bfin_nand.c @@ -98,6 +98,7 @@ static void bfin_nfc_read_buf(struct mtd_info *mtd, uint8_t *buf, int len) /* Contents do not matter */ bfin_write_NFC_DATA_RD(0x); + SSYNC(); Should such syncing not be integral part of the bfin_write_NFC_DATA_RD() aceessor? on the Blackfin processor, the ssync instruction is a barrier rather than a hard requirement (well, that isnt 100% true, but those edge cases dont apply to peripherals). since the NFC_DATA_RD MMR could be written in such a way to not need the barrier, we dont place ssync's into the MMR defines. especially because the ssync instruction flushes all buffers in the chip, not just the peripherals, so it can be pretty heavy handed. -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] bin_dep.sh Support
On Monday 06 April 2009 04:24:39 Wolfgang Denk wrote: In message Ronen Shitrit wrote: I'm not sure we are on the same page here, the Kirkwood has an internal bootROM which can only boot an image if this image is wrapped by a specific header. What a stupid (read: broken) hardware design. There are tons of standards for image formats, and even more commonly used formats I would not dare to call standard; but this processor has to invent yet another one? true there are plenty of formats out there, but there arent really ones geared towards booting a processor. the ELF format is way too bloated/complex (and yet still not flexible enough) to be usable, and that's about the closest applicable format i'm familiar with. beyond the simple processor will start execution at address , there isnt any standardization here. the Blackfin processor too has a custom format (LDR) for booting code. it's akin to the PHDRs in ELF, plus some additional flag bits to control behavior. but in our world, i wrote external utilities to manage ELF-LDR conversion and so i didnt need a dedicated script in u-boot to do that ugly conversion mojo, just a new Makefile target (u-boot.ldr). -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] bin_dep.sh Support
Dear Ronen Shitrit, In message 309002c0da137042828828fc53d7a9347e13538...@il-mb01.marvell.com you wrote: Dear Ronen Shitrit, In message 309002c0da137042828828fc53d7a9347e13537...@il-mb01.marvell.com= you wrote: I'm not sure we are on the same page here, the Kirkwood has an internal bootROM which can only boot an image if this image is wrapped by a specific header. There are tons of standards for image formats, and even more commonly used formats I would not dare to call standard; but this processor has to invent yet another one? Could you please use standard quoting rules? See http://www.netmeister.org/news/learn2quote.html Aplso, please restrict your line lengh to some 70 characters or so. Thanks. [Ronen Shitrit] I still think we are not on the same page here. This isn't another image format... But yes, it is. Why do we need the bootrom? For example the KW doesn't have HW NAND ECC support :( But we still want to support boot from NAND and ve protected from upto 4 bi t ECC. So the CPU wakes up and start running code from the bootROM (embedded ROM i n the Kirkwood) this code read the NAND and verify its ECC, then according to the binary image header in the NAND it initialize the DRAM for this spec You see? binary image header Here you say yourself that this is a binary image header, i. e. a prorpietary image format. Fix the hardware design? [Ronen Shitrit] probably won't happen... Though so. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de backups: always in season, never out of style. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] bin_dep.sh Support
On Monday 06 April 2009 05:16:02 Wolfgang Denk wrote: in message Mike wrote: the Blackfin processor too has a custom format (LDR) for booting code. it's akin to the PHDRs in ELF, plus some additional flag bits to control behavior. but in our world, i wrote external utilities to manage ELF-LDR conversion and so i didnt need a dedicated script in u-boot to do that ugly conversion mojo, just a new Makefile target (u-boot.ldr). ...which seems to be an acceptable (to both sides) compromise to me. minus support for embedding the environment into the image ... i have a patch that adds an option to tools/envcrc to export the environment as a binary blob so that it can be passed to the external utility, but you wouldnt take it because you wanted me to fix my hardware instead ;). -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] bin_dep.sh Support
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wolfgang Denk Sent: Monday, April 06, 2009 2:46 PM To: Mike Frysinger Cc: u-boot@lists.denx.de; Ronen Shitrit Subject: Re: [U-Boot] [PATCH] bin_dep.sh Support Dear Mike, in message 200904060503.18864.vap...@gentoo.org you wrote: the Blackfin processor too has a custom format (LDR) for booting code. it's akin to the PHDRs in ELF, plus some additional flag bits to control behavior. but in our world, i wrote external utilities to manage ELF-LDR conversion and so i didnt need a dedicated script in u-boot to do that ugly conversion mojo, just a new Makefile target (u-boot.ldr). ...which seems to be an acceptable (to both sides) compromise to me. I understood from the discussion so far that- 1. There are several cases where u-boot.bin does not help alone 2. in some cases there are external tools to be used for the conversion but ideally it is not possible to include each tool in a project Let's consider specific case - a board having serial console, flash, dram, a processor and supported u-boot. As a user ideally I expect u-boot.bin generated by u-boot make should go onto flash and board should work. But if this doesn't work then how should we educate the uses and address their questions whereas he might have stumped flashing wrong u-boot.bin to his board...? This is case with Kirkwood. I don't think it is ONLY processor having this boot sequence architecture, there may be several in pipeline...who knows. Kirkwood is today's need to be addressed. In my opinion objective of any boot loader is to provide flashable binary. Bin_dep.sh provides a framework inside u-boot, whether to use it or not is sole decision of board/processor specific code. So why not include it :-) Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] bin_dep.sh Support
On Monday 06 April 2009 05:38:59 Prafulla Wadaskar wrote: As a user ideally I expect u-boot.bin generated by u-boot make should go onto flash and board should work. i disagree. u-boot.bin should be the exact flat binary of converting from the u-boot ELF file using objdump. But if this doesn't work then how should we educate the uses and address their questions whereas he might have stumped flashing wrong u-boot.bin to his board...? yes. we havent had a problem in the Blackfin world with educating people. if the bootrom is used, then they have to use u-boot.ldr. if they're using an older Blackfin part and the one bootmode that supports direct execution (the part starts running at a hardcoded address), then and only then can they use u-boot.bin. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Uboot booting RTOS
Hi All, I am trying to boot a RTOS from uboot. I have the uboot flashed in NAND Flash. When i power on the board(OMAP3530 based from Mistral) uboot prompt comes up. Now how do i boot an RTOS which is also residing in NAND Flash at different offset.? Can i acheive this without changing the source code of current Uboot. ? ie Can i acheive this by setting certain environment variables? The format of RTOS which i am trying to port is not similar to Linux. It is Just an executable(OS and application compiled and built together to form an executable). I am newbie to uboot. Please help me on this Thanks, Rahanesh The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Best place for vendor drivers
Dear Jens Scharsig, In message grchq0$5v...@ger.gmane.org you wrote: Where is the best place to store this device driver? 1. uboot-root/device/video 2. uboot-root/board/[vendor]/[name for common dir] drivers/video/ Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Worlds are conquered, galaxies destroyed -- but a woman is always a woman. -- Kirk, Conscience of the King, stardate unknown ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Macroni ha ha ha ha ha
Sorry
Pls ignore this email...
Regards..
Prafulla . .
-Original Message-
From: Prafulla Wadaskar [mailto:prafu...@marvell.com]
Sent: Monday, April 06, 2009 9:23 PM
To: u-boot@lists.denx.de
Cc: Ronen Shitrit; Prafulla Wadaskar
Subject: [PATCH v2] Macroni ha ha ha ha ha
From: prafulla_wadaskar prafu...@marvell.com
Added macronix SF driver for MTD framework MX25L12805D is
supported and tested
TBD: sector erase implementation, other deivces support
Signed-off-by: prafulla_wadaskar prafu...@marvell.com
Reviewed by: Mike Frysinger vap...@gentoo.org Tested by:
prafulla_wadaskar prafu...@marvell.com
Signed-off-by: prafulla_wadaskar prafu...@marvell.com
---
drivers/mtd/spi/Makefile|1 +
drivers/mtd/spi/macronix.c | 312
+++
drivers/mtd/spi/spi_flash.c |5 +
3 files changed, 318 insertions(+), 0 deletions(-) create
mode 100644 drivers/mtd/spi/macronix.c
diff --git a/drivers/mtd/spi/Makefile
b/drivers/mtd/spi/Makefile index 3d4f892..2332249 100644
--- a/drivers/mtd/spi/Makefile
+++ b/drivers/mtd/spi/Makefile
@@ -27,6 +27,7 @@ LIB := $(obj)libspi_flash.a
COBJS-$(CONFIG_SPI_FLASH)+= spi_flash.o
COBJS-$(CONFIG_SPI_FLASH_ATMEL) += atmel.o
+COBJS-$(CONFIG_SPI_FLASH_MACRONIX) += macronix.o
COBJS-$(CONFIG_SPI_FLASH_STMICRO)+= stmicro.o
COBJS:= $(COBJS-y)
diff --git a/drivers/mtd/spi/macronix.c
b/drivers/mtd/spi/macronix.c new file mode 100644 index
000..c98d0e4
--- /dev/null
+++ b/drivers/mtd/spi/macronix.c
@@ -0,0 +1,312 @@
+/*
+ * Copyright 2009(C) Marvell International Ltd. and its affiliates
+ * Prafulla Wadaskar prafu...@marvell.com
+ *
+ * Based on drivers/mtd/spi/stmicro.c
+ *
+ * Copyright 2008, Network Appliance Inc.
+ * Jason McMullan mcmul...@netapp.com
+ *
+ * Copyright (C) 2004-2007 Freescale Semiconductor, Inc.
+ * TsiChung Liew (tsi-chung.l...@freescale.com)
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include common.h
+#include malloc.h
+#include spi_flash.h
+
+#include spi_flash_internal.h
+
+/* MX25xx-specific commands */
+#define CMD_MX25XX_WREN 0x06/* Write Enable */
+#define CMD_MX25XX_WRDI 0x04/* Write Disable */
+#define CMD_MX25XX_RDSR 0x05/* Read Status
Register */
+#define CMD_MX25XX_WRSR 0x01/* Write Status
Register */
+#define CMD_MX25XX_READ 0x03/* Read Data Bytes */
+#define CMD_MX25XX_FAST_READ 0x0b/* Read Data Bytes at
Higher Speed */
+#define CMD_MX25XX_PP0x02/* Page Program */
+#define CMD_MX25XX_SE0x20/* Sector Erase */
+#define CMD_MX25XX_BE0xD8/* Block Erase */
+#define CMD_MX25XX_CE0xc7/* Chip Erase */
+#define CMD_MX25XX_DP0xb9/* Deep Power-down */
+#define CMD_MX25XX_RES 0xab/* Release from
DP, and Read Signature */
+
+#define MXIC_ID_MX2516 0x15
+#define MXIC_ID_MX2520 0x12
+#define MXIC_ID_MX2532 0x16
+#define MXIC_ID_MX2540 0x13
+#define MXIC_ID_MX2564 0x17
+#define MXIC_ID_MX2580 0x14
+#define MXIC_ID_MX25128 0x18
+
+#define MACRONIX_SR_WIP (1 0)/*
Write-in-Progress */
+
+struct macronix_spi_flash_params {
+ u8 idcode1;
+ u16 page_size;
+ u16 pages_per_sector;
+ u16 sectors_per_block;
+ u16 nr_blocks;
+ const char *name;
+};
+
+struct macronix_spi_flash {
+ struct spi_flash flash;
+ const struct macronix_spi_flash_params *params; };
+
+static inline struct macronix_spi_flash
*to_macronix_spi_flash(struct spi_flash
+ *flash)
+{
+ return container_of(flash, struct macronix_spi_flash, flash); }
+
+static const struct macronix_spi_flash_params
macronix_spi_flash_table[] = {
+ {
+ .idcode1 = MXIC_ID_MX25128,
+ .page_size = 256,
+ .pages_per_sector = 16,
+ .sectors_per_block = 16,
+
[U-Boot] [PATCH] Macronix MX25xx MTD SPI flash driver
From: prafulla_wadaskar prafu...@marvell.com
Added macronix SF driver for MTD framework
MX25L12805D is supported and tested
TBD: sector erase implementation, other deivces support
Change log:
v2: typos corrected, MX25PXX renamed as MX25XX,
spi_flash struct declared as first member,
RDSR command limited to 8bit transfer and cosmetic fixes
Signed-off-by: prafulla_wadaskar prafu...@marvell.com
Reviewed by: Mike Frysinger vap...@gentoo.org
Tested by: prafulla_wadaskar prafu...@marvell.com
Signed-off-by: prafulla_wadaskar prafu...@marvell.com
---
drivers/mtd/spi/Makefile|1 +
drivers/mtd/spi/macronix.c | 312 +++
drivers/mtd/spi/spi_flash.c |5 +
3 files changed, 318 insertions(+), 0 deletions(-)
create mode 100644 drivers/mtd/spi/macronix.c
diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
index 3d4f892..2332249 100644
--- a/drivers/mtd/spi/Makefile
+++ b/drivers/mtd/spi/Makefile
@@ -27,6 +27,7 @@ LIB := $(obj)libspi_flash.a
COBJS-$(CONFIG_SPI_FLASH) += spi_flash.o
COBJS-$(CONFIG_SPI_FLASH_ATMEL)+= atmel.o
+COBJS-$(CONFIG_SPI_FLASH_MACRONIX) += macronix.o
COBJS-$(CONFIG_SPI_FLASH_STMICRO) += stmicro.o
COBJS := $(COBJS-y)
diff --git a/drivers/mtd/spi/macronix.c b/drivers/mtd/spi/macronix.c
new file mode 100644
index 000..c98d0e4
--- /dev/null
+++ b/drivers/mtd/spi/macronix.c
@@ -0,0 +1,312 @@
+/*
+ * Copyright 2009(C) Marvell International Ltd. and its affiliates
+ * Prafulla Wadaskar prafu...@marvell.com
+ *
+ * Based on drivers/mtd/spi/stmicro.c
+ *
+ * Copyright 2008, Network Appliance Inc.
+ * Jason McMullan mcmul...@netapp.com
+ *
+ * Copyright (C) 2004-2007 Freescale Semiconductor, Inc.
+ * TsiChung Liew (tsi-chung.l...@freescale.com)
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include common.h
+#include malloc.h
+#include spi_flash.h
+
+#include spi_flash_internal.h
+
+/* MX25xx-specific commands */
+#define CMD_MX25XX_WREN0x06/* Write Enable */
+#define CMD_MX25XX_WRDI0x04/* Write Disable */
+#define CMD_MX25XX_RDSR0x05/* Read Status Register */
+#define CMD_MX25XX_WRSR0x01/* Write Status Register */
+#define CMD_MX25XX_READ0x03/* Read Data Bytes */
+#define CMD_MX25XX_FAST_READ 0x0b/* Read Data Bytes at Higher Speed */
+#define CMD_MX25XX_PP 0x02/* Page Program */
+#define CMD_MX25XX_SE 0x20/* Sector Erase */
+#define CMD_MX25XX_BE 0xD8/* Block Erase */
+#define CMD_MX25XX_CE 0xc7/* Chip Erase */
+#define CMD_MX25XX_DP 0xb9/* Deep Power-down */
+#define CMD_MX25XX_RES 0xab/* Release from DP, and Read Signature
*/
+
+#define MXIC_ID_MX2516 0x15
+#define MXIC_ID_MX2520 0x12
+#define MXIC_ID_MX2532 0x16
+#define MXIC_ID_MX2540 0x13
+#define MXIC_ID_MX2564 0x17
+#define MXIC_ID_MX2580 0x14
+#define MXIC_ID_MX251280x18
+
+#define MACRONIX_SR_WIP(1 0)/* Write-in-Progress */
+
+struct macronix_spi_flash_params {
+ u8 idcode1;
+ u16 page_size;
+ u16 pages_per_sector;
+ u16 sectors_per_block;
+ u16 nr_blocks;
+ const char *name;
+};
+
+struct macronix_spi_flash {
+ struct spi_flash flash;
+ const struct macronix_spi_flash_params *params;
+};
+
+static inline struct macronix_spi_flash *to_macronix_spi_flash(struct spi_flash
+*flash)
+{
+ return container_of(flash, struct macronix_spi_flash, flash);
+}
+
+static const struct macronix_spi_flash_params macronix_spi_flash_table[] = {
+ {
+ .idcode1 = MXIC_ID_MX25128,
+ .page_size = 256,
+ .pages_per_sector = 16,
+ .sectors_per_block = 16,
+ .nr_blocks = 256,
+ .name = MX25L12805D,
+ },
+};
+
+static int macronix_wait_ready(struct spi_flash *flash, unsigned long timeout)
+{
+ struct spi_slave *spi = flash-spi;
+ unsigned long timebase;
+ int ret;
+ u8 status;
+ u8 cmd =
Re: [U-Boot] [PATCH] bin_dep.sh Support
On Monday 06 April 2009 06:28:33 Wolfgang Denk wrote: In message Mike Frysinger wrote: ...which seems to be an acceptable (to both sides) compromise to me. minus support for embedding the environment into the image ... i have a patch that adds an option to tools/envcrc to export the environment as a binary blob so that it can be passed to the external utility, but you wouldnt take it because you wanted me to fix my hardware instead ;). Not true. I can see that such a tool makes sense - it can be always usefult if you want to pre-initialize the environment on boards where the environment sector(s) is not embedded with the U-Boot image itself. Just post your code :-) ok, extracting the env as a blob isnt problematic, it's the addition of ENV_IS_EMBEDDED_CUSTOM. the env is embedded in the final image that gets burned into flash, but not by u-boot. the external util takes cares of combining the u-boot ELF and the environment blob. but i guess i can split the patch into (1) add --binary to tools/envcrc and (2) add ENV_IS_EMBEDDED_CUSTOM. that way when (2) gets shot down again, at least (1) was added so it's one less thing for me to maintain out of tree. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] s3c64xx: remove unnecessary definition
CONFIG_S3C6400 is must defined at config header file That definition is unnecessary at this file Signed-off-by: Minkyu Kang mk7.k...@samsung.com --- include/s3c6400.h |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/include/s3c6400.h b/include/s3c6400.h index 87f3760..e527c08 100644 --- a/include/s3c6400.h +++ b/include/s3c6400.h @@ -31,10 +31,6 @@ #ifndef __S3C6400_H__ #define __S3C6400_H__ -#ifndef CONFIG_S3C6400 -#define CONFIG_S3C6400 1 -#endif - #define S3C64XX_UART_CHANNELS 3 #define S3C64XX_SPI_CHANNELS 2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tools/envcrc: add --binary option to export embedded env
The --binary option to envcrc can be used to export the embedded env as a
binary blob so that it can be manipulated/examined/whatever externally.
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
tools/envcrc.c | 45 +
1 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/tools/envcrc.c b/tools/envcrc.c
index 4334cdf..ac24967 100644
--- a/tools/envcrc.c
+++ b/tools/envcrc.c
@@ -24,6 +24,7 @@
#include stdio.h
#include stdint.h
#include stdlib.h
+#include string.h
#include unistd.h
#ifndef __ASSEMBLY__
@@ -77,19 +78,55 @@ extern unsigned char environment;
int main (int argc, char **argv)
{
#ifdef ENV_IS_EMBEDDED
+ unsigned char pad = 0x00;
uint32_t crc;
unsigned char *envptr = environment,
*dataptr = envptr + ENV_HEADER_SIZE;
unsigned int datasize = ENV_SIZE;
+ unsigned int eoe;
+
+ if (argv[1] !strncmp(argv[1], --binary=, 9)) {
+ int ipad;
+ sscanf(argv[1] + 9, %i, ipad);
+ pad = ipad;
+ }
+
+ if (pad) {
+ /* find the end of env */
+ for (eoe = 0; eoe datasize - 1; ++eoe)
+ if (!dataptr[eoe] !dataptr[eoe+1]) {
+ eoe += 2;
+ break;
+ }
+ if (eoe datasize - 1)
+ memset(dataptr + eoe, pad, datasize - eoe);
+ }
crc = crc32 (0, dataptr, datasize);
/* Check if verbose mode is activated passing a parameter to the
program */
if (argc 1) {
- printf (CRC32 from offset %08X to %08X of environment =
%08X\n,
- (unsigned int) (dataptr - envptr),
- (unsigned int) (dataptr - envptr) + datasize,
- crc);
+ if (!strncmp(argv[1], --binary, 8)) {
+ int le = (argc 2 ? !strcmp(argv[2], le) : 1);
+ size_t i, start, end, step;
+ if (le) {
+ start = 0;
+ end = ENV_HEADER_SIZE;
+ step = 1;
+ } else {
+ start = ENV_HEADER_SIZE - 1;
+ end = -1;
+ step = -1;
+ }
+ for (i = start; i != end; i += step)
+ printf(%c, (crc (0xFF (i * 8))) (i *
8));
+ fwrite(dataptr, 1, datasize, stdout);
+ } else {
+ printf(CRC32 from offset %08X to %08X of environment =
%08X\n,
+ (unsigned int) (dataptr - envptr),
+ (unsigned int) (dataptr - envptr) + datasize,
+ crc);
+ }
} else {
printf (0x%08X\n, crc);
}
--
1.6.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Macroni ha ha ha ha ha
Dear Prafulla Wadaskar, In message 1239033171-26122-1-git-send-email-prafu...@marvell.com you wrote: From: prafulla_wadaskar prafu...@marvell.com Added macronix SF driver for MTD framework MX25L12805D is supported and tested TBD: sector erase implementation, other deivces support Signed-off-by: prafulla_wadaskar prafu...@marvell.com Reviewed by: Mike Frysinger vap...@gentoo.org Tested by: prafulla_wadaskar prafu...@marvell.com Do you think a commit messsage Macroni ha ha ha ha ha is adequate? This is not funny. You are only wasting our time. Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The two most common things in the universe are hydrogen and stupi- dity. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Macroni ha ha ha ha ha
I already expressed my apology for the same.. Once again I am very sorry for the same. Clearly my intention was not to waste your time. It was an accident I will take care not to happen such things ahead... Hope you will understand me Regards.. Prafulla . . -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Monday, April 06, 2009 4:32 PM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; Ronen Shitrit Subject: Re: [U-Boot] [PATCH v2] Macroni ha ha ha ha ha Dear Prafulla Wadaskar, In message 1239033171-26122-1-git-send-email-prafu...@marvell.com you wrote: From: prafulla_wadaskar prafu...@marvell.com Added macronix SF driver for MTD framework MX25L12805D is supported and tested TBD: sector erase implementation, other deivces support Signed-off-by: prafulla_wadaskar prafu...@marvell.com Reviewed by: Mike Frysinger vap...@gentoo.org Tested by: prafulla_wadaskar prafu...@marvell.com Do you think a commit messsage Macroni ha ha ha ha ha is adequate? This is not funny. You are only wasting our time. Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The two most common things in the universe are hydrogen and stupi- dity. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Macronix MX25xx MTD SPI flash driver
On Monday 06 April 2009 11:54:43 Prafulla Wadaskar wrote:
--- a/drivers/mtd/spi/Makefile
+++ b/drivers/mtd/spi/Makefile
@@ -27,6 +27,7 @@ LIB := $(obj)libspi_flash.a
COBJS-$(CONFIG_SPI_FLASH)+= spi_flash.o
COBJS-$(CONFIG_SPI_FLASH_ATMEL) += atmel.o
+COBJS-$(CONFIG_SPI_FLASH_MACRONIX) += macronix.o
COBJS-$(CONFIG_SPI_FLASH_STMICRO)+= stmicro.o
when submitting patches, you should be developing them against mainline, not
something older. trying to merge this patch would result in conflicts because
this file has changed here.
+static int macronix_wait_ready(struct spi_flash *flash, unsigned long
...
+ if (ret) {
+ debug(SF: Failed to send command %02x: %d\n, cmd[0], ret);
looks like you forgot to change cmd[0] to cmd
since these are trivial and i'm in a good mood, i'll go ahead and fix up the
conflicts and add them to my sf branch. but in the future please make sure to
integrate these methodologies.
-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] Macronix MX25xx MTD SPI flash driver
-Original Message- From: Mike Frysinger [mailto:vap...@gentoo.org] Sent: Monday, April 06, 2009 4:35 PM To: u-boot@lists.denx.de Cc: Prafulla Wadaskar; Ronen Shitrit Subject: Re: [U-Boot] [PATCH] Macronix MX25xx MTD SPI flash driver Change log: v2: typos corrected, MX25PXX renamed as MX25XX, spi_flash struct declared as first member, RDSR command limited to 8bit transfer and cosmetic fixes Signed-off-by: prafulla_wadaskar prafu...@marvell.com Reviewed by: Mike Frysinger vap...@gentoo.org Tested by: prafulla_wadaskar prafu...@marvell.com Signed-off-by: prafulla_wadaskar prafu...@marvell.com --- drivers/mtd/spi/Makefile|1 + the patch change log should go under that --- rather than above it. the patch change log is to make reviewers' lives easier, not to go into the actual commit message. but dont worry about sending another patch, i'll just fix it up when i merge it. -mike Okay Mike, Thanks for your understanding. I will keep quiet on this thread waiting this patch to get mainlined. Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Macronix MX25xx MTD SPI flash driver
On Monday 06 April 2009 11:54:43 Prafulla Wadaskar wrote: From: prafulla_wadaskar prafu...@marvell.com Added macronix SF driver for MTD framework MX25L12805D is supported and tested TBD: sector erase implementation, other deivces support Change log: v2: typos corrected, MX25PXX renamed as MX25XX, spi_flash struct declared as first member, RDSR command limited to 8bit transfer and cosmetic fixes Signed-off-by: prafulla_wadaskar prafu...@marvell.com Reviewed by: Mike Frysinger vap...@gentoo.org Tested by: prafulla_wadaskar prafu...@marvell.com Signed-off-by: prafulla_wadaskar prafu...@marvell.com also i noticed these tags ... issues: - duplicate Signed-off-by tags - tag should have your proper name (so Prafulla Wadaskar) - tags are delimited by dashes, not spaces (so Reviewed-by:) - Tested-by is pretty much implied by Signed-off-by, so you dont need that if the latter is present ... but that isnt a hard rule, and really only applies to the author of the patch rather than other people who have helped out. i bet you've just misconfigured your GIT_AUTHOR_* vars or ~/.gitconfig (or however you're setting your name) so that it reads prafulla_wadaskar ... -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] Gbe Controller driver support for kirkwood SOCs
-Original Message-
From: Ben Warren [mailto:biggerbadder...@gmail.com]
Sent: Saturday, April 04, 2009 12:44 AM
To: Prafulla Wadaskar
Cc: u-boot@lists.denx.de; Ronen Shitrit
Subject: Re: [U-Boot] [PATCH] Gbe Controller driver support
for kirkwood SOCs
Prafulla Wadaskar wrote:
From: prafulla_wadaskar prafu...@marvell.com
Contributors:
Yotam Admon yo...@marvell.com
Michael Blostein michae...@marvell.com
Signed-off-by: prafulla_wadaskar prafu...@marvell.com
Reviewed by:
Ronen Shitrit rshit...@marvell.com
---
snip
diff --git a/net/eth.c b/net/eth.c
index 4bbf84b..77fa8a5 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -73,6 +73,7 @@ int board_eth_init(bd_t *bis) __attribute((weak,
alias(__def_eth_init)));
extern int mv6436x_eth_initialize(bd_t *); extern int
mv6446x_eth_initialize(bd_t *);
+extern int kirkwood_egiga_initialize(bd_t*);
#ifdef CONFIG_API
extern void (*push_packet)(volatile void *, int); @@
-205,6 +206,9 @@
int eth_initialize(bd_t *bis) #if defined(CONFIG_DB64460) ||
defined(CONFIG_P3Mx)
mv6446x_eth_initialize(bis);
#endif
+#ifdef CONFIG_KIRKWOOD_EGIGA
+ kirkwood_egiga_initialize(bis); #endif
if (!eth_devices) {
puts (No ethernet found.\n);
show_boot_progress (-64);
I believe Mike mentioned this already, but you shouldn't be
initializing your drivers here. You'll notice that this area
of code is much smaller than it used to be, and the only
drivers left are Marvell ones. I started cleaning them up,
but the work was huge and lacking hardware I was nervous
about breaking things. IIRC, the MV6436X and MV6446X drivers
duplicate code 99%.
Hi Ben
Neither I have all other hardware with me.
While creating this driver I had this question in my mind
But at safer side I decided not to broke other things...
It will be my pleasure to co-operate to sort this out..
Regards..
Prafulla ..
regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Macroni ha ha ha ha ha
From: prafulla_wadaskar prafu...@marvell.com
Added macronix SF driver for MTD framework
MX25L12805D is supported and tested
TBD: sector erase implementation, other deivces support
Signed-off-by: prafulla_wadaskar prafu...@marvell.com
Reviewed by: Mike Frysinger vap...@gentoo.org
Tested by: prafulla_wadaskar prafu...@marvell.com
Signed-off-by: prafulla_wadaskar prafu...@marvell.com
---
drivers/mtd/spi/Makefile|1 +
drivers/mtd/spi/macronix.c | 312 +++
drivers/mtd/spi/spi_flash.c |5 +
3 files changed, 318 insertions(+), 0 deletions(-)
create mode 100644 drivers/mtd/spi/macronix.c
diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
index 3d4f892..2332249 100644
--- a/drivers/mtd/spi/Makefile
+++ b/drivers/mtd/spi/Makefile
@@ -27,6 +27,7 @@ LIB := $(obj)libspi_flash.a
COBJS-$(CONFIG_SPI_FLASH) += spi_flash.o
COBJS-$(CONFIG_SPI_FLASH_ATMEL)+= atmel.o
+COBJS-$(CONFIG_SPI_FLASH_MACRONIX) += macronix.o
COBJS-$(CONFIG_SPI_FLASH_STMICRO) += stmicro.o
COBJS := $(COBJS-y)
diff --git a/drivers/mtd/spi/macronix.c b/drivers/mtd/spi/macronix.c
new file mode 100644
index 000..c98d0e4
--- /dev/null
+++ b/drivers/mtd/spi/macronix.c
@@ -0,0 +1,312 @@
+/*
+ * Copyright 2009(C) Marvell International Ltd. and its affiliates
+ * Prafulla Wadaskar prafu...@marvell.com
+ *
+ * Based on drivers/mtd/spi/stmicro.c
+ *
+ * Copyright 2008, Network Appliance Inc.
+ * Jason McMullan mcmul...@netapp.com
+ *
+ * Copyright (C) 2004-2007 Freescale Semiconductor, Inc.
+ * TsiChung Liew (tsi-chung.l...@freescale.com)
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include common.h
+#include malloc.h
+#include spi_flash.h
+
+#include spi_flash_internal.h
+
+/* MX25xx-specific commands */
+#define CMD_MX25XX_WREN0x06/* Write Enable */
+#define CMD_MX25XX_WRDI0x04/* Write Disable */
+#define CMD_MX25XX_RDSR0x05/* Read Status Register */
+#define CMD_MX25XX_WRSR0x01/* Write Status Register */
+#define CMD_MX25XX_READ0x03/* Read Data Bytes */
+#define CMD_MX25XX_FAST_READ 0x0b/* Read Data Bytes at Higher Speed */
+#define CMD_MX25XX_PP 0x02/* Page Program */
+#define CMD_MX25XX_SE 0x20/* Sector Erase */
+#define CMD_MX25XX_BE 0xD8/* Block Erase */
+#define CMD_MX25XX_CE 0xc7/* Chip Erase */
+#define CMD_MX25XX_DP 0xb9/* Deep Power-down */
+#define CMD_MX25XX_RES 0xab/* Release from DP, and Read Signature
*/
+
+#define MXIC_ID_MX2516 0x15
+#define MXIC_ID_MX2520 0x12
+#define MXIC_ID_MX2532 0x16
+#define MXIC_ID_MX2540 0x13
+#define MXIC_ID_MX2564 0x17
+#define MXIC_ID_MX2580 0x14
+#define MXIC_ID_MX251280x18
+
+#define MACRONIX_SR_WIP(1 0)/* Write-in-Progress */
+
+struct macronix_spi_flash_params {
+ u8 idcode1;
+ u16 page_size;
+ u16 pages_per_sector;
+ u16 sectors_per_block;
+ u16 nr_blocks;
+ const char *name;
+};
+
+struct macronix_spi_flash {
+ struct spi_flash flash;
+ const struct macronix_spi_flash_params *params;
+};
+
+static inline struct macronix_spi_flash *to_macronix_spi_flash(struct spi_flash
+*flash)
+{
+ return container_of(flash, struct macronix_spi_flash, flash);
+}
+
+static const struct macronix_spi_flash_params macronix_spi_flash_table[] = {
+ {
+ .idcode1 = MXIC_ID_MX25128,
+ .page_size = 256,
+ .pages_per_sector = 16,
+ .sectors_per_block = 16,
+ .nr_blocks = 256,
+ .name = MX25L12805D,
+ },
+};
+
+static int macronix_wait_ready(struct spi_flash *flash, unsigned long timeout)
+{
+ struct spi_slave *spi = flash-spi;
+ unsigned long timebase;
+ int ret;
+ u8 status;
+ u8 cmd = CMD_MX25XX_RDSR;
+
+ ret = spi_xfer(spi, 8, cmd, NULL, SPI_XFER_BEGIN);
+ if (ret) {
+ debug(SF: Failed to send command %02x: %d\n, cmd[0], ret);
+
Re: [U-Boot] [PATCH] bin_dep.sh Support
Dear Mike, in message 200904060503.18864.vap...@gentoo.org you wrote: the Blackfin processor too has a custom format (LDR) for booting code. it's akin to the PHDRs in ELF, plus some additional flag bits to control behavior. but in our world, i wrote external utilities to manage ELF-LDR conversion and so i didnt need a dedicated script in u-boot to do that ugly conversion mojo, just a new Makefile target (u-boot.ldr). ...which seems to be an acceptable (to both sides) compromise to me. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de No matter where you go, there you are... - Buckaroo Banzai ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] bin_dep.sh Support
Dear Prafulla Wadaskar, In message 73173d32e9439e4abb5151606c3e19e250840...@sc-vexch1.marvell.com you wrote: ...which seems to be an acceptable (to both sides) compromise to me. I understood from the discussion so far that- 1. There are several cases where u-boot.bin does not help alone 2. in some cases there are external tools to be used for the conversion but ideally it is not possible to include each tool in a project The U-Boot source tree includes the source code for the U-Boot boot loader. We do not attempt to include source code for all additional tools that may be needed to build a working U-Boot image - we don;t include GCC source code, nor binutils, nor any other tools that are not specific to U-Boot. As a user ideally I expect u-boot.bin generated by u-boot make should go onto flash and board should work. Not really. u-boot.bin is supposed to be a raw binary image; this may be directly executable on most processors, but depending on where and how it is stored additional provisions may be necessary. Such tools are out of the scope of the U-Boot project. But if this doesn't work then how should we educate the uses and address their questions whereas he might have stumped flashing wrong u-boot.bin to his board...? By providing adequate documentation? You invent a processor with special requirements, so it seems only natural to me that you educate the users of your processor about the requirements. I don't think it is ONLY processor having this boot sequence architecture, there may be several in pipeline...who knows. Try and talk to your hardware design team about the problems such a complicated design is causing on the software side... Bin_dep.sh provides a framework inside u-boot, whether to use it or not is sole decision of board/processor specific code. So why not include it :-) Because we do not attempt to include all possible code for any proprietary tool that may be needed to implement all the fancy stuff that might be useful for someone. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Given a choice between two theories, take the one which is funnier. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Macronix MX25xx MTD SPI flash driver
Hi Mike
I missed subject info (i.e. PATCH v2) is this a problem? Shall I send it again?
Regards..
Prafulla . .
-Original Message-
From: Prafulla Wadaskar [mailto:prafu...@marvell.com]
Sent: Monday, April 06, 2009 9:25 PM
To: u-boot@lists.denx.de
Cc: Ronen Shitrit; Prafulla Wadaskar
Subject: [PATCH] Macronix MX25xx MTD SPI flash driver
From: prafulla_wadaskar prafu...@marvell.com
Added macronix SF driver for MTD framework MX25L12805D is
supported and tested
TBD: sector erase implementation, other deivces support
Change log:
v2: typos corrected, MX25PXX renamed as MX25XX, spi_flash
struct declared as first member, RDSR command limited to 8bit
transfer and cosmetic fixes
Signed-off-by: prafulla_wadaskar prafu...@marvell.com
Reviewed by: Mike Frysinger vap...@gentoo.org Tested by:
prafulla_wadaskar prafu...@marvell.com
Signed-off-by: prafulla_wadaskar prafu...@marvell.com
---
drivers/mtd/spi/Makefile|1 +
drivers/mtd/spi/macronix.c | 312
+++
drivers/mtd/spi/spi_flash.c |5 +
3 files changed, 318 insertions(+), 0 deletions(-) create
mode 100644 drivers/mtd/spi/macronix.c
diff --git a/drivers/mtd/spi/Makefile
b/drivers/mtd/spi/Makefile index 3d4f892..2332249 100644
--- a/drivers/mtd/spi/Makefile
+++ b/drivers/mtd/spi/Makefile
@@ -27,6 +27,7 @@ LIB := $(obj)libspi_flash.a
COBJS-$(CONFIG_SPI_FLASH)+= spi_flash.o
COBJS-$(CONFIG_SPI_FLASH_ATMEL) += atmel.o
+COBJS-$(CONFIG_SPI_FLASH_MACRONIX) += macronix.o
COBJS-$(CONFIG_SPI_FLASH_STMICRO)+= stmicro.o
COBJS:= $(COBJS-y)
diff --git a/drivers/mtd/spi/macronix.c
b/drivers/mtd/spi/macronix.c new file mode 100644 index
000..c98d0e4
--- /dev/null
+++ b/drivers/mtd/spi/macronix.c
@@ -0,0 +1,312 @@
+/*
+ * Copyright 2009(C) Marvell International Ltd. and its affiliates
+ * Prafulla Wadaskar prafu...@marvell.com
+ *
+ * Based on drivers/mtd/spi/stmicro.c
+ *
+ * Copyright 2008, Network Appliance Inc.
+ * Jason McMullan mcmul...@netapp.com
+ *
+ * Copyright (C) 2004-2007 Freescale Semiconductor, Inc.
+ * TsiChung Liew (tsi-chung.l...@freescale.com)
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include common.h
+#include malloc.h
+#include spi_flash.h
+
+#include spi_flash_internal.h
+
+/* MX25xx-specific commands */
+#define CMD_MX25XX_WREN 0x06/* Write Enable */
+#define CMD_MX25XX_WRDI 0x04/* Write Disable */
+#define CMD_MX25XX_RDSR 0x05/* Read Status
Register */
+#define CMD_MX25XX_WRSR 0x01/* Write Status
Register */
+#define CMD_MX25XX_READ 0x03/* Read Data Bytes */
+#define CMD_MX25XX_FAST_READ 0x0b/* Read Data Bytes at
Higher Speed */
+#define CMD_MX25XX_PP0x02/* Page Program */
+#define CMD_MX25XX_SE0x20/* Sector Erase */
+#define CMD_MX25XX_BE0xD8/* Block Erase */
+#define CMD_MX25XX_CE0xc7/* Chip Erase */
+#define CMD_MX25XX_DP0xb9/* Deep Power-down */
+#define CMD_MX25XX_RES 0xab/* Release from
DP, and Read Signature */
+
+#define MXIC_ID_MX2516 0x15
+#define MXIC_ID_MX2520 0x12
+#define MXIC_ID_MX2532 0x16
+#define MXIC_ID_MX2540 0x13
+#define MXIC_ID_MX2564 0x17
+#define MXIC_ID_MX2580 0x14
+#define MXIC_ID_MX25128 0x18
+
+#define MACRONIX_SR_WIP (1 0)/*
Write-in-Progress */
+
+struct macronix_spi_flash_params {
+ u8 idcode1;
+ u16 page_size;
+ u16 pages_per_sector;
+ u16 sectors_per_block;
+ u16 nr_blocks;
+ const char *name;
+};
+
+struct macronix_spi_flash {
+ struct spi_flash flash;
+ const struct macronix_spi_flash_params *params; };
+
+static inline struct macronix_spi_flash
*to_macronix_spi_flash(struct spi_flash
+ *flash)
+{
+ return container_of(flash, struct macronix_spi_flash, flash); }
+
+static const struct
Re: [U-Boot] [PATCH] bin_dep.sh Support
-Original Message- From: Detlev Zundel [mailto:d...@denx.de] Sent: Monday, April 06, 2009 3:10 PM To: Wolfgang Denk Cc: Prafulla Wadaskar; u-boot@lists.denx.de; Ronen Shitrit Subject: Re: [U-Boot] [PATCH] bin_dep.sh Support Hi, Dear Prafulla Wadaskar, In message 1238759359-6544-2-git-send-email-prafu...@marvell.com you wrote: From: prafulla_wadaskar prafu...@marvell.com In some cases the u-boot.bin need to be processed further to create bootable u-boot binary from boot device This processing may be cpu,soc and/or board spcific bin_dep.sh provides a mechanism to execute bin_dep.sh if present in above platform specific folders Signed-off-by: prafulla_wadaskar prafu...@marvell.com --- Makefile |2 + tools/bin_dep.sh | 79 ++ 2 files changed, 81 insertions(+), 0 deletions(-) create mode 100755 tools/bin_dep.sh I don't see use cases for this. This should probably remain out of tree. If the wrapping is needed to get a working U-Boot image for this specific board, I'll vote to add the code. Dear Detlev Thanks for your vote. Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Best place for vendor drivers
Hello maintainers, Dear Wolfgang Denk, currently we have 3 Boards (one already in U-boot Tree), witch use the same vendor-specific video hardware. This video device is not a classic framebuffer or console, but supports splashimage and bmp command. Our Question: Where is the best place to store this device driver? 1. uboot-root/device/video 2. uboot-root/board/[vendor]/[name for common dir] best regards Jens Scharsig ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] at91sam9/at91cap: fix CONFIG_SYS_HZ to 1000
Jean-Christophe PLAGNIOL-VILLARD a écrit : The timer has been rewrote with a precision at ~0,18% works fine on an 9260 and solves TFTP timeout problem. Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] bin_dep.sh Support
Dear Mike Frysinger, In message 200904060533.47911.vap...@gentoo.org you wrote: ...which seems to be an acceptable (to both sides) compromise to me. minus support for embedding the environment into the image ... i have a patch that adds an option to tools/envcrc to export the environment as a binary blob so that it can be passed to the external utility, but you wouldnt take it because you wanted me to fix my hardware instead ;). Not true. I can see that such a tool makes sense - it can be always usefult if you want to pre-initialize the environment on boards where the environment sector(s) is not embedded with the U-Boot image itself. Just post your code :-) Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Athens built the Acropolis. Corinth was a commercial city, interested in purely materialistic things. Today we admire Athens, visit it, preserve the old temples, yet we hardly ever set foot in Corinth. - Dr. Harold Urey, Nobel Laureate in chemistry ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Macronix MX25xx MTD SPI flash driver
On Monday 06 April 2009 06:46:29 Prafulla Wadaskar wrote: I missed subject info (i.e. PATCH v2) is this a problem? Shall I send it again? dont worry about it. the [PATCH ...] contents of the summary are dropped when merging into git. however, there is one other thing: Subject: [PATCH] Macronix MX25xx MTD SPI flash driver From: prafulla_wadaskar prafu...@marvell.com Added macronix SF driver for MTD framework MX25L12805D is supported and tested TBD: sector erase implementation, other deivces support Change log: v2: typos corrected, MX25PXX renamed as MX25XX, spi_flash struct declared as first member, RDSR command limited to 8bit transfer and cosmetic fixes Signed-off-by: prafulla_wadaskar prafu...@marvell.com Reviewed by: Mike Frysinger vap...@gentoo.org Tested by: prafulla_wadaskar prafu...@marvell.com Signed-off-by: prafulla_wadaskar prafu...@marvell.com --- drivers/mtd/spi/Makefile|1 + the patch change log should go under that --- rather than above it. the patch change log is to make reviewers' lives easier, not to go into the actual commit message. but dont worry about sending another patch, i'll just fix it up when i merge 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 v3] Add imls utility command
Hi Wolfgang,
2009/4/5 Wolfgang Denk w...@denx.de:
Dear Marco,
In message 49d8e8f3.4010...@gmail.com you wrote:
+ for (j = sectoroffset; j sectorcount; ++j) {
i. e. add
if (lseek(fd, j*sectorsize, SEEK_SET) != j*sectorsize) {
error handling goes here
}
Mmm...I don't well understand why. For example if a sector is 128k and
the header size is for example of 100 byte, after the read below, at the
beginning of the cycle, the offset will be 100 byte (we say that
sectoroffset is 0) and for example we don't find any image. At next
cycle if I do an lseek of 1*128K, I'll get (1*128K)+100 byte as offset,
at next (2*128k) + 200 byte and so on. To do this I should do an lseek
after the read as lseek(fd,-readbyte,SEEK_CUR).
Please think about this again. We use a single lseek() before each
read() to position the read pointer at the next sector boundary, i.e.
where we need it. We don't care whe reit is after the read().
Oops sorry, I've read SEEK_CUR instead of SEEK_SET, ok in this way works.
...
+ len = image_get_size(hdr);
+ data = malloc(len * sizeof(char));
Come on. sizeof(char) ? You must be joking.
+ if (!data) {
+ fprintf (stderr, %s: Can't allocate memory: %s\n,
+ cmdname, strerror(errno));
+ exit(EXIT_FAILURE);
+ }
Get rid of this malloc(), too.
I can't know in this case the size of the data, to remove the malloc I
have to allocate a fixed buffer of X byte, I think in this case a malloc
is better.
No. Who claims you must read the whole image at once? Use a fixed
buffer of a convenient size (say PAGE_SIZE), and read the data
sequentially. No need to allocate zillions of megabytes of memory at
once.
Ok, I'll try to do that sequentially.
+ lseek(fd, -len, SEEK_CUR);
Why would this lseek() be needed? [And ifit ws needed, you should
check it's return value.]
It was needed to be aligned to sector boundary and set the file offset
as before to call this function (see my comment above).
Your thinking is inverted. Don't try to fix the read pointer after
each read(). Set it as needed before the read() when necessary.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A memorandum is written not to inform the reader, but to protect the
writer. -- Dean Acheson
I'll send a new patch with the modification as soon as
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] bin_dep.sh Support
Hi, Dear Prafulla Wadaskar, In message 1238759359-6544-2-git-send-email-prafu...@marvell.com you wrote: From: prafulla_wadaskar prafu...@marvell.com In some cases the u-boot.bin need to be processed further to create bootable u-boot binary from boot device This processing may be cpu,soc and/or board spcific bin_dep.sh provides a mechanism to execute bin_dep.sh if present in above platform specific folders Signed-off-by: prafulla_wadaskar prafu...@marvell.com --- Makefile |2 + tools/bin_dep.sh | 79 ++ 2 files changed, 81 insertions(+), 0 deletions(-) create mode 100755 tools/bin_dep.sh I don't see use cases for this. This should probably remain out of tree. If the wrapping is needed to get a working U-Boot image for this specific board, I'll vote to add the code. On the other hand, I wouldn't probably add this to the u-boot.bin target. A makefile should really specify what file is generated from what and generating an extra target in the u-boot.bin rule somewhat violates this rule. I'd say, add another target and the script. Hopefully we can make this as generic as possible so that other boards needing this can only plug in their script. Cheers Detlev -- I will use free software even if it is less powerful, or less reliable, because freedom is the most important thing, and that is what the Free Software movement is about. How we get freedom. -- Richard M. Stallman -- 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 2/2] net: Add Xilinx LL Temac driver
Hi Wolfgang and Ben, Dear Michal, In message 4981658c.7070...@monstr.eu you wrote: I'm really sorry for taking so long getting to this. Mostly little things: it's ok you are busy guy. I removed uninteresting part of code. I added all your reported things to u-boot-microblaze.git net branch. Thanks for pull. What exactly is the state of this today? It seems this did not hit mainline yet? Yes, this driver is not in mainline. Ben wanted to changed this driver to new network driver style. I tried to do it but I my toolchain had a problem with weak function. I see two solution. 1. Add old style driver without new net multi interface 2. Add new style driver and microblaze community just comment one line in eth.c (this line int board_eth_init(bd_t *bis) __attribute((weak, alias(__def_eth_init)));) Both solution are possible. If you agree with me, I'll send new version driver for comments. And of course the best solution is update my toolchain but there we have some problems. Thanks, Michal Best regards, Wolfgang Denk -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-Boot starting point
Hi all, This is my first post here. I am working with a board having MIPS arch. and i have a strange requirement wherein i need to initialize about 64MB of RAM with some data. Currently i am facing problem as my board supports only 64MB RAM and i need to initialize those memory before U-Boot gets loaded. So, i am wondering how this can be done? If i can know the exact location of the code wherein the U-Boot gets loaded into RAM i can place the initialization sequence before U-Boot gets into operation. Expecting your reply,Thanks in advance. -- View this message in context: http://www.nabble.com/U-Boot-starting-point-tp22912466p22912466.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] Enabling ARM DCache (and MMU setup) in U-Boot
On Tue, Mar 31, 2009 at 4:09 PM, Jean-Christophe PLAGNIOL-VILLARD wrote: if you want to use the dcache you must first correctly setup the MMU and the TLB I set-up : 1) pagetable in the SDRAM (one master pagetable, to map all 4096 pages of address space to map from the virtual to the same addresses in physical address) 2) I use client domain 3 3) set up all permissions to RW 4) attached pagetable (put info about master table address into CP15 reg) When I try to switch MMU on after all of this (in CP15 reg), u-boot blocks. I created one command to do all this init, and in the end write into CP15 reg to switch on MMU. Is this approach OK? but for some reason, u-boot blocks there, right after switching MMU on. I am sure that MMU works, because I can boot Linux on the same board, and Linux works. With JTAG I can see that pagetable is written on SDRAM on given address, so I suspect on permissions, but from each pagetable entry I have that domain and access permissions as I said (domain 3 client, RW). Do you have any idea what can be wrong and where to look? Best regards, Drasko ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Macronix MX25xx MTD SPI flash driver
Dear Prafulla Wadaskar, In message 1239033283-26144-1-git-send-email-prafu...@marvell.com you wrote: Signed-off-by: prafulla_wadaskar prafu...@marvell.com Reviewed by: Mike Frysinger vap...@gentoo.org Tested by: prafulla_wadaskar prafu...@marvell.com There are a couple of formal issues here: Please change Reviewed by: into Reviewed-by: and Tested by: into Tested-by: - no, this is not nitpicking, some automated tools rely on the correct spelling. Also, all these entries require a real name, so please change prafulla_wadaskar into Prafulla Wadaskar. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Wherever you go...There you are.- Buckaroo Banzai ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Macronix MX25xx MTD SPI flash driver
Dear Mike Frysinger, In message 200904060711.50104.vap...@gentoo.org you wrote: since these are trivial and i'm in a good mood, i'll go ahead and fix up the conflicts and add them to my sf branch. but in the future please make sure to integrate these methodologies. Please don't or undo. The Signed-off-by: entry is not OK either, and we cannot change this. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I have a theory that it's impossible to prove anything, but I can't prove it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-usb
The following changes since commit
712ac6a1a6909a58d6549fb220cc921a7e9f9979:
Wolfgang Denk (1):
Merge branch 'master' of git://git.denx.de/u-boot-arm
are available in the git repository at:
git://git.denx.de/u-boot-usb.git master
Jean-Christophe PLAGNIOL-VILLARD (1):
drivers/usb: regorganisation
Remy Bohmer (1):
Support for PXA27X UDC.
Makefile |4 +-
drivers/serial/usbtty.c|2 +-
drivers/serial/usbtty.h| 10 +-
drivers/usb/{ = gadget}/Makefile | 31 +-
drivers/usb/{usbdcore.c = gadget/core.c} |2 +-
drivers/usb/{usbdcore_ep0.c = gadget/ep0.c} |2 +-
include/usbdcore_ep0.h = drivers/usb/gadget/ep0.h |0
.../usb/{usbdcore_mpc8xx.c = gadget/mpc8xx_udc.c} |9 +-
.../{usbdcore_omap1510.c = gadget/omap1510_udc.c} |6 +-
drivers/usb/gadget/pxa27x_udc.c| 702
drivers/usb/{ = host}/Makefile| 37 +-
drivers/usb/{usb_ehci_core.h = host/ehci-core.h} |0
drivers/usb/{usb_ehci_fsl.c = host/ehci-fsl.c}|6 +-
drivers/usb/{usb_ehci_fsl.h = host/ehci-fsl.h}|0
drivers/usb/{usb_ehci_core.c = host/ehci-hcd.c} |3 +-
drivers/usb/{usb_ehci_ixp.c = host/ehci-ixp4xx.c} |5 +-
drivers/usb/{usb_ehci_pci.c = host/ehci-pci.c}|5 +-
drivers/usb/{usb_ehci_vct.c = host/ehci-vct.c}|4 +-
drivers/usb/{usb_ehci.h = host/ehci.h}|0
drivers/usb/{ = host}/isp116x-hcd.c |0
drivers/usb/{ = host}/isp116x.h |0
drivers/usb/{atmel_usb.c = host/ohci-at91.c} |0
drivers/usb/{usb_ohci.c = host/ohci-hcd.c}|3 +-
drivers/usb/{usb_ohci.h = host/ohci.h}|0
drivers/usb/{ = host}/r8a66597-hcd.c |0
drivers/usb/{ = host}/r8a66597.h |0
drivers/usb/{s3c64xx_usb.c = host/s3c64xx-hcd.c} |0
drivers/usb/{sl811_usb.c = host/sl811-hcd.c} |2 +-
drivers/usb/{ = host}/sl811.h |0
drivers/usb/musb/Makefile | 47 ++
drivers/usb/{davinci_usb.c = musb/davinci.c} |2 +-
drivers/usb/{davinci_usb.h = musb/davinci.h} |0
drivers/usb/{ = musb}/musb_core.c |0
drivers/usb/{ = musb}/musb_core.h |0
drivers/usb/{ = musb}/musb_hcd.c |0
drivers/usb/{ = musb}/musb_hcd.h |0
include/asm-arm/arch-pxa/pxa-regs.h| 296 +++--
include/{usbdcore_mpc8xx.h = usb/mpc8xx_udc.h}|0
.../{usbdcore_omap1510.h = usb/omap1510_udc.h}|0
include/usb/pxa27x_udc.h | 69 ++
include/{usbdcore.h = usbdevice.h}|0
41 files changed, 1118 insertions(+), 129 deletions(-)
copy drivers/usb/{ = gadget}/Makefile (60%)
rename drivers/usb/{usbdcore.c = gadget/core.c} (99%)
rename drivers/usb/{usbdcore_ep0.c = gadget/ep0.c} (99%)
rename include/usbdcore_ep0.h = drivers/usb/gadget/ep0.h (100%)
rename drivers/usb/{usbdcore_mpc8xx.c = gadget/mpc8xx_udc.c} (99%)
rename drivers/usb/{usbdcore_omap1510.c = gadget/omap1510_udc.c} (99%)
create mode 100644 drivers/usb/gadget/pxa27x_udc.c
rename drivers/usb/{ = host}/Makefile (64%)
rename drivers/usb/{usb_ehci_core.h = host/ehci-core.h} (100%)
rename drivers/usb/{usb_ehci_fsl.c = host/ehci-fsl.c} (97%)
rename drivers/usb/{usb_ehci_fsl.h = host/ehci-fsl.h} (100%)
rename drivers/usb/{usb_ehci_core.c = host/ehci-hcd.c} (99%)
rename drivers/usb/{usb_ehci_ixp.c = host/ehci-ixp4xx.c} (96%)
rename drivers/usb/{usb_ehci_pci.c = host/ehci-pci.c} (97%)
rename drivers/usb/{usb_ehci_vct.c = host/ehci-vct.c} (96%)
rename drivers/usb/{usb_ehci.h = host/ehci.h} (100%)
rename drivers/usb/{ = host}/isp116x-hcd.c (100%)
rename drivers/usb/{ = host}/isp116x.h (100%)
rename drivers/usb/{atmel_usb.c = host/ohci-at91.c} (100%)
rename drivers/usb/{usb_ohci.c = host/ohci-hcd.c} (99%)
rename drivers/usb/{usb_ohci.h = host/ohci.h} (100%)
rename drivers/usb/{ = host}/r8a66597-hcd.c (100%)
rename drivers/usb/{ = host}/r8a66597.h (100%)
rename drivers/usb/{s3c64xx_usb.c = host/s3c64xx-hcd.c} (100%)
rename drivers/usb/{sl811_usb.c = host/sl811-hcd.c} (99%)
rename drivers/usb/{ = host}/sl811.h (100%)
create mode 100644 drivers/usb/musb/Makefile
rename drivers/usb/{davinci_usb.c = musb/davinci.c} (99%)
rename drivers/usb/{davinci_usb.h = musb/davinci.h} (100%)
rename drivers/usb/{ = musb}/musb_core.c (100%)
rename drivers/usb/{ = musb}/musb_core.h (100%)
rename drivers/usb/{ = musb}/musb_hcd.c (100%)
rename drivers/usb/{ = musb}/musb_hcd.h (100%)
rename include/{usbdcore_mpc8xx.h = usb/mpc8xx_udc.h} (100%)
rename include/{usbdcore_omap1510.h = usb/omap1510_udc.h} (100%)
create mode 100644 include/usb/pxa27x_udc.h
rename include/{usbdcore.h = usbdevice.h} (100%)
Re: [U-Boot] [PATCH v2] Support for PXA27X UDC.
Hello Vivek, 2009/3/10 Vivek Kutal vivek.ku...@azingo.com: This Patch adds Support for PXA27X UDC. Signed-off-by: Vivek Kutal vivek.ku...@azingo.com --- Resinding after doing the changes suggested by Kim. Applied to U-boot usb. Thanks. Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 3/5] Add NAND SPL entries to gitignore.
Hi
+++ b/nand_spl/.gitignore
@@ -0,0 +1,7 @@
+# NAND-SPL files
+/u-boot-spl
+/u-boot-spl-aligned.bin
+/u-boot-spl.bin
+/u-boot-spl.map
+/board/imx31_phycore/nand_boot_mx31.c
+/board/imx31_phycore/*.S
Hmm, can we create a directory for board-specific temporary files to go, so
we don't need board-specific stuff in .gitignore?
Or better, add some makefile rules so we can produce nand_spl versions of .o
files without having to symlink the source anywhere.
Sounds like a good idea. I have one solution for this now, I'll see if
there's a better one before posting a suggestion tomorrow evening.
Ok, I have an updated nand_spl/board/freescale/mx31pdk/Makefile below.
It works for both in-tree and out of tree builds. I'm not particularly
happy with the $(obj)%.o: $(SRCTREE)... lines but I couldn't make it
work otherwise. Perhaps someone has a better solution.
I know gmail will mangle at least one long line, but I'll update my
patch series later as well.
Thanks, Magnus
--- /dev/null 2009-04-06 20:44:51.328125000 +0200
+++ Makefile2009-04-06 20:43:55.68750 +0200
@@ -0,0 +1,54 @@
+CONFIG_NAND_SPL= y
+
+include $(TOPDIR)/config.mk
+include $(TOPDIR)/nand_spl/board/$(BOARDDIR)/config.mk
+
+LDSCRIPT= $(TOPDIR)/nand_spl/board/$(BOARDDIR)/u-boot.lds
+LDFLAGS= -Bstatic -T $(LDSCRIPT) -Ttext $(TEXT_BASE)
$(PLATFORM_LDFLAGS)
+AFLAGS += -DCONFIG_NAND_SPL
+CFLAGS += -DCONFIG_NAND_SPL
+
+SOBJS = start.o lowlevel_init.o
+COBJS = nand_boot_mx31.o
+
+SRCS := $(SRCTREE)/nand_spl/nand_boot_mx31.c
+SRCS += $(SRCTREE)/cpu/arm1136/start.S
+SRCS += $(SRCTREE)/board/freescale/mx31pdk/lowlevel_init.S
+OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS))
+__OBJS := $(SOBJS) $(COBJS)
+LNDIR := $(OBJTREE)/nand_spl/board/$(BOARDDIR)
+
+nandobj:= $(OBJTREE)/nand_spl/
+
+ALL= $(nandobj)u-boot-spl $(nandobj)u-boot-spl.bin
$(nandobj)u-boot-spl-aligned.bin
+
+all: $(obj).depend $(ALL)
+
+$(nandobj)u-boot-spl-aligned.bin: $(nandobj)u-boot-spl
+ $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary $ $@
+
+$(nandobj)u-boot-spl.bin: $(nandobj)u-boot-spl
+ $(OBJCOPY) ${OBJCFLAGS} -O binary $ $@
+
+$(nandobj)u-boot-spl: $(OBJS)
+ cd $(LNDIR) $(LD) $(LDFLAGS) $(__OBJS) \
+ -Map $(nandobj)u-boot-spl.map \
+ -o $(nandobj)u-boot-spl
+
+#
+
+$(obj)%.o: $(SRCTREE)/cpu/arm1136/%.S
+ $(CC) $(AFLAGS) -c -o $@ $
+
+$(obj)%.o: $(SRCTREE)/board/freescale/mx31pdk/%.S
+ $(CC) $(AFLAGS) -c -o $@ $
+
+$(obj)%.o: $(SRCTREE)/nand_spl/%.c
+ $(CC) $(CFLAGS) -c -o $@ $
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] core ticks/timer code
On Sat, Apr 04, 2009 at 11:14:09PM +0200, Wolfgang Denk wrote: Dear Scott Wood, In message 20090331213202.gb19...@ld0162-tx32.am.freescale.net you wrote: Is there any particular reason not to change the powerpc get_timer implementation to use the timebase (scaled down to ms)? I think so. There are some boards where we actually measure the system clock frequency against a known reference clock. IIRC this requires the TB to be independent, or something like that. [It's a long time since that code was written.] The existing get_timer uses the decrementer, which is not independent of the timebase. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] bin_dep.sh Support
On Mon, Apr 06, 2009 at 10:24:39AM +0200, Wolfgang Denk wrote: Dear Ronen Shitrit, In message 309002c0da137042828828fc53d7a9347e13537...@il-mb01.marvell.com you wrote: I'm not sure we are on the same page here, the Kirkwood has an internal bootROM which can only boot an image if this image is wrapped by a specific header. What a stupid (read: broken) hardware design. There are tons of standards for image formats, and even more commonly used formats I would not dare to call standard; but this processor has to invent yet another one? The same could be said about u-boot requiring its own image format (ELF and raw binary images can't be passed a device tree or bd_t, AFAICT). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] core ticks/timer code
Dear Scott, In message 20090406191242.ga4...@ld0162-tx32.am.freescale.net you wrote: Is there any particular reason not to change the powerpc get_timer implementation to use the timebase (scaled down to ms)? Side note: we already use the timebase for the implementation of udelay() and friends which are available as soon as we have a (limited) C runtime environment, i. e. long before relocation. I think so. There are some boards where we actually measure the system clock frequency against a known reference clock. IIRC this requires the TB to be independent, or something like that. [It's a long time since that code was written.] The existing get_timer uses the decrementer, which is not independent of the timebase. Yes, you are right. I should have looked up the actual implementation. Sorry, volatile memory with too few/short refresh cycles ;-) Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de For every complex problem, there is a solution that is simple, neat, and wrong. -- H. L. Mencken ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] bin_dep.sh Support
Dear Scott Wood, In message 20090406193049.gb4...@ld0162-tx32.am.freescale.net you wrote: There are tons of standards for image formats, and even more commonly used formats I would not dare to call standard; but this processor has to invent yet another one? The same could be said about u-boot requiring its own image format (ELF and raw binary images can't be passed a device tree or bd_t, AFAICT). When the U-Boot (or rather PPCBoot at that time) development was starte, there was a very important reason for not using ELF: wasting a full 64 kB for the standard ELF file header was unthinkable on most embedded devices of that time. Now, on fat systems with ample resource on one side, and on the other side with the infrastructure more or less in place to compose a bootm command from small, separate building blocks, it should be not difficult to add such a feature, too. On the other hand, ELF images are missing a few key points available in U-Boot images so I would not recommend using plain ELF for any system where reliability or just ease of use are important (which was the other part of the rationale that led to that format). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The first rule of magic is simple. Don't waste your time waving your hands and hoping when a rock or a club will do. - McCloctnik the Lucid ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] Blackfin: nand: flush peripheral before polling it
On Mon, Apr 06, 2009 at 03:53:48AM -0400, Mike Frysinger wrote: From: Graf Yang graf.y...@analog.com We need to make sure the data written to the nand flash controller makes it there before we start polling its status register. Otherwise, we may get stale data and return before the controller is actually ready. Signed-off-by: Graf Yang graf.y...@analog.com Signed-off-by: Mike Frysinger vap...@gentoo.org --- Acked-by: Scott Wood scottw...@freescale.com -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Uboot booting RTOS
On Mon, Apr 06, 2009 at 03:44:43PM +0530, rahan...@tataelxsi.co.in wrote: When i power on the board(OMAP3530 based from Mistral) uboot prompt comes up. Now how do i boot an RTOS which is also residing in NAND Flash at different offset.? Can i acheive this without changing the source code of current Uboot. ? Yes. Use nand read to copy the image into RAM, then jump to it using whatever mechanism is appropriate for your image. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Macronix MX25xx MTD SPI flash driver
On Monday 06 April 2009 14:15:23 Wolfgang Denk wrote: In message Mike Frysinger wrote: since these are trivial and i'm in a good mood, i'll go ahead and fix up the conflicts and add them to my sf branch. but in the future please make sure to integrate these methodologies. Please don't or undo. The Signed-off-by: entry is not OK either, and we cannot change this. how so ? Prafulla: could you resubmit then ? the cleaned up patch i merged is here: http://git.denx.de/?p=u-boot/u-boot- blackfin.git;a=commitdiff;h=eddc6059da8dd71cbe84522b281b15b26dd927c7 the things i fixed: - your name - duplicate tags - patch changelog in commit - missing change to spi_flash_internal.h - fixed Makefile conflicts - cmd[0] vs cmd error -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] bin_dep.sh Support
On Monday 06 April 2009 15:49:43 Wolfgang Denk wrote: In message Scott Wood wrote: There are tons of standards for image formats, and even more commonly used formats I would not dare to call standard; but this processor has to invent yet another one? The same could be said about u-boot requiring its own image format (ELF and raw binary images can't be passed a device tree or bd_t, AFAICT). When the U-Boot (or rather PPCBoot at that time) development was starte, there was a very important reason for not using ELF: wasting a full 64 kB for the standard ELF file header was unthinkable on most embedded devices of that time. Now, on fat systems with ample resource on one side, and on the other side with the infrastructure more or less in place to compose a bootm command from small, separate building blocks, it should be not difficult to add such a feature, too. On the other hand, ELF images are missing a few key points available in U-Boot images so I would not recommend using plain ELF for any system where reliability or just ease of use are important (which was the other part of the rationale that led to that format). which are the same reasons processors do not implement support for ELF as a booting source ... lets say i was to design a brand new part today with an on-chip rom that supports booting from a variety of sources (UART, SPI/I2C/NAND flashes, directly addressable NOR flashes, as a slave device to SPI/I2C, etc...), what format would you recommend that could satisfy all of these requirements ? i'm not aware of any which is why the Blackfin processor has its own stripped down LDR format. -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] rtl8169: fix cache coherency problem
Wolfgang Denk wrote: Dear Ben, In message 49a4d6bc.3010...@renesas.com Yoshihiro Shimoda wrote: Fix the problem that cannot access actual data when CPU data cache enabled. Signed-off-by: Yoshihiro Shimoda shimoda.yoshih...@renesas.com --- drivers/net/rtl8169.c | 11 ++- 1 files changed, 10 insertions(+), 1 deletions(-) I did not see any comments on this? Ditto for the other patch: http://article.gmane.org/gmane.comp.boot-loaders.u-boot/55286 Tested-by: Nobuhiro Iwamatsu iwamatsu.nobuh...@renesas.com I checked and tested these. Work file. Best regards, Nobuhiro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] inline ppc assembly on standalone applications
Hello, I need to access board cpu registers using ppc assembly language. It is possible to add inline assembly codes in standalone applications? Thanks, -- View this message in context: http://www.nabble.com/inline-ppc-assembly-on-standalone-applications-tp22922264p22922264.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] Help about a simplified bootloader.
Hi, Actually the code is based on Atmel's bootstrap. On Fri, Apr 3, 2009 at 7:57 PM, Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote: On 14:44 Fri 03 Apr , os user wrote: Hi all, I want to boot linux by a simplified bootloader. I use Atmel's ARM chip (AT91SAM9RL64EK board). Now, I can boot linux with my small program. The small program will parse the image generaed by mkimage and copy the kernel bianry from NAND flash to SDRAM, construct the tag list, disable I/D cache, disable interrupt and then jump to kernel entry point. The system can startup, but when accessing rootfile system(the rootfile system was also in the NAND chip), a lot of CRC errors were found. See below, mtd-read(0x1fb2c bytes from 0x1804d4) returned ECC error mtd-read(0x1fa38 bytes from 0x3e05c8) returned ECC error mtd-read(0x1f7dc bytes from 0x7c0824) returned ECC error jffs2_scan_inode_node(): CRC failed on node at 0x007c37a4: Read 0xd9b2bc33, calculated 0xda4805c1 and sometimes the sytem even crashed when R/W filesystem. But with the same linux kernel and rootfile system, if I use U-Boot to boot linux, everything seems OK. Can anyone tell is there any trick that's related with linux NAND driver in U-Boot? Or any suggestion to help me moving on? use U-Boot or Atmel Bootstrap Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Help about a simplified bootloader.
Sure, the Code will be GPL based. On Sat, Apr 4, 2009 at 1:51 AM, Wolfgang Denk w...@denx.de wrote: Dear os user, In message 34f262ce0904022344u6e27ad07g8263785dd36ac...@mail.gmail.com you wrote: I want to boot linux by a simplified bootloader. I use Atmel's ARM chip (AT91SAM9RL64EK board). Now, I can boot linux with my small program. The small program will parse the image generaed by mkimage ... and sometimes the sytem even crashed when R/W filesystem. But with the same linux kernel and rootfile system, if I use U-Boot to boot linux, everything seems OK. Can anyone tell is there any trick that's related with linux NAND driver in U-Boot? Or any suggestion to help me moving on? Well, you already mentioned the solution: either use U-Boot, which seems to be working fine, or fix your own program such that it performs the same intializations like U-Boot. Be careful when copying code from U-Boot - U-Boot is under GPL, and you may quickly find that you have to release your program under GPL, too. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Maintain an awareness for contribution -- to your schedule, your project, our company. - A Group of Employees ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Help about a simplified bootloader.
Hi, The data in NAND chip(linux kernel and RootFS) is the same when booting linux from U-Boot and from the simple loader. :-( On Sat, Apr 4, 2009 at 12:53 AM, Scott Wood scottw...@freescale.com wrote: On Fri, Apr 03, 2009 at 02:44:03PM +0800, os user wrote: I want to boot linux by a simplified bootloader. I use Atmel's ARM chip (AT91SAM9RL64EK board). Now, I can boot linux with my small program. The small program will parse the image generaed by mkimage and copy the kernel bianry from NAND flash to SDRAM, construct the tag list, disable I/D cache, disable interrupt and then jump to kernel entry point. The system can startup, but when accessing rootfile system(the rootfile system was also in the NAND chip), a lot of CRC errors were found. See below, mtd-read(0x1fb2c bytes from 0x1804d4) returned ECC error mtd-read(0x1fa38 bytes from 0x3e05c8) returned ECC error mtd-read(0x1f7dc bytes from 0x7c0824) returned ECC error jffs2_scan_inode_node(): CRC failed on node at 0x007c37a4: Read 0xd9b2bc33, calculated 0xda4805c1 and sometimes the sytem even crashed when R/W filesystem. But with the same linux kernel and rootfile system, if I use U-Boot to boot linux, everything seems OK. Can anyone tell is there any trick that's related with linux NAND driver in U-Boot? Or any suggestion to help me moving on? Are you using the same software to program the NAND in each case? If not, perhaps they have a different OOB layout? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] Fix for NFS boot for OMAP3 EVM
Hi,
What is the status of this patch ?
Any comments.
regards
-Original Message-
From: Pillai, Manikandan
Sent: Tuesday, March 03, 2009 9:10 AM
To: u-boot@lists.denx.de; dirk.be...@googlemail.com
Cc: Pillai, Manikandan
Subject: [PATCH 1/1] Fix for NFS boot for OMAP3 EVM
The eth_halt() function has been modified to remove the
chip reset and instead stop the transmit/receive from the device.
Signed-off-by: Manikandan Pillai mani.pil...@ti.com
---
drivers/net/smc911x.c | 23 ++-
1 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index 1ded8f0..2f0852e 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -116,6 +116,27 @@ static int smc911x_phy_reset(void)
return 0;
}
+static void smc911x_shutdown(void)
+{
+ unsigned cr;
+
+ /* Turn of Rx and TX */
+ cr = smc911x_get_mac_csr(MAC_CR);
+ cr = ~(MAC_CR_TXEN | MAC_CR_RXEN | MAC_CR_HBDIS);
+ smc911x_set_mac_csr(MAC_CR, cr);
+
+ /* Stop Transmission */
+ cr = smc911x_get_mac_csr(TX_CFG);
+ cr = ~(TX_CFG_STOP_TX);
+ smc911x_set_mac_csr(TX_CFG, cr);
+ /* Stop receiving packets */
+ cr = smc911x_get_mac_csr(RX_CFG);
+ cr = ~(RX_CFG_RXDOFF);
+ smc911x_set_mac_csr(RX_CFG, cr);
+
+}
+
+
static void smc911x_phy_configure(void)
{
int timeout;
@@ -224,7 +245,7 @@ int eth_send(volatile void *packet, int length)
void eth_halt(void)
{
- smc911x_reset();
+ smc911x_shutdown();
}
int eth_rx(void)
--
1.5.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
