[Random i2c outages / timeouts]

Hi there,

 

I have a little problem with my i2c-screen on the Helios4.

 

It was setup according to the Kobol-Wiki and was working right from the start. However after running for some time (in this example it took around 6 hours) the screen is black and empty.

 

Once I SSH back into the helios and restart the systemd sys-oled.service, it works again for some time...

 

"journalctl -u sys-oled.service" gives the following:

Sep 13 10:18:38 helios4 systemd[1]: Started System Starting on OLED Display.
Sep 13 16:46:01 helios4 python3[23009]: Traceback (most recent call last):
Sep 13 16:46:01 helios4 python3[23009]:   File "/usr/local/bin/sys-oled", line 158, in <module>
Sep 13 16:46:01 helios4 python3[23009]:     main()
Sep 13 16:46:01 helios4 python3[23009]:   File "/usr/local/bin/sys-oled", line 148, in main
Sep 13 16:46:01 helios4 python3[23009]:     display_info(device)
Sep 13 16:46:01 helios4 python3[23009]:   File "/usr/local/bin/sys-oled", line 130, in display_info
Sep 13 16:46:01 helios4 python3[23009]:     draw.text((0, 27), network(net_name), font=font, fill="white")
Sep 13 16:46:01 helios4 python3[23009]:   File "/usr/local/lib/python3.7/dist-packages/luma/core/render.py", line 43, in __exit__
Sep 13 16:46:01 helios4 python3[23009]:     self.device.display(self.image)
Sep 13 16:46:01 helios4 python3[23009]:   File "/usr/local/lib/python3.7/dist-packages/luma/oled/device/__init__.py", line 114, in display
Sep 13 16:46:01 helios4 python3[23009]:     self.command(set_page_address, 0x02, 0x10)
Sep 13 16:46:01 helios4 python3[23009]:   File "/usr/local/lib/python3.7/dist-packages/luma/core/device.py", line 48, in command
Sep 13 16:46:01 helios4 python3[23009]:     self._serial_interface.command(*cmd)
Sep 13 16:46:01 helios4 python3[23009]:   File "/usr/local/lib/python3.7/dist-packages/luma/core/interface/serial.py", line 91, in command
Sep 13 16:46:01 helios4 python3[23009]:     list(cmd))
Sep 13 16:46:01 helios4 python3[23009]:   File "/usr/local/lib/python3.7/dist-packages/smbus2/smbus2.py", line 643, in write_i2c_block_data
Sep 13 16:46:01 helios4 python3[23009]:     ioctl(self.fd, I2C_SMBUS, msg)
Sep 13 16:46:01 helios4 python3[23009]: TimeoutError: [Errno 110] Connection timed out
Sep 13 16:46:01 helios4 systemd[1]: sys-oled.service: Main process exited, code=exited, status=1/FAILURE
Sep 13 16:46:01 helios4 systemd[1]: sys-oled.service: Failed with result 'exit-code'.

 

Any hint / idea is highly appreciated.

 

[Helios4 - Cryptographic Engines And Security Accelerator (CESA) Benchmarking]

vor 11 Stunden schrieb sfx2000:

 

Armada 38x is fairly decent with CESA in specific use cases - and it's worth the effort perhaps to get it up and running (armbian, if I recall, doesn't enable it by default)

 

MV3720 is a different chip - and there, it's better to skip the CESA units, and go with software on the cores, IMHO...

Aaah ok, now I get it. You referred to the MV3720.. That makes sense.

Thanks for the update!

[Helios4 - Cryptographic Engines And Security Accelerator (CESA) Benchmarking]

vor 1 Stunde schrieb m4110c:

Thanks!

That means, it makes no sense to even use aes-cbc-essiv:sha256 anymore. Kobol Team is out of business so there will be no fix regarding this... I guess I'll do a cryptsetup benchmark and just use the fastest cipher it finds.

Strangely when running a `cryptsetup benchmark` I can see that the interrupt is  triggered:

 

 

Doesn't that mean that it's using CESA?

 

Also, I wonder why there is no interrupt activity on 49 but just on 48. Seems the distribution to both CPUs is not working..?

[Faster SD card support]

vor 24 Minuten schrieb Werner:

Most likely no

 

https://forum.armbian.com/topic/18844-kobol-team-is-pulling-the-plug

 

Thanks for the info!

[Helios4 - Cryptographic Engines And Security Accelerator (CESA) Benchmarking]

vor 11 Minuten schrieb jsr:

I'm on Armbian 21.08.2 Buster with Linux 5.10.60-mvebu and CESA is not functional.

 

Regards,

James

Thanks!

That means, it makes no sense to even use aes-cbc-essiv:sha256 anymore. Kobol Team is out of business so there will be no fix regarding this... I guess I'll do a cryptsetup benchmark and just use the fastest cipher it finds.

[Faster SD card support]

Hi,

any news about this?

It states in the wiki:

 

Zitat

From Linux Kernel 4.19 onwards, High Speed and UHS-I modes for Helios4 do NOT work. It requires further work on our side.

 

Will there still be work on "your" side, given that the model seems to be End-of-Life?

If not, is there any way we could still make it work? I would take the risk, especially since the wiki provides a recovery method....

[Helios4 - Cryptographic Engines And Security Accelerator (CESA) Benchmarking]

Double post, sorry.

(Why can't I delete my own posts?)

[Helios4 - Cryptographic Engines And Security Accelerator (CESA) Benchmarking]

Am 11.7.2020 um 07:50 schrieb sfx2000:

With CESA - many assumptions based on Armada 38x - where things in scope looked very good on ARM-V7A - both the Marvell cores and the later ARM-a9's... Armada is mixed up here... let's just say that 38x has massive bandwidth inside the chip - MV3720/Mochi doesn't...

 

MV3720 - always a tradeoff - more CPU and throughput, or offload to the CESA units, which is probably similar to other "off-loads" for dedicated accelerators

 

Personally - I would not recommend CESA here,,, I would recommend core here as the is CPU/MEM,  and CESA is limited, and so is the bus within the chip itself.

 

I don't understand this exatly. The poster above you found these values:

 - Plain access to disk: 180MB/s

 - LUKS2 + CESA: 140MB/s

 - LUKS2 (no CESA): 52MB/s

 

So I wonder how/why you think not using CESA is better here. From my point of view this seems to be a contradiction. Or is there something I don't see?

[Helios4 - Cryptographic Engines And Security Accelerator (CESA) Benchmarking]

I should add, that I'm using the NAS for storing large files that are almost only written, medium files that are written once and read from time to time, and small files that are read and written often.. 

[Helios4 - Cryptographic Engines And Security Accelerator (CESA) Benchmarking]

Hi there, 

 

I have a Helios 4 (last batch) and just wanted to ask if CESA is still not functional with the current Buster release? 

 

I'm in the midst of a new setup and wonder if I should even try to use CESA. 

 

Also one question for clarification:

 

Here in the forums, but also in the Kool-wiki, I it seems to me, that people are saying that CPU crypto is superior to CESA in terms of performance...

 

As I'm quite noobish regarding this, I would be very grateful for any recommendations. 

 

Thanks in advance!