[coreboot] #143: GWNrhCTD
#143: GWNrhCTD --+- Reporter: yehcadusm | Owner: somebody Type: defect | Status: new Priority: major | Milestone: flashrom v1.1 Component: coreboot|Version: v2 Keywords: OQMfDOyZuXkPWXpgUu | Dependencies: xRubMEkrdfnCnLGYpfq Patchstatus: there is no patch | --+- UuJ2sh a href=http://lsdikozhgfyb.com/;lsdikozhgfyb/a, [url=http://zamzpaxpzixz.com/]zamzpaxpzixz[/url], [link=http://kijfmgjhiuug.com/]kijfmgjhiuug[/link], http://zmcrcittastx.com/ -- Ticket URL: http://tracker.coreboot.org/trac/coreboot/ticket/143 coreboot http://www.coreboot.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] #144: GWNrhCTD
#144: GWNrhCTD --+- Reporter: yehcadusm | Owner: somebody Type: defect | Status: new Priority: major | Milestone: flashrom v1.1 Component: coreboot|Version: v2 Keywords: OQMfDOyZuXkPWXpgUu | Dependencies: xRubMEkrdfnCnLGYpfq Patchstatus: there is no patch | --+- UuJ2sh a href=http://lsdikozhgfyb.com/;lsdikozhgfyb/a, [url=http://zamzpaxpzixz.com/]zamzpaxpzixz[/url], [link=http://kijfmgjhiuug.com/]kijfmgjhiuug[/link], http://zmcrcittastx.com/ -- Ticket URL: http://tracker.coreboot.org/trac/coreboot/ticket/144 coreboot http://www.coreboot.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Fwd: sony vaio pcg sr1k
I have the same problem, I have a vaio vgn-fz21m and I hate its own bios. Since it may be misunderstood, I would like to choose the best words to express my need. I can even donate some money to coreboot if someone is willing to write smthing. :) Please write it for us :) I really, really hate sony's own bios, it gave no option/choice to the user. With kind regards... AAP On Thu, Jul 16, 2009 at 1:33 AM, ron minnichrminn...@gmail.com wrote: I am afraid it will probably never be safe to flash your laptop with coreboot. Sony made it very hard for us to figure out what we needed to do. We looked into a very similar laptop to yours 9 years ago and finally decided it was not worth our time. Sorry ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problem with objcopy: cannot generate coreboot.strip
Thanks for your reply, Myles! Myles Watson wrote: On Thu, Jul 16, 2009 at 6:55 AM, Jeffrey C. Jacobs jac...@itd.nrl.navy.mil mailto:jac...@itd.nrl.navy.mil wrote: gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o /usr/bin/ld: warning: dot moved backwards before `.text' /usr/bin/ld: warning: dot moved backwards before `.id' /usr/bin/ld: warning: dot moved backwards before `.text' /usr/bin/ld: warning: dot moved backwards before `.id' /usr/bin/ld: warning: dot moved backwards before `.text' /usr/bin/ld: warning: dot moved backwards before `.id' I haven't seen these warnings. Are they the cause? Well, I just tried to build the Tyan S1846 board and got these warnings for CRT0: /usr/bin/ld: warning: dot moved backwards before `.id' /usr/bin/ld: warning: dot moved backwards before `.id' /usr/bin/ld: warning: dot moved backwards before `.id' So I guess that may be a red herring since... nm -n linuxbios | sort linuxbios.map objcopy --gap-fill 0xff -R .note.gnu.build-id -O binary linuxbios linuxbios.strip objcopy: linuxbios.strip: Bad value objcopy: linuxbios.strip: Bad value make[1]: *** [linuxbios.strip] Error 1 make[1]: Leaving directory `/home/jacobs/LinuxBIOS-v2-GRUB-PTR/targets/arcom/apollo/apollo/image' make: *** [image/linuxbios.rom] Error 1 I haven't seen anything like this myself. Do all boards fail for you, or is it just this one? Abuild still passes all the boards for me. ... the Tyan S1846 DOES pass the objcopy step so it looks to be specific to my target (the arcom/apollo board). The funny thing is, this was all working before I updated to the latest version (though I could never boot past the jump to boot loader step before). I should also note in the strace I originally attached that objcopy literally tries to write like 4GB of 0xFF before dying if that helps. In fact, it prints one Bad value before the massive write, and one after. Also, to be clear, the strace I attached was for my build of the latest Coreboot, not from my old LinuxBIOS and that I get the same error for both the old and current edition. Thanks again! Jeffrey. -- 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
Hi Zheng, 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. Aha. That would perhaps explain why my box with Quad-Core AMD Opteron(tm) Processor 2372 HE with revision id 0x100f42 really does not like ucode revision 92 (it resets itself constantly). Issues: 1. I really dont know what their nicknames are (Shanghai C2 or something). Don't know about that. 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. Well, I have my box booting without any ucode update. It would be nice to have mc_patch_0186.h public if that's the revision for my cpus. Who do I ask? 3. I haven't made coreboot go thoroughly on this RB-C2. This patch is just half tested. I now have a working tree for Supermicro h8dmr with RB-C2 but it needs a bit more tweaking and cleaning up. I hope to get that ready soon so I can submit the patch to the list. I am not confident it is 100% correct. I'll test tonight or tomorrow and let you know how it goes. Thanks! Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problem with objcopy: cannot generate coreboot.strip
On Thu, Jul 16, 2009 at 8:33 AM, Jeffrey C. Jacobs jac...@itd.nrl.navy.milwrote: Thanks for your reply, Myles! No problem. Myles Watson wrote: On Thu, Jul 16, 2009 at 6:55 AM, Jeffrey C. Jacobs jac...@itd.nrl.navy.mil mailto:jac...@itd.nrl.navy.mil wrote: gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o /usr/bin/ld: warning: dot moved backwards before `.text' /usr/bin/ld: warning: dot moved backwards before `.id' /usr/bin/ld: warning: dot moved backwards before `.text' /usr/bin/ld: warning: dot moved backwards before `.id' /usr/bin/ld: warning: dot moved backwards before `.text' /usr/bin/ld: warning: dot moved backwards before `.id' I haven't seen these warnings. Are they the cause? Well, I just tried to build the Tyan S1846 board and got these warnings for CRT0: /usr/bin/ld: warning: dot moved backwards before `.id' /usr/bin/ld: warning: dot moved backwards before `.id' /usr/bin/ld: warning: dot moved backwards before `.id' No .text warnings, though. So I guess that may be a red herring since... Could be, but they still look suspicious to me. ... the Tyan S1846 DOES pass the objcopy step so it looks to be specific to my target (the arcom/apollo board). The funny thing is, this was all working before I updated to the latest version (though I could never boot past the jump to boot loader step before). I should also note in the strace I originally attached that objcopy literally tries to write like 4GB of 0xFF before dying if that helps. I would say that sounds like a negative number. So if you're telling it to fill a negative amount of space with 0xff... Maybe start by comparing ldscripts and offsets between the S1846 and your board? Try removing the gap-fill parameter to narrow it down? Good luck, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problem with objcopy: cannot generate coreboot.strip
Myles Watson wrote: On Thu, Jul 16, 2009 at 8:33 AM, Jeffrey C. Jacobs jac...@itd.nrl.navy.mil mailto:jac...@itd.nrl.navy.mil wrote: Myles Watson wrote: On Thu, Jul 16, 2009 at 6:55 AM, Jeffrey C. Jacobs jac...@itd.nrl.navy.mil mailto:jac...@itd.nrl.navy.mil mailto:jac...@itd.nrl.navy.mil mailto:jac...@itd.nrl.navy.mil wrote: Well, I just tried to build the Tyan S1846 board and got these warnings for CRT0: No .text warnings, though. So I guess that may be a red herring since... Could be, but they still look suspicious to me. I'll keep that in mind, thanks... I would say that sounds like a negative number. So if you're telling it to fill a negative amount of space with 0xff... Maybe start by comparing ldscripts and offsets between the S1846 and your board? Try removing the gap-fill parameter to narrow it down? I tried turning off the gap fill and got past the Bad value error and was able to produce a coreboot.strip file which turned out to be EXACTLY 2**32 bytes in size. I like your accidental negative idea though given that it is exactly 2**32, I think it may actually be an accidental 0. I wonder, were any new CONFIG_* parameters added in the last couple months? When I converted over, I searched all my old .lb parameters for any reference to the non-CONFIG form and am pretty sure I got them all, but if any were added that I didn't take into account, that may be the cause of my error in the latest Coreboot, though it wouldn't explain why I'm getting the same Bad value error on the older LinuxBIOS build. Also, what happens when I set CONFIG_ROM_IMAGE_SIZE to 0x0C000 if the coreboot ROM turns out to be bigger than 49152? What is a typically size for the coreboot ROM? I made the ROM Image Size so small because I only have a 256kB flash and GRUB2 with modules turned out to be a bit over 128kB (153900 Bytes). So, have I made a nubie mistake? I could have sworn this was working before I updated but if tweaking sizes here and there is the solution, that's what I'll try. Thanks again Myles! Jeffrey. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Fwd: sony vaio pcg sr1k
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
Re: [coreboot] Problem with objcopy: cannot generate coreboot.strip
The cause of a 2^32 file can be that gcc has been upgraded and is generating new section names that are not covered in our ldscripts. I fixed this problem recently in another context. The new sections will get linked at address 0. I think your accidental 0 idea is correct. Can you do a readelf on the various coreboot files and look for a section name that is not in the ldscripts? ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] failover only for s2895
I had always misunderstood failover. I thought it was the last resort if
normal fallback didn't work. It actually is just a minimal image that
chooses whether to run normal or fallback.
This patch makes that clear for the s2895 by separating the files. I like
it much better. I'm eventually planning to do the same for all of the AMD
Tyan boards. For the patch to apply, you have to svn cp cache_as_ram_auto.c
to failover.c
The only problem I had was where to put the definition of post_code. Since
it is trivial, I made it a #define. I tried to put it in other places, but
it affected the PPC targets and others because we define post_code in other
places.
Boot tested.
Signed-off-by: Myles Watson myle...@gmail.com
Thanks,
Myles
Index: cbv2/src/mainboard/tyan/s2895/cache_as_ram_auto.c
===
--- cbv2.orig/src/mainboard/tyan/s2895/cache_as_ram_auto.c
+++ cbv2/src/mainboard/tyan/s2895/cache_as_ram_auto.c
@@ -1,4 +1,3 @@
-#define ASSEMBLY 1
#define __ROMCC__
#define K8_ALLOCATE_IO_RANGE 1
@@ -21,11 +20,12 @@
#include option_table.h
#include pc80/mc146818rtc_early.c
-#if CONFIG_USE_FAILOVER_IMAGE==0
+#define post_code(x) outb(x, 0x80)
#include pc80/serial.c
#include arch/i386/lib/console.c
#include ram/ramtest.c
+
#include cpu/amd/model_fxx_rev.h
#include northbridge/amd/amdk8/incoherent_ht.c
@@ -34,8 +34,6 @@
#include cpu/amd/model_fxx/apic_timer.c
#include lib/delay.c
-#endif
-
#include cpu/x86/lapic/boot_cpu.c
#include northbridge/amd/amdk8/reset_test.c
#include superio/smsc/lpc47b397/lpc47b397_early_serial.c
@@ -44,8 +42,6 @@
#define SUPERIO_GPIO_IO_BASE 0x400
-#if CONFIG_USE_FAILOVER_IMAGE==0
-
#include cpu/x86/bist.h
#include northbridge/amd/amdk8/debug.c
@@ -118,117 +114,8 @@ static inline int spd_read_byte(unsigned
#include cpu/amd/model_fxx/init_cpus.c
-#endif
-
-#if ((CONFIG_HAVE_FAILOVER_BOOT==1) (CONFIG_USE_FAILOVER_IMAGE == 1)) || ((CONFIG_HAVE_FAILOVER_BOOT==0) (CONFIG_USE_FALLBACK_IMAGE == 1))
-
-#include southbridge/nvidia/ck804/ck804_enable_rom.c
-#include northbridge/amd/amdk8/early_ht.c
-
-static void sio_setup(void)
-{
-
- unsigned value;
- uint32_t dword;
- uint8_t byte;
-
- pci_write_config32(PCI_DEV(0, CK804_DEVN_BASE+1, 0), 0xac, 0x047f0400);
-
- byte = pci_read_config8(PCI_DEV(0, CK804_DEVN_BASE+1 , 0), 0x7b);
- byte |= 0x20;
- pci_write_config8(PCI_DEV(0, CK804_DEVN_BASE+1 , 0), 0x7b, byte);
-
- dword = pci_read_config32(PCI_DEV(0, CK804_DEVN_BASE+1 , 0), 0xa0);
- dword |= (129)|(10);
- pci_write_config32(PCI_DEV(0, CK804_DEVN_BASE+1 , 0), 0xa0, dword);
-
- dword = pci_read_config32(PCI_DEV(0, CK804_DEVN_BASE+1, 0), 0xa4);
- dword |= (116);
- pci_write_config32(PCI_DEV(0, CK804_DEVN_BASE+1 , 0), 0xa4, dword);
-
- lpc47b397_enable_serial(SUPERIO_GPIO_DEV, SUPERIO_GPIO_IO_BASE);
- value = lpc47b397_gpio_offset_in(SUPERIO_GPIO_IO_BASE, 0x77);
- value = 0xbf;
- lpc47b397_gpio_offset_out(SUPERIO_GPIO_IO_BASE, 0x77, value);
-
-}
-
-void failover_process(unsigned long bist, unsigned long cpu_init_detectedx)
-{
- unsigned last_boot_normal_x = last_boot_normal();
-
- /* Is this a cpu only reset? or Is this a secondary cpu? */
- if ((cpu_init_detectedx) || (!boot_cpu())) {
- if (last_boot_normal_x) {
- goto normal_image;
- } else {
- goto fallback_image;
- }
- }
-
- /* Nothing special needs to be done to find bus 0 */
- /* Allow the HT devices to be found */
-
- enumerate_ht_chain();
-
- sio_setup();
-
- /* Setup the ck804 */
- ck804_enable_rom();
-
- /* Is this a deliberate reset by the bios */
-// post_code(0x22);
- if (bios_reset_detected() last_boot_normal_x) {
- goto normal_image;
- }
- /* This is the primary cpu how should I boot? */
- else if (do_normal_boot()) {
- goto normal_image;
- }
- else {
- goto fallback_image;
- }
- normal_image:
-// post_code(0x23);
- __asm__ volatile (jmp __normal_image
- : /* outputs */
- : a (bist), b(cpu_init_detectedx) /* inputs */
- );
-
- fallback_image:
-// post_code(0x25);
-#if CONFIG_HAVE_FAILOVER_BOOT==1
- __asm__ volatile (jmp __fallback_image
- : /* outputs */
- : a (bist), b (cpu_init_detectedx) /* inputs */
- )
-#endif
- ;
-}
-#endif
-
-void real_main(unsigned long bist, unsigned long cpu_init_detectedx);
-
void cache_as_ram_main(unsigned long bist, unsigned long cpu_init_detectedx)
{
-#if CONFIG_HAVE_FAILOVER_BOOT==1
- #if CONFIG_USE_FAILOVER_IMAGE==1
- failover_process(bist, cpu_init_detectedx);
- #else
- real_main(bist, cpu_init_detectedx);
- #endif
-#else
- #if CONFIG_USE_FALLBACK_IMAGE == 1
- failover_process(bist, cpu_init_detectedx);
- #endif
- real_main(bist, cpu_init_detectedx);
-#endif
-}
-
-#if CONFIG_USE_FAILOVER_IMAGE==0
-
-void real_main(unsigned long bist, unsigned long cpu_init_detectedx)
-{
static const uint16_t spd_addr [] = {
(0xa3)|0, (0xa3)|2, 0, 0,
(0xa3)|1, (0xa3)|3, 0, 0,
@@ -248,7 +135,7 @@ void real_main(unsigned long bist, unsig
bsp_apicid = init_cpus(cpu_init_detectedx);
}
-// post_code(0x32);
+
Re: [coreboot] failover only for s2895
On Thu, Jul 16, 2009 at 8:42 AM, Myles Watsonmyle...@gmail.com wrote: I had always misunderstood failover. I thought it was the last resort if normal fallback didn't work. It actually is just a minimal image that chooses whether to run normal or fallback. that's why I never liked the name :-) It's confusing. Acked-by: Ronald G. Minnich rmin...@gmail.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [v2] r4427 - trunk/coreboot-v2/src/mainboard/tyan/s2895
Author: myles Date: 2009-07-16 17:53:11 +0200 (Thu, 16 Jul 2009) New Revision: 4427 Added: trunk/coreboot-v2/src/mainboard/tyan/s2895/failover.c Modified: trunk/coreboot-v2/src/mainboard/tyan/s2895/Config.lb trunk/coreboot-v2/src/mainboard/tyan/s2895/cache_as_ram_auto.c Log: Separate cache_as_ram_auto.c and failover.c for Tyan s2895. Signed-off-by: Myles Watson myle...@gmail.com Acked-by: Ronald G. Minnich rmin...@gmail.com Modified: trunk/coreboot-v2/src/mainboard/tyan/s2895/Config.lb === --- trunk/coreboot-v2/src/mainboard/tyan/s2895/Config.lb2009-07-15 00:03:28 UTC (rev 4426) +++ trunk/coreboot-v2/src/mainboard/tyan/s2895/Config.lb2009-07-16 15:53:11 UTC (rev 4427) @@ -29,10 +29,25 @@ end if CONFIG_USE_INIT +if CONFIG_USE_FAILOVER_IMAGE makerule ./auto.o + depends $(CONFIG_MAINBOARD)/failover.c option_table.h + action $(CC) $(DISTRO_CFLAGS) $(CFLAGS) $(CPPFLAGS) -I$(TOP)/src -I. -c $(CONFIG_MAINBOARD)/failover.c -o $@ + end +else + makerule ./auto.o depends $(CONFIG_MAINBOARD)/cache_as_ram_auto.c option_table.h action $(CC) $(DISTRO_CFLAGS) $(CFLAGS) $(CPPFLAGS) -I$(TOP)/src -I. -c $(CONFIG_MAINBOARD)/cache_as_ram_auto.c -o $@ end +end +else #CONFIG_USE_INIT +if CONFIG_USE_FAILOVER_IMAGE + makerule ./auto.inc + depends $(CONFIG_MAINBOARD)/failover.c option_table.h + action $(CC) $(DISTRO_CFLAGS) $(CFLAGS) $(CPPFLAGS) $(DEBUG_CFLAGS) -I$(TOP)/src -I. -c -S $(CONFIG_MAINBOARD)/failover.c -o $@ + action perl -e 's/\.rodata/.rom.data/g' -pi $@ + action perl -e 's/\.text/.section .rom.text/g' -pi $@ + end else makerule ./auto.inc depends $(CONFIG_MAINBOARD)/cache_as_ram_auto.c option_table.h @@ -41,51 +56,32 @@ action perl -e 's/\.text/.section .rom.text/g' -pi $@ end end +end #CONFIG_USE_INIT ## ## Build our 16 bit and 32 bit coreboot entry code ## -if CONFIG_HAVE_FAILOVER_BOOT - if CONFIG_USE_FAILOVER_IMAGE - mainboardinit cpu/x86/16bit/entry16.inc - ldscript /cpu/x86/16bit/entry16.lds - end -else - if CONFIG_USE_FALLBACK_IMAGE - mainboardinit cpu/x86/16bit/entry16.inc - ldscript /cpu/x86/16bit/entry16.lds - end +if CONFIG_USE_FAILOVER_IMAGE + mainboardinit cpu/x86/16bit/entry16.inc + ldscript /cpu/x86/16bit/entry16.lds end mainboardinit cpu/x86/32bit/entry32.inc if CONFIG_USE_INIT ldscript /cpu/x86/32bit/entry32.lds - end - - if CONFIG_USE_INIT ldscript /cpu/amd/car/cache_as_ram.lds end ## ## Build our reset vector (This is where coreboot is entered) ## -if CONFIG_HAVE_FAILOVER_BOOT -if CONFIG_USE_FAILOVER_IMAGE +if CONFIG_USE_FAILOVER_IMAGE mainboardinit cpu/x86/16bit/reset16.inc ldscript /cpu/x86/16bit/reset16.lds -else - mainboardinit cpu/x86/32bit/reset32.inc - ldscript /cpu/x86/32bit/reset32.lds -end else -if CONFIG_USE_FALLBACK_IMAGE - mainboardinit cpu/x86/16bit/reset16.inc - ldscript /cpu/x86/16bit/reset16.lds -else mainboardinit cpu/x86/32bit/reset32.inc ldscript /cpu/x86/32bit/reset32.lds -end end ## @@ -97,21 +93,14 @@ ## ## ROMSTRAP table for CK804 ## -if CONFIG_HAVE_FAILOVER_BOOT - if CONFIG_USE_FAILOVER_IMAGE - mainboardinit southbridge/nvidia/ck804/romstrap.inc - ldscript /southbridge/nvidia/ck804/romstrap.lds - end -else - if CONFIG_USE_FALLBACK_IMAGE - mainboardinit southbridge/nvidia/ck804/romstrap.inc - ldscript /southbridge/nvidia/ck804/romstrap.lds - end +if CONFIG_USE_FAILOVER_IMAGE + mainboardinit southbridge/nvidia/ck804/romstrap.inc + ldscript /southbridge/nvidia/ck804/romstrap.lds end - ## - ## Setup Cache-As-Ram - ## +## +## Setup Cache-As-Ram +## mainboardinit cpu/amd/car/cache_as_ram.inc ### @@ -119,14 +108,8 @@ ### Things are delicate and we test to see if we should ### failover to another image. ### -if CONFIG_HAVE_FAILOVER_BOOT - if CONFIG_USE_FAILOVER_IMAGE - ldscript /arch/i386/lib/failover_failover.lds - end -else - if CONFIG_USE_FALLBACK_IMAGE - ldscript /arch/i386/lib/failover.lds - end +if CONFIG_USE_FAILOVER_IMAGE + ldscript /arch/i386/lib/failover_failover.lds end ## Modified: trunk/coreboot-v2/src/mainboard/tyan/s2895/cache_as_ram_auto.c === --- trunk/coreboot-v2/src/mainboard/tyan/s2895/cache_as_ram_auto.c 2009-07-15 00:03:28 UTC (rev 4426) +++ trunk/coreboot-v2/src/mainboard/tyan/s2895/cache_as_ram_auto.c 2009-07-16 15:53:11 UTC
Re: [coreboot] failover only for s2895
On Thu, Jul 16, 2009 at 9:46 AM, ron minnich rminn...@gmail.com wrote: On Thu, Jul 16, 2009 at 8:42 AM, Myles Watsonmyle...@gmail.com wrote: I had always misunderstood failover. I thought it was the last resort if normal fallback didn't work. It actually is just a minimal image that chooses whether to run normal or fallback. that's why I never liked the name :-) It's confusing. One of these days we'll have to change the name of cache_as_ram_auto.c and failover.c at the same time. Acked-by: Ronald G. Minnich rmin...@gmail.com Rev 4427. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [patch] LAB support for Asus M2V-MX SE
Hi folks, The attached patch enables LAB for this motherboard in coreboot-v2. Should I change the ROM size or leave it as it is? Also, Carl Daniel said something about CONFIG_XIP_ROM_SIZE calculation. Is it ok if I just hardcode it to 64KB? Signed-of by: Cristi Măgherușancristi.magheru...@net.utcluj.ro --- a/src/mainboard/asus/m2v-mx_se/Options.lb +++ b/src/mainboard/asus/m2v-mx_se/Options.lb @@ -92,6 +92,7 @@ uses CONFIG_HT_CHAIN_END_UNITID_BASE uses CONFIG_SB_HT_CHAIN_UNITID_OFFSET_ONLY # bx_b005+ uses CONFIG_SB_HT_CHAIN_ON_BUS0 +uses CONFIG_PRECOMPRESSED_PAYLOAD uses CONFIG_COMPRESSED_PAYLOAD_NRV2B uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses CONFIG_USE_PRINTK_IN_CAR --- /dev/null +++ b/targets/asus/m2v-mx_se/Config-lab.lb @@ -0,0 +1,24 @@ +# Sample config file for +# the Asus M2V-MX-SE +# This will make a target directory of ./m2v-mx_se + +target m2v-mx_se +mainboard asus/m2v-mx_se + +option CONFIG_COMPRESSED_PAYLOAD_LZMA=1 +option CONFIG_PRECOMPRESSED_PAYLOAD=1 + +# I have a 4MB SPI flash +option CONFIG_ROM_SIZE= 4096 * 1024 + +# reserved for coreboot +option CONFIG_ROM_IMAGE_SIZE = 128 * 1024 + +option CONFIG_XIP_ROM_SIZE = 65536 + +romimage image + option COREBOOT_EXTRA_VERSION=$(shell cat ../../VERSION)_Fallback + payload ../payload.elf.lzma +end + +buildrom ./coreboot.rom CONFIG_ROM_SIZE image -- Ing. Cristi Măgherușan, System/Network Engineer Technical University of Cluj-Napoca, Romania http://cc.utcluj.ro +40264 401247 --- a/src/mainboard/asus/m2v-mx_se/Options.lb +++ b/src/mainboard/asus/m2v-mx_se/Options.lb @@ -92,6 +92,7 @@ uses CONFIG_HT_CHAIN_END_UNITID_BASE uses CONFIG_SB_HT_CHAIN_UNITID_OFFSET_ONLY # bx_b005+ uses CONFIG_SB_HT_CHAIN_ON_BUS0 +uses CONFIG_PRECOMPRESSED_PAYLOAD uses CONFIG_COMPRESSED_PAYLOAD_NRV2B uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses CONFIG_USE_PRINTK_IN_CAR --- /dev/null +++ b/targets/asus/m2v-mx_se/Config-lab.lb @@ -0,0 +1,24 @@ +# Sample config file for +# the Asus M2V-MX-SE +# This will make a target directory of ./m2v-mx_se + +target m2v-mx_se +mainboard asus/m2v-mx_se + +option CONFIG_COMPRESSED_PAYLOAD_LZMA=1 +option CONFIG_PRECOMPRESSED_PAYLOAD=1 + +# I have a 4MB SPI flash +option CONFIG_ROM_SIZE= 4096 * 1024 + +# reserved for coreboot +option CONFIG_ROM_IMAGE_SIZE = 128 * 1024 + +option CONFIG_XIP_ROM_SIZE = 65536 + +romimage image + option COREBOOT_EXTRA_VERSION=$(shell cat ../../VERSION)_Fallback + payload ../payload.elf.lzma +end + +buildrom ./coreboot.rom CONFIG_ROM_SIZE image signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] LAB support for Asus M2V-MX SE
The attached patch enables LAB for this motherboard in coreboot-v2. Should I change the ROM size or leave it as it is? I would leave it as it works for you. Also, Carl Daniel said something about CONFIG_XIP_ROM_SIZE calculation. Is it ok if I just hardcode it to 64KB? Do you need to change it? It should be set correctly in src/mainboard/.../Options.lb if the board needs something different than the default. Signed-of by: Cristi Măgherușancristi.magheru...@net.utcluj.ro With the XIP question addressed: Acked-by: Myles Watson myle...@gmail.com Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [patch] Buildrom support for Asus M2V-MX SE
Here's the patch: http://panzer.utcluj.ro/cgi-bin/cgit.cgi/avatt/patch/?id=1f45b765097fd8ba2139a078bd57679e16ac4699 Signed-off by: Cristi Măgherușan cristi.magheru...@net.utcluj.ro I'm unable to say which others may worth it, but someone who's interested by buildrom can also cherry-pick some changesets/patches from my git repos at http://panzer.utcluj.ro/cgi-bin/cgit.cgi/ and include them in the main buildrom repo. A few of them are merged in the buildrom repo, while others are still in AVATT (I'm using braid to track my buildrom repo from AVATT, so it's easy to do it), but they will be merged eventually when I have some spare time.. From 1f45b765097fd8ba2139a078bd57679e16ac4699 Mon Sep 17 00:00:00 2001 From: Cristi Măgherușan cristi.magheru...@net.utcluj.ro Date: Thu, 16 Jul 2009 18:16:13 + Subject: Added support for my Asus M2V-MX SE --- diff --git a/buildrom/buildrom-devel/config/platforms/Config.in b/buildrom/buildrom-devel/config/platforms/Config.in index e8a0a8b..1fa6a12 100644 --- a/buildrom/buildrom-devel/config/platforms/Config.in +++ b/buildrom/buildrom-devel/config/platforms/Config.in @@ -104,6 +104,13 @@ config PLATFORM_ASUS_A8N_E select PLATFORM select PLATFORM_SUPPORT_64BIT +config PLATFORM_ASUS_M2V_MX_SE + bool ASUS M2V-MX SE + depends on VENDOR_ASUS + depends on COREBOOT_V2 + select PLATFORM + select PLATFORM_SUPPORT_64BIT + config PLATFORM_GA_2761GXDK bool GIGABYTE GA-2761GXDK depends on VENDOR_GIGABYTE diff --git a/buildrom/buildrom-devel/config/platforms/asus_m2v-mx_se.conf b/buildrom/buildrom-devel/config/platforms/asus_m2v-mx_se.conf new file mode 100644 index 000..a78863e --- a/dev/null +++ b/buildrom/buildrom-devel/config/platforms/asus_m2v-mx_se.conf @@ -0,0 +1,28 @@ +# Support for the ASUS A8V-E SE board + + Platform configuration + +ifeq ($(CONFIG_TARGET_64BIT),y) +TARGET_ARCH=x86_64 +CFLAGS_platform = +else +TARGET_ARCH=i686 +CFLAGS_platform = +endif + +# kernel configuration (for LAB) + +# TODO + +UCLIBC_ARCH=$(TARGET_ARCH) + +# Etherboot configuration + +ETHERBOOT_ARCH=i386 + +# coreboot configuration + +COREBOOT_VENDOR=asus +COREBOOT_BOARD=m2v-mx_se +CBV2_TDIR=m2v-mx_se +CBV2_TAG=4426 diff --git a/buildrom/buildrom-devel/config/platforms/platforms.conf b/buildrom/buildrom-devel/config/platforms/platforms.conf index 733ca73..f5f62f8 100644 --- a/buildrom/buildrom-devel/config/platforms/platforms.conf +++ b/buildrom/buildrom-devel/config/platforms/platforms.conf @@ -23,6 +23,7 @@ PLATFORM-$(CONFIG_PLATFORM_DBE61) = dbe61.conf PLATFORM-$(CONFIG_PLATFORM_GA_M57SLI_S4) = m57sli.conf PLATFORM-$(CONFIG_PLATFORM_ASUS_A8V_E_SE) = asus_a8v-e_se.conf PLATFORM-$(CONFIG_PLATFORM_ASUS_A8N_E) = asus_a8n-e.conf +PLATFORM-$(CONFIG_PLATFORM_ASUS_M2V_MX_SE) = asus_m2v-mx_se.conf PLATFORM-$(CONFIG_PLATFORM_TYAN_S2881) = tyan-s2881.conf PLATFORM-$(CONFIG_PLATFORM_TYAN_S2882) = tyan-s2882.conf PLATFORM-$(CONFIG_PLATFORM_TYAN_S2891) = tyan-s2891.conf -- Ing. Cristi Măgherușan, System/Network Engineer Technical University of Cluj-Napoca, Romania http://cc.utcluj.ro +40264 401247 signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] Buildrom support for Asus M2V-MX SE
Acked-by: Ronald G. Minnich rminn...@gmail.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] add pretty cpu name for Athlon X2 5050e
See attached. I'm not sure if I could predict the IDs for the 4050e/4450e/4850e - anyone know? I only have a 5050e. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator Add pretty name for AMD Athlon(tm) 64 X2 Dual Core Processor 5050e. Boot tested. Signed-off-by: Ward Vandewege w...@gnu.org Index: src/cpu/amd/model_fxx/processor_name.c === --- src/cpu/amd/model_fxx/processor_name.c (revision 4407) +++ src/cpu/amd/model_fxx/processor_name.c (working copy) @@ -301,6 +302,10 @@ processor_name_string = AMD Athlon(tm) 64 FX-ZZ Dual Core Processor; break; + case 0x31073: + processor_name_string = + AMD Athlon(tm) 64 X2 Dual Core Processor TT50e; + break; /* Socket S1g1 */ case 0x00012: processor_name_string = -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] LAB support for Asus M2V-MX SE
On Thu, 2009-07-16 at 14:45 -0600, Myles Watson wrote: The attached patch enables LAB for this motherboard in coreboot-v2. Should I change the ROM size or leave it as it is? I would leave it as it works for you. Ok, I will. Also, Carl Daniel said something about CONFIG_XIP_ROM_SIZE calculation. Is it ok if I just hardcode it to 64KB? Do you need to change it? It should be set correctly in src/mainboard/.../Options.lb if the board needs something different than the default. Okay, the thing is that the other motherboards I've seen with LAB support do have it defined the same way as I did. I'll see if they are also having the same option duplicated in Options.lb and are just overriding in here. Also, I created a ROM and it seems the image is 64KB smaller than it should (4MB). Does anyone have any idea why could it be like this? Thanks, Cristi -- Ing. Cristi Măgherușan, System/Network Engineer Technical University of Cluj-Napoca, Romania http://cc.utcluj.ro +40264 401247 signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] add pretty cpu name for Athlon X2 5050e
On 16.07.2009 23:29, Ward Vandewege wrote: See attached. I'm not sure if I could predict the IDs for the 4050e/4450e/4850e - anyone know? I only have a 5050e. The doc you're looking for is http://support.amd.com/us/Processor_TechDocs/33610_PUB_Rev3%2042v3.pdf Table 8 should have the info you need. Regards, Carl-Daniel -- http://www.hailfinger.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
RB-C2 probably uses socket type AM3, which is not supported in Coreboot currently. I wonder if your board can go through the whole image. You can contact tim.per...@amd.com about the patch releasing. Zheng -Original Message- From: Ward Vandewege [mailto:w...@gnu.org] Sent: Thursday, July 16, 2009 10:37 PM To: Bao, Zheng Cc: Coreboot Subject: Re: [coreboot] [patch] [AMD Fam10] Fix confused RB-C2 and DA-C2 Hi Zheng, 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. Aha. That would perhaps explain why my box with Quad-Core AMD Opteron(tm) Processor 2372 HE with revision id 0x100f42 really does not like ucode revision 92 (it resets itself constantly). Issues: 1. I really dont know what their nicknames are (Shanghai C2 or something). Don't know about that. 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. Well, I have my box booting without any ucode update. It would be nice to have mc_patch_0186.h public if that's the revision for my cpus. Who do I ask? 3. I haven't made coreboot go thoroughly on this RB-C2. This patch is just half tested. I now have a working tree for Supermicro h8dmr with RB-C2 but it needs a bit more tweaking and cleaning up. I hope to get that ready soon so I can submit the patch to the list. I am not confident it is 100% correct. I'll test tonight or tomorrow and let you know how it goes. Thanks! Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] LAB support for Asus M2V-MX SE
Okay, the thing is that the other motherboards I've seen with LAB support do have it defined the same way as I did. I'll see if they are also having the same option duplicated in Options.lb and are just overriding in here. I did some of that. I didn't understand where to put defaults at the time. Also, I created a ROM and it seems the image is 64KB smaller than it should (4MB). Does anyone have any idea why could it be like this? Sorry I misunderstood. I thought you had a working image. Here's a simple diff from Config.lb that builds a 2 MB image for me. Thanks, Myles mag.diff Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [patch] A bug in AMD fam10 am2r2 module
This is an obvious bug which I overlooked when I worked on the AM2r2
modules.
Zheng
Signed-off-by: Zheng Bao zheng@amd.com
Index: src/northbridge/amd/amdmct/mct/mctardk4.c
===
--- src/northbridge/amd/amdmct/mct/mctardk4.c (revision 4427)
+++ src/northbridge/amd/amdmct/mct/mctardk4.c (working copy)
@@ -121,7 +121,7 @@
*AddrTmgCTL = 0x002F2F00;
else if (Speed == 4)
*AddrTmgCTL = 0x00202520;
- else if (Speed == 4)
+ else if (Speed == 5)
*AddrTmgCTL = 0x002F2020;
else
*AddrTmgCTL = 0x002F2F2F;
@@ -130,7 +130,7 @@
*CMDmode = 2;
*AddrTmgCTL = 0x00202520;
*ODC_CTL = 0x00113222;
- } else if(Speed == 4) {
+ } else if(Speed == 5) {
*CMDmode = 2;
*AddrTmgCTL = 0x002F2020;
*ODC_CTL = 0x00113222;
AMD_fam10_AM2r2_fix_bug.patch
Description: AMD_fam10_AM2r2_fix_bug.patch
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] A bug in AMD fam10 am2r2 module
Acked-by: Ronald G. Minnich rminn...@gmail.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [v2] r4430 - trunk/coreboot-v2/src/northbridge/amd/amdmct/mct
Author: zbao
Date: 2009-07-17 07:41:34 +0200 (Fri, 17 Jul 2009)
New Revision: 4430
Modified:
trunk/coreboot-v2/src/northbridge/amd/amdmct/mct/mctardk4.c
Log:
This is an obvious bug which I overlooked when I worked on the AM2r2
modules.
Signed-off-by: Zheng Bao zheng@amd.com
Acked-by: Ronald G. Minnich rminn...@gmail.com
Modified: trunk/coreboot-v2/src/northbridge/amd/amdmct/mct/mctardk4.c
===
--- trunk/coreboot-v2/src/northbridge/amd/amdmct/mct/mctardk4.c 2009-07-17
04:31:53 UTC (rev 4429)
+++ trunk/coreboot-v2/src/northbridge/amd/amdmct/mct/mctardk4.c 2009-07-17
05:41:34 UTC (rev 4430)
@@ -121,7 +121,7 @@
*AddrTmgCTL = 0x002F2F00;
else if (Speed == 4)
*AddrTmgCTL = 0x00202520;
- else if (Speed == 4)
+ else if (Speed == 5)
*AddrTmgCTL = 0x002F2020;
else
*AddrTmgCTL = 0x002F2F2F;
@@ -130,7 +130,7 @@
*CMDmode = 2;
*AddrTmgCTL = 0x00202520;
*ODC_CTL = 0x00113222;
- } else if(Speed == 4) {
+ } else if(Speed == 5) {
*CMDmode = 2;
*AddrTmgCTL = 0x002F2020;
*ODC_CTL = 0x00113222;
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] A bug in AMD fam10 am2r2 module
Committed, r4430. Zheng -Original Message- From: ron minnich [mailto:rminn...@gmail.com] Sent: Friday, July 17, 2009 1:33 PM To: Bao, Zheng Cc: Coreboot Subject: Re: [coreboot] [patch] A bug in AMD fam10 am2r2 module Acked-by: Ronald G. Minnich rminn...@gmail.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
