Our product has the ability to boot from one of multiple possible boot media for a given BTMODE setting. Regardless of which medium is used, the kernel and rootfs will be identical, and we will need a way to determine which boot path was taken from within a user-mode Linux application.
It seem that the most appropriate way to do this would be to inspect the tracing vector registers described in Sections 4.3.2.4 and 4.12 of the TRM. However, attempting to access these registers via an mmap() of /dev/mem (or, equivalently, through the use of the devmem2 utility) results in a "Bus error" and some kernel output:
# devmem2 0x4031d040 w
/dev/mem opened.Unhandled fault: external abort on non-linefetch (0x1018) at 0x4026e040
Memory mapped at address 0x4026e000.
Bus error
From seeing similar behavior in other forum posts here, it seems as though this might be caused by an interface clock being disabled. Thus, I tried to enable the OCMC clock via the CM_ALWON_OCMC_0_CLKCTRL register to see if that would make a difference, but the register did not take on the new value:
# devmem2 0x481801b4 w 2
/dev/mem opened.
Memory mapped at address 0x400fd000.
Value at address 0x481801B4 (0x400fd1b4): 0x0
Written 0x2; readback 0x0
Again, a search of the forums pointed me to the possibility that certain registers might only be mutable when the CPU is in supervisor mode.
That all said, I have a few questions:
- Am I on the right path here, or is there a much different/easier approach that I should be taking to determine the boot source?
- How do I determine which clock(s) to enable in order to access the registers that I'm interested in?
- How can I successfully achieve the register write that I'm attempting (the second devmem2 example, above) from a user-space application?
