J1939 message length

J1939 message length

[pascal]

Hi,

I've installed the patch for using j1939 socket CAN under linux 
(beagleBone black).

It works fine for receiving j1939 message and sending short message (8 
bytes max).

But when I try to send long message (>8 bytes long), but the message has 
not been sent.

I use the sendTo method to send frame.

Do I have to do something special to send long message?

I'm working with a 3.8.13 kernel on beaglebone black.

Thanks a lot

Pascal

Re: J1939 message length

[Kurt Van Dijck]

Hey Pascal,

On Thu, Dec 11, 2014 at 10:44:39AM +0000, pascal wrote:
> Hi,
> 
> I've installed the patch for using j1939 socket CAN under linux 
> (beagleBone black).
> 
> It works fine for receiving j1939 message and sending short message (8 
> bytes max).
> 
> But when I try to send long message (>8 bytes long), but the message has 
> not been sent.

Ok.
You provide little info how you detect that <=8 bytes work, and >8 bytes do not work.

What do you see on the (raw) CAN bus?

Are you aware of the Transport Protocol on J1939 that delivers messages >8 bytes?

Kurt
> 
> I use the sendTo method to send frame.
> 
> Do I have to do something special to send long message?

no, not necessarily.

> I'm working with a 3.8.13 kernel on beaglebone black.

Kind regards,
Kurt

RE: J1939 message length

[pfifre.ext]

Hi Kurt,

I resolved the issue. The problem appears with long message because, according to the j1939 specifications, the end of message has to be fulfilled with 0xFF if the message is not modulo 8.
Apparently, the j1939  drivers don't make the padding with 0xFF.
Then I do that in my software and it works fine know.

Perhaps, It will be a good idea to add this in the drivers.

Best regards,

Pascal

-----Message d'origine-----
De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be] 
Envoyé : vendredi 12 décembre 2014 12:08
À : zze-Open the box FIFRE P ext IMT/OLPS
Cc : linux-can@vger.kernel.org
Objet : Re: J1939 message length

Hey Pascal,

On Thu, Dec 11, 2014 at 10:44:39AM +0000, pascal wrote:
> Hi,
> 
> I've installed the patch for using j1939 socket CAN under linux 
> (beagleBone black).
> 
> It works fine for receiving j1939 message and sending short message (8 
> bytes max).
> 
> But when I try to send long message (>8 bytes long), but the message 
> has not been sent.

Ok.
You provide little info how you detect that <=8 bytes work, and >8 bytes do not work.

What do you see on the (raw) CAN bus?

Are you aware of the Transport Protocol on J1939 that delivers messages >8 bytes?

Kurt
> 
> I use the sendTo method to send frame.
> 
> Do I have to do something special to send long message?

no, not necessarily.

> I'm working with a 3.8.13 kernel on beaglebone black.

Kind regards,
Kurt

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Re: J1939 message length

[Kurt Van Dijck]

Hey,

On Mon, Dec 15, 2014 at 08:58:14AM +0000, pfifre.ext@orange.com wrote:
> Hi Kurt,
> 
> I resolved the issue. The problem appears with long message because, according to the j1939 specifications, the end of message has to be fulfilled with 0xFF if the message is not modulo 8.
> Apparently, the j1939  drivers don't make the padding with 0xFF.

You're not the first to find an actual ECU complaining on this.
I assembled a patch earlier this year, see http://lists.kde.org/?l=linux-can&m=139825572207448&w=2

> Then I do that in my software and it works fine know.

I advise to apply that patch, and avoid to calculate packet sizes in userspace.

Which is the remote ECU that does not accept the packets?

> 
> Perhaps, It will be a good idea to add this in the drivers.

Yep, I'll do.

Kind regards,
Kurt
> 
> Best regards,
> 
> Pascal
> 
> -----Message d'origine-----
> De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be] 
> Envoyé : vendredi 12 décembre 2014 12:08
> À : zze-Open the box FIFRE P ext IMT/OLPS
> Cc : linux-can@vger.kernel.org
> Objet : Re: J1939 message length
> 
> Hey Pascal,
> 
> On Thu, Dec 11, 2014 at 10:44:39AM +0000, pascal wrote:
> > Hi,
> > 
> > I've installed the patch for using j1939 socket CAN under linux 
> > (beagleBone black).
> > 
> > It works fine for receiving j1939 message and sending short message (8 
> > bytes max).
> > 
> > But when I try to send long message (>8 bytes long), but the message 
> > has not been sent.
> 
> Ok.
> You provide little info how you detect that <=8 bytes work, and >8 bytes do not work.
> 
> What do you see on the (raw) CAN bus?
> 
> Are you aware of the Transport Protocol on J1939 that delivers messages >8 bytes?
> 
> Kurt
> > 
> > I use the sendTo method to send frame.
> > 
> > Do I have to do something special to send long message?
> 
> no, not necessarily.
> 
> > I'm working with a 3.8.13 kernel on beaglebone black.
> 
> Kind regards,
> Kurt
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 

RE: J1939 message length

[pfifre.ext]

Hi Kurt,

Thanks a lot for your answer.
The remote (not an ECU) is a software from AEF which is use to discover the ISO 11783 ECU on the CAN bus.

Best regards,

Pascal

-----Message d'origine-----
De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be] 
Envoyé : lundi 15 décembre 2014 10:32
À : zze-Open the box FIFRE P ext IMT/OLPS
Cc : linux-can@vger.kernel.org
Objet : Re: J1939 message length

Hey,

On Mon, Dec 15, 2014 at 08:58:14AM +0000, pfifre.ext@orange.com wrote:
> Hi Kurt,
> 
> I resolved the issue. The problem appears with long message because, according to the j1939 specifications, the end of message has to be fulfilled with 0xFF if the message is not modulo 8.
> Apparently, the j1939  drivers don't make the padding with 0xFF.

You're not the first to find an actual ECU complaining on this.
I assembled a patch earlier this year, see http://lists.kde.org/?l=linux-can&m=139825572207448&w=2

> Then I do that in my software and it works fine know.

I advise to apply that patch, and avoid to calculate packet sizes in userspace.

Which is the remote ECU that does not accept the packets?

> 
> Perhaps, It will be a good idea to add this in the drivers.

Yep, I'll do.

Kind regards,
Kurt
> 
> Best regards,
> 
> Pascal
> 
> -----Message d'origine-----
> De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be]
> Envoyé : vendredi 12 décembre 2014 12:08 À : zze-Open the box FIFRE P 
> ext IMT/OLPS Cc : linux-can@vger.kernel.org Objet : Re: J1939 message 
> length
> 
> Hey Pascal,
> 
> On Thu, Dec 11, 2014 at 10:44:39AM +0000, pascal wrote:
> > Hi,
> > 
> > I've installed the patch for using j1939 socket CAN under linux 
> > (beagleBone black).
> > 
> > It works fine for receiving j1939 message and sending short message 
> > (8 bytes max).
> > 
> > But when I try to send long message (>8 bytes long), but the message 
> > has not been sent.
> 
> Ok.
> You provide little info how you detect that <=8 bytes work, and >8 bytes do not work.
> 
> What do you see on the (raw) CAN bus?
> 
> Are you aware of the Transport Protocol on J1939 that delivers messages >8 bytes?
> 
> Kurt
> > 
> > I use the sendTo method to send frame.
> > 
> > Do I have to do something special to send long message?
> 
> no, not necessarily.
> 
> > I'm working with a 3.8.13 kernel on beaglebone black.
> 
> Kind regards,
> Kurt
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Re: J1939 message length

[Laurent Vaudoit]

Kurt Van Dijck <dev.kurt <at> vandijck-laurijssen.be> writes:

Hi Kurt,
> 
> Hey,
> 
> On Mon, Dec 15, 2014 at 08:58:14AM +0000, pfifre.ext <at> orange.com 
wrote:
> > Hi Kurt,
> > 
> > I resolved the issue. The problem appears with long message because, 
according to the j1939
> specifications, the end of message has to be fulfilled with 0xFF if the 
message is not modulo 8.
> > Apparently, the j1939  drivers don't make the padding with 0xFF.
> 
> You're not the first to find an actual ECU complaining on this.
> I assembled a patch earlier this year, see http://lists.kde.org/?l=linux-
can&m=139825572207448&w=2
> 
> > Then I do that in my software and it works fine know.
> 
> I advise to apply that patch, and avoid to calculate packet sizes in 
userspace.

I've seen this message concerning a bug in the DLC can frame when a more 
than 8 bytes J1939 frame is sent.

Looking at the patch, it seems that every j1939 frame will be padded with 
0xFF, even single frame (less than 8 bytes).
I think this is an error as standard SAEJ1939-21 specifies that for example 
PGN request (0xEA00) is 3 byes length, and so can frame dlc must be 3 set 
to 3.

May be the patch should be move on the transport module who manage Data 
transfer protocol?
Is there something i missed?
> 
> Which is the remote ECU that does not accept the packets?
> 
> > 
> > Perhaps, It will be a good idea to add this in the drivers.
> 
> Yep, I'll do.
> 

Best regards,
Laurent
> Kind regards,
> Kurt
> > 
> > Best regards,
> > 
> > Pascal
> > 
> > -----Message d'origine-----
> > De : Kurt Van Dijck [mailto:dev.kurt <at> vandijck-laurijssen.be] 
> > Envoyé : vendredi 12 décembre 2014 12:08
> > À : zze-Open the box FIFRE P ext IMT/OLPS
> > Cc : linux-can <at> vger.kernel.org
> > Objet : Re: J1939 message length
> > 
> > Hey Pascal,
> > 
> > On Thu, Dec 11, 2014 at 10:44:39AM +0000, pascal wrote:
> > > Hi,
> > > 
> > > I've installed the patch for using j1939 socket CAN under linux 
> > > (beagleBone black).
> > > 
> > > It works fine for receiving j1939 message and sending short message 
(8 
> > > bytes max).
> > > 
> > > But when I try to send long message (>8 bytes long), but the message 
> > > has not been sent.
> > 
> > Ok.
> > You provide little info how you detect that <=8 bytes work, and >8 
bytes do not work.
> > 
> > What do you see on the (raw) CAN bus?
> > 
> > Are you aware of the Transport Protocol on J1939 that delivers messages 
>8 bytes?
> > 
> > Kurt
> > > 
> > > I use the sendTo method to send frame.
> > > 
> > > Do I have to do something special to send long message?
> > 
> > no, not necessarily.
> > 
> > > I'm working with a 3.8.13 kernel on beaglebone black.
> > 
> > Kind regards,
> > Kurt
> > 
> > 
___________________________________________________________________________
______________________________________________
> > 
> > Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et
> ne doivent donc
> > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
recu ce message par erreur,
> veuillez le signaler
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les 
messages electroniques etant
> susceptibles d'alteration,
> > Orange decline toute responsabilite si ce message a ete altere, deforme 
ou falsifie. Merci.
> > 
> > This message and its attachments may contain confidential or privileged 
information that may be
> protected by law;
> > they should not be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender and 
delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have 
been modified, changed or falsified.
> > Thank you.
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: J1939 message length

[Kurt Van Dijck]

Hey Laurent,

> Hi Kurt,
> > 
> > Hey,
> > 
> > On Mon, Dec 15, 2014 at 08:58:14AM +0000, pfifre.ext <at> orange.com 
> wrote:
> > > Hi Kurt,
> > > 
> > > I resolved the issue. The problem appears with long message because, 
> according to the j1939
> > specifications, the end of message has to be fulfilled with 0xFF if the 
> message is not modulo 8.
> > > Apparently, the j1939  drivers don't make the padding with 0xFF.
> > 
> > You're not the first to find an actual ECU complaining on this.
> > I assembled a patch earlier this year, see http://lists.kde.org/?l=linux-
> can&m=139825572207448&w=2
> > 
> > > Then I do that in my software and it works fine know.
> > 
> > I advise to apply that patch, and avoid to calculate packet sizes in 
> userspace.
> 
> I've seen this message concerning a bug in the DLC can frame when a more 
> than 8 bytes J1939 frame is sent.
> 
> Looking at the patch, it seems that every j1939 frame will be padded with 
> 0xFF, even single frame (less than 8 bytes).
> I think this is an error as standard SAEJ1939-21 specifies that for example 
> PGN request (0xEA00) is 3 byes length, and so can frame dlc must be 3 set 
> to 3.

You're right,
0xea00 indeed is defined as 3 bytes.

If I recall correctly, J1939 defines _all_ but 0xea00 to be 8 bytes long,
and use padding when not all bytes are used.
Your example happens to be the one and only exception.

> 
> May be the patch should be move on the transport module who manage Data 
> transfer protocol?

After thinking again, I realize that moving the fix to the transport protocol
would solve the problem without introducing any unwanted side effects.
Ensuring that single frames are padded to 8 bytes may be considered
a freedom/responsability of the userspace program.

> Is there something i missed?

Apparently not :-)

Kind regards,
Kurt

RE: J1939 message length

[pfifre.ext]

Hi Kurt,

I have an issue on address claim.

When I call the bind the claim address is send with a DLC of 8 and 8 bytes sent on the CAN.
But, according to the ISO11783, I need to send and address CLAIM by a 3 bytes frame.

How can, I do that with existing kernel J1939 stack or where I can modify this?

Thanks a lot.
Best regards,

Pascal
-----Message d'origine-----
De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be] 
Envoyé : lundi 15 décembre 2014 10:32
À : zze-Open the box FIFRE P ext IMT/OLPS
Cc : linux-can@vger.kernel.org
Objet : Re: J1939 message length

Hey,

On Mon, Dec 15, 2014 at 08:58:14AM +0000, pfifre.ext@orange.com wrote:
> Hi Kurt,
> 
> I resolved the issue. The problem appears with long message because, according to the j1939 specifications, the end of message has to be fulfilled with 0xFF if the message is not modulo 8.
> Apparently, the j1939  drivers don't make the padding with 0xFF.

You're not the first to find an actual ECU complaining on this.
I assembled a patch earlier this year, see http://lists.kde.org/?l=linux-can&m=139825572207448&w=2

> Then I do that in my software and it works fine know.

I advise to apply that patch, and avoid to calculate packet sizes in userspace.

Which is the remote ECU that does not accept the packets?

> 
> Perhaps, It will be a good idea to add this in the drivers.

Yep, I'll do.

Kind regards,
Kurt
> 
> Best regards,
> 
> Pascal
> 
> -----Message d'origine-----
> De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be]
> Envoyé : vendredi 12 décembre 2014 12:08 À : zze-Open the box FIFRE P 
> ext IMT/OLPS Cc : linux-can@vger.kernel.org Objet : Re: J1939 message 
> length
> 
> Hey Pascal,
> 
> On Thu, Dec 11, 2014 at 10:44:39AM +0000, pascal wrote:
> > Hi,
> > 
> > I've installed the patch for using j1939 socket CAN under linux 
> > (beagleBone black).
> > 
> > It works fine for receiving j1939 message and sending short message 
> > (8 bytes max).
> > 
> > But when I try to send long message (>8 bytes long), but the message 
> > has not been sent.
> 
> Ok.
> You provide little info how you detect that <=8 bytes work, and >8 bytes do not work.
> 
> What do you see on the (raw) CAN bus?
> 
> Are you aware of the Transport Protocol on J1939 that delivers messages >8 bytes?
> 
> Kurt
> > 
> > I use the sendTo method to send frame.
> > 
> > Do I have to do something special to send long message?
> 
> no, not necessarily.
> 
> > I'm working with a 3.8.13 kernel on beaglebone black.
> 
> Kind regards,
> Kurt
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Re: J1939 message length

[Kurt Van Dijck]

Hi Pascal,

I apologise for the late answer.
Your email has slipped in without drawing my attention.

Please find my answer below.

--- Original message ---
> Date: Mon, 27 Apr 2015 09:22:17 +0000
> From: pfifre.ext@orange.com
> To: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>
> CC: "linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
> Subject: RE: J1939 message length
> 
> Hi Kurt,
> 
> I have an issue on address claim.
> 
> When I call the bind the claim address is send with a DLC of 8 and 8 bytes sent on the CAN.
> But, according to the ISO11783, I need to send and address CLAIM by a 3 bytes frame.

The "Address Claim" PGN (0x0ee00) is 8 bytes, even in iso11783.
I think you refer to the "Request for address claimed" PGN, which is 3 bytes,
with PGN 0x0ea00, and payload 00ee00.

> 
> How can, I do that with existing kernel J1939 stack or where I can modify this?
You can just send a 3 byte message with send(SOCK, <DATA>, 3, 0)

If you want to do the address claiming,
then you may take a look at jacd, a j1939 adddress claim daemon.
It does all the userspace handling necessary for address claiming.
You can find it at https://github.com/kurt-vd/can-utils.git, in j1939-v6 branch.

Kind regards,
Kurt

RE: J1939 message length

[pfifre.ext]

Thanks for your answer Kurt.

Yes, I refer to "Request for address claimed" PGN, wich is normally 3 bytes.
When I send it with a length of 3, like jacd do, the request is sent with 8 bytes (the others are padded with 0xFF).
When I try with jacd, it sends the same frame.

I think it's a bug, I'm right?
I think, that the driver doesn't analyse the PGN and pad the frame systemically.

I can't use the send function to send the frame, because I need to specify the PGN in the address.

Then one of devices on the bus doesn't answer to the request.

Regards,

Pascal

-----Message d'origine-----
De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be] 
Envoyé : mardi 19 mai 2015 10:46
À : zze-Open the box FIFRE P ext IMT/OLPS
Cc : linux-can@vger.kernel.org
Objet : Re: J1939 message length

Hi Pascal,

I apologise for the late answer.
Your email has slipped in without drawing my attention.

Please find my answer below.

--- Original message ---
> Date: Mon, 27 Apr 2015 09:22:17 +0000
> From: pfifre.ext@orange.com
> To: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>
> CC: "linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
> Subject: RE: J1939 message length
> 
> Hi Kurt,
> 
> I have an issue on address claim.
> 
> When I call the bind the claim address is send with a DLC of 8 and 8 bytes sent on the CAN.
> But, according to the ISO11783, I need to send and address CLAIM by a 3 bytes frame.

The "Address Claim" PGN (0x0ee00) is 8 bytes, even in iso11783.
I think you refer to the "Request for address claimed" PGN, which is 3 bytes, with PGN 0x0ea00, and payload 00ee00.

> 
> How can, I do that with existing kernel J1939 stack or where I can modify this?
You can just send a 3 byte message with send(SOCK, <DATA>, 3, 0)

If you want to do the address claiming,
then you may take a look at jacd, a j1939 adddress claim daemon.
It does all the userspace handling necessary for address claiming.
You can find it at https://github.com/kurt-vd/can-utils.git, in j1939-v6 branch.

Kind regards,
Kurt

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

RE: J1939 message length

[pfifre.ext]

Hi again Kurt,

I tried to send the request with a send after binding the socket.
I have a protocol error return code = 0x47.

What does it mean?

Thanks a lot for your support.

Best regards,

Pascal

-----Message d'origine-----
De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be] 
Envoyé : mardi 19 mai 2015 10:46
À : zze-Open the box FIFRE P ext IMT/OLPS
Cc : linux-can@vger.kernel.org
Objet : Re: J1939 message length

Hi Pascal,

I apologise for the late answer.
Your email has slipped in without drawing my attention.

Please find my answer below.

--- Original message ---
> Date: Mon, 27 Apr 2015 09:22:17 +0000
> From: pfifre.ext@orange.com
> To: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>
> CC: "linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
> Subject: RE: J1939 message length
> 
> Hi Kurt,
> 
> I have an issue on address claim.
> 
> When I call the bind the claim address is send with a DLC of 8 and 8 bytes sent on the CAN.
> But, according to the ISO11783, I need to send and address CLAIM by a 3 bytes frame.

The "Address Claim" PGN (0x0ee00) is 8 bytes, even in iso11783.
I think you refer to the "Request for address claimed" PGN, which is 3 bytes, with PGN 0x0ea00, and payload 00ee00.

> 
> How can, I do that with existing kernel J1939 stack or where I can modify this?
You can just send a 3 byte message with send(SOCK, <DATA>, 3, 0)

If you want to do the address claiming,
then you may take a look at jacd, a j1939 adddress claim daemon.
It does all the userspace handling necessary for address claiming.
You can find it at https://github.com/kurt-vd/can-utils.git, in j1939-v6 branch.

Kind regards,
Kurt

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Re: J1939 message length

[Kurt Van Dijck]

Hey,

--- Original message ---
> Date: Tue, 19 May 2015 15:40:38 +0200
> From: laurent vaudoit <laurent.vaudoit@gmail.com>
> To: pfifre.ext@orange.com
> Cc: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>,
> 	"linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
> Subject: Re: J1939 message length
> 
> Hi Pascal,
> 
> i think you're mentionning the bug i have seen a few time ago.
> the pgn request is allways sent with 8 bytes instead of only 3 bytes.

I think that now too.

> i think the padding should be done in the transport layer instead of in the
> main.c file.
> you can have a look at the beginning of this mail thread.

You could change the patch mentioned earlier as:

diff --git a/net/can/j1939/main.c b/net/can/j1939/main.c
index 7edf843..1479de4 100644
--- a/net/can/j1939/main.c
+++ b/net/can/j1939/main.c
@@ -156,7 +156,9 @@ static int j1939_send_can(struct sk_buff *skb)
 		canid |= ((sk_addr->pgn & 0x3ffff) << 8);
 
 	msg->can_id = canid;
+	if ((dlc < 8) && sk_addr->pgn != 0x0ea00)) {
+		memset(msg->data+dlc, 0xff, 8 - dlc);
+		dlc = 8;
+	}
 	msg->can_dlc = dlc;
  
 	/* set net_device */
 	ret = -ENODEV;
	

--
This should fix the request PGN bug.

Due to the interest, I just worked out a different patch
that _only_ pads transport protocol data frames.
This only solves problems when the receiver is intolerant
for transport protocol frames, and not for regular frames.

Note that it makes not real sense to apply both patches.

diff --git a/net/can/j1939/transport.c b/net/can/j1939/transport.c
index 2b50902..187aaad 100644
--- a/net/can/j1939/transport.c
+++ b/net/can/j1939/transport.c
@@ -369,8 +369,9 @@ static int j1939tp_tx_dat(struct session *related,
 	/* fix pgn */
 	skb_cb->pgn = related->extd ? etp_pgn_dat : tp_pgn_dat;
 
-	skdat = skb_put(skb, len);
+	skdat = skb_put(skb, 8);
 	memcpy(skdat, dat, len);
+	memset(skdat+len, 0xff, 8-len);
 	ret = j1939_send_normalized_pkt(skb);
 	if (ret < 0)
 		kfree_skb(skb);


Kind regards,
Kurt

> 
> Regards
> 
> Laurent
> 
> On Tue, May 19, 2015 at 3:27 PM, <pfifre.ext@orange.com> wrote:
> 
> > Thanks for your answer Kurt.
> >
> > Yes, I refer to "Request for address claimed" PGN, wich is normally 3
> > bytes.
> > When I send it with a length of 3, like jacd do, the request is sent with
> > 8 bytes (the others are padded with 0xFF).
> > When I try with jacd, it sends the same frame.
> >
> > I think it's a bug, I'm right?
> > I think, that the driver doesn't analyse the PGN and pad the frame
> > systemically.
> >
> > I can't use the send function to send the frame, because I need to specify
> > the PGN in the address.
> >
> > Then one of devices on the bus doesn't answer to the request.
> >
> > Regards,
> >
> > Pascal
> >
> > -----Message d'origine-----
> > De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be]
> > Envoyé : mardi 19 mai 2015 10:46
> > À : zze-Open the box FIFRE P ext IMT/OLPS
> > Cc : linux-can@vger.kernel.org
> > Objet : Re: J1939 message length
> >
> > Hi Pascal,
> >
> > I apologise for the late answer.
> > Your email has slipped in without drawing my attention.
> >
> > Please find my answer below.
> >
> > --- Original message ---
> > > Date: Mon, 27 Apr 2015 09:22:17 +0000
> > > From: pfifre.ext@orange.com
> > > To: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>
> > > CC: "linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
> > > Subject: RE: J1939 message length
> > >
> > > Hi Kurt,
> > >
> > > I have an issue on address claim.
> > >
> > > When I call the bind the claim address is send with a DLC of 8 and 8
> > bytes sent on the CAN.
> > > But, according to the ISO11783, I need to send and address CLAIM by a 3
> > bytes frame.
> >
> > The "Address Claim" PGN (0x0ee00) is 8 bytes, even in iso11783.
> > I think you refer to the "Request for address claimed" PGN, which is 3
> > bytes, with PGN 0x0ea00, and payload 00ee00.
> >
> > >
> > > How can, I do that with existing kernel J1939 stack or where I can
> > modify this?
> > You can just send a 3 byte message with send(SOCK, <DATA>, 3, 0)
> >
> > If you want to do the address claiming,
> > then you may take a look at jacd, a j1939 adddress claim daemon.
> > It does all the userspace handling necessary for address claiming.
> > You can find it at https://github.com/kurt-vd/can-utils.git, in j1939-v6
> > branch.
> >
> > Kind regards,
> > Kurt
> >
> >
> > _________________________________________________________________________________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc
> > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> > recu ce message par erreur, veuillez le signaler
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> > electroniques etant susceptibles d'alteration,
> > Orange decline toute responsabilite si ce message a ete altere, deforme ou
> > falsifie. Merci.
> >
> > This message and its attachments may contain confidential or privileged
> > information that may be protected by law;
> > they should not be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender and
> > delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have been
> > modified, changed or falsified.
> > Thank you.
> >
> >

RE: J1939 message length

[pfifre.ext]

Thanks a lot Kurt

-----Message d'origine-----
De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be] 
Envoyé : mardi 19 mai 2015 23:02
À : laurent vaudoit
Cc : zze-Open the box FIFRE P ext IMT/OLPS; linux-can@vger.kernel.org
Objet : Re: J1939 message length

Hey,

--- Original message ---
> Date: Tue, 19 May 2015 15:40:38 +0200
> From: laurent vaudoit <laurent.vaudoit@gmail.com>
> To: pfifre.ext@orange.com
> Cc: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>,
> 	"linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
> Subject: Re: J1939 message length
> 
> Hi Pascal,
> 
> i think you're mentionning the bug i have seen a few time ago.
> the pgn request is allways sent with 8 bytes instead of only 3 bytes.

I think that now too.

> i think the padding should be done in the transport layer instead of 
> in the main.c file.
> you can have a look at the beginning of this mail thread.

You could change the patch mentioned earlier as:

diff --git a/net/can/j1939/main.c b/net/can/j1939/main.c index 7edf843..1479de4 100644
--- a/net/can/j1939/main.c
+++ b/net/can/j1939/main.c
@@ -156,7 +156,9 @@ static int j1939_send_can(struct sk_buff *skb)
 		canid |= ((sk_addr->pgn & 0x3ffff) << 8);
 
 	msg->can_id = canid;
+	if ((dlc < 8) && sk_addr->pgn != 0x0ea00)) {
+		memset(msg->data+dlc, 0xff, 8 - dlc);
+		dlc = 8;
+	}
 	msg->can_dlc = dlc;
  
 	/* set net_device */
 	ret = -ENODEV;
	

--
This should fix the request PGN bug.

Due to the interest, I just worked out a different patch that _only_ pads transport protocol data frames.
This only solves problems when the receiver is intolerant for transport protocol frames, and not for regular frames.

Note that it makes not real sense to apply both patches.

diff --git a/net/can/j1939/transport.c b/net/can/j1939/transport.c index 2b50902..187aaad 100644
--- a/net/can/j1939/transport.c
+++ b/net/can/j1939/transport.c
@@ -369,8 +369,9 @@ static int j1939tp_tx_dat(struct session *related,
 	/* fix pgn */
 	skb_cb->pgn = related->extd ? etp_pgn_dat : tp_pgn_dat;
 
-	skdat = skb_put(skb, len);
+	skdat = skb_put(skb, 8);
 	memcpy(skdat, dat, len);
+	memset(skdat+len, 0xff, 8-len);
 	ret = j1939_send_normalized_pkt(skb);
 	if (ret < 0)
 		kfree_skb(skb);


Kind regards,
Kurt

> 
> Regards
> 
> Laurent
> 
> On Tue, May 19, 2015 at 3:27 PM, <pfifre.ext@orange.com> wrote:
> 
> > Thanks for your answer Kurt.
> >
> > Yes, I refer to "Request for address claimed" PGN, wich is normally 
> > 3 bytes.
> > When I send it with a length of 3, like jacd do, the request is sent 
> > with
> > 8 bytes (the others are padded with 0xFF).
> > When I try with jacd, it sends the same frame.
> >
> > I think it's a bug, I'm right?
> > I think, that the driver doesn't analyse the PGN and pad the frame 
> > systemically.
> >
> > I can't use the send function to send the frame, because I need to 
> > specify the PGN in the address.
> >
> > Then one of devices on the bus doesn't answer to the request.
> >
> > Regards,
> >
> > Pascal
> >
> > -----Message d'origine-----
> > De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be]
> > Envoyé : mardi 19 mai 2015 10:46
> > À : zze-Open the box FIFRE P ext IMT/OLPS Cc : 
> > linux-can@vger.kernel.org Objet : Re: J1939 message length
> >
> > Hi Pascal,
> >
> > I apologise for the late answer.
> > Your email has slipped in without drawing my attention.
> >
> > Please find my answer below.
> >
> > --- Original message ---
> > > Date: Mon, 27 Apr 2015 09:22:17 +0000
> > > From: pfifre.ext@orange.com
> > > To: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>
> > > CC: "linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
> > > Subject: RE: J1939 message length
> > >
> > > Hi Kurt,
> > >
> > > I have an issue on address claim.
> > >
> > > When I call the bind the claim address is send with a DLC of 8 and 
> > > 8
> > bytes sent on the CAN.
> > > But, according to the ISO11783, I need to send and address CLAIM 
> > > by a 3
> > bytes frame.
> >
> > The "Address Claim" PGN (0x0ee00) is 8 bytes, even in iso11783.
> > I think you refer to the "Request for address claimed" PGN, which is 
> > 3 bytes, with PGN 0x0ea00, and payload 00ee00.
> >
> > >
> > > How can, I do that with existing kernel J1939 stack or where I can
> > modify this?
> > You can just send a 3 byte message with send(SOCK, <DATA>, 3, 0)
> >
> > If you want to do the address claiming, then you may take a look at 
> > jacd, a j1939 adddress claim daemon.
> > It does all the userspace handling necessary for address claiming.
> > You can find it at https://github.com/kurt-vd/can-utils.git, in 
> > j1939-v6 branch.
> >
> > Kind regards,
> > Kurt
> >
> >
> > ____________________________________________________________________
> > _____________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations 
> > confidentielles ou privilegiees et ne doivent donc pas etre 
> > diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> > ce message par erreur, veuillez le signaler a l'expediteur et le 
> > detruire ainsi que les pieces jointes. Les messages electroniques 
> > etant susceptibles d'alteration, Orange decline toute responsabilite 
> > si ce message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or 
> > privileged information that may be protected by law; they should not 
> > be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender 
> > and delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that 
> > have been modified, changed or falsified.
> > Thank you.
> >
> >

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

RE: J1939 message length

[pfifre.ext]

Hi All,

My j1939 works fine! Thanks a lot.

Now, I need to implement diagnostic ISOTP protocol on the same link.
I tried isotpsend tool to make a simple test first but this tool told me that the protocol is not supported.
Does it mean that I need to select in the kernel?

I looked for isotp.c in the kernel (net/can/isotp.c) but nothing like here.

Do you know if I need to upgrade the kernel or add user mode modules?

Thanks

Pascal


-----Message d'origine-----
De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be] 
Envoyé : mardi 19 mai 2015 23:02
À : laurent vaudoit
Cc : zze-Open the box FIFRE P ext IMT/OLPS; linux-can@vger.kernel.org
Objet : Re: J1939 message length

Hey,

--- Original message ---
> Date: Tue, 19 May 2015 15:40:38 +0200
> From: laurent vaudoit <laurent.vaudoit@gmail.com>
> To: pfifre.ext@orange.com
> Cc: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>,
> 	"linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
> Subject: Re: J1939 message length
> 
> Hi Pascal,
> 
> i think you're mentionning the bug i have seen a few time ago.
> the pgn request is allways sent with 8 bytes instead of only 3 bytes.

I think that now too.

> i think the padding should be done in the transport layer instead of 
> in the main.c file.
> you can have a look at the beginning of this mail thread.

You could change the patch mentioned earlier as:

diff --git a/net/can/j1939/main.c b/net/can/j1939/main.c index 7edf843..1479de4 100644
--- a/net/can/j1939/main.c
+++ b/net/can/j1939/main.c
@@ -156,7 +156,9 @@ static int j1939_send_can(struct sk_buff *skb)
 		canid |= ((sk_addr->pgn & 0x3ffff) << 8);
 
 	msg->can_id = canid;
+	if ((dlc < 8) && sk_addr->pgn != 0x0ea00)) {
+		memset(msg->data+dlc, 0xff, 8 - dlc);
+		dlc = 8;
+	}
 	msg->can_dlc = dlc;
  
 	/* set net_device */
 	ret = -ENODEV;
	

--
This should fix the request PGN bug.

Due to the interest, I just worked out a different patch that _only_ pads transport protocol data frames.
This only solves problems when the receiver is intolerant for transport protocol frames, and not for regular frames.

Note that it makes not real sense to apply both patches.

diff --git a/net/can/j1939/transport.c b/net/can/j1939/transport.c index 2b50902..187aaad 100644
--- a/net/can/j1939/transport.c
+++ b/net/can/j1939/transport.c
@@ -369,8 +369,9 @@ static int j1939tp_tx_dat(struct session *related,
 	/* fix pgn */
 	skb_cb->pgn = related->extd ? etp_pgn_dat : tp_pgn_dat;
 
-	skdat = skb_put(skb, len);
+	skdat = skb_put(skb, 8);
 	memcpy(skdat, dat, len);
+	memset(skdat+len, 0xff, 8-len);
 	ret = j1939_send_normalized_pkt(skb);
 	if (ret < 0)
 		kfree_skb(skb);


Kind regards,
Kurt

> 
> Regards
> 
> Laurent
> 
> On Tue, May 19, 2015 at 3:27 PM, <pfifre.ext@orange.com> wrote:
> 
> > Thanks for your answer Kurt.
> >
> > Yes, I refer to "Request for address claimed" PGN, wich is normally 
> > 3 bytes.
> > When I send it with a length of 3, like jacd do, the request is sent 
> > with
> > 8 bytes (the others are padded with 0xFF).
> > When I try with jacd, it sends the same frame.
> >
> > I think it's a bug, I'm right?
> > I think, that the driver doesn't analyse the PGN and pad the frame 
> > systemically.
> >
> > I can't use the send function to send the frame, because I need to 
> > specify the PGN in the address.
> >
> > Then one of devices on the bus doesn't answer to the request.
> >
> > Regards,
> >
> > Pascal
> >
> > -----Message d'origine-----
> > De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be]
> > Envoyé : mardi 19 mai 2015 10:46
> > À : zze-Open the box FIFRE P ext IMT/OLPS Cc : 
> > linux-can@vger.kernel.org Objet : Re: J1939 message length
> >
> > Hi Pascal,
> >
> > I apologise for the late answer.
> > Your email has slipped in without drawing my attention.
> >
> > Please find my answer below.
> >
> > --- Original message ---
> > > Date: Mon, 27 Apr 2015 09:22:17 +0000
> > > From: pfifre.ext@orange.com
> > > To: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>
> > > CC: "linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
> > > Subject: RE: J1939 message length
> > >
> > > Hi Kurt,
> > >
> > > I have an issue on address claim.
> > >
> > > When I call the bind the claim address is send with a DLC of 8 and 
> > > 8
> > bytes sent on the CAN.
> > > But, according to the ISO11783, I need to send and address CLAIM 
> > > by a 3
> > bytes frame.
> >
> > The "Address Claim" PGN (0x0ee00) is 8 bytes, even in iso11783.
> > I think you refer to the "Request for address claimed" PGN, which is 
> > 3 bytes, with PGN 0x0ea00, and payload 00ee00.
> >
> > >
> > > How can, I do that with existing kernel J1939 stack or where I can
> > modify this?
> > You can just send a 3 byte message with send(SOCK, <DATA>, 3, 0)
> >
> > If you want to do the address claiming, then you may take a look at 
> > jacd, a j1939 adddress claim daemon.
> > It does all the userspace handling necessary for address claiming.
> > You can find it at https://github.com/kurt-vd/can-utils.git, in 
> > j1939-v6 branch.
> >
> > Kind regards,
> > Kurt
> >
> >
> > ____________________________________________________________________
> > _____________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations 
> > confidentielles ou privilegiees et ne doivent donc pas etre 
> > diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> > ce message par erreur, veuillez le signaler a l'expediteur et le 
> > detruire ainsi que les pieces jointes. Les messages electroniques 
> > etant susceptibles d'alteration, Orange decline toute responsabilite 
> > si ce message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or 
> > privileged information that may be protected by law; they should not 
> > be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender 
> > and delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that 
> > have been modified, changed or falsified.
> > Thank you.
> >
> >

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Re: J1939 message length

[Oliver Hartkopp]

On 05/21/2015 05:16 PM, pfifre.ext@orange.com wrote:
> Hi All,
> 
> My j1939 works fine! Thanks a lot.
> 
> Now, I need to implement diagnostic ISOTP protocol on the same link.
> I tried isotpsend tool to make a simple test first but this tool told me that the protocol is not supported.
> Does it mean that I need to select in the kernel?
> 
> I looked for isotp.c in the kernel (net/can/isotp.c) but nothing like here.
> 
> Do you know if I need to upgrade the kernel or add user mode modules?


Hi Pascal,

the ISOTP stuff is currently outside the mainline tree too.
There are some minor things to clarify for the blocking of big PDU chunks in
the socket interface.

Btw. you can clone the isotp development repository from here:

https://github.com/hartkopp/can-isotp-modules

git clone https://github.com/hartkopp/can-isotp-modules.git

Then do

cd can-isotp-modules/net/can
./make_isotp.sh

which should create a can-isotp.ko module file you can load into your kernel:

insmod ./can-isotp.ko

That should make it :-)

Please read the README.isotp file from

https://github.com/hartkopp/can-isotp-modules

especially for the tx-queue-len configuration for you CAN netdevice.

Regards,
Oliver

RE: J1939 message length

[pfifre.ext]

Thanks a lot Oliver.

I will try this today and give you back my results.

-----Message d'origine-----
De : Oliver Hartkopp [mailto:socketcan@hartkopp.net] 
Envoyé : jeudi 21 mai 2015 22:22
À : zze-Open the box FIFRE P ext IMT/OLPS; Kurt Van Dijck; laurent vaudoit
Cc : linux-can@vger.kernel.org
Objet : Re: J1939 message length



On 05/21/2015 05:16 PM, pfifre.ext@orange.com wrote:
> Hi All,
> 
> My j1939 works fine! Thanks a lot.
> 
> Now, I need to implement diagnostic ISOTP protocol on the same link.
> I tried isotpsend tool to make a simple test first but this tool told me that the protocol is not supported.
> Does it mean that I need to select in the kernel?
> 
> I looked for isotp.c in the kernel (net/can/isotp.c) but nothing like here.
> 
> Do you know if I need to upgrade the kernel or add user mode modules?


Hi Pascal,

the ISOTP stuff is currently outside the mainline tree too.
There are some minor things to clarify for the blocking of big PDU chunks in the socket interface.

Btw. you can clone the isotp development repository from here:

https://github.com/hartkopp/can-isotp-modules

git clone https://github.com/hartkopp/can-isotp-modules.git

Then do

cd can-isotp-modules/net/can
./make_isotp.sh

which should create a can-isotp.ko module file you can load into your kernel:

insmod ./can-isotp.ko

That should make it :-)

Please read the README.isotp file from

https://github.com/hartkopp/can-isotp-modules

especially for the tx-queue-len configuration for you CAN netdevice.

Regards,
Oliver


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

RE: J1939 message length

[pfifre.ext]

Hi Kurt,

I continue my works on J1939 on another platform (based on IMX6 and Yocto).

I try now to patch the Yocto Kernel to embed your J1939 stack.
But, this yocto kernel is based on 3.10-r0 and the nearest version of your git is for 3.8 or for 3.12-rc1 kernels.

I tried to patch with the git J1939-v3.8 and lot of conflicts appears during merge.
I think I will have the same issues with 3.12-rc1.

I suppose that modifications of the kernel are limited to can stack and can drivers. I'm right?
Can I patch my kernel manualy with the specific J1939 sources and adapt their structures to my kernel version?

What do you think about that?

Best regards,

Pascal

 
-----Message d'origine-----
De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be] 
Envoyé : mardi 19 mai 2015 10:46
À : zze-Open the box FIFRE P ext IMT/OLPS
Cc : linux-can@vger.kernel.org
Objet : Re: J1939 message length

Hi Pascal,

I apologise for the late answer.
Your email has slipped in without drawing my attention.

Please find my answer below.

--- Original message ---
> Date: Mon, 27 Apr 2015 09:22:17 +0000
> From: pfifre.ext@orange.com
> To: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>
> CC: "linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
> Subject: RE: J1939 message length
> 
> Hi Kurt,
> 
> I have an issue on address claim.
> 
> When I call the bind the claim address is send with a DLC of 8 and 8 bytes sent on the CAN.
> But, according to the ISO11783, I need to send and address CLAIM by a 3 bytes frame.

The "Address Claim" PGN (0x0ee00) is 8 bytes, even in iso11783.
I think you refer to the "Request for address claimed" PGN, which is 3 bytes, with PGN 0x0ea00, and payload 00ee00.

> 
> How can, I do that with existing kernel J1939 stack or where I can modify this?
You can just send a 3 byte message with send(SOCK, <DATA>, 3, 0)

If you want to do the address claiming,
then you may take a look at jacd, a j1939 adddress claim daemon.
It does all the userspace handling necessary for address claiming.
You can find it at https://github.com/kurt-vd/can-utils.git, in j1939-v6 branch.

Kind regards,
Kurt

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

RE: J1939 + iMX6 + yocto

[Kurt Van Dijck]

Hi,


On 4 September 2015 14:24:15 CEST, pfifre.ext@orange.com wrote:
>Hi Kurt,
>
>I continue my works on J1939 on another platform (based on IMX6 and
>Yocto).

I'm currently using the same iMX6 with yocto. 

>
>I try now to patch the Yocto Kernel to embed your J1939 stack.
>But, this yocto kernel is based on 3.10-r0 and the nearest version of
>your git is for 3.8 or for 3.12-rc1 kernels.
>
>I tried to patch with the git J1939-v3.8 and lot of conflicts appears
>during merge.
>I think I will have the same issues with 3.12-rc1.
>
You need first to rebase the j1939 branch onto 3.10, or else you merge everything including 3.12.

>I suppose that modifications of the kernel are limited to can stack and
>can drivers. I'm right?

Can stack only, no drivers.

>Can I patch my kernel manualy with the specific J1939 sources and adapt
>their structures to my kernel version?

You should merge using git and resolve merge conflicts on the way.
I cannot tell from my current position which branch to start best with.
Or you could wait until Tuesday, then I can push a my 3.10 branch. I've gone through the merge conflicts already...

>
>What do you think about that?
>
>Best regards,
>
>Pascal
>

Sent from a small mobile device

RE: J1939 + iMX6 + yocto

[pfifre.ext]

Hi Kurt,

Glad to know that you already work on the same feature.

Which platform do you use?
I'm working now on the Digi ConnectCore 6.

I'm wating on Tuesday to get your 3.10 branch and test it on my side.

Thanks a lot for your help!

Pascal


-----Message d'origine-----
De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be] 
Envoyé : lundi 7 septembre 2015 02:40
À : FIFRE Pascal Ext IMT/OLPS
Cc : linux-can@vger.kernel.org
Objet : RE: J1939 + iMX6 + yocto

Hi,


On 4 September 2015 14:24:15 CEST, pfifre.ext@orange.com wrote:
>Hi Kurt,
>
>I continue my works on J1939 on another platform (based on IMX6 and 
>Yocto).

I'm currently using the same iMX6 with yocto. 

>
>I try now to patch the Yocto Kernel to embed your J1939 stack.
>But, this yocto kernel is based on 3.10-r0 and the nearest version of 
>your git is for 3.8 or for 3.12-rc1 kernels.
>
>I tried to patch with the git J1939-v3.8 and lot of conflicts appears 
>during merge.
>I think I will have the same issues with 3.12-rc1.
>
You need first to rebase the j1939 branch onto 3.10, or else you merge everything including 3.12.

>I suppose that modifications of the kernel are limited to can stack and 
>can drivers. I'm right?

Can stack only, no drivers.

>Can I patch my kernel manualy with the specific J1939 sources and adapt 
>their structures to my kernel version?

You should merge using git and resolve merge conflicts on the way.
I cannot tell from my current position which branch to start best with.
Or you could wait until Tuesday, then I can push a my 3.10 branch. I've gone through the merge conflicts already...

>
>What do you think about that?
>
>Best regards,
>
>Pascal
>

Sent from a small mobile device

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Re: J1939 + iMX6 + yocto

[Kurt Van Dijck]

Hi Pascal,

I got back to my PC now.
I see how the j1939-v3.10 branch dissapeared. I had pushed it
to gitorious.org, which is obsolete now, thinking that I had pushed it
to github. I set that right just now.

> Which platform do you use?
We have a custom iMX6 platform (in-house developed), with the core
similar to sabre-lite from Boundary Devices (They have renamed that
board now). Our board has 2 SJA1000 chips added.

I also updated iproute2-j1939, to a version that is equal to what yocto
is using now. This was less effort than choosing a different version
of iproute2 in yocto (to me).

Kind regards,
Kurt

--- Original message ---
> Date:	Mon, 7 Sep 2015 06:31:47 +0000
> From: pfifre.ext@orange.com
> To: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>
> CC: "linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
> Subject: RE: J1939 + iMX6 + yocto
> 
> Hi Kurt,
> 
> Glad to know that you already work on the same feature.
> 
> Which platform do you use?
> I'm working now on the Digi ConnectCore 6.
> 
> I'm wating on Tuesday to get your 3.10 branch and test it on my side.
> 
> Thanks a lot for your help!
> 
> Pascal
> 
> 
> -----Message d'origine-----
> De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be] 
> Envoyé : lundi 7 septembre 2015 02:40
> À : FIFRE Pascal Ext IMT/OLPS
> Cc : linux-can@vger.kernel.org
> Objet : RE: J1939 + iMX6 + yocto
> 
> Hi,
> 
> 
> On 4 September 2015 14:24:15 CEST, pfifre.ext@orange.com wrote:
> >Hi Kurt,
> >
> >I continue my works on J1939 on another platform (based on IMX6 and 
> >Yocto).
> 
> I'm currently using the same iMX6 with yocto. 
> 
> >
> >I try now to patch the Yocto Kernel to embed your J1939 stack.
> >But, this yocto kernel is based on 3.10-r0 and the nearest version of 
> >your git is for 3.8 or for 3.12-rc1 kernels.
> >
> >I tried to patch with the git J1939-v3.8 and lot of conflicts appears 
> >during merge.
> >I think I will have the same issues with 3.12-rc1.
> >
> You need first to rebase the j1939 branch onto 3.10, or else you merge everything including 3.12.
> 
> >I suppose that modifications of the kernel are limited to can stack and 
> >can drivers. I'm right?
> 
> Can stack only, no drivers.
> 
> >Can I patch my kernel manualy with the specific J1939 sources and adapt 
> >their structures to my kernel version?
> 
> You should merge using git and resolve merge conflicts on the way.
> I cannot tell from my current position which branch to start best with.
> Or you could wait until Tuesday, then I can push a my 3.10 branch. I've gone through the merge conflicts already...
> 
> >
> >What do you think about that?
> >
> >Best regards,
> >
> >Pascal
> >
> 
> Sent from a small mobile device
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 

RE: J1939 + iMX6 + yocto

[pfifre.ext]

Hi Kurt,

Thanks a lot for your update.
I get the 3.10 today from github.

"I also updated iproute2-j1939, to a version that is equal to what yocto is using now. "
What do you mean? Do you patch iproute2 for using j1939? In that case how can I retrieve this iproute2-j1939 stack to use it in yocto?

Best regards,

Pascal

-----Message d'origine-----
De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be] 
Envoyé : mardi 8 septembre 2015 09:58
À : FIFRE Pascal Ext IMT/OLPS
Cc : linux-can@vger.kernel.org
Objet : Re: J1939 + iMX6 + yocto

Hi Pascal,

I got back to my PC now.
I see how the j1939-v3.10 branch dissapeared. I had pushed it to gitorious.org, which is obsolete now, thinking that I had pushed it to github. I set that right just now.

> Which platform do you use?
We have a custom iMX6 platform (in-house developed), with the core similar to sabre-lite from Boundary Devices (They have renamed that board now). Our board has 2 SJA1000 chips added.

I also updated iproute2-j1939, to a version that is equal to what yocto is using now. This was less effort than choosing a different version of iproute2 in yocto (to me).

Kind regards,
Kurt

--- Original message ---
> Date:	Mon, 7 Sep 2015 06:31:47 +0000
> From: pfifre.ext@orange.com
> To: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>
> CC: "linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
> Subject: RE: J1939 + iMX6 + yocto
> 
> Hi Kurt,
> 
> Glad to know that you already work on the same feature.
> 
> Which platform do you use?
> I'm working now on the Digi ConnectCore 6.
> 
> I'm wating on Tuesday to get your 3.10 branch and test it on my side.
> 
> Thanks a lot for your help!
> 
> Pascal
> 
> 
> -----Message d'origine-----
> De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be]
> Envoyé : lundi 7 septembre 2015 02:40
> À : FIFRE Pascal Ext IMT/OLPS
> Cc : linux-can@vger.kernel.org
> Objet : RE: J1939 + iMX6 + yocto
> 
> Hi,
> 
> 
> On 4 September 2015 14:24:15 CEST, pfifre.ext@orange.com wrote:
> >Hi Kurt,
> >
> >I continue my works on J1939 on another platform (based on IMX6 and 
> >Yocto).
> 
> I'm currently using the same iMX6 with yocto. 
> 
> >
> >I try now to patch the Yocto Kernel to embed your J1939 stack.
> >But, this yocto kernel is based on 3.10-r0 and the nearest version of 
> >your git is for 3.8 or for 3.12-rc1 kernels.
> >
> >I tried to patch with the git J1939-v3.8 and lot of conflicts appears 
> >during merge.
> >I think I will have the same issues with 3.12-rc1.
> >
> You need first to rebase the j1939 branch onto 3.10, or else you merge everything including 3.12.
> 
> >I suppose that modifications of the kernel are limited to can stack 
> >and can drivers. I'm right?
> 
> Can stack only, no drivers.
> 
> >Can I patch my kernel manualy with the specific J1939 sources and 
> >adapt their structures to my kernel version?
> 
> You should merge using git and resolve merge conflicts on the way.
> I cannot tell from my current position which branch to start best with.
> Or you could wait until Tuesday, then I can push a my 3.10 branch. I've gone through the merge conflicts already...
> 
> >
> >What do you think about that?
> >
> >Best regards,
> >
> >Pascal
> >
> 
> Sent from a small mobile device
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Re: J1939 + iMX6 + yocto

[Kurt Van Dijck]

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

--- Original message ---
> Date: Tue, 8 Sep 2015 09:33:35 +0000
> From: pfifre.ext@orange.com
> To: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>
> CC: "linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
> Subject: RE: J1939 + iMX6 + yocto
> 
> > I also updated iproute2-j1939, to a version that is equal to what yocto is using now.
> What do you mean? Do you patch iproute2 for using j1939? In that case how can I retrieve this iproute2-j1939 stack to use it in yocto?

See http://elinux.org/J1939#Sources

You need a patched iproute2 ip program to activate j1939 on a CAN
device. Altough I had an iproute2 ready, I could not get it easily
in yocto to compile. So I created iproute2-j1939 v3.16 branch,
which equals the iproute2 version that (my) yocto uses.
I then added the bitbake recipe (see attachment) which reuses
all patches applied to the stock iproute2 program.


[-- Attachment #2: iproute2-j1939_3.16.bb --]
[-- Type: text/plain, Size: 992 bytes --]

FILESEXTRAPATHS_prepend := "${THISDIR}/../../../poky/meta/recipes-connectivity/iproute2/iproute2:"
require ../../../poky/meta/recipes-connectivity/iproute2/iproute2.inc

SRC_URI = "git://github.com/kurt-vd/iproute2.git;protocol=git;branch=j1939-v3.16 \
           file://configure-cross.patch \
           file://0001-iproute2-de-bash-scripts.patch \
           file://0001-ip-link-Remove-unnecessary-device-checking.patch \
	   "


SRCREV = "be0377ecb5a2129fc7f2f8eabeae7f68d9f44e99"
S = "${WORKDIR}/git"

# CFLAGS are computed in Makefile and reference CCOPTS
#
EXTRA_OEMAKE_append = " CCOPTS='${CFLAGS}'"
ALTERNATIVE_PRIORITY = "120"
ALTERNATIVE_TARGET[ip] = "${base_sbindir}/ip.iproute2-j1939"

# install: only install the 'ip' tool itself, not the complete package.
# If the complete package is required, just install the regular iproute2 tool.
# PS: you are free to install the exact same iproute2 version.
do_install () {
	install -D ${S}/ip/ip ${D}${base_sbindir}/ip.iproute2-j1939
}

RE: J1939 + iMX6 + yocto

[pfifre.ext]

Thanks Kurt.

I will test it on thursday and back to you.

Best regards,

Pascal

-----Message d'origine-----
De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be] 
Envoyé : mardi 8 septembre 2015 14:33
À : FIFRE Pascal Ext IMT/OLPS
Cc : linux-can@vger.kernel.org
Objet : Re: J1939 + iMX6 + yocto

--- Original message ---
> Date: Tue, 8 Sep 2015 09:33:35 +0000
> From: pfifre.ext@orange.com
> To: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>
> CC: "linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
> Subject: RE: J1939 + iMX6 + yocto
> 
> > I also updated iproute2-j1939, to a version that is equal to what yocto is using now.
> What do you mean? Do you patch iproute2 for using j1939? In that case how can I retrieve this iproute2-j1939 stack to use it in yocto?

See http://elinux.org/J1939#Sources

You need a patched iproute2 ip program to activate j1939 on a CAN device. Altough I had an iproute2 ready, I could not get it easily in yocto to compile. So I created iproute2-j1939 v3.16 branch, which equals the iproute2 version that (my) yocto uses.
I then added the bitbake recipe (see attachment) which reuses all patches applied to the stock iproute2 program.


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

RE: J1939 + iMX6 + yocto

[pfifre.ext]

Hi Kurt,

I tried to patch my Kernel (3.10r0) with the j1939-v3.10 and lot of conflicts appears again.
I noticed that I have also conflicts with the documentation repository in kernel. It seems to be strange, no?

If I just want to add j1939 stack, can I try this:
1) Add j1939 repository from your git sources in <linux kernel>/net/can/j1939
2) Mofidy Kconfig and Makefile in net/can to add j1939
3) Put the can.h from your from your git sources in <linux kernel>/include/linux/can.h
4) Modifiying af_can.c to :
	a) add these functions : can_rtl_doit, can_rtnl_dumpit, can_rtln_dump_addr, can_get_link_af_size, can_fill_link_af, can_validate_link_af, can_set_link_af
	b) add these structure : can_rtnl-af_ops
	c) Modify init_can to call rtl functions
5) Make a patch for Yocto with these

What do you think about this?

BTW, for another target, I try to get iproute2-j1939 from your github to compile for a 3.8 kernel, and the branches j1939-vX.X disappear. I found only the master branch. Is it normal?

Thanks for your great support.

Pascal





-----Message d'origine-----
De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be] 
Envoyé : mardi 8 septembre 2015 09:58
À : FIFRE Pascal Ext IMT/OLPS
Cc : linux-can@vger.kernel.org
Objet : Re: J1939 + iMX6 + yocto

Hi Pascal,

I got back to my PC now.
I see how the j1939-v3.10 branch dissapeared. I had pushed it to gitorious.org, which is obsolete now, thinking that I had pushed it to github. I set that right just now.

> Which platform do you use?
We have a custom iMX6 platform (in-house developed), with the core similar to sabre-lite from Boundary Devices (They have renamed that board now). Our board has 2 SJA1000 chips added.

I also updated iproute2-j1939, to a version that is equal to what yocto is using now. This was less effort than choosing a different version of iproute2 in yocto (to me).

Kind regards,
Kurt

--- Original message ---
> Date:	Mon, 7 Sep 2015 06:31:47 +0000
> From: pfifre.ext@orange.com
> To: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>
> CC: "linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
> Subject: RE: J1939 + iMX6 + yocto
> 
> Hi Kurt,
> 
> Glad to know that you already work on the same feature.
> 
> Which platform do you use?
> I'm working now on the Digi ConnectCore 6.
> 
> I'm wating on Tuesday to get your 3.10 branch and test it on my side.
> 
> Thanks a lot for your help!
> 
> Pascal
> 
> 
> -----Message d'origine-----
> De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be]
> Envoyé : lundi 7 septembre 2015 02:40
> À : FIFRE Pascal Ext IMT/OLPS
> Cc : linux-can@vger.kernel.org
> Objet : RE: J1939 + iMX6 + yocto
> 
> Hi,
> 
> 
> On 4 September 2015 14:24:15 CEST, pfifre.ext@orange.com wrote:
> >Hi Kurt,
> >
> >I continue my works on J1939 on another platform (based on IMX6 and 
> >Yocto).
> 
> I'm currently using the same iMX6 with yocto. 
> 
> >
> >I try now to patch the Yocto Kernel to embed your J1939 stack.
> >But, this yocto kernel is based on 3.10-r0 and the nearest version of 
> >your git is for 3.8 or for 3.12-rc1 kernels.
> >
> >I tried to patch with the git J1939-v3.8 and lot of conflicts appears 
> >during merge.
> >I think I will have the same issues with 3.12-rc1.
> >
> You need first to rebase the j1939 branch onto 3.10, or else you merge everything including 3.12.
> 
> >I suppose that modifications of the kernel are limited to can stack 
> >and can drivers. I'm right?
> 
> Can stack only, no drivers.
> 
> >Can I patch my kernel manualy with the specific J1939 sources and 
> >adapt their structures to my kernel version?
> 
> You should merge using git and resolve merge conflicts on the way.
> I cannot tell from my current position which branch to start best with.
> Or you could wait until Tuesday, then I can push a my 3.10 branch. I've gone through the merge conflicts already...
> 
> >
> >What do you think about that?
> >
> >Best regards,
> >
> >Pascal
> >
> 
> Sent from a small mobile device
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Re: J1939 + iMX6 + yocto

[Kurt Van Dijck]

> Date: Thu, 10 Sep 2015 09:56:06 +0000
> 
> Hi Kurt,
> 
> I tried to patch my Kernel (3.10r0) with the j1939-v3.10 and lot of conflicts appears again.

Did you follow the steps that I explained on http://elinux.org#J1939?
It should work, unless you are not on a v3.10 branch of your repository.

> I noticed that I have also conflicts with the documentation repository in kernel. It seems to be strange, no?
> 
> If I just want to add j1939 stack, can I try this:
> 1) Add j1939 repository from your git sources in <linux kernel>/net/can/j1939
> 2) Mofidy Kconfig and Makefile in net/can to add j1939
> 3) Put the can.h from your from your git sources in <linux kernel>/include/linux/can.h
> 4) Modifiying af_can.c to :
> 	a) add these functions : can_rtl_doit, can_rtnl_dumpit, can_rtln_dump_addr, can_get_link_af_size, can_fill_link_af, can_validate_link_af, can_set_link_af
> 	b) add these structure : can_rtnl-af_ops
> 	c) Modify init_can to call rtl functions
> 5) Make a patch for Yocto with these

You can use git to show the diff between v3.10 and j1939-v3.10.

> 
> What do you think about this?
> 
> BTW, for another target, I try to get iproute2-j1939 from your github to compile for a 3.8 kernel, and the branches j1939-vX.X disappear. I found only the master branch. Is it normal?
No.
I see all branches, but that are not as many as branches in the kernel.
The iproute2 of a newer version is usable on older versions.

Kurt

RE: J1939 + iMX6 + yocto

[pfifre.ext]

Hi Kurt,

"Did you follow the steps that I explained on http://elinux.org#J1939?"
Yes, I follow your explanations on http://elinux.org#J1939
I'm on a v3.10r0, but I don't think that's the r0 change the kernel a lot.
I will try it again.

"You can use git to show the diff between v3.10 and j1939-v3.10"
OK.

"I see all branches, but that are not as many as branches in the kernel."
OK, I will try it again.

Regards,

Pascal


-----Message d'origine-----
De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be] 
Envoyé : jeudi 10 septembre 2015 13:34
À : FIFRE Pascal Ext IMT/OLPS
Cc : linux-can@vger.kernel.org
Objet : Re: J1939 + iMX6 + yocto


> Date: Thu, 10 Sep 2015 09:56:06 +0000
> 
> Hi Kurt,
> 
> I tried to patch my Kernel (3.10r0) with the j1939-v3.10 and lot of conflicts appears again.

Did you follow the steps that I explained on http://elinux.org#J1939?
It should work, unless you are not on a v3.10 branch of your repository.

> I noticed that I have also conflicts with the documentation repository in kernel. It seems to be strange, no?
> 
> If I just want to add j1939 stack, can I try this:
> 1) Add j1939 repository from your git sources in <linux kernel>/net/can/j1939
> 2) Mofidy Kconfig and Makefile in net/can to add j1939
> 3) Put the can.h from your from your git sources in <linux kernel>/include/linux/can.h
> 4) Modifiying af_can.c to :
> 	a) add these functions : can_rtl_doit, can_rtnl_dumpit, can_rtln_dump_addr, can_get_link_af_size, can_fill_link_af, can_validate_link_af, can_set_link_af
> 	b) add these structure : can_rtnl-af_ops
> 	c) Modify init_can to call rtl functions
> 5) Make a patch for Yocto with these

You can use git to show the diff between v3.10 and j1939-v3.10.

> 
> What do you think about this?
> 
> BTW, for another target, I try to get iproute2-j1939 from your github to compile for a 3.8 kernel, and the branches j1939-vX.X disappear. I found only the master branch. Is it normal?
No.
I see all branches, but that are not as many as branches in the kernel.
The iproute2 of a newer version is usable on older versions.

Kurt

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Re: J1939 + iMX6 + yocto

[Marc Kleine-Budde]

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

On 09/10/2015 03:18 PM, pfifre.ext@orange.com wrote:
> "Did you follow the steps that I explained on http://elinux.org#J1939?"
> Yes, I follow your explanations on http://elinux.org#J1939
> I'm on a v3.10r0, but I don't think that's the r0 change the kernel a lot.
> I will try it again.

What's a v3.10r0? There is no official "r0" Kernel release. Your kernel
vendor may probably help you with this.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


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

RE: J1939 + iMX6 + yocto

[pfifre.ext]

In fact is a 3.10-r0 and not 3.10r0.
But you are right : it's not an official release.

Yes, I think so : I will talk with my provider.

I try also another way : 
1) get an official release of 3.10
2) make a patch with  the j1939 release
3) try to apply the patch to my kernel and see


Regards,

Pascal

 

-----Message d'origine-----
De : Marc Kleine-Budde [mailto:mkl@pengutronix.de] 
Envoyé : jeudi 10 septembre 2015 15:31
À : FIFRE Pascal Ext IMT/OLPS; Kurt Van Dijck
Cc : linux-can@vger.kernel.org
Objet : Re: J1939 + iMX6 + yocto

On 09/10/2015 03:18 PM, pfifre.ext@orange.com wrote:
> "Did you follow the steps that I explained on http://elinux.org#J1939?"
> Yes, I follow your explanations on http://elinux.org#J1939 I'm on a 
> v3.10r0, but I don't think that's the r0 change the kernel a lot.
> I will try it again.

What's a v3.10r0? There is no official "r0" Kernel release. Your kernel vendor may probably help you with this.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Re: J1939 + iMX6 + yocto

[Kurt Van Dijck]

> In fact is a 3.10-r0 and not 3.10r0.
> But you are right : it's not an official release.
> 

git diff v3.10.. --stat -- net/can/ include/linux/can include/uapi/linux/can.h include/uapi/linux/can

yielded this to my side, after applying j1939 and everything.

 include/linux/can/core.h       |   31 +
 include/linux/can/dev.h        |    2 +
 include/uapi/linux/can.h       |   20 +-
 include/uapi/linux/can/Kbuild  |    1 +
 include/uapi/linux/can/j1939.h |   99 +++
 net/can/Kconfig                |    2 +
 net/can/Makefile               |    2 +
 net/can/af_can.c               |  213 +++++-
 net/can/bcm.c                  |    4 +-
 net/can/j1939/Kconfig          |   22 +
 net/can/j1939/Makefile         |   14 +
 net/can/j1939/address-claim.c  |  227 +++++++
 net/can/j1939/bus.c            |  516 ++++++++++++++
 net/can/j1939/filter.c         |   76 +++
 net/can/j1939/j1939-priv.h     |  314 +++++++++
 net/can/j1939/main.c           |  463 +++++++++++++
 net/can/j1939/proc.c           |   81 +++
 net/can/j1939/promisc.c        |   43 ++
 net/can/j1939/rtnl.c           |  306 +++++++++
 net/can/j1939/socket.c         |  984 +++++++++++++++++++++++++++
 net/can/j1939/transport.c      | 1449 ++++++++++++++++++++++++++++++++++++++++
 net/can/raw.c                  |    4 +-
 22 files changed, 4867 insertions(+), 6 deletions(-)

What does your v3.10-r0, before applying j1939?

> Yes, I think so : I will talk with my provider.
> 
> I try also another way : 
> 1) get an official release of 3.10
> 2) make a patch with  the j1939 release
> 3) try to apply the patch to my kernel and see

Sounds like a good plan to try!

Kurt

RE: J1939 + iMX6 + yocto

[pfifre.ext]

Hi Kurt,

My kernel is a part of the Yocto generation.
In fact, I tried to patch the <yocto>/tmp/work/git/ repository because the kernel is here.
Perhaps, it was a bad idea. What do you think about that?

Yesterday, I downloaded a version an official kernel release and applied the j1939 patch.
I had the same results as you (below).
I think I'm on the good road.

Thanks Kurt !

Regards,

Pascal

-----Message d'origine-----
De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be] 
Envoyé : vendredi 11 septembre 2015 05:50
À : FIFRE Pascal Ext IMT/OLPS
Cc : Marc Kleine-Budde; linux-can@vger.kernel.org
Objet : Re: J1939 + iMX6 + yocto

> In fact is a 3.10-r0 and not 3.10r0.
> But you are right : it's not an official release.
> 

git diff v3.10.. --stat -- net/can/ include/linux/can include/uapi/linux/can.h include/uapi/linux/can

yielded this to my side, after applying j1939 and everything.

 include/linux/can/core.h       |   31 +
 include/linux/can/dev.h        |    2 +
 include/uapi/linux/can.h       |   20 +-
 include/uapi/linux/can/Kbuild  |    1 +
 include/uapi/linux/can/j1939.h |   99 +++
 net/can/Kconfig                |    2 +
 net/can/Makefile               |    2 +
 net/can/af_can.c               |  213 +++++-
 net/can/bcm.c                  |    4 +-
 net/can/j1939/Kconfig          |   22 +
 net/can/j1939/Makefile         |   14 +
 net/can/j1939/address-claim.c  |  227 +++++++
 net/can/j1939/bus.c            |  516 ++++++++++++++
 net/can/j1939/filter.c         |   76 +++
 net/can/j1939/j1939-priv.h     |  314 +++++++++
 net/can/j1939/main.c           |  463 +++++++++++++
 net/can/j1939/proc.c           |   81 +++
 net/can/j1939/promisc.c        |   43 ++
 net/can/j1939/rtnl.c           |  306 +++++++++
 net/can/j1939/socket.c         |  984 +++++++++++++++++++++++++++
 net/can/j1939/transport.c      | 1449 ++++++++++++++++++++++++++++++++++++++++
 net/can/raw.c                  |    4 +-
 22 files changed, 4867 insertions(+), 6 deletions(-)

What does your v3.10-r0, before applying j1939?

> Yes, I think so : I will talk with my provider.
> 
> I try also another way : 
> 1) get an official release of 3.10
> 2) make a patch with  the j1939 release
> 3) try to apply the patch to my kernel and see

Sounds like a good plan to try!

Kurt

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Re: J1939 + iMX6 + yocto

[Kurt Van Dijck]

> My kernel is a part of the Yocto generation.

Because we have our own board, we never actually used the kernel from
Yocto, instead we told yocto to use our own kernel.
I've never actually performed the operation on yocto's kernel.

Can you provide the git url of the kernel you were using (that
v3.10-r0)?
I could give it a try to merge can-j1939 into it.

> In fact, I tried to patch the <yocto>/tmp/work/git/ repository because the kernel is here.
> Perhaps, it was a bad idea. What do you think about that?

As told above, we tell yocto to use a different kernel, because I think
that is easier.

Of course, our kernel also has a bunch of freescale commits applied.

Kurt

RE: J1939 + iMX6 + yocto

[pfifre.ext]

Hi Kurt,

I have some good news: 
I've created a patch for j1939.txt and apply to my yocto kernel (then a merge with your modifications).
I try, now, to make a bbappend and a recipe to patch the kernel with yocto.

I will keep you informed to of my progress

Regards,

Pascal

-----Message d'origine-----
De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be] 
Envoyé : vendredi 11 septembre 2015 11:48
À : FIFRE Pascal Ext IMT/OLPS
Cc : Marc Kleine-Budde; linux-can@vger.kernel.org
Objet : Re: J1939 + iMX6 + yocto

> My kernel is a part of the Yocto generation.

Because we have our own board, we never actually used the kernel from Yocto, instead we told yocto to use our own kernel.
I've never actually performed the operation on yocto's kernel.

Can you provide the git url of the kernel you were using (that v3.10-r0)?
I could give it a try to merge can-j1939 into it.

> In fact, I tried to patch the <yocto>/tmp/work/git/ repository because the kernel is here.
> Perhaps, it was a bad idea. What do you think about that?

As told above, we tell yocto to use a different kernel, because I think that is easier.

Of course, our kernel also has a bunch of freescale commits applied.

Kurt

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

RE: J1939 + iMX6 + yocto

[pfifre.ext]

Hi Kurt,

I made the patch for Yocto and now my Yocto Kernel embeds j1939!!
Now, I need to add iproute2 and my application.

Thanks a lot for your great support

Pascal

-----Message d'origine-----
De : FIFRE Pascal Ext IMT/OLPS 
Envoyé : vendredi 11 septembre 2015 11:54
À : 'Kurt Van Dijck'; FIFRE Pascal Ext IMT/OLPS
Cc : Marc Kleine-Budde; linux-can@vger.kernel.org
Objet : RE: J1939 + iMX6 + yocto

Hi Kurt,

I have some good news: 
I've created a patch for j1939.txt and apply to my yocto kernel (then a merge with your modifications).
I try, now, to make a bbappend and a recipe to patch the kernel with yocto.

I will keep you informed to of my progress

Regards,

Pascal

-----Message d'origine-----
De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be]
Envoyé : vendredi 11 septembre 2015 11:48 À : FIFRE Pascal Ext IMT/OLPS Cc : Marc Kleine-Budde; linux-can@vger.kernel.org Objet : Re: J1939 + iMX6 + yocto

> My kernel is a part of the Yocto generation.

Because we have our own board, we never actually used the kernel from Yocto, instead we told yocto to use our own kernel.
I've never actually performed the operation on yocto's kernel.

Can you provide the git url of the kernel you were using (that v3.10-r0)?
I could give it a try to merge can-j1939 into it.

> In fact, I tried to patch the <yocto>/tmp/work/git/ repository because the kernel is here.
> Perhaps, it was a bad idea. What do you think about that?

As told above, we tell yocto to use a different kernel, because I think that is easier.

Of course, our kernel also has a bunch of freescale commits applied.

Kurt

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

RE: J1939 + iMX6 + yocto

[pfifre.ext]

Hi Kurt,

I add the Yocto patch yesterday in my distribution.
It's very strange, because it seems to be applied on build (it appears on the Build without errors) but not on the distribution: I can't add any j1939 link (either "dev" is duplicate, or "j1939" is a garbage).
Apparently, bitbake finds the necessary files.
I have just one warning at build : the file file://0001-ip-link-Remove-unnecessary-device-checking.patch doesn't be found by the build (not present on poky, then I removed this line in the bb).

In fact, I notice that the git command in the bb doesn't work. I have made a voluntary error in the path and the build ran with no errors.
Then, your patch is no applied to the distribution.

Do you have any idea?

It's the last task I have to do to run all the features of my application.

Thanks for your support.

Best regards,

Pascal


-----Message d'origine-----
De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be] 
Envoyé : mardi 8 septembre 2015 14:33
À : FIFRE Pascal Ext IMT/OLPS
Cc : linux-can@vger.kernel.org
Objet : Re: J1939 + iMX6 + yocto

--- Original message ---
> Date: Tue, 8 Sep 2015 09:33:35 +0000
> From: pfifre.ext@orange.com
> To: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>
> CC: "linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
> Subject: RE: J1939 + iMX6 + yocto
> 
> > I also updated iproute2-j1939, to a version that is equal to what yocto is using now.
> What do you mean? Do you patch iproute2 for using j1939? In that case how can I retrieve this iproute2-j1939 stack to use it in yocto?

See http://elinux.org/J1939#Sources

You need a patched iproute2 ip program to activate j1939 on a CAN device. Altough I had an iproute2 ready, I could not get it easily in yocto to compile. So I created iproute2-j1939 v3.16 branch, which equals the iproute2 version that (my) yocto uses.
I then added the bitbake recipe (see attachment) which reuses all patches applied to the stock iproute2 program.


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

RE: J1939 + iMX6 + yocto

[Kurt Van Dijck]

On 18 September 2015 11:04:29 CEST, pfifre.ext@orange.com wrote:
>Hi Kurt,
>
>I add the Yocto patch yesterday in my distribution.
>It's very strange, because it seems to be applied on build (it appears
>on the Build without errors) but not on the distribution: I can't add
>any j1939 link (either "dev" is duplicate, or "j1939" is a garbage).

The warning comes from iproute2. Did you patch that already?

>Apparently, bitbake finds the necessary files.
>I have just one warning at build : the file
>file://0001-ip-link-Remove-unnecessary-device-checking.patch doesn't be
>found by the build (not present on poky, then I removed this line in
>the bb).
>
>In fact, I notice that the git command in the bb doesn't work. I have
>made a voluntary error in the path and the build ran with no errors.
>Then, your patch is no applied to the distribution.
>
>Do you have any idea?
>
>It's the last task I have to do to run all the features of my
>application.
>
>Thanks for your support.
>
>Best regards,
>
>Pascal
>

Sent from a small mobile device

RE: J1939 + iMX6 + yocto

[pfifre.ext]

Hi Kurt,

That's the question: the patch seems to be build, but, this warning : "either "dev" is duplicate, or "j1939" is a garbage" seems that no patch has been done on the final distribution, no?
I remember that this warning comes with the absence of iproute2-j1939 patch. It is right?

I verified the iproute2-j1939 recipe alone and it works fine.
I think the patch won't be correctly done with the global recipe.

Best regards,

Pascal


-----Message d'origine-----
De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be] 
Envoyé : vendredi 18 septembre 2015 14:11
À : FIFRE Pascal Ext IMT/OLPS
Cc : linux-can@vger.kernel.org
Objet : RE: J1939 + iMX6 + yocto



On 18 September 2015 11:04:29 CEST, pfifre.ext@orange.com wrote:
>Hi Kurt,
>
>I add the Yocto patch yesterday in my distribution.
>It's very strange, because it seems to be applied on build (it appears 
>on the Build without errors) but not on the distribution: I can't add 
>any j1939 link (either "dev" is duplicate, or "j1939" is a garbage).

The warning comes from iproute2. Did you patch that already?

>Apparently, bitbake finds the necessary files.
>I have just one warning at build : the file 
>file://0001-ip-link-Remove-unnecessary-device-checking.patch doesn't be 
>found by the build (not present on poky, then I removed this line in 
>the bb).
>
>In fact, I notice that the git command in the bb doesn't work. I have 
>made a voluntary error in the path and the build ran with no errors.
>Then, your patch is no applied to the distribution.
>
>Do you have any idea?
>
>It's the last task I have to do to run all the features of my 
>application.
>
>Thanks for your support.
>
>Best regards,
>
>Pascal
>

Sent from a small mobile device

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

RE: J1939 + iMX6 + yocto

[Kurt Van Dijck]

On 18 September 2015 14:29:40 CEST, pfifre.ext@orange.com wrote:
>Hi Kurt,
>
>That's the question: the patch seems to be build, but, this warning :
>"either "dev" is duplicate, or "j1939" is a garbage" seems that no
>patch has been done on the final distribution, no?
>I remember that this warning comes with the absence of iproute2-j1939
>patch. It is right?
>

Yes, you're right

>I verified the iproute2-j1939 recipe alone and it works fine.
>I think the patch won't be correctly done with the global recipe.
>

So this becomes a pure yocto issue.
Are you sure that 'ip' tool on the rootfs is from busybox or iproute2?

Kurt

>Best regards,
>
>Pascal
>
>
>-----Message d'origine-----
>De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be] 
>Envoyé : vendredi 18 septembre 2015 14:11
>À : FIFRE Pascal Ext IMT/OLPS
>Cc : linux-can@vger.kernel.org
>Objet : RE: J1939 + iMX6 + yocto
>
>
>
>On 18 September 2015 11:04:29 CEST, pfifre.ext@orange.com wrote:
>>Hi Kurt,
>>
>>I add the Yocto patch yesterday in my distribution.
>>It's very strange, because it seems to be applied on build (it appears
>
>>on the Build without errors) but not on the distribution: I can't add 
>>any j1939 link (either "dev" is duplicate, or "j1939" is a garbage).
>
>The warning comes from iproute2. Did you patch that already?
>
>>Apparently, bitbake finds the necessary files.
>>I have just one warning at build : the file 
>>file://0001-ip-link-Remove-unnecessary-device-checking.patch doesn't
>be 
>>found by the build (not present on poky, then I removed this line in 
>>the bb).
>>
>>In fact, I notice that the git command in the bb doesn't work. I have 
>>made a voluntary error in the path and the build ran with no errors.
>>Then, your patch is no applied to the distribution.
>>
>>Do you have any idea?
>>
>>It's the last task I have to do to run all the features of my 
>>application.
>>
>>Thanks for your support.
>>
>>Best regards,
>>
>>Pascal
>>
>
>Sent from a small mobile device
>
>_________________________________________________________________________________________________________________________
>
>Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc
>pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>recu ce message par erreur, veuillez le signaler
>a l'expediteur et le detruire ainsi que les pieces jointes. Les
>messages electroniques etant susceptibles d'alteration,
>Orange decline toute responsabilite si ce message a ete altere, deforme
>ou falsifie. Merci.
>
>This message and its attachments may contain confidential or privileged
>information that may be protected by law;
>they should not be distributed, used or copied without authorisation.
>If you have received this email in error, please notify the sender and
>delete this message and its attachments.
>As emails may be altered, Orange is not liable for messages that have
>been modified, changed or falsified.
>Thank you.

Sent from a small mobile device

RE: J1939 + iMX6 + yocto

[pfifre.ext]

Hi Kurt,

I found my mistake.

It works now.

Thanks a lot,

Pascal

-----Message d'origine-----
De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be] 
Envoyé : samedi 19 septembre 2015 08:35
À : FIFRE Pascal Ext IMT/OLPS
Cc : linux-can@vger.kernel.org
Objet : RE: J1939 + iMX6 + yocto



On 18 September 2015 14:29:40 CEST, pfifre.ext@orange.com wrote:
>Hi Kurt,
>
>That's the question: the patch seems to be build, but, this warning :
>"either "dev" is duplicate, or "j1939" is a garbage" seems that no 
>patch has been done on the final distribution, no?
>I remember that this warning comes with the absence of iproute2-j1939 
>patch. It is right?
>

Yes, you're right

>I verified the iproute2-j1939 recipe alone and it works fine.
>I think the patch won't be correctly done with the global recipe.
>

So this becomes a pure yocto issue.
Are you sure that 'ip' tool on the rootfs is from busybox or iproute2?

Kurt

>Best regards,
>
>Pascal
>
>
>-----Message d'origine-----
>De : Kurt Van Dijck [mailto:dev.kurt@vandijck-laurijssen.be]
>Envoyé : vendredi 18 septembre 2015 14:11 À : FIFRE Pascal Ext IMT/OLPS 
>Cc : linux-can@vger.kernel.org Objet : RE: J1939 + iMX6 + yocto
>
>
>
>On 18 September 2015 11:04:29 CEST, pfifre.ext@orange.com wrote:
>>Hi Kurt,
>>
>>I add the Yocto patch yesterday in my distribution.
>>It's very strange, because it seems to be applied on build (it appears
>
>>on the Build without errors) but not on the distribution: I can't add 
>>any j1939 link (either "dev" is duplicate, or "j1939" is a garbage).
>
>The warning comes from iproute2. Did you patch that already?
>
>>Apparently, bitbake finds the necessary files.
>>I have just one warning at build : the file 
>>file://0001-ip-link-Remove-unnecessary-device-checking.patch doesn't
>be 
>>found by the build (not present on poky, then I removed this line in 
>>the bb).
>>
>>In fact, I notice that the git command in the bb doesn't work. I have 
>>made a voluntary error in the path and the build ran with no errors.
>>Then, your patch is no applied to the distribution.
>>
>>Do you have any idea?
>>
>>It's the last task I have to do to run all the features of my 
>>application.
>>
>>Thanks for your support.
>>
>>Best regards,
>>
>>Pascal
>>
>
>Sent from a small mobile device
>
>_________________________________________________________________________________________________________________________
>
>Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc
>pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>recu ce message par erreur, veuillez le signaler
>a l'expediteur et le detruire ainsi que les pieces jointes. Les
>messages electroniques etant susceptibles d'alteration,
>Orange decline toute responsabilite si ce message a ete altere, deforme
>ou falsifie. Merci.
>
>This message and its attachments may contain confidential or privileged
>information that may be protected by law;
>they should not be distributed, used or copied without authorisation.
>If you have received this email in error, please notify the sender and
>delete this message and its attachments.
>As emails may be altered, Orange is not liable for messages that have
>been modified, changed or falsified.
>Thank you.

Sent from a small mobile device

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.