Some terms I will keep using - EVT (Engineering Validation Test), and DVT (Design Validation Test) they are different stages of prototypes, EVT being the first initial prototype. In our current roadmap, we are testing the I.MX8M Plus DVT and designing the I.MX 95 EVT in parallel.

(Fair warning, these updates may be overly detailed 🙈)

Hardware Design

Bringing Display over Type-C, bye-bye Mini HDMI

While both processor variants for the Comet are swappable, the I.MX95 does not have a native HDMI interface that the I.MX8M Plus does. This means to get display out, we have to convert the 2x LVDS in the I.MX95 to HDMI, but alternatively we could convert it to DisplayPort and make it available on the USB-C.

Max Resolution: Each individual LVDS (4-lane) for the I.MX95 can do 1080p60 (165 Hz), but the LVDS to DP Type-C controller can accept two LVDS channels as inputs and combine their bandwidths. So theoretically we can run the clock at 330 MHz, and get maximum of 4K30 support. This will of course have to be validated and will require some black magic at our end.

For the I.MX8M Plus, we are going to convert the HDMI to DP Type-C. There is a small catch, it is the USB2 on the side that gets the DisplayPort support, so one hub to rule them all is not feasible. We couldn’t bring this to the bottom type-C because -

• Distance from SOC, signal loss is a risk
• More importantly, this would replace our already sound, well-tested and reliable PD Controller + Charging IC setup.

Moving the NanoSIM Connector

LTE/5G Antenna design is an upcoming topic in our list, and the top edge is a premium real-estate for better reception. We are moving the SIM Card along with the MicroSD card under the M.2 slot. This indirectly also helps improve our waterproofing to some extent.

This is a tricky connector, but we think insertion should be possible without removing the aluminium middle frame, but for removing you will have to unscrew the middle frame off. Sigh! We tried but in the size constraints we couldn’t find a push-push connector.

Replacing the Boot-Mode DIP Switch

The Comet has a hardware boot-mode switch that lets you switch the the boot mode to either boot from EMMC, SD Card or put the device in the flash mode. You most likely will not need to bother about this.

The DVT used a tiny boot-mode DIP switch which is quite tricky to access from the top of our rear enclosure. Some of our team members are not good dealing with small components, including myself, so we have damaged few of them in the process and I wanted to do something about this critical component that can always reliably rescue you from a potential brick situation.

We are replacing this with standard 2x2 2.00 mm header+Jumper (shunt). There is a bit of a nostalgia to this design too, if you’ve assembled desktops in 2000s you know what i am talking about.

Switching to LPDDR5X for power savings on I.MX95

We are switching to LPDDR5X parts for the I.MX95, for some reasons we always thought the I.MX95 was limited to LPDDR5, but when we dug deeper into the reference manual and later when confirmed with NXP it is evident that the 95 can support LPDDR5X. This means the I.MX95 can leverage some performance benefits on the DRAM consumption when in idle or low-speed usage.

Hopefully this helps offset some of the higher power consumption for the 95 🤞, there are more opportunities but that comes later.

Enhancing Thermal Design (On-going)

One of the things that keep awake at night is the I.MX95’s thermals. The CPU is significantly faster and with more number of cores, and the GPU is atleast 2x faster than the I.MX8M Plus. Since more than a month, we are actively pursuing improvements in the thermal design, to accommodate for this increased requirements.

All our simulations are being tested with the processor at 4.5W which seems to be its upper limit. We are also trying to simulate in our lab.

We unfortunately don’t have the NXP’s official EVK yet, so we aren’t able to test but we are working on improving the design as much as we can to have a favorable outcome when the I.MX95 EVKs arrive. We haven’t nailed down on the final design for the thermals yet, hoping to finish by next update.

Road to I.MX95 EVT Prototype

Our I.MX95 design did hit a roadblock with handling the Display Out but we are past it and are working towards releasing the PCB for manufacturing in 4 weeks from now. In parallel, our BSP teams are already testing our core peripherals like the display with the EVK and getting a hang of things before the PCB arrives. Our schematics are close to completion and the layout is getting in-progress.

Here are some early sneak-peaks into the PCB layout top and bottom.

Hardware Testing

One of our top priorities right now is qualitatively testing the I.MX 8M Plus DVT prototype and any customized components for the Comet to ensure that any inherent issues don’t move to the upcoming I.MX 95 EVT. We have a unique approach where I push the hardware engineers to their limits and they push the Comet hardware to its limits, works well.

