This is not an issue but an idea for the firmware.

[mist-devel]

This is not an issue but an idea for the firmware.

[sorgelig]

You don't need any extra hardware to re-flash broken firmware. ARM MCU has OTP emergency bootloader. Just need to short JP1 for 10 seconds and then you can re-flash through onboard USB connector. Check the Wiki.

IO Controller has very limited RAM. Only 64kb. And it's used by main firmware. Also, there is no MMU and OS there. It means, binaries should be compiled into absolute address. Thus, you cannot have plugin systems where base firmware can choose which plugin to use since they can overlap each other.

But it still possible to implement some kind of USB access through FPGA and use some virtual CPU (like ZPU) to make driver for specific device, although the range of supported devices will be limited due to SPI speed and pipe access.

IO Controller is very simple and slow. You cannot think about it as about Raspberry Pi :)

[sorgelig]

As far as i know, there is USB ethernet support in Amiga core. So, i think, it should be possible to add ethernet for other cores as well. May be some small tweaks required for IO firmware for non-Amiga cores (since Amiga has special support in IO firmware) but that is doable if really required.

[rrmagro]

I already read that, but i forgot about the JP1 jumper.
I know that the MCU has 64Kb of RAM and the firmware to run uses it, but it should be some way to implement some kind of BIOS to read the modules from the SD Card and execute them even if the MCU is slow its faster than any simulated core. You probably are correct about some modules overlad each other, but that would be very simple to solve, just use a configuration file to specify wich ones should be loaded.
I probably making it sound simple but probably is not.

[rrmagro]

About the ethernet i know that the amiga has support as far as the firmware and the core, but i think its limited.
For the Atari ST there are some threads currently in the forum that talk abou it.
But my idea about that is that it should me made generic in the firmware and (again) a module implements a specific ehternet card with an external file being loaded from the sd card.

But the idea of in general was to split the firmware in to main parts. the part that should stay in the MCU flash and would be generic and the "Dynamic" part that could be in the SD Card.

The are several "BIOS/OS" implemented in smaller sizes than 64Kb.

[harbaum]

The firmware has support for ethernet. But it's currently only available to the Atari ST core. I plan to make it available to all cores and then write a simple tutorial for this. But this will probably not happen in the next few weeks. I already promised sorgelig to write another tutorial ...

[rrmagro]

Great more tutorials are always a good thing, it helps other developers.

I am talking about the possibilities of a generic firmware being in the MCU flash and modules being loaded from the SD Card, not just for the support for the Ethernet but for other things, i.e. support for different joysticks, debugging modules such as loggers ( I know serial port has that, but does it need to be always loaded or in the flash?), sound/midi driver ( the firmware should only share a port then the driver related to the core should be external to the firmware, this would be nice since it could be costumized meaning for example redirecting the sound to a USB Sound card or other device ), these are just a few things, but if you think about it there are many more.

This would allow a simple/generic firmware and a specific module to each core, not making the firmware complex and with several parts that are specific to a core. A cleaner firmware, that any one could read and know what to implement outside of it.

Instad of making several changes to the firmware for each core, one could make them on the SD card, leaving the firmware intact.

[harbaum]

That's a great idea. I'll put it on the to-be-considered list. And once the main cores are finished we can start having a closer look at this. There are a lot of things that need to be done to make this work incl. e.g. finding a way to compile and dynamically link such a plugib against the running firmware. So this will not just be done in three days.

Of course you are welcome to start working on this as well. The bettet elaborated the concept is the easier will implementation itself be.

[rrmagro]

I have already started to investigate this some time ago and all the possibilities indicated that it's possible, that's why i open this "issue".

But until now i didn't advance more because i needed to know if you would consider it.

I'l try to make a text explaining better.

Thank you.

[harbaum]

We don't need more explanation. I think we already understood what you want. But there are many software things to solve. Before implementing something like that some testing needs to be done to understand how to load code, what kind of hooks to use from within the firmware. How to export symbols from the firmware to the plugin.

So what's needed now is someone actually figuring out how to do this. Try to compile a plugin etc etc ...

