(And of course uClibc 0.9.33 ships the day after I release Aboriginal 1.1.1. Yay, but now I have to go test it...)

SUSv4 continues to be full of subtle assumptions and missing pieces. For example, with xargs the -L option works on "non-empty" lines but doesn't specify whether a line containing whitespace is "empty", or only zero length lines are. (In this case it mentions trailing whitespace indicates continuation, so I guess a line with only whitespace has to be empty due to the continuation rule. I presume trailing whitespace on the last line is not an error.)

Finally got xargs checked in to toybox. It's only got the basic -ns0 options (yes, -0 is a basic options, had to be designed into the tokenizing), but at this point filling out the test suite is the hard part.

What bit me in the test suite? I wanted to use "ls -w" as part of one of the tests, which turns out to be a gnu/dammit extension, and thus doesn't hold weight. Like so much the Free Software Foundation does, ls -w turns out to be utterly useless because they didn't think it through.

When ls's output is a tty it detects the screen width and wraps lines, as required by SUSv4. The -w option is described in the man page as "assume screen width instead of current value", so I should be able to test ls -w against xargs -s and check that the wrapping decisions match, right?

Here's the stupid part: -w only works if you have a tty. If you don't have a tty, the -1 option (list one file per line) is implied. So if you go "ls -w 80 > filename" it does one entry per line just as it would if you hadn't specified -w in the first place. I.E. the most obvious use for -w is exactly where it DOESN'T WORK.

The FSF still sucks at engineering, because it's not what they do. The FSF is somewhere between a religious organization without an invisible friend to venerate, and a lobbying group that never buys appointments with politicians. The common element of those is fundraising, and the Linux Foundation's got them beat there. (Both organizations sponsor a bit of engineering development, and presumably budget it as a marketing expense.)

I've been collapsing /bin and /usr/bin together since forever, and now it's a thing, so I linked to one of my old off-topic busybox posts about it in the LWN discussion comments, from where it got scooped up by Lennart Pottering, and from there became the top "story" on y-combinator, where I do not have an account so can't comment on the the fascinating discussion of my offhanded historical blathering.

I usually have to go to great lengths to track down and mirror computer history stuff, always nice when it comes to me. Although if somebody's going to say I "got many other details wrong" it'd be nice to list them. Good to know that Sun specifically was to blame for /opt, I need to research Sun's "project Lulu" which is going to be hard given Robert Young's Lulu occluding the search term. I remember the bit in "Under the Radar" about it, and the Larry... (Wall? Page? the bitkeeper guy) treatise it links to. I should re-read them.

The backstory is that I started symlinking /bin /sbin and /lib to their /usr counterparts in the yellowbox days back at WebOffice (2001 or thereabouts) because it made read-only vs read-write tracking easier. (All the read-only root filesystem stuff was under /usr, all the writeable stuff was under /var, and everything else at the top level was a symlink or mount point for a non-block backed filesystem.) Keep in mind I'm the guy who wrote up the first initramfs documentation: the first clear /bin vs /usr/bin explanation I got was in the tutorial workbook from Atlanta Linux Showcase 1999 (which I've still got), but clearly initrd obsoleted that split even before initramfs existed. (Linux 0.0.1 had kernel/blk_drv/ramdisk.c already.)

But I also did it because computer history is a hobby of mine and I learned backstory of _why_ /usr/bin and sbin and lib happened: Their first hard drive was only half a megabyte, they added a bigger but slower 2.5 megabyte RK05 disk pack on /usr for the home directories, but the root disk was so small it leaked into /usr, and when they got a third disk (another RK05 disk pack I think, I need to track down the references) they mounted it on /home and gave /usr over to the system. Keeping commonly used binaries in /bin and /sbin was because the first disk was _faster_.

All of this was an implementation detail of their original PDP-11 system circa 1972. It made perfect sense for Ken and Dennis to do, it _never_ applied to Linux running on PC hardware in any way. When I got taught it at ALS in 1999 I went "huh", because I am weird. (This is also why I'm so slow learning new tools: I question assumptions down to the bedrock on a regular basis, and am not COMFORTABLE unless I understand WHY we're doing stuff. Sometimes it's good, sometimes it's incredibly inconvenient. Oh well.)

