Home
Well, that was an interesting little voyage through the innards of a complex piece of hardware. As I said back on the 28th of July (eek, a while ago), I can't seem to find the memory location of the Ethernet chip on my development kit (the Decomsys/Elektrobit Node
The Elektrobit help department were ... well, unhelpful, but it's not necessarily their fault: this is an old bit of kit, on the verge of going out of support, so I don't expect too much. Still, they gave me an idea of how to proceed, and I started to wield u-boot's 'md' with abandon. u-boot being the bootloader the dev-kit uses to start up, and md being the 'memory dump' command, allowing me to print the contents of a given memory address to screen, I went on a little sojourn through the machine's IO 'memory' (memory-mapped I/O system, which makes the next bit easier than it would otherwise be). Having written out approximately what I expected to find (a set of 16 contiguous 16-bit registers in memory, with the default startup values from the datasheet, I spiralled out from the area where they should be, looking high and low (higher and lower in memory, in any case). And there they abruptly were, offset from the location in the documentation by 0x300. 0x300 is a rather odd offset, but I assume all the locations were shifted up to accomodate an interrupt table or a new or expanded peripheral or something at some point... Why the documentation wasn't updated is another question entirely. Still. Using the correct base address of 0x42000300 instead of 0x42000000 as in the data sheet, the Ethernet chip kicks straight into life, and the code that wasn't working at all with the old base address suddenly wakes up and starts sending frames. Granted they're a bit malformed, but it's nice to see I got all the memory management and device initialisation stanzas correct despite not getting any kind of useful response from the hardware.
Having the u-boot source code to work from probably has something to do with that. Open-source makes my life easier, again.
...and I think someone just scored a point from me.
If you remember, I was having some interesting trouble with the Ethernet chip on my development board earlier this week. It turns out that the chip is, in fact, exactly where I think it is in the memory map. When the support email came back, the response was basically "Heh, so it does. I wonder why that is?" So, no simple solutions for me, then... I'm really starting to hate this part of the project, as there seems to be so much fumbling around in the dark, and so little progress, at the moment.
Also, Michael Jackson is dead (to add to the hysteria, except not). I remember his was the first album I ever owned, on cassette, back in the days before CDs. From what we've seen of him in the last few years, though, I think he died a while before he was dead: there didn't seem to be much left of the MJ of the eighties and nineties. More of the names and faces of my childhood going away. I guess this is what growing old feels like.
The BBC has a mildly interesting article today about something that's kind of street art, but kind of more than that. Ghost Bikes are bicycles, painted white and with almost all moving parts removed, that are chained to an object in the street near a place where a cyclist was recently killed. They tend to appear overnight, like all self-respecting spooks. Given the vulnerability of cyclists on Britain's roads, and the number that are killed each year, I think I approve.
In other news, it seems the reason why the Ethernet chip was not playing ball yesterday, is that it isn't where I think it is. I have a copy of the device memory map in front of me. I am making all of my calls through the area in that map to which the device is assigned. The returns make no sense - even a static call that should always return the chip's ID signature (0x33) is instead just full of 0xff. I do not understand. This is extremely annoying.
Frustrating few days here, unfortunately. I've been busily trying to get an SMC91111 Ethernet chip to emit a frame on to the network when I poke it, which is to all accounts much harder than it should be. At the moment, the Memory Management Unit and I are not on good terms.
Lemme asplain. If I want to send a frame, I have to ask the chip to allocate enough memory to hold it, transfer the data into the allocated memory, then set the transmit flag for that frame. The chip takes care of the rest. However, at the moment, conversations between the two of us look more like this (with apologies to Aquarion)
Me: OK, time to go. Initialise, please. Chip: Alright, hang on... ok, done. Gimme sommat to do. Me: Allocate a page of memory, please. Big enough to hold this frame. Chip: Uh... right. Done. Me: Can I have a pointer to that page, please? Chip: Here you go. It's a nice pointer. Got nice angles and a pretty paint-job. Me: ...right. Anyway, please put this frame in the page pointed to by the aforementioned lovely pointer. Chip: HAHAHAHAHAHAHAHAHA no. Me: But... you gave me that perfectly happily a minute ago. Chip: Dunno what you're talking about, guv'nor. Nothing there. Doesn't exist.
Repeat until bored. I've yet to figure out what's causing it: in the words of Thomas Edison, I've found more ways that don't work. I just wish I could pop non-solutions off the stack more quickly.