Help unsubscribe -----Original Message----- From: coreboot-requ...@coreboot.org <coreboot-requ...@coreboot.org> Sent: 20 April 2020 01:08 To: coreboot@coreboot.org Subject: coreboot Digest, Vol 182, Issue 10
Send coreboot mailing list submissions to coreboot@coreboot.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to coreboot-requ...@coreboot.org You can reach the person managing the list at coreboot-ow...@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 <trip...@hackingthe.net> Subject: [coreboot] T530 with discrete GPU To: coreboot <coreboot@coreboot.org> Message-ID: <bd6a5c59-2550-f7b4-16a6-e21211d48...@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.zh...@gmail.com> Subject: [coreboot] OCP blog for coreboot on server To: coreboot <coreboot@coreboot.org> Message-ID: <cahgda7dkrpzhgpy9ymxptj-kh2sj10w_z2lgfpt0tst2oro...@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-intelr-xeonr-scalable-processor . 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 <mikeb...@gmail.com> Subject: [coreboot] [gerrit] Impossible to delete some of the ancient changes To: coreboot <coreboot@coreboot.org> Message-ID: <CAK7947nhmXfZQRkQbexKQfhd8-0wpTd==C1bKNoWZxGh00m=l...@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 <qmaster...@gmail.com> Subject: [coreboot] Re: Some problems with graphic display when using coreboot + seabios. To: Dalao <da...@tutanota.com>, Rafael Send <flyingfishfin...@gmail.com>, Matt DeVillier <matt.devill...@gmail.com>, coreboot <coreboot@coreboot.org> Message-ID: <caaaskfdoweblz6m+jmfm3_qqe-48jfed8p_ha3-qkfq6smo...@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 <sam...@sholland.org> Subject: [coreboot] Re: [PATCH v4 1/2] firmware: google: Expose CBMEM over sysfs To: patrick.rudo...@9elements.com, linux-ker...@vger.kernel.org Cc: coreboot@coreboot.org, Thomas Gleixner <t...@linutronix.de>, Greg Kroah-Hartman <gre...@linuxfoundation.org>, Alexios Zavras <alexios.zav...@intel.com>, Allison Randal <alli...@lohutok.net>, Julius Werner <jwer...@chromium.org>, Stephen Boyd <swb...@chromium.org> Message-ID: <a624d2a1-a839-f9f2-c54f-410fd8666...@sholland.org> Content-Type: text/plain; charset=utf-8 On 4/7/20 3:29 AM, patrick.rudo...@9elements.com wrote: > From: Patrick Rudolph <patrick.rudo...@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.rudo...@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.rudo...@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.rudo...@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.rudo...@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.rudo...@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.herrm...@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 <sam...@sholland.org> Tested-by: Samuel Holland <sam...@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@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org ------------------------------ End of coreboot Digest, Vol 182, Issue 10 ***************************************** _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org