+1 for preferring a single-core concurrency model. This would be much more likely to be reusable for other platforms, and much simpler to maintain in the long run (way less platform-specific details to keep track of and figure out again and again for every new chipset). You CAR problems would become much more simple... just make sure the scheduler structures get migrated together with the rest of the globals and it should work fine out of the box.
On Mon, Feb 13, 2017 at 12:31 PM, ron minnich rminnich@gmail.com wrote:
On Mon, Feb 13, 2017 at 11:17 AM Nico Huber nico.h@gmx.de wrote:
Another idea just popped up: Performing "background" tasks in udelay() / mdelay() implementations ;)
that is adurbin's threading model. I really like it.
A lot of times, concurrency will get you just as far as ||ism without the nastiness.
But if we're going to make a full up kernel for rom, my suggestion is we could start with a real kernel, perhaps linux. We could then rename coreboot to, say, LinuxBIOS.
ron
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot