Page 1 of 1

Basic raspberry pi OS very slow kprintf

Posted: Thu Aug 11, 2016 7:35 am
by petroms
Hi!

I set out to port an exiting x86 hobby OS called yaosp to ARM for the raspberry pi hardware. It is a nice UNIX like OS, and its original authors managed to implemented so much functionality and ported many libraries that is asonishing for a team of 2 people. The code clarity is also fascinating and the kernel code is very minimal in the same time. (https://github.com/csko/yaosp)

So, here's my take on getting the console working with a kprintf() like method: https://github.com/attilaszia/armyaosp.
The script source/kernel/stat.sh should compile the kernel.img (via a custom written python utility).

I'm using some of Alex Chadwick's code to to negotiate a framebuffer with the GPU via malboxes, and then I use somewhat modified draw_pixel and draw_character methods to redraw the screen upon putchars. The result is horribly slow, it looks like if there was a sleep between consecutive characters when I call the kprintf function with any string.

Why could this happen? Does the per-character redrawing of the 80x25 console buffer have such a performance impact?

(The original x86 code navigated in the VGA video buffer and did not redraw the screen upon putchars, that is what I try to simulate using the console char buffer)

Re: Basic raspberry pi OS very slow kprintf

Posted: Fri Aug 12, 2016 8:48 am
by Firzen
So, I mostly skimmed your code.
But it seems that for every character you draw, you decode a font and then draw each pixel individually.

I'm not sure why the drawing code is all in assembly either, but then again I only skimmed.

In order to speed up the rendering of each character, you can probably decode the font once and store the resulting values in memory. Afterwards you should be able to just blit the characters into your screen memory.

The other more important thing is, why redraw the whole screen? Surely you can just redraw the area that has changed.

There might be some other performance issue with your drawing routine, but I don't think I want to read through asm and try to spot a bug.