Add mvsata support to SHEEVAPLUG
Signed-off-by: Gérald Kerma gera...@gmail.com
---
include/configs/sheevaplug.h | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/include/configs/sheevaplug.h b/include/configs/sheevaplug.h
index
Dear GEAK,
In message 4c6635c1.2080...@gmail.com you wrote:
Add mvsata support to SHEEVAPLUG
...
--- a/include/configs/sheevaplug.h
+++ b/include/configs/sheevaplug.h
@@ -98,6 +98,7 @@
#define CONFIG_CMD_NAND
#define CONFIG_CMD_PING
#define CONFIG_CMD_USB
+#define CONFIG_CMD_IDE
On Mon, Aug 9, 2010 at 7:42 AM, Alexander Stein wrote:
Am Montag, 9. August 2010, 09:13:45 schrieb Mike Frysinger:
On AT91 the watchdog mode register can only be written once after reset.
If this register is written by u-boot e.g. a Linux driver can't
reconfigure the watchdog later. If the
Add mvsata support to SHEEVAPLUG
Signed-off-by: Gérald Kerma gera...@gmail.com
---
Changes in v2:
* typo fixed
* list reordered
include/configs/sheevaplug.h | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/include/configs/sheevaplug.h
Commit 64419e47518bbba059c80b77558f93ad4804145c aliases
the uint16_t usp and uint32_t uip variables in print_buffer()
to uint8_t variable linebuf without aligning it to an uint32_t
address, thus causing data aborts on ARM when doing md.l on
32-bit wide area (and probably 16-bit wide as well).
(adding Mike for info as he is the submitter of 64419e47)
Hi all,
on current origin/master, doing an md on internal registers area
(0xf1xx) causes a data abort on orion5x-based edminiv2.
A git bisect between origin/master ('bad') and the last edminiv2 commit
The buffer for the status request must be word aligned
because it is accessed with 32 bit pointer in the
eth_status_complete function.
Signed-off-by: Stefano Babic sba...@denx.de
---
drivers/usb/gadget/ether.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
The patch removes an endless loop in the usb_eth_send
if the tx_complete is not called before going
in the loop. The driver interrupt routine is called
allowing the driver to check if the TX is completed.
Signed-off-by: Stefano Babic sba...@denx.de
---
Changes from V1:
- Comments by Remy
On Sat, Aug 14, 2010 at 4:11 AM, Albert Aribaud wrote:
Commit 64419e47518bbba059c80b77558f93ad4804145c aliases
the uint16_t usp and uint32_t uip variables in print_buffer()
to uint8_t variable linebuf without aligning it to an uint32_t
address, thus causing data aborts on ARM when doing md.l
Le 14/08/2010 10:25, Mike Frysinger a écrit :
int print_buffer (ulong addr, void* data, uint width, uint count, uint
linelen)
{
- uint8_t linebuf[MAX_LINE_LENGTH_BYTES + 1];
+ uint8_t linebuf[MAX_LINE_LENGTH_BYTES + 1]
+
Hello,
my current work in the AT91 SoCs will add several new drivers.
Some of them require new header files in arch-at91 or amendments
to existing header files there. Same for some at91 specific
header files in driver/*.
In existing header files it is adding adresses for
going-to-be-used
On 2010/08/14 10:14 AM, Albert ARIBAUD wrote:
Rogan, please test it and see if it fixes your issue as well (can't
swear that it will).
Mike, please test it and see if it does not regress on your side (can't
see why it should, but maybe the __aligned__ attribute is going to choke
your build
Dear Schleifer, Alexander,
If you have two days patience, wait for the new driver, I will be
most happy to have a tester ;)
TOP9000 mmci
mci: setting clock 194000 Hz, block size 512
mci: setting clock 24832000 Hz, block size 512
mci: setting clock 194000 Hz, block size 512
mci: setting clock
Hi folks
Since include/ide.h defines IDE_BUS(dev) as (dev 1), it ignores the
values of CONFIG_SYS_IDE_MAXBUS and CONFIG_SYS_MAXDEVICE, and
unconditionally expects an IDE bus to have two devices.
This expectation falls down with the Orion5x SATA support, which uses
that SATA controller in IDE
On 2010/08/14 12:41 PM, Rogan Dawes wrote:
-#defineIDE_BUS(dev)(dev 1)
+#defineIDE_BUS(dev)(dev (CONFIG_SYS_IDE_MAXDEVICE /
CONFIG_SYS_IDE_MAXBUS - 1))
#defineATA_CURR_BASE(dev)
(CONFIG_SYS_ATA_BASE_ADDR+ide_bus_offset[IDE_BUS(dev)])
Ok, I'm an idiot!
Le 14/08/2010 12:46, Rogan Dawes a écrit :
On 2010/08/14 12:41 PM, Rogan Dawes wrote:
-#defineIDE_BUS(dev)(dev 1)
+#defineIDE_BUS(dev)(dev (CONFIG_SYS_IDE_MAXDEVICE /
CONFIG_SYS_IDE_MAXBUS - 1))
#defineATA_CURR_BASE(dev)
Hello.
GEAK wrote:
Add mvsata support to SHEEVAPLUG
Signed-off-by: Gérald Kerma gera...@gmail.com
---
include/configs/sheevaplug.h | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/include/configs/sheevaplug.h
Hello.
Stefano Babic wrote:
The buffer for the status request must be word aligned
because it is accessed with 32 bit pointer in the
eth_status_complete function.
Signed-off-by: Stefano Babic sba...@denx.de
[...]
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index
Stefano Babic wrote:
The patch removes an endless loop in the usb_eth_send
if the tx_complete is not called before going
in the loop. The driver interrupt routine is called
allowing the driver to check if the TX is completed.
Signed-off-by: Stefano Babic sba...@denx.de
---
[...]
diff
Le 14/08/2010 14:19, Sergei Shtylyov a écrit :
+#define CONFIG_SYS_ATA_DATA_OFFSET (0x0100)
+#define CONFIG_SYS_ATA_REG_OFFSET (0x0100)
+#define CONFIG_SYS_ATA_ALT_OFFSET (0x0100)
The parens are useless here.
As this code comes from the mvsata_ide driver introduction, Sergei's
Dear Reinhard Meyer,
In message 4c665cb9.2040...@emk-elektronik.de you wrote:
If I add those discrete changes to each driver patch (where it
might actually belong), the incremental changes to some of
those files would require all those driver patches to be applied
in the right order to
Hi,
2010/8/14 Stefano Babic sba...@denx.de:
The buffer for the status request must be word aligned
because it is accessed with 32 bit pointer in the
eth_status_complete function.
Signed-off-by: Stefano Babic sba...@denx.de
---
drivers/usb/gadget/ether.c | 2 +-
1 files changed, 1
Hi,
2010/8/14 Sergei Shtylyov sshtyl...@mvista.com:
Hello.
Stefano Babic wrote:
The buffer for the status request must be word aligned
because it is accessed with 32 bit pointer in the
eth_status_complete function.
Signed-off-by: Stefano Babic sba...@denx.de
[...]
diff --git
Hi,
2010/8/14 Stefano Babic sba...@denx.de:
The patch removes an endless loop in the usb_eth_send
if the tx_complete is not called before going
in the loop. The driver interrupt routine is called
allowing the driver to check if the TX is completed.
Signed-off-by: Stefano Babic
Dear Wolfgang Denk,
If I add those discrete changes to each driver patch (where it
might actually belong), the incremental changes to some of
those files would require all those driver patches to be applied
in the right order to avoid conflicts.
Yes, and? What's the problem with that?
None
On Sat, Aug 14, 2010 at 4:33 AM, Albert ARIBAUD wrote:
Le 14/08/2010 10:25, Mike Frysinger a écrit :
int print_buffer (ulong addr, void* data, uint width, uint count, uint
linelen)
{
- uint8_t linebuf[MAX_LINE_LENGTH_BYTES + 1];
+ uint8_t linebuf[MAX_LINE_LENGTH_BYTES + 1]
+
Dear Reinhard Meyer,
In message 4c66cccf.9080...@emk-elektronik.de you wrote:
None for me. Only for people that want to try out a single (driver)
patch.
They can apply the patch series anyway (at least to the patch they are
interested in).
For example at91_gpbr.h is required by two
Dear Wolfgang Denk,
Have the first add that file, and the second assume it comes later in
the sequence.
You don't mean by sequence PATCH 1/n, 2/n, etc? The drivers are so
independent that that would not really make sense...
The wiki page does not talk about drivers... It's a general rule and
On Sat, Aug 14, 2010 at 3:30 PM, Reinhard Meyer wrote:
#define DBU_ADDR 0xsomething (in a SoC header file)
dbu_t *dbu = (dbu_t *)DBU_ADDR; (in a function)
needs to be volatile ...
-mike
___
U-Boot mailing list
U-Boot@lists.denx.de
Dear Mike Frysinger,
On Sat, Aug 14, 2010 at 3:30 PM, Reinhard Meyer wrote:
#define DBU_ADDR 0xsomething (in a SoC header file)
dbu_t *dbu = (dbu_t *)DBU_ADDR; (in a function)
needs to be volatile ...
-mike
Why? The elements are used as parameters to readl/writel functions:
status =
Dear Reinhard Meyer,
In message 4c66eeca.5020...@emk-elektronik.de you wrote:
Have the first add that file, and the second assume it comes later in
the sequence.
You don't mean by sequence PATCH 1/n, 2/n, etc? The drivers are so
independent that that would not really make sense...
Then
Dear Wolfgang Denk,
Then just write in the comment part of the second patch that the other
one has to be applied first...
Thats fine with me.
Anyway, is the method of (for example!)
#define DBU_ADDR 0xsomething (in a SoC header file)
dbu_t *dbu = (dbu_t *)DBU_ADDR; (in a function)
OK?
Would the toolchain gulp when one defines the whole 4 GB that way?
In fact, a rather novel approach (just theorizing here):
#define SRAM_BASE offsetof(soc.sram)
#define SRAM_SIZE sizeof(soc.sram)
dbu_t *dbu = (dbu_t *)offsetof(soc.dbu);
without ever assigning soc the address 0...
Reinhard
On Sat, Aug 14, 2010 at 3:40 PM, Reinhard Meyer wrote:
Dear Mike Frysinger,
On Sat, Aug 14, 2010 at 3:30 PM, Reinhard Meyer wrote:
#define DBU_ADDR 0xsomething (in a SoC header file)
dbu_t *dbu = (dbu_t *)DBU_ADDR; (in a function)
needs to be volatile ...
Why? The elements are used as
Dear Reinhard Meyer,
In message 4c66f54d.2060...@emk-elektronik.de you wrote:
I was even thinking of something like
struct soc {
u32 xyz[0x80]; /* XYZ unit */
u32 dbu[0x80]; /* Debug Unit */
u32 rstc[0x80]; /* Reset Controller */
and so on.
This is what PPC used to
Dear Reinhard Meyer,
In message 4c6700e5.2070...@emk-elektronik.de you wrote:
Would the toolchain gulp when one defines the whole 4 GB that way?
In fact, a rather novel approach (just theorizing here):
#define SRAM_BASE offsetof(soc.sram)
#define SRAM_SIZE sizeof(soc.sram)
dbu_t *dbu
Dear Wolfgang Denk,
I think we have a misunderstaning ehre - I thought the entries like
xyz were indeed u32 types - buut now I get the impression that
what you have in mind is that they are actually structs describing
hardware blocks.
No, thats just spacemakers, otherwise one would have do
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
tools/Makefile |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/tools/Makefile b/tools/Makefile
index 749d994..ea271bf 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -41,6 +41,7 @@ include $(TOPDIR)/config.mk
#
Convert the tools/env/Makefile to use the same host tool syntax as the
other tool subdirs.
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
tools/env/Makefile |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/env/Makefile b/tools/env/Makefile
index
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
tools/.gitignore |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/tools/.gitignore b/tools/.gitignore
index cb067a4..07f21a3 100644
--- a/tools/.gitignore
+++ b/tools/.gitignore
@@ -9,3 +9,8 @@
/ubsha1
40 matches
Mail list logo
