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

Tue Apr 16 00:36:42 PDT 2019

> Gesendet: Freitag, 12. April 2019 um 19:07 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 12-04-19 15:39, Arno Steffens wrote:
> >
> >
> >> 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)
>
> Yeah, Xilinx is very unclear about that stuff. Some of the PS settings
> end up in the bootloader, but quite a lot (like the PS-PL
> intercommunication) doesn't end up anywhere at all and just serves to
> make Vivado show or hide pins on the processor IP.
>
> > 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?
>
> I think your kernel is lacking the zynq pinmux driver, run the kernel's
> menuconfig and enable it.

Zync-Pinmux driver has been already enabled, just to be sure I added the CONFIG_GENERIC_PINMUX_FUNCTIONS: with no change.
In a next attemped I changed back to the old FSBL (with pinmux to i2c hardware) - same.
As mentioned I can get rid of this kernel-message by removing last line in devicetree - but no dev-node /dev/i2c-0 or 1 will be created.
I added to kernel some debug statements and get in messages (just that with i2c in it):

microzed-zynq7 user.debug kernel: bus: 'i2c': add driver rtc-pcf8563
microzed-zynq7 user.debug kernel: i2c-core: driver [rtc-pcf8563] registered
microzed-zynq7 user.info kernel: i2c /dev entries driver
microzed-zynq7 user.debug kernel: device class 'i2c-dev': registering
microzed-zynq7 user.debug kernel: bus: 'i2c': add driver pmbus
microzed-zynq7 user.debug kernel: i2c-core: driver [pmbus] registered
microzed-zynq7 user.debug kernel: bus: 'i2c': add driver ucd9000
microzed-zynq7 user.debug kernel: i2c-core: driver [ucd9000] registered
microzed-zynq7 user.debug kernel: bus: 'i2c': add driver ucd9200
microzed-zynq7 user.debug kernel: i2c-core: driver [ucd9200] registered
microzed-zynq7 user.debug kernel: platform gpios-i2c at 22: Retrying from deferred list
microzed-zynq7 user.debug kernel: bus: 'platform': driver_probe_device: matched device gpios-i2c at 22 with driver i2c-gpio
microzed-zynq7 user.debug kernel: bus: 'platform': really_probe: probing driver i2c-gpio with device gpios-i2c at 22
microzed-zynq7 user.info kernel: i2c-gpio gpios-i2c at 22: could not find pctldev for node /amba/slcr at f8000000/pinctrl at 700/i2c0-default, deferring probe
microzed-zynq7 user.debug kernel: i2c-gpio gpios-i2c at 22: no pinctrl handle
microzed-zynq7 user.debug kernel: platform gpios-i2c at 22: Driver i2c-gpio requests probe deferral
microzed-zynq7 user.debug kernel: platform gpios-i2c at 22: Added to deferred list
microzed-zynq7 user.debug kernel: platform gpios-i2c at 28: Retrying from deferred list
microzed-zynq7 user.debug kernel: bus: 'platform': driver_probe_device: matched device gpios-i2c at 28 with driver i2c-gpio
microzed-zynq7 user.debug kernel: bus: 'platform': really_probe: probing driver i2c-gpio with device gpios-i2c at 28
microzed-zynq7 user.info kernel: i2c-gpio gpios-i2c at 28: could not find pctldev for node /amba/slcr at f8000000/pinctrl at 700/i2c1-default, deferring probe
microzed-zynq7 user.debug kernel: i2c-gpio gpios-i2c at 28: no pinctrl handle
microzed-zynq7 user.debug kernel: platform gpios-i2c at 28: Driver i2c-gpio requests probe deferral
microzed-zynq7 user.debug kernel: platform gpios-i2c at 28: Added to deferred list
microzed-zynq7 user.debug kernel: platform gpios-i2c at 22: Retrying from deferred list
...

>
> If you've already changed the pinmux in the FSBL, you can remove the
> pinmux references "pinctrl-names" and "pinctrl-0" from the gpio driver
> and that should also work, without the pinmux driver that is.

For now I would better keep it in, a reconfiguration again shoudn't matter. Just to be sure.
Seems to be an easier task to switch to bitbang as it is in real...

Found a patch (https://patchwork.kernel.org/patch/7464441/) from you, wondering if this becomes part of mainline (I am on 4.14.52 kernel.org)

Cheers
Arno

>
> > A nice weekend,
>
> Same!
>
> >
> >>>> 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
> >>
> >
>
>
> --
> Mike Looijmans
>