@jeremias.tx
Well, now I am not sure what to think. I had a “Hello world” project and I tried to run it. I get the same issue. I think the docker image is not running which crashes the debugger. Where to i find the steps to start the docker image? So, if I was still running V2 Beta, would that make a difference?
Do we have a list of overlays used to build the dev board?
Steve
I’m still highly skeptical that the device tree change caused this, all we did was enable another i2c. It does not make any sense, unless you can offer an explanation. What this looks like is an issue with your development environment specifically. Otherwise there is no reason I would not see the same issue as well since I have the exact same device tree change as you.
You’ve seen my overlay and my tcbuild.yaml, you should know exactly how my OS image is configured. Despite this I don’t have any issues deploying and debugging with VSCode.
Where to i find the steps to start the docker image?
If you look at your VSCode logs you can literally see the commands that are being ran on the device:
All it does is scp the docker-compose.yml file from your project to the Toradex module. Then it runs the docker-compose command as shown in the picture above. Of course the IP address and name will be different for your project, but again you can look in your logs to see what commands are being ran.
So, if I was still running V2 Beta, would that make a difference?
I’m not sure what you’re talking about here. Are you talking about the IDE extension? It’s no longer in Beta anymore, what version are you even running? Version 2.4 of our extension is out already: Torizon IDE Extension - Visual Studio Marketplace
Do we have a list of overlays used to build the dev board?
I don’t know what you mean here overlays are not used to build the dev board. Overlays are not the same thing as device trees, please stop confusing these terms. Our default image uses the device tree for the dev board by default, you don’t need to do anything to configure it for the dev board.
If you copy my work exactly as I shared above, you will have exactly what I have on my device. A Torizon image with the default dev board device tree with an overlay that enables an additional i2c. That is all we discussed on this thread, that is all I have.
I do not know what else I can tell you. I’ve shown you exactly everything I’ve done and I can’t reproduce this issue that you’re having.
Best Regards,
Jeremias
@jeremias.tx
I understand your frustration here. I am just trying to get to the bottom of the issue. Clearly, the container is not runing, as there are no logs after it’s up and it the system doesn’t even know it existed, yet I can see it up by using the docker ps command. But it’s only up a few seconds.
Also you are running 6.5 and I am running 6.4. Maybe that is the difference?
And in the files, I saw reference to a beta version for V2. I am not sure how to check what I have.
And If overlays are not used to build the dev board, then why do we need the clear: true to remove them? There are clearly HDMI and other overlays that are added that aren’t in the build we have the overlays removed, otherwise the i2c-6 would show up and it doesn’t.
Steve
Am I missing something here?
Alsot you are runnig 6.5 and I am running 6.4. Maybe that is the difference?
This should make virtually 0 difference for a hello-world application. Again this would not make a lot of sense. But did you try 6.5 as a sanity test to match my environment?
And If overlays are not used to build the dev board, then why do we need the clear: true to remove them?
You’re not using the right terminology here and it’s very confusing. We have a set of default overlays that get applied in our images, they are not used to “build” the dev board as you said. These overlays just enable basic stuff like HDMI for evaluation purposes. But since all you care about here is enabling i2c we remove these overlays cause they cause conflict. One of these default overlays uses SODIMM 19, which is why I asked you to remove these overlays with clear: true otherwise your i2c can’t use SODIMM 19 at the same time. Does that make sense?
And in the files, I saw reference to a beta version for V2. I am not sure how to check what I have.
You can check the version of your installed extensions in the extensions menu of VSCode.
At this point could you just try re-installing the IDE extension environment cause nothing here is making sense anymore from my perspective.
To summarize, all I did here was take our 6.5.0 release image. Remove the default overlays for things like HDMI to avoid pin conflicts. Apply the i2c overlay to enable an additional overlay. Nothing about this should have any effect on the VSCode side of things.
Best Regards,
Jeremias
@jeremias.tx
OK, yes that makes sense.
In an earlier version, I tried disabling the HDMI and associated pins. I might try that again and see if that makes any difference.
Yes, I agree, nothing here makes any sense.
Even more, I tried launching the docker container manually with a continuous command in the docker-compose.yml to make is stay up. It does seem to stay up longer, but after its gone, it is like it was never up in the first place, which is why I think that it is a docker issue. Here is some more info:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
981d3a80caa7 192.168.12.185:5002/gimbal3bcontainer-debug:arm64 “bash -c 'tail -f /d…” 19 seconds ago Up 18 seconds torizon-gimbal3bcontainer-debug-1
6bbbbe3286ad moby/buildkit:buildx-stable-1 “buildkitd” 21 hours ago Exited (1) 15 hours ago buildx_buildkit_default
56c5cab65308 107cd23a43de “/usr/sbin/sshd -D” 21 hours ago Exited (0) 21 hours ago trusting_ardinghelli
b1c6f714141b 107cd23a43de “/usr/sbin/sshd -D” 21 hours ago Exited (0) 21 hours ago sweet_maxwell
torizon@verdin-imx8mp-14762705:~$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
6b39a132590f torizon/weston-vivante “/usr/bin/entry.sh” 1 second ago Created torizon-weston-1
90e5294fc311 portainer/portainer-ce “/portainer --templa…” 1 second ago Created torizon-portainer-1
6bbbbe3286ad moby/buildkit:buildx-stable-1 “buildkitd” 21 hours ago Exited (1) 15 hours ago buildx_buildkit_default
56c5cab65308 107cd23a43de “/usr/sbin/sshd -D” 21 hours ago Exited (0) 21 hours ago trusting_ardinghelli
b1c6f714141b 107cd23a43de “/usr/sbin/sshd -D” 21 hours ago Exited (0) 21 hours ago sweet_maxwell
torizon@verdin-imx8mp-14762705:~$
As you can see, in the last check with docker ps -a it clearly shows that the container was up 18 seconds. That is the most I can get it to stay up is about 18 seconds. In the next execution of that roughly 3 seconds later, there is no evidence it was ever there. Which is really odd, since exited containers that were running usually show up in that list. If the container goes away, it would explain why the debugger or the app exits with an abnormal exit. This should be up continuously.
So, I went back to the full build where there is an i2c-6 and thus and hdmi port. If I run the same command of starting the docker, it stays up. In the previous example I added a echo “test” within the continous loop and now when I stop the container, I can use docker logs -t and use the ID of the container and I get a string of “test” output in the logs.
So, my conclusion is that for some reason, the docker that is launched won’t run on the BSP. Not sure why yours does.
I did check my version of the extension and it is the latest, v2.4.1.
Just not sure why yours works and mine doesn’t.
It’s hard to tell from your output here what’s going on. Can you try removing all unneeded container and container images. Can you get any logs from this debug container that exits immediately?
All the debug container does is setup SSH as you can see it’s main process is /usr/sbin/sshd -D not something that should just exit immediately.
So, I went back to the full build where there is an i2c-6 and thus and hdmi port. If I run the same command of starting the docker, it stays up.
Why would a simple hello-world type application care about i2c6 and hdmi being enabled on the device? For me it doesn’t matter what interfaces I have, for a hello-world it just runs. You sure nothing else is being changed in the OS build? Can you share your full tcbuild.yml file and your overlay file again, I just want to make sure.
What happens if you just remove the default overlays but don’t add the i2c overlay? So basically just clear the overlays from the image but don’t add your own.
I still think it might be quicker for you to just reset your entire development environment from re-installing the device to re-installing the IDE extension. Otherwise I don’t know when or if we’ll even find out what’s wrong with your current setup.
Best Regards,
Jeremias
@jeremias.tx
Well, just as a FYI, if I added back in the hdmi overlay after the overlay clear, the docker image stays up. That tells me that the HDMI has something to do with the docker container, needing a video and or sound output. I reversed the order of the way the overlays were added and added my overlay first, then the HDMI. Now my I2C takes precedence so I can debug and run my code!
Anyway, I am up and running again. Thanks for the help and patience!
Steve
Did your code even have any reliance on i2c/hdmi?
No, we have no current need for HDMI, I2C yes, but even removing the i2c5 from the compose file, didn’t allow the container to run. Once i2c5 was, there, I could get the correct responses at the proper addresses. But I think that the container must have a video requirement and if the HDMI overly isn’t enabled, there isn’t a video component there and it exits before it’s really fully up.
Steve
Are you using one of the project templates that need display output? For my hello-world test I just used the C++ Makefile template and that did not need HDMI at all.
@jeremias.tx
I did Hello World months ago. As far as I know, I just used the single file c++ project. Is there a way to tell in the debug or dockerFile?
Steve
Well if there’s a Weston container involved, usually that’s a good indication that graphics of some kind are being used. Though you experienced this issue with a hello-world project, so I’m really not sure what to say there.
On my side HDMI was completely disabled and I had no displays of any kind attached to my device. With this I was able to debug a simple hello-world with no issues. It’s very strange how your setup is behaving differently.
Best Regards,
Jeremias
@jeremias.tx
There is no direct call for a Weston Container, but I am running torizon with the built in containers preprovisioned.
These are the apps that I’ve added to my container in the dockerfile.debug:
iproute2
can-utils
vim
python3
python3-pip
python3-setuptools
python3-can
python3-spidev
net-tools \
All recommended by the CAN and SPI examples. But none of these should require a Graphic port that I know of.
Steve
@jeremias.tx
I did try downloading and installing 6.5.0. But I can’t debug with this for some reason. I am getting this error:
time=“2024-02-26T18:50:12Z” level=warning msg=“The "DOCKER_LOGIN" variable is not set. Defaulting to a blank string.”
gimbal3bcontainer-debug Pulling
gimbal3bcontainer-debug Warning
WARNING: Some service image(s) must be built from source by running:
docker compose build gimbal3bcontainer-debug
1 error occurred:
* Error response from daemon: Get “https://192.168.12.185:5002/v2/”: http: server gave HTTP response to HTTPS client
I thought the build of the image was completed by the VSCode and the power shell commands.
Steve
The part about http: server gave HTTP response to HTTPS client is the core issue here. Sounds similar to what happened here: Problem setting Torizon with Python app template
When you re-flashed your device to 6.5.0 did you remove and re-add it to the extension?
If yes, could you check the contents of /etc/docker/daemon.json on your device as suggested in the other post I just linked.
Best Regards,
Jeremias
I don’t have the file on my device. I wouldn’t expect it either if I am redownloading a torizon build since the drive is nuked before it downloads it.
I checked with my other colleague and he doesn’t have it on his either. Also, the setting in .vscode/settings.json of apollox.overwriteHostIp isn’t there either.
I noticed that the “apollox” has been dropped from the torizon IDE Extension 2.4.1 (version is actually v2.4.120) name. I am assuming it is the right one since there doesn’t seem to be any others listed.
Steve
I don’t have the file on my device. I wouldn’t expect it either if I am redownloading a torizon build since the drive is nuked before it downloads it.
Okay, but if you re-add your device into the extension like add it as a new device, this file does not get created? The extension should automatically create this file on the device when you add it to the extension.
I checked with my other colleague and he doesn’t have it on his either. Also, the setting in .vscode/settings.json of apollox.overwriteHostIp isn’t there either.
You can add this option to settings.json it’s not written in there by default.
Best Regards,
Jeremias
@jeremias.tx
Yes, it turns out that the file is created when you remove and re-add your board. And then the docker debug build occurs when you run debug. I will try removing the HDMI for the build to see if the docker container will run.
Steve
@jeremias.tx
So, when I boot up with this change, there is still a conflict that I see in the bootup from the debug port:
[ 0.881868] imx-drm display-subsystem: no available port
[ 1.012856] pca953x 3-0021: failed writing register
[ 1.078520] clk: failed to reparent hsio_axi to sys_pll2_500m: -16
[ 1.092347] clk: failed to reparent hsio_axi to sys_pll2_500m: -16
[ 1.103107] clk: failed to reparent hsio_axi to sys_pll2_500m: -16
[ 2.383420] +V3.3_SW: Underflow of regulator enable count
Starting version 250.5+
[ 6.593194] ina2xx 3-0040: error configuring the device: -6
[ 6.699882] imx8mp-pinctrl 30330000.pinctrl: pin MX8MP_IOMUXC_SAI5_RXFS already requested by 30ae0000.i2c; cannot claim for 3-001a
[ 6.712521] imx8mp-pinctrl 30330000.pinctrl: pin-75 (3-001a) status -22
[ 6.719230] imx8mp-pinctrl 30330000.pinctrl: could not request pin 75 (MX8MP_IOMUXC_SAI5_RXFS) from group sai1grp on device 30330000.pinctrl
[ 6.741419] nau8822 3-001a: Error applying setting, reverse things back
So, while it is working, this doesn’t show up as conflict in the pinout designer. In the imx8mp-verdin.dtsi it is listed as part of the sailgrp, which the pin is the AUDIOMIX_SAI1_TX_DATA00. Again, not in the pinout designer.
Also, many of the names in the pinout designer, don’t correspond to the names in the files. I think it has something to do with a sound driver? But I can’t seem to disable the right thing to make this go away. I tried to disable the sailgrp, but then it won’t boot up right and does a continuous reboot.
The reason I am chasing this, is it is slowing up the boot up process.
Thanks,
Steve
@jeremias.tx
It had something do to with the sound. I had disabled hdmi sound but that didn’t seem to do anything.
I added the following after removing the hdmi overlay from the build:
&lcdif3 {
status = “disabled”;
};
&nau8822_1a {
status = “disabled”;
};
&sound_card {
status = “disabled”;
};
I still get a configuration error but it boots to the login >20 seconds faster.
[ 5.993686] ina2xx 3-0040: error configuring the device: -6
The i2c6 is gone and i2c5 works as it should. Oh and this is using 6.5 without the preconfigured containers and I am able to debug just fine. At some point, I may go back to 6.4.0 to see if I can debug with this same setup, i.e. not adding in the hdmi overlay.
Oh and thanks for all your patience and help!
Steve
