Re: [coreboot] [regression] Increased romstage boot time on ASRock E350M1 (AMD Family 14h)
I've been bisecting this today. I see an increase of about 1 second somewhere between commit 35261c0d476ef and commit 730a043fb6c. That's a range of 15 commits On the good commits, I get the boot messages: > APIC: 00 missing read_resources > APIC: 01 missing read_resources > I2C: 00:50 missing read_resources > I2C: 00:51 missing read_resources > Warning: Can't write PCI_INTR 0xC00/0xC01 registers because '> mainboard_picr_data' or 'mainboard_intr_data' tables are NULL > Payload not loaded. On the bad commits, I get the boot messages: > APIC: 00 missing read_resources > APIC: 01 missing read_resources > I2C: 00:50 missing read_resources > I2C: 00:51 missing read_resources > skipping PNP: 002e.307@23 fixed resource, size=0! > skipping PNP: 002e.307@e4 fixed resource, size=0! > skipping PNP: 002e.307@ed fixed resource, size=0! > skipping PNP: 002e.9@2a fixed resource, size=0! > skipping PNP: 002e.9@e0 fixed resource, size=0! > skipping PNP: 002e.a@e7 fixed resource, size=0! > skipping PNP: 002e.d@ec fixed resource, size=0! > Warning: Can't write PCI_INTR 0xC00/0xC01 registers because > 'mainboard_picr_data' or 'mainboard_intr_data' tables are NULL > Payload not loaded. I don't think that this has anything to do with system tools. I can continue bisecting tomorrow, but I expect that the extra time will be found in one of these commits: 68825740 - asrock/e350m1: Add ACPI S3 support d28474b4 - asrock/e350m1: Match super-io GPIO configuration with vendor 3b01cf17 - superio/nuvoton/nct5572d: Add missing logical devices Martin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] Proposal for policy for changing the development guidelines
Alex, Please stop already. We know you don't agree with the decision. Stefan has agreed privately that he shouldn't have submitted those, and that it set a bad precedent. As you say in your email, *YOU* even questioned it when he did it, and he agreed that he would change them from Intel syntax to AT&T syntax. The "change" WAS to formalize an unwritten rule that had been broken a few times in the past. There was significant discussion in several meetings about the reasons for and against standardizing on AT&T syntax. Many of us, including myself, learned x86 assembly using Intel syntax, and find it easier to read. Mixing Intel syntax with AT&T syntax is just confusing and seems like bad practice. Because of this, the decision was made to go with AT&T syntax only. It was NOT done to spite you, whatever you might believe. If you have a reason for using Intel syntax that is really more persuasive than keeping the asm code in the project consistent, feel free to state it. Otherwise, PLEASE let's move on. Martin On Sat, Jan 30, 2016 at 5:44 PM, ron minnich wrote: > > > On Sat, Jan 30, 2016 at 3:06 PM Alex G. wrote: >> >> Furthermore, I believe that this arbitrary >> change was done as an act of spite towards a set of engineers. > > > Well, wow. This just got weird. I think I'm done with this discussion. > > ron > > -- > coreboot mailing list: coreboot@coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] Proposal for policy for changing the development guidelines
On Sat, Jan 30, 2016 at 3:06 PM Alex G. wrote: > Furthermore, I believe that this arbitrary > change was done as an act of spite towards a set of engineers. Well, wow. This just got weird. I think I'm done with this discussion. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] Proposal for policy for changing the development guidelines
On 01/30/2016 11:30 AM, ron minnich wrote: > The change to the guidelines is hence a codification of a practice that > goes back to the project's beginnings. I find that statement inaccurate. This practice had not been an issue in the past, on patches that you yourself approved. Mixed syntaxes have been present in the codebase for a while. See EXHIBIT A. EXHIBIT B shows a patch, mid last year, when a new intel_syntax code was introduced. There was only one comment (following) about the syntax. The patch was approved by you, Ron, without mentioning what you claim has been a practice. > Patrick Georgi, Jul 13, 2015 > follow up patch: we don't really want two _syntaxes in one file_, right? (emphasis added) The comment clearly addresses the issue of mixing two syntaxes within a file. It does not mention "a practice that goes back to the project's beginnings", nor does it mention that either "AT&T syntax is to be used through-out the project", or "No new Intel syntax code is allowed into the project." EXHIBIT C, shows another such patch that, you, have also approved, Ron. The comment got no replies. > Ronald G. Minnich, Oct 30 10:43 AM > why intel syntax _in a file that is att syntax_? it's a real oportunity for a buggy time.+2'ing because you promised me you're rewrite it. (emphasis added) Notice how the issue here is strictly the mixing of syntaxes within the same file. EXHIBIT D shows another such patch, this time approved by me. I have made a comment about the issue of mixed syntax. > Alexandru Gagniuc, Jul 17, 2015 > Really? Mixed syntax in the same file? This also addresses strictly the issue of mixing of syntaxes within the same file. EXHIBIT E shows another patch, that you yourself approved. This time, there was not even a mention of mixed syntaxes. I conclude from these, that your assertion that this has been an unspoken rule, is not true. Furthermore, I believe that this arbitrary change was done as an act of spite towards a set of engineers. Also, since you, and the rest of the coreboot leadership have shown a pattern of first discussing changes to the project publicly, on the mailing list, I conclude that a discussion about this issue was deliberately avoided in order to prevent those engineers, as well as other coreboot community members, from presenting their arguments. Alex ### EXHIBIT A: Presence of .intel_syntax ### * 4a30ab9 cpu/amd: remove .intel_syntax * 0302b06 arch/x86: remove .intel_syntax * c7b2b7c cbfstool: Fix potential error when using hash attribute $ git reset --hard c7b2b7c67dc8afb52c3dc8e9297e5ed81fa22674 $ git grep intel_syntax src/arch/x86/boot.c:".intel_syntax noprefix\n\t" src/arch/x86/c_start.S:.intel_syntax noprefix src/arch/x86/wakeup.S: .intel_syntax noprefix src/cpu/amd/agesa/cache_as_ram.inc: .intel_syntax noprefix src/cpu/amd/pi/cache_as_ram.inc: .intel_syntax noprefix ### EXHIBIT B: src/arch/x86/[boot.c, c_start.S] ### $ git blame src/arch/x86/boot.c |grep intel_syntax 9693885a src/arch/x86/boot/boot.c (Stefan Reinauer 2015-06-18 01:23:48 -0700 63) ".intel_syntax noprefix\n\t" $ git blame src/arch/x86/c_start.S |grep intel_syntax 9693885a src/arch/x86/lib/c_start.S (Stefan Reinauer 2015-06-18 01:23:48 -0700 403) .intel_syntax noprefix $ git show 9693885a commit 9693885ad88d21ead7bd9ebc32f3e4901841b18b Author: Stefan Reinauer Date: Thu Jun 18 01:23:48 2015 -0700 x86: Port x86 over to compile cleanly with x86-64 Change-Id: I26f1bbf027435be593f11bce4780111dcaf7cb86 Signed-off-by: Stefan Reinauer Signed-off-by: Scott Duplichan Reviewed-on: http://review.coreboot.org/10586 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand Reviewed-by: Ronald G. Minnich ### EXHIBIT C: src/arch/x86/wakeup.S ### $ git blame src/arch/x86/wakeup.S |grep intel_syntax ac901e6b src/arch/x86/wakeup.S (Stefan Reinauer 2015-07-31 16:46:28 -0700 32).intel_syntax noprefix $ git show ac901e6b commit ac901e6bedc98d115ebb8089afd8f67aef39c000 Author: Stefan Reinauer Date: Fri Jul 31 16:46:28 2015 -0700 wakeup: Switch back to 32bit mode first On x86_64 we need to leave long mode before we can switch to 16bit mode. Oh joy! When's my 64bit resume pointer coming? Why didn't this get caught earlier? Seems the Asrock E350M2 didn't do Suspend/Resume? Yes, I know it's Intel syntax. Will be converted to AT&T syntax as soon as the whole thing actually works.. 8) Change-Id: Ic51869cf67d842041f8842cd9964d72a024c335f Signed-off-by: Stefan Reinauer Reviewed-on: http://review.coreboot.org/11106 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich ### EXHIBIT D: src/cpu/amd/agesa/cache_as_ram.inc ### $ git blame src/cpu/amd/agesa/cache_as_ram.inc |grep intel_syntax 67b9430b src/cpu/amd/agesa/cache_as_ram.inc (Stefan Reinauer 2015-06-18 01:14:01 -0700 66) .intel_syntax noprefix $ git show 67b9430b co
Re: [coreboot] [RFC] Proposal for policy for changing the development guidelines
The requirement for ATT syntax was set informally in 2001, when I had some partners from U. Md. who were advocating for Intel syntax. We discovered that having two syntaxes is unworkable. >From that time we assumed that everyone would use a common syntax. It certainly never occurred to us that we had to say it explicitly, since it seems obvious that uniform assembly syntax is a good idea, and that the syntax we currently use, and that our tools use, should determine the assembly syntax for new code. The change to the guidelines is hence a codification of a practice that goes back to the project's beginnings. thanks ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] F2A85-M - Richland CPU support doesn't work.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 2016-01-29 14:19, Patrick Georgi a écrit : 2016-01-28 14:22 GMT+01:00 Loic : I have to apply the patch as an attachment for it to work. I modify the options in Kconfig because coreboot doesn't start quickly without this... Thank you. I pushed the patch to gerrit, split for CPU and mainboard: https://review.coreboot.org/#/c/13510/ https://review.coreboot.org/#/c/13511/ Thanks a lot. Loic -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQYcBAEBAgAGBQJWq3NUAAoJEOU2PAjT6toD1Ugv/j0d5Wj34Q5CCNWwaUtK0if6 m0zy0mwEHdy2LH5D8ZiWSw8M5Sb+URSf2H/hQiiGjk4FljyIc5V/aye0ZqrFXkvz UlkQVR54rzQ7MFuZFGi8qFqMM1eUdiiaxaYU1xP5TbM7m6bWKqGF7E3iueCWxwMD IOchIWvejRAGbDep4yL0B2seR2BqkVZlsfSV6weAjLOhe43vae2oa7BPc4VH9cFx 1RNObzrMxT2GEU7XUFWkkpCG7Hw+wkfMEARDB9YTlO86XD75lOhh82tAEg1Rj+TE c9ou3SlY5xVmKXGYImGZQ+1K6hgIgmNB/a72+r4z5OEKcU93ua7On30w2o7wa47y BQQ1peqPJHaN5sVS9qvnkrjtjbVi7+dqwKvdtgi6lYk+jkWdTUkTlfu5Kg4Ud10g 8J6ZGXrkuISLChYaAJ3kAu9gaXEYl8bOwuqWJPCVM3t19SMftJf1X/gGWFWl1ypa sCes0RF463+GMfTbJnIHJvxZda6dc8KNTalRWPLYVyXl5hM4vtoUhxH7yCATNOdq fj8N+pgDbzfYWqZyv4xxJxOBtaEZdNGl9xgx1V8pon/6u/bw7VAznixk+hf0uDL9 UrnKLMGVQAFgr3x2ExhO4hoLtPt5IJWRxUOGTKW8JFLlARkt53mfNjVjJ1tEy62Z kD2HQb7U2714dM1Id9fntvz+McgdQzbR5fx6G4CtkGycd9yYlkRvx+NvfAUczyDr jU3nmTIZX7MsgNm5hqizWHJTrJRnT5l4O4CDpaqBzMW5RghIUOTjSc1SNrpV0XQl eCRDhov0Fk32ejyA83l7/m+Nxb7thOmJYBnUVtfQegu7kRrfhu4UFa5oO21vyflq GZzqODT2l3BqqdT5Ak74C0602Eju0Vgycn0MEjj4YbLtJCG4t4tHS7xmWFmvjWh4 tnkL32WGI4UY4pGbriAEnaXY97YJBX68JjyPoAagvg8oBfzKN/WnZ1WNGceA1zfY AGcRct3hE+T7uiiueqLwPlF8N2cOND1Bc4qSBu+rm0eTX7HCgHVizYSoC3p8PJD5 xKmM6pl/qFwLXPBW23egHeiNcAE3sQ4xZbapurL1dAs9jiKdU1EzyeH7IbwKKyM6 ZAJlf2aPm4/rKqnzElGI7PNUCaj2OG6jhvOE9vqrtVWlOmx0zoshGg1XSreLe/hH m7kdR2TRVqcaiPGq7H7nX2rixfiWdB00Ev5U4bMf+svNu1H95/OMjwYggLGG8BJu ulKNZ21oIM3BVk7vbn1XLTjozPQzlU+MTv8er8mVB/2XGLAG5zinp6ACA/1zwKOH ejKk4AwsNRTUfGYb++xX7AgBRz9xY4Fn79l5GjzwlGRvvjKnBHrf+dzpenQ42+Vg yfYApeIwukIpeVWDnuFAv7AmiLhUHV/8CTeDtfaTDM+OQu8DkJorBl+h3hFEaJXu tDS30mwWopoJjqTmWIt2FfLDi/0yBtuur/tF9tiQ1atSXVoB15xJN1ph2ir5B5sT tsVdFFFAt8KvrnXhHhzMXv/tvMZ4KuQyvaJIFQCv+qDOX0BbGYLHiOKf0XWlOy/0 ejofZD6XOK2qKpWIjdYTOfsKxHk/DEnp3bT4vtsSJCTAnAi+qjfqfwmVDArojTFS D4Xs2yg9CPd1BzeMT6i6Cn4R4Ade8VAEumgZsZJkSQyeAUaCL/+GpKrSOqPmWcOj KgB9gsy1fl7ZqO92kh5RfTGMhuTHeLiAXZiLEXTQghLKbqz8RWQFii0LXI4/hutI HezS5Oy/AWWlpH+0+dt8oI9zrVEEhGeE0vkFaOQxbj/YzqxWGiUQWaukVjc+J4eO C4aDLE/Gl+rAzVT/XnbWcaaUj7HpOEKUUtyk8N9VAnhy/Eud48YlRARO3hHl9AWP yeq0Ap5I1L1ytvFH1e/m0BSuNp2kQn6SJiTx0dqs1gRluuHtSVaPRYvfPY5r0wlr HWi2FXuq9fceFo3Aus/DjP1vjbA9weKmKmm4501LGLFaIlxTljVGz/XritIfvh2b 0mC6g2x73dRtC6iolTSJId+ZRq2iq67utKKYNlGl6Q== =HRkd -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: Announcing coreboot 4.3
A new post titled "Announcing coreboot 4.3" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/01/29/announcing-coreboot-4-3/ Dear coreboot community, today marks the release of coreboot 4.3, the third release on our time based release schedule. Since the last release, 1030 commits by 114 authors added a net total of 17500 lines to the source code. Thank you to all who contributed! The release tarballs are available at http://www.coreboot.org/releases/. There’s also a 4.3 tag and branch in the git repository. Besides the usual addition of new mainboards (14) and chipsets (various), a big theme of the development since 4.2 was cleaning up the code: 20 mainboards were removed that aren’t on the market for years (and even hard to get on Ebay). For several parts of the tree, we established tighter controls, making errors out of what were warnings (and cleaning up the code to match) and provided better tests for various aspects of the tree, and in general tried to establish a more consistent structure across the code base. Besides that, we had various improvements across the tree, each important when using the hardware, but to numerous for individual shout outs. Martin compiled a list that’s best posted verbatim. Thanks Martin! Log of commit 529fd81f640fa514ea4c443dd561086e7c582a64 to commit 1bf5e6409678d04fd15f9625460078853118521c for a total of 1030 commits: Mainboards Added 14 mainboards – asus/kfsn4-dre_k8: Native init Dual AMD K8 CPUs & Nvidia CK804 southbridge – esd/atom15: Bay Trail SOC mainboard using Intel’s FSP – gigabyte/ga-g41m-es2l: Intel Core 2 / Native init x4x NB / I82801GX SB – google/guado: Intel Broadwell chromebox (Asus Chromebox CN62) – google/oak: Mediatek MT8173 SoC chromebook – google/tidus: Intel Broadwell chromebox (Lenovo ThinkCentre Chromebox) – google/veyron_emile: Rockchip RK3288 SoC board – intel/d510mo: Native init Intel Pineview with Intel I82801GX southbridge – intel/littleplains: Intel Atom c2000 (Rangeley) SoC board – intel/stargo2: Intel Ivy Bridge / Cave Creek usint Intel’s FSP – lenovo/r400: Intel Core 2 / Native init GM45 NB / Intel I82801IX SB – lenovo/t500: Intel Core 2 / Native init GM45 NB / Intel I82801IX SB – purism/librem13: Intel Broadwell Laptop using Intel MRC – sunw/ultra40m2: Native init Dual AMD K8 Processors & Nvidia MCP55 SB Removed 20 mainboards – arima/hdama – digitallogic/adl855pc – ibm/e325, e326 – intel/sklrvp – iwill/dk8s2, dk8x – newisys/khepri – tyan/s2735, s2850, s2875, s2880, s2881 & s2882 – tyan/s2885, s2891, s2892, s2895, s4880 & s4882 Improvements to mainboards – amd/bettong: fixes to Interrupts, Memory config, S4, EMMC, UARTS – asus/kgpe-d16: IOMMU and memory fixes, Add CMOS options, Enable GART – intel/strago: GPIO, DDR, & SD config, FSP updates, Clock fixes – ACPI fixes across various platforms – Many individual fixes to other mainboards Continued updates for the Intel Skylake platform – google/chell, glados, & lars: FSP & Memory updates, Add Fan & NHLT support – intel/kunimitsu: FSP & GPIO updates, Add Fan & NHLT (audio) support Build system – Update build to use FMAP based firmware layout with multiple cbfs sections – Enable Kconfig strict mode – Kconfig warnings are no longer allowed. – Enable ACPI warnings are errors in IASL – warnings are no longer allowed. – Tighten checking on toolchains and give feedback to users if there are issues – Updates to get the ADA compiler to work correctly for coreboot – Various improvements to Makefiles and build scripts – Cleanup of CBFS file handling Utilities – cleanups and improvements to many of the utilities – cbfstool: Many fixes and extensions to integrate with FMAP – Add amdfwtool to combine AMD firmware blobs instead of using shell scripts. – Toolchain updates: new versions of GMP & MPFR. Add ADA. – Updates for building on NetBSD & OS X Payloads – SeaBIOS: Update stable release to 1.9.0 – coreinfo: fix date, hide cursor, use crosscompiler to build – libpayload: updates for cbfs, XHCI and DesignWare HCD controllers ARM – Added 1 soc: mediatek/mt8173 – Various fixes for ARM64 platforms X86 – Added 2 northbridges: intel/pineview & x4x – Removed 1 northbridge: intel/i440lx – Added 1 southbridge: intel/fsp_i89xx – Removed 2 southbridge(s): intel/esb6300 & i82801cx – Rename amd/model_10xxx to family_10h-family_15h. – ACPI: fix warnings, Add functions for IVRS, DMAR I/O-APIC and HPET entries – Work in many areas fixing issues compiling in 64-bit – Numerous other fixes across the tree Areas with significant work on updates and fixes – cpu/amd/model_fxx – intel/fsp1_x: Fix timestanps & postcodes, add native CAR & microcode – nb/amd/amdfam10: Add S3, voltage & ACPI, speed fixes & MANY other changes – nb/amd/amdmct: Add S3, mem voltage, Fix performance & MANY other changes – nb/intel/sandybridge: Add IOMMU & ACPI DMAR support, Memory cleanup – soc/intel/braswell: FSP & ACPI updates, GPIO & clock Fixes – soc/intel/fsp_baytrail: GPIO, microcode and Interrupt u
[coreboot] Memory Initialization
I am new to coreboot and would like to change some of the memory initialization code to recognize a currently unsupported 240-pin DDR3 module. The intention is to load coreboot on a Supermicro H8SCM motherboard. Can someone please help identify where the code is that performs the memory initialization. (reads the SPD, configures/trains memory, performs pattern tests and creates e820 map). Thank you Simon -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] Proposal for policy for changing the development guidelines
2016-01-30 15:26 GMT+01:00 Paul Menzel : > But then, I wondered why I was not aware of that section in the > development guidelines [2], and wanted to read up on it. While at it, I > also looked through the history, and there I see, that it was only > added [3] on the same day. We had mentions of intel assembler syntax on the list over the decades (all 1.5 of them, proposed starting point for web based searches: site:www.coreboot.org/pipermail/coreboot/ -gerrit intel syntax), and it was always clear that coreboot uses AT&T syntax for x86. The collective consciousness (with apologies to Durkheim) was pretty consistent here. The reason why this was added now is that people insisted that as long as there's no written down hard rule about it, everything is fair game. Personally, I'm not a huge fan of this model, but after the power games surrounding this topic already took forever (may include traces of hyperbole), it was the most economic decision to just nail it down. >4. If there is objection, and no agreement can be reached, the > proposal(s) should go up for a vote. The vote period should be at > least one week. There exists no electorate (or to state it more constructively: who gets to vote?) > No idea, but I’d think it’d be only fair to revert the changes made > this months, and discuss them first. With all the time already wasted on the assembly syntax issue (and no chance for a different outcome), and everything else looking like context-preserving clarifications (eg. GPL -> GPLv2) or harmless updates (bug tracker) I don't see a need for that. This also assumes both that your proposal takes effect, and is effective retroactively. The main problem here (if any) was the lack of notification after changing the document. Given the limited impact (there were no other instances of .intel_syntax out there, and folks generally knew to use AT&T syntax), it probably wasn't considered a big deal. Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [RFC] Proposal for policy for changing the development guidelines
Dear coreboot folks, I’d like to request for a policy on how the coreboot development guidelines are changed. ### Background ### The discussion in patch set #11784 [1] confused me quite a bit. Especially, seeing Aaron’s quote of the development guidelines I thought, why is this even discussed. > https://www.coreboot.org/Development_Guidelines#Assembly_Language states: > "To keep the code consistent across the different supported > platforms, AT&T syntax is to be used through-out the project. We are > working actively on replacing the existing Intel syntax code with > AT&T syntax. No new Intel syntax code is allowed into the project." But then, I wondered why I was not aware of that section in the development guidelines [2], and wanted to read up on it. While at it, I also looked through the history, and there I see, that it was only added [3] on the same day. I thought that editing rights for that page were blocked, because changes without discussion shouldn’t be made. Further on, I’d like changes to the development guidelines be announced in the official forum, which is this mailing list, so that developers, normally not reading the guidelines every day, are made aware of that. ### Proposal ### Changes to the development guidelines can only be made, when the following criteria are met. 1. A proposal of the change was sent to the list tagged with [RFC]. 2. The proposal was up for discussion for at least two weeks. 3. If there is no objection, the change can be made. 4. If there is objection, and no agreement can be reached, the proposal(s) should go up for a vote. The vote period should be at least one week. 5. Changes have to be announced to the list. ### Past changes ### No idea, but I’d think it’d be only fair to revert the changes made this months, and discuss them first. Thanks, Paul [1] https://review.coreboot.org/11784 [2] https://www.coreboot.org/Development_Guidelines#Assembly_Language [3] https://www.coreboot.org/index.php?title=Development_Guidelines&type=revision&diff=17850&oldid=17709 signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] HPET: Minimum Clock Ticks and HPET_MIN_TICKS
Dear coreboot folks,
thanks to Timothy Pearson’s patch set #13159 (southbridge/amd/sb700:
Set HPET min tick value to RPR recommendation) [1] I became aware of
the Kconfig option `HPET_MIN_TICKS`.
It looks like quite some boards (southbridges) don’t set it and it then
gets set to 0 in `src/arch/x86/acpi.c`.
```
509 void acpi_create_hpet(acpi_hpet_t *hpet)
510 {
511 acpi_header_t *header = &(hpet->header);
512 acpi_addr_t *addr = &(hpet->addr);
513
514 memset((void *)hpet, 0, sizeof(acpi_hpet_t));
515
516 /* Fill out header fields. */
517 memcpy(header->signature, "HPET", 4);
518 memcpy(header->oem_id, OEM_ID, 6);
519 memcpy(header->oem_table_id, ACPI_TABLE_CREATOR, 8);
520 memcpy(header->asl_compiler_id, ASLC, 4);
521
522 header->length = sizeof(acpi_hpet_t);
523 header->revision = 1; /* Currently 1. Table added in ACPI 2.0. */
524
525 /* Fill out HPET address. */
526 addr->space_id = 0; /* Memory */
527 addr->bit_width = 64;
528 addr->bit_offset = 0;
529 addr->addrl = CONFIG_HPET_ADDRESS & 0x;
530 addr->addrh = ((unsigned long long)CONFIG_HPET_ADDRESS) >> 32;
531
532 hpet->id = *(unsigned int*)CONFIG_HPET_ADDRESS;
533 hpet->number = 0;
534 hpet->min_tick = CONFIG_HPET_MIN_TICKS;
535
536 header->checksum = acpi_checksum((void *)hpet, sizeof(acpi_hpet_t));
537 }
```
That’s the case on the ASRock E350M1.
```
$ more /tmp/hpet.dsl
/*
* Intel ACPI Component Architecture
* AML/ASL+ Disassembler version 20160108-32
* Copyright (c) 2000 - 2016 Intel Corporation
*
* Disassembly of hpet.dat, Sat Jan 30 12:37:21 2016
*
* ACPI Data Table [HPET]
*
* Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue
*/
[000h 4]Signature : "HPET"[High Precision Event
Timer table]
[004h 0004 4] Table Length : 0038
[008h 0008 1] Revision : 01
[009h 0009 1] Checksum : 71
[00Ah 0010 6] Oem ID : "CORE "
[010h 0016 8] Oem Table ID : "COREBOOT"
[018h 0024 4] Oem Revision :
[01Ch 0028 4] Asl Compiler ID : "CORE"
[020h 0032 4]Asl Compiler Revision :
[024h 0036 4]Hardware Block ID : 43538210
[028h 0040 12] Timer Block Register : [Generic Address Structure]
[028h 0040 1] Space ID : 00 [SystemMemory]
[029h 0041 1]Bit Width : 40
[02Ah 0042 1] Bit Offset : 00
[02Bh 0043 1] Encoded Access Width : 00 [Undefined/Legacy]
[02Ch 0044 8] Address : FED0
[034h 0052 1] Sequence Number : 00
[035h 0053 2] Minimum Clock Ticks :
[037h 0055 1]Flags (decoded below) : 00
4K Page Protect : 0
64K Page Protect : 0
Raw Table Data: Length 56 (0x38)
: 48 50 45 54 38 00 00 00 01 71 43 4F 52 45 20 20 // HPET8qCORE
0010: 43 4F 52 45 42 4F 4F 54 00 00 00 00 43 4F 52 45 // COREBOOTCORE
0020: 00 00 00 00 10 82 53 43 00 40 00 00 00 00 D0 FE // ..SC.@..
0030: 00 00 00 00 00 00 00 00 //
```
As Timothy did, I guess this should be fixed. How should that be done?
1. Define a default value in `src/arch/x86/Kconfig` similar to
`HPET_ADDRESS` and allow an override `HPET_MIN_TICKS_OVERRIDE`?
2. Or does this need to be set in every southbridge?
Thanks,
Paul
[1] https://review.coreboot.org/13159
signature.asc
Description: This is a digitally signed message part
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
