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 IRQ s 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.

Answer 2

You could apply the following approaches in order of increasing fidelity (and effort):

• If you have a software API to the planned hardware, then a stub that responds with simulated results would provide a first-order solution.
• If the hardware is memory mapped, create a simulation process/thread that updates the memory as though it were the external hardware.
• Then, if more fidelity is required, the approach by artless noise using page faults for memory mapped devices could be introduced to make the simulator transparent to the actual API, and introduce synchronous event updates.
• Finally, it may be less effort to build hardware (possibly with more software) that provides the same interface to the application to give hardware-in-the-loop simulation from outside the system. This would give you the exact hardware interface, but just move the complexity to the test scaffolding.

Answer 3

If your RTOS have a hardware abstraction layer (HAL) between kernel and hardware. It could be a good point for simulating I/Os.

If you don't have any kind of HAL layer, then this could be one reason to implement it. There are also lot of other good reasons for HAL (see here ). Google with " hardware abstraction " to get more information.

There are also some ARM emulators (ARMware and similars) for simulating ARM devices.

Answer 4

The test you wish to do is similar to send a virtual IO request to your kernel. I think the concept is similar to software based, para-virtualization.

Software based Hypervisor is your test program; sending virtual IO to your kernel and your kernel contains a virtual IO driver to accept these IO requests.

After processing, the virtual IO driver must also be able to make a hypercall to your hypervisor to alert the state of virtual IO signal.

Answer 5

No information on your RTOS/kernel.... but i suppose your RTOS/kernel should have something like ioctl . why dont you use it?