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. 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. > 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