• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 2167 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Can you control a Posted vs non-Posted write on an A8.

Justin Jansen
Intellectual 655 points
Other Parts Discussed in Thread: SYSBIOS

I've had some confusion lately about posted vs non-posted writes from the A8.  There is a lot of different terminology out there that I think are indicating the same thing, but thought I'd pose the question here to be sure.

I'm working on the 814x processor, and my A8 writes take the same amount of time as reads.  The DSP behaves as I would expect and takes a shorter amount of time to write vs read.  So, it acts like the A8 may not be using posted writes when the region is not cacheable.

The ARM documents its different memory properties here:

http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344i/Babghade.html#Babeidga

Is the characteristic I've described one that would match a strongly ordered access type, while what I really want is a device access type?

I don't know how this translates tho the registers or MMU PT on the TI reference manuals, and if that is the proper place to control a posted vs non-posted write from the A8.  Does anyone have experience with the A8 on this topic?  I don't think the question is limited to this chip, but rather TI's use of the A8.

  • 0
    Guru 31670 points

    Justin,

    In your case, since you are running sys-bios MMU will not be enabled. So, does Page table entries will not be required and their by the access type will also not be defined. 

    I did some research on the topic, and it seems like ARM is running in half the frequency than being configured to. Basically if you look closely on DPLLS block diagram you can see a "by 2" divider before the clkout of the PLL. I couldn't find a bit which will enable/disable this. So, I assume that it is always enabled. This is just a hypothesis. I may be wrong also. Can you try doubling/increasing your ARM frequency and see the performance. 

  • 0 in reply to Renjith Thomas
    Intellectual 655 points

    I do have the MMU enabled, and sysbios has cacheable, bufferable, sharable, and noexecute bits.  I only have the noexecute bits set.  If I set the shareable bit, the access time increases by an order of magnitude.  So I'm not sure how to control strongly ordered vs device memory type, or even if I can...or if I would even want to.

    As for the /2, I believe we have this accounted for, and not only that, but the PLL won't lock on anything higher than what I think is 900Mhz for me on the dev kit.  And, the cycle counter matches periodic rate I can watch a gpio toggle on the scope.  I think I'm good with the PLL.

  • 0 in reply to Justin Jansen
    Guru 31670 points

    Justin,

    I need to dig in deeper to understand more about the shareable bit. I'll check this and get back in couple of days.

  • 0 in reply to Justin Jansen
    Guru 31670 points

    Jansen,

    I'm not clear about BIOS architecture. Are these bufferable, cacheable and sharable permissions applicable to the entire memory or are you selectively doing it with a page table or else are you using Memory Protection Unit alone?

  • 0 in reply to Renjith Thomas
    Intellectual 655 points

    I have answered my own question.  It is the buffer able section property in the arm mmu that controls if a write can be handed off to a queue to complete.  Otherwise every noncacheable access waits for the completion acknowledgement from the end target before releasing the next instruction.  However TI did not hook up the arm such that a barrier instruction like DSB forces the completion of this write queue.  You must issue a read to the peripheral in question to flush the accesses.