In Cortex-A7 TRM, we can access internal L1 cache related memory via CP15 instructions. We can retreive Tag RAM/Dirty RAM MOESI state of specific cache line. As stated here.
However, it is not mentioned anywhere the detail about the 4-bit MOESI encoding (e.g. 000 refer to what state, etc.). Not anywhere in Armv7-A TRM either. Also, it said 4-bit, but won't 3-bit suffice to encode the 5 MOESI states (UC,UD,SC,SD,I).
Did I miss something?
It seems like ARM only provide these information to its Debug and Silicon partners. I posted on ARM Community with an answer : https://community.arm.com/thread/10498
Related
A (hopefully) simple question.
Can I create my MMU page tables in ARM tightly coupled memory, or is there a restriction that prevents me doing this.
I have 16k of data TCM that seems quite suitable for this task (the instruction TCM will contain my secure world code), but I'm getting abort exceptions when enabling the MMU.
When I compile my secure world code to target SRAM everything works as expected. The problem is that on this SoC SRAM is available from an FPGA-like device that does not respect TrustZone at all.
Am I missing something here, or do I need to carve off a small piece of RAM for myself to get this all working?
I'm working on an ARM1176JZ-S.
So, many years later I found my answer in the ARM Architecture Reference Manual for ARMv6 while browsing around for something completely different!
In section B4.7.3, Page table translation in VMSAv6 (page B4-25), the answer is mentioned just after discussing whether L1 cache is used in the page table walk, and it says:
Hardware page table walks cannot cause reads from TCM.
any apps or the system kernel can access or even modify the content of CPU cahce and/or TLB?
I found a short description about the CPU cache from this webiste:
"No programming language has direct access to CPU cache. Reading and writing the cache is something done automatically by the hardware; there's NO way to write instructions which treat the cache as any kind of separate entity. Reads and writes to the cache happen as side-effect to all instructions that touch memory."
From this message, it seems there is no way to read/write the content of CPU cahce/TLB.
However, I also got another information that conflicts with the above one. That information implies that a debug tool may be able to dump/show the content of CPU cache.
Currently I'm confused. so please help me.
I got some answers from another post: dump the contents of TLB buffer of x86 CPU. Thanks adamdunson.
People could read this document about test registers, but it is only available on very old x86 machines test registers
Another descriptions from wiki https://en.wikipedia.org/wiki/Test_register:
A test register, in the Intel 80486 processor, was a register used by
the processor, usually to do a self-test. Most of these registers were
undocumented, and used by specialized software. The test registers
were named TR3 to TR7. Regular programs don't usually require these
registers to work. With the Pentium, the test registers were replaced
by a variety of model-specific registers (MSRs).
Two test registers, TR6 and TR7, were provided for the purpose of
testing. TR6 was the test command register, and TR7 was the test data
register. These registers were accessed by variants of the MOV
instruction. A test register may either be the source operand or the
destination operand. The MOV instructions are defined in both
real-address mode and protected mode. The test registers are
privileged resources. In protected mode, the MOV instructions that
access them can only be executed at privilege level 0. An attempt to
read or write the test registers when executing at any other privilege
level causes a general protection exception. Also, those instructions
generate invalid opcode exception on any CPU newer than 80486.
In fact, I'm still expecting some similar functions on Intel i7 or i5. Unfortunately, I do not find any related document about that. If anyone has such information, please let me know.
As per the kernel documentation of gic device tree bindings
"Primary GIC is attached directly to the CPU and typically has PPIs and SGIs."
"Secondary GICs are cascaded into the upward interrupt controller and do not
have PPIs or SGIs."
I do not find the term primary/secondary GIC in GIC-400.
Can anyone please describe the difference or point to the document which tell something about it.
The terminology Primary and Secondary is Linux terminology. You will not find it in an ARM data sheet. The PPIs are banked per-CPU. The code can execute on any CPU, so only the extra interrupts maybe set. I think this is rather pedantic as most systems will only have one controller.
Find out how many interrupts are supported.
The GIC only supports up to 1020 interrupt sources.
This comes from allocation of the address space on the controller. There is only decode room to fit 1020 external interrupts. Note, the define CONFIG_GIC_NON_BANKED and the note Frankein-GIC without banked registers... It is most normal that in an SMP-ARM that the GIC will service all cores. The variable gic_nr tracks the number of controllers. If you have more that 1020 interrupt sources, you need another controller.
Can anyone please describe the difference?
The primary will service the PPIs. The PPI exist on the 2nd controller, but they are redundant. The 2nd (and higher) controllers are just for external interrupts.
I have read article of Duartes from: http://duartes.org/gustavo/blog/post/how-the-kernel-manages-your-memory
In part that describes about PTE content, bit [0:11] is different with description in ARMv5 Architecture Reference Manual
Detail is:
Bit [0:11] of the PTE contain:
In Duartes article: bit 0: P (present), bit 1: R/W , bit 2: U/S (user/supervisor),...
In ARMv5 Architecture Reference Manual : Bits[1:0] Identify the type of descriptor (0b11 marks a fine page table descriptor), Bits[4:2]: The meaning of these bits is IMPLEMENTATION DEFINED,...
(Refer at: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0198e/I16780.html ) . I think the Second-level descriptor in ARMv5 Architecture Reference Manual is corresponding with PTE in Duartes's article.
So, question is the PTE descriptor is depending on platform (x86, ARM,...) ?.
For me, I think PTE descriptor should not depend on platform.
Thanks
As each architecture implement their MMU (memory management unit) differently, the PTE descriptor is architecture dependent.
If we look at Linux, it has a three level page table structure (inherited from the x86 architecture), which in most ARM platforms is wrapped to fit a two level page table structure (newer ARM have support for 3 levels). Linux also uses "dirty" and "accessed" bit that is available in the x86 architecture for the memory management logic of the kernel. These bits are not available in the ARM architecture, which ARM Linux has solved by emulating it in software. This is done by having two versions of the PTE page tables. One for the OS which contains these missing "bits", and one for the actual HW to use.
In the end, the Linux OS for different architectures behave the same. It's all about how the OS are using the hardware mechanisms that the specific architecture is offering as there are pro and cons for each.
The ARM Linux code is different depending on the type of ARM and other conditionals. pgtable.h, page.h and mostly pgtable-2level.h give some details. There are two versions of PTE values; one for Linux and one for hardware.
I'm working on a boot loader on an x86 machine.
When the BIOS copies the contents of the MBR to 0x7c00 and jumps to that address, is there a standard meaning to the contents of the registers? Do the registers have standard values?
I know that the segment registers are typically set to 0, but will sometimes be 0x7c0. What about the other hardware registers?
This early execution environment is highly implementation defined, meaning the implementation of your particular BIOS. Never make any assumptions on the contents of registers. They might be initialized to 0, but they might contain a random value just as well.
from the OS dev Wiki, which is where I get information when I'm playing with my toy OS's
Best option would be to assume nothing. If they have meaning, you will find that from the other side when you need the information they provide.
Undefined, I believe? I think it depends on the mainboard and CPU, and should be treated as random for your own good.
Safest bet is to assume undefined.
Always assume undefined, otherwise you'll hit bad problems if you ever try to port architectures.
There is nothing quite like the pain of porting code that assumes everything uninitialized will be set to zero.
The only thing that I know to be well defined is the processor state immediately after reset.
For the record you can find that in Intel's Software Developer's Manual Vol 3 chapter 8: "PROCESSOR MANAGEMENT AND INITIALIZATION" in the table titled " IA-32 Processor States Following Power-up, Reset, or INIT"
You can always initialize them yourself to start with a known state.