This repository has been archived by the owner. It is now read-only.

Add basic support for Nokia N9 #1046

Closed
wants to merge 5 commits into
base: master
from

Conversation

Projects
None yet
5 participants
@pavelmachek
Member

pavelmachek commented Dec 27, 2017

Filip Matijević did all the work here, I'm just attempting to merge it (with his permission).

N9 has pretty good mainline support, and it is being improved, so it is good target. OTOH it does not have a u-SD card slot, and battery is not removable, which makes it tricky. Currently, it is usable with root mounted over NFS over USB, including working xfce4.

filippz and others added some commits Nov 11, 2017

Add watchdog-kick package
Some devices (namely Nokia N9/950) use more than one watchdog, and
watchdog-kick package kicks all of /dev/watchdogs? every 10 seconds so
they don't reset the device
Merge branch 'master' into n9-3
Pull latest master; prepare for merge.
Fix kconfig_check warning.
./pmbootstrap.py kconfig_check
[11:57:47] WARNING: linux-nokia-n9/config-nokia-n9.armhf:
CONFIG_DEVTMPFS_MOUNT should *not* be set. See
<https://wiki.postmarketos.org/wiki/Kernel_configuration#CONFIG_DEVTMPFS_MOUNT>
for details.
[11:57:47] ERROR: kconfig_check failed!
@ollieparanoid

ollieparanoid suggested changes Dec 28, 2017 edited

@filippz and @pavelmachek: Big thanks you to both of you! I'm excited that postmarketOS works on another Nokia phone! \o/

@pavelmachek: do you also own a N9?

@filippz: I have seen your tweets, from what I understand you have demos working so far. Did you get a wayland compositor or X11 running, and if so, would you (or @pavelmachek) like to take a photo with something postmarketOS specific for the upcoming blog post?

It would be fantastic if one of you had time to update the N9 device page (device page howto).

Last but not least I would love to make the pmbootstrap flasher boot command execute the right 0xffff command automatically and that should be pretty easy, only the pmb/config/__init__.py needs to be adjusted I think. Maybe one of you could play with that and check if it works.

"$pkgdir"/etc/postmarketos-mkinitfs/hooks/00-${pkgname}.sh
#Atmel TS
install -D -m644 "$srcdir"/RM-696_Pyrenees_SMD_V1_6.raw \

This comment has been minimized.

@ollieparanoid

ollieparanoid Dec 28, 2017

Member

Could you package the firmware in its own package in the firmware folder (e.g firmware-atmel-ts, ideally with a more exact name of the screen)?

If it's proprietary, please don't ship it with the package (even if it is just a small file), but download it from somewhere on the web - just look at how it's done in the other firmware packages.

I'm just curious why the file gets renamed to maxtouch.cfg btw, has this any special meaning?

Finally we put postmarketOS firmware into /lib/firmware/postmarketos, so it never conflicts with the linux-firmware package from Alpine. Our firmware loading script looks in that path, too.

@ollieparanoid

ollieparanoid Dec 28, 2017

Member

Could you package the firmware in its own package in the firmware folder (e.g firmware-atmel-ts, ideally with a more exact name of the screen)?

If it's proprietary, please don't ship it with the package (even if it is just a small file), but download it from somewhere on the web - just look at how it's done in the other firmware packages.

I'm just curious why the file gets renamed to maxtouch.cfg btw, has this any special meaning?

Finally we put postmarketOS firmware into /lib/firmware/postmarketos, so it never conflicts with the linux-firmware package from Alpine. Our firmware loading script looks in that path, too.

This comment has been minimized.

@filippz

filippz Dec 29, 2017

Contributor

Well, this is a strange one. The "firmware" is in fact configuration file that can be dumped from running hw by using https://github.com/atmel-maxtouch/mxt-app, or simply c/p over from previous versions etc. The thing is that is simply has to be called maxtouch.cfg (kernel drivers can't be told the file name by using dts property or something like that) and since we expect using N950 that has the same TS controller but slightly different screen orientation that has to be matched by TS controller we also need a bit different (just 2 bytes) maxtouch.cfg for it but it must be named the same. I'm targeting for using the same kernel package for N950 by means of subpackages so the names in the package should be more meaningful that maxtouch.cfg (ie RM-696_Pyrenees_SMD_V1_6.raw)

@filippz

filippz Dec 29, 2017

Contributor

