BBB Kernel Config

Hi,

I am new member on this board and want some help, I have not much experience on building kernels.

I want to edit the config of my existing kernel locally on BBB. The kernel I use is 4.19.94-ti-rt-r70 and want to enable the PHY_TIMESTAMPING. I am telling this because I have continues received delay_req without timestamp and from some search it seems that the timestamping is not enabled. This is only when having HW timestamps on software there is no problem.

Some instructions how to do the sequence will be much appreciated.

Regards,
Jim

Hi @jnk19 it’s here:

Our production config is here:

Regards,

Thank you for your answer. I see that this module is not build on the kernel. Is there a big problem to add it on newer version or if you can tell me how to config the kernel and add them.

Or maybe on TI RT kernel is enabled with an other way.

The modules are:

`CONFIG_PTP_1588_CLOCK=m`
`CONFIG_NETWORK_PHY_TIMESTAMPING=y`

Regards.

Build testing right now:

CONFIG_PTP_1588_CLOCK was already enabled, guess we just missed the timestamp option…

Regards,

That is good news :grinning:

Will these be available if I do a kernel update via update_kernel.sh?

Regards.

EDIT

Is needed any additional drivers or modules on kernel for PHY of BBB to have PTP v2 support?

Yes it is better now but the received delay_req without timestamp has not stopped. It happens only on Unicast delay request on Multicast is normal and working. Also tried to work with PTP v1 without success. It gives me this error ioctl SIOCSHWTSTAMP failed: Numerical result out of range . It must be a bug with drivers or something is not enabled.

Also if this is a not big problem can the CONFIG_NETWORK_PHY_TIMESTAMPING=y be enabled and on 5.10.90-ti-rt just to make a test?

Best regards.

I’ve made things a little easier:

I’ll add that option to both 5.4/5.10…x

Regards,

1 Like

Thank you for the response.

I will try with all the kernels and see, waiting for updating them. Hoping with some branch might have fixed this problem. I will report back.

Regards.

Ok I will take it from the start.

After the timestamp patching on kernel the things not going too well as I expected.

On kernel 5.10 ti rt the timestamp is still not enabled (maybe be buggy).

Capabilities:
** hardware-transmit**
** software-transmit**
** hardware-receive**
** software-receive**
** software-system-clock**
** hardware-raw-clock**
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
** off**
** on**
Hardware Receive Filter Modes:
** none**
** ptpv2-event**

On kernel 5.4 ti rt it seems to be activated the timestamps, but the performance is the same as 5.10 ti rt. So in reality might not be activated.Also the HW timestamp can not be started at all,only Software timestamp is working.

Capabilities:
** hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE)**
** software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE)**
** hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE)**
** software-receive (SOF_TIMESTAMPING_RX_SOFTWARE)**
** software-system-clock (SOF_TIMESTAMPING_SOFTWARE)**
** hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE)**
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
** off (HWTSTAMP_TX_OFF)**
** on (HWTSTAMP_TX_ON)**
Hardware Receive Filter Modes:
** none (HWTSTAMP_FILTER_NONE)**
** ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT)**

On kernel 4.19 ti rt the things are a bit better, the timestamps seems to be activated with some better performance but again not to be ok. Also some clocks are activated also.

Capabilities:
** hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE)**
** software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE)**
** hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE)**
** software-receive (SOF_TIMESTAMPING_RX_SOFTWARE)**
** software-system-clock (SOF_TIMESTAMPING_SOFTWARE)**
** hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE)**
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
** off (HWTSTAMP_TX_OFF)**
** on (HWTSTAMP_TX_ON)**
Hardware Receive Filter Modes:
** none (HWTSTAMP_FILTER_NONE)**
** ptpv1-l4-event (HWTSTAMP_FILTER_PTP_V1_L4_EVENT)**
** ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT)**

With all the kernel when I start ptp4l the ptp0 clock can not be activated or read on bullseye. On buster can be read without any problem.

The latency from the PTP receiver to the BBB is drifting real bad. It is above 0.5ms and on some occasions it completely lose the packets either with HW or software timestamping. I have tried also the free running mode, it is a little better but not correct.

Also when having Unicast delay requests it drops the packets with an error received DELAY_REQ without timestamp on all kernels.

I tried PTP v1 also which can not be started at all and give me the error:

ptp4l[1276.027]: driver rejected most general HWTSTAMP filter
ptp4l[1276.035]: ioctl SIOCSHWTSTAMP failed: Numerical result out of range
ptp4l[1276.039]: port 1: INITIALIZING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)

and this is also with tx_timestamp_timeout 400

In conclusion something is not working correct on kernel (drivers or modules) or something is not enabled or need update. I think some investigation should be done. The device has the possibilities but it seems not be working as expected. The same test has be done with BBB industrial with same results. The best solution as it is now is with 4.19 ti rt kernel.

Maybe to be tried is also with

nohz=off

on kernel config to disable the ticks on idle and provide the highest accuracy, if this can be configure on kernel for test.

Regards.

Yeap that did the trick.

When starting ptp4l the ptp0 device is not self working at RT so you have to do it manually. For some unknown reason yet. This is on buster release.

