Thread by @Foone, Can anyone suggest a way for me to cross-compile binaries for QNX [...]

Can anyone suggest a way for me to cross-compile binaries for QNX 6.2, on armle? (specifically, ARM9)

I've tried looking at the official methods and it doesn't look like there's really a way to get this setup without spending lots of money (and I'm not even sure that would work)

and the problem with googling things like "GCC FOR QNX" is that it gives me options like running GCC on QNX, which is great, except I don't have a working QNX 6.2 arm machine I could run GCC on... except the one I'm compiling for.

so I want to compile elsewhere, and then move the binaries over.

and I can get a 30-day evaluation copy of QNX... but they're gonna give me QNX 7.0 which isn't the version I need, plus I don't have an arm9 system to run it on.
(and I'm not sure if I even could run QNX 7.0 X86 and crosscompile to armle)

there is an openQNX project, but it's not exactly gonna help because step one in compiling it is "install QNX 6.4.0" https://github.com/vocho/openqnx

vocho/openqnx

mirror of git://git.code.sf.net/p/monartis/openqnx - vocho/openqnx

https://github.com/vocho/openqnx

I did find a download on their site of the QNX Dev Platform 6.5.0 for x86 which I figured might be close enough to try getting started, but it demands a license key and won't take my license key (probably because it's QNX 7.0 only?)

although if I tell it to run off the CD instead of installing... I'm at a desktop in about 4 seconds.

QNX is pretty neat.

oh hey it's got Firefox 2.0, from 2008!

That's too old to load up twitter.

ok so there's a QNX Software Center which lets you manage installations, so hopefully it'll help me get to the point of getting a license key for 6.2 (or 6.5)

amusingly, it's written in java, and built on top of Eclipse.

nope, it just lets me install QNX 7.0 SDK. I don't think 7.0 QNX binaries are backwards compatible... but I don't know! so maybe I should do that anyway.

wait, am I picking an update policy, or a political party?

the official download site has lots of potentially interesting sections like this, the SDK for 6.4...

but clicking them says "OK ENTER YOUR SERIAL NUMBER AND PASSWORD" which obviously I don't have.
So that's not an option.

so I've got the QNX 7.0 SDK installed and it includes a lot of armle binaries, so let's try copying one of those over and seeing if they run...

nope.
weird error, but I'm guessing it's just mis-identified because QNX 6.2 doesn't know how to run a QNX 7.0 binary

so it turns out an ISO of the 6.3.2 SDK is on the internet archive... let's see if I can install this.

NOPE! the installer won't take my evaluation key, because it's for 7.0, not 6.3.2