Mirell's now informed me that I need to actually _write_ the computer history book I've been meaning to do forever, rather than just blogging about it. I have boxes of unscanned magazines, books to read, so many links to collate... I need to dig up the old proposed topic index I wrote up over 10 years ago. (Great thing about computer history: your old todo lists don't go stale. It's still history, now even more so.)

Why Linux on the Desktop will never happen, part eight thousand, four hundred, and seventy two:.

Finally rebooted my netbook today (instead of just suspend/resume) because too many things had stopped working. The network fails in low memory situations with a panic in dmesg saying it can't allocate memory. (Why the network card is trying to _allocate_ memory for each packet instead of having some static buffers is one of those unanswerable questions.) This fix is "sudo insmod -r iwlagn && sleep 1 && sudo insmod iwlagn" repeated several times because for the first couple dmesg says a watchdog timer dies after 4 seconds of trying to bring the card up.

The sound died too, but that's something like 15 separate modules with a dependency hierarchy I've never managed to work out, so I can't just rmmod and insmod that. So I did without sound for a while... until the network rmmod/insmod trick stopped working last night. Now it was giving me the timeout message _twice_ on each cycle, something was horked, so... reboot.

On reboot, it prompts me to log in, and won't let me. I note that I selected "shutdown" from the menu rather than just holding the button down; I was _nice_ to the system, which was probably my mistake.

So I ctrl-alt-F1 over to a text console, log in there and dig up .xsession-errors, and it says:

/etc/gdm/Xsession: Beginning session setup...
Setting IM through im-switch for locale=en_US.
Start IM through /etc/X11/xinit/xinput.d/all_ALL linked to /etc/X11/xinit/xinput.d/default.
/usr/bin/startxfce4: X server already running on display :0
<stdin>:1:3: error: invalid preprocessing directive #Those
<stdin>:2:3: error: invalid preprocessing directive #or
<stdin>:3:3: error: invalid preprocessing directive #Xft
<stdin>:4:3: error: invalid preprocessing directive #Xft
xrdb:  "Xft.hinting" on line 13 overrides entry on line 6
xrdb:  "Xft.hintstyle" on line 14 overrides entry on line 7
xfce4-session: Unable to access file /home/landley/.ICEauthority: Permission denied
XIO:  fatal IO error 104 (Connection reset by peer) on X server ":0.0"
      after 38 requests (37 known processed) with 0 events remaining.

Obviously the solution is "sudo mv .ICEauthority .ICEauthority.bak", we can totally expect any random end-user to know how to do that. Just as they'd know about ctrl-alt-F1 (which the kernel developers keep threatening to remove).

I note that even I have no idea what .ICEauthority is _for_. It's bound to be more of that unnecessary selinux/dbus/hal style crap Linux has been growing. Lennart Pottering recently published part 12 of his "systemd for administrators" series on LWN. Anything that requires a 12 part series to explain should not be on my system.

If you wonder why I'm not particularly worried about Android obsoleting vanilla Linux: from a usability perspective they honestly can't make it much worse.

The Obama administration wasn't content to take away Habeas Corups but recently removed the fifth amendment as well, which combined with the "oh yeah torture was fine" stuff means this is no longer funny.

This is why leaving war crimes unprosecuted was a bad idea: he didn't cauterize the wound, and so the infection continues to spread...

Banging on the long-delayed Aboriginal Linux release again, which is in part blocked by the fact that mips' network connection went away, so the emulated mips system thinks it can use distcc but fails when it tries (and then overloads because it hasn't got enough memory for a fully local -j 3 build without the OOM killer going off).The problem actually isn't the kernel upgrade, the problem turns out to be the QEMU upgrade. It worked in qemu 0.15.1, and didn't work in 1.0, and git bisect tracked that down to commit 5632ae46: "mips_malta: move i8259 initialization after piix4 initialization".

Not quite sure how to deal with that: "use qemu 1.0 for x86 because the emulator command name changed, but use 0.15.1 for mips because there's a blocking bug". Hmmm...