Getting the Display Out to work

The Comet uses Mini HDMI (for now), when you plug the cable into a monitor there is an exchange of information where the monitor tells the host what modes (resolutions) it can support. We had an issue in the EVT where this communication which happens on I2C failed. This was patched in the DVT and here is a quick demo of Fedora with XFCE desktop -

There is graphics/DRM issue with Mouse, we are yet to look at

I am always pleasantly surprised by how much the I.MX8M Plus punches above its limits. As of right now we have tested at around 1080p60 but it can go upto 2k60, this particular video is running at 1920x1200 at 60Hz.

Ensuring Battery Performance & Certifications

Originally with the EVT we had a 5-wire battery for the Comet, 5-wire to support high discharge currents (4A), so you have +,+,-,- and TS (for temperature sensing). We couldn’t get these many wires to fit well in the battery enclosure, they aren’t easy to bend either. In the DVT we switched our batteries to flex cables, something similar to what smartphones use to save space inside. But when we tested the new Flex PCB batteries we could only get 12Wh which is roughly 30% less, we tested and re-tested.

Initially our supplier didn’t agree (of course) but we submitted video evidences and test records. Eventually it was concluded that the new batteries had their protection circuits misconfigured for the standard 3.7V LiPo batteries while the Comet’s battery spec is at 3.85V, to help squeeze some more juice in (4100h).

We have sorted this out with our manufacturer and we are now moving to certifications - IEC 62133:2017 CB, BIS, UN38.3+MSDS, RoHS, REACH and CE.

Note - We still have a regular 3-pin connector in case you want to bring a different (maybe bigger battery).

Power-In Testing

I spoke of this earlier on Discord, the EVT was plagued with all sorts of power-in issues, we just couldn’t supply enough power to the board. We had made too many assumptions, and validated very little. We learnt our lesson and fixed everything in DVT, and happy to power is no longer a problem for us.

Now to go a step further we decided to verify and stress test our limits

• Battery+Charger: We could in all pull in 25W
• Charger but no Battery: We are able to draw up to 20W
• Only Battery: We could do 20W

This is what our test setup looked like, two DC Loads, one DC Power supply, Type-C power meter and a multimeter.

We want to push these numbers closer to 30W. This is important because we don’t know what you folks will bring in on the M.2, USBs and the extension area.

USB Testing

USB is a critical interface for the Comet, it powers a lot of things. We’ve recently spent sometime verifying how much power and transfer bandwidths we can get out of them. We’ve used a USB 3.0 to Gigabit adapter to verify.

We are yet to check what is the max speeds we can get, theoretically USB 3.0s give 5000 mb/s speeds. We will try with a 2.5 gigabit adapter or a NVME USB drive and get back on this.

Troubleshooting WiFi (On-going) 😭

This is probably the only problem child for the DVT. Our WiFi works but we are not seeing the kind of speeds and consistency that we should. We are seeing sporadic issues such as - limited upload speeds on particular channels, random sudden drop to 0 Mb/s while running iperf3 .

We are working closely with U-Blox team in India and now in Germany to get to the bottom of this. Luckily our design team was at Embedded World in Nuremberg with a test unit. We are sending them a unit early next week, I will get back with the updates.

LTE Testing (On-going)

We have two modems from Quectel with us, the EM05 and EM060K. We already did get the EM05 working with Calls, SMS and Data, but the EM05 is a Cat 4 modem, whereas the new one EM060K is a Cat 6 modem which means it can run at a lot more speeds. For the EM05, we have tested speeds close to ~20 Mb/s, but we are yet to test the EM060K further.

We have hit a snag, the EM060K is widely supported and well certified across regions but the firmware out-of-the-box is Data-only 🤦‍♂️, Quectel can help us customise the firmware but we are discussing with them about long-term support.

We had Quectel visit our office earlier this week and we will be working closely with them for custom antenna that are optimised for our form factor and mechanical design. This is something we will be pursuing next month.

Overall Testing Status

So far everything with DVT looks good 😇, we are working on completing most of the testing effort by end of this month.

Software

Migrating to Mainline Linux Kernel 😱

This is HUUGE! Up until now we were always testing with NXP’s downstream kernel but few weeks back we started messing around with the mainline mainly to get our media and camera stack working without their proprietary blobs. We are actually pleasantly surprised how most of the things are already working. Here is a small glimpse of things that are tested, and some issues.

