GSoC proposal: Better support for RISC-V systems

[Jonathan Neuschäfer]

Hi everyone,

Below is a link to my GSoC project proposal draft[1]. In essence it's
about porting coreboot to a non-emulated board with a RISC-V CPU. If you
have any comments, please go ahead and add them to the document.

The exact RISC-V board is not yet decided, but I'll fix that as soon as
I can.

Also, I'm not sure about the timeline. It currently weighs heavily on
the first half. Maybe I'm not giving the individual subtasks enough
time; maybe I have not listed enough subtasks to fill the three months
time frame.

Jonathan

[1]: https://docs.google.com/document/d/1Ex1rP7Y9kX4y5TQCx28uZyqx8iSgih_JyVGnM3fl...

[Paul Menzel]

Dear Jonathan,

Am Freitag, den 25.03.2016, 04:38 +0100 schrieb Jonathan Neuschäfer:
> Below is a link to my GSoC project proposal draft[1]. In essence it's
> about porting coreboot to a non-emulated board with a RISC-V CPU. If you
> have any comments, please go ahead and add them to the document.

thank you very much for your promising proposal!
> The exact RISC-V board is not yet decided, but I'll fix that as soon as
> I can.

What alternatives are there?
> Also, I'm not sure about the timeline. It currently weighs heavily on
> the first half. Maybe I'm not giving the individual subtasks enough
> time; maybe I have not listed enough subtasks to fill the three months
> time frame.

Looking at it, I’d say, two weeks for implementing RAM initialization
is a bit short. But I have no idea, if it compares to current x86
initialization or is more like in the old days.

What tasks would there be, when – as you noted in your proposal – the
development does not arrive in time or there are other problems?

If I am not mistaken, you mentioned, you have some Intel GM45 Dell
laptop with DDR2 memory. Could (start) implementing support for that be
a backup task?

Thanks,

Paul
>

[Jonathan Neuschäfer]

On Fri, Mar 25, 2016 at 12:23:19PM +0100, Paul Menzel wrote:
> Dear Jonathan,
>
> Am Freitag, den 25.03.2016, 04:38 +0100 schrieb Jonathan Neuschäfer:
> > Below is a link to my GSoC project proposal draft[1]. In essence it's
> > about porting coreboot to a non-emulated board with a RISC-V CPU. If you
> > have any comments, please go ahead and add them to the document.
>
> thank you very much for your promising proposal!

Thanks for taking a look :-)
> > The exact RISC-V board is not yet decided, but I'll fix that as soon as
> > I can.
>
> What alternatives are there?

I've discussed this some more with Ron, and it will be an untethered
lowRISC[1] ("untethered" meaning that it doesn't use the Host-Target
Interface which is a bridge and abstraction layer for I/O) on a Nexys 4
board by Diligence[2], which has 128MB of RAM.
> > Also, I'm not sure about the timeline. It currently weighs heavily on
> > the first half. Maybe I'm not giving the individual subtasks enough
> > time; maybe I have not listed enough subtasks to fill the three months
> > time frame.
>
> Looking at it, I’d say, two weeks for implementing RAM initialization
> is a bit short. But I have no idea, if it compares to current x86
> initialization or is more like in the old days.
>
> What tasks would there be, when – as you noted in your proposal – the
> development does not arrive in time or there are other problems?

I have no good answer to that. I have now changed the first two weeks to
be about getting coreboot (+Linux) to run in a Emulator, but that
certainly can't fill the whole three months.
> If I am not mistaken, you mentioned, you have some Intel GM45 Dell
> laptop with DDR2 memory. Could (start) implementing support for that be
> a backup task?

Yes, I have that laptop, and I will probably try to port it in the
future, but I'm not sure how well it fits in the context of GSoC, given
that I haven't written a proposal and timeline.

Jonathan

[1]: http://www.lowrisc.org/docs/untether-v0.2/
[2]: http://store.digilentinc.com/nexys-4-ddr-artix-7-fpga-trainer-board-recommen...

[ron minnich]

On Fri, Mar 25, 2016 at 9:34 AM Jonathan Neuschäfer 
wrote:
> I've discussed this some more with Ron, and it will be an untethered
> lowRISC[1] ("untethered" meaning that it doesn't use the Host-Target
> Interface which is a bridge and abstraction layer for I/O) on a Nexys 4
> board by Diligence[2], which has 128MB of RAM.

yep, this is fine.
> > > Also, I'm not sure about the timeline. It currently weighs heavily on
> > > the first half. Maybe I'm not giving the individual subtasks enough
> > > time; maybe I have not listed enough subtasks to fill the three months
> > > time frame.

I can *guarantee*, based on the last two ports, that there will be all
kinds of problems that nobody
could anticipate.You will have no trouble filling 3 month. Any timeline and
description of work to be done will of necessity be imprecise.

When Thaminda did the work last summer, every single thing we thought was
working in the toolchain/simulator
was completely broken 2 weeks before he started. This was challenging.
Everything that had worked, stopped working.

As for DRAM, I am pretty sure it's going to be a matter of setting the
right values in the right registers, as on many ARM boards
and chromebooks. I don't think we'll be doing training from scratch.
> > What tasks would there be, when – as you noted in your proposal – the
> > development does not arrive in time or there are other problems?

There will be problems and we'll have to improvise. There's no shortage of
tasks and we'll have to work it out.
> I have no good answer to that. I have now changed the first two weeks to
> be about getting coreboot (+Linux) to run in a Emulator, but that
> certainly can't fill the whole three months.

That's not certain. Let's not overplan this. There's no way to know what's
going to go wrong.
> > If I am not mistaken, you mentioned, you have some Intel GM45 Dell
> > laptop with DDR2 memory. Could (start) implementing support for that be
> > a backup task?

I, personally, think this is a distraction and not a good idea. Let's not
do this.

thanks

ron