Hi,
Again, thank you very much for your prompt answer.
Looks good, the tee_mm functions handle resource allocation typically virtual or physical memory. It doesn't touch the memory itself. The code above looks OK. Yep, the memory will be physically contiguous since the entire TA RAM range (represented here by tee_mm_sec_ddr) is mapped with physically contiguous memory.
The code 'works' beautifully. That is; The FB addresses it produces seem plausible: D/TC:0 0 imx_lcdif_init:334 fb[0] @0x88e00000 (pa 0x8e100000) D/TC:0 0 imx_lcdif_init:334 fb[1] @0x88e96000 (pa 0x8e196000) Even accessing the buffer using the corresponding virtual addresses produces no Abort faults.
Unfortunately, it doesn't produce an image on the LCD either. However, if I (illegally) re-use part of shared memory as a frame buffer, I _do_ get an image. Details from conf.mk: CFG_DRAM_BASE = 0x80000000 CFG_DDR_SIZE = 0x10000000 CFG_SHMEM_SIZE = 0x00200000 CFG_SHMEM_START = ($(CFG_DRAM_BASE) + $(CFG_DDR_SIZE) - $(CFG_SHMEM_SIZE))
Details from code: fb_pa = 0x90000000 - FB_SIZE; fb_va = (void *fb_pa, MEM_AREA_NSEC_SHM);
We are starting to suspect that the LCD peripheral is denied access to the frame buffer by the TZ controller, and this specific peripheral's bus master doesn't seem to have corresponding Supervisor mode bits in the HP0 or SA register.
Now I do know that this problem is beyond the scope of this mailing list, but if anybody on this list knows more about this, I'd be more than happy to hear about it!
With kind regards,
Robert.