[coreboot] HPET MSI/FSB on AMD 16h
I am using a PCEngines APU2 system and I noticed that its HPET timers do not advertise FSB (MSI) interrupt delivery capability. That is despite the fact that BKDG for family 16h models 30h - 3Fh says that those capability bits are hardwired to 1. I took a quick look through coreboot sources (APU2 firmware is coreboot) and noticed something interesting. It seems that the repository includes code for AGESA (src/vendorcode/amd/agesa) and there I see that the MSI capability can be turned on / off via a special PM I/O register. It appears that HPET MSI support is disabled on some platforms by default: src/vendorcode/amd/agesa/f15tn/Proc/Fch/Interface/Family/Hudson2/EnvDefHudson2.c: TRUE,// HpetMsiDis src/vendorcode/amd/agesa/f16kb/Proc/Fch/Interface/Family/Yangtze/EnvDefYangtze.c: TRUE,// HpetMsiDis Does anyone know what is a reason for that? Are there any hardware errata related to that feature? I think that MSI delivery is more efficient and "sexy" than the traditional delivery via IO-APIC (although everything is integrated). Also, is there a way to override that default in a mainboard configuration? Thank you. -- Andriy Gapon ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
Re: [coreboot] shrdw question
On 29/03/2018 21:25, ron minnich wrote: > I have the following code: > > movl $0x12345678, %eax > movl $0x, %ebx > movb $0x10, %cl > shrdw %ebx, %eax > > quiz: what's the value of %ax after this instruction? Given 'w', correct notation for the last instruction should be shrdw %bx, %ax ? I believe that the original value of %ax would be shifted out and replaced with the value of %bx. So, 0xbbbb. Same as %bx. -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD platform: IO-APIC => Local APIC delivery modes
On 10/10/2016 21:59, Rudolf Marek wrote: > Hi Andriy, > >> An example: >> $ ioapic_wr 3 0xff000300 > > I tried with minicom and IRQ 4, and I can confirm that NMI is delivered only > when using the redirection entry above. The one 0x0400 does > nothing > in my case. I tested on AMD Hudson chipset, It would be interesting to test 0x00...300 and 0xff...400 just for completeness. > I had to add #include to > have the proper type defines under Linux. I'll also add this one just in case. > The NMI arrived to all CPUs, Linux said: > > Oct 10 20:51:08 ruik kernel: [ 891.596625] Uhhuh. NMI received for unknown > reason 31 on CPU 2. > Oct 10 20:51:08 ruik kernel: [ 891.596631] Uhhuh. NMI received for unknown > reason 31 on CPU 1. > Oct 10 20:51:08 ruik kernel: [ 891.596633] Uhhuh. NMI received for unknown > reason 31 on CPU 0. > Oct 10 20:51:08 ruik kernel: [ 891.596636] Uhhuh. NMI received for unknown > reason 31 on CPU 3. > Oct 10 20:51:08 ruik kernel: [ 891.596638] Do you have a strange power saving > mode enabled? > Oct 10 20:51:08 ruik kernel: [ 891.596639] Do you have a strange power saving > mode enabled? > Oct 10 20:51:08 ruik kernel: [ 891.596644] Do you have a strange power saving > mode enabled? > Oct 10 20:51:08 ruik kernel: [ 891.596646] Dazed and confused, but trying to > continue > Oct 10 20:51:08 ruik kernel: [ 891.596648] Dazed and confused, but trying to > continue > Oct 10 20:51:08 ruik kernel: [ 891.596652] Dazed and confused, but trying to > continue > Oct 10 20:51:08 ruik kernel: [ 891.59] Do you have a strange power saving > mode enabled? > Oct 10 20:51:08 ruik kernel: [ 891.596670] Dazed and confused, but trying to > continue > > I can try to contact Mr. AMD ask them to at least publish new errata versions. That would be great. I am really curious about the official clarification on the issue. Maybe there is a configuration bit that they forgot to set or something like that. I found a really old document about AMD-8131 chipset which seems like something that later morphed into the APIC component of the southbrdiges and in that document they discuss APIC -> HT mapping quite extensively. I wonder what went wrong later on. In this copy of the document it's on page 67 http://www.tautec-electronics.de/Datenblaetter/Schaltkreise/AMD8131.pdf -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD platform: IO-APIC => Local APIC delivery modes
On 08/10/2016 23:57, Rudolf Marek wrote: > I did the HPET NMI generator on Intel PCH, it works fine. I just fill the MSI > addr/data in a way that it was delivering NMI to certain CPU - physical > delivery > to a CPU with a certain ID. > > If this does not work on AMD, perhaps there is some problem with chipset > configuration. Please check the HT specs and try to sort out the MT3 setup. > I've just got this working on my AMD hardware too. I had to use the same HT encoding for the Delivery Mode / Message Type bits as with IO-APIC. -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD platform: IO-APIC => Local APIC delivery modes
On 09/10/2016 13:02, Andriy Gapon wrote: > On 08/10/2016 23:04, Andriy Gapon wrote: >> On 08/10/2016 20:35, Rudolf Marek wrote: >>> Andriy Gapon wrote: > [...] >>> This has to do about Hypertransportspecification. Please have a look to >>> >>> Table 103. x86 Interrupt Request Packet Format (HT spec version 1.1) >>> There is this MT3 explained. >> >> Thank you for the pointer! I will have a look. >> >>>> I went over the BKDG and SB7x0 documentation (RRG, RPG) and only PCI_Reg >>>> 62h of >>>> device 20 function 0 in SB7x0 caught my eye. Namely, K8_INTR, MT3_Set and >>>> MT3_Auto bits. They all are about K8 INTR [NMI] message. >>>> On my system the register is set to 0x24, that is K8_INTR is set, but >>>> MT3_Set >>>> and MT3_Auto are not... >>> >>> So, this just helps to generate right format to HT bus... maybe the CPU is >>> confused... and you will need to change it. Now it should be more clear >>> what the >>> MT3 means. >> >> I will try to map those to the HT protocol details. > > The HyperTransport Specification is very enlightening. > Thank you, Rudolf, for setting me on that path! > I used version 3.0 found here http://www.hypertransport.org/ht-3-0-link-spec. > Especially useful is Appendix F.1 Interrupts, particularly tables 106 and 108. Apologies, the above references are actually for the HT 1.0 document. In the HT 3.0 document the tables are 150 and 152. > The document and some experiments allowed me to understand one important > thing. > Both PIC and APIC interrupts are delivered over HyperTransport. There are no > special physical wires for the PIC interrupts. > > Figuring out the MT3_Set and MT3_Auto bits was very easy. > The bits affect only the PIC interrupts, they have no effect on the I/O APIC > interrupts. > On the SB700+Athlon system those bits are unset and that means that MT[3] of > the > HyperTransport messages (Message Type, bit 3) is zero. In turn, that means > that > the PIC interrupts are delivered as normal ExtINT interrupts as if they were > coming from the I/O APIC. That explains why LintEn has the effect on the PIC > interrupts. > The bits are named slightly differently in the SB800 documentation. They are > Mts_set and Mts_auto and they belong to PMIO PM_Reg 08h. > But they have exactly the same function. > On the SB850+Phenom system Mts_set is 1 and Mts_auto is 0. So, MT[3] is one > for > the PIC interrupt messages. That means that their type is 'Legacy PIC ExtInt > (LINT0)', not the regular ExtInt. That's why LintEn does not affect them. > > So, the above explains everything I see with the PIC interrupts, but does not > explain the problems with the I/O APIC interrupts. And here I made a wild > guess... and it seems to be correct. > > I set Delivery Mode in the redirection table to the HyperTransport defined NMI > message type, 0_011, and it worked! > This is the redirection entry I used: 0xff000300 (note that the > destination is set to the broadcast address as required by Table 106). More tests show that individual APIC IDs can also be used in addition to the broadcast ID. > There is an apparent bug in the AMD southbridges. Despite what the APIC > specification says and what Table 108 of the HyperTransport 3.0 specification > reiterates, the delivery mode bits are copied as-is into the HyperTransport > messages. That's not a problem for fixed, lowest priority and SMI interrupts > where the bits are exactly the same. But the APIC NMI mode gets interpreted > as > INIT which explains the problems I was with it. Also, it seems that APIC > ExtINT > mode (111) is an undefined value for the HyperTransport message type, but > messages with that type get treated as normal interrupts. > > Rudolf, thank you very much again! > I hope that the findings will help other people too. > -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD platform: IO-APIC => Local APIC delivery modes
On 08/10/2016 23:04, Andriy Gapon wrote: > On 08/10/2016 20:35, Rudolf Marek wrote: >> Andriy Gapon wrote: [...] >> This has to do about Hypertransportspecification. Please have a look to >> >> Table 103. x86 Interrupt Request Packet Format (HT spec version 1.1) >> There is this MT3 explained. > > Thank you for the pointer! I will have a look. > >>> I went over the BKDG and SB7x0 documentation (RRG, RPG) and only PCI_Reg >>> 62h of >>> device 20 function 0 in SB7x0 caught my eye. Namely, K8_INTR, MT3_Set and >>> MT3_Auto bits. They all are about K8 INTR [NMI] message. >>> On my system the register is set to 0x24, that is K8_INTR is set, but >>> MT3_Set >>> and MT3_Auto are not... >> >> So, this just helps to generate right format to HT bus... maybe the CPU is >> confused... and you will need to change it. Now it should be more clear what >> the >> MT3 means. > > I will try to map those to the HT protocol details. The HyperTransport Specification is very enlightening. Thank you, Rudolf, for setting me on that path! I used version 3.0 found here http://www.hypertransport.org/ht-3-0-link-spec. Especially useful is Appendix F.1 Interrupts, particularly tables 106 and 108. The document and some experiments allowed me to understand one important thing. Both PIC and APIC interrupts are delivered over HyperTransport. There are no special physical wires for the PIC interrupts. Figuring out the MT3_Set and MT3_Auto bits was very easy. The bits affect only the PIC interrupts, they have no effect on the I/O APIC interrupts. On the SB700+Athlon system those bits are unset and that means that MT[3] of the HyperTransport messages (Message Type, bit 3) is zero. In turn, that means that the PIC interrupts are delivered as normal ExtINT interrupts as if they were coming from the I/O APIC. That explains why LintEn has the effect on the PIC interrupts. The bits are named slightly differently in the SB800 documentation. They are Mts_set and Mts_auto and they belong to PMIO PM_Reg 08h. But they have exactly the same function. On the SB850+Phenom system Mts_set is 1 and Mts_auto is 0. So, MT[3] is one for the PIC interrupt messages. That means that their type is 'Legacy PIC ExtInt (LINT0)', not the regular ExtInt. That's why LintEn does not affect them. So, the above explains everything I see with the PIC interrupts, but does not explain the problems with the I/O APIC interrupts. And here I made a wild guess... and it seems to be correct. I set Delivery Mode in the redirection table to the HyperTransport defined NMI message type, 0_011, and it worked! This is the redirection entry I used: 0xff000300 (note that the destination is set to the broadcast address as required by Table 106). There is an apparent bug in the AMD southbridges. Despite what the APIC specification says and what Table 108 of the HyperTransport 3.0 specification reiterates, the delivery mode bits are copied as-is into the HyperTransport messages. That's not a problem for fixed, lowest priority and SMI interrupts where the bits are exactly the same. But the APIC NMI mode gets interpreted as INIT which explains the problems I was with it. Also, it seems that APIC ExtINT mode (111) is an undefined value for the HyperTransport message type, but messages with that type get treated as normal interrupts. Rudolf, thank you very much again! I hope that the findings will help other people too. -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD platform: IO-APIC => Local APIC delivery modes
On 08/10/2016 20:35, Rudolf Marek wrote: > Hi Andriy, > >> First, the hardware that I am talking about: it's a typical consumer system >> with >> a Family 10h AMD processor, SB700 southbridge and 780G northbridge: >> http://www.gigabyte.com/products/product-page.aspx?pid=3004#sp > > What superIO is it? On that system it's ITE IT8718F. On the other system that I tested (see my other post) it's IT8721F. >> What I want to achieve is to get an interrupt generated by a SuperIO chip >> (external to the chipset) delivered to a CPU as a NMI. > > You could set a bit which enables NMI when IOCHKCK# is asserted. But, I guess > the SuperIO wont generate it for you - unless you have own gadget. Yes. Also, to answer another of your questions, I want to have an interrupt generated by the SuperIO's watchdog timer be delivered as an NMI. >> So, the first thing I tried is simply to set the NMI delivery mode for the >> pin. >> Unfortunately, that does not work, the system gets reset as soon as the >> interrupt is generated. >> So, my first question is: can that be made to work at all? > > Did you set vector to 0x0 ? Maybe it did not like the rest of the fields? I double-checked, all the bits seem to be correct as only the NMI mode bit has to be set, all other have to be or can be zeroes: 0x0400 (using 64-bit format for two 32-bit registers of the redirection table entry). >> So, I decided to not give up and to try to use the legacy interrupt mode to >> get >> what I want. I think that that's how Linux NMI watchdog driver used to work. >> So, I programmed LINT0 and LINT1 for NMI delivery mode (on all cores, all >> two of >> them), enabled legacy PIC (I guess that it's built into the chipset) and made >> sure that the interrupt is unmasked. But absolutely nothing happened when >> the >> interrupt is generated. >> From this I concluded that the PIC is not connected to the CPUs. > > The PIC is "connected" to CPU via LINT0 if set to extINT. Or through the entry > in IOAPIC. Well, I was talking about the physical level (or something close to it). Anyway, as it turned out I was wrong and the PIC is actually connected both to the LINT0 pin of the CPU and pin 0 of the I/O APIC. >> I think that this is an interesting discovery: PIC's configuration affects >> how >> the IO-APIC communicates to the Local APICs. > > This has to do about Hypertransportspecification. Please have a look to > > Table 103. x86 Interrupt Request Packet Format (HT spec version 1.1) > There is this MT3 explained. Thank you for the pointer! I will have a look. >> I went over the BKDG and SB7x0 documentation (RRG, RPG) and only PCI_Reg 62h >> of >> device 20 function 0 in SB7x0 caught my eye. Namely, K8_INTR, MT3_Set and >> MT3_Auto bits. They all are about K8 INTR [NMI] message. >> On my system the register is set to 0x24, that is K8_INTR is set, but MT3_Set >> and MT3_Auto are not... > > So, this just helps to generate right format to HT bus... maybe the CPU is > confused... and you will need to change it. Now it should be more clear what > the > MT3 means. I will try to map those to the HT protocol details. >> In the coreboot source code I see that the register is set up with exactly >> the >> same value in src/southbridge/amd/sb700/early_setup.c. >> And, for what it's worth, bit 5 (0x20 mask) is documented as "reserved". > > Could be that it is something unrelated - Maybe leftover from SB600, where the > bit is documented. It has to do something with SMI on USB. Okay. >> I hope that this was not a boring read. > > Nope, it is was quite interesting. Why you need to trigger NMI by superIO? > Maybe there is other solution. I think at least some silicon revisions of > SB700 > had some magic bit which was triggering NMI if written. As I wrote above, I want to create another variant of an "NMI watchdog". Watchdog timers in ITE SuperIOs are able to either reset a system or to generate an interrupt. I want to use the latter option to get the NMI. > You can perhaps generate NMI using MSI/MSI-X or HPET (i tried with this) Actually, I tried that with SB700 and SB850 HPETs. I configured a timer for an FSB (=MSI, I guess) interrupt mode and set the delivery mode in the same fashion as I would for an MSI interrupt. The results were exactly the same as what I am getting when setting IO-APIC redirection mode to NMI. If you were able to get this stuff to work on a similar hardware, then I would appreciate your advice. Thank you very much! -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] patch for superiotool/freebsd
on 27/09/2012 01:01 Bernhard Urban said the following: hey Andriy, thanks for your patch! please submit it via gerrit, see http://www.coreboot.org/Git It seems that the patch got committed while I was waiting for a weekend to come to set up myself with gerrit. Which I did anyways :-) Thank you very much! On Wed, Sep 26, 2012 at 10:49 PM, Andriy Gapon a...@freebsd.org wrote: Guys, It's been quite a while since I worked with any coreboot tools. I see that a lot has changed... I am posting a trivial FreeBSD-related patch here, but I am ready to follow the proper way if you give me a kick towards it :-) Thank you! diff --git a/util/superiotool/Makefile b/util/superiotool/Makefile index 41625d3..2388f4e 100644 --- a/util/superiotool/Makefile +++ b/util/superiotool/Makefile @@ -41,7 +41,7 @@ LIBS = -framework IOKit -framework DirectHW -lpci -lz endif ifeq ($(OS_ARCH), FreeBSD) CFLAGS = -O2 -Wall -Werror -Wstrict-prototypes -Wundef -Wstrict-aliasing \ - -Werror-implicit-function-declaration -ansi $(SVNDEF) \ + -Werror-implicit-function-declaration -ansi $(VERSION) \ -I/usr/local/include LDFLAGS += -L/usr/local/lib LIBS = -lz -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] patch for superiotool/freebsd
Guys, It's been quite a while since I worked with any coreboot tools. I see that a lot has changed... I am posting a trivial FreeBSD-related patch here, but I am ready to follow the proper way if you give me a kick towards it :-) Thank you! diff --git a/util/superiotool/Makefile b/util/superiotool/Makefile index 41625d3..2388f4e 100644 --- a/util/superiotool/Makefile +++ b/util/superiotool/Makefile @@ -41,7 +41,7 @@ LIBS = -framework IOKit -framework DirectHW -lpci -lz endif ifeq ($(OS_ARCH), FreeBSD) CFLAGS = -O2 -Wall -Werror -Wstrict-prototypes -Wundef -Wstrict-aliasing \ - -Werror-implicit-function-declaration -ansi $(SVNDEF) \ + -Werror-implicit-function-declaration -ansi $(VERSION) \ -I/usr/local/include LDFLAGS += -L/usr/local/lib LIBS = -lz -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SB800/RS880 docs
on 06/06/2011 19:49 Marc Jones said the following: Updated. Thank you. That page is a very convenient place to get links to the specs. BTW, looks like SB800 BDG was missed: support.amd.com/us/Embedded_TechDocs/45483.pdf On Sun, Jun 5, 2011 at 3:26 AM, Andriy Gapon a...@icyb.net.ua wrote: Looks like the docs page http://www.coreboot.org/Datasheets#AMD_4 can be updated: http://support.amd.com/us/psearch/Pages/psearch.aspx?type=2.2%3B2.3product=2.7.4.3.5.3.2contentType=Tech+Doc+Embeddedostype=keywords=items=20 -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] SB800/RS880 docs
Looks like the docs page http://www.coreboot.org/Datasheets#AMD_4 can be updated: http://support.amd.com/us/psearch/Pages/psearch.aspx?type=2.2%3B2.3product=2.7.4.3.5.3.2contentType=Tech+Doc+Embeddedostype=keywords=items=20 -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] update superiotool support for FreeBSD
on 17/10/2010 19:37 Idwer Vollering said the following: Update support for FreeBSD. Signed-off-by: Idwer Vollering vid...@gmail.com mailto:vid...@gmail.com BTW: http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/superiotool/ -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] superiotool NetBSD support
on 17/10/2010 17:43 Peter Lemenkov said the following: 2010/10/17 Jonathan A. Kollasch jakll...@kollasch.net: Provide for I/O space access on NetBSD. It seems that it's time for flashrom maintainers to reconsider their opinion regarding autotools since the complexity and number of nesting levels of ifdefs within flashrom sources becomes more and more difficult to read and understand. BTW: http://sourceforge.net/projects/mk-configure/ -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Porting to Asus M4A785-M
Juhana Helovuo said the following: Meanwhile, I added call to it8712f_kill_watchdog() , like Rudolf Marek suggested. BTW, if it's not too hard, could you please share what value that register (IT8712F_CONFIG_REG_WATCHDOG) has before being reset to zero in it8712f_kill_watchdog? Thanks! -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] gigabyte dual bios programming
on 15/07/2010 21:09 Carl-Daniel Hailfinger said the following: Did you know that SB700 (and later) has its own Dual BIOS mechanism? If there is interest, I can help with implementing support for that feature in flashrom. Does that mechanism require that flash chips are wired to the south bridge (handled by its SPI controller)? Or is it a more generic mechanism? -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] gigabyte dual bios programming
on 16/07/2010 16:29 Qing Pei Wang said the following: i think the spi chips are wired to both south bridge and super I/O. On my mobo they are definitely wired to Super I/O only. That doesn't preclude, of course, Super I/O being wired to SB :-) -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] gigabyte dual bios programming
on 14/07/2010 23:25 Peter Stuge said the following: Andriy Gapon wrote: In this context I would really appreciate unabridged version of ITE IT8718F-S specification. Maybe you already know this, but I would not expect the superio to be involved very much in the dualbios mechanism - at most an IO pin would be used for the handshake with the patented timer. Still I would like to get the spec. It may also depend on a particular motherboard, chip, etc. Perhaps the patented timer is implemented in Super I/O. At least, we see that some undocumented Super I/O register(s) are used to switch between the flash chips and some other related things. -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] gigabyte dual bios programming
In this context I would really appreciate unabridged version of ITE IT8718F-S specification. If someone could somehow share it, it would be terrific. -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Dualbios on GA-MA770-UD3
on 09/04/2010 19:52 Vadim Girlin said the following: Here is code fragment I mentioned - some bit is set then reset: (Not sure now that this code runs at all) Vadim, cool work! BTW: http://www.rom.by/forum/Gigabyte_DualBIOS :-) -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Dualbios on GA-MA770-UD3
on 09/04/2010 15:42 Carl-Daniel Hailfinger said the following: On 09.04.2010 14:35, Andriy Gapon wrote: on 09/04/2010 15:18 Carl-Daniel Hailfinger said the following: By the way, some of us have good contacts at ITE, so we can ask ITE for details about the undocumented registers. BTW: http://www.flashrom.org/pipermail/flashrom/2009-September/000542.html Doesn't look like anybody showed interest that time. I'm very sorry about that. Your mail is still on my huge TODO list (final university exams are eating up my time). Two weeks from now I'll finally have time to start tackling all flashrom TODOs. No problem, I frequently find myself in the same situation. -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Dualbios on GA-MA770-UD3
on 09/04/2010 15:18 Carl-Daniel Hailfinger said the following: By the way, some of us have good contacts at ITE, so we can ask ITE for details about the undocumented registers. BTW: http://www.flashrom.org/pipermail/flashrom/2009-September/000542.html Doesn't look like anybody showed interest that time. -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] msrtool: freebsd support
on 28/11/2009 07:24 Peter Stuge said the following: Andriy Gapon wrote: Please review the following patch that adds FreeBSD support to msrtool. MSR values are obtained via /dev/cpuctl ioctl interface. Signed-off-by: Andriy Gapon a...@icyb.net.ua I made some small changes, _open() should consider the mode even if RDONLY is all that is used now. Thanks! r4965 Thanks a lot! -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] msrtool: posix-ify configure script
Please review the following patch.
It changes a few bash-specific constructs to more portable syntax specified by
POSIX. After the change the script keeps working with bash interpreter and can
also be interpreted by FreeBSD /bin/sh.
Signed-off-by: Andriy Gapon a...@icyb.net.ua
Index: configure
===
--- configure (revision 4776)
+++ configure (working copy)
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
#
# This file is part of msrtool.
#
@@ -25,7 +25,7 @@
REV=`svnversion -c . 2/dev/null | sed 's,.*:,,' 2/dev/null`
VERSION=${VERSION:-$REV}
-function findprog {
+findprog() {
NPARMS=$#
WHAT=${1}
shift
@@ -41,7 +41,7 @@
while test $i -lt $NPARMS; do
test -z ${1} {
shift
- i=$[$i+1]
+ i=$(($i+1))
continue
}
FILE=`which ${1} 2/dev/null`
@@ -50,7 +50,7 @@
break
}
shift
- i=$[$i+1]
+ i=$(($i+1))
done
test -z ${1} {
echo not found! 12
@@ -62,7 +62,7 @@
exit 0
}
-function trycompile {
+trycompile() {
NPARMS=$#
WHAT=${1}
shift
@@ -84,7 +84,7 @@
exit 0
}
shift
- i=$[$i+1]
+ i=$(($i+1))
done
echo failed! 12
echo 12
@@ -99,7 +99,7 @@
exit 1
}
-function trylink {
+trylink() {
NPARMS=$#
WHAT=${1}
shift
@@ -121,7 +121,7 @@
exit 0
}
shift
- i=$[$i+1]
+ i=$(($i+1))
done
echo failed! 12
echo 12
--
Andriy Gapon
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] msrtool: freebsd support
Please review the following patch that adds FreeBSD support to msrtool.
MSR values are obtained via /dev/cpuctl ioctl interface.
Signed-off-by: Andriy Gapon a...@icyb.net.ua
Index: msrtool.c
===
--- msrtool.c (revision 4776)
+++ msrtool.c (working copy)
@@ -49,6 +49,7 @@
static struct sysdef allsystems[] = {
{ linux, Linux with /dev/cpu/*/msr, linux_probe, linux_open,
linux_close,
linux_rdmsr },
{ darwin, OS X with DirectIO, darwin_probe, darwin_open,
darwin_close,
darwin_rdmsr },
+ { freebsd, FreeBSD with /dev/cpuctl*, freebsd_probe, freebsd_open,
freebsd_close, freebsd_rdmsr },
{ SYSTEM_EOT }
};
Index: Makefile.in
===
--- Makefile.in (revision 4776)
+++ Makefile.in (working copy)
@@ -27,7 +27,7 @@
LDFLAGS = @LDFLAGS@
TARGETS = geodelx.o cs5536.o k8.o
-SYSTEMS = linux.o darwin.o
+SYSTEMS = linux.o darwin.o freebsd.o
OBJS= $(PROGRAM).o msrutils.o sys.o $(SYSTEMS) $(TARGETS)
all: $(PROGRAM)
Index: msrtool.h
===
--- msrtool.h (revision 4776)
+++ msrtool.h (working copy)
@@ -28,6 +28,10 @@
#define __DARWIN__
#include DirectIO/darwinio.h
#endif
+#if defined(__FreeBSD__)
+#include sys/ioctl.h
+#include sys/cpuctl.h
+#endif
#include pci/pci.h
#define HEXCHARS 0123456789abcdefABCDEF
@@ -186,6 +190,12 @@
extern int darwin_close(uint8_t cpu);
extern int darwin_rdmsr(uint8_t cpu, uint32_t addr, struct msr *val);
+/* freebsd.c */
+extern int freebsd_probe(const struct sysdef *system);
+extern int freebsd_open(uint8_t cpu, enum SysModes mode);
+extern int freebsd_close(uint8_t cpu);
+extern int freebsd_rdmsr(uint8_t cpu, uint32_t addr, struct msr *val);
+
/** target externs **/
/* geodelx.c */
Index: freebsd.c
===
--- freebsd.c (revision 0)
+++ freebsd.c (revision 0)
@@ -0,0 +1,96 @@
+/*
+ * This file is part of msrtool.
+ *
+ * Copyright (c) 2009 coresystems GmbH
+ *
+ * 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 sys/types.h
+#include sys/stat.h
+#include fcntl.h
+#include unistd.h
+#include string.h
+#include errno.h
+
+#include msrtool.h
+
+static int msr_fd[MAX_CORES] = {-1, -1, -1, -1, -1, -1, -1, -1};
+
+int freebsd_probe(const struct sysdef *system)
+{
+#ifdef __FreeBSD__
+ struct stat st;
+
+ return stat(/dev/cpuctl0, st) == 0;
+#else
+ return 0;
+#endif
+}
+
+int freebsd_open(uint8_t cpu, enum SysModes mode)
+{
+#ifdef __FreeBSD__
+ char devname[32];
+
+ if (cpu = MAX_CORES)
+ return 0;
+
+ snprintf(devname, sizeof(devname), /dev/cpuctl%u, cpu);
+ msr_fd[cpu] = open(devname, O_RDONLY);
+ if (msr_fd[cpu] 0) {
+ perror(devname);
+ return 0;
+ }
+ return 1;
+#else
+ return 0;
+#endif
+}
+
+int freebsd_close(uint8_t cpu)
+{
+ if (cpu = MAX_CORES)
+ return 0;
+
+ if (msr_fd[cpu] != -1)
+ close(msr_fd[cpu]);
+ msr_fd[cpu] = -1;
+ return 1;
+}
+
+int freebsd_rdmsr(uint8_t cpu, uint32_t addr, struct msr *val)
+{
+#ifdef __FreeBSD__
+ cpuctl_msr_args_t args;
+
+ if (cpu = MAX_CORES)
+ return 0;
+
+ if (msr_fd[cpu] 0)
+ return 0;
+
+ args.msr = addr;
+ if (ioctl(msr_fd[cpu], CPUCTL_RDMSR, args) 0) {
+ perror(CPUCTL_RDMSR);
+ return 0;
+ }
+
+ val-hi = args.data 32;
+ val-lo = args.data 0x;
+ return 1;
+#else
+ return 0;
+#endif
+}
--
Andriy Gapon
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [OT] machine check related to promotion to a large page
Sorry for the offtopic, but I see from time to time technical people from amd.com writing to this list, so I decided to try my luck. I would be very grateful for any help with the following issues. Perhaps, I could be referred to the proper technical contacts. FreeBSD starting with upcoming 8.0 version has transparent support for large pages (superpages in FreeBSD terms). This means that an eligible range of 4KB pages can be promoted to a 4MB page at an opportune moment. The large page can also be broken down into normal pages when needed, of course. Large pages can also be explicitly allocated, but that is beside the point. We seem to have a problem, that is perhaps caused by lack of strictness in our code, that looks to be caused by the mentioned above superpages feature. But the problem manifests itself only on AMD family 10h processors. To be precise, we have reports that family Fh is not affected, all problem reports are for family 10h and we have no positive or negative reports for family 11h. Another mandatory condition for the problem to manifest itself is having machine check enabled by either BIOS or OS. Also, the problem is reported only for long mode. So, the actual problem manifestation is a machine check report about parity error in DC TLB L1. All reporters have confirmed that they don't experience any problems if the superpages feature is turned off. So it seems likely that this machine check report is not indicative of a hardware fault. It looks that the way our code currently works it is possible that we could get into a situation where two TLB entries would exist for the same linear-to-physical translation. One through a large page and another through a normal page. Most likely both should be correct (point to the same physical location). Is it possible that such a situation could lead the integrity checking logic to believe that there is a parity error in TLB? I've searched though the errata for family 10h processors but couldn't find one that would match. Examples of processors affected by the problem (as reported by FreeBSD kernel): 1). CPU: AMD Athlon(tm) II X2 250 Processor (3013.75-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x100f62 Stepping = 2 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x802009SSE3,MON,CX16,POPCNT AMD Features=0xee500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x37ffLAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT 2). CPU: Quad-Core AMD Opteron(tm) Processor 2352 (2100.09-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x100f23 Stepping = 3 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x802009SSE3,MON,CX16,POPCNT AMD Features=0xee400800SYSCALL,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x7ffLAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS This is how FreeBSD MCA code reported the machine check: MCA: CPU 5 UNCOR PCC OVER DTLB L1 error MCA: Address 0x80e5c8000 My guess of possible FreeBSD code issue: 4K mappings are not flushed when corresponding PDE is updated from pointing to PT to pointing to a 2M page. Thank you. -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] BIOS RAM in AMD SB7XX southbridges ?
on 28/10/2009 06:55 Darmawan Salihun said the following: On 10/28/09, Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net wrote: On 27.10.2009 14:06, Darmawan Salihun wrote: What is the BIOS RAM in AMD SB7XX used for? Is it to buffer the BIOS contents from SPI flash chip prior to execution of the very first instruction? No. I recall that it's impossible to execute code directly in an SPI chip. Yes, but the chipset takes care of the SPI command interface and presents the contents of the SPI chip nicely memory mapped to the CPU, so the CPU can execute the ROM contents directly. I see. So, there must be some sort of independent microcontroller/microprocessor in the southbridge that fetches the contents of the SPI chip and present it in a memory-mapped way to the CPU. Probably this is how the BIOS RAM is used by the internal microcontroller/microprocessor in the southbridge. No, I think. BIOS RAM is some sort of scratch-pad memory for arbitrary use by software. I suspect this because an ex-intel engineer that I spoke to, told me that back then he was using ARM7TDMI to do the job of presenting the BIOS contents in a memory-mapped way to the CPU. These days, the function must've been integrated in the southbridge as you said. I suspect AMD do the same. Yes, most probably. But BIOS RAM has nothing to do with this. Chipset directs memory access for certain range(s) to embedded SPI controller which in turn translates them into appropriate SPI commands. -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] ECC with AMD Family 10h processors
Are there any guidelines or code for setting up DRAM ECC mode in memory controller of AMD Family 10h processors? I mean beyond what BKDG has to say on that. Thank you! -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [flashrom] Transaction Error with opcode 0x03 failed...
Yu Ning, thank you very much again. BTW, an unrelated question: Generating OPCODES... done does this line mean that no opcodes at all were generated? I wonder why that could be. -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [flashrom] Transaction Error with opcode 0x03 failed...
on 06/05/2009 18:41 FENG Yu Ning said the following: Look at FREG2. 0x5C: 0x023f000b (FREG2) The value 0x0(23f)0(00b) means, the area in the flash chip from 0x00(00b)000 to 0x00(23f)fff belongs to (F)lash (REG)ion (2), which stores data for the Management Engine. That is, flashrom runs into error when it is trying to read FREG2. Now look at FRAP. 0x50: 0x1a1b (FRAP) The least significant byte '1b' indicates which regions software can read. Expand it to binary, 00011011. That means the software can read FREG0, FREG1, FREG3 and FREG4 but not FREG2. That is why flashrom runs into error at offset 45056. Yu Ning, thank you for the very enlightening explanation! I wonder what the following means (on my machine): 0x54: 0x (FREG0) Flash region of size 0? BTW: 0x50: 0x0a0b (FRAP) -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] flashrom on intel dg33tl
on 30/01/2009 02:39 Carl-Daniel Hailfinger said the following: On 29.01.2009 13:45, Andriy Gapon wrote: Sorry for top posting. flashrom stopped working for me on intel DG33TL motherboard since I reported success. In the quoted older message below you can find what flashrom reported then, here is what it reports now: Ah yes. You're hitting the problem that the read opcode is prohibited by the BIOS. Older flashrom versions ignored that and simply read the memory-mapped contents near the top of the address space. These dumps were incomplete, though, so in a way claiming to have dumped the ROM was a bug. The new code tries to get it right and hits the roadblock erected by the BIOS. There's nothing we can do to fix it unless we discover a bug in the hardware (or implement the descriptor mode driver for ICH). Thank you for the information. I noticed that the image that older flashrom produced was less than half a size of Intel's rescue image. I think that it still should be possible to unlock the hardware via software (or something like that), because Intel has a tool that updates BIOS from within OS (you guessed it right - available only for Windows). -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] flashrom on intel dg33tl
on 30/01/2009 11:43 Stefan Reinauer said the following: On 29.01.2009 13:45 Uhr, Andriy Gapon wrote: Sorry for top posting. flashrom stopped working for me on intel DG33TL motherboard since I reported success. In the quoted older message below you can find what flashrom reported then, here is what it reports now: What did you change? Update your BIOS? Update flashrom? Only flashrom was updated. I think that Carl-Daniel has already explained the situation to me. -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] flashrom on intel dg33tl
: probe_jedec: id1 0xff, id2 0xff, id1 parity violation Probing for SyncMOS S29C51004T, 512 KB: probe_jedec: id1 0xff, id2 0xff, id1 parity violation Probing for Winbond W25x10, 128 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Winbond W25x20, 256 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Winbond W25x40, 512 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Winbond W25x80, 1024 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Winbond W29C011, 128 KB: probe_jedec: id1 0xff, id2 0xff, id1 parity violation Probing for Winbond W29C020C, 256 KB: probe_jedec: id1 0xff, id2 0xff, id1 parity violation Probing for Winbond W29C040P, 512 KB: probe_jedec: id1 0xff, id2 0xff, id1 parity violation Probing for Winbond W29EE011, 128 KB: === Probing disabled for Winbond W29EE011 because the probing sequence puts the AMIC A49LF040A in a funky state. Use 'flashrom -c W29EE011' if you have a board with this chip. === Probing for Winbond W39V040A, 512 KB: probe_jedec: id1 0xff, id2 0xff, id1 parity violation Probing for Winbond W39V040B, 512 KB: probe_jedec: id1 0xff, id2 0xff, id1 parity violation Probing for Winbond W39V040C, 512 KB: probe_w39v040c: id1 0xff, id2 0xff, id1 parity violation Probing for Winbond W39V040FA, 512 KB: probe_jedec: id1 0xff, id2 0xff, id1 parity violation Probing for Winbond W39V080A, 1024 KB: probe_jedec: id1 0xff, id2 0xff, id1 parity violation Probing for Winbond W49F002U, 256 KB: probe_jedec: id1 0xff, id2 0xff, id1 parity violation Probing for Winbond W49V002A, 256 KB: probe_jedec: id1 0xff, id2 0xff, id1 parity violation Probing for Winbond W49V002FA, 256 KB: probe_jedec: id1 0xff, id2 0xff, id1 parity violation Probing for Winbond W39V080FA, 1024 KB: probe_winbond_fwhub: vid 0xff, did 0xff Probing for Winbond W39V080FA (dual mode), 512 KB: probe_winbond_fwhub: vid 0xff, did 0xff Probing for Atmel unknown Atmel SPI chip, 0 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for EON unknown EON SPI chip, 0 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Macronix unknown Macronix SPI chip, 0 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for PMC unknown PMC SPI chip, 0 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for SST unknown SST SPI chip, 0 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for ST unknown ST SPI chip, 0 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 === This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE Please email a report to flash...@coreboot.org if any of the above operations work correctly for you with this flash part. Please include the full output from the program, including chipset found. Thank you for your help! === Reading flash... ich_spi_read_page: offset=0, number=256, buf=0x800e0 Invalid OPCODE 0x03 Error readingdone. Exit 255 on 14/11/2008 17:46 Andriy Gapon said the following: on 14/11/2008 17:19 Carl-Daniel Hailfinger said the following: On 14.11.2008 15:38, Andriy Gapon wrote: Below is output of flashrom -V. It couldn't find the flash chip. This is ICH9 (G33) chipset. There is one WARNING and one FAILED messages. A few hours ago I posted a patch to recognize your flash chip. The subject was: [coreboot] [PATCH] flashrom: Implement probe support for Atmel chips Please try it and tell us if it works. It seems to have worked and produced 1MByte file on read! $ ~/devel/flashrom/flashrom -V -r -f bios.dump Calibrating delay loop... 260M loops per second, 100 myus = 199 us. OK. No coreboot table found. Found chipset Intel ICH9R, enabling flash write... BIOS Lock Enable: enabled, BIOS Write Enable: disabled, BIOS_CNTL is 0xa tried to set 0xdc to 0xb on Intel ICH9R failed (WARNING ONLY) Root Complex Register Block address = 0xfed1c000 GCS = 0xc01444: BIOS Interface Lock-Down: disabled, BOOT BIOS Straps: 0x1 (SPI) Top Swap : not enabled SPIBAR = 0xfed1c000 + 0x3800 0x00: 0x0035 (HSFS) FLOCKDN 1, FDV 1, FDOPSS 0, SCIP 0, BERASE 0, AEL 0, FCERR 0, FDONE 0 0x50: 0x0a0b (FRAP) BMWAG 0, BMRAG 0, BRWA 10, BRRA 11 0x54: 0x (FREG0) 0x58: 0x00ff0035 (FREG1) 0x5C: 0x00340003 (FREG2) 0x60: 0x00020001 (FREG3) 0x64: 0x0fff (FREG4) 0x74: 0x (PR0) 0x78: 0x (PR1) 0x7C: 0x (PR2) 0x80: 0x (PR3) 0x84: 0x (PR4) 0xB0: 0x (FDOC) SPI Read Configuration: prefetching enabled, caching enabled, FAILED! Probing for AMD Am29F002(N)BB, 256 KB: probe_jedec: id1 0xf9, id2 0x63, id1 parity violation Probing for AMD Am29F002(N)BT, 256 KB: probe_jedec: id1 0xf9, id2 0x63, id1 parity violation Probing for AMD Am29F016D, 2048 KB: probe_29f040b: id1 0xff, id2 0xff Probing for AMD Am29F040B, 512 KB: probe_29f040b: id1 0x3, id2
Re: [coreboot] [PATCH] inteltool: i965, i975, ICH8M and Darwin support.
on 04/12/2008 01:56 Stefan Reinauer said the following: Uwe Hermann wrote: ... On Sun, Nov 30, 2008 at 10:07:55PM +0100, Stefan Reinauer wrote: ... + /* Reading this register will hang a macbook pro */ + printf(pmbase+0x%04x: 0x\n, i); Any idea why? Hardware problem or OS problem? Does Linux on Apple hardware have the same issue? If yes, the #ifdef DARWIN check may not be correct/complete. I am not sure yet. There is no Linux on that box. It might even be a generic ICH8 thing. Time will show and bring a patch when we find out. From publicly available ICH9 spec (I guess ICH8 is the same here): quote LV2 — Level 2 Register I/O Address: PMBASE + 14h ... Reads to this register return all 0s, writes to this register have no effect. Reads to this register generate a “enter a level 2 power state” (C2) to the clock control logic. This will cause the STPCLK# signal to go active, and stay active until a break event occurs. Throttling (due either to THTL_EN or FORCE_THTL) will be ignored. ... NOTE: This register should not be used by IA-64 processors or systems with more than 1 logical processor, unless appropriate semaphoring software has been put in place to ensure that all threads/processors are ready for the C2 state when the read to this register occurs. /quote The subsequent byte registers are LV3, LV4, LV5 and for mobile version LV6 intended for entering C3, C4, C5 and C6 states. -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Darwin support
on 04/12/2008 11:59 Stefan Reinauer said the following: Peter Stuge wrote: Stefan Reinauer wrote: While the above always works in the default case and in the case that pciutils' PREFIX was just /usr, one might say the right way to do this is by looking for pciutils on the system, ie with autoconf. But that's outside of the scope of this patch. Does the msrtool configure script run well on Darwin? Only a very quick test: ./configure -n searching for compiler (gcc cc icc)... ./configure: line 28: seq: command not found using in PATH -n searching for install (install ginstall)... ./configure: line 28: seq: command not found using in PATH configured using the following settings: VERSION=3766 CC= CFLAGS= -Os -Wall -Werror LDFLAGS= INSTALL= PREFIX=/usr/local -n creating Makefile... done I tried it on FreeBSD with the following tweaks: replace seq with gseq and explicitly use /usr/local/bin/bash to execute configure (it's not in POSIX shell syntax): $ bash ./configure searching for compiler (gcc cc icc)... using /usr/bin/gcc in PATH searching for install (install ginstall)... using /usr/bin/install in PATH finding CFLAGS for libpci (from pciutils)... using: -Os -Wall -Werror -I/usr/local/include finding LDFLAGS for libpci (from pciutils)... using: -L/usr/local/lib -lpci -lz configured using the following settings: VERSION=3770M CC=gcc CFLAGS= -Os -Wall -Werror -I/usr/local/include LDFLAGS= -L/usr/local/lib -lpci -lz INSTALL=install PREFIX=/usr/local creating Makefile... done -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] flashrom on intel dg33tl
: probe_jedec: id1 0xff, id2 0xff, id1 parity violation Probing for SyncMOS S29C31004T, 512 KB: probe_jedec: id1 0x3, id2 0x55, id1 parity violation Probing for SyncMOS S29C51001T, 128 KB: probe_jedec: id1 0x32, id2 0x0 Probing for SyncMOS S29C51002T, 256 KB: probe_jedec: id1 0xf9, id2 0x63, id1 parity violation Probing for SyncMOS S29C51004T, 512 KB: probe_jedec: id1 0x3, id2 0x55, id1 parity violation Probing for Winbond W25x10, 128 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Winbond W25x20, 256 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Winbond W25x40, 512 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Winbond W25x80, 1024 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Winbond W29C011, 128 KB: probe_jedec: id1 0x32, id2 0x0 Probing for Winbond W29C020C, 256 KB: probe_jedec: id1 0xf9, id2 0x63, id1 parity violation Probing for Winbond W29C040P, 512 KB: probe_jedec: id1 0x3, id2 0x55, id1 parity violation Probing for Winbond W29EE011, 128 KB: === Probing disabled for Winbond W29EE011 because the probing sequence puts the AMIC A49LF040A in a funky state. Use 'flashrom -c W29EE011' if you have a board with this chip. === Probing for Winbond W39V040A, 512 KB: probe_jedec: id1 0x3, id2 0x55, id1 parity violation Probing for Winbond W39V040B, 512 KB: probe_jedec: id1 0x3, id2 0x55, id1 parity violation Probing for Winbond W39V040C, 512 KB: probe_w39v040c: id1 0x3, id2 0x55, id1 parity violation Probing for Winbond W39V040FA, 512 KB: probe_jedec: id1 0x3, id2 0x55, id1 parity violation Probing for Winbond W39V080A, 1024 KB: probe_jedec: id1 0xff, id2 0xff, id1 parity violation Probing for Winbond W49F002U, 256 KB: probe_jedec: id1 0xf9, id2 0x63, id1 parity violation Probing for Winbond W49V002A, 256 KB: probe_jedec: id1 0xf9, id2 0x63, id1 parity violation Probing for Winbond W49V002FA, 256 KB: probe_jedec: id1 0xf9, id2 0x63, id1 parity violation Probing for Winbond W39V080FA, 1024 KB: probe_winbond_fwhub: vid 0xff, did 0xff Probing for Winbond W39V080FA (dual mode), 512 KB: probe_winbond_fwhub: vid 0x3, did 0x55 Probing for EON unknown EON SPI chip, 0 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Macronix unknown Macronix SPI chip, 0 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for PMC unknown PMC SPI chip, 0 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for SST unknown SST SPI chip, 0 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for ST unknown ST SPI chip, 0 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 No EEPROM/flash device found. If you know which flash chip you have, and if this version of flashrom supports a similar flash chip, you can try to force read your chip. Run: flashrom -f -r -c similar_supported_flash_chip filename Note: flashrom can never write when the flash chip isn't found automatically. -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] flashrom on intel dg33tl
on 14/11/2008 17:19 Carl-Daniel Hailfinger said the following: On 14.11.2008 15:38, Andriy Gapon wrote: Below is output of flashrom -V. It couldn't find the flash chip. This is ICH9 (G33) chipset. There is one WARNING and one FAILED messages. A few hours ago I posted a patch to recognize your flash chip. The subject was: [coreboot] [PATCH] flashrom: Implement probe support for Atmel chips Please try it and tell us if it works. It seems to have worked and produced 1MByte file on read! $ ~/devel/flashrom/flashrom -V -r -f bios.dump Calibrating delay loop... 260M loops per second, 100 myus = 199 us. OK. No coreboot table found. Found chipset Intel ICH9R, enabling flash write... BIOS Lock Enable: enabled, BIOS Write Enable: disabled, BIOS_CNTL is 0xa tried to set 0xdc to 0xb on Intel ICH9R failed (WARNING ONLY) Root Complex Register Block address = 0xfed1c000 GCS = 0xc01444: BIOS Interface Lock-Down: disabled, BOOT BIOS Straps: 0x1 (SPI) Top Swap : not enabled SPIBAR = 0xfed1c000 + 0x3800 0x00: 0x0035 (HSFS) FLOCKDN 1, FDV 1, FDOPSS 0, SCIP 0, BERASE 0, AEL 0, FCERR 0, FDONE 0 0x50: 0x0a0b (FRAP) BMWAG 0, BMRAG 0, BRWA 10, BRRA 11 0x54: 0x (FREG0) 0x58: 0x00ff0035 (FREG1) 0x5C: 0x00340003 (FREG2) 0x60: 0x00020001 (FREG3) 0x64: 0x0fff (FREG4) 0x74: 0x (PR0) 0x78: 0x (PR1) 0x7C: 0x (PR2) 0x80: 0x (PR3) 0x84: 0x (PR4) 0xB0: 0x (FDOC) SPI Read Configuration: prefetching enabled, caching enabled, FAILED! Probing for AMD Am29F002(N)BB, 256 KB: probe_jedec: id1 0xf9, id2 0x63, id1 parity violation Probing for AMD Am29F002(N)BT, 256 KB: probe_jedec: id1 0xf9, id2 0x63, id1 parity violation Probing for AMD Am29F016D, 2048 KB: probe_29f040b: id1 0xff, id2 0xff Probing for AMD Am29F040B, 512 KB: probe_29f040b: id1 0x3, id2 0x55 Probing for AMD Am29LV040B, 512 KB: probe_29f040b: id1 0x3, id2 0x55 Probing for ASD AE49F2008, 256 KB: probe_jedec: id1 0xf9, id2 0x63, id1 parity violation Probing for Atmel AT25DF021, 256 KB: Programming OPCODES... done RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Atmel AT25DF041A, 512 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Atmel AT25DF081, 1024 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Atmel AT25DF161, 2048 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Atmel AT25DF321, 4096 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Atmel AT25DF321A, 4096 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Atmel AT25DF641, 8192 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Atmel AT25F512B, 64 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Atmel AT25FS010, 128 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Atmel AT25FS040, 512 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Atmel AT26DF041, 512 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Atmel AT26DF081A, 1024 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Opcode 5 not found. run OPCODE 0x05 failed Chip status register is 00 Found chip Atmel AT26DF081A (1024 KB) at physical address 0xfff0. Probing for Atmel AT26DF161, 2048 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Atmel AT26DF161A, 2048 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Atmel AT26F004, 512 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Atmel AT29C020, 256 KB: probe_jedec: id1 0xf9, id2 0x63, id1 parity violation Probing for Atmel AT29C040A, 512 KB: probe_jedec: id1 0x3, id2 0x55, id1 parity violation Probing for Atmel AT45CS1282, 16896 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Atmel AT45DB011D, 128 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Atmel AT45DB021D, 256 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Atmel AT45DB041D, 512 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Atmel AT45DB081D, 1024 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Atmel AT45DB161D, 2048 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Atmel AT45DB321C, 4224 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Atmel AT45DB321D, 4096 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Atmel AT45DB642D, 8192 KB: RDID returned 1f 45 01. probe_spi_rdid_generic: id1 0x1f, id2 0x4501 Probing for Atmel AT49F002(N), 256 KB: probe_jedec: id1 0xf9, id2 0x63, id1 parity violation
Re: [coreboot] romcc -mcpu=p3?
on 30/10/2008 11:16 Andriy Gapon said the following: It seems that romcc with -mcpu=p3 -O produces incorrect code for cpu/x86/16bit/reset16.inc. -mpcu=p2 -O does work fine. I will try to provide more hard data later but it looks like the following code is compiled into an (slightly) incorrect jump which breaks things terribly, of course. .section .reset .code16 .globl reset_vector reset_vector: .byte 0xe9 .int _start - ( . + 2 ) . = 0x8; .code32 Jump seems to be off by -4 bytes. My original analysis was quite incorrect. I did thorougher analysis now and here are the main differences. Indeed there are some changes in offsets but the jumps seem to be correct: --- fallback-p2/coreboot.map2008-10-30 23:29:14.0 +0200 +++ fallback-p3/coreboot.map2008-10-30 23:39:44.0 +0200 @@ -112,10 +112,10 @@ 4000 A HEAP_SIZE 4000 A _RAMBASE 4000 A _iseg -b889 A _binary_coreboot_ram_rom_size -b890 A _start_offset -b8c8 A gdtptr16_offset -f889 A _eiseg +b887 A _binary_coreboot_ram_rom_size +b88c A _start_offset +b8c4 A gdtptr16_offset +f887 A _eiseg 0001 A ROM_IMAGE_SIZE 0001 A XIP_ROM_SIZE 0001c200 A TTYS0_BAUD I wonder where these small 2-4 byte shifts came from. but this is not important. What is much more important is that all mmN registers were replaced with xmmN registers. So here are qemu execution logs for comparison (best done side-by-side). With cpu=p2: IN: 0xfff0: jmp0xb890 IN: 0xb890: cli 0xb891: mov%eax,%ebp 0xb894: xor%eax,%eax 0xb897: mov%eax,%cr3 IN: 0xb89a: mov%cs,%ax 0xb89c: shl$0x4,%ax 0xb89f: mov$0xb8c8,%bx 0xb8a2: sub%ax,%bx 0xb8a4: lgdtl %cs:(%bx) 0xb8a9: mov%cr0,%eax 0xb8ac: and$0x7ffaffd1,%eax 0xb8b2: or $0x6001,%eax 0xb8b8: mov%eax,%cr0 IN: 0xb8bb: mov%ebp,%eax 0xb8be: ljmpl $0x8,$0xb8f7 IN: 0xb8f7: mov%eax,%ebp 0xb8f9: mov$0x10,%al 0xb8fb: out%al,$0x80 0xb8fd: mov$0x10,%ax 0xb901: mov%eax,%ds outb: 0080 10 dma: extra page register write addr=0x80 data=0x10 ioport80_write 0X10 IN: 0xb903: mov%eax,%es IN: 0xb905: mov%eax,%ss IN: 0xb907: mov%eax,%fs IN: 0xb909: mov%eax,%gs 0xb90b: mov%ebp,%eax 0xb90d: jmp0xb919 IN: 0xb919: movd %eax,%mm0 0xb91c: mov$0xd,%al . . . With cpu=p3: IN: 0xfff0: jmp0xb88c IN: 0xb88c: cli 0xb88d: mov%eax,%ebp 0xb890: xor%eax,%eax 0xb893: mov%eax,%cr3 IN: 0xb896: mov%cs,%ax 0xb898: shl$0x4,%ax 0xb89b: mov$0xb8c4,%bx 0xb89e: sub%ax,%bx 0xb8a0: lgdtl %cs:(%bx) 0xb8a5: mov%cr0,%eax 0xb8a8: and$0x7ffaffd1,%eax 0xb8ae: or $0x6001,%eax 0xb8b4: mov%eax,%cr0 IN: 0xb8b7: mov%ebp,%eax 0xb8ba: ljmpl $0x8,$0xb8f3 IN: 0xb8f3: mov%eax,%ebp 0xb8f5: mov$0x10,%al 0xb8f7: out%al,$0x80 0xb8f9: mov$0x10,%ax 0xb8fd: mov%eax,%ds outb: 0080 10 dma: extra page register write addr=0x80 data=0x10 ioport80_write 0X10 IN: 0xb8ff: mov%eax,%es IN: 0xb901: mov%eax,%ss IN: 0xb903: mov%eax,%fs IN: 0xb905: mov%eax,%gs 0xb907: mov%ebp,%eax 0xb909: jmp0xb915 IN: 0xb915: movd %eax,%xmm0 qemu: fatal: triple fault EAX= EBX=b8c4 ECX= EDX=0673 ESI= EDI= EBP= ESP= EIP=b915 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00cf9300 CS =0008 00cf9b00 SS =0010 00cf9300 DS =0010 00cf9300 FS =0010 00cf9300 GS =0010 00cf9300 LDT= 8200 TR = 8b00 GDT= b8cc 0017 IDT= CR0=6011 CR2= CR3= CR4= CCS= CCD=6011 CCO=LOGICL FCW=037f FSW= [ST=0] FTW=00 MXCSR=1f80 FPR0= FPR1= FPR2= FPR3= FPR4= FPR5= FPR6= FPR7= XMM00= XMM01= XMM02= XMM03= XMM04= XMM05= XMM06= XMM07= So the logs
Re: [coreboot] support for w83977ef in coreboot-v2
Add support for W83977EF Super-IO chip.
This is based on w83977tf code and on earlier support for this chip in
superiotool.
Signed-off-by: Andriy Gapon [EMAIL PROTECTED]
---
As trivial change as it was I still managed to make a couple of mistakes
(not all files renamed, one old resource line not removed).
Now this is compile tested with slightly modified msi/ms6147.
on 28/10/2008 23:16 Andriy Gapon said the following:
Add (basic) support for W83977EF Super-IO chip.
This is based on w83977tf code and on earlier support for this chip in
superiotool.
Signed-off-by: Andriy Gapon [EMAIL PROTECTED]
---
This was done by copy'n'paste of w83977tf, substitution of w83977tf with
w83977ef, and then some chip-specific changes in the list of logical
devices in w83977tf.h and their resources in superio.c:pnp_dev_info.
The code was not tested yet on real hardware (and there is no mobo in
the src to use it yet), but I believe that it should work - based on
triviality of the changes and hardware specs.
As my changes were fairly minimal I left all copyrights as they were in
w83977tf code.
--
Andriy Gapon
Index: src/superio/winbond/w83977ef/w83977ef_early_serial.c
===
--- src/superio/winbond/w83977ef/w83977ef_early_serial.c(revision 0)
+++ src/superio/winbond/w83977ef/w83977ef_early_serial.c(revision 0)
@@ -0,0 +1,25 @@
+#include arch/romcc_io.h
+#include w83977ef.h
+
+static inline void pnp_enter_ext_func_mode(device_t dev)
+{
+ unsigned int port = dev 8;
+ outb(0x87, port);
+ outb(0x87, port);
+}
+
+static void pnp_exit_ext_func_mode(device_t dev)
+{
+ unsigned int port = dev 8;
+ outb(0xaa, port);
+}
+
+static void w83977ef_enable_serial(device_t dev, unsigned int iobase)
+{
+ pnp_enter_ext_func_mode(dev);
+ pnp_set_logical_device(dev);
+ pnp_set_enable(dev, 0);
+ pnp_set_iobase(dev, PNP_IDX_IO0, iobase);
+ pnp_set_enable(dev, 1);
+ pnp_exit_ext_func_mode(dev);
+}
Index: src/superio/winbond/w83977ef/Config.lb
===
--- src/superio/winbond/w83977ef/Config.lb (revision 0)
+++ src/superio/winbond/w83977ef/Config.lb (revision 0)
@@ -0,0 +1,2 @@
+config chip.h
+object superio.o
Index: src/superio/winbond/w83977ef/superio.c
===
--- src/superio/winbond/w83977ef/superio.c (revision 0)
+++ src/superio/winbond/w83977ef/superio.c (revision 0)
@@ -0,0 +1,117 @@
+/* Copyright 2000 AG Electronics Ltd. */
+/* Copyright 2003-2004 Linux Networx */
+/* Copyright 2004 Tyan
+ By LYH change from PC87360 */
+/* This code is distributed without warranty under the GPL v2 (see COPYING) */
+
+/* 2006-4-24
+ * Adapted for the w83977 by rsmith [EMAIL PROTECTED]
+ * This is mostly just a search and replace on the part type
+ * TODO: Actually see if all the sub functionis exist and are
+ * setup correctly.
+ */
+
+#include arch/io.h
+#include device/device.h
+#include device/pnp.h
+#include console/console.h
+#include string.h
+#include bitops.h
+#include uart8250.h
+#include pc80/keyboard.h
+#include stdlib.h
+#include chip.h
+#include w83977ef.h
+
+static void w83977ef_enter_ext_func_mode(device_t dev)
+{
+outb(0x87, dev-path.u.pnp.port);
+outb(0x87, dev-path.u.pnp.port);
+}
+static void w83977ef_exit_ext_func_mode(device_t dev)
+{
+outb(0xaa, dev-path.u.pnp.port);
+}
+
+static void w83977ef_init(device_t dev)
+{
+ struct superio_winbond_w83977ef_config *conf;
+ struct resource *res0, *res1;
+ /* Wishlist handle well known programming interfaces more
+* generically.
+*/
+ if (!dev-enabled) {
+ return;
+ }
+ conf = dev-chip_info;
+ switch(dev-path.u.pnp.device) {
+ case W83977EF_SP1:
+ res0 = find_resource(dev, PNP_IDX_IO0);
+ init_uart8250(res0-base, conf-com1);
+ break;
+ case W83977EF_SP2:
+ res0 = find_resource(dev, PNP_IDX_IO0);
+ init_uart8250(res0-base, conf-com2);
+ break;
+ case W83977EF_KBC:
+ res0 = find_resource(dev, PNP_IDX_IO0);
+ res1 = find_resource(dev, PNP_IDX_IO1);
+ init_pc_keyboard(res0-base, res1-base, conf-keyboard);
+ break;
+ }
+}
+
+static void w83977ef_set_resources(device_t dev)
+{
+ w83977ef_enter_ext_func_mode(dev);
+ pnp_set_resources(dev);
+ w83977ef_exit_ext_func_mode(dev);
+}
+
+static void w83977ef_enable_resources(device_t dev)
+{
+ w83977ef_enter_ext_func_mode(dev);
+ pnp_enable_resources(dev);
+ w83977ef_exit_ext_func_mode(dev);
+}
+
+static void w83977ef_enable(device_t dev)
+{
+ w83977ef_enter_ext_func_mode(dev);
+ pnp_enable(dev);
+ w83977ef_exit_ext_func_mode(dev
[coreboot] romcc -mcpu=p3?
It seems that romcc with -mcpu=p3 -O produces incorrect code for cpu/x86/16bit/reset16.inc. -mpcu=p2 -O does work fine. I will try to provide more hard data later but it looks like the following code is compiled into an (slightly) incorrect jump which breaks things terribly, of course. .section .reset .code16 .globl reset_vector reset_vector: .byte 0xe9 .int _start - ( . + 2 ) . = 0x8; .code32 Jump seems to be off by -4 bytes. -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] coreboot.v2+seabios on 440bx: option roms not found
In northbridge/intel/i440bx/raminit.c:sdram_set_spd_registers all PAM registers are programmed for RAM R/W access (0x33). When SeaBIOS searches for option ROMs (including VGA ROM) it doesn't do anything about PAM, so it sees empty memory instead of the ROMs. I am not sure what is the best solution here. It is debatable how coreboot should set PAM register, and it is not right to make SeaBIOS too hardware dependent. Maybe coreboot could somehow export functions for setting access to option ROM space (aka legacy memory segments) and SeaBIOS could call them. -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot.v2+seabios on 440bx: option roms not found
on 30/10/2008 16:34 Myles Watson said the following: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andriy Gapon Sent: Thursday, October 30, 2008 8:25 AM To: Coreboot Subject: [coreboot] coreboot.v2+seabios on 440bx: option roms not found In northbridge/intel/i440bx/raminit.c:sdram_set_spd_registers all PAM registers are programmed for RAM R/W access (0x33). When SeaBIOS searches for option ROMs (including VGA ROM) it doesn't do anything about PAM, so it sees empty memory instead of the ROMs. I am not sure what is the best solution here. It is debatable how coreboot should set PAM register, and it is not right to make SeaBIOS too hardware dependent. Maybe coreboot could somehow export functions for setting access to option ROM space (aka legacy memory segments) and SeaBIOS could call them. I think SeaBIOS expects Coreboot to copy the option ROM to 0xc in RAM. That way SeaBIOS gets to stay hardware agnostic. Makes sense! But it doesn't look like this does actually happen (by default). I am playing with msi/ms6147 target (under heavily tweaked qemu). -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot.v2+seabios on 440bx: option roms not found
on 30/10/2008 16:52 Myles Watson said the following: -Original Message- From: Andriy Gapon [mailto:[EMAIL PROTECTED] Sent: Thursday, October 30, 2008 8:43 AM To: Myles Watson Cc: 'Coreboot' Subject: Re: [coreboot] coreboot.v2+seabios on 440bx: option roms not found on 30/10/2008 16:34 Myles Watson said the following: -Original Message- From: [EMAIL PROTECTED] [mailto:coreboot- [EMAIL PROTECTED] On Behalf Of Andriy Gapon Sent: Thursday, October 30, 2008 8:25 AM To: Coreboot Subject: [coreboot] coreboot.v2+seabios on 440bx: option roms not found In northbridge/intel/i440bx/raminit.c:sdram_set_spd_registers all PAM registers are programmed for RAM R/W access (0x33). When SeaBIOS searches for option ROMs (including VGA ROM) it doesn't do anything about PAM, so it sees empty memory instead of the ROMs. I am not sure what is the best solution here. It is debatable how coreboot should set PAM register, and it is not right to make SeaBIOS too hardware dependent. Maybe coreboot could somehow export functions for setting access to option ROM space (aka legacy memory segments) and SeaBIOS could call them. I think SeaBIOS expects Coreboot to copy the option ROM to 0xc in RAM. That way SeaBIOS gets to stay hardware agnostic. Makes sense! But it doesn't look like this does actually happen (by default). I am playing with msi/ms6147 target (under heavily tweaked qemu). You're right. It doesn't happen by default. Kevin sent a simple patch to the list, which I can't find right now :( Basically you tell coreboot to run the ROM, but comment out the execution right after the copy. Let me know if you can't find it, and I'll try to help you dig. I found a post where Kevin talks about this but no patch. I am thinking about this approach for 440BX: set PAM registers to read from ROM, write to RAM mode, copy the whole range onto itself, set PAM register to R/W RAM mode. I am not sure if this better be done for all legacy segments (0xC - 0xF range) or only for option ROM segments (0xC - 0xD range) excluding BIOS Area and BIOS Extension segments. P.S. This approach won't work in stock qemu because of incorrect implementation (absence, actually) of emulation of this mixed PAM mode. -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] port nvramtool to FreeBSD
on 30/10/2008 17:46 Uwe Hermann said the following:
On Wed, Oct 29, 2008 at 03:14:46PM +0200, Andriy Gapon wrote:
Allow nvramtool to build and work on FreeBSD.
Signed-off-by: Andriy Gapon [EMAIL PROTECTED]
Thanks, r3709, with some changes though.
Thanks a lot!
The patch you posted was breaking the build on Linux for me.
Index: cmos_lowlevel.c
===
--- cmos_lowlevel.c (revision 3704)
+++ cmos_lowlevel.c (working copy)
@@ -28,7 +28,15 @@
* 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
\*/
+#if defined(__GLIBC__)
#include sys/io.h
+#endif
This seemed to cause trouble here, I fixed it by putting sys/io.h
into the '#else' part of the 'defined(__FreeBSD__)' code in common.h.
This builds fine for me now, but please check that it also still works
on FreeBSD, just in case.
Yes, FreeBSD build is still fine.
Sorry for the mistakes, thank you for catching and fixing them.
Index: common.h
===
--- common.h (revision 3704)
+++ common.h (working copy)
@@ -43,6 +43,25 @@
#include string.h
#include ctype.h
+#if defined(__FreeBSD__)
+#include sys/types.h
+#include machine/cpufunc.h
+#define OUTB(x, y) do { u_int tmp = (y); outb(tmp, (x)); } while (0)
+#define OUTW(x, y) do { u_int tmp = (y); outw(tmp, (x)); } while (0)
+#define OUTL(x, y) do { u_int tmp = (y); outl(tmp, (x)); } while (0)
+#define INB(x) __extension__ ({ u_int tmp = (x); inb(tmp); })
+#define INW(x) __extension__ ({ u_int tmp = (x); inw(tmp); })
+#define INL(x) __extension__ ({ u_int tmp = (x); inl(tmp); })
+#else
+#define OUTB OUTB
outb
+#define OUTW outw
+#define OUTL outl
+#define INB INB
^^^
inb
+#define INW inw
+#define INL inl
+#endif
+
+
#define FALSE 0
#define TRUE 1
Uwe.
--
Andriy Gapon
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] nvramtool: chipset enable ? [Was: piix4: cmos memory bank 2]
Maybe nvramtool should have some mechanism to enable access to extended CMOS similarly how flashrom enables access to BIOS memory? E.g.: $ pciconf -r -b pci0:0:7:0 0xcb 21 $ ./nvramtool -x | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | 0010 | 00 74 00 02 0f 80 02 c0 ff 00 00 7a ff ff 00 00 | .t.z 0020 | 00 00 00 00 3f 00 00 00 00 00 00 00 ff 00 06 7c | ?..| 0030 | c0 ff 20 80 ff ff ff ff 80 ff ff 0f b2 d1 e9 11 | .. . 0040 | ff 29 ad 3b dc 88 88 bf 05 9b 6a c1 06 00 ff fe | .).;..j. 0050 | e4 98 aa f3 0c 00 07 ff ff d7 ff ff ff 59 00 00 | .Y.. 0060 | e0 38 60 17 fe 70 ff 00 00 00 00 00 00 00 ff 00 | .8`..p.. 0070 | 00 00 00 00 00 00 00 ff 00 00 ff ff ff 1a d7 b0 | 0080 | 40 34 13 02 12 17 04 29 10 08 29 42 00 80 00 00 | @4.)..)B 0090 | 00 74 00 02 0f 80 02 c0 ff 00 00 7a ff ff 00 00 | .t.z 00a0 | 00 00 00 00 3f 00 00 00 00 00 00 00 ff 00 06 7c | ?..| 00b0 | c0 ff 20 80 ff ff ff ff 80 ff ff 0f b2 d1 e9 11 | .. . 00c0 | ff 29 ad 3b dc 88 88 bf 05 9b 6a c1 06 00 ff fe | .).;..j. 00d0 | e4 98 aa f3 0c 00 07 ff ff d7 ff ff ff 59 00 00 | .Y.. 00e0 | e0 38 60 17 fe 70 ff 00 00 00 00 00 00 00 ff 00 | .8`..p.. 00f0 | 00 00 00 00 00 00 00 ff 00 00 ff ff ff 1a d7 b0 | $ pciconf -w -b pci0:0:7:0 0xcb 0x25 $ pciconf -r -b pci0:0:7:0 0xcb 25 $ ./nvramtool -x | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | 0010 | 00 74 00 02 0f 80 02 c0 ff 00 00 7a ff ff 00 00 | .t.z 0020 | 00 00 00 00 3f 00 00 00 00 00 00 00 ff 00 06 7c | ?..| 0030 | c0 ff 20 80 ff ff ff ff 80 ff ff 0f b2 d1 e9 11 | .. . 0040 | ff 29 ad 3b dc 88 88 bf 05 9b 6a c1 06 00 ff fe | .).;..j. 0050 | e4 98 aa f3 0c 00 07 ff ff d7 ff ff ff 59 00 00 | .Y.. 0060 | e0 38 60 17 fe 70 ff 00 00 00 00 00 00 00 ff 00 | .8`..p.. 0070 | 00 00 00 00 00 00 00 ff 00 00 ff ff ff 1a d7 b0 | 0080 | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | 0090 | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | 00a0 | aa 04 ff ff ff ff ff 83 06 ff ff ff ff ff ff ff | 00b0 | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | 00c0 | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | 00d0 | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | 00e0 | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | 00f0 | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | BTW, this was done on FreeBSD, expect a port patch soon :-) on 24/10/2008 18:53 Andriy Gapon said the following: Was the following a revelation only to me or is it a generally obscure knowledge? PIIX4 documentation says that bit 2 of PCI config register 0xCB (of function 0) enables access to CMOS memory bank2 via IO ports 0x72 and 0x73 similarly to regular CMOS memory access via 0x70/0x71. I tested this on my 440BX-based system and this does indeed work: $ od -t xC extcmos.img 000ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff * 040aa 04 ff ff ff ff ff 83 06 ff ff ff ff ff ff ff 060ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff * 200 Most registers are 0xff, but several contain some data, e.g. 83 06 seems to be 0x683, ID of my Pentium III CPU. When bit 2 of 0xCB is zero, then 0x72/0x73 ports seem to provide access to regular CMOS just like 0x70/0x71. -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] port nvramtool to FreeBSD
Allow nvramtool to build and work on FreeBSD.
Signed-off-by: Andriy Gapon [EMAIL PROTECTED]
---
Again this is done using the same technique as for flashrom and superiotool.
Tested on FreeBSD 7.
BTW, any news on official release of flashrom?
--
Andriy Gapon
Index: cmos_lowlevel.c
===
--- cmos_lowlevel.c (revision 3704)
+++ cmos_lowlevel.c (working copy)
@@ -28,7 +28,15 @@
* 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
\*/
+#if defined(__GLIBC__)
#include sys/io.h
+#endif
+
+#if defined(__FreeBSD__)
+#include fcntl.h
+#include unistd.h
+#endif
+
#include common.h
#include cmos_lowlevel.h
@@ -176,8 +184,8 @@
port_1 = 0x73;
}
- outb(index, port_0);
- return inb(port_1);
+ OUTB(index, port_0);
+ return INB(port_1);
}
/
@@ -204,8 +212,8 @@
port_1 = 0x73;
}
- outb(index, port_0);
- outb(value, port_1);
+ OUTB(index, port_0);
+ OUTB(value, port_1);
}
/
@@ -248,8 +256,35 @@
* level is therefore somewhat dangerous.
/
void set_iopl (int level)
- { assert((level = 0) (level = 3));
+ {
+#if defined(__FreeBSD__)
+ static int io_fd = -1;
+#endif
+ assert((level = 0) (level = 3));
+
+#if defined(__FreeBSD__)
+ if (level == 0)
+{
+ if (io_fd != -1)
+ {
+ close(io_fd);
+ io_fd = -1;
+ }
+}
+ else
+{
+ if (io_fd == -1)
+ {
+ io_fd = open(/dev/io, O_RDWR);
+ if (io_fd 0)
+ {
+perror(/dev/io);
+exit(1);
+ }
+ }
+}
+#else
if (iopl(level))
{ fprintf(stderr,
%s: iopl() system call failed. You must be root to do
@@ -257,6 +292,7 @@
prog_name);
exit(1);
}
+#endif
}
/
Index: common.h
===
--- common.h(revision 3704)
+++ common.h(working copy)
@@ -43,6 +43,25 @@
#include string.h
#include ctype.h
+#if defined(__FreeBSD__)
+#include sys/types.h
+#include machine/cpufunc.h
+#define OUTB(x, y) do { u_int tmp = (y); outb(tmp, (x)); } while (0)
+#define OUTW(x, y) do { u_int tmp = (y); outw(tmp, (x)); } while (0)
+#define OUTL(x, y) do { u_int tmp = (y); outl(tmp, (x)); } while (0)
+#define INB(x) __extension__ ({ u_int tmp = (x); inb(tmp); })
+#define INW(x) __extension__ ({ u_int tmp = (x); inw(tmp); })
+#define INL(x) __extension__ ({ u_int tmp = (x); inl(tmp); })
+#else
+#define OUTB OUTB
+#define OUTW outw
+#define OUTL outl
+#define INB INB
+#define INW inw
+#define INL inl
+#endif
+
+
#define FALSE 0
#define TRUE 1
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] port superiotool to FreeBSD
allow superiotool to compile and work on FreeBSD
using the same approach as earlier flashrom port
Signed-off-by: Andriy Gapon [EMAIL PROTECTED]
---
This is tested on FreeBSD 7, dump for W83977EF/EG that I sent previously
was obtained using this patch.
It seems that this approach can also be extended to all coreboot (and
utils) code that uses inX/outX (it is quite unfortunate that Linux and
BSD use different order of parameters for outX).
--
Andriy Gapon
Index: winbond.c
===
--- winbond.c (revision 3697)
+++ winbond.c (working copy)
@@ -470,18 +470,18 @@
static void enter_conf_mode_winbond_88(uint16_t port)
{
- outb(0x88, port);
+ OUTB(0x88, port);
}
static void enter_conf_mode_winbond_89(uint16_t port)
{
- outb(0x89, port);
+ OUTB(0x89, port);
}
static void enter_conf_mode_winbond_86(uint16_t port)
{
- outb(0x86, port);
- outb(0x86, port);
+ OUTB(0x86, port);
+ OUTB(0x86, port);
}
static void probe_idregs_winbond_helper(const char *init, uint16_t port)
Index: ite.c
===
--- ite.c (revision 3697)
+++ ite.c (working copy)
@@ -482,10 +482,10 @@
*/
static void enter_conf_mode_ite(uint16_t port)
{
- outb(0x87, port);
- outb(0x01, port);
- outb(0x55, port);
- outb((port == 0x2e) ? 0x55 : 0xaa, port);
+ OUTB(0x87, port);
+ OUTB(0x01, port);
+ OUTB(0x55, port);
+ OUTB((port == 0x2e) ? 0x55 : 0xaa, port);
}
static void exit_conf_mode_ite(uint16_t port)
Index: nsc.c
===
--- nsc.c (revision 3697)
+++ nsc.c (working copy)
@@ -479,21 +479,21 @@
probing_for(NSC, , port);
- outb(CHIP_ID_REG, port);
- if (inb(port) != CHIP_ID_REG) {
+ OUTB(CHIP_ID_REG, port);
+ if (INB(port) != CHIP_ID_REG) {
if (verbose)
printf(NOTFOUND port=0x%02x, port+1=0x%02x\n,
- inb(port), inb(port + 1));
+ INB(port), INB(port + 1));
return;
}
- id = inb(port + 1);
+ id = INB(port + 1);
- outb(CHIP_REV_REG, port);
- if (inb(port) != CHIP_REV_REG) {
+ OUTB(CHIP_REV_REG, port);
+ if (INB(port) != CHIP_REV_REG) {
printf(Warning: Can't get chip revision. Setting to 0xff.\n);
rev = 0xff;
} else {
- rev = inb(port + 1);
+ rev = INB(port + 1);
}
if (superio_unknown(reg_table, id)) {
Index: superiotool.c
===
--- superiotool.c (revision 3697)
+++ superiotool.c (working copy)
@@ -23,6 +23,11 @@
#include superiotool.h
+#if defined(__FreeBSD__)
+#include fcntl.h
+#include unistd.h
+#endif
+
/* Command line options. */
int dump = 0, verbose = 0, extra_dump = 0;
@@ -31,25 +36,25 @@
uint8_t regval(uint16_t port, uint8_t reg)
{
- outb(reg, port);
- return inb(port + ((port == 0x3bd) ? 2 : 1)); /* 0x3bd is special. */
+ OUTB(reg, port);
+ return INB(port + ((port == 0x3bd) ? 2 : 1)); /* 0x3bd is special. */
}
void regwrite(uint16_t port, uint8_t reg, uint8_t val)
{
- outb(reg, port);
- outb(val, port + 1);
+ OUTB(reg, port);
+ OUTB(val, port + 1);
}
void enter_conf_mode_winbond_fintek_ite_8787(uint16_t port)
{
- outb(0x87, port);
- outb(0x87, port);
+ OUTB(0x87, port);
+ OUTB(0x87, port);
}
void exit_conf_mode_winbond_fintek_ite_8787(uint16_t port)
{
- outb(0xaa, port); /* Fintek, Winbond */
+ OUTB(0xaa, port); /* Fintek, Winbond */
regwrite(port, 0x02, 0x02); /* ITE */
}
@@ -204,6 +209,9 @@
int main(int argc, char *argv[])
{
int i, j, opt, option_index;
+#ifdef __FreeBSD__
+ int io_fd;
+#endif
static const struct option long_options[] = {
{dump,no_argument, NULL, 'd'},
@@ -247,8 +255,13 @@
}
}
+#if defined(__FreeBSD__)
+ if ((io_fd = open(/dev/io, O_RDWR)) 0) {
+ perror(/dev/io);
+#else
if (iopl(3) 0) {
perror(iopl);
+#endif
printf(Superiotool must be run as root.\n);
exit(1);
}
@@ -264,5 +277,8 @@
if (!chip_found)
printf(No Super I/O found\n);
+#ifdef __FreeBSD__
+ close(io_fd);
+#endif
return 0;
}
Index: ali.c
===
--- ali.c (revision 3697)
+++ ali.c (working copy)
@@ -60,13 +60,13 @@
static void enter_conf_mode_ali(uint16_t port)
{
- outb(0x51, port);
- outb(0x23, port);
+ OUTB(0x51, port);
+ OUTB(0x23
Re: [coreboot] superiotool: add register definitions for W83627HF
on 20/10/2008 00:06 Uwe Hermann said the following: On Fri, Oct 17, 2008 at 06:26:52PM +0300, Andriy Gapon wrote: Add register definitions for W83627HF based on publicly available specification and local testing. Also tweak a little bit algorithm for (internal) device id calculation: chips from W83627HF/F/HG/G family have id of 0x52 and a multitude of revisions (0x1x, 0x3A, 0x41, maybe more), chips from W83627HF/GF family have the same device id but revisions 0xFx. Signed-off-by: Andriy Gapon [EMAIL PROTECTED] Looks good, thanks! Committed in r3670. Uwe, I've just noticed this and I apologize a lot: it seems that I used W83627HF and W83627HF/GF where I should have used W83977EF W83977EF/EG in the commit message above. Sorry for causing this confusions, maybe it's still possible to fix the commit message. It should have read: Add register definitions for W83977EF based on publicly available specification and local testing. Also tweak a little bit algorithm for (internal) device id calculation: chips from W83627HF/F/HG/G family have id of 0x52 and a multitude of revisions (0x1x, 0x3A, 0x41, maybe more), chips from W83977EF/EG family have the same device id but revisions 0xFx. Signed-off-by: Andriy Gapon [EMAIL PROTECTED] -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] port superiotool to FreeBSD
on 28/10/2008 17:56 Idwer Vollering said the following: 2008/10/28, Andriy Gapon [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: allow superiotool to compile and work on FreeBSD using the same approach as earlier flashrom port Signed-off-by: Andriy Gapon [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] --- This is tested on FreeBSD 7, dump for W83977EF/EG that I sent previously was obtained using this patch. It seems that this approach can also be extended to all coreboot (and utils) code that uses inX/outX (it is quite unfortunate that Linux and BSD use different order of parameters for outX). -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org mailto:coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot Great ! However, you overlooked outb at lines 471 and 475 in ite.c, see my patch. Idwer Oops and thanks! I did 'svn update' but forgot to 'gmake' after that. -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] support for w83977ef in coreboot-v2
Add (basic) support for W83977EF Super-IO chip.
This is based on w83977tf code and on earlier support for this chip in
superiotool.
Signed-off-by: Andriy Gapon [EMAIL PROTECTED]
---
This was done by copy'n'paste of w83977tf, substitution of w83977tf with
w83977ef, and then some chip-specific changes in the list of logical
devices in w83977tf.h and their resources in superio.c:pnp_dev_info.
The code was not tested yet on real hardware (and there is no mobo in
the src to use it yet), but I believe that it should work - based on
triviality of the changes and hardware specs.
As my changes were fairly minimal I left all copyrights as they were in
w83977tf code.
--
Andriy Gapon
Index: src/superio/winbond/w83977ef/Config.lb
===
--- src/superio/winbond/w83977ef/Config.lb (revision 0)
+++ src/superio/winbond/w83977ef/Config.lb (revision 0)
@@ -0,0 +1,2 @@
+config chip.h
+object superio.o
Index: src/superio/winbond/w83977ef/superio.c
===
--- src/superio/winbond/w83977ef/superio.c (revision 0)
+++ src/superio/winbond/w83977ef/superio.c (revision 0)
@@ -0,0 +1,118 @@
+/* Copyright 2000 AG Electronics Ltd. */
+/* Copyright 2003-2004 Linux Networx */
+/* Copyright 2004 Tyan
+ By LYH change from PC87360 */
+/* This code is distributed without warranty under the GPL v2 (see COPYING) */
+
+/* 2006-4-24
+ * Adapted for the w83977 by rsmith [EMAIL PROTECTED]
+ * This is mostly just a search and replace on the part type
+ * TODO: Actually see if all the sub functionis exist and are
+ * setup correctly.
+ */
+
+#include arch/io.h
+#include device/device.h
+#include device/pnp.h
+#include console/console.h
+#include string.h
+#include bitops.h
+#include uart8250.h
+#include pc80/keyboard.h
+#include stdlib.h
+#include chip.h
+#include w83977ef.h
+
+static void w83977ef_enter_ext_func_mode(device_t dev)
+{
+outb(0x87, dev-path.u.pnp.port);
+outb(0x87, dev-path.u.pnp.port);
+}
+static void w83977ef_exit_ext_func_mode(device_t dev)
+{
+outb(0xaa, dev-path.u.pnp.port);
+}
+
+static void w83977ef_init(device_t dev)
+{
+ struct superio_winbond_w83977ef_config *conf;
+ struct resource *res0, *res1;
+ /* Wishlist handle well known programming interfaces more
+* generically.
+*/
+ if (!dev-enabled) {
+ return;
+ }
+ conf = dev-chip_info;
+ switch(dev-path.u.pnp.device) {
+ case W83977EF_SP1:
+ res0 = find_resource(dev, PNP_IDX_IO0);
+ init_uart8250(res0-base, conf-com1);
+ break;
+ case W83977EF_SP2:
+ res0 = find_resource(dev, PNP_IDX_IO0);
+ init_uart8250(res0-base, conf-com2);
+ break;
+ case W83977EF_KBC:
+ res0 = find_resource(dev, PNP_IDX_IO0);
+ res1 = find_resource(dev, PNP_IDX_IO1);
+ init_pc_keyboard(res0-base, res1-base, conf-keyboard);
+ break;
+ }
+}
+
+static void w83977ef_set_resources(device_t dev)
+{
+ w83977ef_enter_ext_func_mode(dev);
+ pnp_set_resources(dev);
+ w83977ef_exit_ext_func_mode(dev);
+}
+
+static void w83977ef_enable_resources(device_t dev)
+{
+ w83977ef_enter_ext_func_mode(dev);
+ pnp_enable_resources(dev);
+ w83977ef_exit_ext_func_mode(dev);
+}
+
+static void w83977ef_enable(device_t dev)
+{
+ w83977ef_enter_ext_func_mode(dev);
+ pnp_enable(dev);
+ w83977ef_exit_ext_func_mode(dev);
+}
+
+
+static struct device_operations ops = {
+ .read_resources = pnp_read_resources,
+ .set_resources= w83977ef_set_resources,
+ .enable_resources = w83977ef_enable_resources,
+ .enable = w83977ef_enable,
+ .init = w83977ef_init,
+};
+
+static struct pnp_info pnp_dev_info[] = {
+{ ops, W83977EF_FDC, PNP_IO0 | PNP_IRQ0 | PNP_DRQ0, { 0x07f8, 0}, },
+{ ops, W83977EF_PP, PNP_IO0 | PNP_IRQ0 | PNP_DRQ0, { 0x07f8, 0}, },
+{ ops, W83977EF_SP1, PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, },
+{ ops, W83977EF_SP2, PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, },
+// No 4 { 0,},
+{ ops, W83977EF_KBC, PNP_IO0 | PNP_IO1 | PNP_IRQ0 | PNP_IRQ1, {
0x7ff, 0 }, { 0x7ff, 0}, },
+// No 6 { 0,},
+{ ops, W83977EF_CIR, PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, },
+{ ops, W83977EF_GPIO1,PNP_IO0 | PNP_IO1 | PNP_IO2 | PNP_IRQ0 |
PNP_IRQ1, { 0x7ff, 0 }, {0x7ff, 0}, { 0x7ff, 0 }, },
+{ ops, W83977EF_GPIO2,PNP_IO0 | PNP_IRQ0 | PNP_IRQ1, { 0x7fe, 0 }, },
+// No 9 { 0,},
+{ ops, W83977EF_ACPI, PNP_IRQ0, },
+};
+
+static void enable_dev(device_t dev)
+{
+ pnp_enable_devices(dev, ops,
+ ARRAY_SIZE(pnp_dev_info), pnp_dev_info);
+}
+
+struct chip_operations superio_winbond_w83977ef_ops = {
+ CHIP_NAME(Winbond
[coreboot] piix4: cmos memory bank 2
Was the following a revelation only to me or is it a generally obscure knowledge? PIIX4 documentation says that bit 2 of PCI config register 0xCB (of function 0) enables access to CMOS memory bank2 via IO ports 0x72 and 0x73 similarly to regular CMOS memory access via 0x70/0x71. I tested this on my 440BX-based system and this does indeed work: $ od -t xC extcmos.img 000ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff * 040aa 04 ff ff ff ff ff 83 06 ff ff ff ff ff ff ff 060ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff * 200 Most registers are 0xff, but several contain some data, e.g. 83 06 seems to be 0x683, ID of my Pentium III CPU. When bit 2 of 0xCB is zero, then 0x72/0x73 ports seem to provide access to regular CMOS just like 0x70/0x71. -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] superiotool: add register definitions for W83627HF
on 20/10/2008 00:06 Uwe Hermann said the following:
On Fri, Oct 17, 2008 at 06:26:52PM +0300, Andriy Gapon wrote:
Add register definitions for W83627HF based on publicly available
specification and local testing.
Also tweak a little bit algorithm for (internal) device id calculation:
chips from W83627HF/F/HG/G family have id of 0x52 and a multitude of
revisions (0x1x, 0x3A, 0x41, maybe more), chips from W83627HF/GF family
have the same device id but revisions 0xFx.
Signed-off-by: Andriy Gapon [EMAIL PROTECTED]
Looks good, thanks! Committed in r3670.
In addition, I've added your name to the list of contributors in the
README,
Uwe, thanks a lot!
and I removed...
Index: winbond.c
===
--- winbond.c (revision 3667)
+++ winbond.c (working copy)
@@ -39,7 +39,46 @@
/* ID and rev[3..0] */
{0x527, W83977CTF, {/* TODO: Not yet in sensors-detect */
{EOT}}},
[...]
+ {0xa, ACPI,
+ /* Note: Datasheet says 0xe2 can't be read/written. */
... this line. It seem to be copy-paste from some other Super I/O, the
datasheet for this one doesn't seem to say that 0xe2 cannot be read/written
anywhere (or at least I didn't find that place).
I was going to do the same but then noticed that this register is just
mentioned in documentation, there is a section and a name for it, but
there is zero description, the section is just empty.
So I kept that line to be on the safe side, but I agree with its removal.
+ {0x30,0x70,0xe0,0xe1,0xe2,0xe3,0xe4,0xe5,0xe6,0xe7,
+0xf0,0xf1,0xf3,0xf4,0xf6,0xf7,0xf9,0xfe,0xff,EOT},
+ {0x00,0x00,0x00,0x00,MISC,MISC,MISC,0x00,0x00,0x00,
+0x00,0x00,0x00,0x00,0x00,0x00,0x00,RSVD,RSVD,EOT}},
Uwe.
--
Andriy Gapon
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] superiotool: add register definitions for W83627HF
Add register definitions for W83627HF based on publicly available
specification and local testing.
Also tweak a little bit algorithm for (internal) device id calculation:
chips from W83627HF/F/HG/G family have id of 0x52 and a multitude of
revisions (0x1x, 0x3A, 0x41, maybe more), chips from W83627HF/GF family
have the same device id but revisions 0xFx.
Signed-off-by: Andriy Gapon [EMAIL PROTECTED]
---
What about this patch (in addition to my previous question/rant)?
Please note that the last line of the patch simply fixes the comment
about internal device id composition (upper half of reg 0x21 is used).
I chose the most conservative way of detecting W83627HF - only if reg
0x21 value matches 0xFx we skip the previous logic and keep using it for
all other revisions.
Here's an output of patched superiotool on my system, Delta MP2-BX-X:
superiotool r3658
Found Winbond W83977EF/EG (id=0x52, rev=0xf4) at 0x3f0
Register dump:
idx 02 20 21 22 23 24 25 26 28 2a 2b 2c 2d 2e 2f
val ff 52 f4 ff fe 84 00 00 00 00 00 00 00 00 ff
def RR 52 NA ff fe MM 00 MM 00 00 00 00 RR RR RR
LDN 0x00 (Floppy)
idx 30 60 61 70 74 f0 f1 f2 f4 f5
val 00 00 00 00 04 0c 00 ff 00 00
def 01 03 f0 06 02 0e 00 ff 00 00
LDN 0x01 (Parallel port)
idx 30 60 61 70 74 f0
val 00 00 00 00 04 00
def 01 03 78 07 04 3f
LDN 0x02 (COM1)
idx 30 60 61 70 f0
val 01 03 f8 04 00
def 01 03 f8 04 00
LDN 0x03 (COM2)
idx 30 60 61 70 f0 f1
val 01 02 e8 03 00 00
def 01 02 f8 03 00 00
LDN 0x05 (Keyboard)
idx 30 60 61 62 63 70 72 f0
val 01 00 60 00 64 01 0c 40
def 01 00 60 00 64 01 0c 83
LDN 0x07 (GPIO 1)
idx 30 60 61 62 63 64 65 70 72 e0 e1 e2 e3 e4 e5 e6 e7 f1
val 01 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 01 00
def 00 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 01 00
LDN 0x08 (GPIO 2)
idx 30 60 61 70 72 e8 e9 ea eb ec ed f0 f1 f2 f3 f4
val 01 00 00 00 00 10 01 01 01 01 08 00 ff 00 00 00
def 00 00 00 00 00 01 01 01 01 01 01 00 RR 00 00 00
LDN 0x0a (ACPI)
idx 30 70 e0 e1 e2 e3 e4 e5 e6 e7 f0 f1 f3 f4 f6 f7 f9 fe ff
val 00 00 00 00 00 00 00 00 00 00 00 8f 30 00 00 00 00 00 00
def 00 00 00 00 MM MM MM 00 00 00 00 00 00 00 00 00 00 RR RR
--
Andriy Gapon
Index: winbond.c
===
--- winbond.c (revision 3667)
+++ winbond.c (working copy)
@@ -39,7 +39,46 @@
/* ID and rev[3..0] */
{0x527, W83977CTF, { /* TODO: Not yet in sensors-detect */
{EOT}}},
- {0x52f, W83977EF/EG, {/* TODO: Not yet in sensors-detect */
+ {0x52f, W83977EF/EG, {
+ {NOLDN, NULL,
+ {0x02,0x20,0x21,0x22,0x23,0x24,0x25,0x26,0x28,0x2a,
+0x2b,0x2c,0x2d,0x2e,0x2f,EOT},
+ {RSVD,0x52,NANA,0xff,0xfe,MISC,0x00,MISC,0x00,0x00,
+0x00,0x00,RSVD,RSVD,RSVD,EOT}},
+ /* Some register defaults depend on the value of PNPCSV. */
+ {0x0, Floppy,
+ {0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,0xf2,0xf4,
+0xf5,EOT},
+ {0x01,0x03,0xf0,0x06,0x02,0x0e,0x00,0xff,0x00,
+0x00,EOT}},
+ {0x1, Parallel port,
+ {0x30,0x60,0x61,0x70,0x74,0xf0,EOT},
+ {0x01,0x03,0x78,0x07,0x04,0x3f,EOT}},
+ {0x2, COM1,
+ {0x30,0x60,0x61,0x70,0xf0,EOT},
+ {0x01,0x03,0xf8,0x04,0x00,EOT}},
+ {0x3, COM2,
+ {0x30,0x60,0x61,0x70,0xf0,0xf1,EOT},
+ {0x01,0x02,0xf8,0x03,0x00,0x00,EOT}},
+ {0x5, Keyboard,
+ {0x30,0x60,0x61,0x62,0x63,0x70,0x72,0xf0,EOT},
+ {0x01,0x00,0x60,0x00,0x64,0x01,0x0c,0x83,EOT}},
+ {0x7, GPIO 1,
+ {0x30,0x60,0x61,0x62,0x63,0x64,0x65,0x70,0x72,0xe0,
+0xe1,0xe2,0xe3,0xe4,0xe5,0xe6,0xe7,0xf1,EOT},
+ {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01,
+0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x00,EOT}},
+ {0x8, GPIO 2,
+ {0x30,0x60,0x61,0x70,0x72,0xe8,0xe9,0xea,0xeb,0xec,
+0xed,0xf0,0xf1,0xf2,0xf3,0xf4,EOT},
+ {0x00,0x00,0x00,0x00,0x00,0x01,0x01,0x01,0x01,0x01,
+0x01,0x00,RSVD,0x00,0x00,0x00,EOT}},
+ {0xa, ACPI,
+ /* Note: Datasheet says 0xe2 can't be read/written. */
+ {0x30,0x70,0xe0,0xe1,0xe2,0xe3,0xe4,0xe5,0xe6,0xe7,
+0xf0,0xf1,0xf3,0xf4,0xf6,0xf7,0xf9,0xfe,0xff,EOT},
+ {0x00,0x00,0x00,0x00,MISC,MISC,MISC,0x00,0x00,0x00,
+0x00,0x00,0x00,0x00,0x00,0x00,0x00,RSVD,RSVD,EOT}},
{EOT}}},
{0x595, W83627SF, { /* TODO: Not yet in sensors-detect */
{EOT}}},
static void probe_idregs_winbond_helper
Re: [coreboot] Is Coreboot selfmodifying? Award legacy Bios is!
on 01/10/2008 19:04 Mats Erik Andersson said the following: Hello all, the cryptic subject of this message is due to my efforts to verify that Flashrom is producing correct images. After much practical testing I have been able to conclude positively that the Award Bios 4.51 of a FIC mainboard is rewriting the blocks 0x0003800 - 0x00038fff cleartext on system characteristica, 0x0003a00 - 0x0003afff pci-table. I think that this is related to ESCD updates. It seems that some proprietary BIOSes contain flash writing routines which sometimes are even exposed for external use (via special signatures). at each reboot. Now I wonder if also Coreboot is using this opportunity under some circumstances. It is not that I think it is a commendable thing to do, instead it is a rather hazardous endeavour in my eyes. Best regards, Mats Erik Andersson -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] keyboard init patch
on 29/09/2008 20:25 Marc Jones said the following: Andriy Gapon wrote: on 26/09/2008 20:02 Marc Jones said the following: This patch fixes the it8712f keyboard issues and should also fix any general keyboard init issues with other SIOs. Marc Guys, you might find this useful: http://article.gmane.org/gmane.comp.emulators.bochs.devel/7843 It seems that this was included into bochs code. Maybe this is something that we would qemu to support as well. coreboot is a little better behaved than that. It only writes 0xCA/0xCB for specific SIOs(keyboard controllers). Since coreboot builds for qemu we don't need to make any changes. I see, thank you. Actually I have a goal to tweak qemu so that it can run coreboot images that are configured for real 440BX systems. For that qemu should be both sufficiently correct and sufficiently generic in its emulation of 440BX hardware. But I am highjacking this thread already. -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] qemu emulation quirks: legacy memory attributes
Guys, I have an impression that qemu is used quite extensively for coreboot code testing. But I've encountered some problems with its emulation of essential hardware that I didn't have with bochs. This is with non-coreboot code. What do you think about the following: http://thread.gmane.org/gmane.comp.emulators.qemu/30106 [register 20h there should be changed to register 59h] P.S. bochs is really good, BTW, but qemu's speed is fascinating. -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] keyboard init patch
on 26/09/2008 20:02 Marc Jones said the following: This patch fixes the it8712f keyboard issues and should also fix any general keyboard init issues with other SIOs. Marc Guys, you might find this useful: http://article.gmane.org/gmane.comp.emulators.bochs.devel/7843 It seems that this was included into bochs code. Maybe this is something that we would qemu to support as well. -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Incorrect casting in romcc.
Sorry for top posting - did you by a chance confused '' and ' as in your examples below? on 12/09/2008 15:30 Mats Erik Andersson said the following: Hello all, after much backtracking I have identified an unexpected case of (implicit) casting where romcc fails miserably. I desire a computation uint16_t fn(uint8_t d); uint8_t data; data = 0; data += ( fn(0x10) 1 ) 0x007f; where fn(0x10) == 0x1010. However, the actual outcome of the previous calculation is the value 0x01, instead of the expected 0x08. I does not help to provide an explicit casting data += (uint8_t) ( fn(0x10) 1) 0x007f; since provably the incorrect increment 0x01 is still produced. The above code is to be used in i440bx/raminit.c, and if I make the only change in that code to replace the above calculation with the fixed, but intended case data += 0x08; then the full functionality is restored and coreboot can start. In the light of all this, I mean to have found a bug in romcc, unless this can be viewed as a documented shortcoming. Best regards, Mats Erik Andersson -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- Andriy Gapon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [flashrom] layout.c: couple of nitpicks
It seems that in show_id() type of 'walk' variable should of fixed size
(i.e. uint32_t) for x86_64 portability.
Also, it looks suspicious that two legacy bios checks (nvidia and
general) are exactly the same:
if ((*walk) == 0 || ((*walk) 0x3ff) != 0) {
/* We might have an Nvidia chipset bios
...
}
if ((*walk) == 0 || ((*walk) 0x3ff) != 0) {
printf(Flash image seems to be a legacy BIOS. Disabling
checks.\n);
...
--
Andriy Gapon
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
