1) Is it possible to access a physical address which is not defined in /proc/iomem?
2) If the physical address range of a device does not appear in /proc/iomem, does it mean that the device has not been utilized/initialized yet?
1) Is it possible to access a physical address which is not defined in /proc/iomem?
Yes.
Assuming an ARM processor which memory maps all directly-connected periperals, the driver could perform an ioremap() operation to map the physical memory to virtual memory for access.
But a properly written driver would first call request_mem_region() to ensure that it can use (and lay claim to) that physical address space.
The information in /proc/iomem comes from drivers calling request_mem_region().
2) If the physical address range of a device does not appear in /proc/iomem, does it mean that the device has not been utilized/initialized yet?
You would have to inspect the driver code to determine how well written the driver is.
Is there a request_mem_region() before the ioremap()?
Check the system log using the dmesg command; perhaps driver initialization failed.
Assuming that this is a statically-linked driver rather than a loadable module, then as each kernel device driver has its init() routine called you can get trace output by having added the option "initcall_debug" on the kernel command line. If you are using U-Boot, then this option should be added to the "bootargs" variable (which is used for the kernel command line).
Related
I am working in Linux 2.6.20.14 running processor having USB chip FT313. I got a Linux driver from a vendor and I ported that to my Linux. When I do the memory read at the Uboot side on the memory to be mapped to my FT313 chip, I saw each 16-bit value was repeated twice in the memory. For e.g, if the default value is 03130001, the output will be like 03130313 00010001.
I needed to have dummy entries for each register to ignore these repeated values. After that, USB insertion and ejection give prints and IRQ count also increases. But when I tried to mount the Pen Drive as mass storage, SCSI probes won't happen and a USB device is not getting detected as Mass storage. I have already installed USB storage and scsi_mod modules.
Can anyone who has worked on FT313 in Linux tell me whether it is the expected behavior or not? And if it is possible to have FT313 chip as USB mass storage.
I'm familiar with MIPS architecture, and I've known that MIPS has memory section such as kseg0, kseg1. Which determine whether the segment can be cached or mapped. For example, you should locate some I/O devices(like UART) to the uncached segment.
But I didn't find anything related in RISCV arch. So how does the RISCV OS know the address should be mapped or not?
By the way: I know the value in satp CSR desrcibes the translation mode. When OS is running, the value must set other than "Bare(disabled MMU)" so that the OS can support the virtual memory. So if CPU access UART address, the value in satp is still not "Bare"? But it should be "Bare"?
RISC-V is a family of instruction sets, ranging from MCU style processors that have no memory-mapping and no memory protection mechanisms (Physical Memory Protection is optional).
From your question, I assume you are talking about processors that support User and Supervisor level ISA, as documented in the RISC-V privileged spec.
It sounds like you want a spec describing which physical addresses are cacheable. Looking at the list of CSRs, I believe this information is not in the CSRs because it is platform specific. In systems I've worked with, it is either hard-coded in platform drivers or passed via device-tree.
For Linux, the device-tree entries are not RISC-V specific: there are device tree entries specifying the physical address range of memory. Additionally, each I/O device would have a device tree entry specifying its physical address range.
You can read the RISC-V privileged spec (The RISC-V Instruction Set Manual Volume II: Privileged Architecture 3.5 Physical Memory Attributes).
"For RISC-V, we separate out specification and checking of PMAs into a separate hardware structure, the PMA checker. In many cases, the attributes are known at system design time for each physical address region, and can be hardwired into the PMA checker. Where the attributes are run-time configurable, platform-specific memory-mapped control registers can be provided to specify these attributes at a granularity appropriate to each region on the platform (e.g., for an on-chip SRAM that can be flexibly divided between cacheable and uncacheable uses)"
I think if you want to check non-cacheable or cacheable in RISCV, you need to design a PMA unit that provide MMU to check memory attribute.
I want to understand the performance of one device driver module in linux kernel. In this case I use carl9170 device driver in linux.
If I use two physical interfaces, how can the single module carl9170 handle 2 different physical interfaces?
Because so far, I have known that these 2 physical interfaces will make 2 instances and use different packet buffers for each but just using single carl9170 module. So it's confusing me.
And which file in linux kernel source code can I find about this handling method (relates to carl9170 device driver)?
Thank you very much for your help
For 2, take a look at the folder:
drivers/net/wireless/ath/carl9170/
This folder is located under your kernel source directory. It contains all the sources of the driver.
For 1:
It is pretty much how classes works on oriented object programming: how does an object know which instance of the data it must work with? The this pointer references the correct in memory data.
Take a look at the file drivers/net/wireless/ath/carl9170/carl9170.h. Every function exported by the driver is declared at this file. Note that every function has at its first parameter a reference to the struct ar9170 data type. This is exactly the data set that the driver must work with. It specifies everything the driver need to know about the device and its sates, since the USB buses address where the device is connected, to the state of the device, like its power, connection state and any other data the driver itself need in order to keep the device working properly.
Note that this is driver internal data thought. The kernel has its own set of data to keep both the driver, the device and the kernel itself working.
Take a look at the 546 line of carl9170.h. It is where the function declarations starts. This file is as of the kernel 3.8.8.
Just like in Object Oriented Programming you would allocate as many instances of a class as you need, the kernel will allocate as many ar9170 structures a it needs, one referencing each device.
The device ids can be obtained under the /sys/class/net directory. There will be a soft link for each of the network devices attached to your computer. This link will point the device to something like the following:
$ ls -l eth0
../../devices/pci0000:00/0000:00:04.0/0000:02:00.0/net/eth0
The pci0000:00 is the bus. The 0000:00:04.0 I believe is the bus address. Finally, the 0000:02:00.0 is the device id. Afaik, every registered device follows the same logic.
Finally, if you have two carl9170 devices, both will be under the directory /sys/class/net but probably one of them will be named wifi0 and the other wifi1. Also, each of them will point to different devices (check it with the command ls -l /sys/class/net).
I just would like to note that in the explanation I haven't used any wireless card. So I'm not sure whether wireless cards are shown under /sys/class/net or not. Anyway, it will be something very similar, like /sys/class/wireless.
Assume that there is a device using memory-mapped I/O i.e. there is a specific range of physical memory assigned to this device
If virtual memory system is not used, then it is quite straightforward to manipulate the device through read/write operations done with corresponding physical addresses
What if there is virtual memory system ?
Device driver needs to be aware of that specific range of physical memory assigned to that device, but how does it access that address range if it should use virtual addresses instead of physical ?
In case of memory mapped IO devices, any physical address shared by that device can be mapped to the kernel virtual memory using the ioremap() API [1].
Hence in your case, we can map the physical address 0x1234 using ioremap() to obtain its kernel virtual address and start writing data to this address.
[1] http://lxr.gwbnsh.net.cn/linux/arch/cris/mm/ioremap.c
It's been a long time since I've done it, but my recollection is that when you map a block of physical memory, the address in your user space corresponds to that physical memory. Writing to your user-space address is a write to the physical memory.
I've recently started getting into low level stuff and looking into bootloaders and operating systems etc...
As I understand it, for ARM processors at least, peripherals are initialized by the bootloader and then they are mapped into the physical memory space. From here, code can access the peripherals by simply writing values to the memory space mapped to the peripherals registers. Later if the chip has a MMU, it can be used to further remap into virtual memory spaces. Am I right?
What I don't understand are (assuming what I have said above is correct):
How does the bootloader initialize the peripherals if they haven't been mapped to an address space yet?
With virtual memory mapping, there are tables that tell the MMU where to map what. But what determines where peripherals are mapped in physical memory?
When a device boots, the MMU is turned off and you will be typically running in supervisor mode. This means that any addresses provide are physical addresses.
Each ARM SOC (system on Chip) will have a memory map. The correspondece of addresses to devices is determined by which physical data and address line are connect to which parts of the processor. All this information can be found in a Technical reference manual. For OMAP4 chips this can be found here.
There are several ways to connect off-chip device. One is using the GPMC. Here you will need to sepcify the address in the GPMC that you want to use on the chip.
When the MMU is then turned on, these addresses may change depending on how the MMU is programmed. Typically direct access to hardware will also only be available in kernel mode.
Though this is an old question, thought of answering this as it might help some others like me trying to get sufficient answers from stackoverflow.
you explanation is almost correct but want to give little explanation on this one:
peripherals are initialized by the bootloader and then they are mapped into the physical memory space
Onchip peripherals already have a predefined physical address space. For other external IO mapped peripherals (like PCIe), we need to config a physical addr space, but their physical address space range is still predefined. They cannot be configured at random address space.
Now to your questions, here are my answers..
How does the bootloader initialize the peripherals if they haven't been mapped to an address space yet?
As I mentioned above, all (on-chip)peripherals have physical address space predefined (usually will be listed in Memory map chapter of processor RM). So, boot loaders (assuming MMU is off) can directly access them.
With virtual memory mapping, there are tables that tell the MMU where to map what. But what determines where peripherals are mapped in physical memory?
With VMM, there are page tables (created and stored in physical DRAM by kernel) that tells MMU to map virtual addr to physical addr. In linux kernel with 1G kernel virt space (say kernel virtual addrs from 0xc0000000-0xffffffff), on-chip peripherals will need to have a VM space from within the above kernel VM space (so that kernel & only kernel can access it); and page tables will be setup to map that peripheral virt addr to its actual physical addr (the ones defined in RM)
You can't remap peripherals in ARM processor, all peripheral devices correspond to fixed positions in memory map. Even registers are mapped to internal RAM memory that has permanent fixed positions. The only things you can remap are memory devices like SRAM, FLASH, etc. via FSMC or similar core feature. You can however remap a memory mapped add-on custom peripheral that is not part of the core itself, lets say a hard disk controller for instance, but what is inside ARM core its fixed.
A good start is to take a look at processor datasheets at company sites like Philips and ST, or ARM architecture itself at www.arm.com.