Showing changes from revision #3 to #4:
Added | Removed | Changed
This page contains technical details relating to the implementation of the OMAP3 HAL, specifically which source file does what. The source can be viewed online here in the CVS viewer.
Also, a few notable header files:
Although boards such as the beagleboard provide well-defined methods for an OS to determine the board revision by probing the hardware, there is no such standard for determining board type/manufacturer. Thus the OMAP3 HAL provides one entry point per board type, allowing the OS to determine the board type merely by checking which entry point was used. This scheme works well for situations where a headerless ROM image is used (e.g. a ROM image produced by !Builder), and where it’s trivial to have the bootloader use the correct entry point (e.g. the standard u-boot scripts that use the ‘fatload’ and ‘go’ commands).
For situations where headerless ROMs are either not possible or not satisfactory (e.g. if the ROM has been written to a potentially volatile medium such as NAND, or if it’s impossible to reconfigure u-boot to not use a uImage), there is an additional entry point at offset &64 that assumes the ROM is being used as if it were a Linux kernel image. On entry to an ARM Linux kernel, the R2 register contains the machine type ID. the selectconfig_linux routine in Top.s utilises this fact to search the board config list for the correct configuration.
At present, the full list of entry points are as follows:
Offset | Description |
---|---|
&00 | BeagleBoard entry point |
&04 | DevKit8000 entry point |
&08 | IGEPv2 entry point |
&0C | Pandora entry point |
&10 | Touch Book entry point |
&64 | Entry point suitable for use with Linux kernel bootloaders |
1 At the moment there’s no defined way for the HAL to generate some data, call RISCOS_Start, and then access that data once RISC OS has initialised (i.e. when HAL_Init gets called). Which means that (unless I was to add that functionality) the easiest way of getting the HAL to remember what board config is in use is if it gets copied into the 64K of SRAM, which RISC OS currently has no knowledge of and thus doesn’t touch. HAL_Init actually copies the data back out of SRAM and into the HAL workspace pointed to by the sb register – this makes it slightly easier for the HAL to get at the data, since all the HAL entry points get called with sb pointing at the HAL workspace.
2 board.s is included directly mainly just to make sure it’s kept within range of ADR. It also makes it slightly easier to check that the ROM entry point table contains the right number of entries.
3 The OMAP HAL was based around a stripped down version of the Iyonix (aka Tungsten) HAL, which contains the ROM entry point & RAM initialisation code within the first 8K of ROM, along with code which performs a checksum of the ROM image. If the checksum fails it flashes the floppy light and allows a new ROM image to be uploaded & programmed via the serial port. The recovery code (and I assume the official flash programmer) avoids overwriting the first 8K of flash, so this code (in theory) makes an Iyonix unbrickable. So although it’s now clear that this recovery code is unlikely to be needed by the OMAP ROM, some remnants of its existence still remain.