Tim's Tips and Tricks

Git tips

 * Show when a commit was entered in the tree: "git describe "
 * Show the version of software where a change first appeared: "git describe --contains "
 * git log # narrow scope of log
 * git log
 * git lg []  # 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 | grep "
 * Then do: "git show "
 * 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!!)


 * git grep (grep only git-managed files) (credit to Thomas Petazzoni)

Note also that you can use 'git grep', that will only grep the source files that are under version control, skipping all object files and other generated files you may have in your tree, if you're not doing out of tree builds. I use 'git grep' routinely.


 * several people said: "git rebase -i" as a replacement for quilt
 * git add -p
 * git commit --amend

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

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

 * 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.


 * 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.


 * ser2net (Credit to Jean-Christophe PLAGNIOL-VILLARD)


 * ptxdist and barebox (Credit to Robert Schwebel)
 * can load kernel via nfs server (does not require root privileges on host)

--- How to copy data over serial line to Linux: (credit to Alan Carvalho de Assis) http://acassis.wordpress.com/2012/10/21/how-to-transfer-files-to-a-linux-embedded-system-over-serial/

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??