[coreboot] QEMU BIOS question
Hi, 1. What is the difference between QEMU BIOS and the other coreboot BIOS which can be flashed to ROM? I mean what functionalities QEMU lack or incomplete compared to the others? 2. What is the major difference between QEMU coreboot BIOS and the original QEMU BIOS? High-level answers would be very helpful. I just want to know some basics. Any response is very appreciated. Thanks. Regards, Tommy -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] cbfstool2 0.9.9
Hi, I got my TODO covered: the current cbfstool2 works (as cbfstool, that 2 suffix is purely internal) as a drop-in replacement in the coreboot tree, incl. makefiles to build it both for newconfig and kconfig style builds. The code should match the codingstyle and license headers are added, so I think this is ready to go in. You can find the tarball at http://www.coresystems.de/~patrick/cbfstool2-0.9.9.tar.bz2 My change would also include a trivial change to newconfig, to only create a $(obj)/cbfs directory, instead of $(obj)/cbfs/tools/lzma, as this isn't necessary anymore. The svn diff is quite messy, as I reused files that are sufficiently similar using svn mv, and those changes aren't well expressed in diff output. That code is Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de Regards, Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] cbfstool2 0.9.9
Patrick Georgi wrote: Hi, I got my TODO covered: the current cbfstool2 works (as cbfstool, that 2 suffix is purely internal) as a drop-in replacement in the coreboot tree, incl. makefiles to build it both for newconfig and kconfig style builds. The code should match the codingstyle and license headers are added, so I think this is ready to go in. You can find the tarball at http://www.coresystems.de/~patrick/cbfstool2-0.9.9.tar.bz2 My change would also include a trivial change to newconfig, to only create a $(obj)/cbfs directory, instead of $(obj)/cbfs/tools/lzma, as this isn't necessary anymore. The svn diff is quite messy, as I reused files that are sufficiently similar using svn mv, and those changes aren't well expressed in diff output. That code is Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de Always glad to see additional reviews, but this update was really necessary for future use cases of coreboot / CBFS. Therefore Acked-by: Stefan Reinauer ste...@coresystems.de -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] hello coreboot
Hi coreboot my name is eran and i want to now what is road map for supporting the Intel atom core and what version of coreboot bios will support Intel® 945GM + Intel® ICH7R Chipset with Winbond W83627HF Thanks, Eran Shemi -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Geode LX VGA BIOS Patch
Kevin O'Connor wrote:
As before, the main seabios patch looks good to me. The modehack
patch, of course, needs to be cleaned up before committing. Are you
still working on this?
-Kevin
Yes, it is on my todo list. I was thinking about using a device
operations structure or macros to replace the if(hw_type)
statements. This might be overkill at the moment, however it would
be helpful for any future hardware specific expansion. I am lacking
insight on what such a struct should be. The following example is
crafted mostly to fix the current problems I am having.
struct videoDevice {
int (*present) (void); /* check for existence */
void (*enable) (int); /* enable device/mode */
void (*pre_init) (void);
void (*post_init) (void);
void (*set_mode) (u8 mode);
struct VideoParam_s *vga_param_table[];
struct vgamode_s *vga_mode_table[];
void *hw_tables;
};
struct videoDevice geodelx = {
.present = legacyio_check,
.pre_init = geodelx_init,
.post_init = geodelx_demo,
.vga_param_table = lx_param_table,
.vga_mode_table = lx_mode_table,
};
struct videoDevice cirrus = {
.pre_init = cirrus_init,
.set_mode = cirrus_set_video_mode,
.hw_tables = cirrus_modes,
};
struct videoDevice vbe = {
.present = vbe_has_vbe_display,
.enable = dispi_set_enable,
.pre_init = vbe_init,
.hw_tables = vbe_modes,
};
Let me know what you think and I can work on a patch,
Chris Kindt
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] Drop PowerPC port
On 10.09.2009 09:12, Stefan Reinauer wrote: in the progress of restructuring coreboot to work with CBFS, Kconfig and other new features, we basically broke the PowerPC boards. Since none of us has any of the supported hardware available for testing, and there is no real reason to use coreboot on PowerPC processors (there are fine bootloaders, like u-boot), we have been discussing to drop the PowerPC port completely if nobody is willing to step up and revive it. I remember some people talking about MIPS64 support for coreboot, and having _working_ PowerPC support in coreboot might help us to keep the general coreboot design mostly architecture-independent. However, since PowerPC support is essentially untestable without supported hardware, we don't even know if it is (or was) broken and thus it serves no purpose except holding development back. Drop it unless someone has the hardware and the skills to at least keep PowerPC support working with some help from others. In case someone magically appears, we can still dig up the old code from svn. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] Drop PowerPC port
Carl-Daniel Hailfinger wrote: On 10.09.2009 09:12, Stefan Reinauer wrote: in the progress of restructuring coreboot to work with CBFS, Kconfig and other new features, we basically broke the PowerPC boards. Since none of us has any of the supported hardware available for testing, and there is no real reason to use coreboot on PowerPC processors (there are fine bootloaders, like u-boot), we have been discussing to drop the PowerPC port completely if nobody is willing to step up and revive it. I remember some people talking about MIPS64 support for coreboot, and having _working_ PowerPC support in coreboot might help us to keep the general coreboot design mostly architecture-independent. Unfortunately, those people never even showed up on the mailing list to ask questions, so I doubt it's ever going to happen. However, since PowerPC support is essentially untestable without supported hardware, we don't even know if it is (or was) broken and thus it serves no purpose except holding development back. It compiles, but it basically can not work as it is now, sadly. Drop it unless someone has the hardware and the skills to at least keep PowerPC support working with some help from others. In case someone magically appears, we can still dig up the old code from svn. Full ack. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [v2][patch] Remover waits for keyboard controller keyboard enable status
Ping. Anyone want to test and ack this? Marc On Thu, Aug 20, 2009 at 11:04 PM, Marc Jones marcj...@gmail.com wrote: The code was waiting for status that doesn't get returned. Stefan, This should be correct. Can you try it out on a few of your problem KBCs/keyboards? Signed-off-by: Marc Jones marcj...@gmail.com -Marc -- http://marcjonesconsulting.com -- http://marcjonesconsulting.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] unstable AMD Fam10h boot
On Tue, Sep 8, 2009 at 11:02 AM, Marc Jones marcj...@gmail.com wrote:
On Sun, Sep 6, 2009 at 4:32 PM, ron minnichrminn...@gmail.com wrote:
The way I see it the memory setup and SMP support in CAR are two very
different issues.
This bug is totally my fault...
Yes, Memory setup and SMP CAR are two different issues. The SMP setup
happens during CAR is to setup microcode, HT and FIDVID prior to the
PLL reset and memory setup.
All the SMP PCI config space access should be MMIO. It is the first
thing that is enabled in CPU init in set_pci_mmio_conf_reg().
The bug is that I mixed a mem setup function in with SMP setup by
using mctGetLogicalCPUID() which uses Get_NB32. As pointed out, the
GET_NB32 is a cf8/cfc function. The mct code ported from AGESA assumes
that it is running on the BSP only and uses cf8/cfc. (historical
k8 bug I think)
I think that I should change the mct PCI config functions to call the
coreboot pci_read_config32 functions that handle MMIO vs cfc/cf8
nicely. This should future proof mct functions in CAR and a step
toward SMP memory setup.
Some of that mct code PCI config space code is a little funny (ok, a
lot funny), so it will take a little care. I should be able work patch
in a couple of days.
Here is a patch that fixes the cf8 config access. Not complicated like
I initially recalled. Thanks to Ralf for pointing out the bug.
This needs testing. Anyone?
Signed-off-by: Marc Jones marcj...@gmail.com
Thanks,
Marc
--
http://marcjonesconsulting.com
Use the coreboot pci config read/write functions instead of direct cf8/cfc access. The fam10 pci functions will use mmio and not have SMP pci access issues.
Signed-off-by: Marc Jones marcj...@gmail.com↔
Index: coreboot-v2/src/northbridge/amd/amdmct/mct/mct_d.c
===
--- coreboot-v2.orig/src/northbridge/amd/amdmct/mct/mct_d.c 2009-09-13 18:01:54.0 -0600
+++ coreboot-v2/src/northbridge/amd/amdmct/mct/mct_d.c 2009-09-13 18:09:08.0 -0600
@@ -2474,10 +2474,8 @@
{
u32 addr;
- addr = (dev4) | (reg 0xFF) | ((reg 0xf00)16);
- outl((131) | (addr ~3), 0xcf8);
-
- return inl(0xcfc);
+ addr = ((dev4) | (reg 0xFF) | ((reg 0xf00)16)) ~3;
+ return pci_read_config32(addr);
}
@@ -2485,9 +2483,8 @@
{
u32 addr;
- addr = (dev4) | (reg 0xFF) | ((reg 0xf00)16);
- outl((131) | (addr ~3), 0xcf8);
- outl(val, 0xcfc);
+ addr = ((dev4) | (reg 0xFF) | ((reg 0xf00)16)) ~3;
+ pci_write_config32(addr);
}
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] unstable AMD Fam10h boot
On Sun, Sep 13, 2009 at 06:46:38PM -0600, Marc Jones wrote: Here is a patch that fixes the cf8 config access. Not complicated like I initially recalled. Thanks to Ralf for pointing out the bug. This needs testing. Anyone? We've got a couple H8DME/fam10 boxes coming this week, so I should be able to test this in a couple days. Will do as soon as we get the hardware. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
