[opinion] Fedora needs an architect (part 2)

December 18th, 2010

So the other day, I wrote an opinion blog post entitled Fedora needs an architect. I’ve had some favorable comments on this idea, with a majority thinking this is a good idea that should be raised and discussed further. But I’m not going to raise it at least this side of the holidays because it’s such an obvious idea that others should have thought of it (which generally means it’ll be a bikeshed discussion), and because I don’t really want to deal with flamewar nonsense. Maybe in the new year I’ll bring this incredibly simple and obvious idea up in some meeting or other.


[opinion] Fedora needs an architect

December 15th, 2010

I read yet another thread about Fedora randomly changing the way UNIX has done things forever (the specific thread was on /dev/shm mount options) and it reminded me that I’ve been saying for a while that Fedora urgently needs an architect. FESCo should appoint a person as their technical representative who speaks for overall system architecture concerns. The person in this role should actively seek out compatibility or integration problems but should also be a “go to” person for concerns that arise in the interests of distribution cohesion. Sure, they should be accountable, etc. but the idea that everything should be filed in some ticket and wait a week for FESCo to debate it is both the reason these things don’t get filed (because you can’t file every tiny annoyance) and also the reason why we have these long mailing list threads in the interim.

Here are some of the things an actual architect could do:

  • Embody the overall engineering effort. Help determine overall distribution vision, help set direction, and make recommendations to the various stakeholders about what is required and what is not in order to meet the goals Fedora sets forth. This includes rationalizing the impact of certain possible technical decisions, and recommending against others.
  • Help handle initial discussion of a new feature, work out the integration planning, liase with stakeholders (figure out who they are and actively seek them out if necessary)
  • Monitor the distribution mailing lists for technical issues and be able to have a non-partisan recommendation in the case that there isn’t a mutually agreed upon answer. For really contentious stuff, others would handle it anyway so they can pass it on. But for stuff like system defaults, they can help resolve many problems that arise quickly.
  • etc.

I know that an architect isn’t going to happen, but this is my personal opinion nonetheless. I am certain that were there actually one person in that role we’d see a marked improvement in overall cohesion and distribution quality well within 2 releases.


[rant] Charging retirees more for benefits

December 14th, 2010

We have a little problem in the US. The “little” problem I am referring to here is that the federal government doesn’t appropriately provide a minimal social safety net for everyone (the actually fair form of capitalism in which everyone has a minimal standard and doesn’t have to worry about the basics). It’s made worse during a recession when otherwise reputable radio shows like APM’s Marketplace run a story implying that retiring employees have it too good and should be taken down a notch – somehow “appropriately” suffering because they’re done supplying work and neither corporations or government want to care about them any more. The problem is that for years they have done work, have contributed to society, and people who retire deserve a little more respect. Public workers in general deserve more respect (especially teachers), and to be seen less as whining complainers who get all these great benefits. Public workers in the US really don’t get good benefits compared with those in other rich nations anyway. It’s time to take a step back and ask yourself “what’s actually wrong with giving these folks a decent deal, and living up to the promises, anyway?” There are plenty of wastes of money in government without attacking benefits.


Car Computer Plans

December 13th, 2010

So I had a little accident the other evening in my Mazda MX5. This has motivated me to actually install some of the things I’ve been meaning to for a while now. I’ve decided that when it comes back, it’s going to be getting a second deep cycle battery added, and at least one BeagleBoard. Said board will be attached to cameras and other sensors, in addition to a 3G radio, so that I can track my car at all times, and watch live streaming video of whatever it is up to, including preserving video of any future accident. The basics are easy enough and I’m going to start with those so that it gets done. More fancy things like replacing the empeg and doing full radar tracking of other vehicles that come anywhere near my car can come sometime later. I’ll blog about it.


Using OpenOCD with BeagleBoard-xM

December 13th, 2010

NOTE: This is an extremely technical blog post intended only for very serious embedded Linux developers. It was written mostly for the benefit of Google. I wish that this posting had existed over the weekend when I was looking at this.

