If we have a dual-core ARM CPU, does that mean we also have all COprocessors as "dual-cored"?
I mean, do we have two sets of cp14 or cp15 registers in this case?
Thank you!
I believe each core would have the same debug hw registers IF the maker of the SOC device compiled that silicon IP into each core (which is likely). You'll have to interrogate each core to see if it's supported. Then you'd have to execute the instructions accessing CP14 etc from the core in question (to access its CP14)
Related
As I was reading through the kernel source code I noticed that a mapping between the physical core id and the virtual core number is being created. This could be because there is some degree of uncertainty in the order in which the cores are brought up.
In a multi-core system, which physical core is the first to boot? Is it always physical core #0? Does this hold for x86, x64, ARM and ARM64?
According to the Intel SDM, in recent Intel processors the selection of the bootstrap processor (BSP) is handled either "through a special system bus cycle" or "by platform-specific arrangement of the combination of hardware, BIOS, and/or configuration input options."
In my experience (with Intel processors only), the BSP always has APIC ID 0 (although this is not guaranteed). However, I don't know whether that means that it is always the same physical core within the processor, or even if there is any way to tell.
For more information, see section 8.4 of the Intel SDM, volume 3A.
I was going through the logs after booting up the intel edison. I came accross the word. Is it the name of bios?Does it do some security verification like key matching/checking and all ?
Intel Edison board, more precisely Intel Tangier SoC, has a Minute IA (i486+, also known as Pentium ISA microarchitecture) based MCU (for example, Intel Quark D2000 SoC has it as far as I know) which is part of so called Platform Services Hub (PSH). PSH has own Page Cache (to keep RTOS and its applications), LAPIC. The peripheral, such as DMA and I2C, is shared with System Controller Unit (SCU). SCU actually controls PSH.
When system starts MCU boots first. Inside it is a Viper RTOS with some modifications, i.e. it has a library to support sensors.
There is no information available from Intel regarding use of open source RTOS, such as Zephyr, on PSH.
I am currently trying to access the registers of the ARM9 core on the Zynq Z702 SoC using the XIlinx's XMD tool provided as part of the SDK. When I try to read a part of memory, I am getting an MMU related error. Do i need some specialized hardware to read and write to these registers when running an OS on the processor. Please help.
P.S. : I am running Linux 3.x.x kernel on the processor and the memory region I am trying to access are memory mapped regions and are not occupied by any kernel or user-space code.
I wanna know if normal practice of setting the breakpoints, step-in & step-out works same for the code which reside on ROM also. Do we have to do something extra for ROM debugging.
It will depend largely on the processor an the debug hardware you use. Many microcontrollers include on-chip debug hardware that includes hardware breakpoints that are essentially program-counter comparators. Other facilities may be supported such as data access break-points and instruction trace - essentially an on-chip in-circuit emulator (ICE).
Hardware breakpoints are a necessarily limited resource; for example ARM7 devices have just two while ARM Cortex-M3/4 are endowed with eight.
Either way, to utilise on-chip debug you require suitable debugger hardware (often via JTAG, or a vendor proprietary interface) to interface the target to the host debugger software.
For chips without on-chip debug, you typically use an in-circuit emulator. This is debug hardware that connects to the target board in place of the processor and can be controlled directly by the host debug software. The emulator hardware executes instructions identically to the actual processor but can be halted and stepped and have breakpoints set. Essentially the ICE works like a special version of the target processor with debug support. A true ICE is uncommon on modern processors since on-chip debug capabilities are almost ubiquitous even on small devices such as PIC and AVR, however some external debug hardware can support features not available on on-chip debug. For example Segger's J-Link supports unlimited break-points on ARM7 and Cortex-M3/4.
Linux kernel 3.9 support ARM processor for KVM. (http://kernelnewbies.org/Linux_3.9)
There should be CPU H/W support for KVM such as Intel VT or AMD-V. So, my questions are:
What kind of ARM processors can be used for KVM?
What ARM technologies enables KVM on ARM?
Best Regards.
I found this information from Linux kernel commits (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=749cf76c5a363e1383108a914ea09530bfa0bd43).
Only supported core is Cortex-A15 for now.
And, ARM Coretex A15 provides H/W Virtualization Extension and LPAE(Large Physical Address Extension). Please see this document for more information.
I collected some related information in my blog. It's written in Korean, but you can use Google translate.