cleverca22
Posts: 1324
Joined: Sat Aug 18, 2012 2:33 pm

HVS permission issues, MMIO appears to be readonly

Sat Sep 19, 2020 1:18 am

is there some undocumented register to deny the ARM write access to peripherals like the HVS?

under linux:

Code: Select all

[    3.977719] gpiomem-bcm2835 3f200000.gpiomem: Initialised: Registers at 0x3f200000
[    3.985478] vc4_drm_register
[    3.990284] vc4-drm soc:gpu: vc4_platform_drm_probe
[    3.996534] OF: graph: no port node found in /soc/dpi@7e208000
[    4.002430] vc4-drm soc:gpu: bound 3f208000.dpi (ops vc4_dpi_ops)
[    4.008581] vc4_hvs 3f400000.hvs: hvs: 0xcf7ccc40
[    4.013299] [drm] vc4: 0xcf7cc840
[    4.016614] [drm] 0x0000 (SCALER_DISPCTRL): 0x80080000
[    4.021773] [drm] 0x0004 (SCALER_DISPSTAT): 0x00000020
[    4.026910] [drm] 0x0008 (SCALER_DISPID): 0x64647276
[    4.031893] [drm] 0x000c (SCALER_DISPECTRL): 0x813f0000
[    4.037116] [drm] 0x0010 (SCALER_DISPPROF): 0x00000000
[    4.042272] [drm] 0x0014 (SCALER_DISPDITHER): 0x00000000
[    4.047601] [drm] 0x0018 (SCALER_DISPEOLN): 0x00000000
[    4.052737] [drm] 0x0020 (SCALER_DISPLIST0): 0x00000000
[    4.057979] [drm] 0x0024 (SCALER_DISPLIST1): 0x00000000
[    4.063201] [drm] 0x0028 (SCALER_DISPLIST2): 0x00000000
[    4.068443] [drm] 0x002c (SCALER_DISPLSTAT): 0x30000000
[    4.073666] [drm] 0x0030 (SCALER_DISPLACT0): 0x00000000
[    4.078907] [drm] 0x0034 (SCALER_DISPLACT1): 0x00000000
[    4.084130] [drm] 0x0038 (SCALER_DISPLACT2): 0x00000000
[    4.089370] [drm] 0x0040 (SCALER_DISPCTRL0): 0x00000000
[    4.094593] [drm] 0x0044 (SCALER_DISPBKGND0): 0x00000000
[    4.099921] [drm] 0x0048 (SCALER_DISPSTAT0): 0x10000000
[    4.105144] [drm] 0x004c (SCALER_DISPBASE0): 0x00000000
[    4.110385] [drm] 0x0050 (SCALER_DISPCTRL1): 0x00000000
[    4.115608] [drm] 0x0054 (SCALER_DISPBKGND1): 0x00000000
[    4.120936] [drm] 0x0058 (SCALER_DISPSTAT1): 0x10000000
[    4.126158] [drm] 0x005c (SCALER_DISPBASE1): 0x00000000
[    4.131400] [drm] 0x0060 (SCALER_DISPCTRL2): 0x00000000
[    4.136622] [drm] 0x0064 (SCALER_DISPBKGND2): 0x00000000
[    4.141950] [drm] 0x0068 (SCALER_DISPSTAT2): 0x10000000
[    4.147192] [drm] 0x006c (SCALER_DISPBASE2): 0x00000000
[    4.152414] [drm] 0x0070 (SCALER_DISPALPHA2): 0x000000ff
[    4.157743] [drm] 0x0080 (SCALER_OLEDOFFS): 0x00000000
[    4.162878] [drm] 0x0084 (SCALER_OLEDCOEF0): 0x00000000
[    4.168120] [drm] 0x0088 (SCALER_OLEDCOEF1): 0x00000000
[    4.173342] [drm] 0x008c (SCALER_OLEDCOEF2): 0x00000000
[    4.178580] [drm] HVS ctx:
[    4.181291] [drm] 0x00000000 (B): 0xda11643b 0x1b04cd17 0x3811b2c7 0x8661bfdf
[    4.188445] [drm] 0x00000010 (B): 0xc4bc041b 0xe0bbfbb4 0x8a36af98 0xaea4b98f
[    4.195580] [drm] 0x00000020 (B): 0x300f7475 0xfff0ffbd 0x6c62fa2a 0x9babfae1
[    4.202733] [drm] 0x00000030 (B): 0x49956a5c 0xeecc9fdd 0xb546c4c8 0x7e62dc46
[    4.209887] [drm] 0x00000040 (B): 0x8e0f9990 0x3aa6caeb 0x3557ee08 0x37d02fb5
[    4.217021] [drm] 0x00000050 (B): 0x89c7c667 0xae0fd492 0xaff1e859 0x9481e8fe
[    4.224174] [drm] 0x00000060 (B): 0xf416c55c 0xe279474c 0xde44b914 0x4e9b32e4
[    4.231328] [drm] 0x00000070 (B): 0x908a979b 0x66dc1952 0x1a63fb00 0x7d899e65
[    4.238482] [drm] 0x00000080 (D): 0x8f387e3e 0x0047f2c5 0xf0054ff2 0x95713b2f
[    4.245616] [drm] 0x00000090 (D): 0x2b7b0800 0x6763d524 0x50675564 0x21c0f4e9
[    4.252770] [drm] 0x000000a0 (D): 0x1e50c832 0x364d97d5 0xe0df0b84 0x9d4274bd
[    4.259924] [drm] 0x000000b0 (D): 0x1c93f5d6 0x8af5bc9a 0x758e96f0 0xa6d76d5c
[    4.267058] [drm] 0x000000c0 (D): 0x5a15680f 0x39f32a83 0x373871ac 0xcdd4e2d8
[    4.274212] [drm] 0x000000d0 (D): 0x82951b77 0xa4d8eeb8 0x0515e491 0x2c42d679
[    4.281365] [drm] 0x000000e0 (D): 0xf7afc5a1 0x185bbe7d 0x7fb3585e 0x8c0ebc84
[    4.288518] [drm] 0x000000f0 (D): 0x382119b0 0x2e7febd0 0xf79da7d8 0xacad2482
[    4.295653] vc4_hvs 3f400000.hvs: a
[    4.299163] vc4_hvs 3f400000.hvs: b
[    4.302652] vc4_hvs 3f400000.hvs: c
[    4.306141] vc4_hvs 3f400000.hvs: d
[    4.309651] vc4_hvs 3f400000.hvs: setting SCALER_DISPCTRL to 0x80080000
[    4.316265] Unhandled fault: imprecise external abort (0x1c06) at 0x00000000
[    4.323307] pgd = (ptrval)
[    4.326011] [00000000] *pgd=00000000
[    4.329593] Internal error: : 1c06 [#1] SMP ARM
[    4.334121] Modules linked in:
[    4.337181] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.19.89-v7+ #84
[    4.343615] Hardware name: BCM2835
[    4.347023] PC is at vc4_hvs_bind+0x158/0x160 
[    4.351381] LR is at vprintk_emit+0x234/0x364 
[    4.355735] pc : [<c05aa7e8>]    lr : [<c018565c>]    psr: 60000053
[    4.361997] sp : cf4f9c50  ip : cf4f9ad0  fp : cf4f9c7c
[    4.367218] r10: cf788000  r9 : 00000000  r8 : 00018000
[    4.372440] r7 : cf7cc840  r6 : cf5cb410  r5 : 80080000  r4 : 00000000
[    4.378962] r3 : d0870000  r2 : 00000000  r1 : 00000000  r0 : 0000003b
[    4.385486] Flags: nZCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment none
[    4.392704] Control: 10c5383d  Table: 0000406a  DAC: 00000051
any attempt to write to any HVS register results in an external abort

and it doesnt appear to be an issue with how linux is configuring it, because i can also reproduce it with a baremetal arm kernel:

Code: Select all

DFAR: 0x80180011
DFSR: 0x00001c06
Fatal Exception: Data abort
ARM registers:
      r0: 0x00002000  r1: 0x00030008  r2: 0x80080000  r3: 0x0090e9ec
      r4: 0x0f000000  r5: 0x410fd034  r6: 0x00742e77  r7: 0x00023f70
      r8: 0x48001590  r9: 0x01101808 r10: 0x00020800 r11: 0x10820844
     r12: 0x00000040  sp: 0x08010800  lr: 0x020b0800  pc: 0x00008066
    cpsr: 0x600000f3
panic(): "Fatal CPU exception!"@trap.cc:49

it definitely feels like the arm core isnt being allowed to configure HVS, because then HVS could be told to read sensitive areas of ram

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 9509
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: HVS permission issues, MMIO appears to be readonly

Sat Sep 19, 2020 6:56 am

Seeing as the KMS driver writes the HVS DISPCTRL register in many places (eg https://github.com/raspberrypi/linux/bl ... hvs.c#L664), no.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

cleverca22
Posts: 1324
Joined: Sat Aug 18, 2012 2:33 pm

Re: HVS permission issues, MMIO appears to be readonly

Sat Sep 19, 2020 6:59 am

6by9 wrote:
Sat Sep 19, 2020 6:56 am
Seeing as the KMS driver writes the HVS DISPCTRL register in many places (eg https://github.com/raspberrypi/linux/bl ... hvs.c#L664), no.
yep, thats exactly where its failing for me

of note, i'm not using the closed-source firmware, so i may be missing some critical register to give the arm permission to modify HVS config

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 9509
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: HVS permission issues, MMIO appears to be readonly

Sat Sep 19, 2020 8:32 am

Have you turned the power domain and clocks on?

At an axi level, accessing a powered down block results in badness on the bus. With the vpu that's normally trapped although I don't recall the details (exception or dummy result for reads). You may be seeing the equivalent exception handling on the arm.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

cleverca22
Posts: 1324
Joined: Sat Aug 18, 2012 2:33 pm

Re: HVS permission issues, MMIO appears to be readonly

Sat Sep 19, 2020 8:40 am

6by9 wrote:
Sat Sep 19, 2020 8:32 am
Have you turned the power domain and clocks on?

At an axi level, accessing a powered down block results in badness on the bus. With the vpu that's normally trapped although I don't recall the details (exception or dummy result for reads). You may be seeing the equivalent exception handling on the arm.
its definitely not power or clocking logic

i can drive the HVS+PV+DPI fully and get a valid signal, from VPU only code, without any power-domain logic

linux can also read all of the HVS control registers without fault

when the HVS is disabled (the default) reading dlist memory faults in linux
but if the VPU pre-enables the HVS, that is reflected in the HVS control registers(as seen by linux reading them), and reading the dlist memory no longer faults

but any attempt to write to any HVS register from the arm faults

edit: it feels like some security features, to stop the arm from making the HVS read crypto keys out of secure ram, which start.elf has always been turning off for everybody

cleverca22
Posts: 1324
Joined: Sat Aug 18, 2012 2:33 pm

Re: HVS permission issues, MMIO appears to be readonly

Sun Sep 20, 2020 10:25 am

@6by9 would you be able to dig a bit deeper into the source to see if there is something obvious like that, or ask another one of the engineers?

i feel like the answer might be in "helpers/arm_loader/arm_loader.c" or a related file, but without the original source finding the answer is a lot harder

Return to “Graphics programming”