Any way to support custom exception handler?

[MatthewRobertDunn]

Is it possible to implement a custom exception handler? I couldn't see any way of doing this..

One way of implementing this is by slightly modifying CExceptionHandler to allow inheritance:

class CExceptionHandler
{
public:
	CExceptionHandler (void);
	~CExceptionHandler (void);
	
	void Throw (unsigned nException);

	virtual void Throw (unsigned nException, TAbortFrame *pFrame);
	
	static CExceptionHandler *Get (void);

protected:
	static CExceptionHandler *s_pThis;

private:
	static const char *s_pExceptionName[];
};

You can then create your own class inheriting from CExceptionHandler and replacing s_pThis with your own

#include <circle/exceptionhandler.h>


#ifndef _mosexceptionhandler_h
#define _mosexceptionhandler_h

class MOSExceptionHandler : CExceptionHandler
{
    public:
	    MOSExceptionHandler (void);
	    ~MOSExceptionHandler (void);
        virtual void Throw (unsigned nException, TAbortFrame *pFrame);
};

#endif

static const char FromExcept[] = "MOSExcept";

MOSExceptionHandler::MOSExceptionHandler(void)
{
    s_pThis = this;  //Override new handler to this.
}

MOSExceptionHandler::~MOSExceptionHandler(void)
{
    s_pThis = 0;
}

void MOSExceptionHandler::Throw(unsigned nException, TAbortFrame *pFrame)
{
    CLogger::Get()->Write(FromExcept, LogNotice, "I'm a custom exception handler");
    CExceptionHandler::Throw(nException, pFrame);
}

[rsta2]

I made the CExceptionHandler::Throw() methods virtual on the develop branch, so that you can implement a custom exception handler. Setting s_pThis in the derived class is not necessary, because there is only one this pointer for a derived class object, which is the same like in the base class. Thanks for suggesting this feature!

[MatthewRobertDunn]

because there is only one this pointer for a derived class object, which is the same like in the base class.

Oh, of course. Silly me. Apologies for that. It's been a while since I've used C++

There's another suggestion I'd like to implement -- I'd like to return from an exception handler, but the code in exceptionstub64.S and exceptionstub.S currently does not allow that as it does not correctly preserve registers and it messes up the stack a little

I want to return from the exception handler so I can handle SWI/SVC exceptions to implement kernel function calls. (And maybe paging support)

[MatthewRobertDunn]

No problems. Thank you for your time.

I was thinking of executing this work by introducing a small feature at a time in a manner that is non-breaking to circle. Though you are right, I don't know if this can be achieved until the work is done. I also don't have every raspberry pi model, (though I have 1, 3 and 4) to test on.

That said, at least one of the initial features required for supporting OS development -- returning from an exception handler, appears to be a low impact change. The code is also extremely similar to existing circle code -- the same code you use to return from interrupts. So if interrupt returning is reliable in circle. I would imagine that exception returns will be as well.

My thought was returning with a new page-table configuration could be a low impact change as well. If you don't call the function that returns with a different page table. It's not used, so there is a 100% guarantee the stability of existing circle functions isn't impacted.

CExceptionHandler:ContinueWithNewPagetable(functionPointer, pagetable, level)...   //if you don't call this on the end of your handler, no harm, no foul,

If the end user uses this function to modify the page table in a breaking way -- I would consider that not circles problem.

[rsta2]

I think, it's not that simple. The return from the exception handler is not a big deal, as long you do not need a context switch, when returning from the handler, which is normally the case, when you want to work with multiple processes. A context switch is also necessary on returning from the system timer IRQ, if you want to implement preemptive multi-tasking, which you probably want. I have some code here for AArch32 to do this, but is rather complex and I wouldn't rely on it for Circle.

Switching between page tables requires multiple page tables to be created and maintained. Circle currently uses only one page table with a flat 1:1 mapping. Diving into the deeps of MMU programming is a thing of its own, and it would have been done for both AArch32 and AArch64 separately to be consistent.

Also the management of different privilege levels is an issue. Currently Circle uses only two levels in AArch64, one for normal processing and one for interrupts. Adding another PL for user processes may affect several things in Circle (e.g. execution levels, implementation of EnterCritical()). This has all been implemented years ago and would require to be checked in this process, which needs time and motivation.

What I could offer is, that I create a new feature branch (e.g. os-support) in the Circle repository and collect the code, which comes from you here. But I cannot make promises, if this code will ever make it into a Circle release. It depends on its quality and on the feeling, which I will have about, if it is a risk for the stability and understandability of Circle or not.

[MatthewRobertDunn]

I think, it's not that simple.

Yup. Nothing ever is.

A context switch is also necessary on returning from the system timer IRQ, if you want to implement preemptive multi-tasking, which you probably want. I have some code here for AArch32 to do this, but is rather complex and I wouldn't rely on it for Circle.

I don't really expect Circle to function after the context switch in any capacity. Just that circle provides you the facilities to perform it. It would be up to the end-user to put something sane in the process memory space.

Switching between page tables requires multiple page tables to be created and maintained. Circle currently uses only one page table with a flat 1:1 mapping.

Yup. Here all I would expect is Circle to provide you with data structures to describe the page tables in c++. Circle shouldn't need to be aware that you are using them. If the page table isn't flat as circle expects, Circle calls should fail. The theme would be that circle only provides you with facilities to manipulate the hardware. I would expect that Circle calls are only possible from 'kernel mode' when a flat page table is set and the privilege level is as Circle expects.

If Circle users were interested in dabbling with OS development, they would need to implement their own supervisor calls, and a library that wraps them. At most Circle might provide them with a naive method to raise a supervisor call, perhaps. I wouldn't expect any circle functionality to work outside of the Circle environment. I think if Circle provided much more than this then Circle would be dictating too much as to how the OS should be written

Diving into the deeps of MMU programming is a thing of its own, and it would have been done for both AArch32 and AArch64 separately to be consistent.

Yup. Makes sense.

Also the management of different privilege levels is an issue. Currently Circle uses only two levels in AArch64, one for normal processing and one for interrupts. Adding another PL for user processes may affect several things in Circle (e.g. execution levels, implementation of EnterCritical()). This has all been implemented years ago and would require to be checked in this process, which needs time and motivation.

Ah. I wasn't aware that Circle was using privilege levels in any capacity other than the default start up level. I'll have a look. Thanks.

What I could offer is, that I create a new feature branch (e.g. os-support) in the Circle repository and collect the code, which comes from you here. But I cannot make promises, if this code will ever make it into a Circle release. It depends on its quality and on the feeling, which I will have about, if it is a risk for the stability and understandability of Circle or not.

Thanks, you've been more than accommodating and I'm sorry for perhaps squandering your time.

My initial motivations for this was primarily fun and education. There's very little in the way of cheap well-documented hardware that everyone can get access to that is all virtually identical. The only other reasonable option for this sort of project is emulation of standardized, primarily older, hardware. I agree with you that Circle replicating a lot of what linux does, would of course be silly.

The end goal I vaguely had in mind is a separate code-repository that leverages circle to demonstrate OS concepts one at a time. Similar to your existing samples -- 01-gpio, 02-screepixel etc

For the OS project they would be something like 01-svc-handler, 02-multitasking, 03-paging..

There the 02 demo would be something very trivial like a timer swapping between two C functions that just perform calculations and raise an exception every N calculations.

It's possible you have higher expectations out of this than I had.

One thing I noticed is that gcc supports spitting out position independent binaries for arm which may allow a simple way to compile some toy user processes.

[rsta2]

I think, for a project like Circle you need some kind of scope, something you can focus on to make decisions, what to include and what not. Otherwise you will get a collection of functions, where it is difficult to see through. For Circle my focus is on supporting users to write bare metal applications in a number of areas of use (e.g. retro computing, sound synthesizers).

If this focus would be extended by a support for writing operating systems, or parts of it for educational purpose, I think, it must be done "right". I would need some plan, some model for this, which can be incorporated into the former scope. I find it difficult to think about the design of a software project without this. This is probably more than adding some functions for specific tasks.

Perhaps I need some distance to think about this again. There are a number of features, which I refused at the first sight, but realized later. Generally I think, it would be interesting to build a foundation for implementing OS stuff in Circle, but perhaps it's not the time to do is yet.

[MatthewRobertDunn]

Make sense, thank you again for your consideration.

[MatthewRobertDunn]

This is what I had to do to get exception returning working (for 64 bit)

b14ddf6

This allows me to implement a custom exception handler that can return from SWI and SVC calls. As the Panic log level already pauses execution, there doesn't seem to be any downside to allowing exception handlers to return normally.

In kernel.cpp:

	unsigned nTime = m_Timer.GetTime ();
	while (1)
	{
		while (nTime == m_Timer.GetTime ())
		{
			
		}

		nTime = m_Timer.GetTime ();
		m_Logger.Write (FromUser, LogNotice, "Time is %u I'm about to make a kernel call", nTime);
		asm ("svc 0");	//supervisor call #0
		m_Logger.Write (FromUser, LogNotice, "I'm back from the call");
	}

In my custom exception handler:

void MOSExceptionHandler::Throw(unsigned nException, TAbortFrame *pFrame)
{
    u64 ec = (pFrame->esr_el1 >> 26) & 0x3F;
    u64 iss = pFrame->esr_el1 & 0x1FFFFFF;

    if (ec == 0x15 && iss == 0) //Check if a SVC 0 occurred 
    {
        CLogger::Get()->Write(LogSource, LogNotice, "I'm a mock kernel function call!");
    }
    else
    {
        CExceptionHandler::Throw(nException, pFrame);
    }
}

[dlbogdan]

With deep respect for the work done here, wouldn’t it make more sense to port an existing RTOS (like FreeRTOS) to this platform using circle that already supports user processes than to write an entire new OS from scratch? Maybe I missed the point, for which I appologise, I’m just a simple developer who writes firmware for various MCUs most of the time for robots and stuff like that.

[ArnoldUK]

@dlbogdan
The circle SDK supports all the features of an RTOS and is quite well put together and simple to use, that's why I like using it.
A bare minimum circle kernel can boot a raspberry pi and start a process in less than a second. Also, because it is targetted at a specific device there is less chance of bugs and problems with code targetting multiple platforms and devices.

I guess this post is going to get moved by the moderator as per the topic title.
If circle supported the PICO then that would make it even more better for me. I thought I'd sneek that in here also.
@rsta2 feel free to delete or move my post.