overlays: Add overlay to run an upstream kernel

[agraf]

The difference between upstream and downstream device trees is
marginal by now. This overlay combines all overlays required to
make the downstream device tree upstream compatible.

See: raspberrypi/firmware#943

The idea behind this overlay is that the RPi firmware can then
based on the upstream flag apply this overlay automatically,
providing kernels that need to follow upstream bindings (like
U-Boot) with a device tree to work against.

Signed-off-by: Alexander Graf [email protected]

[pelwell]

Thinking about this, there will be no way to apply any parameters, so are you happy with the defaults?

ovmerge will strip the parameter declarations once any have been applied (put the parameters after each overlay name, separated by commas and no whitespace) - you can force the same behaviour by just appending a comma, or you can explicitly re-apply the defaults.

[agraf]

I don't fully grasp that comment :). So the combined overlay does have an overrides section still around which seems to at least remotely reflect the parameters you can specify in the individual overlay files, no?

With the automated detection and applying of an "upstream" overlay, there obviously is no way to apply parameters. But that shouldn't be terribly bad as long as the defaults are sane.

[pelwell]

That's the question. The most critical parameter is the size of the CMA pool - 256MB is the default value, but it probably won't work on a device with less than 1GB RAM. Fortunately the CMA size can be overridden from cmdline.txt, so I'm tempted to make cma-96 the safe default.

The other most critical parameter is dr_mode - the upstream DTBs are tuned for the devices, with rpi-zero using "otg" (the default) and everything else using "host". You would lose this distinction by applying the same overlay to all downstream DTBs. A better way might be to bake the "natural" dr_mode into the downstream DTBs, knowing that it will be ignored by the dwc-otg driver, and adjusting the overlay to only set dr_mode in the event that the parameter is used.

[agraf]

As for CMA size, we need to find different ways to tune that anyways. Applying random kernel command line options from firmware doesn't scale (think of the BSDs again) and really doesn't apply to any boot flow I'm interested in, as that always involved grub which overwrites whatever firmware puts in the command line anyway :).

As for dr_mode, I agree that it would be a good idea to put the natural mode into the base DTB and only adjust it if desired.

You're definitely much better at device tree wizardry than me, do you think you could just quickly assemble something?

[pelwell]

I've hit a snag - the downstream set of DTBs doesn't include one for Pi Zero - we just use the B+ DTB - although there is one for the Zero W. This means there is nowhere to record the fact that the Zero wants OTG mode.

[agraf]

So how does the downstream kernel on the Zero itself know that it should use OTG instead of Host Mode?

[pelwell]

It doesn't - the downstream driver doesn't support OTG. You have to use the dwc2 overlay to load the upstream driver - dr_mode="otg" is the default.

[agraf]

So that means the Zero simply doesn't work with USB out of the box, even with downstream? Then we can default to dr_mode = "host" in the upstream overlay, no?

[agraf]

Ok, consider me puzzled. I've booted a RPi3 with the dwc2 overlay applied, so dr_mode="otg". I've also verified that it really is:

$ cat /sys/kernel/debug/3f980000.usb/dr_mode
otg

But the USB controller is definitely in host mode - I can use ethernet and an attached USB keyboard.

[pelwell]

The Zero does work with USB out of the box, but as a host. If you think upstream Zero users without an upstream DTB (extremely niche) would be happy with that then I can live with it.

OTG mode means "either host or peripheral, depending on the type of cable and some hardware magic". The Pi 3 is lacking the hardware magic, so it comes up in host mode.

[agraf]

I just tried on the CM3 as well (I don't have a Zero handy) and that works as expected as well with USB host working as USB host.

I still fail to see why the Zero would not work - the special hardware is usually in the micro->USB-A adapter which you need for the Zero to even plug anything in, right? So OTG detection should work just fine there too.

[pelwell]

The upstream DTB has gone out of its way to give the Pi Zero (but not the Zero W, for some reason) a DTB that specifies "otg" mode, whereas the others are locked to "host". However, since all the other Pis either have hardware OTG control methods or tie the pin to ground, setting "otg" mode on all Pis should be safe.

Which brings us back to the ovmerge command line:

ovmerge -c vc4-kms-v3d-overlay.dts,cma-96 dwc2-overlay.dts,dr_mode=otg upstream-aux-interrupt-overlay.dts > upstream-overlay.dts

The resulting overlay will have no parameters to document.

[lategoodbye]

Just a note about the upstream dtb for the Zero W. The dr_mode should also be "otg", but a regression (#2390) forced me to start with "host". Now this issue has been fixed and in 4.17 the dr_mode of Zero W will also be "otg".

[pelwell]

I've merged an updated version of this overlay. The firmware still needs to be modified to load it automatically.