Moving to mainline was always part of the plan, but we are now moving this ahead in the timeline. We are transitioning all our build system and testing to the mainline version, you can check the branch pushed here at https://github.com/mecha-org/linux/tree/mecha-v6.19-wip

This couldn’t have been done without @bshah, his effort and direction.

Libcamera Support with Hardware ISP+Encoder Pipeline

Just few days back after 4 weeks of constant effort we finally got our entire camera pipeline working. The Camera pipeline can be largely represented as - Sensor → ISP → Encoder. Each of these in the I.MX8MP are hardware components, now instead of proprietary blobs we have switched to using libcamera and the open-source mainline drivers for this entire pipeline.

Here are stills captured from the camera and encoded. Note - the camera ISP needs to be tuned for color matching, white balance.

Also thanks to the @libcamera community for their support.

Re-engineering the Launcher

We ourselves are unhappy about the last version of our launcher UI, it is slow and hogs CPU and GPU resources way too much. We have experimented with a lot of GUI libraries in the past and at some point, we even starting writing our own GUI Library (mctk) too. We are now course correcting by changing our mental mapping on how we want to build this.

A typical GUI application works in these layers -
Widgets → Layouting → Primitives → Renderer → GPU

The widgets are abstracted UI components that have no control of underlying rendering, and cannot cross the realm to GPU-level optimisations. Whereas the renderer is designed for generic UI and equipped enough to form a baseline. What if we removed these abstractions and directly connected our widgets/UI with the renderer, just like how few games roll without a game engine. Squeezing every bit of performance and optimising for the Comet’s GPU. This is where we are headed.

This effort is being made here https://github.com/mecha-org/mecha-wayland, and we currently have tied in the WSI+EGL+Basic Renderer. Our approach is to measure everything at each step to ensure we are always in control of the end performance.

Our goal is to get a launcher UI that utilises minimal resources, has least power overhead while giving liquid-smooth performance.

Supply Chain

On-going Procurement & US-Iran conflict

Our first production batch for the Mecha Comet is planned for 5000 units, we started procuring from January but we have speeded it up from March. The US-Iran conflict is resulting in disruption on the supply chain, and most large semiconductors are revising prices from April. We are trying to lock in the price and supply for all the long lead time components by end of this month.

To promote transparency, I have shared a table below summary of our current procurement status.

On the other side, the rising memory costs show no sign of slowing down, we unfortunately accounted for the memories based on Jan prices, and even though we reserved some memories but not for all variants. The memory costs have risen another 40%-50% in Feb, and we are hearing a bigger jump in June. Here is a summary of our memory procurement.

I wish I had better news to share, these are perilous times. That said, we are actively working with all our distributors and sources closely to ensure that there are no hiccups. I am grateful for all our backers to have invested with us in these uncertain times. As of right now, we are not seeing any risks other than taking further hits on our margins.

Upcoming Backer Portal (or Pledge Manager)

We are working on our backer portal and plan to launch it by end of next week, you will be able to manage your pre-ordered Comet, its configuration, add more units, add-ons and update your shipping address directly within the portal.

Community

NixOS on the Mecha Comet

Sometime last month, one of our community members @Ame took lead on getting NixOS to boot on the Comet with some help from @bshah and we have lift off.

You can find her repo here https://github.com/amelia-raine/mechanix-nix/tree/comet-imx8mp-image

Kali on the Mecha Comet

Dhruvesh (@iam_optimus) from our team ported Kali with some help from other community members on our DVT units. Here are some sneak peaks and a demo

We pushed an experiment branch here on https://github.com/mecha-org/mecha-make/tree/kali-experimental

Flame Jam 2026 + Mecha Comet

Mecha was one of the sponsors for the Flame Game Jam 2026, organized by the amazing folks from Flame—a 2D game engine built on top of Flutter that lets you ship across all platforms, including the Comet. We're giving away one Comet+Gamepad to the winner.

You can review all the submissions here - https://itch.io/jam/flame-game-jam-2026/entries

Upcoming Milestones

Here is a summary of all the immediate milestones that we are closely tracking -

Mecha Comet

• Finish DVT Testing: March 31
• Development Testing for Certification: March 31
• Complete LTE Antenna design: April 15
• Release I.MX95 EVT for manufacturing: April 21

Extensions

• Release next iterations of Keyboard for manufacturing: April 15
• Release next iterations of Gamepad for manufacturing: April 15

That’s it for now. Thank you for suffering me, and see you in the next one! I would love to hear your thoughts, feedback and any inputs.

Shoaib