Re: [coreboot] Add coreboot storage driver

[Aaron Durbin]

On Mon, Feb 13, 2017 at 9:32 PM, ron minnich  wrote:
> andrey, great questions. If you're really concerned about those issues, then
> yes, maybe a space sharing solution is the right one.
>
> I really would rather not see people implementing schedulers at this point.
> If we're going to go that route, let's get a reasonable
> operating system and use it instead. If we continue on coreboot's current
> trajectory we're going to end up like every other
> firmware project that became an OS, and that to me is the wrong direction.

It's quite the predicament if we don't want to give up on boot speed.
Being heavily invested in coreboot is where we currently are -- for
better or worse (I think for the better). For an optimized bootflow
all pieces of work that need to be done pretty much need to be closely
coupled. One needs to globally optimize the full sequence. Carving
that work into granular pieces across different code bases just leaves
the perf on the floor that we seem to be absolutely needing to
maintain boot speeds. Is Chrome OS going against tide of coreboot
wanting to solve those sorts of issues?
> ron
>
> On Mon, Feb 13, 2017 at 6:43 PM Andrey Petrov 
> wrote:
> > Hi,
> >
> > On 02/13/2017 12:31 PM, ron minnich 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 how do you guarantee code will get a slice of execution time when it
> > needs it? For example for eMMC link training you need to issue certain
> > commands with certain time interval. Lets say every 10ms. How do you
> > make sure that happens? You can keep track of time and see when next
> > piece of work needs to be scheduled, but how do you guarantee you enter
> > this udelay code often enough?
> >
> > Andrey