info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
ACPI Hardwaretabelle und/oder Device Tree aus dem laufenden System anzeigen
47 views
Skip to first unread message
Marc Haber
Jun 29, 2021, 3:40:44 PM6/29/21
to
Hallo,
ich spiele im Moment mit dem Raspberry Pi 4 herum und versuche auch zu
verstehen, wie die Kiste bootet und wie die Gerätetreiber des
Linux-Kernels ihre Hardware finden und funktionieren.
Auf der ARM-Plattform wird die Hardware ja üblicherweise mit einem
Device Tree beschrieben. Vom Banana Pi kenne ich das so, dass der
Device Tree vom Bootmanager an eine bestimmte Stelle im Adressraum
geladen wird und dieser Offset denn dam Kernel mitgegeben wird. Es
gibt aber wohl auch eine Möglichkeit, dass der Kernel den Device Tree
selbst mitbringt (dann aber natürlich hart hardwarespezifisch ist).
Auf dem Raspberry Pi 4 werden kernel und initramfs in den
Debian-Images direkt vom bootcode.bin geladen und gestartet, ohne dass
noch ein linux-spezifischer Bootloader im Spiel ist. Auch auf dem
Raspberry Pi gibt es dtb-Files, ich finde aber keine Stelle, wo das
auf die Hardware passende File dem Kernel bekanntgegeben wird.
Und schließlich kann man den Raspberry Pi 4 auch noch mit einer
UEFI-Firmware starten (die dann grub startet), dann ist kein Device
Tree im Spiel, sondern ACPI, und das müssen die Gerätetreiber
unterstützen.
Und dann kann man diese UEFI-Firmware auch noch so einstellen, dass
kein ACPI, sondern Device Tree benutzt wird; allerdings ist das
System, das man dann so über grub startet, nicht besonders lauffähig
(es fehlt der eine oder der andere Teil des USB), und zwar auch dann,
wenn man grub mit einem devicetree-Kommando explizit anweist,
bcm2711-rpi-4-b.dtb zu laden. Muss man da noch mehr angeben?
Gibt es irgendwelche Userspace-Tools, mit denen man sich den Device
Tree, den der laufende Kernel wirklich benutzt, in möglichst
menschenlesbarer Version anzeigen lassen kann?
Gibt es weiterhin irgendwelche Userspace-Tools, mit denen man sich die
ACPI-Tabellen, die der laufende kernel wirklich benutzt, in möglichst
menschlesbarer Version anzeigen lassen kann?
Wenn sich jemand mit diesen Mechanismen auskennt, bin ich auch gerne
bereit, Pointer auf Literatur etc entgegenzunehmen und mir anzugucken
wie die Dokumentation aussieht. Ich bin allerdings weder großartiger
Programmierer noch ein Kernel-Hacker, es ist somit davon auszugehen,
dass mich Dokumentation für Kernel-Developer überfordert.
Vielen Dank!
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
ich spiele im Moment mit dem Raspberry Pi 4 herum und versuche auch zu
verstehen, wie die Kiste bootet und wie die Gerätetreiber des
Linux-Kernels ihre Hardware finden und funktionieren.
Auf der ARM-Plattform wird die Hardware ja üblicherweise mit einem
Device Tree beschrieben. Vom Banana Pi kenne ich das so, dass der
Device Tree vom Bootmanager an eine bestimmte Stelle im Adressraum
geladen wird und dieser Offset denn dam Kernel mitgegeben wird. Es
gibt aber wohl auch eine Möglichkeit, dass der Kernel den Device Tree
selbst mitbringt (dann aber natürlich hart hardwarespezifisch ist).
Auf dem Raspberry Pi 4 werden kernel und initramfs in den
Debian-Images direkt vom bootcode.bin geladen und gestartet, ohne dass
noch ein linux-spezifischer Bootloader im Spiel ist. Auch auf dem
Raspberry Pi gibt es dtb-Files, ich finde aber keine Stelle, wo das
auf die Hardware passende File dem Kernel bekanntgegeben wird.
Und schließlich kann man den Raspberry Pi 4 auch noch mit einer
UEFI-Firmware starten (die dann grub startet), dann ist kein Device
Tree im Spiel, sondern ACPI, und das müssen die Gerätetreiber
unterstützen.
Und dann kann man diese UEFI-Firmware auch noch so einstellen, dass
kein ACPI, sondern Device Tree benutzt wird; allerdings ist das
System, das man dann so über grub startet, nicht besonders lauffähig
(es fehlt der eine oder der andere Teil des USB), und zwar auch dann,
wenn man grub mit einem devicetree-Kommando explizit anweist,
bcm2711-rpi-4-b.dtb zu laden. Muss man da noch mehr angeben?
Gibt es irgendwelche Userspace-Tools, mit denen man sich den Device
Tree, den der laufende Kernel wirklich benutzt, in möglichst
menschenlesbarer Version anzeigen lassen kann?
Gibt es weiterhin irgendwelche Userspace-Tools, mit denen man sich die
ACPI-Tabellen, die der laufende kernel wirklich benutzt, in möglichst
menschlesbarer Version anzeigen lassen kann?
Wenn sich jemand mit diesen Mechanismen auskennt, bin ich auch gerne
bereit, Pointer auf Literatur etc entgegenzunehmen und mir anzugucken
wie die Dokumentation aussieht. Ich bin allerdings weder großartiger
Programmierer noch ein Kernel-Hacker, es ist somit davon auszugehen,
dass mich Dokumentation für Kernel-Developer überfordert.
Vielen Dank!
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Tim Ritberg
Jun 29, 2021, 4:12:13 PM6/29/21
to
Am 29.06.21 um 21:40 schrieb Marc Haber:
>
> Gibt es irgendwelche Userspace-Tools, mit denen man sich den Device
> Tree, den der laufende Kernel wirklich benutzt, in möglichst
> menschenlesbarer Version anzeigen lassen kann?
ja:
dtc -I fs /proc/device-tree
https://www.raspberrypi.org/documentation/configuration/device-tree.md
Tim
>
> Gibt es irgendwelche Userspace-Tools, mit denen man sich den Device
> Tree, den der laufende Kernel wirklich benutzt, in möglichst
> menschenlesbarer Version anzeigen lassen kann?
dtc -I fs /proc/device-tree
https://www.raspberrypi.org/documentation/configuration/device-tree.md
Tim
Kay Martinen
Jul 4, 2021, 2:30:01 PM7/4/21
to
Am 29.06.21 um 21:40 schrieb Marc Haber:
> ich spiele im Moment mit dem Raspberry Pi 4 herum und versuche auch zu
> verstehen, wie die Kiste bootet und wie die Gerätetreiber des
> Linux-Kernels ihre Hardware finden und funktionieren.
...
> verstehen, wie die Kiste bootet und wie die Gerätetreiber des
> Linux-Kernels ihre Hardware finden und funktionieren.
> Und schließlich kann man den Raspberry Pi 4 auch noch mit einer
> UEFI-Firmware starten (die dann grub startet), dann ist kein Device
> Tree im Spiel, sondern ACPI, und das müssen die Gerätetreiber
> unterstützen.
...
> UEFI-Firmware starten (die dann grub startet), dann ist kein Device
> Tree im Spiel, sondern ACPI, und das müssen die Gerätetreiber
> unterstützen.
>
> Gibt es weiterhin irgendwelche Userspace-Tools, mit denen man sich die
> ACPI-Tabellen, die der laufende kernel wirklich benutzt, in möglichst
> menschlesbarer Version anzeigen lassen kann?
Hast du mal geschaut ob dein raspi OS (raspbian oder ein debian/arm?)
> Gibt es weiterhin irgendwelche Userspace-Tools, mit denen man sich die
> ACPI-Tabellen, die der laufende kernel wirklich benutzt, in möglichst
> menschlesbarer Version anzeigen lassen kann?
die vom PC üblichen tools kennt wie dmidecode oder die acpi-tools?
Auf meinem ubuntu Laptop kommt beim stichwort 'acpi' mit autocomplete
schon so viel:
> root@lifebook:~# acpi
> acpi acpid acpiexec acpinames acpitool
> acpi_available acpidump acpihelp acpisrc acpixtract
> acpibin acpidump-acpica acpi_listen acpitail acpixtract-acpica
Ich denke dann könnte was passendes dabei sein.
Beispiel:
> root@lifebook:~# acpidump -v
>
> Intel ACPI Component Architecture
> ACPI Binary Table Dump Utility version 20180105
> Copyright (c) 2000 - 2018 Intel Corporation
>
> root@lifebook:~# acpidump -s
> ACPI: SSDT 0x0000000000000000 00090C (v01 PmRef Cpu0Ist 00003000 INTL 20061109)
> ACPI: MCFG 0x0000000000000000 00003C (v01 FUJ PC 00000001 PTL 00000001)
> ACPI: ASF! 0x0000000000000000 0000A5 (v32 FUJ PC 00000001 PTL 00000001)
> ACPI: APIC 0x0000000000000000 000098 (v01 FUJ PC 00000001 PTL 00000001)
> ACPI: SLIC 0x0000000000000000 000176 (v01 FUJ PC 01100000 FUJ 00000001)
> ACPI: SSDT 0x0000000000000000 0002C1 (v01 FUJ BayAhci2 00000001 INTL 20061109)
> ACPI: DSDT 0x0000000000000000 008E87 (v02 FUJ FJNB223 01100000 INTL 20061109)
> ACPI: UEFI 0x0000000000000000 000256 (v01 FUJ PC 00000001 PTL 00000001)
> ACPI: SSDT 0x0000000000000000 0009F5 (v01 PmRef CpuPm 00003000 INTL 20061109)
> ACPI: UEFI 0x0000000000000000 00003E (v01 FUJ PC 00000001 PTL 00000001)
> ACPI: SSDT 0x0000000000000000 0000B6 (v02 FUJ DockSsdt 00000001 INTL 20061109)
> ACPI: FACP 0x0000000000000000 0000F4 (v03 FUJ PC 01100000 FUJ 00000001)
> ACPI: SSDT 0x0000000000000000 000346 (v01 FUJ SataAhci 00000001 INTL 20061109)
> ACPI: TCPA 0x0000000000000000 000032 (v02 PTL CRESTLN 06040000 00005A52)
> ACPI: HPET 0x0000000000000000 000038 (v01 FUJ PC 00000001 PTL 00000001)
> ACPI: SSDT 0x0000000000000000 0005B9 (v02 FUJ VistSsdt 00000001 INTL 20061109)
> ACPI: UEFI 0x0000000000000000 000042 (v01 PTL COMBUF 00000001 PTL 00000001)
> ACPI: FACS 0x0000000000000000 000040
> ACPI: SSDT 0x0000000000000000 000119 (v01 PmRef ApCst 00003000 INTL 20061109)
> ACPI: SSDT 0x0000000000000000 0007A9 (v01 PmRef Cpu0Cst 00003001 INTL 20061109)
> ACPI: SSDT 0x0000000000000000 000303 (v01 PmRef ApIst 00003000 INTL 20061109)
Mir sagt das erst mal auch nix aber du willst dich damit ja auch
befassen, ich nicht. :)
Kay
--
Posted via leafnode
0 new messages