Am 28.08.2015 16:12, schrieb ron minnich:
I would say bring it in to the repo. We have assembly, we have our own C compiler even, so a higher level language hardly seems a bad idea. If this can make our code base better in some way, why not use it?
I'm not concerned about the language. More about the content `device driver`, which could be used anywhere (actually, I first planed to use it in FILO, why is coreboot doing gfx init anyway?). Also, I was bothered some- times when code got copied from coreboot to libpayload or the other way around. I don't know if the real problem was that libpayload resides in it's own repository. But having simple device drivers in it's own place seems to be a good idea, for me.
Anyway, I'll push it next week (I guess) when the code got cleared.
Nico
ron
On Fri, Aug 28, 2015 at 4:55 AM Nico Huber nico.huber@secunet.com wrote:
Am 21.08.2015 22:47, schrieb ron minnich:
This sounds wonderful. I'm all for it.
Did you just kill any discussion with that line? :)
Things live currently in a small library that I called `libsparkhw` (came spontaneously, I don't care much about the name). It contains some framework (Timer, I/O, Debugging) to do hardware stuff in SPARK, plus the mentioned graphics initialization. I falter to push it directly for inclusion into the coreboot repo. Maybe we want a separate reposi- tory for it (like libpayload has)? It would also make it easier to use it in other components (e.g. bootloaders and such, and of course our own products where the code stems from).
We have discussed the licensing and will push this under GPLv2 + later if there are no reasonable concerns.
Nico
2015-08-28 17:35 GMT+02:00 Nico Huber nico.huber@secunet.com:
I don't know if the real problem was that libpayload resides in it's own repository.
libpayload still shares a repo with coreboot. There were ideas to separate them, but that never materialized.
But having simple device drivers in it's own place seems to be a good idea, for me.
If you want, I can setup a repo at coreboot.org, mirrored to github.com/coreboot, and we hook it up as submodule. That would place it somewhere below 3rdparty/ for consistency with the other submodules. Your code, your decision.
Patrick
-
Nico Huber -
Patrick Georgi