[HN Gopher] Ultiboberon - Oberon on bare metal Raspberry Pi
       ___________________________________________________________________
        
       Ultiboberon - Oberon on bare metal Raspberry Pi
        
       Author : xkriva11
       Score  : 94 points
       Date   : 2021-04-04 08:45 UTC (14 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | [deleted]
        
       | bsenftner wrote:
       | > "Ultibo core is an embedded or bare metal development
       | environment for Raspberry Pi. It is not an operating system but
       | provides many of the same services as an OS, things like memory
       | management, networking, filesystems and threading plus much
       | more."
       | 
       | Is there a name or term for a library that provides OS Services
       | in such a manner that the final application does not need an OS
       | to run?
       | 
       | Such a technique strikes me as a great way to eliminate the huge
       | space of possible system exploits. We all have clients with
       | dedicated systems devoted to running specific applications; why
       | not make those system truly dedicated with no OS, just the
       | dedicated application supplying all OS needs within itself?
        
         | arbitrage wrote:
         | > Is there a name or term for a library that provides OS
         | Services in such a manner
         | 
         | Yes, it's called an OS. Absurd reductionist cultivating of a
         | zoo of hyper-focused jargon to create the illusion of
         | exclusionary expertise does not change that fact.
        
         | drhodes wrote:
         | Yep, check it out
         | 
         | https://en.wikipedia.org/wiki/Unikernel
         | 
         | https://mirage.io/
         | 
         | A 2014 podcast from IEEE,
         | 
         | https://www.se-radio.net/2014/05/episode-204-anil-madhavaped...
        
           | criddell wrote:
           | The first microcontrollers I ever messed with were MC6811
           | based boards like the HandyBoard. I never thought of it
           | before, but I think they were unikernel.
        
         | layoutIfNeeded wrote:
         | It's called a unikernel.
        
         | pjmlp wrote:
         | Basically that is how many computers used to work in the old
         | days, and also what is known as bare metal programming, where
         | the language runtime takes the role of a very thin OS.
        
       | johndoe0815 wrote:
       | Great project - love to see more alternative systems.
       | 
       | It should be noted that this is a port (or, rather a rewrite in
       | Pascal) of Peter de Wachter's RISC5 emulator to a bare-metal
       | Raspberry Pi environment, not a native Oberon system running on
       | bare-metal ARM (i.e. there is no ARM compiler backend and all
       | binaries are compiled for RISC5 and run in emulation).
        
         | 082349872349872 wrote:
         | IIRC the Oberon-powered drone was running on ARM, so there are
         | ARM codegens for at least some versions of Oberon.
         | 
         | Edit:
         | https://people.inf.ethz.ch/wirth/Oberon/Oberon.ARM.Compiler....
         | 
         | (not that this is meant to detract from TFA, just to point out
         | the possibility for someone to take another step.)
        
           | johndoe0815 wrote:
           | Thanks for the link!
           | 
           | Adapting the Project Oberon compiler code generation isn't
           | that difficult, but the devil is in the details :). My
           | student Rikke described some of the challenges porting
           | Project Oberon to RISC-V in her project report
           | (https://github.com/solbjorg/oberon-
           | riscv/blob/master/report....).
           | 
           | I assume that the most time-consuming task to get Project
           | Oberon to run on ARM/Raspberry Pi would be to write device
           | drivers for more complex devices, e.g. USB and Ethernet.
           | These could be written in Oberon (which would be a
           | considerable effort) or possibly be abstracted by using a
           | bare-metal hypervisor that supports VirtIO device
           | abstractions, e.g. Vmware ESXI. This way, one would only have
           | to implement VirtIO drivers in Oberon, which is considerably
           | less complex.
           | 
           | Connecting a PS/2 keyboard and mouse instead of USB might
           | also be an alternative, since drivers for PS/2 are far less
           | complex: http://www.deater.net/weave/vmwprod/hardware/pi-ps2/
        
         | ncmncm wrote:
         | Thank you, that is helpful background. Running Oberon code this
         | way is akin to running Python code on Micropython on bare
         | metal. But probably faster.
         | 
         | Even running in an emulator _on bare metal_ is more fun than
         | anything coddled in a massive OS. The threshold of fun is where
         | you get to schedule and vector your own interrupts.
         | 
         | At some point you will hunger for the actual native code
         | experience, but the difference turns out to be pretty abstract
         | unless you are counting clock cycles. The software that landed
         | the Apollo Lunar Excursion Module on the moon was mostly coded
         | to an emulator.
        
           | pjmlp wrote:
           | I recall reading somewhere that was the original idea of
           | P-Code, Wirth never planned to use it as basis for Pascal
           | emulators, rather as a tool for bootstraping compilers, but
           | then Pascal USCD took off.
        
       | unnouinceput wrote:
       | Quote: "It is not an operating system but provides many of the
       | same services as an OS, things like memory management,
       | networking, filesystems and threading plus much more."
       | 
       | Well, if it looks like a duck and walks like a duck, it is a
       | duck. Let's not beat the bush here, it is an operating system.
       | 
       | Also this misses a "2016" in title, since that was the last time
       | the GitHub repository was touched by developer.
        
       ___________________________________________________________________
       (page generated 2021-04-04 23:01 UTC)