Re: [meta-xilinx] macb.c and DT: detect/scan PHY address for a single mdio

[Mike Looijmans]

"0" is not a valid address for a PHY, it's the "broadcast" address on the MDIO 
bus. You should make your hardware designer who selected it hurt somewhere 
painful.


Having said that, address 0 usally happens to work if there's only one PHY on 
that bus, since it will be the only one responding to that broadcast.


Change reg = <0x3> to reg = <0x0> in the devicetree. You can optionally change 
the descriptions as well, but it's the "reg" that really matters. This might 
work on the board with address "3" because that will also respond to the 
broadcast address 0.




On 18-07-18 03:12, Oleg K Dzhimiev wrote:

Hi,

How do I keep the device tree compatible across the board revisions if phy 
addrs are different?
We got a new board revision with a different phy reg, where old rev reg == 
0x3, new rev reg == 0x0.


Here's the DT:

ps7_ethernet_0: ps7-ethernet@e000b000 {
local-mac-address = [00 0e 64 10 00 00];
phy-handle = <&phy3>;
phy-mode = "rgmii-id";
mdio {
#address-cells = <1>;
#size-cells = <0>;
phy3: phy@3 {
                                         /* Atheros 8035 */
                                         compatible =
"ethernet-phy-id004d.d072";
/* compatible = "ethernet-phy-ieee802.3-c22";*/
device_type = "ethernet-phy";
reg = <0x3>;
};
};
};


So far, with the old revision (addr==0x3) I have tried to remove 'reg' hoping 
it would do some sort of scanning but the macb driver (macb_mii_probe) 
registers 32 phy structs then picks the first one (addr==0) and timeouts 
trying to reset it.


Thanks,

Oleg Dzhimiev
Electronics Engineer
phone: +1 801 783  x124
Elphel, Inc.




--
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] PMUFW debugging with debug flags

[Giordon Stark]

Hi all,

I'm trying to debug a PLL hang on a custom board (ultrascale+ chip) that
Xilinx believes is related to the PMUFW. To aid in debugging the issue,
they asked for two flags to be turned on:

https://github.com/kratsg/meta-l1calo/commit/ca4ce190f69f89bc3da4d39bcf32d00329264351#diff-0740188d1d09f1293bb14f19f19be79a



*file: recipes-bsp/pmu-firmware/pmu-firmware_2017.3.bbappend*
# Please enable debug logs in pmufw by defining XPFW_DEBUG_DETAILED and
DEBUG_MODE macros in pmufw source code.
# See http://www.wiki.xilinx.com/PMU+Firmware for more flags.

EXTRA_COMPILER_FLAGS_append = " -DXPFW_DEBUG_DETAILED -DDEBUG_MODE"

However, when recompiling and re-running -- I do not see extra debug
information from the PMUFW -- so I'm patching the kernel
drivers/clk/zynqmp/pll.c to get more information about the PLL hang itself
in the meantime.

Any ideas? Did I do something wrong in enabling the debug flags?

Giordon
-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] libmali EGLDeviceExt support

[Hyun Kwon]

Hi Jean-Francois,

The EGLDeviceEXT, which seems to require EGL 1.5, is not supported by the 
libMali, which supports EGL 1.4.

I believe the requirement here is to be able to specify which fb device file to 
open. The change is relatively simple, but unfortunately it's not currently in 
our plan. And just for information, internally, we are enabling the mali drm 
backend to support wayland. We don't run eglfs kms on the mali with drm 
backend, so not sure if it works out of box or not. It may be worth trying 
though. If the support case is filed through Xilinx, we will be able to 
prioritize accordingly.

Otherwise, only option that I can think of is to use X11, run multiple X11 
instances and run Qt on corresponding instance. I understand this is not your 
preferred approach.

Thanks,
-hyun

