V25 support

[anchorz]

Would it be possible to provide some help for a new CPU? The V25 needs a bit work on startup, interrupt handling and some timer thing.

I would assume to use a 80188 CPU, headless and ROMfs would do as a start, just prepare a ROM image with additional 128K RAM.

Is there a minimal .config for headless operation?

[ghaerr]

I'd be happy to help discuss what needs to happen for a new CPU, but you'll have to do most of the actual programming, ROM flashing and testing, as I don't have access to an SBC to directly help. I would suggest you start by looking at and building the "default" 8018X port using 8018x.config, just copy that to .config and make. It runs in ROM with 128k RAM, and uses a minimal headless configuration, with the serial port being the console.

I think @cocus, who contributed the 8018X port did some outside-of-ELKS initialization (like UART init, but I could be wrong) in ROM before passing control to the ELKS startup code; you might be able to do the same.

[cocus]

what's the V25? an embedded sibiling of the NEC V20?

So, for the 8018X (the embedded ones), I created a startup ROM code that enables the UART, GPIOs and such, then runs a function from the "elks ROM" and finally does an "int" to jump into elks. Have a look here https://github.com/cocus/8018x-elks-ldr.

[anchorz]

Thanks. It gives some insight on how to link and start elks. fun fact:
// Now call that INT19
int $0x19

int19h is the IO-Exception handler for V25. good, that it is not active after reset.

V25 is somewhat similar to V20 as a CPU. The peripherals are memory mappend, which can be mapped into a 256 bytes data structure within in the kernel data segment.

There are some interesting goodies. The V25 has an build in task switch. Instead of saving the registers, it does a bank switch on interrupt. Second, it provides an IO-Exception on IN/OUT command which can be used as a simple HW virtualization approach.

Con: But suprisingly the only CPU, I know of, that does not come with TX empty flag.

[anchorz]

Are you suggesting to use the option ROM approach arch/i86/boot/Image over linking the "system" to another address? That would mean the 64K memory segment F000 is unused or would it be more preferable to link system to another address other than E000 ? Is the segment start address E000 somewhat important to keep?

[cocus]

I have my loader set up so it calls ELKS at E000, but it also contains the ROMFS a little bit afterwards, so starting at E000 until the very start of the loader, you can fill it up with ELKS + ROMFS. in my scenario, the ROMFS is almost full, so these won't get wasted. if you don't want to use the ROMFS, then I suspect the ELKS option rom should be moved to a position towards the end of the memory region.
I don't know how to change that E000 base, @ghaerr might get some insights here.

As an FYI, here's the "mappings" inside my flash image (that is mapped at 80000, i.e. 512kB):

ROM_ELKS_IMAGE_AT = 917504 # 0xe0000 (can use until 0x7ffff)
ROM_ELKS_ROMFS_AT = 524288 # 0x80000 (can use until 0xfefff)
ROM_LOADER_AT = 1044480 # 0xff000