<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=utf-8" http-equiv=Content-Type>
<STYLE>
BLOCKQUOTE {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px; MARGIN-LEFT: 2em
}
OL {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
UL {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
P {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
BODY {
LINE-HEIGHT: 1.5; FONT-FAMILY: 微软雅黑; COLOR: #000000; FONT-SIZE: 10.5pt
}
</STYLE>
<META name=GENERATOR content="MSHTML 8.00.7600.17267"></HEAD>
<BODY style="MARGIN: 10px">
<DIV>Hi, all</DIV>
<DIV> </DIV>
<DIV>Thanks for your advices. Actually, I want to continue this project
after the GSoC2013. I think there are still lots of work we need to do in the
future, such as adding some more effective tests for PCI-CAN device,
investing into QEMU mainline and also some others that Pavel Pisa
suggested.
<DIV> </DIV></DIV>
<DIV>Thanks,</DIV>
<DIV>Jin Yang</DIV>
<HR style="WIDTH: 210px; HEIGHT: 1px" align=left color=#b5c4df SIZE=1>
<DIV><SPAN>
<DIV style="FONT-FAMILY: verdana; FONT-SIZE: 10pt">
<DIV>jinyang.sia@gmail.com</DIV></DIV></SPAN></DIV>
<DIV> </DIV>
<DIV
style="BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0cm; PADDING-LEFT: 0cm; PADDING-RIGHT: 0cm; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<DIV
style="PADDING-BOTTOM: 8px; PADDING-LEFT: 8px; PADDING-RIGHT: 8px; FONT-FAMILY: tahoma; BACKGROUND: #efefef; COLOR: #000000; FONT-SIZE: 12px; PADDING-TOP: 8px">
<DIV><B>From:</B> <A href="mailto:gedare@rtems.org">Gedare Bloom</A></DIV>
<DIV><B>Date:</B> 2013-09-16 20:57</DIV>
<DIV><B>To:</B> <A
href="mailto:jinyang.sia@gmail.com">jinyang.sia@gmail.com</A></DIV>
<DIV><B>CC:</B> <A href="mailto:ppisa4lists@pikron.com">Pavel Pisa</A>; <A
href="mailto:cynt6007@vandals.uidaho.edu">Rempel, Cynthia</A>; <A
href="mailto:chrisj@rtems.org">Chris Johns</A>; <A
href="mailto:rtems-devel@rtems.org">RTEMS Devel</A></DIV>
<DIV><B>Subject:</B> Re: [GSoC] CAN SJA1000</DIV></DIV></DIV>
<DIV>
<DIV>Jin Yang, you should incorporate these notes and suggestions to your</DIV>
<DIV>project's wrap-up / summary descriptions. If you are interested in</DIV>
<DIV>continuing after GSoC with this project I think this will be a good</DIV>
<DIV>direction to head.</DIV>
<DIV>-Gedare</DIV>
<DIV> </DIV>
<DIV>On Sun, Sep 15, 2013 at 3:56 PM, Pavel Pisa <ppisa4lists@pikron.com>
wrote:</DIV>
<DIV>> Hello Jin Yang and all others,</DIV>
<DIV>></DIV>
<DIV>> congratulation to achieving the main goal.</DIV>
<DIV>></DIV>
<DIV>> I have read your instructions and build sucesfull</DIV>
<DIV>> the QEMU on AMD64 Debian Wheezy.</DIV>
<DIV>> I have run the compiled QEMU with 64-bit 3.2.x kernel</DIV>
<DIV>> used on a host and guest side of the QEMU.</DIV>
<DIV>></DIV>
<DIV>> I have included board integration into LinCAN driver</DIV>
<DIV>></DIV>
<DIV>>
http://sourceforge.net/p/ortcan/lincan/ci/master/tree/lincan/src/pcisja1000mm.c</DIV>
<DIV>></DIV>
<DIV>> and run successfully LinCAN test tools on the guest side</DIV>
<DIV>> against your SJA1000 HW emulation. I have connected host</DIV>
<DIV>> side to the virtual SocketCAN bus and used OrtCAN qCANalyzer</DIV>
<DIV>> on the host side</DIV>
<DIV>></DIV>
<DIV>> http://ortcan.sourceforge.net/qcanalyzer/</DIV>
<DIV>></DIV>
<DIV>> I have not found any problems during this test.</DIV>
<DIV>> But tat is quit simple test and it would worth to</DIV>
<DIV>> try some more demanding testing. But as you know</DIV>
<DIV>> we are not fast (unfortuantelly) in many cases so</DIV>
<DIV>> it would take some time. Anyway it worth to run</DIV>
<DIV>> our CAN Benchmarks to torture code and clean possible</DIV>
<DIV>> bugs</DIV>
<DIV>></DIV>
<DIV>> http://rtime.felk.cvut.cz/can/</DIV>
<DIV>></DIV>
<DIV>> By the way, we have included actual MPC5200 RTEMS CAN</DIV>
<DIV>> driver into our benchmarks this summer and results are</DIV>
<DIV>> quite in favor for RTEMS but that is partially caused</DIV>
<DIV>> by dummy implementation of CAN gateway user on RTEMS</DIV>
<DIV>> for testing. But that worths separate e-mail as we</DIV>
<DIV>> finish the work.</DIV>
<DIV>></DIV>
<DIV>> As for actual Jin Yang's QEMU CAN code, I think that</DIV>
<DIV>> it is valuable achievement for GSoC project and if</DIV>
<DIV>> stability is confirmed by testing, it is good base</DIV>
<DIV>> for RTEMS CAN infrastructure development.</DIV>
<DIV>></DIV>
<DIV>> On the other hand, for long term sustainability</DIV>
<DIV>> it is required to invest into inclusion of code</DIV>
<DIV>> to the QEMU mainline. This requires to port code</DIV>
<DIV>> to the actual QEMU git version. I do not know</DIV>
<DIV>> how big amount it means because QEMU is fast</DIV>
<DIV>> mowing target. It may be above GSoC project contract</DIV>
<DIV>> size. But it really worth to be done.</DIV>
<DIV>></DIV>
<DIV>> As for the code review, I think that there is too</DIV>
<DIV>> much CAN specific code push into generic qemu-char.c</DIV>
<DIV>> file</DIV>
<DIV>></DIV>
<DIV>> qemu-jin-yang/qemu-char.c</DIV>
<DIV>></DIV>
<DIV>> The registration in actual QEMU git version seems to be more</DIV>
<DIV>> modular</DIV>
<DIV>></DIV>
<DIV>> register_char_driver_qapi("parallel",
CHARDEV_BACKEND_KIND_PARALLEL,</DIV>
<DIV>>
qemu_chr_parse_parallel);</DIV>
<DIV>></DIV>
<DIV>> The all SocketCAN specific code has to be moved to other</DIV>
<DIV>> file and there must be mechanism to disable build of that</DIV>
<DIV>> code</DIV>
<DIV>></DIV>
<DIV>> qemu-jin-yang/qemu-char.c</DIV>
<DIV>> +#include <linux/can.h></DIV>
<DIV>> +#include <linux/can/raw.h></DIV>
<DIV>></DIV>
<DIV>> The reason is that SocketCAN is Linux specific and that part</DIV>
<DIV>> of the code included in the common QEMU infrastructure</DIV>
<DIV>> would made it non-portable.</DIV>
<DIV>></DIV>
<DIV>> As for the actual can controller emulation, it is/or can be</DIV>
<DIV>> made fully portable to all host systems and for all target</DIV>
<DIV>> configurations which support PCI</DIV>
<DIV>></DIV>
<DIV>> qemu-jin-yang/hw/can-pci.c</DIV>
<DIV>></DIV>
<DIV>> It would worth to separate SJA1000 part of the code from</DIV>
<DIV>> PCI mapping to allows use SJA1000 emulator even on non-PCI</DIV>
<DIV>> platforms. It would worth even to allows to use SJA1000</DIV>
<DIV>> emulator with different PCI cards mapping. The most of real</DIV>
<DIV>> CAN interface cards have more PCI regions/BARs and actual CAN</DIV>
<DIV>> chips are mapped to region 1 or 2. Region 0 is usually used</DIV>
<DIV>> to control PCI bridge part of the card. Use of generic PCI</DIV>
<DIV>> bridge chips usually means that some interrupt configuration</DIV>
<DIV>> is required in this bridge control area.</DIV>
<DIV>> But these two are not high priority for now.</DIV>
<DIV>></DIV>
<DIV>> As for actual SJA1000 chip emulation, I would prefer personally</DIV>
<DIV>> if the register bit masks are not hardcoded by numbers but</DIV>
<DIV>> if some better readable constants are used. I.e.</DIV>
<DIV>></DIV>
<DIV>>
http://sourceforge.net/p/ortcan/lincan/ci/master/tree/lincan/include/sja1000p.h</DIV>
<DIV>></DIV>
<DIV>> But again that can be done later.</DIV>
<DIV>></DIV>
<DIV>> Best wishes,</DIV>
<DIV>></DIV>
<DIV>>
Pavel Pisa</DIV>
<DIV>></DIV>
<DIV>></DIV>
<DIV>> On Sunday 15 of September 2013 10:16:39 jinyang.sia@gmail.com
wrote:</DIV>
<DIV>>> Hi,</DIV>
<DIV>>></DIV>
<DIV>>> I just update the
http://wiki.rtems.org/wiki/index.php/Qemu_simulations</DIV>
<DIV>>> remove some unecessary data and add some new information. Some of
them is</DIV>
<DIV>>> not complete. However I don't know how to upload pictures to the
site?</DIV>
<DIV>>></DIV>
<DIV>>> Thanks,</DIV>
<DIV>>> Jin Yang</DIV>
<DIV>>></DIV>
<DIV>>></DIV>
<DIV>>></DIV>
<DIV>>></DIV>
<DIV>>> jinyang.sia@gmail.com</DIV></DIV></BODY></HTML>