Well there is still a matter of adding a table on elinux.org
As for "real kernel development", I'm currently working on twl5031_bbc driver (replacement for twl4030_bci) which is needed in order for usb-moded from Mer to even start - bringing us closer to possibility of getting ssh over usb to work (at least on Mer/Nemo)
There's a lot of thing left to do (IIRC):
sensors for proximity, ambiental light, magnetometer, accelerometer
Audio parts
CMT (modem, migth be same or at least very similar to the one on N900, so we should reuse Palis work)
Bluetooth
BME support (battery charging) - we should check if BME used on N900 matches the on on N9/950, since the one from N900 has been reverse engineered. If it's not 100% compatible we should then fix that, which is still a better option than patching twl4030_madc in kernel so that old BME binary blob can talk to it
NFC support
GPS support (simple driver exists, but userspace must speak proprietary MEIF)
ECI/ACI - whatever is called (support for controls on wired earphones - undocumented in twl5031 IIRC)
TV out (depends on ECI/ACI for detection of cable connection)
FM radio
...
Also N950 specific stuff:
LCD panel support
touchscreen (completed/untested)
keyboard (completed/untested)
support for keyboard slide event (completed/untested)
LED support (N9 uses LP5521, N950 uses LP5523)
WLAN support (same wl1271 module as on N9, but connected in a different way)
If someone would be interested in CMT (my N9 has broken CMT chip and is not fully functional in that regard) and/or BME (mostly done in userspace, N900 guys can help us with that) that would be awesome.
Since I'm rebasing and rewriting history in git all the time (not good for collaboration) I'm not sure what would be the best way for others to contribute, so I'm open to suggestions in that regard.
Friendly reminder that a fully functional. Black. 64G (scandinavia) N9 is waiting a proper home.
Allthough. With this good progress i will probably regret LOL. (Just kidding. Ping me and its on its way)
Another progress update - no big ones this time, just to keep the thing going
I've completed twl5031 BCC driver and USB now detects if something is plugged in and device type (from charging point of view). This allows for usb-moded from Mer to start up, which in turn allows USB networking to be started so we can SSH into Nemo.
I've also completed Vibra support for N9. N950 uses different Vibration system - tied with twl5031/4030 audio system, so this will be done at that stage.
LED support is ready on N9 (lp5521 chip). Since N950 uses a bit different chip (lp5523), someone with N950 will have to do the work (shouldn't be too hard - probably just needs entries in DTS file). Small patch was required to MCE (already accepted), and lp5521 driver form mainline was also patched.
I also made an error of not including CONFIG_CPUFREQ_DT in kernel config which made N9 run @600 MHz (AFAIK), but even with it, system would run @800MHz only and some additional entries in DTS are needed to enable full 1GHz speed. With this change and by stopping pulseaudio service (restarts all the time due to no audio support at this time, consuming much of CPU time) N9 seems to be more responsive. Sadly I still get
Code:
pvr: lipstick: IOCTL 70 failed (13)
every time lipstick (or fingerterm, for example) uses GPU. If anybody has any idea how to prevent this now it would be a good time to speak out.
I'm currently going mad with apds990x driver (ALS/PS sensor) and I hope it well be ready soon. Unfortunately N950 doesn't use that chip, so no support for it at this time. In userspace some Mer packages need patching for it to work: boardname (patch pending acceptance) and sensorfw (patch not ready at this time)
Progress report will be available from time to time - as usual.
With 3.5.3 Debian refuses to boot (black screen). How to debug it?
I guess without working serial cable you are forced to be really creative (for example write some file at different "init point" and check for its existence after reboot)
Maybe minimos could spare some time and try to debug it for you?
To post #100. Well, I guess you should simply stop rebasing
Is there anything that you could give to danpio? Is there anything danpio wants?
Well, no one expressed desire to look at CMT or BME. I guess anything on that list is free for taking (apart form apds990x, and things reported working earlier)
With 3.5.3 Debian refuses to boot (black screen). How to debug it?
First, you can check ubiboot log file to see if it goes successfully until executing the kernel used by Debian. If ubiboot is happy, you should check Debian syslog logs to see if there are any logs about this boot attempt. If not, it usually means that either the kernel didn't boot successfully, or userspace has crashed very early, and this makes debugging much harder. If logs exist, you should check them to see what went wrong.
BTW, remember that in Debian, you should have started kicking watchdog files from early in the boot process (usually, both in its initrd/initramfs, and after continuing the boot process by some simple service.
Sadly only lis302 is the same on both N9 and N950 (positioned a bit differently). N950 uses bh1770glc/sfh7770 for ALS/PS (supported in kernel), but magnetometer ak8974 is tricky one (no support for it mainline).
In Mer/Nemo, ALS/PS and accelerometer work by adding appropriate config file to sensorfw package, but ak8975 needs additional coding (since driver in mainline is quite different than the old one). I have that code ready, but I'm unsure how to properly test it so I'll try to get some info about that during next week.
I'll move onto audio bits after sensorfw is done (since we have 3 audio chips this could be rather complicated).There are still important things left to be done (apart from missing bits for N950) like CMT and BME, so I hope someone might take a shot at those.
On the following link are current kernel patches: https://www.dropbox.com/s/ogx2nbzoxf...x.tar.bz2?dl=1 Consider them to be tentative (not final in any way, shape, form or fashion) and that file will simply be overwritten with fresh patches from time to time.
First, you can check ubiboot log file to see if it goes successfully until executing the kernel used by Debian. If ubiboot is happy, you should check Debian syslog logs to see if there are any logs about this boot attempt. If not, it usually means that either the kernel didn't boot successfully, or userspace has crashed very early, and this makes debugging much harder. If logs exist, you should check them to see what went wrong.
BTW, remember that in Debian, you should have started kicking watchdog files from early in the boot process (usually, both in its initrd/initramfs, and after continuing the boot process by some simple service.
Does the syslog remain after the unsuccessful boot?
How can I start kicking the watchdog? Can I disable it as we did with our N900s?
Does the syslog remain after the unsuccessful boot?
I doubt that syslog gets the chance to even start. Kicking watchdog should start immediately when control reaches Debian (the first thing to be executed by its init script).
Originally Posted by
How can I start kicking the watchdog? Can I disable it as we did with our N900s?
It depends on your init system. If using systemd, it should be the first service to be started. If using SysV init, you can put it on top of main init script to be started in the background.
Kicking watchdog can be achieved using a simple infinite while loop with an echo command to a special device file. I don't remember the device file now but others can help if you don't know it already. It is done in ubiboot too, or you can find it in Harmatten/Nemo/SFOS/Nitroid init scripts for N9.
