thud, warrior, zeus support

[floion]

Hi. Do you plan to add any or all of the above branches? Also, I see https://wiki.embeddedarm.com/wiki/TS-4900_Kernel_Compile_Guide mentions a newer kernel. Any plan to also add the new kernel to any of these future branches and / or to also the existing sumo branch if support for thud, warrior, zeus would take too long?

Thank you

[vicgal]

Hi. Do you plan to add any or all of the above branches? Also, I see https://wiki.embeddedarm.com/wiki/TS-4900_Kernel_Compile_Guide mentions a newer kernel. Any plan to also add the new kernel to any of these future branches and / or to also the existing sumo branch if support for thud, warrior, zeus would take too long?

Thank you

Hello @markfeathers,

We are in the process of updating most of our supported boards to thud or warrior. Do you have any updates on the above? Kind regards

[markfeathers]

Hello,

At the moment we do not have firm plans on when we will have a new yocto. I expect it to happen, but I do not have a planned date when we would update to the latest.

[floion]

Thanks for getting back. In this case, is there anything preventing you to switch to the newer kernel on the existing sumo branch?

[markfeathers]

There is no limitation I'm aware of. Our 4.9 kernel just didn't exist when I made the sumo branch, but I expect it should drop in the same.

[floion]

I see. So will you do the switch to it in your layer?

[vicgal]

Hi @markfeathers,

Friendly reminder about this. We would like to do the thud/warrior update of balena-ts and it would be great if we could have the newer kernel.

Regards

[markfeathers]

Hi @vicgal, I just pushed this change to sumo to support this 4.9.11 kernel. Let me know if this is sufficient. I can ask around here if a warrior port is otherwise required.

[floion]

Hi @markfeathers thanks a lot. This is good for now until you add support for thud or warrior

[floion]

@markfeathers I am testing the 4.9.11 kernel and there seem to be some problems with rtc. Specifically these errors:

dmesg|grep -i rtc

[ 2.157414] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 [ 2.164323] rtc-isl12022 0-006f: rtc core: registered rtc-isl12022 as rtc0 [ 2.774534] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 [ 2.781194] rtc-isl12022 0-006f: hctosys: unable to read the hardware clock [ 17.868323] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 [ 18.768597] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 [ 101.085323] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 [ 106.492270] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 [ 108.344920] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 [ 203.150696] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 [ 236.904338] systemd-udevd[30]: starting version 215 [ 238.125040] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 [ 238.134904] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 [ 238.151495] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6

journalctl --no-pager -u timeinit-rtc.service

-- Logs begin at Fri 2020-01-24 15:54:51 UTC, end at Tue 2020-01-28 10:30:21 UTC. -- Jan 24 15:55:01 localhost hwclock[750]: hwclock: RTC_RD_TIME: Input/output error Jan 24 15:55:01 localhost systemd[1]: timeinit-rtc.service: Main process exited, code=exited, status=1/FAILURE Jan 24 15:55:01 localhost systemd[1]: timeinit-rtc.service: Failed with result 'exit-code'. Jan 24 15:55:01 localhost systemd[1]: Failed to start Initialize system clock from RTC.

timedatectl

[ 101.085323] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 Failed to query server: Failed to read RTC: Input/output error

I do see the rtc device created in /dev:

ls -al /dev/rtc*

lrwxrwxrwx 1 root root 4 Jan 24 15:55 /dev/rtc -> rtc0 crw------- 1 root root 253, 0 Jan 24 15:55 /dev/rtc0

On the previous 4.1.15 I see no devices in /dev. Also, I see a somewhat similar rtc error in dmesg there too: dmesg | grep -i rtc

[ 1.906747] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-5 [ 4.040668] hctosys: unable to open rtc device (rtc0)

But timedatectl works as expected there:

timedatectl Local time: Tue 2020-01-28 10:49:06 UTC Universal time: Tue 2020-01-28 10:49:06 UTC RTC time: n/a Time zone: n/a (UTC, +0000) System clock synchronized: yes systemd-timesyncd.service active: n/a RTC in local TZ: no

Are you aware of any such issues in the new 4.9.11 kernel?

[supercalhotas]

Hi there,

i'm testing the 4.9.11 on a ts7970, and it seems to work fine here:

root@exeggutor:~# dmesg | grep rtc [ 1.761378] rtc-ds1307: probe of 0-0068 failed with error -5 [ 1.763359] rtc-isl12022 0-006f: voltage dropped below 85%, date and time is not reliable. [ 1.763588] rtc-isl12022 0-006f: rtc core: registered rtc-isl12022 as rtc0

root@exeggutor:~# hwclock -r [58104.501063] rtc-isl12022 0-006f: voltage dropped below 85%, date and time is not reliable. Fri Feb 28 09:09:59 2020 0.000000 seconds

regards

[fredwbacon]

The current zeus branch for meta-ts is specifying the tsimx-linux branch named ts-imx_4.9.11_1.0.0_ga, but the revision it specifies is from the test/ts-kris/yocto-testing branch. How stable is this testing branch? I'm attempting to leap frog several versions to bring our hardware up to date. We're running on a TS-4900 board.

[floion]

@supercalhotas thanks for the follow-up, I forgot to mention the issues is present on the ts4900

[markfeathers]