Darn it, musl is lgpl, and thus pointless. I was looking at it as a potential bionic replacement to complement toybox as a toolbox replacement, but it won't. Android allows no GPL in userspace.

I'm excited by the opportunity for toybox to replace toolbox on a billion machines and become the de-facto standard when the smartphone repeats the mini->micro transition and becomes the new default computing platform.

But I mothballed Toybox was pointless back when it was just fighting for a fraction of BusyBox's market share, which was fighting for a fraction of glibc's market share, which was fighting for a fraction of Windows' market share.

Musl is fighting for a fraction of uClibc's market share, which is fighting for a fraction of glibc's market share, which is fighting for a fraction of Windows' market share. Good luck with that, I have other things to do with my time.

Toolbox and Bionic are both weak-ass stubs Google did just enough of to run Java, and no more. They are crying OUT for replacement, and since I was one of the big reasons for BusyBox's success (not the only one, but I turned an embedded-only toy into a general purpose program), I'm in an excellent position to do a Toolbox replacement.

But that replacement won't be GPL. The Free Software Foundation has poisoned the GPL (I commented about that on lwn.net recently), which is why GPL use is declining faster than ever. Android's "no GPL in userspace" policy explicitly includes LGPL.

And that isn't just a Google thing, it's everybody building systems around Android too. (This includes my day job: previous versions of their product included stuff like BusyBox, but that stopped last year and none of the new stuff we're working on is allowed to. They're pretty typical.)

Back when Eric Raymond and I wrote the 64 bit transition paper, we focused on the wrong transition, a mistake I acknowledged last year while explaining some of the things I'd gotten wrong in that paper. Yes, the switch from 32 to 64 bit PCs was our chance to break into the PC desktop, and we blew it. (If incremental change between transitions was possible either OS/2 or the first 30 years of Linux would have at _least_ clawed their way above 2% market share.) But the PC desktop is going away in favor of the smartphone desktop, which is scaling up via tablets and USB docking stations to displace the PC the way the PC displaced minicomputer terminals in the 70's and 80's. That transition is a race between iPhone and Android, with vanilla Linux and the Gnu/dammit stuff so far back you can't even see it.

Comparing the PC to phone transition to the earlier minicomputer to PC transition, the smartphone has just emerged from the Commodore 64 vs Amiga vs Atari 800 scramble. The macintosh and PC of this generation have now emerged. Google is the IBM of this era, somewhat locked down and surrounded by a cloud of followers that innovate a bit but not so far they lose compatability. If I can convince this generations equivalents of Compaq and HP and Gateway to all do the same thing, then Google might take it up the same way Linus Torvalds finally merged squashfs when it became ubiquitous. (Basically, because his reluctance to do so had ceased to matter to anybody but him: it was universally used anyway.)

Sigh. It wasn't the Musl developers' fault I got excited without checking the details. It's a bit painful to see an enormous missed opportunity right next to a corresponding waste of time effort and talent, like watching someone dying of thirst crawl right past an oasis. But as they say, "you can lead a horse to water"...

Didn't get an Aboriginal release out this weekend, instead I wrote up documentation on toybox's argument parsing logic and finally did a first pass at collating the zillion toybox todo snippets into the main todo file.