So I now have several Texas Instruments BeagleBoard-xM boards based upon the TI DM37x series Cortex-A8 based SoC. The “xM” is an improvement on the original BeagleBoard that features the improved DM3730 in place of the original OMAP3530. Like its predecessor, the DM37x series includes Texas Instruments’ on-chip “ICEpick” JTAG TAP controller that can be used to selectively expose various additional JTAG TAPs provided by other on-chip devices. This facilities selective exposure of these devices (which may not be present in the case of the “AM” version of the chip, or otherwise might be in a low-power or otherwise disabled state), because it is nice to be able to ignore devices we don’t want to play with today. The ICEpick itself can handle up to 16 devices, although the majority of those are “reserved” for the scarily more complex days of tomorrow. If you want some of the details, refer to chapter 27 of the DaVinci Digital Media Processor Technical Reference Manual (TRM) (under “User Guides”).

The full possible DM37x JTAG chain contains the following devices (in OpenOCD ordering, from TDO to TDI – the inverse of the physical ordering of the bus, which starts with the ICEpick at 0 and ends with the DAP at 3): DAP (Debug Access Port), Sequencer (ARM968), DSP, D2D, ICEpick. It’s the last device in the chain that we really care about because it is through the Debug Access Port that we will poke at the system memory address space and registers within the Cortex-A8 processor. At Power ON, the default JTAG chain configuration will depend upon the strapping of the EMU0 and EMU1 lines (which are exposed on the Flyswatter as jumpers adjacent to the JTAG ribbon cable). If both of these lines are high (pins 1-2 not 0-1 on the Rev-B Flyswatter, i.e. nearest to the ribbon cable) – which they had better be if you want an “out of the box experience” – then the only device to appear in the chain will be the ICEpick. OpenOCD is expecting this, because it contains special macro functions that will instruct the ICEpick through its control command registers to expose any additional TAPs after initialization (we actually only want the DAP in the default case, which is how OpenOCD will behave for you if you don’t change it). Each time a new TAP is exposed, the OpenOCD JTAG logic will do the necessary state transition for it to take effect (for the chain to lengthen or contract according to devices appearing and disappearing in the chain).

