Patch 1 adds generalisation to spi_flash.c to allow for table driven
probing of JEDEC and NON-JEDEC conformant devices
Patch 2 adds the actual Ramtron support
Patch 2 requires Patch 1 to be applied first.
___
U-Boot mailing list
U-Boot@lists.denx.de
JEDEC types
non JEDEC types
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
drivers/mtd/spi/Makefile |1 +
drivers/mtd/spi/ramtron.c| 321 ++
drivers/mtd/spi/spi_flash.c |8 +
drivers/mtd/spi
Dear Wolfgang Denk,
In this case patches MUST be numbered.
I know, and I expected them to be numbered by send-email, but I have to
have them numbered by format-patch. But there is now the catch that I got 8
commits and it numbers consequently 1/8, 2/8. What simple trick allows me to
format-patch
Dear Wolfgang Denk,
I know, and I expected them to be numbered by send-email, but I have to
have them numbered by format-patch. But there is now the catch that I got 8
commits and it numbers consequently 1/8, 2/8. What simple trick allows me to
format-patch only HEAD~8 and HEAD~7 ?
git
Dear Wolfgang Denk,
Thanks. Way too simple to see the dots through a big redwood board.
(though I'd use HEAD~8..HEAD~7)
This would give you only a single patch, representing the commit at
HEAD~7
Thanks for clarifying! Interesting logic, however ;)
Is there a similar simple trick to
Dear Mike Frysinger,
7c7e2813318b84fc4fbec57b23e2ad68ff000564 NET: move legacy enc28j60.c to
sidetrack - Ben took that one to net/next on 31.08.2010
that's Ben's call to move from net to mainline ... and unless there's a
pressing reason for this to be in mainline (i cant see any), keeping it
Dear Mike Frysinger,
On Sunday, September 12, 2010 15:06:07 Wolfgang Denk wrote:
Reinhard Meyer wrote:
Is there a similar simple trick to produce the 0/n e-Mail? I mean without
hand entering Subject and Body into the send-email phase? Like having it
in a prepared file?
Maybe the --compose
Dear Steve Sakoman,
I did a bit of v2010.09-rc1 testing on OMAP3 this evening and things
looked good until I tried a simple memory display!
The output froze after the memory address was displayed:
Overo # md 8200 10
8200:
That _might_ be the unaligned access to the buffer. Try
Dear Alexander Stein,
+ /* Disable PITC
+ * Add 0x1000 to current counter to stop it faster
+ * without waiting for wrapping back to 0
+ */
Sorry, a multiline comment goes like this:
/*
* 1st line
* ...
* last line
*/
Best Regards,
Reinhard
attachment:
Dear Andreas Bießmann,
+ sprintf(dev-name, at91_emac);
I would think emac is sufficient. That they are on an AT91 system
should be obvious to the user.
And if, somehow, in the future, MACB and AT91_EMAC get merged, we
would not need to change this again :)
Reinhard
Dear Stefano Babic,
Amit Kucheria wrote:
Stefano,
Any further comment on this patch? Does it still require more work
that we can take on?
Hi Amit,
as I know there is a newer version of the patch [V6] as the one you
reported:
Dear Lei Wen,
Hi Reinhard,
Besides that my remarks to yesterdays patch of yours are still valid:
Those magic numbers are due to a specific hardware controller/limitation
and not any SD/MMC card limitation.
And which hardware driver are you using this with?
Maybe some context would help.
Dear all,
#define MACH_TYPE_WLAN_COMPUTER2966
+#define MACH_TYPE_DOCKSTAR 2998
NAK. We don't edit mach-types.h manually.
If you need it updated, please send a request to do so to the acting
ARM custodian (ahem).
But also note that we always sync against
On 08.09.2010 09:48, Wolfgang Denk wrote:
Dear Reinhard Meyer,
In message4c87065a.5050...@emk-elektronik.de you wrote:
Dear Wolfgang Denk,
+ /* linebuf as a union causes proper alignment */
+ union linebuf {
+ uint32_t ui[MAX_LINE_LENGTH_BYTES/4 + 1];
+ uint16_t us
Dear Wolfgang Denk,
Dear Reinhard Meyer,
In message4c873717.6000...@emk-elektronik.de you wrote:
Since it apparently takes roughly two months for additions to the database
at http://www.arm.linux.org.uk/developer/machines/ (last entry: 3061 right
now)
to trickle to the u-boot file
use a union to cause necessary alignment per architecture
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
lib/display_options.c | 27 +++
1 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/lib/display_options.c b/lib/display_options.c
index
Wolfgang Denk schrieb:
Dear Reinhard Meyer,
In message 4c874c02.9030...@emk-elektronik.de you wrote:
I'm open to suggestions.
I'd allow manual adding of a #define MACH_TYPE_ at the end of the list
provided its value is higher than the last official entry. Once the
official
list
Dear Mike Frysinger,
On Monday, September 06, 2010 10:59:16 Reinhard Meyer wrote:
+int enc_miiphy_read(const char *devname, u8 phy_adr, u8 reg, u16 *value)
+{
+struct eth_device *dev = eth_get_dev_by_name(devname);
+if (dev) {
+enc_dev_t *enc = to_enc(dev
Dear Paulraj, Sandeep,
We are in sync with the latest in linux kernel
Take a look at
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=history;f=arch/arm/tools/mach-types;h=48cbdcb6bbd4288929f31bef94da3691b160a489;hb=917977d107c9640dbb29ce85542735ad56e3aa5a
Please read the
Dear Wolfgang Denk,
Yes, error handling blows up the code. But it helpos a lot to make
programs reliable and robust.
Of course I will add that.
And in theory it could help.
In reality no SPI drivers check for conflicting
claims - and therefore notoriously return ZERO.
A nice example:
int
On 07.09.2010 15:57, Wolfgang Denk wrote:
Dear Lei Wen,
In message1283862729-17045-1-git-send-email-lei...@marvell.com you wrote:
Signed-off-by: Lei Wenlei...@marvell.com
---
drivers/mmc/mmc.c | 59
++--
1 files changed, 38
Dear Will Tucker,
Hi,
I’m trying to get the ATSAM9G20-EK booting from SD/MMC on MCI A, with the
Nand
and Dataflash disabled, with no luck.
I have gotten the latest u-boot-atmel compiled and placed boot.bin on a FAT
16
formatted. When I turn power on I only get RomBoot on the
Dear Wolfgang Denk,
+/* linebuf as a union causes proper alignment */
+union linebuf {
+uint32_t ui[MAX_LINE_LENGTH_BYTES/4 + 1];
+uint16_t us[MAX_LINE_LENGTH_BYTES/2 + 1];
+uint8_t uc[MAX_LINE_LENGTH_BYTES/1 + 1];
Please replace the magic
Dear Lei Wen,
As mmc host limitation, the max number of block in one go
should be limited to 65535, and the max buffer size should
not excceed 512k bytes.
Where does this limitation supposedly come from?
And, 65535 blocks (of 512) are already near 32 MB.
TOP9000 mmci
mci: setting clock
Lei Wen schrieb:
On Mon, Sep 6, 2010 at 5:23 PM, Reinhard Meyer u-b...@emk-elektronik.de
wrote:
Dear Lei Wen,
As mmc host limitation, the max number of block in one go
You already write it's a HOST limitation.
should be limited to 65535, and the max buffer size should
not excceed 512k
Lei Wen schrieb:
Where does this limitation supposedly come from?
This limitation comes from the SD/MMC sepc. You could find one and
check the 0x6 offset register(BLOCK COUNT REGISTER).
This might refer to certain HOST controllers, but not to Cards!
You are right, this comes from HOST, not
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
drivers/net/Makefile |1 +
drivers/net/enc28j60.c | 842
drivers/net/enc28j60.h | 250 ++
include/netdev.h |2 +
4 files changed, 1095 insertions(+), 0
Dear Lei Wen,
According spec, high capacity mmc should be calculated by sector
number multiply by sector size.
Signed-off-by: Lei Wen lei...@marvell.com
---
drivers/mmc/mmc.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/mmc.c
Reinhard Meyer schrieb:
This patch adds SD/MMC support to AT91SAM9260/9XE/9G20
using the generic MMC framework.
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
The driver itself is not dependent on any particular AT91 or AVR32
device, but further work in device specific files
Reinhard Meyer schrieb:
From: Reinhard Meyer i...@emk-elektronik.de
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
arch/arm/include/asm/arch-at91/at91_gpbr.h | 45 +
arch/arm/include/asm/arch-at91/at91_rtt.h | 36 ++
drivers/rtc/Makefile
Reinhard Meyer schrieb:
Define the different location of the GPBRs for the 9XE
Define the proper CPU Name
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
arch/arm/include/asm/arch-at91/at91sam9260.h | 18 ++
1 files changed, 14 insertions(+), 4 deletions
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
arch/arm/cpu/arm926ejs/at91/reset.c | 17 -
1 files changed, 8 insertions(+), 9 deletions(-)
Applied (with requested changes) to u-boot-atmel/next
Thanks,
Reinhard
___
U-Boot
Reinhard Meyer schrieb:
From: Reinhard Meyer i...@emk-elektronik.de
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
drivers/spi/atmel_spi.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
Applied to u-boot-atmel/next
Thanks,
Reinhard
Reinhard Meyer schrieb:
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c | 35
+++--
1 files changed, 25 insertions(+), 10 deletions(-)
Applied to u-boot-atmel/next
Thanks,
Reinhard
Reinhard Meyer schrieb:
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
arch/arm/include/asm/arch-at91/hardware.h |1 +
arch/arm/include/asm/arch-at91/memory-map.h |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
Applied to u-boot-atmel/next
Thanks,
Reinhard
Dear Alexander Stein,
...
Signed-off-by: Alexander Stein alexander.st...@systec-electronic.com
...
+ /* Disble PITC
+ * Add 0x1000 to current counter to stop it faster
+ * without waiting for wrapping back to 0
+ */
+ writel(cpiv + 0x1000, pit-mr);
...
Please
Dear Andreas Bießmann,
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
---
arch/arm/include/asm/arch-at91/at91_emac.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/arch-at91/at91_emac.h
Alexander Stein schrieb:
Signed-off-by: Alexander Stein alexander.st...@systec-electronic.com
---
arch/arm/include/asm/arch-at91/at91_pit.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Applied to u-boot-atmel/next
Thanks,
Reinhard
Andreas Bießmann schrieb:
Dear Reinhard Meyer,
Am 03.09.2010 12:25, schrieb Reinhard Meyer:
Dear Andreas Bießmann,
Please resubmit as pure text, not base64 encoded.
my MUA tells me:
---8---
Message-Id: 1283082856-82859-1-git-send-email-andreas.de...@googlemail.com
...
Content
Hello Andreas,
did/can you test that one as well?
Then I can take all 3 of the series in.
Thanks,
Reinhard
In addition to the real PC value, also print the value of PC after
subtracting the relocation offset. This value will match the address in
the ELF file so it's much easier to figure out
Reinhard Meyer schrieb:
Reinhard Meyer schrieb:
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
arch/arm/include/asm/arch-at91/hardware.h |1 +
arch/arm/include/asm/arch-at91/memory-map.h |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
Applied to u-boot-atmel
environement
Jens Scharsig (1):
AT91 Fix: return value of get_tbclk
Reinhard Meyer (7):
AT91: MCI: add SD/MMC driver using mmc framework
AT91: add RTT and GPBR based RTC
AT91SAM9XE: add embedded flash support
AT91: fix at91sam9260.h for AT91SAM9XE
AT91: reset.c
Haavard Skinnemoen schrieb:
In addition to the real PC value, also print the value of PC after
subtracting the relocation offset. This value will match the address in
the ELF file so it's much easier to figure out where things went wrong.
Signed-off-by: Haavard Skinnemoen
Haavard Skinnemoen schrieb:
The paging system which is required to set up caching properties has not
yet been initialized when the SDRAM is initialized. So when the
map_physmem() function is converted to return the physical address
unchanged, the SDRAM initialization will break on some boards.
Haavard Skinnemoen schrieb:
Use the MMU hardware to set up 1:1 mappings between physical and virtual
addresses. This allows us to bypass the cache when accessing the flash
without having to do any physical-to-virtual address mapping in the CFI
driver.
The virtual memory mappings are defined
The following changes since commit bd2313078114c4b44c4a5ce149af43bcb7fc8854:
Wolfgang Denk (1):
Merge branch 'master' of ssh://gemini/home/wd/git/u-boot/master
are available in the git repository at:
git://git.denx.de/u-boot-atmel avr32
Haavard Skinnemoen (3):
avr32: Print
Dear Mike Frysinger,
pass the bus/cs/speed/mode in to the initialize function and store it in the
per-device state. then you can work fine with multiple enc28j60 devices in
one board.
along those lines, all of the local enc funcs should be changed to take the
private state and operate off
On 03.09.2010 21:51, Mike Frysinger wrote:
yes and no. the spi bus/cs/mode/speed is established at initialize() time,
not init(), so you'd need to store that per-instance information somewhere.
and how the discussion about netconsole handling falls out (not calling
init/halt after every
On 03.09.2010 23:03, Mike Frysinger wrote:
not sure, however, if calling spi_setup_slave() is ok at this point.
i believe the func should only doing validation on the arguments. it shouldnt
need to talk to any actual hardware. maybe this needs codifying in the API
documentation.
In
On 04.09.2010 00:14, Mike Frysinger wrote:
On Friday, September 03, 2010 17:23:43 Reinhard Meyer wrote:
On 03.09.2010 23:03, Mike Frysinger wrote:
not sure, however, if calling spi_setup_slave() is ok at this point.
i believe the func should only doing validation on the arguments
Jens Scharsig schrieb:
Am 2010-08-31 09:36, schrieb Reinhard Meyer:
Hi,
}
-- 1.6.0.2
Applied to u-boot-atmel/next
Thanks,
Reinhard
What is the reason for the new branch/Custodian Tree u-boot-atmel.
Hello,
one reason is that AVR32 and AT91 share alot in the peripheral
building blocks
Hi,
making the change to the union, I also realized that
/* Copy from memory into linebuf and print hex values */
for (i = 0; i linelen; i++) {
uint32_t x;
if (width == 4)
x = lb.u32[i] = *(volatile uint32_t *)data;
else if (width == 2)
x
use a union to cause necessary alignment per architecture
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
lib/display_options.c | 24 +---
1 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/lib/display_options.c b/lib/display_options.c
index 20319e6
Hi,
this patch also fixed BOOTDELAY on AT91:
* Fix: return value of get_tbclk
* this fixes issue with prematurely restart/retry, if BOOT_RETRY_TIMEOUT is used
Signed-off-by: Jens Scharsig js_at...@scharsoft.de
---
cpu/arm926ejs/at91/timer.c |5 +
1 files changed, 1 insertions(+), 4
Hi Detlev,
diff --git a/lib/display_options.c b/lib/display_options.c
index 20319e6..9048a8a 100644
--- a/lib/display_options.c
+++ b/lib/display_options.c
@@ -101,7 +101,7 @@ void print_size(unsigned long long size, const char *s)
#define DEFAULT_LINE_LENGTH_BYTES (16)
int print_buffer
Reinhard Meyer schrieb:
+uint32_t linebuf[MAX_LINE_LENGTH_BYTES/4 + 1];
uint32_t *uip = (void*)linebuf;
uint16_t *usp = (void*)linebuf;
uint8_t *ucp = (void*)linebuf;
I personally prefer this above an attribute. Its disputeable but I prefer
to do things with normal C
Albert ARIBAUD schrieb:
Le 30/08/2010 12:31, Stefano Babic a écrit :
Detlev Zundel wrote:
Hi Reinhard,
Hi Reinhard, hi Detlev,
should make the buffer an union:
union {
uint32_t ui[MAX.../4+1];
uint16_t us[MAX.../2+1];
uint8_t uc[MAX...+1];
} linebuf;
That also sounds good
Xiangfu Liu schrieb:
Signed-off-by: Xiangfu Liu xian...@openmobilefree.net
---
include/mmc.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/mmc.h b/include/mmc.h
index fcb237e..b913a60 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -189,12 +189,12
Detlev Zundel schrieb:
Detlev, regarding the discussion I would only point out that we have to
be sure that such kind of patch will be merged in the current release.
It would be a real pity if a new official realease is published and then
even a simple md command does not work on ARM.
I
On 30.08.2010 20:03, Albert ARIBAUD wrote:
Le 30/08/2010 18:47, Detlev Zundel a écrit :
Hi Reinhard,
Detlev Zundel schrieb:
Detlev, regarding the discussion I would only point out that we have to
be sure that such kind of patch will be merged in the current release.
It would be a real pity
Dear Albert ARIBAUD,
If you need a patch for this, I have made the change here this morning.
I can format and email one instantly.
Reinhard
I say go ahead!
Its there, right after the message. It has a different title,
because I made it before I found the tread about the issue :)
Reinhard
Dear Mike Frysinger,
On Thursday, August 26, 2010 16:00:50 Reinhard Meyer wrote:
interesting, but what if we push it further. something like this (untested):
That code does not address the following issues to complete extend:
1. JEDEC conformant that have ID in first byte
2. JEDEC conformant
Dear Mike Frysinger,
On Friday, August 27, 2010 07:16:37 Reinhard Meyer wrote:
From: Reinhard Meyeri...@emk-elektronik.de
Signed-off-by: Reinhard Meyeru-b...@emk-elektronik.de
looks like you still need to do `git commit --amend --author 'Reinhard Meyer
u-b...@emk-elektronik.de'` ...
Both
On 29.08.2010 00:28, Mike Frysinger wrote:
On Saturday, August 28, 2010 18:23:18 Reinhard Meyer wrote:
Dear Mike Frysinger,
On Friday, August 27, 2010 07:16:37 Reinhard Meyer wrote:
From: Reinhard Meyeri...@emk-elektronik.de
Signed-off-by: Reinhard Meyeru-b...@emk-elektronik.de
looks like
On 29.08.2010 01:17, Mike Frysinger wrote:
On Saturday, August 28, 2010 17:48:39 Mike Frysinger wrote:
+/* Make sure the ID was jedec extended */
+j = flashes[i].shift - 1;
+while (j= 0 idcode[j] == 0x7f)
+
On 29.08.2010 02:14, Mike Frysinger wrote:
if you want to take the patch i posted and extend that by itself with the
comments here, and then do the ramtron patch separately on top of that, that'd
be great.
Hehe, you like to impose extra work on poor moi
the first patch would add the table
On 29.08.2010 04:26, Mike Frysinger wrote:
On Saturday, August 28, 2010 21:59:26 Reinhard Meyer wrote:
On 29.08.2010 02:14, Mike Frysinger wrote:
if you want to take the patch i posted and extend that by itself with the
comments here, and then do the ramtron patch separately on top
On 29.08.2010 06:34, Mike Frysinger wrote:
when you're editing a commit in the middle of a rebase, you can add on any
number of commits you like on top of it. so usually the way i split commits:
git rebase -icommit^
mark the commit i want to split as edit
exit the
Stefano Babic schrieb:
As linebuf is accessed with 32-bit pointers, its address
must be 32 bit aligned to avoid misaligned access.
Signed-off-by: Stefano Babic sba...@denx.de
---
lib/display_options.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
From: Reinhard Meyer i...@emk-elektronik.de
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
drivers/mtd/spi/Makefile |1 +
drivers/mtd/spi/ramtron.c| 312 ++
drivers/mtd/spi/spi_flash.c | 54 ++-
drivers/mtd
Dear Timur,
On Aug 27, 2010, at 8:14 AM, Detlev Zundeld...@denx.de wrote:
We can discuss this once I see the code that makes virtual coordinates
If you can help me figure out how to get the boot text to appear below the
logo, I won't need to use virtual coordinates.
1. would it be
On 27.08.2010 20:24, Stefano Babic wrote:
Reinhard Meyer wrote:
Hi Reinhard,
Why not just declare it as
uint_32t linebuf[MAX_LINE_LENGTH_BYTES/4+1];
?
Yes, we do not need any special compiler attribute. I forward to Albert,
he sent previously an analog patch to solve this issue
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
lib/display_options.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/display_options.c b/lib/display_options.c
index 20319e6..9048a8a 100644
--- a/lib/display_options.c
+++ b/lib/display_options.c
@@ -101,7
Dear Mike Frysinger,
From: Reinhard Meyeri...@emk-elektronik.de
Give me a tip how I can change that info. The first patch to this was
committed while I used info. Squashing other patches into it does not
change that. rebase -i, edit, --amend does not present that line for
edit. The only idea I
Dear Mike Frysinger,
#if defined(CONFIG_SPI_FRAM_RAMTRON)
# define IDCODE_LEN 10
#else
# define IDCODE_LEN 5
#endif
OK, see below. Can't we have it 10 generally? The impact should be
negligible?
hrm, i guess ... but i didnt even really like raising it to the 5 for one
specific family
Dear Mike Frysinger,
From: Reinhard Meyeri...@emk-elektronik.de
Give me a tip how I can change that info. The first patch to this was
committed while I usedinfo. Squashing other patches into it does not
change that. rebase -i, edit, --amend does not present that line for
edit. The only idea
and cleaned up error messages and help,
removed pointless debug() call.
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
common/cmd_spi.c | 40 +---
1 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/common/cmd_spi.c b/common
Dear Mike,
1. looking at spi_flash.c, shall I add the standard copyright,
keeping atmel as author?
2. I can find the following lengths of idcode used:
atmel 2
macronix 3
ramtron 9
spansion 5
sst 3
stmicro 4
winbond 3
Do you really want to flexify this? Even before relocation 5 bytes
more on
Dear Mike,
I have been looking at the possible solutions quite some time now,
the issue is rather complex:
1. according to Ramtron, 0x7f is a continuation byte defined in a
JEDEC standard (I could not find a spec for that), and shall be
ignored until a non-0x7f shows. That shall be Manufacturer
Dear Xu, Hong,
Per the latest datasheet from Atmel's official website, 0xFD60 is GPBR
base address for SAM9XE
0xFD50 is GPBR base address for SAM9260.
True. I still think it was not planned like that. It just makes live more
complicated since otherwise, as long as one does not use the
From: Reinhard Meyer i...@emk-elektronik.de
---
arch/arm/include/asm/arch-at91/at91_gpbr.h | 45 +
arch/arm/include/asm/arch-at91/at91_rtt.h | 36 ++
drivers/rtc/Makefile |1 +
drivers/rtc/at91sam9_rtt.c | 100
Define the different location of the GPBRs for the 9XE
Define the proper CPU Name
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
arch/arm/include/asm/arch-at91/at91sam9260.h | 18 ++
1 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include
From: Reinhard Meyer i...@emk-elektronik.de
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
arch/arm/include/asm/arch-at91/at91_gpbr.h | 45 +
arch/arm/include/asm/arch-at91/at91_rtt.h | 36 ++
drivers/rtc/Makefile |1 +
drivers/rtc
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
common/cmd_i2c.c | 17 +++--
1 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c
index 371e022..1283c82 100644
--- a/common/cmd_i2c.c
+++ b/common/cmd_i2c.c
@@ -152,7 +152,7
From: Reinhard Meyer i...@emk-elektronik.de
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
drivers/mtd/spi/Makefile |1 +
drivers/mtd/spi/ramtron.c| 297 ++
drivers/mtd/spi/spi_flash.c | 13 ++
drivers/mtd/spi
From: Reinhard Meyer i...@emk-elektronik.de
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
drivers/spi/atmel_spi.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/atmel_spi.c b/drivers/spi/atmel_spi.c
index 317c0b4..d0de931 100644
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
arch/arm/include/asm/arch-at91/hardware.h |1 +
arch/arm/include/asm/arch-at91/memory-map.h |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/arch-at91/hardware.h
b/arch/arm/include/asm
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c | 35 +++--
1 files changed, 25 insertions(+), 10 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c
b/arch/arm/cpu/arm926ejs/at91
Dear Mike Frysinger,
bus:cs[.mode]bit_len dout
how so ? the bus:cs.mode field is always going to be one argv, and your patch
has it so that argv[1] is always parsed against this form. i dont see where
this limitation is that you're seeing ...
-mike
Currently, without a :, the . part won't
Dear Mike Frysinger,
i dont have a problem with going through the env as a hook, but it doesnt seem
to scale. what if you have 2 fram devices and a winbond spi flash ? perhaps
the name spec should be:
fram_dev.bus.cs
then you can signal that only certainbus.cs locations should get
Dear Mike Frysinger,
were you going to send an updated version ?
Soon. Currently I have other issues and a rather
dirty working tree :)
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Dear sandeep suresh,
Dear Reinhard Meyer,
Appreciate your quick response. I had done this earlier
before posting this mail, but with the same problem:
step 1) export PATH=$PATH:/work/arm/4.3.2/bin
step 2) make distclean
step 3) make AT91SAM9260ek_config
step 4)make
Can you please help me
Dear sandeep suresh,
Dear Reinhard Meyer All,
Apology for not sending to the mailing list; forwarding
the same to the mailing list. There is already a #define
CONFIG_AT91SAM9260ek 1 in /include/configs/at91sam9260ek.h. I will check
further.
#define CONFIG_AT91SAM9G20EK !!!
I
Dear Mike Frysinger,
this usage string no longer makes sense. how about:
[bus:]cs[.mode] bit_len dout - Send bit_len bits from
dout out the SPI\n
The problem is, that without blowing up the parser even more, only
2 forms of the command are valid:
the classic form
cs bit_len dout
or
For some reason Atmel changed the GPBR address for the AT91SAM9XE
to be different from the engineering samples and the AT91SAM9260.
Also let the correct SoC name be defined.
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
arch/arm/include/asm/arch-at91/at91sam9260.h | 19
For some reason Atmel changed the GPBR address for the AT91SAM9XE
to be different from the engineering samples and the AT91SAM9260.
Also let the correct SoC name be defined.
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
one probably need not understand why the first mail
got
- 0 spaces
- 1 space
- 2 spaces
- 3 spaces
- 4 spaces
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Dear Xu, Hong,
adds kernel compatible RTC handling to u-boot using the RTT
and one GPBRegister
...
arch/arm/include/asm/arch-at91/at91_gpbr.h | 45 +
arch/arm/include/asm/arch-at91/at91_rtt.h | 36 ++
drivers/rtc/Makefile |1 +
Dear Xu, Hong,
Some of Atmel's ARM926EJS chips have builtin RTC, for example, SAM9G45
SAM9M10 SAM9RL and new X5 serials.
May we take this into account at this stage?
Maybe you can help me here:
the 9260 and the 9XE-ENG Sample (soldered on my EK)
have the GPBRs at 0xfd50.
Its sold as a
Dear sandeep suresh,
Dear all,
I am using the AT91SAM9G20EK kit and want to port Linux on this. I am
using
the AT91SAM9260ek configuration as it seems the closest. The problem is after
building the U-boot with the sources for this board, generating the .bin,
loading and a power on
501 - 600 of 735 matches
Mail list logo
