This must be done from userspace. I'm not sure what debian uses for init system but Nemo is using systemd which does this by itself. You'll have /var/log/journal/randomname dir with logs which are not plain text, and you'll have to use journalctl --directory=/mountpount/var/log/journal/randomname to see them. But that happens rather late, so watchdogs are first to solve (and there is nothing in dmesg if they kick in - it's just like pulling the PSU plug)

Perhaps service manuals or schematics is of use here ?

http://www.cpkb.org/wiki/Nokia_N9-00_service_manual

marmistrz is using N950, and I see no obvious FBUS connector (maybe it's deeper under SIM shiled, similar to N9, but less accessible due to full size SIM card):


Anyway, we might be able to use USB to get SSH over it, but porting display driver w/o working serial console on N950 could be challenging at best.

Does it mean that the display driver works on N9 (pyrenees) but not on N950 (himalaya)?

Probably not. It needs same power supplies as does pyrenees, but DSI bus HS clocks are different N9 = 210.24 MHz (https://github.com/filippz/kernel-ad...-rm680.c#L1907) vs N950 = 256.32 MHz (https://github.com/filippz/kernel-ad...-rm680.c#L1953) - same goes for LP clocks. Other than that himalaya seems to be more like taal display (as pyrenees is OLED based) which is supported in mainline.

Still, I suggest working on 3.5 which is know to boot N950 with working display/touchscreen. When (if?) I get USB to work on mainline we'll be able to ssh into N9/N950 and use dmesg to see what's going on instead of serial cable. I suppose that's our best bet to make working display driver for N950.

I wonder if we could make use of ubiboot to load ubiboot again just on mainline kernel instead of some other OS (Nemo, SFOS, Debian) - as it just has what we need at this stage (watchdog kicking, display+touchscreen, usb networking + telnet/ssh). Other OS-es are quite "heavy" now and expect existance of WiFi, CMT, Audio, ALS/PS, BME.... Just an idea if someone would consider testing it

Ok, I'll try.

It's why I'm using Debian - it expects nothing unusual.

The test jig for the N950 has a DB-9 serial connector, and it attaches to that double row of 'dots' that in the picture are shown just above the SIM card slot.
Hopefully in the weekend I can try to trace which pins go where.

Cool
For reference (forgive me, if I'm stating the obvious): I'm using just GND (from SIM shield) and FBUS TX pin connected to CP2102 USB to TTL converter.
I would connect GND pin of CP2102 to SIM Shiled, and RX(D) pin to a "free wire", fire up minicom (set it to 115200bps) and try to find TX pin by connecting "free wire" to one of the pins and short pressing power button on N950 that is powered off. On the right pin you should get some garbage in minicom (due to wrong speed/parity...settings), if not move on to next one until you find one that does produce something on screen when short pressing power button.

Once you do, you can try to boot kernel with console output - ubiboot args are needed to tell kernel what tty to use and at what speed, for Nemo and 4.3 kernel I'm using: On N9 I'm using simple piece of cardboard with two wires (held in place by means of clear tape) pushed into SIM slot - didn't brake anything so I guess you're safe and can't destroy N950 by doing this procedure. I still hope that some similar contraption can be made for N950 (if TX is duplicated somewhere in SIM shield bay) and testing can be done without opening the device.

There's the jig:


The N950 sits locked on top, with the battery removed. The battery can be placed on the back of the jig or an external PSU can be used, see bottom left corner.
Normally the UART is connected to the computer with the RS232 terminal via a DB9-to-RJ50 cable (which contains a RS232 level adapter) to the 10pins UART connector to the left, but by using the switch on the top left corner, the DB9 on the jig can instead be selected.

The chip sitting behind the DB9 connector is a MAX3218, a common RS232 transceiver / level adapter.
So, if the DB9 connector is selected, there is electrical continuity:
- between pin10 of the max3218 (R2OUT) and the 2nd pin (counting from left) on the top row of pogopins. The corresponding R2IN signal goes to pin 2 of the DB9 (RXD)
- between pin 8 of the max3218 (T2IN) and the 1st pin on the left on the bottom row of pogopins. The corresponding T2OUT goes to pin 3 of the DB9 (TXD)
- 2nd pin from left on the bottom row offers a handy GND.
Didn't trace the other signals as after all TXD, RXD and GND are probably all what matters
Serial communications works at 115200 8N1, and under Harmattan the serial terminal is seen as ttyS0.

I'm working on touchscreen suport and I need help of a kind soul with N950 to do the following:

• download mxt-app to your N950 (more info at https://github.com/atmel-maxtouch/mxt-app)
• issue ln -s /lib/ld-linux.so.3 /lib/ld-linux-armhf.so.3
• as root run the following command:
  
  Code:

  ./mxt-app -d i2c-dev:2-004b --save RM-680_Himalaya_AUO_V1_1.xcfg

• paste generated RM-680_Himalaya_AUO_V1_1.xcfg file to pasetbin/pastie...

Atmel maXTouch driver in kernel can't be used as is so I'm hoping that the ones from https://github.com/atmel-maxtouch/linux will be OK. In any case xcfg files are needed by the driver but in Nokia kernels there was no xcfg files but standard header files generated from cfg files (https://github.com/nemomobile/kernel...smd_v1_6.cfg.h & https://github.com/filippz/kernel-ad...auo_v1_1.cfg.h). mxt-app can extract xcfg file from running device and with a little manual patching from header files we can get what we need.