AW: [Socket-can] Re: Which CAN driver to port to for PPC

AW: [Socket-can] Re: Which CAN driver to port to for PPC

[Hartkopp, Oliver (K-GEFE/E)]

Hi all,

> Robert Schwebel wrote:
> > ...
> > In december, we have made a synchronisation meeting with the VW people
> > who made the initial port for 2.4; they are more focussed on having
> > higher level transport protocols ontop of the "raw" socket interface we
> > currently use. During that process we have reviewed the user interface
> > with regard to their use cases, so it will have to be changed a little
> > bit before we have something which is in a state to be posted on lkml.
> > 

To be more correctly: Our focus is more on content-filtering of cyclic
sent and received CAN-messages as well as on CAN-transport-protocols
like ISO-TP (where two CAN-IDs are used to implement a point-to-point
connection via the CAN-Bus by segmenting long (means >8 Byte) PDUs).

The transport protocols and the so called "Broadcast-Manager" (for
content-filtering, cyclic sending, RTR-Handling, Timeout-Handling) are
not ontop the RAW-socket but arranged /next/ to the CAN_RAW-protocol in
the protocol-family PF_CAN. You may find a picture of this 'arrangement'
in the first hit of 'PF_CAN' in google (sorry it's german - figure page 5):

http://www.network-on-wheels.de/downloads/VDE2004_Luebke_Paper.pdf

As we had some problems to publish our software, we shared our ideas with
Robert, Jan and Benedikt who have been working on the same problems in 2004.

We are now bringing our implementations and APIs together, to publish a
real Kernel-proof implementation for PF_CAN. Fortunately our implementations
do not differ in core-things so it's just a bit cosmetic on both sides.
Btw. VW has a Kernel 2.4 implementation and Robert and Benedikt have a
Kernel 2.6 port - so it becomes a win-win-situation for both sides ... :-)

> Jan Kiszka wrote:
>
> Beyond the outstanding comparably minor API adjustments, we furthermore
> discussed first ideas how to define the lowest interface, i.e. the CAN
> network device layer. That should be done in a way which makes porting
> CAN low-level drivers between the standard kernel and a real-time Linux
> CAN stack trivial. That's a unique chance (compared to the situation of
> RTnet e.g.), so we should take it.
> 
> (..) This means we could end up with portable CAN
> applications and drivers, RT and non-RT!
> 

As the RTDM and a 'standard'-netdevice are quite similar (in opposite to
the former used char-devices for CAN-drivers) it should be quite easy to
create some kind of CAN-HW-abstraction layer to fit the bare controller
access into a netdevice and respectively a RTDM-device. As both sides
currently support various CAN-controllers this is a really good chance
to bring not only the socket-API (for the user software) but the low
level can driver API (for the driver developer) together.

> As Robert said, it "just" requires some resources for implementing
> this... ;)

I'm looking forward to create this CAN-HW-abstraction layer with Jan and
Robert, as i assume the required ressources to be melting down after a
initial work that is done together in the approved way. After this is
defined, it shall be very easy for driver developers to make their CAN-HW
work as netdevice / RTDM-device. So every work is just done once.

Finally i wish you a happy new year in advance! May 2006 be the year of
excellent
(and settled) CAN-concepts inside the Linux kernel for all of us ;-)

Best regards,

Oliver

Re: [Socket-can] Re: Which CAN driver to port to for PPC

[Robert Schwebel]

Hi Oliver, 

On Fri, Dec 30, 2005 at 07:00:54PM +0100, Hartkopp, Oliver (K-GEFE/E)
wrote:
> > As Robert said, it "just" requires some resources for implementing
> > this... ;)
> 
> I'm looking forward to create this CAN-HW-abstraction layer with Jan
> and Robert, as i assume the required ressources to be melting down
> after a initial work that is done together in the approved way. After
> this is defined, it shall be very easy for driver developers to make
> their CAN-HW work as netdevice / RTDM-device. So every work is just
> done once.

Writing device drivers will be easy - Sascha has done drivers for
SJA1000 based boards in less than a day and for completely new and
braindamaged chips in less than a week.  

The _real_ work will be on the infrastructure side; to be useful for a
wider audience the existing code has to be forward ported to the latest
2.6 trees and it has to be ported to use modern kernel techniques; even
our 2.6 code suffers a bit from it's history and doesn't use all the
mechanisms the kernel offers today.

We surely could do this, especially Marc and Sascha have quite some
experience with CAN and the network stack, but as always the rule is
that paying customers come first. So as long as there is nobody
sponsoring this project we will work on it only in our sparetime. 

> Finally i wish you a happy new year in advance! May 2006 be the year
> of excellent (and settled) CAN-concepts inside the Linux kernel for
> all of us ;-)

Let's hope this! :-)

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

Which CAN driver to port to for PPC

[David Jander]

Hi,