> -Original Message-
> From: Jean-Francois Dagenais [mailto:jeff.dagen...@gmail.com]
> Sent: Tuesday, July 17, 2018 11:57 AM
> To: Madhurkiran Harikrishnan ; Manjukumar
> Harthikote Matha ; meta-
> xil...@lists.yoctoproject.org
> Cc: Hyun Kwon ; Maxime Roussin-Bélanger
> 
> Subject: libmali EGLDeviceExt support
> 
> Hi all,
> 
> We have a dual screen setup running on top of xilinx/linux/4.14's new XLNX
> DRM (Thanks Hyun, great job with the refactor BTW). So far I can only set
> the dual display through the native KMS modetest command line.
> 
> Now we need to make Qt5 work. To make things clean, we thought we'd
> use the modern APIs for this, namely something like this:
> http://doc.qt.io/qt-5/embedded-linux.html#advanced-eglfs-kms-features in
> order to setup the cloned screens on /dev/dri/card0.
> 
> The problem is that the libMali provided binaries only use /dev/fb0 and the
> corresponding EGL header files are too old such that EGLDeviceEXT is not
> defined. Thus Qt's generic
> qtbase/src/plugins/platforms/eglfs/deviceintegration/eglfs_kms_egldevice
> will simply not work.
> 
> Is there any way xilinx will provide a updated libmali package? Or is there
> any other ways to use the MALI on top of EGLFS? We are trying, if possible,
> to avoid larger window frameworks such as X11 and wayland. And we are
> also under the impression, so far and perhaps falsely, that we cannot setup
> our screen cloning using the currently provided libmali-xlnx stack.
> 
> Thanks for any pointers.
> /jfd
> 

-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] PMUFW debugging with debug flags

[Jean-Francois Dagenais]

Hi Giordon,

> On Jul 19, 2018, at 8:58 AM, Giordon Stark  wrote:
> 
> However, when recompiling and re-running -- I do not see extra debug 
> information from the PMUFW -- so I'm patching the kernel 
> drivers/clk/zynqmp/pll.c to get more information about the PLL hang itself in 
> the meantime.
> 
> Any ideas? Did I do something wrong in enabling the debug flags?

Are you using the meta-xilinx-tools pmu_firmware recipe?

I ask because, coincidently, I am discussing a patch in xsctbase:do_configure 
about cleaning the xsct workspace on do_configure start to avoid these kinds of 
behaviour. See 
https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-June/003916.html and 
https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-July/003986.html

Turns out I had the manual "rm" in my local repo only, but the point remains.

Hope this helps!
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] PMUFW debugging with debug flags

[Giordon Stark]

Hi JF,

No, but I am on rocko so it's got the two different layers under
meta-xilinx and I'm using the meta-xilinx-bsp version. Is meta-xilinx-tools
completely different? The main reason I'm not using meta-xilinx-tools right
now is that my understanding is I need the SDK installed on the machine and
point m-x-t at it, and I'm just trying to get things in a way that doesn't
depend on something external to yocto...

Giordon

On Thu, Jul 19, 2018 at 8:55 AM Jean-Francois Dagenais <
jeff.dagen...@gmail.com> wrote:

> Hi Giordon,
>
> > On Jul 19, 2018, at 8:58 AM, Giordon Stark  wrote:
> >
> > However, when recompiling and re-running -- I do not see extra debug
> information from the PMUFW -- so I'm patching the kernel
> drivers/clk/zynqmp/pll.c to get more information about the PLL hang itself
> in the meantime.
> >
> > Any ideas? Did I do something wrong in enabling the debug flags?
>
> Are you using the meta-xilinx-tools pmu_firmware recipe?
>
> I ask because, coincidently, I am discussing a patch in
> xsctbase:do_configure about cleaning the xsct workspace on do_configure
> start to avoid these kinds of behaviour. See
> https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-June/003916.html
> and
> https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-July/003986.html
>
> Turns out I had the manual "rm" in my local repo only, but the point
> remains.
>
> Hope this helps!

-- 
Giordon Stark
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] PMUFW debugging with debug flags

[Peter Smith]

The two recipes are different for sure, I noticed this only yesterday and
yes you need xsct for m-x-t