Well, this is a strange one. The "firmware" is in fact configuration file that can be dumped from running hw by using https://github.com/atmel-maxtouch/mxt-app, or simply c/p over from previous versions etc. The thing is that is simply has to be called maxtouch.cfg (kernel drivers can't be told the file name by using dts property or something like that) and since we expect using N950 that has the same TS controller but slightly different screen orientation that has to be matched by TS controller we also need a bit different (just 2 bytes) maxtouch.cfg for it but it must be named the same. I'm targeting for using the same kernel package for N950 by means of subpackages so the names in the package should be more meaningful that maxtouch.cfg (ie RM-696_Pyrenees_SMD_V1_6.raw)

This comment has been minimized.

@ollieparanoid

ollieparanoid Dec 29, 2017

Member

Would it make sense to rewrite the driver to get the config file from somewhere in /etc/ then?

I think you don't even need a subpackage - you could make one device-... package for the N9 and one for the N950, and let each one ship their own config file, but depend on the same kernel package.

@ollieparanoid

ollieparanoid Dec 29, 2017

Member

Would it make sense to rewrite the driver to get the config file from somewhere in /etc/ then?

I think you don't even need a subpackage - you could make one device-... package for the N9 and one for the N950, and let each one ship their own config file, but depend on the same kernel package.

This comment has been minimized.

@filippz

filippz Dec 29, 2017

Contributor

There was a discussion at LKML where Atmel guys were trying to push some changes but the whole thing stalled when maintainers requested to rewrite driver to use regmap - the discussion wasn't productive after that (keywords: proprietary, custom, NDA, ...) One idea in there was to use DT entry instead of special file - which would be great for our usercase, but I'm reluctant to bring this up on LKML once more :)

Actually, putting maxtouch.cfg in device- package seems to be a good idea. Maybe we can do that once we decide to introduce support for N950 (CC @pavelmachek)

@filippz

filippz Dec 29, 2017

Contributor

There was a discussion at LKML where Atmel guys were trying to push some changes but the whole thing stalled when maintainers requested to rewrite driver to use regmap - the discussion wasn't productive after that (keywords: proprietary, custom, NDA, ...) One idea in there was to use DT entry instead of special file - which would be great for our usercase, but I'm reluctant to bring this up on LKML once more :)

Actually, putting maxtouch.cfg in device- package seems to be a good idea. Maybe we can do that once we decide to introduce support for N950 (CC @pavelmachek)

deviceinfo_external_disk="false"
deviceinfo_external_disk_install="false"
deviceinfo_arch="armhf"

This comment has been minimized.

@ollieparanoid

ollieparanoid Dec 28, 2017

Member

How about adding deviceinfo_flash_method="0xffff" here?

@ollieparanoid

ollieparanoid Dec 28, 2017

Member

How about adding deviceinfo_flash_method="0xffff" here?

This comment has been minimized.

@filippz

filippz Dec 29, 2017

Contributor

I haven't used 0xffff (I'm using ubiboot via serial cable), so @pavelmachek might be the one to have more info. Currently, there is no easy way to "flash" N9/N950 with pmOS.

@filippz

filippz Dec 29, 2017

Contributor

I haven't used 0xffff (I'm using ubiboot via serial cable), so @pavelmachek might be the one to have more info. Currently, there is no easy way to "flash" N9/N950 with pmOS.

@@ -0,0 +1,19 @@
#!/bin/bash

This comment has been minimized.

@ollieparanoid

ollieparanoid Dec 28, 2017

Member

This script exists twice basically, once for the initfs-hook and once for the watchdog-kick package. I prefer the packaged version, because:

  • #!/bin/sh
  • doesn't check if sleep exists, and that check isn't necessary as busybox always provides it
  • tabs instead of spaces is in line with the rest of Alpine and postmarketOS shell scripts

I think kicking the watchdog is a feature that other devices might need as well, and I would also like to reduce the duplication. How about we add and run the watchdog-kick script to/in the initramfs, when a new deviceinfo_kick_watchdog option in the deviceinfo is set?

You could integrate it just like msm-fb-refresher is integrated to the initramfs (grep the aports/postmarketos-mkinitfs/ for msm).

(CC @Halamix2, your device had a watchdog problem, maybe such a script helps you as well.)

@ollieparanoid

ollieparanoid Dec 28, 2017

Member

This script exists twice basically, once for the initfs-hook and once for the watchdog-kick package. I prefer the packaged version, because:

  • #!/bin/sh
  • doesn't check if sleep exists, and that check isn't necessary as busybox always provides it
  • tabs instead of spaces is in line with the rest of Alpine and postmarketOS shell scripts

I think kicking the watchdog is a feature that other devices might need as well, and I would also like to reduce the duplication. How about we add and run the watchdog-kick script to/in the initramfs, when a new deviceinfo_kick_watchdog option in the deviceinfo is set?

You could integrate it just like msm-fb-refresher is integrated to the initramfs (grep the aports/postmarketos-mkinitfs/ for msm).

