CM4 is missing IEEE1588-2008 support through BCM54210PE

[tschiemer]

Is this the right place for my bug report? Yes: I asked on the forum, I asked the raspberry foundation through the contact form but didn't get any response - it is very much kernel related as is explained in the forum post.

Describe the bug The CM4 has an undocumented inofficial PHY (BCM54210PE) that supports hardware timestamping (and a hardware clock, actually??), but there seems to be no driver supporting these features.

So CM4 does actually not provide hardware based IEEE1588-2008 support as opposed to what the raspberry pi foundation actually communicates in the CM4 datasheet.

To reproduce sudo ethtool -T eth0 only shows software timestamping capabilities.

Expected behaviour Depends - the raspberry pi foundation never communicated what IEEE1588-2008 features are supported such that is is unclear what exactly can be expected; also the PHY documentation is not available such that possibilities (ie optimal expected behaviour) can not be described.

Expected (according to https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/s1-using_ptp):

• eth support for:
  • SOF_TIMESTAMPING_TX_HARDWARE
  • SOF_TIMESTAMPING_RX_HARDWARE
  • (possibly) SOF_TIMESTAMPING_RAW_HARDWARE
• shows PTP Hardware Clock (because BCM54210PE has on-chip clock)
• Hardware Transmit Timestamp Modes ??
• Hardware Receive Filter Modes ??

The CM4 datasheet lists SYNC_IN, SYNC_OUT pins ment for IEEE1588-2008 support but has not further specified this. It actually is a question wether these pins are needed in the first place - because the PHY would seem to have a hardware-clock itself. Further it must be clear wether the PHY's internal clock (if any) is routed to a CM4 pin in any form and if not this should be fixed in future revisions because custom boards for the CM4 might require tight synchronization to a hardware clock.

Actual behaviour sudo ethtool -T eth0 only shows software timestamping capabilities. There is no (documented) synchronizable IEEE1588-2008 clock signal going from the CM4.

System Raspberry Pi Compute Module 4

Raspberry Pi OS Lite, January 11th 2021, Kernel version: 5.4 Ubuntu Server 20.04.2 LTS,

Logs none

Additional context BCM54210PE documentation is required to implement to see actual features provided and configuration options - IEEE802.3-2018 seems to define said capabilities etc. Possibly also required are CM4 schematics and BCM2711 documentation. Also see IEEE802.3-2018 Section 90. Ethernet support for time synchronization protocols

I can try to take care of the implementation, but I would like to have the mentioned documents.

[neggles]

@maxlem I can fairly confidently say the Pi4 PHY does not have hardware timestamping capability 😢 The CM4 technical docs call out IEEE 1588/HW timestamp support, but the Pi4 technical docs don't.

Edit: Snipped some stuff out, as there are public product pages for both PHYs with feature lists;

Pi4 BCM54213PE CM4 BCM54210PE (well, not the PE specifically, but I assume that just means "lower power version" or possibly "Raspberry Pi version"

54213PE has no mention of timestamping/clocking support, while 54210PE explicitly does 👍

[cfdez-tech]

At the moment we're working on a driver for supporting PTP on the 54210PE on RPI, but it's not fully working yet. RX it's working but TX isn't.

If you're interested in collaborating please feel free to take a look at https://github.com/cfdez-tech/linux/tree/bcm54210pe_ptp

Thanks!

[cfdez-tech]

The driver it's nearly done, but I don't know why txtstamp function is not being called. Any help will be welcomed.

[pelwell]

By "RPI" you mean CM4, right?

[cfdez-tech]

By "RPI" you mean CM4, right?

Yes, sorry.

[maxlem]

@maxlem I can fairly confidently say the Pi4 PHY does not have hardware timestamping capability The CM4 technical docs call out IEEE 1588/HW timestamp support, but the Pi4 technical docs don't.

Edit: Snipped some stuff out, as there are public product pages for both PHYs with feature lists;

Pi4 BCM54213PE CM4 BCM54210PE (well, not the PE specifically, but I assume that just means "lower power version" or possibly "Raspberry Pi version"

54213PE has no mention of timestamping/clocking support, while 54210PE explicitly does

Those pesky chipmakers.. I'm sure the feature is just fused-off Too bad, then :(

[JohnnyBBravo]

Are there any updates on this? Is the TX timestamping working? I'm afraid I'm of no use with code, but I'm more than happy to help with testing & troubleshooting. Having 1588/HW timestamping is one of the reasons why I got a CM4 in the first place :-)

[JohnnyBBravo]

Anyone?

[tschiemer]

Can try to have look further into summer/july

@cfdez-tech is the previously mentioned state (rx working but not tx) still the state of affairs? as I undertsand you the driver's txstamp function is not being called? (didn't have a look yet)

[cfdez-tech]

Hi Philip,

I'm sorry, but other urgent projects get in my way so I've got to step aside this one. I'll take care of it ASAP.

Thanks,

Carlos Fernández Embedded Linux Engineer Technica Electronics Barcelona Av. de la Via Augusta, 15-25 Sant Cugat del Vallès, Barcelona, 08174

Tel: +34 933959156

[cid:d4600bed-25e2-4490-865f-44f1b55b053a]

---

From: philip @.> Sent: Friday, July 2, 2021 9:35 AM To: raspberrypi/linux @.> Cc: Carlos Fernandez @.>; Mention @.> Subject: Re: [raspberrypi/linux] CM4 is missing IEEE1588-2008 support through BCM54210PE (#4151)

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Can try to have look further into summer/july

@cfdez-techhttps://github.com/cfdez-tech is the previously mentioned state (rx working but not tx) still the state of affairs? as I undertsand you the driver's txstamp function is not being called? (didn't have a look yet)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/raspberrypi/linux/issues/4151#issuecomment-872787133, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ATFJWPINH52574Z3KS2AWLTTVVT3VANCNFSM4XWOSD6Q.

[jdkoftinoff]

@marcohabeck: but to be able to use the PHY sensibly, it takes a little more. EE 802.1Qav traffic shaper VLAN support, and several queues. The driver and of course the hardware must support this. In order to be able to implement real-time capable fieldbuses at all. The board is supposed to be intended for the industry, isn't it? I am honest and say that at the price it is questionable to develop all of this without help. That everything is under NDA makes it very difficult. There are alternatives ...

I am struggling to understand the point you are actually trying to make here. Yes, PTPv2 support alone is not enough to add support for EtherCAT, Ethernet AVB and other similar real-time ethernet-based protocols - but they all require PTPv2 be implemented first. There are plenty of uses for PTPv2 outside of synchronous networking, too - so the obvious first step would be to add driver support for the PHY PTP clock/timestamping hardware, which is what this thread is about. Yes, there's an NDA on some of the hardware documentation, but there are also plenty of people with access to that NDA'd documentation & it's not always needed to figure it out anyway. Many hands make light work, and the low cost of raspberry pi produced devices attracts a lot of people! Getting back on topic, excellent news indeed! Hopefully there's support for timestamping unicast PTP (and NTP!) packets, since I only have one switch (with a mere four ports) that supports layer-2 PTP...

I am just curious about what kind switch you got that supports layer-2 PTP? Would you able to share some info about it, like witch brand, model, the chip used inside, etc... I am trying hard to find a decent one of SMB grade.

It seems that Broadcom has its own time sync tech (BroadSync HD), which claims to be 802.1as compliant. But 802.1as is not fully compliant with 1588v2, so this get things even more complex.

thanks!

Late to this thread but I have the https://motu.com/products/avb/avb-switch which works great and you can get it from Amazon and guitar center or other music places like Sweetwater

[ahmadexp]

Just wondering if getting PTP to work on the CM4 finally became a reality? Also, please have a look the open source timingcard.com that allows you to build you GM with a given NIC on the side

[ulbricht-inr]

PTP is working with RPI4 https://hackaday.com/2021/08/16/new-part-day-raspberry-pi-hat-for-ieee1588-precision-time-protocol/ I see no blockingpoint to port this also to CM4, because just SPI and an Ethernet-PHY is needed.

[nullr0ute]

PTP is working with RPI4 https://hackaday.com/2021/08/16/new-part-day-raspberry-pi-hat-for-ieee1588-precision-time-protocol/ I see no blockingpoint to port this also to CM4, because just SPI and an Ethernet-PHY is needed.

That's an addon HAT that's doing it separately to the onboard NIC and injecting the timestamps. The HW needs to be able to support PTP for it to work with the onboard NIC and someone needs to add support to the drivers. It's not just as simple as turning on kernel configs.

[marcohabeck]

I feel the same way. It bypasses the real problem without solving it.

Am 19.08.2021 um 12:11 schrieb Peter Robinson:

PTP is working with RPI4
https://hackaday.com/2021/08/16/new-part-day-raspberry-pi-hat-for-ieee1588-precision-time-protocol/
<https://hackaday.com/2021/08/16/new-part-day-raspberry-pi-hat-for-ieee1588-precision-time-protocol/>
I see no blockingpoint to port this also to CM4, because just SPI
and an Ethernet-PHY is needed.

That's an addon HAT that's doing it separately to the onboard NIC and injecting the timestamps. The HW needs to be able to support PTP for it to work with the onboard NIC and someone needs to add support to the drivers. It's not just as simple as turning on kernel configs.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/4151#issuecomment-901788529, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYOHWJTM2WSNYRI6LYNLI3T5TKGJANCNFSM4XWOSD6Q.

[neggles]

Yeah, that's... a really nasty and expensive hackaround. If you're going to go that far, it would be a lot cheaper, simpler, and easier to put an i210-AT or i350 NIC on a CM4 carrier board connected to the module's PCIe lane... or use a Zynq-7000 SoC which can do HW timestamping all by itself, with a bit of effort and FPGA gateware. (Can you tell I've spent a lot of time looking into SBCs with hardware PTP capability?)

The whole point of this issue is, the CM4's Ethernet PHY does not need any external hardware to do hardware timestamped PTP - and as such it should be able to hit within a few hundred nanoseconds accuracy (with direct 1PPS-in going to the PHY chip from a GPS or other stratum-0 source).

I would love to help out with getting this working, since it seems like those who were working on it before don't have time at the moment, but the necessary bits and pieces of SDK are hidden behind Broadcom NDA walls & I'm not aware of any simple way for an individual to get access, so wait I shall 😀

[ghost]

Given Raspberry Pi gave the CM4 a different, presumably more costly, PHY compared to the Pi 4, specifically to support IEEE1588-2008 I find it somewhat surprising that they don't appear to be doing anything about adding Linux support for this feature. Of course, they could be working on it and just not saying anything publicly.

[ahmadexp]

I am working with them directly on this issue. Expect some good news soon.

[lasselj]

Hi,

As I happen to make something called "Timebeat", I just wanted to leave a note about the "Pi210" configuration and benchmark. With an i210 in the PCIe slot and a kernel that supports HW_TS, it can achieve quite good accuracy: +/-10ns on the PHC, +/-50ns on the system clock.

Attached are some screenshots in case anyone cares.

For the addition of HW_TS capability to the ethernet controller on the CM4, I guess I would say that it is important to implement the gettimex64 call as PTP_SYS_OFFSET_EXTENDED will otherwise not be available. The difference between the accuracy of PTP_SYS_OFFSET_EXTENDED and PTP_SYS_OFFSET is about two orders of magnitude as it relates to synchronising the system clock from the PHC.

In case anyone working on this wants to test, then let me know and I'll make available the arm64 version of Timebeat.

All the best,

Lasse

[geerlingguy]

@lasselj - I added a new issue to track the I210 in my PCI Express card site since it looks like you have the first instance of a verified working card in a Pi CM4: https://github.com/geerlingguy/raspberry-pi-pcie-devices/issues/204 (I know others have mentioned it...). I may try picking one up to see if I can get it working with the Time Card.

I asked there but I'll also ask here—did you just install Intel's driver directly, or did you have to do any other steps to get the card working correctly?

[lasselj]

@geerlingguy Yeah, actually I got it because I wanted to complete the work started by @cfdez-tech for hwts on the onboard ethernet controller, but @ahmadexp makes me feel like it's not going to be time well spent. Attached the kernel config diff. Wasn't sure what option actually included the igb driver so probably more in it than is required.

i210.txt

[JohnnyBBravo]

I am working with them directly on this issue. Expect some good news soon.

Any updates perhaps?

[cfdez-tech]

Sorry, no updates from our side. Development is halted.

Carlos Fernández Embedded Linux Engineer Technica Electronics Barcelona Av. de la Via Augusta, 15-25 Sant Cugat del Vallès, Barcelona, 08174

Tel: +34 933959156

[cid:37b38b35-eb5b-4c4d-ad16-aaed1d2efd71]

---

From: JohnnyBBravo @.> Sent: Monday, October 11, 2021 7:41 PM To: raspberrypi/linux @.> Cc: Carlos Fernandez @.>; Mention @.> Subject: Re: [raspberrypi/linux] CM4 is missing IEEE1588-2008 support through BCM54210PE (#4151)

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

I am working with them directly on this issue. Expect some good news soon.

Any updates perhaps?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/raspberrypi/linux/issues/4151#issuecomment-940223846, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ATFJWPPRAFZZQJ72HWK24MTUGMOT3ANCNFSM4XWOSD6Q. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[rlseaman]

A native CM4 carrier board supporting timekeeping features as discussed here, perhaps a variant of Time Card (https://github.com/opencomputeproject/Time-Appliance-Project/tree/master/Time-Card), would be great. Alternately, we're a Meinberg shop and I plan to contact them about an arm64 driver for their IRIG PCIe card. But in the meantime there is a very functional TimeHat (https://millerjs.org/timehat) that I have running on a CM4 as well as Pi4, Pi3, and zeros. This includes a mini TimeHat version about the size of the u-blox daughter card in the photos at the link. It would be great to get this development un-halted and enable hardware time stamping. There's clearly a lot of interest given this thread!

[JohnnyBBravo]

I am working with them directly on this issue. Expect some good news soon.

@ahmadexp Has there been any progress perhaps?

[laf0rge]

Another few months without any update here.

It's really sad that Broadcom just doesn't simply release the related register-level manual and as a result deprives CM4 users from productively/efficiently working on the related driver support for hardware timestamping.

[ahmadexp]

Trust me, I have been working on these behind the scene. There is a long chain of approval that I have been going through to get this to become a reality.

Sent from my iPhone

On Dec 11, 2021, at 10:49 AM, Harald Welte @.***> wrote:

 Another few months without any update here.

It's really sad that Broadcom just doesn't simply release the related register-level manual and as a result deprives CM4 users from productively/efficiently working on the related driver support for hardware timestamping.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[eric957]

The Mini Router/PC is a box from Seeedstudio which packages a CM4 with dual ethernet ports, the second being USB3 based. They claim 1588 compatibility on the first port but I doubt it’s actually working. Has anybody had any experience with it ?

[ainguraXmarquiegui]

@eric957 , are you talking about this? https://www.seeedstudio.com/CM4-Router-Board-p-5211.html

I don't find any mention to 1588, can you point out where you found that information?

[eric957]

@ainguraXmarquiegui Its rather there: https://www.seeedstudio.com/Dual-GbE-Carrier-Board-with-4GB-RAM-32GB-eMMC-RPi-CM4-Case-p-5029.html. Scroll down, the table under "Compute Module 4" mentions IEEE1588. I have asked a question in the FAQ part (mentioning this page we’re writing) but they haven’t answered. It looks like they just copy-pasted the CM4 specs. I have ordered this part, so I should be able to test.

[nullr0ute]

@ainguraXmarquiegui Its rather there: https://www.seeedstudio.com/Dual-GbE-Carrier-Board-with-4GB-RAM-32GB-eMMC-RPi-CM4-Case-p-5029.html.

It states "Onboard Gigabit Ethernet PHY supporting IEEE1588" which is the same one being discussed here. The HW may be capable of supporting it, the driver does not currently.

[ydirson]

It looks like several devs worked on this feature, it would be great if they could share their current work, so other interested parties can contribute and the time they spent on this work is not completely wasted ;)

[KyleJudd]

IT WORKS!!! kinda...

Thank you cfdez-tech for getting this started.

I took cfdez-tech 's code and worked out some of the issues he mentioned, and my ExtremeNetwork X430-8P says my CM4 is "asCapable" with a stable peer-delay of 200 nsecs. I believe this is enough to confirm that the CM4 PHY does have hardware timing features and that they work properly.

That being said, I see some performance issues when I compare it to the i210, so its possible that what looks like an oasis might really be a mirage. For example, using test code I wrote, I can query the i210 time over 8000 per sec, but the bcm device responds only about 200 times per sec. Its just test code, I don't know if this creates a real problem in other people's code, but the difference is noticeable. Likewise, using the regular socket sendto() calls are a little sluggish compared to the i210.

I'd like to share the code back, but I'm not sure the best way to do that. I'm not really an expert on git or GitHub and would prefer not to use my own repositories. If cfdez-tech is available to work on this, I can send it to him, let him review this first, and he can merge it into his code base. If cfdez-tech is not available, perhaps someone from the Broadcom or raspberry pi team that can take control of this. If PTP is really working properly in my code, then the only thing left is to tune the driver for performance. That seems like something that should be done by someone at Broadcom, so that it is done exactly how they want it, not done by a linux-driver rookie like myself.

Let me know what you think and hopefully we can figure out the next step.

Kyle

[ydirson]

I'd like to share the code back, but I'm not sure the best way to do that.

The best way is to just fork cfdez-tech's repo and push your work there!

[ahmadexp]

IT WORKS!!! kinda...

Thank you cfdez-tech for getting this started.

I took cfdez-tech 's code and worked out some of the issues he mentioned, and my ExtremeNetwork X430-8P says my CM4 is "asCapable" with a stable peer-delay of 200 nsecs. I believe this is enough to confirm that the CM4 PHY does have hardware timing features and that they work properly.

That being said, I see some performance issues when I compare it to the i210, so its possible that what looks like an oasis might really be a mirage. For example, using test code I wrote, I can query the i210 time over 8000 per sec, but the bcm device responds only about 200 times per sec. Its just test code, I don't know if this creates a real problem in other people's code, but the difference is noticeable. Likewise, using the regular socket sendto() calls are a little sluggish compared to the i210.

I'd like to share the code back, but I'm not sure the best way to do that. I'm not really an expert on git or GitHub and would prefer not to use my own repositories. If cfdez-tech is available to work on this, I can send it to him, let him review this first, and he can merge it into his code base. If cfdez-tech is not available, perhaps someone from the Broadcom or raspberry pi team that can take control of this. If PTP is really working properly in my code, then the only thing left is to tune the driver for performance. That seems like something that should be done by someone at Broadcom, so that it is done exactly how they want it, not done by a linux-driver rookie like myself.

Let me know what you think and hopefully we can figure out the next step.

Kyle

If you like, share it with @jlemon

[KyleJudd]

The best way is to just fork cfdez-tech's repo and push your work there!

I agree, it makes sense to work through cfdez-tech's repo, but simply put, I just don't know how to do that. I'm a professional software developer with 20+ years experience, but I just haven't switched from SVN to GitHub, and some of the terminology is confusing to me. There are plenty of instructions on-line, but I want to take the time to learn the "right" way to do this.

Can someone please give me simple step-by-step instructions? So far I have "git clone" cfdez-tech's "bcm54210pe_ptp" branch to my local computer, modified the source, compiled and tested. What is the next step? Can I push this back into his repo as-is, or do I need to "git clone" a clean version, modify the source, so that object files and such are not pushed back to cfdez-tech's repo? Does he get a chance to review and approve what I push or will my changes appear immediately on his repo?

If I can get simple/clear instructions, I can work on this tonight or tomorrow. I can figure it out for myself, but I want to make sure I don't step on other people's toes. Thanks for your patience.

[gnomon-]

[snip]

If I can get simple/clear instructions, I can work on this tonight or tomorrow. I can figure it out for myself, but I want to make sure I don't step on other people's toes. Thanks for your patience.

@KyleJudd , I can help out here. I think we're both in North America, on the east coast, so I think our timezones likely overlap pretty well. Is there any chance you're on liberachat, or reachable via some other realtime comms service? I can give you a hand. (The process isn't complicated but the terminology acquisition might be a bit bewildering, so I worry that sending step-by-step instructions might introduce a multistage back-and-forth that would prove to be much more frustrating than a brief interactive session.)

[neggles]

Can someone please give me simple step-by-step instructions? So far I have "git clone" cfdez-tech's "bcm54210pe_ptp" branch to my local computer, modified the source, compiled and tested. What is the next step? Can I push this back into his repo as-is, or do I need to "git clone" a clean version, modify the source, so that object files and such are not pushed back to cfdez-tech's repo? Does he get a chance to review and approve what I push or will my changes appear immediately on his repo?

If I can get simple/clear instructions, I can work on this tonight or tomorrow. I can figure it out for myself, but I want to make sure I don't step on other people's toes. Thanks for your patience.

The steps here are quite simple;

1. Go to the repository you cloned's page on GitHub and click the "Fork" button in the top-right; this will create a copy of the repo under your account and take you to that page.
2. Copy the clone URL for this newly-forked repo (likely to be https://github.com/KyleJudd/linux.git or git@github.com:KyleJudd/linux.git if you are using Git over SSH)
3. In your local copy of the repository, run the following commands:

git remote rename origin upstream

This will change the name of the 'remote' (the git term for an external copy of a repository) from 'origin' (the default) to 'upstream', which is the name conventionally used for the source repository of a fork.

git remote add origin https://github.com/KyleJudd/linux.git

This will add your own fork of the repository as a new remote named 'origin'.

If you have not already committed your changes to the repository - I suspect you will have, but just in case - do the following:

git add .

This 'stages' changed files in preparation for a commit.

git commit -m "commit message"

This commits the changes to the repository - alter the commit message as you see fit

If your local changes were applied to the same branch, i.e. you have not run git branch prior to committing changes, optionally run the following to rename your local branch:

git branch -m new-branch-name

Perhaps use bcm54210pe_ptp-update or cm4-ptp-kylejudd or something along those lines, up to you, just don't reuse an existing branch name.

Finally, push your updated branch to your own copy of the repo:

git push -u origin new-branch-name

This will upload your changes to a branch on your fork of the repository.

This process does not make any changes whatsoever to the original repository - you cannot modify the repositories of other users without permission, so that's not something you need to worry about. Once you have pushed your changes, you do have the option to submit your branch to the original via a pull request - this allows the original repository owner to assess your changes and decide whether they wish to accept and merge them into their own branch - but that's not necessary.

Once the git push finishes, you will find your branch available at https://github.com/KyleJudd/linux/tree/new-branch-name 😄

I hope I have been clear enough - more details can be found in github's support/help docs, as well as git's own documentation, if you'd like more details about what the above does. 🚀

[KyleJudd]

Ok, we are making progress. Thanks gnomen for offering to help, thanks neg2led for the detailed description. That is what I needed and I think I understand the GitHub process now.

The last issue to resolve is that I want to make sure that, if I do this on my own GitHub account, I am not publishing information that Broadcom considers confidential or proprietary. I know the register information needed to make drivers is found in documentation that Broadcom keeps private and releases only with an NDA. It would be great if someone from Broadcom could either give permission or object, so that we know what we can and can not do.

For that reason, it seems best for me to fork cfdez-tech's repo to a private repo on my account, make my changes, then do a pull request so cfdez-tech can merge the changes himself. If I get confirmation that everything is public domain, I can make my repo public.

But don't worry, if this takes more than a day or two to figure out, I can post instructions on how to modify cfdez-tech's code to make it work

Thanks - Kyle

[neggles]

The last issue to resolve is that I want to make sure that, if I do this on my own GitHub account, I am not publishing information that Broadcom considers confidential or proprietary. I know the register information needed to make drivers is found in documentation that Broadcom keeps private and releases only with an NDA. It would be great if someone from Broadcom could either give permission or object, so that we know what we can and can not do.

FWIW, you're not going to get anything resembling a response from Broadcom - certainly not here. They generally maintain a wall of silence when it comes to the open-source community, as you can tell from the length of this thread + the fact it's been almost 18 months since the CM4 was released and, despite the spec sheet proudly proclaiming PTP/IEEE 1588v2 support in hardware, no driver (official or otherwise) has materialized.

While some details about the chip may be covered under an NDA/confidential, you personally have not signed an NDA or seen the confidential documents in question - they can hardly accuse you of breaking an agreement you didn't ever sign, or sharing information you were never provided.

On top of that, and perhaps more importantly, all of the code in the repository (being part of the Linux kernel) is licensed under GPLv2 or another compatible/less-restrictive license; you can see this at the top of the source code files, e.g. the first line of bcm54210pe_ptp.c has an SPDX license identifier of GPL-2.0+ present.

I'm sure you're at least somewhat familiar with the GPL, but just for the sake of completeness, code released under GPLv2 can be freely shared, modified, and re-shared by anyone - you are free to do whatever you like when it comes to posting/sharing GPL sources publicly, as long as you maintain the GPL licensing and follow a few other rules. The whole point of copyleft licenses is to make sure source code is shared, after all 😝

One other note:

For that reason, it seems best for me to fork cfdez-tech's repo to a private repo on my account, make my changes, then do a pull request so cfdez-tech can merge the changes himself. If I get confirmation that everything is public domain, I can make my repo public.

This is not actually possible; all pull requests opened on a public repository are also public, so you can't open a PR from a private repository to a public one - in doing so you'd have to make the PR's contents public as well, which would defeat the purpose of opening it from a private repo.

[cfdez-tech]

Hi all,

Seeing the current NDA discussion, first of all I must say thanks to all people getting this working, especially @KyleJudd @gnomon- and all of you. Unfortunately, for the moment I must close this branch waiting for future license movements, I don't want to make it wrong and spoil all of our work.

Please feel free to let me know your advances. I can integrate them and, maybe in the future (le'ts hope), we can make it public. I'll let you know as soon as I can met this public again.

Thanks for your efforts,

[cfdez-tech]

PS: @KyleJudd if you want to, please feel free to contact me at carlos.fernandez@technica-engineering.de maybe, I think, we can find a solution.

[KyleJudd]

Good to hear from you cfdez-tech. I'll email you directly and share my work and we can discuss this further

Thanks neg2led, I think your comments about GPLv2 and licensing are correct, but the question is what exactly has Broadcom publicly released. If there is leaked information on the internet that Broadcom did not release under GPLv2, Broadcom still has a right to stop that info from being shared.

My intention is to get a working PHY driver included into the main raspi kernel so that everyone in the world can have access to it. But that will never happen if we are working against Broadcom instead of working with Broadcom, and vice versa. I'm optimistic that the licensing/documentation could be worked out in a few days or weeks.

Like I said in my first post, my solution works with my AVB/PTP switches (ExtremeNetworks & MOTU), but there are still issues that prevent it from working as well as the i210. I think we will need more info from Broadcom to resolve those issues and make it a viable product. I do know that sharing my progress in this discussion will encourage other developers to "figure it out themselves", so that's good too.

I'll communicate with Carlos and report back.

[marcohabeck]

I'm happy to hear that there are successes. But I'm less optimistic, see the Linux kernel licensing rules. You won't get clearance from Broadcom because you won't find anyone who is authorized. Anything you release based on knowledge based on the NDA will be prohibited by Broadcom. There are reasons why Broadcom does not provide a driver for public linux. I suspect that the PHY is working poorly and your tests already indicate that.

Yes, for 18 months a product has been advertised with functions that it does not have. In addition, this product is not available. There are alternatives, not for the price but with excellent support.

Raspberry Pi Foundation also doesn't have enough power as a customer to push Broadcom to release it. It's funny that nothing has been heard from the official side for 18 months. An example of choosing the wrong hardware during development.

[ydirson]

There are alternatives, not for the price but with excellent support.

If all you're looking for is PTP with hardware timestamping on a SBC, I was able to see it work on a Maaxboard, and I suspect a number of other iMX8 boards will too. It works our of the box with the Debian image they provide (just need to add the necessary packages).

[KyleJudd]

You could be right marcohabeck, but there could be other explanations as well. To be funny, there probably is someone already working on the CM5 and maybe Broadcom intends to release the CM5 with PTP/AVB features far supperior to even the i210. Perhaps enabling the CM4 would prevent people from buying the superior CM5, and its really in our own best interest to be patient :)

Perhaps someone at Broadcom is already reading this thread and just needs one or two more days to respond. Perhaps that person is on vacation and will be back Monday to help us out. :)

Who knows.

Remember though, you can still stick a i210 in the pci slot and use it with your CM4. Broadcom delivered that, even though it may be against there own interests. Its not that you can't do PTP/AVB with the CM4, you just need to use an Intel product to do it.

I think the performance issues I mentioned are really an issue of knowing the correct registers and modes to use, and I just don't have the documentation for that. I think this is really just a job for a Broadcom engineer to fix, because they would know the best way to do it, and they're getting paid for that, and Broadcom can profit from that.

[KyleJudd]

I'm not familiar with the Maaxboard/iMX8 stuff. What nic/mac/phy do they use? I didn't see that info on there product page.

[marcohabeck]

TSN support is still a long way off. Except for a few experiments, I don't see any projects that would be really viable. Especially since this support has to be in the kernel. This has been included in macOS since 2013, and little has changed under Linux for years.

PTP is also only part of what is needed. Qos, SRP and much more is also required. Without the support of the hardware, this is not possible. As long as the corresponding information is under the NDA, this is not possible.

You could try swapping the PHY, but the choice of pin-compatible ones is slim.

If you don't get in trouble as well, Broadcom could claim part of their success came from information from the NDA.

[KyleJudd]

Give me a project board with a build in i210 and I'll go away and stop bothering people:)

[JamesH65]

You could be right marcohabeck, but there could be other explanations as well. To be funny, there probably is someone already working on the CM5 and maybe Broadcom intends to release the CM5 with PTP/AVB features far supperior to even the i210. Perhaps enabling the CM4 would prevent people from buying the superior CM5, and its really in our own best interest to be patient :)

Perhaps someone at Broadcom is already reading this thread and just needs one or two more days to respond. Perhaps that person is on vacation and will be back Monday to help us out. :)

Who knows.

There seems to be some misunderstanding here. Broadcom have nothing to do with Raspberry Pi board designs, they don't design the boards, that is entirely down to Raspberry Pi. Raspberry Pi do use Broadcom products on their boards, the SoC has inbuilt ethernet, but Broadcom write all the drivers for that IP.