coreboot April 2020

coreboot@coreboot.org

39 participants
36 discussions

[RFH] Test link time optimization (LTO)
by Paul Menzel 28 Apr '20

28 Apr '20

Dear coreboot folks, Despite ever increasing flash ROM chip sizes, small images are still desired for faster boot times, faster flash times, and more space for payloads, which is sometimes needed for adding several payloads (including GRUB/TianoCore) or Linux payloads. Jacob Garber did great work to achieve this goal by enabling Link Time Optimization (LTO) for coreboot [1] and libpayload [2]. While doing this, he also found and fixed several bugs in the code base. Currently, it fails for AMD AGESA boards due handling of illegal globals. > Yes, this is a current limitation of LTO right now. Because the > object files are all lumped together into a single unit, all > information about where the symbols came from is lost, so > EXCLUDE_FILE is unable of excluding the AGESA objects from the > illegal_globals check. Tracing where a symbol came from has been > implemented in LLVM [0], but I'm not sure if it's on the roadmap for > GCC. For now it's probably best to disable LTO when compiling AGESA. > > [0]: https://llvm.org/devmtg/2017-10/slides/LTOLinkerScriptsEdlerVonKoch.pdf If somebody has a solution for that, that’d be great. It’d be great, if more people could test this, on your boards, and report back. I propose, to submit the change-sets before the next release, and to enable LTO for libpayload by default, and to disable it for coreboot by default. Big thanks again to Jacob for doing this. (My attempt doing this for GRUB failed. ;-)) Kind regards, Paul [1]: https://review.coreboot.org/c/coreboot/+/38989 [2]: https://review.coreboot.org/c/coreboot/+/38291

2 1

GSoC interested student - short (late) presentation and several questions
by Antonin Reitz 28 Apr '20

28 Apr '20

Hello, As a GSoC candidate, I have been digging for some time within coreboot repos, building stuff, booting different OSes with different payloads and different tweaks, and so on. I have applied to two coreboot projects: 1) "Fully support building coreboot with the Clang compiler", 2) "Port GRUB2 to RISC-V". As an ENS master student intending to pursue in the academic field, I chose : - coreboot organization because, very briefly, I believe in open hardware/firmware and am very interested in system development and computer security, especially in the intersection of both ; - these 2 possible projects because, again very briefly, I am highly interested since a few years in both the LLVM toolchain and the RISC-V architecture. I already worked on research projects related to all of this during research internships, and think of this GSoC as an opportunity to learn more while contributing to one of the open source projects I am the most interested in. - Due to COVID-19 outbreak and corresponding countermeasures in France, I do not have access currently to all of the hardware normally at my disposal. Even if I have enough resources to work remotely in a reasonable manner, I try to optimize my setup, and think about using ccache (when useful) and distcc (when possible). Thankfully, I have access to some of my school resources that should allow me to work efficiently, a few mid-range workstations. The first topic would probably be more resource-intensive. I already have some experience with ccache. Do you have any additional advice? It could really be useful (and interesting)? - I also tried to build coreboot toolchain targets on different Linux distributions, and I have some trouble on Arch Linux with the clang target. I managed to bisect it to an issue between gcc 9.2.0-4 and gcc 9.3.0-1. I did not find anything about this previously, is there something I am missing and I should be aware of, before I go further? Please find attached the error message, due to a narrowing conversion. It is quite late to get in touch with the developers team, but I had to cope with issues related to COVID-19. I am very sorry about that, but now that it is done, I am ready for this GSoC. Best regards, Antonin Reitz

1 0

Adding unit testing to the tree
by Patrick Georgi 28 Apr '20

28 Apr '20

Hi everybody, There's some fine work by Jan on Gerrit on the issue of adding unit testing infrastructure to our tree and I'd like to see it merged soon. So far, most feedback was by Google folks so this is a heads up for everybody (and especially those not at Google) to take a look and offer your input. The design doc, build infra and demonstration test cases can be found at https://review.coreboot.org/39893 and the commits that are based on it. I aim for inclusion near the end of the week unless there's feedback showing weaknesses in the plan or implementation. Thanks, Patrick

1 0

Re: CBFS pointer problem with SeaBios and Apollo Lake platform
by Wolfgang Kamp - datakamp 27 Apr '20

27 Apr '20

Hallo Alexander, danke! Ich werde das austesten. Viele Grüße Wolfgang -----Ursprüngliche Nachricht----- Von: Alexander 'lynxis' Couzens [mailto:lynxis@fe80.eu] Gesendet: Montag, 27. April 2020 12:52 An: Wolfgang Kamp - datakamp <wmkamp(a)datakamp.de> Betreff: Re: [coreboot] CBFS pointer problem with SeaBios and Apollo Lake platform Hallo Wolfgang, hier ist ein alter HACK/Patch von mir, als ich Probleme mit dem Seabios hatte. Ist schon etwas länger her, eventuell hilft der dir. e.g. CONFIG_CBFS_LOCATION=0xffc23038 Schönen Gruß, lynxis / Alexander On Thu, 23 Apr 2020 08:15:42 +0000 Wolfgang Kamp - datakamp <wmkamp(a)datakamp.de> wrote: > Hello, > > Am I correct that the problem still exists that SeaBios can't find the > CBFS in apl platform? > > Kind regards, > Wolfgang Kamp -- Alexander Couzens mail: lynxis(a)fe80.eu jabber: lynxis(a)fe80.eu gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604

1 0

CBFS pointer problem with SeaBios and Apollo Lake platform
by Wolfgang Kamp - datakamp 27 Apr '20

27 Apr '20

Hello, Am I correct that the problem still exists that SeaBios can't find the CBFS in apl platform? Kind regards, Wolfgang Kamp

4 7

libgfxinit: Panel Backlight with Apollo Lake (Broxton)
by Wolfgang Kamp - datakamp 27 Apr '20

27 Apr '20

Hello, I found out that the panel backlight enable function in libgfxinit for Broxton platform (Intel x5-E3940) will not work for me. The Backlight Enabling Sequence Description in the Intel document Doc Ref # IHD-OS-BXT-Vol 7-05.17 says: 1. Set frequency and duty cycle in BLC_PWM_FREQ Frequency and BLC_PWM_DUTY Duty Cycle. 2. Enable PWM output and set polarity in BLC_PWM_CTL PWM Enable and PWM Polarity. It is also necessary to set Bit 2 in the PP_CONTROL register to "1" to enable Backlight Power. In "hw-gfx-gma-panel.adb" in the function Backlight_On only BXT_BLC_PWM_CTL_ENABLE will be set and PP_CONTROL setting is excluded through the If statement. Also I can't find any call of the Set_Backlight function and I'm missing the setting of the PWM frequency divider in this function. Most panels will work with 200Hz PWM. Can anyone help? Kind regards, Wolfgang Kamp

2 2

Re: Planning the next coreboot release
by Keith Hui 23 Apr '20

23 Apr '20

Hi Patrick, > 1. If you have anything big that you want to get in before the release, Can we get [38354] merged before 4.12 is cut? This is the last patch needed to get onboard SCSI on Asus P2B-LS working - all its prerequisites have been merged. I have a new board and more 440BX platform stuff in the pipeline and I understand they will have to wait. Thanks Keith [38354] https://review.coreboot.org/c/coreboot/+/38354

1 0

Memtest86+ stuck
by Max Zim 23 Apr '20

23 Apr '20

Hello, I discovered the issue with Memtest86+ stuck on my Thinkpad x230 on the very first tests. Always on the same point, 52%. Every release since 4.8 works this way, coreboot 4.7 works fine. Is this a known bug?

6 11

Beginners questions
by JPT 22 Apr '20

22 Apr '20

Hi, I successfully built coreboot for my X220. Now I got a few questions: - tiano and grub payloads fail building. Is this normal? I build from master branch. (there seems to be a bug with config, conflicting SeaBIOS and Tianocore) - which branch or tag should I build stable images from? - 700 KB Tianocore should fit into 8 MB flash? - what is the preferred payload for a recent 64 bit Linux? - which payloads deliver the usual BIOS functions OSes rely on, like ACPI etc? - Wow, SeaBIOS almost boots DOS, where original UEFI couldn't at all. anyone interested in bug-reports regarding the "almost"? thank you very much JPT

2 1

Help unsubscribe
by Dan Collins 21 Apr '20

21 Apr '20

Help unsubscribe -----Original Message----- From: coreboot-request(a)coreboot.org <coreboot-request(a)coreboot.org> Sent: 20 April 2020 01:08 To: coreboot(a)coreboot.org Subject: coreboot Digest, Vol 182, Issue 10 Send coreboot mailing list submissions to coreboot(a)coreboot.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to coreboot-request(a)coreboot.org You can reach the person managing the list at coreboot-owner(a)coreboot.org When replying, please edit your Subject line so it is more specific than "Re: Contents of coreboot digest..." Today's Topics: 1. T530 with discrete GPU (David Hobach) 2. OCP blog for coreboot on server (Jonathan Zhang) 3. [gerrit] Impossible to delete some of the ancient changes (Mike Banon) 4. Re: Some problems with graphic display when using coreboot + seabios. (Ivan Ivanov) 5. Re: [PATCH v4 1/2] firmware: google: Expose CBMEM over sysfs (Samuel Holland) ---------------------------------------------------------------------- Date: Mon, 13 Apr 2020 10:11:16 +0200 From: David Hobach <tripleh(a)hackingthe.net> Subject: [coreboot] T530 with discrete GPU To: coreboot <coreboot(a)coreboot.org> Message-ID: <bd6a5c59-2550-f7b4-16a6-e21211d48603(a)hackingthe.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms010204000102080903030405" This is a cryptographically signed message in MIME format. --------------ms010204000102080903030405 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi all, did anyone get the discrete GPU working on a T530 with coreboot? All I got so far was a blank screen when trying to switch to "Discrete=20 Only" with nvramtool. With "Integrated Only" it doesn't even show up in=20 lspci. Interestingly, both showed up on the first reboot after the "Discrete=20 Only" change, but the blank screen happened after the first full=20 shutdown. Hardware... The main problem there: Without dGPU support, the external display port on a T530 docking=20 station is not driven at all - it is hardwired to the GPU, if present.=20 So when buying one of those, it actually hurts to have a dGPU. Best Regards David --------------ms010204000102080903030405 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC CIMwggh/MIIGZ6ADAgECAgMT1NgwDQYJKoZIhvcNAQENBQAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNp Z25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcwHhcN MTgxMDEwMTgxNzQyWhcNMjAxMDA5MTgxNzQyWjBBMRgwFgYDVQQDEw9DQWNlcnQgV29UIFVz ZXIxJTAjBgkqhkiG9w0BCQEWFnRyaXBsZWhAaGFja2luZ3RoZS5uZXQwggQiMA0GCSqGSIb3 DQEBAQUAA4IEDwAwggQKAoIEAQDuXAoDd3IYI7UTMkpkpwXzVGxYTG7G6QSjl8lszjNCLA5c k2QvskXWJH9zbjUO++9wREbkvq+Ws8Ddlgj0ldX7h6XZDE4EuPD3L7VEakD1vSL6Z4jV7Vna 6eLOD34JueYVtfslujgUvjdJr1lOQqf6T+SCibymfPo8jcOxT85duRI/uzDofHvYT/z/QIWR A5LBEs4VXVxpq7R8y3ffrEJuj/RA3KATXm0s0dgVdYh2e6bpu8AuES8D+N5Zn2QzYu9udNBF GZ/Z1RvVYRXTYQlBZ8wAF+KOT+Civsb22b0w4ZXDh9Rzn7M0D3yrNzxkLhJmyoB5ALiWW5Iv HHiwEfNMPOs7OYsGf9MAcIIsewFAmFD5jOOpsQVZ353i7frMItj0wDB8bVmEgPxGUof9fv4q +fMvjI+mfvju7FXQb5IPWYvwGR0pO4eQigRW3qEtGu/rizBwwJmGa5Aum9S3lHazS1TF9uxQ EohvHWNp/s3hSgFFFswUmyROND9nlcU7Y1tcL7GnEgPx0Kq2h/wZ2WR9Uro9g8EKqYoAOsWG yNg9jSKjHWCB8boGlQRz3uNv6KgOBJjJN/sTTwuaduDkGxcRCRGK+nhwZ9j9EhHALsx9diRs uVlqfKkAPgOvzQZy5RMDKKi11k8xeu1ubOdVsANIwW6BfNKOQMTI3wI5fDlsMM+nmE/QZCV6 QlUuTHaxcFeNeHtAl6lxl6MGAV3zYWHrAc9mYwfLoQydH6+RpdVuARiXfpbGgBkJir/Cm4IH gYAi4GuzVDD/LSzQSq9MJmhKhdM8WSP+PaZr99IQw/ylAio4ZB2ga2vFskOf/90BcrXq+MKX gKSJRZPDqarBzKbkj5gE6kKtInYHsLuXgjYuBJkf81wzzGMEusFgjKlKDtVnHhPZ0UDvjPzX IxeccV08QdqRtvj/2qg6rhgP/mKaRkAoFlBFF65fPkfIfqojp8pCmjErl0P/yaEWB8nea4Mh yyXOEPb3X5xhYEQO1wx+Rq5aV3hnr02IQxxCo46K2wPREPzG0rhCADmNBFWc4/gXmiOv9K74 9M0wCSiIdnMRKxmdJgDwb7PWiwALkj9Or7N6Wi45V/2MtXdnN56U9pHgBm1+j0XkYEW8n5sr 13BofhdmiMbDn5Z1IMKLuzhly32UVo7WYxAATKIicPVc+NGYwVyriuUN0OF3CVQQHFiicATq VNZ2eJgsxb60vRxjxFifoLGvesUBObXrDQRaixN3T0VTDeza1HRyC4uBy+87DIsEtcm/I9Q2 Yqcs8RYBoUqSO7uzbaUnAI+mu5S64fnd5uP7sAcmOREQo+tpmX+46yZE9SrlxXdEGPLEoOst VB5zUFeLMOsNrnJBwQjTOw4hAgMBAAGjggFGMIIBQjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVy IHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYI KwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEw MgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEG A1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMCEGA1Ud EQQaMBiBFnRyaXBsZWhAaGFja2luZ3RoZS5uZXQwDQYJKoZIhvcNAQENBQADggIBAKT116oK WmHaCR+tq18liXD+24IDsDFrBjSO9gP5MTTxcVPuIcWCFSCuDFEgUMf+25gokk+kQsjezUZW eipoxkyWvaJLyqiMZ1ClTLkCvoN4ESNu+vbenfU6s0/LKbDtHOQTqLr2atWr7XIBbBdgh9Oc gbwmEAsqslNyJaN9XfeMNCIw6+sBr5zPS49nBKANXUQTeQmvVeOUot75nzcP1SctXXuUXX1F OHNwerwvIEom/m92FFfZPpxco+9ZN+vuyfTS7evhaoNO2mZ1+NZf5z+Kb+HkaBHwUJcEplXb x1NzusVtTTMwdT1F7lscyQqgq5pb41O74i+zkmHHLSkMaNLZ5J6moXZF+9lotz08rdK3G1sP WmZzR400rgeyS+TVmxm5s6TdDq6R30319OtlztpK2My/CWyurraIufjSry1LycKVZI/7ShLq DGHaxGETyqdwdZ6/4bFVOEQ2CWbd6CfiBWFhDx3FN/yRNnumFE/iznaUHcSu6+uXWxauAsXX aA8CKN4EPb67OaPThxOsSn+YYHran6IUZvRfy6jjodRci4Lm4bCAgPuiCpZdWK7CLn6YeLpd MfHca7+nX8GVG6Xoyu7wDcLjGr3bw0yGSmGpXkkbax11fjZyC5P7b4WSUjcBOuU8OYxSNKpl eHm7OagpNNDXfrShu9ht7MbuLWZ/MYIG0TCCBs0CAQEwgYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNp Z25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAxPU 2DANBglghkgBZQMEAgMFAKCCAiEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMjAwNDEzMDgxMTE2WjBPBgkqhkiG9w0BCQQxQgRA8ZcncJUXkFJ1HLN979ew qycXvo/i+Y2rD1f9fyYSjb7B5pjzipzly9ZoISMCu8nI94riLmFR1F/+tgUv+anjxzBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGR BgkrBgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDov L3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEw HwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAxPU2DCBkwYLKoZIhvcNAQkQAgsx gYOggYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQu b3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkB FhJzdXBwb3J0QGNhY2VydC5vcmcCAxPU2DANBgkqhkiG9w0BAQEFAASCBADOpgmk4yq0Cg55 uE/tr/pXog4qU6lRsGgpZG6aS9f0J7G+9EycN91vr5mfyOhxrIF2ZDTCyeSyQlbA3gdwvQJV QHmEKcC0PEu7o897H6BnQmF4Teh1bzMHX5+icV/SzPfMOcOf5mGEJhWSWsG6GdV1/hSv336Y h82P19A1LrIYUu1lmEcIIOLAyVCbTziCt5kBCeL/XehHTLdq0jWWRVNja2Zn+s6m3O9m74zR kA0ta0oq7ZtEofgDWfnWkVxhqRGW++LqWKURlUnos+JjdZepEDvbm0ahPW8BgM8M2l6v9u9n Y+3uP4szPnKtFY42T0X4NjglJQdWhmoEPV6EGDPP6NsjxZHB+bT88hYkr2Nu9vkrgzzMdnYS hwHZ7OMB5XIAbONJLjfOkjxGTXmty5NMtGB7SmYxCRkRrCNeS2gMx13o7P8J5hq327aqjHpv UW0Zd9/wQJ06HfO3qvAbDWq6129UvegJJQVFu1bUnIc2PS9YlkgdLyaaeSZBtUvyIZIzeT63 k7kPAk8HRdJHnMfzErXTbEYRpEgADGWEp2D30rM7Axr6CbeCGtEthUEvl7PYpuYu+h/ysAyQ dksp+k7XGOqNVBKl+Q5qzpribxgUp6WwI7UOFcs7KUYMzbf5uL5UDqdSZQmPlYdpSWHh8xPU qbE9jXx19QotQvGHDBlrDUC42Mebc3gVQYQAAhoKwF77R2B6ld/lC65mYBDc6xfc0BGcXHC/ ghR3Rf/23GcSWkaZUFim9GlKxhDlUy+p8s2vckGQsZFGtcdFSazgxYXtiRLD28KH0XbKWkR7 a/JKPfEkTBU0ghU2jFcHqbf/eEzJq7PMAk9yufAHOEzr4C5F0YTWqC1CM64Qg20I1cFTHCYh r8oSbtJ8SBApy8iW/cOeqdT0LFbzUKRiXqBtbEgXX6zNqyQJbgodUhZsarVyt6cTTLR9kksN xEjGTvss7i8MoPJlhmNTljgqiOjVZESZCXy7aByve7MCB4UG7QzHat+WM18bEiRf/a1H3Hbl J8CTVnZRbAUesgvphUV5DVq+0fgkp7CsGeWz08fUno3okjWYsvGDubVWlQ3eVvoXY7Hrtg5N VXP+usm9pDwliseC+miOtS0ll5Ubar/ktscdVkSQIifI3VmEewDIbSR/udHdC+ofXhnC2s2R hTGX2Q0PZymNQKLGDok7NTlwtqT+YD5tplLg4ERLVJe7SUEj02OoSx+pLipUpbIScvT7gnhr cKwwM4MPuGAa8isrL2YjR3LRYlaHL1hZk/MCXzuseEphQ7xi2UuArYAVyUiBJOX7eR8xXOQh oDZ+VZFWshBTp1CBlJI50eW9kgw77CuOZbpX0p0/Ns6RPBnzWahEcc6+AAAAAAAA --------------ms010204000102080903030405-- ------------------------------ Date: Thu, 16 Apr 2020 08:21:39 -0700 From: Jonathan Zhang <jon.zhixiong.zhang(a)gmail.com> Subject: [coreboot] OCP blog for coreboot on server To: coreboot <coreboot(a)coreboot.org> Message-ID: <CAHGDa7DkrpzHgPY9ymXptj-Kh2Sj10W_Z2LGfPt0TSt2OROTvQ(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Thanks for the coreboot community for providing a strong technology foundation and continuous support, coreboot support for servers powered by Intel Xeon-SP processors is becoming a reality: https://www.opencompute.org/blog/linux-firmware-boots-up-server-powered-by-… . We look forward to further collaboration with you! "For my ally is the Force, and a powerful ally it is." Thank you, Jonathan ------------------------------ Date: Fri, 17 Apr 2020 13:11:50 +0300 From: Mike Banon <mikebdp2(a)gmail.com> Subject: [coreboot] [gerrit] Impossible to delete some of the ancient changes To: coreboot <coreboot(a)coreboot.org> Message-ID: <CAK7947nhmXfZQRkQbexKQfhd8-0wpTd==C1bKNoWZxGh00m=LA(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" i.e. would like to remove the worthless & abandoned 17439 , 17505 , 17506 , 17507 changes I have done at 2016 year (this work has been eventually merged, so nothing of a value will be lost) - but a Delete button for them is not available. Best regards, Mike Banon ------------------------------ Date: Sun, 19 Apr 2020 01:11:08 +0300 From: Ivan Ivanov <qmastery16(a)gmail.com> Subject: [coreboot] Re: Some problems with graphic display when using coreboot + seabios. To: Dalao <dalao(a)tutanota.com>, Rafael Send <flyingfishfinger(a)gmail.com>, Matt DeVillier <matt.devillier(a)gmail.com>, coreboot <coreboot(a)coreboot.org> Message-ID: <CAAaskFDOWEbLZ6m+JMFM3_qQE-48JFeD8P_hA3-qKfQ6sMoZQg(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" > > Personally, given that it's 2020, I'd not bother with legacy-installed > OSes (or SeaBIOS) outside of use with emulation or if a special use > case demands it. Esp given that it's easy enough to migrate Windows > from legacy to UEFI. > UEFI is such an abomination that using SeaBIOS may be the sanest option even in 2030. ------------------------------ Date: Sun, 19 Apr 2020 19:07:40 -0500 From: Samuel Holland <samuel(a)sholland.org> Subject: [coreboot] Re: [PATCH v4 1/2] firmware: google: Expose CBMEM over sysfs To: patrick.rudolph(a)9elements.com, linux-kernel(a)vger.kernel.org Cc: coreboot(a)coreboot.org, Thomas Gleixner <tglx(a)linutronix.de>, Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>, Alexios Zavras <alexios.zavras(a)intel.com>, Allison Randal <allison(a)lohutok.net>, Julius Werner <jwerner(a)chromium.org>, Stephen Boyd <swboyd(a)chromium.org> Message-ID: <a624d2a1-a839-f9f2-c54f-410fd86664a0(a)sholland.org> Content-Type: text/plain; charset=utf-8 On 4/7/20 3:29 AM, patrick.rudolph(a)9elements.com wrote: > From: Patrick Rudolph <patrick.rudolph(a)9elements.com> > > Make all CBMEM buffers available to userland. This is useful for tools > that are currently using /dev/mem. > > Make the id, size and address available, as well as the raw table data. > > Tools can easily scan the right CBMEM buffer by reading > /sys/bus/coreboot/drivers/cbmem/coreboot*/cbmem_attributes/id > or > /sys/bus/coreboot/devices/coreboot*/cbmem_attributes/id > > The binary table data can then be read from > /sys/bus/coreboot/drivers/cbmem/coreboot*/cbmem_attributes/data > or > /sys/bus/coreboot/devices/coreboot*/cbmem_attributes/data > > Signed-off-by: Patrick Rudolph <patrick.rudolph(a)9elements.com> > --- > -v2: > - Add ABI documentation > - Add 0x prefix on hex values > -v3: > - Use BIN_ATTR_RO > -v4: > - Use temporary memremap instead of persistent ioremap > - Constify a struct > - Get rid of unused headers > - Use dev_{get|set}_drvdata > - Use dev_groups to automatically handle attributes > - Updated file description > - Updated ABI documentation > --- > Documentation/ABI/stable/sysfs-bus-coreboot | 44 +++++++ > drivers/firmware/google/Kconfig | 9 ++ > drivers/firmware/google/Makefile | 1 + > drivers/firmware/google/cbmem-coreboot.c | 128 ++++++++++++++++++++ > drivers/firmware/google/coreboot_table.h | 14 +++ > 5 files changed, 196 insertions(+) > create mode 100644 Documentation/ABI/stable/sysfs-bus-coreboot > create mode 100644 drivers/firmware/google/cbmem-coreboot.c > > diff --git a/Documentation/ABI/stable/sysfs-bus-coreboot > b/Documentation/ABI/stable/sysfs-bus-coreboot > new file mode 100644 > index 000000000000..6055906f41f2 > --- /dev/null > +++ b/Documentation/ABI/stable/sysfs-bus-coreboot > @@ -0,0 +1,44 @@ > +What: /sys/bus/coreboot/devices/.../cbmem_attributes/id > +Date: Apr 2020 > +KernelVersion: 5.6 I guess these will be 5.8 now. > +Contact: Patrick Rudolph <patrick.rudolph(a)9elements.com> > +Description: > + coreboot device directory can contain a file named > + cbmem_attributes/id if the device corresponds to a CBMEM > + buffer. > + The file holds an ASCII representation of the CBMEM ID in hex > + (e.g. 0xdeadbeef). > + > +What: /sys/bus/coreboot/devices/.../cbmem_attributes/size > +Date: Apr 2020 > +KernelVersion: 5.6 > +Contact: Patrick Rudolph <patrick.rudolph(a)9elements.com> > +Description: > + coreboot device directory can contain a file named > + cbmem_attributes/size if the device corresponds to a CBMEM > + buffer. > + The file holds an representation as decimal number of the nit: "a representation" (maybe "a decimal representation"?) > + CBMEM buffer size (e.g. 64). > + > +What: /sys/bus/coreboot/devices/.../cbmem_attributes/address > +Date: Apr 2020 > +KernelVersion: 5.6 > +Contact: Patrick Rudolph <patrick.rudolph(a)9elements.com> > +Description: > + coreboot device directory can contain a file named > + cbmem_attributes/address if the device corresponds to a CBMEM > + buffer. > + The file holds an ASCII representation of the physical address > + of the CBMEM buffer in hex (e.g. 0x000000008000d000) and should > + be used for debugging only. > + > +What: /sys/bus/coreboot/devices/.../cbmem_attributes/data > +Date: Apr 2020 > +KernelVersion: 5.6 > +Contact: Patrick Rudolph <patrick.rudolph(a)9elements.com> > +Description: > + coreboot device directory can contain a file named > + cbmem_attributes/data if the device corresponds to a CBMEM > + buffer. > + The file holds a read-only binary representation of the CBMEM > + buffer. > diff --git a/drivers/firmware/google/Kconfig > b/drivers/firmware/google/Kconfig index a3a6ca659ffa..11a67c397ab3 > 100644 > --- a/drivers/firmware/google/Kconfig > +++ b/drivers/firmware/google/Kconfig > @@ -58,6 +58,15 @@ config GOOGLE_FRAMEBUFFER_COREBOOT > This option enables the kernel to search for a framebuffer in > the coreboot table. If found, it is registered with simplefb. > > +config GOOGLE_CBMEM_COREBOOT > + tristate "Coreboot CBMEM access" > + depends on GOOGLE_COREBOOT_TABLE > + help > + This option exposes all available CBMEM buffers to userland. > + The CBMEM id, size and address as well as the raw table data > + are exported as sysfs attributes of the corresponding coreboot > + table. > + > config GOOGLE_MEMCONSOLE_COREBOOT > tristate "Firmware Memory Console" > depends on GOOGLE_COREBOOT_TABLE > diff --git a/drivers/firmware/google/Makefile > b/drivers/firmware/google/Makefile > index d17caded5d88..62053cd6d058 100644 > --- a/drivers/firmware/google/Makefile > +++ b/drivers/firmware/google/Makefile > @@ -2,6 +2,7 @@ > > obj-$(CONFIG_GOOGLE_SMI) += gsmi.o > obj-$(CONFIG_GOOGLE_COREBOOT_TABLE) += coreboot_table.o > +obj-$(CONFIG_GOOGLE_CBMEM_COREBOOT) += cbmem-coreboot.o > obj-$(CONFIG_GOOGLE_FRAMEBUFFER_COREBOOT) += framebuffer-coreboot.o > obj-$(CONFIG_GOOGLE_MEMCONSOLE) += memconsole.o > obj-$(CONFIG_GOOGLE_MEMCONSOLE_COREBOOT) += memconsole-coreboot.o > diff --git a/drivers/firmware/google/cbmem-coreboot.c > b/drivers/firmware/google/cbmem-coreboot.c > new file mode 100644 > index 000000000000..f76704a6eec7 > --- /dev/null > +++ b/drivers/firmware/google/cbmem-coreboot.c > @@ -0,0 +1,128 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * cbmem-coreboot.c > + * > + * Exports CBMEM as attributes in sysfs. > + * > + * Copyright 2012-2013 David Herrmann <dh.herrmann(a)gmail.com> > + * Copyright 2017 Google Inc. > + * Copyright 2019 9elements Agency GmbH */ > + > +#include <linux/device.h> > +#include <linux/kernel.h> > +#include <linux/string.h> > +#include <linux/module.h> > +#include <linux/io.h> > + > +#include "coreboot_table.h" > + > +#define CB_TAG_CBMEM_ENTRY 0x31 > + > +struct cb_priv { > + struct lb_cbmem_entry entry; > +}; > + > +static ssize_t id_show(struct device *dev, > + struct device_attribute *attr, char *buffer) { > + const struct cb_priv *priv = dev_get_drvdata(dev); > + > + return sprintf(buffer, "%#08x\n", priv->entry.id); } > + > +static ssize_t size_show(struct device *dev, > + struct device_attribute *attr, char *buffer) { > + const struct cb_priv *priv = dev_get_drvdata(dev); > + > + return sprintf(buffer, "%u\n", priv->entry.entry_size); } > + > +static ssize_t address_show(struct device *dev, > + struct device_attribute *attr, char *buffer) { > + const struct cb_priv *priv = dev_get_drvdata(dev); > + > + return sprintf(buffer, "%#016llx\n", priv->entry.address); } > + > +static DEVICE_ATTR_RO(id); > +static DEVICE_ATTR_RO(size); > +static DEVICE_ATTR_RO(address); > + > +static struct attribute *cb_mem_attrs[] = { > + &dev_attr_address.attr, > + &dev_attr_id.attr, > + &dev_attr_size.attr, > + NULL > +}; > + > +static ssize_t data_read(struct file *filp, struct kobject *kobj, > + struct bin_attribute *bin_attr, > + char *buffer, loff_t offset, size_t count) { > + const struct device *dev = kobj_to_dev(kobj); > + const struct cb_priv *priv = dev_get_drvdata(dev); > + void *ptr; > + > + /* CBMEM is always RAM with unknown caching attributes. */ > + ptr = memremap(priv->entry.address, priv->entry.entry_size, > + MEMREMAP_WB | MEMREMAP_WT); > + if (!ptr) > + return -ENOMEM; > + > + count = memory_read_from_buffer(buffer, count, &offset, ptr, > + priv->entry.entry_size); > + memunmap(ptr); > + > + return count; > +} > + > +static BIN_ATTR_RO(data, 0); > + > +static struct bin_attribute *cb_mem_bin_attrs[] = { > + &bin_attr_data, > + NULL > +}; > + > +static const struct attribute_group cb_mem_attr_group = { > + .name = "cbmem_attributes", > + .attrs = cb_mem_attrs, > + .bin_attrs = cb_mem_bin_attrs, > +}; > + > +static const struct attribute_group *attribute_groups[] = { > + &cb_mem_attr_group, > + NULL, > +}; > + > +static int cbmem_probe(struct coreboot_device *cdev) { > + struct device *dev = &cdev->dev; > + struct cb_priv *priv; > + > + priv = devm_kmalloc(dev, sizeof(*priv), GFP_KERNEL); > + if (!priv) > + return -ENOMEM; > + > + memcpy(&priv->entry, &cdev->cbmem_entry, sizeof(priv->entry)); I don't think it is necessary to create a second copy of the table entry, when it is already available at cdev->cbmem_entry. You could do: dev_set_drvdata(dev, cdev); and that removes the need for struct cb_priv. Otherwise, Reviewed-by: Samuel Holland <samuel(a)sholland.org> Tested-by: Samuel Holland <samuel(a)sholland.org> I hacked nvramtool to pull the CMOS layout from /sys/bus/coreboot/devices/coreboot0/attributes/data, and that seemed to work. Cheers, Samuel > + > + dev_set_drvdata(dev, priv); > + > + return 0; > +} > + > +static struct coreboot_driver cbmem_driver = { > + .probe = cbmem_probe, > + .drv = { > + .name = "cbmem", > + .dev_groups = attribute_groups, > + }, > + .tag = CB_TAG_CBMEM_ENTRY, > +}; > + > +module_coreboot_driver(cbmem_driver); > + > +MODULE_AUTHOR("9elements Agency GmbH"); MODULE_LICENSE("GPL"); > diff --git a/drivers/firmware/google/coreboot_table.h > b/drivers/firmware/google/coreboot_table.h > index 7b7b4a6eedda..fc20b8649882 100644 > --- a/drivers/firmware/google/coreboot_table.h > +++ b/drivers/firmware/google/coreboot_table.h > @@ -59,6 +59,19 @@ struct lb_framebuffer { > u8 reserved_mask_size; > }; > > +/* > + * There can be more than one of these records as there is one per cbmem entry. > + * Describes a buffer in memory containing runtime data. > + */ > +struct lb_cbmem_entry { > + u32 tag; > + u32 size; > + > + u64 address; > + u32 entry_size; > + u32 id; > +}; > + > /* A device, additionally with information from coreboot. */ struct > coreboot_device { > struct device dev; > @@ -66,6 +79,7 @@ struct coreboot_device { > struct coreboot_table_entry entry; > struct lb_cbmem_ref cbmem_ref; > struct lb_framebuffer framebuffer; > + struct lb_cbmem_entry cbmem_entry; > }; > }; > > ------------------------------ Subject: Digest Footer _______________________________________________ coreboot mailing list -- coreboot(a)coreboot.org To unsubscribe send an email to coreboot-leave(a)coreboot.org ------------------------------ End of coreboot Digest, Vol 182, Issue 10 *****************************************

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot April 2020