and it appears they both de-metadata (they're named by their hash!) and encrypt the files inside the installer, so I can't just yoink out a binary or two

although the hashes don't match the files as-is: so I think they're accessed by the hash of the unencrypted file. huh.

I'm not saying I'm trying to bypass the serial check, but it does some amusing things:
first of all, there's valid serials that were leaked on the openqnx forum, but they're all expired now.
So just set your windows clock back, right?

except... it doesn't work.
So, see, it doesn't actually check your windows clock: it checks your BIOS clock.
Sneaky!
So you set the BIOS clock back, and... it doesn't work.

because it turns out it also looks through your hard drive (presumably like C:\\ and C:\\Windows) and if it sees any files with a last-modified date later than your BIOS date, it uses that date instead.

it's almost like they've got a vested interest in people not stealing this software, eh?

but that means to get it working you'd need to install an OS fresh on a machine which had had the clock set back prior to installation, to ensure there were no late-dated-files on the drive.

And who would go to all that effort just to run an old SDK installer?

why yes, windows XP, it's definitely 2004, I turned off virtualbox's time sync, I set the BIOS back using a DOS boot disk, and I definitely don't have a network connection

ahh, dang it. this is service pack 3, which has some files from 2008.

REINSTALL TIME

SP2 was 2004, so it should be fine.

And yes, I could probably do this faster by writing a script to search the hard drive and change all the timestamps, but reinstalling XP is mostly automated and the non-automated parts I can do in my sleep.
So just doing a reinstall may be "slower" but takes less Foone-CPU-time

so I can be doing other things while it reinstalls.

like eating a burrito

SHIT, AN IMPASSE!

nevermind it turns out I have lots of XP keys

WHY AM I SEEING 2007 FILES ON MY XP SP2 INSTALL, MICROSOFT?

gonna boot a livecd, mount the windows partition, and recursively search for later-than-2004 files.

I just said fuck it and changed every file on the partition to have a modification time of 4:20 am June 23, 2004

annoyingly, linux (somehow) loaded the correct time instead of the wrong one I stuffed into the BIOS, so then when I rebooted back into windows, it was 2020 again, and now all my work on fixing dates has been undone

and now... it won't boot.

it won't boot off the LIVECD.

HOW DID I BREAK A LIVECD?

OK I got it working by applying Tech Support Action #1: turn it off and on again
and Tech Support Action #2:
Do Action #1 again

and we're back to fixing the file times

well, fuck.
it didn't change the creation times.

apparently it doesn't check creation times.

ok! we have an armle target for qnx 6.3.2.
Let's grab a binary out of /usr/bin and see if it runs on the remote...

although I have no network and no virtualbox extensions... how do I get files off the VM?

floppy disks, of course. Virtual ones, but that's still floppy disks!

nooooo illegal instructions!

so they're both armle-qnx 6.3.2, so I bet the ones for the harmony remote had to be compiled with special options, because the armle target binaries are for a newer arm/different ARM than the remote uses.

lemme see if I can use the IDE and reconfigure it to compile a slightly different sort of ARM

yeah, my hello world code errors out too.

or I could try installing the Board Support Package for the Freescale i.MX21. This may just give me the right binaries I need.

setting up the BSP didn't really help, so I'm looking into compiler options again.
It's using... GCC 2.95.3? good lord. fortunately that's the oldest one they have on the GCC docs page...

ok, so, back to the hardware thread: the CPU is specifically a ARM926EJ-S.
So I need to make sure GCC is targeting that.

That should be compatible with arm9tdmi, but nope, I'm getting a Memory Fault when I try to run it.
maybe it's using the wrong ABI?

so it turns out it doesn't just have GCC 2.95.3, it also has GCC 3.3.5, it just defaults to 2.95.3

I don't know why.
ANYWAY, let's see if gcc 3.3.5 can give us better control over what is being generated

compiling for arm920 gives me illegal instructions.

same for arm920t

OK SO helloworld6 (which does nothing but return with exit status 7) errors out at ip=00100418.
Let's load it into Ghidra and see what 00100418 is .

so it turns out it's cpy... the first command of _start.

uh oh. That can't be good.

so if we go over to a command that definitely works, like the "hao" binary off the remote, we'll see that it starts with... cpy.
encoded in exactly the same way.

THE FUCK!?

so all I can guess then is that the binary isn't getting loaded properly: the first command of _start isn't actually THERE, it's something else or gibberish.

my kingdom for gdb!

although I was assuming I don't have gdb, someone in a private message pointed out that QNX doesn't have a native gdb interface, instead it uses "qconn" to present a remote interface for a GDB running on another system

Naturally this remote wouldn't ship with qconn, though, that'd just be silly...

OH MY GOD IT DOES

now I just gotta figure out how to get my VM to talk to the remote.

well it's talking to the remote, but failing to load some kind of file. I suspect this is a path issue, since it seems to be using cygwin... I bet it's trying to give it a full path (starting with C:\\) and cygwin doesn't like it

$well it's talking to the remote, but failing to load some kind of file. I suspect this is a path issue, since it seems to be using cygwin... I bet it's trying to give it a full path (starting with C:\\) and cygwin doesn't like it$

yeah, it's confirming it connected properly.

wait, what the shit?
it's working! I'm debugging it!

and if I run the debugged executable from the command line... it still works.

... did I just have to compile for debug? is that all this was? release mode doesn't work?

ok, no, it's not that simple.
Because if I compile the program for debug, I end up with a
14,597 byte Hello World program that doesn't work, it throws a memory fault.

but if I run the remote-debug option, it copies over a 14,611 byte binary THAT DOES.

this is the download page.
Something about this way of downloading a binary causes it to be a slightly different file that works

It's not even the debugger.
I can just go "run on target" and it'll work.

huh.

OH MY GOD YOU ARE SHITTING ME

Correct:

Incorrect:

My fucking FTP client wasn't detecting these as binary files for some ungodly reason (IT'S SUPPOSED TO!) and was transferring them in text mode, so it was converting them to and from unix line endings

ugh which means all those precompiled programs I was trying to run way back when?
they probably DO work, just my fucking FTP client was corrupting them

yep.

the moral of the story is that life is a lot easier when you're not a big fucking idiot

ok, so, what next?

obviously everyone wants doom, but I'm not sure this thing is even running photon, the QNX windowing system. it might be doing raw framebuffer stuff

which'd mean the existing QNX-DOOM port wouldn't work.

so we'd have to write a new one, one that targets the framebuffer.

that can be done. Time to investigate and see how we can draw to the screen.

so if we go look in /etc/system/config, we can see there's a bunch of config files, for keymaps and "GF"s, and display.conf.
display.conf lists links to all these conf files...

which look like this.
All these displays seem to be 320x240, or 240x320.

Great for doom, actually, since it's native resolution is 320x200.

But which one of these configurations are we using?

