HAL OS layout and headers (changes)

Showing changes from revision #4 to #5: Added | Removed | Changed

Hardware Abstraction Layer

» HAL/OS layout and headers

The OS is linked to run at a particular base address. Pre-HAL OS’s were linked to run at <n>MB, <n>MB (in logical space), that is on a MB alignment to allow efficientMMU section mapping. For In simplicity, theHAL /OS -based layout OS can versions allow this a is fixed still maximum true, size however for it will be theHAL , currently that set is at located 64k. on Then the megabyte boundary and not the kernel. The kernel (and the rest of the OS base modules) address will be <n>MB+64k. located This at allows an a offset defined by theHALHALSize of parameter up defined in the platform’s build environment file (note this setting must also match the kernel offset specified in the components file). During the build, the HALSize value is exposed to 64K assembler to components be via placed at the bottom of aROMOSROM_HALSize below constant, the assuming OS, you and have the aHALGET Hdr:HALSize.<HALSize> /OS combination statement to within still your be assembler section-mapped. sources. AROM should be portable to hardware variants merely by replacing the 64k HAL block.

A Note more that flexible for system section-mapping would to only be sacrifice possible, theMMU mapping efficiency. The HAL and must OS make could sure be the placed in any desired way, provided that each is contiguous in physical memory.HAL + OS are aligned correctly in physical space (i.e. combined HAL + OS starts on a megabyte boundary). Other offsets are supported (down to 4k page size), but will result in less efficient TLB usage.

OS image header

The OS starts with a header including a magic word – this aids probing and location of images. The OS header format is defined as:

Word 0: Magic word ("OSIm" - &6D49534F)
Word 1: Flags
            bit 0 => image supports compression
            bits 1-31 reserved
Word 2: Image size (bytes)
Word 3: Offset (bytes) from OS base to table of OS routine entry points
Word 4: Number of entries in table
If the 'supports compression' flag is set:
Word 5: Compressed image size (bytes)
Word 6: Offset (bytes) from OS base to decompression header
Word 7: Compression offset (bytes)

For details of how compressed ROMs operate, see the Compressed ROMs page.

HAL descriptor block

The HAL itself should have whatever header is required to start the system. For example on ARM7500 16→32 bit switch code is required, and on the 9500 parts a special ROM header and checksum must be present. A Unlike the OS image header, theHAL descriptor block, block instead of a header, can be placed somewhere at in any (word-aligned) location within theHAL. A pointer to this block is passed by the HAL to the OS in the RISCOS_Start call:

Word 0: Flags
            bit 0 => uncachable workspace (32K) required
            bits 1-31 reserved
Word 1: Offset (bytes) from descriptor to start of HAL (will be <= 0)
Word 2: HAL size (bytes)
Word 3: Offset (bytes) from descriptor to table of HAL routine entry points
Word 4: Number of entries in table
Word 5: Size of HAL static workspace required (bytes)

See also HAL workspace for details on how the OS uses the HAL header to allocate the HAL’s workspace.

Information source: Kernel.Docs.HAL.HAL_API in CVS

Unused source: Kernel.Docs.HAL.Entries in CVS