linux-kernel - Re: [PATCH v4 0/3] Introduce support for T-head TH1520 Mailbox

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c8513bdb-1180-470b-a664-a8d526a12e5b@samsung.com>
Date: Tue, 22 Oct 2024 13:54:00 +0200
From: Michal Wilczynski <m.wilczynski@...sung.com>
To: Drew Fustini <dfustini@...storrent.com>
Cc: drew@...7.com, guoren@...nel.org, wefu@...hat.com,
	jassisinghbrar@...il.com, robh@...nel.org, krzk+dt@...nel.org,
	conor+dt@...nel.org, paul.walmsley@...ive.com, palmer@...belt.com,
	aou@...s.berkeley.edu, m.szyprowski@...sung.com,
	linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org
Subject: Re: [PATCH v4 0/3] Introduce support for T-head TH1520 Mailbox



On 10/16/24 20:08, Drew Fustini wrote:
> On Wed, Oct 16, 2024 at 12:03:05AM +0200, Michal Wilczynski wrote:
>>
>>
>> On 10/14/24 20:31, Drew Fustini wrote:
>>> On Mon, Oct 14, 2024 at 02:33:11PM +0200, Michal Wilczynski wrote:
>>>> The T-head TH1520 SoC supports a hardware mailbox that enables two cores
>>>> within the SoC to communicate and coordinate [1]. One example of such
>>>> coordination would be cooperation with the T-Head E902 core, which is
>>>> responsible for power, clock, and resource management. For example, in
>>>> the specific case of the BXM-4-64 GPU, it needs to be powered on by the
>>>> E902 core, and the kernel running on the E910 needs to 'ask' the
>>>> firmware running on the E902 core to enable power to the GPU island.
>>>> Given recent advancements in work on the upstream GPU driver [2], there
>>>> is an emerging need to get this code in the mainline kernel.
>>>>
>>>> Link: https://protect2.fireeye.com/v1/url?k=2021d256-7fbdfb7c-20205919-000babe598f7-ca654d1a9bc866ac&q=1&e=11e97355-e6e9-4aac-a996-cc475156b3c8&u=https%3A%2F%2Fopenbeagle.org%2Fbeaglev-ahead%2Fbeaglev-ahead%2F-%2Fblob%2Fmain%2Fdocs%2FTH1520%2520System%2520User%2520Manual.pdf [1]
>>>> Link: https://gitlab.freedesktop.org/imagination/linux-firmware/-/issues/1 [2]
>>>>
>>>> Thanks, Krzysztof and Rob, for your review! Since this series is gaining
>>>> some interest, I've dropped the RFC prefix with the v3 update.
>>>
>>> I've applied this series and booted okay. I see the driver loaded:
>>>
>>>  /sys/devices/platform/soc/ffffc38000.mailbox/driver points to
>>>  /sys/bus/platform/drivers/th1520-mbox
>>>
>>> How do you test that the communication with the E902 is working
>>> correctly?
>>
>> Thank you for your interest. To test this, I've prepared a diff that
>> includes the missing drivers utilizing the mailbox and enabled the GPU
>> node in the device tree to use the drm/imagination driver.
>>
>> I've observed that when the power was turned off through the E902 core
>> using the mailbox, the drm/imagination driver would hang in
>> pvr_load_gpu_id() while attempting to read its BVNC from the register.
>> However, when the GPU was turned on via the mailbox, the BVNC could be
>> read correctly. Still, the firmware fails to boot due to some missing
>> programming in the drm/imagination driver, which is currently being
>> worked on. I've briefly explained this in the first commit of this
>> series.
>>
>> If you'd like to try this yourself, I'd be happy to push these setups to
>> a GitHub repository and provide you with a link, so you can see the
>> setup in action.
> 
> I think that would be helpful for myself and others to be able to see
> the interaction.

I’ve cleaned up the code and it’s ready to share. I’ll include this
description and the GitHub links in the cover letter for the next
revision.

I’ve created two branches. Both contain the same code, including this
patch series and some extra commits with mailbox consumers. The only
difference is that one branch has an additional commit that switches ON
calls to OFF calls (and vice versa) to observe the behavior when the GPU
is turned off via the mailbox.

To reproduce, simply clone the repository, add the following extra options
in the config:

CONFIG_DRM_POWERVR=y
CONFIG_LIGHT_AON=y
CONFIG_LIGHT_AON_PD=y

Then build and deploy on the target.

In case [1], the output should be:
[    2.478394] light_aon_probe: virtual_log_mem=0x000000005faf564a, phy base=0x33600000, size:2097152
[    2.488589] succeed to create power domain debugfs direntry
[    2.494987] powervr ffef400000.gpu: Before reading BVNC
At this point, the system will hang because the driver is trying to read
memory-mapped registers while the GPU isn’t powered on.

In case [2], the GPU powers on correctly, and the BVNC can be read
without issues. If the specific firmware file isn’t available, the
output would look like this:
root@...yos-lpi4a:~# dmesg | grep gpu
[    2.408207] powervr ffef400000.gpu: Before reading BVNC
[    2.413533] powervr ffef400000.gpu: After reading BVNC
[    2.418930] powervr ffef400000.gpu: Direct firmware load for powervr/rogue_36.52.104.182_v1.fw failed with error -2
[    2.429568] powervr ffef400000.gpu: [drm] *ERROR* failed to load firmware powervr/rogue_36.52.104.182_v1.fw (err=-2)
[    2.440403] powervr ffef400000.gpu: probe with driver powervr failed with error -2

Here are the links:
[1] - https://github.com/mwilczy/linux/tree/22_october_demonstrate_mailbox_not_working
[2] - https://github.com/mwilczy/linux/tree/22_october_demonstrate_mailbox_working

Note: U-Boot must load the AON firmware at startup to the address mapped
for AON for this to work properly.

Thanks,
Michał

> 
> Thanks,
> Drew
>