@floion Can you verify you have the /boot/ts4900-fpga.bin file? The FPGA is on the same I2C bus and might not handle these pins correctly unless it is loaded.

We have discussed this here and we will have a yocto zeus release soon for our i.MX6 platforms. I apologize this did not come sooner.

[ts-kris]

@fredwbacon

How stable is this testing branch? I'm attempting to leap frog several versions to bring our hardware up to date.

As long as this issue is open, the support is incomplete and subject to change at any time. As it is now, it builds and boots.

[floion]

Hi @markfeathers I have the fpga in the required location:

reading /boot/ts4900-fpga.bin 118642 bytes read in 31 ms (3.6 MiB/s) ICE40 FPGA reloaded successfully

Any other idea about what may be at fault here?

[floion]

@ts-kris can you share what branch you are building?

[ts-kris]

@floion Preliminary instructions for our Yocto Zeus can be found here: https://github.com/embeddedarm/ts-oe-bsp/tree/zeus

Note that these are still subject to change and we are still working out some of the changes for our documentation that have occurred in Yocto between versions.

[floion]

@ts-kris this will not build an SD card image that is ready to be burnt to the SD. Do you have that also?

[supercalhotas]

@ts-kris, so far so good! already done our flavor-images and i'll produce a bring up for a 7970 tomorrow and perform some tests. Do you have any troubles on your tests?

btw, faced this issue building perf on your 4.9.11 https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-kernel/perf?id=92469aad50b623afa423c19d82ed2e3c667c5e6a (hope that can be helpful for the others)

Regards

[ts-kris]

@floion I'm not sure what you mean. It generates a tarball located at "tmp/deploy/images/tsimx6/" that can be unpacked to the SD card or eMMC of your device. We do not offer disk images for the TS-4900 for Yocto releases.

@supercalhotas Networking has changed, we've not yet documented this. But when making .network files to configure interfaces via systemd-networkd, Yocto has added a default file for eth and en* interfaces. To configure those correctly, any added .network files must be named "XX-wired.network" where XX is a 2 digit number less than 80. Yocto now provides a buries "80-wired.network" default configuration that /etc/ can override if it is a similar name. Otherwise, no issues in testing so far.

[floion]

@ts-kris I just booted the image I built over the weekend. This is the image:

root@ts-imx6:~# cat /etc/os-release ID="poky" NAME="Poky (Yocto Project Reference Distro)" VERSION="3.0.2 (zeus)" VERSION_ID="3.0.2" PRETTY_NAME="Poky (Yocto Project Reference Distro) 3.0.2 (zeus)"

It was built using the instructions from the link you supplied. But I see the exact same errors:

root@ts-imx6:~# hwclock [ 78.202373] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 [ 78.209473] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 [ 78.217643] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 hwclock: ioctl(3, RTC_UIE_ON, 0) to /dev/rtc0 failed: Input/output error

and

root@ts-imx6:~# dmesg | grep -i rtc [ 5.314927] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 [ 5.321827] rtc-isl12022 0-006f: rtc core: registered rtc-isl12022 as rtc0 [ 7.134556] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 [ 7.141215] rtc-isl12022 0-006f: hctosys: unable to read the hardware clock [ 59.296058] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 [ 59.303145] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 [ 67.296047] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 [ 67.303129] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 [ 75.296048] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 [ 75.303246] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 [ 78.202373] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 [ 78.209473] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 [ 78.217643] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 [ 83.296074] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 [ 83.303184] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 [ 91.295919] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 [ 91.302911] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 [ 99.295418] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6 [ 99.302515] rtc-isl12022 0-006f: isl12022_read_regs: read error, ret=-6

I can share this image with you so you can maybe boot it on your board and verify this exact same image? Thank you

[ts-kris]

@floion I'm not able to reproduce this with the Yocto Zeus build. Tested on TS-8550-4900, TS-7990, and TS-7970 with the same image. The output below is from a TS-8550-4900.

root@ts-imx6:~# dmesg|grep -i rtc
[    5.318274] rtc-isl12022 0-006f: voltage dropped below 85%, date and time is not reliable.
[    5.326808] rtc-isl12022 0-006f: rtc core: registered rtc-isl12022 as rtc0
[    7.141149] rtc-isl12022 0-006f: setting system clock to 2020-03-17 19:36:53 UTC (1584473813)
root@ts-imx6:~# hwclock
2020-03-17 19:38:03.245801+00:00

root@ts-imx6:~# cat /etc/os-release 
ID="poky"
NAME="Poky (Yocto Project Reference Distro)"
VERSION="3.0.2 (zeus)"
VERSION_ID="3.0.2"
PRETTY_NAME="Poky (Yocto Project Reference Distro) 3.0.2 (zeus)"

You may have a hardware issue, but it is strange that it does not occur when you use an older image.

Also, please verify the coin cell battery is of sufficient charge. You may want to try disconnecting the battery, letting the RTC completely die, and then setting it again from the system time on the next boot and see how that performs.

If you have further issues with this, please submit an RMA request or reach out to our support team through support.embeddedarm.com

[floion]

Hi @ts-kris thanks for the follow-up. Can you tell me on the TS-8550-4900 combination, what was the revision of the ts4900 daughter board you tested with? I tested on Rev. D ts4900

[ts-kris]

@floion Rev. D TS-4900 and Rev. B TS-8550

[floion]

Thanks @ts-kris