3rd-party/linux-kernel-module-cheat
1
0
Fork 0
mirror of https://github.com/cirosantilli/linux-kernel-module-cheat.git synced 2026-01-27 20:14:27 +01:00
Code Issues Releases Wiki Activity

merge

Browse Source
This commit is contained in:
Ciro Santilli
2018-04-19 07:20:59 +01:00
parent ca84b8d0a7
commit 0d8c066a8e
1 changed files with 65 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

72
README.adoc
View File

@@ -1147,6 +1147,29 @@ Maybe it is because they are being copied around at specific locations instead o
See also: https://stackoverflow.com/questions/2589845/what-are-the-first-operations-that-the-linux-kernel-executes-on-boot See also: https://stackoverflow.com/questions/2589845/what-are-the-first-operations-that-the-linux-kernel-executes-on-boot
==== GDB step debug early boot by address
One possibility is to run:
....
./trace-boot -a arm
....
and then find the second address (the first one does not work, already too late maybe):
....
less ./out/arm/qemu/trace.txt
....
and break there:
....
./run -a arm -d
./rungdb -a arm '*0x1000'
....
but TODO: it does not show the source assembly under `arch/arm`: https://stackoverflow.com/questions/11423784/qemu-arm-linux-kernel-boot-debug-no-source-code
=== GDB step debug userland processes === GDB step debug userland processes
QEMU's `-gdb` GDB breakpoints are set on virtual addresses, so you can in theory debug userland processes as well. QEMU's `-gdb` GDB breakpoints are set on virtual addresses, so you can in theory debug userland processes as well.
@@ -2254,6 +2277,8 @@ Make the kernel reboot after n seconds after panic:
echo 1 > /proc/sys/kernel/panic echo 1 > /proc/sys/kernel/panic
.... ....
Can also be controlled with the `panic` kernel boot parameter.
`0` to disable: https://unix.stackexchange.com/questions/29567/how-to-configure-the-linux-kernel-to-reboot-on-panic/29569#29569 `0` to disable: https://unix.stackexchange.com/questions/29567/how-to-configure-the-linux-kernel-to-reboot-on-panic/29569#29569
The panic trace looks like: The panic trace looks like:
@@ -2453,6 +2478,8 @@ echo 1 > /proc/sys/kernel/panic_on_warn
insmod /warn_on.ko insmod /warn_on.ko
.... ....
Can also be activated with the `panic_on_warn` boot parameter.
=== Linux kernel tracing === Linux kernel tracing
==== CONFIG_PROC_EVENTS ==== CONFIG_PROC_EVENTS
@@ -4245,24 +4272,55 @@ but this strategy failed for the other archs for some reason.
===== QEMU with gem5 kernel configuration ARM ===== QEMU with gem5 kernel configuration ARM
To test this, hack up `run` to use the `out/arm-gem5/buildroot` directory, and then run:
.... ....
./run -a arm cp kernel_config_arm-gem5 kernel_config_fragment
.... ....
Now QEMU hangs at: First, we note that gem5 still boots.
So we proceed to bisect the configs until QEMU boots, which leads to the three options:
.... ....
audio: Could not init `oss' audio driver sed -Ei \
-e '/^CONFIG_ARCH_MULTI_V7=y/d' \
-e '/^CONFIG_CMDLINE="console=ttyAMA0"/d' \
-e '/^# CONFIG_SCSI_SYM53C8XX_2 is not set/d' \
kernel_config_fragment \
;
.... ....
and the display shows: Then we try to boot GEM5 again, but removing just `CONFIG_ARCH_MULTI_V7=y` leads to:
.... ....
Guest has not initialized the display (yet). Error: unrecognized/unsupported processor variant (0x410fc0f0).
.... ....
which looks really bad! Arghh, so that option blocks either one.
From QEMU, doing;
....
cat /proc/cpuinfo
....
leads to:
....
model name : ARM926EJ-S rev 5 (v5l)
CPU architecture: 5TEJ
....
which wiki says is pre-ARMv7 (ARMv5)
gem5 on the other hand says:
....
model name : ARMv7
CPU architecture: 7
....
We also tried to use `-- --cpu a15`, found with `-- --cpu help`, but not changes.
===== gem5 with QEMU kernel configuration ARM ===== gem5 with QEMU kernel configuration ARM
Test it out with: Test it out with: