search for: spsr

...o, evtchn_upcall_pending)); + DEFINE(OFFSET_ARCH_VCPU_INFO, offsetof(struct vcpu_info, arch)); + DEFINE(OFFSET_TSP, offsetof(struct arch_vcpu_info, sp)); + DEFINE(OFFSET_TLR, offsetof(struct arch_vcpu_info, lr)); + DEFINE(OFFSET_TCPSR, offsetof(struct arch_vcpu_info, cpsr)); + DEFINE(OFFSET_TSPSR, offsetof(struct arch_vcpu_info, spsr)); + DEFINE(OFFSET_VCR, offsetof(struct arch_vcpu_info, cr)); + DEFINE(OFFSET_VDACR, offsetof(struct arch_vcpu_info, dacr)); + DEFINE(OFFSET_VCPAR, offsetof(struct arch_vcpu_info, cpar)); + DEFINE(OFFSET_VPIDR, offsetof(struct arch_vcpu_info, pidr));...

Hello, I am trying to boot Arndale board with Julien''s new XenARM patch series. But I have got "Data Abort" while in booting. My environment is: - Arndale Board - Xen-4.3-unstable from branch "arm" in git://xenbits.xen.org/people/julieng/xen-unstable.git - Dom0 Kernel from branch "dev-arndale-dom0-3.9" in

...-- Exit Code: 1 Command Output (stderr): -- <stdin>:1356:9: error: instruction requires: armv7m mrs r8, apsr ^ <stdin>:1357:9: error: instruction requires: armv7m mrs r8, cpsr ^ <stdin>:1358:9: error: instruction requires: armv7m mrs r8, spsr ^ and the second was the same for basic-arm-instructions.s. The problem seems to be that the MSRMask parser is then always used, even for non-M-class. Richard

