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