> Gesendet: Freitag, 12. April 2019 um 19:07 Uhr > Von: "Mike Looijmans" <mike.looijm...@topic.nl> > An: "Arno Steffens" <e...@gmx.de> > Cc: "meta xilinx" <meta-xilinx@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.looijm...@topic.nl> > >> An: "meta xilinx" <meta-xilinx@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@22: could not find pctldev for node > > /amba/slcr@f8000000/pinctrl@700/i2c0-default, deferring probe > > i2c-gpio gpios-i2c@28: could not find pctldev for node > > /amba/slcr@f8000000/pinctrl@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@22: Retrying from deferred list microzed-zynq7 user.debug kernel: bus: 'platform': driver_probe_device: matched device gpios-i2c@22 with driver i2c-gpio microzed-zynq7 user.debug kernel: bus: 'platform': really_probe: probing driver i2c-gpio with device gpios-i2c@22 microzed-zynq7 user.info kernel: i2c-gpio gpios-i2c@22: could not find pctldev for node /amba/slcr@f8000000/pinctrl@700/i2c0-default, deferring probe microzed-zynq7 user.debug kernel: i2c-gpio gpios-i2c@22: no pinctrl handle microzed-zynq7 user.debug kernel: platform gpios-i2c@22: Driver i2c-gpio requests probe deferral microzed-zynq7 user.debug kernel: platform gpios-i2c@22: Added to deferred list microzed-zynq7 user.debug kernel: platform gpios-i2c@28: Retrying from deferred list microzed-zynq7 user.debug kernel: bus: 'platform': driver_probe_device: matched device gpios-i2c@28 with driver i2c-gpio microzed-zynq7 user.debug kernel: bus: 'platform': really_probe: probing driver i2c-gpio with device gpios-i2c@28 microzed-zynq7 user.info kernel: i2c-gpio gpios-i2c@28: could not find pctldev for node /amba/slcr@f8000000/pinctrl@700/i2c1-default, deferring probe microzed-zynq7 user.debug kernel: i2c-gpio gpios-i2c@28: no pinctrl handle microzed-zynq7 user.debug kernel: platform gpios-i2c@28: Driver i2c-gpio requests probe deferral microzed-zynq7 user.debug kernel: platform gpios-i2c@28: Added to deferred list microzed-zynq7 user.debug kernel: platform gpios-i2c@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.looijm...@topic.nl> > >>>> An: "Arno Steffens" <e...@gmx.de> > >>>> Cc: "meta xilinx" <meta-xilinx@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.looijm...@topic.nl> > >>>>>> An: "Arno Steffens" <e...@gmx.de>, "meta xilinx" > >>>>>> <meta-xilinx@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@yoctoproject.org > >> https://lists.yoctoproject.org/listinfo/meta-xilinx > >> > > > > > -- > Mike Looijmans > -- _______________________________________________ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
