Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 3 年多

通知 13
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 24 2月, 2011 4 次提交
    • R
      ARM: improve module relocation fixup diagnostics · 68e6fad4
      由 Russell King 提交于 
      Current diagnostics are rather poor when things go wrong:
  ipv6: relocation out of range, section 2 reloc 0 sym 'snmp_mib_free'

Let's include a little more information about the problem:
  ipv6: section 2 reloc 0 sym 'snmp_mib_free': relocation 28 out of range (0xbf0000a4 -> 0xc11b4858)

so that we show exactly what the problem is - not only what type of
relocation but also the offending address range too.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      68e6fad4
    • R
      ARM: add 'uinstall' target for installing uboot kernels · a65d2922
      由 Russell King 提交于 
      We have 'install' and 'zinstall' for installing Image and zImage
kernels, so add 'uinstall' to complete the set.

This allows developers to have a ~/bin/installkernel script which (eg)
copies the kernel to the tftp server automatically once the kernel
has built, resulting in a better workflow.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      a65d2922
    • R
      ARM: fix some sparse errors in generic ARM code · 2bbd7e9b
      由 Russell King 提交于 
      arch/arm/kernel/return_address.c:37:6: warning: symbol 'return_address' was not declared. Should it be static?
arch/arm/kernel/setup.c:76:14: warning: symbol 'processor_id' was not declared. Should it be static?
arch/arm/kernel/traps.c:259:1: warning: symbol 'die_lock' was not declared. Should it be static?
arch/arm/vfp/vfpmodule.c:156:6: warning: symbol 'vfp_raise_sigfpe' was not declared. Should it be static?
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      2bbd7e9b
    • R
      ARM: DMA: top-down allocation in DMA coherent region · 459c1517
      由 Russell King 提交于 
      Achieve better usage of the DMA coherent region by doing top-down
allocation rather than bottom up.  If we ask for a 128kB allocation,
this will be aligned to 128kB and satisfied from the very bottom
address.  If we then ask for a 600kB allocation, this will be aligned
to 1MB, and we will have a 896kB hole.

Performing top-down allocation resolves this by allocating the 128kB
at the very top, and then the 600kB can come in below it without any
unnecessary wastage.

This problem was reported by Janusz Krzysztofik, who had 2 x 128kB +
1 x 640kB allocations which wouldn't fit into 1MB.
Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      459c1517
  3. 16 2月, 2011 1 次提交
  5. 01 2月, 2011 11 次提交
  7. 31 1月, 2011 17 次提交
  9. 30 1月, 2011 1 次提交
  11. 29 1月, 2011 6 次提交