mirror of
https://github.com/hardkernel/kernel_common_drivers.git
synced 2026-06-25 12:03:48 +09:00
dongqing.li
bb84725f88
PD#SWPL-192100 Problem: The 32-bit kernel cannot use the ramdump function. Because the .text section is typically at 0x00108000, which will be overwritten by the BL2E/BL33 after reboot. And the PC side is unable to parse it. Solution: 1. After kernel panic, use DMA to copy the 0-24MB region to the 0x09000000 area. 2. Reboot to bl33z, fill compress_section[1] with the 0x09000000 region. 3. Analyze it using the same method as before. Verify: sc2 Change-Id: I3e22beb06321289c6643d3f05ec2d910d5ce0beb Signed-off-by: dongqing.li <dongqing.li@amlogic.com>
32 lines
954 B
Plaintext
32 lines
954 B
Plaintext
# SPDX-License-Identifier: (GPL-2.0+ OR MIT)
|
|
|
|
config AMLOGIC_RAMDUMP
|
|
bool "Amlogic full ramdump"
|
|
default n
|
|
help
|
|
Amlogic ramump implementation. When kernel pain is
|
|
generated, the entire ddr data will be compressed and
|
|
copied out. Finally, use the crash tool to debug and
|
|
analyze on the PC side.
|
|
|
|
config AMLOGIC_RAMDUMP_TEXTOFFSET
|
|
bool "set TEXTOFFSET=0x02008000 for kernel 32bit"
|
|
depends on ARM
|
|
depends on AMLOGIC_RAMDUMP
|
|
default n
|
|
help
|
|
The 32-bit kernel cannot use ramdump because the text
|
|
section at 1MB is overwritten by BL2 after reboot.
|
|
Set TEXTOFFSET to 24MB+, just for kernel 32bit.
|
|
|
|
config AMLOGIC_RAMDUMP_DMA_COPY
|
|
bool "DMA copy 0-24MB after kernel panic"
|
|
depends on ARM
|
|
depends on AMLOGIC_RAMDUMP
|
|
default y if !AMLOGIC_RAMDUMP_TEXTOFFSET
|
|
default n
|
|
help
|
|
The 32-bit kernel cannot use ramdump because the text
|
|
section at 1MB is overwritten by BL2 after reboot.
|
|
DMA copy 0-24MB to high-mem area after kernel panic.
|