Dear Ben Warren,
Applied to net repo.
OOPS, I already caught them in the AT91 repo and they are on the way to
mainstream already.
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Dear Peter Gsellmann,
this issue is already fixed by the patch:
[PATCH] AT91 clock/timer: move static data to global_data struct
(Message-Id: 1286290475-2989-1-git-send-email-u-b...@emk-elektronik.de)
of Oct 5, 2010. Please try that patch. I will apply it to u-boot-atmel soon
if no complaints
Dear Mike Frysinger,
On Tuesday, October 05, 2010 10:56:39 Reinhard Meyer wrote:
+/*
+ * count the number of continuation bytes, but
+ * leave at least 3 bytes to the end of the buffer untouched
+ */
+for (shift = 0, idp = idbuf;
+shift (sizeof(idbuf) - 3
Hello,
I just have built gcc-4.3.5 for arm-eabi. When I compile u-boot with it,
it stops after the DRAM: 64 MiB. I _assume_ that relocation does not work.
I do not have time right now to further investigate this issue, but if
someone else finds the same problem, this might be an issue worth
Dear Mike Frysinger,
NONE of the existing functions work with expansion, so they all get the
unshifted, full ID buffer.
err, right. was thinking it also shifted off the manu id byte and not just
the continuation bytes.
i'll tweak the patch i posted and pull in your ramtron patch.
Dear Lei Wen,
As suggested by Reinhard, I add two additional member in mmc structure,
so that we could specify its value in each driver. If that value is 0, then
the behavior would be the same as original, as no seperation.
After thinking alot about this:
Preface: (for understanding of the
Reinhard Meyer schrieb:
Hello,
I just have built gcc-4.3.5 for arm-eabi. When I compile u-boot with it,
it stops after the DRAM: 64 MiB. I _assume_ that relocation does not work.
I do not have time right now to further investigate this issue, but if
someone else finds the same problem
Dear Lei Wen,
Ok, I am also fine with not include the 512KiB restriction.
So we comes to a conclusion that we still use v1 patch, but cut the
512KiB limitation?
Considering the comments that were given to that one, yes.
As mmc host limitation, the max number of block in one go
should be
Dear all concerned,
But my (limited!) understanding is that it's not a platform problem
you are solving, but one of this special kind of controller, which
nobody else would ever run into.
I would vouch to extend
struct mmc {
struct list_head link;
char name[32];
void
Dear Lei Wen,
I think it is a generic problem, and I am also curios why other people
don't complain for it...
Because it is NOT a generic problem.
In Linux code, the multi-write write semantic also has such limitation
in platform code.
So if UBOOT also could have this, that would be so
On 09.10.2010 00:54, David Collier wrote:
Apologies if this is a double -post - I didn't get it back in my feed
from the mailing list maybe it is awaiting approval or something.
But I'm off on holiday, and I'd really like it to be out there
Dear Andreas Bießmann,
This patch increases timeout for autonegotiation from 1 second to 3 seconds.
Some boards (e.g. at91rm9200ek) did not negotiate within 1 second.
@@ -220,7 +220,7 @@ static int at91emac_phy_reset(struct eth_device *netdev)
at91emac_write(emac,
Dear Andreas Bießmann,
This patch increases timeout for autonegotiation from 1 second to 3 seconds.
Some boards (e.g. at91rm9200ek) did not negotiate within 1 second.
@@ -220,7 +220,7 @@ static int at91emac_phy_reset(struct eth_device *netdev)
at91emac_write(emac,
Back to the problem: How about moving the watchdog_reset call to
serial_puts()
in common/serial.c? Or do you have another (better) idea in mind?
Are you really sure this is the right place, i. e. this is where the
problem happens?
I doubt that.
lwmon5 which has this nasty 100 ms
Dear Albert Aribaud, Heiko Schocher,
ELF relocation tables generated with linker option -pie can
be used to fixup code and data in a single loop at relocation,
removing the need for manual fixups anywhere else in the code.
To me it looks now like we have dangling use of
Dear Albert ARIBAUD,
Indeed, CONFIG_SYS_ARM_WITHOUT_RELOC should disappear eventually -- it's
still there only to give board maintainers a way to build with and
without relocation e.g. for testing purposes, and it was announced that
it would disappear when relocation makes it into an official
Dear Mike Frysinger,
Simple stuff already posted to the list a while ago. I'm pretty sure
I have all the latest versions of these patches, but submitters should
probably double check ...
You might want to look at my V5 Patch of SPI table driven probing and
RAMTRON support. Its V4 with your
Dear Graeme Russ,
I had a quick look at this and nothing is jumping out at me. Of course I am
not familiar with ARM asm...
I don't see any reason why this ultimately will not work eventually. You
may be having some issues with the transition from asm-C-asm through the
relocation - This was
Dear Graeme Russ,
P.S. Here's a thought I ended up discarding:
Each board could have a main config with all the common configuration
values and a number of secondary includes (which include the primary) for
each specific configuration. The entry in boards.cfg would select a
specific
Dear chris chriss,
I'm trying to test the cache on my beagle with a snapshot from the git tree
today. I tried it out by loading a file from the mmc with dcache off and
then dcache on. I didn't see any difference in speed. After reading this
commit
Dear Wolfgang Denk, dear Albert Aribaud,
Initial Test reports:
File Size with Heiko's patch: 244k
U-Boot works.
File size with Albert's V2 patch: 255k
U-Boot stops at:
U-Boot 2010.09-00113-g3c5eeb8-dirty (Oct 05 2010 - 10:04:25)
CPU: AT91SAM9XE
Crystal frequency: 18.432 MHz
CPU clock
Dear Wolfgang Denk, dear Albert Aribaud,
Initial Test reports:
File Size with Heiko's patch: 244k
U-Boot works.
File size with Albert's V2 patch: 255k
U-Boot stops at:
U-Boot 2010.09-00113-g3c5eeb8-dirty (Oct 05 2010 - 10:04:25)
CPU: AT91SAM9XE
Crystal frequency: 18.432 MHz
CPU
I _think_ the linker file needs a .align there:
(.data ends with a non-aligned address!)
Why do I happen to have all the luck when testing ;)
.data 0x21f37f540x0 drivers/spi/libspi.a(atmel_spi.o)
.data 0x21f37f540x0 drivers/rtc/librtc.a(at91sam9_rtt.o)
.data
Dear Wolfgang Denk,
Be careful! Both my and Heikos patches go _on_top_ of Albert's patch!
Just figured that out already:)
But for arm926 I don't need your patch, and Heikos' was adding
relocation fixup to env, which is not needed anymore, right?
It crashes during relocation, I am adding debug
Dear Albert ARIBAUD,
U-Boot 2010.09-00114-g4ab53c3-dirty (Oct 05 2010 - 11:46:07)
U-Boot code: 21F0 - 21F3EBA0 BSS: - 21F80100
CPU: AT91SAM9XE
Crystal frequency: 18.432 MHz
CPU clock: 198.656 MHz
Master clock : 99.328 MHz
I2C: ready
monitor len: 00080100
Dear ALL,
Hah... with this patch it works:
diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S
index 5a7ae7e..cf3a59f 100644
--- a/arch/arm/cpu/arm926ejs/start.S
+++ b/arch/arm/cpu/arm926ejs/start.S
@@ -266,7 +266,7 @@ fixnext:
str r1, [r0]
Dear Heiko Schocher,
... but I don;t know if this is the right change! Better would
be to know, why the last entry in __rel_dyn_start is filled with
...
As an EOF marker, maybe?
Maybe the loop should be left by ble and a test for zero of an entry?
Umm ble seems wrong to me anyway:
Dear Heiko Schocher,
start = first entry, end = address AFTER last entry,
so it should be blt, or?
Yep. But I think, ble is right ... we should know, why this
entry is filled with
No, we want a loop through all entries:
start: 1st entry
2nd entry
...
last
for (p = start; p end; p += 8)
work;
and not
Give me some time, and I will complete this loop to do
relocation in C.
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Albert ARIBAUD schrieb:
Le 05/10/2010 11:39, Reinhard Meyer a écrit :
for (p = start; p end; p += 8)
work;
and not
Give me some time, and I will complete this loop to do
relocation in C.
Almost finished with it :)
Reinhard
Be careful, though, that you need a way to obtain
Dear Graeme Russ,
.globl _rel_dyn_start_ofs
_rel_dyn_start_ofs:
.word __rel_dyn_start - _start
.globl _rel_dyn_end_ofs
_rel_dyn_end_ofs:
.word __rel_dyn_end - _start
.globl _dynsym_start_ofs
_dynsym_start_ofs:
.word __dynsym_start - _start
get the values to C.
Odd, is
Dear All ;)
Umm... is my understanding correct that we can drop the whole
CONFIG_SYS_ARM_WITHOUT_RELOC stuff then, too?
I believe we're just changing the relocation solution, but we're not
changing the overall strategy regarding CONFIG_SYS_ARM_WITHOUT_RELOC.
We should not forget that right
Dear Albert ARIBAUD,
Le 05/10/2010 13:17, Reinhard Meyer a écrit :
Dear All ;)
Umm... is my understanding correct that we can drop the whole
CONFIG_SYS_ARM_WITHOUT_RELOC stuff then, too?
I believe we're just changing the relocation solution, but we're not
changing the overall strategy
---
arch/arm/cpu/arm926ejs/start.S |8 -
arch/arm/lib/board.c | 57 +++-
include/configs/top9000_9xe.h |1 +
3 files changed, 63 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S
Reinhard Meyer schrieb:
---
arch/arm/cpu/arm926ejs/start.S |8 -
arch/arm/lib/board.c | 57
+++-
include/configs/top9000_9xe.h |1 +
3 files changed, 63 insertions(+), 3 deletions(-)
PLEASE - this is only for study
Dear Albert ARIBAUD,
- pure ELF format (8 bytes per relocation plus .dynsym)
... already there, and then to be done:
- unified 32-bit format (half the size of pure ELF)
- unified 16-bit delta format (a fourth of the size of pure ELF)
Even an 8-bit delta format is possible:
use the value
Reinhard Meyer (1):
AT91: convert cpu.c to struct SoC access
arch/arm/cpu/arm926ejs/at91/cpu.c | 48 ++--
arch/arm/include/asm/arch-at91/at91_emac.h |2 +-
drivers/net/at91_emac.c| 22 +++---
drivers/serial/atmel_usart.c
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.
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
Supports most types that support Read-Id and the FM25H20.
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
drivers/mtd/spi/Makefile |1 +
drivers/mtd/spi/ramtron.c| 319 ++
drivers/mtd/spi/spi_flash.c |8
for JEDEC devices without and with extension bytes
for non JEDEC devices
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
drivers/mtd/spi/spi_flash.c | 137 +--
1 files changed, 93 insertions(+), 44 deletions(-)
diff --git a/drivers/mtd/spi
Dear Albert ARIBAUD,
include/configs/top9000_9xe.h |1 +
That's my board. Not in mainstream yet. Just sets the define there.
+#ifdef CONFIG_USE_C_RELOCATION
+/* TODO: check for identical source and destination */
+/* TODO: check for overlapping */
+/* copy image, including
Dear Graeme Russ,
On Wed, Oct 6, 2010 at 2:32 PM, Marek Vasutmarek.va...@gmail.com wrote:
Dne Út 5. října 2010 22:03:23 Wolfgang Denk napsal(a):
The logodl board has long been unmaintained and left broken.
As obviously nobody is interestedin that code any more, we may as well
remove it.
I wrote:
Dear Wolfgang Denk,
In message 4ca5d26d.2090...@emk-elektronik.de you wrote:
If this is really for all AT91 SoCs, then please feel free to
introduce a common define (CONFIG_SYS_AT91 ?) and use that. Eventually
you can clean up some other such #if's on the way.
That would have to be
Dear Mike Frysinger, All:)
On Tuesday, September 14, 2010 10:50:09 Reinhard Meyer wrote:
JEDEC types
non JEDEC types
this changelog is useless ... either make it say something, or just leave it
empty
+static int ramtron_common(struct spi_flash *flash,
+u32 offset, size_t
Dear Wolfgang Denk,
The Qs that remain now are:
1. currently I see about 8 CONFIG_AT91SAMxxx defines required
(not only 2 like above). The method is still undecided how to
handle this. Add CONFIG_AT91SAM9_FAMILY to common.h? Or put
all 8 defined() into global_data.h (would give 4 lines
Dear Wolfgang Denk,
I see the misunderstanding here:
It will be needed to replace the #if defined(CONFIG_AT91SAM9260) ||
defined(CONFIG_AT91SAM9XE) in global_data.h and a ton of similar
ocurrences like these:
That does not exist yet (its only in my local tree so far!)
Dear Wolfgang Denk,
Patch 1 will change the #if and introduce CONFIG_AT91SAM9_FAMILY
instead.
Patch 2 will fix at91/clock.c+timer.c
Maybe there is a misunderstanding here. I see three patches
1. introduce CONFIG_AT91SAM9_FAMILY to common.h
2. add an #ifdef CONFIG_AT91SAM9_FAMILY to
Dear Albert ARIBAUD,
Right now I can build (not run, mind you) u-boot for edminiv2 without
-fPIC/-fPIE, with -pie and a modified u-boot.lds and start.S. Almost all
of the .rel.dyn fixup entries are type 23, that is, relative to the base
address, which is good. However, here are about ten
Dear Vipin Kumar,
A writel to status_reg results in byte by byte writing
How do you know that? Disassembly? Bus snooping?
Disassembly
I agree with you. I always considered such behaviour of the ARM C
compiler a bug, and still do. However, people with better knowledge
of the ARm
Dear Wolfgang Denk, Vipin Kumar,
In message 4ca9acaa.2020...@st.com you wrote:
This writel results in writing byte by byte on the address pointed to by
status_reg.
This problem is visible with both gcc version 4.4.1 as well as 4.5.0
I bet this is on some ARM system?
Yes, it is on an ARM
Dear Wolfgang Denk,
I see the misunderstanding here:
It will be needed to replace the #if defined(CONFIG_AT91SAM9260) ||
defined(CONFIG_AT91SAM9XE) in global_data.h and a ton of similar
ocurrences like these:
That does not exist yet (its only in my local tree so far!)
Dear Heiko Schocher,
printenv, saveenv: works fine.
env print, evn save: make U-Boot hang. (then I must reset the board)
as I thought ... can you try following patch:
Not surprisingly, it makes env subcommands work on ARM/AT91, too:)
Thanks,
Reinhard
PS: I still get the *** Warning - bad
Hello,
before the relocation patches, and if relocation is disabled
(CONFIG_SYS_ARM_WITHOUT_RELOC)
board_init() is called _very_ early, before relocation.
With relocation enabled, board_init() is called after relocation and
when BSS is available.
--- Board maintainers should look at their
Dear Wolfgang Denk,
In message4ca9eb88.5000...@emk-elektronik.de you wrote:
1. The board's config file defines CONFIG_AT91FAMILY like this:
/* SoC */
#define CONFIG_ARM926EJS 1 /* ARM926EJS Core */
#define CONFIG_AT91FAMILY 1 /* it's a member of AT91 */
Dear Wolfgang Denk,
The general question, however was, if that approach is OK with you.
Well, I still prefer to have this added to a single, central location
instead to a large number of board config files.
AT91 does not have a really large number of config files.
However, if you have to
Hello Heiko,
I try to understand how the relocation process could handle pointers (to
functions or other data) in const or data sections.
Your code cannot know what is data and what is a pointer that needs
adjustment?
Best Regards,
Reinhard
___
U-Boot
Dear Albert ARIBAUD,
I try to understand how the relocation process could handle pointers (to
functions or other data) in const or data sections.
Your code cannot know what is data and what is a pointer that needs
adjustment?
Best Regards,
Reinhard
Hi Reinhart,
Short answer - the
Dear all,
thanks for all the info.
My AT91 boards will not use relocation for the time being, and if
relocation is god-like enforced I will find a way not to use it.
I don't need to spend 10% more code for all that trouble.
Reinhard
___
U-Boot mailing
Dear J. William Campbell,
On 10/2/2010 3:17 AM, Joakim Tjernlund wrote:
Hello Reinhard,
Reinhard Meyer wrote:
Dear Albert ARIBAUD,
I try to understand how the relocation process could handle pointers (to
functions or other data) in const or data sections.
Your code cannot know what is data
Dear Heiko Schocher,
In message4ca4aeff.3050...@denx.de you wrote:
If TEXT_BASE == relocation address it could be defined,
never tested.
If I think right, relocation address would vary with u-boot size,
so there seems no really reliable way to ensure above if is true.
Even worse, when it
Hello,
it seems, that with relocation enabled, some
data does not seem to get initialized properly:
w/o relocation:
mmci
mci: setting clock 194000 Hz, block size 512
mci: setting clock 194000 Hz, block size 512
mci: setting clock 194000 Hz, block size 512
mci: setting clock 194000 Hz, block
Dear Wolfgang Denk,
Dear Reinhard Meyer,
In message 4ca590e6.6070...@emk-elektronik.de you wrote:
it seems, that with relocation enabled, some
data does not seem to get initialized properly:
I rather suspect you have code running that violates the
pre-relocation restrictions (no bss
Dear Heiko Schocher,
Hmm.. mabe something with at91_clock_init()
This is called in arch_cpu_init(), and
at the end, clocks are stored in
arch/arm/cpu/arm926ejs/at91/clock.c
in static unsigned long vars ... as this code
runs before relocation, this seems to me as it
could be the reason
Dear Wolfgang Denk,
...which is, and always has been, illegal.
nitpick
it became illegal once u-boot for AT91 became required to be relocated
/nitpick
Not bd- but gd- which was made for exactly that purpose.
typedef struct global_data...
I will try that. And fix the whitespace error as
Dear Wolfgang Denk,
nitpick
it became illegal once u-boot for AT91 became required to be relocated
/nitpick
No, it has always been illegal. You might thave been lucky that in
your case the erros did not show up erarlier, but this does not change
anything.
Sorry, before recently there was
Dear Wolfgang Denk,
For the fix, I see an ugly multiline
#if defined(AT91SAM9260) || defined(AT91SAM9G20) || ...
coming into arch/arm/asm/global_data.h.
There is no common defined value for all AT91 SoCs that could be used.
If this is really for all AT91 SoCs, then please feel free to
I did the changes of adding the clock values to gd, and it became somewhat
better, but there are still issues pending:
1. NAND accesses cause raise: Signal # 8 caught
but still work, kernel boots normally.
2. environment is still invalid - when I boot the
CONFIG_SYS_ARM_WITHOUT_RELOC
Dear Wolfgang Denk,
In message 4ca5d26d.2090...@emk-elektronik.de you wrote:
If this is really for all AT91 SoCs, then please feel free to
introduce a common define (CONFIG_SYS_AT91 ?) and use that. Eventually
you can clean up some other such #if's on the way.
That would have to be set either
Dear Wolfgang Denk,
The environment issues still persist. I am at a loss
there now.
Observation: the old style commands setenv, printenv, etc.
work, but any env command except for env alone crashes.
OK. If printenv works and env print fails then it has nothing to
do with the environment
Dear Sergei Shtylyov,
+#ifdef I2C_ADDR_IGNORE_LIST
+unsigned char i2c_ignore_list[] = I2C_ADDR_IGNORE_LIST;
This array is aking to be *static*...
... and *const* as well ?
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
Hello,
after enabling relocation I get the following output:
U-Boot 2010.09-00106-g6e135b9-dirty (Sep 30 2010 - 16:57:43)
U-Boot code: 21F0 - 21F3C140 BSS: - 21F7D700
CPU: AT91SAM9XE
Crystal frequency: 18.432 MHz
CPU clock: 198.656 MHz
Master clock : 99.328 MHz
I2C:
Dear Stefano Babic,
1. should CONFIG_SKIP_RELOCATE_UBOOT be not defined anymore?
I had the same issue because I forget to remove it from my config file.
After dropping it, I got the u-boot prompt again ;-)
Thank you, that (partially) helped:
U-Boot 2010.09-00106-g6e135b9-dirty (Sep 30 2010 -
Dear Heiko Schocher,
Before the relocation: macb, enc and environment did work :)
I have to look into that issue later...
No spontaneous idea ... maybe something with gpio pins?
The relocation should ideally not affect that ;)
I suspect the initiallization now does not call all functions
Dear Can Aydin,
The reason this is an RFC is that unfortunately the hardware on these
chips does not permit indefinite SPI transactions on a given chip
select. A chip select is asserted only when a 'transaction length' has
been passed to the controller. Once the number of characters specified
Dear Wolfgang Denk, Can Aydin,
True, a GPIO pin could be re-purposed to serve as chip select, but that
would involve a soldering iron and a steady hand as the P1/P2xxRDB
That was not the question.
Reinhard asked if the SPI Chip Select Pins could be configured such so
that they can be
Dear Andreas Bießmann,
This patch also removes conditional nameing of at91_emac driver whether it's
connection to PHY is RMII or MII.
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
+ sprintf(dev-name, at91_emac);
Applied to u-boot-atmel/at91, with name shortened to emac.
Dear Andreas Bießmann,
This patch replaces the unnecessary waiting in at91emac_read() and
at91emac_write() by checking the IDLE flag.
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
Applied to u-boot-atmel/at91.
Thanks,
Reinhard
___
Dear Andreas Bießmann,
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
---
resent this patch cause of
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/83565/focus=83856
Applied to u-boot-atmel/at91.
Thanks,
Reinhard
___
U-Boot
Dear Alexander Stein,
When disabled the PIT runs until it reaches the CPIV value.
The Linux PIT driver stops the PIT and waits until it stopped. This can
take over 100ms. Simply stopping in u-boot isn't sufficient as the PIT
will still be running when Linux is waiting until it stopped.
So, we
Dear Mike Frysinger,
On Tuesday, September 21, 2010 01:21:46 Reinhard Meyer wrote:
well, now i cant reproduce the issue, cold or warm booting :/.
...
although, earlier i was testing when the sun was out and shining on the board
but now it's night, so maybe it's a cold-blooded part :x
Dear Mike Frysinger,
might want to check out the thread i started over a year ago:
[u-boot] core ticks/timer code
it delves into these internals and may help you here
-mike
Thanks for the hint, and sorry to have started the topic again ;)
However it seems no resolution has come up
Dear Wolfgang Denk,
In message 4c98536c.6010...@emk-elektronik.de you wrote:
For me it seems useful to keep both functions and have ticks
increment at a hardware-convenient rate.
If the hardware timer can be prescaled to increment at 1000 Hz that
is fine, but I see no immediate need for that.
Just to report on preliminary findings I had:
Rebasing my current TOP9000 port on u-boot/master compiles
and works fine.
Code size increased moderately from 223592 to 223976.
Rebasing my current TOP9000 port on u-boot/next compiles
after defining CONFIG_SYS_SDRAM_BASE and
Dear Albert ARIBAUD,
Le 21/09/2010 14:39, Reinhard Meyer a écrit :
Rebasing my current TOP9000 port on u-boot/next compiles
after defining CONFIG_SYS_SDRAM_BASE and CONFIG_SYS_INIT_SP_ADDR.
Code size increased heavyly from 223592 to 245544.
And U-Boot crashes instantly (I know there is more
Reinhard Meyer schrieb:
Therefore I strongly suggest that all extras (PIC) needed solely for
relocation
should be switchable OFF by a configuration option. Who does need that
relocation in the first place? For years ARM did work without it; why now
blowing up the code?
Sorry, to be precise
Stefan Roese schrieb:
Please note that this increase is not only because of the new ARM relocation
support, but the environment rework done by Wolfgang:
Yes, that, too. About 5.5k
next w/o relocation (#define CONFIG_SYS_ARM_WITHOUT_RELOC)
and w/o cache (#define CONFIG_SYS_NO_[DI]CACHE):
Dear Mike Frysinger,
On Monday, September 20, 2010 17:44:38 Mike Frysinger wrote:
finally got around to testing this. seems like the init needs some work.
if i power on the system (cold boot), boot Linux over the on-chip mac, and
let Linux program the enc part, it works fine under Linux.
Hello,
it is my understanding that get_ticks() shall return the count of
a free running (hardware) counter that increments by a total of
get_tbclk() every second. Both functions are long long.
I also understand that this counter does not necessarily increment at
a rate of CONFIG_SYS_HZ, but at a
Dear Wolfgang Denk, Lei Wen, Andy Fleming,
Dear Lei Wen,
In messageaanlktimaqttcjf52djf-ahdeffqbhfwyejd3024vw...@mail.gmail.com you
wrote:
How about merge this patch? :-)
I will wait for a pull request from the responsible custodian.
Maybe you should have put him on cc: ... (done
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
arch/arm/cpu/arm926ejs/at91/cpu.c | 32
1 files changed, 12 insertions(+), 20 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/at91/cpu.c
b/arch/arm/cpu/arm926ejs/at91/cpu.c
index 141a7d1..087fe95
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.
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.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
for JEDEC devices without and with extension bytes
for non JEDEC devices
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
drivers/mtd/spi/spi_flash.c | 137 +--
1 files changed, 93 insertions(+), 44 deletions(-)
diff --git a/drivers/mtd/spi
On 14.09.2010 16:53, Mike Frysinger wrote:
On Tuesday, September 14, 2010 10:50:08 Reinhard Meyer wrote:
for JEDEC devices without and with extension bytes
for non JEDEC devices
Signed-off-by: Reinhard Meyeru-b...@emk-elektronik.de
needs to be a blank line before s-o-b tags and friends
Dear Anatolij Gustschin,
The latter was already used by AT91.
Looking at your patch I just noticed that the AT91 version is not up to
date. It won't work for AT91SAM9XE. I had a better, struct access variant
in my tree but somehow due to rebasing I must have lost it...
I'll reconstruct it and
Dear Anatolij Gustschin,
This patch consolidates bootcount_{store|load} for ARM by
implementing a common version in arch/arm/lib/bootcount.c. This
code is now used by all ARM variants that currently have these
functions implemented.
Also supports two different bootcount versions:
a)
Dear William C. Landolina,
Reinhard - FYI, your 2010.09-rc1 SD/MMC patches work on an Atmel 9G45
evaluation kit. I customized the board and configuration files following the
directions in README.atmel_mci and everything works as expected. I included
the console output from a test boot
Dear Wolfgang Denk,
Please help testing, and check if all your relevant patches have been
included.
Rebasing worked without manual intervention, u-boot still compiles and
works for my board (at91sam9xe-based). Code size increased 0x20 bytes.
The following (published) patches are left ahead of
V3: further refinements:
- use priv member instead of container method
- allow setting of MAC address by write_hwaddr method
- avoid shutting down link between commands
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
drivers/net/Makefile |1 +
drivers/net/enc28j60.c | 978
for JEDEC devices without and with extension bytes
for non JEDEC devices
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
drivers/mtd/spi/spi_flash.c | 139 +--
1 files changed, 94 insertions(+), 45 deletions(-)
diff --git a/drivers/mtd/spi
401 - 500 of 735 matches
Mail list logo
