Skip to content
  1. Aug 08, 2020
    • Tim Gover's avatar
      dts: bcm2711: Disable DVP by default · f2f7e4b2
      Tim Gover authored 
      The HDMI DVP should be disabled by default as is the case for other
display related drivers. This changes resolves an issue when using
the legacy firmware display driver where the DVP caused the 108 MHz
clock in HDMI TX to be gated off when Linux started. This effectively
stopped the firmware from being able to change the HDMI analog PHY
registers.

Add a fragment to re-enable this in vc4-kms-v3d-pi4-overlay
      3 tags
      f2f7e4b2
  3. Aug 03, 2020
  5. Jul 31, 2020
  7. Jul 30, 2020
    • Phil Elwell's avatar
      overlays: Fix sc16is75x overlays w.r.t. serdev · 5e1be667
      Phil Elwell authored 
      Enabling serdev support in rpi-5.4.y had the unintended consequence of
making any UART device node with a subnode look like a "serdev" node,
which prevents it from having the usual /dev/ttyXXX character device.
Solve the problem by moving the subnode (a static clock declaration)
into the root node.

At the same time, regularise (and sometimes correct) the overlays.

See: https://github.com/raspberrypi/linux/issues/3765



Signed-off-by: default avatarPhil Elwell <phil@raspberrypi.com>
      5e1be667
    • Phil Elwell's avatar
      ARM: proc-v7: Force misalignment of early stmia · 068c6b23
      Phil Elwell authored 
      In an attempt to prevent the problem of CPUn not starting, explicitly
misalign the scratch space used to save registers acros the cache
invalidation.

Notes:
At this stage in the boot process the core is running with its cache
disabled. Before enabling the cache its contents must be explicitly
invalidated, a process that requires quite a few registers that the
caller must preserve. Evidence suggests that something is writing a
block of zeroes over that space at a time when all other cores should
be idle, possibly some kind of write-combiner, and the misalignment is
designed to disrupt any write-coalescing.

In truth, I don't understand why this patch works, and when the failure
is so random it is hard to be certain that this isn't just rolling the
dice again. One interesting test would be to change the "addeq r12, #4"s
to "addeq r12, #0"s determine see if the offset itself is significant or
just the additional code.

See: https://github.com/Hexxeh/rpi-firmware/issues/232



Signed-off-by: default avatarPhil Elwell <phil@raspberrypi.com>
      068c6b23
  9. Jul 28, 2020
  11. Jul 27, 2020
  13. Jul 24, 2020
  15. Jul 23, 2020
  17. Jul 22, 2020
  19. Jul 21, 2020
  21. Jul 18, 2020
  23. Jul 17, 2020
  25. Jul 16, 2020