Draft email to genode list about framebuffer

Fri Sep 21 12:38:55 CEST 2018

Hi Edward,

On Mon, Sep 17, 2018 at 12:21:46PM -0500, Edward Sandberg wrote:
> I am attempting to add framebuffer support for the Wandboard Quad using
> the imx53 code as a base and modifying it as necessary.  At this point I
> can build run/framebuffer with the seL4 kernel and I see no errors when
> I run the uImage on the wandboard Quad but I also don't get any HDMI ouput.
> 
> I resolved the problem of the bootloader not providing the framebuffer
> information by hardcoding the framebuffer address, width, height, bpp,
> and pitch in the framebuffer.cc file.  I have tracked down almost all of
> the addresses that needed to be modified but I am stuck on a couple things.
> 

I'm not sure, whether your attempt to tweak the existing IPU driver
written for i.MX53 QSB slightly is the best approach. Honestly, the
display management of the i.MX series is quite complex. Did you had a
look into the manual? There are more then 600 pages for the register
description of the IPU only. That does not include IP cores for HDMI,
pulse-width-modulation, power-management and clocking needed for it,
and necessary pin configuration (e.g.: IOMUX).

The driver we wrote is a hard-coded version for i.MX53 QSB or Sabre
Tablet that assumes you're using either a LVDS diplay connected to diplay
port di0 or di1 both with fixed size resolution. Due to the complexity
of the display engine we followed the approach to trace Linux kernel
accesses of IPU registers and tried to match it to the model given by
the manual. Anyway, that approach does not scale that well. If you
have to use another display, resolution, display port etc. on your
board, maybe even want to change some of that dynamically, there are
much more things to do than just changing the I/O memory base
addresses or interrupt numbers.

Dependent on your use-case, you might succeed quicker by tweaking the
existent implementation, as long as you have a static display
configuration and will never change the underlying board. But, if
you're not 100% sure about future changes regarding the display
configuration or the actual board, my advice would be to either
delving deeply into the inner workings of the IPU and rewrite a
dynamic model of the driver (complex task, but scales best), or to
follow the dde-linux approach like we did for the FEC ethernet and USB
driver of i.MX6 (dependent on your linux kernel knowledge, less
complex).

Some last remarks regarding you target platform:

* AFAIK, there are two IPU block on the SoC with 4 display ports in
  total, you will have to know which disply port is used by your
  display in the first place
* The IOMUX configuration is crucial for your display configuration,
  at best you take all necessary settings given in the device tree of
  your board, or by dumping the register set after booting e.g., Linux
* Of course, clocking and power-control are relevant too, the CCM
  (clock control module), and PMU (power management unit) are at least
  relevant for you
* HDMI uses another IP core beside the IPU, it is not used by our
  i.MX53 setup, so you have to enable that separately

> In /os/src/drivers/platform/spec/imx53/ccm.h lines 82 and 83, what are
> these addresses?  I can't find them anywhere in the imx53 device tree.
> write<Cscmr2>(0xa2b32f0b);
> write<Cdcdr>(0x14370092);

Those are clock settings in the CCM for clock multiplexing and
dividers. Please, have a look into the i.MX53 technical manual for
further details.

> 
> In:
> ./os/src/drivers/platform/spec/imx53/iim.h line 27,
> ./os/src/drivers/framebuffer/spec/imx53/pwm.h line 22, and
> ./os/src/drivers/platform/spec/imx53/src.h line 30
> I am unclear on the significance of the chosen register/bitfields and if
> they needs to be changed to match the imx6:
> struct Fuse_bank0_gp6 : Register<0x878, 32> {};

It is used to read the board revision. We use it in the platform
driver, which exports the information to the IPU driver. The IPU
driver than decides which display configuration has to be used: QSB or
SABRE tablet.

> struct Ctrl_reg : Register<0x0, 32>

The PWM (Pulse-Width-Modulation) device is used on the i.MX53 SABRE
tablet to drive the tablet's display. It is not needed for the IPU
itself, or for the LVDS display we used for i.MX53 QSB.

> struct Ipu_rst : Bitfield<3, 1> { };

Obviously, it resets the IPU in the first place.

> 
> Can anyone help with these?
> 
> Also I have added all of my changes in a branch of the genode code:
> https://github.com/sand7000/genode/commit/bb7ad099bed584d31542ac237f127798aa0e032c
> In case anyone is interested or is familiar with the imx53/imx6 and has
> insight into what else I might need to modify.

I hope I could help you a bit with my explanations. Honestly again,
the topic is too complex to find the missing piece in your
implementation by having a look at it. You first need to investigate
your concrete board setup.

Best regards
Stefan

> 
> -- 
> Edward Sandberg
> Adventium Labs
> 111 3rd Avenue S. Suite #100
> Minneapolis, MN 55401
> ed.sandberg at adventiumlabs.com
> 
> 
> 
> _______________________________________________
> Genode users mailing list
> users at lists.genode.org
> https://lists.genode.org/listinfo/users

-- 
Stefan Kalkowski
Genode labs

https://github.com.skalk | https://genode.org