Is it possible to get the information for a device tree using /sys of a running kernel?
Clash Royale CLAN TAG#URR8PPP
up vote
15
down vote
favorite
Commonly for arm systems, device trees supply hardware information to the kernel (Linux). These device trees exist as dts (device tree source) files that are compiled and loaded to the kernel. Problem is that I do not have access to such a dts file, not even to a dtb file.
I have access to /sys and /proc on the machine and I wanted to ask if that would allow me to "guess the correct values" to be used in a dts?
Also potential answer could highlight additionally the aspect if the answer to this question also depends on whether the device tree interface was used in the first place (i.e. a dtb was created and provided to the kernel) instead of some more hacking "we simply divert from vanilla and patch the kernel so as to solve the device information problem for our kernel only"-solution?
linux linux-kernel arm device-tree reverse-engineering
asked Feb 26 '16 at 0:28
humanityANDpeace
4,80653452
add a comment |
up vote
15
down vote
favorite
Commonly for arm systems, device trees supply hardware information to the kernel (Linux). These device trees exist as dts (device tree source) files that are compiled and loaded to the kernel. Problem is that I do not have access to such a dts file, not even to a dtb file.
I have access to /sys and /proc on the machine and I wanted to ask if that would allow me to "guess the correct values" to be used in a dts?
Also potential answer could highlight additionally the aspect if the answer to this question also depends on whether the device tree interface was used in the first place (i.e. a dtb was created and provided to the kernel) instead of some more hacking "we simply divert from vanilla and patch the kernel so as to solve the device information problem for our kernel only"-solution?
linux linux-kernel arm device-tree reverse-engineering
asked Feb 26 '16 at 0:28
humanityANDpeace
4,80653452
Do you have access to the boot image? You could extract the device tree from there. I can help.
– phk
Oct 17 '16 at 18:03
add a comment |
up vote
15
down vote
favorite
up vote
15
down vote
favorite
Commonly for arm systems, device trees supply hardware information to the kernel (Linux). These device trees exist as dts (device tree source) files that are compiled and loaded to the kernel. Problem is that I do not have access to such a dts file, not even to a dtb file.
I have access to /sys and /proc on the machine and I wanted to ask if that would allow me to "guess the correct values" to be used in a dts?
Also potential answer could highlight additionally the aspect if the answer to this question also depends on whether the device tree interface was used in the first place (i.e. a dtb was created and provided to the kernel) instead of some more hacking "we simply divert from vanilla and patch the kernel so as to solve the device information problem for our kernel only"-solution?
linux linux-kernel arm device-tree reverse-engineering
asked Feb 26 '16 at 0:28
humanityANDpeace
4,80653452
Commonly for arm systems, device trees supply hardware information to the kernel (Linux). These device trees exist as dts (device tree source) files that are compiled and loaded to the kernel. Problem is that I do not have access to such a dts file, not even to a dtb file.
I have access to /sys and /proc on the machine and I wanted to ask if that would allow me to "guess the correct values" to be used in a dts?
Also potential answer could highlight additionally the aspect if the answer to this question also depends on whether the device tree interface was used in the first place (i.e. a dtb was created and provided to the kernel) instead of some more hacking "we simply divert from vanilla and patch the kernel so as to solve the device information problem for our kernel only"-solution?
linux linux-kernel arm device-tree reverse-engineering
linux linux-kernel arm device-tree reverse-engineering
asked Feb 26 '16 at 0:28
humanityANDpeace
4,80653452
asked Feb 26 '16 at 0:28
humanityANDpeace
4,80653452
edited Feb 27 '16 at 7:06
asked Feb 26 '16 at 0:28
humanityANDpeace
4,80653452
asked Feb 26 '16 at 0:28
humanityANDpeace
4,80653452
asked Feb 26 '16 at 0:28
humanityANDpeace
4,80653452
4,80653452
Do you have access to the boot image? You could extract the device tree from there. I can help.
– phk
Oct 17 '16 at 18:03
add a comment |
Do you have access to the boot image? You could extract the device tree from there. I can help.
– phk
Oct 17 '16 at 18:03
Do you have access to the boot image? You could extract the device tree from there. I can help.
– phk
Oct 17 '16 at 18:03
Do you have access to the boot image? You could extract the device tree from there. I can help.
– phk
Oct 17 '16 at 18:03
add a comment |
2 Answers
2
active
oldest
votes
up vote
20
down vote
/proc/device-tree or /sys/firmware/devicetree/base
I think both are aliases, /sys/firmware/devicetree/base likely being the better choice after the taming of /proc.
You can then access dts properties from files:
hexdump /sys/firmware/devicetree/base/apb-pclk/clock-frequency
The output format for integers is binary, so hexdump is needed.
dtc -I fs
Get a full device tree from the filesystem:
sudo apt-get install device-tree-compiler
dtc -I fs -O dts /sys/firmware/devicetree/base
outputs the dts to stdout.
Learned from: How to list the kernel Device Tree | Unix & Linux Stack Exchange
Tested with this QEMU + Buildroot setup on the Linux kernel v4.19 arm64.
answered Dec 16 '16 at 18:44
Ciro Santilli 新疆改造中心 六四事件 法轮功
4,64824038
add a comment |
up vote
3
down vote
I'm not sure if I understand you correctly.
If you're on a system that booted using a dtb, your device tree should be accessible inside debugfs.
You can also try the dtc tools by Pantelis Antoniou, they include fdtdump and fdtget that print dts from a blob.
If you don't have a device tree at all and did not boot boot from a dtb, then you'll have to go through the machine code yourself and add all device specific attributes and nodes to your dts. There is no "synthetic" device tree generated for such a boot. A starting point would be a similar machine or parent and then working your way system by system.
answered Feb 27 '16 at 0:20
FRob
1466
Thanks, to clarify. There is a chance that thedtbmight be accessible through through the debugfs yet that would rely onCONFIG_DEBUG_FSin.configand even if set still on the mere whim that they actually used adtbto start with, do I read this right? So with some "bad luck" they did neither and used some sort of direct kernel patching instaed of device tree interface, also right? So this would mean the last resort woult be machine code, given they violate GPLv2 and closesource the kernel, right?
– humanityANDpeace
Feb 27 '16 at 7:01
Yes and yes for the first two. Last, IANAL, but the machine arch/???/mach-???/board-???.c would contain the special devices present for a machine in older kernels. This should be covered by GPL and have to be available for a fee. Individual device drivers might be closed source, no violation there.
– FRob
Feb 27 '16 at 14:02
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
20
down vote
/proc/device-tree or /sys/firmware/devicetree/base
I think both are aliases, /sys/firmware/devicetree/base likely being the better choice after the taming of /proc.
You can then access dts properties from files:
hexdump /sys/firmware/devicetree/base/apb-pclk/clock-frequency
The output format for integers is binary, so hexdump is needed.
dtc -I fs
Get a full device tree from the filesystem:
sudo apt-get install device-tree-compiler
dtc -I fs -O dts /sys/firmware/devicetree/base
outputs the dts to stdout.
Learned from: How to list the kernel Device Tree | Unix & Linux Stack Exchange
Tested with this QEMU + Buildroot setup on the Linux kernel v4.19 arm64.
answered Dec 16 '16 at 18:44
Ciro Santilli 新疆改造中心 六四事件 法轮功
4,64824038
add a comment |
up vote
20
down vote
/proc/device-tree or /sys/firmware/devicetree/base
I think both are aliases, /sys/firmware/devicetree/base likely being the better choice after the taming of /proc.
You can then access dts properties from files:
hexdump /sys/firmware/devicetree/base/apb-pclk/clock-frequency
The output format for integers is binary, so hexdump is needed.
dtc -I fs
Get a full device tree from the filesystem:
sudo apt-get install device-tree-compiler
dtc -I fs -O dts /sys/firmware/devicetree/base
outputs the dts to stdout.
Learned from: How to list the kernel Device Tree | Unix & Linux Stack Exchange
Tested with this QEMU + Buildroot setup on the Linux kernel v4.19 arm64.
answered Dec 16 '16 at 18:44
Ciro Santilli 新疆改造中心 六四事件 法轮功
4,64824038
add a comment |
up vote
20
down vote
up vote
20
down vote
/proc/device-tree or /sys/firmware/devicetree/base
I think both are aliases, /sys/firmware/devicetree/base likely being the better choice after the taming of /proc.
You can then access dts properties from files:
hexdump /sys/firmware/devicetree/base/apb-pclk/clock-frequency
The output format for integers is binary, so hexdump is needed.
dtc -I fs
Get a full device tree from the filesystem:
sudo apt-get install device-tree-compiler
dtc -I fs -O dts /sys/firmware/devicetree/base
outputs the dts to stdout.
Learned from: How to list the kernel Device Tree | Unix & Linux Stack Exchange
Tested with this QEMU + Buildroot setup on the Linux kernel v4.19 arm64.
answered Dec 16 '16 at 18:44
Ciro Santilli 新疆改造中心 六四事件 法轮功
4,64824038
/proc/device-tree or /sys/firmware/devicetree/base
I think both are aliases, /sys/firmware/devicetree/base likely being the better choice after the taming of /proc.
You can then access dts properties from files:
hexdump /sys/firmware/devicetree/base/apb-pclk/clock-frequency
The output format for integers is binary, so hexdump is needed.
dtc -I fs
Get a full device tree from the filesystem:
sudo apt-get install device-tree-compiler
dtc -I fs -O dts /sys/firmware/devicetree/base
outputs the dts to stdout.
Learned from: How to list the kernel Device Tree | Unix & Linux Stack Exchange
Tested with this QEMU + Buildroot setup on the Linux kernel v4.19 arm64.
answered Dec 16 '16 at 18:44
Ciro Santilli 新疆改造中心 六四事件 法轮功
4,64824038
edited yesterday
answered Dec 16 '16 at 18:44
Ciro Santilli 新疆改造中心 六四事件 法轮功
4,64824038
answered Dec 16 '16 at 18:44
Ciro Santilli 新疆改造中心 六四事件 法轮功
4,64824038
answered Dec 16 '16 at 18:44
Ciro Santilli 新疆改造中心 六四事件 法轮功
4,64824038
4,64824038
add a comment |
add a comment |
up vote
3
down vote
I'm not sure if I understand you correctly.
If you're on a system that booted using a dtb, your device tree should be accessible inside debugfs.
You can also try the dtc tools by Pantelis Antoniou, they include fdtdump and fdtget that print dts from a blob.
If you don't have a device tree at all and did not boot boot from a dtb, then you'll have to go through the machine code yourself and add all device specific attributes and nodes to your dts. There is no "synthetic" device tree generated for such a boot. A starting point would be a similar machine or parent and then working your way system by system.
answered Feb 27 '16 at 0:20
FRob
1466
Thanks, to clarify. There is a chance that thedtbmight be accessible through through the debugfs yet that would rely onCONFIG_DEBUG_FSin.configand even if set still on the mere whim that they actually used adtbto start with, do I read this right? So with some "bad luck" they did neither and used some sort of direct kernel patching instaed of device tree interface, also right? So this would mean the last resort woult be machine code, given they violate GPLv2 and closesource the kernel, right?
– humanityANDpeace
Feb 27 '16 at 7:01
Yes and yes for the first two. Last, IANAL, but the machine arch/???/mach-???/board-???.c would contain the special devices present for a machine in older kernels. This should be covered by GPL and have to be available for a fee. Individual device drivers might be closed source, no violation there.
– FRob
Feb 27 '16 at 14:02
add a comment |
up vote
3
down vote
I'm not sure if I understand you correctly.
If you're on a system that booted using a dtb, your device tree should be accessible inside debugfs.
You can also try the dtc tools by Pantelis Antoniou, they include fdtdump and fdtget that print dts from a blob.
If you don't have a device tree at all and did not boot boot from a dtb, then you'll have to go through the machine code yourself and add all device specific attributes and nodes to your dts. There is no "synthetic" device tree generated for such a boot. A starting point would be a similar machine or parent and then working your way system by system.
answered Feb 27 '16 at 0:20
FRob
1466
Thanks, to clarify. There is a chance that thedtbmight be accessible through through the debugfs yet that would rely onCONFIG_DEBUG_FSin.configand even if set still on the mere whim that they actually used adtbto start with, do I read this right? So with some "bad luck" they did neither and used some sort of direct kernel patching instaed of device tree interface, also right? So this would mean the last resort woult be machine code, given they violate GPLv2 and closesource the kernel, right?
– humanityANDpeace
Feb 27 '16 at 7:01
Yes and yes for the first two. Last, IANAL, but the machine arch/???/mach-???/board-???.c would contain the special devices present for a machine in older kernels. This should be covered by GPL and have to be available for a fee. Individual device drivers might be closed source, no violation there.
– FRob
Feb 27 '16 at 14:02
add a comment |
up vote
3
down vote
up vote
3
down vote
I'm not sure if I understand you correctly.
If you're on a system that booted using a dtb, your device tree should be accessible inside debugfs.
You can also try the dtc tools by Pantelis Antoniou, they include fdtdump and fdtget that print dts from a blob.
If you don't have a device tree at all and did not boot boot from a dtb, then you'll have to go through the machine code yourself and add all device specific attributes and nodes to your dts. There is no "synthetic" device tree generated for such a boot. A starting point would be a similar machine or parent and then working your way system by system.
answered Feb 27 '16 at 0:20
FRob
1466
I'm not sure if I understand you correctly.
If you're on a system that booted using a dtb, your device tree should be accessible inside debugfs.
You can also try the dtc tools by Pantelis Antoniou, they include fdtdump and fdtget that print dts from a blob.
If you don't have a device tree at all and did not boot boot from a dtb, then you'll have to go through the machine code yourself and add all device specific attributes and nodes to your dts. There is no "synthetic" device tree generated for such a boot. A starting point would be a similar machine or parent and then working your way system by system.
answered Feb 27 '16 at 0:20
FRob
1466
answered Feb 27 '16 at 0:20
FRob
1466
answered Feb 27 '16 at 0:20
FRob
1466
answered Feb 27 '16 at 0:20
FRob
1466
1466
Thanks, to clarify. There is a chance that thedtbmight be accessible through through the debugfs yet that would rely onCONFIG_DEBUG_FSin.configand even if set still on the mere whim that they actually used adtbto start with, do I read this right? So with some "bad luck" they did neither and used some sort of direct kernel patching instaed of device tree interface, also right? So this would mean the last resort woult be machine code, given they violate GPLv2 and closesource the kernel, right?
– humanityANDpeace
Feb 27 '16 at 7:01
Yes and yes for the first two. Last, IANAL, but the machine arch/???/mach-???/board-???.c would contain the special devices present for a machine in older kernels. This should be covered by GPL and have to be available for a fee. Individual device drivers might be closed source, no violation there.
– FRob
Feb 27 '16 at 14:02
add a comment |
Thanks, to clarify. There is a chance that thedtbmight be accessible through through the debugfs yet that would rely onCONFIG_DEBUG_FSin.configand even if set still on the mere whim that they actually used adtbto start with, do I read this right? So with some "bad luck" they did neither and used some sort of direct kernel patching instaed of device tree interface, also right? So this would mean the last resort woult be machine code, given they violate GPLv2 and closesource the kernel, right?
– humanityANDpeace
Feb 27 '16 at 7:01
Yes and yes for the first two. Last, IANAL, but the machine arch/???/mach-???/board-???.c would contain the special devices present for a machine in older kernels. This should be covered by GPL and have to be available for a fee. Individual device drivers might be closed source, no violation there.
– FRob
Feb 27 '16 at 14:02
Thanks, to clarify. There is a chance that the
dtb might be accessible through through the debugfs yet that would rely on CONFIG_DEBUG_FS in .config and even if set still on the mere whim that they actually used a dtb to start with, do I read this right? So with some "bad luck" they did neither and used some sort of direct kernel patching instaed of device tree interface, also right? So this would mean the last resort woult be machine code, given they violate GPLv2 and closesource the kernel, right?– humanityANDpeace
Feb 27 '16 at 7:01
Thanks, to clarify. There is a chance that the
dtb might be accessible through through the debugfs yet that would rely on CONFIG_DEBUG_FS in .config and even if set still on the mere whim that they actually used a dtb to start with, do I read this right? So with some "bad luck" they did neither and used some sort of direct kernel patching instaed of device tree interface, also right? So this would mean the last resort woult be machine code, given they violate GPLv2 and closesource the kernel, right?– humanityANDpeace
Feb 27 '16 at 7:01
Yes and yes for the first two. Last, IANAL, but the machine arch/???/mach-???/board-???.c would contain the special devices present for a machine in older kernels. This should be covered by GPL and have to be available for a fee. Individual device drivers might be closed source, no violation there.
– FRob
Feb 27 '16 at 14:02
Yes and yes for the first two. Last, IANAL, but the machine arch/???/mach-???/board-???.c would contain the special devices present for a machine in older kernels. This should be covered by GPL and have to be available for a fee. Individual device drivers might be closed source, no violation there.
– FRob
Feb 27 '16 at 14:02
add a comment |
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f265890%2fis-it-possible-to-get-the-information-for-a-device-tree-using-sys-of-a-running%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Do you have access to the boot image? You could extract the device tree from there. I can help.
– phk
Oct 17 '16 at 18:03