On Thu, 19 Jul 2018, 14:58 Giordon Stark,  wrote:

> Hi JF,
>
> No, but I am on rocko so it's got the two different layers under
> meta-xilinx and I'm using the meta-xilinx-bsp version. Is meta-xilinx-tools
> completely different? The main reason I'm not using meta-xilinx-tools right
> now is that my understanding is I need the SDK installed on the machine and
> point m-x-t at it, and I'm just trying to get things in a way that doesn't
> depend on something external to yocto...
>
> Giordon
>
> On Thu, Jul 19, 2018 at 8:55 AM Jean-Francois Dagenais <
> jeff.dagen...@gmail.com> wrote:
>
>> Hi Giordon,
>>
>> > On Jul 19, 2018, at 8:58 AM, Giordon Stark  wrote:
>> >
>> > However, when recompiling and re-running -- I do not see extra debug
>> information from the PMUFW -- so I'm patching the kernel
>> drivers/clk/zynqmp/pll.c to get more information about the PLL hang itself
>> in the meantime.
>> >
>> > Any ideas? Did I do something wrong in enabling the debug flags?
>>
>> Are you using the meta-xilinx-tools pmu_firmware recipe?
>>
>> I ask because, coincidently, I am discussing a patch in
>> xsctbase:do_configure about cleaning the xsct workspace on do_configure
>> start to avoid these kinds of behaviour. See
>> https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-June/003916.html
>> and
>> https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-July/003986.html
>>
>> Turns out I had the manual "rm" in my local repo only, but the point
>> remains.
>>
>> Hope this helps!
>
> --
> Giordon Stark
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] macb.c and DT: detect/scan PHY address for a single mdio

[Oleg K Dzhimiev]

Mike,

Thanks. Will double check with reg=<0x0> - though expecting the same effect
as having it undefined.
Meanwhile I've found AR# 69132
 - looks exactly what is
needed - it just hasn't made it to the linux-xlnx yet.

Thanks again,
Oleg

On Thu, Jul 19, 2018 at 3:22 AM Mike Looijmans 
wrote:

> "0" is not a valid address for a PHY, it's the "broadcast" address on the
> MDIO
> bus. You should make your hardware designer who selected it hurt somewhere
> painful.
>
> Having said that, address 0 usally happens to work if there's only one PHY
> on
> that bus, since it will be the only one responding to that broadcast.
>
> Change reg = <0x3> to reg = <0x0> in the devicetree. You can optionally
> change
> the descriptions as well, but it's the "reg" that really matters. This
> might
> work on the board with address "3" because that will also respond to the
> broadcast address 0.
>
>
>
> On 18-07-18 03:12, Oleg K Dzhimiev wrote:
> > Hi,
> >
> > How do I keep the device tree compatible across the board revisions if
> phy
> > addrs are different?
> > We got a new board revision with a different phy reg, where old rev reg
> ==
> > 0x3, new rev reg == 0x0.
> >
> > Here's the DT:
> >
> > ps7_ethernet_0: ps7-ethernet@e000b000 {
> > local-mac-address = [00 0e 64 10 00 00];
> > phy-handle = <&phy3>;
> > phy-mode = "rgmii-id";
> > mdio {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > phy3: phy@3 {
> >  /* Atheros 8035 */
> >  compatible =
> > "ethernet-phy-id004d.d072";
> > /* compatible = "ethernet-phy-ieee802.3-c22";*/
> > device_type = "ethernet-phy";
> > reg = <0x3>;
> > };
> > };
> > };
> >
> >
> > So far, with the old revision (addr==0x3) I have tried to remove 'reg'
> hoping
> > it would do some sort of scanning but the macb driver (macb_mii_probe)
> > registers 32 phy structs then picks the first one (addr==0) and timeouts
> > trying to reset it.
> >
> > Thanks,
> >
> > Oleg Dzhimiev
> > Electronics Engineer
> > phone: +1 801 783  x124
> > Elphel, Inc.
> >
> >
>
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx