3 ms·

Every working microprocessor ever created can run bare metal code.

mathisfun123 3y ago
Whether it was clear to you or that OP specifically was asking about the GPU, you shouldn't be so confident in universals like this. In this case, it turns out to be basically false in that the driver for the GPU is closed source: https://electronics.stackexchange.com/questions/512232/stm32mp157-gpu-documentation https://electronics.stackexchange.com/questions/512232/stm32...
- bullen 3y ago
  "however it mentions that it supports OpenGL ES 2.1 API" Without 3+ you miss out on VAO which IMO is the last GL feature.
- mikepavone 3y ago
  There is an open source driver for Vivante GPUs, including the GC400 (or maybe GCNano? and the official docs are oddly vague on what GPU is used and 3rd party sources disagree) used in the STM32MP157: etnaviv. I can't seem to find anything on what's in the STM32MP2 though other than that it supports Vulkan though. Not sure why ST is so tight-lipped on what GPU IP they're using
the__alchemist 3y ago
This seems to blur the lines. Writing bare metal for Cortex-M is straightforward. For your desktop or laptop PC? Your phone? Doable OFC, but probably very difficult.
- flyingcircus3 3y ago
  Sure. But that difficulty all comes down to whose shoulders you stand on. If the peripherals' functionalities and their registers are fully described in a datasheet, and you have a working toolchain, and a viable method for loading binaries, then you are set. Additional libraries on top would make it even easier, but you at least have the device's specifications. Companies like Qualcomm, Broadcom, and Marvell are notorious for locking down their documentation. If you're not shipping millions of units, they're not going to give you the time of day. And even if they are willing to work with you, they're not going to provide you with full register maps, or really anything that would allow you to be independent of them. Instead, they'll give you binary blobs that handle low level details. Every datasheet is watermarked, and NDAs are required to get them. Most of the other big players, STMicro, Texas Instruments, Nordic, Microchip, etc, are far more open. Just about all of their parts are well documented, and those documents are freely available.
  - the__alchemist 3y ago
    ST's RMs are a bit of a pain, but the info is there, and reasonably consistent. The SVDs have many errors, and inconsistent between variants, but there are some open source patch systems available. (Like SVD2Rust). It's nice ST is getting into this space, even though I don't have a use case for this type of device now. As you mention, Nordic's docs are great too. I noticed for a certain ST part (rangefinder), instead of a documented register API, there was a C library for it. I posted on their forum because I was confused (and not using C). An engineer explained that they did it that way because at the hardware level, the device was very complicated, and they weren't sure the best ways to configure it; they wanted to leave open the option to change it later. So, not obfuscation like you're describing with the *COMs, but a technical decision to use a library.

Whether it was clear to you or that OP specifically was asking about the GPU, you shouldn't be so confident in universals like this. In this case, it turns out to be basically false in that the driver for the GPU is closed source: https://electronics.stackexchange.com/questions/512232/stm32mp157-gpu-documentation https://electronics.stackexchange.com/questions/512232/stm32...

bullen 3y ago
"however it mentions that it supports OpenGL ES 2.1 API" Without 3+ you miss out on VAO which IMO is the last GL feature.
mikepavone 3y ago
There is an open source driver for Vivante GPUs, including the GC400 (or maybe GCNano? and the official docs are oddly vague on what GPU is used and 3rd party sources disagree) used in the STM32MP157: etnaviv. I can't seem to find anything on what's in the STM32MP2 though other than that it supports Vulkan though. Not sure why ST is so tight-lipped on what GPU IP they're using

the__alchemist 3y ago

This seems to blur the lines. Writing bare metal for Cortex-M is straightforward. For your desktop or laptop PC? Your phone? Doable OFC, but probably very difficult.

flyingcircus3 3y ago
Sure. But that difficulty all comes down to whose shoulders you stand on. If the peripherals' functionalities and their registers are fully described in a datasheet, and you have a working toolchain, and a viable method for loading binaries, then you are set. Additional libraries on top would make it even easier, but you at least have the device's specifications. Companies like Qualcomm, Broadcom, and Marvell are notorious for locking down their documentation. If you're not shipping millions of units, they're not going to give you the time of day. And even if they are willing to work with you, they're not going to provide you with full register maps, or really anything that would allow you to be independent of them. Instead, they'll give you binary blobs that handle low level details. Every datasheet is watermarked, and NDAs are required to get them. Most of the other big players, STMicro, Texas Instruments, Nordic, Microchip, etc, are far more open. Just about all of their parts are well documented, and those documents are freely available.
- the__alchemist 3y ago
  ST's RMs are a bit of a pain, but the info is there, and reasonably consistent. The SVDs have many errors, and inconsistent between variants, but there are some open source patch systems available. (Like SVD2Rust). It's nice ST is getting into this space, even though I don't have a use case for this type of device now. As you mention, Nordic's docs are great too. I noticed for a certain ST part (rangefinder), instead of a documented register API, there was a C library for it. I posted on their forum because I was confused (and not using C). An engineer explained that they did it that way because at the hardware level, the device was very complicated, and they weren't sure the best ways to configure it; they wanted to leave open the option to change it later. So, not obfuscation like you're describing with the *COMs, but a technical decision to use a library.