diff --git a/README.adoc b/README.adoc index 8aff96b..b24f702 100644 --- a/README.adoc +++ b/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://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 <>. - -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 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 not possible to use snapshots with <> 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 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. -==== 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 <>. + +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. -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 @@ -3894,7 +3882,7 @@ insmod /platform_device.ko ==== gem5 educational hardware models -TODO +TODO get some working! http://gedare-csphd.blogspot.co.uk/2013/02/adding-simple-io-device-to-gem5.html