Skip to content

Commit 92c7bb6

Browse files
cirosantillicirosantilli
committed
readme: move leds and gpio into hardware models section
1 parent 8916262 commit 92c7bb6

File tree

1 file changed

+96
-108
lines changed

1 file changed

+96
-108
lines changed

‎README.adoc

Lines changed: 96 additions & 108 deletions
Original file line numberDiff line numberDiff line change
@@ -3555,108 +3555,6 @@ Looks like a recompile is needed to modify the image...
35553555
* https://superuser.com/questions/736423/changing-kernel-bootsplash-image
35563556
* https://unix.stackexchange.com/questions/153975/how-to-change-boot-logo-in-linux-mint
35573557

3558-
=== GPIO
3559-
3560-
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.
3561-
3562-
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
3563-
3564-
The best you can do is to hack our link:build[] script to add:
3565-
3566-
....
3567-
HOST_QEMU_OPTS='--extra-cflags=-DDEBUG_PL061=1'
3568-
....
3569-
3570-
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.
3571-
3572-
Then compile with:
3573-
3574-
....
3575-
./build -aa -b br2_gpio -c kernel_config_fragment/gpio -l
3576-
....
3577-
3578-
then test it out with:
3579-
3580-
....
3581-
/gpio.sh
3582-
....
3583-
3584-
Buildroot's Linux tools package provides some GPIO CLI tools: `lsgpio`, `gpio-event-mon`, `gpio-hammer`, TODO document them here.
3585-
3586-
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.
3587-
3588-
=== LEDs
3589-
3590-
TODO: broken when `arm` moved to `-M virt`, same as <<gpio>>.
3591-
3592-
Try hacking QEMU's `hw/misc/arm_sysctl.c` with a printf:
3593-
3594-
....
3595-
static void arm_sysctl_write(void *opaque, hwaddr offset,
3596-
uint64_t val, unsigned size)
3597-
{
3598-
arm_sysctl_state *s = (arm_sysctl_state *)opaque;
3599-
3600-
switch (offset) {
3601-
case 0x08: /* LED */
3602-
printf("LED val = %llx\n", (unsigned long long)val);
3603-
....
3604-
3605-
and then rebuild with:
3606-
3607-
....
3608-
./build -aa -c kernel_config_fragment/leds -lq
3609-
....
3610-
3611-
But beware that one of the LEDs has a heartbeat trigger by default (specified on dts), so it will produce a lot of output.
3612-
3613-
And then activate it with:
3614-
3615-
....
3616-
cd /sys/class/leds/versatile:0
3617-
cat max_brightness
3618-
echo 255 >brightness
3619-
....
3620-
3621-
Relevant QEMU files:
3622-
3623-
* `hw/arm/versatilepb.c`
3624-
* `hw/misc/arm_sysctl.c`
3625-
3626-
Relevant kernel files:
3627-
3628-
* `arch/arm/boot/dts/versatile-pb.dts`
3629-
* `drivers/leds/led-class.c`
3630-
* `drivers/leds/leds-sysctl.c`
3631-
3632-
=== Linux kernel hardening
3633-
3634-
Make it harder to get hacked and easier to notice that you were, at the cost of some (small?) runtime overhead.
3635-
3636-
==== CONFIG_FORTIFY_SOURCE
3637-
3638-
Enable:
3639-
3640-
....
3641-
./build -C 'CONFIG_FORTIFY_SOURCE=y'
3642-
....
3643-
3644-
Test it out:
3645-
3646-
....
3647-
./run -F 'insmod /strlen_overflow.ko'
3648-
....
3649-
3650-
Detects the overflow:
3651-
3652-
....
3653-
<4>[ 3.136382] strlen_overflow: loading out-of-tree module taints kernel.
3654-
<0>[ 3.139534] detected buffer overflow in strlen
3655-
<4>[ 3.141318] ------------[ cut here ]------------
3656-
....
3657-
3658-
followed by a trace.
3659-
36603558
=== Linux kernel testing
36613559

36623560
https://stackoverflow.com/questions/3177338/how-is-the-linux-kernel-tested
@@ -3836,22 +3734,112 @@ As a consequence:
38363734
* it is possible to restore snapshots across boots, since they stay on the same image the entire time
38373735
* it is not possible to use snapshots with <<initrd>> in our setup, since we don't pass `-drive` at all when initrd is enabled
38383736

3839-
=== Educational hardware models
3737+
=== Hardware models
38403738

3841-
We have added and interacted with a few educational hardware models in QEMU.
3739+
This section documents some interesting peripheral hardware models, specially simpler ones that are fun to learn.
38423740

3843-
This is useful to learn:
3741+
Studying them can teach you:
38443742

38453743
* how to create new hardware models for QEMU. Overview: https://stackoverflow.com/questions/28315265/how-to-add-a-new-device-in-qemu-source-code
38463744
* how the Linux kernel interacts with hardware
38473745

38483746
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.
38493747

3850-
==== platform_device
3748+
==== Mainline hardware models
3749+
3750+
This section documents hardware models present in the QEMU upstream.
3751+
3752+
===== GPIO
3753+
3754+
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.
3755+
3756+
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
3757+
3758+
The best you can do is to hack our link:build[] script to add:
3759+
3760+
....
3761+
HOST_QEMU_OPTS='--extra-cflags=-DDEBUG_PL061=1'
3762+
....
3763+
3764+
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.
3765+
3766+
Then compile with:
3767+
3768+
....
3769+
./build -aa -b br2_gpio -c kernel_config_fragment/gpio -l
3770+
....
3771+
3772+
then test it out with:
3773+
3774+
....
3775+
/gpio.sh
3776+
....
3777+
3778+
Buildroot's Linux tools package provides some GPIO CLI tools: `lsgpio`, `gpio-event-mon`, `gpio-hammer`, TODO document them here.
3779+
3780+
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.
3781+
3782+
===== LEDs
3783+
3784+
TODO: broken when `arm` moved to `-M virt`, same as <<gpio>>.
3785+
3786+
Hack QEMU's `hw/misc/arm_sysctl.c` with a printf:
3787+
3788+
....
3789+
static void arm_sysctl_write(void *opaque, hwaddr offset,
3790+
uint64_t val, unsigned size)
3791+
{
3792+
arm_sysctl_state *s = (arm_sysctl_state *)opaque;
3793+
3794+
switch (offset) {
3795+
case 0x08: /* LED */
3796+
printf("LED val = %llx\n", (unsigned long long)val);
3797+
....
3798+
3799+
and then rebuild with:
3800+
3801+
....
3802+
./build -aa -c kernel_config_fragment/leds -lq
3803+
....
3804+
3805+
But beware that one of the LEDs has a heartbeat trigger by default (specified on dts), so it will produce a lot of output.
3806+
3807+
And then activate it with:
3808+
3809+
....
3810+
cd /sys/class/leds/versatile:0
3811+
cat max_brightness
3812+
echo 255 >brightness
3813+
....
3814+
3815+
Relevant QEMU files:
3816+
3817+
* `hw/arm/versatilepb.c`
3818+
* `hw/misc/arm_sysctl.c`
3819+
3820+
Relevant kernel files:
3821+
3822+
* `arch/arm/boot/dts/versatile-pb.dts`
3823+
* `drivers/leds/led-class.c`
3824+
* `drivers/leds/leds-sysctl.c`
3825+
3826+
==== Fork hardware models
3827+
3828+
This section documents hardware models added on link:https://github.com/cirosantilli/qemu[our fork of QEMU].
3829+
3830+
These have been explicitly designed to be educational rather than model real existing hardware.
3831+
3832+
===== platform_device
38513833

38523834
This is an example of hardware coded into an ARM `-M versatilepb` SoC.
38533835

3854-
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.
3836+
Using this device now requires checking out to the branch:
3837+
3838+
....
3839+
git checkout platform-device
3840+
....
3841+
3842+
before building, it does not work on master.
38553843

38563844
The module itself can be found at: https://github.com/cirosantilli/linux-kernel-module-cheat/blob/platform-device/kernel_module/platform_device.c
38573845

@@ -3894,7 +3882,7 @@ insmod /platform_device.ko
38943882

38953883
==== gem5 educational hardware models
38963884

3897-
TODO
3885+
TODO get some working!
38983886

38993887
http://gedare-csphd.blogspot.co.uk/2013/02/adding-simple-io-device-to-gem5.html
39003888

0 commit comments

Comments
 (0)