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.