Dear Leo Yan,
I will like to ask if there are any better documentations that detail the memory mapped addresses for Coresight registers in Hikey960.
I am currently referring to Chapter 2-9-1 in http://mirror.lemaker.org/HiKey960_SoC_Reference_Manual.pdf. This is all the information about coresight addresses that I could retrieve:
0xEC000000 0xED7FFFFF 24M CSSYS_APB
I will like to check if there are any datasheet for hikey960 that is as detailed as that for Juno device (link here: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0515b/CHDIFAD... ).
This is important to me as I am trying to acquire the device snapshot by using CSAL API. I am not sure if there are other ways to do this since the documentation hasn't been exactly straightforward.
The reason for wanting the snapshot is to possibly run openCSD and decode my trace binary files.
I have followed the CSAL build documentations and ran `csls` on my hikey960. The following output is seen but it crashed my device soon after:
```bash hikey960:/ # csls ** CSLS: listing CoreSight config... ** CSLS: Using default ROM address 0xEC000000 00EC031000: 2.1 908 00000037 00/0F type= 4 - LINK [FUNNEL: 7 in ports] 00EC032000: 1.1 912 000000A0 00/0F type= 8 - SINK PORT [TPIU] 00EC033000: 1.2 961 00001B40 00/0F type= 7 - SINK BUFFER(ETR r/w size: 4K) [TMC: ETR configuration] 00EC034000: 4.1 906 00040800 00/0F type=10 - CTI 00EC035000: 3.6 963 00010000 00/0F type= 3 - SOURCE SWSTIM(65536) [STM ext ports only, 64-bit, 128 masters] 00EC036000: 2.3 961 00000480 00/0F type= 6 - LINK SINK BUFFER(4K) [TMC: ETF configuration] 00EC037000: type=13 O TIMESTAMP 00EC038000: type=13 O TIMESTAMP ```
I will also like to understand why it might have crashed my device during the execution of csls.
Please assist.
Yours Sincerely, Jeremy
Hi Jeremy,
On Wed, Jul 17, 2019 at 05:53:28PM +0800, Jeremy Ng wrote:
Dear Leo Yan,
I will like to ask if there are any better documentations that detail the memory mapped addresses for Coresight registers in Hikey960.
I am currently referring to Chapter 2-9-1 in http://mirror.lemaker.org/HiKey960_SoC_Reference_Manual.pdf. This is all the information about coresight addresses that I could retrieve:
0xEC000000 0xED7FFFFF 24M CSSYS_APB
As I know, the CoreSight registers address mapping is not contained in this pdf file.
On the other hand, could you check if below patch is sufficient for you? In this patch, it enabled CoreSight on Hikey960 and contains the addresses for CoreSight devices. https://archive.armlinux.org.uk/lurker/message/20190420.140035.74b936ef.en.h...
I will like to check if there are any datasheet for hikey960 that is as detailed as that for Juno device (link here: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0515b/CHDIFAD... ).
This is important to me as I am trying to acquire the device snapshot by using CSAL API. I am not sure if there are other ways to do this since the documentation hasn't been exactly straightforward.
The reason for wanting the snapshot is to possibly run openCSD and decode my trace binary files.
I have followed the CSAL build documentations and ran `csls` on my hikey960. The following output is seen but it crashed my device soon after:
hikey960:/ # csls ** CSLS: listing CoreSight config... ** CSLS: Using default ROM address 0xEC000000 00EC031000: 2.1 908 00000037 00/0F type= 4 - LINK [FUNNEL: 7 in ports] 00EC032000: 1.1 912 000000A0 00/0F type= 8 - SINK PORT [TPIU] 00EC033000: 1.2 961 00001B40 00/0F type= 7 - SINK BUFFER(ETR r/w size: 4K) [TMC: ETR configuration] 00EC034000: 4.1 906 00040800 00/0F type=10 - CTI 00EC035000: 3.6 963 00010000 00/0F type= 3 - SOURCE SWSTIM(65536) [STM ext ports only, 64-bit, 128 masters] 00EC036000: 2.3 961 00000480 00/0F type= 6 - LINK SINK BUFFER(4K) [TMC: ETF configuration] 00EC037000: type=13 O TIMESTAMP 00EC038000: type=13 O TIMESTAMP
I will also like to understand why it might have crashed my device during the execution of csls.
Cool! Thanks for sharing the method.
Could you try to disable CPUidles for Hikey960? E.g. you could add 'nohlt' in the kernel command line to prevent CPU idle states. Or you could use below command:
# exec 3<> /dev/cpu_dma_latency; echo 0 >&3
Thanks, Leo Yan
Hi Leo Yan,
On Wed, Jul 17, 2019 at 6:04 PM Leo Yan leo.yan@linaro.org wrote:
Hi Jeremy,
On Wed, Jul 17, 2019 at 05:53:28PM +0800, Jeremy Ng wrote:
Dear Leo Yan,
I will like to ask if there are any better documentations that detail
the
memory mapped addresses for Coresight registers in Hikey960.
I am currently referring to Chapter 2-9-1 in http://mirror.lemaker.org/HiKey960_SoC_Reference_Manual.pdf. This is all the information about coresight addresses that I could retrieve:
0xEC000000 0xED7FFFFF 24M CSSYS_APB
As I know, the CoreSight registers address mapping is not contained in this pdf file.
Are there any other pdf files that perhaps I could have access to with all the addresses properly detailed?
Just to improve understanding of what I am trying to accomplish, I will include a snippet of the code from CSAL.
This is a snippet of the code that I am currently trying to write for hikey960, in hope that I might be able to reproduce the results for the other example boards, such as Juno, Snowball or TC2:
static int do_registration_juno(struct cs_devices_t *devices) { enum { A53_0, A53_1, A53_2, A53_3, A57_0, A57_1 }; cs_device_t rep, etr, etf, fun_main, fun_a53, fun_a57, stm, tpiu, sys_cti; cs_device_t r1_fun_scp, r1_fun_common, r1_etf_scp; #ifdef LIB_DEVICE_UNSUPPORTED cs_device_t r1_cti_2, ela_a53, ela_a57; #endif int i;
if (registration_verbose) printf("CSDEMO: Registering CoreSight devices...\n"); cs_register_romtable(0x20000000);
if (registration_verbose) printf("CSDEMO: Registering CPU affinities...\n");
/* CTI affinities */ cs_device_set_affinity(cs_device_register(0x22020000), A57_0); cs_device_set_affinity(cs_device_register(0x22120000), A57_1); cs_device_set_affinity(cs_device_register(0x23020000), A53_0); cs_device_set_affinity(cs_device_register(0x23120000), A53_1); cs_device_set_affinity(cs_device_register(0x23220000), A53_2); cs_device_set_affinity(cs_device_register(0x23320000), A53_3);
/* PMU affinities */ cs_device_set_affinity(cs_device_register(0x22030000), A57_0); cs_device_set_affinity(cs_device_register(0x22130000), A57_1); cs_device_set_affinity(cs_device_register(0x23030000), A53_0); cs_device_set_affinity(cs_device_register(0x23130000), A53_1); cs_device_set_affinity(cs_device_register(0x23230000), A53_2); cs_device_set_affinity(cs_device_register(0x23330000), A53_3);
/* ETMv4 affinities */ cs_device_set_affinity(cs_device_register(0x22040000), A57_0); cs_device_set_affinity(cs_device_register(0x22140000), A57_1); cs_device_set_affinity(cs_device_register(0x23040000), A53_0); cs_device_set_affinity(cs_device_register(0x23140000), A53_1); cs_device_set_affinity(cs_device_register(0x23240000), A53_2); cs_device_set_affinity(cs_device_register(0x23340000), A53_3);
if (registration_verbose) printf("CSDEMO: Registering trace-bus connections...\n");
/* funnels in clusters */ fun_a57 = cs_device_get(0x220C0000); cs_atb_register(cs_cpu_get_device(A57_0, CS_DEVCLASS_SOURCE), 0, fun_a57, 0); cs_atb_register(cs_cpu_get_device(A57_1, CS_DEVCLASS_SOURCE), 0, fun_a57, 1);
fun_a53 = cs_device_get(0x230C0000); cs_atb_register(cs_cpu_get_device(A53_0, CS_DEVCLASS_SOURCE), 0, fun_a53, 0); cs_atb_register(cs_cpu_get_device(A53_1, CS_DEVCLASS_SOURCE), 0, fun_a53, 1); cs_atb_register(cs_cpu_get_device(A53_2, CS_DEVCLASS_SOURCE), 0, fun_a53, 2); cs_atb_register(cs_cpu_get_device(A53_3, CS_DEVCLASS_SOURCE), 0, fun_a53, 3);
/*common setup */ fun_main = cs_device_get(0x20040000); stm = cs_device_get(0x20100000); etf = cs_device_get(0x20010000); rep = cs_device_get(0x20120000); etr = cs_device_get(0x20070000); tpiu = cs_device_get(0x20030000); . .
The addresses stated in the function code for Juno corresponds with the official Technical datasheet as found in https://www.arm.com/files/pdf/DDI0515D1a_juno_arm_development_platform_soc_t... , page 3-21.
Furthermore, I realized that there are missing programmable addresses in Hi3660 datasheet:
0xED800000 0xEFFFFFFF 40M Reserved 0xEC000000 0xED7FFFFF 24M CSSYS_APB 0xE9890000 0xE989FFFF 64K MMC0_NOC_Service_Target
As seen in the data above, there is a gap from 0xE98A0000 to 0xEBFFFFFF I am particularly curious whether the coresight address' offset might be consistent across different boards.
For example, CS_APB starts at 0x2100_0000 for Juno and CS_ROM is found at 0x2000_0000, 0x0100_0000 apart. I have tried to run `csls` on 0xEB00_0000 for hikey960 but as with the previous attempts, the device crashes + there are less info output when probing from that address.
i.e. hikey960:/ # csls ** CSLS: listing CoreSight config... ** CSLS: Using default ROM address 0xEB000000
--- crash ---<
On the other hand, could you check if below patch is sufficient for you? In this patch, it enabled CoreSight on Hikey960 and contains the addresses for CoreSight devices.
https://archive.armlinux.org.uk/lurker/message/20190420.140035.74b936ef.en.h...
Unfortunately, I could not access this webpage from Singapore.
On another note, my hikey960 is run on Linux kernel 4.9: hikey960:/ # uname -ar Linux localhost 4.9.176-12953-g7c09ed7b46a4-dirty #15 SMP PREEMPT Wed Jul 17 16:53:26 +08 2019 aarch64
I will like to check if there are any datasheet for hikey960 that is as detailed as that for Juno device (link here:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0515b/CHDIFAD...
).
This is important to me as I am trying to acquire the device snapshot by using CSAL API. I am not sure if there are other ways to do this since
the
documentation hasn't been exactly straightforward.
The reason for wanting the snapshot is to possibly run openCSD and
decode
my trace binary files.
I have followed the CSAL build documentations and ran `csls` on my hikey960. The following output is seen but it crashed my device soon
after:
hikey960:/ # csls ** CSLS: listing CoreSight config... ** CSLS: Using default ROM address 0xEC000000 00EC031000: 2.1 908 00000037 00/0F type= 4 - LINK [FUNNEL: 7 in ports] 00EC032000: 1.1 912 000000A0 00/0F type= 8 - SINK PORT [TPIU] 00EC033000: 1.2 961 00001B40 00/0F type= 7 - SINK BUFFER(ETR r/w size:
4K)
[TMC: ETR configuration] 00EC034000: 4.1 906 00040800 00/0F type=10 - CTI 00EC035000: 3.6 963 00010000 00/0F type= 3 - SOURCE SWSTIM(65536) [STM
ext
ports only, 64-bit, 128 masters] 00EC036000: 2.3 961 00000480 00/0F type= 6 - LINK SINK BUFFER(4K) [TMC:
ETF
configuration] 00EC037000: type=13 O TIMESTAMP 00EC038000: type=13 O TIMESTAMP
I will also like to understand why it might have crashed my device
during
the execution of csls.
Cool! Thanks for sharing the method.
Could you try to disable CPUidles for Hikey960? E.g. you could add 'nohlt' in the kernel command line to prevent CPU idle states. Or you could use below command:
# exec 3<> /dev/cpu_dma_latency; echo 0 >&3
Previously, I disabled cpu_idle from linux kernel menuconfig and reflashed the kernel. I have also made a bash script to temporarily disable cpuidle. the script is:
#!/bin/sh
# For A53 Cluster for i in 0 1 2 3; do for j in 0 1 2 ; do echo 1 > /sys/devices/system/cpu/cpu$i/cpuidle/state$j/disable; echo 'cpu$i state$j disabled'; done; done
# For A73 Cluster for i in 4 5 6 7; do for j in 0 1 2 ; do echo 1 > /sys/devices/system/cpu/cpu$i/cpuidle/state$j/disable; echo 'cpu$i state$j disabled'; done; done
I am not sure if these methods differ from your methods, but cpuidle in my device should have been switched off.
Nonetheless, i tried your both methods.
After the first method, my device still crash after csls command. How I added the kernel parameters is by adding the following line to the end of the script in ${AOSP_DIR}/device/linaro/hikey/hikey960/BoardConfig.mk:
BOARD_KERNEL_CMDLINE += nohlt
before rebuilding and reflashing the boot image into hikey960. Output of the kernel parameters added can be found: hikey960:/ # cat /proc/cmdline
androidboot.hardware=hikey960 firmware_class.path=/vendor/firmware efi=noruntime init=/init androidboot.boot_devices=soc/ff3b0000.ufs loglevel=15 overlay_mgr.overlay_dt_entry=hardware_cfg_enable_android_fstab *nohlt* buildvariant=eng console=ttyAMA6 androidboot.serialno=2E6F5F3A0180CA83 initrd=0x7C00000,0xC2431
Unfortunately, using both methods simultaneously did not work and csls still did not give me the full listing of the coresight components. The output from the csls command before it crashed remains the same as per our last email.
Thanks, Leo Yan
Thank you for your reply and assistance!
Jeremy
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/discovery.m...
Al
From: CoreSight coresight-bounces@lists.linaro.org On Behalf Of Jeremy Ng Sent: 18 July 2019 04:54 To: leo.yan@linaro.org Cc: coresight@lists.linaro.org Subject: Re: Coresight Memory Mapped Addresses in Hikey960
Hi Leo Yan,
On Wed, Jul 17, 2019 at 6:04 PM Leo Yan <leo.yan@linaro.orgmailto:leo.yan@linaro.org> wrote:
Hi Jeremy,
On Wed, Jul 17, 2019 at 05:53:28PM +0800, Jeremy Ng wrote:
Dear Leo Yan,
I will like to ask if there are any better documentations that detail the memory mapped addresses for Coresight registers in Hikey960.
I am currently referring to Chapter 2-9-1 in http://mirror.lemaker.org/HiKey960_SoC_Reference_Manual.pdf. This is all the information about coresight addresses that I could retrieve:
0xEC000000 0xED7FFFFF 24M CSSYS_APB
As I know, the CoreSight registers address mapping is not contained in this pdf file.
Are there any other pdf files that perhaps I could have access to with all the addresses properly detailed?
Just to improve understanding of what I am trying to accomplish, I will include a snippet of the code from CSAL.
This is a snippet of the code that I am currently trying to write for hikey960, in hope that I might be able to reproduce the results for the other example boards, such as Juno, Snowball or TC2:
static int do_registration_juno(struct cs_devices_t *devices) { enum { A53_0, A53_1, A53_2, A53_3, A57_0, A57_1 }; cs_device_t rep, etr, etf, fun_main, fun_a53, fun_a57, stm, tpiu, sys_cti; cs_device_t r1_fun_scp, r1_fun_common, r1_etf_scp; #ifdef LIB_DEVICE_UNSUPPORTED cs_device_t r1_cti_2, ela_a53, ela_a57; #endif int i;
if (registration_verbose) printf("CSDEMO: Registering CoreSight devices...\n"); cs_register_romtable(0x20000000);
if (registration_verbose) printf("CSDEMO: Registering CPU affinities...\n");
/* CTI affinities */ cs_device_set_affinity(cs_device_register(0x22020000), A57_0); cs_device_set_affinity(cs_device_register(0x22120000), A57_1); cs_device_set_affinity(cs_device_register(0x23020000), A53_0); cs_device_set_affinity(cs_device_register(0x23120000), A53_1); cs_device_set_affinity(cs_device_register(0x23220000), A53_2); cs_device_set_affinity(cs_device_register(0x23320000), A53_3);
/* PMU affinities */ cs_device_set_affinity(cs_device_register(0x22030000), A57_0); cs_device_set_affinity(cs_device_register(0x22130000), A57_1); cs_device_set_affinity(cs_device_register(0x23030000), A53_0); cs_device_set_affinity(cs_device_register(0x23130000), A53_1); cs_device_set_affinity(cs_device_register(0x23230000), A53_2); cs_device_set_affinity(cs_device_register(0x23330000), A53_3);
/* ETMv4 affinities */ cs_device_set_affinity(cs_device_register(0x22040000), A57_0); cs_device_set_affinity(cs_device_register(0x22140000), A57_1); cs_device_set_affinity(cs_device_register(0x23040000), A53_0); cs_device_set_affinity(cs_device_register(0x23140000), A53_1); cs_device_set_affinity(cs_device_register(0x23240000), A53_2); cs_device_set_affinity(cs_device_register(0x23340000), A53_3);
if (registration_verbose) printf("CSDEMO: Registering trace-bus connections...\n");
/* funnels in clusters */ fun_a57 = cs_device_get(0x220C0000); cs_atb_register(cs_cpu_get_device(A57_0, CS_DEVCLASS_SOURCE), 0, fun_a57, 0); cs_atb_register(cs_cpu_get_device(A57_1, CS_DEVCLASS_SOURCE), 0, fun_a57, 1);
fun_a53 = cs_device_get(0x230C0000); cs_atb_register(cs_cpu_get_device(A53_0, CS_DEVCLASS_SOURCE), 0, fun_a53, 0); cs_atb_register(cs_cpu_get_device(A53_1, CS_DEVCLASS_SOURCE), 0, fun_a53, 1); cs_atb_register(cs_cpu_get_device(A53_2, CS_DEVCLASS_SOURCE), 0, fun_a53, 2); cs_atb_register(cs_cpu_get_device(A53_3, CS_DEVCLASS_SOURCE), 0, fun_a53, 3);
/*common setup */ fun_main = cs_device_get(0x20040000); stm = cs_device_get(0x20100000); etf = cs_device_get(0x20010000); rep = cs_device_get(0x20120000); etr = cs_device_get(0x20070000); tpiu = cs_device_get(0x20030000); . .
The addresses stated in the function code for Juno corresponds with the official Technical datasheet as found in https://www.arm.com/files/pdf/DDI0515D1a_juno_arm_development_platform_soc_t..., page 3-21.
Furthermore, I realized that there are missing programmable addresses in Hi3660 datasheet:
0xED800000 0xEFFFFFFF 40M Reserved 0xEC000000 0xED7FFFFF 24M CSSYS_APB 0xE9890000 0xE989FFFF 64K MMC0_NOC_Service_Target
As seen in the data above, there is a gap from 0xE98A0000 to 0xEBFFFFFF I am particularly curious whether the coresight address' offset might be consistent across different boards.
For example, CS_APB starts at 0x2100_0000 for Juno and CS_ROM is found at 0x2000_0000, 0x0100_0000 apart. I have tried to run `csls` on 0xEB00_0000 for hikey960 but as with the previous attempts, the device crashes + there are less info output when probing from that address.
i.e. hikey960:/ # csls ** CSLS: listing CoreSight config... ** CSLS: Using default ROM address 0xEB000000
--- crash ---<
On the other hand, could you check if below patch is sufficient for you? In this patch, it enabled CoreSight on Hikey960 and contains the addresses for CoreSight devices. https://archive.armlinux.org.uk/lurker/message/20190420.140035.74b936ef.en.h...
Unfortunately, I could not access this webpage from Singapore.
On another note, my hikey960 is run on Linux kernel 4.9: hikey960:/ # uname -ar Linux localhost 4.9.176-12953-g7c09ed7b46a4-dirty #15 SMP PREEMPT Wed Jul 17 16:53:26 +08 2019 aarch64
I will like to check if there are any datasheet for hikey960 that is as detailed as that for Juno device (link here: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0515b/CHDIFAD... ).
This is important to me as I am trying to acquire the device snapshot by using CSAL API. I am not sure if there are other ways to do this since the documentation hasn't been exactly straightforward.
The reason for wanting the snapshot is to possibly run openCSD and decode my trace binary files.
I have followed the CSAL build documentations and ran `csls` on my hikey960. The following output is seen but it crashed my device soon after:
hikey960:/ # csls ** CSLS: listing CoreSight config... ** CSLS: Using default ROM address 0xEC000000 00EC031000: 2.1 908 00000037 00/0F type= 4 - LINK [FUNNEL: 7 in ports] 00EC032000: 1.1 912 000000A0 00/0F type= 8 - SINK PORT [TPIU] 00EC033000: 1.2 961 00001B40 00/0F type= 7 - SINK BUFFER(ETR r/w size: 4K) [TMC: ETR configuration] 00EC034000: 4.1 906 00040800 00/0F type=10 - CTI 00EC035000: 3.6 963 00010000 00/0F type= 3 - SOURCE SWSTIM(65536) [STM ext ports only, 64-bit, 128 masters] 00EC036000: 2.3 961 00000480 00/0F type= 6 - LINK SINK BUFFER(4K) [TMC: ETF configuration] 00EC037000: type=13 O TIMESTAMP 00EC038000: type=13 O TIMESTAMP
I will also like to understand why it might have crashed my device during the execution of csls.
Cool! Thanks for sharing the method.
Could you try to disable CPUidles for Hikey960? E.g. you could add 'nohlt' in the kernel command line to prevent CPU idle states. Or you could use below command:
# exec 3<> /dev/cpu_dma_latency; echo 0 >&3
Previously, I disabled cpu_idle from linux kernel menuconfig and reflashed the kernel. I have also made a bash script to temporarily disable cpuidle. the script is:
#!/bin/sh
# For A53 Cluster for i in 0 1 2 3; do for j in 0 1 2 ; do echo 1 > /sys/devices/system/cpu/cpu$i/cpuidle/state$j/disable; echo 'cpu$i state$j disabled'; done; done
# For A73 Cluster for i in 4 5 6 7; do for j in 0 1 2 ; do echo 1 > /sys/devices/system/cpu/cpu$i/cpuidle/state$j/disable; echo 'cpu$i state$j disabled'; done; done
I am not sure if these methods differ from your methods, but cpuidle in my device should have been switched off.
Nonetheless, i tried your both methods.
After the first method, my device still crash after csls command. How I added the kernel parameters is by adding the following line to the end of the script in ${AOSP_DIR}/device/linaro/hikey/hikey960/BoardConfig.mk:
BOARD_KERNEL_CMDLINE += nohlt
before rebuilding and reflashing the boot image into hikey960. Output of the kernel parameters added can be found: hikey960:/ # cat /proc/cmdline androidboot.hardware=hikey960 firmware_class.path=/vendor/firmware efi=noruntime init=/init androidboot.boot_devices=soc/ff3b0000.ufs loglevel=15 overlay_mgr.overlay_dt_entry=hardware_cfg_enable_android_fstab nohlt buildvariant=eng console=ttyAMA6 androidboot.serialno=2E6F5F3A0180CA83 initrd=0x7C00000,0xC2431
Unfortunately, using both methods simultaneously did not work and csls still did not give me the full listing of the coresight components. The output from the csls command before it crashed remains the same as per our last email.
Thanks, Leo Yan
Thank you for your reply and assistance!
Jeremy 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.
Hi Al,
On Fri, Jul 19, 2019 at 5:16 PM Al Grant Al.Grant@arm.com 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/discovery.m...
Al
Thank you for your email. My apologies for the late reply as I only have access to my work on weekdays.
Anyway, I have tried the coresight-tools as updated on CSAL repo.
Unfortunately, the device continues to hang at the same memory mapped address.
Just to clarify the steps I have taken:
1. Since hikey960 is running on AOSP, Linux kernel 4.9, python is not installed 2. I installed python to the device by installing Termux APK, access internet and downloaded python through `pkg install python`
3. Next, i get access to root through adb and added a path to termux's bin files through `PATH=$PATH:/data/data/com.termux/files/usr/bin` 4. I ran `python /data/coresight-tools/csscan.py 0xEC000000`. Below shows the output for csscan and csls to show the similarites between the outputs.
csscan.py ========
hikey960:/ # python /data/coresight-tools/csscan.py 0xEC000000
@0xec000000 0x327 0x000 r0.0 ROM table @0xec030000 0x000 0x000 r0.0 ROM table @0xec031000 0x23b 0x908 r2.0 funnel in-ports:7 @0xec032000 0x23b 0x912 r4.0 port TPIU @0xec033000 0x23b 0x961 r1.0 buffer TMC:ETR memwidth:64 wb:8 @0xec034000 0x23b 0x906 r4.0 CTI channels:4 triggers:8 @0xec035000 0x23b 0x963 r0.0 STM Arm STM rev1 ports:65536 @0xec036000 0x23b 0x961 r1.0 fifo TMC:ETF size:4096 memwidth:128 @0xec037000 0x23b 0x101 r1.0 CoreSight timestamp generator @0xec038000 0x23b 0x101 r1.0 CoreSight timestamp generator
--- device crash ---<
csls === hikey960:/ # csls ** CSLS: listing CoreSight config... ** CSLS: Using default ROM address 0xEC000000 00EC031000: 2.1 908 00000037 00/0F type= 4 - LINK [FUNNEL: 7 in ports] 00EC032000: 1.1 912 000000A0 00/0F type= 8 - SINK PORT [TPIU] 00EC033000: 1.2 961 00001B40 00/0F type= 7 - SINK BUFFER(ETR r/w size: 4K) [TMC: ETR configuration] 00EC034000: 4.1 906 00040800 00/0F type=10 - CTI 00EC035000: 3.6 963 00010000 00/0F type= 3 - SOURCE SWSTIM(65536) [STM ext ports only, 64-bit, 128 masters] 00EC036000: 2.3 961 00000480 00/0F type= 6 - LINK SINK BUFFER(4K) [TMC: ETF configuration] 00EC037000: type=13 O TIMESTAMP 00EC038000: type=13 O TIMESTAMP
--- device crash ---<
I am also aware that CPUIdle must be switched off. I have a bash script that deactivates the CPUIdle settings, on top of the suggestions Leo Yan has made in the previous email.
This is the script used: # For A53 Cluster for i in 0 1 2 3; do for j in 0 1 2 ; do adb shell "echo 1 > /sys/devices/system/cpu/cpu$i/cpuidle/state$j/disable"; adb shell "echo 'cpu$i state$j disabled'"; done; done
# For A73 Cluster for i in 4 5 6 7; do for j in 0 1 2 ; do adb shell "echo 1 > /sys/devices/system/cpu/cpu$i/cpuidle/state$j/disable"; adb shell "echo 'cpu$i state$j disabled'"; done; done
adb shell "exec 3<> /dev/cpu_dma_latency; echo 0 >&3"
Hopefully I have given sufficient details and perhaps a solution can be derived.
Once again, thank you very much for the tools and assistance!
Yours Sincerely, Jeremy
From: CoreSight coresight-bounces@lists.linaro.org On Behalf Of Jeremy
Ng
Sent: 18 July 2019 04:54 To: leo.yan@linaro.org Cc: coresight@lists.linaro.org Subject: Re: Coresight Memory Mapped Addresses in Hikey960
Hi Leo Yan,
On Wed, Jul 17, 2019 at 6:04 PM Leo Yan leo.yan@linaro.org wrote:
Hi Jeremy,
On Wed, Jul 17, 2019 at 05:53:28PM +0800, Jeremy Ng wrote:
Dear Leo Yan,
I will like to ask if there are any better documentations that detail
the
memory mapped addresses for Coresight registers in Hikey960.
I am currently referring to Chapter 2-9-1 in http://mirror.lemaker.org/HiKey960_SoC_Reference_Manual.pdf. This is
all
the information about coresight addresses that I could retrieve:
0xEC000000 0xED7FFFFF 24M CSSYS_APB
As I know, the CoreSight registers address mapping is not contained in this pdf file.
Are there any other pdf files that perhaps I could have access to with all the addresses properly detailed?
Just to improve understanding of what I am trying to accomplish, I will
include
a snippet of the code from CSAL.
This is a snippet of the code that I am currently trying to write for
hikey960,
in hope that I might be able to reproduce the results for the other
example boards,
such as Juno, Snowball or TC2:
static int do_registration_juno(struct cs_devices_t *devices) { enum { A53_0, A53_1, A53_2, A53_3, A57_0, A57_1 }; cs_device_t rep, etr, etf, fun_main, fun_a53, fun_a57, stm, tpiu, sys_cti; cs_device_t r1_fun_scp, r1_fun_common, r1_etf_scp; #ifdef LIB_DEVICE_UNSUPPORTED cs_device_t r1_cti_2, ela_a53, ela_a57; #endif int i;
if (registration_verbose) printf("CSDEMO: Registering CoreSight devices...\n"); cs_register_romtable(0x20000000); if (registration_verbose) printf("CSDEMO: Registering CPU affinities...\n"); /* CTI affinities */ cs_device_set_affinity(cs_device_register(0x22020000), A57_0); cs_device_set_affinity(cs_device_register(0x22120000), A57_1); cs_device_set_affinity(cs_device_register(0x23020000), A53_0); cs_device_set_affinity(cs_device_register(0x23120000), A53_1); cs_device_set_affinity(cs_device_register(0x23220000), A53_2); cs_device_set_affinity(cs_device_register(0x23320000), A53_3); /* PMU affinities */ cs_device_set_affinity(cs_device_register(0x22030000), A57_0); cs_device_set_affinity(cs_device_register(0x22130000), A57_1); cs_device_set_affinity(cs_device_register(0x23030000), A53_0); cs_device_set_affinity(cs_device_register(0x23130000), A53_1); cs_device_set_affinity(cs_device_register(0x23230000), A53_2); cs_device_set_affinity(cs_device_register(0x23330000), A53_3); /* ETMv4 affinities */ cs_device_set_affinity(cs_device_register(0x22040000), A57_0); cs_device_set_affinity(cs_device_register(0x22140000), A57_1); cs_device_set_affinity(cs_device_register(0x23040000), A53_0); cs_device_set_affinity(cs_device_register(0x23140000), A53_1); cs_device_set_affinity(cs_device_register(0x23240000), A53_2); cs_device_set_affinity(cs_device_register(0x23340000), A53_3); if (registration_verbose) printf("CSDEMO: Registering trace-bus connections...\n"); /* funnels in clusters */ fun_a57 = cs_device_get(0x220C0000); cs_atb_register(cs_cpu_get_device(A57_0, CS_DEVCLASS_SOURCE), 0, fun_a57, 0); cs_atb_register(cs_cpu_get_device(A57_1, CS_DEVCLASS_SOURCE), 0, fun_a57, 1); fun_a53 = cs_device_get(0x230C0000); cs_atb_register(cs_cpu_get_device(A53_0, CS_DEVCLASS_SOURCE), 0, fun_a53, 0); cs_atb_register(cs_cpu_get_device(A53_1, CS_DEVCLASS_SOURCE), 0, fun_a53, 1); cs_atb_register(cs_cpu_get_device(A53_2, CS_DEVCLASS_SOURCE), 0, fun_a53, 2); cs_atb_register(cs_cpu_get_device(A53_3, CS_DEVCLASS_SOURCE), 0, fun_a53, 3); /*common setup */ fun_main = cs_device_get(0x20040000); stm = cs_device_get(0x20100000); etf = cs_device_get(0x20010000); rep = cs_device_get(0x20120000); etr = cs_device_get(0x20070000); tpiu = cs_device_get(0x20030000);
.
.
The addresses stated in the function code for Juno corresponds with the
official
Technical datasheet as found in
https://www.arm.com/files/pdf/DDI0515D1a_juno_arm_development_platform_soc_t... ,
page 3-21.
Furthermore, I realized that there are missing programmable addresses in
Hi3660 datasheet:
0xED800000 0xEFFFFFFF 40M Reserved 0xEC000000 0xED7FFFFF 24M CSSYS_APB 0xE9890000 0xE989FFFF 64K MMC0_NOC_Service_Target
As seen in the data above, there is a gap from 0xE98A0000 to 0xEBFFFFFF
I am particularly curious whether the coresight address' offset might be
consistent across different boards.
For example, CS_APB starts at 0x2100_0000 for Juno and CS_ROM is found at
0x2000_0000, 0x0100_0000 apart. I have tried to run `csls` on 0xEB00_0000
for
hikey960 but as with the previous attempts, the device crashes + there
are less info
output when probing from that address.
i.e. hikey960:/ # csls ** CSLS: listing CoreSight config... ** CSLS: Using default ROM address 0xEB000000
--- crash ---<
On the other hand, could you check if below patch is sufficient for you? In this patch, it enabled CoreSight on Hikey960 and contains the addresses for CoreSight devices.
https://archive.armlinux.org.uk/lurker/message/20190420.140035.74b936ef.en.h...
Unfortunately, I could not access this webpage from Singapore.
On another note, my hikey960 is run on Linux kernel 4.9:
hikey960:/ # uname -ar
Linux localhost 4.9.176-12953-g7c09ed7b46a4-dirty #15 SMP PREEMPT Wed Jul
17 16:53:26 +08 2019 aarch64
I will like to check if there are any datasheet for hikey960 that is
as
detailed as that for Juno device (link here:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0515b/CHDIFAD...
).
This is important to me as I am trying to acquire the device snapshot
by
using CSAL API. I am not sure if there are other ways to do this
since the
documentation hasn't been exactly straightforward.
The reason for wanting the snapshot is to possibly run openCSD and
decode
my trace binary files.
I have followed the CSAL build documentations and ran `csls` on my hikey960. The following output is seen but it crashed my device soon
after:
hikey960:/ # csls ** CSLS: listing CoreSight config... ** CSLS: Using default ROM address 0xEC000000 00EC031000: 2.1 908 00000037 00/0F type= 4 - LINK [FUNNEL: 7 in ports] 00EC032000: 1.1 912 000000A0 00/0F type= 8 - SINK PORT [TPIU] 00EC033000: 1.2 961 00001B40 00/0F type= 7 - SINK BUFFER(ETR r/w
size: 4K)
[TMC: ETR configuration] 00EC034000: 4.1 906 00040800 00/0F type=10 - CTI 00EC035000: 3.6 963 00010000 00/0F type= 3 - SOURCE SWSTIM(65536)
[STM ext
ports only, 64-bit, 128 masters] 00EC036000: 2.3 961 00000480 00/0F type= 6 - LINK SINK BUFFER(4K)
[TMC: ETF
configuration] 00EC037000: type=13 O TIMESTAMP 00EC038000: type=13 O TIMESTAMP
I will also like to understand why it might have crashed my device
during
the execution of csls.
Cool! Thanks for sharing the method.
Could you try to disable CPUidles for Hikey960? E.g. you could add 'nohlt' in the kernel command line to prevent CPU idle states. Or you could use below command:
# exec 3<> /dev/cpu_dma_latency; echo 0 >&3
Previously, I disabled cpu_idle from linux kernel menuconfig and
reflashed the kernel.
I have also made a bash script to temporarily disable cpuidle. the script
is:
#!/bin/sh
# For A53 Cluster for i in 0 1 2 3; do for j in 0 1 2 ; do echo 1 > /sys/devices/system/cpu/cpu$i/cpuidle/state$j/disable; echo 'cpu$i state$j disabled'; done; done
# For A73 Cluster for i in 4 5 6 7; do for j in 0 1 2 ; do echo 1 > /sys/devices/system/cpu/cpu$i/cpuidle/state$j/disable; echo 'cpu$i state$j disabled'; done; done
I am not sure if these methods differ from your methods, but cpuidle
in my device should have been switched off.
Nonetheless, i tried your both methods.
After the first method, my device still crash after csls command.
How I added the kernel parameters is by adding the following line
to the end of the script in
${AOSP_DIR}/device/linaro/hikey/hikey960/BoardConfig.mk:
BOARD_KERNEL_CMDLINE += nohlt
before rebuilding and reflashing the boot image into hikey960.
Output of the kernel parameters added can be found:
hikey960:/ # cat /proc/cmdline
androidboot.hardware=hikey960 firmware_class.path=/vendor/firmware
efi=noruntime init=/init androidboot.boot_devices=soc/ff3b0000.ufs loglevel=15 overlay_mgr.overlay_dt_entry=hardware_cfg_enable_android_fstab nohlt buildvariant=eng console=ttyAMA6 androidboot.serialno=2E6F5F3A0180CA83 initrd=0x7C00000,0xC2431
Unfortunately, using both methods simultaneously did not work and csls
still did not give me the full listing of the coresight components.
The output from the csls command before it crashed
remains the same as per our last email.
Thanks, Leo Yan
Thank you for your reply and assistance!
Jeremy
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.
Hi Jeremy,
On Mon, Jul 22, 2019 at 11:42:57AM +0800, Jeremy Ng wrote:
Hi Al,
On Fri, Jul 19, 2019 at 5:16 PM Al Grant Al.Grant@arm.com 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/discovery.m...
Al
Thank you for your email. My apologies for the late reply as I only have access to my work on weekdays.
Anyway, I have tried the coresight-tools as updated on CSAL repo.
Unfortunately, the device continues to hang at the same memory mapped address.
Just to clarify the steps I have taken:
- Since hikey960 is running on AOSP, Linux kernel 4.9, python is not
installed 2. I installed python to the device by installing Termux APK, access internet and downloaded python through `pkg install python`
- Next, i get access to root through adb and added a path to termux's bin
files through `PATH=$PATH:/data/data/com.termux/files/usr/bin` 4. I ran `python /data/coresight-tools/csscan.py 0xEC000000`. Below shows the output for csscan and csls to show the similarites between the outputs.
csscan.py
hikey960:/ # python /data/coresight-tools/csscan.py 0xEC000000
@0xec000000 0x327 0x000 r0.0 ROM table @0xec030000 0x000 0x000 r0.0 ROM table @0xec031000 0x23b 0x908 r2.0 funnel in-ports:7 @0xec032000 0x23b 0x912 r4.0 port TPIU @0xec033000 0x23b 0x961 r1.0 buffer TMC:ETR memwidth:64 wb:8 @0xec034000 0x23b 0x906 r4.0 CTI channels:4 triggers:8 @0xec035000 0x23b 0x963 r0.0 STM Arm STM rev1 ports:65536 @0xec036000 0x23b 0x961 r1.0 fifo TMC:ETF size:4096 memwidth:128 @0xec037000 0x23b 0x101 r1.0 CoreSight timestamp generator @0xec038000 0x23b 0x101 r1.0 CoreSight timestamp generator
--- device crash ---<
csls
hikey960:/ # csls ** CSLS: listing CoreSight config... ** CSLS: Using default ROM address 0xEC000000 00EC031000: 2.1 908 00000037 00/0F type= 4 - LINK [FUNNEL: 7 in ports] 00EC032000: 1.1 912 000000A0 00/0F type= 8 - SINK PORT [TPIU] 00EC033000: 1.2 961 00001B40 00/0F type= 7 - SINK BUFFER(ETR r/w size: 4K) [TMC: ETR configuration] 00EC034000: 4.1 906 00040800 00/0F type=10 - CTI 00EC035000: 3.6 963 00010000 00/0F type= 3 - SOURCE SWSTIM(65536) [STM ext ports only, 64-bit, 128 masters] 00EC036000: 2.3 961 00000480 00/0F type= 6 - LINK SINK BUFFER(4K) [TMC: ETF configuration] 00EC037000: type=13 O TIMESTAMP 00EC038000: type=13 O TIMESTAMP
--- device crash ---<
Sorry for some late ...
Except the CPUIdle should be disabled, we also need to enable CoreSight clock; Could you try below patch for clock driver? The patch sets the CoreSight clock as critical so the kernel will turn on the clock by default:
diff --git a/drivers/clk/hisilicon/clk-hi3660.c b/drivers/clk/hisilicon/clk-hi3660.c index 5b3ad26dcc77..e2243c761871 100644 --- a/drivers/clk/hisilicon/clk-hi3660.c +++ b/drivers/clk/hisilicon/clk-hi3660.c @@ -19,7 +19,7 @@ static const struct hisi_fixed_rate_clock hi3660_fixed_rate_clks[] = { { HI3660_CLK_PPLL2, "clk_ppll2", NULL, 0, 2880000000UL, }, { HI3660_CLK_PPLL3, "clk_ppll3", NULL, 0, 1290000000, }, { HI3660_CLK_SCPLL, "clk_scpll", NULL, 0, 245760000, }, - { HI3660_PCLK, "pclk", NULL, 0, 20000000, }, + { HI3660_PCLK, "pclk", NULL, CLK_IS_CRITICAL, 20000000, }, { HI3660_CLK_UART0_DBG, "clk_uart0_dbg", NULL, 0, 19200000, }, { HI3660_CLK_UART6, "clk_uart6", NULL, 0, 19200000, }, { HI3660_OSC32K, "osc32k", NULL, 0, 32764, },
I saw you said cannot download CoreSight DT binding patch for Hikey960, so enclose the patch for reference.
Thanks, Leo Yan
I am also aware that CPUIdle must be switched off. I have a bash script that deactivates the CPUIdle settings, on top of the suggestions Leo Yan has made in the previous email.
This is the script used: # For A53 Cluster for i in 0 1 2 3; do for j in 0 1 2 ; do adb shell "echo 1 > /sys/devices/system/cpu/cpu$i/cpuidle/state$j/disable"; adb shell "echo 'cpu$i state$j disabled'"; done; done
# For A73 Cluster for i in 4 5 6 7; do for j in 0 1 2 ; do adb shell "echo 1 > /sys/devices/system/cpu/cpu$i/cpuidle/state$j/disable"; adb shell "echo 'cpu$i state$j disabled'"; done; done
adb shell "exec 3<> /dev/cpu_dma_latency; echo 0 >&3"
Hopefully I have given sufficient details and perhaps a solution can be derived.
Once again, thank you very much for the tools and assistance!
Yours Sincerely, Jeremy
From: CoreSight coresight-bounces@lists.linaro.org On Behalf Of Jeremy
Ng
Sent: 18 July 2019 04:54 To: leo.yan@linaro.org Cc: coresight@lists.linaro.org Subject: Re: Coresight Memory Mapped Addresses in Hikey960
Hi Leo Yan,
On Wed, Jul 17, 2019 at 6:04 PM Leo Yan leo.yan@linaro.org wrote:
Hi Jeremy,
On Wed, Jul 17, 2019 at 05:53:28PM +0800, Jeremy Ng wrote:
Dear Leo Yan,
I will like to ask if there are any better documentations that detail
the
memory mapped addresses for Coresight registers in Hikey960.
I am currently referring to Chapter 2-9-1 in http://mirror.lemaker.org/HiKey960_SoC_Reference_Manual.pdf. This is
all
the information about coresight addresses that I could retrieve:
0xEC000000 0xED7FFFFF 24M CSSYS_APB
As I know, the CoreSight registers address mapping is not contained in this pdf file.
Are there any other pdf files that perhaps I could have access to with all the addresses properly detailed?
Just to improve understanding of what I am trying to accomplish, I will
include
a snippet of the code from CSAL.
This is a snippet of the code that I am currently trying to write for
hikey960,
in hope that I might be able to reproduce the results for the other
example boards,
such as Juno, Snowball or TC2:
static int do_registration_juno(struct cs_devices_t *devices) { enum { A53_0, A53_1, A53_2, A53_3, A57_0, A57_1 }; cs_device_t rep, etr, etf, fun_main, fun_a53, fun_a57, stm, tpiu, sys_cti; cs_device_t r1_fun_scp, r1_fun_common, r1_etf_scp; #ifdef LIB_DEVICE_UNSUPPORTED cs_device_t r1_cti_2, ela_a53, ela_a57; #endif int i;
if (registration_verbose) printf("CSDEMO: Registering CoreSight devices...\n"); cs_register_romtable(0x20000000); if (registration_verbose) printf("CSDEMO: Registering CPU affinities...\n"); /* CTI affinities */ cs_device_set_affinity(cs_device_register(0x22020000), A57_0); cs_device_set_affinity(cs_device_register(0x22120000), A57_1); cs_device_set_affinity(cs_device_register(0x23020000), A53_0); cs_device_set_affinity(cs_device_register(0x23120000), A53_1); cs_device_set_affinity(cs_device_register(0x23220000), A53_2); cs_device_set_affinity(cs_device_register(0x23320000), A53_3); /* PMU affinities */ cs_device_set_affinity(cs_device_register(0x22030000), A57_0); cs_device_set_affinity(cs_device_register(0x22130000), A57_1); cs_device_set_affinity(cs_device_register(0x23030000), A53_0); cs_device_set_affinity(cs_device_register(0x23130000), A53_1); cs_device_set_affinity(cs_device_register(0x23230000), A53_2); cs_device_set_affinity(cs_device_register(0x23330000), A53_3); /* ETMv4 affinities */ cs_device_set_affinity(cs_device_register(0x22040000), A57_0); cs_device_set_affinity(cs_device_register(0x22140000), A57_1); cs_device_set_affinity(cs_device_register(0x23040000), A53_0); cs_device_set_affinity(cs_device_register(0x23140000), A53_1); cs_device_set_affinity(cs_device_register(0x23240000), A53_2); cs_device_set_affinity(cs_device_register(0x23340000), A53_3); if (registration_verbose) printf("CSDEMO: Registering trace-bus connections...\n"); /* funnels in clusters */ fun_a57 = cs_device_get(0x220C0000); cs_atb_register(cs_cpu_get_device(A57_0, CS_DEVCLASS_SOURCE), 0, fun_a57, 0); cs_atb_register(cs_cpu_get_device(A57_1, CS_DEVCLASS_SOURCE), 0, fun_a57, 1); fun_a53 = cs_device_get(0x230C0000); cs_atb_register(cs_cpu_get_device(A53_0, CS_DEVCLASS_SOURCE), 0, fun_a53, 0); cs_atb_register(cs_cpu_get_device(A53_1, CS_DEVCLASS_SOURCE), 0, fun_a53, 1); cs_atb_register(cs_cpu_get_device(A53_2, CS_DEVCLASS_SOURCE), 0, fun_a53, 2); cs_atb_register(cs_cpu_get_device(A53_3, CS_DEVCLASS_SOURCE), 0, fun_a53, 3); /*common setup */ fun_main = cs_device_get(0x20040000); stm = cs_device_get(0x20100000); etf = cs_device_get(0x20010000); rep = cs_device_get(0x20120000); etr = cs_device_get(0x20070000); tpiu = cs_device_get(0x20030000);
.
.
The addresses stated in the function code for Juno corresponds with the
official
Technical datasheet as found in
https://www.arm.com/files/pdf/DDI0515D1a_juno_arm_development_platform_soc_t... ,
page 3-21.
Furthermore, I realized that there are missing programmable addresses in
Hi3660 datasheet:
0xED800000 0xEFFFFFFF 40M Reserved 0xEC000000 0xED7FFFFF 24M CSSYS_APB 0xE9890000 0xE989FFFF 64K MMC0_NOC_Service_Target
As seen in the data above, there is a gap from 0xE98A0000 to 0xEBFFFFFF
I am particularly curious whether the coresight address' offset might be
consistent across different boards.
For example, CS_APB starts at 0x2100_0000 for Juno and CS_ROM is found at
0x2000_0000, 0x0100_0000 apart. I have tried to run `csls` on 0xEB00_0000
for
hikey960 but as with the previous attempts, the device crashes + there
are less info
output when probing from that address.
i.e. hikey960:/ # csls ** CSLS: listing CoreSight config... ** CSLS: Using default ROM address 0xEB000000
--- crash ---<
On the other hand, could you check if below patch is sufficient for you? In this patch, it enabled CoreSight on Hikey960 and contains the addresses for CoreSight devices.
https://archive.armlinux.org.uk/lurker/message/20190420.140035.74b936ef.en.h...
Unfortunately, I could not access this webpage from Singapore.
On another note, my hikey960 is run on Linux kernel 4.9:
hikey960:/ # uname -ar
Linux localhost 4.9.176-12953-g7c09ed7b46a4-dirty #15 SMP PREEMPT Wed Jul
17 16:53:26 +08 2019 aarch64
I will like to check if there are any datasheet for hikey960 that is
as
detailed as that for Juno device (link here:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0515b/CHDIFAD...
).
This is important to me as I am trying to acquire the device snapshot
by
using CSAL API. I am not sure if there are other ways to do this
since the
documentation hasn't been exactly straightforward.
The reason for wanting the snapshot is to possibly run openCSD and
decode
my trace binary files.
I have followed the CSAL build documentations and ran `csls` on my hikey960. The following output is seen but it crashed my device soon
after:
hikey960:/ # csls ** CSLS: listing CoreSight config... ** CSLS: Using default ROM address 0xEC000000 00EC031000: 2.1 908 00000037 00/0F type= 4 - LINK [FUNNEL: 7 in ports] 00EC032000: 1.1 912 000000A0 00/0F type= 8 - SINK PORT [TPIU] 00EC033000: 1.2 961 00001B40 00/0F type= 7 - SINK BUFFER(ETR r/w
size: 4K)
[TMC: ETR configuration] 00EC034000: 4.1 906 00040800 00/0F type=10 - CTI 00EC035000: 3.6 963 00010000 00/0F type= 3 - SOURCE SWSTIM(65536)
[STM ext
ports only, 64-bit, 128 masters] 00EC036000: 2.3 961 00000480 00/0F type= 6 - LINK SINK BUFFER(4K)
[TMC: ETF
configuration] 00EC037000: type=13 O TIMESTAMP 00EC038000: type=13 O TIMESTAMP
I will also like to understand why it might have crashed my device
during
the execution of csls.
Cool! Thanks for sharing the method.
Could you try to disable CPUidles for Hikey960? E.g. you could add 'nohlt' in the kernel command line to prevent CPU idle states. Or you could use below command:
# exec 3<> /dev/cpu_dma_latency; echo 0 >&3
Previously, I disabled cpu_idle from linux kernel menuconfig and
reflashed the kernel.
I have also made a bash script to temporarily disable cpuidle. the script
is:
#!/bin/sh
# For A53 Cluster for i in 0 1 2 3; do for j in 0 1 2 ; do echo 1 > /sys/devices/system/cpu/cpu$i/cpuidle/state$j/disable; echo 'cpu$i state$j disabled'; done; done
# For A73 Cluster for i in 4 5 6 7; do for j in 0 1 2 ; do echo 1 > /sys/devices/system/cpu/cpu$i/cpuidle/state$j/disable; echo 'cpu$i state$j disabled'; done; done
I am not sure if these methods differ from your methods, but cpuidle
in my device should have been switched off.
Nonetheless, i tried your both methods.
After the first method, my device still crash after csls command.
How I added the kernel parameters is by adding the following line
to the end of the script in
${AOSP_DIR}/device/linaro/hikey/hikey960/BoardConfig.mk:
BOARD_KERNEL_CMDLINE += nohlt
before rebuilding and reflashing the boot image into hikey960.
Output of the kernel parameters added can be found:
hikey960:/ # cat /proc/cmdline
androidboot.hardware=hikey960 firmware_class.path=/vendor/firmware
efi=noruntime init=/init androidboot.boot_devices=soc/ff3b0000.ufs loglevel=15 overlay_mgr.overlay_dt_entry=hardware_cfg_enable_android_fstab nohlt buildvariant=eng console=ttyAMA6 androidboot.serialno=2E6F5F3A0180CA83 initrd=0x7C00000,0xC2431
Unfortunately, using both methods simultaneously did not work and csls
still did not give me the full listing of the coresight components.
The output from the csls command before it crashed
remains the same as per our last email.
Thanks, Leo Yan
Thank you for your reply and assistance!
Jeremy
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.
Hi Leo Yan,
Thank you for your email!
I will test it out and update the results.
Regards, Jeremy
On Tue, Jul 23, 2019 at 9:12 AM Leo Yan leo.yan@linaro.org wrote:
Hi Jeremy,
On Mon, Jul 22, 2019 at 11:42:57AM +0800, Jeremy Ng wrote:
Hi Al,
On Fri, Jul 19, 2019 at 5:16 PM Al Grant Al.Grant@arm.com 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/discovery.m...
Al
Thank you for your email. My apologies for the late reply as I only have access to my work on weekdays.
Anyway, I have tried the coresight-tools as updated on CSAL repo.
Unfortunately, the device continues to hang at the same memory mapped address.
Just to clarify the steps I have taken:
- Since hikey960 is running on AOSP, Linux kernel 4.9, python is not
installed 2. I installed python to the device by installing Termux APK, access internet and downloaded python through `pkg install python`
- Next, i get access to root through adb and added a path to termux's
bin
files through `PATH=$PATH:/data/data/com.termux/files/usr/bin` 4. I ran `python /data/coresight-tools/csscan.py 0xEC000000`. Below shows the output for csscan and csls to show the similarites between the
outputs.
csscan.py
hikey960:/ # python /data/coresight-tools/csscan.py 0xEC000000
@0xec000000 0x327 0x000 r0.0 ROM table @0xec030000 0x000 0x000 r0.0 ROM table @0xec031000 0x23b 0x908 r2.0 funnel
in-ports:7
@0xec032000 0x23b 0x912 r4.0 port TPIU @0xec033000 0x23b 0x961 r1.0 buffer TMC:ETR memwidth:64 wb:8 @0xec034000 0x23b 0x906 r4.0 CTI
channels:4
triggers:8 @0xec035000 0x23b 0x963 r0.0 STM Arm STM rev1
ports:65536
@0xec036000 0x23b 0x961 r1.0 fifo TMC:ETF size:4096 memwidth:128 @0xec037000 0x23b 0x101 r1.0 CoreSight timestamp generator @0xec038000 0x23b 0x101 r1.0 CoreSight timestamp generator
--- device crash ---<
csls
hikey960:/ # csls ** CSLS: listing CoreSight config... ** CSLS: Using default ROM address 0xEC000000 00EC031000: 2.1 908 00000037 00/0F type= 4 - LINK [FUNNEL: 7 in ports] 00EC032000: 1.1 912 000000A0 00/0F type= 8 - SINK PORT [TPIU] 00EC033000: 1.2 961 00001B40 00/0F type= 7 - SINK BUFFER(ETR r/w size:
4K)
[TMC: ETR configuration] 00EC034000: 4.1 906 00040800 00/0F type=10 - CTI 00EC035000: 3.6 963 00010000 00/0F type= 3 - SOURCE SWSTIM(65536) [STM
ext
ports only, 64-bit, 128 masters] 00EC036000: 2.3 961 00000480 00/0F type= 6 - LINK SINK BUFFER(4K) [TMC:
ETF
configuration] 00EC037000: type=13 O TIMESTAMP 00EC038000: type=13 O TIMESTAMP
--- device crash ---<
Sorry for some late ...
Except the CPUIdle should be disabled, we also need to enable CoreSight clock; Could you try below patch for clock driver? The patch sets the CoreSight clock as critical so the kernel will turn on the clock by default:
diff --git a/drivers/clk/hisilicon/clk-hi3660.c b/drivers/clk/hisilicon/clk-hi3660.c index 5b3ad26dcc77..e2243c761871 100644 --- a/drivers/clk/hisilicon/clk-hi3660.c +++ b/drivers/clk/hisilicon/clk-hi3660.c @@ -19,7 +19,7 @@ static const struct hisi_fixed_rate_clock hi3660_fixed_rate_clks[] = { { HI3660_CLK_PPLL2, "clk_ppll2", NULL, 0, 2880000000UL, }, { HI3660_CLK_PPLL3, "clk_ppll3", NULL, 0, 1290000000, }, { HI3660_CLK_SCPLL, "clk_scpll", NULL, 0, 245760000, },
{ HI3660_PCLK, "pclk", NULL, 0, 20000000, },
{ HI3660_PCLK, "pclk", NULL, CLK_IS_CRITICAL, 20000000, }, { HI3660_CLK_UART0_DBG, "clk_uart0_dbg", NULL, 0, 19200000, }, { HI3660_CLK_UART6, "clk_uart6", NULL, 0, 19200000, }, { HI3660_OSC32K, "osc32k", NULL, 0, 32764, },
I saw you said cannot download CoreSight DT binding patch for Hikey960, so enclose the patch for reference.
Thanks, Leo Yan
I am also aware that CPUIdle must be switched off. I have a bash script
that
deactivates the CPUIdle settings, on top of the suggestions Leo Yan has
made
in the previous email.
This is the script used: # For A53 Cluster for i in 0 1 2 3; do for j in 0 1 2 ; do adb shell "echo 1 >
/sys/devices/system/cpu/cpu$i/cpuidle/state$j/disable";
adb shell "echo 'cpu$i state$j disabled'"; done; done
# For A73 Cluster for i in 4 5 6 7; do for j in 0 1 2 ; do adb shell "echo 1 >
/sys/devices/system/cpu/cpu$i/cpuidle/state$j/disable";
adb shell "echo 'cpu$i state$j disabled'"; done; done
adb shell "exec 3<> /dev/cpu_dma_latency; echo 0 >&3"
Hopefully I have given sufficient details and perhaps a solution can be derived.
Once again, thank you very much for the tools and assistance!
Yours Sincerely, Jeremy
From: CoreSight coresight-bounces@lists.linaro.org On Behalf Of
Jeremy
Ng
Sent: 18 July 2019 04:54 To: leo.yan@linaro.org Cc: coresight@lists.linaro.org Subject: Re: Coresight Memory Mapped Addresses in Hikey960
Hi Leo Yan,
On Wed, Jul 17, 2019 at 6:04 PM Leo Yan leo.yan@linaro.org wrote:
Hi Jeremy,
On Wed, Jul 17, 2019 at 05:53:28PM +0800, Jeremy Ng wrote:
Dear Leo Yan,
I will like to ask if there are any better documentations that
detail
the
memory mapped addresses for Coresight registers in Hikey960.
I am currently referring to Chapter 2-9-1 in http://mirror.lemaker.org/HiKey960_SoC_Reference_Manual.pdf. This
is
all
the information about coresight addresses that I could retrieve:
0xEC000000 0xED7FFFFF 24M CSSYS_APB
As I know, the CoreSight registers address mapping is not contained in this pdf file.
Are there any other pdf files that perhaps I could have access to with all the addresses properly detailed?
Just to improve understanding of what I am trying to accomplish, I will
include
a snippet of the code from CSAL.
This is a snippet of the code that I am currently trying to write for
hikey960,
in hope that I might be able to reproduce the results for the other
example boards,
such as Juno, Snowball or TC2:
static int do_registration_juno(struct cs_devices_t *devices) { enum { A53_0, A53_1, A53_2, A53_3, A57_0, A57_1 }; cs_device_t rep, etr, etf, fun_main, fun_a53, fun_a57, stm, tpiu, sys_cti; cs_device_t r1_fun_scp, r1_fun_common, r1_etf_scp; #ifdef LIB_DEVICE_UNSUPPORTED cs_device_t r1_cti_2, ela_a53, ela_a57; #endif int i;
if (registration_verbose) printf("CSDEMO: Registering CoreSight devices...\n"); cs_register_romtable(0x20000000); if (registration_verbose) printf("CSDEMO: Registering CPU affinities...\n"); /* CTI affinities */ cs_device_set_affinity(cs_device_register(0x22020000), A57_0); cs_device_set_affinity(cs_device_register(0x22120000), A57_1); cs_device_set_affinity(cs_device_register(0x23020000), A53_0); cs_device_set_affinity(cs_device_register(0x23120000), A53_1); cs_device_set_affinity(cs_device_register(0x23220000), A53_2); cs_device_set_affinity(cs_device_register(0x23320000), A53_3); /* PMU affinities */ cs_device_set_affinity(cs_device_register(0x22030000), A57_0); cs_device_set_affinity(cs_device_register(0x22130000), A57_1); cs_device_set_affinity(cs_device_register(0x23030000), A53_0); cs_device_set_affinity(cs_device_register(0x23130000), A53_1); cs_device_set_affinity(cs_device_register(0x23230000), A53_2); cs_device_set_affinity(cs_device_register(0x23330000), A53_3); /* ETMv4 affinities */ cs_device_set_affinity(cs_device_register(0x22040000), A57_0); cs_device_set_affinity(cs_device_register(0x22140000), A57_1); cs_device_set_affinity(cs_device_register(0x23040000), A53_0); cs_device_set_affinity(cs_device_register(0x23140000), A53_1); cs_device_set_affinity(cs_device_register(0x23240000), A53_2); cs_device_set_affinity(cs_device_register(0x23340000), A53_3); if (registration_verbose) printf("CSDEMO: Registering trace-bus connections...\n"); /* funnels in clusters */ fun_a57 = cs_device_get(0x220C0000); cs_atb_register(cs_cpu_get_device(A57_0, CS_DEVCLASS_SOURCE), 0, fun_a57, 0); cs_atb_register(cs_cpu_get_device(A57_1, CS_DEVCLASS_SOURCE), 0, fun_a57, 1); fun_a53 = cs_device_get(0x230C0000); cs_atb_register(cs_cpu_get_device(A53_0, CS_DEVCLASS_SOURCE), 0, fun_a53, 0); cs_atb_register(cs_cpu_get_device(A53_1, CS_DEVCLASS_SOURCE), 0, fun_a53, 1); cs_atb_register(cs_cpu_get_device(A53_2, CS_DEVCLASS_SOURCE), 0, fun_a53, 2); cs_atb_register(cs_cpu_get_device(A53_3, CS_DEVCLASS_SOURCE), 0, fun_a53, 3); /*common setup */ fun_main = cs_device_get(0x20040000); stm = cs_device_get(0x20100000); etf = cs_device_get(0x20010000); rep = cs_device_get(0x20120000); etr = cs_device_get(0x20070000); tpiu = cs_device_get(0x20030000);
.
.
The addresses stated in the function code for Juno corresponds with the
official
Technical datasheet as found in
https://www.arm.com/files/pdf/DDI0515D1a_juno_arm_development_platform_soc_t...
,
page 3-21.
Furthermore, I realized that there are missing programmable addresses
in
Hi3660 datasheet:
0xED800000 0xEFFFFFFF 40M Reserved 0xEC000000 0xED7FFFFF 24M CSSYS_APB 0xE9890000 0xE989FFFF 64K MMC0_NOC_Service_Target
As seen in the data above, there is a gap from 0xE98A0000 to 0xEBFFFFFF
I am particularly curious whether the coresight address' offset might
be
consistent across different boards.
For example, CS_APB starts at 0x2100_0000 for Juno and CS_ROM is found
at
0x2000_0000, 0x0100_0000 apart. I have tried to run `csls` on
0xEB00_0000
for
hikey960 but as with the previous attempts, the device crashes + there
are less info
output when probing from that address.
i.e. hikey960:/ # csls ** CSLS: listing CoreSight config... ** CSLS: Using default ROM address 0xEB000000
--- crash ---<
On the other hand, could you check if below patch is sufficient for you? In this patch, it enabled CoreSight on Hikey960 and contains the addresses for CoreSight devices.
https://archive.armlinux.org.uk/lurker/message/20190420.140035.74b936ef.en.h...
Unfortunately, I could not access this webpage from Singapore.
On another note, my hikey960 is run on Linux kernel 4.9:
hikey960:/ # uname -ar
Linux localhost 4.9.176-12953-g7c09ed7b46a4-dirty #15 SMP PREEMPT Wed
Jul
17 16:53:26 +08 2019 aarch64
I will like to check if there are any datasheet for hikey960 that
is
as
detailed as that for Juno device (link here:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0515b/CHDIFAD...
).
This is important to me as I am trying to acquire the device
snapshot
by
using CSAL API. I am not sure if there are other ways to do this
since the
documentation hasn't been exactly straightforward.
The reason for wanting the snapshot is to possibly run openCSD and
decode
my trace binary files.
I have followed the CSAL build documentations and ran `csls` on my hikey960. The following output is seen but it crashed my device
soon
after:
hikey960:/ # csls ** CSLS: listing CoreSight config... ** CSLS: Using default ROM address 0xEC000000 00EC031000: 2.1 908 00000037 00/0F type= 4 - LINK [FUNNEL: 7 in
ports]
00EC032000: 1.1 912 000000A0 00/0F type= 8 - SINK PORT [TPIU] 00EC033000: 1.2 961 00001B40 00/0F type= 7 - SINK BUFFER(ETR r/w
size: 4K)
[TMC: ETR configuration] 00EC034000: 4.1 906 00040800 00/0F type=10 - CTI 00EC035000: 3.6 963 00010000 00/0F type= 3 - SOURCE SWSTIM(65536)
[STM ext
ports only, 64-bit, 128 masters] 00EC036000: 2.3 961 00000480 00/0F type= 6 - LINK SINK BUFFER(4K)
[TMC: ETF
configuration] 00EC037000: type=13 O TIMESTAMP 00EC038000: type=13 O TIMESTAMP
I will also like to understand why it might have crashed my device
during
the execution of csls.
Cool! Thanks for sharing the method.
Could you try to disable CPUidles for Hikey960? E.g. you could add 'nohlt' in the kernel command line to prevent CPU idle states. Or
you
could use below command:
# exec 3<> /dev/cpu_dma_latency; echo 0 >&3
Previously, I disabled cpu_idle from linux kernel menuconfig and
reflashed the kernel.
I have also made a bash script to temporarily disable cpuidle. the
script
is:
#!/bin/sh
# For A53 Cluster for i in 0 1 2 3; do for j in 0 1 2 ; do echo 1 > /sys/devices/system/cpu/cpu$i/cpuidle/state$j/disable; echo 'cpu$i state$j disabled'; done; done
# For A73 Cluster for i in 4 5 6 7; do for j in 0 1 2 ; do echo 1 > /sys/devices/system/cpu/cpu$i/cpuidle/state$j/disable; echo 'cpu$i state$j disabled'; done; done
I am not sure if these methods differ from your methods, but cpuidle
in my device should have been switched off.
Nonetheless, i tried your both methods.
After the first method, my device still crash after csls command.
How I added the kernel parameters is by adding the following line
to the end of the script in
${AOSP_DIR}/device/linaro/hikey/hikey960/BoardConfig.mk:
BOARD_KERNEL_CMDLINE += nohlt
before rebuilding and reflashing the boot image into hikey960.
Output of the kernel parameters added can be found:
hikey960:/ # cat /proc/cmdline
androidboot.hardware=hikey960 firmware_class.path=/vendor/firmware
efi=noruntime init=/init androidboot.boot_devices=soc/ff3b0000.ufs loglevel=15
overlay_mgr.overlay_dt_entry=hardware_cfg_enable_android_fstab
nohlt buildvariant=eng console=ttyAMA6 androidboot.serialno=2E6F5F3A0180CA83 initrd=0x7C00000,0xC2431
Unfortunately, using both methods simultaneously did not work and csls
still did not give me the full listing of the coresight components.
The output from the csls command before it crashed
remains the same as per our last email.
Thanks, Leo Yan
Thank you for your reply and assistance!
Jeremy
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.
Hi Leo Yan,
On Tue, Jul 23, 2019 at 9:12 AM Leo Yan leo.yan@linaro.org wrote:
Hi Jeremy,
On Mon, Jul 22, 2019 at 11:42:57AM +0800, Jeremy Ng wrote:
Hi Al,
On Fri, Jul 19, 2019 at 5:16 PM Al Grant Al.Grant@arm.com 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/discovery.m...
Al
Thank you for your email. My apologies for the late reply as I only have access to my work on weekdays.
Anyway, I have tried the coresight-tools as updated on CSAL repo.
Unfortunately, the device continues to hang at the same memory mapped address.
Just to clarify the steps I have taken:
- Since hikey960 is running on AOSP, Linux kernel 4.9, python is not
installed 2. I installed python to the device by installing Termux APK, access internet and downloaded python through `pkg install python`
- Next, i get access to root through adb and added a path to termux's
bin
files through `PATH=$PATH:/data/data/com.termux/files/usr/bin` 4. I ran `python /data/coresight-tools/csscan.py 0xEC000000`. Below
shows
the output for csscan and csls to show the similarites between the
outputs.
csscan.py
hikey960:/ # python /data/coresight-tools/csscan.py 0xEC000000
@0xec000000 0x327 0x000 r0.0 ROM table @0xec030000 0x000 0x000 r0.0 ROM table @0xec031000 0x23b 0x908 r2.0 funnel
in-ports:7
@0xec032000 0x23b 0x912 r4.0 port TPIU @0xec033000 0x23b 0x961 r1.0 buffer TMC:ETR memwidth:64 wb:8 @0xec034000 0x23b 0x906 r4.0 CTI
channels:4
triggers:8 @0xec035000 0x23b 0x963 r0.0 STM Arm STM rev1
ports:65536
@0xec036000 0x23b 0x961 r1.0 fifo TMC:ETF size:4096 memwidth:128 @0xec037000 0x23b 0x101 r1.0 CoreSight timestamp generator @0xec038000 0x23b 0x101 r1.0 CoreSight timestamp generator
--- device crash ---<
csls
hikey960:/ # csls ** CSLS: listing CoreSight config... ** CSLS: Using default ROM address 0xEC000000 00EC031000: 2.1 908 00000037 00/0F type= 4 - LINK [FUNNEL: 7 in ports] 00EC032000: 1.1 912 000000A0 00/0F type= 8 - SINK PORT [TPIU] 00EC033000: 1.2 961 00001B40 00/0F type= 7 - SINK BUFFER(ETR r/w size:
4K)
[TMC: ETR configuration] 00EC034000: 4.1 906 00040800 00/0F type=10 - CTI 00EC035000: 3.6 963 00010000 00/0F type= 3 - SOURCE SWSTIM(65536) [STM
ext
ports only, 64-bit, 128 masters] 00EC036000: 2.3 961 00000480 00/0F type= 6 - LINK SINK BUFFER(4K) [TMC:
ETF
configuration] 00EC037000: type=13 O TIMESTAMP 00EC038000: type=13 O TIMESTAMP
--- device crash ---<
Sorry for some late ...
Except the CPUIdle should be disabled, we also need to enable CoreSight clock; Could you try below patch for clock driver? The patch sets the CoreSight clock as critical so the kernel will turn on the clock by default:
diff --git a/drivers/clk/hisilicon/clk-hi3660.c
b/drivers/clk/hisilicon/clk-hi3660.c
index 5b3ad26dcc77..e2243c761871 100644 --- a/drivers/clk/hisilicon/clk-hi3660.c +++ b/drivers/clk/hisilicon/clk-hi3660.c @@ -19,7 +19,7 @@ static const struct hisi_fixed_rate_clock
hi3660_fixed_rate_clks[] = {
{ HI3660_CLK_PPLL2, "clk_ppll2", NULL, 0, 2880000000UL, }, { HI3660_CLK_PPLL3, "clk_ppll3", NULL, 0, 1290000000, }, { HI3660_CLK_SCPLL, "clk_scpll", NULL, 0, 245760000, },
{ HI3660_PCLK, "pclk", NULL, 0, 20000000, },
{ HI3660_PCLK, "pclk", NULL, CLK_IS_CRITICAL, 20000000, }, { HI3660_CLK_UART0_DBG, "clk_uart0_dbg", NULL, 0, 19200000, }, { HI3660_CLK_UART6, "clk_uart6", NULL, 0, 19200000, }, { HI3660_OSC32K, "osc32k", NULL, 0, 32764, },
I saw you said cannot download CoreSight DT binding patch for Hikey960, so enclose the patch for reference.
Thanks, Leo Yan
I have applied both patches and tried the discovery tools again, both python and csls. The output from both tools are exactly the same as the previous email
I hope I have given enough details about the problems and hopefully we can devise a solution together. Unfortunately, I have no idea why this is happening. Perhaps you could direct me to look at possible areas that are causing the problems to surface.
Yours Sincerely, Jeremy
On Tue, Jul 23, 2019 at 9:12 AM Leo Yan leo.yan@linaro.org wrote:
Hi Jeremy,
On Mon, Jul 22, 2019 at 11:42:57AM +0800, Jeremy Ng wrote:
Hi Al,
On Fri, Jul 19, 2019 at 5:16 PM Al Grant Al.Grant@arm.com 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/discovery.m...
Al
Thank you for your email. My apologies for the late reply as I only have access to my work on weekdays.
Anyway, I have tried the coresight-tools as updated on CSAL repo.
Unfortunately, the device continues to hang at the same memory mapped address.
Just to clarify the steps I have taken:
- Since hikey960 is running on AOSP, Linux kernel 4.9, python is not
installed 2. I installed python to the device by installing Termux APK, access internet and downloaded python through `pkg install python`
- Next, i get access to root through adb and added a path to termux's
bin
files through `PATH=$PATH:/data/data/com.termux/files/usr/bin` 4. I ran `python /data/coresight-tools/csscan.py 0xEC000000`. Below shows the output for csscan and csls to show the similarites between the
outputs.
csscan.py
hikey960:/ # python /data/coresight-tools/csscan.py 0xEC000000
@0xec000000 0x327 0x000 r0.0 ROM table @0xec030000 0x000 0x000 r0.0 ROM table @0xec031000 0x23b 0x908 r2.0 funnel
in-ports:7
@0xec032000 0x23b 0x912 r4.0 port TPIU @0xec033000 0x23b 0x961 r1.0 buffer TMC:ETR memwidth:64 wb:8 @0xec034000 0x23b 0x906 r4.0 CTI
channels:4
triggers:8 @0xec035000 0x23b 0x963 r0.0 STM Arm STM rev1
ports:65536
@0xec036000 0x23b 0x961 r1.0 fifo TMC:ETF size:4096 memwidth:128 @0xec037000 0x23b 0x101 r1.0 CoreSight timestamp generator @0xec038000 0x23b 0x101 r1.0 CoreSight timestamp generator
--- device crash ---<
csls
hikey960:/ # csls ** CSLS: listing CoreSight config... ** CSLS: Using default ROM address 0xEC000000 00EC031000: 2.1 908 00000037 00/0F type= 4 - LINK [FUNNEL: 7 in ports] 00EC032000: 1.1 912 000000A0 00/0F type= 8 - SINK PORT [TPIU] 00EC033000: 1.2 961 00001B40 00/0F type= 7 - SINK BUFFER(ETR r/w size:
4K)
[TMC: ETR configuration] 00EC034000: 4.1 906 00040800 00/0F type=10 - CTI 00EC035000: 3.6 963 00010000 00/0F type= 3 - SOURCE SWSTIM(65536) [STM
ext
ports only, 64-bit, 128 masters] 00EC036000: 2.3 961 00000480 00/0F type= 6 - LINK SINK BUFFER(4K) [TMC:
ETF
configuration] 00EC037000: type=13 O TIMESTAMP 00EC038000: type=13 O TIMESTAMP
--- device crash ---<
Sorry for some late ...
Except the CPUIdle should be disabled, we also need to enable CoreSight clock; Could you try below patch for clock driver? The patch sets the CoreSight clock as critical so the kernel will turn on the clock by default:
diff --git a/drivers/clk/hisilicon/clk-hi3660.c b/drivers/clk/hisilicon/clk-hi3660.c index 5b3ad26dcc77..e2243c761871 100644 --- a/drivers/clk/hisilicon/clk-hi3660.c +++ b/drivers/clk/hisilicon/clk-hi3660.c @@ -19,7 +19,7 @@ static const struct hisi_fixed_rate_clock hi3660_fixed_rate_clks[] = { { HI3660_CLK_PPLL2, "clk_ppll2", NULL, 0, 2880000000UL, }, { HI3660_CLK_PPLL3, "clk_ppll3", NULL, 0, 1290000000, }, { HI3660_CLK_SCPLL, "clk_scpll", NULL, 0, 245760000, },
{ HI3660_PCLK, "pclk", NULL, 0, 20000000, },
{ HI3660_PCLK, "pclk", NULL, CLK_IS_CRITICAL, 20000000, }, { HI3660_CLK_UART0_DBG, "clk_uart0_dbg", NULL, 0, 19200000, }, { HI3660_CLK_UART6, "clk_uart6", NULL, 0, 19200000, }, { HI3660_OSC32K, "osc32k", NULL, 0, 32764, },
I saw you said cannot download CoreSight DT binding patch for Hikey960, so enclose the patch for reference.
Thanks, Leo Yan
I am also aware that CPUIdle must be switched off. I have a bash script
that
deactivates the CPUIdle settings, on top of the suggestions Leo Yan has
made
in the previous email.
This is the script used: # For A53 Cluster for i in 0 1 2 3; do for j in 0 1 2 ; do adb shell "echo 1 >
/sys/devices/system/cpu/cpu$i/cpuidle/state$j/disable";
adb shell "echo 'cpu$i state$j disabled'"; done; done
# For A73 Cluster for i in 4 5 6 7; do for j in 0 1 2 ; do adb shell "echo 1 >
/sys/devices/system/cpu/cpu$i/cpuidle/state$j/disable";
adb shell "echo 'cpu$i state$j disabled'"; done; done
adb shell "exec 3<> /dev/cpu_dma_latency; echo 0 >&3"
Hopefully I have given sufficient details and perhaps a solution can be derived.
Once again, thank you very much for the tools and assistance!
Yours Sincerely, Jeremy
From: CoreSight coresight-bounces@lists.linaro.org On Behalf Of
Jeremy
Ng
Sent: 18 July 2019 04:54 To: leo.yan@linaro.org Cc: coresight@lists.linaro.org Subject: Re: Coresight Memory Mapped Addresses in Hikey960
Hi Leo Yan,
On Wed, Jul 17, 2019 at 6:04 PM Leo Yan leo.yan@linaro.org wrote:
Hi Jeremy,
On Wed, Jul 17, 2019 at 05:53:28PM +0800, Jeremy Ng wrote:
Dear Leo Yan,
I will like to ask if there are any better documentations that
detail
the
memory mapped addresses for Coresight registers in Hikey960.
I am currently referring to Chapter 2-9-1 in http://mirror.lemaker.org/HiKey960_SoC_Reference_Manual.pdf. This
is
all
the information about coresight addresses that I could retrieve:
0xEC000000 0xED7FFFFF 24M CSSYS_APB
As I know, the CoreSight registers address mapping is not contained in this pdf file.
Are there any other pdf files that perhaps I could have access to with all the addresses properly detailed?
Just to improve understanding of what I am trying to accomplish, I will
include
a snippet of the code from CSAL.
This is a snippet of the code that I am currently trying to write for
hikey960,
in hope that I might be able to reproduce the results for the other
example boards,
such as Juno, Snowball or TC2:
static int do_registration_juno(struct cs_devices_t *devices) { enum { A53_0, A53_1, A53_2, A53_3, A57_0, A57_1 }; cs_device_t rep, etr, etf, fun_main, fun_a53, fun_a57, stm, tpiu, sys_cti; cs_device_t r1_fun_scp, r1_fun_common, r1_etf_scp; #ifdef LIB_DEVICE_UNSUPPORTED cs_device_t r1_cti_2, ela_a53, ela_a57; #endif int i;
if (registration_verbose) printf("CSDEMO: Registering CoreSight devices...\n"); cs_register_romtable(0x20000000); if (registration_verbose) printf("CSDEMO: Registering CPU affinities...\n"); /* CTI affinities */ cs_device_set_affinity(cs_device_register(0x22020000), A57_0); cs_device_set_affinity(cs_device_register(0x22120000), A57_1); cs_device_set_affinity(cs_device_register(0x23020000), A53_0); cs_device_set_affinity(cs_device_register(0x23120000), A53_1); cs_device_set_affinity(cs_device_register(0x23220000), A53_2); cs_device_set_affinity(cs_device_register(0x23320000), A53_3); /* PMU affinities */ cs_device_set_affinity(cs_device_register(0x22030000), A57_0); cs_device_set_affinity(cs_device_register(0x22130000), A57_1); cs_device_set_affinity(cs_device_register(0x23030000), A53_0); cs_device_set_affinity(cs_device_register(0x23130000), A53_1); cs_device_set_affinity(cs_device_register(0x23230000), A53_2); cs_device_set_affinity(cs_device_register(0x23330000), A53_3); /* ETMv4 affinities */ cs_device_set_affinity(cs_device_register(0x22040000), A57_0); cs_device_set_affinity(cs_device_register(0x22140000), A57_1); cs_device_set_affinity(cs_device_register(0x23040000), A53_0); cs_device_set_affinity(cs_device_register(0x23140000), A53_1); cs_device_set_affinity(cs_device_register(0x23240000), A53_2); cs_device_set_affinity(cs_device_register(0x23340000), A53_3); if (registration_verbose) printf("CSDEMO: Registering trace-bus connections...\n"); /* funnels in clusters */ fun_a57 = cs_device_get(0x220C0000); cs_atb_register(cs_cpu_get_device(A57_0, CS_DEVCLASS_SOURCE), 0, fun_a57, 0); cs_atb_register(cs_cpu_get_device(A57_1, CS_DEVCLASS_SOURCE), 0, fun_a57, 1); fun_a53 = cs_device_get(0x230C0000); cs_atb_register(cs_cpu_get_device(A53_0, CS_DEVCLASS_SOURCE), 0, fun_a53, 0); cs_atb_register(cs_cpu_get_device(A53_1, CS_DEVCLASS_SOURCE), 0, fun_a53, 1); cs_atb_register(cs_cpu_get_device(A53_2, CS_DEVCLASS_SOURCE), 0, fun_a53, 2); cs_atb_register(cs_cpu_get_device(A53_3, CS_DEVCLASS_SOURCE), 0, fun_a53, 3); /*common setup */ fun_main = cs_device_get(0x20040000); stm = cs_device_get(0x20100000); etf = cs_device_get(0x20010000); rep = cs_device_get(0x20120000); etr = cs_device_get(0x20070000); tpiu = cs_device_get(0x20030000);
.
.
The addresses stated in the function code for Juno corresponds with the
official
Technical datasheet as found in
https://www.arm.com/files/pdf/DDI0515D1a_juno_arm_development_platform_soc_t...
,
page 3-21.
Furthermore, I realized that there are missing programmable addresses
in
Hi3660 datasheet:
0xED800000 0xEFFFFFFF 40M Reserved 0xEC000000 0xED7FFFFF 24M CSSYS_APB 0xE9890000 0xE989FFFF 64K MMC0_NOC_Service_Target
As seen in the data above, there is a gap from 0xE98A0000 to 0xEBFFFFFF
I am particularly curious whether the coresight address' offset might
be
consistent across different boards.
For example, CS_APB starts at 0x2100_0000 for Juno and CS_ROM is found
at
0x2000_0000, 0x0100_0000 apart. I have tried to run `csls` on
0xEB00_0000
for
hikey960 but as with the previous attempts, the device crashes + there
are less info
output when probing from that address.
i.e. hikey960:/ # csls ** CSLS: listing CoreSight config... ** CSLS: Using default ROM address 0xEB000000
--- crash ---<
On the other hand, could you check if below patch is sufficient for you? In this patch, it enabled CoreSight on Hikey960 and contains the addresses for CoreSight devices.
https://archive.armlinux.org.uk/lurker/message/20190420.140035.74b936ef.en.h...
Unfortunately, I could not access this webpage from Singapore.
On another note, my hikey960 is run on Linux kernel 4.9:
hikey960:/ # uname -ar
Linux localhost 4.9.176-12953-g7c09ed7b46a4-dirty #15 SMP PREEMPT Wed
Jul
17 16:53:26 +08 2019 aarch64
I will like to check if there are any datasheet for hikey960 that
is
as
detailed as that for Juno device (link here:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0515b/CHDIFAD...
).
This is important to me as I am trying to acquire the device
snapshot
by
using CSAL API. I am not sure if there are other ways to do this
since the
documentation hasn't been exactly straightforward.
The reason for wanting the snapshot is to possibly run openCSD and
decode
my trace binary files.
I have followed the CSAL build documentations and ran `csls` on my hikey960. The following output is seen but it crashed my device
soon
after:
hikey960:/ # csls ** CSLS: listing CoreSight config... ** CSLS: Using default ROM address 0xEC000000 00EC031000: 2.1 908 00000037 00/0F type= 4 - LINK [FUNNEL: 7 in
ports]
00EC032000: 1.1 912 000000A0 00/0F type= 8 - SINK PORT [TPIU] 00EC033000: 1.2 961 00001B40 00/0F type= 7 - SINK BUFFER(ETR r/w
size: 4K)
[TMC: ETR configuration] 00EC034000: 4.1 906 00040800 00/0F type=10 - CTI 00EC035000: 3.6 963 00010000 00/0F type= 3 - SOURCE SWSTIM(65536)
[STM ext
ports only, 64-bit, 128 masters] 00EC036000: 2.3 961 00000480 00/0F type= 6 - LINK SINK BUFFER(4K)
[TMC: ETF
configuration] 00EC037000: type=13 O TIMESTAMP 00EC038000: type=13 O TIMESTAMP
I will also like to understand why it might have crashed my device
during
the execution of csls.
Cool! Thanks for sharing the method.
Could you try to disable CPUidles for Hikey960? E.g. you could add 'nohlt' in the kernel command line to prevent CPU idle states. Or
you
could use below command:
# exec 3<> /dev/cpu_dma_latency; echo 0 >&3
Previously, I disabled cpu_idle from linux kernel menuconfig and
reflashed the kernel.
I have also made a bash script to temporarily disable cpuidle. the
script
is:
#!/bin/sh
# For A53 Cluster for i in 0 1 2 3; do for j in 0 1 2 ; do echo 1 > /sys/devices/system/cpu/cpu$i/cpuidle/state$j/disable; echo 'cpu$i state$j disabled'; done; done
# For A73 Cluster for i in 4 5 6 7; do for j in 0 1 2 ; do echo 1 > /sys/devices/system/cpu/cpu$i/cpuidle/state$j/disable; echo 'cpu$i state$j disabled'; done; done
I am not sure if these methods differ from your methods, but cpuidle
in my device should have been switched off.
Nonetheless, i tried your both methods.
After the first method, my device still crash after csls command.
How I added the kernel parameters is by adding the following line
to the end of the script in
${AOSP_DIR}/device/linaro/hikey/hikey960/BoardConfig.mk:
BOARD_KERNEL_CMDLINE += nohlt
before rebuilding and reflashing the boot image into hikey960.
Output of the kernel parameters added can be found:
hikey960:/ # cat /proc/cmdline
androidboot.hardware=hikey960 firmware_class.path=/vendor/firmware
efi=noruntime init=/init androidboot.boot_devices=soc/ff3b0000.ufs loglevel=15
overlay_mgr.overlay_dt_entry=hardware_cfg_enable_android_fstab
nohlt buildvariant=eng console=ttyAMA6 androidboot.serialno=2E6F5F3A0180CA83 initrd=0x7C00000,0xC2431
Unfortunately, using both methods simultaneously did not work and csls
still did not give me the full listing of the coresight components.
The output from the csls command before it crashed
remains the same as per our last email.
Thanks, Leo Yan
Thank you for your reply and assistance!
Jeremy
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.
Hi Leo Yan,
My apologies for the multiple emails.
On a separate topic from coresight discovery, the new patch I have applied have resulted in failure to activate the etm drivers for tracing.
The above result can be seen here:
# echo 1 > ec036000.etf/enable_sink # echo 1 > ed440000.etm/enable_source # cat ed440000.etm/enable_source 0
I might be doing something wrong. Any guidance will be appreciated.
Sincerely, Jeremy
On Tue, Jul 23, 2019 at 9:12 AM Leo Yan leo.yan@linaro.org wrote:
Hi Jeremy,
On Mon, Jul 22, 2019 at 11:42:57AM +0800, Jeremy Ng wrote:
Hi Al,
On Fri, Jul 19, 2019 at 5:16 PM Al Grant Al.Grant@arm.com 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/discovery.m...
Al
Thank you for your email. My apologies for the late reply as I only have access to my work on weekdays.
Anyway, I have tried the coresight-tools as updated on CSAL repo.
Unfortunately, the device continues to hang at the same memory mapped address.
Just to clarify the steps I have taken:
- Since hikey960 is running on AOSP, Linux kernel 4.9, python is not
installed 2. I installed python to the device by installing Termux APK, access internet and downloaded python through `pkg install python`
- Next, i get access to root through adb and added a path to termux's
bin
files through `PATH=$PATH:/data/data/com.termux/files/usr/bin` 4. I ran `python /data/coresight-tools/csscan.py 0xEC000000`. Below shows the output for csscan and csls to show the similarites between the
outputs.
csscan.py
hikey960:/ # python /data/coresight-tools/csscan.py 0xEC000000
@0xec000000 0x327 0x000 r0.0 ROM table @0xec030000 0x000 0x000 r0.0 ROM table @0xec031000 0x23b 0x908 r2.0 funnel
in-ports:7
@0xec032000 0x23b 0x912 r4.0 port TPIU @0xec033000 0x23b 0x961 r1.0 buffer TMC:ETR memwidth:64 wb:8 @0xec034000 0x23b 0x906 r4.0 CTI
channels:4
triggers:8 @0xec035000 0x23b 0x963 r0.0 STM Arm STM rev1
ports:65536
@0xec036000 0x23b 0x961 r1.0 fifo TMC:ETF size:4096 memwidth:128 @0xec037000 0x23b 0x101 r1.0 CoreSight timestamp generator @0xec038000 0x23b 0x101 r1.0 CoreSight timestamp generator
--- device crash ---<
csls
hikey960:/ # csls ** CSLS: listing CoreSight config... ** CSLS: Using default ROM address 0xEC000000 00EC031000: 2.1 908 00000037 00/0F type= 4 - LINK [FUNNEL: 7 in ports] 00EC032000: 1.1 912 000000A0 00/0F type= 8 - SINK PORT [TPIU] 00EC033000: 1.2 961 00001B40 00/0F type= 7 - SINK BUFFER(ETR r/w size:
4K)
[TMC: ETR configuration] 00EC034000: 4.1 906 00040800 00/0F type=10 - CTI 00EC035000: 3.6 963 00010000 00/0F type= 3 - SOURCE SWSTIM(65536) [STM
ext
ports only, 64-bit, 128 masters] 00EC036000: 2.3 961 00000480 00/0F type= 6 - LINK SINK BUFFER(4K) [TMC:
ETF
configuration] 00EC037000: type=13 O TIMESTAMP 00EC038000: type=13 O TIMESTAMP
--- device crash ---<
Sorry for some late ...
Except the CPUIdle should be disabled, we also need to enable CoreSight clock; Could you try below patch for clock driver? The patch sets the CoreSight clock as critical so the kernel will turn on the clock by default:
diff --git a/drivers/clk/hisilicon/clk-hi3660.c b/drivers/clk/hisilicon/clk-hi3660.c index 5b3ad26dcc77..e2243c761871 100644 --- a/drivers/clk/hisilicon/clk-hi3660.c +++ b/drivers/clk/hisilicon/clk-hi3660.c @@ -19,7 +19,7 @@ static const struct hisi_fixed_rate_clock hi3660_fixed_rate_clks[] = { { HI3660_CLK_PPLL2, "clk_ppll2", NULL, 0, 2880000000UL, }, { HI3660_CLK_PPLL3, "clk_ppll3", NULL, 0, 1290000000, }, { HI3660_CLK_SCPLL, "clk_scpll", NULL, 0, 245760000, },
{ HI3660_PCLK, "pclk", NULL, 0, 20000000, },
{ HI3660_PCLK, "pclk", NULL, CLK_IS_CRITICAL, 20000000, }, { HI3660_CLK_UART0_DBG, "clk_uart0_dbg", NULL, 0, 19200000, }, { HI3660_CLK_UART6, "clk_uart6", NULL, 0, 19200000, }, { HI3660_OSC32K, "osc32k", NULL, 0, 32764, },
I saw you said cannot download CoreSight DT binding patch for Hikey960, so enclose the patch for reference.
Thanks, Leo Yan
I am also aware that CPUIdle must be switched off. I have a bash script
that
deactivates the CPUIdle settings, on top of the suggestions Leo Yan has
made
in the previous email.
This is the script used: # For A53 Cluster for i in 0 1 2 3; do for j in 0 1 2 ; do adb shell "echo 1 >
/sys/devices/system/cpu/cpu$i/cpuidle/state$j/disable";
adb shell "echo 'cpu$i state$j disabled'"; done; done
# For A73 Cluster for i in 4 5 6 7; do for j in 0 1 2 ; do adb shell "echo 1 >
/sys/devices/system/cpu/cpu$i/cpuidle/state$j/disable";
adb shell "echo 'cpu$i state$j disabled'"; done; done
adb shell "exec 3<> /dev/cpu_dma_latency; echo 0 >&3"
Hopefully I have given sufficient details and perhaps a solution can be derived.
Once again, thank you very much for the tools and assistance!
Yours Sincerely, Jeremy
From: CoreSight coresight-bounces@lists.linaro.org On Behalf Of
Jeremy
Ng
Sent: 18 July 2019 04:54 To: leo.yan@linaro.org Cc: coresight@lists.linaro.org Subject: Re: Coresight Memory Mapped Addresses in Hikey960
Hi Leo Yan,
On Wed, Jul 17, 2019 at 6:04 PM Leo Yan leo.yan@linaro.org wrote:
Hi Jeremy,
On Wed, Jul 17, 2019 at 05:53:28PM +0800, Jeremy Ng wrote:
Dear Leo Yan,
I will like to ask if there are any better documentations that
detail
the
memory mapped addresses for Coresight registers in Hikey960.
I am currently referring to Chapter 2-9-1 in http://mirror.lemaker.org/HiKey960_SoC_Reference_Manual.pdf. This
is
all
the information about coresight addresses that I could retrieve:
0xEC000000 0xED7FFFFF 24M CSSYS_APB
As I know, the CoreSight registers address mapping is not contained in this pdf file.
Are there any other pdf files that perhaps I could have access to with all the addresses properly detailed?
Just to improve understanding of what I am trying to accomplish, I will
include
a snippet of the code from CSAL.
This is a snippet of the code that I am currently trying to write for
hikey960,
in hope that I might be able to reproduce the results for the other
example boards,
such as Juno, Snowball or TC2:
static int do_registration_juno(struct cs_devices_t *devices) { enum { A53_0, A53_1, A53_2, A53_3, A57_0, A57_1 }; cs_device_t rep, etr, etf, fun_main, fun_a53, fun_a57, stm, tpiu, sys_cti; cs_device_t r1_fun_scp, r1_fun_common, r1_etf_scp; #ifdef LIB_DEVICE_UNSUPPORTED cs_device_t r1_cti_2, ela_a53, ela_a57; #endif int i;
if (registration_verbose) printf("CSDEMO: Registering CoreSight devices...\n"); cs_register_romtable(0x20000000); if (registration_verbose) printf("CSDEMO: Registering CPU affinities...\n"); /* CTI affinities */ cs_device_set_affinity(cs_device_register(0x22020000), A57_0); cs_device_set_affinity(cs_device_register(0x22120000), A57_1); cs_device_set_affinity(cs_device_register(0x23020000), A53_0); cs_device_set_affinity(cs_device_register(0x23120000), A53_1); cs_device_set_affinity(cs_device_register(0x23220000), A53_2); cs_device_set_affinity(cs_device_register(0x23320000), A53_3); /* PMU affinities */ cs_device_set_affinity(cs_device_register(0x22030000), A57_0); cs_device_set_affinity(cs_device_register(0x22130000), A57_1); cs_device_set_affinity(cs_device_register(0x23030000), A53_0); cs_device_set_affinity(cs_device_register(0x23130000), A53_1); cs_device_set_affinity(cs_device_register(0x23230000), A53_2); cs_device_set_affinity(cs_device_register(0x23330000), A53_3); /* ETMv4 affinities */ cs_device_set_affinity(cs_device_register(0x22040000), A57_0); cs_device_set_affinity(cs_device_register(0x22140000), A57_1); cs_device_set_affinity(cs_device_register(0x23040000), A53_0); cs_device_set_affinity(cs_device_register(0x23140000), A53_1); cs_device_set_affinity(cs_device_register(0x23240000), A53_2); cs_device_set_affinity(cs_device_register(0x23340000), A53_3); if (registration_verbose) printf("CSDEMO: Registering trace-bus connections...\n"); /* funnels in clusters */ fun_a57 = cs_device_get(0x220C0000); cs_atb_register(cs_cpu_get_device(A57_0, CS_DEVCLASS_SOURCE), 0, fun_a57, 0); cs_atb_register(cs_cpu_get_device(A57_1, CS_DEVCLASS_SOURCE), 0, fun_a57, 1); fun_a53 = cs_device_get(0x230C0000); cs_atb_register(cs_cpu_get_device(A53_0, CS_DEVCLASS_SOURCE), 0, fun_a53, 0); cs_atb_register(cs_cpu_get_device(A53_1, CS_DEVCLASS_SOURCE), 0, fun_a53, 1); cs_atb_register(cs_cpu_get_device(A53_2, CS_DEVCLASS_SOURCE), 0, fun_a53, 2); cs_atb_register(cs_cpu_get_device(A53_3, CS_DEVCLASS_SOURCE), 0, fun_a53, 3); /*common setup */ fun_main = cs_device_get(0x20040000); stm = cs_device_get(0x20100000); etf = cs_device_get(0x20010000); rep = cs_device_get(0x20120000); etr = cs_device_get(0x20070000); tpiu = cs_device_get(0x20030000);
.
.
The addresses stated in the function code for Juno corresponds with the
official
Technical datasheet as found in
https://www.arm.com/files/pdf/DDI0515D1a_juno_arm_development_platform_soc_t...
,
page 3-21.
Furthermore, I realized that there are missing programmable addresses
in
Hi3660 datasheet:
0xED800000 0xEFFFFFFF 40M Reserved 0xEC000000 0xED7FFFFF 24M CSSYS_APB 0xE9890000 0xE989FFFF 64K MMC0_NOC_Service_Target
As seen in the data above, there is a gap from 0xE98A0000 to 0xEBFFFFFF
I am particularly curious whether the coresight address' offset might
be
consistent across different boards.
For example, CS_APB starts at 0x2100_0000 for Juno and CS_ROM is found
at
0x2000_0000, 0x0100_0000 apart. I have tried to run `csls` on
0xEB00_0000
for
hikey960 but as with the previous attempts, the device crashes + there
are less info
output when probing from that address.
i.e. hikey960:/ # csls ** CSLS: listing CoreSight config... ** CSLS: Using default ROM address 0xEB000000
--- crash ---<
On the other hand, could you check if below patch is sufficient for you? In this patch, it enabled CoreSight on Hikey960 and contains the addresses for CoreSight devices.
https://archive.armlinux.org.uk/lurker/message/20190420.140035.74b936ef.en.h...
Unfortunately, I could not access this webpage from Singapore.
On another note, my hikey960 is run on Linux kernel 4.9:
hikey960:/ # uname -ar
Linux localhost 4.9.176-12953-g7c09ed7b46a4-dirty #15 SMP PREEMPT Wed
Jul
17 16:53:26 +08 2019 aarch64
I will like to check if there are any datasheet for hikey960 that
is
as
detailed as that for Juno device (link here:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0515b/CHDIFAD...
).
This is important to me as I am trying to acquire the device
snapshot
by
using CSAL API. I am not sure if there are other ways to do this
since the
documentation hasn't been exactly straightforward.
The reason for wanting the snapshot is to possibly run openCSD and
decode
my trace binary files.
I have followed the CSAL build documentations and ran `csls` on my hikey960. The following output is seen but it crashed my device
soon
after:
hikey960:/ # csls ** CSLS: listing CoreSight config... ** CSLS: Using default ROM address 0xEC000000 00EC031000: 2.1 908 00000037 00/0F type= 4 - LINK [FUNNEL: 7 in
ports]
00EC032000: 1.1 912 000000A0 00/0F type= 8 - SINK PORT [TPIU] 00EC033000: 1.2 961 00001B40 00/0F type= 7 - SINK BUFFER(ETR r/w
size: 4K)
[TMC: ETR configuration] 00EC034000: 4.1 906 00040800 00/0F type=10 - CTI 00EC035000: 3.6 963 00010000 00/0F type= 3 - SOURCE SWSTIM(65536)
[STM ext
ports only, 64-bit, 128 masters] 00EC036000: 2.3 961 00000480 00/0F type= 6 - LINK SINK BUFFER(4K)
[TMC: ETF
configuration] 00EC037000: type=13 O TIMESTAMP 00EC038000: type=13 O TIMESTAMP
I will also like to understand why it might have crashed my device
during
the execution of csls.
Cool! Thanks for sharing the method.
Could you try to disable CPUidles for Hikey960? E.g. you could add 'nohlt' in the kernel command line to prevent CPU idle states. Or
you
could use below command:
# exec 3<> /dev/cpu_dma_latency; echo 0 >&3
Previously, I disabled cpu_idle from linux kernel menuconfig and
reflashed the kernel.
I have also made a bash script to temporarily disable cpuidle. the
script
is:
#!/bin/sh
# For A53 Cluster for i in 0 1 2 3; do for j in 0 1 2 ; do echo 1 > /sys/devices/system/cpu/cpu$i/cpuidle/state$j/disable; echo 'cpu$i state$j disabled'; done; done
# For A73 Cluster for i in 4 5 6 7; do for j in 0 1 2 ; do echo 1 > /sys/devices/system/cpu/cpu$i/cpuidle/state$j/disable; echo 'cpu$i state$j disabled'; done; done
I am not sure if these methods differ from your methods, but cpuidle
in my device should have been switched off.
Nonetheless, i tried your both methods.
After the first method, my device still crash after csls command.
How I added the kernel parameters is by adding the following line
to the end of the script in
${AOSP_DIR}/device/linaro/hikey/hikey960/BoardConfig.mk:
BOARD_KERNEL_CMDLINE += nohlt
before rebuilding and reflashing the boot image into hikey960.
Output of the kernel parameters added can be found:
hikey960:/ # cat /proc/cmdline
androidboot.hardware=hikey960 firmware_class.path=/vendor/firmware
efi=noruntime init=/init androidboot.boot_devices=soc/ff3b0000.ufs loglevel=15
overlay_mgr.overlay_dt_entry=hardware_cfg_enable_android_fstab
nohlt buildvariant=eng console=ttyAMA6 androidboot.serialno=2E6F5F3A0180CA83 initrd=0x7C00000,0xC2431
Unfortunately, using both methods simultaneously did not work and csls
still did not give me the full listing of the coresight components.
The output from the csls command before it crashed
remains the same as per our last email.
Thanks, Leo Yan
Thank you for your reply and assistance!
Jeremy
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.
Hi Jeremy,
On Tue, Jul 23, 2019 at 02:14:00PM +0800, Jeremy Ng wrote:
Hi Leo Yan,
My apologies for the multiple emails.
It's no matter.
On a separate topic from coresight discovery, the new patch I have applied have resulted in failure to activate the etm drivers for tracing.
The above result can be seen here:
# echo 1 > ec036000.etf/enable_sink # echo 1 > ed440000.etm/enable_source # cat ed440000.etm/enable_source 0
I might be doing something wrong. Any guidance will be appreciated.
I think you have missed some patches for DT binding. Please see enclosed tar file which contains the DT binding.
After download it, you could use below command to apply them on the git tree:
$ tar zxvf cs_dt_binding.tgz $ cd $kernel $ git am $path/to/cs_dt_binding/*
Could you confirm you are using which kernel versio (4.14 or 4.19)?
Thanks, Leo Yan
Hi Leo Yan,
On Tue, Jul 23, 2019 at 9:12 PM Leo Yan leo.yan@linaro.org wrote:
Hi Jeremy,
On Tue, Jul 23, 2019 at 02:14:00PM +0800, Jeremy Ng wrote:
Hi Leo Yan,
My apologies for the multiple emails.
It's no matter.
On a separate topic from coresight discovery, the new patch I have applied have resulted in failure to activate the etm drivers for tracing.
The above result can be seen here:
# echo 1 > ec036000.etf/enable_sink # echo 1 > ed440000.etm/enable_source # cat ed440000.etm/enable_source 0
I might be doing something wrong. Any guidance will be appreciated.
I think you have missed some patches for DT binding. Please see enclosed tar file which contains the DT binding.
After download it, you could use below command to apply them on the git tree:
$ tar zxvf cs_dt_binding.tgz $ cd $kernel $ git am $path/to/cs_dt_binding/*
Could you confirm you are using which kernel versio (4.14 or 4.19)?
Thanks, Leo Yan
Thank you for the tar file. Unfortunately I can only try the changes when I return to office in 11 hours time.
I am actually using kernel version 4.9 as based on the AOSP reco, https://source.android.com/setup/build/devices I will try using 4.19, if that is the preferred version.
As always, thank you very much for your patience and guidance. I will update the outcome once I try out on the device later.
Cheers, Jeremy
Hi Leo Yan,
On Tue, Jul 23, 2019 at 9:12 PM Leo Yan leo.yan@linaro.org wrote:
Hi Jeremy,
On Tue, Jul 23, 2019 at 02:14:00PM +0800, Jeremy Ng wrote:
Hi Leo Yan,
My apologies for the multiple emails.
It's no matter.
On a separate topic from coresight discovery, the new patch I have
applied
have resulted in failure to activate the etm drivers for tracing.
The above result can be seen here:
# echo 1 > ec036000.etf/enable_sink # echo 1 > ed440000.etm/enable_source # cat ed440000.etm/enable_source 0
I might be doing something wrong. Any guidance will be appreciated.
I think you have missed some patches for DT binding. Please see enclosed tar file which contains the DT binding.
After download it, you could use below command to apply them on the git tree:
$ tar zxvf cs_dt_binding.tgz $ cd $kernel $ git am $path/to/cs_dt_binding/*
Could you confirm you are using which kernel versio (4.14 or 4.19)?
I am currently using the kernel source from https://android.googlesource.com/kernel/hikey-linaro/+/refs/heads/android-hi...
However, when I tried to apply the patches, all the patches have failed. the output log is as follows:
# git am /home/jem/Downloads/cs_dt_binding/* Applying: dt-bindings: arm: coresight: Add new compatible for static replicator error: Documentation/devicetree/bindings/arm/coresight.txt: does not match index Patch failed at 0001 dt-bindings: arm: coresight: Add new compatible for static replicator Use 'git am --show-current-patch' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". # git am --skip Applying: coresight: replicator: Add new device id for static replicator error: patch failed: drivers/hwtracing/coresight/coresight-replicator.c:189 error: drivers/hwtracing/coresight/coresight-replicator.c: patch does not apply Patch failed at 0002 coresight: replicator: Add new device id for static replicator Use 'git am --show-current-patch' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". # git am --skip Applying: dt-bindings: arm: coresight: Unify funnel DT binding error: Documentation/devicetree/bindings/arm/coresight.txt: does not match index Patch failed at 0003 dt-bindings: arm: coresight: Unify funnel DT binding Use 'git am --show-current-patch' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". # git am --skip Applying: coresight: funnel: Support static funnel error: patch failed: drivers/hwtracing/coresight/coresight-funnel.c:43 error: drivers/hwtracing/coresight/coresight-funnel.c: patch does not apply Patch failed at 0004 coresight: funnel: Support static funnel Use 'git am --show-current-patch' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
When I try to manually patch the files, i realized that the line numbers that indicated changes are vastly different from my original files.
(i.e. Patch log ======= --- a/drivers/hwtracing/coresight/coresight-replicator.c +++ b/drivers/hwtracing/coresight/coresight-replicator.c @@ -189,6 +189,9 @@ static int replicator_probe(struct device *dev, struct resource *res) dev->platform_data = pdata; }
+ if (of_device_is_compatible(np, "arm,coresight-replicator")) + pr_warn_once("Uses OBSOLETE CoreSight replicator binding\n"); + drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL); if (!drvdata) return -ENOMEM;
Actual file line ===========
from line 66 to 73 static int replicator_probe(struct platform_device *pdev) { int ret; struct device *dev = &pdev->dev; struct coresight_platform_data *pdata = NULL; struct replicator_drvdata *drvdata; struct coresight_desc desc = { 0 }; struct device_node *np = pdev->dev.of_node; . . }
I realized that there might be several changes prior to your patch that I might have missed out and are not pushed to upstream.
Thanks, Leo Yan
Please assist!
Regards, Jeremy
Hi Jeremy,
On Tue, Jul 23, 2019 at 02:14:00PM +0800, Jeremy Ng wrote:
Hi Leo Yan,
My apologies for the multiple emails.
On a separate topic from coresight discovery, the new patch I have applied have resulted in failure to activate the etm drivers for tracing.
The above result can be seen here:
# echo 1 > ec036000.etf/enable_sink # echo 1 > ed440000.etm/enable_source # cat ed440000.etm/enable_source 0
I checked the AOSP kernel 4.14 and 4.19, the kernel 4.14 [1] has enabled the CoreSight for Hikey960 yet; so I suggest you could directly use this branch as the first step (And please ignore my shared patches since all Hi3660 CoreSight patches have been merged into AOSP 4.14 kernel).
I tested the kernel 4.14 with below commands and it does can work well:
# exec 3<> /dev/cpu_dma_latency; echo 0 >&3 # echo 1 > ec036000.etf/enable_sink # echo 1 > ed440000.etm/enable_source # cat ed440000.etm/enable_source 1
Please note, at my side I use the open sourced bootloaders (UEFI + ARM-TF); this might be a difference when you flash booting images, which uses the Hisilicon legacy booting images (if you don't see UEFI booting logs). Suggest you could try up commands firstly, if still fail I'd like to suggest you to reflash booting images by following the steps in the page [2], which uses the booting images from [3].
As a side topic, in case you are interested in Debian distro, you could see the detailed info for Debian installation on Hikey960 [4].
Thanks, Leo Yan
[1] https://android.googlesource.com/kernel/hikey-linaro/+/refs/heads/android-hi... [2] https://www.96boards.org/documentation/consumer/hikey/hikey960/installation/... [3] http://snapshots.linaro.org/reference-platform/components/uefi-staging/lates... [4] https://www.96boards.org/documentation/consumer/hikey/hikey960/downloads/Deb...
Hi Leo Yan,
On Wed, Jul 24, 2019 at 1:35 PM Leo Yan leo.yan@linaro.org wrote:
Hi Jeremy,
On Tue, Jul 23, 2019 at 02:14:00PM +0800, Jeremy Ng wrote:
Hi Leo Yan,
My apologies for the multiple emails.
On a separate topic from coresight discovery, the new patch I have applied have resulted in failure to activate the etm drivers for tracing.
The above result can be seen here:
# echo 1 > ec036000.etf/enable_sink # echo 1 > ed440000.etm/enable_source # cat ed440000.etm/enable_source 0
I checked the AOSP kernel 4.14 and 4.19, the kernel 4.14 [1] has enabled the CoreSight for Hikey960 yet; so I suggest you could directly use this branch as the first step (And please ignore my shared patches since all Hi3660 CoreSight patches have been merged into AOSP 4.14 kernel).
I tested the kernel 4.14 with below commands and it does can work well:
# exec 3<> /dev/cpu_dma_latency; echo 0 >&3 # echo 1 > ec036000.etf/enable_sink # echo 1 > ed440000.etm/enable_source # cat ed440000.etm/enable_source 1
I had access to coresight previously already.
I wanted to use the coresight discovery tools to create device snapshot + coresight trace + coresight configurations. I am not sure if CSAL is the tool to do that, but it appears to be made to do that. After which, I intended to perform full trace decode using OpenCSD.
I am actually fine with not performing full trace decode, just trace protocol/packet decode.
However, the demo in openCSD only shows how to perform full trace decode with proper snapshots. I might be wrong, but I have been looking at the docs all over the place. Some guidance is appreciated here!
Please note, at my side I use the open sourced bootloaders (UEFI + ARM-TF); this might be a difference when you flash booting images, which uses the Hisilicon legacy booting images (if you don't see UEFI booting logs). Suggest you could try up commands firstly, if still fail I'd like to suggest you to reflash booting images by following the steps in the page [2], which uses the booting images from [3].
As a side topic, in case you are interested in Debian distro, you could see the detailed info for Debian installation on Hikey960 [4].
Thanks, Leo Yan
Unfortunately, I do not have a UART tool available to run a Debian distro on hikey960 right now.
As much as I want to use a Debian distro, I am unfortunately impeded by the lack of tools.
If anyone has any other methods to perform full trace decoding without the use of Perf, it will also be highly appreciated!
Details of device: Hikey960 (Cortex-A53 (4 cpu) + Cortex-A73 (4 cpu)) --> ETMv4 data tracing not supported AOSP - linux kernel 4.14
[1] https://android.googlesource.com/kernel/hikey-linaro/+/refs/heads/android-hi... [2] https://www.96boards.org/documentation/consumer/hikey/hikey960/installation/... [3] http://snapshots.linaro.org/reference-platform/components/uefi-staging/lates... [4] https://www.96boards.org/documentation/consumer/hikey/hikey960/downloads/Deb...
Thank you for your guidance, as always!
Yours Sincerely, Jeremy
Hi Jeremy,
On Wed, Jul 24, 2019 at 03:54:52PM +0800, Jeremy Ng wrote:
[...]
I wanted to use the coresight discovery tools to create device snapshot
- coresight trace + coresight configurations. I am not sure if CSAL is the
tool to do that, but it appears to be made to do that. After which, I intended to perform full trace decode using OpenCSD.
I don't think this is blocking issue. We can get the CoreSight topology and registers base address from CSAL, or from the DT binding file. Before I used the DT binding info to extract info to create OpenCSD snapshot configuration files.
I am actually fine with not performing full trace decode, just trace protocol/packet decode.
However, the demo in openCSD only shows how to perform full trace decode with proper snapshots. I might be wrong, but I have been looking at the docs all over the place. Some guidance is appreciated here!
The one important thing is to generate the snapshot files, which is used to tell decoder the hardware topology; so I think the spec [1] is very useful. You also could refer some existed snapshot files [2][3].
Please note, at my side I use the open sourced bootloaders (UEFI + ARM-TF); this might be a difference when you flash booting images, which uses the Hisilicon legacy booting images (if you don't see UEFI booting logs). Suggest you could try up commands firstly, if still fail I'd like to suggest you to reflash booting images by following the steps in the page [2], which uses the booting images from [3].
As a side topic, in case you are interested in Debian distro, you could see the detailed info for Debian installation on Hikey960 [4].
Thanks, Leo Yan
Unfortunately, I do not have a UART tool available to run a Debian distro on hikey960 right now.
You could buy a UART-serial Mezzanine board [4] which is compatible with 96boards for UART output.
As much as I want to use a Debian distro, I am unfortunately impeded by the lack of tools.
If anyone has any other methods to perform full trace decoding without the use of Perf, it will also be highly appreciated!
Details of device: Hikey960 (Cortex-A53 (4 cpu) + Cortex-A73 (4 cpu)) --> ETMv4 data tracing not supported AOSP - linux kernel 4.14
Thanks, Leo Yan
[1] https://github.com/Linaro/OpenCSD/blob/master/decoder/docs/specs/ARM%20Trace... [2] https://github.com/Linaro/OpenCSD/tree/master/decoder/tests/snapshots/juno-u... [3] http://people.linaro.org/~leo.yan/opencsd_hikey/hikey_snapshot.tgz [4] https://www.96boards.org/product/uartserial/
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/discovery.m...
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.
I also force 'check=True' for write operations so want to add a read-after-write barrier but actually this is not very useful.
@Al, not sure if the patch can provide any useful code which can be picked or not?
- 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; 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
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.
Hi Al,
On Fri, Jul 26, 2019 at 10:27:30AM +0000, Al Grant wrote:
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.
You are welcome and thanks for the enhancements.
- 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?
Here does single-socket mean single cluster?
Hikey960 have two clusters: CA53x4 and CA73x4 CPUs; And I saw two timestamp blocks:
@0xec037000 0x23b 0x101 r1.0 CoreSight timestamp generator @0xec038000 0x23b 0x101 r1.0 CoreSight timestamp generator
The aborts happen for the second timestamp block.
Thanks, Leo Yan
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.
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?
Here does single-socket mean single cluster?
No, a multi-cluster system would still typically only have one timestamp generator. Or if it had two, it might have e.g. one for Non-Secure and one for Secure (e.g. for tracing the Cortex-M processors that do all the boot and management stuff we don't see), or maybe one for trace and one for the global time as seen by Linux. At any rate we would not expect timestamp generators to be repeated per cluster of application cores - they are global by nature.
For a physically multi-die system (multi-socket, or these days, multi-chiplet) you would expect one set of everything per die, including timestamp generators per die. This would be in server class systems (almost certainly using ACPI rather than DTS). On such a system the global memory map might have separate ranges for the components for each die, and we would expect timestamp generators in there along with everything else. The system should appear as if it had a single root ROM table that directly or indirectly represented the whole system. We are only just starting to get into self-hosted trace on such systems but we do need to think about it. E.g. it is unlikely trace will be sent between dies, so there will be (at least) one trace sink per die.
Hikey960 have two clusters: CA53x4 and CA73x4 CPUs; And I saw two timestamp blocks:
@0xec037000 0x23b 0x101 r1.0 CoreSight timestamp generator @0xec038000 0x23b 0x101 r1.0 CoreSight timestamp generator
The aborts happen for the second timestamp block.
Ok, that might indicate it's reserved for Secure use. Or it might mean something else... hopefully it's possible to work around by excluding that address.
I don't believe there is any way, in general, of doing a self-hosted discovery via ROM table, that does not carry the risk of having to repeatedly deal with lockups and resets, and add addresses to be explicitly excluded.
What I could do, is automate this in csscan.py - i.e. maintain a continual snapshot of what we're trying to access, and if you run it again after a crash it would spot what you were trying to access and automatically exclude it.
Al
Thanks, Leo Yan
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.
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.
Hi Al and Leo yan,
Thank you very much to both of you for your patient and assistance!
All the input ideas have worked in my hikey960.
Thank you!
Regards, Jeremy
On Fri, Jul 26, 2019 at 7:28 PM Al Grant Al.Grant@arm.com wrote:
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?
Here does single-socket mean single cluster?
No, a multi-cluster system would still typically only have one timestamp generator. Or if it had two, it might have e.g. one for Non-Secure and one for Secure (e.g. for tracing the Cortex-M processors that do all the boot and management stuff we don't see), or maybe one for trace and one for the global time as seen by Linux. At any rate we would not expect timestamp generators to be repeated per cluster of application cores - they are global by nature.
For a physically multi-die system (multi-socket, or these days, multi-chiplet) you would expect one set of everything per die, including timestamp generators per die. This would be in server class systems (almost certainly using ACPI rather than DTS). On such a system the global memory map might have separate ranges for the components for each die, and we would expect timestamp generators in there along with everything else. The system should appear as if it had a single root ROM table that directly or indirectly represented the whole system. We are only just starting to get into self-hosted trace on such systems but we do need to think about it. E.g. it is unlikely trace will be sent between dies, so there will be (at least) one trace sink per die.
Hikey960 have two clusters: CA53x4 and CA73x4 CPUs; And I saw two timestamp blocks:
@0xec037000 0x23b 0x101 r1.0 CoreSight timestamp generator @0xec038000 0x23b 0x101 r1.0 CoreSight timestamp generator
The aborts happen for the second timestamp block.
Ok, that might indicate it's reserved for Secure use. Or it might mean something else... hopefully it's possible to work around by excluding that address.
I don't believe there is any way, in general, of doing a self-hosted discovery via ROM table, that does not carry the risk of having to repeatedly deal with lockups and resets, and add addresses to be explicitly excluded.
What I could do, is automate this in csscan.py - i.e. maintain a continual snapshot of what we're trying to access, and if you run it again after a crash it would spot what you were trying to access and automatically exclude it.
Al
Thanks, Leo Yan
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.
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.