Detlev Zundel d...@denx.de wrote:
Problem is that in order to make the CFI driver work on avr32, we need
to change the map_physmem() macro to return the physical address
unchanged.
I see. And I presume you cannot tell the situation apart inside
map_physmem?
I don't think so. How do you
noticed on certain boards
Haavard Skinnemoen (3):
avr32: Print unrelocated PC on exception
avr32: Use uncached() macro to get an address for SDRAM init
avr32: Add simple paging support
arch/avr32/cpu/at32ap700x/Makefile |2 +-
arch/avr32/cpu/at32ap700x/mmu.c
() macro will return an address which will
always cause uncached accessed to be made. Since this happens in the
board code, using avr32-specific features should be ok, and will allow
the SDRAM initialization to keep working.
Signed-off-by: Haavard Skinnemoen haavard.skinnem...@atmel.com
---
board
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.skinnem...@atmel.com
---
arch/avr32/cpu
' command work again on ATNGW100 and other boards
using the CFI driver, hopefully without breaking any rules.
Signed-off-by: Haavard Skinnemoen haavard.skinnem...@atmel.com
---
arch/avr32/cpu/at32ap700x/Makefile |2 +-
arch/avr32/cpu/at32ap700x/mmu.c| 78
Detlev Zundel d...@denx.de wrote:
So this patch replaces a construct which seems to be valid over all
architectures by a construct which is only used in avr32, right? It
also deletes the explicit statement that such a mapping is not needed
any further.
Problem is that in order to make the
Mike Frysinger vap...@gentoo.org wrote:
On Sun, Aug 8, 2010 at 9:27 PM, Haavard Skinnemoen wrote:
Mike Frysinger vap...@gentoo.org wrote:
explicitly cc-ing the atmel guys just so there's no surprise when
at91/avr32
have been handled over to someone else without their explicit ACK
Wolfgang Denk w...@denx.de wrote:
Dear Haavard Skinnemoen,
In message 20100809132949.43c81...@hskinnemoen-d830 you wrote:
But it does seem kind of rude to just hand everything off without
Cc'ing any of the maintainers in question. Perhaps they would respond
more quickly if people
Wolfgang Denk w...@denx.de wrote:
Dear Haavard Skinnemoen,
In message 20100809181318.5ec2a...@hskinnemoen-d830 you wrote:
First, I have poked them a number of times, both on and off list.
I haven't received any such pokes from you in a long time.
I'm not talking about you here
Mike Frysinger vap...@gentoo.org wrote:
explicitly cc-ing the atmel guys just so there's no surprise when at91/avr32
have been handled over to someone else without their explicit ACK ...
So...what exactly are you Cc'ing us on?
Haavard
___
U-Boot
Wolfgang Denk w...@denx.de wrote:
Can you please try and rebase this code on top of Heiko's ARM rework
patches, i. e. with cache and relocation support?
See
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/81825/focus=82142
My intention is that after -rc1 has been released (i. e.
Simply include the generic version. We could optimize this a bit more,
as unaligned 32-bit accesses are ok on AP7, but let's make it work
first.
Signed-off-by: Haavard Skinnemoen haavard.skinnem...@atmel.com
---
arch/avr32/include/asm/unaligned.h |1 +
1 files changed, 1 insertions(+), 0
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.skinnem...@atmel.com
---
arch/avr32/cpu
this fix, v2008.10 is the latest usable release.
The patches are based on v2010.06, but it merges fine with the latest
upstream master. The AVR32 master branch currently contains a workaround
which I plan to revert if these patches are acceptable.
Haavard Skinnemoen (3):
avr32: Add missing
' command work again on ATNGW100 and other boards
using the CFI driver, hopefully without breaking any rules.
Signed-off-by: Haavard Skinnemoen haavard.skinnem...@atmel.com
---
arch/avr32/cpu/at32ap700x/Makefile |2 +-
arch/avr32/cpu/at32ap700x/mmu.c| 78
Bas Mevissen ab...@basmevissen.nl wrote:
On Mon, 2 Aug 2010 14:06:26 +0200, Haavard Skinnemoen
haavard.skinnem...@atmel.com wrote:
This series fixes a trivial build issue, as well as a longstanding
problem with the 'saveenv' command on ATNGW100.
Is that the same problem that makes
Wolfgang Denk w...@denx.de wrote:
I think that the issue should be fixed by making sure FLASH is detected
at 0x and NOT at 0xa000, correct?
This has been discussed in one of the longer and more heated
discussions on that list; see thread starting here:
Becky Bruce becky.br...@freescale.com wrote:
I'm not really deep enough in the implementation details and thus
would appreciate comments for example from Becky and Stefan. In my
opinion, turning on or off the cache on an address range should be
implemented as outlined above, i. e. as an
Mark Jackson mpfj-l...@mimc.co.uk wrote:
The functions could also return (architecture dependant) a remapped
address to be used, then we could support:-
Right, and that is the important part: If I'm allowed to return a
remapped address, this API will be trivial to implement on AVR32. If
not, it
Wolfgang Denk w...@denx.de wrote:
Dear Haavard Skinnemoen,
In message 20090831155327.62b58...@hskinnemoen-d830 you wrote:
Possibly. But it means even more effort and even larger code, so I'm
not exactly happy about it.
Really? Sorry if I'm asking dumb questions - I don't know AVR32
Becky Bruce becky.br...@freescale.com wrote:
Sorry, guys, I'm still not clear on what's going on. Haavard, did you
expect each call to flash_map to return a different VA each time (i.e.
you're trying to do some sort of dynamic mapping), or are you just
calling it to get the VA that
Becky Bruce becky.br...@freescale.com wrote:
Becky: the fact that Haavard's code is breaking is not considered an
indication of a deficiency in his code.
I'm not calling the code deficient, just a bit inconsistent, and it
wasn't clear to me why. When code uses the same value 1) by
Stefan Roese s...@denx.de wrote:
On Tuesday 01 September 2009 10:57:52 Haavard Skinnemoen wrote:
Well, usually we run with IC on and with DC off, usually because
quite a number of drivers and other code do not use proper I/O
accessors yet, and/or because it's easier
Wolfgang Denk w...@denx.de wrote:
Dear Haavard Skinnemoen,
Like I explained in an earlier mail, the default setup includes a 1:1
mapping of the lowest addresses, but it's cacheable. The default setup
also includes an uncached mapping of the same memory at a higher
virtual address.
You
Wolfgang Denk w...@denx.de wrote:
Dear Haavard Skinnemoen,
In message 20090901123829.55fcb...@hskinnemoen-d830 you wrote:
And that is EXACTLY why I'm trying to advocate: Keep the additional
complexity (which can be kept to a minimum) localized to a handful of
drivers, and don't change
Wolfgang Denk w...@denx.de wrote:
Dear Haavard Skinnemoen,
In message 20090901134257.59961...@hskinnemoen-d830 you wrote:
complexity (which can be kept to a minimum) localized to a handful of
drivers, and don't change the command line interface or the board
configuration
Wolfgang Denk w...@denx.de wrote:
Well, that was the part of me saying before: as long as it doesn't
hurt others. We don't want to add that complexity to U-Boot as noone
needs it.
Right. I forgot that nobody actually needs this.
Fuck it, I'm out.
Haavard
Thiago A. Corrêa thiago.cor...@gmail.com wrote:
Hi,
I don't want to intrude too much into the discussion, but I would
like to offer a small bit of info
Oh, I wish more people would intrude ;-)
On Tue, Sep 1, 2009 at 10:23 AM, Haavard
Skinnemoenhaavard.skinnem...@atmel.com wrote:
It
Hans-Christian Egtvedt hans-christian.egtv...@atmel.com wrote:
Yeah...I'm unsure myself. The system will boot, but the 'saveenv'
command doesn't work...so while I really want to fix this issue
_properly_, I'm not sure if there's enough time to do that before the
next release.
Did
On Fri, 28 Aug 2009 14:58:15 -0500
Becky Bruce becky.br...@freescale.com wrote:
FYI, before the patch, the CFI driver was sometimes doing the map,
but IIRC it was also abusing the physical address, treating it as
a virtual address without mapping it.
In that case, those places should have been
On Sat, 29 Aug 2009 13:39:02 +0200
Stefan Roese s...@denx.de wrote:
I think too, that revering the patch in question is not the right
solution for this problem in the current stage. But I have to admit
that I don't have enough insight into your platform to come up with
another good idea
On Sun, 30 Aug 2009 20:11:01 +0200
Wolfgang Denk w...@denx.de wrote:
Dear Haavard Becky,
In message 20090830173640.2af9c...@siona you wrote:
The only way for that to work
is when VA=PA (or, depending on what you were doing with the
address,
Well, VA==PA is the default setting
Hi Wolfgang,
Please pull
git://git.denx.de/u-boot-avr32.git master
to receive the following fix for a fairly longstanding and annoying
ATNGW100 bug.
Haavard Skinnemoen (1):
atngw100: Use virtual address in CONFIG_ENV_ADDR
include/configs/atngw100.h |2 +-
1 files changed, 1
-by: Haavard Skinnemoen haavard.skinnem...@atmel.com
---
include/configs/atngw100.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/configs/atngw100.h b/include/configs/atngw100.h
index 4ed5514..9777ec0 100644
--- a/include/configs/atngw100.h
+++ b/include/configs/atngw100
Mark Jackson mpfj-l...@mimc.co.uk wrote:
Haavard Skinnemoen wrote:
Ever since the CFI driver was rewritten to use virtual addresses, thus
eliminating the whole point of the map_physmem() macro, ATNGW100 has
been broken like this:
How about other boards (like the MIMC200) ?
Aren't
Mark Jackson mpfj-l...@mimc.co.uk wrote:
Haavard Skinnemoen wrote:
Possibly, but NGW100 is the only one which I've seen reports about.
STK1000 is safe since it doesn't use the CFI driver.
I did kinda report this in the thread JFFS2 scanning bug, and
the triple-revert patch you posted
Wolfgang Denk w...@denx.de wrote:
#define CONFIG_ENV_IS_IN_FLASH 1
#define CONFIG_ENV_SIZE65536
-#define CONFIG_ENV_ADDR(CONFIG_SYS_FLASH_BASE +
CONFIG_SYS_FLASH_SIZE - CONFIG_ENV_SIZE)
+#define CONFIG_ENV_ADDR
Kumar Gala ga...@kernel.crashing.org wrote:
Reverting 09ce9921a7d8b1ce764656b14b42217bbf4faa38 would bring things
back to the way they were, and fix both the saveenv problem and the
jffs2 problem.
Such a revert would break other boards that now expect the new
behavior (like all the
Michal Simek wrote:
Hi Custodians,
Do you have any problem with this asm-generic/errno.h patch?
Patch is available in u-boot-microblaze.git asm-generic branch.
Looks good to me too.
Haavard
___
U-Boot mailing list
U-Boot@lists.denx.de
Mike Frysinger wrote:
Obviously the second item here will become void if vendor lockout of
updates becomes common. So what will be left of the essential freedoms?
I can study the code, I can modify it, but I am not allowed to run it.
Excellent.
and this is why i dislike the GPLv3.
Wolfgang Denk wrote:
In message 20090707135141.79798...@hskinnemoen-d830 you wrote:
While I think fighting for extensible and hackable hardware is good,
I think a software license is the wrong way to go about it. Let's stick
to the proven model of GPLv2: You can use my software if I get
Wolfgang Denk wrote:
I'm only talking about software (code and data) here. If I cannot
change (or just rebuild) the (Free!) software any more because to
actually run it I need some secret data (like a signature) then this
is still a software problem. One that can be prevented by
Jean-Christophe PLAGNIOL-VILLARD wrote:
for at91 the GUARD_TIME is 1 and IIRC it's lcd specific
You just contradicted yourself.
The Guard time is the number of empty frames (with control signals
enabled but no data) to wait before starting to send valid data to the
display.
Setting it slightly
Jean-Christophe PLAGNIOL-VILLARD wrote:
On 08:53 Tue 23 Jun , Haavard Skinnemoen wrote:
Jean-Christophe PLAGNIOL-VILLARD wrote:
for at91 the GUARD_TIME is 1 and IIRC it's lcd specific
You just contradicted yourself.
at91 boards
Ok, I see.
The Guard time is the number
Mark Jackson wrote:
User-Agent: Thunderbird 2.0.0.21 (X11/20090409)
(...)
My patch has been mangled ... there's an extra space at the start of each
unchanged patch line.
Read about how to make Thunderbird behave here:
On Mon, 22 Jun 2009 16:31:20 +0100
Mark Jackson mpfj-l...@mimc.co.uk wrote:
Haavard Skinnemoen wrote:
Mark Jackson wrote:
User-Agent: Thunderbird 2.0.0.21 (X11/20090409)
(...)
My patch has been mangled ... there's an extra space at the start
of each unchanged patch line
Jean-Christophe PLAGNIOL-VILLARD wrote:
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Cc: Haavard Skinnemoen haavard.skinnem...@atmel.com
Acked-by: Haavard Skinnemoen haavard.skinnem...@atmel.com
___
U-Boot mailing list
U-Boot
On Fri, 27 Mar 2009 23:30:19 +0100
Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote:
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index 631b969..175d82a 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -1788,13 +1788,10 @@ static void
Jean-Christophe PLAGNIOL-VILLARD wrote:
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Cc: Ben Warren biggerbadder...@gmail.com
Cc: Haavard Skinnemoen haavard.skinnem...@atmel.com
Acked-by: Haavard Skinnemoen haavard.skinnem...@atmel.com
Mike Frysinger wrote:
- /* Up to 2 seconds */
- ret = stmicro_wait_ready(flash, 2 * CONFIG_SYS_HZ);
+ ret = stmicro_wait_ready(flash, SPI_FLASH_PAGE_ERASE_TIMEOUT);
50 ms is an awful lot less than 2 seconds. Sure this is safe?
Haavard
Mike Frysinger wrote:
On Thursday 02 April 2009 07:20:13 Haavard Skinnemoen wrote:
Mike Frysinger wrote:
- /* Up to 2 seconds */
- ret = stmicro_wait_ready(flash, 2 * CONFIG_SYS_HZ);
+ ret = stmicro_wait_ready(flash, SPI_FLASH_PAGE_ERASE_TIMEOUT);
50 ms
problems where none
otherwise exist.
Signed-off-by: Mike Frysinger vap...@gentoo.org
CC: Haavard Skinnemoen haavard.skinnem...@atmel.com
Acked-by: Haavard Skinnemoen haavard.skinnem...@atmel.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http
Mike Frysinger wrote:
since there doesnt seem to be a proper location for spi flash patches to
accumulate, do you mind if i start up a branch to accumulate the current set
?
No, please feel free to do that.
i dont know how active you want to be with the sf subsystem ... or maybe
you're
Mike Frysinger wrote:
Signed-off-by: Mike Frysinger vap...@gentoo.org
CC: Haavard Skinnemoen haavard.skinnem...@atmel.com
Looks good to me.
Acked-by: Haavard Skinnemoen haavard.skinnem...@atmel.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http
Mike Frysinger wrote:
The common SPI flash code reads the idcode and passes it down to the SPI
flash driver, so there is no need to read it again ourselves.
Signed-off-by: Mike Frysinger vap...@gentoo.org
CC: Haavard Skinnemoen haavard.skinnem...@atmel.com
CC: Jason McMullan mcmul
it always reads 5 id
bytes from all flashes.
Signed-off-by: Mike Frysinger vap...@gentoo.org
CC: Mingkai Hu mingkai...@freescale.com
CC: Haavard Skinnemoen haavard.skinnem...@atmel.com
Yes, that's much better. But perhaps you should pass the last two bytes
to the debug() call a bit further down
Mike Frysinger wrote:
Signed-off-by: Mike Frysinger vap...@gentoo.org
CC: Haavard Skinnemoen haavard.skinnem...@atmel.com
Acked-by: Haavard Skinnemoen haavard.skinnem...@atmel.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de
Jean-Christophe PLAGNIOL-VILLARD wrote:
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Applied, thanks
Haavard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
, so I had to beat the tree back into shape from time to time.
Gunnar Rangoy (1):
AVR32: Make GPIO implmentation cpu dependent
Haavard Skinnemoen (15):
avr32: Update README
avr32: data_bits should reflect the actual number of data bits
avr32: refactor the portmux/gpio code
.
Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
Ack-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Haavard is ok for you too?
Sure.
Acked-by: Haavard Skinnemoen haavard.skinnem...@atmel.com
___
U-Boot mailing list
U-Boot
Jean-Christophe PLAGNIOL-VILLARD wrote:
Latest upstream master builds just fine here...though the last release
may be broken because I pushed the fix too late.
Ah, I see the avr32 master branch is still broken. I've fixed it by
pulling from mainline.
I've try the next branch and it's
Jean-Christophe PLAGNIOL-VILLARD wrote:
make[1]: In file included from clk.c:24:
/private/u-boot-arm/include/asm/io.h:129: error: conflicting types for
'virt_to_phys'
/private/u-boot-arm/include/asm/io.h:80: error: previous definition of
'virt_to_phys' was here
Haavard could you take a
Jean-Christophe PLAGNIOL-VILLARD wrote:
introduce two new weak functions board_bdinfo and cpu_bdinfo to allow
board and cpu to print more information
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Cc: Haavard Skinnemoen haavard.skinnem...@atmel.com
Cc: Mike Frysinger
Wolfgang Denk wrote:
I have the following patches still marked as open in my list. Could
you please have a look...
Sure. Would those patches be acceptable now or should I hold them off
until the next merge window?
Haavard
___
U-Boot mailing list
Gunnar Rangoy wrote:
From: Olav Morken olav...@gmail.com
The AT32UC3A series of processors doesn't contain any cache, and issuing
cache control instructions on those will cause an exception. This commit
makes cacheflush.h arch-dependent in preparation for the AT32UC3A-support.
Gunnar Rangoy wrote:
From: Olav Morken olav...@gmail.com
The AVR32A architecture (which AT32UC3A-series is based on) has a
different memory layout than the AVR32B-architecture. This patch moves
addrspace.h to an arch-dependent directory in preparation for
AT32UC3A-support. It also moves
Gunnar Rangoy wrote:
There are some differences in the implementation of GPIO in the
at32uc chip compared to the ap700x series.
Signed-off-by: Gunnar Rangoy gun...@rangoy.com
Signed-off-by: Paul Driveklepp pauldrivekl...@gmail.com
Signed-off-by: Olav Morken olav...@gmail.com
Applied to
Gunnar Rangoy wrote:
From: Olav Morken olav...@gmail.com
The AT32UC3A0512ES chip has a bug when disabling interrupts. As a
workaround, two NOPs can be inserted.
Signed-off-by: Gunnar Rangoy gun...@rangoy.com
Signed-off-by: Paul Driveklepp pauldrivekl...@gmail.com
Signed-off-by: Olav
Mark Jackson wrote:
Added code to setup the extra Flash and FRAM chip selects as used on the
MIMC200 board.
V2 moves the init code from the common cpu.c file into the board specific
setup file.
Signed-off-by: Mark Jackson m...@mimc.co.uk
Applied to mimc200 after fixing up some
Mark Jackson wrote:
Haavard Skinnemoen wrote:
Mark Jackson wrote:
We do NOT want to do everything that is possible, but only what is
reasonable.
Exactly ... otherwise where do you stop ? JPG, GIF, TIFF, PNG, etc ?
We're *only* meant to be showing a simply boot up image (not view
Mark Jackson wrote:
We do NOT want to do everything that is possible, but only what is
reasonable.
Exactly ... otherwise where do you stop ? JPG, GIF, TIFF, PNG, etc ?
We're *only* meant to be showing a simply boot up image (not view lots
of different sized photos or movies !!), in a
Ben Warren wrote:
Jean-Christophe PLAGNIOL-VILLARD wrote:
make sense
so I'll put a 10Mpbs phy personnaly instead or a 10/100 that can be put in a
10 mode instead to avoid to manage it in the code
I haven't shopped for PHYs in a while, but imagine it's probably hard to
find one
Jean-Christophe PLAGNIOL-VILLARD wrote:
On the EVK1100 board, the CPU (UC3A0512) is connected to the PHY via an
RMII bus. This requires the CPU clock to be at least 50 MHz.
Unfortunately, the chip on current EVK1100 boards may be unable to run
at more than 50 MHz, and with the oscillator
Jean-Christophe PLAGNIOL-VILLARD wrote:
On 22:36 Sat 17 Jan , Jean-Christophe PLAGNIOL-VILLARD wrote:
Hi all,
AVR32 AT91 share a lot of IP as networking for example (macb)
so it will the same in the u-boot drivers
In consequence these common drivers will need ack
Hi Wolfgang,
Please pull
git://git.denx.de/u-boot-avr32.git master
to receive the following build fix for avr32 (all boards are affected).
Haavard Skinnemoen (2):
avr32: Remove second definition of virt_to_phys()
Merge branch 'fixes'
include/asm-avr32/io.h |9 ++---
1
Kumar Gala wrote:
On Dec 3, 2008, at 11:04 PM, Becky Bruce wrote:
include/flash.h was commented to say that the address in
flash_info-start was a physical address. However, from u-boot's
point of view, and looking at most flash code, it makes more
sense for this to be a virtual
Kumar Gala wrote:
As I look at this we really need to understand what Haavard was trying
to get with:
commit 12d30aa79779c2aa7a998bbae4c075f822a53004
Author: Haavard Skinnemoen hskinnem...@atmel.com
Date: Thu Dec 13 12:56:34 2007 +0100
cfi_flash: Use map_physmem
Ulf Samuelsson wrote:
ons 2009-01-07 klockan 21:56 +0100 skrev Jean-Christophe
PLAGNIOL-VILLARD:
Hi,
The AT91 arch use a at45 driver design to be show as a parallel flash
but it's a spi flash.
Haavard add a new spi flash framework which support the dataflash
so
Mike Frysinger wrote:
in your original drivers/mtd/spi/spi_flash.c commit, you had this:
#ifdef CONFIG_SPI_FLASH_SPANSION
case 0x01:
flash = spi_flash_probe_spansion(spi, idcode);
break;
#endif
does that mean you have a spansion driver sitting around but it just wasnt
it perfectly clear what the value means.
Acked-by: Haavard Skinnemoen haavard.skinnem...@atmel.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
structures so that things work out.
Signed-off-by: Brad Bozarth bfli...@yumbrad.com
Signed-off-by: Mike Frysinger vap...@gentoo.org
CC: Haavard Skinnemoen haavard.skinnem...@atmel.com
Acked-by: Haavard Skinnemoen haavard.skinnem...@atmel.com
___
U
Kumar Gala wrote:
/* virt_to_phys will only work when address is in P1 or P2 */
-static __inline__ unsigned long virt_to_phys(volatile void *address)
+static inline phys_addr_t virt_to_phys(volatile void *address)
{
Is the volatile really needed?
The problem is that the 'packet'
Kumar Gala wrote:
Lets go w/volatile for now and worry about this post v2009.01
Sounds good to me.
Haavard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
From: Haavard Skinnemoen haavard.skinnem...@atmel.com
Date: Wed, 17 Dec 2008 16:43:18 +0100
Subject: [PATCH] avr32: Remove second definition of virt_to_phys()
The second definition introduced by 65e43a1063 conflicts with the
existing one.
Also, convert the existing definition to use phys_addr_t
in SPI flash in this
setup would probably brick the board as the rest of the sector tends to
contain actual U-Boot data/code.
Signed-off-by: Mike Frysinger [EMAIL PROTECTED]
Makes sense to me. Assuming this is how other types of flash work,
Acked-by: Haavard Skinnemoen [EMAIL PROTECTED
Wolfgang Denk [EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED] you wrote:
Due to a bug with the SDRAM-controller, running code from the SDRAM is
impossible. This patch disables relocation of the command table on those
chips.
You are aware that this is dangerous, as it will
Wolfgang Denk [EMAIL PROTECTED] wrote:
Dear Olav Morken,
In message [EMAIL PROTECTED] you wrote:
This patch adds support for the AT32UC3A0xxx chips.
Signed-off-by: Gunnar Rangoy [EMAIL PROTECTED]
Signed-off-by: Paul Driveklepp [EMAIL PROTECTED]
Signed-off-by: Olav Morken [EMAIL
Piotr Ziecik [EMAIL PROTECTED] wrote:
Export flash_sector_size() function from drivers/mtd/cfi_flash.c.
Signed-off-by: Piotr Ziecik [EMAIL PROTECTED]
Why?
Haavard
___
U-Boot mailing list
U-Boot@lists.denx.de
functions are needed here.
To enable this weak functions you need to define
CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS in your board config header.
Otherwise the old default functions will be used resulting
in smaller code.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
Acked-by: Haavard Skinnemoen
Mike Frysinger [EMAIL PROTECTED] wrote:
On Monday 17 November 2008 16:17:54 Graeme Russ wrote:
Should I declare these functions as weak in the core i386 code and use a
config #define to override or should I seperate the functions out into
seperate source files and use conditional
Wolfgang Denk [EMAIL PROTECTED] wrote:
+static inline unsigned long get_hsb_clk_rate(void)
+{
+ //TODO HSB is always the same as cpu-rate
---^^
+ return MAIN_CLK_RATE CFG_CLKDIV_CPU;
Simply removing this comment should be fine.
Haavard
Olav Morken [EMAIL PROTECTED] wrote:
This is a patch series which adds support for the ATEVK1100 evaluation
board[1], and the AT32UC3A0xxx[2] microcontrollers used on that board.
The patch series is based on avr32/next.
I've applied this and the other series you posted to the 'evk1100'
branch
Wolfgang Denk [EMAIL PROTECTED] wrote:
Dear Haavard Skinnemoen,
In message [EMAIL PROTECTED] you wrote:
I've applied this and the other series you posted to the 'evk1100'
branch in
git://git.denx.de/u-boot-avr32.git evk1100
Please submit incremental patches addressing
Stefan Roese [EMAIL PROTECTED] wrote:
Old version without weak aliases:
textdata bss dec hex filename
280964 20232 50788 351984 55ef0 ./u-boot
New version with weak aliases:
textdata bss dec hex filename
280520 20232 50788 351540 55d34
Stefan Roese [EMAIL PROTECTED] wrote:
I could do it this way, sure. But how about this version:
static void __flash_write8(u8 value, void *addr)
{
__raw_writeb(value, addr);
}
...
#ifdef CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS
void flash_write8(u8 value, void
Jean-Christophe PLAGNIOL-VILLARD [EMAIL PROTECTED] wrote:
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD [EMAIL PROTECTED]
Acked-by: Haavard Skinnemoen [EMAIL PROTECTED]
I'm a bit out of sync at the moment. Wolfgang, can you apply it
directly?
diff --git a/lib_avr32/bootm.c b/lib_avr32
Jean-Christophe PLAGNIOL-VILLARD [EMAIL PROTECTED] wrote:
This patch trades off the removal of most of the #ifdef ugly for
a lot of duplication. Which is the lesser of two evils?
Only 4 archs share actually the same code avr32, i386, mips and sh
which actually I've plan to modify for sh
Antonio R. Costa [EMAIL PROTECTED] wrote:
As we agreed with Haavard I'll try to make a general SDHC patch for all
Atmel platform soon.
Note that there's a generic MMC framework in the works:
http://www.nabble.com/-U-Boot---PATCH-00-10--Add-MMC-Framework-td20256840.html
which we should
Andy Fleming [EMAIL PROTECTED] wrote:
diff --git a/include/asm-avr32/arch-at32ap700x/mmc.h
b/include/asm-avr32/arch-at32ap700x/mmc.h
deleted file mode 100644
index 9caba91..000
--- a/include/asm-avr32/arch-at32ap700x/mmc.h
+++ /dev/null
-struct mmc_cid {
-struct mmc_csd
-#define
Andy Fleming [EMAIL PROTECTED] wrote:
Here's a new framework (based roughly off the linux one) for managing
MMC controllers. It handles all of the standard SD/MMC transactions,
leaving the host drivers to implement only what is necessary to
deal with their specific hardware.
This also
1 - 100 of 153 matches
Mail list logo
