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

Fri Apr 12 10:07:42 PDT 2019

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.

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