Hi Leo,
Hi Al, Jeremy,
On Fri, Jul 19, 2019 at 09:16:35AM +0000, Al Grant wrote:
Hi,
CSAL can be tricky to use as a discovery tool. I’ve now added a Python tool which might be easier to use, especially if you have to work around bus hangs etc. Please see csscan.py here:
https://github.com/ARM-software/CSAL/tree/master/coresight-tools
You can do a scan using
python csscan.py <rom-base-address>
As well as listing configuration details for the devices, it can also discover ATB topology (not CTI yet, sorry) and report on what state the devices are currently in.
There’s some explanation on the discovery process:
https://github.com/ARM-software/CSAL/blob/master/coresight-tools/disco very.md
Today I found time to try CSAL tool with script csscan.py on Hikey960, just list some finding at my side.
Firstly, I run the script csscan.py with below command:
python csscan.py -vvv 0xEC000000
The result is very unstable and easily to cause the external abort. I can confirm that this is not caused by clock; and the external abort is random happening when access different registers. Usually, this is caused by some specific timing requirement or even memory barrier issue; This is why I worked out the enclosed patches, which sleep for 1s for every registers accessing (both for reading and writing); This can improve much and avoid the abort issue.
Thanks for the patch! I'll add a command-line option to wait for a configurable time. Glad to hear this helps. When we're just reading the ROM table and device registers, we shouldn't need barriers, so if we are having to introduce sleeps, it might point to a hardware issue.
I also force 'check=True' for write operations so want to add a read-after-write barrier but actually this is not very useful.
Yes, the readback check happens automatically with -v. I'll add an option to do that independent of -v.
There are some registers which we don't expect to read back the same value, either because they are totally "write-only" or have a write-only field. These generally have explicit check=False. But it might still be possible to read some other register to check the effect has happened, e.g. after writing a 1 to a CLR register we might be able to check some other register now shows 0.
@Al, not sure if the patch can provide any useful code which can be picked or not?
Yes, definitely. Thanks for highlighting these issues.
I'll also add a logging option to capture all attempted register accesses in a file, so that we can have this without having to have full verbosity to the terminal output.
- Based on the enclosed script, there still have two registers accessing will always cause the external abort: 0xec040000 and 0xec040000, this two registers are for timestamp based on the log;
There may be a timestamp generator shared with Secure parts of the chip, so we might be seeing any attempt to read it from Non-Secure treated as a system level error. Not sure why we'd ever need two timestamp generators though. Is this just an ordinary single-socket HiKey960? I had thought that was one of the systems we had established we could deal with.
Al
So I use below command to exclude these two registers accessing and then the csscan.py script can finish traversing for CoreSight topology. The great thing is I also can see the script will dump the CTI related registers.
python csscan.py -vvv --exclude=0xec040000 --exclude=0xec080000 0xEC000000
Thanks, Leo Yan
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.