Ben NanoNote patches (MIPS/Ingenic JZ4720) and memory mapping issues

Paul Boddie paul at boddie.org.uk
Mon Mar 12 18:28:50 CET 2018


Hello,

Accompanying my patches for the MIPS Creator CI20 (Ingenic JZ4780), I have 
some patches that get Fiasco.OC booting on the Ben NanoNote (Ingenic JZ4720). 
Currently, I can get a task running that shows some data on the screen. More 
details about the Ben NanoNote can be found here:

http://en.qi-hardware.com/wiki/Ben_NanoNote

(It is a "palmtop" device from around 2010 that was made in fairly limited 
quantities but unfortunately didn't get the attention it deserved that might 
have seen follow-on models, and many more units, being made.)

Unfortunately, the data I display on the screen isn't aligned properly. This 
isn't a fundamental problem since I was happily using the screen to emit bit 
patterns in order to debug the kernel while working to bring it up on the 
hardware.

However, now, in my example task, I see what would appear to be a 9-pixel 
misalignment with the screen. Something like this, each digit being a pixel of 
a certain colour, with groups of ten sharing the same colour:

122222222223333333333...111111111

Although I suspect that this is some kind of peripheral initialisation issue, 
none of the device registers are any different from before, and I can even 
neglect to initialise most of them, keeping the configuration from the 
bootloader, and still see the problem. The registers I do have to change are 
the ones that tell the LCD peripheral where the framebuffer is, but I can 
check that the values I use are consistent with where I am storing screen 
data.

So it makes sense to me to check whether there might be something related to 
L4Re or Fiasco.OC (and my modifications, of course) that could be causing 
this. In my task, I do the following:

l4re_ma_alloc_align(fb_size, fbmem, L4RE_MA_CONTINUOUS | L4RE_MA_PINNED, 6)

Here, the documentation indicates that the alignment will be 2**6 or 64 bytes, 
although it will in practice be page-aligned and thus 4096 bytes in my case.

This, upon success, is then followed by this:

l4re_rm_attach(&fb_vaddr, fb_size,L4RE_RM_SEARCH_ADDR | L4RE_RM_EAGER_MAP,
               fbmem, 0, L4_PAGESHIFT)

And upon success, I obtain the physical address for the region:

l4re_ds_phys(fbmem, 0, &fb_paddr, &fb_size_out)

Both the virtual and physical addresses seem to be page-aligned.

From my limited knowledge of the hardware, I cannot envisage a situation where 
writes to the physical memory would be offset, let alone wrapped in the way 
described above. But I suppose I could easily be unaware of other things that 
might be happening, and so it seems worthwhile to ask around.

By the way, my patches are here:

http://www.boddie.org.uk/paul/L4Re-Fiasco.OC.html

I would certainly appreciate hearing any ideas about things I might have 
overlooked.

Thanks,

Paul



More information about the l4-hackers mailing list