Hi all,
In v4:
- Implemented kgdb_nmi serial driver, it provides 'nmi_console' KDB
command. With the driver we can use our debugger port as a normal
console, except that we can always get back to the debugger using the
magic sequence. Note that I still somewhat reluctant to introduce
software-raised interrupts, as they're arch-specific and not always
possible. So today the driver uses a tasklet, it should be pretty
cheap: we're checking for the input on timer interrupts, but we don't
cause needless wakeups. The pro of this is that it works everywhere
(but arches still have an option to optimize things, of course);
- Two new patches added to propagate init_poll() callbacks from tty
to uart drivers. As a side-effect, a long-standing bug fixed in
amba-pl1011 driver;
- Dropped patch 'Get rid of .LCcralign local label';
- Some more fixes in SVC return path. Now it seems rock-solid;
- The patches were rebased on the latest Linus' tree, and as usual can
be found in the following repo:
git://git.infradead.org/users/cbou/linux-nmi-kdb.git master
Boilerplate:
These patches introduce KGDB FIQ debugger support. The idea (and some
code, of course) comes from Google's FIQ debugger[2]. There are some
differences (mostly implementation details, feature-wise they're almost
equivalent, or can be made equivalent, if desired).
The FIQ debugger is a facility that can be used to debug situations when
the kernel stuck in uninterruptable sections, e.g. the kernel infinitely
loops or deadlocked in an interrupt or with interrupts disabled. On some
development boards there is even a special NMI button, which is very
useful for debugging weird kernel hangs.
And FIQ is basically an NMI, it has a higher priority than IRQs, and
upon IRQ exception FIQs are not disabled. It is still possible to
disable FIQs (as well as some "NMIs" on other architectures), but via
special means.
So, here FIQs and NMIs are synonyms, but in the code I use NMI term for
arch-independent code, and FIQs for ARM code.
A few years ago KDB wasn't yet ready for production, or even not
well-known, so originally Google implemented its own FIQ debugger that
included its own shell, ring-buffer, commands, dumping, backtracing
logic and whatnot. This is very much like PowerPC's xmon
(arch/powerpc/xmon), except that xmon was there for a decade, so it even
predates KDB.
Anyway, nowadays KGDB/KDB is the cross-platform debugger, and the only
feature that was missing is NMI handling. This is now fixed for ARM.
There are a few differences comparing to the original (Google's) FIQ
debugger:
- Doing stuff in FIQ context is dangerous, as there we are not allowed
to cause aborts or faults. In the original FIQ debugger there was a
"signal" software-induced interrupt, upon exit from FIQ it would fire,
and we would continue to execute "dangerous" commands from there.
In KGDB/KDB we don't use signal interrupts. We can do easier: set up a
breakpoint, continue, and you'll trap into KGDB again in a safe
context.
It works for most cases, but I can imagine cases when you can't set up
a breakpoint. For these cases we'd better introduce a KDB command
"exit_nmi", that will rise the SW IRQ, after which we're allowed to do
anything.
- KGDB/KDB FIQ debugger shell is synchronous. In Google's version you
could have a dedicated shell always running in the FIQ context, so
when you type something on a serial line, you won't actually cause any
debugging actions, FIQ would save the characters in its own buffer and
continue execution normally. But when you hit return key after the
command, then the command is executed.
In KGDB/KDB FIQ debugger it is different. Once you enter KGDB, the
kernel will stop until you instruct it to continue.
This might look as a drastic change, but it is not. There is actually
no difference whether you have sync or async shell, or at least I
couldn't find any use-case where this would matter at all. Anyways, it
is still possible to do async shell in KDB, just don't see any need
for this.
- Original FIQ debugger used a custom FIQ vector handling code, w/ a lot
of logic in it. In this approach I'm using the fact that FIQs are
basically IRQs, except that we there are a bit more registers banked,
and we can actually trap from the IRQ context.
But this all does not prevent us from using a simple jump-table based
approach as used in the generic ARM entry code. So, here I just reuse
the generic approach.
Note that I test the code on a modelled ARM machine (QEMU Versatile), so
there might be some issues on a real HW, but it works in QEMU tho. :-)
Assuming you have QEMU >= 1.1.0, you can easily play with the code using
ARM/versatile defconfig and command like this:
qemu-system-arm -nographic -machine versatilepb -kernel
linux/arch/arm/boot/zImage -append "console=ttyAMA0 kgdboc=ttyAMA0
kgdb_fiq.enable=1"
Thanks,
--
arch/arm/Kconfig | 19 ++
arch/arm/common/vic.c | 28 +++
arch/arm/include/asm/hardware/vic.h | 2 +
arch/arm/include/asm/kgdb.h | 8 +
arch/arm/kernel/Makefile | 1 +
arch/arm/kernel/entry-armv.S | 167 +----------------
arch/arm/kernel/entry-header.S | 170 ++++++++++++++++++
arch/arm/kernel/kgdb_fiq.c | 99 ++++++++++
arch/arm/kernel/kgdb_fiq_entry.S | 87 +++++++++
arch/arm/mach-versatile/Makefile | 1 +
arch/arm/mach-versatile/kgdb_fiq.c | 31 ++++
drivers/tty/serial/Kconfig | 19 ++
drivers/tty/serial/Makefile | 1 +
drivers/tty/serial/amba-pl011.c | 60 +++++--
drivers/tty/serial/kgdb_nmi.c | 348 ++++++++++++++++++++++++++++++++++++
drivers/tty/serial/kgdboc.c | 16 ++
drivers/tty/serial/serial_core.c | 30 ++++
include/linux/kdb.h | 29 +--
include/linux/kgdb.h | 34 ++++
include/linux/serial_core.h | 2 +
include/linux/tty_driver.h | 1 +
kernel/debug/debug_core.c | 36 +++-
kernel/debug/kdb/kdb_main.c | 29 +++
23 files changed, 1024 insertions(+), 194 deletions(-)
In v3:
- Per Colin Cross suggestion, added a way to release a debug console for
normal use. This is done via 'disable_nmi' command (in the original
FIQ debugger it was 'console' command). For this I added a new
callback in the tty ops, and serial drivers have to provide a way to
clear its interrupts. The patch 'tty/serial/kgdboc: Add and wire up
clear_irqs callback' explains the concept in details.
- Made the debug entry prompt more shell-like;
- A new knocking mode '-1'. It disables the feature altogether, and thus
makes it possible to hook KDB entry to a dedicated button.
- The code was rebased on 'v3.5 + kdb kiosk'[1] patches;
In v2:
- Per Colin Cross' suggestion, we should not enter the debugger on any
received byte (this might be a problem when there's a noise on the
serial line). So there is now an additional patch that implements
"knocking" to the KDB (either via $3#33 command or return key, this is
configurable);
- Reworked {enable,select}_fiq/is_fiq callbacks, now multi-mach kernels
should not be a problem;
- For versatile machines there are run-time checks for proper UART port
(kernel will scream aloud if out of range port is specified);
- Added some __init annotations;
- Since not every architecture defines FIQ_START, we can't just blindly
select CONFIG_FIQ symbol. So ARCH_MIGHT_HAVE_FIQ introduced;
- Add !THUMB2_KERNEL dependency for KGDB_FIQ, we don't support Thumb2
kernels;
- New patch that is used to get rid of LCcralign label in alignment_trap
macro.
[1] https://lkml.org/lkml/2012/7/26/260
[2]
Original Google's FIQ debugger, fiq_* files:
http://android.git.linaro.org/gitweb?p=kernel/common.git;a=tree;f=arch/arm/…
And board support as an example of using it:
http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=commitdiff;h=461cb80c1…
== Linus Walleij linusw ==
=== Highlights ===
* Cleaned-up and converted U300 to use sparse IRQs
* Submitted a devicetree patch set for the Integrator
* Fixed two regressions on ux500 in the -rc:s, Lee did
fix them similarly in parallell.
* Submitted an ASIC ID patch set for the ux500 and
synchronized back to the internal 3.4 kernel tree.
* Ongoing work on sparse IRQ for Nomadik and Ux500
* Ongoing work to synchronize i2c driver changes from
Alessandro Rubini to the internal 3.4 tree.
* Reviewed a patch bomb of 22 patches from Lee Jones
pertaining to the AB8500 ALSA codec.
* Reviewed timer driver for aarch64 generic time.
* First review of14 patches for AT91 pinctrl from
Jean-Christophe Plaiginol-Villard.
* Discussed pinctrl suspend/resume semantics.
=== Plans ===
* Invited to participate in the ARM mini-summit in San Diego,
accepted and booked travels.
* Test the PL08x patches on the Ericsson Research
PB11MPCore and submit platform data for using
pl08x DMA on that platform.
* Look into other Ux500 stuff in need of mainlining...
using an internal tracking sheet for this.
* Look into regmap.
=== Misc ===
* Released libmtp 1.1.4 (as if you care).
=== Issues ===
* N/A
Thanks,
Linus Walleij
Hi all,
This quite long email (sorry!) has two purposes: to announce userland
lowmemory killer daemon to a broader audience, and to resume discussion
on lowmemory notifications.
The userland lowmemory killer daemon (ulmkd), behaves the same way as
kernel's lowmemorykiller (LMK) driver, except that the policy now lives
in the userland, and the daemon expects some 'low memory notification'
services from the kernel (currently, the main backend is cgroups).
Plus, with userland approach now we can send not only SIGKILL, but also
user-specific events, upon which programs would not just quit, but would
e.g. release/garbage collect memory or we could even try to
preemptively suspend and put selected "currently not important"
processes into swap (something, I believe, Windows 8 does nowadays,
sorry for the analogy. :-) This also seem to slightly relate to
fallocate volatile work: the trend is to make resource management a bit
smarter, export userland's knowledge about resources to the kernel, give
the kernel some hints.
ulmkd is a drop-in replacement for lowmemorykiller driver; one can
disable CONFIG_ANDROID_LOW_MEMORY_KILLER in the kernel config, start
ulmkd, and everything should behave the same way.
Also, I do hope the code would be useful not only for Android, so if
anybody wants to extend it, you're more than welcome.
The code is tiny, and is available in this git repo:
git://git.infradead.org/users/cbou/ulmkd.git
(The repo is three months old since the stuff seem to just work, at
least with cgroups.)
The daemon consists of two parts,
- Low memory notifications handling;
- Task list management.
For notifications, there are two backends: cgroups and vmevent. Vmevent
support is quite outdated, but it is still there just to show the idea.
I plan to substitute it with deferred timer polling + shrinker
notifications (see below).
For task list management, two methods implemented: /proc based (the
daemon reads PIDs and oom_adj values from the /proc directory), and
shared memory based, where it is expected that Android Activity Manager
(or Maemo, or Tizen manager, or whatever) would keep the task list in
the memory, and share it with the killer daemon. The demo_shm.c file
provides a small example, it "proxies" task list from /proc to a shared
memory. (The Android Activity Manager already manages its own task
list, we just need to teach it to share it with the daemon.)
Note that we have to implement LMK as a separate small daemon, the
reason behind this is best described in Android example: in JVM we can't
guarantee 'no new new memory allocations', we're out of control of what
JVM does with memory. Plus, we don't want the killer to be swapped out,
and so in ulmkd we call mlockall(), thus locking just the small daemon,
not the whole JVM.
Some words about latency: the reaction time is not a big issue in "Low
Memory Killer" duties, this is because LMK triggers when we have plenty
of free memory and time (tens and hundreds of megabytes), and OOMK
(in-kernel OOM killer) will help us if we're too slow. So ulmkd by no
means is going to "replace" OOMK.
Note that no matter if we choose to kill processes from kernel or
userspace, current in-kernel LMK driver would still need a lot of rework
to get it right.
The main problem is vm_stat counters. The vm_stat counters are per-node,
per-cpu, and gathering the statistics from all the nodes might be quite
expensive: e.g. on SMP to synchronize global counters, we'd need to
issue an IPI, which, if we presume that we need a low-latency LMK, would
disturb the system quite a lot, and the whole point of "light weight"
LMK driver defeats itself.
In-kernel LMK started when most users where UP/"embedded", so it was all
straightforward. But now SMP is quite common setup even on embedded
devices, and so we will need to "adjust" LMK to a new reality, sooner or
later. And we'd better do it in the best possible way, right from the
start.
(Note that adding another LRUs, like "easily reclaimable list", doesn't
solve the vm_stat issue. Identifying which pages are easily reclaimable
is one thing, but statistics is another.)
So, in-kernel LMK shares the same issues with vmevent lowmemory
notification approach, because both use vm_stat, which we can't update
frequently, and so the statistics are not up to date anyway.
In ulmkd I want to try another approach (in addition to cgroups):
- Considering that we don't have to be super-low-latency, we can just
poll /proc/vmstat from userland very infrequently *and* using deferred
timers approach to save power, as we did in vmevents -- we won't wake
up the system needlessly. As far as I can see, there is no such thing
as deferred timers for userland yet, so this is going to be a key
part.
- Export shrinker notifications to userland (via vmevents API?). This
would zap all the discussions about what to consider "low memory", as
shrinker is just a small hint that kernel is short on the memory, and
we'll OOM pretty soon (assuming no swap).
Does it sound viable? Note that nothing is set in stone here, before
going all-in into it, I'd really want to hear opinions and more ideas.
Thanks!
Anton.
== Linus Walleij linusw ==
=== Highlights ===
* Sent pull requests to Linus Torvalds for pin control and
GPIO (as stand-in for Grand Likely). Both for v3.5 fixes before
the v3.6 merge window, and the bulk of patches in the
merge window, and fixes following the merge window.
* My patches to migrate the Integrator and Nomadik machines
over to common clk have been accepted upstream and
merged to Torvalds.
* Invited to participate in the ARM mini-summit in San Diego,
accepted and booked travels.
* After returning from my vacation I mainly catched up on
things, wrote a lot of mail and synced the ST-Ericsson
internal development tree in both directions.
=== Plans ===
* Look into sparse IRQs for the platforms I know.
* Test the PL08x patches on the Ericsson Research
PB11MPCore and submit platform data for using
pl08x DMA on that platform.
* Look into other Ux500 stuff in need of mainlining...
using an internal tracking sheet for this.
* Review a 22-patch bomb from Lee Jones.
=== Issues ===
* N/A
Thanks,
Linus Walleij
These two weeks have flown by so quickly, I literally had a feeling that
the time has been ticking twice as fast. Maybe that is because I had a
bunch of small assorted items to do, i.e. no big accomplishments, just a
routine. Not all of the items were completed, though; mainly, I still
didn't get to LMK, but hopefully FIQ stuff will calm down (I have 27
KDB/FIQ patches already, heh), and so I'll have some time for lowmemory
killer.
== Highlights ==
* Finished and sent out thrid version of KGDB/KDB FIQ patch set: in the
latest version I introduced disable_nmi command;
* Per Russell King's review comments, reworked return path for KGDB
FIQ handler (to properly save SVC's SPSR register we have to jump
back and forth through the ARM execution modes);
* Prepared a set of patches that reworks and cleanups FIQ usage in
ARM land (FIQ_START and disable/enable_fiq() calls). Had to carefully
audit drivers and subarches;
* Addressed Alan Cox's comments on KDB Kiosk mode support patches,
reworked and sent out v2 of the patch that adds appropriate flags
to the KDB commands;
* Started adding 'console' into KDB FIQ. I tried to avoid it as
the whole scheme might look ugly (i.e. console->kgdb->FIQ->console),
but Colin showed a case where just detaching FIQ is not enough, and
so the dedicated KDB FIQ console is mandatory;
* Had to spent a bit of time on battery stuff, this merge window pull
request has been unusually complicated as there were conflicts with
ACPI/thermal tree. Also there were a bunch of patches for review.
--
Anton Vorontsov
Email: cbouatmailru(a)gmail.com
=== Highlights ===
* Sent out LRU_VOLATILE work to lkml. Minimal feedback so far.
* Generated some initial statistics on ashmem usage and frequency
* Fought with uboot/devicetree trying to replace a kernel on current
ubuntu images
* Did some initial investagation on using the ETM/ETB driver w/
pandaboard. Got stuck as the driver isn't seemingly finding the device.
Not sure if that's a devicetree issue or what.
* Chased down a timekeeping regression tripped by a system with a broken
CMOS clock.
* Continued work generating better test cases for timekeeping.
* Started some planning for Kernel Summit/Plumbers discussions
* Ran the android upstreaming subteam meeting
=== Plans ===
* Take another shot at ETB/ETM work
* Further stress testing of the LRU_VOLATILE work using Android's ashmem
and adding memory pressure via kernel boot args
* Work on slides & presentation for Plumbers
=== Issues ===
* None
=== omarrmz ===
* [PATCH 0/3] OMAP: hwmod: reset API proposal review: IN PROGRESS.
- 3/3 will be merged for 3.7, however it is not enough for remoteproc to work.
- 2/3 is being discussed, had to debug some comments made by Paul that
don't affect my patch because of current clock framework behavior.
- 1/3 no comments received yet.
* Reworked iommu OFF mode support patches with a minor update.
* Mailbox runtime OFF mode: IN PROGRESS.
- Saving & restoring context per mailbox instance, instead of entire
bunch of registers.
- This might trigger a mailbox cleanup later on.
* ARMv8
- Looking at ARMv8 architecture patches, to be familiarized with the
work: IN PROGRESS.
* Completing HR courses: DONE.
* Consolidate iommu changes into original series: NO UPDATE.
- * Rebase current patches on top of Paul W changes (and accepted
patches), and prepare to re-send iommu changes.
* Get some time to do an omap mailbox cleanup: NO UPDATE.
* Review patches from Laurent on tidspbridge: NO UPDATE.
- Review a separate bug he is reporting.
=== Plans ===
* Complete mailbox changes for OFF mode support.
* Keep on looking at aarch64 patches.
Regards,
Omar
Hi Peter,
I'm current studying the kvm and its bootwrapper code, and find a
confused point,
hoping to get a answer here.
First I quote words from ARM virt extension spec, it says:
"When in Hyp Mode:
An MSR instruction which attempts to modify the CSPR.M bits is
UNPREDICTABLE, except in Debug
state."
While in bootwrapper, I see code would set cpu into hyp mode and
launch the kernel.
In kernel booting stage, it would first set the cpu mode to SVC in the
start of arch/arm/kernel/head.S.
And the most important is the kernel set cpu mode by directly using
the MSR method which is
forbidden by the virt extension spec...
So here is my question:
1. Could the kernel set SVC behavior lead to any issue?
2. And could we set the cpu into SVC in bootwrapper before launch the kernel?
I tried to switch to SVC before launching kernel by insert a SVC entry
in hyp vector table, and
copy the desired mode into spsr first then call the eret instruction.
However the bootwarpper seems
get hang there and I didn't figure out why...
Thanks,
Lei
Hi all,
I do realize that we're in the middle of the merge window. But maybe
some of you will be bored enough to look into this; and no problem if
you don't feel like it -- I promise to send a brand new shiny v4 after
the merge window, so you won't miss a bit of this new cool stuff. :-)
In v3:
- Per Colin Cross suggestion, added a way to release a debug console for
normal use. This is done via 'disable_nmi' command (in the original
FIQ debugger it was 'console' command). For this I added a new callback
in the tty ops, and serial drivers have to provide a way to clear its
interrupts. The patch 'tty/serial/kgdboc: Add and wire up clear_irqs
callback' explains the concept in details.
- Made the debug entry prompt more shell-like;
- A new knocking mode '-1'. It disables the feature altogether, and thus
makes it possible to hook KDB entry to a dedicated button.
- The code was rebased on 'v3.5 + kdb kiosk'[1] patches; and for
convenience it is now available in the following repo:
git://git.infradead.org/users/cbou/linux-nmi-kdb.git master
Rationale for this patch set:
These patches introduce KGDB FIQ debugger support. The idea (and some
code, of course) comes from Google's FIQ debugger[2]. There are some
differences (mostly implementation details, feature-wise they're almost
equivalent, or can be made equivalent, if desired).
The FIQ debugger is a facility that can be used to debug situations
when the kernel stuck in uninterruptable sections, e.g. the kernel
infinitely loops or deadlocked in an interrupt or with interrupts
disabled. On some development boards there is even a special NMI
button, which is very useful for debugging weird kernel hangs.
And FIQ is basically an NMI, it has a higher priority than IRQs, and
upon IRQ exception FIQs are not disabled. It is still possible to
disable FIQs (as well as some "NMIs" on other architectures), but via
special means.
So, here FIQs and NMIs are synonyms, but in the code I use NMI term
for arch-independent code, and FIQs for ARM code.
A few years ago KDB wasn't yet ready for production, or even not
well-known, so originally Google implemented its own FIQ debugger
that included its own shell, ring-buffer, commands, dumping,
backtracing logic and whatnot. This is very much like PowerPC's xmon
(arch/powerpc/xmon), except that xmon was there for a decade, so it
even predates KDB.
Anyway, nowadays KGDB/KDB is the cross-platform debugger, and the
only feature that was missing is NMI handling. This is now fixed for
ARM.
There are a few differences comparing to the original (Google's) FIQ
debugger:
- Doing stuff in FIQ context is dangerous, as there we are not allowed
to cause aborts or faults. In the original FIQ debugger there was a
"signal" software-induced interrupt, upon exit from FIQ it would fire,
and we would continue to execute "dangerous" commands from there.
In KGDB/KDB we don't use signal interrupts. We can do easier:
set up a breakpoint, continue, and you'll trap into KGDB again
in a safe context.
It works for most cases, but I can imagine cases when you can't
set up a breakpoint. For these cases we'd better introduce a
KDB command "exit_nmi", that will rise the SW IRQ, after which
we're allowed to do anything.
- KGDB/KDB FIQ debugger shell is synchronous. In Google's version
you could have a dedicated shell always running in the FIQ context,
so when you type something on a serial line, you won't actually cause
any debugging actions, FIQ would save the characters in its own
buffer and continue execution normally. But when you hit return key
after the command, then the command is executed.
In KGDB/KDB FIQ debugger it is different. Once you enter KGDB, the
kernel will stop until you instruct it to continue.
This might look as a drastic change, but it is not. There is actually
no difference whether you have sync or async shell, or at least I
couldn't find any use-case where this would matter at all. Anyways,
it is still possible to do async shell in KDB, just don't see any
need for this.
- Original FIQ debugger used a custom FIQ vector handling code, w/
a lot of logic in it. In this approach I'm using the fact that
FIQs are basically IRQs, except that we there are a bit more
registers banked, and we can actually trap from the IRQ context.
But this all does not prevent us from using a simple jump-table
based approach as used in the generic ARM entry code. So, here
I just reuse the generic approach.
Note that I test the code on a modelled ARM machine (QEMU Versatile), so
there might be some issues on a real HW, but it works in QEMU tho. :-)
Assuming you have QEMU >= 1.1.0, you can easily play with the code
using ARM/versatile defconfig and command like this:
qemu-system-arm -nographic -machine versatilepb \
-kernel linux/arch/arm/boot/zImage \
-append "console=ttyAMA0 kgdboc=ttyAMA0 kgdb_fiq.enable=1"
Thanks,
--
arch/arm/Kconfig | 19 +++
arch/arm/common/vic.c | 28 +++++
arch/arm/include/asm/hardware/vic.h | 2 +
arch/arm/include/asm/kgdb.h | 8 ++
arch/arm/kernel/Makefile | 1 +
arch/arm/kernel/entry-armv.S | 169 +------------------------
arch/arm/kernel/entry-header.S | 176 ++++++++++++++++++++++++++-
arch/arm/kernel/kgdb_fiq.c | 159 ++++++++++++++++++++++++
arch/arm/kernel/kgdb_fiq_entry.S | 76 ++++++++++++
arch/arm/mach-versatile/Makefile | 1 +
arch/arm/mach-versatile/include/mach/irqs.h | 1 +
arch/arm/mach-versatile/kgdb_fiq.c | 31 +++++
drivers/tty/serial/amba-pl011.c | 13 ++
drivers/tty/serial/kgdboc.c | 9 ++
drivers/tty/serial/serial_core.c | 15 +++
include/linux/kgdb.h | 14 +++
include/linux/serial_core.h | 1 +
include/linux/tty_driver.h | 1 +
kernel/debug/debug_core.c | 13 +-
kernel/debug/kdb/kdb_debugger.c | 4 +
kernel/debug/kdb/kdb_main.c | 20 +++
21 files changed, 591 insertions(+), 170 deletions(-)
In v2:
- Per Colin Cross' suggestion, we should not enter the debugger on any
received byte (this might be a problem when there's a noise on the
serial line). So there is now an additional patch that implements
"knocking" to the KDB (either via $3#33 command or return key, this
is configurable);
- Reworked {enable,select}_fiq/is_fiq callbacks, now multi-mach kernels
should not be a problem;
- For versatile machines there are run-time checks for proper UART port
(kernel will scream aloud if out of range port is specified);
- Added some __init annotations;
- Since not every architecture defines FIQ_START, we can't just blindly
select CONFIG_FIQ symbol. So ARCH_MIGHT_HAVE_FIQ introduced;
- Add !THUMB2_KERNEL dependency for KGDB_FIQ, we don't support Thumb2
kernels;
- New patch that is used to get rid of LCcralign label in alignment_trap
macro.
[1] https://lkml.org/lkml/2012/7/26/260
[2] Original Google's FIQ debugger, fiq_* files:
http://android.git.linaro.org/gitweb?p=kernel/common.git;a=tree;f=arch/arm/…
And board support as an example of using it:
http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=commitdiff;h=461cb80c1…
--
Anton Vorontsov
Email: cbouatmailru(a)gmail.com
