Port to other Cortex A single board computer?

[dirkarnez]

I love Circle for its simplicity. Is it technically convenient to edit Circle in order to port to other Cortex A single board computer (for example: change the GPIO settings, etc.) or start baremetal development environment from scratch instead? Looking for cheaper RPI alternatives, and cannot find any baremetal library similar to Circle at the moment.

[rsta2]

I'm trying to keep things simple. I'm glad, that this can be seen. Circle is very much targeted on the Raspberry Pi. Some classes could be reused on other SBCs, but most of the drivers probably not.

[rsta2]

Agreed, but I was addressing @dirkarnez's and other bare-metal apps here. ;)

[dirkarnez]

@rsta2 Thanks bro i noticed Raspberry Pi Zero 2 W and some other minimalistic SBC, products in RPI family is great, but it seems they all don't have built-in analog pins hahaha, it makes the purchase not really worthy hahaha even the alternatives are much cheaper 😢.

After Circle opening the door of baremetal programming i am learning to port desktop apps to Cortex A* CPU and make use of hardware peripherals like analog input and i don't want to touch any RPI add-on boards for ADC or other functionalities because i want to target Cortex A* CPU for product making and not to depend on RPI products. Oh it is very difficult hahaha.

May i know is Circle made possible because of the publicly available documentation or you have also done some reverse-engineering? Oh i found some Linux kernel and UBoot reference hahaha. I am so afraid the CPU i buy in the future is lacking hardware information to do any development and waste money hahahah!

[dirkarnez]

@znmeb i am looking for 2G at least for running desktop app ports... so....

[rsta2]

Raspberry Pi offers documents about the hardware of their SBCs, especially of the peripherals. Also the community forum is a great help. It will also help, if you are good in reading Linux kernel sources. BTW. I understand, that you have your requirements, but attaching a cheap ADC (e.g. MCP3008 via SPI) is not a big deal.

[dirkarnez]

I see, yes, i was buying exactly MCP3008 for RPI hahahah!

[dirkarnez]

@rsta2 Hello bro, i am learning how did you deal with .dtb files (https://github.com/raspberrypi/firmware/tree/master/boot) but i have no clue from read this repo, may i ask how did you make them work inside Circle programs please? It seems they are prebuilt binaries, is there some interfaces or calling conventions for us to invoke functions inside them for initializing some peripherals maybe? Sorry i am super newbie to ask :P I have found circle/devicetreeblob.h but may i ask how did you know what content inside the .dtb files is helpful? Thank you so much!

[rsta2]

.dtb (Device Tree Blob) files are compiled from .dts (Device Tree Source) files with the dtc compiler. Some .dtb files come with the Raspberry Pi firmware (normally one for each RPi model), and they describe the hardware configuration for devices, which cannot be detected automatically (not like USB devices for example). They have a tree structure. There are also Device Tree Overlay files (.dtbo) which can be specified in config.txt and which enable specific hardware features. But this is not used by Circle.

Circle needs Device Tree access, to be able to fetch some necessary configuration parameters (e.g. memory address windows or MAC addresses of network devices). The class CMachineInfo holds a copy of the Device Tree Blob in memory and provides a pointer to an instance of the class CDeviceTreeBlob, which can be used to parse the tree structure and to fetch specific configuration values, which are of interest.

Please have a look at this example, which fetches the MAC address for the MACB Ethernet NIC of the RPi 5 from the Device Tree.

An Device Tree .dtb file can be translated into its source using the dtc compiler with:

dtc -I dtb -O dts filename.dtb > filename.dts

With this you can look into the definitions and find the values, that you need.

[dirkarnez]

@rsta2 Wow thank you so much for the details! It seems like the dts is just like a specialized version of json-like file XDXD, I looked at the mac address example and then found the device tree specification that shows meaning of those properties!

But let's say for example there are some peripherals that the company gives us the dtb and the linux drivers (e.g. GPU driver on Linux), to make such GPU work on baremetal environment like Circle, does it mean we must rewrite these Linux drivers / HAL from scratch without any chance of leveraging the Linux-dependent driver / HAL code ?

[rsta2]

You are welcome. Yes, Linux drivers must be ported. One could try to emulate some functions of the Linux kernel driver API in the bare metal code, but if you want to emulate the whole API, you could also build another Linux. Not possible. So you must modify the Linux drivers. Especially the Device Tree code could be replaced by hard-coded values, at least for values, which do not change. But for the GPU driver it's more the higher level DRM (Direct Rendering Manager) API, which is the problem. Difficult to see through.

[dirkarnez]

Omg, i did not thought of Direct Rendering Manager in between the GPU and the baremetal environment! too many porting work 😣