> 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) 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? A nice weekend, Arno > >> 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 >
zynq-microzed-sp.dts
Description: audio/vnd.dts
-- _______________________________________________ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
