Re: [coreboot] [PATCH] HP e-Vectra P2706T support
Peter Stuge wrote: Carl-Daniel Hailfinger wrote: The code does not really support more than one CPU type at a time. CAR code for K8/Fam10 autodetects the CPU and issues the right commands based on autodetection. That's fine, but it's not worth much without actually supporting both CPU types later on in the binary as well.. Yes, and no. We used that codeto be able to switch between two completely different AMD mainboards (different chipsets and different CPUs) instead of doing normal/fallback. On K8/Fam10 this choice is done after enabling CAR. So just having unified CAR is worth a whole lot already. Apart from that, it would be very nice to unify the later K8/Fam10 CPU code of course. Maybe you want to give it a try? Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] HP e-Vectra P2706T support
Paweł Stawicki wrote: I was able run my VIA c3 processor :-) changing the line: chip cpu/intel/socket_PGA370# CPU to: chip cpu/via/model_c3 in Config.lb but how to turn on intel processors AND via C3 processors ? Instead of the above, you should add the VIA cpu to the PGA370 socket. right now the Config.lb of that socket looks like this: config chip.h object socket_PGA370.o dir /cpu/intel/model_6xx You should add another line there: dir /cpu/via/model_c3 This will enable CPU support code for all model 6xx intel CPUs as well as VIA C3 CPUs As a side discussion to all developers: We could move the sockets from intel/ and amd/ to src/cpu/sockets or some such for those few CPUs that have a cross vendor compatible socket (right now I think only some old VIA CPUs have that...) Not sure if it's worth the effort. Flames? Ideas? Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] HP e-Vectra P2706T support
Peter Stuge wrote: but how to turn on intel processors AND via C3 processors ? This is the first time it has been done. Supporting several CPUs on one socket is not so new though. The code does not really support more than one CPU type at a time. Not exactly. All required infrastructure is there and we have been doing that many, many times. For example for Core Duo and Core 2 Duo CPUs. The difference here is that the two CPU types come from different vendor directories, but that shouldn't be an issue. Check the cpu_table[] array of each supported CPU and arch/i386/lib/cpu.c:cpu_initialize()/set_cpu_ops() to learn about the matching. It would be nice to improve this because the AM2 mainboards can use both k8 and fam10, but it's not being worked on. The problem with K8 and Fam10 is not a CPU issue but a northbridge issue. All CPU specific code can be executed just fine, but in our model the northbridge is always fixed part of the board and not of the CPU, which is why it is somewhat hard coded. This is not a problem for stage2, but only for auto.c. Basically auto.c needs to do know both/several northbridges and choose which one to use. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PCI config
Myles Watson wrote: The attached patch fixes booting for arima/hdama. How should we really fix it? In v3 didn't we just scrap type 2 accesses all together? We can keep the type 2 support code, but the auto detection at run time makes absolutely no sense. I sent a patch for this some days ago, but I think Carl-Daniel didn't have too much success with it on his board. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Make various DEBUG defines user-configurable in menuconfig
Myles Watson wrote: Right now I'd like to match newconfig and kill it as quickly as possible. Sure, same here. I don't think this patch interferes with this effort though. As long as all of the code that gets enabled/disabled is only print statements, that's probably true. I was worried that some of these boards may depend on the correct setting of those debug flags to be functional. Which boards are that? Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Major cleanups of hard_reset() related code/config
Uwe Hermann wrote: See patch. I'm happy for any comments. Also, I'm not sure how all this hard_reset() stuff is meant to work. Many southbridges have _two_ implementations of hard_reset(). Why? Some only have one. Some have none, but I guess that's OK, as their RAM init or other coreboot code doesn't need to reset the machine (?) And then there are various reset.c files in the mainboard directories which don't look board-specific at all. I propose to drop them all and provide one global hard_reset() function somewhere. Feasible? It might silently break a lot of stuff. There's about 6 ways to reset a machine (probably more) and it's not always trivial to see why a certain reset method is needed at a certain time. To your patch, I don't understand why you're suggesting to rename hard_reset to board_name_hard_reset(). That seems like an awful idea... Any reason for it? Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] booting fails on FAM10 machine
Hi all, I did a fresh svn co the other day and tried building and running a Tyan S2912_fam10 system. With older sources (rev 4729) everything worked just fine, with the newest checkout the booting process stops at setting MTRR registers or a little later (depending on the compiler used: 3.4.6 builds faster code and gets further than 4.3.3, both Ubuntu fashion). I tried tracking down the problem and it appeared to me as if the switch from CONFIG_LB_MEM_TOPK to CONFIG_RAMTOP must have something to do with this though I couldnt find an error when comparing all the files affected by this switch. Attached are the last lines of the debug printout. Does anyone have an idea, where this error might come from or if there are any unintended side effects associated with this change? Thanks in advance, Maximilian -- Maximilian Thuermer University of Heidelberg Zentrales Institut für Technische Informatik (ziti) Computer Architecture Group B 6, 26, 68131 Mannheim http://ra.ziti.uni-heidelberg.de email: maximilian.thuer...@ziti.uni-heidelberg.de Initializing devices... Root Device init APIC_CLUSTER: 0 init start_eip=0xd000, offset=0x0010, code_size=0x005b Initializing CPU #0 CPU: vendor AMD device 100f42 CPU: family 10, model 04, stepping 02 nodeid = 00, coreid = 00 Enabling cache Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM DONE fixed MTRRs Setting variable MTRR 0, base:0MB, range: 8192MB, type WB ADDRESS_MASK_HIGH=0x Setting variable MTRR 1, base: 8192MB, range: 512MB, type WB ADDRESS_MASK_HIGH=0x Setting variable MTRR 2, base: 3584MB, range: 512MB, type UC ADDRESS_MASK_HIGH=0x DONE variable MTRRs Clear out the extra MTRR's call enable_var_mtrr() Leave x86_setup_var_mtrrs MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled Setting up local apic... apic_id: 0x00 done. CPU model: AMD Thermal Test Kit siblings = 03, CPU #0 initialized Asserting INIT. Waiting for send to finish... +Deasserting INIT. Waiting for send to finish... +#startup loops: 2. Sending STARTUP #1 to 1. After apic_write. Startup point 1. Waiting for send to finish... +Sending STARTUP #2 to 1. After apic_write. Startup point 1. Waiting for send to finish... +After Startup. Initializing CPU #1 CPU: vendor AMD device 100f42 CPU: family 10, model 04, stepping 02 nodeid = 00, coreid = 01 Enabling cache Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM DONE fixed MTRRs Setting variable MTRR 0, base:0MB, range: 8192MB, type WB ADDRESS_MASK_HIGH=0x Setting variable MTRR 1, base: 8192MB, range: 512MB, type WB ADDRESS_MASK_HIGH=0x Setting variable MTRR 2, base: 3584MB, range: 512MB, type UC ADDRESS_MASK_HIGH=0x DONE variable MTRRs Clear out the extra MTRR's call enable_var_mtrr() Leave x86_setup_var_mtrrs MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled Setting up local apic... apic_id: 0x01 done. CPU model: AMD Thermal Test Kit siblings = 03, CPU #1 initialized Asserting INIT.
Re: [coreboot] Help getting a P2B board running with coreboot
On 21/10/09 18:27, Mark Marshall wrote: Hi. I've been lurking here for some time, and am slowly trying to get a ASUS P2B board to run with coreboot. This is mainly so that I can get to grips with how coreboot works - the P2B seemed to be an easy starting point (well documented and cheap, they're on e-bay for £10). I've built a ROM image from earlier today and loaded it into a flash, and I do get some serial output. I can see coreboot attempts to initialize the memory and then hangs when it tries to copy the CBFS image to RAM. I've played with the magic numbers in raminit.c (so that they match the DIMM I've got) and now it boots. So most of my questions have now been answered. Thanks anyway. MM PS. Is there a good reason why boards of this vintage don't use CAR? Is there a chance that some CPUs will not have enough cache to make it worth while, or is this something that someone could add at some point? -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] HP e-Vectra P2706T support
2009/10/22 Stefan Reinauer ste...@coresystems.de Instead of the above, you should add the VIA cpu to the PGA370 socket. right now the Config.lb of that socket looks like this: config chip.h object socket_PGA370.o dir /cpu/intel/model_6xx You should add another line there: dir /cpu/via/model_c3 This will enable CPU support code for all model 6xx intel CPUs as well as VIA C3 CPUs This change seems to work. Thanks a lot. Paweł -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Make various DEBUG defines user-configurable in menuconfig
As long as all of the code that gets enabled/disabled is only print statements, that's probably true. I was worried that some of these boards may depend on the correct setting of those debug flags to be functional. Which boards are that? There are lots of boards affected by this patch, and especially some of the DEBUG_CAR stuff looked like copy-paste from other places. I don't think we should encourage people to change those settings until they've been tested, or at least until someone is willing to go through and make sure that it only enables/disables print statements. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PCI config
Myles Watson wrote: How should we really fix it? In v3 didn't we just scrap type 2 accesses all together? We can keep the type 2 support code, but the auto detection at run time makes absolutely no sense. I sent a patch for this some days ago, but I think Carl-Daniel didn't have too much success with it on his board. Maybe we could simplify it a little and try again. It looks like the rs690 changes were pretty extensive. Generally, we should also change the mainboard code to access pci devices in -init, not in -enable. This should solve the issues. Then, dropping auto detect could be the next step. -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: i...@coresystems.de • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]
It froze again. Here is some of the output: SMBus controller enabled Ram1.00 setting up CPU00 northbridge registers done. Ram1.01 setting up CPU01 northbridge registers done. Ram2.00 Enabling dual channel memory Registered 166Mhz RAM end at 0x0010 kB Lower RAM end at 0x0010 kB Ram2.01 Enabling dual channel memory Registered 166Mhz RAM end at 0x0020 kB Lower RAM end at 0x0020 kB Ram3 Before starting clocks: Before memreset: cpu is pre_c0 after first udelay -- Hugh Greenberg Myles Watson wrote: While I was just trying to get seabios to boot gpxe, coreboot hung at the same spot. It seems to happen randomly now, not every time it boots like before. Too bad. I guess put all the debugging back in and see if it still hangs randomly, and if it is exactly the same spot. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PCI config
Myles Watson wrote: How should we really fix it? In v3 didn't we just scrap type 2 accesses all together? We can keep the type 2 support code, but the auto detection at run time makes absolutely no sense. I sent a patch for this some days ago, but I think Carl-Daniel didn't have too much success with it on his board. Maybe we could simplify it a little and try again. It looks like the rs690 changes were pretty extensive. Generally, we should also change the mainboard code to access pci devices in -init, not in -enable. This should solve the issues. I thought enable was run at the very beginning, before scan, while init was run at the end. That seems like a hard conversion to make. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PCI config
Myles Watson wrote: The attached patch fixes booting for arima/hdama. How should we really fix it? In v3 didn't we just scrap type 2 accesses all together? We can keep the type 2 support code, but the auto detection at run time makes absolutely no sense. The auto detection code is the only place the type 2 struct is referenced. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]
On Thu, Oct 22, 2009 at 09:16:14AM -0600, Myles Watson wrote: RAM end at 0x0020 kB Lower RAM end at 0x0020 kB Ram3 Before starting clocks: Before memreset: cpu is pre_c0 after first udelay OK. So the timer worked for the first udelay... Does it only freeze when you have both CPUs enabled? Have you tried it with the no_smp patch again? I'm grasping at straws. This is starting to sound like all the weirdness I was seeing when working on the h8dmr fam10 port a few months ago. Are you sure it hangs? I thought so at first as well, but it turned out that things were running extremely slowly when compiling with gcc 4.3 (32 bit). If I waited 5 minutes or so eventually the board would boot. Can you reproduce a hang when changing CONSOLE_LOGLEVEL ? In my case the board would just hang if I lowered the default loglevel to something less than 8. I never did figure out what was going on there. Ron thought perhaps there was a cache issue. I put a file in the tree with the issues I ran into src/mainboard/supermicro/h8dmr_fam10/README I haven't been able to revisit yet as that particular box is in production. What toolchain are you using? 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
Re: [coreboot] booting fails on FAM10 machine
I did a fresh svn co the other day and tried building and running a Tyan S2912_fam10 system. With older sources (rev 4729) everything worked just fine, with the newest checkout the booting process stops at setting MTRR registers or a little later (depending on the compiler used: 3.4.6 builds faster code and gets further than 4.3.3, both Ubuntu fashion). I tried tracking down the problem and it appeared to me as if the switch from CONFIG_LB_MEM_TOPK to CONFIG_RAMTOP It's possible. Could you try Rev 4787 4788 to make sure, then send me the logs from both? I'm also interested in the coreboot_ram.map files. must have something to do with this though I couldnt find an error when comparing all the files affected by this switch. Attached are the last lines of the debug printout. Does anyone have an idea, where this error might come from or if there are any unintended side effects associated with this change? There shouldn't have been any. Hopefully everywhere it was (TOPK) it is now (RAMTOP 10) and everywhere it was (TOPK10) it is (RAMTOP). Thanks for helping track it down. Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PCI config
On Thu, Oct 22, 2009 at 9:36 AM, Stefan Reinauer ste...@coresystems.dewrote: Myles Watson wrote: I thought enable was run at the very beginning, before scan, while init was run at the end. Yes. That seems like a hard conversion to make. Why? I thought that some of the PCI accesses were to set things up before scanning the bus and reading the resources. If we change the order drastically, we will probably break all kinds of assumptions. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] HP e-Vectra P2706T support
dir /cpu/via/model_c3 Since this worked for him, is there a reason not to commit the change? This will enable CPU support code for all model 6xx intel CPUs as well as VIA C3 CPUs As a side discussion to all developers: We could move the sockets from intel/ and amd/ to src/cpu/sockets or some such for those few CPUs that have a cross vendor compatible socket (right now I think only some old VIA CPUs have that...) Not sure if it's worth the effort. Flames? Ideas? I think we can justify the position that it's still an Intel socket, even if a VIA CPU fits in it. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PCI config
On 22.10.2009 09:57, Stefan Reinauer wrote: Myles Watson wrote: The attached patch fixes booting for arima/hdama. How should we really fix it? In v3 didn't we just scrap type 2 accesses all together? We can keep the type 2 support code, but the auto detection at run time makes absolutely no sense. I sent a patch for this some days ago, but I think Carl-Daniel didn't have too much success with it on his board. Yes, if I applied the complete patch, the board was hanging. If I applied parts of the patch (the rs690 part), the board still was hanging, but I think that was due to a device tree code bug/limitation. I can dig up the details if you want, becase the patch itself looked desirable. Regards, Carl-Daniel -- Developer quote of the week: We are juggling too many chainsaws and flaming arrows and tigers. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PCI config
On Thu, Oct 22, 2009 at 9:45 AM, Carl-Daniel Hailfinger
c-d.hailfinger.devel.2...@gmx.net wrote:
On 22.10.2009 09:57, Stefan Reinauer wrote:
Myles Watson wrote:
The attached patch fixes booting for arima/hdama.
How should we really fix it? In v3 didn't we just scrap type 2
accesses all together?
We can keep the type 2 support code, but the auto detection at run time
makes absolutely no sense.
I sent a patch for this some days ago, but I think Carl-Daniel didn't
have too much success with it on his board.
Yes, if I applied the complete patch, the board was hanging. If I
applied parts of the patch (the rs690 part), the board still was
hanging, but I think that was due to a device tree code bug/limitation.
I can dig up the details if you want, becase the patch itself looked
desirable.
What if you just take out the init call in the enable function?
Modified patch attached.
Thanks,
Myles
Simplify coreboot PCI handling
This patch drops the conf1/conf2 autodetection and replaces it by
(usually northbridge specific) hardcodes.
This patch also adds pci_domain_init() which needs to be called by
mainboard enable_dev() functions in order to be able to use the pci
config space functions. This allows to drop i386 specific code from
generic files again...
There is an even better approach to the PCI config space access in mainboard
specific init files problem, but that should go into another patch:
static void init(struct device *dev)
{
// Do the stuff here!
}
static void enable_dev(struct device *dev)
{
// Install an init function for this mainboard device
dev-ops-init = init;
}
struct chip_operations mainboard_ops = {
.enable_dev = enable_dev,
};
Signed-off-by: Stefan Reinauer ste...@coresystems.de
Index: svn/src/southbridge/amd/rs690/rs690.c
===
--- svn.orig/src/southbridge/amd/rs690/rs690.c
+++ svn/src/southbridge/amd/rs690/rs690.c
@@ -37,34 +37,33 @@ void static rs690_config_misc_clk(device
{
u32 reg;
u16 word;
- /* u8 byte; */
- struct bus pbus; /* fake bus for dev0 fun1 */
+ device_t nb2_dev = dev_find_slot(0, PCI_DEVFN(0, 1));
reg = pci_read_config32(nb_dev, 0x4c);
reg |= 1 0;
pci_write_config32(nb_dev, 0x4c, reg);
- word = pci_cf8_conf1.read16(pbus, 0, 1, 0xf8);
+ word = pci_read_config16(nb2_dev, 0xf8);
word = 0xf00;
- pci_cf8_conf1.write16(pbus, 0, 1, 0xf8, word);
+ pci_write_config16(nb2_dev, 0xf8, word);
- word = pci_cf8_conf1.read16(pbus, 0, 1, 0xe8);
+ word = pci_read_config16(nb2_dev, 0xe8);
word = ~((1 12) | (1 13) | (1 14));
word |= 1 13;
- pci_cf8_conf1.write16(pbus, 0, 1, 0xe8, word);
+ pci_write_config16(nb2_dev, 0xe8, word);
- reg = pci_cf8_conf1.read32(pbus, 0, 1, 0x94);
+ reg = pci_read_config32(nb2_dev, 0x94);
reg = ~((1 16) | (1 24) | (1 28));
- pci_cf8_conf1.write32(pbus, 0, 1, 0x94, reg);
+ pci_write_config32(nb2_dev, 0x94, reg);
- reg = pci_cf8_conf1.read32(pbus, 0, 1, 0x8c);
+ reg = pci_read_config32(nb2_dev, 0x8c);
reg = ~((1 13) | (1 14) | (1 24) | (1 25));
reg |= 1 13;
- pci_cf8_conf1.write32(pbus, 0, 1, 0x8c, reg);
+ pci_write_config32(nb2_dev, 0x8c, reg);
- reg = pci_cf8_conf1.read32(pbus, 0, 1, 0xcc);
+ reg = pci_read_config32(nb2_dev, 0xcc);
reg |= 1 24;
- pci_cf8_conf1.write32(pbus, 0, 1, 0xcc, reg);
+ pci_write_config32(nb2_dev, 0xcc, reg);
reg = nbmc_read_index(nb_dev, 0x7a);
reg = ~0x3f;
@@ -72,26 +71,28 @@ void static rs690_config_misc_clk(device
reg = ~(1 6);
set_htiu_enable_bits(nb_dev, 0x05, 1 11, 1 11);
nbmc_write_index(nb_dev, 0x7a, reg);
+
/* Powering Down efuse and strap block clocks after boot-up. GFX Mode. */
- reg = pci_cf8_conf1.read32(pbus, 0, 1, 0xcc);
+ reg = pci_read_config32(nb2_dev, 0xcc);
reg = ~(1 23);
- reg |= 1 24;
- pci_cf8_conf1.write32(pbus, 0, 1, 0xcc, reg);
+ reg |= 1 24; // already set?
+ pci_write_config32(nb2_dev, 0xcc, reg);
+
#if 0
/* Powerdown reference clock to graphics core PLL in northbridge only mode */
- reg = pci_cf8_conf1.read32(pbus, 0, 1, 0x8c);
+ reg = pci_read_config32(nb2_dev, 0x8c);
reg |= 1 21;
- pci_cf8_conf1.write32(pbus, 0, 1, 0x8c, reg);
+ pci_write_config32(nb2_dev, 0x8c, reg);
/* Powering Down efuse and strap block clocks after boot-up. NB Only Mode. */
- reg = pci_cf8_conf1.read32(pbus, 0, 1, 0xcc);
+ reg = pci_read_config32(nb2_dev, 0xcc);
reg |= (1 23) | (1 24);
- pci_cf8_conf1.write32(pbus, 0, 1, 0xcc, reg);
+ pci_write_config32(nb2_dev, 0xcc, reg);
/* Powerdown clock to memory controller in northbridge only mode */
- byte = pci_cf8_conf1.read8(pbus, 0, 1, 0xe4);
+ byte = pci_read_config8(nb2_dev, 0xe4);
byte |= 1 0;
- pci_cf8_conf1.write8(pbus, 0, 1, 0xe4, reg);
+ pci_write_config8(nb2_dev, 0xe4, reg);
/* CLKCFG:0xE8 Bit[17] = 0x1 Powerdown clock to IOC GFX block in no external graphics mode */
/* TODO: */
Index: svn/src/southbridge/amd/rs690/rs690_pcie.c
Re: [coreboot] [PATCH] HP e-Vectra P2706T support
Myles Watson wrote: dir /cpu/via/model_c3 Since this worked for him, is there a reason not to commit the change? No. As a side discussion to all developers: We could move the sockets from intel/ and amd/ to src/cpu/sockets or some such for those few CPUs that have a cross vendor compatible socket (right now I think only some old VIA CPUs have that...) Not sure if it's worth the effort. Flames? Ideas? I think we can justify the position that it's still an Intel socket, even if a VIA CPU fits in it. good plan. -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: i...@coresystems.de • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Kontron doesn't build with Kconfig
SMM support hasn't been added yet. Should we disable SMI for Kontron, or does someone who understands it want to add the code to the Makefiles? It doesn't look that bad, but it will be a lot easier for someone who is already familiar with it. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [v2] r4823 - trunk/coreboot-v2/src/cpu/amd/model_lx
Author: stepan Date: 2009-10-22 18:59:33 +0200 (Thu, 22 Oct 2009) New Revision: 4823 Modified: trunk/coreboot-v2/src/cpu/amd/model_lx/vsmsetup.c Log: trivial: add note that VSA blob belongs into CBFS. Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de Modified: trunk/coreboot-v2/src/cpu/amd/model_lx/vsmsetup.c === --- trunk/coreboot-v2/src/cpu/amd/model_lx/vsmsetup.c 2009-10-22 02:54:25 UTC (rev 4822) +++ trunk/coreboot-v2/src/cpu/amd/model_lx/vsmsetup.c 2009-10-22 16:59:33 UTC (rev 4823) @@ -291,6 +291,7 @@ * much better parameterized */ + // TODO this is a CBFS candidate //VSA is cat onto the end after LB builds rom = ((unsigned long)0) - (CONFIG_ROM_SIZE + 36 * 1024); buf = (unsigned char *)VSA2_BUFFER; -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [v2] r4824 - trunk/coreboot-v2/src/southbridge/ricoh/rl5c476
Author: stepan
Date: 2009-10-22 19:02:44 +0200 (Thu, 22 Oct 2009)
New Revision: 4824
Modified:
trunk/coreboot-v2/src/southbridge/ricoh/rl5c476/rl5c476.c
Log:
minimal whitespace fix (trivial)
Signed-off-by: Stefan Reinauer ste...@coresystems.de
Acked-by: Stefan Reinauer ste...@coresystems.de
Modified: trunk/coreboot-v2/src/southbridge/ricoh/rl5c476/rl5c476.c
===
--- trunk/coreboot-v2/src/southbridge/ricoh/rl5c476/rl5c476.c 2009-10-22
16:59:33 UTC (rev 4823)
+++ trunk/coreboot-v2/src/southbridge/ricoh/rl5c476/rl5c476.c 2009-10-22
17:02:44 UTC (rev 4824)
@@ -172,7 +172,7 @@
if( enable_cf_boot (PCI_FUNC(dev-path.pci.devfn) == 1)){
/* fake index as it isn't in PCI config space */
resource = new_resource(dev, 1);
- resource-flags |= IORESOURCE_MEM ;
+ resource-flags |= IORESOURCE_MEM;
resource-size = 0x1000;
resource-align = resource-gran = 12;
resource-limit= 0x;
@@ -188,7 +188,7 @@
resource = find_resource(dev,1);
if( !(resource-flags IORESOURCE_STORED) ){
resource-flags |= IORESOURCE_STORED ;
- printk_debug(%s 1 ==
%x\n,dev_path(dev),resource-base);
+ printk_debug(%s 1 == %x\n, dev_path(dev),
resource-base);
cf_base = resource-base;
}
}
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Some help for the lay person?
On Thu, Oct 22, 2009 at 07:29:14AM +0200, Peter Stuge wrote: Mick Reed wrote: Procedure 2: check out coreboot-v2 source cd into coreboot-v2 directory make menuconfig make Note that this is still in alpha stage for most if not all listed boards. Yep. Where is kconfig looking for payload.elf? Either in coreboot-v2 or in the build/ directory. Top-level coreboot-v2 directory works (don't know about build/). It didn't seem to like the absolute path that I put into menuconfig. I consider that a bug then. Again, note that Kconfig does not really work completely yet. An absolute path should work there. It does, I just tested on trunk. I would like a relative path be relative to the coreboot-v2 directory rather than the build subdirectory. That's the case in trunk, works fine. I'm trying to build a rom with filo for my tyan s2885. I'd like to write a generic build tutorial for the lay person, or at least for non-programmers (me). I have identified some general steps, and have some questions. We'll have such a generic HOWTO in the wiki as soon as kconfig becomes the default (no need to write something for the old system, it'll be gone soon). Here's the current (work in progress) page: http://www.coreboot.org/Build_HOWTO Please let us know if there is missing information or if you have suggestions for improvements (but note that kconfig is a moving target right now, one or two things may change until we make it the default). Procedure 4: Test the rom (qemu, etc) Put it in the machine and go! (flashrom) You cannot test an image meant for real hardware in QEMU. Only the Emulation / QEMU mainboard works in QEMU. And the QEMU mainboard won't work on any actual hardware either, of course. FYI flashrom works on my board, I upgraded and verified my vendor bios with it. Tyan S2885? We don't seem to list that on the flashrom page, yet. Can you post flashrom -V output to the flashrom mailing list for reference? Did flashrom say VERIFIED after the write? Thanks! Uwe. -- http://www.hermann-uwe.de | http://www.randomprojects.org http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Post code 0x80
Hello, I am working on booting up VIA VX800 board with coreboot. I have coreboot (r4824) stuck on POST code 0x80 (sequence was 00 - 10 - 80) with this board. Could somebody please let me know where (in which source file in coreboot) this code is outputted in port 0x80? Thank you, Konstantin Lazarev. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Post code 0x80
On Thu, Oct 22, 2009 at 6:29 PM, Konstantin Lazarev klaza...@sbcglobal.netwrote: Hello, I am working on booting up VIA VX800 board with coreboot. I have coreboot (r4824) stuck on POST code 0x80 (sequence was 00 - 10 - 80) with this board. Could somebody please let me know where (in which source file in coreboot) this code is outputted in port 0x80? src/boot/hardwaremain.c, right before console_init. Hopefully you'll quickly get to the point where you can use serial output, it's much more informative. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] CBFS failed to load vga rom
PCI: 00:02.0 init Starting Graphics Initialization Check CBFS header at fffeffe0 magic is 4f524243 Found CBFS header at fffeffe0 Check fallback/coreboot_ram CBFS: follow chain: fff0 + 38 + 8073 + align - fff080c0 Check CBFS: follow chain: fff080c0 + 28 + e7ef8 + align - CBFS: Could not find file pci8086,3577.rom In cbfs, rom address for PCI: 00:02.0 = On mainboard, rom address for PCI: 00:02.0 = fff0 PCI Expansion ROM, signature 0x414c, INIT size 0xa400, data ptr 0x6166 Incorrect Expansion ROM Header Signature 414c Graphics Initialization Complete any ideas? -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] CBFS failed to load vga rom
Have you added the vga rom into image by running ./cbfs/cbfstool ./coreboot.rom add ../vga_bios.rom pci,.rom optionrom : vendor id : device id And Please provide the output of sh cbfstool coreboot.rom print Zheng Date: Thu, 22 Oct 2009 23:42:19 -0400 From: j...@settoplinux.org To: coreboot@coreboot.org Subject: [coreboot] CBFS failed to load vga rom PCI: 00:02.0 init Starting Graphics Initialization Check CBFS header at fffeffe0 magic is 4f524243 Found CBFS header at fffeffe0 Check fallback/coreboot_ram CBFS: follow chain: fff0 + 38 + 8073 + align - fff080c0 Check CBFS: follow chain: fff080c0 + 28 + e7ef8 + align - CBFS: Could not find file pci8086,3577.rom In cbfs, rom address for PCI: 00:02.0 = On mainboard, rom address for PCI: 00:02.0 = fff0 PCI Expansion ROM, signature 0x414c, INIT size 0xa400, data ptr 0x6166 Incorrect Expansion ROM Header Signature 414c Graphics Initialization Complete any ideas? -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot _ Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail you. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Post code 0x80
Konstantin Lazarev wrote: I am working on booting up VIA VX800 board with coreboot. Which board are you using? //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] CBFS failed to load vga rom
On 10/23/2009 12:07 AM, Zheng Bao wrote: Have you added the vga rom into image by running ./cbfs/cbfstool ./coreboot.rom add ../vga_bios.rom pci,.rom optionrom : vendor id : device id And Please provide the output of sh cbfstool coreboot.rom print Zheng Date: Thu, 22 Oct 2009 23:42:19 -0400 From: j...@settoplinux.org To: coreboot@coreboot.org Subject: [coreboot] CBFS failed to load vga rom PCI: 00:02.0 init Starting Graphics Initialization Check CBFS header at fffeffe0 magic is 4f524243 Found CBFS header at fffeffe0 Check fallback/coreboot_ram CBFS: follow chain: fff0 + 38 + 8073 + align - fff080c0 Check CBFS: follow chain: fff080c0 + 28 + e7ef8 + align - CBFS: Could not find file pci8086,3577.rom In cbfs, rom address for PCI: 00:02.0 = On mainboard, rom address for PCI: 00:02.0 = fff0 PCI Expansion ROM, signature 0x414c, INIT size 0xa400, data ptr 0x6166 Incorrect Expansion ROM Header Signature 414c Graphics Initialization Complete any ideas? -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail you. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010 [...@smitty5m cbfstool]$ ./cbfstool /home/joe/coreboot-v2/build/coreboot.rom print /home/joe/coreboot-v2/build/coreboot.rom: 1024 kB, bootblocksize 65536, romsize 1048576, offset 0x0 Alignment: 64 bytes Name Offset Type Size fallback/coreboot_ram 0x0stage32883 0x80c0 null 950008 [...@smitty5m cbfstool]$ I am using kconfig. Isn't kconfig supposed to add the vga rom to image? -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] CBFS failed to load vga rom
Joseph Smith wrote: On 10/23/2009 12:07 AM, Zheng Bao wrote: Have you added the vga rom into image by running ./cbfs/cbfstool ./coreboot.rom add ../vga_bios.rom pci,.rom optionrom : vendor id : device id And Please provide the output of sh cbfstool coreboot.rom print .. [...@smitty5m cbfstool]$ ./cbfstool /home/joe/coreboot-v2/build/coreboot.rom print /home/joe/coreboot-v2/build/coreboot.rom: 1024 kB, bootblocksize 65536, romsize 1048576, offset 0x0 Alignment: 64 bytes Name Offset Type Size fallback/coreboot_ram 0x0stage32883 0x80c0 null 950008 [...@smitty5m cbfstool]$ I am using kconfig. Isn't kconfig supposed to add the vga rom to image? You have to enable CONFIG_VGA_BIOS, set CONFIG_FALLBACK_VGA_BIOS_ID to the right PCI ID and give the filename at CONFIG_FALLBACK_VGA_BIOS_FILE. Look under VGA BIOS in the top level menu. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] CBFS failed to load vga rom
On 10/23/2009 12:33 AM, Peter Stuge wrote: Joseph Smith wrote: On 10/23/2009 12:07 AM, Zheng Bao wrote: Have you added the vga rom into image by running ./cbfs/cbfstool ./coreboot.rom add ../vga_bios.rom pci,.rom optionrom : vendor id : device id And Please provide the output of sh cbfstool coreboot.rom print .. [...@smitty5m cbfstool]$ ./cbfstool /home/joe/coreboot-v2/build/coreboot.rom print /home/joe/coreboot-v2/build/coreboot.rom: 1024 kB, bootblocksize 65536, romsize 1048576, offset 0x0 Alignment: 64 bytes Name Offset Type Size fallback/coreboot_ram 0x0stage32883 0x80c0 null 950008 [...@smitty5m cbfstool]$ I am using kconfig. Isn't kconfig supposed to add the vga rom to image? You have to enable CONFIG_VGA_BIOS, set CONFIG_FALLBACK_VGA_BIOS_ID to the right PCI ID and give the filename at CONFIG_FALLBACK_VGA_BIOS_FILE. Look under VGA BIOS in the top level menu. from my config.h #define CONFIG_VGA_BIOS 1 #define CONFIG_FALLBACK_VGA_BIOS_ID 8086,3577 #define CONFIG_FALLBACK_VGA_BIOS_FILE pci8086,3577.rom Still no go... -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] CBFS failed to load vga rom
Joseph Smith wrote: Look under VGA BIOS in the top level menu. from my config.h #define CONFIG_VGA_BIOS 1 #define CONFIG_FALLBACK_VGA_BIOS_ID 8086,3577 #define CONFIG_FALLBACK_VGA_BIOS_FILE pci8086,3577.rom Still no go... _BIOS_FILE should be the name of the VGA BIOS as it exists in the top level v2 directory. The CBFS name is generated from _BIOS_ID. Is your file called the same thing on disk as it should be in CBFS? Also try make distclean followedy by make menuconfig. If you still don't get build/coreboot.rom to have the VGA BIOS, please run make V=1 and send the last 20 or so lines to the list. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] CBFS failed to load vga rom
On 10/23/2009 12:45 AM, Peter Stuge wrote: Joseph Smith wrote: Look under VGA BIOS in the top level menu. from my config.h #define CONFIG_VGA_BIOS 1 #define CONFIG_FALLBACK_VGA_BIOS_ID 8086,3577 #define CONFIG_FALLBACK_VGA_BIOS_FILE pci8086,3577.rom Still no go... _BIOS_FILE should be the name of the VGA BIOS as it exists in the top level v2 directory. The CBFS name is generated from _BIOS_ID. Is your file called the same thing on disk as it should be in CBFS? Also try make distclean followedy by make menuconfig. If you still don't get build/coreboot.rom to have the VGA BIOS, please run make V=1 and send the last 20 or so lines to the list. #define CONFIG_VGA_BIOS 1 #define CONFIG_FALLBACK_VGA_BIOS_FILE vgabios.bin #define CONFIG_FALLBACK_VGA_BIOS_ID 8086,3577 Here are all the cbfs lines from the build, I don't see anything about the vga rom??? mkdir -p /home/joe/coreboot-v2/build/util/cbfstool printf HOSTCC util/cbfstool/common.o\n HOSTCC util/cbfstool/common.o gcc -DCOMPACT -g -I/home/joe/coreboot-v2/util/kconfig -I/home/joe/coreboot-v2/build/util/kconfig -g -c -o /home/joe/coreboot-v2/build/util/cbfstool/common.o /home/joe/coreboot-v2/util/cbfstool/common.c printf HOSTCC util/cbfstool/compress.o\n HOSTCC util/cbfstool/compress.o gcc -DCOMPACT -g -I/home/joe/coreboot-v2/util/kconfig -I/home/joe/coreboot-v2/build/util/kconfig -g -c -o /home/joe/coreboot-v2/build/util/cbfstool/compress.o /home/joe/coreboot-v2/util/cbfstool/compress.c printf HOSTCXXutil/cbfstool/minilzma.o\n HOSTCXXutil/cbfstool/minilzma.o g++ -DCOMPACT -g -I/home/joe/coreboot-v2/util/kconfig -I/home/joe/coreboot-v2/build/util/kconfig -c -o /home/joe/coreboot-v2/build/util/cbfstool/minilzma.o /home/joe/coreboot-v2/util/cbfstool/lzma/minilzma.cc printf HOSTCXXutil/cbfstool/LZMAEncoder.o\n HOSTCXXutil/cbfstool/LZMAEncoder.o g++ -DCOMPACT -g -I/home/joe/coreboot-v2/util/kconfig -I/home/joe/coreboot-v2/build/util/kconfig -c -o /home/joe/coreboot-v2/build/util/cbfstool/LZMAEncoder.o /home/joe/coreboot-v2/util/cbfstool/lzma/C/7zip/Compress/LZMA/LZMAEncoder.cpp printf HOSTCXXutil/cbfstool/LZInWindow.o\n HOSTCXXutil/cbfstool/LZInWindow.o g++ -DCOMPACT -g -I/home/joe/coreboot-v2/util/kconfig -I/home/joe/coreboot-v2/build/util/kconfig -c -o /home/joe/coreboot-v2/build/util/cbfstool/LZInWindow.o /home/joe/coreboot-v2/util/cbfstool/lzma/C/7zip/Compress/LZ/LZInWindow.cpp printf HOSTCXXutil/cbfstool/RangeCoderBit.o\n HOSTCXXutil/cbfstool/RangeCoderBit.o g++ -DCOMPACT -g -I/home/joe/coreboot-v2/util/kconfig -I/home/joe/coreboot-v2/build/util/kconfig -c -o /home/joe/coreboot-v2/build/util/cbfstool/RangeCoderBit.o /home/joe/coreboot-v2/util/cbfstool/lzma/C/7zip/Compress/RangeCoder/RangeCoderBit.cpp printf HOSTCXXutil/cbfstool/StreamUtils.o\n HOSTCXXutil/cbfstool/StreamUtils.o g++ -DCOMPACT -g -I/home/joe/coreboot-v2/util/kconfig -I/home/joe/coreboot-v2/build/util/kconfig -c -o /home/joe/coreboot-v2/build/util/cbfstool/StreamUtils.o /home/joe/coreboot-v2/util/cbfstool/lzma/C/7zip/Common/StreamUtils.cpp printf HOSTCXXutil/cbfstool/OutBuffer.o\n HOSTCXXutil/cbfstool/OutBuffer.o g++ -DCOMPACT -g -I/home/joe/coreboot-v2/util/kconfig -I/home/joe/coreboot-v2/build/util/kconfig -c -o /home/joe/coreboot-v2/build/util/cbfstool/OutBuffer.o /home/joe/coreboot-v2/util/cbfstool/lzma/C/7zip/Common/OutBuffer.cpp printf HOSTCXXutil/cbfstool/Alloc.o\n HOSTCXXutil/cbfstool/Alloc.o g++ -DCOMPACT -g -I/home/joe/coreboot-v2/util/kconfig -I/home/joe/coreboot-v2/build/util/kconfig -c -o /home/joe/coreboot-v2/build/util/cbfstool/Alloc.o /home/joe/coreboot-v2/util/cbfstool/lzma/C/Common/Alloc.cpp printf HOSTCXXutil/cbfstool/CRC.o\n HOSTCXXutil/cbfstool/CRC.o g++ -DCOMPACT -g -I/home/joe/coreboot-v2/util/kconfig -I/home/joe/coreboot-v2/build/util/kconfig -c -o /home/joe/coreboot-v2/build/util/cbfstool/CRC.o /home/joe/coreboot-v2/util/cbfstool/lzma/C/Common/CRC.cpp printf HOSTCC util/cbfstool/cbfs-mkstage.o\n HOSTCC util/cbfstool/cbfs-mkstage.o gcc -DCOMPACT -g -I/home/joe/coreboot-v2/util/kconfig -I/home/joe/coreboot-v2/build/util/kconfig -g -c -o /home/joe/coreboot-v2/build/util/cbfstool/cbfs-mkstage.o /home/joe/coreboot-v2/util/cbfstool/cbfs-mkstage.c printf HOSTCC util/cbfstool/cbfs-mkpayload.o\n HOSTCC util/cbfstool/cbfs-mkpayload.o gcc -DCOMPACT -g -I/home/joe/coreboot-v2/util/kconfig -I/home/joe/coreboot-v2/build/util/kconfig -g -c -o /home/joe/coreboot-v2/build/util/cbfstool/cbfs-mkpayload.o /home/joe/coreboot-v2/util/cbfstool/cbfs-mkpayload.c printf HOSTCC util/cbfstool/cbfstool.o\n HOSTCC util/cbfstool/cbfstool.o gcc -DCOMPACT -g -I/home/joe/coreboot-v2/util/kconfig -I/home/joe/coreboot-v2/build/util/kconfig -g -c -o /home/joe/coreboot-v2/build/util/cbfstool/cbfstool.o
