[fedora-arm] Re: device tree on Pi4B

--- test_kernel/builddir/kernel_build/BUILD/kernel-5.19/linux-5.19.0-65.local.fc37.aarch64/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c 2022-07-31 17:03:01.000000000 -0400
+++ /home/sfalco/vchiq_arm.c 2022-08-12 11:10:23.609220349 -0400
@@ -81,6 +81,10 @@
.cache_line_size = 64,
};

+static struct vchiq_drvdata bcm2711_drvdata = {
+ .cache_line_size = 64,
+};
+
struct vchiq_arm_state {
/* Keepalive-related data */
struct task_struct *ka_thread;
@@ -1761,6 +1765,7 @@
static const struct of_device_id vchiq_of_match[] = {
{ .compatible = "brcm,bcm2835-vchiq", .data = &bcm2835_drvdata },
{ .compatible = "brcm,bcm2836-vchiq", .data = &bcm2836_drvdata },
+ { .compatible = "brcm,bcm2711-vchiq", .data = &bcm2711_drvdata },
{},
};
MODULE_DEVICE_TABLE(of, vchiq_of_match);
On 8/4/22 02:46 AM, Peter Robinson wrote:
> On Wed, Aug 3, 2022 at 8:04 PM Steven A. Falco <stevenfalco@gmail.com> wrote:
>>
>> On 8/3/22 02:24 PM, Peter Robinson wrote:
>>> On Wed, Aug 3, 2022 at 4:17 PM Steven A. Falco <stevenfalco@gmail.com> wrote:
>>>>
>>>> I have a Pi4B that is working pretty well with the aarch64 version of Fedora Rawhide, but I have one issue that I haven't been able to find a solution to.
>>>>
>>>> I have an Adafruit RTC connected via I2C (https://www.adafruit.com/product/3386). If I use the kernel device tree, this device is not found.
>>>>
>>>> I then tried switching to the firmware device tree via the instructions in https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi/HATs. That works pretty well - I can now add an overlay for the RTC in /boot/efi/config.txt and the RTC is found during boot. dtoverlay=i2c-rtc,pcf8523,addr=0x68
>>>>
>>>> However, once I've switched to the firmware device tree, I no longer have /dev/vchiq, which means that I can no longer use vcgencmd. Instead, vcgencmd gives me "VCHI initialization failed".
>>>
>>> It should be the same as required in Raspbian. Have you checked the
>>> details in /boot/efi/overlays/README? Out of interest what do you use
>>> /dev/vchiq / vcgencmd for?
>>
>> I've looked at the README, but it doesn't mention VCHI, so I'm not sure how to enable VCHI when using the firmware DT. I'll look at the kernel DT source - perhaps that gives clues as to how to create an overlay that I could then use with the firmware DT.
>
> I'll take a look when I get a few cycles.

Turns out the vchiq_probe code in vchiq_arm.c is looking for either "brcm,bcm2835-vchiq" or "brcm,bcm2836-vchiq", while the FW DT is supplying "brcm,bcm2711-vchiq". I attached a patch that lets me insert the vchiq driver; the driver in turn creates the /dev/vchiq node, and I am then able to use vcgencmd.

I have to manually modprobe the driver when using the FW DT. The driver is automatically inserted during boot when using the kernel DT. I haven't tracked that part down yet...

>> One interesting thing is that the kernel DT shows the RTC on bus 3, but the firmware DT shows the RTC on bus 1.
>
> Three's different "modes" (for want of a better description) where the
> firmware steals buses for it's own use.
>
>> BTW, I'm using vcgencmd to measure the temperature and to check the "get_throttled" flag to detect voltage dips.
>
> You can also use tmon in the kernel-tools package to monitor temp,
> thermal trip points and the like.
>
>>>> Is there any way to get both the RTC and vcgencmd to work? Which device tree would I choose? Do I have to build a custom kernel or is there some other way to enable the RTC with the kernel device tree?
>>>
>>> You don't need a custom kernel but you'd need to build your own DT as
>>> obviously anything that is not default on the RPi devices themselves
>>> is optional hence the requirement of overlays.
>>
>> Understood. I don't know which is better - the firmware DT or the kernel DT. I guess the FW DT has the advantage that it is easy to turn stuff on/off, but the kernel DT probably better matches the drivers.
>
> For the later point, not really, they are slowly converging closer
> together. Fedora as a whole is moving towards SystemReady IR style of
> DT where it's provided by the firmware and I hope to stop shipping the
> kernel ones all together.
>
>> And of course the last thing I want is to have to regenerate a custom DT each time the kernel is updated.
>
> You shouldn't need to do that for each kernel.