- 30 4月, 2019 40 次提交
-
-
由 Philippe Mathieu-Daudé 提交于
Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190412165416.7977-12-philmd@redhat.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Philippe Mathieu-Daudé 提交于
Reviewed-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190412165416.7977-11-philmd@redhat.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Philippe Mathieu-Daudé 提交于
Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190412165416.7977-10-philmd@redhat.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Philippe Mathieu-Daudé 提交于
Since uWireSlave is only used in this new header, there is no need to expose it via "qemu/typedefs.h". Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190412165416.7977-9-philmd@redhat.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Philippe Mathieu-Daudé 提交于
Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190412165416.7977-8-philmd@redhat.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Philippe Mathieu-Daudé 提交于
Reviewed-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190412165416.7977-7-philmd@redhat.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Philippe Mathieu-Daudé 提交于
Add an entries the Blizzard device in MAINTAINERS. Reviewed-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190412165416.7977-6-philmd@redhat.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Philippe Mathieu-Daudé 提交于
Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190412165416.7977-5-philmd@redhat.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Philippe Mathieu-Daudé 提交于
No code used the tc6393xb_gpio_in_get() and tc6393xb_gpio_out_set() functions since their introduction in commit 88d2c950. Time to remove them. Suggested-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190412165416.7977-4-philmd@redhat.com Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Philippe Mathieu-Daudé 提交于
Suggested-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190412165416.7977-3-philmd@redhat.com Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Philippe Mathieu-Daudé 提交于
Reviewed-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NCédric Le Goater <clg@kaod.org> Reviewed-by: NMarkus Armbruster <armbru@redhat.com> Signed-off-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190412165416.7977-2-philmd@redhat.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Philippe Mathieu-Daudé 提交于
This device is used by both ARM (BCM2836, for raspi2) and AArch64 (BCM2837, for raspi3) targets, and is not CPU-specific. Move it to common object, so we build it once for all targets. Signed-off-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190427133028.12874-1-philmd@redhat.com Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Peter Maydell 提交于
Enable the FPU by default for the Cortex-M4 and Cortex-M33. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20190416125744.27770-27-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
Implement the VLLDM instruction for v7M for the FPU present cas. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20190416125744.27770-26-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
Implement the VLSTM instruction for v7M for the FPU present case. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20190416125744.27770-25-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
The M-profile architecture floating point system supports lazy FP state preservation, where FP registers are not pushed to the stack when an exception occurs but are instead only saved if and when the first FP instruction in the exception handler is executed. Implement this in QEMU, corresponding to the check of LSPACT in the pseudocode ExecuteFPCheck(). Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20190416125744.27770-24-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
Pushing registers to the stack for v7M needs to handle three cases: * the "normal" case where we pend exceptions * an "ignore faults" case where we set FSR bits but do not pend exceptions (this is used when we are handling some kinds of derived exception on exception entry) * a "lazy FP stacking" case, where different FSR bits are set and the exception is pended differently Implement this by changing the existing flag argument that tells us whether to ignore faults or not into an enum that specifies which of the 3 modes we should handle. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20190416125744.27770-23-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
In the v7M architecture, if an exception is generated in the process of doing the lazy stacking of FP registers, the handling of possible escalation to HardFault is treated differently to the normal approach: it works based on the saved information about exception readiness that was stored in the FPCCR when the stack frame was created. Provide a new function armv7m_nvic_set_pending_lazyfp() which pends exceptions during lazy stacking, and implements this logic. This corresponds to the pseudocode TakePreserveFPException(). Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20190416125744.27770-22-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
Add a new helper function which returns the MMU index to use for v7M, where the caller specifies all of the security state, privilege level and whether the execution priority is negative, and reimplement the existing arm_v7m_mmu_idx_for_secstate_and_priv() in terms of it. We are going to need this for the lazy-FP-stacking code. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20190416125744.27770-21-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
The M-profile FPCCR.ASPEN bit indicates that automatic floating-point context preservation is enabled. Before executing any floating-point instruction, if FPCCR.ASPEN is set and the CONTROL FPCA/SFPA bits indicate that there is no active floating point context then we must create a new context (by initializing FPSCR and setting FPCA/SFPA to indicate that the context is now active). In the pseudocode this is handled by ExecuteFPCheck(). Implement this with a new TB flag which tracks whether we need to create a new FP context. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20190416125744.27770-20-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
The M-profile FPCCR.S bit indicates the security status of the floating point context. In the pseudocode ExecuteFPCheck() function it is unconditionally set to match the current security state whenever a floating point instruction is executed. Implement this by adding a new TB flag which tracks whether FPCCR.S is different from the current security state, so that we only need to emit the code to update it in the less-common case when it is not already set correctly. Note that we will add the handling for the other work done by ExecuteFPCheck() in later commits. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20190416125744.27770-19-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
We are close to running out of TB flags for AArch32; we could start using the cs_base word, but before we do that we can economise on our usage by sharing the same bits for the VFP VECSTRIDE field and the XScale XSCALE_CPAR field. This works because no XScale CPU ever had VFP. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20190416125744.27770-18-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
Move the NS TBFLAG down from bit 19 to bit 6, which has not been used since commit c1e37810 in 2015, when we started passing the entire MMU index in the TB flags rather than just a 'privilege level' bit. This rearrangement is not strictly necessary, but means that we can put M-profile-only bits next to each other rather than scattered across the flag word. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20190416125744.27770-17-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
Handle floating point registers in exception return. This corresponds to pseudocode functions ValidateExceptionReturn(), ExceptionReturn(), PopStack() and ConsumeExcStackFrame(). Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20190416125744.27770-16-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
The magic value pushed onto the callee stack as an integrity check is different if floating point is present. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20190416125744.27770-15-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
The TailChain() pseudocode specifies that a tail chaining exception should sanitize the excReturn all-ones bits and (if there is no FPU) the excReturn FType bits; we weren't doing this. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20190416125744.27770-14-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
For v8M floating point support, transitions from Secure to Non-secure state via BLNS and BLXNS must clear the CONTROL.SFPA bit. (This corresponds to the pseudocode BranchToNS() function.) Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20190416125744.27770-13-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
Implement the code which updates the FPCCR register on an exception entry where we are going to use lazy FP stacking. We have to defer to the NVIC to determine whether the various exceptions are currently ready or not. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Message-id: 20190416125744.27770-12-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
Handle floating point registers in exception entry. This corresponds to the FP-specific parts of the pseudocode functions ActivateException() and PushStack(). We defer the code corresponding to UpdateFPCCR() to a later patch. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20190416125744.27770-11-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
Currently the code in v7m_push_stack() which detects a violation of the v8M stack limit simply returns early if it does so. This is OK for the current integer-only code, but won't work for the floating point handling we're about to add. We need to continue executing the rest of the function so that we check for other exceptions like not having permission to use the FPU and so that we correctly set the FPCCR state if we are doing lazy stacking. Refactor to avoid the early return. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20190416125744.27770-10-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
The M-profile CONTROL register has two bits -- SFPA and FPCA -- which relate to floating-point support, and should be RES0 otherwise. Handle them correctly in the MSR/MRS register access code. Neither is banked between security states, so they are stored in v7m.control[M_REG_S] regardless of current security state. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20190416125744.27770-9-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
If the floating point extension is present, then the SG instruction must clear the CONTROL_S.SFPA bit. Implement this. (On a no-FPU system the bit will always be zero, so we don't need to make the clearing of the bit conditional on ARM_FEATURE_VFP.) Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20190416125744.27770-8-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
Correct the decode of the M-profile "coprocessor and floating-point instructions" space: * op0 == 0b11 is always unallocated * if the CPU has an FPU then all insns with op1 == 0b101 are floating point and go to disas_vfp_insn() For the moment we leave VLLDM and VLSTM as NOPs; in a later commit we will fill in the proper implementation for the case where an FPU is present. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20190416125744.27770-7-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
Like AArch64, M-profile floating point has no FPEXC enable bit to gate floating point; so always set the VFPEN TB flag. M-profile also has CPACR and NSACR similar to A-profile; they behave slightly differently: * the CPACR is banked between Secure and Non-Secure * if the NSACR forces a trap then this is taken to the Secure state, not the Non-Secure state Honour the CPACR and NSACR settings. The NSACR handling requires us to borrow the exception.target_el field (usually meaningless for M profile) to distinguish the NOCP UsageFault taken to Secure state from the more usual fault taken to the current security state. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20190416125744.27770-6-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
The only "system register" that M-profile floating point exposes via the VMRS/VMRS instructions is FPSCR, and it does not have the odd special case for rd==15. Add a check to ensure we only expose FPSCR. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20190416125744.27770-5-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
The M-profile floating point support has three associated config registers: FPCAR, FPCCR and FPDSCR. It also makes the registers CPACR and NSACR have behaviour other than reads-as-zero. Add support for all of these as simple reads-as-written registers. We will hook up actual functionality later. The main complexity here is handling the FPCCR register, which has a mix of banked and unbanked bits. Note that we don't share storage with the A-profile cpu->cp15.nsacr and cpu->cp15.cpacr_el1, though the behaviour is quite similar, for two reasons: * the M profile CPACR is banked between security states * it preserves the invariant that M profile uses no state inside the cp15 substruct Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20190416125744.27770-4-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
For M-profile the MVFR* ID registers are memory mapped, in the range we implement via the NVIC. Allow them to be read. (If the CPU has no FPU, these registers are defined to be RAZ.) Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20190416125744.27770-3-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
Enforce that for M-profile various FPSCR bits which are RES0 there but have defined meanings on A-profile are never settable. This ensures that M-profile code can't enable the A-profile behaviour (notably vector length/stride handling) by accident. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20190416125744.27770-2-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
Normally configure identifies the source path by looking at the location where the configure script itself exists. We also provide a --source-path option which lets the user manually override this. There isn't really an obvious use case for the --source-path option, and in commit 92712822 in 2017 we accidentally added some logic that looks at $source_path before the command line option that overrides it has been processed. The fact that nobody complained suggests that there isn't any use of this option and we aren't testing it either; remove it. This allows us to move the "make $source_path absolute" logic up so that there is no window in the script where $source_path is set but not yet absolute. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com> Message-id: 20190318134019.23729-1-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
In the stripe8() function we use a variable length array; however we know that the maximum length required is MAX_NUM_BUSSES. Use a fixed-length array and an assert instead. Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NFrancisco Iglesias <frasse.iglesias@gmail.com> Reviewed-by: NAlistair Francis <alistair.francis@wdc.com> Reviewed-by: NStefano Garzarella <sgarzare@redhat.com> Message-id: 20190328152635.2794-1-peter.maydell@linaro.org
-