TorizonCore Builder not available in Visual Studio Code

Technical Support
, ,
1

I cannot see the TorizonCore Builder template as an option for a new project in Visual Studio Code.

I have the extension installed (V1.4.0) and it seems to be working fine for application development and debugging.

I have installed TorizonCore Builder as per your doc “TorizonCore Builder Tool - Customizing TorizonCore Images – Setup Script” (as per here) and that all seems fine.

But when I try to create a new Builder Image Customization Project, as described in your doc “TorizonCore Builder VS Code Integration”, as detailed here, I do not see TorizonCore Builder option. This is what I see:

image
image837×544 29.4 KB

I must have missed something in my setup/installation, but I have no idea what. Any ideas?

Thanks for the help,
Peter

2

Hi @bcpberry ,

Currently version 1.4.0 of our IDE extension does not have TorizonCore Builder integration. A new version that has this feature is expected to be released in the next few days.

In the meantime you can uninstall version 1.4.0 and instead use the early access version of our extension, which should have TorizonCore Builder integration. Just keep in mind that this version is in active development and hasn’t been tested thoroughly yet.

Best regards,
Lucas Akira

3

Hi @lucas_a.tx,

Thanks for that information. It would be pretty helpful if that was stated in the docs.

I tried the early access version. The Builder is now there but when I clicked on the “Create Torizon image customization project” all I got was the following error message:

The YAML extension (redhat.vscode-yaml) is required to create TorizonCore Builder customization projects.

So I guess it’s not quite ready for this yet.

Best regards,
Peter

4

Hi @bcpberry ,

I completely agree with you. The TorizonCore Builder integration documentation was published ahead of time, before leaving early access.

My apologies for the inconvenience. I’ll notify this internally to avoid future inconsistencies in our documentation.

About the message you got, you should install the YAML Language Support by Red Hat VSCode extension as stated in TorizonCore Builder VS Code Integration | Toradex Developer Center. This should solve the error.

One final note: the IDE extension uses its own TorizonCore Builder installation, so it is not necessary to run the stand-alone script for TCBuilder before running VSCode.

Let me know if that helps you.

Best regards,
Lucas Akira

5

Hi @lucas_a.tx

Thanks for the response. I note that the installation of the YAML extension is listed as a prerequisite in the docs, so I should have seen that before posting my last question.

So, I have made some progress with this, but not much. Three problems:

  • When selecting the hardware platform from the drop-down list, the one connected was listed with the plug icon, as per the document. However, when then presented with the list of base images, none were marked with the plug icon, contradicting what is in the doc. Since I want to make a minor modification to the image I’m using, this indicator would be very helpful. To move ahead, I chose the one from the list that I think matched the one already loaded.

  • I then modified the splash-screen and build-date values in the tcbuild.yaml, and pressed F5 to build the image. However, the build fails because value of the build-date was rejected. When first opening the file, this value was set to “NaN” and was marked as erroneous with a red squiggly line. I edited it with a valid number but no matter what I enter it is rejected (numbers, “NaN”, “null”) and I cannot proceed with the build. Here’s a pic of what I see:

image

  • To make some progress, I deleted the build-date line, and again pressed F5. The build proceeded but then terminated with a number of “HTTP request failed” errors. I note that the doc says that these are generic error messages, so I looked for the cause of the error in the logs. I see several issues, including:

    • A schema validation error, which I assume is because of my deletion of the build-date line.

    • An entry “An unexpected Exception occured. Please provide the following stack trace to the Toradex TorizonCore support team”

    • An entry “Error: could not find an Easy Installer image in the storage.”

I have uploaded the full output log for your reference.

This is my first attempt at modifying a Torizon image, and I need to do this because I need to modify the Device Tree. I could do it manually (as per your other docs) but I would prefer to use this VS Code integrated method. I understand that this is an “early access” version of this tool, so I am simply happy to help getting it to work, and any help you can provide will be much appreciated.

Kind regards,
Peter

tcbuild log.txt (3.4 KB)

6

Hi @bcpberry ,

