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?