Fix USB/FIQ lock-ups

[schnitzeltony]

What I did - no rocket science [1]:

• Applied RT-patches 4.19.72-rt26 on top of rpi-4.19.y / 4.19.79 (most recent
  version applying rt-patch properly)
• Applied a slightly rebased version of the original (4.14) fiq-patch [2]
• grepped for 'fiq_fsm_spin_lock(' and 'fiq_fsm_spin_unlock(' and added missing
  rt-specific replacements
• rebased changes back to rpi-4.19.y-rt

What this patch does:

• fix a lock/unlock thinko in dwc_otg_hcd.c
• add one missing pair of fiq_fsm_spin_lock/fiq_fsm_spin_unlock replacements

With builds of [1] Rapsi3 is running without a singe issue for two weeks now
and it was stressed by

• moving gigabytes from USB-Stick to SDCard
• several usb-midi-keyboard jam sessions

Addresses [3]

[1] https://github.com/schnitzeltony/meta-raspi-light/tree/master/recipes-kernel/linux
[2] 05dd5c4
[3] #2943

Signed-off-by: Andreas Müller [email protected]

[schnitzeltony]

V2 Thinko was on my side :)

[guysoft]

Hey, I ran a test build of RealtimePi based on this branch. Would appreciate testers, might not work on Pi4 yet, but that I can add on my end later:
http://unofficialpi.org/Distros/RealtimePi/nightly/2019-12-11_2019-09-26-realtimepi-buster-lite-0.4.0.zip

[pelwell]

@guysoft In the event we get no third-party confirmation, I'll accept your gut feel that the patch is plausible.

[guysoft]

I will try find a way to test it, currently out of free SD cards. I'd recommended at least someone boots and confirms with uname before you pull it.

[guysoft]

Looks like its booting on a 3B+. The pi4 is not booting for me. Unsure why.

$ uname -a
Linux realtimepi 4.19.71-rt24-v7 #2 SMP PREEMPT RT Wed Dec 11 19:27:18 GMT 2019 armv7l GNU/Linux

[schnitzeltony]

Yes - I tested with P3 only since I do not have a running pi4 yet (have no cooling solution with soundcard plugged)

@guysoft Can you share some logs?

[guysoft]

Ok I have located I was building the Pi4 kernel wrong. So Its likely this would also work for the Pi4. But it might take me a day or so to get the configuration right and push another image out (this is regarding kenrel7l.img)

After that I can also add kernel8.img build (aka 64bit kernel) as well.

[guysoft]

@schnitzeltony The logs are available on the Jenkins server building this.
Send me an email on guysoft at gmail dot com and I will give you viewing access.

I closed public view after Jenkins had a vulnerability that compromised the jenkins user.

[schnitzeltony]

OK - will wait for pi4 rebuild results. If it still fails I'll send you an email

[guysoft]

Looks like we have a go:

pi@realtimepi:~$ uname -a
Linux realtimepi 4.19.71-rt24-v7l #3 SMP PREEMPT RT Tue Dec 17 12:31:29 GMT 2019 armv7l GNU/Linux
pi@realtimepi:~$ cat /sys/firmware/devicetree/base/model
Raspberry Pi 4 Model B Rev 1.1

You can download the image at:
http://unofficialpi.org/Distros/RealtimePi/nightly/2019-12-17_2019-09-26-realtimepi-buster-lite-0.4.0.zip

md5:
http://unofficialpi.org/Distros/RealtimePi/nightly/2019-12-17_2019-09-26-realtimepi-buster-lite-0.4.0.zip.md5

I am adding the 64bit build too and making a release candidate on my side. This was stalling long enough.

[guysoft]

@pelwell Ok, so it seems all is good except I can't build and test on the 64bit kernel.
I can't seem to find the configuration option in the build docs:
https://www.raspberrypi.org/documentation/linux/kernel/building.md

Can you tell me what I need to set instead of KERNEL="kernel7l" make ARCH=arm bcm2711_defconfig?

Also is bcm2711-rpi-4-b.dtb the same for both?

[pelwell]

Assuming you can get hold of a cross compiler (which might be tricky if building on a 32-bit userland - it's probably easier from x86-64) you'll need something like:

KERNEL=kernel8.img
make ARCH=arm64 bcm2711_defconfig CROSS_COMPILE=aarch64-unknown-linux-gnueabi- bcm2711_defconfig
make ARCH=arm64 bcm2711_defconfig CROSS_COMPILE=aarch64-unknown-linux-gnueabi- zImage modules dtbs

[pelwell]

And yes, the same DTB can be used for both.

[guysoft]

@pelwell Ah, hell. That would be a pain. At the moment CustomPiOS was mainly built so you can install packages on an SD card as if you are doing so on a Pi. That is, it uses the toolchain from Raspbian. This indeed would require the 64bit toolchain to run on the current release of Raspbian
(in fact, we could ship that as part of the distro. It might be a good way to let people build 64bit applications on current Raspbian using the 64bit kernel).
Its not ideal for kernel building, but it works for it and is pretty sturdy to maintain, which is my main goal at the moment.

I think if this is the case for now I will release the current build, and then figure if there is call for a 64bit realtime kernel and if so how to build it.
It also means that I strongly advise pulling this PR. It pus the branch back in working order.

[guysoft]

Ok, rebuilding against raspberrypi/linux and pushing that as RC2