Ticket #303 (Invalid)Thu Aug 30 13:00:39 UTC 2012
Kernel flag HALFlag_NCNBWorkspace does nothing
| Reported by: | Sprow (202) | Severity: | Normal |
| Part: | RISC OS: General | Release: | |
| Milestone: | Status | Invalid |
Details by Sprow (202):
Spotted ages ago, but was awaiting bug tracker.
This was on BBxM (OMAP3 HAL) which requests NCNB workspace.
In the kernel this is defined to be at 0xFAFE8000.
Dumping that memory does not show the characteristic board name string that the OMAP3 HAL keeps, dumping workspace at R9 from OS_Hardware does. I concluded that HALFlag_NCNBWorkspace is being ignored.
Changelog:
Modified by Jeffrey Lee (213) Fri, August 31 2012 - 12:52:16 GMT
What are you expecting the flag to do? Setting the flag should give the HAL two sets of workspace: The regular cacheable workspace (at whatever size the HAL requests), and the NCNB workspace (currently fixed at 32KB size). In my experience the flag works exactly as advertised.
The OMAP HALs make use of it during the keyboard scanning phase, in order to give the HAL resident USB drivers some IO memory. So if you were expecting to store some data there and read it back after boot, you might find that it’s already been overwritten by the HAL.
Modified by Sprow (202) Mon, September 03 2012 - 22:10:33 GMT
I think I was expecting it to use one or the other, ie. if the HAL requests NCNB workspace then all its workspace would be there (and nowhere else).
You’re saying a HAL can have both? Then this is not a fault and can be dismissed.
Modified by Jeffrey Lee (213) Tue, September 04 2012 - 12:52:16 GMT
- Status changed from Open to Invalid
Yes, the HAL can have both. I’ll tweak the wiki docs to make it a bit clearer.
