Hello F&S-support,
according to some entries in the forum there are open items in release 2.0 of the Multi-Platform package. I was wondering whether there will be an update containing all those patches floating around/promised in the threads.
Regards,
Volker
Would be interesting for us too.
Yes, we know that the Multi-Platform Linux was a little neglected in the past few months. As you may know, we had some problems this year with quite a lot of CPUs that were discontinued by the Manufacturer rather surprisingly. So in turn we had to discontinue some of our most important boards and modules. This urgently required the introduction of a set of successor boards, and, as a consequence, our highest priority was to get these new boards up and running to be able to provide our existing customers with replacements. At the same time two of our Linux developers were enticed away by a headhunter, so our Linux department was considerably reduced. Unfortunately this meant that the boards based on Samsung S5PV210 CPU (armStoneA8, NetDCU14 and PicoMOD7A) were a little out of focus for a while.
Nevertheless, all these new boards introduced this year are on a good way now. They need some more fine tuning, but in general they are working. And our department is again staffed with new people, so the momentum regarding Linux development will increase again.
As a next step we will try to add the new boards (based on Freescale Vybrid CPU and Freescale i.MX6 CPU) to our Multi-Platform Linux. This will take a few more weeks as this is no easy task. But when this is done, progress will continue with all these boards, so we expect that the S5PV210 platform will get updates more regularly again as part of the then enhanced Multi-Platform release. So I think we will see newer kernel versions in Q1 of next year.
Your F&S Development Team
First of all, I would like to wish you all a good start in this New Year !
I must admit that I didn't track the CPU roadmap of most developers but I noticed that there is quite a lot going on. I saw that TI tries to provide a longer time-on-market with their Sitara processor series and some manufacturers provide a drop-in replacement, for example Allwinner. I also noticed that TI is remarkably active in respect to the Linux support, even an SDK for the PowerVR SGX530 is available and support for OpenGL is on the way (something we will IMHO never get for the Samsung S5PV210 CPU, at least not for the Multi-Platform Linux). Even CAN seems to be on-board. Possibly this could be an option for the next NetDCU version.
Unfortunately we cannot wait until the successor of the NetDCU14 is released. I'm afraid we cannot even wait until end of Q1/2014. So I hope we will see a new version a little bit sooner. In the meantime I backported some bugfixes applied to the mainstream driver for the MCP251x mainly to exclude observerations that may be reported due to outdated drivers (also seems to solve the problem described in this topic : <!-- l --><a class="postlink-local" href="http://www.forum.fs-net.de/viewtopic.php?f=60&t=3362">viewtopic.php?f=60&t=3362</a><!-- l -->). So I would recommend to pick at least kernel 3.12, even 3.13 if possible for the new version of the Multi-Platform Linux.
Regards,
Volker
Hello F&S-support,
Q1 has passed and nothing has happened in respect to the next version. In the meantime we integrated our boards in the system and ran into some serious problems. Some of these we were able to handle (see my other postings according to CAN interfaces).
Now we observe CAN message losses when running the CAN bus at 500 kHz and roughly 10 % busload. Checking the throughput we discovered CAN message loss, about 3 % depending on the CPU load (3 % is the best case we observed with the CPU running idle). candump reports rx overruns.
Searching the internet reveals that this is a common problem with the MCP2515 in combination with some 3.x kernels and the default kernel driver. There are also some solutions out there including improvements to the SPI interface and an alternative driver.
In my opinion this is a really serious bug in the board support package that must be addressed and fixed as fast as possible.
Regards,
Volker
Have you included all the changes of V2.0 in your own image? Especially the irq_flags for mcp251x_info* in mach-netdcu14.c have to be set to IRQF_TRIGGER_LOW | IRQF_ONESHOT to fetch all interrupts and the SPI speed for the mcp2515 entries in netdcu14_spi_slaves[] must be set to 10000000 to have the best throughput. With these settings, most of the non-LED-specific modifications of your patch are already included in our version.
Using IRQF_TRIGGER_FALLING will not work with MCP2515, the IRQ is definitely a low IRQ. Setting it to IRQF_TRIGGER_FALLING will miss some interrupts. This was wrong in the driver from the beginning on, I don't understand why they ever did that in the original driver.
Your F&S Support Team
I definitely know that we didn't apply all the changes provided after the release of V2.0 but we did apply those patches that are important for us. This includes the patch you mentioned. I also double-checked that before answering. Interestingly the statements about IRQF_TRIGGER_LOW differ a bit. I've read the following :
Quote'Note that the "IRQF_ONESHOT" flag is only required for kernel 3.6. For kernel 3.2 you should remove it. Adjust the GPIO pin used for interrupt (here 25), the SPI frequency (here 10MHz) and MCP2515 oscillator frequency (here 20MHz) to your setup.'
(<!-- m --><a class="postlink" href="http://elinux.org/RPi_CANBus">http://elinux.org/RPi_CANBus</a><!-- m -->)
But I don't know enough to decide which is wrong and which is right.
See again that they have IRQF_TRIGGER_FALLING in the RPi code of your link. THIS DOES NOT WORK. The MCP2515 has a low-level IRQ which means that if the interrupt service thread does not handle all interrupts and leaves the routine, the IRQ line will stay low. If you use IRQF_TRIGGER_FALLING, then there will be no further interrupt (as there is no further falling edge) and you will miss messages. If you use IRQF_TRIGGER_LOW, then the interrupt will immediately be triggered again and the remaining stuff will be handled. So IRQF_TRIGGER_LOW is the only possible way to handle this interrupt correctly.
And when using an interrupt service thread combined with a level triggered interrupt, you'll definitely need IRQF_ONESHOT or you'll end up in an endless loop with a forever hitting IRQ.
The reason for the IRQF_TRIGGER_FALLING in the MCP2515 driver code was that the code originally was targeted for an Atmel CPU that did not support level interrupts at all. So they used IRQF_TRIGGER_FALLING as a replacement, but they also modified the code of the internal interrupt service routine of the Atmel CPU to handle level interrupts correctly by reporting them as edge interrupts. So the driver code does *not* work with IRQF_TRIGGER_FALLING without also modifying the IRQ subsystem, too. This is what many people are missing and then they get problems with the MCP2515 driver.
We had an intermediate patch here on the forum that also did the wrong thing and tried to use IRQF_TRIGGER_FALLING. But this was fixed in V2.0 and was replaced by IRQF_TRIGGER_LOW | IRQF_ONESHOT. So you should check if your settings in mach_netdcu14.c actually match this V2.0 version. This is related to the MCP251x settings directly and also to the SPI configuration.
What I'm currently not aware of is if the SPI driver can be optimized. Here it may be possible that a newer SPI driver is more efficient and can therefore help increase the throughput. The version that the RPi code uses seems to come from linux-3.6. You can try yourself if you can get this newer version running on our 3.3.7 kernel.
Your F&S Support Team
As I said we're using V2.0 and some patches, more precisely the following :
* NetDCU14-Correct-UART-configuration.-UART0-with-RTS-.patch
* Activate-TOUT1-PWM.1-via-backlight-system.patch
* Add-hwmon-support-to-read-ADC-channels.patch
* linux-mcp251x-20130423_plus.patch (The one I mentioned somewhere above)
So we definitely have IRQF_TRIGGER_LOW | IRQF_ONESHOT set in our mach-netdcu14.c and I checked that.
I also made a quick glance at the SPI driver and it seems to me that this is a not so easy task. Additionally these changes may interfere with some other changes made by the F&S team (spi-s3c64xx.c). Another approach I tried was to generate a patch based upon the changes made by F&S in respect to stock 3.3.7 and to apply these changes to 3.6.11 which of course returns with a lot of errors.
The one option left together with multiplatform 2.0 I can see is trying the alternative driver mcp2515.c which I will do next.
Can you give us a quick report about the progress for the next Multi-Platform release ?
Regards
Volker
So far we had no luck integrating the alternative driver for the MCP2515. So we are back to square one, hoping for a new release fixing all our problems.
Regards
Volker
