|ARM Technical Support Knowledge Articles|
Applies to: Fast Models
The PVBusMapper component is used for remapping transactions based on the transaction's attributes. When a transaction is made within a 4KB block of memory, PVBusMapper creates a fast channel (if one doesn't exist already) and sends all future transactions to the same 4KB block and with the same transaction attributes through the channel.
When a channel has not been created for a given incoming transaction, the remap behaviour is called. This behaviour allows for the incoming transaction to analyzed and the decision on how to map it to be taken. For example, you could remap the address or the attributes or both for a given transaction.
The example in this article demonstrates the creation of a channels, destroying them and remapping addresses.
The example system attached to this article contains the following components:
This component is used to remap transactions in our system according to their attributes. In essence it behaves as a dummy external MMU component with very basic/limited functionality. The component is capable of internally mapping transactions to different ports based on the attributes. For the purpose of this example, the implemented remap behaviour of this component is as follows:
// The callback behavious is passed a RemapRequest object containing all the
// information about the transaction. Look at RemapRequest.h for more details
// on the available API
slave behavior remap( pv::RemapRequest& req_ ) : unsigned
printf("\nRemapper : Inside Remap Callback\n");
printf("\t : Obtaining transaction information....\n");
// Get the transaction attributes (RemapRequest member function)
attributes = req_.getModifiableTransactionAttributes();
// Check if it is secure or non-secure
bool non_secure = attributes->isNormalWorld();
address = req_.getOriginalTransactionAddress();
printf("\t : Address = 0x%08x\n",address);
printf("\t : Security = %s\n",non_secure?"Non-Secure":"Secure");
if( non_secure )
// if non-secure transaction translate address, PA = VA + Offset and output transaction on pvbus_m port
// Get the 4kb aligned base address for this transaction using
// getPageBase() function and add offset to it.
new_base_address = (req_.getPageBase() + Offset);
// This function creates a channel and mapping
// Only called once for a 4KB block.
// NOTE: The base address passed as arguement must be 4kb aligned!
printf("\t : Translating Non-Secure transaction....\n");
printf("\t : Incoming VA = 0x%08x\n",address);
printf("\t : 4k block base address = 0x%08x\n",req_.getPageBase());
printf("\t : Offset = 0x%08x\n",Offset);
printf("\t : New base address = 0x%08x\n",new_base_address);
// Use pvbus_m for this transaction
printf("\t : Remapped to NSRAM (pvbus_m) at physical address 0x%8x\n\n", new_base_address);
// if secure transaction no translation. Only output transaction on pvbus_m port
// Use pvbus_m for secure transactions
// This is connected to SRAM.
printf("\t : Remapped to SRAM (pvbus_m), not address translation\n\n");
For Non-Secure transactions:
For Secure transactions:
The Remapper component also has a memory mapped RW register which contains an offset value used to translate NS accesses. When the register is modified the component has to revoke all currently created channels so that news one with the updated offset can be created.
The revoking of channels can be achieved by calling the allBusMapChanging behavious of the PVBusMapper's control port. This will revoke every currently created channel.
The application code starts up in the Secure World (Supervisor mode) and writes the value "0xCAFE" to address 0x10000004. The remapper then creates a channel and routes this value into SRAM. The code then writes another value ("0xDEAD") to the same address and this time it can be seen that the Remap callback is not called as the channel has already been created for secure transactions to the address range (4KB).
After this the code switches to the Non-Secure world and performs a write at the same address. Since the attributes have changed the transaction no longer matches the channel created previously, so a new one is need and hence the remap behaviour is called.
Lastly, the core writes to the offset register to change the offset value. This triggers all channels to be removed and hence when perform another transaction to the same address remap is called and this time uses the new offset value for the translation.
model_shell -m <PATH/TO/MODEL>.dll -a <PATH/TO/APP/CODE>.axf
Article last edited on: 2013-04-30 09:52:12
Did you find this article helpful? Yes No
How can we improve this article?