AM3352: AM3352(SDK V9.1): Setting Date beyond 2038-01-19 is not working

Mukul: 

 Isn't this issue part of the overall Linux issue? https://www.reddit.com/r/linux/comments/18of33p/the_y2038_problem_explained/  So AM335x will stay on Linux base v 6.1.x with the SDK 9.3? 

I suspect the processors that are supported Sitara SDKs v 10.x with Linux base v 6.6.x also should get the 2038 issue supported? 

thanks

Jim

Hello Mukul:

The customer is urging us greatly, and it`s too long to wait until November.Is there a patch based on processor-sdk-09.01.00-legacy-config.txt that can solve the Y2038 issue?

In this link "">git.ti.com/.../, we found the  meta-ti: fix Y2038 issue  patch used for am57x-9.x. And the am57x-9.x is a sub-branch of kirkstone branch. Based on that,  we found the layer config file processor-sdk-09.01.00-config.txt in "https://git.ti.com/cgit/arago-project/oe-layersetup/commit/configs/processor-sdk?id=d5e365ff3883df74d6b7dab98c21abde2ce5922c" which is related to the meta-tisdk layer tag 09.01.00.08.

Now we are trying to apply the https://git.ti.com/cgit/ti-sdk-linux/meta-tisdk/commit/?h=am57x-9.x&id=05147498e307623efa85475f4fd2979d59452263 patch with processor-sdk-09.01.00-config.txt layer config file to verify Y2038 can be fixed or not ? Can you give us some suggestions.

Hello Ning,

Andreas has some links in that previous thread you found that might be helpful:
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1336931/am3352-setting-date-beyond-2038-01-19-is-not-working/5156910#5156910

Regards,

Nick

Hello Jim,

A couple notes:
 - y2038 only affects 32 bit processors like AM335x & AM437x
 - the Linux kernel itself is y2038 safe in kernel 6.1. The issue in SDK 9.1 is that some userspace code is not compatible with 64 bit time

Regards,

Nick

Hello, Mukul

The below link Andreas mentioned to update oe-core only has been tried, but it not take effect.
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1336931/am3352-setting-date-beyond-2038-01-19-is-not-working/5156910#5156910

So I would like to ask , do we need to add the meta-ti: fix Y2038 issue  patch used for am57x-9.x. in meta-tisdk layer meanwhile?

Hello Ning,

I will provide some general guidance here, but keep in mind that I CANNOT guarantee that everything will work here, since TI has not yet put together an AM335x SDK with a filesystem that is completely y2038 compliant.

First off, the developers have told me that the AM57x patch you found is more of a "hack" than a "complete" solution, and that it will probably NOT be sufficient to create a y2038 compatible AM335x filesystem on their own. https://git.ti.com/cgit/ti-sdk-linux/meta-tisdk/commit/?h=am57x-9.x&id=05147498e307623efa85475f4fd2979d59452263

This is a really good description of y2038 and what it actually takes to ensure that your code is y2038 compliant, I highly suggest reading it before doing any other steps here: https://osseu2024.sched.com/event/1ej4C/surviving-19-jan-2038-on-32-bit-platforms-lessons-learned-and-common-problems-alexander-kanavin-linutronix 

Where the slides are here: https://static.sched.com/hosted_files/osseu2024/8b/EOSS%20Vienna%202024%20-%20Surviving%20Y2038.pdf

Basically, ANY code that uses 32 bits to store time can cause a y2038 issue. So the AM57x patch you found are intended to force SOME packages to use 64 bit time, but kirkstone specifically still has 32 bit time packages in it that you would need to be careful with.

That's another element of the AM57x SDK 9.2 that I will work with that team to better document - the default filesystem that comes with the SDK might be y2038 compliant, but you could still very easily make it NOT compliant by including the wrong package, or accidentally letting your userspace C code use a 32 bit time value instead of a 64 bit time value. It is up to the individual customer to test their code and make sure that the final product is y2038 compliant.

Regards,

Nick