https://intel.taleo.net/careersection/1/jobdetail.ftl?job=725464
Thanks,
Scott
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
you don't want to follow the EFI path of a separate API for each
device type. That's pre-unix thinking. It's also a path we're on,
because coreboot was never intended to have drivers, and now we're
getting them, and we have not really thought it out.
You do want to create a reasonable abstraction
The other suggestion: take your time, and let's evolve this by looking
at code. Think about the interface first. Start a Google doc and we
can pitch in. That's how a lot of early linuxbios was done, via
emphasizing discussion of the API before we wrote code.
ron
--
coreboot mailing list: coreboo
Am Donnerstag, den 09.01.2014, 08:37 -0600 schrieb Scott Duplichan:
> https://intel.taleo.net/careersection/1/jobdetail.ftl?job=725464
Thanks - unfortunately it's on the wrong continent, as usual.
US developers seem to be mostly hoovered up by Google and Sage.
There's a considerable amount of
Hi Scott,
Without additional information about the following questions, the job offer
misses some candidates. Still, in this economy, kudos for the offer.
1. What does "coreboot engineer" mean? An engineer who has experience with
coreboot -- or an engineer who will be working openly, supporting t
On 01/09/2014 12:26 PM, ron minnich wrote:
> The other suggestion: take your time, and let's evolve this by looking
> at code. Think about the interface first. Start a Google doc and we
> can pitch in. That's how a lot of early linuxbios was done, via
> emphasizing discussion of the API before we w
David Hubbard [mailto:david.c.hubbard+coreb...@gmail.com] wrote:
]Hi Scott,
]Without additional information about the following questions,
]the job offer misses some candidates. Still, in this economy,
]kudos for the offer.
I have never worked for Intel so I can only guess about
the job details.
On Thu, Jan 9, 2014 at 10:48 AM, Patrick Georgi wrote:
> Am Donnerstag, den 09.01.2014, 08:37 -0600 schrieb Scott Duplichan:
> > https://intel.taleo.net/careersection/1/jobdetail.ftl?job=725464
> Thanks - unfortunately it's on the wrong continent, as usual.
>
> US developers seem to be mostly
Hello every one. I have searched a lot on the Net to find my answer but
I didn't got any helpful results so I decided to use the mailing list. my
question is that has any body ported coreboot to Bochs emulator
successfully.
I know that Qemu or Simnow are available for emulating a platform but I
lik
A number of us used bochs years ago for coreboot debugging. IIRC it
"just worked" when we tried it.
ron
On Thu, Jan 9, 2014 at 5:22 PM, behrouz khosravi wrote:
> Hello every one. I have searched a lot on the Net to find my answer but
> I didn't got any helpful results so I decided to use the mai
ron minnich [mailto:rminn...@gmail.com] wrote:
]A number of us used bochs years ago for coreboot debugging. IIRC it
]"just worked" when we tried it.
]
]ron
I remember in 2008 when a guy named Kevin proposed changing the
bochs bios from asm code to C code because the build environment
for the asm
i ran into three issues when trying to build FILO in the coreboot git
repo, using make menuconfig and make. i found work-arounds for two of
them. here are the issues:
TL;DR:
1.) include/arch doesn't exist (work-around by symlinking)
2.) conflicting types error
3.) invalid git command when building
Am 2014-01-10 02:22, schrieb behrouz khosravi:
I know that Qemu or Simnow are available for emulating a platform but
I like to test it Bochs.
If I remember correctly, one issue is that bochs has its BIOS entry
point at 0xf_fff0 (and maps the bios there, just below 1MB), while
coreboot expects a
Am 2014-01-10 05:58, schrieb Andrew Engelbrecht:
i ran into three issues when trying to build FILO in the coreboot git
repo, using make menuconfig and make. i found work-arounds for two of
them. here are the issues:
These are with filo 0.6.0, right? It depends on an age-old version of
libpayload
14 matches
Mail list logo
