Re: [microblaze-uclinux] DMA and cache

[John Williams <jwilliams@xxxxxxxxxxxxxx>]

Hi Jim,

Jim Van Vorst wrote:

> More specifically, I would think the OS would want to know the actual 
> physical
> size of ram.  If you lied to it would it end up double mapping memory?  
> I.e. if
> you have 64M and set HIGHADDR to 128M, ran petalinux-copy-autoconfig and
> rebuilt, the OS would think it had 128M to play with, then allocs from 
> 64M - 128M
> would remap to 0M - 64M?
> Is this an order of operations thing?  Do you set HIGHADDR to 64M then make
> the kernel with that, then set it back to 128M in the .mhs file and 
> rebuild the
> bitstream with that?

The approach is to double the address window of the DDR controller, but 
use the MSS parameter MEMORY_SIZE to force the size back down to the 
real (physical) size.

That will control the size exported in Kconfig.auto, and used by the 
bootloader and kernel etc.

> Also, if I wanted to take a different path and allocate some 
> (uncacheable) BRAM for the DMA,
> is there some central point in the code to handle that?  It looks like 
> there is
> one file that plays the UNCACHED_SHADOW OR/AND game but that calls
> some kernel allocation stuff.  What I'd want is another freelist that 
> pointed to
> my BRAM and use that.  Does the kernel have a create_freelist() type of
> function and memory alloc/free routines that can take my freelist context?

Managing BRAM with a proper kernel allocator has been on the to-do list 
for years, but I've never had the time to pursue it properly.

In principle it shouldn't be too hard, you could probably re-use the 
kernel's memory zone concept, to create a fast BRAM zone.  I've never 
seen it done nicely, even on other embedded / SoC arch's with fast 
on-chip memory.  It's always a bit of a hack, although maybe there's 
some precedent in the 2.6 kernel that I didn't see in 2.4.  If you are 
brave, it could be worth a post to the LKML to ask.  If there's a good 
model to follow, porting it across to MicroBlaze shouldn't be too hard 
at all.

The V4/PPC ethernet driver had a hack in it to allow DMA buffer 
descriptors (BDs) to be managed from BRAM - again it was a bit of a 
hack, jsut hard coded addresses and memory sizes.  The DMA transfers 
themselves went via main memory, it wus just the descriptors stored in 
fast on-chip RAM.

Remember also  that to make BRAM DMA-addressable you'll have to tie one 
port to the MicroBlaze DLMB, and the other port to an OPB_BRAM_IF_CNTRL.

Regards,

John
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/