Flutter not suitable for RaspberryPI 3B+

Flutter seems to be a nice GUI framework to create portable GUIs for all kinds of systems, such as Win, Desktop-Linux, Android, iPhone. Just the latest version doesn’t seem suitable for RaspberryPI 3B+ (1GB RAM) based Linux systems.

I wasn’t even able to produce a native GUI app for RP3B+ at all. The initial set up of Flutter environment on RaspberryPI 3B+ failed already, running out of memory (RAM). And AFAICS the underlying dart compiler does not support cross compilation yet, therefor it is not possible to execute the flutter/dart compiler on amd64 to produce native code for RP3B+/ARMv8.

Flutter seems to be nice for systems with 4GB of RAM or more, but Flutter doesn’t seem suitable for devices such as the RaspberryPI 3B+, providing 1GB of RAM “only”.

Rust borrowing/lifetime & Modules

The connections between modules are the assumptions which the modules make about each other.

David Parnas
Information Distribution Aspects of Design Methodology, 1971

The Rust borrowing and lifetime concept help to express the assumptions being made between modules.

Defining an API, it is not about the signature of methods only, but also about the assumption about the usage and lifetime of the input and output data.

FIT image containing u-boot script

FIT images may be signed and verified by bootloader u-boot, as required for opencritis.org. FIT images may contain multiple images, such as the kernel, fdt device trees initramfs and scritps.

As the FIT image is tagging each embedded element, these entities are embedded in raw format, for example zImage, initrd.cpio and the scripts as simple text files. For example see this fit image declaration of file “image.its”

/dts-v1/;

/ {
  description = "OpenCritis arm/virt FIT Image";
  #address-cells = <1>;

  images {
          kernel {
             description = "Kernel";
             data = /incbin/("zImage");
             type = "kernel";
             arch = "arm";
             os = "linux";
             compression = "none";
             load = <0x40400000>;
             entry = <0x40400000>;
             hash {
                algo = "sha256";
             };
          };

          fdt {
            description = "Flattened Device tree";
            data = /incbin/("nxp6ulevk.dtb");
            type = "flat_dt";
            arch = "ARM";
            compression = "none";
            hash {
      	       algo = "sha256";
            };
        };
 
      bootscript {
        description = "Bootscript";
        data = /incbin/("u-boot.scr");
        type = "script";
        compression = "none";
      };           
};

configurations {
      default = "standard";
      standard {
            description = "Standard Boot";
            kernel = "kernel";
            fdt = "fdt";
            hash {
                    algo = "sha256";
            };
      };
   };
};

An u-boot script “u-boot.scr” has the form:

setenv bootargs "console=ttyAMA0,115200 ro rootwait root=/dev/sda2"
bootm  ${loadaddr}
echo "Bad image or kernel."
reset

The fit image “image.ub” is generated using the following command

mkimage -f image.its image.ub

Loading a fit image and sourcing the script is done as follows:

setenv loadaddr 0x48000000
fatload mmc 0:1  ${loadaddr} image.ub
source ${loadaddr}:bootscript

Note: indexed node names will be refused by u-boot FIT parser yielding “Bad FIT image format”, for example do not use the following form 

...
script@1 { .... };