mirror of
https://github.com/cirosantilli/linux-kernel-module-cheat.git
synced 2026-01-28 04:24:26 +01:00
readme: move leds and gpio into hardware models section
This commit is contained in:
Ciro Santilli
204
README.adoc
204
README.adoc
@@ -3555,108 +3555,6 @@ Looks like a recompile is needed to modify the image...
|
|||||||
* https://superuser.com/questions/736423/changing-kernel-bootsplash-image
|
* https://superuser.com/questions/736423/changing-kernel-bootsplash-image
|
||||||
* https://unix.stackexchange.com/questions/153975/how-to-change-boot-logo-in-linux-mint
|
* https://unix.stackexchange.com/questions/153975/how-to-change-boot-logo-in-linux-mint
|
||||||
|
|
||||||
=== GPIO
|
|
||||||
|
|
||||||
TODO: broken. Was working before we moved `arm` from `-M versatilepb` to `-M virt` around af210a76711b7fa4554dcc2abd0ddacfc810dfd4. Either make it work on `-M virt` if that is possible, or document precisely how to make it work with `versatilepb`, or hopefully `vexpress` which is newer.
|
|
||||||
|
|
||||||
QEMU does not have a very nice mechanism to observe GPIO activity: https://raspberrypi.stackexchange.com/questions/56373/is-it-possible-to-get-the-state-of-the-leds-and-gpios-in-a-qemu-emulation-like-t/69267#69267
|
|
||||||
|
|
||||||
The best you can do is to hack our link:build[] script to add:
|
|
||||||
|
|
||||||
....
|
|
||||||
HOST_QEMU_OPTS='--extra-cflags=-DDEBUG_PL061=1'
|
|
||||||
....
|
|
||||||
|
|
||||||
where link:http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0190b/index.html[PL061] is the dominating ARM Holdings hardware that handles GPIO.
|
|
||||||
|
|
||||||
Then compile with:
|
|
||||||
|
|
||||||
....
|
|
||||||
./build -aa -b br2_gpio -c kernel_config_fragment/gpio -l
|
|
||||||
....
|
|
||||||
|
|
||||||
then test it out with:
|
|
||||||
|
|
||||||
....
|
|
||||||
/gpio.sh
|
|
||||||
....
|
|
||||||
|
|
||||||
Buildroot's Linux tools package provides some GPIO CLI tools: `lsgpio`, `gpio-event-mon`, `gpio-hammer`, TODO document them here.
|
|
||||||
|
|
||||||
Those broke MIPS build in 2017-02: https://bugs.busybox.net/show_bug.cgi?id=10276 and so we force disable them in our MIPS build currently.
|
|
||||||
|
|
||||||
=== LEDs
|
|
||||||
|
|
||||||
TODO: broken when `arm` moved to `-M virt`, same as <<gpio>>.
|
|
||||||
|
|
||||||
Try hacking QEMU's `hw/misc/arm_sysctl.c` with a printf:
|
|
||||||
|
|
||||||
....
|
|
||||||
static void arm_sysctl_write(void *opaque, hwaddr offset,
|
|
||||||
uint64_t val, unsigned size)
|
|
||||||
{
|
|
||||||
arm_sysctl_state *s = (arm_sysctl_state *)opaque;
|
|
||||||
|
|
||||||
switch (offset) {
|
|
||||||
case 0x08: /* LED */
|
|
||||||
printf("LED val = %llx\n", (unsigned long long)val);
|
|
||||||
....
|
|
||||||
|
|
||||||
and then rebuild with:
|
|
||||||
|
|
||||||
....
|
|
||||||
./build -aa -c kernel_config_fragment/leds -lq
|
|
||||||
....
|
|
||||||
|
|
||||||
But beware that one of the LEDs has a heartbeat trigger by default (specified on dts), so it will produce a lot of output.
|
|
||||||
|
|
||||||
And then activate it with:
|
|
||||||
|
|
||||||
....
|
|
||||||
cd /sys/class/leds/versatile:0
|
|
||||||
cat max_brightness
|
|
||||||
echo 255 >brightness
|
|
||||||
....
|
|
||||||
|
|
||||||
Relevant QEMU files:
|
|
||||||
|
|
||||||
* `hw/arm/versatilepb.c`
|
|
||||||
* `hw/misc/arm_sysctl.c`
|
|
||||||
|
|
||||||
Relevant kernel files:
|
|
||||||
|
|
||||||
* `arch/arm/boot/dts/versatile-pb.dts`
|
|
||||||
* `drivers/leds/led-class.c`
|
|
||||||
* `drivers/leds/leds-sysctl.c`
|
|
||||||
|
|
||||||
=== Linux kernel hardening
|
|
||||||
|
|
||||||
Make it harder to get hacked and easier to notice that you were, at the cost of some (small?) runtime overhead.
|
|
||||||
|
|
||||||
==== CONFIG_FORTIFY_SOURCE
|
|
||||||
|
|
||||||
Enable:
|
|
||||||
|
|
||||||
....
|
|
||||||
./build -C 'CONFIG_FORTIFY_SOURCE=y'
|
|
||||||
....
|
|
||||||
|
|
||||||
Test it out:
|
|
||||||
|
|
||||||
....
|
|
||||||
./run -F 'insmod /strlen_overflow.ko'
|
|
||||||
....
|
|
||||||
|
|
||||||
Detects the overflow:
|
|
||||||
|
|
||||||
....
|
|
||||||
<4>[ 3.136382] strlen_overflow: loading out-of-tree module taints kernel.
|
|
||||||
<0>[ 3.139534] detected buffer overflow in strlen
|
|
||||||
<4>[ 3.141318] ------------[ cut here ]------------
|
|
||||||
....
|
|
||||||
|
|
||||||
followed by a trace.
|
|
||||||
|
|
||||||
=== Linux kernel testing
|
=== Linux kernel testing
|
||||||
|
|
||||||
https://stackoverflow.com/questions/3177338/how-is-the-linux-kernel-tested
|
https://stackoverflow.com/questions/3177338/how-is-the-linux-kernel-tested
|
||||||
@@ -3836,22 +3734,112 @@ As a consequence:
|
|||||||
* it is possible to restore snapshots across boots, since they stay on the same image the entire time
|
* it is possible to restore snapshots across boots, since they stay on the same image the entire time
|
||||||
* it is not possible to use snapshots with <<initrd>> in our setup, since we don't pass `-drive` at all when initrd is enabled
|
* it is not possible to use snapshots with <<initrd>> in our setup, since we don't pass `-drive` at all when initrd is enabled
|
||||||
|
|
||||||
=== Educational hardware models
|
=== Hardware models
|
||||||
|
|
||||||
We have added and interacted with a few educational hardware models in QEMU.
|
This section documents some interesting peripheral hardware models, specially simpler ones that are fun to learn.
|
||||||
|
|
||||||
This is useful to learn:
|
Studying them can teach you:
|
||||||
|
|
||||||
* how to create new hardware models for QEMU. Overview: https://stackoverflow.com/questions/28315265/how-to-add-a-new-device-in-qemu-source-code
|
* how to create new hardware models for QEMU. Overview: https://stackoverflow.com/questions/28315265/how-to-add-a-new-device-in-qemu-source-code
|
||||||
* how the Linux kernel interacts with hardware
|
* how the Linux kernel interacts with hardware
|
||||||
|
|
||||||
To get started, have a look at the "Hardware device drivers" section under link:kernel_module/README.adoc[], and try to run those modules, and then grep the QEMU source code.
|
To get started, have a look at the "Hardware device drivers" section under link:kernel_module/README.adoc[], and try to run those modules, and then grep the QEMU source code.
|
||||||
|
|
||||||
==== platform_device
|
==== Mainline hardware models
|
||||||
|
|
||||||
|
This section documents hardware models present in the QEMU upstream.
|
||||||
|
|
||||||
|
===== GPIO
|
||||||
|
|
||||||
|
TODO: broken. Was working before we moved `arm` from `-M versatilepb` to `-M virt` around af210a76711b7fa4554dcc2abd0ddacfc810dfd4. Either make it work on `-M virt` if that is possible, or document precisely how to make it work with `versatilepb`, or hopefully `vexpress` which is newer.
|
||||||
|
|
||||||
|
QEMU does not have a very nice mechanism to observe GPIO activity: https://raspberrypi.stackexchange.com/questions/56373/is-it-possible-to-get-the-state-of-the-leds-and-gpios-in-a-qemu-emulation-like-t/69267#69267
|
||||||
|
|
||||||
|
The best you can do is to hack our link:build[] script to add:
|
||||||
|
|
||||||
|
....
|
||||||
|
HOST_QEMU_OPTS='--extra-cflags=-DDEBUG_PL061=1'
|
||||||
|
....
|
||||||
|
|
||||||
|
where link:http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0190b/index.html[PL061] is the dominating ARM Holdings hardware that handles GPIO.
|
||||||
|
|
||||||
|
Then compile with:
|
||||||
|
|
||||||
|
....
|
||||||
|
./build -aa -b br2_gpio -c kernel_config_fragment/gpio -l
|
||||||
|
....
|
||||||
|
|
||||||
|
then test it out with:
|
||||||
|
|
||||||
|
....
|
||||||
|
/gpio.sh
|
||||||
|
....
|
||||||
|
|
||||||
|
Buildroot's Linux tools package provides some GPIO CLI tools: `lsgpio`, `gpio-event-mon`, `gpio-hammer`, TODO document them here.
|
||||||
|
|
||||||
|
Those broke MIPS build in 2017-02: https://bugs.busybox.net/show_bug.cgi?id=10276 and so we force disable them in our MIPS build currently.
|
||||||
|
|
||||||
|
===== LEDs
|
||||||
|
|
||||||
|
TODO: broken when `arm` moved to `-M virt`, same as <<gpio>>.
|
||||||
|
|
||||||
|
Hack QEMU's `hw/misc/arm_sysctl.c` with a printf:
|
||||||
|
|
||||||
|
....
|
||||||
|
static void arm_sysctl_write(void *opaque, hwaddr offset,
|
||||||
|
uint64_t val, unsigned size)
|
||||||
|
{
|
||||||
|
arm_sysctl_state *s = (arm_sysctl_state *)opaque;
|
||||||
|
|
||||||
|
switch (offset) {
|
||||||
|
case 0x08: /* LED */
|
||||||
|
printf("LED val = %llx\n", (unsigned long long)val);
|
||||||
|
....
|
||||||
|
|
||||||
|
and then rebuild with:
|
||||||
|
|
||||||
|
....
|
||||||
|
./build -aa -c kernel_config_fragment/leds -lq
|
||||||
|
....
|
||||||
|
|
||||||
|
But beware that one of the LEDs has a heartbeat trigger by default (specified on dts), so it will produce a lot of output.
|
||||||
|
|
||||||
|
And then activate it with:
|
||||||
|
|
||||||
|
....
|
||||||
|
cd /sys/class/leds/versatile:0
|
||||||
|
cat max_brightness
|
||||||
|
echo 255 >brightness
|
||||||
|
....
|
||||||
|
|
||||||
|
Relevant QEMU files:
|
||||||
|
|
||||||
|
* `hw/arm/versatilepb.c`
|
||||||
|
* `hw/misc/arm_sysctl.c`
|
||||||
|
|
||||||
|
Relevant kernel files:
|
||||||
|
|
||||||
|
* `arch/arm/boot/dts/versatile-pb.dts`
|
||||||
|
* `drivers/leds/led-class.c`
|
||||||
|
* `drivers/leds/leds-sysctl.c`
|
||||||
|
|
||||||
|
==== Fork hardware models
|
||||||
|
|
||||||
|
This section documents hardware models added on link:https://github.com/cirosantilli/qemu[our fork of QEMU].
|
||||||
|
|
||||||
|
These have been explicitly designed to be educational rather than model real existing hardware.
|
||||||
|
|
||||||
|
===== platform_device
|
||||||
|
|
||||||
This is an example of hardware coded into an ARM `-M versatilepb` SoC.
|
This is an example of hardware coded into an ARM `-M versatilepb` SoC.
|
||||||
|
|
||||||
Using this device now requires checking out to: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/platform-device before building, it does not work on master.
|
Using this device now requires checking out to the branch:
|
||||||
|
|
||||||
|
....
|
||||||
|
git checkout platform-device
|
||||||
|
....
|
||||||
|
|
||||||
|
before building, it does not work on master.
|
||||||
|
|
||||||
The module itself can be found at: https://github.com/cirosantilli/linux-kernel-module-cheat/blob/platform-device/kernel_module/platform_device.c
|
The module itself can be found at: https://github.com/cirosantilli/linux-kernel-module-cheat/blob/platform-device/kernel_module/platform_device.c
|
||||||
|
|
||||||
@@ -3894,7 +3882,7 @@ insmod /platform_device.ko
|
|||||||
|
|
||||||
==== gem5 educational hardware models
|
==== gem5 educational hardware models
|
||||||
|
|
||||||
TODO
|
TODO get some working!
|
||||||
|
|
||||||
http://gedare-csphd.blogspot.co.uk/2013/02/adding-simple-io-device-to-gem5.html
|
http://gedare-csphd.blogspot.co.uk/2013/02/adding-simple-io-device-to-gem5.html
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user