using j1939

using j1939

[wutz]

Hi Kurt,

I am sorry it is me again. I cloned the three repositories, can-j1939-modules, can-j1939, iproute2-1939 as you told me. Now I want to create new packages out of this repositories (I hope this is the right way). 
But now I am facing the next problem, what type of packages do I have to create for each particular repository?


Sorry for your trouble,

Wolfgang
-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone

Re: using j1939

[Kurt Van Dijck]

> I cloned the three repositories, can-j1939-modules, can-j1939, iproute2-1939 as you told me.
I suppose you meant 'can-j1939-modules', 'can-j1939-utils' and 'iproute2-j1939' ...

> Now I want to create new packages out of this repositories (I hope this is the right way). 
Packages?
I'm afraid you lost me on this. Using your (cross)toolchain, you do
$ make
etc. to compile (& install) the binaries.
> But now I am facing the next problem, what type of packages do I have to create for each particular repository?
I believe you're asking something for a specific build system, but I
do not know which one.
What build system do you use?

Would it be interesting to setup things on your (linux) host PC on a virtual CAN bus?
Then several things may be a lot easier.

Kurt

Re: using j1939

[Kurt Van Dijck]

On Tue, Dec 06, 2011 at 01:14:03PM +0100, Kurt Van Dijck wrote:
> I believe you're asking something for a specific build system, but I
> do not know which one.
> What build system do you use?

I was too quick, I got the answer in history: you're using OSELAS....
Isn't that a Pengutronix toolchain? They may know how to do stuff...
Since linux-can now moved to git repositories, replacing 'can' with
'can-j1939' _could_ be easy...

Kurt

Re: using j1939

[Wolfgang]

> I'm afraid you lost me on this. Using your (cross)toolchain, you do
> $ make
> etc. to compile (& install) the binaries.

The guys from pengutronix (I am using ptxdist 2010.07.1) told me 
that I have to know how the things in the repositories 
have to be built.

> > But now I am facing the next problem, what type of packages do 
I have to
create for each particular repository?
> I believe you're asking something for a specific build system, but I
> do not know which one.
> What build system do you use?

found and using toolchain:
'/opt/OSELAS.Toolchain-1.99.3/powerpc-603e-linux-gnu/
gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/bin'


> Would it be interesting to setup things on your (linux) host 
>PC on a virtual CAN bus?
> Then several things may be a lot easier.

It should or have to run on the target phyCore MPC5121etiny

Wolfgang

Re: using j1939

[Kurt Van Dijck]

> The guys from pengutronix (I am using ptxdist 2010.07.1) told me 
> that I have to know how the things in the repositories 
> have to be built.
> 
can-j1939-utils: (Similar to can-utils)
I think you need to do this:
$ ./autogen.sh
$ ./configure --host=powerpc-603e-linux-gnu --prefix=/usr
$ make
$ make install DESTDIR=...

iproute2-j1939: (Similar to iproute2, which is for sure present in your toolchain)
I think you need to do this:
$ make KERNEL_INCLUDE=<KERNEL_HEADER_PATH> CC=powerpc-603e-linux-gnu-gcc
$ make install DESTDIR=...

can-j1939-modules:
I'm not sure. Building this package with a cross-toolchain is something I never did.
I patched the kernel source itself in a 'cross' situation.
I only used can-j1939-modules for my own host.

anyone?

> > > But now I am facing the next problem, what type of packages do 
> I have to
> create for each particular repository?
Yes, I think so.

Kurt

Re: using j1939

[Oliver Hartkopp]

On 06.12.2011 13:37, Wolfgang wrote:
>> I'm afraid you lost me on this. Using your (cross)toolchain, you do
>> $ make
>> etc. to compile (&  install) the binaries.
>
> The guys from pengutronix (I am using ptxdist 2010.07.1) told me
> that I have to know how the things in the repositories
> have to be built.
>
>>> But now I am facing the next problem, what type of packages do
> I have to
> create for each particular repository?
>> I believe you're asking something for a specific build system, but I
>> do not know which one.
>> What build system do you use?
>
> found and using toolchain:
> '/opt/OSELAS.Toolchain-1.99.3/powerpc-603e-linux-gnu/
> gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/bin'
>

Hello Wolfgang,

when you build your BSP e.g. with

ptxdist images

in the directory 'build-target/linux-2.6.xx' your Linux kernel is 
unpacked, patched and compiled.

For a quick hack you can just try to update the files in