The default upstream version of OpenOCD does not work with BeagleBoard-xM at the moment (as of v0.4.0-651-gc6e0705 – last modification on December 8th) because some logic was recently added to master that attempts to handle busticated DAP ROM addresses on a Freescale (not Texas Instruments) IMX51 processor, which is very similar to the DM37x. Due to this “fixup”, the DM37x’s correctly provided ROM table information will be “fixed” to use the wrong DAP address, which won’t work. For the moment, find the following loop in src/target/arm_adi_v5.c:

        /* Some CPUs are messed up, so fixup if needed. */
        for (i = 0; i < sizeof(broken_cpus)/sizeof(struct broken_cpu); i++)
                if (broken_cpus[i].dbgbase == dbgbase &&
                        broken_cpus[i].apid == apid) {
                        LOG_WARNING("Found broken CPU (%s), trying to fixup "
                                "ROM Table location from 0x%08x to 0x%08x",
                                broken_cpus[i].model, dbgbase,
                        dbgbase = broken_cpus[i].correct_dbgbase;

Wrap it with a #if 0 (and don't forget to also comment or define away the definition of "i") such that it won't take effect. Then, if you have a Rev-B xM you will also need to edit the file tcl/target/amdm37x.cfg to add a new TAPID for the undocumented revision recently made to the ICEpick on these TI parts (this is backward compatible with the Rev-A because it will now look for both):

   switch $CHIPTYPE {
      dm37x {
         # Primary TAP: ICEpick-C (JTAG route controller) and boundary scan
         set _JRC_TAPID  0x0b89102f
         set _JRC_TAPID1 0x1b89102f
# Primary TAP: ICEpick - it is closest to TDI so last in the chain
jtag newtap $_CHIPNAME jrc -irlen 6 -ircapture 0x1 -irmask 0x3f \
   -expected-id $_JRC_TAPID -expected-id $_JRC_TAPID1

Then make and install the OpenOCD binaries (ensure you have the free FTDI libraries installed, and configure with “configure –enable-maintainer-mode –enable-ft2232_libftdi”). You can now use OpenOCD with the xM revA or B.


[rant] Desktop application complexity (part 2)

December 12th, 2010

There were some useful comments on my previous post, but I think they missed my point: there’s too much complexity here. It’s true that entirely self-contained applications are a relic of yesteryear and that having things work well together is useful, but it’s the mechanics that drive me nuts…some questions I have to ask every time I interact with desktop apps and related infrastructure these days:

  • Is it gconf, dconf, gsettings, kconfig, or some random other thing today? Is it worth figuring out before it’s something else?
  • Has it recently been entirely re-written to be the one true solution, obsoleting everything that went ten minutes before? And will it be re-invented ten minutes from now?
  • Is there a web page I can go to to get a non core GNOME/whatever developer summary of what’s going on? (no, there isn’t).
  • etc.

Heck, last time I tried building GNOME I followed the jhbuild instructions, only to be told that I was doing it wrong and should use something else now GNOME Shell is the flavor of the month. I have nothing against forward progress, but I have a lot against random new things popping up that suddenly replace stuff and aren’t well understood outside of a small group of core developers. The Linux kernel developers take great steps to ensure this is not the case and I would love to see the same happen elsewhere.

Hope that clarifies my frustrations. It’s not so much that gnome-settings-daemon can’t handle NFS mounts properly, it’s that it might not even be worth looking into it because I fear it’ll be replaced by something entirely new, “super awesome” (but not well understood or widely documented) solution in about ten minutes from now.


My car crash

December 11th, 2010

Photo: My poor little car.

So I had a car crash outside the office the other day. Nobody was hurt, but my car is going to be in the shop for a while. I was turning left into the parking lot, yielded on a green light, but didn’t see the other guy who was motoring on through the lights in a car with dealer plates on because he was obscured by a very large construction truck. He hit me at the passenger-side rear of the car, taking out the bumper, side panel, and at least hurting the alignment. I don’t consider the accident my fault, but I’m pretty sure the state of Massachusetts will, since I was making a left turn (this being number 15 on the list of findings of fault they prescribe). To add insult to injury, I was given a “failure to yield” warning (by an officer who turned up after the event) that I contend was not the case but cannot legally appeal because there is no penalty associated with this (unless I get a second ticket in the next twelve months).

Not having had a crash before (other than hitting a cow in a rental some years ago), and therefore not knowing any good body shops, I took the car to an insurer recommended facility in Cambridge (it was drivable, but I kept it to under 40 all the way home to avoid any of the panels becoming further damaged). This being the US, and therefore generally irrationally fearful of government or regulation in general, we have no good consumer standards agencies run by the federal or state government (BBB doesn’t count), so it’s really the Wild West when it comes to knowing if a body shop is any good. Private companies like Yelp try to solve a problem that should be solved at the national level and can only provide some data points to feed into a decision. The body shop seems ok, but their state filings show that they moved from Brighton to Cambridge earlier this year (why was that?) and that they’ve paid fines several years in a row for being late filing (but is that even unusual when it comes to this kind of place? does that mean anything other than that they fix cars but aren’t trained lawyers or accountants?). In the end, all I could go on was the advice of the insurer, my inclination that the damage wasn’t hugely structural, and the professionalism of the person that I spoke with on the phone and subsequently met in person when I dropped the car off. Anyway, I hope that works out ok.

In the wake of this accident, I’ve had several ideas for rather diabolical (but legal) means to avoid a repeat, and certainly to avoid being accused of failing to yield or acting other than in an exemplary fashion at all times. This will involve a large quantity of sensors, cameras, and computing power installed in the car when I get it back again.