Can PCI(e)-device claim non-variable memory- or I/O-port-mapped addresses ? Or even fixed interrupts ?
Related
can someone please tell me what contents does the memory have at very small Addresses(0-100), such as address 7 for example in a Linux-based operating system such as CentOS and in Windows ?
Low Virtual Addresses
For most operating systems, at least the lower half of a virtual address space depends on the process it belongs to (with "kernel space" in the upper portion). Typically, to catch dodgy pointers (which includes things like "int pointer = NULL; foo = pointer[1234];" and "struct myStructure *pointer = NULL; foo = pointer->myField;"; where the address that's accessed isn't the address that the pointer points to) the lowest virtual addresses are reserved for literally nothing; so that if any software tries to access it the CPU generates a page fault to inform the kernel that software tried to do something very wrong.
Low Physical Addresses
What is at low physical addresses depend on which type of computer it is (80x86, ARM, MIPs, ...) and what the firmware is (e.g. BIOS, UEFI) and other factors (how the chipset was configured). Without this information there can't be a specific answer (the only possible answer is "nobody can know").
I want to periodically check the state of the RAM ECC detection in my firmware on a STM32H753.
The ECC mechanism is well described in the Reference Manual for the Flash but not very well (in my opinion) for the RAM.
I've seen that there are dedicated interrupts for RAM ECC but it is not clear if they are triggered for single error or double error ?
Also, why a dedicated interrupt and not a BusFault (like it is done on the Flash if I understood correctly ?)
Also , I don't want to get interrupted for a single error (that is properly corrected). Instead I want to get the status periodically and log the error somewhere. What is the register to read to check whether a single error happened ?
I've got an answer on STMicro forum, I thought it might be helpful to post it here. The answer is from a member called Berendi.
"RAMECC status and interrupt flags are defined in the stm32h7??xx.h headers, and there are some code examples in stm32h7xx_hal_ramecc.h/.c
Apparently it's possible to independently mask single/double ecc fault interrupts.
There is application note AN5342 as well, but it's not very helpful."
Under a special condition I'm experiencing an hardfault exception. The ICSR indicates that it's an escalation from systick (pending exception = 15).
Any ideas how this would happen?
My guess is, that it's some kind of dead-lock.
Any recommendations how to trace this (without Atmel Studio)?
I'm using FreeRTOS 7.5.2.
UPDATE:
I added some more fault register to the output dump. So it's indeed a bus fault with a systick interrupt pending:
EXCEPTION HANDLER
- ICSR active exception: 3
- ICSR pending exception: 15
- ICSR pending interrupt: 0
- Hardfault status: 0x40000000
- Memory fault status: 0x00
- Bus fault status: 0x04
- Usage fault status: 0x0000
I was able to track down the exception to a FreeRTOS call:
vTaskDelay(10/portTICK_RATE_MS);
The application has 2 tasks:
Task with priority 2 (parameter to xTaskCreate)
Task with priority 1
Tasks 1 enters an area locked with a semaphore and hits the line mentioned above. Task 2 should wake up and run until it also wants to enter the locked area.
I think you have misunderstood the ICSR. This is not saying the exception has escalated from a SYSTICK and does not have anything to do with the hard fault.
Firstly you need to look in the HFSR (hard fault status register). If forced is set is means it is either escalated from a bus fault, mem man fault or usage fault (I suspect it will be forced). If it is then look in the CFSR to see what kind of error you have.
You can then debug further from here. If it is a type of bus error (again quite likely) then you need to look at the BFARVALID bit in the CFSR. If this is set then you are lucky as the BFAR register will contain the address of the fault. If this is not set then things get a bit more difficult! Bare in mind then CFSR is actually several registers in one so needs decoding correctly, some of the bits are types of bus error and others are mem man faults etc..
I'm not sure why you would think a [software?] deadlock would cause a hardware hardfault, but some information on debugging hard faults can be found here: http://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html
I would also recommend updating to a newer version of FreeRTOS as the newer the version the more assert() statements are including to catch interrupt priority and other interrupt related misuse and misconfguration.
I have a Netcard eth0，it has single queue and its IRQ number is 63，
My question is：
If I set /proc/irq/63/smp_affinity to fffff
Whether means that the Linux kernel will distribute the IRQ of eth0 to each cpu in my system?
is its function equal to the rps(receive package steering)？
No, the smp_affinity is a bitmask or cpu list of allowed CPUs for this IRQ. For eg if set to 0x1 it will pin that IRQ to CPU 0 ...
No. Setting the smp_affinity to fffff just means that the kernel can use any CPU in the fffff to handle IRQ 63.
If you want to distribute packet processing load with a NIC that only has a single RX queue, you have to use RPS.
Check out a blog post I wrote about this that explains all of this and more in detail.
I got a strange text by 'catting' the /proc/ioports file of my PC linux,
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc0
...
What I dont understand is the anterior part of each entry, look at the first entry for example, does it mean 31(0x1f in hex) ports occupied by dma1? If true, I cannot imagine how many ports on x86 processor, since I know there are only several 8bit ports on a 8bit-MCU.
Can anyone detail the meaning of the number, and the io ports of x86 processor?
It's the list of I/O ports regions that have been claimed by kernel drivers using the request_region kernel function. So it's not the complete list of I/O ports or devices available, only the ones that have been claimed by various kernel drivers. The request_region mechanism allows the kernel to prevent multiple drivers from talking to the same device.
/proc/ioports lists the ranges and names of ioports provided by device drivers in the Linux kernel of ports of the port ranges claimed and handled by said drivers.
As an example, io ports 0070 - 007f are claimed by the RTC Linux kernel driver.
One would assume that said port ranges claimed by the driver correspond to the appropriate port ranges offered by the respective hardware but you should note that there is actually no mechanism that ensures that indeed they are.