This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

does the BUFFERABLE bit of HPROT/AxCACHE ever mean anything by itself?

Note: This was originally posted on 31st July 2009 at http://forums.arm.com

hi all,

there seems to be a clear definition of "bufferable" in both the AHB and AXI specs, pertaining to where write responses must be issued from. but, then there are tables like the following from an ARM10 manual, which makes it seems like bufferable doesn't mean anything by itself:

C B Notes
0 0 Uncached, unbuffered
0 1 Uncached, buffered
1 0 Write-through cached, buffered
1 1 Write-back cached, buffered[/font]

for both AHB and AXI, does the bufferable bit always have to be interpreted along with the cacheable bit?

another thread seems to imply this:
[url="http://forums.arm.com/index.php?showtopic=12871"]http://forums.arm.com/index.php?showtopic=12871[/url]

any other official statements to this effect?

thanks!
james

Parents

Peter Harris over 12 years ago

Note: This was originally posted on 28th October 2009 at http://forums.arm.com

Yes, that sounds right to me. The pair of bits describe the memory type you are accessing, and therefore what the bus / cache infrastructure is allowed to do with it. Interpreting either of these bits individually only gives a partial picture of the memory type, and is pretty meaningless.
Cancel
Vote up 0 Vote down

Cancel

Reply

Peter Harris over 12 years ago

Note: This was originally posted on 28th October 2009 at http://forums.arm.com

Yes, that sounds right to me. The pair of bits describe the memory type you are accessing, and therefore what the bus / cache infrastructure is allowed to do with it. Interpreting either of these bits individually only gives a partial picture of the memory type, and is pretty meaningless.
Cancel
Vote up 0 Vote down

Cancel

Children

No data