Part Number: AM5728
Tool/software: Linux
Hi there,
I'm working with Linux processor-sdk 05.02.00.10 and RTOS processor-sdk 4.03.00.05.
I successfully worked with jailhouse hypervisor on the AM5728 evaluation board.
Now I'm trying to startup jailhouse on a AM5728 based custom board.
I can startup my SYS/BIOS inmate application and debug it. During the init phase I get the famous dump from the kernel:
[ 147.605931] ------------[ cut here ]------------
[ 147.610600] WARNING: CPU: 0 PID: 28 at /home/stx-ti/Projects/tisdk/build/arago-tmp-external-linaro-toolchain/work-shared/am57xx-evm/kernel-source/drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x254/0x370
[ 147.629222] 44000000.ocp:L3 Custom Error: MASTER MPU TARGET GPMC(Read): Data Access in User mode during Functional access
[ 147.640328] Modules linked in: jailhouse(O) vnetdevice(O) sha512_generic sha512_arm sha256_generic sha1_generic sha1_arm md5 cbc xhci_plat_hcd xhci_hcd usbcore dwc3 udc_core usb_common ti_prueth pru_rproc pruss pruss_intc snd_soc_omap_hdmi_audio omap_aes_driver pruss_soc_bus c_can_platform c_can can_dev omap_sham omap_wdt phy_omap_usb2 ahci_platform libahci_platform libahci libata scsi_mod ti_vpe ti_vip ti_sc ti_csc ti_vpdma dwc3_omap rtc_omap extcon_palmas rtc_palmas gpio_tpic2810 ov2659 v4l2_fwnode omap_des des_generic crypto_engine omap_crypto omap_remoteproc virtio_rpmsg_bus rpmsg_core remoteproc sch_fq_codel cryptodev(O)
[ 147.696164] CPU: 0 PID: 28 Comm: irq/23-l3-app-i Tainted: G O 4.14.79-rt47-gd9200ca684 #9
[ 147.696167] Hardware name: Generic DRA74X (Flattened Device Tree)
[ 147.696169] Backtrace:
[ 147.696187] [<c010b808>] (dump_backtrace) from [<c010baec>] (show_stack+0x18/0x1c)
[ 147.696194] r7:00000009 r6:60030013 r5:00000000 r4:c0d575a0
[ 147.696204] [<c010bad4>] (show_stack) from [<c082245c>] (dump_stack+0x90/0xa4)
[ 147.696215] [<c08223cc>] (dump_stack) from [<c012aea0>] (__warn+0xec/0x104)
[ 147.696220] r7:00000009 r6:c0ad5790 r5:00000000 r4:d4a31e40
[ 147.696229] [<c012adb4>] (__warn) from [<c012aef8>] (warn_slowpath_fmt+0x40/0x48)
[ 147.696234] r9:0000000b r8:d4a14b10 r7:c0ad55fc r6:00000002 r5:c0ad56bc r4:c0ad5760
[ 147.696243] [<c012aebc>] (warn_slowpath_fmt) from [<c041e108>] (l3_interrupt_handler+0x254/0x370)
[ 147.696246] r3:d4a14980 r2:c0ad5760
[ 147.696249] r4:80080003
[ 147.696258] [<c041deb4>] (l3_interrupt_handler) from [<c0181dd8>] (irq_forced_thread_fn+0x28/0x7c)
[ 147.696263] r10:c0181db0 r9:d4a14e80 r8:d49df100 r7:00000001 r6:00000000 r5:d49df100
[ 147.696265] r4:d4a14e80
[ 147.696272] [<c0181db0>] (irq_forced_thread_fn) from [<c0182130>] (irq_thread+0x130/0x208)
[ 147.696276] r7:00000001 r6:00000000 r5:ffffe000 r4:d4a14ea4
[ 147.696284] [<c0182000>] (irq_thread) from [<c0149368>] (kthread+0x164/0x16c)
[ 147.696289] r10:d4871b20 r9:c0182000 r8:d4a14e80 r7:d4a30000 r6:00000000 r5:d4a14ec0
[ 147.696291] r4:d49e3080
[ 147.696299] [<c0149204>] (kthread) from [<c0107a90>] (ret_from_fork+0x14/0x24)
[ 147.696303] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c0149204
[ 147.696306] r4:d4a14ec0
[ 147.696308] ---[ end trace 0000000000000002 ]---
Specifically this dump is generated when SPI_open() goes down all the way to McSPIReset(), which attempts to read and write McSPI4 register MCSPI_SYSSTATUS(0x480BA114).
Additionally when the error is generated GPMC related registers are set to:
GPMC_ERR_ADDRESS (0x50000044) = 0x0480B110
GPMC_ERR_TYPE (0x50000048) = 0x00000211
Previously I made sure that ALL the SPI's are disabled in the Linux kernel dts, and SPI is disabled in the kernel config, so I'm trying to figure out what causes this error.
Going through AM572x_Sitara_Processors_Technical_Reference_Manual, L3_MAIN Interconnect (fascinating stuff) I found out that a configurable firewall exists, and
an interrupt is generated to the Cortex-A15 INTC upon protection violation. (14.2.3.7.3.4 L3_MAIN Firewall Error Logging)
I suspect the firewall needs to be configured to allow user access, but I'm not sure where and how.
I also don't understand why an attempt to read a SPI related register causes an error in GPMC.
In attempt to prevent the interrupt, setting the GPMC_FW registers
GPMC_FW_START_REGION_i_1 (0x4A210090) = 0x480BA000
GPMC_FW_END_REGION_i_1 (0x4A210094) = 0x480BB000
didn't change the behavior.
Can you please explain why SPI is related to GPMC, and more important how can I configure the firewall to allow user access to SPI registers?
Thanks a lot,
Nir.