@Eric-Katzfey we are using A doodle radio

Just found that reboot -f works.

It's interesting weird that the network interface seems to not go down but all the services do - and don't come back.

Any recommendations on how to reboot the VOXL2 from the ssh terminal?

It stops our mavlink router and ssh terminals when running reboot or reboot.sh

But I can still ping it's IP address, but the ssh and mavlink servers do not return.

Hi,

I'm curious if there is any ongoing work to update the native instruction sets into the kernel modalAI is building for the VOXL2.

Here is the current instruction set listed by the kernel. I'm having issue building newer projects that use the newer SIMD instruction sets provided by ARM. Here are most of the issues:

We are stuck with Ubuntu 18.04 - saw we are limited for the gcc version up to 8 (along side default gcc7.5) - there is a ppa that you can grab from to get up to the latest. I am able to run gcc-10 on the VOXL2, but the arm compiler march options aren't supported by the binutils 2.30 provided by Ubuntu 18.04. I maually built binutils to allow for assembly of those instruction sets.

The important ones are flagm, i8mm, and blfoat16 - they've all been back-ported by ARM in the linux kernel to support up to armV8.3 supported chips, which should be the Kyro (8 Cortex78 cores)

At the very least we should have the instruction sets available in the kernel, so that we can pass the march=native and get all of the cpu operations needed. This will go along way when trying to build latest and greatest AI frameworks like accelerated tensorflow lite, ONNX runtime, and pytorch.

These are the native extensions available to gcc are:

cat /proc/cpuinfo 
Processor	: AArch64 Processor rev 0 (aarch64)
processor	: 0
BogoMIPS	: 38.40
Features	: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer	: 0x51
CPU architecture: 8
CPU variant	: 0xd
CPU part	: 0x805
CPU revision	: 14

If we could port some of the updates from the official linux arm64 kernel to the modalAI kernel

Is this even possible to start cherry-picking these updates? I also see that qualcomm is developing or releasing a newer versionof the kernel?

I see that the default is qrb5165-ubun1.0-14 but under the package manager and createpoint I saw development for qrb5165-ubun2.0 - was curious if there was a known difference.

If I get pointed in the right direction I'd be glad to help out. I want to make sure we can run all the latsest and greatest neural nets and these SIMD instructions are the key.

@mrawding Just answering my own forum for those who don't have access to internet based NTP server. A few solutions to stop it being synced back to Dec 15 2021

1. Run a local NTP server on the groundstation

2. If running a timesync service like chrony - write a system service to detect a difference between the system time and the last modification time of /var/lib/systemd/timesync/clock and then running touch /var/lib/systemd/timesync/clock to reset this time - probably 1-5s daemon rate would make sense.

@Eric-Katzfey Thanks for the response. Chrony is our timesync service we use, but it doesn't stick after reboot. I'll have to look into mimicking the NTP sync in a different service. Thanks!

I'm trying to debug a kernel issue that seems like it is rebooting on kernel panic. I see that the parameter is set to -1 (reboot immediately) , which I changed to 0 (disable). But viewing the journalctl logs is quite annoying. Especially since the date is always set to Dec 15 2021.

I see there might be RTC support in the kernel setting the /dev/rtc0 clock to beginning of UTC time.

Dec 10 09:15:49 voxl kernel: rtc-pm8xxx c440000.qcom,spmi:qcom,pm8150@0:qcom,pm8150_rtc: rtc core: registered pm8xxx_rtc as rtc0
Dec 10 09:15:49 voxl kernel: rtc-pm8xxx c440000.qcom,spmi:qcom,pm8150@0:qcom,pm8150_rtc: setting system clock to 1970-01-01 00:00:05 UTC (5)

So couple questions

1. Is that actually a RTC or is it virtual?
2. Where is Dec 15 2021 set? Is it in the BIOS? I can't find it anywhere.
3. timedatectl set-time does not stick after reboot, guessing date is defaulting to BIOS
4. How can I modify BIOS either pre/post firmware flash to update the time I want?

@Moderator I just tried running those instructions for VOXL1 build, but have an issue downloading the manifest package from codeaurora.

I posted an issue here about it. Please let me know if there is an update!

@Eric-Katzfey Hi Eric, any update on this release?

Hi all,

I am also interested in connected FLIR Boson to VOXL2 - is it recommended to use the JST USB3.0 port on the 5G expansion board or the USBC/adb port.

Also if it is the JST port - are there any recommended breakout cables to purchase?

Lastly, do you know if the supported FLI Boson mentioned in the specifications matrix is the 320 or 640 - and if it was tested with USB 2.0

Great. I'm not sure if this is helpful or just an example of what NOT to do.

So I actually found that the userdata error was caused by some sort of permissions error.

It seemed that elevating my user to root permissions with sudo su worked best but maybe sudo could work.

For some reason, I guess the fastboot byte stream gets altered when not executing from root even though my user has permissions for USB and can run almost any fastboot command without sudo. It is strange since a full flash has worked multiple times before seeing this userdata failed partition write

Anyways, after finally getting past the userdata issue - I found that my device was constantly in fastboot mode and could write to both boot partitions with

fastboot flash boot_a <img>
and
fastboot flash boot_b <img>

Although actually booting caused this issue

fastboot flash boot <img>

downloading 'boot.img'...
OKAY [  0.613s]
booting...
FAILED (remote: Failed to load/authenticate boot image: Device Error)
finished. total time: 0.614s

I realized after looking through my bash history that I ran a command that is no bueno.

fastboot --set-active=b which changed the boot slot.

I then changed it back to fastboot --set-active=a and now the device works as it should.

I just figured I should post this so people can have more clarity on what NOT to do in case you have a feeling that your device is corrupted or something is wrong with the bootloader.