I would like to use the Verdin IMX8M-PLUS module and start with one of the carrier boards. I need to develop one C++ application for the A-cores. So for me containers are overhead. I do not want to learn something new that I do not need. And I do not want to add complexity so that more things can go wrong. Things I do not master.
So I hope it is possible to just run a linux version and develop one C++ app using Visual Studio Code.
Hello @simmania ,
You can use our reference images (minimal or multimedia), that donât use containers, and customize them or build your own ones using Yocto.
Here you can find some documentation about application development.
Best regards,
Josep
Thank you for the links Josep, but I believe the other half of the question was
One C++ application using trusted X11 tools not having to use Wayland/Westin. From my own journey down this road, even with minimal, we could not use trusted for decades X11 tools. We had to use unproven Wayland/Westin and we could not control screen locations due the the âcompositorâ nature of that icky stuff.
If you donât need any UI, not even for the default debugger printf(), one can make minimal work with trusted tools.
Please correct me if Iâm wrong.
Will minimal allow the initial poster to use tools/libraries theyâve trusted for decades, or will they have to endure Wayland/Westin? I couldnât get X11 to work under that.
Hello @seasoned_geek ,
Regarding your question , you can refer to what my colleague @rafael.tx said in this thread created by you:
Toradex bases our BSP offers on what the manufacturer of the SoC provides. We work hard to make sure that our modules are well-integrated and all the HW features are supported. We also do extensive testing to make sure that everything works as expected.
Additionally, we put a lot of effort to make sure that our modules can run with mainline kernels. At the end of the day, we usually donât take upon ourselves to support features that are not supported officially in the SoC BSP.
X support is an example of that, as NXP dropped official support for it on their BSP, we cannot keep up with this support ourselves. Our team is significantly smaller than NXPâs teams and we cannot make sure all GPU features work well on the entire range of modules we provide to our customers.
On the other hand, we also try our best to make sure that our customers are not blocked from using the software that they see fit.
Now, to answer your questions directly:
What are the plans for continued pure X11 (no Wayland/Weston/xwayland) support on what hardware going forward?
We have no plans to officially support X11 anymore. Customers are welcome to use it themselves and see if the results fit the project requirements.
Best regards,
Josep
Thank you for the reply.
Tis a sad sad day because that means Toradex is eliminated from an awful lot of projects. ARM vendors still supporting X11 are getting a lot of business.
Whatâs really odd is that according to the build configurations in this document. X11 is added back in for imx9
As I understand Yocto is for experienced Linux users. Iâm not. I know Ubuntu and would like to develop a C++ application using Ubuntu.
I hate to be the bearer of bad news here, but Toradex products arenât âdesktopâ computers. These arenât like Raspberry Pi where you get a Raspian desktop Linux distribution and can compile then run one C++ program with all of your Dev tools on the target. Some people do âdev on targetâ but 99% donât.
There is a VS Code/Codium plugin many people use for developing applications/containers on the target, I donât/wonât use it.
The market segment for Toradex (and they can feel free to correct me) is embedded systems.
That is both a medical device and an embedded system. (actually two because the thermometer is also one). These get a custom OS as well as a custom application. Once developed and through FDA approval anywhere from thousands to millions of units get made.
This is also an embedded system.
It has no display. I didnât develop it so cannot tell you for certain if it has an OS or is pure bare metal coding. It does have software and might have only a 4-bit CPU (yes, there are 4-bit CPUs out there for things like this that donât need to do much.)
Despite the development carrier boards making the Toradex products seem like a small desktop computer, they are not. You cannot compile a simple binary and post it somewhere for everyone to download to their Toradex Dev board because the universe these products exist in arenât trying to mimic desktop/laptop computers.
Given what youâve written I have to believe you have these products confused with a Raspberry Pi or Beagle Bone. The market segment here is the development of embedded systems.
I know. An embedded system is exactly what we want to make. Actually I would love to program the iMX8M A-core bare metal. But that is not possible. As I understand we need to use some Linux OS at least.
I just do not like the complexity of containers and cross compiling. We developed for the Jetson Orin Nano boards from nVidia using a Visual Studio Code compiler on the target. That was perfect for our use case.
I would like to do that again. Unless the cross compilation is easy and has fast iteration cycles. But that is not the case Iâm affraid.
Actually we want to switch to the iMX8M because of the MCU that can be programmed bare metal.
That is correct.
Containers do rather suck.
Do you need the iMX8? I ask that question because pre-iMX8 (Toradex please correct if Iâm wrong) you didnât have to use containers and X11 was/is still supported, though you may have to use an older version of Torizon Core or whatever it was called then.
On my HP z820 with 120GB of physical RAM, 20 physical core, and a Ubuntu VM running on a 6TB WD Black spinning disk (not SSD) a full from source Yocto build takes me roughly 3.5 hours. If you try to do it on a standard corporate laptop with SSD you might well die of old age before it completes.
Having said that, unless you are working on device drivers or something that requires being compiled into the kernel, you should only have to endure such a build once. After it has been deployed to target you can copy your cross compiled executable(s) to target to run. You can even remote debug if you built GDB server into your dev target.
I do not know how the VS Code/Codium plug-in stuff works. I tried it once and uninstalled it. For my last project with Toradex components we ended up using containers because we were on iMX8. Wayland/Westin is the part that really sucks. One cannot control any screen positioning. Your X11 application has to make one full screen window then you can control the position of things inside of that window.
You can do X11 development/deployment inside of a Buster container. The X11 support contained in Wayland/Westin is dramatically incomplete. I used NanoGUI because it stayed well within the bounds of what seemed to function.
For developers who hack on the fly (Agile) containers protect the guilty. When coding without an actual plan, just a âUser Storyâ developers will continually bash into each other if they are on a single OS instance without a parental unit keeping the kids apart. Containers make bad code more usable by keeping it from causing more problems than it otherwise would. It doesnât make it better code, just hides how bad it really is because you cannot reach outside of your container and trash the OS or other processes.
I took a quick look at the Jetson stuff you mentioned. Are you doing Robotics? I too would have a severe aversion to containers being used in such a product. Would think it is almost impossible for safety systems to function properly if they cannot read everything going on in every container and gracefully divert rather than shut down.
Just my 0.0002 cents.
While Toradex or NXP does not officially support bare metal programming for the iMX8 A-core, it is indeed completely possible. You have several options available:
- You can create and run your own bare metal application in place of U-Boot.
- Alternatively, you can modify U-Boot to incorporate the additional functionality you require.
- Another approach is to create a U-Boot application to suit your needs.
Ultimately, the choice depends on your specific project requirements and preferences. you need.
Yes we do
Not really. But we want to control hardware with iMX8.
We need to connect cameras for special tracking.
And we want to use the M-core for low level controlling and audio stuff.
All I want is Ubuntu or Debian to develop our app. Why is that so difficult?
Iâm affraid that that would be way to difficult. As I understand the MCUXpresso software does not support the A-core.
So you have to figure out yourself how to control all peripherals and set all needed registers. That may be ok for a simple device as a Uart. But to get the chip working we need to configure a lot of peripherals like clock generation and memory management.
The Reference Manual of the iMX8 is more then 7000 pages! So support from somethink like MCUXpresso is really needed.
So I think that is a no go.
You can use Ubuntu, Debian, OpenSuSE, Manjaro, or any other Linux OS on your desktop to develop software for your target. You simply cross compile and deploy. These are not hobby systems like the Raspberry Pi.
Eventually you are going to have to do a Yocto build for an OS on the target to deploy. Deploying Ubuntu or any other Linux desktop one an embedded system is leaving it open to 8-lane wide security holes and crashes. The entire point of a Yocto build is to strip Linux down to only what you need.
Unattended Upgrades is a virus that cannot really be removed from Ubuntu. No matter how many times you kill it, the thing is like Jason from the Holloween movie franchise. It keeps coming back to life. Now that Linux has integrated networking into the kernel, when this thing reaches out to check for updates and finds it cannot get to the Internet your whole system hangs until it exceeds timeout. If your camera stuff is being used to self-drive a vehicle moving at 80 MPH around a mountain curve, the driver just died. Twenty seconds of network timeout sent them right over the edge of that mountain highway.
I get it. You have a set way of doing things. All you wanted to have change was the processor, but that is not what happened. You arenât moving from a 286 to a 386. You may need to move to a non-NXP Arm 8 processor that still supports X11. The only reason iMX8 doesnât still support X11 is NXP stopped providing X11 video support in the BSP. This is low level software other vendors choose to provide.
If you are adamant about running a desktop distro on iMx8, here are some links. You will be completely on your own.
adding Snapd though I would not recommend it
Manjaro even has Arm
You have a choice to make: either delve into bare metal programming, where youâll handle tasks such as clock generation and memory management, or opt for an operating system that manages these tasks for you. Itâs worth noting that if you explore the U-Boot documentation or its source code, youâll observe that it handles many of these tasks. U-Boot can be seen as a rudimentary OS. It operates on the A-core, and you donât need the MCUXpresso for compilation. For a deeper understanding, please refer to this article.
We also offer a prepared Linux version for your convenience. If Debian is your preference, a Debian container is available. However, if containers donât suit your needs and you desire a âpureâ Ubuntu or Debian, and believe that to make such thing is not âso difficultâ, feel free to undertake the task yourself. All the source code is openly available
I bought the iMX8MP and Verdin Developer Board assuming I could (almost) immediately start programming.
This is by far not the case. Unless you already know a lot about Linux and Containers I guess.
You will be developing for a Linux target as nobody uses Windows for embedded systems. You donât have to develop using a Linux host itâs just that professionals donât use Microsoft products. The documentation and tutorial allows for you to use a Windows host for development.
There can really be no substitution for reading the documentation and watching the videos. Nay, actually following step by step line of code by line of code, replicating the tutorial programs.
In the lower end embedded system world, Linux rules the land ⊠unless you work for Agco, then it is embedded DOS. The stuff which has higher risk to human life, like surgical robots, uses QNX because it has FDA certified versions. Most self-driving autonomous (sp?) vehicle things will be forced to use that save version of QNX by regulation soon as well.
I donât know what you were using before, but embedded systems is working close to the metal. If you want to do bare metal, then you need to have a much simpler SOM/CPU. Your hardware people can take the diagrams and design specs from Toradex and strip out every component and trace you do not need, do same thing with carrier board, and your bare metal way of life will be much easier to achieve. . . you will have to wait for the production run, pay for a minimum quantity, etc. etc.
Containers do suck, but they allow lesser skilled developers to be productive. That uninitialized pointer canât trash some other process on the device even when you are running as root within your container. for people that went to college and understand true Software Engineering uses SDLC based Waterfall these guardrails arenât really necessary. For everybody else, they are. Sadly, there are a lot more of the âeverybody elseâ crowd in the market these days.
Iâve been running some flavor of Linux as my primary desktop for well over a decade. I moved to Linux when IBM killed off OS/2 Warp. Microsoft has been a dead entity in my world for most of the past 30 years. Same for almost every embedded developer I run into . . . just not so many of them old enough to remember OS/2 these days.
Any time I move to a new processor in the embedded systems world there is always about 7 days of reading documentation, configuring build environment, generating âHello World!â level executables, etc.
1 Like