Help unsubscribe
-----Original Message-----
From: [email protected] <[email protected]>
Sent: 20 April 2020 01:08
To: [email protected]
Subject: coreboot Digest, Vol 182, Issue 10
Send coreboot mailing list submissions to
[email protected]
To subscribe or unsubscribe via email, send a message with subject or body
'help' to
[email protected]
You can reach the person managing the list at
[email protected]
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 <[email protected]>
Subject: [coreboot] T530 with discrete GPU
To: coreboot <[email protected]>
Message-ID: <[email protected]>
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 <[email protected]>
Subject: [coreboot] OCP blog for coreboot on server
To: coreboot <[email protected]>
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 <[email protected]>
Subject: [coreboot] [gerrit] Impossible to delete some of the ancient
changes
To: coreboot <[email protected]>
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 <[email protected]>
Subject: [coreboot] Re: Some problems with graphic display when using
coreboot + seabios.
To: Dalao <[email protected]>, Rafael Send
<[email protected]>, Matt DeVillier
<[email protected]>, coreboot <[email protected]>
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 <[email protected]>
Subject: [coreboot] Re: [PATCH v4 1/2] firmware: google: Expose CBMEM
over sysfs
To: [email protected], [email protected]
Cc: [email protected], Thomas Gleixner <[email protected]>, Greg
Kroah-Hartman <[email protected]>, Alexios Zavras
<[email protected]>, Allison Randal <[email protected]>,
Julius Werner <[email protected]>, Stephen Boyd
<[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On 4/7/20 3:29 AM, [email protected] wrote:
> From: Patrick Rudolph <[email protected]>
>
> 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 <[email protected]>
> ---
> -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 <[email protected]>
> +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 <[email protected]>
> +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 <[email protected]>
> +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 <[email protected]>
> +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 <[email protected]>
> + * 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 <[email protected]>
Tested-by: Samuel Holland <[email protected]>
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 -- [email protected] To unsubscribe send an email to
[email protected]
------------------------------
End of coreboot Digest, Vol 182, Issue 10
*****************************************
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
