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