build-target/linux-2.6.xx/net/can/*
build-target/linux-2.6.xx/include/linux/can/*

with the files from Kurt (can-j1939-modules).

The you need to drop the compile stage with

pxtdist drop kernel.compile

And then build the stuff again (with 'ptxdist images')

Btw. the idea from Kurt with cross-compiling is also good.

But you should define the KERNELDIR= .../build-target/linux-2.6.xx then 
as THIS is the real kernel you are building for your system.

Regards,
Oliver

Re: using j1939

[Wolfgang]

> can-j1939-utils: (Similar to can-utils)
> I think you need to do this:
> $ ./autogen.sh
> $ ./configure --host=powerpc-603e-linux-gnu --prefix=/usr
> $ make
> $ make install DESTDIR=...

it is working but nothing is built in the directory /test
.......
libtool: install: /usr/bin/install -c slcanpty /usr/bin/slcanpty
make[1]: Nothing to be done for `install-data-am'.
make[1]: Leaving directory `/can-j1939-utils'
make: Nothing to be done for `/test'


> iproute2-j1939: (Similar to iproute2, which is for sure present
in your toolchain)
> I think you need to do this:
> $ make KERNEL_INCLUDE=<KERNEL_HEADER_PATH> CC=powerpc-603e-linux-gnu
>-gcc

utils.c: In function ‘rt_addrpr_n2a’:
utils.c:518: error: ‘AF_CAN’ undeclared (first use in this function)
utils.c:518: error: (Each undeclared identifier is reported only once
utils.c:518: error: for each function it appears in.)
make[1]: *** [utils.o] Error 1
make: *** [all] Error 2

> $ make install DESTDIR=...
 
> can-j1939-modules:
> I'm not sure. Building this package with a cross-toolchain 
is something I never did.
> I patched the kernel source itself in a 'cross' situation.
> I only used can-j1939-modules for my own host.

Are these mandatory or what files do I have to use?

 
--Wolfgang

using j1939: j1939.h

[Kurt Van Dijck]

On Wed, Dec 07, 2011 at 08:55:58AM +0000, Wolfgang wrote:

I forgot to mention the modifications to your toolchain:
include/linux/can.h and include/linux/can/j1939.h must be taken
accordingly to what you'll find in can-j1939-modules (under
include/socketcan/{can.h,can/j1939.h}.

Otherwise, you will not build any of j1939 I think...

@Oliver,
How can one use the headers of an external can-modules
repository for CAN?


> > can-j1939-utils: (Similar to can-utils)
> > I think you need to do this:
> > $ ./autogen.sh
do not forget to
$ export PATH=$PATH:YOUR_PATH_TO_POWERPC_TOOLCHAIN_BIN
> > $ ./configure --host=powerpc-603e-linux-gnu --prefix=/usr
I see (using some arm compiler)
...
checking for strtoul... yes
checking for linux/can/gw.h... no
checking for linux/can/j1939.h... yes
...
> > $ make
...
canbusload.c:(.text+0x890): undefined reference to `pselect'
...
So, I edited GNUmakefile, and removed canbusload from the program list.
and then, all gets compiled.

> > $ make install DESTDIR=...
> 
> it is working but nothing is built in the directory /test
"/test" ?
> .......
> libtool: install: /usr/bin/install -c slcanpty /usr/bin/slcanpty
> make[1]: Nothing to be done for `install-data-am'.
> make[1]: Leaving directory `/can-j1939-utils'
> make: Nothing to be done for `/test'
Now I'm sure, you forgot the j1939 header in the toolchain.

I'm gonna work to indicate j1939.h status during ./configure ...
It's these kind of small problems that I never encountered during
development ...
> 

Kurt

Re: using j1939: j1939.h

[Kurt Van Dijck]

> I'm gonna work to indicate j1939.h status during ./configure ...
> It's these kind of small problems that I never encountered during
> development ...
I pushed 1 commit to can-j1939-utils.
$ ./autogen.sh
must be issued again. It will now show more explicit that SAE J1939
will be built or not.

> > 
> 
> Kurt

Re: using j1939: j1939.h

[Wolfgang]

Now everything worked fine and I was able compile can-j1939-utils,
iproute2-j1939 and I got two directories with $.../usr/bin.

Where do I have to place this 2 folders now or how do I get it 
proper to the target?

Thanks!!

using j1939: userspace binaries

[Kurt Van Dijck]

On Thu, Dec 08, 2011 at 12:23:47PM +0000, Wolfgang wrote:
> Now everything worked fine and I was able compile can-j1939-utils,
> iproute2-j1939 and I got two directories with $.../usr/bin.
great!
> 
> Where do I have to place this 2 folders now
all binaries in ..../usr/bin should go in /usr/bin on the target.

Kurt

Re: using j1939: userspace binaries

[Wolfgang]

> > Where do I have to place this 2 folders now
> all binaries in ..../usr/bin should go in /usr/bin on the target.

ok just copy and paste? But from which directory the one generated 
by can-j1939-utils or iproute2-j1939 because they contain both 
all the same binaries.

--Wolfgang

Re: using j1939: userspace binaries

[Kurt Van Dijck]

On Thu, Dec 08, 2011 at 12:48:53PM +0000, Wolfgang wrote:
> > > Where do I have to place this 2 folders now
> > all binaries in ..../usr/bin should go in /usr/bin on the target.
> 
> ok just copy and paste?
for example
> But from which directory the one generated 
> by can-j1939-utils or iproute2-j1939 because they contain both 
> all the same binaries.
that sounds not good.
can-j1939-utils should have binaries like candump, can..., jspy, jacd, ...

iproute2-j1939 should have (at least) ip.

what files (binaries) exist in your .../usr/bin ?

Kurt

Re: using j1939: userspace binaries

[Wolfgang]

> that sounds not good.
> can-j1939-utils should have binaries like candump, can..., jspy, jacd, ...

^^yes, that is true


 
> iproute2-j1939 should have (at least) ip.

gosh, it seems that I was a bit puzzled.

I wanted to make

$ make KERNEL_INCLUDE=<KERNEL_HEADER_PATH> CC=powerpc-603e-linux-gnu-gcc
then 

utils.c: In function ‘rt_addrpr_n2a’:
utils.c:518: error: ‘AF_CAN’ undeclared (first use in this function)
utils.c:518: error: (Each undeclared identifier is reported only once
utils.c:518: error: for each function it appears in.)
make[1]: *** [utils.o] Error 1
make: *** [all] Error 2

occured

using j1939: AF_CAN missing

[Kurt Van Dijck]

On Thu, Dec 08, 2011 at 02:27:23PM +0000, Wolfgang wrote:
> > that sounds not good.
> > can-j1939-utils should have binaries like candump, can..., jspy, jacd, ...
> 
> ^^yes, that is true
> 
> 
>  
> > iproute2-j1939 should have (at least) ip.
> 
> gosh, it seems that I was a bit puzzled.
> 
> I wanted to make
> 
> $ make KERNEL_INCLUDE=<KERNEL_HEADER_PATH> CC=powerpc-603e-linux-gnu-gcc
> then 
I went back to this. I think I indeed puzzled you a bit.

For can-(j1939-)modules, you have to 'KERNEL_INCLUDE=<KERNEL_HEADER_PATH>'
or even better, KERNEL_DIR=...,

For iproute2(-j1939), 
$ make CC=powerpc-603e-linux-gnu-gcc
will do.

But I believe you almost there.

> 
> utils.c: In function ‘rt_addrpr_n2a’:
> utils.c:518: error: ‘AF_CAN’ undeclared (first use in this function)
It appears your toolchain isn't even aware of CAN.
I'm not sure how to solve that one.

Anyone?

Kurt

iproute2-j1939

[Kurt Van Dijck]

Wolfgang,

While playing with iproute2-j1939, I detected an outdated header j1939.h.

please pull.

Kurt

Re: using j1939: AF_CAN missing

[Oliver Hartkopp]

Am 08.12.2011 16:17, schrieb Kurt Van Dijck:
>
> utils.c: In function ‘rt_addrpr_n2a’:
> utils.c:518: error: ‘AF_CAN’ undeclared (first use in this function)
> It appears your toolchain isn't even aware of CAN.
> I'm not sure how to solve that one.
>
> Anyone?

Yep. As i written before the include files of the BSP itself are outdated.

You need to specifiy the Kernel includes directory to be taken from the 
cross built Kernel.

---
in the directory 'build-target/linux-2.6.xx' your Linux kernel is 
unpacked, patched and compiled.

For a quick hack you can just try to update the files in

build-target/linux-2.6.xx/net/can/*
build-target/linux-2.6.xx/include/linux/can/*
---

This kernel supports CAN.

Your modules will not match (and load) if you build the modules against 
a different kernel.

And also the can-utils are happy when having the 'right' kernel includes ;-)

Regards,
Oliver

Re: iproute2-j1939

[Wolfgang]

I pulled it, but the error remains. 

Is it possible that 
I am using the wrong kernel_header_path:
/.../OSELAS.BSP-Phytec-phyCORE-MPC512x-tiny-PD10.1.0\
/platform-phyCORE-MPC5121e/sysroot-target/kernel-headers

Re: iproute2-j1939

[Wolfgang]

OK, I should read all posts not only the last one.

I made:
with the new one

$iproute2-j1939> make CC=powerpc-603e-linux-gnu-gcc

same error "AF-CAN" undeclared



$can-j1939-modules>make KERNEL_DIR=<...> C=powerpc-603e-linux\
-gnu-gcc

make[1]: *** No rule to make target `modules'.  Stop.
make: *** [modules] Error 2

So do you think I have to replace the can.h in the
kernel_header_path
(/,.../sysroot-target/kernel-headers/include/linux)?

--Wolfgang

Re: iproute2-j1939

[Oliver Hartkopp]

Am 08.12.2011 17:44, schrieb Wolfgang:
> OK, I should read all posts not only the last one.
>
> I made:
> with the new one
>
> $iproute2-j1939>  make CC=powerpc-603e-linux-gnu-gcc
>
> same error "AF-CAN" undeclared
>
>
>
> $can-j1939-modules>make KERNEL_DIR=<...>  C=powerpc-603e-linux\
> -gnu-gcc
>
> make[1]: *** No rule to make target `modules'.  Stop.
> make: *** [modules] Error 2
>
> So do you think I have to replace the can.h in the
> kernel_header_path
> (/,.../sysroot-target/kernel-headers/include/linux)?

What do you use for KERNEL_DIR=<..> ??
Can you send the complete line?

Regards,
Oliver

Re: iproute2-j1939

[Wolfgang]

Morning,

> What do you use for KERNEL_DIR=<..> ??
> Can you send the complete line?
> 
I have build the BSP (which is supporting socketcan) some time ago;

I make in ip2route-j1939:

$ make KERNEL_DIR=</home/wolfgang/phytec/kernel/OSELAS.BSP-Phytec-\
phyCORE-MPC512x-tiny-PD09.1.0/platform-phyCORE-MPC5121e/build-target\
/linux-2.6.31> CC=powerpc-603e-linux-gnu-gcc

Re: iproute2-j1939

[Oliver Hartkopp]

Am 09.12.2011 08:28, schrieb Wolfgang:
> Morning,
>
>> What do you use for KERNEL_DIR=<..>  ??
>> Can you send the complete line?
>>
> I have build the BSP (which is supporting socketcan) some time ago;
>
> I make in ip2route-j1939:
>
> $ make KERNEL_DIR=</home/wolfgang/phytec/kernel/OSELAS.BSP-Phytec-\
> phyCORE-MPC512x-tiny-PD09.1.0/platform-phyCORE-MPC5121e/build-target\
> /linux-2.6.31>  CC=powerpc-603e-linux-gnu-gcc

Hm:

Try to remove the < > and/or try to define an extra define for the 
include path to catch

|
|.../build-target/linux-2.6.31/include

e.g. like in this EXTRA_CFLAGS

|EXTRA_CFLAGS += \
||         -I$(TOPDIR)/include \
||         -I$(TOPDIR)/drivers/net/can/hal \
||         \
||         -DETH_P_CAN=0x000C \
||         -DARPHRD_CAN=280|

Regards,
Oliver

Re: iproute2-j1939

[Kurt Van Dijck]

> So do you think I have to replace the can.h in the
> kernel_header_path
can.h got updated (struct can_addr extended), but I'm not sure
exactly which paths must be updated.

Kurt

Re: iproute2-j1939

[Oliver Hartkopp]

Am 09.12.2011 09:07, schrieb Kurt Van Dijck:
>> So do you think I have to replace the can.h in the
>> kernel_header_path
> can.h got updated (struct can_addr extended), but I'm not sure
> exactly which paths must be updated.

Argh - right. I missed that.

So my written ideas missed this detail :-(

Sorry,
Oliver

Re: iproute2-j1939

[Wolfgang]

> can.h got updated (struct can_addr extended), but I'm not sure
> exactly which paths must be updated.

OK, so do you think I have to replace the existing can.h with the can.h from
can-j1939-modules?

Or is it possible that the af_can.h (found in can-j1939-modules/net/can)
has to be included in the utils.c file (utils.c:518: error: 'AF_CAN'\
 undeclared (first use in this function), it's just an idea?

Re: iproute2-j1939

[Kurt Van Dijck]

On Fri, Dec 09, 2011 at 09:02:53AM +0000, Wolfgang wrote:
> > can.h got updated (struct can_addr extended), but I'm not sure
> > exactly which paths must be updated.
> 
> OK, so do you think I have to replace the existing can.h with the can.h from
> can-j1939-modules?
Yes, I think so.
> 
> Or is it possible that the af_can.h (found in can-j1939-modules/net/can)
> has to be included in the utils.c file (utils.c:518: error: 'AF_CAN'\
>  undeclared (first use in this function), it's just an idea?
No, you don't need CAN.

the macro AF_CAN for userspace applications is in bits/socket.h (of the toolchain),
included by sys/socket.h.
If AF_CAN is unknown, even when "#include <sys/socket.h>", you need to modify
bits/socket.h IMO. "#include <linux/socket.h>" would work, but feels a bit dirty.

You can safely add "#define AF_CAN 29" and "#define AF_CAN PF_CAN" in "sys/socket.h"

Kurt

Re: iproute2-j1939

[Wolfgang]

> You can safely add "#define AF_CAN 29" and "#define AF_CAN PF_CAN" in
"sys/socket.h"

Ok, I have, done that and it worked but now the next error occured, next thing
was not declared. So I thought, I will build the newer oselas toolchain? Does
this make sense?

new one:                       old one:
gcc-4.5.2                      gcc-4.3.2
glibc-2.13-binutils-2.21       glibc-2.8-binutils-2.18
linux-2.6.36                   linux-2.6.27


--Wolfgang

Re: iproute2-j1939

[Kurt Van Dijck]

On Fri, Dec 09, 2011 at 10:56:01AM +0000, Wolfgang wrote:
> > You can safely add "#define AF_CAN 29" and "#define AF_CAN PF_CAN" in
> "sys/socket.h"
> 
> Ok, I have, done that and it worked but now the next error occured, next thing
> was not declared. So I thought, I will build the newer oselas toolchain? Does
What was not declared?

> this make sense?
> 
> new one:                       old one:
> gcc-4.5.2                      gcc-4.3.2
> glibc-2.13-binutils-2.21       glibc-2.8-binutils-2.18
> linux-2.6.36                   linux-2.6.27
> 
I'm not aware of the integration of linux-can in glibc's headers.
Anyone experience with this configuration?

I'm asking myself, do you got regular iproute2 compiled (with CAN)?
I believe you facing problems not related to my j1939 port of them.

Kurt

Re: iproute2-j1939

[Wolfgang]

> I'm asking myself, do you got regular iproute2 compiled (with CAN)?
> I believe you facing problems not related to my j1939 port of them.

Do you mean the iproute2 which is included in the BSP?

--Wolfgang

Re: iproute2-j1939

[Kurt Van Dijck]

On Fri, Dec 09, 2011 at 11:12:30AM +0000, Wolfgang wrote:
> > I'm asking myself, do you got regular iproute2 compiled (with CAN)?
> > I believe you facing problems not related to my j1939 port of them.
> 
> Do you mean the iproute2 which is included in the BSP?
Yes.
It must have been compiled, and I assume it carries CAN support.
The j1939 port of iproute2 does fail on things like AF_CAN etc.
Something must be different.

Kurt

Re: iproute2-j1939

[Wolfgang]

> > > I'm asking myself, do you got regular iproute2 compiled (with CAN)?
> > > I believe you facing problems not related to my j1939 port of them.
> > 
> > Do you mean the iproute2 which is included in the BSP?
> Yes.
> It must have been compiled, and I assume it carries CAN support.
> The j1939 port of iproute2 does fail on things like AF_CAN etc.
> Something must be different.

Ok, I see it is really tough.
At the moment I am building the new toolchain, afterwards I will build a new
BSP. Maybe I have spoilt anything, in the BSP src directory is the ordinary
iproute2-2.6.29-1.tar.bz2 in fact, but maybe a new BSP will help!

--Wolfgang

Re: using j1939

[Kurt Van Dijck]

Wolfgang et.al.,

I created git://gitorious.org:~kurt-vd/linux-can/linux-can-j1939.git
This is a clone of linux-can (currently 3.2.0-rc2+), with can-j1939 built in.

Kurt

On Tue, Dec 06, 2011 at 02:24:21PM +0100, Oliver Hartkopp wrote:
> On 06.12.2011 13:37, Wolfgang wrote:
> >>I'm afraid you lost me on this. Using your (cross)toolchain, you do
> >>$ make
> >>etc. to compile (&  install) the binaries.
> >
> >The guys from pengutronix (I am using ptxdist 2010.07.1) told me
> >that I have to know how the things in the repositories
> >have to be built.
> >
> >>>But now I am facing the next problem, what type of packages do
> >I have to
> >create for each particular repository?
> >>I believe you're asking something for a specific build system, but I
> >>do not know which one.
> >>What build system do you use?
> >
> >found and using toolchain:
> >'/opt/OSELAS.Toolchain-1.99.3/powerpc-603e-linux-gnu/
> >gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/bin'
> >
> 
> Hello Wolfgang,
> 
> when you build your BSP e.g. with
> 
> ptxdist images
> 
> in the directory 'build-target/linux-2.6.xx' your Linux kernel is
> unpacked, patched and compiled.
> 
> For a quick hack you can just try to update the files in
> 
> build-target/linux-2.6.xx/net/can/*
> build-target/linux-2.6.xx/include/linux/can/*
> 
> with the files from Kurt (can-j1939-modules).
> 
> The you need to drop the compile stage with
> 
> pxtdist drop kernel.compile
> 
> And then build the stuff again (with 'ptxdist images')
> 
> Btw. the idea from Kurt with cross-compiling is also good.
> 
> But you should define the KERNELDIR= .../build-target/linux-2.6.xx
> then as THIS is the real kernel you are building for your system.
> 
> Regards,
> Oliver
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: using j1939

[Wolfgang]

> I created git://gitorious.org:~kurt-vd/linux-can/linux-can-j1939.git
> This is a clone of linux-can (currently 3.2.0-rc2+), with can-j1939
>built in.

Thanks, I am wondering how or what can I use?

Re: using j1939

[Kurt Van Dijck]

On Fri, Dec 09, 2011 at 03:49:11PM +0100, Wolfgang Wagner wrote:
> > I don't understand your question.
> > Yes, you may use it.
> 
> I cloned the linux-can-j1939 repository, but how do I get it to the target or what I have to do to get it setup for the target?
Ok, I suppose you do not compile your kernel yourself.
I don't know that for your system.

Let's stick to the original plan then and get can-j1939-modules working (after getting iproute2-j1939 up).

Kurt
> 
> Thanks!
> 
> -- 
> NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
> Jetzt informieren: http://www.gmx.net/de/go/freephone

Re: using j1939

[Wolfgang Wagner]

> Ok, I suppose you do not compile your kernel yourself.

Yes, ptxdist compiles everything automatic, but as Oliver suggest
for my system I can can drop the kernel and compile it again with 

$ ptxdist drop kernel compile
$ ptxdist go

So is there a possibility to modify my kernel with files of your
linux-can-j1939 repository and compile it again?


> Let's stick to the original plan then and get can-j1939-modules working
(after getting iproute2-j1939 up).

So if I use the tarball iproute2-2.6.39.tar.gz, you can find everywhere,
it should work? Or is there the possibility, that I possibly can faulty
one?

Re: using j1939

[Kurt Van Dijck]

On Fri, Dec 09, 2011 at 05:23:52PM +0000, Wolfgang Wagner wrote:
> > Ok, I suppose you do not compile your kernel yourself.
> 
> Yes, ptxdist compiles everything automatic, but as Oliver suggest
> for my system I can can drop the kernel and compile it again with 
> 
> $ ptxdist drop kernel compile
> $ ptxdist go
> 
> So is there a possibility to modify my kernel with files of your
> linux-can-j1939 repository and compile it again?
Yes, that must work. Take everything in net/can/*.
I'm not sure on the drivers. They may use other subsystems (like USB)
that have differences accross versions.
I'd first try to core CAN itself(net/can) and leave the drivers (drivers/net/can)
as is.
The header is a bit a mixture:
copy include/linux/can.h, all include/linux/can/*.h  but dev.h, and
_no_ include/linux/can/platform/*.h

> 
> 
> > Let's stick to the original plan then and get can-j1939-modules working
> (after getting iproute2-j1939 up).
> 
> So if I use the tarball iproute2-2.6.39.tar.gz, you can find everywhere,
> it should work? Or is there the possibility, that I possibly can faulty
> one?
I think a iproute2-2.6.39.tar.gz should compile.
Iproute2-j1939 did fail because of CAN definitions, that are in  a standard
iproute2 also.
If that one  compiles, my iproute2-j1939 should work as.
> 

Kurt

Re: using j1939

[Wolfgang]

> Yes, that must work. Take everything in net/can/*.
> I'm not sure on the drivers. They may use other subsystems (like USB)
> that have differences accross versions.
> I'd first try to core CAN itself(net/can) and leave the drivers
(drivers/net/can)
> as is.
> The header is a bit a mixture:
> copy include/linux/can.h, all include/linux/can/*.h  but dev.h, and
> _no_ include/linux/can/platform/*.h

Ok I replaced everything as you told me, but while compiling

make[1]: Entering directory
`/home/wolfgang/phytec/kernel/OSELAS.BSP-Phytec-phyCORE-MPC512x-tiny-\
PD09.1.0/platform-phyCORE-MPC5121e/build-target/linux-2.6.31'
  CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
  SYMLINK include/asm -> include/asm-powerpc
  CALL    scripts/checksyscalls.sh
  CHK     include/linux/compile.h
  CALL    arch/powerpc/kernel/systbl_chk.sh
  CC      net/can/bcm.o
In file included from net/can/bcm.c:55:
include/linux/can.h:80: error: expected specifier-qualifier-list \
before'__kernel_sa_family_t'
net/can/bcm.c: In function 'bcm_proc_getifname':
net/can/bcm.c:150: error: implicit declaration of function
'dev_get_by_index_rcu'
net/can/bcm.c:150: warning: assignment makes pointer from integer \
without a cast
net/can/bcm.c: In function 'bcm_send_to_user':
net/can/bcm.c:332: error: 'struct sockaddr_can' has no member named\ 
can_family'
net/can/bcm.c:333: error: 'struct sockaddr_can' has no member named 
can_ifindex'
net/can/bcm.c: In function 'bcm_sendmsg':
net/can/bcm.c:1253: error: 'struct sockaddr_can' has no member named 
'can_ifindex'
net/can/bcm.c:1253: error: 'struct sockaddr_can' has no member named 
'can_ifindex'
net/can/bcm.c:1256: error: 'struct sockaddr_can' has no member named 
'can_family'
net/can/bcm.c:1260: error: 'struct sockaddr_can' has no member named 
'can_ifindex'
net/can/bcm.c: In function 'bcm_connect':
net/can/bcm.c:1495: error: 'struct sockaddr_can' has no member named 
'can_ifindex'
net/can/bcm.c:1495: error: 'struct sockaddr_can' has no member named 
'can_ifindex'
net/can/bcm.c:1502: error: 'struct sockaddr_can' has no member named 
'can_ifindex'
net/can/bcm.c:1505: error: 'struct sockaddr_can' has no member named 
'can_ifindex'
net/can/bcm.c: In function 'bcm_recvmsg':
net/can/bcm.c:1559: error: implicit declaration of function 
'sock_recv_ts_and_drops'
make[3]: *** [net/can/bcm.o] Error 1
make[2]: *** [net/can] Error 2
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [net] Error 2
make[1]: *** Waiting for unfinished jobs....

Re: using j1939

[Kurt Van Dijck]

On Mon, Dec 12, 2011 at 11:27:33AM +0000, Wolfgang wrote:
> > Yes, that must work. Take everything in net/can/*.
> > I'm not sure on the drivers. They may use other subsystems (like USB)
> > that have differences accross versions.
> > I'd first try to core CAN itself(net/can) and leave the drivers
> (drivers/net/can)
> > as is.
> > The header is a bit a mixture:
> > copy include/linux/can.h, all include/linux/can/*.h  but dev.h, and
> > _no_ include/linux/can/platform/*.h
> 
> Ok I replaced everything as you told me, but while compiling
> 
> make[1]: Entering directory
> `/home/wolfgang/phytec/kernel/OSELAS.BSP-Phytec-phyCORE-MPC512x-tiny-\
> PD09.1.0/platform-phyCORE-MPC5121e/build-target/linux-2.6.31'
>   CHK     include/linux/version.h
>   CHK     include/linux/utsrelease.h
>   SYMLINK include/asm -> include/asm-powerpc
>   CALL    scripts/checksyscalls.sh
>   CHK     include/linux/compile.h
>   CALL    arch/powerpc/kernel/systbl_chk.sh
>   CC      net/can/bcm.o
> In file included from net/can/bcm.c:55:
> include/linux/can.h:80: error: expected specifier-qualifier-list \
> before'__kernel_sa_family_t'

I've noticed in recent kernels that 'sa_family_t' got replaced
by '__kernel_sa_family_t'.
I see no harm in undoing this, thus modifying the new include/linux/can.h,
making sockaddr_can.can_family of type sa_family_t again.

Kurt

Re: using j1939

[Wolfgang]

I am sorry next error:

CHK     include/linux/version.h                                                
                                                                               
         
  CHK     include/linux/utsrelease.h                                           
                                                                               
           
  SYMLINK include/asm -> include/asm-powerpc                                   
                                                                               
           
  CALL    scripts/checksyscalls.sh                                             
                                                                               
           
  CHK     include/linux/compile.h                                              
                                                                               
           
  CALL    arch/powerpc/kernel/systbl_chk.sh                                    
                                                                               
           
  CC      net/can/bcm.o                                                        
                                                                               
           
net/can/bcm.c: In function 'bcm_proc_getifname':                               
                                                                               
           
net/can/bcm.c:150: error: implicit declaration of function
'dev_get_by_index_rcu'                                                         
                                
net/can/bcm.c:150: warning: assignment makes pointer from integer without a cast
                                                                               
          
  CC      net/can/gw.o                                                         
                                                                               
           
net/can/bcm.c: In function 'bcm_recvmsg':                                      
                                                                               
           
net/can/bcm.c:1559: error: implicit declaration of function
'sock_recv_ts_and_drops'                                                       
                               
make[3]: *** [net/can/bcm.o] Error 1                                           
                                                                               
           
make[3]: *** Waiting for unfinished jobs....
  CC      drivers/net/can/dev.o
net/can/gw.c: In function 'cgw_module_init':
net/can/gw.c:928: error: too many arguments to function '__rtnl_register'
net/can/gw.c:935: error: too many arguments to function '__rtnl_register'
net/can/gw.c:936: error: too many arguments to function '__rtnl_register'
make[3]: *** [net/can/gw.o] Error 1
make[2]: *** [net/can] Error 2
make[1]: *** [net] Error 2
make[1]: *** Waiting for unfinished jobs....
  CC      drivers/net/can/mscan/mscan.o
  CC      drivers/net/can/mscan/mpc52xx_can.o
  LD      drivers/net/can/can-dev.o
  LD      drivers/net/can/mscan/mscan-mpc52xx.o
  LD      drivers/net/can/mscan/built-in.o
  LD      drivers/net/can/built-in.o
  LD      drivers/net/built-in.o
  LD      drivers/built-in.o

--Wolfgang

backporting can & can-j1939

[Kurt Van Dijck]

Wolfgang,

I tried myself a little backport of net/can/ into 2.6.31.
It appears quite complex. It may be better to start over
with a fresh kernel, and copy those files from my
can-j1939-modules, since this repository contains
#if KERNEL_VERSION macros that will make it work on 2.6.31.

I'm even using this on 2.6.25, so don't worry, it _will_ work
sooner or later.

I'm not sure exactly how the include/socketcan from can-j1939-modules
should be merged into the kernel source.
I think this is a bit of a manual job to do for the header files.

Anyone better ideas?

Kind regards,
Kurt

Re: backporting can & can-j1939

[Wolfgang]

> It appears quite complex. It may be better to start over
> with a fresh kernel, and copy those files from my
> can-j1939-modules, since this repository contains
> #if KERNEL_VERSION macros that will make it work on 2.6.31.

I am not really sure, so I ask, should I build a new kernel and after building
replace the things from can-j1939-modules or should I place the things from
can-j1939-modules before building the kernel?
And what particular things should I copy?

--Wolfgang

Re: backporting can & can-j1939

[Kurt Van Dijck]

On Tue, Dec 13, 2011 at 03:20:24PM +0000, Wolfgang wrote:
> > It appears quite complex. It may be better to start over
> > with a fresh kernel, and copy those files from my
> > can-j1939-modules, since this repository contains
> > #if KERNEL_VERSION macros that will make it work on 2.6.31.
> 
> I am not really sure, so I ask, should I build a new kernel and after building
> replace the things from can-j1939-modules or should I place the things from
> can-j1939-modules before building the kernel?
> And what particular things should I copy?

Ok, Maybe I did explain it a bit fuzzy.

Like Oliver suggested earlier, you will ultimately build a new kernel.
1. You extract the kernel source (I believe $ptxdist prepare <kernel>).
2. You copy from can-j1939-modules into the extracted kernel sources:
   $ cp -r <can-j1939>/net/can/* <kernel>/net/can/
   $ cp <can-j1939>/include/socketcan/can.h <kernel>/include/linux/can.h
   $ cp <can-j1939>/include/socketcan/can/{bcm,core,error,gw,isotp,j1939,netlink,raw}.h \
	<kernel>/include/linux/can/
   and replace all "#include <socketcan/xxx.h>"
   with "#include <linux/xxx.h>".
   This "#include" thing will appear in files you just copies (net/can/* and include/linux/can*)
3. Continue the build process

Sorry for not making this clear the first time :-).
I hope it is clear now?

Kurt

Re: backporting can & can-j1939

[Wolfgang]

> Sorry for not making this clear the first time .
> I hope it is clear now?

That is absolutly no problem, I am really glad that you are helping me that much.

I hope this will work with less trouble!

--Wolfgang

Re: backporting can & can-j1939

[Wolfgang]

Your proposal worked perfect, I can still hardly believe it.

on the target:

$ dmesg | fgrep -i can

mpc52xx_can 80001300.mscan: MSCAN at 0xd1080300, irq 16, clock 100000000 Hz
mpc52xx_can 80001380.mscan: MSCAN at 0xd1084380, irq 17, clock 100000000 Hz
can: controller area network core (rev 20090105 abi 8)
can: raw protocol (rev 20090105)
can: broadcast manager protocol (rev 20090105 t)
can: netlink gateway (rev 20101209)
can: SAE J1939


but when I type (according  to the j1939.txt)

$ ip link set can0 j1939 on

it says:

Error: either "dev" is duplicate, or "j1939" is a garbage.

What have I done wrong, or how is it made right?


Thank you very much so far!!

--Wolfgang

Re: backporting can & can-j1939

[Kurt Van Dijck]

On Wed, Dec 14, 2011 at 01:29:08PM +0000, Wolfgang wrote:
> Your proposal worked perfect, I can still hardly believe it.

Ok, that relieves a bit the pressure.
> 
> on the target:
> 
> $ dmesg | fgrep -i can
> 
> mpc52xx_can 80001300.mscan: MSCAN at 0xd1080300, irq 16, clock 100000000 Hz
> mpc52xx_can 80001380.mscan: MSCAN at 0xd1084380, irq 17, clock 100000000 Hz
> can: controller area network core (rev 20090105 abi 8)
> can: raw protocol (rev 20090105)
> can: broadcast manager protocol (rev 20090105 t)
> can: netlink gateway (rev 20101209)
> can: SAE J1939
> 
> 
> but when I type (according  to the j1939.txt)
> 
> $ ip link set can0 j1939 on

Hold here: Your 2.6.31 is too old for this feature.
You must do : $ echo can0 > /proc/net/can-j1939/net
as a legacy measure.

You will be able to use $ip for adding/removing addressing info.

> 
> it says:
> 
> Error: either "dev" is duplicate, or "j1939" is a garbage.

This makes me think you have the original 'stock' iproute2, and not
the iproute2-j1939 one (but I'm not sure yet today).

I'll come back on this tomorrow...
Kurt

> 
> Thank you very much so far!!

Thank you for the patience with operating as a 'test user'!

Kurt

Re: backporting can & can-j1939

[Wolfgang]

> Hold here: Your 2.6.31 is too old for this feature.
> You must do : $ echo can0 > /proc/net/can-j1939/net
> as a legacy measure.
> 
> You will be able to use $ip for adding/removing addressing info.

Ok, I will try that.

> > Error: either "dev" is duplicate, or "j1939" is a garbage.
> 
> This makes me think you have the original 'stock' iproute2, and not
> the iproute2-j1939 one (but I'm not sure yet today).

Yes, you are right I was using the 'stock' iproute2, should I replace the stock 
with the j1939 iproute2, before compiling the kernel? I think I understood that 
wrong. 
Do I have to replace the can-utils as well; I am still not complete aware how
the respitories differ from each other


--Wolfgang

Using can & can-j1939

[Kurt Van Dijck]

On Wed, Dec 14, 2011 at 06:19:45PM +0000, Wolfgang wrote:
> > > Error: either "dev" is duplicate, or "j1939" is a garbage.
> > 
> > This makes me think you have the original 'stock' iproute2, and not
> > the iproute2-j1939 one (but I'm not sure yet today).
> 
> Yes, you are right I was using the 'stock' iproute2
That explains things :-)

> should I replace the stock 
> with the j1939 iproute2, before compiling the kernel?
No, not before 'compiling' the kernel.
But before 'using' the j1939 options from the newly compiled kernel.
> I think I understood that wrong. 
Not really..., see below

> Do I have to replace the can-utils as well;
Yes,
> I am still not complete aware how
> the respitories differ from each other
I did never really explain this, therefore:
I added j1939 into the kernel => recompile kernel.
I added j1939 configuration to iproute2 => replace iproute2 for using j1939
I added some specific j1939 support & monitoring tools (jacd, ...) => 
	replace can-utils for using j1939

Summarize: the real core of j1939 is in kernel space.
To get it up & running, you need some (smaller) userspace modifications.

I hope this demistifies a tiny bit

Kind regards,
Kurt

Re: Using can & can-j1939

[Wolfgang]

> I hope this demistifies a tiny bit

OK, I think things got a bit clearer for me.

1. You have to get the j1939 'into' the kernel space (check).
2. You have to cross compile the utils (check) and iproute2(remaining) and copy 
   it in the running target user space.

Hope I got that right!?


Now let's handle the problem with compilation of the iproute2, 
I did,
$make CC=powerpc-603e-linux-gnu-gcc error:

powerpc-603e-linux-gnu-gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall 
-I../include -DRESOLVE_HOSTNAMES -DLIBDIR=\"/usr/lib/\" -I/usr//usr/include  -o 
arpd arpd.c ../lib/libnetlink.a ../lib/libutil.a -ldb -lpthread
/opt/OSELAS.Toolchain-1.99.3/powerpc-603e-linux-gnu/gcc-4.3.2-glibc-2.8-binutils-
2.18-kernel-2.6.27-sanitized/lib/gcc/powerpc-603e-linux-gnu/4.3.2/../../../..
/powerpc-603e-linux-gnu/bin/ld: cannot find -ldb
collect2: ld returned 1 exit status
make[1]: *** [arpd] Error 1
make[1]: Leaving directory `/home/wolfgang/iproute2-j1939/misc'
make: *** [all] Error 2

Could that be a problem, because of an previous error a copied the db_185 header 
from the host to the toolchain usr/include directory?

--Wolfgang

Cross-compiling iproute2-j1939

[Kurt Van Dijck]

On Thu, Dec 15, 2011 at 08:35:30AM +0000, Wolfgang wrote:
> > I hope this demistifies a tiny bit
> 
> OK, I think things got a bit clearer for me.
> 
> 1. You have to get the j1939 'into' the kernel space (check).
> 2. You have to cross compile the utils (check) and iproute2(remaining) and copy 
>    it in the running target user space.
> 
> Hope I got that right!?
Yes, that's it.
You summarized it well, I'll reuse this for documentation eventually.
> 
> 
> Now let's handle the problem with compilation of the iproute2, 
> I did,
> $make CC=powerpc-603e-linux-gnu-gcc error:
> 
> powerpc-603e-linux-gnu-gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall 
> -I../include -DRESOLVE_HOSTNAMES -DLIBDIR=\"/usr/lib/\" -I/usr//usr/include  -o 
> arpd arpd.c ../lib/libnetlink.a ../lib/libutil.a -ldb -lpthread
> /opt/OSELAS.Toolchain-1.99.3/powerpc-603e-linux-gnu/gcc-4.3.2-glibc-2.8-binutils-
> 2.18-kernel-2.6.27-sanitized/lib/gcc/powerpc-603e-linux-gnu/4.3.2/../../../..
> /powerpc-603e-linux-gnu/bin/ld: cannot find -ldb
> collect2: ld returned 1 exit status
> make[1]: *** [arpd] Error 1
> make[1]: Leaving directory `/home/wolfgang/iproute2-j1939/misc'
> make: *** [all] Error 2
> 
> Could that be a problem, because of an previous error a copied the db_185 header 
> from the host to the toolchain usr/include directory?
I think you got really far now, and reached 'arpd' (on my system, 'ip' is compiled then).
'arpd' needs 'libdb'. I don't think copying the db_185 header is a problem, but the
libdb.so or libdb.a remains absent.

I think Pengutronix supports compiling iproute2 _with_ some patches. I think you
better apply those too.
As an alternative, you could get rid of arpd (I'm not using it on our target) with following
patch or similar:

Kurt

Index: iproute2-2.6.35/misc/Makefile
===================================================================
--- iproute2-2.6.35.orig/misc/Makefile	2010-08-25 16:27:27.000000000 +0200
+++ iproute2-2.6.35/misc/Makefile	2010-08-25 16:29:58.000000000 +0200
@@ -1,10 +1,10 @@
 SSOBJ=ss.o ssfilter.o
 LNSTATOBJ=lnstat.o lnstat_util.o
 
-TARGETS=ss nstat ifstat rtacct arpd lnstat
-
 include ../Config
 
+TARGETS=ss nstat ifstat rtacct lnstat $(MISC_EXTRA)
+
 all: $(TARGETS)
 
 ss: $(SSOBJ) $(LIBUTIL)

Re: Cross-compiling iproute2-j1939

[Wolfgang]

> I think Pengutronix supports compiling iproute2 _with_ some patches. 
>think you better apply those too. 
When you can use it I could send you the bash compiling iproute2 with pengutronix

I don't know which or what they patched, so I applied your proposal (I had to
change it in the iproute2-j1939, not in the BSP?) - and it worked.

When I have it to change it in the BSP, I am wondering how it get reference, 
because I do $make KERNEL_INCLUDE=<KERNEL_HEADER_PATH> CC=...

but the kernel header path is .../built-target/linux-2.6.31 and the
iproute2 path is ../built-target/iproute2-2.6.29-1 so they aren't 
in touch, as I understand that.

But I hope I did it right!! So can I now copy and/or replace the 
things which I created from compiling iproute2-j1939 and can-utils-j1939 
to the target or all of it?

(iproute2 created 6 directories etc, lib, sbin, share, usr, var)

--Wolfgang

replacing iproute2 & can-utils with j1939 variants

[Kurt Van Dijck]

On Thu, Dec 15, 2011 at 11:24:13AM +0000, Wolfgang wrote:
> 
> but the kernel header path is .../built-target/linux-2.6.31 and the
> iproute2 path is ../built-target/iproute2-2.6.29-1 so they aren't 
> in touch, as I understand that.
Kernel does not alter the ABI in an incompatible way. So iprout2-2.6.29
will work with linux-2.6.29 and higher.

The other way (like iproute2-2.6.35 on linux-2.6.31) works as long
as iproute2 does not use features introduced since 2.6.31 :-)

> 
> But I hope I did it right!! So can I now copy and/or replace the 
> things which I created from compiling iproute2-j1939 and can-utils-j1939 
> to the target or all of it?
You can.
To be more precise, you :
* _must_ replace the original 'ip' with the one from iproute2-j1939
* _must_ add 'jacd', 'jspy' and 'jsr' from can-j1939-utils

You _may_ replace other binaries, but that is not necessary.

Kurt

Re: replacing iproute2 & can-utils with j1939 variants

[Wolfgang]

I copied all things as you told me, I think/hope the hardest part is over now.
Thank you!!


What do I have to do afterwards I did

$ echo can0 /proc/net/can-j1939/net

because if I do '$ifconfig can0 up' it responses with 

mpc52xx_can 80001300.mscan: bit-timing not yet defined
ifconfig: SIOCSIFFLAGS: Invalid argument


(Just for information this time different answer:
$ ip link set can0 j1939 on
RTNETLINK answers: Invalid argument )

Is there any documentation or is it possible to use cangw with API?

--Wolfgang

using can-j1939

[Kurt Van Dijck]

On Thu, Dec 15, 2011 at 01:43:30PM +0000, Wolfgang wrote:
> I copied all things as you told me, I think/hope the hardest part is over now.
> Thank you!!
> 
> 
> What do I have to do afterwards I did
> 
> $ echo can0 /proc/net/can-j1939/net
$ echo can0 > /proc/net/can-j1939/net

> 
> because if I do '$ifconfig can0 up' it responses with 
> 
> mpc52xx_can 80001300.mscan: bit-timing not yet defined
> ifconfig: SIOCSIFFLAGS: Invalid argument

try:

$ ip link set can0 up type can bitrate 250000
> 
> 
> (Just for information this time different answer:
> $ ip link set can0 j1939 on
> RTNETLINK answers: Invalid argument )
> 

now, you can:

$ jspy -P
to see all j1939 packets. Transport Protocol sessions are assembled into big packets.

> Is there any documentation
There isn't much documenation yet of jspy & jsr, but they are basic tools.

$ jspy -?
produces:
jspy: An SAE J1939 spy utility
Usage: jspy [OPTION...] [[IFACE:][NAME|SA][,PGN]]

  -v, --verbose         Increase verbosity
  -P, --promisc         Run in promiscuous mode
                        (= receive traffic not for this ECU)
  -b, --block=SIZE      Use a receive buffer of SIZE (default 1024)
  -t, --time[=a|d|z|A]  Show time: (a)bsolute, (d)elta, (z)ero, (A)bsolute w date

$ jsr -?
produces:
jsr: An SAE J1939 send/recv utility
Usage: jsr [OPTION...] SOURCE [DEST]

  -v, --verbose         Increase verbosity
  -p, --priority=VAL    J1939 priority (0..7, default 6)
  -S, --serialize       Strictly serialize outgoing packets
  -s, --size            Packet size, default autodetected

  SOURCE        [IFACE:][NAME|SA][,PGN]
  DEST                  [NAME|SA]

jsr allows you to put stdin into transmitted j1939 packets, and received j1939 packets
onto stdout.

jacd is used for dynamic address claiming. I believe it's a bit early to start with.

$ ip
can now be used to:
* add SA 0x80 to can0

$ ip addr add j1939 0x80 dev can0

from that point, 0x80 can be used to send packets with.

and likewise
$ ip addr del j1939 0x80 dev can0

$ ip addr
may show things like:

4: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN qlen 10
    link/can 
    can-j1939 0x80 scope link 

> or is it possible to use cangw with API?
cangw (like can-j1939) is not present in your 2.6.31 kernel.
Since you managed importing can-j1939, importing cangw will succeed definitely.
cangw requires less modification in userspace tools ...

Before proceeding however, what exactly is the application?
Will you bridge j1939 packets unmodified?
Are transport sessions involved?
Is information repacked into different packets?

...
Kurt

Re: using can-j1939

[Wolfgang]

> Before proceeding however, what exactly is the application?
> Will you bridge j1939 packets unmodified?

I want read from one bus modify the data field of the j1939 frame and write the
modified packet on the other bus.

--Wolfgang

Re: using can-j1939

[Kurt Van Dijck]

On Thu, Dec 15, 2011 at 02:49:44PM +0000, Wolfgang wrote:
> > Before proceeding however, what exactly is the application?
> > Will you bridge j1939 packets unmodified?
> 
> I want read from one bus modify the data field of the j1939 frame and write the
> modified packet on the other bus.
So only 1 PGN is bridged? No other PGN's.

Kurt

Re: using can-j1939

[Wolfgang]

> So only 1 PGN is bridged? No other PGN's.

For the first steps I would be happy with 1 but finally and if it isn't 
'impossible' 3.

--Wolfgang

Re: using can-j1939

[Kurt Van Dijck]

On Thu, Dec 15, 2011 at 03:16:05PM +0000, Wolfgang wrote:
> > So only 1 PGN is bridged? No other PGN's.
> 
> For the first steps I would be happy with 1 but finally and if it isn't 
> 'impossible' 3.
ok. a limited number :-)

Do you relay them (on the second bus) using the same source address, i.e.
to all 3 PGN's use the same source address when sent out?
The source addresses of the 3 received PGN's (on the first bus) do not matter.

In fact, a limited number here is fine too.
The thing is, my can-j1939 stack is (BSD sockets alike) assigned a limited
number of J1939 source addresses. Only those source addresses are allowed
in outgoing packets (a bit like IP networks, and probably others)

You can do unmodified relaying even from the command line
by piping 2 instances of jsr, like

$ ip addr add j1939 0x80 dev can1
$ jsr can0:80,feda | jsr can1:80,feda

This should do some basics already.

Kurt

Re: using can-j1939

[Wolfgang]

> Do you relay them (on the second bus) using the same source address, 
>i.e.to all 3 PGN's use the same source address when sent out?
> The source addresses of the 3 received PGN's (on the first bus) 
>do not matter.
 
 In fact, a limited number here is fine too.
 The thing is, my can-j1939 stack is (BSD sockets alike) assigned a 
limited number of J1939 source addresses. Only those source addresses 
are allowed in outgoing packets (a bit like IP networks, 
and probably others)


No, all 3 PGNs are sent by one sender(source)!

--Wolfgang

Re: using can-j1939

[Kurt Van Dijck]

> I want read from one bus modify the data field of the j1939 frame and write the
> modified packet on the other bus.
Are the packets 'broadcasted' or destination specific?

Kurt

Re: using can-j1939

[Wolfgang]

> Are the packets 'broadcasted' or destination specific?

The packets are destination specific. But I was wrong the, it should read and
write from both bus' - sorry, but only 2 specific address'!

--Wolfgang

Re: using can-j1939

[Kurt Van Dijck]

On Fri, Dec 16, 2011 at 09:00:45AM +0000, Wolfgang wrote:
> > Are the packets 'broadcasted' or destination specific?
> 
> The packets are destination specific.
> But I was wrong the, it should read and
> write from both bus' - sorry, but only 2 specific address'!
Even that is no problem...

Re: using can-j1939

[Wolfgang]

> > The packets are destination specific.
> > But I was wrong the, it should read and
> > write from both bus' - sorry, but only 2 specific address'!
> Even that is no problem...

OK, this sounds great. I am just browsing through the documentation and wondering
if it is possible to activate j1939 per default, that it would be possible to use
the target as stand alone.

--Wolfgang

Re: using can-j1939

[Kurt Van Dijck]

On Fri, Dec 16, 2011 at 02:29:45PM +0000, Wolfgang wrote:
> > > The packets are destination specific.
> > > But I was wrong the, it should read and
> > > write from both bus' - sorry, but only 2 specific address'!
> > Even that is no problem...
> 
> OK, this sounds great. I am just browsing through the documentation and wondering
> if it is possible to activate j1939 per default,
Of course this is possible, but unwanted.
This choice is comparable to "not setting 250Kb per default".
Read more below.

> that it would be possible to use
> the target as stand alone.
You should initialize the CAN bus(ses) on powerup:
* set baudrate
* set j1939 on
* set iface up.

Typically this is done in some init scripts.

Kind regards,
Kurt

API calls

[Wolfgang]

Hi Kurt,

I am sorry, but I am not too much in socket programming yet, and I can't find 
much information about socketCAN. I am using the j1939.txt.

I am trying to create a socket and send something, the addr 0x80 I have defined
before. What have I done wrong or how is it made right?

#include <sys/ioctl.h>
#include <net/if.h>
#include <string.h>
#include <linux/can/j1939.h>
#include <unistd.h>
#include <sys/socket.h>
#include <stdio.h>



int main ()
{
    int s;
    s = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
	    
    struct sockaddr_can addr;

    memset(&addr, 0, sizeof(addr));
    addr.can_ifindex = ifindex("can0");
    addr.can_addr.j1939.name = TEST;
    addr.can_addr.j1939.addr = 0x80;
    addr.can_addr.j1939.pgn = 0x12300;

    bind(s, (void *)&addr, sizeof(addr));
    
    sendto(s, data, sizeof(data), 0, (void *)&addr, sizeof(addr));
    
}


Kind regards,
Wolfgang

Re: API calls

[Kurt Van Dijck]

On Tue, Dec 20, 2011 at 10:35:05AM +0000, Wolfgang wrote:
> Hi Kurt,
> 
> I am sorry, but I am not too much in socket programming yet, and I can't find 
> much information about socketCAN. I am using the j1939.txt.
man socket
man bind
man sendto
man recv
....

Socket programming (not CAN specific) wasn't very easy for me neither the first time.

Since you seem to have gottten pretty far with a first test program,
I've corrected some mistakes/bad practices.

> 
> I am trying to create a socket and send something, the addr 0x80 I have defined
> before. What have I done wrong or how is it made right?
> 
> #include <sys/ioctl.h>
> #include <net/if.h>
> #include <string.h>
#include <linux/can.h>
> #include <linux/can/j1939.h>
> #include <unistd.h>
> #include <sys/socket.h>
> #include <stdio.h>
/* for if_nametoindex() */
#include <net/if.h>
> 
> 
> 
> int main ()
> {
>     int s;
>     s = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
> 	    
>     struct sockaddr_can addr;
> 
>     memset(&addr, 0, sizeof(addr));
>     addr.can_ifindex = ifindex("can0");
     addr.can_ifindex = if_nametoindex("can0");
>     addr.can_addr.j1939.name = TEST;
@name is used for dynamic addressing.
If you're using static addressing, assign J1939_NO_NAME (== 0, so leaving is fine too).
      addr.can_addr.j1939.name = J1939_NO_NAME;

>     addr.can_addr.j1939.addr = 0x80;
>     addr.can_addr.j1939.pgn = 0x12300;
> 
>     bind(s, (void *)&addr, sizeof(addr));
better is:
	int ret;

	if (bind(...) < 0)
		perror("bind failed");
	
	if (send(s, data, sizeof(data), 0) < 0)
		perror("send failed");

If sizeof(data) <= 8, then this
will broadcast a message with _can_id_ 0x1923ff80:
* (/*priority*/6 << 26) | (/*pgn*/0x12300 << 8) | (/*source*/0x80).
* PGN 0x123 is of type PDU1 => destination address in PDU-specific
* no destination given => broadcast (0xff).

>     
>     sendto(s, data, sizeof(data), 0, (void *)&addr, sizeof(addr));
likewise, this would send the message to ..., yourself again.
can_id will be 0x19238080

I hope this clears up a bit.
J1939 isn't very transparent on the composition of it's CAN identifiers.
The can-j1939 stack deals with all issues, safeguarding you from protocol violations
on the bus, but the stack may return error codes when you try something illegal.
You should check them (i.e. doing "if (send(...) < 0) perror(...);")

Kind regards,
Kurt

Re: API calls

[Wolfgang]

> man socket
> man bind
> man sendto
> man recv

I've forgotten those, thanks.

 
#include <sys/ioctl.h>
#include <net/if.h>
#include <string.h>
#include <linux/can/j1939.h>
#include <linux/can.h>
#include <unistd.h>
#include <sys/socket.h>
#include <stdio.h>



int main (void)
{
	int s;
	s = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
	    
	struct sockaddr_can addr;

    memset(&addr, 0, sizeof(addr));
    addr.can_ifindex = if_nametoindex("can0");
    
    addr.can_addr.j1939.name = J1939_NO_NAME;
    addr.can_addr.j1939.addr = 0x80;
    addr.can_addr.j1939.pgn = 0x12300;
              
       
    if (bind(s, (void *)&addr, sizeof(addr))<0)
    {
    perror ("bind failed");
    }

    
    if (send(s, data, sizeof(data), 0) < 0)
    {
    perror ("send failed");
    }
    
return 0;
}

I changed the program, but I am wondering how to send an entire j1939 frame with
the data?

--Wolfgang

Re: API calls

[Kurt Van Dijck]

On Tue, Dec 20, 2011 at 02:49:43PM +0000, Wolfgang wrote:
> 
> I changed the program, but I am wondering how to send an entire j1939 frame with
> the data?

send(s, data, sizeof(data), 0) does send. But I see 'data' not defined?

I'm afraid I don't really understand the question this time ...
Can you explain a bit more?

Kurt

Re: API calls

[Wolfgang]

I was a bit hasty. It is not working, but I don't get it. Eclipse is saying 
bind failed: Invalid argument
send failed: Destination address required

How is a frame send with id and data, like when you do $cansend can0 
-ei0x123ff80 0xFF. Because only data is sent now?


#include <sys/ioctl.h>
#include <net/if.h>
#include <string.h>
#include <linux/can/j1939.h>
#include <linux/can.h>
#include <unistd.h>
#include <sys/socket.h>
#include <stdio.h>



int main (void)
{
	int s;
	s = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
	    
	struct sockaddr_can addr;

    memset(&addr, 0, sizeof(addr));
    addr.can_ifindex = if_nametoindex("can0");
    
    addr.can_addr.j1939.name = J1939_NO_NAME;
    addr.can_addr.j1939.addr = 0x80;
    addr.can_addr.j1939.pgn = 0x12300;
      
   
   struct can_frame frame;
   frame.data[1] = 0xFF;   
   
       
      
    if (bind(s, (void *)&addr, sizeof(addr))<0)
    {
    perror ("bind failed");
    }
    
    
   if (send(s, frame.data, sizeof(frame.data), 0) < 0)
   {
   perror ("send failed");
   }
    
return 0;
}

Re: API calls

[Kurt Van Dijck]

On Tue, Dec 20, 2011 at 03:43:13PM +0000, Wolfgang wrote:
> I was a bit hasty. It is not working, but I don't get it. Eclipse is saying 
> bind failed: Invalid argument
I went into the code. I forgot to add:
     addr.can_family = AF_CAN;
I think this is what is missing.

> send failed: Destination address required
Yep, since bind failed, you will not be able to use the socket already (man socket).

I just pushed a commit into linux-can-j1939. You may decide to merge it into
your kernel. I found that the test for 'bind succeeded' is wrong in sendmsg.
Therefore, you get some error because you really did not bind yet, but
after the patch, you will get the error ENOTCONN, which is very appropriate.
> 
> How is a frame send with id and data, like when you do $cansend can0 
> -ei0x123ff80 0xFF. Because only data is sent now?

The ID is composed from the address information you supplied earlier
with bind(), connect() and/or sendto().
This is different with CAN raw, but remind that CAN raw does not imply addressing
on the bus neither. 

can-j1939 does export an address concept to userspace, and verifies that
you're not cheating on the bus. And the modules thus allow to
do transport protocol with addressing verified.

So, to summarize, you may later on start using sendto(), and supply
an address structure with destination address and/or PGN set.

Kurt

Re: API calls

[Wolfgang]

#include <sys/ioctl.h>
#include <net/if.h>
#include <string.h>
#include <linux/can/j1939.h>
#include <linux/can.h>
#include <unistd.h>
#include <sys/socket.h>
#include <stdio.h>


int main (void)
{
	int s;
	s = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
	    
	struct sockaddr_can addr;

    memset(&addr, 0, sizeof(addr));
    addr.can_ifindex = if_nametoindex("can0");
    
    addr.can_addr.j1939.name = J1939_NO_NAME;
    addr.can_addr.j1939.addr = 0x80;
    addr.can_addr.j1939.pgn = 0xFFD0;
    addr.can_family = AF_CAN;  
   
	struct can_frame frame;
	   
      
    if (bind(s, (void *)&addr, sizeof(addr))<0)
    {
    perror ("bind failed");
    }
      		
	  if (send(s, frame.data, sizeof(frame.data), 0)<0)
   		{
  		 perror ("send failed");
  		 }
   
return 0;
}

It is working, the ID is composed 18FFD080, thanks. I also tried recv() - it is 
working as well. 
Is it possible to implement only the bytes you really need from the data array,
because the dlc is always 8.
So sendto() is used to send to a specific address, at the moment I am always
doing broadcast?

--Wolfgang

using can-j1939

[Kurt Van Dijck]

On Wed, Dec 21, 2011 at 10:46:44AM +0000, Wolfgang wrote:
> 
> It is working, the ID is composed 18FFD080, thanks. I also tried recv() - it is 
> working as well. 
Great!!

> Is it possible to implement only the bytes you really need from the data array,
> because the dlc is always 8.
I bet len (= sizeof(frame.data) in your example) is 8.
If you want to send 3 bytes, then supply 3 bytes to the kernel!
> So sendto() is used to send to a specific address, at the moment I am always
> doing broadcast?
yes.
> 
> --Wolfgang
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: using can-j1939

[Wolfgang]

> I bet len (= sizeof(frame.data) in your example) is 8.
> If you want to send 3 bytes, then supply 3 bytes to the kernel!
OK, so I set the unused bytes 0 and don't care.


> > So sendto() is used to send to a specific address, at the moment I am always
> > doing broadcast?
> yes.
Maybe you can give me a hint what I did wrong
...
addr.can_addr.j1939.name = 0x81;
....
if (sendto(s, frame.data, strlen(frame.data), 0, (void *)&addr, \
sizeof(frame.data))<0)
    {
    	perror ("sendto failed");
    }


One general question, am I right, you have to create for every different
struct sockaddr_can (different pgn etc.) one socket per 
interface?

Gratefully,
Wolfgang

Re: using can-j1939

[Kurt Van Dijck]

On Wed, Dec 21, 2011 at 03:11:30PM +0000, Wolfgang wrote:
> > I bet len (= sizeof(frame.data) in your example) is 8.
> > If you want to send 3 bytes, then supply 3 bytes to the kernel!
> OK, so I set the unused bytes 0 and don't care.
you should not have unused bytes, but I believe you get the picture...
> 
> 
> > > So sendto() is used to send to a specific address, at the moment I am always
> > > doing broadcast?
> > yes.
> Maybe you can give me a hint what I did wrong
> ...
> addr.can_addr.j1939.name = 0x81;
> ....
> if (sendto(s, frame.data, strlen(frame.data), 0, (void *)&addr, \
> sizeof(frame.data))<0)
sendto(s, frame.data, strlen(frame.data), 0, (void *)&addr, sizeof(addr)/*!!!*/)
you supplied the sizeof frame.data, where you should supply the size of addr.

>     {
>     	perror ("sendto failed");
>     }
> 
> 
> One general question, am I right, you have to create for every different
> struct sockaddr_can (different pgn etc.) one socket per 
> interface?
You will want to create 1 socket per interface and per used source address.

You bind with can_addr.j1939.addr = 0x80 and can_addr.j1939.pgn = J1939_NO_PGN
then you can do sendto with dest_addr.j1939.sa = DEST address &
dest_addr.j1939.pgn = YOUR_PGN.

So, the latter YOUR_PGN may vary with each call.
The option to preset a PGN during bind() allows to use write & send on the socket
but is an inferior option in this regard.

Kurt

Re: using can-j1939

[Wolfgang]

> You will want to create 1 socket per interface and per used source address.

OK, 2 source address, 2 interfaces = 4 sockets?!
 
> You bind with can_addr.j1939.addr = 0x80 and can_addr.j1939.pgn = J1939_NO_PGN
> then you can do sendto with dest_addr.j1939.sa = DEST address &
> dest_addr.j1939.pgn = YOUR_PGN.

#include <sys/ioctl.h>
#include <net/if.h>
#include <string.h>
#include <linux/can/j1939.h>
#include <linux/can.h>
#include <unistd.h>
#include <sys/socket.h>
#include <stdio.h>
#include <sys/types.h>


int main (void)
{
	int s;
	s = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
	    
	struct sockaddr_can addr;

    memset(&addr, 0, sizeof(addr));
    addr.can_ifindex = if_nametoindex("can0");
    addr.can_addr.j1939.name = J1939_NO_NAME;    
    addr.can_addr.j1939.addr = 0x80;
    addr.can_addr.j1939.pgn = J1939_NO_PGN;
    addr.can_family = AF_CAN;  
   
   
    if (bind(s, (void *)&addr, sizeof(addr))<0)
    	{
    		perror ("bind failed");
        	}     	
   
  		struct sockaddr_can dest_addr;
  		
  		memset(&dest_addr, 0, sizeof(dest_addr));
		dest_addr.can_addr.j1939.name = 0x9ABCDEFULL;
    	        dest_addr.can_addr.j1939.pgn = 0x12300;

	
	if (sendto(s, frame.data, sizeof (frame.data), 0, (void *)&dest_addr, \
sizeof(dest_addr))<0)
		{
			perror ("sendto failed");
		       }
  		 
 return 0;
}

I hope I get that right, with the new struct sockaddr_can. But anything is wrong
$sendto failed: Invalid argument. Sure I got the solution?!?


Thanks,
--Wolfgang

Re: using can-j1939

[Kurt Van Dijck]

On Thu, Dec 22, 2011 at 01:06:06PM +0000, Wolfgang wrote:
> > You will want to create 1 socket per interface and per used source address.
> 
> OK, 2 source address, 2 interfaces = 4 sockets?!
I assume you utilize 2 source addresses, one on each interface? In that case, you
need only 2 sockets.
>  
> > You bind with can_addr.j1939.addr = 0x80 and can_addr.j1939.pgn = J1939_NO_PGN
> > then you can do sendto with dest_addr.j1939.sa = DEST address &
> > dest_addr.j1939.pgn = YOUR_PGN.
> 
> #include <sys/ioctl.h>
> #include <net/if.h>
> #include <string.h>
> #include <linux/can/j1939.h>
> #include <linux/can.h>
> #include <unistd.h>
> #include <sys/socket.h>
> #include <stdio.h>
> #include <sys/types.h>
> 
> 
> int main (void)
> {
> 	int s;
> 	s = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
> 	    
> 	struct sockaddr_can addr;
> 
>     memset(&addr, 0, sizeof(addr));
>     addr.can_ifindex = if_nametoindex("can0");
>     addr.can_addr.j1939.name = J1939_NO_NAME;    
>     addr.can_addr.j1939.addr = 0x80;
>     addr.can_addr.j1939.pgn = J1939_NO_PGN;
>     addr.can_family = AF_CAN;  
>    
>    
>     if (bind(s, (void *)&addr, sizeof(addr))<0)
>     	{
>     		perror ("bind failed");
>         	}     	
>    
>   		struct sockaddr_can dest_addr;
>   		
>   		memset(&dest_addr, 0, sizeof(dest_addr));
please set the can_family type, to avoid EINVAL
		dest_addr.can_family = AF_CAN;  
Since I suppose you do not use dynamic address claiming, do:
		dest_addr.can_addr.j1939.name = J1939_NO_NAME;
for broadcasted messages:
		dest_addr.can_addr.j1939.addr = J1939_NO_ADDR;
for destination specific messages, set .addr to the destination address.

> 		dest_addr.can_addr.j1939.name = 0x9ABCDEFULL;
>     	        dest_addr.can_addr.j1939.pgn = 0x12300;
> 
> 	
> 	if (sendto(s, frame.data, sizeof (frame.data), 0, (void *)&dest_addr, \
> sizeof(dest_addr))<0)
> 		{
> 			perror ("sendto failed");
> 		       }
>   		 
>  return 0;
> }
> 
> I hope I get that right, with the new struct sockaddr_can. But anything is wrong
> $sendto failed: Invalid argument. Sure I got the solution?!?
We're getting there ...
Kurt
> 
> 
> Thanks,
> --Wolfgang
> 
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: using can-j1939

[Wolfgang]

Hi,

am I right, if I start for every pgn I want to bridge a new process? Or will it
work if all pgns to be bridged are in one process? I'm just wondering what will
bring a better performance? 

--Wolfgang

Re: using can-j1939

[Kurt Van Dijck]

On Wed, Dec 28, 2011 at 10:49:39AM +0000, Wolfgang wrote:
> Hi,
> 
> am I right, if I start for every pgn I want to bridge a new process? Or will it
> work if all pgns to be bridged are in one process? I'm just wondering what will
> bring a better performance? 
A third option is to start 1 process, with different sockets, each socket bridging 1 pgn.

They all work.
I have no idea what will bring the best performance.
I think your second option will bring:
* the most understandable source code...
* less memory consumption
* less scheduler load
* more transparency (FIFO operation is lost when using different processes)

Kurt
> 
> --Wolfgang
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

recv list

[Wolfgang]

Hi,

OK, I create 1 socket for one source address (what is the maximum of pgns per 
socket?). 
So if I use recvfrom for one specific pgn - while waiting for that specific pgn
the other pgns from that src address are stored in the buffer of the socket and
will be later "recvfrom"? So no can frame will be lost?

Am I right, with this, only the j1939 frame with id<0x19233000> should be
received, but nothing is done, (just waiting for anything), what have I done 
wrong?

#include <sys/ioctl.h>
#include <net/if.h>
#include <string.h>
#include <linux/can/j1939.h>
#include <linux/can.h>
#include <unistd.h>
#include <sys/socket.h>
#include <stdio.h>
#include <sys/types.h>



int main (void)
{
	int s;
	s = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
	    
	struct sockaddr_can addr;

    memset(&addr, 0, sizeof(addr));
    addr.can_ifindex = if_nametoindex("can0");
    addr.can_addr.j1939.name = J1939_NO_NAME;    
    addr.can_addr.j1939.addr = 0x00;
    addr.can_addr.j1939.pgn = J1939_NO_PGN;
    addr.can_family = AF_CAN;  
   
   
    if (bind(s, (void *)&addr, sizeof(addr))<0)
    	{
    		perror ("bind failed");
        	}
   
   
	struct can_frame frame      	
   
   struct sockaddr_can dest_addr;
   
   memset(&dest_addr, 0, sizeof(dest_addr));
   dest_addr.can_family = AF_CAN;
   dest_addr.can_addr.j1939.name = J1939_NO_NAME;
   dest_addr.can_addr.j1939.addr = 0x30;
   dest_addr.can_addr.j1939.pgn = 0x12300;
   
    	if (recvfrom(s, frame.data, sizeof(frame.data), 0, (void *)&dest_addr,\
 sizeof(dest_addr))<0)
		{
  	 	perror ("recvfrom failed");
  	 	}
   		 
  return 0;
}


Wolfgang

Re: recv list

[Kurt Van Dijck]

On Wed, Jan 04, 2012 at 04:28:46PM +0000, Wolfgang wrote:
> Hi,
> 
> OK, I create 1 socket for one source address (what is the maximum of pgns per 
> socket?). 
a bit unlimited, use filters there.
> So if I use recvfrom for one specific pgn - while waiting for that specific pgn
Nope,
man recvfrom ....

can-j1939 will store the source address & PGN into the 'src_addr' (called dest_addr
in your example).
You cannot pick a specific PGN from the incoming queue.

> the other pgns from that src address are stored in the buffer of the socket and
> will be later "recvfrom"? So no can frame will be lost?
> 
> Am I right, with this, only the j1939 frame with id<0x19233000> should be
> received, but nothing is done, (just waiting for anything), what have I done 
> wrong?
> 
> #include <sys/ioctl.h>
> #include <net/if.h>
> #include <string.h>
> #include <linux/can/j1939.h>
> #include <linux/can.h>
> #include <unistd.h>
> #include <sys/socket.h>
> #include <stdio.h>
> #include <sys/types.h>
> 
> 
> 
> int main (void)
> {
> 	int s;
> 	s = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
> 	    
> 	struct sockaddr_can addr;
> 
>     memset(&addr, 0, sizeof(addr));
>     addr.can_ifindex = if_nametoindex("can0");
>     addr.can_addr.j1939.name = J1939_NO_NAME;    
>     addr.can_addr.j1939.addr = 0x00;
>     addr.can_addr.j1939.pgn = J1939_NO_PGN;
>     addr.can_family = AF_CAN;  
>    
>    
>     if (bind(s, (void *)&addr, sizeof(addr))<0)
>     	{
>     		perror ("bind failed");
>         	}
>    
>    
> 	struct can_frame frame      	

you should do now:
	int ret;
	socklen_t len; 
	struct sockaddr_can src_addr;
	char buf[128];

	while (1) {
		len = sizeof(src_addr);
		ret = recvfrom(s, buf, sizeof(buf), 0, (void *)&src_addr, &len);
		if (ret < 0)
			perror ("recvfrom failed");
		/* now, ret contains the received size */ 
		/* do things with data */
		/* set broadcast */
		src_addr.can_addr.j1939.addr = J1939_NO_ADDR;
		src_addr.can_addr.j1939.name = J1939_NO_NAME;
		if (sendto(s2, buf, ret, 0, (void *)&src_addr, len) < 0)
			perror("sendto failed");
	}
>    
>    struct sockaddr_can dest_addr;
>    
>    memset(&dest_addr, 0, sizeof(dest_addr));
>    dest_addr.can_family = AF_CAN;
>    dest_addr.can_addr.j1939.name = J1939_NO_NAME;
>    dest_addr.can_addr.j1939.addr = 0x30;
>    dest_addr.can_addr.j1939.pgn = 0x12300;
>    
>     	if (recvfrom(s, frame.data, sizeof(frame.data), 0, (void *)&dest_addr,\
>  sizeof(dest_addr))<0)
> 		{
>   	 	perror ("recvfrom failed");
>   	 	}
>    		 
>   return 0;
> }
> 
> 
> Wolfgang
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: recv list

[Wolfgang]

OK, I hope I understood it right now, 'recvfrom' returns me more information 
than 'recv', I thought I can filter with it. But I have to do this before with 
struct 'j1939_filter' and 'setsockopt' to choose which frames from the bus are 
cared about.

So if I unterstand it right this should bridge from can0 to can1 and if the 
sender is 0x30 it prints the first data byte?


#include <sys/ioctl.h>
#include <net/if.h>
#include <string.h>
#include <linux/can/j1939.h>
#include <linux/can.h>
#include <unistd.h>
#include <sys/socket.h>
#include <stdio.h>
#include <sys/types.h>


int main (void)
{
	int s;
	s = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
	    
	struct sockaddr_can addr;

    memset(&addr, 0, sizeof(addr));
    addr.can_ifindex = if_nametoindex("can0");
    addr.can_addr.j1939.name = J1939_NO_NAME;    
    addr.can_addr.j1939.addr = 0x00;
    addr.can_addr.j1939.pgn = J1939_NO_PGN;
    addr.can_family = AF_CAN;  
   
   
    if (bind(s, (void *)&addr, sizeof(addr))<0)
    	{
    		perror ("bind failed");
        	}
        	
     
    int s2;
	s2 = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
	
	struct sockaddr_can addr2;	
	   
    memset(&addr2, 0, sizeof(addr2));
    addr2.can_ifindex = if_nametoindex("can1");
    addr2.can_addr.j1939.name = J1939_NO_NAME;    
    addr2.can_addr.j1939.addr = 0x3D;
    addr2.can_addr.j1939.pgn = J1939_NO_PGN;
    addr2.can_family = AF_CAN;  
   
   
    if (bind(s2, (void *)&addr2, sizeof(addr2))<0)
    	{
    		perror ("bind2 failed");
        	}
        	
    int ret;
	socklen_t len; 
	struct sockaddr_can src_addr;
	char buf[128];
	src_addr.can_family = AF_CAN;


	while (1) {
		len = sizeof(src_addr);
		ret = recvfrom(s, buf, sizeof(buf), 0, (void *)&src_addr, &len);
		
		if (ret < 0)
		perror ("recvfrom failed");

		/*if the frame is sent by 0x30 do this*/
		if (src_addr.can_addr.j1939.addr == 0x30)
		{
			printf("%x\n", buf[0]);
			
			if (sendto(s2, buf, ret, 0, (void *)&src_addr, len) < 0)
				perror("sendto failed");
						
		}
		
		/*else just bridge it*/
		else 
		{
			if (sendto(s2, buf, ret, 0, (void *)&src_addr, len) < 0)
				perror("sendto failed");
		}

	}

  		 
  return 0;
}


Thanks so far!

Re: recv list

[Kurt Van Dijck]

On Thu, Jan 05, 2012 at 10:55:19AM +0000, Wolfgang wrote:
> OK, I hope I understood it right now, 'recvfrom' returns me more information 
> than 'recv', I thought I can filter with it. But I have to do this before with 
> struct 'j1939_filter' and 'setsockopt' to choose which frames from the bus are 
> cared about.
right!
> 
> So if I unterstand it right this should bridge from can0 to can1 and if the 
> sender is 0x30 it prints the first data byte?
pretty good. I did point a few minor remarks.
> 
> 
> #include <sys/ioctl.h>
> #include <net/if.h>
> #include <string.h>
> #include <linux/can/j1939.h>
> #include <linux/can.h>
> #include <unistd.h>
> #include <sys/socket.h>
> #include <stdio.h>
> #include <sys/types.h>
> 
> 
> int main (void)
> {
> 	int s;
> 	s = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
> 	    
> 	struct sockaddr_can addr;
> 
>     memset(&addr, 0, sizeof(addr));
>     addr.can_ifindex = if_nametoindex("can0");
>     addr.can_addr.j1939.name = J1939_NO_NAME;    
>     addr.can_addr.j1939.addr = 0x00;
>     addr.can_addr.j1939.pgn = J1939_NO_PGN;
>     addr.can_family = AF_CAN;  
>    
>    
>     if (bind(s, (void *)&addr, sizeof(addr))<0)
>     	{
>     		perror ("bind failed");
>         	}
>         	
>      
>     int s2;
> 	s2 = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
> 	
> 	struct sockaddr_can addr2;	
> 	   
>     memset(&addr2, 0, sizeof(addr2));
>     addr2.can_ifindex = if_nametoindex("can1");
>     addr2.can_addr.j1939.name = J1939_NO_NAME;    
>     addr2.can_addr.j1939.addr = 0x3D;
>     addr2.can_addr.j1939.pgn = J1939_NO_PGN;
>     addr2.can_family = AF_CAN;  
>    
>    
>     if (bind(s2, (void *)&addr2, sizeof(addr2))<0)
>     	{
>     		perror ("bind2 failed");
>         	}
>         	
>     int ret;
> 	socklen_t len; 
> 	struct sockaddr_can src_addr;
> 	char buf[128];
> 	src_addr.can_family = AF_CAN;
This assignment is useless...
> 
> 
> 	while (1) {
> 		len = sizeof(src_addr);
> 		ret = recvfrom(s, buf, sizeof(buf), 0, (void *)&src_addr, &len);
> 		
> 		if (ret < 0)
> 		perror ("recvfrom failed");
> 
> 		/*if the frame is sent by 0x30 do this*/
> 		if (src_addr.can_addr.j1939.addr == 0x30)
> 		{
you could test if 'ret' > 0, since 'ret' may be 0.
Altough sending frames without data is rare in j1939...
> 			printf("%x\n", buf[0]);
> 			
In this example, the remainder of the 'if' is equal as the 'else' ...
> 			if (sendto(s2, buf, ret, 0, (void *)&src_addr, len) < 0)
> 				perror("sendto failed");
> 						
> 		}
> 		
> 		/*else just bridge it*/
> 		else 
> 		{
> 			if (sendto(s2, buf, ret, 0, (void *)&src_addr, len) < 0)
> 				perror("sendto failed");
> 		}
> 
> 	}
> 
>   		 
>   return 0;
> }
> 
> 
> Thanks so far!

Note that this bridge puts the originating source address as bridged destination address.
This does not matter for PDU2 type of PGN's (== PDU-specific is not the destination address),
it may not be completely right.

I'd expect to 'empty' (== put J1939_NO_ADDR) the src_addr.can_addr.j1939.addr member
before sendto(), resulting in a broadcasted PGN.

In a later iteration, You could (if necessary, since I have no clue what kind of
traffic you will bridge):
* make the receiving socket (s) 'promiscuous', i.e. receiving all traffic.
* fetch the original destination by using recvmsg() as illustrated in jspy.

I think you're bridge will work. great job!

Kurt
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: recv list

[Wolfgang]

> Note that this bridge puts the originating source address as bridged
destination address.
> This does not matter for PDU2 type of PGN's (== PDU-specific is not the 
> destination address), it may not be completely right.
> 
> I'd expect to 'empty' (== put J1939_NO_ADDR) the src_addr.can_addr.j1939.addr 
> member before sendto(), resulting in a broadcasted PGN.

