BARE METAL VERSUS LINUX IMAGE ON HPS
The Hard Processor System (HPS) side of the board is a processor system, dual ARM core, plus peripherals, which can run either Linux or standalone programs. The system running Linux boots through a boot loader and some startup modules, then firing up Linux itself. The boot loader and startup environment can also transfer control to code that runs without an operating system - this is bare metal mode.
ROLE OF HWLIB
The API and library functions of HWLIB are designed to access and control the SoC resources when running in bare metal mode. One would code applications in C for this purpose, compile them and launch them under the boot loading system.
I had found some makefiles that included the HWLIB modules such that the source code of HWLIB would have been compiled as part of the make process for the example project. I could have made use of this to get my alt_bridge_manager.c code compiled, but this is not the route I want to go. Rather, I want the full Linux environment to support mmap access to files as well as hosting the user interface for my project.
LINUX DRIVERS FOR ACCESS TO SOC RESOURCES
A version of Yocto Linux was created to support the SoC systems such as my Cyclone V based Terasic DE10-Nano board. It provides device drivers to manage all the functions of the SoC, enabling a memory mapped means of controlling everything. Thus, no HWLIB is needed if you will run Linux on the system.
DOCUMENTATION IS SPLIT
I realized why I was having so much difficulty finding this documented. Intel has documented their hardware and toolchains, but points people at a separate rocketboard.org site for anything related to Linux for the SoC.
I had assumed this was just for those who wanted to modify Linux or were interested in how it was built to run on the HPS, but it appears that anything to do with using the SoC under Linux is shoved off to this site. I had worked through several Intel eLearning courses on SoC trying to find anything about accessing the SoC features through apps on Linux, finally realizing that the schism existed.
/RANT
Frankly, the entire experience exposes the lack of concern about the user, with all the decisions for how to organize toolchains (multiple parts not well integrated) and even the divide between Intel and Rocketboards.org, emblematic of a focus on fiefdoms or legal department separations in spite of the fact that this impairs the experience for the user/purchaser of the product.
Convenient for Intel; don't care about the impact on the end user. They could easily have provided some overview level information that describes this taxonomy, artificial to the user but obviously meaningful to various organizations, managers and legal relationships inside Intel. Similarly, they could have provided integrative tutorials and documentation to show the user how to pull together the bits, but this is chaotically strewn through the website.
I hate having my time wasted unnecessarily. I care about the projects, technology and getting things done. It is annoying to have my time diverted from my goals for specious reasons.
/END RANT
That is all just incredible! I'm sorry you're having to struggle through all that, though I do appreciate your chronicle of the process! Though I think I would like to, I've not yet learned how to use FPGAs. But I worked with some engineers who did. There always seemed to be a huge problem every time the version of the software toolset changed, and they seemed to have no choice about whether to update or not. I don't remember whose devices they were using though.
ReplyDeleteSounds like either a job for ChatGPT or output from it.
ReplyDelete