• Bare metal programming on the Pi

    From bob prohaska@3:770/3 to All on Sat Dec 19 16:58:30 2020
    Found a somewhat readable (for a non-programmer) account of how to
    load and run "bare metal" programs on a Pi4. It's at: https://isometimes.github.io/rpi4-osdev/

    The author still uses u-boot to load and run his code, leaving the question
    of how much code he _didn't_ write remains resident and active.

    I'm getting the impression that u-boot starts a considerable amount of
    activity on the GPU. Does it simply go away once an introduced kernel is started? Later on in the tutorial it's clear that bluetooth requires
    its own software, which doesn't appear to be open source.

    So, just how "bare" is bare metal on the Pi?

    Thanks for reading,

    bob prohaska

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to bob prohaska on Sat Dec 19 17:43:54 2020
    On Sat, 19 Dec 2020 16:58:30 -0000 (UTC)
    bob prohaska <bp@www.zefox.net> wrote:

    I'm getting the impression that u-boot starts a considerable amount of activity on the GPU. Does it simply go away once an introduced kernel is started? Later on in the tutorial it's clear that bluetooth requires
    its own software, which doesn't appear to be open source.

    So, just how "bare" is bare metal on the Pi?

    AIUI the GPU is really in control of the hardware, all the code
    that runs on the GPU is closed source binary blobs and there's quite a lot
    of it.

    --
    Steve O'Hara-Smith | Directable Mirror Arrays C:\>WIN | A better way to focus the sun
    The computer obeys and wins. | licences available see
    You lose and Bill collects. | http://www.sohara.org/

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to bob prohaska on Sat Dec 19 21:04:25 2020
    bob prohaska <bp@www.zefox.net> wrote:
    Found a somewhat readable (for a non-programmer) account of how to
    load and run "bare metal" programs on a Pi4. It's at: https://isometimes.github.io/rpi4-osdev/

    The author still uses u-boot to load and run his code, leaving the question of how much code he _didn't_ write remains resident and active.

    I'm getting the impression that u-boot starts a considerable amount of activity on the GPU. Does it simply go away once an introduced kernel is started? Later on in the tutorial it's clear that bluetooth requires
    its own software, which doesn't appear to be open source.

    The GPU runs its own OS and provides services to the ARM cores via the 'mailbox' interface. Other components (eg wifi and bluetooth) contain their own processors running their own software stacks. In general you don't get sources to software running on 'peripherals'.

    On Pis 1-3 the GPU boots *first* and then loads the kernel ready for the
    ARM. On Pi4 it's a more 'normal' system with the ARM in charge.

    So, just how "bare" is bare metal on the Pi?

    You can get the ARM cores to yourself if you want. It is possible to keep u-boot
    in memory to provide 'firmware' services that your operating system doesn't provide, and there's also TrustZone, although I don't think the Pi
    environment uses that out of the box (I'm less familiar with Pi4).

    If you want to do bare-metal things without U-boot, there's BakingPi: https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/
    although that's written for the Pi1 and will need small changes for Pis
    0/2/3. I'm not sure it'll work on Pi4. There are some PRs for supporting other Pis (Alex hasn't been able to work on it for a while): https://github.com/Chadderz121/bakingpi-www

    Theo

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From bob prohaska@3:770/3 to Theo on Sun Dec 20 00:10:03 2020
    Theo <theom+news@chiark.greenend.org.uk> wrote:
    You can get the ARM cores to yourself if you want. It is possible to keep
    u-boot
    in memory to provide 'firmware' services that your operating system doesn't provide, and there's also TrustZone, although I don't think the Pi environment uses that out of the box (I'm less familiar with Pi4).

    Can the firmware services alluded to be called by a user logged in
    through a "normal" connection? I.e., bypassing normal security and authentication mechanisms? That's not an issue if the firmware is removed/overwritten by the loaded operating system, but if u-boot
    remains I understand much better the objections raised by open source advocates.

    If you want to do bare-metal things without U-boot, there's BakingPi: https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/
    although that's written for the Pi1 and will need small changes for Pis 0/2/3. I'm not sure it'll work on Pi4. There are some PRs for supporting other Pis (Alex hasn't been able to work on it for a while): https://github.com/Chadderz121/bakingpi-www

    Thank you for a highly informative reply. I'm not competent to do much
    with BakingPi, certainly nothing remotely useful, but it gives insights
    which I didn't have before.

    bob prohaska

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to bob prohaska on Sun Dec 20 13:36:40 2020
    bob prohaska <bp@www.zefox.net> wrote:
    Theo <theom+news@chiark.greenend.org.uk> wrote:
    You can get the ARM cores to yourself if you want. It is possible to keep
    u-boot
    in memory to provide 'firmware' services that your operating system
    doesn't
    provide, and there's also TrustZone, although I don't think the Pi environment uses that out of the box (I'm less familiar with Pi4).

    Can the firmware services alluded to be called by a user logged in
    through a "normal" connection? I.e., bypassing normal security and authentication mechanisms? That's not an issue if the firmware is removed/overwritten by the loaded operating system, but if u-boot
    remains I understand much better the objections raised by open source advocates.

    If you're running regular Linux, generally not from userland. If you're running bare-metal, you have kernel privilege so it's up to you how you set things up. You could choose to overwrite u-boot if you don't want it
    present.

    If you have TrustZone, your code running outside TrustZone is
    protected from trampling over the TZ firmware. If you want to get rid of
    that firmware you need your bootloader to run things inside the TrustZone.
    (I don't believe the Pi does anything with TZ by default and may not have TZ support in the hardware)

    Theo

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)