Posted by Chris Ball
Thu, 19 Aug 2010 17:52:00 GMT
First, some background:
KDB (a kernel debugger shell) and
KMS (kernel mode-setting) combine to let you drop into a graphical shell when something debugger-worthy happens on your Linux machine. That thing might be a panic, or a breakpoint, or a hardware trap, or a manual entry into the kdb shell. Inside the shell you can, for example: get a backtrace, inspect
dmesg or
ps, look at memory contents, and kill tasks.
This is a big improvement over the previous model of "something bad happens to your laptop while it's in X, and the keyboard LEDs start blinking, and you hard-reboot and wonder what happened and wish your laptop had a serial port".
Here's a video of KDB+KMS in action — it's from Jason Wessel at Wind River, who deserves massive kudos for having enough patience to get all of this debugging code merged into mainline Linux to everyone's satisfaction:
Jesse recently wrote about how to give KDB+KMS a spin on Intel graphics chipsets, and now I've written patches that allow
radeon and
nouveau users to join in too. The method for testing them is similar to Jesse's:
git clone git://dev.laptop.org/users/cjb/linux-2.6
cd linux-2.6git checkout kgdb-next- Config the kernel as in Jesse's post, and build/install it.
- Boot with
kgdboc=kms,kbd kernel arguments.
- Enter KDB with sysrq-g, or
echo g > /proc/sysrq-trigger, and type go to leave KDB.
If you test with radeon or nouveau, please let me know what hardware you tested on, and whether everything worked. Thanks!
Tags kernel, linux | no comments
Posted by Chris Ball
Thu, 19 Nov 2009 18:40:00 GMT
I've written up a feature proposal on how we can use Btrfs snapshots to enable system rollbacks in Fedora 13, by gluing together the existing kernel code to do Btrfs snapshots, a UI for performing rollbacks, and a yum plugin to make snapshots automatically before each yum transaction. Lots of good comments so far, and LWN has written an article about it.
(Updated: The LWN link is no longer subscriber-only.)
Tags btrfs, fedora, linux | 11 comments
Posted by Chris Ball
Fri, 30 Nov 2007 20:27:00 GMT
Dear everyone who likes Unix,
I have a binary (which uses glib and was compiled from C) and I'd like to get output with the function name each time any function in that binary is called. So, I'd like the output of ltrace(1), but for function calls rather than dynamic library calls. I am bored of adding g_debug("%s", G_STRFUNC); to the top of all my functions.
You'd think this would be easy, given that incredibly similar tools have existed for twenty years, but so far the shortest answer I've heard starts "well, you could write a gcc profile function stub that..". It would be nice not have to recompile, since gdb certainly doesn't have to, but I'd welcome the way to achieve this with a recompile as well.
Any ideas? Thanks!
Update: jmbr wins, with the only solution that doesn't require anything more than gdb, and no recompile. Here's his script: http://superadditive.com/software/callgraph. I'd like to work on it to add support for modules loaded with dlopen().
Tags c, linux | 15 comments
Posted by Chris Ball
Mon, 24 Jul 2006 15:41:00 GMT
We have a Planet for the WSOP students now — Planet WSOP.
Thrilled to see that two of our students, Maria Soler and Cecilia Gonzales, were reported on in El Pais, one of the biggest newspapers in Spain. Does anyone feel like coming up with an English translation of the article?
I spent the last week at OLS. My first time there, and a lot of fun talks and parties. Xen and virtualisation really seem to be coming of age; impressive talks on:
- live migration of VMs
- the Linux support for live CPU/memory hotplug
- Rik van Riel's work on measuring what resources a VM is using (so you can use the hotplug support to change VM resources at runtime depending on what's actually being used)
Greg Kroah-Hartman's driver tutorial (photo) and keynote (slides) were excellent — three cheers for anyone who has the guts to stand up and say "Closed-source kernel drivers are illegal" in a room full of Linux vendors — and the systemtap talk and One Laptop Per Child BOF were other favourites of mine.
One of the WSOP students, Monia Ghobadi, also came to OLS to hack on her project (integrating GNU screen with gnome-terminal) with Behdad and I; was lovely to meet and work with her.
Tags gnome, linux | 7 comments | no trackbacks
Posted by Chris Ball
Thu, 11 May 2006 00:40:00 GMT
Kjartan Maraas pointed me at this Fedora bug yesterday — it points out that /proc/$pid/maps has been broken in Rawhide for a month. The patch that made linux/fs/proc/task_mmu.c (which is where map requests are handled) diverge from mainline is this one. I can't read more about its motivation since the Bugzilla ID is security blocked.
So, where to start? mm_for_maps() is a new function that does a bunch of checks on the relationship between task and current before deciding whether to allow the request; I threw some printk()s in to find out which were failing, and found that we take the !__ptrace_may_attach(task)) path to the out label in the code below:
if (task->mm != mm)
goto out;
if (task->mm != current->mm && !__ptrace_may_attach(task))
goto out;
From there, it got hazy. __ptrace_may_attach() returns whatever security_ptrace() does. This takes us into pluggable LSMs land — any LSM that gave a struct security_operations with a pointer to a ptrace function will have a shot at returning an error that would be sent back to security_ptrace() to stop our request from completing.
But how do I tell which LSM is complaining, or even which LSMs are loaded? After all, they're registered at runtime. Enter systemtap, as wisely suggested to me by Bill Nottingham (whom I now surely owe beer to). Systemtap is similar to the Solaris dtrace; it'll let you instrument and track kernel functions and system calls for a running kernel. It was installed on my Rawhide machine by default, which is always a nice touch.
So, how to see which ptrace functions were registered? Enter my first systemtap probe:
unity:cjb~ % cat list-ptrace.stp
probe kernel.function("*ptrace*") {
printf("%s\n", probefunc())
}
unity:cjb~ % sudo stap list-ptrace.stp
At this point, our stp script is converted into C code and compiled into a kernel module, before being loaded into the running kernel. After running a cat /proc/<pid>/maps in another terminal, we see:
__ptrace_may_attach
cap_ptrace
.. which suggests that cap_ptrace was called by __ptrace_may_attach, and that's where our __ptrace_may_attach might be being turned down. To be sure that we got to cap_ptrace via __ptrace_may_attach, we can ask for a backtrace:
unity:cjb~ % cat cap-backtrace.stp
probe kernel.function("cap_ptrace") {
printf("%s -> %s\n", probefunc(), print_backtrace())
}
unity:cjb~ % sudo stap cap-backtrace.stp
cap_ptrace ->
trace for 6345 (cat)
0xc04c2286 : cap_ptrace+0x7/0x49 []
0xc042a600 : __ptrace_may_attach+0xac/0xae []
0xc049350c : mm_for_maps+0x83/0xd8 []
0xc0492892 : m_start+0x28/0x11d []
0xc04800d9 : seq_read+0xdb/0x268 []
0xc0446288 : audit_syscall_entry+0x104/0x12b []
0xc047fffe : seq_read+0x0/0x268 []
0xc04648e2 : vfs_read+0x9f/0x13e []
0xc0464d2e : sys_read+0x3c/0x63 []
0xc0403d07 : syscall_call+0x7/0xb []
We're pretty sure that cap_ptrace was responsible. Hunting through its source, we see that it has a path to return -EPERM, which would do it. So, we recompile the kernel in order to have cap_ptrace tell us what return value it's going to use, right? Well, no. Straight back to systemtap:
unity:cjb~ % cat return-codes.stp
probe kernel.function("*ptrace*").return {
printf("%s -> ", probefunc())
log(returnstr(1));
}
The .return after the function pattern tells systemtap to trigger when the function is returning, and returnstr(1) asks for the return value as a decimal. There's also print_regs(), if you prefer to see what's in EAX directly. Over to the other terminal to cat a maps file again, and:
unity:cjb~ % sudo stap return-codes.stp
cap_ptrace -> 0
__ptrace_may_attach -> 0
That's odd. cap_ptrace is returning 0, which we can see in its code is meant to mean success, and __ptrace_may_attach is receiving it back unharmed. Cue an "ah-hah!" moment as we realise that the conditional:
if (task->mm != current->mm && !__ptrace_may_attach(task))
goto out;
.. has the wrong polarity; each of the functions that __ptrace_may_attach backs onto return zero for "success" (permission to attach), but the logic above is "if we're not trying to get the map of the current process, and __ptrace_may_attach isn't non-zero, we should fail". The exclamation mark needs to disappear.
And so we're done. My uses of systemtap weren't nearly as complex as those in the tutorial, but I'm happy that I saved myself the kernel compiles. I'd somehow managed to miss any hype around systemtap; if you're another systemtap user, please consider blogging your code!
Tags fedora, kernel, linux | 9 comments | no trackbacks
Posted by Chris Ball
Mon, 24 Apr 2006 18:36:00 GMT
I noticed that the AIGLX movies on the Fedora wiki showed a neat wobbly minimize animation, and decided to find out where the code was. It was disabled in metacity CVS — here's a patch
to enable this animation as the default, with the explosion animation still available if you start metacity with USE_EXPLOSION=1. Enjoy!
Tags fedora, linux | 4 comments | no trackbacks
Posted by Chris Ball
Mon, 24 Apr 2006 01:19:00 GMT
GIT is immensely impressive. Sadly, Dominik Brodowski is even more impressive, and has a fix for the bug I was having fun bisecting sitting in his PCMCIA tree; note to self to next time mail the relevant maintainer and ask if they know anything about the bug you're going to try and fix.
Here's the git bisect visualisation letting me know which merge was responsible, which is where I decided to check out brodo's tree. (Of course, I could also have continued the bisection down to the individual patch.)
Tags kernel, linux | 11 comments | no trackbacks
Posted by Chris Ball
Sat, 22 Apr 2006 03:23:00 GMT
Busy day. I'm pleased and impressed that 2/3 of the bugs I mentioned yesterday are fixed:
S3 sleep works again after applying this patch from Hugh Dickins. I don't get video or ethernet when I come back, but that's taken care of by unloading my ethernet driver beforehand, and by killing/restarting X on resume. I should see if using vbetool differently (restorestate, perhaps) helps with that.
A CVS commit to lvm claims to fix the problem I had, and the new package is in the buildqueue.
Nothing new on my pccardctl eject oops. I'm going to try and git bisect this over the weekend — it's a nice candidate for bisection, since it was working as recently as 2.6.16 and it's not clear whether this is a locking problem (the PCMCIA code moved from semaphores to mutexes, but the patch looks sensible) or a netdev problem.
Tags fedora, kernel, linux | 1 comment | no trackbacks
Posted by Chris Ball
Fri, 21 Apr 2006 04:10:00 GMT
Keeping track of details for a few bugs I'm seeing in current Rawhide on the new laptop:
- S3 sleep is broken, possibly libata-wide since Jeremy is hitting the same symptoms as me (no disk access on resume) and he's on AHCI while I'm on
sd_mod and ata_piix. The symptoms are syslogd complaining that it can't write out the journal, and lots of repeated:
sd 0:0:0:0: SCSI error: return code = 0x40000
end_request: I/O error, dev sda, sector 18800717
pccardctl eject is giving me an oops, which is new to Rawhide; looks like this is upstream, since it's the same oops as in this lkml post.
- The lvm(8) in my kernel-2141 initrd fails to boot, giving:
Volume group for uuid not found: (uuid)
0 logical volume(s) in volume group "group0" now active
mount: could not find filesystem /dev/root
I reverted bin/lvm in the initrd to the version found in 2136, which has the same version number but a different md5sum — that booted, so this looks like a new bug in lvm.
Tags fedora, linux | 5 comments | no trackbacks
Posted by Chris Ball
Thu, 20 Apr 2006 00:08:00 GMT
I've bought myself an Alienware m5500, which is a laptop based on the Uniwill 259EN3. I wanted a laptop with a high resolution screen (the m5500 does 1920x1200 on a 15" LCD) and Intel graphics. (I don't want to support either ATI or nVidia, and IBM and Dell make you choose an ATI/nVidia card if you go above their standard resolution screens). My machine has:
- Intel Pentium M 730 1.6GHz 2MB L2 Cache 533MHz FSB
- 512M RAM, 40G disk
- Alienware m5500 15.4" WideUXGA 1920x1200 LCD
- Intel GMA900 (915GM/i810) Extreme Graphics
- Intel PRO/Wireless 2200 b/g Wireless Card
I have Fedora Core 5 running on it now, but I'm sad to say that it wasn't without pain:
I booted from the FC5 install CD. The kernel booted, switched over to Anaconda, and I got a black screen and hung system. Tried again, this time using these instructions to start a VNC installer. That worked, and I soon found out that Fedora now has no NTFS support at all, which meant that the single NTFS partition taking up the entire disk would have to be deleted. (Which sounded fine at the time but is annoying me now — see the wifi section below.) Ubuntu's installer can do NTFS resizing, but Fedora thinks that the kernel NTFS support violates patents and is not legally redistributable.
After the install, I got the same X crash on my first boot. Booting into runlevel 3 got me to a shell. I determined that the X failure was this bug, which requires applying this patch to Xorg to get the card working. Now that Xorg is modular, it's (thankfully) sufficient to just download the latest xorg-x11-server.src.rpm, make the change, and rpmbuild -ba to have the specfile take care of building you a new RPM.
That got X working at 800x600; to get to 1920x1200 you need to use 915resolution and the following modeline:
ModeLine "1920x1200" 230 1920 1936 2096 2528 1200 1201 1204 1250
Now, on to wireless. I downloaded the ieee80211 stack, ipw2200 driver and ipw2000 firmware, and:
unity:cjb~ % sudo modprobe ipw2200
ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection
ipw2200: Radio Frequency Kill Switch is On:
Kill switch must be turned off for wireless networking to work.
ipw2200: Detected geography ZZM (11 802.11bg channels, 0 802.11a channels)
There is a wifi button on the case, next to the power switch — which implies that it's a hardware button, rather than a software button like the function keys on the keyboard — but pressing it turns on the "sleep" LED rather than the "wifi" LED, and ipw2200 continues to make the same complaint. I see that drivers exist to control the kill switch in software, but none I've seen work on this machine. I suspect that booting into Windows (which I can't do now since I wasn't able to keep/resize the partition) would get the wifi working in Linux either temporarily or permanently. I took a backup of the disk (dd if=/dev/sda of=nfs-mounted-backup) and booted the XP recovery CD that came with the machine, but it either hung or needed many minutes at "Setup is inspecting your computer's hardware configuration", and my patience for Windows is pretty limited. I'll try again if I don't get any other suggestions.
I posted some cries for help about this and dug out my very old, trusty Orinoco wireless PC Card and inserted it. And the machine hung immediately, and did so repeatably. I dug around until I found this linux-kernel thread which contains a safer /etc/pcmcia/config.opts, and that's working fine. Update: Hmph. It works anytime after init has loaded (udev, perhaps?), but the machine hangs at the cs: memory probe if I try to boot with the card already inserted. Any ideas?
I set about installing AIGLX, and the performance is good, especially for an Intel chipset. The photo at the bottom shows AIGLX and true transparency in gnome-terminal, which is lovely to have (at last), especially on a laptop when you're likely to want to be copying from a web page into a terminal, etc.
So, that's about it for day one. To summarise:
ACPI
Well, sleep (suspend-to-ram; S3) seemed to be working out of the box, but it isn't now. It looks like the IDE driver isn't coming back; if I can keep an ssh session connected, I see repeated in dmesg:
sd 0:0:0:0: SCSI error: return code = 0x40000
end_request: I/O error, dev sda, sector 18800717
I'll look into having the sd module removed and restarted — anyone know how I should do that on FC5/Rawhide? I also had to change resume_video() in /etc/pm/functions-intel to get video back:
#/usr/sbin/vbetool post
#/usr/sbin/vbetool vbestate restore < /var/run/vbestate
/usr/sbin/vbetool dpms on
Suspend to disk works, and doesn't even take that long, but kicks me back to the gdm prompt (!) from a logged in session. Update: Working now, after putting 915resolution in the resume path as well. Thanks, Jens!
The ACPI function keys don't do anything in software, not sure which driver they need.
CPU scaling
Working, switches between 750MHz/1.1GHz/1.6GHz automatically.
Graphics
Working after patching Xorg, acceleration works, AIGLX works.
Synaptics touchpad
Working, I disabled tap-to-click and vertical scrolling:
Option "VertScrollDelta" "0"
Option "HorizScrollDelta" "0"
Option "MaxTapMove" "0"
Option "MaxTapTime" "0"
USB, Sound (snd-intel-hda), SD card reader, DVD burning, Firewire.
Working.
VGA out
Works, after adding the following:
Option "MonitorLayout" "CRT,LFP"
Option "Clone" "true"
Option "SWCursor" "true"
I'll keep this post updated as I learn more about the machine. Here's the photo:
Tags laptop, linux | 31 comments | no trackbacks
Posted by Chris Ball
Fri, 31 Mar 2006 00:56:00 GMT
After writing my previous post about notifications (which is required reading for the rest of this one, I'm afraid), I was able to talk to Robert Love about the Yi Yang patch, and why he thinks it didn't get a good response. He gave a few reasons:
- It's lossy; you lose events from boot time, from before the userspace daemon starts, and if the daemon crashes.
- Requires root to listen on netlink, as opposed to the
inotify_add_watch(2) syscall interface of inotify.
- For this purpose
poll(2) is good, netlink is bad.
All of which are reasonable complaints. If that's the wrong solution, though, what would the right one look like? Thankfully, Robert has ideas on that too (and I hope I explain them correctly):
To avoid the causes of lossiness above, the log should be an on-disk log maintained by the filesystem. Having it done by each filesystem separately isn't necessarily awful for maintainability; the ext3 journalling layer is supposedly generic. There should be sequence points, so the (single) userspace daemon reading the log knows that it's up to date as of sequence n, and can tell the kernel to clean the parts of the log up to n.
The on-disk log would be fixed in size and circular — so still lossy so far — but Robert has an idea (which Tridge and Rusty Russell are apparently also partly responsible for) to make sure the lossiness doesn't hurt so bad. Here it is.
You do event "compression"; the log is stored in a tree of path names and events. If you have change events for a couple of hundred files in /home/foo/{bar,baz,etc}, you mark all of /home/foo as dirty and throw away the events inside it. Userspace has to go off and stat(2)-dance inside /home/foo to find which files have changed, but at least you've traded precision for accuracy and come out with a log that enables every change to be noticed. You'd keep reparenting as you run out of room in the log, so if you exhausted log space recording changes in /home/foo and /home/bar, all of /home gets marked dirty.
This is still root-only so far, but you can build security on it.
So! This is a lot more work than Yang's elegant netlink patch, but I've decided that ridding the world of updatedb is a worthy goal, and so I'll be starting work on Robert's design next week. I've booked days off work to go to LinuxWorld Boston, and an interested friend is visiting from the UK as well. A further idea is to get the userspace daemon to export inotify-compatible events, so that programs like Beagle can use this new mechanism without requiring a rewrite. I'm assured that apps like F-spot and Leaftag are waiting for this kind of event notification too.
(Note: Firefox hung as I was writing this post, taking the unfinished blog entry with it, with strace hanging on a futex. I blame the flash on the LinuxWorld site. But! Getting a core file with gdb's gcore and running strings on it gave me a perfectly-formatted blog post back. Yay!)
Tags kernel, linux | 16 comments | no trackbacks
Posted by Chris Ball
Mon, 27 Mar 2006 17:55:00 GMT
It took far too long to find this half-remembered linux-kernel thread on Google amidst all the results (mostly from distro installer guides) claiming that swap partitions are preferable to swap files. Here's hoping the link below will help future searchers.
Swap files and swap partitions have the same performance:
In 2.6 [swap files and swap partitions] have the same reliability and they will have the same performance unless the swapfile is badly fragmented.
-- Andrew Morton, on linux-kernel.
(There is a performance difference under Linux 2.4, though, as explained at the link above.)
Update: Tim comments that swsusp (the kernel software suspend-to-disk support) only works with swap partitions, so there is still one good reason to use a swap partition. Suspend2 doesn't have this limitation.
Tags kernel, linux | 11 comments | no trackbacks
Posted by Chris Ball
Sat, 25 Mar 2006 05:20:00 GMT
sweet rattle of disk:
a new locatedb comes;
I should go to sleep.
— me.
I've been thinking, over the last week or two, about the right way to handle an incremental updatedb — and in turn, the right way to handle generic filesystem notifications from the kernel. Fortunately, someone else has been thinking about it too and has actually been writing code, but we'll get to that in a moment.
These thoughts started off as a linux-kernel thread, with Jon Masters wondering if inotify can be used for this. Alas no, for what appear to be many reasons:
- inotify has no support for recursive watches; you'd have to put a watch on every directory on the system.
- Even this wouldn't work, because there's a hard limit on the number of watches on a system (8192 per "device", but inotify doesn't use a device interface anymore, it uses syscalls now) and this limit is an order of magnitude smaller than the number of directories on my
/.
- There's a race condition which would kill performance, meaning that you have to do a
stat(2) dance over each directory to make sure you see modifications — while you can guarantee that the kernel will deliver you each event for a directory you're interested in, you can't guarantee being able to register interest in a newly-created directory before something happens to files inside it, leaving you needing to scan inside the directory after registering the watch on it.
So that isn't going to work. As Jon points out, there are more uses for this than stopping your Linux box acting as a bedtime alarm clock every day; anti-virus people want it (and already use LSMs for the purpose), and smart indexing/backup tools could use it. OS X and Vista both have this kind of indexing service.
What's really needed is a lightweight layer that sends notifications of filesystem events to userspace via netlink, such that userspace can do what it wants with them. Luckily for us, that's exactly the patch that appeared on linux-kernel yesterday, courtesy of Yi Yang. This is a small and non-invasive patch (I think the relevant code-review phrase here is: "This is elegant, but correct.") that does just what we need and no more. It hasn't had a great reception so far, but I'd love to see it in mainline.
And now, I really should go to sleep. G'night!
Tags kernel, linux | 24 comments | no trackbacks
Posted by Chris Ball
Wed, 22 Mar 2006 01:51:00 GMT
Following on from my last productivity post, here's an area in which I'm not excited about the time-saving new features I'm using, but would love to be: gnome-terminal. I see that it just branched for 2.14, leaving us free to fantasize about new features for HEAD. Here's my top three:
Local search through scrollback:
screen(1) lets you search through scrollback. I do so a lot. But I wish it was better:
- There's no incremental search, and matches aren't highlighted as you type (as in an emacs
search-forward or vim hlsearch), which means that you don't know whether the next match is going to be on the line above or the page above until you hit return and look around to see where the cursor went.
- The latency is on the wrong end; when working over ssh tunnels, or on a low-bandwidth connection, it's painful to try and operate screen's search, leaving me making typos and confused and accidentally falling out of copy mode and ending up at the tail of the terminal again. You've been there, you know what I'm talking about.
- I don't run the majority of my shells inside screen, and there's no way to stick the contents of an terminal inside screen once you realise you need to search through it.
Personally, I think this is a pretty compelling argument for local, incremental search through scrollback. Anyone else?
Horizontally-stretchable views:
I work in terminals with a lot of text (e-mail) and a lot of program (make) output, and want to minimise paging up and down — if you do too, you probably try and resize your terminal such that it's still around 80 cols, but is the height of most of your screen. That's fine, but vertical screen space is expensive; you can only do that for a small number of terminals.
This got me thinking about extending the terminal horizontally, such that text scrolls off the right segment of a terminal and immediately onto the left segment, where each segment is 80x24 or whatever. For more details, see the feature request I filed in GNOME Bugzilla asking what the gnome-terminal maintainers think about this.
Display-independent terminals:
I don't care about this feature as much, but it's a logical step forward from the separation of model and view that the last feature requires. Your gnome-terminals could exist outside of the X server they were started from and be attached/detached from X servers at will, as you move around; this is already possible with some X applications. The use cases are keeping terminal state between work and home, or even more importantly for me: not having to worry about losing terminals when your X server restarts.
Does anyone think any of these have potential?
Also, hello to Planet GNOME! You might be interested in my previous posts on zsh/ssh/emacs
and Linux on the Treo 650. If anyone's willing to come up with a Hackergotchi for me, there's a photo here. Thanks!
Tags gnome, linux | 12 comments | no trackbacks
Posted by Chris Ball
Tue, 14 Mar 2006 04:28:00 GMT
I've just taken advantage of the massively impressive work performed by Shadowmite
and others and installed Linux on Mad's Treo 650. Here's a photo:
Plenty more on my Flickr page.
I used Luke's instructions, but couldn't get the supplied watch-and-upload script working; it wasn't seeing the Treo's responses, so I ended up (after verifying that the connection was okay with minicom) just pasting in:
cat ./codeupload.load > /dev/ttyUSB0
./sendimage ./zImage 0xa0800000 > /dev/ttyUSB0
./sendimage ./initrd.gz 0xa1500000 > /dev/ttyUSB0
./sendimage ./linuxupload.bin 0xa1d00000 > /dev/ttyUSB0
cat ./go.bin > /dev/ttyUSB0
.. and hitting space on the Treo to boot Linux.
Everything but the GSM radio is working now; it's hoped that that'll be on the way soon, as it presents itself as a simple AT command-set modem over a UART.
Tags linux, treo650 | 14 comments | no trackbacks