However, when then presented with the list of base images, none were marked with the plug icon, contradicting what is in the doc.

Curiously enough I didn’t find this behavior when using a different module (Colibri iMX8X), but I found it when using a Verdin iMX8M Mini, just like you did. I’ll report this internally for further investigation, thank you.

I then modified the splash-screen and build-date values in the tcbuild.yaml, and pressed F5 to build the image. However, the build fails because value of the build-date was rejected. When first opening the file, this value was set to “NaN” and was marked as erroneous with a red squiggly line.

The build-date field refers to the date that a specific TorizonCore version was built and released. It serves as a way to identify our Monthly and Nightly releases, and it isn’t necessary when using a quarterly release.

The fact that the tcbuild.yaml template has this field present when it shouldn’t is a recently found bug that is currently being worked on.

To make some progress, I deleted the build-date line, and again pressed F5.

Right, doing this and one more thing should solve your problem, see below.

The build proceeded but then terminated with a number of “HTTP request failed” errors. I note that the doc says that these are generic error messages, so I looked for the cause of the error in the logs.

I saw your attached logs, and this caught my attention:

[05-02 14:29:46.263] tcbuild.yaml: [...] 'build-number': 13, 'build-date': 'NaN'}}} is not valid under any of the given schemas, while parsing /input

That means that the file being parsed still has the build-date line. The subsequent error messages in the log seem to be a consequence of this one.

I was able to reproduce the log results when deleting the line in question, then pressing F5 to build the image, without saving the YAML file beforehand.

Did you save the tcbuild.yaml file before pressing F5? If not, remove the line, make sure to save the YAML file first and then press F5.

I hope that helps you.

Best regards,
Lucas Akira

7

Hi @lucas_a.tx,

Thanks again. Getting there, but not home yet.

The build seems to now go OK, but there is still a problem:

[05-03 12:57:09.123] Starting http server to serve OSTree.
[05-03 12:57:21.784] Resolving hostname “verdin-imx8mm-06895059.local” using mDNS on all interfaces failed.
[05-03 12:57:21.906] HTTP request failed

I am not sure what the difference is between “mDNS” and normal name resolution. I am able to ping verdin-imx8mm-06895059.local from both the Windows cmd prompt and from WSL, and have other utilities (e.g. PuTTY, WinSCP) that use this name without issues. I did some reading on mDNS but I didn’t find anything that helped.

I tried using the TC Builder Deploy command again on its own but got the same error.

Any ideas?

For reference I’ve uploaded the full log.

Best regards,
Peter

tcbuild log 2.txt (3.7 KB)

8

@bcpberry,

Just to inform you I was able to reproduce this same connection issue on my Windows setup. We’re looking into this now. Strangely enough if I use the TC Builder Deploy command on it’s own but I specify the IP address or just <hostname> (without “local”) then the connection works. But in VSCode it seems to hard-default to <hostname>.local.

We’ll inform you when we figure something out or a workaround here.

9

Hi @jeremias.tx

Thanks for confirming this. And yes, please do let me know when there is a fix available.

In the mean time I have managed to deploy my custom image using the manual Deploy command and the IP address, as per your suggestion. So now I can move on to wrapping my head around actually doing the customization.

The first question that came to mind after doing the deploy was “How can I tell what customized image I have installed?”. I am looking for some way that I can quickly identify my customized image from the SSH prompt, i.e. something I can customize in the tcbuild.yaml file that I can quickly inspect using some command (such as uname).

I tried setting a key/value pair in the customization/kernel/arguments section (as per this example in your docs). The customization appeared to have been built OK - i.e. putting this in the yaml file:

customization:
splash-screen: DataberryLogoTransparent.png
kernel:
arguments:
- databerry=123

resulted in this line in the log:

Kernel custom arguments successfully configured with “databerry=123”.

However, I could not see this when I tried using the sysctl command after the board had re-booted with the new image.

Two questions:

  • What would be your recommendation for doing this?
  • Any idea why the custom argument does not appear to have been applied?

Thanks again for your help.

Peter

10

What would be your recommendation for doing this?

For your first question, there’s a couple of ways to see what “version” of your custom image you have installed. When deploying with TorizonCore Builder you may have seen messages in the output containing various hashes. Particularly on the deploy stage you’ll see something like:

Deploying OSTree with checksum 92cba81e75ce14217f032cf0e81e2de3e97c971249264d39e446842c1a847534

This hash refers to the hash of the custom OS that got deployed. Once you flash/install your custom OS you can see the hash of the running system, by running the following command on the device:

ostree admin status
* torizon 92cba81e75ce14217f032cf0e81e2de3e97c971249264d39e446842c1a847534.0
    Version: 5.7.0-devel-20220524+build.622-tcbuilder.20220610170942
    origin refspec: torizon

Notice how the hash matches the hash from TorizonCore Builder, which makes sense. This is one way you can create this sort of version link. However, this will require you to make note of these hashes as custom images get produced.

If you want a kind of “higher-level” versioning then you could engage with our platform services: Torizon Cloud Overview | Toradex Developer Center

With this you can version your custom OSes and push them to our Platform Services server for easier management and organization. Though this is more of a commercial solution so it may not be suitable for your situation.

Any idea why the custom argument does not appear to have been applied?

I believe you’re looking in the wrong spot. The kernel arguments customization is for setting arguments on the kernel command like. I did a quick test and can see my custom argument on the device like so:

cat /proc/cmdline 
pci=nomsi root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/79606f95a520d7929c1bf5d279521c0b2c530a3f02847dde420fb7377dcdf9e3/0 TEST=1

I hope this helps clear things up.

Best Regards,
Jeremias

11

Thanks again @jeremias.tx for the fast response.

Firstly, responses to your answers:

  • I had read about the use of the hash to identify the image, but I am looking for something a bit easier to read, and yes, something that doesn’t require memorizing the hash from the deploy log.

  • I intend to eventually make use of your OTA service, but at the moment I’m still very much in development mode and am just trying to figure out how all this stuff works and fits together.

  • I had tried using the “cat /proc/cmdline” idea but I still did not see my customized argument.

However, I think I the main problem is that I have not understood something here.

What directory/folder is used when deploying? I ask this because I am confused about the relationship between the “tcbworkdir” (which I initial created following one of your docs), and the folder that I created when starting my own customization project from within VS Code. I assumed that the “tcbworkdir” was just an arbitrarily named directory, and that running the Deploy command from inside this directory would deploy the image it contained. I also assumed that running the Deploy command from the directory created for my own customization project would deploy the image contained in the “output_directory” created by the Build command which I ran from inside VS Code. To add to my confusion about what I’m doing here, this what I see when I run the “ostree admin status” command after doing a number of deployments:

verdin-imx8mm-06895059:~$ ostree admin status
* torizon 0314b9c6fa7de5940b7963d82c6db7e3077d4a478138994602d71586c5afd882.4
Version: 5.6.0+build.13
origin refspec: tcbuilder:0314b9c6fa7de5940b7963d82c6db7e3077d4a478138994602d71586c5afd882
torizon 0314b9c6fa7de5940b7963d82c6db7e3077d4a478138994602d71586c5afd882.3 (rollback)
Version: 5.6.0+build.13
origin refspec: tcbuilder:0314b9c6fa7de5940b7963d82c6db7e3077d4a478138994602d71586c5afd882

Note the “.4” after the first hash, and the “.3 (rollback)” after the second hash. I did some reading on this and it seems that I now have multiple images deployed with the first one being the current booted deployment. What does this mean?

I apologize for this somewhat convoluted post. Perhaps I could summarize all this with this question:

  • If I build the image from VS Code, how should I go about running the manual Deploy command to ensure I deploy the image I have just built?

Best regards,
Peter

12

Ok there are several confusions here. Though I think most of these stem from you trying to use TorizonCore Builder both from the command-line and from VSCode. Since deploying is currently bugged from the VSCode side let’s just focus on the command-line approach for now.