Testing it at 4.19 ti rt.

The latency has improved much. Even with free_running off.

Not fixed the other problems but fixed the latency.

Regards

@jnk19 thinking genericlly should we globally do nohz=off? i think for our single core AM335x would clock accuracy be more important then saving a little bit of power?

A few years ago power would have been important, but today really need to push the am335x to it’s full potential to keep up with other faster devices…

Edit: in 5.10.x we have:

CONFIG_NO_HZ_COMMON=y
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set

One option?

 # Timers subsystem
 #
 CONFIG_TICK_ONESHOT=y
-CONFIG_NO_HZ_COMMON=y
-# CONFIG_HZ_PERIODIC is not set
-CONFIG_NO_HZ_IDLE=y
+CONFIG_HZ_PERIODIC=y
+# CONFIG_NO_HZ_IDLE is not set

Edit:

There is also a boot parameter "nohz=" that can be used to disable
dyntick-idle mode in CONFIG_NO_HZ_IDLE=y kernels by specifying "nohz=off".
By default, CONFIG_NO_HZ_IDLE=y kernels boot with "nohz=on", enabling
dyntick-idle mode.

So CONFIG_NO_HZ_IDLE forces nohz=on

Thoughts,

Correct CONFIG_NO_HZ_IDLE forces nohz=on also affects other things on devices (generally devices or processes that are on idle state).

The nohz option is the c-states of the kernel (power savings) which should be turn off. Specially if you are working with low latency settings.

But it may affect sometimes the performance of cpu depending the processes you are running,

In general on a single core cpu it should have better performance.

A test should be done to see the performance.

+CONFIG_HZ_PERIODIC=y
+# CONFIG_NO_HZ_IDLE is not set

I think that will do the trick.

EDIT

On kernel 5.10 and new generation kernels it is enabled probably because the hardware supporting it (newer devices) . In that case (AM335x) might need to disable the power savings on kernel to improve the performance.

Regards

1 Like

Here’s a quick test:

http://gfnd.rcn-ee.org:81/farm/bbb.io/CONFIG_HZ_PERIODIC=y/

This also gives us: Linux Kernel Driver DataBase: CONFIG_NTP_PPS: PPS kernel consumer support

Regards,

I have mixed comments so far.

On installing packages running processes it performs way better.

But when running a process on with RT scheduling (example ptp4l) when running suddenly the PHY is stopped and restart with an error:

port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
port 1: FAULTY to LISTENING on INIT_COMPLETE

It need more testing.

In general it seems to be better from before. It performs better.

As for this: Linux Kernel Driver DataBase: CONFIG_NTP_PPS: PPS kernel consumer support if get enabled then you can have sync with external PPS (it might be GPS). It should be enabled if want to work with boundary clocks with PTP or synchronize NTP via PPS .

It is a must I think.

I will report back.

Regards.

I think that with config something goes wrong.

I see high kernel usage almost to 100% and bottleneck the cpu.

The rsyslogd using this very high.

For using ptp4l not this config.

I think not touch this:

-CONFIG_NO_HZ_COMMON=y
-# CONFIG_HZ_PERIODIC is not set
-CONFIG_NO_HZ_IDLE=y
+CONFIG_HZ_PERIODIC=y
+# CONFIG_NO_HZ_IDLE is not set

Regards.

Sorry to disturb I have an other question and might be possible to enable.

This flags can be added on the drivers if possible?

all (HWTSTAMP_FILTER_ALL)
ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC)
ptpv1-l4-delay-req (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ)
ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC)
ptpv2-l4-delay-req (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ)
ptpv2-l2-sync (HWTSTAMP_FILTER_PTP_V2_L2_SYNC)
ptpv2-l2-delay-req (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ)
ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT)
ptpv2-sync (HWTSTAMP_FILTER_PTP_V2_SYNC)
ptpv2-delay-req (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ)

The flags I have now via ethtool is that:

ptpv1-l4-event        (HWTSTAMP_FILTER_PTP_V1_L4_EVENT)
ptpv2-event           (HWTSTAMP_FILTER_PTP_V2_EVENT)

Regards,
Jim

Hi,
I was trying to get unicast G.8275.2 working on the BBB with linuxptp. I get the same error “received delay_req without timestamp” when I try hardware timestamping.

tp4l[2274.297]: port 1: MASTER to UNCALIBRATED on RS_SLAVE
ptp4l[2274.354]: timed out while polling for tx timestamp
ptp4l[2274.355]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[2274.356]: port 1: send delay request failed
ptp4l[2274.357]: port 1: UNCALIBRATED to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)

After reading “Support for E2E message types, IPv4 transport, and unicast negotation enables use of the Telecom profile. This is also supported by LinuxPTP, and may be configured using a configuration file similar to the one below: (Note: only supported on PRU-ICSS ports using DualEMAC, and supports slave side only)”
From 4.2. PTP — Processor SDK Linux for AM335X Documentation

I suspect the BBB will not support PTP unicast hardware timestamping. Would be nice to get unicast PTP working if possible. Might be a question for TI.

Regards
Eoin