Hi All,
I'm very new to coreboot. I'm trying to boot my old hp eVectra with coreboot (because my old bios don't support VIA c3 processor)
It took me some time to understand why my onboard VGA card don't starts, but now it works :-)
Now I have a new problem. My linux distribution boots very slow (approximately 30 minutes - to the login prompt). I found this mail: [PATCH] Initial support for the MSI MS-6178 (i810-based)http://news.gmane.org/find-root.php?message_id=%3c20070831091956.GA9039%40greenwood%3e From: Uwe Hermann with the same problem but I could not find the solution in the mailing thread.
can someone help me
ps. Sorry for my bad English
Hi,
On Wed, Oct 14, 2009 at 11:38:44PM +0200, Paweł Stawicki wrote:
I'm very new to coreboot. I'm trying to boot my old hp eVectra with coreboot (because my old bios don't support VIA c3 processor)
It took me some time to understand why my onboard VGA card don't starts, but now it works :-)
Now I have a new problem. My linux distribution boots very slow (approximately 30 minutes - to the login prompt). I found this mail: [PATCH] Initial support for the MSI MS-6178 (i810-based)http://news.gmane.org/find-root.php?message_id=%3c20070831091956.GA9039%40greenwood%3e From: Uwe Hermann with the same problem but I could not find the solution in the mailing thread.
Do you already run coreboot on the board? Or do you want to add support?
Either way, please send the following information so we can support it:
* lspci -tvnn * superiotool -dV * getpir output (a file named irq_table.c) * mptable output
You can get the utilities via:
svn co svn://coreboot.org/repos/trunk/util
Thanks, Uwe.
I already run coreboot on my system. The problem is that my linux started from coreboot i very slow (comparing to the original BIOS)
I have no idea where might be the problem.
I'm attaching the irq_tables.c and output.txt you requested. (all generated with the original BIOS)
the superio is a NSC PC87364 but coreboot works with your PC87360 implementation. it is a uniprocessor PIII platform.
I tried to boot the system with a: Pentium 3 733MHz, and Celeron 400MHz
the coreboot booted linux works slow with both processors.
Best regards. Paweł Stawicki
2009/10/18 Uwe Hermann uwe@hermann-uwe.de
Hi,
On Wed, Oct 14, 2009 at 11:38:44PM +0200, Paweł Stawicki wrote:
I'm very new to coreboot. I'm trying to boot my old hp eVectra with coreboot (because my old bios don't support VIA c3 processor)
It took me some time to understand why my onboard VGA card don't starts, but now it works :-)
Now I have a new problem. My linux distribution boots very slow (approximately 30 minutes - to the login prompt). I found this mail: [PATCH] Initial support for the MSI MS-6178 (i810-based)<
http://news.gmane.org/find-root.php?message_id=%3c20070831091956.GA9039%40gr...
From: Uwe Hermann with the same problem but I could not find the solution in the mailing thread.
Do you already run coreboot on the board? Or do you want to add support?
Either way, please send the following information so we can support it:
- lspci -tvnn
- superiotool -dV
- getpir output (a file named irq_table.c)
- mptable output
You can get the utilities via:
svn co svn://coreboot.org/repos/trunk/util
Thanks, Uwe.
http://www.hermann-uwe.de | http://www.randomprojects.org http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
On Sun, Oct 18, 2009 at 12:46:40PM +0200, Paweł Stawicki wrote:
I already run coreboot on my system.
OK, let's first add a proper target for the board then (patch attached). We can then improve the code as needed.
Please reply with Acked-by: Paweł Stawicki stawel@gmail.com if it builds and boots on your hardware.
The problem is that my linux started from coreboot i very slow (comparing to the original BIOS)
Could be missing cache initialization for the CPU, not sure. We don't yet enable cache on all CPUs (it's on our TODO list though).
Uwe.
Acked-by: Paweł Stawicki stawel@gmail.com
the patch is working correct. My linux distribution boots very fast :) the only problem is that the vga bios is not booting. I'm trying investigate.
2009/10/19 Uwe Hermann uwe@hermann-uwe.de
On Sun, Oct 18, 2009 at 12:46:40PM +0200, Paweł Stawicki wrote:
I already run coreboot on my system.
OK, let's first add a proper target for the board then (patch attached). We can then improve the code as needed.
Please reply with Acked-by: Paweł Stawicki stawel@gmail.com if it builds and boots on your hardware.
The problem is that my linux started from coreboot i very slow (comparing to the original BIOS)
Could be missing cache initialization for the CPU, not sure. We don't yet enable cache on all CPUs (it's on our TODO list though).
Uwe.
http://www.hermann-uwe.de | http://www.randomprojects.org http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
I was able to turn on the vga bios with some little changes:
I added the following lines to the files: file: coreboot-v2/targets/hp/e_vectra_p2706t/Config.lb #vga bios pci_rom /tmp/vgabios.rom vendor_id=0x8086 device_id=0x7125 #ethernet bios #pci_rom /tmp/ethbios.rom vendor_id=0x10b7 device_id=0x9200
file: coreboot-v2/src/mainboard/hp/e_vectra_p2706t/Options.lb uses CONFIG_VGA_ROM_RUN default CONFIG_VGA_ROM_RUN = 1
sorry for this format but the patch not commited, and it if difficult to me to create a diff.
the vga bios was generated with: $ amideco In0203.rom -x $ cp amipci_00.20 /tmp/vgabios.rom
where: In0203.rom is a original BIOS file from hp sites
still, acpi is not working, i try to find the reason tomorrow.
Paweł
W dniu 20 października 2009 23:34 użytkownik Paweł Stawicki < stawel@gmail.com> napisał:
Acked-by: Paweł Stawicki stawel@gmail.com
the patch is working correct. My linux distribution boots very fast :) the only problem is that the vga bios is not booting. I'm trying investigate.
2009/10/19 Uwe Hermann uwe@hermann-uwe.de
On Sun, Oct 18, 2009 at 12:46:40PM +0200, Paweł Stawicki wrote:
I already run coreboot on my system.
OK, let's first add a proper target for the board then (patch attached). We can then improve the code as needed.
Please reply with Acked-by: Paweł Stawicki stawel@gmail.com if it builds and boots on your hardware.
The problem is that my linux started from coreboot i very slow (comparing to the original BIOS)
Could be missing cache initialization for the CPU, not sure. We don't yet enable cache on all CPUs (it's on our TODO list though).
Uwe.
http://www.hermann-uwe.de | http://www.randomprojects.org http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
On Wed, Oct 21, 2009 at 12:56:00AM +0200, Paweł Stawicki wrote:
I was able to turn on the vga bios with some little changes:
I added the following lines to the files: file: coreboot-v2/targets/hp/e_vectra_p2706t/Config.lb #vga bios pci_rom /tmp/vgabios.rom vendor_id=0x8086 device_id=0x7125 #ethernet bios #pci_rom /tmp/ethbios.rom vendor_id=0x10b7 device_id=0x9200
file: coreboot-v2/src/mainboard/hp/e_vectra_p2706t/Options.lb uses CONFIG_VGA_ROM_RUN default CONFIG_VGA_ROM_RUN = 1
Thanks, added to svn (the pci_rom lines are comments only, you have to enable them).
still, acpi is not working, i try to find the reason tomorrow.
Oh, this is easy. There is no ACPI implementation for this board in coreboot.
Uwe.
On Tue, Oct 20, 2009 at 11:34:16PM +0200, Paweł Stawicki wrote:
Acked-by: Paweł Stawicki stawel@gmail.com the patch is working correct.
Thanks, r4820.
My linux distribution boots very fast :) the only problem is that the vga bios is not booting. I'm trying investigate.
As this is onboard VGA (not a PCI plugin-card) I assume, you need to add the VGA BIOS image to coreboot.rom.
This can be done by adding a line like this to targets/.../Config.lb:
pci_rom /tmp/vga.bin vendor_id=0x8086 device_id=0x27a2
(in kconfig it's a bit simpler, but I'm not sure if your board works fine with kconfig already)
You need to adapt the vga.bin path/filename, and the PCI vendor/device ID (you can do a test-boot and coreboot will tell you which ID it tries to find on the serial console).
You can get vga.bin (filename may differ) using the phnxdeco, amideco, awardeco, or bios_extract utilities.
For PCI graphics cards it's simpler, they should usually work out of the box, but let us know if that's not the case.
I'll make a superiotool patch for your Super I/O so we can dump the register contents and fix the Super I/O setup a bit.
Can you tell us how big the ROM chip is in the board (so we can fix the default Kconfig file)? Also, if you have some time to test all available hardware components with coreboot let us know the results. It would be nice if we could make a wiki status page for your board, such as this one for example:
http://www.coreboot.org/MSI_MS-6178
Uwe.
2009/10/21 Uwe Hermann uwe@hermann-uwe.de
On Tue, Oct 20, 2009 at 11:34:16PM +0200, Paweł Stawicki wrote:
Acked-by: Paweł Stawicki stawel@gmail.com the patch is working correct.
Thanks, r4820.
My linux distribution boots very fast :) the only problem is that the vga bios is not booting. I'm trying investigate.
As this is onboard VGA (not a PCI plugin-card) I assume, you need to add the VGA BIOS image to coreboot.rom.
This can be done by adding a line like this to targets/.../Config.lb:
pci_rom /tmp/vga.bin vendor_id=0x8086 device_id=0x27a2
yes i added this line and it seems that i need also add: uses CONFIG_VGA_ROM_RUN default CONFIG_VGA_ROM_RUN = 1 to the Options.lb file, without this it doesn't work. I needed also this patch: http://www.coreboot.org/pipermail/coreboot/2009-July/050497.html
The console is turning on when the linux is starting (not at the FILO start)
(in kconfig it's a bit simpler, but I'm not sure if your board works fine with kconfig already)
You need to adapt the vga.bin path/filename, and the PCI vendor/device ID (you can do a test-boot and coreboot will tell you which ID it tries to find on the serial console).
You can get vga.bin (filename may differ) using the phnxdeco, amideco, awardeco, or bios_extract utilities.
For PCI graphics cards it's simpler, they should usually work out of the box, but let us know if that's not the case.
the e-Vectra has no additional slots on board , therefor it has only an onboard vga card.
I'll make a superiotool patch for your Super I/O so we can dump the register contents and fix the Super I/O setup a bit.
sounds great.
Can you tell us how big the ROM chip is in the board (so we can fix the default Kconfig file)b?
the bios size is 512KB - really :-) the vga bios size is 32KB it has also an ethernet bios inside the bios (size 58880B)
Also, if you have some time to test all available hardware components with coreboot let us know the results. It would be nice if we could make a wiki status page for your board, such as this one for example:
ok, I will try to make the tests tomorrow.
Uwe.
http://www.hermann-uwe.de | http://www.randomprojects.org http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
Thanks a lot. Paweł
2009/10/21 Uwe Hermann uwe@hermann-uwe.de
Also, if you have some time to test all available hardware components with coreboot let us know the results. It would be nice if we could make a wiki status page for your board, such as this one for example:
I have tested some (which I know how) hardware components, if you need some more, tell me how, and I make the tests.
I'm attaching the results.
I have tested the board with 3 CPUs, and 2 RAMs. the summary are in the summary.txt file.
it seems that my Via C3 processor is not working correct. I'll try to find why. (it hasn't worked with my original BIOS, too)
bests regards Paweł Stawicki
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 ?
Paweł Stawicki wrote:
I was able run my VIA c3 processor :-)
Nice.
but how to turn on intel processors AND via C3 processors ?
This is the first time it has been done.
The code does not really support more than one CPU "type" at a time. It would be nice to improve this because the AM2 mainboards can use both k8 and fam10, but it's not being worked on.
//Peter
On 22.10.2009 03:50, Peter Stuge wrote:
Paweł Stawicki wrote:
but how to turn on intel processors AND via C3 processors ?
This is the first time it has been done.
The code does not really support more than one CPU "type" at a time. It would be nice to improve this because the AM2 mainboards can use both k8 and fam10, but it's not being worked on.
CAR code for K8/Fam10 autodetects the CPU and issues the right commands based on autodetection.
Regards, Carl-Daniel
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..
//Peter
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
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
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
2009/10/22 Stefan Reinauer stepan@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ł
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
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.