(CC @Halamix2, your device had a watchdog problem, maybe such a script helps you as well.)

This comment has been minimized.

@filippz

filippz Dec 29, 2017

Contributor

Ah... My N9 has damaged MTD so I get lots of ECC errors that slow the boot down. Once kernel starts using WD they need to be kicked every 30sec, but OpenRC from root partition doesn't get started early enough to be kicked from there (especially when first boot resizes FS and generates crypto keys), hence the solution to have a similar script in initramfs. IIRC checking for /bin/sleep was also needed - but I can't remember why... I've tried to make both scripts reusable on other devices so they might be a base for something better in the future.

As for #!/bin/sh vs #!/bin/bash- it's all the same to a Windows guy :) I probably had issues detecting existence of /bin/sleep or something stupid like that.

@filippz

filippz Dec 29, 2017

Contributor

Ah... My N9 has damaged MTD so I get lots of ECC errors that slow the boot down. Once kernel starts using WD they need to be kicked every 30sec, but OpenRC from root partition doesn't get started early enough to be kicked from there (especially when first boot resizes FS and generates crypto keys), hence the solution to have a similar script in initramfs. IIRC checking for /bin/sleep was also needed - but I can't remember why... I've tried to make both scripts reusable on other devices so they might be a base for something better in the future.

As for #!/bin/sh vs #!/bin/bash- it's all the same to a Windows guy :) I probably had issues detecting existence of /bin/sleep or something stupid like that.

@@ -0,0 +1,128 @@
# APKBUILD based on linux-vanilla aport. Changes:

This comment has been minimized.

@ollieparanoid

ollieparanoid Dec 28, 2017

Member

Ideally we would use linux-postmarketos-stable (which the N900 uses, or -mainline/-lts) instead, so we can use the same kernel package across multiple devices. Would it be feasible for you to change it in this PR or in a follow up PR?

