From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8825FC433E0 for ; Tue, 26 Jan 2021 13:59:29 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1CD33229C9 for ; Tue, 26 Jan 2021 13:59:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1CD33229C9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=unikie.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.75099.135125 (Exim 4.92) (envelope-from ) id 1l4OsD-0004Sc-4e; Tue, 26 Jan 2021 13:59:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 75099.135125; Tue, 26 Jan 2021 13:59:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1l4OsD-0004SV-1R; Tue, 26 Jan 2021 13:59:13 +0000 Received: by outflank-mailman (input) for mailman id 75099; Tue, 26 Jan 2021 13:59:12 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1l4OsB-0004SQ-Nc for xen-devel@lists.xenproject.org; Tue, 26 Jan 2021 13:59:12 +0000 Received: from mail-lf1-x135.google.com (unknown [2a00:1450:4864:20::135]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 91dbc0d7-3993-4911-b9c2-b31e86ca4e30; Tue, 26 Jan 2021 13:59:09 +0000 (UTC) Received: by mail-lf1-x135.google.com with SMTP id m22so22829974lfg.5 for ; Tue, 26 Jan 2021 05:59:09 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 91dbc0d7-3993-4911-b9c2-b31e86ca4e30 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unikie-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r68rIuJKbHhp2knjyQUOmU9agLKLkqieGzaufXvNPWY=; b=G5F8pYi2usHOfa2ZZqBEDItXo8N/Jv5koxKPjOsfadFanLS+I45qjqgWMtecWOnwM0 8nZiZIxuY6Bd+E/k1peoPznyuJwK74Favs0WW1Om1hFxRdPHKQ2Ia3dPHpKuTy4eh4AC S6aM08pLwAHEBz8N2Gk+P4g3u+uBbSvKxL3NA7rcUkrXkiniz8nJ6jUuI6XcBBB/pwP6 nfmNT2FhkvCa3F+G7Qz6LXul5aa4g6Nz0gZdGFsui3u0GT7kwVY0QY9xRgXVdW9UYhOc OVcDKjbYz5F7xkTmbP2BIEcj7Hkoi5m5fI+m+ZatNf8gOgMbcX1BorJL2M3bVY9a0uM4 IHYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r68rIuJKbHhp2knjyQUOmU9agLKLkqieGzaufXvNPWY=; b=hToGDUo9TkXIeP9C/IM3ScRCPZTH8UCUusI/zXCbaDQA2PvrnCwRqgDU8WiC7BYQwX 8wX0wQRRBCYAXnz+EAcF0Bzy3gXYZO0/QaWxUTvcvDxkNrUeqFe6ht39qXuaxCGS1XWW mA9fa18PnVLyOmm7RfBiO6M0VKt+eMgqlPQUCzh2qlVnzpwSk16cheBRPnEO+bBb+sA4 QRfJUzQ+Z1rhL82YccIQ8z8w37m7tHWHb5T3c4q609SzOJPGCxyfs9Qps5QfaRH/8hOv o0qFdbBKBGSS0i9Q6Q26Zcw4FZfSD+GR2O55k2P4sfhxtJqGBJzVqb8Wgbu9bN6x8Yh+ HYgQ== X-Gm-Message-State: AOAM531875698AHYI/Exh58uaI/1lVCfFcvgXEqPIGhuDjRJKEic69YU T7le14ot6oFDq2574hzCV7mtd00T2dfc27xKoCoOKQ== X-Google-Smtp-Source: ABdhPJzh74grNA1AWCLIkpXrSyxy+rB7PUsgvNjHIs++vLBLaqUQdFMkV+vHCNvJfHCboTglOvKaTvuRipMPMzdmBBE= X-Received: by 2002:ac2:4114:: with SMTP id b20mr2753211lfi.180.1611669548104; Tue, 26 Jan 2021 05:59:08 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jukka Kaartinen Date: Tue, 26 Jan 2021 15:58:57 +0200 Message-ID: Subject: Re: Question about xen and Rasp 4B To: Stefano Stabellini Cc: Xen-devel , Roman Shaposhnik , Julien Grall , Bertrand Marquis Content-Type: multipart/alternative; boundary="000000000000e9184905b9ce0ebf" --000000000000e9184905b9ce0ebf Content-Type: text/plain; charset="UTF-8" On Tue, Jan 26, 2021 at 12:59 PM Jukka Kaartinen wrote: > > > On Tue, Jan 26, 2021 at 2:54 AM Stefano Stabellini > wrote: > >> On Sat, 23 Jan 2021, Jukka Kaartinen wrote: >> > Thanks for the response! >> > >> > On Sat, Jan 23, 2021 at 2:27 AM Stefano Stabellini < >> sstabellini@kernel.org> wrote: >> > + xen-devel, Roman, >> > >> > >> > On Fri, 22 Jan 2021, Jukka Kaartinen wrote: >> > > Hi Stefano, >> > > I'm Jukka Kaartinen a SW developer working on enabling >> hypervisors on mobile platforms. One of our HW that we use on >> > development is >> > > Raspberry Pi 4B. I wonder if you could help me a bit :). >> > > >> > > I'm trying to enable the GPU with Xen + Raspberry Pi for >> > dom0. >> https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=232323#p1797605 >> > > >> > > I got so far that GPU drivers are loaded (v3d & vc4) without >> errors. But now Xen returns error when X is starting: >> > > (XEN) traps.c:1986:d0v1 HSR=0x93880045 pc=0x00007f97b14e70 >> gva=0x7f7f817000 gpa=0x0000401315d000 >> > > I tried to debug what causes this and looks >> like find_mmio_handler cannot find handler. >> > > (See more here: >> https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=232323&start=25#p1801691 >> ) >> > > >> > > Any ideas why the handler is not found? >> > >> > >> > Hi Jukka, >> > >> > I am glad to hear that you are interested in Xen on RaspberryPi >> :-) I >> > haven't tried the GPU yet, I have been using the serial only. >> > Roman, did you ever get the GPU working? >> > >> > >> > The error is a data abort error: Linux is trying to access an >> address >> > which is not mapped to dom0. The address seems to be >> 0x401315d000. It is >> > a pretty high address; I looked in device tree but couldn't spot >> it. >> > >> > >From the HSR (the syndrom register) it looks like it is a >> translation >> > fault at EL1 on stage1. As if the Linux address mapping was wrong. >> > Anyone has any ideas how this could happen? Maybe a >> reserved-memory >> > misconfiguration? >> > >> > I had issues with loading the driver in the first place. Apparently >> swiotlb is used, maybe it can cause this. I also tried to enable CMA. >> > config.txt: >> > dtoverlay=vc4-fkms-v3d,cma=320M@0x0-0x40000000 >> > gpu_mem=128 >> >> Also looking at your other reply and the implementation of >> vc4_bo_create, it looks like this is a CMA problem. >> >> It would be good to run a test with the swiotlb-xen disabled: >> >> diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c >> index 467fa225c3d0..2bdd12785d14 100644 >> --- a/arch/arm/xen/mm.c >> +++ b/arch/arm/xen/mm.c >> @@ -138,8 +138,7 @@ void xen_destroy_contiguous_region(phys_addr_t >> pstart, unsigned int order) >> static int __init xen_mm_init(void) >> { >> struct gnttab_cache_flush cflush; >> - if (!xen_initial_domain()) >> - return 0; >> + return 0; >> xen_swiotlb_init(1, false); >> >> cflush.op = 0; >> > With this change the kernel is not booting up. (btw. I'm using USB SSD for > my OS.) > [ 0.071081] bcm2835-dma fe007000.dma: Unable to set DMA mask > [ 0.076277] bcm2835-dma fe007b00.dma: Unable to set DMA mask > (XEN) physdev.c:16:d0v0 PHYSDEVOP cmd=25: not implemented > (XEN) physdev.c:16:d0v0 PHYSDEVOP cmd=15: not implemented > [ 0.592695] pci 0000:00:00.0: Failed to add - passthrough or MSI/MSI-X > might fail! > (XEN) physdev.c:16:d0v0 PHYSDEVOP cmd=15: not implemented > [ 0.606819] pci 0000:01:00.0: Failed to add - passthrough or MSI/MSI-X > might fail! > [ 1.212820] usb 1-1: device descriptor read/64, error 18 > [ 1.452815] usb 1-1: device descriptor read/64, error 18 > [ 1.820813] usb 1-1: device descriptor read/64, error 18 > [ 2.060815] usb 1-1: device descriptor read/64, error 18 > [ 2.845548] usb 1-1: device descriptor read/8, error -61 > [ 2.977603] usb 1-1: device descriptor read/8, error -61 > [ 3.237530] usb 1-1: device descriptor read/8, error -61 > [ 3.369585] usb 1-1: device descriptor read/8, error -61 > [ 3.480765] usb usb1-port1: unable to enumerate USB device > > Traces stop here. I could try with a memory card. Maybe it makes a > difference. > > >> >> It is going to be fine just to boot Dom0 and DomUs without PV drivers. >> Also, can you post the device tree that you are using here? Just in case >> there is an issue with Xen parsing any possible /reserved-memory nodes >> with CMA info that need to be passed on to Dom0. > > Here is the device dumped from command line: > dtc -I fs /proc/device-tree > > https://drive.google.com/file/d/17u18dJHxRfbGZMtRXIwtLVZZfMj9KwN-/view?usp=sharing > > Here is log from XEN when it goes through the device tree: https://drive.google.com/file/d/1jvT3ZNJeXHfxPOffiaRSRg8FPwQHS1mb/view?usp=sharing > >> >> > > p.s. >> > > While testing I found issue with Xen master branch and your >> patch: xen/rpi4: implement watchdog-based reset >> > > >> > > Looks like black listing the bcm2835-pm >> > > @@ -37,12 +41,69 @@ static const struct dt_device_match >> rpi4_blacklist_dev[] __initconst = >> > > * The aux peripheral also shares a page with the aux UART. >> > > */ >> > > DT_MATCH_COMPATIBLE("brcm,bcm2835-aux"), >> > > + /* Special device used for rebooting */ >> > > + DT_MATCH_COMPATIBLE("brcm,bcm2835-pm"), >> > > >> > > will prevent v3d driver to locate phandle. I think it will use >> the same resource: >> > > pm: watchdog@7e100000 { >> > > compatible = "brcm,bcm2835-pm", "brcm,bcm2835-pm-wdt"; >> > > #power-domain-cells = <1>; >> > > #reset-cells = <1>; >> > > reg = <0x7e100000 0x114>, >> > > <0x7e00a000 0x24>, >> > > <0x7ec11000 0x20>; >> > > clocks = <&clocks BCM2835_CLOCK_V3D>, >> > > <&clocks BCM2835_CLOCK_PERI_IMAGE>, >> > > <&clocks BCM2835_CLOCK_H264>, >> > > <&clocks BCM2835_CLOCK_ISP>; >> > > clock-names = "v3d", "peri_image", "h264", "isp"; >> > > system-power-controller; >> > > >> > > }; >> > >> > Yeah, I imagine it could be possible. Can you post the error >> message you >> > are seeing from the v3d driver? >> > >> > This is the error: >> > [ 0.069682] OF: /v3dbus/v3d@7ec04000: could not find phandle >> > [ 0.074828] OF: /v3dbus/v3d@7ec04000: could not find phandle >> > v3d driver is not loaded. >> > >> > -- >> > Br, >> > Jukka Kaartinen >> > >> > > > > > -- > Br, > Jukka Kaartinen > -- Br, Jukka Kaartinen --000000000000e9184905b9ce0ebf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 26, 2021 at 12:59 PM Jukk= a Kaartinen <jukka.kaartin= en@unikie.com> wrote:


On Tue, Jan 26, 2021 at = 2:54 AM Stefano Stabellini <sstabellini@kernel.org> wrote:
On Sat, 23 Jan 2021, Jukka Kaartinen = wrote:
> Thanks for the response!
>
> On Sat, Jan 23, 2021 at 2:27 AM Stefano Stabellini <sstabellini@kernel.org>= wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0+ xen-devel, Roman,
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0On Fri, 22 Jan 2021, Jukka Kaartinen wrote:<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> Hi Stefano,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> I'm Jukka=C2=A0Kaartinen a SW devel= oper working on enabling hypervisors on mobile platforms. One of our HW tha= t we use on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0development is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Raspberry Pi 4B. I wonder if you could = help me a bit :).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> I'm trying to enable the GPU with X= en=C2=A0+ Raspberry Pi for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0dom0.=C2=A0https://www.raspberrypi.org/forums/viewtopic.php?f=3D6= 3&t=3D232323#p1797605
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> I got so far that GPU drivers are loade= d (v3d & vc4) without errors. But now Xen returns error=C2=A0when X is = starting:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> (XEN) traps.c:1986:d0v1 HSR=3D0x9388004= 5 pc=3D0x00007f97b14e70 gva=3D0x7f7f817000 gpa=3D0x0000401315d000
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0I tried to debug what causes this= and looks like=C2=A0find_mmio_handler=C2=A0cannot find handler.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> (See more here: https://www.raspberrypi.org/f= orums/viewtopic.php?f=3D63&t=3D232323&start=3D25#p1801691 )
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Any ideas why the handler is not found?=
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Jukka,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I am glad to hear that you are interested in= Xen on RaspberryPi :-)=C2=A0 I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0haven't tried the GPU yet, I have been u= sing the serial only.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Roman, did you ever get the GPU working?
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0The error is a data abort error: Linux is tr= ying to access an address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0which is not mapped to dom0. The address see= ms to be 0x401315d000. It is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0a pretty high address; I looked in device tr= ee but couldn't spot it.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>From the HSR (the syndrom register) it l= ooks like it is a translation
>=C2=A0 =C2=A0 =C2=A0 =C2=A0fault at EL1 on stage1. As if the Linux addr= ess mapping was wrong.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Anyone has any ideas how this could happen? = Maybe a reserved-memory
>=C2=A0 =C2=A0 =C2=A0 =C2=A0misconfiguration?
>
> I had issues=C2=A0with loading the driver in the first place. Apparent= ly swiotlb is used, maybe it=C2=A0can cause this. I also tried to enable CM= A.
> config.txt:
> dtoverlay=3Dvc4-fkms-v3d,cma=3D320M@0x0-0x40000000
> gpu_mem=3D128

Also looking at your other reply and the implementation of
vc4_bo_create, it looks like this is a CMA problem.

It would be good to run a test with the swiotlb-xen disabled:

diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 467fa225c3d0..2bdd12785d14 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -138,8 +138,7 @@ void xen_destroy_contiguous_region(phys_addr_t pstart, = unsigned int order)
=C2=A0static int __init xen_mm_init(void)
=C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct gnttab_cache_flush cflush;
-=C2=A0 =C2=A0 =C2=A0 =C2=A0if (!xen_initial_domain())
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return 0;
+=C2=A0 =C2=A0 =C2=A0 =C2=A0return 0;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 xen_swiotlb_init(1, false);

=C2=A0 =C2=A0 =C2=A0 =C2=A0 cflush.op =3D 0;
With this= change the kernel is not booting up. (btw. I'm using USB SSD for my OS= .)
[ =C2=A0 =C2=A00.071081] bcm2835-dma fe007000.dma: Unable to s= et DMA mask
[ =C2=A0 =C2=A00.076277] bcm2835-dma fe007b00.dma: Unable to= set DMA mask
(XEN) physdev.c:16:d0v0 PHYSDEVOP cmd=3D25: not implemente= d
(XEN) physdev.c:16:d0v0 PHYSDEVOP cmd=3D15: not implemented
[ =C2= =A0 =C2=A00.592695] pci 0000:00:00.0: Failed to add - passthrough or MSI/MS= I-X might fail!
(XEN) physdev.c:16:d0v0 PHYSDEVOP cmd=3D15: not implemen= ted
[ =C2=A0 =C2=A00.606819] pci 0000:01:00.0: Failed to add - passthrou= gh or MSI/MSI-X might fail!
[ =C2=A0 =C2=A01.212820] usb 1-1: device des= criptor read/64, error 18
[ =C2=A0 =C2=A01.452815] usb 1-1: device descr= iptor read/64, error 18
[ =C2=A0 =C2=A01.820813] usb 1-1: device descrip= tor read/64, error 18
[ =C2=A0 =C2=A02.060815] usb 1-1: device descripto= r read/64, error 18
[ =C2=A0 =C2=A02.845548] usb 1-1: device descriptor = read/8, error -61
[ =C2=A0 =C2=A02.977603] usb 1-1: device descriptor re= ad/8, error -61
[ =C2=A0 =C2=A03.237530] usb 1-1: device descriptor read= /8, error -61
[ =C2=A0 =C2=A03.369585] usb 1-1: device descriptor read/8= , error -61
[ =C2=A0 =C2=A03.480765] usb usb1-port1: unable to enumerate= USB device

Traces stop here. I could try with= a memory card. Maybe it makes a difference.
=C2=A0

It is going to be fine just to boot Dom0 and DomUs without PV drivers.
Also, can you post the device tree that you are using here? Just in case there is an issue with Xen parsing any possible /reserved-memory nodes
with CMA info that need to be passed on to Dom0.
Here is t= he device dumped from command line:
Here is log from XEN when it go= es through the device tree:

=C2=A0


>=C2=A0 =C2=A0 =C2=A0 =C2=A0> p.s.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> While testing I found issue with Xen ma= ster branch and your patch:=C2=A0xen/rpi4: implement watchdog-based reset >=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Looks like black listing the=C2=A0bcm28= 35-pm
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> @@ -37,12 +41,69 @@ static const struct= dt_device_match rpi4_blacklist_dev[] __initconst =3D
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0 * The aux peripher= al also shares a page with the aux UART.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0 */
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0DT_MATCH_COMPATIBLE= ("brcm,bcm2835-aux"),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> + =C2=A0 =C2=A0/* Special device used f= or rebooting */
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> + =C2=A0 =C2=A0DT_MATCH_COMPATIBLE(&quo= t;brcm,bcm2835-pm"),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> will prevent v3d driver to locate phand= le. I think it will use the same resource:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0 pm: watchdog@7e100000 {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0compatible = =3D "brcm,bcm2835-pm", "brcm,bcm2835-pm-wdt";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> #power-domain-cells =3D <1>;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> #reset-cells =3D <1>;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> reg =3D <0x7e100000 0x114>,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0<0x7e00a000 0x24= >,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0<0x7ec11000 0x20= >;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> clocks =3D <&clocks BCM2835_CLOC= K_V3D>,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> <&clocks BCM2835_CLOCK_PERI_IMAG= E>,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> <&clocks BCM2835_CLOCK_H264>,=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> <&clocks BCM2835_CLOCK_ISP>;<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> clock-names =3D "v3d", "= peri_image", "h264", "isp";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> system-power-controller;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> };
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Yeah, I imagine it could be possible. Can yo= u post the error message you
>=C2=A0 =C2=A0 =C2=A0 =C2=A0are seeing from the v3d driver?
>
> This is the error:
> [ =C2=A0 =C2=A00.069682] OF: /v3dbus/v3d@7ec04000: could not find phan= dle
> [ =C2=A0 =C2=A00.074828] OF: /v3dbus/v3d@7ec04000: could not find phan= dle
> v3d driver is not loaded.
>
> --
> Br,
> Jukka Kaartinen
>
>


--
Br,
Jukka Kaartinen
=


--
Br,
Jukka Kaarti= nen
--000000000000e9184905b9ce0ebf--