Preemption on ARM Thumb-2

[David Boddie]

I've been messing around with the Thumb toolchain to do bare metal
programming on a Cortex-M4 MCU. Since that worked fairly well, I tried to
build more of the Inferno kernel, but have run into problems.

The thing I'm unsure about is how to implement the interrupt handling to get
time-slicing to work. On the Raspberry Pi and other ARM ports, the handlers
appear to change into SVC mode with interrupts disabled before calling trap()
to do all sorts of process switching. On Cortex-M4, there's only handler mode
and thread mode, and you can't switch between them.

In some ways, it would be easier to be able to separate the preemptive
process switching from all the calls to sched() but that looks like it might
be quite difficult.

Has anyone attempted anything like this before?

David

[da...@boddie.org.uk]

On Tuesday 22 February 2022, I wrote:

> In some ways, it would be easier to be able to separate the preemptive
> process switching from all the calls to sched() but that looks like it
> might be quite difficult.

I think I have a better handle on this than before, though I'm not getting

much further than starting an /osinit.dis file that can spawn a function

to do work alongside the main function.

Beyond that, I'm having trouble doing much with files. I can stat
directories and get file handles for them, but reading their

contents is failing inside the kernel. I believe I should be able to

read them without problems.

The error I get when I use print("%r") to print it is "i/o count too small".
Maybe I don't have enough memory to use for allocation, or perhaps I forgot

to configure something.

Any ideas?

David

[da...@boddie.org.uk]

Following up, it seems that I was supplying an array that was too small to sys->readn.

I can at least supply a file in the root file system and read it back at boot time.

[da...@boddie.org.uk]

On Friday 2 December 2022, I wrote:

Following up, it seems that I was supplying an array that was too small to sys->readn.

I can at least supply a file in the root file system and read it back at boot time.

I fixed some glaring errors in the way I handle the timer interrupt - though
wouldn't claim it's a good way to handle it even now - and things seem a bit
more stable than before. Having said that, newly flashing the OS and booting to
a tiny shell resulted in a fault when running ps for the first time, so clearly
more work is needed.

I pushed my work to my Bitbucket and GitLab forks, but it seems that a lot of
action is on GitHub these days so I rebased my branch onto a fresh clone of the
Inferno mirror there:

https://github.com/dboddie/inferno-os/tree/stm32f405

Something will have to be done to reduce the RAM footprint before useful
programs can be run - beyond some simple tools, anyway.

David

[da...@boddie.org.uk]

On Monday 23 January 2023, I wrote:

I pushed my work to my Bitbucket and GitLab forks, but it seems that a lot of

action is on GitHub these days so I rebased my branch onto a fresh clone of the
Inferno mirror there:

https://github.com/dboddie/inferno-os/tree/stm32f405

Something will have to be done to reduce the RAM footprint before useful
programs can be run - beyond some simple tools, anyway.

 

I found a way to reduce the RAM footprint a bit, so there was a bit more
progress. I also created a separate repository to automate builds so that I
could catch problems and share successful builds:
https://github.com/dboddie/inferno-test-builds/actions

I'm currently playing with bits of hardware:
https://dboddie.gitlab.io/inferno-diary/2023-03-04.html

At some point I should revisit undefined instruction handling and implement
support for double precision floating point instructions. That would get more
code to run without faulting.

David

[da...@boddie.org.uk]

Continuing on this theme, I got the basic Inferno port running on two other boards:

SAMD51: https://dboddie.gitlab.io/inferno-diary/2023-06-28.html

Apollo3: https://dboddie.gitlab.io/inferno-diary/2023-08-22.html

The first one of these no longer works. The second is the one I'm currently exploring.

David

[Giovanni Lostumbo]

The SparkFun Artemis forum might have some info, but I don't know if there are many on baremetal: https://forum.sparkfun.com/viewforum.php?f=167&sid=35868d767997cdcafb9f9ce95962d346

Also,  you could try the Apollo SDK issue section:  https://github.com/sparkfun/Arduino_Apollo3/issues (somewhat active but Arduino IDE)

and other Artemis repositories: https://github.com/orgs/sparkfun/repositories?q=artemis&type=all&language=&sort=

[da...@boddie.org.uk]

Thanks for the links! I've been digging around in SparkFun's own support for the Arduino environment to find out how various peripherals are set up:

https://github.com/sparkfun/Arduino_Apollo3

There's certainly not as many sources of bare metal code as, for example, the STM32 series of microcontrollers.