I had read about the use of the hash to identify the image, but I am looking for something a bit easier to read, and yes, something that doesn’t require memorizing the hash from the deploy log.

If you want better version handling then you’ll have to engage with our OTA update system as I mentioned.

I had tried using the “cat /proc/cmdline” idea but I still did not see my customized argument.

Looking at the latest information you supplied, I don’t believe you are actually deploying your changes correctly. Again this is probably from switching between VSCode and command-line methods. I’ll explain further below after I touched on your other points.

What directory/folder is used when deploying?

Your assumptions here are incorrect. TorizonCore Builder does not deploy the working directory it deploys references. When customizations are made with TorizonCore Builder the metadata for these changes are stored in a backend storage that is not typically visible to the user. A reference is made to refer to a set of changes, similar to branches in Git. The deploy command is given a reference to then deploy, not a directory.

Looking at the deployment list you provided I think I know what happened. As you stated you have 4 deployments on this device, however they all have the same hash. You must have deployed basically the same OS 4 times. Also compare your deployment list with mine:

ostree admin status
* torizon 92cba81e75ce14217f032cf0e81e2de3e97c971249264d39e446842c1a847534.0
    Version: 5.7.0-devel-20220524+build.622-tcbuilder.20220610170942
    origin refspec: torizon

Notice how the Version field has *tcbuilder* in it. This signifies that this deployment has been modified by TorizonCore Builder. None of your deployments seem to have this. It seems like you just deployed the base un-modified OS version several times. Which would explain why your kernel argument customization is not seen.

Just to sum it all up, just ignore everything about the VSCode TorizonCore Builder integration for the time being. Follow this article on customizing kernel arguments with TorizonCore Builder: Customizing Kernel Arguments in Torizon | Toradex Developer Center

This article will show you how to properly deploy from the command-line, either using stand-alone commands or the build command.

Best Regards,
Jeremias

13

Hi @jeremias.tx

OK, I’ve done that, and now I’m getting somewhere. Thanks for the expansive answer.

One last question and then I promise I’ll leave this. Is there anything magical about the “tcbworkdir” directory - i.e. is this name assumed as a default or otherwise in any of the commands, or can I create different customization directories of any name in any sub-directory?

Thanks again for your help,
Peter

14

The working directory for TorizonCore Builder is just that a working directory. The name shouldn’t matter.

The only significance is that the working directory and the files/directories in this directory are the only things that TorizonCore Builder can “see”. And this is determined from whatever directory you execute TorizonCore Builder in, meaning it can change from command to command.

For example say you are in directory A with file A. You execute a TorizonCore Builder command while in directory A, from here it can “see” file A. If you move to Directory B and execute another TorizonCore Builder command, the tool will no longer be able to “see” file A since you changed working directories.

To avoid such confusions I always recommend executing all TorizonCore Builder commands from the same directory location.

Best Regards,
Jeremias

15

Thanks @jeremias.tx, that helps. I’m making some progress now.

16

Glad I could help to clarify.

17

Hi @jeremias.tx ,

Just over a year ago I needed to create a customized TorizonCore image. I initially tried using the Toradex Torizon Support extension for Visual Studio Code, but, after much trouble, you advised abandoning this approach because the extension basically was not up to it - please see above.

I am now re-visiting this (and re-learning the whole thing having been working on totally unrelated stuff since then), and my first goal is to upgrade TorizonCore to the latest version (i.e. V5 to V6), and upgrade the Visual Studio Code extension to the latest V2.

My question is this: Is the new V2 extension now working OK to do this image customization, or do you still recommend just doing it all manually (i.e. as you advised in the above posts)?

Peter

18

You should be fine to proceed now with the V2 extensions. Keep in mind our documentation is a bit light regarding the V2 extensions. But for TorizonCore Builder you just need to install an additional extension alongside the main extension: TorizonCore Builder - Visual Studio Marketplace

Then you can create a TorizonCore Builder based project in VS Code. If you have any issues feel free to open another thread so we can tackle the issue there.

Best Regards,
Jeremias