The STM32MP257F-EV1

 This is the follow on to the STM32MP1 series. This time a dual core Cortex-A35 a Cortex-M33 and a Cortex-M0+.

As shipped, they provide a 16G micro SD card with Linux on it. That card is partitioned with a lot of odd small partitions. The important ones are at the end, p10 and p11. Unfortunately p10, the / partition is only 4G so immediately there is a storage crisis when you start populating the usual tools. A quick dd from that card to a 256G card I had lying around and we now have a start of something useful. Next is to run gparted on my RPi5 and first move p11 which is /usr/local to 1MiB from the end. Don't leave that as 0 or the move will fail. Once moved, you can resize p10 to be 200+G. Now we have some useful space.

I added a user with sudoers privs. There is no date/time setup when it boots, that needs to get rectified with a ntp callout. 

Now... there is no C compiler or binutils. binutils got installed. Lots of apt update -> apt install xyz's.
Here is an interesting factoid, the CPU in this platform is aarch64.... so is the RPi5.... I wonder... if tools built over on the RPi5 can run on the STM32MP2? So... a huge gcc14 tree I built on the RPi5 was transferred over the ethernet interface. After unpacking that... wouldn't you know the native gcc build from the RPi5... runs! It's not that climactic as you would expect that for text based tools, the system calls and lib calls would be satisfied... and they are. With that 30GB tree... will my Ada compiler allow local builds as well? Another large tree copied over from the RPi5, went to one of my working dirs and build a recent project I was working on. Amazingly... I get an ELF file at the end after a clean build, no issues. There are two flavours of compiler, the aarch64 C,C++,Ada and 32bit arm for the Cortex-M's. All of them work fine w/o any local building of toolchains.

Where am I now... currently... finding out how to get an ELF FW into the on chip Cortex-M33. This seems to need some remote procedure incantations. I am studying this. I can guarantee you, on this earth, no-one has run Ada on the Cortex-M33 inside the STM32MP257... yet! I am also thinking about how to debug that Cortex-M33. Part of me wonders if an openocd dongle on the STM32MP257F-EV1's USB port could connect up with the JTAG for it...

Btw, my native RPi5 gcc14 also works, here is a GPIO toggler for GPIOJ[6], the orange LED (LD3).

#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ioctl.h>
#include <unistd.h>

#include <linux/gpio.h>

int main(int argc, char **argv)
{
    struct gpiohandle_request req;
    struct gpiohandle_data data;
    char chrdev_name[20];
    int fd, ret;

    strcpy(chrdev_name, "/dev/gpiochip9");

    /*  Open device: gpiochip9 for GPIO bank J */
    fd = open(chrdev_name, 0);
    if (fd == -1) {
        ret = -errno;
        fprintf(stderr, "Failed to open %s\n", chrdev_name);

        return ret;
    }

    /* request GPIO line: GPIO_J_6 */
    req.lineoffsets[0] = 6;
    req.flags = GPIOHANDLE_REQUEST_OUTPUT;
    memcpy(req.default_values, &data, sizeof(req.default_values));
    strcpy(req.consumer_label, "led_gpio_j_6");
    req.lines  = 1;

    ret = ioctl(fd, GPIO_GET_LINEHANDLE_IOCTL, &req);
    if (ret == -1) {
        ret = -errno;
        fprintf(stderr, "Failed to issue GET LINEHANDLE IOCTL (%d)\n",
                ret);
    }
    if (close(fd) == -1)
        perror("Failed to close GPIO character device file");

    /*  Start led blinking */
    while(1) {

        data.values[0] = !data.values[0];
        ret = ioctl(req.fd, GPIOHANDLE_SET_LINE_VALUES_IOCTL, &data);
        if (ret == -1) {
            ret = -errno;
            fprintf(stderr, "Failed to issue %s (%d)\n",
                    "GPIOHANDLE_SET_LINE_VALUES_IOCTL", ret);
        }
        sleep(1);
    }

    /*  release line */
    ret = close(req.fd);
    if (ret == -1) {
        perror("Failed to close GPIO LINEHANDLE device file");
        ret = -errno;
    }
    return ret;
}