<!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>I just read this e-mail today. didn't check the e-mail for a long time,
because a little busy on the graduation stuffs. I still want to do
something on this project. So, i would like to working on anything i can
help.</DIV>
<DIV> </DIV>
<DIV>Thanks,</DIV>
<DIV>Jin Yang</DIV>
<DIV> </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:pisa@cmp.felk.cvut.cz">Pavel
Pisa</A></DIV>
<DIV><B>Date:</B> 2014-05-15 21:53</DIV>
<DIV><B>To:</B> <A href="mailto:stefanha@gmail.com">Stefan Hajnoczi</A>; <A
href="mailto:afaerber@suse.de">AndreasFärber</A>; <A
href="mailto:peter.crosthwaite@xilinx.com">Peter Crosthwaite</A></DIV>
<DIV><B>CC:</B> <A
href="mailto:qemu-devel@nongnu.org">qemu-devel@nongnu.org</A>; <A
href="mailto:socketcan@hartkopp.net">Oliver Hartkopp A</A>; <A
href="mailto:jinyang.sia@gmail.com">jinyang.sia</A>; <A
href="mailto:sw@weilnetz.de">Stefan Weil</A>; <A
href="mailto:rtems-devel@rtems.org">rtems-devel</A>; <A
href="mailto:linux-can@vger.kernel.org">linux-can</A></DIV>
<DIV><B>Subject:</B> Re: [Qemu-devel] [PATCH 0/2] CAN SJA100 controller
emulation and SocketCAN based host CAN bus access</DIV></DIV></DIV>
<DIV>
<DIV>Hello all,</DIV>
<DIV> </DIV>
<DIV>the first much thanks to Stefan, Andreas and Peter</DIV>
<DIV>for reply.</DIV>
<DIV> </DIV>
<DIV>Next, should I keep linux-can in the talk</DIV>
<DIV>(it is against list cross-posting rule) or all</DIV>
<DIV>potentially interrested participants agree to stay/follow</DIV>
<DIV>this and future CAN+QEMU related topics on QEMU list?</DIV>
<DIV> </DIV>
<DIV>I would remove RTEMS in the next post. Even that</DIV>
<DIV>it is one of potential users, original "investor",</DIV>
<DIV>internals of the emulation are out of this project</DIV>
<DIV>scope.</DIV>
<DIV> </DIV>
<DIV>On Monday 12 of May 2014 11:18:09 Andreas Färber wrote:</DIV>
<DIV>> Am 12.05.2014 11:01, schrieb Peter Crosthwaite:</DIV>
<DIV>> > On Sat, May 10, 2014 at 4:14 AM, Pavel Pisa
<pisa@cmp.felk.cvut.cz> wrote:</DIV>
<DIV>> >> The work is based on Jin Yang GSoC 2013 work funded</DIV>
<DIV>> >> by Google and mentored in frame of RTEMS project GSoC</DIV>
<DIV>> >> slot donated to QEMU.</DIV>
<DIV>></DIV>
<DIV>> Should/can that be recorded in form of his Signed-off-by before
yours?</DIV>
<DIV> </DIV>
<DIV>I try to do something with that. I would preffer to add him</DIV>
<DIV>but I would like to have his confirmation beforehand.</DIV>
<DIV>The GSoC 2013 work is available in his GitHub repo including</DIV>
<DIV>negotiated final licence inclusion</DIV>
<DIV> </DIV>
<DIV>https://github.com/Jin-Yang/QEMU-1.4.2</DIV>
<DIV> </DIV>
<DIV>I was against to bothering you by patches for old QEMU</DIV>
<DIV>version so I have postponed communication till I have</DIV>
<DIV>time to bring it to the latest GIT. But there is significant</DIV>
<DIV>redesign which unties changes from hardcoded modifications</DIV>
<DIV>to QEMU character driver (original approach) and changes</DIV>
<DIV>whole patches architecture substantially including</DIV>
<DIV>omission of some functionality for beginning and probably</DIV>
<DIV>introduction of new errors. So I think that I am not</DIV>
<DIV>authorized to provide Signed-off-by Jin Yang on my own.</DIV>
<DIV>But original work status and license is declared by</DIV>
<DIV>Jin Yang and GSoC 2013.</DIV>
<DIV> </DIV>
<DIV>> > That's a big patch. And it seems to add a new API/framework, then
new</DIV>
<DIV>> > users of that API. Can you add your core as a single patch,
then</DIV>
<DIV>> > incrementally bring your devices stuff as subsequent patches? My
guess</DIV>
<DIV>> > is this should be about 3 patches - are there any circular
deps,</DIV>
<DIV>> > requiring you to bring your three c files all at once or is there
a</DIV>
<DIV>> > logical order you can add them for ease of review?</DIV>
<DIV>></DIV>
<DIV>> True. But before you resend, I'd like to hear Stefan H.'s view
of</DIV>
<DIV>> whether CAN should go into hw/net/ at all or into, e.g.,
hw/can/.</DIV>
<DIV> </DIV>
<DIV>That is significant question and my sending of the patch series is
mainly</DIV>
<DIV>base to start discussion about this and support architecture.</DIV>
<DIV>I need to learn mnore about QEMU internals and possible mechanisms</DIV>
<DIV>to use from QEMU experts as well.</DIV>
<DIV> </DIV>
<DIV>> Independently of the placement, it's always an interesting question
of</DIV>
<DIV>> who will maintain this new infrastructure - I don't see any new</DIV>
<DIV>> MAINTAINERS entries getting added in either patch (NB: a diffstat in
0/2</DIV>
<DIV>> would've been nice) for patch review.</DIV>
<DIV> </DIV>
<DIV>I have personal interrest in CAN and control systems etc. which</DIV>
<DIV>can be tracked more than 15 years back. But I have no funding</DIV>
<DIV>for this/QEMU work and some of my other projects available.</DIV>
<DIV>On the other hand, our group on Department of Control Enginnering</DIV>
<DIV>of Czech Technical University have participated in many serious</DIV>
<DIV>projects and we contribute to (ideally all open) CAN ecosystems.</DIV>
<DIV> </DIV>
<DIV>CAN at Czech Technical University</DIV>
<DIV> </DIV>
<DIV> https://rtime.felk.cvut.cz/can/</DIV>
<DIV> </DIV>
<DIV>links our group projects and some small part of our university</DIV>
<DIV>other departments CAN projects, which we have got some notice about.</DIV>
<DIV> </DIV>
<DIV>I cannot speak for our group head if he provide support/allows</DIV>
<DIV>to maintain QEMU CAN project by us. But I personally have</DIV>
<DIV>interrest for this and I would apply for maintainership.</DIV>
<DIV>But I/personally can provide only my spare time thought</DIV>
<DIV>I have a problems with fast responses and time in general.</DIV>
<DIV> </DIV>
<DIV>But I am keeping many open project alive or at least compilable</DIV>
<DIV>for 15 years and more already.</DIV>
<DIV> </DIV>
<DIV>https://www.ohloh.net/accounts/ppisa/positions</DIV>
<DIV> </DIV>
<DIV>On Tuesday 13 of May 2014 14:29:08 Stefan Hajnoczi wrote:</DIV>
<DIV>> On Fri, May 9, 2014 at 8:10 PM, Pavel Pisa
<pisa@cmp.felk.cvut.cz> wrote:</DIV>
<DIV>></DIV>
<DIV>> Please run the patches through scripts/checkpatch.pl and address
the</DIV>
<DIV>> warnings.</DIV>
<DIV>></DIV>
<DIV>> This patch doesn't use QEMU's network layer. Perhaps it should
but</DIV>
<DIV>> I'm not familiar with CAN. The QEMU network layer implements
a</DIV>
<DIV>> point-to-point model where NetClientState instances can
send/receive</DIV>
<DIV>> packets. It seems a subset of this was reimplemented for CAN but
I</DIV>
<DIV>> don't see much unique behavior in the core CAN code. Why didn't
you</DIV>
<DIV>> use the QEMU network layer?</DIV>
<DIV> </DIV>
<DIV>Yes, that is main question. It would be great to use QEMU
infrastructure</DIV>
<DIV>for broadcasting messages/frames. I am not enough familiar with it</DIV>
<DIV>and I would need some help to find how it could be used for CAN.</DIV>
<DIV> </DIV>
<DIV>But on the other hand, there is question, if real behavior</DIV>
<DIV>and messages ordering should be modelled for CAN or if</DIV>
<DIV>we consider only some +/- working solution. If the behave</DIV>
<DIV>of real CAN network is required later, it can be very hard</DIV>
<DIV>to model it by infrastructure designed for other data flow.</DIV>
<DIV> </DIV>
<DIV>In the full model case, each CanBusClient should publish</DIV>
<DIV>its list of CAN communication objects ready for Tx and Rx.</DIV>
<DIV>For Tx usually ordered by message IDs (representing priority</DIV>
<DIV>in arbitration process). Global clients order for given bus</DIV>
<DIV>should be recomputed for each change on clients list by</DIV>
<DIV>client's change activated bus arbitration process.</DIV>
<DIV>That process should then select next message for transmition.</DIV>
<DIV>Then it should be delivered to all CanBusClien's Rx communication</DIV>
<DIV>objects which filters match CAN message ID.</DIV>
<DIV> </DIV>
<DIV>The main problem (when compared to the real bus) is, that real</DIV>
<DIV>bus does transfer rate limiting (max 1M bit/s - stuffing etc.).</DIV>
<DIV>But in QEMU faster messages flow can overflow Rx buffers</DIV>
<DIV>in situations which cannot lead to the overflow in real situation.</DIV>
<DIV>So there should be some mechanism to check Rx object availability</DIV>
<DIV>in clients. Than there should be mechanism to postpone data exchange</DIV>
<DIV>in such case for at least time equivalent to real message presence</DIV>
<DIV>on a wire (we have implemented computation for exact time required</DIV>
<DIV>for message from its actual data including stuffing and CRC done</DIV>
<DIV>for our industrial partner in other project).</DIV>
<DIV> </DIV>
<DIV>The message Tx attempt expiration should be postponed for</DIV>
<DIV>even longer when it is not accepted/confirmed by any</DIV>
<DIV>target and error should be reported back to corresponding</DIV>
<DIV>Tx object.</DIV>
<DIV> </DIV>
<DIV>Some controllers provide "overload frame" response which</DIV>
<DIV>should/could be included/emulated as well.</DIV>
<DIV> </DIV>
<DIV>Controllers should evaluate and count Tx and Rx errors counts</DIV>
<DIV>and change state appropriately.</DIV>
<DIV> </DIV>
<DIV>I am not sure if all that can be emulated by network QEMU</DIV>
<DIV>subsystem or if required changes are acceptable.</DIV>
<DIV> </DIV>
<DIV>I do not know if it worth to consider all this at all.</DIV>
<DIV> </DIV>
<DIV>My actual goal was to have something simple which works</DIV>
<DIV>and can be used for drivers implementors (i.e. RTEMS)</DIV>
<DIV>to get into state when first message is sent and received</DIV>
<DIV>and then switch to real HW.</DIV>
<DIV> </DIV>
<DIV>And yes, it would be great to have all this implemented</DIV>
<DIV>to can do drivers testing and correctness assessment in QEMU.</DIV>
<DIV> </DIV>
<DIV>I am able to think about infrastructure which allows such</DIV>
<DIV>extensions in future. But real implementation is muti-man-year</DIV>
<DIV>project which needs contribution from more people.</DIV>
<DIV> </DIV>
<DIV>So at the end, I am not sure if net or not-net. I expected</DIV>
<DIV>some objections to addition of subsystem. If you agree</DIV>
<DIV>with hw/can than I would incline to separation of code which</DIV>
<DIV>needs to follow CAN infrastructure development caused</DIV>
<DIV>changes together.</DIV>
<DIV> </DIV>
<DIV>> > - CAN bus simple SJA1000 PCI card emulation for
QEMU</DIV>
<DIV>> ></DIV>
<DIV>> > Files:</DIV>
<DIV>> ></DIV>
<DIV>> > - include/net/can_emu.h</DIV>
<DIV>> > -
basic CAN bus related types. Those which could possibly clash</DIV>
<DIV>>
>
with Linux kernel prepended by "qemu_".</DIV>
<DIV>> > -
prototypes for CAN buses naming and clients registration</DIV>
<DIV>> > -
original Jin Yang approach uses chardev, but that does not</DIV>
<DIV>>
> map
well to little different semantics of CAN messages</DIV>
<DIV>>
>
distribution. I have considered common vlan code but</DIV>
<DIV>>
> I
have not found how to use it with CAN well too.</DIV>
<DIV>> ></DIV>
<DIV>> > - hw/net/can_core.c</DIV>
<DIV>> > -
implementation of CAN messages delivery</DIV>
<DIV>> > -
support to connect into real host CAN bus network for case</DIV>
<DIV>>
> of
Linux SocketCAN</DIV>
<DIV>></DIV>
<DIV>> The network layer implements (poorly) a flow control mechanism so
that</DIV>
<DIV>> devices with limited buffers, like a USB network card, can pause</DIV>
<DIV>> receive until the guest has drained the receive buffer. I don't
see</DIV>
<DIV>> that in the CAN code, so is it okay to drop frames?</DIV>
<DIV> </DIV>
<DIV>There is no such mechanism in our implementation now.</DIV>
<DIV>But it is desirable in longer run an there was some minimal</DIV>
<DIV>solution in original Jin Yang's char device code.</DIV>
<DIV> </DIV>
<DIV>> About the Linux socket file descriptor:</DIV>
<DIV>> 1. It should be non-blocking because QEMU is an event-driven
program.</DIV>
<DIV>> We must never block waiting to read/write data from/to a socket.</DIV>
<DIV>> 2. Missing EINTR error handling in case a signal interrupted a</DIV>
<DIV>> read(2)/write(2) system call.</DIV>
<DIV> </DIV>
<DIV>Yes, that are next steps or other option is to start</DIV>
<DIV>delivery thread for each CAN bus. Which could be natural</DIV>
<DIV>solution for real bus behavior simulation.</DIV>
<DIV>Are there some reasons against use of separate thread</DIV>
<DIV>for this purpose?</DIV>
<DIV> </DIV>
<DIV>Even such thread could call actual syscall nonblockin</DIV>
<DIV>to can timeout and report errors. But it could be simpler</DIV>
<DIV>to program and parallelize mesages delivery with emulated CPU run.</DIV>
<DIV> </DIV>
<DIV>> In the QEMU network layer the can_core.c behavior would be
produced</DIV>
<DIV>> using a hub with a tap or socket netdev. The broadcast code in
the</DIV>
<DIV>> hub netdev is separate from the Linux-specific tap code. I think
you</DIV>
<DIV>> can implement a CAN socket netdev and use the hub to broadcast.</DIV>
<DIV> </DIV>
<DIV>I need to learn more about QEMU internals and reusable features.</DIV>
<DIV>Thank for suggestions.</DIV>
<DIV> </DIV>
<DIV>> > - hw/net/can_sja1000.h</DIV>
<DIV>> > -
declarations of SJA1000 CAN controller registers</DIV>
<DIV>>
> and
connection type independent part of API</DIV>
<DIV>> ></DIV>
<DIV>> > - hw/net/can_sja1000.c</DIV>
<DIV>> > -
SJA1000 CAN controller registers and registers model</DIV>
<DIV>>
>
implementation - hard part implemented by Jin Yang</DIV>
<DIV>> ></DIV>
<DIV>> > - hw/net/can_pci.c</DIV>
<DIV>> > -
connection of above infrastructure to the minimal PCI</DIV>
<DIV>>
>
card with only one mmio BAR and no bridge interrupts setup</DIV>
<DIV>>
> and
control. Unfortuantelly, I am not aware of any such</DIV>
<DIV>>
>
straightforward card but it is great for testing and</DIV>
<DIV>>
>
drivers porting. Used vendor and product ID are random ones</DIV>
<DIV>>
>
chosen by Jin Yang, if there is some consensus that work</DIV>
<DIV>> > worth for integration then I suggest to ask RedHat for unique PCI
ID</DIV>
<DIV>> > donation</DIV>
<DIV>></DIV>
<DIV>> What is the relationship between can_pci.c and the emulated Kvaser
device?</DIV>
<DIV>></DIV>
<DIV>> Implementing one real device would be very important to establish
that</DIV>
<DIV>> this CAN implementation can model real devices.</DIV>
<DIV> </DIV>
<DIV>There is broad range of CAN controllers, we have selected one famous
CAN</DIV>
<DIV>discrete controller chip SJA1000. Problem is, that it predates PCI</DIV>
<DIV>and is intended to be used with 8051 like multiplexed bus.</DIV>
<DIV>It is still one of the most used chips on addons cards. CAN is common</DIV>
<DIV>on SoC and MCUs and they use many different derivations or completely</DIV>
<DIV>different registers models. But there is really very little other</DIV>
<DIV>CAN controller chips available for addon cards (OKI, discontinued Intel,
...).</DIV>
<DIV>So SJA1000 is reasonable choice for our QEMU effort. But it has to be
used</DIV>
<DIV>in combination with some PCI-local bus bridge. But these bridges</DIV>
<DIV>are quite strange, sometimes reused chip for old ISDN solutions etc.</DIV>
<DIV>So they need special configuration to access local bus connected CAN</DIV>
<DIV>controller and mainly to setup routing of interrupts.</DIV>
<DIV> </DIV>
<DIV>Emulation of PCI-local bus bridge complicates both sides in action -</DIV>
<DIV>QEMU emulation side and developed CAN drivers side. That is why</DIV>
<DIV>we have "designed" basic card with clean implementation directly</DIV>
<DIV>mapping SJA1000 chip into PCI memory BAR with direct, level triggered</DIV>
<DIV>routing of interrupt to corresponding "PCI board" A pin.</DIV>
<DIV> </DIV>
<DIV>When we have confirmed that this works together with modified</DIV>
<DIV>LinCAN driver I have started to implement model corresponding</DIV>
<DIV>to real PCI CAN card. I have selected Kvaser card because</DIV>
<DIV>we pose more of these at university/so I can check real contents</DIV>
<DIV>of other configuration/support spaces/BARs on real device.</DIV>
<DIV>The advantage of that selection is that driver for this card</DIV>
<DIV>is included in mainline Linux in CAN/SocketCAN subsystem.</DIV>
<DIV>This board can have up to four SJA1000 chips in one of its BARs,</DIV>
<DIV>The board routes interrupts through bride interrupt control/masking</DIV>
<DIV>and configuration, which has to be emulated as well.</DIV>
<DIV>It even maps chips into I/O space instead of MMIO.</DIV>
<DIV> </DIV>
<DIV>I think that for drivers writers or even can infrastructure</DIV>
<DIV>developers (userspace and higher level tools) it is advantage to have</DIV>
<DIV>simple solution with corresponding driver in a guest kernel
(something</DIV>
<DIV>like virtio). On the other hand, concrete real hardware driver</DIV>
<DIV>testing requires exact hardware complexity emulation and allows</DIV>
<DIV>to use unmodified OS and available drivers.</DIV>
<DIV> </DIV>
<DIV>But if you think, that this artificial simple card design is not</DIV>
<DIV>good idea for QEMU, then it can be discarded and only Kvaser</DIV>
<DIV>(when it works now) included.</DIV>
<DIV> </DIV>
<DIV>The decisions for further development</DIV>
<DIV> </DIV>
<DIV>Should be minimal working solution included in the QEMU</DIV>
<DIV>mainline in short term?</DIV>
<DIV>(months .. or rather wait for agreement on final</DIV>
<DIV>infrastructure, may be years because of our other load</DIV>
<DIV>and complexity of full model task)</DIV>
<DIV> </DIV>
<DIV>Is preferred approach to open CAN QEMU fork on GitHub?</DIV>
<DIV>Etc...</DIV>
<DIV> </DIV>
<DIV>I consider as a good result, that my actual attempt and QEMU offered</DIV>
<DIV>infrastructure allows to to provide minimal testable solution with</DIV>
<DIV>no QEMU modifications (except Makefiles). So I hope that is is</DIV>
<DIV>reasonable start and our effort would be of some use for others.</DIV>
<DIV> </DIV>
<DIV>Best wishes,</DIV>
<DIV> </DIV>
<DIV>
Pavel</DIV>
<DIV> </DIV>
<DIV>PS: I am not sure if I will be online till Monday</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV></DIV></BODY></HTML>