When merging with a linux-postmarketos package, we could put the N9 specific patches in a subfolder in the aport (like it's done in our qt5-qtwebengine aport).

@ollieparanoid

ollieparanoid Dec 28, 2017

Member

Ideally we would use linux-postmarketos-stable (which the N900 uses, or -mainline/-lts) instead, so we can use the same kernel package across multiple devices. Would it be feasible for you to change it in this PR or in a follow up PR?

When merging with a linux-postmarketos package, we could put the N9 specific patches in a subfolder in the aport (like it's done in our qt5-qtwebengine aport).

This comment has been minimized.

@filippz

filippz Dec 29, 2017

Contributor

As @pavelmachek already commented - I'd leave it as it is for time being.

@filippz

filippz Dec 29, 2017

Contributor

As @pavelmachek already commented - I'd leave it as it is for time being.

0009-ARM-dts-N9-N950-Add-touchscreen-support.patch
0010-ARM-N9-N950-Add-PVR-drivers.patch
$_config
compiler-gcc6.h

This comment has been minimized.

@ollieparanoid

ollieparanoid Dec 28, 2017

Member

This should not be necessary with a 4.14 kernel

@ollieparanoid

ollieparanoid Dec 28, 2017

Member

This should not be necessary with a 4.14 kernel

This comment has been minimized.

@filippz

filippz Dec 29, 2017

Contributor

We can try without it - right @pavelmachek?

@filippz

filippz Dec 29, 2017

Contributor

We can try without it - right @pavelmachek?

package() {
cd "$srcdir/build/arch/arm/boot"
cat zImage dts/omap3-n9.dtb > zImage-dtb

This comment has been minimized.

@ollieparanoid

ollieparanoid Dec 28, 2017

Member

postmarketos-mkinitfs can also pick the dtb file as specified in the deviceinfo and attach it to the kernel. That would be necessary when using a linux-postmarketos-* package instead.

@ollieparanoid

ollieparanoid Dec 28, 2017

Member

postmarketos-mkinitfs can also pick the dtb file as specified in the deviceinfo and attach it to the kernel. That would be necessary when using a linux-postmarketos-* package instead.

This comment has been minimized.

@filippz

filippz Dec 29, 2017

Contributor

OK, we' can try without it (CC @pavelmachek)

@filippz

filippz Dec 29, 2017

Contributor

OK, we' can try without it (CC @pavelmachek)

This comment has been minimized.

@ollieparanoid

ollieparanoid Dec 29, 2017

Member

Seems like you guys are busy, so I would say since we're not merging the kernel together with linux-postmarketos-* yet, we can leave this one as it is for now.

@ollieparanoid

ollieparanoid Dec 29, 2017

Member

Seems like you guys are busy, so I would say since we're not merging the kernel together with linux-postmarketos-* yet, we can leave this one as it is for now.

watchdog-kick
"
build() {

This comment has been minimized.

@ollieparanoid

ollieparanoid Dec 28, 2017

Member

empty build() functions can be removed

@ollieparanoid

ollieparanoid Dec 28, 2017

Member

empty build() functions can be removed

This comment has been minimized.

@filippz

filippz Dec 29, 2017

Contributor

IIRC there was a warning w/o it - I'll retry and see.

@filippz

filippz Dec 29, 2017

Contributor

IIRC there was a warning w/o it - I'll retry and see.

echo X > $wd
fi
done
sleep 10s

This comment has been minimized.

@ollieparanoid

ollieparanoid Dec 28, 2017

Member

any reason why this version has 10s and the one from the initramfs has 2s?

@ollieparanoid

ollieparanoid Dec 28, 2017

Member

any reason why this version has 10s and the one from the initramfs has 2s?

This comment has been minimized.

@filippz

filippz Dec 29, 2017

Contributor

We need to be sure that the time between when initramfs script kicks them for the last time and the one that is started from root partition kicks them for the first time is no more that 30sec. If we have too high number in tere the time from last kick by initramfs script to the time root partition script is started could be longer, so the 2s seemed reasonable.

@filippz

filippz Dec 29, 2017

Contributor

We need to be sure that the time between when initramfs script kicks them for the last time and the one that is started from root partition kicks them for the first time is no more that 30sec. If we have too high number in tere the time from last kick by initramfs script to the time root partition script is started could be longer, so the 2s seemed reasonable.

pid=/run/watchdog-kick.pid
depend() {
after udev

This comment has been minimized.

@ollieparanoid

ollieparanoid Dec 28, 2017

Member

Shouldn't the watchdog be started as early as possible, without waiting for udev?

@ollieparanoid

ollieparanoid Dec 28, 2017

Member

Shouldn't the watchdog be started as early as possible, without waiting for udev?

This comment has been minimized.

@filippz

filippz Dec 29, 2017

Contributor

Yes, but we need /dev to be populated so if we start it too early and there is no /dev/watchdog? devices to kick and we retry after 10s - that might me just too long and the device dies.

@filippz

filippz Dec 29, 2017

Contributor

Yes, but we need /dev to be populated so if we start it too early and there is no /dev/watchdog? devices to kick and we retry after 10s - that might me just too long and the device dies.

@filippz

This comment has been minimized.

Show comment
Hide comment
@filippz

filippz Dec 28, 2017

Contributor

@ollieparanoid Thank you for review. GPU works for a handful of basic demos due to issues with glibc vs musl. There is X11 support in the GPU drivers but I haven't tried it yet - I'll try using https://github.com/nemomobile/ti-omap3-sgx-wayland-wsegl for wayland first and fall back to X11 if that fails. Currently I'm working on packaging both kernel modules and userspace libraries but it's a slow process. In any case we have working bootsplash and xfce4 using just fb so we can use either one for pictures.
As for the rest of the things you commented on I'll try to reply sometime tomorrow if time permits.

Contributor

filippz commented Dec 28, 2017

@ollieparanoid Thank you for review. GPU works for a handful of basic demos due to issues with glibc vs musl. There is X11 support in the GPU drivers but I haven't tried it yet - I'll try using https://github.com/nemomobile/ti-omap3-sgx-wayland-wsegl for wayland first and fall back to X11 if that fails. Currently I'm working on packaging both kernel modules and userspace libraries but it's a slow process. In any case we have working bootsplash and xfce4 using just fb so we can use either one for pictures.
As for the rest of the things you commented on I'll try to reply sometime tomorrow if time permits.

@ollieparanoid

This comment has been minimized.

Show comment
Hide comment
@ollieparanoid

ollieparanoid Dec 28, 2017

Member

Awesome, take your time! I think the goal of gcompat is to make all glibc applications work with musl (right @awilfox?), so they would probably be happy to receive bug reports if you have time for it at one point. Ideally the issues get ironed out quickly then.

And a photo with framebuffer sounds good. There are people who actually prefer free framebuffer vs. non-free accelerated drivers (but it's really cool that you somewhat got them working too!)

Member

ollieparanoid commented Dec 28, 2017

Awesome, take your time! I think the goal of gcompat is to make all glibc applications work with musl (right @awilfox?), so they would probably be happy to receive bug reports if you have time for it at one point. Ideally the issues get ironed out quickly then.

And a photo with framebuffer sounds good. There are people who actually prefer free framebuffer vs. non-free accelerated drivers (but it's really cool that you somewhat got them working too!)

@pavelmachek

This comment has been minimized.

Show comment
Hide comment
@pavelmachek

pavelmachek Dec 28, 2017

Member
Member

pavelmachek commented Dec 28, 2017

@pavelmachek

This comment has been minimized.

Show comment
Hide comment
@pavelmachek

pavelmachek Dec 29, 2017

Member
Member

pavelmachek commented Dec 29, 2017

@ollieparanoid

This comment has been minimized.

Show comment
Hide comment
@ollieparanoid

ollieparanoid Dec 29, 2017

Member

Thanks to both of you for answering the questions in such detail, and thanks for expanding the wiki page! In my opinion, only the following is left to do before we can ship it 🚢:

  • remove compiler-gcc6.h
  • shorten the initramfs watchdog-kick hook (we could also integrate watchdog-kick hook into the initramfs like msm-fb-refresher, but that doesn't seem to be beneficial enough at this point). This should do it (untested):
#!/bin/sh
watchdog_kick() {
	while true; do
		for wd in /dev/watchdog*; do
			[ -c $wd ] && echo X > $wd
		done
	done
	sleep 2s
}
watchdog_kick &

EDIT: Changes above (and a working hook, this one does not work) have been made by @filippz in his repository, which gives us the following TODOs:

  • integrate changes into this PR:
    • remove compiler-gcc6.h
    • updated watchdog-kick initramfs hook and OpenRC service

...and this one remains:

  • adjust the package and kernel name to use the codename. The wiki page states, that the codename is Lankku/rm-969, so we should use one of those for consistency (which one do you prefer? if a device has multiple code names, we just chose one). The N900 has device-nokia-rx51 as device package name.
Member

ollieparanoid commented Dec 29, 2017

Thanks to both of you for answering the questions in such detail, and thanks for expanding the wiki page! In my opinion, only the following is left to do before we can ship it 🚢:

  • remove compiler-gcc6.h
  • shorten the initramfs watchdog-kick hook (we could also integrate watchdog-kick hook into the initramfs like msm-fb-refresher, but that doesn't seem to be beneficial enough at this point). This should do it (untested):
#!/bin/sh
watchdog_kick() {
	while true; do
		for wd in /dev/watchdog*; do
			[ -c $wd ] && echo X > $wd
		done
	done
	sleep 2s
}
watchdog_kick &

EDIT: Changes above (and a working hook, this one does not work) have been made by @filippz in his repository, which gives us the following TODOs:

  • integrate changes into this PR:
    • remove compiler-gcc6.h
    • updated watchdog-kick initramfs hook and OpenRC service

...and this one remains:

  • adjust the package and kernel name to use the codename. The wiki page states, that the codename is Lankku/rm-969, so we should use one of those for consistency (which one do you prefer? if a device has multiple code names, we just chose one). The N900 has device-nokia-rx51 as device package name.
@filippz

This comment has been minimized.

Show comment
Hide comment
@filippz

filippz Dec 29, 2017

Contributor

My vote goes to rm-696 (N950 is rm-680) - these are mentioned in early kernels and device labels etc. I've managed to get SGX stuff packaged and I'm off to see if it boots, after that I'll retry with gcc6 removed and changed watchdog-kick hook. Thanks @ollieparanoid & @pavelmachek!

Contributor

filippz commented Dec 29, 2017

My vote goes to rm-696 (N950 is rm-680) - these are mentioned in early kernels and device labels etc. I've managed to get SGX stuff packaged and I'm off to see if it boots, after that I'll retry with gcc6 removed and changed watchdog-kick hook. Thanks @ollieparanoid & @pavelmachek!

@awilfox

This comment has been minimized.

Show comment
Hide comment
@awilfox

awilfox Dec 30, 2017

I'm not sure what gcompat has to do with anything after a cursory read of the comments here, but that is correct. It's a binary library and won't be any help compiling glibc software, but will help run binaries built against glibc. Bug reports or missing APIs go on the BTS and merge requests go on the official GitLab.

awilfox commented Dec 30, 2017

I'm not sure what gcompat has to do with anything after a cursory read of the comments here, but that is correct. It's a binary library and won't be any help compiling glibc software, but will help run binaries built against glibc. Bug reports or missing APIs go on the BTS and merge requests go on the official GitLab.

@pavelmachek

This comment has been minimized.

Show comment
Hide comment
@pavelmachek

pavelmachek Dec 30, 2017

Member
Member

pavelmachek commented Dec 30, 2017

@ollieparanoid

This comment has been minimized.

Show comment
Hide comment
@ollieparanoid

ollieparanoid Dec 30, 2017

Member

@pavelmachek: we use the code names for all devices, so we would have to change all of them to keep it consistent. I think it makes more sense to adjust the N9 packaging to device-nokia-rm-696 and linux-nokia-rm-696.

Member

ollieparanoid commented Dec 30, 2017

@pavelmachek: we use the code names for all devices, so we would have to change all of them to keep it consistent. I think it makes more sense to adjust the N9 packaging to device-nokia-rm-696 and linux-nokia-rm-696.

@filippz

This comment has been minimized.

Show comment
Hide comment
@filippz

filippz Dec 31, 2017

Contributor

I've completed SGX packaging (includes downloading of extracted content of Graphics_SDK_setuplinux_4_10_00_01_hardfp_minimal_demos.bin since that file requires i386 libs to be executed and I wasn't able to find a workaround). Only strange thing I'm struggling with is that I need to explicitly preload libgcompat (sudo env "LD_PRELOAD=/lib/libgcompat.so.0" eglinfo) and even then not all binaries work due to missing symbols, but at least some demos do run OK.

I can confirm that the compiler-gcc6.h is not needed and can be dropped.

I tried your (@ollieparanoid ) watchdog-kick hook but it didn't work, as sleep should be moved one line up, but the thing that breaks the boot is /etc/postmarketos-mkinitfs/hooks/00-device-nokia-n9.sh: line 12: sleep: not found. I'm not an expert by any means, but only viable workaround I've found is to check for existence of /bin/sleep before calling it. In any case - both watchdog scripts are modified (the OpenRC one now can accept optional -1 arg that is used when shutting down to call explicitly kick the watchdogs goodbye one last time)

The last thing remaining is the renaming of the packages to rm-696 and maybe we can also consider including SGX immediately, since I haven't made a separate commit for it in linux-nokia-n9 package (it's all in my repo) - but I'm open to suggestions.

Contributor

filippz commented Dec 31, 2017

I've completed SGX packaging (includes downloading of extracted content of Graphics_SDK_setuplinux_4_10_00_01_hardfp_minimal_demos.bin since that file requires i386 libs to be executed and I wasn't able to find a workaround). Only strange thing I'm struggling with is that I need to explicitly preload libgcompat (sudo env "LD_PRELOAD=/lib/libgcompat.so.0" eglinfo) and even then not all binaries work due to missing symbols, but at least some demos do run OK.

I can confirm that the compiler-gcc6.h is not needed and can be dropped.

I tried your (@ollieparanoid ) watchdog-kick hook but it didn't work, as sleep should be moved one line up, but the thing that breaks the boot is /etc/postmarketos-mkinitfs/hooks/00-device-nokia-n9.sh: line 12: sleep: not found. I'm not an expert by any means, but only viable workaround I've found is to check for existence of /bin/sleep before calling it. In any case - both watchdog scripts are modified (the OpenRC one now can accept optional -1 arg that is used when shutting down to call explicitly kick the watchdogs goodbye one last time)

The last thing remaining is the renaming of the packages to rm-696 and maybe we can also consider including SGX immediately, since I haven't made a separate commit for it in linux-nokia-n9 package (it's all in my repo) - but I'm open to suggestions.

@awilfox

This comment has been minimized.

Show comment
Hide comment
@awilfox

awilfox Jan 1, 2018

Can you tell me what eglinfo (etc) have for DT_INTERP? If you have scanelf installed, this should be as simple as running scanelf -i /path/to/eglinfo.

Please do report any missing symbols to the gcompat tracker. We can try to implement them.

awilfox commented Jan 1, 2018

Can you tell me what eglinfo (etc) have for DT_INTERP? If you have scanelf installed, this should be as simple as running scanelf -i /path/to/eglinfo.

Please do report any missing symbols to the gcompat tracker. We can try to implement them.

@filippz

This comment has been minimized.

Show comment
Hide comment
@filippz

filippz Jan 1, 2018

Contributor

eglinfo uses ld-linux.so.3, but I've linked that missing one to ld-musl-armhf.so.1 instead of ld-linux-armhf.so.3, so that is not a problem of gcompat.

Other binaries that don't work are complaining about missing __vsprintf_chk and I've made a report #43 for that.

Thank you for your time!

Contributor

filippz commented Jan 1, 2018

eglinfo uses ld-linux.so.3, but I've linked that missing one to ld-musl-armhf.so.1 instead of ld-linux-armhf.so.3, so that is not a problem of gcompat.

Other binaries that don't work are complaining about missing __vsprintf_chk and I've made a report #43 for that.

Thank you for your time!

@ollieparanoid

This comment has been minimized.

Show comment
Hide comment
@ollieparanoid

ollieparanoid Jan 1, 2018

Member

@filippz: Thanks for the status update!

I can't explain right now why the sleep binary would be missing at this point, as I've just confirmed in QEMU that the sleep binary exists with the debug-shell hook (which gets executed in the same line as all other hooks - including the N9 hook - in init.sh). Agreed, leaving the check for /bin/sleep in place seems to be the only way to make it work right now. The modifications you've made to the watchdog sound good!

Regarding the SGX blob: Right now the only proprietary packages we have are in the firmware folder, and since we're trying to make proprietary firmware and userspace optional (#756) I think it makes sense to discuss in that issue where exactly to package userland blobs before integrating it. I'll write my ideas down in the issue and recommend for now that we leave the SGX blob out of this PR and package it in a new one, when the details are figured out.

The TODO list from above has been updated. Thanks for the great work everyone!

@pavelmachek: Would you mind updating this pull request when you find time for it?

PS: The blog post is out and mentions the N9 progress.

Member

ollieparanoid commented Jan 1, 2018

@filippz: Thanks for the status update!

I can't explain right now why the sleep binary would be missing at this point, as I've just confirmed in QEMU that the sleep binary exists with the debug-shell hook (which gets executed in the same line as all other hooks - including the N9 hook - in init.sh). Agreed, leaving the check for /bin/sleep in place seems to be the only way to make it work right now. The modifications you've made to the watchdog sound good!

Regarding the SGX blob: Right now the only proprietary packages we have are in the firmware folder, and since we're trying to make proprietary firmware and userspace optional (#756) I think it makes sense to discuss in that issue where exactly to package userland blobs before integrating it. I'll write my ideas down in the issue and recommend for now that we leave the SGX blob out of this PR and package it in a new one, when the details are figured out.

The TODO list from above has been updated. Thanks for the great work everyone!

@pavelmachek: Would you mind updating this pull request when you find time for it?

PS: The blog post is out and mentions the N9 progress.

@filippz

This comment has been minimized.

Show comment
Hide comment
@filippz

filippz Jan 6, 2018

Contributor

@ollieparanoid Is it OK to compile kernel modules together with linux- package or is that something you'd like to see in separate APKBUILD? It way more easier to build it in same APKBUILD but we need to pull the TI SDK in to build them so I need to ask. I can make a supbackage for them and make userspace libs package to depend on that subpackage if that makes any difference.

Contributor

filippz commented Jan 6, 2018

@ollieparanoid Is it OK to compile kernel modules together with linux- package or is that something you'd like to see in separate APKBUILD? It way more easier to build it in same APKBUILD but we need to pull the TI SDK in to build them so I need to ask. I can make a supbackage for them and make userspace libs package to depend on that subpackage if that makes any difference.

@ollieparanoid

This comment has been minimized.

Show comment
Hide comment
@ollieparanoid

ollieparanoid Jan 6, 2018

Member

How does the SDK look like? If it's just a bunch of source code files (kernel modules?), then I would recommend that we put it in the linux APKBUILD for now (we don't use a shared kernel anyway). In that case we could possibly split it in its own APKBUILD when we use the shared kernel in the future.

But if it contains binaries, just like a firmware package, then I think it we should split it right now. The reasoning is, that we don't have any firmware outside of the aports/firmware folder.

Could you post a link to the SDK?

Member

ollieparanoid commented Jan 6, 2018

How does the SDK look like? If it's just a bunch of source code files (kernel modules?), then I would recommend that we put it in the linux APKBUILD for now (we don't use a shared kernel anyway). In that case we could possibly split it in its own APKBUILD when we use the shared kernel in the future.

But if it contains binaries, just like a firmware package, then I think it we should split it right now. The reasoning is, that we don't have any firmware outside of the aports/firmware folder.

Could you post a link to the SDK?

@filippz

This comment has been minimized.

Show comment
Hide comment
@filippz

filippz Jan 6, 2018

Contributor

Well, it not just kernel modules source, but also a bunch of .so and binary files. For this package I only need source files, and the rest is not used. Since those kernel modules are built using existing kernel sources that have been already built linux- package is a natural place for them. Once (or better if) I get userspace to use GPU, additional package will contain those libs and binaries - but to make things more complicated those libs/binaries should be placed in /usr/local/lib & /usr/local/bin. I guess modifying LD_LIBRARY_PATH is also an option if they must be placed elsewhere. I've already tried making that package and it's providing to be problematic due to a fact those libs should be used instead of mesa libs that are pulled in due to dependencies of various pmOS packages - but we'll see what to do if and when I get something usable.

The full download is here , but since it's binary file that needs x86 libs to be extracted, I've simply repacked it to tar.gz and uploaded to Dropbox here.

Contributor

filippz commented Jan 6, 2018

Well, it not just kernel modules source, but also a bunch of .so and binary files. For this package I only need source files, and the rest is not used. Since those kernel modules are built using existing kernel sources that have been already built linux- package is a natural place for them. Once (or better if) I get userspace to use GPU, additional package will contain those libs and binaries - but to make things more complicated those libs/binaries should be placed in /usr/local/lib & /usr/local/bin. I guess modifying LD_LIBRARY_PATH is also an option if they must be placed elsewhere. I've already tried making that package and it's providing to be problematic due to a fact those libs should be used instead of mesa libs that are pulled in due to dependencies of various pmOS packages - but we'll see what to do if and when I get something usable.

The full download is here , but since it's binary file that needs x86 libs to be extracted, I've simply repacked it to tar.gz and uploaded to Dropbox here.

@ollieparanoid

This comment has been minimized.

Show comment
Hide comment
@ollieparanoid

ollieparanoid Jan 6, 2018

Member

Hosting on dropbox doesn't look very stable to me, how about we split up the package and put the sources on github? We have this organization created for the purpose where the upstream source code isn't packaged in an useful way for us. So for this case, how about we put just the header files in an extra repo there and tag it with the version number of the SDK. Then you could use that as source and let GitHub generate a tarball for you - while at the same time it's convenient to browse the source online.

Please note that we can only do that if the license allows us to do this - are the kernel module sources under the GPLv2, just like the kernel?

And to answer your question: yes, I think it makes sense to put it in the kernel package then, especially if it makes it easier 👍

(I am not sure where exactly they are in the archive and I kind of need to go - but I could look into it more later.)

Member

ollieparanoid commented Jan 6, 2018

Hosting on dropbox doesn't look very stable to me, how about we split up the package and put the sources on github? We have this organization created for the purpose where the upstream source code isn't packaged in an useful way for us. So for this case, how about we put just the header files in an extra repo there and tag it with the version number of the SDK. Then you could use that as source and let GitHub generate a tarball for you - while at the same time it's convenient to browse the source online.

Please note that we can only do that if the license allows us to do this - are the kernel module sources under the GPLv2, just like the kernel?

And to answer your question: yes, I think it makes sense to put it in the kernel package then, especially if it makes it easier 👍

(I am not sure where exactly they are in the archive and I kind of need to go - but I could look into it more later.)

@filippz

This comment has been minimized.

Show comment
Hide comment
@filippz

filippz Jan 7, 2018

Contributor

I've decided to drop support for SGX for time being, as it seems that the guys from Maemo Leste managed to reuse old Nokia drivers on N900 with mainline kernel. In theory they are better choice since we know those were able to run X11 as is, and Nemo was running Wayland with those and an additional WSEGL plugin. I haven't had a chance to try it out, but if it works there will be a separate PR for it or TI ones if those turn out to be a better choice.

Contributor

filippz commented Jan 7, 2018

I've decided to drop support for SGX for time being, as it seems that the guys from Maemo Leste managed to reuse old Nokia drivers on N900 with mainline kernel. In theory they are better choice since we know those were able to run X11 as is, and Nemo was running Wayland with those and an additional WSEGL plugin. I haven't had a chance to try it out, but if it works there will be a separate PR for it or TI ones if those turn out to be a better choice.

@filippz

This comment has been minimized.

Show comment
Hide comment
@filippz

filippz Jan 7, 2018

Contributor

@pavelmachek - could you please update my commits in this PR with fresh versions from my repo? I don't think I can do it myself.

Contributor

filippz commented Jan 7, 2018

@pavelmachek - could you please update my commits in this PR with fresh versions from my repo? I don't think I can do it myself.

@pavelmachek

This comment has been minimized.

Show comment
Hide comment
@pavelmachek

pavelmachek Jan 7, 2018

Member
Member

pavelmachek commented Jan 7, 2018

@filippz

This comment has been minimized.

Show comment
Hide comment
@filippz

filippz Jan 8, 2018

Contributor

@ollieparanoid I guess it's up to you to decide. If you want you can then close this PR and I'll make another one, or @pavelmachek will update this one.

Contributor

filippz commented Jan 8, 2018

@ollieparanoid I guess it's up to you to decide. If you want you can then close this PR and I'll make another one, or @pavelmachek will update this one.

@ollieparanoid

This comment has been minimized.

Show comment
Hide comment
@ollieparanoid

ollieparanoid Jan 8, 2018

Member

Yeah I think it's easier when you open a new PR coming from your account. Looking forward to it!

Member

ollieparanoid commented Jan 8, 2018

Yeah I think it's easier when you open a new PR coming from your account. Looking forward to it!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.