Difference between revisions of "Tim's Tips and Tricks"
(→board handling: add uart-finding tip from Todd) |
|||
Line 5: | Line 5: | ||
=== Git tips === | === Git tips === | ||
− | * git describe <commit> | + | * Show when a commit was entered in the tree: "git describe <commit>" |
− | * git describe --contains <commit> | + | * Show the version of software where a change first appeared: "git describe --contains <commit>" |
* git log <file> # narrow scope of log | * git log <file> # narrow scope of log | ||
** git log <dir> | ** git log <dir> | ||
** git lg [<dir_or_file>] # nice summary | ** git lg [<dir_or_file>] # nice summary | ||
*** alias.lg=log --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr %an)%Creset' --abbrev-commit --date=relative | *** alias.lg=log --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr %an)%Creset' --abbrev-commit --date=relative | ||
− | * git annotate <file> | grep < | + | *** how to do a git alias, with colors! |
− | + | ||
+ | * find the commit for a specific line in a file: "git annotate <file> | grep <regex_of_line>" | ||
+ | ** Then do: "git show <commit_of_interest>" | ||
+ | ** This is good to find out: why is it here? who did this?, when did it get changed to this? | ||
+ | |||
* git bisect | * git bisect | ||
− | |||
* git proxy (finally!!) | * git proxy (finally!!) | ||
Line 25: | Line 28: | ||
* diffinfo - my own tool for managing patches | * diffinfo - my own tool for managing patches | ||
** splitting a patch: splitpatch - tool to break patches apart | ** splitting a patch: splitpatch - tool to break patches apart | ||
+ | |||
+ | === source finding === | ||
+ | * cgrep, mgrep, confgrep, kgrep, armcgrep, jgrep - scan C code, Makefiles, .config, Kconfig, arm C files, and java code, respectively for a search pattern | ||
+ | ** thin wrappers on 'find . [some conditions] -exec egrep $1' | ||
+ | * finds - find a string in a set of files (Credit to Todd Fischer of RidgeRun) | ||
+ | |||
+ | I use a tool, finds, I got from someone about 15 years ago. It simply | ||
+ | does a recursive look for a string in all files of interest in a | ||
+ | directory tree. When I get a big tarball of code that I don't intend to | ||
+ | build, but want to grab some logic, I use finds. I have created a | ||
+ | variety of variations of finds (which I usually later throw away) as my | ||
+ | search needs change. Essentially finds is | ||
+ | |||
+ | find . -exec fgrep -H "$1" {} \; | ||
+ | |||
+ | but with lots and lots of other qualifiers. You can see a usable | ||
+ | version at | ||
+ | |||
+ | https://www.ridgerun.com/developer/wiki/index.php/Tip_of_the_day#finds_-_find_a_string_in_common_text_files | ||
+ | |||
+ | === kernel debugging === | ||
+ | * use of fs/sync.c:SYSCALL_DEFINE0(sync) for user-space triggered printks | ||
+ | * use of qemu for kernel debugging | ||
+ | |||
+ | === testing === | ||
+ | * tbtorture.sh - for stress testing | ||
=== board handling === | === board handling === | ||
Line 32: | Line 61: | ||
** Usually use tftp boot kernel, with NFS rootfs | ** Usually use tftp boot kernel, with NFS rootfs | ||
*** but can do other setups: feed kernel through serial line, put kernel on SD card using known-good kernel, etc. | *** but can do other setups: feed kernel through serial line, put kernel on SD card using known-good kernel, etc. | ||
− | |||
* ttc - command line tool for board control | * ttc - command line tool for board control |
Revision as of 11:37, 23 October 2012
Contents
Sources
- Hugh Blemings - Learning Kernel Hacking from clever people - elc-us-2008-slides-final.pdf
Ideas for individual tips
Git tips
- Show when a commit was entered in the tree: "git describe <commit>"
- Show the version of software where a change first appeared: "git describe --contains <commit>"
- git log <file> # narrow scope of log
- git log <dir>
- git lg [<dir_or_file>] # nice summary
- alias.lg=log --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr %an)%Creset' --abbrev-commit --date=relative
- how to do a git alias, with colors!
- find the commit for a specific line in a file: "git annotate <file> | grep <regex_of_line>"
- Then do: "git show <commit_of_interest>"
- This is good to find out: why is it here? who did this?, when did it get changed to this?
- git bisect
- git proxy (finally!!)
patch management
- quilt - patches as first class objects
- git for development work, then convert to quilt patches
- git rebase --interactive
- precommit - quilt pop -a, basediff, quilt push -a, scripts/fix-filemodes.sh
- diffinfo - my own tool for managing patches
- splitting a patch: splitpatch - tool to break patches apart
source finding
- cgrep, mgrep, confgrep, kgrep, armcgrep, jgrep - scan C code, Makefiles, .config, Kconfig, arm C files, and java code, respectively for a search pattern
- thin wrappers on 'find . [some conditions] -exec egrep $1'
- finds - find a string in a set of files (Credit to Todd Fischer of RidgeRun)
I use a tool, finds, I got from someone about 15 years ago. It simply does a recursive look for a string in all files of interest in a directory tree. When I get a big tarball of code that I don't intend to build, but want to grab some logic, I use finds. I have created a variety of variations of finds (which I usually later throw away) as my search needs change. Essentially finds is
find . -exec fgrep -H "$1" {} \;
but with lots and lots of other qualifiers. You can see a usable version at
kernel debugging
- use of fs/sync.c:SYSCALL_DEFINE0(sync) for user-space triggered printks
- use of qemu for kernel debugging
testing
- tbtorture.sh - for stress testing
board handling
- consistent board setup (including remote access)
- connections: serial, network, power (web-based control) [images]
- power port controller [image]
- Usually use tftp boot kernel, with NFS rootfs
- but can do other setups: feed kernel through serial line, put kernel on SD card using known-good kernel, etc.
- connections: serial, network, power (web-based control) [images]
- ttc - command line tool for board control
- abstracts differences between boards
- allows for board sharing (ttc reserve)
- everything is scritable, and remotable
- object-oriented: inheritance to quickly modify attributes of a board "class"
- items abstracted:
- kernel source, toolchain, architecture, defconfig, kernel image name, tool paths
- kernel build, install
- board console access, reboot, run arbitrary commands, reset
- filesystem access (copy from/to)
Finding the ttyUSB* for a board connected to a multi-port hub: (Credit to Todd Fischer of RidgeRun): A recurring problem I had was finding the right /dev/ttyUSB? device. I have a nice USB to 4 serial port adaptor in a metal box I have screwed to my bench. I also use several USB serial dongles. For reasons I don't understand, they change association (at least under Ubuntu). I created two scripts lsuart and uart. The output of lsuart gives me information about the serial ports, like
Available USB UARTs ------------------- a:/dev/ttyUSB0 FTDI USB Serial Device 0000:00:04.1-4.1 (4 port jack A) b:/dev/ttyUSB1 FTDI USB Serial Device 0000:00:04.1-4.2 (4 port jack B) c:/dev/ttyUSB2 FTDI USB Serial Device 0000:00:04.1-4.3 (4 port jack C) :/dev/ttyUSB3 pl2303 0000:00:02.1-4.2 () d:/dev/ttyUSB4 FTDI USB Serial Device 0000:00:04.1-4.4 (4 port jack D)
In use ------ /dev/ttyUSB4: 9705: picocom -b 115200 -r -l /dev/ttyUSB4
I gave names (a, b, c, d) to the 4 fixed uarts. Now I look at which port my serial cable is plugged into - say the 3rd one, which I call c, and I can fire up picocom with the standard setting using
uart c
Sometimes I can't find a terminal session (too many windows open), so I use the PID from the In use section of the lsuart output to kill it.
If others have the "where is my USB serial port" problem, I can love up my shell script (lsuart is a symbolic link to uart), which is around 200 lines of ugly sysfs parsing.
personal productivity
- my workflow:
- different day for each topic area
- today script
- multiple todo's, NOTES all over the place (several in each work directory)
- must do a context save in each directory, before moving on
- git branch is essential - commit changes (even if flaky) before moving on
- my favoriate mailing lists:
- sorry, but linux-embedded seems to be dead
- lkml, linux-arm, yocto-devel
- celinux-dev
- attend conferences, talk to smart people
- conferences I attend:
- ELC, ELCE, linuxcon US, Linuxcon Japan, Linuxcon Europe (by serendipity)
- what about plumbers?? other regional events??