Raspberry-QNX
Raspberry-QNX copied to clipboard
varghes
Kernel Up & fully functioning?
I'm having trouble using interrupts, I've ported the QNX SD card driver source over to the Pi (and it works) but the only interrupt that seems to fire is #33 (video). I've attached to that because it reliably (and unfortunately often) calls the handler where I check the SDHOST device registers for what I need. It never fires int #56 which is what I should be using to be optimal.
I notice that even the included devc-serdebug driver (although it attaches to int #57) never gets a int signal either.
Also, that serial port driver stops working (accepting input) when I run the SD card driver. I'm not sure why, the SD driver source works on my other (non-Pi) QNX system. I just don't start it and instead use the default/boot connection (ksh complains that /dev/tty isn't there and there won't be full job control) but I can at least still enter commands and get output, even though it's a bit funky.
I guess my question is, is the kernel really fully functioning?
More debugging shows the kernel is in fact enabling the int controller bits correctly (0x2000B200). Further still, setting BUSY_CMD_SET on SD commands makes the controller raise the interrupt correctly too, so almost everything is working now...
devc-serdebug still stops accepting data from my terminal, but only after I perform a directory listing of the newly mounted SD card (which is weird, because it's already done quite a lot of SD card commands, including reading a few sectors - just not as many as it does reading the root folder).
Thanks for making this available.
Hmmm, if I start the devc device before the SD driver, it locks up right away.
I must have assumed you connected to int #57 but I can see in the config (startup script) that it's being set to #1 (a timer).
I don't think this is compatible with libcam.so... Probably a lot of things, actually.
Ha! I did see it attach to # 57, it's hard-coded deep in the code.
What's happening (for future readers)... devc-serdebug attaches to int 57, this initially works well. The SD driver then attaches to int 56 which also works, but for some reason masks 57 preventing any more serial input (this is not code in the SD driver source, maybe it's a bug in procnto or maybe libcam.so, who knows).
I now know this is what's happening, because I also wrote a standalone program that sleeps for 30 seconds, wakes, calls InterruptMask(57,-1); and InteruptUnmask(57,-1); and loops to sleep again... After 30 seconds once booted, the serial port becomes active again suddenly processing the input in the fifo, but the next time I go to access the SD card it doesn't work because its int 56 is now masked so SD command completion is never processed.
For a bit of fun, I modified the serial driver to connect to int 33 (the one that goes off by itself at a rapid pace) and it worked very well too until... I started the SD driver, and the video int also stopped firing (masked) and I'm sure the SD driver source isn't doing blanket mask calls over the full range of interrupts! So it seems this kernel might have significant issues.
Oh well.
LOL - I modified both programs to attach to int # 33 - both devices are now working "properly". SD card is much slower than it was on the correct interrupt.
A real one int wonder! :)
Reopening the issue, because this isn't hard to fix...
Assembly source file: callout_interrupt_bcm2835.S needs to be changed (although I just hexedited startup-bcm2835 to avoid having to reassemble and relink)...
Wherever #IRQC_DISAB..1/2 or #IRQC_ENAB..1/2 are used, it loads the value into R1 or R3 updates it and writes it back. This is wrong and ends up masking more than is desired. I fixed it by setting R1 or R3 to #0 so only one bit is ever "on" when writing back to the enable/disable irq register.
SD card is fast now, serial input keeps working as it should.
Got the USB mouse and keyboard driver working... Had to alter the graphics driver too, I'm using adobe/macromedia flash-gf (from an old logitech remote-control firmware download) to make the graphics driver not report success on every (and all) surface requests - only the first one - which makes the GLES gears look better too (if it thinks it has a couple of frame buffers, it tries to use them and it looks messy, but a NULL will make it use software buffers and it works better). Have had to fix a crash when a surface is freed too, gfi seems to have a bug in there somewhere...
No wonder my (Ford 2011 car's) QNX system didn't implement the "gfi_" stuff. flash-gf also doesn't translate the full keyboard key-set, they missed a bunch of keys - not so important I guess...
LOL - this stuff is soo cool, and yet so amateurish... No wonder Ford went to Microsoft and then back again to QNX... When WinCE had just as many issues...... FYI - I'm not releasing any of this until the kernel's interrupt stuff is working properly here.
Ah, nasty, interrupts have been set to max 64 - and I need #66 to implement the sound driver...
I give up.
Each function here has exactly the same number of instructions as the original, but they are now "complete" (and while hex-editing these in, you need to change the hard-coded 64 to 72 in the init_intrinfo function)...
CALLOUT_START(interrupt_id_bcm2835_aic, 0, interrupt_patch_aic)
mov ip, #0x000000ff
orr ip, ip, #0x0000ff00
orr ip, ip, #0x00ff0000
orr ip, ip, #0xff000000
ldr r1, [ip, #IRQC_BASICPEND_OFF]
mov r2, #1
mov r3, #IRQC_DISABBASIC_OFF
mov r4, #8
mov r5, #72
3: subs r5, r5, #1
blt 0f
2: subs r4, r4, #1
blt 1f
tst r1, r2, lsl r4
beq 3b
mov r1, r2, lsl r4
str r1, [ip, r3]
b 0f
1: subs r3, r3, #4
mov r4, #32
cmp r5, #63
ldreq r1, [ip, #IRQC_IRQPEND2_OFF]
ldrne r1, [ip, #IRQC_IRQPEND1_OFF]
b 2b
mov r5, r5
0: mov r4, r5
CALLOUT_END(interrupt_id_bcm2835_aic)
CALLOUT_START(interrupt_eoi_bcm2835_aic, 0, interrupt_patch_aic)
mov ip, #0x000000ff
orr ip, ip, #0x0000ff00
orr ip, ip, #0x00ff0000
orr ip, ip, #0xff000000
teq r7, #0
bne 0f
mov r2, #1
mov r3, #IRQC_ENABIRQ1_OFF
cmp r4, #31
addgt r3, r3, #4
cmp r4, #31
subgt r4, r4, #32
cmp r4, #31
addgt r3, r3, #4
cmp r4, #31
subgt r4, r4, #32
mov r1, r2, lsl r4
str r1, [ip, r3]
0:
CALLOUT_END(interrupt_eoi_bcm2835_aic)
CALLOUT_START(interrupt_mask_bcm2835_aic, 0, interrupt_patch_aic)
mov ip, #0x000000ff
orr ip, ip, #0x0000ff00
orr ip, ip, #0x00ff0000
orr ip, ip, #0xff000000
mov r2, #1
mov r3, #IRQC_DISABIRQ1_OFF
cmp r1, #31
addgt r3, r3, #4
cmp r1, #31
subgt r1, r1, #32
cmp r1, #31
addgt r3, r3, #4
cmp r1, #31
subgt r1, r1, #32
mov r0, r2, lsl r1
str r0, [ip, r3]
mov r0, #0
mov pc, lr
CALLOUT_END(interrupt_mask_bcm2835_aic)
CALLOUT_START(interrupt_unmask_bcm2835_aic, 0, interrupt_patch_aic)
mov ip, #0x000000ff
orr ip, ip, #0x0000ff00
orr ip, ip, #0x00ff0000
orr ip, ip, #0xff000000
mov r2, #1
mov r3, #IRQC_ENABIRQ1_OFF
cmp r1, #31
addgt r3, r3, #4
cmp r1, #31
subgt r1, r1, #32
cmp r1, #31
addgt r3, r3, #4
cmp r1, #31
subgt r1, r1, #32
mov r0, r2, lsl r1
str r0, [ip, r3]
mov r0, #0
mov pc, lr
CALLOUT_END(interrupt_unmask_bcm2835_aic)