OK I hope I fixed that, I want to keep the originating source address and it 
should stay PDU2 type.

> In a later iteration, You could (if necessary, since I have no clue what kind
> of traffic you will bridge):
> * make the receiving socket (s) 'promiscuous', i.e. receiving all traffic.
> * fetch the original destination by using recvmsg() as illustrated in jspy.

At the moment I am also not aware what particular traffic I will bridge, I am
still 'playing' around. But the target is to place that bridge between an 
existing engine bus and an existing ECU. So different source address' the 
existing ECU is 'interested' in (but I think not in all in the network) and one 
source address from the ECU.

In the example below, I wanted, if the pgn is 0xFEF5 (this is a pgn I will 
definitely need) to print the first byte otherwise just bridge it. 
But it is not working! Could you see an error? Sorry!

int main (void)
{
	int s;
	s = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
	    
	struct sockaddr_can addr;

    memset(&addr, 0, sizeof(addr));
    addr.can_ifindex = if_nametoindex("can0");
    addr.can_addr.j1939.name = J1939_NO_NAME;    
    addr.can_addr.j1939.addr = 0x00;
    addr.can_addr.j1939.pgn = J1939_NO_PGN;
    addr.can_family = AF_CAN;  
   
   
    if (bind(s, (void *)&addr, sizeof(addr))<0)
    	{
    		perror ("bind failed");
        	}
        	
     
    int s2;
	s2 = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
	
	struct sockaddr_can addr2;	
	   
    memset(&addr2, 0, sizeof(addr2));
    addr2.can_ifindex = if_nametoindex("can1");
    addr2.can_addr.j1939.name = J1939_NO_NAME;    
    addr2.can_addr.j1939.addr = 0x3D;
    addr2.can_addr.j1939.pgn = J1939_NO_PGN;
    addr2.can_family = AF_CAN;     
   
    if (bind(s2, (void *)&addr2, sizeof(addr2))<0)
    	{
    		perror ("bind2 failed");
        	}
    int ret;
	socklen_t len; 
	struct sockaddr_can src_addr;
	char buf[128];


	while (1) {
		len = sizeof(src_addr);
		ret = recvfrom(s, buf, sizeof(buf), 0, (void *)&src_addr, &len);
		
		if (ret < 0)
		perror ("recvfrom failed");
		
		src_addr.can_addr.j1939.addr = J1939_NO_ADDR;

		/*if the frame is sent by 0x30 do this*/
		if (src_addr.can_addr.j1939.pgn == 0xFEF5)
		{
			if (ret < 0)
			perror ("no data");
			
			printf("%x\n", buf[0]);
/*I didn't get it what you wanted to tell me with the remainder*/
			
			if (sendto(s2, buf, ret, 0, (void *)&src_addr, len) < 0)
				perror("sendto failed");
						
		}
		
		/*else just bridge it*/
		else
		{ 
			if (sendto(s2, buf, ret, 0, (void *)&src_addr, len) < 0)
				perror("sendto failed");
		}

	}

  		 
  return 0;
}



--Wolfgang

Re: recv list

[Kurt Van Dijck]

On Thu, Jan 05, 2012 at 09:24:25PM +0000, Wolfgang wrote:
> > Note that this bridge puts the originating source address as bridged
> destination address.
> > This does not matter for PDU2 type of PGN's (== PDU-specific is not the 
> > destination address), it may not be completely right.
> > 
> > I'd expect to 'empty' (== put J1939_NO_ADDR) the src_addr.can_addr.j1939.addr 
> > member before sendto(), resulting in a broadcasted PGN.
> 
> OK I hope I fixed that, I want to keep the originating source address and it 
> should stay PDU2 type.
The source address of outgoing packets is the one you gave with bind().

> 
> > In a later iteration, You could (if necessary, since I have no clue what kind
> > of traffic you will bridge):
> > * make the receiving socket (s) 'promiscuous', i.e. receiving all traffic.
> > * fetch the original destination by using recvmsg() as illustrated in jspy.
> 
> At the moment I am also not aware what particular traffic I will bridge, I am
> still 'playing' around. But the target is to place that bridge between an 
> existing engine bus and an existing ECU. So different source address' the 
> existing ECU is 'interested' in (but I think not in all in the network) and one 
> source address from the ECU.
> 
> In the example below, I wanted, if the pgn is 0xFEF5 (this is a pgn I will 
> definitely need) to print the first byte otherwise just bridge it. 
> But it is not working! Could you see an error? Sorry!
strange.
I see 1 problem still: you will need to bind with 0x00 on can1 & with 0x3d on can0
probably. In fact, there's no need yet to bind with a valid source address on can0
since you're listening only.
That does however not explain the problem.

