Native ARM - Moving towards better structured kernel workspace

[jgharston]

I'm not sure if this should be written up as an issue in the absense of anywhere looking like a "discussion" area. Feel free to close this and move the discussion to a more appropriate place.

A lot of the ARM kernel code has hardwired bits in at the moment. Some things will need to move to being vectors/buffers/etc. For instance, for GetEnv/SetEnv/WriteEnv and friends to work the environment string needs to be a copy of the string used, not a pointer to the string used. Several issues, including: the passed string will in user space and may be stomped on by another program loading over it, it has to be considered read-only (eg is could be a line in the middle of a BASIC program) and parts of Execute need to modify the string, etc.

Today I've been digging through notes from the Matchbox development and digging through our real-world reference hardware: the Acorn ARM Eval System, the Sprow CoPro and RISC OS itself.

At a general level, an ARM system is laid out like this (ignoring relocation for the moment): ...ARM memory layout 0000 +------------+ .....|..Hardware..| Should 0100 +------------+ be .....|...Kernel...| read-only 1000 +------------+ in .....|.Operating..| USER .....|..System....| mode 8000 +------------+ .....|...User.....| .....|............| .....\//\//\//\//\//\//\// (sorry, I still can't get these code blocks to work properly)

'AB' (ARM BASIC 1.00) is an example of a program that runs in a kernel-only environment loading to &1000, like running Bas32 on PanOS without booting Pandora, or BasicZ80 on Z80Tube without booting CP/M. RISC OS-y type code such as the ARM BASIC module (BASIC 1.05 and later) run in high memory with 8000 as the bottom of user memory.

I'm still digging through code and documentation to more fully draft up kernel workspace layout recommendations, but based on the reference hardware I recommend starting by moving towards this: Initial layout: &0000-FF Hardware entries and vectors &0300-FF Debugger workspace &0E00-FF Environment buffer and Error buffer &0F00-EF Supervisor input buffer &0FFB-FF Environment time (move this later on)

This gives us a start to getting GetEnv and friends working, SetEnv and OSCLI copy the command line (stripped of leading stars/spaces/'RUN') to &0E00 and the start time to &0FFB-&0FFF, Execute is able to modify it to swap in a module name, GetEnv returns R0=&E00, R1=ramtop, R2=&FFB.

I'm also looking through my module handling code to work out where things need to go to a module handler to hook in.

[BigEd]

(I've tweaked the title of this issue. Does this proposal/request for comment apply to both the ARM2 and native ARM coprocessors?)

[fordp2002]

I am guessing not as we use the genuine ARM ROM on the the ARM 2. Maybe we should call the native ARM "32 Bit ARM"? The code runs on several generations of ARM Architecture and the common factor is they are all running as 32 Bit.

[BigEd]

But ARM2 is also 32 bit. In this project we seem to be fairly consistent using "ARM2" and "Native ARM". It's true that Native ARM is running in 32 bit mode even on the Pi 3. I suggest that if we ever make an ARM core running in 64 bit mode, we call it ARM8 or ARM64 - or at any rate, something different.

[hoglet67]

Jonathan, I'm very happy for us to move in this general direction for a future release (i.e. beyond Boa) and it would be great to have you work on this. But please please get a build/test environment up and running before starting to change lots of code. As we refactor/improve things, it's really important that we keep things running, and try to keep changes incremental, and use individual commits. I would suggest something of this nature be done on it's own branch.

[hoglet67]

I am guessing not as we use the genuine ARM ROM on the the ARM 2

Actually we are. Why did you think this would not be possible?

The ARM2 (from MAME) is pretty much a super-set of the original ARM. I think there's just one instruction that's not backwards compatible, and this is very rarely used.

[fordp2002]

ARM2 is 26 Bit from an address bus point of view.

[BigEd]

Oh, 26 bit addressing - I see now where you're coming from.

[jgharston]

Oh, definitely, I'm not planning to change any code at the moment, just drafting a road map. At the moment I've got my tube-swi.c to compile, but not link with anything else. And until I carefully saw off the composite video connector from my Pi I can't plug it into my Master to confirm I've correctly copied the current build to it. At the moment consider me as drafting pseudocode describing intended functionality.

Am I correct in understanding that "ARM2" is emulating the Acorn ARM Evaluation System (and uses the ARMEval's Brazil ROM), and that "ARM Native" is running on the bare metal, and most of the "client" is implemented in C.

[jgharston]

Answering BigEd's question in post#2, the suggested target roadmap is very close to what the ARM2/ARMEval actually uses (and is a tidied up version of what is buried very far down underneath RISC OS).

[BigEd]

Am I correct in understanding that "ARM2" is emulating the Acorn ARM Evaluation System (and uses the ARMEval's Brazil ROM), and that "ARM Native" is running on the bare metal, and most of the "client" is implemented in C.

Yes, that's right. I see Dave has given this issue's title a "Native ARM" prefix - so, it seems we're heading towards making the Native ARM core work rather like the ARM2/ARM Eval, with the differences that come from the Pi's CPU:

• 32 bit addressing, not like a '26 bit' machine
• maybe some alignment constraints? but with these features
• very high performance
• loads of RAM

[fordp2002]

There would be less alignment constraints ARM7TDMI and before could not handle split loads. I got some interest in writing a version of BBC Basic with VFP support over in the RISC OS forum. The fastest Copro in the world could be a lot faster yet ;)