Re: [GSoC] CAN SJA1000
Hi, all
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.
Thanks,
Jin Yang
jinyang@gmail.com
From: Gedare Bloom
Date: 2013-09-16 20:57
To: jinyang@gmail.com
CC: Pavel Pisa; Rempel, Cynthia; Chris Johns; RTEMS Devel
Subject: Re: [GSoC] CAN SJA1000
Jin Yang, you should incorporate these notes and suggestions to your
project's wrap-up / summary descriptions. If you are interested in
continuing after GSoC with this project I think this will be a good
direction to head.
-Gedare
On Sun, Sep 15, 2013 at 3:56 PM, Pavel Pisa wrote:
> Hello Jin Yang and all others,
>
> congratulation to achieving the main goal.
>
> I have read your instructions and build sucesfull
> the QEMU on AMD64 Debian Wheezy.
> I have run the compiled QEMU with 64-bit 3.2.x kernel
> used 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 side
> against your SJA1000 HW emulation. I have connected host
> side to the virtual SocketCAN bus and used OrtCAN qCANalyzer
> on 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 to
> try some more demanding testing. But as you know
> we are not fast (unfortuantelly) in many cases so
> it would take some time. Anyway it worth to run
> our CAN Benchmarks to torture code and clean possible
> bugs
>
> http://rtime.felk.cvut.cz/can/
>
> By the way, we have included actual MPC5200 RTEMS CAN
> driver into our benchmarks this summer and results are
> quite in favor for RTEMS but that is partially caused
> by dummy implementation of CAN gateway user on RTEMS
> for testing. But that worths separate e-mail as we
> finish the work.
>
> As for actual Jin Yang's QEMU CAN code, I think that
> it is valuable achievement for GSoC project and if
> stability is confirmed by testing, it is good base
> for RTEMS CAN infrastructure development.
>
> On the other hand, for long term sustainability
> it is required to invest into inclusion of code
> to the QEMU mainline. This requires to port code
> to the actual QEMU git version. I do not know
> how big amount it means because QEMU is fast
> mowing target. It may be above GSoC project contract
> size. But it really worth to be done.
>
> As for the code review, I think that there is too
> much CAN specific code push into generic qemu-char.c
> file
>
> qemu-jin-yang/qemu-char.c
>
> The registration in actual QEMU git version seems to be more
> modular
>
> register_char_driver_qapi("parallel", CHARDEV_BACKEND_KIND_PARALLEL,
> qemu_chr_parse_parallel);
>
> The all SocketCAN specific code has to be moved to other
> file and there must be mechanism to disable build of that
> code
>
> qemu-jin-yang/qemu-char.c
> +#include
> +#include
>
> The reason is that SocketCAN is Linux specific and that part
> of the code included in the common QEMU infrastructure
> would made it non-portable.
>
> As for the actual can controller emulation, it is/or can be
> made fully portable to all host systems and for all target
> configurations which support PCI
>
> qemu-jin-yang/hw/can-pci.c
>
> It would worth to separate SJA1000 part of the code from
> PCI mapping to allows use SJA1000 emulator even on non-PCI
> platforms. It would worth even to allows to use SJA1000
> emulator with different PCI cards mapping. The most of real
> CAN interface cards have more PCI regions/BARs and actual CAN
> chips are mapped to region 1 or 2. Region 0 is usually used
> to control PCI bridge part of the card. Use of generic PCI
> bridge chips usually means that some interrupt configuration
> is required in this bridge control area.
> But these two are not high priority for now.
>
> As for actual SJA1000 chip emulation, I would prefer personally
> if the register bit masks are not hardcoded by numbers but
> if 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
>
>
> On Sunday 15 of September 2013 10:16:39 jinyang@gmail.com wrote:
>> Hi,
>>
>> I just update the http://wiki.rtems.org/wiki/index.php/Qemu_simulations
>> remove some unecessary data and add some new information. Some of them is
>> not complete. However I don't know how to upload pictures to the site?
>>
>> Thanks,
>> Jin Yang
>>
>>
>>
>>
>> jinyang@gmail.com___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
Building RTEMS i386 simulation environment based on Grub2 and QEMU
Hi, all I just build a i386 simulation environment based on Grub2 and QEMU, maybe you can try this if like. http://www.rtems.org/wiki/index.php/Building_Grub The new one is on section 'Grub2', the previous one alse reserved. The original one is based on Grub legacy. However most Linux distributions have updated to Grub2. We should compile the grub legacy and also get some bugs if we use the previous method. I have test it on Ubuntu-13.04 platform without 'kpartk' software. I hope it works on other platforms. If any bugs occur when you try this on your platform, please feel free to let me know. I will try to figure it out. Thanks, Jin Yang jinyang@gmail.com___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
GSoC2014 - Port LinCAN to RTEMS
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
CAN-PCI device, some problems fixed
Hi, Pavel and all Some of the probems have fixed, and there are still some may take little more time. Details in https://github.com/Jin-Yang/QEMU-1.4.2 . the license problem: done. Recently, I have tried to find out how to just compile part of QEMU, then we can choose if the CAN-PCI module should be compiled. However, I didn't find out how to do that. Then I think ONLY on linux platform the CAN-PCI device can be supported then "#ifdef __linux__" added. I think this maybe work which also means CAN-PCI can only be used on Linux. I don't have a Windows environment(tried many times, but failed), so I don't know if this can work, just hope so. I have downloaded the recent Git version 2.0.0-rc0, just as you say register_char_driver_qapi() was used. I will try to figure out how this works. Then change CAN-PCI to this form too. Maybe this will take som time. When you said "It would worth to separate SJA1000 part of the code from PCI mapping to allows use SJA1000 emulator even on non-PCI platforms. It would worth even to allows to use SJA1000 emulator with different PCI cards mapping", does this mean that see SJA1000 as a common device just like the UART device? Is this really necessary? Since the CAN device is not a common device for the computers. I think maybe PCI is a better choice. About the readable constants, most of the numbers has been replaced some of them such as addr16-28 may be different when reading or writing. So, I think check the DataSheet maybe a good choice, maybe this can be changed when debug the LinCAN this summer later. jinyang@gmail.com___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
CAN SJA100 controller emulation and SocketCAN based host CAN bus access
Hi, all 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. Thanks, Jin Yang jinyang@gmail.com From: Pavel Pisa Date: 2014-05-15 21:53 To: Stefan Hajnoczi; AndreasFärber; Peter Crosthwaite CC: qemu-de...@nongnu.org; Oliver Hartkopp A; jinyang.sia; Stefan Weil; rtems-devel; linux-can Subject: Re: [Qemu-devel] [PATCH 0/2] CAN SJA100 controller emulation and SocketCAN based host CAN bus access Hello all, the first much thanks to Stefan, Andreas and Peter for reply. Next, should I keep linux-can in the talk (it is against list cross-posting rule) or all potentially interrested participants agree to stay/follow this and future CAN+QEMU related topics on QEMU list? I would remove RTEMS in the next post. Even that it is one of potential users, original "investor", internals of the emulation are out of this project scope. On Monday 12 of May 2014 11:18:09 Andreas Färber wrote: > Am 12.05.2014 11:01, schrieb Peter Crosthwaite: > > On Sat, May 10, 2014 at 4:14 AM, Pavel Pisa wrote: > >> The work is based on Jin Yang GSoC 2013 work funded > >> by Google and mentored in frame of RTEMS project GSoC > >> slot donated to QEMU. > > Should/can that be recorded in form of his Signed-off-by before yours? I try to do something with that. I would preffer to add him but I would like to have his confirmation beforehand. The GSoC 2013 work is available in his GitHub repo including negotiated final licence inclusion https://github.com/Jin-Yang/QEMU-1.4.2 I was against to bothering you by patches for old QEMU version so I have postponed communication till I have time to bring it to the latest GIT. But there is significant redesign which unties changes from hardcoded modifications to QEMU character driver (original approach) and changes whole patches architecture substantially including omission of some functionality for beginning and probably introduction of new errors. So I think that I am not authorized to provide Signed-off-by Jin Yang on my own. But original work status and license is declared by Jin Yang and GSoC 2013. > > That's a big patch. And it seems to add a new API/framework, then new > > users of that API. Can you add your core as a single patch, then > > incrementally bring your devices stuff as subsequent patches? My guess > > is this should be about 3 patches - are there any circular deps, > > requiring you to bring your three c files all at once or is there a > > logical order you can add them for ease of review? > > True. But before you resend, I'd like to hear Stefan H.'s view of > whether CAN should go into hw/net/ at all or into, e.g., hw/can/. That is significant question and my sending of the patch series is mainly base to start discussion about this and support architecture. I need to learn mnore about QEMU internals and possible mechanisms to use from QEMU experts as well. > Independently of the placement, it's always an interesting question of > who will maintain this new infrastructure - I don't see any new > MAINTAINERS entries getting added in either patch (NB: a diffstat in 0/2 > would've been nice) for patch review. I have personal interrest in CAN and control systems etc. which can be tracked more than 15 years back. But I have no funding for this/QEMU work and some of my other projects available. On the other hand, our group on Department of Control Enginnering of Czech Technical University have participated in many serious projects and we contribute to (ideally all open) CAN ecosystems. CAN at Czech Technical University https://rtime.felk.cvut.cz/can/ links our group projects and some small part of our university other departments CAN projects, which we have got some notice about. I cannot speak for our group head if he provide support/allows to maintain QEMU CAN project by us. But I personally have interrest for this and I would apply for maintainership. But I/personally can provide only my spare time thought I have a problems with fast responses and time in general. But I am keeping many open project alive or at least compilable for 15 years and more already. https://www.ohloh.net/accounts/ppisa/positions On Tuesday 13 of May 2014 14:29:08 Stefan Hajnoczi wrote: > On Fri, May 9, 2014 at 8:10 PM, Pavel Pisa wrote: > > Please run the patches through scripts/checkpatch.pl and address the > warnings. > > This patch doesn't use QEMU's network layer. Perhaps it should but > I'm not familiar with CAN. The QEMU network layer implements a > point-to-point model where NetClientState instances can send/receive > packets. It seems a subset of this was reimplemented for CAN but I > don't see much unique behavi
