Dear Haavard Skinnemoen,
Am 12.08.2010 08:52, schrieb Haavard Skinnemoen:
The paging system which is required to set up caching properties has not
yet been initialized when the SDRAM is initialized. So when the
map_physmem() function is converted to return the physical address
unchanged, the
Haavard Skinnemoen schrieb:
The paging system which is required to set up caching properties has not
yet been initialized when the SDRAM is initialized. So when the
map_physmem() function is converted to return the physical address
unchanged, the SDRAM initialization will break on some boards.
Hi Haavard,
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
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
Hi Haavard,
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
The paging system which is required to set up caching properties has not
yet been initialized when the SDRAM is initialized. So when the
map_physmem() function is converted to return the physical address
unchanged, the SDRAM initialization will break on some boards.
The avr32-specific uncached()
Hi Haavard,
The paging system which is required to set up caching properties has not
yet been initialized when the SDRAM is initialized. So when the
map_physmem() function is converted to return the physical address
unchanged, the SDRAM initialization will break on some boards.
The
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
8 matches
Mail list logo