Re: The N9/N950 Kernel Upstreaming Force
 

I would like to help, but I'm currently stuck - correct way of compilation is not clear.

I can compile mer-n9-2.6.32-latest-nokia-pr1.3 with Open Mode patch.
- but do I have correct xxx_defconfig is unknown

Is there something secret thing to be done, because I try new kernel with ubiboot (easier would be just flash new version)
- my version shut down without any evidence what went wrong

Janne

Re: The N9/N950 Kernel Upstreaming Force
 

I can send you defconfig and build scripts I used (PM me your e-mail for that), but at this point without working serial console you'll not be able to do much as there is no display/sound/led...
You might wait a few days for me to port pvr kernel modules from 3.5.3 and get the display running (hopefully)

Re: The N9/N950 Kernel Upstreaming Force
 

Progress update:

Yesterday I managed to update PVR kernel drivers to "something" that compiles with current kernel by removing the following:

• /proc entries as the code is not updated to use seq_file required in kernel >= 3.10
• notification between OMAP DSS display driver and PVR (this is not implemented in OMAP DSS)
• power management features (they are not implemented in kernel: https://github.com/torvalds/linux/bl...omap-pm-noop.c)

However, to even try getting the display to work we still need the following:

• implement support for pyrenees (N9) and himalaya (N950) OMAP DSS displays
• add DT OMAP DSS parts necessary to omap-n9.dts and omap-n950.dts

In 3.5.3 that stuff was in the following files (list may not be complete):

• https://github.com/filippz/kernel-ad...el-nokia-dsi.c (taal, himalaya and pyrenees)
• https://github.com/filippz/kernel-ad...lays/ctrl-gf.c (mentions himalaya specific hacks)
• https://github.com/filippz/kernel-ad.../board-rm680.c

:) Good news: display driver might be ready in https://github.com/torvalds/linux/bl...panel-dsi-cm.c (taal is mentioned there, probably needs tweaking for himalaya and pyrenees). Seems that there were plans for adding other display types into it, but were abandoned: https://github.com/torvalds/linux/co...096b825326d3e2

:( Bad news: I really don't know enough about this to be able to port these parts myself :o Any volunteers :confused:

Re: The N9/N950 Kernel Upstreaming Force
 

For people using Ubuntu 14.04 or its derivatives: you need gcc < 4.8 or >= 4.8.3.

I'm building the 4.9 compiler from Wily and see what happens next.

/edit: I'm lazy and I'll be using the toolchain from the ppa. https://launchpad.net/~terry.guo/+ar...c-arm-embedded

Re: The N9/N950 Kernel Upstreaming Force
 

Will this script make sense for N950? (I care only about booting right now) Or should I add/remove something: https://github.com/marmistrz/debian9...debian_n950.sh

Yes, the repo is messy, but I'll try to do something for multi-device when we have it working on n950/n9.

Re: The N9/N950 Kernel Upstreaming Force
 

OK, I'm even more confused than before (I didn't think if that was even possible)

