Add meta-hailo support #569
Conversation
huaqianli
force-pushed
the
lee/hailo-card
branch
3 times, most recently
from
d71b261 to
57d9565
Compare
| > Note: `numpy==1.23.3` is preinstalled. Please do not upgrade it, as | ||
| > `hailort v4.18.0` requires this specific version. Upgrading `numpy` may cause | ||
| > `pyhailort` to fail to execute. |
There was a problem hiding this comment.
Will apt-upgrade updates it? If do, I bet you need a package pin config.
There was a problem hiding this comment.
You would need to pin it via apt preferences then. But that is security-wise a bad idea as well, thus this issue of hailo stack needs fixing.
There was a problem hiding this comment.
Currently, we are using Hailo V4.18, which officially requires numpy 1.23.3. Even if Hailo fixes this issue, they may not backport the fix to V4.18, making the situation quite challenging. There are significant differences between numpy 1.23 and 1.24, meaning that backporting the patches to V4.18 would require a substantial effort.
So far, IMHO, it would be a good choice for us.
There was a problem hiding this comment.
We are already patching hailo for other reasons. Key question is what is breaking when using a (distro-)maintained numpy version in their stack? Your version will not receive any updates (EOL in upstream, not under Debian maintenance), even if there should be bugs or even CVEs.
There was a problem hiding this comment.
I believe the issue is caused by the changes mentioned in the numpy 1.24.0 release notes:
https://numpy.org/doc/2.0/release/1.24.0-notes.html
There are also a large number of new and expired deprecations due to changes in promotion and cleanups. This might be called a deprecation release. Highlights are
Many new deprecations, check them out.
Many expired deprecations,
New F2PY features and fixes.
New “dtype” and “casting” keywords for stacking functions.There was a problem hiding this comment.
I suppose Hailort will require a bunch of modifications to eliminate the deprecations. Anyway I'll suggest Hailo to follow the numpy version of the Debian LTS.
recipes-bsp/u-boot/files/0015-TEMP-arm64-dts-ti-iot2050-Add-overlay-for-DMA-isolat.patch
Outdated
Show resolved
Hide resolved
huaqianli
force-pushed
the
lee/hailo-card
branch
3 times, most recently
from
af68e5c to
cbd7b7a
Compare
| hailo-firmware \ | ||
| hailortcli \ | ||
| python3-hailort \ | ||
| " |
There was a problem hiding this comment.
Why a separate CI image? Did the build time exceeded the limit on github?
You want to explain such details, at least in the commit message (reasoning, not feature-listing).
There was a problem hiding this comment.
same as above #569 (comment)
There was a problem hiding this comment.
That unfortunately makes no sense yet.
There was a problem hiding this comment.
ACK, I'll drop this and refine the commit message
recipes-kernel/linux/files/patches-6.1/0100-swiotlb-Make-IO_TLB_SEGSIZE-configurable.patch
Outdated
Show resolved
Hide resolved
huaqianli
force-pushed
the
lee/hailo-card
branch
3 times, most recently
from
a5ac6ac to
e0392a7
Compare
This commit integrates the following main components: - hailo-pci (OSS kernel module) - hailo-firmware (proprietary firmware for hailo8 chip) - hailort (Userspace Libraries) - hailortcli (tool) - hailort (service) - libhailort (c library) - libhailort-dev (dev package) - python3-hailort (python library) - libgsthailo (gstreamer element) Signed-off-by: Li Hua Qian <[email protected]>
Signed-off-by: Li Hua Qian <[email protected]>
Reserve a 64M memory region and ensure that all PCI devices do their DMA only inside that region. This is configured via a restricted-dma-pool and enforced with the help of the first PVU. Applying this isolation is not totally free in terms of overhead and memory consumption. It makes only sense for variants that support secure booting, and generally only when this is actually enable. Therefore model it as overlay that can be activated on demand. The firmware will take care of this via DT fixup during boot and will also provide a way to adjust the pool size. Signed-off-by: Li Hua Qian <[email protected]>
The AM654 lacks an IOMMU, thus does not support isolating DMA requests from untrusted PCI devices to selected memory regions this way. Use static PVU-based protection instead. For this, we use the availability of restricted-dma-pool memory regions as trigger and register those as valid DMA targets with the PVU. In addition, we need to enable the mapping of requester IDs to VirtIDs in the PCI RC. We only use a single VirtID so far, catching all devices. This may be extended later on. Signed-off-by: Li Hua Qian <[email protected]>
Signed-off-by: Li Hua Qian <[email protected]>
Signed-off-by: Li Hua Qian <[email protected]>
Signed-off-by: Li Hua Qian <[email protected]>
PVU-based DMA isolation brings SWIO TLB to the table and the maximum allowable number of contiguous slabs to map is 128 by default, but meta-hailo requires more than 128. Hence increase it to 256 when meta-hailo is included. Signed-off-by: Li Hua Qian <[email protected]>
huaqianli
force-pushed
the
lee/hailo-card
branch
from
e0392a7 to
a52ed0b
Compare
meta-hailo: Fix the CMA issue when PVU was integrated
linux-iot2050: Make PVU only available for secureboot build
README: Add SENS SM firmware update tool info
iot2050-conf-webui: Fix the wrong article number of SM1231 4AI
linux-iot2050: Add support for PVU-based DMA isolation on AM654
u-boot-iot2050: Add support for PVU-based DMA isolation on AM654
Add support for Hailo Card