Notes on reverse engineering (changes)

Showing changes from revision #0 to #1: Added | Removed | Changed

You want to port RISC OS to a new platform? In an ideal world you’d have access to full the documentation about the platform, where every register lives and what it does. However the world is sadly not like that, and many OEMs assume that once they’ve ported Linux to their platform their job is done. So here are a few tips on how to work out information that would be in the technical manual if you had one. Be aware that a reverse engineered port is a good deal harder than one with full documentation.

1. Make sure RISC OS runs on the CPU core in your target. If it doesn’t, you don’t want to be fighting that battle as well as dealing with unknown hardware. Try finding another target, or an emulator, were you can at least get RISC OS running with minimal I/O.
2. Grab the Linux source for your platform, and make sure you can build it and boot it
3. Look at the Linux ‘dmesg’ boot logs for clues. For example, if it says:
   

   Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
   
   serial8250.0: ttyS0 at MMIO 0xfffb0000 (irq = 47) is a ST16654

   
   That tells you the address and type of the serial port. 16550 chips are already supported by RISC OS (as the FDC37C665GT chip in the Risc PC contains a 16550-compatible port), so you only need to repurpose this driver. If RISC OS doesn’t support your device, it tells you where in the Linux source to look for the driver. Be aware that different MMU settings can cause the IO registers to move around.
4. Use iotools under Linux to explore IO devices.

For example, Raspberry Pi dmesg says:

sdhci: Secure Digital Host Controller Interface driver

sdhci: Copyright© Pierre Ossman

mmc0: Unknown controller version (2). You may experience problems.

mmc0: SDHCI controller on BCM2708_Arasan [platform] using platform’s DMA

mmc0: BCM2708 SDHC host at 0×08300000 DMA 4 IRQ 20

If I do

iotools mmio_dump 0×08300000

I see a register dump that seems to tie up with the SD Host Controller specification . If I then compare this with the documentation for the BeagleBoard SD controller, I can start making guesses as to how Broadcom’s controller is similar and how it’s different.
(actually I get a completely different address on my board’s dmesg, but it’s the same idea)

The Dell Mini 9 laptop also has an SDHCI controller, but that’s a PCI device so dmesg doesn’t give its address. So I have to read the PCI configuration registers using iotools first to find out where in mmio space it lives before I can read it. The address can also be found using ‘lspci -vvv’. iotools mmio_dump of this address also shows a register dump that matches.

So now I can guess where the chip lives and what sort of hardware it is. I can then try to infer what’s going on from other published specifications, and check it with the Linux source.