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/bb7ad099bed584d31542ac237f127798aa... 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@adventiumlabs.com
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users