iWave Systems i.MX8M Mini Board is a development platform based on an update versions of the company’s iW-RainboW-G34M-SM i.MX 8M Mini system-on-module and designed specifically for low-cost facial recognition systems thanks to NXP eIQ ML software, and MIPI display and camera.
iWave Systems i.MX8M Mini (aka iW-RainboW-G34D) specifications:
- SoM
- SoC – NXP i.MX8M Mini Q/QL/D/DL/S/SL with up to 4x Cortex-A53 cores, 1x Cortex-M4F real-time core, Vivante 3D and 2D GPUs
- System Memory – 1GB LPDDR4 (Expandable up to 4GB)
- Storage – 8GB eMMC Flash (Expandable), optional 2MB QSPI Flash optional Micro SD slot
- Wireless – Dual-band 802.11a/b/g/n/ac WiFi 5 and Bluetooth 5.0.
- PMIC – BD71847AMWV
- i.MX8M SODIMM Carrier Board
- Storage – MicroSD slot
- Display I/F – MIPI DSI display connector
- Camera I/F – MIPI CSI camera connector
- Audio – Audio codec, 3.5mm Line In/Out jack
- Networking – Up to 2x Gigabit Ethernet ports (One is Optional)
- USB – 2x USB 2.0 Host ports, 1x USB 2.0 device port
- Debugging – Serial console on Micro USB Port, JTAG header
- Expansion – 1x Data UART, GPIO Header, eCSPI (Enhanced Configurable Serial Peripheral Interface) header
- Misc – RTC Coin cell, boot mode switch; ON/OFF, reset Switch
- Dimensions – 100 x 72 mm (Pico-ITX form factor)
- Display – 5.5” HD AMOLED MIPI DSI display
- Camera – OV5640 camera module up to 1080p30
- Power Supply – 5V @ 1A DC Input
- Temperature Range – 0°C to +60°C
- Compliance – REACH & RoHS
A facial recognition demo is included with the development kit. It relies on a Qt5 GUI, eIQ OpenCV ML software to compare the faces captured by the camera against registered face images in a database using the Django framework. The board also sends real-time data to the cloud via Ethernet and WiFi, so that authorized access and unauthorized detection can be visualized on a web dashboard.
One of the main use cases of the development kit is access control with face recognition solutions being much safer than fingerprint-based access control solutions in the time of COVID-19, as it enables zero-contact access application by using individuals’ faces to authorize access to a commercial/industrial space, home/office, transportation, banking, and government sites.
There’s no information about availability nor pricing. You may read a bit more about the solution on the press release, and/or contact the company via the product page.
Via LinuxGizmos
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Why such an old Linux kernel version? 4.14.98 was well over a year ago now
The worst is not that it was release over a year ago, but that it contains 7653 bugs that were since fixed in mainline and that the only two possible reasons for this kernel to have been left for dead for more than one year are either that they don’t care, which is not acceptable from a serious vendor, or that their kernel is so heavily patched that it cannot even stand security and stability updates, which is not an acceptable reason either. In any case, nobody should use this unmaintained BSP under such conditions! Usually NXP takes care of… Read more »
How much would a mainlined kernal add to SoC products production costs?
You mean if the silicon vendor already has a mainlined kernel?
Yes how much costs would it add..
It’s not necessary a big deal in costs. It is more a question about comfort. It’s simple to just don’t care about coding standards etc.
There may be significant costs in the short term as a company would have to rebase its code to be compliant with mainline Linux guidelines. They’d have to pay developer time to do it, and it may delay other projects. It’s further complicated because of closed-source binary blobs so they have to rely on other partnering companies (e.g. GPU IP) to do the same.
But over the long term, it should pay off, as new features and security fixes are added to new Linux releases without the company having to be involved.
But when they’re in an LTS branch, there is almost nothing to do. Just a “git rebase v4.14.181”, fix the rare conflicts which systematically mean that some code they changed was actually affected by a bug, and that’s all. If *this* is too hard, either they’re totally incompetent and nobody must trust them to deliver critical fixes, or their BSP is a pile of crap which ruins everything and it cannot simply be trusted at all.
Okay, the costs in short term are true. I still don’t get why people aren’t doing it in the first place. It’s the best strategy you can have.
That’s not what is going on. Their tech support people are trained on how to use and debug the released BSP. It costs a lot of time and money to train their people so NXP does not constantly update their BSP. The whole point of a BSP is so that you and tech support are looking at the same code while they try and help you fix your problem. Two different definitions of support are being conflated 1) support as in mainline support. Is the code in mainline and does it work. 2) support as in tech support. Will NXP… Read more »
There is a corollary to this…
If you ask NXP “do you support kernel 5.6”, they will answer no.. We only support the BSP. That is because you are asking that question to the tech support people and they answer in their work context.
But then if you try mainline 5.6 you’ll discover that it works (most of the time). And you’ll say iMX is supported in mainline, why did they tell me it wasn’t!?! This is because you are now using the other definition of support.
… and that has been an ongoing discussion for a long time about commercial interest of companies compared to open source efforts and success of (partly to mostly) unpaid development work, but in either case leading into cultural improvements and growth of knowledge?
What’s a silicon company’s philosophy?
What is Allwinners philosophy (now)?
http://www.allwinnertech.com/index.php?c=about&a=index&id=24
What are NXP’s customer relations like?
https://www.nxp.com/company/our-company/about-nxp/sustainability:CORP_SOCIAL_RESP
Jon, I’m not speaking about rebasing their BSP on top of each major release, I know that this is a major pain. I’m speaking about doing the very minimally required hygiene which is to rebase to the up-to-date version in the LTS branch they’re using (here it ought to have been 4.14.181 and not 4.14.98). Greg KH now maintains these kernels for 6 years and that’s awesome for every vendor. But what’s the point if they stick to a bogus, outdated version forever ? At work we ALWAYS rebase our patches on top of the latest LTS kernel of the… Read more »
> It costs a lot of time and money to train their people so NXP does not constantly update their BSP.
But if their BSP is based on an LTS kernel what’s the point of doing this when they ‘forget’ to update this LTS kernel to latest version available?
Just merge the the LTS branch in yourself, that’s what I do. The problem here is in keeping you and the support team all on the same piece of code. They don’t want it to be a moving target.
Differentiate between what the tech support people that work at NXP will answer questions on vs what you can do on your own. The iMX8 is fully working in mainline. You can build a fully up to date kernel anytime you want to. That is different than saying to iMX tech support – your code is broken, here’s instructions on how to break it, now give me a fix. They’ll only do that for their released BSP. What NXP tech support is not going to do is debug your random mainline build for you. If you want to use mainline… Read more »
My point above is that their BSP is broken because they refuse to apply the required fixes on it and everyone in the world can figure how to break it, possibly remotely root it (because surely in these 7600 bugs some are remotely exploitable). By deploying this unmaintained code in the wild, you’re knowingly putting your customers at risk. It would be nice if some serious vendors (and I consider NXP as serious) would provide their BSP as patch sets and they would themselves ask their customers to apply them on top of branch X.Y. This way, if a customer… Read more »
You just have to do the merge onto the latest kernel yourself. These tech support guys are not core kernel developers. They can’t deal with the constant code churn from mainline. Merging up to the current LTS versions is your job, not theirs. Also consider that every customer is going to merge up to a different LTS version. There is also a testing guarantee going on here. NXP has run a lot of tests on their BSPs. They don’t want to keep doing that over and over with each LTS point release. Maybe they will update the BSP once a… Read more »
> You just have to do the merge onto the latest kernel yourself(…) A BSP is not something that you would ship This is the broken part of the process, which is demonstrated by every single router, NAS, modem or whatever blackbox vendor shipping with the exact version of the BSP they validated because “it comes from the SoC vendor who knows what they’re doing and we don’t want to risk to lose support”. Remember 3.3.8 as initially provided by OpenWRT that was found running in virtually any sub-5watt device even years after 3.3 was dead ? > NXP has… Read more »
There is no perfect solution. It is simply not practical for the SOC vendor to track continuous kernel churn on a daily basis in their BSPs. NXP has a pretty good compromise in keeping everything in a shape where is it pretty easy to merge. About the only thing you could fault them for is not updating their BSPs once a year or so. But that costs money and they may not have the customers/revenue to justify that work for every BSP. The core concept here is to get everything into mainline so that the customer can do the update.… Read more »
NXP is a reliable and highly professional vendor, extended customer support and aware of social and environmental responsibility. But if this skills on hardware not include, that there is software related trust in continuation on security updates, especially with ai-related recognition coding, what’s then their advantage over (formerly) less security concerned Chinese vendors, for example. Outsourcing that revision of mainline security means talking ’bout networking experts with longanimity. LTS releases updating is therefore on different levels delayed, compared to instant mainline (that business customers can include on their own responsibility and comparable investment into such being “up-to-date”). No supporter of… Read more »
> What updated driver and security improvements customers been missing since around a year? Nobody should have to manually validate each of these 7653 fixes. The purpose of LTS is “take it all and trust us, if we fail we’ll fix it, it’s always safer up to date”. That doesn’t mean you must update all the time. It just means that the bare minimum the vendor must do is provide something that is up to date when shipped. If it takes two weeks of QA after the last change, nobody will complain that the kernel is 2 weeks old. Here… Read more »
Got the point, probably, so maybe better just give it a while
https://xkcd.com/1820/
It may also be a business decision… as I can see there’s a service called “Vigiles Software: Keeping Your Linux BSP Secure”: https://www.nxp.com/support/support/nxp-engineering-services/vigiles-software-keeping-your-linux-bsp-secure:VIGILES I found it through an upcoming webinar that reads: Security should be considered throughout the lifetime of an embedded system. Continually changing threat environments, new deployment modes, and third-party software updates mean that your BSP software can no longer remain static and “frozen.” https://register.gotowebinar.com/register/2712071180302143755 So based on the discussion above, I understand they provide a fixed BSP for which their support staff is trained, and then customers can either apply the patchsets themselves or with some help… Read more »
> So based on the discussion above, I understand they provide a fixed BSP for which their support staff is trained, and then customers can either apply the patchsets themselves or with some help using VIGILES. Then at the very least they should not propose 4.14.98 as the base but 4.14.0. The problem with 4.14.98 is that nobody knows the current versions and this one looks high enough to appear as the up-to-date one. When you see 4.14.0 there’s no doubt at least. Or if they need to be on top of 4.14.98+ because of some API changes, at least… Read more »
Reliable security (responsible for users behind business-to-business) with purchasing cost of a system is not overall cost for longterm support. That’s probably where “authorize access to a commercial/industrial space, home/office, transportation, banking, and government sites” description changes its static meaning?
And by the way another proof that it doesn’t work is that iWave is their customer here and simply relies on the outdated BSP provided by the SoC vendor.
give it a signet “not confidable on that BSP revision”?
Who would?
It is easy to generate a patch from most BSPs. Look in the kernel makefile and check out the kernel tree for the tag you see there. Then copy the BSP onto that checked out tree. Do ‘git diff’. Now you have your patch. Commit it, then merge in future tags if you want. That usually works but sometimes you will have to do it in smaller chunks, jumping three months ahead usually works, jumping two years ahead almost always fails (ie merge conflicts). I do wish all of the SOC vendors would stop the tarballs and simply provide git… Read more »
It’s based on latest NXP GA Release:
https://source.codeaurora.org/external/imx/imx-manifest/tree/?h=imx-linux-sumo
imx-4.14.98-2.0.0_ga.xml
Not familiar with codeaurora. Just talked to the postmarket OS people. They told me that codeaurora is basically the dump for Qualcomm etc.
Just posted an interview with NXP and Timesys that goes into more details about NXP Linux BSP and maintenance:
https://www.cnx-software.com/2020/07/04/interview-nxp-linux-bsp-and-timesys-vigiles-maintenance-service-security-updates/
iWave – never get schematics for SOM. After purchase they will constantly ask Zoom and solicitate their service.