Yes, systems being able to load programs from mass storage have been written in 64k. But these e.g. didn't already include a full USB stack or a FAT32 capable file system layer.

[harbaum]

I have included this in the todo list.

[rkrajnc]

UBoot and similiar systems are usually used on architectures that have limited ROM space and plenty of RAM, so only the UBoot is loaded in ROM and all other software is loaded into RAM.

Microcontrollers are just the opposite - they have very little RAM and plenty of ROM space, so you usually don't have to deal with firmware 'plugins', and you save the resource you have the least - RAM.

There are other ways in which space in both ROM and RAM can be saved.
For ROM, Thumb instruction set can be used, especially for code that is only run once or is not timing-critical, so all initialization functions etc. can be compiled in Thumb mode.
For RAM, memory overlays can be used - if all config variables for a core were kept in a single struct, for example, all these (global) structs could be assigned the same start location in memory, and initialized when the specific core is loaded. This is supported in the GNU linker.

Overlays can be used for code also, but it is a little bit trickier. One can instruct the linker to build parts of the firmware at the same address located in RAM, and export these parts of the resulting binary in separate files (the linker knows how to do that) that could be loaded from SD card. This way you get support for firmware plugins, but they are always build together with the base firmware.

There is a way to build each plugin separately, but this is definitely the hardest way. In this case, all global symbols must be exported from the base firmware and defined in each plugin. Which also means that any change in the base firmware will require a rebuild of all plugins. The base firmware will also need a way to access some kind of init function (probably through a pointer attached to the plugin binary), which will populate a table with function pointers, so the base firmware will know where to call the plugin functions. Supporting the ability to load multiple plugins at the same time is even harder. Also, while ARM normally supports position-independent code, so all jumps etc. are PC-relative, it is more problematic how data is accessed - with an index offset in a register, so this could still prove to be problematic.

I have implemented such a system before (for a product that supported 'patching' ROM system functions with functions loaded in RAM), and I can honestly say it was pretty challenging. But that was actually easier than what is proposed here, as you only patched existing functions, so the base firmware already knew what kind of function it is calling, as you basically replaced a pointer to a function in ROM with a pointer to a similar function with same signature (same parameters, same return) in RAM. Calling functions that the base firmware knows nothing about is much harder - you can basically only call void f (void) functions, since you can't know what params each function will need. Sure, it can be done, by using some inline assembler, but again, lots of work.

If the idea is to save space, there are other much simpler options to try first, which I mentioned above. On the other hand, if the idea is to build a real plugin system, there's a lot of work to do, and a lot of things to consider. Sounds like an interesting project! ;)

[harbaum]

That's all true. We are currently not in a situation where ARM controller RAM or flash is getting low and we still have lots, often even trivial options left.

Once flash space gets too limited we can significantly reduce the internal debug output. Significant RAM can be saved by just sharing all the file structures used for floppy and hdd emulation between all the cores. The same is true for those various sector buffers.

But the plugin ideas sounds fun. If someone implements that i'd definitely enjoy it. But there so much that we'll likely want to do before that. Like writing a SNES core or writing a cycle exact 68k core ...

[sorgelig]

N64 would be better than SNES ;)

[Newsdee]

Could the MiST hardware handle a Neogeo? Although game-wise the
SNES/Genesis have a much bigger and diverse library.
On Jan 19, 2016 7:43 PM, "sorgelig" [email protected] wrote:

N64 would be better than SNES ;)

—
Reply to this email directly or view it on GitHub
#16 (comment)
.

[MmmPT]

or sharp 68000...

On Tue, Jan 19, 2016 at 11:43 AM, sorgelig [email protected] wrote:

N64 would be better than SNES ;)

—
Reply to this email directly or view it on GitHub
#16 (comment)
.

[rrmagro]

I have been investigating several options, so that the work to be done would be as little as possible. So I have found one that could be a best choice Nuttx RTOS, there's no need for a MMU and has been ported to several MCU and CPU's including the Z80 and several arm MCU's.
Please consider this, I think it would be a plus for the MIST. But I'm too new to the hardware scene.

[harbaum]

Looks interesting. I'll have a look at it. Thanks.