Hi Wolfgang,
On Tuesday 28 April 2009, Wolfgang Denk wrote:
I took a quick look at the flash driver. The main functions
lpc24xx_flash_erase() and lpc24xx_write_buff() are not even referenced
somewhere in this patch. They seem to be used in the 2nd patch (2/2)
though. It's hard to really
Hi Wolfgang,
On Tuesday 28 April 2009, Wolfgang Denk wrote:
Into drivers/mtd? Even if it's not a MTD driver? This doesn't make
mnuch sense to me.
In the end this driver will be used by the common FLASH user interface
(cmd_flash.c, cmd_mem.c). So I prefer to have the driver for this
This patch includes support for the LPC2468 processor from NXP.
Signed-off-by: Remco Poelstra remco.poelstra+u-b...@duran-audio.com
---
It now also includes support for the ethernet interface.
It does not include any changes to flash related code, until it's known
where to put it. Stefan was
Hi Remco,
Remco Poelstra wrote:
This patch includes support for the LPC2468 processor from NXP.
Signed-off-by: Remco Poelstra remco.poelstra+u-b...@duran-audio.com
---
It now also includes support for the ethernet interface.
It does not include any changes to flash related code, until it's
On Saturday 25 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
In message 20090424215804.gc10...@game.jcrosoft.org you wrote:
...
+#define COPY_BUFFER_LOCATION 0x4000fde0
evenif it's soc specific flash support I think they need to be store
with the other flash and need to
Dear Stefan Roese,
In message 200904270927.29232...@denx.de you wrote:
I took a quick look at the flash driver. The main functions
lpc24xx_flash_erase() and lpc24xx_write_buff() are not even referenced
somewhere in this patch. They seem to be used in the 2nd patch (2/2) though.
It's hard
This patch includes support for the LPC2468 processor from NXP.
Signed-off-by: Remco Poelstra remco.poelstra+u-b...@duran-audio.com
---
A working board example will be submitted when this patch is found to be OK.
This patch is against latest git.
The previous problem with PUTx vs. writex is
Dear Remco Poelstra,
In message 49f1a92f.9070...@duran-audio.com you wrote:
This patch includes support for the LPC2468 processor from NXP.
Thanks.
Here a few comments:
--- a/cpu/arm720t/cpu.c
+++ b/cpu/arm720t/cpu.c
@@ -75,7 +75,7 @@ int cleanup_before_linux (void)
/* go to high
On 13:57 Fri 24 Apr , Remco Poelstra wrote:
This patch includes support for the LPC2468 processor from NXP.
Signed-off-by: Remco Poelstra remco.poelstra+u-b...@duran-audio.com
---
A working board example will be submitted when this patch is found to be OK.
This patch is against latest
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090424215804.gc10...@game.jcrosoft.org you wrote:
...
+#define COPY_BUFFER_LOCATION 0x4000fde0
evenif it's soc specific flash support I think they need to be store with the
other flash and need to have the ack of Stefan
No, not really.
Jean-Christophe PLAGNIOL-VILLARD schreef:
No, thumb code is less efficient in terms of performance, but this
single file needs thumb code. See LPC2292.
what is the Difference?
until a real big gap please do not use thumb
IAP entries need thumb code. This is not a problem, they are only
Jean-Christophe PLAGNIOL-VILLARD schreef:
I'm not an expert in assembly, but at first I had immap.h included in
start.S and it complained about invalid instructions, so if I combine
hardware.h and immap.h, then there must be some way of making sure that
the assembler ignores the C code in
Remco Poelstra schreef:
Yes I do. They are straight from the LPC2292 code, so once they were
considered OK. I checked out the the write{s,l,b} functions in asm/io.h,
but although they look similar, for some reason they simply don't work.
Given the similarities between the write{s,l,b} and
--- u-boot-orig/cpu/arm720t/lpc24xx/Makefile 1970-01-01
01:00:00.0 +0100
+++ u-boot-cleanup/cpu/arm720t/lpc24xx/Makefile2009-03-19
10:56:53.0 +0100
...
+$(SOBJS):
+ $(CC) $(AFLAGS) -march=armv4t -c -o $(SOBJS) iap_entry.S
Such compile options hsould
On 11:06 Wed 25 Mar , Remco Poelstra wrote:
Wolfgang Denk schreef:
Dear Remco Poelstra,
Is there no way we can do without such a #ifdef here?
The problem is that start.S needs hardware.h, but the code in immap.h
should not be included in start.S, so I can not merge hardware.h and
Wolfgang Denk schreef:
Dear Remco Poelstra,
In message 49c8be7a.10...@duran-audio.com you wrote:
This patch includes support for the LPC2468 processor from NXP.
The example board will follow when this patch is OK.
Such a comment does not belong into the commit message. Please mode it
Dear Remco Poelstra,
In message 49c9eb4d.5050...@duran-audio.com you wrote:
--- u-boot-orig/cpu/arm720t/interrupts.c 2009-03-18 00:42:12.0
+0100
+++ u-boot-cleanup/cpu/arm720t/interrupts.c2009-03-24
11:48:50.0 +0100
@@ -29,7 +29,11 @@
#include common.h
Wolfgang Denk schreef:
Dear Remco Poelstra,
Is there no way we can do without such a #ifdef here?
The problem is that start.S needs hardware.h, but the code in immap.h
should not be included in start.S, so I can not merge hardware.h and immap.h
Why not? I'm not aware of such a
Dear Remco Poelstra,
In message 49c8be7a.10...@duran-audio.com you wrote:
This patch includes support for the LPC2468 processor from NXP.
The example board will follow when this patch is OK.
Such a comment does not belong into the commit message. Please mode it
below the --- line.
Dear Remco Poelstra,
In message 49c25f75.3080...@duran-audio.com you wrote:
Wolfgang Denk schreef:
+/* Vectored Interrupt Controller (VIC) */
+#define VIC_BASE_ADDR 0xF000
+#define VICIRQStatus (*(volatile unsigned long *)(VIC_BASE_ADDR +
0x000))
+#define VICFIQStatus
Dear Remco Poelstra,
In message 49c10b37.1070...@duran-audio.com you wrote:
This patch includes support for the LPC2468 processor from NXP.
Signed-off-by: Remco Poelstra remco.poelstra+u-b...@duran-audio.com
General comment: There are lots of coding style issues: trailing
white space,
21 matches
Mail list logo
