KindleBerry Pi, raspberry pi with a kindle screen!

[projectdp]

Originally Posted by NiLuJe

@projectdp: I see a gnueabihf in your TC tuple... The hardfloat ABI is a bad idea when targeting the Kindle. Use a softfp TC.

(It doesn't necessarily have anything to do with the issue at hand, but it'll save you some potential issues later on).

Oh sorry if this isn't clear, I'm compiling this on the Raspberry Pi. I wanted to use KindleVNC to display aaquake2 playing on the Pi.

[twobob]

Originally Posted by projectdp

Appreciate the help! Still though when I go to

~/asciiportal/PDCurses-3.4/sdl1 and do a make, I get the following error:

gcc -O2 -Wall -I..  -o firework ../demos/firework.c libpdcurses.a -L/usr/lib/arm-linux-gnueabihf -lSDL
/usr/bin/ld: libpdcurses.a(initscr.o)(.text+0x320): unresolvable R_ARM_ABS32 relocation against symbol `ttytype'
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make: *** [firework] Error 1

Which is very similar to the error I was receiving earlier.

http://people.defora.org/~khorben/place/blog/8

mentions this type of error in clibs on arm.
he also talks about digging into the errors originating code, which would no doubt help. It's beyond my skills.

I assume you have all the relevant kernel symbols in your keychain, although again I am not sure if that is even related to the issue. sorry mate

[knc1]

Originally Posted by twobob

http://people.defora.org/~khorben/place/blog/8

mentions this type of error in clibs on arm.
he also talks about digging into the errors originating code, which would no doubt help. It's beyond my skills.

I assume you have all the relevant kernel symbols in your keychain, although again I am not sure if that is even related to the issue. sorry mate

-fPIC

And why does that line show an unadorned "gcc" -
Are you native compiling this thing?

[NiLuJe]

@projectdp: Oh, right, missed that, sorry .

Then, yes, +1 on knc1 answer: build the *library* in PIC mode. (If it's using a decent buildsystem, there's a switch, if not, carefully messing around with the *PIC flags).

[projectdp]

Originally Posted by twobob

http://people.defora.org/~khorben/place/blog/8

mentions this type of error in clibs on arm.
he also talks about digging into the errors originating code, which would no doubt help. It's beyond my skills.

I assume you have all the relevant kernel symbols in your keychain, although again I am not sure if that is even related to the issue. sorry mate

I'm not sure that it's safe to assume that all the relevant kernel symbols are in my keychain -- I don't even know what that means. You guys know way more about this, why am I so ignorant of all these things!? I'll do my homework.

Thanks for your efforts!

Originally Posted by knc1

-fPIC

And why does that line show an unadorned "gcc" -
Are you native compiling this thing?

I'll give that a shot.

1: I don't know, what is unadorned about the gcc line?
2: Yes I'm native compiling.

Sure appreciate the help

Originally Posted by NiLuJe

@projectdp: Oh, right, missed that, sorry .

Then, yes, +1 on knc1 answer: build the *library* in PIC mode. (If it's using a decent buildsystem, there's a switch, if not, carefully messing around with the *PIC flags).

Ok awesome I'll try that.
Thanks NiLuJe

[twobob]

unadorned "gcc" -

as opposed to /opt/gcc-linaro-arm-linux-gnueabi-2012.04-20120426_linux/bin/arm-linux-gnueabi-gcc
(Linaro K5)

or

/opt/arm-2007q3/bin/arm-none-linux-gnueabi-gcc
(Code Sourcery K3)

native compile = build for the machine you are running build on

cross compile = build for a different target.

gcc -o foo blar.c would build a windows executable on a window box, linux on a linux

arm-linux-gnueabi-gcc -o foo blar.c would build a kindle-ready one, on both.

Have a read up on the general principles of x-compiling : ) but that's the gist of it : )

(pictures, kindle 5 and 3 TC's)

[knc1]

This is only an example of statements you may find in a Makefile intended to be used for both cross-compiles and native-compiles:

PHP Code:

AS      = $(CROSS_COMPILE)as
LD      = $(CROSS_COMPILE)ld
CC      = $(CROSS_COMPILE)gcc
CPP     = $(CC) -E
AR      = $(CROSS_COMPILE)ar
NM      = $(CROSS_COMPILE)nm
STRIP   = $(CROSS_COMPILE)strip
OBJCOPY = $(CROSS_COMPILE)objcopy
OBJDUMP = $(CROSS_COMPILE)objdump
RANLIB  = $(CROSS_COMPILE)RANLIB 


After which, in the Makefile, all references to the toolchain take the symbolic form of:
$(AS)

So in twobob's example path to the ARM cross-compiler, if the Makefile is called with:

PHP Code:

CROSS_COMPILE='arm-linux-gnueabi-' 


set in its envronment, then $(AS) will be: arm-linux-gnueabi-as

If CROSS_COMPILE is not set (or an empty string), then $(AS) will be: as

The 'unadorned' name for the host machine's assembler.

In other words, your #2 answered your #1

[pepijndevos]

Originally Posted by NiLuJe

Saw it on hackaday, too, but fun project And nice to see it in a 'final' stage .

If only we had working OTG support, the K4/Touch provides mostly the same (or better) processing power as the Pi, minus the graphics chip .

I was thinking the same, and it seems progress is being made: http://www.christian-hoff.com/?p=139

[twobob]

I already have that code in GIT.

needs porting is "all"

time allowing

[skull43]

Amazing work !