Tried to play with musl (which seems to be trying to replace uClibc the way toybox is trying to replace busybox), but the git repository has been down all evening. (The web page is up, but the git repo isn't?) Oh well, I tried.

Honestly, Github exists, mirroring git is _trivial_ and he didn't _bother_. The website isn't down, just the git repo; I take that to mean the project's author doesn't think the repository is worth anybody else's time to pay attention to (or he would have made it possible for us to do so). And thus the project goes back down my todo list to the "cat flossing" levels. Oh well.

Alas, appreaching 2 weeks into the new year and not having finished it... time to set the symlink anyway.

I also need to get an aboriginal linux release out. And update the toybox todo. Maybe this weekend.

Day jobs. They are time consuming.

The FSF deleted the last GPLv2 release of binutils (2.17) off their website, an replaced it with a binutils 2.17a. I downloaded that and diffed it against the real 2.17, and the first difference was:

--- binutils-2.17/cgen/cpu/fr30.cpu     1969-12-31 18:00:00.000000000 -0600
+++ binutils-2.17.new/cgen/cpu/fr30.cpu 2011-08-24 06:40:39.000000000 -0500
@@ -0,0 +1,1863 @@
+
+; -*- Scheme -*-
+; Copyright 2011 Free Software Foundation, Inc.
+;
+; Contributed by Red Hat Inc;
+;
+; This file is part of the GNU Binutils.
+;
+; This program is free software; you can redistribute it and/or modify
+; it under the terms of the GNU General Public License as published by
+; the Free Software Foundation; either version 3 of the License, or
+; (at your option) any later version.

The new file is GPLv3. Those bastards at the FSF deleted the last GPLv2 release of binutils off their website, replaced it with a GPLv3 version, and REDIRECTED THE OLD FILENAME TO POINT TO THE NEW FILE WHICH IS UNDER A DIFFERENT LICENSE.

Wow that's evil. (They keep using the word "freedom", but they seem to think it means we should do only what they want us to, be happy with what they give us without question, and act in obedience to their whims. I do not think it means what they think it means. We are apparently NOT free to consider GPLv3 a bad idea and want no part of it; they'll take away our old GPLv2 stuff and inflict the new license on us by stealth if necessary. GPLv3 hadn't been released when binutils 2.17 shipped, but apparently that's the license it's under now. At least if you get it from their website.)

Luckily Aboriginal Linux's sha1sum check caught it, and automatically fell back to my mirror location, which still has the real 2.17. I noticed all this while trying to figure out why that had happened.

Sigh. Me and my big mouth.

The tl;dr version: somebody was an asshole on IRC and I responded in kind for about 15 seconds before /ignoring them, randomly rolled a critical hit on the parting shot, and thus got kicked out of a position in Funtoo development I'd never asked for in the first place. Oh well.

So hanging out on the #funtoo channel, one of the devs suddenly started going off on a random unprovoked rant about how "If welfare worked, I'd lose weight when thin people exercise", and so on.

This pissed me off, since my sister and her four kids have been on food stamps and living in heavily subsidized housing ever since her husband left her for the wife of some military guy deployed to Iraq. I've sent her tens of thousands of dollars over the years, in the past year alone I bought each niecephew a netbook, and flew all five of them to florida to see their great grandparents with us over christmas. My father and grandfather have also each sent her five figure amounts, but I haven't got the money to actually _support_ her, and if she moves she'd lose custody of her kids.

Another friend was recently homeless (she moved to Austin for a job right as the recession hit and the job wasn't here anymore when she got here because the _company_ went away, then she was tied to an apartment lease in a strange city but couldn't find a new job during her three months of saved living expenses, had her car reposessed shortly before she was evicted from her apartment, had her purse stolen her first week on the street with all her photo ID in it, and spent about nine months camped in a park before I found her). She's currently unemployed again (I helped her put her life back together enough to get a minimum wage clerical job but it only lasted a couple months), and now she's trying to survive a bad infection of both kidneys without health insurance (this is apparently why she hasn't been sleeping well since before christmas; as with all poor people she only went to the doctor when the problem wouldn't go away on its' own for a long time, so it's pretty advanced by the time it's diagnosed). She's on 1500 miligrams of antibiotics a day, which I gave her most of the money to pay for (she borrowed the rest from a friend, another dancer she met dancing at a strip club; which was the only job she could get without photo ID and turns out to pay horribly when four different managers want to be "tipped out" to the tune of $50 each every night; she wound up _losing_ money half the time, especially since her skin's a bit sun-damaged from holding a sign on street corners, which might make maybe half minimum wage on a good day and literally nothing on a bad day).

The clinic she went to (the emergency room just tried to give her Vicodin and send her away) says she really _needs_ to be on intravenous antibiotics, but she can't afford them, and the next appointment to see if she can qualify for medicaid isn't until friday. Last I heard one of her kidneys had already shut down. I'm seriously worried she's going to die, of something entirely treatable, because she hasn't got health insurance.

This is not "some anecdote". Her name is Heather, her 26th birthday is a week from Friday. I was hoping to get her dental work for her birthday (living on the streets is really hard on the teeth, first place she went to said a dozen teeth can't be saved and need to come out), but after the other medical bills I can't afford it.

Another friend is dead broke and moved back in with her father because she can't find a job (her degree is in mortuary science, kinda specific), and can't really search for one from his suburban house without a car. (She previously lived with her mother in NYC, and thus never got a driver's license. She's terrified of having to move back in with her mother "because of the roaches".) Her father recently had his _second_ sudden massive abdominal surgery (the details are horrific, but he survived and is doing well enough to have the colostomy bag removed soon), so now she's taking care of him. He's been underemployed since the dot-com crash caused his business to fold, and back on the market in his 50's he hit the age discrimination our industry's full of, so he had to start social security early (hence is getting less of it), then he tried to take up the post-mortgage collapse "refinancing" plans that basically meant the bank told him to stop paying his mortgage until the process completed, and then tried to reposess his house when he complied. (Ongoing legal battle there is in something like its third year, involving every form of malfeasance on the part of the bank you can imagine, including up through the "robo-signers".)

Another friend is currently broke and unemployed after high school, due to a motorcycle accident that hospitalized her (her knee is still screwed up due to severed nerves) that prevented her from starting college on time, and thus cost her a scholarship. She moved from Arkansas to Louisiana recently (more or less couch surfing), and tried to check into a mental hospital (feeling suicidal) which wouldn't take her.

Another friend's been hospitalized a couple times for stress (related to his father winding up in jail basically for life) and a back injury (he's in his 20's but fell down the stairs in his apartment), but luckily he had health insurance. Except now he's unemployed and paying something like $1000/month for Cobra, which has eaten through his savings and is currently going on credit cards (along with his rent and other living expenses) while he job hunts. He's a fairly recent college graduate with only ~3 years experience on his resume, so even though he's probably smarter than me it's a lot harder for him to find a job without moving to a strange city where he has no friends.

This is not an exhaustive list. My ex-roommate Reese was homeless for a while, she got back on her feet after I let her "rent" a room from me for a year and only pay for one month of that. Back when I dabbled in real estate in the late 90's I rented a place to a guy named Tim who had been homeless for a while before I met him (dug himself out of it waiting tables, eventually saved up and bought a trailer in a trailer park). My brother tried his own dabbling in real estate and the mortage crisis happened while he was trying to fix up and sell four properties (one of which he was living in), they all wound up getting reposessed, and he lost his job, so he moved back in with his father for a while.

So when this guy on the Funtoo list started randomly mouthing off about how safety net programs didn't help _him_ and were thus worthless, I told him to "die in a fire" before slash-ignoring him. This was my mistake.

A couple hours Daniel Robbins informed me that the guy's father _did_ die in a fire (about five years ago), and the police suspect him of arson and raided his house last week, so it was the most hurtful possible thing I could have said to him (which I honestly didn't know), and I "couldn't represent the Funtoo project" anymore, which actually comes as something of a relief.

I never actually asked to be on the Funtoo core team, and warned him I probably wouldn't have time to do much with it, I was just working on a technology he found useful. I've wanted to get bootstrap-gentoo working for _years_ and still do, and it's not actually that _hard_ since he and I did about the first third of it in a single evening when he visited Austin last month. But the bits I don't know are in _gentoo_, and learning the guts of gentoo just isn't all that interesting to me, so it's been on my todo list for years and hasn't quite made it to the top yet.

The reason it not being on this core team anymore comes as a relief is I no longer feel _guilty_ about not spending enough time on it. Funtoo wanted me to maintain wiki pages and regression test their "metro" image builder tool (which is another highly integrated thing like catalyst that's almost useless for the bootstrapping I want to do: it's simply not compatible with anything other than itself). These are all interesting todo items, but I have no time! (Heck, I never did set up a standalone funtoo system, and deleted my funtoo chroot while I was in Florida because my fiddling around had glitched it and my netbook was out of space anyway. Now I don't have to feel guilty about not finding time to set it back up.)

That said, yeah I shouldn't have said that to whoever that guy was, wouldn't have if I'd known the context, and would happily apologize to him. Turnabout is fair play and all, but I also had the option to be _better_ than him, and probably should have taken it. To do otherwise makes Wil Wheaton sad.

(I think the real lesson I'm taking away from all this is I shouldn't let it get to be afternoon without having eaten anything all day if there's any chance I'll have to interact with people.)

Other bugs in aboriginal linux:

1) Powerpc threading segfaults immediately on application launch. (Non-threaded stuff seems to work fine.)

2) Sparc threading hangs, and the g++ "hello world" build fails with an uknown link type.

3) If the network card config fails the CPUS count is still set to 3, but without distcc the builds don't ge distributed, and boards with only 256 megs of ram can't do -j 3 builds locally without dying.

All of these were there in the 1.1.0 release (and in fact sparc dynamic linking didn't work at all) so they're not _regressions_ and thus don't hold up the release, but I should fix both next time around. (And the proper fix to #3 is really to fix the network cards.

Still debugging the 3.2 kernel. Apparently everybody's network drivers went bye-bye and need a vendor symbol now (not just the intel stuff), and one of my long term todo items has been to switch more board emulations over to gigabit ethernet (which has less overhead and thus works faster than 100baseT or 10baseT emulations).

Unfortunately, enabling the intel E1000 driver on armv5l panics the kernel at some point after it loads. (Sometimes. Other times, it boots up but the interface still doesn't work, I don't think the device probe actually finds one even when I tell qemu to provide one using the same arguments that work on i686. Possibly the qemu code for that is target-specific, even though it's a PCI device.)

I got an ssh account on Daniel Robbins' fire-breathing 16-way server with 48 gigs of ram (actually an openvz container), and managed to wget the 3.2 kernel over there yesterday. Today I can't download it to my laptop from kernel.org, so I copied the one from that server.

Yes, the 3.2 kernel is out and even today kernel.org is melting under the strain of serving it. I'm told the local mirrors (eu.kernel.org and such) aren't back up yet. I never got a release out with 3.1 (upgraded the repository to that right after cutting 1.1.0 in October), so I waited for 3.2 to come out and now I'm trying to get 3.2 out promptly to make staying in sync with kernel releases a bit easier.

One of the perl removal patches needed to be rediffed, but that was just to remove fuzz; otherwise still works just fine. The sparc relocation fix for 3.1 is already upstream, so yank that.

In 3.2, the network card config symbols have been deeply screwed up for some reason: now you need to specify which vendor the cards belong to. If you want the E1000 driver, you have to add CONFIG_ETHERNET and CONFIG_NET_VENDOR_INTEL, for no apparent reason. I don't know why they did this. Ask commit dee1ad47f2ee7.

I'm mucking about with the early boot code of a Texas Instruments board at work, which means I'm reading through the guts of U-boot.

Bootable kernels tend to make an ELF image, and then run it through "objcopy -O binary elffile binfile" to create a fully linked runnable binary blob of raw machine language, with a fixed load address and start address, that can actually run unmodified on the hardware.

In Linux, this ELF file is called "vmlinux", and in U-boot it's "u-boot", and both are still around after the build if you want to play with them. (QEMU can cheat slightly: it contains an ELF loader that does what objcopy does, and in the process it can determine what load address and start address to use from the ELF metadata. So "qemu -kernel vmlinux" (or u-boot) works on some targets. One of my todo items is to make it work on all of them, the fiddliness is how to feed in the kernel command line.)

The start address generally corresponds to the symbol "_start" in the ELF file (it's actually a field in the ELF header, but the location of _start is the default that field gets set to by the ELF tools), which is some assembly function that does the really low level setup necessary before it can jump to C code. You have to set the processor into the right mode, make sure problematic hardware we haven't configured yet is switched off (disable interrupts and Memory Management Unit), and set the stack pointer to a chunk of memory so C has local variables and so the first C function can call other functions and return from them.

The first thing the C code generally does set up the DRAM controller to start refreshing memory at the correct rate, so data written to DRAM actually stays there. Until the DRAM controller is set up (which is nontrivial, since the same hardware has to work with different brands/speeds/sizes of memory that get refreshed in different ways), all reads from DRAM return random garbage.

This raises a couple of interesting questions. The first is "How does u-boot run before the DRAM init happens?" By running out of something other than DRAM. Your board has to have some non-volatile memory such as ROM or Flash to provide a boot program when you switch it on, which has the disadvantage of being insanely slow compared to DRAM, but once the DRAM is initialized you can copy the rest of your code into DRAM and run from there.

The other question is: where do you get memory for the C stack? In the olden days, C's need for a stack led BIOS vendors to write the DRAM controller init routines in assembly language using no storage other than the CPU registers, which was horrible and is why BIOS development used to be black magic nobody understood. Then the "coreboot" project came up with the a trick of repurposing the processor's data cache via a static TLB entry, so a chunk of address ranges were stored in cache instead of DRAM, providing enough stack space to run a DRAM controller setup function in C. (And there was much rejoicing.) You only need to do it the old way on processors with no L1 or L2 cache (which are obsolete these days because the latency of DRAM fetch from chips a couple inches away does not mix well with modern clock speeds: just sending a signal down that much wire is several clock cycles' round trip, let alone having the DRAM circuitry actually look stuff up).

In general, having more assembly code than necessary raises maintenance problems: it's extremely awkward to write and debug assembly compared to C, and every processor has its own slightly different assembly language which few people know all that well. You generally want to Jump to C code as fast as possible, where the potential number of people who can review/maintain your code increases by an order of magnitude and you have many more tools at your disposal.

Alas, somebody needs to tell Texas Instruments this.

In this case, Texas Instruments went with an overcomplciated 3 layer approach, plus extra hardware. It includes a ROM in its system-on chip and builds U-boot twice. The ROM loads the first instance of U-boot (called "MLO" for some reason) from an SD card into 256k of dedicated on-chip memory (which is not the same as the L2 cache, and is thus mostly wasted after boot time). The ROM has to have a device driver to talk to the SD card through an MMC bus and parse the FAT filesystem to find and read the MLO file. The MLO instance of U-boot has to have its own MMC+SD+FAT driver to load a bigger U-boot into DRAM after it's initialized the DRAM refresh circuitry. And then that U-boot has to have a third instance of the same controller in order to load Linux from the SD card.

Yes, really.

In the u-boot board I'm working on right now, _start is defined in the file "arch/arm/cpu/arm_cortexa8/start.S", and it does _not_ do the minimal work necessary to jump to C. Instead, Texas Instruments wrote extensive setup code in assembly language.

The _start code begins with a branch to the label "reset:", jumping past some memory used to store variables. The reset routine sets the cpu to SVC32 mode, and then has a large blob to "copy vectors to mask ROM indirect addr" inside an #ifdef CONFIG_OMAP34XX that I really hope doesn't apply to the board I'm using. (I doubt Wolfgang Denk would allow such a horror upstream into his code, most likely it's only present in the vendor fork I'm using.)

Next it then optionally calls cpu_init_crit. This disables the processor cache and MMU (in case something left them on), and then calls lowlevel_init which is board-specific init (in this case in arch/arm/cpu/arm_cortexa8/ti81xx/lowlevel_init.S . What does "optionally" mean here? It's in an #ifndef CONFIG_SKIP_LOWLEVEL_INIT, but that doesn't seem to be set in our board's include/config.h or the files sourced from it.)

Lots of plumbing in lowlevel_init.S involves NOR flash, which our board config doesn't seem to have enabled either. The lowlevel_init: label is at line 383 in the source I'm looking at, and minus the NOR bits it does two things: 1) Set the stack pointer to the end of the first block of physical memory (SRAM0_START+SRAM0_SIZE-4). 2) Try to figure out if we're running from DRAM already or not.

Bootable kernels tend to make an ELF image, and then run it through "objcopy -O binary elffile binfile" to create a fully linked runnable binary blob.

The rest of this blog entry just explains that statement.

The ELF file format is a container format (like zip/tar/cpio or one the "ar" tool does for *.a static libraries). Executable files, shared libraries, and the *.o files created by compiling source code are all different kinds of ELF files.

Instead of a bunch of separate files, this format is optimized to contain chunks of program code. The archive's metadata describes what kind of code it contains (armv7 little endian 32 bit using the Thumb2 extensions...), and lists a bunch of named "symbols" describing the chunks of data in the archive. This includes "sections" of memory (with attributes like read-only or zero filled), plus the variables and functions that live in those sections. Each variable or function includes a size in bytes, the section name it lives in, the offset within that section it starts at, and so on. A bunch of tools can show this data, but "objdump -x" and "readelf -a" the big ones.

The Linux kernel contains an ELF loader that can parse ELF files and load them into memory, sometimes delegating to a dynamic linker (another program listed in the ELF headers as responsible for dealing with this program).

But running hardware needs raw machine language, so at boot time you need a full linked binary blob, a "load address" to copy it into memory at, and a "start address" to jump to. (Sometimes the start address is the same as the load address. Sometimes a jump to the real start address is inserted at the very start of the file.)

Bootable kernels tend to make an ELF image, and then run it through "objcopy -O binary elffile binfile" to create a fully linked runnable binary blob with a known load address and start address. In the case of Linux, the ELF file is called "vmlinux". In the case of u-boot, the elf file is called "u-boot". They're still around at the end of the build, and you can play with 'em if you like. (If you ever hook a debugger up to a JTAG interface to debug a running kernel, loading the ELF file into the debugger gives it all the symbol information to provide symbol and function names instead of raw memory addresses for everything.)

A "relocateable" program can be loaded and run from any memory location, but it has to either be REALLY carefully programmed (only using relative addresses that are a given distance forward or backward from the current location), or use some sort of wrapper has to run on it to adjust all its addresses with regards to where it's been loaded this time around. The relocation code has to be one big function using entirely local variables: it can't access any globals or call any other functions because those would have to be relocated, which is a chicken and egg problem.

Another common kind of wrapper decompresses the program, so the binary you actually load can be compressed and thus much smaller. Both kind of wrappers run first, and then jumps to the real starting location once they've doen their work on the runnable image. This is a form of relocation, but the wrapper is just copying the output to a known location so it doesn't actually have to patch all its jump and read/write instructions that use an address: those can still be fixed at build time.

This morning Sprint's horrible network got astonishingly bad. From my house, with three bars signal, I managed to load _one_ web page (no graphics) after half an hour of trying. Switching to airplane mode and back (force-reinitializing the radio) didn't help, so I rebooted, and when that didn't help I finally broke down and allowed my phone to do the "upgrade" it's been pestering me about since I got it.

This "upgrade" did exactly one thing: it disabled tethering in my phone. That's it. Tethering worked fine out of the box. Now the instant I switch on USB or Wireless tethering, the 3g icon goes away and the bars turn from green to gray. As soon as I switch it off, it comes back. 100% reliable. (I'm not saying the green 3g icon actually passes PACKETS, I'm just saying whether or not it's got a data connection associated with the tower.)

I called sprint's tech support, and they said:

• Their network has been having 3g outages since the 25th, still ongoing. This week of bad service is apparently not noteworthy.
• They want to charge me an extra $30 a month to restore my ability to connect my laptop to my phone, which WORKED FINE OUT OF THE BOX until they "upgraded" it away. It's fine for me to repeatedly download DVD images onto my phone and delete them (it's got something like 12 gigabytes of storage, I can queue up a 4 gig image each day entirely in the phone with about 30 seconds effort on my part), so clearly this isn't a _bandwidth_ issue. This is them being greedy.

They already charge me $100/month for the phone. T-mobile is advertising literally half that ($50/month) and their network is reasonably reliable, which sprint's isn't.

This means T-mobile is $70/month cheaper for better service, and breaking the contract with sprint (one month into it) would only cost $350, so I'd come out ahead after 5 months.

I'm sorry, Sprint, but given the above you DESERVE to go out of business.