[meta-xilinx] multiple problems with microzed-zynq7 machine

[Nathan Rossi]

On 27 January 2017 at 01:09, David Roman <droman at ifae.es> wrote:
> Removing that solves the problem, thanks. But what surprise me is that these
> problems starts with the commit that I mentioned before
> (061a16fd21bc0f419eda03aee6ee0ce11b48f27) which seems that only changes some
> kernel configuration and anything more. Doing a checkout to the previous
> commit don't have these problems.
>
>
> I don't know why but seems that setting CONFIG_FIXED_PHY to something
> different from "y" fixes the problems too. Also, I found that my board uses
> Marvell 88E1510 not the 88e1512, so appending the right compatible string
> also fixes it (then I don't understand how this problem don't have occurred
> before). Anyway, the compatible string for the ethernet-phy (in the microzed
> dts) is not missing the 88e1510?

So the microzed schematics list a 88e1512 (use on actual boards may
vary?). However there is no compatible driver in the kernel for this
exact phy. Leaving the compatible string empty will let it auto detect
and select a phy from the known ID's, and the 88e1510 driver is masked
to match a set of phys including the 88e1512. Also setting the
compatible string to compatible = "marvell,88e1512",
"marvell,88e1510"; would also likely do the trick. But following the
mainline kernel device tree (which was just added in v4.10 btw) is
probably the better option, since there is no specific config required
to use the phy. And auto detection when the driver is available is a
better option as well. At some point the kernel device tree will
become the default for the board and the meta-xilinx one will be
removed.

>
>
> I suppose that the problem about the DMA is some configuration option that
> should be enabled/disabled I will try to see what have have changed and
> configure it properly. I attach the full log after fixing the Ethernet
> problem.

[    0.803073] xilinx-vdma 40400000.dma: failed to get axi_aclk (4294967294)
[    0.803121] xilinx-vdma: probe of 40400000.dma failed with error -2

Yes this is something i remember seeing on a rev-up of a different
device tree. The bindings in kernel v4.6 changed, you need to provide
the clock that drives the dma device.

A node like this is what you will need, note the "clocks" and
"clock-names". You will have to figure out which clock drives your
dma, in this case its fclk0 (15, fclk1 = 16, fclk2 = 17, fclk3 = 18).

axi_vdma_0: dma at 43000000 {
#dma-cells = <1>;
compatible = "xlnx,axi-vdma-1.00.a";
clocks = <&clkc 15>;
clock-names = "s_axi_lite_aclk";
interrupt-parent = <&intc>;
interrupts = <0 30 4>;
reg = <0x43000000 0x10000>;
xlnx,flush-fsync = <0x1>;
xlnx,num-fstores = <0x1>;
dma-channel at 43000000 {
compatible = "xlnx,axi-vdma-mm2s-channel";
interrupts = <0 30 4>;
xlnx,datawidth = <0x20>;
xlnx,device-id = <0x0>;
};
};

Regards,
Nathan

>
>
> Thank you very much for your time and sorry for my ignorance.
>
>
>
> On 25/01/17 18:48, Nathan Rossi wrote:
>>
>> On 25 January 2017 at 23:47, David Roman <droman at ifae.es> wrote:
>>>
>>> Hi
>>>
>>> I'm having two problems when trying to use the morty branch for a
>>> microzed-zynq7 machine.
>>> First, the ethernet is not working and shows an error (Configuring
>>> network
>>> interfaces... ifconfig: SIOCGIFFLAGS: No such device)
>>
>> Hi David,
>>
>> This issue might be related to the fact that the device tree in the
>> meta-xilinx layer for the microzed has a compatible string listed for
>> the phy node. The mainline kernel hasn't got that
>>
>> (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/zynq-microzed.dts?id=refs/tags/v4.10-rc5#n52).
>>
>> Could you try removing the compatible string set. Also please provide
>> the full kernel boot log if possible.
>>
>>> Second, DMA is not usable (requesting an slave channel from our kernel
>>> module fails).
>>
>> Not sure what you are referring to here, you will need to provide more
>> details. The DMA drivers in the kernel have changed over the past few
>> releases (they have been upstreamed), and some of the dts bindings
>> have changed too. Kernel log and error messages would be useful here
>> too.
>>
>> Regards,
>> Nathan
>
>
>
> --
> Avís - Aviso - Legal Notice - (LOPD) - http://legal.ifae.es