On 29.08.2015 14:09, Peter Stuge wrote:
ron minnich wrote:
and I still think it belongs in the tree.
No way.
This is a library of device drivers. It has no place whatsoever as a
subdirectory lost somewhere in the already too big coreboot repository.
libsparkhw needs to live in its own
On 29.08.2015 21:58, ron minnich wrote:
If people feel strongly enough about this then we can do an external repo
for now.
Either way around, we would have to learn how to best integrate SPARK
code in coreboot. There would still be some steps to go from linking
with an adalib, to SPARK beeing a
Ron,
ron minnich wrote:
I think this could prove to be a very important new direction for coreboot,
I agree.
and I still think it belongs in the tree.
No way.
This is a library of device drivers. It has no place whatsoever as a
subdirectory lost somewhere in the already too big coreboot
If people feel strongly enough about this then we can do an external repo
for now.
Nico, do you want to set up a github repo and we can work out procedures
people use to try this out? As you know I'm more interested in Muen as a
replacement for the ramstage but this is a good first step.
ron
--
ron minnich wrote:
If people feel strongly enough about this then we can do an
external repo for now.
Nico, do you want to set up a github repo
There are more options than the coreboot repository and github.
If Nico is willing to push the code to coreboot.org then I think a
separate
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,
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,
On Fri, Aug 28, 2015 at 9:12 AM, ron minnich rminn...@gmail.com wrote:
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?
Does this mean
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?
ron
On Fri, Aug 28, 2015 at 4:55 AM Nico Huber nico.hu...@secunet.com wrote:
Am
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
2015-08-28 16:13 GMT+02:00 Aaron Durbin adur...@google.com:
Does this mean we can start writing our userland tools in golang?
If you can provide portability guarantees for userland compilers like
we do for target compilers...
(which is one of my main worries right now: gnat requires an ada
2015-08-28 17:35 GMT+02:00 Nico Huber nico.hu...@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
Am 28.08.2015 17:51, schrieb Patrick Georgi:
2015-08-28 17:35 GMT+02:00 Nico Huber nico.hu...@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
I would really like this to be in the tree. It gives us a chance to do
things in coreboot that go beyond C and assembly. So that's my $.02.
What harm would it do?
ron
On Fri, Aug 28, 2015 at 9:00 AM Nico Huber nico.hu...@secunet.com wrote:
Am 28.08.2015 17:51, schrieb Patrick Georgi:
we can work those problems. We've worked lots harder ones. . Heck, we
build, what, 5 different cross compilers now, including the riscv one
that's not even official? And our *own* C compiler? I think we're OK. Oh,
wait, I forgot: we have the ACPI language too. If we can put
something that ugly in
On 28.08.2015 18:29, ron minnich wrote:
I would really like this to be in the tree. It gives us a chance to do
things in coreboot that go beyond C and assembly. So that's my $.02.
Same here.
Besides that, SPARK gives us easier provability of code. That is
something governments and safety
Hi coreboot folks!
I dared to link a coreboot ramstage with, well, not only C but also some
fancy Ada code. Things worked out well enough and I'd like to release
the code and upstream it.
So, first question: Would it be accepted? being written in a foreign
language?
This code is essentially
This sounds wonderful. I'm all for it.
ron
On Fri, Aug 21, 2015 at 1:46 PM Nico Huber nico.hu...@secunet.com wrote:
Hi coreboot folks!
I dared to link a coreboot ramstage with, well, not only C but also some
fancy Ada code. Things worked out well enough and I'd like to release
the code and
18 matches
Mail list logo