The cradle for this device said it's vodka. So hopefully that's right, and we can narrow it down to vodka, but there's two vodkas:
gf_vodka_innoxlux.conf
gf_vodka_wintek.conf

well, when I saw the back of the LCD, it said this:

and "WD-F2432 LCD" gets some hits, for Wintek.

So we've got a wintek display!

lots of info in here.
Although the interesting part is the vbase and vsize... that sounds like this thing is just memory-mapped.

vbase of 0xC3C00000 makes since, that's in the upper 1gb of memory space (and this thing only has 32mb? 64mb?)
and vsize is 0x96000... does that make sense?

well, the resolution is 320x240, or 76,800 pixels.
0x96000 is 614400, or exactly 8 times that.

8 bytes per pixel doesn't make a lot of sense, though.
Maybe it's incompletely decoded, or it has multiple pages, or something similar?

this stuff also says it's used to configure how the IMX21 talks to the display... maybe we don't need to talk to the display, maybe we need to talk to the IMX21.

time to find a datasheet

also while I've got this thing working, I should figure out how to image the flash chip (while running from it)

I did a manual FTP backup of all the files earlier, but that just includes the filesystem, and kinda misses out on some parts

plus it's corrupt

also, shout out to that conf file for having "Reverse Verdtical Scan"

it's also not monochrome.
it's momochrome

I just noticed there's a libasound .so.2 in /usr/flashlite/lib so possibly it does have some actual sound support?

with good ol' ALSA!

there's also the io-audio tool/driver.
which seems to be way too complicated to just be a beeper

ahh, ok: it's not running photon, but it is running io-display, which is the QNX Graphics Framework server.
So if I want to draw things on screen, I can use the libgf library, or opengl es.

and now I've crashed the network stack.
wooo!

I also gotta figure out how to control whether the LCD is on or off, because apparently that's not automatic. it's handled from INSIDE the main flash file... although knowing this stupid thing, it's probably activated by making an HTTP request to some http endpoint

and I killed the network stack AGAIN

DAMN IT LOGITECH YOU HAVE A MEMORY LEAK IN YOUR FTP SERVER.

ON THE REMOTE

SHUT UP

huh. so my QNX 6.3.2 SDK doesn't seem to have the headers for using libgf.

that's weird. I'm pretty sure it was used then... but maybe I'm misreading fragmentary docs and there isn't any libgf for QNX 6.3.2?

basically what I'm saying is
tfw no gf.h

wait, no, libgf .so is on the fucking remote! so it definitely does use libgf.

SO WHERE ARE THE HEADERS

oh sweet banana flavored jesus, you have to buy a separate license to use libgf, which is discontinued and not supported anymore

because I need the "Advanced Graphics TDK" to be allowed to DRAW TO THE FUCKING SCREEN

ok so what if I cheat a bunch.

I have the dynamic library, the .so: with that, I can probably generate the matching .lib

but what about the headers? well... I can get some of that by cheating in a different way, the docs:

alternatively, I could kill the Graphics Framework service and write to the LCD myself. might be easier *shrug*

so your remote is in power saving mode, and you push a key. how does it wake up?

WELL SOME LUA CODE MAKES HTTP REQUESTS TO THE WEBSERVER, TO START...

the nice thing about this design is that if you want to find out if your remote is muted, you can just plug in the USB cable and wget the settings API

because obviously when you push a button it should have to make an HTTP request and then parse some XML to know if it should beep

NO WONDER THIS FUCKER NEEDS A 233MHZ CPU

there's also some sort of other messaging system going on, handled by sys_srv
it seems to be listening for some kind of message, and then responding to them by turning them into lua calls which turns them into HTTP requests

because god forbid we be consistently overdesigned, no, it makes more sense to have several of them all working differently

seems it involves sending UDP packets to port 1600, which get turned into lua through shared memory, and then HTTP

so if I want to find out how you encode a packet to tell it to turn the backlight on, I could reverse engineer this binary and these three libraries...

or I could just kill the sys_srv process and then run my own program listening on port 1600 that dumps what messages it gets.

someone's probably compiled netcat for qnx, right?

I'm pretty sure (from looking at the Lua stuff) that the answer is "it sends XML packets around", though.

hey look my remote has netcat now

gotta love "for some reason" showing up in a comment

OK, I've got control over the backlight/LCD-on now.
I basically took the SysService.lua file and hacked out a lot of the functionality until it just turns the lights on, or off.

And ten minutes later, the screen is still on.
Interesting. Apparently my way of doing a FUCK YOU, FORCE ON disables the auto-sleep timer.

And this is what you get if you kill io-display! WHITENESS!

and my control-the-display scripts still work when io-display is dead. that's good.

I just need to figure out how to control the display manually, which should be... easy...

Latest Threads Unrolled: