ARM-Kernel Testing Module

Question

I have a two-core ARM embedded system device that is running a RTOS/kernel that I wrote. I wish to write an internal diagnostics tool/module to simulate I/O to the kernel for testing purposes. Obviously, this would not totally replace real world testing, with physical hardware interfaces and all. I'm guessing this would be close to hypervisor. What are the methods/concepts for doing this?

Answer 1

I have used L4's microkernel and hardware permissions are mapped as MMU pages; ARM options are 1k,4k,64k pages and 1M sections. Also, you can look at Linux's FB deferred I/O. The idea is to provide a memory mapped psuedo-register set. You can then use a page fault handler with fault address to determine which psuedo-register is being hit. You may have to look at the instructions. For instance, the code could use write-back and other updates. The Linux alignment handler code is probably very instructive.

See: ARM ARM - Chapter B3 Memory Management Unit.
        ARM ARM - 2.6.5 data abort (data access memory abort).

You also need to simulate interrupts. Using a timer (with whatever distribution you like) the driver/OS ISRs can be involked. In order to minimize timer use, timing wheels can be used to create different probability distribution functions of interrupt arrival. You may also wish to put this timer as a FIQ, if possible. This can allow your test device's ISR to received data updates even with regular IRQs masked. You could also emulate DMA with a FIQ handler on a constant timer interrupt. Of course this assumes that your test drivers do not use a FIQ and you have a FIQ timer available.

Many OS driver have registers-caches, especially if the device is a write-only chip. Taking a look at this code may also be helpful.

With L4, a particular cell is given permission for an actual physical device range. This is relocated in virtual space. The additional issue with a hypervisor is that you have multiple OS's running and you have to switch permission to wink-in/wink-out a the different hardware peripherals. I don't believe you have to do this.

Cavets: Multi-CPU locking may have issues with data fault handling; your drivers should not access hardware via multiple-CPUs. The handler can run with interrupts locked and on a single CPU, this solution will work. I believe that if an exception occurs, the strex will return with a condition code set. Possibly you could handle this in the fault handler.

I proposed the solution above because of the way you phrased the question and the arm tag.

---

As Pekka notes, if you choose to use C++, this maybe helpful in design for test. A useful pattern is a pure virtual interface in the driver that accesses the hardware. When you are testing, you replace this virtual interface with a simulation class; doing this in 'C' is also possible with function pointer bundles. These types of activities are well documented, so I ruled them out. However, you might consider clarifying the question and maybe re-tagging if this is the kind of solution you are looking for.