Difference between revisions of "Linux Debug"
(→Showing clock tree) |
SebastienSz (Talk | contribs) m (→Observing systems clocks) |
||
(One intermediate revision by the same user not shown) | |||
Line 139: | Line 139: | ||
have been hit and their counters. | have been hit and their counters. | ||
</pre> | </pre> | ||
+ | |||
+ | ==Observing system clocks== | ||
+ | |||
+ | You can "export" and observe some clocks: | ||
+ | * On OPOS6UL/L: signal CLKO1 is available on pad JTAG_TMS (pin 7 of J36) and signal CLKO2 is available on pad JTAG_TDO (pin 13 of J36). | ||
+ | |||
+ | Example on OPOS6UL/L: | ||
+ | |||
+ | Mux CLKO1 and CLKO2 signals on JTAG_TMS and JTAG_DO: | ||
+ | <pre> | ||
+ | # devmem 0x20E0048 32 3 | ||
+ | # devmem 0x20E004C 32 3 | ||
+ | </pre> | ||
+ | |||
+ | Export ARM clock (divided by 8) on CLKO2: | ||
+ | <pre> | ||
+ | # devmem 0x20C4060 32 0x1EA0001 | ||
+ | </pre> | ||
+ | |||
+ | See the reference manual of the OPOS6UL/L for the others clocks "exportable". | ||
==Links== | ==Links== | ||
* http://www-users.cs.umn.edu/~boutcher/kprobes/ | * http://www-users.cs.umn.edu/~boutcher/kprobes/ | ||
* http://tree.celinuxforum.org/CelfPubWiki/PatchArchive | * http://tree.celinuxforum.org/CelfPubWiki/PatchArchive |
Latest revision as of 09:31, 3 May 2019
Tips to do debugging under Linux.
Contents
Introduction
On this page, you will find usefull informations for debugging your Linux kernel/drivers.
Testing your custom Linux kernel before flashing it
You can test a linux kernel you've generated without having to reflash your board and destroy your currently working image. Indeed Linux kernel images can be loaded and started from SDRAM with U-Boot:
BIOS> run download_kernel MAC: 00:1e:ac:00:00:02 operating at 100M full duplex mode Using dm9000 device TFTP from server 192.168.0.104; our IP address is 192.168.0.10 Filename 'apf9328-linux.bin'. Load address: 0x8000000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ######## done Bytes transferred = 1703940 (1a0004 hex) BIOS> bootm ## Booting kernel from Legacy Image at 08000000 ...
Changing processor registers from Linux user space with imxregs
This tool allows you to access i.MX registers from Linux userspace/console. This way you can debug your driver or access i.MX hardware functionnalities directly from Linux console.
In recent releases (>= 3.0) you should find this tool in /usr/bin/ on your board.
Unlock registers access
Note: On APF51/APF28/OPOS6UL you don't have to explicitly unlock registers in U-Boot to access them under Linux, like explained just above |
- To use it, you must clear i.MX PAR_1 & PAR_2 registers (registers access rights) before launching Linux kernel, so in U-Boot type (example here is for APF9328):
BIOS> mw.l 0x00200008 0 BIOS> mw.l 0x00210008 0
- on APF27:
BIOS> mw 10000008 0 BIOS> mw 10020008 0
If you use it frequently, a small script unlock_regs has been defined in U-Boot, and you can call it before booting your board:
BIOS> run unlock_regs BIOS> boot
Usage
- Then in Linux console/terminal, launch imxregs like that:
# imxregs REGISTER_NAME (give it the register name as printed in i.MX Ref Manual or just the begining of the name)
or
# imxregs (to dump all supported registers)
Examples
- Show OCR1 registers of each GPIO Port:
# imxregs OCR1
- Write 0x00000123 to OCR1_D register:
# imxregs OCR1_D 123
Changing FPGA IP's registers from Linux user space
See fpgaregs tool.
Using DebugFS
DebugFS is a in-kernel filesystem, similar to procfs or sysfs, that allows Linux driver to easily communicate debug informations to user space. Full documentation: http://lxr.linux.no/linux+v2.6.32/Documentation/filesystems/debugfs.txt or http://www.linuxtopia.org/online_books/linux_kernel/kernel_configuration/ch09s07.html
Mounting it
# mount -t debugfs none /sys/kernel/debug
Showing already allocated GPIOs
# cat /sys/kernel/debug/gpio GPIOs 0-31, gpio-0: gpio-5 (LCD ) in lo gpio-6 (LCD ) in lo gpio-7 (LCD ) in lo gpio-8 (LCD ) in lo ....
Showing clock tree
Device Drivers ---> Common Clock Framework ---> [*] DebugFS representation of clock tree | Creates a directory hierarchy in debugfs for visualizing the clk | tree structure. Each directory contains read-only members | that export information specific to that clk node: clk_rate, | clk_flags, clk_prepare_count, clk_enable_count & clk_notifier_count.
all clocks are availables under /sys/kernel/debug/clk:
# mount -t debugfs none /sys/kernel/debug/ # cat /sys/kernel/debug/clk/clk_summary
Tracers
Function profiler
$ make linux-menuconfig
Kernel hacking ---> [*] Tracers ---> [*] Kernel Function Tracer ... [*] Kernel function profiler This option enables the kernel function profiler. A file is created in debugfs called function_profile_enabled which defaults to zero. When a 1 is echoed into this file profiling begins, and when a zero is entered, profiling stops. A "functions" file is created in the trace_stats directory; this file shows the list of functions that have been hit and their counters.
Observing system clocks
You can "export" and observe some clocks:
- On OPOS6UL/L: signal CLKO1 is available on pad JTAG_TMS (pin 7 of J36) and signal CLKO2 is available on pad JTAG_TDO (pin 13 of J36).
Example on OPOS6UL/L:
Mux CLKO1 and CLKO2 signals on JTAG_TMS and JTAG_DO:
# devmem 0x20E0048 32 3 # devmem 0x20E004C 32 3
Export ARM clock (divided by 8) on CLKO2:
# devmem 0x20C4060 32 0x1EA0001
See the reference manual of the OPOS6UL/L for the others clocks "exportable".