...he binary. The D0 has id 14 on ARM because there are 13 other registers preceding it: namespace ARM { enum { NoRegister, APSR = 1, APSR_NZCV = 2, CPSR = 3, FPEXC = 4, FPINST = 5, FPSCR = 6, FPSCR_NZCV = 7, FPSID = 8, ITSTATE = 9, LR = 10, PC = 11, SP = 12, SPSR = 13, D0 = 14, ... -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

...rm/entry.S b/xen/arch/arm/entry.S index 0b9cce5..36f1119 100644 --- a/xen/arch/arm/entry.S +++ b/xen/arch/arm/entry.S @@ -102,6 +102,10 @@ ENTRY(return_to_guest) ENTRY(return_to_hypervisor) ldr lr, [sp, #UREGS_lr] + ldr r11, [sp, #UREGS_pc] + msr ELR_hyp, r11 + ldr r11, [sp, #UREGS_cpsr] + msr SPSR_hyp, r11 pop {r0-r12} add sp, #(UREGS_R8_fiq - UREGS_sp); /* SP, LR, SPSR, PC */ eret -- 1.7.2.5

Hi Kurt, The assembly parser doesn't (yet) handle these, you're right. Currently, the MRS instruction is split into two variants in the ARMInstrThumb2.td file, t2MRS and t2MRSsys, one for the user mode version reading cpsr and one for the system mode version reading spsr. MSR, by contrast, has a custom parse method for the mask operand since it's a bit more complex than an either/or. You'll likely want to merge the two MRS variants into one and add an operand for the system register, mapping that to the proper encoding bits in the instruction, and use a cu...

...i Kurt, > > The assembly parser doesn't (yet) handle these, you're right. Currently, > the MRS instruction is split into two variants in the ARMInstrThumb2.td > file, t2MRS and t2MRSsys, one for the user mode version reading cpsr and > one for the system mode version reading spsr. MSR, by contrast, has a > custom parse method for the mask operand since it's a bit more complex than > an either/or. > > You'll likely want to merge the two MRS variants into one and add an > operand for the system register, mapping that to the proper encoding bits > in...

I was attempting to compile some code with a recent (r138716) version of llvm/clang, targeting a cortex-m4 processor. And I get an error like this: CC: sched_garbage.c In file included from sched_garbage.c:43: In file included from ./os_internal.h:48: In file included from /p/nuttx/trunk/nuttx/include/sched.h:47: In file included from /p/nuttx/trunk/nuttx/include/nuttx/sched.h:54: In file

...gt; The assembly parser doesn't (yet) handle these, you're right. Currently, > > the MRS instruction is split into two variants in the ARMInstrThumb2.td > > file, t2MRS and t2MRSsys, one for the user mode version reading cpsr and > > one for the system mode version reading spsr. MSR, by contrast, has a > > custom parse method for the mask operand since it's a bit more complex than > > an either/or. > > > > You'll likely want to merge the two MRS variants into one and add an > > operand for the system register, mapping that to the pro...

> /tmp/foo.s:1:2: error: instruction requires: distinct-ops > sllk %r2,%r3,1 > ^ That seems like it would be a good improvement for all targets. > ARM seems to rely on the current MatchOperandParserImpl() behaviour, > so I'm not going to suggest changing it unconditionally. Presumably you switched it and looked at what fell over; do you remember what kind

Dear all, in my TestRegisterInfo.td file, I defined a register like this: class TestReg<bits<6> enc, string name> : Register<name> { let HWEncoding{5-0} = enc; let Namespace = "TEST"; } def D0 : TestReg<0x01, "d0">, DwarfRegNum<[1]>; but when I compile, the result I have in TestGenAsmMatcher.inc is this: case 'd': // 7

...> -- > <stdin>:1356:9: error: instruction requires: armv7m > mrs r8, apsr > ^ > <stdin>:1357:9: error: instruction requires: armv7m > mrs r8, cpsr > ^ > <stdin>:1358:9: error: instruction requires: armv7m > mrs r8, spsr > ^ > > and the second was the same for basic-arm-instructions.s. The problem seems > to be that the MSRMask parser is then always used, even for non-M-class. This seems fixable. The custom parsers that are only valid for certain sub targets could easily have an explicit early...

I'm trying to add some instructions that are only available on certain processors. These instructions use context-dependent parsers. Everything works fine for the valid cases, but if you try to use an instruction on processors that don't support it, the asm parser says: /tmp/foo.s:1:2: error: invalid operands for instruction sllk %r2,%r3,1 ^ rather than:

I last posted this back in April to critical acclaim (AKA near total silence). I''m not sure who looks after tools/include/xen-foreign. I had thought it was Jan but I think I was confused and was thinking of the semi-related xen/include/compat stuff. IOW I think nobody felt "responsible". Unless there''s any objection lets just treat this as coming under tools. The

The following patches shave some rough edges off the tools build system to allow cross compiling for at least arm32 and arm64 based on the Debian/Ubuntu multiarch infrastructure. They also add the necessary fixes to build for arm64 (which I have only tried cross, not native). I have posted some instructions on how to compile with these patches on the wiki:

Hello everyone, this is the fourth version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See

Hello everyone, this is the very first version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See

First off, Apologies for the massive patch series... This series boots a 32-bit dom0 kernel to a command prompt on an ARMv8 (AArch64) model. The kernel is the same one as I am currently using with the 32 bit hypervisor I haven''t yet tried starting a guest or anything super advanced like that ;-). Also there is not real support for 64-bit domains at all, although in one or two places I

I''ve addressed all (I think/hope) of the review comments. The main change is to expose the guest virtual platform (e.g. memory layout and interrupt usage etc) to the toolstack via the public interface. This is then used during FDT generation. I have just codified the current defacto standard layout, it''s probably not the best layout but any change can be a separate patch/series.

This round implements all of the review comments from V2 and all patches are now acked. Unless there are any objections I intend to apply later this morning. Ian.