if I have a base of 0x00000432 and some bounds, say 500, how can I translate various virtual addresses to physical addresses?
VA 0x0000043 --> ?
VA 0x0000054c --> ?
Related
I'm trying to write a PCIe driver to DMA pages from the host memory to an FPGA. My host setup is Cavium ThunderX2 and my FPGAs are Xilinx Alveo U50.
A DMA from/to the host causes the ARM SMMU v3.4 to throw an event 0x10 Translation fault. I'm using dma_map_single(..) and dma_alloc_coherent(..) Linux APIs to map the virtual address of the page to a DMA-capable address.
Further inspecting the event records, Context Descriptor, and Stream Table Entries, I have the following information.
Type of Fault - F_TRANSLATION (Translation Fault)
S2 == 0 (Stage 1 Fault - Virtual Address -> Intermediate Physical Address stage)
Class of Fault = TT/TTD (Translation Table Descriptor Fetch)
PnU == Underprivileged Access
T0SZ == 5'b01000 (16); T1SZ == 5'b00000 (IGNORED because EPD1 == 1)
VAS == 49 bits (Virtual Address Size)
TG0 == 00 (4 kB page granule size)
EPD0 == 0 (Stage 1 page table walk enabled)
EPD1 == 1 (Stage 2 is bypassed)
TB0/1 == 0 (Top byte ignore disabled)
IPS == 44 bits (Input Address size)
SMMU Config = 3'b101 (Stage 1 translation enabled, Stage 2 bypassed)
Sample Virtual and DMA address of the page obtained -
Virtual Address - 0xFFFF--- (64-bit value)
DMA Address - 0x9F733CA000 (looks within the range defined by T0SZ and compliant with the IPS)
I'm unable to figure why I'm getting a Stage 1 translation fault when everything looks fine. Technically, I should be getting a Stage 2 fault since it is bypassed and the input address should translate through the TTB0.
P.S. I'm a newbie to ARM v8. Let me know if you need additional information in the comments.
Attached is a picture of the fault F_TRANSLATION.
I was able to fix the issue. There was a synchronization lapse between the IOMMU and the DMA mapping. There were no valid descriptors found for the mapped DMA addresses in the SMMU.
I used dma_alloc_coherent(SZ_2M) to get a buffer region and use IOMMU domain ops to map the IOVA to the SMMU.
int ret = iommu_domain->ops->map(domain, IOVA, size, phys_addr, PROT)
Now the SMMU is able to fetch and translate the IOVA.
For some reason, dma_map_single(..) doesn't work with my current implementation. I have to investigate why a streaming DMA API doesn't work.
This question refers to an architecture using segmentation with paging. In this architecture, the 32-bit virtual address is divided into fields as follows:
4 bit segment number | 12 bit page number |
16 bit offset
Find the physical address corresponding to each of the following virtual addresses (answer "bad virtual address" if the virtual address is invalid).
1.00000000
2.20022002
3.10015555
Please help me with this, i dont know how to create page table and segment table for this mapping !!!
You are a little shy on details, so lets fill in a few:
Each segment has a 4096 (=2^12) entry translation table associated with it; otherwise it would not be interesting.
Each entry will contain a physical base address.
The extra offset will be added to this base address to find the final one.
So, in this hypothetical MMU, we could have a function like:
paddr_t translate(uint32_t vaddr) {
return segment[vaddr>>28].page[(vaddr>>16)&0xfff] + (vaddr & 0xffff);
}
A real (useful) mmu would have a bit more like:
paddr_t translate(uint32_t vaddr) {
seg_t *seg;
page_t *page;
if ((seg = segment[vaddr>>28]) && (page = seg->pagetab[(vaddr>>16)&0xfff])) {
return page->base + (vaddr & 0xffff);
} else {
raise(SEGV);
}
}
this is showing the sparseness of both segments and page mappings. It would likely have some permissions, as well, but this should help get you to the next obstacle.
Why are the virtual addresses in the dumpfiles different, when I use XDD and Radare2?
Radare2-dump
Xdd-dump
The first image shows the Radare2-dump, the second one the xdd-dump. The addresses are not completely different.
The xdd is:
000007b0
The radare2 is:
0x004007b0
Why is there a offset of 0x00400000?
Edit: I am working on Linux.
I'm struggling to understand where to get the address of a device on a device tree? As an example how do I know that I should set <0x00900000 0x20000> in here.
Is memory mapped IO done in the hardware (the processor itself) or in software and do I just have to pass the right address in the device tree?
Is the address hardcoded on the processor or can I just set an arbitrary address? I cannot find anything in my reference manual about setting a certain address in the device tree
These kind of addresses can be found in the Reference Manual of the processor.
You can find the link here.
Take a look at the chapter 48 (OCRAM On-chip RAM Memory Controller) and more specifically at the section 48.2.1 (page 4118):
The total on-chip RAM size for the chip is 128 Kbytes, organized as 16K x 64 bits,mapped from 0x00900000 to 0x0091FFFF
This is where come from the values <0x00900000 0x20000> from the dtsi file, corresponding to the base address and the offset.
These values are in dts/dtsi file provided by the chip maker.
I'm a freelancer. I have finished a project for a company that uses Ethernet (TCP+UDP) with a STM32F4 Device.
While I was testing I used MACs in the space 00:00:00:00:00:xx , but now we need to assign final MACs.
The question here is that the company that pays the project dont want to buy OUI mac space. They say that is it practically impossible to have 2 cards in the same network with the same MAC address.
Another reason that they are telling me is that they will use this ethernet device card in places where no more ethernet device except a WIFI router and maybe more of our cards would be connected.
I found on internet places telling that you can use FF:FF:FF:FF:FF:FF as null mac address, I have been testing it without any problem (i thought that ARP would fail but it is working), but they would not be able to connnect 2 cards together in this case.
I have some questions about this.
Is it legal to use MACs from other companies or even non assigned MACs addresses?
Is there any interval of MACs that they can use freely without paying
Any reason to convince them to buy the OUI space would be welcomed too.
I don't think using non-asigned OUI is good, but MAC addresses with second bit 1 are called "locally administered addresses" and can be used without registering to IEEE.
This mean that you can use MAC addresses like x2:xx:xx:xx:xx:xx, x6:xx:xx:xx:xx:xx, etc. to stand for your NIC.
Notr that MAC addresses with first bit 1 are for multicasting, not for standing fir single NIC, and that MAC address FF:FF:FF:FF:FF:FF is for broadcasting, not null.
MAC address - Wikipedia, the free encyclopedia
To clarify MikeCAT's answer - it is the two least significant bits of the 1st byte of the MAC address that are important - what I think of as the 7th and 8th bit:
??????XY:????????:???????? ????????:????????:????????
where ? represents any bit in the mac address, and X is the U/L bit and Y is the Uni/multi cast bit
If the the eighth bit of a MAC address is 1, devices may have trouble getting IP addresses using DHCP. If the eighth bit of a MAC address is 0, you may have more luck.
The 7th and 8th bit of MAC addresses are special:
Bit 8 == 0 for unicast
Bit 8 == 1 for multicast
Bit 7 is also special - 0 = globally unique (assigned to a manufacturer to use) and 1 = locally administered (we should use these addresses!)