03 May, 2016

7 commits


02 May, 2016

1 commit


01 May, 2016

4 commits


29 Apr, 2016

2 commits


28 Apr, 2016

5 commits

  • The DMA was outputting the palette on the screen because the base
    for the DMA was not after the palette. In addition to that, the ceiling was
    also too high, this led that the output on the screen was shifted.

    NOTE: According to the TRM, even in 16/24bit mode a palette is required
    in the first 32 bytes of the framebuffer.

    See also:
    https://e2e.ti.com/support/arm/sitara_arm/f/791/p/234967/834483#834483

    "In this mode, the LCDC will assume all information is data and thus you
    need to ensure that the DMA points to the first pixel of data and not the
    first entry in the frame buffer which is the beginning of the 512 byte
    palette."

    Signed-off-by: Martin Pietryka
    Reviewed-by: Hannes Schmelzer
    Tested-by: Hannes Schmelzer

    Martin Pietryka
     
  • To support 16bpp we just need to change the raster_ctrl register
    accordingly. Also 32bpp mode should work as well, but was not tested.
    According to the TRM the uppermost byte will be ignored when
    LCD_TFT_24BPP_UNPACK is set.

    The switch logic is based on the Linux kernel tilcdc driver:
    drivers/gpu/drm/tilcdc/tilcdc_crtc.c: lines 407 through 419
    (kernel was checked out at commit: bcc981e9ed8)

    Signed-off-by: Martin Pietryka
    Reviewed-by: Hannes Schmelzer
    Tested-by: Hannes Schmelzer

    Martin Pietryka
     
  • While the OMAP3 has 64KiB of SRAM, per the TRM the download area is only
    from 0x40200000 to 0x4020F000 and exceeding that will cause failure to
    boot. Further, we need to make sure that we don't run into
    SRAM_SCRATCH_SPACE_ADDR as once SPL is running we will write values
    there and would corrupt our running image.

    Cc: Adam Ford
    Cc: Steve Sakoman
    Signed-off-by: Tom Rini

    Tom Rini
     
  • LDO3 is used for the VGA output, this fixes a regression where the VGA
    output on these boards would no longer work.

    Signed-off-by: Hans de Goede
    Acked-by: Ian Campbell

    Hans de Goede
     
  • We are running with the caches disabled when mctl_mem_matches gets called,
    but the cpu's write buffer is still there and can still get in the way,
    add a memory barrier to fix this.

    This avoids mctl_mem_matches always returning false in some cases, which
    was resulting in:

    U-Boot SPL 2015.07 (Apr 14 2016 - 18:47:26)
    DRAM: 1024 MiB

    U-Boot 2015.07 (Apr 14 2016 - 18:47:26 +0200) Allwinner Technology

    CPU: Allwinner A23 (SUN8I)
    DRAM: 512 MiB

    Where 512 MiB is the right amount, but the DRAM controller would be
    initialized for 1024 MiB.

    Signed-off-by: Hans de Goede
    Acked-by: Ian Campbell

    Hans de Goede
     

26 Apr, 2016

21 commits