[coreboot] [PATCH] some more CONFIG_ prefixes
Hi,
attached patch renames some preprocessor symbols. I have no idea why
those symbols were left alone before, after this, they're somewhat more
in line with the rest of the tree.
Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de
Index: src/southbridge/intel/esb6300/esb6300_lpc.c
===
--- src/southbridge/intel/esb6300/esb6300_lpc.c (revision 4441)
+++ src/southbridge/intel/esb6300/esb6300_lpc.c (working copy)
@@ -18,8 +18,8 @@
#define MAINBOARD_POWER_OFF 0
#define MAINBOARD_POWER_ON 1
-#ifndef MAINBOARD_POWER_ON_AFTER_FAIL
-#define MAINBOARD_POWER_ON_AFTER_FAIL MAINBOARD_POWER_ON
+#ifndef CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL
+#define CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL MAINBOARD_POWER_ON
#endif
#define ALL(0xff 24)
@@ -277,7 +277,7 @@
{
uint8_t byte;
uint32_t value;
- int pwr_on=MAINBOARD_POWER_ON_AFTER_FAIL;
+ int pwr_on=CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL;
/* sata settings */
pci_write_config32(dev, 0x58, 0x1181);
Index: src/southbridge/intel/i82801gx/i82801gx_lpc.c
===
--- src/southbridge/intel/i82801gx/i82801gx_lpc.c (revision 4441)
+++ src/southbridge/intel/i82801gx/i82801gx_lpc.c (working copy)
@@ -33,8 +33,8 @@
#define MAINBOARD_POWER_OFF 0
#define MAINBOARD_POWER_ON 1
-#ifndef MAINBOARD_POWER_ON_AFTER_FAIL
-#define MAINBOARD_POWER_ON_AFTER_FAIL MAINBOARD_POWER_ON
+#ifndef CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL
+#define CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL MAINBOARD_POWER_ON
#endif
#define NMI_OFF 0
Index: src/include/x86emu/fpu_regs.h
===
--- src/include/x86emu/fpu_regs.h (revision 4441)
+++ src/include/x86emu/fpu_regs.h (working copy)
@@ -40,7 +40,7 @@
#define __X86EMU_FPU_REGS_H
-#if defined(CONFIG_DEBUG) (DEBUG == 0)
+#if defined(CONFIG_DEBUG) (CONFIG_DEBUG == 0)
#undef CONFIG_DEBUG
#endif
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] some more CONFIG_ prefixes
attached patch renames some preprocessor symbols. I have no idea why those symbols were left alone before, after this, they're somewhat more in line with the rest of the tree. @@ -18,8 +18,8 @@ #define MAINBOARD_POWER_OFF 0 #define MAINBOARD_POWER_ON 1 -#ifndef MAINBOARD_POWER_ON_AFTER_FAIL -#define MAINBOARD_POWER_ON_AFTER_FAIL MAINBOARD_POWER_ON +#ifndef CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL +#define CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL MAINBOARD_POWER_ON #endif Since they're #ifndef, that means they weren't part of the old config system, or there is a bug. Those symbols are always defined, and are tested based on their values. Is there a uses statement for them somewhere? Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] non static 0x1000 IO space can be broken
-Original Message- From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On Behalf Of Rudolf Marek Sent: Sunday, July 19, 2009 1:49 PM To: Kevin O'Connor Cc: Coreboot Subject: Re: [coreboot] non static 0x1000 IO space can be broken resources. Maybe we should just add a generic resource for everything under 0x1000? That's the way the rest of the boards did it. I'm sorry I missed this southbridge. I thought I got them all. The resource allocator will only care about the last I/O resource that you add, because it doesn't split allocations. So if you add 5 resources all under 0x1000 with the last one ending at 0x1000, or 1 resource 0x0-0x1000, it will have the same effect. I noticed in your patch that you're setting the limit = base+size-1. The limit is not the same as the end of the resource. For most I/O, the limit should be 0x. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] non static 0x1000 IO space can be broken
Hi Myles, That's the way the rest of the boards did it. I'm sorry I missed this southbridge. I thought I got them all. Ok. Please prepare the patch. The resource allocator will only care about the last I/O resource that you add, because it doesn't split allocations. So if you add 5 resources all under 0x1000 with the last one ending at 0x1000, or 1 resource 0x0-0x1000, it will have the same effect. ok. I noticed in your patch that you're setting the limit = base+size-1. The limit is not the same as the end of the resource. For most I/O, the limit should be 0x. aha true. This was cut and paste from k8t890 where it was used to setup APIC resource. For mem resource it should be how? I don't understand the gran too. For this SB (the VT8237S) we will definitely need to dynamically allocate a mmio BAR for SPI controller. I will prepare a patch, but cannot test. I would like to ask if you care about the decoding range for flashes - if I need some other resource for that and also about 0xfee... for MSI. Rudolf -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] non static 0x1000 IO space can be broken
On Mon, Jul 20, 2009 at 8:14 AM, Rudolf Marek r.ma...@assembler.cz wrote: Hi Myles, That's the way the rest of the boards did it. I'm sorry I missed this southbridge. I thought I got them all. Ok. Please prepare the patch. Attached. Signed-off-by: Myles Watson myle...@gmail.com I noticed in your patch that you're setting the limit = base+size-1. The limit is not the same as the end of the resource. For most I/O, the limit should be 0x. aha true. This was cut and paste from k8t890 where it was used to setup APIC resource. For mem resource it should be how? I don't understand the gran too. The limit should always be the upper bound that a type of resource could be set to. For I/O 0x, for MEM, 0x... gran sets the granularity of an allocation. For example, on K8 you have to allocate I/O to links at least 4K at a time, so the granularity is 12. gran and align should never matter for fixed resources. For this SB (the VT8237S) we will definitely need to dynamically allocate a mmio BAR for SPI controller. I will prepare a patch, but cannot test. I would like to ask if you care about the decoding range for flashes - if I need some other resource for that and also about 0xfee... for MSI. Anything above 0xfec... doesn't matter, since you have an APIC resource there. Thanks, Myles Index: svn/src/southbridge/via/vt8237r/vt8237r_lpc.c === --- svn.orig/src/southbridge/via/vt8237r/vt8237r_lpc.c +++ svn/src/southbridge/via/vt8237r/vt8237r_lpc.c @@ -426,11 +426,15 @@ static void vt8237r_read_resources(devic res = new_resource(dev, 0x44); res-base = VT8237R_APIC_BASE; res-size = 256; - res-limit = res-base + res-size - 1; - res-align = 8; - res-gran = 8; + res-limit = 0xUL; res-flags = IORESOURCE_MEM | IORESOURCE_FIXED | IORESOURCE_STORED | IORESOURCE_ASSIGNED; + + res = new_resource(dev, 1); + res-base = 0x0UL; + res-size = 0x1000UL; + res-limit = 0xUL; + res-flags = IORESOURCE_IO | IORESOURCE_ASSIGNED | IORESOURCE_FIXED; } /** -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] option rom size problem
Hi all, Since i am working with adding libpayload usb stack to option rom, i have been blocked with the usb_initialize function. I find that the size of libpayload is 104K, but the max size of option rom is oxff * 512bytes. which means 127.5K. I am afraid our option rom can not works fine with usb stack properly. Is there any other method for us to expand the rom size? -- Jason Wang Peking University -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] some more CONFIG_ prefixes
On 20.07.2009 15:57 Uhr, Myles Watson wrote: attached patch renames some preprocessor symbols. I have no idea why those symbols were left alone before, after this, they're somewhat more in line with the rest of the tree. @@ -18,8 +18,8 @@ #define MAINBOARD_POWER_OFF 0 #define MAINBOARD_POWER_ON 1 -#ifndef MAINBOARD_POWER_ON_AFTER_FAIL -#define MAINBOARD_POWER_ON_AFTER_FAIL MAINBOARD_POWER_ON +#ifndef CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL +#define CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL MAINBOARD_POWER_ON #endif Since they're #ifndef, that means they weren't part of the old config system, or there is a bug. Those symbols are always defined, and are tested based on their values. Is there a uses statement for them somewhere? The old config tool has an flag to determine whether an option should be exported always or only if it is used. Stefan -- 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] [PATCH] some more CONFIG_ prefixes
On 20.07.2009 13:08 Uhr, Patrick Georgi wrote: Hi, attached patch renames some preprocessor symbols. I have no idea why those symbols were left alone before, after this, they're somewhat more in line with the rest of the tree. Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de -- 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] [PATCH] some more CONFIG_ prefixes
On Mon, Jul 20, 2009 at 9:45 AM, Stefan Reinauer ste...@coresystems.dewrote: On 20.07.2009 15:57 Uhr, Myles Watson wrote: Since they're #ifndef, that means they weren't part of the old config system, or there is a bug. Those symbols are always defined, and are tested based on their values. Is there a uses statement for them somewhere? The old config tool has an flag to determine whether an option should be exported always or only if it is used. You're right. I'd forgotten about that. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] option rom size problem
On 20.07.2009 17:40 Uhr, Jason Wang wrote: Hi all, Since i am working with adding libpayload usb stack to option rom, i have been blocked with the usb_initialize function. I find that the size of libpayload is 104K, but the max size of option rom is oxff * 512bytes. which means 127.5K. I am afraid our option rom can not works fine with usb stack properly. Is there any other method for us to expand the rom size? I think only those parts of libpayload that are actually used are getting linked into the final binary, since the objects are packed into an ar archive. Do you exceed the rom size with libpayload and your code already, or is this rather a theoretical issue? -rw-r--r-- 1 stepan staff 114826 Jul 20 17:50 libpayload.a -rw-r--r-- 1 stepan staff1192 Jul 20 17:50 colors.o -rw-r--r-- 1 stepan staff1624 Jul 20 17:50 console.o -rw-r--r-- 1 stepan staff1940 Jul 20 17:50 coreboot.o -rw-r--r-- 1 stepan staff1720 Jul 20 17:50 ctype.o -rw-r--r-- 1 stepan staff 514 Jul 20 17:50 exec.S.o -rw-r--r-- 1 stepan staff 692 Jul 20 17:50 exec.o -rw-r--r-- 1 stepan staff5928 Jul 20 17:50 getopt_long.o -rw-r--r-- 1 stepan staff 896 Jul 20 17:50 head.S.o -rw-r--r-- 1 stepan staff 703 Jul 20 17:50 ipchecksum.o -rw-r--r-- 1 stepan staff1384 Jul 20 17:50 keyboard.o -rw-r--r-- 1 stepan staff4592 Jul 20 17:50 lar.o -rw-r--r-- 1 stepan staff1328 Jul 20 17:50 lib.o -rw-r--r-- 1 stepan staff 920 Jul 20 17:50 main.o -rw-r--r-- 1 stepan staff3224 Jul 20 17:50 malloc.o -rw-r--r-- 1 stepan staff1076 Jul 20 17:50 memory.o -rw-r--r-- 1 stepan staff1432 Jul 20 17:50 nvram.o -rw-r--r-- 1 stepan staff1608 Jul 20 17:50 options.o -rw-r--r-- 1 stepan staff2160 Jul 20 17:50 pci.o -rw-r--r-- 1 stepan staff6660 Jul 20 17:50 printf.o -rw-r--r-- 1 stepan staff 816 Jul 20 17:50 rand.o -rw-r--r-- 1 stepan staff1756 Jul 20 17:50 readline.o -rw-r--r-- 1 stepan staff9016 Jul 20 17:50 sha1.o -rw-r--r-- 1 stepan staff1032 Jul 20 17:50 speaker.o -rw-r--r-- 1 stepan staff2648 Jul 20 17:50 string.o -rw-r--r-- 1 stepan staff 712 Jul 20 17:50 sysinfo.o -rw-r--r-- 1 stepan staff1808 Jul 20 17:50 time.o -rw-r--r-- 1 stepan staff1448 Jul 20 17:50 timer.o -rw-r--r-- 1 stepan staff 10224 Jul 20 17:50 tinycurses.o -rw-r--r-- 1 stepan staff 11436 Jul 20 17:50 uhci.o -rw-r--r-- 1 stepan staff2384 Jul 20 17:50 uhci_rh.o -rw-r--r-- 1 stepan staff5560 Jul 20 17:50 usb.o -rw-r--r-- 1 stepan staff 884 Jul 20 17:50 usb_dev.o -rw-r--r-- 1 stepan staff1576 Jul 20 17:50 usbinit.o -rw-r--r-- 1 stepan staff5704 Jul 20 17:50 usbmsc.o -rw-r--r-- 1 stepan staff 524 Jul 20 17:50 util.S.o -rw-r--r-- 1 stepan staff2032 Jul 20 17:50 vga.o -rw-r--r-- 1 stepan staff2848 Jul 20 17:50 video.o -rw-r--r-- 1 stepan staff 582 Jul 20 17:50 virtual.o I would think there is some potential for optimization: lar, tinycurses, vga, sha1, getopt_long, speaker, video, and probably some more stuff could be removed? Stefan -- 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] option rom size problem
On 20.07.2009 17:54, Stefan Reinauer wrote: On 20.07.2009 17:40 Uhr, Jason Wang wrote: Since i am working with adding libpayload usb stack to option rom, i have been blocked with the usb_initialize function. I find that the size of libpayload is 104K, but the max size of option rom is oxff * 512bytes. which means 127.5K. I am afraid our option rom can not works fine with usb stack properly. Is there any other method for us to expand the rom size? I think only those parts of libpayload that are actually used are getting linked into the final binary, since the objects are packed into an ar archive. Do you exceed the rom size with libpayload and your code already, or is this rather a theoretical issue? If you really exceed the allowed size, the problem is not only option rom size but also where in RAM you can place that much code. Compression can help if you have enough free RAM to place that option ROM somewhere. Where does the option ROM end up? Below 1M? Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] option rom size problem
Hi Stefan On Mon, Jul 20, 2009 at 11:54 AM, Stefan Reinauerste...@coresystems.de wrote: On 20.07.2009 17:40 Uhr, Jason Wang wrote: Hi all, Since i am working with adding libpayload usb stack to option rom, i have been blocked with the usb_initialize function. I find that the size of libpayload is 104K, but the max size of option rom is oxff * 512bytes. which means 127.5K. I am afraid our option rom can not works fine with usb stack properly. Is there any other method for us to expand the rom size? I think only those parts of libpayload that are actually used are getting linked into the final binary, since the objects are packed into an ar archive. Do you exceed the rom size with libpayload and your code already, or is this rather a theoretical issue? No, not theoretical we have reached the max limit, even with a minimal configuration. -rw-r--r-- 1 stepan staff 114826 Jul 20 17:50 libpayload.a -rw-r--r-- 1 stepan staff 1192 Jul 20 17:50 colors.o -rw-r--r-- 1 stepan staff 1624 Jul 20 17:50 console.o -rw-r--r-- 1 stepan staff 1940 Jul 20 17:50 coreboot.o -rw-r--r-- 1 stepan staff 1720 Jul 20 17:50 ctype.o -rw-r--r-- 1 stepan staff 514 Jul 20 17:50 exec.S.o -rw-r--r-- 1 stepan staff 692 Jul 20 17:50 exec.o -rw-r--r-- 1 stepan staff 5928 Jul 20 17:50 getopt_long.o -rw-r--r-- 1 stepan staff 896 Jul 20 17:50 head.S.o -rw-r--r-- 1 stepan staff 703 Jul 20 17:50 ipchecksum.o -rw-r--r-- 1 stepan staff 1384 Jul 20 17:50 keyboard.o -rw-r--r-- 1 stepan staff 4592 Jul 20 17:50 lar.o -rw-r--r-- 1 stepan staff 1328 Jul 20 17:50 lib.o -rw-r--r-- 1 stepan staff 920 Jul 20 17:50 main.o -rw-r--r-- 1 stepan staff 3224 Jul 20 17:50 malloc.o -rw-r--r-- 1 stepan staff 1076 Jul 20 17:50 memory.o -rw-r--r-- 1 stepan staff 1432 Jul 20 17:50 nvram.o -rw-r--r-- 1 stepan staff 1608 Jul 20 17:50 options.o -rw-r--r-- 1 stepan staff 2160 Jul 20 17:50 pci.o -rw-r--r-- 1 stepan staff 6660 Jul 20 17:50 printf.o -rw-r--r-- 1 stepan staff 816 Jul 20 17:50 rand.o -rw-r--r-- 1 stepan staff 1756 Jul 20 17:50 readline.o -rw-r--r-- 1 stepan staff 9016 Jul 20 17:50 sha1.o -rw-r--r-- 1 stepan staff 1032 Jul 20 17:50 speaker.o -rw-r--r-- 1 stepan staff 2648 Jul 20 17:50 string.o -rw-r--r-- 1 stepan staff 712 Jul 20 17:50 sysinfo.o -rw-r--r-- 1 stepan staff 1808 Jul 20 17:50 time.o -rw-r--r-- 1 stepan staff 1448 Jul 20 17:50 timer.o -rw-r--r-- 1 stepan staff 10224 Jul 20 17:50 tinycurses.o -rw-r--r-- 1 stepan staff 11436 Jul 20 17:50 uhci.o -rw-r--r-- 1 stepan staff 2384 Jul 20 17:50 uhci_rh.o -rw-r--r-- 1 stepan staff 5560 Jul 20 17:50 usb.o -rw-r--r-- 1 stepan staff 884 Jul 20 17:50 usb_dev.o -rw-r--r-- 1 stepan staff 1576 Jul 20 17:50 usbinit.o -rw-r--r-- 1 stepan staff 5704 Jul 20 17:50 usbmsc.o -rw-r--r-- 1 stepan staff 524 Jul 20 17:50 util.S.o -rw-r--r-- 1 stepan staff 2032 Jul 20 17:50 vga.o -rw-r--r-- 1 stepan staff 2848 Jul 20 17:50 video.o -rw-r--r-- 1 stepan staff 582 Jul 20 17:50 virtual.o I would think there is some potential for optimization: lar, tinycurses, vga, sha1, getopt_long, speaker, video, and probably some more stuff could be removed? Removing most of libpayload we can take something around 100k, I think it`s not enough. Regards... -- (°= Leandro Dorileo //\ldori...@gmail.com - http://www.dorilex.net V_/ Software is a matter of freedom. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] option rom size problem
Hi Carl On Mon, Jul 20, 2009 at 12:48 PM, Carl-Daniel Hailfingerc-d.hailfinger.devel.2...@gmx.net wrote: On 20.07.2009 17:54, Stefan Reinauer wrote: On 20.07.2009 17:40 Uhr, Jason Wang wrote: Since i am working with adding libpayload usb stack to option rom, i have been blocked with the usb_initialize function. I find that the size of libpayload is 104K, but the max size of option rom is oxff * 512bytes. which means 127.5K. I am afraid our option rom can not works fine with usb stack properly. Is there any other method for us to expand the rom size? I think only those parts of libpayload that are actually used are getting linked into the final binary, since the objects are packed into an ar archive. Do you exceed the rom size with libpayload and your code already, or is this rather a theoretical issue? If you really exceed the allowed size, the problem is not only option rom size but also where in RAM you can place that much code. Compression can help if you have enough free RAM to place that option ROM somewhere. Do you mean we can have a code to decompress the option ROM and jump to it? Where does the option ROM end up? Below 1M? Do you mean in RAM? do you want to know when we move the option ROM to RAM? if so, I can tell you that we are not moving the option ROM to RAM, we leave it to seabios, seabios is who moves the ROM code to RAM. Regards... -- (°= Leandro Dorileo //\ldori...@gmail.com - http://www.dorilex.net V_/ Software is a matter of freedom. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] option rom size problem
Hi Carl On Mon, Jul 20, 2009 at 1:12 PM, Leandro Dorileoldori...@gmail.com wrote: Hi Carl On Mon, Jul 20, 2009 at 12:48 PM, Carl-Daniel Hailfingerc-d.hailfinger.devel.2...@gmx.net wrote: On 20.07.2009 17:54, Stefan Reinauer wrote: On 20.07.2009 17:40 Uhr, Jason Wang wrote: Since i am working with adding libpayload usb stack to option rom, i have been blocked with the usb_initialize function. I find that the size of libpayload is 104K, but the max size of option rom is oxff * 512bytes. which means 127.5K. I am afraid our option rom can not works fine with usb stack properly. Is there any other method for us to expand the rom size? I think only those parts of libpayload that are actually used are getting linked into the final binary, since the objects are packed into an ar archive. Do you exceed the rom size with libpayload and your code already, or is this rather a theoretical issue? If you really exceed the allowed size, the problem is not only option rom size but also where in RAM you can place that much code. Compression can help if you have enough free RAM to place that option ROM somewhere. Do you mean we can have a code to decompress the option ROM and jump to it? Where does the option ROM end up? Below 1M? Do you mean in RAM? do you want to know when we move the option ROM to RAM? if so, I can tell you that we are not moving the option ROM to RAM, we leave it to seabios, seabios is who moves the ROM code to RAM. Of course that I think in a (future)hack to configure the option ROM to be used with seabios or not, so we can have a code to copy from ROM to RAM and so on. Regards -- (°= Leandro Dorileo //\ldori...@gmail.com - http://www.dorilex.net V_/ Software is a matter of freedom. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] [AMD Fam10] Fix confused RB-C2 and DA-C2
Bao, Zheng wrote: In Fam10 BKDG, it says 31:28 PkgType: package type. Specifies the processor package type. This field is encoded as follows: 0001b: AM2r2 or AM3. What is the difference between AM2 and AM2r2? //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] non static 0x1000 IO space can be broken
Myles Watson wrote: Signed-off-by: Myles Watson myle...@gmail.com Looks good, just not tested. Acked-by: Peter Stuge pe...@stuge.se -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [v2] r4442 - in trunk/coreboot-v2/src: include/x86emu southbridge/intel/esb6300 southbridge/intel/i82801gx
Author: oxygene
Date: 2009-07-20 21:34:47 +0200 (Mon, 20 Jul 2009)
New Revision: 4442
Modified:
trunk/coreboot-v2/src/include/x86emu/fpu_regs.h
trunk/coreboot-v2/src/southbridge/intel/esb6300/esb6300_lpc.c
trunk/coreboot-v2/src/southbridge/intel/i82801gx/i82801gx_lpc.c
Log:
Rename some preprocessor symbols. I have no idea why
those symbols were left alone before, after this, they're
somewhat more in line with the rest of the tree.
Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de
Acked-by: Stefan Reinauer ste...@coresystems.de
Modified: trunk/coreboot-v2/src/include/x86emu/fpu_regs.h
===
--- trunk/coreboot-v2/src/include/x86emu/fpu_regs.h 2009-07-19 00:18:15 UTC
(rev 4441)
+++ trunk/coreboot-v2/src/include/x86emu/fpu_regs.h 2009-07-20 19:34:47 UTC
(rev 4442)
@@ -40,7 +40,7 @@
#define __X86EMU_FPU_REGS_H
-#if defined(CONFIG_DEBUG) (DEBUG == 0)
+#if defined(CONFIG_DEBUG) (CONFIG_DEBUG == 0)
#undef CONFIG_DEBUG
#endif
Modified: trunk/coreboot-v2/src/southbridge/intel/esb6300/esb6300_lpc.c
===
--- trunk/coreboot-v2/src/southbridge/intel/esb6300/esb6300_lpc.c
2009-07-19 00:18:15 UTC (rev 4441)
+++ trunk/coreboot-v2/src/southbridge/intel/esb6300/esb6300_lpc.c
2009-07-20 19:34:47 UTC (rev 4442)
@@ -18,8 +18,8 @@
#define MAINBOARD_POWER_OFF 0
#define MAINBOARD_POWER_ON 1
-#ifndef MAINBOARD_POWER_ON_AFTER_FAIL
-#define MAINBOARD_POWER_ON_AFTER_FAIL MAINBOARD_POWER_ON
+#ifndef CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL
+#define CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL MAINBOARD_POWER_ON
#endif
#define ALL(0xff 24)
@@ -277,7 +277,7 @@
{
uint8_t byte;
uint32_t value;
- int pwr_on=MAINBOARD_POWER_ON_AFTER_FAIL;
+ int pwr_on=CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL;
/* sata settings */
pci_write_config32(dev, 0x58, 0x1181);
Modified: trunk/coreboot-v2/src/southbridge/intel/i82801gx/i82801gx_lpc.c
===
--- trunk/coreboot-v2/src/southbridge/intel/i82801gx/i82801gx_lpc.c
2009-07-19 00:18:15 UTC (rev 4441)
+++ trunk/coreboot-v2/src/southbridge/intel/i82801gx/i82801gx_lpc.c
2009-07-20 19:34:47 UTC (rev 4442)
@@ -33,8 +33,8 @@
#define MAINBOARD_POWER_OFF 0
#define MAINBOARD_POWER_ON 1
-#ifndef MAINBOARD_POWER_ON_AFTER_FAIL
-#define MAINBOARD_POWER_ON_AFTER_FAIL MAINBOARD_POWER_ON
+#ifndef CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL
+#define CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL MAINBOARD_POWER_ON
#endif
#define NMI_OFF 0
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Fwd: sony vaio pcg sr1k
Ok, I feel mad enough :) Is there a documentation/info/video that describes what I should do? Also, one more comment, in a previous attempt, I used some tool to enable the virtualization technology of the cpu with hacking it without the own menu of the original bios. I hope this has no harm on bios, correct? Thx On Thu, Jul 16, 2009 at 6:34 PM, ron minnichrminn...@gmail.com wrote: if you really want this you'll need to tear the laptop open and set up some way to safely flash -- meaning, a way to recover from failures. You need to temporarily sacrifice at least one laptop to the cause. I doubt you want to do that :-) sorry ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [v2] r4443 - trunk/coreboot-v2/src/southbridge/via/vt8237r
Author: myles Date: 2009-07-20 21:42:15 +0200 (Mon, 20 Jul 2009) New Revision: 4443 Modified: trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237r_lpc.c Log: Add legacy I/O region for vt8237r southbridge. Signed-off-by: Myles Watson myle...@gmail.com Acked-by: Peter Stuge pe...@stuge.se Modified: trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237r_lpc.c === --- trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237r_lpc.c 2009-07-20 19:34:47 UTC (rev 4442) +++ trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237r_lpc.c 2009-07-20 19:42:15 UTC (rev 4443) @@ -426,11 +426,15 @@ res = new_resource(dev, 0x44); res-base = VT8237R_APIC_BASE; res-size = 256; - res-limit = res-base + res-size - 1; - res-align = 8; - res-gran = 8; + res-limit = 0xUL; res-flags = IORESOURCE_MEM | IORESOURCE_FIXED | IORESOURCE_STORED | IORESOURCE_ASSIGNED; + + res = new_resource(dev, 1); + res-base = 0x0UL; + res-size = 0x1000UL; + res-limit = 0xUL; + res-flags = IORESOURCE_IO | IORESOURCE_ASSIGNED | IORESOURCE_FIXED; } /** -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] non static 0x1000 IO space can be broken
Acked-by: Peter Stuge pe...@stuge.se Rev 4443. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] [AMD Fam10] Fix confused RB-C2 and DA-C2
On Thu, Jul 16, 2009 at 03:40:49PM +0800, Bao, Zheng wrote: This patch is about the DA-C2 and RB-C2. Chip with install processor Revision ID of 0x100F62 is DA-C2, instead of RB-C2 which was incorrectly defined in raminit_amdmct.c. RB-C2's ID is 0x100F42. The Erratas applied to them are almost the same. Issues: 1. I really dont know what their nicknames are (Shanghai C2 or something). 2. About the mc_patch_0186.h, I dont know if it is allowed to be released. If you really need it, please contact AMD Inc to see if it is public. 3. I haven't made coreboot go thoroughly on this RB-C2. This patch is just half tested. I am not confident it is 100% correct. Zheng Signed-off-by: Zheng Bao zheng@amd.com With this patch, I can still boot my system with 00100F42h (RB-C2) CPUs - Opteron 2372HE. Acked-by: Ward Vandewege w...@gnu.org Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] [AMD Fam10] Fix confused RB-C2 and DA-C2
On Mon, Jul 20, 2009 at 10:10:13AM +0800, Bao, Zheng wrote: According to the Revision Guide, I think there might be several kinds of 0x100F42 RB-C2. They are AM2r2, AM3, F1207. Yeah, I see that on page 10 of the Fam10h Revision guide. Note that the link on http://developer.amd.com/documentation/guides/Pages/default.aspx to the Fam10 revision guide is wrong, the correct link is http://support.amd.com/us/Processor_TechDocs/41322.pdf The actual socket type should be read from CPUID_8001_EBX. Right? I think so, according to the revision guide... Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] fam10/h8dmr: extreme slowness in CBFS memset / memcpy
Following up on this - Patrick helped in IRC this evening, and we came to the conclusion that it's probably *not* an MTRR issue, since we figured out the code seems to set MTRRs properly. We found out after adding an extra MTRR over the flash chip, which did not change anything. The system boots fairly normally after the slowdowns, and appears to work normally. It sets three MTRRs further in the bootup process: reg00: base=0x ( 0MB), size=32768MB: write-back, count=1 reg01: base=0x8 (32768MB), size= 512MB: write-back, count=1 reg02: base=0xe000 (3584MB), size= 512MB: uncachable, count=1 Any thoughts on something else I should look at to debug this? Thanks, Ward. On Sun, Jul 19, 2009 at 09:23:21PM -0400, Ward Vandewege wrote: Hi all, I'm working on a fam10 tree for supermicro h8dmr. I'm using CBFS. It boots, but I'm struggling with some extreme slowness during boot. In particular, the memset function in src/lib/memset.c takes *minutes* to clear 1.2MB of ram. A little further CBFS does a memcpy which takes another 20 or 30 seconds: Stage: load fallback/coreboot_ram @ 2097152/1245184 bytes, enter @ 20 LOONG pause Stage: after memset on-stack variables at 00ffbec8 and 00ffbed4 cbfs_decompress: algo: 0 cbfs_decompress: uncompressed another lengthy pause cbfs_decompress: memcpy from 0xffbecc to 0xffbed0 for 0x2d304 bytes done Stage: done loading. The first, lengthly pause is new; it is apparently caused by something introduced between r4368 and r4440. The second pause was there already in r4368. I understand this may have something to do with MTRRs - looking at the logs it seems MTRRs are not set up until well after CBFS has dealt with coreboot_ram. This box has 32GB of ram, in case that makes a difference. Any suggestions? Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] [AMD Fam10] Fix confused RB-C2 and DA-C2
If anyone can tell me what the nicknames of AMD_RB_C2 AMD_DA_C2 are, I will submit the code. Zheng -Original Message- From: Ward Vandewege [mailto:w...@gnu.org] Sent: Tuesday, July 21, 2009 3:58 AM To: Bao, Zheng Cc: Coreboot Subject: Re: [coreboot] [patch] [AMD Fam10] Fix confused RB-C2 and DA-C2 On Thu, Jul 16, 2009 at 03:40:49PM +0800, Bao, Zheng wrote: This patch is about the DA-C2 and RB-C2. Chip with install processor Revision ID of 0x100F62 is DA-C2, instead of RB-C2 which was incorrectly defined in raminit_amdmct.c. RB-C2's ID is 0x100F42. The Erratas applied to them are almost the same. Issues: 1. I really dont know what their nicknames are (Shanghai C2 or something). 2. About the mc_patch_0186.h, I dont know if it is allowed to be released. If you really need it, please contact AMD Inc to see if it is public. 3. I haven't made coreboot go thoroughly on this RB-C2. This patch is just half tested. I am not confident it is 100% correct. Zheng Signed-off-by: Zheng Bao zheng@amd.com With this patch, I can still boot my system with 00100F42h (RB-C2) CPUs - Opteron 2372HE. Acked-by: Ward Vandewege w...@gnu.org Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Fwd: sony vaio pcg sr1k
Hi Ahmet, ahmet alper parker wrote: Ok, I feel mad enough :) Is there a documentation/info/video that describes what I should do? An efficient firmware level developer has years of software and ideally also hardware education (autodidact, or otherwise) as well as development experience. That can't really be packaged in a video that can just be clicked on in a web browser. There is however a lot of documentation available online, and of course the source code can be used to learn a lot! There are several presentations about coreboot available online, but they are all somewhat introductory and overviewy, because it is difficult to go into all details in only 40 minutes. The better way to start is typically from the other end - learn all you can about lowlevel PC programming in general, and then focus on coreboot. coreboot isn't a great place to learn everything you need. It can certainly be done, but it will take a very long time. If you have already opened your laptop several times to do some hacking, and you figured out how to do it yourself, I think it could be really interesting to work on coreboot. You would learn about every single pin (there are a thousand or so) on the major chips in your laptop, you would get a soldering iron if you don't already have one and you would learn how to solder surface mount components on the laptop mainboard. You could also help yourself by learning about electronics, voltages and current, in order to turn your laptop (meant for users) into an embedded systems development board (good for firmware level development). This might mostly consist of mechanical (i.e. physical) hacks, to be able to run the system without the case, but that can be very tricky. Also, one more comment, in a previous attempt, I used some tool to enable the virtualization technology of the cpu with hacking it without the own menu of the original bios. I hope this has no harm on bios, correct? That's impossible to say without knowing exactly what the tool did. I would say that if your system still starts and runs, and you notice no problems while running the system, then your BIOS is still OK. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
