Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 14
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 14 1月, 2014 1 次提交
    • P
      MIPS: Support for 64-bit FP with O32 binaries · 597ce172
      由 Paul Burton 提交于 
      CPUs implementing MIPS32 R2 may include a 64-bit FPU, just as MIPS64 CPUs
do. In order to preserve backwards compatibility a 64-bit FPU will act
like a 32-bit FPU (by accessing doubles from the least significant 32
bits of an even-odd pair of FP registers) when the Status.FR bit is
zero, again just like a mips64 CPU. The standard O32 ABI is defined
expecting a 32-bit FPU, however recent toolchains support use of a
64-bit FPU from an O32 MIPS32 executable. When an ELF executable is
built to use a 64-bit FPU a new flag (EF_MIPS_FP64) is set in the ELF
header.

With this patch the kernel will check the EF_MIPS_FP64 flag when
executing an O32 binary, and set Status.FR accordingly. The addition
of O32 64-bit FP support lessens the opportunity for optimisation in
the FPU emulator, so a CONFIG_MIPS_O32_FP64_SUPPORT Kconfig option is
introduced to allow this support to be disabled for those that don't
require it.

Inspired by an earlier patch by Leonid Yegoshin, but implemented more
cleanly & correctly.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Paul Burton <paul.burton@imgtec.com>
Patchwork: https://patchwork.linux-mips.org/patch/6154/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      597ce172
  3. 09 11月, 2013 1 次提交
  5. 30 10月, 2013 23 次提交
  7. 10 10月, 2013 3 次提交
  9. 07 10月, 2013 1 次提交
    • J
      MIPS: stack protector: Fix per-task canary switch · 8b3c569a
      由 James Hogan 提交于 
      Commit 1400eb65 (MIPS: r4k,octeon,r2300: stack protector: change canary
per task) was merged in v3.11 and introduced assembly in the MIPS resume
functions to update the value of the current canary in
__stack_chk_guard. However it used PTR_L resulting in a load of the
canary value, instead of PTR_LA to construct its address. The value is
intended to be random but is then treated as an address in the
subsequent LONG_S (store).

This was observed to cause a fault and panic:

CPU 0 Unable to handle kernel paging request at virtual address 139fea20, epc == 8000cc0c, ra == 8034f2a4
Oops[#1]:
...
$24   : 139fea20 1e1f7cb6
...
Call Trace:
[<8000cc0c>] resume+0xac/0x118
[<8034f2a4>] __schedule+0x5f8/0x78c
[<8034f4e0>] schedule_preempt_disabled+0x20/0x2c
[<80348eec>] rest_init+0x74/0x84
[<804dc990>] start_kernel+0x43c/0x454
Code: 3c18804b  8f184030  8cb901f8 <af190000> 00c0e021  8cb002f0 8cb102f4  8cb202f8  8cb302fc

This can also be forced by modifying
arch/mips/include/asm/stackprotector.h so that the default
__stack_chk_guard value is more likely to be a bad (or unaligned)
pointer.

Fix it to use PTR_LA instead, to load the address of the canary value,
which the LONG_S can then use to write into it.

Reported-by: bobjones (via #mipslinux on IRC)
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Gregory Fong <gregory.0xf0@gmail.com>
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/6026/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      8b3c569a
  11. 04 10月, 2013 1 次提交
  13. 19 9月, 2013 2 次提交
  15. 18 9月, 2013 1 次提交
  17. 13 9月, 2013 3 次提交
    • M
      MIPS: kernel: vpe: Make vpe_attrs an array of pointers. · 1b467633
      由 Markos Chandras 提交于 
      Commit 567b21e9
"mips: convert vpe_class to use dev_groups"

broke the build on MIPS since vpe_attrs should be an array
of 'struct device_attribute' pointers.

Fixes the following build problem:
arch/mips/kernel/vpe.c:1372:2: error: missing braces around initializer
[-Werror=missing-braces]
arch/mips/kernel/vpe.c:1372:2: error: (near initialization for 'vpe_attrs[0]')
[-Werror=missing-braces]

Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: John Crispin <blogic@openwrt.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5819/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      1b467633
    • L
      MIPS: Fix SMP core calculations when using MT support. · 670bac3a
      由 Leonid Yegoshin 提交于 
      The TCBIND register is only available if the core has MT support. It
should not be read otherwise. Secondly, the number of TCs (siblings)
are calculated differently depending on if the kernel is configured
as SMVP or SMTC.
Signed-off-by: NLeonid Yegoshin <Leonid.Yegoshin@imgtec.com>
Signed-off-by: NSteven J. Hill <Steven.Hill@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5822/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      670bac3a
    • M
      MIPS: DECstation HRT initialization rearrangement · daed1285
      由 Maciej W. Rozycki 提交于 
      Not all I/O ASIC versions have the free-running counter implemented, an
early revision used in the 5000/1xx models aka 3MIN and 4MIN did not have
it.  Therefore we cannot unconditionally use it as a clock source.
Fortunately if not implemented its register slot has a fixed value so it
is enough if we check for the value at the end of the calibration period
being the same as at the beginning.

This also means we need to look for another high-precision clock source on
the systems affected.  The 5000/1xx can have an R4000SC processor
installed where the CP0 Count register can be used as a clock source.
Unfortunately all the R4k DECstations suffer from the missed timer
interrupt on CP0 Count reads erratum, so we cannot use the CP0 timer as a
clock source and a clock event both at a time.  However we never need an
R4k clock event device because all DECstations have a DS1287A RTC chip
whose periodic interrupt can be used as a clock source.

This gives us the following four configuration possibilities for I/O ASIC
DECstations:

1. No I/O ASIC counter and no CP0 timer, e.g. R3k 5000/1xx (3MIN).

2. No I/O ASIC counter but the CP0 timer, i.e. R4k 5000/150 (4MIN).

3. The I/O ASIC counter but no CP0 timer, e.g. R3k 5000/240 (3MAX+).

4. The I/O ASIC counter and the CP0 timer, e.g. R4k 5000/260 (4MAX+).

For #1 and #2 this change stops the I/O ASIC free-running counter from
being installed as a clock source of a 0Hz frequency.  For #2 it also
arranges for the CP0 timer to be used as a clock source rather than a
clock event device, because having an accurate wall clock is more
important than a high-precision interval timer.  For #3 there is no
change.  For #4 the change makes the I/O ASIC free-running counter
installed as a clock source so that the CP0 timer can be used as a clock
event device.

Unfortunately the use of the CP0 timer as a clock event device relies on a
succesful completion of c0_compare_interrupt.  That never happens, because
while waiting for a CP0 Compare interrupt to happen the function spins in
a loop reading the CP0 Count register.  This makes the CP0 Count erratum
trigger reliably causing the interrupt waited for to be lost in all cases.
As a result #4 resorts to using the CP0 timer as a clock source as well,
just as #2.  However we want to keep this separate arrangement in case
(hope) c0_compare_interrupt is eventually rewritten such that it avoids
the erratum.
Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5825/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      daed1285
  19. 06 9月, 2013 3 次提交
    • P
      MIPS: kexec: Fix random crashes while loading crashkernel · c2882b7f
      由 Prem Mallappa 提交于 
      Fixed compilation errors in case of non-KEXEC kernel
Rearranging code so that crashk_res gets updated.
- crashk_res is updated after mips_parse_crashkernel(),
   after resource_init(), which is after arch_mem_init().
- The reserved memory is actually treated as Usable memory,
   Unless we load the crash kernel, everything works.
Signed-off-by: NPrem Mallappa <pmallappa@caviumnetworks.com>
Cc: linux-mips <linux-mips@linux-mips.org>
Patchwork: http://patchwork.linux-mips.org/patch/5805/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      c2882b7f
    • P
      MIPS: kdump: Skip walking indirection page for crashkernels · 273463b7
      由 Prem Mallappa 提交于 
      KDUMP: skip indirection page, as crashkernel has already copied to destination

[ralf@linux-mips.org: cosmetic changes.]
Signed-off-by: NPrem Mallappa <pmallappa@caviumnetworks.com>
Cc: linux-mips <linux-mips@linux-mips.org>
Patchwork: https://patchwork.linux-mips.org/patch/5786/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      273463b7
    • M
      MIPS: DECstation HRT calibration bug fixes · 8533966a
      由 Maciej W. Rozycki 提交于 
      This change corrects DECstation HRT calibration, by removing the following
bugs:

1. Calibration period selection -- HZ / 10 has been chosen, however on
   DECstation computers, HZ never divides by 10, as the choice for HZ is
   among 128, 256 and 1024.  The choice therefore results in a systematic
   calibration error, e.g. 6.25% for the usual choice of 128 for HZ:

   128 / 10 * 10 = 120

   (128 - 120) / 128 -> 6.25%

   The change therefore makes calibration use HZ / 8 that is always
   accurate for the HZ values available, getting rid of the systematic
   error.

2. Calibration starting point synchronisation -- the duration of a number
   of intervals between DS1287A periodic interrupt assertions is measured,
   however code does not ensure at the beginning that the interrupt has
   not been previously asserted.  This results in a variable error of e.g.
   up to another 6.25% for the period of HZ / 8 (8.(3)% with the original
   HZ / 10 period) and the usual choice of 128 for HZ:

   1 / 16 -> 6.25%

   1 / 12 -> 8.(3)%

   The change therefore adds an initial call to ds1287_timer_state that
   clears any previous periodic interrupt pending.

The same issue applies to both I/O ASIC counter and R4k CP0 timer
calibration on DECstation systems as similar code is used in both cases
and both pieces of code are covered by this fix.

On an R3400 test system used this fix results in a change of the I/O ASIC
clock frequency reported from values like:

I/O ASIC clock frequency 23185830Hz

to:

I/O ASIC clock frequency 24999288Hz

removing the miscalculation by 6.25% from the systematic error and (for
the individual sample provided) a further 1.00% from the variable error,
accordingly.  The nominal I/O ASIC clock frequency is 25MHz on this
system.

Here's another result, with the fix applied, from a system that has both
HRTs available (using an R4400 at 60MHz nominal):

MIPS counter frequency 59999328Hz
I/O ASIC clock frequency 24999432Hz
Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5807/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      8533966a
  21. 04 9月, 2013 1 次提交