RISC OS Open
A fast and easily customised operating system for ARM devices
ROOL
Home | News | Downloads | Bugs | Bounties | Forum | Documents | Photos | Contact us
Account
Forums → Community Support →

allocating physically contiguous memory

Subscribe to allocating physically contiguous memory 8 posts, 2 voices

 
Nov 13, 2017 8:28pm
Avatar Matt (481) 28 posts

I’m struggling to allocate the above using the new PMP dynamic areas – although this would appear to be the correct way for what I want. I just want to be able to allocate a number of large buffers, and be able to temporarily map them in (which I’m finding hard).

I was wondering if anyone had visited this and maybe share some code or help. I’m targeting an iMX6 5.23.

Thanks for reading,
Matt

 
Nov 14, 2017 11:30am
Avatar Jeffrey Lee (213) 4856 posts

The basic procedure you’ll want to follow is:

  1. Create a PMP using OS_DynamicArea 0, with bit 20 of the flags set.
  2. To allocate a physical buffer:
    1. Make sure your PMP has enough physical space (resize using OS_DynamicArea 23 if necessary)
    2. Identify some PMP page numbers which have no RAM allocated to them (if necessary you can query the state using OS_DynamicArea 25). The numbers don’t need to be contiguous.
    3. Identify some physically contiguous RAM to allocate to those pages, probably via OS_Memory 12
    4. Use OS_DynamicArea 21 to assign those pages to your PMP. Make sure bit 15 of the page flags are set so that nobody else can steal the pages from you (if another app were to request the same physical page numbers, the kernel would swap your pages with replacement pages taken from the free pool, but those replacements would be at different physical addresses and are unlikely to be contiguous. Setting bit 15 prevents the other app from getting your pages.)
  3. To map in/out your pages, use OS_DynamicArea 22. Again, make sure that bit 15 of the page flags remains set.

You might find this post useful, since that attempts to explain the many different ID/indexing schemes and how they relate to logical and physical addresses.

 
Nov 14, 2017 8:06pm
Avatar Matt (481) 28 posts

Thanyou, that has made things much clearer. However one thing I haven’t quite understood is deciding/calculating the value of the DA page number’s indicating the logical address when I map them in. Do I calculate, choose or obtain the logical address’s?

Thanks,
Matt

 
Nov 14, 2017 9:39pm
Avatar Matt (481) 28 posts

Ah, sorry – I think I see now – the logical base is automatic, and you only have to decide index – correct?

Many thanks,
Matt

 
Nov 14, 2017 10:56pm
Avatar Jeffrey Lee (213) 4856 posts

Yes – the kernel picks the base logical address of your dynamic area, you just control the index/offset from that base (up to the max logical size specified when the DA was created)

 
Dec 15, 2017 11:51pm
Avatar Matt (481) 28 posts

Hi, I’m struggling with this. Reason 21 fails for me – even if I set the page numbers to -2. I’m assuming the problem is related to my handler which doesnt seem to get called. If I can get my handler to be called properly ( I’m using the cmhg generic-veneers wrapper currently – I will try something else ) is there something I’m missing?

Dump out:

swi(&66,0, -1, 0, -1, (1<<8)+(1<<20), 64*1024*1024, (int)dynamic_area, -1, “IPU Surface Area”, 1024) → 0, 281, 0, 1201696768
area: 0×119
Log base: 47A07000
Log size limit: 67108864
Max physical pages: 1024
s→pages: 16
swi(&68,12 + (1 << 8), s→pages * PAGE_SIZE, 12) → 268, 65536, 12, 10441
s→page_index: 10441
mem = { 0, 10441, 32768, 1, 10442, 32768, 2, 10443, 32768, 3, 10444, 32768, 4, 10445, 32768, 5, 10446, 32768, 6, 10447, 32768, 7, 10448, 32768, 8, 10449, 32768, 9, 10450, 32768, 10, 10451, 32768, 11, 10452, 32768, 12, 10453, 32768, 13, 10454, 32768, 14, 10455, 32768, 15, 10456, 32768, }
swi(&66,21, area, (int) &mem, s→pages) → 536880164, 281, -98533956, 16

( 16/16 not processed )

Thanks,
Matt

 
Dec 16, 2017 9:25am
Avatar Jeffrey Lee (213) 4856 posts

I can’t see anything obviously wrong with the way you’re setting up the DA or the page list. However this makes me think that you might be passing in a pointer to a pointer?

(int) &mem

In C an array is generally handled exactly the same as a pointer (the main difference being that the compiler will try and do bounds checking for an array). Try replacing it with just “(int) mem” and see how you get on.

If it’s still not working, it would be good to check what the error returned by OS_ReadDynamicArea is (the V flag will be set and R0 will be a pointer to an error block)

I’m assuming the problem is related to my handler which doesnt seem to get called. If I can get my handler to be called properly ( I’m using the cmhg generic-veneers wrapper currently – I will try something else )

A generic-veneer wrapper should be fine, and I wouldn’t expect your handler to get called in this situation. For basic PMP DAs, the handler is only called when someone uses OS_ChangeDynamicArea to adjust the size of your DA – e.g. this could happen as the result of someone dragging the bar in the task manager (if you don’t set bit 7 of the DA flags to prevent this). If your DA is only used internally by your code, then you could implement your handler so that it always returns an error, preventing any resizing by OS_ChangeDynamicArea.

 
Dec 17, 2017 7:21pm
Avatar Matt (481) 28 posts

Eeek – well spotted – I’d looked over that so many times… And that’s great that I dont have to worry about the handler. It’s interesting that the C language allows referencing a simple array – what is the result? Another pointer would need to be allocated just to make it work !? You could say an array points to itself. Note that &func returns the same as func when used as a pointer – but with arrays I imagine its undefined..

Anyway many thanks,
Matt

Reply

To post replies, please first log in.

Forums → Community Support →

Search forums

Social

Follow us on and

Commercial use

For commercial enquiries, please contact the owners of RISC OS, Castle Technology Ltd.

ROOL Store

Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.

Donate! Why?

Help ROOL make things happen – please consider donating!

Description

Community-provided support for all users of RISC OS.

Voices

  • Matt (481)
  • Jeffrey Lee (213)

Options

  • Forums
  • Login
Site design © RISC OS Open Limited 2011 except where indicated
The RISC OS Open Beast theme is based on Beast's default layout

Valid XHTML 1.0  |  Valid CSS

Powered by Beast © 2006 Josh Goebel and Rick Olson
This site runs on Rails

Hosted by Arachsys