[meta-xilinx] Kernel version, xilinx git repo, yocto kernel

Fri Apr 12 06:39:56 PDT 2019

> Gesendet: Mittwoch, 10. April 2019 um 07:39 Uhr
> Von: "Mike Looijmans" <mike.looijmans at topic.nl>
> An: "meta xilinx" <meta-xilinx at yoctoproject.org>
> Betreff: Re: [meta-xilinx] Kernel version, xilinx git repo, yocto kernel
>
> On 07-04-19 11:41, Arno Steffens wrote:
> > In fact, I think I have difficulties with glitches on the bus, but changes at the boards are much more expensive and time consuming - so I'll try to get a better stability with that gpio-bitbang driver.
> >
> > Thanks Mike, especially for the hints with devicetree. Are this GPIO numbers are same as MIO-Pin-numbers? I found that the base-include for zynq has been changed completly (at least in my eyes), so it will take some time to adapt it to a new kernel.
> > I created a new bitstream (IO set to GPIO instead of I2C) and (not sure whether it is required) a new fsbl.  I don't need I2c in Uboot, but I am wondering where this gets information about it. Including driver in kernel is smallest issue. So altogether this becomes quite a project for me ;) but I hope I learn a lot with that. Did all this steps just once or twice some time ago.
> >
>
> GPIO and MIO pin numbers are the same.
>
> The bitstream has no efect whatsoever on the MIO pins (Xilinx is very unclear
> about this), so there's no need to change it.
>
> The "pinmux" settings let the kernel change the pin assignments, so there is
> also no need to alter the bootloader. On the 7-series at least the bootloader
> only needs enough to boot the system, the kernel can configure everything else.
>

That partly comes to late for me. I digged around (run from one trouble to next with Vivado) but finally come to a simular but not same conclusion. In fact, bitstream doesn't contain pinmux, but FSBL. At least after changing just FSBL i2c doesn't work at all (with old cadence i2c-kernel/devicetree). So kernel/devicetree alone might not be enough (kernel 4.14)
I changed kernel for using bitbang instead of cadence i2c driver. But with devicetree I failed. I didn't get a clue how it works in detail and compiler is not very helpful with debug messages. Especially this mixture of zynq-7000.dtsi and dts.
I finally end up with decompiling my previous devicetree, fiddling your miami devicetree to kernel, run dtbs and decompiled the dtb.
So I have 2 simplier decompiled devicetrees for a better side by side comparison.
With adding i2c stuff I get at least something compilable again (see attached), but kernel gives me

i2c /dev entries driver
cdns-wdt f8005000.watchdog: Xilinx Watchdog Timer at df8f6000 with timeout 10s
....
i2c-gpio gpios-i2c at 22: could not find pctldev for node /amba/slcr at f8000000/pinctrl at 700/i2c0-default, deferring probe
i2c-gpio gpios-i2c at 28: could not find pctldev for node /amba/slcr at f8000000/pinctrl at 700/i2c1-default, deferring probe

So I have I2C0 with GPIO22,23 and I2C1 with 28,29.

(Without the last i2c entries in dts I don't get this messages, but in neither of the options an entry /dev/i2c-0,1 is created).
What is wrong/missed?

A nice weekend,
Arno

> >> Gesendet: Freitag, 05. April 2019 um 07:44 Uhr
> >> Von: "Mike Looijmans" <mike.looijmans at topic.nl>
> >> An: "Arno Steffens" <epsi at gmx.de>
> >> Cc: "meta xilinx" <meta-xilinx at yoctoproject.org>
> >> Betreff: Re: Aw: Re: [meta-xilinx] Kernel version, xilinx git repo, yocto kernel
> >>
> >> On 04-04-19 14:03, Arno Steffens wrote:
> >>> Thanks Mike for this clear (and surprising) words.
> >>> The reason I thought it might help is that functions like this (cdns_i2c_init_recovery_info) has been added.
> >>
> >> Well if you need recovery, something is broken on the bus...
> >>
> >>> I'll check the bitbang option. Do I have to expect performance/timing issues?
> >>> I guess I have to adjust devicetree for that too? Phuuuuu. Thats always magic to me.
> >>> Kind regards, Arno
> >>
> >> Here's our devicetree that sets up the bitbank stuff:
> >>
> >> https://github.com/topic-embedded-products/linux/blob/topic-miami/arch/arm/boot/dts/topic-miami.dtsi
> >>
> >> Don't forget to activate the bitbang GPIO I2C driver in the "drivers" section
> >> of the kernel configuration as well.
> >>
> >>>
> >>>> Gesendet: Donnerstag, 04. April 2019 um 07:31 Uhr
> >>>> Von: "Mike Looijmans" <mike.looijmans at topic.nl>
> >>>> An: "Arno Steffens" <epsi at gmx.de>, "meta xilinx" <meta-xilinx at yoctoproject.org>
> >>>> Betreff: Re: [meta-xilinx] Kernel version, xilinx git repo, yocto kernel
> >>>>
> >>>> Simple solution would be to just stop using the cadence driver. There are
> >>>> issues in the Zynq that cannot really be resolved in software apparently, and
> >>>> the only way around them we've found is to just use a bitbang GPIO controller
> >>>> on the same pins. That made all problems go away.
> >>>>
> >>>> Chances are that moving to a newer kernel will not resolve your I2C issues anyway.
> >>>>
> >>>> On 03-04-19 13:53, Arno Steffens wrote:
> >>>>> I need a more recent kernel (Zynq 7000) and wondering, what can I do.
> >>>>> Why I am looking for that?
> >>>>> I have I2C issues and guess I need the recovery functionality, but the Cadence I2c driver that supports it is only in the current xilinx master branch. Even not in mainline 4.19.
> >>>>>
> >>>>> Before this I2C issue popped up I took a kernel.org LTS kernel and patch/take over the qspi/dma stuff that I need from the xilinx kernel. But this time it will not work. What would you recommend me?
> >>>>>
> >>>>> Just take to master branch? That will probably never work with RT patches ...
> >>>>> The xlx-kernel - Which kernel-org version it is based on?
> >>>>>
> >>>>> Best regards, Arno
>
> --
> _______________________________________________
> meta-xilinx mailing list
> meta-xilinx at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zynq-microzed-sp.dts
Type: audio/vnd.dts
Size: 13329 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/meta-xilinx/attachments/20190412/10333fa8/attachment.bin>