I was trying to write dts part by looking at the board file, schematics and other similar boards. According to schematics (known to be faulty) and board file from 3.5 I've noticed that display is powered from vmmc2 and from vio (both from twl5031). So I connected vdd-supply of dsi to vmmc2 (https://www.kernel.org/doc/Documenta...,omap3-dss.txt) but there is nowhere to connect vio. By looking in 3.5 I noticed that the user of that supply is ctrl-gf.c, which is driver for TC358710XBG (MIPI® DISPLAY HUB/BRIDGE). Cool, another thing to port I'm thinking :(

But... strangest thing: that driver is not being used in 3.5 (#CONFIG_CTRL_GF is not set), but is being used in 2.6 (CONFIG_CTRL_GF=y) :eek:

My best guess: at some point one of development versions of our devices was in need of multiple DSI outputs (OMAP3 has only one) and that chip was chosen to provide them (for multiple displays or what :confused:) Seems that driver and CONFIG_CTRL_GF=y where left together with supply entries in board file by mistake.

If anyone has another explanation I'd like to hear it, but for now I'm assuming that second power supply (vio) is to be ignored.

Re: The N9/N950 Kernel Upstreaming Force
 

Filip,

I have absolutely no idea about this. Maybe pali will know something.

Re: The N9/N950 Kernel Upstreaming Force
 

ok, I tried the script as uploaded in #45, something weird happens:

I'll setup ubiboot later on.

Re: The N9/N950 Kernel Upstreaming Force
 

In DebiaN900, the installation of System V init and removal of systemd is intentional. You can clear the $INIT variable in debian.conf if you want to keep systemd.

The reason is says "Installation failed" is because you removed this line so the script automatically calls the clean_up() function when it exits.

If you want to learn more about the trap shell built-in utility and how it works, you can find the POSIX definition here.

Re: The N9/N950 Kernel Upstreaming Force
 

I've tried setting up ubiboot, I get something like (I'll have access to the device tomorrow and may paste the exact message then)

"Booting the kernel failed. Please run maintenance boot"

Is there any way to find out what has failed, without setting up an external serial console? No such file or directory? Unable to mount?

Re: The N9/N950 Kernel Upstreaming Force
 

Check MyDocs/ubiboot (or where you put your config) for logs.

To me it seems your kernel was not found at all, so wrong config?
(as when second kernel was loaded and execution handed over there should be no such message)

Re: The N9/N950 Kernel Upstreaming Force
 

Believe it or not... this is actually good:
https://www.dropbox.com/s/fww96kfiaa..._2240.JPG?dl=0

Took me huge amount of time to get OMAP DSS to even talk to display panel, as it seems that DSS kernel drivers aren't doing a good job when bootloader (MOSLO, ubiboot...) configures DSS before boot.

A few things remain to be done:

• reset other parts of DSS subsytem (now I'm just resseting DSI) and that might prevent trouble with TE (Tear Elimination) IRQ
• add support for multiple displays in panel-dsi-cm.c (for now I've just replaced taal specific parts with pyrenees ones)
• entries in Harmattan kernel suggest that certain pyrenees panels don't handle properly reading from it's registers in HS (High Speed) mode - drop to LP (Low Power) mode before reading, and revert to HS after to be safe
• add support for N950 himalaya panel

As mentioned earlier, log now show IRQ problem (http://pastie.org/10460434) which seem to be related to TE IRQ, and hopefully resetting whole DSS before configuring it will fix this.
Also, I wasn't able to match LP clock speed to the one in older kernels which may be of some importance. Current DSS drivers configure necessary dividers for specified clocks themselves as opposed to old ones where dividers were set trough manual configuration (and older DSI drivers were rigged to optionally use alternate clock source making it easier to match desired speeds). Since I don't have any datasheet of N9/N950 displays (they seem to be manufactured by Samsung Display and AU Optronics respectfully) I can't really tell what clock speeds are really supported.

Re: The N9/N950 Kernel Upstreaming Force
 

We have working framebuffer now:
https://www.dropbox.com/s/3hfp0rjf0m..._6403.JPG?dl=0

I couldn't get rid of omapdss DSI error: Framedone not received for 250ms! when declaring screen to be 480x864. I had to swap x and y resolutions, and apply rotation by 90° (on the panel itself). Also, visible area is 480x854 not 480x864, so that was also added to panel driver. Swapping x and y can be eventually corrected trough framebuffer rotation (/sys/devices/platform/omapdss/display0/rotate) and by using fbset (this is what we use on SFOS, but Nemo has a hidden ace in his sleeve: https://github.com/nemomobile-ux/gla...c/main.cpp#L41) If necessary we could use ubiboot boot args to set these, hiding this stuff form userspace altogether.

By looking at the code in 2.6 kernel, there are a lot of hacks depending on panel revision/manufacturer (pyrenees is manufactured by either Samsung Mobile Display or LG Display). Since my panel revision (fe.91.96) seem to be unaffected by most (all?) of them, adding those bits will be done at a later time since I can't really test if they make any difference. It's possible that those panels didn't make it into the wild (or at least some of them), so we might actually be OK. If someone has different rev then mine, please post so (dmesg | grep -i pyrenees)

Next in line are PowerVR drivers and touchscreen...

Re: The N9/N950 Kernel Upstreaming Force
 

Mine is "" ;)
do not get anything on HW rev1601

Re: The N9/N950 Kernel Upstreaming Force
 

Just tried it on my N9:
You can try grepping for panel-nokia-dsi (gives us revision) to be safe. atmel_mxt informs about manufacturer (SMD above).

You can try rebooting before those commands (I'm unsure if kernel log overflows in time...)

Re: The N9/N950 Kernel Upstreaming Force
 

Yep, it does:

Re: The N9/N950 Kernel Upstreaming Force
 

White 64GB
Pyrenees panel revision c1.8b.96
RM-696-Pyrenees_LGD_V1_1.bin

Re: The N9/N950 Kernel Upstreaming Force
 

Ah the infamous 1601 raises its head again! :D

Re: The N9/N950 Kernel Upstreaming Force
 

hardware revision 1501 (black 64GB)

Re: The N9/N950 Kernel Upstreaming Force
 

On N950

Re: The N9/N950 Kernel Upstreaming Force
 

So,

finally found enough time to sit back and try booting the upstream kernel with DebiaN900 on N950.

This is the ubiboot.log (or rather its tail)

And my ubiboot.conf
http://paste.ubuntu.com/12792793/

Notice one thing: although I specify partition 4 in ubiboot.conf (Debian is on /dev/mmcblk0p4), the log states

which is the Harmattan rootfs.

Still, I have absolutely no idea why it happens. Or maybe it's the default command line? Do you have any ideas?

Re: The N9/N950 Kernel Upstreaming Force
 

Hi marmistrz,
yes 'ubiboot' is a big thing with some challenges.
As second kernel needs to be loaded from first kernel (with his root) from any location on any partition you need to specify the full partition path.
You gave full path inside your new rootfs only (/boot/kernel.name)
but you need to specify the partition also. And as juiceme (HUGE thanks to him, cannot stop to do so :)) created it like OS names instead partition numbers, you will have to specify
/boot/Debian/boot/kernel.name

Re: The N9/N950 Kernel Upstreaming Force
 

So the path should be in general:

shouldn't it?

Re: The N9/N950 Kernel Upstreaming Force
 

Yes, if you got the new kernel to load in the new partition under '/boot'.
(default ubiboot assumption)

You may have that kernel anywhere. On any partition on any place.
But that mount points '/boot/$(OSNAME)/' should make it easier for not so experienced people (and make it harder for people like you ;)).

Re: The N9/N950 Kernel Upstreaming Force
 

Working PVR drivers under 4.3.0-rc5:
https://www.dropbox.com/s/y6fnt79r6x..._2255.JPG?dl=0

I almost forgot how great glacier looks :o

As expected, some hacks are required: I had to change ubiboot parameters, and issue fbset in userspace, but the biggest obstacle seems problematic display panel drivers. I get warnings from kernel and "Framedone not received for 250ms!" after those warnings. I'll have to spend some more time to figure this one out...

Re: The N9/N950 Kernel Upstreaming Force
 

Hooray!
_______________

On the other hand, I've just managed to boot the stock kernel on Debian (sort of). I mean: the system starts up, shows a black screen and dies. But it's still progress anyway.

So without a possibility of logging without hardware hacks I won't be able to do anything further. But, Filip, is your PVR ready to show me the boot log?

Re: The N9/N950 Kernel Upstreaming Force
 

In my experience only thing that causes N9 to "die" is the twl5031 (drivers are called twl4030..., and it's not really twl5031 but seems to be some custom made part with ACI/ECI) It does so when twl4030-wdt watchdog doesn't get kicked for 30s (see here: http://talk.maemo.org/showpost.php?p=1485818&postcount=20). You can't use flasher to disable that, because ubiboot starts kicking both watchdogs (essentially starting them if flasher had set them not to be started automatically) - so something has to kick them until shutdown.

If your are running "the stock kernel" (2.6 I presume) then the kernel is not to blame here - as we know that kernel is working OK. I would suggest you try the mentioned watchdog "thing" which may be enough to get some logs saved.

If you're interested I can post details on how to make serial cable without opening/damaging the device (that small cardboard piece with two wires sticking out in pictures is just inserted instead of SIM tray). - that might save you a lot of trouble.

Here is Nemo booting 4.3.0-rc5 captured with it: http://pastebin.com/raw.php?i=mZkmscN9 - as you see it's quite "informative" :)

Re: The N9/N950 Kernel Upstreaming Force
 

There's one problem: the N950 doesn't have a SIM tray! One simply pushes the card inside the slot (and it's and ordinary SIM slot, just like the N900 one, not microSIM)

I'm not using 2.6. I'm using 4.3 from the start.

Re: The N9/N950 Kernel Upstreaming Force
 

Hm, I wonder if anyone knows where FBUS TX pin is on N950 (we need just that one, second is GND that can be found everywhere)? In any case on N950 dispaly panel is not the same as the one on N9 so I doubt that anything related to display would work with the patches I've made. I'll try to see if we can get USB to work and bring SSH into the game over USB. In the meantime you could try using 3.5 while we get 4.3 into shape.

Re: The N9/N950 Kernel Upstreaming Force
 

And what about redirecting dmesg to a file? I can freely access the filesystem after the boot fails. This may be easier to do. Of course SSH is a much better way out, but this would be a temporary measure

/edit: found this: http://unix.stackexchange.com/questi...ed-into-a-file

Re: The N9/N950 Kernel Upstreaming Force
 

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)

Re: The N9/N950 Kernel Upstreaming Force
 

Perhaps service manuals or schematics is of use here ?

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

Re: The N9/N950 Kernel Upstreaming Force
 

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):
http://cdn.slashgear.com/wp-content/...teardown_2.jpg

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.

Re: The N9/N950 Kernel Upstreaming Force
 

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

Re: The N9/N950 Kernel Upstreaming Force
 

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 ;)

Re: The N9/N950 Kernel Upstreaming Force
 

Ok, I'll try.

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

Re: The N9/N950 Kernel Upstreaming Force
 

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.

Re: The N9/N950 Kernel Upstreaming Force
 

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.

Re: The N9/N950 Kernel Upstreaming Force
 

There's the jig:
http://i.imgur.com/11kurRy.jpg

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.

Re: The N9/N950 Kernel Upstreaming Force
 

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.