tag:blogger.com,1999:blog-30140999418233795602024-03-05T20:36:20.344-06:00Jeff Bastian's BlogThoughts and Musings, Tips and TricksJeff Bastianhttp://www.blogger.com/profile/18128075341421142000noreply@blogger.comBlogger18125tag:blogger.com,1999:blog-3014099941823379560.post-77562568412691513702014-04-28T09:06:00.002-05:002014-04-28T09:55:12.866-05:00Lenovo T440s touchpad configuration for X11The new clickpad (a button-less touchpad) on the Lenovo T440s (and other newer models like the T540p) has a few issues with Linux and X11: the biggest problems are (1) when you push the pad down to click, the cursor rapidly flies off in seemingly random directions because the pad is very sensitive, and (2) the top-edge of the clickpad serves as software-emulated-buttons for the pointing stick (the classic Thinkpad red nub) and the cursor again flies off in random directions when you try to click them.<br />
<br />
The good news is that Peter Hutterer and others have been working on the problem and <a href="http://who-t.blogspot.com.au/2014/03/xorg-synaptics-support-for-lenovo-t440.html">the driver has been updated to fix the issues</a>.<br />
<br />
However, until the updated driver gets out of rawhide, I need a workaround. A quick search finds a large number of X11 configuration tweaks on various blogs and forums: <a href="http://who-t.blogspot.com.au/2013/12/lenovo-t440-touchpad-button.html">Peter Hutterer</a>, <a href="http://hokietux.net/blog/blog/2014/02/15/fedora-20-on-the-lenovo-t440s/">Ben Hilburn</a>, <a href="https://blog.lnx.cx/2014/03/20/fedora-20-and-the-thinkpad-t440s-touchpad/">Tim Bielawa</a>, <a href="http://major.io/2013/08/24/get-a-rock-solid-linux-touchpad-configuration-for-the-lenovo-x1-carbon/">Major Hayden</a> and more.<br />
<br />
Here's the configuration tweak I am using. The <tt>AreaTopEdge</tt> setting turns off motion tracking along the top edge so the software-emulated-buttons are only buttons, and the <tt>SoftButtonAreas</tt> setting defines the edges for the right- and middle-buttons (the left-button is whatever is left over).<br />
<br />
<div id="jbcode"><code>[jbastian@localhost ~]$ cat /etc/X11/xorg.conf.d/99-clickpad-softbuttons.conf <br />
<br />
Section "InputClass"<br />
Identifier "Default clickpad buttons"<br />
MatchDriver "synaptics"<br />
MatchIsTouchpad "on"<br />
Option "ClickPad" "on"<br />
# Soft Button Areas:<br />
# first 4 parameters: right button left, right, top, bottom edge<br />
# last 4 parameters: middle button left, right, top, bottom edge<br />
Option "SoftButtonAreas" "65% 0 0 2600 35% 65% 0 2600"<br />
# use /usr/local/bin/evtest to find the value for the top edge<br />
Option "AreaTopEdge" "2600"<br />
# reduce motion from noise during click events <br />
# (default value of 8 is too low)<br />
Option "HorizHysteresis" "30"<br />
Option "VertHysteresis" "30"<br />
EndSection</code></div><br />
I'm also running <tt>syndaemon</tt> which will disable the clickpad while typing to avoid accidental cursor movements from your palms brushing on the pad.<br />
<br />
<div id="jbcode"><code>[jbastian@localhost ~]$ cat ~/.config/autostart/syndaemon.desktop <br />
[Desktop Entry]<br />
Comment[en_US]=Disable Touchpad while Typing<br />
Comment=Disable Touchpad while Typing<br />
Exec=/usr/bin/syndaemon -d<br />
GenericName[en_US]=syndaemon<br />
GenericName=syndaemon<br />
Icon=system-run<br />
MimeType=<br />
Name[en_US]=syndaemon<br />
Name=syndaemon<br />
OnlyShowIn=KDE;<br />
Path=<br />
StartupNotify=false<br />
Terminal=false<br />
TerminalOptions=<br />
TryExec=syndaemon -d<br />
Type=Application<br />
Version=1.0<br />
X-DBUS-ServiceName=<br />
X-DBUS-StartupType=none<br />
X-Desktop-File-Install-Version=0.21<br />
X-KDE-SubstituteUID=false<br />
X-KDE-Username=</code></div>Jeff Bastianhttp://www.blogger.com/profile/18128075341421142000noreply@blogger.com1tag:blogger.com,1999:blog-3014099941823379560.post-41128389564686554652013-06-28T17:09:00.005-05:002013-06-28T17:17:33.208-05:00A beautiful custom wood case for my PandaboardMy father, Dennis, built a beautiful wooden case to protect my Pandaboard from dust and the elements (and to hide the bright LEDs at night). Here it is running <a href="https://fedoraproject.org/wiki/Architectures/ARM" target="_blank">Fedora 19</a>! <br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj8sBDmfxy5L_i30qzUv-4Y8T_bh_GbXH8qC3QVjKFAFoII1ElT6H1vb1hpce9xdWSUOLO3c7ypLiaQLeGyKhciB9Hm_6acELSurlotk-z4igJyVqO8x9OD_bzfrBZuMgE9gMgqJ2Jopbg/s1600/pandaboard-case-01.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="213" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj8sBDmfxy5L_i30qzUv-4Y8T_bh_GbXH8qC3QVjKFAFoII1ElT6H1vb1hpce9xdWSUOLO3c7ypLiaQLeGyKhciB9Hm_6acELSurlotk-z4igJyVqO8x9OD_bzfrBZuMgE9gMgqJ2Jopbg/s320/pandaboard-case-01.jpg" width="320" /></a></div><br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEit7sZnvUy2eQdEbYElLbenE2l32xqK7kr4ILP87_9mxjwqivSyIRfDWvIwOcFUgcLZrYMTD1TN36nq8FDxsL1zgJRjta_2pVCE5fHMcvXidn19rmmhRzco_gqQBmdC0LSsHIf-44V7gDA/s1600/pandaboard-case-02.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="213" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEit7sZnvUy2eQdEbYElLbenE2l32xqK7kr4ILP87_9mxjwqivSyIRfDWvIwOcFUgcLZrYMTD1TN36nq8FDxsL1zgJRjta_2pVCE5fHMcvXidn19rmmhRzco_gqQBmdC0LSsHIf-44V7gDA/s320/pandaboard-case-02.jpg" width="320" /></a></div><br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiGpz_RzTLc5atfSVusoYb-W1dcvEezcvgUyqRMKYQWw_aAVqZyNpI4YfV81dG6H3uGE3nIYcxQCRJJKX6M56WvzuQdRheF1eQ4rvIeGwcMnrCg4pLpzgaOW_hOWt05zXgSOAYOtwt0UCc/s1600/pandaboard-case-03.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="213" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiGpz_RzTLc5atfSVusoYb-W1dcvEezcvgUyqRMKYQWw_aAVqZyNpI4YfV81dG6H3uGE3nIYcxQCRJJKX6M56WvzuQdRheF1eQ4rvIeGwcMnrCg4pLpzgaOW_hOWt05zXgSOAYOtwt0UCc/s320/pandaboard-case-03.jpg" width="320" /></a></div><br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgDm3a6h9UK9uM8wqwdzsFJdzpm5pdT6FB7E0HyxRmg_VMzPyIRHV8NImQkDSdcwt7LprrRUAz7IRgWp0bL0XLgFBSC8JLE_mhNoDEf_uOwjQUGsLDRd5q-ttDO7k1zEJqinQ2rlUGxEYI/s1600/pandaboard-case-04.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="213" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgDm3a6h9UK9uM8wqwdzsFJdzpm5pdT6FB7E0HyxRmg_VMzPyIRHV8NImQkDSdcwt7LprrRUAz7IRgWp0bL0XLgFBSC8JLE_mhNoDEf_uOwjQUGsLDRd5q-ttDO7k1zEJqinQ2rlUGxEYI/s320/pandaboard-case-04.jpg" width="320" /></a></div><br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhbhn8JyD9IKr_hPxaTG-DHYy42fgsBtM7STp9pObzMpXbIffwQQ5soY8NOKyr1wpx7-Dc0rfnX2XG-kVaZJlxe9E3h86t2E_cdwmsaciB6U7USzLP81O39mveFoWEp2mpoJNZRDe3s_zw/s1600/pandaboard-case-05.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="213" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhbhn8JyD9IKr_hPxaTG-DHYy42fgsBtM7STp9pObzMpXbIffwQQ5soY8NOKyr1wpx7-Dc0rfnX2XG-kVaZJlxe9E3h86t2E_cdwmsaciB6U7USzLP81O39mveFoWEp2mpoJNZRDe3s_zw/s320/pandaboard-case-05.jpg" width="320" /></a></div><br />
<div id="jbcode"><code>U-Boot 2013.04 (Jun 17 2013 - 12:42:04)<br />
<br />
CPU : OMAP4430 ES2.1<br />
Board: OMAP4 Panda<br />
I2C: ready<br />
DRAM: 1 GiB<br />
MMC: OMAP SD/MMC: 0<br />
Using default environment<br />
...<br />
<br />
Fedora release 19 (Schrödinger’s Cat)<br />
Kernel 3.9.5-301.fc19.armv7hl on an armv7l (ttyO2)<br />
<br />
panda login: jbastian<br />
Password: <br />
[jbastian@panda ~]$ uname -a<br />
Linux panda.localdomain 3.9.5-301.fc19.armv7hl #1 SMP Wed Jun 12 14:56:17 UTC 2013 armv7l armv7l armv7l GNU/Linux<br />
</code><br />
</div>Jeff Bastianhttp://www.blogger.com/profile/18128075341421142000noreply@blogger.com0tag:blogger.com,1999:blog-3014099941823379560.post-60625404294843593222012-11-07T16:45:00.000-06:002012-11-07T17:59:42.439-06:00Extract vmlinux with the power of the command lineWhile working on a problem today, I wanted to search the kernel image for some strings of text. The kernel image, however, is compressed which means a simple strings-and-grep on the image file won't find anything:<br />
<br />
<div id="jbcode"><code>$ file /boot/vmlinuz-3.6.2-4.fc17.x86_64<br />
/boot/vmlinuz-3.6.2-4.fc17.x86_64: Linux kernel x86 boot executable bzImage...<br />
$ strings /boot/vmlinuz-3.6.2-4.fc17.x86_64 | grep microcode<br />
$</code></div><br />
Note that bzImage does not necessarily mean the kernel was compressed with bzip2! It's typically done with gzip.<br />
<br />
But a simple gunzip won't work either. I'll actually use zcat since it doesn't expect a .gz suffix on the filename:<br />
<br />
<div id="jbcode"><code>$ zcat /boot/vmlinuz-3.6.2-4.fc17.x86_64<br />
gzip: /boot/vmlinuz-3.6.2-4.fc17.x86_64: not in gzip format</code></div><br />
The kernel image is a self-extracting compressed file. There's a small bit of code at the beginning of the file which extracts the compressed payload in the remainder of the file. I need to strip that chunk of code from the beginning in order to use gunzip (or zcat). But how many bytes do I need to strip?<br />
<br />
Many file types start with a simple header including a "magic number" (just a well-known fixed number) to help identify and verify the file's type. If I can find the gzip magic number somewhere in the vmlinuz file, I can strip all the bytes <i>before</i> the magic number.<br />
<br />
Files compressed with gzip start with 0x1F8B0800. A simple test can verify that. Let's compress a small bit of data and send it to xxd (a hex dumper) and show the first 4 bytes:<br />
<br />
<div id="jbcode"><code>$ echo "hello world" | gzip -c | xxd -l4<br />
0000000: 1f8b 0800 ....</code></div><br />
Ok, so now I need to find 0x1F8B0800 somewhere in the vmlinuz file. Let's start simple with xxd and grep:<br />
<br />
<div id="jbcode"><code>$ xxd /boot/vmlinuz-3.6.2-4.fc17.x86_64 | grep "1f8b 0800"<br />
$</code></div><br />
Nothing? Hmm, maybe it's not grouped the same way? That is, maybe it's "__1f 8b08 00__"? Fortunately, xxd can change the grouping using the -g option. Let's use -g1 to just show 1 byte per group, i.e., "1f 8b 08 00".<br />
<br />
<div id="jbcode"><code>$ xxd -g1 /boot/vmlinuz-3.6.2-4.fc17.x86_64 | grep "1f 8b 08 00"<br />
$</code></div><br />
Still nothing? Maybe the magic number is split on a line break? Let's try something shorter, just the first 3 bytes, with a line of context:<br />
<br />
<div id="jbcode"><code>$ xxd -g1 /boot/vmlinuz-3.6.2-4.fc17.x86_64 | grep -C1 "1f 8b 08"<br />
00044b0: 78 49 00 48 c7 c1 40 78 49 00 48 c1 e9 03 fd f3 xI.H..@xI.H.....<br />
00044c0: 48 a5 fc 5e 48 8d 83 00 08 49 00 ff e0 <span style="color: red;">1f 8b 08</span> H..^H....I......<br />
00044d0: <span style="color: red;">00</span> 00 00 00 00 02 03 ec dd 09 7c 14 e5 1d f8 ff ..........|.....</code></div><br />
Ah-hah, there it is! The "1f 8b 08" is at the end of the second line and the "00" is at the beginning of the third line. The byte 0x1f is on the line with offset 0x44c0 and it's 13, or 0xd, bytes into the line, so the magic number begins at offset 0x44cd. Converting to decimal with the bc command (note: bc expects hex digits in all caps!):<br />
<br />
<div id="jbcode"><code>$ echo 'ibase=16; 44CD' | bc<br />
17613</code></div><br />
So now I can use dd to extract the compressed image by skipping over the first 17613 bytes of the vmlinuz file:<br />
<br />
<div id="jbcode"><code>$ dd bs=1 skip=17613 if=/boot/vmlinuz-3.6.2-4.fc17.x86_64 of=/tmp/vmlinux.gz<br />
4814195+0 records in<br />
4814195+0 records out<br />
4814195 bytes (4.8 MB) copied, 6.28984 s, 765 kB/s</code></div><br />
And just to double-check the header:<br />
<br />
<div id="jbcode"><code>$ xxd -g1 -l4 /tmp/vmlinux.gz<br />
0000000: 1f 8b 08 00 ....</code></div><br />
It looks good, so run it through gunzip:<br />
<br />
<div id="jbcode"><code>$ gunzip /tmp/vmlinux.gz<br />
gzip: /tmp/vmlinux.gz: decompression OK, trailing garbage ignored</code></div><br />
Great!<br />
<br />
But, clearly this method is fragile since the magic number is difficult to find with line-breaks and grouping and what-not. There must be a better way. What I really need is a simple raw hex dump of the kernel — no offset at the beginning of each line, no byte grouping, no line breaks, no ASCII interpretation at the end of each line — and then I know I can find 1f8b0800 and its offset.<br />
<br />
Perusing the xxd man page, I see the -g0 option will remove all grouping, and the -p option will give a plain hex dump (no offsets, no ASCII). That's a good start:<br />
<br />
<div id="jbcode"><code>$ xxd -g0 -p /boot/vmlinuz-3.6.2-4.fc17.x86_64<br />
4d5aea0700c0078cc88ed88ec08ed031e4fbfcbe4000ac20c07409b40ebb<br />
0700cd10ebf231c0cd16cd19eaf0ff00f000000000000000000000000000<br />
b800000044697265637420666c6f70707920626f6f74206973206e6f7420<br />
...<br />
...</code></div><br />
I can join each line to make one continuous string by deleting the newline characters with the tr command (and use head to only show the first 100 bytes instead of dumping megabytes of hex into my terminal):<br />
<br />
<div id="jbcode"><code>$ xxd -g0 -p /boot/vmlinuz-3.6.2-4.fc17.x86_64 | tr -d '\n' | head -c 100<br />
4d5aea0700c0078cc88ed88ec08ed031e4fbfcbe4000ac20c07409b40ebb0700cd10ebf231c0cd16cd19eaf0ff00f0000000</code></div><br />
The grep command has a -b option to print the byte offset of the matching string. Combine it with the -o option to only print the first match:<br />
<br />
<div id="jbcode"><code>$ xxd -g0 -p /boot/vmlinuz-3.6.2-4.fc17.x86_64 | tr -d '\n' | grep -b -o 1f8b0800<br />
35226:1f8b0800</code></div><br />
Ah-hah, I have an offset of 35226! But, remember, 1 byte is printed as 2 hex digits, so it has to be divided by 2. And I only need the offset (the field before the colon). I can do both with awk:<br />
<br />
<div id="jbcode"><code>$ xxd -g0 -p /boot/vmlinuz-3.6.2-4.fc17.x86_64 | tr -d '\n' | grep -b -o 1f8b0800 | awk -F: '{print $1/2}'<br />
17613</code></div><br />
Hooray, 17613 is the same offset I found the hard way above!<br />
I can actually combine all of this into one big command:<br />
<br />
<div id="jbcode"><code>$ dd bs=1 skip=$(xxd -g0 -p /boot/vmlinuz-3.6.2-4.fc17.x86_64 | \<br />
tr -d '\n' | grep -b -o 1f8b0800 | awk -F: '{print $1/2}') \<br />
if=/boot/vmlinuz-3.6.2-4.fc17.x86_64 | gzip -d -c > /tmp/vmlinux<br />
4814195+0 records in<br />
4814195+0 records out<br />
4814195 bytes (4.8 MB) copied, 6.00158 s, 802 kB/s<br />
<br />
gzip: stdin: decompression OK, trailing garbage ignored</code></div><br />
And finally, I can search for my strings:<br />
<br />
<div id="jbcode"><code>$ strings /tmp/vmlinux | grep microcode<br />
microcode : 0x%x<br />
4Atom PSE erratum detected, BIOS microcode update recommended<br />
6perf_event_intel: PEBS enabled due to microcode update<br />
6perf_event_intel: PEBS disabled due to CPU errata, please upgrade<br />
microcode<br />
0mce: [Hardware Error]: PROCESSOR %u:%x TIME %llu SOCKET %u APIC %x<br />
microcode %x<br />
perf_check_microcode</code></div><br />
Whew.<br />
<br />
<b>Update:</b> Shortly after writing this blog post, I found the grep command can search binary files for hex values with a couple more options: -a to search binary files, and -P to use Perl-compatible regular expressions. This shortens the command to find the offset to a much simpler:<br />
<br />
<div id="jbcode"><code>$ grep -a -b -o -P '\x1f\x8b\x08\x00' /boot/vmlinuz-3.6.2-4.fc17.x86_64 | awk -F: '{print $1}'<br />
17613</code></div><br />
And if I use a couple of environment variable, it becomes much easier to read:<br />
<br />
<div id="jbcode"><code>$ export VMLINUZ=/boot/vmlinuz-3.6.2-4.fc17.x86_64<br />
$ SKIP=$(grep -aboP '\x1f\x8b\x08\x00' $VMLINUZ | awk -F: '{print $1}')<br />
$ dd bs=1 skip=$SKIP if=$VMLINUZ | gzip -d -c > /tmp/vmlinux<br />
4814195+0 records in<br />
4814195+0 records out<br />
4814195 bytes (4.8 MB) copied, 5.15674 s, 934 kB/s<br />
<br />
gzip: stdin: decompression OK, trailing garbage ignored</code></div>Jeff Bastianhttp://www.blogger.com/profile/18128075341421142000noreply@blogger.com3tag:blogger.com,1999:blog-3014099941823379560.post-53651077192787629212012-06-20T18:19:00.001-05:002012-06-20T18:21:36.579-05:00Static workspaces and Keyboard Shortcuts in Gnome Shell 3.4I've been a KDE and Xfce user for a long time, but I've been experimenting with Gnome Shell lately out of curiosity. I tend to use a lot of workspaces (or virtual desktops) to organize my work — email on workspace 2, developing code on workspace 3, web browser on 4, etc. — so I really do not like the dynamic workspaces feature in Gnome Shell because closing the last window on a workspace destroys that workspace and shifts all the others around which confuses me.<br />
<br />
But with Fedora 17 and Gnome Shell 3.4, it is possible to disable dynamic workspaces and set a fixed number of workspaces instead. (It was possible to do this earlier with the <a href="http://intgat.tigress.co.uk/rmy/extensions/index.html" target="_blank">Frippery extensions</a>.) Fire up <span style="font-family: monospace;">gnome-tweak-tool</span> and go to the Shell settings to make the change:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjQv8rPVACOnguCGcmIPsyeakCiiH_x-9ECI5yAqqsyu6Dnrs0jyrBSh-7sBcsaRFmCA39PhyxMnMNSicSQDbDVPY5Kk2_YiNv6cv9GayPacCVG3gc8DmqVkS52Yg-AQrnxxwKSSTCTdmY/s1600/gnome-tweak-tool-dynamic-workspaces.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="255" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjQv8rPVACOnguCGcmIPsyeakCiiH_x-9ECI5yAqqsyu6Dnrs0jyrBSh-7sBcsaRFmCA39PhyxMnMNSicSQDbDVPY5Kk2_YiNv6cv9GayPacCVG3gc8DmqVkS52Yg-AQrnxxwKSSTCTdmY/s320/gnome-tweak-tool-dynamic-workspaces.png" width="320" /></a></div>
<br />
I also like to use keyboard shortcuts to switch between workspaces and move windows to various workspaces. CTRL-F1 to go to workspaces 1, CTRL-F2 for workspace 2, etc. And CTRL-SHIFT-F<i>N</i> to move a window to workspace <i>N</i>. Unfortunately, the Keyboard Settings Shortcuts GUI <a href="https://bugzilla.redhat.com/show_bug.cgi?id=826024" target="_blank">only shows the hotkey settings for desktops 1 through 4</a>:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhtTNSu6gPam63mFGSIvSjzwVe0Zi9ZWEZqr5XrznoUgH1KD5MQmu0J1Wumh45BwAWA5GWuiSmmv3P_801M8oRyzsPf-7m-rDulfutSsYOneDg9KbZxpX-uiHZShIZDOa6H5mHKU7iHhxY/s1600/gnome-keyboard-shortcuts.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="232" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhtTNSu6gPam63mFGSIvSjzwVe0Zi9ZWEZqr5XrznoUgH1KD5MQmu0J1Wumh45BwAWA5GWuiSmmv3P_801M8oRyzsPf-7m-rDulfutSsYOneDg9KbZxpX-uiHZShIZDOa6H5mHKU7iHhxY/s320/gnome-keyboard-shortcuts.png" width="320" /></a></div>
<br />
It is possible to create keyboard shortcuts for desktops 5 and up, but the settings are hidden away in the <span style="font-family: monospace;">gsettings</span> database. So fire up a terminal window and run:<br />
<br />
<div id="jbcode">
<code>[user@localhost ~]$ gsettings set org.gnome.desktop.wm.keybindings \<br />
switch-to-workspace-5 "[\"<Control>F5\"]"<br />
[user@localhost ~]$ gsettings set org.gnome.desktop.wm.keybindings \<br />
move-to-workspace-5 "[\"<Control><Shift>F5\"]"</code></div>
<br />
This sets CTRL-F5 to switch to workspace 5, and CTRL-SHIFT-F5 to move the current window to workspace 5. Feel free to choose other keys like ALT or SUPER.<br />
<br />
To make life easier, I wrote this simple script to change all the hotkeys for desktops 1 through 12:<br />
<br />
<div id="jbcode">
<code>#!/bin/bash<br /><br /># Disable dynamic workspaces and set 12 fixed workspaces, and set the<br /># hot-keys for switching and moving windows to the workspaces.<br />#<br /># The Gnome 3.4 Shell keyboard settings GUI only exposes hot-key configuration<br /># for workspaces 1-4 so you have to use the command line for spaces 5+.<br />#<br /># Jeff Bastian, 2012-06-20<br /><br />echo "Disabling dynamic workspaces"<br />gsettings set org.gnome.shell.overrides dynamic-workspaces false<br /><br />echo "Setting 12 fixed workspaces"<br />gsettings set org.gnome.desktop.wm.preferences num-workspaces 12<br /><br />for ((x=1 ; x <= 12 ; x++)) ; do<br /> echo "Setting hotkeys for workspace $x"<br /> gsettings set org.gnome.desktop.wm.keybindings \<br /> switch-to-workspace-$x "[\"<Control>F$x\"]"<br /> gsettings set org.gnome.desktop.wm.keybindings \<br /> move-to-workspace-$x "[\"<Control><Shift>F$x\"]"<br />done<br /><br />echo "Done"<br />echo "~~~~"<br />echo "Verify Settings:"<br />gsettings list-recursively org.gnome.shell.overrides | grep dynamic-workspaces<br />gsettings list-recursively org.gnome.desktop.wm.preferences | grep num-workspaces<br />gsettings list-recursively org.gnome.desktop.wm.keybindings | grep to-workspace</code></div>
<br />Jeff Bastianhttp://www.blogger.com/profile/18128075341421142000noreply@blogger.com6tag:blogger.com,1999:blog-3014099941823379560.post-20549402232359987062011-11-26T13:46:00.002-06:002011-11-26T14:15:49.032-06:00A PandaBoard Desktop with Fedora 13A serial port console, while nice and simple to work on, is a little lacking for eye candy, so today I installed X Windows and Xfce to run a desktop on my PandaBoard.<br />
<br />
The installation was the easy part:<br />
<div id="jbcode"><code>yum -y groupinstall Base 'X Window System' 'XFCE' 'GNOME Desktop Environment'</code></div><br />
And then it was hurry-up-and-wait while it installed 421 packages.<br />
<br />
When it finished, I rebooted it and found a few problems that I had to fix. The default resolution for the display is a safe 640x480, so I had to add a kernel command line option to make it 1280x1024: <tt><a href="http://omappedia.org/wiki/Bootargs_for_enabling_display#DSS_specific_bootargs" target="_blank">omapfb.mode=dvi:1280x1024MR-24@60</a></tt>. I also added another <tt>console=tty0</tt> option so both the serial port and the display could be consoles. The last console parameter is the primary console and for now I kept the serial port as primary for easier debugging.<br />
<br />
<div id="jbcode"><code>[root@fedora-arm ~]# mount /dev/mmcblk0p1 /mnt/boot<br />
[root@fedora-arm ~]# cd /mnt/boot<br />
[root@fedora-arm boot]# vim boot.cmd<br />
[root@fedora-arm boot]# cat boot.cmd<br />
setenv mpurate 800<br />
setenv bootargs '<span style="color: red;">console=tty0</span> console=ttyO2,115200n8 ro rootwait root=/dev/sda1 mpurate=${mpurate} init=/sbin/init earlyprintk rd_NO_PLYMOUTH selinux=0 <span style="color: red;">omapfb.mode=dvi:1280x1024MR-24@60</span>'<br />
setenv bootcmd 'mmc rescan 0; mmc init; fatload mmc 0:1 0x80300000 uImage; fatload mmc 0:1 0x81600000 uInitrd; bootm 0x80300000 0x81600000'<br />
boot<br />
[root@fedora-arm boot]# mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n 'Pandaboard Boot Script' -d boot.cmd boot.scr<br />
Image Name: Pandaboard Boot Script<br />
Created: Sat Nov 26 14:22:00 2011<br />
Image Type: ARM Linux Script (uncompressed)<br />
Data Size: 359 Bytes = 0.35 kB = 0.00 MB<br />
Load Address: 00000000<br />
Entry Point: 00000000<br />
Contents:<br />
Image 0: 351 Bytes = 0.34 kB = 0.00 MB<br />
[root@fedora-arm boot]# cd <br />
[root@fedora-arm ~]# umount /mnt/boot</code></div><br />
I then updated /etc/inittab to make runlevel 5 the default and rebooted the PandaBoard again.<br />
<br />
I noticed ntpdate was failing to set the clock. I tried running it manually and noticed it couldn't resolve the hostname 0.fedora.pool.ntp.org. A quick peek at /etc/resolv.conf showed that NetworkManager had re-written the file with nothing but comments because I have /etc/sysconfig/network-scripts/ifcfg-eth0 set up for a static IP address for now. So I disabled NetworkManager with chkconfig and cleaned up resolv.conf and rebooted once more.<br />
<br />
This time it almost worked. It went through all the boot scripts cleanly, but it got stuck when it should have started X11 and gdm. Fortunately the serial console still worked, so I logged in and discovered that the /etc/rc.d/rc script was still running and starting up runlevel 5, but it didn't seem to be doing anything. I then found it was waiting for /etc/rc.d/rc5.d/S99local to finish (aka /etc/rc.d/rc.local). I looked at this script and remembered the <a href="http://jeffbastian.blogspot.com/2011/04/my-pandaboard-is-unboxed-and-ready-to.html" target="_blank">"ugly hack"</a> I had to set up back in April to run agetty on the serial port. It was running in a never-ending loop which means it will never finish and the init scripts will never start X11. <br />
<br />
The Fedora ARM page no longer mentions this ugly hack, so I guess the bug has been fixed and I can use a normal upstart job to manage agetty on the serial port. I commented out the hack in the rc.local script and created a new /etc/init/serial-ttyO2.conf job:<br />
<br />
<div id="jbcode"><code>[root@fedora-arm ~]# cat /etc/rc.d/rc.local<br />
#!/bin/sh<br />
#<br />
# This script will be executed *after* all the other init scripts.<br />
# You can put your own initialization stuff in here if you don't<br />
# want to do the full Sys V style init stuff.<br />
<br />
touch /var/lock/subsys/local<br />
<br />
# horrible hack to respawn serial console<br />
###while true<br />
###do<br />
### /sbin/agetty -L 115200 console vt100<br />
###done<br />
<br />
[root@fedora-arm ~]# cat /etc/init/serial-ttyO2.conf <br />
start on stopped rc RUNLEVEL=[2345]<br />
stop on runlevel [016]<br />
<br />
respawn<br />
pre-start exec /sbin/securetty ttyO2<br />
exec /sbin/agetty /dev/ttyO2 115200 vt100-nav</code><br />
<code><br />
[root@fedora-arm ~]# initctl start serial-ttyO2<br />
serial-ttyO2 start/running, process 20245</code></div><br />
One final reboot and ... Hooray! It ran through the firstboot setup and then launched X11 and gdm. I logged in to Xfce and launched Firefox and a Terminal. I now have a completely silent desktop!<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi5EUD2x6bTVIRcqIZX_Ag6WUYi3iO2Uf90cTpEq3DtE3_9eROODrNoUNeh1uffk4b8leIyNlS0uWwQPgbycBIj7nmYNonbFOtbQBcjdZr34AiiyYT7_5DGU8zuhrJ2G8pbPXxFa62pNBc/s1600/fedora-arm-desktop.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="256" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi5EUD2x6bTVIRcqIZX_Ag6WUYi3iO2Uf90cTpEq3DtE3_9eROODrNoUNeh1uffk4b8leIyNlS0uWwQPgbycBIj7nmYNonbFOtbQBcjdZr34AiiyYT7_5DGU8zuhrJ2G8pbPXxFa62pNBc/s320/fedora-arm-desktop.png" width="320" /></a></div>Jeff Bastianhttp://www.blogger.com/profile/18128075341421142000noreply@blogger.com0tag:blogger.com,1999:blog-3014099941823379560.post-49823792751461736312011-11-14T13:09:00.003-06:002011-11-14T13:17:55.667-06:00System Clock on the PandaBoardA quick way to find the physical device backing a filesystem is to use the 'df' command. (LVM, software-RAID, LUKS, and other layers can make this more complicated.) I did this on my PandaBoard and was a little surprised at the answer:<br />
<br />
<div id="jbcode"><code>[root@fedora-arm ~]# df -Th /<br />
Filesystem Type Size Used Avail Use% Mounted on<br />
/dev/root nfs 7.4G 1.8G 5.3G 25% /</code></div><br />
Why is it NFS-mounting a USB flash drive? And /dev/root doesn't tell me what the device name is. I was expecting to see something like sda1 or mmcblk0p1.<br />
<br />
I thought that was weird, so I edited /etc/fstab and changed the device and filesystem type:<br />
<div id="jbcode"><code>[root@fedora-arm ~]# diff -u /etc/fstab.ORIG /etc/fstab<br />
--- /etc/fstab.ORIG 2011-11-14 10:09:40.000000000 -0600<br />
+++ /etc/fstab 2011-11-14 12:48:58.000000000 -0600<br />
@@ -1,4 +1,4 @@<br />
-/dev/<span style="color: red;">root</span> / <span style="color: red;">nfs</span> defaults 1 1<br />
+/dev/<span style="color: red;">sda1</span> / <span style="color: red;">ext3</span> defaults 1 1</code></div><br />
And then I rebooted my PandaBoard and quickly learned why it's set to NFS:<br />
<div id="jbcode"><code> Welcome to Fedora <br />
Press 'I' to enter interactive startup.<br />
Starting udev: [ OK ]<br />
Setting hostname fedora-arm: [ OK ]<br />
Setting up Logical Volume Management: No volume groups found<br />
[ OK ]<br />
Checking filesystems<br />
Checking all file systems.<br />
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/sda1 <br />
fedoraroot: Superblock last mount time (Mon Nov 14 11:19:35 2011,<br />
now = Sat Jan 1 00:00:01 2000) is in the future.<br />
<br />
<br />
fedoraroot: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.<br />
(i.e., without -a or -p options)<br />
[FAILED]</code></div><br />
There's no battery-backed clock on the PandaBoard so the clock gets reset to 2000-01-01 00:00:00 every time it's power-cycled, and this causes the Fedora boot scripts to get confused and force a filesystem check.<br />
<br />
Apparently mounting the root filesystem as NFS is one way to workaround this problem.<br />
<br />
I mentioned this in #fedora-arm on <a href="http://freenode.net/">freenode</a> and Chris Tyler suggested modifying the boot scripts to set the clock to 1 minute past the previous write time of the root filesystem.<br />
<br />
Here's what I came up with:<br />
<div id="jbcode"><code>--- /etc/rc.d/rc.sysinit.ORIG 2011-03-08 15:51:46.000000000 -0600<br />
+++ /etc/rc.d/rc.sysinit 2011-11-14 12:44:28.441405990 -0600<br />
@@ -577,6 +577,15 @@<br />
fi<br />
if [ -z "$fastboot" -a "$READONLY" != "yes" ]; then<br />
<br />
+ # set the clock on the PandaBoard to 1 minute after last write<br />
+ # time of root filesystem to avoid "last mount is in the future"<br />
+ echo "Current system clock is $(date)"<br />
+ rootdev=$(egrep '\s/\s' /etc/fstab | awk '{print $1}')<br />
+ lastwrite=$(dumpe2fs -h $rootdev 2>/dev/null | \<br />
+ grep "Last write time" | sed -e 's/^[^:]*:\s*//')<br />
+ echo "Setting system clock to 1 minute after $lastwrite"<br />
+ date -s "$lastwrite + 1 minute"<br />
+<br />
STRING=$"Checking filesystems"<br />
echo $STRING<br />
fsck -T -t noopts=_netdev -A $fsckoptions</code></div><br />
Notice the new messages (red text) during boot:<br />
<div id="jbcode"><code> Welcome to Fedora <br />
Press 'I' to enter interactive startup.<br />
Starting udev: [ OK ]<br />
Setting hostname fedora-arm: [ OK ]<br />
Setting up Logical Volume Management: No volume groups found<br />
[ OK ]<br />
<span style="color: red;">Current system clock is Sat Jan 1 00:00:01 CST 2000</span><br style="color: red;" /><span style="color: red;"> Setting system clock to 1 minute after Mon Nov 14 12:45:36 2011</span><br style="color: red;" /><span style="color: red;"> Mon Nov 14 12:46:36 CST 2011</span><br />
Checking filesystems<br />
Checking all file systems.<br />
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/sda1 <br />
fedoraroot: clean, 69076/489600 files, 487736/1957605 blocks<br />
[ OK ]<br />
...</code></div><br />
<br />
And the root filesystem and device look correct now!<br />
<div id="jbcode"><code>[root@fedora-arm ~]# df -Th /<br />
Filesystem Type Size Used Avail Use% Mounted on<br />
/dev/sda1 ext3 7.4G 1.8G 5.3G 25% /</code></div><br />
Note that I do have ntpd start later in the boot process which sets the actual correct time.Jeff Bastianhttp://www.blogger.com/profile/18128075341421142000noreply@blogger.com1tag:blogger.com,1999:blog-3014099941823379560.post-47966403277994455292011-09-14T13:27:00.000-05:002011-09-14T13:27:28.624-05:00SD Card SpeedsAfter yesterday's benchmarks revealed a possible problem with the SD card performance, <a href="http://lists.fedoraproject.org/pipermail/arm/2011-September/001957.html">Mark Salter asked me to run a few more tests</a> to see if <a href="https://lwn.net/Articles/457145/">the DMA API patch set</a> is hurting the SD card (but helping USB storage).<br />
<br />
I recompiled the 2.6.40.3-2.02.fc13.armv7l.omap kernel but I disabled the DMA API patch set. I also tested with smp (the default) and nosmp. And just for good measure, I re-tested the 2.6.35-g6d019da-dirty kernel because the last time I tested 2.6.35 was in May and I've updated a few packages since then.<br />
<br />
It does not appear that the DMA API patch set is to blame for the slower SD card performance. The random seek times were longer than 76000ms for all variants of 2.6.40.3 compared to just 664ms on 2.6.35. The sequential reads were fastest with 2.6.35, but today's test was quite a bit faster than May's test; I'm not sure what to make of that. Likewise, sequential writes were also fastest with 2.6.35.<br />
<br />
Thus, some other change between 2.6.35 and 2.6.40 must be responsible for the drop in SD card performance, but what?<br />
<br />
<table align="center" border="3" cellpadding="2" cellspacing="1"><tbody>
<tr><td class="header" colspan="2"><span><b>Version 1.96</b></span></td><td class="header" colspan="6"><span><b>Sequential Output</b></span></td><td class="header" colspan="4"><span><b>Sequential Input</b></span></td><td class="header" colspan="2" rowspan="2"><span><b>Random<br />
Seeks</b></span></td></tr>
<tr><td></td><td>Size</td><td colspan="2">Per Char</td><td colspan="2">Block</td><td colspan="2">Rewrite</td><td colspan="2">Per Char</td><td colspan="2">Block</td></tr>
<tr><td colspan="2"></td><td class="ksec"><span>K/sec</span></td><td class="ksec"><span>% CPU</span></td><td class="ksec"><span>K/sec</span></td><td class="ksec"><span>% CPU</span></td><td class="ksec"><span>K/sec</span></td><td class="ksec"><span>% CPU</span></td><td class="ksec"><span>K/sec</span></td><td class="ksec"><span>% CPU</span></td><td class="ksec"><span>K/sec</span></td><td class="ksec"><span>% CPU</span></td><td class="ksec"><span>/sec</span></td><td class="ksec"><span>% CPU</span></td></tr>
<tr><td bgcolor="#FFFFFF" class="rowheader" rowspan="2"><span>SD Card 2.6.35 (May 2011)</span></td><td bgcolor="#FFFFFF" class="size">2G</td><td bgcolor="#00FF00">41</td><td bgcolor="#38C700">93</td><td bgcolor="#07F800">3125</td><td bgcolor="#39C600">5</td><td bgcolor="#4DB200">3371</td><td bgcolor="#5CA300">4</td><td bgcolor="#C63900">336</td><td bgcolor="#A25D00">99</td><td bgcolor="#B44B00">17598</td><td bgcolor="#A85700">15</td><td bgcolor="#25DA00">27.4</td><td bgcolor="#14EB00">1</td></tr>
<tr><td bgcolor="#FFFFFF" class="size" colspan="1">Latency</td><td bgcolor="#00FF00" colspan="2">1168ms</td><td bgcolor="#54AB00" colspan="2">33487ms</td><td bgcolor="#1BE400" colspan="2">32391ms</td><td bgcolor="#C83700" colspan="2">44466us</td><td bgcolor="#FF0000" colspan="2">2628ms</td><td bgcolor="#00FF00" colspan="2">663ms</td></tr>
<tr><td bgcolor="#FFFFFF" class="rowheader" rowspan="2"><span>SD Card 2.6.35 (Sept 2011)</span></td><td bgcolor="#FFFFFF" class="size">2G</td><td bgcolor="#17E800">39</td><td bgcolor="#41BE00">91</td><td bgcolor="#08F700">3118</td><td bgcolor="#39C600">5</td><td bgcolor="#41BE00">3465</td><td bgcolor="#53AC00">4</td><td bgcolor="#5EA100">448</td><td bgcolor="#3AC500">99</td><td bgcolor="#976800">19104</td><td bgcolor="#A05F00">16</td><td bgcolor="#1CE300">27.9</td><td bgcolor="#0FF000">1</td></tr>
<tr><td bgcolor="#FFFFFF" class="size" colspan="1">Latency</td><td bgcolor="#B54A00" colspan="2">3900ms</td><td bgcolor="#AF5000" colspan="2">42424ms</td><td bgcolor="#E01F00" colspan="2">54958ms</td><td bgcolor="#00FF00" colspan="2">19929us</td><td bgcolor="#01FE00" colspan="2">667ms</td><td bgcolor="#01FE00" colspan="2">664ms</td></tr>
<tr><td bgcolor="#FFFFFF" class="rowheader" rowspan="2"><span>SD Card 2.6.40.3 + DMA patch + SMP</span></td><td bgcolor="#FFFFFF" class="size">2G</td><td bgcolor="#D32C00">22</td><td bgcolor="#966900">65</td><td bgcolor="#D22D00">1862</td><td bgcolor="#A35C00">4</td><td bgcolor="#B74800">2544</td><td bgcolor="#5AA500">3</td><td bgcolor="#C33C00">339</td><td bgcolor="#9E6100">99</td><td bgcolor="#8D7200">19626</td><td bgcolor="#956A00">16</td><td bgcolor="#F10E00">15.6</td><td bgcolor="#E41B00">1</td></tr>
<tr><td bgcolor="#FFFFFF" class="size" colspan="1">Latency</td><td bgcolor="#6C9300" colspan="2">2793ms</td><td bgcolor="#30CF00" colspan="2">29928ms</td><td bgcolor="#56A900" colspan="2">39111ms</td><td bgcolor="#F90600" colspan="2">50446us</td><td bgcolor="#00FF00" colspan="2">665ms</td><td bgcolor="#EC1300" colspan="2">76023ms</td></tr>
<tr><td bgcolor="#FFFFFF" class="rowheader" rowspan="2"><span>SD Card 2.6.40.3 + DMA patch + nosmp</span></td><td bgcolor="#FFFFFF" class="size">2G</td><td bgcolor="#F40B00">19</td><td bgcolor="#A45B00">58</td><td bgcolor="#F20D00">1669</td><td bgcolor="#5FA000">3</td><td bgcolor="#BB4400">2513</td><td bgcolor="#5EA100">3</td><td bgcolor="#C03F00">343</td><td bgcolor="#996600">99</td><td bgcolor="#778800">20829</td><td bgcolor="#37C800">13</td><td bgcolor="#D52A00">17.2</td><td bgcolor="#B74800">1</td></tr>
<tr><td bgcolor="#FFFFFF" class="size" colspan="1">Latency</td><td bgcolor="#708F00" colspan="2">2858ms</td><td bgcolor="#857A00" colspan="2">38268ms</td><td bgcolor="#708F00" colspan="2">42161ms</td><td bgcolor="#FE0100" colspan="2">51148us</td><td bgcolor="#01FE00" colspan="2">667ms</td><td bgcolor="#EE1100" colspan="2">76651ms</td></tr>
<tr><td bgcolor="#FFFFFF" class="rowheader" rowspan="2"><span>SD Card 2.6.40.3 + no patch + SMP</span></td><td bgcolor="#FFFFFF" class="size">2G</td><td bgcolor="#A75800">26</td><td bgcolor="#926D00">76</td><td bgcolor="#F20D00">1669</td><td bgcolor="#5FA000">3</td><td bgcolor="#DB2400">2271</td><td bgcolor="#837C00">3</td><td bgcolor="#807F00">411</td><td bgcolor="#56A900">99</td><td bgcolor="#8E7100">19592</td><td bgcolor="#966900">16</td><td bgcolor="#EF1000">15.7</td><td bgcolor="#E11E00">1</td></tr>
<tr><td bgcolor="#FFFFFF" class="size" colspan="1">Latency</td><td bgcolor="#708F00" colspan="2">2855ms</td><td bgcolor="#609F00" colspan="2">34616ms</td><td bgcolor="#FB0400" colspan="2">58124ms</td><td bgcolor="#14EB00" colspan="2">22279us</td><td bgcolor="#01FE00" colspan="2">666ms</td><td bgcolor="#FF0000" colspan="2">82254ms</td></tr>
<tr><td bgcolor="#FFFFFF" class="rowheader" rowspan="2"><span>SD Card 2.6.40.3 + no patch + nosmp</span></td><td bgcolor="#FFFFFF" class="size">2G</td><td bgcolor="#FF0000">18</td><td bgcolor="#9D6200">54</td><td bgcolor="#FC0300">1603</td><td bgcolor="#6E9100">3</td><td bgcolor="#CB3400">2395</td><td bgcolor="#6F9000">3</td><td bgcolor="#9B6400">382</td><td bgcolor="#708F00">99</td><td bgcolor="#768900">20894</td><td bgcolor="#36C900">13</td><td bgcolor="#E11E00">16.5</td><td bgcolor="#C93600">1</td></tr>
<tr><td bgcolor="#FFFFFF" class="size" colspan="1">Latency</td><td bgcolor="#FF0000" colspan="2">5020ms</td><td bgcolor="#59A600" colspan="2">33958ms</td><td bgcolor="#03FC00" colspan="2">29546ms</td><td bgcolor="#FF0000" colspan="2">51301us</td><td bgcolor="#01FE00" colspan="2">666ms</td><td bgcolor="#F10E00" colspan="2">77587ms</td></tr>
</tbody></table>Jeff Bastianhttp://www.blogger.com/profile/18128075341421142000noreply@blogger.com0tag:blogger.com,1999:blog-3014099941823379560.post-22174574113491063952011-09-13T09:43:00.002-05:002011-09-13T10:51:02.882-05:00Storage Speed on the PandaBoard Revisited (Again)Since my last post, I took a short vacation and I've been helping in the <a href="http://lists.fedoraproject.org/pipermail/arm/2011-August/001861.html">Virtual Fedora Activity Days (VFAD) to rebuild packages for Fedora 15 hardfp (hardware floating point)</a>.<br />
<br />
Research into the slow storage speeds on the PandaBoard (and other Cortex-ARM9 systems) has continued and <a href="https://lwn.net/Articles/457145/">a patch set developed</a> to hopefully improve the situation. David Marlin <a href="http://lists.fedoraproject.org/pipermail/arm/2011-September/001940.html">built a 2.6.40.3-2.02.fc13.armv7l.omap kernel with the patch set</a>, so I downloaded a copy and ran bonnie++ again.<br />
<br />
The results were mixed for the SD card. Sequential reads had a nice improvement, but sequential output and random seeks took a big hit. The random seek times are particularly worrisome with an increase from 663ms to 76023ms! Something doesn't seem right.<br />
<br />
The USB hard drive, though, saw some nice improvements overall. Sequential write latencies dropped from 5.8 seconds down to 0.38 seconds and throughput more than doubled: 9 MiB/s vs 23 MiB/s! Sequential reads latencies increased a bit, but throughput again more than doubled: 12 MiB/s vs 27 MiB/s! Random seeks also saw a nice improvement from 7.6s down to 4.9s.<br />
<br />
<br />
<table align="center" border="3" cellpadding="2" cellspacing="1"><tbody>
<tr><td class="header" colspan="2"><b>Version 1.96</b></td><td class="header" colspan="6"><b>Sequential Output</b></td><td class="header" colspan="4"><b>Sequential Input</b></td><td class="header" colspan="2" rowspan="2"><b>Random<br />
Seeks</b></td></tr>
<tr><td></td><td>Size</td><td colspan="2">Per Char</td><td colspan="2">Block</td><td colspan="2">Rewrite</td><td colspan="2">Per Char</td><td colspan="2">Block</td></tr>
<tr><td colspan="2"></td><td class="ksec">K/sec</td><td class="ksec">% CPU</td><td class="ksec">K/sec</td><td class="ksec">% CPU</td><td class="ksec">K/sec</td><td class="ksec">% CPU</td><td class="ksec">K/sec</td><td class="ksec">% CPU</td><td class="ksec">K/sec</td><td class="ksec">% CPU</td><td class="ksec">/sec</td><td class="ksec">% CPU</td></tr>
<tr><td bgcolor="#FFFFFF" class="rowheader" rowspan="2">SD Card 2.6.35-g6d019da-dirty</td><td bgcolor="#FFFFFF" class="size">2G</td><td bgcolor="#1EE100">41</td><td bgcolor="#3DC200">93</td><td bgcolor="#F10E00">3125</td><td bgcolor="#788700">5</td><td bgcolor="#E71800">3371</td><td bgcolor="#55AA00">4</td><td bgcolor="#A25D00">336</td><td bgcolor="#768900">99</td><td bgcolor="#A65900">17598</td><td bgcolor="#9C6300">15</td><td bgcolor="#E91600">27.4</td><td bgcolor="#00FF00">1</td></tr>
<tr><td bgcolor="#FFFFFF" class="size" colspan="1">Latency</td><td bgcolor="#5FA000" colspan="2">1168ms</td><td bgcolor="#FF0000" colspan="2">33487ms</td><td bgcolor="#D32C00" colspan="2">32391ms</td><td bgcolor="#47B800" colspan="2">44466us</td><td bgcolor="#FF0000" colspan="2">2628ms</td><td bgcolor="#00FF00" colspan="2">663ms</td></tr>
<tr><td bgcolor="#FFFFFF" class="rowheader" rowspan="2">SD Card 2.6.40.3-2.02.fc13.armv7l.omap</td><td bgcolor="#FFFFFF" class="size">2G</td><td bgcolor="#FD0200">22</td><td bgcolor="#9D6200">65</td><td bgcolor="#FF0000">1862</td><td bgcolor="#F80700">4</td><td bgcolor="#FF0000">2544</td><td bgcolor="#53AC00">3</td><td bgcolor="#9F6000">339</td><td bgcolor="#738C00">99</td><td bgcolor="#847B00">19626</td><td bgcolor="#8A7500">16</td><td bgcolor="#FF0000">15.6</td><td bgcolor="#A45B00">1</td></tr>
<tr><td bgcolor="#FFFFFF" class="size" colspan="1">Latency</td><td bgcolor="#FF0000" colspan="2">2793ms</td><td bgcolor="#E41B00" colspan="2">29928ms</td><td bgcolor="#FF0000" colspan="2">39111ms</td><td bgcolor="#738C00" colspan="2">50446us</td><td bgcolor="#39C600" colspan="2">665ms</td><td bgcolor="#FF0000" colspan="2">76023ms</td></tr>
<tr><td bgcolor="#FFFFFF" class="rowheader" rowspan="2">USB HD 2.6.35-g6d019da-dirty</td><td bgcolor="#FFFFFF" class="size">2G</td><td bgcolor="#06F900">43</td><td bgcolor="#42BD00">99</td><td bgcolor="#AB5400">9017</td><td bgcolor="#A15E00">16</td><td bgcolor="#C43B00">4538</td><td bgcolor="#7C8300">6</td><td bgcolor="#7F8000">369</td><td bgcolor="#55AA00">99</td><td bgcolor="#FF0000">12357</td><td bgcolor="#609F00">9</td><td bgcolor="#6C9300">93.9</td><td bgcolor="#A25D00">6</td></tr>
<tr><td bgcolor="#FFFFFF" class="size" colspan="1">Latency</td><td bgcolor="#00FF00" colspan="2">215ms</td><td bgcolor="#2BD400" colspan="2">5849ms</td><td bgcolor="#25DA00" colspan="2">5889ms</td><td bgcolor="#847B00" colspan="2">52858us</td><td bgcolor="#00FF00" colspan="2">108ms</td><td bgcolor="#18E700" colspan="2">7643ms</td></tr>
<tr><td bgcolor="#FFFFFF" class="rowheader" rowspan="2">USB HD 2.6.40.3-2.02.fc13.armv7l.omap</td><td bgcolor="#FFFFFF" class="size">2G</td><td bgcolor="#35CA00">39</td><td bgcolor="#639C00">99</td><td bgcolor="#00FF00">23519</td><td bgcolor="#04FB00">26</td><td bgcolor="#00FF00">11118</td><td bgcolor="#837C00">15</td><td bgcolor="#AB5400">327</td><td bgcolor="#817E00">99</td><td bgcolor="#00FF00">27314</td><td bgcolor="#3FC000">18</td><td bgcolor="#00FF00">150.6</td><td bgcolor="#FF0000">12</td></tr>
<tr><td bgcolor="#FFFFFF" class="size" colspan="1">Latency</td><td bgcolor="#0BF400" colspan="2">322ms</td><td bgcolor="#00FF00" colspan="2">383ms</td><td bgcolor="#00FF00" colspan="2">341ms</td><td bgcolor="#916E00" colspan="2">54567us</td><td bgcolor="#3CC300" colspan="2">697ms</td><td bgcolor="#0FF000" colspan="2">4910ms</td></tr>
</tbody></table><br />
I also tried a simple test with hdparm as shown on lwn.net:<br />
<br />
<div id="jbcode"><code>[root@fedora-arm ~]# uname -r<br />
2.6.40.3-2.02.fc13.armv7l.omap<br />
<br />
[root@fedora-arm ~]# hdparm -t /dev/mmcblk0p4<br />
<br />
/dev/mmcblk0p4:<br />
Timing buffered disk reads: 50 MB in 3.10 seconds = 16.11 MB/sec<br />
<br />
[root@fedora-arm ~]# hdparm -t /dev/sda1<br />
<br />
/dev/sda1:<br />
Timing buffered disk reads: 66 MB in 3.05 seconds = 21.64 MB/sec</code></div><br />
Compared to the older kerrnel:<br />
<br />
<div id="jbcode"><code>[root@fedora-arm ~]# uname -r<br />
2.6.35-g6d019da-dirty<br />
<br />
[root@fedora-arm ~]# hdparm -t /dev/mmcblk0p4<br />
<br />
/dev/mmcblk0p4:<br />
Timing buffered disk reads: 50 MB in 3.09 seconds = 16.20 MB/sec<br />
<br />
[root@fedora-arm ~]# hdparm -t /dev/sda1<br />
<br />
/dev/sda1:<br />
Timing buffered disk reads: 26 MB in 3.04 seconds = 8.56 MB/sec<br />
</code></div><br />
The SD card's performance is about the same, but the USB hard drive is much faster with the new patch!Jeff Bastianhttp://www.blogger.com/profile/18128075341421142000noreply@blogger.com2tag:blogger.com,1999:blog-3014099941823379560.post-38291917105567388932011-07-14T17:20:00.002-05:002011-07-14T17:27:04.739-05:00Persistent MAC Address on the PandaBoardThe PandaBoard <a href="http://lwn.net/Articles/435894/">doesn't have an EEPROM to store a MAC address</a> for the on-board NIC, and as a result, a new random MAC address is generated on boot. This can be a problem for DHCP lease pools, firewall rules, and more.<br />
<br />
I mentioned in an earlier post that Ubuntu 11.04 is somehow keeping the NIC's MAC address persistent despite the lack of an EEPROM. I investigated a bit and found it was a simple combination of (1) setting a MAC address in the NetworkManager settings and (2) this driver patch going into the latest upstream kernels: <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f4e8ab7cc4e819011ca6325e54383b3da7a5d130">smsc95xx: generate random MAC address once, not every ifup</a>.<br />
<br />
Back in Fedora 13, I upgraded to David Marlin's latest 2.6.39-1.01.fc13.armv7l kernel from <a href="http://people.redhat.com/dmarlin/packages/FedoraArm/">http://people.redhat.com/dmarlin/packages/FedoraArm/</a> — which includes the above patch — and booted the PandaBoard.<br />
<br />
The first thing I noticed was that the NIC is named <tt>eth0</tt> now instead of <tt>usb0</tt> (that's a nice touch) and, as expected, it has a new random MAC address:<br />
<div id="jbcode"><code>[root@fedora-arm ~]# ifconfig -a<br />
eth0 Link encap:Ethernet HWaddr 4E:19:68:14:3C:F9 <br />
BROADCAST MULTICAST MTU:1492 Metric:1<br />
...</code></div><br />
I changed the MAC address using the standard tools and it appeared to stick:<br />
<div id="jbcode"><code>[root@fedora-arm ~]# ifconfig eth0 hw ether CA:BC:15:4D:B4:49<br />
[root@fedora-arm ~]# ifconfig eth0<br />
eth0 Link encap:Ethernet HWaddr CA:BC:15:4D:B4:49 <br />
BROADCAST MULTICAST MTU:1492 Metric:1<br />
...</code></div><br />
I wanted to make this survive a reboot, so I looked at the <tt>/etc/sysconfig/network-scripts/ifup-eth</tt> script and found this chunk:<br />
<div id="jbcode"><code># this isn't the same as the MAC in the configuration filename. It is<br />
# available as a configuration option in the config file, forcing the kernel<br />
# to think an ethernet card has a different MAC address than it really has.<br />
if [ -n "${MACADDR}" ]; then<br />
ip link set dev ${DEVICE} address ${MACADDR}<br />
fi</code></div><br />
(The <tt>ip</tt> command is preferred over the older <tt>ifconfig</tt> command.)<br />
<br />
So, I edited <tt>/etc/sysconfig/network-scripts/ifcfg-eth0</tt> and removed the HWADDR variable and set MACADDR instead:<br />
<div id="jbcode"><code>DEVICE=eth0<br />
BOOTPROTO=static<br />
ONBOOT=yes<br />
<strong>MACADDR=CA:BC:15:4D:B4:49</strong><br />
TYPE=Ethernet<br />
IPADDR=192.168.1.2<br />
NETMASK=255.255.255.0<br />
GATEWAY=192.168.1.1</code></div><br />
I rebooted the PandaBoard and it worked:<br />
<div id="jbcode"><code> Welcome to Fedora <br />
Press 'I' to enter interactive startup.<br />
Starting udev: [ OK ]<br />
Setting hostname fedora-arm: [ OK ]<br />
...<br />
fedora-arm login: root<br />
Password: <br />
Last login: Thu Jul 14 16:48:49 on console<br />
[root@fedora-arm ~]# ifconfig eth0 | grep HWaddr<br />
eth0 Link encap:Ethernet HWaddr CA:BC:15:4D:B4:49</code></div><br />
Hooray for persistent MAC addresses!Jeff Bastianhttp://www.blogger.com/profile/18128075341421142000noreply@blogger.com3tag:blogger.com,1999:blog-3014099941823379560.post-55617750621281452312011-07-09T12:49:00.003-05:002011-07-14T11:03:49.147-05:00PandaBoard Display Resolution<span class="Apple-style-span" style="font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13px; line-height: 18px;">I wanted to return to the persistent-MAC-address problem and compare Fedora vs Ubuntu, so I swapped SD cards to Ubuntu and powered up the PandaBoard. To my surprise, Ubuntu set the display resolution to 640x480. This Samsung 2233SW monitor supports 1920x1080, so why is it so low? I checked the Monitor Preferences and it only listed 640x480 as an option, and I fired up a terminal and 'xrand -q' reported the same. I know the last time I booted into Ubuntu in May, it was much higher than 640x480. What changed?<br />
<br />
I tried adding a new mode with 'xrandr --new-mode ...' but that didn't work.<br />
<br />
I found the Omappedia <a href="http://omappedia.org/wiki/Bootargs_for_enabling_display" style="color: #1d75a2; text-decoration: none;">Bootargs for Enabling Display</a> page and tried modifying my /boot/boot.script (and running flash-kernel) to add omapfb.mode=dvi:1920x1080MR-24@60 to the kernel command line arguments, but that didn't work either.<br />
<br />
A few hours and many unsuccessful attempts later, I looked around the room and saw an older Dell 1707FPc monitor sitting in the corner. Maybe I was using that monitor in May? It only supports 1280x1024, so maybe it will work better? I cleaned up my boot.script and swapped monitors and voila, it came up with 1280x1024!<br />
<br />
I guess the PandaBoard doesn't like this Samsung display for some reason.</span>Jeff Bastianhttp://www.blogger.com/profile/18128075341421142000noreply@blogger.com3tag:blogger.com,1999:blog-3014099941823379560.post-4949138084859930762011-06-02T11:45:00.000-05:002011-06-02T11:45:30.735-05:00Storage Speed on the PandaBoard RevisitedA <a href="http://lists.fedoraproject.org/pipermail/arm/2011-May/001392.html">recent thread on the Fedora arm mailing list</a> had me revisit the storage speed tests I ran recently. DJ Delorie found that his USB storage speed more than doubled if he <tt>ping</tt>ed the PandaBoard from another host. The PandaBoard's ethernet is part of the USB smsc95xx chipset, so it makes sense that they're related.<br />
<br />
With that in mind, I ran the bonnie++ tests again while <tt>ping</tt>ing the PandaBoard (from the same system running minicom to access the serial console of the PandaBoard). The first row is copied-and-pasted from the last test. The second row holds the new results.<br />
<br />
<table align="center" border="3" cellpadding="2" cellspacing="1"><tbody>
<tr><td colspan="2"><span><b>Version 1.96</b></span></td><td colspan="6"><span><b>Sequential Output</b></span></td><td colspan="4"><span><b>Sequential Input</b></span></td><td colspan="2" rowspan="2"><span><b>Random<br />
Seeks</b></span></td></tr>
<tr><td></td><td>Size</td><td colspan="2">Per Char</td><td colspan="2">Block</td><td colspan="2">Rewrite</td><td colspan="2">Per Char</td><td colspan="2">Block</td></tr>
<tr><td colspan="2"></td><td><span>K/sec</span></td><td><span>% CPU</span></td><td><span>K/sec</span></td><td><span>% CPU</span></td><td><span>K/sec</span></td><td><span>% CPU</span></td><td><span>K/sec</span></td><td><span>% CPU</span></td><td><span>K/sec</span></td><td><span>% CPU</span></td><td><span>/sec</span></td><td><span>% CPU</span></td></tr>
<tr><td bgcolor="#FFFFFF" rowspan="2"><span>USB HD</span></td><td bgcolor="#FFFFFF">2G</td><td bgcolor="#7F8000">43</td><td bgcolor="#55AA00">99</td><td bgcolor="#FF0000">9017</td><td bgcolor="#51AE00">16</td><td bgcolor="#FF0000">4538</td><td bgcolor="#5BA400">6</td><td bgcolor="#936C00">369</td><td bgcolor="#689700">99</td><td bgcolor="#FF0000">12357</td><td bgcolor="#51AE00">9</td><td bgcolor="#ED1200">93.9</td><td bgcolor="#609F00">6</td></tr>
<tr><td bgcolor="#FFFFFF" colspan="1">Latency</td><td bgcolor="#669900" colspan="2">215ms</td><td bgcolor="#FF0000" colspan="2">5849ms</td><td bgcolor="#FF0000" colspan="2">5889ms</td><td bgcolor="#4EB100" colspan="2">52858us</td><td bgcolor="#FF0000" colspan="2">108ms</td><td bgcolor="#FF0000" colspan="2">7643ms</td></tr>
<tr><td bgcolor="#FFFFFF" rowspan="2"><span>USB HD with ping</span></td><td bgcolor="#FFFFFF">2G</td><td bgcolor="#AB5400">38</td><td bgcolor="#817E00">99</td><td bgcolor="#00FF00">19038</td><td bgcolor="#857A00">39</td><td bgcolor="#00FF00">9709</td><td bgcolor="#7A8500">14</td><td bgcolor="#986700">364</td><td bgcolor="#6D9200">99</td><td bgcolor="#00FF00">24947</td><td bgcolor="#857A00">21</td><td bgcolor="#24DB00">162.7</td><td bgcolor="#748B00">11</td></tr>
<tr><td bgcolor="#FFFFFF" colspan="1">Latency</td><td bgcolor="#6E9100" colspan="2">220ms</td><td bgcolor="#00FF00" colspan="2">1714ms</td><td bgcolor="#00FF00" colspan="2">1319ms</td><td bgcolor="#897600" colspan="2">62165us</td><td bgcolor="#00FF00" colspan="2">16327us</td><td bgcolor="#00FF00" colspan="2">1542ms</td></tr>
</tbody></table><br />
That's amazing! Sequential Writes more than doubled: from 9017 K/sec to 19038 K/sec. And Sequential Reads doubled: from 12357 K/sec to 24947 K/sec!<br />
<br />
There seems to be a bug somewhere, maybe in the smsc95xx driver? If this can be fixed, using a USB hard drive could greatly improve the storage speeds on the PandaBoard.Jeff Bastianhttp://www.blogger.com/profile/18128075341421142000noreply@blogger.com3tag:blogger.com,1999:blog-3014099941823379560.post-87408330872462251342011-05-21T13:40:00.002-05:002011-05-31T09:58:13.598-05:00Storage Speed on the PandaBoardIn my experience so far with the PandaBoard, I noticed that the system feels sluggish using the SD card. I'm using a Class 6 SD card which means it can sustain 6 MB/sec writes. The USB 2.0 bus is capable of a max 480 Mbps, or 60 MB/sec; in practice, USB tops out at around 30 MB/sec due to CPU overhead. Still, that's quite a bit faster than the 6 MB/sec the SD card can do. With that in mind, I wanted to compare the performance of the SD card against a USB 2.0 hard drive.<br />
<br />
The bonnie++ tool is great for testing storage performance, so I installed it with a quick <tt>yum install bonnie++</tt> and ran it against both the SD card and the hard drive. I was using the <a href="http://scotland.proximity.on.ca/arm/kernel/pandaboard/2.6.35.3/"><tt>2.6.35-g6d019da-dirty</tt> kernel</a>.<br />
<br />
It's generally a good idea to store the output of bonnie++ on a different drive from the one being tested so as not to interfere with the results, so first create a RAM-disk:<br />
<br />
<div id="jbcode"><code>[root@fedora-arm ~]# mkdir /bonnie<br />
[root@fedora-arm ~]# mount -t tmpfs none /bonnie</code></div><br />
The SD card holds the root filesystem, so I tested it first; note that you have to run bonnie++ as a non-root user.<br />
<br />
<div id="jbcode"><code>[jbastian@fedora-arm ~]$ bonnie++ -d /tmp -n 0 -m "SD Card" -q 1>>/bonnie/bonnie.csv 2>/dev/null</code></div><br />
It takes a while for bonnie++ to do its thing, so I fired it up and grabbed a bucket of popcorn and a movie. When it finished, I ran it again on the USB hard drive: just change <tt>/tmp</tt> to <tt>/mnt/usb</tt>. The output is just appended to the bonnie.csv file.<br />
<br />
<div id="jbcode"><code>[jbastian@fedora-arm ~]$ bonnie++ -d /mnt/usb -n 0 -m "USB HD" -q 1>>/bonnie/bonnie.csv 2>/dev/null</code></div><br />
The output is CSV, but bonnie++ includes a tool to convert it to HTML to make it more readable:<br />
<br />
<div id="jbcode"><code>[jbastian@fedora-arm ~]$ bon_csv2html /bonnie/bonnie.csv > bonnie.html</code></div><br />
I used <tt>tidy -i</tt> to reformat the HTML a bit so I could remove the columns for the file creation tests (which I did not run), and the results look like:<br />
<br />
<table align="center" border="3" cellpadding="2" cellspacing="1"><tbody>
<tr><td class="header" colspan="2"><b>Version 1.96</b></td><td class="header" colspan="6"><b>Sequential Output</b></td><td class="header" colspan="4"><b>Sequential Input</b></td><td class="header" colspan="2" rowspan="2"><b>Random<br />
Seeks</b></td></tr>
<tr><td></td><td>Size</td><td colspan="2">Per Char</td><td colspan="2">Block</td><td colspan="2">Rewrite</td><td colspan="2">Per Char</td><td colspan="2">Block</td></tr>
<tr><td colspan="2"></td><td class="ksec">K/sec</td><td class="ksec">% CPU</td><td class="ksec">K/sec</td><td class="ksec">% CPU</td><td class="ksec">K/sec</td><td class="ksec">% CPU</td><td class="ksec">K/sec</td><td class="ksec">% CPU</td><td class="ksec">K/sec</td><td class="ksec">% CPU</td><td class="ksec">/sec</td><td class="ksec">% CPU</td></tr>
<tr><td bgcolor="#FFFFFF" class="rowheader" rowspan="2">SD Card</td><td bgcolor="#FFFFFF" class="size">2G</td><td bgcolor="#9E6100">41</td><td bgcolor="#679800">93</td><td bgcolor="#FF0000">3125</td><td bgcolor="#58A700">5</td><td bgcolor="#C83700">3371</td><td bgcolor="#57A800">4</td><td bgcolor="#A65900">336</td><td bgcolor="#7B8400">99</td><td bgcolor="#50AF00">17598</td><td bgcolor="#887700">15</td><td bgcolor="#FF0000">27.4</td><td bgcolor="#12ED00">1</td></tr>
<tr><td bgcolor="#FFFFFF" class="size" colspan="1">Latency</td><td bgcolor="#FF0000" colspan="2">1168ms</td><td bgcolor="#FF0000" colspan="2">33487ms</td><td bgcolor="#FF0000" colspan="2">32391ms</td><td bgcolor="#4CB300" colspan="2">44466us</td><td bgcolor="#FF0000" colspan="2">2628ms</td><td bgcolor="#00FF00" colspan="2">663ms</td></tr>
<tr><td bgcolor="#FFFFFF" class="rowheader" rowspan="2">USB HD</td><td bgcolor="#FFFFFF" class="size">2G</td><td bgcolor="#8D7200">43</td><td bgcolor="#6D9200">99</td><td bgcolor="#00FF00">9017</td><td bgcolor="#7D8200">16</td><td bgcolor="#5CA300">4538</td><td bgcolor="#7E8100">6</td><td bgcolor="#857A00">369</td><td bgcolor="#5AA500">99</td><td bgcolor="#D02F00">12357</td><td bgcolor="#4FB000">9</td><td bgcolor="#00FF00">93.9</td><td bgcolor="#DF2000">6</td></tr>
<tr><td bgcolor="#FFFFFF" class="size" colspan="1">Latency</td><td bgcolor="#00FF00" colspan="2">215ms</td><td bgcolor="#00FF00" colspan="2">5849ms</td><td bgcolor="#00FF00" colspan="2">5889ms</td><td bgcolor="#8B7400" colspan="2">52858us</td><td bgcolor="#00FF00" colspan="2">108ms</td><td bgcolor="#FF0000" colspan="2">7643ms</td></tr>
</tbody></table><br />
As I expected, the SD card clearly wins with random seek times: 663ms vs 7643ms. This is one of the major advantages of flash storage over traditional spinning magnetic media since flash does not have to move a head over the disk and then wait for the desired sector to spin under the head. It's interesting, though, that even with the significantly slower seek times, the hard drive managed to squeeze out 93.9 seeks/sec compared to only 27.4 seeks/sec on the SD card.<br />
<br />
The throughput results are more interesting. On sequential output, the hard drive is the winner with 9017 K/sec compared to the SD card's 3125 K/sec. Writing data is one of the weaknesses of flash storage since <a href="http://en.wikipedia.org/wiki/Flash_memory#Block_erasure">it has to re-write an entire block if you need to flip a bit from a 0 to 1</a>. For sequential input, the SD card managed a respectable 17598 K/sec vs the hard drive's 12357 K/sec.<br />
<br />
Overall, the SD card performs nicely on large sequential reads, but the USB hard drive seems to outperform it in general usage. Unfortunately, neither drive came close to the 30 MB/sec I was hoping for.<br />
<br />
Just for fun, I also ran zcav, another tool provided by bonnie++ to test the read rates over a hard drive. On a normal hard drive, the read rates will be faster on the outer edge of the disk since the outer tracks have a longer circumference and thus have more sectors compared to the inner tracks, thus more sectors pass under the head in one revolution of the disk on the outer tracks.<br />
<br />
On an SD card, the rates should be constant since there is no spinning disk.<br />
<br />
The zcav needs access to the raw device, so I'll run it as root. Again, store the zcav output in the RAM disk so it doesn't interfere with the testing. I only tested the first 8 GB of the hard drive since the SD card is only 8 GB in size, and also because testing all 200 GB would take all day!<br />
<br />
<div id="jbcode"><code>[root@fedora-arm ~]# zcav -l /bonnie/zcav-sdcard.out /dev/mmcblk0<br />
[root@fedora-arm ~]# zcav -r 8192 -l /bonnie/zcav-usbhd.out -f /dev/sda</code></div><br />
The output is just a series of numbers in three columns:<br />
<div id="jbcode"><code>#block offset (GiB), MiB/s, time<br />
0.00 14.59 17.547<br />
0.25 16.10 15.897<br />
0.50 15.09 16.966<br />
...</code></div><br />
I think this will be easier to make sense of as a graph, so <tt>gnuplot</tt> to the rescue:<br />
<br />
<div id="jbcode"><code>[jbastian@fedora-arm ~]$ gnuplot<br />
...<br />
gnuplot> set terminal png<br />
Terminal type set to 'png'<br />
Options are 'nocrop font /usr/share/fonts/dejavu/DejaVuSans.ttf 12 size 640,480 '<br />
gnuplot> set output "zcav_graph.png"<br />
gnuplot> set title "ZCAV"<br />
gnuplot> set xlabel "Block Offset (GiB)"<br />
gnuplot> set ylabel "MiB/sec"<br />
gnuplot> set yrange [0:20]<br />
gnuplot> plot "zcav-sdcard.out" using 1:2 title 'SD Card' with lines, \<br />
> "zcav-usbhd.out" using 1:2 title 'USB HD' with lines<br />
gnuplot> quit</code></div><br />
And the graph:<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhPy7tuof05LIZe1qIlNxwuNuHAoUD3LT6lxQvV9TTw2nLNBghs7iQKLGYjIDKK82s5N8RprK3Wh494eYxHMTzfmpoaExKSbfmz03VVwM1EqhwiFsCh6xwFRltlS7CTheVWRVQatjFG1Dw/s1600/zcav_graph.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhPy7tuof05LIZe1qIlNxwuNuHAoUD3LT6lxQvV9TTw2nLNBghs7iQKLGYjIDKK82s5N8RprK3Wh494eYxHMTzfmpoaExKSbfmz03VVwM1EqhwiFsCh6xwFRltlS7CTheVWRVQatjFG1Dw/s1600/zcav_graph.png" /></a></div><br />
The SD card seems to be reading at about 15 MiB/sec and the USB hard drive at about 10 MiB/sec. This is a little below the first bonnie++ run showing 17 Mib/sec and 12 MiB/sec respectively, but the SD card is still consistently faster than the USB hard drive at sequential reads.<br />
<br />
For comparison, I ran bonnie++ on a desktop system (Core 2 Quad @ 2.66 GHz, 6 GiB RAM, 320 GiB SATA hard drive) running Red Hat Enterprise Linux 6.1 and it had a nice 58 MiB/sec for sequential writes, 72 MiB/sec for sequential reads, and a 1066ms latency for random seeks. Here's the full set of numbers compared to the PandaBoard:<br />
<br />
<table align="center" border="3" cellpadding="2" cellspacing="1"><tbody>
<tr><td class="header" colspan="2"><b>Version 1.96</b></td><td class="header" colspan="6"><b>Sequential Output</b></td><td class="header" colspan="4"><b>Sequential Input</b></td><td class="header" colspan="2" rowspan="2"><b>Random<br />
Seeks</b></td></tr>
<tr><td></td><td>Size</td><td colspan="2">Per Char</td><td colspan="2">Block</td><td colspan="2">Rewrite</td><td colspan="2">Per Char</td><td colspan="2">Block</td></tr>
<tr><td colspan="2"></td><td class="ksec">K/sec</td><td class="ksec">% CPU</td><td class="ksec">K/sec</td><td class="ksec">% CPU</td><td class="ksec">K/sec</td><td class="ksec">% CPU</td><td class="ksec">K/sec</td><td class="ksec">% CPU</td><td class="ksec">K/sec</td><td class="ksec">% CPU</td><td class="ksec">/sec</td><td class="ksec">% CPU</td></tr>
<tr><td bgcolor="#FFFFFF" class="rowheader" rowspan="2">SD Card</td><td bgcolor="#FFFFFF" class="size">2G</td><td bgcolor="#FF0000">41</td><td bgcolor="#FB0400">93</td><td bgcolor="#FF0000">3125</td><td bgcolor="#E31C00">5</td><td bgcolor="#FF0000">3371</td><td bgcolor="#E21D00">4</td><td bgcolor="#FF0000">336</td><td bgcolor="#FF0000">99</td><td bgcolor="#E91600">17598</td><td bgcolor="#FF0000">15</td><td bgcolor="#FF0000">27.4</td><td bgcolor="#887700">1</td></tr>
<tr><td bgcolor="#FFFFFF" class="size" colspan="1">Latency</td><td bgcolor="#FF0000" colspan="2">1168ms</td><td bgcolor="#FF0000" colspan="2">33487ms</td><td bgcolor="#FF0000" colspan="2">32391ms</td><td bgcolor="#B24D00" colspan="2">44466us</td><td bgcolor="#FF0000" colspan="2">2628ms</td><td bgcolor="#00FF00" colspan="2">663ms</td></tr>
<tr><td bgcolor="#FFFFFF" class="rowheader" rowspan="2">USB HD</td><td bgcolor="#FFFFFF" class="size">2G</td><td bgcolor="#FF0000">43</td><td bgcolor="#FF0000">99</td><td bgcolor="#E51A00">9017</td><td bgcolor="#FF0000">16</td><td bgcolor="#F20D00">4538</td><td bgcolor="#FF0000">6</td><td bgcolor="#FC0300">369</td><td bgcolor="#E61900">99</td><td bgcolor="#FF0000">12357</td><td bgcolor="#D82700">9</td><td bgcolor="#8E7100">93.9</td><td bgcolor="#FF0000">6</td></tr>
<tr><td bgcolor="#FFFFFF" class="size" colspan="1">Latency</td><td bgcolor="#2DD200" colspan="2">215ms</td><td bgcolor="#17E800" colspan="2">5849ms</td><td bgcolor="#2CD300" colspan="2">5889ms</td><td bgcolor="#FF0000" colspan="2">52858us</td><td bgcolor="#00FF00" colspan="2">108ms</td><td bgcolor="#FF0000" colspan="2">7643ms</td></tr>
<tr><td bgcolor="#FFFFFF" class="rowheader" rowspan="2">Desktop SATA</td><td bgcolor="#FFFFFF" class="size">11G</td><td bgcolor="#00FF00">578</td><td bgcolor="#01FE00">97</td><td bgcolor="#00FF00">58851</td><td bgcolor="#00FF00">11</td><td bgcolor="#00FF00">25655</td><td bgcolor="#00FF00">4</td><td bgcolor="#00FF00">2636</td><td bgcolor="#00FF00">94</td><td bgcolor="#00FF00">72324</td><td bgcolor="#00FF00">4</td><td bgcolor="#00FF00">176.9</td><td bgcolor="#00FF00">1</td></tr>
<tr><td bgcolor="#FFFFFF" class="size" colspan="1">Latency</td><td bgcolor="#00FF00" colspan="2">13998us</td><td bgcolor="#00FF00" colspan="2">3126ms</td><td bgcolor="#00FF00" colspan="2">411ms</td><td bgcolor="#00FF00" colspan="2">25294us</td><td bgcolor="#4DB200" colspan="2">862ms</td><td bgcolor="#0FF000" colspan="2">1066ms</td></tr>
</tbody></table><br />
My conclusion: I will continue using the SD card to hold the root filesystem. I was hoping to get a performance boost out of a hard drive, but I think the USB bus is the bottleneck for the hard drive. Hopefully the PandaBoard 2.0 (or whatever it will be called) will have a SATA port on it!Jeff Bastianhttp://www.blogger.com/profile/18128075341421142000noreply@blogger.com3tag:blogger.com,1999:blog-3014099941823379560.post-77522153525490589502011-05-09T20:03:00.001-05:002011-05-10T10:17:15.628-05:00Ubuntu on the PandaBoardOnce I was in the mood for trying other operating systems, I thought I'd try <a href="https://wiki.ubuntu.com/ARM/OMAP">Ubuntu for ARM</a> and see how it compared to <a href="http://fedoraproject.org/wiki/Architectures/ARM">Fedora</a> and Android.<br />
<br />
I downloaded the "Texas Instruments OMAP4 preinstalled netbook image for OMAP4 boards" of Natty Narwhal (11.04) from <a href="http://cdimage.ubuntu.com/releases/11.04/release/">http://cdimage.ubuntu.com/releases/11.04/release/</a><br />
<br />
Installation was much simpler than Fedora or Android (/dev/mmcblk0 was my SD card); using sudo or running as root:<br />
<div id="jbcode"><code>gunzip -c ubuntu-11.04-preinstalled-netbook-armel+omap4.img.gz | dd bs=4M of=/dev/mmcblk0<br />
sync</code></div><br />
I moved the SD card over to the PandaBoard and turned on the power and that was it! Wow.<br />
<br />
It took a long time to boot due to the slow SD card (again, a future post), but eventually it was up and running and I was browsing the web with Firefox.<br />
<br />
X-Windows was just using the basic frame buffer driver so the graphics were not very fast, but it was certainly usable for basic web browsing. I'll have to try the accelerated drivers later.<br />
<br />
Some nice touches:<br />
<br />
<ol><li>The disk image included the two partitions necessary for the PandaBoard to boot.</li>
<li>The image actually included a kernel (the Fedora images require you to build your own kernel or download one from omappedia.org or pandaboard.org)</li>
<li>During the first boot, it resized the ext3 partition to fill up the SD card; the image had a 2.4 GiB partition for the root filesystem, but it expanded and filled up my 8 GiB SD card.</li>
<li>The NIC has a fixed MAC address without passing a kernel command line argument. I need to figure out how it did this.</li>
<li>If you need to make changes to the kernel boot arguments, there's a flash-kernel script that updates the boot.scr file for you. (This reminds of me of running lilo way back when to update the boot process on x86.)</li>
</ol>Jeff Bastianhttp://www.blogger.com/profile/18128075341421142000noreply@blogger.com2tag:blogger.com,1999:blog-3014099941823379560.post-55344907208254958652011-05-09T19:19:00.003-05:002011-05-09T19:22:34.907-05:00Android on the PandaBoardFor some weekend fun, I thought I'd check out Android on the PandaBoard (a.k.a. "Pandroid", heh) and see how Android compared to my webOS phone (a Palm Pre).<br />
<div><br />
</div><div>The "installation" of Android was roughly equivalent to the Fedora 13 experience:</div><div><ol><li>Create a small FAT partition and a larger ext3 partition on the SD card</li>
<li><a href="http://code.google.com/p/pandroid/downloads/list">Download Android</a> (I grabbed L27.10.2-P1_pandroid_rls.tar.bz2)</li>
<li>Copy the bootloader/* files to the boot partition (MLO, u-boot.bin, and uImage)</li>
<li>Copy the myfs/* files to the root filesystem partition</li>
<li>Unmount the SD card and move it to the PandaBoard</li>
</ol>Booting Android differed a bit from Fedora:<br />
<ol><li>Connect USB2Serial cable and fire up minicom</li>
<li>Attach the power and... it gives an error:<br />
<tt>booti: cannot find 'boot' partition<br />
Fastboot entered...</tt></li>
</ol>After searching the web for a while, I found a different set of boot arguments in the <a href="http://www.omappedia.org/wiki/PandaBoard_L27.10.2-P1_Release_Notes#Bootargs">L27.10.2-P1 release notes</a> to try (as opposed to <a href="http://omappedia.org/wiki/OMAP_Pandroid_Main#Bootargs">this set of arguments</a>):</div><div><div id="jbcode"><code>setenv bootargs 'console=ttyO2,115200n8 androidboot.console=ttyO2 mem=456M@0x80000000 mem=512M@0xA0000000 root=/dev/mmcblk0p2 rw rootdelay=2 init=/init vram="32M" omapfb.vram=0:16M,1:16M consoleblank=0' <br />
setenv bootcmd 'mmcinit 0;fatload mmc 0 0x80000000 uImage; bootm 0x80000000'<br />
boot</code></div><br />
Trying it again:<br />
<ol><li>Hit the power reset button, then hit a key in minicom to interrupt the autoboot sequence</li>
<li>At the 'PANDA #' prompt, enter (copy and paste, actually) the above setenv commands for bootargs and bootcmd and then boot</li>
</ol>It took a while to load (due to the slow SD card, more on this in a future post), but eventually Android popped up on my LCD monitor (connected with an HDMI-A to DVI-D cable). The touch screen normally used on phone is simulated with a USB mouse and a regular cursor (left button is a finger tap, middle button is the menu, and right button is back), however, the cursor for the mouse was really slow and jumped around to try to keep up with mouse movements.<br />
<ol></ol></div><div>A bit more reading and I learned that <a href="http://omappedia.org/wiki/OMAP_Pandroid_Main#Graphics_Accelerator_Drivers">the Android image does not include accelerated drivers</a> for the PandaBoard's PowerVR SGX540 chipset. Fortunately, drivers are just another <a href="https://gforge.ti.com/gf/project/omapgraphics/frs/">quick download</a> from Texas Instruments. I grabbed the drivers for L27.10.2-P1 image and copied them to the SD card (using my regular Linux laptop again), booted once more, and the graphics were nice and snappy!<br />
<br />
It seemed to have trouble bringing up the network (I think it <a href="http://omappedia.org/wiki/OMAP_Pandroid_Main#WLAN">needs more drivers</a>), so I couldn't actually do a whole lot except fire up the basic apps that came with Android, e.g., calculator, address book, nothing too exciting, but the core OS worked!</div>Jeff Bastianhttp://www.blogger.com/profile/18128075341421142000noreply@blogger.com11tag:blogger.com,1999:blog-3014099941823379560.post-14361442734226191572011-05-06T12:32:00.000-05:002011-05-06T12:32:57.546-05:00PandaBoard Networking with Fedora 13With Fedora 13 booting on the PandaBoard, the next step is to bring up the network so I can install more useful software with yum.<br />
<br />
The default configuration for the usb0 NIC is for DHCP:<br />
<br />
<div id="jbcode"><code>[root@fedora-arm ~]# cat /etc/sysconfig/network-scripts/ifcfg-usb0 <br />
DEVICE=usb0<br />
BOOTPROTO=dhcp<br />
ONBOOT=no</code></div><br />
But DHCP isn't working for me, it just hangs:<br />
<br />
<div id="jbcode"><code>[root@fedora-arm ~]# ifup usb0<br />
<br />
Determining IP information for usb0...Unknown HZ value! (94) Assume 100.</code></div><br />
I think the Unknown HZ value message is unrelated to the DHCP problem.<br />
<br />
I'm not sure what's going on with DHCP, so I will just try a static IP address for now. First, I need the MAC address of the interface:<br />
<br />
<div id="jbcode"><code>[root@fedora-arm ~]# ifconfig usb0<br />
usb0 Link encap:Ethernet HWaddr 4A:0B:B3:2A:3E:67<br />
...<br />
</code></div><br />
With the MAC address, I can create a config file for the NIC:<br />
<br />
<div id="jbcode"><code>[root@fedora-arm ~]# cat /etc/sysconfig/network-scripts/ifcfg-usb0<br />
DEVICE=usb0<br />
BOOTPROTO=static<br />
ONBOOT=yes<br />
HWADDR=4A:0B:B3:2A:3E:67<br />
TYPE=Ethernet<br />
IPADDR=192.168.1.111<br />
NETMASK=255.255.255.0<br />
GATEWAY=192.168.1.254</code></div><br />
Bring up the interface:<br />
<br />
<div id="jbcode"><code>[root@fedora-arm network-scripts]# ifup usb0<br />
[root@fedora-arm network-scripts]# ifconfig usb0<br />
usb0 Link encap:Ethernet HWaddr 8A:F4:D3:E9:EB:1A <br />
inet addr:192.168.1.111 Bcast:192.168.1.255 Mask:255.255.255.0<br />
UP BROADCAST RUNNING MULTICAST MTU:1492 Metric:1<br />
...</code></div><br />
And ping the router:<br />
<br />
<div id="jbcode"><code>[root@fedora-arm network-scripts]# ping 192.168.1.254<br />
PING 192.168.1.254 (192.168.1.254) 56(84) bytes of data.<br />
64 bytes from 192.168.1.254: icmp_seq=1 ttl=255 time=6.80 ms<br />
64 bytes from 192.168.1.254: icmp_seq=2 ttl=255 time=0.794 ms<br />
^C</code></div><br />
Networking is up and running!<br />
<br />
Finally, as a sanity check, I rebooted to make sure networking still comes up okay.<br />
<br />
Wait, what's this?<br />
<br />
<div id="jbcode"><code>[root@fedora-arm network-scripts]# reboot<br />
...<br />
Bringing up loopback interface: [ OK ]<br />
Bringing up interface usb0: Device usb0 has different MAC address than expected<br />
, ignoring.<br />
[FAILED]<br />
...</code></div><br />
The MAC address is different? How is that possible?<br />
<br />
<div id="jbcode"><code>Fedora release 13 (Goddard)<br />
Kernel 2.6.35-g6d019da-dirty on an armv7l (console)<br />
<br />
fedora-arm login: root<br />
Password: <br />
Last login: Sat Jan 1 00:00:17 on console<br />
[root@fedora-arm ~]# ifconfig usb0<br />
usb0 Link encap:Ethernet HWaddr CA:70:56:5B:23:7A <br />
BROADCAST MULTICAST MTU:1492 Metric:1<br />
...</code></div><br />
Wow, that HWaddr is nothing like the address on the previous boot!<br />
<br />
A quick Google search later and I learned the NIC on the PandaBoard does not have a MAC address stored in the EEPROM because it doesn't have an EEPROM! Thus, it generates a new random MAC address on every boot. Argh.<br />
<a href="http://lwn.net/Articles/435894/">http://lwn.net/Articles/435894/</a><br />
<a href="https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/673504">https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/673504</a><br />
<br />
The workaround for now is to pass in a MAC address of your choosing on the kernel command line, for example, <tt>smsc95xx.macaddr=01:02:03:04:05:06</tt><br />
<br />
So, I powered-down the the PandaBoard and moved the SD card over to my regular Linux workstation to create a new boot.scr file.<br />
<br />
First, I had to yum install uboot-tools to get the mkimage command. Next, I created a boot.cmd file on the first partition of the SD card:<br />
<br />
<div id="jbcode"><code>[root@localhost ~]# mount /dev/mmcblk0p2 /mnt/panda-rootfs<br />
[root@localhost ~]# mount /dev/mmcblk0p1 /mnt/panda-rootfs/boot<br />
[root@localhost ~]# cd /mnt/panda-rootfs/boot<br />
[root@localhost boot]# vi boot.cmd<br />
[root@localhost boot]# cat boot.cmd<br />
fatload mmc 0:1 0x80000000 uImage<br />
setenv bootargs 'ro elevator=noop vram=32M root=/dev/mmcblk0p2 fixrtc console=ttyO2,115200 mem=460M@0x80000000 mem=460M@0xA0000000 smsc95xx.macaddr=CA:BC:15:4D:B4:49'<br />
bootm 0x80000000</code></div><br />
And then I converted it into the boot script format with the mkimage command:<br />
<br />
<div id="jbcode"><code>[root@localhost boot]# mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n 'Pandaboard boot script' -d boot.cmd boot.scr</code></div><br />
Unmount the SD card and move it back to the Pandaboard and boot it.<br />
<br />
<div id="jbcode"><code>fedora-arm login: root<br />
Password: <br />
Last login: Fri May 6 11:03:29 from 192.168.1.76<br />
[root@fedora-arm ~]# ifconfig usb0<br />
usb0 Link encap:Ethernet HWaddr CA:BC:15:4D:B4:49 <br />
...</code></div><br />
The MAC address looks good! Let's update the ifcfg-usb0 and set the HWADDR line again.<br />
<br />
<div id="jbcode"><code>[root@fedora-arm ~]# vi /etc/sysconfig/network-scripts/ifcfg-usb0<br />
[root@fedora-arm ~]# grep HWADDR /etc/sysconfig/network-scripts/ifcfg-usb0<br />
HWADDR=CA:BC:15:4D:B4:49</code></div><br />
And one more reboot just-to-be-sure:<br />
<br />
<div id="jbcode"><code>...<br />
Bringing up loopback interface: [ OK ]<br />
Bringing up interface usb0: [ OK ]<br />
...<br />
Fedora release 13 (Goddard)<br />
Kernel 2.6.35-g6d019da-dirty on an armv7l (console)<br />
<br />
fedora-arm login: root<br />
Password: <br />
Last login: Fri May 6 11:55:45 on console<br />
[root@fedora-arm ~]# ifconfig usb0<br />
usb0 Link encap:Ethernet HWaddr CA:BC:15:4D:B4:49 <br />
inet addr:192.168.1.111 Bcast:192.168.1.255 Mask:255.255.255.0<br />
UP BROADCAST RUNNING MULTICAST MTU:1492 Metric:1<br />
...</code></div><br />
Yay! It works!<br />
<br />
<br />
One final note: in addition to the lack of EEPROM to store the MAC address, there also does not seem to be a system clock. Every time I boot, the system date is set to midnight, January 1, 2000. ntpdate and ntpd should help with that. I installed both and set the step-tickers (used by ntpdate) to:<br />
<br />
<div id="jbcode"><code>[root@fedora-arm ~]# cat /etc/ntp/step-tickers <br />
# List of servers used for initial synchronization.<br />
0.fedora.pool.ntp.org<br />
1.fedora.pool.ntp.org<br />
2.fedora.pool.ntp.org</code></div><br />
Then enable both ntpdate and ntpd with chkconfig:<br />
<br />
<div id="jbcode"><code>[root@fedora-arm ~]# chkconfig ntpdate on<br />
[root@fedora-arm ~]# chkconfig ntpd on</code></div><br />
And now the date should be correct after a reboot.<br />
<br />
<div id="jbcode"><code>[root@fedora-arm ~]# reboot<br />
<br />
Broadcast message from root@fedora-arm<br />
(/dev/console) at 12:17 ...<br />
...<br />
Starting sshd: [ OK ]<br />
ntpdate: Synchronizing with time server: [ OK ]<br />
Starting ntpd: [ OK ]<br />
<br />
Fedora release 13 (Goddard)<br />
Kernel 2.6.35-g6d019da-dirty on an armv7l (console)<br />
<br />
fedora-arm login: root<br />
Password: <br />
Last login: Fri May 6 12:00:31 on console<br />
[root@fedora-arm ~]# date<br />
Fri May 6 12:18:38 CDT 2011</code></div><br />
That looks better!Jeff Bastianhttp://www.blogger.com/profile/18128075341421142000noreply@blogger.com3tag:blogger.com,1999:blog-3014099941823379560.post-75658487397566957042011-04-21T17:04:00.002-05:002011-05-06T12:49:31.342-05:00My First PandaBoardMy PandaBoard is unboxed and ready to <strike>play</strike> work!<br />
<br />
There is no installer (anaconda) for Fedora on ARM systems yet, so installation means downloading an image of the root filesystem and a kernel. The root filesystem is generic for all ARM (v5 and newer) systems so it does not include a kernel.<br />
<br />
Download the root filesystem and kernel onto your host machine with an SD card reader.<br />
<br />
<div id="jbcode"><code>wget http://scotland.proximity.on.ca/fedora-arm/beta/f13/rootfs-f13-beta-2011-03-23.tar.bz2<br />
wget http://scotland.proximity.on.ca/arm/kernel/pandaboard/2.6.35.3/boot.zip<br />
wget http://scotland.proximity.on.ca/arm/kernel/pandaboard/2.6.35.3/boot_no_vid.tar.gz<br />
wget http://scotland.proximity.on.ca/arm/kernel/pandaboard/2.6.35.3/uImage_config</code></div><br />
Links from <a href="http://fedoraproject.org/wiki/Architectures/ARM/F13-ARM-Beta2">http://fedoraproject.org/wiki/Architectures/ARM/F13-ARM-Beta2</a><br />
<br />
Next, the filesystem and the kernel need to be copied to an SD(HC) card. The SD card should have a small FAT32 partition at the beginning to hold the kernel, and the rest of the card can be a regular Linux ext3 filesystem.<br />
<br />
After inserting the SD card in the reader, I can see from the dmesg logs the <br />
device name:<br />
<div id="jbcode"><code>$ dmesg<br />
...<br />
[ 277.436513] mmc0: new SDHC card at address 0007<br />
[ 277.536720] mmcblk0: mmc0:0007 SD08G 7.43 GiB <br />
[ 277.541804] mmcblk0: p1<br />
...</code></div><br />
This <a href="http://www.omappedia.org/wiki/SD_Configuration">script from omappedia.org</a> will do the trick; many thanks to the folks in #pandaboard on freenode IRC for helping me get the SD card formatted correctly!<br />
<br />
<div id="jbcode"><code>#!/bin/sh<br />
<br />
DRIVE=$1<br />
<br />
dd if=/dev/zero of=$DRIVE bs=1024 count=1024<br />
<br />
SIZE=`fdisk -l $DRIVE | grep Disk | awk '{print $5}'`<br />
<br />
echo DISK SIZE - $SIZE bytes<br />
<br />
CYLINDERS=`echo $SIZE/255/63/512 | bc`<br />
<br />
echo CYLINDERS - $CYLINDERS<br />
<br />
{<br />
echo ,9,0x0C,*<br />
echo ,,,-<br />
} | sfdisk -D -H 255 -S 63 -C $CYLINDERS $DRIVE<br />
<br />
mkfs.vfat -F 32 -n "boot" ${DRIVE}p1<br />
mke2fs -j -L "rootfs" ${DRIVE}p2</code></div><br />
NOTE: If your system shows the device as /dev/sda1 (or similar), then you will need to remove the 'p' from the last two lines, e.g.,<br />
mkfs.vfat -F 32 -n "boot" ${DRIVE}1<br />
<br />
Format the device using the above script and then take a look at it with parted:<br />
<div id="jbcode"><code>$ sudo ./sd-card-format.sh </code><code>/dev/mmcblk0</code><br />
<code> ...<br />
$ sudo parted /dev/mmcblk0 print<br />
Model: SD SD08G (sd/mmc)<br />
Disk /dev/mmcblk0: 7986MB<br />
Sector size (logical/physical): 512B/512B<br />
Partition Table: msdos<br />
<br />
Number Start End Size Type File system Flags<br />
1 32.3kB 74.0MB 74.0MB primary fat32 boot, lba<br />
2 74.0MB 7979MB 7904MB primary ext3</code></div><br />
That looks better!<br />
<br />
Okay, now I can extract the filesystem onto the SD card. Mount the second partition onto a /mnt/panda-rootfs directory.<br />
<div id="jbcode"><code>$ sudo mkdir /mnt/panda-rootfs<br />
$ sudo mount /dev/mmcblk0p2 /mnt/panda-rootfs<br />
$ cd /mnt/panda-rootfs && sudo tar xf ~/Download/arm-f13-beta2/rootfs-f13-beta-2011-03-23.tar.bz2<br />
</code></div><br />
Finally, the kernel can be extracted into the first partition:<br />
<div id="jbcode"><code>$ sudo mount /dev/mmcblk0p1 /mnt/panda-rootfs/boot<br />
$ cd /mnt/panda-rootfs && sudo unzip ~/Download/arm-f13-beta2/kernel/pandaboard/2.6.35.3/boot.zip<br />
Archive: ~/Download/arm-f13-beta2/kernel/pandaboard/2.6.35.3/boot.zip<br />
inflating: boot/boot.scr <br />
inflating: boot/MLO <br />
inflating: boot/u-boot.bin <br />
inflating: boot/uImage</code></div><br />
A quick check to see that both partitions have some used space:<br />
<div id="jbcode"><code>$ df -Th /mnt/panda-rootfs /mnt/panda-rootfs/boot<br />
Filesystem Type Size Used Avail Use% Mounted on<br />
/dev/mmcblk0p2<br />
ext3 7.3G 549M 6.4G 8% /mnt/panda-rootfs<br />
/dev/mmcblk0p1<br />
vfat 120M 2.8M 117M 3% /mnt/panda-rootfs/boot</code></div><br />
There's <a href="http://fedoraproject.org/wiki/Architectures/ARM/F13-ARM-Beta2#PandaBoard_Serial_Login">a known bug with launching a getty</a> on the PandaBoard. For now, edit the /etc/rc.d/rc.local file and uncomment the "horrible hack":<br />
<div id="jbcode"><code>$ sudo vim /mnt/panda-rootfs/etc/rc.d/rc.local<br />
# horrible hack to respawn serial console<br />
while true<br />
do<br />
/sbin/agetty -L 115200 console vt100<br />
done</code></div><br />
Finally, unmount and remove the SD card and transfer it to the PandaBoard.<br />
<div id="jbcode"><code>$ cd && sudo umount /mnt/panda-rootfs/boot && sudo umount /mnt/panda-rootfs && sudo sync</code></div><br />
The PandaBoard is set up to use a serial console, so attach a serial cable (or a USB-to-serial cable with a Prolific PL2303 chip) and fire up minicom. I'm using a USB-to-serial cable, so I ran 'minicom -s' to configure it for /dev/ttyUSB0. With minicom running, I finally attached the power cable to the PandaBoard and watched it boot.<br />
<br />
<div id="jbcode"><code>Texas Instruments X-Loader 1.4.4ss (Mar 1 2011 - 23:55:13)<br />
Reading boot sector<br />
Loading u-boot.bin from mmc<br />
<br />
<br />
U-Boot 2011.03-rc1 (Feb 09 2011 - 01:46:42)<br />
<br />
CPU : OMAP4430<br />
Board: OMAP4 Panda<br />
I2C: ready<br />
DRAM: 1 GiB<br />
MMC: OMAP SD/MMC: 0<br />
Using default environment<br />
<br />
In: serial<br />
Out: serial<br />
Err: serial<br />
Hit any key to stop autoboot: 0 <br />
reading boot.scr<br />
<br />
...<br />
...<br />
...<br />
<br />
Fedora release 13 (Goddard)<br />
Kernel 2.6.35-g6d019da-dirty on an armv7l (console)<br />
<br />
fedora-arm login: root<br />
Password: <br />
Last login: Sat Jan 1 00:41:17 on console<br />
[root@fedora-arm ~]# cat /proc/cpuinfo<br />
Processor : ARMv7 Processor rev 2 (v7l)<br />
processor : 0<br />
BogoMIPS : 1195.29<br />
<br />
processor : 1<br />
BogoMIPS : 1166.88<br />
<br />
Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3 <br />
CPU implementer : 0x41<br />
CPU architecture: 7<br />
CPU variant : 0x1<br />
CPU part : 0xc09<br />
CPU revision : 2<br />
<br />
Hardware : OMAP4430 Panda Board<br />
Revision : 0020<br />
Serial : 0000000000000000</code></div><br />
It works!<br />
<br />
Next up, networking...Jeff Bastianhttp://www.blogger.com/profile/18128075341421142000noreply@blogger.com0tag:blogger.com,1999:blog-3014099941823379560.post-52944382795282765472011-04-21T08:30:00.002-05:002011-05-06T12:50:17.289-05:00A Greener Home ServerI have an old Mac Mini G4 that I've been using as my always-on home server, but it draws a fair amount of power for a system that's idle most of the time (<a href="http://support.apple.com/kb/HT3468">32 watts</a>, up to 85 watts when busy) , so I decided to look into running an ARM system (they typically use less than 5 watts).<br />
<br />
After considering the <a href="http://www.globalscaletechnologies.com/p-22-sheevaplug-dev-kit-us.aspx">SheevaPlug</a>, the <a href="http://www.globalscaletechnologies.com/t-guruplugdetails.aspx">GuruPlug</a>, the <a href="http://beagleboard.org/">BeagleBoard</a>, the <a href="http://www.pandaboard.org/">PandaBoard</a>, and even the <a href="http://www.pogoplug.com/">pink PogoPlug</a>, I decided to order a PandaBoard since it has a dual-core OMAP4 at 1 GHz with 1 GiB of RAM. It was on backorder for a few days, but it finally arrived!<br />
<br />
Next step: get Fedora up and running on it with the help of<br />
<ul><li><a href="http://fedoraproject.org/wiki/Architectures/ARM">http://fedoraproject.org/wiki/Architectures/ARM</a></li>
<li><a href="http://paulfedora.wordpress.com/2011/03/25/fedora-13-arm-beta2/">http://paulfedora.wordpress.com/2011/03/25/fedora-13-arm-beta2/</a></li>
<li><a href="http://perfectlylogical.wordpress.com/2011/03/19/milestone-0-2-videoless-uimage-to-maximize-ram-on-pandaboard/">http://perfectlylogical.wordpress.com/2011/03/19/milestone-0-2-videoless-uimage-to-maximize-ram-on-pandaboard/</a></li>
</ul>Jeff Bastianhttp://www.blogger.com/profile/18128075341421142000noreply@blogger.com2tag:blogger.com,1999:blog-3014099941823379560.post-98884746787442932010-09-10T07:59:00.001-05:002011-04-21T08:23:59.293-05:00testing bloggerThis is a test.<br />
<br />
<div id="jbcode"><code>#!/bin/sh<br />
<br />
echo "Hello World"</code></div><br />
This test is concluded.Jeff Bastianhttp://www.blogger.com/profile/18128075341421142000noreply@blogger.com0