Detlev Zundel 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 pro
Detlev Zundel 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 CFI driver
veenv' command work again on ATNGW100 and other boards
using the CFI driver, hopefully without breaking any rules.
Signed-off-by: Haavard Skinnemoen
---
arch/avr32/cpu/at32ap700x/Makefile |2 +-
arch/avr32/cpu/at32ap700x/mmu.c| 78
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
---
arch/avr32/cpu/exception.c |3 ++-
1
() 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
---
board/atmel/atngw100/atngw100.c
tion issue 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/at32ap
Wolfgang Denk 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
Wolfgang Denk 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 wo
Mike Frysinger wrote:
> On Sun, Aug 8, 2010 at 9:27 PM, Haavard Skinnemoen wrote:
> > Mike Frysinger wrote:
> >> explicitly cc-ing the atmel guys just so there's no surprise when
> >> at91/avr32
> >> have been handled over to someone else without t
Wolfgang Denk 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. when
Mike Frysinger 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 mailing list
U-Boot
Bas Mevissen wrote:
> On Mon, 2 Aug 2010 14:06:26 +0200, Haavard Skinnemoen
> 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 f
veenv' command work again on ATNGW100 and other boards
using the CFI driver, hopefully without breaking any rules.
Signed-off-by: Haavard Skinnemoen
---
arch/avr32/cpu/at32ap700x/Makefile |2 +-
arch/avr32/cpu/at32ap700x/mmu.c| 78
2. Without
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: A
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
---
arch/avr32/cpu/exception.c |3 ++-
1
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
---
arch/avr32/include/asm/unaligned.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
create
[resending because the mailing list was accidentally dropped from Cc]
Reinhard Meyer wrote:
> I would be willing to help solve the issue/dispute.
Thanks.
> Correct me if I am wrong:
>
> 1. The issue seems to be the requirement/wish by Wolfgang Denk that
> virtual and physical addresses of fla
Wolfgang Denk 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:
> http://thread.gmane.org/gm
Mark Jackson 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 will be quite di
Becky Bruce 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 operation changing t
Thiago A. Corrêa 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
> Skinnemoen wrote:
> >> It would be a
Wolfgang Denk 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
_
Wolfgang Denk 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
Wolfgang Denk 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 ha
Wolfgang Denk 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
>
Stefan Roese 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 b
Becky Bruce 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 mapping
> it and 2)
Becky Bruce 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 corresponds to some PA, sin
Wolfgang Denk 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&#
Wolfgang Denk wrote:
> Dear Haavard Skinnemoen,
>
> In message <20090830224218.10f14...@siona> you wrote:
> >
> > > Well, VA==PA is the default setting for U-Boot that shall be used for
> > > all systems, unless it is really impossible on a board to impl
Hans-Christian Egtvedt 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 you test loading somet
On Sun, 30 Aug 2009 20:30:59 +0200
Wolfgang Denk wrote:
> Dear Haavard Skinnemoen,
>
> In message <20090828105050.0ddb0...@hskinnemoen-d830> you wrote:
> >
> > Please pull
> >
> > git://git.denx.de/u-boot-avr32.git master
> >
> > to rece
On Sun, 30 Aug 2009 20:11:01 +0200
Wolfgang Denk 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 se
On Sat, 29 Aug 2009 13:39:02 +0200
Stefan Roese 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 quickly.
Yea
On Fri, 28 Aug 2009 14:58:15 -0500
Becky Bruce 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 fixed, no?
> The o
Kumar Gala 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 36-bit physical cf
Wolfgang Denk 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(0xa00
Mark Jackson 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
Mark Jackson 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
em.
Signed-off-by: Haavard Skinnemoen
---
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.
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
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
http:/
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
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 softwar
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
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 board
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
On Mon, 22 Jun 2009 16:31:20 +0100
Mark Jackson 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 spac
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:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=b
Jean-Christophe PLAGNIOL-VILLARD wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
> Cc: Haavard Skinnemoen
Acked-by: Haavard Skinnemoen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Wolfgang Denk wrote:
> > component X is always supposed to come before component Y, that can be
> > done with different levels of initcalls, or just by arranging the
> > makefiles appropriately (with a comment warning people not to change it).
>
> The problem is that there is no such fix order.
On Fri, 27 Mar 2009 23:30:19 +0100
Jean-Christophe PLAGNIOL-VILLARD 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 flash_fixup_atmel(flash
Jean-Christophe PLAGNIOL-VILLARD wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
> Cc: Ben Warren
> Cc: Haavard Skinnemoen
Acked-by: Haavard Skinnemoen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/l
likely hood of causing problems where none
> otherwise exist.
>
> Signed-off-by: Mike Frysinger
> CC: Haavard Skinnemoen
Acked-by: Haavard Skinnemoen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
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
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:
> 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
>
havior where it always reads 5 id
> bytes from all flashes.
>
> Signed-off-by: Mike Frysinger
> CC: Mingkai Hu
> CC: Haavard Skinnemoen
Yes, that's much better. But perhaps you should pass the last two bytes
to the debug() call a bit further down too?
I guess it'
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
> CC: Haavard Skinnemoen
> CC: Jason McMullan
> CC: TsiChung Liew
Looks re
Mike Frysinger wrote:
> Signed-off-by: Mike Frysinger
> CC: Haavard Skinnemoen
Looks good to me.
Acked-by: Haavard Skinnemoen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Mike Frysinger wrote:
> Signed-off-by: Mike Frysinger
> CC: Haavard Skinnemoen
Acked-by: Haavard Skinnemoen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
fs in driver: we manage a
> > configuration variable.
> >
> > Signed-off-by: Nicolas Ferre
> Ack-by: Jean-Christophe PLAGNIOL-VILLARD
>
> Haavard is ok for you too?
Sure.
Acked-by: Haavard Skinnemoen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
ge
windows, 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
Jean-Christophe PLAGNIOL-VILLARD wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
Applied, thanks
Haavard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/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
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 ?
> >
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
Applied to mimc200 after fixing up some whitespace dama
Mark Jackson wrote:
> Change the MIMC200 startup code to use the built-in (rather than
> hard-coded) funtions for setting up gclk outputs.
>
> We'll also move the code to the new, more-appropriate
> board_postclk_init() routine.
>
> Signed-off-by: Mark Jackson
Applied to mimc200 and merged into
Gunnar Rangoy wrote:
> From: Olav Morken
>
> The AT32UC3A0512ES chip has a bug when disabling interrupts. As a
> workaround, two NOPs can be inserted.
>
> Signed-off-by: Gunnar Rangoy
> Signed-off-by: Paul Driveklepp
> Signed-off-by: Olav Morken
Applied to evk1100-prep, thanks.
Haavard
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
> Signed-off-by: Paul Driveklepp
> Signed-off-by: Olav Morken
Applied to evk1100-prep, thanks.
Haavard
_
Gunnar Rangoy wrote:
> From: Olav Morken
>
> 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 some address-sp
Gunnar Rangoy wrote:
> From: Olav Morken
>
> 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.
>
> Signed-off-by: Gunnar
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
U-
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
> Cc: Haavard Skinnemoen
> Cc: Mike Frysinger
> ---
> reb
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 !!
Olav Morken wrote:
> On Mon, Jan 26, 2009 at 21:03, Wolfgang Denk wrote:
> > Dear =?ISO-8859-1?Q?Gunnar_Rang=F8y?=,
> >
> > In message
> > you wrote:
> []
> >> >
> >> > It would be nice if you used readable names instead of all these
> >> > magic hardcoded constants.
> >>
> >> Each bit in th
Olav Morken wrote:
> > Yes, AP7000 have two Ethernet MACs. And if I got this right you want to
> > make a generic config about it, so then I guess it should open up for
> > having more than one MAC.
>
> OK, how about adding a CONFIG_MACB_ADVERTISE(id)-option, where id is
> the id of the MACB (pa
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
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 oscil
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 driver
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 ++
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
> Date: Thu Dec 13 12:56:34 2007 +0100
>
> cfi_flash: Use map_phy
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 vi
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 dataflas
rysinger
I like it. "hz" makes it perfectly clear what the value means.
Acked-by: Haavard Skinnemoen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
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
spi structures so that things work out.
>
> Signed-off-by: Brad Bozarth
> Signed-off-by: Mike Frysinger
> CC: Haavard Skinnemoen
Acked-by: Haavard Skinnemoen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
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
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 'pac
;From 92c78a3bbcb2ce508b4bf1c4a1e0940406a024bb Mon Sep 17 00:00:00 2001
From: Haavard Skinnemoen
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, conv
, saving the environment 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-
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.d
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'
bra
Piotr Zięcik <[EMAIL PROTECTED]> wrote:
> Wednesday 19 November 2008 14:51:01 Haavard Skinnemoen napisał(a):
> > > Export flash_sector_size() function from drivers/mtd/cfi_flash.c.
> >
> > Why?
>
> This function is used by cfi-mtd driver, which I have p
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
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 co
t; Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
Acked-by: Haavard Skinnemoen <[EMAIL PROTECTED]>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
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
http://lists.denx.de/mailman/listi
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: Ola
1 - 100 of 180 matches
Mail list logo