We have developed CAN hardware based on the Philips SJA1000 controller hooked 
to a MPC8xx based processor board. Now we want to write driver support for 
it. My first try was lincan-0.3.1, which seemed quite well written at first 
glance. Porting was easy too, and the driver works fine on our board with the 
latest kernel (2.6.14).
But.... this driver lacks a proper way of checking the status of the CAN 
controller from userspace :-( Not that nice after all!

Then I see on the DENX website, mention of Rubini's OCAN (mostly useless to 
us), and Peak's PCAN drivers (there is a port for MPC5200 on DENX's site). No 
word about lincan, though.

The reason I suppose is, someone already figured out that lincan is not a good 
choice for whatever reason (status reportability ??), right?

Before beginning to re-invent wheels and re-discover known problems in certain 
CAN driver architectures, could someone please point me to the right place to 
start looking for answers (if that place exists) or just give the answer, 
opinion or experience with one of PeakCAN, lincan, can4linux, etc...?

I am again puzzeled about which way to go.

Thanks for any advice,

-- 
David Jander
Protonic Holland.

Re: Which CAN driver to port to for PPC

[Alessandro Rubini]

Hello.

> [...]
> Then I see on the DENX website, mention of Rubini's OCAN (mostly
> useless to us),

I need to port ocan to support SJA1000 on an ARM device, as a client
asked for it.  Also, another client asked for a 2.6 port, so all of
this will happen pretty soon (2-3 weeks). I don't know if that makes
any difference.

/alessandro

Re: Which CAN driver to port to for PPC

[David Jander]

Hi all,

On Tuesday 27 December 2005 22:49, Alessandro Rubini wrote:
> I need to port ocan to support SJA1000 on an ARM device, as a client
> asked for it.  Also, another client asked for a 2.6 port, so all of
> this will happen pretty soon (2-3 weeks). I don't know if that makes
> any difference.

That could of course make a difference.... eventually.
The problem I see with Ocan is that it has a very different API than all the 
others. I know of at least two others, which try to be compatible (or at 
least easily portable between) with each other: lincan and can4linux. I am 
not sure but I think they started from the same base, and somehow agreed to 
stay API-compatible.
Ocan's API on the other hand, seems to be tailored around the intel 
controller, and doing little more than offering a user-space interface to the 
chip, much in the same way as one is used to programming small 
microcontrollers with integrated CAN periferals. I wonder how the port to 
SJA1000 will turn out, since I believe it would have to emulate some 
82527-specific stuff, in order to offer a compatible API.
The advantage OCan might have, is probably better control of timing, since 
AFAIK, one can avoid using queues, which give additional delays if the queue 
is not empty; somehting often not wanted in real-time applications.

Also one difficulty in designing a good CAN driver model, is the fact that CAN 
offers up to the link-layer in hardware, and the rest is application 
specific, so it is hard to do much in the driver without hampering some 
possible application. I am convinced though, that there should be a 
chip/card-independent API to the application-programmer, and that effort 
should be done to converge into the same direction. Programmers now really 
have a tough time choosing, and that is as bad as having no choice at all 
IMHO.

So, wouldn't it be better to try to unite forces and at least offer similar 
API's, or even better, develop a standard linux CAN framework? I guess there 
is little chance something like this will ever become part of the kernel, but 
right now the situation is really awful. CAN is quite popular for embedded 
systems, but even embedded systems developers like to write portable code.

Regards,

P.S.: Alessandro: I have copy of "LDD1" on my desk, and I like it a lot. 
Thanks!

-- 
David Jander
Protonic Holland.

Re: Which CAN driver to port to for PPC

[Andrey Volkov]

David Jander wrote:
> Hi all,
> 
> On Tuesday 27 December 2005 22:49, Alessandro Rubini wrote:
> 
>>I need to port ocan to support SJA1000 on an ARM device, as a client
>>asked for it.  Also, another client asked for a 2.6 port, so all of
>>this will happen pretty soon (2-3 weeks). I don't know if that makes
>>any difference.
> 
> 
> That could of course make a difference.... eventually.
> The problem I see with Ocan is that it has a very different API than all the 
> others. I know of at least two others, which try to be compatible (or at 
> least easily portable between) with each other: lincan and can4linux. I am 
> not sure but I think they started from the same base, and somehow agreed to 
> stay API-compatible.

Robert Schwebel et al have worked socket based CAN (i.e. implement CAN
as _net_ dev, not as char), as consequence you will not have problem
with major/minor numbers, duplicated code in drivers for different
chips, could share CAN dev between diff processes _without_ misc. third
party shared libraies, stacked CAN protocols (CANopen/NMEA2000 could be
abstract kernel module)... But currently it is not open for everyone
(due to beta status, AFAIK)

Alessandro, please check Pengutronix work first, may be it will be
helpfull to you to,
Also I permit oneself to quotate _you_ ;) from LDDv3 pp6-7:

"The three classes are:

Character devices

A character (char) device is one that can be accessed as a stream of
bytes (like a file); a char driver is in charge of implementing this
behavior. Such a driver usually implements at least the open, close,
read, and write system calls. The text console (/dev/console) and the
serial ports (/dev/ttyS0 and friends) are examples of char devices, as
they are well represented by the stream abstraction. Char devices are
accessed by means of filesystem nodes, such as /dev/tty1 and /dev/lp0.
The only relevant difference between a char device and a regular file is
that you can always move back and forth in the regular file, whereas
most char devices are just data channels, which you can only access
sequentially. There exist, nonetheless, char devices that look like data
areas, and you can move back and forth in them; for instance, this
usually applies to frame grabbers, where the applications can access the
whole acquired image using mmap or lseek.

Block devices

Like char devices, block devices are accessed by filesystem nodes in the
/dev directory. A block device is a device (e.g., a disk) that can host
a filesystem. In most Unix systems, a block device can only handle I/O
operations that transfer one or more whole blocks, which are usually 512
bytes (or a larger power of two) bytes in length. Linux, instead, allows
the application to read and write a block device like a char device—it
permits the transfer of any number of bytes at a time. As a result,
block and char devices differ only in the way data is managed internally
by the kernel, and thus in the kernel/driver software interface. Like a
char device, each block device is accessed through a filesystem node,
and the difference between them is transparent to the user. Block
drivers have a completely different interface to the kernel than char
drivers.

Network interfaces

Any network transaction is made through an interface, that is, a device
that is able to exchange data with other hosts. Usually, an interface is
a hardware device, but it might also be a pure software device, like the
loopback interface. A network interface is in charge of sending and
receiving data packets, driven by the network subsystem of the kernel,
without knowing how individual transactions map to the actual packets
being transmitted. Many network connections (especially those using TCP)
are stream-oriented, but network devices are, usually, designed around
the transmission and receipt of packets. A network driver knows nothing
about individual connections; it only handles packets."

so CAN _is_ Network interface, but not char device
(how it often implemented).

P.S. Robert, when I check last time, it was mature enogh, so may be time
to open mail-list and svn?

--
Regards
Andrey Volkov

Re: Which CAN driver to port to for PPC

[Robert Schwebel]

Hi, 

On Wed, Dec 28, 2005 at 06:02:26PM +0300, Andrey Volkov wrote:
> Robert Schwebel et al have worked socket based CAN (i.e. implement CAN
> as _net_ dev, not as char), as consequence you will not have problem
> with major/minor numbers, duplicated code in drivers for different
> chips, could share CAN dev between diff processes _without_ misc.
> third party shared libraies, stacked CAN protocols (CANopen/NMEA2000
> could be abstract kernel module)... But currently it is not open for
> everyone (due to beta status, AFAIK)
> 
> Alessandro, please check Pengutronix work first, may be it will be
> helpfull to you to
>
> [...]
>
> P.S. Robert, when I check last time, it was mature enogh, so may be time
> to open mail-list and svn?

The socket-can stuff is mature enouth to have been used in some projects
at Pengutronix.

In december, we have made a synchronisation meeting with the VW people
who made the initial port for 2.4; they are more focussed on having
higher level transport protocols ontop of the "raw" socket interface we
currently use. During that process we have reviewed the user interface
with regard to their use cases, so it will have to be changed a little
bit before we have something which is in a state to be posted on lkml.

Unfortunately we have no commercial project behind the infrastructure
work, so it's priority is lower than it should be to really drive things
forward (paying customers have a higher priority than community work). 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

Re: [Socket-can] Re: Which CAN driver to port to for PPC

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]

Robert Schwebel wrote:
> ...
> In december, we have made a synchronisation meeting with the VW people
> who made the initial port for 2.4; they are more focussed on having
> higher level transport protocols ontop of the "raw" socket interface we
> currently use. During that process we have reviewed the user interface
> with regard to their use cases, so it will have to be changed a little
> bit before we have something which is in a state to be posted on lkml.
> 

Beyond the outstanding comparably minor API adjustments, we furthermore
discussed first ideas how to define the lowest interface, i.e. the CAN
network device layer. That should be done in a way which makes porting
CAN low-level drivers between the standard kernel and a real-time Linux
CAN stack trivial. That's a unique chance (compared to the situation of
RTnet e.g.), so we should take it.

This real-time stack is to be derived from the RT-SJA1000 driver
Wolfgang pointed at. It is already based on an abstraction layer (RTDM)
that makes it portable across many of the various RT-Linux variant. So
far this includes support for Xenomai and RTAI, RTLinux/GPL is planning
to adopt RTDM as well. This means we could end up with portable CAN
applications and drivers, RT and non-RT!

As Robert said, it "just" requires some resources for implementing
this... ;)

Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]