From myles at pel.cs.byu.edu Fri Feb 1 01:00:18 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Thu, 31 Jan 2008 17:00:18 -0700 Subject: [coreboot] [LinuxBIOS] Qemu compile for LinuxBIOSV2 In-Reply-To: <4758198C.8020209@sun.com> References: <47506A1F.8070104@sun.com> <20071203181517.GK9493@cosmic.amd.com> <475447C5.7020406@sun.com> <47545F8F.5090003@gmx.net> <47546480.5070509@sun.com> <475467D7.9010504@gmx.net> <4758198C.8020209@sun.com> Message-ID: <2831fecf0801311600s1e7b0780j90e4e431d7133fab@mail.gmail.com> I know this should tell me something more than it does, but I'm hoping it helps someone else. Building v3 and v2 for Qemu fails for me on FC6 with binutils updated to 2.18.50, but succeeds on FC6-64-bit with the same binutils built from source. The error messages are similar Since they're both targeting the same architecture, that struck me as strange. Any suggestions? Thanks, Myles v2's failure: echo '/*ldoptions*/' > ldscript.ld; cat ldoptions >> ldscript.ld ; for file in /home/myles/test/buildrom/buildrom-devel/work/coreboot/svn/src/arch/i386/init/ldscript.lb /home/myles/test/buildrom/buildrom-devel/work/coreboot/svn/src//cpu/x86/16bit/entry16.lds /home/myles/test/buildrom/buildrom-devel/work/coreboot/svn/src//cpu/x86/32bit/entry32.lds /home/myles/test/buildrom/buildrom-devel/work/coreboot/svn/src//cpu/x86/16bit/reset16.lds /home/myles/test/buildrom/buildrom-devel/work/coreboot/svn/src//arch/i386/lib/id.lds ; do echo /\* $file \*/ >> ldscript.ld; cat $file >> ldscript.ld ; done gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o /usr/bin/ld: linuxbios: section `.id' can't be allocated in segment 1 LOAD: .id .reset /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make[2]: *** [linuxbios] Error 1 make[2]: Leaving directory `/home/myles/test/buildrom/buildrom-devel/work/coreboot/svn/targets/emulation/qemu-i386/qemu-i386/image' make[1]: *** [image/linuxbios.rom] Error 1 make[1]: Leaving directory `/home/myles/test/buildrom/buildrom-devel/work/coreboot/svn/targets/emulation/qemu-i386/qemu-i386' v3's failure: make[1]: Entering directory `/home/myles/test/buildrom/buildrom-devel/work/coreboot-v3/svn' CP build/config.h GEN build/build.h CC build/stage0.init /usr/bin/ld: /home/myles/test/buildrom/buildrom-devel/work/coreboot-v3/svn/build/stage0.o: section `.stage0_1' can't be allocated in segment 0 LOAD: .stage0_1 .resetvector /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make[1]: *** [/home/myles/test/buildrom/buildrom-devel/work/coreboot-v3/svn/build/stage0.init] Error 1 make[1]: Leaving directory `/home/myles/test/buildrom/buildrom-devel/work/coreboot-v3/svn' From joe at smittys.pointclark.net Fri Feb 1 02:03:51 2008 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Thu, 31 Jan 2008 20:03:51 -0500 Subject: [coreboot] i82801xx nic problems. In-Reply-To: References: <20080130095008.gfcv3tp68o84gww8@www.smittys.pointclark.net> <20080130231315.25180.qmail@stuge.se> <20080131025251.9rywc04bkkso4oss@www.smittys.pointclark.net> <20080131173425.opf7401bwgossswo@www.smittys.pointclark.net> Message-ID: <20080131200351.ejhum634gck0k0wc@www.smittys.pointclark.net> Quoting Corey Osgood : >> How would do a dump of the nics eeprom in Linux? I'm thinking this is >> where the problem is coming from??? > > Use awarddeco. afaik the site is down, but it must be mirrored somewhere. > Huh? How do I do a register dump of the eeprom with awarddeco? That would be for getting the pci rom. I already have the the pci rom, and an AMI bios not Award. But, that doesn't matter to coreboot because it won't load a pci rom for a device that it can't detect. I wonder if there is a way to load the pci rom before the bus scan. I'm thinking the original bios does that, and the pci rom acually turns on the device and sets up it's registers. Anyone want to take a shot here??? Thanks - Joe From david.hendricks at gmail.com Fri Feb 1 09:06:15 2008 From: david.hendricks at gmail.com (David Hendricks) Date: Fri, 1 Feb 2008 00:06:15 -0800 Subject: [coreboot] [LinuxBIOS] [patch] MSI MS-7135 (this time with attachment) In-Reply-To: <20071207054444.GW2629@kirkkit.kollasch.net> References: <20071207054444.GW2629@kirkkit.kollasch.net> Message-ID: Whoa, I don't know how I let this one slip by... Did you manage to get SATA working, by chance? That was a show stopper for me, but I haven't been able to diagnose it. 2007/12/6 : > Initial support for MSI MS-7135 (K8N Neo3) mainboard. > > Signed-off-by: Jonathan A. Kollasch > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spappola at hotmail.com Fri Feb 1 06:51:26 2008 From: spappola at hotmail.com (Alessandro Rossi) Date: Fri, 1 Feb 2008 05:51:26 +0000 Subject: [coreboot] coreboot on supermicro X5DPR-8G2+ ? Message-ID: Hi all, I would like to know if it will be possibile to use coreboot on Supermicro X5FPR-8G2+ motherboard. On-Board Devices Chipset ? Intel? E7501 chipset ? MCH + ICH3-S + P64H2 more specification here : http://www.supermicro.com/products/motherboard/Xeon/E7501/X5DPR-8G2+.cfm Since I'm new to coreboot how could I test it ? Regards Alessandro _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakllsch at kollasch.net Fri Feb 1 17:36:26 2008 From: jakllsch at kollasch.net (jakllsch at kollasch.net) Date: Fri, 1 Feb 2008 10:36:26 -0600 Subject: [coreboot] [LinuxBIOS] [patch] MSI MS-7135 (this time with attachment) In-Reply-To: References: <20071207054444.GW2629@kirkkit.kollasch.net> Message-ID: <20080201163626.GA1756@kirkkit.kollasch.net> On Fri, Feb 01, 2008 at 12:06:15AM -0800, David Hendricks wrote: > Whoa, I don't know how I let this one slip by... Did you manage to get SATA > working, by chance? That was a show stopper for me, but I haven't been able > to diagnose it. I did not get the second set of two SATA ports working, but I did get the first set working. Also, I didn't get the audio to work. Sure, I could spend centuries twiddling the PCI Configuration Space, but that doesn't seem like my idea of fun. Reading publicly available documentation seems like a lot more fun. ;-) So, basically, I'm saying it's beyond my power to fix. Unless NVIDIA is going to have a change of heart on Valentines Day. But I'm not holding my breath. Sigh. > 2007/12/6 : > > > Initial support for MSI MS-7135 (K8N Neo3) mainboard. > > > > Signed-off-by: Jonathan A. Kollasch Jonathan Kollasch -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ward at gnu.org Fri Feb 1 18:03:42 2008 From: ward at gnu.org (Ward Vandewege) Date: Fri, 1 Feb 2008 12:03:42 -0500 Subject: [coreboot] [LinuxBIOS] [patch] MSI MS-7135 (this time with attachment) In-Reply-To: <20080201163626.GA1756@kirkkit.kollasch.net> References: <20071207054444.GW2629@kirkkit.kollasch.net> <20080201163626.GA1756@kirkkit.kollasch.net> Message-ID: <20080201170342.GA15310@localdomain> On Fri, Feb 01, 2008 at 10:36:26AM -0600, jakllsch at kollasch.net wrote: > On Fri, Feb 01, 2008 at 12:06:15AM -0800, David Hendricks wrote: > > Whoa, I don't know how I let this one slip by... Did you manage to get SATA > > working, by chance? That was a show stopper for me, but I haven't been able > > to diagnose it. > > I did not get the second set of two SATA ports working, but I did > get the first set working. Also, I didn't get the audio to work. Aha. This is another example of the ck804 sata issues. You may want to have a look at this ftp://ftp.lnxi.com/pub/linuxbios/h8dce/SOURCE That's another ck804-based board, and I suspect that all sata ports on both controllers work there. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From wrightjmf at gmail.com Fri Feb 1 19:47:28 2008 From: wrightjmf at gmail.com (Jeremy Wright) Date: Fri, 1 Feb 2008 18:47:28 +0000 Subject: [coreboot] Capio II 320 and Coreboot Message-ID: Hi, I'm new to Coreboot, but I've been able to get a BIOS burned and sort of working. I'm working with a Capio II 320 (see specs below) and I've tried using the "Axus TC320" and "ASI MB-5BLMP" build tutorials since the CPU and chipsets are so similar. I've also tried using Etherboot and FILO as the payloads with the same results. The ASI tutorial starts up and initializes the network interface, but I never get any video. With the Axus TC320 tutorial, I get video, the network interface is initialized, and I get a splash screen, but that's where it stops. When using Etherboot I can see that the Capio starts to boot from my network boot server and then stops. Is there a way I can get console output with the Axus TC320 setup? If I could see what's going on I might be able to fix it. Any help will be greatly appreciated. Boundless (Neoware) Capio II 320 Cyrix MediaGXm 233MHz Geode CS5530 companion device Intel 82559ER Network Interface 48MB DiskOnChip 32MB SDRAM DIMM Thanks, Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Fri Feb 1 19:59:59 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 1 Feb 2008 10:59:59 -0800 Subject: [coreboot] Capio II 320 and Coreboot In-Reply-To: References: Message-ID: <13426df10802011059sf8e3f99j25749f957e07af83@mail.gmail.com> Have you set up serial console? Or is that your question? ron From wrightjmf at gmail.com Fri Feb 1 20:11:40 2008 From: wrightjmf at gmail.com (Jeremy Wright) Date: Fri, 1 Feb 2008 19:11:40 +0000 Subject: [coreboot] Capio II 320 and Coreboot In-Reply-To: <13426df10802011059sf8e3f99j25749f957e07af83@mail.gmail.com> References: <13426df10802011059sf8e3f99j25749f957e07af83@mail.gmail.com> Message-ID: No, I haven't set up serial console. Is there documentation on how to do that? I wasn't sure what the next step should be since I'm so unfamiliar with Coreboot. Thanks. On Feb 1, 2008 6:59 PM, ron minnich wrote: > Have you set up serial console? Or is that your question? > > ron > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Fri Feb 1 20:15:09 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 1 Feb 2008 11:15:09 -0800 Subject: [coreboot] Capio II 320 and Coreboot In-Reply-To: References: <13426df10802011059sf8e3f99j25749f957e07af83@mail.gmail.com> Message-ID: <13426df10802011115y47de664fo57fcede4b1f3fd3@mail.gmail.com> I am pretty sure one or both of those targets has serial console enabled. The next thing to do is boot standard bios on that board, with linux, hook up serial to a box you know works, run minicom on each end, and just verify that serial works at all. Then we can talk about coreboot serial :-) ron From rminnich at gmail.com Fri Feb 1 20:28:30 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 1 Feb 2008 11:28:30 -0800 Subject: [coreboot] PATCH: lx loads payload again, with new vsa, proper PCI bus scan etc. Message-ID: <13426df10802011128g38532556x6883d956cd096c49@mail.gmail.com> With this set of changes, the lx target loads VSA and configures the PCI bus, with VSA operating correctly. This is tested with AMD's recently released new-model VSA code. Note that v3 build is correctly compressing the uncompressed vsa payload. I am really happy with v3 so far. Signed-off-by: Ronald G. Minnich Sadly, the first jump to payload crashes and burns. Marc, can you check this with fs2 for me? I still have not found mine ... PS: PLEASE, if you are going to the coreboot summit April 3-5, register at hpcsw.org. You can get good rates at the hotel through april 6 even. I am staying there through sunday. thanks ron -------------- next part -------------- A non-text attachment was scrubbed... Name: lxloadspayload.diff Type: text/x-patch Size: 7912 bytes Desc: not available URL: From wrightjmf at gmail.com Fri Feb 1 20:32:36 2008 From: wrightjmf at gmail.com (Jeremy Wright) Date: Fri, 1 Feb 2008 19:32:36 +0000 Subject: [coreboot] Capio II 320 and Coreboot In-Reply-To: <13426df10802011115y47de664fo57fcede4b1f3fd3@mail.gmail.com> References: <13426df10802011059sf8e3f99j25749f957e07af83@mail.gmail.com> <13426df10802011115y47de664fo57fcede4b1f3fd3@mail.gmail.com> Message-ID: I can't run Linux on the Capios because they don't have any external drive access, and the only thing that they will boot off of is the DiskOnChip which has Windows CE on it (which wants to see a Windows Terminal Server). One of the reasons that I am trying Coreboot is to get to where I can reprogram the DOC to put Linux on it. So, I'm stuck on testing serial communications with minicom on the Capio end. Any ideas? Thanks. On Feb 1, 2008 7:15 PM, ron minnich wrote: > I am pretty sure one or both of those targets has serial console > enabled. The next thing to do is boot standard bios on that board, > with linux, hook up serial to a box you know works, run minicom on > each end, and just verify that serial works at all. > > Then we can talk about coreboot serial :-) > > ron > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Fri Feb 1 20:35:40 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 1 Feb 2008 11:35:40 -0800 Subject: [coreboot] Capio II 320 and Coreboot In-Reply-To: References: <13426df10802011059sf8e3f99j25749f957e07af83@mail.gmail.com> <13426df10802011115y47de664fo57fcede4b1f3fd3@mail.gmail.com> Message-ID: <13426df10802011135l7c18edf3r7444292c6e6c2071@mail.gmail.com> can you get kermit or some other terminal emulator for windows CE? just to test? ron From wrightjmf at gmail.com Fri Feb 1 20:39:58 2008 From: wrightjmf at gmail.com (Jeremy Wright) Date: Fri, 1 Feb 2008 19:39:58 +0000 Subject: [coreboot] Capio II 320 and Coreboot In-Reply-To: <13426df10802011135l7c18edf3r7444292c6e6c2071@mail.gmail.com> References: <13426df10802011059sf8e3f99j25749f957e07af83@mail.gmail.com> <13426df10802011115y47de664fo57fcede4b1f3fd3@mail.gmail.com> <13426df10802011135l7c18edf3r7444292c6e6c2071@mail.gmail.com> Message-ID: I'll try to set up a termporary terminal server with Windows XP and see if I can get to the point where I can try kermit or something similar. On Feb 1, 2008 7:35 PM, ron minnich wrote: > can you get kermit or some other terminal emulator for windows CE? > > just to test? > > ron > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ward at gnu.org Fri Feb 1 20:59:46 2008 From: ward at gnu.org (Ward Vandewege) Date: Fri, 1 Feb 2008 14:59:46 -0500 Subject: [coreboot] coreboot summit april 3-5: hotel room share? Message-ID: <20080201195946.GA17762@localdomain> http://www.hpcsw.org/hotel.shtml The rate for single occupancy is $158/night; double occupancy is $183/night. Anyone interested in saving money and sharing a double occupancy room? Ron assured me that the double occupancy rooms have 2 beds. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From jakllsch at kollasch.net Fri Feb 1 21:01:13 2008 From: jakllsch at kollasch.net (jakllsch at kollasch.net) Date: Fri, 1 Feb 2008 14:01:13 -0600 Subject: [coreboot] CK804 interrupt steering - SATA fix Message-ID: <20080201200113.GB1756@kirkkit.kollasch.net> Hi, I've reverse engineered some registers in the CK804. I believe with this information all SATA ports can be enabled without any lost interrupts. More on fixing the SATA issue later on, now what I've found. ---- LPC bridge PCI config registers: 0x7c:0x0000ffff - bitmap of masked pci irqs? - PIRQ[ABCD] possibly? 0x7c:0x00f00000 - sata at f8 - port 1 0x7c:0x0f000000 - sata at f7 - port 1 0x80:0xf0000000 - sata at f7 - port 0 0x80:0x0f000000 - sata at f8 - port 0 0x80:0x0000f000 - EHCI 0x84:0x00000f00 - NIC 0x84:0x0000000f - OHCI known values of nibbles: 0 - unrouted? 1 - irq 23 8 - irq 20 c - irq 12 d - irq 21 e - irq 14 f - irq 15 ----- When the interrupts of both SATA ports on each controller are routed the same, the regular drivers should work. I've only tested this with NetBSD's viaide(4), I have no idea if these may also apply to the ADMA mode. On many boards these registers are set in mptable.c. I hope someone can make good use of this. Jonathan Kollasch -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rminnich at gmail.com Fri Feb 1 21:08:29 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 1 Feb 2008 12:08:29 -0800 Subject: [coreboot] [LinuxBIOS] flashrom on ga 2761gxdk In-Reply-To: <4798D178.7050204@gmx.net> References: <13426df10801082236o6974bc7agf705b168fa322941@mail.gmail.com> <4785572C.2070708@gmx.net> <13426df10801092016o3b47fd9bl76887c70549c75b3@mail.gmail.com> <47860BC1.8050002@gmx.net> <47861062.3020909@gmx.net> <4796198A.8050406@gmx.net> <13426df10801220837m77f7d0cfv7c1a9d8d1cce5ab5@mail.gmail.com> <47961F17.3020204@gmx.net> <13426df10801222025o4e6b5f8rafd500a841a633e9@mail.gmail.com> <4798D178.7050204@gmx.net> Message-ID: <13426df10802011208o7e700249r3268e3e7692e40be@mail.gmail.com> OK here goes. Attached is: my current svn diff the 016 part, verbose the 004 part, verbose. I tried two different 16 mbit parts and both fail. I don't think the parts are dead. any help appreciated, I'm puzzled. Today is my dedicated coreboot day so I can try anything here. thanks ron -------------- next part -------------- A non-text attachment was scrubbed... Name: 16 Type: application/octet-stream Size: 6787 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 4 Type: application/octet-stream Size: 1839 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: f.diff Type: text/x-patch Size: 922 bytes Desc: not available URL: From c-d.hailfinger.devel.2006 at gmx.net Fri Feb 1 21:11:21 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 01 Feb 2008 21:11:21 +0100 Subject: [coreboot] PATCH: lx loads payload again, with new vsa, proper PCI bus scan etc. In-Reply-To: <13426df10802011128g38532556x6883d956cd096c49@mail.gmail.com> References: <13426df10802011128g38532556x6883d956cd096c49@mail.gmail.com> Message-ID: <47A37CE9.2020007@gmx.net> On 01.02.2008 20:28, ron minnich wrote: > With this set of changes, the lx target loads VSA and configures the PCI bus, > with VSA operating correctly. This is tested with AMD's recently released > new-model VSA code. Note that v3 build is correctly compressing the uncompressed > vsa payload. I am really happy with v3 so far. > > Signed-off-by: Ronald G. Minnich > That's great! Acked-by: Carl-Daniel Hailfinger This passed my compile tests for all targets except the artec dbe61, which has been broken for a long time anyway. A few minor comments. It would be great if you could address them before committing. northbridge/amd/geodelx/domain is a copy of northbridge/amd/geodelx/dts. You probably want to use "svn mv" for that because it preserves history and the old file was probably intended to have been moved, not copied. northbridge/amd/geodelx/vsmsetup.c:247: warning: ?biosint? defined but not used Since the new VSA does not use BIOSINT services anymore, deleting biosint and related functions from vsmsetup.c would shrink vsmsetup.c by one fourth. Patch follows (could you merge it into your patch?): Signed-off-by: Carl-Daniel Hailfinger Index: northbridge/amd/geodelx/vsmsetup.c =================================================================== --- northbridge/amd/geodelx/vsmsetup.c (Revision 570) +++ northbridge/amd/geodelx/vsmsetup.c (Arbeitskopie) @@ -227,83 +227,3 @@ MEMSIZE = 0x12 }; -int pcibios(unsigned long *pedi, unsigned long *pesi, unsigned long *pebp, - unsigned long *pesp, unsigned long *pebx, unsigned long *pedx, - unsigned long *pecx, unsigned long *peax, unsigned long *pflags); - -int handleint21(unsigned long *pedi, unsigned long *pesi, unsigned long *pebp, - unsigned long *pesp, unsigned long *pebx, unsigned long *pedx, - unsigned long *pecx, unsigned long *peax, - unsigned long *pflags); - -/* see the vga_exit() call. until we clean this up this function will remain here */ -static int biosint(unsigned long intnumber, - unsigned long gsfs, unsigned long dses, - unsigned long edi, unsigned long esi, - unsigned long ebp, unsigned long esp, - unsigned long ebx, unsigned long edx, - unsigned long ecx, unsigned long eax, - unsigned long cs_ip, unsigned short stackflags) -{ - unsigned long ip; - unsigned long cs; - unsigned long flags; - int ret = -1; - - ip = cs_ip & 0xffff; - cs = cs_ip >> 16; - flags = stackflags; - - printk(BIOS_DEBUG, "biosint: INT# 0x%lx\n", intnumber); - printk(BIOS_DEBUG, "biosint: eax 0x%lx ebx 0x%lx ecx 0x%lx edx 0x%lx\n", - eax, ebx, ecx, edx); - printk(BIOS_DEBUG, "biosint: ebp 0x%lx esp 0x%lx edi 0x%lx esi 0x%lx\n", - ebp, esp, edi, esi); - printk(BIOS_DEBUG, "biosint: ip 0x%lx cs 0x%lx flags 0x%lx\n", - ip, cs, flags); - printk(BIOS_DEBUG, "biosint: gs 0x%lx fs 0x%lx ds 0x%lx es 0x%lx\n", - gsfs >> 16, gsfs & 0xffff, dses >> 16, dses & 0xffff); - - // cases in a good compiler are just as good as your own tables. - switch (intnumber) { - case 0 ... 15: - // These are not BIOS service, but the CPU-generated exceptions - printk(BIOS_INFO, "biosint: Oops, exception %lu\n", intnumber); - if (esp < 0x1000) { - printk(BIOS_DEBUG, "Stack contents: "); - while (esp < 0x1000) { - printk(BIOS_DEBUG, "0x%04x ", *(unsigned short *)esp); - esp += 2; - } - printk(BIOS_DEBUG, "\n"); - } - printk(BIOS_DEBUG, "biosint: Bailing out ... not now\n"); - // "longjmp" - //vga_exit(); - break; - - case PCIBIOS: - ret = pcibios(&edi, &esi, &ebp, &esp, - &ebx, &edx, &ecx, &eax, &flags); - break; - case MEMSIZE: - // who cares. - eax = 128 * 1024; - ret = 0; - break; - case 0x15: - ret = handleint21(&edi, &esi, &ebp, &esp, - &ebx, &edx, &ecx, &eax, &flags); - break; - default: - printk(BIOS_INFO, "BIOSINT: Unsupport int #0x%lx\n", intnumber); - break; - } - if (ret) - flags |= 1; // carry flags - else - flags &= ~1; - stackflags = flags; - return ret; -} - From techie at whiterocker.com Fri Feb 1 21:12:27 2008 From: techie at whiterocker.com (Chris Kilgour) Date: Fri, 01 Feb 2008 12:12:27 -0800 Subject: [coreboot] Geode LX/CS5536 VSA In-Reply-To: <47A1FF9C.2040700@amd.com> References: <47A1FF9C.2040700@amd.com> Message-ID: <47A37D2B.5010208@whiterocker.com> Marc Jones wrote: > The following changes were made: > Remove int15 callbacks removed. CPU and memory are calculated by VSA. > VSA no longer takes all the MFGPTs. Two are now available for OS use. > I have "ported" the previous VSA sources from the OLPC git tree, so that it builds under GNU tools. It is completely untested, but I plan to start testing it any time now. It has never been released. I would appreciate any comments from the list on: 1. hosting these VSA sources. Would coreboot.org be a good place to keep the GNU-ified VSA sources? 2. the idea of permanently moving to a GNU-buildable version? 3. anyone interesting in helping to test the "port"? I also want to patch my "port" based on the newer sources you provided Marc. In looking at the diff's against the OLPC git, I see there are about 42 files with mostly-minor code changes, about 26 files removed. It should be easy to handle the patching, so I am inclined to do that before releasing and testing. One thing I'm wondering about: there are about 65 files that have no changes except the copyright notice was updated to 2008. Was that intended? Chris. From c-d.hailfinger.devel.2006 at gmx.net Fri Feb 1 21:22:59 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 01 Feb 2008 21:22:59 +0100 Subject: [coreboot] Geode LX/CS5536 VSA In-Reply-To: <47A37D2B.5010208@whiterocker.com> References: <47A1FF9C.2040700@amd.com> <47A37D2B.5010208@whiterocker.com> Message-ID: <47A37FA3.4000505@gmx.net> Hi Chris! First of all, welcome on board! On 01.02.2008 21:12, Chris Kilgour wrote: > Marc Jones wrote: > >> The following changes were made: >> Remove int15 callbacks removed. CPU and memory are calculated by VSA. >> VSA no longer takes all the MFGPTs. Two are now available for OS use. >> > > I have "ported" the previous VSA sources from the OLPC git tree, so that > it builds under GNU tools. It is completely untested, but I plan to > start testing it any time now. It has never been released. > Great, thanks! > I would appreciate any comments from the list on: > 1. hosting these VSA sources. Would coreboot.org be a good place to > keep the GNU-ified VSA sources? > Probably yes. The laptop.org GIT tree only has 2 revisions. Such an amount of change could easily be handled with subversion and coreboot.org surely could handle that. The final decision is made by Stefan, though. > 2. the idea of permanently moving to a GNU-buildable version? > It would certainly make outside contributions easier. > 3. anyone interesting in helping to test the "port"? > I'm pretty sure AMD is interested, although those people working on Geode targets for coreboot will want to test as well. The ability to tailor the VSA to do exactly the things we need and skip the rest is a really exciting prospect. > I also want to patch my "port" based on the newer sources you provided > Marc. In looking at the diff's against the OLPC git, I see there are > about 42 files with mostly-minor code changes, about 26 files removed. > It should be easy to handle the patching, so I am inclined to do that > before releasing and testing. > Please do. Regards, Carl-Daniel From svn at coreboot.org Fri Feb 1 21:35:53 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Fri, 1 Feb 2008 21:35:53 +0100 Subject: [coreboot] r571 - in coreboot-v3: device mainboard/pcengines/alix1c northbridge/amd/geodelx util/dtc Message-ID: Author: rminnich Date: 2008-02-01 21:35:53 +0100 (Fri, 01 Feb 2008) New Revision: 571 Added: coreboot-v3/northbridge/amd/geodelx/apic coreboot-v3/northbridge/amd/geodelx/domain coreboot-v3/northbridge/amd/geodelx/pci Removed: coreboot-v3/northbridge/amd/geodelx/dts Modified: coreboot-v3/device/device.c coreboot-v3/device/pci_device.c coreboot-v3/mainboard/pcengines/alix1c/dts coreboot-v3/northbridge/amd/geodelx/geodelx.c coreboot-v3/northbridge/amd/geodelx/vsmsetup.c coreboot-v3/util/dtc/flattree.c Log: with VSA operating correctly. This is tested with AMD's recently released new-model VSA code. Changes: Index: util/dtc/flattree.c Add an ID entry for apic properties. Index: northbridge/amd/geodelx/apic This is a new dts for the northbridge used as an APIC. Index: northbridge/amd/geodelx/pci This is a new dts for the northbridge used as a PCI device. Index: northbridge/amd/geodelx/geodelx.c Fix a non-obvious bug: we had set phase3 scan bus for both the domain AND the PCI device, which is a mistake: can't scan from the PCI device too. Index: northbridge/amd/geodelx/domain This is a new dts for the northbridge used as an pci domain. Created via svn move dts domain Index: device/pci_device.c If there are leftover devices, it is now a warning, not an error, since there are some no-pci devices in the tree now. For future: only complain about leftover PCI devices ... Index: device/device.c make devcnt a global and initialize it in init_dev. Add a debug printk. Index: mainboard/pcengines/alix1c/dts Add an 'apic' entry for the mainboard. This actually looks pretty clean to me, the way it went in. Index: northbridge/amd/geodelx/vsmsetup.c Delete all pcibios int support, no longer needed for VSA. Please note that this patch includes Carl-Daniel's improvements below, which I have Ack-ed. Signed-off-by: Ronald G. Minnich A few minor comments. It would be great if you could address them before committing. northbridge/amd/geodelx/domain is a copy of northbridge/amd/geodelx/dts. You probably want to use "svn mv" for that because it preserves history and the old file was probably intended to have been moved, not copied. northbridge/amd/geodelx/vsmsetup.c:247: warning: ?\226?\128?\152biosint?\226?\128?\153 defined but not used Since the new VSA does not use BIOSINT services anymore, deleting biosint and related functions from vsmsetup.c would shrink vsmsetup.c by one fourth. Patch follows (could you merge it into your patch?): Signed-off-by: Carl-Daniel Hailfinger Acked-by: Ronald G. Minnich Modified: coreboot-v3/device/device.c =================================================================== --- coreboot-v3/device/device.c 2008-01-31 14:01:23 UTC (rev 570) +++ coreboot-v3/device/device.c 2008-02-01 20:35:53 UTC (rev 571) @@ -67,6 +67,12 @@ static struct device devs[MAX_DEVICES]; /** + * the number of devices that have been allocated + */ +static int devcnt; + + +/** * The device creator. * * reserves a piece of memory for a device in the tree @@ -76,9 +82,9 @@ static struct device *new_device(void) { - static int devcnt=0; devcnt++; + printk(BIOS_SPEW, "%s: devcnt %d\n", __FUNCTION__, devcnt); /* Should we really die here? */ if (devcnt>=MAX_DEVICES) { die("Too many devices. Increase MAX_DEVICES\n"); @@ -155,6 +161,7 @@ dev->ops = c->ops; last_dev_p = &dev->next; } + devcnt = 0; } /** Modified: coreboot-v3/device/pci_device.c =================================================================== --- coreboot-v3/device/pci_device.c 2008-01-31 14:01:23 UTC (rev 570) +++ coreboot-v3/device/pci_device.c 2008-02-01 20:35:53 UTC (rev 571) @@ -1136,9 +1136,9 @@ if (old_devices) { struct device *left; for (left = old_devices; left; left = left->sibling) { - printk(BIOS_ERR, "%s\n", dev_path(left)); + printk(BIOS_SPEW, "%s\n", left->dtsname); } - die("PCI: Left over static devices.\n"); + banner(BIOS_SPEW, "PCI: Left over static devices.\n"); } /* For all children that implement scan_bus() (i.e. bridges) Modified: coreboot-v3/mainboard/pcengines/alix1c/dts =================================================================== --- coreboot-v3/mainboard/pcengines/alix1c/dts 2008-01-31 14:01:23 UTC (rev 570) +++ coreboot-v3/mainboard/pcengines/alix1c/dts 2008-02-01 20:35:53 UTC (rev 571) @@ -25,11 +25,16 @@ cpus { enabled; }; + apic { + /config/("northbridge/amd/geodelx/apic"); + enabled; + }; domain0 { - /config/("northbridge/amd/geodelx/dts"); + /config/("northbridge/amd/geodelx/domain"); enabled; pcidomain = "0"; device0,0 { + /config/("northbridge/amd/geodelx/pci"); enabled; pcipath = "1,0"; }; Added: coreboot-v3/northbridge/amd/geodelx/apic =================================================================== --- coreboot-v3/northbridge/amd/geodelx/apic (rev 0) +++ coreboot-v3/northbridge/amd/geodelx/apic 2008-02-01 20:35:53 UTC (rev 571) @@ -0,0 +1,25 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2008 Ronald G. Minnich + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +{ + constructor = "geodelx_north_constructors"; + apicid = "PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_LXBRIDGE"; +}; + Copied: coreboot-v3/northbridge/amd/geodelx/domain (from rev 570, coreboot-v3/northbridge/amd/geodelx/dts) =================================================================== --- coreboot-v3/northbridge/amd/geodelx/domain (rev 0) +++ coreboot-v3/northbridge/amd/geodelx/domain 2008-02-01 20:35:53 UTC (rev 571) @@ -0,0 +1,25 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2008 Ronald G. Minnich + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +{ + constructor = "geodelx_north_constructors"; + domainid = "PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_LXBRIDGE"; +}; + Deleted: coreboot-v3/northbridge/amd/geodelx/dts =================================================================== --- coreboot-v3/northbridge/amd/geodelx/dts 2008-01-31 14:01:23 UTC (rev 570) +++ coreboot-v3/northbridge/amd/geodelx/dts 2008-02-01 20:35:53 UTC (rev 571) @@ -1,25 +0,0 @@ -/* - * This file is part of the coreboot project. - * - * Copyright (C) 2008 Ronald G. Minnich - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA - */ - -{ - constructor = "geodelx_north_constructors"; - domainid = "PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_LXBRIDGE"; -}; - Modified: coreboot-v3/northbridge/amd/geodelx/geodelx.c =================================================================== --- coreboot-v3/northbridge/amd/geodelx/geodelx.c 2008-01-31 14:01:23 UTC (rev 570) +++ coreboot-v3/northbridge/amd/geodelx/geodelx.c 2008-02-01 20:35:53 UTC (rev 571) @@ -380,9 +380,12 @@ }; /** Operations for when the northbridge is running a PCI device. */ +/** Note that phase3 scan is done in the domain, + * and MUST NOT be done here too + */ static struct device_operations geodelx_pci_ops = { .constructor = default_device_constructor, - .phase3_scan = pci_domain_scan_bus, + .phase3_scan = 0, .phase4_read_resources = pci_domain_read_resources, .phase4_set_resources = geodelx_northbridge_set_resources, .phase5_enable_resources = enable_childrens_resources, Added: coreboot-v3/northbridge/amd/geodelx/pci =================================================================== --- coreboot-v3/northbridge/amd/geodelx/pci (rev 0) +++ coreboot-v3/northbridge/amd/geodelx/pci 2008-02-01 20:35:53 UTC (rev 571) @@ -0,0 +1,25 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2008 Ronald G. Minnich + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +{ + constructor = "geodelx_north_constructors"; + pciid = "PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_LXBRIDGE"; +}; + Modified: coreboot-v3/northbridge/amd/geodelx/vsmsetup.c =================================================================== --- coreboot-v3/northbridge/amd/geodelx/vsmsetup.c 2008-01-31 14:01:23 UTC (rev 570) +++ coreboot-v3/northbridge/amd/geodelx/vsmsetup.c 2008-02-01 20:35:53 UTC (rev 571) @@ -222,88 +222,3 @@ "do_vsmbios: VSA2 VR signature not valid, install failed!\n"); } -enum { - PCIBIOS = 0x1a, - MEMSIZE = 0x12 -}; - -int pcibios(unsigned long *pedi, unsigned long *pesi, unsigned long *pebp, - unsigned long *pesp, unsigned long *pebx, unsigned long *pedx, - unsigned long *pecx, unsigned long *peax, unsigned long *pflags); - -int handleint21(unsigned long *pedi, unsigned long *pesi, unsigned long *pebp, - unsigned long *pesp, unsigned long *pebx, unsigned long *pedx, - unsigned long *pecx, unsigned long *peax, - unsigned long *pflags); - -/* see the vga_exit() call. until we clean this up this function will remain here */ -static int biosint(unsigned long intnumber, - unsigned long gsfs, unsigned long dses, - unsigned long edi, unsigned long esi, - unsigned long ebp, unsigned long esp, - unsigned long ebx, unsigned long edx, - unsigned long ecx, unsigned long eax, - unsigned long cs_ip, unsigned short stackflags) -{ - unsigned long ip; - unsigned long cs; - unsigned long flags; - int ret = -1; - - ip = cs_ip & 0xffff; - cs = cs_ip >> 16; - flags = stackflags; - - printk(BIOS_DEBUG, "biosint: INT# 0x%lx\n", intnumber); - printk(BIOS_DEBUG, "biosint: eax 0x%lx ebx 0x%lx ecx 0x%lx edx 0x%lx\n", - eax, ebx, ecx, edx); - printk(BIOS_DEBUG, "biosint: ebp 0x%lx esp 0x%lx edi 0x%lx esi 0x%lx\n", - ebp, esp, edi, esi); - printk(BIOS_DEBUG, "biosint: ip 0x%lx cs 0x%lx flags 0x%lx\n", - ip, cs, flags); - printk(BIOS_DEBUG, "biosint: gs 0x%lx fs 0x%lx ds 0x%lx es 0x%lx\n", - gsfs >> 16, gsfs & 0xffff, dses >> 16, dses & 0xffff); - - // cases in a good compiler are just as good as your own tables. - switch (intnumber) { - case 0 ... 15: - // These are not BIOS service, but the CPU-generated exceptions - printk(BIOS_INFO, "biosint: Oops, exception %lu\n", intnumber); - if (esp < 0x1000) { - printk(BIOS_DEBUG, "Stack contents: "); - while (esp < 0x1000) { - printk(BIOS_DEBUG, "0x%04x ", *(unsigned short *)esp); - esp += 2; - } - printk(BIOS_DEBUG, "\n"); - } - printk(BIOS_DEBUG, "biosint: Bailing out ... not now\n"); - // "longjmp" - //vga_exit(); - break; - - case PCIBIOS: - ret = pcibios(&edi, &esi, &ebp, &esp, - &ebx, &edx, &ecx, &eax, &flags); - break; - case MEMSIZE: - // who cares. - eax = 128 * 1024; - ret = 0; - break; - case 0x15: - ret = handleint21(&edi, &esi, &ebp, &esp, - &ebx, &edx, &ecx, &eax, &flags); - break; - default: - printk(BIOS_INFO, "BIOSINT: Unsupport int #0x%lx\n", intnumber); - break; - } - if (ret) - flags |= 1; // carry flags - else - flags &= ~1; - stackflags = flags; - return ret; -} - Modified: coreboot-v3/util/dtc/flattree.c =================================================================== --- coreboot-v3/util/dtc/flattree.c 2008-01-31 14:01:23 UTC (rev 570) +++ coreboot-v3/util/dtc/flattree.c 2008-02-01 20:35:53 UTC (rev 571) @@ -551,6 +551,10 @@ fprintf(f, "\t.id = {.type=DEVICE_ID_PCI,.u={.pci={ %s }}},\n", prop->val.val); } + if (streq(prop->name, "apicid")){ + fprintf(f, "\t.id = {.type=DEVICE_ID_APIC,.u={.pci={ %s }}},\n", + prop->val.val); + } } } /* Process the properties specified in the mainboard dts. From rminnich at gmail.com Fri Feb 1 21:36:33 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 1 Feb 2008 12:36:33 -0800 Subject: [coreboot] PATCH: lx loads payload again, with new vsa, proper PCI bus scan etc. In-Reply-To: <47A37CE9.2020007@gmx.net> References: <13426df10802011128g38532556x6883d956cd096c49@mail.gmail.com> <47A37CE9.2020007@gmx.net> Message-ID: <13426df10802011236q7bd5e4d7v78357e293f73d2c0@mail.gmail.com> Committed revision 571. I included your svn mv suggestion, and have also removed the pci biosint support in vsmsetup.c Thanks ron From c-d.hailfinger.devel.2006 at gmx.net Fri Feb 1 21:51:54 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 01 Feb 2008 21:51:54 +0100 Subject: [coreboot] PATCH: lx loads payload again, with new vsa, proper PCI bus scan etc. In-Reply-To: <13426df10802011236q7bd5e4d7v78357e293f73d2c0@mail.gmail.com> References: <13426df10802011128g38532556x6883d956cd096c49@mail.gmail.com> <47A37CE9.2020007@gmx.net> <13426df10802011236q7bd5e4d7v78357e293f73d2c0@mail.gmail.com> Message-ID: <47A3866A.7090407@gmx.net> On 01.02.2008 21:36, ron minnich wrote: > Committed revision 571. > > I included your svn mv suggestion, and have also removed the pci > biosint support in vsmsetup.c > Thanks, great! Regards, Carl-Daniel From svn at coreboot.org Fri Feb 1 21:59:17 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Fri, 1 Feb 2008 21:59:17 +0100 Subject: [coreboot] r103 - buildrom-devel/packages/filo Message-ID: Author: ward Date: 2008-02-01 21:59:17 +0100 (Fri, 01 Feb 2008) New Revision: 103 Modified: buildrom-devel/packages/filo/filo.mk Log: Fixed a broken check for the M57SLI board (the config variable name changed a long time ago). This re-introduces the 5 second filo sata spinup delay in filo, which allows for cold booting. Without it, the sata drive(s) are not spun up by the time FILO tries to access them, which means only warm boots worked. This is a trivial patch. Signed-off-by: Ward Vandewege Acked-by: Ward Vandewege Modified: buildrom-devel/packages/filo/filo.mk =================================================================== --- buildrom-devel/packages/filo/filo.mk 2008-01-30 23:27:53 UTC (rev 102) +++ buildrom-devel/packages/filo/filo.mk 2008-02-01 20:59:17 UTC (rev 103) @@ -8,7 +8,7 @@ FILO_PATCHES=$(PACKAGE_DIR)/filo/patches/make.patch -ifeq ($(CONFIG_PLATFORM_M57SLI),y) +ifeq ($(CONFIG_PLATFORM_GA_M57SLI_S4),y) FILO_PATCHES += $(PACKAGE_DIR)/filo/patches/sata-spinup-delay.patch endif From marc.jones at amd.com Fri Feb 1 22:03:42 2008 From: marc.jones at amd.com (Marc Jones) Date: Fri, 01 Feb 2008 14:03:42 -0700 Subject: [coreboot] Geode LX/CS5536 VSA In-Reply-To: <47A37D2B.5010208@whiterocker.com> References: <47A1FF9C.2040700@amd.com> <47A37D2B.5010208@whiterocker.com> Message-ID: <47A3892E.5070207@amd.com> Hi Chris, Chris Kilgour wrote: > Marc Jones wrote: >> The following changes were made: >> Remove int15 callbacks removed. CPU and memory are calculated by VSA. >> VSA no longer takes all the MFGPTs. Two are now available for OS use. >> > > I have "ported" the previous VSA sources from the OLPC git tree, so that > it builds under GNU tools. It is completely untested, but I plan to > start testing it any time now. It has never been released. > This is great. We had hoped that someone in the community would do this. > I would appreciate any comments from the list on: > 1. hosting these VSA sources. Would coreboot.org be a good place to > keep the GNU-ified VSA sources? I think that makes sense since coreboot is the project that VSA is most closely associated with. > 2. the idea of permanently moving to a GNU-buildable version? Yes! We would love to have more people working on this code and making it better. I am sure the size can be reduced even more. This would help it fit into the rom and take up less system memory. Both would be great helps to embedded LX designs. > 3. anyone interesting in helping to test the "port"? I think we should be able to get a few people to test the port, myself included. > I also want to patch my "port" based on the newer sources you provided > Marc. In looking at the diff's against the OLPC git, I see there are > about 42 files with mostly-minor code changes, about 26 files removed. > It should be easy to handle the patching, so I am inclined to do that > before releasing and testing. That would be fine. We will check these changes into the OLPC git tree when Jordan gets back next week (or so). > > One thing I'm wondering about: there are about 65 files that have no > changes except the copyright notice was updated to 2008. Was that intended? Due to laziness on my part, yes. Jordan and I were going to discuss if that really went into the git tree. Thanks for stepping up and starting this effort. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From c-d.hailfinger.devel.2006 at gmx.net Fri Feb 1 22:21:25 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 01 Feb 2008 22:21:25 +0100 Subject: [coreboot] [LinuxBIOS] flashrom on ga 2761gxdk In-Reply-To: <13426df10802011208o7e700249r3268e3e7692e40be@mail.gmail.com> References: <13426df10801082236o6974bc7agf705b168fa322941@mail.gmail.com> <4785572C.2070708@gmx.net> <13426df10801092016o3b47fd9bl76887c70549c75b3@mail.gmail.com> <47860BC1.8050002@gmx.net> <47861062.3020909@gmx.net> <4796198A.8050406@gmx.net> <13426df10801220837m77f7d0cfv7c1a9d8d1cce5ab5@mail.gmail.com> <47961F17.3020204@gmx.net> <13426df10801222025o4e6b5f8rafd500a841a633e9@mail.gmail.com> <4798D178.7050204@gmx.net> <13426df10802011208o7e700249r3268e3e7692e40be@mail.gmail.com> Message-ID: <47A38D55.2060803@gmx.net> On 01.02.2008 21:08, ron minnich wrote: > Attached is: > my current svn diff > the 016 part, verbose > the 004 part, verbose. > > I tried two different 16 mbit parts and both fail. I don't think the > parts are dead. For the 4 Mbit part we see this in the logs: > RDID returned bf 25 8d. For the 16 Mbit part we see this: > RDID returned ff ff ff. If communication with the 16 Mbit part (SST25VF016B) had worked like in earlier times, we would have seen this instead: > RDID returned bf 25 41. The ff ff ff sequence from RDID tells us that either there is some communication failure between SPI controller and flash chip or the board setup (southbridge/superio config) differs. It would be very interesting to: - boot with a 4 Mbit chip and switch to the 16 Mbit chip during runtime - find out if the chips are wired differently (this includes being soldered on different pads) - check for accidential shorts. I'm sure we can debug this, in the worst case with the help of an oscilloscope. Regards, Carl-Daniel From wrightjmf at gmail.com Fri Feb 1 22:29:31 2008 From: wrightjmf at gmail.com (Jeremy Wright) Date: Fri, 1 Feb 2008 21:29:31 +0000 Subject: [coreboot] Capio II 320 and Coreboot In-Reply-To: References: <13426df10802011059sf8e3f99j25749f957e07af83@mail.gmail.com> <13426df10802011115y47de664fo57fcede4b1f3fd3@mail.gmail.com> <13426df10802011135l7c18edf3r7444292c6e6c2071@mail.gmail.com> Message-ID: I got a Windows terminal server set up, but I can't execute the terminal emulator locally. It just runs on the server. The way that Windows CE is set up on the DOC, I can't install (or run) anything locally. It's a remote desktop only client. The best that I can do is "reset it to factory condition" which doesn't give me any more control. Is there any way I can try serial console without testing the serial communications first? On Feb 1, 2008 7:39 PM, Jeremy Wright wrote: > I'll try to set up a termporary terminal server with Windows XP and see if > I can get to the point where I can try kermit or something similar. > > > On Feb 1, 2008 7:35 PM, ron minnich wrote: > > > can you get kermit or some other terminal emulator for windows CE? > > > > just to test? > > > > ron > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juergen127 at kreuzholzen.de Fri Feb 1 22:30:26 2008 From: juergen127 at kreuzholzen.de (Juergen Beisert) Date: Fri, 1 Feb 2008 22:30:26 +0100 Subject: [coreboot] Capio II 320 and Coreboot In-Reply-To: References: Message-ID: <200802012230.27261.juergen127@kreuzholzen.de> On Friday 01 February 2008 19:47, Jeremy Wright wrote: > Hi, > > I'm new to Coreboot, but I've been able to get a BIOS burned and sort of > working. I'm working with a Capio II 320 (see specs below) and I've tried > using the "Axus TC320" and "ASI MB-5BLMP" build tutorials since the CPU and > chipsets are so similar. I've also tried using Etherboot and FILO as the > payloads with the same results. The ASI tutorial starts up and initializes > the network interface, but I never get any video. With the Axus TC320 > tutorial, I get video, the network interface is initialized, and I get a > splash screen, but that's where it stops. When using Etherboot I can see > that the Capio starts to boot from my network boot server and then stops. > Is there a way I can get console output with the Axus TC320 setup? If I > could see what's going on I might be able to fix it. > > Any help will be greatly appreciated. > > Boundless (Neoware) Capio II 320 > Cyrix MediaGXm 233MHz > Geode CS5530 companion device > Intel 82559ER Network Interface > 48MB DiskOnChip > 32MB SDRAM DIMM Sounds like my CAPIO Boundless II. I also tried this to boot via coreboot, but without success. There is no serial device available on this target for debugging purposes and the 82559 seems special as the standard etherboot for this device fails also. Getting a console with coreboot might help for coreboot, but etherboot for example cannot use it. So if etherboot fails you will stick at the same point. Juergen From joe at smittys.pointclark.net Fri Feb 1 22:37:17 2008 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Fri, 01 Feb 2008 16:37:17 -0500 Subject: [coreboot] Competition at LinuxTag 2008 in Berlin, May 28-31 In-Reply-To: <20080127144614.jme0okh68sw48ss0@www.smittys.pointclark.net> References: <20080125151723.9531.qmail@stuge.se> <20080125190858.ihu40e6o0wso0cg4@www.smittys.pointclark.net> <20080127064135.4682.qmail@stuge.se> <479C63B2.8000000@gmail.com> <20080127075933.4qeqlfrtc80cw4s8@www.smittys.pointclark.net> <20080127150610.31466.qmail@stuge.se> <20080127144614.jme0okh68sw48ss0@www.smittys.pointclark.net> Message-ID: <20080201163717.rzw342vsgs8sswwk@www.smittys.pointclark.net> Quoting joe at smittys.pointclark.net: > Quoting Peter Stuge : > >> On Sun, Jan 27, 2008 at 07:59:33AM -0500, joe at smittys.pointclark.net wrote: >>> I am pretty fluent in php / html. >> >> Going back to the competition, we will need a database, an entry form >> and some way to pick the winner. I think a web based entry form is a >> good idea. >> >> >> //Peter >> > Sure Peter, that would be simple. Each form submitted gets an entry > number. Then at drawing time we use a random number generator to pick > the winner. Let me know if your serious about this and I will wip > something up. > So Peter did you want me wip something up? Thanks - Joe From rminnich at gmail.com Fri Feb 1 22:38:14 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 1 Feb 2008 13:38:14 -0800 Subject: [coreboot] [LinuxBIOS] flashrom on ga 2761gxdk In-Reply-To: <47A38D55.2060803@gmx.net> References: <13426df10801082236o6974bc7agf705b168fa322941@mail.gmail.com> <47860BC1.8050002@gmx.net> <47861062.3020909@gmx.net> <4796198A.8050406@gmx.net> <13426df10801220837m77f7d0cfv7c1a9d8d1cce5ab5@mail.gmail.com> <47961F17.3020204@gmx.net> <13426df10801222025o4e6b5f8rafd500a841a633e9@mail.gmail.com> <4798D178.7050204@gmx.net> <13426df10802011208o7e700249r3268e3e7692e40be@mail.gmail.com> <47A38D55.2060803@gmx.net> Message-ID: <13426df10802011338m2ea34605j2f2fe167834ad28d@mail.gmail.com> On Feb 1, 2008 1:21 PM, Carl-Daniel Hailfinger wrote: > - boot with a 4 Mbit chip and switch to the 16 Mbit chip during runtime That's how I'm doing this -- how swap. No choice, I don't have a bios on the big parts. > - find out if the chips are wired differently (this includes being > soldered on different pads) > - check for accidential shorts. > I gotta find a scope I suppose. What's weird is these parts were being found earlier. ron From ward at gnu.org Fri Feb 1 22:46:02 2008 From: ward at gnu.org (Ward Vandewege) Date: Fri, 1 Feb 2008 16:46:02 -0500 Subject: [coreboot] m57sli-s4 flashrom regression for v1(.1) boards (plcc) since r2972 Message-ID: <20080201214602.GA18563@localdomain> So; r2972 introduced two patches with this comment: ========================================================================== r2972 | hailfinger | 2007-11-14 10:09:30 -0500 (Wed, 14 Nov 2007) | 17 lines Autodetect presence of serial flash and set up the board accordingly. This enables us to have only one configuration and one set of code for all revisions of the Gigabyte GA-M57SLI-S4. Flash is now setup correctly for both SPI and LPC flash. Detection of SPI flash in flashrom on rev. 2.x boards now hangs instead of failing. However, that is just an effect of the combination of incomplete initialization of the SPI controller and paranoid checks in the flashrom SPI code. If anyone wants to work on that, he needs a logic analyzer or creative imagination. Hint: LPC-to-SPI read passthrough, clock signal. Remaining issues for the M57SLI: Fan/environment control. Signed-off-by: Carl-Daniel Hailfinger Acked-by: Harald Gutmann ========================================================================== One of those patches breaks flashrom on rev 1 and 1.1 of the m57sli (that's the plcc version of the board): Index: src/mainboard/gigabyte/m57sli/Config.lb =================================================================== --- src/mainboard/gigabyte/m57sli/Config.lb (revision 2955) +++ src/mainboard/gigabyte/m57sli/Config.lb (revision 2972) @@ -310,7 +310,7 @@ # SIO pin set 1 input mode #irq 0xc8 = 0x0 # SIO pin set 2 mixed input/output # mode - irq 0xc9 = 0x0 + irq 0xc9 = 0x40 # SIO pin set 4 input mode #irq 0xcb = 0x0 # Generate SMI# on EC IRQ Reversing this hunk fixes flashrom on the plcc version of our board. If it turns out that this value needs to be different for the various revisions of the m57sli, any thoughts on how we are going to handle that? Carl-Daniel - this hunk seems somewhat unrelated to the log message and the other part of r2972; do you remember what exactly it was for? Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From wrightjmf at gmail.com Fri Feb 1 22:47:04 2008 From: wrightjmf at gmail.com (Jeremy Wright) Date: Fri, 1 Feb 2008 21:47:04 +0000 Subject: [coreboot] Capio II 320 and Coreboot In-Reply-To: <200802012230.27261.juergen127@kreuzholzen.de> References: <200802012230.27261.juergen127@kreuzholzen.de> Message-ID: Hi Juergen, Is it that you don't have the superio (or whatever it's called) parallel/serial card for the Capio, or does Coreboot not recognize it? I have the card, I just need to know how to use it for debugging, or even if I can. Have you tried FILO with your Capio? I got the same result with it which makes me wonder if the problem is something other than the 82559. On Feb 1, 2008 9:30 PM, Juergen Beisert wrote: > On Friday 01 February 2008 19:47, Jeremy Wright wrote: > > Hi, > > > > I'm new to Coreboot, but I've been able to get a BIOS burned and sort of > > working. I'm working with a Capio II 320 (see specs below) and I've > tried > > using the "Axus TC320" and "ASI MB-5BLMP" build tutorials since the CPU > and > > chipsets are so similar. I've also tried using Etherboot and FILO as the > > payloads with the same results. The ASI tutorial starts up and > initializes > > the network interface, but I never get any video. With the Axus TC320 > > tutorial, I get video, the network interface is initialized, and I get a > > splash screen, but that's where it stops. When using Etherboot I can see > > that the Capio starts to boot from my network boot server and then > stops. > > Is there a way I can get console output with the Axus TC320 setup? If I > > could see what's going on I might be able to fix it. > > > > Any help will be greatly appreciated. > > > > Boundless (Neoware) Capio II 320 > > Cyrix MediaGXm 233MHz > > Geode CS5530 companion device > > Intel 82559ER Network Interface > > 48MB DiskOnChip > > 32MB SDRAM DIMM > > Sounds like my CAPIO Boundless II. I also tried this to boot via coreboot, > but > without success. There is no serial device available on this target for > debugging purposes and the 82559 seems special as the standard etherboot > for > this device fails also. > > Getting a console with coreboot might help for coreboot, but etherboot for > example cannot use it. So if etherboot fails you will stick at the same > point. > > Juergen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.jones at amd.com Fri Feb 1 22:44:19 2008 From: marc.jones at amd.com (Marc Jones) Date: Fri, 01 Feb 2008 14:44:19 -0700 Subject: [coreboot] PATCH: lx loads payload again, with new vsa, proper PCI bus scan etc. In-Reply-To: <13426df10802011236q7bd5e4d7v78357e293f73d2c0@mail.gmail.com> References: <13426df10802011128g38532556x6883d956cd096c49@mail.gmail.com> <47A37CE9.2020007@gmx.net> <13426df10802011236q7bd5e4d7v78357e293f73d2c0@mail.gmail.com> Message-ID: <47A392B3.1040406@amd.com> ron minnich wrote: > Committed revision 571. > > I included your svn mv suggestion, and have also removed the pci > biosint support in vsmsetup.c > > Thanks > > ron > Ron, How is VSA being compressed and built in? I seem to have missed something. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From rminnich at gmail.com Fri Feb 1 22:50:59 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 1 Feb 2008 13:50:59 -0800 Subject: [coreboot] PATCH: lx loads payload again, with new vsa, proper PCI bus scan etc. In-Reply-To: <47A392B3.1040406@amd.com> References: <13426df10802011128g38532556x6883d956cd096c49@mail.gmail.com> <47A37CE9.2020007@gmx.net> <13426df10802011236q7bd5e4d7v78357e293f73d2c0@mail.gmail.com> <47A392B3.1040406@amd.com> Message-ID: <13426df10802011350y38a5ddcbjfd822d42e327839d@mail.gmail.com> On Feb 1, 2008 1:44 PM, Marc Jones wrote: > How is VSA being compressed and built in? I seem to have missed something. No, I missed something: it's not being compressed. Oops. That's for buildrom. ./build/util/lar/lar -a build/bios.bin lxvsa:blob/vsa I could nrv2b encode it by hand, then it would also work. ron From rminnich at gmail.com Fri Feb 1 22:52:13 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 1 Feb 2008 13:52:13 -0800 Subject: [coreboot] Capio II 320 and Coreboot In-Reply-To: References: <200802012230.27261.juergen127@kreuzholzen.de> Message-ID: <13426df10802011352s6d395f21hbf3f8fc393a194bf@mail.gmail.com> On Feb 1, 2008 1:47 PM, Jeremy Wright wrote: > Hi Juergen, > > Is it that you don't have the superio (or whatever it's called) > parallel/serial card for the Capio, or does Coreboot not recognize it? I > have the card, I just need to know how to use it for debugging, or even if I > can. > can you run any programs on this node at all? Can you assemble a program? How does this thing boot anyway. ron From marc.jones at amd.com Fri Feb 1 22:54:43 2008 From: marc.jones at amd.com (Marc Jones) Date: Fri, 01 Feb 2008 14:54:43 -0700 Subject: [coreboot] PATCH: lx loads payload again, with new vsa, proper PCI bus scan etc. In-Reply-To: <13426df10802011350y38a5ddcbjfd822d42e327839d@mail.gmail.com> References: <13426df10802011128g38532556x6883d956cd096c49@mail.gmail.com> <47A37CE9.2020007@gmx.net> <13426df10802011236q7bd5e4d7v78357e293f73d2c0@mail.gmail.com> <47A392B3.1040406@amd.com> <13426df10802011350y38a5ddcbjfd822d42e327839d@mail.gmail.com> Message-ID: <47A39523.7090809@amd.com> ron minnich wrote: > On Feb 1, 2008 1:44 PM, Marc Jones wrote: > >> How is VSA being compressed and built in? I seem to have missed something. > > No, I missed something: it's not being compressed. Oops. That's for buildrom. > > ./build/util/lar/lar -a build/bios.bin lxvsa:blob/vsa > > I could nrv2b encode it by hand, then it would also work. > > ron > > OK, I agree it is for buildrom to compress. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From wrightjmf at gmail.com Fri Feb 1 23:00:09 2008 From: wrightjmf at gmail.com (Jeremy Wright) Date: Fri, 1 Feb 2008 22:00:09 +0000 Subject: [coreboot] Capio II 320 and Coreboot In-Reply-To: <13426df10802011352s6d395f21hbf3f8fc393a194bf@mail.gmail.com> References: <200802012230.27261.juergen127@kreuzholzen.de> <13426df10802011352s6d395f21hbf3f8fc393a194bf@mail.gmail.com> Message-ID: I can't run any programs on the node or assemble anything. The Capio BIOS boots a DiskOnChip (48 meg Flash drive) just like it would a hard drive. The DOC contains a pre-burned copy of Windows CE that is preconfigured to only give you the remote desktop connection dialog. I can bring up the standard Windows CE F2 menu, but it doesn't have any options to give me local access. So, the options that I've come up with so far are Coreboot, and buying/building an adapter card for the DOC. I would rather have the flexibility of Coreboot if at all possible though. On Feb 1, 2008 9:52 PM, ron minnich wrote: > On Feb 1, 2008 1:47 PM, Jeremy Wright wrote: > > Hi Juergen, > > > > Is it that you don't have the superio (or whatever it's called) > > parallel/serial card for the Capio, or does Coreboot not recognize it? I > > have the card, I just need to know how to use it for debugging, or even > if I > > can. > > > > can you run any programs on this node at all? Can you assemble a > program? How does this thing boot anyway. > > ron > -------------- next part -------------- An HTML attachment was scrubbed... URL: From c-d.hailfinger.devel.2006 at gmx.net Fri Feb 1 23:01:20 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 01 Feb 2008 23:01:20 +0100 Subject: [coreboot] Capio II 320 and Coreboot In-Reply-To: References: Message-ID: <47A396B0.6030805@gmx.net> On 01.02.2008 19:47, Jeremy Wright wrote: > I'm new to Coreboot, but I've been able to get a BIOS burned and sort of > working. I'm working with a Capio II 320 (see specs below) and I've tried > using the "Axus TC320" and "ASI MB-5BLMP" build tutorials since the CPU and > chipsets are so similar. I've also tried using Etherboot and FILO as the > payloads with the same results. The ASI tutorial starts up and initializes > the network interface, but I never get any video. With the Axus TC320 > tutorial, I get video, the network interface is initialized, and I get a > splash screen, but that's where it stops. When using Etherboot I can see > that the Capio starts to boot from my network boot server and then stops. Does that mean etherboot manages to load something over the network for both the Axus and the ASI target? > Is > there a way I can get console output with the Axus TC320 setup? If I could > see what's going on I might be able to fix it. > Since you got as far as having etherboot retrieve something over the network, the obvious next step would be to: - control etherboot over the network (no idea if that is possible) or - have etherboot load a payload which communicates over the network. Once you establish interaction over the network, a serial console is still desirable, but you can control the hardware and make the serial console work. Regards, Carl-Daniel From rminnich at gmail.com Fri Feb 1 23:04:16 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 1 Feb 2008 14:04:16 -0800 Subject: [coreboot] first REAL LX payload runs Message-ID: <13426df10802011404h713918f0r839e379f65292a1e@mail.gmail.com> Well, it's really not much but hey ... main: movb $0x11, %al outb %al, $0x80 movb $0x12, %al outb %al, $0x81 ret POSTS just fine. FILO just won't work ... well more later. My goal is to get this to go today, we'll see; I have a few more hours. ron From wrightjmf at gmail.com Fri Feb 1 23:05:38 2008 From: wrightjmf at gmail.com (Jeremy Wright) Date: Fri, 1 Feb 2008 22:05:38 +0000 Subject: [coreboot] Capio II 320 and Coreboot In-Reply-To: <47A396B0.6030805@gmx.net> References: <47A396B0.6030805@gmx.net> Message-ID: According to the logs on my LTSP server (using TFTP), it's the Capio is getting an IP address and then not requesting anything. Am I confused about how Etherboot works? Can Etherboot load a secondary payload like that? On Feb 1, 2008 10:01 PM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006 at gmx.net> wrote: > On 01.02.2008 19:47, Jeremy Wright wrote: > > I'm new to Coreboot, but I've been able to get a BIOS burned and sort of > > working. I'm working with a Capio II 320 (see specs below) and I've > tried > > using the "Axus TC320" and "ASI MB-5BLMP" build tutorials since the CPU > and > > chipsets are so similar. I've also tried using Etherboot and FILO as the > > payloads with the same results. The ASI tutorial starts up and > initializes > > the network interface, but I never get any video. With the Axus TC320 > > tutorial, I get video, the network interface is initialized, and I get a > > splash screen, but that's where it stops. When using Etherboot I can see > > that the Capio starts to boot from my network boot server and then > stops. > > Does that mean etherboot manages to load something over the network for > both the Axus and the ASI target? > > > Is > > there a way I can get console output with the Axus TC320 setup? If I > could > > see what's going on I might be able to fix it. > > > > Since you got as far as having etherboot retrieve something over the > network, the obvious next step would be to: > - control etherboot over the network (no idea if that is possible) or > - have etherboot load a payload which communicates over the network. > > Once you establish interaction over the network, a serial console is > still desirable, but you can control the hardware and make the > serial console work. > > > Regards, > Carl-Daniel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From c-d.hailfinger.devel.2006 at gmx.net Fri Feb 1 23:07:04 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 01 Feb 2008 23:07:04 +0100 Subject: [coreboot] m57sli-s4 flashrom regression for v1(.1) boards (plcc) since r2972 In-Reply-To: <20080201214602.GA18563@localdomain> References: <20080201214602.GA18563@localdomain> Message-ID: <47A39808.6060905@gmx.net> On 01.02.2008 22:46, Ward Vandewege wrote: > So; r2972 introduced two patches with this comment: > > ========================================================================== > > r2972 | hailfinger | 2007-11-14 10:09:30 -0500 (Wed, 14 Nov 2007) | 17 lines > > Autodetect presence of serial flash and set up the board accordingly. > This enables us to have only one configuration and one set of code for > all revisions of the Gigabyte GA-M57SLI-S4. > Flash is now setup correctly for both SPI and LPC flash. > > Detection of SPI flash in flashrom on rev. 2.x boards now hangs > instead of failing. However, that is just an effect of the combination > of incomplete initialization of the SPI controller and paranoid checks > in the flashrom SPI code. > If anyone wants to work on that, he needs a logic analyzer or creative > imagination. Hint: LPC-to-SPI read passthrough, clock signal. > > Remaining issues for the M57SLI: Fan/environment control. > > Signed-off-by: Carl-Daniel Hailfinger > Acked-by: Harald Gutmann > > ========================================================================== > > One of those patches breaks flashrom on rev 1 and 1.1 of the m57sli (that's > the plcc version of the board): > > Index: src/mainboard/gigabyte/m57sli/Config.lb > =================================================================== > --- src/mainboard/gigabyte/m57sli/Config.lb (revision 2955) > +++ src/mainboard/gigabyte/m57sli/Config.lb (revision 2972) > @@ -310,7 +310,7 @@ > # SIO pin set 1 input mode > #irq 0xc8 = 0x0 > # SIO pin set 2 mixed input/output > # mode > - irq 0xc9 = 0x0 > + irq 0xc9 = 0x40 > # SIO pin set 4 input mode > #irq 0xcb = 0x0 > # Generate SMI# on EC IRQ > > Reversing this hunk fixes flashrom on the plcc version of our board. > I had one similar report from another user of rev 1.x of the board. The change slipped in, it was there to reduce differences on rev 2.x boards, but it turned out that it was not related to the flashrom issues and will cause flashing on rev 1.x to fail. > If it turns out that this value needs to be different for the various > revisions of the m57sli, any thoughts on how we are going to handle that? > > Carl-Daniel - this hunk seems somewhat unrelated to the log message and the > other part of r2972; do you remember what exactly it was for? > See above. Could you send a patch to revert it and change the comment above the reverted line to "SIO pin set 2 input mode" Such a patch is acked in advance. Acked-by: Carl-Daniel Hailfinger Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Fri Feb 1 23:08:54 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 01 Feb 2008 23:08:54 +0100 Subject: [coreboot] PATCH: lx loads payload again, with new vsa, proper PCI bus scan etc. In-Reply-To: <13426df10802011350y38a5ddcbjfd822d42e327839d@mail.gmail.com> References: <13426df10802011128g38532556x6883d956cd096c49@mail.gmail.com> <47A37CE9.2020007@gmx.net> <13426df10802011236q7bd5e4d7v78357e293f73d2c0@mail.gmail.com> <47A392B3.1040406@amd.com> <13426df10802011350y38a5ddcbjfd822d42e327839d@mail.gmail.com> Message-ID: <47A39876.8030102@gmx.net> On 01.02.2008 22:50, ron minnich wrote: > On Feb 1, 2008 1:44 PM, Marc Jones wrote: > > >> How is VSA being compressed and built in? I seem to have missed something. >> > > No, I missed something: it's not being compressed. Oops. That's for buildrom. > > ./build/util/lar/lar -a build/bios.bin lxvsa:blob/vsa > > I could nrv2b encode it by hand, then it would also work. > Why nrv2b? Default compression does work out just fine. Regards, Carl-Daniel From rminnich at gmail.com Fri Feb 1 23:15:48 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 1 Feb 2008 14:15:48 -0800 Subject: [coreboot] PATCH: lx loads payload again, with new vsa, proper PCI bus scan etc. In-Reply-To: <47A39876.8030102@gmx.net> References: <13426df10802011128g38532556x6883d956cd096c49@mail.gmail.com> <47A37CE9.2020007@gmx.net> <13426df10802011236q7bd5e4d7v78357e293f73d2c0@mail.gmail.com> <47A392B3.1040406@amd.com> <13426df10802011350y38a5ddcbjfd822d42e327839d@mail.gmail.com> <47A39876.8030102@gmx.net> Message-ID: <13426df10802011415h5c131262n84439d706aec6aa5@mail.gmail.com> On Feb 1, 2008 2:08 PM, Carl-Daniel Hailfinger wrote: > Why nrv2b? Default compression does work out just fine. > no real reason. ron From c-d.hailfinger.devel.2006 at gmx.net Fri Feb 1 23:24:56 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 01 Feb 2008 23:24:56 +0100 Subject: [coreboot] VSA and vm86/x86emu Message-ID: <47A39C38.9010701@gmx.net> Hi, it seems that executing VSA requires vm86 to be useful. Since we unconditionally execute the VSA, we should unconditionally require vm86 support (PCI_OPTION_ROM_RUN_VM86) via Kconfig for Geode targets. Not doing so will either cause compile failures or runtime failures. Adding select PCI_OPTION_ROM_RUN_VM86 below config CPU_AMD_GEODELX did not work out for me. Any ideas? Regards, Carl-Daniel -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: config URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: makelog_pcengines_alix1c.txt URL: From ward at gnu.org Fri Feb 1 23:37:58 2008 From: ward at gnu.org (Ward Vandewege) Date: Fri, 1 Feb 2008 17:37:58 -0500 Subject: [coreboot] m57sli-s4 flashrom regression for v1(.1) boards (plcc) since r2972 In-Reply-To: <47A39808.6060905@gmx.net> References: <20080201214602.GA18563@localdomain> <47A39808.6060905@gmx.net> Message-ID: <20080201223758.GA19199@localdomain> Hi Carl-Daniel, On Fri, Feb 01, 2008 at 11:07:04PM +0100, Carl-Daniel Hailfinger wrote: > I had one similar report from another user of rev 1.x of the board. The > change slipped in, it was there to reduce differences on rev 2.x > boards, but it turned out that it was not related to the flashrom issues > and will cause flashing on rev 1.x to fail. > > See above. Could you send a patch to revert it and change the comment > above the reverted line to > "SIO pin set 2 input mode" Sure. Thanks for your swift response! Patch attached, will commit unless there are objections. Thanks, Ward. > Such a patch is acked in advance. > Acked-by: Carl-Daniel Hailfinger -- Ward Vandewege Free Software Foundation - Senior System Administrator -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-r2972-regression.patch Type: text/x-diff Size: 756 bytes Desc: not available URL: From c-d.hailfinger.devel.2006 at gmx.net Fri Feb 1 23:42:17 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 01 Feb 2008 23:42:17 +0100 Subject: [coreboot] Capio II 320 and Coreboot In-Reply-To: References: <47A396B0.6030805@gmx.net> Message-ID: <47A3A049.7030906@gmx.net> On 01.02.2008 23:05, Jeremy Wright wrote: > According to the logs on my LTSP server (using TFTP), it's the Capio is > getting an IP address and then not requesting anything. Am I confused about > how Etherboot works? > Does the DHCP server ever get a DHCPREQUEST response to its DHCPOFFER packet? If you're not sure, a pcap log (via ethereal or tcpdump) as attachment to the list should help us diagnose whether the Capio really receives packets from the server. Note: The pcap log should have 4 packets and be reasonably small (~300-2000 bytes). > Can Etherboot load a secondary payload like that? > Well, it can load a payload, so it should be able to load a payload which interacts over the network. Regards, Carl-Daniel From rminnich at gmail.com Fri Feb 1 23:43:13 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 1 Feb 2008 14:43:13 -0800 Subject: [coreboot] Capio II 320 and Coreboot In-Reply-To: <47A3A049.7030906@gmx.net> References: <47A396B0.6030805@gmx.net> <47A3A049.7030906@gmx.net> Message-ID: <13426df10802011443u4a929be2sf5bb326318148b27@mail.gmail.com> On Feb 1, 2008 2:42 PM, Carl-Daniel Hailfinger wrote: > On 01.02.2008 23:05, Jeremy Wright wrote: > > Can Etherboot load a secondary payload like that? > > Sure. I've loaded filo and etherboot with etherboot. ron From rminnich at gmail.com Fri Feb 1 23:44:09 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 1 Feb 2008 14:44:09 -0800 Subject: [coreboot] v3 loads and starts filo on alix1c! Message-ID: <13426df10802011444v77d48bf6k3e71aeeeef4a7730@mail.gmail.com> Closer ... it's dying in pci init somewhere. It gets to 0:f.7 and then no more output. ron From c-d.hailfinger.devel.2006 at gmx.net Fri Feb 1 23:49:34 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 01 Feb 2008 23:49:34 +0100 Subject: [coreboot] v3 loads and starts filo on alix1c! In-Reply-To: <13426df10802011444v77d48bf6k3e71aeeeef4a7730@mail.gmail.com> References: <13426df10802011444v77d48bf6k3e71aeeeef4a7730@mail.gmail.com> Message-ID: <47A3A1FE.4070104@gmx.net> On 01.02.2008 23:44, ron minnich wrote: > Closer ... > > it's dying in pci init somewhere. It gets to 0:f.7 and then no more output. > Great! What about using memtest as a payload? I believe it does not use any PCI access. Besides that, if we have memtest running and it spits out errors, we know where to look further. Regards, Carl-Daniel From rminnich at gmail.com Fri Feb 1 23:51:02 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 1 Feb 2008 14:51:02 -0800 Subject: [coreboot] v3 loads and starts filo on alix1c! In-Reply-To: <47A3A1FE.4070104@gmx.net> References: <13426df10802011444v77d48bf6k3e71aeeeef4a7730@mail.gmail.com> <47A3A1FE.4070104@gmx.net> Message-ID: <13426df10802011451he11f36elb64db983708a8703@mail.gmail.com> On Feb 1, 2008 2:49 PM, Carl-Daniel Hailfinger wrote: > What about using memtest as a payload? I believe it does not use any PCI > access. Besides that, if we have memtest running and it spits out > errors, we know where to look further. > Will try that next. ron From ward at gnu.org Fri Feb 1 23:53:09 2008 From: ward at gnu.org (Ward Vandewege) Date: Fri, 1 Feb 2008 17:53:09 -0500 Subject: [coreboot] [PATCH] (resend2) fix the flashrom problem on m57sli boards with SPI flash In-Reply-To: <1201744911.47a12c0fccc1c@imp.free.fr> References: <1201744911.47a12c0fccc1c@imp.free.fr> Message-ID: <20080201225309.GA19881@localdomain> On Thu, Jan 31, 2008 at 03:01:51AM +0100, Florentin Demetrescu wrote: > This patch fixes the decoding of the IO address range 0x0820->0x0827 into the > LPC device of the MCP55 southbridge, thus enabling flashrom access to the SPI > interface of the IT8716 SIO chip. > Changes : > 1) - increase MAX_RESOURCES to 24 in device.h -> this was needed because some > functions of a PNP device can have more than 12 resources (ex the GPIO function > of IT8716f), in which case one could have an "array overflow" inside the device > structure (yes gcc is stupid!..) and ultimately a disaster (fool pointer at > device init time..) > 2) - define resource masks for the GPIO function in > src/superio/ite/it8716f/superio.c -> this is needed because otherwise the IO > ranges which are set into the LPC bridge of the SB are very strange (f.ex.: > 0x800->0x7ff and so on..). Problem: the PNP_IO0 resource is not defined for the > GPIO function, thus we have to define a "fake" mask "{0,0}" to avoid mismatching > by the init code > 3) - enable the flash SPI interface into > src/mainboard/gigabyte/m57sli/Config.lb (by enabling the corresponding resource > into the GPIO function). I know that this is problematic because not all m57sli > boards are SPI, but .. do anyone have a better idea how to handle this?.. I have verified your patch on a v2 of this board (it works!) as well as on a v1 (plcc). It does not affect flashing on v1 nor have any averse side effects that I noticed, so I think this patch should go in. > Signed-off-by: Florentin Demetrescu Acked-by: Ward Vandewege If nobody objects I will commit this later tonight or tomorrow. Thanks a lot! Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From c-d.hailfinger.devel.2006 at gmx.net Sat Feb 2 00:02:27 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 02 Feb 2008 00:02:27 +0100 Subject: [coreboot] [PATCH] (resend2) fix the flashrom problem on m57sli boards with SPI flash In-Reply-To: <20080201225309.GA19881@localdomain> References: <1201744911.47a12c0fccc1c@imp.free.fr> <20080201225309.GA19881@localdomain> Message-ID: <47A3A503.1020006@gmx.net> On 01.02.2008 23:53, Ward Vandewege wrote: > On Thu, Jan 31, 2008 at 03:01:51AM +0100, Florentin Demetrescu wrote: > >> This patch fixes the decoding of the IO address range 0x0820->0x0827 into the >> LPC device of the MCP55 southbridge, thus enabling flashrom access to the SPI >> interface of the IT8716 SIO chip. >> Changes : >> 1) - increase MAX_RESOURCES to 24 in device.h -> this was needed because some >> functions of a PNP device can have more than 12 resources (ex the GPIO function >> of IT8716f), in which case one could have an "array overflow" inside the device >> structure (yes gcc is stupid!..) and ultimately a disaster (fool pointer at >> device init time..) >> 2) - define resource masks for the GPIO function in >> src/superio/ite/it8716f/superio.c -> this is needed because otherwise the IO >> ranges which are set into the LPC bridge of the SB are very strange (f.ex.: >> 0x800->0x7ff and so on..). Problem: the PNP_IO0 resource is not defined for the >> GPIO function, thus we have to define a "fake" mask "{0,0}" to avoid mismatching >> by the init code >> 3) - enable the flash SPI interface into >> src/mainboard/gigabyte/m57sli/Config.lb (by enabling the corresponding resource >> into the GPIO function). I know that this is problematic because not all m57sli >> boards are SPI, but .. do anyone have a better idea how to handle this?.. >> > > I have verified your patch on a v2 of this board (it works!) as well as on a > v1 (plcc). It does not affect flashing on v1 nor have any averse side effects > that I noticed, so I think this patch should go in. > > >> Signed-off-by: Florentin Demetrescu >> > Acked-by: Ward Vandewege > Acked-by: Carl-Daniel Hailfinger > If nobody objects I will commit this later tonight or tomorrow. > Please do. Regards, Carl-Daniel From svn at coreboot.org Sat Feb 2 00:07:05 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Sat, 2 Feb 2008 00:07:05 +0100 Subject: [coreboot] r3087 - trunk/coreboot-v2/src/mainboard/gigabyte/m57sli Message-ID: Author: ward Date: 2008-02-02 00:07:04 +0100 (Sat, 02 Feb 2008) New Revision: 3087 Modified: trunk/coreboot-v2/src/mainboard/gigabyte/m57sli/Config.lb Log: This patch reverses an erroneous change that sneaked in during r2972, and broke flashrom on the plcc-based rev 1 and 1.1 of the Gigabyte m57sli-s4 board. Signed-off-by: Ward Vandewege Acked-by: Carl-Daniel Hailfinger Modified: trunk/coreboot-v2/src/mainboard/gigabyte/m57sli/Config.lb =================================================================== --- trunk/coreboot-v2/src/mainboard/gigabyte/m57sli/Config.lb 2008-01-28 22:55:47 UTC (rev 3086) +++ trunk/coreboot-v2/src/mainboard/gigabyte/m57sli/Config.lb 2008-02-01 23:07:04 UTC (rev 3087) @@ -309,8 +309,8 @@ #irq 0xc3 = 0x0 # SIO pin set 1 input mode #irq 0xc8 = 0x0 - # SIO pin set 2 mixed input/output mode - irq 0xc9 = 0x40 + # SIO pin set 2 input mode + irq 0xc9 = 0x0 # SIO pin set 4 input mode #irq 0xcb = 0x0 # Generate SMI# on EC IRQ From svn at coreboot.org Sat Feb 2 00:14:41 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Sat, 2 Feb 2008 00:14:41 +0100 Subject: [coreboot] r3088 - in trunk/coreboot-v2/src: include/device mainboard/gigabyte/m57sli superio/ite/it8716f Message-ID: Author: ward Date: 2008-02-02 00:14:40 +0100 (Sat, 02 Feb 2008) New Revision: 3088 Modified: trunk/coreboot-v2/src/include/device/device.h trunk/coreboot-v2/src/mainboard/gigabyte/m57sli/Config.lb trunk/coreboot-v2/src/superio/ite/it8716f/superio.c Log: This patch fixes the decoding of the IO address range 0x0820->0x0827 into the LPC device of the MCP55 southbridge, thus enabling flashrom access to the SPI interface of the IT8716 SIO chip. Changes : 1) - increase MAX_RESOURCES to 24 in device.h -> this was needed because some functions of a PNP device can have more than 12 resources (ex the GPIO function of IT8716f), in which case one could have an "array overflow" inside the device structure (yes gcc is stupid!..) and ultimately a disaster (fool pointer at device init time..) 2) - define resource masks for the GPIO function in src/superio/ite/it8716f/superio.c -> this is needed because otherwise the IO ranges which are set into the LPC bridge of the SB are very strange (f.ex.: 0x800->0x7ff and so on..). Problem: the PNP_IO0 resource is not defined for the GPIO function, thus we have to define a "fake" mask "{0,0}" to avoid mismatching by the init code 3) - enable the flash SPI interface into src/mainboard/gigabyte/m57sli/Config.lb (by enabling the corresponding resource into the GPIO function). I know that this is problematic because not all m57sli boards are SPI, but .. do anyone have a better idea how to handle this?.. Signed-off-by: Florentin Demetrescu I (Ward) have verified your patch on a rev2 of this board (it works!) as well as on a rev1 (plcc). It does not affect flashing on rev1 nor have any averse side effects that I noticed, so I think this patch should go in. Acked-by: Ward Vandewege Acked-by: Carl-Daniel Hailfinger Modified: trunk/coreboot-v2/src/include/device/device.h =================================================================== --- trunk/coreboot-v2/src/include/device/device.h 2008-02-01 23:07:04 UTC (rev 3087) +++ trunk/coreboot-v2/src/include/device/device.h 2008-02-01 23:14:40 UTC (rev 3088) @@ -55,7 +55,7 @@ unsigned disable_relaxed_ordering : 1; }; -#define MAX_RESOURCES 12 +#define MAX_RESOURCES 24 #define MAX_LINKS 8 /* * There is one device structure for each slot-number/function-number Modified: trunk/coreboot-v2/src/mainboard/gigabyte/m57sli/Config.lb =================================================================== --- trunk/coreboot-v2/src/mainboard/gigabyte/m57sli/Config.lb 2008-02-01 23:07:04 UTC (rev 3087) +++ trunk/coreboot-v2/src/mainboard/gigabyte/m57sli/Config.lb 2008-02-01 23:14:40 UTC (rev 3088) @@ -290,7 +290,7 @@ # Simple I/O base io 0x62 = 0x800 # Serial Flash I/O (SPI only) - #io 0x64 = 0x820 + io 0x64 = 0x820 # watch dog force timeout (parallel flash only) #irq 0x71 = 0x1 # No WDT interrupt Modified: trunk/coreboot-v2/src/superio/ite/it8716f/superio.c =================================================================== --- trunk/coreboot-v2/src/superio/ite/it8716f/superio.c 2008-02-01 23:07:04 UTC (rev 3087) +++ trunk/coreboot-v2/src/superio/ite/it8716f/superio.c 2008-02-01 23:14:40 UTC (rev 3088) @@ -152,7 +152,7 @@ {&ops, IT8716F_KBCK, PNP_IO0 | PNP_IO1 | PNP_IRQ0, {0x7ff, 0}, {0x7ff, 0x4},}, {&ops, IT8716F_KBCM, PNP_IRQ0,}, - {&ops, IT8716F_GPIO,}, + {&ops, IT8716F_GPIO, PNP_IO1 | PNP_IO2, {0, 0}, {0x7f8, 0}, {0x7f8, 0},}, {&ops, IT8716F_MIDI, PNP_IO0 | PNP_IRQ0, {0x7fe, 0x4},}, {&ops, IT8716F_GAME, PNP_IO0, {0x7ff, 0},}, {&ops, IT8716F_IR,}, From svn at coreboot.org Sat Feb 2 00:17:28 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Sat, 2 Feb 2008 00:17:28 +0100 Subject: [coreboot] r104 - buildrom-devel/config/platforms Message-ID: Author: ward Date: 2008-02-02 00:17:26 +0100 (Sat, 02 Feb 2008) New Revision: 104 Modified: buildrom-devel/config/platforms/m57sli.conf Log: Bump up coreboot revision used for m57sli to 3088. This fixes flashrom on both plcc-based (that was a regression caused by r2972) and spi-based versions of this board (thanks to Florentin Demetrescu's excellent debugging work). This is a trivial patch. Signed-off-by: Ward Vandewege Acked-by: Ward Vandewege Modified: buildrom-devel/config/platforms/m57sli.conf =================================================================== --- buildrom-devel/config/platforms/m57sli.conf 2008-02-01 20:59:17 UTC (rev 103) +++ buildrom-devel/config/platforms/m57sli.conf 2008-02-01 23:17:26 UTC (rev 104) @@ -40,7 +40,7 @@ COREBOOT_BOARD=m57sli CBV2_CONFIG=Config.lb CBV2_TDIR=m57sli -CBV2_TAG=3079 +CBV2_TAG=3088 COREBOOT_ROM_NAME=coreboot.rom # FILO configuration From svn at coreboot.org Sat Feb 2 00:26:33 2008 From: svn at coreboot.org (coreboot) Date: Fri, 01 Feb 2008 23:26:33 -0000 Subject: [coreboot] #87: flashrom issues on m57sli-s4 In-Reply-To: <040.c279821705ba477c152671a193fcee84@coreboot.org> References: <040.c279821705ba477c152671a193fcee84@coreboot.org> Message-ID: <049.3db648471a01568cb3a60b255e2e36d9@coreboot.org> #87: flashrom issues on m57sli-s4 -------------------------+-------------------------------------------------- Reporter: ward | Owner: hailfinger Type: defect | Status: closed Priority: major | Milestone: Component: flashrom | Version: v2 Resolution: fixed | Keywords: Dependencies: | Patchstatus: there is no patch -------------------------+-------------------------------------------------- Changes (by ward): * status: assigned => closed * resolution: => fixed Comment: PLCC-based flashing was accidentally broken in r2972. This was fixed in r3087. SPI-based flashing is now also fixed since r3088, thanks to Florentin Demetrescu. -- Ticket URL: coreboot From echelon at free.fr Sat Feb 2 00:38:35 2008 From: echelon at free.fr (Florentin Demetrescu) Date: Sat, 02 Feb 2008 00:38:35 +0100 Subject: [coreboot] [PATCH] (resend2) fix the flashrom problem on m57sli boards with SPI flash In-Reply-To: <20080201225309.GA19881@localdomain> References: <1201744911.47a12c0fccc1c@imp.free.fr> <20080201225309.GA19881@localdomain> Message-ID: <1201909115.47a3ad7bd8b97@imp.free.fr> It rocks!.. Now after taking a little break (1-2 weeks), I will begin to tackle the problems of ACPI and/or the incorrect init of IRQs on lagacy PCI slots on this board.. (which one is most urgent?) This is my roadmap for the short-term.. For the long term, Id like to contribute to the porting of coreboot-v3 on this board.. (but firstly, I have to familiarize myself with the coreboot-v3 architecture..) Florentin Quoting Ward Vandewege : > On Thu, Jan 31, 2008 at 03:01:51AM +0100, Florentin Demetrescu wrote: > > This patch fixes the decoding of the IO address range 0x0820->0x0827 into > the > > LPC device of the MCP55 southbridge, thus enabling flashrom access to the > SPI > > interface of the IT8716 SIO chip. > > Changes : > > 1) - increase MAX_RESOURCES to 24 in device.h -> this was needed because > some > > functions of a PNP device can have more than 12 resources (ex the GPIO > function > > of IT8716f), in which case one could have an "array overflow" inside the > device > > structure (yes gcc is stupid!..) and ultimately a disaster (fool pointer at > > device init time..) > > 2) - define resource masks for the GPIO function in > > src/superio/ite/it8716f/superio.c -> this is needed because otherwise the > IO > > ranges which are set into the LPC bridge of the SB are very strange (f.ex.: > > 0x800->0x7ff and so on..). Problem: the PNP_IO0 resource is not defined for > the > > GPIO function, thus we have to define a "fake" mask "{0,0}" to avoid > mismatching > > by the init code > > 3) - enable the flash SPI interface into > > src/mainboard/gigabyte/m57sli/Config.lb (by enabling the corresponding > resource > > into the GPIO function). I know that this is problematic because not all > m57sli > > boards are SPI, but .. do anyone have a better idea how to handle this?.. > > I have verified your patch on a v2 of this board (it works!) as well as on a > v1 (plcc). It does not affect flashing on v1 nor have any averse side effects > that I noticed, so I think this patch should go in. > > > Signed-off-by: Florentin Demetrescu > Acked-by: Ward Vandewege > > If nobody objects I will commit this later tonight or tomorrow. > > Thanks a lot! > Ward. > > -- > Ward Vandewege > Free Software Foundation - Senior System Administrator > From c-d.hailfinger.devel.2006 at gmx.net Sat Feb 2 00:47:41 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 02 Feb 2008 00:47:41 +0100 Subject: [coreboot] [PATCH] (resend2) fix the flashrom problem on m57sli boards with SPI flash In-Reply-To: <1201909115.47a3ad7bd8b97@imp.free.fr> References: <1201744911.47a12c0fccc1c@imp.free.fr> <20080201225309.GA19881@localdomain> <1201909115.47a3ad7bd8b97@imp.free.fr> Message-ID: <47A3AF9D.4080308@gmx.net> On 02.02.2008 00:38, Florentin Demetrescu wrote: > Now after taking a little break (1-2 weeks), I will begin to tackle the problems > of ACPI and/or the incorrect init of IRQs on lagacy PCI slots on this board.. > (which one is most urgent?) This is my roadmap for the short-term.. > I think there is some code in the tree which will generate ACPI tables almost automatically. IIRC Rudolf Marek was working on that. > For the long term, Id like to contribute to the porting of coreboot-v3 on this > board.. (but firstly, I have to familiarize myself with the coreboot-v3 > architecture..) > That would be great! Coreboot v3 is a lot easier to understand and its boot messages are mostly self-explaining. The qemu target should work just fine. For anyone starting to work with v3, I have to ask you to write down any questions arising from unclear boot messages or badly commented/explained code. I hope the v3 codebase has none of these problems, but I have worked with that codebase for too long to be able to analyze it from an outsider's point of view. Regards, Carl-Daniel From jakllsch at kollasch.net Sat Feb 2 00:51:22 2008 From: jakllsch at kollasch.net (jakllsch at kollasch.net) Date: Fri, 1 Feb 2008 17:51:22 -0600 Subject: [coreboot] [LinuxBIOS] [patch] MSI MS-7135 (this time with attachment) In-Reply-To: <20080201163626.GA1756@kirkkit.kollasch.net> References: <20071207054444.GW2629@kirkkit.kollasch.net> <20080201163626.GA1756@kirkkit.kollasch.net> Message-ID: <20080201235121.GC1756@kirkkit.kollasch.net> On Fri, Feb 01, 2008 at 10:36:26AM -0600, jakllsch at kollasch.net wrote: > On Fri, Feb 01, 2008 at 12:06:15AM -0800, David Hendricks wrote: > > Whoa, I don't know how I let this one slip by... Did you manage to get SATA > > working, by chance? That was a show stopper for me, but I haven't been able > > to diagnose it. > > I did not get the second set of two SATA ports working, but I did > get the first set working. Also, I didn't get the audio to work. Huh, well, I now have *all* the SATA ports working. I also fixed the audio. The magic with the audio is to `#define CK804_USE_ACI 1`. This should fix any ck804 board with audio, probably including the a8n-e. I should probably update the patch and get it to work with coreboot v2 svn. Jonathan Kollasch -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From info at coresystems.de Sat Feb 2 00:58:43 2008 From: info at coresystems.de (coreboot information) Date: Sat, 02 Feb 2008 00:58:43 +0100 Subject: [coreboot] r3087 build service Message-ID: Dear coreboot readers! This is the automated build check service of coreboot. The developer "ward" checked in revision 3087 to the coreboot source repository and caused the following changes: Change Log: This patch reverses an erroneous change that sneaked in during r2972, and broke flashrom on the plcc-based rev 1 and 1.1 of the Gigabyte m57sli-s4 board. Signed-off-by: Ward Vandewege Acked-by: Carl-Daniel Hailfinger Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3087&device=serengeti_cheetah_fam10&vendor=amd If something broke during this checkin please be a pain in ward's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system From r.marek at assembler.cz Sat Feb 2 00:58:52 2008 From: r.marek at assembler.cz (Rudolf Marek) Date: Sat, 02 Feb 2008 00:58:52 +0100 Subject: [coreboot] [PATCH] (resend2) fix the flashrom problem on m57sli boards with SPI flash In-Reply-To: <47A3AF9D.4080308@gmx.net> References: <1201744911.47a12c0fccc1c@imp.free.fr> <20080201225309.GA19881@localdomain> <1201909115.47a3ad7bd8b97@imp.free.fr> <47A3AF9D.4080308@gmx.net> Message-ID: <47A3B23C.1040504@assembler.cz> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I think there is some code in the tree which will generate ACPI tables > almost automatically. IIRC Rudolf Marek was working on that. Yep I got ACPI events working. (Pressing button will triger gnome logout screen) plus machine powers down when told so ;) I have even some very experimental suspend to RAM working. I have also ACPI IRQ routing working. I started with this wiki page: http://www.coreboot.org/ACPI_in_coreboot And someone contributed some tool for FADT table generation. For example please look to ASUS A8V-E SE board directory. And of course ACPI specs ;) (http://www.acpi.info) Although my time is very limited right now I think I can at least answer mails about the ACPI stuff if you need some help. >> For the long term, Id like to contribute to the porting of coreboot-v3 on this >> board.. (but firstly, I have to familiarize myself with the coreboot-v3 >> architecture..) >> > > That would be great! Coreboot v3 is a lot easier to understand and its > boot messages are mostly self-explaining. The qemu target should work > just fine. Yep it would be cool. If you do the K8 stuff I will do the VIA chipset stuff porting. Thanks, Rudolf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHo7I83J9wPJqZRNURAsexAJ47AfBHqS8yG6/5BRcDSZwfpORMiQCfUW5H YP2H5UVfgSPMXIWm/9C8k/A= =QFrw -----END PGP SIGNATURE----- From c-d.hailfinger.devel.2006 at gmx.net Sat Feb 2 01:31:38 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 02 Feb 2008 01:31:38 +0100 Subject: [coreboot] [PATCH] (resend2) fix the flashrom problem on m57sli boards with SPI flash In-Reply-To: <47A3B23C.1040504@assembler.cz> References: <1201744911.47a12c0fccc1c@imp.free.fr> <20080201225309.GA19881@localdomain> <1201909115.47a3ad7bd8b97@imp.free.fr> <47A3AF9D.4080308@gmx.net> <47A3B23C.1040504@assembler.cz> Message-ID: <47A3B9EA.40503@gmx.net> On 02.02.2008 00:58, Rudolf Marek wrote: > Although my time is very limited right now I think I can at least > answer mails > about the ACPI stuff if you need some help. My time is very limited as well. I hope that this changes sometime in March. > >> For the long term, Id like to contribute to the porting of > coreboot-v3 on this > >> board.. (but firstly, I have to familiarize myself with the coreboot-v3 > >> architecture..) > >> > > That would be great! Coreboot v3 is a lot easier to understand and its > > boot messages are mostly self-explaining. The qemu target should work > > just fine. > > Yep it would be cool. If you do the K8 stuff I will do the VIA chipset > stuff > porting. I'd say we first try to get the Alix.1C Geode LX working perfectly in v3 to better understand all issues in v3 hardware bringup. With luck, that will happen this weekend. Then I hope porting most Geode LX targets will be easy and give us a better feeling of what should be done in mainboard specific code vs. processor/chipset specific code. After that, porting K8 code would be the obvious next step, although I hope we can clean up the code a lot before moving it to v3. My goal for the next 6 months is to obsolete all v2 Geode LX targets by supporting them in v3. That and the easier porting should move enough development resources to v3 for it to gain strong momentum and quite a bit of media coverage. Regards, Carl-Daniel From info at coresystems.de Sat Feb 2 01:52:03 2008 From: info at coresystems.de (coreboot information) Date: Sat, 02 Feb 2008 01:52:03 +0100 Subject: [coreboot] r3088 build service Message-ID: Dear coreboot readers! This is the automated build check service of coreboot. The developer "ward" checked in revision 3088 to the coreboot source repository and caused the following changes: Change Log: This patch fixes the decoding of the IO address range 0x0820->0x0827 into the LPC device of the MCP55 southbridge, thus enabling flashrom access to the SPI interface of the IT8716 SIO chip. Changes : 1) - increase MAX_RESOURCES to 24 in device.h -> this was needed because some functions of a PNP device can have more than 12 resources (ex the GPIO function of IT8716f), in which case one could have an "array overflow" inside the device structure (yes gcc is stupid!..) and ultimately a disaster (fool pointer at device init time..) 2) - define resource masks for the GPIO function in src/superio/ite/it8716f/superio.c -> this is needed because otherwise the IO ranges which are set into the LPC bridge of the SB are very strange (f.ex.: 0x800->0x7ff and so on..). Problem: the PNP_IO0 resource is not defined for the GPIO function, thus we have to define a "fake" mask "{0,0}" to avoid mismatching by the init code 3) - enable the flash SPI interface into src/mainboard/gigabyte/m57sli/Config.lb (by enabling the corresponding resource into the GPIO function). I know that this is problematic because not all m57sli boards are SPI, but .. do anyone have a better idea how to handle this?.. Signed-off-by: Florentin Demetrescu I (Ward) have verified your patch on a rev2 of this board (it works!) as well as on a rev1 (plcc). It does not affect flashing on rev1 nor have any averse side effects that I noticed, so I think this patch should go in. Acked-by: Ward Vandewege Acked-by: Carl-Daniel Hailfinger Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3088&device=serengeti_cheetah_fam10&vendor=amd If something broke during this checkin please be a pain in ward's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system From stepan at coresystems.de Sat Feb 2 02:39:15 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 02 Feb 2008 02:39:15 +0100 Subject: [coreboot] Geode LX/CS5536 VSA In-Reply-To: <47A37FA3.4000505@gmx.net> References: <47A1FF9C.2040700@amd.com> <47A37D2B.5010208@whiterocker.com> <47A37FA3.4000505@gmx.net> Message-ID: <47A3C9C3.6040505@coresystems.de> Carl-Daniel Hailfinger wrote: >> I would appreciate any comments from the list on: >> 1. hosting these VSA sources. Would coreboot.org be a good place to >> keep the GNU-ified VSA sources? >> >> > > Probably yes. The laptop.org GIT tree only has 2 revisions. Such an > amount of change could easily be handled with subversion and > coreboot.org surely could handle that. The final decision is made by > Stefan, though. > Yes, we can add a seperate repository for that. Or even check it into the coreboot tree? Would that make sense? Whatever is preferred by you guys. >> 2. the idea of permanently moving to a GNU-buildable version? >> >> > > It would certainly make outside contributions easier. > > Yes, no need for MASM to build the whole thing is a great step forward. Congratulations! Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From wrightjmf at gmail.com Sat Feb 2 02:46:45 2008 From: wrightjmf at gmail.com (Jeremy Wright) Date: Sat, 2 Feb 2008 01:46:45 +0000 Subject: [coreboot] Capio II 320 and Coreboot In-Reply-To: <13426df10802011443u4a929be2sf5bb326318148b27@mail.gmail.com> References: <47A396B0.6030805@gmx.net> <47A3A049.7030906@gmx.net> <13426df10802011443u4a929be2sf5bb326318148b27@mail.gmail.com> Message-ID: Yes, the server gets a DHCPREQUEST response to its DHCPOFFER. I took the ethereal advice and found that not only is DHCP working, but TFTP is working as well. I noticed it was loading the nbi.img image (sucessfully), so I switched it to pxelinux.0 and got a different response. The client starts to load the pxelinux.0 image, gets to block 2, and then resets, asks for an address via DHCP again, and starts trying to download the image again until it gets to block 2. It will keep going in this loop forever unless I stop it. When it loads the nbi.img file, it doesn't have the looping problem. I have included the output from ethereal below hoping that it will shed some light on the situation. I'm a little puzzled. Should I try another version of Etherboot? I'm using version 5.2.6. Thanks, Jeremy No. Time Source Destination Protocol Info 1 0.000000 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0xe16c0e9 2 0.028507 Cisco-Li_0b:4f:e7 Broadcast ARP Who has 192.168.0.247? Tell 192.168.0.1 3 0.704732 192.168.0.1 192.168.0.247 DHCP DHCP Offer - Transaction ID 0xe16c0e9 4 0.705118 192.168.0.247 255.255.255.255 DHCP DHCP Request - Transaction ID 0xe16c0e9 5 0.737300 192.168.0.1 192.168.0.247 DHCP DHCP ACK - Transaction ID 0xe16c0e9 6 0.737626 Ncr_16:c0:5e Broadcast ARP Who has 192.168.0.1? Tell 192.168.0.247 7 0.737660 192.168.0.1 192.168.0.247 ICMP Echo (ping) request 8 0.737669 Cisco-Li_0b:4f:e7 Ncr_16:c0:5e ARP 192.168.0.1 is at 00:18:f8:0b:4f:e7 9 0.737757 192.168.0.247 192.168.0.1 TFTP Read Request, File: /ltsp/i386/pxelinux.0, Transfer type: octet, blksize=1432 10 0.739513 192.168.0.1 192.168.0.247 TFTP Option Acknowledgement, blksize=1432 11 0.739640 192.168.0.247 192.168.0.1 TFTP Acknowledgement, Block: 0 12 0.739770 192.168.0.1 192.168.0.247 TFTP Data Packet, Block: 1 13 0.740292 192.168.0.247 192.168.0.1 TFTP Acknowledgement, Block: 1 14 0.740343 192.168.0.1 192.168.0.247 TFTP Data Packet, Block: 2 15 1.740598 192.168.0.1 192.168.0.247 TFTP Data Packet, Block: 2 16 3.776443 192.168.0.1 192.168.0.247 TFTP Data Packet, Block: 2 17 5.736343 Cisco-Li_0b:4f:e7 Ncr_16:c0:5e ARP Who has 192.168.0.247? Tell 192.168.0.1 18 6.736318 Cisco-Li_0b:4f:e7 Ncr_16:c0:5e ARP Who has 192.168.0.247? Tell 192.168.0.1 19 7.736294 Cisco-Li_0b:4f:e7 Ncr_16:c0:5e ARP Who has 192.168.0.247? Tell 192.168.0.1 20 7.812340 192.168.0.1 192.168.0.247 TFTP Data Packet, Block: 2 21 7.981137 192.168.0.247 255.255.255.255 DHCP DHCP Discover - Transaction ID 0xe16c176 22 7.981593 192.168.0.1 192.168.0.247 DHCP DHCP Offer - Transaction ID 0xe16c176 23 7.981976 192.168.0.247 255.255.255.255 DHCP DHCP Request - Transaction ID 0xe16c176 24 7.985617 192.168.0.1 192.168.0.247 DHCP DHCP ACK - Transaction ID 0xe16c176 25 7.985927 Ncr_16:c0:5e Broadcast ARP Who has 192.168.0.1? Tell 192.168.0.247 26 7.985959 Cisco-Li_0b:4f:e7 Ncr_16:c0:5e ARP 192.168.0.1 is at 00:18:f8:0b:4f:e7 27 7.986042 192.168.0.247 192.168.0.1 TFTP Read Request, File: /ltsp/i386/pxelinux.0, Transfer type: octet, blksize=1432 28 7.987704 192.168.0.1 192.168.0.247 TFTP Option Acknowledgement, blksize=1432 29 7.987824 192.168.0.247 192.168.0.1 TFTP Acknowledgement, Block: 0 30 7.987947 192.168.0.1 192.168.0.247 TFTP Data Packet, Block: 1 31 7.988477 192.168.0.247 192.168.0.1 TFTP Acknowledgement, Block: 1 32 7.988554 192.168.0.1 192.168.0.247 TFTP Data Packet, Block: 2 33 8.988357 192.168.0.1 192.168.0.247 TFTP Data Packet, Block: 2 34 11.024306 192.168.0.1 192.168.0.247 TFTP Data Packet, Block: 2 35 12.988160 Cisco-Li_0b:4f:e7 Ncr_16:c0:5e ARP Who has 192.168.0.247? Tell 192.168.0.1 36 13.988134 Cisco-Li_0b:4f:e7 Ncr_16:c0:5e ARP Who has 192.168.0.247? Tell 192.168.0.1 37 14.988108 Cisco-Li_0b:4f:e7 Ncr_16:c0:5e ARP Who has 192.168.0.247? Tell 192.168.0.1 38 15.060153 192.168.0.1 192.168.0.247 TFTP Data Packet, Block: 2 39 15.226659 192.168.0.247 255.255.255.255 DHCP DHCP Discover - Transaction ID 0xe16c1f6 ...and so on and so on On Feb 1, 2008 10:43 PM, ron minnich wrote: > On Feb 1, 2008 2:42 PM, Carl-Daniel Hailfinger > wrote: > > On 01.02.2008 23:05, Jeremy Wright wrote: > > > > Can Etherboot load a secondary payload like that? > > > > > Sure. I've loaded filo and etherboot with etherboot. > > ron > -------------- next part -------------- An HTML attachment was scrubbed... URL: From c-d.hailfinger.devel.2006 at gmx.net Sat Feb 2 03:22:23 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 02 Feb 2008 03:22:23 +0100 Subject: [coreboot] Capio II 320 and Coreboot In-Reply-To: References: <47A396B0.6030805@gmx.net> <47A3A049.7030906@gmx.net> <13426df10802011443u4a929be2sf5bb326318148b27@mail.gmail.com> Message-ID: <47A3D3DF.5010001@gmx.net> On 02.02.2008 02:46, Jeremy Wright wrote: > Yes, the server gets a DHCPREQUEST response to its DHCPOFFER. I took the > ethereal advice and found that not only is DHCP working, but TFTP is working > as well. I noticed it was loading the nbi.img image (sucessfully), so I > Good. How big is nbi.img? > switched it to pxelinux.0 and got a different response. The client starts to > load the pxelinux.0 image, gets to block 2, and then resets, asks for an > address via DHCP again, and starts trying to download the image again until > it gets to block 2. It will keep going in this loop forever unless I stop > it. When it loads the nbi.img file, it doesn't have the looping problem. > That looks a lot like memory problems, but it is only a gut feeling. (One image is loaded completely , another image with a possibly different load address causes a crash.) A size comparison and load address comparison could help debug the issue. > I'm a little puzzled. Should I try another version of Etherboot? I'm using > version 5.2.6. > There is a small chance that the behaviour of Etherboot 5.4.3 is different. Please try it. Is there any chance you can try to have etherboot load etherboot? The problem with that is of course that the second etherboot has to send a different ID string for its DHCP requests, otherwise you can't find out whether the new DHCP request is from the flashed etherboot after the machine resets itself or from the etherboot loaded over the network. However, my experience with etherboot is very limited, but Ron and others know a LOT about it. Regards, Carl-Daniel From wrightjmf at gmail.com Sat Feb 2 03:59:41 2008 From: wrightjmf at gmail.com (Jeremy Wright) Date: Sat, 2 Feb 2008 02:59:41 +0000 Subject: [coreboot] Capio II 320 and Coreboot In-Reply-To: <47A3D3DF.5010001@gmx.net> References: <47A396B0.6030805@gmx.net> <47A3A049.7030906@gmx.net> <13426df10802011443u4a929be2sf5bb326318148b27@mail.gmail.com> <47A3D3DF.5010001@gmx.net> Message-ID: >Good. How big is nbi.img? nbi.img is 5.6 MB and pxelinux.0 is 12.8 kB. >That looks a lot like memory problems, but it is only a gut feeling. >(One image is loaded completely , another image with a possibly >different load address causes a crash.) A size comparison and load >address comparison could help debug the issue. I tried switching out the SDRAM and it didn't make any difference. Is that what you meant or should I try a different ROM chip? Is there documentation on how to do size and load address comparisons? >There is a small chance that the behaviour of Etherboot 5.4.3 is >different. Please try it. I'll do that. >Is there any chance you can try to have etherboot load etherboot? Is there any documentation on how to load etherboot with etherboot? Thanks. On Feb 2, 2008 2:22 AM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006 at gmx.net> wrote: > On 02.02.2008 02:46, Jeremy Wright wrote: > > Yes, the server gets a DHCPREQUEST response to its DHCPOFFER. I took the > > ethereal advice and found that not only is DHCP working, but TFTP is > working > > as well. I noticed it was loading the nbi.img image (sucessfully), so I > > > > Good. How big is nbi.img? > > > switched it to pxelinux.0 and got a different response. The client > starts to > > load the pxelinux.0 image, gets to block 2, and then resets, asks for an > > address via DHCP again, and starts trying to download the image again > until > > it gets to block 2. It will keep going in this loop forever unless I > stop > > it. When it loads the nbi.img file, it doesn't have the looping problem. > > > > That looks a lot like memory problems, but it is only a gut feeling. > (One image is loaded completely , another image with a possibly > different load address causes a crash.) A size comparison and load > address comparison could help debug the issue. > > > I'm a little puzzled. Should I try another version of Etherboot? I'm > using > > version 5.2.6. > > > > There is a small chance that the behaviour of Etherboot 5.4.3 is > different. Please try it. > > Is there any chance you can try to have etherboot load etherboot? The > problem with that is of course that the second etherboot has to send a > different ID string for its DHCP requests, otherwise you can't find out > whether the new DHCP request is from the flashed etherboot after the > machine resets itself or from the etherboot loaded over the network. > > However, my experience with etherboot is very limited, but Ron and > others know a LOT about it. > > > Regards, > Carl-Daniel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Sat Feb 2 04:21:06 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 1 Feb 2008 19:21:06 -0800 Subject: [coreboot] Capio II 320 and Coreboot In-Reply-To: <47A3D3DF.5010001@gmx.net> References: <47A396B0.6030805@gmx.net> <47A3A049.7030906@gmx.net> <13426df10802011443u4a929be2sf5bb326318148b27@mail.gmail.com> <47A3D3DF.5010001@gmx.net> Message-ID: <13426df10802011921y2a510fj302dc5581512266a@mail.gmail.com> where does nbi.img load and where does etherboot load? ron From wrightjmf at gmail.com Sat Feb 2 04:39:11 2008 From: wrightjmf at gmail.com (Jeremy Wright) Date: Sat, 2 Feb 2008 03:39:11 +0000 Subject: [coreboot] Capio II 320 and Coreboot In-Reply-To: <13426df10802011921y2a510fj302dc5581512266a@mail.gmail.com> References: <47A396B0.6030805@gmx.net> <47A3A049.7030906@gmx.net> <13426df10802011443u4a929be2sf5bb326318148b27@mail.gmail.com> <47A3D3DF.5010001@gmx.net> <13426df10802011921y2a510fj302dc5581512266a@mail.gmail.com> Message-ID: I'm not sure where either of the images load since I can't run any applications locally on the client. Is there a way to see where applications load from there server side? Sorry if that's a naive question, but I'm pretty new to this. On Feb 2, 2008 3:21 AM, ron minnich wrote: > where does nbi.img load and where does etherboot load? > > ron > -------------- next part -------------- An HTML attachment was scrubbed... URL: From garrett at derner.com Sat Feb 2 05:01:46 2008 From: garrett at derner.com (Garrett Derner) Date: Fri, 01 Feb 2008 22:01:46 -0600 Subject: [coreboot] LinuxBIOS on VIA EPIA EN15000 In-Reply-To: <4796FEA6.9000908@gmail.com> References: <31HsNmXE.1200994157.0775580.bernhard.maenner@mail.cablevision.at> <20080122193152.601.qmail@stuge.se> <4796FEA6.9000908@gmail.com> Message-ID: <47A3EB2A.1030304@derner.com> I have a PC2500E and would like to help. How do I get started? At the moment I am running it with a single 1GB stick, but if it helps, I am willing to add a second dimm. I am using Kubuntu most of the time, and also have Gentoo and Syllable set up. Garrett Derner > ... I will need a sucker, I mean, volunteer who has a > board like the gOS desktop board with multiple dimms to give this a shot > eventually, I still don't have one, and this winter's been a lot harder > on my wallet then I expected. > > -Corey > > From jakllsch at kollasch.net Sat Feb 2 05:21:14 2008 From: jakllsch at kollasch.net (jakllsch at kollasch.net) Date: Fri, 1 Feb 2008 22:21:14 -0600 Subject: [coreboot] [patch] add MSI MS-7135 support, try two Message-ID: <20080202042114.GD1756@kirkkit.kollasch.net> Initial support for MSI MS-7135 (K8N Neo3) mainboard. Signed-off-by: Jonathan A. Kollasch -------------- next part -------------- Index: src/mainboard/msi/ms7135/Config.lb =================================================================== --- src/mainboard/msi/ms7135/Config.lb (revision 0) +++ src/mainboard/msi/ms7135/Config.lb (revision 0) @@ -0,0 +1,306 @@ +## +## This file is part of the coreboot project. +## +## Copyright (C) 2007 AMD +## (Written by Yinghai Lu for AMD) +## Copyright (C) 2007 Philipp Degler +## (Thanks to LSRA University of Mannheim for their support) +## Copyright (C) 2008 Jonathan A. Kollasch +## +## This program is free software; you can redistribute it and/or modify +## it under the terms of the GNU General Public License as published by +## the Free Software Foundation; either version 2 of the License, or +## (at your option) any later version. +## +## This program is distributed in the hope that it will be useful, +## but WITHOUT ANY WARRANTY; without even the implied warranty of +## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +## GNU General Public License for more details. +## +## You should have received a copy of the GNU General Public License +## along with this program; if not, write to the Free Software +## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +## + +## +## Compute the location and size of where this firmware image +## (coreboot plus bootloader) will live in the boot rom chip. +## +if USE_FAILOVER_IMAGE + default ROM_SECTION_SIZE = FAILOVER_SIZE + default ROM_SECTION_OFFSET = (ROM_SIZE - FAILOVER_SIZE) +else + if USE_FALLBACK_IMAGE + default ROM_SECTION_SIZE = FALLBACK_SIZE + default ROM_SECTION_OFFSET = (ROM_SIZE - FALLBACK_SIZE - FAILOVER_SIZE) + else + default ROM_SECTION_SIZE = (ROM_SIZE - FALLBACK_SIZE - FAILOVER_SIZE) + default ROM_SECTION_OFFSET = 0 + end +end + +## +## Compute the start location and size size of the coreboot bootloader. +## +default PAYLOAD_SIZE = (ROM_SECTION_SIZE - ROM_IMAGE_SIZE) +default CONFIG_ROM_PAYLOAD_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) + +## +## Compute where this copy of coreboot will start in the boot ROM. +## +default _ROMBASE = ( CONFIG_ROM_PAYLOAD_START + PAYLOAD_SIZE ) + +## +## Compute a range of ROM that can be cached to speed up coreboot +## execution speed. +## +## XIP_ROM_SIZE must be a power of 2 (here 64 Kbyte) +## XIP_ROM_BASE must be a multiple of XIP_ROM_SIZE +## +default XIP_ROM_SIZE = (64 * 1024) + +if USE_FAILOVER_IMAGE + default XIP_ROM_BASE = (_ROMBASE - XIP_ROM_SIZE + ROM_IMAGE_SIZE) +else + if USE_FALLBACK_IMAGE + default XIP_ROM_BASE = (_ROMBASE - XIP_ROM_SIZE + ROM_IMAGE_SIZE + FAILOVER_SIZE) + else + default XIP_ROM_BASE = (_ROMBASE - XIP_ROM_SIZE + ROM_IMAGE_SIZE) + end +end + +arch i386 end + +## +## Build the objects we have code for in this directory. +## + +driver mainboard.o + +#dir /drivers/ati/ragexl + +# Needed by irq_tables and mptable and acpi_tables. +object get_bus_conf.o + +if HAVE_MP_TABLE + object mptable.o +end + +if HAVE_PIRQ_TABLE + object irq_tables.o +end + +if USE_DCACHE_RAM + if CONFIG_USE_INIT + makerule ./auto.o + depends "$(MAINBOARD)/cache_as_ram_auto.c option_table.h" + action "$(CC) -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/cache_as_ram_auto.c -Os -nostdinc -nostdlib -fno-builtin -Wall -c -o $@" + end + else + makerule ./auto.inc + depends "$(MAINBOARD)/cache_as_ram_auto.c option_table.h" + action "$(CC) -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/cache_as_ram_auto.c -Os -nostdinc -nostdlib -fno-builtin -Wall -c -S -o $@" + action "perl -e 's/.rodata/.rom.data/g' -pi $@" + action "perl -e 's/.text/.section .rom.text/g' -pi $@" + end + end +end + +## +## Build our 16 bit and 32 bit coreboot entry code. +## +if HAVE_FAILOVER_BOOT + if USE_FAILOVER_IMAGE + mainboardinit cpu/x86/16bit/entry16.inc + ldscript /cpu/x86/16bit/entry16.lds + end +else + if USE_FALLBACK_IMAGE + mainboardinit cpu/x86/16bit/entry16.inc + ldscript /cpu/x86/16bit/entry16.lds + end +end + +mainboardinit cpu/x86/32bit/entry32.inc + +if USE_DCACHE_RAM + if CONFIG_USE_INIT + ldscript /cpu/x86/32bit/entry32.lds + ldscript /cpu/amd/car/cache_as_ram.lds + end +end + +## +## Build our reset vector (this is where coreboot is entered). +## +if HAVE_FAILOVER_BOOT + if 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 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 + +if USE_DCACHE_RAM +else + ### Should this be in the northbridge code? + mainboardinit arch/i386/lib/cpu_reset.inc +end + +## +## Include an ID string (for safe flashing). +## +mainboardinit southbridge/nvidia/ck804/id.inc +ldscript /southbridge/nvidia/ck804/id.lds + +## +## ROMSTRAP table for CK804 +## +if HAVE_FAILOVER_BOOT + if USE_FAILOVER_IMAGE + mainboardinit southbridge/nvidia/ck804/romstrap.inc + ldscript /southbridge/nvidia/ck804/romstrap.lds + end +else + if USE_FALLBACK_IMAGE + mainboardinit southbridge/nvidia/ck804/romstrap.inc + ldscript /southbridge/nvidia/ck804/romstrap.lds + end +end + +if USE_DCACHE_RAM + ## + ## Setup Cache-As-Ram + ## + mainboardinit cpu/amd/car/cache_as_ram.inc +end + + +### +### This is the early phase of coreboot startup. +### Things are delicate and we test to see if we should +### failover to another image. +### +if HAVE_FAILOVER_BOOT + if USE_FAILOVER_IMAGE + if USE_DCACHE_RAM + ldscript /arch/i386/lib/failover_failover.lds + end + end +else + if USE_FALLBACK_IMAGE + if USE_DCACHE_RAM + ldscript /arch/i386/lib/failover.lds + end + end +end + +### +### O.k. We aren't just an intermediary anymore! +### + +## +## Setup RAM +## +if USE_DCACHE_RAM + if CONFIG_USE_INIT + initobject auto.o + else + mainboardinit ./auto.inc + end +end + +## +## Include the secondary configuration files +## +if CONFIG_CHIP_NAME + config chip.h +end + +chip northbridge/amd/amdk8/root_complex # Root complex + device apic_cluster 0 on # APIC cluster + chip cpu/amd/socket_754 # Socket 754 CPU + device apic 0 on end # APIC + end + end + + device pci_domain 0 on # PCI domain + chip northbridge/amd/amdk8 # mc0 + device pci 18.0 on # Northbridge + # Devices on link 0, link 0 == LDT 0 + chip southbridge/nvidia/ck804 # Southbridge + device pci 0.0 on end # HT + device pci 1.0 on # LPC + chip superio/winbond/w83627thf # Super I/O + device pnp 2e.0 off # Floppy + io 0x60 = 0x3f0 + irq 0x70 = 6 + drq 0x74 = 2 + end + device pnp 2e.1 on # Parallel port + io 0x60 = 0x378 + irq 0x70 = 0 + end + device pnp 2e.2 on # Com1 + io 0x60 = 0x3f8 + irq 0x70 = 4 + end + device pnp 2e.3 on # Com2 + io 0x60 = 0x2f8 + irq 0x70 = 3 + end + device pnp 2e.5 on # PS/2 keyboard + io 0x60 = 0x60 + io 0x62 = 0x64 + irq 0x70 = 1 + irq 0x72 = 12 + end + device pnp 2e.6 off end # non-existant or undocumented + device pnp 2e.7 off end # Game, MIDI, GPIO 1, GPIO 5 + device pnp 2e.8 off end # GPIO 2 + device pnp 2e.9 off end # GPIO 3, GPIO 4 + device pnp 2e.a off end # ACPI + device pnp 2e.b on # env monitor + io 0x60 = 0x290 + irq 0x70 = 0 + end + end + end + device pci 1.1 on end # SMbus + device pci 2.0 on end # USB 1.1 + device pci 2.1 on end # USB 2 + device pci 4.0 on end # Onboard audio (ACI) + device pci 4.1 off end # Onboard modem (MCI) -- not wired out + device pci 6.0 on end # IDE + device pci 7.0 on end # SATA 1 + device pci 8.0 on end # SATA 0 + device pci 9.0 on end # PCI + device pci a.0 on end # NIC + device pci b.0 off end # PCI E 3 -- not wired out + device pci c.0 off end # PCI E 2 -- not wired out + device pci d.0 on end # PCI E 1 + device pci e.0 on end # PCI E 0 + register "ide0_enable" = "1" + register "ide1_enable" = "1" + register "sata0_enable" = "1" + register "sata1_enable" = "1" + # register "mac_eeprom_smbus" = "3" + # register "mac_eeprom_addr" = "0x51" + end + end + device pci 18.1 on end + device pci 18.2 on end + device pci 18.3 on end + end + end +end Index: src/mainboard/msi/ms7135/mptable.c =================================================================== --- src/mainboard/msi/ms7135/mptable.c (revision 0) +++ src/mainboard/msi/ms7135/mptable.c (revision 0) @@ -0,0 +1,226 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2007 AMD + * (Written by Yinghai Lu for AMD) + * Copyright (C) 2007 Philipp Degler + * (Thanks to LSRA University of Mannheim for their support) + * Copyright (C) 2008 Jonathan A. Kollasch + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include +#include +#include +#include + +#include + +extern unsigned char bus_isa; +extern unsigned char bus_ck804[6]; +extern unsigned apicid_ck804; + +extern unsigned bus_type[256]; + +extern void get_bus_conf(void); + +void *smp_write_config_table(void *v) +{ + static const char sig[4] = "PCMP"; + static const char oem[8] = "MSI "; + static const char productid[12] = "MS7135 "; + struct mp_config_table *mc; + unsigned sbdn; + + int bus_num; + int i; + + mc = (void *)(((char *)v) + SMP_FLOATING_TABLE_LEN); + memset(mc, 0, sizeof(*mc)); + + memcpy(mc->mpc_signature, sig, sizeof(sig)); + mc->mpc_length = sizeof(*mc); /* initially just the header */ + mc->mpc_spec = 0x04; + mc->mpc_checksum = 0; /* not yet computed */ + memcpy(mc->mpc_oem, oem, sizeof(oem)); + memcpy(mc->mpc_productid, productid, sizeof(productid)); + mc->mpc_oemptr = 0; + mc->mpc_oemsize = 0; + mc->mpc_entry_count = 0; /* No entries yet... */ + mc->mpc_lapic = LAPIC_ADDR; + mc->mpe_length = 0; + mc->mpe_checksum = 0; + mc->reserved = 0; + + smp_write_processors(mc); + + get_bus_conf(); + sbdn = sysconf.sbdn; + +/* Bus: Bus ID Type*/ + /* define numbers for pci and isa bus */ + for (bus_num = 0; bus_num < 256; bus_num++) { + if (bus_type[bus_num]) + smp_write_bus(mc, bus_num, "PCI "); + } + smp_write_bus(mc, bus_isa, "ISA "); + + +/* I/O APICs: APIC ID Version State Address*/ + { + device_t dev; + struct resource *res; + uint32_t dword; + + dev = dev_find_slot(bus_ck804[0], PCI_DEVFN(sbdn + 0x1, 0)); + if (dev) { + res = find_resource(dev, PCI_BASE_ADDRESS_1); + if (res) { + smp_write_ioapic(mc, apicid_ck804, 0x11, + res->base); + } + + /* Initialize interrupt mapping */ + + /* copied from stock bios */ + /*0x01800500,0x1800d509,0x00520d08*/ + + /* if this register is what i think it is ... */ + dword = 0x08d0d218; + pci_write_config32(dev, 0x7c, dword); + + dword = 0x8d001509; + pci_write_config32(dev, 0x80, dword); + + dword = 0x00010271; + pci_write_config32(dev, 0x84, dword); + + } + } + +/*I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# */ + smp_write_intsrc(mc, mp_ExtINT, + MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, + bus_isa, 0x0, apicid_ck804, 0x0); + smp_write_intsrc(mc, mp_INT, + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, + bus_isa, 0x1, apicid_ck804, 0x1); + smp_write_intsrc(mc, mp_INT, + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, + bus_isa, 0x0, apicid_ck804, 0x2); + smp_write_intsrc(mc, mp_INT, + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, + bus_isa, 0x3, apicid_ck804, 0x3); + smp_write_intsrc(mc, mp_INT, + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, + bus_isa, 0x4, apicid_ck804, 0x4); + + smp_write_intsrc(mc, mp_INT, + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, + bus_isa, 0x6, apicid_ck804, 0x6); + smp_write_intsrc(mc, mp_INT, + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, + bus_isa, 0x7, apicid_ck804, 0x7); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, + bus_isa, 0x8, apicid_ck804, 0x8); + smp_write_intsrc(mc, mp_INT, + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, + bus_isa, 0x9, apicid_ck804, 0x9); + + smp_write_intsrc(mc, mp_INT, + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, + bus_isa, 0xc, apicid_ck804, 0xc); + smp_write_intsrc(mc, mp_INT, + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, + bus_isa, 0xd, apicid_ck804, 0xd); + smp_write_intsrc(mc, mp_INT, + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, + bus_isa, 0xe, apicid_ck804, 0xe); + smp_write_intsrc(mc, mp_INT, + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, + bus_isa, 0xf, apicid_ck804, 0xf); + + // Onboard ck804 smbus + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[0], ((sbdn + 1) << 2) | 1, apicid_ck804, 10); /* (this seems odd) */ + + // Onboard ck804 USB 1.1 + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[0], ((sbdn + 2) << 2) | 0, apicid_ck804, 23); + + // Onboard ck804 USB 2.0 + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[0], ((sbdn + 2) << 2) | 1, apicid_ck804, 23); + + // Onboard ck804 AC-97 + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[0], ((sbdn + 4) << 2) | 0, apicid_ck804, 23); + + // Onboard ck804 SATA 0 + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[0], ((sbdn + 7) << 2) | 0, apicid_ck804, 20); + + // Onboard ck804 SATA 1 + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[0], ((sbdn + 8) << 2) | 0, apicid_ck804, 21); + + // Onboard ck804 NIC + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[0], ((sbdn + 10) << 2) | 0, apicid_ck804, 22); // should be 21 + + /* legacy PCI */ + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[1], (7 << 2) | 0, apicid_ck804, 17); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[1], (7 << 2) | 1, apicid_ck804, 18); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[1], (7 << 2) | 2, apicid_ck804, 19); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[1], (7 << 2) | 3, apicid_ck804, 16); + /* --- */ + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[1], (8 << 2) | 0, apicid_ck804, 18); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[1], (8 << 2) | 1, apicid_ck804, 19); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[1], (8 << 2) | 2, apicid_ck804, 16); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[1], (8 << 2) | 3, apicid_ck804, 17); + /* --- */ + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[1], (9 << 2) | 0, apicid_ck804, 19); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[1], (9 << 2) | 1, apicid_ck804, 16); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[1], (9 << 2) | 2, apicid_ck804, 17); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[1], (9 << 2) | 3, apicid_ck804, 18); + + /* PCI-E x1 port */ + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[2], (0 << 2) | 0, apicid_ck804, 19); + /* XXX fill in f1-3 */ + + /* PCI-E x16 port */ /* XXX fix me */ + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[3], (0 << 2) | 0, apicid_ck804, 18); + /* XXX fill in f1-3 */ + +/*Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN#*/ + smp_write_lintsrc(mc, mp_ExtINT, + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, + bus_ck804[0], 0x0, MP_APIC_ALL, 0x0); + smp_write_lintsrc(mc, mp_NMI, + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, + bus_ck804[0], 0x0, MP_APIC_ALL, 0x1); + + /* There is no extension information... */ + + /* Compute the checksums */ + mc->mpe_checksum = + smp_compute_checksum(smp_next_mpc_entry(mc), mc->mpe_length); + mc->mpc_checksum = smp_compute_checksum(mc, mc->mpc_length); + printk_debug("Wrote the mp table end at: %p - %p\n", + mc, smp_next_mpe_entry(mc)); + return smp_next_mpe_entry(mc); +} + +unsigned long write_smp_table(unsigned long addr) +{ + void *v; + v = smp_write_floating_table(addr); + return (unsigned long)smp_write_config_table(v); +} Index: src/mainboard/msi/ms7135/irq_tables.c =================================================================== --- src/mainboard/msi/ms7135/irq_tables.c (revision 0) +++ src/mainboard/msi/ms7135/irq_tables.c (revision 0) @@ -0,0 +1,260 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2007 AMD + * (Written by Yinghai Lu for AMD) + * Copyright (C) 2007 Philipp Degler + * (Thanks to LSRA University of Mannheim for their support) + * Copyright (C) 2008 Jonathan A. Kollasch + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +/* Documentation at: http://www.microsoft.com/hwdev/busbios/PCIIRQ.HTM */ + +#include +#include +#include +#include +#include +#include + +extern unsigned char bus_isa; +extern unsigned char bus_ck804[6]; +extern void get_bus_conf(void); + +/** + * Add one line to IRQ table. + */ +static void write_pirq_info(struct irq_info *pirq_info, uint8_t bus, + uint8_t devfn, uint8_t link0, uint16_t bitmap0, + uint8_t link1, uint16_t bitmap1, uint8_t link2, + uint16_t bitmap2, uint8_t link3, uint16_t bitmap3, + uint8_t slot, uint8_t rfu) +{ + pirq_info->bus = bus; + pirq_info->devfn = devfn; + pirq_info->irq[0].link = link0; + pirq_info->irq[0].bitmap = bitmap0; + pirq_info->irq[1].link = link1; + pirq_info->irq[1].bitmap = bitmap1; + pirq_info->irq[2].link = link2; + pirq_info->irq[2].bitmap = bitmap2; + pirq_info->irq[3].link = link3; + pirq_info->irq[3].bitmap = bitmap3; + pirq_info->slot = slot; + pirq_info->rfu = rfu; +} + +void pci_assign_irqs(unsigned, unsigned, const unsigned char *); + +/** + * Create the IRQ routing table. + * Values are derived from getpir generated code. + */ +unsigned long write_pirq_routing_table(unsigned long addr) +{ + + struct irq_routing_table *pirq; + struct irq_info *pirq_info; + unsigned slot_num; + uint8_t *v; + + uint8_t sum = 0; + int i; + unsigned sbdn; + + /* get_bus_conf() will find out all bus num and apic that share with + * mptable.c and mptable.c + */ + get_bus_conf(); + sbdn = sysconf.sbdn; + + /* Align the table to be 16 byte aligned. */ + addr += 15; + addr &= ~15; + + /* This table must be betweeen 0xf0000 & 0x100000 */ + printk_info("Writing IRQ routing tables to 0x%x...", addr); + + pirq = (void *)(addr); + v = (uint8_t *) (addr); + + pirq->signature = PIRQ_SIGNATURE; + pirq->version = PIRQ_VERSION; + + pirq->rtr_bus = bus_ck804[0]; + pirq->rtr_devfn = ((sbdn + 9) << 3) | 0; + + pirq->exclusive_irqs = 0x828; + + pirq->rtr_vendor = 0x10de; + pirq->rtr_device = 0x005c; + + pirq->miniport_data = 0; + + memset(pirq->rfu, 0, sizeof(pirq->rfu)); + + pirq_info = (void *)(&pirq->checksum + 1); + slot_num = 0; + +//Slot1 PCIE 16x + write_pirq_info(pirq_info, bus_ck804[1], (0 << 3) | 0, 0x3, 0xdeb8, 0x4, + 0xdeb8, 0x1, 0xdeb8, 0x2, 0xdeb8, 4, 0); + pirq_info++; + slot_num++; + +//Slot2 PCIE 1x + write_pirq_info(pirq_info, bus_ck804[2], (0 << 3) | 0, 0x4, 0xdeb8, 0x1, + 0xdeb8, 0x2, 0xdeb8, 0x3, 0xdeb8, 5, 0); + pirq_info++; + slot_num++; + +//Slot3 PCIE 1x + write_pirq_info(pirq_info, bus_ck804[3], (0 << 3) | 0, 0x1, 0xdeb8, 0x2, + 0xdeb8, 0x3, 0xdeb8, 0x4, 0xdeb8, 6, 0); + pirq_info++; + slot_num++; + +//Slot4 PCIE 4x + write_pirq_info(pirq_info, bus_ck804[4], (0x4 << 3) | 0, + 0x2, 0xdeb8, 0x3, 0xdeb8, 0x4, 0xdeb8, 0x1, 0xdeb8, + 7, 0); + pirq_info++; + slot_num++; + +//Slot5 - 7 PCI + for (i = 0; i < 3; i++) { + write_pirq_info(pirq_info, bus_ck804[5], (0 << (6 + i)) | 0, + ((i + 0) % 4) + 1, 0xdeb8, + ((i + 1) % 4) + 1, 0xdeb8, + ((i + 2) % 4) + 1, 0xdeb8, + ((i + 3) % 4) + 1, 0xdeb8, i, 0); + pirq_info++; + slot_num++; + } + +//pci bridge + write_pirq_info(pirq_info, bus_ck804[0], ((sbdn + 9) << 3) | 0, 0x1, + 0xdeb8, 0x2, 0xdeb8, 0x3, 0xdeb8, 0x4, 0xdeb8, 0, 0); + pirq_info++; + slot_num++; + +//smbus + write_pirq_info(pirq_info, bus_ck804[0], ((sbdn + 1) << 3) | 0, 0x2, + 0xdeb8, 0, 0, 0, 0, 0, 0, 0, 0); + pirq_info++; + slot_num++; + +//usb + write_pirq_info(pirq_info, bus_ck804[0], ((sbdn + 2) << 3) | 0, 0x1, + 0xdeb8, 0x2, 0xdeb8, 0, 0, 0, 0, 0, 0); + pirq_info++; + slot_num++; + +//audio + write_pirq_info(pirq_info, bus_ck804[0], ((sbdn + 4) << 3) | 0, 0x1, + 0xdeb8, 0, 0, 0, 0, 0, 0, 0, 0); + pirq_info++; + slot_num++; +//sata + write_pirq_info(pirq_info, bus_ck804[0], ((sbdn + 7) << 3) | 0, 0x1, + 0xdeb8, 0, 0, 0, 0, 0, 0, 0, 0); + pirq_info++; + slot_num++; +//sata + write_pirq_info(pirq_info, bus_ck804[0], ((sbdn + 8) << 3) | 0, 0x1, + 0xdeb8, 0, 0, 0, 0, 0, 0, 0, 0); + pirq_info++; + slot_num++; +//nic + write_pirq_info(pirq_info, bus_ck804[0], ((sbdn + 0xa) << 3) | 0, 0x1, + 0xdeb8, 0, 0, 0, 0, 0, 0, 0, 0); + pirq_info++; + slot_num++; + + pirq->size = 32 + 16 * slot_num; + + for (i = 0; i < pirq->size; i++) + sum += v[i]; + + sum = pirq->checksum - sum; + + if (sum != pirq->checksum) { + pirq->checksum = sum; + } + + printk_info("done.\n"); + + unsigned char irq[4]; + irq[0] = 0; + irq[1] = 0; + irq[2] = 0; + irq[3] = 0; + + /* Bus, device, slots IRQs for {A,B,C,D}. */ + + irq[0] = 10; /* SMBus */ /* test me */ + pci_assign_irqs(bus_ck804[0], 1, irq); + + irq[0] = 10; /* USB */ + irq[1] = 10; + pci_assign_irqs(bus_ck804[0], 2, irq); + + irq[0] = 10; /* AC97 */ + irq[1] = 0; + pci_assign_irqs(bus_ck804[0], 4, irq); + + irq[0] = 11; /* SATA */ + pci_assign_irqs(bus_ck804[0], 7, irq); + + irq[0] = 5; /* SATA */ + pci_assign_irqs(bus_ck804[0], 8, irq); + + irq[0] = 10; /* Ethernet */ + pci_assign_irqs(bus_ck804[0], 10, irq); + + + /* physical slots */ + + irq[0] = 5; /* PCI E1 - x1 */ + pci_assign_irqs(bus_ck804[2], 0, irq); + + irq[0] = 11; /* PCI E2 - x16 */ + pci_assign_irqs(bus_ck804[3], 0, irq); + + /* AGP-on-PCI "AGR" ignored */ + + irq[0] = 10; /* PCI1 */ + irq[1] = 11; + irq[2] = 5; + irq[3] = 0; + pci_assign_irqs(bus_ck804[1], 7, irq); + + irq[0] = 11; /* PCI2 */ + irq[1] = 10; + irq[2] = 5; + irq[3] = 0; + pci_assign_irqs(bus_ck804[1], 8, irq); + + irq[0] = 5; /* PCI3 */ + irq[1] = 10; + irq[2] = 11; + irq[3] = 0; + pci_assign_irqs(bus_ck804[1], 9, irq); + + + return (unsigned long)pirq_info; +} Index: src/mainboard/msi/ms7135/Options.lb =================================================================== --- src/mainboard/msi/ms7135/Options.lb (revision 0) +++ src/mainboard/msi/ms7135/Options.lb (revision 0) @@ -0,0 +1,321 @@ +## +## This file is part of the coreboot project. +## +## Copyright (C) 2007 Philipp Degler +## (Thanks to LSRA University of Mannheim for their support) +## Copyright (C) 2008 Jonathan A. Kollasch +## +## This program is free software; you can redistribute it and/or modify +## it under the terms of the GNU General Public License as published by +## the Free Software Foundation; either version 2 of the License, or +## (at your option) any later version. +## +## This program is distributed in the hope that it will be useful, +## but WITHOUT ANY WARRANTY; without even the implied warranty of +## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +## GNU General Public License for more details. +## +## You should have received a copy of the GNU General Public License +## along with this program; if not, write to the Free Software +## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +## + +uses HAVE_MP_TABLE +uses HAVE_PIRQ_TABLE +uses USE_FALLBACK_IMAGE +uses USE_FAILOVER_IMAGE +uses HAVE_FALLBACK_BOOT +uses HAVE_FAILOVER_BOOT +uses HAVE_HARD_RESET +uses IRQ_SLOT_COUNT +uses HAVE_OPTION_TABLE +uses CONFIG_MAX_CPUS +uses CONFIG_MAX_PHYSICAL_CPUS +uses CONFIG_LOGICAL_CPUS +uses CONFIG_IOAPIC +uses CONFIG_SMP +uses FALLBACK_SIZE +uses FAILOVER_SIZE +uses ROM_SIZE +uses ROM_SECTION_SIZE +uses ROM_IMAGE_SIZE +uses ROM_SECTION_SIZE +uses ROM_SECTION_OFFSET +uses CONFIG_ROM_PAYLOAD +uses CONFIG_ROM_PAYLOAD_START +uses CONFIG_COMPRESSED_PAYLOAD_LZMA +uses PAYLOAD_SIZE +uses _ROMBASE +uses XIP_ROM_SIZE +uses XIP_ROM_BASE +uses STACK_SIZE +uses HEAP_SIZE +uses USE_OPTION_TABLE +uses LB_CKS_RANGE_START +uses LB_CKS_RANGE_END +uses LB_CKS_LOC +uses MAINBOARD_PART_NUMBER +uses MAINBOARD_VENDOR +uses MAINBOARD +uses MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID +uses MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID +uses COREBOOT_EXTRA_VERSION +uses _RAMBASE +uses CONFIG_GDB_STUB +uses CROSS_COMPILE +uses CC +uses HOSTCC +uses OBJCOPY +uses TTYS0_BAUD +uses TTYS0_BASE +uses TTYS0_LCS +uses DEFAULT_CONSOLE_LOGLEVEL +uses MAXIMUM_CONSOLE_LOGLEVEL +uses MAINBOARD_POWER_ON_AFTER_POWER_FAIL +uses CONFIG_CONSOLE_SERIAL8250 +uses CONFIG_CONSOLE_BTEXT +uses HAVE_INIT_TIMER +uses CONFIG_GDB_STUB +uses CONFIG_CHIP_NAME +uses CONFIG_CONSOLE_VGA +uses CONFIG_PCI_ROM_RUN +uses HW_MEM_HOLE_SIZEK + +uses USE_DCACHE_RAM +uses DCACHE_RAM_BASE +uses DCACHE_RAM_SIZE +uses CONFIG_USE_INIT +uses DCACHE_RAM_GLOBAL_VAR_SIZE +uses CONFIG_AP_CODE_IN_CAR +uses MEM_TRAIN_SEQ +uses WAIT_BEFORE_CPUS_INIT + +uses ENABLE_APIC_EXT_ID +uses APIC_ID_OFFSET +uses LIFT_BSP_APIC_ID + +uses CONFIG_PCI_64BIT_PREF_MEM + +uses HT_CHAIN_UNITID_BASE +uses HT_CHAIN_END_UNITID_BASE +uses SB_HT_CHAIN_ON_BUS0 +uses SB_HT_CHAIN_UNITID_OFFSET_ONLY + +uses CONFIG_LB_MEM_TOPK + + +## ROM_SIZE is the size of boot ROM that this board will use. +## ---> 512 Kbytes +default ROM_SIZE=(512*1024) + +## +## FALLBACK_SIZE is the amount of the ROM the complete fallback image will use +## +default FALLBACK_SIZE=(252*1024) + +#FAILOVER: 4K +default FAILOVER_SIZE=(4*1024) + +### +### Build options +### + +## +## Build code for the fallback boot +## +default HAVE_FALLBACK_BOOT=1 +default HAVE_FAILOVER_BOOT=1 + +## +## Build code to reset the motherboard from coreboot +## +default HAVE_HARD_RESET=1 + +## +## Build code to export a programmable irq routing table +## +default HAVE_PIRQ_TABLE=1 +default IRQ_SLOT_COUNT=13 + +## +## Build code to export an x86 MP table +## Useful for specifying IRQ routing values +## +default HAVE_MP_TABLE=1 + +## +## Build code to export a CMOS option table +## +default HAVE_OPTION_TABLE=1 + +## +## Move the default coreboot cmos range off of AMD RTC registers +## +default LB_CKS_RANGE_START=49 +default LB_CKS_RANGE_END=122 +default LB_CKS_LOC=123 + +## +## Build code for SMP support +## Only worry about 2 micro processors +## +default CONFIG_SMP=1 +default CONFIG_MAX_CPUS=2 +default CONFIG_MAX_PHYSICAL_CPUS=1 +default CONFIG_LOGICAL_CPUS=1 + +#1G memory hole +default HW_MEM_HOLE_SIZEK=0x100000 + +##HT Unit ID offset, default is 1, the typical one +default HT_CHAIN_UNITID_BASE=0 + +##real SB Unit ID, default is 0x20, mean dont touch it at last +#default HT_CHAIN_END_UNITID_BASE=0x10 + +#make the SB HT chain on bus 0, default is not (0) +default SB_HT_CHAIN_ON_BUS0=2 + +##only offset for SB chain?, default is yes(1) +default SB_HT_CHAIN_UNITID_OFFSET_ONLY=0 + +#BTEXT Console +#default CONFIG_CONSOLE_BTEXT=1 + +#VGA Console +default CONFIG_CONSOLE_VGA=1 +default CONFIG_PCI_ROM_RUN=1 + +## +## enable CACHE_AS_RAM specifics +## +default USE_DCACHE_RAM=1 +#default DCACHE_RAM_BASE=0xcf000 +#default DCACHE_RAM_SIZE=0x1000 +default DCACHE_RAM_BASE=0xc8000 +default DCACHE_RAM_SIZE=0x08000 +default DCACHE_RAM_GLOBAL_VAR_SIZE=0x01000 +default CONFIG_USE_INIT=0 + +default CONFIG_AP_CODE_IN_CAR=0 +default MEM_TRAIN_SEQ=2 +default WAIT_BEFORE_CPUS_INIT=0 + +## APIC stuff +#default ENABLE_APIC_EXT_ID=0 +#default APIC_ID_OFFSET=0x10 +#default LIFT_BSP_APIC_ID=0 + + +#default CONFIG_PCI_64BIT_PREF_MEM=1 + +## +## Build code to setup a generic IOAPIC +## +default CONFIG_IOAPIC=1 + +## +## Clean up the motherboard id strings +## +default MAINBOARD_PART_NUMBER="K8N Neo3 (MS-7135)" +default MAINBOARD_VENDOR="MSI" +default MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID=0x1462 +default MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID=0x7135 + +### +### coreboot layout values +### + +## ROM_IMAGE_SIZE is the amount of space to allow coreboot to occupy. +default ROM_IMAGE_SIZE = (64*1024) +#65536 + +## +## Use a small 8K stack +## +default STACK_SIZE=0x2000 + +## +## Use a small 16K heap +## +default HEAP_SIZE=0x4000 + +## +## Only use the option table in a normal image +## +#efault USE_OPTION_TABLE = !USE_FALLBACK_IMAGE +default USE_OPTION_TABLE = (!USE_FALLBACK_IMAGE) && (!USE_FAILOVER_IMAGE ) + +## +## coreboot C code runs at this location in RAM +## +default _RAMBASE=0x00004000 + +## +## Load the payload from the ROM +## +default CONFIG_ROM_PAYLOAD = 1 + +### +### Defaults of options that you may want to override in the target config file +### + +## +## The default compiler +## +default CC="$(CROSS_COMPILE)gcc -m32" +default HOSTCC="gcc" + +## +## Disable the gdb stub by default +## +default CONFIG_GDB_STUB=0 + +## +## The Serial Console +## + +# To Enable the Serial Console +default CONFIG_CONSOLE_SERIAL8250=1 + +## Select the serial console baud rate +default TTYS0_BAUD=115200 +#default TTYS0_BAUD=57600 +#default TTYS0_BAUD=38400 +#default TTYS0_BAUD=19200 +#default TTYS0_BAUD=9600 +#default TTYS0_BAUD=4800 +#default TTYS0_BAUD=2400 +#default TTYS0_BAUD=1200 + +# Select the serial console base port +default TTYS0_BASE=0x3f8 + +# Select the serial protocol +# This defaults to 8 data bits, 1 stop bit, and no parity +default TTYS0_LCS=0x3 + +## +### Select the coreboot loglevel +## +## EMERG 1 system is unusable +## ALERT 2 action must be taken immediately +## CRIT 3 critical conditions +## ERR 4 error conditions +## WARNING 5 warning conditions +## NOTICE 6 normal but significant condition +## INFO 7 informational +## DEBUG 8 debug-level messages +## SPEW 9 Way too many details + +## Request this level of debugging output +default DEFAULT_CONSOLE_LOGLEVEL=8 +## At a maximum only compile in this level of debugging +default MAXIMUM_CONSOLE_LOGLEVEL=8 + +## +## Select power on after power fail setting +default MAINBOARD_POWER_ON_AFTER_POWER_FAIL="MAINBOARD_POWER_ON" + +### End Options.lb +end Index: src/mainboard/msi/ms7135/chip.h =================================================================== --- src/mainboard/msi/ms7135/chip.h (revision 0) +++ src/mainboard/msi/ms7135/chip.h (revision 0) @@ -0,0 +1,25 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2008 Jonathan A. Kollasch + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +extern struct chip_operations mainboard_msi_ms7135_ops; + +struct mainboard_ms7135_config { + int nothing; +}; Index: src/mainboard/msi/ms7135/cmos.layout =================================================================== --- src/mainboard/msi/ms7135/cmos.layout (revision 0) +++ src/mainboard/msi/ms7135/cmos.layout (revision 0) @@ -0,0 +1,98 @@ +entries + +#start-bit length config config-ID name +#0 8 r 0 seconds +#8 8 r 0 alarm_seconds +#16 8 r 0 minutes +#24 8 r 0 alarm_minutes +#32 8 r 0 hours +#40 8 r 0 alarm_hours +#48 8 r 0 day_of_week +#56 8 r 0 day_of_month +#64 8 r 0 month +#72 8 r 0 year +#80 4 r 0 rate_select +#84 3 r 0 REF_Clock +#87 1 r 0 UIP +#88 1 r 0 auto_switch_DST +#89 1 r 0 24_hour_mode +#90 1 r 0 binary_values_enable +#91 1 r 0 square-wave_out_enable +#92 1 r 0 update_finished_enable +#93 1 r 0 alarm_interrupt_enable +#94 1 r 0 periodic_interrupt_enable +#95 1 r 0 disable_clock_updates +#96 288 r 0 temporary_filler +0 384 r 0 reserved_memory +384 1 e 4 boot_option +385 1 e 4 last_boot +386 1 e 1 ECC_memory +388 4 r 0 reboot_bits +392 3 e 5 baud_rate +395 1 e 1 hw_scrubber +396 1 e 1 interleave_chip_selects +397 2 e 8 max_mem_clock +399 1 e 2 dual_core +400 1 e 1 power_on_after_fail +412 4 e 6 debug_level +416 4 e 7 boot_first +420 4 e 7 boot_second +424 4 e 7 boot_third +428 4 h 0 boot_index +432 8 h 0 boot_countdown +440 4 e 9 slow_cpu +444 1 e 1 nmi +445 1 e 1 iommu +728 256 h 0 user_data +984 16 h 0 check_sum +# Reserve the extended AMD configuration registers +1000 24 r 0 reserved_memory + + + +enumerations + +#ID value text +1 0 Disable +1 1 Enable +2 0 Enable +2 1 Disable +4 0 Fallback +4 1 Normal +5 0 115200 +5 1 57600 +5 2 38400 +5 3 19200 +5 4 9600 +5 5 4800 +5 6 2400 +5 7 1200 +6 6 Notice +6 7 Info +6 8 Debug +6 9 Spew +7 0 Network +7 1 HDD +7 2 Floppy +7 8 Fallback_Network +7 9 Fallback_HDD +7 10 Fallback_Floppy +#7 3 ROM +8 0 400Mhz +8 1 333Mhz +8 2 266Mhz +8 3 200Mhz +9 0 off +9 1 87.5% +9 2 75.0% +9 3 62.5% +9 4 50.0% +9 5 37.5% +9 6 25.0% +9 7 12.5% + +checksums + +checksum 392 983 984 + + Index: src/mainboard/msi/ms7135/mainboard.c =================================================================== --- src/mainboard/msi/ms7135/mainboard.c (revision 0) +++ src/mainboard/msi/ms7135/mainboard.c (revision 0) @@ -0,0 +1,28 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2008 Jonathan A. Kollasch + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include "chip.h" + +#if CONFIG_CHIP_NAME == 1 +struct chip_operations mainboard_msi_ms7135_ops = { + CHIP_NAME("MSI MS7135 Mainboard") +}; +#endif Index: src/mainboard/msi/ms7135/cache_as_ram_auto.c =================================================================== --- src/mainboard/msi/ms7135/cache_as_ram_auto.c (revision 0) +++ src/mainboard/msi/ms7135/cache_as_ram_auto.c (revision 0) @@ -0,0 +1,276 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2007 AMD + * (Written by Yinghai Lu for AMD) + * Copyright (C) 2007 Philipp Degler + * (Thanks to LSRA University of Mannheim for their support) + * Copyright (C) 2008 Jonathan A. Kollasch + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#define ASSEMBLY 1 +#define __ROMCC__ + +#define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1) + +/* Used by raminit. */ +#define QRANK_DIMM_SUPPORT 1 + +/* Turn this on for SMBus debugging output. */ +#define DEBUG_SMBUS 0 + +#if CONFIG_LOGICAL_CPUS == 1 +#define SET_NB_CFG_54 1 +#endif + +#include +#include +#include +#include +#include +#include +#include "option_table.h" +#include "pc80/mc146818rtc_early.c" +#include "cpu/x86/lapic/boot_cpu.c" +#include "northbridge/amd/amdk8/reset_test.c" +#include "superio/winbond/w83627hf/w83627hf_early_serial.c" + +#if USE_FAILOVER_IMAGE == 0 + +/* Used by ck804_early_setup(). */ +#define CK804_NUM 1 +#define CK804_USE_NIC 1 +#define CK804_USE_ACI 1 + +#if CONFIG_USE_INIT == 0 +#include "lib/memcpy.c" +#endif + +#include +#include "pc80/serial.c" +#include "arch/i386/lib/console.c" +#include "ram/ramtest.c" +#include "northbridge/amd/amdk8/incoherent_ht.c" +#include "southbridge/nvidia/ck804/ck804_early_smbus.c" +#include "northbridge/amd/amdk8/raminit.h" +#include "cpu/amd/model_fxx/apic_timer.c" +#include "lib/delay.c" +#include "northbridge/amd/amdk8/debug.c" +#include "cpu/amd/mtrr/amd_earlymtrr.c" +#include "cpu/x86/bist.h" +#include "northbridge/amd/amdk8/setup_resource_map.c" +#include "northbridge/amd/amdk8/coherent_ht.c" +#include "cpu/amd/dualcore/dualcore.c" + +static void memreset_setup(void) +{ + /* FIXME: Nothing to do? */ +} + +static void memreset(int controllers, const struct mem_controller *ctrl) +{ + /* FIXME: Nothing to do? */ +} + +static inline void activate_spd_rom(const struct mem_controller *ctrl) +{ + /* FIXME: Nothing to do? */ +} + +static inline int spd_read_byte(unsigned device, unsigned address) +{ + return smbus_read_byte(device, address); +} + +#include "northbridge/amd/amdk8/raminit.c" +#include "sdram/generic_sdram.c" +#include "southbridge/nvidia/ck804/ck804_early_setup_ss.h" +#include "southbridge/nvidia/ck804/ck804_early_setup_car.c" +#include "cpu/amd/car/copy_and_run.c" +#include "cpu/amd/car/post_cache_as_ram.c" +#include "cpu/amd/model_fxx/init_cpus.c" + +#endif /* USE_FAILOVER_IMAGE */ + +#if ((HAVE_FAILOVER_BOOT==1) && (USE_FAILOVER_IMAGE == 1)) \ + || ((HAVE_FAILOVER_BOOT==0) && (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; + + /* Subject decoding */ + 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); + + /* LPC Positive Decode 0 */ + dword = pci_read_config32(PCI_DEV(0, CK804_DEVN_BASE + 1, 0), 0xa0); + /* Serial 0, Serial 1 */ + dword |= (1 << 0) | (1 << 1); + pci_write_config32(PCI_DEV(0, CK804_DEVN_BASE + 1, 0), 0xa0, dword); +} + +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? */ + 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: + __asm__ volatile ("jmp __normal_image" + : /* outputs */ + :"a" (bist), "b"(cpu_init_detectedx) /* inputs */ + ); + +fallback_image: + +#if HAVE_FAILOVER_BOOT == 1 + __asm__ volatile ("jmp __fallback_image" + : /* outputs */ + :"a" (bist), "b"(cpu_init_detectedx) /* inputs */ + ) +#endif + ; +} + +#endif /* ((HAVE_FAILOVER_BOOT==1) && (USE_FAILOVER_IMAGE == 1)) ... */ + +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 HAVE_FAILOVER_BOOT == 1 +#if USE_FAILOVER_IMAGE == 1 + failover_process(bist, cpu_init_detectedx); +#else + real_main(bist, cpu_init_detectedx); +#endif +#else +#if USE_FALLBACK_IMAGE == 1 + failover_process(bist, cpu_init_detectedx); +#endif + real_main(bist, cpu_init_detectedx); +#endif +} + +#if USE_FAILOVER_IMAGE == 0 +void real_main(unsigned long bist, unsigned long cpu_init_detectedx) +{ + static const uint16_t spd_addr[] = { + (0xa << 3) | 0, (0xa << 3) | 1, 0, 0, + 0, 0, 0, 0, + 0, 0, 0, 0, + 0, 0, 0, 0, + }; + + int needs_reset; + unsigned bsp_apicid = 0; + + struct mem_controller ctrl[8]; + unsigned nodes; + + if (bist == 0) { + bsp_apicid = init_cpus(cpu_init_detectedx); + } + + w83627hf_enable_serial(SERIAL_DEV, TTYS0_BASE); + uart_init(); + console_init(); + + /* Halt if there was a built in self test failure */ + report_bist_failure(bist); + +#if 0 + dump_pci_device(PCI_DEV(0, 0x18, 0)); +#endif + + needs_reset = setup_coherent_ht_domain(); + + wait_all_core0_started(); +#if CONFIG_LOGICAL_CPUS==1 + // It is said that we should start core1 after all core0 launched + start_other_cores(); + wait_all_other_cores_started(bsp_apicid); +#endif + + needs_reset |= ht_setup_chains_x(); + + needs_reset |= ck804_early_setup_x(); + + if (needs_reset) { + print_info("ht reset -\r\n"); + soft_reset(); + } + + allow_all_aps_stop(bsp_apicid); + + nodes = get_nodes(); + //It's the time to set ctrl now; + fill_mem_ctrl(nodes, ctrl, spd_addr); + + enable_smbus(); + +#if 0 + dump_spd_registers(&ctrl[0]); + dump_smbus_registers(); +#endif + + memreset_setup(); + sdram_initialize(nodes, ctrl); + +#if 0 + print_pci_devices(); + dump_pci_devices(); +#endif + + post_cache_as_ram(); +} +#endif /* USE_FAILOVER_IMAGE */ Index: src/mainboard/msi/ms7135/get_bus_conf.c =================================================================== --- src/mainboard/msi/ms7135/get_bus_conf.c (revision 0) +++ src/mainboard/msi/ms7135/get_bus_conf.c (revision 0) @@ -0,0 +1,127 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2007 AMD + * (Written by Yinghai Lu for AMD) + * Copyright (C) 2007 Philipp Degler + * (Thanks to LSRA University of Mannheim for their support) + * Copyright (C) 2008 Jonathan A. Kollasch + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include +#include +#include +#include +#if CONFIG_LOGICAL_CPUS == 1 +#include +#endif + +#include + +/* Global variables for MB layouts and these will be shared by irqtable, + * mptable and acpi_tables. + */ +/* busnum is default */ +unsigned char bus_isa; +unsigned char bus_ck804[6]; +unsigned apicid_ck804; + +unsigned pci1234x[] = { //Here you only need to set value in pci1234 for HT-IO that could be installed or not + //You may need to preset pci1234 for HTIO board, please refer to src/northbridge/amd/amdk8/get_sblk_pci1234.c for detail + 0x0000ff0, //no HTIO for ms7135 +}; +unsigned hcdnx[] = { //HT Chain device num, actually it is unit id base of every ht device in chain, assume every chain only have 4 ht device at most + 0x20202020, //ms7135 has only one ht-chain +}; +unsigned bus_type[256]; + +extern void get_sblk_pci1234(void); + +static unsigned get_bus_conf_done = 0; + +void get_bus_conf(void) +{ + unsigned apicid_base; + + device_t dev; + unsigned sbdn; + int i, j; + + if (get_bus_conf_done == 1) + return; //do it only once + + get_bus_conf_done = 1; + + sysconf.hc_possible_num = sizeof(pci1234x) / sizeof(pci1234x[0]); + sysconf.hc_possible_num = sizeof(pci1234x) / sizeof(pci1234x[0]); + for (i = 0; i < sysconf.hc_possible_num; i++) { + sysconf.pci1234[i] = pci1234x[i]; + sysconf.hcdn[i] = hcdnx[i]; + } + + get_sblk_pci1234(); + + sysconf.sbdn = (sysconf.hcdn[0] & 0xff); // first byte of first chain + sbdn = sysconf.sbdn; + + for (i = 0; i < 6; i++) { + bus_ck804[i] = 0; + } + + for (i = 0; i < 256; i++) { + bus_type[i] = 0; + } + + bus_type[0] = 1; //pci + + bus_ck804[0] = (sysconf.pci1234[0] >> 16) & 0xff; + + bus_type[bus_ck804[0]] = 1; + + /* CK804 */ + int dn = -1; + for (i = 1; i < 4; i++) { + switch (i) { + case 1: dn = 9; break; + case 2: dn = 13; break; + case 3: dn = 14; break; + default: dn = -1; break; + } + dev = dev_find_slot(bus_ck804[0], PCI_DEVFN(sbdn + dn, 0)); + if (dev) { + bus_ck804[i] = pci_read_config8(dev, PCI_SECONDARY_BUS); + bus_isa = pci_read_config8(dev, PCI_SUBORDINATE_BUS); + bus_isa++; + for (j = bus_ck804[i]; j < bus_isa; j++) + bus_type[j] = 1; + } else { + printk_debug + ("ERROR - could not find PCI %02x:%02x.0, using defaults\n", + bus_ck804[0], sbdn + dn); + bus_isa = bus_ck804[i - 1] + 1; + } + } + +/*I/O APICs: APIC ID Version State Address*/ +#if CONFIG_LOGICAL_CPUS==1 + apicid_base = get_apicid_base(3); +#else + apicid_base = CONFIG_MAX_PHYSICAL_CPUS; +#endif + apicid_ck804 = apicid_base + 0; +} Index: targets/msi/ms7135/Config.lb =================================================================== --- targets/msi/ms7135/Config.lb (revision 0) +++ targets/msi/ms7135/Config.lb (revision 0) @@ -0,0 +1,61 @@ +## +## This file is part of the coreboot project. +## +## Copyright (C) 2007 Philipp Degler +## (Thanks to LSRA University of Mannheim for their support) +## Copyright (C) 2008 Jonathan A. Kollasch +## +## This program is free software; you can redistribute it and/or modify +## it under the terms of the GNU General Public License as published by +## the Free Software Foundation; either version 2 of the License, or +## (at your option) any later version. +## +## This program is distributed in the hope that it will be useful, +## but WITHOUT ANY WARRANTY; without even the implied warranty of +## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +## GNU General Public License for more details. +## +## You should have received a copy of the GNU General Public License +## along with this program; if not, write to the Free Software +## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +## + +target ms7135 +mainboard msi/ms7135 + +option DEFAULT_CONSOLE_LOGLEVEL=8 +option MAXIMUM_CONSOLE_LOGLEVEL=8 + +option HAVE_PIRQ_TABLE=1 +option CONFIG_CONSOLE_VGA=1 +option CONFIG_PCI_ROM_RUN=1 + + +romimage "normal" + option USE_FAILOVER_IMAGE=0 + option USE_FALLBACK_IMAGE=0 + option ROM_IMAGE_SIZE=0x20000 + option XIP_ROM_SIZE=0x20000 + option COREBOOT_EXTRA_VERSION="_Normal" + payload /tmp/payload.elf +end + +romimage "fallback" + option USE_FAILOVER_IMAGE=0 + option USE_FALLBACK_IMAGE=1 + option ROM_IMAGE_SIZE=0x20000 + option XIP_ROM_SIZE=0x20000 + option COREBOOT_EXTRA_VERSION="_Fallback" + payload /tmp/payload.elf +end + +romimage "failover" + option USE_FAILOVER_IMAGE=1 + option USE_FALLBACK_IMAGE=0 + option ROM_IMAGE_SIZE=FAILOVER_SIZE + option XIP_ROM_SIZE=FAILOVER_SIZE + option COREBOOT_EXTRA_VERSION="_Failover" +end + +buildrom ./coreboot.rom ROM_SIZE "normal" "fallback" "failover" +#buildrom ./coreboot.rom ROM_SIZE "normal" "fallback" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rminnich at gmail.com Sat Feb 2 05:49:01 2008 From: rminnich at gmail.com (ron minnich) Date: Fri, 1 Feb 2008 20:49:01 -0800 Subject: [coreboot] goal for march summit Message-ID: <13426df10802012049t54d8f799p7b0c7b99f315583@mail.gmail.com> I think our goal should be to get our first v3 port to the k8. We need a good, simple, cheap, target board with really common IO (i.e. PATA, serial, etc.) Any ideas? ron From david.hendricks at gmail.com Sat Feb 2 07:29:17 2008 From: david.hendricks at gmail.com (David Hendricks) Date: Fri, 1 Feb 2008 22:29:17 -0800 Subject: [coreboot] [LinuxBIOS] [patch] MSI MS-7135 (this time with attachment) In-Reply-To: <20080201235121.GC1756@kirkkit.kollasch.net> References: <20071207054444.GW2629@kirkkit.kollasch.net> <20080201163626.GA1756@kirkkit.kollasch.net> <20080201235121.GC1756@kirkkit.kollasch.net> Message-ID: Have you benchmarked SATA performance? I'm curious if you can run a quick "time dd" kind of benchmark. I was only getting around 2MB/sec. Then again, I had not applied this magic at the time. On Feb 1, 2008 3:51 PM, wrote: > On Fri, Feb 01, 2008 at 10:36:26AM -0600, jakllsch at kollasch.net wrote: > > On Fri, Feb 01, 2008 at 12:06:15AM -0800, David Hendricks wrote: > > > Whoa, I don't know how I let this one slip by... Did you manage to get > SATA > > > working, by chance? That was a show stopper for me, but I haven't been > able > > > to diagnose it. > > > > I did not get the second set of two SATA ports working, but I did > > get the first set working. Also, I didn't get the audio to work. > > Huh, well, I now have *all* the SATA ports working. I also fixed the > audio. > > The magic with the audio is to `#define CK804_USE_ACI 1`. This > should fix any ck804 board with audio, probably including the a8n-e. > > I should probably update the patch and get it to work with coreboot > v2 svn. > > Jonathan Kollasch > -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey.osgood at gmail.com Sat Feb 2 09:13:27 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Sat, 2 Feb 2008 03:13:27 -0500 Subject: [coreboot] LinuxBIOS on VIA EPIA EN15000 In-Reply-To: <47A3EB2A.1030304@derner.com> References: <31HsNmXE.1200994157.0775580.bernhard.maenner@mail.cablevision.at> <20080122193152.601.qmail@stuge.se> <4796FEA6.9000908@gmail.com> <47A3EB2A.1030304@derner.com> Message-ID: Sorry I haven't posted a new patch, I've spent the last week trying to get a new laptop set up the way I want it, in a way that makes Vista, MediaDirect, and openSUSE happy. Think I've finally got it, now I just need to get all my stuff off the old laptop. I should be able to get to this this weekend, especially if the weather here is as bad as I think it's going to be. At the moment, the biggest holdup is that IDE (or PATA, whatever you want to call it) isn't working, and I've only got about half of a linux from scratch install done on an SATA drive. -Corey On Feb 1, 2008 11:01 PM, Garrett Derner wrote: > I have a PC2500E and would like to help. How do I get started? > > At the moment I am running it with a single 1GB stick, but if it helps, > I am willing to add a second dimm. > > I am using Kubuntu most of the time, and also have Gentoo and Syllable > set up. > > > Garrett Derner > > > ... I will need a sucker, I mean, volunteer who has a > > board like the gOS desktop board with multiple dimms to give this a shot > > eventually, I still don't have one, and this winter's been a lot harder > > on my wallet then I expected. > > > > -Corey > > > > > > > -- > coreboot mailing list > coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juergen127 at kreuzholzen.de Sat Feb 2 10:04:46 2008 From: juergen127 at kreuzholzen.de (Juergen Beisert) Date: Sat, 2 Feb 2008 10:04:46 +0100 Subject: [coreboot] Capio II 320 and Coreboot In-Reply-To: References: <200802012230.27261.juergen127@kreuzholzen.de> Message-ID: <200802021004.47315.juergen127@kreuzholzen.de> Hi Jeremy, On Friday 01 February 2008 22:47, Jeremy Wright wrote: > Is it that you don't have the superio (or whatever it's called) > parallel/serial card for the Capio, or does Coreboot not recognize it? This box has a superio, but the serial lines are not physically available. > I have the card, I just need to know how to use it for debugging, or even if > I can. Hmm, I have to reopen the box to see what's in it. > Have you tried FILO with your Capio? I got the same result with it which > makes me wonder if the problem is something other than the 82559. I tried with etherboot only. But it failed, and without a serial console no chance to discover why. Juergen From r.marek at assembler.cz Sat Feb 2 10:58:00 2008 From: r.marek at assembler.cz (Rudolf Marek) Date: Sat, 02 Feb 2008 10:58:00 +0100 Subject: [coreboot] goal for march summit In-Reply-To: <13426df10802012049t54d8f799p7b0c7b99f315583@mail.gmail.com> References: <13426df10802012049t54d8f799p7b0c7b99f315583@mail.gmail.com> Message-ID: <47A43EA8.1080702@assembler.cz> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ron minnich wrote: > I think our goal should be to get our first v3 port to the k8. DDR or DDR2 based? > We need a good, simple, cheap, target board with really common IO > (i.e. PATA, serial, etc.) Hmm I would say K8T890+VT8237 it works fine and I have the datasheets (even for onboard clockchip ;) There are at least two boards: Asus A8V-E Deluxe - uwe has it - very similar to mine, just IRQ routing must be fixed. Asus A8V-E SE - I have it. I checked ebay and there is 7 boards left. http://cgi.ebay.com/ASUS-A8V-E-SE-VIA-K8T890-Dual-Core-939-Athlon-64-X2-NIB_W0QQitemZ130193749716QQihZ003QQcategoryZ99245QQssPageNameZWDVWQQrdZ1QQcmdZViewItem ($123) I dont know if this is enough or not :/ But anyway, Rudolf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHpD6o3J9wPJqZRNURAjgnAJ9y2epPI0cOVYnRzeEDA9r7sBTgTwCgqjty VzCpOyA5Nc9x3P7LM60+Gwc= =Ta/E -----END PGP SIGNATURE----- From juergen127 at kreuzholzen.de Sat Feb 2 12:08:42 2008 From: juergen127 at kreuzholzen.de (Juergen Beisert) Date: Sat, 2 Feb 2008 12:08:42 +0100 Subject: [coreboot] Capio II 320 and Coreboot In-Reply-To: <200802021004.47315.juergen127@kreuzholzen.de> References: <200802021004.47315.juergen127@kreuzholzen.de> Message-ID: <200802021208.43054.juergen127@kreuzholzen.de> Hi Jeremy, On Saturday 02 February 2008 10:04, Juergen Beisert wrote: > On Friday 01 February 2008 22:47, Jeremy Wright wrote: > > Is it that you don't have the superio (or whatever it's called) > > parallel/serial card for the Capio, or does Coreboot not recognize it? > > This box has a superio, but the serial lines are not physically available. Ups, sorry. A few minutes ago I opened the box again and: There is no SuperIO! At least in this box are no serial lines available, no LPT aso. Only a very small device for PS/2 keyboard and mouse support. Juergen From c-d.hailfinger.devel.2006 at gmx.net Sat Feb 2 13:42:02 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 02 Feb 2008 13:42:02 +0100 Subject: [coreboot] goal for march summit In-Reply-To: <47A43EA8.1080702@assembler.cz> References: <13426df10802012049t54d8f799p7b0c7b99f315583@mail.gmail.com> <47A43EA8.1080702@assembler.cz> Message-ID: <47A4651A.6030603@gmx.net> On 02.02.2008 10:58, Rudolf Marek wrote: > ron minnich wrote: > > I think our goal should be to get our first v3 port to the k8. > > DDR or DDR2 based? DDR init code is easier, but almost all current processors have DDR2 or DDR3. > > We need a good, simple, cheap, target board with really common IO > > (i.e. PATA, serial, etc.) > > Hmm I would say K8T890+VT8237 it works fine and I have the datasheets > (even for > onboard clockchip ;) Great. Can we pick a socket AM2 board with these chips? Such boards are more readily available than socket 939 boards and usually they are also cheaper. A list of socket AM2 boards with K8T890/K8M890, availability and price in Germany follows: Asrock ALiveSATA2-GLAN, K8T890 (50 ?) Asus M2V, K8T890 (63 ?, difficult to get) Asus M2V-X (unavailable) Asus M2V-TVM, K8M890 (49 ?, difficult to get) Asus M2V-MX, K8M890 (43 ?) Asus M2V-MX SE, K8M890 (38 ?) Foxconn K8M890M2MA-RS2H, K8M890 (40 ?) Foxconn K8M890M2MB-RS2H, K8M890 (36 ?) MSI K9VGM-V, K8M890 (38 ?) > There are at least two boards: > Asus A8V-E Deluxe - uwe has it - very similar to mine, just IRQ > routing must be > fixed. > > Asus A8V-E SE - I have it. I checked ebay and there is 7 boards left. > ($123) That's really expensive. See above for my preferences. However, it would be great if we had a board supported in v2 before we try to port it to v3. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Sat Feb 2 14:15:33 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 02 Feb 2008 14:15:33 +0100 Subject: [coreboot] v3 loads and starts filo on alix1c! In-Reply-To: <13426df10802011451he11f36elb64db983708a8703@mail.gmail.com> References: <13426df10802011444v77d48bf6k3e71aeeeef4a7730@mail.gmail.com> <47A3A1FE.4070104@gmx.net> <13426df10802011451he11f36elb64db983708a8703@mail.gmail.com> Message-ID: <47A46CF5.4010407@gmx.net> On 01.02.2008 23:51, ron minnich wrote: > On Feb 1, 2008 2:49 PM, Carl-Daniel Hailfinger > wrote: > >> What about using memtest as a payload? I believe it does not use any PCI >> access. Besides that, if we have memtest running and it spits out >> errors, we know where to look further. >> > > Will try that next. > Can we celebrate working memtest? That would be really great. Any remaining patches in your tree? Regards, Carl-Daniel From r.marek at assembler.cz Sat Feb 2 14:19:39 2008 From: r.marek at assembler.cz (Rudolf Marek) Date: Sat, 02 Feb 2008 14:19:39 +0100 Subject: [coreboot] goal for march summit In-Reply-To: <47A4651A.6030603@gmx.net> References: <13426df10802012049t54d8f799p7b0c7b99f315583@mail.gmail.com> <47A43EA8.1080702@assembler.cz> <47A4651A.6030603@gmx.net> Message-ID: <47A46DEB.1060709@assembler.cz> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, > Great. Can we pick a socket AM2 board with these chips? Such boards are > more readily available than socket 939 boards and usually they are also > cheaper. A list of socket AM2 boards with K8T890/K8M890, availability > and price in Germany follows: > > Asrock ALiveSATA2-GLAN, K8T890 (50 ?) > Asus M2V, K8T890 (63 ?, difficult to get) > Asus M2V-X (unavailable) > Asus M2V-TVM, K8M890 (49 ?, difficult to get) > Asus M2V-MX, K8M890 (43 ?) > Asus M2V-MX SE, K8M890 (38 ?) > Foxconn K8M890M2MA-RS2H, K8M890 (40 ?) > Foxconn K8M890M2MB-RS2H, K8M890 (36 ?) > MSI K9VGM-V, K8M890 (38 ?) > Hmm M2V seems to use VT3351 aka K8T890CF (not CE). I checked some lspci dumps I found and this is bit different - perhaps I will need to contact VIA again and get the docs. This can take few months :/ I would suggest to stick with the boards which PCI id is 00:00.0 0600: 1106:0238 00:00.1 0600: 1106:1238 00:00.2 0600: 1106:2238 00:00.3 0600: 1106:3238 00:00.4 0600: 1106:4238 00:00.5 0800: 1106:5238 00:00.7 0600: 1106:7238 00:01.0 0604: 1106:b188 (K8T890CE variant) I was unable to find the M2V-MX lspci -xxx dump on the net. Imho the chipset is called K8M890. But it seems that it is CE version + unichrome. It uses internal AGP and unichrome card. The AGP bridge may need some programming. Lets try to get some PCI dumps first. The southbridge is VT8237A it should be fairly similar same to VT8237R. I know already about one difference, hopefully not more will arise. Again, there is a chance to get the datasheets from VIA under NDA, but it takes some time to get them - in my case slightly less time I guess - I have already signed the papers and I think it can be extended to that chipsets too. To sum it up, with VIA we may be able to get the datasheets, it just takes time. They also answered some of my technical questions and provided additional help and asked their engineers. All just takes a lot of time to get the answers ;) > That's really expensive. It was "buy now" button. > See above for my preferences. However, it would be great if we had a > board supported in v2 before we try to port it to v3. Yep. Rudolf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHpG3r3J9wPJqZRNURAst0AJ9kxdieSgRLJGitBjzA1AoFaA+PugCfcj+U rm7tmGvEajdhLNg3jmWOwCo= =Ptud -----END PGP SIGNATURE----- From c-d.hailfinger.devel.2006 at gmx.net Sat Feb 2 14:36:56 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 02 Feb 2008 14:36:56 +0100 Subject: [coreboot] [patch] add MSI MS-7135 support, try two In-Reply-To: <20080202042114.GD1756@kirkkit.kollasch.net> References: <20080202042114.GD1756@kirkkit.kollasch.net> Message-ID: <47A471F8.3040705@gmx.net> On 02.02.2008 05:21, jakllsch at kollasch.net wrote: > Initial support for MSI MS-7135 (K8N Neo3) mainboard. > > Signed-off-by: Jonathan A. Kollasch > > --- src/mainboard/msi/ms7135/mptable.c (revision 0) > +++ src/mainboard/msi/ms7135/mptable.c (revision 0) > [...] > + > +/*I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# */ > + smp_write_intsrc(mc, mp_ExtINT, > + MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, > + bus_isa, 0x0, apicid_ck804, 0x0); > + smp_write_intsrc(mc, mp_INT, > + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, > + bus_isa, 0x1, apicid_ck804, 0x1); > + smp_write_intsrc(mc, mp_INT, > + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, > + bus_isa, 0x0, apicid_ck804, 0x2); > + smp_write_intsrc(mc, mp_INT, > + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, > + bus_isa, 0x3, apicid_ck804, 0x3); > + smp_write_intsrc(mc, mp_INT, > + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, > + bus_isa, 0x4, apicid_ck804, 0x4); > + > + smp_write_intsrc(mc, mp_INT, > + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, > + bus_isa, 0x6, apicid_ck804, 0x6); > + smp_write_intsrc(mc, mp_INT, > + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, > + bus_isa, 0x7, apicid_ck804, 0x7); > + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, > + bus_isa, 0x8, apicid_ck804, 0x8); > + smp_write_intsrc(mc, mp_INT, > + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, > + bus_isa, 0x9, apicid_ck804, 0x9); > + > + smp_write_intsrc(mc, mp_INT, > + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, > + bus_isa, 0xc, apicid_ck804, 0xc); > + smp_write_intsrc(mc, mp_INT, > + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, > + bus_isa, 0xd, apicid_ck804, 0xd); > + smp_write_intsrc(mc, mp_INT, > + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, > + bus_isa, 0xe, apicid_ck804, 0xe); > + smp_write_intsrc(mc, mp_INT, > + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, > + bus_isa, 0xf, apicid_ck804, 0xf); > + > + // Onboard ck804 smbus > + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[0], ((sbdn + 1) << 2) | 1, apicid_ck804, 10); /* (this seems odd) */ > + > + // Onboard ck804 USB 1.1 > + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[0], ((sbdn + 2) << 2) | 0, apicid_ck804, 23); > + > + // Onboard ck804 USB 2.0 > + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[0], ((sbdn + 2) << 2) | 1, apicid_ck804, 23); > + > + // Onboard ck804 AC-97 > + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[0], ((sbdn + 4) << 2) | 0, apicid_ck804, 23); > + > + // Onboard ck804 SATA 0 > + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[0], ((sbdn + 7) << 2) | 0, apicid_ck804, 20); > + > + // Onboard ck804 SATA 1 > + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[0], ((sbdn + 8) << 2) | 0, apicid_ck804, 21); > + > + // Onboard ck804 NIC > + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[0], ((sbdn + 10) << 2) | 0, apicid_ck804, 22); // should be 21 > + > + /* legacy PCI */ > + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[1], (7 << 2) | 0, apicid_ck804, 17); > + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[1], (7 << 2) | 1, apicid_ck804, 18); > + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[1], (7 << 2) | 2, apicid_ck804, 19); > + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[1], (7 << 2) | 3, apicid_ck804, 16); > + /* --- */ > + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[1], (8 << 2) | 0, apicid_ck804, 18); > + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[1], (8 << 2) | 1, apicid_ck804, 19); > + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[1], (8 << 2) | 2, apicid_ck804, 16); > + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[1], (8 << 2) | 3, apicid_ck804, 17); > + /* --- */ > + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[1], (9 << 2) | 0, apicid_ck804, 19); > + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[1], (9 << 2) | 1, apicid_ck804, 16); > + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[1], (9 << 2) | 2, apicid_ck804, 17); > + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[1], (9 << 2) | 3, apicid_ck804, 18); > + > + /* PCI-E x1 port */ > + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[2], (0 << 2) | 0, apicid_ck804, 19); > + /* XXX fill in f1-3 */ > + > + /* PCI-E x16 port */ /* XXX fix me */ > + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL | MP_IRQ_POLARITY_LOW, bus_ck804[3], (0 << 2) | 0, apicid_ck804, 18); > + /* XXX fill in f1-3 */ > + > +/*Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN#*/ > + smp_write_lintsrc(mc, mp_ExtINT, > + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, > + bus_ck804[0], 0x0, MP_APIC_ALL, 0x0); > + smp_write_lintsrc(mc, mp_NMI, > + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, > + bus_ck804[0], 0x0, MP_APIC_ALL, 0x1); Could you simplify the code above with macros like in r3035 and r3041? That would make the code easier to review and maintain. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Sat Feb 2 15:24:01 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 02 Feb 2008 15:24:01 +0100 Subject: [coreboot] goal for march summit In-Reply-To: <47A46DEB.1060709@assembler.cz> References: <13426df10802012049t54d8f799p7b0c7b99f315583@mail.gmail.com> <47A43EA8.1080702@assembler.cz> <47A4651A.6030603@gmx.net> <47A46DEB.1060709@assembler.cz> Message-ID: <47A47D01.8090107@gmx.net> On 02.02.2008 14:19, Rudolf Marek wrote: > > Great. Can we pick a socket AM2 board with these chips? Such boards are > > more readily available than socket 939 boards and usually they are also > > cheaper. A list of socket AM2 boards with K8T890/K8M890, availability > > and price in Germany follows: > > > Asrock ALiveSATA2-GLAN, K8T890 (50 Euro) > > Asus M2V, K8T890 (63 Euro, difficult to get) > > Asus M2V-X (unavailable) > > Asus M2V-TVM, K8M890 (49 Euro, difficult to get) > > Asus M2V-MX, K8M890 (43 Euro) > > Asus M2V-MX SE, K8M890 (38 Euro) > > Foxconn K8M890M2MA-RS2H, K8M890 (40 Euro) > > Foxconn K8M890M2MB-RS2H, K8M890 (36 Euro) > > MSI K9VGM-V, K8M890 (38 Euro) > > > Hmm M2V seems to use VT3351 aka K8T890CF (not CE). I checked some > lspci dumps I > found and this is bit different - perhaps I will need to contact VIA > again and > get the docs. This can take few months :/ That's unfortunate. Then again, the M2V is difficult to get, so it probably is not a viable candidate. > I would suggest to stick with the boards which PCI id is > > 00:00.0 0600: 1106:0238 > 00:00.1 0600: 1106:1238 > 00:00.2 0600: 1106:2238 > 00:00.3 0600: 1106:3238 > 00:00.4 0600: 1106:4238 > 00:00.5 0800: 1106:5238 > 00:00.7 0600: 1106:7238 > 00:01.0 0604: 1106:b188 > > (K8T890CE variant) > > I was unable to find the M2V-MX lspci -xxx dump on the net. Imho the > chipset is > called K8M890. But it seems that it is CE version + unichrome. It uses > internal > AGP and unichrome card. The AGP bridge may need some programming. Lets > try to > get some PCI dumps first. The southbridge is VT8237A it should be > fairly similar > same to VT8237R. Good. > I know already about one difference, hopefully not more will > arise. Again, there is a chance to get the datasheets from VIA under > NDA, but it > takes some time to get them - in my case slightly less time I guess - > I have > already signed the papers and I think it can be extended to that > chipsets too. That would be great! We will need support for newer VIA chipsets anyway, so if you're 2 months ahead with requests, supporting the K8T890CF and K8T890CE+Unichrome should be attainable until May 2008. > To sum it up, with VIA we may be able to get the datasheets, it just > takes time. > They also answered some of my technical questions and provided > additional help > and asked their engineers. All just takes a lot of time to get the > answers ;) Good to know that they cooperate. > > That's really expensive. > > It was "buy now" button. My list mentioned boards available from German online stores, so it would be mostly equivalent to "buy now" at ebay. By the way, the MSI K9VGM-V is available in the US from Newegg for $35. MSI have been cooperative in the past when trying to port their boards, so this may be a good choice. Regards, Carl-Daniel From wrightjmf at gmail.com Sat Feb 2 16:23:17 2008 From: wrightjmf at gmail.com (Jeremy Wright) Date: Sat, 2 Feb 2008 15:23:17 +0000 Subject: [coreboot] Capio II 320 and Coreboot In-Reply-To: <200802021208.43054.juergen127@kreuzholzen.de> References: <200802021004.47315.juergen127@kreuzholzen.de> <200802021208.43054.juergen127@kreuzholzen.de> Message-ID: Thanks for checking Juergen. I'm hoping that having the SuperIO card will help me figure out what's going on. I did find out through ethereal that Etherboot is communicating with the server, it's just not loading the image correctly. I'll let you know what I find out. Thanks again. On Feb 2, 2008 11:08 AM, Juergen Beisert wrote: > Hi Jeremy, > > On Saturday 02 February 2008 10:04, Juergen Beisert wrote: > > On Friday 01 February 2008 22:47, Jeremy Wright wrote: > > > Is it that you don't have the superio (or whatever it's called) > > > parallel/serial card for the Capio, or does Coreboot not recognize it? > > > > This box has a superio, but the serial lines are not physically > available. > > Ups, sorry. A few minutes ago I opened the box again and: There is no > SuperIO! > At least in this box are no serial lines available, no LPT aso. Only a > very > small device for PS/2 keyboard and mouse support. > > Juergen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at smittys.pointclark.net Sat Feb 2 16:53:19 2008 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Sat, 02 Feb 2008 10:53:19 -0500 Subject: [coreboot] LinuxWorld Expo 2008 San Francisco Aug 4-7 Message-ID: <20080202105319.nzrgoxzh8g0o8owo@www.smittys.pointclark.net> Hello, Just wanted to let any of you Californians (you know who you are) that LinuxWorld Expo 2008 is coming and if you wanted to participate you probibly should get on board. I think this would be a great way for coreboot to get some exposure. Thanks - Joe From urbez at linuxupc.upc.edu Sat Feb 2 17:08:42 2008 From: urbez at linuxupc.upc.edu (Urbez Santana Roma) Date: Sat, 02 Feb 2008 17:08:42 +0100 Subject: [coreboot] Testing results CN10000, Via chipsets CN700 and VT8237 with a C7 CPU, and a Kingstom DDR2 memory. Message-ID: <1201968523.3300.30.camel@urbez.site> With my project RemoteBIOS and one elf portion of coreboot, i have tested the CN10000 mainboard, with the RAM initialization routines, written by Corey Osgood, and the code of VT8237R written by Rudolf Marek. I have found the first problem, that i have resolved, the memory initialization must use the 20 bit active when use a CBR memory comand: do_ram_command( RAM_COMMAND_MRS, 0x0022d8); must be: do_ram_command( RAM_COMMAND_MRS, 0x1022d8); do_ram_command( RAM_COMMAND_MRS, 0x21c20); must be: do_ram_command( RAM_COMMAND_MRS, 0x121c20); do_ram_command( RAM_COMMAND_MRS, 0x20020); must be: do_ram_command( RAM_COMMAND_MRS, 0x120020); Without the 20 bit active, the Kingstom Memory not works. The detection of SPD: The ram returns: SPD_DENSITY_OF_EACH_ROW_ON_MODULE=0x80 SPD_NUM_BANKS_PER_SDRAM=0x04 With the last code of corey, the result of configuration for PCI(0,0,3)[0x40] are 0x08, and is the correct value for the 512MB RAM that i have. Be careful, with that, i not use ROMCC for generate the code of the function sdram_set_spd_registers() written by Corey, i use directly gcc with xmmstack. The code of disable SATA works, but the normal IDE does not apear too, with the disable_sata() function. If you use the function, SATA and IDE goes disabled, i have ignored at the moment these function, y must investigate what happends. I have generated the fadt and the dsdt with the genfadt and gendsdt and, ACPI works fine. I must force the kernel with acpi=force, and enable lapic, changing the code of the Linux kernel, that do not support for Centaur Vendors, and then both ACPI and the LAPIC works. All IRQ's works good, and the linux works. What not works? the control of the Memory in the SuperIO, none of the features, can control the memory with DMA, for example VIA-Rhine, and VIA VT82xxx IDE. Then i must in the kernel write the parameter ide=nodma. And then the Linux works, without DMA, and without complete work with the Ethernet, are detected, but fails in the first interrupt. I are testing more, how to enable the access of the southbrigde to the memory, for DMA actions, but i not have documentation, but can test the southbrigde PCI configurations, with relative speed, only changing a script, for test. I say us, if i have luck. Thanks all for read this. From c-d.hailfinger.devel.2006 at gmx.net Sat Feb 2 17:25:47 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 02 Feb 2008 17:25:47 +0100 Subject: [coreboot] Capio II 320 and Coreboot In-Reply-To: References: <13426df10802011059sf8e3f99j25749f957e07af83@mail.gmail.com> <13426df10802011115y47de664fo57fcede4b1f3fd3@mail.gmail.com> Message-ID: <47A4998B.3040900@gmx.net> On 01.02.2008 20:32, Jeremy Wright wrote: > I can't run Linux on the Capios because they don't have any external drive > access, and the only thing that they will boot off of is the DiskOnChip > which has Windows CE on it (which wants to see a Windows Terminal Server). > http://damnsmalllinux.org/cgi-bin/forums/ikonboard.cgi?act=Print;f=26;t=12165 has some interesting info about Damn Small Linux on the Capio II. > One of the reasons that I am trying Coreboot is to get to where I can > reprogram the DOC to put Linux on it. So, I'm stuck on testing serial > communications with minicom on the Capio end. I think that if you manage to reprogram the DOC outside the Capio, you can run Linux and use that to further debug Coreboot. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Sat Feb 2 17:42:33 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 02 Feb 2008 17:42:33 +0100 Subject: [coreboot] Unmerged mainboard targets in v2 In-Reply-To: <20080201170342.GA15310@localdomain> References: <20071207054444.GW2629@kirkkit.kollasch.net> <20080201163626.GA1756@kirkkit.kollasch.net> <20080201170342.GA15310@localdomain> Message-ID: <47A49D79.8050208@gmx.net> On 01.02.2008 18:03, Ward Vandewege wrote: > You may want to have a look at this > > ftp://ftp.lnxi.com/pub/linuxbios/h8dce/SOURCE > > That's another ck804-based board, and I suspect that all sata ports on both > controllers work there. > It would be great if someone could invest time to inspect all of ftp://ftp.lnxi.com/pub/linuxbios/ and tell us which unmerged boards we can find there and which svn revision they are based on. Maybe we can salvage a few targets and increase our supported base. Regards, Carl-Daniel From rminnich at gmail.com Sat Feb 2 19:00:43 2008 From: rminnich at gmail.com (ron minnich) Date: Sat, 2 Feb 2008 10:00:43 -0800 Subject: [coreboot] v3 loads and starts filo on alix1c! In-Reply-To: <47A46CF5.4010407@gmx.net> References: <13426df10802011444v77d48bf6k3e71aeeeef4a7730@mail.gmail.com> <47A3A1FE.4070104@gmx.net> <13426df10802011451he11f36elb64db983708a8703@mail.gmail.com> <47A46CF5.4010407@gmx.net> Message-ID: <13426df10802021000v46198237qbdbc9f69b49978e6@mail.gmail.com> On Feb 2, 2008 5:15 AM, Carl-Daniel Hailfinger wrote: > Can we celebrate working memtest? That would be really great. > Any remaining patches in your tree? memtest fails with some sort of exception. Not sure what yet. ron From jakllsch at kollasch.net Sat Feb 2 19:52:53 2008 From: jakllsch at kollasch.net (jakllsch at kollasch.net) Date: Sat, 2 Feb 2008 12:52:53 -0600 Subject: [coreboot] [patch] add MSI MS-7135 support, try two In-Reply-To: <47A471F8.3040705@gmx.net> References: <20080202042114.GD1756@kirkkit.kollasch.net> <47A471F8.3040705@gmx.net> Message-ID: <20080202185252.GE1756@kirkkit.kollasch.net> On Sat, Feb 02, 2008 at 02:36:56PM +0100, Carl-Daniel Hailfinger wrote: > Could you simplify the code above with macros like in r3035 and r3041? That would make the code easier to review and maintain. Yeah. Should I send the complete patch again with the changes? Jonathan Kollasch -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From c-d.hailfinger.devel.2006 at gmx.net Sat Feb 2 20:06:25 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 02 Feb 2008 20:06:25 +0100 Subject: [coreboot] [patch] add MSI MS-7135 support, try two In-Reply-To: <20080202185252.GE1756@kirkkit.kollasch.net> References: <20080202042114.GD1756@kirkkit.kollasch.net> <47A471F8.3040705@gmx.net> <20080202185252.GE1756@kirkkit.kollasch.net> Message-ID: <47A4BF31.9080705@gmx.net> On 02.02.2008 19:52, jakllsch at kollasch.net wrote: > On Sat, Feb 02, 2008 at 02:36:56PM +0100, Carl-Daniel Hailfinger wrote: > >> Could you simplify the code above with macros like in r3035 and r3041? That would make the code easier to review and maintain. >> > > Yeah. Should I send the complete patch again with the changes? > Please do so. The patch looked nice otherwise. Regards, Carl-Daniel From jakllsch at kollasch.net Sat Feb 2 20:41:07 2008 From: jakllsch at kollasch.net (jakllsch at kollasch.net) Date: Sat, 2 Feb 2008 13:41:07 -0600 Subject: [coreboot] [patch] add MSI MS-7135 support, try three Message-ID: <20080202194107.GF1756@kirkkit.kollasch.net> Initial support for MSI MS-7135 (K8N Neo3) mainboard. Signed-off-by: Jonathan A. Kollasch -------------- next part -------------- Index: src/mainboard/msi/ms7135/Config.lb =================================================================== --- src/mainboard/msi/ms7135/Config.lb (revision 0) +++ src/mainboard/msi/ms7135/Config.lb (revision 0) @@ -0,0 +1,306 @@ +## +## This file is part of the coreboot project. +## +## Copyright (C) 2007 AMD +## (Written by Yinghai Lu for AMD) +## Copyright (C) 2007 Philipp Degler +## (Thanks to LSRA University of Mannheim for their support) +## Copyright (C) 2008 Jonathan A. Kollasch +## +## This program is free software; you can redistribute it and/or modify +## it under the terms of the GNU General Public License as published by +## the Free Software Foundation; either version 2 of the License, or +## (at your option) any later version. +## +## This program is distributed in the hope that it will be useful, +## but WITHOUT ANY WARRANTY; without even the implied warranty of +## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +## GNU General Public License for more details. +## +## You should have received a copy of the GNU General Public License +## along with this program; if not, write to the Free Software +## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +## + +## +## Compute the location and size of where this firmware image +## (coreboot plus bootloader) will live in the boot rom chip. +## +if USE_FAILOVER_IMAGE + default ROM_SECTION_SIZE = FAILOVER_SIZE + default ROM_SECTION_OFFSET = (ROM_SIZE - FAILOVER_SIZE) +else + if USE_FALLBACK_IMAGE + default ROM_SECTION_SIZE = FALLBACK_SIZE + default ROM_SECTION_OFFSET = (ROM_SIZE - FALLBACK_SIZE - FAILOVER_SIZE) + else + default ROM_SECTION_SIZE = (ROM_SIZE - FALLBACK_SIZE - FAILOVER_SIZE) + default ROM_SECTION_OFFSET = 0 + end +end + +## +## Compute the start location and size size of the coreboot bootloader. +## +default PAYLOAD_SIZE = (ROM_SECTION_SIZE - ROM_IMAGE_SIZE) +default CONFIG_ROM_PAYLOAD_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) + +## +## Compute where this copy of coreboot will start in the boot ROM. +## +default _ROMBASE = ( CONFIG_ROM_PAYLOAD_START + PAYLOAD_SIZE ) + +## +## Compute a range of ROM that can be cached to speed up coreboot +## execution speed. +## +## XIP_ROM_SIZE must be a power of 2 (here 64 Kbyte) +## XIP_ROM_BASE must be a multiple of XIP_ROM_SIZE +## +default XIP_ROM_SIZE = (64 * 1024) + +if USE_FAILOVER_IMAGE + default XIP_ROM_BASE = (_ROMBASE - XIP_ROM_SIZE + ROM_IMAGE_SIZE) +else + if USE_FALLBACK_IMAGE + default XIP_ROM_BASE = (_ROMBASE - XIP_ROM_SIZE + ROM_IMAGE_SIZE + FAILOVER_SIZE) + else + default XIP_ROM_BASE = (_ROMBASE - XIP_ROM_SIZE + ROM_IMAGE_SIZE) + end +end + +arch i386 end + +## +## Build the objects we have code for in this directory. +## + +driver mainboard.o + +#dir /drivers/ati/ragexl + +# Needed by irq_tables and mptable and acpi_tables. +object get_bus_conf.o + +if HAVE_MP_TABLE + object mptable.o +end + +if HAVE_PIRQ_TABLE + object irq_tables.o +end + +if USE_DCACHE_RAM + if CONFIG_USE_INIT + makerule ./auto.o + depends "$(MAINBOARD)/cache_as_ram_auto.c option_table.h" + action "$(CC) -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/cache_as_ram_auto.c -Os -nostdinc -nostdlib -fno-builtin -Wall -c -o $@" + end + else + makerule ./auto.inc + depends "$(MAINBOARD)/cache_as_ram_auto.c option_table.h" + action "$(CC) -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/cache_as_ram_auto.c -Os -nostdinc -nostdlib -fno-builtin -Wall -c -S -o $@" + action "perl -e 's/.rodata/.rom.data/g' -pi $@" + action "perl -e 's/.text/.section .rom.text/g' -pi $@" + end + end +end + +## +## Build our 16 bit and 32 bit coreboot entry code. +## +if HAVE_FAILOVER_BOOT + if USE_FAILOVER_IMAGE + mainboardinit cpu/x86/16bit/entry16.inc + ldscript /cpu/x86/16bit/entry16.lds + end +else + if USE_FALLBACK_IMAGE + mainboardinit cpu/x86/16bit/entry16.inc + ldscript /cpu/x86/16bit/entry16.lds + end +end + +mainboardinit cpu/x86/32bit/entry32.inc + +if USE_DCACHE_RAM + if CONFIG_USE_INIT + ldscript /cpu/x86/32bit/entry32.lds + ldscript /cpu/amd/car/cache_as_ram.lds + end +end + +## +## Build our reset vector (this is where coreboot is entered). +## +if HAVE_FAILOVER_BOOT + if 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 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 + +if USE_DCACHE_RAM +else + ### Should this be in the northbridge code? + mainboardinit arch/i386/lib/cpu_reset.inc +end + +## +## Include an ID string (for safe flashing). +## +mainboardinit southbridge/nvidia/ck804/id.inc +ldscript /southbridge/nvidia/ck804/id.lds + +## +## ROMSTRAP table for CK804 +## +if HAVE_FAILOVER_BOOT + if USE_FAILOVER_IMAGE + mainboardinit southbridge/nvidia/ck804/romstrap.inc + ldscript /southbridge/nvidia/ck804/romstrap.lds + end +else + if USE_FALLBACK_IMAGE + mainboardinit southbridge/nvidia/ck804/romstrap.inc + ldscript /southbridge/nvidia/ck804/romstrap.lds + end +end + +if USE_DCACHE_RAM + ## + ## Setup Cache-As-Ram + ## + mainboardinit cpu/amd/car/cache_as_ram.inc +end + + +### +### This is the early phase of coreboot startup. +### Things are delicate and we test to see if we should +### failover to another image. +### +if HAVE_FAILOVER_BOOT + if USE_FAILOVER_IMAGE + if USE_DCACHE_RAM + ldscript /arch/i386/lib/failover_failover.lds + end + end +else + if USE_FALLBACK_IMAGE + if USE_DCACHE_RAM + ldscript /arch/i386/lib/failover.lds + end + end +end + +### +### O.k. We aren't just an intermediary anymore! +### + +## +## Setup RAM +## +if USE_DCACHE_RAM + if CONFIG_USE_INIT + initobject auto.o + else + mainboardinit ./auto.inc + end +end + +## +## Include the secondary configuration files +## +if CONFIG_CHIP_NAME + config chip.h +end + +chip northbridge/amd/amdk8/root_complex # Root complex + device apic_cluster 0 on # APIC cluster + chip cpu/amd/socket_754 # Socket 754 CPU + device apic 0 on end # APIC + end + end + + device pci_domain 0 on # PCI domain + chip northbridge/amd/amdk8 # mc0 + device pci 18.0 on # Northbridge + # Devices on link 0, link 0 == LDT 0 + chip southbridge/nvidia/ck804 # Southbridge + device pci 0.0 on end # HT + device pci 1.0 on # LPC + chip superio/winbond/w83627thf # Super I/O + device pnp 2e.0 off # Floppy + io 0x60 = 0x3f0 + irq 0x70 = 6 + drq 0x74 = 2 + end + device pnp 2e.1 on # Parallel port + io 0x60 = 0x378 + irq 0x70 = 0 + end + device pnp 2e.2 on # Com1 + io 0x60 = 0x3f8 + irq 0x70 = 4 + end + device pnp 2e.3 on # Com2 + io 0x60 = 0x2f8 + irq 0x70 = 3 + end + device pnp 2e.5 on # PS/2 keyboard + io 0x60 = 0x60 + io 0x62 = 0x64 + irq 0x70 = 1 + irq 0x72 = 12 + end + device pnp 2e.6 off end # non-existant or undocumented + device pnp 2e.7 off end # Game, MIDI, GPIO 1, GPIO 5 + device pnp 2e.8 off end # GPIO 2 + device pnp 2e.9 off end # GPIO 3, GPIO 4 + device pnp 2e.a off end # ACPI + device pnp 2e.b on # env monitor + io 0x60 = 0x290 + irq 0x70 = 0 + end + end + end + device pci 1.1 on end # SMbus + device pci 2.0 on end # USB 1.1 + device pci 2.1 on end # USB 2 + device pci 4.0 on end # Onboard audio (ACI) + device pci 4.1 off end # Onboard modem (MCI) -- not wired out + device pci 6.0 on end # IDE + device pci 7.0 on end # SATA 1 + device pci 8.0 on end # SATA 0 + device pci 9.0 on end # PCI + device pci a.0 on end # NIC + device pci b.0 off end # PCI E 3 -- not wired out + device pci c.0 off end # PCI E 2 -- not wired out + device pci d.0 on end # PCI E 1 + device pci e.0 on end # PCI E 0 + register "ide0_enable" = "1" + register "ide1_enable" = "1" + register "sata0_enable" = "1" + register "sata1_enable" = "1" + # register "mac_eeprom_smbus" = "3" + # register "mac_eeprom_addr" = "0x51" + end + end + device pci 18.1 on end + device pci 18.2 on end + device pci 18.3 on end + end + end +end Index: src/mainboard/msi/ms7135/mptable.c =================================================================== --- src/mainboard/msi/ms7135/mptable.c (revision 0) +++ src/mainboard/msi/ms7135/mptable.c (revision 0) @@ -0,0 +1,221 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2007 AMD + * (Written by Yinghai Lu for AMD) + * Copyright (C) 2007 Philipp Degler + * (Thanks to LSRA University of Mannheim for their support) + * Copyright (C) 2008 Jonathan A. Kollasch + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include +#include +#include +#include + +#include + +extern unsigned char bus_isa; +extern unsigned char bus_ck804[6]; +extern unsigned apicid_ck804; + +extern unsigned bus_type[256]; + +extern void get_bus_conf(void); + +void *smp_write_config_table(void *v) +{ + static const char sig[4] = "PCMP"; + static const char oem[8] = "MSI "; + static const char productid[12] = "MS7135 "; + struct mp_config_table *mc; + unsigned sbdn; + + int bus_num; + int i; + + mc = (void *)(((char *)v) + SMP_FLOATING_TABLE_LEN); + memset(mc, 0, sizeof(*mc)); + + memcpy(mc->mpc_signature, sig, sizeof(sig)); + mc->mpc_length = sizeof(*mc); /* initially just the header */ + mc->mpc_spec = 0x04; + mc->mpc_checksum = 0; /* not yet computed */ + memcpy(mc->mpc_oem, oem, sizeof(oem)); + memcpy(mc->mpc_productid, productid, sizeof(productid)); + mc->mpc_oemptr = 0; + mc->mpc_oemsize = 0; + mc->mpc_entry_count = 0; /* No entries yet... */ + mc->mpc_lapic = LAPIC_ADDR; + mc->mpe_length = 0; + mc->mpe_checksum = 0; + mc->reserved = 0; + + smp_write_processors(mc); + + get_bus_conf(); + sbdn = sysconf.sbdn; + +/* Bus: Bus ID Type*/ + /* define numbers for pci and isa bus */ + for (bus_num = 0; bus_num < 256; bus_num++) { + if (bus_type[bus_num]) + smp_write_bus(mc, bus_num, "PCI "); + } + smp_write_bus(mc, bus_isa, "ISA "); + + +/* I/O APICs: APIC ID Version State Address*/ + { + device_t dev; + struct resource *res; + uint32_t dword; + + dev = dev_find_slot(bus_ck804[0], PCI_DEVFN(sbdn + 0x1, 0)); + if (dev) { + res = find_resource(dev, PCI_BASE_ADDRESS_1); + if (res) { + smp_write_ioapic(mc, apicid_ck804, 0x11, + res->base); + } + + /* Initialize interrupt mapping */ + + /* copied from stock bios */ + /*0x01800500,0x1800d509,0x00520d08*/ + + /* if this register is what i think it is ... */ + dword = 0x08d0d218; + pci_write_config32(dev, 0x7c, dword); + + dword = 0x8d001509; + pci_write_config32(dev, 0x80, dword); + + dword = 0x00010271; + pci_write_config32(dev, 0x84, dword); + + } + } + + /* Now, assemble the table. */ + + smp_write_intsrc(mc, mp_ExtINT, + MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, + bus_isa, 0x0, apicid_ck804, 0x0); + +#define ISA_INT(intr, pin) \ + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, \ + bus_isa, (intr), apicid_ck804, (pin)) + + ISA_INT(1, 1); + ISA_INT(0, 2); + ISA_INT(3, 3); + ISA_INT(4, 4); + + ISA_INT(6, 6); + ISA_INT(7, 7); + ISA_INT(8, 8); + ISA_INT(9, 9); + + ISA_INT(0xc, 0xc); + ISA_INT(0xd, 0xd); + ISA_INT(0xe, 0xe); + ISA_INT(0xf, 0xf); + +#define PCI_INT(bus, dev, fn, pin) \ + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, \ + bus_ck804[bus], (((dev)<<2)|(fn)), apicid_ck804, (pin)) + +#if 0 + // Onboard ck804 smbus + PCI_INT(0, sbdn+1, 1, 10); /* (this seems odd, how to test?) */ + +#endif + // Onboard ck804 USB + PCI_INT(0, sbdn+2, 0, 23); + PCI_INT(0, sbdn+2, 1, 23); + + // Onboard ck804 AC-97 + PCI_INT(0, sbdn+4, 0, 23); + + // Onboard ck804 SATA 0 + PCI_INT(0, sbdn+7, 0, 20); + + // Onboard ck804 SATA 1 + PCI_INT(0, sbdn+8, 0, 21); + + // Onboard ck804 NIC + PCI_INT(0, sbdn+10, 0, 22); + + + /* legacy PCI */ + PCI_INT(1, 7, 0, 17); + PCI_INT(1, 7, 1, 18); + PCI_INT(1, 7, 2, 19); + PCI_INT(1, 7, 3, 16); + + PCI_INT(1, 8, 0, 18); + PCI_INT(1, 8, 1, 19); + PCI_INT(1, 8, 2, 16); + PCI_INT(1, 8, 3, 17); + + PCI_INT(1, 9, 0, 19); + PCI_INT(1, 9, 1, 16); + PCI_INT(1, 9, 2, 17); + PCI_INT(1, 9, 3, 18); + + + /* PCI-E x1 port */ + PCI_INT(2, 0, 0, 19); + /* XXX guesses */ + PCI_INT(2, 0, 1, 16); + PCI_INT(2, 9, 2, 17); + PCI_INT(2, 9, 3, 18); + + /* PCI-E x16 port */ /* XXX fix me ? */ + PCI_INT(3, 0, 0, 18); + /* XXX guesses */ + PCI_INT(3, 0, 1, 19); + PCI_INT(3, 0, 2, 16); + PCI_INT(3, 0, 3, 17); + +/*Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN#*/ + smp_write_lintsrc(mc, mp_ExtINT, + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, + bus_ck804[0], 0x0, MP_APIC_ALL, 0x0); + smp_write_lintsrc(mc, mp_NMI, + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, + bus_ck804[0], 0x0, MP_APIC_ALL, 0x1); + + /* There is no extension information... */ + + /* Compute the checksums */ + mc->mpe_checksum = + smp_compute_checksum(smp_next_mpc_entry(mc), mc->mpe_length); + mc->mpc_checksum = smp_compute_checksum(mc, mc->mpc_length); + printk_debug("Wrote the mp table end at: %p - %p\n", + mc, smp_next_mpe_entry(mc)); + return smp_next_mpe_entry(mc); +} + +unsigned long write_smp_table(unsigned long addr) +{ + void *v; + v = smp_write_floating_table(addr); + return (unsigned long)smp_write_config_table(v); +} Index: src/mainboard/msi/ms7135/irq_tables.c =================================================================== --- src/mainboard/msi/ms7135/irq_tables.c (revision 0) +++ src/mainboard/msi/ms7135/irq_tables.c (revision 0) @@ -0,0 +1,265 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2007 AMD + * (Written by Yinghai Lu for AMD) + * Copyright (C) 2007 Philipp Degler + * (Thanks to LSRA University of Mannheim for their support) + * Copyright (C) 2008 Jonathan A. Kollasch + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +/* Documentation at: http://www.microsoft.com/hwdev/busbios/PCIIRQ.HTM */ + +/* This is probably not right, feel free to fix this if you don't want + * to use the mptable. + */ + +#include +#include +#include +#include +#include +#include + +extern unsigned char bus_isa; +extern unsigned char bus_ck804[6]; +extern void get_bus_conf(void); + +/** + * Add one line to IRQ table. + */ +static void write_pirq_info(struct irq_info *pirq_info, uint8_t bus, + uint8_t devfn, uint8_t link0, uint16_t bitmap0, + uint8_t link1, uint16_t bitmap1, uint8_t link2, + uint16_t bitmap2, uint8_t link3, uint16_t bitmap3, + uint8_t slot, uint8_t rfu) +{ + pirq_info->bus = bus; + pirq_info->devfn = devfn; + pirq_info->irq[0].link = link0; + pirq_info->irq[0].bitmap = bitmap0; + pirq_info->irq[1].link = link1; + pirq_info->irq[1].bitmap = bitmap1; + pirq_info->irq[2].link = link2; + pirq_info->irq[2].bitmap = bitmap2; + pirq_info->irq[3].link = link3; + pirq_info->irq[3].bitmap = bitmap3; + pirq_info->slot = slot; + pirq_info->rfu = rfu; +} + +void pci_assign_irqs(unsigned, unsigned, const unsigned char *); + +/** + * Create the IRQ routing table. + * Values are derived from getpir generated code. + */ +unsigned long write_pirq_routing_table(unsigned long addr) +{ + + struct irq_routing_table *pirq; + struct irq_info *pirq_info; + unsigned slot_num; + uint8_t *v; + + uint8_t sum = 0; + int i; + unsigned sbdn; + + /* get_bus_conf() will find out all bus num and apic that share with + * mptable.c and mptable.c + */ + get_bus_conf(); + sbdn = sysconf.sbdn; + + /* Align the table to be 16 byte aligned. */ + addr += 15; + addr &= ~15; + + /* This table must be betweeen 0xf0000 & 0x100000 */ + printk_info("Writing IRQ routing tables to 0x%x...", addr); + + pirq = (void *)(addr); + v = (uint8_t *) (addr); + + pirq->signature = PIRQ_SIGNATURE; + pirq->version = PIRQ_VERSION; + + pirq->rtr_bus = bus_ck804[0]; + pirq->rtr_devfn = ((sbdn + 9) << 3) | 0; + + pirq->exclusive_irqs = 0x828; + + pirq->rtr_vendor = 0x10de; + pirq->rtr_device = 0x005c; + + pirq->miniport_data = 0; + + memset(pirq->rfu, 0, sizeof(pirq->rfu)); + + pirq_info = (void *)(&pirq->checksum + 1); + slot_num = 0; + +//Slot1 PCIE 16x + write_pirq_info(pirq_info, bus_ck804[1], (0 << 3) | 0, 0x3, 0xdeb8, 0x4, + 0xdeb8, 0x1, 0xdeb8, 0x2, 0xdeb8, 4, 0); + pirq_info++; + slot_num++; + +//Slot2 PCIE 1x + write_pirq_info(pirq_info, bus_ck804[2], (0 << 3) | 0, 0x4, 0xdeb8, 0x1, + 0xdeb8, 0x2, 0xdeb8, 0x3, 0xdeb8, 5, 0); + pirq_info++; + slot_num++; + +//Slot3 PCIE 1x + write_pirq_info(pirq_info, bus_ck804[3], (0 << 3) | 0, 0x1, 0xdeb8, 0x2, + 0xdeb8, 0x3, 0xdeb8, 0x4, 0xdeb8, 6, 0); + pirq_info++; + slot_num++; + +//Slot4 PCIE 4x + write_pirq_info(pirq_info, bus_ck804[4], (0x4 << 3) | 0, + 0x2, 0xdeb8, 0x3, 0xdeb8, 0x4, 0xdeb8, 0x1, 0xdeb8, + 7, 0); + pirq_info++; + slot_num++; + +//Slot5 - 7 PCI + for (i = 0; i < 3; i++) { + write_pirq_info(pirq_info, bus_ck804[5], (0 << (6 + i)) | 0, + ((i + 0) % 4) + 1, 0xdeb8, + ((i + 1) % 4) + 1, 0xdeb8, + ((i + 2) % 4) + 1, 0xdeb8, + ((i + 3) % 4) + 1, 0xdeb8, i, 0); + pirq_info++; + slot_num++; + } + +//pci bridge + write_pirq_info(pirq_info, bus_ck804[0], ((sbdn + 9) << 3) | 0, 0x1, + 0xdeb8, 0x2, 0xdeb8, 0x3, 0xdeb8, 0x4, 0xdeb8, 0, 0); + pirq_info++; + slot_num++; + +//smbus + write_pirq_info(pirq_info, bus_ck804[0], ((sbdn + 1) << 3) | 0, 0x2, + 0xdeb8, 0, 0, 0, 0, 0, 0, 0, 0); + pirq_info++; + slot_num++; + +//usb + write_pirq_info(pirq_info, bus_ck804[0], ((sbdn + 2) << 3) | 0, 0x1, + 0xdeb8, 0x2, 0xdeb8, 0, 0, 0, 0, 0, 0); + pirq_info++; + slot_num++; + +//audio + write_pirq_info(pirq_info, bus_ck804[0], ((sbdn + 4) << 3) | 0, 0x1, + 0xdeb8, 0, 0, 0, 0, 0, 0, 0, 0); + pirq_info++; + slot_num++; +//sata + write_pirq_info(pirq_info, bus_ck804[0], ((sbdn + 7) << 3) | 0, 0x1, + 0xdeb8, 0, 0, 0, 0, 0, 0, 0, 0); + pirq_info++; + slot_num++; +//sata + write_pirq_info(pirq_info, bus_ck804[0], ((sbdn + 8) << 3) | 0, 0x1, + 0xdeb8, 0, 0, 0, 0, 0, 0, 0, 0); + pirq_info++; + slot_num++; +//nic + write_pirq_info(pirq_info, bus_ck804[0], ((sbdn + 0xa) << 3) | 0, 0x1, + 0xdeb8, 0, 0, 0, 0, 0, 0, 0, 0); + pirq_info++; + slot_num++; + + pirq->size = 32 + 16 * slot_num; + + for (i = 0; i < pirq->size; i++) + sum += v[i]; + + sum = pirq->checksum - sum; + + if (sum != pirq->checksum) { + pirq->checksum = sum; + } + + printk_info("done.\n"); + +#if 0 + unsigned char irq[4]; + irq[0] = 0; + irq[1] = 0; + irq[2] = 0; + irq[3] = 0; + + /* Bus, device, slots IRQs for {A,B,C,D}. */ + + irq[0] = 10; /* SMBus */ /* test me */ + pci_assign_irqs(bus_ck804[0], 1, irq); + + irq[0] = 10; /* USB */ + irq[1] = 10; + pci_assign_irqs(bus_ck804[0], 2, irq); + + irq[0] = 10; /* AC97 */ + irq[1] = 0; + pci_assign_irqs(bus_ck804[0], 4, irq); + + irq[0] = 11; /* SATA */ + pci_assign_irqs(bus_ck804[0], 7, irq); + + irq[0] = 5; /* SATA */ + pci_assign_irqs(bus_ck804[0], 8, irq); + + irq[0] = 10; /* Ethernet */ + pci_assign_irqs(bus_ck804[0], 10, irq); + + + /* physical slots */ + + irq[0] = 5; /* PCI E1 - x1 */ + pci_assign_irqs(bus_ck804[2], 0, irq); + + irq[0] = 11; /* PCI E2 - x16 */ + pci_assign_irqs(bus_ck804[3], 0, irq); + + /* AGP-on-PCI "AGR" ignored */ + + irq[0] = 10; /* PCI1 */ + irq[1] = 11; + irq[2] = 5; + irq[3] = 0; + pci_assign_irqs(bus_ck804[1], 7, irq); + + irq[0] = 11; /* PCI2 */ + irq[1] = 10; + irq[2] = 5; + irq[3] = 0; + pci_assign_irqs(bus_ck804[1], 8, irq); + + irq[0] = 5; /* PCI3 */ + irq[1] = 10; + irq[2] = 11; + irq[3] = 0; + pci_assign_irqs(bus_ck804[1], 9, irq); +#endif + + return (unsigned long)pirq_info; +} Index: src/mainboard/msi/ms7135/Options.lb =================================================================== --- src/mainboard/msi/ms7135/Options.lb (revision 0) +++ src/mainboard/msi/ms7135/Options.lb (revision 0) @@ -0,0 +1,321 @@ +## +## This file is part of the coreboot project. +## +## Copyright (C) 2007 Philipp Degler +## (Thanks to LSRA University of Mannheim for their support) +## Copyright (C) 2008 Jonathan A. Kollasch +## +## This program is free software; you can redistribute it and/or modify +## it under the terms of the GNU General Public License as published by +## the Free Software Foundation; either version 2 of the License, or +## (at your option) any later version. +## +## This program is distributed in the hope that it will be useful, +## but WITHOUT ANY WARRANTY; without even the implied warranty of +## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +## GNU General Public License for more details. +## +## You should have received a copy of the GNU General Public License +## along with this program; if not, write to the Free Software +## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +## + +uses HAVE_MP_TABLE +uses HAVE_PIRQ_TABLE +uses USE_FALLBACK_IMAGE +uses USE_FAILOVER_IMAGE +uses HAVE_FALLBACK_BOOT +uses HAVE_FAILOVER_BOOT +uses HAVE_HARD_RESET +uses IRQ_SLOT_COUNT +uses HAVE_OPTION_TABLE +uses CONFIG_MAX_CPUS +uses CONFIG_MAX_PHYSICAL_CPUS +uses CONFIG_LOGICAL_CPUS +uses CONFIG_IOAPIC +uses CONFIG_SMP +uses FALLBACK_SIZE +uses FAILOVER_SIZE +uses ROM_SIZE +uses ROM_SECTION_SIZE +uses ROM_IMAGE_SIZE +uses ROM_SECTION_SIZE +uses ROM_SECTION_OFFSET +uses CONFIG_ROM_PAYLOAD +uses CONFIG_ROM_PAYLOAD_START +uses CONFIG_COMPRESSED_PAYLOAD_LZMA +uses PAYLOAD_SIZE +uses _ROMBASE +uses XIP_ROM_SIZE +uses XIP_ROM_BASE +uses STACK_SIZE +uses HEAP_SIZE +uses USE_OPTION_TABLE +uses LB_CKS_RANGE_START +uses LB_CKS_RANGE_END +uses LB_CKS_LOC +uses MAINBOARD_PART_NUMBER +uses MAINBOARD_VENDOR +uses MAINBOARD +uses MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID +uses MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID +uses COREBOOT_EXTRA_VERSION +uses _RAMBASE +uses CONFIG_GDB_STUB +uses CROSS_COMPILE +uses CC +uses HOSTCC +uses OBJCOPY +uses TTYS0_BAUD +uses TTYS0_BASE +uses TTYS0_LCS +uses DEFAULT_CONSOLE_LOGLEVEL +uses MAXIMUM_CONSOLE_LOGLEVEL +uses MAINBOARD_POWER_ON_AFTER_POWER_FAIL +uses CONFIG_CONSOLE_SERIAL8250 +uses CONFIG_CONSOLE_BTEXT +uses HAVE_INIT_TIMER +uses CONFIG_GDB_STUB +uses CONFIG_CHIP_NAME +uses CONFIG_CONSOLE_VGA +uses CONFIG_PCI_ROM_RUN +uses HW_MEM_HOLE_SIZEK + +uses USE_DCACHE_RAM +uses DCACHE_RAM_BASE +uses DCACHE_RAM_SIZE +uses CONFIG_USE_INIT +uses DCACHE_RAM_GLOBAL_VAR_SIZE +uses CONFIG_AP_CODE_IN_CAR +uses MEM_TRAIN_SEQ +uses WAIT_BEFORE_CPUS_INIT + +uses ENABLE_APIC_EXT_ID +uses APIC_ID_OFFSET +uses LIFT_BSP_APIC_ID + +uses CONFIG_PCI_64BIT_PREF_MEM + +uses HT_CHAIN_UNITID_BASE +uses HT_CHAIN_END_UNITID_BASE +uses SB_HT_CHAIN_ON_BUS0 +uses SB_HT_CHAIN_UNITID_OFFSET_ONLY + +uses CONFIG_LB_MEM_TOPK + + +## ROM_SIZE is the size of boot ROM that this board will use. +## ---> 512 Kbytes +default ROM_SIZE=(512*1024) + +## +## FALLBACK_SIZE is the amount of the ROM the complete fallback image will use +## +default FALLBACK_SIZE=(252*1024) + +#FAILOVER: 4K +default FAILOVER_SIZE=(4*1024) + +### +### Build options +### + +## +## Build code for the fallback boot +## +default HAVE_FALLBACK_BOOT=1 +default HAVE_FAILOVER_BOOT=1 + +## +## Build code to reset the motherboard from coreboot +## +default HAVE_HARD_RESET=1 + +## +## Build code to export a programmable irq routing table +## +default HAVE_PIRQ_TABLE=1 +default IRQ_SLOT_COUNT=13 + +## +## Build code to export an x86 MP table +## Useful for specifying IRQ routing values +## +default HAVE_MP_TABLE=1 + +## +## Build code to export a CMOS option table +## +default HAVE_OPTION_TABLE=1 + +## +## Move the default coreboot cmos range off of AMD RTC registers +## +default LB_CKS_RANGE_START=49 +default LB_CKS_RANGE_END=122 +default LB_CKS_LOC=123 + +## +## Build code for SMP support +## Only worry about 2 micro processors +## +default CONFIG_SMP=1 +default CONFIG_MAX_CPUS=2 +default CONFIG_MAX_PHYSICAL_CPUS=1 +default CONFIG_LOGICAL_CPUS=1 + +#1G memory hole +default HW_MEM_HOLE_SIZEK=0x100000 + +##HT Unit ID offset, default is 1, the typical one +default HT_CHAIN_UNITID_BASE=0 + +##real SB Unit ID, default is 0x20, mean dont touch it at last +#default HT_CHAIN_END_UNITID_BASE=0x10 + +#make the SB HT chain on bus 0, default is not (0) +default SB_HT_CHAIN_ON_BUS0=2 + +##only offset for SB chain?, default is yes(1) +default SB_HT_CHAIN_UNITID_OFFSET_ONLY=0 + +#BTEXT Console +#default CONFIG_CONSOLE_BTEXT=1 + +#VGA Console +default CONFIG_CONSOLE_VGA=1 +default CONFIG_PCI_ROM_RUN=1 + +## +## enable CACHE_AS_RAM specifics +## +default USE_DCACHE_RAM=1 +#default DCACHE_RAM_BASE=0xcf000 +#default DCACHE_RAM_SIZE=0x1000 +default DCACHE_RAM_BASE=0xc8000 +default DCACHE_RAM_SIZE=0x08000 +default DCACHE_RAM_GLOBAL_VAR_SIZE=0x01000 +default CONFIG_USE_INIT=0 + +default CONFIG_AP_CODE_IN_CAR=0 +default MEM_TRAIN_SEQ=2 +default WAIT_BEFORE_CPUS_INIT=0 + +## APIC stuff +#default ENABLE_APIC_EXT_ID=0 +#default APIC_ID_OFFSET=0x10 +#default LIFT_BSP_APIC_ID=0 + + +#default CONFIG_PCI_64BIT_PREF_MEM=1 + +## +## Build code to setup a generic IOAPIC +## +default CONFIG_IOAPIC=1 + +## +## Clean up the motherboard id strings +## +default MAINBOARD_PART_NUMBER="K8N Neo3 (MS-7135)" +default MAINBOARD_VENDOR="MSI" +default MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID=0x1462 +default MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID=0x7135 + +### +### coreboot layout values +### + +## ROM_IMAGE_SIZE is the amount of space to allow coreboot to occupy. +default ROM_IMAGE_SIZE = (64*1024) +#65536 + +## +## Use a small 8K stack +## +default STACK_SIZE=0x2000 + +## +## Use a small 16K heap +## +default HEAP_SIZE=0x4000 + +## +## Only use the option table in a normal image +## +#efault USE_OPTION_TABLE = !USE_FALLBACK_IMAGE +default USE_OPTION_TABLE = (!USE_FALLBACK_IMAGE) && (!USE_FAILOVER_IMAGE ) + +## +## coreboot C code runs at this location in RAM +## +default _RAMBASE=0x00004000 + +## +## Load the payload from the ROM +## +default CONFIG_ROM_PAYLOAD = 1 + +### +### Defaults of options that you may want to override in the target config file +### + +## +## The default compiler +## +default CC="$(CROSS_COMPILE)gcc -m32" +default HOSTCC="gcc" + +## +## Disable the gdb stub by default +## +default CONFIG_GDB_STUB=0 + +## +## The Serial Console +## + +# To Enable the Serial Console +default CONFIG_CONSOLE_SERIAL8250=1 + +## Select the serial console baud rate +default TTYS0_BAUD=115200 +#default TTYS0_BAUD=57600 +#default TTYS0_BAUD=38400 +#default TTYS0_BAUD=19200 +#default TTYS0_BAUD=9600 +#default TTYS0_BAUD=4800 +#default TTYS0_BAUD=2400 +#default TTYS0_BAUD=1200 + +# Select the serial console base port +default TTYS0_BASE=0x3f8 + +# Select the serial protocol +# This defaults to 8 data bits, 1 stop bit, and no parity +default TTYS0_LCS=0x3 + +## +### Select the coreboot loglevel +## +## EMERG 1 system is unusable +## ALERT 2 action must be taken immediately +## CRIT 3 critical conditions +## ERR 4 error conditions +## WARNING 5 warning conditions +## NOTICE 6 normal but significant condition +## INFO 7 informational +## DEBUG 8 debug-level messages +## SPEW 9 Way too many details + +## Request this level of debugging output +default DEFAULT_CONSOLE_LOGLEVEL=8 +## At a maximum only compile in this level of debugging +default MAXIMUM_CONSOLE_LOGLEVEL=8 + +## +## Select power on after power fail setting +default MAINBOARD_POWER_ON_AFTER_POWER_FAIL="MAINBOARD_POWER_ON" + +### End Options.lb +end Index: src/mainboard/msi/ms7135/chip.h =================================================================== --- src/mainboard/msi/ms7135/chip.h (revision 0) +++ src/mainboard/msi/ms7135/chip.h (revision 0) @@ -0,0 +1,25 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2008 Jonathan A. Kollasch + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +extern struct chip_operations mainboard_msi_ms7135_ops; + +struct mainboard_ms7135_config { + int nothing; +}; Index: src/mainboard/msi/ms7135/cmos.layout =================================================================== --- src/mainboard/msi/ms7135/cmos.layout (revision 0) +++ src/mainboard/msi/ms7135/cmos.layout (revision 0) @@ -0,0 +1,98 @@ +entries + +#start-bit length config config-ID name +#0 8 r 0 seconds +#8 8 r 0 alarm_seconds +#16 8 r 0 minutes +#24 8 r 0 alarm_minutes +#32 8 r 0 hours +#40 8 r 0 alarm_hours +#48 8 r 0 day_of_week +#56 8 r 0 day_of_month +#64 8 r 0 month +#72 8 r 0 year +#80 4 r 0 rate_select +#84 3 r 0 REF_Clock +#87 1 r 0 UIP +#88 1 r 0 auto_switch_DST +#89 1 r 0 24_hour_mode +#90 1 r 0 binary_values_enable +#91 1 r 0 square-wave_out_enable +#92 1 r 0 update_finished_enable +#93 1 r 0 alarm_interrupt_enable +#94 1 r 0 periodic_interrupt_enable +#95 1 r 0 disable_clock_updates +#96 288 r 0 temporary_filler +0 384 r 0 reserved_memory +384 1 e 4 boot_option +385 1 e 4 last_boot +386 1 e 1 ECC_memory +388 4 r 0 reboot_bits +392 3 e 5 baud_rate +395 1 e 1 hw_scrubber +396 1 e 1 interleave_chip_selects +397 2 e 8 max_mem_clock +399 1 e 2 dual_core +400 1 e 1 power_on_after_fail +412 4 e 6 debug_level +416 4 e 7 boot_first +420 4 e 7 boot_second +424 4 e 7 boot_third +428 4 h 0 boot_index +432 8 h 0 boot_countdown +440 4 e 9 slow_cpu +444 1 e 1 nmi +445 1 e 1 iommu +728 256 h 0 user_data +984 16 h 0 check_sum +# Reserve the extended AMD configuration registers +1000 24 r 0 reserved_memory + + + +enumerations + +#ID value text +1 0 Disable +1 1 Enable +2 0 Enable +2 1 Disable +4 0 Fallback +4 1 Normal +5 0 115200 +5 1 57600 +5 2 38400 +5 3 19200 +5 4 9600 +5 5 4800 +5 6 2400 +5 7 1200 +6 6 Notice +6 7 Info +6 8 Debug +6 9 Spew +7 0 Network +7 1 HDD +7 2 Floppy +7 8 Fallback_Network +7 9 Fallback_HDD +7 10 Fallback_Floppy +#7 3 ROM +8 0 400Mhz +8 1 333Mhz +8 2 266Mhz +8 3 200Mhz +9 0 off +9 1 87.5% +9 2 75.0% +9 3 62.5% +9 4 50.0% +9 5 37.5% +9 6 25.0% +9 7 12.5% + +checksums + +checksum 392 983 984 + + Index: src/mainboard/msi/ms7135/mainboard.c =================================================================== --- src/mainboard/msi/ms7135/mainboard.c (revision 0) +++ src/mainboard/msi/ms7135/mainboard.c (revision 0) @@ -0,0 +1,28 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2008 Jonathan A. Kollasch + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include "chip.h" + +#if CONFIG_CHIP_NAME == 1 +struct chip_operations mainboard_msi_ms7135_ops = { + CHIP_NAME("MSI MS7135 Mainboard") +}; +#endif Index: src/mainboard/msi/ms7135/cache_as_ram_auto.c =================================================================== --- src/mainboard/msi/ms7135/cache_as_ram_auto.c (revision 0) +++ src/mainboard/msi/ms7135/cache_as_ram_auto.c (revision 0) @@ -0,0 +1,276 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2007 AMD + * (Written by Yinghai Lu for AMD) + * Copyright (C) 2007 Philipp Degler + * (Thanks to LSRA University of Mannheim for their support) + * Copyright (C) 2008 Jonathan A. Kollasch + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#define ASSEMBLY 1 +#define __ROMCC__ + +#define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1) + +/* Used by raminit. */ +#define QRANK_DIMM_SUPPORT 1 + +/* Turn this on for SMBus debugging output. */ +#define DEBUG_SMBUS 0 + +#if CONFIG_LOGICAL_CPUS == 1 +#define SET_NB_CFG_54 1 +#endif + +#include +#include +#include +#include +#include +#include +#include "option_table.h" +#include "pc80/mc146818rtc_early.c" +#include "cpu/x86/lapic/boot_cpu.c" +#include "northbridge/amd/amdk8/reset_test.c" +#include "superio/winbond/w83627hf/w83627hf_early_serial.c" + +#if USE_FAILOVER_IMAGE == 0 + +/* Used by ck804_early_setup(). */ +#define CK804_NUM 1 +#define CK804_USE_NIC 1 +#define CK804_USE_ACI 1 + +#if CONFIG_USE_INIT == 0 +#include "lib/memcpy.c" +#endif + +#include +#include "pc80/serial.c" +#include "arch/i386/lib/console.c" +#include "ram/ramtest.c" +#include "northbridge/amd/amdk8/incoherent_ht.c" +#include "southbridge/nvidia/ck804/ck804_early_smbus.c" +#include "northbridge/amd/amdk8/raminit.h" +#include "cpu/amd/model_fxx/apic_timer.c" +#include "lib/delay.c" +#include "northbridge/amd/amdk8/debug.c" +#include "cpu/amd/mtrr/amd_earlymtrr.c" +#include "cpu/x86/bist.h" +#include "northbridge/amd/amdk8/setup_resource_map.c" +#include "northbridge/amd/amdk8/coherent_ht.c" +#include "cpu/amd/dualcore/dualcore.c" + +static void memreset_setup(void) +{ + /* FIXME: Nothing to do? */ +} + +static void memreset(int controllers, const struct mem_controller *ctrl) +{ + /* FIXME: Nothing to do? */ +} + +static inline void activate_spd_rom(const struct mem_controller *ctrl) +{ + /* FIXME: Nothing to do? */ +} + +static inline int spd_read_byte(unsigned device, unsigned address) +{ + return smbus_read_byte(device, address); +} + +#include "northbridge/amd/amdk8/raminit.c" +#include "sdram/generic_sdram.c" +#include "southbridge/nvidia/ck804/ck804_early_setup_ss.h" +#include "southbridge/nvidia/ck804/ck804_early_setup_car.c" +#include "cpu/amd/car/copy_and_run.c" +#include "cpu/amd/car/post_cache_as_ram.c" +#include "cpu/amd/model_fxx/init_cpus.c" + +#endif /* USE_FAILOVER_IMAGE */ + +#if ((HAVE_FAILOVER_BOOT==1) && (USE_FAILOVER_IMAGE == 1)) \ + || ((HAVE_FAILOVER_BOOT==0) && (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; + + /* Subject decoding */ + 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); + + /* LPC Positive Decode 0 */ + dword = pci_read_config32(PCI_DEV(0, CK804_DEVN_BASE + 1, 0), 0xa0); + /* Serial 0, Serial 1 */ + dword |= (1 << 0) | (1 << 1); + pci_write_config32(PCI_DEV(0, CK804_DEVN_BASE + 1, 0), 0xa0, dword); +} + +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? */ + 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: + __asm__ volatile ("jmp __normal_image" + : /* outputs */ + :"a" (bist), "b"(cpu_init_detectedx) /* inputs */ + ); + +fallback_image: + +#if HAVE_FAILOVER_BOOT == 1 + __asm__ volatile ("jmp __fallback_image" + : /* outputs */ + :"a" (bist), "b"(cpu_init_detectedx) /* inputs */ + ) +#endif + ; +} + +#endif /* ((HAVE_FAILOVER_BOOT==1) && (USE_FAILOVER_IMAGE == 1)) ... */ + +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 HAVE_FAILOVER_BOOT == 1 +#if USE_FAILOVER_IMAGE == 1 + failover_process(bist, cpu_init_detectedx); +#else + real_main(bist, cpu_init_detectedx); +#endif +#else +#if USE_FALLBACK_IMAGE == 1 + failover_process(bist, cpu_init_detectedx); +#endif + real_main(bist, cpu_init_detectedx); +#endif +} + +#if USE_FAILOVER_IMAGE == 0 +void real_main(unsigned long bist, unsigned long cpu_init_detectedx) +{ + static const uint16_t spd_addr[] = { + (0xa << 3) | 0, (0xa << 3) | 1, 0, 0, + 0, 0, 0, 0, + 0, 0, 0, 0, + 0, 0, 0, 0, + }; + + int needs_reset; + unsigned bsp_apicid = 0; + + struct mem_controller ctrl[8]; + unsigned nodes; + + if (bist == 0) { + bsp_apicid = init_cpus(cpu_init_detectedx); + } + + w83627hf_enable_serial(SERIAL_DEV, TTYS0_BASE); + uart_init(); + console_init(); + + /* Halt if there was a built in self test failure */ + report_bist_failure(bist); + +#if 0 + dump_pci_device(PCI_DEV(0, 0x18, 0)); +#endif + + needs_reset = setup_coherent_ht_domain(); + + wait_all_core0_started(); +#if CONFIG_LOGICAL_CPUS==1 + // It is said that we should start core1 after all core0 launched + start_other_cores(); + wait_all_other_cores_started(bsp_apicid); +#endif + + needs_reset |= ht_setup_chains_x(); + + needs_reset |= ck804_early_setup_x(); + + if (needs_reset) { + print_info("ht reset -\r\n"); + soft_reset(); + } + + allow_all_aps_stop(bsp_apicid); + + nodes = get_nodes(); + //It's the time to set ctrl now; + fill_mem_ctrl(nodes, ctrl, spd_addr); + + enable_smbus(); + +#if 0 + dump_spd_registers(&ctrl[0]); + dump_smbus_registers(); +#endif + + memreset_setup(); + sdram_initialize(nodes, ctrl); + +#if 0 + print_pci_devices(); + dump_pci_devices(); +#endif + + post_cache_as_ram(); +} +#endif /* USE_FAILOVER_IMAGE */ Index: src/mainboard/msi/ms7135/get_bus_conf.c =================================================================== --- src/mainboard/msi/ms7135/get_bus_conf.c (revision 0) +++ src/mainboard/msi/ms7135/get_bus_conf.c (revision 0) @@ -0,0 +1,127 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2007 AMD + * (Written by Yinghai Lu for AMD) + * Copyright (C) 2007 Philipp Degler + * (Thanks to LSRA University of Mannheim for their support) + * Copyright (C) 2008 Jonathan A. Kollasch + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include +#include +#include +#include +#if CONFIG_LOGICAL_CPUS == 1 +#include +#endif + +#include + +/* Global variables for MB layouts and these will be shared by irqtable, + * mptable and acpi_tables. + */ +/* busnum is default */ +unsigned char bus_isa; +unsigned char bus_ck804[6]; +unsigned apicid_ck804; + +unsigned pci1234x[] = { //Here you only need to set value in pci1234 for HT-IO that could be installed or not + //You may need to preset pci1234 for HTIO board, please refer to src/northbridge/amd/amdk8/get_sblk_pci1234.c for detail + 0x0000ff0, //no HTIO for ms7135 +}; +unsigned hcdnx[] = { //HT Chain device num, actually it is unit id base of every ht device in chain, assume every chain only have 4 ht device at most + 0x20202020, //ms7135 has only one ht-chain +}; +unsigned bus_type[256]; + +extern void get_sblk_pci1234(void); + +static unsigned get_bus_conf_done = 0; + +void get_bus_conf(void) +{ + unsigned apicid_base; + + device_t dev; + unsigned sbdn; + int i, j; + + if (get_bus_conf_done == 1) + return; //do it only once + + get_bus_conf_done = 1; + + sysconf.hc_possible_num = sizeof(pci1234x) / sizeof(pci1234x[0]); + sysconf.hc_possible_num = sizeof(pci1234x) / sizeof(pci1234x[0]); + for (i = 0; i < sysconf.hc_possible_num; i++) { + sysconf.pci1234[i] = pci1234x[i]; + sysconf.hcdn[i] = hcdnx[i]; + } + + get_sblk_pci1234(); + + sysconf.sbdn = (sysconf.hcdn[0] & 0xff); // first byte of first chain + sbdn = sysconf.sbdn; + + for (i = 0; i < 6; i++) { + bus_ck804[i] = 0; + } + + for (i = 0; i < 256; i++) { + bus_type[i] = 0; + } + + bus_type[0] = 1; //pci + + bus_ck804[0] = (sysconf.pci1234[0] >> 16) & 0xff; + + bus_type[bus_ck804[0]] = 1; + + /* CK804 */ + int dn = -1; + for (i = 1; i < 4; i++) { + switch (i) { + case 1: dn = 9; break; + case 2: dn = 13; break; + case 3: dn = 14; break; + default: dn = -1; break; + } + dev = dev_find_slot(bus_ck804[0], PCI_DEVFN(sbdn + dn, 0)); + if (dev) { + bus_ck804[i] = pci_read_config8(dev, PCI_SECONDARY_BUS); + bus_isa = pci_read_config8(dev, PCI_SUBORDINATE_BUS); + bus_isa++; + for (j = bus_ck804[i]; j < bus_isa; j++) + bus_type[j] = 1; + } else { + printk_debug + ("ERROR - could not find PCI %02x:%02x.0, using defaults\n", + bus_ck804[0], sbdn + dn); + bus_isa = bus_ck804[i - 1] + 1; + } + } + +/*I/O APICs: APIC ID Version State Address*/ +#if CONFIG_LOGICAL_CPUS==1 + apicid_base = get_apicid_base(3); +#else + apicid_base = CONFIG_MAX_PHYSICAL_CPUS; +#endif + apicid_ck804 = apicid_base + 0; +} Index: src/config/Config.lb =================================================================== --- src/config/Config.lb (revision 3088) +++ src/config/Config.lb (working copy) @@ -5,7 +5,7 @@ makedefine CPP:= $(CC) -x assembler-with-cpp -DASSEMBLY -E makedefine LIBGCC_FILE_NAME := $(shell $(CC) -print-libgcc-file-name) -makedefine GCC_INC_DIR := $(shell LC_ALL=C $(CC) -print-search-dirs | sed -ne "s/install: \(.*\)/\1include/gp") +makedefine GCC_INC_DIR := /usr/include makedefine CPPFLAGS := -I$(TOP)/src/include -I$(TOP)/src/arch/$(ARCH)/include -I$(GCC_INC_DIR) $(CPUFLAGS) makedefine CFLAGS := $(CPU_OPT) $(DISTRO_CFLAGS) $(CPPFLAGS) -Os -nostdinc -nostdlib -fno-builtin -Wall Index: targets/msi/ms7135/Config.lb =================================================================== --- targets/msi/ms7135/Config.lb (revision 0) +++ targets/msi/ms7135/Config.lb (revision 0) @@ -0,0 +1,61 @@ +## +## This file is part of the coreboot project. +## +## Copyright (C) 2007 Philipp Degler +## (Thanks to LSRA University of Mannheim for their support) +## Copyright (C) 2008 Jonathan A. Kollasch +## +## This program is free software; you can redistribute it and/or modify +## it under the terms of the GNU General Public License as published by +## the Free Software Foundation; either version 2 of the License, or +## (at your option) any later version. +## +## This program is distributed in the hope that it will be useful, +## but WITHOUT ANY WARRANTY; without even the implied warranty of +## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +## GNU General Public License for more details. +## +## You should have received a copy of the GNU General Public License +## along with this program; if not, write to the Free Software +## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +## + +target ms7135 +mainboard msi/ms7135 + +option DEFAULT_CONSOLE_LOGLEVEL=8 +option MAXIMUM_CONSOLE_LOGLEVEL=8 + +option HAVE_PIRQ_TABLE=1 +option CONFIG_CONSOLE_VGA=1 +option CONFIG_PCI_ROM_RUN=1 + + +romimage "normal" + option USE_FAILOVER_IMAGE=0 + option USE_FALLBACK_IMAGE=0 + option ROM_IMAGE_SIZE=0x20000 + option XIP_ROM_SIZE=0x20000 + option COREBOOT_EXTRA_VERSION="_Normal" + payload /tmp/payload.elf +end + +romimage "fallback" + option USE_FAILOVER_IMAGE=0 + option USE_FALLBACK_IMAGE=1 + option ROM_IMAGE_SIZE=0x20000 + option XIP_ROM_SIZE=0x20000 + option COREBOOT_EXTRA_VERSION="_Fallback" + payload /tmp/payload.elf +end + +romimage "failover" + option USE_FAILOVER_IMAGE=1 + option USE_FALLBACK_IMAGE=0 + option ROM_IMAGE_SIZE=FAILOVER_SIZE + option XIP_ROM_SIZE=FAILOVER_SIZE + option COREBOOT_EXTRA_VERSION="_Failover" +end + +buildrom ./coreboot.rom ROM_SIZE "normal" "fallback" "failover" +#buildrom ./coreboot.rom ROM_SIZE "normal" "fallback" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jakllsch at kollasch.net Sat Feb 2 20:45:55 2008 From: jakllsch at kollasch.net (jakllsch at kollasch.net) Date: Sat, 2 Feb 2008 13:45:55 -0600 Subject: [coreboot] [LinuxBIOS] [patch] MSI MS-7135 (this time with attachment) In-Reply-To: References: <20071207054444.GW2629@kirkkit.kollasch.net> <20080201163626.GA1756@kirkkit.kollasch.net> <20080201235121.GC1756@kirkkit.kollasch.net> Message-ID: <20080202194554.GG1756@kirkkit.kollasch.net> On Fri, Feb 01, 2008 at 10:29:17PM -0800, David Hendricks wrote: > Have you benchmarked SATA performance? I'm curious if you can run a quick > "time dd" kind of benchmark. I was only getting around 2MB/sec. Then again, > I had not applied this magic at the time. I get a normal 80mbyte/s or so out of it here. I'd assume you had an interrupts issue. Jonathan Kollasch -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ward at gnu.org Sat Feb 2 21:49:09 2008 From: ward at gnu.org (Ward Vandewege) Date: Sat, 2 Feb 2008 15:49:09 -0500 Subject: [coreboot] buildrom trac Message-ID: <20080202204909.GA29361@localdomain> Stepan gracefully configured trac for buildrom at http://tracker.coreboot.org/trac/buildrom Thanks! Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From rminnich at gmail.com Sat Feb 2 23:11:27 2008 From: rminnich at gmail.com (ron minnich) Date: Sat, 2 Feb 2008 14:11:27 -0800 Subject: [coreboot] memtest running on alix1c! Message-ID: <13426df10802021411u453d18f1he57a3be8600b1a85@mail.gmail.com> it was a minicom/terminal size issue. A big minicom caused memtest to get a divide by zero. It's running! It has confusion: L1 Cache: Unknown | Test #6 [Moving inversions, 32 bit pattern] L2 Cache: Unknown | Testing: 120K - 256M 255M but hey ... ron From svn at coreboot.org Sun Feb 3 00:12:48 2008 From: svn at coreboot.org (coreboot) Date: Sat, 02 Feb 2008 23:12:48 -0000 Subject: [coreboot] #69: Fix mptable util so the output will compile In-Reply-To: <073.b38df2b306d12e435820a4cd51225583@coreboot.org> References: <073.b38df2b306d12e435820a4cd51225583@coreboot.org> Message-ID: <082.f453528a06f2a776783831812d2b250b@coreboot.org> #69: Fix mptable util so the output will compile ------------------------------------------------------+--------------------- Reporter: Jon Dufresne | Owner: somebody Type: defect | Status: closed Priority: major | Milestone: Component: code | Version: v2 Resolution: fixed | Keywords: Dependencies: | Patchstatus: patch has been committed ------------------------------------------------------+--------------------- Comment (by anonymous): Signed-off-by: Jon Dufresne -- Ticket URL: coreboot From svn at coreboot.org Sun Feb 3 00:13:46 2008 From: svn at coreboot.org (coreboot) Date: Sat, 02 Feb 2008 23:13:46 -0000 Subject: [coreboot] #70: fix util/getpir so that the output will compile In-Reply-To: <073.eb95d8161cbec83dfbc8ab8396f01eee@coreboot.org> References: <073.eb95d8161cbec83dfbc8ab8396f01eee@coreboot.org> Message-ID: <082.4b6637f537591e6d113b1f349b1329a9@coreboot.org> #70: fix util/getpir so that the output will compile ------------------------------------------------------+--------------------- Reporter: Jon Dufresne | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: code | Version: v2 Resolution: | Keywords: Dependencies: | Patchstatus: patch needs work ------------------------------------------------------+--------------------- Comment (by jon.dufresne at gmail.com): Signed-off-by: Jon Dufresne -- Ticket URL: coreboot From joe at smittys.pointclark.net Sun Feb 3 02:34:30 2008 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Sat, 02 Feb 2008 20:34:30 -0500 Subject: [coreboot] Run PCI rom before PCI bus scan?? Message-ID: <20080202203430.1p2at6gtc0skw0so@www.smittys.pointclark.net> Hello, Is there a way to run a PCI rom before the PCI bus scan runs??? Thanks - Joe From corey.osgood at gmail.com Sun Feb 3 03:21:19 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Sat, 2 Feb 2008 21:21:19 -0500 Subject: [coreboot] Run PCI rom before PCI bus scan?? In-Reply-To: <20080202203430.1p2at6gtc0skw0so@www.smittys.pointclark.net> References: <20080202203430.1p2at6gtc0skw0so@www.smittys.pointclark.net> Message-ID: Yep. Take a look in pci_rom.c, there's a function that runs the rom (I think it's just rom_run but it might be pci_rom_run). It can't go into auto.c, since it's only in post-ram linuxbios, but there should be somewhere you can put it (maybe i82801xx.c's i82801xx_init is early enough, or else the pci domain setup). I can't guarantee that it'll actually work or help, though. If it does work, do register dumps both before and after the rom runs, and see what it does, we can probably do the same thing without the rom. -Corey On Feb 2, 2008 8:34 PM, wrote: > Hello, > Is there a way to run a PCI rom before the PCI bus scan runs??? > > Thanks - Joe > > -- > coreboot mailing list > coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Sun Feb 3 03:34:20 2008 From: rminnich at gmail.com (ron minnich) Date: Sat, 2 Feb 2008 18:34:20 -0800 Subject: [coreboot] Run PCI rom before PCI bus scan?? In-Reply-To: <20080202203430.1p2at6gtc0skw0so@www.smittys.pointclark.net> References: <20080202203430.1p2at6gtc0skw0so@www.smittys.pointclark.net> Message-ID: <13426df10802021834i5b892084r2e06fa765e4b4d89@mail.gmail.com> On Feb 2, 2008 5:34 PM, wrote: > Hello, > Is there a way to run a PCI rom before the PCI bus scan runs??? Yes, we have to do this on any later geode. The LX port should give you a hint on how it's done. Thanks ron From rminnich at gmail.com Sun Feb 3 03:41:13 2008 From: rminnich at gmail.com (ron minnich) Date: Sat, 2 Feb 2008 18:41:13 -0800 Subject: [coreboot] memtest on lx on v3: working Message-ID: <13426df10802021841t4b9ecb68u43d83d414720e37d@mail.gmail.com> turned out the problem was some weirdness between minicom/memtest on serial. I resized the terminal window that minicom was in and memtest has been running fine for almost 5 hours. I also have mode cache enable around so that it happens in disable_car. This helps a bit. But I still feel we're not caching ROM. ron From tiagomnm at gmail.com Sun Feb 3 03:44:52 2008 From: tiagomnm at gmail.com (Tiago Marques) Date: Sun, 3 Feb 2008 02:44:52 +0000 Subject: [coreboot] goal for march summit In-Reply-To: References: <13426df10802012049t54d8f799p7b0c7b99f315583@mail.gmail.com> <47A43EA8.1080702@assembler.cz> <47A4651A.6030603@gmx.net> <47A46DEB.1060709@assembler.cz> Message-ID: I have an M2V, haven't tried coreboot yet, but flashrom works like a charm after some effortless tweaking. PLCC is socketed. The onboard flash chip still needs support in flashrom though. I flashed an W39V040B there, the M2V has a W39V040C. Then again, you should probably pick a bioas with a 8Mb chip. ASRocks are mostly crap, don't be surprised if they decide to die while in development. Tiago From wrightjmf at gmail.com Sun Feb 3 05:09:00 2008 From: wrightjmf at gmail.com (Jeremy Wright) Date: Sun, 3 Feb 2008 04:09:00 +0000 Subject: [coreboot] Capio II 320 and Coreboot In-Reply-To: <47A4998B.3040900@gmx.net> References: <13426df10802011059sf8e3f99j25749f957e07af83@mail.gmail.com> <13426df10802011115y47de664fo57fcede4b1f3fd3@mail.gmail.com> <47A4998B.3040900@gmx.net> Message-ID: >http://damnsmalllinux.org/cgi-bin/forums/ikonboard.cgi?act=Print;f=26;t=12165 >has some interesting info about Damn Small Linux on the Capio II. Yeah, I've seen that before, but I'm having a hard time finding a TC325. I'll keep my eyes out for one though. Thanks. On Feb 2, 2008 4:25 PM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006 at gmx.net> wrote: > On 01.02.2008 20:32, Jeremy Wright wrote: > > I can't run Linux on the Capios because they don't have any external > drive > > access, and the only thing that they will boot off of is the DiskOnChip > > which has Windows CE on it (which wants to see a Windows Terminal > Server). > > > > > http://damnsmalllinux.org/cgi-bin/forums/ikonboard.cgi?act=Print;f=26;t=12165 > has some interesting info about Damn Small Linux on the Capio II. > > > One of the reasons that I am trying Coreboot is to get to where I can > > reprogram the DOC to put Linux on it. So, I'm stuck on testing serial > > communications with minicom on the Capio end. > > I think that if you manage to reprogram the DOC outside the Capio, you > can run Linux and use that to further debug Coreboot. > > > Regards, > Carl-Daniel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.hendricks at gmail.com Sun Feb 3 06:35:31 2008 From: david.hendricks at gmail.com (David Hendricks) Date: Sat, 2 Feb 2008 21:35:31 -0800 Subject: [coreboot] [LinuxBIOS] [patch] MSI MS-7135 (this time with attachment) In-Reply-To: <20080202194554.GG1756@kirkkit.kollasch.net> References: <20071207054444.GW2629@kirkkit.kollasch.net> <20080201163626.GA1756@kirkkit.kollasch.net> <20080201235121.GC1756@kirkkit.kollasch.net> <20080202194554.GG1756@kirkkit.kollasch.net> Message-ID: That's very possible -- My pirq table didn't look nearly as nice as yours! On Feb 2, 2008 11:45 AM, wrote: > On Fri, Feb 01, 2008 at 10:29:17PM -0800, David Hendricks wrote: > > Have you benchmarked SATA performance? I'm curious if you can run a > quick > > "time dd" kind of benchmark. I was only getting around 2MB/sec. Then > again, > > I had not applied this magic at the time. > > I get a normal 80mbyte/s or so out of it here. > I'd assume you had an interrupts issue. > > Jonathan Kollasch > -------------- next part -------------- An HTML attachment was scrubbed... URL: From c-d.hailfinger.devel.2006 at gmx.net Sun Feb 3 14:50:54 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sun, 03 Feb 2008 14:50:54 +0100 Subject: [coreboot] goal for march summit In-Reply-To: References: <13426df10802012049t54d8f799p7b0c7b99f315583@mail.gmail.com> <47A43EA8.1080702@assembler.cz> <47A4651A.6030603@gmx.net> <47A46DEB.1060709@assembler.cz> Message-ID: <47A5C6BE.8070400@gmx.net> On 03.02.2008 03:44, Tiago Marques wrote: > I have an M2V, haven't tried coreboot yet, but flashrom works like a > charm after some effortless tweaking. PLCC is socketed. > Can you post a patch? > The onboard flash chip still needs support in flashrom though. I > flashed an W39V040B there, the M2V has a W39V040C. > flashrom -V, please. > Then again, you should probably pick a bioas with a 8Mb chip. > ASRocks are mostly crap, don't be surprised if they decide to die > while in development. > I thought they had improved in the last few years. Can you post superiotool, dmidecode, lspci -nnvvvxxx to the list in a new thread? That would help a lot to check how difficult porting is going to be. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Sun Feb 3 14:53:12 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sun, 03 Feb 2008 14:53:12 +0100 Subject: [coreboot] memtest running on alix1c! In-Reply-To: <13426df10802021411u453d18f1he57a3be8600b1a85@mail.gmail.com> References: <13426df10802021411u453d18f1he57a3be8600b1a85@mail.gmail.com> Message-ID: <47A5C748.5040408@gmx.net> Wohooo! Great! Congratulations! On 02.02.2008 23:11, ron minnich wrote: > it was a minicom/terminal size issue. A big minicom caused memtest to > get a divide by zero. It's running! > Haha, a memtest bug. I guess they'd like to hear about it. > It has confusion: > L1 Cache: Unknown | Test #6 [Moving inversions, 32 bit pattern] > L2 Cache: Unknown | Testing: 120K - 256M 255M > Good enough for now. We might want to find out why it has no idea about cache size, though. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Sun Feb 3 14:57:34 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sun, 03 Feb 2008 14:57:34 +0100 Subject: [coreboot] memtest on lx on v3: working In-Reply-To: <13426df10802021841t4b9ecb68u43d83d414720e37d@mail.gmail.com> References: <13426df10802021841t4b9ecb68u43d83d414720e37d@mail.gmail.com> Message-ID: <47A5C84E.10909@gmx.net> On 03.02.2008 03:41, ron minnich wrote: > turned out the problem was some weirdness between minicom/memtest on > serial. I resized the terminal window that minicom was in and memtest > has been running fine for almost 5 hours. > > I also have mode cache enable around so that it happens in > disable_car. This helps a bit. Care to send a patch? I'd like to commit this as soon as possible. > But I still feel we're not caching ROM. > IIRC there was some tool to compare important MSR settings with a reference. Maybe some variable sized MTRRs are not set correctly. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Sun Feb 3 15:01:30 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sun, 03 Feb 2008 15:01:30 +0100 Subject: [coreboot] Run PCI rom before PCI bus scan?? In-Reply-To: <13426df10802021834i5b892084r2e06fa765e4b4d89@mail.gmail.com> References: <20080202203430.1p2at6gtc0skw0so@www.smittys.pointclark.net> <13426df10802021834i5b892084r2e06fa765e4b4d89@mail.gmail.com> Message-ID: <47A5C93A.6090708@gmx.net> On 03.02.2008 03:34, ron minnich wrote: > On Feb 2, 2008 5:34 PM, wrote: > >> Hello, >> Is there a way to run a PCI rom before the PCI bus scan runs??? >> > > Yes, we have to do this on any later geode. The LX port should give > you a hint on how it's done. > Sorry, but how are you going to run a ROM before you know where it is located? I can see a way to run an image of a PCI ROM before PCI bus scan if the image resides in main system flash, but otherwise... Regards, Carl-Daniel From tsylla at gmail.com Sun Feb 3 16:18:25 2008 From: tsylla at gmail.com (Tom Sylla) Date: Sun, 03 Feb 2008 10:18:25 -0500 Subject: [coreboot] memtest running on alix1c! In-Reply-To: <47A5C748.5040408@gmx.net> References: <13426df10802021411u453d18f1he57a3be8600b1a85@mail.gmail.com> <47A5C748.5040408@gmx.net> Message-ID: <47A5DB41.9090901@gmail.com> >> It has confusion: >> L1 Cache: Unknown | Test #6 [Moving inversions, 32 bit pattern] >> L2 Cache: Unknown | Testing: 120K - 256M 255M See if you can make sure this is not another memtest bug. For a long time, memtest did not know that Geode LX CPUID meant to read the cache information like an AMD processor. I think the issue was fixed in more recent memtest versions. If memtest is ok, make sure the cache information MSRs for CPUID are being programmed correctly. From urbez at linuxupc.upc.edu Sun Feb 3 16:49:04 2008 From: urbez at linuxupc.upc.edu (Urbez Santana Roma) Date: Sun, 03 Feb 2008 16:49:04 +0100 Subject: [coreboot] VIA EPIA CN100000 is finally Working all. Message-ID: <1202053744.3231.43.camel@urbez.site> Finally works, my mainboard complete, with the IDE +dma, network, usb, etc... I must only add the same that y have commented in my last email, for working the access of IDE , network, etc. Mainboard: VIA EPIA CN10000. Chipsets: VT8237 and CN700 Cpu: C7 Ram: 512MB DDR2 KVR533D2N4 Linux Kernel: 2.6.22 1. Make a clone of the last posted code for CN700/C7 jetway mainboard of Corey Osgood, for your mainboard. 2. Set to 1 the 20 bit in the function sdram_enable() to all MRS RAM Commands. If not, the Kingstom Memory not initiates correctly. 3. comment the call to the function disable_sata(), if not, your normal ide not appears in the PCI config space. 4. Add the follow code to the end of the function main() in auto.c: if not, your normal IDE cannot use DMA and via-rhine, usb's, etc, not works. //This enable the access of PCI devices to the PCI bus master? pci_write_config8(cn700->d0f7, 0x57, 0x20);//was 0x01 5. If you will that the FILO not confuses scanning PCI, you must add, to the end of main() in auto.c: pci_write_config8(cn700->d1f0,0x19,0x1,CF8);//enable PCI-BRIGDE SECONDARY BUS pci_write_config8(cn700->d1f0,0x1a,0x1,CF8); 6. If you want that your BIOS, runs at the maximum CPU speed, in my case, the CPU starts with 800MHz, and i needed in the bios that works with 1000MHz. You can add this if u will: #define MSR_IA32_PERF_STATUS 0x00000198 #define MSR_IA32_PERF_CTL 0x00000199 #define MSR_IA32_MISC_ENABLE 0x000001a0 msr_t msr; print_debug("Enabling C7 Power Save\r\n"); msr=rdmsr(MSR_IA32_MISC_ENABLE); if (!(msr.lo & 0x10000)) {msr.lo| 0x10000;wrmsr(MSR_IA32_MISC_ENABLE,msr); msr=rdmsr(MSR_IA32_PERF_STATUS); //TODO: wait CPU not busy bit 16 & 17 off (STATUS) wrmsr(MSR_IA32_PERF_CTL, 0, (hi&0xff00)| ((hi>>16)&0x00ff)); //Max multi Factor, and minimum voltage //TODO: wait CPU transition bit 16 & 17 off (STATUS) 7. If you will, you can generate your fadt.c and dsdt.c with the genfadt and gendsdt tool, or generate one new. 8. Force the ACPI in the kernel if not uses it with acpi=force 9. If you want that your kernel recognises lapic, you must change the kernel driver, for not ignore another Vendors differs of AMD and Intel, in the function "static int __init detect_init_APIC (void)" of the file ./arch/i386/kernel/apic.c End. From joe at smittys.pointclark.net Sun Feb 3 17:59:35 2008 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Sun, 03 Feb 2008 11:59:35 -0500 Subject: [coreboot] Run PCI rom before PCI bus scan?? In-Reply-To: <47A5C93A.6090708@gmx.net> References: <20080202203430.1p2at6gtc0skw0so@www.smittys.pointclark.net> <13426df10802021834i5b892084r2e06fa765e4b4d89@mail.gmail.com> <47A5C93A.6090708@gmx.net> Message-ID: <20080203115935.i97o0dio00kkk8oc@www.smittys.pointclark.net> Quoting Carl-Daniel Hailfinger : > On 03.02.2008 03:34, ron minnich wrote: >> On Feb 2, 2008 5:34 PM, wrote: >> >>> Hello, >>> Is there a way to run a PCI rom before the PCI bus scan runs??? >>> >> >> Yes, we have to do this on any later geode. The LX port should give >> you a hint on how it's done. >> > > Sorry, but how are you going to run a ROM before you know where it is > located? I can see a way to run an image of a PCI ROM before PCI bus > scan if the image resides in main system flash, but otherwise... > > Regards, > Carl-Daniel > Ok, let me be more specific. I am pretty sure the pci rom for the 82562ET nic runs and powers on the onboard ethernet device. The nic does not have an eeprom. All the device settings are kept in the pci rom on the bios. After the rom runs it enables it, sets up PHY registers, sets up it PCI config registers, and requests use of the PCI bridge. That is why I need it to run before the PCI bus scan. Make sense? Thanks - Joe From rminnich at gmail.com Sun Feb 3 18:15:09 2008 From: rminnich at gmail.com (ron minnich) Date: Sun, 3 Feb 2008 09:15:09 -0800 Subject: [coreboot] Run PCI rom before PCI bus scan?? In-Reply-To: <20080203115935.i97o0dio00kkk8oc@www.smittys.pointclark.net> References: <20080202203430.1p2at6gtc0skw0so@www.smittys.pointclark.net> <13426df10802021834i5b892084r2e06fa765e4b4d89@mail.gmail.com> <47A5C93A.6090708@gmx.net> <20080203115935.i97o0dio00kkk8oc@www.smittys.pointclark.net> Message-ID: <13426df10802030915j5b094d01k898c5bf7d9d5d1a4@mail.gmail.com> Joe, I think Carl-Daniel is asking: where is the image for the PCI ROM located? In BIOS flash, as it is on some systems? or on some PCI card? If on a PCI card, that makes running it before PCI is configured more "interesting". Not impossible, just harder. ron From stepan at coresystems.de Sun Feb 3 19:37:38 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 3 Feb 2008 19:37:38 +0100 Subject: [coreboot] Run PCI rom before PCI bus scan?? In-Reply-To: <20080202203430.1p2at6gtc0skw0so@www.smittys.pointclark.net> References: <20080202203430.1p2at6gtc0skw0so@www.smittys.pointclark.net> Message-ID: <20080203183738.GA4289@coresystems.de> * joe at smittys.pointclark.net [080203 02:34]: > Hello, > Is there a way to run a PCI rom before the PCI bus scan runs??? Running a _PCI_ ROM without knowing where the PCI device lives (ie. before the _scan_) sounds impossible to me. There might be something wrong with the approach. Why do you want/need to do this? We do execute 16bit bios binary chunks in vm86 mode before the pci scan on geode. But those are not option roms but VSA that are required to make some virtual devices appear at all. Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From r.marek at assembler.cz Sun Feb 3 19:52:50 2008 From: r.marek at assembler.cz (Rudolf Marek) Date: Sun, 03 Feb 2008 19:52:50 +0100 Subject: [coreboot] VIA EPIA CN100000 is finally Working all. In-Reply-To: <1202053744.3231.43.camel@urbez.site> References: <1202053744.3231.43.camel@urbez.site> Message-ID: <47A60D82.9010300@assembler.cz> Hi Urbez, > 4. Add the follow code to the end of the function main() in auto.c: if > not, your normal IDE cannot use DMA and via-rhine, usb's, etc, not > works. > > //This enable the access of PCI devices to the PCI bus master? > pci_write_config8(cn700->d0f7, 0x57, 0x20);//was 0x01 I think this is connected to some last DRAM address stuff. DMA may not work if this is incorrect. Consult some similar datasheet jjj.ivn.pbz.gj!ra!qbjaybnqf!qngnfurrgf!puvcfrgf!QF_PA400_118.mvc It may be the last bank ending address??? Perhaps this must be copied from function 3 maybe? > > 5. If you will that the FILO not confuses scanning PCI, you must add, to > the end of main() in auto.c: > > pci_write_config8(cn700->d1f0,0x19,0x1,CF8);//enable PCI-BRIGDE > SECONDARY BUS > pci_write_config8(cn700->d1f0,0x1a,0x1,CF8); Perhaps is something translating configuration cycles? Rudolf From joe at smittys.pointclark.net Sun Feb 3 20:44:43 2008 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Sun, 03 Feb 2008 14:44:43 -0500 Subject: [coreboot] Run PCI rom before PCI bus scan?? In-Reply-To: <20080203183738.GA4289@coresystems.de> References: <20080202203430.1p2at6gtc0skw0so@www.smittys.pointclark.net> <20080203183738.GA4289@coresystems.de> Message-ID: <20080203144443.q9r9b16s00wgk8k0@www.smittys.pointclark.net> Quoting Stefan Reinauer : > * joe at smittys.pointclark.net [080203 02:34]: >> Hello, >> Is there a way to run a PCI rom before the PCI bus scan runs??? > > Running a _PCI_ ROM without knowing where the PCI device lives (ie. > before the _scan_) sounds impossible to me. Shouldn't be impossible if you manually told coreboot where the PCI device lives. > There might be something > wrong with the approach. Why do you want/need to do this? > Again. coreboot is not able to find the 82562ET onboard nic. The lights on the nic are not coming on. And there is no eeprom, everything comes from the pci rom in the bios. Here is what I think the PCI rom does with the original bios: 1. powers on and enables device 2. sets up PHY registers 3. sets up it PCI config registers 4. and requests use of the PCI bridge If I could figure out how to do #1 the rest would be fairly simple to setup,although I am not exactly sure about PHY registers. Then I wouldn't need the pci rom at all. > Joe, I think Carl-Daniel is asking: where is the image for the PCI ROM > located? In BIOS flash, as it is on some systems? or on some PCI card? > If on a PCI card, that makes running it before PCI is configured more > "interesting". Not impossible, just harder. Yes, the pci rom currently lives in the bios. It is a three part rom, Intel boot agent, Intel PXE, and the base code (I think the base code is the only real part I need??). Thanks - Joe From peter at stuge.se Sun Feb 3 20:50:17 2008 From: peter at stuge.se (Peter Stuge) Date: Sun, 3 Feb 2008 20:50:17 +0100 Subject: [coreboot] Run PCI rom before PCI bus scan?? In-Reply-To: <20080203144443.q9r9b16s00wgk8k0@www.smittys.pointclark.net> References: <20080202203430.1p2at6gtc0skw0so@www.smittys.pointclark.net> <20080203183738.GA4289@coresystems.de> <20080203144443.q9r9b16s00wgk8k0@www.smittys.pointclark.net> Message-ID: <20080203195017.7447.qmail@stuge.se> On Sun, Feb 03, 2008 at 02:44:43PM -0500, joe at smittys.pointclark.net wrote: > Yes, the pci rom currently lives in the bios. It is a three part > rom, Intel boot agent, Intel PXE, and the base code (I think the > base code is the only real part I need??). Intel southbridges support "flash sharing" so that both the system CPU and the NIC can use one and the same flash chip. If there is indeed a blob in the factory BIOS that is required for your NIC to operate, then you'll have to teach coreboot about this flash sharing scheme. At the very least it will require putting the NIC blob at a predefined location in flash, but I doubt it stops there. Since your NIC is onboard and does not work I suppose this is what you're up against. //Peter From tsylla at gmail.com Sun Feb 3 21:29:04 2008 From: tsylla at gmail.com (Tom Sylla) Date: Sun, 03 Feb 2008 15:29:04 -0500 Subject: [coreboot] Run PCI rom before PCI bus scan?? In-Reply-To: <20080203144443.q9r9b16s00wgk8k0@www.smittys.pointclark.net> References: <20080202203430.1p2at6gtc0skw0so@www.smittys.pointclark.net> <20080203183738.GA4289@coresystems.de> <20080203144443.q9r9b16s00wgk8k0@www.smittys.pointclark.net> Message-ID: <47A62410.90805@gmail.com> joe at smittys.pointclark.net wrote: > Here is what I think the PCI rom does with the original bios: > > 1. powers on and enables device > 2. sets up PHY registers > 3. sets up it PCI config registers > 4. and requests use of the PCI bridge > > If I could figure out how to do #1 the rest would be fairly simple to > setup,although I am not exactly sure about PHY registers. Then I > wouldn't need the pci rom at all. I'm not sure it really works this way. A normal platform has some mechanism to set the default values for the LAN config registers. It can be a dedicated SPI ROM, or a dedicated chunk of your boot ROM, or you could program them in your BIOS. I would guess that a PCI ROM is expecting all of those registers to have been programmed already. Furthermore, many of those settings are *platform specific*, so they would not be in any sort of generic PCI ROM that you would get from Intel, or generate using their tools. I recently designed a platform with an 82571 Intel LOM, and I programmed proper values in the SPI, and don't load any PCI ROM at all. It works fine in all OSes. The PCI ROM usually just provides things like PXE or manageability stuff. You need to figure out how your platform is handling this. I think it is unlikely that the PCI expansion ROM is doing what you think it is. From rminnich at gmail.com Sun Feb 3 21:49:38 2008 From: rminnich at gmail.com (ron minnich) Date: Sun, 3 Feb 2008 12:49:38 -0800 Subject: [coreboot] patch: init gx cache earlier. Message-ID: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> This moves the lx cache setup to stage1, not stage 2. Things run a bit faster. Still far too slow, however. ron -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: lxcache.diff Type: text/x-patch Size: 28414 bytes Desc: not available URL: From c-d.hailfinger.devel.2006 at gmx.net Sun Feb 3 21:52:59 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sun, 03 Feb 2008 21:52:59 +0100 Subject: [coreboot] Run PCI rom before PCI bus scan?? In-Reply-To: <20080203115935.i97o0dio00kkk8oc@www.smittys.pointclark.net> References: <20080202203430.1p2at6gtc0skw0so@www.smittys.pointclark.net> <13426df10802021834i5b892084r2e06fa765e4b4d89@mail.gmail.com> <47A5C93A.6090708@gmx.net> <20080203115935.i97o0dio00kkk8oc@www.smittys.pointclark.net> Message-ID: <47A629AB.9050309@gmx.net> On 03.02.2008 17:59, joe at smittys.pointclark.net wrote: > Quoting Carl-Daniel Hailfinger : > > >> On 03.02.2008 03:34, ron minnich wrote: >> >>> On Feb 2, 2008 5:34 PM, wrote: >>> >>> >>>> Hello, >>>> Is there a way to run a PCI rom before the PCI bus scan runs??? >>>> >>>> >>> Yes, we have to do this on any later geode. The LX port should give >>> you a hint on how it's done. >>> >>> >> Sorry, but how are you going to run a ROM before you know where it is >> located? I can see a way to run an image of a PCI ROM before PCI bus >> scan if the image resides in main system flash, but otherwise... >> >> Regards, >> Carl-Daniel >> >> > Ok, let me be more specific. I am pretty sure the pci rom for the > 82562ET nic runs and powers on the onboard ethernet device. The nic > does not have an eeprom. All the device settings are kept in the pci > rom on the bios. OK, so the PCI ROM is located inside the main system flash. IMO we should invent a name for such constellations. Off-card ROM? > After the rom runs it enables it, sets up PHY > registers, sets up it PCI config registers, and requests use of the > PCI bridge. That is why I need it to run before the PCI bus scan. > > Make sense? > Indeed, it does. Regards, Carl-Daniel From rminnich at gmail.com Sun Feb 3 21:57:12 2008 From: rminnich at gmail.com (ron minnich) Date: Sun, 3 Feb 2008 12:57:12 -0800 Subject: [coreboot] Run PCI rom before PCI bus scan?? In-Reply-To: <47A629AB.9050309@gmx.net> References: <20080202203430.1p2at6gtc0skw0so@www.smittys.pointclark.net> <13426df10802021834i5b892084r2e06fa765e4b4d89@mail.gmail.com> <47A5C93A.6090708@gmx.net> <20080203115935.i97o0dio00kkk8oc@www.smittys.pointclark.net> <47A629AB.9050309@gmx.net> Message-ID: <13426df10802031257o39537597v7eef52638259de14@mail.gmail.com> On Feb 3, 2008 12:52 PM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006 at gmx.net> wrote: > > > > OK, so the PCI ROM is located inside the main system flash. IMO we > should invent a name for such constellations. Off-card ROM? > we pretty much named this already for VGA. It is supported in various mainboards, via Config.lb, so we could do something along those lines. I can't find a mainboard example right now. Gee, we have a lot of mainboards now :-) ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From c-d.hailfinger.devel.2006 at gmx.net Sun Feb 3 23:30:44 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sun, 03 Feb 2008 23:30:44 +0100 Subject: [coreboot] Capio II 320 and Coreboot In-Reply-To: References: <13426df10802011059sf8e3f99j25749f957e07af83@mail.gmail.com> <13426df10802011115y47de664fo57fcede4b1f3fd3@mail.gmail.com> <47A4998B.3040900@gmx.net> Message-ID: <47A64094.5080904@gmx.net> On 03.02.2008 05:09, Jeremy Wright wrote: >> http://damnsmalllinux.org/cgi-bin/forums/ikonboard.cgi?act=Print;f=26;t=12165 >> has some interesting info about Damn Small Linux on the Capio II. >> > > Yeah, I've seen that before, but I'm having a hard time finding a TC325. > I'll keep my eyes out for one though. Thanks. > In theory, someone who already has DSL on the Capio II should be able to run some diagnostic tools (flashrom, superiotool, lspci -nnvvvxxx, dmidecode, dmesg). The contents of /proc/iomem, /proc/ioports, /proc/interrupts would also be interesting. Maybe that gives us enough information about memory ranges that should be avoided etc. Regards, Carl-Daniel From joe at smittys.pointclark.net Mon Feb 4 00:15:52 2008 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Sun, 03 Feb 2008 18:15:52 -0500 Subject: [coreboot] Run PCI rom before PCI bus scan?? In-Reply-To: <47A62410.90805@gmail.com> References: <20080202203430.1p2at6gtc0skw0so@www.smittys.pointclark.net> <20080203183738.GA4289@coresystems.de> <20080203144443.q9r9b16s00wgk8k0@www.smittys.pointclark.net> <47A62410.90805@gmail.com> Message-ID: <20080203181552.tybs70ow5c4osoo4@www.smittys.pointclark.net> Quoting Tom Sylla : > joe at smittys.pointclark.net wrote: >> Here is what I think the PCI rom does with the original bios: >> >> 1. powers on and enables device >> 2. sets up PHY registers >> 3. sets up it PCI config registers >> 4. and requests use of the PCI bridge >> >> If I could figure out how to do #1 the rest would be fairly simple >> to setup,although I am not exactly sure about PHY registers. Then >> I wouldn't need the pci rom at all. > > I'm not sure it really works this way. A normal platform has some > mechanism to set the default values for the LAN config registers. It > can be a dedicated SPI ROM, or a dedicated chunk of your boot ROM, or > you could program them in your BIOS. I would guess that a PCI ROM is > expecting all of those registers to have been programmed already. > Furthermore, many of those settings are *platform specific*, so they > would not be in any sort of generic PCI ROM that you would get from > Intel, or generate using their tools. > > I recently designed a platform with an 82571 Intel LOM, and I > programmed proper values in the SPI, and don't load any PCI ROM at all. > It works fine in all OSes. The PCI ROM usually just provides things > like PXE or manageability stuff. > > You need to figure out how your platform is handling this. I think it > is unlikely that the PCI expansion ROM is doing what you think it is. Thanks Tom, This makes alot of sense. All the million pages of documentation I have read, and read they talk about an eeprom (which is the SPI???) and an PCI rom. I guess I am getting the two confused. This board has an Intel 82562ET LOM. How do I access the SPI rom in linux (read/dump/write)? I found this program called eepro100-diag and/or ethtool that is supposed to be able to this but have not tried them yet. Also Intel speaks of an PHY register is that the register that is in the SPI. Thanks for your help. I hope you won't mind helping me on this, seeing you have already done it before? Thanks - Joe From c-d.hailfinger.devel.2006 at gmx.net Mon Feb 4 00:26:38 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 04 Feb 2008 00:26:38 +0100 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> Message-ID: <47A64DAE.7020704@gmx.net> On 03.02.2008 21:49, ron minnich wrote: > This change moves the geodelxinit code from stage2 to stage1, which in > turn gets cache turned on much sooner. The system boots a bit faster. > > We're still far too slow, perhaps because we are not caching ROM? > Have you tried adding a "fillup" file to the lar which occupies the remaing unsused space? That should help a lot. Besides that, having a boot time breakdown to find the worst offenders is an investment into the future. But how should we implement that? Maybe a Kconfig variable which adds TSC timestamps to all printk() calls? While rdtsc() is slow, it is not slow enough to actually show up in profiles if we use it together with printk. > Index: arch/x86/Makefile > Add geodelxinit.o object > Index: arch/x86/geodelx/geodelxinit.c > svn move here from geode northbridge directory and add sizeram function. > Index: arch/x86/geodelx/stage1.c > add called to northbridge_init_early() > Index: northbridge/amd/geodelx/Makefile > remove geodelxinit.o object > Index: northbridge/amd/geodelx/geodelxinit.c > svn move this to arch/x86/geodelx > Index: northbridge/amd/geodelx/geodelx.c > remove call to northbridge_init_early() > > Signed-off-by: Ronald G. Minnich I'm not sure about this patch. It increases stage0/stage1 size and seems to move northbridge init to a generic arch directory. How northbridge specific is geodelxinit.c? Is it a piece of northbridge code? We could link northbridge/amd/geodelx/geodelxinit.c into stage1 even if it is inside the northbridge dir. Regards, Carl-Daniel From rminnich at gmail.com Mon Feb 4 00:32:18 2008 From: rminnich at gmail.com (ron minnich) Date: Sun, 3 Feb 2008 15:32:18 -0800 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <47A64DAE.7020704@gmx.net> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> Message-ID: <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> On Feb 3, 2008 3:26 PM, Carl-Daniel Hailfinger wrote: > Have you tried adding a "fillup" file to the lar which occupies the > remaing unsused space? That should help a lot. That's no longer the big time item. The big time item is now the decompress, which seems to run at 4 kilobytes per second. > > Besides that, having a boot time breakdown to find the worst offenders > is an investment into the future. But how should we implement that? > Maybe a Kconfig variable which adds TSC timestamps to all printk() > calls? While rdtsc() is slow, it is not slow enough to actually show up > in profiles if we use it together with printk. we can just put the option in kconfig. we had this option in v2. > I'm not sure about this patch. It increases stage0/stage1 size and seems > to move northbridge init to a generic arch directory. How northbridge > specific is geodelxinit.c? Is it a piece of northbridge code? We could > link northbridge/amd/geodelx/geodelxinit.c into stage1 even if it is > inside the northbridge dir. The LX does not have the kind of clean breakdown of components we are used to on other systems. I don't think you can say geodelxinit is "northbridge specific" or not. I am happy to move it back to the northbridge directory and just link it in. We've got to run this in stage1 IMHO. We can't wait until stage2 phase 2 to turn on cache. It's just way too slow. ron From corey.osgood at gmail.com Mon Feb 4 02:19:26 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Sun, 3 Feb 2008 20:19:26 -0500 Subject: [coreboot] VIA EPIA CN100000 is finally Working all. In-Reply-To: <1202053744.3231.43.camel@urbez.site> References: <1202053744.3231.43.camel@urbez.site> Message-ID: On Feb 3, 2008 10:49 AM, Urbez Santana Roma wrote: > > Finally works, my mainboard complete, with the IDE +dma, network, usb, > etc... > > I must only add the same that y have commented in my last email, for > working the access of IDE , network, etc. > > Mainboard: VIA EPIA CN10000. > Chipsets: VT8237 and CN700 > Cpu: C7 > Ram: 512MB DDR2 KVR533D2N4 > Linux Kernel: 2.6.22 > > 1. Make a clone of the last posted code for CN700/C7 jetway mainboard of > Corey Osgood, for your mainboard. > > 2. Set to 1 the 20 bit in the function sdram_enable() to all MRS RAM > Commands. If not, the Kingstom > Memory not initiates correctly. > > 3. comment the call to the function disable_sata(), if not, your normal > ide not appears in the PCI config space. Weird. This USED to work, I'm still trying to figure out how I messed it up. 4. Add the follow code to the end of the function main() in auto.c: if > not, your normal IDE cannot use DMA and via-rhine, usb's, etc, not > works. > > //This enable the access of PCI devices to the PCI bus master? > pci_write_config8(cn700->d0f7, 0x57, 0x20);//was 0x01 As Rudolf said, this is supposed to be the address of the last dram bank, IE how much ram the system has. Interestingly enough, although these registers are in the northbridge's config space, they're actually set on the southbridge, through the vlink. That's why some registers have to be set both in d0f3 and d0f7. I'm setting this up now in d0f3 during raminit, so I can just copy it over. 5. If you will that the FILO not confuses scanning PCI, you must add, to > the end of main() in auto.c: > > pci_write_config8(cn700->d1f0,0x19,0x1,CF8);//enable PCI-BRIGDE > SECONDARY BUS > pci_write_config8(cn700->d1f0,0x1a,0x1,CF8); Huh? I think these are already set somewhere, perhaps c7_cpu_setup(). Might not be in the older patch. > 6. If you want that your BIOS, runs at the maximum CPU speed, in my > case, the CPU starts > with 800MHz, and i needed in the bios that works with 1000MHz. You can > add this if u will: > > #define MSR_IA32_PERF_STATUS 0x00000198 > #define MSR_IA32_PERF_CTL 0x00000199 > #define MSR_IA32_MISC_ENABLE 0x000001a0 > > msr_t msr; > print_debug("Enabling C7 Power Save\r\n"); > msr=rdmsr(MSR_IA32_MISC_ENABLE); > if (!(msr.lo & 0x10000)) {msr.lo| > 0x10000;wrmsr(MSR_IA32_MISC_ENABLE,msr); > msr=rdmsr(MSR_IA32_PERF_STATUS); > //TODO: wait CPU not busy bit 16 & 17 off (STATUS) > wrmsr(MSR_IA32_PERF_CTL, 0, (hi&0xff00)| ((hi>>16)&0x00ff)); > //Max multi Factor, and minimum voltage > //TODO: wait CPU transition bit 16 & 17 off (STATUS) OK, I'll add this, thanks! Is this CPU-specific, or does this set any CPU to the max speed? > 7. If you will, you can generate your fadt.c and dsdt.c with the genfadt > and gendsdt tool, or generate one new. > > 8. Force the ACPI in the kernel if not uses it with acpi=force > > 9. If you want that your kernel recognises lapic, you must change the > kernel driver, for not ignore > another Vendors differs of AMD and Intel, in the function "static int > __init detect_init_APIC (void)" of the file ./arch/i386/kernel/apic.c > > End. Thanks, this should be very helpful. I'll take your changes into account, and have a fresh patch sometime soon. Watching the super bowl atm, but I should have some time tomorrow. -Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey.osgood at gmail.com Mon Feb 4 02:20:43 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Sun, 3 Feb 2008 20:20:43 -0500 Subject: [coreboot] VIA EPIA CN100000 is finally Working all. In-Reply-To: <47A60D82.9010300@assembler.cz> References: <1202053744.3231.43.camel@urbez.site> <47A60D82.9010300@assembler.cz> Message-ID: On Feb 3, 2008 1:52 PM, Rudolf Marek wrote: > Hi Urbez, > > > 4. Add the follow code to the end of the function main() in auto.c: if > > not, your normal IDE cannot use DMA and via-rhine, usb's, etc, not > > works. > > > > //This enable the access of PCI devices to the PCI bus master? > > pci_write_config8(cn700->d0f7, 0x57, 0x20);//was 0x01 > > I think this is connected to some last DRAM address stuff. DMA may not > work if > this is incorrect. Consult some similar datasheet > jjj.ivn.pbz.gj!ra!qbjaybnqf!qngnfurrgf!puvcfrgf!QF_PA400_118.mvc > It may be the last bank ending address??? Perhaps this must be copied from > function 3 maybe? Exactly > > > > 5. If you will that the FILO not confuses scanning PCI, you must add, to > > the end of main() in auto.c: > > > > pci_write_config8(cn700->d1f0,0x19,0x1,CF8);//enable PCI-BRIGDE > > SECONDARY BUS > > pci_write_config8(cn700->d1f0,0x1a,0x1,CF8); > > Perhaps is something translating configuration cycles? > > Rudolf Nope, secondary and subordinate bus number. But what's up with the CF8 at the end of these commands? -Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: From c-d.hailfinger.devel.2006 at gmx.net Mon Feb 4 02:32:46 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 04 Feb 2008 02:32:46 +0100 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> Message-ID: <47A66B3E.7020807@gmx.net> On 04.02.2008 00:32, ron minnich wrote: > On Feb 3, 2008 3:26 PM, Carl-Daniel Hailfinger > wrote: > > >> Have you tried adding a "fillup" file to the lar which occupies the >> remaing unsused space? That should help a lot. >> > > That's no longer the big time item. The big time item is now the > decompress, which seems to run > at 4 kilobytes per second. > Ouch. That really hurts. We probably want to add print_conf() from v2/src/mainboard/pcengines/alix1c/mainboard.c to v3. Comparing the v3 output of print_conf to the v2 output may be enlightening. I don't have any Geode LX boards, so I can't really test. >> Besides that, having a boot time breakdown to find the worst offenders >> is an investment into the future. But how should we implement that? >> Maybe a Kconfig variable which adds TSC timestamps to all printk() >> calls? While rdtsc() is slow, it is not slow enough to actually show up >> in profiles if we use it together with printk. >> > > we can just put the option in kconfig. we had this option in v2. > Sorry, I can't find such an option in v2 and the svn log also didn't turn up any hits. Could you point me to a specific file and/or revision? I have a (wrong due to varargs for vtxprintf) prototype patch for v3: Index: lib/console.c =================================================================== --- lib/console.c (Revision 571) +++ lib/console.c (Arbeitskopie) @@ -7,6 +7,8 @@ int vtxprintf(void (*)(unsigned char, void *arg), void *arg, const char *, va_list); +#define rdtscl(low) __asm__ __volatile__ ("rdtsc" : "=a" (low) : : "edx") + static int console_loglevel(void) { return CONFIG_DEFAULT_CONSOLE_LOGLEVEL; @@ -34,11 +36,15 @@ { va_list args; int i; + u32 tstamp; if (msg_level > console_loglevel()) { return 0; } + rdtscl(tstamp); + vtxprintf(console_tx_byte, (void *)0, "[tsc %d] ", tstamp); + va_start(args, fmt); i = vtxprintf(console_tx_byte, (void *)0, fmt, args); va_end(args); >> I'm not sure about this patch. It increases stage0/stage1 size and seems >> to move northbridge init to a generic arch directory. How northbridge >> specific is geodelxinit.c? Is it a piece of northbridge code? We could >> link northbridge/amd/geodelx/geodelxinit.c into stage1 even if it is >> inside the northbridge dir. >> > > The LX does not have the kind of clean breakdown of components we are > used to on other systems. I don't think you can say geodelxinit is > "northbridge specific" or not. I am happy to move it back to the > northbridge directory and just link it in. > Ah yes, the Geode architecture. > We've got to run this in stage1 IMHO. We can't wait until stage2 phase > 2 to turn on cache. It's just way too slow. > Indeed. Without the file move, the patch is fine. Could you post a new version? Thanks, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Mon Feb 4 03:08:22 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 04 Feb 2008 03:08:22 +0100 Subject: [coreboot] [PATCH] v2: factor out print_conf() from Geode LX mainboard dirs Message-ID: <47A67396.1090107@gmx.net> Factor out print_conf() from Geode LX mainboard directories. The following mainboard files had identical Geode LX specific print_conf() implementations: mainboard/amd/db800/mainboard.c mainboard/amd/norwich/mainboard.c mainboard/digitallogic/msm800sev/mainboard.c mainboard/pcengines/alix1c/mainboard.c Move print_conf() to northbridge/amd/lx/northbridge.c where it belongs. mainboard/amd/db800/mainboard.c | 155 -------------------------- mainboard/amd/norwich/mainboard.c | 157 --------------------------- mainboard/digitallogic/msm800sev/mainboard.c | 157 +++------------------------ mainboard/pcengines/alix1c/mainboard.c | 132 ---------------------- northbridge/amd/lx/northbridge.c | 152 +++++++++++++++++++++++++- 5 files changed, 173 insertions(+), 580 deletions(-) Add a copyright notice to mainboard/digitallogic/msm800sev/mainboard.c. Not compile tested because I lack the resources. Signed-off-by: Carl-Daniel Hailfinger -- http://www.hailfinger.org/ Index: LinuxBIOSv2-printconf/src/mainboard/digitallogic/msm800sev/mainboard.c =================================================================== --- LinuxBIOSv2-printconf/src/mainboard/digitallogic/msm800sev/mainboard.c (Revision 3086) +++ LinuxBIOSv2-printconf/src/mainboard/digitallogic/msm800sev/mainboard.c (Arbeitskopie) @@ -1,144 +1,29 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2007 Advanced Micro Devices, Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + #include #include -#include -#include -#include -#include -#include -#include -#include "../../../southbridge/amd/cs5536/cs5536.h" #include "chip.h" -/* Print the platform configuration */ -void print_conf(void) { -#if DEFAULT_CONSOLE_LOGLEVEL >= BIOS_ERR - int i; - unsigned long iol; - msr_t msr; - - int cpu_msr_defs[] = { CPU_BC_L2_CONF, CPU_IM_CONFIG, - CPU_DM_CONFIG0, CPU_RCONF_DEFAULT, - CPU_RCONF_BYPASS, CPU_RCONF_A0_BF, CPU_RCONF_C0_DF, CPU_RCONF_E0_FF, - CPU_RCONF_SMM, CPU_RCONF_DMM, GLCP_DELAY_CONTROLS, GL_END - }; - - int gliu0_msr_defs[] = {MSR_GLIU0_BASE1, MSR_GLIU0_BASE2, MSR_GLIU0_BASE4, MSR_GLIU0_BASE5, MSR_GLIU0_BASE6, - GLIU0_P2D_BMO_0, GLIU0_P2D_BMO_1, MSR_GLIU0_SYSMEM, - GLIU0_P2D_RO_0, GLIU0_P2D_RO_1, GLIU0_P2D_RO_2, MSR_GLIU0_SHADOW, - GLIU0_IOD_BM_0, GLIU0_IOD_BM_1, GLIU0_IOD_BM_2, - GLIU0_IOD_SC_0, GLIU0_IOD_SC_1, GLIU0_IOD_SC_2, GLIU0_IOD_SC_3, GLIU0_IOD_SC_4, GLIU0_IOD_SC_5, - GLIU0_GLD_MSR_COH, GL_END - }; - - int gliu1_msr_defs[] = {MSR_GLIU1_BASE1, MSR_GLIU1_BASE2, MSR_GLIU1_BASE3, MSR_GLIU1_BASE4, MSR_GLIU1_BASE5, MSR_GLIU1_BASE6, - MSR_GLIU1_BASE7, MSR_GLIU1_BASE8, MSR_GLIU1_BASE9, MSR_GLIU1_BASE10, - GLIU1_P2D_R_0, GLIU1_P2D_R_1, GLIU1_P2D_R_2, GLIU1_P2D_R_3, MSR_GLIU1_SHADOW, - GLIU1_IOD_BM_0, GLIU1_IOD_BM_1, GLIU1_IOD_BM_2, - GLIU1_IOD_SC_0, GLIU1_IOD_SC_1, GLIU1_IOD_SC_2, GLIU1_IOD_SC_3, - GLIU1_GLD_MSR_COH, GL_END - }; - - int rconf_msr[] = { CPU_RCONF0, CPU_RCONF1, CPU_RCONF2, CPU_RCONF3, CPU_RCONF4, - CPU_RCONF5, CPU_RCONF6, CPU_RCONF7, GL_END - }; - - int cs5536_msr[] = { MDD_LBAR_GPIO, MDD_LBAR_FLSH0, MDD_LBAR_FLSH1, MDD_LEG_IO, MDD_PIN_OPT, - MDD_IRQM_ZLOW, MDD_IRQM_ZHIGH, MDD_IRQM_PRIM, GL_END - }; - - int pci_msr[] = { GLPCI_CTRL, GLPCI_ARB, GLPCI_REN, GLPCI_A0_BF, GLPCI_C0_DF, GLPCI_E0_FF, - GLPCI_RC0, GLPCI_RC1, GLPCI_RC2, GLPCI_RC3, GLPCI_ExtMSR, GLPCI_SPARE, - GL_END - }; - - int dma_msr[] = { MDD_DMA_MAP, MDD_DMA_SHAD1, MDD_DMA_SHAD2, MDD_DMA_SHAD3, MDD_DMA_SHAD4, - MDD_DMA_SHAD5, MDD_DMA_SHAD6, MDD_DMA_SHAD7, MDD_DMA_SHAD8, - MDD_DMA_SHAD9, GL_END - }; - - - printk_debug("---------- CPU ------------\n"); - - for(i = 0; cpu_msr_defs[i] != GL_END; i++) { - msr = rdmsr(cpu_msr_defs[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", cpu_msr_defs[i], msr.hi, msr.lo); - } - - printk_debug("---------- GLIU 0 ------------\n"); - - for(i = 0; gliu0_msr_defs[i] != GL_END; i++) { - msr = rdmsr(gliu0_msr_defs[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", gliu0_msr_defs[i], msr.hi, msr.lo); - } - - printk_debug("---------- GLIU 1 ------------\n"); - - for(i = 0; gliu1_msr_defs[i] != GL_END; i++) { - msr = rdmsr(gliu1_msr_defs[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", gliu1_msr_defs[i], msr.hi, msr.lo); - } - - printk_debug("---------- RCONF ------------\n"); - - for(i = 0; rconf_msr[i] != GL_END; i++) { - msr = rdmsr(rconf_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", rconf_msr[i], msr.hi, msr.lo); - } - - printk_debug("---------- VARIA ------------\n"); - msr = rdmsr(0x51300010); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", 0x51300010, msr.hi, msr.lo); - - msr = rdmsr(0x51400015); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", 0x51400015, msr.hi, msr.lo); - - printk_debug("---------- DIVIL IRQ ------------\n"); - msr = rdmsr(MDD_IRQM_YLOW); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_YLOW, msr.hi, msr.lo); - msr = rdmsr(MDD_IRQM_YHIGH); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_YHIGH, msr.hi, msr.lo); - msr = rdmsr(MDD_IRQM_ZLOW); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_ZLOW, msr.hi, msr.lo); - msr = rdmsr(MDD_IRQM_ZHIGH); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_ZHIGH, msr.hi, msr.lo); - - - printk_debug("---------- PCI ------------\n"); - - for(i = 0; pci_msr[i] != GL_END; i++) { - msr = rdmsr(pci_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", pci_msr[i], msr.hi, msr.lo); - } - - printk_debug("---------- LPC/UART DMA ------------\n"); - - for(i = 0; dma_msr[i] != GL_END; i++) { - msr = rdmsr(dma_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", dma_msr[i], msr.hi, msr.lo); - } - - printk_debug("---------- CS5536 ------------\n"); - - for(i = 0; cs5536_msr[i] != GL_END; i++) { - msr = rdmsr(cs5536_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", cs5536_msr[i], msr.hi, msr.lo); - } - - iol = inl(GPIOL_INPUT_ENABLE); - printk_debug("IOR 0x%08X is now 0x%08X\n", GPIOL_INPUT_ENABLE, iol); - iol = inl(GPIOL_EVENTS_ENABLE); - printk_debug("IOR 0x%08X is now 0x%08X\n", GPIOL_EVENTS_ENABLE, iol); - iol = inl(GPIOL_INPUT_INVERT_ENABLE); - printk_debug("IOR 0x%08X is now 0x%08X\n", GPIOL_INPUT_INVERT_ENABLE, iol); - iol = inl(GPIO_MAPPER_X); - printk_debug("IOR 0x%08X is now 0x%08X\n", GPIO_MAPPER_X, iol); -#endif //DEFAULT_CONSOLE_LOGLEVEL >= BIOS_ERR -} - -static void init(struct device *dev) { - +static void init(struct device *dev) +{ printk_debug("MSM800SEV ENTER %s\n", __FUNCTION__); - printk_debug("MSM800SEV EXIT %s\n", __FUNCTION__); } Index: LinuxBIOSv2-printconf/src/mainboard/amd/norwich/mainboard.c =================================================================== --- LinuxBIOSv2-printconf/src/mainboard/amd/norwich/mainboard.c (Revision 3086) +++ LinuxBIOSv2-printconf/src/mainboard/amd/norwich/mainboard.c (Arbeitskopie) @@ -19,162 +19,8 @@ #include #include -#include -#include -#include -#include -#include "../../../southbridge/amd/cs5536/cs5536.h" #include "chip.h" -/* Print the platform configuration - do before PCI init or it will not - * work right. - */ -void print_conf(void) -{ -#if DEFAULT_CONSOLE_LOGLEVEL >= BIOS_ERR - int i; - unsigned long iol; - msr_t msr; - - int cpu_msr_defs[] = { CPU_BC_L2_CONF, CPU_IM_CONFIG, CPU_DM_CONFIG0, - CPU_RCONF_DEFAULT, CPU_RCONF_BYPASS, CPU_RCONF_A0_BF, - CPU_RCONF_C0_DF, CPU_RCONF_E0_FF, CPU_RCONF_SMM, CPU_RCONF_DMM, - GLCP_DELAY_CONTROLS, GL_END - }; - - int gliu0_msr_defs[] = { MSR_GLIU0_BASE1, MSR_GLIU0_BASE2, - MSR_GLIU0_BASE4, MSR_GLIU0_BASE5, MSR_GLIU0_BASE6, - GLIU0_P2D_BMO_0, GLIU0_P2D_BMO_1, MSR_GLIU0_SYSMEM, - GLIU0_P2D_RO_0, GLIU0_P2D_RO_1, GLIU0_P2D_RO_2, - MSR_GLIU0_SHADOW, GLIU0_IOD_BM_0, GLIU0_IOD_BM_1, - GLIU0_IOD_BM_2, GLIU0_IOD_SC_0, GLIU0_IOD_SC_1, GLIU0_IOD_SC_2, - GLIU0_IOD_SC_3, GLIU0_IOD_SC_4, GLIU0_IOD_SC_5, - GLIU0_GLD_MSR_COH, GL_END - }; - - int gliu1_msr_defs[] = { MSR_GLIU1_BASE1, MSR_GLIU1_BASE2, - MSR_GLIU1_BASE3, MSR_GLIU1_BASE4, MSR_GLIU1_BASE5, - MSR_GLIU1_BASE6, MSR_GLIU1_BASE7, MSR_GLIU1_BASE8, - MSR_GLIU1_BASE9, MSR_GLIU1_BASE10, GLIU1_P2D_R_0, - GLIU1_P2D_R_1, GLIU1_P2D_R_2, GLIU1_P2D_R_3, MSR_GLIU1_SHADOW, - GLIU1_IOD_BM_0, GLIU1_IOD_BM_1, GLIU1_IOD_BM_2, GLIU1_IOD_SC_0, - GLIU1_IOD_SC_1, GLIU1_IOD_SC_2, GLIU1_IOD_SC_3, - GLIU1_GLD_MSR_COH, GL_END - }; - - int rconf_msr[] = { CPU_RCONF0, CPU_RCONF1, CPU_RCONF2, CPU_RCONF3, - CPU_RCONF4, CPU_RCONF5, CPU_RCONF6, CPU_RCONF7, GL_END - }; - - int cs5536_msr[] = { MDD_LBAR_GPIO, MDD_LBAR_FLSH0, MDD_LBAR_FLSH1, - MDD_LEG_IO, MDD_PIN_OPT, MDD_IRQM_ZLOW, MDD_IRQM_ZHIGH, - MDD_IRQM_PRIM, GL_END - }; - - int pci_msr[] = { GLPCI_CTRL, GLPCI_ARB, GLPCI_REN, GLPCI_A0_BF, - GLPCI_C0_DF, GLPCI_E0_FF, GLPCI_RC0, GLPCI_RC1, GLPCI_RC2, - GLPCI_RC3, GLPCI_ExtMSR, GLPCI_SPARE, GL_END - }; - - int dma_msr[] = { MDD_DMA_MAP, MDD_DMA_SHAD1, MDD_DMA_SHAD2, - MDD_DMA_SHAD3, MDD_DMA_SHAD4, MDD_DMA_SHAD5, MDD_DMA_SHAD6, - MDD_DMA_SHAD7, MDD_DMA_SHAD8, MDD_DMA_SHAD9, GL_END - }; - - printk_debug("---------- CPU ------------\n"); - - for (i = 0; cpu_msr_defs[i] != GL_END; i++) { - msr = rdmsr(cpu_msr_defs[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", - cpu_msr_defs[i], msr.hi, msr.lo); - } - - printk_debug("---------- GLIU 0 ------------\n"); - - for (i = 0; gliu0_msr_defs[i] != GL_END; i++) { - msr = rdmsr(gliu0_msr_defs[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", - gliu0_msr_defs[i], msr.hi, msr.lo); - } - - printk_debug("---------- GLIU 1 ------------\n"); - - for (i = 0; gliu1_msr_defs[i] != GL_END; i++) { - msr = rdmsr(gliu1_msr_defs[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", - gliu1_msr_defs[i], msr.hi, msr.lo); - } - - printk_debug("---------- RCONF ------------\n"); - - for (i = 0; rconf_msr[i] != GL_END; i++) { - msr = rdmsr(rconf_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", rconf_msr[i], - msr.hi, msr.lo); - } - - printk_debug("---------- VARIA ------------\n"); - msr = rdmsr(0x51300010); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", 0x51300010, msr.hi, - msr.lo); - - msr = rdmsr(0x51400015); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", 0x51400015, msr.hi, - msr.lo); - - printk_debug("---------- DIVIL IRQ ------------\n"); - msr = rdmsr(MDD_IRQM_YLOW); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_YLOW, msr.hi, - msr.lo); - msr = rdmsr(MDD_IRQM_YHIGH); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_YHIGH, - msr.hi, msr.lo); - msr = rdmsr(MDD_IRQM_ZLOW); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_ZLOW, msr.hi, - msr.lo); - msr = rdmsr(MDD_IRQM_ZHIGH); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_ZHIGH, - msr.hi, msr.lo); - - printk_debug("---------- PCI ------------\n"); - - for (i = 0; pci_msr[i] != GL_END; i++) { - msr = rdmsr(pci_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", pci_msr[i], - msr.hi, msr.lo); - } - - printk_debug("---------- LPC/UART DMA ------------\n"); - - for (i = 0; dma_msr[i] != GL_END; i++) { - msr = rdmsr(dma_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", dma_msr[i], - msr.hi, msr.lo); - } - - printk_debug("---------- CS5536 ------------\n"); - - for (i = 0; cs5536_msr[i] != GL_END; i++) { - msr = rdmsr(cs5536_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", cs5536_msr[i], - msr.hi, msr.lo); - } - - iol = inl(GPIO_IO_BASE + GPIOL_INPUT_ENABLE); - printk_debug("IOR 0x%08X is now 0x%08X\n", - GPIO_IO_BASE + GPIOL_INPUT_ENABLE, iol); - iol = inl(GPIOL_EVENTS_ENABLE); - printk_debug("IOR 0x%08X is now 0x%08X\n", - GPIO_IO_BASE + GPIOL_EVENTS_ENABLE, iol); - iol = inl(GPIOL_INPUT_INVERT_ENABLE); - printk_debug("IOR 0x%08X is now 0x%08X\n", - GPIO_IO_BASE + GPIOL_INPUT_INVERT_ENABLE, iol); - iol = inl(GPIO_MAPPER_X); - printk_debug("IOR 0x%08X is now 0x%08X\n", GPIO_IO_BASE + GPIO_MAPPER_X, - iol); -#endif //DEFAULT_CONSOLE_LOGLEVEL >= BIOS_ERR -} - static void init(struct device *dev) { printk_debug("Norwich ENTER %s\n", __FUNCTION__); @@ -188,6 +34,5 @@ struct chip_operations mainboard_amd_norwich_ops = { CHIP_NAME("AMD Norwich Mainboard") - .enable_dev = enable_dev, - + .enable_dev = enable_dev, }; Index: LinuxBIOSv2-printconf/src/mainboard/amd/db800/mainboard.c =================================================================== --- LinuxBIOSv2-printconf/src/mainboard/amd/db800/mainboard.c (Revision 3086) +++ LinuxBIOSv2-printconf/src/mainboard/amd/db800/mainboard.c (Arbeitskopie) @@ -19,162 +19,8 @@ #include #include -#include -#include -#include -#include -#include "../../../southbridge/amd/cs5536/cs5536.h" #include "chip.h" -/* Print the platform configuration - do before PCI init or it will not - * work right. - */ -void print_conf(void) -{ -#if DEFAULT_CONSOLE_LOGLEVEL >= BIOS_ERR - int i; - unsigned long iol; - msr_t msr; - - int cpu_msr_defs[] = { CPU_BC_L2_CONF, CPU_IM_CONFIG, CPU_DM_CONFIG0, - CPU_RCONF_DEFAULT, CPU_RCONF_BYPASS, CPU_RCONF_A0_BF, - CPU_RCONF_C0_DF, CPU_RCONF_E0_FF, CPU_RCONF_SMM, CPU_RCONF_DMM, - GLCP_DELAY_CONTROLS, GL_END - }; - - int gliu0_msr_defs[] = { MSR_GLIU0_BASE1, MSR_GLIU0_BASE2, - MSR_GLIU0_BASE4, MSR_GLIU0_BASE5, MSR_GLIU0_BASE6, - GLIU0_P2D_BMO_0, GLIU0_P2D_BMO_1, MSR_GLIU0_SYSMEM, - GLIU0_P2D_RO_0, GLIU0_P2D_RO_1, GLIU0_P2D_RO_2, - MSR_GLIU0_SHADOW, GLIU0_IOD_BM_0, GLIU0_IOD_BM_1, - GLIU0_IOD_BM_2, GLIU0_IOD_SC_0, GLIU0_IOD_SC_1, GLIU0_IOD_SC_2, - GLIU0_IOD_SC_3, GLIU0_IOD_SC_4, GLIU0_IOD_SC_5, - GLIU0_GLD_MSR_COH, GL_END - }; - - int gliu1_msr_defs[] = { MSR_GLIU1_BASE1, MSR_GLIU1_BASE2, - MSR_GLIU1_BASE3, MSR_GLIU1_BASE4, MSR_GLIU1_BASE5, - MSR_GLIU1_BASE6, MSR_GLIU1_BASE7, MSR_GLIU1_BASE8, - MSR_GLIU1_BASE9, MSR_GLIU1_BASE10, GLIU1_P2D_R_0, - GLIU1_P2D_R_1, GLIU1_P2D_R_2, GLIU1_P2D_R_3, MSR_GLIU1_SHADOW, - GLIU1_IOD_BM_0, GLIU1_IOD_BM_1, GLIU1_IOD_BM_2, GLIU1_IOD_SC_0, - GLIU1_IOD_SC_1, GLIU1_IOD_SC_2, GLIU1_IOD_SC_3, - GLIU1_GLD_MSR_COH, GL_END - }; - - int rconf_msr[] = { CPU_RCONF0, CPU_RCONF1, CPU_RCONF2, CPU_RCONF3, - CPU_RCONF4, CPU_RCONF5, CPU_RCONF6, CPU_RCONF7, GL_END - }; - - int cs5536_msr[] = { MDD_LBAR_GPIO, MDD_LBAR_FLSH0, MDD_LBAR_FLSH1, - MDD_LEG_IO, MDD_PIN_OPT, MDD_IRQM_ZLOW, MDD_IRQM_ZHIGH, - MDD_IRQM_PRIM, GL_END - }; - - int pci_msr[] = { GLPCI_CTRL, GLPCI_ARB, GLPCI_REN, GLPCI_A0_BF, - GLPCI_C0_DF, GLPCI_E0_FF, GLPCI_RC0, GLPCI_RC1, GLPCI_RC2, - GLPCI_RC3, GLPCI_ExtMSR, GLPCI_SPARE, GL_END - }; - - int dma_msr[] = { MDD_DMA_MAP, MDD_DMA_SHAD1, MDD_DMA_SHAD2, - MDD_DMA_SHAD3, MDD_DMA_SHAD4, MDD_DMA_SHAD5, MDD_DMA_SHAD6, - MDD_DMA_SHAD7, MDD_DMA_SHAD8, MDD_DMA_SHAD9, GL_END - }; - - printk_debug("---------- CPU ------------\n"); - - for (i = 0; cpu_msr_defs[i] != GL_END; i++) { - msr = rdmsr(cpu_msr_defs[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", - cpu_msr_defs[i], msr.hi, msr.lo); - } - - printk_debug("---------- GLIU 0 ------------\n"); - - for (i = 0; gliu0_msr_defs[i] != GL_END; i++) { - msr = rdmsr(gliu0_msr_defs[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", - gliu0_msr_defs[i], msr.hi, msr.lo); - } - - printk_debug("---------- GLIU 1 ------------\n"); - - for (i = 0; gliu1_msr_defs[i] != GL_END; i++) { - msr = rdmsr(gliu1_msr_defs[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", - gliu1_msr_defs[i], msr.hi, msr.lo); - } - - printk_debug("---------- RCONF ------------\n"); - - for (i = 0; rconf_msr[i] != GL_END; i++) { - msr = rdmsr(rconf_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", rconf_msr[i], - msr.hi, msr.lo); - } - - printk_debug("---------- VARIA ------------\n"); - msr = rdmsr(0x51300010); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", 0x51300010, msr.hi, - msr.lo); - - msr = rdmsr(0x51400015); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", 0x51400015, msr.hi, - msr.lo); - - printk_debug("---------- DIVIL IRQ ------------\n"); - msr = rdmsr(MDD_IRQM_YLOW); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_YLOW, msr.hi, - msr.lo); - msr = rdmsr(MDD_IRQM_YHIGH); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_YHIGH, - msr.hi, msr.lo); - msr = rdmsr(MDD_IRQM_ZLOW); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_ZLOW, msr.hi, - msr.lo); - msr = rdmsr(MDD_IRQM_ZHIGH); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_ZHIGH, - msr.hi, msr.lo); - - printk_debug("---------- PCI ------------\n"); - - for (i = 0; pci_msr[i] != GL_END; i++) { - msr = rdmsr(pci_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", pci_msr[i], - msr.hi, msr.lo); - } - - printk_debug("---------- LPC/UART DMA ------------\n"); - - for (i = 0; dma_msr[i] != GL_END; i++) { - msr = rdmsr(dma_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", dma_msr[i], - msr.hi, msr.lo); - } - - printk_debug("---------- CS5536 ------------\n"); - - for (i = 0; cs5536_msr[i] != GL_END; i++) { - msr = rdmsr(cs5536_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", cs5536_msr[i], - msr.hi, msr.lo); - } - - iol = inl(GPIO_IO_BASE + GPIOL_INPUT_ENABLE); - printk_debug("IOR 0x%08X is now 0x%08X\n", - GPIO_IO_BASE + GPIOL_INPUT_ENABLE, iol); - iol = inl(GPIOL_EVENTS_ENABLE); - printk_debug("IOR 0x%08X is now 0x%08X\n", - GPIO_IO_BASE + GPIOL_EVENTS_ENABLE, iol); - iol = inl(GPIOL_INPUT_INVERT_ENABLE); - printk_debug("IOR 0x%08X is now 0x%08X\n", - GPIO_IO_BASE + GPIOL_INPUT_INVERT_ENABLE, iol); - iol = inl(GPIO_MAPPER_X); - printk_debug("IOR 0x%08X is now 0x%08X\n", GPIO_IO_BASE + GPIO_MAPPER_X, - iol); -#endif //DEFAULT_CONSOLE_LOGLEVEL >= BIOS_ERR -} - static void init(struct device *dev) { printk_debug("AMD DB800 ENTER %s\n", __FUNCTION__); @@ -189,5 +35,4 @@ struct chip_operations mainboard_amd_db800_ops = { CHIP_NAME("AMD DB800 Mainboard") .enable_dev = enable_dev, - }; Index: LinuxBIOSv2-printconf/src/mainboard/pcengines/alix1c/mainboard.c =================================================================== --- LinuxBIOSv2-printconf/src/mainboard/pcengines/alix1c/mainboard.c (Revision 3086) +++ LinuxBIOSv2-printconf/src/mainboard/pcengines/alix1c/mainboard.c (Arbeitskopie) @@ -19,140 +19,8 @@ #include #include -#include -#include -#include -#include -#include -#include "../../../southbridge/amd/cs5536/cs5536.h" #include "chip.h" -/* Print the platform configuration. */ -void print_conf(void) { -#if DEFAULT_CONSOLE_LOGLEVEL >= BIOS_ERR - int i; - unsigned long iol; - msr_t msr; - - int cpu_msr_defs[] = { CPU_BC_L2_CONF, CPU_IM_CONFIG, - CPU_DM_CONFIG0, CPU_RCONF_DEFAULT, - CPU_RCONF_BYPASS, CPU_RCONF_A0_BF, CPU_RCONF_C0_DF, CPU_RCONF_E0_FF, - CPU_RCONF_SMM, CPU_RCONF_DMM, GLCP_DELAY_CONTROLS, GL_END - }; - - int gliu0_msr_defs[] = {MSR_GLIU0_BASE1, MSR_GLIU0_BASE2, MSR_GLIU0_BASE4, MSR_GLIU0_BASE5, MSR_GLIU0_BASE6, - GLIU0_P2D_BMO_0, GLIU0_P2D_BMO_1, MSR_GLIU0_SYSMEM, - GLIU0_P2D_RO_0, GLIU0_P2D_RO_1, GLIU0_P2D_RO_2, MSR_GLIU0_SHADOW, - GLIU0_IOD_BM_0, GLIU0_IOD_BM_1, GLIU0_IOD_BM_2, - GLIU0_IOD_SC_0, GLIU0_IOD_SC_1, GLIU0_IOD_SC_2, GLIU0_IOD_SC_3, GLIU0_IOD_SC_4, GLIU0_IOD_SC_5, - GLIU0_GLD_MSR_COH, GL_END - }; - - int gliu1_msr_defs[] = {MSR_GLIU1_BASE1, MSR_GLIU1_BASE2, MSR_GLIU1_BASE3, MSR_GLIU1_BASE4, MSR_GLIU1_BASE5, MSR_GLIU1_BASE6, - MSR_GLIU1_BASE7, MSR_GLIU1_BASE8, MSR_GLIU1_BASE9, MSR_GLIU1_BASE10, - GLIU1_P2D_R_0, GLIU1_P2D_R_1, GLIU1_P2D_R_2, GLIU1_P2D_R_3, MSR_GLIU1_SHADOW, - GLIU1_IOD_BM_0, GLIU1_IOD_BM_1, GLIU1_IOD_BM_2, - GLIU1_IOD_SC_0, GLIU1_IOD_SC_1, GLIU1_IOD_SC_2, GLIU1_IOD_SC_3, - GLIU1_GLD_MSR_COH, GL_END - }; - - int rconf_msr[] = { CPU_RCONF0, CPU_RCONF1, CPU_RCONF2, CPU_RCONF3, CPU_RCONF4, - CPU_RCONF5, CPU_RCONF6, CPU_RCONF7, GL_END - }; - - int cs5536_msr[] = { MDD_LBAR_GPIO, MDD_LBAR_FLSH0, MDD_LBAR_FLSH1, MDD_LEG_IO, MDD_PIN_OPT, - MDD_IRQM_ZLOW, MDD_IRQM_ZHIGH, MDD_IRQM_PRIM, GL_END - }; - - int pci_msr[] = { GLPCI_CTRL, GLPCI_ARB, GLPCI_REN, GLPCI_A0_BF, GLPCI_C0_DF, GLPCI_E0_FF, - GLPCI_RC0, GLPCI_RC1, GLPCI_RC2, GLPCI_RC3, GLPCI_ExtMSR, GLPCI_SPARE, - GL_END - }; - - int dma_msr[] = { MDD_DMA_MAP, MDD_DMA_SHAD1, MDD_DMA_SHAD2, MDD_DMA_SHAD3, MDD_DMA_SHAD4, - MDD_DMA_SHAD5, MDD_DMA_SHAD6, MDD_DMA_SHAD7, MDD_DMA_SHAD8, - MDD_DMA_SHAD9, GL_END - }; - - - printk_debug("---------- CPU ------------\n"); - - for(i = 0; cpu_msr_defs[i] != GL_END; i++) { - msr = rdmsr(cpu_msr_defs[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", cpu_msr_defs[i], msr.hi, msr.lo); - } - - printk_debug("---------- GLIU 0 ------------\n"); - - for(i = 0; gliu0_msr_defs[i] != GL_END; i++) { - msr = rdmsr(gliu0_msr_defs[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", gliu0_msr_defs[i], msr.hi, msr.lo); - } - - printk_debug("---------- GLIU 1 ------------\n"); - - for(i = 0; gliu1_msr_defs[i] != GL_END; i++) { - msr = rdmsr(gliu1_msr_defs[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", gliu1_msr_defs[i], msr.hi, msr.lo); - } - - printk_debug("---------- RCONF ------------\n"); - - for(i = 0; rconf_msr[i] != GL_END; i++) { - msr = rdmsr(rconf_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", rconf_msr[i], msr.hi, msr.lo); - } - - printk_debug("---------- VARIA ------------\n"); - msr = rdmsr(0x51300010); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", 0x51300010, msr.hi, msr.lo); - - msr = rdmsr(0x51400015); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", 0x51400015, msr.hi, msr.lo); - - printk_debug("---------- DIVIL IRQ ------------\n"); - msr = rdmsr(MDD_IRQM_YLOW); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_YLOW, msr.hi, msr.lo); - msr = rdmsr(MDD_IRQM_YHIGH); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_YHIGH, msr.hi, msr.lo); - msr = rdmsr(MDD_IRQM_ZLOW); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_ZLOW, msr.hi, msr.lo); - msr = rdmsr(MDD_IRQM_ZHIGH); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_ZHIGH, msr.hi, msr.lo); - - - printk_debug("---------- PCI ------------\n"); - - for(i = 0; pci_msr[i] != GL_END; i++) { - msr = rdmsr(pci_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", pci_msr[i], msr.hi, msr.lo); - } - - printk_debug("---------- LPC/UART DMA ------------\n"); - - for(i = 0; dma_msr[i] != GL_END; i++) { - msr = rdmsr(dma_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", dma_msr[i], msr.hi, msr.lo); - } - - printk_debug("---------- CS5536 ------------\n"); - - for(i = 0; cs5536_msr[i] != GL_END; i++) { - msr = rdmsr(cs5536_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", cs5536_msr[i], msr.hi, msr.lo); - } - - iol = inl(GPIOL_INPUT_ENABLE); - printk_debug("IOR 0x%08X is now 0x%08X\n", GPIOL_INPUT_ENABLE, iol); - iol = inl(GPIOL_EVENTS_ENABLE); - printk_debug("IOR 0x%08X is now 0x%08X\n", GPIOL_EVENTS_ENABLE, iol); - iol = inl(GPIOL_INPUT_INVERT_ENABLE); - printk_debug("IOR 0x%08X is now 0x%08X\n", GPIOL_INPUT_INVERT_ENABLE, iol); - iol = inl(GPIO_MAPPER_X); - printk_debug("IOR 0x%08X is now 0x%08X\n", GPIO_MAPPER_X, iol); -#endif //DEFAULT_CONSOLE_LOGLEVEL >= BIOS_ERR -} - static void init(struct device *dev) { printk_debug("ALIX1.C ENTER %s\n", __FUNCTION__); Index: LinuxBIOSv2-printconf/src/northbridge/amd/lx/northbridge.c =================================================================== --- LinuxBIOSv2-printconf/src/northbridge/amd/lx/northbridge.c (Revision 3086) +++ LinuxBIOSv2-printconf/src/northbridge/amd/lx/northbridge.c (Arbeitskopie) @@ -34,7 +34,9 @@ #include #include "chip.h" #include "northbridge.h" +#include "../../../southbridge/amd/cs5536/cs5536.h" + /* here is programming for the various MSRs.*/ #define IM_QWAIT 0x100000 @@ -76,7 +78,6 @@ extern void graphics_init(void); extern void cpubug(void); extern void chipsetinit(void); -extern void print_conf(void); extern uint32_t get_systop(void); void northbridge_init_early(void); @@ -118,6 +119,155 @@ 0} }; +/* Print the platform configuration - do before PCI init or it will not + * work right. + */ +void print_conf(void) +{ +#if DEFAULT_CONSOLE_LOGLEVEL >= BIOS_ERR + int i; + unsigned long iol; + msr_t msr; + + int cpu_msr_defs[] = { CPU_BC_L2_CONF, CPU_IM_CONFIG, CPU_DM_CONFIG0, + CPU_RCONF_DEFAULT, CPU_RCONF_BYPASS, CPU_RCONF_A0_BF, + CPU_RCONF_C0_DF, CPU_RCONF_E0_FF, CPU_RCONF_SMM, CPU_RCONF_DMM, + GLCP_DELAY_CONTROLS, GL_END + }; + + int gliu0_msr_defs[] = { MSR_GLIU0_BASE1, MSR_GLIU0_BASE2, + MSR_GLIU0_BASE4, MSR_GLIU0_BASE5, MSR_GLIU0_BASE6, + GLIU0_P2D_BMO_0, GLIU0_P2D_BMO_1, MSR_GLIU0_SYSMEM, + GLIU0_P2D_RO_0, GLIU0_P2D_RO_1, GLIU0_P2D_RO_2, + MSR_GLIU0_SHADOW, GLIU0_IOD_BM_0, GLIU0_IOD_BM_1, + GLIU0_IOD_BM_2, GLIU0_IOD_SC_0, GLIU0_IOD_SC_1, GLIU0_IOD_SC_2, + GLIU0_IOD_SC_3, GLIU0_IOD_SC_4, GLIU0_IOD_SC_5, + GLIU0_GLD_MSR_COH, GL_END + }; + + int gliu1_msr_defs[] = { MSR_GLIU1_BASE1, MSR_GLIU1_BASE2, + MSR_GLIU1_BASE3, MSR_GLIU1_BASE4, MSR_GLIU1_BASE5, + MSR_GLIU1_BASE6, MSR_GLIU1_BASE7, MSR_GLIU1_BASE8, + MSR_GLIU1_BASE9, MSR_GLIU1_BASE10, GLIU1_P2D_R_0, + GLIU1_P2D_R_1, GLIU1_P2D_R_2, GLIU1_P2D_R_3, MSR_GLIU1_SHADOW, + GLIU1_IOD_BM_0, GLIU1_IOD_BM_1, GLIU1_IOD_BM_2, GLIU1_IOD_SC_0, + GLIU1_IOD_SC_1, GLIU1_IOD_SC_2, GLIU1_IOD_SC_3, + GLIU1_GLD_MSR_COH, GL_END + }; + + int rconf_msr[] = { CPU_RCONF0, CPU_RCONF1, CPU_RCONF2, CPU_RCONF3, + CPU_RCONF4, CPU_RCONF5, CPU_RCONF6, CPU_RCONF7, GL_END + }; + + int cs5536_msr[] = { MDD_LBAR_GPIO, MDD_LBAR_FLSH0, MDD_LBAR_FLSH1, + MDD_LEG_IO, MDD_PIN_OPT, MDD_IRQM_ZLOW, MDD_IRQM_ZHIGH, + MDD_IRQM_PRIM, GL_END + }; + + int pci_msr[] = { GLPCI_CTRL, GLPCI_ARB, GLPCI_REN, GLPCI_A0_BF, + GLPCI_C0_DF, GLPCI_E0_FF, GLPCI_RC0, GLPCI_RC1, GLPCI_RC2, + GLPCI_RC3, GLPCI_ExtMSR, GLPCI_SPARE, GL_END + }; + + int dma_msr[] = { MDD_DMA_MAP, MDD_DMA_SHAD1, MDD_DMA_SHAD2, + MDD_DMA_SHAD3, MDD_DMA_SHAD4, MDD_DMA_SHAD5, MDD_DMA_SHAD6, + MDD_DMA_SHAD7, MDD_DMA_SHAD8, MDD_DMA_SHAD9, GL_END + }; + + printk_debug("---------- CPU ------------\n"); + + for (i = 0; cpu_msr_defs[i] != GL_END; i++) { + msr = rdmsr(cpu_msr_defs[i]); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", + cpu_msr_defs[i], msr.hi, msr.lo); + } + + printk_debug("---------- GLIU 0 ------------\n"); + + for (i = 0; gliu0_msr_defs[i] != GL_END; i++) { + msr = rdmsr(gliu0_msr_defs[i]); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", + gliu0_msr_defs[i], msr.hi, msr.lo); + } + + printk_debug("---------- GLIU 1 ------------\n"); + + for (i = 0; gliu1_msr_defs[i] != GL_END; i++) { + msr = rdmsr(gliu1_msr_defs[i]); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", + gliu1_msr_defs[i], msr.hi, msr.lo); + } + + printk_debug("---------- RCONF ------------\n"); + + for (i = 0; rconf_msr[i] != GL_END; i++) { + msr = rdmsr(rconf_msr[i]); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", rconf_msr[i], + msr.hi, msr.lo); + } + + printk_debug("---------- VARIA ------------\n"); + msr = rdmsr(0x51300010); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", 0x51300010, msr.hi, + msr.lo); + + msr = rdmsr(0x51400015); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", 0x51400015, msr.hi, + msr.lo); + + printk_debug("---------- DIVIL IRQ ------------\n"); + msr = rdmsr(MDD_IRQM_YLOW); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_YLOW, msr.hi, + msr.lo); + msr = rdmsr(MDD_IRQM_YHIGH); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_YHIGH, + msr.hi, msr.lo); + msr = rdmsr(MDD_IRQM_ZLOW); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_ZLOW, msr.hi, + msr.lo); + msr = rdmsr(MDD_IRQM_ZHIGH); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_ZHIGH, + msr.hi, msr.lo); + + printk_debug("---------- PCI ------------\n"); + + for (i = 0; pci_msr[i] != GL_END; i++) { + msr = rdmsr(pci_msr[i]); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", pci_msr[i], + msr.hi, msr.lo); + } + + printk_debug("---------- LPC/UART DMA ------------\n"); + + for (i = 0; dma_msr[i] != GL_END; i++) { + msr = rdmsr(dma_msr[i]); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", dma_msr[i], + msr.hi, msr.lo); + } + + printk_debug("---------- CS5536 ------------\n"); + + for (i = 0; cs5536_msr[i] != GL_END; i++) { + msr = rdmsr(cs5536_msr[i]); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", cs5536_msr[i], + msr.hi, msr.lo); + } + + iol = inl(GPIO_IO_BASE + GPIOL_INPUT_ENABLE); + printk_debug("IOR 0x%08X is now 0x%08X\n", + GPIO_IO_BASE + GPIOL_INPUT_ENABLE, iol); + iol = inl(GPIOL_EVENTS_ENABLE); + printk_debug("IOR 0x%08X is now 0x%08X\n", + GPIO_IO_BASE + GPIOL_EVENTS_ENABLE, iol); + iol = inl(GPIOL_INPUT_INVERT_ENABLE); + printk_debug("IOR 0x%08X is now 0x%08X\n", + GPIO_IO_BASE + GPIOL_INPUT_INVERT_ENABLE, iol); + iol = inl(GPIO_MAPPER_X); + printk_debug("IOR 0x%08X is now 0x%08X\n", GPIO_IO_BASE + GPIO_MAPPER_X, + iol); +#endif //DEFAULT_CONSOLE_LOGLEVEL >= BIOS_ERR +} + /* todo: add a resource record. We don't do this here because this may be called when * very little of the platform is actually working. */ From corey.osgood at gmail.com Mon Feb 4 04:56:24 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Sun, 3 Feb 2008 22:56:24 -0500 Subject: [coreboot] VIA EPIA CN100000 is finally Working all. In-Reply-To: <1202053744.3231.43.camel@urbez.site> References: <1202053744.3231.43.camel@urbez.site> Message-ID: Couple questions: On Feb 3, 2008 10:49 AM, Urbez Santana Roma wrote: > > 6. If you want that your BIOS, runs at the maximum CPU speed, in my > case, the CPU starts > with 800MHz, and i needed in the bios that works with 1000MHz. You can > add this if u will: > > #define MSR_IA32_PERF_STATUS 0x00000198 > #define MSR_IA32_PERF_CTL 0x00000199 > #define MSR_IA32_MISC_ENABLE 0x000001a0 > > msr_t msr; > print_debug("Enabling C7 Power Save\r\n"); > msr=rdmsr(MSR_IA32_MISC_ENABLE); > if (!(msr.lo & 0x10000)) {msr.lo| > 0x10000; msr.lo |= 0x10000? > wrmsr(MSR_IA32_MISC_ENABLE,msr); > msr=rdmsr(MSR_IA32_PERF_STATUS); > //TODO: wait CPU not busy bit 16 & 17 off (STATUS) > wrmsr(MSR_IA32_PERF_CTL, 0, (hi&0xff00)| ((hi>>16)&0x00ff)); > //Max multi Factor, and minimum voltage > //TODO: wait CPU transition bit 16 & 17 off (STATUS) > } I'm about to test out the rest of the changes. Thanks, Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey.osgood at gmail.com Mon Feb 4 04:58:45 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Sun, 3 Feb 2008 22:58:45 -0500 Subject: [coreboot] VIA EPIA CN100000 is finally Working all. In-Reply-To: References: <1202053744.3231.43.camel@urbez.site> Message-ID: On Feb 3, 2008 10:56 PM, Corey Osgood wrote: > Couple questions: > > On Feb 3, 2008 10:49 AM, Urbez Santana Roma > wrote: > > > > > 6. If you want that your BIOS, runs at the maximum CPU speed, in my > > case, the CPU starts > > with 800MHz, and i needed in the bios that works with 1000MHz. You can > > add this if u will: > > > > #define MSR_IA32_PERF_STATUS 0x00000198 > > #define MSR_IA32_PERF_CTL 0x00000199 > > #define MSR_IA32_MISC_ENABLE 0x000001a0 > > > > msr_t msr; > > print_debug("Enabling C7 Power Save\r\n"); > > msr=rdmsr(MSR_IA32_MISC_ENABLE); > > if (!(msr.lo & 0x10000)) {msr.lo| > > 0x10000; > > > msr.lo |= 0x10000? > > > > wrmsr(MSR_IA32_MISC_ENABLE,msr); > > msr=rdmsr(MSR_IA32_PERF_STATUS); > > //TODO: wait CPU not busy bit 16 & 17 off (STATUS) > > wrmsr(MSR_IA32_PERF_CTL, 0, (hi&0xff00)| ((hi>>16)&0x00ff)); > > //Max multi Factor, and minimum voltage > > //TODO: wait CPU transition bit 16 & 17 off (STATUS) > > > > } > Dammit, this was supposed to be: }? Or is the if supposed to end after the first wrmsr? Sorry! -Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Mon Feb 4 06:09:32 2008 From: peter at stuge.se (Peter Stuge) Date: Mon, 4 Feb 2008 06:09:32 +0100 Subject: [coreboot] VIA EPIA CN100000 is finally Working all. In-Reply-To: References: <1202053744.3231.43.camel@urbez.site> Message-ID: <20080204050932.15866.qmail@stuge.se> On Sun, Feb 03, 2008 at 08:19:26PM -0500, Corey Osgood wrote: > Thanks, this should be very helpful. I'll take your changes into > account, and have a fresh patch sometime soon. I'll test on my CN10k board as well when you do. > Watching the super bowl atm Heh, had an eye on it while doing some soldering. What a come-back. //Peter From rminnich at gmail.com Mon Feb 4 06:44:00 2008 From: rminnich at gmail.com (ron minnich) Date: Sun, 3 Feb 2008 21:44:00 -0800 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <47A66B3E.7020807@gmx.net> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> Message-ID: <13426df10802032144s3fb5f14bx2f4d67a698e7e90b@mail.gmail.com> Here is the patch that does not do the move. Thanks ron -------------- next part -------------- A non-text attachment was scrubbed... Name: lxcache.diff Type: text/x-patch Size: 5171 bytes Desc: not available URL: From corey.osgood at gmail.com Mon Feb 4 08:33:48 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Mon, 4 Feb 2008 02:33:48 -0500 Subject: [coreboot] VIA EPIA CN100000 is finally Working all. In-Reply-To: <20080204050932.15866.qmail@stuge.se> References: <1202053744.3231.43.camel@urbez.site> <20080204050932.15866.qmail@stuge.se> Message-ID: Urbez, can you send a patch against svn? Or at least your auto.c and vt8237r_ide.c? I've been trying for the last several hours now, and I can't get FILO to detect my IDE drive, without disabling SATA, so I'm assuming/hoping you've changed something that I've missed. Works fine with SATA disabled though. Thanks! On Feb 4, 2008 12:09 AM, Peter Stuge wrote: > On Sun, Feb 03, 2008 at 08:19:26PM -0500, Corey Osgood wrote: > > Thanks, this should be very helpful. I'll take your changes into > > account, and have a fresh patch sometime soon. > > I'll test on my CN10k board as well when you do. > > > > Watching the super bowl atm > > Heh, had an eye on it while doing some soldering. What a come-back. Ugh, tell me about it. *Is from New England, and a Patriots fan* -Corey > > > //Peter > > -- > coreboot mailing list > coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duwe at lst.de Mon Feb 4 09:56:06 2008 From: duwe at lst.de (Torsten Duwe) Date: Mon, 4 Feb 2008 09:56:06 +0100 Subject: [coreboot] CK804 interrupt steering - SATA fix In-Reply-To: <20080201200113.GB1756@kirkkit.kollasch.net> References: <20080201200113.GB1756@kirkkit.kollasch.net> Message-ID: <200802040956.06360.duwe@lst.de> On Friday 01 February 2008, jakllsch at kollasch.net wrote: > Hi, > > I've reverse engineered some registers in the CK804. I believe with this > information all SATA ports can be enabled without any lost interrupts. Great! > known values of nibbles: > > 0 - unrouted? > 1 - irq 23 > 8 - irq 20 > c - irq 12 > d - irq 21 > e - irq 14 > f - irq 15 These are the IO-APIC "pin numbers", not the interrupt routine taken on the CPU end? Torsten From stepan at coresystems.de Mon Feb 4 10:24:47 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Mon, 04 Feb 2008 10:24:47 +0100 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <47A66B3E.7020807@gmx.net> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> Message-ID: <47A6D9DF.7000500@coresystems.de> Carl-Daniel Hailfinger wrote: > Sorry, I can't find such an option in v2 and the svn log also didn't > turn up any hits. Could you point me to a specific file and/or revision? > I have a (wrong due to varargs for vtxprintf) prototype patch for v3: > > Index: lib/console.c > =================================================================== > --- lib/console.c (Revision 571) > +++ lib/console.c (Arbeitskopie) > @@ -7,6 +7,8 @@ > int vtxprintf(void (*)(unsigned char, void *arg), > void *arg, const char *, va_list); > > +#define rdtscl(low) __asm__ __volatile__ ("rdtsc" : "=a" (low) : : "edx") > + > static int console_loglevel(void) > { > return CONFIG_DEFAULT_CONSOLE_LOGLEVEL; > @@ -34,11 +36,15 @@ > { > va_list args; > int i; > + u32 tstamp; > > if (msg_level > console_loglevel()) { > return 0; > } > > + rdtscl(tstamp); > + vtxprintf(console_tx_byte, (void *)0, "[tsc %d] ", tstamp); > + > va_start(args, fmt); > i = vtxprintf(console_tx_byte, (void *)0, fmt, args); > va_end(args); > > > NACK! x86 Assembler code (that only works on x86 cpus with a TSC) in generic C code is an absolute no-go! If this is supposed to go in at any later time please change it. Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From c-d.hailfinger.devel.2006 at gmx.net Mon Feb 4 10:35:10 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 04 Feb 2008 10:35:10 +0100 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <47A6D9DF.7000500@coresystems.de> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> <47A6D9DF.7000500@coresystems.de> Message-ID: <47A6DC4E.60801@gmx.net> On 04.02.2008 10:24, Stefan Reinauer wrote: > Carl-Daniel Hailfinger wrote: > >> Sorry, I can't find such an option in v2 and the svn log also didn't >> turn up any hits. Could you point me to a specific file and/or revision? >> I have a (wrong due to varargs for vtxprintf) prototype patch for v3: >> >> Index: lib/console.c >> =================================================================== >> --- lib/console.c (Revision 571) >> +++ lib/console.c (Arbeitskopie) >> @@ -7,6 +7,8 @@ >> int vtxprintf(void (*)(unsigned char, void *arg), void >> *arg, const char *, va_list); >> >> +#define rdtscl(low) __asm__ __volatile__ ("rdtsc" : "=a" (low) : : >> "edx") >> + >> static int console_loglevel(void) >> { >> return CONFIG_DEFAULT_CONSOLE_LOGLEVEL; >> @@ -34,11 +36,15 @@ >> { >> va_list args; >> int i; >> + u32 tstamp; >> >> if (msg_level > console_loglevel()) { >> return 0; >> } >> >> + rdtscl(tstamp); >> + vtxprintf(console_tx_byte, (void *)0, "[tsc %d] ", tstamp); >> + >> va_start(args, fmt); >> i = vtxprintf(console_tx_byte, (void *)0, fmt, args); >> va_end(args); >> > > NACK! x86 Assembler code (that only works on x86 cpus with a TSC) in > generic C code is an absolute no-go! If this is supposed to go in at > any later time please change it. Fully agreed. This was just a debugging hack. I'd love to do this in a generic way. Do you know where/when/whether we had printk timestamps in v2? Regards, Carl-Daniel From jeff_th at sympatico.ca Mon Feb 4 07:07:41 2008 From: jeff_th at sympatico.ca (Jeffrey Thompson) Date: Mon, 4 Feb 2008 01:07:41 -0500 Subject: [coreboot] igel-132 xm smart Message-ID: <6bpm1d$59cfrb@toip4.srvr.bell.ca> Hi All, New to this and hope someone can direct me. I have acquired a few "igel-132 xm smart" thin clients that have admin passwords and are not able to be reset to default configs. I am hoping I can somehow get linux on these units and have no support from Igel. I did notice a couple posts for Igel thin clients but I don't see how to do any hardware mods if they are required. Thanks for you patience and looking forward to any assistance. JT -------------- next part -------------- An HTML attachment was scrubbed... URL: From c-d.hailfinger.devel.2006 at gmx.net Mon Feb 4 10:48:41 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 04 Feb 2008 10:48:41 +0100 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <13426df10802032144s3fb5f14bx2f4d67a698e7e90b@mail.gmail.com> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> <13426df10802032144s3fb5f14bx2f4d67a698e7e90b@mail.gmail.com> Message-ID: <47A6DF79.1040108@gmx.net> Hi Ron, I really like it. One minor typo in arch/x86/Makefile, rest looks very good. Regards, Carl-Daniel On 04.02.2008 06:44, ron minnich wrote: > This change moves the geodelxinit code from stage2 to stage1, which in > turn gets cache turned on much sooner. The system boots a bit faster. > > We're still far too slow, perhaps because we are not caching ROM? > > Index: arch/x86/Makefile > Add ../../northbridge/amd/geodelx/geodelxinit.o object > Index: arch/x86/geodelx/geodelxinit.c > add sizeram function. > Index: arch/x86/geodelx/stage1.c > add called to northbridge_init_early() > Index: northbridge/amd/geodelx/Makefile > remove geodelxinit.o object > remove sizeram function. > Index: northbridge/amd/geodelx/geodelx.c > remove call to northbridge_init_early() Compile tested, no new warnings, no new errors. Acked-by: Carl-Daniel Hailfinger > Index: northbridge/amd/geodelx/geodelx.c > =================================================================== > --- northbridge/amd/geodelx/geodelx.c (revision 571) > +++ northbridge/amd/geodelx/geodelx.c (working copy) > @@ -142,49 +142,6 @@ > }; > > /** > - * Size up ram. > - * > - * All we need to do here is read the MSR for DRAM and grab out the sizing > - * bits. Note that this code depends on initram having run. It uses the MSRs, > - * not the SPDs, and the MSRs of course are set up by initram. > - * > - * @return TODO > - */ > -int sizeram(void) > -{ > - struct msr msr; > - int sizem = 0; > - u32 dimm; > - > - /* Get the RAM size from the memory controller as calculated > - * and set by auto_size_dimm(). > - */ > - msr = rdmsr(MC_CF07_DATA); > - printk(BIOS_DEBUG, "sizeram: _MSR MC_CF07_DATA: %08x:%08x\n", msr.hi, > - msr.lo); > - > - /* DIMM 0 */ > - dimm = msr.hi; > - /* Installed? */ > - if ((dimm & 7) != 7) { > - /* 1:8MB, 2:16MB, 3:32MB, 4:64MB, ... 7:512MB, 8:1GB */ > - sizem = 4 << ((dimm >> 12) & 0x0F); > - } > - > - /* DIMM 1 */ > - dimm = msr.hi >> 16; > - /* Installed? */ > - if ((dimm & 7) != 7) { > - /* 1:8MB, 2:16MB, 3:32MB, 4:64MB, ... 7:512MB, 8:1GB */ > - sizem += 4 << ((dimm >> 12) & 0x0F); > - } > - > - printk(BIOS_DEBUG, "sizeram: sizem 0x%xMB\n", sizem); > - > - return sizem; > -} > - > -/** > * Currently not set up. > * > * @param dev The nortbridge device. > @@ -317,7 +274,7 @@ > > printk(BIOS_SPEW, ">> Entering northbridge.c: %s\n", __FUNCTION__); > > - northbridge_init_early(); > +// northbridge_init_early(); > chipsetinit(); > > setup_realmode_idt(); > Index: northbridge/amd/geodelx/geodelxinit.c > =================================================================== > --- northbridge/amd/geodelx/geodelxinit.c (revision 571) > +++ northbridge/amd/geodelx/geodelxinit.c (working copy) > @@ -25,7 +25,6 @@ > #include > > /* Function prototypes */ > -extern int sizeram(void); > > struct gliutable { > unsigned long desc_name; > @@ -142,6 +141,49 @@ > } > > /** > + * Size up ram. > + * > + * All we need to do here is read the MSR for DRAM and grab out the sizing > + * bits. Note that this code depends on initram having run. It uses the MSRs, > + * not the SPDs, and the MSRs of course are set up by initram. > + * > + * @return TODO > + */ > +int sizeram(void) > +{ > + struct msr msr; > + int sizem = 0; > + u32 dimm; > + > + /* Get the RAM size from the memory controller as calculated > + * and set by auto_size_dimm(). > + */ > + msr = rdmsr(MC_CF07_DATA); > + printk(BIOS_DEBUG, "sizeram: _MSR MC_CF07_DATA: %08x:%08x\n", msr.hi, > + msr.lo); > + > + /* DIMM 0 */ > + dimm = msr.hi; > + /* Installed? */ > + if ((dimm & 7) != 7) { > + /* 1:8MB, 2:16MB, 3:32MB, 4:64MB, ... 7:512MB, 8:1GB */ > + sizem = 4 << ((dimm >> 12) & 0x0F); > + } > + > + /* DIMM 1 */ > + dimm = msr.hi >> 16; > + /* Installed? */ > + if ((dimm & 7) != 7) { > + /* 1:8MB, 2:16MB, 3:32MB, 4:64MB, ... 7:512MB, 8:1GB */ > + sizem += 4 << ((dimm >> 12) & 0x0F); > + } > + > + printk(BIOS_DEBUG, "sizeram: sizem 0x%xMB\n", sizem); > + > + return sizem; > +} > + > +/** > * Set up the system memory registers, i.e. memory that can be used > * for non-VSM (or SMM) purposes. > * > Index: northbridge/amd/geodelx/Makefile > =================================================================== > --- northbridge/amd/geodelx/Makefile (revision 571) > +++ northbridge/amd/geodelx/Makefile (working copy) > @@ -22,7 +22,6 @@ > ifeq ($(CONFIG_NORTHBRIDGE_AMD_GEODELX),y) > > STAGE2_CHIPSET_OBJ += $(obj)/northbridge/amd/geodelx/geodelx.o \ > - $(obj)/northbridge/amd/geodelx/geodelxinit.o \ > $(obj)/northbridge/amd/geodelx/vsmsetup.o > > endif > Index: arch/x86/geodelx/stage1.c > =================================================================== > --- arch/x86/geodelx/stage1.c (revision 571) > +++ arch/x86/geodelx/stage1.c (working copy) > @@ -55,6 +55,7 @@ > */ > void disable_car(void) > { > + extern void northbridge_init_early(void); > int i; > > for (i = 0; i < ARRAY_SIZE(msr_table); i++) > @@ -67,5 +68,6 @@ > __asm__ __volatile__("cld; rep movsl" ::"D" (DCACHE_RAM_BASE), "S" (DCACHE_RAM_BASE), "c" (DCACHE_RAM_SIZE/4): "memory"); > __asm__ __volatile__ ("wbinvd\n"); > banner(BIOS_DEBUG, "Disable_car: done wbinvd"); > + northbridge_init_early(); > banner(BIOS_DEBUG, "disable_car: done"); > } > Index: arch/x86/Makefile > =================================================================== > --- arch/x86/Makefile (revision 571) > +++ arch/x86/Makefile (working copy) > @@ -117,6 +117,7 @@ > ifeq ($(CONFIG_CPU_AMD_GEODELX),y) > STAGE0_CAR_OBJ = geodelx/stage0.o > STAGE0_ARCH_X86_OBJ += geodelx/stage1.o > + STAGE0_ARCH_X86_OBJ += ../..//northbridge/amd/geodelx/geodelxinit.o > Shouldn't this have only one slash before northbridge, like this: + STAGE0_ARCH_X86_OBJ += ../../northbridge/amd/geodelx/geodelxinit.o > else > STAGE0_CAR_OBJ = stage0_i586.o > endif > From r.marek at assembler.cz Mon Feb 4 11:25:33 2008 From: r.marek at assembler.cz (Rudolf Marek) Date: Mon, 04 Feb 2008 11:25:33 +0100 Subject: [coreboot] VIA EPIA CN100000 is finally Working all. In-Reply-To: References: <1202053744.3231.43.camel@urbez.site> <20080204050932.15866.qmail@stuge.se> Message-ID: <47A6E81D.8060005@assembler.cz> Corey Osgood wrote: > Urbez, can you send a patch against svn? Or at least your auto.c and > vt8237r_ide.c? I've been trying for the last several hours now, and I > can't get FILO to detect my IDE drive, without disabling SATA, so I'm > assuming/hoping you've changed something that I've missed. Works fine > with SATA disabled though. Thanks! Yep this needs to be documented. If you have SATA ports and 2xIDE FILO thinks like this: hda - SATA0 hdb - dummySATA0 hdc - SATA1 hdd - dummySATA1 hde - PriMaster IDE hdf - PriSlave IDE hdg - SecMaster IDE hdh - SecSlave IDE Rudolf From vn.lalitha at gmail.com Mon Feb 4 11:36:44 2008 From: vn.lalitha at gmail.com (Lalitha V.N.) Date: Mon, 4 Feb 2008 16:06:44 +0530 Subject: [coreboot] Flashing problem on the SST49LF004B Message-ID: Hello all ............ we are working on the coreboot project ..... Initially we are copied the BIOS(PM49FL004) content that is present in the motherboard( ASRock K8Upgrade-VM800) in a file name called jan-14 and tried to flash(write) the content in the filename jan-14 on to a new flashrom SST49LF004B.. but flash is not happened properly .. these are the steps we followed ... [root at turtle9 flashrom]# flashrom Calibrating delay loop... OK. No LinuxBIOS table found. Found chipset "VT8237", enabling flash write... OK. generic_spi_command called, but no SPI chipset detected Pm49FL004 found at physical address 0xfff80000. Flash part is Pm49FL004 (512 KB). No operations were specified. *Reading the original Bios content in to the file jan14:* [root at turtle9 flashrom]# flashrom -r jan14 Calibrating delay loop... OK. No LinuxBIOS table found. Found chipset "VT8237", enabling flash write... OK. generic_spi_command called, but no SPI chipset detected Pm49FL004 found at physical address 0xfff80000. Flash part is Pm49FL004 (512 KB). Reading Flash...done [root at turtle9 flashrom]# flashrom -v jan14 Calibrating delay loop... OK. No LinuxBIOS table found. Found chipset "VT8237", enabling flash write... OK. generic_spi_command called, but no SPI chipset detected Pm49FL004 found at physical address 0xfff80000. Flash part is Pm49FL004 (512 KB). Flash image seems to be a legacy BIOS. Disabling checks. Verifying flash... VERIFIED. ***Then we removed the original Bios chip and inserted the new flashrom SST49LF004B and tried to flash(write) the content present in the filename jan14 ,but finally we got the result as bellow ........ *Writing on to the new Bios chip (SST49LF004B):* [root at turtle9 flashrom]# flashrom -w jan14 Calibrating delay loop... OK. No LinuxBIOS table found. Found chipset "VT8237", enabling flash write... OK. generic_spi_command called, but no SPI chipset detected SST49LF004A/B found at physical address 0xfff80000. Flash part is SST49LF004A/B (512 KB). Flash image seems to be a legacy BIOS. Disabling checks. Programming page: 0007 at address: 0x00070000 *Then we varified .....* [root at turtle9 flashrom]# flashrom -v jan14 Calibrating delay loop... okNo LinuxBIOS table found.Found chipset "VT8237": Enabling flash write... OK.SST49LF004A/B found at physical address: 0xfff80000Flash part is SST49LF004A/B (512 KB)Flash image seems to be a legacy BIOS. Disabling checks.Verifying flash - FAILED So we tried to change the flashrom utility code..so first we downloaded coreboot code from the coreboot.org then in that we tried to change the code in util/flashrom file but stil we are unable to get the way where we need to change the code such that the flash can happen ... we are also gone through the datasheet of SST49LF004B and PM49FL004 but we are not getting any exact idea ....... please guide us............... with regards, lalitha -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.marek at assembler.cz Mon Feb 4 11:42:28 2008 From: r.marek at assembler.cz (Rudolf Marek) Date: Mon, 04 Feb 2008 11:42:28 +0100 Subject: [coreboot] goal for march summit In-Reply-To: <47A5C6BE.8070400@gmx.net> References: <13426df10802012049t54d8f799p7b0c7b99f315583@mail.gmail.com> <47A43EA8.1080702@assembler.cz> <47A4651A.6030603@gmx.net> <47A46DEB.1060709@assembler.cz> <47A5C6BE.8070400@gmx.net> Message-ID: <47A6EC14.7090608@assembler.cz> Ok, I got some response from VIA that K8T890CF is quite similar. As I said. There are some changes. Question is what to ask now, because the M2V seems to be not available. Go for K8M890/VT8237A? I have following plan. Someone from Coreboot community will also get NDA plus me. I think I'm able to answer most of the questions so I will act as some kind of filter and we shell ask VIA only in trouble. Lets agree on the chipset first. Rudolf From joe at smittys.pointclark.net Mon Feb 4 13:49:36 2008 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Mon, 04 Feb 2008 07:49:36 -0500 Subject: [coreboot] Run PCI rom before PCI bus scan?? In-Reply-To: <20080203181552.tybs70ow5c4osoo4@www.smittys.pointclark.net> References: <20080202203430.1p2at6gtc0skw0so@www.smittys.pointclark.net> <20080203183738.GA4289@coresystems.de> <20080203144443.q9r9b16s00wgk8k0@www.smittys.pointclark.net> <47A62410.90805@gmail.com> <20080203181552.tybs70ow5c4osoo4@www.smittys.pointclark.net> Message-ID: <20080204074936.4q1bevm7ksggowsk@www.smittys.pointclark.net> Hello, I would like to report that with ethtool under the original bios I am able to dump the 82562ET eeprom registers: 0010 957a d175 1a03 0000 0201 4701 0000 0000 0000 49b2 0000 8086 007f 0000 0000 8080 8080 7a7a 7a7a bd90 60b3 0000 7454 8bab 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1039 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0128 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 4030 0000 0000 0000 c731 According to the datasheet: http://download.intel.com/design/network/applnots/ap409.pdf There are a few registers out of the norm. I am going to re-program them back to their defaults and try coreboot again?? One major difference I noticed is Linux is detecting the device id of 103Ah and the eeprom has a device id of 1039h (this value should be correct). Could the incorrect device id cause the PCI bridge scan not to detect the device? Thanks - Joe From urbez at linuxupc.upc.edu Mon Feb 4 14:08:50 2008 From: urbez at linuxupc.upc.edu (urbez at linuxupc.upc.edu) Date: Mon, 04 Feb 2008 14:08:50 +0100 Subject: [coreboot] VIA EPIA CN100000 is finally Working all. In-Reply-To: References: <1202053744.3231.43.camel@urbez.site> Message-ID: <20080204140850.kdeceau3frk88kcs@linuxupc.upc.es> Sorry :))) i have read this and yes, after the wrmsr, must have a } problem with cut and paste to the email , the 80 character console :) if (!(msr.lo & 0x10000)) {msr.lo|=0x10000;wrmsr(MSR_IA32_MISC_ENABLE,msr);} And it works with C7 cpu, and uses the minimum voltage that accepts your CPU and the maximum Speed Multiplier of your CPU. I'm not sure if works on another CPU. Mmm, i must download the last svn, for compare with that i have, with a diff. Is different the auto.c, that i use, i cray for fit into the ROM_SIZE. Initially i have working with a separate v8237 driver copied from another via , but, finally, if i remember i use the entire v8237r version of Rudolf Marek. I confirm that, when i can generate the pach for epia-cn, i'm at work :) The CF8, is a missed parameter that i use in another program. I use normally another PCI routines, i not remember why. I cray, for pass the size as a parameter, better, if you use tables. Ignore the CF8, and cut it :) It is possible that your mainboard, starts with diferent parameters in the bridge that not afect mine? But wait for the DIFF results with the last version of SVN, to confirm if are more easy the problem, and i can have forgotten extra changes. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From c-d.hailfinger.devel.2006 at gmx.net Mon Feb 4 14:37:26 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 04 Feb 2008 14:37:26 +0100 Subject: [coreboot] goal for march summit In-Reply-To: <47A6EC14.7090608@assembler.cz> References: <13426df10802012049t54d8f799p7b0c7b99f315583@mail.gmail.com> <47A43EA8.1080702@assembler.cz> <47A4651A.6030603@gmx.net> <47A46DEB.1060709@assembler.cz> <47A5C6BE.8070400@gmx.net> <47A6EC14.7090608@assembler.cz> Message-ID: <47A71516.3060400@gmx.net> On 04.02.2008 11:42, Rudolf Marek wrote: > Ok, > > I got some response from VIA that K8T890CF is quite similar. As I said. There > are some changes. Question is what to ask now, because the M2V seems to be not > available. > > Go for K8M890/VT8237A? > I'm all for it K8M890, but do we want to target VT8237Rplus (M2V-TVM), VT8237A (M2V-MX) or VT8237S(M2V-MX SE)? Unfortunately, the only comparison between these southbridges is http://de.wikipedia.org/wiki/VIA_Southbridges > I have following plan. Someone from Coreboot community will also get NDA plus > Maybe Stefan can get such a NDA? > me. I think I'm able to answer most of the questions so I will act as some kind > of filter and we shell ask VIA only in trouble. > Good idea. > Lets agree on the chipset first. > Yes. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Mon Feb 4 14:52:05 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 04 Feb 2008 14:52:05 +0100 Subject: [coreboot] v3 challenge: global variables Message-ID: <47A71885.1070803@gmx.net> Hi, I have a really tough challenge for you: I need a global variable in v3. Global means that it has to be accessible from all of stage1/stage2 code (maybe except initram). So far I only see one unacceptably hackish solution: Pass a pointer to the global variable to every function in the codebase. It works, but I'd rather not post a patch doing this because it violates my aesthetic sense, especially because the variable is used in only very few functions, however those are called all over the place. A possible alternative would be a getter/setter function for the variable. I have no problem with that, but the getter/setter function has to store the location of the variable somewhere, and that can't be solved except through pointer passing like above. There must be a solution out there, I just can't see it. Regards, Carl-Daniel From peter at stuge.se Mon Feb 4 16:23:32 2008 From: peter at stuge.se (Peter Stuge) Date: Mon, 4 Feb 2008 16:23:32 +0100 Subject: [coreboot] Flashing problem on the SST49LF004B In-Reply-To: References: Message-ID: <20080204152332.10586.qmail@stuge.se> On Mon, Feb 04, 2008 at 04:06:44PM +0530, Lalitha V.N. wrote: > in a file name called jan-14 and tried to flash(write) the content > in the filename jan-14 on to a new flashrom SST49LF004B.. This should work. > ***Then we removed the original Bios chip and inserted the new > flashrom SST49LF004B and tried to flash(write) > > [root at turtle9 flashrom]# flashrom -w jan14 flashrom -w does not automatically erase the flash chip before writing. I find this very unintuitive, but it is the way it currently works. Please try running flashrom -E on the SST chip first, and then run flashrom -w and finally flashrom -v to verify. Please let us know if that works or not. Thanks! //Peter From peter at stuge.se Mon Feb 4 16:28:32 2008 From: peter at stuge.se (Peter Stuge) Date: Mon, 4 Feb 2008 16:28:32 +0100 Subject: [coreboot] v3 challenge: global variables In-Reply-To: <47A71885.1070803@gmx.net> References: <47A71885.1070803@gmx.net> Message-ID: <20080204152832.12294.qmail@stuge.se> On Mon, Feb 04, 2008 at 02:52:05PM +0100, Carl-Daniel Hailfinger wrote: > I have a really tough challenge for you: I need a global variable > in v3. Why? //Peter From rminnich at gmail.com Mon Feb 4 16:43:07 2008 From: rminnich at gmail.com (ron minnich) Date: Mon, 4 Feb 2008 07:43:07 -0800 Subject: [coreboot] Run PCI rom before PCI bus scan?? In-Reply-To: <20080204074936.4q1bevm7ksggowsk@www.smittys.pointclark.net> References: <20080202203430.1p2at6gtc0skw0so@www.smittys.pointclark.net> <20080203183738.GA4289@coresystems.de> <20080203144443.q9r9b16s00wgk8k0@www.smittys.pointclark.net> <47A62410.90805@gmail.com> <20080203181552.tybs70ow5c4osoo4@www.smittys.pointclark.net> <20080204074936.4q1bevm7ksggowsk@www.smittys.pointclark.net> Message-ID: <13426df10802040743h7979ca0dr3e79c85de6b1a234@mail.gmail.com> On Feb 4, 2008 4:49 AM, wrote: > Could the incorrect device id cause the PCI bridge scan not to detect > the device? That's very unlikely. ron From rminnich at gmail.com Mon Feb 4 16:45:13 2008 From: rminnich at gmail.com (ron minnich) Date: Mon, 4 Feb 2008 07:45:13 -0800 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <47A6D9DF.7000500@coresystems.de> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> <47A6D9DF.7000500@coresystems.de> Message-ID: <13426df10802040745x4921ca9ev4662339f1bf8ff27@mail.gmail.com> we can provide a function, cycles, in the arch-dependent code. cycles returns whatever makes sense for the architecture. Then this patch can be cleaned up. thanks ron From c-d.hailfinger.devel.2006 at gmx.net Mon Feb 4 16:52:56 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 04 Feb 2008 16:52:56 +0100 Subject: [coreboot] v3 challenge: global variables In-Reply-To: <20080204152832.12294.qmail@stuge.se> References: <47A71885.1070803@gmx.net> <20080204152832.12294.qmail@stuge.se> Message-ID: <47A734D8.4010504@gmx.net> On 04.02.2008 16:28, Peter Stuge wrote: > On Mon, Feb 04, 2008 at 02:52:05PM +0100, Carl-Daniel Hailfinger wrote: > >> I have a really tough challenge for you: I need a global variable >> in v3. >> > > Why? > It's a pointer to the printk log buffer. That way, we have printk as soon as we enter stage 1, even before the Super I/O is initialized. As an added benefit, we can make the coreboot log available to payloads. Regards, Carl-Daniel From ward at gnu.org Mon Feb 4 17:00:19 2008 From: ward at gnu.org (Ward Vandewege) Date: Mon, 4 Feb 2008 11:00:19 -0500 Subject: [coreboot] v3 challenge: global variables In-Reply-To: <47A734D8.4010504@gmx.net> References: <47A71885.1070803@gmx.net> <20080204152832.12294.qmail@stuge.se> <47A734D8.4010504@gmx.net> Message-ID: <20080204160019.GA10338@localdomain> On Mon, Feb 04, 2008 at 04:52:56PM +0100, Carl-Daniel Hailfinger wrote: > On 04.02.2008 16:28, Peter Stuge wrote: > > On Mon, Feb 04, 2008 at 02:52:05PM +0100, Carl-Daniel Hailfinger wrote: > > > >> I have a really tough challenge for you: I need a global variable > >> in v3. > >> > > > > Why? > > > > It's a pointer to the printk log buffer. That way, we have printk as > soon as we enter stage 1, even before the Super I/O is initialized. As > an added benefit, we can make the coreboot log available to payloads. That would be awesome. I'd love to see it show up in dmesg... Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From rminnich at gmail.com Mon Feb 4 17:12:46 2008 From: rminnich at gmail.com (ron minnich) Date: Mon, 4 Feb 2008 08:12:46 -0800 Subject: [coreboot] v3 challenge: global variables In-Reply-To: <47A734D8.4010504@gmx.net> References: <47A71885.1070803@gmx.net> <20080204152832.12294.qmail@stuge.se> <47A734D8.4010504@gmx.net> Message-ID: <13426df10802040812o639f6a12j76f280500b3ef60a@mail.gmail.com> So, this is an example of the reason for the (void *) param I was suggesting some time back. Such needs come up. One option is to have a convention that globals are at the base of the stack, rounded to 64k. e.g. %esp & 0xffff0000 is where globals live. ron From svn at coreboot.org Mon Feb 4 17:16:16 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Mon, 4 Feb 2008 17:16:16 +0100 Subject: [coreboot] r572 - in coreboot-v3: arch/x86 arch/x86/geodelx northbridge/amd/geodelx Message-ID: Author: rminnich Date: 2008-02-04 17:16:16 +0100 (Mon, 04 Feb 2008) New Revision: 572 Modified: coreboot-v3/arch/x86/Makefile coreboot-v3/arch/x86/geodelx/stage1.c coreboot-v3/northbridge/amd/geodelx/Makefile coreboot-v3/northbridge/amd/geodelx/geodelx.c coreboot-v3/northbridge/amd/geodelx/geodelxinit.c Log: This change moves the geodelxinit code from stage2 to stage1, which in turn gets cache turned on much sooner. The system boots a bit faster. We're still far too slow, perhaps because we are not caching ROM? Index: arch/x86/Makefile Add ../../northbridge/amd/geodelx/geodelxinit.o object Index: arch/x86/geodelx/geodelxinit.c add sizeram function. Index: arch/x86/geodelx/stage1.c add called to northbridge_init_early() Index: northbridge/amd/geodelx/Makefile remove geodelxinit.o object Index: northbridge/amd/geodelx/geodelx.c remove call to northbridge_init_early() remove sizeram function. Signed-off-by: Ronald G. Minnich Acked-by: Carl-Daniel Hailfinger Modified: coreboot-v3/arch/x86/Makefile =================================================================== --- coreboot-v3/arch/x86/Makefile 2008-02-01 20:35:53 UTC (rev 571) +++ coreboot-v3/arch/x86/Makefile 2008-02-04 16:16:16 UTC (rev 572) @@ -117,6 +117,7 @@ ifeq ($(CONFIG_CPU_AMD_GEODELX),y) STAGE0_CAR_OBJ = geodelx/stage0.o STAGE0_ARCH_X86_OBJ += geodelx/stage1.o + STAGE0_ARCH_X86_OBJ += ../../northbridge/amd/geodelx/geodelxinit.o else STAGE0_CAR_OBJ = stage0_i586.o endif Modified: coreboot-v3/arch/x86/geodelx/stage1.c =================================================================== --- coreboot-v3/arch/x86/geodelx/stage1.c 2008-02-01 20:35:53 UTC (rev 571) +++ coreboot-v3/arch/x86/geodelx/stage1.c 2008-02-04 16:16:16 UTC (rev 572) @@ -55,6 +55,7 @@ */ void disable_car(void) { + extern void northbridge_init_early(void); int i; for (i = 0; i < ARRAY_SIZE(msr_table); i++) @@ -67,5 +68,6 @@ __asm__ __volatile__("cld; rep movsl" ::"D" (DCACHE_RAM_BASE), "S" (DCACHE_RAM_BASE), "c" (DCACHE_RAM_SIZE/4): "memory"); __asm__ __volatile__ ("wbinvd\n"); banner(BIOS_DEBUG, "Disable_car: done wbinvd"); + northbridge_init_early(); banner(BIOS_DEBUG, "disable_car: done"); } Modified: coreboot-v3/northbridge/amd/geodelx/Makefile =================================================================== --- coreboot-v3/northbridge/amd/geodelx/Makefile 2008-02-01 20:35:53 UTC (rev 571) +++ coreboot-v3/northbridge/amd/geodelx/Makefile 2008-02-04 16:16:16 UTC (rev 572) @@ -22,7 +22,6 @@ ifeq ($(CONFIG_NORTHBRIDGE_AMD_GEODELX),y) STAGE2_CHIPSET_OBJ += $(obj)/northbridge/amd/geodelx/geodelx.o \ - $(obj)/northbridge/amd/geodelx/geodelxinit.o \ $(obj)/northbridge/amd/geodelx/vsmsetup.o endif Modified: coreboot-v3/northbridge/amd/geodelx/geodelx.c =================================================================== --- coreboot-v3/northbridge/amd/geodelx/geodelx.c 2008-02-01 20:35:53 UTC (rev 571) +++ coreboot-v3/northbridge/amd/geodelx/geodelx.c 2008-02-04 16:16:16 UTC (rev 572) @@ -142,49 +142,6 @@ }; /** - * Size up ram. - * - * All we need to do here is read the MSR for DRAM and grab out the sizing - * bits. Note that this code depends on initram having run. It uses the MSRs, - * not the SPDs, and the MSRs of course are set up by initram. - * - * @return TODO - */ -int sizeram(void) -{ - struct msr msr; - int sizem = 0; - u32 dimm; - - /* Get the RAM size from the memory controller as calculated - * and set by auto_size_dimm(). - */ - msr = rdmsr(MC_CF07_DATA); - printk(BIOS_DEBUG, "sizeram: _MSR MC_CF07_DATA: %08x:%08x\n", msr.hi, - msr.lo); - - /* DIMM 0 */ - dimm = msr.hi; - /* Installed? */ - if ((dimm & 7) != 7) { - /* 1:8MB, 2:16MB, 3:32MB, 4:64MB, ... 7:512MB, 8:1GB */ - sizem = 4 << ((dimm >> 12) & 0x0F); - } - - /* DIMM 1 */ - dimm = msr.hi >> 16; - /* Installed? */ - if ((dimm & 7) != 7) { - /* 1:8MB, 2:16MB, 3:32MB, 4:64MB, ... 7:512MB, 8:1GB */ - sizem += 4 << ((dimm >> 12) & 0x0F); - } - - printk(BIOS_DEBUG, "sizeram: sizem 0x%xMB\n", sizem); - - return sizem; -} - -/** * Currently not set up. * * @param dev The nortbridge device. @@ -317,7 +274,7 @@ printk(BIOS_SPEW, ">> Entering northbridge.c: %s\n", __FUNCTION__); - northbridge_init_early(); +// northbridge_init_early(); chipsetinit(); setup_realmode_idt(); Modified: coreboot-v3/northbridge/amd/geodelx/geodelxinit.c =================================================================== --- coreboot-v3/northbridge/amd/geodelx/geodelxinit.c 2008-02-01 20:35:53 UTC (rev 571) +++ coreboot-v3/northbridge/amd/geodelx/geodelxinit.c 2008-02-04 16:16:16 UTC (rev 572) @@ -25,7 +25,6 @@ #include /* Function prototypes */ -extern int sizeram(void); struct gliutable { unsigned long desc_name; @@ -142,6 +141,49 @@ } /** + * Size up ram. + * + * All we need to do here is read the MSR for DRAM and grab out the sizing + * bits. Note that this code depends on initram having run. It uses the MSRs, + * not the SPDs, and the MSRs of course are set up by initram. + * + * @return TODO + */ +int sizeram(void) +{ + struct msr msr; + int sizem = 0; + u32 dimm; + + /* Get the RAM size from the memory controller as calculated + * and set by auto_size_dimm(). + */ + msr = rdmsr(MC_CF07_DATA); + printk(BIOS_DEBUG, "sizeram: _MSR MC_CF07_DATA: %08x:%08x\n", msr.hi, + msr.lo); + + /* DIMM 0 */ + dimm = msr.hi; + /* Installed? */ + if ((dimm & 7) != 7) { + /* 1:8MB, 2:16MB, 3:32MB, 4:64MB, ... 7:512MB, 8:1GB */ + sizem = 4 << ((dimm >> 12) & 0x0F); + } + + /* DIMM 1 */ + dimm = msr.hi >> 16; + /* Installed? */ + if ((dimm & 7) != 7) { + /* 1:8MB, 2:16MB, 3:32MB, 4:64MB, ... 7:512MB, 8:1GB */ + sizem += 4 << ((dimm >> 12) & 0x0F); + } + + printk(BIOS_DEBUG, "sizeram: sizem 0x%xMB\n", sizem); + + return sizem; +} + +/** * Set up the system memory registers, i.e. memory that can be used * for non-VSM (or SMM) purposes. * From jakllsch at kollasch.net Mon Feb 4 17:16:43 2008 From: jakllsch at kollasch.net (jakllsch at kollasch.net) Date: Mon, 4 Feb 2008 10:16:43 -0600 Subject: [coreboot] CK804 interrupt steering - SATA fix In-Reply-To: <200802040956.06360.duwe@lst.de> References: <20080201200113.GB1756@kirkkit.kollasch.net> <200802040956.06360.duwe@lst.de> Message-ID: <20080204161642.GK1756@kirkkit.kollasch.net> On Mon, Feb 04, 2008 at 09:56:06AM +0100, Torsten Duwe wrote: > On Friday 01 February 2008, jakllsch at kollasch.net wrote: > > Hi, > > > > I've reverse engineered some registers in the CK804. I believe with this > > information all SATA ports can be enabled without any lost interrupts. > > Great! > > > known values of nibbles: > > > > 0 - unrouted? > > 1 - irq 23 > > 8 - irq 20 > > c - irq 12 > > d - irq 21 > > e - irq 14 > > f - irq 15 > > These are the IO-APIC "pin numbers", not the interrupt routine taken on the > CPU end? Yes. Jonathan Kollasch -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rminnich at gmail.com Mon Feb 4 17:17:18 2008 From: rminnich at gmail.com (ron minnich) Date: Mon, 4 Feb 2008 08:17:18 -0800 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <47A6DF79.1040108@gmx.net> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> <13426df10802032144s3fb5f14bx2f4d67a698e7e90b@mail.gmail.com> <47A6DF79.1040108@gmx.net> Message-ID: <13426df10802040817p20d21ec2nf3bda25c47184e70@mail.gmail.com> On Feb 4, 2008 1:48 AM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006 at gmx.net> wrote: > Hi Ron, > > I really like it. One minor typo in arch/x86/Makefile, rest looks very > good. > > > > Compile tested, no new warnings, no new errors. > Acked-by: Carl-Daniel Hailfinger I fixed the two // Committed revision 572. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stepan at coresystems.de Mon Feb 4 17:22:24 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Mon, 04 Feb 2008 17:22:24 +0100 Subject: [coreboot] v3 challenge: global variables In-Reply-To: <13426df10802040812o639f6a12j76f280500b3ef60a@mail.gmail.com> References: <47A71885.1070803@gmx.net> <20080204152832.12294.qmail@stuge.se> <47A734D8.4010504@gmx.net> <13426df10802040812o639f6a12j76f280500b3ef60a@mail.gmail.com> Message-ID: <47A73BC0.6090204@coresystems.de> ron minnich wrote: > So, this is an example of the reason for the (void *) param I was > suggesting some time back. Such needs come up. > > One option is to have a convention that globals are at the base of the > stack, rounded to 64k. > > e.g. %esp & 0xffff0000 is where globals live. > > Let's just put the buffer to a well known address. We're trying to add a flexibility here that is just ballast. The buffer might need to change its position, ie when we are going from CAR to real RAM. Who knows. But other than that... -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From rminnich at gmail.com Mon Feb 4 17:26:23 2008 From: rminnich at gmail.com (ron minnich) Date: Mon, 4 Feb 2008 08:26:23 -0800 Subject: [coreboot] v3 challenge: global variables In-Reply-To: <47A73BC0.6090204@coresystems.de> References: <47A71885.1070803@gmx.net> <20080204152832.12294.qmail@stuge.se> <47A734D8.4010504@gmx.net> <13426df10802040812o639f6a12j76f280500b3ef60a@mail.gmail.com> <47A73BC0.6090204@coresystems.de> Message-ID: <13426df10802040826u120148f2j5842635622b26673@mail.gmail.com> On Feb 4, 2008 8:22 AM, Stefan Reinauer wrote: > > Let's just put the buffer to a well known address. > We're trying to add a flexibility here that is just ballast. OK, good point. So far our dedicated addresses are these: page 0 -- for vm86 page 1 -- for vm86 0x88000 -- 0x8ffff -- stack. (stack should probably move to 0x98000) Then put log buffer at 0x90000? ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marc.Jones at AMD.com Mon Feb 4 17:28:51 2008 From: Marc.Jones at AMD.com (Marc Jones) Date: Mon, 04 Feb 2008 09:28:51 -0700 Subject: [coreboot] Geode LX/CS5536 VSA In-Reply-To: <47A3C9C3.6040505@coresystems.de> References: <47A1FF9C.2040700@amd.com> <47A37D2B.5010208@whiterocker.com> <47A37FA3.4000505@gmx.net> <47A3C9C3.6040505@coresystems.de> Message-ID: <47A73D43.7080809@AMD.com> Stefan Reinauer wrote: > Carl-Daniel Hailfinger wrote: >>> I would appreciate any comments from the list on: >>> 1. hosting these VSA sources. Would coreboot.org be a good place to >>> keep the GNU-ified VSA sources? >>> >> >> Probably yes. The laptop.org GIT tree only has 2 revisions. Such an >> amount of change could easily be handled with subversion and >> coreboot.org surely could handle that. The final decision is made by >> Stefan, though. >> > Yes, we can add a seperate repository for that. Or even check it into > the coreboot tree? Would that make sense? > Whatever is preferred by you guys. > I think a separate repository would be better. >>> 2. the idea of permanently moving to a GNU-buildable version? >>> >> >> It would certainly make outside contributions easier. >> >> > Yes, no need for MASM to build the whole thing is a great step > forward. Congratulations! > If you would like to understand the architecture the VSA developers guide is helpful. http://www.amd.com/files/connectivitysolutions/geode/geode_gx/32664B_gx_vsa2_proggd.pdf Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From c-d.hailfinger.devel.2006 at gmx.net Mon Feb 4 17:42:59 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 04 Feb 2008 17:42:59 +0100 Subject: [coreboot] v3 challenge: global variables In-Reply-To: <13426df10802040826u120148f2j5842635622b26673@mail.gmail.com> References: <47A71885.1070803@gmx.net> <20080204152832.12294.qmail@stuge.se> <47A734D8.4010504@gmx.net> <13426df10802040812o639f6a12j76f280500b3ef60a@mail.gmail.com> <47A73BC0.6090204@coresystems.de> <13426df10802040826u120148f2j5842635622b26673@mail.gmail.com> Message-ID: <47A74093.6080403@gmx.net> On 04.02.2008 17:26, ron minnich wrote: > On Feb 4, 2008 8:22 AM, Stefan Reinauer wrote: > > >> Let's just put the buffer to a well known address. >> We're trying to add a flexibility here that is just ballast. >> It's not that easy. I need the location of the buffer and the current offset inside the buffer. The one global variable would have pointed to a struct containing all that info. > OK, good point. > > So far our dedicated addresses are these: > page 0 -- for vm86 > page 1 -- for vm86 > 0x88000 -- 0x8ffff -- stack. (stack should probably move to 0x98000) > Then put log buffer at 0x90000? > The log buffer has to be on the stack during CAR. That's not a big problem because we can allocate it in stage1_main(). The problem is that we need a way to locate where exactly the buffer is. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Mon Feb 4 17:45:22 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 04 Feb 2008 17:45:22 +0100 Subject: [coreboot] Geode LX/CS5536 VSA In-Reply-To: <47A73D43.7080809@AMD.com> References: <47A1FF9C.2040700@amd.com> <47A37D2B.5010208@whiterocker.com> <47A37FA3.4000505@gmx.net> <47A3C9C3.6040505@coresystems.de> <47A73D43.7080809@AMD.com> Message-ID: <47A74122.6000904@gmx.net> On 04.02.2008 17:28, Marc Jones wrote: > Stefan Reinauer wrote: > >> Carl-Daniel Hailfinger wrote: >> >>>> I would appreciate any comments from the list on: >>>> 1. hosting these VSA sources. Would coreboot.org be a good place to >>>> keep the GNU-ified VSA sources? >>>> >>>> >>> Probably yes. The laptop.org GIT tree only has 2 revisions. Such an >>> amount of change could easily be handled with subversion and >>> coreboot.org surely could handle that. The final decision is made by >>> Stefan, though. >>> >>> >> Yes, we can add a seperate repository for that. Or even check it into >> the coreboot tree? Would that make sense? >> Whatever is preferred by you guys. >> >> > I think a separate repository would be better. > Fully agreed. There is one problem, though. We may run out of paths on the server side if we invent another base path for a repo. But I'm pretty sure Stefan can tell us about the general organization of different repos hosted at coreboot.org, so we may figure out something reasonable. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Mon Feb 4 17:47:47 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 04 Feb 2008 17:47:47 +0100 Subject: [coreboot] v3 challenge: global variables In-Reply-To: <13426df10802040812o639f6a12j76f280500b3ef60a@mail.gmail.com> References: <47A71885.1070803@gmx.net> <20080204152832.12294.qmail@stuge.se> <47A734D8.4010504@gmx.net> <13426df10802040812o639f6a12j76f280500b3ef60a@mail.gmail.com> Message-ID: <47A741B3.3030902@gmx.net> On 04.02.2008 17:12, ron minnich wrote: > So, this is an example of the reason for the (void *) param I was > suggesting some time back. Such needs come up. > > One option is to have a convention that globals are at the base of the > stack, rounded to 64k. > > e.g. %esp & 0xffff0000 is where globals live. > That could work, although in a slightly different way. I would store a pointer at the base of the stack. That pointer would point to a struct which has all global info. Regards, Carl-Daniel -- http://www.hailfinger.org/ From rminnich at gmail.com Mon Feb 4 17:48:07 2008 From: rminnich at gmail.com (ron minnich) Date: Mon, 4 Feb 2008 08:48:07 -0800 Subject: [coreboot] v3 challenge: global variables In-Reply-To: <47A741B3.3030902@gmx.net> References: <47A71885.1070803@gmx.net> <20080204152832.12294.qmail@stuge.se> <47A734D8.4010504@gmx.net> <13426df10802040812o639f6a12j76f280500b3ef60a@mail.gmail.com> <47A741B3.3030902@gmx.net> Message-ID: <13426df10802040848i751d0765ve14ea54b1b8e7e5e@mail.gmail.com> On Feb 4, 2008 8:47 AM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006 at gmx.net> wrote: > > > That could work, although in a slightly different way. I would store a > pointer at the base of the stack. That pointer would point to a struct > which has all global info. > sure. At that point it's actually a parameter by any other name but :-) ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From stepan at coresystems.de Mon Feb 4 17:49:20 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Mon, 4 Feb 2008 17:49:20 +0100 Subject: [coreboot] v3 challenge: global variables In-Reply-To: <47A74093.6080403@gmx.net> References: <47A71885.1070803@gmx.net> <20080204152832.12294.qmail@stuge.se> <47A734D8.4010504@gmx.net> <13426df10802040812o639f6a12j76f280500b3ef60a@mail.gmail.com> <47A73BC0.6090204@coresystems.de> <13426df10802040826u120148f2j5842635622b26673@mail.gmail.com> <47A74093.6080403@gmx.net> Message-ID: <20080204164919.GA13506@coresystems.de> * Carl-Daniel Hailfinger [080204 17:42]: > It's not that easy. I need the location of the buffer and the current > offset inside the buffer. The one global variable would have pointed to > a struct containing all that info. You want that pointer persistant anyways, because you will likely have to pass it to linux, too. So why not have the first 4 byte of the buffer as "buffer pointer"? Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From c-d.hailfinger.devel.2006 at gmx.net Mon Feb 4 17:50:40 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 04 Feb 2008 17:50:40 +0100 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <13426df10802040745x4921ca9ev4662339f1bf8ff27@mail.gmail.com> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> <47A6D9DF.7000500@coresystems.de> <13426df10802040745x4921ca9ev4662339f1bf8ff27@mail.gmail.com> Message-ID: <47A74260.2020000@gmx.net> On 04.02.2008 16:45, ron minnich wrote: > we can provide a function, cycles, in the arch-dependent code. cycles > returns whatever makes sense for the architecture. > > Then this patch can be cleaned up. > What about this? (Varargs stuff still needs to get fixed.) Regards, Carl-Daniel Signed-off-by: Carl-Daniel Hailfinger Index: include/arch/x86/cpu.h =================================================================== --- include/arch/x86/cpu.h (Revision 571) +++ include/arch/x86/cpu.h (Arbeitskopie) @@ -196,4 +196,23 @@ __asm__ __volatile__("hlt" : : : "memory"); } +/** + * Retrieve a 32-bit time stamp. The generic get_timestamp() offers no guarantee + * whatsoever about monotony, granularity, absence of wraparounds or linear + * relationship between the time stamp and real time. + * This implementation has wraparounds after 2^32 cycles of the TSC register + * and will usually have a linear dependency on real time. + * Qemu and Geode LX support the rdtsc instruction. + * If v3 ever is used on x86 architectures which don't support rdtsc, we have + * to provide an alternative. + * + * @return 32-bit truncated number of TSC cycles since poweron. + */ +u32 get_timestamp(void) +{ + u32 tstamp; + __asm__ __volatile__ ("rdtsc" : "=a" (tstamp) : : "edx"); + return tstamp; +} + #endif /* ARCH_X86_CPU_H */ Index: lib/console.c =================================================================== --- lib/console.c (Revision 571) +++ lib/console.c (Arbeitskopie) @@ -34,11 +34,16 @@ { va_list args; int i; + u32 tstamp; if (msg_level > console_loglevel()) { return 0; } + tstamp = get_timestamp(); +#error vtxprintf expects varargs, need to fix up + vtxprintf(console_tx_byte, (void *)0, "[tstamp %d] ", tstamp); + va_start(args, fmt); i = vtxprintf(console_tx_byte, (void *)0, fmt, args); va_end(args); -- http://www.hailfinger.org/ From c-d.hailfinger.devel.2006 at gmx.net Mon Feb 4 18:09:12 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 04 Feb 2008 18:09:12 +0100 Subject: [coreboot] v3 challenge: global variables In-Reply-To: <20080204164919.GA13506@coresystems.de> References: <47A71885.1070803@gmx.net> <20080204152832.12294.qmail@stuge.se> <47A734D8.4010504@gmx.net> <13426df10802040812o639f6a12j76f280500b3ef60a@mail.gmail.com> <47A73BC0.6090204@coresystems.de> <13426df10802040826u120148f2j5842635622b26673@mail.gmail.com> <47A74093.6080403@gmx.net> <20080204164919.GA13506@coresystems.de> Message-ID: <47A746B8.9040709@gmx.net> On 04.02.2008 17:49, Stefan Reinauer wrote: > * Carl-Daniel Hailfinger [080204 17:42]: > >> It's not that easy. I need the location of the buffer and the current >> offset inside the buffer. The one global variable would have pointed to >> a struct containing all that info. >> > > You want that pointer persistant anyways, because you will likely have > to pass it to linux, too. So why not have the first 4 byte of the buffer > as "buffer pointer"? > Hm yes. That still leaves us with the problem to locate the buffer. We cannot rely on gcc to place it on stack in the location we want. Regards, Carl-Daniel -- http://www.hailfinger.org/ From peter at stuge.se Mon Feb 4 17:54:44 2008 From: peter at stuge.se (Peter Stuge) Date: Mon, 4 Feb 2008 17:54:44 +0100 Subject: [coreboot] v3 challenge: global variables In-Reply-To: <47A73BC0.6090204@coresystems.de> References: <47A71885.1070803@gmx.net> <20080204152832.12294.qmail@stuge.se> <47A734D8.4010504@gmx.net> <13426df10802040812o639f6a12j76f280500b3ef60a@mail.gmail.com> <47A73BC0.6090204@coresystems.de> Message-ID: <20080204165444.1243.qmail@stuge.se> On Mon, Feb 04, 2008 at 05:22:24PM +0100, Stefan Reinauer wrote: > >e.g. %esp & 0xffff0000 is where globals live. > > Let's just put the buffer to a well known address. Yes, simple is good. //Peter From stepan at coresystems.de Mon Feb 4 18:13:36 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Mon, 4 Feb 2008 18:13:36 +0100 Subject: [coreboot] v3 challenge: global variables In-Reply-To: <47A746B8.9040709@gmx.net> References: <47A71885.1070803@gmx.net> <20080204152832.12294.qmail@stuge.se> <47A734D8.4010504@gmx.net> <13426df10802040812o639f6a12j76f280500b3ef60a@mail.gmail.com> <47A73BC0.6090204@coresystems.de> <13426df10802040826u120148f2j5842635622b26673@mail.gmail.com> <47A74093.6080403@gmx.net> <20080204164919.GA13506@coresystems.de> <47A746B8.9040709@gmx.net> Message-ID: <20080204171336.GA15039@coresystems.de> * Carl-Daniel Hailfinger [080204 18:09]: > Hm yes. That still leaves us with the problem to locate the buffer. We > cannot rely on gcc to place it on stack in the location we want. But we know which "memory area" is CARed. We can just use a piece of that area. No need to involve gcc and its stack -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From corey.osgood at gmail.com Mon Feb 4 18:37:32 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Mon, 4 Feb 2008 12:37:32 -0500 Subject: [coreboot] Fwd: VIA EPIA CN100000 is finally Working all. In-Reply-To: References: <1202053744.3231.43.camel@urbez.site> <20080204140850.kdeceau3frk88kcs@linuxupc.upc.es> Message-ID: Oops, forgot the cc. I need to get thunderbird set back up. -Corey ---------- Forwarded message ---------- From: Corey Osgood Date: Feb 4, 2008 12:36 PM Subject: Re: [coreboot] VIA EPIA CN100000 is finally Working all. To: urbez at linuxupc.upc.edu On Feb 4, 2008 8:08 AM, wrote: > Sorry :))) i have read this and yes, after the wrmsr, must have a } > problem with cut and paste to the email , the 80 character console :) > > if (!(msr.lo & 0x10000)) {msr.lo|=0x10000 > ;wrmsr(MSR_IA32_MISC_ENABLE,msr);} > > And it works with C7 cpu, and uses the minimum voltage that accepts your > CPU > and the maximum Speed Multiplier of your CPU. > I'm not sure if works on another CPU. Ok, thanks. I'm having some issues with that bit of code as well: msr = rdmsr(MSR_IA32_PERF_STATUS); //TODO: wait CPU not busy bit 16 & 17 off (STATUS) wrmsr(MSR_IA32_PERF_CTL, 0, ((hi & 0xff00) | ((hi >> 16) & 0xff00)); This fails to compile, because wrmsr needs only 2 params and an msr struct (I think, never dove much into the msr stuff). I think this is what you're intending, just need to know if it's right: msr.lo = 0; msr.hi &= 0xff00; msr.hi |= (msr.hi >> 16); //or should it be msr.lo? wrmsr(MSR_IA32_PERF_CTL, msr); > Mmm, i must download the last svn, for compare with that i have, with a > diff. > Is different the auto.c, that i use, i cray for fit into the ROM_SIZE. > Initially i have working with a separate v8237 driver copied from another > via > , but, finally, if i remember i use the entire v8237r version of Rudolf > Marek. > I confirm that, when i can generate the pach for epia-cn, i'm at work :) > > The CF8, is a missed parameter that i use in another program. > I use normally another PCI routines, i not remember why. I cray, for pass > the > size as a parameter, better, if you use tables. > Ignore the CF8, and cut it :) > > It is possible that your mainboard, starts with diferent parameters in the > bridge that not afect mine? > > But wait for the DIFF results with the last version of SVN, to confirm if > are > more easy the problem, and i can have forgotten extra changes. If you want just send me a tarball of whatever you have, I'll sort through it and whip up a patch. I'm stuck in st. elsewhere with no access to the machine tonight anyways. -Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.marek at assembler.cz Mon Feb 4 18:38:50 2008 From: r.marek at assembler.cz (Rudolf Marek) Date: Mon, 04 Feb 2008 18:38:50 +0100 Subject: [coreboot] goal for march summit In-Reply-To: <47A71516.3060400@gmx.net> References: <13426df10802012049t54d8f799p7b0c7b99f315583@mail.gmail.com> <47A43EA8.1080702@assembler.cz> <47A4651A.6030603@gmx.net> <47A46DEB.1060709@assembler.cz> <47A5C6BE.8070400@gmx.net> <47A6EC14.7090608@assembler.cz> <47A71516.3060400@gmx.net> Message-ID: <47A74DAA.5040102@assembler.cz> > I'm all for it K8M890, but do we want to target VT8237Rplus (M2V-TVM), > VT8237A (M2V-MX) or VT8237S(M2V-MX SE)? Unfortunately, the only > comparison between these southbridges is > http://de.wikipedia.org/wiki/VIA_Southbridges I know at least one difference between VT8237A and VT8237R on register level (it is already documented somewhere). I guess this should not cause many troubles. > Maybe Stefan can get such a NDA? I gained such NDA as individual, through the web based form. It took a lot of time (one month). This all leads me to that idea that you or Uwe or someone else can go for NDA too. Due to lack of any free time, I can just help you to understand some caveats of datasheets and general design. I spent lot of time playing with this. So thats the reason I'm proposing this scheme. >> me. I think I'm able to answer most of the questions so I will act as some kind >> of filter and we shell ask VIA only in trouble. >> > > Good idea. Above is some more text to this. Thanks, Rudolf From stepan at coresystems.de Mon Feb 4 18:40:50 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Mon, 04 Feb 2008 18:40:50 +0100 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <47A74260.2020000@gmx.net> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> <47A6D9DF.7000500@coresystems.de> <13426df10802040745x4921ca9ev4662339f1bf8ff27@mail.gmail.com> <47A74260.2020000@gmx.net> Message-ID: <47A74E22.1080009@coresystems.de> Carl-Daniel Hailfinger wrote: > On 04.02.2008 16:45, ron minnich wrote: > >> we can provide a function, cycles, in the arch-dependent code. cycles >> returns whatever makes sense for the architecture. >> >> Then this patch can be cleaned up. >> >> > > What about this? (Varargs stuff still needs to get fixed.) > > What exactly do you intend to fix? > #endif /* ARCH_X86_CPU_H */ > Index: lib/console.c > =================================================================== > --- lib/console.c (Revision 571) > +++ lib/console.c (Arbeitskopie) > @@ -34,11 +34,16 @@ > { > va_list args; > int i; > + u32 tstamp; > > if (msg_level > console_loglevel()) { > return 0; > } > > + tstamp = get_timestamp(); > +#error vtxprintf expects varargs, need to fix up > NACK. > + vtxprintf(console_tx_byte, (void *)0, "[tstamp %d] ", tstamp); > + > va_start(args, fmt); > i = vtxprintf(console_tx_byte, (void *)0, fmt, args); > va_end(args); > > > -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From r.marek at assembler.cz Mon Feb 4 18:51:17 2008 From: r.marek at assembler.cz (Rudolf Marek) Date: Mon, 04 Feb 2008 18:51:17 +0100 Subject: [coreboot] Run PCI rom before PCI bus scan?? In-Reply-To: <20080204074936.4q1bevm7ksggowsk@www.smittys.pointclark.net> References: <20080202203430.1p2at6gtc0skw0so@www.smittys.pointclark.net> <20080203183738.GA4289@coresystems.de> <20080203144443.q9r9b16s00wgk8k0@www.smittys.pointclark.net> <47A62410.90805@gmail.com> <20080203181552.tybs70ow5c4osoo4@www.smittys.pointclark.net> <20080204074936.4q1bevm7ksggowsk@www.smittys.pointclark.net> Message-ID: <47A75095.3070109@assembler.cz> > difference I noticed is Linux is detecting the device id of 103Ah and > the eeprom has a device id of 1039h (this value should be correct). This is written in some datasheet (IMHO ICH4) It means that the ROM values were not used. I tried to help you so I read some datahsets but without any luck to ROMchip. Maybe you can try to scan original bios for same values as there are in the EEPROM. Maybe there is somewhere a pointer to them. Rudolf From c-d.hailfinger.devel.2006 at gmx.net Mon Feb 4 19:02:42 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 04 Feb 2008 19:02:42 +0100 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <47A74E22.1080009@coresystems.de> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> <47A6D9DF.7000500@coresystems.de> <13426df10802040745x4921ca9ev4662339f1bf8ff27@mail.gmail.com> <47A74260.2020000@gmx.net> <47A74E22.1080009@coresystems.de> Message-ID: <47A75342.6000603@gmx.net> On 04.02.2008 18:40, Stefan Reinauer wrote: > Carl-Daniel Hailfinger wrote: >> On 04.02.2008 16:45, ron minnich wrote: >> >>> we can provide a function, cycles, in the arch-dependent code. cycles >>> returns whatever makes sense for the architecture. >>> >>> Then this patch can be cleaned up. >>> >> >> What about this? (Varargs stuff still needs to get fixed.) >> > What exactly do you intend to fix? vtxprintf expects to get called with va_list. My call to vtxprintf is wrong, but I forgot how to do it the right way. >> #endif /* ARCH_X86_CPU_H */ >> Index: lib/console.c >> =================================================================== >> --- lib/console.c (Revision 571) >> +++ lib/console.c (Arbeitskopie) >> @@ -34,11 +34,16 @@ >> { >> va_list args; >> int i; >> + u32 tstamp; >> >> if (msg_level > console_loglevel()) { >> return 0; >> } >> >> + tstamp = get_timestamp(); >> +#error vtxprintf expects varargs, need to fix up >> > > NACK. The #error will not be committed, of course. It is just there because I don't know how to call vtxprintf correctly. Please help. >> + vtxprintf(console_tx_byte, (void *)0, "[tstamp %d] ", tstamp); >> + >> va_start(args, fmt); >> i = vtxprintf(console_tx_byte, (void *)0, fmt, args); >> va_end(args); Regards, Carl-Daniel -- http://www.hailfinger.org/ From rminnich at gmail.com Mon Feb 4 19:43:52 2008 From: rminnich at gmail.com (ron minnich) Date: Mon, 4 Feb 2008 10:43:52 -0800 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <47A75342.6000603@gmx.net> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> <47A6D9DF.7000500@coresystems.de> <13426df10802040745x4921ca9ev4662339f1bf8ff27@mail.gmail.com> <47A74260.2020000@gmx.net> <47A74E22.1080009@coresystems.de> <47A75342.6000603@gmx.net> Message-ID: <13426df10802041043s7f21deelcf80ce391806ecb7@mail.gmail.com> I would rather not have C code in .h files ... bloats code. thanks ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Mon Feb 4 19:46:20 2008 From: rminnich at gmail.com (ron minnich) Date: Mon, 4 Feb 2008 10:46:20 -0800 Subject: [coreboot] v3 challenge: global variables In-Reply-To: <47A746B8.9040709@gmx.net> References: <47A71885.1070803@gmx.net> <20080204152832.12294.qmail@stuge.se> <47A734D8.4010504@gmx.net> <13426df10802040812o639f6a12j76f280500b3ef60a@mail.gmail.com> <47A73BC0.6090204@coresystems.de> <13426df10802040826u120148f2j5842635622b26673@mail.gmail.com> <47A74093.6080403@gmx.net> <20080204164919.GA13506@coresystems.de> <47A746B8.9040709@gmx.net> Message-ID: <13426df10802041046o7c9d6f49oce7fa20e118d86bb@mail.gmail.com> I think we're making this too hard. Given a CAR address space, starting at CARBASE and ending at CAREND, we partition it as follows: bottom 1/2: stack top 1/2: defined by the Linux log buffer struct. All done. ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From c-d.hailfinger.devel.2006 at gmx.net Mon Feb 4 20:03:40 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 04 Feb 2008 20:03:40 +0100 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <13426df10802041043s7f21deelcf80ce391806ecb7@mail.gmail.com> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> <47A6D9DF.7000500@coresystems.de> <13426df10802040745x4921ca9ev4662339f1bf8ff27@mail.gmail.com> <47A74260.2020000@gmx.net> <47A74E22.1080009@coresystems.de> <47A75342.6000603@gmx.net> <13426df10802041043s7f21deelcf80ce391806ecb7@mail.gmail.com> Message-ID: <47A7618C.9060809@gmx.net> On 04.02.2008 19:43, ron minnich wrote: > I would rather not have C code in .h files ... bloats code. > The header file in question is a collection of a dozen C functions, all of them rather small. Do we want to clean up the file to resemble a real header file? Regards, Carl-Daniel -- http://www.hailfinger.org/ From rminnich at gmail.com Mon Feb 4 20:11:00 2008 From: rminnich at gmail.com (ron minnich) Date: Mon, 4 Feb 2008 11:11:00 -0800 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <47A7618C.9060809@gmx.net> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> <47A6D9DF.7000500@coresystems.de> <13426df10802040745x4921ca9ev4662339f1bf8ff27@mail.gmail.com> <47A74260.2020000@gmx.net> <47A74E22.1080009@coresystems.de> <47A75342.6000603@gmx.net> <13426df10802041043s7f21deelcf80ce391806ecb7@mail.gmail.com> <47A7618C.9060809@gmx.net> Message-ID: <13426df10802041111o506a29a2hb68bbc6a4e6e955@mail.gmail.com> On Feb 4, 2008 11:03 AM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006 at gmx.net> wrote: > On 04.02.2008 19:43, ron minnich wrote: > > I would rather not have C code in .h files ... bloats code. > > > > The header file in question is a collection of a dozen C functions, all > of them rather small. Do we want to clean up the file to resemble a real > header file? > Let's put cleaning it up on the list of TODOs, but at the same time let's not grow it. I don't want to change things too much now that we're almost booting. ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From c-d.hailfinger.devel.2006 at gmx.net Mon Feb 4 20:40:17 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 04 Feb 2008 20:40:17 +0100 Subject: [coreboot] v3 challenge: global variables In-Reply-To: <13426df10802041046o7c9d6f49oce7fa20e118d86bb@mail.gmail.com> References: <47A71885.1070803@gmx.net> <20080204152832.12294.qmail@stuge.se> <47A734D8.4010504@gmx.net> <13426df10802040812o639f6a12j76f280500b3ef60a@mail.gmail.com> <47A73BC0.6090204@coresystems.de> <13426df10802040826u120148f2j5842635622b26673@mail.gmail.com> <47A74093.6080403@gmx.net> <20080204164919.GA13506@coresystems.de> <47A746B8.9040709@gmx.net> <13426df10802041046o7c9d6f49oce7fa20e118d86bb@mail.gmail.com> Message-ID: <47A76A21.3060507@gmx.net> On 04.02.2008 19:46, ron minnich wrote: > I think we're making this too hard. > > Given a CAR address space, starting at CARBASE and ending at CAREND, we > partition it as follows: > bottom 1/2: stack > top 1/2: defined by the Linux log buffer struct. > Are you using "top" and "bottom" in the sense of memory addresses or their place on the stack? > All done. > Generally speaking, the concept is intriguing. However, I fear we want to increase log buffer size once RAM is enabled. For targets with 4k of CAR, that means we restrict the buffer to 2k and the stack to 2k. While this may be sufficient during CAR stage, once RAM is enabled we may have deep call chains which eat more than 2k (total) of stack, which will cause silent stack corruption when the log buffer reaches its wraparound point. If we push a pointer to the log buffer struct as first element on the stack, we can move the log buffer easily once RAM is enabled, while at the same time making sure nothing will interfere with the regular stack. Regards, Carl-Daniel -- http://www.hailfinger.org/ From marc.jones at amd.com Mon Feb 4 20:54:44 2008 From: marc.jones at amd.com (Marc Jones) Date: Mon, 04 Feb 2008 12:54:44 -0700 Subject: [coreboot] [PATCH] v2: factor out print_conf() from Geode LX mainboard dirs In-Reply-To: <47A67396.1090107@gmx.net> References: <47A67396.1090107@gmx.net> Message-ID: <47A76D84.7080201@amd.com> Carl-Daniel Hailfinger wrote: > Factor out print_conf() from Geode LX mainboard directories. The > following mainboard files had identical Geode LX specific print_conf() > implementations: > mainboard/amd/db800/mainboard.c > mainboard/amd/norwich/mainboard.c > mainboard/digitallogic/msm800sev/mainboard.c > mainboard/pcengines/alix1c/mainboard.c > Move print_conf() to northbridge/amd/lx/northbridge.c where it belongs. > > mainboard/amd/db800/mainboard.c | 155 > -------------------------- > mainboard/amd/norwich/mainboard.c | 157 > --------------------------- > mainboard/digitallogic/msm800sev/mainboard.c | 157 > +++------------------------ > mainboard/pcengines/alix1c/mainboard.c | 132 ---------------------- > northbridge/amd/lx/northbridge.c | 152 > +++++++++++++++++++++++++- > 5 files changed, 173 insertions(+), 580 deletions(-) > > Add a copyright notice to mainboard/digitallogic/msm800sev/mainboard.c. > > Not compile tested because I lack the resources. > > Signed-off-by: Carl-Daniel Hailfinger > I tested it on Norwich. Acked-by: Marc Jones -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From rminnich at gmail.com Mon Feb 4 21:34:34 2008 From: rminnich at gmail.com (ron minnich) Date: Mon, 4 Feb 2008 12:34:34 -0800 Subject: [coreboot] v3 challenge: global variables In-Reply-To: <47A76A21.3060507@gmx.net> References: <47A71885.1070803@gmx.net> <47A734D8.4010504@gmx.net> <13426df10802040812o639f6a12j76f280500b3ef60a@mail.gmail.com> <47A73BC0.6090204@coresystems.de> <13426df10802040826u120148f2j5842635622b26673@mail.gmail.com> <47A74093.6080403@gmx.net> <20080204164919.GA13506@coresystems.de> <47A746B8.9040709@gmx.net> <13426df10802041046o7c9d6f49oce7fa20e118d86bb@mail.gmail.com> <47A76A21.3060507@gmx.net> Message-ID: <13426df10802041234u65b0c958kc320ca3ee490f88e@mail.gmail.com> On Feb 4, 2008 11:40 AM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006 at gmx.net> wrote: > > > Are you using "top" and "bottom" in the sense of memory addresses or > their place on the stack? memory addresses.So for example log buf could be 0x8c000 to 0x8ffff and stack from 0x80000 to 0x8bfff ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordan.crouse at amd.com Mon Feb 4 21:51:46 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Mon, 4 Feb 2008 13:51:46 -0700 Subject: [coreboot] Geode LX/CS5536 VSA In-Reply-To: <47A37FA3.4000505@gmx.net> References: <47A1FF9C.2040700@amd.com> <47A37D2B.5010208@whiterocker.com> <47A37FA3.4000505@gmx.net> Message-ID: <20080204205146.GA9492@cosmic.amd.com> On 01/02/08 21:22 +0100, Carl-Daniel Hailfinger wrote: > Hi Chris! > > First of all, welcome on board! > > On 01.02.2008 21:12, Chris Kilgour wrote: > > Marc Jones wrote: > > > >> The following changes were made: > >> Remove int15 callbacks removed. CPU and memory are calculated by VSA. > >> VSA no longer takes all the MFGPTs. Two are now available for OS use. > >> > > > > I have "ported" the previous VSA sources from the OLPC git tree, so that > > it builds under GNU tools. It is completely untested, but I plan to > > start testing it any time now. It has never been released. > > > > Great, thanks! > > > I would appreciate any comments from the list on: > > 1. hosting these VSA sources. Would coreboot.org be a good place to > > keep the GNU-ified VSA sources? > > > > Probably yes. The laptop.org GIT tree only has 2 revisions. Such an > amount of change could easily be handled with subversion and > coreboot.org surely could handle that. The final decision is made by > Stefan, though. The history on the GIT tree is really not interesting - it just shows when I pushed the original VSA code and the LX update. > > 2. the idea of permanently moving to a GNU-buildable version? > > > > It would certainly make outside contributions easier. Yes - that would be best. THe original code is nice for debugging behavior in the VSA blob, but really only serves a documentation / historical purpose. If anything, we can toss the original tarball for archival purposes. > > 3. anyone interesting in helping to test the "port"? > > > > I'm pretty sure AMD is interested, although those people working on > Geode targets for coreboot will want to test as well. The ability to > tailor the VSA to do exactly the things we need and skip the rest is a > really exciting prospect. Absolutely, I'm interested. Also, we will want to teach buildrom to build the GNUified VSA. -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From jordan.crouse at amd.com Mon Feb 4 21:54:10 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Mon, 4 Feb 2008 13:54:10 -0700 Subject: [coreboot] goal for march summit In-Reply-To: <13426df10802012049t54d8f799p7b0c7b99f315583@mail.gmail.com> References: <13426df10802012049t54d8f799p7b0c7b99f315583@mail.gmail.com> Message-ID: <20080204205410.GC9492@cosmic.amd.com> On 01/02/08 20:49 -0800, ron minnich wrote: > I think our goal should be to get our first v3 port to the k8. > > We need a good, simple, cheap, target board with really common IO > (i.e. PATA, serial, etc.) > > Any ideas? How about the Serengeti-Cheetah on SimNow? Thats a free platform that everybody can use (and the new public release fixes some of the bugs that we have discovered). Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From chris at stockwith.co.uk Mon Feb 4 22:04:11 2008 From: chris at stockwith.co.uk (Chris Lingard) Date: Mon, 04 Feb 2008 21:04:11 +0000 Subject: [coreboot] Problem with M57SLI and newly installed MX25L4005 Message-ID: <47A77DCB.2070405@stockwith.co.uk> I recently found someone who could do the work of modifying the motherboard, Harald kindly posted me the chip. The machine came back and it would not boot with the switch up I then probably made a mistake, I used the BIOS itself to dump the factory BIOS to several floppies; then flipped the switch and wrote the factory BIOS to the new chip. The machine now boots from either BIOS. Using flashrom to detect the chip I get: Calibrating delay loop... 853M loops per second. OK. No coreboot table found. Found chipset "NVIDIA MCP55", enabling flash write... OK. Found board "GIGABYTE GA-M57SLI-S4": enabling flash write... Serial flash segment 0xfffe0000-0xffffffff enabled Serial flash segment 0x000e0000-0x000fffff enabled Serial flash segment 0xffee0000-0xffefffff disabled Serial flash segment 0xfff80000-0xfffeffff enabled LPC write to serial flash enabled serial flash pin 29 OK. Probing for MX25L4005, 512 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f, id2 0x9d7e No EEPROM/flash device found. The factory BIOS is the same except that it returns Probing for MX25L4005, 512 KB RDID returned 7f 9d 7e. No EEPROM/flash device found. I have tried coreboot v2 and v3; and have also tried compiling 32 bit on another machine and copyied the binary across. Both by machines have recent compilers, nothing earlier that gcc-4 series, but get no errors or warnings. Also a very recent glibc version 2.6. I tried writing the LinuxBios from a floppy, but the BIOS refuses saying there is a checksum error On running superiotool there is no BIOS chip connected to the 8716? (should there be?) superiotool r3064 Found ITE IT8716F (id=0x8716, rev=0x0) at 0x2e Register dump: idx 07 20 21 22 23 24 2b val 0a 87 16 00 11 1a 00 def NA 87 16 01 00 00 00 LDN 0x00 (Floppy) idx 30 60 61 70 74 f0 f1 val 01 03 f0 06 02 00 80 def 00 03 f0 06 02 00 00 LDN 0x01 (COM1) idx 30 60 61 70 f0 f1 f2 f3 val 00 00 00 00 00 50 00 7f def 00 03 f8 04 00 50 00 7f LDN 0x02 (COM2) idx 30 60 61 70 f0 f1 f2 f3 val 00 00 00 00 00 50 00 7f def 00 02 f8 03 00 50 00 7f LDN 0x03 (Parallel port) idx 30 60 61 62 63 70 74 f0 val 00 00 00 00 00 00 04 08 def 00 03 78 07 78 07 03 03 LDN 0x04 (Environment controller) idx 30 60 61 62 63 70 f0 f1 f2 f3 f4 f5 f6 val 01 02 90 00 00 00 80 00 0a 00 80 00 ff def 00 02 90 02 30 09 00 00 00 00 00 NA NA LDN 0x05 (Keyboard) idx 30 60 61 62 63 70 71 f0 val 01 00 60 00 64 01 02 68 def 01 00 60 00 64 01 02 00 LDN 0x06 (Mouse) idx 30 70 71 f0 val 01 0c 02 00 def 00 0c 02 00 LDN 0x07 (GPIO) idx 25 26 27 28 29 2a 2c 60 61 62 63 64 65 70 71 72 73 74 b0 b1 b2 b3 b4 b5 b 8 b9 ba bb bc bd c0 c1 c2 c3 c4 c8 c9 ca cb cc e0 e1 e2 e3 e4 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd val 00 43 20 00 81 00 1f 00 00 08 00 08 20 00 00 00 38 00 00 00 00 00 00 00 0 0 00 00 00 01 00 00 43 20 00 00 00 40 00 00 00 00 00 00 00 00 10 40 00 00 00 00 28 00 00 00 00 00 32 00 def 01 00 00 40 00 00 00 00 00 00 00 00 00 00 00 20 38 00 00 00 00 00 00 00 0 0 00 00 00 00 00 01 00 00 40 00 01 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 NA 00 LDN 0x08 (MIDI port) idx 30 60 61 70 f0 val 00 03 00 0a 00 def 00 03 00 0a 00 LDN 0x09 (Game port) idx 30 60 61 val 00 02 01 def 00 02 01 LDN 0x0a (Consumer IR) idx 30 60 61 70 f0 val 00 03 10 0b 06 def 00 03 10 0b 00 The block diagram shows the BIOS connected directly to the 570-SLI and not via the 8716 Could someone please give me a clue of either what I have missed out, or how to proceed? Chris Lingard From chris at stockwith.co.uk Mon Feb 4 22:15:52 2008 From: chris at stockwith.co.uk (Chris Lingard) Date: Mon, 04 Feb 2008 21:15:52 +0000 Subject: [coreboot] Problem with M57SLI and newly installed MX25L4005 Correction In-Reply-To: <47A77DCB.2070405@stockwith.co.uk> References: <47A77DCB.2070405@stockwith.co.uk> Message-ID: <47A78088.60608@stockwith.co.uk> Chris Lingard wrote wrongly, correction Manufacturer BIOS chip 7f 9d 7f New MX25L4005 7f 9d 7e From marc.jones at amd.com Mon Feb 4 22:56:09 2008 From: marc.jones at amd.com (Marc Jones) Date: Mon, 04 Feb 2008 14:56:09 -0700 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <13426df10802032144s3fb5f14bx2f4d67a698e7e90b@mail.gmail.com> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> <13426df10802032144s3fb5f14bx2f4d67a698e7e90b@mail.gmail.com> Message-ID: <47A789F9.7030701@amd.com> ron minnich wrote: > We're still far too slow, perhaps because we are not caching ROM? Correct. Here is a patch that changes that. BUT, here is a problem here. Due to some cache coherency snoop problems across pci we need the ROM cache properties to be write-serialize + cache disabled. My suggestion is to reset the ROM cache properties in stage2 once code is executing in memory. The problem is that stage2 returns to stage1 to load the payload. v3 would be slow again trying to decompress the payload. I don't have any good ideas to fix this yet. I don't know if any other systems will have similar problems with going back to the ROM to load payloads. Most BIOS "shadow" and this isn't an issues. It isn't an issue in v2 because the payload load code is in memory. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: romcache.patch URL: From wrightjmf at gmail.com Mon Feb 4 22:58:04 2008 From: wrightjmf at gmail.com (Jeremy Wright) Date: Mon, 4 Feb 2008 21:58:04 +0000 Subject: [coreboot] Capio II 320 and Coreboot In-Reply-To: <47A64094.5080904@gmx.net> References: <13426df10802011059sf8e3f99j25749f957e07af83@mail.gmail.com> <13426df10802011115y47de664fo57fcede4b1f3fd3@mail.gmail.com> <47A4998B.3040900@gmx.net> <47A64094.5080904@gmx.net> Message-ID: Well, I wasn't able to get the output of any commands from a Capio running DSL, but I tried hooking the first serial port up to a laptop and I got some data when the Capio is powered on and the splash screen comes up (it's not much though). I assume that means there is some data exchange going on, but I'm not sure where to go next. The program I used was not a terminal emulator, it was just a serial program that captured all the hex output from the serial port. Is there any way to set up a serial console now so that I can see what FILO/Etherboot are doing? Thanks, Jeremy On Feb 3, 2008 10:30 PM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006 at gmx.net> wrote: > On 03.02.2008 05:09, Jeremy Wright wrote: > >> > http://damnsmalllinux.org/cgi-bin/forums/ikonboard.cgi?act=Print;f=26;t=12165 > >> has some interesting info about Damn Small Linux on the Capio II. > >> > > > > Yeah, I've seen that before, but I'm having a hard time finding a TC325. > > I'll keep my eyes out for one though. Thanks. > > > > In theory, someone who already has DSL on the Capio II should be able to > run some diagnostic tools (flashrom, superiotool, lspci -nnvvvxxx, > dmidecode, dmesg). The contents of /proc/iomem, /proc/ioports, > /proc/interrupts would also be interesting. > Maybe that gives us enough information about memory ranges that should > be avoided etc. > > > Regards, > Carl-Daniel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Mon Feb 4 23:08:00 2008 From: rminnich at gmail.com (ron minnich) Date: Mon, 4 Feb 2008 14:08:00 -0800 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <47A789F9.7030701@amd.com> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> <13426df10802032144s3fb5f14bx2f4d67a698e7e90b@mail.gmail.com> <47A789F9.7030701@amd.com> Message-ID: <13426df10802041408p6aee9ab3pa3c94c6a30dfe74b@mail.gmail.com> Why can't we shadow? If we never write to the ROM space, at all, why not put the changed cache settings in right BEFORE we jump to the payload? i.e. don't change it to "slow" mode until we no longer need it cached? thanks ron From corey.osgood at gmail.com Tue Feb 5 00:15:45 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Mon, 4 Feb 2008 18:15:45 -0500 Subject: [coreboot] Fwd: Capio II 320 and Coreboot In-Reply-To: References: <13426df10802011059sf8e3f99j25749f957e07af83@mail.gmail.com> <13426df10802011115y47de664fo57fcede4b1f3fd3@mail.gmail.com> <47A4998B.3040900@gmx.net> <47A64094.5080904@gmx.net> Message-ID: Again, forgot to hit reply all, sorry. ---------- Forwarded message ---------- From: Corey Osgood Date: Feb 4, 2008 6:15 PM Subject: Re: [coreboot] Capio II 320 and Coreboot To: Jeremy Wright On Feb 4, 2008 4:58 PM, Jeremy Wright wrote: > Well, I wasn't able to get the output of any commands from a Capio running > DSL, but I tried hooking the first serial port up to a laptop and I got some > data when the Capio is powered on and the splash screen comes up (it's not > much though). I assume that means there is some data exchange going on, but > I'm not sure where to go next. The program I used was not a terminal > emulator, it was just a serial program that captured all the hex output from > the serial port. Is there any way to set up a serial console now so that I > can see what FILO/Etherboot are doing? > > Thanks, > > Jeremy minicom and picocom are the usual targets, they allow you to use a console over serial. most distros have minicom packages. -Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.jones at amd.com Tue Feb 5 00:27:36 2008 From: marc.jones at amd.com (Marc Jones) Date: Mon, 04 Feb 2008 16:27:36 -0700 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <13426df10802041408p6aee9ab3pa3c94c6a30dfe74b@mail.gmail.com> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> <13426df10802032144s3fb5f14bx2f4d67a698e7e90b@mail.gmail.com> <47A789F9.7030701@amd.com> <13426df10802041408p6aee9ab3pa3c94c6a30dfe74b@mail.gmail.com> Message-ID: <47A79F68.3040906@amd.com> ron minnich wrote: > Why can't we shadow? > We could. > If we never write to the ROM space, at all, why not put the changed > cache settings in right BEFORE we jump to the payload? i.e. don't > change it to "slow" mode until we no longer need it cached? I think that this would be ok. Maybe a generic call pre_payload() before the payload is run. I think that this would be a good genreic call for mainboard customization, like hardware_stage1(). It does mean that there will be duplicate code for each Geode platform. I was working on a patch but it grows the size of the bootblock. It was only a few bytes too large but I grew it from 16KB to 20KB. I know we don't expect the bootblock to change much but should is be mainboard specific? I'm still hitting the PCI device problem so I have only tested that it builds and the ROM is being cached. I can't get to the cache disable portion. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: romcache.patch URL: From corey.osgood at gmail.com Tue Feb 5 01:21:05 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Mon, 4 Feb 2008 19:21:05 -0500 Subject: [coreboot] VIA EPIA CN100000 is finally Working all. In-Reply-To: <1202160636.3232.6.camel@urbez.site> References: <1202053744.3231.43.camel@urbez.site> <20080204140850.kdeceau3frk88kcs@linuxupc.upc.es> <1202160636.3232.6.camel@urbez.site> Message-ID: On Feb 4, 2008 4:30 PM, Urbez Santana Roma wrote: > Sorry, i use my rdmsr and wrmsr, that difers too. > the first parameter is hi, then lo > I have transform it with too speed in the email. > > msr.lo=((msr.hi & 0xff00) | ((msr.hi >> 16) & 0xff00); > msr.hi=0; > wrmsr(MSR_IA32_PERF_CTL, msr); > > No problem, i make a patch for the svn, and send it. > I have the last downloaded, when all works, with them, send i the patch. > But i have show that the name is coreboot :))), ok, only names > Linuxbios->coreboot :) > with the same case. Could be 1 hour... sorry wait ... > > I must adapt the code, to the standard functions of Linuxbios, for no > confuse the people :) > > Urbez. Alright, cool. When I send in the rest of the cn700 stuff, I intend to just create a patch with the LinuxBIOS stuff still intact, then open it with a text editor and autoreplace everything. Might help you out as well. And I remembered the cc this time! -Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: From kononov at dls.net Tue Feb 5 06:29:12 2008 From: kononov at dls.net (Roman Kononov) Date: Mon, 04 Feb 2008 23:29:12 -0600 Subject: [coreboot] Cold reset in Tyan s2912 Message-ID: <47A7F428.1070704@dls.net> I have difficulty cold-resetting Tyan s2912, which has mcp55. The sequence outb(0x2,0xcf9); outb(0x6,0xcf9); is a warm reset. It does not reset the HyperTransport link frequency and width. The sequence outb(0xa,0xcf9); outb(0xe,0xcf9); causes the CPU to hang but does not reset the MB. Does anybody know what is wrong? Thanks, Roman From rminnich at gmail.com Tue Feb 5 07:31:58 2008 From: rminnich at gmail.com (ron minnich) Date: Mon, 4 Feb 2008 22:31:58 -0800 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <47A79F68.3040906@amd.com> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> <13426df10802032144s3fb5f14bx2f4d67a698e7e90b@mail.gmail.com> <47A789F9.7030701@amd.com> <13426df10802041408p6aee9ab3pa3c94c6a30dfe74b@mail.gmail.com> <47A79F68.3040906@amd.com> Message-ID: <13426df10802042231m753736aahb0a607d9c7bfdcec@mail.gmail.com> I think this is fine but I'd like to fit it into the "stage" nomenclature, so the numbering fits. So which stage is this? I am not sure, I feel like the stage numbering never quite got finished :-) possibly stage 3 is load payload, stage 4 is prepare the machine for a payload, and stage5 is run the payload? ron From yinghailu at gmail.com Tue Feb 5 07:48:18 2008 From: yinghailu at gmail.com (yhlu) Date: Mon, 4 Feb 2008 22:48:18 -0800 Subject: [coreboot] Cold reset in Tyan s2912 In-Reply-To: <47A7F428.1070704@dls.net> References: <47A7F428.1070704@dls.net> Message-ID: <2ea3fae10802042248y5b94d7bq2ffb426944da8abe@mail.gmail.com> On Feb 4, 2008 9:29 PM, Roman Kononov wrote: > I have difficulty cold-resetting Tyan s2912, which has mcp55. > > The sequence > outb(0x2,0xcf9); > outb(0x6,0xcf9); > is a warm reset. It does not reset the HyperTransport link frequency and width. how do you know? do you have other co-processor or htx installed? YH From svn at coreboot.org Tue Feb 5 10:21:47 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Tue, 5 Feb 2008 10:21:47 +0100 Subject: [coreboot] r3089 - in trunk/coreboot-v2/src: mainboard/amd/db800 mainboard/amd/norwich mainboard/digitallogic/msm800sev mainboard/pcengines/alix1c northbridge/amd/lx Message-ID: Author: hailfinger Date: 2008-02-05 10:21:46 +0100 (Tue, 05 Feb 2008) New Revision: 3089 Modified: trunk/coreboot-v2/src/mainboard/amd/db800/mainboard.c trunk/coreboot-v2/src/mainboard/amd/norwich/mainboard.c trunk/coreboot-v2/src/mainboard/digitallogic/msm800sev/mainboard.c trunk/coreboot-v2/src/mainboard/pcengines/alix1c/mainboard.c trunk/coreboot-v2/src/northbridge/amd/lx/northbridge.c Log: Factor out print_conf() from Geode LX mainboard directories. The following mainboard files had identical Geode LX specific print_conf() implementations: mainboard/amd/db800/mainboard.c mainboard/amd/norwich/mainboard.c mainboard/digitallogic/msm800sev/mainboard.c mainboard/pcengines/alix1c/mainboard.c Move print_conf() to northbridge/amd/lx/northbridge.c where it belongs. Add a copyright notice to mainboard/digitallogic/msm800sev/mainboard.c. Signed-off-by: Carl-Daniel Hailfinger Acked-by: Marc Jones Modified: trunk/coreboot-v2/src/mainboard/amd/db800/mainboard.c =================================================================== --- trunk/coreboot-v2/src/mainboard/amd/db800/mainboard.c 2008-02-01 23:14:40 UTC (rev 3088) +++ trunk/coreboot-v2/src/mainboard/amd/db800/mainboard.c 2008-02-05 09:21:46 UTC (rev 3089) @@ -19,162 +19,8 @@ #include #include -#include -#include -#include -#include -#include "../../../southbridge/amd/cs5536/cs5536.h" #include "chip.h" -/* Print the platform configuration - do before PCI init or it will not - * work right. - */ -void print_conf(void) -{ -#if DEFAULT_CONSOLE_LOGLEVEL >= BIOS_ERR - int i; - unsigned long iol; - msr_t msr; - - int cpu_msr_defs[] = { CPU_BC_L2_CONF, CPU_IM_CONFIG, CPU_DM_CONFIG0, - CPU_RCONF_DEFAULT, CPU_RCONF_BYPASS, CPU_RCONF_A0_BF, - CPU_RCONF_C0_DF, CPU_RCONF_E0_FF, CPU_RCONF_SMM, CPU_RCONF_DMM, - GLCP_DELAY_CONTROLS, GL_END - }; - - int gliu0_msr_defs[] = { MSR_GLIU0_BASE1, MSR_GLIU0_BASE2, - MSR_GLIU0_BASE4, MSR_GLIU0_BASE5, MSR_GLIU0_BASE6, - GLIU0_P2D_BMO_0, GLIU0_P2D_BMO_1, MSR_GLIU0_SYSMEM, - GLIU0_P2D_RO_0, GLIU0_P2D_RO_1, GLIU0_P2D_RO_2, - MSR_GLIU0_SHADOW, GLIU0_IOD_BM_0, GLIU0_IOD_BM_1, - GLIU0_IOD_BM_2, GLIU0_IOD_SC_0, GLIU0_IOD_SC_1, GLIU0_IOD_SC_2, - GLIU0_IOD_SC_3, GLIU0_IOD_SC_4, GLIU0_IOD_SC_5, - GLIU0_GLD_MSR_COH, GL_END - }; - - int gliu1_msr_defs[] = { MSR_GLIU1_BASE1, MSR_GLIU1_BASE2, - MSR_GLIU1_BASE3, MSR_GLIU1_BASE4, MSR_GLIU1_BASE5, - MSR_GLIU1_BASE6, MSR_GLIU1_BASE7, MSR_GLIU1_BASE8, - MSR_GLIU1_BASE9, MSR_GLIU1_BASE10, GLIU1_P2D_R_0, - GLIU1_P2D_R_1, GLIU1_P2D_R_2, GLIU1_P2D_R_3, MSR_GLIU1_SHADOW, - GLIU1_IOD_BM_0, GLIU1_IOD_BM_1, GLIU1_IOD_BM_2, GLIU1_IOD_SC_0, - GLIU1_IOD_SC_1, GLIU1_IOD_SC_2, GLIU1_IOD_SC_3, - GLIU1_GLD_MSR_COH, GL_END - }; - - int rconf_msr[] = { CPU_RCONF0, CPU_RCONF1, CPU_RCONF2, CPU_RCONF3, - CPU_RCONF4, CPU_RCONF5, CPU_RCONF6, CPU_RCONF7, GL_END - }; - - int cs5536_msr[] = { MDD_LBAR_GPIO, MDD_LBAR_FLSH0, MDD_LBAR_FLSH1, - MDD_LEG_IO, MDD_PIN_OPT, MDD_IRQM_ZLOW, MDD_IRQM_ZHIGH, - MDD_IRQM_PRIM, GL_END - }; - - int pci_msr[] = { GLPCI_CTRL, GLPCI_ARB, GLPCI_REN, GLPCI_A0_BF, - GLPCI_C0_DF, GLPCI_E0_FF, GLPCI_RC0, GLPCI_RC1, GLPCI_RC2, - GLPCI_RC3, GLPCI_ExtMSR, GLPCI_SPARE, GL_END - }; - - int dma_msr[] = { MDD_DMA_MAP, MDD_DMA_SHAD1, MDD_DMA_SHAD2, - MDD_DMA_SHAD3, MDD_DMA_SHAD4, MDD_DMA_SHAD5, MDD_DMA_SHAD6, - MDD_DMA_SHAD7, MDD_DMA_SHAD8, MDD_DMA_SHAD9, GL_END - }; - - printk_debug("---------- CPU ------------\n"); - - for (i = 0; cpu_msr_defs[i] != GL_END; i++) { - msr = rdmsr(cpu_msr_defs[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", - cpu_msr_defs[i], msr.hi, msr.lo); - } - - printk_debug("---------- GLIU 0 ------------\n"); - - for (i = 0; gliu0_msr_defs[i] != GL_END; i++) { - msr = rdmsr(gliu0_msr_defs[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", - gliu0_msr_defs[i], msr.hi, msr.lo); - } - - printk_debug("---------- GLIU 1 ------------\n"); - - for (i = 0; gliu1_msr_defs[i] != GL_END; i++) { - msr = rdmsr(gliu1_msr_defs[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", - gliu1_msr_defs[i], msr.hi, msr.lo); - } - - printk_debug("---------- RCONF ------------\n"); - - for (i = 0; rconf_msr[i] != GL_END; i++) { - msr = rdmsr(rconf_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", rconf_msr[i], - msr.hi, msr.lo); - } - - printk_debug("---------- VARIA ------------\n"); - msr = rdmsr(0x51300010); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", 0x51300010, msr.hi, - msr.lo); - - msr = rdmsr(0x51400015); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", 0x51400015, msr.hi, - msr.lo); - - printk_debug("---------- DIVIL IRQ ------------\n"); - msr = rdmsr(MDD_IRQM_YLOW); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_YLOW, msr.hi, - msr.lo); - msr = rdmsr(MDD_IRQM_YHIGH); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_YHIGH, - msr.hi, msr.lo); - msr = rdmsr(MDD_IRQM_ZLOW); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_ZLOW, msr.hi, - msr.lo); - msr = rdmsr(MDD_IRQM_ZHIGH); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_ZHIGH, - msr.hi, msr.lo); - - printk_debug("---------- PCI ------------\n"); - - for (i = 0; pci_msr[i] != GL_END; i++) { - msr = rdmsr(pci_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", pci_msr[i], - msr.hi, msr.lo); - } - - printk_debug("---------- LPC/UART DMA ------------\n"); - - for (i = 0; dma_msr[i] != GL_END; i++) { - msr = rdmsr(dma_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", dma_msr[i], - msr.hi, msr.lo); - } - - printk_debug("---------- CS5536 ------------\n"); - - for (i = 0; cs5536_msr[i] != GL_END; i++) { - msr = rdmsr(cs5536_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", cs5536_msr[i], - msr.hi, msr.lo); - } - - iol = inl(GPIO_IO_BASE + GPIOL_INPUT_ENABLE); - printk_debug("IOR 0x%08X is now 0x%08X\n", - GPIO_IO_BASE + GPIOL_INPUT_ENABLE, iol); - iol = inl(GPIOL_EVENTS_ENABLE); - printk_debug("IOR 0x%08X is now 0x%08X\n", - GPIO_IO_BASE + GPIOL_EVENTS_ENABLE, iol); - iol = inl(GPIOL_INPUT_INVERT_ENABLE); - printk_debug("IOR 0x%08X is now 0x%08X\n", - GPIO_IO_BASE + GPIOL_INPUT_INVERT_ENABLE, iol); - iol = inl(GPIO_MAPPER_X); - printk_debug("IOR 0x%08X is now 0x%08X\n", GPIO_IO_BASE + GPIO_MAPPER_X, - iol); -#endif //DEFAULT_CONSOLE_LOGLEVEL >= BIOS_ERR -} - static void init(struct device *dev) { printk_debug("AMD DB800 ENTER %s\n", __FUNCTION__); @@ -189,5 +35,4 @@ struct chip_operations mainboard_amd_db800_ops = { CHIP_NAME("AMD DB800 Mainboard") .enable_dev = enable_dev, - }; Modified: trunk/coreboot-v2/src/mainboard/amd/norwich/mainboard.c =================================================================== --- trunk/coreboot-v2/src/mainboard/amd/norwich/mainboard.c 2008-02-01 23:14:40 UTC (rev 3088) +++ trunk/coreboot-v2/src/mainboard/amd/norwich/mainboard.c 2008-02-05 09:21:46 UTC (rev 3089) @@ -19,162 +19,8 @@ #include #include -#include -#include -#include -#include -#include "../../../southbridge/amd/cs5536/cs5536.h" #include "chip.h" -/* Print the platform configuration - do before PCI init or it will not - * work right. - */ -void print_conf(void) -{ -#if DEFAULT_CONSOLE_LOGLEVEL >= BIOS_ERR - int i; - unsigned long iol; - msr_t msr; - - int cpu_msr_defs[] = { CPU_BC_L2_CONF, CPU_IM_CONFIG, CPU_DM_CONFIG0, - CPU_RCONF_DEFAULT, CPU_RCONF_BYPASS, CPU_RCONF_A0_BF, - CPU_RCONF_C0_DF, CPU_RCONF_E0_FF, CPU_RCONF_SMM, CPU_RCONF_DMM, - GLCP_DELAY_CONTROLS, GL_END - }; - - int gliu0_msr_defs[] = { MSR_GLIU0_BASE1, MSR_GLIU0_BASE2, - MSR_GLIU0_BASE4, MSR_GLIU0_BASE5, MSR_GLIU0_BASE6, - GLIU0_P2D_BMO_0, GLIU0_P2D_BMO_1, MSR_GLIU0_SYSMEM, - GLIU0_P2D_RO_0, GLIU0_P2D_RO_1, GLIU0_P2D_RO_2, - MSR_GLIU0_SHADOW, GLIU0_IOD_BM_0, GLIU0_IOD_BM_1, - GLIU0_IOD_BM_2, GLIU0_IOD_SC_0, GLIU0_IOD_SC_1, GLIU0_IOD_SC_2, - GLIU0_IOD_SC_3, GLIU0_IOD_SC_4, GLIU0_IOD_SC_5, - GLIU0_GLD_MSR_COH, GL_END - }; - - int gliu1_msr_defs[] = { MSR_GLIU1_BASE1, MSR_GLIU1_BASE2, - MSR_GLIU1_BASE3, MSR_GLIU1_BASE4, MSR_GLIU1_BASE5, - MSR_GLIU1_BASE6, MSR_GLIU1_BASE7, MSR_GLIU1_BASE8, - MSR_GLIU1_BASE9, MSR_GLIU1_BASE10, GLIU1_P2D_R_0, - GLIU1_P2D_R_1, GLIU1_P2D_R_2, GLIU1_P2D_R_3, MSR_GLIU1_SHADOW, - GLIU1_IOD_BM_0, GLIU1_IOD_BM_1, GLIU1_IOD_BM_2, GLIU1_IOD_SC_0, - GLIU1_IOD_SC_1, GLIU1_IOD_SC_2, GLIU1_IOD_SC_3, - GLIU1_GLD_MSR_COH, GL_END - }; - - int rconf_msr[] = { CPU_RCONF0, CPU_RCONF1, CPU_RCONF2, CPU_RCONF3, - CPU_RCONF4, CPU_RCONF5, CPU_RCONF6, CPU_RCONF7, GL_END - }; - - int cs5536_msr[] = { MDD_LBAR_GPIO, MDD_LBAR_FLSH0, MDD_LBAR_FLSH1, - MDD_LEG_IO, MDD_PIN_OPT, MDD_IRQM_ZLOW, MDD_IRQM_ZHIGH, - MDD_IRQM_PRIM, GL_END - }; - - int pci_msr[] = { GLPCI_CTRL, GLPCI_ARB, GLPCI_REN, GLPCI_A0_BF, - GLPCI_C0_DF, GLPCI_E0_FF, GLPCI_RC0, GLPCI_RC1, GLPCI_RC2, - GLPCI_RC3, GLPCI_ExtMSR, GLPCI_SPARE, GL_END - }; - - int dma_msr[] = { MDD_DMA_MAP, MDD_DMA_SHAD1, MDD_DMA_SHAD2, - MDD_DMA_SHAD3, MDD_DMA_SHAD4, MDD_DMA_SHAD5, MDD_DMA_SHAD6, - MDD_DMA_SHAD7, MDD_DMA_SHAD8, MDD_DMA_SHAD9, GL_END - }; - - printk_debug("---------- CPU ------------\n"); - - for (i = 0; cpu_msr_defs[i] != GL_END; i++) { - msr = rdmsr(cpu_msr_defs[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", - cpu_msr_defs[i], msr.hi, msr.lo); - } - - printk_debug("---------- GLIU 0 ------------\n"); - - for (i = 0; gliu0_msr_defs[i] != GL_END; i++) { - msr = rdmsr(gliu0_msr_defs[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", - gliu0_msr_defs[i], msr.hi, msr.lo); - } - - printk_debug("---------- GLIU 1 ------------\n"); - - for (i = 0; gliu1_msr_defs[i] != GL_END; i++) { - msr = rdmsr(gliu1_msr_defs[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", - gliu1_msr_defs[i], msr.hi, msr.lo); - } - - printk_debug("---------- RCONF ------------\n"); - - for (i = 0; rconf_msr[i] != GL_END; i++) { - msr = rdmsr(rconf_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", rconf_msr[i], - msr.hi, msr.lo); - } - - printk_debug("---------- VARIA ------------\n"); - msr = rdmsr(0x51300010); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", 0x51300010, msr.hi, - msr.lo); - - msr = rdmsr(0x51400015); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", 0x51400015, msr.hi, - msr.lo); - - printk_debug("---------- DIVIL IRQ ------------\n"); - msr = rdmsr(MDD_IRQM_YLOW); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_YLOW, msr.hi, - msr.lo); - msr = rdmsr(MDD_IRQM_YHIGH); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_YHIGH, - msr.hi, msr.lo); - msr = rdmsr(MDD_IRQM_ZLOW); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_ZLOW, msr.hi, - msr.lo); - msr = rdmsr(MDD_IRQM_ZHIGH); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_ZHIGH, - msr.hi, msr.lo); - - printk_debug("---------- PCI ------------\n"); - - for (i = 0; pci_msr[i] != GL_END; i++) { - msr = rdmsr(pci_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", pci_msr[i], - msr.hi, msr.lo); - } - - printk_debug("---------- LPC/UART DMA ------------\n"); - - for (i = 0; dma_msr[i] != GL_END; i++) { - msr = rdmsr(dma_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", dma_msr[i], - msr.hi, msr.lo); - } - - printk_debug("---------- CS5536 ------------\n"); - - for (i = 0; cs5536_msr[i] != GL_END; i++) { - msr = rdmsr(cs5536_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", cs5536_msr[i], - msr.hi, msr.lo); - } - - iol = inl(GPIO_IO_BASE + GPIOL_INPUT_ENABLE); - printk_debug("IOR 0x%08X is now 0x%08X\n", - GPIO_IO_BASE + GPIOL_INPUT_ENABLE, iol); - iol = inl(GPIOL_EVENTS_ENABLE); - printk_debug("IOR 0x%08X is now 0x%08X\n", - GPIO_IO_BASE + GPIOL_EVENTS_ENABLE, iol); - iol = inl(GPIOL_INPUT_INVERT_ENABLE); - printk_debug("IOR 0x%08X is now 0x%08X\n", - GPIO_IO_BASE + GPIOL_INPUT_INVERT_ENABLE, iol); - iol = inl(GPIO_MAPPER_X); - printk_debug("IOR 0x%08X is now 0x%08X\n", GPIO_IO_BASE + GPIO_MAPPER_X, - iol); -#endif //DEFAULT_CONSOLE_LOGLEVEL >= BIOS_ERR -} - static void init(struct device *dev) { printk_debug("Norwich ENTER %s\n", __FUNCTION__); @@ -188,6 +34,5 @@ struct chip_operations mainboard_amd_norwich_ops = { CHIP_NAME("AMD Norwich Mainboard") - .enable_dev = enable_dev, - + .enable_dev = enable_dev, }; Modified: trunk/coreboot-v2/src/mainboard/digitallogic/msm800sev/mainboard.c =================================================================== --- trunk/coreboot-v2/src/mainboard/digitallogic/msm800sev/mainboard.c 2008-02-01 23:14:40 UTC (rev 3088) +++ trunk/coreboot-v2/src/mainboard/digitallogic/msm800sev/mainboard.c 2008-02-05 09:21:46 UTC (rev 3089) @@ -1,144 +1,29 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2007 Advanced Micro Devices, Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + #include #include -#include -#include -#include -#include -#include -#include -#include "../../../southbridge/amd/cs5536/cs5536.h" #include "chip.h" -/* Print the platform configuration */ -void print_conf(void) { -#if DEFAULT_CONSOLE_LOGLEVEL >= BIOS_ERR - int i; - unsigned long iol; - msr_t msr; - - int cpu_msr_defs[] = { CPU_BC_L2_CONF, CPU_IM_CONFIG, - CPU_DM_CONFIG0, CPU_RCONF_DEFAULT, - CPU_RCONF_BYPASS, CPU_RCONF_A0_BF, CPU_RCONF_C0_DF, CPU_RCONF_E0_FF, - CPU_RCONF_SMM, CPU_RCONF_DMM, GLCP_DELAY_CONTROLS, GL_END - }; - - int gliu0_msr_defs[] = {MSR_GLIU0_BASE1, MSR_GLIU0_BASE2, MSR_GLIU0_BASE4, MSR_GLIU0_BASE5, MSR_GLIU0_BASE6, - GLIU0_P2D_BMO_0, GLIU0_P2D_BMO_1, MSR_GLIU0_SYSMEM, - GLIU0_P2D_RO_0, GLIU0_P2D_RO_1, GLIU0_P2D_RO_2, MSR_GLIU0_SHADOW, - GLIU0_IOD_BM_0, GLIU0_IOD_BM_1, GLIU0_IOD_BM_2, - GLIU0_IOD_SC_0, GLIU0_IOD_SC_1, GLIU0_IOD_SC_2, GLIU0_IOD_SC_3, GLIU0_IOD_SC_4, GLIU0_IOD_SC_5, - GLIU0_GLD_MSR_COH, GL_END - }; - - int gliu1_msr_defs[] = {MSR_GLIU1_BASE1, MSR_GLIU1_BASE2, MSR_GLIU1_BASE3, MSR_GLIU1_BASE4, MSR_GLIU1_BASE5, MSR_GLIU1_BASE6, - MSR_GLIU1_BASE7, MSR_GLIU1_BASE8, MSR_GLIU1_BASE9, MSR_GLIU1_BASE10, - GLIU1_P2D_R_0, GLIU1_P2D_R_1, GLIU1_P2D_R_2, GLIU1_P2D_R_3, MSR_GLIU1_SHADOW, - GLIU1_IOD_BM_0, GLIU1_IOD_BM_1, GLIU1_IOD_BM_2, - GLIU1_IOD_SC_0, GLIU1_IOD_SC_1, GLIU1_IOD_SC_2, GLIU1_IOD_SC_3, - GLIU1_GLD_MSR_COH, GL_END - }; - - int rconf_msr[] = { CPU_RCONF0, CPU_RCONF1, CPU_RCONF2, CPU_RCONF3, CPU_RCONF4, - CPU_RCONF5, CPU_RCONF6, CPU_RCONF7, GL_END - }; - - int cs5536_msr[] = { MDD_LBAR_GPIO, MDD_LBAR_FLSH0, MDD_LBAR_FLSH1, MDD_LEG_IO, MDD_PIN_OPT, - MDD_IRQM_ZLOW, MDD_IRQM_ZHIGH, MDD_IRQM_PRIM, GL_END - }; - - int pci_msr[] = { GLPCI_CTRL, GLPCI_ARB, GLPCI_REN, GLPCI_A0_BF, GLPCI_C0_DF, GLPCI_E0_FF, - GLPCI_RC0, GLPCI_RC1, GLPCI_RC2, GLPCI_RC3, GLPCI_ExtMSR, GLPCI_SPARE, - GL_END - }; - - int dma_msr[] = { MDD_DMA_MAP, MDD_DMA_SHAD1, MDD_DMA_SHAD2, MDD_DMA_SHAD3, MDD_DMA_SHAD4, - MDD_DMA_SHAD5, MDD_DMA_SHAD6, MDD_DMA_SHAD7, MDD_DMA_SHAD8, - MDD_DMA_SHAD9, GL_END - }; - - - printk_debug("---------- CPU ------------\n"); - - for(i = 0; cpu_msr_defs[i] != GL_END; i++) { - msr = rdmsr(cpu_msr_defs[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", cpu_msr_defs[i], msr.hi, msr.lo); - } - - printk_debug("---------- GLIU 0 ------------\n"); - - for(i = 0; gliu0_msr_defs[i] != GL_END; i++) { - msr = rdmsr(gliu0_msr_defs[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", gliu0_msr_defs[i], msr.hi, msr.lo); - } - - printk_debug("---------- GLIU 1 ------------\n"); - - for(i = 0; gliu1_msr_defs[i] != GL_END; i++) { - msr = rdmsr(gliu1_msr_defs[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", gliu1_msr_defs[i], msr.hi, msr.lo); - } - - printk_debug("---------- RCONF ------------\n"); - - for(i = 0; rconf_msr[i] != GL_END; i++) { - msr = rdmsr(rconf_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", rconf_msr[i], msr.hi, msr.lo); - } - - printk_debug("---------- VARIA ------------\n"); - msr = rdmsr(0x51300010); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", 0x51300010, msr.hi, msr.lo); - - msr = rdmsr(0x51400015); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", 0x51400015, msr.hi, msr.lo); - - printk_debug("---------- DIVIL IRQ ------------\n"); - msr = rdmsr(MDD_IRQM_YLOW); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_YLOW, msr.hi, msr.lo); - msr = rdmsr(MDD_IRQM_YHIGH); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_YHIGH, msr.hi, msr.lo); - msr = rdmsr(MDD_IRQM_ZLOW); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_ZLOW, msr.hi, msr.lo); - msr = rdmsr(MDD_IRQM_ZHIGH); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_ZHIGH, msr.hi, msr.lo); - - - printk_debug("---------- PCI ------------\n"); - - for(i = 0; pci_msr[i] != GL_END; i++) { - msr = rdmsr(pci_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", pci_msr[i], msr.hi, msr.lo); - } - - printk_debug("---------- LPC/UART DMA ------------\n"); - - for(i = 0; dma_msr[i] != GL_END; i++) { - msr = rdmsr(dma_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", dma_msr[i], msr.hi, msr.lo); - } - - printk_debug("---------- CS5536 ------------\n"); - - for(i = 0; cs5536_msr[i] != GL_END; i++) { - msr = rdmsr(cs5536_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", cs5536_msr[i], msr.hi, msr.lo); - } - - iol = inl(GPIOL_INPUT_ENABLE); - printk_debug("IOR 0x%08X is now 0x%08X\n", GPIOL_INPUT_ENABLE, iol); - iol = inl(GPIOL_EVENTS_ENABLE); - printk_debug("IOR 0x%08X is now 0x%08X\n", GPIOL_EVENTS_ENABLE, iol); - iol = inl(GPIOL_INPUT_INVERT_ENABLE); - printk_debug("IOR 0x%08X is now 0x%08X\n", GPIOL_INPUT_INVERT_ENABLE, iol); - iol = inl(GPIO_MAPPER_X); - printk_debug("IOR 0x%08X is now 0x%08X\n", GPIO_MAPPER_X, iol); -#endif //DEFAULT_CONSOLE_LOGLEVEL >= BIOS_ERR -} - -static void init(struct device *dev) { - +static void init(struct device *dev) +{ printk_debug("MSM800SEV ENTER %s\n", __FUNCTION__); - printk_debug("MSM800SEV EXIT %s\n", __FUNCTION__); } Modified: trunk/coreboot-v2/src/mainboard/pcengines/alix1c/mainboard.c =================================================================== --- trunk/coreboot-v2/src/mainboard/pcengines/alix1c/mainboard.c 2008-02-01 23:14:40 UTC (rev 3088) +++ trunk/coreboot-v2/src/mainboard/pcengines/alix1c/mainboard.c 2008-02-05 09:21:46 UTC (rev 3089) @@ -19,140 +19,8 @@ #include #include -#include -#include -#include -#include -#include -#include "../../../southbridge/amd/cs5536/cs5536.h" #include "chip.h" -/* Print the platform configuration. */ -void print_conf(void) { -#if DEFAULT_CONSOLE_LOGLEVEL >= BIOS_ERR - int i; - unsigned long iol; - msr_t msr; - - int cpu_msr_defs[] = { CPU_BC_L2_CONF, CPU_IM_CONFIG, - CPU_DM_CONFIG0, CPU_RCONF_DEFAULT, - CPU_RCONF_BYPASS, CPU_RCONF_A0_BF, CPU_RCONF_C0_DF, CPU_RCONF_E0_FF, - CPU_RCONF_SMM, CPU_RCONF_DMM, GLCP_DELAY_CONTROLS, GL_END - }; - - int gliu0_msr_defs[] = {MSR_GLIU0_BASE1, MSR_GLIU0_BASE2, MSR_GLIU0_BASE4, MSR_GLIU0_BASE5, MSR_GLIU0_BASE6, - GLIU0_P2D_BMO_0, GLIU0_P2D_BMO_1, MSR_GLIU0_SYSMEM, - GLIU0_P2D_RO_0, GLIU0_P2D_RO_1, GLIU0_P2D_RO_2, MSR_GLIU0_SHADOW, - GLIU0_IOD_BM_0, GLIU0_IOD_BM_1, GLIU0_IOD_BM_2, - GLIU0_IOD_SC_0, GLIU0_IOD_SC_1, GLIU0_IOD_SC_2, GLIU0_IOD_SC_3, GLIU0_IOD_SC_4, GLIU0_IOD_SC_5, - GLIU0_GLD_MSR_COH, GL_END - }; - - int gliu1_msr_defs[] = {MSR_GLIU1_BASE1, MSR_GLIU1_BASE2, MSR_GLIU1_BASE3, MSR_GLIU1_BASE4, MSR_GLIU1_BASE5, MSR_GLIU1_BASE6, - MSR_GLIU1_BASE7, MSR_GLIU1_BASE8, MSR_GLIU1_BASE9, MSR_GLIU1_BASE10, - GLIU1_P2D_R_0, GLIU1_P2D_R_1, GLIU1_P2D_R_2, GLIU1_P2D_R_3, MSR_GLIU1_SHADOW, - GLIU1_IOD_BM_0, GLIU1_IOD_BM_1, GLIU1_IOD_BM_2, - GLIU1_IOD_SC_0, GLIU1_IOD_SC_1, GLIU1_IOD_SC_2, GLIU1_IOD_SC_3, - GLIU1_GLD_MSR_COH, GL_END - }; - - int rconf_msr[] = { CPU_RCONF0, CPU_RCONF1, CPU_RCONF2, CPU_RCONF3, CPU_RCONF4, - CPU_RCONF5, CPU_RCONF6, CPU_RCONF7, GL_END - }; - - int cs5536_msr[] = { MDD_LBAR_GPIO, MDD_LBAR_FLSH0, MDD_LBAR_FLSH1, MDD_LEG_IO, MDD_PIN_OPT, - MDD_IRQM_ZLOW, MDD_IRQM_ZHIGH, MDD_IRQM_PRIM, GL_END - }; - - int pci_msr[] = { GLPCI_CTRL, GLPCI_ARB, GLPCI_REN, GLPCI_A0_BF, GLPCI_C0_DF, GLPCI_E0_FF, - GLPCI_RC0, GLPCI_RC1, GLPCI_RC2, GLPCI_RC3, GLPCI_ExtMSR, GLPCI_SPARE, - GL_END - }; - - int dma_msr[] = { MDD_DMA_MAP, MDD_DMA_SHAD1, MDD_DMA_SHAD2, MDD_DMA_SHAD3, MDD_DMA_SHAD4, - MDD_DMA_SHAD5, MDD_DMA_SHAD6, MDD_DMA_SHAD7, MDD_DMA_SHAD8, - MDD_DMA_SHAD9, GL_END - }; - - - printk_debug("---------- CPU ------------\n"); - - for(i = 0; cpu_msr_defs[i] != GL_END; i++) { - msr = rdmsr(cpu_msr_defs[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", cpu_msr_defs[i], msr.hi, msr.lo); - } - - printk_debug("---------- GLIU 0 ------------\n"); - - for(i = 0; gliu0_msr_defs[i] != GL_END; i++) { - msr = rdmsr(gliu0_msr_defs[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", gliu0_msr_defs[i], msr.hi, msr.lo); - } - - printk_debug("---------- GLIU 1 ------------\n"); - - for(i = 0; gliu1_msr_defs[i] != GL_END; i++) { - msr = rdmsr(gliu1_msr_defs[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", gliu1_msr_defs[i], msr.hi, msr.lo); - } - - printk_debug("---------- RCONF ------------\n"); - - for(i = 0; rconf_msr[i] != GL_END; i++) { - msr = rdmsr(rconf_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", rconf_msr[i], msr.hi, msr.lo); - } - - printk_debug("---------- VARIA ------------\n"); - msr = rdmsr(0x51300010); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", 0x51300010, msr.hi, msr.lo); - - msr = rdmsr(0x51400015); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", 0x51400015, msr.hi, msr.lo); - - printk_debug("---------- DIVIL IRQ ------------\n"); - msr = rdmsr(MDD_IRQM_YLOW); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_YLOW, msr.hi, msr.lo); - msr = rdmsr(MDD_IRQM_YHIGH); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_YHIGH, msr.hi, msr.lo); - msr = rdmsr(MDD_IRQM_ZLOW); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_ZLOW, msr.hi, msr.lo); - msr = rdmsr(MDD_IRQM_ZHIGH); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_ZHIGH, msr.hi, msr.lo); - - - printk_debug("---------- PCI ------------\n"); - - for(i = 0; pci_msr[i] != GL_END; i++) { - msr = rdmsr(pci_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", pci_msr[i], msr.hi, msr.lo); - } - - printk_debug("---------- LPC/UART DMA ------------\n"); - - for(i = 0; dma_msr[i] != GL_END; i++) { - msr = rdmsr(dma_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", dma_msr[i], msr.hi, msr.lo); - } - - printk_debug("---------- CS5536 ------------\n"); - - for(i = 0; cs5536_msr[i] != GL_END; i++) { - msr = rdmsr(cs5536_msr[i]); - printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", cs5536_msr[i], msr.hi, msr.lo); - } - - iol = inl(GPIOL_INPUT_ENABLE); - printk_debug("IOR 0x%08X is now 0x%08X\n", GPIOL_INPUT_ENABLE, iol); - iol = inl(GPIOL_EVENTS_ENABLE); - printk_debug("IOR 0x%08X is now 0x%08X\n", GPIOL_EVENTS_ENABLE, iol); - iol = inl(GPIOL_INPUT_INVERT_ENABLE); - printk_debug("IOR 0x%08X is now 0x%08X\n", GPIOL_INPUT_INVERT_ENABLE, iol); - iol = inl(GPIO_MAPPER_X); - printk_debug("IOR 0x%08X is now 0x%08X\n", GPIO_MAPPER_X, iol); -#endif //DEFAULT_CONSOLE_LOGLEVEL >= BIOS_ERR -} - static void init(struct device *dev) { printk_debug("ALIX1.C ENTER %s\n", __FUNCTION__); Modified: trunk/coreboot-v2/src/northbridge/amd/lx/northbridge.c =================================================================== --- trunk/coreboot-v2/src/northbridge/amd/lx/northbridge.c 2008-02-01 23:14:40 UTC (rev 3088) +++ trunk/coreboot-v2/src/northbridge/amd/lx/northbridge.c 2008-02-05 09:21:46 UTC (rev 3089) @@ -34,7 +34,9 @@ #include #include "chip.h" #include "northbridge.h" +#include "../../../southbridge/amd/cs5536/cs5536.h" + /* here is programming for the various MSRs.*/ #define IM_QWAIT 0x100000 @@ -76,7 +78,6 @@ extern void graphics_init(void); extern void cpubug(void); extern void chipsetinit(void); -extern void print_conf(void); extern uint32_t get_systop(void); void northbridge_init_early(void); @@ -118,6 +119,155 @@ 0} }; +/* Print the platform configuration - do before PCI init or it will not + * work right. + */ +void print_conf(void) +{ +#if DEFAULT_CONSOLE_LOGLEVEL >= BIOS_ERR + int i; + unsigned long iol; + msr_t msr; + + int cpu_msr_defs[] = { CPU_BC_L2_CONF, CPU_IM_CONFIG, CPU_DM_CONFIG0, + CPU_RCONF_DEFAULT, CPU_RCONF_BYPASS, CPU_RCONF_A0_BF, + CPU_RCONF_C0_DF, CPU_RCONF_E0_FF, CPU_RCONF_SMM, CPU_RCONF_DMM, + GLCP_DELAY_CONTROLS, GL_END + }; + + int gliu0_msr_defs[] = { MSR_GLIU0_BASE1, MSR_GLIU0_BASE2, + MSR_GLIU0_BASE4, MSR_GLIU0_BASE5, MSR_GLIU0_BASE6, + GLIU0_P2D_BMO_0, GLIU0_P2D_BMO_1, MSR_GLIU0_SYSMEM, + GLIU0_P2D_RO_0, GLIU0_P2D_RO_1, GLIU0_P2D_RO_2, + MSR_GLIU0_SHADOW, GLIU0_IOD_BM_0, GLIU0_IOD_BM_1, + GLIU0_IOD_BM_2, GLIU0_IOD_SC_0, GLIU0_IOD_SC_1, GLIU0_IOD_SC_2, + GLIU0_IOD_SC_3, GLIU0_IOD_SC_4, GLIU0_IOD_SC_5, + GLIU0_GLD_MSR_COH, GL_END + }; + + int gliu1_msr_defs[] = { MSR_GLIU1_BASE1, MSR_GLIU1_BASE2, + MSR_GLIU1_BASE3, MSR_GLIU1_BASE4, MSR_GLIU1_BASE5, + MSR_GLIU1_BASE6, MSR_GLIU1_BASE7, MSR_GLIU1_BASE8, + MSR_GLIU1_BASE9, MSR_GLIU1_BASE10, GLIU1_P2D_R_0, + GLIU1_P2D_R_1, GLIU1_P2D_R_2, GLIU1_P2D_R_3, MSR_GLIU1_SHADOW, + GLIU1_IOD_BM_0, GLIU1_IOD_BM_1, GLIU1_IOD_BM_2, GLIU1_IOD_SC_0, + GLIU1_IOD_SC_1, GLIU1_IOD_SC_2, GLIU1_IOD_SC_3, + GLIU1_GLD_MSR_COH, GL_END + }; + + int rconf_msr[] = { CPU_RCONF0, CPU_RCONF1, CPU_RCONF2, CPU_RCONF3, + CPU_RCONF4, CPU_RCONF5, CPU_RCONF6, CPU_RCONF7, GL_END + }; + + int cs5536_msr[] = { MDD_LBAR_GPIO, MDD_LBAR_FLSH0, MDD_LBAR_FLSH1, + MDD_LEG_IO, MDD_PIN_OPT, MDD_IRQM_ZLOW, MDD_IRQM_ZHIGH, + MDD_IRQM_PRIM, GL_END + }; + + int pci_msr[] = { GLPCI_CTRL, GLPCI_ARB, GLPCI_REN, GLPCI_A0_BF, + GLPCI_C0_DF, GLPCI_E0_FF, GLPCI_RC0, GLPCI_RC1, GLPCI_RC2, + GLPCI_RC3, GLPCI_ExtMSR, GLPCI_SPARE, GL_END + }; + + int dma_msr[] = { MDD_DMA_MAP, MDD_DMA_SHAD1, MDD_DMA_SHAD2, + MDD_DMA_SHAD3, MDD_DMA_SHAD4, MDD_DMA_SHAD5, MDD_DMA_SHAD6, + MDD_DMA_SHAD7, MDD_DMA_SHAD8, MDD_DMA_SHAD9, GL_END + }; + + printk_debug("---------- CPU ------------\n"); + + for (i = 0; cpu_msr_defs[i] != GL_END; i++) { + msr = rdmsr(cpu_msr_defs[i]); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", + cpu_msr_defs[i], msr.hi, msr.lo); + } + + printk_debug("---------- GLIU 0 ------------\n"); + + for (i = 0; gliu0_msr_defs[i] != GL_END; i++) { + msr = rdmsr(gliu0_msr_defs[i]); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", + gliu0_msr_defs[i], msr.hi, msr.lo); + } + + printk_debug("---------- GLIU 1 ------------\n"); + + for (i = 0; gliu1_msr_defs[i] != GL_END; i++) { + msr = rdmsr(gliu1_msr_defs[i]); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", + gliu1_msr_defs[i], msr.hi, msr.lo); + } + + printk_debug("---------- RCONF ------------\n"); + + for (i = 0; rconf_msr[i] != GL_END; i++) { + msr = rdmsr(rconf_msr[i]); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", rconf_msr[i], + msr.hi, msr.lo); + } + + printk_debug("---------- VARIA ------------\n"); + msr = rdmsr(0x51300010); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", 0x51300010, msr.hi, + msr.lo); + + msr = rdmsr(0x51400015); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", 0x51400015, msr.hi, + msr.lo); + + printk_debug("---------- DIVIL IRQ ------------\n"); + msr = rdmsr(MDD_IRQM_YLOW); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_YLOW, msr.hi, + msr.lo); + msr = rdmsr(MDD_IRQM_YHIGH); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_YHIGH, + msr.hi, msr.lo); + msr = rdmsr(MDD_IRQM_ZLOW); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_ZLOW, msr.hi, + msr.lo); + msr = rdmsr(MDD_IRQM_ZHIGH); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_ZHIGH, + msr.hi, msr.lo); + + printk_debug("---------- PCI ------------\n"); + + for (i = 0; pci_msr[i] != GL_END; i++) { + msr = rdmsr(pci_msr[i]); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", pci_msr[i], + msr.hi, msr.lo); + } + + printk_debug("---------- LPC/UART DMA ------------\n"); + + for (i = 0; dma_msr[i] != GL_END; i++) { + msr = rdmsr(dma_msr[i]); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", dma_msr[i], + msr.hi, msr.lo); + } + + printk_debug("---------- CS5536 ------------\n"); + + for (i = 0; cs5536_msr[i] != GL_END; i++) { + msr = rdmsr(cs5536_msr[i]); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", cs5536_msr[i], + msr.hi, msr.lo); + } + + iol = inl(GPIO_IO_BASE + GPIOL_INPUT_ENABLE); + printk_debug("IOR 0x%08X is now 0x%08X\n", + GPIO_IO_BASE + GPIOL_INPUT_ENABLE, iol); + iol = inl(GPIOL_EVENTS_ENABLE); + printk_debug("IOR 0x%08X is now 0x%08X\n", + GPIO_IO_BASE + GPIOL_EVENTS_ENABLE, iol); + iol = inl(GPIOL_INPUT_INVERT_ENABLE); + printk_debug("IOR 0x%08X is now 0x%08X\n", + GPIO_IO_BASE + GPIOL_INPUT_INVERT_ENABLE, iol); + iol = inl(GPIO_MAPPER_X); + printk_debug("IOR 0x%08X is now 0x%08X\n", GPIO_IO_BASE + GPIO_MAPPER_X, + iol); +#endif //DEFAULT_CONSOLE_LOGLEVEL >= BIOS_ERR +} + /* todo: add a resource record. We don't do this here because this may be called when * very little of the platform is actually working. */ From info at coresystems.de Tue Feb 5 11:08:59 2008 From: info at coresystems.de (coreboot information) Date: Tue, 05 Feb 2008 11:08:59 +0100 Subject: [coreboot] r3089 build service Message-ID: Dear coreboot readers! This is the automated build check service of coreboot. The developer "hailfinger" checked in revision 3089 to the coreboot source repository and caused the following changes: Change Log: Factor out print_conf() from Geode LX mainboard directories. The following mainboard files had identical Geode LX specific print_conf() implementations: mainboard/amd/db800/mainboard.c mainboard/amd/norwich/mainboard.c mainboard/digitallogic/msm800sev/mainboard.c mainboard/pcengines/alix1c/mainboard.c Move print_conf() to northbridge/amd/lx/northbridge.c where it belongs. Add a copyright notice to mainboard/digitallogic/msm800sev/mainboard.c. Signed-off-by: Carl-Daniel Hailfinger Acked-by: Marc Jones Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3089&device=serengeti_cheetah_fam10&vendor=amd If something broke during this checkin please be a pain in hailfinger's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system From c-d.hailfinger.devel.2006 at gmx.net Tue Feb 5 13:00:33 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Tue, 05 Feb 2008 13:00:33 +0100 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <13426df10802042231m753736aahb0a607d9c7bfdcec@mail.gmail.com> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> <13426df10802032144s3fb5f14bx2f4d67a698e7e90b@mail.gmail.com> <47A789F9.7030701@amd.com> <13426df10802041408p6aee9ab3pa3c94c6a30dfe74b@mail.gmail.com> <47A79F68.3040906@amd.com> <13426df10802042231m753736aahb0a607d9c7bfdcec@mail.gmail.com> Message-ID: <47A84FE1.6050304@gmx.net> On 05.02.2008 07:31, ron minnich wrote: > I think this is fine but I'd like to fit it into the "stage" > nomenclature, so the numbering fits. > > So which stage is this? I am not sure, I feel like the stage numbering > never quite got finished :-) > > possibly stage 3 is load payload, stage 4 is prepare the machine for a > payload, and stage5 is run the payload? > Remember that we load stage 2 like a payload, so we'd have execution order stage 0,1,3,4,5,2,3,4,5,realpayload. Stage 2 is also special because it lives completely in RAM, but it calls a lot of functions in bootblock ROM. If we shadow the boot block, most problems should disappear. One thing I didn't understand: Marc Jones wrote: > Due to some cache coherency snoop problems across pci we need the ROM > cache properties to be write-serialize + cache disabled. The data in ROM doesn't change nor do we write to it. So where exactly do we need write snooping and/or write-serialize? Regards, Carl-Daniel -- http://www.hailfinger.org/ From kononov at dls.net Tue Feb 5 16:48:01 2008 From: kononov at dls.net (Roman Kononov) Date: Tue, 05 Feb 2008 09:48:01 -0600 Subject: [coreboot] Cold reset in Tyan s2912 In-Reply-To: <2ea3fae10802042248y5b94d7bq2ffb426944da8abe@mail.gmail.com> References: <47A7F428.1070704@dls.net> <2ea3fae10802042248y5b94d7bq2ffb426944da8abe@mail.gmail.com> Message-ID: <47A88531.3010204@dls.net> On 2008-02-05 00:48 yhlu said the following: > On Feb 4, 2008 9:29 PM, Roman Kononov wrote: >> I have difficulty cold-resetting Tyan s2912, which has mcp55. >> >> The sequence >> outb(0x2,0xcf9); >> outb(0x6,0xcf9); >> is a warm reset. It does not reset the HyperTransport link frequency and width. > > how do you know? > > do you have other co-processor or htx installed? I have a co-processor. The sequence I hope to have: 1) Power up. Power-on reset. The co-processor takes long time to become alive (~500s). By this time the CPU thinks that the HT link is dead. 2) CPU issues another reset. 3) The CPU re-initializes the HT link and the connection is happy. With the above sequence, the step 3) is a warm reset, and the CPU does not attempt to re-initialize the link. > > YH Roman From kononov at dls.net Tue Feb 5 16:51:38 2008 From: kononov at dls.net (Roman Kononov) Date: Tue, 05 Feb 2008 09:51:38 -0600 Subject: [coreboot] Cold reset in Tyan s2912 In-Reply-To: <47A88531.3010204@dls.net> References: <47A7F428.1070704@dls.net> <2ea3fae10802042248y5b94d7bq2ffb426944da8abe@mail.gmail.com> <47A88531.3010204@dls.net> Message-ID: <47A8860A.8060807@dls.net> On 2008-02-05 09:48 Roman Kononov said the following: > On 2008-02-05 00:48 yhlu said the following: >> On Feb 4, 2008 9:29 PM, Roman Kononov wrote: >>> I have difficulty cold-resetting Tyan s2912, which has mcp55. >>> >>> The sequence >>> outb(0x2,0xcf9); >>> outb(0x6,0xcf9); >>> is a warm reset. It does not reset the HyperTransport link frequency and width. >> how do you know? >> >> do you have other co-processor or htx installed? > > I have a co-processor. > > The sequence I hope to have: > > 1) Power up. Power-on reset. The co-processor takes long time to become > alive (~500s). By this time the CPU thinks that the HT link is dead. ~0.5s here. > 2) CPU issues another reset. > 3) The CPU re-initializes the HT link and the connection is happy. > > With the above sequence, the step 3) is a warm reset, and the CPU does > not attempt to re-initialize the link. > >> YH > > Roman > From joe at smittys.pointclark.net Tue Feb 5 16:51:39 2008 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Tue, 05 Feb 2008 10:51:39 -0500 Subject: [coreboot] Run PCI rom before PCI bus scan?? In-Reply-To: <47A75095.3070109@assembler.cz> References: <20080202203430.1p2at6gtc0skw0so@www.smittys.pointclark.net> <20080203183738.GA4289@coresystems.de> <20080203144443.q9r9b16s00wgk8k0@www.smittys.pointclark.net> <47A62410.90805@gmail.com> <20080203181552.tybs70ow5c4osoo4@www.smittys.pointclark.net> <20080204074936.4q1bevm7ksggowsk@www.smittys.pointclark.net> <47A75095.3070109@assembler.cz> Message-ID: <20080205105139.rhwr4w0eg0gg0wws@www.smittys.pointclark.net> So I found this in the ICH4 datasheet: The LAN controller enters Wake on LAN mode after reset if the Wake on LAN bit in the EEPROM is set *(which it is)*. At this point, the LAN controller is in the D0u state. When the LAN controller is in Wake on LAN mode: ? The LAN controller scans incoming packets for a Magic Packet and asserts the PME# signal for 52 ms when a one is detected in Wake on LAN mode. ? The Activity LED changes its functionality to indicates that the received frame passed Individual Address (IA) filtering or broadcast filtering. ? The PCI Configuration registers are accessible to the host *(this is what I'm looking for!!)*. The LAN controller switches from Wake on LAN mode to the D0a power state following So, if this is correct I think I was right in saying the nic seemed like it was powered off?? At this point I need to figure out how to assert a PME# signal to wake up the nic. Maybe from the Power Managment Control register?? Thanks - Joe From rminnich at gmail.com Tue Feb 5 17:07:08 2008 From: rminnich at gmail.com (ron minnich) Date: Tue, 5 Feb 2008 08:07:08 -0800 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <47A84FE1.6050304@gmx.net> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> <13426df10802032144s3fb5f14bx2f4d67a698e7e90b@mail.gmail.com> <47A789F9.7030701@amd.com> <13426df10802041408p6aee9ab3pa3c94c6a30dfe74b@mail.gmail.com> <47A79F68.3040906@amd.com> <13426df10802042231m753736aahb0a607d9c7bfdcec@mail.gmail.com> <47A84FE1.6050304@gmx.net> Message-ID: <13426df10802050807p5d79cd40la850dbe43de94a64@mail.gmail.com> On Feb 5, 2008 4:00 AM, Carl-Daniel Hailfinger wrote: > > Remember that we load stage 2 like a payload, so we'd have execution > order stage 0,1,3,4,5,2,3,4,5,realpayload. Not if the stage definition is in main. I realized some time ago that arch/x86/stage1.c is misnamed (my fault) -- since it alls all the stages. It's really what we used to call hardwaremain, I wonder if we should just call it coreboot main or something. Marc, is it really possible to shadow bios if it is up in high memory? Or do we have to shadow fxxxx addresses? If we have to shadow fxxxx addresses, then we need to do something like this: assembly First C code calls stage1 disable_car shadow boot block to fxxxx jump to entry point in fxxxx stage 2 payload, run it other code payload jump to payload or not? ron From peter at stuge.se Tue Feb 5 17:44:48 2008 From: peter at stuge.se (Peter Stuge) Date: Tue, 5 Feb 2008 17:44:48 +0100 Subject: [coreboot] Run PCI rom before PCI bus scan?? In-Reply-To: <20080205105139.rhwr4w0eg0gg0wws@www.smittys.pointclark.net> References: <20080202203430.1p2at6gtc0skw0so@www.smittys.pointclark.net> <20080203183738.GA4289@coresystems.de> <20080203144443.q9r9b16s00wgk8k0@www.smittys.pointclark.net> <47A62410.90805@gmail.com> <20080203181552.tybs70ow5c4osoo4@www.smittys.pointclark.net> <20080204074936.4q1bevm7ksggowsk@www.smittys.pointclark.net> <47A75095.3070109@assembler.cz> <20080205105139.rhwr4w0eg0gg0wws@www.smittys.pointclark.net> Message-ID: <20080205164448.26302.qmail@stuge.se> On Tue, Feb 05, 2008 at 10:51:39AM -0500, joe at smittys.pointclark.net wrote: > So I found this in the ICH4 datasheet: > > The LAN controller enters Wake on LAN mode after reset if the Wake > on LAN bit in the EEPROM is set *(which it is)*. You could try changing this bit in the EEPROM before running coreboot and see if you get different results from the PCI scan. > When the LAN controller is in Wake on LAN mode: > ? The LAN controller scans incoming packets for a Magic Packet and > asserts the PME# signal for 52 ms when a one is detected in Wake on > LAN mode. .. > ? The PCI Configuration registers are accessible to the host *(this > is what I'm looking for!!)*. Right, and this says that they are accessible even when the NIC is in WoL mode. > So, if this is correct I think I was right in saying the nic seemed > like it was powered off?? At this point I need to figure out how to > assert a PME# signal to wake up the nic. Maybe from the Power > Managment Control register?? Note that PME# is asserted by the NIC. Ie. PME# is considered an output from the NIC. Remember that Wake on LAN means that the NIC wakes up the computer if a special packet is received. I'm afraid I don't think this is causing the problem you're seeing. :\ //Peter From marc.jones at amd.com Tue Feb 5 18:23:51 2008 From: marc.jones at amd.com (Marc Jones) Date: Tue, 05 Feb 2008 10:23:51 -0700 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <47A84FE1.6050304@gmx.net> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> <13426df10802032144s3fb5f14bx2f4d67a698e7e90b@mail.gmail.com> <47A789F9.7030701@amd.com> <13426df10802041408p6aee9ab3pa3c94c6a30dfe74b@mail.gmail.com> <47A79F68.3040906@amd.com> <13426df10802042231m753736aahb0a607d9c7bfdcec@mail.gmail.com> <47A84FE1.6050304@gmx.net> Message-ID: <47A89BA7.2000509@amd.com> Carl-Daniel Hailfinger wrote: > On 05.02.2008 07:31, ron minnich wrote: >> I think this is fine but I'd like to fit it into the "stage" >> nomenclature, so the numbering fits. >> >> So which stage is this? I am not sure, I feel like the stage numbering >> never quite got finished :-) >> >> possibly stage 3 is load payload, stage 4 is prepare the machine for a >> payload, and stage5 is run the payload? >> > > Remember that we load stage 2 like a payload, so we'd have execution > order stage 0,1,3,4,5,2,3,4,5,realpayload. Stage 2 is also special > because it lives completely in RAM, but it calls a lot of functions in > bootblock ROM. If we shadow the boot block, most problems should disappear. > Since I was working in Stage1.c I assumed it was stage1 and that every other stage is called from stage1. > One thing I didn't understand: > Marc Jones wrote: >> Due to some cache coherency snoop problems across pci we need the ROM >> cache properties to be write-serialize + cache disabled. > > The data in ROM doesn't change nor do we write to it. So where exactly > do we need write snooping and/or write-serialize? The problem is a transaction depth issue and bottlenecks inside the GX and LX that go across PCI. The conditions are very complicated but it comes down to we need write serialization for writes to PCI. If you look in the data book you can't have write serialization and the cache enabled on a given area. During coreboot we don't have to worry about a write or a PCI bus master so I think we can enable caching the ROM. After coreboot we can't be sure what will happen in the system so we need to set it up to be safe. For example flashrom just clears the write protect bit. If the cache were enabled (no write serialization) and flashrom was writing the ROM we would be in a precarious position. A PCI bus master doing a read or a write that has a hit on a tag would cause enough bottleneck conditions that it might hit the bug. We could change flashrom but that doesn't help other tools. We need to leave the system in a safe state. Also, caching the ROM after it is no longer used doesn't make much sense. So, we need a call just before the payload runs to clean up the system. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From marc.jones at amd.com Tue Feb 5 18:42:13 2008 From: marc.jones at amd.com (Marc Jones) Date: Tue, 05 Feb 2008 10:42:13 -0700 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <13426df10802050807p5d79cd40la850dbe43de94a64@mail.gmail.com> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> <13426df10802032144s3fb5f14bx2f4d67a698e7e90b@mail.gmail.com> <47A789F9.7030701@amd.com> <13426df10802041408p6aee9ab3pa3c94c6a30dfe74b@mail.gmail.com> <47A79F68.3040906@amd.com> <13426df10802042231m753736aahb0a607d9c7bfdcec@mail.gmail.com> <47A84FE1.6050304@gmx.net> <13426df10802050807p5d79cd40la850dbe43de94a64@mail.gmail.com> Message-ID: <47A89FF5.4070608@amd.com> ron minnich wrote: > On Feb 5, 2008 4:00 AM, Carl-Daniel Hailfinger > wrote: > >> Remember that we load stage 2 like a payload, so we'd have execution >> order stage 0,1,3,4,5,2,3,4,5,realpayload. > > Not if the stage definition is in main. I realized some time ago that > arch/x86/stage1.c is misnamed (my fault) -- since it alls all the > stages. > > It's really what we used to call hardwaremain, I wonder if we should > just call it coreboot main or something. > I guess you can change the stage names and add a stageX for pre_payloaD() but that seems excessive. > Marc, is it really possible to shadow bios if it is up in high memory? > Or do we have to shadow fxxxx addresses? > It wouldn't have to be there. It could be anywhere in main memory. After memory init in v2 the main coreboot image is copied to low memory and everything is run from there. > If we have to shadow fxxxx addresses, then we need to do something like this: > > assembly > First C code calls stage1 > disable_car > shadow boot block to fxxxx > jump to entry point in fxxxx > stage 2 payload, run it > other code > payload > jump to payload > Instead of a shadow step I would change stage2 to contain the lar other utilities and payload loader for a couple of reasons. It does make stage 2 bigger but you still copy less to memory in the long run. In addition stage2 is compressed so I expect the growth in the ROM image wouldn't be too bad. Another advantage is that the bootblock(stage1.c) would not change as often since it won't do as much (I had to grow it to add the pre_payload call). Also, shadowing steps can be confusing to follow and that would be right in the middle of stage1.c and would grow the bootblock even more. I am not saying we have to shadow. I think the patch I sent is a good enough solution for Geode. I don't want Geode to change the architecture and make things more difficult for CPUs that don't have these limitations. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From yinghailu at gmail.com Tue Feb 5 18:45:36 2008 From: yinghailu at gmail.com (yhlu) Date: Tue, 5 Feb 2008 09:45:36 -0800 Subject: [coreboot] Cold reset in Tyan s2912 In-Reply-To: <47A88531.3010204@dls.net> References: <47A7F428.1070704@dls.net> <2ea3fae10802042248y5b94d7bq2ffb426944da8abe@mail.gmail.com> <47A88531.3010204@dls.net> Message-ID: <2ea3fae10802050945o23031186tade4eaef8049cccb@mail.gmail.com> On Feb 5, 2008 7:48 AM, Roman Kononov wrote: > On 2008-02-05 00:48 yhlu said the following: > > > On Feb 4, 2008 9:29 PM, Roman Kononov wrote: > >> I have difficulty cold-resetting Tyan s2912, which has mcp55. > >> > >> The sequence > >> outb(0x2,0xcf9); > >> outb(0x6,0xcf9); > >> is a warm reset. It does not reset the HyperTransport link frequency and width. > > > > how do you know? > > > > do you have other co-processor or htx installed? > > I have a co-processor. > > The sequence I hope to have: > > 1) Power up. Power-on reset. The co-processor takes long time to become > alive (~500s). By this time the CPU thinks that the HT link is dead. > 2) CPU issues another reset. > 3) The CPU re-initializes the HT link and the connection is happy. > > With the above sequence, the step 3) is a warm reset, and the CPU does > not attempt to re-initialize the link. that is co-processor problem. Please talk the co-processor vendor about that. they have solution for you problem. otherwise return that to get one from another vendor. YH From c.jones at f5.com Tue Feb 5 20:00:31 2008 From: c.jones at f5.com (Clay Jones) Date: Tue, 5 Feb 2008 11:00:31 -0800 Subject: [coreboot] Build error with top of tree V2 Message-ID: Hi, I am getting the following error when building the Serengeti_cheetah_fam10 target: gcc -m32 -nostdlib -nostartfiles -static -o coreboot -T ldscript.ld crt0.o nm -n coreboot | sort > coreboot.map objcopy --gap-fill 0xff -O binary coreboot coreboot.strip cp ../payload.elf payload ./buildrom coreboot.strip coreboot.rom payload 0x3f000 0x7f000 coreboot image is 258104 bytes; only 258048 allowed Coreboot input file larger than allowed size! : Success make[1]: *** [coreboot.rom] Error 2 make[1]: Leaving directory `/home/cjones/coreboot-v2/targets/amd/serengeti_cheetah_fam10/serengeti_ cheetah_fam10/fallback' make: *** [fallback/coreboot.rom] Error 1 cjones at scully:/home/cjones/coreboot-v2/targets/amd/serengeti_cheetah_fam 10/serengeti_cheetah_fam10 The coreboot image is always a little bigger that the space allowed. I have seen this before, but I can't remember what causes it. Anybody know? From r00ter at uboot.com Tue Feb 5 20:04:55 2008 From: r00ter at uboot.com (r00ter at uboot.com) Date: Tue, 5 Feb 2008 19:04:55 +0000 Subject: [coreboot] tyan s2895 how to? Message-ID: <20080205190457.7B014FA605@mail.uboot.com> hello, first, thanks for your work. i'am very interested in your project and want to install coreboot with a kernel as payload on my tyan s2895 and using a addon graphiccard(geforce 6600 gt). my current system is running gentoo (kernel 2.6.24 x64). i read the amd64 doc and want to start. i only want to ask if there's a image of the tyan and a geforce 6600gt. and are there some tutorials in german? or german users or developers who can help me? Thank you ----- community mit gratis blog, chat, video, foto, gallery, sms, mail www.uboot.com From kononov at dls.net Tue Feb 5 20:13:15 2008 From: kononov at dls.net (Roman Kononov) Date: Tue, 05 Feb 2008 13:13:15 -0600 Subject: [coreboot] Cold reset in Tyan s2912 In-Reply-To: <2ea3fae10802050945o23031186tade4eaef8049cccb@mail.gmail.com> References: <47A7F428.1070704@dls.net> <2ea3fae10802042248y5b94d7bq2ffb426944da8abe@mail.gmail.com> <47A88531.3010204@dls.net> <2ea3fae10802050945o23031186tade4eaef8049cccb@mail.gmail.com> Message-ID: <47A8B54B.4020005@dls.net> On 2008-02-05 11:45, yhlu wrote: > On Feb 5, 2008 7:48 AM, Roman Kononov wrote: >> On 2008-02-05 00:48 yhlu said the following: >> >>> On Feb 4, 2008 9:29 PM, Roman Kononov wrote: >>>> I have difficulty cold-resetting Tyan s2912, which has mcp55. >>>> >>>> The sequence >>>> outb(0x2,0xcf9); >>>> outb(0x6,0xcf9); >>>> is a warm reset. It does not reset the HyperTransport link frequency and width. >>> how do you know? >>> >>> do you have other co-processor or htx installed? >> I have a co-processor. >> >> The sequence I hope to have: >> >> 1) Power up. Power-on reset. The co-processor takes long time to become >> alive (~500s). By this time the CPU thinks that the HT link is dead. >> 2) CPU issues another reset. >> 3) The CPU re-initializes the HT link and the connection is happy. >> >> With the above sequence, the step 3) is a warm reset, and the CPU does >> not attempt to re-initialize the link. > > that is co-processor problem. > > Please talk the co-processor vendor about that. they have solution for > you problem. otherwise return that to get one from another vendor. Thanks for the recommendation. Who makes socket F co-processors? Can you tell me how to make the cold reset please? Roman From myles at pel.cs.byu.edu Tue Feb 5 20:29:59 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Tue, 5 Feb 2008 12:29:59 -0700 Subject: [coreboot] Cold reset in Tyan s2912 In-Reply-To: <47A8B54B.4020005@dls.net> References: <47A7F428.1070704@dls.net> <2ea3fae10802042248y5b94d7bq2ffb426944da8abe@mail.gmail.com> <47A88531.3010204@dls.net><2ea3fae10802050945o23031186tade4eaef8049cccb@mail.gmail.com> <47A8B54B.4020005@dls.net> Message-ID: <016a01c8682d$7f916070$4f22040a@chimp> > On 2008-02-05 11:45, yhlu wrote: > > On Feb 5, 2008 7:48 AM, Roman Kononov wrote: > >> On 2008-02-05 00:48 yhlu said the following: > >> > >>> On Feb 4, 2008 9:29 PM, Roman Kononov wrote: > >>>> I have difficulty cold-resetting Tyan s2912, which has mcp55. > >>>> > >>>> The sequence > >>>> outb(0x2,0xcf9); > >>>> outb(0x6,0xcf9); > >>>> is a warm reset. It does not reset the HyperTransport link frequency > and width. > >>> how do you know? > >>> > >>> do you have other co-processor or htx installed? > >> I have a co-processor. > >> > >> The sequence I hope to have: > >> > >> 1) Power up. Power-on reset. The co-processor takes long time to become > >> alive (~500s). By this time the CPU thinks that the HT link is dead. > >> 2) CPU issues another reset. > >> 3) The CPU re-initializes the HT link and the connection is happy. > >> > >> With the above sequence, the step 3) is a warm reset, and the CPU does > >> not attempt to re-initialize the link. > > > > that is co-processor problem. > > > > Please talk the co-processor vendor about that. they have solution for > > you problem. otherwise return that to get one from another vendor. > > Thanks for the recommendation. Who makes socket F co-processors? > > Can you tell me how to make the cold reset please? Isn't there supposed to be a way to use ldtstop to reinitialize the HT link without a cold reset? It seems like I read that it is faster. Myles From marc.jones at amd.com Tue Feb 5 20:39:14 2008 From: marc.jones at amd.com (Marc Jones) Date: Tue, 05 Feb 2008 12:39:14 -0700 Subject: [coreboot] Build error with top of tree V2 In-Reply-To: References: Message-ID: <47A8BB62.6050501@amd.com> Clay Jones wrote: > Hi, > > I am getting the following error when building the > Serengeti_cheetah_fam10 target: > > > gcc -m32 -nostdlib -nostartfiles -static -o coreboot -T ldscript.ld > crt0.o > nm -n coreboot | sort > coreboot.map > objcopy --gap-fill 0xff -O binary coreboot coreboot.strip > cp ../payload.elf payload > ./buildrom coreboot.strip coreboot.rom payload 0x3f000 0x7f000 > coreboot image is 258104 bytes; only 258048 allowed > Coreboot input file larger than allowed size! > : Success > make[1]: *** [coreboot.rom] Error 2 > make[1]: Leaving directory > `/home/cjones/coreboot-v2/targets/amd/serengeti_cheetah_fam10/serengeti_ > cheetah_fam10/fallback' > make: *** [fallback/coreboot.rom] Error 1 > cjones at scully:/home/cjones/coreboot-v2/targets/amd/serengeti_cheetah_fam > 10/serengeti_cheetah_fam10 > > > The coreboot image is always a little bigger that the space allowed. I > have seen this before, but I can't remember what causes it. Anybody > know? > > > Can you post your distribution, gcc version and binutils versions? Are you using buildrom? Did you build a normal image too? did you change the mainboard or target config.lb? I get the following using buildrom on my local directory: ./buildrom coreboot.strip coreboot.rom payload 0x3f000 0x7f000 Payload: 61872 coreboot: 258048 ROM size: 520192 Left space: 200272 Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From corey.osgood at gmail.com Tue Feb 5 20:49:52 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Tue, 5 Feb 2008 14:49:52 -0500 Subject: [coreboot] Run PCI rom before PCI bus scan?? In-Reply-To: <20080205164448.26302.qmail@stuge.se> References: <20080202203430.1p2at6gtc0skw0so@www.smittys.pointclark.net> <20080203183738.GA4289@coresystems.de> <20080203144443.q9r9b16s00wgk8k0@www.smittys.pointclark.net> <47A62410.90805@gmail.com> <20080203181552.tybs70ow5c4osoo4@www.smittys.pointclark.net> <20080204074936.4q1bevm7ksggowsk@www.smittys.pointclark.net> <47A75095.3070109@assembler.cz> <20080205105139.rhwr4w0eg0gg0wws@www.smittys.pointclark.net> <20080205164448.26302.qmail@stuge.se> Message-ID: From kononov at dls.net Tue Feb 5 20:54:06 2008 From: kononov at dls.net (Roman Kononov) Date: Tue, 05 Feb 2008 13:54:06 -0600 Subject: [coreboot] Cold reset in Tyan s2912 In-Reply-To: <016a01c8682d$7f916070$4f22040a@chimp> References: <47A7F428.1070704@dls.net> <2ea3fae10802042248y5b94d7bq2ffb426944da8abe@mail.gmail.com> <47A88531.3010204@dls.net><2ea3fae10802050945o23031186tade4eaef8049cccb@mail.gmail.com> <47A8B54B.4020005@dls.net> <016a01c8682d$7f916070$4f22040a@chimp> Message-ID: <47A8BEDE.7080004@dls.net> On 2008-02-05 13:29, Myles Watson wrote: > Isn't there supposed to be a way to use ldtstop to reinitialize the HT link > without a cold reset? It seems like I read that it is faster. No, ldtstop does not fully reinitialize the link. If the CPU detects a dead link after the cold reset, it will never reinitialize that link. This comes from the experiments. Roman From yinghailu at gmail.com Tue Feb 5 21:18:31 2008 From: yinghailu at gmail.com (yhlu) Date: Tue, 5 Feb 2008 12:18:31 -0800 Subject: [coreboot] Cold reset in Tyan s2912 In-Reply-To: <47A8B54B.4020005@dls.net> References: <47A7F428.1070704@dls.net> <2ea3fae10802042248y5b94d7bq2ffb426944da8abe@mail.gmail.com> <47A88531.3010204@dls.net> <2ea3fae10802050945o23031186tade4eaef8049cccb@mail.gmail.com> <47A8B54B.4020005@dls.net> Message-ID: <2ea3fae10802051218q1276c73dk99d9352a69cc77f1@mail.gmail.com> On Feb 5, 2008 11:13 AM, Roman Kononov wrote: > > On 2008-02-05 11:45, yhlu wrote: > > On Feb 5, 2008 7:48 AM, Roman Kononov wrote: > >> On 2008-02-05 00:48 yhlu said the following: > >> > >>> On Feb 4, 2008 9:29 PM, Roman Kononov wrote: > >>>> I have difficulty cold-resetting Tyan s2912, which has mcp55. > >>>> > >>>> The sequence > >>>> outb(0x2,0xcf9); > >>>> outb(0x6,0xcf9); > >>>> is a warm reset. It does not reset the HyperTransport link frequency and width. > >>> how do you know? > >>> > >>> do you have other co-processor or htx installed? > >> I have a co-processor. > >> > >> The sequence I hope to have: > >> > >> 1) Power up. Power-on reset. The co-processor takes long time to become > >> alive (~500s). By this time the CPU thinks that the HT link is dead. > >> 2) CPU issues another reset. > >> 3) The CPU re-initializes the HT link and the connection is happy. > >> > >> With the above sequence, the step 3) is a warm reset, and the CPU does > >> not attempt to re-initialize the link. > > > > that is co-processor problem. > > > > Please talk the co-processor vendor about that. they have solution for > > you problem. otherwise return that to get one from another vendor. > > Thanks for the recommendation. Who makes socket F co-processors? I don't think there are hundreds of vendors for that. DRC computer? > > Can you tell me how to make the cold reset please? you don't need cold reset. at that case even cold reset doesn't work. YH From kononov at dls.net Tue Feb 5 21:36:27 2008 From: kononov at dls.net (Roman Kononov) Date: Tue, 05 Feb 2008 14:36:27 -0600 Subject: [coreboot] Cold reset in Tyan s2912 In-Reply-To: <2ea3fae10802051218q1276c73dk99d9352a69cc77f1@mail.gmail.com> References: <47A7F428.1070704@dls.net> <2ea3fae10802042248y5b94d7bq2ffb426944da8abe@mail.gmail.com> <47A88531.3010204@dls.net> <2ea3fae10802050945o23031186tade4eaef8049cccb@mail.gmail.com> <47A8B54B.4020005@dls.net> <2ea3fae10802051218q1276c73dk99d9352a69cc77f1@mail.gmail.com> Message-ID: <47A8C8CB.4090109@dls.net> On 2008-02-05 14:18, yhlu wrote: > I don't think there are hundreds of vendors for that. > > DRC computer? They offer only socket 940. > you don't need cold reset. > > at that case even cold reset doesn't work. After "HT Cold Reset" (PWROK deasserted and SYSRST asserted) the CPU reinitializes its links. This is proven. Roman. From libv at skynet.be Tue Feb 5 21:47:18 2008 From: libv at skynet.be (Luc Verhaegen) Date: Tue, 5 Feb 2008 21:47:18 +0100 Subject: [coreboot] flashrom: Add board enable for VIA EPIA SP. Message-ID: <20080205204718.GA32021@skynet.be> Luc Verhaegen. SUSE/Novell X Driver Developer. -------------- next part -------------- Flashrom: Add board enable for VIA EPIA SP. Signed-off-by: Luc Verhaegen Index: board_enable.c =================================================================== --- board_enable.c (revision 3089) +++ board_enable.c (working copy) @@ -3,7 +3,7 @@ * * Copyright (C) 2005-2007 coresystems GmbH * Copyright (C) 2006 Uwe Hermann - * Copyright (C) 2007 Luc Verhaegen + * Copyright (C) 2007-2008 Luc Verhaegen * Copyright (C) 2007 Carl-Daniel Hailfinger * * This program is free software; you can redistribute it and/or modify @@ -213,6 +213,28 @@ } /** + * Suited for VIAs EPIA SP. + */ +static int board_via_epia_sp(const char *name) +{ + struct pci_dev *dev; + uint8_t val; + + dev = pci_dev_find(0x1106, 0x3227); /* VT8237 ISA bridge */ + if (!dev) { + fprintf(stderr, "\nERROR: VT8237 ISA bridge not found.\n"); + return -1; + } + + /* All memory cycles, not just ROM ones, go to LPC */ + val = pci_read_byte(dev, 0x59); + val &= ~0x80; + pci_write_byte(dev, 0x59, val); + + return 0; +} + +/** * Suited for ASUS P5A. * * This is rather nasty code, but there's no way to do this cleanly. @@ -393,6 +415,8 @@ NULL, NULL, "VIA EPIA M/MII/...", board_via_epia_m}, {0x1106, 0x3177, 0x1043, 0x80A1, 0x1106, 0x3205, 0x1043, 0x8118, NULL, NULL, "ASUS A7V8-MX SE", board_asus_a7v8x_mx}, + {0x1106, 0x3227, 0x1106, 0xAA01, 0x1106, 0x0259, 0x1106, 0xAA01, + NULL, NULL, "VIA EPIA SP", board_via_epia_sp}, {0x8086, 0x1076, 0x8086, 0x1176, 0x1106, 0x3059, 0x10f1, 0x2498, NULL, NULL, "Tyan Tomcat K7M", board_asus_a7v8x_mx}, {0x10B9, 0x1541, 0x0000, 0x0000, 0x10B9, 0x1533, 0x0000, 0x0000, From c.jones at f5.com Tue Feb 5 22:07:47 2008 From: c.jones at f5.com (Clay Jones) Date: Tue, 5 Feb 2008 13:07:47 -0800 Subject: [coreboot] Build error with top of tree V2 In-Reply-To: <47A8BB62.6050501@amd.com> References: <47A8BB62.6050501@amd.com> Message-ID: I am using buildrom and have built with the following tools on centos 4.4 (redhat): gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3) GNU Make 3.80 GNU ld version 2.15.92.0.2 20040927 GNU objcopy 2.15.92.0.2 20040927 -----Original Message----- From: Marc Jones [mailto:marc.jones at amd.com] Sent: Tuesday, February 05, 2008 11:39 AM To: Clay Jones Cc: coreboot at coreboot.org Subject: Re: [coreboot] Build error with top of tree V2 Clay Jones wrote: > Hi, > > I am getting the following error when building the > Serengeti_cheetah_fam10 target: > > > gcc -m32 -nostdlib -nostartfiles -static -o coreboot -T ldscript.ld > crt0.o > nm -n coreboot | sort > coreboot.map > objcopy --gap-fill 0xff -O binary coreboot coreboot.strip > cp ../payload.elf payload > ./buildrom coreboot.strip coreboot.rom payload 0x3f000 0x7f000 > coreboot image is 258104 bytes; only 258048 allowed > Coreboot input file larger than allowed size! > : Success > make[1]: *** [coreboot.rom] Error 2 > make[1]: Leaving directory > `/home/cjones/coreboot-v2/targets/amd/serengeti_cheetah_fam10/serengeti_ > cheetah_fam10/fallback' > make: *** [fallback/coreboot.rom] Error 1 > cjones at scully:/home/cjones/coreboot-v2/targets/amd/serengeti_cheetah_fam > 10/serengeti_cheetah_fam10 > > > The coreboot image is always a little bigger that the space allowed. I > have seen this before, but I can't remember what causes it. Anybody > know? > > > Can you post your distribution, gcc version and binutils versions? Are you using buildrom? Did you build a normal image too? did you change the mainboard or target config.lb? I get the following using buildrom on my local directory: ./buildrom coreboot.strip coreboot.rom payload 0x3f000 0x7f000 Payload: 61872 coreboot: 258048 ROM size: 520192 Left space: 200272 Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. From myles at pel.cs.byu.edu Tue Feb 5 22:20:06 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Tue, 5 Feb 2008 14:20:06 -0700 Subject: [coreboot] Coreboot-v2 patch rom names Message-ID: <2831fecf0802051320h8e96311k6bc636cf6856163d@mail.gmail.com> This patch changes all rom names that aren't coreboot.rom in Config.lb files. I think that since the directory specifies the architecture and the board, it is redundant information to name it something else, and it makes it more difficult to automate the build process (buildrom). In buildrom we should just use Config-options.lb files instead of patching or keeping our own. It just adds more to maintain, with very little benefit. The correct place for Config.lb files is in the coreboot-v2 tree. The next patch would add Config-lab.lb files for each architecture supported by buildrom. Another patch would change buildrom to stop patching Config.lb files. There is already a CBV2_CONFIG variable that would work nicely for selecting the correct file. Comments? Signed-off-by: Myles Watson -------------- next part -------------- A non-text attachment was scrubbed... Name: coreboot.rom.patch Type: text/x-patch Size: 5324 bytes Desc: not available URL: From myles at pel.cs.byu.edu Tue Feb 5 22:20:06 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Tue, 5 Feb 2008 14:20:06 -0700 Subject: [coreboot] Coreboot-v2 patch rom names Message-ID: <2831fecf0802051320h8e96311k6bc636cf6856163d@mail.gmail.com> This patch changes all rom names that aren't coreboot.rom in Config.lb files. I think that since the directory specifies the architecture and the board, it is redundant information to name it something else, and it makes it more difficult to automate the build process (buildrom). In buildrom we should just use Config-options.lb files instead of patching or keeping our own. It just adds more to maintain, with very little benefit. The correct place for Config.lb files is in the coreboot-v2 tree. The next patch would add Config-lab.lb files for each architecture supported by buildrom. Another patch would change buildrom to stop patching Config.lb files. There is already a CBV2_CONFIG variable that would work nicely for selecting the correct file. Comments? Signed-off-by: Myles Watson -------------- next part -------------- A non-text attachment was scrubbed... Name: coreboot.rom.patch Type: text/x-patch Size: 5324 bytes Desc: not available URL: From jordan.crouse at amd.com Tue Feb 5 22:48:51 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Tue, 5 Feb 2008 14:48:51 -0700 Subject: [coreboot] Coreboot-v2 patch rom names In-Reply-To: <2831fecf0802051320h8e96311k6bc636cf6856163d@mail.gmail.com> References: <2831fecf0802051320h8e96311k6bc636cf6856163d@mail.gmail.com> Message-ID: <20080205214851.GA14674@cosmic.amd.com> On 05/02/08 14:20 -0700, Myles Watson wrote: > This patch changes all rom names that aren't coreboot.rom in Config.lb files. > > I think that since the directory specifies the architecture and the > board, it is redundant information to name it something else, and it > makes it more difficult to automate the build process (buildrom). > > In buildrom we should just use Config-options.lb files instead of > patching or keeping our own. It just adds more to maintain, with very > little benefit. The correct place for Config.lb files is in the > coreboot-v2 tree. > > The next patch would add Config-lab.lb files for each architecture > supported by buildrom. Another patch would change buildrom to stop > patching Config.lb files. There is already a CBV2_CONFIG variable > that would work nicely for selecting the correct file. > > Comments? > > Signed-off-by: Myles Watson Acked-by: Jordan Crouse Are you going to patch buildrom to remove the ROM name stuff too? If so, I ack it now if I don't see it until later. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From svn at coreboot.org Tue Feb 5 22:53:15 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Tue, 5 Feb 2008 22:53:15 +0100 Subject: [coreboot] r3090 - in trunk/coreboot-v2/targets: agami/aruma amd/db800 amd/norwich amd/serengeti_cheetah_fam10 arima/hdama artecgroup/dbe61 emulation/qemu-i386 msi/ms9185 msi/ms9282 newisys/khepri technologic/ts5300 Message-ID: Author: myles Date: 2008-02-05 22:53:15 +0100 (Tue, 05 Feb 2008) New Revision: 3090 Modified: trunk/coreboot-v2/targets/agami/aruma/Config.lb trunk/coreboot-v2/targets/agami/aruma/Config1M.lb trunk/coreboot-v2/targets/amd/db800/Config.lb trunk/coreboot-v2/targets/amd/norwich/Config.lb trunk/coreboot-v2/targets/amd/serengeti_cheetah_fam10/Config.lb trunk/coreboot-v2/targets/arima/hdama/Config.kernelimage.lb trunk/coreboot-v2/targets/artecgroup/dbe61/Config.lb trunk/coreboot-v2/targets/emulation/qemu-i386/Config-abuild.lb trunk/coreboot-v2/targets/emulation/qemu-i386/Config.lb trunk/coreboot-v2/targets/msi/ms9185/Config.lb trunk/coreboot-v2/targets/msi/ms9282/Config.lb trunk/coreboot-v2/targets/newisys/khepri/Config.lb trunk/coreboot-v2/targets/technologic/ts5300/Config.lb Log: This patch changes all rom names that aren't coreboot.rom in Config.lb files. I think that since the directory specifies the architecture and the board, it is redundant information to name it something else, and it makes it more difficult to automate the build process (buildrom). Signed-off-by: Myles Watson Acked-by: Jordan Crouse Modified: trunk/coreboot-v2/targets/agami/aruma/Config.lb =================================================================== --- trunk/coreboot-v2/targets/agami/aruma/Config.lb 2008-02-05 09:21:46 UTC (rev 3089) +++ trunk/coreboot-v2/targets/agami/aruma/Config.lb 2008-02-05 21:53:15 UTC (rev 3090) @@ -26,4 +26,4 @@ payload ../../../../../../filo.elf end -buildrom ./agami_aruma.rom ROM_SIZE "normal" "fallback" +buildrom ./coreboot.rom ROM_SIZE "normal" "fallback" Modified: trunk/coreboot-v2/targets/agami/aruma/Config1M.lb =================================================================== --- trunk/coreboot-v2/targets/agami/aruma/Config1M.lb 2008-02-05 09:21:46 UTC (rev 3089) +++ trunk/coreboot-v2/targets/agami/aruma/Config1M.lb 2008-02-05 21:53:15 UTC (rev 3090) @@ -21,4 +21,4 @@ payload ../../../../../../linux.elf end -buildrom ./agami_aruma.rom ROM_SIZE "fallback" +buildrom ./coreboot.rom ROM_SIZE "fallback" Modified: trunk/coreboot-v2/targets/amd/db800/Config.lb =================================================================== --- trunk/coreboot-v2/targets/amd/db800/Config.lb 2008-02-05 09:21:46 UTC (rev 3089) +++ trunk/coreboot-v2/targets/amd/db800/Config.lb 2008-02-05 21:53:15 UTC (rev 3090) @@ -46,4 +46,4 @@ payload ../payload.elf end -buildrom ./db800.rom ROM_SIZE "fallback" +buildrom ./coreboot.rom ROM_SIZE "fallback" Modified: trunk/coreboot-v2/targets/amd/norwich/Config.lb =================================================================== --- trunk/coreboot-v2/targets/amd/norwich/Config.lb 2008-02-05 09:21:46 UTC (rev 3089) +++ trunk/coreboot-v2/targets/amd/norwich/Config.lb 2008-02-05 21:53:15 UTC (rev 3090) @@ -46,4 +46,4 @@ payload ../payload.elf end -buildrom ./norwich.rom ROM_SIZE "fallback" +buildrom ./coreboot.rom ROM_SIZE "fallback" Modified: trunk/coreboot-v2/targets/amd/serengeti_cheetah_fam10/Config.lb =================================================================== --- trunk/coreboot-v2/targets/amd/serengeti_cheetah_fam10/Config.lb 2008-02-05 09:21:46 UTC (rev 3089) +++ trunk/coreboot-v2/targets/amd/serengeti_cheetah_fam10/Config.lb 2008-02-05 21:53:15 UTC (rev 3090) @@ -65,6 +65,6 @@ option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Failover" end -#buildrom ./amd-cheetah-fam10.rom ROM_SIZE "normal" "fallback" "failover" -buildrom ./amd-cheetah-fam10.rom ROM_SIZE "fallback" "failover" +#buildrom ./coreboot.rom ROM_SIZE "normal" "fallback" "failover" +buildrom ./coreboot.rom ROM_SIZE "fallback" "failover" Modified: trunk/coreboot-v2/targets/arima/hdama/Config.kernelimage.lb =================================================================== --- trunk/coreboot-v2/targets/arima/hdama/Config.kernelimage.lb 2008-02-05 09:21:46 UTC (rev 3089) +++ trunk/coreboot-v2/targets/arima/hdama/Config.kernelimage.lb 2008-02-05 21:53:15 UTC (rev 3090) @@ -100,4 +100,4 @@ # payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf end -buildrom ./luxbios.rom ROM_SIZE "fallback" +buildrom ./coreboot.rom ROM_SIZE "fallback" Modified: trunk/coreboot-v2/targets/artecgroup/dbe61/Config.lb =================================================================== --- trunk/coreboot-v2/targets/artecgroup/dbe61/Config.lb 2008-02-05 09:21:46 UTC (rev 3089) +++ trunk/coreboot-v2/targets/artecgroup/dbe61/Config.lb 2008-02-05 21:53:15 UTC (rev 3090) @@ -31,4 +31,4 @@ payload ../payload.elf end -buildrom ./dbe61.rom ROM_SIZE "fallback" +buildrom ./coreboot.rom ROM_SIZE "fallback" Modified: trunk/coreboot-v2/targets/emulation/qemu-i386/Config-abuild.lb =================================================================== --- trunk/coreboot-v2/targets/emulation/qemu-i386/Config-abuild.lb 2008-02-05 09:21:46 UTC (rev 3089) +++ trunk/coreboot-v2/targets/emulation/qemu-i386/Config-abuild.lb 2008-02-05 21:53:15 UTC (rev 3090) @@ -18,5 +18,5 @@ payload __PAYLOAD__ end -buildrom ./qemu-bios.rom ROM_SIZE "image" +buildrom ./coreboot.rom ROM_SIZE "image" Modified: trunk/coreboot-v2/targets/emulation/qemu-i386/Config.lb =================================================================== --- trunk/coreboot-v2/targets/emulation/qemu-i386/Config.lb 2008-02-05 09:21:46 UTC (rev 3089) +++ trunk/coreboot-v2/targets/emulation/qemu-i386/Config.lb 2008-02-05 21:53:15 UTC (rev 3090) @@ -16,5 +16,5 @@ payload /home/stepan/core.img end -buildrom ./qemu-bios.rom ROM_SIZE "image" +buildrom ./coreboot.rom ROM_SIZE "image" Modified: trunk/coreboot-v2/targets/msi/ms9185/Config.lb =================================================================== --- trunk/coreboot-v2/targets/msi/ms9185/Config.lb 2008-02-05 09:21:46 UTC (rev 3089) +++ trunk/coreboot-v2/targets/msi/ms9185/Config.lb 2008-02-05 21:53:15 UTC (rev 3090) @@ -91,4 +91,4 @@ # payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_com2.zelf end -buildrom ./ms9185.lxb ROM_SIZE "normal" "fallback" +buildrom ./coreboot.rom ROM_SIZE "normal" "fallback" Modified: trunk/coreboot-v2/targets/msi/ms9282/Config.lb =================================================================== --- trunk/coreboot-v2/targets/msi/ms9282/Config.lb 2008-02-05 09:21:46 UTC (rev 3089) +++ trunk/coreboot-v2/targets/msi/ms9282/Config.lb 2008-02-05 21:53:15 UTC (rev 3090) @@ -88,4 +88,4 @@ # payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_com2.zelf end -buildrom ./ms9282.lxb ROM_SIZE "normal" "fallback" +buildrom ./coreboot.rom ROM_SIZE "normal" "fallback" Modified: trunk/coreboot-v2/targets/newisys/khepri/Config.lb =================================================================== --- trunk/coreboot-v2/targets/newisys/khepri/Config.lb 2008-02-05 09:21:46 UTC (rev 3089) +++ trunk/coreboot-v2/targets/newisys/khepri/Config.lb 2008-02-05 21:53:15 UTC (rev 3090) @@ -42,4 +42,4 @@ payload ../../../payloads/tg3--ide_disk.zelf end -buildrom ./khepri.rom ROM_SIZE "normal" "fallback" +buildrom ./coreboot.rom ROM_SIZE "normal" "fallback" Modified: trunk/coreboot-v2/targets/technologic/ts5300/Config.lb =================================================================== --- trunk/coreboot-v2/targets/technologic/ts5300/Config.lb 2008-02-05 09:21:46 UTC (rev 3089) +++ trunk/coreboot-v2/targets/technologic/ts5300/Config.lb 2008-02-05 21:53:15 UTC (rev 3090) @@ -29,4 +29,4 @@ payload /home/stepan/filo-ts5300.elf end -buildrom ./technologic_ts5300.rom ROM_SIZE "fallback" +buildrom ./coreboot.rom ROM_SIZE "fallback" From c.jones at f5.com Tue Feb 5 23:10:42 2008 From: c.jones at f5.com (Clay Jones) Date: Tue, 5 Feb 2008 14:10:42 -0800 Subject: [coreboot] Build error with top of tree V2 In-Reply-To: References: <47A8BB62.6050501@amd.com> Message-ID: I found the problem. The wrong ar command was being used because the make file does not have " $(CROSS_COMPILE)" in front of the ar command. -----Original Message----- From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Clay Jones Sent: Tuesday, February 05, 2008 1:08 PM To: Marc Jones Cc: coreboot at coreboot.org Subject: Re: [coreboot] Build error with top of tree V2 I am using buildrom and have built with the following tools on centos 4.4 (redhat): gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3) GNU Make 3.80 GNU ld version 2.15.92.0.2 20040927 GNU objcopy 2.15.92.0.2 20040927 -----Original Message----- From: Marc Jones [mailto:marc.jones at amd.com] Sent: Tuesday, February 05, 2008 11:39 AM To: Clay Jones Cc: coreboot at coreboot.org Subject: Re: [coreboot] Build error with top of tree V2 Clay Jones wrote: > Hi, > > I am getting the following error when building the > Serengeti_cheetah_fam10 target: > > > gcc -m32 -nostdlib -nostartfiles -static -o coreboot -T ldscript.ld > crt0.o > nm -n coreboot | sort > coreboot.map > objcopy --gap-fill 0xff -O binary coreboot coreboot.strip > cp ../payload.elf payload > ./buildrom coreboot.strip coreboot.rom payload 0x3f000 0x7f000 > coreboot image is 258104 bytes; only 258048 allowed > Coreboot input file larger than allowed size! > : Success > make[1]: *** [coreboot.rom] Error 2 > make[1]: Leaving directory > `/home/cjones/coreboot-v2/targets/amd/serengeti_cheetah_fam10/serengeti_ > cheetah_fam10/fallback' > make: *** [fallback/coreboot.rom] Error 1 > cjones at scully:/home/cjones/coreboot-v2/targets/amd/serengeti_cheetah_fam > 10/serengeti_cheetah_fam10 > > > The coreboot image is always a little bigger that the space allowed. I > have seen this before, but I can't remember what causes it. Anybody > know? > > > Can you post your distribution, gcc version and binutils versions? Are you using buildrom? Did you build a normal image too? did you change the mainboard or target config.lb? I get the following using buildrom on my local directory: ./buildrom coreboot.strip coreboot.rom payload 0x3f000 0x7f000 Payload: 61872 coreboot: 258048 ROM size: 520192 Left space: 200272 Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. -- coreboot mailing list coreboot at coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot From marc.jones at amd.com Tue Feb 5 23:19:17 2008 From: marc.jones at amd.com (Marc Jones) Date: Tue, 05 Feb 2008 15:19:17 -0700 Subject: [coreboot] Build error with top of tree V2 In-Reply-To: References: <47A8BB62.6050501@amd.com> Message-ID: <47A8E0E5.80705@amd.com> Clay Jones wrote: > I found the problem. The wrong ar command was being used because the > make file does not have " $(CROSS_COMPILE)" in front of the ar command. > Good catch! Which file or can you send a patch? Thanks, Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From c-d.hailfinger.devel.2006 at gmx.net Tue Feb 5 23:41:20 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Tue, 05 Feb 2008 23:41:20 +0100 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <47A89BA7.2000509@amd.com> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> <13426df10802032144s3fb5f14bx2f4d67a698e7e90b@mail.gmail.com> <47A789F9.7030701@amd.com> <13426df10802041408p6aee9ab3pa3c94c6a30dfe74b@mail.gmail.com> <47A79F68.3040906@amd.com> <13426df10802042231m753736aahb0a607d9c7bfdcec@mail.gmail.com> <47A84FE1.6050304@gmx.net> <47A89BA7.2000509@amd.com> Message-ID: <47A8E610.7070303@gmx.net> On 05.02.2008 18:23, Marc Jones wrote: > Carl-Daniel Hailfinger wrote: >> On 05.02.2008 07:31, ron minnich wrote: >>> I think this is fine but I'd like to fit it into the "stage" >>> nomenclature, so the numbering fits. >>> >>> So which stage is this? I am not sure, I feel like the stage numbering >>> never quite got finished :-) >>> >>> possibly stage 3 is load payload, stage 4 is prepare the machine for a >>> payload, and stage5 is run the payload? >> >> Remember that we load stage 2 like a payload, so we'd have execution >> order stage 0,1,3,4,5,2,3,4,5,realpayload. Stage 2 is also special >> because it lives completely in RAM, but it calls a lot of functions in >> bootblock ROM. If we shadow the boot block, most problems should >> disappear. > > Since I was working in Stage1.c I assumed it was stage1 and that every > other stage is called from stage1. Fully agreed. >> One thing I didn't understand: >> Marc Jones wrote: >>> Due to some cache coherency snoop problems across pci we need the ROM >>> cache properties to be write-serialize + cache disabled. >> >> The data in ROM doesn't change nor do we write to it. So where exactly >> do we need write snooping and/or write-serialize? > > The problem is a transaction depth issue and bottlenecks inside the GX > and LX that go across PCI. The conditions are very complicated but it > comes down to we need write serialization for writes to PCI. If you > look in the data book you can't have write serialization and the cache > enabled on a given area. During coreboot we don't have to worry about > a write or a PCI bus master so I think we can enable caching the ROM. > After coreboot we can't be sure what will happen in the system so we > need to set it up to be safe. For example flashrom just clears the > write protect bit. If the cache were enabled (no write serialization) > and flashrom was writing the ROM we would be in a precarious position. > A PCI bus master doing a read or a write that has a hit on a tag > would cause enough bottleneck conditions that it might hit the bug. We > could change flashrom but that doesn't help other tools. We need to > leave the system in a safe state. Also, caching the ROM after it is no > longer used doesn't make much sense. So, we need a call just before > the payload runs to clean up the system. Thanks for the explanation. So this final cleanup need not be applied for stage2, only for the real payload because we don't know what the payload may do. Regards, Carl-Daniel From info at coresystems.de Tue Feb 5 23:42:16 2008 From: info at coresystems.de (coreboot information) Date: Tue, 05 Feb 2008 23:42:16 +0100 Subject: [coreboot] r3090 build service Message-ID: Dear coreboot readers! This is the automated build check service of coreboot. The developer "myles" checked in revision 3090 to the coreboot source repository and caused the following changes: Change Log: This patch changes all rom names that aren't coreboot.rom in Config.lb files. I think that since the directory specifies the architecture and the board, it is redundant information to name it something else, and it makes it more difficult to automate the build process (buildrom). Signed-off-by: Myles Watson Acked-by: Jordan Crouse Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3090&device=serengeti_cheetah_fam10&vendor=amd If something broke during this checkin please be a pain in myles's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system From c-d.hailfinger.devel.2006 at gmx.net Tue Feb 5 23:44:20 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Tue, 05 Feb 2008 23:44:20 +0100 Subject: [coreboot] Build error with top of tree V2 In-Reply-To: References: Message-ID: <47A8E6C4.3010408@gmx.net> Hi Clay, On 05.02.2008 20:00, Clay Jones wrote: > I am getting the following error when building the > Serengeti_cheetah_fam10 target: > > gcc -m32 -nostdlib -nostartfiles -static -o coreboot -T ldscript.ld > crt0.o > nm -n coreboot | sort > coreboot.map > objcopy --gap-fill 0xff -O binary coreboot coreboot.strip > cp ../payload.elf payload > ./buildrom coreboot.strip coreboot.rom payload 0x3f000 0x7f000 > coreboot image is 258104 bytes; only 258048 allowed > Coreboot input file larger than allowed size! > : Success > make[1]: *** [coreboot.rom] Error 2 > make[1]: Leaving directory > `/home/cjones/coreboot-v2/targets/amd/serengeti_cheetah_fam10/serengeti_ > cheetah_fam10/fallback' > make: *** [fallback/coreboot.rom] Error 1 > cjones at scully:/home/cjones/coreboot-v2/targets/amd/serengeti_cheetah_fam > 10/serengeti_cheetah_fam10 > > > The coreboot image is always a little bigger that the space allowed. I > have seen this before, but I can't remember what causes it. Anybody > know? > gcc generates bigger code than expected. Another gcc version might help, although tweaking the expected size will work as well. Regards, Carl-Daniel From rminnich at gmail.com Tue Feb 5 23:44:33 2008 From: rminnich at gmail.com (ron minnich) Date: Tue, 5 Feb 2008 14:44:33 -0800 Subject: [coreboot] v3 Message-ID: <13426df10802051444w6376c67bsf1b6c651a5662758@mail.gmail.com> An assumption on v3 going on was that we could run out of ROM, and be fast, since caches are our friend. That assumption is not working out. Here is another possible design. stage 0, running in ROM, turns on CAR and runs initram in the LAR. initram disables car, copies ALL of LAR to top of memory (defined as Top Of Ram - size of LAR) initram finds stage2 in LAR, uncompresses to RAM, jumps to it. stage2 finds stage3 in LAR, uncompresses to RAM, runs it. stage3 finds payload in LAR, uncompresses to RAM, runs it. So we go to a chain model instead of call/return. We stop using ROM-based code due to performance problems. Comments? ron From marc.jones at amd.com Tue Feb 5 23:47:51 2008 From: marc.jones at amd.com (Marc Jones) Date: Tue, 05 Feb 2008 15:47:51 -0700 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <47A8E610.7070303@gmx.net> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> <13426df10802032144s3fb5f14bx2f4d67a698e7e90b@mail.gmail.com> <47A789F9.7030701@amd.com> <13426df10802041408p6aee9ab3pa3c94c6a30dfe74b@mail.gmail.com> <47A79F68.3040906@amd.com> <13426df10802042231m753736aahb0a607d9c7bfdcec@mail.gmail.com> <47A84FE1.6050304@gmx.net> <47A89BA7.2000509@amd.com> <47A8E610.7070303@gmx.net> Message-ID: <47A8E797.8050805@amd.com> Carl-Daniel Hailfinger wrote: > On 05.02.2008 18:23, Marc Jones wrote: >> Carl-Daniel Hailfinger wrote: > > Thanks for the explanation. So this final cleanup need not be applied > for stage2, only for the real payload because we don't know what the > payload may do. > > Correct. That was what my patch was supposed to do. There is still the question of the best place to call. I put it in mainboard so each platform would have a chance at last minute fixups. In Geode case, it could go in the northbride/cpu code.... Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From c.jones at f5.com Wed Feb 6 00:13:54 2008 From: c.jones at f5.com (Clay Jones) Date: Tue, 5 Feb 2008 15:13:54 -0800 Subject: [coreboot] Build error with top of tree V2 In-Reply-To: <47A8E0E5.80705@amd.com> References: <47A8BB62.6050501@amd.com> <47A8E0E5.80705@amd.com> Message-ID: I think it is buildtarget that creates the make file. I haven't looked for it yet. -----Original Message----- From: Marc Jones [mailto:marc.jones at amd.com] Sent: Tuesday, February 05, 2008 2:19 PM To: Clay Jones Cc: coreboot at coreboot.org Subject: Re: [coreboot] Build error with top of tree V2 Clay Jones wrote: > I found the problem. The wrong ar command was being used because the > make file does not have " $(CROSS_COMPILE)" in front of the ar command. > Good catch! Which file or can you send a patch? Thanks, Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From kononov at dls.net Wed Feb 6 00:29:15 2008 From: kononov at dls.net (Roman Kononov) Date: Tue, 05 Feb 2008 17:29:15 -0600 Subject: [coreboot] Cold reset in Tyan s2912 In-Reply-To: <47A88531.3010204@dls.net> References: <47A7F428.1070704@dls.net> <2ea3fae10802042248y5b94d7bq2ffb426944da8abe@mail.gmail.com> <47A88531.3010204@dls.net> Message-ID: <47A8F14B.6040601@dls.net> On 2008-02-05 09:48, Roman Kononov wrote: > I have a co-processor. > > The sequence I hope to have: > > 1) Power up. Power-on reset. The co-processor takes long time to become > alive (~500s). By this time the CPU thinks that the HT link is dead. > 2) CPU issues another reset. > 3) The CPU re-initializes the HT link and the connection is happy. > > With the above sequence, the step 3) is a warm reset, and the CPU does > not attempt to re-initialize the link. Never mind. I found the way to make the reset long enough. Thanks, Roman From c-d.hailfinger.devel.2006 at gmx.net Wed Feb 6 01:21:10 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 06 Feb 2008 01:21:10 +0100 Subject: [coreboot] v3 In-Reply-To: <13426df10802051444w6376c67bsf1b6c651a5662758@mail.gmail.com> References: <13426df10802051444w6376c67bsf1b6c651a5662758@mail.gmail.com> Message-ID: <47A8FD76.2050802@gmx.net> On 05.02.2008 23:44, ron minnich wrote: > An assumption on v3 going on was that we could run out of ROM, and be > fast, since caches are our friend. > > That assumption is not working out. Here is another possible design. > > stage 0, running in ROM, turns on CAR and runs initram in the LAR. > > initram disables car, copies ALL of LAR to top of memory (defined as > Top Of Ram - size of LAR) > I hope you mean 4G - size of LAR. Otherwise we have to compile a lot of code as relocatable or duplicate it. Our boot block will become a very bloated blob with PIC and non-PIC mixed and lots of access wrappers. (And Segher will explode... ;-)) > initram finds stage2 in LAR, uncompresses to RAM, jumps to it. > > stage2 finds stage3 in LAR, uncompresses to RAM, runs it. > > stage3 finds payload in LAR, uncompresses to RAM, runs it. > > So we go to a chain model instead of call/return. > Sorry, but that is horrible.That way every stage has to call lar functions and we possibly have to integrate a dynamic linker into v3. > We stop using ROM-based code due to performance problems. > I like Marc's approach of enabling failsafe settings directly before payload execution a lot more. ROM is cacheable as long as we control the environment. But your shadowing idea is definitely an avenue to explore. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Wed Feb 6 01:43:53 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 06 Feb 2008 01:43:53 +0100 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <47A79F68.3040906@amd.com> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> <13426df10802032144s3fb5f14bx2f4d67a698e7e90b@mail.gmail.com> <47A789F9.7030701@amd.com> <13426df10802041408p6aee9ab3pa3c94c6a30dfe74b@mail.gmail.com> <47A79F68.3040906@amd.com> Message-ID: <47A902C9.30001@gmx.net> On 05.02.2008 00:27, Marc Jones wrote: > ron minnich wrote: >> Why can't we shadow? > > We could. Even at the top of the 4G address range? If that is possible, I'd vote to shadow the bootblock only to save RAM. Some comments on the patch: > Cache the ROM to speed up stage2 and payload decompression. > > Due to some cache coherency snoop problems across PCI GeodeLc needs the ROM cache properties to be write-serialize + cache disabled by runtime. > Add pre_payload() call to each mainboard as the final coreboot function before the payload is called. > > Signed-off by: Marc Jones > > Index: coreboot-v3/northbridge/amd/geodelx/geodelxinit.c > =================================================================== > --- coreboot-v3.orig/northbridge/amd/geodelx/geodelxinit.c 2008-02-04 13:35:52.000000000 -0700 > +++ coreboot-v3/northbridge/amd/geodelx/geodelxinit.c 2008-02-04 13:36:12.000000000 -0700 > @@ -658,7 +658,7 @@ > #define SYSMEM_RCONF_WRITETHROUGH 8 > #define DEVRC_RCONF_DEFAULT 0x21 > #define ROMBASE_RCONF_DEFAULT 0xFFFC0000 > -#define ROMRC_RCONF_DEFAULT 0x25 > +#define ROMRC_RCONF_DEFAULT 0x04 > Maybe keep the 0x25 as ROMRC_RCONF_SAFE? > > /** > * TODO. > Index: coreboot-v3/mainboard/adl/msm800sev/stage1.c > =================================================================== > --- coreboot-v3.orig/mainboard/adl/msm800sev/stage1.c 2008-02-04 15:41:14.000000000 -0700 > +++ coreboot-v3/mainboard/adl/msm800sev/stage1.c 2008-02-04 15:50:04.000000000 -0700 > @@ -53,3 +53,15 @@ > cs5536_disable_internal_uart(); > w83627hf_enable_serial(0x2e, SERIAL_DEV, SERIAL_IOBASE); > } > + > +void pre_payload(void) > +{ > + struct msr msr; > + > + /* Set ROM cache properties for runtime. */ > + msr = rdmsr(CPU_RCONF_DEFAULT); > + msr.hi &= ~(0xFF << 24); // clear ROMRC > + msr.hi |= 0x25 << 24; // set WS, CD, WP > Use ROMRC_RCONF_SAFE instead of 0x25? > + wrmsr(CPU_RCONF_DEFAULT, msr); > + banner(BIOS_DEBUG, "pre_payload: done"); > +} pre_payload() is not board specific, but Geode LX-specific. geodelxinit.c may be a more appropriate location. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Wed Feb 6 01:47:28 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 06 Feb 2008 01:47:28 +0100 Subject: [coreboot] v3 In-Reply-To: <47A8FD76.2050802@gmx.net> References: <13426df10802051444w6376c67bsf1b6c651a5662758@mail.gmail.com> <47A8FD76.2050802@gmx.net> Message-ID: <47A903A0.2060303@gmx.net> I'm sorry. I just reread my mail and realized the tone didn't come out right. I wish to apologize if this caused any irritation. Regards, Carl-Daniel On 06.02.2008 01:21, Carl-Daniel Hailfinger wrote: > On 05.02.2008 23:44, ron minnich wrote: > >> An assumption on v3 going on was that we could run out of ROM, and be >> fast, since caches are our friend. >> >> That assumption is not working out. Here is another possible design. >> >> stage 0, running in ROM, turns on CAR and runs initram in the LAR. >> >> initram disables car, copies ALL of LAR to top of memory (defined as >> Top Of Ram - size of LAR) >> >> > > I hope you mean 4G - size of LAR. Otherwise we have to compile a lot of > code as relocatable or duplicate it. Our boot block will become a very > bloated blob with PIC and non-PIC mixed and lots of access wrappers. > (And Segher will explode... ;-)) > > >> initram finds stage2 in LAR, uncompresses to RAM, jumps to it. >> >> stage2 finds stage3 in LAR, uncompresses to RAM, runs it. >> >> stage3 finds payload in LAR, uncompresses to RAM, runs it. >> >> So we go to a chain model instead of call/return. >> >> > > Sorry, but that is horrible.That way every stage has to call lar > functions and we possibly have to integrate a dynamic linker into v3. > Please disregard the dynamic linker comment. >> We stop using ROM-based code due to performance problems. >> > > I like Marc's approach of enabling failsafe settings directly before > payload execution a lot more. ROM is cacheable as long as we control the > environment. > > But your shadowing idea is definitely an avenue to explore. > > Regards, > Carl-Daniel > > -- http://www.hailfinger.org/ From rminnich at gmail.com Wed Feb 6 01:48:36 2008 From: rminnich at gmail.com (ron minnich) Date: Tue, 5 Feb 2008 16:48:36 -0800 Subject: [coreboot] v3 In-Reply-To: <47A903A0.2060303@gmx.net> References: <13426df10802051444w6376c67bsf1b6c651a5662758@mail.gmail.com> <47A8FD76.2050802@gmx.net> <47A903A0.2060303@gmx.net> Message-ID: <13426df10802051648t76450241le9e20e1e7e025ada@mail.gmail.com> Carl-Daniel, you could never irritate me, your comments are too incredibly useful for that! let's forget I said anything. Marc, your proposed patch (pre-payload) is Acked-by: Ronald G. Minnich let's try it out.If you can commit I will test tonight or tomorrow night. ron From yinghailu at gmail.com Wed Feb 6 02:06:41 2008 From: yinghailu at gmail.com (yhlu) Date: Tue, 5 Feb 2008 17:06:41 -0800 Subject: [coreboot] Cold reset in Tyan s2912 In-Reply-To: <47A8F14B.6040601@dls.net> References: <47A7F428.1070704@dls.net> <2ea3fae10802042248y5b94d7bq2ffb426944da8abe@mail.gmail.com> <47A88531.3010204@dls.net> <47A8F14B.6040601@dls.net> Message-ID: <2ea3fae10802051706s1474c5c0ra1f6454486d5e7f2@mail.gmail.com> On Feb 5, 2008 3:29 PM, Roman Kononov wrote: > On 2008-02-05 09:48, Roman Kononov wrote: > > I have a co-processor. > > > > The sequence I hope to have: > > > > 1) Power up. Power-on reset. The co-processor takes long time to become > > alive (~500s). By this time the CPU thinks that the HT link is dead. > > 2) CPU issues another reset. > > 3) The CPU re-initializes the HT link and the connection is happy. > > > > With the above sequence, the step 3) is a warm reset, and the CPU does > > not attempt to re-initialize the link. > > Never mind. I found the way to make the reset long enough. > then cold reset and warm reset all work? YH From c-d.hailfinger.devel.2006 at gmx.net Wed Feb 6 02:09:08 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 06 Feb 2008 02:09:08 +0100 Subject: [coreboot] Problem with M57SLI and newly installed MX25L4005 In-Reply-To: <47A77DCB.2070405@stockwith.co.uk> References: <47A77DCB.2070405@stockwith.co.uk> Message-ID: <47A908B4.7010105@gmx.net> On 04.02.2008 22:04, Chris Lingard wrote: > I recently found someone who could do the work of modifying the > motherboard, Harald kindly posted me the chip. > > The machine came back and it would not boot with the switch up > > I then probably made a mistake, I used the BIOS itself to dump the > factory BIOS to several floppies; then flipped the switch and wrote the > factory BIOS to the new chip. The machine now boots from either BIOS. > > Using flashrom to detect the chip I get: > > Calibrating delay loop... 853M loops per second. OK. > No coreboot table found. > Found chipset "NVIDIA MCP55", enabling flash write... OK. > Found board "GIGABYTE GA-M57SLI-S4": enabling flash write... Serial > flash segment 0xfffe0000-0xffffffff enabled > Serial flash segment 0x000e0000-0x000fffff enabled > Serial flash segment 0xffee0000-0xffefffff disabled > Serial flash segment 0xfff80000-0xfffeffff enabled > LPC write to serial flash enabled > serial flash pin 29 > OK. > > > > Probing for MX25L4005, 512 KB > RDID returned 7f 9d 7e. > probe_spi: id1 0x7f, id2 0x9d7e > > > > No EEPROM/flash device found. > > The factory BIOS is the same except that it returns > > Probing for MX25L4005, 512 KB > RDID returned 7f 9d 7e. > > > > No EEPROM/flash device found. > Please specify which flash chips you are using. The snipped logs are extremely misleading, especially because the RDID output contradicts the MX25L4005 claim in the mail subject. The RDID you are seeing is from a Pm25LV040 (7f 9d 7e). > The block diagram shows the BIOS connected directly to the 570-SLI and > not via the 8716 > That block diagram is correct for v1.x of the board. > Could someone please give me a clue of either what I have missed out, or > how to proceed? > We need to know the exact flash chip types before we can proceed. Regards, Carl-Daniel From kononov at dls.net Wed Feb 6 02:19:20 2008 From: kononov at dls.net (Roman Kononov) Date: Tue, 05 Feb 2008 19:19:20 -0600 Subject: [coreboot] Cold reset in Tyan s2912 In-Reply-To: <2ea3fae10802051706s1474c5c0ra1f6454486d5e7f2@mail.gmail.com> References: <47A7F428.1070704@dls.net> <2ea3fae10802042248y5b94d7bq2ffb426944da8abe@mail.gmail.com> <47A88531.3010204@dls.net> <47A8F14B.6040601@dls.net> <2ea3fae10802051706s1474c5c0ra1f6454486d5e7f2@mail.gmail.com> Message-ID: <47A90B18.1060205@dls.net> On 2008-02-05 19:06, yhlu wrote: > then cold reset and warm reset all work? These things are still the same. Warm reset works. Cold reset does not. After the cold reset sequence the CPU hangs, only the push button or power switch can revive it. Is it supposed to work or there are secrets somewhere? Roman From c-d.hailfinger.devel.2006 at gmx.net Wed Feb 6 02:35:17 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 06 Feb 2008 02:35:17 +0100 Subject: [coreboot] [PATCH] flashrom: Handle JEDEC continuation codes in SPI ID Message-ID: <47A90ED5.2040205@gmx.net> Chris: Try this patch against latest flashrom, please. It will not detect your chip, but id1/id2 output should change. I need full output from flashrom -V with that patch to proceed further. Handle JEDEC JEP106W continuation codes in SPI RDID. Some vendors like Programmable Micro Corp need this. Both the serial and parallel flash JEDEC detection routines would benefit from a parity/sanity check of the vendor ID. Will do this later. Signed-off-by: Carl-Daniel Hailfinger http://www.hailfinger.org/ Index: flashrom-spisecondjedecpage/spi.c =================================================================== --- flashrom-spisecondjedecpage/spi.c (Revision 3086) +++ flashrom-spisecondjedecpage/spi.c (Arbeitskopie) @@ -281,8 +281,14 @@ uint8_t manuf_id; uint16_t model_id; if (!generic_spi_rdid(readarr)) { - manuf_id = readarr[0]; - model_id = (readarr[1] << 8) | readarr[2]; + /* Check if this is a continuation vendor ID */ + if (readarr[0] == 0x7f) { + manuf_id = (readarr[0] << 8) | readarr[1]; + model_id = readarr[2]; + } else { + manuf_id = readarr[0]; + model_id = (readarr[1] << 8) | readarr[2]; + } printf_debug("%s: id1 0x%x, id2 0x%x\n", __FUNCTION__, manuf_id, model_id); if (manuf_id == flash->manufacture_id && model_id == flash->model_id) { From Marc.Jones at AMD.com Wed Feb 6 02:38:46 2008 From: Marc.Jones at AMD.com (Marc Jones) Date: Tue, 05 Feb 2008 18:38:46 -0700 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <47A902C9.30001@gmx.net> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> <13426df10802032144s3fb5f14bx2f4d67a698e7e90b@mail.gmail.com> <47A789F9.7030701@amd.com> <13426df10802041408p6aee9ab3pa3c94c6a30dfe74b@mail.gmail.com> <47A79F68.3040906@amd.com> <47A902C9.30001@gmx.net> Message-ID: <47A90FA6.5090805@AMD.com> Carl-Daniel Hailfinger wrote: > On 05.02.2008 00:27, Marc Jones wrote: > >> ron minnich wrote: >> >>> Why can't we shadow? >>> >> We could. >> > > Even at the top of the 4G address range? If that is possible, I'd vote > to shadow the bootblock only to save RAM. > > Some comments on the patch: > > >> Cache the ROM to speed up stage2 and payload decompression. >> >> Due to some cache coherency snoop problems across PCI GeodeLc needs the ROM cache properties to be write-serialize + cache disabled by runtime. >> Add pre_payload() call to each mainboard as the final coreboot function before the payload is called. >> >> Signed-off by: Marc Jones >> >> Index: coreboot-v3/northbridge/amd/geodelx/geodelxinit.c >> =================================================================== >> --- coreboot-v3.orig/northbridge/amd/geodelx/geodelxinit.c 2008-02-04 13:35:52.000000000 -0700 >> +++ coreboot-v3/northbridge/amd/geodelx/geodelxinit.c 2008-02-04 13:36:12.000000000 -0700 >> @@ -658,7 +658,7 @@ >> #define SYSMEM_RCONF_WRITETHROUGH 8 >> #define DEVRC_RCONF_DEFAULT 0x21 >> #define ROMBASE_RCONF_DEFAULT 0xFFFC0000 >> -#define ROMRC_RCONF_DEFAULT 0x25 >> +#define ROMRC_RCONF_DEFAULT 0x04 >> >> > > Maybe keep the 0x25 as ROMRC_RCONF_SAFE? > > ok >> >> /** >> * TODO. >> Index: coreboot-v3/mainboard/adl/msm800sev/stage1.c >> =================================================================== >> --- coreboot-v3.orig/mainboard/adl/msm800sev/stage1.c 2008-02-04 15:41:14.000000000 -0700 >> +++ coreboot-v3/mainboard/adl/msm800sev/stage1.c 2008-02-04 15:50:04.000000000 -0700 >> @@ -53,3 +53,15 @@ >> cs5536_disable_internal_uart(); >> w83627hf_enable_serial(0x2e, SERIAL_DEV, SERIAL_IOBASE); >> } >> + >> +void pre_payload(void) >> +{ >> + struct msr msr; >> + >> + /* Set ROM cache properties for runtime. */ >> + msr = rdmsr(CPU_RCONF_DEFAULT); >> + msr.hi &= ~(0xFF << 24); // clear ROMRC >> + msr.hi |= 0x25 << 24; // set WS, CD, WP >> >> > > Use ROMRC_RCONF_SAFE instead of 0x25? > > sure >> + wrmsr(CPU_RCONF_DEFAULT, msr); >> + banner(BIOS_DEBUG, "pre_payload: done"); >> +} >> > > > pre_payload() is not board specific, but Geode LX-specific. > geodelxinit.c may be a more appropriate location. > > Correct, but I foresee other non-Geode platforms needing a call just prior to the payload running but I am flexible on this. Do others have an opinion? Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From yinghailu at gmail.com Wed Feb 6 02:41:41 2008 From: yinghailu at gmail.com (yhlu) Date: Tue, 5 Feb 2008 17:41:41 -0800 Subject: [coreboot] Cold reset in Tyan s2912 In-Reply-To: <47A90B18.1060205@dls.net> References: <47A7F428.1070704@dls.net> <2ea3fae10802042248y5b94d7bq2ffb426944da8abe@mail.gmail.com> <47A88531.3010204@dls.net> <47A8F14B.6040601@dls.net> <2ea3fae10802051706s1474c5c0ra1f6454486d5e7f2@mail.gmail.com> <47A90B18.1060205@dls.net> Message-ID: <2ea3fae10802051741n756a27ddhe25379b4f3f142cb@mail.gmail.com> On Feb 5, 2008 5:19 PM, Roman Kononov wrote: > On 2008-02-05 19:06, yhlu wrote: > > then cold reset and warm reset all work? > > These things are still the same. Warm reset works. Cold reset does not. > After the cold reset sequence the CPU hangs, only the push button or power > switch can revive it. Is it supposed to work or there are secrets somewhere? if replace the co-processor with opteron, does the cold reset work? YH From rminnich at gmail.com Wed Feb 6 02:44:07 2008 From: rminnich at gmail.com (ron minnich) Date: Tue, 5 Feb 2008 17:44:07 -0800 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <47A90FA6.5090805@AMD.com> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> <13426df10802032144s3fb5f14bx2f4d67a698e7e90b@mail.gmail.com> <47A789F9.7030701@amd.com> <13426df10802041408p6aee9ab3pa3c94c6a30dfe74b@mail.gmail.com> <47A79F68.3040906@amd.com> <47A902C9.30001@gmx.net> <47A90FA6.5090805@AMD.com> Message-ID: <13426df10802051744v7c8af499rbf3227e64ed0319d@mail.gmail.com> On Feb 5, 2008 5:38 PM, Marc Jones wrote: > Correct, but I foresee other non-Geode platforms needing a call just > prior to the payload running but I am flexible on this. > Do others have an opinion? yes. I think we'll need this. And I would like, in the future, to get the stage numbering back because the question of "when does this run relative to other things" was a big point of confusion in v2. But my ack still stands :-) ron From c-d.hailfinger.devel.2006 at gmx.net Wed Feb 6 02:52:34 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 06 Feb 2008 02:52:34 +0100 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <47A90FA6.5090805@AMD.com> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> <13426df10802032144s3fb5f14bx2f4d67a698e7e90b@mail.gmail.com> <47A789F9.7030701@amd.com> <13426df10802041408p6aee9ab3pa3c94c6a30dfe74b@mail.gmail.com> <47A79F68.3040906@amd.com> <47A902C9.30001@gmx.net> <47A90FA6.5090805@AMD.com> Message-ID: <47A912E2.3060503@gmx.net> On 06.02.2008 02:38, Marc Jones wrote: > Carl-Daniel Hailfinger wrote: >> On 05.02.2008 00:27, Marc Jones wrote: >>> >>> /** >>> * TODO. >>> Index: coreboot-v3/mainboard/adl/msm800sev/stage1.c >>> =================================================================== >>> --- coreboot-v3.orig/mainboard/adl/msm800sev/stage1.c 2008-02-04 >>> 15:41:14.000000000 -0700 >>> +++ coreboot-v3/mainboard/adl/msm800sev/stage1.c 2008-02-04 >>> 15:50:04.000000000 -0700 >>> @@ -53,3 +53,15 @@ >>> cs5536_disable_internal_uart(); >>> w83627hf_enable_serial(0x2e, SERIAL_DEV, SERIAL_IOBASE); >>> } >>> + >>> +void pre_payload(void) >>> +{ >>> + struct msr msr; >>> + >>> + /* Set ROM cache properties for runtime. */ >>> + msr = rdmsr(CPU_RCONF_DEFAULT); >>> + msr.hi &= ~(0xFF << 24); // clear ROMRC >>> + msr.hi |= 0x25 << 24; // set WS, CD, WP >>> >> >> Use ROMRC_RCONF_SAFE instead of 0x25? > sure Thanks. >>> + wrmsr(CPU_RCONF_DEFAULT, msr); >>> + banner(BIOS_DEBUG, "pre_payload: done"); >>> +} >>> >> >> >> pre_payload() is not board specific, but Geode LX-specific. >> geodelxinit.c may be a more appropriate location. >> >> > Correct, but I foresee other non-Geode platforms needing a call just > prior to the payload running but I am flexible on this. Sorry, I didn't express clearly enough what I wanted. I just tried to avoid duplication if this specific version of pre_payload() in mainboard code and hoped to have the code of this pre_payload() in geodelxinit.c. Maybe rename it to platform_pre_payload() and have it called by pre_payload() inside mainboard specific code. That would give us all the flexibility with minimum code duplication. Regards, Carl-Daniel -- http://www.hailfinger.org/ From kononov at dls.net Wed Feb 6 02:53:58 2008 From: kononov at dls.net (Roman Kononov) Date: Tue, 05 Feb 2008 19:53:58 -0600 Subject: [coreboot] Cold reset in Tyan s2912 In-Reply-To: <2ea3fae10802051741n756a27ddhe25379b4f3f142cb@mail.gmail.com> References: <47A7F428.1070704@dls.net> <2ea3fae10802042248y5b94d7bq2ffb426944da8abe@mail.gmail.com> <47A88531.3010204@dls.net> <47A8F14B.6040601@dls.net> <2ea3fae10802051706s1474c5c0ra1f6454486d5e7f2@mail.gmail.com> <47A90B18.1060205@dls.net> <2ea3fae10802051741n756a27ddhe25379b4f3f142cb@mail.gmail.com> Message-ID: <47A91336.6060001@dls.net> On 2008-02-05 19:41, yhlu wrote: > if replace the co-processor with opteron, does the cold reset work? I did not try 2 processors. With a single processor alone it does not work. Roman From Marc.Jones at AMD.com Wed Feb 6 02:55:36 2008 From: Marc.Jones at AMD.com (Marc Jones) Date: Tue, 05 Feb 2008 18:55:36 -0700 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <47A912E2.3060503@gmx.net> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> <13426df10802032144s3fb5f14bx2f4d67a698e7e90b@mail.gmail.com> <47A789F9.7030701@amd.com> <13426df10802041408p6aee9ab3pa3c94c6a30dfe74b@mail.gmail.com> <47A79F68.3040906@amd.com> <47A902C9.30001@gmx.net> <47A90FA6.5090805@AMD.com> <47A912E2.3060503@gmx.net> Message-ID: <47A91398.1050602@AMD.com> Carl-Daniel Hailfinger wrote: > On 06.02.2008 02:38, Marc Jones wrote: > >> Carl-Daniel Hailfinger wrote: >> >>> >>> pre_payload() is not board specific, but Geode LX-specific. >>> geodelxinit.c may be a more appropriate location. >>> >>> >>> >> Correct, but I foresee other non-Geode platforms needing a call just >> prior to the payload running but I am flexible on this. >> > > Sorry, I didn't express clearly enough what I wanted. I just tried to > avoid duplication if this specific version of pre_payload() in mainboard > code and hoped to have the code of this pre_payload() in geodelxinit.c. > Maybe rename it to platform_pre_payload() and have it called by > pre_payload() inside mainboard specific code. That would give us all the > flexibility with minimum code duplication. > > Regards, > Carl-Daniel > > Good point. I will fix this. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From c-d.hailfinger.devel.2006 at gmx.net Wed Feb 6 02:56:22 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 06 Feb 2008 02:56:22 +0100 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <13426df10802051744v7c8af499rbf3227e64ed0319d@mail.gmail.com> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> <13426df10802032144s3fb5f14bx2f4d67a698e7e90b@mail.gmail.com> <47A789F9.7030701@amd.com> <13426df10802041408p6aee9ab3pa3c94c6a30dfe74b@mail.gmail.com> <47A79F68.3040906@amd.com> <47A902C9.30001@gmx.net> <47A90FA6.5090805@AMD.com> <13426df10802051744v7c8af499rbf3227e64ed0319d@mail.gmail.com> Message-ID: <47A913C6.3070009@gmx.net> On 06.02.2008 02:44, ron minnich wrote: > On Feb 5, 2008 5:38 PM, Marc Jones wrote: > > >> Correct, but I foresee other non-Geode platforms needing a call just >> prior to the payload running but I am flexible on this. >> Do others have an opinion? >> > > yes. I think we'll need this. And I would like, in the future, to get > the stage numbering back because the question of "when does this run > relative to other things" was a big point of confusion in v2. > > But my ack still stands :-) > Despite my comments, Marc's patch also is Acked-by: Carl-Daniel Hailfinger We still can decide how to do this in a generic-yet-not-redundant way after the patch was committed. And maybe the version Marc commits is already perfect. ;-) Regards, Carl-Daniel -- http://www.hailfinger.org/ From svn at coreboot.org Wed Feb 6 03:36:51 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Wed, 6 Feb 2008 03:36:51 +0100 Subject: [coreboot] r573 - in coreboot-v3: arch/x86 include/arch/x86 mainboard/adl/msm800sev mainboard/amd/norwich mainboard/artecgroup/dbe61 mainboard/emulation/qemu-x86 mainboard/pcengines/alix1c northbridge/amd/geodelx util/lar Message-ID: Author: mjones Date: 2008-02-06 03:36:50 +0100 (Wed, 06 Feb 2008) New Revision: 573 Modified: coreboot-v3/arch/x86/Makefile coreboot-v3/arch/x86/ldscript.ld coreboot-v3/arch/x86/stage1.c coreboot-v3/include/arch/x86/amd_geodelx.h coreboot-v3/mainboard/adl/msm800sev/stage1.c coreboot-v3/mainboard/amd/norwich/stage1.c coreboot-v3/mainboard/artecgroup/dbe61/stage1.c coreboot-v3/mainboard/emulation/qemu-x86/stage1.c coreboot-v3/mainboard/pcengines/alix1c/stage1.c coreboot-v3/northbridge/amd/geodelx/geodelxinit.c coreboot-v3/util/lar/lar.h Log: Cache the ROM to speed up stage2 and payload decompression. Due to some problems with PCI transactions, Geode LX needs the ROM cache properties to be write-serialize + cache disabled by runtime. More details below. Add mainboard_pre_payload() call to each mainboard as the final coreboot function before the payload is called by stage1. Note that this patch also grows the bootblock from 16K to 20K to make room for mainboard_pre_payload(). "The problem is a transaction depth issue and bottlenecks inside the GX and LX that go across PCI. The conditions are very complicated but it comes down to we need write serialization for writes to PCI. If you look in the data book you can't have write serialization and the cache enabled on a given area. During coreboot we don't have to worry about a write or a PCI bus master so I think we can enable caching the ROM. After coreboot we can't be sure what will happen in the system so we need to set it up to be safe. For example flashrom just clears the write protect bit. If the cache were enabled (no write serialization) and flashrom was writing the ROM we would be in a precarious position. A PCI bus master doing a read or a write that has a hit on a tag would cause enough bottleneck conditions that it might hit the bug. We could change flashrom but that doesn't help other tools. We need to leave the system in a safe state. Also, caching the ROM after it is no longer used doesn't make much sense. So, we need a call just before the payload runs to clean up the system." Signed-off-by: Marc Jones Acked-by: Carl-Daniel Hailfinger Acked-by: Ronald G. Minnich Modified: coreboot-v3/arch/x86/Makefile =================================================================== --- coreboot-v3/arch/x86/Makefile 2008-02-04 16:16:16 UTC (rev 572) +++ coreboot-v3/arch/x86/Makefile 2008-02-06 02:36:50 UTC (rev 573) @@ -157,7 +157,7 @@ $(Q)$(OBJCOPY) --prefix-symbols=stage0_ $(obj)/stage0.o $(obj)/stage0-prefixed.o $(Q)printf " TEST $(subst $(shell pwd)/,,$(@))\n" - $(Q)test `wc -c < $(obj)/stage0.init` -gt 16128 && \ + $(Q)test `wc -c < $(obj)/stage0.init` -gt 20224 && \ printf "Error. Bootblock got too big.\n" || true $(Q)printf " NM $(subst $(shell pwd)/,,$(@))\n" $(Q)$(NM) $(obj)/stage0.o | sort -u > $(obj)/stage0.init.map Modified: coreboot-v3/arch/x86/ldscript.ld =================================================================== --- coreboot-v3/arch/x86/ldscript.ld 2008-02-04 16:16:16 UTC (rev 572) +++ coreboot-v3/arch/x86/ldscript.ld 2008-02-06 02:36:50 UTC (rev 573) @@ -28,7 +28,7 @@ TARGET(binary) SECTIONS { - . = 0xffffc000 + 256; /* leave space for vpd */ + . = 0xffffb000 + 256; /* leave space for vpd */ .stage0_1 . : { _stage0_1 = .; Modified: coreboot-v3/arch/x86/stage1.c =================================================================== --- coreboot-v3/arch/x86/stage1.c 2008-02-04 16:16:16 UTC (rev 572) +++ coreboot-v3/arch/x86/stage1.c 2008-02-06 02:36:50 UTC (rev 573) @@ -37,6 +37,7 @@ void die(const char *msg); void hardware_stage1(void); void disable_car(void); +void mainboard_pre_payload(void); static void stop_ap(void) { @@ -177,11 +178,13 @@ legacy(&archive, "normal/payload", (void *)UNCOMPRESS_AREA, mem); entry = load_file_segments(&archive, "normal/payload"); - if (entry != (void*)-1) + if (entry != (void*)-1) { + /* Final coreboot call before handing off to the payload. */ + mainboard_pre_payload(); run_address(entry); - else + } else { die("FATAL: No usable payload found.\n"); - + } die ("FATAL: Last stage returned to coreboot.\n"); } Modified: coreboot-v3/include/arch/x86/amd_geodelx.h =================================================================== --- coreboot-v3/include/arch/x86/amd_geodelx.h 2008-02-04 16:16:16 UTC (rev 572) +++ coreboot-v3/include/arch/x86/amd_geodelx.h 2008-02-06 02:36:50 UTC (rev 573) @@ -1269,6 +1269,7 @@ void cpu_reg_init(int debug_clock_disable, u8 dimm0, u8 dimm1); void system_preinit(void); void msr_init(void); +void geode_pre_payload(void); #endif #endif Modified: coreboot-v3/mainboard/adl/msm800sev/stage1.c =================================================================== --- coreboot-v3/mainboard/adl/msm800sev/stage1.c 2008-02-04 16:16:16 UTC (rev 572) +++ coreboot-v3/mainboard/adl/msm800sev/stage1.c 2008-02-06 02:36:50 UTC (rev 573) @@ -53,3 +53,9 @@ cs5536_disable_internal_uart(); w83627hf_enable_serial(0x2e, SERIAL_DEV, SERIAL_IOBASE); } + +void mainboard_pre_payload(void) +{ + geode_pre_payload(); + banner(BIOS_DEBUG, "mainboard_pre_payload: done"); +} Modified: coreboot-v3/mainboard/amd/norwich/stage1.c =================================================================== --- coreboot-v3/mainboard/amd/norwich/stage1.c 2008-02-04 16:16:16 UTC (rev 572) +++ coreboot-v3/mainboard/amd/norwich/stage1.c 2008-02-06 02:36:50 UTC (rev 573) @@ -46,3 +46,9 @@ */ cs5536_setup_onchipuart(); } + +void mainboard_pre_payload(void) +{ + geode_pre_payload(); + banner(BIOS_DEBUG, "mainboard_pre_payload: done"); +} Modified: coreboot-v3/mainboard/artecgroup/dbe61/stage1.c =================================================================== --- coreboot-v3/mainboard/artecgroup/dbe61/stage1.c 2008-02-04 16:16:16 UTC (rev 572) +++ coreboot-v3/mainboard/artecgroup/dbe61/stage1.c 2008-02-06 02:36:50 UTC (rev 573) @@ -61,3 +61,9 @@ */ cs5536_setup_onchipuart(); } + +void mainboard_pre_payload(void) +{ + geode_pre_payload(); + banner(BIOS_DEBUG, "mainboard_pre_payload: done"); +} Modified: coreboot-v3/mainboard/emulation/qemu-x86/stage1.c =================================================================== --- coreboot-v3/mainboard/emulation/qemu-x86/stage1.c 2008-02-04 16:16:16 UTC (rev 572) +++ coreboot-v3/mainboard/emulation/qemu-x86/stage1.c 2008-02-06 02:36:50 UTC (rev 573) @@ -30,3 +30,8 @@ void disable_car(void) { } + + +void pre_payload(void) +{ +} Modified: coreboot-v3/mainboard/pcengines/alix1c/stage1.c =================================================================== --- coreboot-v3/mainboard/pcengines/alix1c/stage1.c 2008-02-04 16:16:16 UTC (rev 572) +++ coreboot-v3/mainboard/pcengines/alix1c/stage1.c 2008-02-06 02:36:50 UTC (rev 573) @@ -49,3 +49,9 @@ w83627hf_enable_serial(0x2e, SERIAL_DEV, SERIAL_IOBASE); } + +void mainboard_pre_payload(void) +{ + geode_pre_payload(); + banner(BIOS_DEBUG, "mainboard_pre_payload: done"); +} Modified: coreboot-v3/northbridge/amd/geodelx/geodelxinit.c =================================================================== --- coreboot-v3/northbridge/amd/geodelx/geodelxinit.c 2008-02-04 16:16:16 UTC (rev 572) +++ coreboot-v3/northbridge/amd/geodelx/geodelxinit.c 2008-02-06 02:36:50 UTC (rev 573) @@ -658,7 +658,8 @@ #define SYSMEM_RCONF_WRITETHROUGH 8 #define DEVRC_RCONF_DEFAULT 0x21 #define ROMBASE_RCONF_DEFAULT 0xFFFC0000 -#define ROMRC_RCONF_DEFAULT 0x25 +#define ROMRC_RCONF_SAFE 0x25 +#define ROMRC_RCONF_DEFAULT 0x04 /** * TODO. @@ -848,3 +849,15 @@ printk(BIOS_DEBUG, "Exit %s\n", __FUNCTION__); } + +void geode_pre_payload(void) +{ + struct msr msr; + + /* Set ROM cache properties for runtime. */ + msr = rdmsr(CPU_RCONF_DEFAULT); + msr.hi &= ~(0xFF << 24); // clear ROMRC + msr.hi |= ROMRC_RCONF_SAFE << 24; // set WS, CD, WP + wrmsr(CPU_RCONF_DEFAULT, msr); +} + Modified: coreboot-v3/util/lar/lar.h =================================================================== --- coreboot-v3/util/lar/lar.h 2008-02-04 16:16:16 UTC (rev 572) +++ coreboot-v3/util/lar/lar.h 2008-02-06 02:36:50 UTC (rev 573) @@ -52,7 +52,7 @@ #define MAGIC "LARCHIVE" #define MAX_PATHLEN 1024 -#define BOOTBLOCK_SIZE 16384 +#define BOOTBLOCK_SIZE 20480 #define BOOTBLOCK_NAME "bootblock" #define BOOTBLOCK_NAME_LEN 16 From Marc.Jones at AMD.com Wed Feb 6 03:38:08 2008 From: Marc.Jones at AMD.com (Marc Jones) Date: Tue, 05 Feb 2008 19:38:08 -0700 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <47A913C6.3070009@gmx.net> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> <13426df10802032144s3fb5f14bx2f4d67a698e7e90b@mail.gmail.com> <47A789F9.7030701@amd.com> <13426df10802041408p6aee9ab3pa3c94c6a30dfe74b@mail.gmail.com> <47A79F68.3040906@amd.com> <47A902C9.30001@gmx.net> <47A90FA6.5090805@AMD.com> <13426df10802051744v7c8af499rbf3227e64ed0319d@mail.gmail.com> <47A913C6.3070009@gmx.net> Message-ID: <47A91D90.4080605@AMD.com> For completeness here is the patch with the acks. r573 Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: romcache.patch URL: From c-d.hailfinger.devel.2006 at gmx.net Wed Feb 6 03:44:58 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 06 Feb 2008 03:44:58 +0100 Subject: [coreboot] Problem with M57SLI and newly installed MX25L4005 In-Reply-To: <47A908B4.7010105@gmx.net> References: <47A77DCB.2070405@stockwith.co.uk> <47A908B4.7010105@gmx.net> Message-ID: <47A91F2A.7000609@gmx.net> On 06.02.2008 02:09, Carl-Daniel Hailfinger wrote: > On 04.02.2008 22:04, Chris Lingard wrote: > >> I recently found someone who could do the work of modifying the >> motherboard, Harald kindly posted me the chip. >> >> The machine came back and it would not boot with the switch up >> >> I then probably made a mistake, I used the BIOS itself to dump the >> factory BIOS to several floppies; then flipped the switch and wrote the >> factory BIOS to the new chip. The machine now boots from either BIOS. >> >> Using flashrom to detect the chip I get: >> >> Calibrating delay loop... 853M loops per second. OK. >> No coreboot table found. >> Found chipset "NVIDIA MCP55", enabling flash write... OK. >> Found board "GIGABYTE GA-M57SLI-S4": enabling flash write... Serial >> flash segment 0xfffe0000-0xffffffff enabled >> Serial flash segment 0x000e0000-0x000fffff enabled >> Serial flash segment 0xffee0000-0xffefffff disabled >> Serial flash segment 0xfff80000-0xfffeffff enabled >> LPC write to serial flash enabled >> serial flash pin 29 >> OK. >> >> >> >> Probing for MX25L4005, 512 KB >> RDID returned 7f 9d 7e. >> probe_spi: id1 0x7f, id2 0x9d7e >> >> >> >> No EEPROM/flash device found. >> >> The factory BIOS is the same except that it returns >> >> Probing for MX25L4005, 512 KB >> RDID returned 7f 9d 7e. >> >> >> >> No EEPROM/flash device found. >> >> > > Please specify which flash chips you are using. The snipped logs are > extremely misleading, especially because the RDID output contradicts the > MX25L4005 claim in the mail subject. > The RDID you are seeing is from a Pm25LV040 (7f 9d 7e). > > >> The block diagram shows the BIOS connected directly to the 570-SLI and >> not via the 8716 >> >> > > That block diagram is correct for v1.x of the board. > > >> Could someone please give me a clue of either what I have missed out, or >> how to proceed? >> >> > > We need to know the exact flash chip types before we can proceed. > Can you try the patch below? We need full output from flashrom -V. Signed-off-by: Carl-Daniel Hailfinger Index: flashrom-spi_pm25/flash.h =================================================================== --- flashrom-spi_pm25/flash.h (Revision 3086) +++ flashrom-spi_pm25/flash.h (Arbeitskopie) @@ -158,7 +158,8 @@ /* Programmable Micro Corp is listed in JEP106W in bank 2, so it should have * a 0x7F continuation code prefix. */ -#define PMC_ID 0x9D /* PMC */ +#define PMC_ID 0x7F9D /* PMC */ +#define PMC_ID_NOPREFIX 0x9D /* PMC, missing 0x7F prefix */ #define PMC_49FL002 0x6D #define PMC_49FL004 0x6E Index: flashrom-spi_pm25/flashchips.c =================================================================== --- flashrom-spi_pm25/flashchips.c (Revision 3086) +++ flashrom-spi_pm25/flashchips.c (Arbeitskopie) @@ -100,9 +100,9 @@ probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, {"SST49LF160C", SST_ID, SST_49LF160C, 2048, 4 * 1024 , probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, - {"Pm49FL002", PMC_ID, PMC_49FL002, 256, 16 * 1024, + {"Pm49FL002", PMC_ID_NOPREFIX, PMC_49FL002, 256, 16 * 1024, probe_jedec, erase_chip_jedec, write_49fl004}, - {"Pm49FL004", PMC_ID, PMC_49FL004, 512, 64 * 1024, + {"Pm49FL004", PMC_ID_NOPREFIX, PMC_49FL004, 512, 64 * 1024, probe_jedec, erase_chip_jedec, write_49fl004}, {"W29C011", WINBOND_ID, W_29C011, 128, 128, probe_jedec, erase_chip_jedec, write_jedec}, @@ -205,6 +205,8 @@ probe_spi, NULL, NULL}, {"MX unknown SPI chip", MX_ID, GENERIC_DEVICE_ID, 0, 0, probe_spi, NULL, NULL}, + {"PMC unknown SPI chip", PMC_ID, GENERIC_DEVICE_ID, 0, 0, + probe_spi, NULL, NULL}, {"SST unknown SPI chip", SST_ID, GENERIC_DEVICE_ID, 0, 0, probe_spi, NULL, NULL}, {"ST unknown SPI chip", ST_ID, GENERIC_DEVICE_ID, 0, 0, Index: flashrom-spi_pm25/spi.c =================================================================== --- flashrom-spi_pm25/spi.c (Revision 3086) +++ flashrom-spi_pm25/spi.c (Arbeitskopie) @@ -281,8 +281,14 @@ uint8_t manuf_id; uint16_t model_id; if (!generic_spi_rdid(readarr)) { - manuf_id = readarr[0]; - model_id = (readarr[1] << 8) | readarr[2]; + /* Check if this is a continuation vendor ID */ + if (readarr[0] == 0x7f) { + manuf_id = (readarr[0] << 8) | readarr[1]; + model_id = readarr[2]; + } else { + manuf_id = readarr[0]; + model_id = (readarr[1] << 8) | readarr[2]; + } printf_debug("%s: id1 0x%x, id2 0x%x\n", __FUNCTION__, manuf_id, model_id); if (manuf_id == flash->manufacture_id && model_id == flash->model_id) { From svn at coreboot.org Wed Feb 6 04:12:53 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Wed, 6 Feb 2008 04:12:53 +0100 Subject: [coreboot] r574 - coreboot-v3/mainboard/emulation/qemu-x86 Message-ID: Author: hailfinger Date: 2008-02-06 04:12:53 +0100 (Wed, 06 Feb 2008) New Revision: 574 Modified: coreboot-v3/mainboard/emulation/qemu-x86/stage1.c Log: Fix compilation for qemu/x86 by renaming pre_payload() to mainboard_pre_payload() in mainboard/emulation/qemu-x86/stage1.c. Signed-off-by: Carl-Daniel Hailfinger Acked-by: Carl-Daniel Hailfinger Modified: coreboot-v3/mainboard/emulation/qemu-x86/stage1.c =================================================================== --- coreboot-v3/mainboard/emulation/qemu-x86/stage1.c 2008-02-06 02:36:50 UTC (rev 573) +++ coreboot-v3/mainboard/emulation/qemu-x86/stage1.c 2008-02-06 03:12:53 UTC (rev 574) @@ -32,6 +32,6 @@ } -void pre_payload(void) +void mainboard_pre_payload(void) { } From c-d.hailfinger.devel.2006 at gmx.net Wed Feb 6 04:14:44 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 06 Feb 2008 04:14:44 +0100 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <47A91D90.4080605@AMD.com> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A64DAE.7020704@gmx.net> <13426df10802031532y6eab0f5esc3c3d30b7206b0d6@mail.gmail.com> <47A66B3E.7020807@gmx.net> <13426df10802032144s3fb5f14bx2f4d67a698e7e90b@mail.gmail.com> <47A789F9.7030701@amd.com> <13426df10802041408p6aee9ab3pa3c94c6a30dfe74b@mail.gmail.com> <47A79F68.3040906@amd.com> <47A902C9.30001@gmx.net> <47A90FA6.5090805@AMD.com> <13426df10802051744v7c8af499rbf3227e64ed0319d@mail.gmail.com> <47A913C6.3070009@gmx.net> <47A91D90.4080605@AMD.com> Message-ID: <47A92624.5070805@gmx.net> On 06.02.2008 03:38, Marc Jones wrote: > For completeness here is the patch with the acks. > r573 Thanks. Qemu/x86 compilation fixed in r574. Regards, Carl-Daniel -- http://www.hailfinger.org/ From corey.osgood at gmail.com Wed Feb 6 06:08:29 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Wed, 6 Feb 2008 00:08:29 -0500 Subject: [coreboot] GENFADT and GENDSDT In-Reply-To: <20080129143724.GB28415@greenwood> References: <1201476962.17287.3.camel@urbez.site> <479DA347.6010301@assembler.cz> <1201541496.3453.12.camel@urbez.site> <479E154C.9050602@gmail.com> <1201558563.3453.25.camel@urbez.site> <479F0412.3060106@gmx.net> <20080129143724.GB28415@greenwood> Message-ID: On Jan 29, 2008 9:37 AM, Uwe Hermann wrote: > Hi, > > On Tue, Jan 29, 2008 at 11:46:42AM +0100, Carl-Daniel Hailfinger wrote: > > On 28.01.2008 23:16, Urbez Santana Roma wrote: > > > Ok. The changes are done. Here the attachments. > > > > > > > Great, thanks! I'd like to have them committed as soon as possible. > > > > Where do we want to store these utilities? util/gen_dt or separate > > directories for both of them? > > I'd personally merge them into one tool as they're very small programs. > Then invoke the different functionalities with two --foo / --bar > switches. Here's a very dumb combination of the two utilities, it hardcodes /proc/acpi/xxx, since I can't think of any reason they'd be different, and also the fadt.c/dsdt.c. No switches yet, but I think we can just add all that stuff later. I've also tried to clean everything up, tabs, etc, etc. I've changed the dsdt line comments to use /**/ style, so the output can be compared with iasl's, but to get a meaning full diff you need to run iasl with optimizations disabled. -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey.osgood at gmail.com Wed Feb 6 06:10:34 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Wed, 6 Feb 2008 00:10:34 -0500 Subject: [coreboot] GENFADT and GENDSDT In-Reply-To: References: <1201476962.17287.3.camel@urbez.site> <479DA347.6010301@assembler.cz> <1201541496.3453.12.camel@urbez.site> <479E154C.9050602@gmail.com> <1201558563.3453.25.camel@urbez.site> <479F0412.3060106@gmx.net> <20080129143724.GB28415@greenwood> Message-ID: On Feb 6, 2008 12:08 AM, Corey Osgood wrote: > On Jan 29, 2008 9:37 AM, Uwe Hermann wrote: > > > Hi, > > > > On Tue, Jan 29, 2008 at 11:46:42AM +0100, Carl-Daniel Hailfinger wrote: > > > On 28.01.2008 23:16, Urbez Santana Roma wrote: > > > > Ok. The changes are done. Here the attachments. > > > > > > > > > > Great, thanks! I'd like to have them committed as soon as possible. > > > > > > Where do we want to store these utilities? util/gen_dt or separate > > > directories for both of them? > > > > I'd personally merge them into one tool as they're very small programs. > > Then invoke the different functionalities with two --foo / --bar > > switches. > > > Here's a very dumb combination of the two utilities, it hardcodes > /proc/acpi/xxx, since I can't think of any reason they'd be different, and > also the fadt.c/dsdt.c. No switches yet, but I think we can just add all > that stuff later. I've also tried to clean everything up, tabs, etc, etc. > I've changed the dsdt line comments to use /**/ style, so the output can be > compared with iasl's, but to get a meaning full diff you need to run iasl > with optimizations disabled. > And now for the attachment! I also haven't added myself as a copyright holder, since all I did was cleanup and add a trivial function. Here's a sign-off anyway: Signed-off-by: Corey Osgood -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: genacpi.c Type: text/x-csrc Size: 9790 bytes Desc: not available URL: From rminnich at gmail.com Wed Feb 6 06:52:00 2008 From: rminnich at gmail.com (ron minnich) Date: Tue, 5 Feb 2008 21:52:00 -0800 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <47A92624.5070805@gmx.net> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A789F9.7030701@amd.com> <13426df10802041408p6aee9ab3pa3c94c6a30dfe74b@mail.gmail.com> <47A79F68.3040906@amd.com> <47A902C9.30001@gmx.net> <47A90FA6.5090805@AMD.com> <13426df10802051744v7c8af499rbf3227e64ed0319d@mail.gmail.com> <47A913C6.3070009@gmx.net> <47A91D90.4080605@AMD.com> <47A92624.5070805@gmx.net> Message-ID: <13426df10802052152p5ca2a710g4f6f4dc60a5ee03c@mail.gmail.com> I see a big improvement in boot time. The only remaining issue is the scan for LAR entries in empty space. ron From vn.lalitha at gmail.com Wed Feb 6 08:52:14 2008 From: vn.lalitha at gmail.com (Lalitha V.N.) Date: Wed, 6 Feb 2008 13:22:14 +0530 Subject: [coreboot] Flashing problem on the SST49LF004B Message-ID: Hi...... Thanks for your reply........ We have tried like this,we have copied original BIOS(PM49FL004) content in the filename feb6 and tried to flash on SST49LF004B flashrom chip and then we followed this steps ..... root at turtle10 ~]# /usr/sbin/flashrom -E Calibrating delay loop... OK. No LinuxBIOS table found. Found chipset "VT8237", enabling flash write... OK. SST49LF004A/B found at physical address 0xfff80000. Flash part is SST49LF004A/B (512 KB). Erasing flash chip [root at turtle10 ~]# /usr/sbin/flashrom -w feb6 Calibrating delay loop... OK. No LinuxBIOS table found. Found chipset "VT8237", enabling flash write... OK. SST49LF004A/B found at physical address 0xfff80000. Flash part is SST49LF004A/B (512 KB). Flash image seems to be a legacy BIOS. Disabling checks. Programming page: 0007 at address: 0x00070000 [root at turtle10 ~]# /usr/sbin/flashrom -v feb6 Calibrating delay loop... OK. No LinuxBIOS table found. Found chipset "VT8237", enabling flash write... OK. SST49LF004A/B found at physical address 0xfff80000. Flash part is SST49LF004A/B (512 KB). Flash image seems to be a legacy BIOS. Disabling checks. Verifying flash... FAILED! Still we are unable to flash , please guide us which procedure should follow and is it necessary for us to change the flashrom chip? otherwise is it required to change the code in flashrom utility....? if it is require please guide where we need to change.. such that flash can happen.. with regards, Lalitha. -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey.osgood at gmail.com Wed Feb 6 09:38:57 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Wed, 6 Feb 2008 03:38:57 -0500 Subject: [coreboot] Flashing problem on the SST49LF004B In-Reply-To: References: Message-ID: Please try this: flashrom -E dd if=/dev/zero of=zero.bin bs=1024 count=512 flashrom -v zero.bin This should tell if the erase or write is where the problem is. Probably the write, but better to know for sure. Also, please do a "reply all" to your mailing's last response on the list, it helps to keep threads organized. -Corey On Feb 6, 2008 2:52 AM, Lalitha V.N. wrote: > Hi...... > > Thanks for your reply........ > > We have tried like this,we have copied original BIOS(PM49FL004) content in > the filename feb6 and tried to flash on > > SST49LF004B flashrom chip and then we followed this steps ..... > > root at turtle10 ~]# /usr/sbin/flashrom -E > > Calibrating delay loop... OK. > > No LinuxBIOS table found. > > Found chipset "VT8237", enabling flash write... OK. > > SST49LF004A/B found at physical address 0xfff80000. > > Flash part is SST49LF004A/B (512 KB). > > Erasing flash chip > > > [root at turtle10 ~]# /usr/sbin/flashrom -w feb6 > > Calibrating delay loop... OK. > > No LinuxBIOS table found. > > Found chipset "VT8237", enabling flash write... OK. > > SST49LF004A/B found at physical address 0xfff80000. > > Flash part is SST49LF004A/B (512 KB). > > Flash image seems to be a legacy BIOS. Disabling checks. > > Programming page: 0007 at address: 0x00070000 > > > [root at turtle10 ~]# /usr/sbin/flashrom -v feb6 > > Calibrating delay loop... OK. > > No LinuxBIOS table found. > > Found chipset "VT8237", enabling flash write... OK. > > SST49LF004A/B found at physical address 0xfff80000. > > Flash part is SST49LF004A/B (512 KB). > > Flash image seems to be a legacy BIOS. Disabling checks. > > Verifying flash... FAILED! > > Still we are unable to flash , please guide us which procedure should > follow and is it necessary > > for us to change the flashrom chip? otherwise is it required to change the > code in flashrom utility....? > > if it is require please guide where we need to change.. such that flash > can happen.. > > > with regards, > Lalitha. > > > -- > coreboot mailing list > coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vn.lalitha at gmail.com Wed Feb 6 11:05:58 2008 From: vn.lalitha at gmail.com (Lalitha V.N.) Date: Wed, 6 Feb 2008 15:35:58 +0530 Subject: [coreboot] Flashing problem on the SST49LF004B In-Reply-To: References: Message-ID: Hi...... we have tried these steps but now we got the same result as what we got in the previous steps.... and these are the steps we followed ...... [root at turtle10 ~]# /usr/sbin/flashrom -E Calibrating delay loop... OK. No LinuxBIOS table found. Found chipset "VT8237", enabling flash write... OK. SST49LF004A/B found at physical address 0xfff80000. Flash part is SST49LF004A/B (512 KB). Erasing flash chip [root at turtle10 ~]# dd if=/dev/zero of=zero.bin bs=1024 count=512 512+0 records in 512+0 records out 524288 bytes (524 kB) copied, 0.00345299 s, 152 MB/s [root at turtle10 ~]# /usr/sbin/flashrom -v zero.bin Calibrating delay loop... OK. No LinuxBIOS table found. Found chipset "VT8237", enabling flash write... OK. SST49LF004A/B found at physical address 0xfff80000. Flash part is SST49LF004A/B (512 KB). Flash image seems to be a legacy BIOS. Disabling checks. Verifying flash... FAILED! with regards, Lalitha. On Feb 6, 2008 2:08 PM, Corey Osgood wrote: > Please try this: > > flashrom -E > dd if=/dev/zero of=zero.bin bs=1024 count=512 > flashrom -v zero.bin > > This should tell if the erase or write is where the problem is. Probably > the write, but better to know for sure. Also, please do a "reply all" to > your mailing's last response on the list, it helps to keep threads > organized. > > -Corey > > On Feb 6, 2008 2:52 AM, Lalitha V.N. wrote: > > > Hi...... > > > > Thanks for your reply........ > > > > We have tried like this,we have copied original BIOS(PM49FL004) content > > in the filename feb6 and tried to flash on > > > > SST49LF004B flashrom chip and then we followed this steps ..... > > > > root at turtle10 ~]# /usr/sbin/flashrom -E > > > > Calibrating delay loop... OK. > > > > No LinuxBIOS table found. > > > > Found chipset "VT8237", enabling flash write... OK. > > > > SST49LF004A/B found at physical address 0xfff80000. > > > > Flash part is SST49LF004A/B (512 KB). > > > > Erasing flash chip > > > > > > [root at turtle10 ~]# /usr/sbin/flashrom -w feb6 > > > > Calibrating delay loop... OK. > > > > No LinuxBIOS table found. > > > > Found chipset "VT8237", enabling flash write... OK. > > > > SST49LF004A/B found at physical address 0xfff80000. > > > > Flash part is SST49LF004A/B (512 KB). > > > > Flash image seems to be a legacy BIOS. Disabling checks. > > > > Programming page: 0007 at address: 0x00070000 > > > > > > [root at turtle10 ~]# /usr/sbin/flashrom -v feb6 > > > > Calibrating delay loop... OK. > > > > No LinuxBIOS table found. > > > > Found chipset "VT8237", enabling flash write... OK. > > > > SST49LF004A/B found at physical address 0xfff80000. > > > > Flash part is SST49LF004A/B (512 KB). > > > > Flash image seems to be a legacy BIOS. Disabling checks. > > > > Verifying flash... FAILED! > > > > Still we are unable to flash , please guide us which procedure should > > follow and is it necessary > > > > for us to change the flashrom chip? otherwise is it required to change > > the code in flashrom utility....? > > > > if it is require please guide where we need to change.. such that flash > > can happen.. > > > > > > with regards, > > Lalitha. > > > > > > -- > > coreboot mailing list > > coreboot at coreboot.org > > http://www.coreboot.org/mailman/listinfo/coreboot > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tiagomnm at gmail.com Wed Feb 6 12:10:29 2008 From: tiagomnm at gmail.com (Tiago Marques) Date: Wed, 6 Feb 2008 11:10:29 +0000 Subject: [coreboot] goal for march summit In-Reply-To: References: <13426df10802012049t54d8f799p7b0c7b99f315583@mail.gmail.com> <47A43EA8.1080702@assembler.cz> <47A4651A.6030603@gmx.net> <47A46DEB.1060709@assembler.cz> <47A5C6BE.8070400@gmx.net> Message-ID: I sent the "patch" to Uwe, but I think I didn't posted it yet. I will do it ASAP. My machine were the M2V currently is has no CPU now, have to get some time to do that. About ASRocks.... I wouldn't trust them. Even not too long ago I got one who was supposedly very good but had a stupid incompatibility problem with a regular HDD from seagate. Not something ordinary. Boards from 3-5 years ago stopped working not long after being two years old. Generally they use really cheap components. The only improvement they're doing is by using solid capacitors on a new line that they are launching now. Tiago Marques From rminnich at gmail.com Wed Feb 6 13:06:15 2008 From: rminnich at gmail.com (ron minnich) Date: Wed, 6 Feb 2008 04:06:15 -0800 Subject: [coreboot] goal for march summit In-Reply-To: <20080204205410.GC9492@cosmic.amd.com> References: <13426df10802012049t54d8f799p7b0c7b99f315583@mail.gmail.com> <20080204205410.GC9492@cosmic.amd.com> Message-ID: <13426df10802060406p3e4e955cyeb7f3209fd2f967@mail.gmail.com> On Feb 4, 2008 12:54 PM, Jordan Crouse wrote: > How about the Serengeti-Cheetah on SimNow? Thats a free platform that > everybody can use (and the new public release fixes some of the bugs that > we have discovered). is the v3 support for this in buildrom? That could be a first step for this target. ron From chris at stockwith.co.uk Wed Feb 6 13:20:24 2008 From: chris at stockwith.co.uk (Chris Lingard) Date: Wed, 06 Feb 2008 12:20:24 +0000 Subject: [coreboot] Problem with M57SLI and newly installed MX25L4005 In-Reply-To: <47A908B4.7010105@gmx.net> References: <47A77DCB.2070405@stockwith.co.uk> <47A908B4.7010105@gmx.net> Message-ID: <47A9A608.1020600@stockwith.co.uk> Carl-Daniel Hailfinger wrote: > Please specify which flash chips you are using. The snipped logs are > extremely misleading, especially because the RDID output contradicts the > MX25L4005 claim in the mail subject. > The RDID you are seeing is from a Pm25LV040 (7f 9d 7e). > We need to know the exact flash chip types before we can proceed. Sorry for length of this Coreboot-v2 release 3088. This is the factory chip, I think Calibrating delay loop... 844M loops per second. OK. No coreboot table found. Found chipset "NVIDIA MCP55", enabling flash write... OK. Found board "GIGABYTE GA-M57SLI-S4": enabling flash write... Serial flash segmen t 0xfffe0000-0xffffffff enabled Serial flash segment 0x000e0000-0x000fffff enabled Serial flash segment 0xffee0000-0xffefffff disabled Serial flash segment 0xfff80000-0xfffeffff enabled LPC write to serial flash enabled serial flash pin 29 OK. Probing for Am29F040B, 512 KB probe_29f040b: id1 0x49, id2 0x4d Probing for Am29LV040B, 512 KB probe_29f040b: id1 0x49, id2 0x4d Probing for Am29F016D, 2048 KB probe_29f040b: id1 0xff, id2 0xff Probing for AE49F2008, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for At29C040A, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for At29C020, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for At49F002(N), 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for At49F002(N)T, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for EN29F002(A)(N)T, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for EN29F002(A)(N)B, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for MBM29F400TC, 512 KB probe_m29f400bt: id1 0x49, id2 0x44 Probing for MX29F002, 256 KB probe_29f002: id1 0x83, id2 0x83 Probing for MX25L4005, 512 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f, id2 0x9d7e Probing for MX25L8005, 1024 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f, id2 0x9d7e Probing for MX25L3205, 4096 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f, id2 0x9d7e Probing for S25FL016A, 2048 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f, id2 0x9d7e Probing for SST25VF040B, 512 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f, id2 0x9d7e Probing for SST25VF016B, 2048 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f, id2 0x9d7e Probing for SST29EE020A, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST28SF040A, 512 KB probe_28sf040: id1 0x49, id2 0x4d Probing for SST39SF010A, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for SST39SF020A, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST39SF040, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for SST39VF020, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST49LF040B, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for SST49LF040, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for SST49LF020A, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST49LF080A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for SST49LF002A/B, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST49LF003A/B, 384 KB probe_jedec: id1 0x92, id2 0xdb Probing for SST49LF004A/B, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for SST49LF008A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for SST49LF004C, 512 KB probe_49lfxxxc: id1 0x49, id2 0x4d Probing for SST49LF008C, 1024 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for SST49LF016C, 2048 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for SST49LF160C, 2048 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for Pm49FL002, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for Pm49FL004, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for W29C011, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for W29C040P, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for W29C020C, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for W29EE011, 128 KB probe_w29ee011: id1 0xff, id2 0xff Probing for W49F002U, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for W49V002A, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for W49V002FA, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for W39V040FA, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for W39V040A, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for W39V040B, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for W39V080A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for W25x10, 128 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f, id2 0x9d7e Probing for W25x20, 256 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f, id2 0x9d7e Probing for W25x40, 512 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f, id2 0x9d7e Probing for W25x80, 1024 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f, id2 0x9d7e Probing for M29F002B, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for M50FW040, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for M29W040B, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for M29F002T/NT, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for M29F400BT, 512 KB probe_m29f400bt: id1 0x49, id2 0x44 Probing for M50FLW040A, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for M50FLW040B, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for M50FLW080A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FLW080B, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FW080, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FW016, 2048 KB probe_jedec: id1 0xff, id2 0xff Probing for M50LPW116, 2048 KB probe_jedec: id1 0xff, id2 0xff Probing for M29W010B, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for M29F040B, 512 KB probe_29f040b: id1 0x49, id2 0x4d Probing for M25P05-A, 64 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f, id2 0x9d7e Probing for M25P10-A, 128 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f, id2 0x9d7e Probing for M25P20, 256 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f, id2 0x9d7e Probing for M25P40, 512 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f, id2 0x9d7e Probing for M25P80, 1024 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f, id2 0x9d7e Probing for M25P16, 2048 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f, id2 0x9d7e Probing for M25P32, 4096 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f, id2 0x9d7e Probing for M25P64, 8192 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f, id2 0x9d7e Probing for M25P128, 16384 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f, id2 0x9d7e Probing for 82802ab, 512 KB probe_82802ab: id1 0x49, id2 0x4d Probing for 82802ac, 1024 KB probe_82802ab: id1 0xff, id2 0xff Probing for F49B002UA, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for LHF00L04, 1024 KB probe_lhf00l04: id1 0xff, id2 0xff Probing for S29C51001T, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for S29C51002T, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for S29C51004T, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for S29C31004T, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for EON unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned 7f 9d 7e. probe_spi: id1 0x7f, id2 0x9d7e Probing for MX unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned 7f 9d 7e. probe_spi: id1 0x7f, id2 0x9d7e Probing for SST unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned 7f 9d 7e. probe_spi: id1 0x7f, id2 0x9d7e Probing for ST unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned 7f 9d 7e. probe_spi: id1 0x7f, id2 0x9d7e No EEPROM/flash device found. Switch up, this is the chip that Harald sent me, the packet has MX25L4005A written on it Calibrating delay loop... 831M loops per second. OK. No coreboot table found. Found chipset "NVIDIA MCP55", enabling flash write... OK. Found board "GIGABYTE GA-M57SLI-S4": enabling flash write... Serial flash segmen t 0xfffe0000-0xffffffff enabled Serial flash segment 0x000e0000-0x000fffff enabled Serial flash segment 0xffee0000-0xffefffff disabled Serial flash segment 0xfff80000-0xfffeffff enabled LPC write to serial flash enabled serial flash pin 29 OK. Probing for Am29F040B, 512 KB probe_29f040b: id1 0xff, id2 0xff Probing for Am29LV040B, 512 KB probe_29f040b: id1 0xff, id2 0xff Probing for Am29F016D, 2048 KB probe_29f040b: id1 0xff, id2 0xff Probing for AE49F2008, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for At29C040A, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for At29C020, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for At49F002(N), 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for At49F002(N)T, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for EN29F002(A)(N)T, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for EN29F002(A)(N)B, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for MBM29F400TC, 512 KB probe_m29f400bt: id1 0xff, id2 0xff Probing for MX29F002, 256 KB probe_29f002: id1 0x83, id2 0x83 Probing for MX25L4005, 512 KB RDID returned 7f 9d 7f. probe_spi: id1 0x7f, id2 0x9d7f Probing for MX25L8005, 1024 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f, id2 0x9d7d Probing for MX25L3205, 4096 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f, id2 0x9d7d Probing for S25FL016A, 2048 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f, id2 0x9d7d Probing for SST25VF040B, 512 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f, id2 0x9d7d Probing for SST25VF016B, 2048 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f, id2 0x9d7d Probing for SST29EE020A, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST28SF040A, 512 KB probe_28sf040: id1 0xff, id2 0xff Probing for SST39SF010A, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for SST39SF020A, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST39SF040, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for SST39VF020, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST49LF040B, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for SST49LF040, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for SST49LF020A, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST49LF080A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for SST49LF002A/B, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST49LF003A/B, 384 KB probe_jedec: id1 0x92, id2 0xdb Probing for SST49LF004A/B, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for SST49LF008A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for SST49LF004C, 512 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for SST49LF008C, 1024 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for SST49LF016C, 2048 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for SST49LF160C, 2048 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for Pm49FL002, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for Pm49FL004, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for W29C011, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for W29C040P, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for W29C020C, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for W29EE011, 128 KB probe_w29ee011: id1 0xff, id2 0xff Probing for W49F002U, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for W49V002A, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for W49V002FA, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for W39V040FA, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for W39V040A, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for W39V040B, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for W39V080A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for W25x10, 128 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f, id2 0x9d7d Probing for W25x20, 256 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f, id2 0x9d7e Probing for W25x40, 512 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f, id2 0x9d7d Probing for W25x80, 1024 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f, id2 0x9d7d Probing for M29F002B, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for M50FW040, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for M29W040B, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for M29F002T/NT, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for M29F400BT, 512 KB probe_m29f400bt: id1 0xff, id2 0xff Probing for M50FLW040A, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FLW040B, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FLW080A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FLW080B, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FW080, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FW016, 2048 KB probe_jedec: id1 0xff, id2 0xff Probing for M50LPW116, 2048 KB probe_jedec: id1 0xff, id2 0xff Probing for M29W010B, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for M29F040B, 512 KB probe_29f040b: id1 0xff, id2 0xff Probing for M25P05-A, 64 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f, id2 0x9d7d Probing for M25P10-A, 128 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f, id2 0x9d7d Probing for M25P20, 256 KB RDID returned 7f 9d 7f. probe_spi: id1 0x7f, id2 0x9d7f Probing for M25P40, 512 KB RDID returned 7f 9d 7f. probe_spi: id1 0x7f, id2 0x9d7f Probing for M25P80, 1024 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f, id2 0x9d7d Probing for M25P16, 2048 KB RDID returned 7f 9d 7f. probe_spi: id1 0x7f, id2 0x9d7f Probing for M25P32, 4096 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f, id2 0x9d7d Probing for M25P64, 8192 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f, id2 0x9d7d Probing for M25P128, 16384 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f, id2 0x9d7d Probing for 82802ab, 512 KB probe_82802ab: id1 0xff, id2 0xff Probing for 82802ac, 1024 KB probe_82802ab: id1 0xff, id2 0xff Probing for F49B002UA, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for LHF00L04, 1024 KB probe_lhf00l04: id1 0xff, id2 0xff Probing for S29C51001T, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for S29C51002T, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for S29C51004T, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for S29C31004T, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for EON unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned 7f 9d 7d. probe_spi: id1 0x7f, id2 0x9d7d Probing for MX unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned 7f 9d 7d. probe_spi: id1 0x7f, id2 0x9d7d Probing for SST unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned 7f 9d 7d. probe_spi: id1 0x7f, id2 0x9d7d Probing for ST unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned 7f 9d 7d. probe_spi: id1 0x7f, id2 0x9d7d No EEPROM/flash device found. From c-d.hailfinger.devel.2006 at gmx.net Wed Feb 6 14:12:33 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 06 Feb 2008 14:12:33 +0100 Subject: [coreboot] GENFADT and GENDSDT In-Reply-To: References: <1201476962.17287.3.camel@urbez.site> <479DA347.6010301@assembler.cz> <1201541496.3453.12.camel@urbez.site> <479E154C.9050602@gmail.com> <1201558563.3453.25.camel@urbez.site> <479F0412.3060106@gmx.net> <20080129143724.GB28415@greenwood> Message-ID: <47A9B241.7050004@gmx.net> On 06.02.2008 06:10, Corey Osgood wrote: > On Feb 6, 2008 12:08 AM, Corey Osgood wrote: > > >> On Jan 29, 2008 9:37 AM, Uwe Hermann wrote: >> >> >>> On Tue, Jan 29, 2008 at 11:46:42AM +0100, Carl-Daniel Hailfinger wrote: >>> >>>> On 28.01.2008 23:16, Urbez Santana Roma wrote: >>>> >>>>> Ok. The changes are done. Here the attachments. >>>>> >>>>> >>>> Great, thanks! I'd like to have them committed as soon as possible. >>>> >>>> Where do we want to store these utilities? util/gen_dt or separate >>>> directories for both of them? >>>> >>> I'd personally merge them into one tool as they're very small programs. >>> Then invoke the different functionalities with two --foo / --bar >>> switches. >>> >> Here's a very dumb combination of the two utilities, it hardcodes >> /proc/acpi/xxx, since I can't think of any reason they'd be different, and >> I'd like to avoid the hardcode. That way, you can work on copies of these virtual files. This is especially useful if you can't run genacpi on the machine you want to dump. >> also the fadt.c/dsdt.c. No switches yet, but I think we can just add all >> that stuff later. I've also tried to clean everything up, tabs, etc, etc. >> I've changed the dsdt line comments to use /**/ style, so the output can be >> compared with iasl's, but to get a meaning full diff you need to run iasl >> with optimizations disabled. >> > > And now for the attachment! I also haven't added myself as a copyright > holder, since all I did was cleanup and add a trivial function. Here's a > sign-off anyway: > Signed-off-by: Corey Osgood > Thanks for working on the merge! A few comments: > /* > * This file is part of the coreboot project. > * > * Copyright (C) 2008 Urbez Santana > * > * This program is free software; you can redistribute it and/or modify > * it under the terms of the GNU General Public License as published by > * the Free Software Foundation; either version 2 of the License, or > * (at your option) any later version. > * > * This program is distributed in the hope that it will be useful, > * but WITHOUT ANY WARRANTY; without even the implied warranty of > * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > * GNU General Public License for more details. > * > * You should have received a copy of the GNU General Public License > * along with this program; if not, write to the Free Software > * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA > */ > > #include > #include > > typedef unsigned char u8; > typedef unsigned long u32; > unsigned long is 64bit on 64bit architectures. You either want unsigned int or you do something like this: typedef uint32_t u32; > typedef unsigned short u16; > > typedef struct acpi_gen_regaddr { > u8 space_id; > u8 bit_width; > u8 bit_offset; > u8 resv; > u32 addrl; > u32 addrh; > } __attribute__ ((packed)) acpi_addr_t; > > /* Generic ACPI Header, provided by (almost) all tables */ > > typedef struct acpi_table_header /* ACPI common table header */ > { > char signature [4]; /* ACPI signature (4 ASCII characters) */\ > u32 length; /* Length of table, in bytes, including header */\ > u8 revision; /* ACPI Specification minor version # */\ > u8 checksum; /* To make sum of entire table == 0 */\ > char oem_id [6]; /* OEM identification */\ > char oem_table_id [8]; /* OEM table identification */\ > u32 oem_revision; /* OEM revision number */\ > char asl_compiler_id [4]; /* ASL compiler vendor ID */\ > u32 asl_compiler_revision; /* ASL compiler revision number */ > } __attribute__ ((packed)) acpi_header_t; > > > typedef struct acpi_fadt { > struct acpi_table_header header; > u32 firmware_ctrl; > u32 dsdt; > u8 res1; > u8 preferred_pm_profile; > u16 sci_int; > u32 smi_cmd; > u8 acpi_enable; > u8 acpi_disable; > u8 s4bios_req; > u8 pstate_cnt; > u32 pm1a_evt_blk; > u32 pm1b_evt_blk; > u32 pm1a_cnt_blk; > u32 pm1b_cnt_blk; > u32 pm2_cnt_blk; > u32 pm_tmr_blk; > u32 gpe0_blk; > u32 gpe1_blk; > u8 pm1_evt_len; > u8 pm1_cnt_len; > u8 pm2_cnt_len; > u8 pm_tmr_len; > u8 gpe0_blk_len; > u8 gpe1_blk_len; > u8 gpe1_base; > u8 cst_cnt; > u16 p_lvl2_lat; > u16 p_lvl3_lat; > u16 flush_size; > u16 flush_stride; > u8 duty_offset; > u8 duty_width; > u8 day_alrm; > u8 mon_alrm; > u8 century; > u16 iapc_boot_arch; > u8 res2; > u32 flags; > struct acpi_gen_regaddr reset_reg; > u8 reset_value; > u8 res3; > u8 res4; > u8 res5; > u32 x_firmware_ctl_l; > u32 x_firmware_ctl_h; > u32 x_dsdt_l; > u32 x_dsdt_h; > struct acpi_gen_regaddr x_pm1a_evt_blk; > struct acpi_gen_regaddr x_pm1b_evt_blk; > struct acpi_gen_regaddr x_pm1a_cnt_blk; > struct acpi_gen_regaddr x_pm1b_cnt_blk; > struct acpi_gen_regaddr x_pm2_cnt_blk; > struct acpi_gen_regaddr x_pm_tmr_blk; > struct acpi_gen_regaddr x_gpe0_blk; > struct acpi_gen_regaddr x_gpe1_blk; > } __attribute__ ((packed)) acpi_fadt_t; > > struct acpi_fadt FADT; > > char strn[64]; > char *stri(int i, const char *str) > { > strncpy(strn, str, i); > strn[i] = 0; > return strn; > } > > void print_u8(FILE *w, char *name, u8 val) > { > fprintf(w, " %s = 0x%02x;\n", name, (int)val); > } > > void print_u16(FILE *w,char *name, u16 val) > { > fprintf(w, " %s = 0x%04x;\n", name, (int)val); > } > > void print_u32(FILE *w, char *name, u32 val) > { > fprintf(w, " %s = 0x%08lx;\n", name, val); > } > > > void print_acpi_gen_regaddr(FILE *w, char *name, acpi_addr_t val) > { > char name2[256]; > sprintf(name2, "%s.space_id", name); > print_u8(w, name2, val.space_id); > sprintf(name2, "%s.bit_width", name); > print_u8(w, name2, val.bit_width); > sprintf(name2, "%s.bit_offset", name); > print_u8(w, name2, val.bit_offset); > sprintf(name2, "%s.resv", name); > print_u8(w, name2, val.resv); > sprintf(name2, "%s.addrl", name); > print_u32(w, name2, val.addrl); > sprintf(name2, "%s.addrh", name); > print_u32(w, name2, val.addrh); > } > > void print_acpi_header(FILE *w,char *name,acpi_header_t val) > Space after comma? Same in other places. > { > char name2[256]; > fprintf(w, " memcpy(header->signature, \"%s\", 4);\n", stri(4, val.signature)); > fprintf(w, " header->length = 0x%08x;\n", val.length); > fprintf(w, " header->revision = 0x%02x;\n", (int)val.revision); > fprintf(w, " memcpy(header->oem_id, \"%s\", 6);\n", stri(6, val.oem_id)); > fprintf(w, " memcpy(header->oem_table_id, \"%s\", 8);\n", stri(8, val.oem_table_id)); > fprintf(w, " header->oem_revision = 0x%08x;\n", val.oem_revision); > fprintf(w, " memcpy(header->asl_compiler_id, \"%s\", 4);\n", stri(4,val.asl_compiler_id)); > fprintf(w, " header->asl_compiler_revision = 0x%08x;\n", val.asl_compiler_revision); > } > > int genfadt(void) > { > FILE *r,*w; > int len; > int off; > int i; > unsigned char buf[8]; > > r = fopen("/proc/acpi/fadt", "rb"); > if(!r) { > printf("Could not open /proc/acpi/dsdt, are you root?\n"); > You mean fadt here. > return 0; > } > w = fopen("fadt.c", "wb"); > if(!w) { > printf("Could not write fadt.c\n"); > return 0; > } > fprintf(w, "/* Intel ACPI Component Architecture\n" > " * File generated by genfadt\n" > " * The content of this file is the intellectual property of its \n" > " * respective owner.\n" > " * Do not distribute without the permission of the copyright holder.\n" > " */\n\n\n"); > len = fread(&FADT, 1, sizeof(FADT), r); > > fprintf(w, "#include \n"); > fprintf(w, "#include \n\n"); > fprintf(w, "void acpi_create_fadt(acpi_fadt_t *fadt,acpi_facs_t *facs,void *dsdt) {\n\n"); > fprintf(w, " acpi_header_t *header = &(fadt->header);\n\n"); > fprintf(w, " memset((void *)fadt, 0, sizeof(acpi_fadt_t));\n"); > > print_acpi_header(w, "fadt->header", FADT.header); > fprintf(w, "\n fadt->firmware_ctrl = facs;\n"); > fprintf(w, " fadt->dsdt = dsdt;\n\n"); > print_u8(w, "fadt->res1", FADT.res1); > print_u8(w, "fadt->preferred_pm_profile", FADT.preferred_pm_profile); > print_u16(w, "fadt->sci_int", FADT.sci_int); > print_u32(w, "fadt->smi_cmd", FADT.smi_cmd); > print_u8(w, "fadt->acpi_enable", FADT.acpi_enable); > print_u8(w, "fadt->acpi_disable", FADT.acpi_disable); > print_u8(w, "fadt->s4bios_req", FADT.s4bios_req); > print_u8(w, "fadt->pstate_cnt", FADT.pstate_cnt); > print_u32(w, "fadt->pm1a_evt_blk", FADT.pm1a_evt_blk); > print_u32(w, "fadt->pm1b_evt_blk", FADT.pm1b_evt_blk); > print_u32(w, "fadt->pm1a_cnt_blk", FADT.pm1a_cnt_blk); > print_u32(w, "fadt->pm1b_cnt_blk", FADT.pm1b_cnt_blk); > print_u32(w, "fadt->pm2_cnt_blk", FADT.pm2_cnt_blk); > print_u32(w, "fadt->pm_tmr_blk", FADT.pm_tmr_blk); > print_u32(w, "fadt->gpe0_blk", FADT.gpe0_blk); > print_u32(w, "fadt->gpe1_blk", FADT.gpe1_blk); > print_u8(w, "fadt->pm1_evt_len", FADT.pm1_evt_len); > print_u8(w, "fadt->pm1_cnt_len", FADT.pm1_cnt_len); > print_u8(w, "fadt->pm2_cnt_len", FADT.pm2_cnt_len); > print_u8(w, "fadt->pm_tmr_len", FADT.pm_tmr_len); > print_u8(w, "fadt->gpe0_blk_len", FADT.gpe0_blk_len); > print_u8(w, "fadt->gpe1_blk_len", FADT.gpe1_blk_len); > print_u8(w, "fadt->gpe1_base", FADT.gpe1_base); > print_u8(w, "fadt->cst_cnt", FADT.cst_cnt); > print_u16(w, "fadt->p_lvl2_lat", FADT.p_lvl2_lat); > print_u16(w, "fadt->p_lvl3_lat", FADT.p_lvl3_lat); > print_u16(w, "fadt->flush_size", FADT.flush_size); > print_u16(w, "fadt->flush_stride", FADT.flush_stride); > print_u8(w, "fadt->duty_offset", FADT.duty_offset); > print_u8(w, "fadt->duty_width", FADT.duty_width); > print_u8(w, "fadt->day_alrm", FADT.day_alrm); > print_u8(w, "fadt->mon_alrm", FADT.mon_alrm); > print_u8(w, "fadt->century", FADT.century); > print_u16(w, "fadt->iapc_boot_arch", FADT.iapc_boot_arch); > print_u8(w, "fadt->res2", FADT.res2); > print_u32(w, "fadt->flags", FADT.flags); > print_acpi_gen_regaddr(w, "fadt->reset_reg", FADT.reset_reg); > print_u8(w, "fadt->reset_value", FADT.reset_value); > print_u8(w, "fadt->res3", FADT.res3); > print_u8(w, "fadt->res4", FADT.res4); > print_u8(w, "fadt->res5", FADT.res5); > fprintf(w, "\n fadt->x_firmware_ctl_l = facs;\n"); > fprintf(w, " fadt->x_firmware_ctl_h = 0;\n"); > fprintf(w, " fadt->x_dsdt_l = dsdt;\n"); > fprintf(w, " fadt->x_dsdt_h = 0;\n\n"); > print_acpi_gen_regaddr(w, "fadt->x_pm1a_evt_blk", FADT.x_pm1a_evt_blk); > print_acpi_gen_regaddr(w, "fadt->x_pm1b_evt_blk", FADT.x_pm1b_evt_blk); > print_acpi_gen_regaddr(w, "fadt->x_pm1a_cnt_blk", FADT.x_pm1a_cnt_blk); > print_acpi_gen_regaddr(w, "fadt->x_pm1b_cnt_blk", FADT.x_pm1b_cnt_blk); > print_acpi_gen_regaddr(w, "fadt->x_pm2_cnt_blk", FADT.x_pm2_cnt_blk); > print_acpi_gen_regaddr(w, "fadt->x_pm_tmr_blk", FADT.x_pm_tmr_blk); > print_acpi_gen_regaddr(w, "fadt->x_gpe0_blk", FADT.x_gpe0_blk); > print_acpi_gen_regaddr(w, "fadt->x_gpe1_blk", FADT.x_gpe1_blk); > > fprintf(w, "\n header->checksum = acpi_checksum((void *)fadt, sizeof(acpi_fadt_t));\n}\n"); > > fclose(w); > fclose(r); > return 1; > } > > > > > int gendsdt(void) > { > FILE *r,*w; //r = /proc/.. w = dsdt.c > int len; > int off; > int i; > unsigned char buf[8]; > > r = fopen("/proc/acpi/dsdt", "rb"); > if(!r) { > printf("Could not open /proc/acpi/dsdt, are you root?\n"); > return 0; > } > w = fopen("dsdt.c", "wb"); > if(!w) { > printf("Could not write dsdt.c\n"); > return 0; > } > > fprintf(w, "/* Intel ACPI Component Architecture\n" > " * File generated by gendsdt\n" > " * The content of this file is the intellectual property of its \n" > " * respective owner.\n" > " * Do not distribute without the permission of the copyright holder.\n" > " */\n\n\n"); > fprintf(w, "unsigned char AmlCode[] =\n{\n"); > off = 0; > while(!feof(r)) > { > len = fread(buf, 1, 8, r); > if (len <= 0) > break; > fprintf(w, " "); > for (i = 0; i < len; i++) > fprintf(w, "0x%02x,", (int)buf[i]); > fprintf(w, " /* %08x \"", off); > for (i = 0; i < len; i++) > fprintf(w, "%c", (buf[i] >= 32 && buf[i] < 127) ? buf[i] : '.'); > fprintf(w, "\" */\n"); > off += len; > } > fprintf(w, "};\n"); > fclose(w); > fclose(r); > return 1; > } > > int main(void) > { > if(!gendsdt()) > return 0; > if(!genfadt()) > return 0; > } > Regards, Carl-Daniel From chris at stockwith.co.uk Wed Feb 6 14:18:22 2008 From: chris at stockwith.co.uk (Chris Lingard) Date: Wed, 06 Feb 2008 13:18:22 +0000 Subject: [coreboot] Problem with M57SLI and newly installed MX25L4005 In-Reply-To: <47A91F2A.7000609@gmx.net> References: <47A77DCB.2070405@stockwith.co.uk> <47A908B4.7010105@gmx.net> <47A91F2A.7000609@gmx.net> Message-ID: <47A9B39E.6090101@stockwith.co.uk> Carl-Daniel Hailfinger wrote: > > Can you try the patch below? We need full output from flashrom -V. > > Signed-off-by: Carl-Daniel Hailfinger > > Index: flashrom-spi_pm25/flash.h > =================================================================== > --- flashrom-spi_pm25/flash.h (Revision 3086) > +++ flashrom-spi_pm25/flash.h (Arbeitskopie) > @@ -158,7 +158,8 @@ > /* Programmable Micro Corp is listed in JEP106W in bank 2, so it should have > * a 0x7F continuation code prefix. > */ > -#define PMC_ID 0x9D /* PMC */ > +#define PMC_ID 0x7F9D /* PMC */ > +#define PMC_ID_NOPREFIX 0x9D /* PMC, missing 0x7F prefix */ > #define PMC_49FL002 0x6D > #define PMC_49FL004 0x6E > > Index: flashrom-spi_pm25/flashchips.c > =================================================================== > --- flashrom-spi_pm25/flashchips.c (Revision 3086) > +++ flashrom-spi_pm25/flashchips.c (Arbeitskopie) > @@ -100,9 +100,9 @@ > probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, > {"SST49LF160C", SST_ID, SST_49LF160C, 2048, 4 * 1024 , > probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, > - {"Pm49FL002", PMC_ID, PMC_49FL002, 256, 16 * 1024, > + {"Pm49FL002", PMC_ID_NOPREFIX, PMC_49FL002, 256, 16 * 1024, > probe_jedec, erase_chip_jedec, write_49fl004}, > - {"Pm49FL004", PMC_ID, PMC_49FL004, 512, 64 * 1024, > + {"Pm49FL004", PMC_ID_NOPREFIX, PMC_49FL004, 512, 64 * 1024, > probe_jedec, erase_chip_jedec, write_49fl004}, > {"W29C011", WINBOND_ID, W_29C011, 128, 128, > probe_jedec, erase_chip_jedec, write_jedec}, > @@ -205,6 +205,8 @@ > probe_spi, NULL, NULL}, > {"MX unknown SPI chip", MX_ID, GENERIC_DEVICE_ID, 0, 0, > probe_spi, NULL, NULL}, > + {"PMC unknown SPI chip", PMC_ID, GENERIC_DEVICE_ID, 0, 0, > + probe_spi, NULL, NULL}, > {"SST unknown SPI chip", SST_ID, GENERIC_DEVICE_ID, 0, 0, > probe_spi, NULL, NULL}, > {"ST unknown SPI chip", ST_ID, GENERIC_DEVICE_ID, 0, 0, > Index: flashrom-spi_pm25/spi.c > =================================================================== > --- flashrom-spi_pm25/spi.c (Revision 3086) > +++ flashrom-spi_pm25/spi.c (Arbeitskopie) > @@ -281,8 +281,14 @@ > uint8_t manuf_id; > uint16_t model_id; > if (!generic_spi_rdid(readarr)) { > - manuf_id = readarr[0]; > - model_id = (readarr[1] << 8) | readarr[2]; > + /* Check if this is a continuation vendor ID */ > + if (readarr[0] == 0x7f) { > + manuf_id = (readarr[0] << 8) | readarr[1]; > + model_id = readarr[2]; > + } else { > + manuf_id = readarr[0]; > + model_id = (readarr[1] << 8) | readarr[2]; > + } > printf_debug("%s: id1 0x%x, id2 0x%x\n", __FUNCTION__, manuf_id, model_id); > if (manuf_id == flash->manufacture_id && > model_id == flash->model_id) { I got version 3086, applied your patch, and the output is identical to that already posted. From chris at stockwith.co.uk Wed Feb 6 14:31:18 2008 From: chris at stockwith.co.uk (Chris Lingard) Date: Wed, 06 Feb 2008 13:31:18 +0000 Subject: [coreboot] Problem with M57SLI and newly installed MX25L4005 In-Reply-To: <47A9B39E.6090101@stockwith.co.uk> References: <47A77DCB.2070405@stockwith.co.uk> <47A908B4.7010105@gmx.net> <47A91F2A.7000609@gmx.net> <47A9B39E.6090101@stockwith.co.uk> Message-ID: <47A9B6A6.8030308@stockwith.co.uk> Chris Lingard wrote: > > > I got version 3086, applied your patch, and the output is identical to > that already posted. Please ignore this post From c-d.hailfinger.devel.2006 at gmx.net Wed Feb 6 14:41:21 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 06 Feb 2008 14:41:21 +0100 Subject: [coreboot] Problem with M57SLI and newly installed MX25L4005 In-Reply-To: <47A9B39E.6090101@stockwith.co.uk> References: <47A77DCB.2070405@stockwith.co.uk> <47A908B4.7010105@gmx.net> <47A91F2A.7000609@gmx.net> <47A9B39E.6090101@stockwith.co.uk> Message-ID: <47A9B901.3030104@gmx.net> On 06.02.2008 14:18, Chris Lingard wrote: > Carl-Daniel Hailfinger wrote: > > >> Can you try the patch below? We need full output from flashrom -V. >> >> Signed-off-by: Carl-Daniel Hailfinger >> >> Index: flashrom-spi_pm25/flash.h >> =================================================================== >> --- flashrom-spi_pm25/flash.h (Revision 3086) >> +++ flashrom-spi_pm25/flash.h (Arbeitskopie) >> @@ -158,7 +158,8 @@ >> /* Programmable Micro Corp is listed in JEP106W in bank 2, so it should have >> * a 0x7F continuation code prefix. >> */ >> -#define PMC_ID 0x9D /* PMC */ >> +#define PMC_ID 0x7F9D /* PMC */ >> +#define PMC_ID_NOPREFIX 0x9D /* PMC, missing 0x7F prefix */ >> #define PMC_49FL002 0x6D >> #define PMC_49FL004 0x6E >> >> Index: flashrom-spi_pm25/flashchips.c >> =================================================================== >> --- flashrom-spi_pm25/flashchips.c (Revision 3086) >> +++ flashrom-spi_pm25/flashchips.c (Arbeitskopie) >> @@ -100,9 +100,9 @@ >> probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, >> {"SST49LF160C", SST_ID, SST_49LF160C, 2048, 4 * 1024 , >> probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, >> - {"Pm49FL002", PMC_ID, PMC_49FL002, 256, 16 * 1024, >> + {"Pm49FL002", PMC_ID_NOPREFIX, PMC_49FL002, 256, 16 * 1024, >> probe_jedec, erase_chip_jedec, write_49fl004}, >> - {"Pm49FL004", PMC_ID, PMC_49FL004, 512, 64 * 1024, >> + {"Pm49FL004", PMC_ID_NOPREFIX, PMC_49FL004, 512, 64 * 1024, >> probe_jedec, erase_chip_jedec, write_49fl004}, >> {"W29C011", WINBOND_ID, W_29C011, 128, 128, >> probe_jedec, erase_chip_jedec, write_jedec}, >> @@ -205,6 +205,8 @@ >> probe_spi, NULL, NULL}, >> {"MX unknown SPI chip", MX_ID, GENERIC_DEVICE_ID, 0, 0, >> probe_spi, NULL, NULL}, >> + {"PMC unknown SPI chip", PMC_ID, GENERIC_DEVICE_ID, 0, 0, >> + probe_spi, NULL, NULL}, >> {"SST unknown SPI chip", SST_ID, GENERIC_DEVICE_ID, 0, 0, >> probe_spi, NULL, NULL}, >> {"ST unknown SPI chip", ST_ID, GENERIC_DEVICE_ID, 0, 0, >> Index: flashrom-spi_pm25/spi.c >> =================================================================== >> --- flashrom-spi_pm25/spi.c (Revision 3086) >> +++ flashrom-spi_pm25/spi.c (Arbeitskopie) >> @@ -281,8 +281,14 @@ >> uint8_t manuf_id; >> uint16_t model_id; >> if (!generic_spi_rdid(readarr)) { >> - manuf_id = readarr[0]; >> - model_id = (readarr[1] << 8) | readarr[2]; >> + /* Check if this is a continuation vendor ID */ >> + if (readarr[0] == 0x7f) { >> + manuf_id = (readarr[0] << 8) | readarr[1]; >> + model_id = readarr[2]; >> + } else { >> + manuf_id = readarr[0]; >> + model_id = (readarr[1] << 8) | readarr[2]; >> + } >> printf_debug("%s: id1 0x%x, id2 0x%x\n", __FUNCTION__, manuf_id, model_id); >> if (manuf_id == flash->manufacture_id && >> model_id == flash->model_id) { >> > > > I got version 3086, applied your patch, and the output is identical to > that already posted. > Thanks for testing. The output should be mostly identical on the first look, but not exactly identical. If it is exactly identical, the executed binary didn't contain the patch. I'm looking for the following output changes: > probe_spi: id1 0x7f, id2 0x9d7e should become > probe_spi: id1 0x7f9d, id2 0x7e and there should be three additional lines near the end: > Probing for PMC unknown SPI chip, 0 KB > WARNING: size: 0 -> 4096 (page size) > RDID returned 7f 9d 7d. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Wed Feb 6 14:42:33 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 06 Feb 2008 14:42:33 +0100 Subject: [coreboot] Problem with M57SLI and newly installed MX25L4005 In-Reply-To: <47A9A608.1020600@stockwith.co.uk> References: <47A77DCB.2070405@stockwith.co.uk> <47A908B4.7010105@gmx.net> <47A9A608.1020600@stockwith.co.uk> Message-ID: <47A9B949.30208@gmx.net> On 06.02.2008 13:20, Chris Lingard wrote: > Carl-Daniel Hailfinger wrote: > >> Please specify which flash chips you are using. The snipped logs are >> extremely misleading, especially because the RDID output contradicts the >> MX25L4005 claim in the mail subject. >> The RDID you are seeing is from a Pm25LV040 (7f 9d 7e). >> >> We need to know the exact flash chip types before we can proceed. >> > > Sorry for length of this > No problem, we are used to even bigger mails. And in your case, I explicitly requested it. Thanks. > Coreboot-v2 release 3088. This is the factory chip, I think > OK. Any chance to find out what's written on the factory chip? > Found chipset "NVIDIA MCP55", enabling flash write... OK. > Found board "GIGABYTE GA-M57SLI-S4" > [...] > Probing for EON unknown SPI chip, 0 KB > WARNING: size: 0 -> 4096 (page size) > RDID returned 7f 9d 7e. > probe_spi: id1 0x7f, id2 0x9d7e > Probing for MX unknown SPI chip, 0 KB > WARNING: size: 0 -> 4096 (page size) > RDID returned 7f 9d 7e. > probe_spi: id1 0x7f, id2 0x9d7e > Probing for SST unknown SPI chip, 0 KB > WARNING: size: 0 -> 4096 (page size) > RDID returned 7f 9d 7e. > probe_spi: id1 0x7f, id2 0x9d7e > Probing for ST unknown SPI chip, 0 KB > WARNING: size: 0 -> 4096 (page size) > RDID returned 7f 9d 7e. > probe_spi: id1 0x7f, id2 0x9d7e > No EEPROM/flash device found. > The RDID results are consistent between RDID calls. > Switch up, this is the chip that Harald sent me, the packet has > MX25L4005A written on it > OK. Strange... I believe you, but the results below suggest another chip. > Found chipset "NVIDIA MCP55", enabling flash write... OK. > Found board "GIGABYTE GA-M57SLI-S4" > [...] > Probing for EON unknown SPI chip, 0 KB > WARNING: size: 0 -> 4096 (page size) > RDID returned 7f 9d 7d. > probe_spi: id1 0x7f, id2 0x9d7d > Probing for MX unknown SPI chip, 0 KB > WARNING: size: 0 -> 4096 (page size) > RDID returned 7f 9d 7d. > probe_spi: id1 0x7f, id2 0x9d7d > Probing for SST unknown SPI chip, 0 KB > WARNING: size: 0 -> 4096 (page size) > RDID returned 7f 9d 7d. > probe_spi: id1 0x7f, id2 0x9d7d > Probing for ST unknown SPI chip, 0 KB > WARNING: size: 0 -> 4096 (page size) > RDID returned 7f 9d 7d. > probe_spi: id1 0x7f, id2 0x9d7d > No EEPROM/flash device found. > EDIT: I just saw your mail from a few minutes ago. The output of the patched flashrom will prove enlightening. Regards, Carl-Daniel -- http://www.hailfinger.org/ From c-d.hailfinger.devel.2006 at gmx.net Wed Feb 6 14:53:48 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 06 Feb 2008 14:53:48 +0100 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <13426df10802052152p5ca2a710g4f6f4dc60a5ee03c@mail.gmail.com> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A789F9.7030701@amd.com> <13426df10802041408p6aee9ab3pa3c94c6a30dfe74b@mail.gmail.com> <47A79F68.3040906@amd.com> <47A902C9.30001@gmx.net> <47A90FA6.5090805@AMD.com> <13426df10802051744v7c8af499rbf3227e64ed0319d@mail.gmail.com> <47A913C6.3070009@gmx.net> <47A91D90.4080605@AMD.com> <47A92624.5070805@gmx.net> <13426df10802052152p5ca2a710g4f6f4dc60a5ee03c@mail.gmail.com> Message-ID: <47A9BBEC.7030306@gmx.net> On 06.02.2008 06:52, ron minnich wrote: > I see a big improvement in boot time. The only remaining issue is the > scan for LAR entries in empty space. > Great! Can you fill up empty LAR space with any uncompressed(!) file of the right size? That will give us a reasonable estimate of v3 boot time. I'm very interested in how well v3 compares against v2. The cleanliness of v3 is great, but if it even comes with better speed, we have a really strong selling point. Regards, Carl-Daniel -- http://www.hailfinger.org/ From chris at stockwith.co.uk Wed Feb 6 15:05:04 2008 From: chris at stockwith.co.uk (Chris Lingard) Date: Wed, 06 Feb 2008 14:05:04 +0000 Subject: [coreboot] Problem with M57SLI and newly installed MX25L4005 In-Reply-To: <47A9B901.3030104@gmx.net> References: <47A77DCB.2070405@stockwith.co.uk> <47A908B4.7010105@gmx.net> <47A91F2A.7000609@gmx.net> <47A9B39E.6090101@stockwith.co.uk> <47A9B901.3030104@gmx.net> Message-ID: <47A9BE90.1090905@stockwith.co.uk> Carl-Daniel Hailfinger wrote: > > Thanks for testing. > The output should be mostly identical on the first look, but not exactly > identical. If it is exactly identical, the executed binary didn't > contain the patch. > I'm looking for the following output changes: > >> probe_spi: id1 0x7f, id2 0x9d7e > should become >> probe_spi: id1 0x7f9d, id2 0x7e > and there should be three additional lines near the end: >> Probing for PMC unknown SPI chip, 0 KB >> WARNING: size: 0 -> 4096 (page size) >> RDID returned 7f 9d 7d. Sorry. Think I may have got it right now :-( Switch down, (the factory chip?) Calibrating delay loop... 864M loops per second. OK. No coreboot table found. Found chipset "NVIDIA MCP55", enabling flash write... OK. Found board "GIGABYTE GA-M57SLI-S4": enabling flash write... Serial flash segment 0xfffe0000-0xffffffff enabled Serial flash segment 0x000e0000-0x000fffff enabled Serial flash segment 0xffee0000-0xffefffff disabled Serial flash segment 0xfff80000-0xfffeffff enabled LPC write to serial flash enabled serial flash pin 29 OK. Probing for Am29F040B, 512 KB probe_29f040b: id1 0x49, id2 0x4d Probing for Am29LV040B, 512 KB probe_29f040b: id1 0x49, id2 0x4d Probing for Am29F016D, 2048 KB probe_29f040b: id1 0xff, id2 0xff Probing for AE49F2008, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for At29C040A, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for At29C020, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for At49F002(N), 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for At49F002(N)T, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for EN29F002(A)(N)T, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for EN29F002(A)(N)B, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for MBM29F400TC, 512 KB probe_m29f400bt: id1 0x49, id2 0x44 Probing for MX29F002, 256 KB probe_29f002: id1 0x83, id2 0x83 Probing for MX25L4005, 512 KB RDID returned 7f 9d 7e. probe_spi: id1 0x9d, id2 0x7e Probing for MX25L8005, 1024 KB RDID returned 7f 9d 7e. probe_spi: id1 0x9d, id2 0x7e Probing for MX25L3205, 4096 KB RDID returned 7f 9d 7e. probe_spi: id1 0x9d, id2 0x7e Probing for S25FL016A, 2048 KB RDID returned 7f 9d 7e. probe_spi: id1 0x9d, id2 0x7e Probing for SST25VF040B, 512 KB RDID returned 7f 9d 7e. probe_spi: id1 0x9d, id2 0x7e Probing for SST25VF016B, 2048 KB RDID returned 7f 9d 7e. probe_spi: id1 0x9d, id2 0x7e Probing for SST29EE020A, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST28SF040A, 512 KB probe_28sf040: id1 0x49, id2 0x4d Probing for SST39SF010A, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for SST39SF020A, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST39SF040, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for SST39VF020, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST49LF040B, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for SST49LF040, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for SST49LF020A, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST49LF080A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for SST49LF002A/B, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST49LF003A/B, 384 KB probe_jedec: id1 0x92, id2 0xdb Probing for SST49LF004A/B, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for SST49LF008A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for SST49LF004C, 512 KB probe_49lfxxxc: id1 0x49, id2 0x4d Probing for SST49LF008C, 1024 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for SST49LF016C, 2048 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for SST49LF160C, 2048 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for Pm49FL002, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for Pm49FL004, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for W29C011, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for W29C040P, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for W29C020C, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for W29EE011, 128 KB probe_w29ee011: id1 0xff, id2 0xff Probing for W49F002U, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for W49V002A, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for W49V002FA, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for W39V040FA, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for W39V040A, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for W39V040B, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for W39V080A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for W25x10, 128 KB RDID returned 7f 9d 7e. probe_spi: id1 0x9d, id2 0x7e Probing for W25x20, 256 KB RDID returned 7f 9d 7e. probe_spi: id1 0x9d, id2 0x7e Probing for W25x40, 512 KB RDID returned 7f 9d 7e. probe_spi: id1 0x9d, id2 0x7e Probing for W25x80, 1024 KB RDID returned 7f 9d 7e. probe_spi: id1 0x9d, id2 0x7e Probing for M29F002B, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for M50FW040, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for M29W040B, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for M29F002T/NT, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for M29F400BT, 512 KB probe_m29f400bt: id1 0x49, id2 0x44 Probing for M50FLW040A, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for M50FLW040B, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for M50FLW080A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FLW080B, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FW080, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FW016, 2048 KB probe_jedec: id1 0xff, id2 0xff Probing for M50LPW116, 2048 KB probe_jedec: id1 0xff, id2 0xff Probing for M29W010B, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for M29F040B, 512 KB probe_29f040b: id1 0x49, id2 0x4d Probing for M25P05-A, 64 KB RDID returned 7f 9d 7e. probe_spi: id1 0x9d, id2 0x7e Probing for M25P10-A, 128 KB RDID returned 7f 9d 7e. probe_spi: id1 0x9d, id2 0x7e Probing for M25P20, 256 KB RDID returned 7f 9d 7e. probe_spi: id1 0x9d, id2 0x7e Probing for M25P40, 512 KB RDID returned 7f 9d 7e. probe_spi: id1 0x9d, id2 0x7e Probing for M25P80, 1024 KB RDID returned 7f 9d 7e. probe_spi: id1 0x9d, id2 0x7e Probing for M25P16, 2048 KB RDID returned 7f 9d 7e. probe_spi: id1 0x9d, id2 0x7e Probing for M25P32, 4096 KB RDID returned 7f 9d 7e. probe_spi: id1 0x9d, id2 0x7e Probing for M25P64, 8192 KB RDID returned 7f 9d 7e. probe_spi: id1 0x9d, id2 0x7e Probing for M25P128, 16384 KB RDID returned 7f 9d 7e. probe_spi: id1 0x9d, id2 0x7e Probing for 82802ab, 512 KB probe_82802ab: id1 0x49, id2 0x4d Probing for 82802ac, 1024 KB probe_82802ab: id1 0xff, id2 0xff Probing for F49B002UA, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for LHF00L04, 1024 KB probe_lhf00l04: id1 0xff, id2 0xff Probing for S29C51001T, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for S29C51002T, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for S29C51004T, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for S29C31004T, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for EON unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned 7f 9d 7e. probe_spi: id1 0x9d, id2 0x7e Probing for MX unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned 7f 9d 7e. probe_spi: id1 0x9d, id2 0x7e Probing for PMC unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned 7f 9d 7e. probe_spi: id1 0x9d, id2 0x7e Probing for SST unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned 7f 9d 7e. probe_spi: id1 0x9d, id2 0x7e Probing for ST unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned 7f 9d 7e. probe_spi: id1 0x9d, id2 0x7e No EEPROM/flash device found. Switch up, (the new chip?) Calibrating delay loop... 827M loops per second. OK. No coreboot table found. Found chipset "NVIDIA MCP55", enabling flash write... OK. Found board "GIGABYTE GA-M57SLI-S4": enabling flash write... Serial flash segment 0xfffe0000-0xffffffff enabled Serial flash segment 0x000e0000-0x000fffff enabled Serial flash segment 0xffee0000-0xffefffff disabled Serial flash segment 0xfff80000-0xfffeffff enabled LPC write to serial flash enabled serial flash pin 29 OK. Probing for Am29F040B, 512 KB probe_29f040b: id1 0xff, id2 0xff Probing for Am29LV040B, 512 KB probe_29f040b: id1 0xff, id2 0xff Probing for Am29F016D, 2048 KB probe_29f040b: id1 0xff, id2 0xff Probing for AE49F2008, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for At29C040A, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for At29C020, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for At49F002(N), 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for At49F002(N)T, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for EN29F002(A)(N)T, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for EN29F002(A)(N)B, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for MBM29F400TC, 512 KB probe_m29f400bt: id1 0xff, id2 0xff Probing for MX29F002, 256 KB probe_29f002: id1 0x83, id2 0x83 Probing for MX25L4005, 512 KB RDID returned 7f 9d 7d. probe_spi: id1 0x9d, id2 0x7d Probing for MX25L8005, 1024 KB RDID returned 7f 9d 7d. probe_spi: id1 0x9d, id2 0x7d Probing for MX25L3205, 4096 KB RDID returned 7f 9d 7d. probe_spi: id1 0x9d, id2 0x7d Probing for S25FL016A, 2048 KB RDID returned 7f 9d 7d. probe_spi: id1 0x9d, id2 0x7d Probing for SST25VF040B, 512 KB RDID returned 7f 9d 7d. probe_spi: id1 0x9d, id2 0x7d Probing for SST25VF016B, 2048 KB RDID returned 7f 9d 7d. probe_spi: id1 0x9d, id2 0x7d Probing for SST29EE020A, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST28SF040A, 512 KB probe_28sf040: id1 0xff, id2 0xff Probing for SST39SF010A, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for SST39SF020A, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST39SF040, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for SST39VF020, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST49LF040B, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for SST49LF040, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for SST49LF020A, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST49LF080A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for SST49LF002A/B, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST49LF003A/B, 384 KB probe_jedec: id1 0x92, id2 0xdb Probing for SST49LF004A/B, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for SST49LF008A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for SST49LF004C, 512 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for SST49LF008C, 1024 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for SST49LF016C, 2048 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for SST49LF160C, 2048 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for Pm49FL002, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for Pm49FL004, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for W29C011, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for W29C040P, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for W29C020C, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for W29EE011, 128 KB probe_w29ee011: id1 0xff, id2 0xff Probing for W49F002U, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for W49V002A, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for W49V002FA, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for W39V040FA, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for W39V040A, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for W39V040B, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for W39V080A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for W25x10, 128 KB RDID returned 7f 9d 7f. probe_spi: id1 0x9d, id2 0x7f Probing for W25x20, 256 KB RDID returned 7f 9d 7d. probe_spi: id1 0x9d, id2 0x7d Probing for W25x40, 512 KB RDID returned 7f 9d 7d. probe_spi: id1 0x9d, id2 0x7d Probing for W25x80, 1024 KB RDID returned 7f 9d 7d. probe_spi: id1 0x9d, id2 0x7d Probing for M29F002B, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for M50FW040, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for M29W040B, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for M29F002T/NT, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for M29F400BT, 512 KB probe_m29f400bt: id1 0xff, id2 0xff Probing for M50FLW040A, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FLW040B, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FLW080A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FLW080B, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FW080, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FW016, 2048 KB probe_jedec: id1 0xff, id2 0xff Probing for M50LPW116, 2048 KB probe_jedec: id1 0xff, id2 0xff Probing for M29W010B, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for M29F040B, 512 KB probe_29f040b: id1 0xff, id2 0xff Probing for M25P05-A, 64 KB RDID returned 7f 9d 7d. probe_spi: id1 0x9d, id2 0x7d Probing for M25P10-A, 128 KB RDID returned 7f 9d 7d. probe_spi: id1 0x9d, id2 0x7d Probing for M25P20, 256 KB RDID returned 7f 9d 7d. probe_spi: id1 0x9d, id2 0x7d Probing for M25P40, 512 KB RDID returned 7f 9d 7e. probe_spi: id1 0x9d, id2 0x7e Probing for M25P80, 1024 KB RDID returned 7f 9d 7d. probe_spi: id1 0x9d, id2 0x7d Probing for M25P16, 2048 KB RDID returned 7f 9d 7d. probe_spi: id1 0x9d, id2 0x7d Probing for M25P32, 4096 KB RDID returned 7f 9d 7d. probe_spi: id1 0x9d, id2 0x7d Probing for M25P64, 8192 KB RDID returned 7f 9d 7e. probe_spi: id1 0x9d, id2 0x7e Probing for M25P128, 16384 KB RDID returned 7f 9d 7f. probe_spi: id1 0x9d, id2 0x7f Probing for 82802ab, 512 KB probe_82802ab: id1 0xff, id2 0xff Probing for 82802ac, 1024 KB probe_82802ab: id1 0xff, id2 0xff Probing for F49B002UA, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for LHF00L04, 1024 KB probe_lhf00l04: id1 0xff, id2 0xff Probing for S29C51001T, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for S29C51002T, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for S29C51004T, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for S29C31004T, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for EON unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned 7f 9d 7f. probe_spi: id1 0x9d, id2 0x7f Probing for MX unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned 7f 9d 7d. probe_spi: id1 0x9d, id2 0x7d Probing for PMC unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned 7f 9d 7f. probe_spi: id1 0x9d, id2 0x7f Probing for SST unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned 7f 9d 7d. probe_spi: id1 0x9d, id2 0x7d Probing for ST unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned 7f 9d 7d. probe_spi: id1 0x9d, id2 0x7d No EEPROM/flash device found. From c-d.hailfinger.devel.2006 at gmx.net Wed Feb 6 15:59:04 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 06 Feb 2008 15:59:04 +0100 Subject: [coreboot] Problem with M57SLI and newly installed MX25L4005 In-Reply-To: <47A9BE90.1090905@stockwith.co.uk> References: <47A77DCB.2070405@stockwith.co.uk> <47A908B4.7010105@gmx.net> <47A91F2A.7000609@gmx.net> <47A9B39E.6090101@stockwith.co.uk> <47A9B901.3030104@gmx.net> <47A9BE90.1090905@stockwith.co.uk> Message-ID: <47A9CB38.1050904@gmx.net> On 06.02.2008 15:05, Chris Lingard wrote: > Carl-Daniel Hailfinger wrote: > > >> Thanks for testing. >> The output should be mostly identical on the first look, but not exactly >> identical. If it is exactly identical, the executed binary didn't >> contain the patch. >> I'm looking for the following output changes: >> >> >>> probe_spi: id1 0x7f, id2 0x9d7e >>> >> should become >> >>> probe_spi: id1 0x7f9d, id2 0x7e >>> >> and there should be three additional lines near the end: >> >>> Probing for PMC unknown SPI chip, 0 KB >>> WARNING: size: 0 -> 4096 (page size) >>> RDID returned 7f 9d 7d. >>> > > Sorry. Think I may have got it right now :-( > Yes, indeed. Thanks for the logs. You hit a bug in the existing code which was uncovered by my patch. Can you change the second line of probe_spi() in spi.c from uint8_t manuf_id; to uint32_t manuf_id; and post full results for the original chip again? This time it should find a generic PMC SPI chip. Regards, Carl-Daniel From chris at stockwith.co.uk Wed Feb 6 16:40:15 2008 From: chris at stockwith.co.uk (Chris Lingard) Date: Wed, 06 Feb 2008 15:40:15 +0000 Subject: [coreboot] Problem with M57SLI and newly installed MX25L4005 In-Reply-To: <47A9CB38.1050904@gmx.net> References: <47A77DCB.2070405@stockwith.co.uk> <47A908B4.7010105@gmx.net> <47A91F2A.7000609@gmx.net> <47A9B39E.6090101@stockwith.co.uk> <47A9B901.3030104@gmx.net> <47A9BE90.1090905@stockwith.co.uk> <47A9CB38.1050904@gmx.net> Message-ID: <47A9D4DF.8060402@stockwith.co.uk> Carl-Daniel Hailfinger wrote: > On 06.02.2008 15:05, Chris Lingard wrote: >> Carl-Daniel Hailfinger wrote: >> >> >>> Thanks for testing. >>> The output should be mostly identical on the first look, but not exactly >>> identical. If it is exactly identical, the executed binary didn't >>> contain the patch. >>> I'm looking for the following output changes: >>> >>> >>>> probe_spi: id1 0x7f, id2 0x9d7e >>>> >>> should become >>> >>>> probe_spi: id1 0x7f9d, id2 0x7e >>>> >>> and there should be three additional lines near the end: >>> >>>> Probing for PMC unknown SPI chip, 0 KB >>>> WARNING: size: 0 -> 4096 (page size) >>>> RDID returned 7f 9d 7d. >>>> >> Sorry. Think I may have got it right now :-( >> > > Yes, indeed. > > Thanks for the logs. You hit a bug in the existing code which was > uncovered by my patch. Can you change the second line of probe_spi() in > spi.c from > uint8_t manuf_id; > to > uint32_t manuf_id; > and post full results for the original chip again? This time it should > find a generic PMC SPI chip. > > Regards, > Carl-Daniel Am amazing prediction :-) Switch down bash-3.2# ./flashrom -m gigabyte:m57sli -V Calibrating delay loop... 830M loops per second. OK. No coreboot table found. Found chipset "NVIDIA MCP55", enabling flash write... OK. Found board "GIGABYTE GA-M57SLI-S4": enabling flash write... Serial flash segment 0xfffe0000-0xffffffff enabled Serial flash segment 0x000e0000-0x000fffff enabled Serial flash segment 0xffee0000-0xffefffff disabled Serial flash segment 0xfff80000-0xfffeffff enabled LPC write to serial flash enabled serial flash pin 29 OK. Probing for Am29F040B, 512 KB probe_29f040b: id1 0x49, id2 0x4d Probing for Am29LV040B, 512 KB probe_29f040b: id1 0x49, id2 0x4d Probing for Am29F016D, 2048 KB probe_29f040b: id1 0xff, id2 0xff Probing for AE49F2008, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for At29C040A, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for At29C020, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for At49F002(N), 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for At49F002(N)T, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for EN29F002(A)(N)T, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for EN29F002(A)(N)B, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for MBM29F400TC, 512 KB probe_m29f400bt: id1 0x49, id2 0x44 Probing for MX29F002, 256 KB probe_29f002: id1 0x83, id2 0x83 Probing for MX25L4005, 512 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for MX25L8005, 1024 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for MX25L3205, 4096 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for S25FL016A, 2048 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for SST25VF040B, 512 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for SST25VF016B, 2048 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for SST29EE020A, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST28SF040A, 512 KB probe_28sf040: id1 0x49, id2 0x4d Probing for SST39SF010A, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for SST39SF020A, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST39SF040, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for SST39VF020, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST49LF040B, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for SST49LF040, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for SST49LF020A, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST49LF080A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for SST49LF002A/B, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST49LF003A/B, 384 KB probe_jedec: id1 0x92, id2 0xdb Probing for SST49LF004A/B, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for SST49LF008A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for SST49LF004C, 512 KB probe_49lfxxxc: id1 0x49, id2 0x4d Probing for SST49LF008C, 1024 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for SST49LF016C, 2048 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for SST49LF160C, 2048 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for Pm49FL002, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for Pm49FL004, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for W29C011, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for W29C040P, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for W29C020C, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for W29EE011, 128 KB probe_w29ee011: id1 0xff, id2 0xff Probing for W49F002U, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for W49V002A, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for W49V002FA, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for W39V040FA, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for W39V040A, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for W39V040B, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for W39V080A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for W25x10, 128 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for W25x20, 256 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for W25x40, 512 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for W25x80, 1024 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for M29F002B, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for M50FW040, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for M29W040B, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for M29F002T/NT, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for M29F400BT, 512 KB probe_m29f400bt: id1 0x49, id2 0x44 Probing for M50FLW040A, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for M50FLW040B, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for M50FLW080A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FLW080B, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FW080, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FW016, 2048 KB probe_jedec: id1 0xff, id2 0xff Probing for M50LPW116, 2048 KB probe_jedec: id1 0xff, id2 0xff Probing for M29W010B, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for M29F040B, 512 KB probe_29f040b: id1 0x49, id2 0x4d Probing for M25P05-A, 64 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for M25P10-A, 128 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for M25P20, 256 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for M25P40, 512 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for M25P80, 1024 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for M25P16, 2048 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for M25P32, 4096 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for M25P64, 8192 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for M25P128, 16384 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for 82802ab, 512 KB probe_82802ab: id1 0x49, id2 0x4d Probing for 82802ac, 1024 KB probe_82802ab: id1 0xff, id2 0xff Probing for F49B002UA, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for LHF00L04, 1024 KB probe_lhf00l04: id1 0xff, id2 0xff Probing for S29C51001T, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for S29C51002T, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for S29C51004T, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for S29C31004T, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for EON unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for MX unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for PMC unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e PMC unknown SPI chip found at physical address 0x100000000. Flash part is PMC unknown SPI chip (0 KB). No operations were specified. bash-3.2# ./flashrom -m gigabyte:m57sli -V Calibrating delay loop... 830M loops per second. OK. No coreboot table found. Found chipset "NVIDIA MCP55", enabling flash write... OK. Found board "GIGABYTE GA-M57SLI-S4": enabling flash write... Serial flash segment 0xfffe0000-0xffffffff enabled Serial flash segment 0x000e0000-0x000fffff enabled Serial flash segment 0xffee0000-0xffefffff disabled Serial flash segment 0xfff80000-0xfffeffff enabled LPC write to serial flash enabled serial flash pin 29 OK. Probing for Am29F040B, 512 KB probe_29f040b: id1 0x49, id2 0x4d Probing for Am29LV040B, 512 KB probe_29f040b: id1 0x49, id2 0x4d Probing for Am29F016D, 2048 KB probe_29f040b: id1 0xff, id2 0xff Probing for AE49F2008, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for At29C040A, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for At29C020, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for At49F002(N), 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for At49F002(N)T, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for EN29F002(A)(N)T, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for EN29F002(A)(N)B, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for MBM29F400TC, 512 KB probe_m29f400bt: id1 0x49, id2 0x44 Probing for MX29F002, 256 KB probe_29f002: id1 0x83, id2 0x83 Probing for MX25L4005, 512 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for MX25L8005, 1024 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for MX25L3205, 4096 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for S25FL016A, 2048 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for SST25VF040B, 512 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for SST25VF016B, 2048 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for SST29EE020A, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST28SF040A, 512 KB probe_28sf040: id1 0x49, id2 0x4d Probing for SST39SF010A, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for SST39SF020A, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST39SF040, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for SST39VF020, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST49LF040B, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for SST49LF040, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for SST49LF020A, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST49LF080A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for SST49LF002A/B, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST49LF003A/B, 384 KB probe_jedec: id1 0x92, id2 0xdb Probing for SST49LF004A/B, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for SST49LF008A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for SST49LF004C, 512 KB probe_49lfxxxc: id1 0x49, id2 0x4d Probing for SST49LF008C, 1024 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for SST49LF016C, 2048 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for SST49LF160C, 2048 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for Pm49FL002, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for Pm49FL004, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for W29C011, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for W29C040P, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for W29C020C, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for W29EE011, 128 KB probe_w29ee011: id1 0xff, id2 0xff Probing for W49F002U, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for W49V002A, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for W49V002FA, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for W39V040FA, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for W39V040A, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for W39V040B, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for W39V080A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for W25x10, 128 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for W25x20, 256 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for W25x40, 512 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for W25x80, 1024 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for M29F002B, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for M50FW040, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for M29W040B, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for M29F002T/NT, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for M29F400BT, 512 KB probe_m29f400bt: id1 0x49, id2 0x44 Probing for M50FLW040A, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for M50FLW040B, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for M50FLW080A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FLW080B, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FW080, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FW016, 2048 KB probe_jedec: id1 0xff, id2 0xff Probing for M50LPW116, 2048 KB probe_jedec: id1 0xff, id2 0xff Probing for M29W010B, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for M29F040B, 512 KB probe_29f040b: id1 0x49, id2 0x4d Probing for M25P05-A, 64 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for M25P10-A, 128 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for M25P20, 256 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for M25P40, 512 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for M25P80, 1024 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for M25P16, 2048 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for M25P32, 4096 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for M25P64, 8192 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for M25P128, 16384 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for 82802ab, 512 KB probe_82802ab: id1 0x49, id2 0x4d Probing for 82802ac, 1024 KB probe_82802ab: id1 0xff, id2 0xff Probing for F49B002UA, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for LHF00L04, 1024 KB probe_lhf00l04: id1 0xff, id2 0xff Probing for S29C51001T, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for S29C51002T, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for S29C51004T, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for S29C31004T, 512 KB probe_jedec: id1 0x49, id2 0x4d Probing for EON unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for MX unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for PMC unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e PMC unknown SPI chip found at physical address 0x100000000. Flash part is PMC unknown SPI chip (0 KB). No operations were specified. Switch up bash-3.2# ./flashrom -m gigabyte:m57sli -V Calibrating delay loop... 863M loops per second. OK. No coreboot table found. Found chipset "NVIDIA MCP55", enabling flash write... OK. Found board "GIGABYTE GA-M57SLI-S4": enabling flash write... Serial flash segment 0xfffe0000-0xffffffff enabled Serial flash segment 0x000e0000-0x000fffff enabled Serial flash segment 0xffee0000-0xffefffff disabled Serial flash segment 0xfff80000-0xfffeffff enabled LPC write to serial flash enabled serial flash pin 29 OK. Probing for Am29F040B, 512 KB probe_29f040b: id1 0xff, id2 0xff Probing for Am29LV040B, 512 KB probe_29f040b: id1 0xff, id2 0xff Probing for Am29F016D, 2048 KB probe_29f040b: id1 0xff, id2 0xff Probing for AE49F2008, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for At29C040A, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for At29C020, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for At49F002(N), 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for At49F002(N)T, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for EN29F002(A)(N)T, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for EN29F002(A)(N)B, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for MBM29F400TC, 512 KB probe_m29f400bt: id1 0xff, id2 0xff Probing for MX29F002, 256 KB probe_29f002: id1 0x83, id2 0x83 Probing for MX25L4005, 512 KB RDID returned 7f 9d 7f. probe_spi: id1 0x7f9d, id2 0x7f Probing for MX25L8005, 1024 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f9d, id2 0x7d Probing for MX25L3205, 4096 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f9d, id2 0x7d Probing for S25FL016A, 2048 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f9d, id2 0x7d Probing for SST25VF040B, 512 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f9d, id2 0x7d Probing for SST25VF016B, 2048 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f9d, id2 0x7d Probing for SST29EE020A, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST28SF040A, 512 KB probe_28sf040: id1 0xff, id2 0xff Probing for SST39SF010A, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for SST39SF020A, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST39SF040, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for SST39VF020, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST49LF040B, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for SST49LF040, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for SST49LF020A, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST49LF080A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for SST49LF002A/B, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for SST49LF003A/B, 384 KB probe_jedec: id1 0x92, id2 0xdb Probing for SST49LF004A/B, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for SST49LF008A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for SST49LF004C, 512 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for SST49LF008C, 1024 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for SST49LF016C, 2048 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for SST49LF160C, 2048 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for Pm49FL002, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for Pm49FL004, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for W29C011, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for W29C040P, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for W29C020C, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for W29EE011, 128 KB probe_w29ee011: id1 0xff, id2 0xff Probing for W49F002U, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for W49V002A, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for W49V002FA, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for W39V040FA, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for W39V040A, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for W39V040B, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for W39V080A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for W25x10, 128 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f9d, id2 0x7d Probing for W25x20, 256 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f9d, id2 0x7d Probing for W25x40, 512 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f9d, id2 0x7d Probing for W25x80, 1024 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f9d, id2 0x7d Probing for M29F002B, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for M50FW040, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for M29W040B, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for M29F002T/NT, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for M29F400BT, 512 KB probe_m29f400bt: id1 0xff, id2 0xff Probing for M50FLW040A, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FLW040B, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FLW080A, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FLW080B, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FW080, 1024 KB probe_jedec: id1 0xff, id2 0xff Probing for M50FW016, 2048 KB probe_jedec: id1 0xff, id2 0xff Probing for M50LPW116, 2048 KB probe_jedec: id1 0xff, id2 0xff Probing for M29W010B, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for M29F040B, 512 KB probe_29f040b: id1 0xff, id2 0xff Probing for M25P05-A, 64 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f9d, id2 0x7d Probing for M25P10-A, 128 KB RDID returned 7f 9d 7e. probe_spi: id1 0x7f9d, id2 0x7e Probing for M25P20, 256 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f9d, id2 0x7d Probing for M25P40, 512 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f9d, id2 0x7d Probing for M25P80, 1024 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f9d, id2 0x7d Probing for M25P16, 2048 KB RDID returned 7f 9d 7f. probe_spi: id1 0x7f9d, id2 0x7f Probing for M25P32, 4096 KB RDID returned 7f 9d 7f. probe_spi: id1 0x7f9d, id2 0x7f Probing for M25P64, 8192 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f9d, id2 0x7d Probing for M25P128, 16384 KB RDID returned 7f 9d 7d. probe_spi: id1 0x7f9d, id2 0x7d Probing for 82802ab, 512 KB probe_82802ab: id1 0xff, id2 0xff Probing for 82802ac, 1024 KB probe_82802ab: id1 0xff, id2 0xff Probing for F49B002UA, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for LHF00L04, 1024 KB probe_lhf00l04: id1 0xff, id2 0xff Probing for S29C51001T, 128 KB probe_jedec: id1 0xff, id2 0xff Probing for S29C51002T, 256 KB probe_jedec: id1 0x83, id2 0x83 Probing for S29C51004T, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for S29C31004T, 512 KB probe_jedec: id1 0xff, id2 0xff Probing for EON unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned 7f 9d 7d. probe_spi: id1 0x7f9d, id2 0x7d Probing for MX unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned 7f 9d 7d. probe_spi: id1 0x7f9d, id2 0x7d Probing for PMC unknown SPI chip, 0 KB WARNING: size: 0 -> 4096 (page size) RDID returned 7f 9d 7d. probe_spi: id1 0x7f9d, id2 0x7d PMC unknown SPI chip found at physical address 0x100000000. Flash part is PMC unknown SPI chip (0 KB). No operations were specified. From rminnich at gmail.com Wed Feb 6 17:21:45 2008 From: rminnich at gmail.com (ron minnich) Date: Wed, 6 Feb 2008 08:21:45 -0800 Subject: [coreboot] patch: init gx cache earlier. In-Reply-To: <47A9BBEC.7030306@gmx.net> References: <13426df10802031249y5de2b5f4sd45039591aadc9a8@mail.gmail.com> <47A79F68.3040906@amd.com> <47A902C9.30001@gmx.net> <47A90FA6.5090805@AMD.com> <13426df10802051744v7c8af499rbf3227e64ed0319d@mail.gmail.com> <47A913C6.3070009@gmx.net> <47A91D90.4080605@AMD.com> <47A92624.5070805@gmx.net> <13426df10802052152p5ca2a710g4f6f4dc60a5ee03c@mail.gmail.com> <47A9BBEC.7030306@gmx.net> Message-ID: <13426df10802060821q7c1ec291x3917d91a89e611fe@mail.gmail.com> On Feb 6, 2008 5:53 AM, Carl-Daniel Hailfinger wrote: > I'm very interested in how well v3 compares against v2. The cleanliness > of v3 is great, but if it even comes with better speed, we have a really > strong selling point. Now there is a nice simple idea. Will try it tonight, but only after I get FILO to boot ... ron From mart.raudsepp at artecdesign.ee Wed Feb 6 17:30:23 2008 From: mart.raudsepp at artecdesign.ee (Mart Raudsepp) Date: Wed, 06 Feb 2008 18:30:23 +0200 Subject: [coreboot] [PATCH 1/2] flashrom: add support for AMD CS5536 devices with boot flash Message-ID: <1202315423.4809.22.camel@martr-gentoo.artec> This implements support for devices using AMD Geode companion chip CS5536 that have the Boot ROM on NOR flash that is directly connected to FLASH_CS3 (Boot Flash Chip Select). We need to write enable it in the NORF_CTL MSR register for flashrom to be able to write to it, including JEDEC probe commands. Signed-off-by: Mart Raudsepp --- This patch allows us to stop using AMD gx_utils.ko for BIOS flashing on the DBE61 chipset_enable.c | 43 +++++++++++++++++++++++++++++++++---------- 1 files changed, 33 insertions(+), 10 deletions(-) diff --git a/chipset_enable.c b/chipset_enable.c index 4cbb941..d6ef92e 100644 --- a/chipset_enable.c +++ b/chipset_enable.c @@ -228,6 +228,8 @@ static int enable_flash_cs5530(struct pci_dev *dev, const char *name) static int enable_flash_cs5536(struct pci_dev *dev, const char *name) { + #define MSR_NORF_CTL 0x51400018 + int fd_msr; unsigned char buf[8]; unsigned int addr = 0x1808; @@ -243,34 +245,55 @@ static int enable_flash_cs5536(struct pci_dev *dev, const char *name) * could have potential problems on SMP machines since it * assumes cpu0, but it is safe on the Geode which is not SMP. * + * Geode systems also write protects the NOR flash chip itself + * via MSR_NORF_CTL. To enable write to NOR Boot flash for the + * benefit of systems that have such a setup, raise + * MSR 0x51400018 WE_CS3 (write enable Boot Flash Chip Select). + * * This is probably not portable beyond Linux. */ - fd_msr = open("/dev/cpu/0/msr", O_RDONLY); + fd_msr = open("/dev/cpu/0/msr", O_RDWR); if (!fd_msr) { perror("open msr"); return -1; } lseek64(fd_msr, (off64_t) addr, SEEK_SET); read(fd_msr, buf, 8); - close(fd_msr); + + printf("Enabling Geode MSR to write to flash.\n"); + if (buf[7] != 0x22) { - printf("Enabling Geode MSR to write to flash.\n"); buf[7] &= 0xFB; - fd_msr = open("/dev/cpu/0/msr", O_WRONLY); - if (!fd_msr) { - perror("open msr"); - return -1; - } lseek64(fd_msr, (off64_t) addr, SEEK_SET); if (write(fd_msr, buf, 8) < 0) { perror("msr write"); printf - ("Cannot write to MSR. Make sure msr kernel is loaded: 'modprobe msr'\n"); + ("Cannot write to MSR. Make sure the msr kernel module is loaded: 'modprobe msr'\n"); return -1; } - close(fd_msr); } + + lseek64(fd_msr, (off64_t) MSR_NORF_CTL, SEEK_SET); + if (read(fd_msr, buf, 8) != 8) { + perror("read msr"); + return -1; + } + + /* Raise WE_CS3 bit */ + buf[0] |= 0x08; + + lseek64(fd_msr, (off64_t) MSR_NORF_CTL, SEEK_SET); + if (write(fd_msr, buf, 8) < 0) { + perror("msr write"); + printf + ("Cannot write to MSR. Make sure the msr kernel module is loaded: 'modprobe msr'\n"); + return -1; + } + + close(fd_msr); + + #undef MSR_NORF_CTL return 0; } -- 1.5.4 From mart.raudsepp at artecdesign.ee Wed Feb 6 17:31:13 2008 From: mart.raudsepp at artecdesign.ee (Mart Raudsepp) Date: Wed, 06 Feb 2008 18:31:13 +0200 Subject: [coreboot] [PATCH 2/2] flashrom: cleanups to enable_flash_cs5536 function Message-ID: <1202315473.4809.24.camel@martr-gentoo.artec> Improve error handling and make RCONF_DEFAULT_MSR address be a constant. Signed-off-by: Mart Raudsepp --- chipset_enable.c | 42 +++++++++++++++++++++++++++++++++++------- 1 files changed, 35 insertions(+), 7 deletions(-) diff --git a/chipset_enable.c b/chipset_enable.c index d6ef92e..f5a6612 100644 --- a/chipset_enable.c +++ b/chipset_enable.c @@ -228,11 +228,11 @@ static int enable_flash_cs5530(struct pci_dev *dev, const char *name) static int enable_flash_cs5536(struct pci_dev *dev, const char *name) { - #define MSR_NORF_CTL 0x51400018 + #define MSR_RCONF_DEFAULT 0x1808 + #define MSR_NORF_CTL 0x51400018 int fd_msr; unsigned char buf[8]; - unsigned int addr = 0x1808; /* Geode systems write protect the BIOS via RCONFs (cache * settings similar to MTRRs). To unlock, change MSR 0x1808 @@ -258,41 +258,69 @@ static int enable_flash_cs5536(struct pci_dev *dev, const char *name) perror("open msr"); return -1; } - lseek64(fd_msr, (off64_t) addr, SEEK_SET); - read(fd_msr, buf, 8); + + if (lseek64(fd_msr, (off64_t) MSR_RCONF_DEFAULT, SEEK_SET) == -1) { + perror("lseek64"); + close(fd_msr); + return -1; + } + + if (read(fd_msr, buf, 8) != 8) { + perror("read"); + close(fd_msr); + return -1; + } printf("Enabling Geode MSR to write to flash.\n"); if (buf[7] != 0x22) { buf[7] &= 0xFB; - lseek64(fd_msr, (off64_t) addr, SEEK_SET); + if (lseek64(fd_msr, (off64_t) MSR_RCONF_DEFAULT, SEEK_SET) == -1) { + perror("lseek64"); + close(fd_msr); + return -1; + } + if (write(fd_msr, buf, 8) < 0) { perror("msr write"); printf ("Cannot write to MSR. Make sure the msr kernel module is loaded: 'modprobe msr'\n"); + close(fd_msr); return -1; } } - lseek64(fd_msr, (off64_t) MSR_NORF_CTL, SEEK_SET); + if (lseek64(fd_msr, (off64_t) MSR_NORF_CTL, SEEK_SET) == -1) { + perror("lseek64"); + close(fd_msr); + return -1; + } + if (read(fd_msr, buf, 8) != 8) { perror("read msr"); + close(fd_msr); return -1; } /* Raise WE_CS3 bit */ buf[0] |= 0x08; - lseek64(fd_msr, (off64_t) MSR_NORF_CTL, SEEK_SET); + if (lseek64(fd_msr, (off64_t) MSR_NORF_CTL, SEEK_SET) == -1) { + perror("lseek64"); + close(fd_msr); + return -1; + } if (write(fd_msr, buf, 8) < 0) { perror("msr write"); printf ("Cannot write to MSR. Make sure the msr kernel module is loaded: 'modprobe msr'\n"); + close(fd_msr); return -1; } close(fd_msr); + #undef MSR_RCONF_DEFAULT #undef MSR_NORF_CTL return 0; } -- 1.5.4 From marc.jones at amd.com Wed Feb 6 17:31:00 2008 From: marc.jones at amd.com (Marc Jones) Date: Wed, 06 Feb 2008 09:31:00 -0700 Subject: [coreboot] r574 - coreboot-v3/mainboard/emulation/qemu-x86 In-Reply-To: <20080206031306.229EB5C0050@mail83-va3.bigfish.com> References: <20080206031306.229EB5C0050@mail83-va3.bigfish.com> Message-ID: <47A9E0C4.7080200@amd.com> svn at coreboot.org wrote: > Author: hailfinger > Date: 2008-02-06 04:12:53 +0100 (Wed, 06 Feb 2008) > New Revision: 574 > > -void pre_payload(void) > +void mainboard_pre_payload(void) > { > } Thanks... -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From c-d.hailfinger.devel.2006 at gmx.net Wed Feb 6 18:04:12 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 06 Feb 2008 18:04:12 +0100 Subject: [coreboot] [PATCH] flashrom: Support Pm25LV* Message-ID: <47A9E88C.2060606@gmx.net> Chris: Please try this against latest flashrom with the switch in both positions. It supersedes all previous patches. Handle JEDEC JEP106W continuation codes in SPI RDID. Some vendors like Programmable Micro Corp need this. Both the serial and parallel flash JEDEC detection routines would benefit from a parity/sanity check of the vendor ID. Will do this later. Add untested support for the PMC Pm25LV family of SPI flash chips. Signed-off-by: Carl-Daniel Hailfinger http://www.hailfinger.org/ Index: flashrom-spi_pm25/flash.h =================================================================== --- flashrom-spi_pm25/flash.h (Revision 3090) +++ flashrom-spi_pm25/flash.h (Arbeitskopie) @@ -158,7 +158,20 @@ /* Programmable Micro Corp is listed in JEP106W in bank 2, so it should have * a 0x7F continuation code prefix. */ -#define PMC_ID 0x9D /* PMC */ +#define PMC_ID 0x7F9D /* PMC */ +#define PMC_ID_NOPREFIX 0x9D /* PMC, missing 0x7F prefix */ +#define PMC_25LV512 0x7B +#define PMC_25LV010 0x7C +#define PMC_25LV020 0x7D +#define PMC_25LV040 0x7E +#define PMC_25LV080B 0x13 +#define PMC_25LV016B 0x14 +#define PMC_39LV512 0x1B +#define PMC_39F010 0x1C /* also Pm39LV010 */ +#define PMC_39LV020 0x3D +#define PMC_39LV040 0x3E +#define PMC_39F020 0x4D +#define PMC_39F040 0x4E #define PMC_49FL002 0x6D #define PMC_49FL004 0x6E Index: flashrom-spi_pm25/flashchips.c =================================================================== --- flashrom-spi_pm25/flashchips.c (Revision 3090) +++ flashrom-spi_pm25/flashchips.c (Arbeitskopie) @@ -100,10 +100,22 @@ probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, {"SST49LF160C", SST_ID, SST_49LF160C, 2048, 4 * 1024 , probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, - {"Pm49FL002", PMC_ID, PMC_49FL002, 256, 16 * 1024, + {"Pm49FL002", PMC_ID_NOPREFIX, PMC_49FL002, 256, 16 * 1024, probe_jedec, erase_chip_jedec, write_49fl004}, - {"Pm49FL004", PMC_ID, PMC_49FL004, 512, 64 * 1024, + {"Pm49FL004", PMC_ID_NOPREFIX, PMC_49FL004, 512, 64 * 1024, probe_jedec, erase_chip_jedec, write_49fl004}, + {"Pm25LV512", PMC_ID, PMC_25LV512, 64, 256, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Pm25LV010", PMC_ID, PMC_25LV010, 128, 256, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Pm25LV020", PMC_ID, PMC_25LV020, 256, 256, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Pm25LV040", PMC_ID, PMC_25LV040, 512, 256, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Pm25LV080B", PMC_ID, PMC_25LV080B, 1024, 256, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Pm25LV016B", PMC_ID, PMC_25LV016B, 2048, 256, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, {"W29C011", WINBOND_ID, W_29C011, 128, 128, probe_jedec, erase_chip_jedec, write_jedec}, {"W29C040P", WINBOND_ID, W_29C040P, 512, 256, @@ -205,6 +217,8 @@ probe_spi, NULL, NULL}, {"MX unknown SPI chip", MX_ID, GENERIC_DEVICE_ID, 0, 0, probe_spi, NULL, NULL}, + {"PMC unknown SPI chip", PMC_ID, GENERIC_DEVICE_ID, 0, 0, + probe_spi, NULL, NULL}, {"SST unknown SPI chip", SST_ID, GENERIC_DEVICE_ID, 0, 0, probe_spi, NULL, NULL}, {"ST unknown SPI chip", ST_ID, GENERIC_DEVICE_ID, 0, 0, Index: flashrom-spi_pm25/spi.c =================================================================== --- flashrom-spi_pm25/spi.c (Revision 3090) +++ flashrom-spi_pm25/spi.c (Arbeitskopie) @@ -278,11 +278,17 @@ int probe_spi(struct flashchip *flash) { unsigned char readarr[3]; - uint8_t manuf_id; - uint16_t model_id; + uint32_t manuf_id; + uint32_t model_id; if (!generic_spi_rdid(readarr)) { - manuf_id = readarr[0]; - model_id = (readarr[1] << 8) | readarr[2]; + /* Check if this is a continuation vendor ID */ + if (readarr[0] == 0x7f) { + manuf_id = (readarr[0] << 8) | readarr[1]; + model_id = readarr[2]; + } else { + manuf_id = readarr[0]; + model_id = (readarr[1] << 8) | readarr[2]; + } printf_debug("%s: id1 0x%x, id2 0x%x\n", __FUNCTION__, manuf_id, model_id); if (manuf_id == flash->manufacture_id && model_id == flash->model_id) { From c-d.hailfinger.devel.2006 at gmx.net Wed Feb 6 18:19:08 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 06 Feb 2008 18:19:08 +0100 Subject: [coreboot] Problem with M57SLI and newly installed MX25L4005 In-Reply-To: <47A9D4DF.8060402@stockwith.co.uk> References: <47A77DCB.2070405@stockwith.co.uk> <47A908B4.7010105@gmx.net> <47A91F2A.7000609@gmx.net> <47A9B39E.6090101@stockwith.co.uk> <47A9B901.3030104@gmx.net> <47A9BE90.1090905@stockwith.co.uk> <47A9CB38.1050904@gmx.net> <47A9D4DF.8060402@stockwith.co.uk> Message-ID: <47A9EC0C.8080507@gmx.net> On 06.02.2008 16:40, Chris Lingard wrote: > Carl-Daniel Hailfinger wrote: > >> On 06.02.2008 15:05, Chris Lingard wrote: >> >>> Carl-Daniel Hailfinger wrote: >>> >>> >>> >>>> Thanks for testing. >>>> The output should be mostly identical on the first look, but not exactly >>>> identical. If it is exactly identical, the executed binary didn't >>>> contain the patch. >>>> I'm looking for the following output changes: >>>> >>>> >>>> >>>>> probe_spi: id1 0x7f, id2 0x9d7e >>>>> >>>>> >>>> should become >>>> >>>> >>>>> probe_spi: id1 0x7f9d, id2 0x7e >>>>> >>>>> >>>> and there should be three additional lines near the end: >>>> >>>> >>>>> Probing for PMC unknown SPI chip, 0 KB >>>>> WARNING: size: 0 -> 4096 (page size) >>>>> RDID returned 7f 9d 7d. >>>>> >>>>> >>> Sorry. Think I may have got it right now :-( >>> >>> >> Yes, indeed. >> >> Thanks for the logs. You hit a bug in the existing code which was >> uncovered by my patch. Can you change the second line of probe_spi() in >> spi.c from >> uint8_t manuf_id; >> to >> uint32_t manuf_id; >> and post full results for the original chip again? This time it should >> find a generic PMC SPI chip. >> >> Regards, >> Carl-Daniel >> > > Am amazing prediction :-) > Thanks. I like it when I'm right ;-) > Switch down > bash-3.2# ./flashrom -m gigabyte:m57sli -V > Found chipset "NVIDIA MCP55", enabling flash write... OK. > Found board "GIGABYTE GA-M57SLI-S4": enabling flash write... Serial > [...] > Probing for PMC unknown SPI chip, 0 KB > WARNING: size: 0 -> 4096 (page size) > RDID returned 7f 9d 7e. > probe_spi: id1 0x7f9d, id2 0x7e > PMC unknown SPI chip found at physical address 0x100000000. > Flash part is PMC unknown SPI chip (0 KB). > No operations were specified. > OK, so the generic detection works for the first chip. > bash-3.2# ./flashrom -m gigabyte:m57sli -V > Found chipset "NVIDIA MCP55", enabling flash write... OK. > Found board "GIGABYTE GA-M57SLI-S4": enabling flash write... Serial > [...] > Probing for PMC unknown SPI chip, 0 KB > WARNING: size: 0 -> 4096 (page size) > RDID returned 7f 9d 7e. > probe_spi: id1 0x7f9d, id2 0x7e > PMC unknown SPI chip found at physical address 0x100000000. > Flash part is PMC unknown SPI chip (0 KB). > No operations were specified. > Same log as above, maybe double cut-n-paste? > Switch up > > > bash-3.2# ./flashrom -m gigabyte:m57sli -V > Found chipset "NVIDIA MCP55", enabling flash write... OK. > Found board "GIGABYTE GA-M57SLI-S4": enabling flash write... Serial > [...] > Probing for PMC unknown SPI chip, 0 KB > WARNING: size: 0 -> 4096 (page size) > RDID returned 7f 9d 7d. > probe_spi: id1 0x7f9d, id2 0x7d > PMC unknown SPI chip found at physical address 0x100000000. > Flash part is PMC unknown SPI chip (0 KB). > No operations were specified. > Second chip detected with the generic routine as well. Can you try the patch I posted in a separate thread with subject "[PATCH] flashrom: Support Pm25LV*"? I only need normal flashrom output (without -V) unless a chip is detected as "PMC unknown SPI chip". If it works for you, can you please ack the patch? More details about acking at http://www.coreboot.org/Development_Guidelines sections "Sign-off Procedure" and "Reviews". Regards, Carl-Daniel -- http://www.hailfinger.org/ From marc.jones at amd.com Wed Feb 6 18:29:32 2008 From: marc.jones at amd.com (Marc Jones) Date: Wed, 06 Feb 2008 10:29:32 -0700 Subject: [coreboot] [patch] Build error with top of tree V2 In-Reply-To: References: <47A8BB62.6050501@amd.com> Message-ID: <47A9EE7C.3040601@amd.com> Clay Jones wrote: > I found the problem. The wrong ar command was being used because the > make file does not have " $(CROSS_COMPILE)" in front of the ar command. > I think this might fix the problem. You will need to run buildtarget again. I hope some of the make experts to chime in on this. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ar_crosscomp.patch URL: From peter at stuge.se Wed Feb 6 18:10:23 2008 From: peter at stuge.se (Peter Stuge) Date: Wed, 6 Feb 2008 18:10:23 +0100 Subject: [coreboot] Problem with M57SLI and newly installed MX25L4005 In-Reply-To: <47A9D4DF.8060402@stockwith.co.uk> References: <47A77DCB.2070405@stockwith.co.uk> <47A908B4.7010105@gmx.net> <47A91F2A.7000609@gmx.net> <47A9B39E.6090101@stockwith.co.uk> <47A9B901.3030104@gmx.net> <47A9BE90.1090905@stockwith.co.uk> <47A9CB38.1050904@gmx.net> <47A9D4DF.8060402@stockwith.co.uk> Message-ID: <20080206171023.18732.qmail@stuge.se> On Wed, Feb 06, 2008 at 03:40:15PM +0000, Chris Lingard wrote: > Switch down > bash-3.2# ./flashrom -m gigabyte:m57sli -V .. > probe_spi: id1 0x7f9d, id2 0x7e > Probing for PMC unknown SPI chip, 0 KB > WARNING: size: 0 -> 4096 (page size) > RDID returned 7f 9d 7e. > probe_spi: id1 0x7f9d, id2 0x7e > PMC unknown SPI chip found at physical address 0x100000000. > Flash part is PMC unknown SPI chip (0 KB). Executing same a second time - with switch still down it seems. > bash-3.2# ./flashrom -m gigabyte:m57sli -V .. > probe_spi: id1 0x7f9d, id2 0x7e > Probing for PMC unknown SPI chip, 0 KB > WARNING: size: 0 -> 4096 (page size) > RDID returned 7f 9d 7e. > probe_spi: id1 0x7f9d, id2 0x7e > PMC unknown SPI chip found at physical address 0x100000000. > Flash part is PMC unknown SPI chip (0 KB). Then throw the switch: > Switch up > bash-3.2# ./flashrom -m gigabyte:m57sli -V .. > probe_spi: id1 0x7f9d, id2 0x7d > Probing for PMC unknown SPI chip, 0 KB > WARNING: size: 0 -> 4096 (page size) > RDID returned 7f 9d 7d. > probe_spi: id1 0x7f9d, id2 0x7d > PMC unknown SPI chip found at physical address 0x100000000. > Flash part is PMC unknown SPI chip (0 KB). This is rather strange. You're using an MX chip but it identifies itself as PMC. Is the RDID byteorder messed up? //Peter From svn at coreboot.org Wed Feb 6 18:47:16 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Wed, 6 Feb 2008 18:47:16 +0100 Subject: [coreboot] r105 - buildrom-devel/bin Message-ID: Author: ward Date: 2008-02-06 18:47:15 +0100 (Wed, 06 Feb 2008) New Revision: 105 Modified: buildrom-devel/bin/fetchsvn.sh Log: This fixes a subtle bug in the fetchsvn.sh script. Because of the use of an exit statement in a subshell, the script did not abort when an svn update failed, leading to tarballs that claimed to be some svn revision but were really some other revision... This is a trivial patch. Signed-off-by: Ward Vandewege Acked-by: Ward Vandewege Modified: buildrom-devel/bin/fetchsvn.sh =================================================================== --- buildrom-devel/bin/fetchsvn.sh 2008-02-01 23:17:26 UTC (rev 104) +++ buildrom-devel/bin/fetchsvn.sh 2008-02-06 17:47:15 UTC (rev 105) @@ -32,6 +32,16 @@ echo "Couldn't update the repository." exit 1 }) + if [ `echo $?` -ne 0 ]; then + # The parentheses around the cd $DIR/svn; svn update ... commands above + # cause those commands to be executed as a list, in a subshell. As a + # consequence, if something goes wrong the exit command exits the + # subshell, not the script. And that means that the tar command below was + # still being executed even if the svn checkout failed, which could lead + # to nasty, nasty situations where we had a tarball that claimed to be a + # certain SVN revision, but was really some other revision... + exit 1 + fi fi fi From uwe at hermann-uwe.de Wed Feb 6 18:51:15 2008 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Wed, 6 Feb 2008 18:51:15 +0100 Subject: [coreboot] [patch] Build error with top of tree V2 In-Reply-To: <47A9EE7C.3040601@amd.com> References: <47A9EE7C.3040601@amd.com> Message-ID: <20080206175115.GA10566@greenwood> On Wed, Feb 06, 2008 at 10:29:32AM -0700, Marc Jones wrote: > Cross compile flags were missing for ar to create coreboot.a. > > Signed-off-by: Marc Jones > > Index: coreboot-v2/src/config/Config.lb > =================================================================== > --- coreboot-v2.orig/src/config/Config.lb 2008-02-06 10:17:43.000000000 -0700 > +++ coreboot-v2/src/config/Config.lb 2008-02-06 10:17:22.000000000 -0700 > @@ -35,7 +35,7 @@ > makerule coreboot.a > depends "$(OBJECTS)" > action "rm -f coreboot.a" > - action "ar cr coreboot.a $(OBJECTS)" > + action "$(CROSS_COMPILE) ar cr coreboot.a $(OBJECTS)" > end Untested, but I'm pretty sure that there should _not_ be a space in there. Better: action "$(CROSS_COMPILE)ar cr coreboot.a $(OBJECTS)" Someone should actually test this, though. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org From c.jones at f5.com Wed Feb 6 18:53:53 2008 From: c.jones at f5.com (Clay Jones) Date: Wed, 6 Feb 2008 09:53:53 -0800 Subject: [coreboot] [patch] Build error with top of tree V2 In-Reply-To: <47A9EE7C.3040601@amd.com> References: <47A8BB62.6050501@amd.com> <47A9EE7C.3040601@amd.com> Message-ID: That is the right place but you need to remove the space after the ) like this + action "$(CROSS_COMPILE) ar cr coreboot.a $(OBJECTS)" To + action "$(CROSS_COMPILE)ar cr coreboot.a $(OBJECTS)" -----Original Message----- From: Marc Jones [mailto:marc.jones at amd.com] Sent: Wednesday, February 06, 2008 9:30 AM To: Clay Jones Cc: coreboot at coreboot.org Subject: Re: [coreboot] [patch] Build error with top of tree V2 Clay Jones wrote: > I found the problem. The wrong ar command was being used because the > make file does not have " $(CROSS_COMPILE)" in front of the ar command. > I think this might fix the problem. You will need to run buildtarget again. I hope some of the make experts to chime in on this. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From peter at stuge.se Wed Feb 6 18:23:32 2008 From: peter at stuge.se (Peter Stuge) Date: Wed, 6 Feb 2008 18:23:32 +0100 Subject: [coreboot] Run PCI rom before PCI bus scan?? In-Reply-To: References: <20080202203430.1p2at6gtc0skw0so@www.smittys.pointclark.net> <20080203183738.GA4289@coresystems.de> <20080203144443.q9r9b16s00wgk8k0@www.smittys.pointclark.net> <47A62410.90805@gmail.com> <20080203181552.tybs70ow5c4osoo4@www.smittys.pointclark.net> <20080204074936.4q1bevm7ksggowsk@www.smittys.pointclark.net> <47A75095.3070109@assembler.cz> <20080205105139.rhwr4w0eg0gg0wws@www.smittys.pointclark.net> <20080205164448.26302.qmail@stuge.se> Message-ID: <20080206172332.21955.qmail@stuge.se> On Tue, Feb 05, 2008 at 02:49:52PM -0500, Corey Osgood wrote: > "In the LAN controller the D0 state is partitioned into two substates > > and > > "The integrated LAN controller will be disabled if no Platform LAN > Connect component is detected (See Section 5.2.1.3)." > > > Any help? The first one isn't that interesting since it also implies that PCI config regs are actually available. The second one, or rather section 5.2.1.3, could be interesting if "Platform LAN Connect component" is usually found in the BIOS. //Peter From uwe at hermann-uwe.de Wed Feb 6 19:05:46 2008 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Wed, 6 Feb 2008 19:05:46 +0100 Subject: [coreboot] flashrom: Add board enable for VIA EPIA SP. In-Reply-To: <20080205204718.GA32021@skynet.be> References: <20080205204718.GA32021@skynet.be> Message-ID: <20080206180546.GB10566@greenwood> On Tue, Feb 05, 2008 at 09:47:18PM +0100, Luc Verhaegen wrote: > + dev = pci_dev_find(0x1106, 0x3227); /* VT8237 ISA bridge */ Is this really meant to be VT8237 or should it be VT8237R? > + if (!dev) { > + fprintf(stderr, "\nERROR: VT8237 ISA bridge not found.\n"); Ditto. > + return -1; > + } > + > + /* All memory cycles, not just ROM ones, go to LPC */ > + val = pci_read_byte(dev, 0x59); > + val &= ~0x80; Just some cosmetics: I personally find the val &= ~(1 << 7); notation clearer for manipulating bits. Otherwise this looks good. With the above changes: Acked-by: Uwe Hermann If nobody complains I'll commit with the changes above. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org From c-d.hailfinger.devel.2006 at gmx.net Wed Feb 6 19:09:40 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 06 Feb 2008 19:09:40 +0100 Subject: [coreboot] Problem with M57SLI and newly installed MX25L4005 In-Reply-To: <20080206171023.18732.qmail@stuge.se> References: <47A77DCB.2070405@stockwith.co.uk> <47A908B4.7010105@gmx.net> <47A91F2A.7000609@gmx.net> <47A9B39E.6090101@stockwith.co.uk> <47A9B901.3030104@gmx.net> <47A9BE90.1090905@stockwith.co.uk> <47A9CB38.1050904@gmx.net> <47A9D4DF.8060402@stockwith.co.uk> <20080206171023.18732.qmail@stuge.se> Message-ID: <47A9F7E4.9070009@gmx.net> On 06.02.2008 18:10, Peter Stuge wrote: > On Wed, Feb 06, 2008 at 03:40:15PM +0000, Chris Lingard wrote: > >> Switch down >> bash-3.2# ./flashrom -m gigabyte:m57sli -V >> > .. > >> probe_spi: id1 0x7f9d, id2 0x7e >> Probing for PMC unknown SPI chip, 0 KB >> WARNING: size: 0 -> 4096 (page size) >> RDID returned 7f 9d 7e. >> probe_spi: id1 0x7f9d, id2 0x7e >> PMC unknown SPI chip found at physical address 0x100000000. >> Flash part is PMC unknown SPI chip (0 KB). >> > >> Switch up >> bash-3.2# ./flashrom -m gigabyte:m57sli -V >> > .. > >> probe_spi: id1 0x7f9d, id2 0x7d >> Probing for PMC unknown SPI chip, 0 KB >> WARNING: size: 0 -> 4096 (page size) >> RDID returned 7f 9d 7d. >> probe_spi: id1 0x7f9d, id2 0x7d >> PMC unknown SPI chip found at physical address 0x100000000. >> Flash part is PMC unknown SPI chip (0 KB). >> > > > This is rather strange. You're using an MX chip but it identifies > itself as PMC. Is the RDID byteorder messed up? > I'm pretty sure the byteorder is OK. Even if the byteorder was messed up, a Macronix chip should have 0xC2 in there somewhere. Three possible explanations: - the switch does not work as intended - the chip has been relabeled - we are reading garbage from the SuperIO. Regards, Carl-Daniel From marc.jones at amd.com Wed Feb 6 19:09:42 2008 From: marc.jones at amd.com (Marc Jones) Date: Wed, 06 Feb 2008 11:09:42 -0700 Subject: [coreboot] [patch] Build error with top of tree V2 In-Reply-To: References: <47A8BB62.6050501@amd.com> <47A9EE7C.3040601@amd.com> Message-ID: <47A9F7E6.1060703@amd.com> Clay Jones wrote: > That is the right place but you need to remove the space after the ) > like this > > + action "$(CROSS_COMPILE)ar cr coreboot.a $(OBJECTS)" > Fixed. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ar_crosscomp.patch URL: From peter at stuge.se Wed Feb 6 18:45:39 2008 From: peter at stuge.se (Peter Stuge) Date: Wed, 6 Feb 2008 18:45:39 +0100 Subject: [coreboot] flashrom: Add board enable for VIA EPIA SP. In-Reply-To: <20080205204718.GA32021@skynet.be> References: <20080205204718.GA32021@skynet.be> Message-ID: <20080206174539.27259.qmail@stuge.se> On Tue, Feb 05, 2008 at 09:47:18PM +0100, Luc Verhaegen wrote: > Flashrom: Add board enable for VIA EPIA SP. > > Signed-off-by: Luc Verhaegen If it works: (I can't test) Acked-by: Peter Stuge > Index: board_enable.c > =================================================================== > --- board_enable.c (revision 3089) > +++ board_enable.c (working copy) > @@ -3,7 +3,7 @@ > * > * Copyright (C) 2005-2007 coresystems GmbH > * Copyright (C) 2006 Uwe Hermann > - * Copyright (C) 2007 Luc Verhaegen > + * Copyright (C) 2007-2008 Luc Verhaegen > * Copyright (C) 2007 Carl-Daniel Hailfinger > * > * This program is free software; you can redistribute it and/or modify > @@ -213,6 +213,28 @@ > } > > /** > + * Suited for VIAs EPIA SP. > + */ > +static int board_via_epia_sp(const char *name) > +{ > + struct pci_dev *dev; > + uint8_t val; > + > + dev = pci_dev_find(0x1106, 0x3227); /* VT8237 ISA bridge */ > + if (!dev) { > + fprintf(stderr, "\nERROR: VT8237 ISA bridge not found.\n"); > + return -1; > + } > + > + /* All memory cycles, not just ROM ones, go to LPC */ > + val = pci_read_byte(dev, 0x59); > + val &= ~0x80; > + pci_write_byte(dev, 0x59, val); > + > + return 0; > +} > + > +/** > * Suited for ASUS P5A. > * > * This is rather nasty code, but there's no way to do this cleanly. > @@ -393,6 +415,8 @@ > NULL, NULL, "VIA EPIA M/MII/...", board_via_epia_m}, > {0x1106, 0x3177, 0x1043, 0x80A1, 0x1106, 0x3205, 0x1043, 0x8118, > NULL, NULL, "ASUS A7V8-MX SE", board_asus_a7v8x_mx}, > + {0x1106, 0x3227, 0x1106, 0xAA01, 0x1106, 0x0259, 0x1106, 0xAA01, > + NULL, NULL, "VIA EPIA SP", board_via_epia_sp}, > {0x8086, 0x1076, 0x8086, 0x1176, 0x1106, 0x3059, 0x10f1, 0x2498, > NULL, NULL, "Tyan Tomcat K7M", board_asus_a7v8x_mx}, > {0x10B9, 0x1541, 0x0000, 0x0000, 0x10B9, 0x1533, 0x0000, 0x0000, > -- > coreboot mailing list > coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot From chris at stockwith.co.uk Wed Feb 6 19:20:51 2008 From: chris at stockwith.co.uk (Chris Lingard) Date: Wed, 06 Feb 2008 18:20:51 +0000 Subject: [coreboot] Problem with M57SLI and newly installed MX25L4005 In-Reply-To: <47A9EC0C.8080507@gmx.net> References: <47A77DCB.2070405@stockwith.co.uk> <47A908B4.7010105@gmx.net> <47A91F2A.7000609@gmx.net> <47A9B39E.6090101@stockwith.co.uk> <47A9B901.3030104@gmx.net> <47A9BE90.1090905@stockwith.co.uk> <47A9CB38.1050904@gmx.net> <47A9D4DF.8060402@stockwith.co.uk> <47A9EC0C.8080507@gmx.net> Message-ID: <47A9FA83.1020109@stockwith.co.uk> Carl-Daniel Hailfinger wrote: > Can you try the patch I posted in a separate thread with subject > "[PATCH] flashrom: Support Pm25LV*"? > > I only need normal flashrom output (without -V) unless a chip is > detected as "PMC unknown SPI chip". > If it works for you, can you please ack the patch? More details about > acking at http://www.coreboot.org/Development_Guidelines sections > "Sign-off Procedure" > and > "Reviews". > > Regards, > Carl-Daniel > Fantastic, output at last Switch up Calibrating delay loop... OK. No coreboot table found. Found chipset "NVIDIA MCP55", enabling flash write... OK. Found board "GIGABYTE GA-M57SLI-S4": enabling flash write... Serial flash segment 0xfffe0000-0xffffffff enabled Serial flash segment 0x000e0000-0x000fffff enabled Serial flash segment 0xffee0000-0xffefffff disabled Serial flash segment 0xfff80000-0xfffeffff enabled LPC write to serial flash enabled serial flash pin 29 OK. Pm25LV020 found at physical address 0xfffc0000. Flash part is Pm25LV020 (256 KB). No operations were specified. Switch down Calibrating delay loop... OK. No coreboot table found. Found chipset "NVIDIA MCP55", enabling flash write... OK. Found board "GIGABYTE GA-M57SLI-S4": enabling flash write... Serial flash segment 0xfffe0000-0xffffffff enabled Serial flash segment 0x000e0000-0x000fffff enabled Serial flash segment 0xffee0000-0xffefffff disabled Serial flash segment 0xfff80000-0xfffeffff enabled LPC write to serial flash enabled serial flash pin 29 OK. Pm25LV040 found at physical address 0xfff80000. Flash part is Pm25LV040 (512 KB). No operations were specified. Though I am still pretty sure that I have a MX25L4005A, because this is what Harald wrote on the packet From peter at stuge.se Wed Feb 6 18:54:44 2008 From: peter at stuge.se (Peter Stuge) Date: Wed, 6 Feb 2008 18:54:44 +0100 Subject: [coreboot] Coreboot-v2 patch rom names In-Reply-To: <2831fecf0802051320h8e96311k6bc636cf6856163d@mail.gmail.com> References: <2831fecf0802051320h8e96311k6bc636cf6856163d@mail.gmail.com> Message-ID: <20080206175444.29969.qmail@stuge.se> On Tue, Feb 05, 2008 at 02:20:06PM -0700, Myles Watson wrote: > The correct place for Config.lb files is in the coreboot-v2 tree. So obvious when you write it out. :) > The next patch would add Config-lab.lb files for each architecture > supported by buildrom. I like it! //Peter From ward at gnu.org Wed Feb 6 19:34:12 2008 From: ward at gnu.org (Ward Vandewege) Date: Wed, 6 Feb 2008 13:34:12 -0500 Subject: [coreboot] Coreboot-v2 patch rom names In-Reply-To: <2831fecf0802051320h8e96311k6bc636cf6856163d@mail.gmail.com> References: <2831fecf0802051320h8e96311k6bc636cf6856163d@mail.gmail.com> Message-ID: <20080206183412.GA18240@localdomain> On Tue, Feb 05, 2008 at 02:20:06PM -0700, Myles Watson wrote: > This patch changes all rom names that aren't coreboot.rom in Config.lb files. > > I think that since the directory specifies the architecture and the > board, it is redundant information to name it something else, and it > makes it more difficult to automate the build process (buildrom). Great. > In buildrom we should just use Config-options.lb files instead of > patching or keeping our own. It just adds more to maintain, with very > little benefit. The correct place for Config.lb files is in the > coreboot-v2 tree. > > The next patch would add Config-lab.lb files for each architecture > supported by buildrom. That would work - but what about other payloads? Maybe we could use a naming scheme like Config-buildrom-$(PAYLOAD).lb and then make buildrom look for such a file, perhaps falling back to the generic Config.lb file if it does not exist? Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From libv at skynet.be Wed Feb 6 19:47:06 2008 From: libv at skynet.be (Luc Verhaegen) Date: Wed, 6 Feb 2008 19:47:06 +0100 Subject: [coreboot] flashrom: Add board enable for VIA EPIA SP. In-Reply-To: <20080206174539.27259.qmail@stuge.se> References: <20080205204718.GA32021@skynet.be> <20080206174539.27259.qmail@stuge.se> Message-ID: <20080206184706.GA3747@skynet.be> On Wed, Feb 06, 2008 at 06:45:39PM +0100, Peter Stuge wrote: > On Tue, Feb 05, 2008 at 09:47:18PM +0100, Luc Verhaegen wrote: > > Flashrom: Add board enable for VIA EPIA SP. > > > > Signed-off-by: Luc Verhaegen > > If it works: (I can't test) > > Acked-by: Peter Stuge Yeah, it does, i needed the SP to flash a similar FWH rom for another machine. That other machine now works, after stumbling over the "remove jumper first, you idiot" bit, so it has been tested fruitfully :) Luc Verhaegen. SUSE/Novell Driver Developer. From chris at stockwith.co.uk Wed Feb 6 19:14:00 2008 From: chris at stockwith.co.uk (Chris Lingard) Date: Wed, 06 Feb 2008 18:14:00 +0000 Subject: [coreboot] [PATCH] flashrom: Support Pm25LV* In-Reply-To: <47A9E88C.2060606@gmx.net> References: <47A9E88C.2060606@gmx.net> Message-ID: <47A9F8E8.2080200@stockwith.co.uk> Carl-Daniel Hailfinger wrote: > Chris: Please try this against latest flashrom with the switch in both > positions. It supersedes all previous patches. > > Handle JEDEC JEP106W continuation codes in SPI RDID. Some vendors like > Programmable Micro Corp need this. > Both the serial and parallel flash JEDEC detection routines would > benefit from a parity/sanity check of the vendor ID. Will do this later. > > Add untested support for the PMC Pm25LV family of SPI flash chips. > > Signed-off-by: Carl-Daniel Hailfinger > > http://www.hailfinger.org/ > > Index: flashrom-spi_pm25/flash.h > =================================================================== > --- flashrom-spi_pm25/flash.h (Revision 3090) > +++ flashrom-spi_pm25/flash.h (Arbeitskopie) > @@ -158,7 +158,20 @@ > /* Programmable Micro Corp is listed in JEP106W in bank 2, so it should have > * a 0x7F continuation code prefix. > */ > -#define PMC_ID 0x9D /* PMC */ > +#define PMC_ID 0x7F9D /* PMC */ > +#define PMC_ID_NOPREFIX 0x9D /* PMC, missing 0x7F prefix */ > +#define PMC_25LV512 0x7B > +#define PMC_25LV010 0x7C > +#define PMC_25LV020 0x7D > +#define PMC_25LV040 0x7E > +#define PMC_25LV080B 0x13 > +#define PMC_25LV016B 0x14 > +#define PMC_39LV512 0x1B > +#define PMC_39F010 0x1C /* also Pm39LV010 */ > +#define PMC_39LV020 0x3D > +#define PMC_39LV040 0x3E > +#define PMC_39F020 0x4D > +#define PMC_39F040 0x4E > #define PMC_49FL002 0x6D > #define PMC_49FL004 0x6E > > Index: flashrom-spi_pm25/flashchips.c > =================================================================== > --- flashrom-spi_pm25/flashchips.c (Revision 3090) > +++ flashrom-spi_pm25/flashchips.c (Arbeitskopie) > @@ -100,10 +100,22 @@ > probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, > {"SST49LF160C", SST_ID, SST_49LF160C, 2048, 4 * 1024 , > probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, > - {"Pm49FL002", PMC_ID, PMC_49FL002, 256, 16 * 1024, > + {"Pm49FL002", PMC_ID_NOPREFIX, PMC_49FL002, 256, 16 * 1024, > probe_jedec, erase_chip_jedec, write_49fl004}, > - {"Pm49FL004", PMC_ID, PMC_49FL004, 512, 64 * 1024, > + {"Pm49FL004", PMC_ID_NOPREFIX, PMC_49FL004, 512, 64 * 1024, > probe_jedec, erase_chip_jedec, write_49fl004}, > + {"Pm25LV512", PMC_ID, PMC_25LV512, 64, 256, > + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, > + {"Pm25LV010", PMC_ID, PMC_25LV010, 128, 256, > + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, > + {"Pm25LV020", PMC_ID, PMC_25LV020, 256, 256, > + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, > + {"Pm25LV040", PMC_ID, PMC_25LV040, 512, 256, > + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, > + {"Pm25LV080B", PMC_ID, PMC_25LV080B, 1024, 256, > + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, > + {"Pm25LV016B", PMC_ID, PMC_25LV016B, 2048, 256, > + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, > {"W29C011", WINBOND_ID, W_29C011, 128, 128, > probe_jedec, erase_chip_jedec, write_jedec}, > {"W29C040P", WINBOND_ID, W_29C040P, 512, 256, > @@ -205,6 +217,8 @@ > probe_spi, NULL, NULL}, > {"MX unknown SPI chip", MX_ID, GENERIC_DEVICE_ID, 0, 0, > probe_spi, NULL, NULL}, > + {"PMC unknown SPI chip", PMC_ID, GENERIC_DEVICE_ID, 0, 0, > + probe_spi, NULL, NULL}, > {"SST unknown SPI chip", SST_ID, GENERIC_DEVICE_ID, 0, 0, > probe_spi, NULL, NULL}, > {"ST unknown SPI chip", ST_ID, GENERIC_DEVICE_ID, 0, 0, > Index: flashrom-spi_pm25/spi.c > =================================================================== > --- flashrom-spi_pm25/spi.c (Revision 3090) > +++ flashrom-spi_pm25/spi.c (Arbeitskopie) > @@ -278,11 +278,17 @@ > int probe_spi(struct flashchip *flash) > { > unsigned char readarr[3]; > - uint8_t manuf_id; > - uint16_t model_id; > + uint32_t manuf_id; > + uint32_t model_id; > if (!generic_spi_rdid(readarr)) { > - manuf_id = readarr[0]; > - model_id = (readarr[1] << 8) | readarr[2]; > + /* Check if this is a continuation vendor ID */ > + if (readarr[0] == 0x7f) { > + manuf_id = (readarr[0] << 8) | readarr[1]; > + model_id = readarr[2]; > + } else { > + manuf_id = readarr[0]; > + model_id = (readarr[1] << 8) | readarr[2]; > + } > printf_debug("%s: id1 0x%x, id2 0x%x\n", __FUNCTION__, manuf_id, model_id); > if (manuf_id == flash->manufacture_id && > model_id == flash->model_id) { Works beautifully Acked-by: Chris Lingard From peter at stuge.se Wed Feb 6 19:19:56 2008 From: peter at stuge.se (Peter Stuge) Date: Wed, 6 Feb 2008 19:19:56 +0100 Subject: [coreboot] [patch] Build error with top of tree V2 In-Reply-To: <47A9F7E6.1060703@amd.com> References: <47A9EE7C.3040601@amd.com> <47A9F7E6.1060703@amd.com> Message-ID: <20080206181956.5800.qmail@stuge.se> On Wed, Feb 06, 2008 at 11:09:42AM -0700, Marc Jones wrote: > Cross compile flags were missing for ar to create coreboot.a. > > Signed-off-by: Marc Jones Acked-by: Peter Stuge > Index: coreboot-v2/src/config/Config.lb > =================================================================== > --- coreboot-v2.orig/src/config/Config.lb 2008-02-06 10:17:43.000000000 -0700 > +++ coreboot-v2/src/config/Config.lb 2008-02-06 10:17:22.000000000 -0700 > @@ -35,7 +35,7 @@ > makerule coreboot.a > depends "$(OBJECTS)" > action "rm -f coreboot.a" > - action "ar cr coreboot.a $(OBJECTS)" > + action "$(CROSS_COMPILE)ar cr coreboot.a $(OBJECTS)" > end > > From libv at skynet.be Wed Feb 6 19:59:48 2008 From: libv at skynet.be (Luc Verhaegen) Date: Wed, 6 Feb 2008 19:59:48 +0100 Subject: [coreboot] flashrom: Add board enable for VIA EPIA SP. In-Reply-To: <20080206180546.GB10566@greenwood> References: <20080205204718.GA32021@skynet.be> <20080206180546.GB10566@greenwood> Message-ID: <20080206185948.GB3747@skynet.be> On Wed, Feb 06, 2008 at 07:05:46PM +0100, Uwe Hermann wrote: > On Tue, Feb 05, 2008 at 09:47:18PM +0100, Luc Verhaegen wrote: > > + dev = pci_dev_find(0x1106, 0x3227); /* VT8237 ISA bridge */ > > Is this really meant to be VT8237 or should it be VT8237R? Hrm... Took the disk out already :( Chip itself is covered by a heatsink. The machine i needed to flash the bios for has a VT8237A, and this has 0x3337 for the ISA bridge. pciids.sf.net has the SP device down for a plain VT8237, confirms the VT8237A and has 0x3372 for VT8237S. I'll guess i'll just give in and install a new suse for the p4m900 and return the other disk to its original owner (the SP). > > + val &= ~0x80; > > Just some cosmetics: I personally find the > > val &= ~(1 << 7); > > notation clearer for manipulating bits. Taste :) > If nobody complains I'll commit with the changes above. Let me get back to you on the identification of the devices. Luc Verhaegen. SUSE/Novell X Driver Developer. From peter at stuge.se Wed Feb 6 19:27:53 2008 From: peter at stuge.se (Peter Stuge) Date: Wed, 6 Feb 2008 19:27:53 +0100 Subject: [coreboot] Problem with M57SLI and newly installed MX25L4005 In-Reply-To: <47A9FA83.1020109@stockwith.co.uk> References: <47A77DCB.2070405@stockwith.co.uk> <47A908B4.7010105@gmx.net> <47A91F2A.7000609@gmx.net> <47A9B39E.6090101@stockwith.co.uk> <47A9B901.3030104@gmx.net> <47A9BE90.1090905@stockwith.co.uk> <47A9CB38.1050904@gmx.net> <47A9D4DF.8060402@stockwith.co.uk> <47A9EC0C.8080507@gmx.net> <47A9FA83.1020109@stockwith.co.uk> Message-ID: <20080206182753.7871.qmail@stuge.se> On Wed, Feb 06, 2008 at 06:20:51PM +0000, Chris Lingard wrote: > Switch up > Pm25LV020 found at physical address 0xfffc0000. > Flash part is Pm25LV020 (256 KB). > > Switch down > Pm25LV040 found at physical address 0xfff80000. > Flash part is Pm25LV040 (512 KB). Difference at least, but something is wrong. The factory BIOS for the M57SLI is 512kb and would not fit in the 256KB flash part. > Though I am still pretty sure that I have a MX25L4005A, because > this is what Harald wrote on the packet Oh - but what is on the actual chips? It may seem like there is nothing at all written on top of them, but with good lighting and a magnifying glass the etching should be readable. //Peter From marc.jones at amd.com Wed Feb 6 20:16:39 2008 From: marc.jones at amd.com (Marc Jones) Date: Wed, 06 Feb 2008 12:16:39 -0700 Subject: [coreboot] [patch] v3 stop on vsa errors Message-ID: <47AA0797.2080200@amd.com> I think we should do the same patch to v2. I'll post it if this is ack'ed. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: vsa_die.patch URL: From myles at pel.cs.byu.edu Wed Feb 6 20:22:11 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Wed, 6 Feb 2008 12:22:11 -0700 Subject: [coreboot] Coreboot-v2 patch rom names In-Reply-To: <20080206183412.GA18240@localdomain> References: <2831fecf0802051320h8e96311k6bc636cf6856163d@mail.gmail.com> <20080206183412.GA18240@localdomain> Message-ID: <004001c868f5$92890a70$3222040a@chimp> > -----Original Message----- > From: Ward Vandewege [mailto:ward at gnu.org] > Sent: Wednesday, February 06, 2008 11:34 AM > To: Myles Watson > Cc: Coreboot > Subject: Re: [coreboot] Coreboot-v2 patch rom names > > On Tue, Feb 05, 2008 at 02:20:06PM -0700, Myles Watson wrote: > > This patch changes all rom names that aren't coreboot.rom in Config.lb > files. > > > > I think that since the directory specifies the architecture and the > > board, it is redundant information to name it something else, and it > > makes it more difficult to automate the build process (buildrom). > > Great. > > > In buildrom we should just use Config-options.lb files instead of > > patching or keeping our own. It just adds more to maintain, with very > > little benefit. The correct place for Config.lb files is in the > > coreboot-v2 tree. > > > > The next patch would add Config-lab.lb files for each architecture > > supported by buildrom. > > That would work - but what about other payloads? Maybe we could use a > naming > scheme like > > Config-buildrom-$(PAYLOAD).lb > > and then make buildrom look for such a file, perhaps falling back to the > generic Config.lb file if it does not exist? That could work. Right now the Config-lab.lb for each architecture is a fallback image with compression enabled. Maybe Config-lab.lb is not the right name. Any payload that doesn't use compression will need to use the Config.lb, and any payload that uses compression should use Config-lab.lb In some cases the ROM size is larger for the Config-lab.lb as well. I thought about naming them Config-ROM_SIZE-COMPRESSION.lb: Config-1M-lzma.lb or Config-512K-none.lb But it seemed uglier. The two attached patches implement the switch, the buildrom patch depends on the Coreboot patch being applied first to create a revision 3091. I tested it by not updating the revision, then manually doing "svn up", applying the patch to Coreboot, and rebuilding. There is a lot of cleaning up that could be done in the Config.lb files, but I only touched the ones that buildrom uses, so I wouldn't break anything else. Suggestions are welcome. Myles Signed-off-by: Myles Watson > > Thanks, > Ward. > > -- > Ward Vandewege > Free Software Foundation - Senior System Administrator -------------- next part -------------- A non-text attachment was scrubbed... Name: buildrom-config-cleanup.patch Type: application/octet-stream Size: 60721 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: config-cleanup.patch Type: application/octet-stream Size: 16003 bytes Desc: not available URL: From peter at stuge.se Wed Feb 6 20:24:56 2008 From: peter at stuge.se (Peter Stuge) Date: Wed, 6 Feb 2008 20:24:56 +0100 Subject: [coreboot] Help, I just want to build lar.. Message-ID: <20080206192456.30375.qmail@stuge.se> v3/util/lar $ make printf " BUILD LAR\n" BUILD LAR mkdir -p /util/lar mkdir: cannot create directory `/util': Permission denied make: *** [lardir] Error 1 v3/util/lar $ obj=. make printf " BUILD LAR\n" BUILD LAR mkdir -p ./util/lar v3/util/lar $ wtf? I just want to make lar, that should be ultra simple. v3 $ make util/lar/lar gcc -Wall -g -I/home/stuge/co/v3 -Iinclude -I/home/stuge/co/v3/include -I/home/stuge/co/v3/include/arch/x86/ -include /home/stuge/co/v3/build/config.h -include /home/stuge/co/v3/build/build.h util/lar/lar.c -o util/lar/lar In file included from include/string.h:24, from util/lar/lar.c:23: /home/stuge/co/v3/include/arch/x86/types.h:18: error: conflicting types for 'size_t' /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/stddef.h:214: error: previous declaration of 'size_t' was here In file included from util/lar/lar.c:33: util/lar/lar.h:60: error: redefinition of typedef 'u64' /home/stuge/co/v3/include/arch/x86/types.h:8: error: previous declaration of 'u64' was here util/lar/lar.h:61: error: redefinition of typedef 'u32' /home/stuge/co/v3/include/arch/x86/types.h:9: error: previous declaration of 'u32' was here util/lar/lar.h:62: error: redefinition of typedef 'u8' /home/stuge/co/v3/include/arch/x86/types.h:11: error: previous declaration of 'u8' was here util/lar/lar.c: In function 'main': util/lar/lar.c:240: warning: implicit declaration of function 'strcasecmp' util/lar/lar.c:260: warning: implicit declaration of function 'strdup' util/lar/lar.c:260: warning: incompatible implicit declaration of built-in function 'strdup' make: *** [util/lar/lar] Error 1 //Peter From ward at gnu.org Wed Feb 6 21:07:48 2008 From: ward at gnu.org (Ward Vandewege) Date: Wed, 6 Feb 2008 15:07:48 -0500 Subject: [coreboot] [LinuxBIOS] [PATCH] buildrom: add extract and busybox-config, uclibc-config targets In-Reply-To: <001601c861d6$636ea3b0$cb22040a@chimp> References: <20080110231849.GA22723@localdomain> <008d01c853e2$1c332f90$2023040a@chimp> <20080111224849.GA4101@localdomain> <00fd01c854a6$c22e7cf0$2023040a@chimp> <20080126050829.GA12921@localdomain> <001601c861d6$636ea3b0$cb22040a@chimp> Message-ID: <20080206200748.GA18536@localdomain> On Mon, Jan 28, 2008 at 10:51:19AM -0700, Myles Watson wrote: > It works great for me. The only thing I would like better is if the target > were added to the end of the customconfig file, so that you wouldn't > accidentally pick up the wrong config. (i.e., customconfig-qemu or > customconfig-s2891). I've implemented that - the naming convention for the customconfig files is now customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)--$(COREBOOT_BOARD) and in the case of uclibc and the kernel, I've added the architecture in there as well: customconfig--$(PAYLOAD)--$(UCLIBC_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) customconfig--$(PAYLOAD)--$(KERNEL_BUILD_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) Custom config files will only be used if the payload, (architecture,) vendor and board match. If a custom config file is used, buildrom will say so on stdout. The *-config commands are a bit smarter now: they will copy an existing custom config file back to the source directory so that doing a subsequent make something-config will have the effect of editing the custom config, rather than overwriting it. > I think that could be considered a matter of taste. Maybe we should add the > custom-config option for the kernel as well. I've added the kernel. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator -------------- next part -------------- This patch adds extract targets, as well as some config targets: busybox-config, uclibc-config, kernel-config and filo-config. The extract targets will just extract the component(s) under the work subdirectory. The config targets will run a configure command for the component, and then copy the resulting custom config file to the conf directory for the package using a naming convention that indicates the payload, vendor, board and (for the kernel and uclibc) architecture. That config file will then be used to build the image when 'make' is issued, overriding the default buildrom config for that package/payload - but only if there is a match for payload, vendor and board (and for uclibc and the kernel, architecture). The config targets are somewhat smart: they will copy an existing custom config file back to the source directory so that doing a make something-config when a custom config file exists will have the effect of editing the custom config, rather than overwriting it. If a custom config file is used, buildrom will say so on stdout. Signed-off-by: Ward Vandewege Index: config/payloads/lab.conf =================================================================== --- config/payloads/lab.conf (revision 104) +++ config/payloads/lab.conf (working copy) @@ -30,4 +30,6 @@ PAYLOAD-$(CONFIG_BOOTMENU) += bootmenu PAYLOAD-$(CONFIG_OLPCFLASH) += olpcflash +PAYLOAD=lab + HOSTTOOLS-y = mkelfimage unifdef Index: config/payloads/kernel.conf =================================================================== --- config/payloads/kernel.conf (revision 104) +++ config/payloads/kernel.conf (working copy) @@ -16,4 +16,6 @@ PAYLOAD_COMPRESSED=$(OUTPUT_DIR)/kernel-payload.elf.lzma PAYLOAD-y= kernel +PAYLOAD=kernel + HOSTTOOLS-y = mkelfimage Index: config/payloads/filo.conf =================================================================== --- config/payloads/filo.conf (revision 104) +++ config/payloads/filo.conf (working copy) @@ -8,3 +8,6 @@ PAYLOAD_COMPRESSED=$(OUTPUT_DIR)/filo-payload.elf.lzma PAYLOAD-y=filo + +PAYLOAD=filo + Index: Makefile =================================================================== --- Makefile (revision 104) +++ Makefile (working copy) @@ -21,7 +21,7 @@ config-targets := 1 endif -ifneq ($(filter config %config,$(MAKECMDGOALS)),) +ifneq ($(filter textconfig oldconfig defconfig menuconfig,$(MAKECMDGOALS)),) config-targets := 1 dot-config := 0 endif @@ -60,6 +60,7 @@ PKG_clean=$(patsubst %, %-clean, $(PKGLIST)) PKG_distclean=$(patsubst %, %-distclean, $(PKGLIST)) +PKG_extract=$(patsubst %, %-extract, $(PKGLIST)) # This is the top level target - for v2, the final deliverable is built # by coreboot, for v3 it is built by us, so we have ifdef magic here @@ -78,6 +79,8 @@ payload: $(PAYLOAD_TARGET) +extract: $(PKG_extract) + clean: $(PKG_clean) @ rm -rf $(INITRD_DIR) $(OUTPUT_DIR) Index: packages/unifdef/unifdef.mk =================================================================== --- packages/unifdef/unifdef.mk (revision 104) +++ packages/unifdef/unifdef.mk (working copy) @@ -17,7 +17,7 @@ @ mkdir -p $(SOURCE_DIR) @ wget -P $(SOURCE_DIR) $(UNIFDEF_URL)/$(UNIFDEF_SOURCE) -$(UNIFDEF_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(UNIFDEF_SOURCE) +$(UNIFDEF_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(UNIFDEF_SOURCE) $(UNIFDEF_STAMP_DIR) @ tar -C $(UNIFDEF_DIR) -zxf $(SOURCE_DIR)/$(UNIFDEF_SOURCE) @ rm -f $(UNIFDEF_SRC_DIR)/unifdef @ rm -f $(UNIFDEF_SRC_DIR)/unifdef.o @@ -49,3 +49,5 @@ echo "" .PHONY: unifdef + +unifdef-extract: $(UNIFDEF_STAMP_DIR)/.unpacked Index: packages/kernel/kernel.inc =================================================================== --- packages/kernel/kernel.inc (revision 104) +++ packages/kernel/kernel.inc (working copy) @@ -15,6 +15,12 @@ KERNEL_BUILD_ARCH=i386 endif +ifeq ($(findstring defconfig,$(KERNEL_CONFIG)),defconfig) +ifeq ($(shell if [ -f $(PACKAGE_DIR)/kernel/conf/customconfig--$(PAYLOAD)--$(KERNEL_BUILD_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + KERNEL_CONFIG = $(PACKAGE_DIR)/kernel/conf/customconfig--$(PAYLOAD)--$(KERNEL_BUILD_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) +endif +endif + ifeq ($(CONFIG_VERBOSE),y) KERNEL_FETCH_LOG=/dev/stdout KERNEL_BUILD_LOG=/dev/stdout @@ -25,7 +31,7 @@ KERNEL_INSTALL_LOG=$(KERNEL_LOG_DIR)/install.log endif -$(KERNEL_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(KERNEL_SOURCE) +$(KERNEL_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(KERNEL_SOURCE) | $(KERNEL_STAMP_DIR) @ mkdir -p $(KERNEL_DIR) @ echo "Unpacking kernel..." @ tar -C $(KERNEL_DIR) -jxf $(SOURCE_DIR)/$(KERNEL_SOURCE) @@ -50,8 +56,11 @@ $(KERNEL_SRC_DIR)/.config: $(KERNEL_STAMP_DIR)/.patched @ cat $(KERNEL_CONFIG) | sed -e s:^CONFIG_LOCALVERSION=.*:CONFIG_LOCALVERSION=\"$(ROM_VERSION)\": > $(KERNEL_SRC_DIR)/.config -$(KERNEL_BZIMAGE): $(KERNEL_SRC_DIR)/.config +$(KERNEL_BZIMAGE): $(KERNEL_SRC_DIR)/.config | $(KERNEL_LOG_DIR) @ echo "Building kernel..." +ifneq ($(findstring defconfig,$(KERNEL_CONFIG)),defconfig) + @ echo "Using custom kernel config $(KERNEL_CONFIG)" +endif @ $(MAKE) $(PARALLEL_MAKE) -C $(KERNEL_SRC_DIR) ARCH=$(KERNEL_BUILD_ARCH) \ KERNEL_CC="$(CC)" KERNEL_LD="$(LD)" > $(KERNEL_BUILD_LOG) 2>&1 @@ -63,7 +72,7 @@ @ install -d $(OUTPUT_DIR) @ install -m 0644 $(KERNEL_SRC_DIR)/vmlinux $@ -$(KERNEL_STAMP_DIR)/.headers: $(KERNEL_SRC_DIR)/.config $(STAGING_DIR)/host/bin/unifdef +$(KERNEL_STAMP_DIR)/.headers: $(KERNEL_SRC_DIR)/.config $(STAGING_DIR)/host/bin/unifdef | $(KERNEL_LOG_DIR) @ echo "Installing kernel headers..." @( export PATH=$(PATH):$(STAGING_DIR)/host/bin; \ $(MAKE) -C $(KERNEL_SRC_DIR) ARCH=$(KERNEL_BUILD_ARCH) \ @@ -73,7 +82,7 @@ $(KERNEL_STAMP_DIR) $(KERNEL_LOG_DIR): @ mkdir -p $@ -generic-kernel: $(KERNEL_STAMP_DIR) $(KERNEL_LOG_DIR) $(OUTPUT_DIR)/bzImage $(OUTPUT_DIR)/vmlinux $(KERNEL_STAMP_DIR)/.headers +generic-kernel: $(OUTPUT_DIR)/bzImage $(OUTPUT_DIR)/vmlinux $(KERNEL_STAMP_DIR)/.headers generic-kernel-clean: @ echo "Cleaning kernel..." @@ -83,3 +92,26 @@ generic-kernel-distclean: @ rm -rf $(KERNEL_DIR) + +kernel-extract: $(KERNEL_STAMP_DIR)/.patched + +kernel-config: $(KERNEL_STAMP_DIR)/.patched +ifeq ($(shell if [ -f $(PACKAGE_DIR)/kernel/conf/customconfig--$(PAYLOAD)--$(KERNEL_BUILD_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + @ echo + @ echo "Found an existing custom configuration file:" + @ echo " $(PACKAGE_DIR)/kernel/conf/customconfig--$(PAYLOAD)--$(KERNEL_BUILD_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)" + @ echo "I'm going to copy it back to the source directory for modification." + @ echo "Remove the above file and re-run this command if you want to create a new custom configuration from scratch for this payload/board." + @ echo + @ cp -f $(PACKAGE_DIR)/kernel/conf/customconfig--$(PAYLOAD)--$(KERNEL_BUILD_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) $(KERNEL_SRC_DIR)/.config +endif +ifeq (kernel,$(filter kernel,$(PAYLOAD-y))) + @ echo "Configure kernel..." + @ $(MAKE) -C $(KERNEL_SRC_DIR) menuconfig + @ cp -f $(KERNEL_SRC_DIR)/.config $(PACKAGE_DIR)/kernel/conf/customconfig--$(PAYLOAD)--$(KERNEL_BUILD_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) + @ echo + @ echo "Your custom kernel config file has been saved as $(PACKAGE_DIR)/kernel/conf/customconfig--$(PAYLOAD)--$(KERNEL_BUILD_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)." + @ echo +else + @ echo "Your payload does not require a kernel." +endif Index: packages/filo/filo.mk =================================================================== --- packages/filo/filo.mk (revision 104) +++ packages/filo/filo.mk (working copy) @@ -25,13 +25,17 @@ FILO_TARBALL=filo-svn-$(FILO_TAG).tar.gz +ifeq ($(shell if [ -f $(PACKAGE_DIR)/filo/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + FILO_CONFIG = customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) +endif + $(SOURCE_DIR)/$(FILO_TARBALL): @ mkdir -p $(SOURCE_DIR)/filo @ $(BIN_DIR)/fetchsvn.sh $(FILO_URL) $(SOURCE_DIR)/filo \ $(FILO_TAG) $(SOURCE_DIR)/$(FILO_TARBALL) \ > $(FILO_FETCH_LOG) 2>&1 -$(FILO_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(FILO_TARBALL) +$(FILO_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(FILO_TARBALL) $(FILO_STAMP_DIR) $(FILO_DIR) @ echo "Unpacking filo..." @ tar -C $(FILO_DIR) -zxf $(SOURCE_DIR)/$(FILO_TARBALL) @ touch $@ @@ -48,6 +52,9 @@ $(FILO_SRC_DIR)/filo.elf: $(FILO_STAMP_DIR)/.configured @ echo "Building filo..." +ifeq ($(findstring customconfig,$(FILO_CONFIG)),customconfig) + @ echo "Using custom config $(PACKAGE_DIR)/filo/conf/$(FILO_CONFIG)" +endif @ make -C $(FILO_SRC_DIR) filo.elf > $(FILO_BUILD_LOG) 2>&1 $(FILO_STAMP_DIR) $(FILO_LOG_DIR): @@ -64,3 +71,24 @@ filo-distclean: @ rm -rf $(FILO_DIR)/* +filo-extract: $(FILO_STAMP_DIR)/.patched + +filo-config: $(FILO_STAMP_DIR)/.unpacked +ifeq ($(shell if [ -f $(PACKAGE_DIR)/filo/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + @ echo + @ echo "Found an existing custom configuration file:" + @ echo " $(PACKAGE_DIR)/filo/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)" + @ echo "Please modify this file by hand." + @ echo "Remove the above file and re-run this command if you want to create a new custom configuration from scratch for this payload/board." + @ echo +else + @ echo "Configure filo..." + @ $(MAKE) -C $(FILO_SRC_DIR) config + @ cp -f $(FILO_SRC_DIR)/Config $(PACKAGE_DIR)/filo/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) + @ echo + @ echo "Your custom FILO config has been saved as " + @ echo " $(PACKAGE_DIR)/filo/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)" + @ echo "Please edit it to your liking." + @ echo +endif + Index: packages/busybox/busybox.mk =================================================================== --- packages/busybox/busybox.mk (revision 104) +++ packages/busybox/busybox.mk (working copy) @@ -17,11 +17,18 @@ BUSYBOX_CONFIG ?= defconfig +ifeq ($(findstring defconfig,$(BUSYBOX_CONFIG)),defconfig) +ifeq ($(shell if [ -f $(PACKAGE_DIR)/busybox/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + BUSYBOX_CONFIG = customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) +endif +endif + $(SOURCE_DIR)/$(BUSYBOX_SOURCE): + @ echo "Downloading busybox..." @ mkdir -p $(SOURCE_DIR) @ wget -P $(SOURCE_DIR) $(BUSYBOX_URL)/$(BUSYBOX_SOURCE) -$(BUSYBOX_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(BUSYBOX_SOURCE) +$(BUSYBOX_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(BUSYBOX_SOURCE) | $(BUSYBOX_STAMP_DIR) $(BUSYBOX_DIR) @ echo "Unpacking busybox..." @ tar -C $(BUSYBOX_DIR) -jxf $(SOURCE_DIR)/$(BUSYBOX_SOURCE) @ touch $@ @@ -32,24 +39,27 @@ @ touch $@ $(BUSYBOX_SRC_DIR)/.config: $(BUSYBOX_STAMP_DIR)/.patched - @ cp $(PACKAGE_DIR)/busybox/conf/$(BUSYBOX_CONFIG) $@ + @ cp -f $(PACKAGE_DIR)/busybox/conf/$(BUSYBOX_CONFIG) $@ -$(BUSYBOX_SRC_DIR)/busybox: $(BUSYBOX_SRC_DIR)/.config +$(BUSYBOX_SRC_DIR)/busybox: $(BUSYBOX_SRC_DIR)/.config | $(BUSYBOX_LOG_DIR) @ echo "Building busybox..." +ifneq ($(findstring defconfig,$(BUSYBOX_CONFIG)),defconfig) + @ echo "Using custom config $(PACKAGE_DIR)/busybox/conf/$(BUSYBOX_CONFIG)" +endif @ ( unset CFLAGS; unset LDFLAGS; \ export EXTRA_CFLAGS="$(CFLAGS)";\ export LDFLAGS="$(LDFLAGS_orig)";\ $(MAKE) -C $(BUSYBOX_SRC_DIR) VERBOSE=y \ LIBRARIES="$(LIBS)" all > $(BUSYBOX_BUILD_LOG) 2>&1) -$(INITRD_DIR)/bin/busybox: $(BUSYBOX_SRC_DIR)/busybox +$(INITRD_DIR)/bin/busybox: $(BUSYBOX_SRC_DIR)/busybox | $(BUSYBOX_LOG_DIR) @ $(MAKE) -C $(BUSYBOX_SRC_DIR) \ PREFIX=$(INITRD_DIR) install > $(BUSYBOX_INSTALL_LOG) 2>&1 -$(BUSYBOX_STAMP_DIR) $(BUSYBOX_LOG_DIR): +$(BUSYBOX_STAMP_DIR) $(BUSYBOX_LOG_DIR) $(BUSYBOX_DIR): @ mkdir -p $@ -busybox: $(BUSYBOX_STAMP_DIR) $(BUSYBOX_LOG_DIR) $(INITRD_DIR)/bin/busybox +busybox: $(INITRD_DIR)/bin/busybox busybox-clean: @ echo "Cleaning busybox..." @@ -62,3 +72,26 @@ @ echo "Package: busybox" @ echo "Source: $(BUSYBOX_URL)/$(BUSYBOX_SOURCE)" @ echo "" + +busybox-extract: $(BUSYBOX_STAMP_DIR)/.patched + +busybox-config: $(BUSYBOX_STAMP_DIR)/.patched +ifeq ($(shell if [ -f $(PACKAGE_DIR)/busybox/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + @ echo + @ echo "Found an existing custom configuration file:" + @ echo " $(PACKAGE_DIR)/busybox/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)" + @ echo "I'm going to copy it back to the source directory for modification." + @ echo "Remove the above file and re-run this command if you want to create a new custom configuration from scratch for this payload/board." + @ echo + @ cp -f $(PACKAGE_DIR)/busybox/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) $(BUSYBOX_SRC_DIR)/.config +endif +ifeq (busybox,$(filter busybox,$(PAYLOAD-y))) + @ echo "Configure busybox..." + @ $(MAKE) -C $(BUSYBOX_SRC_DIR) menuconfig + @ cp -f $(BUSYBOX_SRC_DIR)/.config $(PACKAGE_DIR)/busybox/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) + @ echo + @ echo "Your custom busybox config file has been saved as $(PACKAGE_DIR)/busybox/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)." + @ echo +else + @ echo "Your payload does not require busybox." +endif Index: packages/mkelfimage/mkelfimage.mk =================================================================== --- packages/mkelfimage/mkelfimage.mk (revision 104) +++ packages/mkelfimage/mkelfimage.mk (working copy) @@ -15,11 +15,14 @@ MKELFIMAGE_CONFIG_LOG=$(MKELFIMAGE_LOG_DIR)/config.log endif +$(MKELFIMAGE_STAMP_DIR) $(MKELFIMAGE_LOG_DIR): + @ mkdir -p $@ + $(SOURCE_DIR)/$(MKELFIMAGE_SOURCE): @ mkdir -p $(SOURCE_DIR) @ wget -P $(SOURCE_DIR) $(MKELFIMAGE_URL)/$(MKELFIMAGE_SOURCE) -$(MKELFIMAGE_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(MKELFIMAGE_SOURCE) +$(MKELFIMAGE_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(MKELFIMAGE_SOURCE) | $(MKELFIMAGE_STAMP_DIR) $(MKELFIMAGE_LOG_DIR) @ echo "Unpacking mkelfimage..." @ tar -C $(MKELFIMAGE_DIR) -zxf $(SOURCE_DIR)/$(MKELFIMAGE_SOURCE) @ touch $@ @@ -45,11 +48,8 @@ @ install -d $(STAGING_DIR)/sbin @ install -m 0755 $< $@ -$(MKELFIMAGE_STAMP_DIR) $(MKELFIMAGE_LOG_DIR): - @ mkdir -p $@ +mkelfimage: $(STAGING_DIR)/sbin/mkelfImage -mkelfimage: $(MKELFIMAGE_STAMP_DIR) $(MKELFIMAGE_LOG_DIR) $(STAGING_DIR)/sbin/mkelfImage - mkelfimage-clean: $(MAKE) -C $(MKELFIMAGE_SRC_DIR) clean @@ -60,3 +60,6 @@ echo "Package: mkelfimage" echo "Source: $(MKELFIMAGE_URL)/$(MKELFIMAGE_SOURCE)" echo "" + +mkelfimage-extract: $(MKELFIMAGE_STAMP_DIR)/.patched + Index: packages/coreboot-v2/coreboot.inc =================================================================== --- packages/coreboot-v2/coreboot.inc (revision 104) +++ packages/coreboot-v2/coreboot.inc (working copy) @@ -58,8 +58,8 @@ $(CBV2_PAYLOAD_TARGET): $(PAYLOAD_TARGET) @ cp $< $@ -$(CBV2_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(CBV2_TARBALL) - @ echo "Unpacking coreboot..." +$(CBV2_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(CBV2_TARBALL) $(CBV2_STAMP_DIR) $(CBV2_LOG_DIR) + @ echo "Unpacking coreboot ($(CBV2_TARBALL))..." @ tar -C $(CBV2_DIR) -zxf $(SOURCE_DIR)/$(CBV2_TARBALL) @ touch $@ @@ -98,3 +98,6 @@ fi @ rm -rf $(CBV2_DIR)/* + +coreboot-extract: $(CBV2_STAMP_DIR)/.patched + Index: packages/uclibc/uclibc.mk =================================================================== --- packages/uclibc/uclibc.mk (revision 104) +++ packages/uclibc/uclibc.mk (working copy) @@ -9,6 +9,12 @@ UCLIBC_CONFIG ?= defconfig endif +ifeq ($(findstring defconfig,$(UCLIBC_CONFIG)),defconfig) +ifeq ($(shell if [ -f $(PACKAGE_DIR)/uclibc/conf/customconfig--$(PAYLOAD)--$(UCLIBC_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + UCLIBC_CONFIG = customconfig--$(PAYLOAD)--$(UCLIBC_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) +endif +endif + UCLIBC_URL=http://www.uclibc.org/downloads UCLIBC_SOURCE=uClibc-$(UCLIBC_VER).tar.bz2 UCLIBC_DIR=$(BUILD_DIR)/uclibc @@ -25,10 +31,11 @@ endif $(SOURCE_DIR)/$(UCLIBC_SOURCE): + @ echo "Downloading uclibc..." @ mkdir -p $(SOURCE_DIR) @ wget -P $(SOURCE_DIR) $(UCLIBC_URL)/$(UCLIBC_SOURCE) -$(UCLIBC_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(UCLIBC_SOURCE) +$(UCLIBC_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(UCLIBC_SOURCE) $(UCLIBC_STAMP_DIR) $(UCLIBC_DIR) @ echo "Unpacking uclibc..." @ tar -C $(UCLIBC_DIR) -jxf $(SOURCE_DIR)/$(UCLIBC_SOURCE) @ touch $@ @@ -38,6 +45,9 @@ $(UCLIBC_SRC_DIR)/lib/libc.a: $(UCLIBC_SRC_DIR)/.config @ echo "Building uclibc..." +ifneq ($(findstring defconfig,$(UCLIBC_CONFIG)),defconfig) + @ echo "Using custom config $(PACKAGE_DIR)/uclibc/conf/$(UCLIBC_CONFIG)" +endif @ ( unset CFLAGS; unset LDFLAGS; \ $(MAKE) $(PARALLEL_MAKE) -C $(UCLIBC_SRC_DIR) TARGET_ARCH="$(UCLIBC_ARCH)" \ CC="$(CC) $(CROSS_CFLAGS)" LD="$(LD) $(CROSS_LDFLAGS)" \ @@ -61,7 +71,7 @@ @ install -m 755 -d $(STAGING_DIR)/bin @ install -m 755 $< $@ -$(UCLIBC_STAMP_DIR) $(UCLIBC_LOG_DIR): +$(UCLIBC_STAMP_DIR) $(UCLIBC_LOG_DIR) $(UCLIBC_DIR): @ mkdir -p $@ uclibc: $(UCLIBC_STAMP_DIR) $(UCLIBC_LOG_DIR) $(STAGING_DIR)/lib/libc.a @@ -77,3 +87,26 @@ @ echo "Package: uclibc" @ echo "Source: $(UCLIBC_URL)/$(UCLIBC_SOURCE)" @ echo "" + +uclibc-extract: $(UCLIBC_STAMP_DIR)/.unpacked + +uclibc-config: $(UCLIBC_STAMP_DIR)/.unpacked +ifeq ($(shell if [ -f $(PACKAGE_DIR)/uclibc/conf/customconfig--$(PAYLOAD)--$(UCLIBC_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + @ echo + @ echo "Found an existing custom configuration file:" + @ echo " $(PACKAGE_DIR)/uclibc/conf/customconfig--$(PAYLOAD)--$(UCLIBC_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)" + @ echo "I'm going to copy it back to the source directory for modification." + @ echo "Remove the above file and re-run this command if you want to create a new custom configuration from scratch for this payload/board." + @ echo + @ cp -f $(PACKAGE_DIR)/uclibc/conf/customconfig--$(PAYLOAD)--$(UCLIBC_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) $(UCLIBC_SRC_DIR)/.config +endif +ifeq (uclibc,$(filter uclibc,$(PAYLOAD-y))) + @ echo "Configure uclibc..." + @ $(MAKE) -C $(UCLIBC_SRC_DIR) menuconfig + @ cp -f $(UCLIBC_SRC_DIR)/.config $(PACKAGE_DIR)/uclibc/conf/customconfig--$(PAYLOAD)--$(UCLIBC_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) + @ echo + @ echo "Your custom uclibc config file has been saved as $(PACKAGE_DIR)/uclibc/conf/customconfig--$(PAYLOAD)--$(UCLIBC_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)." + @ echo +else + @ echo "Your payload does not require uclibc." +endif Index: packages/lzma/lzma.mk =================================================================== --- packages/lzma/lzma.mk (revision 104) +++ packages/lzma/lzma.mk (working copy) @@ -17,7 +17,7 @@ @ mkdir -p $(SOURCE_DIR) @ wget -P $(SOURCE_DIR) $(LZMA_URL)/$(LZMA_SOURCE) -$(LZMA_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(LZMA_SOURCE) +$(LZMA_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(LZMA_SOURCE) $(LZMA_STAMP_DIR) @ mkdir -p $(LZMA_SRC_DIR) @ tar -C $(LZMA_SRC_DIR) -jxf $(SOURCE_DIR)/$(LZMA_SOURCE) @ touch $@ @@ -44,3 +44,6 @@ lzma-distclean: @ rm -rf $(LZMA_DIR)/* + +lzma-extract: $(LZMA_STAMP_DIR)/.unpacked + From myles at pel.cs.byu.edu Wed Feb 6 21:08:32 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Wed, 6 Feb 2008 13:08:32 -0700 Subject: [coreboot] Help, I just want to build lar.. In-Reply-To: <20080206192456.30375.qmail@stuge.se> References: <20080206192456.30375.qmail@stuge.se> Message-ID: <005301c868fc$0dd8d2e0$3222040a@chimp> Try `make lar` in the v3 directory. Myles > -----Original Message----- > From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] > On Behalf Of Peter Stuge > Sent: Wednesday, February 06, 2008 12:25 PM > To: coreboot at coreboot.org > Subject: [coreboot] Help, I just want to build lar.. > > v3/util/lar $ make > printf " BUILD LAR\n" > BUILD LAR > mkdir -p /util/lar > mkdir: cannot create directory `/util': Permission denied > make: *** [lardir] Error 1 > v3/util/lar $ obj=. make > printf " BUILD LAR\n" > BUILD LAR > mkdir -p ./util/lar > v3/util/lar $ > > wtf? I just want to make lar, that should be ultra simple. > > > v3 $ make util/lar/lar > gcc -Wall -g -I/home/stuge/co/v3 -Iinclude -I/home/stuge/co/v3/include - > I/home/stuge/co/v3/include/arch/x86/ -include > /home/stuge/co/v3/build/config.h -include /home/stuge/co/v3/build/build.h > util/lar/lar.c -o util/lar/lar > In file included from include/string.h:24, > from util/lar/lar.c:23: > /home/stuge/co/v3/include/arch/x86/types.h:18: error: conflicting types > for 'size_t' > /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/stddef.h:214: error: previous > declaration of 'size_t' was here > In file included from util/lar/lar.c:33: > util/lar/lar.h:60: error: redefinition of typedef 'u64' > /home/stuge/co/v3/include/arch/x86/types.h:8: error: previous declaration > of 'u64' was here > util/lar/lar.h:61: error: redefinition of typedef 'u32' > /home/stuge/co/v3/include/arch/x86/types.h:9: error: previous declaration > of 'u32' was here > util/lar/lar.h:62: error: redefinition of typedef 'u8' > /home/stuge/co/v3/include/arch/x86/types.h:11: error: previous declaration > of 'u8' was here > util/lar/lar.c: In function 'main': > util/lar/lar.c:240: warning: implicit declaration of function 'strcasecmp' > util/lar/lar.c:260: warning: implicit declaration of function 'strdup' > util/lar/lar.c:260: warning: incompatible implicit declaration of built-in > function 'strdup' > make: *** [util/lar/lar] Error 1 > > > //Peter > > -- > coreboot mailing list > coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot From stepan at coresystems.de Wed Feb 6 21:09:00 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 06 Feb 2008 21:09:00 +0100 Subject: [coreboot] Help, I just want to build lar.. In-Reply-To: <20080206192456.30375.qmail@stuge.se> References: <20080206192456.30375.qmail@stuge.se> Message-ID: <47AA13DC.1050206@coresystems.de> Peter Stuge wrote: > v3/util/lar $ make > printf " BUILD LAR\n" > BUILD LAR > mkdir -p /util/lar > mkdir: cannot create directory `/util': Permission denied > make: *** [lardir] Error 1 > v3/util/lar $ obj=. make > printf " BUILD LAR\n" > BUILD LAR > mkdir -p ./util/lar > v3/util/lar $ > > wtf? I just want to make lar, that should be ultra simple. > just do "make lar" -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From libv at skynet.be Wed Feb 6 21:17:27 2008 From: libv at skynet.be (Luc Verhaegen) Date: Wed, 6 Feb 2008 21:17:27 +0100 Subject: [coreboot] flashrom: Add board enable for VIA EPIA SP. In-Reply-To: <20080206185948.GB3747@skynet.be> References: <20080205204718.GA32021@skynet.be> <20080206180546.GB10566@greenwood> <20080206185948.GB3747@skynet.be> Message-ID: <20080206201727.GC3747@skynet.be> On Wed, Feb 06, 2008 at 07:59:48PM +0100, Luc Verhaegen wrote: > On Wed, Feb 06, 2008 at 07:05:46PM +0100, Uwe Hermann wrote: > > On Tue, Feb 05, 2008 at 09:47:18PM +0100, Luc Verhaegen wrote: > > > + dev = pci_dev_find(0x1106, 0x3227); /* VT8237 ISA bridge */ > > > > Is this really meant to be VT8237 or should it be VT8237R? > > Hrm... Took the disk out already :( Chip itself is covered by a > heatsink. > > The machine i needed to flash the bios for has a VT8237A, and this has > 0x3337 for the ISA bridge. > > pciids.sf.net has the SP device down for a plain VT8237, confirms > the VT8237A and has 0x3372 for VT8237S. > > I'll guess i'll just give in and install a new suse for the p4m900 and > return the other disk to its original owner (the SP). > Nope... lspci lists nothing VT8237Rish... Just plain VT8237. Luc Verhaegen. SUSE/Novell X Driver Developer. From corey.osgood at gmail.com Wed Feb 6 21:42:44 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Wed, 6 Feb 2008 15:42:44 -0500 Subject: [coreboot] flashrom: Add board enable for VIA EPIA SP. In-Reply-To: References: <20080205204718.GA32021@skynet.be> <20080206180546.GB10566@greenwood> <20080206185948.GB3747@skynet.be> <20080206201727.GC3747@skynet.be> Message-ID: Wonder if it's possible to set gmail's default reply to reply all. Anyways, forgotten again, but I'll add some extra info to make it worthwhile. Here's lspci -xxx from the vt8237r's lpc controller, on jetway j7f2w running ubuntu (I think): 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] 00: 06 11 27 32 87 00 10 02 00 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 27 32 30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 40: 44 c0 f8 0b 00 00 00 00 0c 20 00 00 04 00 0a 08 50: 80 99 09 00 00 00 00 00 62 80 00 08 00 00 00 00 60: 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 00 70: 06 11 27 32 00 00 00 00 00 00 00 00 20 00 00 00 80: 20 84 59 00 b2 30 00 00 01 04 00 00 06 18 00 00 90: 00 40 08 88 a0 c0 38 00 00 c1 20 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 01 05 01 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 09 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 0b 00 00 00 00 00 00 00 00 00 On Feb 6, 2008 3:30 PM, Corey Osgood wrote: > On Feb 6, 2008 3:17 PM, Luc Verhaegen wrote: > > > On Wed, Feb 06, 2008 at 07:59:48PM +0100, Luc Verhaegen wrote: > > > On Wed, Feb 06, 2008 at 07:05:46PM +0100, Uwe Hermann wrote: > > > > On Tue, Feb 05, 2008 at 09:47:18PM +0100, Luc Verhaegen wrote: > > > > > + dev = pci_dev_find(0x1106, 0x3227); /* VT8237 ISA bridge */ > > > > > > > > Is this really meant to be VT8237 or should it be VT8237R? > > > > > > Hrm... Took the disk out already :( Chip itself is covered by a > > > heatsink. > > > > > > The machine i needed to flash the bios for has a VT8237A, and this has > > > 0x3337 for the ISA bridge. > > > > > > pciids.sf.net has the SP device down for a plain VT8237, confirms > > > the VT8237A and has 0x3372 for VT8237S. > > > > > > I'll guess i'll just give in and install a new suse for the p4m900 and > > > return the other disk to its original owner (the SP). > > > > > > > Nope... lspci lists nothing VT8237Rish... Just plain VT8237. > > > > Luc Verhaegen. > > SUSE/Novell X Driver Developer. > > > > > I'm looking at the datasheets and my own lspcis (I have removed the > heatsink on one board), and 0x3227 is indeed the VT8237R/R Plus (not sure > what the Plus adds, but I've got it). Via's website should also say, if you > dig through the marketing garbage. > > -Corey > -------------- next part -------------- An HTML attachment was scrubbed... URL: From myles at pel.cs.byu.edu Wed Feb 6 21:52:23 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Wed, 6 Feb 2008 13:52:23 -0700 Subject: [coreboot] [LinuxBIOS] [PATCH] buildrom: add extract andbusybox-config, uclibc-config targets In-Reply-To: <20080206200748.GA18536@localdomain> References: <20080110231849.GA22723@localdomain> <008d01c853e2$1c332f90$2023040a@chimp> <20080111224849.GA4101@localdomain> <00fd01c854a6$c22e7cf0$2023040a@chimp> <20080126050829.GA12921@localdomain> <001601c861d6$636ea3b0$cb22040a@chimp> <20080206200748.GA18536@localdomain> Message-ID: <006301c86902$2c697920$3222040a@chimp> > > I've implemented that - the naming convention for the customconfig files > is > now > > customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)--$(COREBOOT_BOARD) Nice. > > and in the case of uclibc and the kernel, I've added the architecture in > there as well: > > customconfig--$(PAYLOAD)--$(UCLIBC_ARCH)--$(COREBOOT_VENDOR)- > $(COREBOOT_BOARD) > customconfig--$(PAYLOAD)--$(KERNEL_BUILD_ARCH)--$(COREBOOT_VENDOR)- > $(COREBOOT_BOARD) > > Custom config files will only be used if the payload, (architecture,) > vendor > and board match. Great! > > If a custom config file is used, buildrom will say so on stdout. > > The *-config commands are a bit smarter now: they will copy an existing > custom config file back to the source directory so that doing a subsequent > make something-config will have the effect of editing the custom config, > rather than overwriting it. > > > I think that could be considered a matter of taste. Maybe we should add > the > > custom-config option for the kernel as well. > > I've added the kernel. > Thanks. It's missing the ARCH=$(KERNEL_BUILD_ARCH) on the configure line for kernel and TARGET_ARCH=$(UCLIBC_BUILD_ARCH) for uclibc. On my x86_64 box it makes a 64-bit configuration even for 32-bit targets. I'd like it if the verbose messages about using the custom config were printed after the configuration was done. I never saw the messages because make menuconfig is so verbose. At first I was worried about the dependencies that you added like: +$(FILO_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(FILO_TARBALL) $(FILO_STAMP_DIR) $(FILO_DIR) I thought it would have the same problem we had before with the stamp directory being "modified" when the stamps were, and forcing a complete rebuild, but it didn't seem to happen. I guess I don't understand that well enough. Besides that it looks very good. Acked-by: Myles Watson Myles > Thanks, > Ward. > > -- > Ward Vandewege > Free Software Foundation - Senior System Administrator From libv at skynet.be Wed Feb 6 21:54:55 2008 From: libv at skynet.be (Luc Verhaegen) Date: Wed, 6 Feb 2008 21:54:55 +0100 Subject: [coreboot] flashrom: Add board enable for VIA EPIA SP. In-Reply-To: References: <20080205204718.GA32021@skynet.be> <20080206180546.GB10566@greenwood> <20080206185948.GB3747@skynet.be> <20080206201727.GC3747@skynet.be> Message-ID: <20080206205455.GD3747@skynet.be> On Wed, Feb 06, 2008 at 03:42:44PM -0500, Corey Osgood wrote: > Wonder if it's possible to set gmail's default reply to reply all. Anyways, > forgotten again, but I'll add some extra info to make it worthwhile. Here's > lspci -xxx from the vt8237r's lpc controller, on jetway j7f2w running ubuntu > (I think): > > 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge > [KT600/K8T800/K8T890 South] Well, i'm sure nobody will die from one message and a few comments not having an R in there :) pciids lack the R, so this sounded good enough. VIA Marketing states +R, but i can tell you a nice story about the marketing names of unichromes, their retroactive evolution, and why i am now labelling unichromes/chromes as VT. Please change to +R, it seems like the best guess. I am now wondering though what the actual, physical and tangible difference is between a VT8237 and a VT8237R. Luc Verhaegen. SUSE/Novell X Driver Developer. From jordan.crouse at amd.com Wed Feb 6 22:07:53 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Wed, 6 Feb 2008 14:07:53 -0700 Subject: [coreboot] goal for march summit In-Reply-To: <13426df10802060406p3e4e955cyeb7f3209fd2f967@mail.gmail.com> References: <13426df10802012049t54d8f799p7b0c7b99f315583@mail.gmail.com> <20080204205410.GC9492@cosmic.amd.com> <13426df10802060406p3e4e955cyeb7f3209fd2f967@mail.gmail.com> Message-ID: <20080206210753.GA19217@cosmic.amd.com> On 06/02/08 04:06 -0800, ron minnich wrote: > On Feb 4, 2008 12:54 PM, Jordan Crouse wrote: > > > How about the Serengeti-Cheetah on SimNow? Thats a free platform that > > everybody can use (and the new public release fixes some of the bugs that > > we have discovered). > > is the v3 support for this in buildrom? That could be a first step for > this target. We can easily make it happen. Where by we, I mean one of Myles, or Ward or myself, though if you wait for me, I won't be back in the office before the 19th. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From rminnich at gmail.com Wed Feb 6 22:28:03 2008 From: rminnich at gmail.com (ron minnich) Date: Wed, 6 Feb 2008 13:28:03 -0800 Subject: [coreboot] goal for march summit In-Reply-To: <20080206210753.GA19217@cosmic.amd.com> References: <13426df10802012049t54d8f799p7b0c7b99f315583@mail.gmail.com> <20080204205410.GC9492@cosmic.amd.com> <13426df10802060406p3e4e955cyeb7f3209fd2f967@mail.gmail.com> <20080206210753.GA19217@cosmic.amd.com> Message-ID: <13426df10802061328p2b007ea8s530aa6bd8699d2c9@mail.gmail.com> OK. let's do it. Goal for linuxbi-- er, coreboot summit at the end of march is to have v3 booting on simnow. I will, meanwhile, try to find a friendly vendor who can get low cost boards to the coreboot community. I hope one of the buildrom triumvirate can set up buildrom w/simnow sometime this or next week :-) I tend to lean against via due to the need for chipset NDA. I tend to lean toward AMD chipsets for the first board. Any suggestions there? Thanks, Jordan, for the great idea. Thanks, AMD, for simnow and your continued support for this project. AMD is a great company to work with. thanks ron From ward at gnu.org Wed Feb 6 22:34:59 2008 From: ward at gnu.org (Ward Vandewege) Date: Wed, 6 Feb 2008 16:34:59 -0500 Subject: [coreboot] [LinuxBIOS] [PATCH] buildrom: add extract andbusybox-config, uclibc-config targets In-Reply-To: <006301c86902$2c697920$3222040a@chimp> References: <20080110231849.GA22723@localdomain> <008d01c853e2$1c332f90$2023040a@chimp> <20080111224849.GA4101@localdomain> <00fd01c854a6$c22e7cf0$2023040a@chimp> <20080126050829.GA12921@localdomain> <001601c861d6$636ea3b0$cb22040a@chimp> <20080206200748.GA18536@localdomain> <006301c86902$2c697920$3222040a@chimp> Message-ID: <20080206213459.GA19472@localdomain> On Wed, Feb 06, 2008 at 01:52:23PM -0700, Myles Watson wrote: > It's missing the ARCH=$(KERNEL_BUILD_ARCH) on the configure line for kernel > and TARGET_ARCH=$(UCLIBC_BUILD_ARCH) for uclibc. On my x86_64 box it makes > a 64-bit configuration even for 32-bit targets. Good catch - that should now be fixed, see attached. > I'd like it if the verbose messages about using the custom config were > printed after the configuration was done. I never saw the messages because > make menuconfig is so verbose. Fixed. > At first I was worried about the dependencies that you added like: > > +$(FILO_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(FILO_TARBALL) > $(FILO_STAMP_DIR) $(FILO_DIR) > > I thought it would have the same problem we had before with the stamp > directory being "modified" when the stamps were, and forcing a complete > rebuild, but it didn't seem to happen. I guess I don't understand that well > enough. I've corrected those instances by making them into order-only prerequisites just in case. I'm not entirely sure why we were not seeing the problem for those packages, but better safe than sorry. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator -------------- next part -------------- This patch adds extract targets, as well as some config targets: busybox-config, uclibc-config, kernel-config and filo-config. The extract targets will just extract the component(s) under the work subdirectory. The config targets will run a configure command for the component, and then copy the resulting custom config file to the conf directory for the package using a naming convention that indicates the payload, vendor, board and (for the kernel and uclibc) architecture. That config file will then be used to build the image when 'make' is issued, overriding the default buildrom config for that package/payload - but only if there is a match for payload, vendor and board (and for uclibc and the kernel, architecture). The config targets are somewhat smart: they will copy an existing custom config file back to the source directory so that doing a make something-config when a custom config file exists will have the effect of editing the custom config, rather than overwriting it. If a custom config file is used, buildrom will say so on stdout. Signed-off-by: Ward Vandewege Index: config/payloads/lab.conf =================================================================== --- config/payloads/lab.conf (revision 104) +++ config/payloads/lab.conf (working copy) @@ -30,4 +30,6 @@ PAYLOAD-$(CONFIG_BOOTMENU) += bootmenu PAYLOAD-$(CONFIG_OLPCFLASH) += olpcflash +PAYLOAD=lab + HOSTTOOLS-y = mkelfimage unifdef Index: config/payloads/kernel.conf =================================================================== --- config/payloads/kernel.conf (revision 104) +++ config/payloads/kernel.conf (working copy) @@ -16,4 +16,6 @@ PAYLOAD_COMPRESSED=$(OUTPUT_DIR)/kernel-payload.elf.lzma PAYLOAD-y= kernel +PAYLOAD=kernel + HOSTTOOLS-y = mkelfimage Index: config/payloads/filo.conf =================================================================== --- config/payloads/filo.conf (revision 104) +++ config/payloads/filo.conf (working copy) @@ -8,3 +8,6 @@ PAYLOAD_COMPRESSED=$(OUTPUT_DIR)/filo-payload.elf.lzma PAYLOAD-y=filo + +PAYLOAD=filo + Index: Makefile =================================================================== --- Makefile (revision 104) +++ Makefile (working copy) @@ -21,7 +21,7 @@ config-targets := 1 endif -ifneq ($(filter config %config,$(MAKECMDGOALS)),) +ifneq ($(filter textconfig oldconfig defconfig menuconfig,$(MAKECMDGOALS)),) config-targets := 1 dot-config := 0 endif @@ -60,6 +60,7 @@ PKG_clean=$(patsubst %, %-clean, $(PKGLIST)) PKG_distclean=$(patsubst %, %-distclean, $(PKGLIST)) +PKG_extract=$(patsubst %, %-extract, $(PKGLIST)) # This is the top level target - for v2, the final deliverable is built # by coreboot, for v3 it is built by us, so we have ifdef magic here @@ -78,6 +79,8 @@ payload: $(PAYLOAD_TARGET) +extract: $(PKG_extract) + clean: $(PKG_clean) @ rm -rf $(INITRD_DIR) $(OUTPUT_DIR) Index: packages/unifdef/unifdef.mk =================================================================== --- packages/unifdef/unifdef.mk (revision 104) +++ packages/unifdef/unifdef.mk (working copy) @@ -17,7 +17,7 @@ @ mkdir -p $(SOURCE_DIR) @ wget -P $(SOURCE_DIR) $(UNIFDEF_URL)/$(UNIFDEF_SOURCE) -$(UNIFDEF_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(UNIFDEF_SOURCE) +$(UNIFDEF_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(UNIFDEF_SOURCE) | $(UNIFDEF_STAMP_DIR) @ tar -C $(UNIFDEF_DIR) -zxf $(SOURCE_DIR)/$(UNIFDEF_SOURCE) @ rm -f $(UNIFDEF_SRC_DIR)/unifdef @ rm -f $(UNIFDEF_SRC_DIR)/unifdef.o @@ -49,3 +49,5 @@ echo "" .PHONY: unifdef + +unifdef-extract: $(UNIFDEF_STAMP_DIR)/.unpacked Index: packages/kernel/kernel.inc =================================================================== --- packages/kernel/kernel.inc (revision 104) +++ packages/kernel/kernel.inc (working copy) @@ -15,6 +15,12 @@ KERNEL_BUILD_ARCH=i386 endif +ifeq ($(findstring defconfig,$(KERNEL_CONFIG)),defconfig) +ifeq ($(shell if [ -f $(PACKAGE_DIR)/kernel/conf/customconfig--$(PAYLOAD)--$(KERNEL_BUILD_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + KERNEL_CONFIG = $(PACKAGE_DIR)/kernel/conf/customconfig--$(PAYLOAD)--$(KERNEL_BUILD_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) +endif +endif + ifeq ($(CONFIG_VERBOSE),y) KERNEL_FETCH_LOG=/dev/stdout KERNEL_BUILD_LOG=/dev/stdout @@ -25,7 +31,7 @@ KERNEL_INSTALL_LOG=$(KERNEL_LOG_DIR)/install.log endif -$(KERNEL_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(KERNEL_SOURCE) +$(KERNEL_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(KERNEL_SOURCE) | $(KERNEL_STAMP_DIR) @ mkdir -p $(KERNEL_DIR) @ echo "Unpacking kernel..." @ tar -C $(KERNEL_DIR) -jxf $(SOURCE_DIR)/$(KERNEL_SOURCE) @@ -50,8 +56,11 @@ $(KERNEL_SRC_DIR)/.config: $(KERNEL_STAMP_DIR)/.patched @ cat $(KERNEL_CONFIG) | sed -e s:^CONFIG_LOCALVERSION=.*:CONFIG_LOCALVERSION=\"$(ROM_VERSION)\": > $(KERNEL_SRC_DIR)/.config -$(KERNEL_BZIMAGE): $(KERNEL_SRC_DIR)/.config +$(KERNEL_BZIMAGE): $(KERNEL_SRC_DIR)/.config | $(KERNEL_LOG_DIR) @ echo "Building kernel..." +ifneq ($(findstring defconfig,$(KERNEL_CONFIG)),defconfig) + @ echo "Using custom kernel config $(KERNEL_CONFIG)" +endif @ $(MAKE) $(PARALLEL_MAKE) -C $(KERNEL_SRC_DIR) ARCH=$(KERNEL_BUILD_ARCH) \ KERNEL_CC="$(CC)" KERNEL_LD="$(LD)" > $(KERNEL_BUILD_LOG) 2>&1 @@ -63,7 +72,7 @@ @ install -d $(OUTPUT_DIR) @ install -m 0644 $(KERNEL_SRC_DIR)/vmlinux $@ -$(KERNEL_STAMP_DIR)/.headers: $(KERNEL_SRC_DIR)/.config $(STAGING_DIR)/host/bin/unifdef +$(KERNEL_STAMP_DIR)/.headers: $(KERNEL_SRC_DIR)/.config $(STAGING_DIR)/host/bin/unifdef | $(KERNEL_LOG_DIR) @ echo "Installing kernel headers..." @( export PATH=$(PATH):$(STAGING_DIR)/host/bin; \ $(MAKE) -C $(KERNEL_SRC_DIR) ARCH=$(KERNEL_BUILD_ARCH) \ @@ -73,7 +82,7 @@ $(KERNEL_STAMP_DIR) $(KERNEL_LOG_DIR): @ mkdir -p $@ -generic-kernel: $(KERNEL_STAMP_DIR) $(KERNEL_LOG_DIR) $(OUTPUT_DIR)/bzImage $(OUTPUT_DIR)/vmlinux $(KERNEL_STAMP_DIR)/.headers +generic-kernel: $(OUTPUT_DIR)/bzImage $(OUTPUT_DIR)/vmlinux $(KERNEL_STAMP_DIR)/.headers generic-kernel-clean: @ echo "Cleaning kernel..." @@ -83,3 +92,27 @@ generic-kernel-distclean: @ rm -rf $(KERNEL_DIR) + +kernel-extract: $(KERNEL_STAMP_DIR)/.patched + +kernel-config: $(KERNEL_STAMP_DIR)/.patched +ifeq ($(shell if [ -f $(PACKAGE_DIR)/kernel/conf/customconfig--$(PAYLOAD)--$(KERNEL_BUILD_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + @ cp -f $(PACKAGE_DIR)/kernel/conf/customconfig--$(PAYLOAD)--$(KERNEL_BUILD_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) $(KERNEL_SRC_DIR)/.config +endif +ifeq (kernel,$(filter kernel,$(PAYLOAD-y))) + @ echo "Configure kernel..." + @ $(MAKE) -C $(KERNEL_SRC_DIR) ARCH=$(KERNEL_BUILD_ARCH) menuconfig + @ echo +ifeq ($(shell if [ -f $(PACKAGE_DIR)/kernel/conf/customconfig--$(PAYLOAD)--$(KERNEL_BUILD_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + @ echo "Found an existing custom configuration file:" + @ echo " $(PACKAGE_DIR)/kernel/conf/customconfig--$(PAYLOAD)--$(KERNEL_BUILD_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)" + @ echo "I've copied it back to the source directory for modification." + @ echo "Remove the above file and re-run this command if you want to create a new custom configuration from scratch for this payload/board." + @ echo +endif + @ cp -f $(KERNEL_SRC_DIR)/.config $(PACKAGE_DIR)/kernel/conf/customconfig--$(PAYLOAD)--$(KERNEL_BUILD_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) + @ echo "Your custom kernel config file has been saved as $(PACKAGE_DIR)/kernel/conf/customconfig--$(PAYLOAD)--$(KERNEL_BUILD_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)." + @ echo +else + @ echo "Your payload does not require a kernel." +endif Index: packages/filo/filo.mk =================================================================== --- packages/filo/filo.mk (revision 104) +++ packages/filo/filo.mk (working copy) @@ -25,13 +25,17 @@ FILO_TARBALL=filo-svn-$(FILO_TAG).tar.gz +ifeq ($(shell if [ -f $(PACKAGE_DIR)/filo/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + FILO_CONFIG = customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) +endif + $(SOURCE_DIR)/$(FILO_TARBALL): @ mkdir -p $(SOURCE_DIR)/filo @ $(BIN_DIR)/fetchsvn.sh $(FILO_URL) $(SOURCE_DIR)/filo \ $(FILO_TAG) $(SOURCE_DIR)/$(FILO_TARBALL) \ > $(FILO_FETCH_LOG) 2>&1 -$(FILO_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(FILO_TARBALL) +$(FILO_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(FILO_TARBALL) | $(FILO_STAMP_DIR) $(FILO_DIR) @ echo "Unpacking filo..." @ tar -C $(FILO_DIR) -zxf $(SOURCE_DIR)/$(FILO_TARBALL) @ touch $@ @@ -48,6 +52,9 @@ $(FILO_SRC_DIR)/filo.elf: $(FILO_STAMP_DIR)/.configured @ echo "Building filo..." +ifeq ($(findstring customconfig,$(FILO_CONFIG)),customconfig) + @ echo "Using custom config $(PACKAGE_DIR)/filo/conf/$(FILO_CONFIG)" +endif @ make -C $(FILO_SRC_DIR) filo.elf > $(FILO_BUILD_LOG) 2>&1 $(FILO_STAMP_DIR) $(FILO_LOG_DIR): @@ -64,3 +71,24 @@ filo-distclean: @ rm -rf $(FILO_DIR)/* +filo-extract: $(FILO_STAMP_DIR)/.patched + +filo-config: $(FILO_STAMP_DIR)/.unpacked +ifeq ($(shell if [ -f $(PACKAGE_DIR)/filo/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + @ echo + @ echo "Found an existing custom configuration file:" + @ echo " $(PACKAGE_DIR)/filo/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)" + @ echo "Please modify this file by hand." + @ echo "Remove the above file and re-run this command if you want to create a new custom configuration from scratch for this payload/board." + @ echo +else + @ echo "Configure filo..." + @ $(MAKE) -C $(FILO_SRC_DIR) config + @ cp -f $(FILO_SRC_DIR)/Config $(PACKAGE_DIR)/filo/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) + @ echo + @ echo "Your custom FILO config has been saved as " + @ echo " $(PACKAGE_DIR)/filo/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)" + @ echo "Please edit it to your liking." + @ echo +endif + Index: packages/busybox/busybox.mk =================================================================== --- packages/busybox/busybox.mk (revision 104) +++ packages/busybox/busybox.mk (working copy) @@ -17,11 +17,18 @@ BUSYBOX_CONFIG ?= defconfig +ifeq ($(findstring defconfig,$(BUSYBOX_CONFIG)),defconfig) +ifeq ($(shell if [ -f $(PACKAGE_DIR)/busybox/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + BUSYBOX_CONFIG = customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) +endif +endif + $(SOURCE_DIR)/$(BUSYBOX_SOURCE): + @ echo "Downloading busybox..." @ mkdir -p $(SOURCE_DIR) @ wget -P $(SOURCE_DIR) $(BUSYBOX_URL)/$(BUSYBOX_SOURCE) -$(BUSYBOX_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(BUSYBOX_SOURCE) +$(BUSYBOX_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(BUSYBOX_SOURCE) | $(BUSYBOX_STAMP_DIR) $(BUSYBOX_DIR) @ echo "Unpacking busybox..." @ tar -C $(BUSYBOX_DIR) -jxf $(SOURCE_DIR)/$(BUSYBOX_SOURCE) @ touch $@ @@ -32,24 +39,27 @@ @ touch $@ $(BUSYBOX_SRC_DIR)/.config: $(BUSYBOX_STAMP_DIR)/.patched - @ cp $(PACKAGE_DIR)/busybox/conf/$(BUSYBOX_CONFIG) $@ + @ cp -f $(PACKAGE_DIR)/busybox/conf/$(BUSYBOX_CONFIG) $@ -$(BUSYBOX_SRC_DIR)/busybox: $(BUSYBOX_SRC_DIR)/.config +$(BUSYBOX_SRC_DIR)/busybox: $(BUSYBOX_SRC_DIR)/.config | $(BUSYBOX_LOG_DIR) @ echo "Building busybox..." +ifneq ($(findstring defconfig,$(BUSYBOX_CONFIG)),defconfig) + @ echo "Using custom config $(PACKAGE_DIR)/busybox/conf/$(BUSYBOX_CONFIG)" +endif @ ( unset CFLAGS; unset LDFLAGS; \ export EXTRA_CFLAGS="$(CFLAGS)";\ export LDFLAGS="$(LDFLAGS_orig)";\ $(MAKE) -C $(BUSYBOX_SRC_DIR) VERBOSE=y \ LIBRARIES="$(LIBS)" all > $(BUSYBOX_BUILD_LOG) 2>&1) -$(INITRD_DIR)/bin/busybox: $(BUSYBOX_SRC_DIR)/busybox +$(INITRD_DIR)/bin/busybox: $(BUSYBOX_SRC_DIR)/busybox | $(BUSYBOX_LOG_DIR) @ $(MAKE) -C $(BUSYBOX_SRC_DIR) \ PREFIX=$(INITRD_DIR) install > $(BUSYBOX_INSTALL_LOG) 2>&1 -$(BUSYBOX_STAMP_DIR) $(BUSYBOX_LOG_DIR): +$(BUSYBOX_STAMP_DIR) $(BUSYBOX_LOG_DIR) $(BUSYBOX_DIR): @ mkdir -p $@ -busybox: $(BUSYBOX_STAMP_DIR) $(BUSYBOX_LOG_DIR) $(INITRD_DIR)/bin/busybox +busybox: $(INITRD_DIR)/bin/busybox busybox-clean: @ echo "Cleaning busybox..." @@ -62,3 +72,27 @@ @ echo "Package: busybox" @ echo "Source: $(BUSYBOX_URL)/$(BUSYBOX_SOURCE)" @ echo "" + +busybox-extract: $(BUSYBOX_STAMP_DIR)/.patched + +busybox-config: $(BUSYBOX_STAMP_DIR)/.patched +ifeq ($(shell if [ -f $(PACKAGE_DIR)/busybox/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + @ cp -f $(PACKAGE_DIR)/busybox/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) $(BUSYBOX_SRC_DIR)/.config +endif +ifeq (busybox,$(filter busybox,$(PAYLOAD-y))) + @ echo "Configure busybox..." + @ $(MAKE) -C $(BUSYBOX_SRC_DIR) menuconfig + @ echo +ifeq ($(shell if [ -f $(PACKAGE_DIR)/busybox/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + @ echo "Found an existing custom configuration file:" + @ echo " $(PACKAGE_DIR)/busybox/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)" + @ echo "I've copied it back to the source directory for modification." + @ echo "Remove the above file and re-run this command if you want to create a new custom configuration from scratch for this payload/board." + @ echo +endif + @ cp -f $(BUSYBOX_SRC_DIR)/.config $(PACKAGE_DIR)/busybox/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) + @ echo "Your custom busybox config file has been saved as $(PACKAGE_DIR)/busybox/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)." + @ echo +else + @ echo "Your payload does not require busybox." +endif Index: packages/mkelfimage/mkelfimage.mk =================================================================== --- packages/mkelfimage/mkelfimage.mk (revision 104) +++ packages/mkelfimage/mkelfimage.mk (working copy) @@ -15,11 +15,14 @@ MKELFIMAGE_CONFIG_LOG=$(MKELFIMAGE_LOG_DIR)/config.log endif +$(MKELFIMAGE_STAMP_DIR) $(MKELFIMAGE_LOG_DIR): + @ mkdir -p $@ + $(SOURCE_DIR)/$(MKELFIMAGE_SOURCE): @ mkdir -p $(SOURCE_DIR) @ wget -P $(SOURCE_DIR) $(MKELFIMAGE_URL)/$(MKELFIMAGE_SOURCE) -$(MKELFIMAGE_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(MKELFIMAGE_SOURCE) +$(MKELFIMAGE_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(MKELFIMAGE_SOURCE) | $(MKELFIMAGE_STAMP_DIR) $(MKELFIMAGE_LOG_DIR) @ echo "Unpacking mkelfimage..." @ tar -C $(MKELFIMAGE_DIR) -zxf $(SOURCE_DIR)/$(MKELFIMAGE_SOURCE) @ touch $@ @@ -45,11 +48,8 @@ @ install -d $(STAGING_DIR)/sbin @ install -m 0755 $< $@ -$(MKELFIMAGE_STAMP_DIR) $(MKELFIMAGE_LOG_DIR): - @ mkdir -p $@ +mkelfimage: $(STAGING_DIR)/sbin/mkelfImage -mkelfimage: $(MKELFIMAGE_STAMP_DIR) $(MKELFIMAGE_LOG_DIR) $(STAGING_DIR)/sbin/mkelfImage - mkelfimage-clean: $(MAKE) -C $(MKELFIMAGE_SRC_DIR) clean @@ -60,3 +60,6 @@ echo "Package: mkelfimage" echo "Source: $(MKELFIMAGE_URL)/$(MKELFIMAGE_SOURCE)" echo "" + +mkelfimage-extract: $(MKELFIMAGE_STAMP_DIR)/.patched + Index: packages/coreboot-v2/coreboot.inc =================================================================== --- packages/coreboot-v2/coreboot.inc (revision 104) +++ packages/coreboot-v2/coreboot.inc (working copy) @@ -58,8 +58,8 @@ $(CBV2_PAYLOAD_TARGET): $(PAYLOAD_TARGET) @ cp $< $@ -$(CBV2_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(CBV2_TARBALL) - @ echo "Unpacking coreboot..." +$(CBV2_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(CBV2_TARBALL) | $(CBV2_STAMP_DIR) $(CBV2_LOG_DIR) + @ echo "Unpacking coreboot ($(CBV2_TARBALL))..." @ tar -C $(CBV2_DIR) -zxf $(SOURCE_DIR)/$(CBV2_TARBALL) @ touch $@ @@ -98,3 +98,6 @@ fi @ rm -rf $(CBV2_DIR)/* + +coreboot-extract: $(CBV2_STAMP_DIR)/.patched + Index: packages/uclibc/uclibc.mk =================================================================== --- packages/uclibc/uclibc.mk (revision 104) +++ packages/uclibc/uclibc.mk (working copy) @@ -9,6 +9,12 @@ UCLIBC_CONFIG ?= defconfig endif +ifeq ($(findstring defconfig,$(UCLIBC_CONFIG)),defconfig) +ifeq ($(shell if [ -f $(PACKAGE_DIR)/uclibc/conf/customconfig--$(PAYLOAD)--$(UCLIBC_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + UCLIBC_CONFIG = customconfig--$(PAYLOAD)--$(UCLIBC_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) +endif +endif + UCLIBC_URL=http://www.uclibc.org/downloads UCLIBC_SOURCE=uClibc-$(UCLIBC_VER).tar.bz2 UCLIBC_DIR=$(BUILD_DIR)/uclibc @@ -25,10 +31,11 @@ endif $(SOURCE_DIR)/$(UCLIBC_SOURCE): + @ echo "Downloading uclibc..." @ mkdir -p $(SOURCE_DIR) @ wget -P $(SOURCE_DIR) $(UCLIBC_URL)/$(UCLIBC_SOURCE) -$(UCLIBC_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(UCLIBC_SOURCE) +$(UCLIBC_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(UCLIBC_SOURCE) | $(UCLIBC_STAMP_DIR) $(UCLIBC_DIR) @ echo "Unpacking uclibc..." @ tar -C $(UCLIBC_DIR) -jxf $(SOURCE_DIR)/$(UCLIBC_SOURCE) @ touch $@ @@ -38,6 +45,9 @@ $(UCLIBC_SRC_DIR)/lib/libc.a: $(UCLIBC_SRC_DIR)/.config @ echo "Building uclibc..." +ifneq ($(findstring defconfig,$(UCLIBC_CONFIG)),defconfig) + @ echo "Using custom config $(PACKAGE_DIR)/uclibc/conf/$(UCLIBC_CONFIG)" +endif @ ( unset CFLAGS; unset LDFLAGS; \ $(MAKE) $(PARALLEL_MAKE) -C $(UCLIBC_SRC_DIR) TARGET_ARCH="$(UCLIBC_ARCH)" \ CC="$(CC) $(CROSS_CFLAGS)" LD="$(LD) $(CROSS_LDFLAGS)" \ @@ -61,7 +71,7 @@ @ install -m 755 -d $(STAGING_DIR)/bin @ install -m 755 $< $@ -$(UCLIBC_STAMP_DIR) $(UCLIBC_LOG_DIR): +$(UCLIBC_STAMP_DIR) $(UCLIBC_LOG_DIR) $(UCLIBC_DIR): @ mkdir -p $@ uclibc: $(UCLIBC_STAMP_DIR) $(UCLIBC_LOG_DIR) $(STAGING_DIR)/lib/libc.a @@ -77,3 +87,27 @@ @ echo "Package: uclibc" @ echo "Source: $(UCLIBC_URL)/$(UCLIBC_SOURCE)" @ echo "" + +uclibc-extract: $(UCLIBC_STAMP_DIR)/.unpacked + +uclibc-config: $(UCLIBC_STAMP_DIR)/.unpacked +ifeq ($(shell if [ -f $(PACKAGE_DIR)/uclibc/conf/customconfig--$(PAYLOAD)--$(UCLIBC_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + @ cp -f $(PACKAGE_DIR)/uclibc/conf/customconfig--$(PAYLOAD)--$(UCLIBC_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) $(UCLIBC_SRC_DIR)/.config +endif +ifeq (uclibc,$(filter uclibc,$(PAYLOAD-y))) + @ echo "Configure uclibc..." + @ $(MAKE) -C $(UCLIBC_SRC_DIR) TARGET_ARCH="$(UCLIBC_ARCH)" menuconfig + @ echo +ifeq ($(shell if [ -f $(PACKAGE_DIR)/uclibc/conf/customconfig--$(PAYLOAD)--$(UCLIBC_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + @ echo "Found an existing custom configuration file:" + @ echo " $(PACKAGE_DIR)/uclibc/conf/customconfig--$(PAYLOAD)--$(UCLIBC_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)" + @ echo "I've copied it back to the source directory for modification." + @ echo "Remove the above file and re-run this command if you want to create a new custom configuration from scratch for this payload/board." + @ echo +endif + @ cp -f $(UCLIBC_SRC_DIR)/.config $(PACKAGE_DIR)/uclibc/conf/customconfig--$(PAYLOAD)--$(UCLIBC_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) + @ echo "Your custom uclibc config file has been saved as $(PACKAGE_DIR)/uclibc/conf/customconfig--$(PAYLOAD)--$(UCLIBC_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)." + @ echo +else + @ echo "Your payload does not require uclibc." +endif Index: packages/lzma/lzma.mk =================================================================== --- packages/lzma/lzma.mk (revision 104) +++ packages/lzma/lzma.mk (working copy) @@ -17,7 +17,7 @@ @ mkdir -p $(SOURCE_DIR) @ wget -P $(SOURCE_DIR) $(LZMA_URL)/$(LZMA_SOURCE) -$(LZMA_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(LZMA_SOURCE) +$(LZMA_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(LZMA_SOURCE) | $(LZMA_STAMP_DIR) @ mkdir -p $(LZMA_SRC_DIR) @ tar -C $(LZMA_SRC_DIR) -jxf $(SOURCE_DIR)/$(LZMA_SOURCE) @ touch $@ @@ -44,3 +44,6 @@ lzma-distclean: @ rm -rf $(LZMA_DIR)/* + +lzma-extract: $(LZMA_STAMP_DIR)/.unpacked + From svn at coreboot.org Wed Feb 6 23:07:59 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Wed, 6 Feb 2008 23:07:59 +0100 Subject: [coreboot] r3091 - trunk/util/flashrom Message-ID: Author: hailfinger Date: 2008-02-06 23:07:58 +0100 (Wed, 06 Feb 2008) New Revision: 3091 Modified: trunk/util/flashrom/flash.h trunk/util/flashrom/flashchips.c trunk/util/flashrom/spi.c Log: Handle JEDEC JEP106W continuation codes in SPI RDID. Some vendors like Programmable Micro Corp (PMC) need this. Both the serial and parallel flash JEDEC detection routines would benefit from a parity/sanity check of the vendor ID. Will do this later. Add support for the PMC Pm25LV family of SPI flash chips. Signed-off-by: Carl-Daniel Hailfinger Acked-by: Chris Lingard Modified: trunk/util/flashrom/flash.h =================================================================== --- trunk/util/flashrom/flash.h 2008-02-05 21:53:15 UTC (rev 3090) +++ trunk/util/flashrom/flash.h 2008-02-06 22:07:58 UTC (rev 3091) @@ -158,7 +158,20 @@ /* Programmable Micro Corp is listed in JEP106W in bank 2, so it should have * a 0x7F continuation code prefix. */ -#define PMC_ID 0x9D /* PMC */ +#define PMC_ID 0x7F9D /* PMC */ +#define PMC_ID_NOPREFIX 0x9D /* PMC, missing 0x7F prefix */ +#define PMC_25LV512 0x7B +#define PMC_25LV010 0x7C +#define PMC_25LV020 0x7D +#define PMC_25LV040 0x7E +#define PMC_25LV080B 0x13 +#define PMC_25LV016B 0x14 +#define PMC_39LV512 0x1B +#define PMC_39F010 0x1C /* also Pm39LV010 */ +#define PMC_39LV020 0x3D +#define PMC_39LV040 0x3E +#define PMC_39F020 0x4D +#define PMC_39F040 0x4E #define PMC_49FL002 0x6D #define PMC_49FL004 0x6E Modified: trunk/util/flashrom/flashchips.c =================================================================== --- trunk/util/flashrom/flashchips.c 2008-02-05 21:53:15 UTC (rev 3090) +++ trunk/util/flashrom/flashchips.c 2008-02-06 22:07:58 UTC (rev 3091) @@ -100,10 +100,22 @@ probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, {"SST49LF160C", SST_ID, SST_49LF160C, 2048, 4 * 1024 , probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc}, - {"Pm49FL002", PMC_ID, PMC_49FL002, 256, 16 * 1024, + {"Pm49FL002", PMC_ID_NOPREFIX, PMC_49FL002, 256, 16 * 1024, probe_jedec, erase_chip_jedec, write_49fl004}, - {"Pm49FL004", PMC_ID, PMC_49FL004, 512, 64 * 1024, + {"Pm49FL004", PMC_ID_NOPREFIX, PMC_49FL004, 512, 64 * 1024, probe_jedec, erase_chip_jedec, write_49fl004}, + {"Pm25LV512", PMC_ID, PMC_25LV512, 64, 256, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Pm25LV010", PMC_ID, PMC_25LV010, 128, 256, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Pm25LV020", PMC_ID, PMC_25LV020, 256, 256, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Pm25LV040", PMC_ID, PMC_25LV040, 512, 256, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Pm25LV080B", PMC_ID, PMC_25LV080B, 1024, 256, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, + {"Pm25LV016B", PMC_ID, PMC_25LV016B, 2048, 256, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write, generic_spi_chip_read}, {"W29C011", WINBOND_ID, W_29C011, 128, 128, probe_jedec, erase_chip_jedec, write_jedec}, {"W29C040P", WINBOND_ID, W_29C040P, 512, 256, @@ -205,6 +217,8 @@ probe_spi, NULL, NULL}, {"MX unknown SPI chip", MX_ID, GENERIC_DEVICE_ID, 0, 0, probe_spi, NULL, NULL}, + {"PMC unknown SPI chip", PMC_ID, GENERIC_DEVICE_ID, 0, 0, + probe_spi, NULL, NULL}, {"SST unknown SPI chip", SST_ID, GENERIC_DEVICE_ID, 0, 0, probe_spi, NULL, NULL}, {"ST unknown SPI chip", ST_ID, GENERIC_DEVICE_ID, 0, 0, Modified: trunk/util/flashrom/spi.c =================================================================== --- trunk/util/flashrom/spi.c 2008-02-05 21:53:15 UTC (rev 3090) +++ trunk/util/flashrom/spi.c 2008-02-06 22:07:58 UTC (rev 3091) @@ -278,11 +278,17 @@ int probe_spi(struct flashchip *flash) { unsigned char readarr[3]; - uint8_t manuf_id; - uint16_t model_id; + uint32_t manuf_id; + uint32_t model_id; if (!generic_spi_rdid(readarr)) { - manuf_id = readarr[0]; - model_id = (readarr[1] << 8) | readarr[2]; + /* Check if this is a continuation vendor ID */ + if (readarr[0] == 0x7f) { + manuf_id = (readarr[0] << 8) | readarr[1]; + model_id = readarr[2]; + } else { + manuf_id = readarr[0]; + model_id = (readarr[1] << 8) | readarr[2]; + } printf_debug("%s: id1 0x%x, id2 0x%x\n", __FUNCTION__, manuf_id, model_id); if (manuf_id == flash->manufacture_id && model_id == flash->model_id) { From c-d.hailfinger.devel.2006 at gmx.net Wed Feb 6 23:09:57 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 06 Feb 2008 23:09:57 +0100 Subject: [coreboot] [PATCH] flashrom: Support Pm25LV* In-Reply-To: <47A9F8E8.2080200@stockwith.co.uk> References: <47A9E88C.2060606@gmx.net> <47A9F8E8.2080200@stockwith.co.uk> Message-ID: <47AA3035.8090602@gmx.net> On 06.02.2008 19:14, Chris Lingard wrote: > Carl-Daniel Hailfinger wrote: > >> Chris: Please try this against latest flashrom with the switch in both >> positions. It supersedes all previous patches. >> >> Handle JEDEC JEP106W continuation codes in SPI RDID. Some vendors like >> Programmable Micro Corp need this. >> Both the serial and parallel flash JEDEC detection routines would >> benefit from a parity/sanity check of the vendor ID. Will do this later. >> >> Add untested support for the PMC Pm25LV family of SPI flash chips. >> >> Signed-off-by: Carl-Daniel Hailfinger >> > Works beautifully > > Acked-by: Chris Lingard > Thanks, r3091. Regards, Carl-Daniel -- http://www.hailfinger.org/ From c-d.hailfinger.devel.2006 at gmx.net Wed Feb 6 23:14:59 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 06 Feb 2008 23:14:59 +0100 Subject: [coreboot] Problem with M57SLI and newly installed MX25L4005 In-Reply-To: <47A9FA83.1020109@stockwith.co.uk> References: <47A77DCB.2070405@stockwith.co.uk> <47A908B4.7010105@gmx.net> <47A91F2A.7000609@gmx.net> <47A9B39E.6090101@stockwith.co.uk> <47A9B901.3030104@gmx.net> <47A9BE90.1090905@stockwith.co.uk> <47A9CB38.1050904@gmx.net> <47A9D4DF.8060402@stockwith.co.uk> <47A9EC0C.8080507@gmx.net> <47A9FA83.1020109@stockwith.co.uk> Message-ID: <47AA3163.9020507@gmx.net> On 06.02.2008 19:20, Chris Lingard wrote: > Carl-Daniel Hailfinger wrote: > >> Can you try the patch I posted in a separate thread with subject >> "[PATCH] flashrom: Support Pm25LV*"? >> > Fantastic, output at last > > Switch up > > Calibrating delay loop... OK. > No coreboot table found. > Found chipset "NVIDIA MCP55", enabling flash write... OK. > Found board "GIGABYTE GA-M57SLI-S4": enabling flash write... Serial > flash segment 0xfffe0000-0xffffffff enabled > Serial flash segment 0x000e0000-0x000fffff enabled > Serial flash segment 0xffee0000-0xffefffff disabled > Serial flash segment 0xfff80000-0xfffeffff enabled > LPC write to serial flash enabled > serial flash pin 29 > OK. > Pm25LV020 found at physical address 0xfffc0000. > Flash part is Pm25LV020 (256 KB). > No operations were specified. > > > Switch down > > Calibrating delay loop... OK. > No coreboot table found. > Found chipset "NVIDIA MCP55", enabling flash write... OK. > Found board "GIGABYTE GA-M57SLI-S4": enabling flash write... Serial > flash segment 0xfffe0000-0xffffffff enabled > Serial flash segment 0x000e0000-0x000fffff enabled > Serial flash segment 0xffee0000-0xffefffff disabled > Serial flash segment 0xfff80000-0xfffeffff enabled > LPC write to serial flash enabled > serial flash pin 29 > OK. > Pm25LV040 found at physical address 0xfff80000. > Flash part is Pm25LV040 (512 KB). > No operations were specified. > I really like the results because they make sense. > Though I am still pretty sure that I have a MX25L4005A, because this is > what Harald wrote on the packet > It would be very interesting to know what the vendor flash tool (awdflash?) says about the chips. Could you post details to the list? It would help me to verify the code. Regards, Carl-Daniel -- http://www.hailfinger.org/ From ward at gnu.org Wed Feb 6 23:16:17 2008 From: ward at gnu.org (Ward Vandewege) Date: Wed, 6 Feb 2008 17:16:17 -0500 Subject: [coreboot] Coreboot-v2 patch rom names In-Reply-To: <004001c868f5$92890a70$3222040a@chimp> References: <2831fecf0802051320h8e96311k6bc636cf6856163d@mail.gmail.com> <20080206183412.GA18240@localdomain> <004001c868f5$92890a70$3222040a@chimp> Message-ID: <20080206221617.GB18536@localdomain> On Wed, Feb 06, 2008 at 12:22:11PM -0700, Myles Watson wrote: > > That would work - but what about other payloads? Maybe we could use a > > naming scheme like > > > > Config-buildrom-$(PAYLOAD).lb > > > > and then make buildrom look for such a file, perhaps falling back to the > > generic Config.lb file if it does not exist? > > That could work. Right now the Config-lab.lb for each architecture is a > fallback image with compression enabled. Maybe Config-lab.lb is not the > right name. Any payload that doesn't use compression will need to use the > Config.lb, and any payload that uses compression should use Config-lab.lb > > In some cases the ROM size is larger for the Config-lab.lb as well. About that - eventually I'd like to have the ROM size an option that can be set in the buildrom menus. Each payload/board combination should default to something reasonable (say, 1MB for an LAB payload), but it should be configurable. > I thought about naming them Config-ROM_SIZE-COMPRESSION.lb: > Config-1M-lzma.lb or > Config-512K-none.lb > > But it seemed uglier. Yeah. I don't really like that. > The two attached patches implement the switch, the buildrom patch depends on > the Coreboot patch being applied first to create a revision 3091. I tested > it by not updating the revision, then manually doing "svn up", applying the > patch to Coreboot, and rebuilding. > > There is a lot of cleaning up that could be done in the Config.lb files, but > I only touched the ones that buildrom uses, so I wouldn't break anything > else. > > Suggestions are welcome. > > Myles > > Signed-off-by: Myles Watson This looks good to me. Acked-by: Ward Vandewege Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From jordan.crouse at amd.com Wed Feb 6 23:22:46 2008 From: jordan.crouse at amd.com (Jordan Crouse) Date: Wed, 6 Feb 2008 15:22:46 -0700 Subject: [coreboot] goal for march summit In-Reply-To: <13426df10802061328p2b007ea8s530aa6bd8699d2c9@mail.gmail.com> References: <13426df10802012049t54d8f799p7b0c7b99f315583@mail.gmail.com> <20080204205410.GC9492@cosmic.amd.com> <13426df10802060406p3e4e955cyeb7f3209fd2f967@mail.gmail.com> <20080206210753.GA19217@cosmic.amd.com> <13426df10802061328p2b007ea8s530aa6bd8699d2c9@mail.gmail.com> Message-ID: <20080206222246.GC20367@cosmic.amd.com> On 06/02/08 13:28 -0800, ron minnich wrote: > OK. let's do it. Goal for linuxbi-- er, coreboot summit at the end of > march is to have v3 booting on simnow. I will, meanwhile, try to find > a friendly vendor who can get low cost boards to the coreboot > community. > > I hope one of the buildrom triumvirate can set up buildrom w/simnow > sometime this or next week :-) > > I tend to lean against via due to the need for chipset NDA. I tend to > lean toward AMD chipsets for the first board. Any suggestions there? Unfortunately not. The 8111 chipset on the Serengeti Cheetah is open, but they aren't available any more in real life. Everything else is still closed, but hopefully not for ever. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From rminnich at gmail.com Wed Feb 6 23:23:35 2008 From: rminnich at gmail.com (ron minnich) Date: Wed, 6 Feb 2008 14:23:35 -0800 Subject: [coreboot] goal for march summit In-Reply-To: <20080206222246.GC20367@cosmic.amd.com> References: <13426df10802012049t54d8f799p7b0c7b99f315583@mail.gmail.com> <20080204205410.GC9492@cosmic.amd.com> <13426df10802060406p3e4e955cyeb7f3209fd2f967@mail.gmail.com> <20080206210753.GA19217@cosmic.amd.com> <13426df10802061328p2b007ea8s530aa6bd8699d2c9@mail.gmail.com> <20080206222246.GC20367@cosmic.amd.com> Message-ID: <13426df10802061423r3afb3b69pbfc1f8231a35699f@mail.gmail.com> On Feb 6, 2008 2:22 PM, Jordan Crouse wrote: > > Unfortunately not. The 8111 chipset on the Serengeti Cheetah is open, > but they aren't available any more in real life. Everything else > is still closed, but hopefully not for ever. > we can get v3 up on simnow with old chipset, I am hoping to find an amd-based board with newer chipsets. ron From svn at coreboot.org Wed Feb 6 23:33:51 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Wed, 6 Feb 2008 23:33:51 +0100 Subject: [coreboot] r3092 - in trunk/coreboot-v2/targets: amd/serengeti_cheetah amd/serengeti_cheetah_fam10 emulation/qemu-i386 gigabyte/ga_2761gxdk gigabyte/m57sli supermicro/h8dmr tyan/s2882 tyan/s2891 Message-ID: Author: myles Date: 2008-02-06 23:33:50 +0100 (Wed, 06 Feb 2008) New Revision: 3092 Added: trunk/coreboot-v2/targets/amd/serengeti_cheetah/Config-lab.lb trunk/coreboot-v2/targets/amd/serengeti_cheetah_fam10/Config-lab.lb trunk/coreboot-v2/targets/emulation/qemu-i386/Config-lab.lb trunk/coreboot-v2/targets/gigabyte/m57sli/Config-lab.lb trunk/coreboot-v2/targets/supermicro/h8dmr/Config-lab.lb trunk/coreboot-v2/targets/tyan/s2882/Config-lab.lb trunk/coreboot-v2/targets/tyan/s2891/Config-lab.lb Modified: trunk/coreboot-v2/targets/amd/serengeti_cheetah/Config.lb trunk/coreboot-v2/targets/emulation/qemu-i386/Config.lb trunk/coreboot-v2/targets/gigabyte/ga_2761gxdk/Config.lb trunk/coreboot-v2/targets/gigabyte/m57sli/Config.lb trunk/coreboot-v2/targets/tyan/s2882/Config.lb trunk/coreboot-v2/targets/tyan/s2891/Config.lb Log: This patch changes the Config.lb files and adds Config-lab.lb files for architectures supported by buildrom. Myles Signed-off-by: Myles Watson Acked-by: Ward Vandewege Added: trunk/coreboot-v2/targets/amd/serengeti_cheetah/Config-lab.lb =================================================================== --- trunk/coreboot-v2/targets/amd/serengeti_cheetah/Config-lab.lb (rev 0) +++ trunk/coreboot-v2/targets/amd/serengeti_cheetah/Config-lab.lb 2008-02-06 22:33:50 UTC (rev 3092) @@ -0,0 +1,24 @@ +# Sample config file for +# the amd serengeti_cheetah +# This will make a target directory of ./serengeti_cheetah + +target serengeti_cheetah +mainboard amd/serengeti_cheetah + +option ROM_SIZE = 0x100000 +option USE_FAILOVER_IMAGE=0 +option HAVE_FAILOVER_BOOT=0 +option FAILOVER_SIZE=0 + +romimage "fallback" + option CONFIG_PRECOMPRESSED_PAYLOAD=1 + option CONFIG_COMPRESSED_PAYLOAD_LZMA=1 + option FALLBACK_SIZE=ROM_SIZE + option USE_FALLBACK_IMAGE=1 + option ROM_IMAGE_SIZE=0x1a000 + option XIP_ROM_SIZE=0x40000 + option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" + payload ../payload.elf.lzma +end + +buildrom ./coreboot.rom ROM_SIZE "fallback" Modified: trunk/coreboot-v2/targets/amd/serengeti_cheetah/Config.lb =================================================================== --- trunk/coreboot-v2/targets/amd/serengeti_cheetah/Config.lb 2008-02-06 22:07:58 UTC (rev 3091) +++ trunk/coreboot-v2/targets/amd/serengeti_cheetah/Config.lb 2008-02-06 22:33:50 UTC (rev 3092) @@ -29,7 +29,7 @@ # payload ../../../payloads/tg3.zelf # payload ../../../../payloads/tg3_vga.zelf # payload ../../../../payloads/tg3--filo_hda2_vga.zelf - payload ../../../../payloads/tg3--filo_hda2_vga_5.4.1.zelf +# payload ../../../../payloads/tg3--filo_hda2_vga_5.4.1.zelf # payload ../../../../payloads/e1000_vga.zelf # payload ../../../../payloads/tg3--filo_hda2_vga_5_4.zelf # payload ../../../payloads/tg3_com2.zelf @@ -38,6 +38,7 @@ # payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf # payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_5.3.zelf # payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_com2.zelf + payload ../payload.elf end romimage "fallback" @@ -62,7 +63,7 @@ # payload ../../../../payloads/filo_hda.zelf # payload ../../../../payloads/tg3--filo_hda2_vga.zelf # payload ../../../../payloads/tg3--filo_hda2_vga_5_4.zelf - payload ../../../../payloads/tg3--filo_hda2_vga_5.4.1.zelf +# payload ../../../../payloads/tg3--filo_hda2_vga_5.4.1.zelf # payload ../../../../payloads/filo_hda2_novga.zelf # payload ../../../payloads/tg3_com2.zelf # payload ../../../payloads/e1000--filo.zelf @@ -70,6 +71,7 @@ # payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf # payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_5.3.zelf # payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_com2.zelf + payload ../payload.elf end romimage "failover" Added: trunk/coreboot-v2/targets/amd/serengeti_cheetah_fam10/Config-lab.lb =================================================================== --- trunk/coreboot-v2/targets/amd/serengeti_cheetah_fam10/Config-lab.lb (rev 0) +++ trunk/coreboot-v2/targets/amd/serengeti_cheetah_fam10/Config-lab.lb 2008-02-06 22:33:50 UTC (rev 3092) @@ -0,0 +1,54 @@ +## +## This file is part of the coreboot project. +## +## Copyright (C) 2007 Advanced Micro Devices, Inc. +## +## This program is free software; you can redistribute it and/or modify +## it under the terms of the GNU General Public License as published by +## the Free Software Foundation; either version 2 of the License, or +## (at your option) any later version. +## +## This program is distributed in the hope that it will be useful, +## but WITHOUT ANY WARRANTY; without even the implied warranty of +## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +## GNU General Public License for more details. +## +## You should have received a copy of the GNU General Public License +## along with this program; if not, write to the Free Software +## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +## + +# Sample config file for +# the amd cheetah_fam10 +# This will make a target directory of ./serengeti_cheetah_fam10 + +target serengeti_cheetah_fam10 +mainboard amd/serengeti_cheetah_fam10 +# Request this level of debugging output + option DEFAULT_CONSOLE_LOGLEVEL=11 +# At a maximum only compile in this level of debugging + option MAXIMUM_CONSOLE_LOGLEVEL=11 + +# 1024KB ROM +option ROM_SIZE=1024*1024 +option FALLBACK_SIZE=ROM_SIZE-FAILOVER_SIZE + +romimage "fallback" + option USE_FAILOVER_IMAGE=0 + option USE_FALLBACK_IMAGE=1 + option ROM_IMAGE_SIZE=0x30000 + option XIP_ROM_SIZE=0x40000 + option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" + payload ../payload.elf.lzma +end + +romimage "failover" + option USE_FAILOVER_IMAGE=1 + option USE_FALLBACK_IMAGE=0 + option ROM_IMAGE_SIZE=FAILOVER_SIZE + option XIP_ROM_SIZE=FAILOVER_SIZE + option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Failover" +end + +buildrom ./coreboot.rom ROM_SIZE "fallback" "failover" + Added: trunk/coreboot-v2/targets/emulation/qemu-i386/Config-lab.lb =================================================================== --- trunk/coreboot-v2/targets/emulation/qemu-i386/Config-lab.lb (rev 0) +++ trunk/coreboot-v2/targets/emulation/qemu-i386/Config-lab.lb 2008-02-06 22:33:50 UTC (rev 3092) @@ -0,0 +1,22 @@ +# This will make a target directory of ./emulation_qemu-i386 + +target qemu-i386 +mainboard emulation/qemu-i386 + +option ROM_SIZE=2048*1024 +option CONFIG_COMPRESSED_PAYLOAD_LZMA=0 +option CONFIG_PRECOMPRESSED_PAYLOAD=0 + +option CC="gcc -m32" + +option HAVE_PIRQ_TABLE=1 +option IRQ_SLOT_COUNT=6 + +romimage "image" + option ROM_IMAGE_SIZE=0x10000 + option COREBOOT_EXTRA_VERSION="-LAB" + payload ../payload.elf.lzma +end + +buildrom ./qemu.rom ROM_SIZE "image" + Modified: trunk/coreboot-v2/targets/emulation/qemu-i386/Config.lb =================================================================== --- trunk/coreboot-v2/targets/emulation/qemu-i386/Config.lb 2008-02-06 22:07:58 UTC (rev 3091) +++ trunk/coreboot-v2/targets/emulation/qemu-i386/Config.lb 2008-02-06 22:33:50 UTC (rev 3092) @@ -13,7 +13,8 @@ romimage "image" option ROM_IMAGE_SIZE=0x10000 option COREBOOT_EXTRA_VERSION="-GRUB2" - payload /home/stepan/core.img +# payload /home/stepan/core.img + payload ../payload.elf end buildrom ./coreboot.rom ROM_SIZE "image" Modified: trunk/coreboot-v2/targets/gigabyte/ga_2761gxdk/Config.lb =================================================================== --- trunk/coreboot-v2/targets/gigabyte/ga_2761gxdk/Config.lb 2008-02-06 22:07:58 UTC (rev 3091) +++ trunk/coreboot-v2/targets/gigabyte/ga_2761gxdk/Config.lb 2008-02-06 22:33:50 UTC (rev 3092) @@ -32,7 +32,8 @@ option ROM_IMAGE_SIZE=0x20000 option XIP_ROM_SIZE=0x40000 option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" - payload ../../../../payloads/filo_uda1.elf +# payload ../../../../payloads/filo_uda1.elf + payload ../payload.elf end romimage "fallback" @@ -41,7 +42,8 @@ option ROM_IMAGE_SIZE=0x20000 option XIP_ROM_SIZE=0x40000 option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" - payload ../../../../payloads/filo_uda1.elf +# payload ../../../../payloads/filo_uda1.elf + payload ../payload.elf end romimage "failover" Added: trunk/coreboot-v2/targets/gigabyte/m57sli/Config-lab.lb =================================================================== --- trunk/coreboot-v2/targets/gigabyte/m57sli/Config-lab.lb (rev 0) +++ trunk/coreboot-v2/targets/gigabyte/m57sli/Config-lab.lb 2008-02-06 22:33:50 UTC (rev 3092) @@ -0,0 +1,49 @@ +## +## This file is part of the coreboot project. +## +## Copyright (C) 2007 AMD +## Written by Yinghai Lu for AMD. +## +## This program is free software; you can redistribute it and/or modify +## it under the terms of the GNU General Public License as published by +## the Free Software Foundation; either version 2 of the License, or +## (at your option) any later version. +## +## This program is distributed in the hope that it will be useful, +## but WITHOUT ANY WARRANTY; without even the implied warranty of +## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +## GNU General Public License for more details. +## +## You should have received a copy of the GNU General Public License +## along with this program; if not, write to the Free Software +## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +## + +# Sample config file for + +target m57sli +mainboard gigabyte/m57sli + +option ROM_SIZE=0x100000 +option FALLBACK_SIZE=(ROM_SIZE-0x1000) + +romimage "fallback" + option USE_FAILOVER_IMAGE=0 + option USE_FALLBACK_IMAGE=1 + option CONFIG_COMPRESSED_PAYLOAD_LZMA=1 + option CONFIG_PRECOMPRESSED_PAYLOAD=1 + option ROM_IMAGE_SIZE=0x17000 + option XIP_ROM_SIZE=0x40000 + option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" + payload ../payload.elf.lzma +end + +romimage "failover" + option USE_FAILOVER_IMAGE=1 + option USE_FALLBACK_IMAGE=0 + option ROM_IMAGE_SIZE=FAILOVER_SIZE + option XIP_ROM_SIZE=FAILOVER_SIZE + option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Failover" +end + +buildrom ./coreboot.rom ROM_SIZE "fallback" "failover" Modified: trunk/coreboot-v2/targets/gigabyte/m57sli/Config.lb =================================================================== --- trunk/coreboot-v2/targets/gigabyte/m57sli/Config.lb 2008-02-06 22:07:58 UTC (rev 3091) +++ trunk/coreboot-v2/targets/gigabyte/m57sli/Config.lb 2008-02-06 22:33:50 UTC (rev 3092) @@ -82,7 +82,7 @@ # payload ../../../../payloads/adlo.elf # payload ../../../../payloads/tg3--filo_hda2_vga_5_4.zelf # payload ../../../../payloads/forcedeth_mcp55_filo_hda2.zelf - payload ../../../../payloads/forcedeth--filo_hda2_vga_5_4_2_mcp55.zelf +# payload ../../../../payloads/forcedeth--filo_hda2_vga_5_4_2_mcp55.zelf # payload ../../../../payloads/forcedeth--filo_hda2_vga.zelf # payload ../../../payloads/tg3_com2.zelf # payload ../../../payloads/e1000--filo.zelf @@ -90,6 +90,7 @@ # payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf # payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_5.3.zelf # payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_com2.zelf + payload ../payload.elf end romimage "failover" Added: trunk/coreboot-v2/targets/supermicro/h8dmr/Config-lab.lb =================================================================== --- trunk/coreboot-v2/targets/supermicro/h8dmr/Config-lab.lb (rev 0) +++ trunk/coreboot-v2/targets/supermicro/h8dmr/Config-lab.lb 2008-02-06 22:33:50 UTC (rev 3092) @@ -0,0 +1,48 @@ +## +## This file is part of the coreboot project. +## +## Copyright (C) 2007 AMD +## Written by Yinghai Lu for AMD. +## +## This program is free software; you can redistribute it and/or modify +## it under the terms of the GNU General Public License as published by +## the Free Software Foundation; either version 2 of the License, or +## (at your option) any later version. +## +## This program is distributed in the hope that it will be useful, +## but WITHOUT ANY WARRANTY; without even the implied warranty of +## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +## GNU General Public License for more details. +## +## You should have received a copy of the GNU General Public License +## along with this program; if not, write to the Free Software +## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +## + +target h8dmr +mainboard supermicro/h8dmr + +option ROM_SIZE=0x100000 +# 44K for ATI ROM in 1M; 4K for failover +option FALLBACK_SIZE=(ROM_SIZE-0xC000) + +romimage "fallback" + option USE_FAILOVER_IMAGE=0 + option USE_FALLBACK_IMAGE=1 + option CONFIG_COMPRESSED_PAYLOAD_LZMA=1 + option CONFIG_PRECOMPRESSED_PAYLOAD=1 + option ROM_IMAGE_SIZE=0x18000 + option XIP_ROM_SIZE=0x40000 + option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" + payload ../payload.elf.lzma +end + +romimage "failover" + option USE_FAILOVER_IMAGE=1 + option USE_FALLBACK_IMAGE=0 + option ROM_IMAGE_SIZE=FAILOVER_SIZE + option XIP_ROM_SIZE=FAILOVER_SIZE + option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Failover" +end + +buildrom ./coreboot.rom ROM_SIZE "fallback" "failover" Added: trunk/coreboot-v2/targets/tyan/s2882/Config-lab.lb =================================================================== --- trunk/coreboot-v2/targets/tyan/s2882/Config-lab.lb (rev 0) +++ trunk/coreboot-v2/targets/tyan/s2882/Config-lab.lb 2008-02-06 22:33:50 UTC (rev 3092) @@ -0,0 +1,23 @@ +# Sample config file for +# the Tyan s2882 +# This will make a target directory of ./s2882 + +target s2882 +mainboard tyan/s2882 + +option ROM_SIZE=0x100000 +# 36K for ATI ROM in 1M +option FALLBACK_SIZE=(ROM_SIZE-0x9000) + +# Tyan s2882 +romimage "fallback" + option USE_FALLBACK_IMAGE=1 + option CONFIG_COMPRESSED_PAYLOAD_LZMA=1 + option CONFIG_PRECOMPRESSED_PAYLOAD=1 + option ROM_IMAGE_SIZE=0x17000 + option XIP_ROM_SIZE=0x40000 + option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" + payload ../payload.elf.lzma +end + +buildrom ./coreboot.rom ROM_SIZE "fallback" Modified: trunk/coreboot-v2/targets/tyan/s2882/Config.lb =================================================================== --- trunk/coreboot-v2/targets/tyan/s2882/Config.lb 2008-02-06 22:07:58 UTC (rev 3091) +++ trunk/coreboot-v2/targets/tyan/s2882/Config.lb 2008-02-06 22:33:50 UTC (rev 3092) @@ -26,8 +26,9 @@ # payload ../../../payloads/tg3--filo.zelf # payload ../../../payloads/e1000--filo.zelf # payload ../../../payloads/tg3--e1000--filo.zelf - payload ../../../../payloads/tg3--filo_hda2_vga.zelf +# payload ../../../../payloads/tg3--filo_hda2_vga.zelf # payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf + payload ../payload.elf end romimage "fallback" @@ -44,8 +45,9 @@ # payload ../../../payloads/tg3--filo.zelf # payload ../../../payloads/e1000--filo.zelf # payload ../../../payloads/tg3--e1000--filo.zelf - payload ../../../../payloads/tg3--filo_hda2_vga.zelf +# payload ../../../../payloads/tg3--filo_hda2_vga.zelf # payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf + payload ../payload.elf end buildrom ./coreboot.rom ROM_SIZE "normal" "fallback" Added: trunk/coreboot-v2/targets/tyan/s2891/Config-lab.lb =================================================================== --- trunk/coreboot-v2/targets/tyan/s2891/Config-lab.lb (rev 0) +++ trunk/coreboot-v2/targets/tyan/s2891/Config-lab.lb 2008-02-06 22:33:50 UTC (rev 3092) @@ -0,0 +1,23 @@ +# Sample config file for +# the Tyan s2891 +# This will make a target directory of ./s2891 + +target s2891 +mainboard tyan/s2891 + +option ROM_SIZE=0x100000 +# 36K for ATI ROM in 1M +option FALLBACK_SIZE=(ROM_SIZE-0x9000) + +# Tyan s2891 +romimage "fallback" + option USE_FALLBACK_IMAGE=1 + option CONFIG_COMPRESSED_PAYLOAD_LZMA=1 + option CONFIG_PRECOMPRESSED_PAYLOAD=1 + option ROM_IMAGE_SIZE=0x17000 + option XIP_ROM_SIZE=0x40000 + option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" + payload ../payload.elf.lzma +end + +buildrom ./coreboot.rom ROM_SIZE "fallback" Modified: trunk/coreboot-v2/targets/tyan/s2891/Config.lb =================================================================== --- trunk/coreboot-v2/targets/tyan/s2891/Config.lb 2008-02-06 22:07:58 UTC (rev 3091) +++ trunk/coreboot-v2/targets/tyan/s2891/Config.lb 2008-02-06 22:33:50 UTC (rev 3092) @@ -27,13 +27,14 @@ # payload ../../../payloads/filo_mem.elf # payload ../../../payloads/filo.zelf # payload ../../../payloads/tg3--filo.zelf - payload ../../../../payloads/tg3--filo_hda2_vga.zelf +# payload ../../../../payloads/tg3--filo_hda2_vga.zelf # payload ../../../payloads/tg3--filo_hda2_vga_com2.zelf # payload ../../../payloads/tg3--filo_hda2_vga_5_3.zelf # payload ../../../payloads/tg3--filo_btext_hda2.zelf # payload ../../../payloads/e1000--filo.zelf # payload ../../../payloads/tg3--e1000--filo.zelf # payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf + payload ../payload.elf end romimage "fallback" @@ -49,13 +50,14 @@ # payload ../../../payloads/filo_mem.elf # payload ../../../payloads/filo.zelf # payload ../../../payloads/tg3--filo.zelf - payload ../../../../payloads/tg3--filo_hda2_vga.zelf +# payload ../../../../payloads/tg3--filo_hda2_vga.zelf # payload ../../../payloads/tg3--filo_hda2_vga_com2.zelf # payload ../../../payloads/tg3--filo_hda2_vga_5_3.zelf # payload ../../../payloads/e1000--filo.zelf # payload ../../../payloads/tg3--filo_btext_hda2.zelf # payload ../../../payloads/tg3--e1000--filo.zelf # payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf + payload ../payload.elf end buildrom ./coreboot.rom ROM_SIZE "normal" "fallback" From svn at coreboot.org Wed Feb 6 23:39:13 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Wed, 6 Feb 2008 23:39:13 +0100 Subject: [coreboot] r106 - in buildrom-devel: config/platforms packages/coreboot-v2 packages/coreboot-v2/patches Message-ID: Author: myles Date: 2008-02-06 23:39:12 +0100 (Wed, 06 Feb 2008) New Revision: 106 Removed: buildrom-devel/packages/coreboot-v2/patches/2761gxdk-fix-target.patch buildrom-devel/packages/coreboot-v2/patches/m57sli-filo-and-etherboot-Config.lb.patch buildrom-devel/packages/coreboot-v2/patches/m57sli-kernel-and-lab-Config.lb.patch buildrom-devel/packages/coreboot-v2/patches/qemu-lab.patch buildrom-devel/packages/coreboot-v2/patches/qemu-payload.patch buildrom-devel/packages/coreboot-v2/patches/serengeti_cheetah-lab.patch buildrom-devel/packages/coreboot-v2/patches/serengeti_cheetah-payload.patch buildrom-devel/packages/coreboot-v2/patches/serengeti_cheetah_fam10-lab.patch buildrom-devel/packages/coreboot-v2/patches/supermicro-h8dmr-filo-and-etherboot-Config.lb.patch buildrom-devel/packages/coreboot-v2/patches/supermicro-h8dmr-kernel-and-lab-Config.lb.patch buildrom-devel/packages/coreboot-v2/patches/tyan-s2882-filo-Config.lb.patch buildrom-devel/packages/coreboot-v2/patches/tyan-s2882-kernel-and-lab-Config.lb.patch buildrom-devel/packages/coreboot-v2/patches/tyan-s2891-filo-Config.lb.patch buildrom-devel/packages/coreboot-v2/patches/tyan-s2891-kernel-and-lab-Config.lb.patch Modified: buildrom-devel/config/platforms/alix1c.conf buildrom-devel/config/platforms/db800.conf buildrom-devel/config/platforms/dbe61.conf buildrom-devel/config/platforms/ga-2761gxdk.conf buildrom-devel/config/platforms/m57sli.conf buildrom-devel/config/platforms/msm800sev.conf buildrom-devel/config/platforms/norwich.conf buildrom-devel/config/platforms/qemu.conf buildrom-devel/config/platforms/serengeti_cheetah.conf buildrom-devel/config/platforms/supermicro-h8dmr.conf buildrom-devel/config/platforms/tyan-s2882.conf buildrom-devel/config/platforms/tyan-s2891.conf buildrom-devel/packages/coreboot-v2/alix1c.mk buildrom-devel/packages/coreboot-v2/coreboot.inc buildrom-devel/packages/coreboot-v2/ga-2761gxdk.mk buildrom-devel/packages/coreboot-v2/generic.mk buildrom-devel/packages/coreboot-v2/m57sli.mk buildrom-devel/packages/coreboot-v2/msm800sev.mk buildrom-devel/packages/coreboot-v2/norwich.mk buildrom-devel/packages/coreboot-v2/qemu.mk buildrom-devel/packages/coreboot-v2/serengeti_cheetah.mk buildrom-devel/packages/coreboot-v2/supermicro-h8dmr.mk buildrom-devel/packages/coreboot-v2/tyan-s2882.mk buildrom-devel/packages/coreboot-v2/tyan-s2891.mk Log: This patch simplifies the handling of Config.lb files in buildrom. We no longer keep or patch config files in the buildrom tree. It also bumps the revision on the platforms to take advantage of the simplified Config.lb and Config-lab.lb files. Myles Signed-off-by: Myles Watson Acked-by: Ward Vandewege Modified: buildrom-devel/config/platforms/alix1c.conf =================================================================== --- buildrom-devel/config/platforms/alix1c.conf 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/config/platforms/alix1c.conf 2008-02-06 22:39:12 UTC (rev 106) @@ -28,9 +28,9 @@ COREBOOT_VENDOR=pcengines COREBOOT_BOARD=alix1c CBV2_CONFIG=Config.lb +CBV2_PAYLOAD_FILE_EXT=elf CBV2_TDIR=alix1c CBV2_TAG=3079 -COREBOOT_ROM_NAME=coreboot.rom # FILO configuration Modified: buildrom-devel/config/platforms/db800.conf =================================================================== --- buildrom-devel/config/platforms/db800.conf 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/config/platforms/db800.conf 2008-02-06 22:39:12 UTC (rev 106) @@ -31,9 +31,9 @@ COREBOOT_VENDOR=amd COREBOOT_BOARD=db800 CBV2_CONFIG=Config.lb +CBV2_PAYLOAD_FILE_EXT=elf CBV2_TDIR=db800 CBV2_TAG=3079 -COREBOOT_ROM_NAME=db800.rom # FILO configuration # Use a new FILO config for the DB800 to autoload an image Modified: buildrom-devel/config/platforms/dbe61.conf =================================================================== --- buildrom-devel/config/platforms/dbe61.conf 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/config/platforms/dbe61.conf 2008-02-06 22:39:12 UTC (rev 106) @@ -30,9 +30,9 @@ COREBOOT_VENDOR=artecgroup COREBOOT_BOARD=dbe61 CBV2_CONFIG=Config.lb +CBV2_PAYLOAD_FILE_EXT=elf CBV2_TDIR=dbe61 CBV2_TAG=3079 -COREBOOT_ROM_NAME=dbe61.rom # FILO configuration Modified: buildrom-devel/config/platforms/ga-2761gxdk.conf =================================================================== --- buildrom-devel/config/platforms/ga-2761gxdk.conf 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/config/platforms/ga-2761gxdk.conf 2008-02-06 22:39:12 UTC (rev 106) @@ -35,9 +35,9 @@ COREBOOT_VENDOR=gigabyte COREBOOT_BOARD=ga_2761gxdk CBV2_CONFIG=Config.lb +CBV2_PAYLOAD_FILE_EXT=elf CBV2_TDIR=ga_2761gxdk -CBV2_TAG=3079 -COREBOOT_ROM_NAME=coreboot.rom +CBV2_TAG=3092 # FILO configuration Modified: buildrom-devel/config/platforms/m57sli.conf =================================================================== --- buildrom-devel/config/platforms/m57sli.conf 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/config/platforms/m57sli.conf 2008-02-06 22:39:12 UTC (rev 106) @@ -39,9 +39,9 @@ COREBOOT_VENDOR=gigabyte COREBOOT_BOARD=m57sli CBV2_CONFIG=Config.lb +CBV2_PAYLOAD_FILE_EXT=elf CBV2_TDIR=m57sli -CBV2_TAG=3088 -COREBOOT_ROM_NAME=coreboot.rom +CBV2_TAG=3092 # FILO configuration Modified: buildrom-devel/config/platforms/msm800sev.conf =================================================================== --- buildrom-devel/config/platforms/msm800sev.conf 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/config/platforms/msm800sev.conf 2008-02-06 22:39:12 UTC (rev 106) @@ -29,9 +29,9 @@ COREBOOT_VENDOR=digitallogic COREBOOT_BOARD=msm800sev CBV2_CONFIG=Config.lb +CBV2_PAYLOAD_FILE_EXT=elf CBV2_TDIR=msm800sev CBV2_TAG=3079 -COREBOOT_ROM_NAME=coreboot.rom # FILO configuration Modified: buildrom-devel/config/platforms/norwich.conf =================================================================== --- buildrom-devel/config/platforms/norwich.conf 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/config/platforms/norwich.conf 2008-02-06 22:39:12 UTC (rev 106) @@ -29,9 +29,9 @@ COREBOOT_VENDOR=amd COREBOOT_BOARD=norwich CBV2_CONFIG=Config.lb +CBV2_PAYLOAD_FILE_EXT=elf CBV2_TDIR=norwich CBV2_TAG=3079 -COREBOOT_ROM_NAME=norwich.rom # FILO configuration Modified: buildrom-devel/config/platforms/qemu.conf =================================================================== --- buildrom-devel/config/platforms/qemu.conf 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/config/platforms/qemu.conf 2008-02-06 22:39:12 UTC (rev 106) @@ -24,15 +24,15 @@ ETHERBOOT_ARCH=i386 # coreboot-v2 configuration -CBV2_TAG=3079 +CBV2_TAG=3092 CBV2_CONFIG=Config.lb +CBV2_PAYLOAD_FILE_EXT=elf CBV2_TDIR=qemu-i386 # coreboot v3 configuration CBV3_CONFIG=qemu-i386-defconfig CBV3_TAG=HEAD -COREBOOT_ROM_NAME=qemu.rom COREBOOT_VENDOR=emulation COREBOOT_BOARD=qemu-i386 Modified: buildrom-devel/config/platforms/serengeti_cheetah.conf =================================================================== --- buildrom-devel/config/platforms/serengeti_cheetah.conf 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/config/platforms/serengeti_cheetah.conf 2008-02-06 22:39:12 UTC (rev 106) @@ -44,18 +44,16 @@ COREBOOT_VENDOR=amd CBV2_CONFIG=Config.lb +CBV2_PAYLOAD_FILE_EXT=elf ifeq ($(CONFIG_PLATFORM_CHEETAH_FAM10),y) COREBOOT_BOARD=serengeti_cheetah_fam10 CBV2_TDIR=serengeti_cheetah_fam10 -CBV2_TAG=3085 -COREBOOT_ROM_NAME=amd-cheetah-fam10.rom +CBV2_TAG=3092 else COREBOOT_BOARD=serengeti_cheetah -CBV2_CONFIG=Config.lb CBV2_TDIR=serengeti_cheetah -CBV2_TAG=3086 -COREBOOT_ROM_NAME=serengeti_cheetah.rom +CBV2_TAG=3092 endif # FILO configuration Modified: buildrom-devel/config/platforms/supermicro-h8dmr.conf =================================================================== --- buildrom-devel/config/platforms/supermicro-h8dmr.conf 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/config/platforms/supermicro-h8dmr.conf 2008-02-06 22:39:12 UTC (rev 106) @@ -39,9 +39,9 @@ COREBOOT_VENDOR=supermicro COREBOOT_BOARD=h8dmr CBV2_CONFIG=Config.lb +CBV2_PAYLOAD_FILE_EXT=elf CBV2_TDIR=h8dmr -CBV2_TAG=3079 -COREBOOT_ROM_NAME=coreboot.rom +CBV2_TAG=3092 # FILO configuration Modified: buildrom-devel/config/platforms/tyan-s2882.conf =================================================================== --- buildrom-devel/config/platforms/tyan-s2882.conf 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/config/platforms/tyan-s2882.conf 2008-02-06 22:39:12 UTC (rev 106) @@ -39,9 +39,9 @@ COREBOOT_VENDOR=tyan COREBOOT_BOARD=s2882 CBV2_CONFIG=Config.lb +CBV2_PAYLOAD_FILE_EXT=elf CBV2_TDIR=s2882 -CBV2_TAG=3079 -COREBOOT_ROM_NAME=coreboot.rom +CBV2_TAG=3092 # FILO configuration Modified: buildrom-devel/config/platforms/tyan-s2891.conf =================================================================== --- buildrom-devel/config/platforms/tyan-s2891.conf 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/config/platforms/tyan-s2891.conf 2008-02-06 22:39:12 UTC (rev 106) @@ -39,9 +39,9 @@ COREBOOT_VENDOR=tyan COREBOOT_BOARD=s2891 CBV2_CONFIG=Config.lb +CBV2_PAYLOAD_FILE_EXT=elf CBV2_TDIR=s2891 -CBV2_TAG=3079 -COREBOOT_ROM_NAME=coreboot.rom +CBV2_TAG=3092 # FILO configuration Modified: buildrom-devel/packages/coreboot-v2/alix1c.mk =================================================================== --- buildrom-devel/packages/coreboot-v2/alix1c.mk 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/packages/coreboot-v2/alix1c.mk 2008-02-06 22:39:12 UTC (rev 106) @@ -9,7 +9,7 @@ CBV2_BASE_DIR=svn CBV2_URL=svn://coreboot.org/repos/trunk/coreboot-v2 CBV2_TARBALL=coreboot-svn-$(CBV2_TAG).tar.gz -CBV2_PAYLOAD_TARGET=$(CBV2_BUILD_DIR)/payload.elf +CBV2_PAYLOAD_TARGET=$(CBV2_BUILD_DIR)/payload.$(CBV2_PAYLOAD_FILE_EXT) VSA_URL=http://www.amd.com/files/connectivitysolutions/geode/geode_lx/ CBV2_VSA=lx_vsa.36k.bin TARGET_ROM = $(COREBOOT_VENDOR)-$(COREBOOT_BOARD).rom Modified: buildrom-devel/packages/coreboot-v2/coreboot.inc =================================================================== --- buildrom-devel/packages/coreboot-v2/coreboot.inc 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/packages/coreboot-v2/coreboot.inc 2008-02-06 22:39:12 UTC (rev 106) @@ -15,7 +15,7 @@ endif endif -CBV2_OUTPUT=$(CBV2_BUILD_DIR)/$(COREBOOT_ROM_NAME) +CBV2_OUTPUT=$(CBV2_BUILD_DIR)/coreboot.rom CBV2_DIR=$(BUILD_DIR)/coreboot # If the user wanted to override the build directory - obey that now Modified: buildrom-devel/packages/coreboot-v2/ga-2761gxdk.mk =================================================================== --- buildrom-devel/packages/coreboot-v2/ga-2761gxdk.mk 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/packages/coreboot-v2/ga-2761gxdk.mk 2008-02-06 22:39:12 UTC (rev 106) @@ -6,12 +6,12 @@ endif endif -CBV2_PATCHES=$(PACKAGE_DIR)/coreboot-v2/patches/2761gxdk-fix-target.patch +CBV2_PATCHES= CBV2_BASE_DIR=svn CBV2_URL=svn://coreboot.org/repos/trunk/coreboot-v2 CBV2_TARBALL=coreboot-svn-$(CBV2_TAG).tar.gz -CBV2_PAYLOAD_TARGET=$(CBV2_BUILD_DIR)/payload.elf +CBV2_PAYLOAD_TARGET=$(CBV2_BUILD_DIR)/payload.$(CBV2_PAYLOAD_FILE_EXT) TARGET_ROM = $(COREBOOT_VENDOR)-$(COREBOOT_BOARD).rom include $(PACKAGE_DIR)/coreboot-v2/coreboot.inc Modified: buildrom-devel/packages/coreboot-v2/generic.mk =================================================================== --- buildrom-devel/packages/coreboot-v2/generic.mk 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/packages/coreboot-v2/generic.mk 2008-02-06 22:39:12 UTC (rev 106) @@ -9,7 +9,7 @@ CBV2_BASE_DIR=svn CBV2_URL=svn://coreboot.org/repos/trunk/coreboot-v2 CBV2_TARBALL=coreboot-svn-$(CBV2_TAG).tar.gz -CBV2_PAYLOAD_TARGET=$(CBV2_BUILD_DIR)/payload.elf +CBV2_PAYLOAD_TARGET=$(CBV2_BUILD_DIR)/payload.$(CBV2_PAYLOAD_FILE_EXT) TARGET_ROM = $(COREBOOT_VENDOR)-$(COREBOOT_BOARD).rom # This is the list of components that comprise the ROM (excluding the payload) Modified: buildrom-devel/packages/coreboot-v2/m57sli.mk =================================================================== --- buildrom-devel/packages/coreboot-v2/m57sli.mk 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/packages/coreboot-v2/m57sli.mk 2008-02-06 22:39:12 UTC (rev 106) @@ -1,5 +1,3 @@ -# This is the Generic coreboot target - ifeq ($(CONFIG_PLATFORM),y) ifeq ($(CBV2_TAG),) $(error You need to specify a version to pull in your platform config) @@ -8,27 +6,21 @@ CBV2_PATCHES= -ifeq ($(CONFIG_PAYLOAD_FILO),y) - CBV2_PATCHES += $(PACKAGE_DIR)/coreboot-v2/patches/m57sli-filo-and-etherboot-Config.lb.patch -endif - -ifeq ($(CONFIG_PAYLOAD_ETHERBOOT),y) - CBV2_PATCHES += $(PACKAGE_DIR)/coreboot-v2/patches/m57sli-filo-and-etherboot-Config.lb.patch -endif - ifeq ($(CONFIG_PAYLOAD_KERNEL),y) - CBV2_PATCHES += $(PACKAGE_DIR)/coreboot-v2/patches/m57sli-kernel-and-lab-Config.lb.patch + CBV2_CONFIG = Config-lab.lb + CBV2_PAYLOAD_FILE_EXT = elf.lzma endif ifeq ($(CONFIG_PAYLOAD_LAB),y) - CBV2_PATCHES += $(PACKAGE_DIR)/coreboot-v2/patches/m57sli-kernel-and-lab-Config.lb.patch + CBV2_CONFIG = Config-lab.lb + CBV2_PAYLOAD_FILE_EXT = elf.lzma endif CBV2_BASE_DIR=svn CBV2_URL=svn://coreboot.org/repos/trunk/coreboot-v2 CBV2_TARBALL=coreboot-svn-$(CBV2_TAG).tar.gz -CBV2_PAYLOAD_TARGET=$(CBV2_BUILD_DIR)/payload.elf +CBV2_PAYLOAD_TARGET=$(CBV2_BUILD_DIR)/payload.$(CBV2_PAYLOAD_FILE_EXT) TARGET_ROM = $(COREBOOT_VENDOR)-$(COREBOOT_BOARD).rom include $(PACKAGE_DIR)/coreboot-v2/coreboot.inc Modified: buildrom-devel/packages/coreboot-v2/msm800sev.mk =================================================================== --- buildrom-devel/packages/coreboot-v2/msm800sev.mk 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/packages/coreboot-v2/msm800sev.mk 2008-02-06 22:39:12 UTC (rev 106) @@ -9,7 +9,7 @@ CBV2_BASE_DIR=svn CBV2_URL=svn://coreboot.org/repos/trunk/coreboot-v2 CBV2_TARBALL=coreboot-svn-$(CBV2_TAG).tar.gz -CBV2_PAYLOAD_TARGET=$(CBV2_BUILD_DIR)/payload.elf +CBV2_PAYLOAD_TARGET=$(CBV2_BUILD_DIR)/payload.$(CBV2_PAYLOAD_FILE_EXT) VSA_URL=http://www.amd.com/files/connectivitysolutions/geode/geode_lx/ CBV2_VSA=lx_vsa.36k.bin TARGET_ROM = $(COREBOOT_VENDOR)-$(COREBOOT_BOARD).rom Modified: buildrom-devel/packages/coreboot-v2/norwich.mk =================================================================== --- buildrom-devel/packages/coreboot-v2/norwich.mk 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/packages/coreboot-v2/norwich.mk 2008-02-06 22:39:12 UTC (rev 106) @@ -11,7 +11,7 @@ CBV2_BASE_DIR=svn CBV2_URL=svn://coreboot.org/repos/trunk/coreboot-v2 CBV2_TARBALL=coreboot-svn-$(CBV2_TAG).tar.gz -CBV2_PAYLOAD_TARGET=$(CBV2_BUILD_DIR)/payload.elf +CBV2_PAYLOAD_TARGET=$(CBV2_BUILD_DIR)/payload.$(CBV2_PAYLOAD_FILE_EXT) VSA_URL=http://www.amd.com/files/connectivitysolutions/geode/geode_lx/ CBV2_VSA=lx_vsa.36k.bin TARGET_ROM = $(COREBOOT_VENDOR)-$(COREBOOT_BOARD).rom Deleted: buildrom-devel/packages/coreboot-v2/patches/2761gxdk-fix-target.patch =================================================================== --- buildrom-devel/packages/coreboot-v2/patches/2761gxdk-fix-target.patch 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/packages/coreboot-v2/patches/2761gxdk-fix-target.patch 2008-02-06 22:39:12 UTC (rev 106) @@ -1,24 +0,0 @@ -Index: svn/targets/gigabyte/ga_2761gxdk/Config.lb -=================================================================== ---- svn.orig/targets/gigabyte/ga_2761gxdk/Config.lb 2008-01-18 11:50:03.000000000 -0700 -+++ svn/targets/gigabyte/ga_2761gxdk/Config.lb 2008-01-28 11:28:24.000000000 -0700 -@@ -32,7 +32,8 @@ - option ROM_IMAGE_SIZE=0x20000 - option XIP_ROM_SIZE=0x40000 - option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" -- payload ../../../../payloads/filo_uda1.elf -+# payload ../../../../payloads/filo_uda1.elf -+ payload ../payload.elf - end - - romimage "fallback" -@@ -41,7 +42,8 @@ - option ROM_IMAGE_SIZE=0x20000 - option XIP_ROM_SIZE=0x40000 - option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" -- payload ../../../../payloads/filo_uda1.elf -+# payload ../../../../payloads/filo_uda1.elf -+ payload ../payload.elf - end - - romimage "failover" Deleted: buildrom-devel/packages/coreboot-v2/patches/m57sli-filo-and-etherboot-Config.lb.patch =================================================================== --- buildrom-devel/packages/coreboot-v2/patches/m57sli-filo-and-etherboot-Config.lb.patch 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/packages/coreboot-v2/patches/m57sli-filo-and-etherboot-Config.lb.patch 2008-02-06 22:39:12 UTC (rev 106) @@ -1,96 +0,0 @@ -Index: svn/targets/gigabyte/m57sli/Config.lb -=================================================================== ---- svn.orig/targets/gigabyte/m57sli/Config.lb 2008-01-18 11:50:03.000000000 -0700 -+++ svn/targets/gigabyte/m57sli/Config.lb 2008-01-18 13:33:03.000000000 -0700 -@@ -22,82 +22,30 @@ - target m57sli - mainboard gigabyte/m57sli - --# serengeti_leopard - romimage "normal" --# 48K for SCSI FW --# option ROM_SIZE = 475136 --# 48K for SCSI FW and 48K for ATI ROM --# option ROM_SIZE = 425984 --# 64K for Etherboot --# option ROM_SIZE = 458752 --# 44k for atixx.rom --# option ROM_SIZE = 479232 -- option USE_FAILOVER_IMAGE=0 -+ option USE_FAILOVER_IMAGE=0 - option USE_FALLBACK_IMAGE=0 --# option ROM_IMAGE_SIZE=0x13800 --# option ROM_IMAGE_SIZE=0x18800 - option ROM_IMAGE_SIZE=0x20000 --# option ROM_IMAGE_SIZE=0x15800 - option XIP_ROM_SIZE=0x40000 - option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" --# payload ../../../payloads/tg3--ide_disk.zelf --# payload ../../../payloads/filo.elf --# payload ../../../payloads/filo_mem.elf --# payload ../../../payloads/filo.zelf --# payload ../../../payloads/tg3--filo_hda2.zelf --# payload ../../../payloads/tg3.zelf --# payload ../../../../payloads/tg3_vga.zelf --# payload ../../../../payloads/tg3--filo_hda2_vga.zelf --# payload ../../../../payloads/tg3--filo_hda2_vga_5_4.zelf --# payload ../../../../payloads/forcedeth--filo_hda2_vga.zelf -- payload ../../../../payloads/forcedeth--filo_hda2_vga_5_4_2_mcp55.zelf --# payload ../../../payloads/tg3_com2.zelf --# payload ../../../payloads/e1000--filo.zelf --# payload ../../../payloads/tg3--e1000--filo.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_5.3.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_com2.zelf -+ payload ../payload.elf - end - - romimage "fallback" -- option USE_FAILOVER_IMAGE=0 -+ option USE_FAILOVER_IMAGE=0 - option USE_FALLBACK_IMAGE=1 --# option ROM_IMAGE_SIZE=0x13800 --# option ROM_IMAGE_SIZE=0x19800 - option ROM_IMAGE_SIZE=0x20000 --# option ROM_IMAGE_SIZE=0x15800 - option XIP_ROM_SIZE=0x40000 - option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" --# payload ../../../payloads/tg3--ide_disk.zelf --# payload ../../../payloads/filo.elf --# payload ../../../payloads/filo_mem.elf --# payload ../../../payloads/filo.zelf --# payload ../../../payloads/tg3--filo_hda2.zelf --# payload ../../../payloads/tg3.zelf --# payload ../../../../payloads/tg3_vga.zelf --# payload ../../../../payloads/memtest --# payload ../../../../payloads/e1000_vga.zelf --# payload ../../../../payloads/tg3--filo_hda2_vga.zelf --# payload ../../../../payloads/filo_hda.zelf --# payload ../../../../payloads/adlo.elf --# payload ../../../../payloads/tg3--filo_hda2_vga_5_4.zelf --# payload ../../../../payloads/forcedeth_mcp55_filo_hda2.zelf -- payload ../../../../payloads/forcedeth--filo_hda2_vga_5_4_2_mcp55.zelf --# payload ../../../../payloads/forcedeth--filo_hda2_vga.zelf --# payload ../../../payloads/tg3_com2.zelf --# payload ../../../payloads/e1000--filo.zelf --# payload ../../../payloads/tg3--e1000--filo.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_5.3.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_com2.zelf -+ payload ../payload.elf - end - - romimage "failover" -- option USE_FAILOVER_IMAGE=1 -- option USE_FALLBACK_IMAGE=0 -- option ROM_IMAGE_SIZE=FAILOVER_SIZE -- option XIP_ROM_SIZE=FAILOVER_SIZE -- option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Failover" -+ option USE_FAILOVER_IMAGE=1 -+ option USE_FALLBACK_IMAGE=0 -+ option ROM_IMAGE_SIZE=FAILOVER_SIZE -+ option XIP_ROM_SIZE=FAILOVER_SIZE -+ option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Failover" - end - - #buildrom ./coreboot.rom ROM_SIZE "normal" "fallback" Deleted: buildrom-devel/packages/coreboot-v2/patches/m57sli-kernel-and-lab-Config.lb.patch =================================================================== --- buildrom-devel/packages/coreboot-v2/patches/m57sli-kernel-and-lab-Config.lb.patch 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/packages/coreboot-v2/patches/m57sli-kernel-and-lab-Config.lb.patch 2008-02-06 22:39:12 UTC (rev 106) @@ -1,101 +0,0 @@ ---- LinuxBIOSv2/targets/gigabyte/m57sli/Config.lb-orig 2007-08-14 14:49:13.000000000 -0400 -+++ LinuxBIOSv2/targets/gigabyte/m57sli/Config.lb 2007-08-21 17:56:34.000000000 -0400 -@@ -19,86 +19,32 @@ - ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA - ## - -+# Sample config file for -+ - target m57sli - mainboard gigabyte/m57sli - --# serengeti_leopard --romimage "normal" --# 48K for SCSI FW --# option ROM_SIZE = 475136 --# 48K for SCSI FW and 48K for ATI ROM --# option ROM_SIZE = 425984 --# 64K for Etherboot --# option ROM_SIZE = 458752 --# 44k for atixx.rom --# option ROM_SIZE = 479232 -- option USE_FAILOVER_IMAGE=0 -- option USE_FALLBACK_IMAGE=0 --# option ROM_IMAGE_SIZE=0x13800 --# option ROM_IMAGE_SIZE=0x18800 -- option ROM_IMAGE_SIZE=0x20000 --# option ROM_IMAGE_SIZE=0x15800 -- option XIP_ROM_SIZE=0x40000 -- option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" --# payload ../../../payloads/tg3--ide_disk.zelf --# payload ../../../payloads/filo.elf --# payload ../../../payloads/filo_mem.elf --# payload ../../../payloads/filo.zelf --# payload ../../../payloads/tg3--filo_hda2.zelf --# payload ../../../payloads/tg3.zelf --# payload ../../../../payloads/tg3_vga.zelf --# payload ../../../../payloads/tg3--filo_hda2_vga.zelf --# payload ../../../../payloads/tg3--filo_hda2_vga_5_4.zelf --# payload ../../../../payloads/forcedeth--filo_hda2_vga.zelf -- payload ../../../../payloads/forcedeth--filo_hda2_vga_5_4_2_mcp55.zelf --# payload ../../../payloads/tg3_com2.zelf --# payload ../../../payloads/e1000--filo.zelf --# payload ../../../payloads/tg3--e1000--filo.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_5.3.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_com2.zelf --end -+option ROM_SIZE=0x100000 -+option FALLBACK_SIZE=(ROM_SIZE-0x1000) - - romimage "fallback" -- option USE_FAILOVER_IMAGE=0 -+ option USE_FAILOVER_IMAGE=0 - option USE_FALLBACK_IMAGE=1 --# option ROM_IMAGE_SIZE=0x13800 --# option ROM_IMAGE_SIZE=0x19800 -- option ROM_IMAGE_SIZE=0x20000 --# option ROM_IMAGE_SIZE=0x15800 -+ option CONFIG_COMPRESSED_PAYLOAD_LZMA=1 -+ option CONFIG_PRECOMPRESSED_PAYLOAD=1 -+ option ROM_IMAGE_SIZE=0x17000 - option XIP_ROM_SIZE=0x40000 - option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" --# payload ../../../payloads/tg3--ide_disk.zelf --# payload ../../../payloads/filo.elf --# payload ../../../payloads/filo_mem.elf --# payload ../../../payloads/filo.zelf --# payload ../../../payloads/tg3--filo_hda2.zelf --# payload ../../../payloads/tg3.zelf --# payload ../../../../payloads/tg3_vga.zelf --# payload ../../../../payloads/memtest --# payload ../../../../payloads/e1000_vga.zelf --# payload ../../../../payloads/tg3--filo_hda2_vga.zelf --# payload ../../../../payloads/filo_hda.zelf --# payload ../../../../payloads/adlo.elf --# payload ../../../../payloads/tg3--filo_hda2_vga_5_4.zelf --# payload ../../../../payloads/forcedeth_mcp55_filo_hda2.zelf -- payload ../../../../payloads/forcedeth--filo_hda2_vga_5_4_2_mcp55.zelf --# payload ../../../../payloads/forcedeth--filo_hda2_vga.zelf --# payload ../../../payloads/tg3_com2.zelf --# payload ../../../payloads/e1000--filo.zelf --# payload ../../../payloads/tg3--e1000--filo.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_5.3.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_com2.zelf -+ payload ../payload.elf - end - - romimage "failover" -- option USE_FAILOVER_IMAGE=1 -+ option USE_FAILOVER_IMAGE=1 - option USE_FALLBACK_IMAGE=0 - option ROM_IMAGE_SIZE=FAILOVER_SIZE - option XIP_ROM_SIZE=FAILOVER_SIZE - option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Failover" - end - --#buildrom ./coreboot.rom ROM_SIZE "normal" "fallback" --buildrom ./coreboot.rom ROM_SIZE "normal" "fallback" "failover" -+ -+buildrom ./coreboot.rom ROM_SIZE "fallback" "failover" Deleted: buildrom-devel/packages/coreboot-v2/patches/qemu-lab.patch =================================================================== --- buildrom-devel/packages/coreboot-v2/patches/qemu-lab.patch 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/packages/coreboot-v2/patches/qemu-lab.patch 2008-02-06 22:39:12 UTC (rev 106) @@ -1,28 +0,0 @@ -Index: svn/targets/emulation/qemu-i386/Config.lb -=================================================================== ---- svn/targets/emulation/qemu-i386/Config.lb (revision 2950) -+++ svn/targets/emulation/qemu-i386/Config.lb (working copy) -@@ -3,7 +3,9 @@ - target qemu-i386 - mainboard emulation/qemu-i386 - --option ROM_SIZE=256*1024 -+option ROM_SIZE=2048*1024 -+option CONFIG_COMPRESSED_PAYLOAD_LZMA=0 -+option CONFIG_PRECOMPRESSED_PAYLOAD=0 - - option CC="gcc -m32" - -@@ -12,9 +14,9 @@ - - romimage "image" - option ROM_IMAGE_SIZE=0x10000 -- option LINUXBIOS_EXTRA_VERSION="-GRUB2" -- payload /home/stepan/core.img -+ option LINUXBIOS_EXTRA_VERSION="-LAB" -+ payload ../payload.elf - end - --buildrom ./qemu-bios.rom ROM_SIZE "image" -+buildrom ./qemu.rom ROM_SIZE "image" - Deleted: buildrom-devel/packages/coreboot-v2/patches/qemu-payload.patch =================================================================== --- buildrom-devel/packages/coreboot-v2/patches/qemu-payload.patch 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/packages/coreboot-v2/patches/qemu-payload.patch 2008-02-06 22:39:12 UTC (rev 106) @@ -1,24 +0,0 @@ -Index: svn/targets/emulation/qemu-i386/Config.lb -=================================================================== ---- svn.orig/targets/emulation/qemu-i386/Config.lb 2008-01-18 11:50:03.000000000 -0700 -+++ svn/targets/emulation/qemu-i386/Config.lb 2008-01-18 13:40:00.000000000 -0700 -@@ -4,6 +4,8 @@ - mainboard emulation/qemu-i386 - - option ROM_SIZE=256*1024 -+option CONFIG_COMPRESSED_PAYLOAD_LZMA=0 -+option CONFIG_PRECOMPRESSED_PAYLOAD=0 - - option CC="gcc -m32" - -@@ -13,8 +15,8 @@ - romimage "image" - option ROM_IMAGE_SIZE=0x10000 - option COREBOOT_EXTRA_VERSION="-GRUB2" -- payload /home/stepan/core.img -+ payload ../payload.elf - end - --buildrom ./qemu-bios.rom ROM_SIZE "image" -+buildrom ./qemu.rom ROM_SIZE "image" - Deleted: buildrom-devel/packages/coreboot-v2/patches/serengeti_cheetah-lab.patch =================================================================== --- buildrom-devel/packages/coreboot-v2/patches/serengeti_cheetah-lab.patch 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/packages/coreboot-v2/patches/serengeti_cheetah-lab.patch 2008-02-06 22:39:12 UTC (rev 106) @@ -1,98 +0,0 @@ -Index: svn/targets/amd/serengeti_cheetah/Config.lb -=================================================================== ---- svn/targets/amd/serengeti_cheetah/Config.lb (revision 2950) -+++ svn/targets/amd/serengeti_cheetah/Config.lb (working copy) -@@ -5,81 +5,20 @@ - target serengeti_cheetah - mainboard amd/serengeti_cheetah - --# serengeti_leopard --romimage "normal" --# 48K for SCSI FW --# option ROM_SIZE = 475136 --# 48K for SCSI FW and 48K for ATI ROM --# option ROM_SIZE = 425984 --# 64K for Etherboot --# option ROM_SIZE = 458752 -- option USE_FAILOVER_IMAGE=0 -- option USE_FALLBACK_IMAGE=0 --# option ROM_IMAGE_SIZE=0x13800 --# option ROM_IMAGE_SIZE=0x18800 -- option ROM_IMAGE_SIZE=0x20000 --# option ROM_IMAGE_SIZE=0x15800 -- option XIP_ROM_SIZE=0x40000 -- option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" --# payload ../../../payloads/tg3--ide_disk.zelf --# payload ../../../payloads/filo.elf --# payload ../../../payloads/filo_mem.elf --# payload ../../../payloads/filo.zelf --# payload ../../../payloads/tg3--filo_hda2.zelf --# payload ../../../payloads/tg3.zelf --# payload ../../../../payloads/tg3_vga.zelf --# payload ../../../../payloads/tg3--filo_hda2_vga.zelf -- payload ../../../../payloads/tg3--filo_hda2_vga_5.4.1.zelf --# payload ../../../../payloads/e1000_vga.zelf --# payload ../../../../payloads/tg3--filo_hda2_vga_5_4.zelf --# payload ../../../payloads/tg3_com2.zelf --# payload ../../../payloads/e1000--filo.zelf --# payload ../../../payloads/tg3--e1000--filo.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_5.3.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_com2.zelf --end -+option ROM_SIZE = 0x100000 -+option USE_FAILOVER_IMAGE=0 -+option HAVE_FAILOVER_BOOT=0 -+option FAILOVER_SIZE=0 - --romimage "fallback" -- option USE_FAILOVER_IMAGE=0 -+romimage "fallback" -+ option CONFIG_PRECOMPRESSED_PAYLOAD=1 -+ option CONFIG_COMPRESSED_PAYLOAD_LZMA=1 -+ option FALLBACK_SIZE=ROM_SIZE - option USE_FALLBACK_IMAGE=1 --# option ROM_IMAGE_SIZE=0x13800 --# option ROM_IMAGE_SIZE=0x19800 -- option ROM_IMAGE_SIZE=0x20000 --# option ROM_IMAGE_SIZE=0x15800 -+ option ROM_IMAGE_SIZE=0x1a000 - option XIP_ROM_SIZE=0x40000 -- option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" --# payload ../../../payloads/tg3--ide_disk.zelf --# payload ../../../payloads/filo.elf --# payload ../../../payloads/filo_mem.elf --# payload ../../../payloads/filo.zelf --# payload ../../../payloads/tg3--filo_hda2.zelf --# payload ../../../payloads/tg3.zelf --# payload ../../../../payloads/tg3_vga.zelf --# payload ../../../../payloads/memtest --# payload ../../../../payloads/adlo.elf --# payload ../../../../payloads/e1000_vga.zelf --# payload ../../../../payloads/filo_hda.zelf --# payload ../../../../payloads/tg3--filo_hda2_vga.zelf --# payload ../../../../payloads/tg3--filo_hda2_vga_5_4.zelf -- payload ../../../../payloads/tg3--filo_hda2_vga_5.4.1.zelf --# payload ../../../../payloads/filo_hda2_novga.zelf --# payload ../../../payloads/tg3_com2.zelf --# payload ../../../payloads/e1000--filo.zelf --# payload ../../../payloads/tg3--e1000--filo.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_5.3.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_com2.zelf -+ option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" -+ payload ../payload.elf - end - --romimage "failover" -- option USE_FAILOVER_IMAGE=1 -- option USE_FALLBACK_IMAGE=0 -- option ROM_IMAGE_SIZE=FAILOVER_SIZE -- option XIP_ROM_SIZE=FAILOVER_SIZE -- option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Failover" --end -- -- --buildrom ./coreboot.rom ROM_SIZE "normal" "fallback" "failover" --#buildrom ./coreboot.rom ROM_SIZE "normal" "fallback" -+buildrom ./serengeti_cheetah.rom ROM_SIZE "fallback" Deleted: buildrom-devel/packages/coreboot-v2/patches/serengeti_cheetah-payload.patch =================================================================== --- buildrom-devel/packages/coreboot-v2/patches/serengeti_cheetah-payload.patch 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/packages/coreboot-v2/patches/serengeti_cheetah-payload.patch 2008-02-06 22:39:12 UTC (rev 106) @@ -1,65 +0,0 @@ -Index: svn/targets/amd/serengeti_cheetah/Config.lb -=================================================================== ---- svn.orig/targets/amd/serengeti_cheetah/Config.lb 2008-01-18 11:50:04.000000000 -0700 -+++ svn/targets/amd/serengeti_cheetah/Config.lb 2008-01-28 13:48:15.000000000 -0700 -@@ -21,23 +21,7 @@ - # option ROM_IMAGE_SIZE=0x15800 - option XIP_ROM_SIZE=0x40000 - option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" --# payload ../../../payloads/tg3--ide_disk.zelf --# payload ../../../payloads/filo.elf --# payload ../../../payloads/filo_mem.elf --# payload ../../../payloads/filo.zelf --# payload ../../../payloads/tg3--filo_hda2.zelf --# payload ../../../payloads/tg3.zelf --# payload ../../../../payloads/tg3_vga.zelf --# payload ../../../../payloads/tg3--filo_hda2_vga.zelf -- payload ../../../../payloads/tg3--filo_hda2_vga_5.4.1.zelf --# payload ../../../../payloads/e1000_vga.zelf --# payload ../../../../payloads/tg3--filo_hda2_vga_5_4.zelf --# payload ../../../payloads/tg3_com2.zelf --# payload ../../../payloads/e1000--filo.zelf --# payload ../../../payloads/tg3--e1000--filo.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_5.3.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_com2.zelf -+ payload ../payload.elf - end - - romimage "fallback" -@@ -49,27 +33,7 @@ - # option ROM_IMAGE_SIZE=0x15800 - option XIP_ROM_SIZE=0x40000 - option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" --# payload ../../../payloads/tg3--ide_disk.zelf --# payload ../../../payloads/filo.elf --# payload ../../../payloads/filo_mem.elf --# payload ../../../payloads/filo.zelf --# payload ../../../payloads/tg3--filo_hda2.zelf --# payload ../../../payloads/tg3.zelf --# payload ../../../../payloads/tg3_vga.zelf --# payload ../../../../payloads/memtest --# payload ../../../../payloads/adlo.elf --# payload ../../../../payloads/e1000_vga.zelf --# payload ../../../../payloads/filo_hda.zelf --# payload ../../../../payloads/tg3--filo_hda2_vga.zelf --# payload ../../../../payloads/tg3--filo_hda2_vga_5_4.zelf -- payload ../../../../payloads/tg3--filo_hda2_vga_5.4.1.zelf --# payload ../../../../payloads/filo_hda2_novga.zelf --# payload ../../../payloads/tg3_com2.zelf --# payload ../../../payloads/e1000--filo.zelf --# payload ../../../payloads/tg3--e1000--filo.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_5.3.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_com2.zelf -+ payload ../payload.elf - end - - romimage "failover" -@@ -81,5 +45,4 @@ - end - - --buildrom ./coreboot.rom ROM_SIZE "normal" "fallback" "failover" --#buildrom ./coreboot.rom ROM_SIZE "normal" "fallback" -+buildrom ./serengeti_cheetah.rom ROM_SIZE "normal" "fallback" "failover" Deleted: buildrom-devel/packages/coreboot-v2/patches/serengeti_cheetah_fam10-lab.patch =================================================================== --- buildrom-devel/packages/coreboot-v2/patches/serengeti_cheetah_fam10-lab.patch 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/packages/coreboot-v2/patches/serengeti_cheetah_fam10-lab.patch 2008-02-06 22:39:12 UTC (rev 106) @@ -1,44 +0,0 @@ -Index: svn/targets/amd/serengeti_cheetah_fam10/Config.lb -=================================================================== ---- svn/targets/amd/serengeti_cheetah_fam10/Config.lb (revision 3018) -+++ svn/targets/amd/serengeti_cheetah_fam10/Config.lb (working copy) -@@ -29,29 +29,14 @@ - # At a maximum only compile in this level of debugging - option MAXIMUM_CONSOLE_LOGLEVEL=11 - --# 512KB ROM --option ROM_SIZE=512*1024 -+# 1024KB ROM -+option ROM_SIZE=1024*1024 -+option FALLBACK_SIZE=ROM_SIZE-FAILOVER_SIZE - --# Cheetah Family 10 --#romimage "normal" --# 1MB ROM --# option ROM_SIZE = 0x100000 --# option USE_FAILOVER_IMAGE=0 --# option USE_FALLBACK_IMAGE=0 --# option ROM_IMAGE_SIZE=0x20000 --# option ROM_IMAGE_SIZE=0x30000 --# option XIP_ROM_SIZE=0x40000 --# option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" --# payload ../payload.elf --#end -- - romimage "fallback" - option USE_FAILOVER_IMAGE=0 - option USE_FALLBACK_IMAGE=1 --# option ROM_IMAGE_SIZE=0x13800 --# option ROM_IMAGE_SIZE=0x19800 -- option ROM_IMAGE_SIZE=0x3f000 --# option ROM_IMAGE_SIZE=0x15800 -+ option ROM_IMAGE_SIZE=0x30000 - option XIP_ROM_SIZE=0x40000 - option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" - payload ../payload.elf -@@ -65,6 +50,5 @@ - option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Failover" - end - --#buildrom ./amd-cheetah-fam10.rom ROM_SIZE "normal" "fallback" "failover" - buildrom ./amd-cheetah-fam10.rom ROM_SIZE "fallback" "failover" Deleted: buildrom-devel/packages/coreboot-v2/patches/supermicro-h8dmr-filo-and-etherboot-Config.lb.patch =================================================================== --- buildrom-devel/packages/coreboot-v2/patches/supermicro-h8dmr-filo-and-etherboot-Config.lb.patch 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/packages/coreboot-v2/patches/supermicro-h8dmr-filo-and-etherboot-Config.lb.patch 2008-02-06 22:39:12 UTC (rev 106) @@ -1,87 +0,0 @@ -Index: svn/targets/supermicro/h8dmr/Config.lb -=================================================================== ---- svn.orig/targets/supermicro/h8dmr/Config.lb 2008-01-18 13:09:01.000000000 -0700 -+++ svn/targets/supermicro/h8dmr/Config.lb 2008-01-18 13:09:04.000000000 -0700 -@@ -22,73 +22,25 @@ - target h8dmr - mainboard supermicro/h8dmr - -+# 44K for ATI ROM in 1M -+option ROM_SIZE = 1024*1024-44*1024 -+ - romimage "normal" --# 48K for SCSI FW --# option ROM_SIZE = 475136 --# 48K for SCSI FW and 48K for ATI ROM --# option ROM_SIZE = 425984 --# 64K for Etherboot --# option ROM_SIZE = 458752 --# 44k for atixx.rom --# option ROM_SIZE = 479232 -- option USE_FAILOVER_IMAGE=0 -+ # 44K for ATI ROM in 1M -+ #option ROM_SIZE = 1024*1024-44*1024 - option USE_FALLBACK_IMAGE=0 --# option ROM_IMAGE_SIZE=0x13800 --# option ROM_IMAGE_SIZE=0x18800 - option ROM_IMAGE_SIZE=0x20000 --# option ROM_IMAGE_SIZE=0x15800 -- option XIP_ROM_SIZE=0x40000 -+ option XIP_ROM_SIZE=0x20000 - option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" --# payload ../../../payloads/tg3--ide_disk.zelf --# payload ../../../payloads/filo.elf --# payload ../../../payloads/filo_mem.elf --# payload ../../../payloads/filo.zelf --# payload ../../../payloads/tg3--filo_hda2.zelf --# payload ../../../payloads/tg3.zelf --# payload ../../../../payloads/tg3_vga.zelf --# payload ../../../../payloads/tg3--filo_hda2_vga.zelf --# payload ../../../../payloads/tg3--filo_hda2_vga_5_4.zelf --# payload ../../../../payloads/forcedeth--filo_hda2_vga.zelf -- payload ../../../../payloads/forcedeth--filo_hda2_vga_5_4_2_mcp55.zelf --# payload ../../../payloads/tg3_com2.zelf --# payload ../../../payloads/e1000--filo.zelf --# payload ../../../payloads/tg3--e1000--filo.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_5.3.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_com2.zelf -+ payload ../payload.elf - end - - romimage "fallback" -- option USE_FAILOVER_IMAGE=0 - option USE_FALLBACK_IMAGE=1 --# option ROM_IMAGE_SIZE=0x13800 --# option ROM_IMAGE_SIZE=0x19800 - option ROM_IMAGE_SIZE=0x20000 --# option ROM_IMAGE_SIZE=0x15800 -- option XIP_ROM_SIZE=0x40000 -+ option XIP_ROM_SIZE=0x20000 - option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" --# payload ../../../payloads/tg3--ide_disk.zelf --# payload ../../../payloads/filo.elf --# payload ../../../payloads/filo_mem.elf --# payload ../../../payloads/filo.zelf --# payload ../../../payloads/tg3--filo_hda2.zelf --# payload ../../../payloads/tg3.zelf --# payload ../../../../payloads/tg3_vga.zelf --# payload ../../../../payloads/memtest --# payload ../../../../payloads/e1000_vga.zelf --# payload ../../../../payloads/tg3--filo_hda2_vga.zelf --# payload ../../../../payloads/filo_hda.zelf --# payload ../../../../payloads/adlo.elf --# payload ../../../../payloads/tg3--filo_hda2_vga_5_4.zelf --# payload ../../../../payloads/forcedeth_mcp55_filo_hda2.zelf -- payload ../../../../payloads/forcedeth--filo_hda2_vga_5_4_2_mcp55.zelf --# payload ../../../../payloads/forcedeth--filo_hda2_vga.zelf --# payload ../../../payloads/tg3_com2.zelf --# payload ../../../payloads/e1000--filo.zelf --# payload ../../../payloads/tg3--e1000--filo.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_5.3.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_com2.zelf -+ payload ../payload.elf - end - - romimage "failover" Deleted: buildrom-devel/packages/coreboot-v2/patches/supermicro-h8dmr-kernel-and-lab-Config.lb.patch =================================================================== --- buildrom-devel/packages/coreboot-v2/patches/supermicro-h8dmr-kernel-and-lab-Config.lb.patch 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/packages/coreboot-v2/patches/supermicro-h8dmr-kernel-and-lab-Config.lb.patch 2008-02-06 22:39:12 UTC (rev 106) @@ -1,102 +0,0 @@ -Index: Config.lb -=================================================================== ---- LinuxBIOSv2/targets/supermicro/h8dmr/Config.lb 2008-05-29 14:42:05.000000000 -0400 -+++ LinuxBIOSv2/targets/supermicro/h8dmr/Config.lb 2007-11-30 13:54:40.000000000 -0500 -@@ -22,82 +22,28 @@ - target h8dmr - mainboard supermicro/h8dmr - --romimage "normal" --# 48K for SCSI FW --# option ROM_SIZE = 475136 --# 48K for SCSI FW and 48K for ATI ROM --# option ROM_SIZE = 425984 --# 64K for Etherboot --# option ROM_SIZE = 458752 --# 44k for atixx.rom --# option ROM_SIZE = 479232 -- option USE_FAILOVER_IMAGE=0 -- option USE_FALLBACK_IMAGE=0 --# option ROM_IMAGE_SIZE=0x13800 --# option ROM_IMAGE_SIZE=0x18800 -- option ROM_IMAGE_SIZE=0x20000 --# option ROM_IMAGE_SIZE=0x15800 -- option XIP_ROM_SIZE=0x40000 -- option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" --# payload ../../../payloads/tg3--ide_disk.zelf --# payload ../../../payloads/filo.elf --# payload ../../../payloads/filo_mem.elf --# payload ../../../payloads/filo.zelf --# payload ../../../payloads/tg3--filo_hda2.zelf --# payload ../../../payloads/tg3.zelf --# payload ../../../../payloads/tg3_vga.zelf --# payload ../../../../payloads/tg3--filo_hda2_vga.zelf --# payload ../../../../payloads/tg3--filo_hda2_vga_5_4.zelf --# payload ../../../../payloads/forcedeth--filo_hda2_vga.zelf -- payload ../../../../payloads/forcedeth--filo_hda2_vga_5_4_2_mcp55.zelf --# payload ../../../payloads/tg3_com2.zelf --# payload ../../../payloads/e1000--filo.zelf --# payload ../../../payloads/tg3--e1000--filo.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_5.3.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_com2.zelf --end -+option ROM_SIZE=0x100000 -+# 44K for ATI ROM in 1M; 4K for failover -+option FALLBACK_SIZE=(ROM_SIZE-0xC000) - - romimage "fallback" -- option USE_FAILOVER_IMAGE=0 -+ option USE_FAILOVER_IMAGE=0 - option USE_FALLBACK_IMAGE=1 --# option ROM_IMAGE_SIZE=0x13800 --# option ROM_IMAGE_SIZE=0x19800 -- option ROM_IMAGE_SIZE=0x20000 --# option ROM_IMAGE_SIZE=0x15800 -+ option CONFIG_COMPRESSED_PAYLOAD_LZMA=1 -+ option CONFIG_PRECOMPRESSED_PAYLOAD=1 -+ option ROM_IMAGE_SIZE=0x18000 - option XIP_ROM_SIZE=0x40000 - option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" --# payload ../../../payloads/tg3--ide_disk.zelf --# payload ../../../payloads/filo.elf --# payload ../../../payloads/filo_mem.elf --# payload ../../../payloads/filo.zelf --# payload ../../../payloads/tg3--filo_hda2.zelf --# payload ../../../payloads/tg3.zelf --# payload ../../../../payloads/tg3_vga.zelf --# payload ../../../../payloads/memtest --# payload ../../../../payloads/e1000_vga.zelf --# payload ../../../../payloads/tg3--filo_hda2_vga.zelf --# payload ../../../../payloads/filo_hda.zelf --# payload ../../../../payloads/adlo.elf --# payload ../../../../payloads/tg3--filo_hda2_vga_5_4.zelf --# payload ../../../../payloads/forcedeth_mcp55_filo_hda2.zelf -- payload ../../../../payloads/forcedeth--filo_hda2_vga_5_4_2_mcp55.zelf --# payload ../../../../payloads/forcedeth--filo_hda2_vga.zelf --# payload ../../../payloads/tg3_com2.zelf --# payload ../../../payloads/e1000--filo.zelf --# payload ../../../payloads/tg3--e1000--filo.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_5.3.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_com2.zelf -+ payload ../payload.elf - end - - romimage "failover" -- option USE_FAILOVER_IMAGE=1 -- option USE_FALLBACK_IMAGE=0 -- option ROM_IMAGE_SIZE=FAILOVER_SIZE -- option XIP_ROM_SIZE=FAILOVER_SIZE -- option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Failover" -+ option USE_FAILOVER_IMAGE=1 -+ option USE_FALLBACK_IMAGE=0 -+ option ROM_IMAGE_SIZE=FAILOVER_SIZE -+ option XIP_ROM_SIZE=FAILOVER_SIZE -+ option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Failover" - end - --#buildrom ./coreboot.rom ROM_SIZE "normal" "fallback" --buildrom ./coreboot.rom ROM_SIZE "normal" "fallback" "failover" -+ -+buildrom ./coreboot.rom ROM_SIZE "fallback" "failover" Deleted: buildrom-devel/packages/coreboot-v2/patches/tyan-s2882-filo-Config.lb.patch =================================================================== --- buildrom-devel/packages/coreboot-v2/patches/tyan-s2882-filo-Config.lb.patch 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/packages/coreboot-v2/patches/tyan-s2882-filo-Config.lb.patch 2008-02-06 22:39:12 UTC (rev 106) @@ -1,56 +0,0 @@ -Index: svn/targets/tyan/s2882/Config.lb -=================================================================== ---- svn.orig/targets/tyan/s2882/Config.lb 2008-01-18 11:50:04.000000000 -0700 -+++ svn/targets/tyan/s2882/Config.lb 2008-01-18 13:45:33.000000000 -0700 -@@ -7,45 +7,21 @@ - - # Tyan s2882 - romimage "normal" --# 48K for SCSI FW or ATI ROM -- option ROM_SIZE = 512*1024-48*1024 --# 48K for SCSI FW and 48K for ATI ROM --# option ROM_SIZE = 512*1024-48*1024-48*1024 --# 64K for Etherboot --# option ROM_SIZE = 512*1024-64*1024 -+ # 36K for ATI ROM in 1M -+ option ROM_SIZE = 1024*1024-36*1024 - option USE_FALLBACK_IMAGE=0 --# option ROM_IMAGE_SIZE=0x11800 --# option ROM_IMAGE_SIZE=0x16000 - option ROM_IMAGE_SIZE=0x20000 -- option XIP_ROM_SIZE=0x20000 -+ option XIP_ROM_SIZE=0x20000 - option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" --# payload ../../../payloads/tg3--ide_disk.zelf --# payload ../../../payloads/filo.elf --# payload ../../../payloads/filo_mem.elf --# payload ../../../payloads/filo.zelf --# payload ../../../payloads/tg3--filo.zelf --# payload ../../../payloads/e1000--filo.zelf --# payload ../../../payloads/tg3--e1000--filo.zelf -- payload ../../../../payloads/tg3--filo_hda2_vga.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf -+ payload ../payload.elf - end - - romimage "fallback" - option USE_FALLBACK_IMAGE=1 --# option ROM_IMAGE_SIZE=0x11800 --# option ROM_IMAGE_SIZE=0x16000 - option ROM_IMAGE_SIZE=0x20000 -- option XIP_ROM_SIZE=0x20000 -+ option XIP_ROM_SIZE=0x20000 - option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" --# payload ../../../payloads/tg3--ide_disk.zelf --# payload ../../../payloads/filo.elf --# payload ../../../payloads/filo_mem.elf --# payload ../../../payloads/filo.zelf --# payload ../../../payloads/tg3--filo.zelf --# payload ../../../payloads/e1000--filo.zelf --# payload ../../../payloads/tg3--e1000--filo.zelf -- payload ../../../../payloads/tg3--filo_hda2_vga.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf -+ payload ../payload.elf - end - - buildrom ./coreboot.rom ROM_SIZE "normal" "fallback" Deleted: buildrom-devel/packages/coreboot-v2/patches/tyan-s2882-kernel-and-lab-Config.lb.patch =================================================================== --- buildrom-devel/packages/coreboot-v2/patches/tyan-s2882-kernel-and-lab-Config.lb.patch 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/packages/coreboot-v2/patches/tyan-s2882-kernel-and-lab-Config.lb.patch 2008-02-06 22:39:12 UTC (rev 106) @@ -1,62 +0,0 @@ -Index: LinuxBIOSv2/targets/tyan/s2882/Config.lb -=================================================================== ---- LinuxBIOSv2/targets/tyan/s2882/Config.lb (revision 2867) -+++ LinuxBIOSv2/targets/tyan/s2882/Config.lb (working copy) -@@ -5,47 +5,19 @@ - target s2882 - mainboard tyan/s2882 - --# Tyan s2882 --romimage "normal" --# 48K for SCSI FW or ATI ROM -- option ROM_SIZE = 512*1024-48*1024 --# 48K for SCSI FW and 48K for ATI ROM --# option ROM_SIZE = 512*1024-48*1024-48*1024 --# 64K for Etherboot --# option ROM_SIZE = 512*1024-64*1024 -- option USE_FALLBACK_IMAGE=0 --# option ROM_IMAGE_SIZE=0x11800 --# option ROM_IMAGE_SIZE=0x16000 -- option ROM_IMAGE_SIZE=0x20000 -- option XIP_ROM_SIZE=0x20000 -- option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" --# payload ../../../payloads/tg3--ide_disk.zelf --# payload ../../../payloads/filo.elf --# payload ../../../payloads/filo_mem.elf --# payload ../../../payloads/filo.zelf --# payload ../../../payloads/tg3--filo.zelf --# payload ../../../payloads/e1000--filo.zelf --# payload ../../../payloads/tg3--e1000--filo.zelf -- payload ../../../../payloads/tg3--filo_hda2_vga.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf --end -+option ROM_SIZE=0x100000 -+# 36K for ATI ROM in 1M -+option FALLBACK_SIZE=(ROM_SIZE-0x9000) - -+# Tyan s2882 - romimage "fallback" - option USE_FALLBACK_IMAGE=1 --# option ROM_IMAGE_SIZE=0x11800 --# option ROM_IMAGE_SIZE=0x16000 -- option ROM_IMAGE_SIZE=0x20000 -- option XIP_ROM_SIZE=0x20000 -+ option CONFIG_COMPRESSED_PAYLOAD_LZMA=1 -+ option CONFIG_PRECOMPRESSED_PAYLOAD=1 -+ option ROM_IMAGE_SIZE=0x17000 -+ option XIP_ROM_SIZE=0x40000 - option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" --# payload ../../../payloads/tg3--ide_disk.zelf --# payload ../../../payloads/filo.elf --# payload ../../../payloads/filo_mem.elf --# payload ../../../payloads/filo.zelf --# payload ../../../payloads/tg3--filo.zelf --# payload ../../../payloads/e1000--filo.zelf --# payload ../../../payloads/tg3--e1000--filo.zelf -- payload ../../../../payloads/tg3--filo_hda2_vga.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf -+ payload ../payload.elf - end - --buildrom ./coreboot.rom ROM_SIZE "normal" "fallback" -+buildrom ./coreboot.rom ROM_SIZE "fallback" Deleted: buildrom-devel/packages/coreboot-v2/patches/tyan-s2891-filo-Config.lb.patch =================================================================== --- buildrom-devel/packages/coreboot-v2/patches/tyan-s2891-filo-Config.lb.patch 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/packages/coreboot-v2/patches/tyan-s2891-filo-Config.lb.patch 2008-02-06 22:39:12 UTC (rev 106) @@ -1,66 +0,0 @@ -Index: svn/targets/tyan/s2891/Config.lb -=================================================================== ---- svn.orig/targets/tyan/s2891/Config.lb 2008-01-18 11:50:04.000000000 -0700 -+++ svn/targets/tyan/s2891/Config.lb 2008-01-18 13:48:08.000000000 -0700 -@@ -7,55 +7,21 @@ - - # Tyan s2891 - romimage "normal" --# 48K for ATI ROM in 1M -- option ROM_SIZE = 1024*1024-48*1024 --# 48K for SCSI FW or ATI ROM --# option ROM_SIZE = 512*1024-48*1024 --# 48K for SCSI FW and 48K for ATI ROM --# option ROM_SIZE = 512*1024-48*1024-48*1024 --# 64K for Etherboot --# option ROM_SIZE = 512*1024-64*1024 -+ # 36K for ATI ROM in 1M -+ option ROM_SIZE = 1024*1024-36*1024 - option USE_FALLBACK_IMAGE=0 --# option ROM_IMAGE_SIZE=0x11800 --# option ROM_IMAGE_SIZE=0x13000 --# option ROM_IMAGE_SIZE=0x16000 - option ROM_IMAGE_SIZE=0x20000 -- option XIP_ROM_SIZE=0x20000 -+ option XIP_ROM_SIZE=0x20000 - option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" --# payload ../../../payloads/tg3--ide_disk.zelf --# payload ../../../payloads/filo.elf --# payload ../../../payloads/filo_mem.elf --# payload ../../../payloads/filo.zelf --# payload ../../../payloads/tg3--filo.zelf -- payload ../../../../payloads/tg3--filo_hda2_vga.zelf --# payload ../../../payloads/tg3--filo_hda2_vga_com2.zelf --# payload ../../../payloads/tg3--filo_hda2_vga_5_3.zelf --# payload ../../../payloads/tg3--filo_btext_hda2.zelf --# payload ../../../payloads/e1000--filo.zelf --# payload ../../../payloads/tg3--e1000--filo.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf -+ payload ../payload.elf - end - - romimage "fallback" - option USE_FALLBACK_IMAGE=1 --# option ROM_IMAGE_SIZE=0x11800 --# option ROM_IMAGE_SIZE=0x13000 --# option ROM_IMAGE_SIZE=0x16000 - option ROM_IMAGE_SIZE=0x20000 -- option XIP_ROM_SIZE=0x20000 -+ option XIP_ROM_SIZE=0x20000 - option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" --# payload ../../../payloads/tg3--ide_disk.zelf --# payload ../../../payloads/filo.elf --# payload ../../../payloads/filo_mem.elf --# payload ../../../payloads/filo.zelf --# payload ../../../payloads/tg3--filo.zelf -- payload ../../../../payloads/tg3--filo_hda2_vga.zelf --# payload ../../../payloads/tg3--filo_hda2_vga_com2.zelf --# payload ../../../payloads/tg3--filo_hda2_vga_5_3.zelf --# payload ../../../payloads/e1000--filo.zelf --# payload ../../../payloads/tg3--filo_btext_hda2.zelf --# payload ../../../payloads/tg3--e1000--filo.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf -+ payload ../payload.elf - end - - buildrom ./coreboot.rom ROM_SIZE "normal" "fallback" Deleted: buildrom-devel/packages/coreboot-v2/patches/tyan-s2891-kernel-and-lab-Config.lb.patch =================================================================== --- buildrom-devel/packages/coreboot-v2/patches/tyan-s2891-kernel-and-lab-Config.lb.patch 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/packages/coreboot-v2/patches/tyan-s2891-kernel-and-lab-Config.lb.patch 2008-02-06 22:39:12 UTC (rev 106) @@ -1,70 +0,0 @@ ---- LinuxBIOSv2/targets/tyan/s2891/Config.lb 2007-09-26 16:37:35.000000000 -0400 -+++ LinuxBIOSv2/targets/tyan/s2891/Config.lb 2007-09-26 18:09:54.000000000 -0400 -@@ -5,57 +5,19 @@ - target s2891 - mainboard tyan/s2891 - --# Tyan s2891 --romimage "normal" --# 48K for ATI ROM in 1M -- option ROM_SIZE = 1024*1024-48*1024 --# 48K for SCSI FW or ATI ROM --# option ROM_SIZE = 512*1024-48*1024 --# 48K for SCSI FW and 48K for ATI ROM --# option ROM_SIZE = 512*1024-48*1024-48*1024 --# 64K for Etherboot --# option ROM_SIZE = 512*1024-64*1024 -- option USE_FALLBACK_IMAGE=0 --# option ROM_IMAGE_SIZE=0x11800 --# option ROM_IMAGE_SIZE=0x13000 --# option ROM_IMAGE_SIZE=0x16000 -- option ROM_IMAGE_SIZE=0x20000 -- option XIP_ROM_SIZE=0x20000 -- option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" --# payload ../../../payloads/tg3--ide_disk.zelf --# payload ../../../payloads/filo.elf --# payload ../../../payloads/filo_mem.elf --# payload ../../../payloads/filo.zelf --# payload ../../../payloads/tg3--filo.zelf -- payload ../../../../payloads/tg3--filo_hda2_vga.zelf --# payload ../../../payloads/tg3--filo_hda2_vga_com2.zelf --# payload ../../../payloads/tg3--filo_hda2_vga_5_3.zelf --# payload ../../../payloads/tg3--filo_btext_hda2.zelf --# payload ../../../payloads/e1000--filo.zelf --# payload ../../../payloads/tg3--e1000--filo.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf --end -+option ROM_SIZE=0x100000 -+# 36K for ATI ROM in 1M -+option FALLBACK_SIZE=(ROM_SIZE-0x9000) - -+# Tyan s2891 - romimage "fallback" - option USE_FALLBACK_IMAGE=1 --# option ROM_IMAGE_SIZE=0x11800 --# option ROM_IMAGE_SIZE=0x13000 --# option ROM_IMAGE_SIZE=0x16000 -- option ROM_IMAGE_SIZE=0x20000 -- option XIP_ROM_SIZE=0x20000 -+ option CONFIG_COMPRESSED_PAYLOAD_LZMA=1 -+ option CONFIG_PRECOMPRESSED_PAYLOAD=1 -+ option ROM_IMAGE_SIZE=0x17000 -+ option XIP_ROM_SIZE=0x40000 - option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" --# payload ../../../payloads/tg3--ide_disk.zelf --# payload ../../../payloads/filo.elf --# payload ../../../payloads/filo_mem.elf --# payload ../../../payloads/filo.zelf --# payload ../../../payloads/tg3--filo.zelf -- payload ../../../../payloads/tg3--filo_hda2_vga.zelf --# payload ../../../payloads/tg3--filo_hda2_vga_com2.zelf --# payload ../../../payloads/tg3--filo_hda2_vga_5_3.zelf --# payload ../../../payloads/e1000--filo.zelf --# payload ../../../payloads/tg3--filo_btext_hda2.zelf --# payload ../../../payloads/tg3--e1000--filo.zelf --# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf -+ payload ../payload.elf - end - --buildrom ./coreboot.rom ROM_SIZE "normal" "fallback" -+buildrom ./coreboot.rom ROM_SIZE "fallback" Modified: buildrom-devel/packages/coreboot-v2/qemu.mk =================================================================== --- buildrom-devel/packages/coreboot-v2/qemu.mk 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/packages/coreboot-v2/qemu.mk 2008-02-06 22:39:12 UTC (rev 106) @@ -10,12 +10,11 @@ CBV2_BASE_DIR=svn TARGET_ROM = $(COREBOOT_VENDOR)-$(COREBOOT_BOARD).rom -CBV2_PAYLOAD_TARGET=$(CBV2_BUILD_DIR)/payload.elf +CBV2_PAYLOAD_TARGET=$(CBV2_BUILD_DIR)/payload.$(CBV2_PAYLOAD_FILE_EXT) ifeq ($(CONFIG_PAYLOAD_LAB),y) -CBV2_PATCHES += $(PACKAGE_DIR)/coreboot-v2/patches/qemu-lab.patch -else -CBV2_PATCHES += $(PACKAGE_DIR)/coreboot-v2/patches/qemu-payload.patch + CBV2_CONFIG = Config-lab.lb + CBV2_PAYLOAD_FILE_EXT = elf.lzma endif CBV2_URL=svn://coreboot.org/repos/trunk/coreboot-v2 Modified: buildrom-devel/packages/coreboot-v2/serengeti_cheetah.mk =================================================================== --- buildrom-devel/packages/coreboot-v2/serengeti_cheetah.mk 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/packages/coreboot-v2/serengeti_cheetah.mk 2008-02-06 22:39:12 UTC (rev 106) @@ -18,15 +18,15 @@ ifeq ($(CONFIG_PLATFORM_CHEETAH_FAM10),y) ifeq ($(CONFIG_PAYLOAD_LAB),y) - CBV2_PATCHES += $(PACKAGE_DIR)/coreboot-v2/patches/serengeti_cheetah_fam10-lab.patch + CBV2_CONFIG = Config-lab.lb + CBV2_PAYLOAD_FILE_EXT = elf.lzma endif endif ifeq ($(CONFIG_PLATFORM_SERENGETI_CHEETAH),y) ifeq ($(CONFIG_PAYLOAD_LAB),y) - CBV2_PATCHES += $(PACKAGE_DIR)/coreboot-v2/patches/serengeti_cheetah-lab.patch -else - CBV2_PATCHES += $(PACKAGE_DIR)/coreboot-v2/patches/serengeti_cheetah-payload.patch + CBV2_CONFIG = Config-lab.lb + CBV2_PAYLOAD_FILE_EXT = elf.lzma endif ifeq ($(CONFIG_SIMNOW),y) @@ -37,7 +37,7 @@ CBV2_BASE_DIR=svn CBV2_URL=svn://coreboot.org/repos/trunk/coreboot-v2 CBV2_TARBALL=coreboot-svn-$(CBV2_TAG).tar.gz -CBV2_PAYLOAD_TARGET=$(CBV2_BUILD_DIR)/payload.elf +CBV2_PAYLOAD_TARGET=$(CBV2_BUILD_DIR)/payload.$(CBV2_PAYLOAD_FILE_EXT) TARGET_ROM = $(COREBOOT_VENDOR)-$(COREBOOT_BOARD).rom include $(PACKAGE_DIR)/coreboot-v2/coreboot.inc Modified: buildrom-devel/packages/coreboot-v2/supermicro-h8dmr.mk =================================================================== --- buildrom-devel/packages/coreboot-v2/supermicro-h8dmr.mk 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/packages/coreboot-v2/supermicro-h8dmr.mk 2008-02-06 22:39:12 UTC (rev 106) @@ -1,5 +1,3 @@ -# This is the Generic coreboot target - ifeq ($(CONFIG_PLATFORM),y) ifeq ($(CBV2_TAG),) $(error You need to specify a version to pull in your platform config) @@ -8,27 +6,21 @@ CBV2_PATCHES = -ifeq ($(CONFIG_PAYLOAD_FILO),y) - CBV2_PATCHES += $(PACKAGE_DIR)/coreboot-v2/patches/supermicro-h8dmr-filo-and-etherboot-Config.lb.patch -endif - -ifeq ($(CONFIG_PAYLOAD_ETHERBOOT),y) - CBV2_PATCHES += $(PACKAGE_DIR)/coreboot-v2/patches/supermicro-h8dmr-filo-and-etherboot-Config.lb.patch -endif - ifeq ($(CONFIG_PAYLOAD_KERNEL),y) - CBV2_PATCHES += $(PACKAGE_DIR)/coreboot-v2/patches/supermicro-h8dmr-kernel-and-lab-Config.lb.patch + CBV2_CONFIG = Config-lab.lb + CBV2_PAYLOAD_FILE_EXT = elf.lzma endif ifeq ($(CONFIG_PAYLOAD_LAB),y) - CBV2_PATCHES += $(PACKAGE_DIR)/coreboot-v2/patches/supermicro-h8dmr-kernel-and-lab-Config.lb.patch + CBV2_CONFIG = Config-lab.lb + CBV2_PAYLOAD_FILE_EXT = elf.lzma endif CBV2_BASE_DIR=svn CBV2_URL=svn://coreboot.org/repos/trunk/coreboot-v2 CBV2_TARBALL=coreboot-svn-$(CBV2_TAG).tar.gz -CBV2_PAYLOAD_TARGET=$(CBV2_BUILD_DIR)/payload.elf +CBV2_PAYLOAD_TARGET=$(CBV2_BUILD_DIR)/payload.$(CBV2_PAYLOAD_FILE_EXT) TARGET_ROM = $(COREBOOT_VENDOR)-$(COREBOOT_BOARD).rom include $(PACKAGE_DIR)/coreboot-v2/coreboot.inc Modified: buildrom-devel/packages/coreboot-v2/tyan-s2882.mk =================================================================== --- buildrom-devel/packages/coreboot-v2/tyan-s2882.mk 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/packages/coreboot-v2/tyan-s2882.mk 2008-02-06 22:39:12 UTC (rev 106) @@ -8,23 +8,21 @@ CBV2_PATCHES = -ifeq ($(CONFIG_PAYLOAD_FILO),y) - CBV2_PATCHES += $(PACKAGE_DIR)/coreboot-v2/patches/tyan-s2882-filo-Config.lb.patch -endif - ifeq ($(CONFIG_PAYLOAD_KERNEL),y) - CBV2_PATCHES += $(PACKAGE_DIR)/coreboot-v2/patches/tyan-s2882-kernel-and-lab-Config.lb.patch + CBV2_CONFIG = Config-lab.lb + CBV2_PAYLOAD_FILE_EXT = elf.lzma endif ifeq ($(CONFIG_PAYLOAD_LAB),y) - CBV2_PATCHES += $(PACKAGE_DIR)/coreboot-v2/patches/tyan-s2882-kernel-and-lab-Config.lb.patch + CBV2_CONFIG = Config-lab.lb + CBV2_PAYLOAD_FILE_EXT = elf.lzma endif CBV2_BASE_DIR=svn CBV2_URL=svn://coreboot.org/repos/trunk/coreboot-v2 CBV2_TARBALL=coreboot-svn-$(CBV2_TAG).tar.gz -CBV2_PAYLOAD_TARGET=$(CBV2_BUILD_DIR)/payload.elf +CBV2_PAYLOAD_TARGET=$(CBV2_BUILD_DIR)/payload.$(CBV2_PAYLOAD_FILE_EXT) TARGET_ROM = $(COREBOOT_VENDOR)-$(COREBOOT_BOARD).rom include $(PACKAGE_DIR)/coreboot-v2/coreboot.inc Modified: buildrom-devel/packages/coreboot-v2/tyan-s2891.mk =================================================================== --- buildrom-devel/packages/coreboot-v2/tyan-s2891.mk 2008-02-06 17:47:15 UTC (rev 105) +++ buildrom-devel/packages/coreboot-v2/tyan-s2891.mk 2008-02-06 22:39:12 UTC (rev 106) @@ -8,23 +8,21 @@ CBV2_PATCHES = -ifeq ($(CONFIG_PAYLOAD_FILO),y) - CBV2_PATCHES += $(PACKAGE_DIR)/coreboot-v2/patches/tyan-s2891-filo-Config.lb.patch -endif - ifeq ($(CONFIG_PAYLOAD_KERNEL),y) - CBV2_PATCHES += $(PACKAGE_DIR)/coreboot-v2/patches/tyan-s2891-kernel-and-lab-Config.lb.patch + CBV2_CONFIG = Config-lab.lb + CBV2_PAYLOAD_FILE_EXT = elf.lzma endif ifeq ($(CONFIG_PAYLOAD_LAB),y) - CBV2_PATCHES += $(PACKAGE_DIR)/coreboot-v2/patches/tyan-s2891-kernel-and-lab-Config.lb.patch + CBV2_CONFIG = Config-lab.lb + CBV2_PAYLOAD_FILE_EXT = elf.lzma endif CBV2_BASE_DIR=svn CBV2_URL=svn://coreboot.org/repos/trunk/coreboot-v2 CBV2_TARBALL=coreboot-svn-$(CBV2_TAG).tar.gz -CBV2_PAYLOAD_TARGET=$(CBV2_BUILD_DIR)/payload.elf +CBV2_PAYLOAD_TARGET=$(CBV2_BUILD_DIR)/payload.$(CBV2_PAYLOAD_FILE_EXT) TARGET_ROM = $(COREBOOT_VENDOR)-$(COREBOOT_BOARD).rom include $(PACKAGE_DIR)/coreboot-v2/coreboot.inc From myles at pel.cs.byu.edu Wed Feb 6 23:41:35 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Wed, 6 Feb 2008 15:41:35 -0700 Subject: [coreboot] Coreboot-v2 patch rom names In-Reply-To: <20080206221617.GB18536@localdomain> References: <2831fecf0802051320h8e96311k6bc636cf6856163d@mail.gmail.com> <20080206183412.GA18240@localdomain> <004001c868f5$92890a70$3222040a@chimp> <20080206221617.GB18536@localdomain> Message-ID: <007401c86911$6d8c4950$3222040a@chimp> > > > > In some cases the ROM size is larger for the Config-lab.lb as well. > > About that - eventually I'd like to have the ROM size an option that can > be > set in the buildrom menus. Each payload/board combination should default > to > something reasonable (say, 1MB for an LAB payload), but it should be > configurable. I agree. I just don't know what the best way to do it is. My fear is that we'll have so many Config.lb files that we'll forget to maintain them. > > > I thought about naming them Config-ROM_SIZE-COMPRESSION.lb: > > Config-1M-lzma.lb or > > Config-512K-none.lb > > > > But it seemed uglier. > > Yeah. I don't really like that. > > > Myles > > > > Signed-off-by: Myles Watson > > This looks good to me. > Thanks, v2 Rev 3092 and buildrom Rev 106 Myles > Acked-by: Ward Vandewege > > Thanks, > Ward. > > -- > Ward Vandewege > Free Software Foundation - Senior System Administrator From svn at coreboot.org Wed Feb 6 23:43:44 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Wed, 6 Feb 2008 23:43:44 +0100 Subject: [coreboot] r107 - buildrom-devel/packages/coreboot-v3/conf Message-ID: Author: myles Date: 2008-02-06 23:43:44 +0100 (Wed, 06 Feb 2008) New Revision: 107 Modified: buildrom-devel/packages/coreboot-v3/conf/qemu-i386-defconfig Log: This is a trivial fix of a broken config file from the LinuxBIOS -> Coreboot renaming process. Signed-off-by: Myles Watson Acked-by: Myles Watson Modified: buildrom-devel/packages/coreboot-v3/conf/qemu-i386-defconfig =================================================================== --- buildrom-devel/packages/coreboot-v3/conf/qemu-i386-defconfig 2008-02-06 22:39:12 UTC (rev 106) +++ buildrom-devel/packages/coreboot-v3/conf/qemu-i386-defconfig 2008-02-06 22:43:44 UTC (rev 107) @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# LinuxBIOS version: 3.0.0 -# Tue Jan 8 12:28:41 2008 +# coreboot version: 3.0.0 +# Wed Feb 6 13:55:31 2008 # # @@ -23,12 +23,12 @@ CONFIG_MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID=0x15ad CONFIG_MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID=0x1976 CONFIG_BOARD_EMULATION_QEMU_X86=y -# CONFIG_LINUXBIOS_ROMSIZE_KB_128 is not set -# CONFIG_LINUXBIOS_ROMSIZE_KB_256 is not set -# CONFIG_LINUXBIOS_ROMSIZE_KB_512 is not set -CONFIG_LINUXBIOS_ROMSIZE_KB_1024=y -# CONFIG_LINUXBIOS_ROMSIZE_KB_2048 is not set -CONFIG_LINUXBIOS_ROMSIZE_KB=1024 +# CONFIG_COREBOOT_ROMSIZE_KB_128 is not set +# CONFIG_COREBOOT_ROMSIZE_KB_256 is not set +# CONFIG_COREBOOT_ROMSIZE_KB_512 is not set +CONFIG_COREBOOT_ROMSIZE_KB_1024=y +# CONFIG_COREBOOT_ROMSIZE_KB_2048 is not set +CONFIG_COREBOOT_ROMSIZE_KB=1024 CONFIG_ARCH_X86=y CONFIG_ARCH="x86" CONFIG_CPU_I586=y From info at coresystems.de Wed Feb 6 23:57:26 2008 From: info at coresystems.de (coreboot information) Date: Wed, 06 Feb 2008 23:57:26 +0100 Subject: [coreboot] r3091 build service Message-ID: Dear coreboot readers! This is the automated build check service of coreboot. The developer "hailfinger" checked in revision 3091 to the coreboot source repository and caused the following changes: Change Log: Handle JEDEC JEP106W continuation codes in SPI RDID. Some vendors like Programmable Micro Corp (PMC) need this. Both the serial and parallel flash JEDEC detection routines would benefit from a parity/sanity check of the vendor ID. Will do this later. Add support for the PMC Pm25LV family of SPI flash chips. Signed-off-by: Carl-Daniel Hailfinger Acked-by: Chris Lingard Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3091&device=serengeti_cheetah_fam10&vendor=amd If something broke during this checkin please be a pain in hailfinger's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system From myles at pel.cs.byu.edu Wed Feb 6 23:58:55 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Wed, 6 Feb 2008 15:58:55 -0700 Subject: [coreboot] goal for march summit In-Reply-To: <13426df10802061328p2b007ea8s530aa6bd8699d2c9@mail.gmail.com> References: <13426df10802012049t54d8f799p7b0c7b99f315583@mail.gmail.com><20080204205410.GC9492@cosmic.amd.com><13426df10802060406p3e4e955cyeb7f3209fd2f967@mail.gmail.com><20080206210753.GA19217@cosmic.amd.com> <13426df10802061328p2b007ea8s530aa6bd8699d2c9@mail.gmail.com> Message-ID: <007801c86913$d9d85e30$3222040a@chimp> > I hope one of the buildrom triumvirate can set up buildrom w/simnow > sometime this or next week :-) Here's the patch to add buildrom support for serengeti_cheetah. It's not much, because there's no actual support in v3. I'll add the defconfig and the patch for the simulator (if it's still needed) when that's done. Signed-off-by: Myles Watson Myles -------------- next part -------------- A non-text attachment was scrubbed... Name: cheetah_support.diff Type: application/octet-stream Size: 1360 bytes Desc: not available URL: From myles at pel.cs.byu.edu Thu Feb 7 00:48:35 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Wed, 6 Feb 2008 16:48:35 -0700 Subject: [coreboot] v3 defconfig Message-ID: <2831fecf0802061548u776897baia4d9ab7f887b6637@mail.gmail.com> I'd like to make buildrom support v3 in the same way that it supports v2. I don't want buildrom to keep config files if it can help it. I thought it would be the best to support make defconfig in the same way that the kernel does. I'd like to be able to type make defconfig CONFIG_MAINBOARD_NAME=emulation/qemu-i386 and have it do the right thing. This patch doesn't work unfortunately, and I don't know why. Myles Index: util/kconfig/symbol.c =================================================================== --- util/kconfig/symbol.c (revision 574) +++ util/kconfig/symbol.c (working copy) @@ -54,6 +54,13 @@ uname(&uts); + sym = sym_lookup("MAINBOARDDIR", 0); + sym->type = S_STRING; + sym->flags |= SYMBOL_AUTO; + p = getenv("MAINBOARDDIR"); + if (p) + sym_add_default(sym, p); + sym = sym_lookup("ARCH", 0); sym->type = S_STRING; sym->flags |= SYMBOL_AUTO; Index: util/kconfig/confdata.c =================================================================== --- util/kconfig/confdata.c (revision 574) +++ util/kconfig/confdata.c (working copy) @@ -22,7 +22,7 @@ const char conf_def_filename[] = ".config"; -const char conf_defname[] = "arch/$ARCH/defconfig"; +const char conf_defname[] = "mainboard/$MAINBOARDDIR/defconfig"; const char *conf_confnames[] = { ".config", From info at coresystems.de Thu Feb 7 00:53:11 2008 From: info at coresystems.de (coreboot information) Date: Thu, 07 Feb 2008 00:53:11 +0100 Subject: [coreboot] r3092 build service Message-ID: Dear coreboot readers! This is the automated build check service of coreboot. The developer "myles" checked in revision 3092 to the coreboot source repository and caused the following changes: Change Log: This patch changes the Config.lb files and adds Config-lab.lb files for architectures supported by buildrom. Myles Signed-off-by: Myles Watson Acked-by: Ward Vandewege Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3092&device=serengeti_cheetah_fam10&vendor=amd If something broke during this checkin please be a pain in myles's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system From urbez at linuxupc.upc.edu Thu Feb 7 01:03:04 2008 From: urbez at linuxupc.upc.edu (Urbez Santana Roma) Date: Thu, 07 Feb 2008 01:03:04 +0100 Subject: [coreboot] [PATCH] CN10K patch, FILO ide discover patch. Message-ID: <1202342584.4894.21.camel@urbez.site> Note: for install this patch, you must download the last coreboot SVN, and install first the patch posted by Corey Osgood, that includes CN700/C7 and jetway mainboard. The filo patch is for correct a problem with FILO when tries to find the IDE disk, if more that one IDE interface is on, and no all IDE's are in native Mode. The count of compatibility interfaces are wrong, and not finds the interface that is marked as a IDE 0x0101 or SATA 0x0180 and not all are native, the search of the io base and control, are wrong. If this is not correct sorry :))) If in VT8237R have SATA as an 0101 and the IDE too 0101 class, with this patch, works, because counts corectly the unique non native interface IDE, as the first. NOTE1: in the epia-cn/Config.lb the IDE and SATA are enabled. NOTE2: in epia-cn/auto.c the values of PCI_DEV(0,0x11,0) 0x50 and 0x51 are different, for have IDE and SATA enableds at function enable_mainboard_devices NOTE3: Here is a file base.c that haves a udelay with use of rtdsc NOTE4: another function via_cn_fixup, fixes the use of PCI devices access to the memory. Must be improved, and not use a fixed value. NOTE5: have a change in cn700/raminit.c for configure in CN the memory. NOTE6: vt8237r configures the SATA device as an IDE class 0x0101 must be 0x0180????? Urbez Santana. -------------- next part -------------- A non-text attachment was scrubbed... Name: cn10k.patch Type: text/x-patch Size: 79150 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: filo_ide.patch Type: text/x-patch Size: 1720 bytes Desc: not available URL: From ward at gnu.org Thu Feb 7 01:50:48 2008 From: ward at gnu.org (Ward Vandewege) Date: Wed, 6 Feb 2008 19:50:48 -0500 Subject: [coreboot] goal for march summit In-Reply-To: <007801c86913$d9d85e30$3222040a@chimp> References: <13426df10802061328p2b007ea8s530aa6bd8699d2c9@mail.gmail.com> <007801c86913$d9d85e30$3222040a@chimp> Message-ID: <20080207005048.GA22111@localdomain> On Wed, Feb 06, 2008 at 03:58:55PM -0700, Myles Watson wrote: > > I hope one of the buildrom triumvirate can set up buildrom w/simnow > > sometime this or next week :-) > > Here's the patch to add buildrom support for serengeti_cheetah. It's not > much, because there's no actual support in v3. I'll add the defconfig and > the patch for the simulator (if it's still needed) when that's done. > > Signed-off-by: Myles Watson Acked-by: Ward Vandewege -- Ward Vandewege Free Software Foundation - Senior System Administrator From joe at smittys.pointclark.net Thu Feb 7 04:10:10 2008 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Wed, 06 Feb 2008 22:10:10 -0500 Subject: [coreboot] Run PCI rom before PCI bus scan?? Message-ID: <20080206221010.9xb8sj61wkwwgw40@www.smittys.pointclark.net> Quoting Peter Stuge : > On Tue, Feb 05, 2008 at 02:49:52PM -0500, Corey Osgood wrote: >> "In the LAN controller the D0 state is partitioned into two substates >> >> and >> >> "The integrated LAN controller will be disabled if no Platform LAN >> Connect component is detected (See Section 5.2.1.3)." >> >> >> Any help? > > The first one isn't that interesting since it also implies that PCI > config regs are actually available. > > The second one, or rather section 5.2.1.3, could be interesting if > "Platform LAN Connect component" is usually found in the BIOS. > > > //Peter > OK, here is what I have picked up reading, reading, and more reading: 1. When the system is powered on "At this point, the LAN controller is in the D0u state" 2. The "Platform LAN Connect component" is actually a command script (probibly a rom written in assembly) runs and sets up the CSR register (I could setup a script in the mainboard directory and run from auto.c). 3. At this point it goes into a DOa state. 3. The "Platform LAN Connect component" hands it over to the bios (coreboot) to setup "Memory, or I/O Base Registers in the PCI Configuration space" 4. nic is setup and ready to go! What do you think? Thanks - Joe From peter at stuge.se Thu Feb 7 04:15:03 2008 From: peter at stuge.se (Peter Stuge) Date: Thu, 7 Feb 2008 04:15:03 +0100 Subject: [coreboot] Run PCI rom before PCI bus scan?? In-Reply-To: <20080206221010.9xb8sj61wkwwgw40@www.smittys.pointclark.net> References: <20080206221010.9xb8sj61wkwwgw40@www.smittys.pointclark.net> Message-ID: <20080207031503.475.qmail@stuge.se> On Wed, Feb 06, 2008 at 10:10:10PM -0500, joe at smittys.pointclark.net wrote: > OK, here is what I have picked up reading, reading, and more > reading: > > 1. When the system is powered on "At this point, the LAN > controller is in the D0u state" Check. > 2. The "Platform LAN Connect component" is actually a command > script (probibly a rom written in assembly) runs and sets up the > CSR register That would explain things. > (I could setup a script in the mainboard directory and run from > auto.c). Sounds like a plan. > 3. At this point it goes into a DOa state. Yep. > 3. The "Platform LAN Connect component" hands it over to the bios > (coreboot) to setup "Memory, or I/O Base Registers in the PCI > Configuration space" Check. Though I don't think this is an active hand-over from the connect component, rather that it is called from the BIOS, then when it has finished the BIOS continues on. > 4. nic is setup and ready to go! > > What do you think? This matches your observations and the datasheet quotes. Since the Platform LAN Connect component is indeed software it is no doubt the missing piece of your puzzle. //Peter From corey.osgood at gmail.com Thu Feb 7 07:06:25 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Thu, 7 Feb 2008 01:06:25 -0500 Subject: [coreboot] [PATCH] CN10K patch, FILO ide discover patch. In-Reply-To: <1202342584.4894.21.camel@urbez.site> References: <1202342584.4894.21.camel@urbez.site> Message-ID: On Feb 6, 2008 7:03 PM, Urbez Santana Roma wrote: > > Note: for install this patch, you must download the last coreboot SVN, > and install first the patch posted by Corey Osgood, that includes > CN700/C7 and jetway mainboard. > > The filo patch is for correct a problem with FILO when tries to find the > IDE disk, if more that > one IDE interface is on, and no all IDE's are in native Mode. The count > of compatibility > interfaces are wrong, and not finds the interface that is marked as a > IDE 0x0101 or SATA 0x0180 > and not all are native, the search of the io base and control, are > wrong. > > If this is not correct sorry :))) > > > If in VT8237R have SATA as an 0101 and the IDE too 0101 class, with this > patch, works, because > counts corectly the unique non native interface IDE, as the first. Ok, so maybe this is why FILO beefs for me. It seems to find the IDE controller at hde, but dumps a message about a floating bus. I've already built filo and coreboot with the patch, but I'm holding off til tomorrow to test, at the moment I need sleep. Everything else IDE-wise looks to be the same. NOTE1: in the epia-cn/Config.lb the IDE and SATA are enabled. > NOTE2: in epia-cn/auto.c the values of PCI_DEV(0,0x11,0) 0x50 and 0x51 > are different, for have IDE and SATA enableds at function And they look like they aren't right? IDE cannot be disabled in the same way the rest of the devs there can. Also 0x51's lower bits control keyboard, mouse, and RTC function. > enable_mainboard_devices > NOTE3: Here is a file base.c that haves a udelay with use of rtdsc > NOTE4: another function via_cn_fixup, fixes the use of PCI devices > access to the memory. Must be improved, and not use a fixed value. The bus ones are set later during vt8237r lpc_init, so I'm not sure they're needed here (I've been testing with and without them, not seeing a difference), I'll investigate further. The memory bit is set correct during ram init in my lastest iterations. NOTE5: have a change in cn700/raminit.c for configure in CN the memory. I've confirmed these values to work with my Corsair and A-data memory too. > > NOTE6: vt8237r configures the SATA device as an IDE class 0x0101 must be > 0x0180????? Clearing bit 7 of the SATA's Rx45 allows the sub-class code to be changed. The vt8237r datasheet is floating around the interwebs, it was released by via. There may even be a link to it in the vt8237r code somewhere. Comment on this: + dev = pci_locate_device(PCI_ID(0x1106, 0x3149), 0); + if(dev == PCI_DEV_INVALID) { + print_debug("SATA Controller not found!\n\rUsing 00.f.0 PCI device\r\n"); + dev=PCI_DEV(0,0xf,0); + } If we can't find SATA, it means that for some reason it's probably already disabled, and setting the device statically might hit the IDE controller (since this function's entire purpose is to move the ide controller to where the sata controller is now). And we don't want to be messing up bits on an already flaky IDE controller ;) And lastly: does vga work, and do you use the bochs bios or have you made changes to the emulator so the vga bios will run? -Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Thu Feb 7 07:15:20 2008 From: rminnich at gmail.com (ron minnich) Date: Wed, 6 Feb 2008 22:15:20 -0800 Subject: [coreboot] v3 for alix: add ide support Message-ID: <13426df10802062215x194c285ajc7943a7b785341e0@mail.gmail.com> This code now lets filo find IDE. but it locks up :-( oh well. attached. ron -------------- next part -------------- A non-text attachment was scrubbed... Name: filofixer.diff Type: text/x-patch Size: 3657 bytes Desc: not available URL: From rminnich at gmail.com Thu Feb 7 07:19:30 2008 From: rminnich at gmail.com (ron minnich) Date: Wed, 6 Feb 2008 22:19:30 -0800 Subject: [coreboot] [patch] v3 stop on vsa errors In-Reply-To: <47AA0797.2080200@amd.com> References: <47AA0797.2080200@amd.com> Message-ID: <13426df10802062219n5c222b24t9073e2765b8d3009@mail.gmail.com> Acked-by: Ronald G. Minnich can you commit. Also can you remind me how we get timers working on this thing -- that's my filo problem, no working timer. ron From corey.osgood at gmail.com Thu Feb 7 07:21:15 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Thu, 7 Feb 2008 01:21:15 -0500 Subject: [coreboot] v3 for alix: add ide support In-Reply-To: <13426df10802062215x194c285ajc7943a7b785341e0@mail.gmail.com> References: <13426df10802062215x194c285ajc7943a7b785341e0@mail.gmail.com> Message-ID: On Feb 7, 2008 1:15 AM, ron minnich wrote: > This code now lets filo find IDE. > > but it locks up :-( > > oh well. attached. > > ron > >+ printk(BIOS_DEBUG, "cs5536_ide: %s\n", __func__); not __FUNCTION__ any more? I'm not sure what the current standards are, but either way: Acked-by: Corey Osgood -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Thu Feb 7 07:28:44 2008 From: peter at stuge.se (Peter Stuge) Date: Thu, 7 Feb 2008 07:28:44 +0100 Subject: [coreboot] v3 for alix: add ide support In-Reply-To: References: <13426df10802062215x194c285ajc7943a7b785341e0@mail.gmail.com> Message-ID: <20080207062844.22212.qmail@stuge.se> On Thu, Feb 07, 2008 at 01:21:15AM -0500, Corey Osgood wrote: > >+ printk(BIOS_DEBUG, "cs5536_ide: %s\n", __func__); > > not __FUNCTION__ any more? I'm not sure what the current standards > are, __func__ is good. http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Function-Names.html //Peter From rminnich at gmail.com Thu Feb 7 07:30:28 2008 From: rminnich at gmail.com (ron minnich) Date: Wed, 6 Feb 2008 22:30:28 -0800 Subject: [coreboot] v3 for alix: add ide support In-Reply-To: References: <13426df10802062215x194c285ajc7943a7b785341e0@mail.gmail.com> Message-ID: <13426df10802062230m52e15a7fv8417e52247f0b1c5@mail.gmail.com> On Feb 6, 2008 10:21 PM, Corey Osgood wrote: > not __FUNCTION__ any more? I'm not sure what the current standards are, __FUNCTION__ is gcc and acts kind of like a macro. __func__ is c99 and acts like it is a const variable. You can start looking around at postings about why __func__ is supposed to be wonderful; either way, __FUNCTION__ is supposed to be deprecated. So I am trying to catch up with the 20th century, now that I am in the 21st :-) __FUNCTION__ is deprecated in newer linux kernel code, but will not be replaced in older code, according to http://lkml.org/lkml/2007/5/2/470. We can probably follow the same rule. thanks ron From svn at coreboot.org Thu Feb 7 07:33:49 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Thu, 7 Feb 2008 07:33:49 +0100 Subject: [coreboot] r575 - in coreboot-v3: mainboard/pcengines/alix1c southbridge/amd/cs5536 Message-ID: Author: rminnich Date: 2008-02-07 07:33:49 +0100 (Thu, 07 Feb 2008) New Revision: 575 Modified: coreboot-v3/mainboard/pcengines/alix1c/dts coreboot-v3/southbridge/amd/cs5536/cs5536.c coreboot-v3/southbridge/amd/cs5536/dts Log: With this set of changes FILO now reliably finds the IDE controller. Press for default boot, or for boot prompt... boot: hda1:/vmlinuz root=/dev/hda1 console=tty0 console=ttyS0,115200 malloc_diag: alloc: 240 bytes (3 blocks), free: 16136 bytes (1 blocks) malloc_diag: alloc: 256 bytes (4 blocks), free: 16120 bytes (1 blocks) file_open: dev=hda1, path=/vmlinuz ide_probe: ide_probe drive #0 ide_probe: ctrl 1188096 base 0 find_ide_controller: found PCI IDE controller 1022:209a prog_if=0x80 find_ide_controller: primary channel: compatibility mode find_ide_controller: cmd_base=0x1f0 ctrl_base=0x3f4 Sadly, it locks up at this point, but this is still progress. I realize the location of the defines is a little odd, but I think it is useful to have them right next to the function that uses them. Index: southbridge/amd/cs5536/cs5536.c cs5536.c: add ide support functions from v2 Index: mainboard/pcengines/alix1c/dts Correct error in southbridge pcipath. Add enable_ide to dts. Index: southbridge/amd/cs5536/dts Add dts for enable_ide. Signed-off-by: Ronald G. Minnich Acked-by: Corey Osgood Modified: coreboot-v3/mainboard/pcengines/alix1c/dts =================================================================== --- coreboot-v3/mainboard/pcengines/alix1c/dts 2008-02-06 03:12:53 UTC (rev 574) +++ coreboot-v3/mainboard/pcengines/alix1c/dts 2008-02-07 06:33:49 UTC (rev 575) @@ -40,8 +40,9 @@ }; southbridge { /config/("southbridge/amd/cs5536/dts"); - pcipath = "0xf,1"; + pcipath = "0xf,0"; enabled; + enable_ide = "1"; }; superio { /config/("superio/winbond/w83627hf/dts"); Modified: coreboot-v3/southbridge/amd/cs5536/cs5536.c =================================================================== --- coreboot-v3/southbridge/amd/cs5536/cs5536.c 2008-02-06 03:12:53 UTC (rev 574) +++ coreboot-v3/southbridge/amd/cs5536/cs5536.c 2008-02-07 06:33:49 UTC (rev 575) @@ -541,7 +541,36 @@ } } +#define IDE_CFG 0x40 + #define CHANEN (1L << 1) + #define PWB (1L << 14) + #define CABLE (1L << 16) +#define IDE_DTC 0x48 +#define IDE_CAST 0x4C +#define IDE_ETC 0x50 + /** + * Enabled the IDE. This is code that is optionally run if the ide_enable is set + * in the mainboard dts. + * + * @param dev The device + */ +static void ide_init(struct device *dev) +{ + u32 ide_cfg; + + printk(BIOS_DEBUG, "cs5536_ide: %s\n", __func__); + /* GPIO and IRQ setup are handled in the main chipset code. */ + + // Enable the channel and Post Write Buffer + // NOTE: Only 32-bit writes to the data buffer are allowed when PWB is set + ide_cfg = pci_read_config32(dev, IDE_CFG); + ide_cfg |= CHANEN | PWB; + pci_write_config8(dev, IDE_CFG, ide_cfg); +} + + +/** * TODO. * * @param dev The device to use. @@ -576,6 +605,9 @@ enable_USB_port4(sb); + if (sb->enable_ide) + ide_init(dev); + #warning Add back in unwanted VPCI support #if 0 /* Disable unwanted virtual PCI devices. */ @@ -588,12 +620,6 @@ #endif } -static void southbridge_enable(struct device *dev) -{ - printk(BIOS_ERR, "cs5536: Enter %s: dev is %p\n", __FUNCTION__, dev); - printk(BIOS_ERR, "cs5536: Exit %s: dev is %p\n", __FUNCTION__, dev); -} - /** * A slightly different enable resources than the standard. * We grab control here as VSA has played in this chip as well. Modified: coreboot-v3/southbridge/amd/cs5536/dts =================================================================== --- coreboot-v3/southbridge/amd/cs5536/dts 2008-02-06 03:12:53 UTC (rev 574) +++ coreboot-v3/southbridge/amd/cs5536/dts 2008-02-07 06:33:49 UTC (rev 575) @@ -37,6 +37,9 @@ /* 0:IDE 1:FLASH, if you are using NAND flash instead of IDE drive. */ enable_ide_nand_flash = "0"; + /* IDE: enable CS5536 IDE. There may be a different IDE controller on board */ + enable_ide = "0"; + /* Enable USB Port 4 (0:host 1:device). */ enable_USBP4_device = "0"; From rminnich at gmail.com Thu Feb 7 07:34:10 2008 From: rminnich at gmail.com (ron minnich) Date: Wed, 6 Feb 2008 22:34:10 -0800 Subject: [coreboot] v3 for alix: add ide support In-Reply-To: References: <13426df10802062215x194c285ajc7943a7b785341e0@mail.gmail.com> Message-ID: <13426df10802062234m98219c1q5c1561c301c1df02@mail.gmail.com> Commited rev 575 From rminnich at gmail.com Thu Feb 7 07:52:02 2008 From: rminnich at gmail.com (ron minnich) Date: Wed, 6 Feb 2008 22:52:02 -0800 Subject: [coreboot] FIRST LINUX BOOT: v3 on alix1c! Message-ID: <13426df10802062252h537d1efdg99f48f1cad448296@mail.gmail.com> With this patch to FILO: Index: i386/timer.c =================================================================== --- i386/timer.c (revision 35) +++ i386/timer.c (working copy) @@ -105,7 +105,7 @@ return (end - start) * CLOCK_TICK_RATE / (1000*LATCH); } -static unsigned long long cpu_khz; +static unsigned long long cpu_khz = 500000; void setup_timers(void) { if (!cpu_khz) { I just booted linux. First v3 boot on real hardware. There are still problems. Linux is quite busy as revealed by a POST card but we don't seem to get interrupts. Things are not wired correctly. I am attaching the console log as I think this is pretty important for v3 :-) Wow, this was a long haul, but we are very close. Thanks to you all. thanks ron -------------- next part -------------- A non-text attachment was scrubbed... Name: firstv3boot Type: application/octet-stream Size: 11690 bytes Desc: not available URL: From peter at stuge.se Thu Feb 7 08:08:45 2008 From: peter at stuge.se (Peter Stuge) Date: Thu, 7 Feb 2008 08:08:45 +0100 Subject: [coreboot] FIRST LINUX BOOT: v3 on alix1c! In-Reply-To: <13426df10802062252h537d1efdg99f48f1cad448296@mail.gmail.com> References: <13426df10802062252h537d1efdg99f48f1cad448296@mail.gmail.com> Message-ID: <20080207070845.32578.qmail@stuge.se> On Wed, Feb 06, 2008 at 10:52:02PM -0800, ron minnich wrote: > I just booted linux. First v3 boot on real hardware. Congratulations! > There are still problems. Linux is quite busy as revealed by a POST > card but we don't seem to get interrupts. They are probably related. > Wow, this was a long haul, but we are very close. Thanks to you > all. Very exciting! :) //Peter From rminnich at gmail.com Thu Feb 7 08:46:54 2008 From: rminnich at gmail.com (ron minnich) Date: Wed, 6 Feb 2008 23:46:54 -0800 Subject: [coreboot] FIRST LINUX BOOT: v3 on alix1c! In-Reply-To: <20080207070845.32578.qmail@stuge.se> References: <13426df10802062252h537d1efdg99f48f1cad448296@mail.gmail.com> <20080207070845.32578.qmail@stuge.se> Message-ID: <13426df10802062346g3d00c2dfu1898100cd122efc4@mail.gmail.com> And it just broke again. Something in phase 6 init is not happening for some reason. The cs5536 init is not getting called in phase 6. If somebody wants to look at the last 30 minutes change log and see what I might have done, be my guest. Damn. I hope it is something simple. This is getting old. here is one fix however. ron -------------- next part -------------- A non-text attachment was scrubbed... Name: fixconstructor.diff Type: text/x-patch Size: 614 bytes Desc: not available URL: From Savchenko at altell.ru Thu Feb 7 09:51:07 2008 From: Savchenko at altell.ru (Mikhail Savchenko) Date: Thu, 7 Feb 2008 11:51:07 +0300 Subject: [coreboot] porting coreboot Message-ID: <4F42EFF6-0BEB-4C4F-B349-BCFAFEE356AC@altell.ru> can you assist to port on the tyan motherboard lspci 00:01.0 PCI bridge: Broadcom HT1000 PCI/PCI-X bridge 00:02.0 Host bridge: Broadcom HT1000 Legacy South Bridge 00:02.1 IDE interface: Broadcom HT1000 Legacy IDE controller 00:02.2 ISA bridge: Broadcom HT1000 LPC Bridge 00:03.0 USB Controller: Broadcom HT1000 USB Controller (rev 01) 00:03.1 USB Controller: Broadcom HT1000 USB Controller (rev 01) 00:03.2 USB Controller: Broadcom HT1000 USB Controller (rev 01) 00:04.0 Ethernet controller: Intel Corporation 82541GI/PI Gigabit Ethernet Controller (rev 05) 00:05.0 Ethernet controller: Intel Corporation 82541GI/PI Gigabit Ethernet Controller (rev 05) 00:06.0 VGA compatible controller: XGI - Xabre Graphics Inc Volari Z7 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/ Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/ Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/ Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/ Opteron] Miscellaneous Control 01:0d.0 PCI bridge: Broadcom HT1000 PCI/PCI-X bridge (rev c0) 01:0e.0 IDE interface: Broadcom BCM5785 (HT1000) PATA/IDE Mode 01:0e.1 IDE interface: Broadcom BCM5785 (HT1000) PATA/IDE Mode From c-d.hailfinger.devel.2006 at gmx.net Thu Feb 7 13:29:53 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 07 Feb 2008 13:29:53 +0100 Subject: [coreboot] FIRST LINUX BOOT: v3 on alix1c! In-Reply-To: <13426df10802062252h537d1efdg99f48f1cad448296@mail.gmail.com> References: <13426df10802062252h537d1efdg99f48f1cad448296@mail.gmail.com> Message-ID: <47AAF9C1.3060208@gmx.net> Hi Ron, On 07.02.2008 07:52, ron minnich wrote: > I just booted linux. First v3 boot on real hardware. > CONGRATULATIONS! This is a really great moment in coreboot history. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Thu Feb 7 15:17:08 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 07 Feb 2008 15:17:08 +0100 Subject: [coreboot] goal for march summit In-Reply-To: <13426df10802061423r3afb3b69pbfc1f8231a35699f@mail.gmail.com> References: <13426df10802012049t54d8f799p7b0c7b99f315583@mail.gmail.com> <20080204205410.GC9492@cosmic.amd.com> <13426df10802060406p3e4e955cyeb7f3209fd2f967@mail.gmail.com> <20080206210753.GA19217@cosmic.amd.com> <13426df10802061328p2b007ea8s530aa6bd8699d2c9@mail.gmail.com> <20080206222246.GC20367@cosmic.amd.com> <13426df10802061423r3afb3b69pbfc1f8231a35699f@mail.gmail.com> Message-ID: <47AB12E4.40802@gmx.net> On 06.02.2008 23:23, ron minnich wrote: > On Feb 6, 2008 2:22 PM, Jordan Crouse wrote: > > >> Unfortunately not. The 8111 chipset on the Serengeti Cheetah is open, >> but they aren't available any more in real life. Everything else >> is still closed, but hopefully not for ever. >> > > we can get v3 up on simnow with old chipset, I am hoping to find an > amd-based board with newer chipsets. > The problem with SimNow is that it only works on x86-64 machines. I do all of my development on my x86 (32bit) laptop, so if I ever want to test an x86-64 v3 port, I have to get an extra machine anyway. Hm. I'd really like to have us port existing support for a chipset from v2 to v3, so we can compare settings in case something goes wrong. Now for choosing the chipset: - Nvidia is pretty much ruled out if we want any chance of data sheet access. - SIS have contributed code, but I don't know about data sheets. Besides that, it is very difficult to buy a board with any SIS chipset (in Germany). - VIA is a possible target because we already have some code in v2 and at least one person has access to their data sheets, but they require an NDA. Plus, boards with the chipset are rather easy to buy. - AMD may work out in the next few months... RS690 data sheets (register reference guide) are publicly available, but SB600 is pretty much secret. Marc: Any idea whether the process of publishing the SB600 data sheets is handled by the same persons who are currently occupied with cleaning AMD/ATI Radeon data sheets? Regards, Carl-Daniel -- http://www.hailfinger.org/ From c-d.hailfinger.devel.2006 at gmx.net Thu Feb 7 16:45:59 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 07 Feb 2008 16:45:59 +0100 Subject: [coreboot] FIRST LINUX BOOT: v3 on alix1c! In-Reply-To: <13426df10802062346g3d00c2dfu1898100cd122efc4@mail.gmail.com> References: <13426df10802062252h537d1efdg99f48f1cad448296@mail.gmail.com> <20080207070845.32578.qmail@stuge.se> <13426df10802062346g3d00c2dfu1898100cd122efc4@mail.gmail.com> Message-ID: <47AB27B7.8030406@gmx.net> On 07.02.2008 08:46, ron minnich wrote: > And it just broke again. Something in phase 6 init is not happening > for some reason. > > The cs5536 init is not getting called in phase 6. If somebody wants to > look at the last 30 minutes change log and see what I might have done, > be my guest. > > Damn. I hope it is something simple. This is getting old. > > here is one fix however. > > ron > A little more verbose changelog would be appreciated. > This is a subtle problem. > > Devices must have constructor struct members to be used. > Same problem in superio/fintek/f71805f/superio.c superio/winbond/w83627hf/superio.c device/pcie_device.c device/agp_device.c device/hypertransport.c device/pci_device.c (twice) device/pcix_device.c device/pnp_device.c device/cardbus_device.c device/root_device.c You might want to look though all of them and fix where appropriate. > Signed-off-by: Ronald G. Minnich Acked-by: Carl-Daniel Hailfinger Regards, Carl-Daniel -- http://www.hailfinger.org/ From svn at coreboot.org Thu Feb 7 16:54:34 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Thu, 7 Feb 2008 16:54:34 +0100 Subject: [coreboot] r108 - buildrom-devel/config/platforms Message-ID: Author: myles Date: 2008-02-07 16:54:34 +0100 (Thu, 07 Feb 2008) New Revision: 108 Modified: buildrom-devel/config/platforms/Config.in buildrom-devel/config/platforms/serengeti_cheetah.conf Log: Here's the patch to add buildrom support for serengeti_cheetah. It's not much, because there's no actual support in v3. I'll add the defconfig and the patch for the simulator (if it's still needed) when that's done. Signed-off-by: Myles Watson Acked-by: Ward Vandewege Modified: buildrom-devel/config/platforms/Config.in =================================================================== --- buildrom-devel/config/platforms/Config.in 2008-02-06 22:43:44 UTC (rev 107) +++ buildrom-devel/config/platforms/Config.in 2008-02-07 15:54:34 UTC (rev 108) @@ -103,7 +103,6 @@ config PLATFORM_SERENGETI_CHEETAH bool "AMD Serengeti-Cheetah" depends VENDOR_AMD - depends COREBOOT_V2 select PLATFORM select PLATFORM_SUPPORT_64BIT @@ -117,7 +116,6 @@ config PLATFORM_CHEETAH_FAM10 bool "AMD Serengeti-Cheetah with fam10 processor" depends VENDOR_AMD - depends COREBOOT_V2 select PLATFORM select PLATFORM_SUPPORT_64BIT endchoice Modified: buildrom-devel/config/platforms/serengeti_cheetah.conf =================================================================== --- buildrom-devel/config/platforms/serengeti_cheetah.conf 2008-02-06 22:43:44 UTC (rev 107) +++ buildrom-devel/config/platforms/serengeti_cheetah.conf 2008-02-07 15:54:34 UTC (rev 108) @@ -46,14 +46,18 @@ CBV2_CONFIG=Config.lb CBV2_PAYLOAD_FILE_EXT=elf +CBV3_TAG=HEAD + ifeq ($(CONFIG_PLATFORM_CHEETAH_FAM10),y) COREBOOT_BOARD=serengeti_cheetah_fam10 CBV2_TDIR=serengeti_cheetah_fam10 CBV2_TAG=3092 +CBV3_CONFIG=serengeti_cheetah_fam10-defconfig else COREBOOT_BOARD=serengeti_cheetah CBV2_TDIR=serengeti_cheetah CBV2_TAG=3092 +CBV3_CONFIG=serengeti_cheetah-defconfig endif # FILO configuration From myles at pel.cs.byu.edu Thu Feb 7 16:55:37 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Thu, 7 Feb 2008 08:55:37 -0700 Subject: [coreboot] goal for march summit In-Reply-To: <20080207005048.GA22111@localdomain> References: <13426df10802061328p2b007ea8s530aa6bd8699d2c9@mail.gmail.com> <007801c86913$d9d85e30$3222040a@chimp> <20080207005048.GA22111@localdomain> Message-ID: <00bb01c869a1$e1e7dfe0$3222040a@chimp> > > Here's the patch to add buildrom support for serengeti_cheetah. It's > not > > much, because there's no actual support in v3. I'll add the defconfig > and > > the patch for the simulator (if it's still needed) when that's done. > > > > Signed-off-by: Myles Watson > > Acked-by: Ward Vandewege Thanks, Rev 106 Myles From Marc.Jones at AMD.com Thu Feb 7 17:04:35 2008 From: Marc.Jones at AMD.com (Marc Jones) Date: Thu, 07 Feb 2008 09:04:35 -0700 Subject: [coreboot] goal for march summit In-Reply-To: <47AB12E4.40802@gmx.net> References: <13426df10802012049t54d8f799p7b0c7b99f315583@mail.gmail.com> <20080204205410.GC9492@cosmic.amd.com> <13426df10802060406p3e4e955cyeb7f3209fd2f967@mail.gmail.com> <20080206210753.GA19217@cosmic.amd.com> <13426df10802061328p2b007ea8s530aa6bd8699d2c9@mail.gmail.com> <20080206222246.GC20367@cosmic.amd.com> <13426df10802061423r3afb3b69pbfc1f8231a35699f@mail.gmail.com> <47AB12E4.40802@gmx.net> Message-ID: <47AB2C13.90501@AMD.com> Carl-Daniel Hailfinger wrote: > - AMD may work out in the next few months... RS690 data sheets (register > reference guide) are publicly available, but SB600 is pretty much secret. > > We want to, but I don't know if we will have it done by the summit. > Marc: Any idea whether the process of publishing the SB600 data sheets > is handled by the same persons who are currently occupied with cleaning > AMD/ATI Radeon data sheets? > I think it is the same person and they are very busy with lots of things we want released. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From rminnich at gmail.com Thu Feb 7 17:06:45 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 7 Feb 2008 08:06:45 -0800 Subject: [coreboot] goal for march summit In-Reply-To: <47AB2C13.90501@AMD.com> References: <13426df10802012049t54d8f799p7b0c7b99f315583@mail.gmail.com> <20080204205410.GC9492@cosmic.amd.com> <13426df10802060406p3e4e955cyeb7f3209fd2f967@mail.gmail.com> <20080206210753.GA19217@cosmic.amd.com> <13426df10802061328p2b007ea8s530aa6bd8699d2c9@mail.gmail.com> <20080206222246.GC20367@cosmic.amd.com> <13426df10802061423r3afb3b69pbfc1f8231a35699f@mail.gmail.com> <47AB12E4.40802@gmx.net> <47AB2C13.90501@AMD.com> Message-ID: <13426df10802070806r3d43aa8bl4621ad1549ba06c6@mail.gmail.com> If we want real hardware it is probably going to have to be a cheap via board? ron From svn at coreboot.org Thu Feb 7 17:09:24 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Thu, 7 Feb 2008 17:09:24 +0100 Subject: [coreboot] r576 - coreboot-v3/northbridge/amd/geodelx Message-ID: Author: mjones Date: 2008-02-07 17:09:24 +0100 (Thu, 07 Feb 2008) New Revision: 576 Modified: coreboot-v3/northbridge/amd/geodelx/vsmsetup.c Log: If there is a problem loading VSA we should stop here instead of failing in PCI scan later. Signed-off-by: Marc Jones Acked-by: Ronald G. Minnich Modified: coreboot-v3/northbridge/amd/geodelx/vsmsetup.c =================================================================== --- coreboot-v3/northbridge/amd/geodelx/vsmsetup.c 2008-02-07 06:33:49 UTC (rev 575) +++ coreboot-v3/northbridge/amd/geodelx/vsmsetup.c 2008-02-07 16:09:24 UTC (rev 576) @@ -183,13 +183,11 @@ init_archive(&archive); if (find_file(&archive, "blob/vsa", &file)){ - printk(BIOS_ERR, "NO VSA found!\n"); - return; + die("FATAL: NO VSA found!\n"); } if (process_file(&file, (void *)VSA2_BUFFER)) { - printk(BIOS_ERR, "Processing /blob/vsa failed\n"); - return; + die("FATAL: Processing /blob/vsa failed\n"); } buf = (unsigned char *)VSA2_BUFFER; @@ -202,8 +200,7 @@ don't bother. */ if ((buf[0x20] != 0xb0) || (buf[0x21] != 0x10) || (buf[0x22] != 0xe6) || (buf[0x23] != 0x80)) { - printk(BIOS_ERR, "do_vsmbios: no vsainit.bin signature, skipping!\n"); - return; + die("FATAL: no vsainit.bin signature, skipping!\n"); } /* ecx gets smm, edx gets sysm */ @@ -218,7 +215,6 @@ if (VSA_vrRead(SIGNATURE) == VSA2_SIGNATURE) printk(BIOS_DEBUG, "do_vsmbios: VSA2 VR signature verified\n"); else - printk(BIOS_ERR, - "do_vsmbios: VSA2 VR signature not valid, install failed!\n"); + die("FATAL: VSA2 VR signature not valid, install failed!\n"); } From Marc.Jones at AMD.com Thu Feb 7 17:09:51 2008 From: Marc.Jones at AMD.com (Marc Jones) Date: Thu, 07 Feb 2008 09:09:51 -0700 Subject: [coreboot] [patch] v3 stop on vsa errors In-Reply-To: <13426df10802062219n5c222b24t9073e2765b8d3009@mail.gmail.com> References: <47AA0797.2080200@amd.com> <13426df10802062219n5c222b24t9073e2765b8d3009@mail.gmail.com> Message-ID: <47AB2D4F.2080800@AMD.com> ron minnich wrote: > Acked-by: Ronald G. Minnich > > can you commit. Also can you remind me how we get timers working on > this thing -- that's my filo problem, no working timer. > > ron > > > r576 Thanks, Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From svn at coreboot.org Thu Feb 7 17:17:21 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Thu, 7 Feb 2008 17:17:21 +0100 Subject: [coreboot] r577 - coreboot-v3/southbridge/amd/cs5536 Message-ID: Author: rminnich Date: 2008-02-07 17:17:21 +0100 (Thu, 07 Feb 2008) New Revision: 577 Modified: coreboot-v3/southbridge/amd/cs5536/cs5536.c Log: This is a subtle error. An operations struct, to work as a constructor, must initialize the .constructor struct member. This error is so subtle that we might consider changing the device code; or at least working on the documentation to make it more clear. The key question: do we ever want an operations struct that can NOT operate as a device constructor? When this code was designed over a year ago, it seemed that we might; now, it is not so certain. Signed-off-by: Ronald G. Minnich Acked-by: Carl-Daniel Hailfinger Modified: coreboot-v3/southbridge/amd/cs5536/cs5536.c =================================================================== --- coreboot-v3/southbridge/amd/cs5536/cs5536.c 2008-02-07 16:09:24 UTC (rev 576) +++ coreboot-v3/southbridge/amd/cs5536/cs5536.c 2008-02-07 16:17:21 UTC (rev 577) @@ -618,6 +618,7 @@ outl(0xDEADBEEF, 0xCFC); } #endif + printk(BIOS_SPEW, "cs5536: %s() Exit\n", __FUNCTION__); } /** @@ -631,9 +632,11 @@ printk(BIOS_SPEW, "cs5536: %s()\n", __FUNCTION__); pci_dev_enable_resources(dev); enable_childrens_resources(dev); + printk(BIOS_SPEW, "cs5536: %s() Exit\n", __FUNCTION__); } static struct device_operations southbridge_ops = { + .constructor = default_device_constructor, .phase3_scan = scan_static_bus, .phase4_read_resources = pci_dev_read_resources, .phase4_set_resources = pci_dev_set_resources, From rminnich at gmail.com Thu Feb 7 17:21:32 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 7 Feb 2008 08:21:32 -0800 Subject: [coreboot] coreboot summit april in denver Message-ID: <13426df10802070821x1c4339aex7c6816aa87d373e3@mail.gmail.com> We need to start a program. I am thinking I might do a section on "anatomy of the v3 port to LX". I wonder if any AMD folks could talk about issues relevant to AMD. FSF -- would be nice to from you. Anyone at VIA or SiS care to talk? Intel -- I know you're out there, we'd be happy to see you if you want to discuss your ideas. demos -- any cool hardware anyone wants to bring is fine. I will bring some. Can any Artec people show up? Thanks ron From rminnich at gmail.com Thu Feb 7 17:17:44 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 7 Feb 2008 08:17:44 -0800 Subject: [coreboot] FIRST LINUX BOOT: v3 on alix1c! In-Reply-To: <47AB27B7.8030406@gmx.net> References: <13426df10802062252h537d1efdg99f48f1cad448296@mail.gmail.com> <20080207070845.32578.qmail@stuge.se> <13426df10802062346g3d00c2dfu1898100cd122efc4@mail.gmail.com> <47AB27B7.8030406@gmx.net> Message-ID: <13426df10802070817m26a30571g8e60012867d503b6@mail.gmail.com> Committed revision 577. With a more verbose note. thanks ron From myles at pel.cs.byu.edu Thu Feb 7 17:26:32 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Thu, 7 Feb 2008 09:26:32 -0700 Subject: [coreboot] v3 defconfig Message-ID: <2831fecf0802070826r6444dd01n976f3dfbccd12135@mail.gmail.com> This patch adds support for make defconfig in v3. Those that port v3 to a board should add a defconfig in mainboard/vendor/board/defconfig. I think that the defconfig should: 1. Use the ROM size that comes with the board 2. Enable compression 3. Not include a payload This will make it easy for buildrom or anyone who wants to build it manually to use lar to add their payloads. It also allows buildrom to keep the configs in the coreboot tree. The patch also adds mainboard/emulation/qemu-x86/defconfig Should we change v2 to use the same naming? It would be nice not to have one be qemu-i386 and one qemu-x86. Myles Signed-off-by: Myles Watson -------------- next part -------------- A non-text attachment was scrubbed... Name: defconfig.patch Type: text/x-patch Size: 3866 bytes Desc: not available URL: From Marc.Jones at AMD.com Thu Feb 7 17:37:54 2008 From: Marc.Jones at AMD.com (Marc Jones) Date: Thu, 07 Feb 2008 09:37:54 -0700 Subject: [coreboot] coreboot summit april in denver In-Reply-To: <13426df10802070821x1c4339aex7c6816aa87d373e3@mail.gmail.com> References: <13426df10802070821x1c4339aex7c6816aa87d373e3@mail.gmail.com> Message-ID: <47AB33E2.9060908@AMD.com> ron minnich wrote: > We need to start a program. I am thinking I might do a section on > "anatomy of the v3 port to LX". > > I wonder if any AMD folks could talk about issues relevant to AMD. > > We would be happy to. Did you have something specific in mind? For the most part it will be the same issues that we have in v2 and that we covered at OLS last year. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From ward at gnu.org Thu Feb 7 17:43:20 2008 From: ward at gnu.org (Ward Vandewege) Date: Thu, 7 Feb 2008 11:43:20 -0500 Subject: [coreboot] v3 defconfig In-Reply-To: <2831fecf0802070826r6444dd01n976f3dfbccd12135@mail.gmail.com> References: <2831fecf0802070826r6444dd01n976f3dfbccd12135@mail.gmail.com> Message-ID: <20080207164320.GA7312@localdomain> On Thu, Feb 07, 2008 at 09:26:32AM -0700, Myles Watson wrote: > This patch adds support for make defconfig in v3. Those that port v3 > to a board should add a defconfig in mainboard/vendor/board/defconfig. > I think that the defconfig should: > > 1. Use the ROM size that comes with the board > 2. Enable compression > 3. Not include a payload > > This will make it easy for buildrom or anyone who wants to build it > manually to use lar to add their payloads. It also allows buildrom to > keep the configs in the coreboot tree. That sounds good. > The patch also adds mainboard/emulation/qemu-x86/defconfig > > Should we change v2 to use the same naming? It would be nice not to > have one be qemu-i386 and one qemu-x86. Yes, why not. > Signed-off-by: Myles Watson Acked-by: Ward Vandewege Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From svn at coreboot.org Thu Feb 7 17:50:45 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Thu, 7 Feb 2008 17:50:45 +0100 Subject: [coreboot] r578 - in coreboot-v3: . mainboard/emulation/qemu-x86 util/kconfig Message-ID: Author: myles Date: 2008-02-07 17:50:44 +0100 (Thu, 07 Feb 2008) New Revision: 578 Added: coreboot-v3/mainboard/emulation/qemu-x86/defconfig Modified: coreboot-v3/Makefile coreboot-v3/util/kconfig/confdata.c coreboot-v3/util/kconfig/symbol.c Log: This patch adds support for make defconfig in v3. Those that port v3 to a board should add a defconfig in mainboard/vendor/board/defconfig. I think that the defconfig should: 1. Use the ROM size that comes with the board 2. Enable compression 3. Not include a payload This will make it easy for buildrom or anyone who wants to build it manually to use lar to add their payloads. It also allows buildrom to keep the configs in the coreboot tree. The patch also adds mainboard/emulation/qemu-x86/defconfig Signed-off-by: Myles Watson Acked-by: Ward Vandewege Modified: coreboot-v3/Makefile =================================================================== --- coreboot-v3/Makefile 2008-02-07 16:17:21 UTC (rev 577) +++ coreboot-v3/Makefile 2008-02-07 16:50:44 UTC (rev 578) @@ -80,6 +80,7 @@ ARCH:=$(shell echo $(CONFIG_ARCH)) MAINBOARDDIR=$(shell echo $(CONFIG_MAINBOARD_NAME)) +export MAINBOARDDIR COREBOOTINCLUDE := -I$(src) -Iinclude \ -I$(src)/include \ Added: coreboot-v3/mainboard/emulation/qemu-x86/defconfig =================================================================== --- coreboot-v3/mainboard/emulation/qemu-x86/defconfig (rev 0) +++ coreboot-v3/mainboard/emulation/qemu-x86/defconfig 2008-02-07 16:50:44 UTC (rev 578) @@ -0,0 +1,88 @@ +# +# Automatically generated make config: don't edit +# coreboot version: 3.0.0 +# Wed Feb 6 13:55:31 2008 +# + +# +# General setup +# +# CONFIG_EXPERIMENTAL is not set +# CONFIG_EXPERT is not set +CONFIG_LOCALVERSION="" + +# +# Mainboard +# +# CONFIG_VENDOR_ADL is not set +# CONFIG_VENDOR_AMD is not set +# CONFIG_VENDOR_ARTECGROUP is not set +CONFIG_VENDOR_EMULATION=y +# CONFIG_VENDOR_PCENGINES is not set +CONFIG_MAINBOARD_NAME="emulation/qemu-x86" +CONFIG_MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID=0x15ad +CONFIG_MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID=0x1976 +CONFIG_BOARD_EMULATION_QEMU_X86=y +# CONFIG_COREBOOT_ROMSIZE_KB_128 is not set +# CONFIG_COREBOOT_ROMSIZE_KB_256 is not set +# CONFIG_COREBOOT_ROMSIZE_KB_512 is not set +CONFIG_COREBOOT_ROMSIZE_KB_1024=y +# CONFIG_COREBOOT_ROMSIZE_KB_2048 is not set +CONFIG_COREBOOT_ROMSIZE_KB=1024 +CONFIG_ARCH_X86=y +CONFIG_ARCH="x86" +CONFIG_CPU_I586=y +CONFIG_OPTION_TABLE=y + +# +# Compression +# +CONFIG_COMPRESSION_LZMA=y +# CONFIG_COMPRESSION_NRV2B is not set +CONFIG_DEFAULT_COMPRESSION_LZMA=y +# CONFIG_DEFAULT_COMPRESSION_NRV2B is not set +# CONFIG_DEFAULT_COMPRESSION_NONE is not set + +# +# Console +# +CONFIG_CONSOLE=y +CONFIG_CONSOLE_LOGLEVEL_8=y +# CONFIG_CONSOLE_LOGLEVEL_7 is not set +# CONFIG_CONSOLE_LOGLEVEL_6 is not set +# CONFIG_CONSOLE_LOGLEVEL_5 is not set +# CONFIG_CONSOLE_LOGLEVEL_4 is not set +# CONFIG_CONSOLE_LOGLEVEL_3 is not set +# CONFIG_CONSOLE_LOGLEVEL_2 is not set +# CONFIG_CONSOLE_LOGLEVEL_1 is not set +# CONFIG_CONSOLE_LOGLEVEL_0 is not set +CONFIG_DEFAULT_CONSOLE_LOGLEVEL=8 +CONFIG_CONSOLE_SERIAL=y +CONFIG_CONSOLE_SERIAL_COM1=y +# CONFIG_CONSOLE_SERIAL_COM2 is not set +CONFIG_CONSOLE_SERIAL_115200=y +# CONFIG_CONSOLE_SERIAL_57600 is not set +# CONFIG_CONSOLE_SERIAL_38400 is not set +# CONFIG_CONSOLE_SERIAL_19200 is not set +# CONFIG_CONSOLE_SERIAL_9600 is not set + +# +# Devices +# +CONFIG_PCI_OPTION_ROM_RUN=y +# CONFIG_PCI_OPTION_ROM_RUN_X86EMU is not set +CONFIG_PCI_OPTION_ROM_RUN_VM86=y +# CONFIG_PCI_OPTION_ROM_RUN_NONE is not set +# CONFIG_MULTIPLE_VGA_INIT is not set +# CONFIG_INITIALIZE_ONBOARD_VGA_FIRST is not set +CONFIG_NORTHBRIDGE_INTEL_I440BXEMULATION=y +CONFIG_SOUTHBRIDGE_INTEL_I82371EB=y +CONFIG_SUPERIO_WINBOND_W83627HF=y +CONFIG_NORTHBRIDGE_INTEL_I440BXEMULATION_RAMSIZE=32 + +# +# Payload +# +# CONFIG_PAYLOAD_PREPARSE_ELF is not set +# CONFIG_PAYLOAD_ELF is not set +CONFIG_PAYLOAD_NONE=y Modified: coreboot-v3/util/kconfig/confdata.c =================================================================== --- coreboot-v3/util/kconfig/confdata.c 2008-02-07 16:17:21 UTC (rev 577) +++ coreboot-v3/util/kconfig/confdata.c 2008-02-07 16:50:44 UTC (rev 578) @@ -22,7 +22,7 @@ const char conf_def_filename[] = ".config"; -const char conf_defname[] = "arch/$ARCH/defconfig"; +const char conf_defname[] = "mainboard/$MAINBOARDDIR/defconfig"; const char *conf_confnames[] = { ".config", Modified: coreboot-v3/util/kconfig/symbol.c =================================================================== --- coreboot-v3/util/kconfig/symbol.c 2008-02-07 16:17:21 UTC (rev 577) +++ coreboot-v3/util/kconfig/symbol.c 2008-02-07 16:50:44 UTC (rev 578) @@ -54,6 +54,13 @@ uname(&uts); + sym = sym_lookup("MAINBOARDDIR", 0); + sym->type = S_STRING; + sym->flags |= SYMBOL_AUTO; + p = getenv("MAINBOARDDIR"); + if (p) + sym_add_default(sym, p); + sym = sym_lookup("ARCH", 0); sym->type = S_STRING; sym->flags |= SYMBOL_AUTO; From myles at pel.cs.byu.edu Thu Feb 7 17:51:54 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Thu, 7 Feb 2008 09:51:54 -0700 Subject: [coreboot] v3 defconfig In-Reply-To: <20080207164320.GA7312@localdomain> References: <2831fecf0802070826r6444dd01n976f3dfbccd12135@mail.gmail.com> <20080207164320.GA7312@localdomain> Message-ID: <2831fecf0802070851p7687b137v774a2351d5ea4fe@mail.gmail.com> > > Signed-off-by: Myles Watson > > Acked-by: Ward Vandewege Thanks, Rev 578 Myles From myles at pel.cs.byu.edu Thu Feb 7 18:03:14 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Thu, 7 Feb 2008 10:03:14 -0700 Subject: [coreboot] [ward@gnu.org: Re: [LinuxBIOS] [PATCH] buildrom: addextract andbusybox-config, uclibc-config targets] In-Reply-To: <20080207165755.GA7459@localdomain> References: <20080207165755.GA7459@localdomain> Message-ID: <00c201c869ab$53b2ccd0$3222040a@chimp> > Hey Myles, > > Does this look good enough for an ack? I know you already ack'ed several > previous revisions of this patch, but it's probably best if I don't commit > this without a formal ack of the latest revision :) > > Thanks, > Ward. Sorry, since there wasn't a Signed-off-by: line in the last one I didn't think about it. Good work. Myles Acked-by: Myles Watson From rminnich at gmail.com Thu Feb 7 17:55:35 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 7 Feb 2008 08:55:35 -0800 Subject: [coreboot] Got a problem, which may fix the other problem :-) Message-ID: <13426df10802070855w64130723h887537b01d96680b@mail.gmail.com> Lar does not currently process bss quite right. I kind of blame ELF, but see what you think. Here is filo. These are program headers used in Execution (the 'E' in ELF): LOAD 0x0000c0 0x00100000 0x00100000 0x11430 0x36890 RWE 0x20 LOAD 0x011500 0x001368a0 0x001368a0 0x00048 0x00048 RW 0x20 Note the LOAD sections. Here is more of FILO. These are section headers used in Linking (the 'L' in ELF') [ 2] .text PROGBITS 00100080 000140 00e667 00 WAX 0 0 16 [ 3] .rodata PROGBITS 0010e6e8 00e7a8 002b73 00 A 0 0 4 [ 4] .eh_frame PROGBITS 0011125c 01131c 000070 00 A 0 0 4 [ 5] .data PROGBITS 001112e0 0113a0 000150 00 WA 0 0 32 [ 6] .bss NOBITS 00111440 0114f0 025450 00 WA 0 0 32 [ 7] .initctx PROGBITS 001368a0 011500 000048 00 WA 0 0 32 OK, where did the LOAD sections come from? The first is a combination of .text, .rodata, .eh_frame, and .data. .initctx is the second one. What's the FILO problem? Well: ide_probe: ide_probe drive #0 ide_probe: ctrl 1188128 base f9e8 base f9e8 is the IO base for the controller. f9eh? WHAT IS THAT? Well, it is a chunk of memory that is *supposed* to be zero! it's garbage. it's in the .bss area and lar does not initialize it or anything. Why? Well: [ 6] .bss NOBITS 00111440 0114f0 025450 00 WA 0 0 32 Note that there is NO program header (LOAD above) for this area of memory! There is only this program header! So the elf processor in LAR (which I grabbed from v2) is not processing that section. I don't think it should have to: it's a section header, not a program header, but this is an esoteric argument. So I need to modify LAR to create another payload segment for .bss, which is just a zero-filled thing. I will just look for a section header named .bss and use that. Now, this will be a zero-filled LAR entry but once compressed it will be nothing -- zero's compress nicely. But should we have a LAR type BSS for this type of usage? I am wondering. The BSS type would have a base address and size, and would be taken to mean "Zero this piece of ram". Comments? ron From rminnich at gmail.com Thu Feb 7 17:42:01 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 7 Feb 2008 08:42:01 -0800 Subject: [coreboot] coreboot summit april in denver In-Reply-To: <47AB33E2.9060908@AMD.com> References: <13426df10802070821x1c4339aex7c6816aa87d373e3@mail.gmail.com> <47AB33E2.9060908@AMD.com> Message-ID: <13426df10802070842o58a7ddeepc5e1f78fe1613150@mail.gmail.com> On Feb 7, 2008 8:37 AM, Marc Jones wrote: > We would be happy to. Did you have something specific in mind? For the > most part it will be the same issues that we have in v2 and that we > covered at OLS last year. that would be great. I wonder if you could put in a talk about the new platforms and how they will work in coreboot, that sort of thing. thanks ron From svn at coreboot.org Thu Feb 7 18:41:01 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Thu, 7 Feb 2008 18:41:01 +0100 Subject: [coreboot] r109 - in buildrom-devel: . config/payloads packages/busybox packages/coreboot-v2 packages/filo packages/kernel packages/lzma packages/mkelfimage packages/uclibc packages/unifdef Message-ID: Author: ward Date: 2008-02-07 18:41:01 +0100 (Thu, 07 Feb 2008) New Revision: 109 Modified: buildrom-devel/Makefile buildrom-devel/config/payloads/filo.conf buildrom-devel/config/payloads/kernel.conf buildrom-devel/config/payloads/lab.conf buildrom-devel/packages/busybox/busybox.mk buildrom-devel/packages/coreboot-v2/coreboot.inc buildrom-devel/packages/filo/filo.mk buildrom-devel/packages/kernel/kernel.inc buildrom-devel/packages/lzma/lzma.mk buildrom-devel/packages/mkelfimage/mkelfimage.mk buildrom-devel/packages/uclibc/uclibc.mk buildrom-devel/packages/unifdef/unifdef.mk Log: This patch adds extract targets, as well as some config targets: busybox-config, uclibc-config, kernel-config and filo-config. The extract targets will just extract the component(s) under the work subdirectory. The config targets will run a configure command for the component, and then copy the resulting custom config file to the conf directory for the package using a naming convention that indicates the payload, vendor, board and (for the kernel and uclibc) architecture. That config file will then be used to build the image when 'make' is issued, overriding the default buildrom config for that package/payload - but only if there is a match for payload, vendor and board (and for uclibc and the kernel, architecture). The config targets are somewhat smart: they will copy an existing custom config file back to the source directory so that doing a make something-config when a custom config file exists will have the effect of editing the custom config, rather than overwriting it. If a custom config file is used, buildrom will say so on stdout. Signed-off-by: Ward Vandewege Acked-by: Myles Watson Modified: buildrom-devel/Makefile =================================================================== --- buildrom-devel/Makefile 2008-02-07 15:54:34 UTC (rev 108) +++ buildrom-devel/Makefile 2008-02-07 17:41:01 UTC (rev 109) @@ -21,7 +21,7 @@ config-targets := 1 endif -ifneq ($(filter config %config,$(MAKECMDGOALS)),) +ifneq ($(filter textconfig oldconfig defconfig menuconfig,$(MAKECMDGOALS)),) config-targets := 1 dot-config := 0 endif @@ -60,6 +60,7 @@ PKG_clean=$(patsubst %, %-clean, $(PKGLIST)) PKG_distclean=$(patsubst %, %-distclean, $(PKGLIST)) +PKG_extract=$(patsubst %, %-extract, $(PKGLIST)) # This is the top level target - for v2, the final deliverable is built # by coreboot, for v3 it is built by us, so we have ifdef magic here @@ -78,6 +79,8 @@ payload: $(PAYLOAD_TARGET) +extract: $(PKG_extract) + clean: $(PKG_clean) @ rm -rf $(INITRD_DIR) $(OUTPUT_DIR) Modified: buildrom-devel/config/payloads/filo.conf =================================================================== --- buildrom-devel/config/payloads/filo.conf 2008-02-07 15:54:34 UTC (rev 108) +++ buildrom-devel/config/payloads/filo.conf 2008-02-07 17:41:01 UTC (rev 109) @@ -8,3 +8,6 @@ PAYLOAD_COMPRESSED=$(OUTPUT_DIR)/filo-payload.elf.lzma PAYLOAD-y=filo + +PAYLOAD=filo + Modified: buildrom-devel/config/payloads/kernel.conf =================================================================== --- buildrom-devel/config/payloads/kernel.conf 2008-02-07 15:54:34 UTC (rev 108) +++ buildrom-devel/config/payloads/kernel.conf 2008-02-07 17:41:01 UTC (rev 109) @@ -16,4 +16,6 @@ PAYLOAD_COMPRESSED=$(OUTPUT_DIR)/kernel-payload.elf.lzma PAYLOAD-y= kernel +PAYLOAD=kernel + HOSTTOOLS-y = mkelfimage Modified: buildrom-devel/config/payloads/lab.conf =================================================================== --- buildrom-devel/config/payloads/lab.conf 2008-02-07 15:54:34 UTC (rev 108) +++ buildrom-devel/config/payloads/lab.conf 2008-02-07 17:41:01 UTC (rev 109) @@ -30,4 +30,6 @@ PAYLOAD-$(CONFIG_BOOTMENU) += bootmenu PAYLOAD-$(CONFIG_OLPCFLASH) += olpcflash +PAYLOAD=lab + HOSTTOOLS-y = mkelfimage unifdef Modified: buildrom-devel/packages/busybox/busybox.mk =================================================================== --- buildrom-devel/packages/busybox/busybox.mk 2008-02-07 15:54:34 UTC (rev 108) +++ buildrom-devel/packages/busybox/busybox.mk 2008-02-07 17:41:01 UTC (rev 109) @@ -17,11 +17,18 @@ BUSYBOX_CONFIG ?= defconfig +ifeq ($(findstring defconfig,$(BUSYBOX_CONFIG)),defconfig) +ifeq ($(shell if [ -f $(PACKAGE_DIR)/busybox/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + BUSYBOX_CONFIG = customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) +endif +endif + $(SOURCE_DIR)/$(BUSYBOX_SOURCE): + @ echo "Downloading busybox..." @ mkdir -p $(SOURCE_DIR) @ wget -P $(SOURCE_DIR) $(BUSYBOX_URL)/$(BUSYBOX_SOURCE) -$(BUSYBOX_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(BUSYBOX_SOURCE) +$(BUSYBOX_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(BUSYBOX_SOURCE) | $(BUSYBOX_STAMP_DIR) $(BUSYBOX_DIR) @ echo "Unpacking busybox..." @ tar -C $(BUSYBOX_DIR) -jxf $(SOURCE_DIR)/$(BUSYBOX_SOURCE) @ touch $@ @@ -32,24 +39,27 @@ @ touch $@ $(BUSYBOX_SRC_DIR)/.config: $(BUSYBOX_STAMP_DIR)/.patched - @ cp $(PACKAGE_DIR)/busybox/conf/$(BUSYBOX_CONFIG) $@ + @ cp -f $(PACKAGE_DIR)/busybox/conf/$(BUSYBOX_CONFIG) $@ -$(BUSYBOX_SRC_DIR)/busybox: $(BUSYBOX_SRC_DIR)/.config +$(BUSYBOX_SRC_DIR)/busybox: $(BUSYBOX_SRC_DIR)/.config | $(BUSYBOX_LOG_DIR) @ echo "Building busybox..." +ifneq ($(findstring defconfig,$(BUSYBOX_CONFIG)),defconfig) + @ echo "Using custom config $(PACKAGE_DIR)/busybox/conf/$(BUSYBOX_CONFIG)" +endif @ ( unset CFLAGS; unset LDFLAGS; \ export EXTRA_CFLAGS="$(CFLAGS)";\ export LDFLAGS="$(LDFLAGS_orig)";\ $(MAKE) -C $(BUSYBOX_SRC_DIR) VERBOSE=y \ LIBRARIES="$(LIBS)" all > $(BUSYBOX_BUILD_LOG) 2>&1) -$(INITRD_DIR)/bin/busybox: $(BUSYBOX_SRC_DIR)/busybox +$(INITRD_DIR)/bin/busybox: $(BUSYBOX_SRC_DIR)/busybox | $(BUSYBOX_LOG_DIR) @ $(MAKE) -C $(BUSYBOX_SRC_DIR) \ PREFIX=$(INITRD_DIR) install > $(BUSYBOX_INSTALL_LOG) 2>&1 -$(BUSYBOX_STAMP_DIR) $(BUSYBOX_LOG_DIR): +$(BUSYBOX_STAMP_DIR) $(BUSYBOX_LOG_DIR) $(BUSYBOX_DIR): @ mkdir -p $@ -busybox: $(BUSYBOX_STAMP_DIR) $(BUSYBOX_LOG_DIR) $(INITRD_DIR)/bin/busybox +busybox: $(INITRD_DIR)/bin/busybox busybox-clean: @ echo "Cleaning busybox..." @@ -62,3 +72,27 @@ @ echo "Package: busybox" @ echo "Source: $(BUSYBOX_URL)/$(BUSYBOX_SOURCE)" @ echo "" + +busybox-extract: $(BUSYBOX_STAMP_DIR)/.patched + +busybox-config: $(BUSYBOX_STAMP_DIR)/.patched +ifeq ($(shell if [ -f $(PACKAGE_DIR)/busybox/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + @ cp -f $(PACKAGE_DIR)/busybox/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) $(BUSYBOX_SRC_DIR)/.config +endif +ifeq (busybox,$(filter busybox,$(PAYLOAD-y))) + @ echo "Configure busybox..." + @ $(MAKE) -C $(BUSYBOX_SRC_DIR) menuconfig + @ echo +ifeq ($(shell if [ -f $(PACKAGE_DIR)/busybox/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + @ echo "Found an existing custom configuration file:" + @ echo " $(PACKAGE_DIR)/busybox/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)" + @ echo "I've copied it back to the source directory for modification." + @ echo "Remove the above file and re-run this command if you want to create a new custom configuration from scratch for this payload/board." + @ echo +endif + @ cp -f $(BUSYBOX_SRC_DIR)/.config $(PACKAGE_DIR)/busybox/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) + @ echo "Your custom busybox config file has been saved as $(PACKAGE_DIR)/busybox/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)." + @ echo +else + @ echo "Your payload does not require busybox." +endif Modified: buildrom-devel/packages/coreboot-v2/coreboot.inc =================================================================== --- buildrom-devel/packages/coreboot-v2/coreboot.inc 2008-02-07 15:54:34 UTC (rev 108) +++ buildrom-devel/packages/coreboot-v2/coreboot.inc 2008-02-07 17:41:01 UTC (rev 109) @@ -58,8 +58,8 @@ $(CBV2_PAYLOAD_TARGET): $(PAYLOAD_TARGET) @ cp $< $@ -$(CBV2_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(CBV2_TARBALL) - @ echo "Unpacking coreboot..." +$(CBV2_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(CBV2_TARBALL) | $(CBV2_STAMP_DIR) $(CBV2_LOG_DIR) + @ echo "Unpacking coreboot ($(CBV2_TARBALL))..." @ tar -C $(CBV2_DIR) -zxf $(SOURCE_DIR)/$(CBV2_TARBALL) @ touch $@ @@ -98,3 +98,6 @@ fi @ rm -rf $(CBV2_DIR)/* + +coreboot-extract: $(CBV2_STAMP_DIR)/.patched + Modified: buildrom-devel/packages/filo/filo.mk =================================================================== --- buildrom-devel/packages/filo/filo.mk 2008-02-07 15:54:34 UTC (rev 108) +++ buildrom-devel/packages/filo/filo.mk 2008-02-07 17:41:01 UTC (rev 109) @@ -25,13 +25,17 @@ FILO_TARBALL=filo-svn-$(FILO_TAG).tar.gz +ifeq ($(shell if [ -f $(PACKAGE_DIR)/filo/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + FILO_CONFIG = customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) +endif + $(SOURCE_DIR)/$(FILO_TARBALL): @ mkdir -p $(SOURCE_DIR)/filo @ $(BIN_DIR)/fetchsvn.sh $(FILO_URL) $(SOURCE_DIR)/filo \ $(FILO_TAG) $(SOURCE_DIR)/$(FILO_TARBALL) \ > $(FILO_FETCH_LOG) 2>&1 -$(FILO_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(FILO_TARBALL) +$(FILO_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(FILO_TARBALL) | $(FILO_STAMP_DIR) $(FILO_DIR) @ echo "Unpacking filo..." @ tar -C $(FILO_DIR) -zxf $(SOURCE_DIR)/$(FILO_TARBALL) @ touch $@ @@ -48,6 +52,9 @@ $(FILO_SRC_DIR)/filo.elf: $(FILO_STAMP_DIR)/.configured @ echo "Building filo..." +ifeq ($(findstring customconfig,$(FILO_CONFIG)),customconfig) + @ echo "Using custom config $(PACKAGE_DIR)/filo/conf/$(FILO_CONFIG)" +endif @ make -C $(FILO_SRC_DIR) filo.elf > $(FILO_BUILD_LOG) 2>&1 $(FILO_STAMP_DIR) $(FILO_LOG_DIR): @@ -64,3 +71,24 @@ filo-distclean: @ rm -rf $(FILO_DIR)/* +filo-extract: $(FILO_STAMP_DIR)/.patched + +filo-config: $(FILO_STAMP_DIR)/.unpacked +ifeq ($(shell if [ -f $(PACKAGE_DIR)/filo/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + @ echo + @ echo "Found an existing custom configuration file:" + @ echo " $(PACKAGE_DIR)/filo/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)" + @ echo "Please modify this file by hand." + @ echo "Remove the above file and re-run this command if you want to create a new custom configuration from scratch for this payload/board." + @ echo +else + @ echo "Configure filo..." + @ $(MAKE) -C $(FILO_SRC_DIR) config + @ cp -f $(FILO_SRC_DIR)/Config $(PACKAGE_DIR)/filo/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) + @ echo + @ echo "Your custom FILO config has been saved as " + @ echo " $(PACKAGE_DIR)/filo/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)" + @ echo "Please edit it to your liking." + @ echo +endif + Modified: buildrom-devel/packages/kernel/kernel.inc =================================================================== --- buildrom-devel/packages/kernel/kernel.inc 2008-02-07 15:54:34 UTC (rev 108) +++ buildrom-devel/packages/kernel/kernel.inc 2008-02-07 17:41:01 UTC (rev 109) @@ -15,6 +15,12 @@ KERNEL_BUILD_ARCH=i386 endif +ifeq ($(findstring defconfig,$(KERNEL_CONFIG)),defconfig) +ifeq ($(shell if [ -f $(PACKAGE_DIR)/kernel/conf/customconfig--$(PAYLOAD)--$(KERNEL_BUILD_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + KERNEL_CONFIG = $(PACKAGE_DIR)/kernel/conf/customconfig--$(PAYLOAD)--$(KERNEL_BUILD_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) +endif +endif + ifeq ($(CONFIG_VERBOSE),y) KERNEL_FETCH_LOG=/dev/stdout KERNEL_BUILD_LOG=/dev/stdout @@ -25,7 +31,7 @@ KERNEL_INSTALL_LOG=$(KERNEL_LOG_DIR)/install.log endif -$(KERNEL_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(KERNEL_SOURCE) +$(KERNEL_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(KERNEL_SOURCE) | $(KERNEL_STAMP_DIR) @ mkdir -p $(KERNEL_DIR) @ echo "Unpacking kernel..." @ tar -C $(KERNEL_DIR) -jxf $(SOURCE_DIR)/$(KERNEL_SOURCE) @@ -50,8 +56,11 @@ $(KERNEL_SRC_DIR)/.config: $(KERNEL_STAMP_DIR)/.patched @ cat $(KERNEL_CONFIG) | sed -e s:^CONFIG_LOCALVERSION=.*:CONFIG_LOCALVERSION=\"$(ROM_VERSION)\": > $(KERNEL_SRC_DIR)/.config -$(KERNEL_BZIMAGE): $(KERNEL_SRC_DIR)/.config +$(KERNEL_BZIMAGE): $(KERNEL_SRC_DIR)/.config | $(KERNEL_LOG_DIR) @ echo "Building kernel..." +ifneq ($(findstring defconfig,$(KERNEL_CONFIG)),defconfig) + @ echo "Using custom kernel config $(KERNEL_CONFIG)" +endif @ $(MAKE) $(PARALLEL_MAKE) -C $(KERNEL_SRC_DIR) ARCH=$(KERNEL_BUILD_ARCH) \ KERNEL_CC="$(CC)" KERNEL_LD="$(LD)" > $(KERNEL_BUILD_LOG) 2>&1 @@ -63,7 +72,7 @@ @ install -d $(OUTPUT_DIR) @ install -m 0644 $(KERNEL_SRC_DIR)/vmlinux $@ -$(KERNEL_STAMP_DIR)/.headers: $(KERNEL_SRC_DIR)/.config $(STAGING_DIR)/host/bin/unifdef +$(KERNEL_STAMP_DIR)/.headers: $(KERNEL_SRC_DIR)/.config $(STAGING_DIR)/host/bin/unifdef | $(KERNEL_LOG_DIR) @ echo "Installing kernel headers..." @( export PATH=$(PATH):$(STAGING_DIR)/host/bin; \ $(MAKE) -C $(KERNEL_SRC_DIR) ARCH=$(KERNEL_BUILD_ARCH) \ @@ -73,7 +82,7 @@ $(KERNEL_STAMP_DIR) $(KERNEL_LOG_DIR): @ mkdir -p $@ -generic-kernel: $(KERNEL_STAMP_DIR) $(KERNEL_LOG_DIR) $(OUTPUT_DIR)/bzImage $(OUTPUT_DIR)/vmlinux $(KERNEL_STAMP_DIR)/.headers +generic-kernel: $(OUTPUT_DIR)/bzImage $(OUTPUT_DIR)/vmlinux $(KERNEL_STAMP_DIR)/.headers generic-kernel-clean: @ echo "Cleaning kernel..." @@ -83,3 +92,27 @@ generic-kernel-distclean: @ rm -rf $(KERNEL_DIR) + +kernel-extract: $(KERNEL_STAMP_DIR)/.patched + +kernel-config: $(KERNEL_STAMP_DIR)/.patched +ifeq ($(shell if [ -f $(PACKAGE_DIR)/kernel/conf/customconfig--$(PAYLOAD)--$(KERNEL_BUILD_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + @ cp -f $(PACKAGE_DIR)/kernel/conf/customconfig--$(PAYLOAD)--$(KERNEL_BUILD_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) $(KERNEL_SRC_DIR)/.config +endif +ifeq (kernel,$(filter kernel,$(PAYLOAD-y))) + @ echo "Configure kernel..." + @ $(MAKE) -C $(KERNEL_SRC_DIR) ARCH=$(KERNEL_BUILD_ARCH) menuconfig + @ echo +ifeq ($(shell if [ -f $(PACKAGE_DIR)/kernel/conf/customconfig--$(PAYLOAD)--$(KERNEL_BUILD_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + @ echo "Found an existing custom configuration file:" + @ echo " $(PACKAGE_DIR)/kernel/conf/customconfig--$(PAYLOAD)--$(KERNEL_BUILD_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)" + @ echo "I've copied it back to the source directory for modification." + @ echo "Remove the above file and re-run this command if you want to create a new custom configuration from scratch for this payload/board." + @ echo +endif + @ cp -f $(KERNEL_SRC_DIR)/.config $(PACKAGE_DIR)/kernel/conf/customconfig--$(PAYLOAD)--$(KERNEL_BUILD_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) + @ echo "Your custom kernel config file has been saved as $(PACKAGE_DIR)/kernel/conf/customconfig--$(PAYLOAD)--$(KERNEL_BUILD_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)." + @ echo +else + @ echo "Your payload does not require a kernel." +endif Modified: buildrom-devel/packages/lzma/lzma.mk =================================================================== --- buildrom-devel/packages/lzma/lzma.mk 2008-02-07 15:54:34 UTC (rev 108) +++ buildrom-devel/packages/lzma/lzma.mk 2008-02-07 17:41:01 UTC (rev 109) @@ -17,7 +17,7 @@ @ mkdir -p $(SOURCE_DIR) @ wget -P $(SOURCE_DIR) $(LZMA_URL)/$(LZMA_SOURCE) -$(LZMA_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(LZMA_SOURCE) +$(LZMA_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(LZMA_SOURCE) | $(LZMA_STAMP_DIR) @ mkdir -p $(LZMA_SRC_DIR) @ tar -C $(LZMA_SRC_DIR) -jxf $(SOURCE_DIR)/$(LZMA_SOURCE) @ touch $@ @@ -44,3 +44,6 @@ lzma-distclean: @ rm -rf $(LZMA_DIR)/* + +lzma-extract: $(LZMA_STAMP_DIR)/.unpacked + Modified: buildrom-devel/packages/mkelfimage/mkelfimage.mk =================================================================== --- buildrom-devel/packages/mkelfimage/mkelfimage.mk 2008-02-07 15:54:34 UTC (rev 108) +++ buildrom-devel/packages/mkelfimage/mkelfimage.mk 2008-02-07 17:41:01 UTC (rev 109) @@ -15,11 +15,14 @@ MKELFIMAGE_CONFIG_LOG=$(MKELFIMAGE_LOG_DIR)/config.log endif +$(MKELFIMAGE_STAMP_DIR) $(MKELFIMAGE_LOG_DIR): + @ mkdir -p $@ + $(SOURCE_DIR)/$(MKELFIMAGE_SOURCE): @ mkdir -p $(SOURCE_DIR) @ wget -P $(SOURCE_DIR) $(MKELFIMAGE_URL)/$(MKELFIMAGE_SOURCE) -$(MKELFIMAGE_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(MKELFIMAGE_SOURCE) +$(MKELFIMAGE_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(MKELFIMAGE_SOURCE) | $(MKELFIMAGE_STAMP_DIR) $(MKELFIMAGE_LOG_DIR) @ echo "Unpacking mkelfimage..." @ tar -C $(MKELFIMAGE_DIR) -zxf $(SOURCE_DIR)/$(MKELFIMAGE_SOURCE) @ touch $@ @@ -45,11 +48,8 @@ @ install -d $(STAGING_DIR)/sbin @ install -m 0755 $< $@ -$(MKELFIMAGE_STAMP_DIR) $(MKELFIMAGE_LOG_DIR): - @ mkdir -p $@ +mkelfimage: $(STAGING_DIR)/sbin/mkelfImage -mkelfimage: $(MKELFIMAGE_STAMP_DIR) $(MKELFIMAGE_LOG_DIR) $(STAGING_DIR)/sbin/mkelfImage - mkelfimage-clean: $(MAKE) -C $(MKELFIMAGE_SRC_DIR) clean @@ -60,3 +60,6 @@ echo "Package: mkelfimage" echo "Source: $(MKELFIMAGE_URL)/$(MKELFIMAGE_SOURCE)" echo "" + +mkelfimage-extract: $(MKELFIMAGE_STAMP_DIR)/.patched + Modified: buildrom-devel/packages/uclibc/uclibc.mk =================================================================== --- buildrom-devel/packages/uclibc/uclibc.mk 2008-02-07 15:54:34 UTC (rev 108) +++ buildrom-devel/packages/uclibc/uclibc.mk 2008-02-07 17:41:01 UTC (rev 109) @@ -9,6 +9,12 @@ UCLIBC_CONFIG ?= defconfig endif +ifeq ($(findstring defconfig,$(UCLIBC_CONFIG)),defconfig) +ifeq ($(shell if [ -f $(PACKAGE_DIR)/uclibc/conf/customconfig--$(PAYLOAD)--$(UCLIBC_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + UCLIBC_CONFIG = customconfig--$(PAYLOAD)--$(UCLIBC_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) +endif +endif + UCLIBC_URL=http://www.uclibc.org/downloads UCLIBC_SOURCE=uClibc-$(UCLIBC_VER).tar.bz2 UCLIBC_DIR=$(BUILD_DIR)/uclibc @@ -25,10 +31,11 @@ endif $(SOURCE_DIR)/$(UCLIBC_SOURCE): + @ echo "Downloading uclibc..." @ mkdir -p $(SOURCE_DIR) @ wget -P $(SOURCE_DIR) $(UCLIBC_URL)/$(UCLIBC_SOURCE) -$(UCLIBC_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(UCLIBC_SOURCE) +$(UCLIBC_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(UCLIBC_SOURCE) | $(UCLIBC_STAMP_DIR) $(UCLIBC_DIR) @ echo "Unpacking uclibc..." @ tar -C $(UCLIBC_DIR) -jxf $(SOURCE_DIR)/$(UCLIBC_SOURCE) @ touch $@ @@ -38,6 +45,9 @@ $(UCLIBC_SRC_DIR)/lib/libc.a: $(UCLIBC_SRC_DIR)/.config @ echo "Building uclibc..." +ifneq ($(findstring defconfig,$(UCLIBC_CONFIG)),defconfig) + @ echo "Using custom config $(PACKAGE_DIR)/uclibc/conf/$(UCLIBC_CONFIG)" +endif @ ( unset CFLAGS; unset LDFLAGS; \ $(MAKE) $(PARALLEL_MAKE) -C $(UCLIBC_SRC_DIR) TARGET_ARCH="$(UCLIBC_ARCH)" \ CC="$(CC) $(CROSS_CFLAGS)" LD="$(LD) $(CROSS_LDFLAGS)" \ @@ -61,7 +71,7 @@ @ install -m 755 -d $(STAGING_DIR)/bin @ install -m 755 $< $@ -$(UCLIBC_STAMP_DIR) $(UCLIBC_LOG_DIR): +$(UCLIBC_STAMP_DIR) $(UCLIBC_LOG_DIR) $(UCLIBC_DIR): @ mkdir -p $@ uclibc: $(UCLIBC_STAMP_DIR) $(UCLIBC_LOG_DIR) $(STAGING_DIR)/lib/libc.a @@ -77,3 +87,27 @@ @ echo "Package: uclibc" @ echo "Source: $(UCLIBC_URL)/$(UCLIBC_SOURCE)" @ echo "" + +uclibc-extract: $(UCLIBC_STAMP_DIR)/.unpacked + +uclibc-config: $(UCLIBC_STAMP_DIR)/.unpacked +ifeq ($(shell if [ -f $(PACKAGE_DIR)/uclibc/conf/customconfig--$(PAYLOAD)--$(UCLIBC_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + @ cp -f $(PACKAGE_DIR)/uclibc/conf/customconfig--$(PAYLOAD)--$(UCLIBC_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) $(UCLIBC_SRC_DIR)/.config +endif +ifeq (uclibc,$(filter uclibc,$(PAYLOAD-y))) + @ echo "Configure uclibc..." + @ $(MAKE) -C $(UCLIBC_SRC_DIR) TARGET_ARCH="$(UCLIBC_ARCH)" menuconfig + @ echo +ifeq ($(shell if [ -f $(PACKAGE_DIR)/uclibc/conf/customconfig--$(PAYLOAD)--$(UCLIBC_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + @ echo "Found an existing custom configuration file:" + @ echo " $(PACKAGE_DIR)/uclibc/conf/customconfig--$(PAYLOAD)--$(UCLIBC_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)" + @ echo "I've copied it back to the source directory for modification." + @ echo "Remove the above file and re-run this command if you want to create a new custom configuration from scratch for this payload/board." + @ echo +endif + @ cp -f $(UCLIBC_SRC_DIR)/.config $(PACKAGE_DIR)/uclibc/conf/customconfig--$(PAYLOAD)--$(UCLIBC_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) + @ echo "Your custom uclibc config file has been saved as $(PACKAGE_DIR)/uclibc/conf/customconfig--$(PAYLOAD)--$(UCLIBC_ARCH)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)." + @ echo +else + @ echo "Your payload does not require uclibc." +endif Modified: buildrom-devel/packages/unifdef/unifdef.mk =================================================================== --- buildrom-devel/packages/unifdef/unifdef.mk 2008-02-07 15:54:34 UTC (rev 108) +++ buildrom-devel/packages/unifdef/unifdef.mk 2008-02-07 17:41:01 UTC (rev 109) @@ -17,7 +17,7 @@ @ mkdir -p $(SOURCE_DIR) @ wget -P $(SOURCE_DIR) $(UNIFDEF_URL)/$(UNIFDEF_SOURCE) -$(UNIFDEF_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(UNIFDEF_SOURCE) +$(UNIFDEF_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(UNIFDEF_SOURCE) | $(UNIFDEF_STAMP_DIR) @ tar -C $(UNIFDEF_DIR) -zxf $(SOURCE_DIR)/$(UNIFDEF_SOURCE) @ rm -f $(UNIFDEF_SRC_DIR)/unifdef @ rm -f $(UNIFDEF_SRC_DIR)/unifdef.o @@ -49,3 +49,5 @@ echo "" .PHONY: unifdef + +unifdef-extract: $(UNIFDEF_STAMP_DIR)/.unpacked From ward at gnu.org Thu Feb 7 18:41:41 2008 From: ward at gnu.org (Ward Vandewege) Date: Thu, 7 Feb 2008 12:41:41 -0500 Subject: [coreboot] [ward@gnu.org: Re: [LinuxBIOS] [PATCH] buildrom: addextract andbusybox-config, uclibc-config targets] In-Reply-To: <00c201c869ab$53b2ccd0$3222040a@chimp> References: <20080207165755.GA7459@localdomain> <00c201c869ab$53b2ccd0$3222040a@chimp> Message-ID: <20080207174141.GA7820@localdomain> On Thu, Feb 07, 2008 at 10:03:14AM -0700, Myles Watson wrote: > > Does this look good enough for an ack? I know you already ack'ed several > > previous revisions of this patch, but it's probably best if I don't commit > > this without a formal ack of the latest revision :) > > > > Thanks, > > Ward. > > Sorry, since there wasn't a Signed-off-by: line in the last one I didn't > think about it. Good work. > > Acked-by: Myles Watson Thanks, r109. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From Marc.Karasek at Sun.COM Thu Feb 7 18:45:20 2008 From: Marc.Karasek at Sun.COM (Marc Karasek) Date: Thu, 07 Feb 2008 12:45:20 -0500 Subject: [coreboot] Run PCI rom before PCI bus scan?? In-Reply-To: <20080206172332.21955.qmail@stuge.se> References: <20080202203430.1p2at6gtc0skw0so@www.smittys.pointclark.net> <20080203183738.GA4289@coresystems.de> <20080203144443.q9r9b16s00wgk8k0@www.smittys.pointclark.net> <47A62410.90805@gmail.com> <20080203181552.tybs70ow5c4osoo4@www.smittys.pointclark.net> <20080204074936.4q1bevm7ksggowsk@www.smittys.pointclark.net> <47A75095.3070109@assembler.cz> <20080205105139.rhwr4w0eg0gg0wws@www.smittys.pointclark.net> <20080205164448.26302.qmail@stuge.se> <20080206172332.21955.qmail@stuge.se> Message-ID: <47AB43B0.6070901@sun.com> Let me add me two cents.. I have dealt with the Intel MACs in the past so let me dreg up some memorries... From what I recall, you had a serial eeprom on the board that contained the init for the chip. This was the 82545GM. The eeprom image was protected by a CRC and if the CRC failed it would not load the image. The device would also not be visible on the PCI Bus unless the eeprom was loaded. I have attached the 82545 eeprom spec sheet (freely avail from Intel) maybe this will give you some insight. Intel has a program to read/update the paramters. I never used it, mainly because I was on an embedded system running MIPS-Linux and they would only provide a x86 binary, no src code. It took me a couple of iterations to get the eeprom right. Maybe you can get the utility from Intel and dump the eeprom. What I do not understand is why you would be having problems with coreboot. the only thing I can guess is the default eeprom is putting the MAC into a state that the BIOS must take it out of (maybe WoL). Did you say you have the spec sheet for the part and it talks about the eeprom? /********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek at sun.com ph:770.360.6415 *********************/ Peter Stuge wrote: > On Tue, Feb 05, 2008 at 02:49:52PM -0500, Corey Osgood wrote: > >> "In the LAN controller the D0 state is partitioned into two substates >> >> and >> >> "The integrated LAN controller will be disabled if no Platform LAN >> Connect component is detected (See Section 5.2.1.3)." >> >> >> Any help? >> > > The first one isn't that interesting since it also implies that PCI > config regs are actually available. > > The second one, or rather section 5.2.1.3, could be interesting if > "Platform LAN Connect component" is usually found in the BIOS. > > > //Peter > > -------------- next part -------------- A non-text attachment was scrubbed... Name: ap470.pdf Type: application/pdf Size: 190134 bytes Desc: not available URL: From corey.osgood at gmail.com Thu Feb 7 20:21:43 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Thu, 7 Feb 2008 14:21:43 -0500 Subject: [coreboot] Run PCI rom before PCI bus scan?? In-Reply-To: <47AB43B0.6070901@sun.com> References: <20080202203430.1p2at6gtc0skw0so@www.smittys.pointclark.net> <47A62410.90805@gmail.com> <20080203181552.tybs70ow5c4osoo4@www.smittys.pointclark.net> <20080204074936.4q1bevm7ksggowsk@www.smittys.pointclark.net> <47A75095.3070109@assembler.cz> <20080205105139.rhwr4w0eg0gg0wws@www.smittys.pointclark.net> <20080205164448.26302.qmail@stuge.se> <20080206172332.21955.qmail@stuge.se> <47AB43B0.6070901@sun.com> Message-ID: On Feb 7, 2008 12:45 PM, Marc Karasek wrote: > Let me add me two cents.. > > I have dealt with the Intel MACs in the past so let me dreg up some > memorries... > > From what I recall, you had a serial eeprom on the board that > contained the init for the chip. This was the 82545GM. Hmm, no intel eeprom, but I do see a chip marked "atmel532", which google says is a serial eeprom, less than half an inch from the southbridge. Possible winner? -Corey > The eeprom image was protected by a CRC and if the CRC failed it would > not load the image. The device would also not be visible on the PCI Bus > unless the eeprom was loaded. I have attached the 82545 eeprom spec > sheet (freely avail from Intel) maybe this will give you some insight. > > Intel has a program to read/update the paramters. I never used it, > mainly because I was on an embedded system running MIPS-Linux and they > would only provide a x86 binary, no src code. It took me a couple of > iterations to get the eeprom right. Maybe you can get the utility from > Intel and dump the eeprom. > > What I do not understand is why you would be having problems with > coreboot. the only thing I can guess is the default eeprom is putting > the MAC into a state that the BIOS must take it out of (maybe WoL). Did > you say you have the spec sheet for the part and it talks about the > eeprom? > > /********************* > Marc Karasek > MTS > Sun Microsystems > mailto:marc.karasek at sun.com > ph:770.360.6415 > *********************/ > > > > Peter Stuge wrote: > > On Tue, Feb 05, 2008 at 02:49:52PM -0500, Corey Osgood wrote: > > > >> "In the LAN controller the D0 state is partitioned into two substates > >> > >> and > >> > >> "The integrated LAN controller will be disabled if no Platform LAN > >> Connect component is detected (See Section 5.2.1.3)." > >> > >> > >> Any help? > >> > > > > The first one isn't that interesting since it also implies that PCI > > config regs are actually available. > > > > The second one, or rather section 5.2.1.3, could be interesting if > > "Platform LAN Connect component" is usually found in the BIOS. > > > > > > //Peter > > > > > > -- > coreboot mailing list > coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -------------- next part -------------- An HTML attachment was scrubbed... URL: From myles at pel.cs.byu.edu Thu Feb 7 20:29:11 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Thu, 7 Feb 2008 12:29:11 -0700 Subject: [coreboot] Coreboot-v2 qemu target rename Message-ID: <00d501c869bf$b7271140$3222040a@chimp> Coreboot-v3 calls the qemu board qemu-x86, but Coreboot-v2 calls it qemu-i386. I think that qemu-x86 should be the preferred name. Does anyone have any reservations about the switch to qemu-x86 in Coreboot-v2? Thanks, Myles From Marc.Jones at AMD.com Thu Feb 7 20:16:53 2008 From: Marc.Jones at AMD.com (Marc Jones) Date: Thu, 07 Feb 2008 12:16:53 -0700 Subject: [coreboot] v3 for alix: add ide support In-Reply-To: <13426df10802062215x194c285ajc7943a7b785341e0@mail.gmail.com> References: <13426df10802062215x194c285ajc7943a7b785341e0@mail.gmail.com> Message-ID: <47AB5925.4070205@AMD.com> ron minnich wrote: > This code now lets filo find IDE. > > but it locks up :-( > > oh well. attached. > > ron > I preferred the v2 way of doing this. If the AMD IDE device was found it got initialized. I think it needs a DTS and I think other southbridges with multiple PCI headers will need this too. Back to the 5536, You can have either NAND or IDE PCI header so the enable_ide flag is redundant. If there is a PCI IDE card all of it's memory and I/O will be set in the PCI BAR. They can't use the legacy range so there is no real reason to not init the AMD IDE. If you wanted to make the AMD IDE go away it would be better to remove it via unwanted_vpci. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From Marc.Jones at AMD.com Thu Feb 7 20:27:57 2008 From: Marc.Jones at AMD.com (Marc Jones) Date: Thu, 07 Feb 2008 12:27:57 -0700 Subject: [coreboot] FIRST LINUX BOOT: v3 on alix1c! In-Reply-To: <13426df10802062252h537d1efdg99f48f1cad448296@mail.gmail.com> References: <13426df10802062252h537d1efdg99f48f1cad448296@mail.gmail.com> Message-ID: <47AB5BBD.1040701@AMD.com> ron minnich wrote: > With this patch to FILO: > Index: i386/timer.c > =================================================================== > --- i386/timer.c (revision 35) > +++ i386/timer.c (working copy) > @@ -105,7 +105,7 @@ > return (end - start) * CLOCK_TICK_RATE / (1000*LATCH); > } > > -static unsigned long long cpu_khz; > +static unsigned long long cpu_khz = 500000; > void setup_timers(void) > { > if (!cpu_khz) { > > > I just booted linux. First v3 boot on real hardware. > > There are still problems. Linux is quite busy as revealed by a POST > card but we don't seem to get interrupts. Things are not wired > correctly. > > I am attaching the console log as I think this is pretty important for v3 :-) > > Wow, this was a long haul, but we are very close. Thanks to you all. > > > thanks > > ron > You need good settings for the southbridge in your platform dts. You should be able to copy these from v2. /* LPC IRQ polarity. Each bit is an IRQ 0-15. */ lpc_serirq_polarity = "0"; /* 0:continuous 1:quiet */ lpc_serirq_mode = "0"; /* GPIO(0-0x20) for INT D:C:B:A, 0xFF=none. See virtual PIC spec. */ enable_gpio_int_route = "0"; Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From myles at pel.cs.byu.edu Thu Feb 7 20:54:05 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Thu, 7 Feb 2008 12:54:05 -0700 Subject: [coreboot] Coreboot-v2 qemu target rename In-Reply-To: <00d501c869bf$b7271140$3222040a@chimp> References: <00d501c869bf$b7271140$3222040a@chimp> Message-ID: <2831fecf0802071154x31c837f4g4dbd629ab7fc3018@mail.gmail.com> On Feb 7, 2008 12:29 PM, Myles Watson wrote: > Coreboot-v3 calls the qemu board qemu-x86, but Coreboot-v2 calls it > qemu-i386. I think that qemu-x86 should be the preferred name. > > Does anyone have any reservations about the switch to qemu-x86 in > Coreboot-v2? I didn't think it would be so easy. Here is the patch, which will be followed by these svn commands: svn mv targets/emulation/qemu-i386/ targets/emulation/qemu-x86 svn mv --force targets/emulation/qemu-i386/ targets/emulation/qemu-x86 svn mv --force src/mainboard/emulation/qemu-i386/ src/mainboard/emulation/qemu-x86 svn mv --force src/cpu/emulation/qemu-i386/ src/cpu/emulation/qemu-x86 The patch for buildrom is also pretty simple. If no one has objections to this one I'll submit that one too. Myles Signed-off-by: Myles Watson -------------- next part -------------- A non-text attachment was scrubbed... Name: qemu-rename.patch Type: text/x-patch Size: 4918 bytes Desc: not available URL: From rminnich at gmail.com Thu Feb 7 21:06:53 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 7 Feb 2008 12:06:53 -0800 Subject: [coreboot] FIRST LINUX BOOT: v3 on alix1c! In-Reply-To: <47AB5BBD.1040701@AMD.com> References: <13426df10802062252h537d1efdg99f48f1cad448296@mail.gmail.com> <47AB5BBD.1040701@AMD.com> Message-ID: <13426df10802071206l6fc15000r711f865712dbe778@mail.gmail.com> On Feb 7, 2008 11:27 AM, Marc Jones wrote: > You need good settings for the southbridge in your platform dts. You > should be able to copy these from v2. > > /* LPC IRQ polarity. Each bit is an IRQ 0-15. */ > lpc_serirq_polarity = "0"; > > /* 0:continuous 1:quiet */ > lpc_serirq_mode = "0"; > > /* GPIO(0-0x20) for INT D:C:B:A, 0xFF=none. See virtual PIC spec. */ > enable_gpio_int_route = "0"; > Here are the current defaults (recall that the dts can set defaults) constructor = "cs5536_constructors"; pciid = "PCI_VENDOR_ID_AMD,PCI_DEVICE_ID_AMD_CS5536_ISA"; /* Interrupt enables for LPC bus. Each bit is an IRQ 0-15. */ lpc_serirq_enable = "0"; /* LPC IRQ polarity. Each bit is an IRQ 0-15. */ lpc_serirq_polarity = "0"; /* 0:continuous 1:quiet */ lpc_serirq_mode = "0"; /* GPIO(0-0x20) for INT D:C:B:A, 0xFF=none. See virtual PIC spec. */ enable_gpio_int_route = "0"; /* 0:IDE 1:FLASH, if you are using NAND flash instead of IDE drive. */ enable_ide_nand_flash = "0"; /* IDE: enable CS5536 IDE. There may be a different IDE controller on board */ enable_ide = "0"; /* Enable USB Port 4 (0:host 1:device). */ enable_USBP4_device = "0"; /* 0:off, xxxx:overcurrent setting, e.g. 0x3FEA. * See CS5536 - Data Book (pages 380-381). */ enable_USBP4_overcurrent = "0"; /* COM1 settings */ com1_enable = "0"; com1_address = "0x3f8"; com1_irq = "4"; /* COM2 settings */ com2_enable = "0"; com2_address = "0x2f8"; com2_irq = "3"; From rminnich at gmail.com Thu Feb 7 21:09:17 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 7 Feb 2008 12:09:17 -0800 Subject: [coreboot] v3 for alix: add ide support In-Reply-To: <47AB5925.4070205@AMD.com> References: <13426df10802062215x194c285ajc7943a7b785341e0@mail.gmail.com> <47AB5925.4070205@AMD.com> Message-ID: <13426df10802071209v53f2c127g235212888bb1e238@mail.gmail.com> On Feb 7, 2008 11:16 AM, Marc Jones wrote: > I preferred the v2 way of doing this. If the AMD IDE device was found it > got initialized. I think it needs a DTS and I think other southbridges > with multiple PCI headers will need this too. So it's more like the northbridge part as well. OK, I'll think on this. thanks ron From Marc.Jones at AMD.com Thu Feb 7 21:23:27 2008 From: Marc.Jones at AMD.com (Marc Jones) Date: Thu, 07 Feb 2008 13:23:27 -0700 Subject: [coreboot] FIRST LINUX BOOT: v3 on alix1c! In-Reply-To: <13426df10802071206l6fc15000r711f865712dbe778@mail.gmail.com> References: <13426df10802062252h537d1efdg99f48f1cad448296@mail.gmail.com> <47AB5BBD.1040701@AMD.com> <13426df10802071206l6fc15000r711f865712dbe778@mail.gmail.com> Message-ID: <47AB68BF.4060209@AMD.com> ron minnich wrote: > On Feb 7, 2008 11:27 AM, Marc Jones wrote: > > >> You need good settings for the southbridge in your platform dts. You >> should be able to copy these from v2. >> >> /* LPC IRQ polarity. Each bit is an IRQ 0-15. */ >> lpc_serirq_polarity = "0"; >> >> /* 0:continuous 1:quiet */ >> lpc_serirq_mode = "0"; >> >> /* GPIO(0-0x20) for INT D:C:B:A, 0xFF=none. See virtual PIC spec. */ >> enable_gpio_int_route = "0"; >> >> > > Here are the current defaults (recall that the dts can set defaults) > > constructor = "cs5536_constructors"; > pciid = "PCI_VENDOR_ID_AMD,PCI_DEVICE_ID_AMD_CS5536_ISA"; > > /* Interrupt enables for LPC bus. Each bit is an IRQ 0-15. */ > lpc_serirq_enable = "0"; > > /* LPC IRQ polarity. Each bit is an IRQ 0-15. */ > lpc_serirq_polarity = "0"; > > /* 0:continuous 1:quiet */ > lpc_serirq_mode = "0"; > > /* GPIO(0-0x20) for INT D:C:B:A, 0xFF=none. See virtual PIC spec. */ > enable_gpio_int_route = "0"; > > /* 0:IDE 1:FLASH, if you are using NAND flash instead of IDE drive. */ > enable_ide_nand_flash = "0"; > > /* IDE: enable CS5536 IDE. There may be a different IDE > controller on board */ > enable_ide = "0"; > > /* Enable USB Port 4 (0:host 1:device). */ > enable_USBP4_device = "0"; > > /* 0:off, xxxx:overcurrent setting, e.g. 0x3FEA. > * See CS5536 - Data Book (pages 380-381). > */ > enable_USBP4_overcurrent = "0"; > > /* COM1 settings */ > com1_enable = "0"; > com1_address = "0x3f8"; > com1_irq = "4"; > > /* COM2 settings */ > com2_enable = "0"; > com2_address = "0x2f8"; > com2_irq = "3"; > > Right, so the defaults of 0 would be bad. You need to match the v2 mainboard config.lb for your v3 mainboard dts. for the alixc1 it should be something like this. southbridge { /config/("southbridge/amd/cs5536/dts"); pcipath = "0xf,0"; enabled; enable_ide = "1"; lpc_serirq_enable = "0x000010da"; /* Interrupt enables for LPC bus. Each bit is an IRQ 0-15. */ lpc_serirq_polarity = "0x0000EF25"; /* LPC IRQ polarity. Each bit is an IRQ 0-15. */ lpc_serirq_mode = "1"; /* 0:continuous 1:quiet */ enable_gpio_int_route = "0x0D0C0700"; /* GPIO(0-0x20) for INT D:C:B:A, 0xFF=none. See virtual PIC spec. */ }; Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From stepan at coresystems.de Thu Feb 7 21:28:27 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 7 Feb 2008 21:28:27 +0100 Subject: [coreboot] FIRST LINUX BOOT: v3 on alix1c! In-Reply-To: <13426df10802062346g3d00c2dfu1898100cd122efc4@mail.gmail.com> References: <13426df10802062252h537d1efdg99f48f1cad448296@mail.gmail.com> <20080207070845.32578.qmail@stuge.se> <13426df10802062346g3d00c2dfu1898100cd122efc4@mail.gmail.com> Message-ID: <20080207202826.GA11434@coresystems.de> * ron minnich [080207 08:46]: > This is a subtle problem. > > Devices must have constructor struct members to be used. > > static struct device_operations southbridge_ops = { > + .constructor = default_device_constructor, Before we start doing this all over the place. Do we ever want to define devices and compile them in that we don't want to use? If not, the default behavior with no constructor defined should be that the code automatically uses the default device constructor. -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From stepan at coresystems.de Thu Feb 7 21:32:12 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 7 Feb 2008 21:32:12 +0100 Subject: [coreboot] Coreboot-v2 qemu target rename In-Reply-To: <2831fecf0802071154x31c837f4g4dbd629ab7fc3018@mail.gmail.com> References: <00d501c869bf$b7271140$3222040a@chimp> <2831fecf0802071154x31c837f4g4dbd629ab7fc3018@mail.gmail.com> Message-ID: <20080207203212.GA15884@coresystems.de> * Myles Watson [080207 20:54]: > > Signed-off-by: Myles Watson Acked-by: Stefan Reinauer > Index: src/cpu/emulation/qemu-i386/northbridge.c > =================================================================== > --- src/cpu/emulation/qemu-i386/northbridge.c (revision 3092) > +++ src/cpu/emulation/qemu-i386/northbridge.c (working copy) > @@ -138,7 +138,7 @@ > } > } > > -struct chip_operations cpu_emulation_qemu_i386_ops = { > +struct chip_operations cpu_emulation_qemu_x86_ops = { > CHIP_NAME("QEMU Northbridge") > .enable_dev = enable_dev, > }; > Index: src/cpu/emulation/qemu-i386/chip.h > =================================================================== > --- src/cpu/emulation/qemu-i386/chip.h (revision 3092) > +++ src/cpu/emulation/qemu-i386/chip.h (working copy) > @@ -1,6 +1,6 @@ > -struct cpu_emulation_qemu_i386_config > +struct cpu_emulation_qemu_x86_config > { > }; > > -extern struct chip_operations cpu_emulation_qemu_i386_ops; > +extern struct chip_operations cpu_emulation_qemu_x86_ops; > > Index: src/cpu/emulation/qemu-i386/northbridge.h > =================================================================== > --- src/cpu/emulation/qemu-i386/northbridge.h (revision 3092) > +++ src/cpu/emulation/qemu-i386/northbridge.h (working copy) > @@ -1,5 +1,5 @@ > -#ifndef NORTHBRIDGE_EMULATION_QEMU_I386_H > -#define NORTHBRIDGE_EMULATION_QEMU_I386_H > +#ifndef NORTHBRIDGE_EMULATION_QEMU_X86_H > +#define NORTHBRIDGE_EMULATION_QEMU_X86_H > > > -#endif /* NORTHBRIDGE_EMULATION_QEMU_I386 */ > +#endif /* NORTHBRIDGE_EMULATION_QEMU_X86 */ > Index: src/mainboard/emulation/qemu-i386/Config.lb > =================================================================== > --- src/mainboard/emulation/qemu-i386/Config.lb (revision 3092) > +++ src/mainboard/emulation/qemu-i386/Config.lb (working copy) > @@ -104,7 +104,7 @@ > dir /pc80 > config chip.h > > -chip cpu/emulation/qemu-i386 > +chip cpu/emulation/qemu-x86 > device pci_domain 0 on > device pci 0.0 on end > device pci 1.0 on end > Index: src/mainboard/emulation/qemu-i386/chip.h > =================================================================== > --- src/mainboard/emulation/qemu-i386/chip.h (revision 3092) > +++ src/mainboard/emulation/qemu-i386/chip.h (working copy) > @@ -1,4 +1,4 @@ > -extern struct chip_operations mainboard_emulation_qemu_i386_ops; > +extern struct chip_operations mainboard_emulation_qemu_x86_ops; > > -struct mainboard_emulation_qemu_i386_config { > +struct mainboard_emulation_qemu_x86_config { > }; > Index: src/mainboard/emulation/qemu-i386/mainboard.c > =================================================================== > --- src/mainboard/emulation/qemu-i386/mainboard.c (revision 3092) > +++ src/mainboard/emulation/qemu-i386/mainboard.c (working copy) > @@ -33,7 +33,7 @@ > .device = 0x00b8, > }; > > -struct chip_operations mainboard_emulation_qemu_i386_ops = { > +struct chip_operations mainboard_emulation_qemu_x86_ops = { > CHIP_NAME("QEMU Mainboard") > }; > > Index: targets/emulation/qemu-i386/Config-abuild.lb > =================================================================== > --- targets/emulation/qemu-i386/Config-abuild.lb (revision 3092) > +++ targets/emulation/qemu-i386/Config-abuild.lb (working copy) > @@ -1,7 +1,7 @@ > -# This will make a target directory of ./emulation_qemu-i386 > +# This will make a target directory of ./emulation_qemu-x86 > > -target emulation_qemu-i386 > -mainboard emulation/qemu-i386 > +target emulation_qemu-x86 > +mainboard emulation/qemu-x86 > > __COMPRESSION__ > > Index: targets/emulation/qemu-i386/Config.lb > =================================================================== > --- targets/emulation/qemu-i386/Config.lb (revision 3092) > +++ targets/emulation/qemu-i386/Config.lb (working copy) > @@ -1,7 +1,7 @@ > -# This will make a target directory of ./emulation_qemu-i386 > +# This will make a target directory of ./emulation_qemu-x86 > > -target qemu-i386 > -mainboard emulation/qemu-i386 > +target qemu-x86 > +mainboard emulation/qemu-x86 > > option ROM_SIZE=256*1024 > > Index: targets/emulation/qemu-i386/Config-lab.lb > =================================================================== > --- targets/emulation/qemu-i386/Config-lab.lb (revision 3092) > +++ targets/emulation/qemu-i386/Config-lab.lb (working copy) > @@ -1,7 +1,7 @@ > -# This will make a target directory of ./emulation_qemu-i386 > +# This will make a target directory of ./emulation_qemu-x86 > > -target qemu-i386 > -mainboard emulation/qemu-i386 > +target qemu-x86 > +mainboard emulation/qemu-x86 > > option ROM_SIZE=2048*1024 > option CONFIG_COMPRESSED_PAYLOAD_LZMA=0 > Index: targets/emulation/qemu-i386/Config.OLPC.lb > =================================================================== > --- targets/emulation/qemu-i386/Config.OLPC.lb (revision 3092) > +++ targets/emulation/qemu-i386/Config.OLPC.lb (working copy) > @@ -1,7 +1,7 @@ > -# This will make a target directory of ./emulation_qemu-i386 > +# This will make a target directory of ./emulation_qemu-x86 > > -target qemu-i386-OLPC > -mainboard emulation/qemu-i386 > +target qemu-x86-OLPC > +mainboard emulation/qemu-x86 > > option ROM_SIZE=1024*1024 - (128 * 1024) > option CONFIG_COMPRESSED_PAYLOAD_LZMA=1 > -- > coreboot mailing list > coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From myles at pel.cs.byu.edu Thu Feb 7 21:33:38 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Thu, 7 Feb 2008 13:33:38 -0700 Subject: [coreboot] Buildrom v3 config patch and qemu rename patch Message-ID: <2831fecf0802071233h27604a01pf13ce665dcecebcc@mail.gmail.com> This patch changes buildrom for the renaming of qemu-i386 to qemu-x86. It also adds "make coreboot-v3-config" support ala Ward. Ward, could you check to make sure I didn't do something dumb when I shamelessly copied you? Thanks, Myles Signed-off-by: Myles Watson -------------- next part -------------- A non-text attachment was scrubbed... Name: buildrom-coreboot-v3-config.patch Type: text/x-patch Size: 7621 bytes Desc: not available URL: From svn at coreboot.org Thu Feb 7 21:37:37 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Thu, 7 Feb 2008 21:37:37 +0100 Subject: [coreboot] r3093 - in trunk/coreboot-v2: src/cpu/emulation src/cpu/emulation/qemu-x86 src/mainboard/emulation src/mainboard/emulation/qemu-x86 targets/emulation targets/emulation/qemu-x86 Message-ID: Author: myles Date: 2008-02-07 21:37:37 +0100 (Thu, 07 Feb 2008) New Revision: 3093 Added: trunk/coreboot-v2/src/cpu/emulation/qemu-x86/ trunk/coreboot-v2/src/mainboard/emulation/qemu-x86/ trunk/coreboot-v2/targets/emulation/qemu-x86/ Removed: trunk/coreboot-v2/src/cpu/emulation/qemu-i386/ trunk/coreboot-v2/src/mainboard/emulation/qemu-i386/ trunk/coreboot-v2/targets/emulation/qemu-i386/ Modified: trunk/coreboot-v2/src/cpu/emulation/qemu-x86/chip.h trunk/coreboot-v2/src/cpu/emulation/qemu-x86/northbridge.c trunk/coreboot-v2/src/cpu/emulation/qemu-x86/northbridge.h trunk/coreboot-v2/src/mainboard/emulation/qemu-x86/Config.lb trunk/coreboot-v2/src/mainboard/emulation/qemu-x86/chip.h trunk/coreboot-v2/src/mainboard/emulation/qemu-x86/mainboard.c trunk/coreboot-v2/targets/emulation/qemu-x86/Config-abuild.lb trunk/coreboot-v2/targets/emulation/qemu-x86/Config-lab.lb trunk/coreboot-v2/targets/emulation/qemu-x86/Config.OLPC.lb trunk/coreboot-v2/targets/emulation/qemu-x86/Config.lb Log: Change references to qemu in Coreboot-v2 calls to qemu-x86. The patch was followed by these svn commands: svn mv targets/emulation/qemu-i386/ targets/emulation/qemu-x86 svn mv --force targets/emulation/qemu-i386/ targets/emulation/qemu-x86 svn mv --force src/mainboard/emulation/qemu-i386/ src/mainboard/emulation/qemu-x86 svn mv --force src/cpu/emulation/qemu-i386/ src/cpu/emulation/qemu-x86 Signed-off-by: Myles Watson Acked-by: Stefan Reinauer Modified: trunk/coreboot-v2/src/cpu/emulation/qemu-x86/chip.h =================================================================== --- trunk/coreboot-v2/src/cpu/emulation/qemu-i386/chip.h 2008-02-06 22:33:50 UTC (rev 3092) +++ trunk/coreboot-v2/src/cpu/emulation/qemu-x86/chip.h 2008-02-07 20:37:37 UTC (rev 3093) @@ -1,6 +1,6 @@ -struct cpu_emulation_qemu_i386_config +struct cpu_emulation_qemu_x86_config { }; -extern struct chip_operations cpu_emulation_qemu_i386_ops; +extern struct chip_operations cpu_emulation_qemu_x86_ops; Modified: trunk/coreboot-v2/src/cpu/emulation/qemu-x86/northbridge.c =================================================================== --- trunk/coreboot-v2/src/cpu/emulation/qemu-i386/northbridge.c 2008-02-06 22:33:50 UTC (rev 3092) +++ trunk/coreboot-v2/src/cpu/emulation/qemu-x86/northbridge.c 2008-02-07 20:37:37 UTC (rev 3093) @@ -138,7 +138,7 @@ } } -struct chip_operations cpu_emulation_qemu_i386_ops = { +struct chip_operations cpu_emulation_qemu_x86_ops = { CHIP_NAME("QEMU Northbridge") .enable_dev = enable_dev, }; Modified: trunk/coreboot-v2/src/cpu/emulation/qemu-x86/northbridge.h =================================================================== --- trunk/coreboot-v2/src/cpu/emulation/qemu-i386/northbridge.h 2008-02-06 22:33:50 UTC (rev 3092) +++ trunk/coreboot-v2/src/cpu/emulation/qemu-x86/northbridge.h 2008-02-07 20:37:37 UTC (rev 3093) @@ -1,5 +1,5 @@ -#ifndef NORTHBRIDGE_EMULATION_QEMU_I386_H -#define NORTHBRIDGE_EMULATION_QEMU_I386_H +#ifndef NORTHBRIDGE_EMULATION_QEMU_X86_H +#define NORTHBRIDGE_EMULATION_QEMU_X86_H -#endif /* NORTHBRIDGE_EMULATION_QEMU_I386 */ +#endif /* NORTHBRIDGE_EMULATION_QEMU_X86 */ Modified: trunk/coreboot-v2/src/mainboard/emulation/qemu-x86/Config.lb =================================================================== --- trunk/coreboot-v2/src/mainboard/emulation/qemu-i386/Config.lb 2008-02-06 22:33:50 UTC (rev 3092) +++ trunk/coreboot-v2/src/mainboard/emulation/qemu-x86/Config.lb 2008-02-07 20:37:37 UTC (rev 3093) @@ -104,7 +104,7 @@ dir /pc80 config chip.h -chip cpu/emulation/qemu-i386 +chip cpu/emulation/qemu-x86 device pci_domain 0 on device pci 0.0 on end device pci 1.0 on end Modified: trunk/coreboot-v2/src/mainboard/emulation/qemu-x86/chip.h =================================================================== --- trunk/coreboot-v2/src/mainboard/emulation/qemu-i386/chip.h 2008-02-06 22:33:50 UTC (rev 3092) +++ trunk/coreboot-v2/src/mainboard/emulation/qemu-x86/chip.h 2008-02-07 20:37:37 UTC (rev 3093) @@ -1,4 +1,4 @@ -extern struct chip_operations mainboard_emulation_qemu_i386_ops; +extern struct chip_operations mainboard_emulation_qemu_x86_ops; -struct mainboard_emulation_qemu_i386_config { +struct mainboard_emulation_qemu_x86_config { }; Modified: trunk/coreboot-v2/src/mainboard/emulation/qemu-x86/mainboard.c =================================================================== --- trunk/coreboot-v2/src/mainboard/emulation/qemu-i386/mainboard.c 2008-02-06 22:33:50 UTC (rev 3092) +++ trunk/coreboot-v2/src/mainboard/emulation/qemu-x86/mainboard.c 2008-02-07 20:37:37 UTC (rev 3093) @@ -33,7 +33,7 @@ .device = 0x00b8, }; -struct chip_operations mainboard_emulation_qemu_i386_ops = { +struct chip_operations mainboard_emulation_qemu_x86_ops = { CHIP_NAME("QEMU Mainboard") }; Modified: trunk/coreboot-v2/targets/emulation/qemu-x86/Config-abuild.lb =================================================================== --- trunk/coreboot-v2/targets/emulation/qemu-i386/Config-abuild.lb 2008-02-06 22:33:50 UTC (rev 3092) +++ trunk/coreboot-v2/targets/emulation/qemu-x86/Config-abuild.lb 2008-02-07 20:37:37 UTC (rev 3093) @@ -1,7 +1,7 @@ -# This will make a target directory of ./emulation_qemu-i386 +# This will make a target directory of ./emulation_qemu-x86 -target emulation_qemu-i386 -mainboard emulation/qemu-i386 +target emulation_qemu-x86 +mainboard emulation/qemu-x86 __COMPRESSION__ Modified: trunk/coreboot-v2/targets/emulation/qemu-x86/Config-lab.lb =================================================================== --- trunk/coreboot-v2/targets/emulation/qemu-i386/Config-lab.lb 2008-02-06 22:33:50 UTC (rev 3092) +++ trunk/coreboot-v2/targets/emulation/qemu-x86/Config-lab.lb 2008-02-07 20:37:37 UTC (rev 3093) @@ -1,7 +1,7 @@ -# This will make a target directory of ./emulation_qemu-i386 +# This will make a target directory of ./emulation_qemu-x86 -target qemu-i386 -mainboard emulation/qemu-i386 +target qemu-x86 +mainboard emulation/qemu-x86 option ROM_SIZE=2048*1024 option CONFIG_COMPRESSED_PAYLOAD_LZMA=0 Modified: trunk/coreboot-v2/targets/emulation/qemu-x86/Config.OLPC.lb =================================================================== --- trunk/coreboot-v2/targets/emulation/qemu-i386/Config.OLPC.lb 2008-02-06 22:33:50 UTC (rev 3092) +++ trunk/coreboot-v2/targets/emulation/qemu-x86/Config.OLPC.lb 2008-02-07 20:37:37 UTC (rev 3093) @@ -1,7 +1,7 @@ -# This will make a target directory of ./emulation_qemu-i386 +# This will make a target directory of ./emulation_qemu-x86 -target qemu-i386-OLPC -mainboard emulation/qemu-i386 +target qemu-x86-OLPC +mainboard emulation/qemu-x86 option ROM_SIZE=1024*1024 - (128 * 1024) option CONFIG_COMPRESSED_PAYLOAD_LZMA=1 Modified: trunk/coreboot-v2/targets/emulation/qemu-x86/Config.lb =================================================================== --- trunk/coreboot-v2/targets/emulation/qemu-i386/Config.lb 2008-02-06 22:33:50 UTC (rev 3092) +++ trunk/coreboot-v2/targets/emulation/qemu-x86/Config.lb 2008-02-07 20:37:37 UTC (rev 3093) @@ -1,7 +1,7 @@ -# This will make a target directory of ./emulation_qemu-i386 +# This will make a target directory of ./emulation_qemu-x86 -target qemu-i386 -mainboard emulation/qemu-i386 +target qemu-x86 +mainboard emulation/qemu-x86 option ROM_SIZE=256*1024 From ward at gnu.org Thu Feb 7 21:44:19 2008 From: ward at gnu.org (Ward Vandewege) Date: Thu, 7 Feb 2008 15:44:19 -0500 Subject: [coreboot] Buildrom v3 config patch and qemu rename patch In-Reply-To: <2831fecf0802071233h27604a01pf13ce665dcecebcc@mail.gmail.com> References: <2831fecf0802071233h27604a01pf13ce665dcecebcc@mail.gmail.com> Message-ID: <20080207204419.GA11621@localdomain> On Thu, Feb 07, 2008 at 01:33:38PM -0700, Myles Watson wrote: > This patch changes buildrom for the renaming of qemu-i386 to qemu-x86. > It also adds "make coreboot-v3-config" support ala Ward. Ward, could > you check to make sure I didn't do something dumb when I shamelessly > copied you? Heh :) Looks good, but I would add $(CBV3_STAMP_DIR) as an order-only prerequisite to the $(CBV3_STAMP_DIR)/.unpacked make target; otherwise doing make coreboot-v3-config after make distclean is going to fail for a lack of $(CBV3_STAMP_DIR). > Signed-off-by: Myles Watson With that change: Acked-by: Ward Vandewege Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From myles at pel.cs.byu.edu Thu Feb 7 21:39:20 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Thu, 7 Feb 2008 13:39:20 -0700 Subject: [coreboot] Coreboot-v2 qemu target rename In-Reply-To: <20080207203212.GA15884@coresystems.de> References: <00d501c869bf$b7271140$3222040a@chimp> <2831fecf0802071154x31c837f4g4dbd629ab7fc3018@mail.gmail.com> <20080207203212.GA15884@coresystems.de> Message-ID: <2831fecf0802071239p5ad9316enb1350e6ca813dd51@mail.gmail.com> On Feb 7, 2008 1:32 PM, Stefan Reinauer wrote: > * Myles Watson [080207 20:54]: > > > > Signed-off-by: Myles Watson > Acked-by: Stefan Reinauer Thanks, Rev 3093 Myles From myles at pel.cs.byu.edu Thu Feb 7 21:57:06 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Thu, 7 Feb 2008 13:57:06 -0700 Subject: [coreboot] Buildrom v3 config patch and qemu rename patch In-Reply-To: <20080207204419.GA11621@localdomain> References: <2831fecf0802071233h27604a01pf13ce665dcecebcc@mail.gmail.com> <20080207204419.GA11621@localdomain> Message-ID: <00f101c869cb$ffc29940$3222040a@chimp> > -----Original Message----- > From: Ward Vandewege [mailto:ward at gnu.org] > Sent: Thursday, February 07, 2008 1:44 PM > To: Myles Watson > Cc: Coreboot > Subject: Re: Buildrom v3 config patch and qemu rename patch > > On Thu, Feb 07, 2008 at 01:33:38PM -0700, Myles Watson wrote: > > This patch changes buildrom for the renaming of qemu-i386 to qemu-x86. > > It also adds "make coreboot-v3-config" support ala Ward. Ward, could > > you check to make sure I didn't do something dumb when I shamelessly > > copied you? > > Heh :) Looks good, but I would add $(CBV3_STAMP_DIR) as an order-only > prerequisite to the $(CBV3_STAMP_DIR)/.unpacked make target; otherwise > doing > make coreboot-v3-config after make distclean is going to fail for a lack > of > $(CBV3_STAMP_DIR). Good catch. Should we add that for uclibc as well? Myles > > Signed-off-by: Myles Watson > > With that change: > > Acked-by: Ward Vandewege > > Thanks, > Ward. > > -- > Ward Vandewege > Free Software Foundation - Senior System Administrator From svn at coreboot.org Thu Feb 7 22:11:21 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Thu, 7 Feb 2008 22:11:21 +0100 Subject: [coreboot] r110 - in buildrom-devel: config/platforms packages/coreboot-v3 packages/coreboot-v3/conf Message-ID: Author: myles Date: 2008-02-07 22:11:20 +0100 (Thu, 07 Feb 2008) New Revision: 110 Removed: buildrom-devel/packages/coreboot-v3/conf/qemu-i386-defconfig Modified: buildrom-devel/config/platforms/Config.in buildrom-devel/config/platforms/platforms.conf buildrom-devel/config/platforms/qemu.conf buildrom-devel/config/platforms/serengeti_cheetah.conf buildrom-devel/packages/coreboot-v3/coreboot-v3.mk Log: This patch changes buildrom for the renaming of qemu-i386 to qemu-x86. It also adds "make coreboot-v3-config" support ala Ward. Thanks, Myles Signed-off-by: Myles Watson Acked-by: Ward Vandewege Modified: buildrom-devel/config/platforms/Config.in =================================================================== --- buildrom-devel/config/platforms/Config.in 2008-02-07 17:41:01 UTC (rev 109) +++ buildrom-devel/config/platforms/Config.in 2008-02-07 21:11:20 UTC (rev 110) @@ -95,7 +95,7 @@ select PLATFORM select PLATFORM_SUPPORT_64BIT -config PLATFORM_QEMU-i386 +config PLATFORM_QEMU-X86 bool "QEMU Emulator" depends VENDOR_QEMU select PLATFORM @@ -122,7 +122,7 @@ config BUILD_QEMU bool "Build QEMU with patches for LinuxBIOS" - depends PLATFORM_QEMU-i386 + depends PLATFORM_QEMU-X86 default n help Say 'y' here to build a patched version of QEMU to work with Modified: buildrom-devel/config/platforms/platforms.conf =================================================================== --- buildrom-devel/config/platforms/platforms.conf 2008-02-07 17:41:01 UTC (rev 109) +++ buildrom-devel/config/platforms/platforms.conf 2008-02-07 21:11:20 UTC (rev 110) @@ -18,6 +18,6 @@ PLATFORM-$(CONFIG_PLATFORM_SERENGETI_CHEETAH) = serengeti_cheetah.conf PLATFORM-$(CONFIG_PLATFORM_CHEETAH_FAM10) = serengeti_cheetah.conf PLATFORM-$(CONFIG_PLATFORM_GA_2761GXDK) = ga-2761gxdk.conf -PLATFORM-$(CONFIG_PLATFORM_QEMU-i386) = qemu.conf +PLATFORM-$(CONFIG_PLATFORM_QEMU-X86) = qemu.conf include $(CONFIG_DIR)/platforms/$(PLATFORM-y) Modified: buildrom-devel/config/platforms/qemu.conf =================================================================== --- buildrom-devel/config/platforms/qemu.conf 2008-02-07 17:41:01 UTC (rev 109) +++ buildrom-devel/config/platforms/qemu.conf 2008-02-07 21:11:20 UTC (rev 110) @@ -24,17 +24,16 @@ ETHERBOOT_ARCH=i386 # coreboot-v2 configuration -CBV2_TAG=3092 +CBV2_TAG=3093 CBV2_CONFIG=Config.lb CBV2_PAYLOAD_FILE_EXT=elf -CBV2_TDIR=qemu-i386 +CBV2_TDIR=qemu-x86 # coreboot v3 configuration -CBV3_CONFIG=qemu-i386-defconfig CBV3_TAG=HEAD COREBOOT_VENDOR=emulation -COREBOOT_BOARD=qemu-i386 +COREBOOT_BOARD=qemu-x86 # FILO configuration Modified: buildrom-devel/config/platforms/serengeti_cheetah.conf =================================================================== --- buildrom-devel/config/platforms/serengeti_cheetah.conf 2008-02-07 17:41:01 UTC (rev 109) +++ buildrom-devel/config/platforms/serengeti_cheetah.conf 2008-02-07 21:11:20 UTC (rev 110) @@ -52,12 +52,10 @@ COREBOOT_BOARD=serengeti_cheetah_fam10 CBV2_TDIR=serengeti_cheetah_fam10 CBV2_TAG=3092 -CBV3_CONFIG=serengeti_cheetah_fam10-defconfig else COREBOOT_BOARD=serengeti_cheetah CBV2_TDIR=serengeti_cheetah CBV2_TAG=3092 -CBV3_CONFIG=serengeti_cheetah-defconfig endif # FILO configuration Deleted: buildrom-devel/packages/coreboot-v3/conf/qemu-i386-defconfig =================================================================== --- buildrom-devel/packages/coreboot-v3/conf/qemu-i386-defconfig 2008-02-07 17:41:01 UTC (rev 109) +++ buildrom-devel/packages/coreboot-v3/conf/qemu-i386-defconfig 2008-02-07 21:11:20 UTC (rev 110) @@ -1,88 +0,0 @@ -# -# Automatically generated make config: don't edit -# coreboot version: 3.0.0 -# Wed Feb 6 13:55:31 2008 -# - -# -# General setup -# -# CONFIG_EXPERIMENTAL is not set -# CONFIG_EXPERT is not set -CONFIG_LOCALVERSION="" - -# -# Mainboard -# -# CONFIG_VENDOR_ADL is not set -# CONFIG_VENDOR_AMD is not set -# CONFIG_VENDOR_ARTECGROUP is not set -CONFIG_VENDOR_EMULATION=y -# CONFIG_VENDOR_PCENGINES is not set -CONFIG_MAINBOARD_NAME="emulation/qemu-x86" -CONFIG_MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID=0x15ad -CONFIG_MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID=0x1976 -CONFIG_BOARD_EMULATION_QEMU_X86=y -# CONFIG_COREBOOT_ROMSIZE_KB_128 is not set -# CONFIG_COREBOOT_ROMSIZE_KB_256 is not set -# CONFIG_COREBOOT_ROMSIZE_KB_512 is not set -CONFIG_COREBOOT_ROMSIZE_KB_1024=y -# CONFIG_COREBOOT_ROMSIZE_KB_2048 is not set -CONFIG_COREBOOT_ROMSIZE_KB=1024 -CONFIG_ARCH_X86=y -CONFIG_ARCH="x86" -CONFIG_CPU_I586=y -CONFIG_OPTION_TABLE=y - -# -# Compression -# -CONFIG_COMPRESSION_LZMA=y -# CONFIG_COMPRESSION_NRV2B is not set -CONFIG_DEFAULT_COMPRESSION_LZMA=y -# CONFIG_DEFAULT_COMPRESSION_NRV2B is not set -# CONFIG_DEFAULT_COMPRESSION_NONE is not set - -# -# Console -# -CONFIG_CONSOLE=y -CONFIG_CONSOLE_LOGLEVEL_8=y -# CONFIG_CONSOLE_LOGLEVEL_7 is not set -# CONFIG_CONSOLE_LOGLEVEL_6 is not set -# CONFIG_CONSOLE_LOGLEVEL_5 is not set -# CONFIG_CONSOLE_LOGLEVEL_4 is not set -# CONFIG_CONSOLE_LOGLEVEL_3 is not set -# CONFIG_CONSOLE_LOGLEVEL_2 is not set -# CONFIG_CONSOLE_LOGLEVEL_1 is not set -# CONFIG_CONSOLE_LOGLEVEL_0 is not set -CONFIG_DEFAULT_CONSOLE_LOGLEVEL=8 -CONFIG_CONSOLE_SERIAL=y -CONFIG_CONSOLE_SERIAL_COM1=y -# CONFIG_CONSOLE_SERIAL_COM2 is not set -CONFIG_CONSOLE_SERIAL_115200=y -# CONFIG_CONSOLE_SERIAL_57600 is not set -# CONFIG_CONSOLE_SERIAL_38400 is not set -# CONFIG_CONSOLE_SERIAL_19200 is not set -# CONFIG_CONSOLE_SERIAL_9600 is not set - -# -# Devices -# -CONFIG_PCI_OPTION_ROM_RUN=y -# CONFIG_PCI_OPTION_ROM_RUN_X86EMU is not set -CONFIG_PCI_OPTION_ROM_RUN_VM86=y -# CONFIG_PCI_OPTION_ROM_RUN_NONE is not set -# CONFIG_MULTIPLE_VGA_INIT is not set -# CONFIG_INITIALIZE_ONBOARD_VGA_FIRST is not set -CONFIG_NORTHBRIDGE_INTEL_I440BXEMULATION=y -CONFIG_SOUTHBRIDGE_INTEL_I82371EB=y -CONFIG_SUPERIO_WINBOND_W83627HF=y -CONFIG_NORTHBRIDGE_INTEL_I440BXEMULATION_RAMSIZE=32 - -# -# Payload -# -# CONFIG_PAYLOAD_PREPARSE_ELF is not set -# CONFIG_PAYLOAD_ELF is not set -CONFIG_PAYLOAD_NONE=y Modified: buildrom-devel/packages/coreboot-v3/coreboot-v3.mk =================================================================== --- buildrom-devel/packages/coreboot-v3/coreboot-v3.mk 2008-02-07 17:41:01 UTC (rev 109) +++ buildrom-devel/packages/coreboot-v3/coreboot-v3.mk 2008-02-07 21:11:20 UTC (rev 110) @@ -3,7 +3,7 @@ endif CBV3_URL=svn://coreboot.org/repository/coreboot-v3 -CBV3_TARBALL=coreboot-svn-$(CBV3_TAG).tar.gz +CBV3_TARBALL=coreboot-v3-svn-$(CBV3_TAG).tar.gz CBV3_DIR=$(BUILD_DIR)/coreboot-v3 CBV3_SRC_DIR=$(CBV3_DIR)/svn @@ -32,7 +32,7 @@ $(SOURCE_DIR)/coreboot-v3 $(CBV3_TAG) \ $@ > $(CBV3_FETCH_LOG) 2>&1 -$(CBV3_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(CBV3_TARBALL) +$(CBV3_STAMP_DIR)/.unpacked: $(SOURCE_DIR)/$(CBV3_TARBALL) | $(CBV3_STAMP_DIR) @echo "Unpacking coreboot v3..." @ mkdir -p $(CBV3_DIR) @ tar -C $(CBV3_DIR) -zxf $(SOURCE_DIR)/$(CBV3_TARBALL) @@ -45,8 +45,15 @@ $(CBV3_STAMP_DIR)/.configured: $(CBV3_STAMP_DIR)/.patched @ echo "Configuring coreboot v3..." - @ cp $(PACKAGE_DIR)/coreboot-v3/conf/$(CBV3_CONFIG) $(CBV3_SRC_DIR)/.config +ifeq ($(shell if [ -f $(PACKAGE_DIR)/coreboot-v3/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + @ cp -f $(PACKAGE_DIR)/coreboot-v3/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) $(CBV3_SRC_DIR)/.config + @ echo "Using custom config $(PACKAGE_DIR)/coreboot-v3/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)" @ make -C $(CBV3_SRC_DIR) oldconfig > $(CBV3_CONFIG_LOG) 2>&1 +else + @ make -C $(CBV3_SRC_DIR) defconfig \ + MAINBOARDDIR="$(COREBOOT_VENDOR)/$(COREBOOT_BOARD)" \ + > $(CBV3_CONFIG_LOG) 2>&1 +endif @ touch $@ $(CBV3_OUTPUT): $(CBV3_STAMP_DIR)/.configured @@ -60,9 +67,8 @@ @ mkdir -p $(STAGING_DIR)/bin @ cp $< $@ - $(CBV3_STAMP_DIR) $(CBV3_LOG_DIR): - @ mkdir -p $@ + mkdir -p $@ coreboot-v3: $(CBV3_LOG_DIR) $(CBV3_STAMP_DIR) $(CBV3_OUTPUT) $(STAGING_DIR)/bin/lar @@ -74,3 +80,21 @@ @ rm -rf $(CBV3_DIR)/* @ rm -rf $(STAGING_DIR)/bin/lar +coreboot-v3-config: $(CBV3_STAMP_DIR)/.unpacked +ifeq ($(shell if [ -f $(PACKAGE_DIR)/coreboot-v3/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + @ cp -f $(PACKAGE_DIR)/coreboot-v3/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) $(CBV3_SRC_DIR)/.config +endif + @ echo "Configure coreboot-v3..." + @ $(MAKE) -C $(CBV3_SRC_DIR) menuconfig + @ echo +ifeq ($(shell if [ -f $(PACKAGE_DIR)/coreboot-v3/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) ]; then echo 1; fi),1) + @ echo "Found an existing custom configuration file:" + @ echo " $(PACKAGE_DIR)/coreboot-v3/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)" + @ echo "I've copied it back to the source directory for modification." + @ echo "Remove the above file and re-run this command if you want to create a new custom configuration from scratch for this payload/board." + @ echo +endif + @ cp -f $(CBV3_SRC_DIR)/.config $(PACKAGE_DIR)/coreboot-v3/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD) + @ echo "Your custom coreboot-v3 config file has been saved as $(PACKAGE_DIR)/coreboot-v3/conf/customconfig--$(PAYLOAD)--$(COREBOOT_VENDOR)-$(COREBOOT_BOARD)." + @ echo + @ touch $(CBV3_STAMP_DIR)/.configured From myles at pel.cs.byu.edu Thu Feb 7 22:12:51 2008 From: myles at pel.cs.byu.edu (Myles Watson) Date: Thu, 7 Feb 2008 14:12:51 -0700 Subject: [coreboot] Buildrom v3 config patch and qemu rename patch In-Reply-To: <00f101c869cb$ffc29940$3222040a@chimp> References: <2831fecf0802071233h27604a01pf13ce665dcecebcc@mail.gmail.com> <20080207204419.GA11621@localdomain> <00f101c869cb$ffc29940$3222040a@chimp> Message-ID: <2831fecf0802071312k5d9960d6yd565b5b8e9bf84c4@mail.gmail.com> > > Heh :) Looks good, but I would add $(CBV3_STAMP_DIR) as an order-only > > prerequisite to the $(CBV3_STAMP_DIR)/.unpacked make target; otherwise > > doing > > make coreboot-v3-config after make distclean is going to fail for a lack > > of > > $(CBV3_STAMP_DIR). > > Good catch. Should we add that for uclibc as well? > > Myles I was looking at the wrong line. It was already in uclibc. Rev 110. Thanks, Myles > > > > Signed-off-by: Myles Watson > > > > With that change: > > > > Acked-by: Ward Vandewege From svn at coreboot.org Thu Feb 7 22:26:29 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Thu, 7 Feb 2008 22:26:29 +0100 Subject: [coreboot] r111 - buildrom-devel/packages/coreboot-v3 Message-ID: Author: myles Date: 2008-02-07 22:26:29 +0100 (Thu, 07 Feb 2008) New Revision: 111 Modified: buildrom-devel/packages/coreboot-v3/coreboot-v3.mk Log: Trivial fix of a verbose makefile rule. Thanks, Myles Signed-off-by: Myles Watson Acked-by: Myles Watson Modified: buildrom-devel/packages/coreboot-v3/coreboot-v3.mk =================================================================== --- buildrom-devel/packages/coreboot-v3/coreboot-v3.mk 2008-02-07 21:11:20 UTC (rev 110) +++ buildrom-devel/packages/coreboot-v3/coreboot-v3.mk 2008-02-07 21:26:29 UTC (rev 111) @@ -68,7 +68,7 @@ @ cp $< $@ $(CBV3_STAMP_DIR) $(CBV3_LOG_DIR): - mkdir -p $@ + @ mkdir -p $@ coreboot-v3: $(CBV3_LOG_DIR) $(CBV3_STAMP_DIR) $(CBV3_OUTPUT) $(STAGING_DIR)/bin/lar From info at coresystems.de Thu Feb 7 22:28:43 2008 From: info at coresystems.de (coreboot information) Date: Thu, 07 Feb 2008 22:28:43 +0100 Subject: [coreboot] r3093 build service Message-ID: Dear coreboot readers! This is the automated build check service of coreboot. The developer "myles" checked in revision 3093 to the coreboot source repository and caused the following changes: Change Log: Change references to qemu in Coreboot-v2 calls to qemu-x86. The patch was followed by these svn commands: svn mv targets/emulation/qemu-i386/ targets/emulation/qemu-x86 svn mv --force targets/emulation/qemu-i386/ targets/emulation/qemu-x86 svn mv --force src/mainboard/emulation/qemu-i386/ src/mainboard/emulation/qemu-x86 svn mv --force src/cpu/emulation/qemu-i386/ src/cpu/emulation/qemu-x86 Signed-off-by: Myles Watson Acked-by: Stefan Reinauer Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3093&device=serengeti_cheetah_fam10&vendor=amd If something broke during this checkin please be a pain in myles's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system From svn at coreboot.org Thu Feb 7 22:50:22 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Thu, 7 Feb 2008 22:50:22 +0100 Subject: [coreboot] r3094 - trunk/coreboot-v2/targets Message-ID: Author: ward Date: 2008-02-07 22:50:22 +0100 (Thu, 07 Feb 2008) New Revision: 3094 Modified: trunk/coreboot-v2/targets/buildtarget Log: Make the check for -fno-stack-protector fail silently, if it fails. This is a trivial patch. Signed-off-by: Ward Vandewege Acked-by: Ward Vandewege Modified: trunk/coreboot-v2/targets/buildtarget =================================================================== --- trunk/coreboot-v2/targets/buildtarget 2008-02-07 20:37:37 UTC (rev 3093) +++ trunk/coreboot-v2/targets/buildtarget 2008-02-07 21:50:22 UTC (rev 3094) @@ -61,7 +61,7 @@ CC=gcc fi -$CC -fno-stack-protector -S -xc /dev/null -o .$$.tmp +$CC -fno-stack-protector -S -xc /dev/null -o .$$.tmp 2>/dev/null if [ $? -eq 0 ]; then EXTRA_CFLAGS=-fno-stack-protector From joe at smittys.pointclark.net Thu Feb 7 23:02:55 2008 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Thu, 07 Feb 2008 17:02:55 -0500 Subject: [coreboot] Run PCI rom before PCI bus scan?? In-Reply-To: <47AB43B0.6070901@sun.com> References: <20080202203430.1p2at6gtc0skw0so@www.smittys.pointclark.net> <20080203183738.GA4289@coresystems.de> <20080203144443.q9r9b16s00wgk8k0@www.smittys.pointclark.net> <47A62410.90805@gmail.com> <20080203181552.tybs70ow5c4osoo4@www.smittys.pointclark.net> <20080204074936.4q1bevm7ksggowsk@www.smittys.pointclark.net> <47A75095.3070109@assembler.cz> <20080205105139.rhwr4w0eg0gg0wws@www.smittys.pointclark.net> <20080205164448.26302.qmail@stuge.se> <20080206172332.21955.qmail@stuge.se> <47AB43B0.6070901@sun.com> Message-ID: <20080207170255.xrdzcpbdw40gogw0@www.smittys.pointclark.net> Quoting Marc Karasek : > Let me add me two cents.. > > I have dealt with the Intel MACs in the past so let me dreg up some > memorries... > > From what I recall, you had a serial eeprom on the board that > contained the init for the chip. This was the 82545GM. > > The eeprom image was protected by a CRC and if the CRC failed it would > not load the image. By CRC do you mean checksum? There is a checksum in the eeprom. > The device would also not be visible on the PCI > Bus unless the eeprom was loaded. I have attached the 82545 eeprom > spec sheet (freely avail from Intel) maybe this will give you some > insight. > > Intel has a program to read/update the paramters. I never used it, > mainly because I was on an embedded system running MIPS-Linux and they > would only provide a x86 binary, no src code. It took me a couple of > iterations to get the eeprom right. Maybe you can get the utility from > Intel and dump the eeprom. What I do not understand is why you would be > having problems with coreboot. the only thing I can guess is the > default eeprom is putting the MAC into a state that the BIOS must take > it out of (maybe WoL). Did you say you have the spec sheet for the > part and it talks about the eeprom? > Marc I am able to read the eeprom in Linux with ethtool. Wol is enabled. This is a 82562ET chipset (same family). Corey, I am pretty sure that atmel chip is the eeprom. Again, here is what I think needs to be done: OK, here is what I have picked up reading, reading, and more reading: 1. When the system is powered on "At this point, the LAN controller is in the D0u state" 2. The "Platform LAN Connect component" is actually a command script (probibly a rom written in assembly) runs and sets up the CSR register (I could setup a script in the mainboard directory and run from auto.c). 3. At this point it goes into a DOa state. 3. The "Platform LAN Connect component" hands it over to the bios (coreboot) to setup "Memory, or I/O Base Registers in the PCI Configuration space" 4. nic is setup and ready to go! What do you think? The only thing I am not sure of is how to read/write to the CSR register??? Thanks - Joe From svn at coreboot.org Thu Feb 7 23:42:22 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Thu, 7 Feb 2008 23:42:22 +0100 Subject: [coreboot] r3095 - trunk/coreboot-v2/targets/emulation/qemu-x86 Message-ID: Author: myles Date: 2008-02-07 23:42:22 +0100 (Thu, 07 Feb 2008) New Revision: 3095 Modified: trunk/coreboot-v2/targets/emulation/qemu-x86/Config-lab.lb Log: This is a trivial patch. I missed one of the ROM names when I converted them to coreboot.rom Signed-off-by: Myles Watson Acked-by: Myles Watson Modified: trunk/coreboot-v2/targets/emulation/qemu-x86/Config-lab.lb =================================================================== --- trunk/coreboot-v2/targets/emulation/qemu-x86/Config-lab.lb 2008-02-07 21:50:22 UTC (rev 3094) +++ trunk/coreboot-v2/targets/emulation/qemu-x86/Config-lab.lb 2008-02-07 22:42:22 UTC (rev 3095) @@ -18,5 +18,5 @@ payload ../payload.elf.lzma end -buildrom ./qemu.rom ROM_SIZE "image" +buildrom ./coreboot.rom ROM_SIZE "image" From info at coresystems.de Thu Feb 7 23:43:42 2008 From: info at coresystems.de (coreboot information) Date: Thu, 07 Feb 2008 23:43:42 +0100 Subject: [coreboot] r3094 build service Message-ID: Dear coreboot readers! This is the automated build check service of coreboot. The developer "ward" checked in revision 3094 to the coreboot source repository and caused the following changes: Change Log: Make the check for -fno-stack-protector fail silently, if it fails. This is a trivial patch. Signed-off-by: Ward Vandewege Acked-by: Ward Vandewege Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3094&device=serengeti_cheetah_fam10&vendor=amd If something broke during this checkin please be a pain in ward's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system From corey.osgood at gmail.com Thu Feb 7 23:48:13 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Thu, 7 Feb 2008 17:48:13 -0500 Subject: [coreboot] Run PCI rom before PCI bus scan?? In-Reply-To: References: <20080202203430.1p2at6gtc0skw0so@www.smittys.pointclark.net> <20080204074936.4q1bevm7ksggowsk@www.smittys.pointclark.net> <47A75095.3070109@assembler.cz> <20080205105139.rhwr4w0eg0gg0wws@www.smittys.pointclark.net> <20080205164448.26302.qmail@stuge.se> <20080206172332.21955.qmail@stuge.se> <47AB43B0.6070901@sun.com> <20080207170255.xrdzcpbdw40gogw0@www.smittys.pointclark.net> Message-ID: Another missed cc. On Feb 7, 2008 5:46 PM, Corey Osgood wrote: > On Feb 7, 2008 5:02 PM, wrote: > > > Quoting Marc Karasek : > > > > > Let me add me two cents.. > > > > > > I have dealt with the Intel MACs in the past so let me dreg up some > > > memorries... > > > > > > From what I recall, you had a serial eeprom on the board that > > > contained the init for the chip. This was the 82545GM. > > > > > > The eeprom image was protected by a CRC and if the CRC failed it would > > > not load the image. > > > > By CRC do you mean checksum? There is a checksum in the eeprom. > > > > > The device would also not be visible on the PCI > > > Bus unless the eeprom was loaded. I have attached the 82545 eeprom > > > spec sheet (freely avail from Intel) maybe this will give you some > > > insight. > > > > > > Intel has a program to read/update the paramters. I never used it, > > > mainly because I was on an embedded system running MIPS-Linux and they > > > would only provide a x86 binary, no src code. It took me a couple of > > > iterations to get the eeprom right. Maybe you can get the utility > > from > > > Intel and dump the eeprom. What I do not understand is why you would > > be > > > having problems with coreboot. the only thing I can guess is the > > > default eeprom is putting the MAC into a state that the BIOS must take > > > it out of (maybe WoL). Did you say you have the spec sheet for the > > > part and it talks about the eeprom? > > > > > Marc I am able to read the eeprom in Linux with ethtool. Wol is > > enabled. This is a 82562ET chipset (same family). Corey, I am pretty > > sure that atmel chip is the eeprom. Again, here is what I think needs > > to be done: > > > > OK, here is what I have picked up reading, reading, and more reading: > > 1. When the system is powered on "At this point, the LAN > > controller is in the D0u state" > > > > 2. The "Platform LAN Connect component" is actually a command script > > (probibly a rom written in assembly) runs and sets up the CSR register > > (I could setup a script in the mainboard directory and run from auto.c). > > > > 3. At this point it goes into a DOa state. > > > > 3. The "Platform LAN Connect component" hands it over to the bios > > (coreboot) to setup "Memory, or I/O Base Registers in the PCI > > Configuration space" > > > > 4. nic is setup and ready to go! > > > > What do you think? > > > > The only thing I am not sure of is how to read/write to the CSR > > register??? > > > > > > Thanks - Joe > > > > > > I apologize if this seems disorganized, I'm trying to work it out: > > 1: set up csr memory/io base in the nic. ami bios uses 0xff7ff000 for mem > base, and 0xdc01 as io base, these values should work to test with. > Datasheet contradicts itself, says bits 3:0 of the mem base registers are > all hardwired to 0, then gives a default value of 0x8. > > 2: write 0x3 to register 0xe (in IO space?) to enable the rom and clock. > if this is io space, the write is just outb(val, (NIC_IO_BASE + reg)). There > are reserved registers, so be sure to do a read-modify-write. > > 3: reset the lan controller? write 1 to bit 3 of 0x1c. Wait 1ms > afterwards. > > Good luck, hope this helps > -Corey > -------------- next part -------------- An HTML attachment was scrubbed... URL: From svn at coreboot.org Thu Feb 7 23:53:54 2008 From: svn at coreboot.org (svn at coreboot.org) Date: Thu, 7 Feb 2008 23:53:54 +0100 Subject: [coreboot] r3096 - trunk/coreboot-v2/targets/gigabyte/m57sli Message-ID: Author: ward Date: 2008-02-07 23:53:53 +0100 (Thu, 07 Feb 2008) New Revision: 3096 Modified: trunk/coreboot-v2/targets/gigabyte/m57sli/Config.lb Log: Change payload location in 'normal' - this was missed in r3992 and thus breaks buildrom. This is a trivial patch. Signed-off-by: Ward Vandewege Acked-by: Ward Vandewege Modified: trunk/coreboot-v2/targets/gigabyte/m57sli/Config.lb =================================================================== --- trunk/coreboot-v2/targets/gigabyte/m57sli/Config.lb 2008-02-07 22:42:22 UTC (rev 3095) +++ trunk/coreboot-v2/targets/gigabyte/m57sli/Config.lb 2008-02-07 22:53:53 UTC (rev 3096) @@ -50,13 +50,14 @@ # payload ../../../../payloads/tg3--filo_hda2_vga.zelf # payload ../../../../payloads/tg3--filo_hda2_vga_5_4.zelf # payload ../../../../payloads/forcedeth--filo_hda2_vga.zelf - payload ../../../../payloads/forcedeth--filo_hda2_vga_5_4_2_mcp55.zelf +# payload ../../../../payloads/forcedeth--filo_hda2_vga_5_4_2_mcp55.zelf # payload ../../../payloads/tg3_com2.zelf # payload ../../../payloads/e1000--filo.zelf # payload ../../../payloads/tg3--e1000--filo.zelf # payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf # payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_5.3.zelf # payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_com2.zelf + payload ../payload.elf end romimage "fallback" From Marc.Jones at AMD.com Fri Feb 8 00:00:14 2008 From: Marc.Jones at AMD.com (Marc Jones) Date: Thu, 07 Feb 2008 16:00:14 -0700 Subject: [coreboot] [Fwd: Re: [patch] Build error with top of tree V2] Message-ID: <47AB8D7E.9030500@AMD.com> Looking for an ack. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors -------------- next part -------------- An embedded message was scrubbed... From: "Marc Jones" Subject: Re: [coreboot] [patch] Build error with top of tree V2 Date: Wed, 06 Feb 2008 11:09:42 -0700 Size: 7702 URL: From c-d.hailfinger.devel.2006 at gmx.net Fri Feb 8 00:13:36 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 08 Feb 2008 00:13:36 +0100 Subject: [coreboot] Coreboot-v2 qemu target rename In-Reply-To: <00d501c869bf$b7271140$3222040a@chimp> References: <00d501c869bf$b7271140$3222040a@chimp> Message-ID: <47AB90A0.5090208@gmx.net> On 07.02.2008 20:29, Myles Watson wrote: > Coreboot-v3 calls the qemu board qemu-x86, but Coreboot-v2 calls it > qemu-i386. I think that qemu-x86 should be the preferred name. > > Does anyone have any reservations about the switch to qemu-x86 in > Coreboot-v2? > Hm. Qemu also has an x86-64 version, so it might be easier to see that we target 32bit if we call it i386. Regards, Carl-Daniel From Marc.Jones at AMD.com Fri Feb 8 00:34:44 2008 From: Marc.Jones at AMD.com (Marc Jones) Date: Thu, 07 Feb 2008 16:34:44 -0700 Subject: [coreboot] [patch] [buildrom] pull latest VSA for geode builds Message-ID: <47AB9594.8040001@AMD.com> The Geode tutorial is also up to date with manual build instructions. http://www.coreboot.org/AMD_Geode_Porting_Guide#Manual_build Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: use-uncompressed-vsa.patch URL: From peter at stuge.se Fri Feb 8 00:24:47 2008 From: peter at stuge.se (Peter Stuge) Date: Fri, 8 Feb 2008 00:24:47 +0100 Subject: [coreboot] FIRST LINUX BOOT: v3 on alix1c! In-Reply-To: <20080207202826.GA11434@coresystems.de> References: <13426df10802062252h537d1efdg99f48f1cad448296@mail.gmail.com> <20080207070845.32578.qmail@stuge.se> <13426df10802062346g3d00c2dfu1898100cd122efc4@mail.gmail.com> <20080207202826.GA11434@coresystems.de> Message-ID: <20080207232447.23211.qmail@stuge.se> On Thu, Feb 07, 2008 at 09:28:27PM +0100, Stefan Reinauer wrote: > If not, the default behavior with no constructor defined should be > that the code automatically uses the default device constructor. This makes a lot of sense to me. //Peter From peter at stuge.se Fri Feb 8 00:28:55 2008 From: peter at stuge.se (Peter Stuge) Date: Fri, 8 Feb 2008 00:28:55 +0100 Subject: [coreboot] [Fwd: Re: [patch] Build error with top of tree V2] In-Reply-To: <47AB8D7E.9030500@AMD.com> References: <47AB8D7E.9030500@AMD.com> Message-ID: <20080207232855.24763.qmail@stuge.se> On Thu, Feb 07, 2008 at 04:00:14PM -0700, Marc Jones wrote: > Looking for an ack. I thought I had acked this already. > Cross compile flags were missing for ar to create coreboot.a. > > Signed-off-by: Marc Jones Acked-by: Peter Stuge > Index: coreboot-v2/src/config/Config.lb > =================================================================== > --- coreboot-v2.orig/src/config/Config.lb 2008-02-06 10:17:43.000000000 -0700 > +++ coreboot-v2/src/config/Config.lb 2008-02-06 10:17:22.000000000 -0700 > @@ -35,7 +35,7 @@ > makerule coreboot.a > depends "$(OBJECTS)" > action "rm -f coreboot.a" > - action "ar cr coreboot.a $(OBJECTS)" > + action "$(CROSS_COMPILE)ar cr coreboot.a $(OBJECTS)" > end > > From info at coresystems.de Fri Feb 8 00:43:41 2008 From: info at coresystems.de (coreboot information) Date: Fri, 08 Feb 2008 00:43:41 +0100 Subject: [coreboot] r3095 build service Message-ID: Dear coreboot readers! This is the automated build check service of coreboot. The developer "myles" checked in revision 3095 to the coreboot source repository and caused the following changes: Change Log: This is a trivial patch. I missed one of the ROM names when I converted them to coreboot.rom Signed-off-by: Myles Watson Acked-by: Myles Watson Build Log: Compilation of amd:serengeti_cheetah_fam10 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3095&device=serengeti_cheetah_fam10&vendor=amd If something broke during this checkin please be a pain in myles's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system From rminnich at gmail.com Fri Feb 8 01:04:27 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 7 Feb 2008 16:04:27 -0800 Subject: [coreboot] FIRST LINUX BOOT: v3 on alix1c! In-Reply-To: <20080207202826.GA11434@coresystems.de> References: <13426df10802062252h537d1efdg99f48f1cad448296@mail.gmail.com> <20080207070845.32578.qmail@stuge.se> <13426df10802062346g3d00c2dfu1898100cd122efc4@mail.gmail.com> <20080207202826.GA11434@coresystems.de> Message-ID: <13426df10802071604k1d5e6158g229ce5e18ee53079@mail.gmail.com> On Feb 7, 2008 12:28 PM, Stefan Reinauer wrote: > Do we ever want to define devices and compile them in that we don't want > to use? That's what I can't figure out. I can't recall why that test is there. ron From stepan at coresystems.de Fri Feb 8 01:15:45 2008 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 08 Feb 2008 01:15:45 +0100 Subject: [coreboot] FIRST LINUX BOOT: v3 on alix1c! In-Reply-To: <13426df10802071604k1d5e6158g229ce5e18ee53079@mail.gmail.com> References: <13426df10802062252h537d1efdg99f48f1cad448296@mail.gmail.com> <20080207070845.32578.qmail@stuge.se> <13426df10802062346g3d00c2dfu1898100cd122efc4@mail.gmail.com> <20080207202826.GA11434@coresystems.de> <13426df10802071604k1d5e6158g229ce5e18ee53079@mail.gmail.com> Message-ID: <47AB9F31.6090702@coresystems.de> ron minnich wrote: > On Feb 7, 2008 12:28 PM, Stefan Reinauer wrote: > > >> Do we ever want to define devices and compile them in that we don't want >> to use? >> > > > That's what I can't figure out. I can't recall why that test is there. > That code was heavily restructured. Lets kick the test and use the default constructor. If that doesnt work out we can always go back. If we have to do those excessive add of standard behavior orgies, something must be wrong, so we won't break something that is not broken ;-) -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From c-d.hailfinger.devel.2006 at gmx.net Fri Feb 8 01:19:54 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 08 Feb 2008 01:19:54 +0100 Subject: [coreboot] [patch] [buildrom] pull latest VSA for geode builds In-Reply-To: <47AB9594.8040001@AMD.com> References: <47AB9594.8040001@AMD.com> Message-ID: <47ABA02A.5060907@gmx.net> On 08.02.2008 00:34, Marc Jones wrote: > The Geode tutorial is also up to date with manual build instructions. > http://www.coreboot.org/AMD_Geode_Porting_Guide#Manual_build > Marc > > Update buildrom to pull latest interrupt free VSA from the AMD website, nrv2b compress it, pad to 36K it, and append to Geode coreboot images. > > Signed-off-by: Jordan Crouse > Signed-off-by: Marc Jones > > Index: buildrom/packages/coreboot-v2/geode.inc > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ buildrom/packages/coreboot-v2/geode.inc 2008-02-06 15:39:42.000000000 -0700 > @@ -0,0 +1,19 @@ > +VSA_URL=http://www.amd.com/files/connectivitysolutions/geode/geode_lx/ > +VSA_URL=http://forsteri/~marcj/ > Sure about the second VSA_URL above? > +VSA_BIN=amd_vsa_lx_1.01.bin > + > +CBV2_VSA=lx_vsa.36k.bin > +CBV2_VSA_SIZE=36864 Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Fri Feb 8 01:33:02 2008 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 08 Feb 2008 01:33:02 +0100 Subject: [coreboot] goal for march summit In-Reply-To: <13426df10802070806r3d43aa8bl4621ad1549ba06c6@mail.gmail.com> References: <13426df10802012049t54d8f799p7b0c7b99f315583@mail.gmail.com> <20080204205410.GC9492@cosmic.amd.com> <13426df10802060406p3e4e955cyeb7f3209fd2f967@mail.gmail.com> <20080206210753.GA19217@cosmic.amd.com> <13426df10802061328p2b007ea8s530aa6bd8699d2c9@mail.gmail.com> <20080206222246.GC20367@cosmic.amd.com> <13426df10802061423r3afb3b69pbfc1f8231a35699f@mail.gmail.com> <47AB12E4.40802@gmx.net> <47AB2C13.90501@AMD.com> <13426df10802070806r3d43aa8bl4621ad1549ba06c6@mail.gmail.com> Message-ID: <47ABA33E.4020406@gmx.net> On 07.02.2008 17:06, ron minnich wrote: > If we want real hardware it is probably going to have to be a cheap via board? > I guess so. We may need to find another person willing to get a VIA NDA in case we run into trouble and/or we want to rewrite the v2 code when porting it to v3. Regards, Carl-Daniel From corey.osgood at gmail.com Fri Feb 8 01:47:18 2008 From: corey.osgood at gmail.com (Corey Osgood) Date: Thu, 7 Feb 2008 19:47:18 -0500 Subject: [coreboot] goal for march summit In-Reply-To: <47ABA33E.4020406@gmx.net> References: <13426df10802012049t54d8f799p7b0c7b99f315583@mail.gmail.com> <13426df10802060406p3e4e955cyeb7f3209fd2f967@mail.gmail.com> <20080206210753.GA19217@cosmic.amd.com> <13426df10802061328p2b007ea8s530aa6bd8699d2c9@mail.gmail.com> <20080206222246.GC20367@cosmic.amd.com> <13426df10802061423r3afb3b69pbfc1f8231a35699f@mail.gmail.com> <47AB12E4.40802@gmx.net> <47AB2C13.90501@AMD.com> <13426df10802070806r3d43aa8bl4621ad1549ba06c6@mail.gmail.com> <47ABA33E.4020406@gmx.net> Message-ID: On Feb 7, 2008 7:33 PM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006 at gmx.net> wrote: > On 07.02.2008 17:06, ron minnich wrote: > > If we want real hardware it is probably going to have to be a cheap via > board? > > > > I guess so. We may need to find another person willing to get a VIA NDA > in case we run into trouble and/or we want to rewrite the v2 code when > porting it to v3. > > Regards, > Carl-Daniel I'd be willing, if they'd ever get back to me. -Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Fri Feb 8 02:02:04 2008 From: rminnich at gmail.com (ron minnich) Date: Thu, 7 Feb 2008 17:02:04 -0800 Subject: [coreboot] make LAR parse .bss segments and create LAR