tried 'jspy' yet?
> 
> int main (void)
> {
> 	int s;
> 	s = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
> 	    
> 	struct sockaddr_can addr;
> 
>     memset(&addr, 0, sizeof(addr));
>     addr.can_ifindex = if_nametoindex("can0");
>     addr.can_addr.j1939.name = J1939_NO_NAME;    
>     addr.can_addr.j1939.addr = 0x00;
>     addr.can_addr.j1939.pgn = J1939_NO_PGN;
>     addr.can_family = AF_CAN;  
>    
>    
>     if (bind(s, (void *)&addr, sizeof(addr))<0)
>     	{
>     		perror ("bind failed");
>         	}
>         	
>      
>     int s2;
> 	s2 = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
> 	
> 	struct sockaddr_can addr2;	
> 	   
>     memset(&addr2, 0, sizeof(addr2));
>     addr2.can_ifindex = if_nametoindex("can1");
>     addr2.can_addr.j1939.name = J1939_NO_NAME;    
>     addr2.can_addr.j1939.addr = 0x3D;
>     addr2.can_addr.j1939.pgn = J1939_NO_PGN;
>     addr2.can_family = AF_CAN;     
>    
>     if (bind(s2, (void *)&addr2, sizeof(addr2))<0)
>     	{
>     		perror ("bind2 failed");
>         	}
>     int ret;
> 	socklen_t len; 
> 	struct sockaddr_can src_addr;
> 	char buf[128];
> 
> 
> 	while (1) {
> 		len = sizeof(src_addr);
> 		ret = recvfrom(s, buf, sizeof(buf), 0, (void *)&src_addr, &len);
> 		
> 		if (ret < 0)
> 		perror ("recvfrom failed");
> 		
> 		src_addr.can_addr.j1939.addr = J1939_NO_ADDR;
> 
> 		/*if the frame is sent by 0x30 do this*/
> 		if (src_addr.can_addr.j1939.pgn == 0xFEF5)
> 		{
> 			if (ret < 0)
> 			perror ("no data");
> 			
> 			printf("%x\n", buf[0]);
> /*I didn't get it what you wanted to tell me with the remainder*/
> 			
> 			if (sendto(s2, buf, ret, 0, (void *)&src_addr, len) < 0)
> 				perror("sendto failed");
> 						
> 		}
> 		
> 		/*else just bridge it*/
> 		else
> 		{ 
> 			if (sendto(s2, buf, ret, 0, (void *)&src_addr, len) < 0)
> 				perror("sendto failed");
> 		}
> 
> 	}
> 
>   		 
>   return 0;
> }
> 
> 
> 
> --Wolfgang
> 
> 
> 
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: recv list

[Wolfgang]

> tried 'jspy' yet?

It is not possible because at the moment I am working with a simulation tool,
to get out how things are working, is this a problem?

Now I have a different question, is it possible to bind different sockets with
different src.addr to one interface. Because it is saying 'bind failed: Device 
or resource busy' if I want to do this ('$ip addr add j1939 0x01 dev can0' is 
working, of course) Or do I have to do this with recvmsg()? 
Because as you know I want keep the various src address'.

Kind regards,
Wolfgang

Re: recv list

[Kurt Van Dijck]

On Fri, Jan 06, 2012 at 06:25:59PM +0000, Wolfgang wrote:
> 
> Now I have a different question, is it possible to bind different sockets with
> different src.addr to one interface.
of course, yes.
> Because it is saying 'bind failed: Device 
> or resource busy' if I want to do this ('$ip addr add j1939 0x01 dev can0' is 
> working, of course)
It should work. Since '$ ip addr add ...' worked, there must be something in the code.
I look in the code for this. Did I understand well that only the first bind() succeeds?
> Or do I have to do this with recvmsg()? 
no, wrong idea.
> Because as you know I want keep the various src address'.
I understand your goal...
> 
> Kind regards,
> Wolfgang
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Changing addr with bind()

[Kurt Van Dijck]

On Mon, Jan 09, 2012 at 10:33:18AM +0100, Kurt Van Dijck wrote:
> On Fri, Jan 06, 2012 at 06:25:59PM +0000, Wolfgang wrote:
> > 
> > Now I have a different question, is it possible to bind different sockets with
> > different src.addr to one interface.
> of course, yes.
> > Because it is saying 'bind failed: Device 
> > or resource busy' if I want to do this ('$ip addr add j1939 0x01 dev can0' is 
> > working, of course)
> It should work. Since '$ ip addr add ...' worked, there must be something in the code.
> I look in the code for this. Did I understand well that only the first bind() succeeds?

Stop searching. It's explicitely disabled in can-j1939 kernel code, and I remember
it was not easy to fix in the first versions, but things have changed since.
I'll try to make a fix...

Kurt

Re: Changing addr with bind()

[Kurt Van Dijck]

On Mon, Jan 09, 2012 at 11:02:10AM +0100, Kurt Van Dijck wrote:
> On Mon, Jan 09, 2012 at 10:33:18AM +0100, Kurt Van Dijck wrote:
> > On Fri, Jan 06, 2012 at 06:25:59PM +0000, Wolfgang wrote:
> > > 
> > > Now I have a different question, is it possible to bind different sockets with
> > > different src.addr to one interface.
> > of course, yes.
> > > Because it is saying 'bind failed: Device 
> > > or resource busy' if I want to do this ('$ip addr add j1939 0x01 dev can0' is 
> > > working, of course)
> > It should work. Since '$ ip addr add ...' worked, there must be something in the code.
> > I look in the code for this. Did I understand well that only the first bind() succeeds?
> 
> Stop searching. It's explicitely disabled in can-j1939 kernel code, and I remember
> it was not easy to fix in the first versions, but things have changed since.
> I'll try to make a fix...
I pushed 2 commits to can-j1939-modules repository. You may want to upgrade your sources.
Please note I had no time to test these.

Kurt

Re: recv list

[Wolfgang]

Hi,

now it is saying 'sendto failed: Machine is not on the network', when I am 
sending a message with id 0x15FFD000

#include <sys/ioctl.h>
#include <net/if.h>
#include <string.h>
#include <linux/can/j1939.h>
#include <linux/can.h>
#include <unistd.h>
#include <sys/socket.h>
#include <stdio.h>
#include <sys/types.h>



int main (void)
{
	int s;
	s = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
	    
	struct sockaddr_can addr;

    memset(&addr, 0, sizeof(addr));
    addr.can_ifindex = if_nametoindex("can0");
    addr.can_addr.j1939.name = J1939_NO_NAME;    
    addr.can_addr.j1939.addr = 0x00;
    addr.can_addr.j1939.pgn = J1939_NO_PGN;
    addr.can_family = AF_CAN;  
   
   
    if (bind(s, (void *)&addr, sizeof(addr))<0)
    	   		perror ("bind failed");
    	   	else
        		printf("bind of s1 on can0 successful\n");
        	       	
       	
     
    int s2;
	s2 = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
	
	struct sockaddr_can addr2;	
	   
    memset(&addr2, 0, sizeof(addr2));
    addr2.can_ifindex = if_nametoindex("can1");
    addr2.can_addr.j1939.name = J1939_NO_NAME;    
    addr2.can_addr.j1939.addr = 0x3d;
    addr2.can_addr.j1939.pgn = J1939_NO_PGN;
    addr2.can_family = AF_CAN;     
   
    if (bind(s2, (void *)&addr2, sizeof(addr2))<0)
    	   		perror ("bind2 failed");
        	else
        		printf("bind of s2 on can1 successful\n");
        	
    int ret;
	socklen_t len; 
	struct sockaddr_can src_addr;
	char buf[128];


	while (1) {
		len = sizeof(src_addr);
		ret = recvfrom(s, buf, sizeof(buf), 0, (void *)&src_addr, &len);
		
		
		if (ret < 0)
		perror ("recvfrom failed");
		
		src_addr.can_addr.j1939.addr = J1939_NO_ADDR;

		
			if (sendto(s2, buf, ret, 0, (void *)&src_addr, len) < 0)
				perror("sendto failed");
						
	}

  		 
  return 0;
}

Re: using can-j1939

[Oliver Hartkopp]

On 01.12.2011 12:52, Kurt Van Dijck wrote:

> On Thu, Dec 01, 2011 at 11:54:34AM +0100, Wolfgang Wagner wrote:
>> Hi,
>>
>> thank you very much for your fast response. Glad that you will help me.
>>
>> I want to run the can-j1939 for linux on a Phytec phycore MPC5121e with kernel release 2.6.33.5-rt2x-ptx-pcm046-3.
> I'm not that much used with specific drivers & releases. I included linux-can
> mailing list, maybe they can help to use out-of-tree CAN modules on your system.
>>
>> I managed to download the 3 thing you told me, but now I don't know to move on - I am really desperated because I can't find any proper documentation.
> Did you read Documentation/networking/can/j1939.txt from the can-j1939-modules?
> 
> The Documentation is a currently a weak point. I've had some busy months,
> and j1939 dissappeared from my priorities since our system is working
> properly.
> 
> Oliver Hartkopp has already proposed to work out some use-cases, but as said,
> I've not found time for that yet.
> Maybe this is a good opportunity to do so...


Yeah. Some things continuously pop up after some time :-)

@Wolfgang W.: We had a quite interesting and long discussion about Kurts
suggested implementation. Especially on how to deal with address claiming.
Currently the AUTOSAR J1939 specifications nearly ignore the AC which provides
the possibility of having a simple PDU interface.
But if we want to do AC the discussion comes up how much of it we put into the
kernel-space and how much we do in user-space (e.g. with an AC daemon).

I think Kurt also asked you about your planned setup. Is address claiming also
part of it?

Regards,
Oliver

Re: using can-j1939

[Kurt Van Dijck]

Wolfgang,

> Did you read Documentation/networking/can/j1939.txt from the can-j1939-modules?
In order to not overload you too much, can you (high-level) describe what
you're about to do?
* using dynamic address claiming vs. static addresses
* writing own programs vs. using some predefined cansend/candump.
* sending & receiving vs. receive only.
....

Kind regards,
Kurt Van Dijck

using can-j1939

[Kurt Van Dijck]

On Thu, Dec 01, 2011 at 11:54:34AM +0100, Wolfgang Wagner wrote:
> Hi,
> 
> thank you very much for your fast response. Glad that you will help me.
> 
> I want to run the can-j1939 for linux on a Phytec phycore MPC5121e with kernel release 2.6.33.5-rt2x-ptx-pcm046-3.
I'm not that much used with specific drivers & releases. I included linux-can
mailing list, maybe they can help to use out-of-tree CAN modules on your system.
> 
> I managed to download the 3 thing you told me, but now I don't know to move on - I am really desperated because I can't find any proper documentation.
Did you read Documentation/networking/can/j1939.txt from the can-j1939-modules?

The Documentation is a currently a weak point. I've had some busy months,
and j1939 dissappeared from my priorities since our system is working
properly.

Oliver Hartkopp has already proposed to work out some use-cases, but as said,
I've not found time for that yet.
Maybe this is a good opportunity to do so...

Kurt Van Dijck
> 
> I would be really pleased about your help!
> 
> Kind regards,
> 
> Wolfgang Wagner
> 
> 
> 
> -------- Original-Nachricht --------
> Datum: Thu, 1 Dec 2011 10:07:03 +0100
> Von: Gitorious <no-reply@gitorious.org>
> An: wutz@unterderbruecke.de
> Betreff: New message: Re: j1939
> 
> 
> 
> Hello wutzol
> 
> Kurt Van Dijck has sent you a message on Gitorious:
> ----------------------------------------------------
> 
> Hi,
> 
> Thanks for your interest in can-j1939 for linux.
> In order to use our can-j1939 for linux, you will need 3 things:
> * can-j1939 kernel stack on https://gitorious.org/~kurt-vd/linux-can/can-j1939-modules
>   I've had a patchset to patch the net-next-2.6 linux branch, but it is a bit outdated.
> * can-j1939 utilities on https://gitorious.org/~kurt-vd/linux-can/can-j1939-utils
>   This branch of can-utils contains some additional j1939 specific programs
> * iproute2-j1939 on https://gitorious.org/~kurt-vd/linux-can/iproute2-j1939
>   This replaces iproute2, and adds j1939 specific commands:
>   * turn j1939 on for a specific can device
>   * manage j1939 addressing info for a can device
> 
> Since linux-can moved to gitorious only recently, I'm not sure all my repositories are already up to date. I will check that.
> 
> In the kernel modules, a Documentation/networking/j1939.txt (or similar) is provided.
> I'll be interested in helping you using the j1939 stack. Therefore, you may
> participate in linux-can@vger.kernel.org (linux-can mailing list) or email me directly
> (you'll find my email in the git repositories).
> 
> Kind regards,
> Kurt Van Dijck
> 
> 
> ----------------------------------------------------
> View and reply to this message at https://gitorious.org/messages/118259
> 
> PLEASE DO NOT reply to this email directly as it will go
> nowhere. Instead, use the above link to reply.
> 
> -- 
> NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
> Jetzt informieren: http://www.gmx.net/de/go/freephone