Help unsubscribe
-----Original Message----- From: coreboot-request@coreboot.org coreboot-request@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-request@coreboot.org
You can reach the person managing the list at coreboot-owner@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@hackingthe.net Subject: [coreboot] T530 with discrete GPU To: coreboot coreboot@coreboot.org Message-ID: bd6a5c59-2550-f7b4-16a6-e21211d48603@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@gmail.com Subject: [coreboot] OCP blog for coreboot on server To: coreboot coreboot@coreboot.org Message-ID: CAHGDa7DkrpzHgPY9ymXptj-Kh2Sj10W_Z2LGfPt0TSt2OROTvQ@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-i... .
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@gmail.com Subject: [coreboot] [gerrit] Impossible to delete some of the ancient changes To: coreboot coreboot@coreboot.org Message-ID: CAK7947nhmXfZQRkQbexKQfhd8-0wpTd==C1bKNoWZxGh00m=LA@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@gmail.com Subject: [coreboot] Re: Some problems with graphic display when using coreboot + seabios. To: Dalao dalao@tutanota.com, Rafael Send flyingfishfinger@gmail.com, Matt DeVillier matt.devillier@gmail.com, coreboot coreboot@coreboot.org Message-ID: CAAaskFDOWEbLZ6m+JMFM3_qQE-48JFeD8P_hA3-qKfQ6sMoZQg@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@sholland.org Subject: [coreboot] Re: [PATCH v4 1/2] firmware: google: Expose CBMEM over sysfs To: patrick.rudolph@9elements.com, linux-kernel@vger.kernel.org Cc: coreboot@coreboot.org, Thomas Gleixner tglx@linutronix.de, Greg Kroah-Hartman gregkh@linuxfoundation.org, Alexios Zavras alexios.zavras@intel.com, Allison Randal allison@lohutok.net, Julius Werner jwerner@chromium.org, Stephen Boyd swboyd@chromium.org Message-ID: a624d2a1-a839-f9f2-c54f-410fd86664a0@sholland.org Content-Type: text/plain; charset=utf-8
On 4/7/20 3:29 AM, patrick.rudolph@9elements.com wrote:
From: Patrick Rudolph patrick.rudolph@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@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@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@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@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@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@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@sholland.org Tested-by: Samuel Holland samuel@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-leave@coreboot.org
------------------------------
End of coreboot Digest, Vol 182, Issue 10 *****************************************