HAL

The Hardware Abstraction Layer

The legacy HAL has a list of over 120 entry points, some with subreasons.

Here is my alternate proposal, as used by the C Kernel.

A HAL module will be initialised on each core. Only the first core to enter will have a zero private word to store the workspace in.

The first core should:

• Allocate workspace for all cores, if needed

• If provided, open the debug pipe for reading and start a task to empty it

• Register files with the ResourceFS on Service_ResourceFSStarting

• Start a regular timer interrupt

• Claim IrqV to return the number of the highest priority outstanding interrupt

It may:

• Set variables for the boot files to read (e.g. GPU$Core for Pi boards)

• Handle service calls

• Handle SWIs

• Claim vectors

After that, the kernel will

• initialise the modules stored in ROM

• Execute the file Resources:$.!Boot

The !Boot file (or !Boot.!Run, if !Boot is a directory) can identify the core it is running on by reading the CPU$Core variable, for the rare cases where that information is necessary.

HAL workspace

Workspace for the HAL can be allocated by the first core to enter the init routine. It will usually consist of a block of shared memory and an array with memory for each core, each of which will have a pointer back to the shared area, assuming it is necessary.

Debug Pipe

The kernel may open a special pipe per core for debug output. This will be passed to the HAL on init as a parameter. The HAL can send the output whereever it wants.