Re: [meta-xilinx] Kernel version, xilinx git repo, yocto kernel
> Gesendet: Freitag, 12. April 2019 um 19:07 Uhr > Von: "Mike Looijmans" > An: "Arno Steffens" > Cc: "meta xilinx" > 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" > >> An: "meta xilinx" > >> 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@f800/pinctrl@700/i2c0-default, deferring probe > > i2c-gpio gpios-i2c@28: could not find pctldev for node > > /amba/slcr@f800/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 tha
Re: [meta-xilinx] Kernel version, xilinx git repo, yocto kernel
Sorry, attached file didn't work, I'll try this:
/dts-v1/;
/ {
#address-cells = <0x1>;
#size-cells = <0x1>;
compatible = "avnet,microzed", "xlnx,zynq-7000";
model = "Test Device";
chosen {
bootargs = "earlyprintk";
stdout-path = "serial0:115200n8";
};
aliases {
serial0 = "/amba/serial@e0001000";
};
memory {
device_type = "memory";
reg = <0x0 0x2000>;
};
cpus {
#address-cells = <0x1>;
#size-cells = <0x0>;
cpu@0 {
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <0x0>;
clocks = <0x1 0x3>;
clock-latency = <0x3e8>;
cpu0-supply = <0x2>;
operating-points = <0xa2c2b 0xf4240 0x51616 0xf4240>;
};
cpu@1 {
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <0x1>;
clocks = <0x1 0x3>;
};
};
pmu {
compatible = "arm,cortex-a9-pmu";
interrupts = <0x0 0x5 0x4 0x0 0x6 0x4>;
interrupt-parent = <0x3>;
reg = <0xf8891000 0x1000 0xf8893000 0x1000>;
};
fixedregulator@0 {
compatible = "regulator-fixed";
regulator-name = "VCCPINT";
regulator-min-microvolt = <0xf4240>;
regulator-max-microvolt = <0xf4240>;
regulator-boot-on;
regulator-always-on;
linux,phandle = <0x2>;
phandle = <0x2>;
};
amba {
compatible = "simple-bus";
#address-cells = <0x1>;
#size-cells = <0x1>;
interrupt-parent = <0x3>;
ranges;
adc@f8007100 {
compatible = "xlnx,zynq-xadc-1.00.a";
reg = <0xf8007100 0x20>;
interrupts = <0x0 0x7 0x4>;
interrupt-parent = <0x3>;
clocks = <0x1 0xc>;
};
can@e0008000 {
compatible = "xlnx,zynq-can-1.0";
status = "disabled";
clocks = <0x1 0x13 0x1 0x24>;
clock-names = "can_clk", "pclk";
reg = <0xe0008000 0x1000>;
interrupts = <0x0 0x1c 0x4>;
interrupt-parent = <0x3>;
tx-fifo-depth = <0x40>;
rx-fifo-depth = <0x40>;
};
can@e0009000 {
compatible = "xlnx,zynq-can-1.0";
status = "disabled";
clocks = <0x1 0x14 0x1 0x25>;
clock-names = "can_clk", "pclk";
reg = <0xe0009000 0x1000>;
interrupts = <0x0 0x33 0x4>;
interrupt-parent = <0x3>;
tx-fifo-depth = <0x40>;
rx-fifo-depth = <0x40>;
};
gpio@e000a000 {
compatible = "xlnx,zynq-gpio-1.0";
#gpio-cells = <0x2>;
clocks = <0x1 0x2a>;
gpio-controller;
interrupt-controller;
#interrupt-cells = <0x2>;
interrupt-parent = <0x3>;
interrupts = <0x0 0x14 0x4>;
reg = <0xe000a000 0x1000>;
linux,phandle = <0x6>;
phandle = <0x6>;
};
/* removed cadence stuff
i2c@e0004000 {
compatible = "cdns,i2c-r1p10";
status = "okay";
clocks = <0x1 0x26>;
interrupt-parent = <0x3>;
interrupts = <0x0 0x19 0x4>;
reg = <0xe0004000 0x1000>;
#address-cells = <0x1>;
#size-cells = <0x0>;
};
i2c@e0005000 {
compatible = "cdns,i2c-r1p10";
status = "okay";
clocks = <0x1 0x27>;
interrupt-parent = <0x3>;
interrupts = <0x0 0x30 0x4>;
reg = <0xe0005000 0x1000>;
#address-cells = <0x1>;
#size-cells = <0x0>;
};
*/
interrupt-controller@f8f01000 {
compatible = "arm,cortex-a9-gic";
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" >> An: "meta xilinx" >> 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@f800/pinctrl@700/i2c0-default, deferring probe > i2c-gpio gpios-i2c@28: could not find pctldev for node > /amba/slcr@f800/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" >>>> An: "Arno Steffens" >>>> Cc: "meta xilinx" >>>> 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/
Re: [meta-xilinx] Kernel version, xilinx git repo, yocto kernel
> Gesendet: Mittwoch, 10. April 2019 um 07:39 Uhr > Von: "Mike Looijmans" > An: "meta xilinx" > 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@f800/pinctrl@700/i2c0-default, deferring probe i2c-gpio gpios-i2c@28: could not find pctldev for node /amba/slcr@f800/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" > >> An: "Arno Steffens" > >> Cc: "meta xilinx" > >> 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? Phu. 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" > >>>> An: "Arno Steffens" , "meta xilinx" > >>>> > >>>> Betreff: Re: [meta-xilinx] Kernel version, xilinx git repo, yocto kernel >
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. >> Gesendet: Freitag, 05. April 2019 um 07:44 Uhr >> Von: "Mike Looijmans" >> An: "Arno Steffens" >> Cc: "meta xilinx" >> 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? Phu. 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" >>>> An: "Arno Steffens" , "meta xilinx" >>>> >>>> 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
Re: [meta-xilinx] Kernel version, xilinx git repo, yocto kernel
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. > Gesendet: Freitag, 05. April 2019 um 07:44 Uhr > Von: "Mike Looijmans" > An: "Arno Steffens" > Cc: "meta xilinx" > 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? Phu. 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" > >> An: "Arno Steffens" , "meta xilinx" > >> > >> 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
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? Phu. 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" >> An: "Arno Steffens" , "meta xilinx" >> >> 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
Re: [meta-xilinx] Kernel version, xilinx git repo, yocto kernel
Hi Arno, On 03.04.19 13:53, Arno Steffens wrote: 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. The reason that the driver is not mainline is most likely __NOT__ because it's such a great piece of code. But apparently also relatively simple things like I2C hardware blocks can be suboptimal. Combine non upstream drivers with suboptimal hardware and have fun with it. Regards, Robert -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
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
Re: [meta-xilinx] Kernel version, xilinx git repo, yocto kernel
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. I'll check the bitbang option. Do I have to expect performance/timing issues? I guess I have to adjust devicetree for that too? Phu. Thats always magic to me. Kind regards, Arno > Gesendet: Donnerstag, 04. April 2019 um 07:31 Uhr > Von: "Mike Looijmans" > An: "Arno Steffens" , "meta xilinx" > > 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
[meta-xilinx] Kernel version, xilinx git repo, yocto kernel
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
