[coreboot] Add coreboot storage driver

Vadim Bendebury vbendeb at chromium.org
Tue Feb 14 00:38:01 CET 2017


Incidentally, a few years ago Chirantan and Simon (cced) implemented u-boot
concurrency support for an ARM SOC. I don't remember how much gain it was
bringing, and it did not go into production as it was quite late in the
project cycle.

But they might have some experience to share.

-v


On Tue, Feb 14, 2017 at 7:28 AM, Julius Werner <jwerner at chromium.org> wrote:

> +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 at gmail.com> wrote:
>
>>
>>
>> On Mon, Feb 13, 2017 at 11:17 AM Nico Huber <nico.h at 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 at coreboot.org
>> https://www.coreboot.org/mailman/listinfo/coreboot
>>
>
>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20170214/9b78bb5f/attachment.html>


More information about the coreboot mailing list