Silicon Valley Redneck

Confoozed

OK, so here I am with a requirement to add Ethernet support to AGROS in the next few months, in support of Project Egbert.

No problem, right?  I'd designed Ethernet into the Egbert hardware in anticipation of this; the LPC2387 has the MAC handily built in, so it's just a matter of adding a PHY with a suitably small footprint, plus a magjack.  Then, of course, I need to write a driver, and integrate some FOTS (Freeware Off-The-Shelf) TCP/IP stack if there isn't time to write my own.

Well... I wrote enough of the driver to start testing it for basic functionality, i.e., confirming that it receives packets.

And indeed it does, after a few tweaks.

Trouble is... it receives all the packets.  I played with the filtering options, if not eight ways from Sunday then at least half a dozen from Friday afternoon, and it persists in being in promiscuous mode, even when I resort to settings that should reject everything.

Thinking it might be a problem with the down-rev LPC2378 I was initially playing with, I switched to a board with a current-model LPC2387.  Same result.

Now, here's the thing: normally, you'd set up the filtering options to pass perfect address matches and broadcast packets.

But... those are exactly the packets you'd see if you were plugged into a switch, rather than a hub.  Most Ethernet installations these days are switched... but my lab has an old-fashioned hub, so anything plugged into it will see all the packets going to or from the lab PC and the little NAS that lives in the lab.

And so I come to wonder whether the filters on the LPC23xx Ethernet actually work at all, or if the subsystem has only been tested on switched networks.

If I were confident the end product would only be plugged into switched networks, I wouldn't worry about the interface being stuck in promiscuous mode, but it'll be getting installed in far-off places with unpredictable network characteristics.

Oh, well.  Maybe I'll bother NXP tech support this coming week and try to get an answer.  Or, I could try to corner somebody at the ARM Developer's Conference (or whatever it's called this year) next month.  If all else fails, I can do an address compare on all unicast packets in the device driver.

Coming up for air, briefly.

Arrr!  Here it be Talk Like a No-Good Commie Free-Software User Day, and I'm sitting in front of this, er, Linux workstation... using one core for one thing and another while paid-for closed-source software monopolizes the other core attempting to autoroute the Project Egbert PCB layout.

And, while I'm at it, I notice that I lost a little something a few weeks ago when I did a clean reinstall of Debian, going from a too-many-times-updated -unstable to the current -stable.  Namely, the stock kernel doesn't recognize the extra RAM I installed earlier this year.  Musta been built for 4G maximum, and I've got 6G, which can actually come in useful from time to time, especially the way I use this system.

Well, that would have been a handy excuse to switch to the 2.6.31 kernel, replacing the 2.6.26 that came with the distro, bringing in the latest round of features and updates, and since I'm building from source, which humongous memory support turned on.  And, if it hasn't broken the patches that finally came standard with 2.6.30, it should play nice with CH Products USB HID gadgets.

Trouble is, that means the Debian packaged Nvidia support stops working, so I need to build the driver, and the version I've got handy doesn't build for 2.6.31, besides which I really needs this computer chugging away on that layout.  So, the kernel upgrade waits for another day.

Oh, and the last -unstable before I reinstalled?  KDE4 is a crock.  I thought the version that came with Kubuntu "Jumpin' Jerboa" was maybe just misconfigured, but the Debian version is just about as bad.  Seriously, that thing needs to be taken out and shot.  The suck race between Microsoft and Apple has evidently drawn in the KDE team.

Meanwhile, what I'm supposed to be doing on the interactive side of things is working on, yes, open-source software.  AGROS needs a bunch of enhancements in support of Egbert, and this is the weekend to poke at the LPC23xx Ethernet interface to see how it works, write a driver for it, and decide how to integrate it with AGROS (and whether it integrates directly at this stage, or if I just hack in uIP (about which I also need to learn, and also I need to make sure the customer is OK with the 3-clause BSD license for that feature).

And, just for giggles, 'twould be nice if I could make a plain-vanilla web browser speak HTTP over a serial port, instead of using TCP.  Conceptually, it should work; after all, TCP just emulates a sequential comm link.  Um... wait.  What would happen if...

OK, Firefox thinks http:/dev/ttyS0 means http://www.developer.com/ttyS0, which makes no sense.  Over on the Windows box, IE takes http:/com4:, thinks about it, and gives one of its uninformative error messages... but that might just be a timeout, so perhaps it actually tried (I didn't have anything connected to com4 at the time).  Konqueror complains that I didn't specify a hostname, duh!

And, y'know, if you try doing a Google search for the sort of keywords that would relate to this, you get a lot of results for accessing a remote serial port via HTTP, and nothing (at least in the first few pages of results) about running HTTP over a local serial port.

(Yes, what I'm trying to do does make sense.  Not having Ethernet and a TCP/IP stack up yet, I could still, in principle, test a mini web server/app by just adding GET, POST, and HEAD commands to the monitor that normally runs on the serial port.  It's all text, right?  And, as long as I'm including a control/status web thingy, having the ability to use it via RS-232 could be useful on the non-Ethernet variants.  Or, I suppose, I could include PPP connectivity, but that gets back to needing a TCP/IP stack in place.)

Ah, well.  Enough rambling for now.  Time to get some work done.  Either that, or watch cartoons.  Or maybe take a nap.  (Going for a hike or doing yard work would be other good options, were the weather a fair bit cooler.)

Numbers holding steady

Being a couple of months overdue for a visit to the Kaiser vampires, I headed down to the lab yesterday.  Before breakfast.  Causing breakfast to be very late indeed, 'cause the lab doesn't open all that early.

Well, my hemoglobin A1C is still normal, though still near the top of the range.  Fasting glucose is up a couple of points, to 121, so I'm still battling that demon squid here.  Well, if I were really working at it, I'd have lost 20 pounds by now, and that fasting glucose would likely be a fair bit lower.

Ah, well.  All the other tests came out reasonably OK, and mostly closer to normal than last time.

Today, with no morning vampires on the agenda, it's back to normal, with a little hike between breakfast and work.  More exercise over the holiday weekend: some random little hike Saturday afternoon, and, if all goes as planned, playing in the river on Sunday!

FreeBSD. Ports. Ugh.

FreeBSD is a mighty fine OS for certain uses.

In particular, if you want to set up a server with a particular software configuration, and then leave it running for years on end, FreeBSD is great.

The trouble comes when you've had your system running for a while, and you need to install a new package, or update one that's already installed.

Dependency hell, here we come!

Upgrade a package, and maybe a library version gets bumped, and suddenly everything that needs, e.g., libjpeg.so.9 is unhappy because you now have libjpeg.so.10 installed, and the old apps are looking for the old version, specifically, by name.

And some other packages need updating, and things that they depend on, or that depend on them, then need updating in turn.

When it comes time to do an update, Debian is so much nicer.  Just run apt-get upgrade, and all the dependencies are Just Taken Care Of.

Well, I guess it's time to look at the ports/packages systems again, in more detail, to see what sort of automation may be available these days.

Ah, and the ports build for kdelibs just croaked, because it depends on a previously installed library, which depends on an older version of a library that I updated this afternoon.  And so it goes....

(And I don't even recall exactly what started this.  Oh, wait: yes, I do.  Joy needed the Ruby gem for Image Magick installed, in support of somebody else's code that she's trying to decipher.  That dragged in the latest Image Magick, which needed some libraries updated, which opened a huge can of worms, including a circular dependency between the SVG library and Cairo.)