You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
tt_SiliconDevice::write_mmio_device_register will pad the input buffer if size isn't a multiple of four. If the buffer is padded, the value of the padding is undefined but will be written to the chip. Callers attempting to use "REG_TLB" as a mechanism to perform e.g. 2 byte write of device memory via UC mapping may find this behavior surprising.
Suggestions:
Stronger programmatic distinction between register reads/writes and memory reads/writes. Do not select the behavior based on a magic string.
Stronger programmatic distinction between device access via UC vs WC mappings. Byte access through UC mapping is fine if it is accessing memory.
Allow only 32-bit reads/writes in the register code paths.
The text was updated successfully, but these errors were encountered:
We should untangle this REG_TLB path.
tt_debuda just hit an issue where write_to_device accepts 64bit address, which can then call write_mmio_device_register which also accepts 64bit address, but if write_device_memory is called it accepts 32bit address. Specifically on ARC the L1 address space sits high in 36bit address space (on Wormhole), so they're unable to hit those addresses without fallback_tlb "REG_TLB".
Ouch. That's broken. We should use uint64_t for addresses everywhere, uint32_t is a bug. There are plenty of locations in Blackhole that require 64 bits to address.
tt_SiliconDevice::write_mmio_device_register
will pad the input buffer if size isn't a multiple of four. If the buffer is padded, the value of the padding is undefined but will be written to the chip. Callers attempting to use "REG_TLB" as a mechanism to perform e.g. 2 byte write of device memory via UC mapping may find this behavior surprising.Suggestions:
The text was updated successfully, but these errors were encountered: