A few imminent Kernel tweaks

I’ve just about finished my changes which will allow the OMAP HAL to use special static library versions of the USB drivers for keyboard scanning on boot. Although most of it’s fine, there are three changes that I’d like some feedback on:

Increased HAL size

64K wasn’t enough to hold the USB drivers, so I’ve had to increase the HAL size for the OMAP ROM. At the moment I’m specifying the HAL size manually in the components file, but this isn’t particularly great since it’ll break the !Mk scripts in the HAL and Kernel sources (Or at least it’ll break the Kernel scripts, since the same kernel might need to be used with multiple different HAL sizes). I can see two solutions to this problem – store the HAL size in the env file (similar to ImageSize, which AFAIK is just used to select the appropriate file from HdrSrc), or store the HAL size in HdrSrc (with the appropriate value determined automatically based around the current machine type). Thoughts?

Using SVC mode for handling initial interrupts

The basic interrupt handler that’s used during OS initialisation currently runs in IRQ mode, which prevents IRQ handlers from re-enabling interrupts. This doesn’t work well with the USB drivers, since they like to re-enable interrupts in their IRQ handlers, or during any callbacks. At the moment I’ve fixed this in the HAL by switching to SVC mode in HAL_KbdScanInterrupt. But I’m thinking it would be better if I moved that code over to the kernel. Any complaints?

Adding a new reason code to OS_Heap for aligned memory allocation

The USB drivers needed some heap management code, so I’ve made a stripped-down version of OS_Heap that can be used from the HAL. They also need code for allocating aligned areas of memory for use as I/O buffers (something which is handled by the PCI module under RISC OS). I was going to just copy the code from the PCI module, until I spotted that the PCI module just uses the cheap-and-nasty tactic of allocating (size+max(alignment,boundary)) bytes using OS_Heap, wasting considerable amounts of memory as the alignment/boundary sizes increase. For example, about half the memory the EHCI driver allocates would be wasted, which is quite significant considering I wanted everything to fit into the 32K of noncacheable memory which the kernel provides to the HAL.

So I’ve now added a new GetAreaAligned function to my modified OS_Heap code, which will allocate aligned blocks without wasting memory. I’m thinking it would be a good idea to add this as a new call to OS_Heap (presumably OS_Heap 7), and switch the PCI module over to use it. Any complaints? There are a couple of bits that I’d need to fix up (add boundary support, fix it to work with the re-entrancy code, add debug messages), but I can’t see any reason why it won’t work.

Increased HAL size Thoughts?

All I can say is that I’m sure we need an increased HAL size – and, as far as I can see, some extra HAL functions. I’m thinking specifically of enumeration and manipulation of GPIO lines. So whatever scheme you use should allow room for expansion.

Sorry, not much of a contribution – and one thing at once!

Adding a new reason code to OS_Heap for aligned memory allocation

That sounds good to me.

I’ve no idea about the other two. My gut instinct is I’d rather have stuff in Env files than HdrSrc because I don’t like messing about with HdrSrc more than absolutely necessary (primarily because it’s a larger and more complex component than Env).

Increased HAL size

In the end I decided to copy the way the ImageSize env variable works. I.e. the HALSize env variable is used to select from one of several files in HdrSrc, each of which defines a different OSROM_HALSize value. The only nasty bit is that in the components file we still need to manually specify the offset of the kernel within the ROM image.

Using SVC mode for handling initial interrupts

I’ve now made this change to the cortex branch of the kernel. At some point I’ll also have to check what stack sizes are being used, just to reduce the chance of the SVC stack overflowing.