Jeffrey Lee
authored
Detail: Three main changes: * On odd-numbered (i.e. development) versions of the module, the UtilityModule will now take its date from the VersionNum file instead of using a hard-coded date. * All build versions now look for the new "extended ROM footer" (as created by romlinker 0.04+) at the end of the ROM image and use it to determine the ROM build date for return by OS_ReadSysInfo 9,2. Failing to find the build date in the footer will cause OS_ReadSysInfo 9,2 to return 0. * On odd-numbered versions, OS_Byte 0 will now use the ROM build date (as found in the extended footer) to generate the error block that's returned to the user. This seems OK as the PRM describes OS_Byte 0 as returning the "creation date of the operation system". Plus it's a convenient way of getting the ROM build date into the Switcher, since the switcher uses OS_Byte 0. If the extended footer can't be found (or if the string hasn't been initialised yet, e.g. before Service_PostInit) the code falls back to a hard-coded string containing the date from the VersionNum file. File changes: Makefile - Updated to not create the obsolete Time+Date file (previously used for the ROM build date) Version - Use date from VersionNum file for development builds hdr/Options - New UseNewFX0Error variable/option to make it easy to check which OS_Byte 0 variant should be enabled hdr/KernelWS - Added new string buffers & extended ROM footer pointer to workspace s/Middle - Updated OS_ReadSysInfo 9 code, and added utility functions for searching the extended ROM footer for certain tags s/NewReset - Added a couple of calls to initialise the new string buffers just prior to Service_PostInit. This is required since OS_Byte/OS_ReadSysInfo shouldn't enable interrupts, but date conversion relies on the Territory module, which may enable interrupts. s/PMF/osbyte - Updated OS_Byte 0 code Admin: Tested in OMAP ROM, with and without the extended footer present. Version 5.35, 4.79.2.98.2.41. Tagged as 'Kernel-5_35-4_79_2_98_2_41'