We have a small fleet of DS-5/Development Studio projects that target Cyclone V and we're interested in building these projects in containers. Some questions:
There are a couple of solutions for #4 that we offer.
Fixed Virtual Platforms (FVPs): These are available 'standalone', or as part of the (full) Arm Development Studio.https://developer.arm.com/Tools%20and%20Software/Fixed%20Virtual%20Platforms
A most advanced use case would be to license Arm Fast Models technology to be able to create your own FVP closer to your real hardware.https://developer.arm.com/Tools%20and%20Software/Fast%20Models
Arm Virtual Hardware: Cloud based virtual platforms (both FVP-based and a new technology more suitable for complex Cortex-A systems):https://www.arm.com/products/development-tools/simulation/virtual-hardware
I'm quite stuck on #1 ATM. There a couple constraints I'm working in right now: 1. Must build from Windows and 2. Must build using eclipse/armds_idec. I think we will eventually have to move away from this model as the Windows containers are HUGE and slow, and the full IDE installation seems excessive.
I performed a silent install of ARM DS Intel Edition (at the dev's request) per https://developer.arm.com/documentation/ka004603/latest in a Windows Server Core image and it the installation appears to have completed successfully. However, when I try to start the environment via cmdsuite.exe I get some odd errors:
C:\Program Files\Arm\Development Studio 2022.2\bin>cmdsuite.exe wrapper: Failed to query My Documents directory in registry with error 2cmdsuite.exe wrapper: Could not read environment file C:\Program Files\Arm\Development Studio 2022.2\sw\info\env.ini: Operation not permitted wrapper: Failed to query My Documents directory in registry with error 2Environment configured for Arm Development Studio (build 202220912) Please consult the documentation for available commands and more details WARNING: No compiler toolchain specified for environment You can change the compiler toolchain for this environment at any time by running the 'select_toolchain' command. A default for all future environments can be set with the 'select_default_toolchain' command.
The Server Core image isn't a "complete" Windows API, so there may be something missing here that cmdsuite/armds_idec needs to function properly.
I've never experienced this error before.
I found the below thread (from our older DS-5 toolchain, but the tools share a common ancestry) which may help?https://community.arm.com/support-forums/f/armds-forum/46095/ds-5-eclipse-cannot-read-environment-file-env-ini
That does sound like it would do the trick, but due to the resulting image size/speed we ended up starting with an Ubuntu image and installing ARMDS and a specific version of the ARM compiler requested by the developers and that seems to be working well.
Unfortunately, they appear to have been using a customized version of mkimage in the post-build step that was only built as a Windows exe years ago. I had installed the latest u-boot-tools apt package, but that was apparently generating an img file that had a checksum that didn't match prior builds of the same source.
I was surprised (being new to ES) to find this article: https://www.rocketboards.org/foswiki/Documentation/BuildingBootloaderCycloneVAndArria10 where the instructions have you build u-boot from source.