Oh wow, thanks. I'm quite surprised as I tried the same code as you except without the &-operator; I thought prefixing a function name with the ampersand was optional, both should return the address of the said function AFAIK.

EDIT:
This is great news as I'm now able to initialize the barebone video driver:

Could somebody quickly check my code, it doesn't seem to print the value of f. Either I'm using nl_relocdata wrong, or then I'm too tired and am missing something silly.

http://pastebin.com/N2iiUhd1

That's more or less how SDL behaves at one point, and it's reallocating the function pointer that causes issues. The strings print out fine, calling the function doesn't work though.

EDIT: I've tried everything I can think of. Am I really missing something here or is there no way to use nl_relocdata on a pointer to a function? (I doubt it, even in the wiki it is mentioned)

I see. But how come then that you were able to see the strings?

It does work now, but I'm afraid it will make the porting process a rather "hacky" and dirty one, with #if directives everywhere (breaking the clean code and flexibility) as SDL does rely quite a lot on structs. The code is not that simple in SDL as in the example, so the result might be spaghetti code. For now I'll try to see how it goes with nl_relocdata, if the code becomes an ugly mess I'll tell you. Thanks anyway for pointing out that fix, it'll be useful.

What are the drawbacks of using the ELF loader?

I think I've finally--after many smashed walls, headaches and a bucket of aspirin--narrowed down one major issue.

Have this piece of code for instance:
#include <os.h>

typedef struct type1_t {
    const char *s;
} type1_t;

typedef struct type2_t {
    const char *s1;
    const char *s2;
} type2_t;

int main(void) {
    type1_t test1 = {"foobar"};
    type2_t test2 = {"foo", "bar"};
    printf("test1.s: %s\n", test1.s); /* Prints "foobar" */
    printf("test2.s1: %s\n", test2.s1); /* Should print "foo"; doesn't */
    printf("test2.s2: %s\n", test2.s2); /* Should print "bar"; doesn't */
    return 0;
}
As you can read, the output is:
test1.s: foobar
test2.s1:
test2.s2:
Which is completely wrong. Here's what the output obviously should be: http://codepad.org/DQcGIFy3

I think this might be one of those ARM struct alignment issues, or possibly some other bug. Either way, it has kept me from advancing with the port.
Any input on this one, ExtendeD? (or others, if you know what might be causing the problem)

Sure.

Edit: disregard that, got it to work.

hoffa, will you still continue to try the SDL port?

Yes, I will continue with the SDL port.

either the resulting binary cannot be sent to the calculator

What do you mean exactly?

Using nspire_emu, if I try to send the file nothing happens. No errors no nothing. Now that you mentioned the memcpy issue (didn't anyone was aware of it), I think it might very well be because of that.

or then that GCC doesn't compile the code (with some undefined reference's to memcpy).

See http://www.unsads.com/projects/nsptools/ticket/27 .
I'll quickly fix it if it's a blocking problem for you.

I'd appreciate it a lot if you could fix it, it would allow me to advance with the SDL port and with this library. I'm pretty sure it's what's causing the file not being sent.

A suggestion:

ngl_create_surface(ngl_uint w, ngl_uint h)

Should probably be

ngl_create_surface(ngl_uint x, ngl_uint y, ngl_uint w, ngl_uint h)

ngl_create_surface only allocates memory for the surface. The surface can then be blitted to another surface (which can then be copied to the framebuffer using ngl_flip) using ngl_blit_surface, which asks for the position (the ngl_rect dst_rect parameter).

Edit:
Added support for 16-level grayscale format.