As some of you might have noticed, there is a coreboot-v2-newbuild
branch in the repository. It contains the current state of an effort to
get coreboot v2 to build under kconfig/kbuild(-style) tools, which seems
to be universally accepted as a desirable goal.
(If you don't think so, please state your issues with that, so we
wouldn't waste too much time on this, kthx)
That work was done in a way that abuild is unaffected: except some minor
remaining issues with CONFIG_* prefixes, the source files are exactly
the same as upstream, and abuild ran successfully.
Two boards are Kconfig'd so far, QEmu and Kontron 986LCD-M, but there
are some remaining issues with the Kontron, so it doesn't boot yet. QEmu
builds and runs (but without CAR at this time, and that's deliberate to
have a test case for a romcc-board)
There are quite a lot of things to be done still, and many things are
not at the right location yet (eg. many configuration options reside in
src/Kconfig when there's a better place for them).
Should we push it to trunk now (given that it doesn't break abuild)?
Should we define a milestone that has to be completed (eg. a given set
of boards has to run)?
This is a request for comments, so... :)
On 29.07.2009 10:51, jorgefm(a)cirsa.com wrote:
> This is my first email to this mailing list. I've joined because I've a
> little question related to the
> BIOS superio initialization process and I would like to ask to the
We specialize in coreboot related questions, so it's unlikely we can
help you with a BIOS problem unless you want to replace that BIOS with
> I'm developing a little hardware module with a w83627hf superio module.
> This hardware is attached to a com express module. I've found that my
> hardware is not always initialized
> by the com express BIOS, it depends on the manufacter.
> Then, I think that the hardware is working but I need some initialization
> in the southbridge or something
> else that the first BIOS is doing. Where can I looking for this info? Both
> com express modules has the intel ICH7-M southbridge.
I'd say the best way forward is to diagnose this with the help of
superiotool. Make sure the w83627hf kernel module is not loaded
automatically, then run superiotool -dV and compare the outputs. If
superiotool finds your SuperIO only on one of the boards, you most
likely have a southbridge resource configuration problem which needs to
be addresses by the BIOS manufacturer (or a custom early kernel driver).
If superiotool finds your SuperIO on both boards, compare the settings
and work from there.
On Wed, Jul 29, 2009 at 03:24:06PM +0200, Arnaud Maye wrote:
> Something I just realized. When am using filo I can use the keyboard
> input but this is in fact coming from the UART link, not the PS2
> connector itself, sorry for that.
> However, I've tried to press F12, on the UART client as well as on
> the PS2 keyboard, I cannot reach seabios menu.
Okay, that is different - it leads me to believe that coreboot isn't
turning on your ps2 port.
SeaBIOS does not read keys from the serial port. If you wish to do
that then add the sgabios optionrom to the flash - see the directions
> Something is indeed very wrong as using coreboot as BIOS does not
> initialize the keyboard in fact. Pressing "num lock" on the
> keyboard does not change the LED status. With the legacy BIOS it
> does of course.
It's SeaBIOS that implements the numlock led - since SeaBIOS can't
access the ps2 port it wont work.
> I am sending you what you have asked anyway. So I guess as for the
> VGA we are back to coreboot code base?
I think we need to get input from the coreboot experts.
Attached are two patches
* one checking the return code of various malloc and memalign calls
* another one fixes a bug in the keyboard driver and a bug in the video
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info(a)coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
I'm getting this output when running a qemu ROM compiled using latest v2
tree, and my AVATT payload - with KVM support in qemu/kernel it freezes,
and without, it crashes:
The freeze occurs just after the "Jumping to boot code at 10000" message
If anyone has a clue, please help me.
Ing. Cristi Măgherușan, System/Network Engineer
Technical University of Cluj-Napoca, Romania
http://cc.utcluj.ro +40264 401247
Since DBM690T does not have UHCI controller, i bought an PCI-USB card
which contained two UHCI controller. But It always caused rebooting when the
option rom try to initialize the controller. I attached all of the messages,
and looking for some help.
Until now my doubt is the real bus/dev/func is 06/05/01, but while seabios
search it as 00/05/01.