align malloc and free in VxWorks
lhp
I use following routine to malloc a block of cache-coherent memory which aligns parameter "Align". Align is a value which is power of 2.
void* commonCacheDmaMallocAlign(UINT32 Align,UINT32 Size)
{
char* memory1, memory2;
memory1 = (char*)cacheDmaMalloc(Size + Align);
/* check if allocation successes */
if(memory1 == NULL)
{
printf("can"t allocate memory\n");
return NULL;
}
memory2 = ((char*)(((UINT32)(memory1 + Align)) & (~(Align-1))));
return (void*)memory2;
}
My Question:
Is it safe and correct when I free the memory malloced by commCacheDmaMallocAlign() like this?
void *p;
p = commonCacheDmaMallocAlign(16, 1000);
...
cacheDmaFree(p);
Will the memory between "memory1" and "memory2" be lost? I don't know how the VxWorks kernel
deal with it internally. Who can tell me?
Certaily, we can save the value of original "memory1" first and use cacheDmaFree(memory1) to free the whole memory. I know this is absolutely safe and correct. MUST we do like this? I want an exact answer.
Urban Lindberg
Why do you try to reinvent the wheel? Have a look at memalign! Btw, you
can only free a address you have received my a memory allocation, so
your example might crash or maybe even reboot. You don't say what you
need it for, but if its for DMA, use cacheDmaMalloc. If you really need
to do what the example is intended to, you need to save the values
returned from cacheDmaMalloc and if more than one task can call your
functions you need to add some mutex and maybe a check that Align is a
power of two.
Urban
lhp wrote:
[Snip]
DragonSpring
II ethernet switch chip. The BD of the DMA controller in the chip need
a block of buffer which must be cache-coherent and must align at long
word (16 bytes) bound. So it first use cacheDmaMalloc() to alloc a
block of memory which is cache-coherent, then align it. It cannot use
memalign here.
Is there any other good method to achieve this aim? Please give piece
of source code.
Regards,
Urban Lindberg <qin...@ks.ericsson.se> wrote in message news:<3B41EC87...@ks.ericsson.se>...
DragonSpring
"your example might crash or maybe even reboot." Are you sure?
Why should we add some mutex? I think it is unnecessary.
Urban Lindberg <qin...@ks.ericsson.se> wrote in message news:<3B41EC87...@ks.ericsson.se>...
David Laight
> commCacheDmaMallocAlign() like this?
>
> void *p;
> p = commonCacheDmaMallocAlign(16, 1000);
> ...
> cacheDmaFree(p);
>
> Will the memory between "memory1" and "memory2" be lost?
Not a chance - this is guaranteed to at least generate an error message
from the memPartAlloc code, it might generate a fault in the task freeing the
memory. If really unlucky your system might freeze solid (accessing a random
memory location).
At alternative is to allocate the memory area you need uncached from outside
the area used by the vxWorks kernel. Two options:
1) The end of physical memory - by setting USER_RESERVED_MEM. But beware at
least one WRS BSP (the StrongARM one) uses an area allocated there for an
intermediate page table - then frees an equivalent space from the other end of
the area (ie not the same address if you reserve more space).
2) Low memory below MEM_LOW_ADDR. This has the advantage that you can grope
physical memory and still have it contiguous.
In both cases you can get the standard system page tables set to give this
memory the required properties. The fixed addresses make diagnostics easier!
David
Urban Lindberg
We also use DMA and we use memalign for the buffers and it works as it
should (sorry, I was a bit in error regarding cacheDmaMalloc). I tried
calling cacheDmaMalloc (on a PPC604 VI-board) from the shell and it
seems to return memory align on 2^12, so it should work without any
extra alignment. Yes, I am very sure it will crash or reboot. The
allocator functions actually allocate some extra bytes for accounting of
the memory. The allocator function return the address following the
accounting information. The deallocator takes the address given to it
and subtacts the size of the accounting information and if you don't
return exactly the address you recieved from tha allocator the
bookkeeping will go wrong and will crash or reboot your system. The
accounting information is often one pointer and a long int for the size
of the block and the pointer is followed by the deallocator and
depending of what kind of allocation you made it could access a NULL
pointer (crash), uninitialized pointer (possibly modifying the stack or
even code) which might reboot the system put in an infinite loop or even
correct a bug in your program (I have actually seen all of them happen).
HTH
Urban
DragonSpring wrote:
>
> Yes, we really use it for DMA and the DMA requires the buffer to be aligned.
>
> "your example might crash or maybe even reboot." Are you sure?
>
> Why should we add some mutex? I think it is unnecessary.
>
[snip]