On 09:35 Tue 23 Oct , Tim Bird wrote: > Hi everyone, > > I'm conducting a bit of a survey. I am holding a "Birds-of-a-Feather" > session at ELC Europe in a few weeks on the topic of embedded > Linux tips and tricks. For that session, I'd like to collect > ideas from people about tips or tricks that you use in your own > embedded Linux development. > > Specifically do you have tips in any of the following topic areas > that you would be willing to share with me (so I can share with others?) > > 1. git commands: > Do you have any 'git' commands that you use, that > you think are not commonly known or used? > > My own is 'git describe', which I used quite a bit when > preparing my 'status of embedded Linux' talks. > > Also, I use 'git format-patch' quite a bit when I'm converting > from git commits to a quilt series. I know people use this > for submitting patches to mainline, but I use it a bit differently > (I think) when I'm making a quilt patch series.
git rebase -i also tig > > 2. Custom or homebrew tools: > When I'm moving from git commits to quilt patches, I also use > a homebrew tool called 'diffinfo', that can split large patches > into smaller ones based on regular expressions or file paths. > I know I could also use "git rebase --interactive" for this, but > I've gotten used to my own tool for this. > > Do you have any custom tool that you use to solve a particular > problem you run into frequently, that you would be willing to > describe? > > Another one I use is called 'ttc', for 'tiny target control'. > It is a thin wrapper over many of the commands that are used > to configure, build and install the kernel (as well as execute > commands on the target, move stuff between host and target, etc.) > I use this so that I don't have to remember all the different > config options, toolchain paths, cross-compiler prefix, bootloader > commands, and board access methods for the different boards I use. > Currently I'm only dealing with 2 or 3 boards, but I used to > deal with about 10 different boards on a continual basis. > It was driving me nuts every time I switched from one > board to another, having to re-learn all > the little details about working with the new board. > > Anyone else do something similar? yeah everyday that why I use ser2net with barebox and bootp so I just have to use script to generate my kernel plus home made power swith and then no need known how to manage it > > 3. development practices: > Do you have a way that you debug or develop Linux software, that > may be different from others. For example, I'm a bit of a > debugging medievalist. I still do probably 70% of my kernel debugging > with printks. One quirky "trick" I use, is that I usually put any > printks that I want to trigger from user-space in > fs/sync.c:SYSCALL_DEFINE0(sync) > This syscall is not called under normal conditions by any other > programs, and is easily triggered with the 'sync' command at the shell. > I know I could put something in /proc, or /debugfs, but using > sync does not require mounting anything ahead of time, and it's > much easier to just drop a few printks there than code up a > procfs entry. > > What do you use to debug the kernel? (qemu?, jtag?, kgdb?) Any tips > for using those, that you think other people might not know? I use jtag everday it's really good but as example whe you need to dump a big quantity of data debugfs is more usefull dito when it's come during data high speed transfer > > 3. hardware configuration > How is your hardware set up? The first thing I do when I get a > new board is set it up with a network connection and serial connection > to my host (on an isolated network segment, of course, since Sony doesn't > like my host acting like a DHCP server for other machines!). Also, I > use a digital loggers web-controllable power switch. I used all kinds > of different things previously (including relays that could toggle > reset buttons on the boards, or control the power to the board via > a USB power switch). I usually spend a few hours getting the board > completely set up for automated, command-line driven access. From then > on, I pretty much never touch the board, and I can even access it from > anywhere when I'm traveling, using ssh to my host. > > How do you set up your development boards? Do you have a common > configuration that you use that makes things easier to access the board, > deploy the software, etc. I'm using home made ser2net servers based on at91 I use network boot everyday via bootp with vendor_id, class_i and user_class to describe which kernel I want to use so no need to care too much I use also pxe > > 4. testing > Do you use a specific tool for testing? I have a simple script called > 'tbtorture.sh' that I used to 'hammer' my board when I trying to stress > it. (Lately, I've been trying to cause stack overflows on my ARM system > with 4K stacks.) tbtorture is my own tool that I wrote based on > 'do_hell' by Ingo Molnar. Unfortunately, Sony's internal distribution > doesn't have all the programs that do_hell called, and I re-wrote > parts of it to correspond to what we have in our distro (pretty > much just busybox and a few other things.) > > What is your favorite tool for stress-testing your system? > > What is your favorite tool for testing: > file-system performance? > RT performance? > memory utilization? > kernel regressions? > boot time? boot time scope or logical analyser I buy here in Shanghai > > Do you use an existing open source test framework? If so, which one? I was investigating autotest but complex lava worse so I use home made stuff with expect _______________________________________________ Celinux-dev mailing list Celinux-dev@lists.celinuxforum.org https://lists.celinuxforum.org/mailman/listinfo/celinux-dev
