Re: [coreboot] disabling bios usb stack
Hello, Just checked some binaries - PEI USB driver is loading anyway, no checking for any setup option, so I guess it will be very hard even with the unpacking UEFI image and removing these drivers. Also in most UEFI systems big part of USB driver working in SMM mode, so it will be hard to patch this code on the fly. Best regards, Anton Kochkov. On Wed, Aug 27, 2014 at 1:23 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net wrote: Hi Ron, Am 26.08.2014 00:22 schrieb ron minnich: disabling the usb stack is the goal in this case. AFAIK it's called USB keyboard support, USB legacy support or something similar in most BIOSes. This internally maps a USB keyboard to a virtual PS/2 keyboard and sometimes has quite a few issues. If that's what your friend meant, disabling it should be straightforward in the BIOS menu. However, if your friend is a victim of EFI, I fear he is beyond help except for trying coreboot. Regards, Carl-Daniel -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot project analysis request
Hello! Sadly no answer from Klocwork... Ok, what do you think about Coverity? I mean this one http://scan.coverity.com/ It could be a good addition to this https://www.google-melange.com/gsoc/project/google/gsoc2013/alex_animux/76001 Radare2 is already scanning by Coverity (a few days). Best regards, Anton Kochkov. On Fri, Apr 12, 2013 at 1:32 PM, Антон Кочков anton.koch...@gmail.com wrote: Good day! As I did not get a reply to my message from April 3rd I am trying it again. Is it possible to add the coreboot project https://www.coreboot.org to your free analysis of FOSS projects? As an alternative to the BIOS and UEFI, coreboot and its payloads need and want to be as secure as possible to also outdo UEFI in the security aspect. So code analysis to find out any issues would help coreboot very much. Here is the code git clone http://review.coreboot.org/p/coreboot.git Under the directory `payloads/` there are some programs which are started after coreboot has finished. Under the directory `util/` there are several utilities needed for image creation or for board porting. As a build system, a customized Kconfig is used and there is also the build tool named abuild.. If you have any question, please do not hesitate to ask us. Either on our mailing list http://www.coreboot.org/Mailinglist or myself. The coreboot project and I hope, you are going to help us and are looking forward to what you are going to find. Best regards, Anton Kochkov. PS: If you know any students interested in low level stuff please tell them, that coreboot is participating in Google Summer of Code 2013 http://www.coreboot.org/GSoC . -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Management engine firmware
Please, remember, that ME code is signed, so you can't just write 'dummy' ME firmware. You can try to boot without it, but, it is unpredictable. Best regards, Anton Kochkov. On Thu, Jun 13, 2013 at 5:41 AM, George Chriss gschr...@gmail.com wrote: On Wed, Jun 12, 2013 at 7:16 PM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com wrote: Hello, all. In order to build X201 rom, you need management engine firmware. For chromebook the appropriate blobs are in 3rdparty repo, I suppose supplied by Intel. The only place where I could get ME firmware for X201 is by dumping chip with external programmer. It's probably not appropriate for coreboot to distribute those blobs (I'm unsure on their license) and given that it writes a log to its section which may contain private data, I don't want to distribute it either. Yet without this blob the build legitimately fails. Any suggestions on handling this? Are the coreboot dependencies function calls or something hardware-specific? Is it possible to build a 'dummy' management engine that still boots the X201, even with reduced functionality? (Is ME binary code executed at any point using coreboot?) Sincerely, George -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] coreboot project analysis request
Good day! As I did not get a reply to my message from April 3rd I am trying it again. Is it possible to add the coreboot project https://www.coreboot.org to your free analysis of FOSS projects? As an alternative to the BIOS and UEFI, coreboot and its payloads need and want to be as secure as possible to also outdo UEFI in the security aspect. So code analysis to find out any issues would help coreboot very much. Here is the code git clone http://review.coreboot.org/p/coreboot.git Under the directory `payloads/` there are some programs which are started after coreboot has finished. Under the directory `util/` there are several utilities needed for image creation or for board porting. As a build system, a customized Kconfig is used and there is also the build tool named abuild.. If you have any question, please do not hesitate to ask us. Either on our mailing list http://www.coreboot.org/Mailinglist or myself. The coreboot project and I hope, you are going to help us and are looking forward to what you are going to find. Best regards, Anton Kochkov. PS: If you know any students interested in low level stuff please tell them, that coreboot is participating in Google Summer of Code 2013 http://www.coreboot.org/GSoC . -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] building a coreboot (and 100% free software) compatible box
Not sure, but it is _downloadable_ firmware, while here can be flashed or burned firmware too. Best regards, Anton Kochkov. On Thu, Feb 7, 2013 at 1:46 PM, Kristóf, Csillag csillag.kris...@gmail.com wrote: At 2013-02-07 09:45, Kristóf, Csillag wrote: I think this means you'll need a discrete graphics card, as you mention in 2.1 below. Bitcoin just got ASICs so if you're the type to risk a scammer on fleabay, you could score a great deal. OK, but what graphics card? Both AMD and Nvidia require binary firmwares... Fortunately, that's not true! Nouveau can now run without a firmware on some cards. See here: http://nouveau.freedesktop.org/wiki/InstallDRM#A3D-accel_Firmware That's some progress... Csillag -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH v2] spkmodem
Hello! Could you please send patch for libpayload too? Best regards, Anton Kochkov. On Mon, Jan 21, 2013 at 6:10 PM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com wrote: A new version of spkmodem. This one doesn't lose the bit sync even if I disconnect the cable for the short time (but, of course data sent when no cable is attached is lost) -- Regards Vladimir 'φ-coder/phcoder' Serbinenko -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Gerrit problem: Not able to sign in
Hello! Have same issue today. Best regards, Anton Kochkov. On Thu, Jan 31, 2013 at 12:52 PM, Paul Menzel paulepan...@users.sourceforge.net wrote: Dear coreboot admins, currently I am not able to sign into Gerrit using my Google Mail account. Not found The page you requested was not found, or you do not have permission to view this page. Do you have similar problems? Thanks, Paul -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] bios_extract patches
Sending this to not forget about them: http://paste.flashrom.org/view.php?id=957 - patch for bios_extract for Phoenix http://paste.flashrom.org/view.php?id=1308 - python tool to extract microcode http://paste.flashrom.org/view.php?id=1163 - part of UEFI FFS support?? Best regards, Anton Kochkov. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] bios_extract patches
Forgot about this patch too http://patchwork.coreboot.org/patch/3444/ Best regards, Anton Kochkov. On Wed, Sep 12, 2012 at 7:07 PM, Антон Кочков anton.koch...@gmail.comwrote: Sending this to not forget about them: http://paste.flashrom.org/view.php?id=957 - patch for bios_extract for Phoenix http://paste.flashrom.org/view.php?id=1308 - python tool to extract microcode http://paste.flashrom.org/view.php?id=1163 - part of UEFI FFS support?? Best regards, Anton Kochkov. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] bios_extract patches
I know, btw, bios_extract already in gerrit. Best regards, Anton Kochkov. On Wed, Sep 12, 2012 at 7:21 PM, Peter Stuge pe...@stuge.se wrote: Антон Кочков wrote: Sending this to not forget about them: http://paste.flashrom.org/view.php?id=957 - patch for bios_extract for Phoenix http://paste.flashrom.org/view.php?id=1308 - python tool to extract microcode http://paste.flashrom.org/view.php?id=1163 - part of UEFI FFS support?? bios_extract is a git repo; please make them proper git patches. It might be useful to have a bios_extract repo in coreboot gerrit too. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Fintek F81865 patch
Hello!
Post it on gerrit please http://www.coreboot.org/Git
Best regards,
Anton Kochkov.
On Fri, Aug 31, 2012 at 1:18 PM, Juha Tuomala juha.tuom...@iki.fi wrote:
On Fri, 31 Aug 2012, Juha Tuomala wrote:
Below is a patch for Fintek f81865 superio register dump.
Datasheet: http://www.fintek.com.tw/**files/productfiles/F81865_**
V028P.pdf http://www.fintek.com.tw/files/productfiles/F81865_V028P.pdf
Patch url: http://tuju.fi/tmp/f81865.**patchhttp://tuju.fi/tmp/f81865.patch
diff --git a/util/superiotool/fintek.c b/util/superiotool/fintek.c
index fc1d3f2..8703f68 100644
Well, those defaults were different for each uart, so fixed them, patch
url file has been changed to match patch below:
diff --git a/util/superiotool/fintek.c b/util/superiotool/fintek.c
index fc1d3f2..f5a01de 100644
--- a/util/superiotool/fintek.c
+++ b/util/superiotool/fintek.c
@@ -279,6 +279,54 @@ static const struct superio_registers reg_table[] = {
{0x00,NANA,NANA,NANA,NANA,**NANA,EOT}},
{EOT}}},
{0x0407, F81865F/F-I, {
+ {NOLDN, NULL,
+ {0x02,0x07,0x20,0x21,0x23,**
0x24,0x25,0x26,0x27,0x28,0x29,**0x2a-1,0x2a-2,0x2b,0x2c,0x2d,**EOT},
+ {NANA,0x00,0x07,0x04,0x19,**
0x34,NANA,NANA,NANA,0x00,0x00,**0x00,0x00,0x1f,0x00,0x08,EOT}}**,
+ {0x00, FDC,
+ {0x30,0x60,0x61,0x70,0x74,**0xf0,0xf2,0xf4,EOT},
+ {NANA,0x03,0xf0,NANA,NANA,**NANA,NANA,NANA,EOT}},
+ {0x03, LPT,
+ {0x30,0x60,0x61,0x70,0x74,**0xf0,EOT},
+ {NANA,0x03,0x78,NANA,NANA,**NANA,EOT}},
+ {0x04, HWMON,
+ {0x30,0x60,0x61,0x70,EOT},
+ {NANA,0x02,0x95,NANA,EOT}},
+ {0x05, KBC,
+ {0x30,0x60,0x61,0x70,0x72,**0xfe,0xf0,EOT},
+ {NANA,0x00,0x60,NANA,NANA,**NANA,0x71,EOT}},
+ {0x06, GPIO,
+ {0x30,0x60,0x61,0x70,0xf1,**
0xf2,0xf3,0xf3,0xf4,0xf5,0xf6,**0xf7,0xf8,0xf9,0xe0,0xe1,0xe2,**
0xe3,0xef,0xd0,0xd1,0xd2,0xd3,**0xc0,0xc1,0xc2,0xc3,0xb0,0xb1,**
0xb2,0xb3,0xa0,0xa1,0xa2,0xa3,**0x90,0x91,0x92,0x93,EOT},
+ {NANA,0x00,0x60,NANA,0x00,**
NANA,0x00,0x00,0x00,0x00,0x00,**0x00,0x00,0x00,0x00,0xff,NANA,**
0x00,NANA,0x00,0xff,NANA,0x00,**0x00,0xff,NANA,0x00,0x00,0xff,**
NANA,0x00,0x00,0xff,NANA,0x00,**NANA,NANA,NANA,NANA,EOT}},
+ {0x07, WDT,
+ {0x30,0x60,0x61,0xf5,0xf6,**0xfa,EOT},
+ {NANA,0x00,0x00,0x00,0x00,**NANA,EOT}},
+ {0x08, SPI,
+ {0xf0,0xf1,0xf2,0xf3,0xf4,**
0xf5,0xf6,0xf7,0xf8,0xfa,0xfb,**0xfc,0xfd,0xfe,0xff,EOT},
+ {0x10,0x04,NANA,NANA,0x00,**
0x00,NANA,NANA,0x00,0x00,0x00,**0x00,0x00,0x00,0x00,EOT}},
+ {0x0a, PME ACPI,
+ {0x30,0xf0,0xf1,0xf2,0xf3,**0xf4,0xf5,0xf6,EOT},
+ {NANA,NANA,NANA,NANA,NANA,**0x06,NANA,0x00,EOT}},
+ {0x0b, RTC,
+ {0x30,0x60,0x61,0x70,EOT},
+ {NANA,0x00,0x00,NANA,EOT}},
+ {0x10, UART1,
+ {0x30,0x60,0x61,0x70,0xf0,**0xf2,0xf4,0xf5,EOT},
+ {NANA,0x03,0xf8,NANA,NANA,**NANA,0x00,0x00,EOT}},
+ {0x11, UART2,
+ {0x30,0x60,0x61,0x70,0xf0,**0xf2,0xf4,0xf5,EOT},
+ {NANA,0x02,0xf8,NANA,NANA,**NANA,0x00,0x00,EOT}},
+ {0x12, UART3,
+ {0x30,0x60,0x61,0x70,0xf0,**0xf2,0xf4,0xf5,EOT},
+ {NANA,0x03,0xe8,NANA,NANA,**NANA,0x00,0x00,EOT}},
+ {0x13, UART4,
+ {0x30,0x60,0x61,0x70,0xf0,**0xf2,0xf4,0xf5,EOT},
+ {NANA,0x02,0xe8,NANA,NANA,**NANA,0x00,0x00,EOT}},
+ {0x14, UART5,
+ {0x30,0x60,0x61,0x70,0xf0,**0xf2,0xf4,0xf5,EOT},
+ {NANA,0x00,0x00,NANA,NANA,**NANA,0x00,0x00,EOT}},
+ {0x15, UART6,
+ {0x30,0x60,0x61,0x70,0xf0,**0xf2,0xf4,0xf5,EOT},
+ {NANA,0x00,0x00,NANA,NANA,**NANA,0x00,0x00,EOT}},
{EOT}}},
{EOT}
};
Tuju
--
Säästämisen ja ahkeroinnin tilalle syntyi varsinkin 1960-luvulta lähtien
oman
onnellisuuden ympärillä pyörivä, vastuuton ajattelutapa, joka korostaa
oikeuksia
velvollisuuksien sijaan. - Paul Lillrank
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Moving gerrit to an separate mailing list
Yes, I agree that it can help search important messages, without tons of gerrit notifications. Best regards, Anton Kochkov. On Sun, Aug 12, 2012 at 12:57 AM, Oliver Schinagl oli...@schinagl.nlwrote: As a lurker, mostly anyway, I wholeheartedly agree. And I think for the 'you can set up a filter' group, I think the opposite is true. You can just setup a filter for the gerrit mails to put mails into the same directory I suppose too :) Oliver On 08/08/12 23:28, Alex G. wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've brought this up today on IRC. My main argument is that the coreboot mailing list should be a place for discussion, for newcomers asking for help, talking about the future of the project, etc. Definitely more for discussion and less for patch review. We have gerrit for patch review. Some (actually, a lot) of people prefer to do their reviews by replying to the gerrit emails. It's awesome to have this option. The more the merrier, right? Right. Back in the days -- I mean wy back, think patchwork and svn -- doing patch review on the list, with some deficiencies, worked fine. We switched to git and gerrit. We eventually got to the problem that gerrit traffic accounts for most of the traffic on the mailing list. It makes the list irritatingly clobbered for some people, to the point they just stop using it. The argument from the I like gerrit in the mailinglist camp is setting up your own filter to keep out gerrit message is easy. We can't really force people to do this. They (myself included) would rather stoThp using the mailing list. All I've said and refuted above are arguments and rants we like to use to tease each other. I strongly believe that it makes sense, now more than ever, to separate development and discussion traffic into two separate lists. I hope you all agree. Alex -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQItoNAAoJEL0kPH**NPXJJK+UIP/2yVfa/**UziIDeQRJdhhUOs1C UlGji9eLHw4rPxm9NS+3n+**s3bmQDdnOMZkOZ0mbXCO/**ufTCZurbZ7uOlDQasTYtt rPyU5GeMnILhH159ZIAo8KBI53HrBH**+**RdxOyxY0gVvSw5Vb2Ye4LVCTvrfDIZ**Jo3 p+**h7aPeAaR8mApwo24PAqJX9NDYZjytf**uOFZ91Jw8YS5BXykH8oa8Xj32ezqt7**fV lxOqew7UjNdVT26aCuHnTqlPYUw/**Nl97iluWrebd8Rre6PLai03dxXqVlv**gHHVXJ UzJFflwAn4gEjnYrOfd4qu/**sCkWJkCQDfYx/**DAiJtkPjUeY1FNw1Dnibsi6mP+F3 IleLl/**SWxv21UnZM6OJ999CxYTdXD2sNytlM**65d67UniGfeN6v1ARPZG0l2FzsRC PfUhrcPKryAsVCf4otWI64QUT0r0Kg**xU6qUdX6ZOvFerKcE+**ono8ERJCL4v9TBB+ DVJGV2Dil+67FPzPriRhcLufPfQ14+**B8BRNcFYbYOkmgjBtRmrZk/**WvaEU5uVvII sbXbEzfSKrCKGr/**K00XPRti0CRg7wn6MVeVsLTxvA5HMI**kuGxd9FfmG9EPrC0JXZ tljwICM4AJkbQ6EkDg2Z66SUWnPBtf**iCLNyPs8IfK5rfYkhkreqnWRtwxl8U**a7SE Lk13bwHJ/Jyf5r3RDAJU =543W -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/**mailman/listinfo/coreboothttp://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] git push by http failed.
All looks ok, I think this is gerrit bug, not some git configuration or so. Best regards, Anton Kochkov. On Tue, Aug 21, 2012 at 10:44 AM, Bao, Zheng zheng@amd.com wrote: user.email=fishba...@gmail.com user.name=zbao core.repositoryformatversion=0 core.filemode=true core.bare=false core.logallrefupdates=true core.ignorecase=true remote.origin.fetch=+refs/heads/*:refs/remotes/origin/* remote.origin.url=http://zbao:xxx...@review.coreboot.org/p/coreboot.git remote.origin.push=HEAD:refs/for/master branch.master.remote=origin branch.master.merge=refs/heads/master submodule.3rdparty.url=http://zbao:...@review.coreboot.org/p/blobs.git submodule.3rdparty.update=none alias.co=checkout From: QingPei Wang [mailto:wangqing...@gmail.com] Sent: Tuesday, August 21, 2012 12:19 PM To: Bao, Zheng Cc: coreboot@coreboot.org Subject: Re: [coreboot] git push by http failed. what's your git config ? Best wishes QingPei Wang Phone: 86+018930528086 On Tue, Aug 21, 2012 at 10:54 AM, Bao, Zheng zheng@amd.com wrote: RPC failed; result=22, HTTP code = 500 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Regarding How-To for new board support
Sorry for my try to explain thing, but i mean provide useful output of such tools for flashrom support. And such output for board, which you are _really going_ to port, to help other people point you. I agree that my point me be wrong, but I think, if from 100 ppl, tried to do the port, at least 1 will do that completely - that kind of win! Of course I not mean that anyone can just send some information, and give a working board. Thats my error (as you can see I'm not great speaker, so I'll fix my explanation and improve the FAQ). I agree that for doing things you need to learn a lot, but please, dont afraid if you can't finish this - thats ok. May be I need to figure (as Peter already mentioned) that much more help can receive the man, who already have some code, and stuck on some techinical thing. This is a common sense in many opensource commuties. Also you need to know - rule # 0 - DON'T PLAY WITH COREBOOT WITHOUT WAY TO REPAIR YOUR FLASH ROM. P.S. Sorry for my 'engrish'. Best regards, Anton Kochkov. On Tue, Aug 14, 2012 at 11:43 PM, Nils njaco...@adsltotaal.nl wrote: Hi Peter, You wrote: There is nearly zero correlation between the output of those tools and coreboot support. Please don't waste time on sending the output, and please try to update any and every resource that you find which requests such output, to explain the situation more intelligently. This keeps popping up regularly. To prevent people wasting there and your time in the future maybe someone with wiki write rights (you?) could edit the Will coreboot work on my machine? alinea in the coreboot FAQ: http://www.coreboot.org/FAQ Greetings, Nils. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [libpayload] EHCI USB driver transaction error
Good day (or any other time)! While working with/on libpayload for EHCI USB driver, i've found strange error, when device is found (port status = 0x1803) and sending first control transaction. (usb_attach_device/get_free_address). Mainboard - Foxconn N15235 wait_for_tds(): ERROR with packet = EHCI TD at [0x0004d000] = __EHCI_TD cerr: 0, total_len: 8 __EHCI_TD: next_qtd [0x0004d120] __EHCI_TD: alt_next_qtd [0x0001] __EHCI_TD: token [0x00080248] __EHCI_TD: Bytes to Transfer [8] __EHCI_TD: PID CODE: [2] __EHCI_TD: Interrupt On Complete (IOC) [0] __EHCI_TD: Status Active [0] __EHCI_TD: Status Halted [1] __EHCI_TD: Status Data Buffer Error [0] __EHCI_TD: Status Babble detected [0] __EHCI_TD: Status Transaction Error [1] __EHCI_TD: Status Missed Micro Frame [0] __EHCI_TD: Status Split Transaction State [0] __EHCI_TD: Status Ping State [0] wait_for_tds(): - Attaching full log, where dumping registers/packets on every step. Hope someone know the reason. Best regards, Anton Kochkov. Calculate CPU speed get_cpu_speed(): cpu_khz = 304f1f Reset all USB controllers ehci_create(): starting... init_device_entry(0): starting... init_device_entry(0): done! ehci_create(): done === EHCI HT CAPLENGTH:[0x0020] HCIVERSION: [0x0100] HCSPARAMS:[0x0022] HCCPARAMS:[0x00036881] HCSP_PORTROUTE: [0x] USBCMD: [0x00080011] USBSTS: [0x6008] USBINTR: [0x0007] FRINDEX: [0x2e7b] CTRLDSSEGMENT:[0x] PERIODICLISTBASE: [0x6e5f8000] ASYNCLISTADDR:[0x6e5f13c0] CONFIGFLAG: [0x0001] //=// ehci_create(): starting... init_device_entry(0): starting... init_device_entry(0): done! ehci_create(): done === EHCI HT CAPLENGTH:[0x0020] HCIVERSION: [0x0100] HCSPARAMS:[0x0022] HCCPARAMS:[0x00036881] HCSP_PORTROUTE: [0x] USBCMD: [0x00080011] USBSTS: [0x6008] USBINTR: [0x0007] FRINDEX: [0x3215] CTRLDSSEGMENT:[0x] PERIODICLISTBASE: [0x6e5f9000] ASYNCLISTADDR:[0x6e5f1880] CONFIGFLAG: [0x0001] //=// ehci_take_ownership(): starting... ehci_take_ownership(): success! === EHCI HT CAPLENGTH:[0x0020] HCIVERSION: [0x0100] HCSPARAMS:[0x0022] HCCPARAMS:[0x00036881] HCSP_PORTROUTE: [0x] USBCMD: [0x0008] USBSTS: [0x1000] USBINTR: [0x] FRINDEX: [0x] CTRLDSSEGMENT:[0x] PERIODICLISTBASE: [0x] ASYNCLISTADDR:[0x] CONFIGFLAG: [0x] //=// ehci_reset(): starting... ehci_reset(): done! ehci_take_ownership(): after reset === EHCI HT CAPLENGTH:[0x0020] HCIVERSION: [0x0100] HCSPARAMS:[0x0022] HCCPARAMS:[0x00036881] HCSP_PORTROUTE: [0x] USBCMD: [0x0008] USBSTS: [0x1000] USBINTR: [0x] FRINDEX: [0x] CTRLDSSEGMENT:[0x] PERIODICLISTBASE: [0x] ASYNCLISTADDR:[0x] CONFIGFLAG: [0x] //=// ehci_take_ownership(): starting... ehci_take_ownership(): success! === EHCI HT CAPLENGTH:[0x0020] HCIVERSION: [0x0100] HCSPARAMS:[0x0022] HCCPARAMS:[0x00036881] HCSP_PORTROUTE: [0x] USBCMD: [0x0008] USBSTS: [0x1000] USBINTR: [0x] FRINDEX: [0x] CTRLDSSEGMENT:[0x] PERIODICLISTBASE: [0x] ASYNCLISTADDR:[0x] CONFIGFLAG: [0x] //=// ehci_reset(): starting... ehci_reset(): done! ehci_take_ownership(): after reset === EHCI HT CAPLENGTH:[0x0020] HCIVERSION: [0x0100] HCSPARAMS:[0x0022] HCCPARAMS:[0x00036881] HCSP_PORTROUTE: [0x] USBCMD: [0x0008] USBSTS: [0x1000] USBINTR: [0x] FRINDEX: [0x] CTRLDSSEGMENT:[0x] PERIODICLISTBASE: [0x] ASYNCLISTADDR:[0x] CONFIGFLAG: [0x] //=// ehci_init(): starting EHCI controller... [0x8000d000] ehci_create(): starting... init_device_entry(0): starting...
Re: [coreboot] [libpayload] EHCI USB driver transaction error
Sorry, valid mainboard name - Foxconn H61MXV http://www.foxconnchannel.com/ProductDetail.aspx?T=motherboardU=en-us522 Best regards, Anton Kochkov. On Fri, Jul 20, 2012 at 12:10 PM, Антон Кочков anton.koch...@gmail.comwrote: Good day (or any other time)! While working with/on libpayload for EHCI USB driver, i've found strange error, when device is found (port status = 0x1803) and sending first control transaction. (usb_attach_device/get_free_address). Mainboard - Foxconn N15235 wait_for_tds(): ERROR with packet = EHCI TD at [0x0004d000] = __EHCI_TD cerr: 0, total_len: 8 __EHCI_TD: next_qtd [0x0004d120] __EHCI_TD: alt_next_qtd [0x0001] __EHCI_TD: token [0x00080248] __EHCI_TD: Bytes to Transfer [8] __EHCI_TD: PID CODE: [2] __EHCI_TD: Interrupt On Complete (IOC) [0] __EHCI_TD: Status Active [0] __EHCI_TD: Status Halted [1] __EHCI_TD: Status Data Buffer Error [0] __EHCI_TD: Status Babble detected [0] __EHCI_TD: Status Transaction Error [1] __EHCI_TD: Status Missed Micro Frame [0] __EHCI_TD: Status Split Transaction State [0] __EHCI_TD: Status Ping State [0] wait_for_tds(): - Attaching full log, where dumping registers/packets on every step. Hope someone know the reason. Best regards, Anton Kochkov. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [libpayload] EHCI USB driver transaction error
Problem solved - was error in memory align - so, EHCI go to NULL pointer, which cause PCI error. Best regards, Anton Kochkov. On Fri, Jul 20, 2012 at 12:22 PM, Антон Кочков anton.koch...@gmail.comwrote: Sorry, valid mainboard name - Foxconn H61MXV http://www.foxconnchannel.com/ProductDetail.aspx?T=motherboardU=en-us522 Best regards, Anton Kochkov. On Fri, Jul 20, 2012 at 12:10 PM, Антон Кочков anton.koch...@gmail.comwrote: Good day (or any other time)! While working with/on libpayload for EHCI USB driver, i've found strange error, when device is found (port status = 0x1803) and sending first control transaction. (usb_attach_device/get_free_address). Mainboard - Foxconn N15235 wait_for_tds(): ERROR with packet = EHCI TD at [0x0004d000] = __EHCI_TD cerr: 0, total_len: 8 __EHCI_TD: next_qtd [0x0004d120] __EHCI_TD: alt_next_qtd [0x0001] __EHCI_TD: token [0x00080248] __EHCI_TD: Bytes to Transfer [8] __EHCI_TD: PID CODE: [2] __EHCI_TD: Interrupt On Complete (IOC) [0] __EHCI_TD: Status Active [0] __EHCI_TD: Status Halted [1] __EHCI_TD: Status Data Buffer Error [0] __EHCI_TD: Status Babble detected [0] __EHCI_TD: Status Transaction Error [1] __EHCI_TD: Status Missed Micro Frame [0] __EHCI_TD: Status Split Transaction State [0] __EHCI_TD: Status Ping State [0] wait_for_tds(): - Attaching full log, where dumping registers/packets on every step. Hope someone know the reason. Best regards, Anton Kochkov. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Patch set updated for coreboot: 833a825 superiotool: Add support for NCT6775F(A/B) and NCT6779D
Thanks for the patches!
Also, may be this can help you too, for automating some work
http://hg.droid-developers.org/pygen/src
Right now it is very hackish, but already works ok.
Best regards,
Anton Kochkov.
On Sat, Jun 30, 2012 at 12:21 AM, Guenter Roeck ger...@coreboot.org wrote:
Guenter Roeck (li...@roeck-us.net) just uploaded a new patch set to gerrit,
which you can find at http://review.coreboot.org/1148
-gerrit
commit 833a825f753779d366e401ebd8af6761bb5125f2
Author: Guenter Roeck li...@roeck-us.net
Date: Fri Jun 29 12:22:51 2012 -0700
superiotool: Add support for NCT6775F(A/B) and NCT6779D
Change-Id: I7fcb58f6885460021f4a2024d6ba56b95f11
Signed-off-by: Guenter Roeck li...@roeck-us.net
---
util/superiotool/nuvoton.c | 234
1 files changed, 234 insertions(+), 0 deletions(-)
diff --git a/util/superiotool/nuvoton.c b/util/superiotool/nuvoton.c
index ed2eabc..46b8c2a 100644
--- a/util/superiotool/nuvoton.c
+++ b/util/superiotool/nuvoton.c
@@ -66,6 +66,170 @@ static const struct superio_registers reg_table[] = {
{EOT}}},
{0x1a, WPCM450, {
{EOT}}},
+ {0xb472, NCT6775F (A), {
+ {NOLDN, NULL,
+ {0x20,0x21,0x22,0x23,0x24,0x25,0x26,0x27,0x28,
+ 0x29,0x2a,0x2b,0x2c,0x2d,0x2e,0x2f,EOT},
+ {0xb4,0x72,0xff,0x78,0x40,0x00,0x00,0x7d,0x00,
+ 0x00,0x58,0x77,0xfc,0x04,0x00,MISC,EOT}},
+ {0x00, FDC,
+ {0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,0xf2,0xf4,
+ 0xf5,EOT},
+ {0x03,0x03,0xf0,0x06,0x02,0x8e,0x00,0xff,0x00,
+ 0x00,EOT}},
+ {0x01, Parallel Port,
+ {0x30,0x60,0x61,0x70,0x74,0xf0,EOT},
+ {0x01,0x03,0x78,0x07,0x04,0x3f,EOT}},
+ {0x02, UART A,
+ {0x30,0x60,0x61,0x70,0xf0,EOT},
+ {0x01,0x03,0xf8,0x04,0x00,EOT}},
+ {0x03, UART B, IR,
+ {0x30,0x60,0x61,0x70,0xf0,0xf1,EOT},
+ {0x01,0x02,0xf8,0x03,0x00,0x00,EOT}},
+ {0x05, Keyboard Controller,
+ {0x30,0x60,0x61,0x62,0x63,0x70,0x72,0xf0,EOT},
+ {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x83,EOT}},
+ {0x06, CIR,
+ {0x30,0x60,0x61,0x70,EOT},
+ {0x00,0x00,0x00,0x00,EOT}},
+ {0x07, GPIO6, GPIO7, GPIO8, GPIO9,
+ {0x30,0xe0,0xe1,0xe2,0xe3,0xe4,0xe5,0xe6,0xe7,
+ 0xe8,0xe9,0xea,0xeb,0xec,0xed,0xee,0xf4,0xf5,
+ 0xf6,0xf7,0xf8,EOT},
+ {0x18,0xff,0x00,0x00,0x00,0xef,0x00,0x00,0x00,
+ 0xff,0x00,0x00,0x00,0x00,0x00,0x00,0xff,0x00,
+ 0x00,0x00,0x00,EOT}},
+ {0x08, WDT1, GPIO0, GPIO1,
+ {0x30,0xe0,0xe1,0xe2,0xe3,0xe4,0xf0,
+ 0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,EOT},
+ {0x00,0xff,0x00,0x00,0x00,0x00,0xff,
+ 0x00,0x00,0x00,0x00,0x00,0x00,0x00,EOT}},
+ {0x09, GPIO2, GPIO3, GPIO4, GPIO5,
+ {0x30,0xe0,0xe1,0xe2,0xe3,0xe4,0xe5,0xe6,0xe7,
+ 0xe8,0xe9,0xea,0xeb,0xee,0xf0,0xf1,0xf2,0xf4,
+ 0xf5,0xf6,0xf7,0xfe,EOT},
+ {0x05,0xff,0x00,0x00,0x00,0xff,0x00,0x00,0x00,
+ 0x00,0x00,0x00,0x00,0x00,0xff,0x00,0x00,0xff,
+ 0x00,0x00,0x00,0x00,EOT}},
+ {0x0a, ACPI,
+ {0x30,0xe0,0xe1,0xe2,0xe3,0xe4,0xe5,0xe6,0xe7,
+ 0xe8,0xe9,0xea,0xeb,0xed,0xf2,0xf3,0xf4,0xf6,
+ 0xf7,0xfe,EOT},
+ {0x00,0x01,0x00,0x00,0x00,0x00,0x02,0x1c,0x00,
+ 0x00,0x00,0x00,0x00,0x00,0x7c,0x00,0x00,0x00,
+ 0x20,0x00,EOT}},
+ {0x0b, Hardware Monitor, Front Panel LED,
+ {0x30,0x60,0x61,0x62,0x63,0x70,0xf0,0xf1,0xf2,
+ 0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9,0xfa,0xfb,
+ 0xfc,0xfd,0xfe,
+ EOT},
+ {0x00,0x00,0x00,0x00,0x00,0x00,0xc1,0x00,0x00,
+ 0x00,0x00,0x10,0x00,0x87,0x47,0x00,0x00,0x00,
+ 0x00,0x00,0x00,
+ EOT}},
+ {0x0c, PECI, SST,
+ {0xe0,0xe1,0xe2,0xe3,0xe4,0xe5,0xe6,0xe7,0xe9,
+ 0xee,0xef,0xf1,0xf2,0xf3,0xfa,EOT},
+ {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x0f,
+ 0x47,0x5b,0x40,0x50,0x10,0x00,EOT}},
+ {0x0d, VID,
[coreboot] Military/Industrial Embedded market and coreboot
Good day! Anyone hear about VME and VMEbus? That was common standard for military, industrial and aerospace applications And that was standard without x86. In the early 2000 VITA group announced new successor of VME - OpenVPX ( http://en.wikipedia.org/wiki/VPX ) And now, VPX computers market full of x86 platforms. I think coreboot in this market can bring more advantages for customer, than in desktop/claster pc. And no one on the market hear/wonder about coreboot. I think at least they need to know about. There many magazines, conferences. What if write article or go to some exhibition/conference? See links: Submit article: http://opensystemsmedia.com/submit/news (for magazines http://www.mil-embedded.com/ and http://industrial-embedded.com/ ) Exhibitions, like MILCOM: (http://www.milcom.com) - biggest conference in the world, for military IT. and a lot of other. Best regards, Anton Kochkov. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] BIOS Protection Guidelines from NIST
April 2011: http://csrc.nist.gov/publications/nistpubs/800-147/NIST-SP800-147-April2011.pdf -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Fwd: use gcc 4.6.0 link time optimization to reduce coreboot execution time
May be add something like profiling option with patch for implementing such feature? Best regards, Anton Kochkov. On Sun, May 1, 2011 at 07:37, Scott Duplichan sc...@notabs.org wrote: Kevin O'Connor wrote: ] That's a great boot time! Do you have a breakdown of where the 640ms ] is spent? ] ] -Kevin Hello Kevin, I tried adding some serial logging to get an idea about where the time is spent. The logging adds 8 ms to the boot time: Time in ms 0 cold reset 366 memory initialization complete 469 seabios: maininit(void) 483 seabios: vga_setup() called 604 seabios: vga_setup() returned 621 seabios: startBoot(void) 648 dos autoexec utility logs pmtimer value It looks like the lengthy operations are memory init and VBIOS execution, which is consistent with past experience. UEFI BIOS on this same hardware platform is taking more than 10 seconds. Here seabios kconfig options I changed: Build for coreboot y Hardware init during option ROM execution y Bootmenu n ATA controllers n AHCI controllers y Floppy controller n PS/2 port n USB UHCI controllers n Parallel port n PCIBIOS interface n APM interface n PnP BIOS interface n S3 resume n SMBIOS n Serial port debugging y Show screen writes on debug ports n Thanks, Scott -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Fwd: coreboot and Clang/LLVM
Nope this is error of specifics of -I option for clang gcc works ok on the same tree Also this file already here. Best regards, Anton Kochkov. 2011/4/25 Stefan Reinauer stefan.reina...@coreboot.org: * Антон Кочков anton.koch...@gmail.com [110423 06:55]: Hello! I'm trying to build coreboot with Clang/LLVM. Why? Because Clang produce nice error/warning messages, which help find a bugs. Here will be discussion about such things. Attached first log: ROMCC mainboard/emulation/qemu-x86/bootblock.inc src/arch/x86/init/bootblock_simple.c:1:10: fatal error: 'bootblock_common.h' file not found #include bootblock_common.h Looks like your checked out tree is messed up. It does not even die calling clang, but ROMCC, on a file that certainly exists. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and Clang/LLVM
Attached log with make V=1 Best regards, Anton Kochkov. 2011/4/25 Stefan Reinauer stefan.reina...@coreboot.org: * Антон Кочков anton.koch...@gmail.com [110425 21:15]: Nope this is error of specifics of -I option for clang gcc works ok on the same tree Also this file already here. Hm.. the message is caused by romcc though. Can you run make V=1 with clang? ROMCC mainboard/emulation/qemu-x86/bootblock.inc clang -m32 -MM -MTbuild/mainboard/emulation/qemu-x86/bootblock.inc \ src/arch/x86/init/bootblock_normal.c build/mainboard/emulation/qemu-x86/bootblock.inc.d src/arch/x86/init/bootblock_normal.c:1:10: fatal error: 'bootblock_common.h' file not found #include bootblock_common.h ^ 1 error generated. make: *** [build/mainboard/emulation/qemu-x86/bootblock.inc] Error 1 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Strange ITE IT8502e
Hello! I'm reversed my Dell Vostro V13 board enable (ODM - Inventec) and read from it that my EC have 0x600/0x601 ports. See here: http://paste.flashrom.org/view.php?id=472 And here strange output if i use 0x600/0x601 pair in superiotool: http://paste.flashrom.org/view.php?id=473 Best regards, Anton Kochkov. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] msrtool: generation from C code to XML
msrtool: add support for producing xml files from C code Signed-off-by: Anton Kochkov anton.koch...@gmail.com --- export_msr.patch Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] superiotool: generation from C code to XML
superiotool: add support for producing xml files from C code Signed-off-by: Anton Kochkov anton.koch...@gmail.com --- export_sio.patch Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] msrtool code-generation from xml definitions file. Preliminary release.
See example. Write bugs and suggestions
--
Best regards,
Anton Kochkov
generate.py
Description: Binary data
msrarray name=sample
!-- known cpus --
cpu family=0x6 model=0x17 stepping=5 /
cpu family=0x80 model=0xab stepping=10 /
!-- possible types = { ro, wo, rw } --
msr address=0x0 type=ro name=ID description=Platform ID
!-- possible types = { hex, bin, dec, oct } --
bitfield start=63 size=1 name=id_enabler description=bla-bla type=bin
value number=1 description=enable /
value number=0 description=disable /
/bitfield
/msr
msr address=0xa type=rw name=IP description=new_kf
/msr
/msrarray
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] msrtool: add support for code generation from xml files
msrtool: add support for Intel
Signed-off-by: Anton Kochkov anton.koch...@gmail.com
---
generate.py
Description: Binary data
msrarray name=sample
!-- known cpus --
cpu family=0x6 model=0x17 stepping=5 /
cpu family=0x80 model=0xab stepping=10 /
!-- possible types = { ro, wo, rw } --
msr address=0x0 type=ro name=ID description=Platform ID
!-- possible types = { hex, bin, dec, oct } --
bitfield start=63 size=1 name=id_enabler description=bla-bla type=bin
value number=1 description=enable /
value number=0 description=disable /
/bitfield
/msr
msr address=0xa type=rw name=IP description=new_kf
/msr
/msrarray
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] msrtool: add support for code generation from xml files
msrtool: add support for code generation from xml files
Signed-off-by: Anton Kochkov anton.koch...@gmail.com
---
Sorry, was type error. Now it works out of the box
msrarray name=sample
!-- known cpus --
cpu family=0x6 model=0x17 stepping=5 /
cpu family=0x80 model=0xab stepping=10 /
!-- possible types = { ro, wo, rw } --
msr address=0x0 type=ro name=ID description=Platform ID
!-- possible types = { hex, bin, dec, oct } --
bitfield start=63 size=1 name=id_enabler description=bla-bla type=bin
value number=1 description=enable /
value number=0 description=disable /
/bitfield
/msr
msr address=0xa type=rw name=IP description=new_kf
/msr
/msrarray
generate.py
Description: Binary data
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] msrtool: add support for code generation from xml files. step 2
msrtool: add support for code generation from xml files
Search all *.msr.xml files in directory, creating *.c files from them,
produce *.patch for msrtool.c and msrtool.h
Signed-off-by: Anton Kochkov anton.koch...@gmail.com
---
generate.py
Description: Binary data
msrarray name=sample description=Sample 1 processors family and Co
!-- known cpus --
cpu family=0x6 model=0x17 stepping=5 /
cpu family=0x80 model=0xab stepping=10 /
!-- possible types = { ro, wo, rw } --
msr address=0x0 type=ro name=ID description=Platform ID
!-- possible types = { hex, bin, dec, oct } --
bitfield start=63 size=1 name=id_enabler description=bla-bla type=bin
value number=1 description=enable /
value number=0 description=disable /
/bitfield
/msr
msr address=0xa type=rw name=IP description=new_kf
/msr
/msrarray
msrarray name=sample2 description=Sample 2 processors family and Co
!-- known cpus --
cpu family=0x6 model=0x17 stepping=5 /
cpu family=0x80 model=0xab stepping=10 /
!-- possible types = { ro, wo, rw } --
msr address=0x0 type=ro name=ID description=Platform ID
!-- possible types = { hex, bin, dec, oct } --
bitfield start=63 size=1 name=id_enabler description=bla-bla type=bin
value number=1 description=enable /
value number=0 description=disable /
/bitfield
/msr
msr address=0xa type=rw name=IP description=new_kf
/msr
/msrarray
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] pygen: code generation from xml files. step 1: msrtool module
msrtool: add support for code generation from xml files Search all *.msr.xml files in directory, creating *.c files from them, produce *.patch for msrtool.c and msrtool.h Signed-off-by: Anton Kochkov anton.koch...@gmail.com --- Next will be superiotool module and gui interface pygen.tar.gz Description: GNU Zip compressed data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] pygen: code generation from xml files. step 1: msrtool module - fixes
msrtool: add support for code generation from xml files Search all *.msr.xml files in directory, creating *.c files from them, produce *.patch for msrtool.c and msrtool.h Signed-off-by: Anton Kochkov anton.koch...@gmail.com --- Small fixes, included export_msr.c file, which produce *.msr.xml files from existing code pygen.tar.gz Description: GNU Zip compressed data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] inteltool: first preview for machine-readable output
inteltool: first preview for machine-readable output Signed-off-by: Anton Kochkov anton.koch...@gmail.com --- This is only for preview and discussion, it's still ugly and dont safe/clear. inteltool_machine_readable_first_preview.patch Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Fwd: inteltool: first preview for machine-readable output
inteltool: first preview for machine-readable output
Signed-off-by: Anton Kochkov anton.koch...@gmail.com
---
This is only for preview and discussion, it's still ugly and dont safe/clear.
inteltool_machine_readable_first_preview.patch
Description: Binary data
#include stdio.h
#include inteltool.h
/*
char *xml_header = ?xml version=1.0 encoding=UTF-8? \
database xmlns=http://nouveau.freedesktop.org/; \
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; \
xsi:schemaLocation=http://nouveau.freedesktop.org/ rules-ng.xsd
*/
void machine_readable_printf(reg_t *reg) {
#ifdef XML
printf(register domain='%s' base='0x%x' offset='0x%x' size='%d' value='0x%x' name='%s' description='%s' /\n,
reg-domain, reg-base_addr, reg-offset, reg-size, reg-value, reg-name, reg-desc);
#endif
#ifndef XML
printf(domain: %s\n, reg-domain);
printf(base addr: 0x%x\n, reg-base_addr);
printf(offset: 0x%x\n, reg-offset);
printf(size: %d\n, reg-size);
printf(value: 0x%x\n, reg-value);
printf(name: %s\n, reg-name);
printf(description: %s\n, reg-desc);
#endif
}
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] inteltool: first preview for machine-readable output, fixes
inteltool: first preview for machine-readable output, fixes Signed-off-by: Anton Kochkov anton.koch...@gmail.com --- This is only for preview and discussion, it's still ugly and dont safe/clear. inteltool_machine_readable_second_preview.patch Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] inteltool: added MCH register names for Intel NM10
inteltool: added MCH register names for Intel NM10 Signed-off-by: Anton Kochkov anton.koch...@gmail.com --- mch_registers_nm10.patch Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [inteltool] renamed in bridgetool, added support of other non-Intel chipsets.
inteltool: renamed in bridgetool, added support of other chipsets. Signed-off-by: Anton Kochkov anton.koch...@gmail.com --- bridgetool.patch Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [inteltool] added initial support of CPU extended information
inteltool: added initial support of cpu_info extended information inteltool: dumping MSR registers for Intel Celeron M 743 Signed-off-by: Anton Kochkov anton.koch...@gmail.com --- Now killed cpu.h and placed back all data in cpu.c cpu_fe.patch Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] inteltool: added initial support of CPU extended information
inteltool: added initial support of cpu_info extended information inteltool: dumping MSR registers for Intel Celeron M 743 Signed-off-by: Anton Kochkov anton.koch...@gmail.com --- inteltool.patch Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [inteltool] added initial support of CPU extended information
inteltool: added initial support of cpu_info extended information inteltool: dumping MSR registers for Intel Celeron M 743 Signed-off-by: Anton Kochkov anton.koch...@gmail.com --- inteltool.patch Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] superiotool: Add support to IT85xx series
Add support to IT85xx series
Signed-off-by: Anton Kochkov anton.koch...@gmail.com
---
Index: ite.c
===
--- ite.c (revision 5622)
+++ ite.c (working copy)
@@ -29,11 +29,110 @@
static const struct superio_registers reg_table[] = {
{0x8228, IT8228E, {
{EOT}}},
+{0x8502, IT8502E/TE/G, {
+{NOLDN, NULL,
+ {0x20,0x21,0x22,0x23,0x24,0x25,0x26,0x27,0x28,0x29,
+ 0x2A,0x2B,0x2C,0x2D,0x2E,EOT},
+ {0x85,0x02,0x71,0x01,NANA,0x00,0x00,NANA,NANA,NANA,
+ NANA,NANA,NANA,0x00,NANA,EOT}},
+{0x1, UART1,
+ {0x30,0x60,0x61,0x62,0x63,0x70,0x71,0xf0,EOT},
+ {0x00,0x03,0xf8,0x00,0x00,0x04,0x02,0x00,EOT}},
+{0x4, System Wake-Up,
+ {0x30,0x60,0x61,0x62,0x63,0x70,0x71,0xf0,EOT},
+ {0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x00,EOT}},
+{0x5, Mouse,
+ {0x30,0x60,0x61,0x62,0x63,0x70,0x71,0xf0,EOT},
+ {0x01,0x00,0x00,0x00,0x00,0x0C,0x01,NANA,EOT}},
+{0x6, Keyboard,
+ {0x30,0x60,0x61,0x62,0x63,0x70,0x71,0xf0,EOT},
+ {0x01,0x00,0x60,0x00,0x64,0x01,0x01,NANA,EOT}},
+{0xf, Shared Memory/Flash,
+ {0x30,0x60,0x61,0x62,0x63,0x70,0x71,0xf4,0xf5,
+0xf6,EOT},
+ {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+0x00,EOT}},
+{0x10, BRAM,
+ {0x30,0x60,0x61,0x62,0x63,0x70,0x71,0xf3,0xf4,
+0xf5,EOT},
+ {0x00,0x00,0x70,0x00,0x72,0x08,0x01,NANA,NANA,
+NANA,EOT}},
+{0x11, Power Channel 1,
+ {0x30,0x60,0x61,0x62,0x63,0x70,0x71,EOT},
+
+{0x00,0x00,0x62,0x00,0x66,0x01,0x01,EOT}},
+{0x12, Power Channel 2,
+ {0x30,0x60,0x61,0x62,0x63,0x70,0x71,EOT},
+ {0x00,0x00,0x68,0x00,0x6c,0x01,0x01,EOT}},
+{0x17, Power Channel 3,
+ {0x30,0x60,0x61,0x62,0x63,0x70,0x71,EOT},
+ {0x00,0x00,0x6a,0x00,0x6e,0x01,0x01,EOT}},
+ {EOT}}},
{0x8510, IT8510E/TE/G, {
{EOT}}},
{0x8511, IT8511E/TE/G, {
+{NOLDN, NULL,
+ {0x20,0x21,0x22,0x23,0x24,0x25,0x26,0x27,0x28,0x29,
+ 0x2A,0x2B,0x2C,0x2D,0x2E,EOT},
+ {0x85,0x11,0x10,0x01,NANA,0x00,0x00,NANA,NANA,NANA,
+ NANA,NANA,NANA,0x00,NANA,EOT}},
+{0x4, System Wake-Up,
+ {0x30,0x60,0x61,0x62,0x63,0x70,0x71,0xf0,EOT},
+ {0x00,0x00,0x00,0x00,0x00,0x00,0x03,0x00,EOT}},
+{0x5, Mouse,
+ {0x30,0x60,0x61,0x62,0x63,0x70,0x71,0xf0,EOT},
+ {0x01,0x00,0x00,0x00,0x00,0x0C,0x03,NANA,EOT}},
+{0x6, Keyboard,
+ {0x30,0x60,0x61,0x62,0x63,0x70,0x71,0xf0,EOT},
+ {0x01,0x00,0x60,0x00,0x64,0x01,0x03,NANA,EOT}},
+{0xf, Shared Memory/Flash,
+ {0x30,0x60,0x61,0x62,0x63,0x70,0x71,0xf4,0xf5,
+0xf6,EOT},
+ {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+0x00,EOT}},
+{0x10, Real-Time Clock,
+ {0x30,0x60,0x61,0x62,0x63,0x70,0x71,0xf0,0xf1,
+0xf2,0xf3,0xf4,0xf5,EOT},
+ {0x00,0x00,0x70,0x00,0x72,0x08,0x00,0x00,0x49,
+0x4A,NANA,NANA,NANA,EOT}},
+{0x11, Power Channel 1,
+ {0x30,0x60,0x61,0x62,0x63,0x70,0x71,EOT},
+ {0x00,0x00,0x62,0x00,0x66,0x01,0x03,EOT}},
+{0x12, Power Channel 2,
+ {0x30,0x60,0x61,0x62,0x63,0x70,0x71,EOT},
+ {0x00,0x00,0x68,0x00,0x6c,0x01,0x03,EOT}},
{EOT}}},
{0x8512, IT8512E/F/G, {
+{NOLDN, NULL,
+ {0x20,0x21,0x22,0x23,0x24,0x25,0x26,0x27,0x28,0x29,
+ 0x2A,0x2B,0x2C,0x2D,0x2E,EOT},
+ {0x85,0x12,0x22,0x01,NANA,0x00,0x00,NANA,NANA,NANA,
+ NANA,NANA,NANA,0x00,NANA,EOT}},
+{0x4, System Wake-Up,
+ {0x30,0x60,0x61,0x62,0x63,0x70,0x71,EOT},
+ {0x00,0x00,0x00,0x00,0x00,0x00,0x03,EOT}},
+{0x5, Mouse,
+ {0x30,0x60,0x61,0x62,0x63,0x70,0x71,0xf0,EOT},
+ {0x00,0x00,0x00,0x00,0x00,0x0C,0x03,NANA,EOT}},
+{0x6, Keyboard,
+ {0x30,0x60,0x61,0x62,0x63,0x70,0x71,0xf0,EOT},
+ {0x00,0x00,0x60,0x00,0x64,0x01,0x03,NANA,EOT}},
+{0xf, Shared Memory/Flash,
+ {0x30,0x60,0x61,0x62,0x63,0x70,0x71,0xf4,0xf5,
+0xf6,EOT},
+ {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+0x00,EOT}},
+{0x10, BRAM,
+ {0x30,0x60,0x61,0x62,0x63,0x70,0x71,0xf3,0xf4,
+0xf5,EOT},
+ {0x00,0x00,0x70,0x00,0x72,0x08,0x00,NANA,NANA,
+NANA,EOT}},
+{0x11, Power Channel 1,
+ {0x30,0x60,0x61,0x62,0x63,0x70,0x71,EOT},
+ {0x00,0x00,0x62,0x00,0x66,0x01,0x03,EOT}},
+{0x12, Power Channel 2,
+ {0x30,0x60,0x61,0x62,0x63,0x70,0x71,EOT},
+ {0x00,0x00,0x68,0x00,0x6c,0x01,0x03,EOT}},
{EOT}}},
{0x8513, IT8513E/F/G, {
{EOT}}},
@@ -582,6 +681,14 @@
OUTB((port == 0x2e) ? 0x55 : 0xaa, port);
}
+static void enter_conf_mode_ite_it8502e(uint16_t port)
+{
+ OUTB(0x85, port);
+ OUTB(0x02, port);
+ OUTB(0x55, port);
+
[coreboot] ectool: Add support to extended commands
Add support to extended EC series
Signed-off-by: Anton Kochkov anton.koch...@gmail.com
---
Property changes on: .
___
Added: svn:ignore
+ .ec.c.swp
Index: ectool.c
===
--- ectool.c (revision 5614)
+++ ectool.c (working copy)
@@ -45,16 +45,17 @@
void print_usage(const char *name)
{
- printf(usage: %s [-vh?V]\n, name);
+ printf(usage: %s [-vh?Vi]\n, name);
printf(\n
-v | --version: print the version\n
-h | --help: print this help\n\n
-V | --verbose: print debug information\n
+ -i | --idx: print IDX RAM\n
\n);
exit(1);
}
-int verbose = 0;
+int verbose = 0, dump_idx = 0;
int main(int argc, char *argv[])
{
@@ -64,10 +65,11 @@
{version, 0, 0, 'v'},
{help, 0, 0, 'h'},
{verbose, 0, 0, 'V'},
+{idx, 0, 0, 'i'},
{0, 0, 0, 0}
};
- while ((opt = getopt_long(argc, argv, vh?V,
+ while ((opt = getopt_long(argc, argv, vh?Vi,
long_options, option_index)) != EOF) {
switch (opt) {
case 'v':
@@ -77,6 +79,8 @@
case 'V':
verbose = 1;
break;
+case 'i':
+dump_idx = 1;
case 'h':
case '?':
default:
@@ -99,13 +103,15 @@
}
printf(\n\n);
- printf(EC IDX RAM:\n);
- for (i = 0; i 0x1; i++) {
+if (dump_idx) {
+printf(EC IDX RAM:\n);
+for (i = 0; i 0x1; i++) {
if ((i % 0x10) == 0)
printf(\n%04x: , i);
printf(%02x , ec_idx_read(i));
- }
- printf(\n\n);
+}
+printf(\n\n);
+}
return 0;
Index: ec.c
===
--- ec.c (revision 5614)
+++ ec.c (working copy)
@@ -38,7 +38,7 @@
debug(.);
}
if (!timeout) {
- printf(Timeout while sending command 0x%02x to EC!\n,
+ debug(Timeout while sending command 0x%02x to EC!\n,
command);
// return -1;
}
@@ -57,8 +57,8 @@
if ((timeout 0xff) == 0)
debug(.);
}
- if (!timeout) {
- printf(Timeout while sending data 0x%02x to EC!\n, data);
+ if (timeout) {
+ debug(Timeout while sending data 0x%02x to EC!\n, data);
// return -1;
}
@@ -89,7 +89,7 @@
debug(.);
}
if (!timeout) {
- printf(\nTimeout while receiving data from EC!\n);
+ debug(\nTimeout while receiving data from EC!\n);
// return -1;
}
@@ -101,15 +101,37 @@
uint8_t ec_read(uint8_t addr)
{
- send_ec_command(0x80);
+ send_ec_command(RD_EC);
send_ec_data(addr);
return recv_ec_data();
}
+uint8_t ec_ext_read(uint16_t addr)
+{
+send_ec_command(WR_EC);
+send_ec_data(0x02);
+send_ec_data(addr 0xff);
+send_ec_command(RX_EC);
+send_ec_data(addr 8);
+
+return recv_ec_data();
+}
+
+int ec_ext_write(uint16_t addr, uint8_t data)
+{
+send_ec_command(WR_EC);
+send_ec_data(0x02);
+send_ec_data(addr 0xff);
+send_ec_command(WX_EC);
+send_ec_data(addr 8);
+
+return send_ec_data(data);
+}
+
int ec_write(uint8_t addr, uint8_t data)
{
- send_ec_command(0x81);
+ send_ec_command(WR_EC);
send_ec_data(addr);
return send_ec_data(data);
Index: ec.h
===
--- ec.h (revision 5614)
+++ ec.h (working copy)
@@ -22,8 +22,8 @@
#include stdint.h
-#define EC_DATA 0x62
-#define EC_SC 0x66
+#define EC_SC 0x66
+#define EC_DATA 0x62
/* EC_SC input */
#define EC_SMI_EVT (1 6) // 1: SMI event pending
@@ -40,12 +40,16 @@
#define BE_EC 0x82 // Burst Enable Embedded Controller
#define BD_EC 0x83 // Burst Disable Embedded Controller
#define QR_EC 0x84 // Query Embedded Controller
+#define RX_EC 0xf0// Read Extended operation
+#define WX_EC 0xf1// Write Extended operation
int send_ec_command(uint8_t command);
int send_ec_data(uint8_t data);
int send_ec_data_nowait(uint8_t data);
uint8_t recv_ec_data(void);
uint8_t ec_read(uint8_t addr);
-
+int ec_write(uint8_t addr, uint8_t data);
+uint8_t ec_ext_read(uint16_t addr);
+int ec_ext_write(uint16_t addr, uint8_t data);
uint8_t ec_idx_read(uint16_t addr);
#endif
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] superiotool: Begin implementation support to IT8512/IT8513
Begin implementation support to IT8512/IT8513
Signed-off-by: Anton Kochkov anton.koch...@gmail.com
---
Property changes on: .
___
Added: svn:ignore
+ .dep.inc
Index: ite.c
===
--- ite.c (revision 5527)
+++ ite.c (working copy)
@@ -33,6 +33,10 @@
{EOT}}},
{0x8511, IT8511E/TE/G, {
{EOT}}},
+{0x8512, IT8512E/F/G, {
+ {EOT}}},
+{0x8513, IT8513E/F/G, {
+ {EOT}}},
{0x8661, IT8661F/IT8770F, {
{NOLDN, NULL,
{0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x20,0x21,0x22,
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] inteltool patch: Added support to ICH9 chipset family
Added support to ICH9 chipset family
Signed-off-by: Anton Kochkov anton.koch...@gmail.com
---
diff -c inteltool//gpio.c inteltool2//gpio.c
*** inteltool//gpio.c 2010-05-07 15:16:54.878775130 +0400
--- inteltool2//gpio.c 2010-05-07 14:49:35.0 +0400
***
*** 114,119
--- 114,138
{ 0x3C, 4, GPIO_USE_SEL Override (HIGH) }
};
+ static const io_register_t ich9_gpio_registers[] = {
+ { 0x00, 4, GPIO_USE_SEL },
+ { 0x04, 4, GP_IO_SEL },
+ { 0x08, 4, RESERVED },
+ { 0x0c, 4, GP_LVL },
+ { 0x10, 4, RESERVED },
+ { 0x14, 4, RESERVED },
+ { 0x18, 4, GPO_BLINK },
+ { 0x1c, 4, GP_SER_BLINK },
+ { 0x20, 4, GP_SB_CMDSTS },
+ { 0x24, 4, GP_SB_DATA },
+ { 0x28, 4, RESERVED },
+ { 0x2c, 4, GPI_INV },
+ { 0x30, 4, GPIO_USE_SEL2 },
+ { 0x34, 4, GP_IO_SEL2 },
+ { 0x38, 4, GP_LVL2 },
+ { 0x3C, 4, RESERVED }
+ };
+
int print_gpios(struct pci_dev *sb)
{
***
*** 124,129
--- 143,158
printf(\n= GPIOS =\n\n);
switch (sb-device_id) {
+ case PCI_DEVICE_ID_INTEL_ICH9DH:
+ case PCI_DEVICE_ID_INTEL_ICH9DO:
+ case PCI_DEVICE_ID_INTEL_ICH9R:
+ case PCI_DEVICE_ID_INTEL_ICH9:
+ case PCI_DEVICE_ID_INTEL_ICH9M:
+ case PCI_DEVICE_ID_INTEL_ICH9ME:
+ gpiobase = pci_read_word(sb, 0x48) 0xfffc;
+ gpio_registers = ich9_gpio_registers;
+ size = ARRAY_SIZE(ich9_gpio_registers);
+ break;
case PCI_DEVICE_ID_INTEL_ICH8M:
gpiobase = pci_read_word(sb, 0x48) 0xfffc;
gpio_registers = ich8_gpio_registers;
diff -c inteltool//inteltool.c inteltool2//inteltool.c
*** inteltool//inteltool.c 2010-05-07 15:16:54.878775130 +0400
--- inteltool2//inteltool.c 2010-05-07 14:39:17.0 +0400
***
*** 45,52
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82G33, P35/G33/G31/P31 },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82Q33, Q33 },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_X58, X58 },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH10R, ICH10R },
! { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8M, ICH8-M },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7MDH, ICH7-M DH },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7M, ICH7-M },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7, ICH7 },
--- 45,59
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82G33, P35/G33/G31/P31 },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82Q33, Q33 },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_X58, X58 },
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_GS45MEGMCH, GS45ME-GMCH }, // Northbridge in GS45
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH10R, ICH10R },
! { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9DH, ICH9DH },
! { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9DO, ICH9DO },
! { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9R, ICH9R },
! { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9, ICH9 },
! { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9M, ICH9M },
! { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9ME, ICH9M-E },
! { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8M, ICH8-M },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7MDH, ICH7-M DH },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7M, ICH7-M },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7, ICH7 },
diff -c inteltool//inteltool.h inteltool2//inteltool.h
*** inteltool//inteltool.h 2010-05-07 15:16:54.878775130 +0400
--- inteltool2//inteltool.h 2010-05-07 14:05:50.0 +0400
***
*** 44,51
--- 44,59
#define PCI_DEVICE_ID_INTEL_ICH7M 0x27b9
#define PCI_DEVICE_ID_INTEL_ICH7MDH 0x27bd
#define PCI_DEVICE_ID_INTEL_ICH8M 0x2815
+ #define PCI_DEVICE_ID_INTEL_ICH9DH 0x2912
+ #define PCI_DEVICE_ID_INTEL_ICH9DO 0x2914
+ #define PCI_DEVICE_ID_INTEL_ICH9R 0x2916
+ #define PCI_DEVICE_ID_INTEL_ICH90x2918
+ #define PCI_DEVICE_ID_INTEL_ICH9M 0x2919
+ #define PCI_DEVICE_ID_INTEL_ICH9ME 0x2917
#define PCI_DEVICE_ID_INTEL_ICH10R 0x3a16
+ #define PCI_DEVICE_ID_INTEL_GS45MEGMCH 0x2a40 // northbridge GS45
+
#define PCI_DEVICE_ID_INTEL_82810 0x7120
#define PCI_DEVICE_ID_INTEL_82810DC 0x7122
#define PCI_DEVICE_ID_INTEL_82830M 0x3575
diff -c inteltool//memory.c inteltool2//memory.c
*** inteltool//memory.c 2010-05-07 15:16:54.878775130 +0400
--- inteltool2//memory.c 2010-05-07 14:25:25.0 +0400
***
*** 54,59
--- 54,63
case PCI_DEVICE_ID_INTEL_82830M:
printf(This northbrigde does not have MCHBAR.\n);
return 1;
+ case PCI_DEVICE_ID_INTEL_GS45MEGMCH:
+ mchbar_phys = pci_read_long(nb, 0x48) 0xfffe;
+ mchbar_phys |= ((uint64_t)pci_read_long(nb, 0x4c)) 32;
+ break;
default:
printf(Error: Dumping MCHBAR on this northbridge is not (yet) supported.\n);
return 1;
diff -c inteltool//pcie.c inteltool2//pcie.c
***
[coreboot] inteltool patch: Added support to ICH9 chipset family
Added support to ICH9 chipset family
Signed-off-by: Anton Kochkov anton.koch...@gmail.com
---
Index: gpio.c
===
--- gpio.c (revision 5527)
+++ gpio.c (working copy)
@@ -114,7 +114,26 @@
{ 0x3C, 4, GPIO_USE_SEL Override (HIGH) }
};
+static const io_register_t ich9_gpio_registers[] = {
+ { 0x00, 4, GPIO_USE_SEL },
+ { 0x04, 4, GP_IO_SEL },
+ { 0x08, 4, RESERVED },
+ { 0x0c, 4, GP_LVL },
+ { 0x10, 4, RESERVED },
+ { 0x14, 4, RESERVED },
+ { 0x18, 4, GPO_BLINK },
+ { 0x1c, 4, GP_SER_BLINK },
+ { 0x20, 4, GP_SB_CMDSTS },
+ { 0x24, 4, GP_SB_DATA },
+ { 0x28, 4, RESERVED },
+ { 0x2c, 4, GPI_INV },
+ { 0x30, 4, GPIO_USE_SEL2 },
+ { 0x34, 4, GP_IO_SEL2 },
+ { 0x38, 4, GP_LVL2 },
+ { 0x3C, 4, RESERVED }
+};
+
int print_gpios(struct pci_dev *sb)
{
int i, size;
@@ -124,6 +143,16 @@
printf(\n= GPIOS =\n\n);
switch (sb-device_id) {
+case PCI_DEVICE_ID_INTEL_ICH9DH:
+case PCI_DEVICE_ID_INTEL_ICH9DO:
+case PCI_DEVICE_ID_INTEL_ICH9R:
+case PCI_DEVICE_ID_INTEL_ICH9:
+case PCI_DEVICE_ID_INTEL_ICH9M:
+case PCI_DEVICE_ID_INTEL_ICH9ME:
+gpiobase = pci_read_word(sb, 0x48) 0xfffc;
+ gpio_registers = ich9_gpio_registers;
+ size = ARRAY_SIZE(ich9_gpio_registers);
+ break;
case PCI_DEVICE_ID_INTEL_ICH8M:
gpiobase = pci_read_word(sb, 0x48) 0xfffc;
gpio_registers = ich8_gpio_registers;
Index: inteltool.h
===
--- inteltool.h (revision 5527)
+++ inteltool.h (working copy)
@@ -44,8 +44,16 @@
#define PCI_DEVICE_ID_INTEL_ICH7M 0x27b9
#define PCI_DEVICE_ID_INTEL_ICH7MDH 0x27bd
#define PCI_DEVICE_ID_INTEL_ICH8M 0x2815
+#define PCI_DEVICE_ID_INTEL_ICH9DH 0x2912
+#define PCI_DEVICE_ID_INTEL_ICH9DO 0x2914
+#define PCI_DEVICE_ID_INTEL_ICH9R 0x2916
+#define PCI_DEVICE_ID_INTEL_ICH90x2918
+#define PCI_DEVICE_ID_INTEL_ICH9M 0x2919
+#define PCI_DEVICE_ID_INTEL_ICH9ME 0x2917
#define PCI_DEVICE_ID_INTEL_ICH10R 0x3a16
+#define PCI_DEVICE_ID_INTEL_GS45MEGMCH 0x2a40 // northbridge GS45
+
#define PCI_DEVICE_ID_INTEL_82810 0x7120
#define PCI_DEVICE_ID_INTEL_82810DC 0x7122
#define PCI_DEVICE_ID_INTEL_82830M 0x3575
Index: pcie.c
===
--- pcie.c (revision 5527)
+++ pcie.c (working copy)
@@ -43,6 +43,7 @@
case PCI_DEVICE_ID_INTEL_82Q35:
case PCI_DEVICE_ID_INTEL_82G33:
case PCI_DEVICE_ID_INTEL_82Q33:
+case PCI_DEVICE_ID_INTEL_GS45MEGMCH:
epbar_phys = pci_read_long(nb, 0x40) 0xfffe;
epbar_phys |= ((uint64_t)pci_read_long(nb, 0x44)) 32;
break;
@@ -51,7 +52,7 @@
case PCI_DEVICE_ID_INTEL_82830M:
printf(This northbrigde does not have EPBAR.\n);
return 1;
- default:
+default:
printf(Error: Dumping EPBAR on this northbridge is not (yet) supported.\n);
return 1;
}
@@ -95,15 +96,15 @@
case PCI_DEVICE_ID_INTEL_82Q35:
case PCI_DEVICE_ID_INTEL_82G33:
case PCI_DEVICE_ID_INTEL_82Q33:
+case PCI_DEVICE_ID_INTEL_GS45MEGMCH:
dmibar_phys = pci_read_long(nb, 0x68) 0xfffe;
dmibar_phys |= ((uint64_t)pci_read_long(nb, 0x6c)) 32;
break;
case PCI_DEVICE_ID_INTEL_82810:
case PCI_DEVICE_ID_INTEL_82810DC:
- case PCI_DEVICE_ID_INTEL_82830M:
printf(This northbrigde does not have DMIBAR.\n);
return 1;
- default:
+default:
printf(Error: Dumping DMIBAR on this northbridge is not (yet) supported.\n);
return 1;
}
@@ -149,6 +150,7 @@
case PCI_DEVICE_ID_INTEL_82Q35:
case PCI_DEVICE_ID_INTEL_82G33:
case PCI_DEVICE_ID_INTEL_82Q33:
+case PCI_DEVICE_ID_INTEL_GS45MEGMCH:
pciexbar_reg = pci_read_long(nb, 0x60);
pciexbar_reg |= ((uint64_t)pci_read_long(nb, 0x64)) 32;
break;
Index: powermgt.c
===
--- powermgt.c (revision 5527)
+++ powermgt.c (working copy)
@@ -21,47 +21,47 @@
#include stdio.h
#include inteltool.h
-static const io_register_t ich7_pm_registers[] = {
- { 0x00, 2, PM1_STS },
- { 0x02, 2, PM1_EN },
- { 0x04, 4, PM1_CNT },
- { 0x08, 4, PM1_TMR },
+static const io_register_t ich9_pm_registers[] = {
+ { 0x00, 2, PM1_STS }, // PM1 Status; ACPI pointer: PM1a_EVT_BLK
+ { 0x02, 2, PM1_EN }, // PM1 Enables; ACPI pointer: PM1a_EVT_BLK+2
+ { 0x04, 4, PM1_CNT }, // PM1 Control; ACPI pointer: PM1a_CNT_BLK
+ { 0x08, 4, PM1_TMR }, // PM1 Timer; ACPI pointer: PMTMR_BLK
{ 0x0c, 4, RESERVED },
- { 0x10, 4, PROC_CNT },
+ { 0x10, 4, PROC_CNT }, // Processor Control; ACPI pointer: P_BLK
#if DANGEROUS_REGISTERS
/* These registers return 0 on read, but reading them may cause
- * the system to enter C2/C3/C4 state, which might hang the system.
+ * the system to enter Cx states, which might hang the system.
*/
- { 0x14, 1, LV2 (Mobile/Ultra Mobile) },
- { 0x15, 1, LV3 (Mobile/Ultra
