Re: [coreboot] [PATCH]make emulation/qemu-x86 slightly more standard
On 1/10/10 10:48 PM, Patrick Georgi wrote: attached patch makes qemu use the udelay function in src/pc80/udelay_io.c instead of the equivalent copy in src/cpu/emulation/qemu-x86/northbridge.c. Similar changes can be done for AMD boards (just with UDELAY_LAPIC), I think. Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5006 - in trunk/src: cpu/emulation/qemu-x86 mainboard/emulation/qemu-x86
Author: oxygene
Date: 2010-01-11 10:05:52 +0100 (Mon, 11 Jan 2010)
New Revision: 5006
Modified:
trunk/src/cpu/emulation/qemu-x86/northbridge.c
trunk/src/mainboard/emulation/qemu-x86/Kconfig
trunk/src/mainboard/emulation/qemu-x86/Options.lb
Log:
Make qemu use the udelay function in src/pc80/udelay_io.c
instead of the equivalent copy in src/cpu/emulation/qemu-x86/northbridge.c.
Also, delete the copy.
Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de
Acked-by: Stefan Reinauer ste...@coresystems.de
Modified: trunk/src/cpu/emulation/qemu-x86/northbridge.c
===
--- trunk/src/cpu/emulation/qemu-x86/northbridge.c 2010-01-08 11:26:02 UTC
(rev 5005)
+++ trunk/src/cpu/emulation/qemu-x86/northbridge.c 2010-01-11 09:05:52 UTC
(rev 5006)
@@ -157,12 +157,3 @@
CHIP_NAME(QEMU Northbridge)
.enable_dev = enable_dev,
};
-
-void udelay(unsigned usecs)
-{
- unsigned i;
- for(i = 0; i usecs; i++)
- inb(0x80);
-}
-
-
Modified: trunk/src/mainboard/emulation/qemu-x86/Kconfig
===
--- trunk/src/mainboard/emulation/qemu-x86/Kconfig 2010-01-08 11:26:02 UTC
(rev 5005)
+++ trunk/src/mainboard/emulation/qemu-x86/Kconfig 2010-01-11 09:05:52 UTC
(rev 5006)
@@ -22,13 +22,3 @@
int
default 6
depends on BOARD_EMULATION_QEMU_X86
-
-config HAVE_INIT_TIMER
- bool
- default n
- depends on BOARD_EMULATION_QEMU_X86
-
-config UDELAY_IO
- bool
- default n
- depends on BOARD_EMULATION_QEMU_X86
Modified: trunk/src/mainboard/emulation/qemu-x86/Options.lb
===
--- trunk/src/mainboard/emulation/qemu-x86/Options.lb 2010-01-08 11:26:02 UTC
(rev 5005)
+++ trunk/src/mainboard/emulation/qemu-x86/Options.lb 2010-01-11 09:05:52 UTC
(rev 5006)
@@ -47,6 +47,8 @@
uses CONFIG_DEFAULT_CONSOLE_LOGLEVEL
uses CONFIG_MAXIMUM_CONSOLE_LOGLEVEL
+uses CONFIG_UDELAY_IO
+default CONFIG_UDELAY_IO=1
default CONFIG_CONSOLE_SERIAL8250=1
default CONFIG_DEFAULT_CONSOLE_LOGLEVEL=8
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8QME-2+ IRQ assignment and AMD 8132
Knut Kujat escribió: Hello, over this week I've tried to do a proper IRQ assignment on the H8QME-2+ I've got here. So opened mp_tables.c and started changing the irq routing values with those I got form the board booting with a factory bios. Then I started giving the devices the irq they have when boot with factory bios and it booted without any problems except for two things first of all the two NICs still have irq 0 and thats because they are not pending on the mcp55 as they are on the donator board but on a AMD 8132 tunnel devices that is hanging on a different node: socketF(node3) --- socketF(node2) || socketF(node1) --- socketF(node0) || |ht |ht || AMD8132MCP55 |-- LAN| |-- SCSI |-- SATA |-- ATI ES 1000 |-- USB |-- PCI | lpc SIO I started adding the AMD8132 to the get_bus_conf.c code, by adding I mean stealing code from other boards pasting it to get_bus_conf and trying to make it work ;). So the problem there is that coreboot won't boot with the new code but not because the code is incorrect because it wasn't even executed, I know that because coreboot soft resets in middle of cpu initialization. I already increased Stack size up to 0x1 more makes the boot sequence fail. My second problem is the, irq_tables.c code I tried to customize for this board. I first tried the handy tool that comes with coreboot that auto-generates the irq_tables.c file but it doesn't compile with my board but I at least was able to use the information to modify the already existing irq_tables.c. So before doing changes the dump_irq output look like that: Interrupt routing table found at address 0xf55bb: Version 106.117, size 0x8366 Interrupt router is device 3d:17.4 PCI exclusive interrupt mask: 0x0fde [1,2,3,4,6,7,8,9,10,11] Compatible router: vendor 0x device 0x6075 Device d2:00.2 (slot 106): INTA: link 0x54, irq mask 0x0005 [0,2] INTB: link 0x40, irq mask 0xc839 [0,3,4,5,11,14,15] INTC: link 0x72, irq mask 0x84f7 [0,1,2,4,5,6,7,10,15] INTD: link 0xd2, irq mask 0x4275 [0,2,4,5,6,9,14] Device 83:19.2 (slot 195): INTA: link 0xff, irq mask 0x74b8 [3,4,5,7,10,12,13,14] INTB: link 0x74, irq mask 0x000f [0,1,2,3] INTC: link 0xe8, irq mask 0x9f77 [0,1,2,4,5,6,8,9,10,11,12,15] INTD: link 0xff, irq mask 0x89ff [0,1,2,3,4,5,6,7,8,11,15] Interrupt router at 3d:17.4: Could not read router info from /proc/bus/pci/3d/17.4. and after compiling with the new irq_tables.c I've got the exact same output! So no changes were applied, I cleaned everything before compiling so no doubt I compiled the correct file. So why is it still the same? (I attached a dump_irq output from the board with factory bios). And last but not least, at linux bootup it complains to find only 2 cpus but 16 cores later doing a lspci I can see all 4 cpus (18.0, 19,0 1a.0, 1b.0) and Linux only recognizes 8GB of ram but there are 16GB installed! Thanks in advanced and have a nice weekend, Knut Kujat. Hello, I fixed the 2 cpu and just 8 GB ram issues, now linux finds all 4 cpus and 16 GB. But I'm still having trouble adding AMD 8132 for giving the NICs IRQ. THX, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] When should we retire newconfig?
On January 9, 2010 at 9:11 PM Myles Watson myle...@gmail.com wrote: -Original Message- Am 09.01.2010 13:29, schrieb j...@settoplinux.org: Yes you can add Thomson IP1000 and RCA RM4100 to the list. They build fine with Kconfig. Have you boot tested them yet? I tried them about a month ago (begining of December) and they were booting fine with filo. Unless something drastic has changed since then??? Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
2010/1/8 Patrick Georgi patr...@georgi-clan.de: In that case, your ROM is probably not entirely mapped yet. That's an issue that has to be fixed per chipset (southbridge mostly). I see explicit support for it in cs5530 (even though that _might_ require some more changes), and somewhere in the code of cs5535. I don't know if this is applicable to cs5536, too. If you want to try, this hack might help you (untested, as I don't have the hardware). Maybe the call must be moved around a bit. Unfortunately it didn't help. When I use cs5530_enable_rom() function, the booting process didn't event execute cbfs_load_stage(). Please note that the src/mainboard/digitallogic/msm800sev/auto.c file is not in compilation chain - against it the coreboot/src/mainboard/digitallogic/msm800sev/cache_as_ram_auto.c is used. Maybe it has to be fixed? I've found that the booting process hangs on this part of cbfs_master_header() function (src/lib/cbfs.c): ... outb(0xa1, 0x80); // --- It is printed void *ptr = (void *)*((unsigned long *) CBFS_HEADPTR_ADDR); printk_spew(Check CBFS header at %p\n, ptr); header = (struct cbfs_header *) ptr; outb(0xa2, 0x80); // - It is NOT printed ... I don't know exactly where I need to begin make changes ... Thanks for your interest. -- Piotr Piwko http://www.embedded-engineering.pl/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Future coreboot phases?
On January 10, 2010 at 7:31 AM ron minnich rminn...@gmail.com wrote: great idea, we need it. I think it ought to be a .tex file. But this is a good start, needs to be in svn yes and a wiki page please?? Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Future coreboot phases?
Rudolf Marek wrote: The DQS values are stored in chipset S3 NVRAM during first boot, and used later when resume to fill them in. It could be done via simple backup of all mem cntrl regs but it is not done so. I think this is a brilliant idea for improvement - it would also reduce the resume time ever so slightly. Either a structure for the chipset-specific registers that are needed, filled and saved at first boot and reused on resume - or a super simple blob copy of all registers. (If there's enough space?) //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Future coreboot phases?
Am 11.01.2010 14:42, schrieb Peter Stuge: I don't think svn or wiki matters. .tex is nice because you can easily make .pdf and print. Ron has inspired me to use Lyx. :) markdown can be transformed to tex for those that want it (and thus to pdf), but it's still editable with a simple text editor (unlike lyx files, or tex files of reasonable complexity). Lyx for windows is basically non-existant, for example. I think it's more important to save it than to have the righttm format. I think a wiki page would be fine. Right, and as said, one or the other please. So wiki it is? Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Test : printing current time in serial debug
Hello, I want to display the current date and time inside functions like add_mainboard_resources, suspend_resume or to find the elapsed time between the end of coreboot and the end of the payload for example. I search how to get the current time from protected mode in coreboot. Since there is no library, I think the only way is to call real mode int 1ah from protected mode, but I can't find any example. Is it the only way ? If someone can help me or gives me the source to implement this feature. Thanks in advance for your help. Bonne année ! Adressez gratuitement vos voeux avec Voila.fr sur http://carte-de-voeux.voila.fr -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Test : printing current time in serial debug
conged...@voila.fr wrote: I want to display the current date and time inside functions like add_mainboard_resources, suspend_resume or to find the elapsed time between the end of coreboot and the end of the payload for example. I suggest to do this is by passive measurement outside the running code, e.g. by timestamping messages on the serial port or by timing edges or data on a signal or bus which is accessible throughout the execution of coreboot and the rest of the system. Kevin O'Connor has written a script for serial port timestamping which is available in the SeaBIOS repository. It also does accounting for the serial port output overhead in coreboot, which is nice. I search how to get the current time from protected mode in coreboot. Since there is no library, I think the only way is to call real mode int 1ah from protected mode, but I can't find any example. Is it the only way ? There are no BIOS interrupt services available in coreboot. If you need them, you can use coreboot with a SeaBIOS payload, but it will not help during execution of coreboot itself. If someone can help me or gives me the source to implement this feature. Basically you have to rely on what the hardware provides you. There are several different timer peripherals in a modern x86 system and which one you should use depends on lots of parameters (resolution and maximum primarily, but also the cost of using the timers) for the times that you want to measure, if you choose to do it internally in the coreboot code. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Future coreboot phases?
On January 11, 2010 at 1:52 PM Patrick Georgi patr...@georgi-clan.de wrote: Am 11.01.2010 14:42, schrieb Peter Stuge: I don't think svn or wiki matters. .tex is nice because you can easily make .pdf and print. Ron has inspired me to use Lyx. :) markdown can be transformed to tex for those that want it (and thus to pdf), but it's still editable with a simple text editor (unlike lyx files, or tex files of reasonable complexity). Lyx for windows is basically non-existant, for example. I think it's more important to save it than to have the righttm format. I think a wiki page would be fine. Right, and as said, one or the other please. So wiki it is? My vote is for wiki... Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Test : printing current time in serial debug
On January 11, 2010 at 2:24 PM Peter Stuge pe...@stuge.se wrote: conged...@voila.fr wrote: I want to display the current date and time inside functions like add_mainboard_resources, suspend_resume or to find the elapsed time between the end of coreboot and the end of the payload for example. I suggest to do this is by passive measurement outside the running code, e.g. by timestamping messages on the serial port or by timing edges or data on a signal or bus which is accessible throughout the execution of coreboot and the rest of the system. Kevin O'Connor has written a script for serial port timestamping which is available in the SeaBIOS repository. It also does accounting for the serial port output overhead in coreboot, which is nice. I search how to get the current time from protected mode in coreboot. Since there is no library, I think the only way is to call real mode int 1ah from protected mode, but I can't find any example. Is it the only way ? There are no BIOS interrupt services available in coreboot. If you need them, you can use coreboot with a SeaBIOS payload, but it will not help during execution of coreboot itself. If someone can help me or gives me the source to implement this feature. Basically you have to rely on what the hardware provides you. There are several different timer peripherals in a modern x86 system and which one you should use depends on lots of parameters (resolution and maximum primarily, but also the cost of using the timers) for the times that you want to measure, if you choose to do it internally in the coreboot code. If you have an Intel chipset, I have meade some recent discoveries (thanks to serialice) that the ICH southbridges actually have a timer built into the power management registers. You could always do a read of this register at the starting point and another read of this register at the ending point to calculate load time if that is what you are looking for(some vender bios's use this method to calulate memory timing). Hope that helps. Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
Piotr Piwko wrote: I've found that the booting process hangs on this part of cbfs_master_header() function (src/lib/cbfs.c): ... outb(0xa1, 0x80); // --- It is printed void *ptr = (void *)*((unsigned long *) CBFS_HEADPTR_ADDR); printk_spew(Check CBFS header at %p\n, ptr); header = (struct cbfs_header *) ptr; outb(0xa2, 0x80); // - It is NOT printed ... I don't know exactly where I need to begin make changes ... Do you see the printk message? Could you also add outb() before and after the printk? If it hangs on the printk call I guess it's a stack issue. Did you already try the v3 support for adl/msm800sev? //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
On Mon, Jan 11, 2010 at 2:24 PM, Peter Stuge pe...@stuge.se wrote: Did you already try the v3 support for adl/msm800sev? yes, try this first. See if it goes. Then you'll need to match up what v3 does with what v2 does, and if you get it fixed, I will thank you A LOT. Would be nice to have the msm800 working in v2 :-) ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] When should we retire newconfig?
Patrick Georgi wrote: 4. Implement it like in southbridge/amd/amd8111: 4a. Add a new file (I recommend southbridge/$vendor/$device/bootblock.c) with a static void bootblock_southbridge_init(void) function that enables rom mapping 4b. Set BOOTBLOCK_SOUTHBRIDGE_INIT to point to the file Please can some of these be renamed? map_rom.c (or map_full_rom.c or possibly enable_rom_decode.c) southbridge_map_rom() (or similar per filename above) My reasoning is that the build system is a great place to describe _when_ files are used, but code and filenames need only say _what_ they do - if there is one single convention. I think 4b. should be made general. I don't know if I prefer always including the file and having an empty function, or allowing the file to be included only for southbridges where it actually exists. Empty functions really suck; source code noise. Automagic build rules do too; rename a file and get a runtime error instead of a buildtime error. I have to go with the lesser evil; the empty function. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [bios_extract] filenames patch for phoenix
Matthias Wenzel wrote:
+++ b/phoenix.c
..
@@ -117,10 +117,10 @@ PhoenixModule(unsigned char *BIOSImage, int BIOSLength,
int Offset)
ModuleName = PhoenixModuleNameGet(Module-Type);
if (ModuleName) {
- filename = malloc(strlen(ModuleName) + 7);
+ filename = malloc(strlen(ModuleName) + 7 + 3);
sprintf(filename, %s_%1d.rom, ModuleName, Module-Id);
} else {
- filename = malloc(9);
+ filename = malloc(9 + 3);
sprintf(filename, %02X_%1d.rom, Module-Type, Module-Id);
}
If everything (also Type) is u8 then the above is 1 byte extra :) but
better safe than sorry!
If anything is larger than u8 then the above needs some more bytes.
//Peter
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8QME-2+ IRQ assignment and AMD 8132
Knut Kujat wrote: I fixed the 2 cpu and just 8 GB ram issues, How? //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Integrated graphics controller on second bus?
Andrej Skirn wrote: I don't see any mention of needing SeaBios to get the VGA working on the Wiki, although Peter Stuge suggested it. It depends on the VGA BIOS. Some of them rely on more BIOS interrupt services being available, some work with less services. coreboot tries to provide some few interrupt services to please the VGA BIOS but it is in no way a substitute for what SeaBIOS provides. If you have native code for initializing graphics in coreboot (currently only for the Chrome on K8M890 IIRC) then neither VGA BIOS nor other BIOS interrupt service junk is needed - and native code typically runs much faster because it does much less. This poses a problem though, since I'd like to have the screen working as early as possible, How long time do you have before SeaBIOS runs the VGA BIOS? With some optimizations, Kevin got this time down to roughly 500ms. Is that too long? (200 of these were the VGA BIOS itself.) and I'm not certain it's a good idea to initialize it twice in any case. Back in the day I used to do a real mode call from DOS programs to c000:0003 which would basically re-run the VGA BIOS unless it had self-modified during the first run. This always worked very reliably and I expect it will still. I don't normally do that as it confuses my USB serial-adapter and just do a PCI reset instead, I strongly recommend against this. Instead please make sure to always power cycle, in order to always start with a clean state. It's even good to leave power off for a while, ideally lots of seconds, to make sure there's no charge left in power rail capacitors or RAM. but then SeaBios hangs in do_boot, after printing B of Booting from. Without VGA BIOS it gets past this point and starts loading the OS. (Without display I can't tell exactly how successful it is at this, though). Can you try to use the serial output to get more debug information? Another data point might be to use Google's SGABIOS, it's a VGA BIOS with a serial port backend. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [bios_extract] filenames patch for phoenix
Peter Stuge wrote:
Matthias Wenzel wrote:
+++ b/phoenix.c
..
@@ -117,10 +117,10 @@ PhoenixModule(unsigned char *BIOSImage, int
BIOSLength, int Offset)
ModuleName = PhoenixModuleNameGet(Module-Type);
if (ModuleName) {
-filename = malloc(strlen(ModuleName) + 7);
+filename = malloc(strlen(ModuleName) + 7 + 3);
sprintf(filename, %s_%1d.rom, ModuleName, Module-Id);
} else {
-filename = malloc(9);
+filename = malloc(9 + 3);
sprintf(filename, %02X_%1d.rom, Module-Type, Module-Id);
}
If everything (also Type) is u8 then the above is 1 byte extra :) but
better safe than sorry!
Both are u8, and yes, I was conservative as some C-libs (other than
glibc) might add a sign with the %1d. Maybe we should write %1u or
even %.3 to be clearer.
mazzoo
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
