Orange Pi

When I saw that it was a bit of a surprise. I thought I did leave it out.

There’s lots of things in there I thought would be a showstopper, but apparently not. I’m still working on the very basics and learning as I go. On the bright side, the iMx6 (?) Interrupt code looks like it may be persuaded to work on the AWH3 code.

A little less noteworthy, I sort of got svnserve working on my home server and managed to get a copy of my source tree uploaded to it using the RO version of SVN.
The lack of versioning has been a concern. In the last couple of days the code broke and I didn’t have anything to revert to. I mean I found the issue, but it was still a pain.

The code had all the OMAP uImage header stuff removed, and the very few boardConfig things left that seemed useful to me have been migrated to the static workspace, with code altered to suit. The reason being mentioned previously. Supporting a few different SoCs and quite a few boards should be mostly possible at runtime I think.

Try making sure SharedRISC_OSLib (i.e. the shared C library) is located before RTSupport in the components file. That’s the only reason I can think of for why RTSupport would crash like that.

SharedRISC_OSLib was commented out. Oops!

I grabbed the source for the iMx6 after looking at some files in the repository. There are some similarities in the functionality that I couldn’t ignore. Besides the interrupts, some other things seem to be a fairly close match.
I’ll get back to it later. Right now the Pi3 is hard at work doing an SVN checkout of the imported source tree. Just trying to get some versioning happening still.

Confirmed RTSupport just locks up.

Been working on getting the GIC up and running for days now. Even though I’ve narrowed it down to a few lines of assembly, I just can’t see what the issue is. I’ve even ported the iMx6 and OMAP4 Interrupts.s across to try and work it out.

In the process I found a slight weakness in the OMAP4 GIC code where portability is concerned. Depending on the specifics of the implementation, MPU_INTC_CPU can cause the build to fail because the offset can be out of range.
In the case of the H3, and probably other SoCs, the Interrupt Distributor is offset &1000 from the SCU, and the CPU Interface by &2000. Ie too far for a relative offset.

I tried the OMAP4 Interrupt code because I stumbled across the FreeBSD code which supports the GIC400, which was apparently based on their OMAP4 code. I figured it was worth trying a modified version of the RO OMAP4 GIC code at least.

e: I worked out the problem. The maximum interrupt on the system isn’t a clean multiple of 16 so the CMP keeps it looping forever. Perhaps I should go for the maximum supported interrupts by the GIC rather than actual usable interrupts?

RTSupport: I remembered that the module startup contains some code which waits for an interrupt (so that it can check behaviour & capture some state). So for the module to work you’ll need a working GIC driver, plus the HAL timer/counter API (both for an interrupt source it can use on startup, and because the module relies on the system timer for scheduling).

Perhaps I should go for the maximum supported interrupts by the GIC rather than actual usable interrupts?

Yes, using the number of interrupts supported by the GIC (or even just rounding the usable interrupts up to the next multiple) should be fine.

That fixed it. It gets through Interrupt_Init now.

Sadly it’s just not getting as far through boot as it used to. With Debug, DebugInterrupts and ExtraDebugInterrupts turned on it gets as far as “Machine ID duff,zero substituted”. With those debugs turned off it stops at “ExecuteInit”.

I should really start a proper thread for the H3.
Although it’s unstable, crashy and generally broken it gets to the CLI again with more regularity. There’s definitely something that’s not being initialised or something early in boot.
Currently I have no way of knowing if the interrupt handler is working as intended, but it seems to be okay for now.

Over the last couple of days I added and implemented most of the timer handler. It’s also the first object I wrote in C for this. Besides a silly logical error which I made with reading pointers from the static workspace initially, it seems to be behaving.
My current goal is to get basic interrupt and timer functionality implemented because it is so integral to the base functionality of RISC OS, or any OS really.

The only reason I did the timers in C was because I was having trouble thinking my way through it in assembly. For some reason they have some timer specific registers and some common ones which need masking to get information for a specific timer. Also it was way easier for me for now to calculate the timer granularity using a couple of switch statements.
I’d forgotten that DDE C is a little finicky about typecasting, but I got there.

I started my thread