on March 25, 2022 I zipped up a custom image that EasyInstaller could install on the Dahlia carrier. We could play sound and record sound. Life was good.
Now that clients are coming in from other countries tried the image on a modified board. Just got static garbage in wav file no matter what we did. There also appears to be no rhyme or reason to how it decides LINE-IN or MIC.
Ripped hair out. Slammed head against desk repeatedly. Questioned every mod. Spent hours testing.
Took virgin board with no mods. Used EasyInstaller to install the the image from the zip file that has been unchanged since March 25. Got garbage sound.
On both boards ssh’ed in. Killed the containers. Launched our container interactively to get terminal. Used the Alsa Mixer TUI to set card and capture volume. Used arecord to capture sound. Got static garbage.
Installed SABRENT USB stereo sound adapter in USB port for both boards and rebooted each. Again SSH’ed in, killed the container, used the ALSA Mixer TUI to select card and capture volume. Both boards record clean sound using arecord.
Questions:
Is there a way to STOP EasyInstaller from pulling down “updates” for the HOST OS? We need to lock this into a version that worked. I tried using a local old version but it appears to still pull down the latest and most broken version.
Is anyone else trying to record sound with Dahlia and suddenly having issues on boards that worked before?
What changes have went in to EasyInstaller and the HOST OS that impact the imx8mp-wm8904? You can play sound just fine, but it seems to be randomly choosing input source, or perhaps blending both together, collecting huge quantities of static and garbage.
How can we achieve stability with Toradex? This was a serious shocker. We put stuff away that worked perfectly and now it no longer works if you follow the instructions to load the software.
This all sounds very strange. You created a custom image that was known to work for your purposes, but when you flash this image it no longer works as expected?
Is there a way to STOP EasyInstaller from pulling down “updates” for the HOST OS? We need to lock this into a version that worked. I tried using a local old version but it appears to still pull down the latest and most broken version.
I’m not sure what you mean here. Are you saying that Easy Installer is installing OS versions other than the one you specified? Because that sounds very odd. Easy Installer should only install what you specify and does not pull down “updates” of it’s own accord.
I’m not sure what you mean here. Are you saying that Easy Installer is installing OS versions other than the one you specified? Because that sounds very odd. Easy Installer should only install what you specify and does not pull down “updates” of it’s own accord.
This is untrue. Easy Installer always reaches out to the Internet and tries to pull down newer versions of things. If you do not have an Internet connection you have to wait for some serious timeouts to get anything installed.
My boss proved this by disconnecting the Dahlia from the Internet and using an older version of Easy Installer (the one we had tested with) installed the archived-for-a-month-passed-everything-last-time version of the software on the target. It worked.
Easy Installer is “updating” things on the target that are not part of an image file and that debris gets left behind to mess things up.
For a medical device there has to be a never-reach-out-to-the-Internet-for-anything-just-use-what-you-have switch. No matter how well intentioned the meaning, nothing can ever change.
I understand that Easy Installer reaches out to the Internet to retrieve a list of images that can be installed. But it shouldn’t actually install anything until prompted to.
Can you observe/determine what is being installed on the device then?
My boss proved this by disconnecting the Dahlia from the Internet and using an older version of Easy Installer (the one we had tested with)
Also what versions of Easy Installer are you referring to here? (Both the new and the old one)
We’ve never heard or seen such reports that Easy Installer “updates” things on the module by itself.
I think you need to stop focusing on the word “install.” EasyInstaller can pooch things if there are any “data values” or “settings” that don’t get reset via a standard image build and deploy. I don’t know about the Dahlia board, but you have such things on the Verdin big board. They are used to enable/disable various devices that share pins.
No.
5.4.0+biuld.4 works
5.5.0+build6 screws the pooch
Don’t know about versions and/or builds in between.
Ok let’s try this then. Are you able to provide me with this custom image of yours?
if yes, then could you provide it to me, as well as detailed instructions on what you are doing and what you are observing. Then I will take your custom image and instructions and try to see if I can reproduce the same observations on my end.
No. Only my employer could do that. All I’m allowed to do at this point is report to you that EasyInstaller is pooching things. The “work around” is to use 5.4 and disconnect everything from the Internet.
Sounds like you’re doing something weird. How do you load TEZI to the module, and how do you provide (USB, SD card, local network) and select your image (GUI, autoinstall)? How does your image.json look like? How do you develop the custom image? You say you “zipped it up”, do you mean you saved the tezi tar file resulted by your build system?
TEZI only gets a list of example reference images from toradex’ servers, but since you use your own image, you don’t need them (or internet). Lack of internet doesn’t give any timeout issues, your image is available as soon as you plug it in (USB, SD, whatever), and it is extracted in correct tree structure to the media (image.json in the root and so on).
TEZI doesn’t install any packages/settings anywhere. Except the image you choose, obviously. What do you mean by “host os”? TEZI? It is just a lightweight linux distribution loaded temporarily in RAM. It wouldn’t even matter if it installed something there.
To me it sounds like you just install wrong image from some other source than you think.
You would be completely incorrect. We have exactly one image. Been the same image since March 25, 2022. This isn’t some IoT hack-on-the-fly project. This is a medical device being developed per FDA regulations.
I’m not authorized to share anymore details. The work around is to use 5.4.0 with both the install computer and Dahlia disconnected from the Internet.
That’s what I’m authorized to share.
Lack of Internet most definitely gives timeout issues as it searches for other packages. Yes, the local one pops up right away, but one can’t actually “do” anything with it until the software has gotten far enough along searching for remote packages.
One navigates to the directory where they downloaded EasyInstaller and unzipped it. They do this in a COMMAND box on Windows 10.
They run the .BAT file to “install” an EasyInstaller image on the target.
Target reboots using that “installed” image. In order to boot that “installed image” said image must configure various devices, most notably the display and mouse. Quite possibly also the CODEC though few people have speakers connected to the target to know. It is here where one can get into trouble if the carrier board has configuration values that it stores. The Verdin full sized board has lots of documented things to connect certain pins to certain devices because they are dual-use and controlled by a value set somewhere. I’m not looking at the doc so I don’t remember the name. I just remember reading these settings persist. I believe, but have not dug into because now that we have a viable work-around it doesn’t matter, that the CODEC must have something similar. At this point in time the booted version of EasyInstaller is technically a “host OS.” It has configured the host so it can operate.
This is all I’m allowed to share.
The work-around is to use 5.4.0 with both Windows 10 computer and the Dahlia don’t have Internet connections until after you have finished installing your image and booted.
If all one is using the CODEC for is an “error buzzer” they won’t notice anything. When using the CODEC for input in a medical diagnosis device, you notice. Something persistent is being retained and it isn’t something normally overwritten/reset by TorizonCore.
Version 5.4.0 doesn’t set whatever this is. 5.5.0 (and I presume later) does.
I’m sorry. That is all I can legally share. Badgering for further details will be pointless.
Well then with all said, I’m not sure how we can possibly help with the issue. Given the strange issue being described here. Along with the lack of information to investigate, or reproduce this issue ourselves.
As long as you have your work-around for your purposes.