Hi, allI'm graduate student from china. I participated the GSoC project last year with the almost same title. However, what I have done last year is to build a simulation environment, so the CAN (Controller Area Network) driver ported could be tested by everyone. Details you can get through http://www.rtems.org/wiki/index.php/Qemu_simulations, you can also get something usefull information through my personal blog http://jin-yang.github.io/ some days later. I just adjust the blog's layout, and most of the blogs were deleted. Actually the reason is I didn't figure out how to insert pictures to RTEMS-WiKi :-( Another IMPORTANT thing I want to say is about the last year's Project. I really feel sorry for what I have done after the gsoc last year. After the GSoC, actually there are still somethings to do as Pavel Pisa suggested, this will posted at the end of mail. I had to find a job and also prepared for my graduation(I will graduate this year, but it's valid for GSoC2014) so a lot of time was spent on these things. The other reason maybe because I think our final goal is to port LinCAN to RTEMS so what I have done last year was just a middle step. Then I just start to learn how RTEMS works and somethings like that. Little attention was paid to the QEMU. It's my fault. I will try to fix the problems occured last year as soon as possible. Since I have built the CAN simulation environment last year, so maybe i could be a better choice to port the LinCAN to RTEMS. That's why I want to participate this year's GSoC. I have write a proposal for this year's GSoC at https://docs.google.com/document/d/12T2Sd9vDBGfMhlansaW0Ti2OmtrpRPgAXxdPuOHbM78. Some of the contents is same with the last year's proposal, some of the quesions we have discussed last year, details you may reference https://docs.google.com/document/d/1PCJ4MAR03fH2tm22AA_OD-h5Xlh68yYL08y9bBOIkCM. However, I still want to get some advices from anyone. Best Regards, Jin Yang. ===================================================Letter form Pavel Pisa===================================================Hello Jin Yang and all others, congratulation to achieving the main goal. I have read your instructions and build sucesfullthe QEMU on AMD64 Debian Wheezy.I have run the compiled QEMU with 64-bit 3.2.x kernelused on a host and guest side of the QEMU. I have included board integration into LinCAN driver http://sourceforge.net/p/ortcan/lincan/ci/master/tree/lincan/src/pcisja1000mm.c and run successfully LinCAN test tools on the guest sideagainst your SJA1000 HW emulation. I have connected hostside to the virtual SocketCAN bus and used OrtCAN qCANalyzeron the host side http://ortcan.sourceforge.net/qcanalyzer/ I have not found any problems during this test.But tat is quit simple test and it would worth totry some more demanding testing. But as you knowwe are not fast (unfortuantelly) in many cases soit would take some time. Anyway it worth to runour CAN Benchmarks to torture code and clean possiblebugs http://rtime.felk.cvut.cz/can/ By the way, we have included actual MPC5200 RTEMS CANdriver into our benchmarks this summer and results arequite in favor for RTEMS but that is partially causedby dummy implementation of CAN gateway user on RTEMSfor testing. But that worths separate e-mail as wefinish the work. As for actual Jin Yang's QEMU CAN code, I think thatit is valuable achievement for GSoC project and ifstability is confirmed by testing, it is good basefor RTEMS CAN infrastructure development. On the other hand, for long term sustainabilityit is required to invest into inclusion of codeto the QEMU mainline. This requires to port codeto the actual QEMU git version. I do not knowhow big amount it means because QEMU is fastmowing target. It may be above GSoC project contractsize. But it really worth to be done. As for the code review, I think that there is toomuch CAN specific code push into generic qemu-char.cfile qemu-jin-yang/qemu-char.c The registration in actual QEMU git version seems to be moremodular register_char_driver_qapi("parallel", CHARDEV_BACKEND_KIND_PARALLEL, qemu_chr_parse_parallel); The all SocketCAN specific code has to be moved to otherfile and there must be mechanism to disable build of thatcode qemu-jin-yang/qemu-char.c+#include <linux/can.h>+#include <linux/can/raw.h> The reason is that SocketCAN is Linux specific and that partof the code included in the common QEMU infrastructurewould made it non-portable. As for the actual can controller emulation, it is/or can bemade fully portable to all host systems and for all targetconfigurations which support PCI qemu-jin-yang/hw/can-pci.c It would worth to separate SJA1000 part of the code fromPCI mapping to allows use SJA1000 emulator even on non-PCIplatforms. It would worth even to allows to use SJA1000emulator with different PCI cards mapping. The most of realCAN interface cards have more PCI regions/BARs and actual CANchips are mapped to region 1 or 2. Region 0 is usually usedto control PCI bridge part of the card. Use of generic PCIbridge chips usually means that some interrupt configurationis required in this bridge control area.But these two are not high priority for now. As for actual SJA1000 chip emulation, I would prefer personallyif the register bit masks are not hardcoded by numbers butif some better readable constants are used. I.e. http://sourceforge.net/p/ortcan/lincan/ci/master/tree/lincan/include/sja1000p.h But again that can be done later. Best wishes, Pavel Pisa jinyang....@gmail.com
_______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
