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
Becky Bruce wrote:
>> This is where Detlev's comment about using the chance to define a
>> cache API comes into play.
>>
>> Yes, we probably should create a set of functions like
>>
>> enable_data_cache(address, size);
>> and
>> disable_data_cache(address, size);
>>
>> which would turn o
On Thu, Sep 3, 2009 at 11:09 AM, Becky Bruce wrote:
> This makes sense to me. The disable function would need to flush the
> range from the cache, but that's the only difficulty I forsee.
> However, I dug up some AVR32 docs, and it looks like the whole dual
> cacheable/CI mapping thing may be arch
Becky Bruce wrote:
>
> On Sep 2, 2009, at 2:59 AM, Wolfgang Denk wrote:
>
>> Dear "J. William Campbell",
>>
>> In message <4a9d99b1.1010...@comcast.net> you wrote:
>>>
>> ...
Becky then posted the summary of this discussion here:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot
On Sep 2, 2009, at 2:59 AM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message <4a9d99b1.1010...@comcast.net> you wrote:
>>
> ...
>>> Becky then posted the summary of this discussion here:
>>>
>>> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/50705
> ...
>> In quick summar
Dear "J. William Campbell",
In message <4a9d99b1.1010...@comcast.net> you wrote:
>
...
> > Becky then posted the summary of this discussion here:
> >
> > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/50705
...
> In quick summary, for the next few years, we will require that all
> "import
Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message <4a9d5ef2.4030...@comcast.net> you wrote:
>
>> I have followed the recent discussions about problems in the CFI
>> driver caused by the need to change the attributes of the address at
>> which the flash is mapped. This dis
Dear "J. William Campbell",
In message <4a9d5ef2.4030...@comcast.net> you wrote:
> I have followed the recent discussions about problems in the CFI
> driver caused by the need to change the attributes of the address at
> which the flash is mapped. This discussion has raised some questions
I have followed the recent discussions about problems in the CFI
driver caused by the need to change the attributes of the address at
which the flash is mapped. This discussion has raised some questions in
my mind regarding the assumptions u-boot makes regarding the behavior of
the addres
10 matches
Mail list logo
