Re: The N9/N950 Kernel Upstreaming Force
 

wicket, how did you know that it was switch_root and why did the config option fix it?

filip.pz: what about disabling watchdog altogether? In the N900 world one did it with a flasher.

Re: The N9/N950 Kernel Upstreaming Force
 

The kernel log displayed the usage of BusyBox's switch_root command. Command usage is often displayed when a command is executed with invalid arguments.

The "losetup: /dev/loop0: No such file or directory" error suggested that CONFIG_BLK_DEV_LOOP might not be enabled/loaded (see the help text for this config option for a description of what it does). It turned out that this wasn't the problem as Filip already had this enabled. He fixed it by enabling DMA.

Re: The N9/N950 Kernel Upstreaming Force
 

Just an update on progress so far (or lack of it).

I've ported hack from 3.5.3 that deals with broken watchdogs, but it hasn't made any difference. To be sure that watchdogs are not to blame, I've used flasher to disable them (good idea marmistrz):
but that didn't help.
Also wehen 3.5.3 gets compiled with: I also get warnings about watchdogs (thanks nieldk), twice about two independent watchdogs:Funny thing is that in 4.3.0-rc2: I get two warnings of single watchdog:I'll rechek if kernel knows about both watchdogs (omap_wdt and twl4030_wdt), and why I get warning for just one of them as opposed to 3.5.3 where both warn about Unexpected close

If nothing helps I'll try to disable systemd services that can't work at this stage, but can make problems (loading kernel modules, starting SGX driver) - still I would expect to see somthing in console, if that's the case

Re: The N9/N950 Kernel Upstreaming Force
 

I don't have any computer access right now, but I'll try the same with Debian when I have it. This way we'll make sure it's not Nemo-related.

Re: The N9/N950 Kernel Upstreaming Force
 

That would be awesome!
I just tried disabling the wd hack in 3.5.3, and it boots, so event without that hack boot shouldn't fail (If I got it right that hack is just for suspend state when watchdogs can't be disabled, but userspace is suspended and doesn't kick them from time to time)

Re: The N9/N950 Kernel Upstreaming Force
 

Filip, did you put up your sources of the 4.x kernel on GH? If no, the please just list all changes from mainline 4.x / the old config

Re: The N9/N950 Kernel Upstreaming Force
 

Nothing public yet. I'll send you and e-mail containing two patches (one for building, and one with wd hack) in a few minutes.

Re: The N9/N950 Kernel Upstreaming Force
 

OK, new theory:

In 3.5.3 watchdogs were miscdevices and accessible trough filesystem. When filesystem got re/u/mounted drivers were getting release file operation called, and kicked the watchdogs, just before init - leaving enough time for userspace to take over.

Now watchdog drivers are in their own kernel class, and only first registered watchdog is linked to /dev/watchdog miscdevice for legacy reasons. So, in our case with 2 watchdogs, only omap_wdt gets kicked and twl4030_wdt doesn't. That doesn't leave enough time for userspace to start DSME that does the kicking in Mer based distros.

Maybe krenel should kick all watchdogs one last time before calling init. I'll test that tomorrow.

Re: The N9/N950 Kernel Upstreaming Force
 

I got Nemo to boot (kinda: http://pastie.org/10440946). Since OBS for Nemo is in a poor state, a lot of packages are not being updated to current versions so I added Jolla repo to update them. This prevents N9 from shutting down during the boot process (DSME gets loaded earlier preventing watchdogs to kick in).

Obviously, graphics are broken and that also prevents MCE from running (even if MCE complains about "config subsystem".) For now I'll try to build new SailfishOS image and continue developing on it, but I imagine that Debian would also be able to boot (probably to nothing usable, but still...)

Re: The N9/N950 Kernel Upstreaming Force
 

With respect to Debian, I have started to package some of the core components from Nemo (dsme, mce-dev. mce, statefs) as part of my Gtk3 work. There not definately not perfect yet and untested on arm as I've been running in a x86_64 container.

dsme I know needs some manual editing after installation as the packaged systemd service file is looking in the wrong place (ie /usr/lib instead of /usr/lib/x86_64-linux-gnu).

Need to change container at the moment as statefs requires fuse (fine with qemu but aiming to get working via lxc) and to work out why mce is playing up (fails to start, causes boot to be delayed by 3min then starts fine)

If they are of any use to anyone, there on my github page...once I remember to upload a wip oneshot package (nemo one is full of bashisms I need to learn to fix).