From: Stefan Roese <sr@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] Add support for Indefia Nimbus Cloud Board
Date: Mon, 22 Mar 2010 10:23:15 +0100 [thread overview]
Message-ID: <201003221023.15825.sr@denx.de> (raw)
In-Reply-To: <20100321163450.6E72D4C022@gemini.denx.de>
Hi Wolfgang,
On Sunday 21 March 2010 17:34:50 Wolfgang Denk wrote:
> > The problem with AVR32 and the CFI flash driver has a few possible
> > solutions as noted by Haavard Skinnemoen in the email [1]. The only
> > thing I can do is to go with the first alternative and set the flash
> > address as the virtual address which is cache-disabled and works
> > flawless with the CFI driver.
> >
> > That solution can also be used by other AVR32 boards, and I _think_ it
> > also solves the JFFS2 scanning problem which was mentioned in [2].
> >
> > The only ugly thing (for me) is when using the CFI commands, the flash
> > addresses has to be shifted by 0xa0000000. (e.g. copy to flash at 0x1000
> > must be written as cp.b <source> 0xa0001000 <size>).
>
> I really dislike such an approach. From the user interface point of
> view this is unacceptable to me.
>
>
> My understanding is that there are only three pretty local areas where
> uncached access to the flash is needed: initialization (i. e. probing
> and querying), erasing, and programming.
Yes. If I don't miss anything then this is correct.
> So it should be possible to switch off caching when entering these
> functions, and turn it on again upon return. Eventually other
> architectures might want to implement such a feature, too, so adding
> generic infrastructure to do that makes sense to me.
>
> Stefan might want to comment here, too ?
Currently I see 2 approaches to support NOR FLASH mapped via a cached memory
region in the common CFI driver:
a) Use write-through cache support (if possible) and add required cache
handling calls (invalidate and flush) at the "correct locations" (TM)
in the CFI driver.
b) Temporarily disable cache in the NOR FLASH memory region before using
the CFI driver. This could be done in some generic places (like Wolfgang
mentioned above) and should not require any additional user action/input.
Not all platforms will support both alternatives.
Semih, would one of the above options be possible for your platform? Does the
AVR support write-through cache? Is it possible to enable such a caching
attribute selectively for the NOR FLASH region?
BTW: It might be that I start working on such a cached NOR FLASH support in
the next few weeks. My current preference is option a) right now.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de
next prev parent reply other threads:[~2010-03-22 9:23 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-17 13:12 [U-Boot] [PATCH] Add support for Indefia Nimbus Cloud Board Semih Hazar
2010-01-06 9:18 ` Semih Hazar
2010-01-17 23:17 ` Wolfgang Denk
2010-01-21 13:13 ` Semih Hazar
2010-01-25 22:31 ` Wolfgang Denk
2010-02-04 17:13 ` Semih Hazar
2010-03-01 14:12 ` Semih Hazar
2010-03-21 16:35 ` Wolfgang Denk
2010-03-21 16:34 ` Wolfgang Denk
2010-03-22 9:23 ` Stefan Roese [this message]
2010-03-23 17:41 ` Semih Hazar
2010-03-23 20:01 ` Wolfgang Denk
2010-03-24 14:51 ` Stefan Roese
2010-02-04 17:14 ` Semih Hazar
2010-03-21 16:44 ` Wolfgang Denk
2010-01-21 13:13 ` Semih Hazar
2010-01-25 22:34 ` Wolfgang Denk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201003221023.15825.sr@denx.de \
--to=sr@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox