Dear Richard,
my linux kernel is 3.0, and my phy is DP83640, and my mac is stmmac,
and my cpu is arm， i just cross-compile the linuxptp, and it seems ok, but
when i run it and use hardware timestamp (./ptp4l - H -i eth0 -p
/dev/ptp0) on my system, the kernel crashed.
so, i just see linuxptp can run in kernel v3.0 and suport DP83640, is
there any thing wrong? thanks!
and this is happed in the function hwts_init (sk.c line 45) , when ioctl
(fd, SIOCHWTSAMP, &ifreq) [sk.c line 62]. thanks again,....please help me
2014-04-05 18:40 GMT+08:00 Richard Cochran <richardcoch...@gmail.com>:
> I looked again at the unicast issue, and here is what I found.
>
> * 1588 has a very complex unicast subscription protocol (16.1). This
> is similar to what you have in this series, and so if we do it right
> then we will have a good basis for adding this later.
>
> * 1588 also allows basically any kind of unicast you might want
> (7.3.2). This probably the reason why other PTP implementations just
> implement whatever they dream up, ignoring (16.1).
>
> * The enterprise profile [1] forbids using (16.1). Instead it has the
> master send unicast delay responses to unicast delay requests and
> use multicast when the delay request is multicast.
>
> 1.
> http://datatracker.ietf.org/doc/draft-ietf-tictoc-ptp-enterprise-profile/
>
> So getting back to this patch, I would like to see this:
>
> > Or how about this: Let transport_send accept an optional pointer to
> > an address structure. Also, transport_recv could always return the
> > source address, and we won't need a separate "get last address"
> > function.
>
> This means using recvfrom in the transports. Also, the struct
> ptp_message should have a new field to hold the source address.
>
> Let us introduce a struct to hold addresses, something like:
>
> struct address {
> uint8_t buf[MAXADDR];
> socklen_t len;
> }
>
> In that way we won't need to add 'addr' and 'len' all over the place,
> and if we end up needing the interface index, it will be easy to add
> later on.
>
> Does this make sense to you?
>
> If not I'll whip up a patch to show what I mean.
>
> Thanks,
> Richard
>
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
>
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
