Thanks a lot for your input. FlexCAN now is up and running with Yocto Linux. See the following patch: https://github.com/modbas/meta-modb...x-udooboard-3.14.56/0001-enable-flexcan.patch
I have a similar patch https://github.com/graugans/meta-ud...-Enable-FlexCAN-interfaces-for-UDOO-Neo.patch + some logic to enable it (krogoth branch) Plus a patch to enable spi https://github.com/graugans/meta-ud...oard/udooneo/0020-udooneo-enable-ecspi2.patch Gesendet von meinem FP2 mit Tapatalk
I was wondering if simply connecting Tx (Pin40) from one board to same pin on another (same with Pin41) would be enough to simply test before I will get transreivers? Do I still have to put resistor across?
As already mentioned its not possible (or that simple). The first post in the thread already covers the procedure for verifying without a transceiver.
Hello. I did read quite a lot about CAN by now but framing and from software perspective but need little help from electrical I got couple of these http://www.waveshare.com/wiki/SN65HVD230_CAN_Board#Support Loopback works fine. So I have couple of questions and do not want to damage my boards. Looking at dmesg I see these lines 2090000.can supply xceiver not found, using dummy regulator. Is this issue? How does full proper dmesg | grep can looks like on yours? Update: I was able to figure this out and got it working . Still wondering about above question related to xceiver not found.
I've tried these, but it doesn't work for me. Seems to be not using the correct .dtb file on boot. My board uses this one: reading dts-overlay/imx6sx-udoo-neo-full-hdmi-m4.dtb This is my latest uEnv.txt: video_output=hdmi #m4_enabled=false #m4last=/path/to/arduino/sketch.fw fdt_file=imx6sx-udoo-neo-full-hdmi-can.dtb use_custom_dtb=true I've tried this: fdt_file=dts-overlay/imx6sx-udoo-neo-full-hdmi-can.dtb But it always still uses the same dtb file: reading dts-overlay/imx6sx-udoo-neo-full-hdmi-m4.dtb How can I make uboot read the proper dtb file? I don't find any examples of uEnv.txt and uboot, etc. so I don't know if what I am doing is even correct. Thanks, Randy Krakora
uboot overrides your fdt_file value when it detects the board type so the value is ignored. I'm not sure what your trying to achieve, however you can just copy your changed dtb to correct dtb in the overlay directory, that's the point of the overlay directory ie: Code: cp imx6sx-udoo-neo-full-hdmi-can.dtb imx6sx-udoo-neo-full-hdmi.dtb
Thanks for taking the time to reply, but it didn't answer my question, I was wanting to know how uEnv.txt worked, it appears to have some replacement environment variables in it to override uboot? But when I try to do that, it doesn't work. I know I could simply rename my file to imx6sx-udoo-neo-full-hdmi-m4.dtb and uboot would load it and things would work, but I just cannot do that in good conscience. Especially when the filenames are very relevant. Why should I rename my file to a name that isn't descriptive to me? It defeats the purpose of having filenames. And if uEnv.txt is useless, why is it used? Why not just have us change the uboot env. variable at boot for loading different .dtb files? And I wondered why my board was using the imx6sx-udoo-neo-full-hdmi-m4.dtb instead of the reading imx6sx-udoo-neo-full-hdmi.dtb file? Hopefully someone can point me to some docs or help describe how this works ( not only for me, but for other community members that may have questions about this now or in the future ). Thanks, Randy Krakora
Simple answer review the uboot source to find out why its happen and change/fix it to your preference.
Thanks again, but not what I was looking for, I'm fine with reviewing the source, but in my opinion, if we have to review the source to figure out how uEnv.txt works, then why is uEnv.txt even part of the system? Makes no sense. Make the dtb/fdt filename a uboot variable we change and be done with it. "Review the source" could be the answer to just about any question I've seen in this forum. -RK
One for the udoo team to answer as it their design @Andrea Rovai. Like it or not and given the size of the community that's probably true.